SQL datubāzes atkopšana gaida: 15 pārbaudīti labojumi [2026]

Kad jūsu SQL datubāze iestrēgst atkopšanas gaidīšanas stāvoklī, tā kļūst nepieejama un tās darbības tiek apturētas. Šajā visaptverošajā rokasgrāmatā ir sniegtas 15 pārbaudītas metodes, kā atrisināt SQL datubāzes atkopšanas gaidīšanas problēmas, sākot no vienkāršas atkopšanastarts uz sarežģītiem avārijas remontiem.

1. SQL datubāzes atkopšanas gaidīšanas stāvokļa izpratne

Pirms jebkādu labojumu veikšanas ir svarīgi saprast, kas izraisa SQL datubāzes atkopšanas problēmas, lai izvēlētos pareizo risinājumu.

1.1 Ko nozīmē “Atgūšanas process”?

Atgūšanas gaidīšana norāda, ka SQL Server atpazīst, ka datubāze ir jāatjauno, bet nevar atjaunottaratkopšanas procesu. Atšķirībā no “Atkopšana”, kas rāda notiekošu aktīvu atkopšanu, “Atkopšana gaida” nozīmē, ka atkopšanu bloķē šķērslis.

Galvenie datubāzes stāvokļi ietver:

ONLINE – Normāls darbības stāvoklis
ATVĒROŠANĀS – Aktīvi notiek atkopšanas process
ATJAUNOŠANA NAV IZSKATĪTA – Atgūšana nav iespējamatart
AIZDODĪGI – Datubāzē ir kritiskas kļūdas
ĀRKĀRTAS – Ierobežota piekļuve tikai lasīšanai remontam
BEZSAISTĒ – Manuāli noņemts bezsaistē

1.2 Biežākie SQL datubāzes atkopšanas gaidīšanas cēloņi

SQL datubāzes atkopšanas gaidīšanas problēmas parasti rodas šādu izplatītu iemeslu dēļ:

Trūkstoši vai bojāti darījumu žurnāla faili (LDF)
Nepietiek vietas diskā atkopšanas darbību laikā
Aparatūras kļūmes un negaidītas sistēmas izslēgšanas
Bojāti MDF datubāzes faili
Failu atļauju problēmas, kas neļauj piekļūt
SQL Server pakalpojumitarproblēmas ar laika noteikšanu
FILESTREAM konfigurācijas kļūdas
Nepareizi failu ceļi pēc servera migrācijas

1.3 Kā pārbaudīt datubāzes stāvokli

Pārbaudiet datubāzes stāvokli, izmantojot šīs metodes:

Izmantojot SQL Server Vadības studija:

Pievienojieties savam SQL Server piemērs
paplašināt Datubāzes mape
Meklējiet datubāzes, kurās ir redzams statuss “(Atkopšana gaida)”

Izmantojot T-SQL komandu:

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

2. Sākotnējā diagnozeostic soļi

Pirms jebkādu SQL datubāzes atkopšanas, gaidot labojumus, ir svarīgi veikt pareizu diagnostiku.

2.1 Pārbaudiet SQL Server Kļūdu žurnāli

Kļūdu žurnālos ir ietverta svarīga informācija par to, kas izraisīja atkopšanas gaidīšanas stāvokli.

atvērts SQL Server Vadības studija
Virzīties uz vadība -> SQL Server Baļķi
Veiciet dubultklikšķi uz pašreizējā žurnāla, lai skatītu jaunākās kļūdas
Meklējiet kļūdu ziņojumus, kas saistīti ar jūsu datubāzi

Varat arī izmantot T-SQL:

EXEC sp_readerrorlog;

2.2 Pārbaudiet Windows notikumu žurnālus

prese Windows atslēga + R
Veids eventvwr.msc un nospiediet taustiņu Enter
Virzīties uz Windows Baļķi -> sistēma un iesniegums
Meklējiet SQL Server saistītās kļūdas ap problēmas rašanās laiku

2.3 Faila pieejamības pārbaude

Pārejiet uz datubāzes failu atrašanās vietām
Pārliecinieties, vai pastāv gan MDF, gan LDF faili
Pārbaudiet, vai diski ir tiešsaistē un pieejami
Pārliecinieties, vai tīkla diski ir pareizi pievienoti

3. 1. labojums: Rez.tart SQL Server Pakalpojumi

RestarTing SQL Server pakalpojumi atrisina daudzas SQL datubāzes atkopšanas problēmas, ko izraisa laika problēmas vai tempsrary resursu konflikti.

3.1 Kad pakalpojums tiek atjaunotstart Darbojas

Šī metode ir efektīva, ja:

Laiksrary resursu bloķēšana s laikātarcaurule
Diska pieejamības kavēšanās
Pakalpojuma atkarības laika problēmas
Nelieli konfigurācijas konflikti

3.2 Kā veikt izpētitart SQL Server Pakalpojumi

Metode 1: SQL Server Konfigurācijas pārvaldnieks

atvērts SQL Server Konfigurācijas pārvaldnieks
Noklikšķiniet SQL Server Pakalpojumi
Ar peles labo pogu noklikšķiniet uz SQL Server piemēram, SQL Server (MSSQLSERVER)
Izvēlēties Restarts
Pagaidiet, līdz pakalpojums pilnībā atjaunojastart

2. metode: pakalpojumu konsole

prese Windows atslēga + R
Veids services.msc un nospiediet taustiņu Enter
Atrodi SQL Server piemēram, SQL Server (MSSQLSERVER)
Ar peles labo pogu noklikšķiniet uz un izvēlieties Restarts

3. metode: PowerShell

Restart-Service -Name "MSSQLSERVER" -Force

3.3 Post-Rez.tart Verifikācija

Pagaidiet 2–3 minūtes, līdz viss ir pabeigts.tarcaurule
Pārbaudiet datubāzes statusu SSMS
Pārbaudiet kļūdu žurnālus, lai uzzinātu par visiem jaunajiem ziņojumiem
Testa datubāzes savienojamība

