SQL Server Pagpapadala ng Log: Kumpletong Gabay para sa DBA [2026]

1. Panimula sa SQL Server Pagpapadala ng Troso

1.1 Ano ang SQL Server Pagpapadala ng troso?

SQL Server Ang log shipping ay isang awtomatikong solusyon sa disaster recovery na nagpapanatili ng mga mainit at standby na kopya ng iyong mga production database. Inililipat ng teknolohiya ang mga backup ng transaction log mula sa isang pangunahing database sa isang pangunahing server instance patungo sa isa o higit pang mga pangalawang database sa magkakahiwalay na pangalawang server instance, na tinitiyak na ang iyong mga pangalawang database ay mananatiling naka-synchronize sa pangunahing database, na nagbibigay ng proteksyon laban sa pagkawala ng data at mga pagkabigo ng server.

1.2 Layunin at mga Benepisyo ng Pagpapadala ng Troso

Ang pagpapadala ng log ay nagsisilbi ng maraming kritikal na layunin sa pangangasiwa ng database:

• Ang pangunahing tungkulin nito ay ang disaster recovery, na nagbibigay ng maaasahang failover target kapag ang iyong pangunahing server ay naging hindi magagamit dahil sa hardware failure, software corruption, o mga sakuna na nakakaapekto sa iyong data center.
• Ito rin ay isang matipid na solusyon na may mataas na kakayahang magamitHindi tulad ng mga feature na pang-enterprise na nangangailangan ng mamahaling paglilisensya, gumagana ang log shipping kasama ang SQL Server Standard Edition, na ginagawang naa-access ito para sa mga organisasyong may limitasyon sa badyet.
• Ang mga secondary database sa standby mode ay nag-aalok ng karagdagang halaga na higit pa sa disaster recovery. Magagamit ito ng mga administrador ng database para sa read-only na pag-uulat, at pag-aalis ng mga workload ng query mula sa production server.
• Ang tampok na naantalang pagpapanumbalik ay nagbibigay ng proteksyon laban sa mga hindi sinasadyang pagbabago ng data. Sa pamamagitan ng pag-configure ng pagkaantala sa pagpapanumbalik, lumilikha ka ng isang palugit ng oras upang makabawi mula sa mga error ng user bago makarating ang mga mapaminsalang pagbabago sa iyong pangalawang database.

2. SQL Server Mga Bahagi at Daloy ng Trabaho sa Pagpapadala ng Log

Ang pagpapadala ng troso ay binubuo ng mga sumusunod na bahagi:

• Pangunahing Server at Pangunahing Database: Ang pangunahing server ay kumakatawan sa iyong produksyon SQL Server instance na nagpapatakbo ng pangunahing database.
• Backup share: Ang intermediate na lokasyon para iimbak at ilipat ang mga backup ng transaction log mula sa pangunahing server patungo sa mga pangalawang server.
• Mga Pangalawang Server at Pangalawang Database: Ang mga pangalawang server ang nagho-host ng mainit at naka-standby na mga kopya ng iyong pangunahing database.
• Monitor Server (Opsyonal): Sinusubaybayan ng server na ito ang kasaysayan at katayuan ng lahat ng operasyon ng backup, pagkopya, at pagpapanumbalik sa iyong buong topolohiya ng pagpapadala ng log.
• Mga Trabaho bilang Ahente: Kabilang ang mga trabaho sa pag-backup, pagkopya, pag-restore, at pag-alerto, na nag-a-automate sa buong proseso ng pagpapadala ng log.

Ang daloy ng trabaho sa automation ay:

1. Ang backup job ay tumatakbo sa pangunahing server at lumilikha ng mga backup ng transaction log ng pangunahing database sa backup share.
2. Ang copy job ay tumatakbo sa bawat pangalawang server at naglilipat ng mga log backup file mula sa backup share patungo sa pangalawang server(s).
3. Ang trabahong pagpapanumbalik ay tumatakbo sa bawat pangalawang server at naglalapat ng mga kinopyang backup ng talaan ng transaksyon sa pangalawang database.
4. Ang trabaho ng alerto ay tumatakbo sa monitor server at sinusuri kung ang mga operasyon sa pag-backup at pag-restore ay nakumpleto sa loob ng mga katanggap-tanggap na takdang panahon.

3. Mga Kinakailangan at Paunang Kinakailangan

3.1 SQL Server Mga Kinakailangan sa Bersyon

Ang pagpapadala ng troso ay magagamit na simula pa noong SQL Server 2000 at nananatiling sinusuportahan sa lahat ng kasunod na bersyon mula SQL Server 2005 hanggang 2025. Ang matagal nang suportang ito ay nagpapakita ng katatagan at patuloy na kaugnayan ng teknolohiya.

3.2 SQL Server Mga Kinakailangan sa Edisyon

Gumagana ang pagpapadala ng log sa mga edisyon ng Standard, Workgroup, Enterprise, at Developer. SQL ServerAng malawak na suporta sa edisyong ito ay ginagawang naa-access ang pagpapadala ng log para sa mga organisasyong walang mga lisensya sa Enterprise Edition, hindi tulad ng mga tampok tulad ng Laging Nasa Availability Groups na nangangailangan ng mga edisyon ng Enterprise o Evaluation.

Paalala: Hindi sinusuportahan ng Express Edition ang pagpapadala ng troso.

3.3 Mga Kinakailangan sa Modelo ng Pagbawi ng Database

Kinakailangan ng pagpapadala ng log para sa pangunahing database na gumamit ng full recovery model o bulk-logged recovery model. Hindi sinusuportahan ang simpleng recovery model dahil SQL Server Awtomatikong pinuputol ang mga log ng transaksyon, na sinisira ang patuloy na kadena ng log na kinakailangan para sa pagpapadala ng log.

Para sa karagdagang detalye tungkol sa mga modelo ng pagbawi, tingnan ang aming komprehensibong gabay sa SQL Server backup.

4. Pag-configure ng Pagpapadala ng Log Gamit ang SSMS

4.1 Gumawa ng Folder para sa Backup Share

Bago i-configure ang pagpapadala ng log, ihanda ang backup share folder kung saan itatago at ililipat ang mga backup ng transaction log.

1. Sa pangunahing server o isang nakalaang file server, lumikha ng isang folder (hal., C:\Backup)
2. Mag-right click sa folder at piliin Mga Katangian
3. I-click ang Pagbabahagi tab
4. I-click ang Advanced na Pagbabahagi
5. Tsek Ibahagi ang folder na ito
6. I-click ang Pahintulot at bigyan Buong kontrol pahintulot sa SQL Server account ng serbisyo Serbisyo ng NT\MSSQLSERVER.
7. I-click ang OK upang mag-aplay.
8. Idokumento ang network path (UNC) (hal., \\PANGALAN-SERVER\Backup)

4.2 Paganahin at I-configure ang Pagpapadala ng Log

1. I-right-click ang pangunahing database at piliin ang Mga Katangian.
2. Sa Mga Katangian ng Database dialog, piliin ang Pagpapadala ng Talaan ng Transaksyon pahina sa kaliwang panel.
3. Tsek Paganahin ito bilang pangunahing database sa isang configuration ng pagpapadala ng log para paganahin ang pagpapadala ng troso.
4. Pagkatapos ay maaari mong i-configure ang mga setting ng backup, pangalawang server, at monitor server sa pahina ng property na ito. Ipapakilala namin ang mga ito sa mga sumusunod na subseksyon.
   
   

4.2.1 I-configure ang Mga Setting ng Backup

1. I-click ang Mga Setting ng pag-backup butones
   
2. Sa Mga Setting ng Backup ng Log ng Transaksyon diyalogo, sa ilalim Landas ng network papunta sa backup folder field, ilagay ang UNC path (hal., \\PANGALAN-SERVER\Backup)
3. Kung ang backup folder ay nasa pangunahing server, ilagay ang lokal na path (hal., C:\Backup)
4. I-configure ang iba pang mga setting, gaya ng panahon ng pagpapanatili ng backup, limitasyon ng alerto, trabaho sa pag-backup, at compression.
5. I-click ang OK para kumpirmahin ang mga setting at isara ang dialog.
   

4.2.2 I-configure ang Secondary Server Instance at Database

