sql >> Database teknologi >  >> RDS >> Oracle

The Performance Tuning Maze

En dag vågner du op og opdager, at du er en Oracle-databaseadministrator. Guderne har endelig set lyset til dit sande potentiale og givet dig mulighed for at arbejde i det bedste job i verden! Du begynder din DBA-karriere så lysøjet og busket hale. Du opretter nye databaser, giver privilegier, skriver PL/SQL-kode. Livet er dejligt. Du kan ikke vente med at stå op om morgenen, hælde den første kop kaffe og pege din browser til dine yndlings Oracle-fora, ivrig efter at opsuge et helt livs viden inden frokost! Hvis disse guder stadig smiler til dig, kan du endda svare på et par spørgsmål og blive belønnet med fantastiske point. Livet er godt. Livet er sødt.

Mens du stadig soler dig i skæret af din nyfundne karriere, kommer nogen til dig med et problem. Et præstationsproblem. Du fryser. Der er en lille klump i halsen, når du kommer til den selverkendelse, at du ikke aner, hvordan du løser problemer med databasens ydeevne. Hvad du ikke var klar over den dag er, at alle DBA'er før dig har været i nøjagtig den samme situation tidligt i deres karriere. Alligevel forhindrer det ikke den anden person i at se på dig og undre dig over, hvorfor du ikke løser præstationsproblemet med det samme. Du er jo DBA, og du burde vide, hvordan du gør det her. Disse magiske ting, de kalder (cue englene synger) Performance Tuning . For det er skrevet, at hvis du skal være DBA og overleve, og gøre dette job godt, bliver du nødt til at tune performance. Andre vil aldrig vide, hvad der foregår bag gardinet, mens du laver eliksirer og kaster trylleformularer. Det eneste, de bekymrer sig om, er, at du har løst deres præstationsproblem, og de kan komme videre med deres daglige arbejde.

På dette tidspunkt tidligt i deres karriere beslutter enhver DBA, at de skal lære mere om denne ting, de kalder Performance Tuning . Hvad er det? Hvordan gør jeg det? Hvordan kan jeg blive den vigtigste person i min it-afdeling, fordi jeg opdagede den hemmelige sovs til at forvandle den 5 timers rapport til et 1 minuts mirakel?

Åh, vi var så unge dengang...så naive. Vi troede, det var nemt. Tryk på et par knapper, fyr op med et par værktøjer og presto. Løsningen til tuning af ydeevne er fundet, og vi er vidunderlige! Livet virkede så let, da vi begav os ned ad den gule murstensvej. Men på denne vej er der ingen skræmmekrager. Ingen løver. Ingen blikmænd. Ikke engang nogen søde små hunde ved navn Toto. Nej...denne vej...denne Oracle Performance Tuning-vej er fyldt med ting, der er meget større. På denne vej møder vi hjælpemidler og værktøjer. Vi møder Forklar Plan. Vi møder tkprof og SQLT. Vi finder vidunderlige udsigter som V$SGA_TARGET_ADVICE og V$SESSION_WAIT og dens tvillinger V$SESSION_EVENT (ikke enæggede tvillinger vel at mærke, men et blik, og du ved, at de er beslægtede).

Så der er du. Din skinnende DBA-titel sidder stadig under dit navn i hver e-mail-signatur, du sender. Og du har nu alle disse vidunderlige værktøjer til din rådighed. Du har hentet ASH og AWR, fordi din virksomhed heldigvis har givet dig Diagnostics Pack. Din bogreol er bevæbnet med fantastiske ting som denne. (Skamløst stik ved jeg). En eller anden god fyr på foraene, som mig, henledte dig til Lighty. Du har en hel værktøjskasse til din rådighed. Ingen! Ikke værktøjskasse….warchest! Små lande andre steder i verden har ikke det arsenal, du har til din rådighed. Hvorfor … jeg kunne røre ved den superhemmelige knap i SQL Tuning Advisor og blæse et af disse lande væk, *og* få SQL ID 98byz76pkyql til at køre hurtigere, mens der stadig kommer damp fra min kaffe...Jeg er så god.

Kan du huske den dag, du modtog dit første præstationsproblem, og du havde den klump i halsen? Der er endnu en dag som den i din DBA-karriere. Det er den dag, du når Performance Tuning Maze (cue the torden og lyn). Men dette er ikke nogen labyrint. Dette er anderledes. De fleste labyrinter har én indgang og én udgang, med mange drejninger og beslutninger undervejs. Denne labyrint, hvorfor, denne labyrint er åbenbart anderledes. Denne labyrint har mange, mange indgange. Og denne labyrint har mange, mange udgange. Hver indgang er et forskelligt værktøj til justering af ydeevne. Og hver udgang er en løsning , men ikke alle løsninger løser virkelig ydeevneproblemet. Og det er den gåde, som Oracles specialister i performancetuning står over for. Jeg har et præstationsproblem. Jeg ved, at på den anden side af denne labyrint er min løsning. Men hvilken indgang vælger jeg? En indgang har Forklar Plan skrevet over sig. En anden indgang har V$DB_CACHE_ADVICE skrevet på den. Hvorfor er der alle disse indgange, en for hvert værktøj til min rådighed. Dette er en fortælling om min ungdom, og forhåbentlig, som Bilbo skrev til Frodo, kan denne historie også hjælpe dig på dine eventyr.

Så jeg vælger en indgang.

Jeg går ind i labyrinten.

Tog jeg et godt valg?

Nå, lad os se, hvor det går hen. Fremme drejer vejen til venstre. Men det er mit eneste valg, så jeg går med det. Dernæst kommer jeg til et vejkryds. Jeg kan gå til højre eller venstre. Jeg drejer til højre. Ups... blindgyde. Så jeg går tilbage og tager det til venstre i stedet for. Endnu en blindgyde. Drats. Jeg kom forkert ind i labyrinten. Nogle gange fører værktøjerne dig ikke til nogen løsning. Så jeg går tilbage til indgangene og træffer et andet valg, valgte et andet værktøj.

Jeg er nu gået ind i labyrinten for anden gang. Men tingene ser meget bedre ud. Jeg fortsætter. Bare et par omgange mere. Jeg kan se lys, så jeg ved, at jeg nærmer mig slutningen. Ja ... der er den, udgangen. Jeg kommer endelig ud på den anden side af labyrinten. Jeg har min løsning til justering af ydeevne i hånden, men efter at jeg har implementeret løsningen, indser jeg hurtigt, at dette slet ikke løste mit præstationsproblem. Nogle gange kan værktøjer føre dig til løsninger, der ikke har nogen betydning for dit specifikke problem. Så det er tid til min tredje indgang til labyrinten.

Nu, da jeg var en dygtig specialist i justering af ydeevne, indså jeg, at alle de indgange, jeg har valgt indtil videre, er relateret til den overordnede databaseydeevne, men det, jeg virkelig leder efter, er ydeevne relateret til en specifik SQL-sætning. Men jeg ved ikke, hvilken SQL-sætning der skal tunes. Hvordan finder jeg ud af hvilken? Godt tre døre nede er en indgang til labyrinten mærket SQL Trace. Lige ved siden af ​​er en dør mærket EM Search Sessions. Jeg slår en mønt og vælger SQL Trace. Kort efter jeg er kommet ind i labyrinten, kommer jeg til et T-kryds. Hvis jeg går til venstre, fører det mig tilbage til døren til EM Search Sessions. Hvis jeg går til højre, er det et direkte skud til udgangen. Jeg går naturligvis til højre. Men det er i dette øjeblik, jeg ved, at snogle gange vil to forskellige værktøjer føre dig til det samme svar. Når jeg forlader labyrinten, får jeg et frikort til tkprof, for når alt kommer til alt, fører alle SQL Trace-veje ikke direkte til tkprof? Jeg har nu den stødende SQL-sætning. Men mit problem er ikke løst endnu. Hvad skal man gøre?

Jeg går tilbage til labyrintens indgang. Nogle gange, vi får et svar fra vores tuning-værktøjer, og vi er nødt til at udføre endnu et løb gennem labyrinten for at bore ned i det endelige svar. Denne gang går jeg ind i SQLT-døren. Et par drejninger og drejninger, men denne labyrintsti er ret nem, eller det ser det ud til. Jeg når til slutningen, og jeg har ikke kun ét svar, jeg har mange svar. Åh... herlig dag! Jeg har fundet alle værktøjers moder.

Jeg hørte andre DBA'er tale om disse mirakelværktøjer som SQLT og AWR Reports. Hvor er de vidunderlige. Disse værktøjer er så fantastiske, at nogle DBA'er kun ser SQLT- og AWR-rapportindgangene. Jeg har altid troet, at det her var sagn om legender, men her har jeg endelig også fundet det ene værktøj til at styre dem alle...ok...en for hver hånd. Jeg har alle disse svar til min rådighed. Hvilket svar er nu direkte relateret til mit præstationsproblem. Her har jeg min SQLT-rapport, og jeg har alle disse svar indeholdt deri. Hvilket svar er mit. Hvilken en?!?!? Nogle gange vil værktøjer give dig for meget information. For mig, som er ny med denne ydelsesjustering, kan output fra SQLT lige så godt være skrevet på Klingon. Men heldigvis kender jeg en kollega DBA, der sidder to kuber ned fra mig, og som taler klingonsk. Jeg giver ham mit SQLT-output. Han bladrer igennem det, og inden for 30 sekunder peger han på et lille afsnit af rapporten og siger de magiske ord. "Se ... lige der ... det er dit problem." Med et spørgende blik på mit ansigt vifter han med hånden over rapporten, og som ved et trylleslag har Google Translate ændret et par ord på siden, og jeg kan nu tydeligt se, at jeg har en tabel med meget dårlige statistikker. Nogle gange er værktøjer med alle disse svar store tidsbesparende for dem, der ved, hvordan man bruger dem. Denne Klingon-talende DBA skubber sine briller op og afslører endnu et afsnit af SQLT-rapporten. "Se her siger han...de dårlige statistikker tvinger en FTS", som om jeg skulle vide, hvad en FTS er på dette tidspunkt i min karriere. Men jeg vil ikke virke som en total n00b, så jeg smiler og nikker samtykkende.

Ok ... jeg kommer tættere på at løse mit problem. Jeg ved, at jeg har dårlig statistik. Jeg går tilbage til mit skrivebord, ivrig efter at komme på arbejde for endelig at løse mit problem. Mens jeg går forbi vandkøleren og går rundt i den evigt tilstedeværende skare af mine kolleger uden noget bedre at gøre hele dagen end at chatte, skinner solen af ​​den ene dør til labyrinten og fanger min øjenkroge...bare én dør. Over den dør er der et skilt, der siger DBA_TABLER. Som enhver god DBA siger jeg til mig selv, at det ikke er en dårlig idé at dobbelttjekke disse ting. Begynder tiltrukket af det, jeg går ind i DBA_TABLES-døren og er igen i labyrinten. Jeg laver en hurtig drejning, og noget springer ud på mig, som for at forskrække mig. Men jeg er ved at blive god til det her. Jeg er ligeglad med, at en lille labyrintbeboer insisterer på at fortælle mig, at dette bord ligger i tablespace BRUGERE. Jeg er hurtig til at vide, at dette ikke gør nogen forskel for mit problem. Jeg skubber på og ignorerer alle disse små imps med deres falske information. jeg trykker på. Og der har jeg det...bekræftelse ved labyrintudgangen, at der ikke er nogen statistik på dette bord. En hurtig lektie blev lært her, nogle gange vil værktøjerne give dig information, der ikke er relevant for dig på denne dag .

