همان طور که می‌دانید وجود یک Backup کامل و آزمایش شده و یک طرح بازگردانی درست برای دیتابیس‌های SQL Server برای سازمانی که در آن کارمی‌کنید؛ اگر مهمترین موضوع نباشد قطعا یکی از مهمترین کارهای شما به عنوان یک DBA است. در این مقاله می‌خواهیم مباحث و مسائل مربوط به مدیریت پایگاه‌های داده در SQL Server را با شما مرور کنیم.
انواع روش Backup
انواع Backupهایی که می‌توانید فراهم کنیدعبارتند از:
- Full backups
- Differential backups
- Transaction log backups
- File backups
- Filegroup backups
- Partial backups
- Full backups
متداول‌ترین Backupهای SQL Server، Completeیا full هستند که به Database Backup نیز معروفند. در این نوع بکاپگیری از کلیه Databaseهای موجود بر روی Instance به همراه همگی Transaction Logهای موجود در آن Backup گرفته می‌شود. با این روش شما براحتی می‌توانید اطلاعات خود را Recover یا بازیابی کنید. این مسئله امکان بازگشت ساده‌ترین شکل دیتابیس را فراهم می‌کند، زیرا همه‌ی محتواها در یک Backup قرار می‌گیرند.
T-SQL:
ایجاد یک Backup کامل از دیتابیس Didgah Test به یک فایل دیسک
BACKUP DATABASE Didgah Test TO DISK = ‘D:\chargoon\backup\DidgahTest.bak’
- Differential backups
گزینه‌ی دیگر برای کمک به بازیابی، ایجاد Backupهای “Differential” است. یکBackup Differential نوعی پشتیبان‌گیری از هر حوزه‌ای‌ست که از زمان ایجاد آخرین Full Backup تغییر کرده است.
Backup Differential از همه‌ی حوزه‌هایی که از زمان آخرین Full Backup تغییر پیدا کرده‌اند، نسخ پشتیبان تهیه می‌کند. هر حوزه از هشت صفحه‌ی KB تشکیل شده، بنابراین یک حوزه شامل 64 KB داده است. هر زمان که داده‌ای تغییر می کند، یک پرچم روشن می‌شود تا SQL Server نیز مطلع شود که اگر یکDifferential Backup ایجاد شده باشد باید حاوی داده‌ای از این حوزه باشد. وقتی یک Backup کامل (Full)انجام می‌شود، همه‌ی این پرچم‌ها خاموش می‌شوند.
بنابراین اگر یک Backup Full و سپس Differential Backup گرفته شود،Differential فقط حوزه‌هایی را در خود دارد که تغییر کرده‌اند. جالب اینجاست اگر یکDifferential Backup جدید گرفته شود، این Backup جدید ،هر حوزه‌ای را که از زمان آخرین Backup کامل تغییر کرده، در خود خواهد داشت؛ بنابراین وقتی که قصد بازگرداندن دیتابیس را دارید، برای رسیدن به متداول‌ترین زمان فقط کافیست Full Backup و آخرینDifferential Backup را بازگردانید.
اگر دیتابیس روی مدل ریکاوری ساده تنظیم شده باشد، می‌توانید ازBackupهای کامل و Differential استفاده کنید. این امر اجازه‌ی انجام ریکاوری در زمان مشخص را نمی‌دهد؛ اما اگرBackup کامل داشته باشید، به شما اجازه می‌دهد تا داده‌ی خود را بازگردانید.
اگر دیتابیس روی مدل ریکاوری Full و یا Bulk logged تنظیم شده باشد، نمی‌توانید ازBackupهای Differential برای حذف تراکنش‌هایی که نیاز به بازگردانده شدن خواهند داشت، استفاده کنید. از آنجایی که Differential از زمان آخرین Full Backup تمام حوزه‌ها را Backup خواهد گرفت، در زمان بازگشت می‌توانید Full Backup خود و آخرین Differential Backup و سپس Backupهای Transaction log را که پس از آخرینDifferential Backup تهیه شده‌اند، بازگردانید. این امر تعداد فایل‌هایی را که نیاز به بازگردانده شدن دارند، کاهش می‌دهد.
T-SQL:
ایجاد Backup transaction log از دیتابیسDidgahTest بر روی فایل دیسک
BACKUP DATABASE DidgahTest TO DISK = D:\chargoon\backup\DidgahTest.DIF’ WITH DIFFERENTIAL
- Transaction log backups
اگر دیتابیس بر روی Full یا Bulk logged تنظیم شده باشد، می‌توانید BackupهایTransaction Log را منتشر کنید. با داشتن این Backupها به همراه Backupهای کامل، می‌توانید به راحتی داده‌های خود را برگردانید. در این موقعیت، اگر شخصی به طور تصادفی همه‌ی داده‌ها را در یک دیتابیس حذف کند، می‌توانید دیتابیس را به نقطه‌ای درست قبل از حذف داده، بازگردانید. تنها نکته قابل توجه این است که اگر دیتابیس بر مدل ریکاوری “Bulk-logged” تنظیم شده باشد و یک عملکرد Bulk منتشر شود، به بازگرداندن همه تراکنش log نیاز دارید.
Backup تراکنش log به شما اجازه می‌دهد تا بخش فعال تراکنش را Backup بگیرید؛ بنابراین پس ازاینکه یک Backup “Full یا Differential را انتشار دادید، Backup transaction log دارای تراکنش هایی خواهد بود که پس از کامل شدن Backupهای دیگر، ایجاد شدند. پس از اینکهBackup transaction log منتشر شد، فضای داخل transaction log می‌تواند برای دیگر پردازش‌ها مجددا استفاده شود.
T-SQL:
ایجاد Backup transaction log از دیتابیس Didgah Test بر روی فایل دیسک
BACKUP LOG T-SQL: TO DISK = ‘D:\Chargoon\Backup\DidgahTest.trn’
عوامل خراب شدن زنجیره بکآپ:
هنگامی که یک نسخه پشتیبان از تراکنش (TLOG) تهیه می‌شود، اطلاعات پشتیبان در پایگاه داده msdb در جداول مختلف ذخیره می‌شوند. اطلاعات ذخیره شده را اطلاعاتی مانند backup_type، logical_device_name، physical_device_name، is_copy_only، is_snapshot و ستون‌های مختلف …_ lsn (lsn = log sequence number) تشکیل می‌دهند.
LSN چیست؟
هر رکورد در ورودی تراکنش SQL Server توسط یک log sequence number (LSN) شناسایی می‌شود. اگرLSN2 بزرگتر از LSN1 باشد، نشان می‌دهد تغییری که در رکورد ثبت شده توسط LSN2 ذکر شده پس از تغییر توصیف شده توسط رکورد LSN1 رخ داده است.
LSN رکورد ورودی می‌تواند برای ساخت توالی‌های restore مفید و کاربردی باشد. از آنجا که LSNها مرتب می‌شوند، می‌توانند برای برابری و نابرابری با علائم (<،>، =، <=،> =) مقایسه شوند. چنین مقایسه‌هایی در هنگام ساخت توالی‌های restore مفید هستند.
LSNها در طی یک توالی restore به طور داخلی مورد استفاده قرار می‌گیرند تا نقطه‌ای را که توسط داده‌ها بازسازی شده‌اند، ردیابی کنند. هنگامیکه یک پشتیبان بازیابی می‌شود، داده‌ها به LSN مربوط به نقطه در زمان پشتیبان‌گیری، باز می‌گردند. پشتیبان‌گیری differential و log، LSN را به زمان دیگری منتقل می کند که به یک LSN بالاتر، مرتبط است.
همان طور که می‌دانید LDF وقایع تراکنش‌های که همراه با تغییر هستند را نگه می‌دارد. اگر پشتیبان‌ها به درستی تنظیم شوند LDFها حجم کمی خواهند داشت و هنگامی رشد می‌کنند که حالت بازیابی پایگاه داده را به FULL تغییر دهیم؛اما فراموش کنیم که از آن log backup بگیریم. هنگامی که زمان انجام تراکنشی طولانی شود و یا اینکه حجم تغییرات در تراکنش زیاد شود، وقایع آن در فایل log دیتابیس ذخیره می‌شود که این باعث رشدlog file خواهد شد که در ادامه دلایل کلی این موضوع را بیشتر توضیح می‌دهیم.
برای بازگردان اطلاعات از روی نسخ پشتیبان که باید موارد زیر مورد توجه قرار گیرد.
- همه‌ی یک فایل‌های نسخ پشتیبان Log transaction که بعد ازDiff تهیه شده‌اند باید موجود باشند.
- در صورت نیاز به استفاده از Tran،Diff،Full باید آخرین Full ریستور شود، سپس Diff مورد نظر، سپس همه‌ی Tranهای بعد از Diff تا زمان مورد نیاز شما همگی پشت سرهم، ریستور شوند.
- در صورت نیاز به استفاده از Tran،Diff،Full بایدRecovery-Model دیتابیس هدف، حتما در مدل Full و یا Bulk Logged قرار گرفته باشد. در صورت استفاده از مود Simple تهیه پشتیبان Tran بی‌معنی است و SQL Server به دلایل منطقی اجازه تهیه این مدل نسخه‌ی پشتیبان را نمی‌دهد.
- اگر نسخه‌ی پشتیبان Log transaction با گزینه‌ی TRUNCATE_ONLY انجام شود، پشتیبان‌هایLog transaction بعدی در زنجیره‌‌ای مجزا تهیه می‌شوند و قابلیت بازگردان و اتصال به فایل‌های قبلی را ندارند.
- اگر پشتیبان FULL Database با گزینه COPY_ONLY گرفته شود. امکان ریستور کردن Diff و یا Tran به اتصال آن به این Fullها وجود ندارد.
اختلالات ناشی از Full Text Search
از قابلیت Full Text می‌توان به عنوان یکی از مزیت‌ها برای جستجوی محتوای فایل‌هایی که در SQL Server وارد شده‌اند نام برد. می‌دانید که برای بهروری بیشتر نرم‌افزار، نیاز به جستجوی اطلاعات در برنامه وجود دارد. می‌توان اطلاعات را با کلماتی مانند “Where ” و یا “Like” و یا هزاران راه دیگر جستجو کرد .در این مقاله می‌خواهیم چگونگی بکارگیری تکنیک Full-text-Search برای جستجو بر روی داده‌های حجیم را بررسی کنیم.
در مقابل Full-Text Search از Like نمی‌توان برای جستجو در بین داده‌ها استفاده کرد؛ چراکه این ابزار فقط برای جستجو در بین کاراکترها، طراحی شده است در نتیجه برای جستجو در بین حجم زیادی از داده‌ها، دستور Like در مقابل Full-Text Search بسیار کندتر عمل خواهد کرد. برای انجام این کار، دستور Like ممکن است چندین دقیقه طول بکشد درحالیکه Full-Text Search در چند ثانیه نتیجه را نشان می‌دهد، به این صورت که برای هر کلمه یک index تعریف و هنگام جستجو از آن استفاده می‌کند در نتیجه سرعت جستجو بالا می‌رود.
این قابلیت جزو ویژگی‌های هر دیتابیس است یعنی اطلاعات این Catalog درون هر دیتابیس منحصرا برای خود کلمات ذخیره می‌شود، به عبارت دیگر این اطلاعات در دیتابیس‌های سیستمی و عمومی SQL Server ذخیره نمی‌شوند. این مدل ذخیره‌سازی به این معنی است که در زمان تهیه نسخ پشتیبان این Catalogها نیز درون فایل پشتیبان، ذخیره می‌شوند که در زمان بازیابی دیتابیس این اطلاعات نیز بازیابی شود.
همانطور که می‌دانید در زمان بازیابی در سرور مقصد همزمان با اینکهPage به Page اطلاعات از فایل پشتیبانی خوانده شده و در فایل مقصد نوشته می‌شود سپس فرآنید آپدیت نسخه‌ی دیتابیس نیز به نسخه‌ی سرور مقصد انجام می‌شود، همین فرآیند برای Storage Catalog مربوط به Full-Text نیز باید انجام شود؛ اما بر اساس تجربه Catalog که در نسخه‌ی SQL Server 2008 ساخته شده برای بازیابی در نسخه‌های جدیدتر دچار مشکل می‌شود و SQLServer نمی‌تواند فرآنید آپدیت را طی کند. این موضوع باعث می‌شود که کل فرآنید بازیابی با شکست مواجه شود.
تنها راه‌حل این است که در دیتابیس موجود در سرور مبدا Full-Text-Catalog را حذف و مجددا اقدام به تهیه نسخه‌ی پشتیبانی کرد و از این فایل جدید برای بازیابی در سرور مقصد استفاده کرد. یا اینکه اگر سرور مقصد وجود ندارد، SQL Server هم با نسخه سرور مبدا، انجام شود.
