بکاپ از فایل گروپ

همانطور که می‌دانیم به منظور ارتقاء پرفورمنس دیتابیس های بزرگ، به دیتابیس چندین فایل اضافه کرده و بسته به اینکه تمرکز بر روی چه موضوعی در جهت این ارتقاء است، دیتا را در چندین فایل توزیع میکنیم، بصورت کلی در کاربردهای زیر، این مهم را ذتبال میکنیم

1. جدا کردن جداول مهم از دیگر جداول ها به منظور رسیدن به uniform Extended  و کاهش زمان Logical Read
2. جدا کردن ستون هایی از یک جدول، که دیتا تایپ آنها LOB بوده ، به منظور کاهش زمان Read (چه فیزیکال ، چه لاجیکال) و در ادامه نوشن در اینگونه جداول مخصوصا از طریق آپدیت، جلوگیری از Page Spilt .
3. جدا کردن Index ها از Data و قرار دادن فایل Index ها در دیسک سریع تر، به منجور ارتقاء پرفورمنس در زمان استفاده از ایندکس
4. افراز یا پارتیشن کردن دیتای یک جدول بر اساس یک معیار و پخش اطلاعات در چندین فایل، به منظور کاهش زمان Read در اثر جستجو در فایل های کوچک تر، بجای یک فایل بزرگ

از بین موارد فوق مورد 1 و 4 هدف این مقاله است، و از بین مورد 1 و 4 مورد 4 بیشتر مورد توجه است، بدین ترتیب که تصور کنیم دیتابیسی داریم چند ده ترابایت و همانند همه دیتابیس ها، که پروسه نسخه پشتیبان شدیدا مورد توجه است ، نیازمند بکاپ گیری از آن بصورت مداوم هستیم ، حال اگر در بهترین حالت استراتژی بکاپ چدیده باشیم که هفته ای یکبار فول بکاپ بگیریم،روزی یکبار دیفرنشیال و … باز هم حجم بکاپ ها، زمان بکاپ گیری(الخصوص فول اول هفته) می تواند مشکلاتی برای ما فراهم کند، از طرفی این چنین دیتابیس هایی با این وسعت، عموما دیتای آرشیو شده در خود داشته که یا بوسیله پارتیشین بندی جداول و تفسیم دیتای جداول در چند فایل نگهداری میشوند(بند 4) و یا جداول جدا شده داشته که این جداول در فایل جدا نگهداری میشوند(بند 1) حتی دیده شده با استفاده از Read-Only کردن فایل گروپ های قدیمی، علاوه بر حفظ اینتگریتی، بشکلی امنیت اطلاعات آرشیو شده نیز فراهم میشود.

با توجه به مقدمه اشاره شد، میتوان مفروضات را در دوجمله خلاصه کرد تا به نتیجه گیری مهمی برسیم:

اولا: دیتابس ما بزرگ است و مسئله بکاپ گیری به لحاظ حجم و زمان مورد توجه است

ثانیا:دیتابیس به چند فایل تقسیم شده و لزوما همه فایل در حال تغییر نیستند

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

• نکته: دیتابیسی که چند فایل دارد و داده ها در آن فایل ها توضیع شده، در واقع چند فایل گروپ داشته که داده های در آن پخش است، هر فایل گروپ هم حداقل یک فایل و معمولا همان یک فایل را دارد، پس منظور ما در این مقاله از فایل، فایل گروپ های تک فایل است،گرچه قابل بست به فایل گروپ های چند فایله هم میباشد.

پس استراتژی بکاپ گیری بدین ترتیب خواهد شد:

• یک فول بکاپ از دیتابیس میگیریم، بدون ورود به بحث فایل و فایل گروپ و کنار میگذاریم.
  • این بکاپ بسیار مهم است و
  • بدون آن بازگردانی اطلاعات،در زمان از دست دادن کل دیتابیس، غیرممکن میباشد
  • این بکاپ ربطی به زنجیزه بکاپ ها نداشته(اگر فایل گروپ های دیگر Readonly باشد)
