عکاسی از دیتابیس!

ساخت Database Snapshot از قابلیتهایی است که شاید کمتر به آن نیاز پیدا کرده باشیم اما زمانی هم که این قابلیت میتوانسته کمک کند، احتمالا از وجود آن بی خبر بوده ایم.
سناریوی زیر را در نظر بگیرید:
برای مطالعه و بهینه سازی سرعت دیتابیس خود یک بکاپ تهیه کرده و با نام دیگری ریستور میکنید تا تستها روی آن انجام شود و دیتابیس اصلی تغییر نکند. اتفاقا حجم این دیتابیس بسیار زیاد است و پس از هر سری آزمایش، هنگامی که میخواهید آنرا به وضعیت قبل از تست برگردانید، مجددا باید ریستور نمایید که زمان زیادی از شما صرف میکند.

این یکی از مواردی است که Database Snapshot کمک میکند تا هم زمان خود را ذخیره کنید و هم IO کمتری به سرور عملیاتی خود وارد نمایید.
قبل از اینکه وارد دستورات ساخت Snapshot شویم، لازم است عملکرد آنرا را بشناسیم:
وقتی Snapshot از دیتابیس خاصی ساخته شود، آنرا در زیر مجموعه Database Snapshots خواهید دید که میتوان USE کرد و کوئری گرفت. اکنون Snapshot فاقد دیتا است و کوئری شما در اصل از دیتابیسی که از آن عکس گرفته اید واکشی میگردد. اگر دیتابیس اصلی ویرایش شود، نهایتا این ویرایش روی حداقل یک Page تاثیر خواهد گذاشت.

چون دیتابیس شما دارای Snapshot است، محتویات Page قبل از ویرایش به دیتابیس Snapshot منتقل میگردد سپس Page در مبدا به روز میگردد. به مرور Pageهای دیگری را ویرایش میکنید و اگر Page اولین بار است که ویرایش میشود، کار کپی به Snapshot اتفاق خواهد افتاد. این عمل اصطلاحا Copy On Write نامیده میشود که از قابلیتهای NTFS است.
میتوان نتیجه گرفت که Snapshot در بدو ساخته شدن اصلا حجمی ندارد اما به مرور با ویرایش دیتابیس اصلی و کپی شدن Pageها حجم میگیرد.
به خاطر داشته باشید در دیتابیس اصلی هر Page فقط یکبار آن هم در اولین بار ویرایش، کپی میگردد. حال برگردیم به Snapshot و دوباره کوئری بزنیم. زمان برای این دیتابیس متوقف شده! هنگامی که اطلاعات را میخوانید، تماما وضعیت زمانی را نشان میدهد که Snapshot گرفته اید و از تغییر خبری نیست. فرضا اگر از جدولی Select بزنید که پس از ساخت Snapshot نیمی از سطرهای آنرا به روز کرده اید، میتوان گفت نصف Pageهای آن از دیتابیس اصلی به دیتابیس Snapshot کپی شده است.

پس هنگام کوئری گرفتن، آن دسته از Pageهایی که تغییر یافته اند، از Snapshot واکشی میگردد و نیمی از Pageها که هنوز ویرایش نشده اند از دیتابیس اصلی. چون همانطور که از نام Snapshot پیداست، مانند عکسی است که از دیتابیس گرفته اید و باید همیشه وضعیت همان زمان عکس گرفتن را به شما نشان دهد.
مایکروسافت معتقد است شما میتوانید برای نگهداری سالهای مالی مختلف، Snapshot بسازید تا وضعیت هر مقطع زمانی را تثبیت نمایید. ولی با این ایده موافق نیستم چون Snapshot همیشه به دیتابیس اصلی وابسته است و اگر آسیب ببیند، Snapshot کارایی خود را از دست میدهد.
کاربرد واقعی Snapshot که مد نظر ما قرار گرفته آن است که دیتابیس اصلی میتواند با سرعت بسیار زیاد، به زمان ساخت Snapshot بازگشت یا Revert انجام دهد و مانند عمل ریستور، شما را به وضعیت قبل از انجام تستها برساند.

اشاره کردیم که ساخت Snapshot برای دیتابیس باعث میگردد زمان در دیتابیس Snapshot متوقف شده، بتوانیم وضعیت اطلاعات در زمان عکس گرفتن را با کوئری مشاهده نماییم حتی اگر دیتابیس اصلی ویرایش شده باشد.
اما قابلیت جالب Snapshot آن است  که در مدت زمان بسیار کوتاه میتوانید دیتابیس اصلی را به آن بازگردانید یا اصطلاحا Revert انجام دهید. برای سناریویی که مثال زده شده بود، پس از انجام تست روی دیتابیس، مایلید آنرا مجددا به وضعیت ابتدایی بازگردانید تا تست تکرار شود. اگر دیتابیس از حجم بالایی برخوردار باشد، ریستور کردن زمان قابل توجهی صرف خواهد نمود در حالیکه Revert به Snapshot بسیار سریع است و فقط اطلاعات دست خورده را بازیابی مینماید!

اکنون دستورات لازم:

هر تعداد که دیتابیس شما Data File داشته باشد، به همان تعداد در Snapshot نیز فایل تعریف خواهد شد. به این فایلها اصطلاحا Sparse File اطلاق میگردد. اگر دیتابیس MyDB دارای دو دیتا فایل به نامهای MyDB_File1 و MyDB_File2 باشد، دستور ساخت Snapshot بدین صورت خواهد بود:

CREATE DATABASE MyDB_Snapshot ON
( NAME = MyDB_File1, FILENAME = 'C:\MyDB_File1_.ss' ),
( NAME = MyDB_File2, FILENAME = 'C:\MyDB_File2_.ss' )
AS SNAPSHOT OF MyDB;
GO

اگر برای دیتابیس بزرگ Snapshot بسازید، Explorer سایز فایل را مانند دیتا فایل اصلی نشان میدهد، اما وقتی از آن Properties بگیرید در قسمت Size on Disk متوجه میشوید که فقط چند کیلو بایت حجم دارد.
برای Revert کردن از این دستور استفاده نمایید:

RESTORE DATABASE MyDB FROM DATABASE_SNAPSHOT='MyDB_Snapshot'