At the moment (and I reserve the right to change my mind in the future), I include SQL Server
2008??™s Change Tracking feature in the same category of data auditing rather than one that relates to
disaster recovery. The problem with user disasters is that the actual problem is rarely known. Yes, you
could use Change Tracking to attempt to recover specific changes, but you would need to know exactly
what the issues are to determine exactly what changes need to be recovered.
I may change my mind on the utility of Change Tracking as a disaster recovery tool the more I
work with it as SQL Server 2008 becomes prevalent in the workforce. It??™s good to keep an open mind
on new features like this.
Change Tracking can potentially place a heavy load on your storage system and on
your server in general. Unlike Change Data Capture, a SQL Server 2008 feature that provides
similar functionality, Change Tracking is performed using a sort of two-phase
commit. Change Data Capture, on the other hand, works by reading from the transaction
log. These features definitely add to the ability to handle user disasters, but upon initial
review, I wouldn??™t consider them a panacea to the problem.
Pages:
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614