رفع خطای 3636 در SQL Server

رفع خطای 3636 در SQL Server: راهنمای جامع مشکل پردازش متادیتای بکاپ و ریستور دیتابیس

خطای 3636 در SQL Server که با شرح “Backup metadata processing error – Backup/restore issue” شناخته می‌شود، یکی از خطاهای حیاتی است که می‌تواند فرآیندهای حیاتی پشتیبان‌گیری (Backup) و بازیابی (Restore) پایگاه‌های داده را مختل کند. این خطا به طور خاص به مشکلات در پردازش متادیتای فایل بکاپ اشاره دارد و می‌تواند مانع از موفقیت‌آمیز بودن عملیات بازیابی دیتابیس شود، که در نهایت به خطر از دست رفتن داده‌ها منجر می‌گردد. در دنیای امروز که داده‌ها از اهمیت بالایی برخوردارند، توانایی اطمینان از سلامت بکاپ‌ها و قابلیت بازیابی آن‌ها، یک رکن اساسی در استراتژی Disaster Recovery (بازیابی فاجعه) هر سازمانی است. مواجهه با خطای 3636 می‌تواند زنگ خطری جدی برای ادمین‌های دیتابیس (DBA) باشد، زیرا مستقیماً بر قابلیت اطمینان سیستم‌های مدیریت داده تأثیر می‌گذارد. درک عمیق این خطا، علل آن و راهکارهای جامع برای رفع آن، برای هر متخصصی که با SQL Server کار می‌کند، ضروری است.

متادیتای بکاپ شامل اطلاعات حیاتی در مورد فایل بکاپ است. این اطلاعات جزئیاتی مانند نام پایگاه داده، زمان پشتیبان‌گیری، نوع پشتیبان‌گیری (کامل، تفاضلی، لاگ تراکنش)، اندازه فایل، تعداد فایل‌های داده و لاگ، و همچنین اطلاعاتی در مورد نسخه SQL Server که بکاپ در آن گرفته شده است را در بر می‌گیرد. در واقع، متادیتا “شناسنامه” فایل بکاپ است که SQL Server برای درک و پردازش صحیح آن به آن نیاز دارد. اگر این متادیتا به هر دلیلی آسیب ببیند یا به درستی خوانده نشود، SQL Server نمی‌تواند عملیات بازیابی را انجام دهد و خطای 3636 را صادر می‌کند. این خطا می‌تواند هنگام تلاش برای بازیابی دیتابیس از یک فایل بکاپ خاص، یا حتی گاهی اوقات در حین عملیات پشتیبان‌گیری رخ دهد، اگرچه بیشتر در مرحله بازیابی مشاهده می‌شود. هدف از این مقاله، ارائه یک راهنمای کامل برای درک، تشخیص و رفع این خطای مهم است تا اطمینان حاصل شود که داده‌های شما همیشه قابل بازیابی و محافظت شده باقی می‌مانند.

علل بروز خطای 3636 در SQL Server

درک علل ریشه‌ای خطای 3636 برای تشخیص و رفع موثر آن بسیار مهم است. این خطا اغلب نشان‌دهنده یک مشکل عمیق‌تر در فایل بکاپ یا محیط اطراف آن است. در اینجا به بررسی جزئی‌تر علل اصلی این خطا می‌پردازیم:

آسیب‌دیدگی فایل بکاپ (Backup File Corruption)

این مورد یکی از شایع‌ترین علل بروز خطای 3636 است. آسیب‌دیدگی می‌تواند به بخش‌های مختلفی از فایل بکاپ، به ویژه بخش متادیتای آن، وارد شود. علل این آسیب‌دیدگی می‌تواند شامل موارد زیر باشد:

