نحوه بازیابی دیتابیس Master در حالتهای مختلف

پایگاه داده master را نمی توان مانند سایر user database ها یا system databaseها بازیابی کرد زیرا SQL Server نمی تواند بدون پایگاه داده master فعال اجرا شود. در حالی که به ندرت نیاز به بازیابی یک پایگاه داده master وجود دارد، در صورت بروز این نیاز، ضروری است که یک DBA برای این وضعیت آماده شود. این مقاله شرایطی را که ممکن است یک پایگاه داده master نیاز به بازیابی داشته باشد و نحوه انجام صحیح مراحل را شرح می دهد.

چه زمانی باید یک پایگاه داده master را بازیابی کرد؟

دلیل شماره 1 که یک پایگاه داده Master نیاز به بازیابی دارد، خرابی است. اگر Master خراب شود، بهترین اقدام معمولاً بازیابی از یک نسخه پشتیبان است. داده‌های موجود در Master نسبتاً ثابت هستند، بنابراین در اکثر سناریوها، از دست دادن چند ساعت از سوابق نباید مشکل بزرگی باشد.

دلایل دیگر برای بازگردانی master ممکن است بازیابی login حذف شده یا پسوردی باشد که تغییر کرده و بنا به دلایلی قابل بازنشانی نیست. اگر پایگاه داده Master نیاز به بازیابی برای بازیابی داده ها یا آبجکتهای کاربر داشته باشد، این فرصتی خواهد بود تا آنها را از Master به یک دیتابیس کاربر منتقل کنید.

دو روش برای بازیابی پایگاه داده Master

2 روش برای بازیابی پایگاه داده اصلی وجود دارد. اولین مورد فقط برای بازیابی یک پایگاه داده Master در Server SQL در حال اجرا قابل استفاده است. اگر مشکل خرابی پایگاه داده Master باشد و این خرابی باعث شود SQL Server از راه اندازی امتناع کند، باید از روش دوم استفاده شود. البته اگر SQL Server در حال اجرا باشد هم می‌توان بصورت دلخواه از روش دوم استفاده کرد.

ابتدا بیایید یک نسخه پشتیبان از دیتابیس تهیه کنیم که بتوانیم از آن برای بازیابی استفاده کنیم.

;backup database master to disk = ‘c:\master.bak’ with compression

هنگامی که سرویس SQL قادر به راه اندازی است، پایگاه داده اصلی SQL Server را بازیابی کنید

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

;restore database master from disk = ‘c:\master.bak’ with replace

نتیجه خطای زیر خواهد بود:

Msg 3108, Level 16, State 1, Line 2
To restore the master database, the server must be running in single-user mode. For information on starting in single-user mode, see “How to: Start an Instance of SQL Server (sqlservr.exe)” in Books Online.

Msg 3013, Level 16, State 1, Line 2
RESTORE DATABASE is terminating abnormally

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

پنجره خط فرمان را باز کرده و run as administrator را انتخاب کنید

در خط فرمان، سرویس را متوقف کنید و با استفاده از دستورات net stop و net start و پارامتر /m برای اجبار حالت تک کاربر، آن را مجددا راه اندازی کنید. کد زیر برای یک اینستنس پیش فرض است. در صورت اجرای یک named instance،عبارت MSSQLSERVER را با نام کامل سرویس تغییر دهید.

C:\WINDOWS\system32>net stop MSSQLSERVERThe SQL Server (MSSQLSERVER) service is stopping…The SQL Server (MSSQLSERVER) service was stopped successfully. C:\WINDOWS\system32>net start MSSQLSERVER /mThe SQL Server (MSSQLSERVER) service is starting.The SQL Server (MSSQLSERVER) service was started successfully.

این سرویس در حالت تک کاربر خواهد بود به این معنی که دقیقاً یک SPID می تواند به اینستنس متصل شود. بسیار مهم است که یک اتصال موجود توسط شخصی که تلاش می کند بازیابی کند حفظ شود. هر شخصی که پنجره SSMS را باز کند به این معنی است که، SPIDهای زیادی متصل خواهد شد. با تلاش برای اتصال دقیقاً با یک پنجره new query از این امر اجتناب کنید و همچنین سعی نکنید Object Explorer را باز کنید زیرا سعی می کند از اتصال استفاده کند.

