sql >> Databasteknik >  >> RDS >> Oracle

The Performance Tuning Maze

En dag vaknar du och upptäcker att du är en Oracle-databasadministratör. Gudarna har äntligen sett ljuset till din sanna potential och låtit dig arbeta i världens bästa jobb! Du börjar din DBA-karriär så ljusögd och buskig svans. Du skapar nya databaser, beviljar privilegier, skriver PL/SQL-kod. Livet är bra. Du kan inte vänta med att gå upp på morgonen, hälla upp den första koppen kaffe och peka med din webbläsare till dina favoritforum för Oracle, ivrig att suga till dig hela livets kunskap innan lunch! Om dessa gudar fortfarande ler mot dig kan du till och med svara på några frågor och bli belönad med fantastiska poäng. Livet är gott. Livet är sött.

Medan du fortfarande solar dig i skenet av din nyfunna karriär kommer någon till dig med ett problem. Ett prestandaproblem. Du fryser. Det finns en liten klump i halsen när du kommer till självförverkligandet att du inte har någon aning om hur du löser problem med databasprestanda. Vad du inte insåg den dagen är att varje DBA före dig har varit i exakt samma situation tidigt i sin karriär. Ändå hindrar det inte den andra personen från att titta på dig och undra varför du inte löser prestandaproblemet omedelbart. När allt kommer omkring är du DBA och du borde veta hur man gör det här. Dessa magiska grejer de kallar (se änglarna som sjunger) Performance Tuning . För det har skrivits, om du ska bli en DBA och överleva, och göra det här jobbet bra, måste du trimma prestanda. Andra kommer aldrig att få veta vad som händer bakom gardinen när du gör trolldrycker och trollformler. Allt de bryr sig om är att du löste deras prestationsproblem och att de kan fortsätta med sitt dagliga arbete.

I början av sin karriär beslutar varje DBA att de behöver lära sig mer om det här som de kallar Performance Tuning . Vad är det? Hur gör jag det? Hur kan jag bli den viktigaste personen på min IT-avdelning eftersom jag upptäckte den hemliga såsen för att förvandla den där 5 timmarsrapporten till ett 1 minuts mirakel?

Åh, vi var så unga då...så naiva. Vi tyckte det var lätt. Tryck på några knappar, tänd några verktyg och presto. Lösningen för prestandajustering har hittats och vi är underbara! Livet verkade så lätt när vi vågade oss på den gula tegelvägen. Men på den här vägen finns det inga skrämmande kråkor. Inga lejon. Inga plåtmän. Inte ens några söta små hundar som heter Toto. Nej ... den här vägen ... den här Oracle Performance Tuning-vägen är fylld med saker som är mycket större. På denna väg möter vi verktyg och verktyg. Vi träffar Explain Plan. Vi träffar tkprof och SQLT. Vi hittar underbara vyer som V$SGA_TARGET_ADVICE och V$SESSION_WAIT och dess tvilling V$SESSION_EVENT (inte identiska tvillingar, men en blick och du vet att de är släkt).

Så där är du. Din glänsande DBA-titel sitter fortfarande under ditt namn i varje e-postsignatur du skickar. Och du har nu alla dessa underbara verktyg till ditt förfogande. Du har plockat upp ASH och AWR eftersom ditt företag tack och lov har gett dig diagnostikpaketet. Din bokhylla är beväpnad med fantastiska böcker som denna. (Skamlös plugg jag vet). Någon bra kille på forumet, som jag, tipsade dig om Lighty. Du har en hel verktygslåda till ditt förfogande. Nej! Inte verktygslåda….warchest! Små länder på andra platser i världen har inte den arsenal du har till ditt förfogande. Varför...jag kunde trycka på den superhemliga knappen i SQL Tuning Advisor och blåsa bort ett av dessa länder, *och* få SQL ID 98byz76pkyql att köras snabbare medan mitt kaffe fortfarande har ånga... Jag är så bra.

Kommer du ihåg den dagen då du fick ditt första prestationsproblem och du hade den där klumpen i halsen? Det finns en annan sådan dag i din DBA-karriär. Det är dagen du når Performance Tuning Maze (visa åskan och blixten). Men det här är ingen labyrint. Det är skillnad. De flesta labyrinter har en ingång och en utgång, med många svängar och beslut längs vägen. Den här labyrinten, varför, den här labyrinten är uppenbarligen annorlunda. Denna labyrint har många, många ingångar. Och denna labyrint har många, många utgångar. Varje ingång är ett annat verktyg för prestandajustering. Och varje utgång är en lösning , men inte alla lösningar löser verkligen prestandaproblemet. Och det här är gåtan som Oracles prestationsinställningsspecialister står inför. Jag har ett prestationsproblem. Jag vet att på andra sidan av denna labyrint är min lösning. Men vilken ingång väljer jag? En ingång har Explain Plan skriven ovanför. En annan ingång har V$DB_CACHE_ADVICE skrivet på den. Varför det finns alla dessa ingångar, en för varje verktyg till mitt förfogande. Det här är en berättelse om min ungdom och förhoppningsvis, som Bilbo skrev till Frodo, kan den här historien också hjälpa dig i dina äventyr.

Så jag väljer en ingång.

Jag går in i labyrinten.

Gjorde jag ett bra val?

Nåväl, låt oss se vart detta leder. Längre fram svänger vägen till vänster. Men det är mitt enda val så jag går med på det. Därefter kommer jag till en korsning. Jag kan gå höger eller vänster. Jag gör en högersväng. Hoppsan... återvändsgränd. Så jag backar och tar det till vänster istället. Ännu en återvändsgränd. Drats. Jag kom in i labyrinten felaktigt. Ibland leder inte verktygen dig till någon lösning. Så jag går tillbaka till ingångarna och gör ett annat val, valde ett annat verktyg.

Jag har nu gått in i labyrinten en andra gång. Men det ser mycket bättre ut. Jag fortsätter. Bara några varv till. Jag kan se ljus så jag vet att jag närmar mig slutet. Ja...där är den, utgången. Jag kommer äntligen ut på andra sidan labyrinten. Jag har min lösning för prestandajustering i handen men efter att jag implementerat lösningen inser jag snabbt att detta inte alls löste mitt prestandaproblem. Ibland kan verktyg leda dig till lösningar som inte har någon betydelse för ditt specifika problem. Så det är dags för min tredje ingång till labyrinten.

Nu, som en skarpsinnig specialist på prestandajustering, insåg jag att alla ingångar jag valt hittills är relaterade till övergripande databasprestanda, men det jag verkligen letar efter är prestanda relaterade till en specifik SQL-sats. Men jag vet inte vilken SQL-sats som behöver finjusteras. Hur kan jag ta reda på vilken? Väl tre dörrar ner är en ingång till labyrinten märkt SQL Trace. Alldeles intill finns en dörr märkt EM Search Sessions. Jag slår ett mynt och väljer SQL Trace. Strax efter att jag kommit in i labyrinten kommer jag till en T-korsning. Om jag går till vänster tar det mig tillbaka till dörren för EM Search Sessions. Om jag går till höger är det ett rakt skott till utgången. Naturligtvis går jag rätt. Men det är i detta ögonblick som jag vet att sibland kommer två olika verktyg att leda dig till samma svar. När jag lämnar labyrinten får jag ett frikort till tkprof för trots allt, leder inte alla SQL Trace-vägar direkt till tkprof? Jag har nu den stötande SQL-satsen. Men mitt problem är inte löst än. Vad ska man göra?

Jag går tillbaka till labyrintens ingång. Ibland, vi får svar från våra inställningsverktyg och vi måste köra en gång till genom labyrinten för att gå in i det slutliga svaret. Den här gången går jag in i SQLT-dörren. Några vändningar, men den här labyrinten är ganska lätt, eller så verkar det som. Jag kommer till slutet, och jag har inte bara ett svar, jag har många svar. Åh...härlig dag! Jag har hittat alla verktygs moder.

Jag hörde andra DBA:er tala om dessa mirakelverktyg som SQLT och AWR Reports. Vad underbara de är. Dessa verktyg är så fantastiska att vissa DBA:er bara ser SQLT- och AWR-rapportingångarna. Jag har alltid trott att det här var grejer med legender, men här har jag äntligen också hittat ett verktyg för att styra dem alla... ok...en för varje hand. Jag har alla dessa svar till mitt förfogande. Vilket svar är nu direkt relaterat till min prestationsfråga. Här har jag min SQLT-rapport och jag har alla dessa svar i den. Vilket svar är mitt. Vilken?!?!? Ibland ger verktyg dig för mycket information. För mig, som är ny med det här med prestandajustering, kan utdata från SQLT lika gärna skrivas på klingonska. Men som tur är, jag känner en kollega DBA som sitter två kuber från mig som talar klingonska. Jag ger honom min SQLT-utgång. Han tummar igenom den och inom 30 sekunder pekar han ut en liten del av rapporten och säger de magiska orden. "Se ... precis där ... det är ditt problem." Med en frågvis blick på mitt ansikte viftar han med handen över rapporten och som genom ett trollslag har Google Translate ändrat några ord på sidan och jag kan nu tydligt se att jag har en tabell med mycket dålig statistik. Ibland är verktyg med alla dessa svar fantastiska tidsbesparingar för dem som vet hur man använder dem. Denna klingontalande DBA lyfter upp sina glasögon och avslöjar ytterligare ett avsnitt av SQLT-rapporten. "Se här säger han ... den där dåliga statistiken tvingar en FTS" som om jag borde veta vad en FTS är vid denna tidpunkt i min karriär. Men jag vill inte verka som en total n00b så jag ler och nickar instämmande.

Ok ... jag närmar mig att lösa mitt problem. Jag vet att jag har dålig statistik. Jag går tillbaka till mitt skrivbord ivrig efter att komma till jobbet för att äntligen lösa mitt problem. När jag går förbi vattenkylaren och går runt den ständigt närvarande skaran av mina medarbetare utan något bättre att göra på hela dagen än att chatta, skiner solen från ena dörren till labyrinten och fångar ögonvrån...bara en dörr. Ovanför den dörren finns en skylt som säger DBA_TABLES. Som vilken bra DBA som helst, säger jag till mig själv att det inte är en dålig idé att dubbelkolla dessa saker. Börja dras till det, jag går in i DBA_TABLES dörren och är återigen i labyrinten. Jag gör en snabb sväng och något hoppar ut på mig som för att skrämma mig. Men jag börjar bli bra på det här. Jag bryr mig inte om att någon liten labyrintboende insisterar på att tala om för mig att det här bordet finns i tabellutrymmet ANVÄNDARE. Jag är snabb att veta att detta inte gör någon skillnad för mitt problem. Jag trycker på och ignorerar alla dessa små luringar med deras falska information. Jag trycker på. Och där har jag det...bekräftelse vid labyrintens utgång att det inte finns någon statistik på det här bordet. En snabb läxa lärdes här, ibland ger verktygen dig information som inte är relevant för dig den här dagen .

Jag kanske är ny på det här DBA-spelet, men jag vet det här. Jag måste se hur saker och ting fungerar nu, göra en förändring och mäta prestandaförbättringen om någon. Så jag går tillbaka till labyrinten. Den här gången går jag in genom dörren som är märkt SQL Developer Autotrace och jag kör den stötande SQL-satsen. Jag får inte bara körtiden för SQL-satsen utan jag kan se antalet läsningar och exekveringsplanen. Jag uppdaterar snabbt statistiken på bordet som min klingontalande vän pekade ut för mig. (snabbt åsido... jag brukade tycka att han var en idiot men nu är han inte så dålig. Jag kan lära mig av den här killen. En dag kanske jag också kan prata klingonska). Sedan går jag in i SQL Developer Autotrace-dörren igen. Inte nog med att min exekvering av sökfrågan gick från 2 minuters körning ner till 2 sekunder, utan läsningen sjönk avsevärt och Explain Planen förbättrades. Ok, den sista delen är lite av en sträcka. Jag är fortfarande för grön för att veta att Explain Planen var bättre, men när jag ser tillbaka på den senare i min karriär vet jag att den var det. Jag lär mig snabbt att ibland är verktygen för prestandajustering som jag har till mitt förfogande inte bara till för att hjälpa till att hitta grundorsaken till problemet, utan också för att bekräfta att lösningen faktiskt löste problemet. Och ibland är verktygen för att bekräfta resultaten inte de verktyg jag använde för att hitta grundorsaken.

Jag informerade snabbt min slutanvändare om att problemet är löst. Användaren klagar något som jag inte riktigt kunde urskilja och kontrollerar om hans liv faktiskt är bättre. Och det är då jag får det. Den största gåvan en DBA någonsin kan få. Det stämmer... Jag fick användartillbedjan . Idag är jag en mirakelarbetare eller så tror användaren. När jag står i den här användarens kubika ropar han ut "HE FIXED IT" och på kö, hela avdelningens huvud dyker upp över de kubiska väggarna som gophers upp ur marken. Hurra..de hejar! Jag älskar livet och solar mig i skenet. Varför chefen ens erbjuder sig att ta oss ut till krogen efter jobbet...första omgången är på henne.

Jag går tillbaka till mitt skrivbord, ivrig att ta mig an nästa utmaning. Det här jobbet kunde inte vara sötare.

Jag minns mina första möten med denna Performance Tuning Maze som om det vore igår. När vi skämtade över pints på puben den kvällen, vågade jag inte tala om några av de saker jag såg i den labyrinten. Mina medarbetare skulle inte förstå hur som helst. Jag berättar aldrig för någon om mina slagsmål med MOS-drakarna. Jag har blivit bränd för många gånger. Jag berättar aldrig för någon hur tråkigt det är att köra en fråga, vänta en timme på ett resultat, försök igen, vänta i en timme, försök igen, vänta i en timme..oops..Jag slumrade till där. Min ungdoms prövningar och prövningar är bättre att spara till en annan tid. Jag kanske skriver en bok till.

Men jag lärde mig mycket på den tiden. Med tiden blev jag bättre och valde den bästa ingången till labyrinten för problemet. Det är trots allt bara med erfarenhet som man kan bli bättre med dessa magiska prestationsavstämningselixir. Jag har också lärt mig att ibland verkar ett verktyg vara det rätta för jobbet, bara för att halvvägs genom trimningen upptäcka att ett annat verktyg är bättre lämpat.

Jag har också lärt mig att det är bara att arbeta med verktygen och lära mig vad de är bra på och omvänt vad de inte är bra på, som jag bäst kan välja det lämpliga verktyget för jobbet. Förr i tiden kändes If ofta som att jag försökte slå in en skruv med en hammare. Nu ser jag en skruv och vet att det bästa verktyget är en skruvmejsel.

Med tiden har jag ökat antalet ingångar till min prestationsavstämningslabyrint. Jag går fortfarande igenom de beprövade dörrarna som med en med bara ett nummer ovanför, 10046. Tidigare har jag fått höra om magiska dörrar som ledde till regnbågar och enhörningar bara för att upptäcka ännu ett grinigt gammalt troll under en bro. Jag var skeptisk till att Lighty var ett så magiskt verktyg i början, men jag hade fel om det.

