رفع خطای Suspect شدن Database در SQL Server

وضعیت Suspect جدی‌ترین وضعیتی است که یک پایگاه‌داده در SQL Server می‌تواند به آن دچار شود. این یعنی SQL Server هنگام تلاش برای Recovery، با یک خطای غیرمنتظره روبه‌رو شده (معمولاً یک صفحه‌ی خراب یا Corrupt در فایل Data یا Log) و برای جلوگیری از آسیب بیشتر، دسترسی به کل پایگاه‌داده را قطع کرده است.

مهم‌ترین علت‌های Suspect شدن

• خرابی سخت‌افزاری دیسک — بدترین سناریو؛ بخشی از فایل .mdf یا .ldf روی دیسک آسیب دیده.
• قطع برق یا خاموشی ناگهانی سرور در وسط نوشتن داده روی دیسک.
• پر شدن ناگهانی دیسک هنگام یک عملیات نوشتن حیاتی.
• باگ در درایور دیسک یا نرم‌افزار آنتی‌ویروس که فایل‌های SQL Server را قفل یا تغییر داده.

مرحله ۱ — بررسی وضعیت دقیق با T-SQL

SELECT name, state_desc
FROM sys.databases
WHERE name = N'ShopDB';
-- اگر state_desc برابر SUSPECT بود، ادامه بده

مرحله ۲ — چک‌کردن Error Log برای علت دقیق

در SSMS → Management → SQL Server Logs دنبال پیام‌هایی با کد 824 (خطای I/O یا Page Checksum) یا 825 (خطای خواندن مکرر دیسک) بگرد — این کدها معمولاً نشانه‌ی مستقیم مشکل فیزیکی دیسک هستند.

گزینه‌ی ۱ (توصیه‌شده): Restore از Backup

اگر Backup معتبر داری، پایگاه‌داده‌ی فعلی را Drop یا Offline کن و از Backup، نسخه‌ی سالم را Restore کن. جزئیات کامل در راهنمای رفع خطاهای رایج هنگام Restore کردن Database.

گزینه ۲: تلاش برای بازیابی بدون Backup (با ریسک از‌دست‌رفتن داده)

اگر واقعاً هیچ Backup ای در دسترس نیست، می‌توانی با DBCC CHECKDB ابتدا میزان خرابی را ارزیابی کنی:

-- مرحله ۱: خارج کردن پایگاه‌داده از حالت Suspect به Emergency Mode (فقط Read-Only)
ALTER DATABASE ShopDB SET EMERGENCY;

-- مرحله ۲: بررسی میزان و نوع خرابی (بدون تغییر داده)
DBCC CHECKDB (ShopDB) WITH NO_INFOMSGS, ALL_ERRORMSGS;

-- مرحله ۳: قراردادن در Single-User Mode برای تعمیر
ALTER DATABASE ShopDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

-- مرحله ۴: تعمیر (فقط در صورت نبود Backup — ممکن است داده از بین برود)
DBCC CHECKDB (ShopDB, REPAIR_ALLOW_DATA_LOSS);

-- مرحله ۵: بازگرداندن به حالت چند-کاربره
ALTER DATABASE ShopDB SET MULTI_USER;

چک‌لیست پیشگیری برای آینده

جمع‌بندی

وضعیت Suspect معمولاً به معنای آسیب واقعی به داده است، نه فقط یک وقفه‌ی موقت. همیشه اول دنبال یک Backup سالم بگرد؛ فقط در نبود آن سراغ ابزارهای تعمیر با ریسک از‌دست‌رفتن داده برو. یک استراتژی Backup منظم، بهترین بیمه در برابر این سناریو است.