4. 2. labojums: pārbaudiet un atrisiniet diska vietas problēmas

Nepietiekama diska vieta ir bieži sastopams SQL datubāzes atkopšanas gaidīšanas problēmu cēlonis. Atkopšanas darbībām ir nepieciešama papildu vieta pagaidu darbplūsmai.rary faili un žurnāla pieaugums.

4.1 Diska vietas problēmu identificēšana

atvērts File Explorer
Navigācija uz diskdziņiem, kuros ir datubāzes faili
Pārbaudiet pieejamo brīvo vietu
Nodrošiniet vismaz 10–20 % brīvas vietas atjaunošanas darbībām

4.2 Diska vietas atbrīvošana

Izdzēsiet nevajadzīgo tempurary faili
skaidrs SQL Server dublējuma faili, ja vietas ziņā kritiski svarīgi
Pārvietojiet nevajadzīgos failus uz citiem diskdziņiem
Ja iespējams, samaziniet citus datubāzes failus

Samazināt datubāzes failus (lietojiet uzmanīgi):

DBCC SHRINKFILE (logicalfilename, target_size);

4.3 Datubāzes iestatīšana tiešsaistē pēc vietas labošanas

Kad būs pieejama brīva vieta, mēģiniet datubāzi padarīt pieejamu tiešsaistē:

ALTER DATABASE [DatabaseName] SET ONLINE;

5. 3. labojums: Iestatīt SQL Server Pakalpojums aizkavētajam Start

Iestatīšana SQL Server uz aizkavētu start atrisina SQL datubāzes atkopšanas gaidīšanas problēmas, ko izraisa krātuves sistēmas vai tīkla diski, kas nav gatavi sistēmas sāknēšanas laikā.

5.1 Laika problēmu izpratne

Laika problēmas rodas, ja:

SAN vai tīkla krātuves inicializācijai nepieciešams laiks.
Diska burti netiek piešķirti agrīnās palaišanas laikā
Tīkla diskdziņiem ir nepieciešama autentifikācija
Krātuves kontrolleriem ir nepieciešams inicializācijas laiks

5.2 Aizkavētās S konfigurēšanatart

prese Windows atslēga + R
Veids services.msc un nospiediet taustiņu Enter
Atrodi SQL Server piemēram, SQL Server (MSSQLSERVER)
Ar peles labo pogu noklikšķiniet uz un izvēlieties īpašības
Mainīt Startupa tips uz Automātiski (Aizkavēta Start)
Noklikšķiniet OK
Restart sistēma, kas jāpārbauda

5.3 Alternatīvi laika noteikšanas risinājumi

Lai iegūtu lielāku kontroli, izveidojiet ieplānotu uzdevumu:

atvērts uzdevumu plānotājs
Noklikšķiniet Darbība -> Izveidot pamata uzdevumu
Ievadiet Vārds un Apraksts uzdevuma, piemēram, “Aizkavēšanās”tart no SQL Server apkalpošana"
Noteikt Trigger uz Kad dators starts
Noteikt Darbība uz Starta programma
Noteikt Programma / Script uz pilnu ceļu Sqlservr.exe, piemēram: C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Binn\sqlservr.exe. To var atrast, izmantojot Windows meklēšanas funkciju.
Pabeigšanas lapā atlasiet Noklikšķinot uz Pabeigt, atveriet šī uzdevuma dialoglodziņu Rekvizīti.
Noklikšķiniet apdare.
Uzdevuma rekvizītu dialoglodziņā noklikšķiniet uz Trigeru tab
Atlasiet sprūdu un noklikšķiniet uz rediģēt
Papildu iestatījumos atzīmējiet Atlikt uzdevumu: un iestatiet laiku uz 3 minūtēm.
Noklikšķiniet Labi.

6. 4. labojums: failu atļauju un piekļuves tiesību labošana

Atļauju problēmas neļauj SQL Server piekļūt datubāzes failiem, kā rezultātā SQL datubāzes atkopšanas gaidīšanas stāvokļi tiek bloķēti. Pareizas failu atļaujas ir būtiskas datubāzes darbībām.

6.1 Bieži sastopamās atļauju problēmas

SQL Server pakalpojuma kontam nav failu piekļuves tiesību
Antivīrusu programmatūra bloķē piekļuvi failiem
Mainītas drošības politikas
Tīkla koplietošanas atļauju problēmas

6.2 Mapes atļauju labošana

Navigācija uz datubāzes failu mapi
Ar peles labo pogu noklikšķiniet uz mapes un atlasiet īpašības
Noklikšķiniet Drošība tab
Noklikšķiniet rediģēt
Pievienot SQL Server pakalpojuma konts, ja tā trūkst
Grant Pilnīga kontrole Atļaujas
Noklikšķiniet OK lai lietotu izmaiņas

Izmantojot komandrindu (icacls):

icacls "C:\Data" /grant "NT SERVICE\MSSQLSERVER":F /T

6.3 Pakalpojuma konta apsvērumi

Pārbaudiet SQL Server pakalpojuma konts:

atvērts SQL Server Konfigurācijas pārvaldnieks
Noklikšķiniet SQL Server Pakalpojumi
Piezīme Pieslēgties kā kontu SQL Server
Pārliecinieties, vai šim kontam ir atbilstošas atļaujas

7. 5. labojums: manuāla faila ceļa korekcija

Failu ceļa problēmas rodas, pārvietojot datubāzes failus vai mainot disku burtus. Šī metode atjaunina SQL Serveriekšējās failu atsauces, nepārvietojot pašus failus.

7.1 Kad rodas ceļa problēmas

Servera aparatūras izmaiņas
Diska burta atkārtota piešķiršana
Tīkla ceļa modifikācijas
Datu bāzes failu pārvietošana