Åh, de sagor jag skulle kunna berätta för dig, men den här historien handlar verkligen om den där Performance Tuning Maze. Det kommer alltid ner till den labyrinten. Välj den bästa möjliga dörren, men bara erfarenhet kan berätta vilken som är bäst. Det låter dig komma fram till din lösning snabbast. Gör en fel sväng och börja om. Var inte rädd för att gå in i labyrinten flera gånger. När du tror att du har lösningen, gå igenom labyrinten för att verifiera. Denna magiska Performance Tuning Maze med alla dessa underbara Oracles prestationsjusteringsverktyg och verktyg har nu blivit en av mina favoritställen att umgås på. Jag gillar att lägga till fler ingångar hela tiden, i hopp om att varje nytt verktyg ska leda mig till slutet av labyrinten mycket snabbare. Ibland gör de det och ibland inte.

Jag minns fortfarande de dagar då jag brukade hänga i den gamla "ratio-baserade trimning" labyrinten, men jag har gått vidare till grönare betesmarker. Jag skrattar fortfarande när jag ser någon ny DBA som står framför den gamla labyrinten, täckt av spindelnät och de kan bara inte ta ledtråden. Och så blir jag arg när jag skriker åt dem att de ska glömma den där labyrinten och komma hit där alla andra hänger, bara för att bli föraktad av någon som tror att de vet bättre. Om vi ​​någonsin ser dem igen kan vi säga "jag sa det" och få oss ett gott skratt.

Jag arbetar ofta med människor som ser mig använda några av dessa glänsande verktyg. De ser mig gå in i labyrinten och komma ut på andra sidan med svaret. Så deras uppenbara nästa fråga är "kan jag gå in i den dörren också?" jag skrattar. "Visst... gå direkt", säger jag till dem. Beväpnade med detta coola tuningverktyg, men ingen kunskap om hur man ställer in Oracle, gör de ett ganska bra, men svagt försök. De kallar mig till labyrinten och ber mig hjälpa dem att lösa problemet. Så vi tänder på verktyget och tittar på det. Jag känner omedelbart igen grundorsaken till problemet, men verktygets glänsande klockor och visselpipor förvirrar neofyten. Vid det här laget pratar jag nu klingonska. Inom några sekunder säger jag "Se...där...det är ditt problem." och jag får tillbaka samma frågetecken som jag gav min DBA-mentor för så många år sedan. Dessa noviser vill alltid ha tillgång till verktygen och tror att de kan använda dem som en mästare. De har ingen aning om vad som finns i labyrinten och inte heller någon aning om hur man navigerar i den. Alltför många människor tror att verktygen är den hemliga såsen när det verkligen är personen som använder verktyget. Tyvärr vill vissa personer med tillgång till verktygen bara ha ett snabbt och enkelt svar. De vill inte lägga tid på som så många av oss.

Dags, dags att följa mästarna. Vi har alla vår version av Mt Rushmore. Hugget i sten. Folk som Millsap, Lewis och Shallahammer för att nämna några. Din Mt Rushmore kan ha andra namn eller till och med liknande. Andra som tittar på vårt Mt Rushmore, allt i sten, inser inte att dessa fina människor var våra guider i labyrinten. De visade oss hur man navigerar i labyrinten. De visade oss hur man använder verktygen och vilka verktyg man ska använda när. De av oss som lärt oss av mästarna gör vårt bästa för att betala det framåt och lära andra, även om vi kanske aldrig når så höga höjder, och det är okej.

Moralen i berättelsen är att lära sig dessa verktyg, lära sig vad de gör och vad de inte gör. Lär dig vilka problem de hjälper till att lösa. Utnyttja verktygen, men inse att du behöver lära dig så mycket du kan så att du kan gå i labyrinten med självförtroende. Tyvärr måste jag avsluta min historia här. Någon kom precis in på mitt kontor med ett annat problem med prestandajustering. Dags att gå in i labyrinten igen. Vilken dörr tar jag nu?


  1. Vad är nytt i SQL Server 2019?

  2. Installera och konfigurera MySQL Workbench på Ubuntu 16.04

  3. Temporal databasdesign, med en twist (live kontra utkastrader)

  4. Oracle till Excel - PL/SQL exportprocedur