• در ادامه زنجیره بکاپ های Full و Differential را زمان بندی میکنیم
  • اول هفته مطابق قبل full میگیریم
  • هر شب Diff میگیریم مطابق پلنی که داریم
  • تفاوت این Full و Diff ها با آنچه تا اینجا دیدم،بکاپ از File Group هایی خواهد بود که ما میدانیم در حال تغییر هستند و نه از کل دیتبایس!
• یکاپ های Log ما، با توجه به اینکه نسخه پشتیبان از Transaction Log ها هست، کمافسابق خواهد بود و هیچ تغییر ندارد
  • فلسفه Log Backup بکاپ از تغییرات واقع در Transactional Log می باشد ، که بسته به اینکه فایل گروپ هایی که میدانیم چیزی قرار نیست در آنها نوشته شود، Read-only هست یا نه، معنای آن متفاوت میشود، بطوری که بصورت پیش فرض Log Backup میشد تغییرات نسبت به Log قبلی و یا تغییرات به Diff یا Full قبلی، اما حال مسئله این هست با دو تا Full داریم، Full کامل  و Full  از file Group ها در حال تغییر! مشخصا اینگونه استنبات می شود که اگر فایل گروپ های که میدانیم تغییر ندارند، به حالت Read-only تغییر کرده باشند، Log Backup میشود تغییرات نسبت به Full از File Group ها یا همان Partial Full ما (یا Partial Diff)  ولی اگر فایل گروپ هایی که تغییر ندارند، Read-only نکنیم، این Log Backup ها، میشود تغییرات از Full اصلی و این موضوع می تونه تعمق بر انگیز باشد، چرا که قرار بود این Full را گرفته و جایی کنار بگذاریم، حال با این فرضیه کل لاگ بکاپ های نسبت به آن Full بوده و زنجیره هفتگی ساخته شده عملا بی فایده است و کلا بکاپ پارشیال برای رسیدن به بازه زمانی خاص، بی معنی هست، چرا که برای رسیدن به آن نقطه زمانی Full کلی و زنجیره Log ها باید ریستور شود و Partial های میانه راه عملا بی فایده خواهد بود.
  • شاید سوالی مطرح شود، که اگر دیتابیس به لحاظ ریکاوری مدل Simple باشد، حال دیگر لاگ بکاپ نداری که ریستور کنیم! پس لابد این سناریو فقط برای حالت ریکاوری مدل Full هست؟ که در جواب باید گفت، اینگونه رفتار اینترپرایز لاید روی دیتابیس های مهم انجام میشود و در این دیتابیس ها Recovery Model در حالت Full هست، اما در واقع باید گفت ماکروسافت برای حالت Simple نیز راه کار ارائه داده و این راه کار استفاده از واژه Partial جزو آپشن های جلوی With در زمان Restore است، که خواهیم دید.
  • بعد از بکاپ های full  و Diff که از فایل گروپ ها گرفتیم، حتما باید لاگ بکاپ داشته باشیم، چرا که فقط با ریستور Log Backup دیتابیس Recover خواهد شد.(یعنی مثل حالت نرمال نیست که آخرین بکاپ را ریکاور کنیم و یا ریکاوری را مجزا فرمان دهیم، حتما باید آخرین بکاپ در زمان ریستور در این سناریو از نوع Log باشد، که البته دلیل مطقی دارد که به آن اشاره خواهیم کرد)دلیل منطقی این نیاز بدین ترتیب است که در زمان ریستور وقتی ما در حال ریستور یک فایل گروپ هستیم، چه تضمینی وجود دارد که بقیه فایل گروپ ها تغییر نداشته باشند؟ به عنوان مثال ما اطلاعات یک فایل گروپ را ریستور میکنیم، بعد از ریستور یکسری دیتا اضافه میشود یا حذف میشود تا برسیم به نقطه زمانی بکاپ،  که ممکن است ارتباطاتی با جداول دیگر از طریق کلید پرایمری و خارجی داشته بشند که این جداول دیگر در همین فایل گروپ نباشند، پس با ریستور یک فایل گروپ احتمال ناسازگاری هست، لذا ما را مجبور میکنه آخرین بکاپی که Recover می کنیم لاگ بکاپ باشه که داخلش تغییرات احتمالی بقیه فایل گروپ ها نیز قرار داشته باشد، و در نکته قبل دیدم، Log Backup ها در این حالت و برای مدیریت تغییرات دیگر فایل گروپ ها، نسبت به full کلی بود، یعنی مشخصا MSSQL داره به ما میگه داستان پارشیال فقط برای حالتی هست که ما فایل گروپ ReadOnly داریم !!!!!!