پس از ایجاد یک اتصال، تلاش برای ورود به Object Explorer یا یک پنجره پرس و جو دوم منجر به این خطا می شود.

اکنون که سرویس راه اندازی شد و پنجره پرس و جو جدید متصل شد، بازیابی که قبلاً ناموفق بود باید کار کند.

در این مرحله سرویس SQL Server متوقف خواهد شد. می توان آن را با استفاده از خط فرمان (بدون پارامتر /m) یا با استفاده از هر روش رایج دیگری مانند پنجره Services یا SQL Server Configuration Manager راه اندازی مجدد کرد.

اولین قدم پس از تهیه نسخه پشتیبان از سرور باید اجرای یک DBCC CHECKDB در برابر پایگاه داده Master باشد تا تأیید شود که هر گونه خرابی برطرف شده است.

هنگامی که سرویس SQL قادر به راه اندازی نیست، پایگاه داده Master را بازیابی کنید

اگر سرویس راه اندازی نشود چگونه می توان دستور restore را اجرا کرد؟

اگر این اتفاق افتاد این مراحلی است که باید برای تکمیل بازیابی دنبال کنید.

مرحله 1

اینستنس دیگری از SQL Server از همان نسخه اصلی SQL Server را پیدا کنید. شاید یک development box کار کند. اگر اینستنس دیگری در دسترس نیست، نصب سریع نسخه Express یا Developer Edition ممکن است مناسب باشد. در صورتی که این رویکرد به صورت اختیاری انتخاب شود و سرویس شروع شود، می‌توان از اینستنس fail شده بعنوان secondary instance استفاده کرد. این دمو از primary instance بعنوان secondary استفاده می کند.

مرحله 2

نسخه پشتیبان Master پایگاه داده را به اینستنس SQL Server بازگردانی کنید که گویی یک پایگاه داده معمولی کاربر است. باید از یک نام جایگزین استفاده شود، به عنوان مثال. master_recovery.

restore database master_recovery from disk = ‘c:\master.bak’ withmove ‘master’ to ‘C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\master_recovery.mdf’,move ‘mastlog’ to ‘C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\mastlog_recovery.ldf’;

مرحله 3

اکنون که پایگاه داده آنلاین است، مرحله 3 این است که آن پایگاه داده را از اینستنس درحال کار جدا کنید.

USE [master]

EXEC master.dbo.sp_detach_db @dbname = N’master_recovery’

مرحله 4

در این مرحله 2 فایل پایگاه داده دیگر به اینستنس درحال کار SQL Server متصل نیستند. مرحله 4 انتقال 2 فایل به سرور میزبان اینتنس ای است که مشکل با master را تجربه می کند. اگر این روش به صورت اختیاری انتخاب شده باشد و بازیابی در اینستنس مورد نظر انجام شده باشد، فایل ها از قبل وجود دارند!

مرحله 5

در مرحله بعد، برای مرحله 5، باید به اینستنسی از SQL Server که مشکل دارد، گفته شود که این فایل های جدید را به جای فایل های خراب در نظر بگیرد. این را می توان با تغییر پارامترهای راه اندازی SQL Server برای اشاره به این فایل های جدید یا تغییر نام master.mdf و mastlog.ldf به نام های جدید و تغییر نام فایل های _recovery برای مطابقت با نام فایل های پیش فرض انجام داد. در هر صورت، شروع بعدی سرویس از فایل های جدید به جای فایل های بد استفاده می کند.

برای این دمو، پارامترهای راه‌اندازی به جای فایل‌های پیش‌فرض به فایل‌های _recovery اشاره کردند. سپس سرویس مجدداً راه اندازی شد (از زمانی که در حال اجرا بود). اکنون این سرویس از پایگاه داده master بازیابی شده به جای پایگاه داده master ناموفق استفاده می کند.

آخرین مرحله اجرای DBCC CHECKDB در این کپی از Master است. اگر این تلاش خراب است، به گذشته برگردید تا یک کپی خوب پیدا شود. CheckDB را نمی توان در مرحله قبلی اجرا کرد زیرا یک پایگاه داده master می تواند هنگام بررسی به عنوان پایگاه داده کاربر، اشکالات کاذب تولید کند.

