Niet zo lang geleden gaf ik een tutorial over Explain Plan aan onze applicatie-ontwikkelingsmedewerkers. Een vraag die naar voren kwam, was hoe ik moet beslissen welke SQL-statements moeten worden aangepast? Ik gebruik een paar verschillende benaderingen en vind kandidaten voor SQL-afstemming vanuit verschillende hoeken.
- Ik voer routinematig code-reviews uit op SQL-statements die onze database raken. Ik gebruik mijn ervaring om snel naar een SQL-instructie te kijken die nieuw is of aanzienlijk is gewijzigd om te beslissen of ik de SQL verder moet onderzoeken. Als een zoekopdracht op een tabel bijvoorbeeld zoekt in een PK- of Unieke kolom, dan kan ik er vrij zeker van zijn dat deze snel zal werken. Als de SQL-instructie er verdacht uitziet, zal ik hem door Explain Plan heen lopen en/of de instructie timen om ervoor te zorgen dat deze voldoende werkt.
- Ik laat Oracle's Enterprise Manager me waarschuwen voor resourceconflicten in ons testdatabasesysteem. Alle SQL-statements die ik tijdens de codebeoordeling heb gemist, zijn soms hier te vinden. Als ik een waarschuwing krijg over een geschil over hulpbronnen, spring ik erop en kijk of een of meer SQL-instructies een probleem veroorzaken. Dit is mijn laatste kans om SQL-statements te vangen voordat ze in productie gaan.
- Ik gebruik Ignite voor Oracle. Dit product is van Confio, maar Confio is nu onderdeel van Solarwinds. Normaal gesproken sluit ik geen producten van leveranciers aan, maar in dit geval maak ik een uitzondering. Wat ik leuk vind aan Ignite, is dat ik het me elke maandag een rapport laat e-mailen. Het rapport bevat de Top N overtreders op basis van wachttijd. Het kost me seconden om dit rapport te bekijken. Ik zoek naar de grote balken in het rapport. In het onderstaande voorbeeldscherm ziet u een blauwe balk die onmiddellijk uw aandacht trekt. Het getal aan de rechterkant is een id-waarde en als u erop klikt, kunt u de SQL-tekst krijgen. Dit is een geweldige manier om de SQL-instructies te identificeren die moeten worden aangepast. Het is supersnel en supergemakkelijk.
Zoals je kunt zien, probeer ik problematische SQL te vinden terwijl ze worden ontwikkeld, wanneer ze zich in ons testsysteem bevinden en zelfs nadat ze in productie zijn genomen.