April 19, 2013 at 1:23 pm
We've got transactional replication setup on a number of tables in a database from one SQL 2008 server to another. Many of the tables have a timestamp/rowversion column defined, and in our table replication options, we have "convert timestamp to binary" selected to make sure the values stay consistent between the two databases.
Periodically, I've noticed that there will be a large backlog of replicated transactions to deliver, and looking through at what the replication account is doing, the vast majority of the operations are just updating the timestamp column to a new value.
We're trying to figure out what might cause just the timestamp/rowversion column to update on the source db, and sadly I'm not finding a ton of info. It appears that standard maintenance operations (index reorgs/rebuilds, etc) don't update it, anyone have any other suggestions?
April 19, 2013 at 1:36 pm
could it be someone was cleaning up data and used a REPLACE without a WHERE statement?
the rowversion gets incrmeneted even thought here was no "real" change:
CREATE TABLE WHATEVER(
WHATEVERID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
DESCRIP VARCHAR(30),
MyRowVersion ROWVERSION
)
INSERT INTO WHATEVER(DESCRIP)
SELECT 'APPLES' UNION
SELECT 'ORANGES' UNION
SELECT 'BANANAS' UNION
SELECT 'GRAPES' UNION
SELECT 'CHERRIES' UNION
SELECT 'KIWI'
--affects ALL rows in the table, but no real change to data, but rowversion is modified.
update whatever set descrip = REPLACE(descrip,'SASQUATCH','')
--vs
--no matching rows, rowversion preserved.
update whatever set descrip = REPLACE(descrip,'SASQUATCH','') WHERE DESCRIP LIKE '%SASQUATCH%'
Lowell
April 19, 2013 at 2:08 pm
Lowell (4/19/2013)
could it be someone was cleaning up data and used a REPLACE without a WHERE statement?the rowversion gets incrmeneted even thought here was no "real" change:
Looks like doing something stupid like running an update and setting a field to the value that already exists does this too, I'm bugging my devs more, but of course no one wants to fess up.
April 19, 2013 at 2:24 pm
dspeterson (4/19/2013)
Lowell (4/19/2013)
could it be someone was cleaning up data and used a REPLACE without a WHERE statement?the rowversion gets incrmeneted even thought here was no "real" change:
Looks like doing something stupid like running an update and setting a field to the value that already exists does this too, I'm bugging my devs more, but of course no one wants to fess up.
Consider that almost 100% of updates sprocs don't look to see if the values have changed. If they did they would be horrible to write and they would be super slow.
create MyUpdateProc
(
@Col1 varchar(10),
@ID int
) as
update MyTable
set Col1 = @Col1
where ID = @ID
The above is a super simplified typical update sproc. This would cause the rowversion to be modified.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply