SQL Server Database sa Recovery Mode: 10 Subok na Pag-aayos [2026 Guide]

SQL Server database sa recovery mode? Kumuha ng 10 napatunayang pag-aayos ngayon! Mga hakbang-hakbang na solusyon mula sa madaling pag-aayos hanggang sa advanced na pag-aayos.

1. Pag-unawa SQL Server Database Recovery Mode

1.1 Ano ang Recovery Mode sa SQL Server

Kapag ang isang SQL Server database ay nagpapakita ng "Sa Pagbawi" katayuan, ibig sabihin SQL Server ay nagsasagawa ng pag-crash recovery o pagbawi ng transaksyon upang matiyak ang pagkakapare-pareho ng database. Ang awtomatikong prosesong ito ay nagpapanatili ng integridad ng data sa pamamagitan ng pag-replay ng mga nakatuong transaksyon at pagbabalik ng mga hindi nakasaad.

Karaniwang nangyayari ang recovery mode pagkatapos ng mga hindi inaasahang shutdown, pagkawala ng kuryente, o sa panahon ng pag-restore ng database. Bagama't ito ay isang normal na mekanismo ng proteksyon, ang mga problema ay lumitaw kapag ang SQL Server ang database sa pagbawi ay tumatagal ng hindi karaniwang mahaba o mukhang natigil.

1.2 Ang Tatlong Yugto ng Pagbawi ng Database

SQL Server Ang pagbawi ay sumusunod sa tatlong natatanging yugto:

1.2.1 Yugto ng Pagsusuri

SQL Server ini-scan ang log ng transaksyon mula sa huling checkpoint upang matukoy ang mga maruruming pahina at aktibong transaksyon. Lumilikha ito ng Dirty Page Table (DPT) at Active Transaction Table (ATT) upang subaybayan kung ano ang nangangailangan ng pagbawi.

1.2.2 Redo Phase (Roll Forward)

Ire-replay ng system ang lahat ng naka-commit na transaksyon na hindi isinulat sa disk bago ang pag-crash. Tinitiyak nito na ang lahat ng ginawang pagbabago ay maayos na inilalapat sa mga file ng database.

1.2.3 I-undo ang Yugto (Rollback)

Ang anumang mga transaksyon na hindi nakatuon ay ibinabalik upang mapanatili ang pagkakapare-pareho ng database. Kapag kumpleto na, magiging available ang database para sa mga normal na operasyon.

1.3 Mga Karaniwang Sintomas at Mensahe ng Error

Kapag ang iyong SQL Server db ay nasa pagbawi, karaniwan mong makikita ang:

• Pangalan ng database na nagpapakita ng "(In Recovery)" sa SQL Server Pamamahala ng Studio
• Mga pagkabigo sa pag-log in gamit ang mga mensaheng "nare-recover ang database".
• Mga entry sa log ng error na nagpapakita ng mga porsyento ng progreso sa pagbawi
• Ang katayuan ng database na nagpapakita ng "RECOVERING" kapag na-query

2. Pinag-ugatan ng SQL Server Mga Isyu sa Recovery Mode

2.1 Hindi Kumpletong Pagpapanumbalik ng mga Operasyon

Ang pinakakaraniwang sanhi ay nangyayari kapag nagre-restore mula sa maraming backup file gamit ang NORECOVERY opsyon na walang final MAY PAGBAWI utos. Iniiwan nito ang database na naghihintay para sa mga karagdagang pagpapatakbo ng pagpapanumbalik.

2.2 Mga Problema sa Log ng Transaksyon

Malaking transaksyon log file o labis na Virtual Log Files (VLFs) makabuluhang mabagal pagbawi. Kapag ang MS SQL ay nasa pagbawi na may libu-libong VLF, ang proseso ay maaaring tumagal ng oras o araw upang makumpleto.

2.3 Mga Isyu na Kaugnay ng System

Ang mga pagpalya ng hardware, pagkawala ng kuryente, o kakulangan ng espasyo sa disk ay maaaring makaabala sa normal na operasyon ng database, na magdudulot ng mahahabang proseso ng pagbawi habang nagre-restart.

2.4 Korapsyon sa Database

