The use of impersonation as I??™ve described is an intriguing idea worth consideration in certain system
configurations. For example, you might have a fully contained subsystem that you can back up and
restore independently of the rest of the system. In the event of data loss, you must be able to re-create
records in the subsystem with little or no impact on consistency. In the example of the manifest system,
perhaps a routine in the larger system can re-create shipping information based on sales orders.
The impersonation technique clearly should be the exception and not the norm, and as with everything
else, it would require significant testing before you could give it a stamp of approval in a
production situation. Still, I wouldn??™t be surprised to find myself using this technique in the future.
Inherent Risks
The drive to have the database restored as quickly as possible often places excessive
stress on a DBA. Have you ever had the CEO of your company stand and look over your
shoulder as you work? The more stress you face, the faster you try to work, and the more
likely it is that you??™ll make a mistake.
Pages:
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265