در ادامه چند تست خواهیم کرد، تا ببینیم نکات که تصور می کنیم چقدر درست است:

فرض کنید داریم، به جز پرایمری یک فایل گروپ دیگر هم داریم، و دو جدول داریم یکی در پرایمیری و دیگر در فایل گروپ فوق، و همه فایل گروپی Read-only نیست:

use master

drop database if exists test

create database Test

go

alter database test add filegroup   rw

go

alter database test add file(name = ‘rw’ , filename = ‘C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\rw.ndf’) TO FILEGROUP rw

go

use test

go

go

create table tb_rw(id int ) on rw

go

insert into tb_rw values (1),(2),(3)

go

create table tb_(id int ) on [primary]

go

insert into tb_ values (4),(5),(6)

go

select * from tb_

select * from tb_rw

go

حال شروع به تست حالت های متفاوت میکنیم:

1. در این حالت اقدام به ریستور یک فایل از بین بکاپ ها میکنیم:

backup database test to disk = N’E:\Class.bak’ with format , init

backup database test filegroup = ‘Rw’ to disk = N’E:\Class_r.bak’  with format , init

delete from tb_rw

use master

restore database test filegroup = ‘rw’ from disk = N’E:\Class_r.bak’ with replace ,   recovery –The roll forward start point is now at log sequence number (LSN) 3800000003250000

use test

select * from tb_rw

–The query processor is unable to produce a plan for the table or view ‘tb_rw’ because the table resides in a filegroup that is not online.

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

• این بار برای حل ابهام قبل، سنارویو را مجدد پیش برده ،ولی همه فایل ها را بر میگردانیم به قرار زیر:

backup database test to disk = N’E:\Class.bak’ with format , init

backup database test filegroup = ‘Rw’ to disk = N’E:\Class_r.bak’  with format , init

delete from tb_rw

use master

restore database test  from disk = N’E:\Class.bak’ with replace  , norecovery

restore database test filegroup = ‘rw’ from disk = N’E:\Class_r.bak’ with replace ,   recovery –The roll forward start point is now at log sequence number (LSN) 38000000029200001

restore database test with recovery

–The roll forward start point is now at log sequence number (LSN) 38000000035500001. Additional roll forward past LSN 38000000035500001 is required to complete the restore sequence.

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

• یک شک دیگه هم هست که شاید باید تک تک فایل گروپ ها را جداگانه برگردوند، گرچه این شک خیلی ضعیف هست چون فول کلی همه فایل گروپ ها را آورده ولی برای تکمیل سند آن حالت را هم تست خواهیم کرد:

backup database test to disk = N’E:\Class.bak’ with  format , init

backup database test filegroup = ‘Rw’ to disk = N’E:\Class_r.bak’  with format , init

delete from tb_rw

use master

restore database test  filegroup = ‘Primary’ from disk = N’E:\Class.bak’ with partial , replace  , norecovery

restore database test filegroup = ‘rw’ from disk = N’E:\Class_r.bak’ with replace ,   recovery –The roll forward start point is now at log sequence number (LSN) 38000000029200001

restore database test with recovery –The roll forward start point is now at log sequence number (LSN) 38000000029300001.

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

backup database test to disk = N’E:\Class.bak’ with format , init

insert into tb_rw values (40)

backup log test   to disk = N’E:\Class_L.bak’  with format , init

delete from tb_rw where id = 1

backup database test filegroup = ‘Rw’ to disk = N’E:\Class_r.bak’  with format , init

delete from tb_rw where id = 2

backup log test   to disk = N’E:\Class_L2.bak’  with format , init

go