7.2 Failu ceļu labošana

Identificējiet pašreizējos failu ceļus kļūdu žurnālos
Atrodiet faktiskos datubāzes failus
Izmantojiet ALTER DATABASE, lai atjauninātu ceļus

Atjaunināt datu faila ceļu:

ALTER DATABASE [DatabaseName] 
MODIFY FILE (NAME = 'LogicalDataFileName', FILENAME = 'C:\NewPath\DatabaseName.mdf');

Atjaunināšanas žurnālfaila ceļš:

ALTER DATABASE [DatabaseName] 
MODIFY FILE (NAME = 'LogicalLogFileName', FILENAME = 'C:\NewPath\DatabaseName_Log.ldf');

7.3 Verifikācijas soļi

Restart SQL Server apkalpošana
Pārbaudiet datubāzes statusu
Pārbaudiet kļūdu žurnālus, lai atrastu ar ceļu saistītus ziņojumus
Testa datubāzes savienojamība

8. 6. labojums: paņemiet datubāzi bezsaistē un pēc tam tiešsaistē

Šīs vienkāršās stāvokļa izmaiņas var atrisināt nelielas SQL datubāzes atkopšanas problēmas, piespiežot tīru stāvokļa pāreju un notīrot tempu.rary slēdzenes.

8.1 Kad šī metode darbojas

Nelielas neatbilstības valsts līmenī
Laiksrary resursu slēdzenes
Vienkārša atkopšanas procesa atiestatīšana
Nekritiski kļūdu stāvokļi

8.2 Bezsaistes/tiešsaistes procedūra

Pārliecinieties, vai nav aktīvu savienojumu ar datubāzi
Izpildiet bezsaistes komandu
Pagaidiet dažas sekundes
Izpildiet tiešsaistes komandu

Droša metode (gaida, kamēr savienojumi tiks aizvērti):

ALTER DATABASE [DatabaseName] SET OFFLINE;
ALTER DATABASE [DatabaseName] SET ONLINE;

Tūlītēja metode (pārtrauc savienojumus):

ALTER DATABASE [DatabaseName] SET OFFLINE WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [DatabaseName] SET ONLINE;

8.3 Riski un apsvērumi

Brīdinājums: Izmantojot ROLLBACK IMMEDIATE, var tikt zaudēti dati no neapstiprinātām transakcijām. Izmantojiet to tikai nepieciešamības gadījumā un pārliecinieties, vai lietotāji ir izrakstījušies.

9. 7. labojums: atspējojiet automātiskās aizvēršanas funkciju

Automātiskās aizvēršanas funkcija var izraisīt SQL datubāzes atkopšanas gaidīšanas problēmas, ja datubāzes bieži tiek atvērtas un aizvērtas, radot laika konfliktus atkopšanas darbību laikā.

9.1 Automātiskās aizvēršanās ietekmes izpratne

Datubāze tiek aizvērta pēc pēdējā lietotāja atvienošanās.
Jāatjauno katru reizi, kad tiek atvērta datubāze
Izveido biežus atveseļošanās ciklus
Var traucēt citām darbībām

9.2 Automātiskās aizvēršanas atspējošana

Izmantojot T-SQL:

ALTER DATABASE [DatabaseName] SET AUTO_CLOSE OFF;

Izmantojot SQL Server Vadības studija:

Ar peles labo pogu noklikšķiniet uz datubāzes
Izvēlēties īpašības
Doties uz opcijas lappuse
Noteikt Automātiska aizvēršana uz Nepatiess
Noklikšķiniet OK

9.3 Saistītie automātiskie iestatījumi

Apsveriet arī iespēju atspējot AUTO_SHRINK, lai uzlabotu veiktspēju:

ALTER DATABASE [DatabaseName] SET AUTO_SHRINK OFF;

10. 8. labojums: izdzēsiet bojātu žurnālfailu un atjaunojiet to.tart

Šī metode darbojas, ja darījumu žurnāla fails ir nopietni bojāts un to nav iespējams salabot. To drīkst izmantot tikai izstrādes vidē vai gadījumos, kad datu zudums ir pieņemams.

10.1 Kad žurnāla dzēšana ir piemērota

⚠️ SVARĪGS BRĪDINĀJUMS: Šī metode izraisa datu zudumu!

Lietojiet tikai tad, ja:

Darbs ar izstrādes/testēšanas datubāzēm
Žurnālfails ir pilnībā bojāts
Citas atkopšanas iespējas nav
Ir pieejamas jaunākās dublējumkopijas

10.2 Žurnālfaila dzēšanas procedūra

apstāties SQL Server pilnībā apkalpot
Navigācija uz datubāzes faila atrašanās vietu
Dzēst .LDF failu (paturēt .MDF failu)
Start SQL Server apkalpošana
SQL Server automātiski izveidos jaunu žurnālfailu

10.3. Svarīgi brīdinājumi

Datu zuduma sekas:

Visas neapstiprinātās transakcijas ir lost pastāvīgi
Žurnāla ķēde ir bojāta — diferenciālās dublējumkopijas nav derīgas
Atgūšana noteiktā laika momentā kļūst neiespējama
Lietot tikai neražošanas vidē

11. 9. labojums: atvienojiet un atkārtoti pievienojiet datubāzi

Spēku atdalīšana un atkārtota piestiprināšana SQL Server lai atjaunotu trūkstošus vai bojātus žurnālfailus. Šī metode var atrisināt SQL datubāzes atkopšanas problēmas, ja žurnālfaili ir problemātiski.

11.1 Kad atvienošana/atkārtota piestiprināšana darbojas

Trūkstošie žurnālfaili
Bojātas žurnālfaila galvenes
Žurnālfaila ceļa izmaiņas
Vienkārši korupcijas scenāriji

11.2 Standarta atvienošanas/atkārtotas piestiprināšanas procedūra