• مشکلات سخت‌افزاری: نقص در هارد دیسک، کنترلر RAID، یا حافظه (RAM) سرور در حین عملیات پشتیبان‌گیری یا ذخیره فایل بکاپ می‌تواند منجر به نوشتن داده‌های ناقص یا خراب در فایل بکاپ شود.
• مشکلات شبکه: اگر فایل بکاپ از طریق شبکه به اشتراک گذاشته شده یا به مقصد راه دور منتقل می‌شود، ناپایداری شبکه، قطعی اتصال، یا خطاهای انتقال داده می‌تواند به آسیب‌دیدگی فایل منجر شود.
• نرم‌افزارهای معیوب: گاهی اوقات، مشکلات در نرم‌افزار SQL Server، درایورهای سیستم عامل، یا حتی نرم‌افزارهای آنتی‌ویروس که فایل بکاپ را اسکن می‌کنند، می‌توانند باعث آسیب‌دیدگی شوند.
• پایگاه داده منبع خراب: اگر پایگاه داده‌ای که از آن بکاپ گرفته می‌شود، در زمان بکاپ‌گیری خودش دچار فساد و خرابی (Corruption) باشد، این خرابی می‌تواند به متادیتای بکاپ منتقل شده و در نتیجه فایل بکاپ را نیز خراب کند.
• نقص در فرآیند پشتیبان‌گیری: قطع شدن ناگهانی برق، خاموش شدن سرور در حین بکاپ‌گیری، یا خطاهای داخلی در موتور SQL Server می‌تواند منجر به ایجاد یک فایل بکاپ ناقص یا آسیب‌دیده شود.

عدم تطابق نسخه SQL Server (SQL Server Version Mismatch)

یکی دیگر از دلایل رایج این خطای 3636، تلاش برای بازیابی یک بکاپ گرفته شده در نسخه‌ای بالاتر از SQL Server به نسخه‌ای پایین‌تر است. به عنوان مثال، اگر بکاپی در SQL Server 2019 گرفته شده باشد و شما سعی کنید آن را در SQL Server 2017 بازیابی کنید، این خطا ممکن است رخ دهد. SQL Server به شدت از بازیابی بکاپ‌های “بالاتر به پایین‌تر” جلوگیری می‌کند تا از مشکلات سازگاری و از دست رفتن داده جلوگیری کند. متادیتای فایل بکاپ حاوی اطلاعات نسخه است و اگر SQL Server مقصد قادر به تفسیر آن نباشد، این خطا ممکن است ظاهر شود.

کمبود مجوزهای دسترسی (Insufficient Permissions)

برای انجام موفقیت‌آمیز عملیات بازیابی، حساب سرویس SQL Server و همچنین حساب کاربری که عملیات بازیابی را آغاز می‌کند، به مجوزهای خاصی نیاز دارند:

• مجوزهای حساب سرویس SQL Server: این حساب باید دارای مجوزهای “خواندنی” (Read) برای دسترسی به فایل بکاپ در مسیر ذخیره‌سازی آن و مجوزهای “نوشتنی” (Write) برای مسیرهایی که فایل‌های داده (MDF) و لاگ (LDF) دیتابیس در آنجا بازیابی می‌شوند، باشد.
• مجوزهای کاربر انجام‌دهنده عملیات: کاربری که دستور RESTORE را اجرا می‌کند، باید دارای نقش sysadmin یا dbcreator باشد، یا حداقل مجوزهای CREATE DATABASE و ALTER ANY DATABASE را داشته باشد.

اگر هر یک از این مجوزها ناکافی باشند، SQL Server نمی‌تواند به فایل بکاپ دسترسی پیدا کند یا فایل‌های دیتابیس را ایجاد کند، که این امر می‌تواند منجر به خطای 3636 شود.

مشکلات سیستم فایل (File System Issues)

مشکلات در سیستم فایل ویندوز (NTFS) که فایل بکاپ در آن ذخیره شده است نیز می‌تواند منجر به این خطا شود. این مشکلات می‌توانند شامل موارد زیر باشند:

• خرابی سیستم فایل: خرابی منطقی در ساختار سیستم فایل که دسترسی به فایل‌ها را مختل می‌کند.
• بدسکتورها (Bad Sectors): وجود بدسکتورها در هارد دیسک که فایل بکاپ روی آن‌ها ذخیره شده، می‌تواند مانع از خواندن صحیح بخش‌های خاصی از فایل، از جمله متادیتای آن، شود.
• نقص در درایورها: درایورهای قدیمی یا ناسازگار دیسک می‌توانند به مشکلات I/O و در نهایت خرابی فایل بکاپ منجر شوند.

نقص در ابزارهای پشتیبان‌گیری شخص ثالث (Third-Party Backup Tool Issues)

اگر از ابزارهای پشتیبان‌گیری شخص ثالث برای مدیریت بکاپ‌های SQL Server استفاده می‌کنید، مشکلاتی در نحوه تعامل این ابزارها با SQL Server’s VSS Writer (Volume Shadow Copy Service) یا با خود فرآیند بکاپ‌گیری داخلی SQL Server، می‌تواند منجر به ایجاد فایل‌های بکاپ خراب یا ناقص شود که سپس در عملیات بازیابی خطای 3636 را ایجاد می‌کنند.