Ang mga sirang file ng database ay pumipigil sa matagumpay na pagkumpleto ng pagbawi, na iniiwan ang database nang walang katapusan na natigil sa recovery mode.

3. Mga Hakbang sa Pag-diagnose Bago ang Pag-aayos

3.1 Sinusuri SQL Server Mga Log ng Error

Bago subukang ayusin, suriin ang SQL Server log ng error para sa mga mensahe sa pag-unlad ng pagbawi. Maghanap ng mga entry na nagpapakita ng mga porsyento ng pagkumpleto at tinantyang oras na natitira.

1. Pagbubukas SQL Server Pamamahala ng Studio
2. Mag-navigate sa pamamahala -> SQL Server Mga tala
3. Suriin ang mga kamakailang entry para sa pangalan ng iyong database
4. Maghanap ng mga indicator ng yugto ng pagbawi (Phase 1, 2, o 3 ng 3)

3.2 Pagsubaybay sa Pag-unlad ng Pagbawi

Gumamit ng mga dynamic na view ng pamamahala upang subaybayan ang mga aktibong pagpapatakbo ng pagbawi:

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

3.3 Pagsusuri sa Estado ng Database

I-verify ang kasalukuyang status ng database para maunawaan ang status ng pagbawi:

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

4. Ayusin ang #1: Maghintay para sa Pagkumpleto ng Natural Recovery

Minsan ang pasensya ang pinakamagandang solusyon kapag ikaw SQL Server ang database ay nasa pagbawi. Gumagana ang diskarteng ito kapag normal nang umuusad ang pagbawi ngunit mas tumatagal kaysa sa inaasahan.

4.1 Kailan Maging Matiyaga

Payagan ang natural na pagkumpleto kapag:

• Ang mga log ng error ay nagpapakita ng tuluy-tuloy na pag-unlad na may pagbaba ng mga pagtatantya sa oras
• Walang naiulat na mga error sa katiwalian
• Ang database kamakailan ay nakaranas ng malalaking transaksyon
• Ang bilang ng VLF ay mapapamahalaan (sa ilalim ng 1,000)

4.2 Pagsubaybay sa Pag-unlad ng Pagbawi

Ang mga pagtatantya sa oras ng pagbawi sa mga log ng error ay kadalasang hindi tumpak. Tumutok sa mga porsyento ng pag-unlad sa halip na oras na natitira. Ang malalaking database na may malawak na kasaysayan ng transaksyon ay maaaring mangailangan ng ilang oras para sa kumpletong pagbawi.

5. Ayusin ang #2: Gamitin ang RESTORE DATABASE WITH RECOVERY

Niresolba ng pag-aayos na ito ang mga hindi kumpletong pagpapatakbo ng pagpapanumbalik kung saan tinanggal ang huling hakbang sa pagbawi. Gamitin ito kapag ang iyong SQL Server db sa pagbawi ay nagresulta mula sa isang proseso ng pagpapanumbalik gamit ang NORECOVERY.

5.1 Pag-unawa sa Utos

Ang IBALIK ANG DATABASE NA MAY PAGBAWI Kinukumpleto ng command ang proseso ng pagbawi sa pamamagitan ng pag-roll back ng mga hindi naka-commit na transaksyon at pagdadala ng database online.

5.2 Mga Hakbang sa Pagpapatupad

1. Pagbubukas SQL Server Pamamahala ng Studio
2. Kumonekta sa iyong SQL Server halimbawa
3. I-click ang Bago > Query na may Kasalukuyang Koneksyon
   
   
4. Ipatupad: RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
5. Maghintay para sa kumpirmasyon ng pagkumpleto

Babala: Gamitin lang ang command na ito kung sigurado kang walang nakabinbin na mga karagdagang operasyon sa pag-restore.

6. Ayusin ang #3: Lutasin ang Mga Isyu sa Log ng Transaksyon

Ang mga problema sa log ng transaksyon ay isang pangunahing sanhi ng pinahabang oras ng pagbawi. Tinutugunan ng pag-aayos na ito ang mga buong log, labis na VLF, at mga isyu sa log space na nananatili SQL Server sa pagbawi.

6.1 Pag-back up ng mga Log ng Transaksyon

Magbakante ng espasyo sa log sa pamamagitan ng paglikha ng mga backup ng log ng transaksyon:

1. Pagbubukas SQL Server Pamamahala ng Studio
2. I-right-click ang iyong database -> Gawain -> Back Up
   
   
3. Baguhin Uri ng backup sa Log ng Transaksyon
   
   
4. Tukuyin ang backup na destinasyon
5. I-click ang OK upang maipatupad

6.2 Pamamahala ng Virtual Log Files (VLFs)

Suriin ang bilang ng VLF gamit ang:

DBCC LOGINFO('YourDatabaseName');

Kung mayroon kang mahigit 1,000 VLF, bawasan ang mga ito sa pamamagitan ng:

1. Bina-back up ang log ng transaksyon
2. Pag-urong ng log file: DBCC SHRINKFILE(LogFileName, TRUNCATEONLY);
3. Palakihin ang log file sa malalaking tipak (1GB o higit pa)

6.3 Ligtas na Pag-urong ng mga Log File

Paliitin lamang ang mga log sa panahon ng mga window ng pagpapanatili kapag walang mga aktibong transaksyon na tumatakbo. Palaging i-backup ang database bago paliitin ang mga operasyon.

7. Ayusin ang #4: Patakbuhin ang DBCC CHECKDB at Ayusin

Maaaring pigilan ng katiwalian sa database ang matagumpay na pagkumpleto ng pagbawi. Ang DBCC CHECKDB ay isang built-in na command na maaaring tukuyin at ayusin ang mga maliliit na isyu sa katiwalian na nagpapanatili sa MS SQL sa recovery mode.

7.1 Pagsusuri para sa Database Corruption

Magsimula sa karaniwang pamamaraan upang beripikahin ang integridad ng database. Subukan muna ang DBCC CHECKDB nang direkta:

1. Ipatupad: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
2. Suriin ang mga resulta para sa mga error sa pagkakapare-pareho
3. Idokumento ang anumang mga mensahe ng katiwalian

Kung nabigo ang DBCC CHECKDB na may mga error tulad ng "Binabawi ang database. Naghihintay hanggang matapos ang pagbawi," nangangahulugan ito na ang database ay aktibong nasa recovery mode at hinaharangan ang pag-access. Sa kasong ito, magpatuloy sa seksyon 7.3 para gamitin ang EMERGENCY mode.

7.2 Mga Opsyon sa Pag-aayos para sa Mga Naa-access na Database

Kung matagumpay na tumakbo ang DBCC CHECKDB at nakakita ng katiwalian, gamitin ang mga hakbang sa pagkukumpuni na ito:

1. Itakda ang database sa single-user mode: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
2. Subukan ang ligtas na pagkumpuni: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
3. Kung hindi matagumpay, gamitin ang: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
4. Bumalik sa multi-user: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;

7.3 Paggamit ng Emergency Mode Kapag Hindi Maa-access ang Database

Ang emergency mode ay kinakailangan lamang kapag ang database ay natigil sa pagbawi at tinatanggihan ang mga normal na pagtatangka ng DBCC CHECKDB. Minamarkahan nito ang database bilang READ_ONLY at hindi pinapagana ang pag-log. Gamitin ang diskarteng ito kapag nabigo ang karaniwang pag-access:

1. Itakda ang emergency mode: ALTER DATABASE [YourDatabaseName] SET EMERGENCY;
2. Itakda ang single-user: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
3. Patakbuhin ang integrity check: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
4. Kung may nakitang katiwalian, patakbuhin muna ang ligtas na pagkukumpuni: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
5. Kung nabigo, gumamit ng pagkumpuni na may pagkawala ng data:  DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
6. Itakda ang multi-user: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
7. Itakda online: ALTER DATABASE [YourDatabaseName] SET ONLINE;

Mahalaga: Ang EMERGENCY mode ay lumalampas sa mga normal na proseso ng pagbawi at dapat lamang gamitin kapag ang database ay ganap na hindi naa-access. Laging subukan muna ang karaniwang DBCC CHECKDB approach bago i-escalate sa EMERGENCY mode.

