SQL Server მონაცემთა ბაზა აღდგენის რეჟიმშია? მიიღეთ 10 დადასტურებული გამოსავალი ახლავე! ეტაპობრივი გადაწყვეტილებები მარტივი გამოსწორებიდან დაწყებული გაფართოებული შეკეთებით დამთავრებული.
1. გაგება SQL Server მონაცემთა ბაზის აღდგენის რეჟიმი
1.1 რას ნიშნავს აღდგენის რეჟიმი? SQL Server
როდესაც SQL Server მონაცემთა ბაზა აჩვენებს სტატუსს „აღდგენის პროცესში“, რაც ნიშნავს, რომ SQL Server მონაცემთა ბაზის თანმიმდევრულობის უზრუნველსაყოფად, ახორციელებს ავარიის ან ტრანზაქციების აღდგენას. ეს ავტომატური პროცესი ინარჩუნებს მონაცემთა მთლიანობას ჩადენილი ტრანზაქციების ხელახლა დაკვრით და დაუსრულებელი ტრანზაქციების გაუქმებით.
აღდგენის რეჟიმი, როგორც წესი, ჩნდება მოულოდნელი გამორთვის, ელექტროენერგიის გათიშვის ან მონაცემთა ბაზის აღდგენის შემდეგ. მიუხედავად იმისა, რომ ეს ნორმალური დამცავი მექანიზმია, პრობლემები წარმოიქმნება, როდესაც SQL Server აღდგენის პროგრამულ უზრუნველყოფაში მონაცემთა ბაზას უჩვეულოდ დიდი დრო სჭირდება ან როგორც ჩანს, ის ჩიხში შედის.
1.2 მონაცემთა ბაზის აღდგენის სამი ფაზა
SQL Server აღდგენა სამ განსხვავებულ ეტაპს მოიცავს:
1.2.1 ანალიზის ფაზა
SQL Server სკანირებს ტრანზაქციების ჟურნალს ბოლო საკონტროლო წერტილიდან, რათა გამოავლინოს „ბინძური გვერდები“ და აქტიური ტრანზაქციები. ის ქმნის „ბინძური გვერდების ცხრილს“ (DPT) და „აქტიური ტრანზაქციების ცხრილს“ (ATT) აღდგენის საჭიროებების თვალყურის დევნებისთვის.
1.2.2 გამეორების ფაზა (წინ გადაგორება)
სისტემა ხელახლა ამუშავებს ყველა ჩადენილ ტრანზაქციას, რომელიც დისკზე არ ჩაიწერა ავარიამდე. ეს უზრუნველყოფს, რომ ყველა ჩადენილი ცვლილება სწორად იქნას გამოყენებული მონაცემთა ბაზის ფაილებში.
1.2.3 გაუქმების ფაზა (უკან დაბრუნება)
მონაცემთა ბაზის თანმიმდევრულობის შესანარჩუნებლად, ნებისმიერი შეუსრულებელი ტრანზაქცია უქმდება. დასრულების შემდეგ, მონაცემთა ბაზა ნორმალური ოპერაციებისთვის ხელმისაწვდომი ხდება.
1.3 გავრცელებული სიმპტომები და შეცდომის შეტყობინებები
როდესაც თქვენი SQL Server db აღდგენის რეჟიმშია, როგორც წესი, ნახავთ:
- მონაცემთა ბაზის სახელი, რომელიც აჩვენებს „(აღდგენის პროცესში)“-ს SQL Server მენეჯმენტის სტუდია
- შესვლის შეცდომები „მონაცემთა ბაზის აღდგენა მიმდინარეობს“ შეტყობინებებით
- შეცდომების ჟურნალის ჩანაწერები, რომლებიც აღდგენის პროგრესის პროცენტულ მაჩვენებლებს აჩვენებს
- მონაცემთა ბაზის მდგომარეობა მოთხოვნის შემთხვევაში აჩვენებს „აღდგენის პროცესშია“-ს
2. ძირითადი მიზეზები SQL Server აღდგენის რეჟიმის პრობლემები
2.1 არასრული აღდგენის ოპერაციები
ყველაზე გავრცელებული მიზეზი ხდება მრავალი სარეზერვო ფაილიდან აღდგენისას, გამოყენებით ნოროკოვერი ვარიანტი საბოლოოს გარეშე აღდგენით ბრძანება. ეს მონაცემთა ბაზას დამატებითი აღდგენის ოპერაციების მოლოდინში ტოვებს.
2.2 ტრანზაქციების ჟურნალის პრობლემები
დიდი რაოდენობით ტრანზაქციების ჟურნალის ფაილები ან ვირტუალური ჟურნალის ფაილების (VLF) ჭარბი რაოდენობა მნიშვნელოვნად ანელებს აღდგენას. როდესაც MS SQL აღდგენის პროცესშია ათასობით VLF-ით, პროცესის დასრულებას შეიძლება საათები ან დღეები დასჭირდეს.
2.3 სისტემასთან დაკავშირებული საკითხები
აპარატურის გაუმართაობამ, ელექტროენერგიის გათიშვამ ან დისკზე არასაკმარისმა სივრცემ შეიძლება შეაფერხოს მონაცემთა ბაზის ნორმალური ოპერაციები, რაც გადატვირთვის დროს ხანგრძლივი აღდგენის პროცესების გამოწვევას გამოიწვევს.
2.4 მონაცემთა ბაზის კორუფცია
დაზიანებული მონაცემთა ბაზის ფაილები ხელს უშლის აღდგენის წარმატებით დასრულებას, რის გამოც მონაცემთა ბაზა განუსაზღვრელი ვადით რჩება აღდგენის რეჟიმში.
3. დიაგნოსტიკური ნაბიჯები შეკეთებამდე
3.1 შემოწმება SQL Server შეცდომების ჟურნალი
გამოსწორების მცდელობამდე, შეამოწმეთ SQL Server აღდგენის პროგრესის შეტყობინებების შეცდომების ჟურნალი. მოძებნეთ ჩანაწერები, რომლებიც აჩვენებს დასრულების პროცენტულ მაჩვენებლებს და დარჩენილ სავარაუდო დროს.
- ღიაა SQL Server მენეჯმენტის სტუდია
- ნავიგაცია მართვის -> SQL Server ლოგები
- გადახედეთ თქვენი მონაცემთა ბაზის სახელის ბოლო ჩანაწერებს
- მოძებნეთ აღდგენის ფაზის ინდიკატორები (ფაზა 1, 2 ან 3-დან 3)
3.2 აღდგენის პროგრესის მონიტორინგი
აქტიური აღდგენის ოპერაციების თვალყურის დევნებისთვის გამოიყენეთ დინამიური მართვის ხედები:
SELECT session_id, command, blocking_session_id, wait_type, wait_time, wait_resource FROM sys.dm_exec_requests WHERE command = 'DB STARTUP';
3.3 მონაცემთა ბაზის მდგომარეობის შემოწმება
აღდგენის სტატუსის გასაგებად, გადაამოწმეთ მონაცემთა ბაზის მიმდინარე მდგომარეობა:
SELECT name, state_desc FROM sys.databases WHERE name = 'YourDatabaseName';
4. გამოსწორება #1: დაელოდეთ ბუნებრივი აღდგენის დასრულებას
ზოგჯერ მოთმინება საუკეთესო გამოსავალია, როდესაც... SQL Server მონაცემთა ბაზა აღდგენის პროცესშია. ეს მიდგომა მუშაობს მაშინ, როდესაც აღდგენა ნორმალურად მიმდინარეობს, მაგრამ მოსალოდნელზე მეტხანს გრძელდება.
4.1 როდის უნდა იყოთ მოთმინება
ბუნებრივი დასრულების დაშვება, როდესაც:
- შეცდომების ჟურნალები აჩვენებს სტაბილურ პროგრესს დროის შეფასებების შემცირებით
- კორუფციის შეცდომები არ არის დაფიქსირებული
- მონაცემთა ბაზაში ბოლო დროს დიდი ტრანზაქციები დაფიქსირდა
- VLF-ის რაოდენობა მართვადია (1,000-ზე ნაკლები)
4.2 აღდგენის პროგრესის მონიტორინგი
შეცდომების ჟურნალებში აღდგენის დროის შეფასებები ხშირად არაზუსტია. ყურადღება გაამახვილეთ პროგრესის პროცენტებზე და არა დარჩენილ დროზე. დიდი მონაცემთა ბაზები, რომლებსაც აქვთ ვრცელი ტრანზაქციების ისტორია, სრული აღდგენისთვის შეიძლება რამდენიმე საათი დასჭირდეს.
5. გამოსწორება #2: გამოიყენეთ მონაცემთა ბაზის აღდგენა აღდგენის ფუნქციით
ეს შესწორება აგვარებს არასრული აღდგენის ოპერაციებს, სადაც საბოლოო აღდგენის ნაბიჯი გამოტოვებული იყო. გამოიყენეთ ეს, როდესაც თქვენი SQL Server აღდგენაში არსებული db NORECOVERY-ის გამოყენებით აღდგენის პროცესის შედეგად შეიქმნა.
5.1 ბრძანების გაგება
ის მონაცემთა ბაზის აღდგენა აღდგენის ფუნქციით ბრძანება ასრულებს აღდგენის პროცესს დაუსრულებელი ტრანზაქციების გაუქმებით და მონაცემთა ბაზის ონლაინ რეჟიმში გადაყვანით.
5.2 განხორციელების ეტაპები
- ღიაა SQL Server მენეჯმენტის სტუდია
- დაუკავშირდით თქვენს SQL Server მაგალითად
- დაწკაპეთ ახალი > მოთხოვნა მიმდინარე კავშირით
- შეასრულე:
RESTORE DATABASE [YourDatabaseName] WITH RECOVERY; - დაელოდეთ დასრულების დადასტურებას
გაფრთხილება: ეს ბრძანება გამოიყენეთ მხოლოდ იმ შემთხვევაში, თუ დარწმუნებული ხართ, რომ დამატებითი აღდგენის ოპერაციები არ არის მოსალოდნელი.
6. გამოსწორება #3: ტრანზაქციების ჟურნალის პრობლემების მოგვარება
ტრანზაქციების ჟურნალის პრობლემები აღდგენის დროის გახანგრძლივების მთავარი მიზეზია. ეს შესწორება აგვარებს სავსე ჟურნალების, ჭარბ VLF-ების და ჟურნალის სივრცის პრობლემებს, რომლებიც ხელს უშლის SQL Server გამოჯანმრთელებაში.
6.1 ტრანზაქციების ჟურნალების სარეზერვო ასლის შექმნა
გაათავისუფლეთ ჟურნალის სივრცე ტრანზაქციების ჟურნალის სარეზერვო ასლების შექმნით:
- ღიაა SQL Server მენეჯმენტის სტუდია
- დააწკაპუნეთ მარჯვენა ღილაკით თქვენს მონაცემთა ბაზაზე -> ამოცანები -> უკან მდე
- შეცვლა სარეზერვო ტიპი to ტრანზაქციების ჟურნალი
- მიუთითეთ სარეზერვო ასლის დანიშნულების ადგილი
- დაწკაპეთ OK შეასრულოს
6.2 ვირტუალური ჟურნალის ფაილების (VLF) მართვა
შეამოწმეთ VLF რაოდენობა შემდეგნაირად:
DBCC LOGINFO('YourDatabaseName');
თუ 1,000-ზე მეტი VLF გაქვთ, შეამცირეთ ისინი:
- ტრანზაქციების ჟურნალის სარეზერვო ასლის შექმნა
- ჟურნალის ფაილის შემცირება:
DBCC SHRINKFILE(LogFileName, TRUNCATEONLY); - ჟურნალის ფაილის დიდ ნაწილებად (1 GB ან მეტი) გაზრდა
6.3 ჟურნალის ფაილების უსაფრთხოდ შემცირება
ჟურნალების შემცირება მხოლოდ ტექნიკური მომსახურების ფანჯრების დროს, როდესაც აქტიური ტრანზაქციები არ მიმდინარეობს. შემცირების ოპერაციების დაწყებამდე ყოველთვის შექმენით მონაცემთა ბაზის სარეზერვო ასლი.
7. გამოსწორება #4: გაუშვით DBCC CHECKDB და შეაკეთეთ
მონაცემთა ბაზის დაზიანებამ შეიძლება ხელი შეუშალოს აღდგენის წარმატებით დასრულებას. DBCC CHECKDB არის ჩაშენებული ბრძანება, რომელსაც შეუძლია იმ მცირე კორუფციული პრობლემების იდენტიფიცირება და გამოსწორება, რომლებიც MS SQL-ს აღდგენის რეჟიმში ტოვებს.
7.1 მონაცემთა ბაზის დაზიანების შემოწმება
მონაცემთა ბაზის მთლიანობის დასადასტურებლად დაიწყეთ სტანდარტული მიდგომით. ჯერ პირდაპირ სცადეთ DBCC CHECKDB:
- შეასრულე:
DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS; - შედეგების გადახედვა თანმიმდევრულობის შეცდომებზე
- ნებისმიერი კორუფციული შეტყობინების დოკუმენტირება
თუ DBCC CHECKDB ვერ ხერხდება ისეთი შეცდომებით, როგორიცაა „მონაცემთა ბაზა აღდგენილია. აღდგენის დასრულებამდე ველოდებით“, ეს ნიშნავს, რომ მონაცემთა ბაზა აქტიურად აღდგენის რეჟიმშია და წვდომას ბლოკავს. ამ შემთხვევაში, გადადით 7.3 პუნქტზე საგანგებო რეჟიმის გამოსაყენებლად.
7.2 ხელმისაწვდომი მონაცემთა ბაზების აღდგენის ვარიანტები
თუ DBCC CHECKDB წარმატებით გაიქცა და აღმოაჩინა დაზიანება, გამოიყენეთ შემდეგი გამოსწორების ნაბიჯები:
- მონაცემთა ბაზის ერთჯერადი რეჟიმის დაყენება:
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER; - უსაფრთხო შეკეთების მცდელობა:
DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD); - წარუმატებლობის შემთხვევაში, გამოიყენეთ:
DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS); - მრავალმომხმარებლიან რეჟიმში დაბრუნება:
ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
7.3 საგანგებო რეჟიმის გამოყენება, როდესაც მონაცემთა ბაზა მიუწვდომელია
საგანგებო რეჟიმი საჭიროა მხოლოდ მაშინ, როდესაც მონაცემთა ბაზა აღდგენის პროცესშია გაჭედილი და უარყოფს DBCC CHECKDB-ის ნორმალურ მცდელობებს. ის მონაცემთა ბაზას მხოლოდ წაკითხვად მონიშნავს და ჟურნალირებას თიშავს. გამოიყენეთ ეს მიდგომა, როდესაც სტანდარტული წვდომა ვერ ხერხდება:
- საგანგებო რეჟიმის დაყენება:
ALTER DATABASE [YourDatabaseName] SET EMERGENCY; - ერთჯერადი მომხმარებლის დაყენება:
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER; - მთლიანობის შემოწმების გაშვება:
DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS; - თუ დაზიანება აღმოჩენილია, პირველ რიგში უსაფრთხო შეკეთება განახორციელეთ:
DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD); - წარუმატებლობის შემთხვევაში, გამოიყენეთ მონაცემების დაკარგვით შეკეთება:
DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS); - მრავალმომხმარებლიანი რეჟიმის დაყენება:
ALTER DATABASE [YourDatabaseName] SET MULTI_USER; - ონლაინ დაყენება:
ALTER DATABASE [YourDatabaseName] SET ONLINE;
მნიშვნელოვანია: საგანგებო რეჟიმი გვერდს უვლის ნორმალურ აღდგენის პროცესებს და უნდა იქნას გამოყენებული მხოლოდ მაშინ, როდესაც მონაცემთა ბაზა სრულიად მიუწვდომელია. საგანგებო რეჟიმში გადასვლამდე ყოველთვის სცადეთ სტანდარტული DBCC CHECKDB მიდგომა.
შეგიძლიათ უფრო ყოვლისმომცველი სახელმძღვანელო, თუ როგორ გამოიყენოთ DBCC CHECKDB.
8. შესწორება #5: აღდგენა სარეზერვო ასლიდან
როდესაც სხვა მეთოდები ვერ ხერხდება ან მონაცემთა მთლიანობა საეჭვოა, სუფთა სარეზერვო ასლიდან აღდგენა ხშირად პრობლემის გადაჭრის ყველაზე საიმედო გადაწყვეტაა. SQL Server მონაცემთა ბაზა აღდგენის საკითხებში.
8.1 როდის უნდა აირჩიოთ სარეზერვო ასლის აღდგენა
სარეზერვო ასლის აღდგენა განიხილეთ, როდესაც:
- აღდგენა 24 საათზე მეტია მიმდინარეობს პროგრესის გარეშე
- კორუფციის შეცდომები ხელს უშლის წარმატებულ შეკეთებას
- თქვენ გაქვთ ბოლოდროინდელი, დადასტურებული სარეზერვო ასლები
- ბოლო სარეზერვო ასლის შემდეგ მონაცემთა დაკარგვა მისაღებია
8.2 ეტაპობრივი აღდგენის პროცესი
- ღიაა SQL Server მენეჯმენტის სტუდია
- მარჯვენა ღილაკის მონაცემთა ბაზა -> მონაცემთა ბაზის აღდგენა
- აირჩიეთ მოწყობილობა წყაროს ქვეშ
- დაწკაპეთ დამატება და გადადით თქვენს სარეზერვო ფაილზე
- აირჩიეთ სარეზერვო ასლი და დააჭირეთ OK
- არჩევა არსებული მონაცემთა ბაზის გადაწერა საჭიროების შემთხვევაში
- დაწკაპეთ OK აღდგენის დასაწყებად
8.3 დროის მომენტში აღდგენა
მონაცემთა მინიმალური დანაკარგისთვის, კონკრეტულ დროს აღსადგენად გამოიყენეთ ტრანზაქციების ჟურნალის სარეზერვო ასლები. დარწმუნდით, რომ გაქვთ ჟურნალის სარეზერვო ასლების უწყვეტი ჯაჭვი სრული სარეზერვო ასლიდან სასურველ აღდგენის წერტილამდე.
8.4 მითითება
დამატებითი ინფორმაციის მიღება შეგიძლიათ ჩვენი ყოვლისმომცველი სახელმძღვანელო სარეზერვო ასლის შექმნისა და აღდგენის შესახებ SQL Server მონაცემთა ბაზები.
9. გამოსწორება #6: ავტომატური დახურვის ფუნქციის გამორთვა
მონაცემთა ბაზის AUTO CLOSE პარამეტრმა შეიძლება გამოიწვიოს აღდგენის განმეორებითი ციკლები, რაც ქმნის შთაბეჭდილებას, რომ თქვენი SQL Server მონაცემთა ბაზა მუდმივად აღდგენის რეჟიმშია. ამ თვისების გამორთვა პრობლემას აგვარებს.
9.1 ავტომატური დახურვის პრობლემების გაგება
როდესაც ავტომატური დახურვა ჩართულია, SQL Server ბოლო კავშირის დასრულების შემდეგ ხურავს მონაცემთა ბაზას და შემდეგ ხელახლა ხსნის მას ახალი კავშირებისთვის. განმეორებითი გახსნა ყოველ ჯერზე აღდგენის პროცესებს იწვევს.
9.2 ავტომატური დახურვის გამორთვა
- ღიაა SQL Server მენეჯმენტის სტუდია
- დააწკაპუნეთ მარჯვენა ღილაკით თქვენს მონაცემთა ბაზაზე -> განცხადებები
- აირჩიეთ პარამეტრები მარცხენა პანელიდან
- უცნობია ავტომატური დახურვა to ყალბი
- დაწკაპეთ OK ცვლილებების გამოსაყენებლად
ალტერნატიულად, გამოიყენეთ T-SQL:
ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;
10. შესწორება #7: გადატვირთვა SQL Server სამსახურის
სერვისის გადატვირთვამ შეიძლება გადაჭრას აღდგენის პროცესების პრობლემა, თუმცა ის სიფრთხილით უნდა იქნას გამოყენებული, რადგან ის თავიდან დაიწყებს აღდგენას. ეს გამოსწორება მუშაობს, როდესაც SQL Server გამოჯანმრთელების პროცესში სრულიად გაყინული ჩანს.
10.1 როდესაც სერვისის გადატვირთვა დაგეხმარებათ
გადატვირთეთ სერვისი, როდესაც:
- აღდგენის პროცესი რამდენიმე საათის განმავლობაში შეჩერებულია
- შეცდომების ჟურნალები ახალ ჩანაწერებს არ აჩვენებს
- სხვა მონაცემთა ბაზები ჩვეულებრივად ფუნქციონირებს
- შეგიძლიათ გახანგრძლივებული შეფერხების დრო აიღოთ
10.2 უსაფრთხო გადატვირთვის პროცედურები
- ღიაა SQL Server კონფიგურაციის მენეჯერი
- ნავიგაცია SQL Server მომსახურება
- მოძებნა SQL Server თუ გსურთ გადატვირთვა, დააწკაპუნეთ მაუსის მარჯვენა ღილაკით SQL Server (ინსტანციის სახელი)
- აირჩიეთ რესტარტი
- დაელოდეთ სერვისის სრულად გადატვირთვას
- აღდგენის პროგრესის შეცდომების ჟურნალების მონიტორინგი
შენიშვნა: გადატვირთვა აღდგენის თავიდან დაწყებას გამოიწვევს, რაც პოტენციურად გაზრდის აღდგენის მთლიან დროს.
11. შესწორება #8: მონაცემთა ბაზის აღდგენა მოხსნით და ხელახლა მიმაგრებით
უკიდურეს შემთხვევაში, გამოაცალკევეთ და ხელახლა მიაერთეთ მონაცემთა ბაზა:
- მონაცემთა ბაზის გამოყოფა:
EXEC sp_detach_db 'YourDatabaseName'; - მხოლოდ MDF ფაილის მიმაგრება:
CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG; - ეს აღადგენს ახალ ტრანზაქციების ჟურნალს
გაფრთხილება: ამ მეთოდმა შეიძლება მონაცემების დაკარგვა გამოიწვიოს. გამოიყენეთ მხოლოდ მაშინ, როდესაც სხვა ვარიანტები ამოწურულია.
12. შესწორება #9: მონაცემთა ბაზის ასლის შექმნის პრობლემების მოგვარება
მონაცემთა ბაზის ასლის შექმნის კონფიგურაციებმა შეიძლება გამოიწვიოს უნიკალური აღდგენის პრობლემები. ეს შესწორება აგვარებს ასლის შექმნის სპეციფიკურ პრობლემებს, რომლებიც მონაცემთა ბაზებს აღდგენის მდგომარეობაში ინარჩუნებს.
12.1 სარკისებური აღდგენის პრობლემები
სარკისებური მონაცემთა ბაზები შეიძლება აღდგენის პროცესში გაიჭედოს პარტნიორთან კავშირის პრობლემების ან საბოლოო წერტილის პრობლემების გამო. როგორც ძირითად, ასევე სარკისებურ მონაცემთა ბაზებს შეუძლიათ აღდგენის სტატუსის ჩვენება.
12.2 სარკისებური აღდგენის გადაწყვეტილებები
გადატვირთეთ სარკისებური საბოლოო წერტილი:
- საბოლოო წერტილის სახელის პოვნა:
SELECT * FROM sys.endpoints WHERE type = 4; - გაჩერების საბოლოო წერტილი:
ALTER ENDPOINT [EndpointName] STATE = STOPPED; - საწყისი საბოლოო წერტილი:
ALTER ENDPOINT [EndpointName] STATE = STARTED;
თუ საბოლოო წერტილის გადატვირთვა ვერ მოხერხდა, სარკისებური პარტნიორობა დაირღვება:
- შეასრულე:
ALTER DATABASE [DatabaseName] SET PARTNER OFF; - გაშვება:
RESTORE DATABASE [DatabaseName] WITH RECOVERY; - მონაცემთა ბაზის ონლაინ რეჟიმში გაშვების შემდეგ, ასლის შექმნის ხელახლა კონფიგურაცია
13. გამოსწორება #10: გამოიყენეთ პროფესიონალური აღდგენის ინსტრუმენტები
მესამე მხარის აღდგენის ინსტრუმენტები ჩაშენების შემთხვევაში, გაფართოებულ აღდგენის შესაძლებლობებს უზრუნველყოფს SQL Server მეთოდები ვერ ხერხდება. ამ ხელსაწყოებს ხშირად შეუძლიათ მონაცემების აღდგენა ძლიერ დაზიანებული მონაცემთა ბაზებიდან.
13.1 DataNumen SQL Recovery
DataNumen SQL Recovery აქვს მაღალი აღდგენის მაჩვენებელი, ყოვლისმომცველ ვარიანტებთან ერთად.
ქვემოთ მოცემულია მისი გამოყენების ნაბიჯები:
- შეაჩერე SQL Server სამსახური.
- აღდგენის რეჟიმში შექმენით მონაცემთა ბაზის ფაილების ასლი, მათ შორის როგორც ძირითადი MDF ფაილი, ასევე მეორადი NDF ფაილები.
- დაწყება SQL Server სამსახური.
- დასაწყისი DataNumen SQL Recovery.
- აღსადგენი მონაცემთა ბაზის წყაროდ აირჩიეთ ასლი, ორიგინალი ფაილის ნაცვლად.
- დააჭირეთ ღილაკს „აღდგენის დაწყება“ და მიჰყევით ინსტრუქციებს მონაცემთა ბაზის აღსადგენად.
- აღდგენის პროცესის შემდეგ, გამოჩნდება ახალი აღდგენის მონაცემთა ბაზა. SQL Server რომელიც შეიცავს ყველა აღდგენილ მონაცემს.
13.2 როდის უნდა განიხილოთ მესამე მხარის ინსტრუმენტები
გამოიყენეთ პროფესიონალური ინსტრუმენტები, როდესაც:
- ჩაშენებული შეკეთების ვარიანტები ვერ ხერხდება ან აფიქსირებს ფართომასშტაბიან დაზიანებას
- ბოლოდროინდელი სარეზერვო ასლები არ არის ხელმისაწვდომი
- კორუფციის მიუხედავად, კრიტიკული მონაცემები უნდა აღდგეს
- სტანდარტული აღდგენის მეთოდები მნიშვნელოვან მონაცემთა დაკარგვას იწვევს
14. პრევენციის საუკეთესო პრაქტიკა
14.1 რეგულარული მოვლის ამოცანები
ამ პრაქტიკის გამოყენება თავიდან ასაცილებლად SQL Server მონაცემთა ბაზაში აღდგენის პრობლემები:
- რეგულარული სრული და ჟურნალის სარეზერვო ასლების შექმნის დაგეგმვა: შეინარჩუნეთ სრული სარეზერვო ჯაჭვები
- მონიტორის VLF-ის რაოდენობა: ოპტიმალური მუშაობისთვის VLF-ები 100-ზე ნაკლები უნდა იყოს
- გეგმის ჟურნალის ფაილის ზომა: მორების წინასწარი ზომა, რათა თავიდან აიცილოთ ზედმეტი თვითზრდა
- გაუშვით ჩვეულებრივი DBCC CHECKDB: კორუფციის ადრეული გამოვლენა
14.2 მონიტორინგი და გაფრთხილება
პროაქტიული მონიტორინგის დაყენება:
- მონაცემთა ბაზის მდგომარეობის ცვლილებების შეტყობინებების კონფიგურაცია
- ლოგ ფაილების დისკებზე დისკის სივრცის მონიტორინგი
- გრძელვადიანი ტრანზაქციების თვალყურის დევნება
- გაფრთხილება VLF-ის გადაჭარბებული რაოდენობის შესახებ
14.3 აპარატურა და ინფრასტრუქტურა
საიმედო ინფრასტრუქტურის უზრუნველყოფა:
- ტრანზაქციების ჟურნალებისთვის გამოიყენეთ სწრაფი მეხსიერება (სასურველია SSD-ები)
- დააინსტალირეთ ზედმეტი კვების წყაროები
- მონაცემებისა და ჟურნალის ფაილების გამოყოფა სხვადასხვა დისკზე
- განვიხილოთ მაღალი ხელმისაწვდომობის გადაწყვეტილებები ისევე როგორც ყოველთვის ხელმისაწვდომი ჯგუფები
15. რთული სცენარების პრობლემების მოგვარება
15.1 მონაცემთა ბაზის მრავალი პრობლემა
როდესაც აღდგენის პროცესში რამდენიმე მონაცემთა ბაზაა გაჭედილი:
- შეამოწმეთ სისტემის მასშტაბით არსებული პრობლემები (დისკის ადგილი, მეხსიერება)
- აღდგენისთვის პრიორიტეტული მიანიჭეთ კრიტიკული მონაცემთა ბაზებს
- გაითვალისწინეთ აპარატურული პრობლემები, რომლებიც გავლენას ახდენს მთელ ეგზემპლარზე
- გადახედეთ სისტემის ბოლო ცვლილებებს ან განახლებებს
15.2 დიდი მონაცემთა ბაზის გასათვალისწინებელი საკითხები
1 ტბ-ზე მეტი მოცულობის მონაცემთა ბაზებისთვის:
- ველით უფრო ხანგრძლივ გამოჯანმრთელებას (შესაძლოა დღეები)
- უზრუნველყოთ მეხსიერების ადეკვატური განაწილება
- გაითვალისწინეთ პარალელური დამუშავების პარამეტრები
- აღდგენის დროს tempdb სივრცის მონიტორინგი
15.3 როდის უნდა დაუკავშირდეთ Microsoft-ის მხარდაჭერის სამსახურს
დაუკავშირდით Microsoft-ის მხარდაჭერის სამსახურს შემდეგ საკითხებზე:
- კრიტიკული წარმოების სისტემები სარეზერვო ასლის ვარიანტების გარეშე
- ეჭვმიტანილი SQL Server პროგრამული შეცდომები
- საწარმოს გარემო, რომელიც მოითხოვს გარანტირებულ აღდგენას
- რთული Always On ან კლასტერიზაციის სცენარები
16. ხშირად დასმული კითხვები
კითხვა: რამდენ ხანს უნდა SQL Server მონაცემთა ბაზის აღდგენას ჩვეულებრივ სჭირდება?
A: აღდგენის დრო დამოკიდებულია მონაცემთა ბაზის ზომაზე, ტრანზაქციების მოცულობასა და აპარატურის მუშაობაზე. მცირე მონაცემთა ბაზების აღდგენას, როგორც წესი, წუთები სჭირდება, ხოლო დიდ მონაცემთა ბაზებს, რომლებსაც ვრცელი ტრანზაქციების ჟურნალები აქვთ, შეიძლება რამდენიმე საათი დასჭირდეს. შეცდომების ჟურნალებში ნაჩვენები დროის შეფასებები ხშირად არაზუსტია, ამიტომ ყურადღება გაამახვილეთ პროგრესის პროცენტებზე.
კითხვა: შემიძლია გავჩერდე? SQL Server აღდგენის დროს მონაცემების დაკარგვის გარეშე?
A: გაჩერება SQL Server აღდგენის დროს გამოყენება ზოგადად უსაფრთხოა, მაგრამ სერვისის გადატვირთვისას აღდგენის პროცესი თავიდანვე განახლდება. ეს ზრდის აღდგენის მთლიან დროს, მაგრამ არ იწვევს დამატებით მონაცემთა დაკარგვას თავდაპირველი ინციდენტის დროს მომხდარის გარდა.
კითხვა: რა განსხვავებაა „აღდგენის პროცესში“ და „აღდგენის მოლოდინში“ პირობებს შორის?
A: „გამოჯანმრთელების პროცესში“ ნიშნავს SQL Server აქტიურად ასრულებს აღდგენის ოპერაციებს. „აღდგენა მოლოდინშია“ მიუთითებს, რომ აღდგენის პროცესი ვერ დაიწყო, როგორც წესი, დაკარგული ფაილების, არასაკმარისი ნებართვების ან დისკზე სივრცის პრობლემების გამო, რომლებიც აღდგენის გაგრძელებამდე უნდა მოგვარდეს.
„აღდგენის მოლოდინში ყოფნის“ შესახებ უფრო დეტალური ინფორმაციის მოძიება შეგიძლიათ ჩვენს ვებგვერდზე. ყოვლისმომცველი სახელმძღვანელო.
კითხვა: დავკარგავ მონაცემებს, თუ გამოვიყენებ REPAIR_ALLOW_DATA_LOSS-ს?
A: დიახ, REPAIR_ALLOW_DATA_LOSS-მა შეიძლება წაშალოს დაზიანებული მონაცემები მონაცემთა ბაზის თანმიმდევრულობის აღსადგენად. ყოველთვის სცადეთ REPAIR_REBUILD, რომელიც აგვარებს სტრუქტურულ პრობლემებს მონაცემთა დაკარგვის გარეშე. გამოიყენეთ REPAIR_ALLOW_DATA_LOSS მხოლოდ უკიდურეს შემთხვევაში, როდესაც აღდგენის სხვა ვარიანტები არ გაქვთ.
კითხვა: შემიძლია თუ არა სხვა მონაცემთა ბაზებზე წვდომა, სანამ ერთი მონაცემთა ბაზა აღდგენის პროცესშია?
A: დიახ, სხვა მონაცემთა ბაზები იმავე საკითხზე SQL Server აღდგენის დროს ინსტანცია ხელმისაწვდომი რჩება. მხოლოდ აღდგენის პროცესში მყოფი მონაცემთა ბაზაა მიუწვდომელი. თუმცა, აღდგენის ოპერაციებმა შეიძლება გავლენა მოახდინოს სერვერის საერთო მუშაობაზე.
კითხვა: რა იწვევს მონაცემთა ბაზის აღდგენის რეჟიმში გაჭედვას?
A: გავრცელებული მიზეზებია NORECOVERY-ის გამოყენებით აღდგენის ოპერაციების არასრული რაოდენობა, ვირტუალური ჟურნალის ფაილების (VLF) სიჭარბე, დიდი, დაუსრულებელი ტრანზაქციები, მონაცემთა ბაზის დაზიანება, დისკზე არასაკმარისი სივრცე და აპარატურული პრობლემები. ასევე, შესაძლოა, ავტომატური დახურვის ფუნქციის მქონე მონაცემთა ბაზები მუდმივად შევიდეს აღდგენაში.
კითხვა: როგორ გავიგო, გამოჯანმრთელება პროგრესირებს თუ ჩერდება?
A: მონიტორი SQL Server აღდგენის პროგრესის შეტყობინებების შეცდომების ჟურნალები, რომლებიც აჩვენებს დასრულების პროცენტულ მაჩვენებლებს. გამოიყენეთ sys.dm_exec_requests აქტიური მონაცემთა ბაზის გაშვების ბრძანებების შესამოწმებლად. თუ პროცენტული მაჩვენებლები დროთა განმავლობაში იზრდება, აღდგენა მიმდინარეობს. რამდენიმე საათის განმავლობაში ახალი ჩანაწერების არარსებობა შეიძლება მიუთითებდეს პროცესის გაჭედვაზე.
კითხვა: უსაფრთხოა თუ არა გადატვირთვა? SQL Server მომსახურება აღდგენის პერიოდში?
A: გადატვირთვა უსაფრთხოა, მაგრამ სიფრთხილით უნდა იქნას გამოყენებული. ეს აღდგენას თავიდან დაიწყებს, რაც შესაძლოა აღდგენის დროს გააორმაგებდეს. გადატვირთეთ მხოლოდ იმ შემთხვევაში, თუ აღდგენა სრულიად გაყინულია და მრავალი საათის განმავლობაში პროგრესი არ არის, ან თუ ეჭვი გეპარებათ, რომ პროცესი ნამდვილად ჩიხშია.
კითხვა: რა განსხვავებაა ავტომატურ დახურვასა და აღდგენის რეჟიმს შორის?
A: ავტომატური დახურვა ავტომატურად ხურავს მონაცემთა ბაზებს, როდესაც კავშირები არ არის და შემდეგ ხელახლა ხსნის მათ ახალი კავშირებისთვის. განმეორებითი გახსნა ყოველ ჯერზე იწვევს მოკლე აღდგენის პროცესებს, რაც ქმნის შთაბეჭდილებას, რომ მონაცემთა ბაზა მუდმივად აღდგენის პროცესშია. ავტომატური დახურვის გამორთვა აგვარებს ამ პრობლემას.
კითხვა: შეუძლია თუ არა ტრანზაქციების ჟურნალის სარეზერვო ასლების შექმნას დახმარება აღდგენის დროს?
A: ტრანზაქციების ჟურნალის სარეზერვო ასლების შექმნას შეუძლია ჟურნალის სივრცის გათავისუფლება, თუ ჟურნალის დისკი სავსეა, რაც პოტენციურად აღდგენის გაგრძელების საშუალებას იძლევა. თუმცა, თქვენ არ შეგიძლიათ შექმნათ სარეზერვო ასლი იმ მონაცემთა ბაზის ჟურნალისთვის, რომელიც ამჟამად აღდგენის რეჟიმშია. ჟურნალის სარეზერვო ასლები უფრო სასარგებლოა პრევენციისა და აღდგენის შემდგომი ტექნიკური მომსახურებისთვის.
კითხვა: როდის უნდა დავუკავშირდე Microsoft-ის მხარდაჭერის სამსახურს?
A: ეჭვის შემთხვევაში, დაუკავშირდით Microsoft-ის მხარდაჭერის სამსახურს კრიტიკული საწარმოო სისტემებისთვის, სადაც ჩაშენებული აღდგენის მეთოდები ვერ ხერხდება. SQL Server პროგრამული უზრუნველყოფის შეცდომები, Always On ან კლასტერიზაციის რთული სცენარებისთვის, ან როდესაც საწარმოს გარემოში საჭიროა მონაცემთა გარანტირებული აღდგენა მინიმალური შეფერხებით.
კითხვა: როგორ შემიძლია თავიდან ავიცილო მონაცემთა ბაზების გაჭედვა აღდგენის პროცესში?
A: რეგულარულად განახორციელეთ სრული და ჟურნალის სარეზერვო ასლები, აკონტროლეთ და მართეთ VLF-ის რაოდენობა, უზრუნველყავით დისკზე საკმარისი ადგილი, გამოიყენეთ სათანადო გამორთვის პროცედურები, შეინარჩუნეთ აპარატურის საიმედოობა, გამორთეთ AUTO CLOSE საწარმოო მონაცემთა ბაზებზე და რეგულარულად გაუშვით DBCC CHECKDB ოპერაციები დაზიანების ადრეულ ეტაპზე გამოსავლენად.
კითხვა: რა არის VLF-ები და რატომ მოქმედებს ისინი აღდგენაზე?
ვირტუალური ჟურნალის ფაილები (VLF) ტრანზაქციების ჟურნალის ფაილებში არსებული შიდა სეგმენტებია. ძალიან ბევრი VLF (1,000-ზე მეტი) მნიშვნელოვნად ანელებს აღდგენას, რადგან SQL Server თითოეული მათგანი ინდივიდუალურად უნდა დამუშავდეს. ჟურნალის ფაილის სწორი ზომა და ზრდის პარამეტრები ხელს უწყობს VLF-ის ოპტიმალური რაოდენობის შენარჩუნებას.
კითხვა: შემიძლია თუ არა მონაცემთა ბაზის აღდგენის პროცესში ყოფნისას სარეზერვო ასლიდან აღდგენა?
A: თქვენ არ შეგიძლიათ აღდგენა მონაცემთა ბაზიდან, რომელიც ამჟამად აღდგენის რეჟიმშია. თქვენ უნდა დაელოდოთ აღდგენის დასრულებას ან შეაჩეროთ SQL Server სერვისი, ან მონაცემთა ბაზის სხვა სახელზე აღდგენა. გადაუდებელი სიტუაციებისთვის, განიხილეთ მონაცემთა ბაზის ახალი სახელით აღდგენა და აღდგენის პრობლემების მოგვარების შემდეგ მისი სახელის შეცვლა.
17. დასკვნა და შემდეგი ნაბიჯები
17.1 ძირითადი გადაწყვეტილებების შეჯამება
როდესაც თქვენი SQL Server მონაცემთა ბაზა აღდგენის პროცესშია, დაიწყეთ ამ მიდგომებით თანმიმდევრობით:
- შეამოწმეთ შეცდომების ჟურნალები და აკონტროლეთ პროგრესი
- თუ პროგრესი სტაბილურია, დაელოდეთ ბუნებრივ დასრულებას
- არასრული აღდგენისთვის გამოიყენეთ RESTORE WITH RECOVERY
- ტრანზაქციების ჟურნალის პრობლემების მოგვარება
- გაუშვით DBCC CHECKDB ან პროფესიონალური ინსტრუმენტები კორუფციის აღმოსაჩენად
- მძიმე შემთხვევებისთვის განიხილეთ სარეზერვო აღდგენა.
ხიდი SQL Server აღდგენის სიტუაციებში მონაცემთა ბაზის პრობლემები ამ დადასტურებული მეთოდების გამოყენებით რამდენიმე საათში გვარდება. რთული სცენარებისთვის, ნუ მოგერიდებათ მოწინავე ტექნიკის ან პროფესიონალური ინსტრუმენტების გამოყენება.
17.2 დამატებითი რესურსები
დამატებითი დახმარებისთვის:
- microsoft SQL Server დოკუმენტაცია
- SQL Server თემის ფორუმები
- მონაცემთა ბაზის ადმინისტრირების ბლოგები და ტექნიკური რესურსები
- პროფესიონალური მონაცემთა ბაზის აღდგენის სერვისები
რეგულარული ტექნიკური მომსახურება და მონიტორინგი ხელს უშლის აღდგენის პრობლემების უმეტესობას. დანერგეთ ამ სახელმძღვანელოში აღწერილი პრევენციული პრაქტიკა, რათა მინიმუმამდე დაიყვანოთ MS SQL-ის გამოყენების შემთხვევები აღდგენის პრობლემებში.
ავტორის შესახებ
იუან შენგი არის მონაცემთა ბაზის უფროსი ადმინისტრატორი (DBA) 10 წელზე მეტი გამოცდილებით SQL Server გარემოსა და საწარმოს მონაცემთა ბაზის მართვაში. მან წარმატებით გადაჭრა მონაცემთა ბაზის აღდგენის ასობით სცენარი ფინანსურ სერვისებში, ჯანდაცვისა და წარმოების ორგანიზაციებში.
იუანი სპეციალიზირებულია SQL Server მონაცემთა ბაზის აღდგენა, მაღალი ხელმისაწვდომობის გადაწყვეტილებები და მუშაობის ოპტიმიზაცია. მისი ფართო პრაქტიკული გამოცდილება მოიცავს მრავალტერაბაიტიანი მონაცემთა ბაზების მართვას, Always On Availability Groups-ის დანერგვას და კრიტიკულად მნიშვნელოვანი ბიზნეს სისტემებისთვის ავტომატური სარეზერვო ასლისა და აღდგენის სტრატეგიების შემუშავებას.
თავისი ტექნიკური ექსპერტიზისა და პრაქტიკული მიდგომის წყალობით, იუანი ფოკუსირებულია ყოვლისმომცველი სახელმძღვანელოების შექმნაზე, რომლებიც მონაცემთა ბაზის ადმინისტრატორებსა და IT სპეციალისტებს დაეხმარება რთული საკითხების გადაჭრაში. SQL Server ეფექტურად უწევს გამოწვევებს. ის მუდმივად ადევნებს თვალყურს უახლეს ამბებს SQL Server რელიზები და Microsoft-ის განვითარებადი მონაცემთა ბაზის ტექნოლოგიები, რეგულარულად ამოწმებს აღდგენის სცენარებს იმის უზრუნველსაყოფად, რომ მისი რეკომენდაციები ასახავდეს რეალურ სამყაროს საუკეთესო პრაქტიკას.
გაქვთ შეკითხვები SQL Server აღდგენა ან გჭირდებათ დამატებითი რჩევები მონაცემთა ბაზის პრობლემების მოგვარებაში? იუანი სიამოვნებით მოგმართავთ. გამოხმაურება და წინადადებები ამ ტექნიკური რესურსების გასაუმჯობესებლად.