Vispirms iestatiet datubāzi avārijas režīmā
Pārslēgties uz vairāku lietotāju režīmu
Atvienot datubāzi
Atkārtoti piestiprināt, izmantojot tikai MDF failu

-- Set to emergency mode
ALTER DATABASE [DatabaseName] SET EMERGENCY;
ALTER DATABASE [DatabaseName] SET MULTI_USER;

-- Detach database
EXEC sp_detach_db '[DatabaseName]';

-- Re-attach with single file (MDF only)
EXEC sp_attach_single_file_db 
    @DBName = '[DatabaseName]', 
    @physname = N'C:\Data\DatabaseName.mdf';

11.3 Alternatīvas pievienošanas metodes

Vairāku failu scenārijiem:

CREATE DATABASE [DatabaseName] 
ON (FILENAME = 'C:\Data\DatabaseName.mdf'),
   (FILENAME = 'C:\Data\DatabaseName_2.ndf')
FOR ATTACH;

12. 10. labojums: Atjaunojiet darījumu žurnāla failus

Žurnāla atjaunošanas laikā tiek izveidots jauns darījumu žurnāla fails, ja oriģināls ir pazudis vai neatgriezeniski bojāts. Šī metode atrisina SQL datubāzes atkopšanas problēmas, taču rezultātā tiek zaudēti dati.

12.1 Kad nepieciešama žurnāla pārbūve

Trūkstoši LDF faili pēc aparatūras kļūmes
Ļoti bojāti darījumu žurnāli
Žurnālfaila ceļa izmaiņas, kuras nevar labot
Ārkārtas atkopšanas situācijas

12.2 Žurnāla atjaunošanas process

⚠️ BRĪDINĀJUMS: Tas izraisa datu zudumu!

Iestatīt datubāzi avārijas režīmā
Izmantojiet REBUILD LOG komandu
Norādiet jaunu žurnālfaila atrašanās vietu
Pārvietot datubāzi tiešsaistē

ALTER DATABASE [DatabaseName] SET EMERGENCY;
GO

ALTER DATABASE [DatabaseName] REBUILD LOG ON 
(NAME = 'DatabaseName_Log', FILENAME = 'C:\Logs\DatabaseName_Log.ldf');
GO

ALTER DATABASE [DatabaseName] SET ONLINE;
GO

12.3 Datu zuduma seku izpratne

Žurnāla atjaunošanas cēloņi:

Visu neapstiprināto darījumu zaudēšana
Bojāti žurnāla secības numuri
Nespēja lietot turpmākās žurnālu dublējumkopijas
Atgūšana noteiktā laika momentā kļūst neiespējama

13. 11. labojums: avārijas režīma remonts ar DBCC PĀRBAUDE

Avārijas režīma labošana ir pēdējās iespējas metode SQL datubāzes atkopšanai, ja rodas problēmas, ko izraisījuši bojājumi. Šī metode var labot datubāzes, taču var izraisīt ievērojamu datu zudumu.

13.1 Avārijas režīma izpratne

⚠️ ĀRKĀRTĒJS BRĪDINĀJUMS: Augsts datu zaudēšanas risks!

Izmantojiet avārijas režīmu tikai šādos gadījumos:

Visas pārējās metodes ir bijušas neveiksmīgas
Nav pieejamas nesen izveidotas dublējumkopijas
Daļa datu atgūšanas ir labāka nekā pilnīga datu zaudēšana
Datu bāze ir kritiski bojāta

13.2 Avārijas remonta procedūra

Vispirms izveidojiet bojātu datubāzes failu dublējumu
Iestatīt datubāzi avārijas režīmā
Pārslēgties uz viena lietotāja režīmu
Palaist CHECKDB ar labošanas opciju
Atgriezties vairāku lietotāju režīmā

-- Step 1: Set to emergency mode
ALTER DATABASE [DatabaseName] SET EMERGENCY;
GO

-- Step 2: Single user mode
ALTER DATABASE [DatabaseName] SET SINGLE_USER;
GO

-- Step 3: Repair with no data loss
DBCC CHECKDB ([DatabaseName], REPAIR_REBUILD) WITH ALL_ERRORMSGS;
GO

-- Step 4: Return to multi-user
ALTER DATABASE [DatabaseName] SET MULTI_USER;
GO

13.3 Post-Remonta novērtējums

Pārskatīt CHECKDB izvadi, lai veiktu labošanas darbības
Pārbaudiet, vai trūkst tabulu vai datu
Pārbaudiet kritisko lietojumprogrammu funkcionalitāti
Apsveriet atjaunošanu no dublējuma, ja datu ir par daudz.ost

14. 12. labojums: pārbaudiet un labojiet FILESTREAM konfigurāciju

FILESTREAM konfigurācijas problēmas var izraisīt SQL datubāzes atkopšanas gaidīšanas problēmas. Šī metode novērš ar FILESTREAM saistītas atkopšanas kļūmes.

14.1 Ar FILESTREAM saistītas atkopšanas problēmas

FILESTREAM draivera savienojuma kļūmes
Konfigurācijas neatbilstības starp SQL Server un OS
Laika problēmas pakalpojumu laikātarcaurule
Atļauju problēmas ar FILESTREAM konteineriem

14.2 FILESTREAM problēmu novēršana

Pārbaudiet FILESTREAM konfigurācijas līmeni
Pārliecinieties, vai Windows funkcija ir iespējota
Restarnepieciešamie pakalpojumi
Pārbaudiet FILESTREAM konteinera atļaujas

Pārbaudiet FILESTREAM konfigurāciju:

SELECT SERVERPROPERTY('FilestreamEffectiveLevel') AS CurrentLevel;

Iespējot FILESTREAM instances līmenī:

EXEC sp_configure 'filestream access level', 2;
RECONFIGURE;

14.3 FILESTREAM labākā prakse

