آموزش بازیابی داده های سالم از دیتابیس خراب SQL

چگونه اطلاعات سالم را از پایگاه داده SQL خراب خارج کنیم؟ احتمال خرابی داده یک جزء جدانشدنی از دنیای پایگاه داده است. اصولا مشکلات خرابی داده از سیستم دیسک سخت است به این صورت که در حین نوشتن داده ها بر روی دیسک سخت به هر دلیلی یکسری اختلالاتی ایجاد شده که نوشتن داده را به صورت کامل به اتمام نمی رساند یا داده به طور صحیح نوشته نمیشود.معمولا مدیران پایگاه داده به صورت روزانه یا هفتگی از پایگاه داده فایل پشتیبان تهیه می کنند تا در مواقعی این چنینی بتوانند داده های خراب را از فایل پشتیبان بازیابی کنند. ولی متاسفانه به دلیل مسائلی، فایل های پشتیبان یا غیر قابل دسترس هستند یا آنها نیز به صورت خراب در آمده و یا داده های خراب را پشتیبانی و ذخیره کرده اند. در چنین شرایطی که نه فایل پشتیبان درست و کامل در دسترس است و نه می توان خیلی از داده ها را از دست داد چه باید کرد؟ در این مقاله، یک مختصر اشاره ای به بازیابی داده های خراب بدون فایل پشتیبان می کنم.

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
سرفصل های این مطلب
  1. داستان

داستان

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

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x298c0e0a; actual: 0x86e3f354). 
It occurred during a read of page (1:348) in database ID 12 at offset 0x000000002b8000 in file…. 

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

  1. زمانی برای این کار نیست
  2. و البته اینکه خود فایل پشتیبان به طور کلی خراب است.

در این شرایط اصولا مدیران پایگاه داده وسایل خود را جمع کرده و نامه استعفای خود را روی میز مدیر خود می گذارند. ولی شما باید چه کار کنید! در این شرایط خونسردی خود را حفظ کرده، و به دنبال چاره باشید. برای بازیابی داده های خراب باری خطای 824 بسیار راه وجود دارد از قبیل:

  1. استفاده از DBCC CHECKDB با پارامتر REPAIR__REBUILD و یا REPAIR__ALLOW__DATA_LOSS که البته از دست دادن داده یک مشکل دیگر است.
  2. استفاده از فایل پشتیبان برای بازیابی Data Page های خراب.

ولی برای انجام اینها، پایگاه داده باید از دسترس خارج شود. ولی همانطور که گفته شد این پایگاه داده نباید از دسترس سیستمهای پرداخت خارج شود. به مثال زیر توجه کنید :

Select * from dbo.TempRows;

/*Msg 824, Level 24, State 2, Line 16
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x298c0e0a; actual: 0x86e3f354). 
It occurred during a read of page (1:348) in database ID 12 at offset 0x000000002b8000 in file 
'C:\Program Files (x86)\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\TempData.mdf'.  
Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
*/

همانطور که می بینید، داده خراب در Data Page 348 است. حالا با دستورات پائین به داخل 348 رفته و داده ی خراب را به صورت دستی پیدا می کنیم

DBCC TRACEON(3604);
DBCC PAGE ('TempData',1,348,2);
/*011FC744:   00000046 61726420 536f6c75 74696f6e 73205364  ...Fard Solutions Sd
011FC758:   6e204268 64202020 20202020 20020000 10002a00  n Bhd        .....*.
011FC76C:   38170000 00000000 46617264 20536f6c 7574696f  8.......Fard Solutio
011FC780:   6e732053 646e2042 68642020 20202020 20ffffff  ns Sdn Bhd       ÿÿÿ
011FC794:   ffffffff ffffffff ff000000 00466172 6420536f  ÿÿÿÿÿÿÿÿÿ....Fard So
011FC7A8:   6c757469 6f6e7320 53646e20 42686420 20202020  lutions Sdn Bhd     
011FC7BC:   20202002 00001000 2a003a17 00000000 00004661     .....*.:.......Fa
011FC7D0:   72642053 6f6c7574 696f6e73 2053646e 20426864  rd Solutions Sdn Bhd
011FC7E4:   20202020 20202020 02000010 002a003b 17000000          .....*.;....*/

همانطور که مشاهده می کنید در ردیف 011FC794 و 011FC780 یک سری F مشاهده می کنید. این قسمت از داده خراب است و باید از داده های سالم جدا شود. توجه داشته باشید که دستور DBCC CHECKDB با دستور REPAIR__ALLOW__DATA__LOSS تمام Data Page را حذف کرده و حدود 160 رکورد سالم دیگر هم حذف می شود.در مرحله بعد توسط دستور زیر نوع Page Verify را به NONE در می آوریم تا بتوانیم داده های سالم را از داده های خراب جدا کنیم.

Alter Database TempData Set Page_Verify None With No_Wait

با این دستور شما در حقیقت Data Page خراب را سالم کردید، یعنی شما می توانید تمامی رکورد ها را بدون خطا از پایگاه داده بازیابی کنید.با استفاده از دستور زیر شما می توانید تمامی رکوردها در Data Page خراب را بازیابی کرده و داده های خراب را شناسایی کنید.

Select sys.fn_physlocformatter(%%physloc%%) As [Location],* from dbo.TempRows
Where sys.fn_physlocformatter(%%physloc%%) Like '(1:348:%'

همانطور که مشاهده می کنید، در تصویر زیر دو رکورد به صورت NULL مشاهده می شود که این دو در حقیقت همان داده های خراب هستند که باید از بین بروند.

وب سایت توسینسو

حالا زمان آن رسیده که نوع Page Verify را به حالت CheckSum برگردانیم.


حمید ج. فرد
حمید ج. فرد

متخصص پایگاه داده SQL Server Microsoft Certified Master: SQL Server 2008 Microsoft Certified Solutions Master: Charter - Data Platform Microsoft Certified Solutions Expert: Data Platform Microsoft Certified Solutions Associate: SQL Server 2012 Microsoft Certified IT Professional Microsoft Certified Technology Specialist Microsoft Certified Professional Developer Microsoft Certified Trainer CIW Database Design Specialist

نظرات