1. I-click ang Idagdag sa ilalim Mga pangalawang server instance at database
2. Sa Mga Setting ng Pangalawang Database dialog, mag-click Ikabit para kumonekta sa pangalawang server instance.
3. Sa Pangalawang Database dropdown, pumili ng umiiral na database o mag-type ng bagong pangalan ng database
4. Sa Pagsisimula ng Pangalawang Database tab, piliin ang Oo, gumawa ng kumpletong backup ng pangunahing database at ibalik ito sa pangalawang database (at gumawa ng pangalawang database kung wala ito)
   
5. I-click ang Kopyahin ang Mga File tab
6. Sa Destination folder para sa mga kinopyang file (Ang folder na ito ay karaniwang matatagpuan sa pangalawang server), ilagay ang lokal na path ng destination folder sa pangalawang server.
7. Tiyaking umiiral ang folder at ang SQL Server May mga pahintulot sa pagsulat ang service account
   
8. I-click ang OK para kumpirmahin ang mga setting at isara ang dialog.

4.2.3 I-configure ang Monitor Server

1. Tsek Gumamit ng instance ng monitor server
   
   
2. I-click ang Setting
3. I-click ang Ikabit para kumonekta sa instance ng monitor server
4. Itakda Burahin ang kasaysayan pagkatapos upang tukuyin ang panahon ng pagpapanatili sa mga oras
5. I-click ang OK para kumpirmahin ang mga setting at isara ang dialog.
   
   

4.2.4 Pagsusuri at Pagkumpleto ng Konpigurasyon

1. Suriin ang lahat ng mga setting sa Pagpapadala ng Talaan ng Transaksyon pahina
2. I-verify ang mga setting ng backup, mga configuration ng pangalawang server, at mga setting ng pagsubaybay
3. I-click ang OK upang ilapat ang konpigurasyon
4. Ang wizard ay lumilikha ng lahat ng kinakailangang trabaho sa mga pangunahin, pangalawa, at monitor server.
5. I-click ang Pagsasara kapag natapos na ang configuration

5. Mga Kalamangan at Disbentaha ng Pagpapadala ng Troso

5.1 Mga Pakinabang ng SQL Server Pagpapadala ng Troso

• Solusyon na Matipid: Gumagana sa SQL Server Standard Edition, na nag-aalis ng mga mamahaling kinakailangan sa paglilisensya ng Enterprise Edition. Ginagawa nitong madaling magamit ang maaasahang disaster recovery para sa mga organisasyong may limitadong badyet.
• Madaling I-configure at Panatilihin: Ginagabayan ng configuration wizard ang mga administrator sa pag-setup gamit ang mga malinaw na opsyon. Karamihan sa mga database ay maaaring i-configure sa loob ng 15-30 minuto nang walang espesyal na pagsasanay.
• Suporta sa Maramihang Pangalawang Server: Sinusuportahan ang maraming pangalawang server nang walang mga limitasyon sa arkitektura. Mag-deploy ng isang pangalawang server para sa lokal na pagbangon mula sa sakuna, isa pa nang malayuan, at pangatlo para sa pag-uulat.
• Minimal na Epekto sa Pangunahing Server: Gumagana nang asynchronous, inaalis ang overhead ng synchronization sa pangunahing server. Hindi maaapektuhan ang mga oras ng pag-commit ng transaksyon.
• Gumagamit ng mga Umiiral nang Backup ng Transaction Log: Ang mga backup ng log shipping ay mga karaniwang backup ng log ng transaksyon, na magagamit para sa point-in-time recovery nang hiwalay sa pagpapadala ng log.
• Opsyon sa Naantalang Pagbawi: Ang tampok na restore delay ay nagbibigay ng proteksyon laban sa mga hindi sinasadyang pagbabago ng data na hindi magagamit sa mga solusyon sa replikasyon sa real-time.
• Hindi Kinakailangan ang Ibinahaging Imbakan: Gumagamit ng independiyenteng imbakan sa bawat server, na nag-aalis ng mga kinakailangan sa ibinahaging imbakan at mga kaugnay na gastos.
• Suporta sa Cross-Platform: Gumagana nang pareho sa parehong Windows at Linux SQL Server mga deployment.
• Gumagana sa Iba't Ibang Domain: Hindi nangangailangan ng mga ugnayan ng tiwala sa domain o pagsasama ng Active Directory.

5.2 Mga Disbentaha at Limitasyon ng Pagpapadala ng Troso

• Walang Awtomatikong Pag-failover: Ang pangunahing limitasyon ay ang manu-manong kinakailangan sa failover. Dapat magsagawa ang mga administrator ng maraming hakbang bago magpatuloy ang serbisyo.
• Pagkaantala sa Pag-synchronize ng Data: Ang mga pangalawang database ay palaging nahuhuli sa mga pangunahing database sa dalas ng pag-backup at pagpapanumbalik.
• Konpigurasyon sa Antas ng Database Lamang: Kino-configure sa antas ng database sa halip na sa antas ng instance. Ang pagprotekta sa 50 database ay nangangailangan ng 50 magkakahiwalay na configuration.
• Mga Pagbabago sa String ng Manu-manong Koneksyon: Dapat i-update ng mga application ang mga connection string upang tumuro sa pangalawang server pagkatapos ng failover.
• Mga Pagkaantala sa Pangalawang Database: Idinidiskonekta ng mga standby mode secondary database ang mga user habang isinasagawa ang mga operasyon sa pagpapanumbalik.
• Hiwalay na Pamamahala ng Database: Ang bawat configuration ng database ay dapat pamahalaan nang paisa-isa nang walang koordinadong kakayahan sa pamamahala.

6. Mga Pinakamahuhusay na Kasanayan at Mga Kaso ng Paggamit

6.1 Kailan Gagamitin ang Pagpapadala ng Log

• Pagbangon Mula sa Sakuna na May Mababang Badyet: Nangunguna bilang isang cost-effective na solusyon sa disaster recovery para sa mga organisasyong hindi kayang bigyang-katwiran ang mga gastos sa paglilisensya ng Enterprise Edition.
• Mga Kinakailangan sa Katamtamang RPO/RTO: Ang mga aplikasyong nakakayanan ang 15-30 minutong pagkawala ng data at 30-60 minutong downtime ay perpektong naaayon sa mga kakayahan nito.
• Server ng Pag-uulat na Read-Only: Gumawa ng mga read-only na kopya para sa pag-uulat ng mga workload na kayang tiisin ang mga pana-panahong pagkaputol ng koneksyon.
• Mga Pamantayang Edisyong Kapaligiran: Mga organisasyong inistandardisa sa SQL Server Walang access ang Standard Edition sa Always On Availability Groups, kaya ang log shipping ang pinakamahusay na opsyon na magagamit.
• Mga Proyekto sa Paglipat ng Server: Pinapadali ang mga paglipat ng server sa pamamagitan ng pagpapanatili ng mga naka-synchronize na kopya sa mga panahon ng transisyon.
• Mga Kinakailangan sa Naantalang Datos: I-configure ang mga pagkaantala sa pagpapanumbalik upang mapanatili ang mga database sa mga nakapirming punto noon para sa mga layunin ng pagsunod o pag-audit.

6.2 Kailan HINDI Dapat Gamitin ang Pagpapadala ng Log

• Mga Kinakailangan sa Halos Walang Downtime: Ang mga aplikasyon na may mga kinakailangan sa RTO na wala pang 15 minuto ay hindi maaaring umasa sa manu-manong failover.
• Kinakailangan ang Awtomatikong Failover: Hindi naaangkop kapag ang mga kinakailangan ng negosyo ay nag-aatas ng awtomatikong failover nang walang interbensyon ng administrator.
• Kinakailangan ang Real-Time Synchronization: Ang mga application na nangangailangan ng real-time o halos real-time na data sa mga secondary server ay hindi maaaring tumanggap ng likas na lag ng log shipping.
• Minimal na Toleransi sa Pagkawala ng Data: Ang mga organisasyong may RPO na nasusukat sa ilang segundo o nangangailangan ng zero data loss ay nangangailangan ng mga synchronous na solusyon.

6.3 Pinakamahusay na Kasanayan

• Pag-optimize ng Dalas ng Pag-backup: Balansehin ang dalas ng pag-backup laban sa mga layunin ng system overhead at recovery. Magsimula sa 15 minutong pagitan at isaayos batay sa aktwal na mga kinakailangan.
• Mga Pagsasaalang-alang sa Landas ng Network: Gumamit ng mga UNC path sa halip na mga naka-map na drive para sa mga lokasyon ng backup. Maglagay ng mga backup share sa maaasahang imprastraktura ng network.
• Pag-setup ng Pagsubaybay at Pag-aalerto: I-configure kaagad ang mga alerto para sa mga pagkabigo sa pag-backup, pagkopya, at pag-restore pagkatapos makumpleto ang pag-setup ng pagpapadala ng log.
• Regular na Iskedyul ng Pagsusulit: Mag-iskedyul ng quarterly o semi-annual na mga failover test upang mapatunayan ang mga pamamaraan at mapanatili ang kahandaan ng administrador.
• Pagpapanatili ng Dokumentasyon: Panatilihin ang detalyadong mga runbook na nagdodokumento ng mga detalye ng configuration, mga pamamaraan ng failover, at mga hakbang sa pag-troubleshoot.
• Mga Pagsasaalang-alang sa Seguridad: Gumamit ng mga nakalaang service account na may kaunting kinakailangang pahintulot. Paghigpitan nang naaangkop ang mga pahintulot sa pagbabahagi ng network.
• Pamamahala ng Espasyo sa Disk: Patuloy na subaybayan ang espasyo sa disk sa mga lokasyon ng backup. I-configure ang mga alerto kapag ang espasyo ay bumaba sa 20%.
• Pag-configure ng Patakaran sa Pagpapanatili: Magtakda ng mga panahon ng pagpapanatili ng backup na mas mahaba kaysa sa iyong pinakamataas na katanggap-tanggap na lag sa pag-synchronize.
• Ibalik ang Pagkaantala para sa Proteksyon: I-configure ang mga pagkaantala sa pagpapanumbalik kapag ang proteksyon laban sa mga hindi sinasadyang pagbabago ay nagbibigay-katwiran sa pagtaas ng lag sa pag-synchronize.

7. Pag-troubleshoot ng Mga Karaniwang Isyu

7.1 Mga Pagkabigo sa Backup Job

• Hindi Sapat na Disk Space: Suriin ang kasaysayan ng trabaho para sa mga error sa espasyo sa disk. I-verify ang magagamit na espasyo at libreng espasyo sa pamamagitan ng pagbura ng mga lumang backup o pagpapagana ng compression.
• Mga Isyu sa Pahintulot: I-verify ang SQL Server Ang service account ay may mga pahintulot na Full Control sa parehong lokal na folder at pagbabahagi ng network.
• Hindi Ganap na Nakabawi ang Database: Bumalik sa full recovery model at kumuha ng full backup para ma-restart ang transaction log chain.

7.2 Mga Pagkabigo sa Trabaho ng Kopya

• Hindi Mapupuntahan ang Landas ng Network: Subukan ang koneksyon mula sa pangalawang server sa pamamagitan ng manu-manong pagmamapa ng path ng network.
• Mga Problema sa Pagpapatunay: I-configure ang mga tahasang kredensyal para sa access sa pagbabahagi ng network kung ang mga server ay nasa iba't ibang domain.
• Mga Isyu sa Pagla-lock ng File: Ibukod ang backup folder mula sa antivirus real-time scanning upang maiwasan ang mga file lock.

7.3 Ibalik ang mga Pagkabigo sa Trabaho

• Mga Nawawalang Backup File: Tiyaking may mga file sa destination folder at tingnan ang history ng pagkopya.
• Error sa Pagpapanumbalik ng Pagkakasunod-sunod: Tukuyin ang mga nawawalang backup ng transaction log at ibalik ang mga ito nang sunod-sunod upang maayos ang log chain.
• Nasa Maling Estado ang Database: Muling simulan ang pagpapadala ng log sa pamamagitan ng pag-restore ng buong backup gamit ang NORECOVERY kung may nakabawi sa database.
• Katiwalian ng File ng Database: Kung magpapatuloy ang mga pagkabigo sa pag-restore sa kabila ng tamang pagkakasunod-sunod at configuration, maaaring masira ang mga database file mismo. Sa ganitong mga kaso, maaaring kailanganin mong gumamit ng espesyal na tool sa pagbawi ng sql para kumuha ng data mula sa mga sirang .MDF at .NDF file bago subukang muling simulan ang pagpapadala ng log.

7.4 Mga Isyu sa Pagkaantala ng Pag-synchronize