use test

select * from tb_rw

در این حالت ما فقط رکورد 3 و 40 را در جدول تستی داریم، و حال می خواهیم اقدام به ریستور کنیم ، مشخصا باید از ریستور full شروع کنیم، طبق تست های  قبل فول پارشیال و فول کامل نباید تفاوتی داشته باشد، ولی ما روزه شک دار نمیگیرم، با فول کامل شروع میکنیم تا برسیم به هدف اصلی که این لاگ ها نسبت به فول اصلی هست یا پارشیال، اگر بخواهیم با پراشیال شروع کنیم و بعد لاگ 2 را ریستور کنیم و به خطا بخوریم، نخواهیم فهمید موضوع چی بوده و شک روی نیاز به فول اصلی خواهد رفت! پس با این مقدمه فول کامل ریستور میکنیم، بعدش فول پارشیال و حالا L2 را ریستور خواهیم کرد، اگر ریستور شود، یعنی لاگ حاوی تغییرات نسبت به پارشیال خواهد بود، اگر ریستور نشود آنگاه باید هر دو لاگ ها را ریستور کرد و عملا پارشیال نقشی نخواهد داشت و لاگ ها نسبت به فول اصلی خواهد بود پس:

use master

restore database test  from disk = N’E:\Class.bak’ with replace  , norecovery

restore database test filegroup = ‘rw’ from disk = N’E:\Class_r.bak’ with replace ,   recovery

restore database test  from disk = N’E:\Class_L2.bak’  with recovery

–The log in this backup set begins at LSN 38000000038900001, which is too recent to apply to the database. An earlier log backup that includes LSN 38000000036900001 can be restored.

restore database test  from disk = N’E:\Class_L2.bak’  with recovery–The log in this backup set begins at LSN 38000000031100001, which is too recent to apply to the database.

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

restore database test  from disk = N’E:\Class.bak’ with replace  , norecovery

restore database test  from disk = N’E:\Class_L.bak’  with norecovery

restore database test  from disk = N’E:\Class_L2.bak’  with recovery

نتیجه: در حالی فایل گروپ Read-only نداریم، عملا Log Backup در سناریوی ما نقشی ندارد، و ما فقط Full و diff پارشیال داریم، و Log ها نسبت به فول کلی هست، و با توجه به اینکه diff و Full هم هیچوقت بدون لاگ ریستور نمیشود، عملا پارشیال به هیچ دردی نخواهد خورد! شاید فقط یک سناریو خیلی محدود بشه روی این بکاپ حساب کرد، که در حالتی باشد، فایل را از دست بدیم و فقط همان فایل را بشکل زیر و با استفاده از Tail ریکاور کنیم بصورت زیر

backup database test to disk = N’E:\Class.bak’ with  format , init

backup database test filegroup = ‘Rw’ to disk = N’E:\Class_r.bak’  with format , init

در این مرحله SQL را استاپ کرده و فایل مربوط به فایل گروپ RW را پاک میکنیم، وقتی دیتابیس بالا می آید در حالت ریکاوری پندینگ خواهد بود

 پس با تیل شروع میکنیم، در حالی که میدانیم تیل تغییرات نسبت به فول اولیه است ولی چون یک فایل را از دست دادیم،همان تک فایل را ریستور میکنیم، تغییرات این فایل و دیگر فایل ها در تیل خواهد بود (اگر لاگ دیگری هم داریم ، تغییرات در دنباله لاگ ها و این تیل است)

use master

backup log test to disk = N’E:\Class_Tail.bak’ with format,init ,  NO_TRUNCATE

restore database test filegroup = ‘rw’ from disk = N’E:\Class_r.bak’ with replace ,   norecovery

restore database test from disk = N’E:\Class_Tail.bak’ with recovery

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

در ادامه چهار حالت تست شده، این بار با استفاده از فایل گروپ Read-only پروسه را دنبال میکنیم پس سناریو مشابه آماده میکنیم، سناریو می تواند خیلی ساده باشد بدین ترتیب که یک فایل گروپ read-only و یک فایل گروپ read-Write داشته باشیم، ولی در محیط عملی ما یک فایل گروپ PRIMARY هم داریم، که پیش فرض بوده و یکسری اطلاعات سیستمی در آن قرار میگیرد، ما سعی میکنیم سناریو را طوری طراحی کینم، که شامل این فایل گروپ هم شود، یعنی ما یک دیتابیس داریم، به جز فایل گروپ PRIMARY ، دو فایل گروپ دیگر دارد، یکی فایل گروپ جاری است که مثلا اطلاعات جاری در آن قرار میگیرد و یک فایل گروپ آرشیو که Read-only هست و نهایت خواهیم داشت:

use master

drop database if exists test

create database Test

go

alter database test add filegroup   Arvhive

go

alter database test add file(name = ‘aa’ , filename = ‘C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\Archive.ndf’) TO FILEGROUP Arvhive

go

alter database test add filegroup   rw

go

alter database test add file(name = ‘rw’ , filename = ‘C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\rw.ndf’) TO FILEGROUP rw

go

use test

go

create table tb_Archive(id int ) on Arvhive

go

insert into tb_Archive values (1),(2),(3)

go

create table tb_rw(id int ) on rw

go

insert into tb_rw values (1),(2),(3)

go

alter database test MODIFY FILEGROUP Arvhive READ_ONLY;

go

create table tb_(id int ) on [primary]

go

insert into tb_ values (4),(5),(6)

go

select * from tb_Archive

select * from tb_

select * from tb_rw

go

پس ما سه جدول داریم tb_Archive در آرشیو که Read-Only هست ، tb_ در پرایمری و tb_rw در RW و شروع به تست خواهیم کرد:

1. در این حالت فرض میکنیم یک تغییر اشتباه در جدولی که در فایل گروپ Read-Write هست رخ داده است، پس می خواهیم فقط همان تغییر را  ریستور کنیم، در حالی که کل فایل ها را ریستور نمیکنیم، فقط همان فایل گروپ، بدون استفاده از Log Backup ، پس خواهیم داشت:

backup database test to disk = N’E:\Class.bak’ with format , init

backup database test filegroup = ‘Rw’ to disk = N’E:\Class_r.bak’  with format , init

delete from tb_rw where id % 2 = 0

use master

restore database test filegroup = ‘rw’ from disk = N’E:\Class_r.bak’ with replace ,   recovery  –The roll forward start point is now at log sequence number (LSN) 38000000048100001.

use test

select * from tb_rw

نتیجه اینکه یک تک فایل را نمیشه ریستور کرد، گرچه بعد از این اتفاق اشتباه آن فایل گروپ از دسترس خارج میشود، ولی دیتای واقع در بقیه فایل گروپ ها قابل دسترس خواهد بود:

use test

select * from tb_

2.این بار مجدد همان سناریو قبلی را پیش میبریم، ولی موقع ریستور همه فایل گروپ های Read-Write را به هر روش ممکن باز میگردانیم و اقدام به بررسی شرایط خواهیم کرد، پس ابتدا کل دیتابیس را ریستور میکنم، که پرایمری هم عضوی از این کل هست(حتی Read-onlyها) سپس فایل گروپ هدف که تغییر کرده را ریستور خواهیم کرد.

backup database test to disk = N’E:\Class.bak’ with format , init

backup database test filegroup = ‘Rw’ to disk = N’E:\Class_r.bak’  with format , init

delete from tb_rw where id % 2 = 0

use master

restore database test filegroup = ‘rw’ from disk = N’E:\Class_r.bak’ with replace ,   recovery  –The roll forward start point is now at log sequence number (LSN) 38000000048100001.

use test

select * from tb_rw

نتیجه اینکه ما انتظار داشتیم از طریق فول همه فایل گروپ Read-Write برگشته و آخرین فایل گروپ هدف ما نیز اور رایت شود و دیتابیس ریکاور شود که نشد! شک هست روی اینکه شاید باید تک تک فایل گروپ های Read-Write را ریستور کرد، که بنظر منظقی تر از ریستور کل دیتابیس باشد،حداقل از دید زمان ریستو و دیزستر ریکاور.

• این بار تک تک فایل گروپ ها Read-Write ریستور کرده و از فول بصورت مستقیم استفاده نمیکنیم و از توی فول در فایل گروپ های Read-Write را میکشیم بیرون، حالا با هر روشی مثلا از توی Full کلی میکشیم بیرون:

backup database test to disk = N’E:\Class.bak’ with format , init

backup database test  filegroup = ‘Rw’ to disk = N’E:\Class_rw.bak’  with format , init

delete from tb_rw where id % 2 = 0

use master

restore database test  filegroup = ‘PRIMARY’ from disk = N’E:\Class.bak’ with replace ,   norecovery ,partial

restore database test  filegroup = ‘Rw’ from disk = N’E:\Class_rw.bak’  with replace ,    recovery –The database cannot be recovered because the log was not restored.The roll forward start point is now at log sequence number (LSN) 38000000071000001.

نتیجه اینکه فرقی نکرد فول را برگردونیم یا از توی فول فایل گروپ Read-Write را بکشیم بیرون، البته شاید بشه سوئیچ Read-Write هم تست کرد..

• در این روش همان سناریو بالا را تکرار میکنیم ولی اینبار سوئیچ Read-Write هم تست میکنیم، البته بعید است نتیجه فرقی کند ولی تست میکنیم:

backup database test to disk = N’E:\Class.bak’ with format , init

backup database test  filegroup = ‘Rw’ to disk = N’E:\Class_rw.bak’  with format , init

delete from tb_rw where id % 2 = 0

use master

restore database test  READ_WRITE_FILEGROUPS from disk = N’E:\Class.bak’ with replace ,   norecovery ,partial

restore database test  filegroup = ‘Rw’ from disk = N’E:\Class_rw.bak’  with replace ,    recovery –The database cannot be recovered because the log was not restored.The roll forward start point is now at log sequence number (LSN) 38000000071000001.

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

• در این حالت در ادامه روش 4 و 3 Read-Write ، اینبار تک تک بکاپ گرفته و تک تک فایل گروپ های فوق را ریستور خواهیم کرد

backup database test  filegroup = ‘PRIMARY’ to disk = N’E:\Class_P.bak’ with format , init

backup database test  filegroup = ‘Rw’ to disk = N’E:\Class_rw.bak’  with format , init

delete from tb_rw where id % 2 = 0

use master

restore database test  filegroup = ‘PRIMARY’ from disk = N’E:\Class_P.bak’ with replace , norecovery 

restore database test  filegroup = ‘Rw’ from disk = N’E:\Class_rw.bak’  with replace ,    recovery –The database cannot be recovered because the log was not restored.The roll forward start point is now at log sequence number (LSN) 38000000071000001.

نتیجه اینکه هر مدلی تلاش کردیم فایل گروپ های Read-Write را برگردانیم، امکان پذیر نبود، بشکلی دچار یاس فلسفی شدم! اما یک مثالی در اینترنت دیدم یک سری به آن زدم و مجدد رفتم حالت 5 را مطالعه کردم، لذا به همان ترتیب پیش خواهم رفت که خواننده متوجه شود از کجا سناریو در آخر کشف شد!

در این مثال که هدف بر گرداندن کل دیتابیس بوده و نه لزوما یک فایل گروپ خاص، نکاتی نهفته است،اول از همه اینکه ما تا اینجا نتوانستیم ریستور کنیم ولی این مثال با ریستور ختم شد، و البته مکانیستم کار بدین ترتیب است که ابتدا فایل گروپ های Write  ریستور شده در حالت recovery و بعد فایل گروپ های Read ریستور شده!

backup database test to disk = N’E:\Class.bak’ with format , init

backup database test filegroup = ‘Arvhive’ to disk = N’E:\Class_a.bak’  with format , init

delete from tb_rw where id % 2 = 0

use master

restore database test READ_WRITE_FILEGROUPS  from disk = N’E:\Class.bak’ with replace ,    recovery ,partial

restore database test filegroup = ‘Arvhive’ from disk = N’E:\Class_A.bak’ with replace ,   recovery