Jeg er måske ny i dette DBA-spil, men jeg ved det. Jeg skal se, hvordan tingene fungerer nu, foretage en ændring og måle præstationsforbedringen, hvis nogen. Så jeg går tilbage til labyrinten. Denne gang går jeg ind ad døren mærket SQL Developer Autotrace, og jeg udfører den stødende SQL-sætning. Jeg får ikke kun kørselstiden for SQL-sætningen, men jeg kan se antallet af læsninger og eksekveringsplanen. Jeg opdaterer hurtigt statistikken på bordet, min Klingon-talende ven påpegede for mig. (hurtigt til side... jeg plejede at tro, han var en idiot, men nu er han ikke så slem. Jeg kan lære af denne fyr. Måske en dag kan jeg også tale klingonsk). Så kommer jeg ind i SQL Developer Autotrace-døren igen. Ikke alene gik min udførelse af forespørgsler fra 2 minutters eksekvering ned til 2 sekunder, men læsningerne faldt betydeligt, og Explain Planen blev forbedret. Ok, den sidste del er lidt af en strækning. Jeg er stadig for grøn til at vide, at Explain Planen var bedre, men når jeg ser tilbage på den senere i min karriere, ved jeg, at den var det. Jeg lærer hurtigt, at nogle gange er ydelsesjusteringsværktøjerne til min rådighed, ikke kun der for at hjælpe med at finde årsagen til problemet, men er også der for at bekræfte, at løsningen faktisk har løst problemet. Og nogle gange er værktøjerne til at bekræfte resultaterne ikke de værktøjer, jeg brugte til at finde årsagen.

Jeg informerede hurtigt min slutbruger om, at problemet er løst. Brugeren brokker sig over noget, jeg ikke helt kunne se, og tjekker, om hans liv faktisk er bedre. Og det er da jeg modtager det. Den største gave en DBA nogensinde kunne modtage. Det er rigtigt... Jeg modtog brugertilbedelse . I dag er jeg en mirakelmager eller det tror brugeren. Mens jeg står i denne brugers kubiske, råber han "HE FIXED IT" og på signalet dukker hele afdelingens hoved op over de kubiske vægge som gophers op af jorden. Hurra..de jubler! Jeg elsker livet og soler mig i skæret. Hvorfor chefen overhovedet tilbyder at tage os med ud på pubben efter arbejde..første runde er på hende.

Jeg går tilbage til mit skrivebord, ivrig efter at tage den næste udfordring op. Dette job kunne ikke være sødere.

Jeg husker mine første møder med denne Performance Tuning Maze, som om det var i går. Da vi jokede over pints på pubben den aften, turde jeg ikke tale om nogle af de ting, jeg så i den labyrint. Mine kolleger ville alligevel ikke forstå. Jeg fortæller aldrig nogen om mine kampe med MOS-dragerne. Jeg er blevet brændt for mange gange. Jeg fortæller aldrig nogen, hvor kedeligt det er at køre en forespørgsel, vente en time på et resultat, prøv igen, vent en time, prøv igen, vent en time..ups..Jeg døsede hen der. Min ungdoms prøvelser og trængsler er bedre gemt til en anden gang. Måske skriver jeg en anden bog.

Men jeg lærte meget dengang. Med tiden blev jeg bedre og valgte den bedste indgang til labyrinten til det aktuelle problem. Det er trods alt kun med erfaring, at man kan blive bedre med disse magiske performance tuning eliksirer. Jeg har også erfaret, at nogle gange ser ét værktøj ud til at være det rigtige til opgaven, kun for halvvejs gennem justeringen at opdage, at et andet værktøj er bedre egnet.

Jeg har også erfaret, at det er kun at arbejde med værktøjerne og lære, hvad de er gode til og omvendt, hvad de ikke er gode til, at jeg bedst kan vælge det passende værktøj til jobbet. Dengang følte If ofte, at jeg prøvede at slå en skrue ind med en hammer. Nu ser jeg en skrue og ved, at det bedste værktøj er en skruetrækker.

Med tiden har jeg vokset antallet af indgange til min performance tuning labyrint. Jeg går stadig gennem de gennemprøvede døre, som med en med kun et nummer over sig, 10046. Tidligere er jeg blevet fortalt om magiske døre, der førte til regnbuer og enhjørninger, kun for at opdage endnu en gnaven gammel trold under en bro. Jeg var skeptisk over for, at Lighty var sådan et magisk værktøj i begyndelsen, men jeg tog fejl med det.

Åh de historier, jeg kunne fortælle dig, men denne historie handler i virkeligheden om den Performance Tuning Maze. Det kommer altid ned til den labyrint. Vælg den bedst mulige dør, men kun erfaring kan fortælle dig, hvilken der er bedst. Det vil lade dig nå frem til din løsning hurtigst. Lav et forkert sving og start forfra. Vær ikke bange for at komme ind i labyrinten flere gange. Når du tror, ​​du har løsningen, skal du gå gennem labyrinten for at verificere. Denne magiske Performance Tuning Maze med alle disse vidundere Oracle-ydelsestuning-værktøjer og værktøjer er nu blevet et af mine yndlingssteder at hænge ud. Jeg kan godt lide at tilføje flere indgange hele tiden, i håb om, at hvert nyt værktøj vil føre mig til slutningen af ​​labyrinten meget hurtigere. Nogle gange gør de det, og nogle gange gør de ikke.

Jeg husker stadig de dage, hvor jeg plejede at hænge ud i den gamle "forholdsbaserede tuning" labyrint, men jeg er gået videre til grønnere græsgange. Jeg griner stadig, når jeg ser en ny DBA stå foran den gamle labyrint, dækket af edderkoppespind, og de kan bare ikke tage antydningen. Og så bliver jeg sur, når jeg råber til dem, at de skal glemme den labyrint og komme herover, hvor alle andre hænger ud, kun for at blive foragtet af en, der tror, ​​de ved bedre. Hvis vi nogensinde ser dem igen, kan vi sige "Jeg fortalte dig det" og få et godt grin.

Jeg arbejder ofte med folk, der ser mig bruge nogle af disse skinnende værktøjer. De ser mig gå ind i labyrinten og komme ud på den anden side med svaret. Så deres åbenlyse næste spørgsmål er "kan jeg også gå ind ad den dør?" jeg griner. "Sikkert ... gå lige videre", siger jeg til dem. Bevæbnet med dette seje tuningværktøj, men ingen viden om, hvordan man tuner Oracle, gør de et ret godt, men svagt forsøg. De kalder mig hen til labyrinten og beder mig hjælpe dem med at løse problemet. Så vi fyrer op i værktøjet og ser på det. Jeg genkender øjeblikkeligt årsagen til problemet, men værktøjets skinnende klokker og fløjter forvirrer neofyten. På dette tidspunkt taler jeg nu klingonsk. Inden for få sekunder siger jeg "Se... lige der... det er dit problem." og jeg får det samme quizze look tilbage, som jeg gav min DBA-mentor for så mange år siden. Disse novicer vil altid have adgang til værktøjerne og tror, ​​de kan bruge dem som en mester. De har ingen anelse om, hvad der er i labyrinten, eller nogen anelse om, hvordan de skal navigere i den. Alt for mange mennesker tror, ​​at værktøjerne er den hemmelige sovs, når det i virkeligheden er personen, der bruger værktøjet. Desværre vil nogle mennesker med adgang til værktøjerne bare have et hurtigt og nemt svar. De ønsker ikke at bruge tiden som så mange af os.

Tid, tid til at følge mestrene. Vi har alle vores version af Mt Rushmore. Udhugget i sten. Folk som Millsap, Lewis og Shallahammer for at nævne nogle få. Din Mt Rushmore kan have andre navne eller endda lignende. Andre, der ser vores Mt Rushmore, alt sammen hugget i sten, ved ikke, at disse fine mennesker var vores guider i labyrinten. De viste os, hvordan man navigerer i labyrinten. De viste os, hvordan vi bruger værktøjerne, og hvilke værktøjer vi skal bruge hvornår. De af os, der lærte af mestrene, prøver vores bedste for at betale det videre og undervise andre, selvom vi måske aldrig når så høje højder, og det er ok.

Moralen i historien er at lære disse værktøjer, lære, hvad de gør, og hvad de ikke gør. Lær, hvilke problemer de hjælper med at tackle. Udnyt værktøjerne, men indse, at du skal lære så meget, du kan, så du kan gå i labyrinten med selvtillid. Desværre er jeg nødt til at afslutte min historie her. Nogen er lige kommet ind på mit kontor med et andet problem med justering af ydeevne. Tid til at gå ind i labyrinten igen. Hvilken dør tager jeg nu?


  1. MySql eksport skema uden data

  2. Advarsel:mysql_fetch_array() forventer, at parameter 1 er ressource, boolesk givet i

  3. Hvordan kalder man Oracle Function i Python?

  4. Hvad betyder PÅ [PRIMÆR]?