Maaari mong makita ang isang mas komprehensibong gabay sa kung paano gamitin ang DBCC CHECKDB.

8. Ayusin ang #5: Ibalik mula sa Backup

Kapag nabigo ang ibang mga pamamaraan o ang integridad ng data ay kaduda-duda, ang pag-restore mula sa isang malinis na backup ay kadalasang ang pinaka-maaasahang solusyon para sa paglutas ng mga problema. SQL Server database sa mga isyu sa pagbawi.

8.1 Kailan Pumili ng Backup Restoration

Isaalang-alang ang backup na pagpapanumbalik kapag:

• Ang pagbawi ay tumatakbo nang higit sa 24 na oras nang walang pag-unlad
• Ang mga error sa katiwalian ay humahadlang sa matagumpay na pagkumpuni
• Mayroon kang mga kamakailang na-verify na backup na magagamit
• Ang pagkawala ng data mula noong huling backup ay katanggap-tanggap

8.2 Hakbang-hakbang na Proseso ng Pagpapanumbalik

1. Pagbubukas SQL Server Pamamahala ng Studio
2. I-right-click ang Databases -> Ibalik ang Database
   
   
3. piliin Device sa ilalim ng Pinagmulan
4. I-click ang Idagdag at mag-browse sa iyong backup na file
5. Piliin ang backup at i-click OK
6. Piliin I-overwrite ang umiiral na database kung kinakailangan
7. I-click ang OK upang simulan ang pagpapanumbalik

8.3 Point-in-Time na Pagbawi

Para sa kaunting pagkawala ng data, gumamit ng mga backup ng log ng transaksyon upang maibalik sa isang partikular na punto ng oras. Tiyaking mayroon kang walang patid na hanay ng mga backup ng log mula sa iyong buong backup hanggang sa nais na punto ng pagbawi.

8.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.

9. Ayusin ang #6: I-disable ang AUTO CLOSE Property

Ang AUTO CLOSE database property ay maaaring magdulot ng paulit-ulit na mga cycle ng pagbawi, na nagpapalabas na ang iyong SQL Server db ay nasa pagbawi palagi. Ang pag-disable sa property na ito ay malulutas ang isyu.

9.1 Pag-unawa sa AUTO CLOSE Isyu

Kapag naka-enable ang AUTO CLOSE, SQL Server isinasara ang database pagkatapos ng huling koneksyon, pagkatapos ay muling buksan ito para sa mga bagong koneksyon. Ang paulit-ulit na pagbubukas na ito ay nagti-trigger ng mga proseso ng pagbawi sa bawat oras.

9.2 Hindi pagpapagana ng AUTO CLOSE

1. Pagbubukas SQL Server Pamamahala ng Studio
2. I-right-click ang iyong database -> Mga Katangian
3. piliin Options mula sa kaliwang panel
4. Itakda Auto Close sa Huwad
5. I-click ang OK upang ilapat ang mga pagbabago

Bilang kahalili, gamitin ang T-SQL:

ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;

10. Ayusin #7: I-restart SQL Server serbisyo

Maaaring malutas ng service restart ang mga natigil na proseso ng pagbawi, ngunit dapat itong gamitin nang may pag-iingat dahil ire-restart nito ang pagbawi mula sa simula. Gumagana ang pag-aayos na ito kapag SQL Server sa pagbawi ay lilitaw na ganap na nagyelo.

10.1 Kapag Nakatutulong ang Pag-restart ng Serbisyo

I-restart ang serbisyo kapag:

• Ang pag-unlad ng pagbawi ay natigil nang ilang oras
• Ang mga log ng error ay hindi nagpapakita ng mga bagong entry
• Ang iba pang mga database ay gumagana nang normal
• Maaari mong bayaran ang pinahabang downtime

10.2 Mga Pamamaraan sa Ligtas na Pag-restart

1. Pagbubukas SQL Server Manager ng Pag-configure
2. Mag-navigate sa SQL Server Serbisyo
3. Hanapin ang SQL Server halimbawa kung gusto mong i-restart, pagkatapos ay i-right-click SQL Server (Pangalan ng Instance)
4. piliin restart
5. Maghintay para sa ganap na pag-restart ng serbisyo
6. Subaybayan ang mga log ng error para sa pag-unlad ng pagbawi