Nodrošināt konsekventu konfigurāciju visos resursostarts
Pārbaudiet, vai FILESTREAM konteineru ceļi ir pieejami.
Pārbaudiet, vai Windows FILESTREAM funkcija ir pareizi iespējota.
Uzraudzīt ar FILESTREAM saistītus kļūdu ziņojumus

15. Labojums Nr. 13: atjaunināšana SQL Server Versija/servisa pakotnes

Vecāks SQL Server versijās, īpaši RTM laidienos, ir zināmas kļūdas, kas rada problēmas ar SQL datubāzes atkopšanu, gaidot gaidīšanas režīmu. Atjaunināšana uz jaunākajām servisa pakotnēm novērš šīs problēmas.

15.1 Zināmas problēmas vecākās versijās

SQL Server 2005. gada RTM atkopšanas kļūdas
Servisa pakotnei specifiski labojumi atkopšanas procesiem
Kumulatīvie atjauninājumi, kas risina problēmas
Saderības problēmas ar jaunākām Windows versijām

15.2 Atjaunināšanas process

Pārbaudiet strāvu SQL Server versija
Atrodiet jaunāko pieejamo servisa pakotni
Lejupielādēt no Microsoft lejupielādes centrs
Plānot apkopes periodu
Instalējiet servisa pakotni
Restart pakalpojumi
Pārbaudiet datubāzes funkcionalitāti

Pārbaudiet pašreizējo versiju:

SELECT @@VERSION;

15.3 Post-Atjaunināt verifikāciju

Apstipriniet, ka versijas numurs ir mainīts
Pārbaudiet, vai visas datubāzes ir pareizi pieejamas tiešsaistē.
Veikt pamata funkcionalitātes testus
Pārraugiet kļūdu žurnālus, lai atklātu jaunas problēmas

16. 14. labojums: atjaunojiet datubāzi no dublējuma

Ja SQL datubāzes atkopšanas neatrisinātās problēmas nevar atrisināt, izmantojot labošanas metodes, atjaunošana no zināmas, labas rezerves kopijas nodrošina most Uzticams risinājums ar paredzamām datu zuduma robežām.

16.1 Kad risinājums ir dublējuma atjaunošana

Vairāki remonta mēģinājumi ir bijuši neveiksmīgi
Kritiskiem ražošanas datiem nepieciešama pārliecība
Pastāv pieņemams datu zuduma logs
Korupcija ir pārāk plaša, lai to labotu

16.2 Pilns datubāzes atjaunošanas process

Identificējiet most nesen izmantojama dublējuma
Nodrošiniet pietiekamu diska vietu atjaunošanai
Izņemiet datubāzi no tīkla vai, ja nepieciešams, atvienojiet to
Atjaunot no dublējuma faila
Lietot žurnālu dublējumkopijas, ja tādas ir pieejamas

Pamata atjaunošana no pilnas dublējuma:

RESTORE DATABASE [DatabaseName] 
FROM DISK = 'C:\Backups\DatabaseName.bak'
WITH REPLACE;

Atjaunošana ar žurnālu dublējumkopijām atkopšanai noteiktā laika punktā:

RESTORE DATABASE [DatabaseName] 
FROM DISK = 'C:\Backups\DatabaseName.bak'
WITH NORECOVERY, REPLACE;

RESTORE LOG [DatabaseName] 
FROM DISK = 'C:\Backups\DatabaseName_Log.trn'
WITH RECOVERY;

16.3. Verifikācija un testēšana

Pārbaudiet, vai datubāze ir veiksmīgi tiešsaistē
Pārbaudiet datu integritāti, izmantojot CHECKDB
Pārbaudiet kritiskās lietojumprogrammu funkcijas
Apstipriniet, ka dublēšana/atjaunošana ir pabeigta bez kļūdām

16.4 Atsauce

Vairāk informācijas varat uzzināt no mūsu visaptveroša rokasgrāmata par dublēšanu un atjaunošanu SQL Server datu bāzes.

17. 15. labojums: profesionāli SQL atkopšanas rīki

Ja manuālas metodes neizdodas atrisināt SQL datubāzes atkopšanas neatrisinātās problēmas, specializēta atkopšanas programmatūra var iegūt datus no nopietni bojātām datubāzēm, kuras nevar labot ar standarta metodēm.

17.1 Kad apsvērt trešo pušu rīkus

Nopietna korupcija, kas pārsniedz manuālas labošanas iespējas
Kritiski svarīgi dati bez pieejamām dublējumkopijām
Vairāki neveiksmīgi manuālas remonta mēģinājumi
Laika ziņā kritiskas atkopšanas prasības

17.2 DataNumen SQL Recovery

DataNumen SQL Recovery ir spēcīgs SQL Server datubāzes atkopšanas rīks.

Tālāk ir norādītas darbības, kā to izmantot.

Apturiet SQL Server Pakalpojumu.
Izveidojiet datubāzes failu kopijas, kas atrodas atkopšanas gaidīšanas stāvoklī, tostarp gan primāro MDF failu, gan sekundāros NDF failus.
Start SQL Server Pakalpojumu.
Start DataNumen SQL Recovery.
Kā atgūstamās datubāzes avotu atlasiet kopiju, nevis oriģinālo failu.
Noklikšķiniet uz “Start Atkopšana” un izpildiet norādījumus, lai atjaunotu datubāzi.
Pēc atkopšanas procesa parādīsies jauna atkopšanas datubāze. SQL Server kas satur visus atgūtos datus.

18. Paplašinātas problēmu novēršanas scenāriji

Sarežģītās vidēs ir nepieciešamas specializētas pieejas, lai atrisinātu SQL datubāzes atkopšanas neatrisinātās problēmas.

18.1 Vairāku datubāzes failu problēmas

Datubāzēm ar vairākiem datu failiem (NDF) nepieciešama rūpīga apstrāde:

Nosakiet, kuras failu grupas ir ietekmētas
Pārbaudiet visu NDF failu pieejamību
Apsveriet failu grupai specifiskas atkopšanas iespējas
Pareizi apstrādājiet tikai lasāmas failu grupas

18.2 Vienmēr ieslēgtas pieejamības grupas

SQL datubāzes atkopšana gaida vienmēr On vides:

Vispirms pārbaudiet primārās kopijas statusu
Sinhronizācijas stāvokļa pārbaude
Apsveriet problemātiskas kopijas noņemšanu un atkārtotu pievienošanu
Pieejamības grupas konfigurācijas pārskatīšana

18.3 Klasteru un augstas pieejamības scenāriji

SQL datubāzes atkopšana gaida rezerves klasteris un augsta pieejamība scenāriji:

Pārbaudiet koplietotās krātuves pieejamību
Pārbaudiet klastera mezglu sakarus
Pārskatīt kļūmjpārlēces klastera žurnālus
Nodrošiniet pareizu DNS atrisi

18.4 WMI un sistēmas līmeņa problēmas

Sistēmas līmeņa problēmas var izraisīt datubāzes problēmas:

WMI repozitorija korupcija
Neizdevās Windows atjauninājumi
Reģistra bojājums
Pakalpojumu atkarības problēmas

19. Profilakses stratēģijas

SQL datubāzes atkopšanas gaidāmo problēmu novēršana ir efektīvāka nekā to labošana pēc to rašanās.

19.1 Rezerves kopēšanas labākā prakse

Ieviesiet automatizētus pilnus dublēšanas grafikus
Konfigurējiet regulāras diferenciālās dublējumkopijas
Iestatiet biežas darījumu žurnāla dublējumkopijas
Regulāri pārbaudiet dublējuma atjaunošanas procedūras
Saglabājiet dublējumkopijas atsevišķās krātuves sistēmās
Pārbaudiet dublējuma integritāti, izmantojot RESTORE VERIFYONLY

19.2 Uzraudzība un apkope

Iestatiet diska vietas uzraudzības brīdinājumus
Regulāru DBCC CHECKDB darbību plānošana
Kontrolēt SQL Server kļūdu žurnāli katru dienu
Izpildīt veiktspējas bāzes līmeņa uzraudzība
Konfigurēt SQL Server Aģenta brīdinājumi par kritiskām kļūdām

19.3 Infrastruktūras apsvērumi

Uzstādiet UPS sistēmas strāvas aizsardzībai
Izmantojiet uzņēmuma līmeņa krātuvi ar redundanci
Ieviesiet atbilstošas izslēgšanas procedūras
Nodrošiniet tīkla stabilitāti koplietotajai krātuvei
Regulāra aparatūras veselības uzraudzība

19.4 SQL Server Konfigurācijas labākā prakse

Izvēlieties atbilstošus atveseļošanās modeļus
Konfigurējiet saprātīgus automātiskās augšanas iestatījumus
Atdaliet datu un žurnālfailus dažādos diskos
Izmantojiet īpašus pakalpojumu kontus ar minimālām privilēģijām
glabāt SQL Server atjaunināts ar jaunākajām servisa pakotnēm

20. Lēmumu koka un metodoloģijas problēmu novēršana

Ievērojiet šo sistemātisko pieeju, ja rodas problēmas ar SQL datubāzes atkopšanu.

20.1 Sistemātiska diagnostikas pieeja

Vispirms pārbaudiet kļūdu žurnālus – Vienmēr start ar SQL Server un Windows žurnāli
Pārbaudiet failu pieejamību – Pārliecinieties, vai visi datubāzes faili pastāv un ir lasāmi
Pārbaudiet vietu diskā – Apstipriniet pietiekamu vietu evakuācijas operācijām
Vispirms izmēģiniet vienkāršus risinājumus – Pakalpojumu restart, bezsaistē/tiešsaistē
Virzība uz sarežģītiem remontiem – Tikai pēc tam, kad vienkāršas metodes neizdodas
Apsveriet atjaunošanu no dublējuma – Kad remonta riski ir pārāk augsti

20.2 Pareizās labošanas metodes izvēle

Zems risks (izmēģiniet vispirms):

Restart SQL Server filmēšanas serviss
Pārbaudiet un novērsiet diska vietu
Labot failu atļaujas
Bezsaistes/tiešsaistes datubāze

Vidējs risks:

Faila ceļa labojumi
Atspējot automātisko aizvēršanu
FILESTREAM konfigurācijas labojumi
Pakalpojums kavējas start

Augsts risks (iespējams datu zudums):

Dzēst žurnālfailu un atjaunottart
Atvienot/atkārtoti pievienot datubāzi
Atjaunot darījumu žurnālus
Avārijas režīma remonts ar DBCC PĀRBAUDE

20.3 Kad eskalēt

Meklējiet profesionālu palīdzību, ja:

Vairākas augsta riska metodes nav izdevušās
Datubāzē ir neaizstājami kritiski dati
Korupcija ietekmē vairākas datubāzes
Pastāv aizdomas par sistēmas līmeņa problēmām
Laika ierobežojumi prasa garantētus rezultātus

21. Bieži uzdotie jautājumi

J: Kāda ir atšķirība starp datubāzes stāvokļiem “ATJAUNOŠANA” un “ATJAUNOŠANA GAIDA”?

A: “ATJAUNOŠANA” nozīmē, ka datubāze aktīvi veic atkopšanas darbības un automātiski atkal darbosies tiešsaistē, kad tās būs pabeigtas. “ATJAUNOŠANA GAIDA” nozīmē SQL Server nevar staratkopšanas procesu kavē šķēršļa, piemēram, trūkstošu failu, nepietiekamas vietas vai bojājumu, dēļ. Ja atkopšana ir gaidāma, tās risināšanai nepieciešama manuāla iejaukšanās.

