- Tuvastab riist- ja tarkvara tõrkeid, reguleerib ajalõpusid ja hoiab ära valepositiivsed tulemused peegeldamisel.
- Parandab jõudlust halvendavaid mustreid: N+1, WHERE-funktsioonid ja puuduvad indeksid.
- Väldi SQL-vigu (süntaks, järjekord, aliased) ja halbu disainipraktikaid (PK-d, normaliseerimine).
- Rakendage KEDB, et lahendada korduvaid intsidente kiiresti ja läbipaistvalt.
Eesmärk on, et teil oleks selge tegevuskava: miks need probleemid tekivad, kuidas neid tuvastada ja milliseid meetmeid võtta. Leiate üksikasjalikud juhised SQL Serveri riist- ja tarkvaravigade (peegeldamise) , jõudlust halvendavate mustrite, levinud päringute kirjutamise vigade, klassikaliste modelleerimis-/arenduslõksude ning ITIL/ITSM-lähenemisviisi korduvate intsidentide dokumenteerimiseks ja lahendamiseks hästi struktureeritud võtmega vigade andmebaasi (KEDB) abil.
Riistvaravead: märgid, põhjused ja reaktsiooniajad
Füüsilised rikked ilmnevad tavaliselt kiiresti, kuna teised süsteemikomponendid teavitavad andmebaasimootorit. Sellisel juhul saab server kohe riistvaravea teate , kuigi mõnikord esineb viivitusi võrgu või I/O taimerite tõttu, mis lükkavad teavituse saamist edasi.
Levinud põhjuste hulka kuuluvad katkine ühendus või kahjustatud kaabel , rikkis võrgukaart, ruuteri või tulemüüri muudatused, lõpp-punkti ümberkonfigureerimine, tehingulogi majutava draivi kadumine või protsessi/operatsioonisüsteemi vead. Need probleemid, kui need mõjutavad logiketast või võrku, võivad põhjustada kõike alates ühenduse katkemisest kuni tõsiste häireteni andmebaasi replikatsioonis või peegeldamises.
Pidage meeles, et mõned võrgukomponendid ja teatud sisend-/väljundalamsüsteemid rakendavad oma sisemisi ajalõpusid . Need ajalõpud on andmebaasist sõltumatud ja võivad tuvastamist edasi lükata, suurendades ajavahemikku tegeliku rikke ja mootori sellest teadlikuks saamise vahel.
Et paremini aru saada, mis "võrgus" toimub, on kasulik küsida võrgumeeskonnalt, millised sõnumid saabuvad porti tüüpiliste sündmuste ajal, näiteks DNS-katkestuste, lahtiühendatud kaablite, tulemüüri portide blokeerimise , porti kuulava rakenduse krahhide, serveri nime muutuste või taaskäivitamise ajal. See sümptomite loetelu kiirendab diagnoosimist, kui teenus ootamatult peatub.
Tarkvaravead ja ajalõpud: millal neid parandada ja kuidas vältida valepositiivseid tulemusi
Tarkvararikked ei edasta iseenesest midagi: server võib jääda lõputult jõudeolekusse ilma jälgimismehhanismita. Seetõttu pingitakse sellistes stsenaariumides nagu andmebaasi peegeldamine eksemplare perioodiliselt ja kui kokkulepitud aja jooksul signaali ei saada, loetakse probleem tekkinuks.
Neid ooteaegu käivitavate tingimuste hulka kuuluvad võrguvead (TCP ajalõpud, rikutud, kadunud või valesti järjestatud paketid) , reageerimata operatsioonisüsteem/server/andmebaas, Windowsi tasemel aegumised ja ressursside puudus: ketta või protsessori küllastus, 100% tehingulogi, ebapiisav mälu või niitide arv.
Kui satute sellisesse olukorda, saate valida ajalõpu suurendamise, koormuse vähendamise või riistvara uuendamise, et nõudlusega toime tulla. Liiga madala ajalõpu määramine põhjustab valepositiivseid tulemusi; liiga kõrge ajalõpu määramine viivitab tegelike tõrgetega toimetulekut.
SQL Serveri peegeldamise pingi/ajalõpu mehhanism
Iga ühenduse aktiivsena hoidmiseks saadab iga eksemplar pingisid kindla intervalliga. Kui ping saabub ajalõpuakna (pluss saatmisaeg) jooksul , eeldatakse, et side on aktiivne ja taimer lähtestatakse. Kui selle intervalli jooksul pingi ei saabu, loetakse ajalõpp möödunuks ja ühendus suletakse, kusjuures sündmust käsitletakse vastavalt rollile ja töörežiimile.
Isegi kui teine server töötab korrektselt, loetakse ajalõppu tõrkeks . Kui konfigureeritud väärtus on keskkonna tavapärase latentsuse jaoks liiga lühike, ilmuvad "fantoomvead". Seetõttu on soovitatav mitte minna alla 10 sekundi.
Suure jõudlusega režiimis on ajalõpp alati 10 sekundit ; see on tavaliselt valepositiivsete tulemuste vältimiseks piisav. Kõrge turvalisusega režiimis on vaikeväärtus samuti 10 sekundit, kuid see on konfigureeritav; kui võrk on aeglane, reguleerige seda selles režiimis 10 sekundile või rohkemale.
Kui teil on vaja seda muuta, pidage meeles, et see muudatus kehtib ainult kõrge turvalisusega seansside kohta . Saate seda vaadata ja muuta mootori administreerimisest või T-SQL-i abil, olenevalt teie versioonist ja poliitikatest.
Kuidas server vea korral reageerib
Mis tahes tüüpi vea korral käitub eksemplar vastavalt oma rollile (esmane/tunnistaja/teisejärguline), töörežiimile ja ühenduse olekule . Partneri kadumise korral erineb käitumine olenevalt sellest, kas oleme tunnistajaga suure jõudlusega või kõrge turvalisusega režiimis, seega on seisakute ja ümberlülituste ennetamiseks oluline dokumenteerida iga seansi töörežiim.
SQL-i jõudlust kahjustavad mustrid (ja kuidas neid parandada)
On neli väga levinud "pattu", mis latentsust asjatult suurendavad. Neid on lihtne märgata ja nende vältimine säästab protsessori, sisend-/väljundressursse ja andmebaasi ligipääsu esimesest päevast alates.
Päringud tsüklites: päringu käivitamine iteratsiooni kohta (klassikaline N+1) korrutab päringute arvu ja latentsust. Andmete korraga hankimine unioni või IN abil või pakkpäringute kasutamine. Loogika töötlemine oma koodis, kasutades mällu juba laaditud struktuure.
Liiga suure hulga andmete laadimine – mittevajalike veergude ja ridade hankimine – on nagu pähkli purustamine haamriga. Filtreeri andmebaasi, vali ainult vajalik , kasuta vajadusel lehekülgi ja väldi SELECT * käsku, kui sul pole selget põhjust.
WHERE-klausli funktsioonid: LOWER(), DATE() või muude funktsioonide rakendamine veergudele takistab sageli indeksite kasutamist. Parem on võrrelda ilma veergu teisendamata: eeltöödelge andmed kõigepealt või teisendage literaal. Näiteks filtreerige kuupäevavahemiku järgi, kasutades kuupäeva/kellaaja veerge ilma neid funktsioonidesse murdmata.
Puuduvad indeksid: Filtreerivate või liidetavate veergude indeksite unustamine on nagu täieliku skannimise küsimine. Vaadake perioodiliselt üle, kus teie rakendus filtreerib/liitub, ja looge sobivad indeksid (vajadusel liitindeksid). Tasakaal: Liiga palju indekseid karistab kirjutamist.
Tüüpilised vead SQL-i kirjutamisel: süntaks, järjekord ja mitmetähenduslikkused
Enamik algajate (ja isegi mõnede kogenumate kasutajate) tehtud vigu on seotud süntaksi ja SQL-süstimisega . Andmebaas ei saa aru, mida sa temalt küsid, ja kurdab. Teksti esiletõstmisega redaktor aitab, kuid levinud lõksude tundmine kiirendab protsessi.
Kirjutamisvead: Vead FROM-i, WHERE-i või tabeli/veergude nimedega on tavalised. Teated näitavad tavaliselt, kus parser eksib . Kasutage esiletõstmise ja automaatse täitmisega redaktorit; kui märksõna pole esile tõstetud, olge kahtlustav.
Sulud ja jutumärgid: Puuduvad sulud või jutumärgid tekitavad raskesti märgatava probleemi. Pidage meeles operaatorite järjestust (JA/VÕI) ja grupeerige tekst sulgudega. Tekstiliteraalides kasutage sisemisi jutumärke vaheldumisi või kasutage üksik- ja kahekordseid jutumärke, et vältida stringi katkemist (nt O'Reilly).
Vigane järjestus SELECT-is: õige järjestus on SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY . ORDER BY või HAVING järjestuse muutmine põhjustab vigu. Jätke see meelde või hoidke spikker käepärast.
Jäta tabeli aliased välja: Iseliitumisel või kui kahel tabelil on sama nimega veerud, saad vea „ebamäärane veerg“. Kasuta lühikesi ja selgeid aliase ning viita veergudele atribuudiga `alias.column`. See muudab SQL-i ka loetavamaks.
Suur- ja väiketähtedega eristavad nimed: kui te kindlasti peate kasutama suur- ja väiketähtedega eristavaid nimesid, peate need otsingumootorist olenevalt jutumärkidesse panema. Parim on neid nimesid vältida; vastasel juhul olge nende viitamisel järjepidev.
Levinud vead andmebaaside arendamisel
Lisaks päringute kirjutamisele on ka disainiotsuseid, mis mõjutavad keskpikas ja pikas perspektiivis. Siin on viis levinud arendusviga koos sellega, mida nende asemel teha terviklikkuse ja hooldatavuse kaitsmiseks.
Salvestatud protseduuride ülekasutamine: need on kasulikud, kuid tänapäevaste ORM-ide ja juurdepääsukihtidega ei pea te enam kogu oma loogikat neisse panema. Salvestatud protseduuridel on hooldus- ja versioonimiskulud ; looge salvestatud protseduure andmetele juurdepääsuks, kui see on põhjendatud, mitte rakenduse äriloogika jaoks.
Vältige primaarvõtmete kasutamist: unikaalsuse delegeerimine vaadetele, salvestatud protseduuridele või rakendusele suurendab keerukust ja vigu. Määrake kõigis tabelites reaalsed primaarvõtmed ja kasutage vajaduse korral unikaalseid võtmeid; see hoiab ära järeldeduplikatsiooni ja habraste päringute tekkimise.
Püsiv kustutamine pehme kustutamise asemel: andmete füüsiline kustutamine muudab auditid ja taastamise keerulisemaks olukorrast „ups, ma ajasin kõik untsu“. Paljude kasutusjuhtude puhul lisage aktiivne/mitteaktiivne (pehme kustutamine) lipp ja jätke see oma päringutest välja. Jätke füüsiline kustutamine kontrollitud puhastuste jaoks.
Teadaolevate vigade andmebaas (KEDB): mis see on ja miks see on teie jaoks hea mõte
Operatsioonides ei saa kõike koheselt lahendada. Ajutised lahendused (möödasõidud) on piiratud ressursside, keerukuse või äritegevuse järjepidevuse vajaduse tõttu vältimatud . KEDB on hoidla, kuhu dokumenteeritakse kõik teadaolevad vead, nende põhjus (kui see on olemas) ja ajutine või püsiv lahendus.
See on osa ITIL-i raamistikust ning on seotud probleemihalduse ja teadmushaldusega. Korduva intsidendi ilmnemisel konsulteerib meeskond KEDB-ga, rakendab tõestatud lahendust ja vähendab seisakuid, selle asemel et nullist alustada.
Kasutajate eelised: kiirem probleemide lahendamine, vähem katkestusi ja prognoositavamad tulemused . IT jaoks: tõhusus (pole vaja jalgratast leiutada), teadmiste säilitamine hoolimata personali lahkumisest ja andmed pidevaks täiustamiseks. Sidusrühmade jaoks: läbipaistvus, teadlikud otsused võimsuse/riski kohta ja kulude kokkuhoid.
Kuidas samm-sammult tõhusat KEDB-d rakendada
1) Määrake ulatus ja eesmärgid: otsustage, millised tõrked on hõlmatud (tarkvara, riistvara, võrk või konkreetsed valdkonnad), kuidas neid liigitatakse ja milliseid eesmärke te taotlete ( keskmise tsükli kiiruse vähendamine, rahulolu parandamine jne). Prioriseerige kriitilised süsteemid ja teenused ning viige ulatus vastavusse ärieesmärkide ja teenusetaseme lepingutega.
Juhtküsimused: Kas see hõlmab kõike või alustame kõige mõjukamatest probleemidest? Kas meie peamine eesmärk on lühendada lahendusaega või tuvastada ka mustreid ennetamiseks?
2) Kogumine ja dokumenteerimine: Tehke koostööd intsidentide/probleemide haldamise osakonna ja meeskondadega, et jäädvustada korduvaid vigu ja tõhusaid lahendusi , mida pole veel dokumenteeritud. Kasutage lihtsat malli selliste väljadega nagu kirjeldus, algpõhjus (kui teada), ajutine/püsiv lahendus, mõju, kuupäevad ja märkused.
Näpunäited: selge keel, tegutsemisjuhised, abistavad klassifikatsioonid, seotud juhtumite linkimine ja kirjete ajakohastamine uute arengute ilmnemisel.
3) Valige tööriist: teil on vaja head otsingut, kategoriseerimist/sildistamist, üksustevahelisi linke, skaleeritavust, aruandlust ja võimalust integreeruda oma ITSM-platvormiga. Eelistage kasutajasõbralikku liidest, et soodustada kasutuselevõttu; kaaluge tehisintellektil põhinevat otsingut ja kohandatavaid töövooge.
4) Koolitage meeskondi: õpetage neile, kuidas tõhusalt dokumenteerida, tõhusalt otsida ja kvaliteeti säilitada. Lisage praktilisi harjutusi reaalsete juhtumitega , kiirjuhendeid, videoid, mentorlust ja regulaarseid täiendkoolitusi. Julgustage tagasisidet protsessi täiustamiseks.
5) Säilitamine ja täiustamine: määrake vastutusvaldkonnad, peamised tulemusnäitajad ja läbivaatamistsükkel (kriitiliste probleemide korral iga kuu, kõige muu korral kvartalis). Luua uute kirjete vastastikune hindamine, pidev dokumenteerimine pärast iga probleemi ning tagasisidekanal kasutajatelt ja toelt.
6) Edendage selle kasutamist: korraldage sisemine kampaania, tunnustage neid, kes panustavad kõige rohkem, ja edendage osakondade (võrk, tarkvara, riistvara) vahelist koostööd . Integreerige KEDB teeninduskultuuri nii, et see oleks esimene koht, kuhu inimesed vaatavad.
KEDB vs. teadmusbaas (KDB): peamised erinevused
KEDB keskendub teadaolevatele tõrgetele ja nende lahendustele (ajutised või püsivad), mis on tihedalt seotud probleemide ja intsidentide haldamisega. See on tavaliselt integreeritud IT-teenuste haldamisega (ITSM) ja selle peamine sihtrühm on tehniline meeskond, kes lahendab intsidente.
KEDB hõlmab palju enamat: parimaid tavasid, protseduure, konfiguratsiooniandmeid, abiartikleid ja muud. Selle hooldus on ulatuslikum, lisaks tehnilistele artiklitele tehakse ka protseduuride ja parimate tavade parandusi . Lühidalt: KEDB on spetsialiseeritud alamhulk põhimõttele „kui see ebaõnnestub, tee seda muud asja“.
Nagu näete, sõltuvad andmebaasi stabiilsus ja jõudlus sama palju füüsiliste ja loogiliste tõrgete (ja nende avastamise aja) mõistmisest kui hea SQL-i kirjutamisest, intelligentsest modelleerimisest ja operatiivsete teadmiste korraldamisest. Kui parandate neli jõudlusmustrit, väldite tüüpilisi süntaksivigu, kasutate tugevaid primaarvõtmeid ja mõistlikku normaliseerimist ning loote ka reaalajas andmebaasi haldussüsteemi (KEDB), on teil kiirem, prognoositavam ja hõlpsamini kasutatav platvorm isegi siis, kui asjad lähevad valesti.
