Gabime të zakonshme në një bazë të dhënash: shkaqet, gabimet dhe zgjidhjet

Informatec Digital » Bazat e të dhënave » Gabime të zakonshme në një bazë të dhënash: shkaqet, gabimet dhe zgjidhjet

Qëllimi është që ju të largoheni me një plan të qartë veprimi: pse ndodhin këto probleme, si t'i zbuloni ato dhe çfarë veprimesh duhet të ndërmerrni. Do të gjeni udhëzime të hollësishme mbi gabimet e harduerit dhe softuerit në SQL Server (pasqyrim) , modelet që dëmtojnë performancën, gabimet e zakonshme të shkrimit të pyetjeve, grackat klasike të modelimit/zhvillimit dhe një qasje ITIL/ITSM për dokumentimin dhe zgjidhjen e incidenteve të përsëritura me një Bazë të Dhënash të Gabimeve me Çelësa (KEDB) të strukturuar mirë.

Gabimet e harduerit: shenjat, shkaqet dhe koha e reagimit

Dështimet fizike zakonisht bëhen të dukshme shpejt sepse komponentët e tjerë të sistemit e njoftojnë motorin e bazës së të dhënave. Kur kjo ndodh, serveri merr një raport të menjëhershëm gabimi hardueri , megjithëse ndonjëherë ka vonesa për shkak të kohëmatësve të rrjetit ose të I/O që e shtyjnë njoftimin.

Shkaqet e zakonshme përfshijnë një lidhje të prishur ose kabllo të dëmtuar , një kartë rrjeti që dështon, ndryshime në router ose firewall, rikonfigurim të pikës fundore, humbje të diskut që strehon regjistrin e transaksioneve ose gabime të procesit/OS-it. Këto probleme, nëse ndikojnë në diskun e regjistrit ose në rrjet, mund të shkaktojnë çdo gjë, nga shkëputjet deri te ndërprerjet serioze në replikimin ose pasqyrimin e bazës së të dhënave.

Kini parasysh se disa komponentë të rrjetit dhe disa nënsisteme I/O aplikojnë afatet e tyre të brendshme kohore . Këto afate kohore janë të pavarura nga baza e të dhënave dhe mund të vonojnë zbulimin, duke rritur intervalin midis defektit aktual dhe kohës kur motori bëhet i vetëdijshëm për të.

Për të kuptuar më mirë se çfarë po ndodh "në rrjet", është e dobishme të pyesni ekipin e rrjetit se çfarë mesazhesh po mbërrijnë në port gjatë ngjarjeve tipike, të tilla si ndërprerjet e DNS-it, kabllot e shkëputura, bllokimi i portit të firewall-it , rrëzimet e aplikacionit që dëgjon në port, ndryshimet e emrit të serverit ose një rinisje. Ky inventar simptomash përshpejton diagnostikimin kur shërbimi ndalet papritur.

Gabimet dhe afatet kohore të softuerit: kur t'i rregulloni ato dhe si të shmangni pozitivet e rreme

Dështimet e softuerit nuk komunikojnë vetë: serveri mund të mbetet pa punë për një kohë të pacaktuar pa një mekanizëm monitorimi. Prandaj, në skenarë si pasqyrimi i bazës së të dhënave, instancat pingohen periodikisht dhe nëse nuk merret asnjë sinjal brenda afatit kohor të rënë dakord, konsiderohet se ka ndodhur një problem.

Ndër kushtet që shkaktojnë këto kohë pritjeje janë gabimet e rrjetit (skadimi i kohës TCP, paketa të korruptuara, të humbura ose të renditura gabimisht) , një sistem operativ/server/bazë të dhënash që nuk përgjigjet, skadimet në nivelin e Windows dhe mungesa e burimeve: mbingarkesa e diskut ose e CPU-së, regjistri i transaksioneve 100%, memorie ose fije të pamjaftueshme.

Nëse e gjeni veten në këtë situatë, mund të zgjidhni të rrisni kohën e skadimit, të zvogëloni ngarkesën ose të përmirësoni harduerin për të përballuar kërkesën. Vendosja e kohës së skadimit shumë e ulët shkakton rezultate pozitive të rreme; vendosja e tij shumë e lartë vonon përgjigjen ndaj dështimeve aktuale.

Mekanizmi i ping/kohëzgjatjes në pasqyrimin e SQL Server

Për të mbajtur çdo lidhje gjallë, çdo instancë dërgon ping-e në një interval të caktuar. Nëse një ping merret brenda dritares së kohës së skadimit (plus kohës së dërgimit) , komunikimi supozohet të jetë aktiv dhe kohëmatësi rivendoset. Nëse nuk arrin asnjë ping brenda atij intervali, koha e skadimit konsiderohet të ketë skaduar dhe lidhja mbyllet, me ngjarjen që trajtohet sipas rolit dhe mënyrës së funksionimit.

Edhe nëse serveri tjetër po funksionon siç duhet, një skadencë kohore konsiderohet dështim . Nëse vlera e konfiguruar është shumë e shkurtër për vonesën normale të mjedisit, do të shfaqen gabime "fantom". Prandaj, rekomandohet që të mos bjerë nën 10 sekonda.

Në modalitetin me performancë të lartë, koha e pritjes është gjithmonë 10 sekonda ; kjo zakonisht është e mjaftueshme për të shmangur pozitivet e rreme. Në modalitetin me siguri të lartë, vlera e parazgjedhur është gjithashtu 10 sekonda, por është e konfigurueshme; rregullojeni atë në 10 sekonda ose më shumë në këtë modalitet nëse rrjeti është i ngadaltë.

Nëse keni nevojë ta ndryshoni, mbani mend se ky modifikim është specifik për seancat me siguri të lartë . Mund ta shikoni dhe modifikoni atë nga administrimi i motorit ose duke përdorur T-SQL, varësisht nga versioni dhe politikat tuaja.

Si reagon serveri kur ka një gabim

Në rast të çdo lloj gabimi, instanca vepron sipas rolit të saj (primar/dëshmitar/sekondar), mënyrës së funksionimit dhe statusit të lidhjes . Nëse humbet një partner, sjellja ndryshon në varësi të faktit nëse jemi në modalitet me performancë të lartë apo me siguri të lartë me një dëshmitar, kështu që është thelbësore të dokumentohet mënyra e funksionimit të secilës seancë për të parashikuar ndërprerjet dhe kalimet në sisteme të ndryshme.

Modelet që ulin performancën në SQL (dhe si t'i rregulloni ato)

Ekzistojnë katër "mëkate" shumë të zakonshme që përkeqësojnë pa nevojë vonesën. Ato janë të lehta për t'u dalluar dhe shmangia e tyre do të kursejë qasje në CPU, I/O dhe bazën e të dhënave që nga dita e parë.

Pyetjet brenda sytheve: ekzekutimi i një pyetjeje për përsëritje (klasiku N+1) shumëfishon udhëtimet dhe vonesën. Merrni të dhënat të gjitha menjëherë me një bashkim ose një IN, ose përdorni pyetje në grup. Përpunoni logjikën në kodin tuaj duke përdorur strukturat e ngarkuara tashmë në memorie.

Ngarkimi i shumë të dhënave—kërkimi i kolonave dhe rreshtave që nuk do t'i përdorni—është si të përdorni një çekiç për të thyer një arrë. Filtroni bazën e të dhënave, zgjidhni vetëm atë që është e nevojshme , përdorni faqosjen nëse është e përshtatshme dhe shmangni SELECT * përveç nëse keni një arsye të qartë.

Funksionet në klauzolën WHERE: Zbatimi i LOWER(), DATE() ose të tjerëve në kolona shpesh parandalon përdorimin e indekseve. Është më mirë të krahasohen pa transformuar kolonën: përpunoni paraprakisht të dhënat së pari ose transformoni literalin. Për shembull, filtroni sipas diapazonit të datave duke përdorur kolonat e datës/orës pa i mbështjellë ato në funksione.

Indekset që mungojnë: Harrimi i indekseve në kolonat që filtrohen ose bashkohen është si të kërkosh një skanim të plotë. Rishikoni periodikisht se ku filtrohet/bashkohet aplikacioni juaj dhe krijoni indekset e duhura (indekse të përbëra kur është e nevojshme). Ekuilibri: Shumë indekse penalizojnë shkrimet.

Gabime tipike gjatë shkrimit të SQL: sintaksa, rendi dhe paqartësitë

Shumica e gabimeve të bëra nga fillestarët (dhe madje edhe nga disa përdorues më me përvojë) lidhen me sintaksën dhe injeksionin SQL . Baza e të dhënave nuk e kupton se çfarë po i kërkoni dhe ankohet. Një redaktues me nënvizim të tekstit ndihmon, por njohja e grackave të zakonshme e përshpejton procesin.

Fjalë të shkruara gabim: Gabimet me emrat FROM, WHERE ose të tabelave/kolonave janë të zakonshme. Mesazhet zakonisht tregojnë se ku po dështon analizuesi . Përdorni një redaktues me theksim dhe plotësim automatik; nëse një fjalë kyçe nuk është e theksuar, kini dyshime.

Kllapat dhe thonjëzat: Mungesa e kllapave ose thonjëzave krijon një problem të vështirë për t'u parë. Mbani mend përparësinë e operatorit (AND/OSE) dhe gruponi tekstin me kllapa. Në tekstin literal, shmangni thonjëzat e brendshme ose alternoni midis thonjëzave të vetme dhe të dyfishta për të shmangur ndërprerjen e vargut (p.sh., O'Reilly).

Renditje e pavlefshme në SELECT: renditja e saktë është SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY . Ndryshimi i rendit të ORDER BY ose HAVING do të shkaktojë gabime. Mësojeni përmendësh këtë ose mbani një fletë mashtrimi afër.

Hiq pseudonimet e tabelave: Në një vetëbashkim ose kur dy tabela kanë kolona me të njëjtin emër, do të shfaqet një gabim "kolonë e paqartë". Përdorni pseudonime të shkurtra dhe të qarta dhe kolona referimi me `alias.column`. Kjo gjithashtu e bën SQL-në më të lexueshme.

Emra të ndjeshëm ndaj shkronjave të mëdha dhe të vogla ose emra të veçantë: Nëse këmbëngulni të përdorni emra që ndryshojnë ndaj shkronjave të mëdha dhe të vogla ose ndaj hapësirave, do t'ju duhet t'i vendosni në thonjëza dyshe , varësisht nga motori i kërkimit. Është më mirë t'i shmangni këta emra; përndryshe, jini konsistent kur i citoni.

Gabime të zakonshme në zhvillimin e bazës së të dhënave

Përtej pyetjeve të shkrimit, ka vendime dizajni që bëjnë diferencën në planin afatmesëm dhe afatgjatë. Ja pesë gabime të zakonshme në zhvillim, së bashku me atë që duhet bërë në vend të kësaj për të mbrojtur integritetin dhe mirëmbajtjen.

Mbipërdorimi i procedurave të ruajtura: Ato janë të dobishme, por me ORM-të moderne dhe shtresat e aksesit, nuk keni më nevojë të vendosni të gjithë logjikën tuaj në to. Procedurat e ruajtura kanë kosto mirëmbajtjeje dhe versionimi ; krijoni procedura të ruajtura për akses në të dhëna kur justifikohet, jo për logjikën e biznesit të aplikacionit.

Shmangni përdorimin e çelësave primarë: delegimi i veçantisë te pamjet, procedurat e ruajtura ose aplikacioni shumëfishon kompleksitetin dhe gabimet. Përcaktoni çelësa primarë realë në të gjitha tabelat dhe përdorni çelësa unikë aty ku është e përshtatshme; kjo do të parandalojë pyetjet pas deduplikimit dhe ato të brishta.

Fshirja e fortë në vend të fshirjes së butë: Fshirja fizike e të dhënave ndërlikon auditimet dhe rikuperimin nga "ups, e ngatërrova". Për shumë raste përdorimi, shtoni një flamur aktiv/joaktiv (fshirje e butë) dhe përjashtojeni atë nga pyetjet tuaja. Lëreni fshirjen fizike për pastrime të kontrolluara.

Baza e të Dhënave të Gabimeve të Njohura (KEDB): Çfarë është dhe pse është një ide e mirë për ju

Në operacione, jo gjithçka mund të zgjidhet menjëherë. Zgjidhjet e përkohshme (zgjidhjet alternative) janë të pashmangshme për shkak të burimeve të kufizuara, kompleksitetit ose nevojës për vazhdimësi të biznesit . KEDB është depoja ku dokumentoni çdo gabim të njohur, shkakun e tij (nëse ka) dhe zgjidhjen e tij të përkohshme ose të përhershme.

Është pjesë e strukturës ITIL dhe ndërthuret me Menaxhimin e Problemeve dhe Menaxhimin e Njohurive. Kur lind një incident i përsëritur, ekipi konsultohet me KEDB, zbaton zgjidhjen e provuar dhe zvogëlon kohën e ndërprerjes në vend që të fillojë nga e para.

Përfitimet për përdoruesit: zgjidhje më e shpejtë, më pak ndërprerje dhe rezultate më të parashikueshme . Për IT-në: efikasitet (nuk ka nevojë të shpikësh rrotën nga e para), ruajtje e njohurive pavarësisht fluksit të personelit dhe të dhëna për përmirësim të vazhdueshëm. Për palët e interesuara: transparencë, vendime të informuara për kapacitetin/rrezikun dhe kursime të kostove.

Si të zbatohet një KEDB efektiv hap pas hapi

1) Përcaktoni fushëveprimin dhe objektivat: vendosni se cilat dështime përfshihen (softuer, harduer, rrjet ose fusha specifike), si klasifikohen ato dhe cilat qëllime po ndiqni ( zvogëloni MTTR-në, përmirësoni kënaqësinë , etj.). Prioritizoni sistemet dhe shërbimet kritike dhe përshtatni fushëveprimin me objektivat e biznesit dhe SLA-të.

Pyetje udhëzuese: A i mbulon të gjitha apo fillojmë me çështjet me më shumë ndikim? A po kërkojmë kryesisht të shkurtojmë kohën e zgjidhjes apo edhe të zbulojmë modele për parandalim?

2) Mbledh dhe dokumento: Puno me Menaxhimin e Incidenteve/Problemeve dhe ekipet për të kapur gabimet e përsëritura dhe zgjidhje efektive që nuk janë dokumentuar ende. Përdor një shabllon të thjeshtë me fusha të tilla si përshkrimi, shkaku rrënjësor (nëse dihet), zgjidhja e përkohshme/e përhershme, ndikimi, datat dhe shënimet.

Këshilla: gjuhë e qartë, hapa të zbatueshëm, klasifikime të dobishme, lidhje e incidenteve të lidhura dhe përditësim i shënimeve kur ka zhvillime të reja.

3) Zgjidhni mjetin: Ju nevojitet një kërkim i mirë, kategorizim/etiketim, lidhje midis artikujve, shkallëzueshmëri, raportim dhe aftësi për t'u integruar me platformën tuaj ITSM. Jepini përparësi një ndërfaqeje miqësore për përdoruesit për të inkurajuar përdorimin; merrni në konsideratë kërkimin e mundësuar nga inteligjenca artificiale dhe rrjedhat e punës të personalizueshme.

4) Trajnoni ekipet: mësojuni atyre si të dokumentojnë në mënyrë efektive, si të kërkojnë me efikasitet dhe si të ruajnë cilësinë. Përfshini ushtrime praktike me raste nga bota reale , udhëzues të shpejtë, video, mentorim dhe kurse të rregullta rifreskimi. Inkurajoni reagimet për të përmirësuar procesin.

5) Mirëmbajtja dhe përmirësimi: Përcaktoni përgjegjësitë, KPI-të dhe një cikël rishikimi (mujor për çështjet kritike, tremujor për gjithçka tjetër). Vendosni rishikim nga kolegët e hyrjeve të reja, dokumentim të vazhdueshëm pas çdo çështjeje dhe një kanal reagimesh nga përdoruesit dhe mbështetja.

6) Promovoni përdorimin e tij: zhvilloni një fushatë të brendshme, njihni ata që kontribuojnë më shumë dhe nxisni bashkëpunimin midis departamenteve (rrjeti, softueri, hardueri). Integroni KEDB-në në kulturën e shërbimit në mënyrë që të bëhet vendi i parë që njerëzit shikojnë.

KEDB kundrejt Bazës së Njohurive (KDB): Dallimet Kryesore

KEDB përqendrohet në dështimet e njohura dhe zgjidhjet e tyre (të përkohshme ose të përhershme), të lidhura ngushtë me Menaxhimin e Problemeve dhe Incidenteve. Zakonisht është i integruar me ITSM dhe audienca e tij kryesore është ekipi teknik që zgjidh incidentet.

KEDB përfshin shumë më tepër: praktikat më të mira, procedurat, të dhënat e konfigurimit, artikujt ndihmës dhe më shumë. Mirëmbajtja e tij është më e gjerë, me rishikime të procedurave dhe praktikave më të mira përveç artikujve teknikë. Shkurt: KEDB është nëngrupi i specializuar i "kur kjo dështon, bëj këtë gjë tjetër".

Siç mund ta shihni, stabiliteti dhe performanca e një baze të dhënash varen po aq shumë nga kuptimi i dështimeve fizike dhe logjike (dhe kohëzgjatja e zbulimit të tyre) sa edhe nga shkrimi i mirë i SQL-së, modelimi inteligjent dhe organizimi i njohurive operacionale. Nëse korrigjoni katër modelet e performancës, shmangni gabimet tipike sintaksore, dizajnoni me çelësa primarë të fortë dhe normalizim të arsyeshëm, dhe gjithashtu krijoni një sistem të menaxhimit të bazës së të dhënave (KEDB), do të keni një platformë më të shpejtë, më të parashikueshme dhe më të lehtë për t’u përdorur, edhe kur gjërat shkojnë keq.