Není to tak dávno, co jsem našim pracovníkům zabývajícím se vývojem aplikací poskytl návod na Explain Plan. Jedna otázka, která se objevila, byla, jak se rozhodnu, které příkazy SQL potřebují vyladění? Používám několik různých přístupů a nacházím kandidáty na ladění SQL z různých úhlů.
- Běžně provádím kontroly kódu u příkazů SQL, které zasahují do naší databáze. Využívám své zkušenosti k rychlému pohledu na příkaz SQL, který je nový nebo byl výrazně upraven, abych se rozhodl, zda musím SQL dále prozkoumat. Pokud například dotaz na tabulku vyhledává ve sloupci PK nebo Unique, mohu si být docela jistý, že poběží rychle. Pokud mi příkaz SQL připadá podezřelý, provedu jej pomocí plánu vysvětlení a/nebo příkaz načasuji, abych zajistil, že bude fungovat dostatečně.
- Upozornil mě Enterprise Manager společnosti Oracle na spor o zdroje v našem testovacím databázovém systému. Jakékoli příkazy SQL, které jsem vynechal během kontroly kódu, lze někdy nalézt zde. Pokud dostanu upozornění na spor o zdroj, skočím dál a zjistím, zda problém nezpůsobuje příkaz SQL nebo dva. Toto je moje poslední šance zachytit příkazy SQL předtím, než se dostanou do produkce.
- Využívám Ignite pro Oracle. Tento produkt je od Confio, ale Confio je nyní součástí Solarwinds. Normálně produkty dodavatele nezapojuji, ale v tomto případě udělám výjimku. Na Ignite se mi líbí, že si od něj každé pondělí nechávám e-mailem zprávu. Zpráva obsahuje nejlepších N pachatelů podle doby čekání. Podívat se na tuto zprávu mi trvá několik sekund. Hledám velké pruhy ve zprávě. Na ukázkovém snímku obrazovky níže můžete vidět modrý pruh, který okamžitě upoutá vaši pozornost. Číslo vpravo je hodnota id a pokud na něj kliknete, můžete získat text SQL. Je to skvělý způsob identifikace příkazů SQL, které je třeba vyladit. Je to super rychlé a super snadné.
Jak vidíte, snažím se najít problematické SQL, jak jsou vyvíjeny, když jsou v našem testovacím systému, a dokonce i poté, co se dostaly do výroby.