چه داده هایی هنگام بازیابی پایگاه داده Master از بین می رود؟

با بازگردانی یک پایگاه داده master قدیمی یا گرفتن یک کپی از اینستنس دیگری، چه داده هایی ممکن است در این انتقال از بین رفته باشد؟

بیشتر داده ها در پایگاه داده master ثابت هستند، اما چند روز به عقب برگردیم، چند چیز برای بررسی وجود دارد.

آیا لاگینی بین پشتیبان گیری و بازیابی اضافه یا حذف شده است؟ اینها باید بازسازی یا حذف شوند.

آیا کسی رمز عبور خود را در آن پنجره تغییر داده است؟ اگر چنین باشد، رمز عبور قدیمی آنها دوباره به اجرا در می آید.

آیا تخصیص role server تغییر کرده است؟ اینها برگردانده خواهند شد.

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

هر تنظیماتی که مانند تنظیمات sp_configure تغییر کرده بود، برگردانده می شد.

بازیابی دیتابیس Master حتی بدون نسخه پشتیبان

اگر هیچ نسخه پشتیبان نداشتید، ما هنوز کمی کار داریم.

اتصال مجدد پایگاه های داده

با استفاده از SSMS و حساب مدیریتی که هنگام نصب آن استفاده کرده اید، به سرور خود متصل شوید. اولین چیزی که متوجه خواهید شد این است که وقتی درخت پایگاه داده را گسترش می دهید خالی است. این به این دلیل است که master حاوی تمام اطلاعات مکان پایگاه داده است و اکنون از بین رفته است. اما پایگاه های داده هنوز وجود دارند، فقط باید به SQL Server بگوییم کجا هستند. اگر از این پایگاه‌های داده پشتیبان دارید، ساده‌ترین راه‌حل استفاده از آن‌ها در حال حاضر است. با استفاده از کد T-SQL زیر با نام پایگاه داده مناسب و نام فایل جایگزین شده یا دستورdatabase attach در SQL Server Management Studio از منوی database:

USE [master]

CREATE DATABASE [UserDatabaseName] ON (FILENAME = N’C:\sqldata\data.mdf’), (FILENAME = N’D:\sqltlog\tlog.ldf’)FOR ATTACH

روی زبانه پایگاه داده کلیک راست کرده و «Attach…» را انتخاب کنید سپس روی «Add» در دیالوگ باکس Attach Database کلیک کنید. با انتخاب فایل mdf برای هر پایگاه داده، فایل های .ndf و .ldf را پیدا می کند (اگر جابجا نشده باشند).

توجه داشته باشید که ممکن است لازم باشد مالکیت پایگاه‌های داده را تغییر دهید، آنها متعلق به حسابی خواهند بود که آنها را مجدداً پیوست کرده است. ابتدا باید لاگین ها را دوباره ایجاد کنید!

“alter authorization on database::[database_name] to “owner_name

بازیابی سایر اشیاء سیستم

چندین نوع آبجکت دیگر وجود دارد که در پایگاه داده master وجود دارد که هنگام بازسازی یا بازیابی از template و نداشتن نسخه پشتیبان از بین خواهند رفت. لاگینها، end pointها، و linked server و موارد دیگر. اینجاست که بقیه بازیابی یا واقعا خسته کننده یا غیرممکن می شود، اما به جنبه مثبت آن نگاه کنید – شما از شر تمام آن توشه ای که سال ها انباشته شده است خلاص خواهید شد. اگر آبجکتهای مشابه در اینستنسهای دیگر (مثلاً محیط‌های QA یا توسعه شما) وجود دارند، می‌توانید از SSMS برای ایجاد اسکریپت‌هایی برای ویرایش و استقرار در سرور بازیابی شده استفاده کنید. حتی اگر آبجکتها دقیقاً مطابقت نداشته باشند، اسکریپت ها به اندازه کافی نزدیک خواهند بود تا شما را از تایپ های بیهوده نجات دهد.

گنجینه دانش رایان