Artiklis pakutakse olulisi näpunäiteid ummikseisude vältimiseks SQL Servers
Kuigi SQL Server on viimase paari aasta jooksul olnud tohutu arengu tunnistajaks, kasutajad seisavad endiselt regulaarselt silmitsi ummikseisuga. Ideaalis peaks andmebaasiserver suutma hankida mitu päringut, kuid see põhjustab sageli blokeeringuid. Konflikte, kus üks protsess ootab teise ressursi vabastamist, nimetatakse plokkideks. Ja siis on ummikseisud.
Kujutage ette olukorda, kus üks inimene palub teisel ressurssi vabastada ja teine ootab, et esimene vabastaks. Selle tulemusena on mõlemad ummikus. Ükski protsess ei saa jätkuda, kuna mõlemad on lukustatud ja nõuavad, et teine ressursi või lukustuse vabastaks.
Töötades koos SQL servers, ummikseisud on üsna tavalised ja võivad kogu protsessi takistada. Ummikuid ei ole võimalik täielikult vältida, kuid ummiku tekkimise võimalust saab kindlasti minimeerida.
Ummikuprobleem
Enne ummikseisu minimeerimise näpunäidete juurde asumist heidame kiire pilgu ummikseisude kõige tõenäolisematele põhjustele. SQL serverd on loodud ummikseisude automaatseks tuvastamiseks, kuid kui neist teatatakse, peaksid andmebaasiadministraatorid püüdma mõista ummikseisu põhjust. Kõige levinum põhjus on andmebaasi halb disain ilma korraliku valideerimise ja testimiseta ning indekseerimise puudumine. Mõned ummikseisud on põhjustatud ka halvasti disainitud päringutest.
Tuleb märkida, et ummikseisud mõjutavad otseselt jõudlust ja võivad andmebaasi töötlemise peatada.
1. Jätke järjekord samaks
Patikukud tekivad paratamatult, kui ressursse ei töödelda täpselt määratletud järjekorras. Patikukude minimeerimiseks peaksid kõik samaaegsed tehingud objektidele juurde pääsema täpselt määratletud järjekorras. Andmebaaside haldajad peaksid andmebaasiobjektidele juurdepääsuks looma selged reeglid. Tavaliselt teostavad lukustusmonitorid ummikseisu kontrolli ja tuvastamisel valivad ühe ummikseisu ohvri ning tühistavad selle tehingu. Seega vabastatakse kõik lukud ja eelmistel seanssidel lubatakse protsessi jätkata. Patikukude ohvrid valitakse serveri määratud ummikseisu prioriteedi või tagasipööramise kulu alusel.
2. Piirang Tehingu ajal
Saate piirata kasutajatel tehingu töötlemise ajal igasuguste andmete sisestamist ja ummikseisude vältimiseks võite andmeid enne tehingut värskendada. Samuti proovige hoida kasutaja interaktsiooni minimaalsel tasemel, kuna see mõjutab kiirust. Ideaalis peaksid tehingud olema lühikesed ja kiired, et vältida ummikseisu. Rakendus peaks olema kujundatud nii, et see haaraks lukud võimalikult lühikese aja jooksul kinni ja vabastaks need võimalikult kiiresti.
3. NOLOCK Vihje
Kui keegi käivitab SQL-i vaikeisolatsioonitasemel tabeli päringu, lukustatakse tabel ja järgmised päringud peavad ootama vabastamist. NOLOCK Hint on sellistes olukordades abiks, kuna võimaldab alistada tabeli lukustamise ja muudele päringutele on lihtne juurde pääseda.
4. Kasutage seotud ühendusi
Kui sama rakendus suudab avada kaks või enam ühendust, mis võivad omavahel koostööd teha, ei tekitaks see ummikuid. Seetõttu on soovitatav kasutada seotud ühendusi.
Ummik ei ole ainuke probleem, mida te tõenäoliselt kogete a SQL Server andmebaasi. Tegelikult juhtumid sql korruptsioon tekitavad teile tõenäolisemalt leina. Andmete kadumise stsenaariumi vältimiseks investeerige võimsasse taastetööriistasse, näiteks DataNumen SQL Recovery.
Autori sissejuhatus:
Victor Simon on andmete taastamise ekspert DataNumen, Inc., mis on maailmas juhtiv andmete taastamise tehnoloogiate, sealhulgas mdb taastamine ja SQL-i taastamise tarkvaratooted. Lisateabe saamiseks külastage https://www.datanumen.com/