J: Kuru risinājumu man vajadzētu izmēģināt vispirms, ja rodas problēmas ar SQL datubāzes atkopšanu?

A: Vienmēr starvispirms ar drošākajām metodēm. Pārbaudiet SQL Server kļūdu žurnālus, pārbaudiet diska vietas pieejamību un pēc tam mēģiniet atkārtotitarTing SQL Server pakalpojumi. Šīs zema riska pieejas atrisina most bieži sastopamas atkopšanas problēmas bez datu zaudēšanas riska.

J: Cik ilgi man jāgaida, pirms izmēģināt citu labošanas metodi?

A: Pakalpojumu vajadzībāmtarts, uzgaidiet 2–3 minūtes, līdz viss ir pabeigtstarVienkāršām stāvokļa izmaiņām, piemēram, bezsaistē/tiešsaistē, uzgaidiet 30–60 sekundes. Sarežģītiem remontiem, piemēram, DBCC CHECKDB, atkarībā no datubāzes lieluma, ņemiet vērā, ka atkopšanas procesi nav pārtraukti.tartē.

J: Vai, novēršot SQL datubāzes atkopšanas problēmas, es zaudēšu datus?

A: Datu zudums ir atkarīgs no izmantotās metodes. Drošas metodes, piemēram, pakalpojumu atjaunošanatarts, diska vietas labojumi un atļauju labojumi neizraisa datu zudumu. Augsta riska metodes, piemēram, avārijas režīma labošana, žurnāla atjaunošana vai žurnālfailu dzēšana, var izraisīt ievērojamu datu zudumu. Vienmēr vispirms izmēģiniet drošās metodes.

J: Vai varu novērst SQL datubāzes atkopšanas gaidīšanas problēmas?

A: Jā, manost problēmas ir novēršamas, veicot atbilstošu apkopi. Regulāri veiciet dublējumkopijas, uzraugiet diska vietu, uzturiet atbilstošu krātuves ietilpību, izmantojiet UPS aizsardzību, veiciet regulāras DBCC CHECKDB darbības un uzturiet SQL Server atjaunināts ar jaunākajām servisa pakotnēm.

J: Vai man vajadzētu mēģināt labot ražošanas datubāzes darba laikā?

A: Nekad nemēģiniet izmantot augsta riska labošanas metodes ražošanas datubāzēs darba laikā. Sarežģītiem remontiem ieplānojiet apkopes periodus. Tomēr drošas metodes, piemēram, servisa atjaunošanatarts vai diska vietas labojumus var mēģināt veikt nekavējoties, ja tie bloķē kritiskas darbības.

J: Kad man vajadzētu atjaunot no dublējuma, nevis mēģināt veikt labošanu?

A: Atjaunojiet no dublējuma, ja vairāki labošanas mēģinājumi neizdodas, ja tiek apstrādāti kritiski svarīgi ražošanas dati, kuriem nepastāv turpmākas bojāšanas risks, ja jums ir nesen izveidotas dublējumkopijas ar pieņemamu datu zuduma periodu vai ja labošanas metodes prasītu ilgāku laiku nekā atjaunošanas darbības.

J: Kā es varu zināt, vai mani datubāzes faili ir bojāti vai vienkārši nepieejami?

Parbaude SQL Server Kļūdu žurnāli konkrētiem kļūdu ziņojumiem. Failu pieejamības problēmas parāda kļūdas “failu nevar atrast” vai atļauju kļūdas. Bojājumi parasti parāda kontrolsummas kļūdas, lapas līmeņa kļūdas vai konsekvences pārkāpumus. Izmantojiet DBCC CHECKDB, lai precīzi pārbaudītu bojājumus, kad datubāze ir pieejama.

J: Kāds ir drošākais veids, kā kopēt datubāzes failus pirms remonta mēģinājuma?

A: Apstāties SQL Server pilnībā instalējiet pakalpojumu un pēc tam kopējiet gan MDF, gan LDF failus uz dublējuma atrašanās vietu. Varat arī izmantot datubāzes dublēšanas komandas, ja datubāze joprojām ir pieejama. Nekad nekopējiet failus, kamēr SQL Server darbojas, jo tas var radīt nekonsekventas kopijas.

J: Vai SQL datubāzes atkopšanas neatrisinātās problēmas var ietekmēt vairākas datubāzes vienlaikus?

A: Jā, sistēmas līmeņa problēmas, piemēram, nepietiekama vieta diskā, pakalpojuma konta problēmas, krātuves kļūmes vai SQL Server Konfigurācijas kļūdas var ietekmēt vairākas datubāzes. Vienmēr pārbaudiet, vai citās datubāzēs nav līdzīgu problēmu, lai identificētu plašākas sistēmas problēmas.

J: Cik bieži man jāpārbauda datubāzes atjaunošanas procedūras?

A: Kritiski svarīgo datubāzu atjaunošanas procedūras pārbaudiet reizi mēnesī, bet svarīgo datubāzu atjaunošanas procedūras – reizi ceturksnī. Iekļaujiet dažādu atjaunošanas scenāriju, piemēram, atkopšanas noteiktā laika punktā, žurnālu secības atjaunošanas un ārkārtas atjaunošanas procedūru, testēšanu. Dokumentējiet un pierakstiet katras pārbaudes laiku ārkārtas situāciju plānošanai.

J: Kad man jāsazinās ar Microsoft atbalsta dienestu vai jāalgo profesionāla palīdzība?

A: Meklējiet profesionālu palīdzību, ja vairāki labošanas mēģinājumi neizdodas, ja tiek apstrādāti kritiski svarīgi dati bez dublējumkopijām, ja rodas sarežģīta datu bojāšana vairākās datubāzēs, rodas nedokumentēti kļūdu ziņojumi vai ja laika ierobežojumu dēļ ir nepieciešami garantēti atkopšanas rezultāti.