tandaan: Ang pag-restart ay magdudulot ng pagsisimula ng paggaling mula sa simula, na posibleng magpapahaba sa kabuuang oras ng paggaling.

11. Ayusin #8: Ayusin ang Database sa pamamagitan ng Pagtanggal at Pag-attach muli

Para sa matinding mga kaso, tanggalin at muling ikabit ang database:

1. Tanggalin ang database: EXEC sp_detach_db 'YourDatabaseName';
2. Ilakip lamang ang MDF file: CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG;
3. Bumubuo ito ng bagong log ng transaksyon

Babala: Ang pamamaraang ito ay maaaring magresulta sa pagkawala ng data. Gamitin lamang kapag naubos na ang ibang mga opsyon.

12. Ayusin #9: Pangasiwaan ang Mga Isyu sa Pag-mirror ng Database

Ang mga pagsasaayos ng pag-mirror ng database ay maaaring magdulot ng mga natatanging problema sa pagbawi. Tinutugunan ng pag-aayos na ito ang mga isyung partikular sa pag-mirror na nagpapanatili sa mga database sa estado ng pagbawi.

12.1 Mga Problema sa Pagbawi na Partikular sa Pag-mirror

Ang mga naka-mirror na database ay maaaring makaalis sa pagbawi dahil sa mga isyu sa koneksyon ng kasosyo o mga problema sa endpoint. Ang parehong principal at mirror database ay maaaring magpakita ng katayuan sa pagbawi.

12.2 Pag-mirror ng Mga Solusyon sa Pagbawi

I-restart ang mirroring endpoint:

1. Hanapin ang pangalan ng endpoint: SELECT * FROM sys.endpoints WHERE type = 4;
2. Ihinto ang endpoint: ALTER ENDPOINT [EndpointName] STATE = STOPPED;
3. Simulang dulo: ALTER ENDPOINT [EndpointName] STATE = STARTED;

Kung hindi matuloy ang pag-restart ng endpoint, putulin ang mirroring partnership:

1. Ipatupad: ALTER DATABASE [DatabaseName] SET PARTNER OFF;
2. Patakbuhin: RESTORE DATABASE [DatabaseName] WITH RECOVERY;
3. I-reconfigure ang pag-mirror kapag online na ang database

13. Ayusin ang #10: Gumamit ng Mga Propesyonal na Tool sa Pagbawi

Ang mga tool sa pagbawi ng third-party ay nagbibigay ng mga advanced na kakayahan sa pag-aayos kapag naka-built-in SQL Server nabigo ang mga pamamaraan. Ang mga tool na ito ay kadalasang nakakapagbawi ng data mula sa mga malubhang sirang database.

13.1 DataNumen SQL Recovery

DataNumen SQL Recovery ay may mataas na rate ng pagbawi, kasama ang mga komprehensibong opsyon.

Nasa ibaba ang mga hakbang para gamitin ito:

1. Itigil ang SQL Server Serbisyo.
2. Gumawa ng kopya ng mga file ng database sa recovery mode, kabilang ang parehong pangunahing MDF file at pangalawang NDF file.
3. Simulan ang SQL Server Serbisyo.
4. simula DataNumen SQL Recovery.
5. Piliin ang kopya, sa halip na ang orihinal na file, bilang pinagmulan ng database na mababawi.
6. I-click ang “Simulan ang Pagbawi” at sundin ang mga tagubilin upang mabawi ang database.
7. Pagkatapos ng proseso ng pagbawi, may lalabas na bagong database ng pagbawi SQL Server na naglalaman ng lahat ng nakuhang data.

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

Gumamit ng mga propesyonal na tool kapag:

• Nabigo ang mga built-in na opsyon sa pag-aayos o nag-uulat ng malawak na katiwalian
• Walang available na kamakailang mga backup
• Dapat na mabawi ang kritikal na data sa kabila ng katiwalian
• Ang mga karaniwang paraan ng pagbawi ay nagreresulta sa makabuluhang pagkawala ng data