• Mga Limitasyon sa Bandwidth ng Network: Paganahin ang backup compression upang mabawasan ang laki ng file at mga kinakailangan sa bandwidth.
• Mataas na Dami ng Transaksyon: Isaalang-alang ang pagpapadalas ng pag-backup upang makagawa ng mas maliliit at mas madaling pamahalaang mga backup file.
• Hindi Sapat na Dalas ng Pagpapanumbalik: Dagdagan ang dalas ng trabaho sa pagpapanumbalik sa tinatayang dalas ng pag-backup at bawasan ang lag.

7.5 Mga Isyu sa Koneksyon ng Monitor Server (SQL 2025)

• Mga Error ng Tagapagbigay ng OLE DB: SQL Server Ang default na mandatory encryption ng 2025 ay sumasalungat sa mga mas lumang instance na walang wastong configuration ng encryption.
• Hindi Pagtugma ng Konfigurasyon ng Encryption: I-verify ang configuration ng naka-link na server sa monitor server at tingnan ang mga setting ng encryption.
• Mga Solusyon sa Paglutas: I-drop at muling likhain ang pagpapadala ng log gamit ang mga parameter ng TLS 1.3 o i-upgrade ang lahat ng instance sa SQL Server 2025.

7.6 SQL Server Mga Isyu sa Serbisyo ng Ahente

• Hindi Sinimulan ang Serbisyo: Suriin ang katayuan ng serbisyo ng Ahente at i-configure ito upang awtomatikong magsimula.
• Hindi Pinagana ang Iskedyul ng Trabaho: I-verify ang katayuan ng iskedyul ng trabaho at paganahin ang mga naka-disable na iskedyul.
• Mga Pagkabigo sa Hakbang ng Trabaho: Suriin ang kasaysayan ng trabaho upang matukoy ang mga hakbang na nabigo at mga partikular na mensahe ng error.

8. Mga Madalas Itanong (FAQ)

T: Maaari ko bang gamitin ang log shipping gamit ang Express Edition?

A: Hindi, SQL Server Hindi sinusuportahan ng Express Edition ang pagpapadala ng log dahil kulang ito SQL Server Ahente.

T: Gaano kadalas ko dapat iiskedyul ang mga backup ng log?

A: Ang mga default na 15 minutong pagitan ay nagbibigay ng makatwirang balanse. Ayusin batay sa iyong layunin sa pagbawi.

T: Maaari bang gamitin ang mga pangalawang database para sa pag-uulat?

A: Oo, ang mga pangalawang database na naka-configure sa standby mode ay nagbibigay-daan sa read-only na access sa pagitan ng mga operasyon ng pag-restore.

T: Ano ang mangyayari kung ang pangunahing server ay mag-crash?

A: Isagawa ang manu-manong failover upang mai-online ang isang pangalawang database. Ang pagkawala ng data ay katumbas ng lag ng synchronization sa oras ng pagkabigo.

T: Maaari ba akong magkaroon ng maraming pangalawang server?

A: Oo, sinusuportahan ng log shipping ang walang limitasyong mga pangalawang server na may mga independiyenteng configuration.

T: Paano ko kakalkulahin ang sync lag?

A: Ihambing ang huling naibalik na timestamp ng talaan ng transaksyon sa kasalukuyang oras gamit ang mga talahanayan ng pagsubaybay sa pagpapadala ng talaan.

T: Maaari bang gumana ang log shipping sa iba't ibang domain?

A: Oo, gumagana ito sa iba't ibang domain o sa mga workgroup environment nang hindi nangangailangan ng mga ugnayan ng tiwala.

T: Ano ang pagkakaiba ng No Recovery at Standby mode?

A: Walang recovery mode na nagpapanatili sa database na hindi maa-access. Pinapayagan ng standby mode ang mga read-only na query sa pagitan ng mga restore.

T: Maaari ko bang pansamantalang ihinto ang pagpapadala ng log?

A: Oo, i-disable ang mga trabahong backup, copy, at restore para i-pause ang synchronization habang pinapanatili ang configuration.

T: Paano ko aalisin ang configuration ng log shipping?

A: Sa Pagpapadala ng Talaan ng Transaksyon pahina ng ari-arian:

1. Alisin ang tsek Paganahin ito bilang pangunahing database sa isang configuration ng pagpapadala ng log
2. I-click ang OK para tanggalin ang configuration at burahin ang mga trabaho.

