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ë hartë të qartë: pse ndodhin, si t'i zbuloni dhe çfarë masash duhet të merrni. Do të gjeni udhëzime të hollësishme në Gabimet e harduerit dhe softuerit në SQL Server (pasqyrimi), modele që ulin performancën, gabime tipike në shkrimin e pyetjeve, dështime klasike të modelimit/zhvillimit dhe një qasje ITIL/ITSM për dokumentimin dhe zgjidhjen e problemeve të përsëritura me një KEDB të strukturuar mirë.

Gabimet e harduerit: shenjat, shkaqet dhe koha e reagimit

Dështimet fizike zakonisht "këndojnë" shpejt sepse komponentët e tjerë të sistemit njoftojnë motorin e bazës së të dhënave. Kur kjo ndodh, serveri merr një gabimi i harduerit u raportua menjëherë, megjithëse ndonjëherë ka vonesa për shkak të kohëmatësve të rrjetit ose të I/O që vonojnë njoftimin.

Shkaqet e zakonshme përfshijnë: lidhje e prishur ose kabllo e dëmtuar, një kartë rrjeti që dështon, ndryshime në router ose firewall, rikonfigurim i pikës fundore, humbje e diskut që strehon regjistrin e transaksioneve ose gabime të procesit/OS-it. Këto janë probleme që, nëse ndikojnë në diskun e regjistrit ose në rrjet, mund të shkaktojnë shkëputje ose ndërprerje 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 zbatojnë sistemet e tyre. kohët e pritjes së brendshmeKëto afate kohore janë të pavarura nga baza e të dhënave dhe mund të vonojnë zbulimin, duke rritur kohën midis defektit aktual dhe ndërgjegjësimit të motorit për të.

Për të kuptuar më mirë se çfarë po ndodh "në rrjet", është një ide e mirë të pyesni ekipin e rrjetit se çfarë mesazhesh mbërrijnë në port kur ndodhin ngjarje tipike si p.sh. DNS jashtë funksionit, kabllot janë shkëputur, portat janë bllokuar nga firewall-i, një aplikacion që dëgjon rrëzimin e portit, një ndryshim emri të serverit ose një rinisje. Ky inventar simptomash përshpejton diagnostikimin kur shërbimi ndërpritet papritur.

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

Dështimet e softuerit nuk komunikohen vetë: serveri mund të jetë jashtë funksionit. duke pritur për një kohë të pacaktuar Nëse nuk do të kishte mekanizëm monitorimi në vend. Prandaj, në skenarë të tillë si pasqyrimi i bazës së të dhënave, instancat pingohen periodikisht dhe nëse nuk arrin asnjë sinjal brenda kohës së rënë dakord, një problem konsiderohet i pranishëm.

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

Nëse e gjeni veten në atë situatë, mund të zgjidhni të zgjasni afatin kohor, zvogëloni ngarkesën ose përmirësoni harduerin për të thithur kërkesën. Vendosja e kohës së pritjes shumë e ulët shkakton rezultate pozitive të rreme; vendosja e saj shumë e lartë vonon përgjigjen ndaj dështimeve reale.

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 merret një ping brenda dritares së kohës së pritjes (plus kohës së dërgesës), supozohet se komunikimi është ende aktiv dhe numëruesi është rivendosur. Nëse nuk merret asnjë ping brenda atij intervali, deklarohet koha e pritjes dhe lidhja mbyllet, duke e trajtuar ngjarjen sipas rolit dhe mënyrës së funksionimit.

Edhe nëse serveri tjetër është në rregull, një koha e pritjes merret si dështimNë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 s; kjo zakonisht është e mjaftueshme për të shmangur pozitivet e rreme. Në modalitetin me siguri të lartë, vlera e parazgjedhur është gjithashtu 10 s, por është e konfigurueshme; rregullojeni atë në atë modalitet në 10 s ose më shumë nëse rrjeti është "dembel".

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

Si reagon serveri kur ka një gabim

Në rast të çdo lloj gabimi, instanca vepron sipas saj. roli (kryesor/dëshmitar/sekondar), mënyra e funksionimit dhe statusi i lidhjesKur një partner humbet, sjellja ndryshon në varësi të faktit nëse po përdorim performancë të lartë apo siguri të lartë me një dëshmitar, kështu që është thelbësore të dokumentojmë mënyrën e funksionimit të secilës seancë për të parashikuar kohët e ndërprerjeve dhe kalimet në tela.

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ë latencën. Ato janë të lehta për t'u dalluar, dhe nëse i shmangni, Ju kurseni CPU, I/O dhe udhëtime në bazën e të dhënave nga dita e parë

Pyetjet brenda sytheve: nisja e një pyetjeje për çdo iteracion (klasi N+1) shumëfishon udhëtimet dhe vonesat. Sillni të dhënat menjëherë me një deklaratë bashkimi ose IN, ose përdorni pyetje batch. Përpunoni logjikën në kodin tuaj me strukturat e ngarkuara tashmë në memorie.

Ngarkimi i shumë të dhënave: Futja e kolonave dhe rreshtave që nuk do t'i përdorni është si të vrisni mizat me një gjyle topi. Filtroni në bazën e të dhënave, zgjidhni vetëm atë që është e nevojshme, faqosje nëse është e aplikueshme dhe shmang SELECT * përveç nëse keni një arsye të qartë.

Funksionet në klauzolën WHERE: Zbatimi i LOWER(), DATE() ose funksioneve të tjera në kolona shpesh parandalon përdorimin e indekseve. Është më mirë të krahasohet pa transformuar kolonën: përpunon paraprakisht të dhënat përpara ose transformoni literalin. Për shembull, filtroni sipas diapazonit të datave me kolona datë/orë pa i mbështjellë ato në funksione.

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

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

Shumica e gabimeve të fillestarëve (dhe jo aq fillestarëve) janë sintaksë y Injeksion SQLBaza e të dhënave nuk e kupton se çfarë po pyet dhe ankohet. Një redaktues i theksimeve ndihmon, por njohja e gabimeve tipike e përshpejton zgjidhjen.

Fjalë të shkruara gabim: Gabimet me emrat FROM, WHERE ose tabela/kolona janë të zakonshme. Mesazhet zakonisht tregojnë ku analizuesi dështonPërdorni një redaktues me nxjerrje në pah dhe plotësim automatik; nëse një fjalë kyçe nuk është e theksuar, kini dyshime.

Kllapa dhe thonjëza: Mungesa e kllapave ose e thonjëzave krijon një vrimë që është e vështirë të shihet. Mbani mend përparësia e operatorit (DHE/OSE) dhe gruponi me kllapa. Në tekstin me shkronja të plota, shmangni thonjëzat e brendshme ose alternoni thonjëza njëshe/dyshe për të shmangur ndërprerjen e vargut (p.sh., O'Reilly).

Renditje e pavlefshme në SELECT: renditja e saktë është Zgjidh → Nga → Ku → Grupo sipas → Duke pasur → Rendit sipasNdryshimi i pozicionit ORDER BY ose HAVING shkakton gabime. Mësojeni përmendësh ose mbani një fletë mashtrimi afër.

Injoroni pseudonimet e tabelave: Në një vetëbashkim ose kur ka kolona me të njëjtin emër në dy tabela, do të merrni "kolonë të paqartë". Përdorni pseudonime të shkurtra dhe të qarta dhe kolonat e referencës me alias.column. Gjithashtu, SQL është më i lexueshëm.

Emra të ndjeshëm ndaj shkronjave të mëdha ose emra të veçantë: Nëse këmbëngulni në emra të ndjeshëm ndaj shkronjave të mëdha ose emra me hapësira, do t'ju duhet t'i vendosni në thonjëza. citate të dyfishta Sipas motorit. Është më mirë t'i shmangni ato emra; nëse jo, jini të qëndrueshëm 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 të bëni në vend të kësaj. mbrojtja e integritetit dhe mirëmbajtjes.

Mbipërdorimi i procedurave të ruajtura: Ato janë të dobishme, por me ORM-të dhe shtresat moderne të aksesit, nuk keni më nevojë të vendosni të gjithë logjikën tuaj atje. SP-të kanë një kosto prej mirëmbajtje dhe versionim; krijoni SP për aksesin në të dhëna kur justifikohet, jo për logjikën e biznesit të aplikacionit.

Mos përdorni çelësa primarë: Delegimi i veçantisë te pamjet, SP-të ose aplikacioni rrit kompleksitetin dhe gabimet. Përcaktoni PK-të e vërteta në të gjitha tavolinat dhe përdorni pyetje unike aty ku është e aplikueshme; do të shmangni deduplikimin post-hoc dhe pyetjet e brishta.

Fshirja e menjëhershme në vend të fshirjes së butë: Fshirja fizike ndërlikon auditimet dhe rikuperimet nga "oops, e bëra gabim". Për shumë raste përdorimi, shton një shenjë kontrolli. aktiv/joaktiv (fshirje e butë) dhe përjashtojeni atë nga pyetjet tuaja. Lëreni fshirjen fizike për spastrimet e 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 alternative janë të pashmangshme. burime të kufizuara, kompleksitet ose nevoja për vazhdimësiKEDB është depoja ku dokumentoni çdo gabim të njohur, shkakun e tij (nëse ka) dhe zgjidhjen e përkohshme ose të përhershme të tij.

Është pjesë e kornizë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 rezolucion i testuar dhe të zvogëlojë 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ë i parashikueshëmPër IT-në: efikasitet (pa rishpikje të rrotës), 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 zona specifike), si klasifikohen ato dhe cilat qëllime ndiqni (zvogëlon MTTR-në, përmirëson kënaqësinë, etj.). Prioritizoni sistemet dhe shërbimet kritike dhe përputhni fushëveprimin me objektivat e biznesit dhe SLA-të.

Pyetje udhëzuese: A i mbulon të gjitha apo fillojmë me më me ndikim? A po kërkojmë kryesisht të shkurtojmë kohën e zgjidhjes apo edhe modelet e pikave 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 alternative efektive që nuk janë shkruar ende. Përdorni një shabllon të thjeshtë me fusha si përshkrimi, shkaku rrënjësor (nëse dihet), zgjidhja e përkohshme/përfundimtare, ndikimi, datat dhe shënimet.

Këshilla: gjuhë e qartë, hapa të zbatueshëm, vlerësime të dobishme, lidhje incidente të lidhura dhe përditësoni hyrjet kur ka lajme.

3) Zgjidhni mjetin: ju nevojitet një kërkim i mirë, kategorizim/etiketim, lidhje midis elementeve, shkallëzueshmëri, raportim dhe aftësia 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ë mirë, të kërkojnë në mënyrë efektive dhe të ruajnë cilësinë. Përfshin praktikat me raste reale, udhëzues të shpejtë, video, mentorim dhe rifreskime periodike. Inkurajon reagimet për të përmirësuar procesin.

5) Mirëmbajtja dhe përmirësimi: Përcaktimi i palëve përgjegjëse, KPI-ve dhe një cikli rishikimi (mujor për artikujt kritikë, tremujor për pjesën tjetër). Vendosja e rishikimit nga kolegët e hyrjeve të reja. dokumentacion i vazhdueshëm pas çdo problemi 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 promovojeni atë. bashkëpunim midis zonave (rrjet, softuer, harduer). Integroni KEDB në kulturën tuaj të shërbimit në mënyrë që të jetë vendi i parë që duhet kërkuar.

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

KEDB përqendrohet në dështimet e njohura dhe zgjidhjen 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 saj kryesore është ekipi teknik që zgjidh incidentet.

KDB mbulon shumë më tepër: praktikat më të mira, procedurat, të dhënat e konfigurimit, artikujt ndihmës, etj. Mirëmbajtja e saj është më e gjerë, me rishikime të procedurave dhe praktikave të mira Përveç artikujve teknikë. Shkurt: KEDB është nëngrupi që specializohet në "kur kjo dështon, bëje atë".

Siç mund ta shihni, stabiliteti dhe performanca e një baze të dhënash varen po aq shumë nga të kuptuarit e dështime fizike dhe logjike (dhe kohët e zbulimit të tyre) dhe shkrimin e mirë të SQL-së, modelimin me mençuri dhe organizimin e njohurive operacionale. Nëse i trajtoni katër modelet e performancës, shmangni gabimet tipike sintaksore, dizajnoni me PK të forta dhe normalizim të arsyeshëm, si dhe ndërtoni një KEDB të drejtpërdrejtë, 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.