شناسایی دقیق علت اصلی خطای 3636 گام اول برای اعمال راهکار مناسب و اطمینان از بازیابی موفقیت‌آمیز پایگاه داده است.

راهکارهای عملی برای رفع خطای 3636

پس از درک علل احتمالی خطای 3636، زمان آن رسیده که به سراغ راهکارهای عملی برای رفع این مشکل برویم. این راهکارها شامل مراحل عیب‌یابی و ترمیم هستند که به ترتیب و با دقت باید اجرا شوند:

الف. بررسی یکپارچگی فایل بکاپ (Backup File Integrity Check)

اولین گام حیاتی برای تشخیص خطای 3636، بررسی این است که آیا فایل بکاپ اصلاً قابل استفاده است یا خیر. SQL Server دستوری به نام RESTORE VERIFYONLY را برای این منظور ارائه می‌دهد. این دستور فایل بکاپ را می‌خواند و بررسی می‌کند که آیا هدینگ (Header) آن به درستی فرمت شده است، آیا تمام مجموعه‌های بکاپ کامل هستند، و آیا فایل قابل خواندن است. این دستور در واقع یک آزمایش مقدماتی برای اطمینان از سلامت کلی فایل بکاپ است.

برای اجرای این دستور، از سینتکس زیر استفاده کنید:

RESTORE VERIFYONLY
FROM DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Backup\YourDatabaseName.bak';

در این دستور، N'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Backup\YourDatabaseName.bak' مسیر کامل و نام فایل بکاپ شما است که باید آن را با مسیر واقعی فایل خود جایگزین کنید. اگر این دستور با موفقیت اجرا شود، پیامی مشابه “The backup set on device ‘C:\…’ is valid.” را دریافت خواهید کرد. در این صورت، فایل بکاپ به احتمال زیاد آسیب‌دیده نیست و علت خطا چیز دیگری است. اما اگر RESTORE VERIFYONLY با خطا مواجه شود (از جمله خطای 3636)، به این معنی است که فایل بکاپ شما خراب شده و غیرقابل استفاده است. در چنین شرایطی، باید به سراغ راهکارهای بعدی بروید.

ب. استفاده از بکاپ سالم دیگر (Using a Different Backup)

اگر RESTORE VERIFYONLY نشان داد که فایل بکاپ شما خراب است، بهترین و مطمئن‌ترین راه حل این است که یک فایل بکاپ دیگر، ترجیحاً یک بکاپ قدیمی‌تر و شناخته شده سالم، را امتحان کنید. اینجاست که اهمیت داشتن استراتژی پشتیبان‌گیری چندگانه و نگهداری چندین نسخه بکاپ در مکان‌های مختلف مشخص می‌شود. تلاش برای بازیابی از یک بکاپ سالم دیگر، شانس موفقیت شما را به شدت افزایش می‌دهد. اگر بکاپ‌های قبلی نیز با همین مشکل مواجه شدند، این می‌تواند نشان‌دهنده یک مشکل سیستماتیک‌تر در فرآیند بکاپ‌گیری شما باشد.

ج. بررسی و رفع مشکلات سخت‌افزاری (Checking and Resolving Hardware Issues)

همانطور که قبلاً ذکر شد، مشکلات سخت‌افزاری می‌توانند عامل اصلی آسیب‌دیدگی فایل‌های بکاپ باشند. بررسی سلامت سخت‌افزار، به ویژه دیسک‌های ذخیره‌سازی و اتصالات شبکه، بسیار مهم است. برای دیسک‌ها، باید موارد زیر را بررسی کنید:

• گزارش‌های S.M.A.R.T: داده‌های S.M.A.R.T (Self-Monitoring, Analysis and Reporting Technology) دیسک‌های سخت را بررسی کنید تا نشانه‌هایی از خرابی قریب‌الوقوع را شناسایی کنید.
• گزارش رویداد ویندوز (Windows Event Viewer): بخش‌های “System” و “Application” در Event Viewer را برای یافتن خطاهای مربوط به دیسک (مانند ID 7, 11, 153) یا شبکه (مانند ID 1070) بررسی کنید.
• ابزارهای تشخیصی دیسک: از ابزارهای مخصوص سازنده دیسک برای بررسی سلامت فیزیکی دیسک استفاده کنید.

