SQL Server Bərpa rejimində verilənlər bazası: 10 düzəliş [2026]

Bir SQL Server verilənlər bazası “Bərpada” statusunu göstərir, yəni SQL Server verilənlər bazası ardıcıllığını təmin etmək üçün qəza bərpası və ya əməliyyatın bərpasını həyata keçirir. Bu avtomatik proses törədilmiş əməliyyatları təkrar oynatmaqla və yerinə yetirilməmiş əməliyyatları geri qaytarmaqla məlumatların bütövlüyünü qoruyur.

Bərpa rejimi adətən gözlənilməz bağlanmalardan, elektrik kəsilməsindən sonra və ya verilənlər bazası bərpası zamanı baş verir. Bu normal bir qoruyucu mexanizm olsa da, problemlər yaranır SQL Server bərpa olunan verilənlər bazası qeyri-adi uzun çəkir və ya ilişib görünür.

1.2 Verilənlər bazasının bərpasının üç mərhələsi

SQL Server bərpa üç fərqli mərhələdən keçir:

1.2.1 Təhlil Mərhələsi

SQL Server çirkli səhifələri və aktiv əməliyyatları müəyyən etmək üçün son yoxlama məntəqəsindən əməliyyat jurnalını skan edir. Bərpaya ehtiyacı olanları izləmək üçün Çirkli Səhifə Cədvəli (DPT) və Aktiv Əməliyyat Cədvəli (ATT) yaradır.

1.2.2 Fazanın təkrarlanması (İrəli fırladın)

Sistem qəzadan əvvəl diskə yazılmamış bütün əməliyyatları təkrarlayır. Bu, bütün qəbul edilmiş dəyişikliklərin verilənlər bazası fayllarına düzgün tətbiq edilməsini təmin edir.

1.2.3 Geri qaytarma mərhələsi (geriyə qayıt)

Verilənlər bazası ardıcıllığını qorumaq üçün hər hansı öhdəsindən gəlməmiş əməliyyatlar geri qaytarılır. Tamamlandıqdan sonra verilənlər bazası normal əməliyyatlar üçün əlçatan olur.

1.3 Ümumi Simptomlar və Səhv Mesajları

Zaman SQL Server db bərpa olunur, adətən görəcəksiniz:

"(Bərpada)"-ni göstərən verilənlər bazası adı SQL Server İdarəetmə Studiyası
“Verilənlər bazası bərpa olunur” mesajları ilə giriş xətaları
Bərpa tərəqqi faizlərini göstərən xəta qeydləri
Sorğu zamanı “BƏRPA”nı göstərən verilənlər bazası vəziyyəti

2. Kök səbəbləri SQL Server Bərpa Rejimi Problemləri

2.1 Natamam Bərpa Əməliyyatları

Ən çox yayılmış səbəb, birdən çox ehtiyat nüsxə faylından bərpa edərkən baş verir NORECOVERY final olmadan seçim BƏRPA İLƏ əmr. Bu, verilənlər bazasını əlavə bərpa əməliyyatlarını gözləyir.

2.2 Tranzaksiya Qeydləri Problemləri

Böyük əməliyyat jurnalı faylları və ya həddindən artıq Virtual Qeyd Faylları (VLF) bərpa prosesini əhəmiyyətli dərəcədə yavaşlatır. MS SQL minlərlə VLF ilə bərpa edildikdə, prosesin tamamlanması saatlar və ya günlər çəkə bilər.

2.3 Sistemlə əlaqəli məsələlər

Avadanlıq nasazlıqları, elektrik kəsintiləri və ya disk sahəsinin kifayət qədər olmaması normal verilənlər bazası əməliyyatlarını poza bilər və yenidən başlatma zamanı uzun bərpa proseslərinə səbəb ola bilər.

2.4 Verilənlər bazasının korrupsiyası

Zədələnmiş verilənlər bazası faylları bərpanın uğurla başa çatmasına mane olur, verilənlər bazası qeyri-müəyyən müddətə bərpa rejimində ilişib qalır.

3. Düzəltmədən əvvəl diaqnostik addımlar

3.1 yoxlanılır SQL Server Səhv qeydləri

Düzəlişlərə cəhd etməzdən əvvəl, yoxlayın SQL Server bərpa tərəqqi mesajları üçün xəta jurnalı. Tamamlanma faizlərini və qalan təxmini vaxtı göstərən qeydləri axtarın.

açıq SQL Server İdarəetmə Studiyası
gedin idarə -> SQL Server Qeydlər
Verilənlər bazanızın adınız üçün son qeydləri nəzərdən keçirin
Bərpa mərhələsinin göstəricilərini axtarın (Mərhələ 1, 2 və ya 3/3)

3.2 Bərpa prosesinin monitorinqi

Aktiv bərpa əməliyyatlarını izləmək üçün dinamik idarəetmə görünüşlərindən istifadə edin:

SELECT session_id, command, blocking_session_id, wait_type, wait_time, wait_resource
FROM sys.dm_exec_requests
WHERE command = 'DB STARTUP';

3.3 Verilənlər bazasının vəziyyətinin yoxlanılması

Bərpa vəziyyətini başa düşmək üçün cari verilənlər bazası vəziyyətini yoxlayın:

SELECT name, state_desc
FROM sys.databases
WHERE name = 'YourDatabaseName';

4. Düzəltmə №1: Təbii bərpanın tamamlanmasını gözləyin

Bəzən səbirli olduğunuz zaman ən yaxşı həll yoludur SQL Server verilənlər bazası bərpa olunur. Bu yanaşma bərpa prosesinin normal getdiyi, lakin gözləniləndən daha uzun sürdüyü zaman işləyir.

4.1 Nə vaxt səbirli olmaq lazımdır

Aşağıdakı hallarda təbii tamamlamaya icazə verin:

Səhv qeydləri azalan vaxt təxminləri ilə sabit irəliləyiş göstərir
Heç bir korrupsiya səhvi bildirilmir
Verilənlər bazası yaxınlarda böyük əməliyyatlarla qarşılaşdı
VLF sayı idarə edilə bilər (1,000-dən az)

4.2 Bərpa prosesinin monitorinqi

Səhv qeydlərində bərpa müddəti təxminləri çox vaxt qeyri-dəqiq olur. Qalan vaxtdan çox irəliləyiş faizlərinə diqqət yetirin. Geniş əməliyyat tarixçəsi olan böyük verilənlər bazası tam bərpa üçün bir neçə saat tələb edə bilər.

5. Düzəltmə №2: BƏRPA İLƏ MƏLUMAT BAZASINI BƏRPA EDİN

Bu düzəliş son bərpa addımının buraxıldığı natamam bərpa əməliyyatlarını həll edir. Bu zaman istifadə edin SQL Server db bərpası NORECOVERY-dən istifadə edərək bərpa prosesinin nəticəsidir.

5.1 Komandanı başa düşmək

The BƏRPA İLƏ MƏLUMAT BAZASINI BƏRPA EDİN əmri yerinə yetirilməmiş əməliyyatları geri qaytarmaqla və verilənlər bazasını onlayn vəziyyətə gətirməklə bərpa prosesini tamamlayır.

5.2 İcra Mərhələləri

açıq SQL Server İdarəetmə Studiyası
Özünüzə qoşun SQL Server Məsələn
Basın Yeni > Cari Bağlantı ilə Sorğu
İcra etmək: RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
Tamamlamanın təsdiqini gözləyin

Warning: Bu əmri yalnız heç bir əlavə bərpa əməliyyatının gözləmədiyinə əminsinizsə istifadə edin.

6. Fix #3: Tranzaksiya Qeydiyyatı Problemlərini Həll edin

Əməliyyat jurnalı problemləri bərpa müddətlərinin uzadılmasının əsas səbəbidir. Bu düzəliş tam qeydləri, həddindən artıq VLF-ləri və saxlanılan log sahəsi problemlərini həll edir SQL Server bərpada.

6.1 Əməliyyat qeydlərinin ehtiyat nüsxəsinin çıxarılması

Tranzaksiya jurnalının ehtiyat nüsxələrini yaratmaqla jurnalda yer boşaldın:

açıq SQL Server İdarəetmə Studiyası
Verilənlər bazanıza sağ vurun -> Tapşırıqlar -> Up Geri
Dəyişdirmək Yedəkləmə növü üçün Əməliyyat jurnalı
Yedəkləmə təyinatını təyin edin
Basın OK icra etmək

6.2 Virtual Qeyd Fayllarının (VLF) idarə edilməsi

VLF sayını yoxlayın:

DBCC LOGINFO('YourDatabaseName');

1,000-dən çox VLF varsa, onları azaldın:

Əməliyyat jurnalının ehtiyat nüsxəsinin çıxarılması
Günlük faylının kiçilməsi: DBCC SHRINKFILE(LogFileName, TRUNCATEONLY);
Günlük faylı böyük hissələrdə böyütmək (1 GB və ya daha çox)

6.3 Log fayllarının təhlükəsiz şəkildə kiçilməsi

Heç bir aktiv əməliyyat işləmədikdə, yalnız texniki xidmət pəncərələri zamanı qeydləri daraltın. Əməliyyatları daraltmadan əvvəl həmişə verilənlər bazasının ehtiyat nüsxəsini çıxarın.

7. №4 düzəldin: DBCC CHECKDB-ni işə salın və Təmir edin

Verilənlər bazasının korlanması bərpanın uğurla başa çatmasına mane ola bilər. DBCC CHECKDB, MS SQL-i bərpa rejimində saxlayan kiçik korrupsiya məsələlərini müəyyən edə və təmir edə bilən daxili əmrdir.

7.1 Verilənlər Bazası Korrupsiyasının Yoxlanması

Verilənlər bazasının bütövlüyünü yoxlamaq üçün standart yanaşmadan başlayın. Əvvəlcə birbaşa DBCC CHECKDB-ni sınayın:

İcra etmək: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
Ardıcıllıq səhvləri üçün nəticələri nəzərdən keçirin
Hər hansı bir korrupsiya mesajını sənədləşdirin

DBCC CHECKDB uğursuz olarsa "Verilənlər bazası bərpa olunur. Bərpa tamamlanana qədər gözləyin" kimi xətalarla bu, verilənlər bazasının aktiv şəkildə bərpa rejimində olduğunu və girişi blokladığını bildirir. Bu halda Fövqəladə vəziyyət rejimindən istifadə etmək üçün bölmə 7.3-ə keçin.

7.2 Əlçatan verilənlər bazaları üçün təmir variantları

DBCC CHECKDB uğurla işlədisə və korrupsiya aşkar edilərsə, bu təmir addımlarını istifadə edin:

Verilənlər bazasını tək istifadəçi rejiminə təyin edin: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
Təhlükəsiz təmirə cəhd edin: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
Əgər uğursuz olarsa, istifadə edin: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
Çox istifadəçiyə qayıt: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;

7.3 Verilənlər bazası əlçatmaz olduqda fövqəladə rejimdən istifadə

Fövqəladə vəziyyət rejimi yalnız verilənlər bazası bərpa prosesində ilişib qaldıqda və normal DBCC CHECKDB cəhdlərini rədd etdikdə tələb olunur. O, verilənlər bazasını YALNIZ READ_ONLY kimi qeyd edir və girişi söndürür. Standart giriş uğursuz olduqda bu yanaşmadan istifadə edin:

Təcili rejim təyin edin: ALTER DATABASE [YourDatabaseName] SET EMERGENCY;
Tək istifadəçi təyin edin: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
Bütövlük yoxlanışını həyata keçirin: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
Korrupsiya aşkar edilərsə, əvvəlcə təhlükəsiz təmiri həyata keçirin: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
Əgər uğursuz olarsa, məlumat itkisi ilə təmirdən istifadə edin: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
Çox istifadəçi təyin edin: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
Onlayn təyin edin: ALTER DATABASE [YourDatabaseName] SET ONLINE;

Mühüm: Fövqəladə vəziyyət rejimi normal bərpa proseslərindən yan keçir və yalnız verilənlər bazası tamamilə əlçatmaz olduqda istifadə edilməlidir. Fövqəladə vəziyyət rejiminə keçməzdən əvvəl həmişə standart DBCC CHECKDB yanaşmasını sınayın.

Bilərsiniz DBCC CHECKDB-dən necə istifadə ediləcəyinə dair daha əhatəli bələdçi.

8. Fix #5: Yedəkləmədən bərpa edin

Digər üsullar uğursuz olduqda və ya məlumatların bütövlüyü şübhə altında olduqda, təmiz ehtiyat nüsxəsindən bərpa etmək çox vaxt problemi həll etmək üçün ən etibarlı həll yoludur. SQL Server bərpa məsələlərində verilənlər bazası.

8.1 Yedək nüsxəsinin bərpasını nə vaxt seçmək lazımdır

Aşağıdakı hallarda ehtiyat nüsxəsinin bərpasını nəzərdən keçirin:

Bərpa 24 saatdan çoxdur ki, irəliləyiş olmadan işləyir
Korrupsiya səhvləri uğurlu təmirə mane olur
Ən son, təsdiqlənmiş yedəkləmələriniz var
Son ehtiyat nüsxədən sonra məlumat itkisi məqbuldur

8.2 Addım-addım Bərpa Prosesi

açıq SQL Server İdarəetmə Studiyası
Sağ-klik Verilənlər bazası -> Verilənlər bazasını bərpa edin
seçmək cihaz Mənbə altında
Basın əlavə etmək və ehtiyat faylınıza göz atın
Yedəkləməni seçin və vurun OK
Seçmək Mövcud verilənlər bazasının üzərinə yazın ehtiyac olarsa
Basın OK bərpaya başlamaq üçün

8.3 Vaxtında Bərpa

Minimum məlumat itkisi üçün, müəyyən bir vaxta bərpa etmək üçün əməliyyat jurnalının ehtiyat nüsxələrindən istifadə edin. Tam ehtiyat nüsxənizdən istədiyiniz bərpa nöqtəsinə qədər kəsilməmiş log ehtiyat nüsxələri zəncirinə malik olduğunuzdan əmin olun.

8.4 İstinad

Ətraflı məlumatı bizdən öyrənə bilərsiniz ehtiyat nüsxəsini çıxarmaq və bərpa etmək üçün hərtərəfli bələdçi SQL Server Məlumat bazaları.

9. 6-cı düzəldin: AVTO BAĞLAMASI xassəsini deaktiv edin

AUTO CLOSE verilənlər bazası xüsusiyyəti təkrar bərpa dövrlərinə səbəb ola bilər ki, bu da sizin SQL Server db daim bərpa olunur. Bu əmlakın söndürülməsi problemi həll edir.

9.1 AVTO BAĞLAMA Məsələlərini Anlamaq

AVTO BAĞLAMA aktiv olduqda, SQL Server sonuncu əlaqə bitdikdən sonra verilənlər bazasını bağlayır, sonra onu yeni bağlantılar üçün yenidən açır. Bu təkrarlanan açılış hər dəfə bərpa proseslərini işə salır.

9.2 AVTO BAĞLANMASINI söndürmək

açıq SQL Server İdarəetmə Studiyası
Verilənlər bazanıza sağ vurun -> Xüsusiyyətlər
seçmək Nizamlamalar sol paneldən
Set Avtomatik Bağla üçün Saxta
Basın OK dəyişiklikləri tətbiq etmək

Alternativ olaraq, T-SQL istifadə edin:

ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;

10. 7 nömrəli düzəliş: Yenidən başladın SQL Server xidmət

Xidmətin yenidən başlaması ilişib qalmış bərpa proseslərini həll edə bilər, lakin ehtiyatla istifadə edilməlidir, çünki bərpanı əvvəldən yenidən başladacaq. Bu düzəliş işləyir SQL Server bərpasında tamamilə donmuş görünür.

10.1 Xidmətin Yenidən Başlatılması Kömək Etdikdə

Xidməti yenidən başladın:

Bərpa prosesi bir neçə saatdır ki, dayanıb
Səhv qeydləri yeni qeydləri göstərmir
Digər verilənlər bazaları normal işləyir
Siz uzadılmış dayanma müddətini ödəyə bilərsiniz

10.2 Təhlükəsiz Yenidən Başlatma Prosedurları

açıq SQL Server Konfiqurasiya meneceri
gedin SQL Server Xidmətlər
Tapmaq SQL Server yenidən başlatmaq istədiyiniz halda, sağ klikləyin SQL Server (Nümunə adı)
seçmək Yenidən başlamaq
Xidmətin tam yenidən başlamasını gözləyin
Bərpa prosesi üçün xəta qeydlərinə nəzarət edin

Qeyd: Yenidən başlatma bərpanın əvvəldən başlamasına səbəb olacaq və bu da ümumi bərpa müddətini uzadacaq.

11. № 8-i düzəldin: Məlumat bazasını ayıraraq və yenidən birləşdirərək təmir edin

Ekstremal hallarda verilənlər bazasını ayırın və yenidən birləşdirin:

Verilənlər bazasını ayırın: EXEC sp_detach_db 'YourDatabaseName';
Yalnız MDF faylını əlavə edin: CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG;
Bu, yeni əməliyyat jurnalını yenidən qurur

Warning: Bu üsul məlumat itkisi ilə nəticələnə bilər. Yalnız digər seçimlər tükəndikdə istifadə edin.

12. №9 düzəldin: Verilənlər Bazasının Yansıtma Problemlərini həll edin

Verilənlər bazasının güzgü konfiqurasiyası unikal bərpa problemlərinə səbəb ola bilər. Bu düzəliş verilənlər bazalarını bərpa vəziyyətində saxlayan əks etdirmə ilə bağlı xüsusi problemləri həll edir.

12.1 Yansıtma üçün Xüsusi Bərpa Problemləri

Yansıtılmış verilənlər bazaları tərəfdaş əlaqəsi problemləri və ya son nöqtə problemləri səbəbindən bərpada ilişib qala bilər. Həm əsas, həm də güzgü verilənlər bazası bərpa vəziyyətini göstərə bilər.

12.2 Yansıtma Bərpa Həlləri

Güzgüləmə son nöqtəsini yenidən başladın:

Son nöqtənin adını tapın: SELECT * FROM sys.endpoints WHERE type = 4;
Son nöqtəni dayandırın: ALTER ENDPOINT [EndpointName] STATE = STOPPED;
Başlanğıc nöqtəsi: ALTER ENDPOINT [EndpointName] STATE = STARTED;

Son nöqtənin yenidən başlaması uğursuz olarsa, güzgü ortaqlığını pozun:

İcra etmək: ALTER DATABASE [DatabaseName] SET PARTNER OFF;
Run: RESTORE DATABASE [DatabaseName] WITH RECOVERY;
Verilənlər bazası onlayn olduqdan sonra əks etdirməni yenidən konfiqurasiya edin

13. №10-u düzəldin: Peşəkar Bərpa Alətlərindən istifadə edin

Üçüncü tərəfin bərpa alətləri quraşdırıldıqda qabaqcıl təmir imkanları təmin edir SQL Server üsullar uğursuz olur. Bu alətlər çox vaxt ciddi şəkildə zədələnmiş verilənlər bazalarından məlumatları bərpa edə bilir.

13.1 DataNumen SQL Recovery

DataNumen SQL Recovery hərtərəfli seçimlərlə birlikdə yüksək bərpa sürətinə malikdir.

Aşağıda ondan istifadə etmək üçün addımlar verilmişdir:

Dayandırın SQL Server Xidmət.
Həm əsas MDF faylı, həm də ikincil NDF faylları daxil olmaqla, bərpa rejimində verilənlər bazası fayllarının surətini çıxarın.
Başlayın SQL Server Xidmət.
start DataNumen SQL Recovery.
Bərpa olunacaq verilənlər bazasının mənbəyi kimi orijinal fayl əvəzinə surəti seçin.
Verilənlər bazasını bərpa etmək üçün "Bərpa etməyə başla" düyməsini basın və təlimatları izləyin.
Bərpa prosesindən sonra yeni bərpa verilənlər bazası görünəcək SQL Server bütün bərpa edilmiş məlumatları ehtiva edir.

13.2 Üçüncü tərəf alətlərini nə vaxt nəzərdən keçirməli

Aşağıdakı hallarda peşəkar vasitələrdən istifadə edin:

Daxili təmir variantları uğursuz olur və ya geniş korrupsiya barədə məlumat verir
Ən son ehtiyat nüsxələri mövcud deyil
Kritik məlumatlar korrupsiyaya baxmayaraq bərpa edilməlidir
Standart bərpa üsulları əhəmiyyətli məlumat itkisi ilə nəticələnir

14. Qarşısının alınması üzrə ən yaxşı təcrübələr

14.1 Daimi Baxım Tapşırıqları

Qarşısının alınması üçün bu təcrübələri həyata keçirin SQL Server bərpa məsələlərində verilənlər bazası:

Daimi tam və log ehtiyat nüsxələrini planlaşdırın: Tam ehtiyat zəncirlərini qoruyun
Monitor VLF sayları: Optimal performans üçün VLF-ləri 100-dən aşağı saxlayın
Günlük faylının ölçüsünü planlaşdırın: Həddindən artıq avtomatik böyümənin qarşısını almaq üçün əvvəlcədən ölçülü loglar
Adi DBCC CHECKDB-ni işə salın: Korrupsiyanı erkən aşkar edin

14.2 Monitorinq və xəbərdarlıq

Proaktiv monitorinq qurun:

Verilənlər bazası vəziyyəti dəyişiklikləri üçün xəbərdarlıqları konfiqurasiya edin
Günlük fayl sürücülərində disk sahəsinə nəzarət edin
Uzun müddət davam edən əməliyyatları izləyin
Həddindən artıq VLF sayları barədə xəbərdarlıq

14.3 Avadanlıq və İnfrastruktur

Etibarlı infrastrukturu təmin edin:

Əməliyyat qeydləri üçün sürətli yaddaşdan istifadə edin (tercihen SSD-lər)
Lazımsız enerji təchizatını həyata keçirin
Fərqli disklərdə məlumat və log fayllarını ayırın
Hesab yüksək mövcudluq həlləri kimi Həmişə Mövcud Qruplar

15. Mürəkkəb Ssenarilərdə problemlərin aradan qaldırılması

15.1 Çoxlu verilənlər bazası məsələləri

Bir neçə verilənlər bazası bərpa prosesində ilişib qaldıqda:

Sistem problemlərini yoxlayın (disk sahəsi, yaddaş)
Bərpa üçün kritik verilənlər bazalarına üstünlük verin
Bütün instansiyaya təsir edən hardware problemlərini nəzərdən keçirin
Son sistem dəyişikliklərini və ya yeniləmələrini nəzərdən keçirin

15.2 Böyük verilənlər bazası ilə bağlı mülahizələr

1TB-dən çox verilənlər bazası üçün:

Daha uzun bərpa müddətini gözləyin (potensial günlər)
Adekvat yaddaş ayrılmasını təmin edin
Paralel emal parametrlərini nəzərdən keçirin
Bərpa zamanı tempdb sahəsinə nəzarət edin

15.3 Microsoft Dəstəyi ilə nə vaxt əlaqə saxlamalısınız

Microsoft Dəstəyi ilə əlaqə saxlayın:

Ehtiyat variantları olmayan kritik istehsal sistemləri
Şübhəsiz SQL Server proqram səhvləri
Zəmanətli bərpa tələb edən müəssisə mühitləri
Kompleks Həmişə Aktiv və ya qruplaşdırma ssenariləri

16. Suallar

S: Nə qədər olmalıdır SQL Server verilənlər bazası bərpası normal alınır?

Cavab: Bərpa müddəti verilənlər bazası ölçüsündən, əməliyyat həcmindən və aparatın performansından asılıdır. Kiçik verilənlər bazaları adətən bir neçə dəqiqə ərzində bərpa olunur, geniş əməliyyat qeydləri olan böyük verilənlər bazası isə bir neçə saat çəkə bilər. Səhv qeydlərində göstərilən vaxt təxminləri çox vaxt qeyri-dəqiq olur, buna görə də bunun əvəzinə irəliləyiş faizlərinə diqqət yetirin.

S: Dayanmaq olar SQL Server məlumatları itirmədən bərpa zamanı?

A: Dayanmaq SQL Server bərpa zamanı ümumiyyətlə təhlükəsizdir, lakin xidmət yenidən başladıqda bərpa prosesini əvvəldən yenidən başladacaq. Bu, ümumi bərpa müddətini uzadır, lakin orijinal hadisə zamanı baş verənlərdən əlavə əlavə məlumat itkisinə səbəb olmur.

S: "Bərpada" və "Bərpa Gözləmədədir" arasındakı fərq nədir?

A: “Bərpada” deməkdir SQL Server bərpa əməliyyatlarını aktiv şəkildə həyata keçirir. “Bərpa Gözlənilir” bərpa prosesinin başlamadığını göstərir, bu, adətən faylların çatışmazlığı, qeyri-kafi icazələr və ya bərpa prosesinin davam etməsindən əvvəl həll edilməli olan disk sahəsi problemləri səbəbindən baş vermir.

“Bərpa Gözləmədədir” haqqında daha ətraflı məlumatı bizim səhifəmizdə tapa bilərsiniz ətraflı guide.

S: REPAIR_ALLOW_DATA_LOSS istifadə etsəm, datanı itirəcəm?

A: Bəli, REPAIR_ALLOW_DATA_LOSS verilənlər bazası ardıcıllığını bərpa etmək üçün zədələnmiş məlumatları silə bilər. Həmişə əvvəlcə məlumat itkisi olmadan struktur problemləri həll edən REPAIR_REBUILD cəhd edin. REPAIR_ALLOW_DATA_LOSS-dan yalnız başqa bərpa seçimləriniz olmadıqda son çarə kimi istifadə edin.

S: Bir verilənlər bazası bərpa olunarkən mən digər verilənlər bazalarına daxil ola bilərəmmi?

A: Bəli, digər verilənlər bazaları eynidir SQL Server nümunə bərpa zamanı əlçatan qalır. Yalnız bərpa olunan verilənlər bazası əlçatan deyil. Bununla belə, bərpa əməliyyatları ümumi server performansına təsir göstərə bilər.

S: Verilənlər bazasının bərpa rejimində ilişib qalmasına nə səbəb olur?

Cavab: Ümumi səbəblərə NORECOVERY-dən istifadə edərək natamam bərpa əməliyyatları, həddindən artıq Virtual Qeyd Faylları (VLF), böyük ölçüdə həyata keçirilməmiş əməliyyatlar, verilənlər bazası korlanması, qeyri-kafi disk sahəsi və aparat problemləri daxildir. AVTO BAĞLAMASI aktivləşdirilmiş verilənlər bazaları da daim bərpaya daxil ola bilər.

S: Bərpa prosesində irəliləyişin olub-olmadığını necə bilə bilərəm?

A: Monitor SQL Server Tamamlanma faizlərini göstərən bərpa irəliləyişi mesajları üçün səhv qeydləri. Aktiv DB STARTUP əmrlərini yoxlamaq üçün sys.dm_exec_requests istifadə edin. Faizlər zamanla artarsa, bərpa irəliləyir. Bir neçə saat ərzində yeni qeyd qeydlərinin olmaması prosesin ilişib qaldığını göstərə bilər.

S: Yenidən başlatmaq təhlükəsizdirmi? SQL Server bərpa zamanı xidmət?

A: Yenidən başlatma təhlükəsizdir, lakin ehtiyatla istifadə edilməlidir. Bu, bərpanı əvvəldən başladacaq və bərpa müddətini ikiqat artıra bilər. Yalnız bərpa bir neçə saat ərzində heç bir irəliləyiş olmadan tamamilə donmuş kimi göründüyü və ya prosesin həqiqətən ilişib qaldığından şübhələndiyiniz təqdirdə yenidən başladın.

S: AVTO BAĞLAMA ilə bərpa rejimi arasında fərq nədir?

A: AUTO CLOSE heç bir əlaqə olmadıqda verilənlər bazalarını avtomatik bağlayır, sonra onları yeni bağlantılar üçün yenidən açır. Bu təkrar açılma hər dəfə qısa bərpa proseslərini işə salaraq verilənlər bazasının daim bərpa olunduğunu göstərir. AVTO BAĞLAMA-nın deaktiv edilməsi bu problemi həll edir.

S: Əməliyyat jurnalının ehtiyat nüsxələri bərpa zamanı kömək edə bilərmi?

A: Əməliyyat jurnalının ehtiyat nüsxələri jurnal diski dolu olduqda jurnal yerini boşalda bilər və bu da bərpanın davam etməsinə imkan verə bilər. Lakin, hazırda bərpa rejimində olan verilənlər bazasının jurnalının ehtiyat nüsxəsini çıxara bilməzsiniz. Jurnal ehtiyat nüsxələri qarşısının alınması və bərpa sonrası texniki xidmət üçün daha faydalıdır.

S: Microsoft Dəstəyi ilə nə vaxt əlaqə saxlamalıyam?

A: Daxili bərpa üsullarının uğursuz olduğu, şübhələndiyiniz zaman kritik istehsal sistemləri üçün Microsoft Dəstəyi ilə əlaqə saxlayın SQL Server kompleks Always On və ya klasterləşdirmə ssenariləri üçün və ya müəssisə mühitləri minimal fasilələrlə zəmanətli məlumatların bərpasını tələb etdikdə proqram xətaları.

S: Verilənlər bazalarının bərpa prosesində ilişib qalmasının qarşısını necə ala bilərəm?

Cavab: Müntəzəm tam və log ehtiyat nüsxələrini həyata keçirin, VLF saylarına nəzarət edin və idarə edin, adekvat disk sahəsini təmin edin, düzgün bağlanma prosedurlarından istifadə edin, avadanlığın etibarlılığını qoruyun, istehsal verilənlər bazalarında AVTOMAL QAPATMA-nı söndürün və korrupsiyanı erkən aşkar etmək üçün müntəzəm DBCC CHECKDB əməliyyatlarını icra edin.

S: VLF-lər nədir və onlar niyə bərpaya təsir edir?

A: Virtual Log Files (VLFs) əməliyyat jurnalı faylları daxilində daxili seqmentlərdir. Həddindən artıq çox VLF (1,000-dən çox) bərpanı əhəmiyyətli dərəcədə yavaşlatır, çünki SQL Server hər birini ayrıca emal etməlidir. Düzgün log faylı ölçüsü və böyümə parametrləri optimal VLF saylarını saxlamağa kömək edir.

S: Verilənlər bazası bərpa olunarkən ehtiyat nüsxədən bərpa edə bilərəmmi?

Cavab: Hazırda bərpa rejimində olan verilənlər bazası üzərindən bərpa edə bilməzsiniz. Siz ya bərpanın tamamlanmasını gözləməli, ya da dayandırmalısınız SQL Server xidmət və ya başqa verilənlər bazası adına bərpa edin. Təcili hallar üçün, yeni verilənlər bazası adına bərpa etməyi və bərpa məsələləri həll edildikdən sonra onun adını dəyişməyi düşünün.

17. Nəticə və sonrakı addımlar

17.1 Əsas həllərin xülasəsi

Zaman SQL Server Verilənlər bazası bərpa mərhələsindədirsə, bu yanaşmalarla başlayın:

Səhv qeydlərini yoxlayın və tərəqqiyə nəzarət edin
Tərəqqi sabitdirsə, təbii tamamlanmanı gözləyin
Natamam bərpalar üçün BƏRPA İLƏ BƏRPA istifadə edin
Tranzaksiya jurnalı problemlərini həll edin
DBCC CHECKDB və ya korrupsiya üçün peşəkar alətləri işə salın
Ağır hallarda ehtiyat nüsxəsinin bərpasını nəzərdən keçirin

körpü SQL Server db bərpa vəziyyətlərində bu sübut edilmiş üsullardan istifadə edərək bir neçə saat ərzində həll olunur. Mürəkkəb ssenarilər üçün qabaqcıl texnika və ya peşəkar vasitələrdən istifadə etməkdən çəkinməyin.

17.2 Əlavə Resurslar

Əlavə yardım üçün:

microsoft SQL Server Documentation
SQL Server İcma Forumları
Verilənlər bazası idarəçiliyi bloqları və texniki resurslar
Professional verilənlər bazası bərpa xidmətləri

Mütəmadi texniki xidmət və monitorinq əksər bərpa problemlərinin qarşısını alır. Gələcəkdə bərpa problemlərində MS SQL-in baş verməsini minimuma endirmək üçün bu təlimatda göstərilən profilaktika təcrübələrini tətbiq edin.

Müəllif haqqında

Yuan Şenq sahəsində 10 ildən çox təcrübəsi olan baş verilənlər bazası administratorudur (DBA). SQL Server mühitlər və müəssisə verilənlər bazası idarə edilməsi. O, maliyyə xidmətləri, səhiyyə və istehsal təşkilatlarında yüzlərlə verilənlər bazası bərpa ssenarisini uğurla həll edib.

Yuan ixtisaslaşır SQL Server verilənlər bazası bərpası, yüksək əlçatanlıq həlləri və performansın optimallaşdırılması. Onun geniş praktiki təcrübəsinə çox terabaytlıq verilənlər bazalarının idarə edilməsi, Həmişə Əlçatımlılıq Qruplarının tətbiqi və kritik missiya sistemləri üçün avtomatlaşdırılmış ehtiyat nüsxə və bərpa strategiyalarının hazırlanması daxildir.

Texniki təcrübəsi və praktik yanaşması sayəsində Yuan verilənlər bazası administratorlarına və İT mütəxəssislərinə mürəkkəb problemləri həll etməyə kömək edən hərtərəfli bələdçilərin yaradılmasına diqqət yetirir. SQL Server problemlərini səmərəli həll edir. O, ən son xəbərlərdən xəbərdardır SQL Server relizlər və Microsoft-un inkişaf edən verilənlər bazası texnologiyaları, onun tövsiyələrinin real dünyanın ən yaxşı təcrübələrini əks etdirməsini təmin etmək üçün bərpa ssenarilərini müntəzəm olaraq sınaqdan keçirir.

haqqında suallarınız var SQL Server bərpası və ya əlavə verilənlər bazası problemlərinin aradan qaldırılması üçün təlimat lazımdır? Yuan salamlayır rəy və təkliflər bu texniki resursların təkmilləşdirilməsi üçün.

SQL Server Bərpa rejimində verilənlər bazası: 10 sübut edilmiş düzəliş [2026 bələdçisi]

1. Anlaşma SQL Server Verilənlər Bazasının Bərpa Rejimi

1.1 Bərpa rejimi nədir SQL Server