This
technique can come in handy when multiple developers or users need a temporary snapshot
of the database, either for reporting or testing purposes.
Leveraging Snapshots in Development
One area I see database snapshots being used extensively (perhaps excessively) is within
development environments. Since SQL Server 2005 expands on the level of development
that you can do with the database, having a technique to test a database change and
quickly revert back is ideal. Enter database snapshots.
Say you create a new set of stored procedures, but before putting them on the server,
you make a database snapshot. After applying them, you notice that you did more harm
than good with your changes. You apply the snapshot??”rinse and repeat. This can apply
to raw development, unit testing, and quality assurance??”you name it.
This poses a potential problem. If the developers have the rights to create snapshots,
uncoordinated ???snapping back??? could be surprising to other developers. If you??™re
in charge of creating snapshots, that may create an undue and sporadic workload. These
are not technology problems, though; these are process issues that you need to address
before using the technology.
Pages:
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441