Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
influent
Constraint Violating Yak Guru
367 Posts |
 Posted - 2012-08-20 : 15:53:51
|
| I'm trying to determine whether I should use the rowversion column to find data changes for an ETL process that will push updates to a cube. According to Erland Sommarskog, in the post linked to below, "if there are plenty of concurrent updates, it can become very difficult to avoid that you miss changes" using rowversion. Unfortunately I can't find more information about that and while I trust Erland, it would be easier to use rowversion if we could.http://social.msdn.microsoft.com/Forums/en/transactsql/thread/7f1cea96-7cf4-4feb-97f4-c15095adf449 |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2012-08-20 : 16:08:44
|
| Erland's argument basically boils down to, if you are pulling millions of rows that are experiencing thousands of transactions while they're being ETL'd, then some changes could be missed if you have to compare rowversions. With Change Tracking that's less of a concern since you'd in effect be reading the transaction log records. CT also reduces the amount of data you'd ultimately have to compare, especially if < 50% of the data changes between each ETL run. With rowversion you could end up comparing every row every time it runs. |
 |
|
|
influent
Constraint Violating Yak Guru
367 Posts |
Posted - 2012-08-20 : 17:35:50
|
| Perfect, thanks. I'm expecting less than 0.1% of the data to be changed with each execution of the ETL, so you've convinced me to use Change Tracking. |
|
|
|
|
|
|
rowversion vs Change Tracking