Inleiding
Dit artikel is een korte bespreking van het belangrijkste geplande onderhoud met een database van het 24/7 informatiesysteem zonder downtime, evenals benaderingen voor de uitvoering ervan in MS SQL Server.
Alle opmerkingen en updates van het artikel worden zeer op prijs gesteld.
Gepland onderhoud
Ik wil u wijzen op het volgende geplande onderhoud:
- Geplande back-ups met verdere verificatie zonder te herstellen
- Gepland herstel van back-ups om hun prestaties te controleren
- Analyse van een gegevensopslagapparaat dat het systeem en alle benodigde databases bevat
- Geplande tests van vereiste services
- Geplande optimalisatie van een systeemprestatie
- Gepland onderhoud van gegevensintegriteit
- Gepland onderhoud van gegevensvalidatie
De eerste drie punten zijn de belangrijkste, omdat ze zorgen voor een systeemherstel na verschillende storingen. Ik zou echter aanraden om ook de drie punten uit te voeren, zodat gebruikers op hun gemak kunnen werken (alle query's moeten dus snel worden uitgevoerd) en zodat gegevens in alle rapportagesystemen worden gevalideerd.
Om gepland onderhoud te automatiseren, is het mogelijk om de onderdelen ervan in de Agent of Windows Scheduler te regelen.
Het zesde punt is gebaseerd op het CHECKDB-commando.
Het zevende punt is geïmplementeerd in de richting van het domeingebied dat in het informatiesysteem wordt gebruikt.
Ik ga in detail praten over de eerste vijf punten.
Geplande back-ups met verdere verificatie zonder te herstellen
Aangezien er veel artikelen over dit onderwerp zijn, moet worden opgemerkt dat het noodzakelijk is om dit geplande onderhoud regelmatig uit te voeren op een back-upserver in plaats van op de hoofdserver. Deze back-upserver moet up-to-date gegevens bevatten (bijvoorbeeld degene die is verkregen met replicatie). Bovendien moet u een back-up maken van alle systeemdatabases (behalve tempdb) op elk exemplaar van de MS SQL Server.
Wanneer de back-up mislukt of een back-upscan een probleem identificeert, is het vereist om deze informatie aan beheerders te rapporteren. U kunt ze bijvoorbeeld e-mailen.
Het is belangrijk om een strategie voor back-up te bepalen, die de volgende vragen zal beantwoorden:
- Hoe vaak en wanneer moeten we een back-up maken van gegevens (volledig, differentieel en transactielogboek)?
- Hoe lang en wanneer moeten we back-ups verwijderen?
Gepland herstel van back-ups om hun prestaties te controleren
Ik raad aan om deze procedure uit te voeren op een back-upserver met hulpprogramma's van derden of de RESTORE commando.
Wanneer het herstellen van een back-up mislukt, is het vereist om deze informatie aan beheerders te melden. U kunt ze bijvoorbeeld e-mailen.
Bovendien is het noodzakelijk om back-ups van systeemdatabases te herstellen. Om dit te doen, moet u ze herstellen als een gebruikelijke gebruikersdatabase met een naam die verschilt van de namen van systeemdatabases.
Analyse van apparaten voor gegevensopslag die het systeem en alle benodigde databases bevatten
U moet analyseren hoeveel ruimte elke database in beslag neemt, hoe de bestandsgrootte verandert en hoe de vrije ruimte op het hele opslagapparaat verandert. U kunt deze taak bijvoorbeeld gedeeltelijk uitvoeren met automatische gegevensverzameling over databasebestanden en logische stations van het besturingssysteem in MS SQL Server.
U kunt deze controle elke dag doen en vervolgens de resultaten verzenden. Zoals gewoonlijk kun je ze naar een e-mail sturen.
Het is ook noodzakelijk om de systeemdatabases te controleren, zodat u zeker weet dat alles correct werkt.
Daarnaast is het belangrijk om opslagapparaten te testen om te controleren of er sprake is van waardevermindering of slechte sectoren.
Houd er rekening mee dat tijdens het testen een apparaat buiten werking zou moeten zijn en dat alle gegevens naar een ander apparaat moeten worden gekopieerd, aangezien het testen het apparaat drastisch belast.
Deze taak is strikt gerelateerd aan de taken van de systeembeheerder, dus we zullen het opzij houden. Om de volledige controle over de zaak te krijgen, moet u de levering van e-mailrapporten automatiseren.
Ik raad aan om deze test twee keer per jaar uit te voeren.
Geplande tests van vereiste services
Serviceonderbrekingen zijn een slechte gewoonte. Daarom komt er bij eventuele storingen een back-upserver in actie. Toch is het noodzakelijk om de logs van tijd tot tijd te controleren. Daarnaast kun je ook denken aan een automatische gegevensverzameling met verdere melding aan een beheerder door een e-mail te sturen.
Het is noodzakelijk om taken van de SQL Server Agent of Windows Scheduler te controleren met een automatische gegevensverzameling over voltooide taken in MS SQL Server.
Geplande optimalisatie van systeemprestaties
Het omvat de volgende aspecten:
- Automatisering van indexdefragmentatie in MS SQL Server-databases
- Het automatiseren van gegevensverzameling over wijzigingen van databaseschema's in MS SQL Server. U kunt een back-up terugzetten en wijzigingen vergelijken, bijvoorbeeld met dbForge
- Opschonen van vastgelopen processen in MS SQL Server automatiseren
- De procedurecache opschonen. Hier moet u bepalen wanneer en wat moet worden opgeruimd
- Een prestatie-indicator implementeren
- Ontwikkelen en aanpassen van geclusterde indexen
Daarnaast raad ik aan om de AUTO_CLOSE . uit te schakelen functie.
Soms, om verschillende redenen, parallelliseert een optimizer een zoekopdracht, die niet altijd optimaal is.
Daarom zijn er enkele aanbevelingen die u in gedachten moet houden:
- Als u veel gegevens krijgt, verlaat dan het parallellisme.
- Als je een paar gegevens krijgt, gebruik dan geen parallellisme.
Er zijn twee parameters in de SQL Server-instantie-instellingen die verantwoordelijk zijn voor parallellisme:
- maximale mate van parallellisme. Om parallellisme uit te schakelen, stelt u "1" in als een waarde, wat betekent dat slechts één processor een code zal uitvoeren.
- kostendrempel voor parallellisme. Het zou standaard ingesteld moeten zijn.
Er zijn twee hoofdwachtrijen:
- een wachtrij voor de CPU-tijd (QCPU-wachtrij). Het vindt plaats wanneer een query is ingeschakeld en wacht op een processor om het uit te voeren.
- een wachtrij voor bronnen (QR-wachtrij). Het vindt plaats wanneer een query wacht tot de resources zijn ontbonden om het proces uit te voeren.
De volgende formule beschrijft de uitvoering van de query (T):
T=TP+TQR+TCPU+TQCPU, waarbij:
- TP maakt tijd voor een plan
- TQR is wachtrijtijd voor bronnen (QR-wachtrij)
- TQCPU is wachtrijtijd voor resources die moeten worden ontbonden (QCPU-wachtrij)
- TCU is tijd om een zoekopdracht uit te voeren
In de systeemweergave sys.dm_exec_query_stats:
- total_worket_time =TP+TCPU+TQCPU
- total_elapsed_time =TQR+TCPU
Met ingebouwde hulpprogramma's kan de uitvoeringstijd van de query niet nauwkeurig worden beoordeeld.
In de meeste gevallen total_elapsed_time geeft u de tijd die dicht bij de uitvoeringstijd van de query ligt.
U kunt de uitvoeringstijd van de query nauwkeuriger bepalen door traceren te gebruiken. Als alternatief kunt u de begin- en eindtijd van de zoekopdracht vastleggen. Wees voorzichtig met sporen, aangezien deze het systeem aanzienlijk belasten. Het is dus beter om het op een back-upserver uit te voeren en gegevens van de hoofdserver te verzamelen. In dit geval wordt alleen het netwerk geladen.
Bij parallellisatie wijst SQL Server N processen toe aan een query (in de editie Standart n<=4). Elk proces vereist CPU-tijd om een query uit te voeren (één proces hoeft niet altijd op elke kern te worden uitgevoerd).
Hoe meer processen je hebt, hoe groter de kans dat sommige worden vervangen door andere, wat leidt tot een hogere TQCPU.
Het kan veel meer tijd kosten om een query uit te voeren bij parallellisatie, in de volgende gevallen:
- Lage schijfsubsysteemdoorvoer. In dit geval kost het ontleden van zoekopdrachten veel meer tijd.
- Gegevens kunnen worden geblokkeerd voor het proces.
- Er is geen index voor het predikaat, wat leidt tot een tabelscan.
Opmerkingen:
U moet parallelle query's uitschakelen op servers waar het niet nodig is om enorme selectie uit te voeren (total_worket_time zou moeten worden verminderd door een mogelijke daling van TCPU en TQCPU). Om dit te doen, moet u de maximale mate van parallellisme instellen op '1' zodat slechts één processor kan werken.
Bovendien kunt u andere frameworks gebruiken om een systeem te bouwen dat de snelle prestaties van databases bepaalt . Het is belangrijk om te begrijpen hoe deze kaders werken en hoe opgehaalde getallen moeten worden geïnterpreteerd.
Wat betreft het ontwikkelen en wijzigen van indexen, namelijk geclusterde indexen, is het belangrijkste punt om te begrijpen hoe de logica van indexen is ingesteld en hoe het werkt.
Houd er rekening mee dat primaire en geclusterde sleutels niet hetzelfde betekenen:
Een primaire sleutel is een kolom of een reeks kolommen, die een record uniek maken in de tabel. Voor de primaire sleutel kunt u een unieke geclusterde of niet-geclusterde index maken. De primaire sleutel wordt in andere tabellen gebruikt als een externe sleutel om gegevensintegriteit te bieden.
Een geclusterde index is een B-boom of de wijziging ervan. De bladeren bevatten zelf gegevens, terwijl de knooppunten indexinformatie bevatten. Bovendien kan een geclusterde index ook niet-uniek zijn. Toch raad ik het aan om uniek te zijn.
Ik wil eraan herinneren dat een B-tree een structuur is die gegevens opslaat in de volgorde gefilterd door een geclusterde index. Het is dus belangrijk om velden die zijn geselecteerd als een geclusterde index in aflopende of oplopende volgorde te groeperen. Voor een geclusterde index kunt u kolommen met een geheel getal (identiteit) gebruiken, evenals gegevens en tijd. Toch zijn kolommen zoals de unieke identifier niet geschikt, omdat de laatste zal leiden tot een regelmatige herstructurering van een B-tree, waardoor het aantal metingen en records op een opslagapparaat waarop de database zich bevindt zal toenemen.
Bovendien moet u ervoor zorgen dat de index wordt gebruikt met de systeemweergave sys.dm_db_index_usage_stats.
PS Het is noodzakelijk om te controleren of gegevens up-to-date zijn op een back-upserver, evenals om een systeem te controleren dat deze gegevens synchroniseert (bijvoorbeeld replicaties).
Lees ook:
Indexdefragmentatie automatiseren in MS SQL Server-databases
Automatische gegevensverzameling van wijzigingen in het databaseschema in MS SQL Server
Automatisch verwijderen van vastgelopen processen in MS SQL Server
Problemen met langlopende zoekopdrachten in MS SQL Server oplossen
Een prestatie-indicator implementeren