14. Mga Pinakamahuhusay na Kasanayan sa Pag-iwas

14.1 Mga Gawain sa Regular na Pagpapanatili

Ipatupad ang mga kasanayang ito upang maiwasan SQL Server database sa mga isyu sa pagbawi:

• Mag-iskedyul ng regular na buo at mag-log backup: Panatilihin ang kumpletong backup chain
• Subaybayan ang mga bilang ng VLF: Panatilihin ang mga VLF sa ilalim ng 100 para sa pinakamainam na pagganap
• Paglaki ng file ng log ng plano: Pre-size logs para maiwasan ang sobrang autogrowth
• Patakbuhin ang regular na DBCC CHECKDB: Maagang matukoy ang katiwalian

14.2 Pagsubaybay at Pag-alerto

I-set up ang proactive monitoring:

1. I-configure ang mga alerto para sa mga pagbabago sa estado ng database
2. Subaybayan ang espasyo sa disk sa mga log file drive
3. Subaybayan ang mga matagal nang transaksyon
4. Alerto sa labis na bilang ng VLF

14.3 Hardware at Imprastraktura

Tiyakin ang maaasahang imprastraktura:

• Gumamit ng mabilis na storage para sa mga log ng transaksyon (mas mabuti ang mga SSD)
• Magpatupad ng mga redundant power supply
• Paghiwalayin ang data at log file sa iba't ibang drive
• Isaalang-alang mga solusyon na may mataas na availability gaya ng Laging Nasa Availability Groups

15. Pag-troubleshoot ng Mga Kumplikadong Sitwasyon

15.1 Maramihang Mga Isyu sa Database

Kapag maraming database ang natigil sa pagbawi:

1. Tingnan kung may mga isyu sa buong system (disk space, memory)
2. Unahin ang mga kritikal na database para sa pagbawi
3. Isaalang-alang ang mga problema sa hardware na nakakaapekto sa buong instance
4. Suriin ang mga kamakailang pagbabago o pag-update ng system

15.2 Malaking Pagsasaalang-alang sa Database

Para sa mga database na higit sa 1TB:

• Asahan ang mas mahabang oras ng pagbawi (maaaring mga araw)
• Tiyakin ang sapat na paglalaan ng memorya
• Isaalang-alang ang parallel processing settings
• Subaybayan ang tempdb space sa panahon ng pagbawi

15.3 Kailan Makipag-ugnayan sa Suporta sa Microsoft

Makipag-ugnayan sa Suporta sa Microsoft para sa:

• Mga kritikal na sistema ng produksyon na walang mga backup na opsyon
• Pinaghihinalaan SQL Server software ng mga bug
• Mga kapaligiran ng negosyo na nangangailangan ng garantisadong pagbawi
• Complex Always On o clustering na mga sitwasyon

16. Mga FAQ

Q: Gaano katagal dapat SQL Server ang pagbawi ng database ay karaniwang tumatagal?

A: Ang oras ng pagbawi ay depende sa laki ng database, dami ng transaksyon, at pagganap ng hardware. Ang mga maliliit na database ay karaniwang bumabawi sa ilang minuto, habang ang malalaking database na may malawak na mga log ng transaksyon ay maaaring tumagal ng ilang oras. Ang mga pagtatantya sa oras na ipinapakita sa mga log ng error ay kadalasang hindi tumpak, kaya tumutok na lang sa mga porsyento ng pag-unlad.

Q: Pwede bang huminto SQL Server sa panahon ng pagbawi nang hindi nawawala ang data?

A: Huminto SQL Server Sa pangkalahatan, ligtas ang proseso ng pagbawi habang nagre-recover ngunit sisimulan muli ang proseso ng pagbawi mula sa simula kapag nag-restart ang serbisyo. Pinapalawig nito ang kabuuang oras ng pagbawi ngunit hindi magdudulot ng karagdagang pagkawala ng data na higit pa sa nangyari noong orihinal na insidente.

T: Ano ang pagkakaiba ng “In Recovery” at “Recovery Pending”?

