SQL Server Տվյալների բազան վերականգնման ռեժիմում. 10 ուղղում [2026]

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 Կառավարման ստուդիա
navigate to կառավարում -> 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. Օգտագործեք RESTORE DATABASE-ը RECOVERY-ով

Այս լուծումը լուծում է անավարտ վերականգնման գործողությունների հետ կապված խնդիրները, որոնց դեպքում բաց է թողնվել վերականգնման վերջնական քայլը։ Օգտագործեք սա, երբ ձեր SQL Server Վերականգնման մեջ գտնվող db-ն առաջացել է NORECOVERY-ի միջոցով վերականգնման գործընթացից։

5.1 Հրամանի հասկացումը

Վերականգնել տվյալների բազան վերականգնման միջոցով հրամանն ավարտում է վերականգնման գործընթացը՝ չեղարկելով չկատարված գործարքները և տվյալների բազան միացնելով առցանց։

5.2 Իրականացման քայլեր

բաց SQL Server Կառավարման ստուդիա
Միացեք ձեր SQL Server օրինակ
Սեղմել Նոր > Հարցում ընթացիկ կապով
Իրականացնել: RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
Սպասեք ավարտի հաստատմանը

Warning: Օգտագործեք այս հրամանը միայն այն դեպքում, եթե վստահ եք, որ վերականգնման լրացուցիչ գործողություններ չկան։

6. Լուծում #3. Լուծեք գործարքների գրանցամատյանի խնդիրները

Գործարքների գրանցամատյանի խնդիրները վերականգնման ժամանակի երկարացման հիմնական պատճառն են: Այս լուծումը լուծում է լիքը գրանցամատյանների, չափազանց շատ VLF-ների և գրանցամատյանի տարածքի խնդիրները, որոնք խանգարում են SQL Server վերականգնման մեջ։

6.1 Գործարքների գրանցամատյանների պահուստավորում

Ազատեք գրանցամատյանի տարածք՝ ստեղծելով գործարքների գրանցամատյանի պահուստային պատճեններ.

բաց SQL Server Կառավարման ստուդիա
Սեղմեք աջ մկնիկի կոճակը ձեր տվյալների բազայի վրա -> Խնդիրներ -> Վերադառնալ Up
Փոփոխություն Պահուստային պատճենի տեսակը դեպի Գործարքների գրանցամատյան
Նշեք պահուստավորման նպատակակետը
Սեղմել OK կատարել

6.2 Վիրտուալ գրանցամատյանների ֆայլերի (VLF) կառավարում

Ստուգեք VLF-ի քանակը հետևյալ կերպ՝

DBCC LOGINFO('YourDatabaseName');

Եթե ունեք 1,000-ից ավելի VLF, կրճատեք դրանք հետևյալ կերպ.

Գործարքների գրանցամատյանի պահուստավորում
Գրանցամատյանի ֆայլի կրճատում. DBCC SHRINKFILE(LogFileName, TRUNCATEONLY);
Գրանցամատյանի ֆայլի մեծ չափաբաժիններով (1 ԳԲ կամ ավելի) մեծացում

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-ի սովորական փորձերը: Այն նշում է տվյալների բազան որպես READ_ONLY և անջատում է գրանցումը: Օգտագործեք այս մոտեցումը, երբ ստանդարտ մուտքը ձախողվում է.

Արտակարգ իրավիճակների ռեժիմ սահմանելը. 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 հատկությունը

Տվյալների բազայի AUTO CLOSE հատկությունը կարող է կրկնվող վերականգնման ցիկլեր առաջացնել, ինչը տպավորություն է ստեղծում, որ ձեր SQL Server db-ն անընդհատ վերականգնման փուլում է։ Այս հատկությունը անջատելը կլուծի խնդիրը։

9.1 Ավտոմատ փակման խնդիրների ըմբռնումը

Երբ ԱՎՏՈՄԱՏ ՓԱԿՈՒՄԸ միացված է, SQL Server Վերջին կապի ավարտից հետո փակում է տվյալների բազան, ապա վերաբացնում այն նոր կապերի համար: Այս կրկնվող բացումը ամեն անգամ ակտիվացնում է վերականգնման գործընթացները:

9.2 Ավտոմատ փակման անջատում

բաց SQL Server Կառավարման ստուդիա
Սեղմեք աջ մկնիկի կոճակը ձեր տվյալների բազայի վրա -> Հատկություններ
ընտրել Ընտրանքներ ձախ վահանակից
հավաքածու Ավտոմատ փակում դեպի Կեղծ
Սեղմել OK փոփոխությունները կիրառելու համար

Այլընտրանքորեն, օգտագործեք T-SQL-ը.

ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;

10. Լուծում #7. Վերագործարկում SQL Server Ծառայությունների

Ծառայության վերագործարկումը կարող է լուծել վերականգնման գործընթացների խցանումը, բայց պետք է զգուշորեն օգտագործել, քանի որ այն վերականգնումը կվերագործարկի սկզբից: Այս լուծումը գործում է, երբ SQL Server վերականգնման փուլում թվում է լիովին սառեցված։

10.1 Երբ ծառայության վերագործարկումը օգնում է

Վերագործարկեք ծառայությունը, երբ՝

Վերականգնման գործընթացը մի քանի ժամով կանգ է առել
Սխալների գրանցամատյանները նոր գրառումներ չեն ցույց տալիս
Մյուս տվյալների բազաները բնականոն աշխատում են
Դուք կարող եք թույլ տալ ձեզ երկարաձգված դադար

10.2 Անվտանգ վերագործարկման ընթացակարգեր

բաց SQL Server Կազմաձևման կառավարիչ
navigate to 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;
Սա վերակառուցում է նոր գործարքների գրանցամատյան

Warning: Այս մեթոդը կարող է հանգեցնել տվյալների կորստի: Օգտագործեք միայն այն դեպքում, երբ մյուս տարբերակները սպառվել են:

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 Տվյալների բազայի վերականգնումը սովորաբար տևո՞ւմ է։

Ա. Վերականգնման ժամանակը կախված է տվյալների բազայի չափից, գործարքների ծավալից և սարքավորումների աշխատանքից: Փոքր տվյալների բազաները սովորաբար վերականգնվում են րոպեների ընթացքում, մինչդեռ մեծ տվյալների բազաները՝ ծավալուն գործարքների գրանցամատյաններով, կարող են տևել մի քանի ժամ: Սխալների գրանցամատյաններում ներկայացված ժամանակի գնահատականները հաճախ անճշտ են, ուստի կենտրոնացեք առաջընթացի տոկոսների վրա:

Հարց. Կարո՞ղ եմ դադարեցնել SQL Server վերականգնման ընթացքում՝ առանց տվյալների կորստի՞

Ա. Կանգ առնելը SQL Server Վերականգնման ընթացքում օգտագործումը, որպես կանոն, անվտանգ է, բայց վերականգնման գործընթացը կվերսկսվի սկզբից, երբ ծառայությունը վերագործարկվի: Սա երկարացնում է վերականգնման ընդհանուր ժամանակը, բայց չի առաջացնում լրացուցիչ տվյալների կորուստ՝ սկզբնական միջադեպի ժամանակ տեղի ունեցածից այն կողմ:

Հարց. Ի՞նչ տարբերություն կա «Վերականգնման փուլում» և «Վերականգնման սպասման փուլում» տարբերակների միջև:

Ա. «Վերականգնման փուլում» նշանակում է SQL Server ակտիվորեն կատարում է վերականգնման գործողություններ: «Վերականգնումը սպասող» նշումը նշանակում է, որ վերականգնման գործընթացը չի կարողացել սկսվել, սովորաբար ֆայլերի բացակայության, անբավարար թույլտվությունների կամ սկավառակի տարածքի հետ կապված խնդիրների պատճառով, որոնք պետք է լուծվեն վերականգնման շարունակությունից առաջ:

«Վերականգնման սպասման» մասին ավելի մանրամասն տեղեկություններ կարող եք գտնել մեր կայքում։ համապարփակ ուղեցույց.

Հարց. Կկորցնե՞մ արդյոք տվյալներ, եթե օգտագործեմ REPAIR_ALLOW_DATA_LOSS-ը:

Ա. Այո, REPAIR_ALLOW_DATA_LOSS-ը կարող է հեռացնել վնասված տվյալները՝ տվյալների բազայի համապատասխանությունը վերականգնելու համար: Միշտ նախ փորձեք REPAIR_REBUILD-ը, որը շտկում է կառուցվածքային խնդիրները՝ առանց տվյալների կորստի: Օգտագործեք REPAIR_ALLOW_DATA_LOSS-ը միայն որպես վերջին միջոց, երբ վերականգնման այլ տարբերակներ չունեք:

Հարց. Կարո՞ղ եմ մուտք գործել այլ տվյալների բազաներ, երբ մեկ տվյալների բազան վերականգնման փուլում է:

Ա. Այո, նույն տվյալների բազաներում կան նաև այլ տվյալներ։ SQL Server վերականգնման ընթացքում ինստանսը մնում է հասանելի։ Միայն վերականգնման փուլում գտնվող տվյալների բազան է անհասանելի։ Այնուամենայնիվ, վերականգնման գործողությունները կարող են ազդել սերվերի ընդհանուր աշխատանքի վրա։

Հարց. Ի՞նչն է պատճառը, որ տվյալների բազան կպչում է վերականգնման ռեժիմին:

Ա. Հաճախակի պատճառներից են NORECOVERY-ի միջոցով անավարտ վերականգնման գործողությունները, վիրտուալ գրանցամատյանների ֆայլերի (VLF) չափազանց մեծ քանակը, մեծ չհաստատված գործարքները, տվյալների բազայի վնասումը, սկավառակի տարածքի անբավարարությունը և սարքավորման հետ կապված խնդիրները: AUTO CLOSE-ը միացված տվյալների բազաները նույնպես կարող են անընդհատ մտնել վերականգնման գործընթաց:

Հարց. Ինչպե՞ս իմանամ, թե արդյոք վերականգնումը առաջընթաց է գրանցում, թե՞ կանգ է առել։

Ա. Մոնիտոր SQL Server Վերականգնման ընթացքի հաղորդագրությունների սխալի գրանցամատյաններ, որոնք ցույց են տալիս ավարտման տոկոսները: Օգտագործեք sys.dm_exec_requests-ը՝ ակտիվ տվյալների բազայի մեկնարկի հրամանների առկայությունը ստուգելու համար: Եթե տոկոսները ժամանակի ընթացքում աճում են, ապա վերականգնումը ընթացքի մեջ է: Մի քանի ժամվա ընթացքում նոր գրառումների բացակայությունը կարող է ցույց տալ գործընթացի խցանում:

Հարց. Անվտանգ է վերագործարկելը SQL Server ծառայություն վերականգնման ընթացքում՞

Ա. Վերագործարկումը անվտանգ է, բայց պետք է զգուշորեն օգտագործել: Այն վերականգնումը կվերագործարկի սկզբից, հնարավոր է՝ կրկնապատկելով վերականգնման ժամանակը: Վերագործարկեք միայն այն դեպքում, եթե վերականգնումը լիովին սառեցված է թվում՝ առանց առաջընթացի մի քանի ժամվա ընթացքում, կամ եթե կասկածում եք, որ գործընթացը իսկապես կանգ է առել:

Հարց. Ի՞նչ տարբերություն կա AUTO CLOSE-ի և վերականգնման ռեժիմի միջև:

Ա. ԱՎՏՈՄԱՏ ՓԱԿՈՒՄԸ ավտոմատ կերպով փակում է տվյալների բազաները, երբ կապեր չկան, ապա վերաբացնում է դրանք նոր կապերի համար: Այս կրկնվող բացումը ամեն անգամ ակտիվացնում է կարճ վերականգնման գործընթացներ, ինչը ստեղծում է տպավորություն, որ տվյալների բազան անընդհատ վերականգնման փուլում է: ԱՎՏՈՄԱՏ ՓԱԿՈՒՄԸ անջատելը լուծում է այս խնդիրը:

Հարց. Կարո՞ղ են գործարքների գրանցամատյանի պահուստային պատճենները օգնել վերականգնման ընթացքում:

Ա. Գործարքների գրանցամատյանի պահուստավորումը կարող է ազատել գրանցամատյանի տարածք, եթե գրանցամատյանի սկավառակը լիքն է, ինչը հնարավոր է թույլ տա շարունակել վերականգնումը: Այնուամենայնիվ, դուք չեք կարող պահուստավորել վերականգնման ռեժիմում գտնվող տվյալների բազայի գրանցամատյանը: Գրանցամատյանի պահուստավորումն ավելի օգտակար է կանխարգելման և վերականգնումից հետո սպասարկման համար:

Հարց. Ե՞րբ պետք է կապվեմ Microsoft-ի աջակցության հետ։

Ա. Կապվեք Microsoft-ի աջակցության հետ կարևոր արտադրական համակարգերի համար, որտեղ ներկառուցված վերականգնման մեթոդները չեն աշխատում, եթե կասկածում եք, որ SQL Server ծրագրային սխալներ, բարդ Always On կամ կլաստերացման սցենարների համար, կամ երբ ձեռնարկությունների միջավայրերը պահանջում են տվյալների երաշխավորված վերականգնում՝ նվազագույն դադարներով։

Հարց. Ինչպե՞ս կարող եմ կանխել տվյալների բազաների խցանումը վերականգնման գործընթացում:

Ա. Կատարեք կանոնավոր լրիվ և գրանցամատյանների պահուստավորում, վերահսկեք և կառավարեք VLF հաշվարկները, ապահովեք բավարար սկավառակի տարածք, օգտագործեք պատշաճ անջատման ընթացակարգեր, պահպանեք սարքավորումների հուսալիությունը, անջատեք AUTO CLOSE-ը արտադրական տվյալների բազաներում և կանոնավոր կերպով կատարեք DBCC CHECKDB գործողություններ՝ վնասը վաղ հայտնաբերելու համար:

Հարց. Ի՞նչ են VLF-ները և ինչո՞ւ են դրանք ազդում վերականգնման վրա:

Ա. Վիրտուալ գրանցամատյանների ֆայլերը (VLF) գործարքների գրանցամատյանների ֆայլերի ներքին հատվածներ են: VLF-ների չափազանց շատությունը (1,000-ից ավելի) զգալիորեն դանդաղեցնում է վերականգնումը, քանի որ SQL Server պետք է յուրաքանչյուրը մշակվի առանձին: Գրանցամատյանի ֆայլի չափսերի և աճի կարգավորումների ճիշտ ընտրությունը օգնում է պահպանել VLF-ի օպտիմալ հաշվարկները:

Հարց. Կարո՞ղ եմ վերականգնել պահուստային պատճենից, երբ տվյալների բազան վերականգնման փուլում է:

Ա. Դուք չեք կարող վերականգնել վերականգնման ռեժիմում գտնվող տվյալների բազայի միջոցով: Դուք պետք է կամ սպասեք վերականգնման ավարտին, կամ դադարեցնեք 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 տվյալների բազայի վերականգնում, բարձր մատչելիության լուծումներ և կատարողականի օպտիմալացում: Նրա լայնածավալ գործնական փորձը ներառում է բազմաբայթ ծավալով տվյալների բազաների կառավարում, միշտ հասանելի խմբերի ներդրում և կարևորագույն բիզնես համակարգերի համար ավտոմատացված պահուստավորման և վերականգնման ռազմավարությունների մշակում:

Իր տեխնիկական փորձագիտության և գործնական մոտեցման միջոցով Յուանը կենտրոնանում է համապարփակ ուղեցույցներ ստեղծելու վրա, որոնք կօգնեն տվյալների բազայի ադմինիստրատորներին և ՏՏ մասնագետներին լուծել բարդ խնդիրներ։ SQL Server արդյունավետորեն մարտահրավերներ է նետում։ Նա տեղեկացված է մնում վերջին նորություններից SQL Server թողարկումները և Microsoft-ի զարգացող տվյալների բազայի տեխնոլոգիաները, պարբերաբար փորձարկելով վերականգնման սցենարները՝ համոզվելու համար, որ նրա առաջարկությունները արտացոլում են իրական աշխարհի լավագույն փորձը։

Հարցեր ունեք SQL Server Վերականգնո՞ւմ, թե՞ անհրաժեշտ է տվյալների բազայի խնդիրների լուծման լրացուցիչ ուղեցույց: Յուանը ողջունում է ձեզ: արձագանքներ և առաջարկություններ այս տեխնիկական ռեսուրսները բարելավելու համար։

SQL Server Տվյալների բազան վերականգնման ռեժիմում. 10 ապացուցված լուծում [2026 թվականի ուղեցույց]