Pitkä SQL-työ: pidä se käynnissä, kun VPN katkeaa
Katkennut VPN jättää yhden kysymyksen, johon asiakasohjelman virhe ei vastaa: vahvistettiinko työ? Anna pitkät työt pysyvälle omistajalle ja täsmäytä ennen uutta yritystä.
VPN katkeaa kaksikymmentä minuuttia indeksin uudelleenrakennuksen alusta, SQL-asiakkaasi näyttää katkenneen yhteyden, eikä ilmeiseen kysymykseen löydy vastausta siitä virheestä. Loppuiko lause, peruutettiinko se vai jatkoiko se ilman sinua? Uudelleenyhdistäminen ja uudelleenlähetys on kolmesta vaihtoehdosta huonoin, koska se muuttaa yhden epävarman tuloksen kahdeksi mahdolliseksi. Siirrä työ jollekin, jolla on pysyvä omistaja, ennen seuraavaa ikkunaa.
Mitä yhteysvirhe ei kerro sinulle
Asiakaspään virhe kuvaa asiakasta. Se kertoo, että pistoke suljettiin, ei sitä, mitä palvelin teki transaktiolle. Lause voi yhä suorittua, se on voitu vahvistaa juuri ennen yhteyden kuolemista tai se on voitu peruuttaa, kun sen istunto siivottiin. Kaikki kolme tuottavat saman viestin kannettavallasi.
Vain palvelimen tila voi ratkaista sen. Katso sinne ennen kuin päätät mitään.
Anna työ palvelinpuolen omistajalle
Työlle, joka ei vaadi ihmistä vahtimaan, anna tietokannan isännän omistaa suoritus. SQL Server Agent ajaa töitä pyynnöstä tai aikataulun mukaan ja tallentaa jokaisen ajon, joten työn elinkaari on riippumaton VPN-istunnostasi. Työn identiteetti tarvitsee täsmälleen ne oikeudet, joita tehtävä vaatii, ei järjestelmänvalvojan täyttä interaktiivista kontekstia. Silloin kannettava käynnistää työn ja lukee tulokset sen sijaan, että se olisi prosessi, joka pitää työn elossa.
EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';Agentin saatavuus riippuu käyttöön ottamastasi versiosta ja palvelusta. Käytä mekanismia, jonka alustasi todella tarjoaa, sen sijaan että olettaisit tämän olevan kaikkialla.
Tietokannan lähellä oleva hyppyisäntä lyhentää polkua ja kannattaa olla, mutta se ei muuta omistuskysymystä. Istunto päättyy silti, kun verkko päättyy. Käytä sitä tarkkailemiseen, älä asiana, joka pitää työn elossa.
Jätä tallenne, jonka seuraava istunto voi lukea
Kirjaa työn nimi tai tunniste, kohdetietokanta ja tulos, jota odotat. Juuri se tallenne antaa toisen istunnon tai toisen henkilön vastata kysymykseen, johon virhe ei pystynyt. Ilman sitä sinulle jää epämääräinen muisto päivityksestä eikä mitään keinoa tarkistaa.
EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';Historia näyttää tuloksen ja ajoituksen vaiheittain, mikä on hyödyllisempää kuin yksi onnistumisen lippu. Lisää tietoja muuttaviin tehtäviin myös sovelluksen oma varmistus: rivimäärä, tarkistussumma tai työn kirjoittama tilausrivi. Kaksi riippumatonta tallennetta tekee uudelleenyrityksestä turvallisen, ja tallennettu työhistoria on niistä ensimmäinen.
Täsmäytä ennen uudelleenlähetystä
Kun tarkkaileva yhteys katoaa, etsi olemassa oleva ajo ennen kuin aloitat toisen. Lue sen vaiheiden tulokset ja päätä, vahvistettiinko työ, valmistuiko se osittain vai eikö se koskaan alkanut. Vasta sitten sovella työnkulun määrittämää uudelleenyrityksen sääntöä, koska sokea uudelleenlähetys voi kopioida latauksen tai epäonnistua toisen kerran puolivälissä.
Pidä pysyvä omistaja ja tarkasteltava tulos, ja lyhyt käyttökatko muuttuu vaivaksi eikä arvaukseksi. Se on koko suunnittelun tavoite: työn pitäisi elää pidempään kuin yhteys, joka sitä pyysi.