Showing posts with label updates. Show all posts
Showing posts with label updates. Show all posts

Wednesday, March 7, 2012

Deferred Updates versus In-Place Updates

The following question was posted on http://support.microsoft.com/kb/195760/en-us:



Q. What are the conditions under which deferred updates occur in SQL Server 7.0?

A. In SQL Server 7.0, all updates are in-place (direct), provided that the column or columns participating in the clustered index key are not changed. If a change is made to a UNIQUE clustered key, the update plan runs in a hybrid mode where the query processor combines direct and deferred updates. If the clustered key is not UNIQUE, all of the updates are run as deferred.

You can use SHOWPLAN to see examples of how this behavior works. Look for the SPLIT and COLLAPSE operators in the plan. If you find a SPLIT below the clustered index update, one of the clustering keys must have been changed. If a COLLAPSE operator is found, the update is running in a hybrid mode; SQL Server collapses delete and insert to the same key values into an in-place update.

NOTE: This behavior holds true for any index.

Has this behavior changed in SQL Server 2005?

Ken, whenever you are modifying the key columns of an index, the operation will be implemented as a delete followed by an insert, as the row needs to move within the B-Tree from the old location to the new. This can be explictly visible in the query plan showed in SHOWPLAN with the SPLIT operator, or be implicitly performed at the Storage Engine level. In SQL 2005, the number of cases where the SPLIT operator is employed is somewhat decreased, but it is still used. See the following trivial example:

use tempdb
go

create table t(p int primary key clustered)
go

update t set p = p + 1
go

Please let me know if you have more questions on this.
Thanks

|||

Okay, that tells me how changes to the primary key columns will be processed. Now what will happen if only the non-key columns are changed?

Ken

|||When only non key columns are updated, changes are performed in place, i.e. without moving the row inside the B-Tree. This is of course a much cheaper operation. You might want to take a look at a new SQL 2005 feature, the ability to include nonkey columns in nonclustered indexes.

Bottom line: an update statement will not maintain the nonclustered indexes whose columns are not being modified, will trigger row movements inside the indexes whose keys are being updated, and perform in place update to indexes whose only non key columns are being modified.

Deferred Updates versus In-Place Updates

The following question was posted on http://support.microsoft.com/kb/195760/en-us:



Q. What are the conditions under which deferred updates occur in SQL Server 7.0?

A. In SQL Server 7.0, all updates are in-place (direct), provided that the column or columns participating in the clustered index key are not changed. If a change is made to a UNIQUE clustered key, the update plan runs in a hybrid mode where the query processor combines direct and deferred updates. If the clustered key is not UNIQUE, all of the updates are run as deferred.

You can use SHOWPLAN to see examples of how this behavior works. Look for the SPLIT and COLLAPSE operators in the plan. If you find a SPLIT below the clustered index update, one of the clustering keys must have been changed. If a COLLAPSE operator is found, the update is running in a hybrid mode; SQL Server collapses delete and insert to the same key values into an in-place update.

NOTE: This behavior holds true for any index.

Has this behavior changed in SQL Server 2005?

Ken, whenever you are modifying the key columns of an index, the operation will be implemented as a delete followed by an insert, as the row needs to move within the B-Tree from the old location to the new. This can be explictly visible in the query plan showed in SHOWPLAN with the SPLIT operator, or be implicitly performed at the Storage Engine level. In SQL 2005, the number of cases where the SPLIT operator is employed is somewhat decreased, but it is still used. See the following trivial example:

use tempdb
go

create table t(p int primary key clustered)
go

update t set p = p + 1
go

Please let me know if you have more questions on this.
Thanks

|||

Okay, that tells me how changes to the primary key columns will be processed. Now what will happen if only the non-key columns are changed?

Ken

|||When only non key columns are updated, changes are performed in place, i.e. without moving the row inside the B-Tree. This is of course a much cheaper operation. You might want to take a look at a new SQL 2005 feature, the ability to include nonkey columns in nonclustered indexes.

Bottom line: an update statement will not maintain the nonclustered indexes whose columns are not being modified, will trigger row movements inside the indexes whose keys are being updated, and perform in place update to indexes whose only non key columns are being modified.

deferred updates in SQL2k (replication)

Hallo!
Are deferred updates possible in MSSQL2k?
I don't found anything in BOL.
Thanks Thomas
Would need some more info as to what you require, but outside of SQL Server
you can use message queuing to defer the update. In SQL Server replication
we have queued updatable subscribers, where the queue can be a sql table or
a MSMQ system. At a more simplistic level, all replication involves deferred
updates to the subscriber, as there is no zero latency technique. The degree
of deferral can be controlled by editing the agent's profile and by altering
the agent schedule.
Regards,
Paul Ibison
|||On Thu, 13 May 2004 09:08:53 +0100, "Paul Ibison"
<Paul.Ibison@.Pygmalion.Com> wrote:

>Would need some more info as to what you require, but outside of SQL Server
>you can use message queuing to defer the update. In SQL Server replication
>we have queued updatable subscribers, where the queue can be a sql table or
>a MSMQ system. At a more simplistic level, all replication involves deferred
>updates to the subscriber, as there is no zero latency technique. The degree
>of deferral can be controlled by editing the agent's profile and by altering
>the agent schedule.
>Regards,
>Paul Ibison
>
In some circumstances in MSSQL 6.5 an UPDATE will changed in
DELETE/INSERT-pair. In a bidirectional replication scenario with
vertical partitions and a special application the need of custom sp
triggers was required.
After 5 years of successful bidirectional replication I will change to
MSSQL2k.
I would know, if this in MSSQL2k similar?
If there are no deferred updates, then I needn't custom triggers or
dynamic filters (new feature in 2k).
thanks in advance
|||Thomas,
the same problem still exists in SQL 2000, although for singleton updates
you can use a trace flag to apply an update on the subscriber
(http://support.microsoft.com/default...microsoft.com
:80/support/kb/articles/q302/3/41.ASP&NoWebContent=1)
HTH,
Paul Ibison

Deferred Updates (Singleton Updates)

How is deferred update implemented in SQL 2005 Replication? I have tried to
set the trace flag 8207 like in SQL 2000, but this is not working.
Thanks,
Andrew
MCSA,MCDBA
Hi Andrew - I've just tried adding the trace flag and it is added OK as
confirmed by "dbcc tracestatus". Did you have a problem adding it or was the
problem later on?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .