Nakabinbin ang Pagbawi ng SQL Database: 15 Subok na Pag-aayos [2026]

Kapag ang iyong SQL database ay natigil sa nakabinbing estado ng pagbawi, ang iyong database ay hindi na maa-access at ang mga operasyon ay hihinto. Ang komprehensibong gabay na ito ay nagbibigay ng 15 napatunayang paraan upang malutas ang mga isyu sa nakabinbing pagbawi ng SQL database, mula sa mga simpleng pag-restart hanggang sa mga advanced na pagkukumpuni sa emerhensya.

1. Pag-unawa sa SQL Database Recovery Nakabinbing Estado

Bago subukan ang anumang pag-aayos, ang pag-unawa sa kung ano ang sanhi ng pagbawi ng database ng SQL na nakabinbing mga isyu ay napakahalaga para sa pagpili ng tamang solusyon.

1.1 Ano ang Kahulugan ng Nakabinbing Pagbawi?

Ang nakabinbing pagbawi ay nagpapahiwatig na SQL Server kinikilala ang isang database na nangangailangan ng pagbawi ngunit hindi masimulan ang proseso ng pagbawi. Hindi tulad ng "Pagbawi" na nagpapakita ng aktibong pagbawi na isinasagawa, ang "Pagbawi Nakabinbin" ay nangangahulugang ang pagbawi ay hinaharangan ng isang balakid.

Ang mga pangunahing estado ng database ay kinabibilangan ng:

ONLINE - Normal na estado ng pagpapatakbo
NAKABAWI – Aktibong tumatakbo ang proseso ng pagbawi
NAKAKABINTONG ANG PAGBAWI – Hindi maaaring magsimula ang pagbawi
SUSPECT – May mga kritikal na error ang database
EMERGENCY – Limitadong read-only na access para sa pag-aayos
Offline - Manu-manong kinuha offline

1.2 Mga Karaniwang Dahilan ng Nakabinbin na Pagbawi ng SQL Database

Ang mga nakabinbing isyu sa pagbawi ng SQL db ay karaniwang nagreresulta mula sa mga karaniwang dahilan na ito:

Nawawala o sira ang mga file ng log ng transaksyon (LDF)
Hindi sapat na espasyo sa disk sa panahon ng pagpapatakbo ng pagbawi
Mga pagkabigo sa hardware at hindi inaasahang pag-shutdown ng system
Sirang MDF database file
Mga isyu sa pahintulot ng file na pumipigil sa pag-access
SQL Server mga problema sa tiyempo ng pagsisimula ng serbisyo
Mga error sa pagsasaayos ng FILESREAM
Mga maling path ng file pagkatapos ng paglilipat ng server

1.3 Paano Suriin ang Estado ng Database

I-verify ang estado ng iyong database gamit ang mga pamamaraang ito:

paggamit SQL Server Management Studio:

Kumonekta sa iyong SQL Server halimbawa
Lumawak Databases folder
Maghanap ng mga database na nagpapakita ng status na "(Nakabinbin ang Pagbawi)".

Gamit ang T-SQL command:

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

2. Mga Paunang Hakbang sa Pag-diagnose

Ang wastong pagsusuri ay mahalaga bago subukan ang anumang pagbawi ng database ng SQL na nakabinbing mga pag-aayos.

2.1 Suriin SQL Server Mga Log ng Error

Ang mga log ng error ay naglalaman ng mahalagang impormasyon tungkol sa kung ano ang sanhi ng nakabinbing estado ng pagbawi.

Pagbubukas SQL Server Pamamahala ng Studio
Mag-navigate sa pamamahala -> SQL Server Mga tala
I-double-click ang kasalukuyang log upang tingnan ang mga kamakailang error
Maghanap ng mga mensahe ng error na nauugnay sa iyong database

Bilang kahalili, gamitin ang T-SQL:

EXEC sp_readerrorlog;

2.2 Suriin ang Windows Event Logs

pindutin Windows Key + R
uri eventvwr.msc at pindutin ang Enter
Mag-navigate sa Windows Logs -> Sistema at application
Hanapin ang SQL Server mga kaugnay na error sa oras na naganap ang isyu

2.3 I-verify ang Accessibility ng File

Mag-navigate sa iyong mga lokasyon ng file ng database
I-verify ang parehong MDF at LDF file na umiiral
Tingnan kung online at naa-access ang mga drive
Kumpirmahin na ang mga network drive ay maayos na naka-mount

3. Ayusin #1: I-restart SQL Server Serbisyo

Pag-restart SQL Server Nilulutas ng mga serbisyo ang maraming nakabinbing isyu sa pagbawi ng SQL database na dulot ng mga problema sa timing o pansamantalang mga conflict sa resource.

3.1 Kailan Gumagana ang Pag-restart ng Serbisyo

Ang pamamaraang ito ay epektibo para sa:

Pansamantalang pag-lock ng mapagkukunan habang nagsisimula
Mga pagkaantala sa pagkakaroon ng drive
Mga isyu sa timing ng dependency sa serbisyo
Mga maliliit na salungatan sa pagsasaayos

3.2 Paano Mag-restart SQL Server Serbisyo

Pamamaraan 1: SQL Server Manager ng Pag-configure

Pagbubukas SQL Server Manager ng Pag-configure
I-click ang SQL Server Serbisyo
Mag-right-click ang SQL Server halimbawa, tulad ng SQL Server (MSSQLSERVER)
piliin restart
Maghintay para sa ganap na pag-restart ng serbisyo

Paraan 2: Services Console

pindutin Windows Key + R
uri services.msc at pindutin ang Enter
Hanapin ang SQL Server halimbawa, tulad ng SQL Server (MSSQLSERVER)
Mag-right-click at piliin restart

Paraan 3: PowerShell

Restart-Service -Name "MSSQLSERVER" -Force

3.3 Pag-verify Pagkatapos ng Pag-restart

Maghintay ng 2-3 minuto para sa kumpletong pagsisimula
Suriin ang katayuan ng database sa SSMS
I-verify ang mga log ng error para sa anumang mga bagong mensahe
Subukan ang pagkakakonekta sa database

4. Ayusin ang #2: Suriin at Lutasin ang Mga Isyu sa Disk Space

Ang kakulangan ng espasyo sa disk ay isang karaniwang sanhi ng mga problema sa nakabinbing pagbawi ng SQL db. Ang mga operasyon sa pagbawi ay nangangailangan ng karagdagang espasyo para sa mga pansamantalang file at paglago ng log.

4.1 Pagkilala sa mga Problema sa Disk Space

Pagbubukas file Explorer
Mag-navigate sa mga drive na naglalaman ng mga file ng database
Suriin ang magagamit na libreng espasyo
Tiyakin ang hindi bababa sa 10-20% na libreng espasyo para sa mga operasyon sa pagbawi

4.2 Pagbakante ng Disk Space

Burahin ang mga hindi kinakailangang pansamantalang file
malinaw SQL Server backup file kung space-kritikal
Ilipat ang mga hindi mahahalagang file sa iba pang mga drive
Paliitin ang iba pang mga file ng database kung maaari

Paliitin ang mga file ng database (gamiting mabuti):

DBCC SHRINKFILE (logicalfilename, target_size);

4.3 Pag-set ng Database Online Pagkatapos ng Space Fix

Kapag available na ang espasyo, subukang dalhin ang database online:

ALTER DATABASE [DatabaseName] SET ONLINE;

5. Ayusin #3: Itakda SQL Server Serbisyo sa Naantalang Pagsisimula

Pagtatakda ng SQL Server Nilulutas ng naantalang pagsisimula ang mga nakabinbing isyu sa pagbawi ng SQL database na dulot ng mga storage system o network drive na hindi handa habang nagbo-boot ang system.

5.1 Pag-unawa sa Mga Isyu sa Timing

Ang mga problema sa timing ay nangyayari kapag:

Ang SAN o network storage ay tumatagal ng oras upang masimulan
Ang mga drive letter ay hindi itinalaga sa maagang pag-boot
Ang mga drive ng network ay nangangailangan ng pagpapatunay
Ang mga controller ng storage ay nangangailangan ng oras ng pagsisimula

5.2 Pag-configure ng Naantalang Pagsisimula

pindutin Windows Key + R
uri services.msc at pindutin ang Enter
Hanapin ang SQL Server halimbawa, tulad ng SQL Server (MSSQLSERVER)
Mag-right-click at piliin Mga Katangian
Baguhin Uri ng startup sa Awtomatikong (Na-delay na Simula)
I-click ang OK
I-restart ang system para subukan

5.3 Mga Alternatibong Solusyon para sa Timing

Para sa higit pang kontrol, gumawa ng nakaiskedyul na gawain:

Pagbubukas Task Scheduler
I-click ang Pagkilos -> Lumikha ng Pangunahing Gawain
Ipasok ang Pangalan at paglalarawan ng gawain, tulad ng "Pagantala ng pagsisimula ng SQL Server serbisyo”
Itakda Trigger sa Kapag nagsimula ang computer
Itakda aksyon sa Magsimula ng programa
Itakda Programa/Script sa buong landas ng Sqlservr.exe, tulad nito: C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Binn\sqlservr.exe. Maaari mong gamitin ang function ng paghahanap sa Windows upang mahanap ito.
Sa pahina ng pagtatapos, piliin Buksan ang dialog ng Properties para sa gawaing ito kapag na-click ko ang Tapusin.
I-click ang Tapusin.
Sa dialog ng mga katangian ng gawain, i-click Trigger tab
Piliin ang trigger at i-click Patnugutan
Sa Advanced na mga setting, suriin Mag-antala ng gawain para sa: at itakda ang oras sa 3 minuto.
I-click ang OK.

6. Ayusin ang #4: Ayusin ang Mga Pahintulot sa File at Mga Karapatan sa Pag-access

Pinipigilan ang mga isyu sa pahintulot SQL Server mula sa pag-access sa mga file ng database, na humahantong sa pagbawi ng database ng SQL na nakabinbing mga estado. Ang mga tamang pahintulot sa file ay mahalaga para sa mga pagpapatakbo ng database.

6.1 Mga Karaniwang Isyu sa Pahintulot

SQL Server Ang account ng serbisyo ay walang mga karapatan sa pag-access ng file
Hinaharang ng software ng antivirus ang pag-access sa file
Binago ang mga patakaran sa seguridad
Mga problema sa pahintulot sa pagbabahagi ng network

6.2 Pagwawasto ng Mga Pahintulot sa Folder

Mag-navigate sa folder ng file ng database
Mag-right click sa folder at piliin Mga Katangian
I-click ang Katiwasayan tab
I-click ang Patnugutan
Idagdag ang SQL Server account ng serbisyo kung nawawala
Grant Buong kontrol mga pahintulot
I-click ang OK upang ilapat ang mga pagbabago

Paggamit ng Command Line (icacls):

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

6.3 Mga Pagsasaalang-alang ng Account ng Serbisyo

I-verify ang SQL Server account ng serbisyo:

Pagbubukas SQL Server Manager ng Pag-configure
I-click ang SQL Server Serbisyo
Tandaan ang Mag-log On Bilang account para sa SQL Server
Tiyaking may wastong mga pahintulot ang account na ito

7. Ayusin ang #5: Manual File Path Correction

Ang mga isyu sa path ng file ay nangyayari kapag ang mga file ng database ay inilipat o nagbabago ang mga drive letter. Ina-update ang pamamaraang ito SQL Servermga sanggunian ng panloob na file nang hindi ginagalaw ang aktwal na mga file.

7.1 Kapag Nangyari ang Mga Isyu sa Landas

Mga pagbabago sa hardware ng server
Drive letter reassignments
Mga pagbabago sa landas ng network
Mga paglilipat ng file ng database

7.2 Pagwawasto ng Mga Path ng File

Tukuyin ang kasalukuyang mga path ng file sa mga error log
Hanapin ang aktwal na mga file ng database
Gamitin ang ALTER DATABASE para i-update ang mga path

I-update ang path ng file ng data:

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

I-update ang path ng log file:

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

7.3 Mga Hakbang sa Pagpapatunay

restart SQL Server serbisyo
Suriin ang katayuan ng database
I-verify ang mga log ng error para sa mga mensaheng nauugnay sa landas
Subukan ang pagkakakonekta sa database

8. Ayusin #6: Kumuha ng Database Offline Pagkatapos Online

Ang simpleng pagbabago ng estado na ito ay maaaring malutas ang maliliit na isyu sa nakabinbing pagbawi ng SQL db sa pamamagitan ng pagpwersa ng isang malinis na paglipat ng estado at pag-clear ng mga pansamantalang kandado.

8.1 Kapag Gumagana ang Paraang Ito

Maliit na hindi pagkakapare-pareho ng estado
Pansamantalang mga kandado ng mapagkukunan
Nagre-reset ang simpleng proseso ng pagbawi
Mga kundisyon ng hindi kritikal na error

8.2 Offline/Online na Pamamaraan

Tiyaking walang aktibong koneksyon sa database
Isagawa ang offline na utos
Maghintay ng ilang segundo
Isagawa ang online na utos

Ligtas na paraan (hinihintay na magsara ang mga koneksyon):

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

Agarang pamamaraan (tinatapos ang mga koneksyon):

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

8.3 Mga Panganib at Pagsasaalang-alang

Babala: Ang paggamit ng ROLLBACK IMMEDIATE ay maaaring magdulot ng pagkawala ng data mula sa mga hindi nakatalagang transaksyon. Gamitin lamang kung kinakailangan at tiyaking naka-log off ang mga user.

9. Ayusin #7: Huwag paganahin ang AUTO CLOSE na Feature

Ang tampok na AUTO CLOSE ay maaaring magdulot ng mga nakabinbing isyu sa pagbawi ng database ng SQL kapag ang mga database ay madalas na nagbubukas at nagsasara, na lumilikha ng mga salungatan sa timing sa panahon ng mga operasyon sa pagbawi.

9.1 Pag-unawa sa AUTO CLOSE Impact

Nagsasara ang database pagkatapos madiskonekta ang huling user
Dapat mabawi sa tuwing magbubukas ang database
Lumilikha ng madalas na mga cycle ng pagbawi
Maaaring makagambala sa iba pang mga operasyon

9.2 Hindi pagpapagana ng AUTO CLOSE

Gamit ang T-SQL:

ALTER DATABASE [DatabaseName] SET AUTO_CLOSE OFF;

paggamit SQL Server Management Studio:

I-right-click ang database
piliin Mga Katangian
Pumunta sa Options pahina
Itakda Auto Close sa Huwad
I-click ang OK

9.3 Mga Kaugnay na Setting ng AUTO

Isaalang-alang din na huwag paganahin ang AUTO_SHRINK para sa mas mahusay na pagganap:

ALTER DATABASE [DatabaseName] SET AUTO_SHRINK OFF;

10. Ayusin #8: Burahin ang Nasira na Log File at I-restart

Gumagana ang pamamaraang ito kapag ang file ng log ng transaksyon ay malubhang nasira at hindi na naayos. Dapat lang itong gamitin sa mga development environment o kapag tinatanggap ang pagkawala ng data.

10.1 Kapag Angkop ang Pagtanggal ng Log

⚠️ KRITIKAL NA BABALA: Ang paraang ito ay nagdudulot ng pagkawala ng data!

Gamitin lamang kapag:

Paggawa gamit ang mga database ng pag-unlad/pagsubok
Ang log file ay ganap na sira
Walang ibang mga opsyon sa pagbawi
Available ang mga kamakailang backup

10.2 Pamamaraan sa Pagtanggal ng Log File

Itigil SQL Server serbisyong ganap
Mag-navigate sa lokasyon ng file ng database
Tanggalin ang .LDF file (panatilihin ang .MDF file)
simula SQL Server serbisyo
SQL Server ay awtomatikong lilikha ng bagong log file

10.3 Mahahalagang Babala

Mga Implikasyon ng Pagkawala ng Data:

Lahat ng hindi naisagawang transaksyon ay permanenteng mawawala
Nasira ang log chain – di-wasto ang mga differential backup
Nagiging imposible ang pagbawi ng point-in-time
Gamitin lamang sa mga kapaligiran na hindi produksyon

11. Ayusin #9: Tanggalin at Muling ilakip ang Database

Pagtanggal at muling pag-attach ng mga puwersa SQL Server upang muling buuin ang nawawala o sirang mga log file. Mareresolba ng pamamaraang ito ang mga nakabinbing isyu sa pagbawi ng database ng SQL kapag may problema ang mga log file.

11.1 Kapag Gumagana ang Detach/Re-attach

Nawawala ang mga log file
Sirang mga header ng log file
Mga pagbabago sa path ng log file
Mga simpleng senaryo ng korapsyon

11.2 Pamamaraan sa Pamamaraan ng Pag-alis/Pagkabit muli

Itakda muna ang database sa emergency mode
Baguhin sa multi-user mode
Tanggalin ang database
Muling ilakip gamit lamang ang MDF file

-- 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 Mga Alternatibong Paraan ng Pag-attach

Para sa maramihang mga sitwasyon ng file:

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

12. Ayusin ang #10: Muling Buuin ang Mga File ng Log ng Transaksyon

Ang muling pagtatayo ng log ay lumilikha ng isang bagong file ng log ng transaksyon kapag ang orihinal ay nawawala o hindi na nababagong nasira. Niresolba ng pamamaraang ito ang mga nakabinbing isyu sa pagbawi ng SQL db ngunit nagreresulta sa pagkawala ng data.

12.1 Kapag Kailangan ang Pagbuo ng Log

Nawawala ang mga LDF file pagkatapos ng pagkabigo ng hardware
Malubhang sira ang mga log ng transaksyon
Mga pagbabago sa path ng log file na hindi maaaring itama
Mga sitwasyong pang-emergency sa pagbawi

12.2 Proseso ng Pagbuo ng Log

⚠️ BABALA: Nagdudulot ito ng pagkawala ng data!

Itakda ang database sa emergency mode
Gamitin ang REBUILD LOG command
Tukuyin ang bagong lokasyon ng log file
Dalhin ang database online

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 Pag-unawa sa Mga Implikasyon ng Pagkawala ng Data

Mga sanhi ng muling pagtatayo ng log:

Pagkawala ng lahat ng hindi nakatalagang transaksyon
Sirang log sequence number
Kawalan ng kakayahang maglapat ng mga kasunod na pag-backup ng log
Nagiging imposible ang pagbawi ng point-in-time

13. Ayusin ang #11: Emergency Mode Repair gamit ang DBCC CHECKDB

Ang pag-aayos ng emergency mode ay isang paraan ng huling-resort para sa pagbawi ng database ng SQL na nakabinbing mga isyu na dulot ng katiwalian. Maaaring ayusin ng paraang ito ang mga database ngunit maaaring magresulta sa malaking pagkawala ng data.

13.1 Pag-unawa sa Emergency Mode

⚠️ SOBRANG BABALA: Mataas na panganib ng pagkawala ng data!

Gamitin lang ang emergency mode kapag:

Ang lahat ng iba pang mga pamamaraan ay nabigo
Walang available na kamakailang mga backup
Ang ilang data recovery ay mas mahusay kaysa sa kabuuang pagkawala
Ang database ay kritikal na sira

13.2 Pamamaraan sa Pag-aayos ng Emergency

Kumuha muna ng backup ng mga sirang file ng database
Itakda ang database sa emergency mode
Lumipat sa single-user mode
Patakbuhin ang CHECKDB na may opsyon sa pag-aayos
Bumalik sa multi-user mode

-- 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 Pagtatasa Pagkatapos ng Pagkukumpuni

Suriin ang output ng CHECKDB para sa mga pagkilos sa pagkukumpuni
Tingnan kung may nawawalang mga talahanayan o data
I-verify ang kritikal na functionality ng application
Isaalang-alang ang pag-restore mula sa backup kung masyadong maraming data ang nawala

14. Ayusin ang #12: Suriin at Ayusin ang FILESTREAM Configuration

Ang mga isyu sa pagsasaayos ng FILESTREAM ay maaaring magdulot ng mga nakabinbing problema sa pagbawi ng database ng SQL. Tinutugunan ng pamamaraang ito ang mga pagkabigo sa pagbawi na tukoy sa FILESTREAM.

14.1 Mga Isyu sa Pagbawi na Kaugnay ng FILESTREAM

Mga pagkabigo sa koneksyon ng driver ng FILESTREAM
Configuration mismatches sa pagitan SQL Server at OS
Mga isyu sa tiyempo habang nagsisimula ang serbisyo
Mga problema sa pahintulot sa mga container ng FILESTREAM

14.2 Pag-troubleshoot ng FILESTREAM

Suriin ang antas ng pagsasaayos ng FILESTREAM
I-verify na pinagana ang feature ng Windows
I-restart ang mga kinakailangang serbisyo
Suriin ang mga pahintulot sa container ng FILESTREAM

Suriin ang configuration ng FILESTREAM:

SELECT SERVERPROPERTY('FilestreamEffectiveLevel') AS CurrentLevel;

Paganahin ang FILESTREAM sa antas ng halimbawa:

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

14.3 FILESTREAM Pinakamahuhusay na Kasanayan

Tiyakin ang pare-parehong configuration sa lahat ng restart
I-verify na ang mga path ng container ng FILESTREAM ay naa-access
Suriin na ang tampok na Windows FILESTREAM ay maayos na pinagana
Subaybayan ang mga mensahe ng error na nauugnay sa FILESTREAM

15. Ayusin #13: Update SQL Server Mga Bersyon/Service Pack

Mas luma SQL Server Ang mga bersyon, lalo na ang mga release ng RTM, ay naglalaman ng mga kilalang bug na nagdudulot ng mga nakabinbing isyu sa pagbawi ng database ng SQL. Ang pag-update sa pinakabagong mga service pack ay malulutas ang mga problemang ito.

15.1 Mga Kilalang Isyu sa Mas Lumang Bersyon

SQL Server 2005 RTM recovery bugs
Mga pag-aayos na partikular sa service pack para sa mga proseso ng pagbawi
Pinagsama-samang mga update na tumutugon sa mga edge case
Mga isyu sa pagiging tugma sa mga mas bagong bersyon ng Windows

15.2 Proseso ng Pag-update

Suriin ang kasalukuyang SQL Server bersyon
Tukuyin ang pinakabagong available na service pack
I-download mula Microsoft Download Center
Mag-iskedyul ng window ng pagpapanatili
I-install ang service pack
I-restart ang mga serbisyo
I-verify ang functionality ng database

Suriin ang kasalukuyang bersyon:

SELECT @@VERSION;

15.3 Pag-verify Pagkatapos ng Update

Kumpirmahin ang numero ng bersyon na binago
Suriin ang lahat ng mga database ay online nang maayos
Magpatakbo ng mga pangunahing pagsubok sa pag-andar
Subaybayan ang mga log ng error para sa anumang mga bagong isyu

16. Ayusin ang #14: Ibalik ang Database mula sa Backup

Kapag ang mga nakabinbing isyu sa pagbawi ng SQL database ay hindi malutas sa pamamagitan ng mga paraan ng pagkukumpuni, ang pag-restore mula sa isang kilalang mahusay na backup ay nagbibigay ng pinaka-maaasahang solusyon na may mahuhulaang mga hangganan ng pagkawala ng data.

16.1 Kapag ang Backup Restoration ang Solusyon

Nabigo ang maraming pagtatangka sa pagkumpuni
Ang data ng kritikal na produksyon ay nangangailangan ng katiyakan
Mayroong katanggap-tanggap na window ng pagkawala ng data
Masyadong malawak ang katiwalian para ayusin

16.2 Buong Proseso ng Pagbabalik ng Database

Tukuyin ang pinakabagong magagamit na backup
Tiyakin ang sapat na espasyo sa disk para sa pagpapanumbalik
Kunin ang database offline o i-drop kung kinakailangan
Ibalik mula sa backup na file
Ilapat ang mga backup ng log kung magagamit

Pangunahing pagpapanumbalik mula sa buong backup:

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

I-restore gamit ang mga log backup para sa point-in-time na pagbawi:

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 Pagpapatunay at Pagsubok

I-verify na matagumpay na online ang database
Suriin ang integridad ng data gamit ang CHECKDB
Subukan ang mga kritikal na function ng application
Kumpirmahin ang backup/restore na nakumpleto nang walang mga error

16.4 Sanggunian

Maaari kang matuto ng higit pang impormasyon mula sa aming komprehensibong gabay sa kung paano i-back up at i-restore SQL Server Mga Database.

17. Ayusin ang #15: Mga Propesyonal na SQL Recovery Tool

Kapag nabigo ang mga manu-manong pamamaraan na lutasin ang mga nakabinbing isyu sa pagbawi ng database ng SQL, maaaring kunin ng dalubhasang software sa pagbawi ang data mula sa mga malubhang sira na database na hindi maaaring ayusin sa pamamagitan ng mga karaniwang pamamaraan.

17.1 Kailan Isasaalang-alang ang Mga Tool ng Third-Party

Matinding katiwalian na lampas sa mga kakayahan ng manu-manong pag-aayos
Kritikal na data na walang available na backup
Maramihang nabigong manu-manong pagtatangka sa pagkumpuni
Mga kinakailangan sa pagbawi ng kritikal sa oras

17.2 DataNumen SQL Recovery

DataNumen SQL Recovery ay isang makapangyarihang SQL Server tool sa pagbawi ng database.

Nasa ibaba ang mga hakbang para gamitin ito:

Itigil ang SQL Server Serbisyo.
Gumawa ng kopya ng mga file ng database sa nakabinbing estado ng pagbawi, kasama ang parehong pangunahing MDF file at ang pangalawang NDF file.
Simulan ang SQL Server Serbisyo.
simula DataNumen SQL Recovery.
Piliin ang kopya, sa halip na ang orihinal na file, bilang pinagmulan ng database na mababawi.
I-click ang “Simulan ang Pagbawi” at sundin ang mga tagubilin upang mabawi ang database.
Pagkatapos ng proseso ng pagbawi, may lalabas na bagong database ng pagbawi SQL Server na naglalaman ng lahat ng nakuhang data.

18. Advanced na Mga Sitwasyon sa Pag-troubleshoot

Ang mga kumplikadong kapaligiran ay nangangailangan ng mga espesyal na diskarte upang malutas ang mga nakabinbing isyu sa pagbawi ng database ng SQL.

18.1 Maramihang Mga Isyu sa File ng Database

Ang mga database na may maraming data file (NDF) ay nangangailangan ng maingat na pangangasiwa:

Tukuyin kung aling mga filegroup ang apektado
Suriin ang lahat ng NDF file para sa accessibility
Isaalang-alang ang mga opsyon sa pagbawi na tukoy sa filegroup
Pangasiwaan ang mga read-only na filegroup nang naaangkop

18.2 Laging Nasa Mga Pangkat ng Availability

Nakabinbin ang pagbawi ng SQL db Palaging Bukas mga kapaligiran:

Suriin muna ang katayuan ng pangunahing replika
I-verify ang katayuan ng pag-synchronize
Isaalang-alang ang pag-alis at muling pagdaragdag ng may problemang replika
Suriin ang configuration ng pangkat ng availability

18.3 Cluster at Mataas na Availability na Sitwasyon

Nakabinbin ang pagbawi ng SQL database sa kumpol ng failover at mataas na kakayahang magamit mga senaryo:

I-verify ang accessibility ng nakabahaging storage
Suriin ang mga komunikasyon sa cluster node
Suriin ang mga failover cluster log
Tiyaking wastong resolusyon ng DNS

18.4 WMI at Mga Isyu sa Antas ng System

Ang mga problema sa antas ng system ay maaaring magdulot ng mga isyu sa database:

WMI repository corruption
Nabigong mga update sa Windows
Korapsyon sa rehistro
Mga problema sa dependency sa serbisyo

19. Mga Istratehiya sa Pag-iwas

Ang pagpigil sa mga nakabinbing isyu sa pagbawi ng database ng SQL ay mas epektibo kaysa sa pag-aayos sa mga ito pagkatapos mangyari ang mga ito.

19.1 I-backup ang Pinakamahuhusay na Kasanayan

Magpatupad ng mga awtomatikong full backup na iskedyul
I-configure ang mga regular na differential backup
Mag-set up ng madalas na mga backup ng log ng transaksyon
Regular na subukan ang mga pamamaraan sa pagbabalik ng backup
Mag-imbak ng mga backup sa magkahiwalay na storage system
I-verify ang integridad ng backup gamit ang RESTORE VERIFYONLY

19.2 Pagsubaybay at Pagpapanatili

I-set up ang mga alerto sa pagsubaybay sa espasyo sa disk
Mag-iskedyul ng mga regular na operasyon ng DBCC CHECKDB
Monitor SQL Server mga log ng error araw-araw
Isakatuparan pagsubaybay sa baseline ng pagganap
I-configure ang SQL Server Mga alerto ng ahente para sa mga kritikal na error

19.3 Mga Pagsasaalang-alang sa Imprastraktura

Mag-install ng mga UPS system para sa proteksyon ng kuryente
Gumamit ng enterprise-grade storage na may redundancy
Magpatupad ng mga wastong pamamaraan ng pagsasara
Tiyakin ang katatagan ng network para sa nakabahaging storage
Regular na pagsubaybay sa kalusugan ng hardware

19.4 SQL Server Mga Pinakamahuhusay na Kasanayan sa Configuration

Pumili ng naaangkop na mga modelo ng pagbawi
I-configure ang mga makabuluhang setting ng auto-growth
Paghiwalayin ang data at log file sa iba't ibang drive
Gumamit ng mga dedikadong account sa serbisyo na may kaunting mga pribilehiyo
Panatilihin SQL Server na-update sa pinakabagong mga service pack

20. Troubleshooting Decision Tree at Methodology

Sundin ang sistematikong diskarte na ito kapag nakakaharap ng mga nakabinbing isyu sa pagbawi ng database ng SQL.

20.1 Systematic Diagnosis Approach

Suriin muna ang mga error log – Palaging magsimula sa SQL Server at mga log ng Windows
I-verify ang accessibility ng file – Tiyakin na ang lahat ng mga file ng database ay umiiral at nababasa
Suriin ang espasyo sa disk – Kumpirmahin ang sapat na espasyo para sa mga operasyon sa pagbawi
Subukan muna ang mga simpleng pag-aayos – Pag-restart ng serbisyo, offline/online
Pag-unlad sa kumplikadong pag-aayos – Pagkatapos lamang mabigo ang mga simpleng pamamaraan
Isaalang-alang ang pagpapanumbalik mula sa backup – Kapag ang mga panganib sa pagkumpuni ay masyadong mataas

20.2 Pagpili ng Tamang Paraan ng Pag-aayos

Mababang Panganib (Subukan muna):

restart SQL Server mga serbisyo
Suriin at lutasin ang espasyo sa disk
Ayusin ang mga pahintulot ng file
Offline/Online na database

Katamtamang Panganib:

Pagwawasto ng landas ng file
Huwag paganahin ang AUTO CLOSE
FILESTREAM pagsasaayos ng configuration
Naantala ang pagsisimula ng serbisyo

Mataas na Panganib (Posible ang Pagkawala ng Data):

Burahin ang log file at i-restart
Tanggalin/muling ikabit ang database
Buuin muli ang mga log ng transaksyon
Emergency mode repair gamit ang DBCC CHECKDB

20.3 Kailan Mag-escalate

Humingi ng propesyonal na tulong kapag:

Nabigo ang maraming paraan na may mataas na panganib
Ang database ay naglalaman ng hindi mapapalitang kritikal na data
Nakakaapekto ang katiwalian sa maraming database
Pinaghihinalaan ang mga isyu sa antas ng system
Ang mga hadlang sa oras ay nangangailangan ng mga garantisadong resulta

21. Mga FAQ

Q: Ano ang pagkakaiba sa pagitan ng "RECOVERING" at "RECOVERY PENDING" na database states?

A: Ang ibig sabihin ng “RECOVERING” ay ang database ay aktibong nagsasagawa ng mga operasyon sa pagbawi at awtomatikong lalabas online kapag kumpleto na. Ang ibig sabihin ng “RECOVERY PEDING” ay SQL Server Hindi masimulan ang proseso ng pagbawi dahil sa isang balakid tulad ng nawawalang mga file, hindi sapat na espasyo, o pagkasira. Ang nakabinbing pagbawi ay nangangailangan ng manu-manong interbensyon upang malutas.

Q: Aling ayusin ang dapat kong subukan muna kapag nakatagpo ng mga nakabinbing isyu sa pagbawi ng database ng SQL?

A: Palaging magsimula sa pinakaligtas na mga pamamaraan muna. Suriin SQL Server mga log ng error, i-verify ang availability ng espasyo sa disk, pagkatapos ay subukang i-restart SQL Server mga serbisyo. Ang mga pamamaraang ito na mababa ang panganib ay nilulutas ang mga pinakakaraniwang isyu sa nakabinbing pagbawi nang walang anumang panganib sa pagkawala ng data.

Q: Gaano katagal ako dapat maghintay bago sumubok ng ibang paraan ng pag-aayos?

A: Para sa mga pag-restart ng serbisyo, maghintay ng 2-3 minuto para sa kumpletong pagsisimula. Para sa mga simpleng pagbabago sa estado tulad ng offline/online, maghintay ng 30-60 segundo. Para sa mga kumplikadong pagkukumpuni tulad ng DBCC CHECKDB, maghintay ng ilang oras depende sa laki ng database. Huwag ihinto ang mga proseso ng pagbawi kapag nasimulan na.

T: Mawawalan ba ako ng data kapag nag-aayos ng mga nakabinbing problema sa pagbawi ng database ng SQL?

A: Ang pagkawala ng data ay nakadepende sa paraan na ginamit. Ang mga ligtas na paraan tulad ng pag-restart ng serbisyo, pag-aayos ng espasyo sa disk, at pagwawasto ng pahintulot ay hindi nagdudulot ng pagkawala ng data. Ang mga mapanganib na paraan tulad ng pag-aayos ng emergency mode, muling pagtatayo ng log, o pagtanggal ng mga log file ay maaaring magresulta sa malaking pagkawala ng data. Palaging subukan muna ang mga ligtas na paraan.

Q: Maaari ko bang pigilan ang SQL database recovery na nakabinbing mga isyu na mangyari?

A: Oo, karamihan sa mga isyu ay maiiwasan sa pamamagitan ng wastong pagpapanatili. Magpatupad ng mga regular na backup, subaybayan ang espasyo sa disk, magpanatili ng sapat na kapasidad ng imbakan, gumamit ng proteksyon ng UPS, magsagawa ng mga regular na operasyon ng DBCC CHECKDB, at panatilihing SQL Server na-update sa pinakabagong mga service pack.

T: Dapat ko bang subukan ang pag-aayos sa mga database ng produksyon sa mga oras ng negosyo?

A: Huwag kailanman subukan ang mga paraan ng pagkukumpuni na may mataas na panganib sa mga database ng produksyon sa oras ng negosyo. Mag-iskedyul ng mga palugit ng pagpapanatili para sa mga kumplikadong pagkukumpuni. Gayunpaman, ang mga ligtas na paraan tulad ng pag-restart ng serbisyo o pag-aayos ng espasyo sa disk ay maaaring subukan kaagad kung hinaharangan ng mga ito ang mga kritikal na operasyon.

T: Kailan ko dapat i-restore mula sa backup sa halip na subukang mag-repair?

A: I-restore mula sa backup kapag nabigo ang maramihang pagtatangka sa pagkumpuni, kapag nakikitungo sa kritikal na data ng produksyon na hindi maaaring magkaroon ng panganib ng karagdagang katiwalian, kapag mayroon kang kamakailang mga backup na may katanggap-tanggap na mga window ng pagkawala ng data, o kapag ang mga paraan ng pagkumpuni ay mas magtatagal kaysa sa pagpapanumbalik ng mga operasyon.

T: Paano ko malalaman kung ang aking mga file sa database ay sira o sadyang hindi naa-access?

A: Suriin SQL Server mga log ng error para sa mga partikular na mensahe ng error. Ang mga isyu sa pagiging naa-access ng file ay nagpapakita ng "hindi mahanap ang file" o mga error sa pahintulot. Karaniwang ipinapakita ng katiwalian ang mga error sa checksum, mga error sa antas ng page, o mga paglabag sa pare-pareho. Gamitin ang DBCC CHECKDB upang tiyak na masuri ang katiwalian kapag naa-access ang database.

T: Ano ang pinakaligtas na paraan upang makopya ang mga file ng database bago subukang mag-ayos?

A: Tumigil ka SQL Server serbisyo, pagkatapos ay kopyahin ang parehong MDF at LDF file sa isang backup na lokasyon. Bilang kahalili, gumamit ng mga database backup command kung ang database ay naa-access pa rin. Huwag kailanman kopyahin ang mga file habang SQL Server ay tumatakbo dahil maaari itong lumikha ng mga hindi tugmang kopya.

T: Maaapektuhan ba ng SQL database ang mga nakabinbing isyu sa maraming database nang sabay-sabay?

A: Oo, mga isyu sa antas ng system tulad ng hindi sapat na espasyo sa disk, mga problema sa account ng serbisyo, mga pagkabigo sa storage, o SQL Server ang mga error sa pagsasaayos ay maaaring makaapekto sa maraming database. Palaging suriin kung ang ibang mga database ay nakakaranas ng mga katulad na isyu upang matukoy ang mas malawak na mga problema sa system.

T: Gaano ko kadalas dapat subukan ang aking mga pamamaraan sa pagpapanumbalik ng database?

A: Test restore procedures buwan-buwan para sa mga kritikal na database, quarterly para sa mahahalagang database. Isama ang pagsubok sa iba't ibang mga sitwasyon sa pagpapanumbalik tulad ng point-in-time na pagbawi, pag-restore ng pagkakasunud-sunod ng log, at mga pamamaraan sa pagpapanumbalik ng emergency. Idokumento at orasan ang bawat pagsubok para sa pagpaplanong pang-emerhensiya.

T: Kailan ako dapat makipag-ugnayan sa Suporta sa Microsoft o umarkila ng propesyonal na tulong?

A: Humingi ng propesyonal na tulong kapag nabigo ang maraming pagtatangka sa pag-aayos, pagharap sa data na kritikal sa misyon nang walang mga backup, nahaharap sa kumplikadong katiwalian sa maraming database, nakakaranas ng mga hindi dokumentadong mensahe ng error, o kapag ang mga hadlang sa oras ay nangangailangan ng garantisadong mga resulta sa pagbawi.

T: Sulit ba ang pamumuhunan sa mga tool sa pagbawi ng SQL ng third-party?

A: Mahalaga ang mga tool sa pagbawi kapag nabigo ang mga manu-manong pamamaraan at walang umiiral na mga backup. Karamihan sa mga tool ay nag-aalok ng mga libreng bersyon ng pagsusuri upang subukan ang kakayahang mabawi bago bilhin. Isaalang-alang ang gastos kumpara sa mga propesyonal na serbisyo, halaga ng data, at posibilidad ng tagumpay. Ang mga tool ay pinakamahusay na gumagana para sa istruktural na katiwalian ngunit maaaring hindi mabawi ang lahat ng uri ng data.

