I was referring to cases where the disk controller has ignored the engine
careful write order, by collapsing disk sector writes and applying them in a
sequence optimal for the disk but out of order from a FB perspective (Jim's
comment about micro code optimization).
In that case, the
09.05.2014 20:08, Leyne, Sean wrote:
I was referring to cases where the disk controller has ignored the engine
careful write order, by collapsing disk sector writes and applying them in
a
sequence optimal for the disk but out of order from a FB perspective (Jim's
comment about micro code
Hello, All.
If a record is inserted or modified, what will be order of page written:
data page
first then index page or vice versa?
--
WBR, SD.
--
Is your legacy SCM system holding you back? Join Perforce
That's an impossible problem to solve, which is one of the many reasons
that retrievals consider the index to be potentially noisy.
That said, in the original implementation, at least, a transaction
couldn't commit until everything touched had been written. But what
constituted a write was
08.05.2014 18:13, Dimitry Sibiryakov wrote:
If a record is inserted or modified, what will be order of page written: data
page
first then index page or vice versa?
IIRC, there is no precedence dependency between these two pages, so they
can be written in any order.
Dmitry
08.05.2014 19:22, Dmitry Yemanov wrote:
IIRC, there is no precedence dependency between these two pages, so they
can be written in any order.
So, with FW=OFF, killing server in-between can produce both orphan nodes and
missing
entries depending on luck and parallel activity.
--
WBR,
08.05.2014 19:22, Dmitry Yemanov wrote:
IIRC, there is no precedence dependency between these two pages, so
they can be written in any order.
So, with FW=OFF, killing server in-between can produce both orphan nodes
and missing entries depending on luck and parallel activity.
True,
08.05.2014 19:49, Leyne, Sean wrote:
True, but that is database corruption problem, not an order of precedence
issue.
Orphan nodes are harmless, missing entries are worse.
--
WBR, SD.
--
Is your legacy SCM
08.05.2014 21:49, Leyne, Sean wrote:
IIRC, there is no precedence dependency between these two pages, so
they can be written in any order.
So, with FW=OFF, killing server in-between can produce both orphan nodes
and missing entries depending on luck and parallel activity.
True, but that is
08.05.2014 22:01, Dimitry Sibiryakov wrote:
True, but that is database corruption problem, not an order of precedence
issue.
Orphan nodes are harmless, missing entries are worse.
We're talking about [missing] entries that should be pointing to
invisible (garbage) record versions. What
08.05.2014 22:08, Dimitry Sibiryakov wrote:
In this case transaction won't be marked as committed and record will be
garbage
collected sooner or later.
Ah, so you meant the case where both TIP and the data page were written
to disk, but the index page was not? Here I agree that FW=OFF makes
So, with FW=OFF, killing server in-between can produce both orphan
nodes and missing entries depending on luck and parallel activity.
True, but that is database corruption problem, not an order of precedence
issue.
That is why using FW=OFF in a production environment (on any
Failures happen.
No matter how much you spend, how much time you design, failures happen.
You might even have a boss who thinks its fun to randomly shut off machines
to ensure the load balancing and fail over systems work
So, you design with failure in mind.
This is a discussion that
13 matches
Mail list logo