در مورد مشکلات شبکه، اطمینان حاصل کنید که ارتباط شبکه پایدار است و هیچ پکت لاسی (Packet Loss) یا تاخیر بالایی (High Latency) وجود ندارد، به خصوص اگر بکاپ‌ها از طریق شبکه منتقل می‌شوند.

د. بررسی مجوزهای دسترسی (Checking Permissions)

مطمئن شوید که حساب سرویس SQL Server و همچنین حساب کاربری که عملیات بازیابی را انجام می‌دهد، دارای مجوزهای کافی هستند. این یک مرحله رایج و اغلب نادیده گرفته شده است:

• حساب سرویس SQL Server:
  • اطمینان حاصل کنید که حساب سرویس SQL Server (معمولاً NT Service\MSSQLSERVER یا یک حساب دامنه خاص) دارای مجوز “خواندنی” (Read) برای پوشه‌ای که فایل بکاپ در آن قرار دارد، و مجوز “نوشتنی” (Write) برای پوشه‌های مقصد فایل‌های .mdf و .ldf است.
  • برای بررسی مجوزها، روی پوشه راست کلیک کرده، به “Properties” -> “Security” بروید و مجوزهای مربوط به حساب سرویس را بررسی کنید.
• کاربر انجام‌دهنده عملیات بازیابی:
  • کاربری که دستور RESTORE را اجرا می‌کند باید دارای نقش sysadmin یا dbcreator باشد. اگر نه، باید حداقل مجوزهای CREATE DATABASE و ALTER ANY DATABASE را داشته باشد.
  • این مجوزها را می‌توان در SQL Server Management Studio (SSMS) تحت “Security” -> “Logins” -> “Properties” -> “Server Roles” یا “User Mappings” بررسی کرد.

ه. بررسی نسخه‌های SQL Server (Checking SQL Server Versions)

عدم تطابق نسخه یکی از دلایل اصلی شکست بازیابی است. شما نمی‌توانید یک بکاپ گرفته شده در یک نسخه جدیدتر از SQL Server را در یک نسخه قدیمی‌تر بازیابی کنید. برای بررسی جزئیات نسخه بکاپ، می‌توانید از دستور RESTORE FILELISTONLY استفاده کنید:

RESTORE FILELISTONLY
FROM DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Backup\YourDatabaseName.bak';

این دستور اطلاعاتی در مورد فایل‌های دیتابیس موجود در بکاپ، از جمله نسخه SQL Server که بکاپ در آن گرفته شده است، را نشان می‌دهد. در خروجی این دستور، ستونی به نام SoftwareVersion وجود دارد که نسخه موتور SQL Server را نشان می‌دهد (به عنوان مثال، 15 برای SQL Server 2019، 14 برای SQL Server 2017 و غیره). اطمینان حاصل کنید که نسخه SQL Server مقصد شما برابر یا بالاتر از این نسخه باشد. در غیر این صورت، شما باید دیتابیس را به یک نسخه SQL Server بالاتر بازیابی کنید.

و. استفاده از گزینه WITH CONTINUE_AFTER_ERROR (پیشنهاد نمی‌شود!)

این گزینه یک راه حل آخرین راهکار است و به شدت توصیه نمی‌شود، زیرا می‌تواند منجر به از دست رفتن داده شود و تنها در شرایطی که هیچ راه دیگری برای بازیابی داده ندارید و مایلید ریسک از دست دادن بخشی از داده‌ها را بپذیرید، باید استفاده شود. CONTINUE_AFTER_ERROR به SQL Server می‌گوید که حتی در صورت مواجهه با خطاهایی مانند خرابی متادیتا، فرآیند بازیابی را ادامه دهد. این کار می‌تواند منجر به یک دیتابیس ناسالم و با داده‌های ناقص شود.

RESTORE DATABASE YourDatabaseName
FROM DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Backup\YourDatabaseName.bak'
WITH MOVE N'YourDatabase_Data' TO N'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\YourDatabaseName_Data.mdf',
MOVE N'YourDatabase_Log' TO N'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\YourDatabaseName_Log.ldf',
REPLACE, CONTINUE_AFTER_ERROR;

