Bieži sastopamas kļūdas datubāzē: cēloņi, kļūdas un risinājumi

Informatec Digital » Datu bāzes » Bieži sastopamas kļūdas datubāzē: cēloņi, kļūdas un risinājumi

Mērķis ir sniegt jums skaidru rīcības plānu: kāpēc šīs problēmas rodas, kā tās atklāt un kādas darbības jāveic. Jūs atradīsiet detalizētas vadlīnijas par aparatūras un programmatūras kļūdām SQL Server (spoguļošana) , veiktspēju graujošiem modeļiem, bieži pieļautām vaicājumu rakstīšanas kļūdām, klasiskām modelēšanas/izstrādes kļūmēm un ITIL/ITSM pieeju atkārtotu incidentu dokumentēšanai un risināšanai, izmantojot labi strukturētu atslēgu kļūdu datubāzi (KEDB).

Aparatūras kļūdas: pazīmes, cēloņi un reakcijas laiks

Fiziskas kļūmes parasti kļūst acīmredzamas ātri, jo citi sistēmas komponenti brīdina datubāzes dzinēju. Kad tas notiek, serveris nekavējoties saņem aparatūras kļūdas ziņojumu , lai gan dažreiz pastāv kavēšanās tīkla vai I/O taimeru dēļ, kas atliek paziņojumu.

Biežākie cēloņi ir pārtraukts savienojums vai bojāts kabelis , tīkla kartes kļūme, maršrutētāja vai ugunsmūra izmaiņas, galapunkta pārkonfigurācija, diska, kurā atrodas darījumu žurnāls, zudums vai procesa/OS kļūdas. Šīs problēmas, ja tās ietekmē žurnāla disku vai tīklu, var izraisīt jebko, sākot no savienojuma pārtraukumiem līdz nopietniem traucējumiem datubāzes replikācijā vai spoguļošanā.

Ņemiet vērā, ka daži tīkla komponenti un noteiktas I/O apakšsistēmas piemēro savus iekšējos taimautus . Šie taimauti nav atkarīgi no datubāzes un var aizkavēt noteikšanu, palielinot intervālu starp faktisko kļūmi un brīdi, kad programma to konstatē.

Lai labāk izprastu, kas notiek "pa vadu", ir lietderīgi pajautāt tīkla komandai, kādi ziņojumi pienāk ostā tipisku notikumu laikā, piemēram, DNS darbības pārtraukumu, atvienotu kabeļu, ugunsmūra portu bloķēšanas , lietojumprogrammas avāriju, kas klausās ostā, servera nosaukuma maiņas vai pārstartēšanas gadījumā. Šī simptomu uzskaite paātrina diagnostiku, kad pakalpojums pēkšņi apstājas.

Programmatūras kļūdas un taimauti: kad tās labot un kā izvairīties no viltus pozitīviem rezultātiem

Programmatūras kļūmes pašas par sevi nepaziņo: serveris varētu bezgalīgi palikt dīkstāvē bez uzraudzības mehānisma. Tāpēc tādos scenārijos kā datubāzes spoguļošana instances periodiski tiek "pingotas", un, ja noteiktajā laika posmā netiek saņemts signāls, tiek uzskatīts, ka ir radusies problēma.

Starp apstākļiem, kas izraisa šos gaidīšanas laikus, ir tīkla kļūdas (TCP taimauti, bojāti, pazaudēti vai nepareizi sakārtoti paketes) , nereaģējoša operētājsistēma/serveris/datubāze, Windows līmeņa derīguma termiņu beigas un resursu trūkums: diska vai centrālā procesora piesātinājums, 100% darījumu žurnāls, nepietiekama atmiņa vai pavedieni.

Ja nonākat šādā situācijā, varat izvēlēties palielināt taimautu, samazināt slodzi vai uzlabot aparatūru, lai apstrādātu pieprasījumu. Pārāk zema taimauta iestatīšana rada kļūdaini pozitīvus rezultātus; pārāk augsta taimauta iestatīšana aizkavē reakciju uz faktiskām kļūmēm.

Ping/taimauta mehānisms SQL Server spoguļošanā

Lai uzturētu katru savienojumu aktīvu, katrs eksemplārs nosūta pingus fiksētā intervālā. Ja pings tiek saņemts taimauta logā (plus sūtīšanas laiks) , tiek pieņemts, ka saziņa ir aktīva, un taimeris tiek atiestatīts. Ja šajā intervālā pings netiek saņemts, taimauts tiek uzskatīts par beigušos un savienojums tiek slēgts, un notikums tiek apstrādāts atbilstoši lomai un darbības režīmam.

Pat ja otrs serveris darbojas pareizi, taimauts tiek uzskatīts par kļūmi . Ja konfigurētā vērtība ir pārāk īsa vides normālajam latentumam, parādīsies "fantoma" kļūdas. Tāpēc nav ieteicams to nepārsniegt zem 10 sekundēm.

Augstas veiktspējas režīmā taimauts vienmēr ir 10 sekundes ; tas parasti ir pietiekami, lai izvairītos no kļūdaini pozitīviem rezultātiem. Augstas drošības režīmā noklusējuma vērtība arī ir 10 sekundes, taču to var konfigurēt; pielāgojiet to uz 10 sekundēm vai ilgāk šajā režīmā, ja tīkls ir lēns.

Ja nepieciešams to mainīt, atcerieties, ka šī modifikācija attiecas tikai uz augstas drošības sesijām . Varat to skatīt un modificēt no dzinēja administrēšanas vai izmantojot T-SQL atkarībā no versijas un politikām.

Kā serveris reaģē kļūdas gadījumā

Jebkura veida kļūdas gadījumā instance rīkojas atbilstoši savai lomai (primārā/liecinieka/sekundārā), darbības režīmam un savienojuma statusam . Ja partneris tiek zaudēts, uzvedība atšķiras atkarībā no tā, vai atrodamies augstas veiktspējas vai augstas drošības režīmā ar liecinieku, tāpēc ir svarīgi dokumentēt katras sesijas darbības režīmu, lai paredzētu dīkstāvi un pārslēgšanos.

SQL veiktspēju pasliktinošie modeļi (un kā tos labot)

Ir četri ļoti izplatīti "grēki", kas nevajadzīgi palielina latentumu. Tos ir viegli pamanīt, un, no tiem izvairoties, jau no pirmās dienas tiks ietaupīta centrālā procesora, ievades/izvades un datubāzes piekļuve .

Vaicājumi ciklu ietvaros: vaicājuma izpilde katrā iterācijā (klasiskais N+1) reizina braucienu skaitu un latentumu. Iegūstiet visus datus uzreiz, izmantojot apvienošanu vai IN, vai izmantojiet pakešvaicājumus. Apstrādājiet loģiku savā kodā, izmantojot struktūras, kas jau ir ielādētas atmiņā.

Pārāk liela datu apjoma ielāde — neizmantoto kolonnu un rindu izgūšana — ir kā rieksta sišana ar āmuru. Filtrējiet datubāzi, atlasiet tikai nepieciešamo , izmantojiet lappušu numerāciju, ja nepieciešams, un izvairieties no SELECT *, ja vien jums nav skaidra iemesla.

Funkcijas WHERE klauzulā: LOWER(), DATE() vai citu lietošana kolonnām bieži vien neļauj izmantot indeksus. Labāk ir salīdzināt, nepārveidojot kolonnu: vispirms apstrādājiet datus vai pārveidojiet literāli. Piemēram, filtrējiet pēc datumu diapazona, izmantojot datuma/laika kolonnas, neaptverot tās funkcijās.

Trūkstoši indeksi: Indeksu aizmirstšana kolonnās, kas filtrē vai apvienojas, ir līdzīga pilnīgas skenēšanas pieprasīšanai. Periodiski pārskatiet, kur jūsu lietojumprogramma filtrē/apvienojas, un izveidojiet atbilstošus indeksus (ja nepieciešams, saliktos indeksus). Līdzsvars: Pārāk daudz indeksu soda par rakstīšanu.

Tipiskas kļūdas, rakstot SQL: sintakse, secība un neskaidrības

Lielākā daļa iesācēju (un pat dažu pieredzējušāku lietotāju) pieļauto kļūdu ir saistītas ar sintaksi un SQL injekciju . Datu bāze nesaprot, ko jūs tai lūdzat, un sūdzas. Redaktors ar teksta izcelšanu palīdz, taču biežāk sastopamo kļūmju pārzināšana paātrina procesu.

Nepareizi uzrakstīti vārdi: Kļūdas ar FROM, WHERE vai tabulu/kolonnu nosaukumiem ir bieži sastopamas. Ziņojumi parasti norāda, kur parsētājs nedarbojas . Izmantojiet redaktoru ar iezīmēšanu un automātisko pabeigšanu; ja atslēgvārds nav iezīmēts, esiet aizdomīgi.

Iekavas un pēdiņas: Trūkstošas ​​iekavas vai pēdiņas rada grūti pamanāmu problēmu. Atcerieties operatora prioritāti (UN/VAI) un grupējiet tekstu ar iekavām. Teksta literāļos atsoļojiet iekšējās pēdiņas vai mainiet vienpēdiņas un dubultpēdiņas, lai izvairītos no virknes pārtraukšanas (piemēram, O'Reilly).

Nepareiza secība SELECT: pareizā secība ir SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY . ORDER BY vai HAVING secības maiņa radīs kļūdas. Iegaumējiet to vai turiet pa rokai apkrāptu lapu.

Izlaidiet tabulas aizstājvārdus: Pašapvienošanās gadījumā vai tad, ja divām tabulām ir kolonnas ar vienādu nosaukumu, jūs saņemsiet kļūdu "neskaidra kolonna". Izmantojiet īsus, skaidrus aizstājvārdus un atsauces uz kolonnām ar `alias.column`. Tas arī padara SQL vieglāk lasāmu.

Reģistrjutīgi vai īpašie nosaukumi: ja vēlaties lietot reģistrjutīgus vai atstarpjutīgus nosaukumus, tie būs jācitē pēdiņās atkarībā no meklētājprogrammas. Vislabāk ir izvairīties no šiem nosaukumiem; pretējā gadījumā esiet konsekventi, tos citējot.

Biežāk sastopamās kļūdas datubāzu izstrādē

Papildus vaicājumu rakstīšanai ir arī dizaina lēmumi, kuriem ir nozīme vidējā termiņā un ilgtermiņā. Šeit ir piecas izplatītas izstrādes kļūdas, kā arī norādījumi, kas jādara, lai aizsargātu integritāti un uzturēšanas iespējas.

Pārmērīga saglabāto procedūru izmantošana: tās ir noderīgas, taču, izmantojot mūsdienīgas darbības mehānismu pārvaldības (ORM) un piekļuves slāņus, jums vairs nav jāievieto tajās visa loģika. Saglabātajām procedūrām ir uzturēšanas un versiju veidošanas izmaksas ; izveidojiet saglabātās procedūras datu piekļuvei, ja tas ir pamatoti, nevis lietojumprogrammu biznesa loģikai.

Izvairieties no primāro atslēgu izmantošanas: unikalitātes deleģēšana skatiem, saglabātajām procedūrām vai lietojumprogrammai palielina sarežģītību un kļūdas. Visās tabulās definējiet reālas primārās atslēgas un, ja nepieciešams, izmantojiet unikālas atslēgas; tas novērsīs pēcdeduplikāciju un trauslus vaicājumus.

Stingrā dzēšana, nevis mīkstā dzēšana: Fiziska datu dzēšana sarežģī auditus un atkopšanu pēc kļūdas "ups, es visu sabojāju". Daudzos lietošanas gadījumos pievienojiet karodziņu aktīva/neaktīva (mīkstā dzēšana) un izslēdziet to no vaicājumiem. Fizisko dzēšanu atstājiet kontrolētai tīrīšanai.

Zināmo kļūdu datubāze (KEDB): Kas tā ir un kāpēc tā ir laba ideja jums

Darbībās ne visu var atrisināt uzreiz. Pagaidu risinājumi (apvedceļi) ir neizbēgami ierobežoto resursu, sarežģītības vai uzņēmējdarbības nepārtrauktības nepieciešamības dēļ . KEDB ir krātuve, kurā dokumentējat katru zināmo kļūdu, tās cēloni (ja tāds ir) un pagaidu vai pastāvīgu risinājumu.

Tā ir daļa no ITIL ietvara un krustojas ar problēmu pārvaldību un zināšanu pārvaldību. Ja rodas atkārtots incidents, komanda konsultējas ar KEDB, piemēro pārbaudītu risinājumu un samazina dīkstāves laiku, nevis sāk visu no jauna.

Ieguvumi lietotājiem: ātrāka problēmu risināšana, mazāk pārtraukumu un paredzamāki rezultāti . IT jomā: efektivitāte (nav nepieciešams izgudrot riteni no jauna), zināšanu saglabāšana, neskatoties uz darbinieku mainību, un dati nepārtrauktai uzlabošanai. Ieinteresētajām personām: pārredzamība, pamatoti lēmumi par kapacitāti/risku un izmaksu ietaupījums.

Kā soli pa solim ieviest efektīvu KEDB

1) Definējiet darbības jomu un mērķus: izlemiet, kuras kļūmes ir iekļautas (programmatūras, aparatūras, tīkla vai konkrētu jomu), kā tās tiek klasificētas un kādus mērķus jūs sasniedzat ( samazināt MTTR, uzlabot apmierinātību utt.). Prioritāti piešķiriet kritiskajām sistēmām un pakalpojumiem un saskaņojiet darbības jomu ar biznesa mērķiem un SLA.

Vadošie jautājumi: Vai tas aptver visu, vai arī mēs sākam ar visietekmīgākajiem jautājumiem? Vai mēs galvenokārt cenšamies saīsināt risināšanas laiku vai arī atklāt preventīvus modeļus?

2) Apkopot un dokumentēt: sadarboties ar incidentu/problēmu pārvaldības nodaļu un komandām, lai fiksētu atkārtotas kļūdas un efektīvus risinājumus , kas vēl nav dokumentēti. Izmantojiet vienkāršu veidni ar tādiem laukiem kā apraksts, pamatcēlonis (ja zināms), pagaidu/pastāvīgs risinājums, ietekme, datumi un piezīmes.

Padomi: skaidra valoda, praktiski soļi, noderīgas klasifikācijas, saistītu incidentu sasaiste un ierakstu atjaunināšana, kad ir jaunas norises.

3) Izvēlieties rīku: Jums ir nepieciešama laba meklēšana, kategorizēšana/marķēšana, saites starp vienumiem, mērogojamība, atskaišu veidošana un iespēja integrēties ar jūsu ITSM platformu. Piešķiriet prioritāti lietotājam draudzīgam interfeisam, lai veicinātu ieviešanu; apsveriet mākslīgā intelekta nodrošinātu meklēšanu un pielāgojamas darbplūsmas.

4) Apmāciet komandas: iemāciet tām efektīvi dokumentēt, efektīvi meklēt un uzturēt kvalitāti. Iekļaujiet praktiskus vingrinājumus ar reāliem gadījumiem , īsas rokasgrāmatas, video, mentoringu un regulāras kvalifikācijas celšanas kursus. Veiciniet atgriezenisko saiti, lai uzlabotu procesu.

5) Uzturēt un uzlabot: Definēt pienākumus, galvenos darbības rādītājus (KPI) un pārskatīšanas ciklu (katru mēnesi kritiskiem jautājumiem, katru ceturksni visam pārējam). Izveidot jaunu ierakstu salīdzinošo pārskatīšanu, nepārtrauktu dokumentāciju pēc katras problēmas un atsauksmju kanālu no lietotājiem un atbalsta dienesta.

6) Veicināt tās izmantošanu: veikt iekšēju kampaņu, novērtēt tos, kuri sniedz vislielāko ieguldījumu, un veicināt sadarbību starp nodaļām (tīkls, programmatūra, aparatūra). Integrēt KEDB apkalpošanas kultūrā, lai tā kļūtu par pirmo vietu, kur cilvēki meklē.

KEDB pret zināšanu bāzi (KDB): galvenās atšķirības

KEDB koncentrējas uz zināmām kļūmēm un to risinājumiem (pagaidu vai pastāvīgām), cieši sasaistot to ar problēmu un incidentu pārvaldību. Tā parasti ir integrēta ar ITSM , un tās galvenā auditorija ir tehniskā komanda, kas risina incidentus.

KEDB ietver daudz vairāk: labāko praksi, procedūras, konfigurācijas datus, palīdzības rakstus un daudz ko citu. Tās uzturēšana ir plašāka, papildus tehniskajiem rakstiem, ietverot procedūru un labākās prakses pārskatīšanu . Īsāk sakot: KEDB ir specializēta apakškopa "ja šī neizdodas, dari šo un to citu".

Kā redzat, datubāzes stabilitāte un veiktspēja ir tikpat atkarīga no fizisko un loģisko kļūmju (un to noteikšanas laiku) izpratnes, cik no labas SQL rakstīšanas, inteliģentas modelēšanas un operatīvo zināšanu organizēšanas. Ja izlabosiet četrus veiktspējas modeļus, izvairīsieties no tipiskām sintakses kļūdām, projektēsiet, izmantojot spēcīgas primārās atslēgas un saprātīgu normalizāciju, kā arī iestatīsiet tiešraides datubāzes pārvaldības sistēmu (KEDB), jums būs ātrāka, paredzamāka un vieglāk lietojama platforma pat tad, ja rodas problēmas.