T: Maaari ko bang ilipat ang pangalawang database sa read-write mode?

A: Oo, isagawa ang RESTORE DATABASE WITH RECOVERY, ngunit sinisira nito ang kadena ng pagpapadala ng log.

T: Ano ang pinakamataas na delay na maaari kong i-configure para sa restore?

A: Walang tiyak na limitasyon. I-configure ang mga pagkaantala mula minuto hanggang araw batay sa iyong mga kinakailangan sa proteksyon.

T: Paano nakakaapekto ang pagpapadala ng log sa estratehiya ng pag-backup?

A: Gumagawa ito ng mga backup ng log ng transaksyon na magagamit para sa parehong pagpapadala ng log at point-in-time recovery.

T: Maaari ko bang gamitin ang log shipping para sa server migration?

A: Oo, i-configure ang pagpapadala ng log sa bagong server, i-synchronize, pagkatapos ay isagawa ang nakaplanong failover ng lumang server habang nasa maintenance.

T: Anong mga kagamitan sa pagsubaybay ang gumagana sa pagpapadala ng troso?

A: SQL Server May kasamang mga built-in na ulat ang Management Studio. Ang mga tool ng third-party tulad ng SQL Monitor at SolarWinds ay nagbibigay ng pinahusay na pagsubaybay.

9. Konklusyon at Rekomendasyon

9.1 Buod ng Mga Pangunahing Punto

SQL Server Ang log shipping ay nagbibigay ng maaasahan at matipid na disaster recovery sa pamamagitan ng awtomatikong operasyon ng pag-backup at pagpapanumbalik ng log ng transaksyon. Gumagana ang teknolohiyang ito sa Standard Edition, nangangailangan ng kaunting imprastraktura, at sumusuporta sa maraming pangalawang server.

Ang pagpapadala ng log ay mahusay para sa mga katamtamang layunin sa pagbawi kung saan katanggap-tanggap ang manu-manong failover. Kabilang sa mga pangunahing limitasyon ang kinakailangan sa manu-manong failover, lag sa pag-synchronize, at saklaw ng configuration sa antas ng database.

Ang teknolohiyang ito ay mahusay na sumasama sa mga umiiral na estratehiya sa pag-backup, sumusuporta sa read-only na pag-uulat sa pamamagitan ng standby mode, at nagbibigay ng proteksyon laban sa mga naantalang pagbabago sa pagpapanumbalik.

9.2 Paggawa ng Tamang Pagpili para sa Iyong Kapaligiran

Suriin ang pagpapadala ng troso batay sa iyong mga partikular na pangangailangan bago ipatupad. Isaalang-alang ang mga layunin sa punto ng pagbawi, mga layunin sa oras ng pagbawi, mga limitasyon sa badyet, at pagpapahintulot sa pagiging kumplikado ng operasyon.

Mga organisasyong gumagamit SQL Server Ang Standard Edition na may katamtamang mga kinakailangan sa pagbawi ay dapat na lubos na isaalang-alang ang pagpapadala ng log. Ang mga negosyo na may mahigpit na RTO na wala pang 15 minuto ay dapat suriin ang Always On Availability Groups.

Isaalang-alang ang mga hybrid na pamamaraan na pinagsasama ang pagpapadala ng troso sa iba pang mga teknolohiya para sa pag-optimize ng gastos habang natutugunan ang iba't ibang mga kinakailangan.

9.3 Mga Susunod na Hakbang at Karagdagang mga Mapagkukunan

Magsimula sa maliliit na pilot implementations upang makakuha ng karanasan. Bumuo ng komprehensibong dokumentasyon, kabilang ang mga detalye ng configuration, mga pamamaraan ng failover, at mga gabay sa pag-troubleshoot.

Mag-iskedyul ng mga regular na failover test upang mapatunayan ang mga pamamaraan at mapanatili ang kahandaan ng administrator. Manatiling napapanahon SQL Server mga update at pagpapahusay.

Mga sanggunian

• Opisyal na Dokumento ng Microsoft: Tungkol sa Pagpapadala ng Troso (SQL Server)
• Opisyal na Dokumento ng Microsoft: I-configure ang Pagpapadala ng Log (SQL Server)

---

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.