J: Vai trešo pušu SQL atkopšanas rīki ir ieguldījuma vērti?

A: Atkopšanas rīki ir vērtīgi, ja manuālās metodes neizdodas un nav dublējumu. Most rīki piedāvā bezmaksas izmēģinājuma versijas, lai pārbaudītu atgūstamību pirms iegādes. Apsveriet cost salīdzinājumā ar profesionālajiem pakalpojumiem, datu vērtību un veiksmes varbūtību. Rīki vislabāk darbojas strukturālu bojājumu gadījumā, taču tie, iespējams, neatgūst visus datu tipus.

J: Kas jādara, ja SQL datubāzes atkopšanas gaidīšanas režīms turpina atkārtoties?

A: Atkārtotas problēmas norāda uz pamatā esošām sistēmas problēmām. Pārbaudiet, vai nav aparatūras kļūmju, nepietiekamu resursu, krātuves sistēmas problēmu vai konfigurācijas problēmu. Pārraugiet Windows notikumu žurnālus, ieviesiet visaptverošu uzraudzību un apsveriet aparatūras jaunināšanu vai pāreju uz uzticamākām krātuves sistēmām.

22. Secinājums un īsa uzziņa

SQL datubāzes atkopšanas neatrisinātās problēmas var atrisināt, izmantojot šīs 15 pārbaudītās metodes, sākot no vienkāršas pakalpojumu atjaunošanastarlīdz sarežģītiem avārijas remontiem.

22.1 Ātro labojumu kopsavilkuma tabula

Fiksēšanas metode	Riska līmenis	Datu zaudēšanas risks	Vislabāk lietots
Restart SQL Server	Zems	neviens	Laika problēmas, tempsrary slēdzenes
Pārbaudiet vietu diskā	Zems	neviens	Ar kosmosu saistītas kļūmes
Aizkavētas start	Zems	neviens	Glabāšanas laika problēmas
Labot atļaujas	Zems	neviens	Piekļuve liegta kļūdas
Pareizi failu ceļi	Zems	neviens	Ceļa izmaiņas, migrācijas
Bezsaistē / tiešsaistē	vidējs	Minimums	Valsts neatbilstības
Atspējot automātisko aizvēršanu	Zems	neviens	Bieži atvēršanas/aizvēršanas cikli
Dzēst žurnālfailu	augsts	Jā	Bojāti žurnāli, izstrādes vides
Atvienojiet/piestipriniet atkārtoti	augsts	Jā	Trūkstoši vai bojāti žurnāli
Atjaunot žurnālus	augsts	Jā	Trūkstošie LDF faili
Avārijas remonts ar DBCC CHECKDB	Ļoti augsts	Jā	Smaga korupcija, pēdējais līdzeklis
Labot FILESTREAM	vidējs	neviens	FILESTREAM konfigurācijas problēmas
Atjaunināt SQL Server	vidējs	neviens	Zināmas versijas kļūdas
Atjaunot no dublējuma	Zems	Kontrolēts	Kad remonta metodes neizdodas
Atkopšanas rīki	vidējs	Mainīgs	Nopietna korupcija, nav dublējumu

22.2 Ārkārtas reaģēšanas kontrolsaraksts

Pirmās 5 minūtes:

Pārbaudiet SQL Server kļūdu žurnāli
Pārbaudiet datubāzes failu pieejamību
Pārbaudiet pieejamo diska vietu
Mēģinājums atrisināt pakalpojumutart
Dokumentu kļūdu ziņojumi

Nākamās 15 minūtes:

Ja pakalpojums ir pieejams, mēģiniet bezsaistē/tiešsaistē.tart neizdevās
Pārbaudiet un novērsiet acīmredzamas atļauju problēmas
Pārbaudiet, vai failu ceļi ir pareizi
Windows notikumu žurnālu pārskatīšana
Novērtējiet rezerves kopijas pieejamību

22.3 Papildu resursi

Atcerieties: profilakse, izmantojot atbilstošas dublējumkopijas, uzraudzību un apkopi, vienmēr ir labāka nekā atkopšana. Regulāra šo procedūru testēšana neražošanas vidē nodrošina, ka esat sagatavots SQL datubāzes atkopšanas neatrisinātām problēmām.

par autoru

Juaņs Šens ir vecākais datubāzes administrators (DBA) ar vairāk nekā 10 gadu pieredzi SQL Server vides un uzņēmumu datubāzu pārvaldību. Viņš ir veiksmīgi atrisinājis simtiem datubāzu atkopšanas scenāriju finanšu pakalpojumu, veselības aprūpes un ražošanas organizācijās.

Juaņa specializējas SQL Server datubāzu atjaunošana, augstas pieejamības risinājumi un veiktspējas optimizācija. Viņa plašā praktiskā pieredze ietver vairāku terabaitu datubāzu pārvaldību, Always On pieejamības grupu ieviešanu un automatizētu dublēšanas un atkopšanas stratēģiju izstrādi kritiski svarīgām biznesa sistēmām.

Izmantojot savu tehnisko pieredzi un praktisko pieeju, Juans koncentrējas uz visaptverošu rokasgrāmatu izveidi, kas palīdz datubāzu administratoriem un IT speciālistiem risināt sarežģītus jautājumus SQL Server efektīvi izaicina. Viņš seko līdzi jaunākajām tendencēm SQL Server laidieniem un Microsoft attīstītajām datubāzu tehnoloģijām, regulāri testējot atkopšanas scenārijus, lai nodrošinātu, ka viņa ieteikumi atspoguļo labāko praksi reālajā pasaulē.

Ir jautājumi par SQL Server atkopšanai vai nepieciešama papildu palīdzība datubāzes problēmu novēršanā? Juans laipni aicina atsauksmes un ieteikumi lai uzlabotu šos tehniskos resursus.

SQL datubāzes atkopšana gaida: 15 pārbaudīti labojumi [2026. gada ceļvedis]