A: Ang ibig sabihin ng “In Recovery”. SQL Server ay aktibong nagsasagawa ng mga operasyon sa pagbawi. Ipinapahiwatig ng "Recovery Pending" na nabigong magsimula ang proseso ng pagbawi, kadalasan dahil sa mga nawawalang file, hindi sapat na mga pahintulot, o mga isyu sa espasyo sa disk na dapat lutasin bago magpatuloy ang pagbawi.

Makakahanap ka ng mas detalyadong impormasyon tungkol sa "Nakabinbin ang Pagbawi" sa aming kumpletong gabay.

T: Mawawalan ba ako ng data kung gagamit ako ng REPAIR_ALLOW_DATA_LOSS?

A: Oo, maaaring alisin ng REPAIR_ALLOW_DATA_LOSS ang sirang data upang maibalik ang pagkakapare-pareho ng database. Palaging subukan muna ang REPAIR_REBUILD, na nag-aayos ng mga isyu sa istruktura nang walang pagkawala ng data. Gamitin lamang ang REPAIR_ALLOW_DATA_LOSS bilang huling paraan kapag wala kang ibang mga opsyon sa pagbawi.

Q: Maaari ko bang ma-access ang iba pang mga database habang ang isang database ay nasa pagbawi?

A: Oo, iba pang mga database sa parehong SQL Server halimbawa ay mananatiling naa-access sa panahon ng pagbawi. Tanging ang database na sumasailalim sa pagbawi ay hindi magagamit. Gayunpaman, ang mga pagpapatakbo ng pagbawi ay maaaring makaapekto sa pangkalahatang pagganap ng server.

Q: Ano ang nagiging sanhi ng isang database na natigil sa recovery mode?

A: Kasama sa mga karaniwang dahilan ang hindi kumpletong pagpapaandar ng pagpapanumbalik gamit ang NORECOVERY, labis na Virtual Log Files (VLFs), malalaking uncommitted na transaksyon, katiwalian sa database, hindi sapat na espasyo sa disk, at mga isyu sa hardware. Ang mga naka-enable na database ng AUTO CLOSE ay maaari ding lumitaw na patuloy na pumasok sa pagbawi.

T: Paano ko malalaman kung umuunlad o natigil ang pagbawi?

A: Monitor SQL Server mga log ng error para sa mga mensahe ng pag-usad ng pagbawi na nagpapakita ng mga porsyento ng pagkumpleto. Gamitin ang sys.dm_exec_requests upang suriin ang mga aktibong utos ng DB STARTUP. Kung tataas ang mga porsyento sa paglipas ng panahon, umuusad ang pagbawi. Ang kawalan ng mga bagong entry sa log sa loob ng ilang oras ay maaaring magpahiwatig ng isang natigil na proseso.

T: Ligtas ba itong i-restart SQL Server serbisyo sa panahon ng paggaling?

A: Ligtas ang pag-restart ngunit dapat gamitin nang may pag-iingat. Ire-restart nito ang recovery mula sa simula, na posibleng magdoble sa oras ng recovery. I-restart lamang kung ang recovery ay tila ganap na nakatigil nang walang progreso sa loob ng maraming oras, o kung pinaghihinalaan mong talagang natigil ang proseso.

Q: Ano ang pagkakaiba ng AUTO CLOSE at recovery mode?

A: Awtomatikong isinasara ng AUTO CLOSE ang mga database kapag walang mga koneksyon, pagkatapos ay muling bubuksan ang mga ito para sa mga bagong koneksyon. Ang paulit-ulit na pagbubukas na ito ay nagti-trigger ng mga maikling proseso ng pagbawi sa bawat oras, na nagpapalabas na ang database ay patuloy na nagre-recover. Ang hindi pagpapagana ng AUTO CLOSE ay malulutas ang isyung ito.

T: Makakatulong ba ang mga backup ng log ng transaksyon sa panahon ng pagbawi?

A: Ang mga backup ng log ng transaksyon ay maaaring magbakante ng espasyo sa log kung puno na ang log drive, na posibleng magpapahintulot sa pagpapatuloy ng pagbawi. Gayunpaman, hindi mo maaaring i-backup ang log ng isang database na kasalukuyang nasa recovery mode. Ang mga backup ng log ay mas kapaki-pakinabang para sa pag-iwas at pagpapanatili pagkatapos ng pagbawi.

