Un jour, vous vous réveillez et découvrez que vous êtes un administrateur de base de données Oracle. Les dieux ont enfin vu la lumière sur votre véritable potentiel et vous ont permis d'occuper le meilleur emploi du monde ! Vous commencez votre carrière de DBA avec les yeux brillants et la queue touffue. Vous créez de nouvelles bases de données, accordez des privilèges, écrivez du code PL/SQL. La vie est belle. Vous avez hâte de vous lever le matin, de vous servir votre première tasse de café et de diriger votre navigateur vers vos forums Oracle préférés, impatients de vous imprégner de toute une vie de connaissances avant le déjeuner ! Si ces dieux vous sourient toujours, vous pouvez même répondre à quelques questions et être récompensé par des points impressionnants. La vie est belle. La vie est douce.
Alors que vous vous prélassez encore dans l'éclat de votre nouvelle carrière, quelqu'un vient vous voir avec un problème. Un problème de performances. Vous gèlez. Il y a une petite boule dans la gorge lorsque vous vous rendez compte que vous ne savez pas comment résoudre les problèmes de performances de la base de données. Ce que vous n'aviez pas réalisé ce jour-là, c'est que tous les administrateurs de bases de données avant vous se sont trouvés exactement dans la même situation au début de leur carrière. Pourtant, cela n'empêche pas l'autre personne de vous regarder en se demandant pourquoi vous ne résolvez pas immédiatement le problème de performances. Après tout, vous êtes le DBA et vous devez savoir comment faire ces choses. Ce truc magique qu'ils appellent (signale le chant des anges) Réglage des performances . Car il a été écrit, si vous allez être un DBA et survivre, et bien faire ce travail, vous devrez ajuster les performances. Les autres ne sauront jamais ce qui se passe derrière le rideau lorsque vous préparez des potions et lancez des sorts. Tout ce qui les intéresse, c'est que vous ayez résolu leur problème de performances et qu'ils puissent poursuivre leur travail quotidien.
À ce stade, au début de leur carrière, chaque administrateur de base de données décide qu'il doit en savoir plus sur ce qu'il appelle l'optimisation des performances. . Qu'est-ce que c'est? Comment fait-on ça? Comment puis-je devenir la personne la plus importante de mon service informatique parce que j'ai découvert la sauce secrète pour transformer ce rapport de 5 heures en un miracle d'une minute ?
Oh, nous étions si jeunes à l'époque… si naïfs. Nous pensions que c'était facile. Appuyez sur quelques boutons, lancez quelques outils et hop. La solution de réglage des performances est trouvée et nous sommes formidables ! La vie semblait si facile alors que nous nous aventurions sur cette route de briques jaunes. Mais sur cette route, il n'y a pas de corbeaux effrayants. Pas de lions. Pas d'hommes de plomb. Pas même de mignons petits chiens nommés Toto. Non… cette route…. cette route Oracle Performance Tuning est remplie de choses bien plus grandes. Sur cette route, nous rencontrons des utilitaires et des outils. Nous rencontrons Expliquez Plan. Nous rencontrons tkprof et SQLT. Nous trouvons des vues magnifiques comme V$SGA_TARGET_ADVICE et V$SESSION_WAIT et son jumeau V$SESSION_EVENT (pas des jumeaux identiques, mais un coup d'œil et vous savez qu'ils sont liés).
Alors vous y êtes. Votre brillant titre de DBA est toujours assis sous votre nom dans chaque signature d'e-mail que vous envoyez. Et vous avez maintenant tous ces merveilleux outils à votre disposition. Vous avez choisi ASH et AWR parce que, heureusement, votre entreprise vous a offert le pack Diagnostics. Votre bibliothèque est armée de grands tomes comme celui-ci. (plug sans vergogne je sais). Un type formidable sur les forums, comme moi, vous a fait découvrir Lighty. Vous avez toute une boîte à outils à votre disposition. Non! Pas de boîte à outils….warchest ! Les petits pays dans d'autres endroits du monde n'ont pas l'arsenal que vous avez à votre disposition. Pourquoi... Je pourrais appuyer sur ce bouton super secret dans SQL Tuning Advisor et faire exploser l'un de ces pays, *et* faites en sorte que l'ID SQL 98byz76pkyql s'exécute plus rapidement pendant que mon café a encore de la vapeur qui s'en dégage... Je suis si bon.
Vous souvenez-vous du jour où vous avez reçu votre premier numéro de performance et que vous aviez cette boule dans la gorge ? Il y a un autre jour comme celui-là dans votre carrière de DBA. C'est le jour où vous atteignez le labyrinthe de réglage des performances (cue le tonnerre et la foudre). Mais ce n'est pas un labyrinthe. Ceci est différent. La plupart des labyrinthes ont une entrée et une sortie, avec de nombreux virages et décisions en cours de route. Ce labyrinthe, pourquoi, ce labyrinthe est évidemment différent. Ce labyrinthe a de très nombreuses entrées. Et ce labyrinthe a beaucoup, beaucoup de sorties. Chaque entrée est un outil de réglage des performances différent. Et chaque sortie est une solution , mais toutes les solutions ne résolvent pas vraiment le problème de performances. Et c'est l'énigme à laquelle sont confrontés les spécialistes de l'optimisation des performances d'Oracle. J'ai un problème de performances. Je sais que de l'autre côté de ce labyrinthe se trouve ma solution. Mais quelle entrée dois-je choisir ? Une entrée a un plan d'explication écrit au-dessus. Une autre entrée a V$DB_CACHE_ADVICE écrit dessus. Pourquoi il y a toutes ces entrées, une pour chaque outil à ma disposition. C'est un conte de ma jeunesse et j'espère que, comme Bilbo l'a écrit à Frodon, cette histoire pourra également vous aider dans vos aventures.
Alors je choisis une entrée.
J'entre dans le labyrinthe.
Ai-je fait un bon choix ?
Eh bien, voyons où cela mène. Plus loin, la route tourne à gauche. Mais c'est mon seul choix donc je fais avec. Ensuite, j'arrive à une intersection. Je peux aller à droite ou à gauche. Je tourne à droite. Oups… impasse. Alors je rebrousse chemin et prends ça à gauche à la place. Encore une impasse. Zut. Je suis entré dans le labyrinthe de manière incorrecte. Parfois, les outils ne vous mènent à aucune solution. Je retourne donc aux entrées et fais un autre choix, choisis un autre outil.
Je suis maintenant entré dans le labyrinthe une deuxième fois. Mais les choses s'annoncent beaucoup mieux. Je continue. Encore quelques tours. Je peux voir la lumière donc je sais que je me rapproche de la fin. Oui… ça y est, la sortie. Je sors enfin de l'autre côté du labyrinthe. J'ai ma solution de réglage des performances en main, mais après avoir implémenté la solution, je réalise rapidement que cela n'a pas du tout résolu mon problème de performances. Parfois, les outils peuvent vous conduire à des solutions qui n'ont aucune incidence sur votre problème spécifique. Il est donc temps pour ma troisième entrée dans le labyrinthe.
Maintenant, étant un spécialiste astucieux du réglage des performances, j'ai réalisé que toutes les entrées que j'ai choisies jusqu'à présent sont liées aux performances globales de la base de données, mais ce que je recherche vraiment, ce sont les performances liées à une instruction SQL spécifique. Mais je ne sais pas quelle instruction SQL doit être réglée. Comment savoir lequel ? Eh bien, trois portes plus bas se trouve une entrée du labyrinthe marquée SQL Trace. Juste à côté se trouve une porte marquée EM Search Sessions. Je lance une pièce et choisis SQL Trace. Peu de temps après être entré dans le labyrinthe, j'arrive à une intersection en T. Si je vais à gauche, cela me ramène à la porte des sessions de recherche EM. Si je vais à droite, c'est un coup droit vers la sortie. Naturellement, je vais à droite. Mais c'est à ce moment que je sais que parfois, deux outils différents vous mèneront à la même réponse. En sortant du labyrinthe, on me donne un laissez-passer gratuit pour tkprof car après tout, toutes les routes SQL Trace ne mènent-elles pas directement à tkprof ? J'ai maintenant l'instruction SQL incriminée. Mais mon problème n'est pas encore résolu. Que faire ?
Je retourne à l'entrée du labyrinthe. Parfois, nous obtenons une réponse de nos outils de réglage et nous devons effectuer un autre parcours dans le labyrinthe pour approfondir la réponse finale. Cette fois, je franchis la porte du SQLT. Quelques rebondissements, mais ce chemin de labyrinthe est assez facile, semble-t-il. J'arrive à la fin, et je n'ai pas seulement une réponse, j'ai plusieurs réponses. Oh…jour glorieux! J'ai trouvé la mère de tous les outils.
J'ai entendu d'autres DBA parler de ces outils miracles comme les rapports SQLT et AWR. Comme ils sont merveilleux. Ces outils sont si performants que certains DBA ne voient que les entrées SQLT et AWR Report. J'ai toujours pensé qu'il s'agissait de légendes, mais ici enfin, j'ai moi aussi trouvé le seul outil pour les gouverner tous… ok… un pour chaque main. J'ai toutes ces réponses à ma disposition. Maintenant, quelle réponse est directement liée à mon problème de performances. Ici, j'ai mon rapport SQLT et j'ai toutes ces réponses qui y sont contenues. Quelle réponse est la mienne. Lequel?!?!? Parfois, les outils vous donneront trop d'informations. Pour moi, qui est nouveau dans ce truc de réglage des performances, la sortie de SQLT pourrait tout aussi bien être écrite en Klingon. Mais heureusement, je connais un collègue DBA qui est assis à deux cubes de moi et qui parle Klingon. Je lui tends ma sortie SQLT. Il le feuillette et en moins de 30 secondes, il montre une minuscule section du rapport et prononce ces mots magiques. "Tu vois... juste là... c'est ton problème." Avec un air interrogateur sur mon visage, il passe la main sur le rapport et comme par magie, Google Translate a changé quelques mots sur la page et je peux maintenant voir clairement que j'ai un tableau avec de très mauvaises statistiques. Parfois, les outils avec toutes ces réponses font gagner beaucoup de temps à ceux qui savent les utiliser. Ce DBA parlant klingon remonte ses lunettes et dévoile une autre section du rapport SQLT. "Voyez ici, dit-il… ces mauvaises statistiques forcent un FTS" comme si j'étais censé savoir ce qu'est un FTS à ce stade de ma carrière. Mais je ne veux pas avoir l'air d'un n00b total, alors je souris et hoche la tête en signe d'accord.
Ok… Je me rapproche de la résolution de mon problème. Je sais que j'ai de mauvaises statistiques. Je retourne à mon bureau impatient de me mettre au travail pour enfin résoudre mon problème. Alors que je passe devant la fontaine à eau et que je fais le tour de la foule omniprésente de mes collègues qui n'ont rien d'autre à faire que de discuter toute la journée, le soleil brille par une porte du labyrinthe et attire le coin de mon œil… juste une porte. Au-dessus de cette porte se trouve un panneau indiquant DBA_TABLES. Et bien comme tout bon DBA, je me dis que ce n'est pas une mauvaise idée de revérifier ces choses. Attiré par celui-ci, j'entre par la porte DBA_TABLES et me retrouve de nouveau dans le labyrinthe. Je fais un tour rapide et quelque chose me saute dessus comme pour me faire sursauter. Mais je deviens bon à ça. Je me fiche qu'un petit habitant du labyrinthe insiste pour me dire que cette table réside dans l'espace table USERS. Je sais rapidement que cela ne change rien à mon problème. Je continue et j'ignore tous ces petits diablotins avec leurs fausses informations. J'appuie. Et voilà… confirmation à la sortie du labyrinthe qu'il n'y a pas de statistiques sur ce tableau. Une leçon rapide a été apprise ici, parfois, les outils vous donneront des informations qui ne vous concernent pas ce jour .
Je suis peut-être nouveau dans ce jeu DBA, mais je le sais. J'ai besoin de voir comment les choses fonctionnent maintenant, de faire un changement et de mesurer l'amélioration des performances, le cas échéant. Je retourne donc dans le labyrinthe. Cette fois, j'entre par la porte marquée SQL Developer Autotrace et j'exécute l'instruction SQL incriminée. Je reçois non seulement le temps d'exécution de l'instruction SQL, mais je peux voir le nombre de lectures et le plan d'exécution. Je mets rapidement à jour les statistiques sur le tableau que m'a indiqué mon ami parlant le klingon. (rapidement… je pensais que c'était un crétin, mais maintenant il n'est pas si mal. Je peux apprendre de ce type. Peut-être qu'un jour, moi aussi, je parlerai le klingon). Ensuite, j'entre à nouveau dans la porte SQL Developer Autotrace. Non seulement l'exécution de ma requête est passée de 2 minutes d'exécution à 2 secondes, mais les lectures ont chuté de manière significative et le plan d'explication s'est amélioré. Ok, cette dernière partie est un peu exagérée. Je suis encore trop vert pour savoir que le plan d'explication était meilleur, mais en y repensant plus tard dans ma carrière, je sais que c'était le cas. J'apprends rapidement que parfois, les outils de réglage des performances à ma disposition ne sont pas seulement là pour aider à trouver la cause première du problème, mais sont également là pour confirmer que la solution a effectivement résolu le problème. Et parfois, les outils pour confirmer les résultats ne sont pas les outils que j'ai utilisés pour trouver la cause première.
J'ai rapidement informé mon utilisateur final que le problème était résolu. L'utilisateur grogne quelque chose que je n'arrive pas à comprendre et vérifie si sa vie est réellement meilleure. Et c'est là que je le reçois. Le plus beau cadeau qu'un DBA puisse jamais recevoir. C'est vrai… J'ai reçu l'adoration des utilisateurs . Aujourd'hui, je suis un faiseur de miracles ou c'est ce que pense l'utilisateur. Alors que je me tiens dans le cube de cet utilisateur, il crie "IL L'A RÉPARÉ" et au bon moment, la tête de tout le département surgit sur les murs du cube comme des gaufres sortis du sol. Hourra..ils applaudissent ! J'aime la vie se prélasser dans la lueur. Pourquoi la patronne propose même de nous emmener au pub après le travail... le premier tour est pour elle.
Je retourne à mon bureau, impatiente de relever le prochain défi. Ce travail ne pourrait pas être plus agréable.
Je me souviens de mes premières rencontres avec ce Performance Tuning Maze comme si c'était hier. Quand nous plaisantions autour de pintes au pub ce soir-là, je n'osais pas parler de certaines des choses que j'avais vues dans ce labyrinthe. Mes collègues ne comprendraient pas de toute façon. Je ne parle jamais à personne de mes combats avec les dragons MOS. J'ai été brûlé trop de fois. Je ne dis jamais à personne à quel point il est ennuyeux d'exécuter une requête, d'attendre une heure pour un résultat, de réessayer, d'attendre une heure, de réessayer, d'attendre une heure... oups... je me suis assoupi là-bas. Les épreuves et les tribulations de ma jeunesse sont mieux gardées pour une autre fois. Peut-être que j'écrirai un autre livre.
Mais j'ai beaucoup appris à cette époque. Au fil du temps, je suis devenu meilleur et j'ai choisi la meilleure entrée dans le labyrinthe pour le problème à résoudre. Après tout, ce n'est qu'avec l'expérience que l'on peut s'améliorer avec ces élixirs magiques de réglage des performances. J'ai également appris que parfois, un outil semble être le bon pour le travail pour découvrir à mi-chemin de l'effort de réglage qu'un autre outil est mieux adapté.
J'ai également appris que ce n'est qu'en travaillant avec les outils et en apprenant ce dans quoi ils sont bons et inversement ce dans quoi ils ne sont pas bons, que je peux choisir au mieux l'outil approprié pour le travail. À l'époque, j'avais souvent l'impression d'essayer d'enfoncer une vis avec un marteau. Maintenant, je vois une vis et je sais que le meilleur outil est un tournevis.
Au fil du temps, j'ai augmenté le nombre d'entrées dans mon labyrinthe de réglage des performances. Je passe toujours par les portes éprouvées comme celle avec juste un numéro au-dessus, 10046. Dans le passé, on m'a parlé de portes magiques qui menaient à des arcs-en-ciel et des licornes pour découvrir encore un vieux troll grincheux sous un pont. J'étais sceptique quant au fait que Lighty soit un outil aussi magique au début, mais je me trompais sur celui-là.
Oh les histoires que je pourrais vous raconter, mais cette histoire concerne vraiment ce labyrinthe de réglage des performances. Cela revient toujours à ce labyrinthe. Choisissez la meilleure porte possible, mais seule l'expérience peut vous dire laquelle est la meilleure. Cela vous permettra d'arriver à votre solution le plus rapidement. Faire un mauvais virage et recommencer. N'ayez pas peur d'entrer dans le labyrinthe plusieurs fois. Lorsque vous pensez avoir la solution, parcourez le labyrinthe pour vérifier. Ce labyrinthe magique de réglage des performances avec tous ces merveilleux utilitaires et outils de réglage des performances d'Oracle est maintenant devenu l'un de mes endroits préférés pour sortir. J'aime ajouter plus d'entrées tout le temps, en espérant que chaque nouvel outil me mènera au bout du labyrinthe beaucoup plus rapidement. Parfois ils le font et parfois ils ne le font pas.
Je me souviens encore de l'époque où je traînais dans l'ancien labyrinthe du "réglage basé sur le ratio", mais je suis passé à des pâturages plus verts. Je ris encore quand je vois un nouveau DBA debout devant ce vieux labyrinthe, couvert de toiles d'araignées et ils ne peuvent tout simplement pas comprendre l'allusion. Et puis je deviens grincheux quand je leur crie d'oublier ce labyrinthe et de venir ici où tout le monde traîne, seulement pour être rejeté par quelqu'un qui pense qu'ils savent mieux. Eh bien, si jamais nous les revoyons, nous pouvons dire "je vous l'avais dit" et bien rire.
Je travaille souvent avec des gens qui me voient utiliser certains de ces outils brillants. Ils me regardent entrer dans le labyrinthe et sortir de l'autre côté avec la réponse. Donc, leur prochaine question évidente est "puis-je aussi entrer par cette porte?" Je ris. « Bien sûr… allez-y », leur dis-je. Armés de cet outil de réglage cool, mais sans aucune connaissance sur la façon de régler Oracle, ils font une tentative assez bonne, mais faible. Ils m'appellent dans le labyrinthe et me demandent de les aider à résoudre le problème. Nous lançons donc l'outil et l'examinons. Je reconnais instantanément la cause profonde du problème, mais les cloches et les sifflets brillants de l'outil déroutent le néophyte. À ce stade, je parle maintenant le klingon. En quelques secondes, je dis " Tu vois… juste là… c'est ton problème." et je retrouve le même regard interrogateur que j'ai donné à mon mentor DBA il y a tant d'années. Ces novices veulent toujours avoir accès aux outils et pensent pouvoir les manier comme un maître. Ils n'ont aucune idée de ce qu'il y a dans le labyrinthe ni de la façon de s'y retrouver. Trop de gens pensent que les outils sont la sauce secrète alors que c'est vraiment la personne qui manie l'outil. Malheureusement, certaines personnes ayant accès aux outils veulent juste une réponse rapide et facile. Ils ne veulent pas perdre de temps comme beaucoup d'entre nous.
Le temps, le temps de suivre les maîtres. Nous avons tous notre version du Mont Rushmore. Sculpté dans la pierre. Des gens comme Millsap, Lewis et Shallahammer pour n'en nommer que quelques-uns. Votre Mt Rushmore peut avoir d'autres noms ou même des noms similaires. D'autres qui voient notre mont Rushmore, tout gravé dans la pierre, ne réalisent pas que ces braves gens étaient nos guides dans le labyrinthe. Ils nous ont montré comment naviguer dans le labyrinthe. Ils nous ont montré comment utiliser les outils et quels outils utiliser quand. Ceux d'entre nous qui ont appris des maîtres font de leur mieux pour donner au suivant et enseigner aux autres, même si nous n'atteindrons peut-être jamais des sommets aussi élevés, et ce n'est pas grave.
La morale de l'histoire est d'apprendre ces outils, d'apprendre ce qu'ils font et ce qu'ils ne font pas. Découvrez les problèmes qu'ils aident à résoudre. Tirez parti des outils, mais réalisez que vous devez en apprendre autant que possible pour pouvoir parcourir le labyrinthe en toute confiance. Malheureusement, je dois terminer mon histoire ici. Quelqu'un vient d'entrer dans mon bureau avec un autre problème de réglage des performances. Il est temps d'entrer à nouveau dans le labyrinthe. Maintenant, quelle porte dois-je prendre ?
