Mahabang SQL job: panatilihin itong tumatakbo kapag bumagsak ang VPN

Bumabagsak ang VPN dalawampung minuto pagkatapos magsimula ang rebuild ng index, nagpapakita ang SQL client mo ng sirang koneksyon, at ang halatang tanong ay walang sagot sa error na iyon. Natapos ba ang statement, na-rollback, o nagpatuloy na tumakbo nang wala ka? Ang muling pagkonekta at muling pagsumite ang pinakamasama sa tatlong opsyon, dahil ginagawa nitong dalawa ang isang hindi tiyak na resulta. Ilipat ang trabaho sa isang bagay na may matibay na may-ari bago ang susunod na window.

Ang hindi sinasabi ng error sa koneksyon

Ang error sa panig ng client ay naglalarawan sa client. Iniulat nito na nagsara ang socket, hindi kung ano ang ginawa ng server sa transaksyon. Maaaring tumatakbo pa ang statement, maaaring na-commit bago pa mamatay ang link, o maaaring na-rollback nang linisin ang session nito. Pareho ang mensaheng ibinibigay ng tatlo sa laptop mo.

Ang estado lang ng server ang makakapagpasya nito. Tumingin doon bago magpasya ng kahit ano.

Ipaubaya ang trabaho sa may-ari sa panig ng server

Para sa trabahong hindi kailangan ng taong magbabantay, hayaan ang host ng database na magmay-ari ng pagpapatupad. Ang SQL Server Agent ay nagpapatakbo ng mga job kapag hiniling o ayon sa iskedyul at itinatala ang bawat pagtakbo, kaya ang lifecycle ng job ay independiyente sa session ng VPN mo. Ang identity ng job ay nangangailangan ng eksaktong mga pahintulot na hinihingi ng gawain, hindi ang buong interactive na konteksto ng isang administrator. Pagkatapos, sinisimulan ng laptop ang trabaho at binabasa ang mga resulta sa halip na maging prosesong nagpapanatili nitong buhay.

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

Ang pagkakaroon ng Agent ay depende sa edition at serbisyong na-deploy mo. Gamitin ang mekanismong aktuwal na ibinibigay ng platform mo sa halip na ipagpalagay na may ganito sa lahat ng lugar.

Ang jump host na malapit sa database ay nagpapamaikli ng landas at sulit na magkaroon, pero hindi nito binabago ang tanong ng pagmamay-ari. Nagtatapos pa rin ang session kapag nagtapos ang network. Gamitin ito para magmasid, hindi para maging bagay na nagpapanatili sa trabahong buhay.

Mag-iwan ng rekord na mababasa ng susunod na session

Itala ang pangalan ng job o identifier, ang target na database at ang resultang inaasahan mo. Ang rekord na iyon ang nagpapahintulot sa ibang session, o ibang tao, na sagutin ang tanong na hindi nasagot ng error. Kung wala ito, natitira lamang ang malabong alaala ng isang update at walang paraan upang suriin.

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

Ipinapakita ng history ang resulta at oras sa bawat hakbang, na mas kapaki-pakinabang kaysa isang success flag. Para sa mga gawaing nagbabago ng data, idagdag din ang sariling verification ng application: bilang ng row, checksum, o status row na isinulat ng job. Dalawang independiyenteng rekord ang nagpapasiguro sa isang retry, at ang naitalang job history ang una sa kanila.

I-reconcile bago muling magsumite

Kapag nawala ang sumusubaybay na koneksyon, hanapin ang umiiral na run bago magsimula ng iba. Basahin ang resulta ng mga hakbang nito at magpasya kung na-commit, bahagyang natapos, o hindi kailanman nagsimula ang trabaho. Pagkatapos lamang ilapat ang panuntunan sa retry na tinutukoy ng workflow, dahil ang bulag na muling pagsumite ay maaaring magdoble ng load o mabigo sa kalahati sa ikalawang pagkakataon.

Panatilihin ang matibay na may-ari at ang nasusuri na resulta, at ang maikling pagkabigo sa access ay nagiging abala sa halip na hula. Iyon ang buong layunin ng disenyo: dapat mabuhay ang trabaho nang mas matagal kaysa sa koneksyong humiling nito.