use test

select * from tb_

go

نکات این مثال:

• فایل گروپ های Read در هر لحظه ریستور میشوند حتی اگر دیتابیس در حالت Restoring نباشد.
• فایل گروپ Write  را میشه بعد ریستور Recover کرد، چون فایل گرپ Read تغییری نداشته که بخواهد بعد آن ریستور بشه و داده را ناسازگار کند.

خوب حالا بر میگردیم به حالت 5  (و البته قابل تعمیم به حالات 1 تا 5) ، فرض کنید در جایی که در شکل زیر مشخص شده داده ای تغییر کند:

خوب حال زمان ریستور، چه تضمینی وجود دارد بین لحظه 1 و 3 تغییر در فایل گروپ اول رخ نداده باشد؟ جواب سوال مشخص است، هیچ تضمینی نیست و باید این دو بکاپ از فایل گروپ ها هم زمان رخ داده یا بهتر است بگوییم در لحظه بکاپ باید از همه فایل گروپ های Read-Write بکاپ بگیریم و این مسئله موجب میشود به نتیجه برسیم:

backup database test  filegroup = ‘Rw’,filegroup = ‘PRIMARY’ to disk = N’E:\Class_MX.bak’  with format , init

delete from tb_rw where id % 2 = 0

use master

restore database test  filegroup = ‘PRIMARY’,filegroup = ‘Rw’  from disk = N’E:\Class_MX.bak’ with replace ,   recovery 

نتیجه اینکه ما باید از همه فایل گروپ های Read-Write همزمان بکاپ گرفته و موقع ریستور بصورت تک تک یا همزمان ریستور کنیم، بدون نیاز به فایل گروپ های Read ، پس میتوان بصورت زیر نیز اقدام کرد:

use test

backup database test  filegroup = ‘Rw’,filegroup = ‘PRIMARY’ to disk = N’E:\Class_MX.bak’  with format , init

delete from tb_rw where id % 2 = 0

use master

restore database test  filegroup = ‘PRIMARY’   from disk = N’E:\Class_MX.bak’ with replace ,   norecovery   , partial

restore database test   filegroup = ‘Rw’  from disk = N’E:\Class_MX.bak’ with replace ,   recovery 

فنی ترین حالت استفاده از سوئیچ زیر است که که شاید اصلا MSSQL این سوئیج را برای این موضوع ارائه داده است:

use test

backup database test  READ_WRITE_FILEGROUPS to disk = N’E:\Class_MX.bak’  with format , init

delete from tb_rw where id % 2 = 0

use master

restore database test  READ_WRITE_FILEGROUPS   from disk = N’E:\Class_MX.bak’ with replace , recovery

پس میشه به نتیحه گیری کلی رسید که، بکاپ از فایل گروپ های Read-Write باید همزمان باشد

حال برمیگردیم به حالتی که فایل گروپ های Read-Only نداشتیم، و دوباره دوره میکنیم با نتیجه بدست آمده، در نتیجه بدست آمده گفتیم باید از تمام فایل گروپ های Read-Write همزمان تهیه بکاپ پارشیال شود، خوب اگر دیتابیس Read-only فایل گروپ نداشته باشد، پس ما باید در لحظه بکاپ گیری از همه فایل گروپ های بکاپ بگیریم که خوب با یک Full Backup معمولی چه فرقی دارد!

از طرفی یادآوری میکنم نتیجه گیری کرده بودیم که Log ها در Transaction Log مربوط به تغییرات است و بر میگرده به فایل گروپ های Read-Write و … نهایت مجدد یادآور میشویم، در سناریویی که فایل گروپ Read-only داریم لاگ ها مربوط به فایل گروپ های Read-Write بوده ، پس Log Backup ها نسبت به پارشیال بکاپ ها (دیفرنشیال یا فول) میباشد.

همچنین ریکاوری مدل دیتابیس نیز دیگر مهم نیست! و این سناریو با این توضیحات برای Recoverymodel=Simple نیز قابل پیاده سازی است.

و در نهایت با خیال راحت بکاپ پلن ما خواهشد شد: