Introduktion
Den här artikeln är en kort genomgång av det huvudsakliga schemalagda underhållet med en databas över informationssystemet dygnet runt som inte har driftstopp, samt metoder för att köra dem i MS SQL Server.
Alla kommentarer och uppdateringar av artikeln uppskattas mycket.
Schemalagt underhåll
Det finns följande planerade underhåll som jag skulle vilja påpeka:
- Schemalagda säkerhetskopieringar med ytterligare verifiering utan återställning
- Schemalagd återställning av säkerhetskopior för att verifiera deras prestanda
- Analyse av datalagringsenhet som innehåller systemet och alla nödvändiga databaser
- Schemalagd testning av obligatoriska tjänster
- Schemalagd optimering av ett systemprestanda
- Schemalagt underhåll av dataintegritet
- Schemalagt underhåll av datavalidering
De första tre punkterna är de viktigaste, eftersom de ger en systemåterställning efter olika fel. Jag skulle dock rekommendera att köra minst tre punkter också, så att användarna kan arbeta med lätthet (därmed bör alla frågor köras snabbt) och så att data bör valideras i alla rapporteringssystem.
För att automatisera schemalagt underhåll är det möjligt att ordna dess delar i Agent eller Windows Scheduler.
Den sjätte punkten är baserad på kommandot CHECKDB.
Den sjunde punkten implementeras mot det domänområde som används i informationssystemet.
Jag kommer att prata i detalj om de första fem punkterna.
Schemalagda säkerhetskopieringar med ytterligare verifiering utan återställning
Eftersom det finns många artiklar om detta ämne, bör det noteras att det är nödvändigt att regelbundet utföra detta schemalagda underhåll på en backupserver, snarare än på huvudservern. Denna backupserver bör innehålla uppdaterade data (till exempel den som ficks med replikering). Dessutom måste du säkerhetskopiera alla systemdatabaser (förutom tempdb) på varje instans av MS SQL Server.
När säkerhetskopieringen misslyckas, eller en säkerhetskopiering identifierar ett problem, är det nödvändigt att rapportera denna information till administratörer. Du kan till exempel maila dem.
Det är viktigt att fastställa en strategi för säkerhetskopiering, som kommer att besvara följande frågor:
- Hur ofta och när ska vi säkerhetskopiera data (fullständig, differential- och transaktionslogg)?
- Hur länge och när ska vi ta bort säkerhetskopior?
Schemalagd återställning av säkerhetskopior för att verifiera deras prestanda
Jag rekommenderar att du kör den här proceduren på en backupserver med tredjepartsverktyg eller RESTORE kommando.
När återställningen av säkerhetskopian misslyckas, är det nödvändigt att rapportera denna information till administratörer. Du kan till exempel maila dem.
Dessutom är det nödvändigt att återställa säkerhetskopior av systemdatabaser. För att göra detta måste du återställa dem som en vanlig användardatabas med ett namn som skiljer sig från namn på systemdatabaser.
Analyse av datalagringsenheter som innehåller system och alla nödvändiga databaser
Du måste analysera hur mycket utrymme varje databas tar, hur filstorlekar ändras och hur storleken på ledigt utrymme i hela lagringsenheten ändras. Till exempel kan du utföra denna uppgift delvis med automatisk datainsamling om databasfiler och logiska enheter i operativsystemet i MS SQL Server.
Du kan göra denna kontroll varje dag och sedan skicka resultat. Som vanligt kan du skicka dem till ett e-postmeddelande.
Det är också nödvändigt att övervaka systemdatabaser så att du ser till att allt fungerar korrekt.
Dessutom är det viktigt att testa lagringsenheter för att kontrollera om det finns några avskrivningar eller dåliga sektorer.
Observera att under testning bör en enhet vara ur funktion och all data bör kopieras till en annan enhet eftersom testning belastar enheten drastiskt.
Denna uppgift är strikt relaterad till systemadministratörens uppgifter så vi kommer att hålla den åt sidan. För att ta full kontroll över ärendet måste du automatisera leveransen av e-postrapporter.
Jag skulle rekommendera att utföra detta test två gånger om året.
Schemalagd testning av nödvändiga tjänster
Serviceavbrott är en dålig praxis. Därför kommer en backupserver att träda i kraft vid eventuella fel. Ändå är det nödvändigt att kontrollera loggar då och då. Dessutom kan du också tänka dig en automatisk datainsamling med ytterligare meddelande till en administratör genom att skicka ett e-postmeddelande.
Det är nödvändigt att kontrollera uppgifterna för SQL Server Agent eller Windows Scheduler med en automatisk datainsamling om slutförda uppgifter i MS SQL Server.
Schemalagd optimering av ett systemprestanda
Det inkluderar följande aspekter:
- Automatisk indexdefragmentering i MS SQL Server-databaser
- Automatisk datainsamling om ändringar av databasscheman i MS SQL Server. Du kan återställa en säkerhetskopia och jämföra ändringar, till exempel med dbForge
- Automatisk rensning av processer som har fastnat i MS SQL Server
- Rensar upp procedurens cache. Här måste du bestämma när och vad som ska städas upp
- Implementera en prestationsindikator
- Utveckla och ändra klustrade index
Dessutom rekommenderar jag att du stänger av AUTO_CLOSE funktion.
Ibland, av olika anledningar, parallelliserar en optimerare en fråga, vilket inte alltid är optimalt.
Därför finns det några rekommendationer du bör tänka på:
- Om du får mycket data, lämna då parallellism.
- Om du får några data, använd inte parallellism.
Det finns två parametrar i SQL Server-instansinställningarna som är ansvariga för parallellism:
- max grad av parallellitet. För att stänga av parallellism, ställ in "1" som ett värde, vilket betyder att endast en processor kommer att exekvera en kod.
- kostnadströskel för parallellitet. Den bör vara inställd som standard.
Det finns två huvudköer:
- en kö för CPU-tiden (QCPU-kö). Det sker när en fråga har aktiverats och väntar på att en processor ska köra den.
- en kö för resurser (QR-kö). Det sker när en fråga väntar på att resurserna ska vara obundna för att exekvera processen.
Följande formel beskriver exekveringen av frågan (T):
T=TP+TQR+TCPU+TQCPU, där:
- TP sammanställer tid för en plan
- TQR är kötid för resurser (QR-kö)
- TQCPU är kötid för resurser att vara obundna (QCPU-kö)
- TCPU är dags att köra en fråga
I systemvyn sys.dm_exec_query_stats:
- total_worket_time =TP+TCPU+TQCPU
- total_elapsed_time =TQR+TCPU
Inbyggda verktyg tillåter inte exakt bedömning av exekveringstiden för frågor.
I de flesta fall total_elapsed_time ger dig den tid som är nära exekveringstiden för en fråga.
Du kan bestämma exekveringstiden för frågan mer exakt genom att använda spårning. Alternativt kan du logga förfrågans start- och sluttid. Var försiktig med spår eftersom de belastar systemet avsevärt. Därför är det bättre att utföra det på en backup-server och samla in data från huvudservern. I det här fallet kommer bara nätverket att laddas.
Vid parallellisering allokerar SQL Server N processer till en fråga (i utgåvan Standart n<=4). Varje process kräver CPU-tid för att exekvera en fråga (en process ska inte alltid exekveras på varje kärna).
Ju fler processer du har, desto större chans att vissa kommer att ersättas av andra, vilket leder till ökad TQCPU.
Det kan ta mycket längre tid att köra en fråga vid parallellisering, i följande fall:
- Låg disksubsystemgenomströmning. I det här fallet tar frågeuppdelningen mycket längre tid.
- Data kan blockeras för processen.
- Det finns inget index för predikatet, vilket leder till en tabellsökning.
Anmärkningar:
Du måste inaktivera parallella frågor på servrar där det inte finns något behov av att utföra ett stort urval (total_worket_time bör minskas på grund av en möjlig minskning av TCPU och TQCPU). För att göra detta måste du ställa in funktionen för maximal grad av parallellitet till '1' för att bara en processor ska fungera.
Dessutom kan du använda andra ramverk för att bygga ett system som bestämmer höghastighetsprestanda för databaser . Det är viktigt att förstå hur dessa ramverk fungerar och hur man tolkar hämtade siffror.
När det gäller utveckling och modifiering av index, nämligen klustrade index, är huvudpoängen att förstå hur logiken för index är inställd och hur den fungerar.
Tänk på att primära och klustrade nycklar inte betyder detsamma:
En primär nyckel är en kolumn eller en uppsättning kolumner, som gör en post unik i tabellen. För primärnyckeln kan du antingen skapa ett unikt klustrat eller icke-klustrat index. Primärnyckeln används i andra tabeller som en främmande nyckel för att tillhandahålla dataintegritet.
Ett klustrat index är ett B-träd eller dess modifiering. Bladen innehåller själva data medan noderna innehåller indexinformation. Dessutom kan ett klustrat index också vara icke-unik. Ändå rekommenderar jag att den är unik.
Jag skulle vilja påminna om att ett B-träd är en struktur som lagrar data i den ordning som filtrerats av ett klustrat index. Därför är det viktigt att gruppera fält som valts som ett klustrat index i fallande eller stigande ordning. För ett klustrat index kan du använda kolumner med heltal (identitet), samt data och tid. Ändå är kolumner som unik identifierare inte lämpliga eftersom det senare kommer att leda till regelbunden omstrukturering av ett B-träd, vilket kommer att öka mängden avläsningar och poster på en lagringsenhet där databasen finns.
Dessutom måste du se till att indexet används med systemvyn sys.dm_db_index_usage_stats.
P.S. Det är nödvändigt att kontrollera om data är uppdaterade på en backupserver, samt kontrollera ett system som synkroniserar dessa data (till exempel replikeringar).
Läs även:
Automatisera indexdefragmentering i MS SQL Server-databaser
Automatisk datainsamling av databasschemaändringar i MS SQL Server
Automatisk radering av processer som har fastnat i MS SQL Server
Felsökning av långa frågor i MS SQL Server
Implementera en prestationsindikator