Waarom is het afstemmen van SQL-prestaties zo belangrijk voor databasebeheer?
Omdat het u veel geld kan besparen. Heb geduld met me en je zult zien hoe.
SQL-prestaties afstemmen en databasebeheer - de punten verbinden
De meeste databaseprofessionals besteden hun tijd aan het aanhouden van de lichten. Ze investeren het grootste deel van hun inspanningen in het garanderen van uptime door middelen zoals geheugen, opslag en netwerkdoorvoer in de gaten te houden. Dat is een groot deel van databasebeheer, maar naarmate meer bedrijven hun databases verplaatsen naar bijna grenzeloze cloudbronnen zoals AWS en Azure, zijn andere aspecten belangrijker geworden.
Het afstemmen van SQL-prestaties is een van die aspecten. Als de lichten eenmaal veilig blijven branden en u hogerop komt in de hiërarchie van behoeften in databasebeheer, is het volgende dat u wilt betere prestaties, en dat vereist afstemming.
Eerste vragen bij het afstemmen van prestaties in SQL
Vroeg of laat komen veel databaseprofessionals voor een SQL Server te staan die ze niet hebben gebouwd. Er zijn niet veel handleidingen voor die situatie. Het afstemmen van SQL-prestaties is een oefening in graven, uitzoeken wat er mis is en het vervolgens iteratief repareren.
In uw eerste reparaties raakt u misschien helemaal geen SQL-instructies aan. Sommige databaseprofessionals beginnen op gebruikers-/sessieniveau. Ze gaan naar waar de gebruikers ontevreden zijn, luisteren naar hun klachten en stellen vragen.
- Welke schermen of pagina's duren te lang om te renderen?
- Is de applicatie langzamer wanneer ze een nieuw ticket maken of een bestaand ticket openen?
- Duurt het lang om een record op te slaan?
- Hoe lang is "een lange tijd?"
Zodra ze die antwoorden hebben, gaan ze kijken wat het in de database veroorzaakt.
Dat is beter dan op de eerste dag gaan zitten en besluiten iets als fragmentatie aan te pakken, wat gebruikers misschien helemaal niet treft. Het punt is om te beginnen met wat gebruikers belangrijk vinden.
Denk ook aan het instantie-/databaseniveau. In de Microsoft-wereld zijn bijvoorbeeld SQL Server Agent-banen een goede plek om te beginnen. Het zijn een reeks acties die gewoonlijk een administratieve taak definiëren die u kunt controleren op succes of mislukking. Ze zijn bedoeld om handig te zijn, maar zoals veel dingen in databasebeheer, stapelen ze zich op omdat mensen vergeten hoe ze zijn ontstaan en wat ze doen.
Het kan zijn dat meerdere taken hetzelfde doen, zoals het uitvoeren van verschillende versies van een indexscript of, erger nog, elkaar tegenwerken. Bekijk de reeds geconfigureerde jobs aan de hand van twee vragen:"Wat doet deze job?" en, belangrijker nog:"Als ik stop met die baan, zal er dan iets ergs gebeuren?"
Op welke factoren moet je letten?
Zodra u het niveau van prestatieafstemming van SQL bereikt, neemt het zijn aanwijzingen voor gedrag af van verschillende factoren. Zoals beschreven tijdens onze Ask the Experts:Database Performance Roundtable-webcast, hoeft u minder tijd te besteden aan het afstemmen van de SQL zelf als u factoren als deze vindt en correct interpreteert:
- Blokkeren — Als de server blokkeert, is het als een tikkende tijdbom. Stel dat een script een transactie start en deze niet sluit; dat zou kunnen leiden tot een logbestand dat alleen maar groeit en groeit totdat de ruimte opraakt. Blokkeren is slecht nieuws voor de prestaties, dus zoek er meteen naar.
- Agenten — Net als bij SQL Server Agent-taken, is het bekend dat beheerders per ongeluk prestatieverslechterende taken in taken verpakken. Ze kunnen transacties uitvoeren of indexen opnieuw opbouwen in een taak, of de database verkleinen in een transactie. Overweeg in een dergelijk geval de agent tijdelijk uit te schakelen om alle bijbehorende taken af te sluiten. Het is een agressieve techniek, maar als het de prestaties verbetert, weet je waarom.
- Wachtstatistieken — Stel jezelf de vraag:"Waar wacht de server nu op?" Metrieken zoals de levensverwachting van pagina's en de lengte van de schijfwachtrij hebben enkele antwoorden, maar ze bieden slechts een beperkt beeld. Wachtstatistieken laten u alles zien door de lens van wachttypen en wachtcategorieën, zodat u zich kunt concentreren op de ongeveer vijf wachtgebeurtenissen die de meeste tijd in beslag nemen. Sp_BlitzFirst van Brent Ozar is een vertrouwde, opgeslagen procedure om te ontdekken waar uw SQL Server-query's momenteel op wachten. Als u vervolgens langetermijnpatronen in wachtstatistieken voor uw server wilt bestuderen, kunt u een prestatiebewakingstool gebruiken.
- Beheerdersactiviteit — Dit staat ook bekend als "pilot error", omdat sommige prestatieproblemen ontstaan door wat u zelf doet. Stel dat u zowel SQL Server Activity Monitor als SQL Server Profiler tegelijkertijd uitvoert en probeert de Query Store te leren. Je kunt het waarnemerseffect niet ontlopen; als je alles op die manier bijhoudt, vraag je alleen maar om de database te vertragen.
- Indexen — Voor iets dat gunstig zou moeten zijn, kunnen indexen je zeker pijn in de nek geven. Sterker nog, ze verdienen meer dan één kogel. Lees verder.
SQL-prestaties afstemmen betekent goed naar indexen kijken
Voor een groot deel komt het afstemmen van SQL-prestaties neer op het afstemmen van de index. Als je dat onder de knie hebt voor databasebeheer op locatie, zijn je vaardigheden gelukkig gemakkelijk overdraagbaar naar databasebeheer in de cloud.
Indexafstemming wordt steeds belangrijker vanwege de evoluerende verscheidenheid aan indexen:geclusterd, niet-geclusterd, uniek, gefilterd, columnstore, hash, voor geheugen geoptimaliseerd niet-geclusterd, XML, ruimtelijk en full-text, om er maar een paar te noemen. Maar een ding dat nooit is veranderd, is de eerste kolom van de index, die de indexbeslissingen aanstuurt die door de database-engine worden genomen.
Veel leveranciers verkopen en implementeren applicaties met veel goedbedoelde indexen die uiteindelijk nooit worden gebruikt of, erger nog, de prestaties belemmeren. Als u de ongebruikte indexscripts of indexconsumptiescripts in sommige softwareproducten onderzoekt, zult u een overdaad aan indexen op een externe sleutel vinden. Als het product bijvoorbeeld 20 externe sleutels gebruikt, kunnen de leveranciers maar liefst 20 indexen leveren, plus tien indexen met één kolom, plus nog eens tien indexen op een unieke geclusterde index, enzovoort.
Wanneer u de mogelijkheid heeft, is de betere manier om database-architectuur te benaderen, te beginnen met één geclusterde index waarvan u denkt dat deze de tabel het beste vertegenwoordigt. Laat het systeem vervolgens een tijdje zichzelf draaien. Als u meer indexen nodig heeft, maakt u deze aan. Indexen toevoegen is een oefening in het inruilen van betere prestaties hier met problemen zoals het opvullen van schijfruimte en vergrendelen daar. Het wordt moeilijk in te zien hoe elke extra index het systeem in het algemeen beïnvloedt.
Overweeg trouwens om indexen te elimineren - de manier waarop een persoon met allergieën voedselgroepen zou elimineren - om te zien hoe de prestaties veranderen. Probeer elke index op uw dev-instantie te verwijderen en kijk welke van invloed zijn op uw top vijf van zoekopdrachten.
Prestaties afstemmen in SQL Server — tools die daarbij horen
Merk op dat u niet de enige bent in dit streven. SQL Server bevat functies die zijn ontworpen om de prestaties te verbeteren.
Met planhandleidingen kunt u wijzigen hoe SQL Server een bepaalde query uitvoert, en hoewel het geen pure afstemming van SQL-prestaties is, heeft dit wel invloed op de prestaties. Veel applicaties bevatten SQL-query's die zijn geschreven door een externe leverancier, en zelfs als die query's slechte prestaties veroorzaken, zijn sommige databaseprofessionals begrijpelijkerwijs terughoudend om ze te wijzigen. Met plangidsen kunt u een vraaghint of een vast plan aan de vraag toevoegen en beïnvloeden hoe deze verloopt.
Het nadeel van plangidsen is echter dat hoewel ze in de loop van de tijd niet veranderen, de omgeving om hen heen dat wel doet. Net als een gedrukte routekaart, kunnen ze op korte termijn goed werken en binnen de kortste keren verouderd raken, dus als u erop gaat vertrouwen, kunt u ze beter af en toe opnieuw bekijken.
Gerelateerd aan planhandleidingen is Query Store, een functie van SQL Server waarmee u de query's kunt identificeren en afstemmen die de meeste bronnen in uw systeem verbruiken. Query Store is niet standaard ingeschakeld voor nieuwe SQL Server- en Azure Synapse Analytics-databases (SQL DW). Maar het is standaard ingeschakeld in nieuwe Azure SQL Databases.
Over het algemeen is het niet moeilijk om Query Store in te schakelen, maar niet elke SQL Server heeft het vanaf het begin nodig. Sommige beheerders weten niets van Query Store en sommigen weten ervan, maar hebben nog niet de tijd genomen om het adequaat te onderzoeken; ze kunnen het beter uitgeschakeld laten. Als ze later begrijpen hoe Query Store werkt, kunnen ze het gebruiken om prestatieverschillen te vinden die worden veroorzaakt door wijzigingen in het queryplan.
Ten slotte analyseert de Database Engine Tuning Advisor workloads en beveelt indexen of partitioneringsstrategieën aan om de queryprestaties te verbeteren. Het is een goed idee om Tuning Advisor op uw database uit te voeren; voer het gewoon niet te snel uit. Zorg ervoor dat uw database voldoende gegevens bevat zodat indexaanbevelingen geldig zijn. Wanneer u uw toepassing voor het eerst bouwt, heeft u mogelijk slechts duizend rijen in elke tabel. De aanbevelingen van Tuning Advisor zijn nuttiger als de database eenmaal is gegroeid.
Laat me het geld zien
Zoals ik aan het begin al zei, is het afstemmen van SQL-prestaties belangrijk voor databasebeheer omdat het u geld kan besparen. Hoe?
Vooral in de cloud, waar schalen met creditcard populair is, ontdekken IT-teams hoe duur maandelijkse opslag echt kan zijn. Bovendien beginnen ze te begrijpen dat het uitvoeren van slecht geschreven query's en het laten beheren van hun indexen door AWS en Azure de kosten voor cloudcomputing verhoogt. Langzame zoekopdrachten en slechte indexen kosten u geld.
Het afstemmen van SQL-prestaties gaat over het goed krijgen van al deze dingen. Op die manier behoudt u controle over uw uitgaven, of u nu in de wereld van OpEx op locatie blijft of migreert naar de CapEx-wereld van de cloud.