در این دستور، YourDatabaseName نام دیتابیس شما، و مقادیر MOVE مسیرهای جدید فایل‌های داده و لاگ هستند. REPLACE برای جایگزینی دیتابیس موجود با همین نام است (با احتیاط استفاده شود). اگر تصمیم به استفاده از این گزینه گرفتید، حتماً پس از بازیابی، دیتابیس را با DBCC CHECKDB (که در ادامه توضیح داده می‌شود) به دقت بررسی کنید.

ز. بررسی SQL Server Error Log و Windows Event Viewer (Checking Logs)

لاگ‌های خطا، گنجینه‌ای از اطلاعات تشخیصی هستند. پس از مواجهه با خطای 3636، بلافاصله SQL Server Error Log را بررسی کنید. این لاگ می‌تواند جزئیات بیشتری در مورد علت دقیق خطا، مانند پیام‌های I/O شکست‌خورده یا مشکلات دسترسی، ارائه دهد. همچنین، Windows Event Viewer را (به خصوص Application و System logs) بررسی کنید. خطاهایی که همزمان با خطای 3636 رخ داده‌اند (مانند خطاهای دیسک یا شبکه) می‌توانند سرنخ‌های مهمی برای تشخیص مشکل سخت‌افزاری ارائه دهند.

ح. اقدام پیشگیرانه: چک‌سام بکاپ (Preventive Measure: Backup Checksum)

برای جلوگیری از بروز خطای 3636 در آینده، بسیار مهم است که در حین عملیات پشتیبان‌گیری از گزینه WITH CHECKSUM استفاده کنید. وقتی CHECKSUM فعال است، SQL Server در طول فرآیند بکاپ‌گیری، یک چک‌سام از داده‌های روی دیسک ایجاد کرده و آن را در فایل بکاپ ذخیره می‌کند. سپس، هنگام بازیابی، SQL Server این چک‌سام را دوباره محاسبه می‌کند و با مقادیر ذخیره شده مقایسه می‌کند. اگر چک‌سام‌ها مطابقت نداشته باشند، نشان‌دهنده خرابی داده در فایل بکاپ است و عملیات بازیابی را با خطا متوقف می‌کند. این کار به شما امکان می‌دهد تا خرابی فایل بکاپ را زودتر و در مرحله بازیابی شناسایی کنید، نه زمانی که به آن نیاز مبرم دارید.

BACKUP DATABASE YourDatabaseName
TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Backup\YourDatabaseName_New.bak'
WITH COMPRESSION, CHECKSUM;

در این دستور، COMPRESSION برای کاهش حجم فایل بکاپ و CHECKSUM برای تضمین یکپارچگی داده‌ها در فایل بکاپ استفاده شده است. فعال کردن این گزینه یک عادت خوب در هر استراتژی پشتیبان‌گیری است.

ط. اقدام پیشگیرانه: بررسی یکپارچگی دیتابیس (Preventive Measure: Database Integrity Check)

اگر پایگاه داده منبع شما از قبل خراب باشد، بکاپی که از آن می‌گیرید نیز می‌تواند حاوی خرابی باشد و در نهایت به خطای 3636 منجر شود. برای جلوگیری از این مشکل، به طور منظم دیتابیس‌های خود را با دستور DBCC CHECKDB بررسی کنید. این دستور یکپارچگی منطقی و فیزیکی تمام اشیاء در دیتابیس مشخص شده را بررسی می‌کند و هرگونه خرابی را گزارش می‌دهد.

DBCC CHECKDB (N'YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS;

این دستور را باید به صورت دوره‌ای (مثلاً هفتگی) بر روی تمام دیتابیس‌های مهم اجرا کنید. اگر DBCC CHECKDB خطایی را گزارش کند، باید قبل از گرفتن بکاپ‌های جدید، آن خطاها را برطرف کنید. با این کار، اطمینان حاصل می‌کنید که بکاپ‌های شما از یک منبع سالم گرفته شده‌اند و احتمال بروز خطای 3636 به دلیل خرابی دیتابیس منبع کاهش می‌یابد.

با پیاده‌سازی این راهکارهای جامع، هم می‌توانید خطای 3636 فعلی را عیب‌یابی و رفع کنید و هم اقدامات پیشگیرانه لازم را برای جلوگیری از وقوع مجدد آن در آینده انجام دهید. حفظ سلامت بکاپ‌ها و قابلیت اطمینان فرآیندهای بازیابی برای تداوم کسب و کار و حفاظت از داده‌ها بسیار حیاتی است.