T: Kailan ako dapat makipag-ugnayan sa Microsoft Support?

A: Makipag-ugnayan sa Suporta sa Microsoft para sa mga kritikal na sistema ng produksyon kung saan nabigo ang mga built-in na paraan ng pagbawi, kapag naghinala ka SQL Server mga bug sa software, para sa kumplikadong Always On o clustering na mga sitwasyon, o kapag ang mga enterprise environment ay nangangailangan ng garantisadong pagbawi ng data na may kaunting downtime.

T: Paano ko mapipigilan ang mga database na hindi makaalis sa pagbawi?

A: Ipatupad ang mga regular na full at log backup, subaybayan at pamahalaan ang mga bilang ng VLF, tiyakin ang sapat na espasyo sa disk, gumamit ng wastong mga pamamaraan sa pag-shutdown, mapanatili ang pagiging maaasahan ng hardware, huwag paganahin ang AUTO CLOSE sa mga database ng produksyon, at magpatakbo ng mga regular na operasyon ng DBCC CHECKDB upang maagang matukoy ang katiwalian.

Q: Ano ang mga VLF at bakit nakakaapekto ang mga ito sa pagbawi?

A: Ang mga Virtual Log Files (VLFs) ay mga panloob na segment sa loob ng mga file ng log ng transaksyon. Masyadong maraming mga VLF (mahigit sa 1,000) ay makabuluhang mabagal ang pagbawi dahil SQL Server dapat iproseso ang bawat isa nang paisa-isa. Ang wastong sukat ng file ng log at mga setting ng paglago ay nakakatulong na mapanatili ang pinakamainam na bilang ng VLF.

Q: Maaari ko bang i-restore mula sa backup habang ang isang database ay nasa recovery?

A: Hindi ka makakapag-restore sa isang database na kasalukuyang nasa recovery mode. Dapat mong hintayin na makumpleto ang pagbawi, itigil ang SQL Server serbisyo, o ibalik sa ibang pangalan ng database. Para sa mga agarang sitwasyon, isaalang-alang ang pagpapanumbalik sa isang bagong pangalan ng database at pagkatapos ay palitan ang pangalan nito kapag nalutas na ang mga isyu sa pagbawi.

17. Konklusyon at Mga Susunod na Hakbang

17.1 Buod ng Mga Pangunahing Solusyon

Kapag ang iyong SQL Server Kung ang database ay nasa recovery, magsimula sa mga sumusunod na pamamaraan ayon sa pagkakasunod-sunod:

1. Suriin ang mga log ng error at subaybayan ang pag-unlad
2. Maghintay para sa natural na pagkumpleto kung ang pag-unlad ay matatag
3. Gamitin ang RESTORE WITH RECOVERY para sa mga hindi kumpletong pag-restore
4. Tugunan ang mga isyu sa log ng transaksyon
5. Patakbuhin ang DBCC CHECKDB o mga propesyonal na tool para sa katiwalian
6. Isaalang-alang ang backup na pagpapanumbalik para sa malalang kaso

tulay SQL Server db sa mga sitwasyon sa pagbawi ay malulutas sa loob ng ilang oras gamit ang mga napatunayang pamamaraang ito. Para sa mga kumplikadong sitwasyon, huwag mag-atubiling gumamit ng mga advanced na diskarte o mga propesyonal na tool.

17.2 Karagdagang Mga Mapagkukunan

Para sa karagdagang tulong:

• microsoft SQL Server dokumentasyon
• SQL Server Mga Forum ng Komunidad
• Mga blog sa pangangasiwa ng database at mga teknikal na mapagkukunan
• Propesyonal na mga serbisyo sa pagbawi ng database

Ang regular na pagpapanatili at pagsubaybay ay nakakaiwas sa karamihan ng mga isyu sa pagbawi. Ipatupad ang mga kasanayan sa pag-iwas na nakabalangkas sa gabay na ito upang mabawasan ang mga paglitaw ng MS SQL sa mga problema sa pagbawi sa hinaharap.

---

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.