فصل ۱۶ — Scaling Workloads: Database Snapshots

Database Snapshot نمای Read-only و Transactionally Consistent از Database در یک نقطه زمان است. Snapshot از Sparse File و Copy-on-Write استفاده می‌کند؛ هنگام تغییر Page در Source، نسخه اصلی Page قبل از Write در Sparse File Snapshot کپی می‌شود.

در لحظه Create، Snapshot تقریباً Data را کپی نمی‌کند. Map به Source Page وجود دارد. اولین تغییر یک Page باعث Copy نسخه قدیمی به Snapshot می‌شود و سپس Source Page تغییر می‌کند.

Read از Snapshot اگر Page هنوز تغییر نکرده باشد از Source و اگر تغییر کرده باشد از Sparse File خوانده می‌شود. با گذر زمان و تغییر بیشتر Source، Snapshot Space رشد می‌کند.

کاربرد و محدودیت

Snapshot برای Reporting کوتاه‌مدت، Recover اشتباه User و Point-in-time Comparison مفید است. Snapshot Backup نیست؛ اگر Source Database/Storage از بین برود Snapshot وابسته نیز قابل اتکا نیست. Snapshot قدیمی می‌تواند Space زیادی مصرف کند.

کتاب Database ‏Chapter16 را برای مثال می‌سازد.

Table و داده نمونه ایجاد می‌شود تا تغییرات بعد از Snapshot قابل مقایسه باشد.

درج داده تکمیل و Source آماده Snapshot می‌شود. Snapshot باید برای هر Data File یک Sparse File Destination داشته باشد؛ Log File در Snapshot وجود ندارد.

CREATE DATABASE Chapter16_Snapshot
ON
( NAME = Chapter16,
  FILENAME = 'D:\Snapshots\Chapter16_Snapshot.ss' )
AS SNAPSHOT OF Chapter16;

Client را می‌توان برای Reporting به آخرین Snapshot هدایت کرد، اما Snapshot Read-only است و Naming/Retention باید مدیریت شود.

Recover Lost Data

برای بازیابی Row حذف‌شده می‌توان داده را از Snapshot SELECT و به Source INSERT کرد. همچنین Database را می‌توان با RESTORE DATABASE ... FROM DATABASE_SNAPSHOT به کل Snapshot برگرداند؛ این Rollback همه تغییرات بعد از Snapshot را حذف می‌کند و باید بسیار آگاهانه اجرا شود.