T: Ano ang dapat kong gawin kung patuloy na umuulit ang pagbawi ng database ng SQL na nakabinbin?

A: Ang mga umuulit na isyu ay nagpapahiwatig ng mga pinagbabatayan na problema sa system. Tingnan kung may mga pagkabigo sa hardware, hindi sapat na mapagkukunan, mga isyu sa storage system, o mga problema sa configuration. Subaybayan ang Windows Event Logs, ipatupad ang komprehensibong pagsubaybay, at isaalang-alang ang pag-upgrade ng hardware o paglipat sa mas maaasahang mga storage system.

22. Konklusyon at Mabilis na Sanggunian

Ang mga nakabinbing isyu sa pagbawi ng SQL database ay maaaring malutas gamit ang 15 napatunayang pamamaraang ito, mula sa mga simpleng pag-restart ng serbisyo hanggang sa mga kumplikadong pagkukumpuni sa emerhensya.

22.1 Talahanayan ng Buod ng Mabilisang Pag-aayos

Ayusin ang Paraan	Antas ng Panganib	Panganib sa Pagkawala ng Data	Pinakamahusay na Ginamit Para sa
restart SQL Server	Mababa	Wala	Mga isyu sa timing, pansamantalang mga kandado
Suriin ang espasyo sa disk	Mababa	Wala	Mga kabiguan na nauugnay sa espasyo
Naantala na simula	Mababa	Wala	Mga problema sa oras ng imbakan
Ayusin ang mga pahintulot	Mababa	Wala	Mga error na tinanggihan sa pag-access
Mga tamang landas ng file	Mababa	Wala	Mga pagbabago sa landas, paglilipat
Offline / Online	Medium	Napakaliit	Mga hindi pagkakapare-pareho ng estado
Huwag paganahin ang AUTO CLOSE	Mababa	Wala	Madalas na bukas/sarado na mga siklo
Tanggalin ang log file	Mataas	Oo	Mga sirang log, dev environment
Tanggalin/muling ikabit	Mataas	Oo	Nawawala o sira ang mga log
Buuin muli ang mga log	Mataas	Oo	Nawawala ang mga LDF file
Pag-aayos ng emergency sa DBCC CHECKDB	Napakataas	Oo	Matinding katiwalian, huling paraan
Ayusin ang FILESTREAM	Medium	Wala	Mga isyu sa configuration ng FILESTREAM
Mga update SQL Server	Medium	Wala	Mga kilalang bersyon ng bug
Ibalik mula sa pag-backup	Mababa	Kontrolado	Kapag nabigo ang mga paraan ng pag-aayos
Mga tool sa pagbawi	Medium	Nagiiba	Matinding katiwalian, walang backup

22.2 Checklist ng Pagtugon sa Emergency

Unang 5 Minuto:

Tsek SQL Server mga log ng error
I-verify ang accessibility ng database file
Suriin ang magagamit na espasyo sa disk
Subukang i-restart ang serbisyo
Mga mensahe ng error sa dokumento

Susunod na 15 Minuto:

Subukan offline/online kung nabigo ang pag-restart ng serbisyo
Suriin at ayusin ang mga halatang isyu sa pahintulot
I-verify na tama ang mga path ng file
Suriin ang mga log ng kaganapan sa Windows
Suriin ang availability ng backup

22.3 Karagdagang Mga Mapagkukunan

Tandaan: Ang pag-iwas sa pamamagitan ng wastong pag-backup, pagsubaybay, at pagpapanatili ay palaging mas mahusay kaysa sa pagbawi. Tinitiyak ng regular na pagsubok sa mga pamamaraang ito sa mga kapaligiran na hindi produksyon na handa ka kapag nangyari ang mga nakabinbing isyu sa pagbawi ng SQL database.

Tungkol sa Author

Yuan Sheng ay isang senior database administrator (DBA) na may higit sa 10 taong karanasan sa SQL Server kapaligiran at pamamahala ng database ng enterprise. Matagumpay niyang nalutas ang daan-daang mga sitwasyon sa pagbawi ng database sa mga serbisyong pinansyal, pangangalaga sa kalusugan, at mga organisasyon sa pagmamanupaktura.

Dalubhasa si Yuan sa SQL Server pagbawi ng database, mga solusyon sa mataas na kakayahang magamit, at pag-optimize ng pagganap. Kasama sa kanyang malawak na karanasan sa hands-on ang pamamahala ng mga multi-terabyte na database, pagpapatupad ng Always On Availability Groups, at pagbuo ng mga automated na backup at mga diskarte sa pagbawi para sa mission-critical na mga sistema ng negosyo.

Sa pamamagitan ng kanyang teknikal na kadalubhasaan at praktikal na diskarte, nakatuon si Yuan sa paglikha ng mga komprehensibong gabay na tumutulong sa mga administrator ng database at mga propesyonal sa IT na malutas ang kumplikado SQL Server mga hamon nang mahusay. Nananatili siyang napapanahon sa pinakabago SQL Server mga release at mga umuunlad na teknolohiya ng database ng Microsoft, na regular na sumusubok sa mga senaryo sa pagbawi upang matiyak na ang kanyang mga rekomendasyon ay sumasalamin sa mga pinakamahusay na kagawian sa totoong mundo.

May mga katanungan tungkol sa SQL Server pagbawi o kailangan ng karagdagang gabay sa pag-troubleshoot ng database? bati ni Yuan puna at mungkahi para sa pagpapabuti ng mga teknikal na mapagkukunang ito.

Nakabinbin ang Pagbawi ng SQL Database: 15 Subok na Pag-aayos [2026 Guide]