Underhåll av SQL Server-systemdatabaser

SQL Server Installation skapar som standard flera systemdatabaser per instans för att underhålla och administrera den instansen. I den här artikeln kommer vi att undersöka dessa systemdatabaser och förstå deras ansvar.

SQL-serversystemdatabaser

I SQL Server skapas systemdatabaser under installationsprocessen för att lagra SQL Server-instansspecifika konfigurationsdetaljer för att fungera normalt. Varje installation av SQL Server skapar minst 5 systemdatabaser och 1 replikeringsrelaterad systemdatabas med namnet distributionsdatabas som kommer att skapas av användare om replikering är konfigurerad i den instansen. Varje systemdatabas har sitt syfte och vi kommer att undersöka detta i detalj senare i den här artikeln.

Systemdatabaserna är:

Master – Installerad som standard
Msdb – Installerad som standard
Modell – Installerad som standard
Tempdb – Installerad som standard
Resurs – Installerad som standard . Introducerad i SQL Server 2005 och tillgänglig i senare SQL Server-versioner och därför inte tillgänglig i SQL Server 2000 och tidigare versioner.
Distribution – Skapat av användaråtgärd . Användare kan skapa distributionsdatabasen för att konfigurera replikering.

För att se systemdatabasen installerad i SQL Server kan vi använda SSMS.

Anslut till din SQL Server-instans, expandera Databaser > Systemdatabaser :

Har du märkt att Resursen saknas databas i listan ovan? Saken är att resursdatabasen är en speciell systemdatabas som inte är listad i SSMS Object Explorer. Däremot kan vi fråga efter resursdatabasens detaljer från ett system DMV som heter sys.sysaltfiles och kör frågan:

SELECT dbid, db_name(dbid) database_name, fileid, name, filename
FROM sys.sysaltfiles
WHERE dbid NOT BETWEEN 5 AND 11

I resultaten kan vi se systemdatabaserna i ordning:master, tempdb, model, msdb, distribution , och slutligen dbid 32767 som är en resursdatabas. Den här resursdatabasen visar dock inget databasnamn eftersom den inte har en post i sys.databases . Jag har uteslutit ett par användardatabaser mellan dbid 5 och 11 och inkluderat AdventureWorks_REPL som ett exempel för att visa att DMV också kan visa användardatabaser. Vi kommer att gå in mer i detalj om resursdatabasen och andra systemdatabaser senare.

SQL System Databaser Restriktioner

Eftersom systemdatabaser innehåller kritiska systemkonfigurationsdetaljer bör det finnas lämpliga säkerhetsåtgärder för att undvika oavsiktlig radering av data. Därför har systemdatabaser följande begränsningar jämfört med användardatabaser:

Systemdatabaser kan inte tas offline

Vi kan ta en användardatabas offline med kommandot ALTER DATABASE som visas nedan:

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

Men om vi försöker ta någon av systemdatabaserna OFFLINE med kommandot ovan, kommer vi att få ett felmeddelande enligt nedan:

Systemdatabaser kan inte släppas

Medan vi kan släppa användardatabaserna genom att köra kommandot DROP DATABASE

DROP DATABASE AdventureWorks

Om vi försöker släppa någon av systemdatabaserna kommer vi att få felmeddelandet enligt nedan:

Ägare av systemdatabaser kan inte ändras

Ägaren av systemdatabasen är sa som standard. Det går inte att ändra. Försök att byta namn på systemdatabasens ägare kommer att provocera fram fel.

Det finns dock ett undantag. Det är möjligt att ändra ägaren till msdb databas.

use [master];
GO
ALTER AUTHORIZATION ON DATABASE::[master] TO [RRJ\RRJ]
GO

Databasnamn på systemdatabaser kan inte ändras

Om vi försöker byta namn på systemdatabaserna får vi ett felmeddelande som visas nedan:

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

Sorteringen av systemdatabaser kan inte ändras

Systemdatabaser skapas med det sorteringsnamn som valts under installationen av SQL Server. När den väl har installerats kan samlingen av systemdatabaser inte ändras. Det enda sättet att ändra systemdatabasens sortering är att installera om SQL Server-instansen med korrekt sortering.

Primär filgrupp av systemdatabaser kan inte ställas in på READ_ONLY-läge

Eftersom systemdatabasen fångar kritisk information relaterad till SQL Server-instanser, tillåter inte SQL Server att de primära datafilerna som finns i den primära filgruppen ställs in som skrivskyddade .

Ändra datafångstfunktion kan inte aktiveras i systemdatabaser

Denna funktion används för att spåra varje DML-ändring som sker i en databas på de spårade tabellerna. Om vi försöker aktivera funktionen Change Data Capture på någon systemdatabaser kommer felet att inträffa:

use master
GO
exec sys.sp_cdc_enable_db

Nu när vi är tydliga med skillnaden mellan systemdatabaser och användardatabaser kan vi undersöka syftet med varje systemdatabas mer i detalj.

Masterdatabas i SQL Server

Mastersystemdatabasen innehåller nyckelkonfigurationsdetaljer relaterade till SQL Server-instansen . SQL Server förlitar sig på dem när den startar en viss instans. Om det av någon anledning är omöjligt att starta huvuddatabasen, kan inte heller SQL Server-instansen startas.

Dessa nyckeldetaljer som lagras i huvuddatabasen inkluderar inloggningskonton, länkade serverdetaljer, slutpunkter, systemkonfigurationsinställningar och detaljer om alla användardatabaser.

Nu kommer frågan. Hur vet SQL Server-tjänsten var data och loggfiler för huvuddatabasen är tillgängliga? Svaret ligger i startkonfigurationsparametrarna för SQL Server-tjänsten.

För att se startkonfigurationsparametrarna för en SQL Server-instans bör vi först känna till det inbyggda verktyget SQL Server Configuration Manager . Det hjälper till att hantera alla SQL Server-relaterade tjänster av alla instanser som är tillgängliga på den specifika servern. För att se dessa data, öppna SQL Server Configuration Manager och den visar listan enligt nedan:

Klicka på SQL Server Services för att se listan över tjänster som är tillgängliga på denna server eller PC:

Vänta en sekund! Det ser bekant ut för services.msc listar alla tjänster som är tillgängliga på servern men visar bara SQL Server-relaterade tjänster.

Låt oss öppna services.msc för att se hur det ser ut och verifiera skillnaderna mellan SQL Server Configuration Manager och services.msc för att jämföra vilken som är bäst.

SQL Server Configuration Manager visar process-ID för de tjänster som för närvarande körs. Vi kunde inte hitta det i services.msc . Naturligtvis kan vi få den här informationen från Windows Task Manager, men SQL Server Configuration Manager hjälpte oss att se detta på ett enda ställe.

Låt oss nu ta en detaljerad vy. Högerklicka på SQL Server-tjänsten från services.msc . Du kommer att se menyerna nedan:Allmänt , Logga in , Återställning och beroenden .

Från SQL Server Configuration Manager, högerklicka på SQL Server(MSSQLSERVER) tjänst> Egenskaper . Den listar menyerna nedan – Logga in, service. FileStream, Advanced, Alwayson OnHigh Availability och Startparametrar .

Startparametrar av tjänsten som lagrar platsen för huvuddatabasdata och loggfiler var endast tillgänglig i SQL Server Configuration Manager .

Klicka på Startparametrar för att se detaljerna – för Befintliga Parametrar . Du kommer att se följande information:

Den fysiska platsen för huvuddatabasen Datafil
Den fysiska platsen för huvuddatabasen Transaktionsloggfil
Den fysiska platsen för ErrorLog-mappen där fel relaterade till SQL Server Service finns.

Vi kan lägga till fler startparametrar som Enanvändarläge (-m) , etc. För det måste vi ange de nödvändiga värdena i Ange en startparameter och klicka på Lägg till .

Vi har märkt att SQL Server Configuration Manager inte bara visar avancerade detaljer utan också tillåter oss att göra många avancerade konfigurationer relaterade till SQL Server-tjänsten. Därför skulle jag personligen rekommendera att du använder SQL Server Configuration Manager för att stoppa/starta SQL Server-relaterade tjänster jämfört med standardalternativet Services.msc.

Rekommenderade metoder för masterdatabasen

Eftersom huvuddatabasen lagrar kritiska detaljer om SQL Server-instansen, rekommenderas att du följer de bästa metoderna när du hanterar den databasen.

Varje konfigurationsändring på en instans av SQL Server kommer att lagras i huvuddatabasen. Därför måste du alltid göra en fullständig säkerhetskopia av huvuddatabasen för att återställa till den senaste statusen ifall vi återställer huvuddatabasen från den fullständiga säkerhetskopian, efter behov.

Även om SQL Server tillåter användare att skapa användartabeller eller andra objekt i huvuddatabasen, rekommenderas det inte att göra det. Huvuddatabasen bör förbli enkel och ren. Om du behöver skapa användarobjekt i huvuddatabasen bör du göra fullständiga säkerhetskopior av huvuddatabasen oftare.

SQL-servern stöder alternativet för startprocedurer att exekvera vissa lagrade procedurer vid start av en SQL Server-instans. Den använder sp_procoption procedur. Var försiktig när du använder det här alternativet eftersom en icke-optimal kod eller rekursiv logik kan påverka starttiden för SQL Server-instansen.

Om SQL Server inte kunde starta på grund av problem med huvuddatabasen måste vi återställa huvuddatabasen från den senast kända säkerhetskopian.

Modelldatabas i SQL Server

Som namnet antyder, Modelsystemdatabasen fungerar som en modell eller mall för vilken användardatabas som helst när det gäller filsökväg, initial storlek, inställningar för automatisk tillväxt och återställningsmodellen och andra konfigurationsalternativ .

Alla användarobjekt som tabeller, procedurer etc. som skapas i modelldatabaserna kommer också att skapas automatiskt över nya användardatabaser i den SQL Server-instansen.

Låt oss verifiera detta genom att skapa en ny tabell i modelldatabasen:

Låt oss kontrollera om den här tabellen finns i modelldatabasen:

Modelldatabasen lagrar också standardfilsökvägen för användardatabaser som visas nedan i Databasegenskaper av msdb databas.

Enligt den aktuella konfigurationen, Initial filstorlek av båda Data och Loggfiler är inställd på 8 MB med automatisk tillväxt för dem båda inställda på 64 MB.

Om du behöver skapa en användardatabas i en annan filsökväg istället för modelldatabasens filplats, kan vi ändra den i Serveregenskaper för den SQL Server-instansen.

I SSMS högerklickar du på Server > Egenskaper > Databasinställningar . Visa standardplatserna för databasen:

Ändra filsökvägen till önskad sökväg och klicka på OK . Användardatabasen Data och Logg filer kommer att skapas på den nya sökvägen du angav.

Låt oss skapa en ny databas med namnet model_test och kontrollera den nya databasens data- och loggfilsökvägar tillsammans med filegenskaperna Initial och Autogrowth och model_verify tabell på den nya databasen.

Låt oss verifiera modelltestet Sökvägar till data och loggfiler. Högerklicka på modelltestet databas> Egenskaper > Filer :

Som vi kan se är Data och Logg filer i model_test databaser skapas enligt sökvägen som är tillgänglig i modelldatabasen. Det ursprungliga filstorleksvärdet för data- och loggfilerna är 8 MB. Autogrowth-värdet är 64 MB. Dessa värden matchar konfigurationen av modelldatabasen.

Nu ska vi kontrollera om model_verify tabellen skapas i modelltestet databas. Vi kan se denna nya databas.

Förutom tabeller gäller detta vyer, lagrade procedurer, funktioner och alla objekt som skapats i modelldatabaserna.

Rekommenderade metoder för modelldatabaser

Eftersom modelldatabasen fungerar som en mall för att skapa en ny användardatabas, bör vi implementera nedanstående rutiner när vi hanterar den:

När du vill implementera några ändringar i modellens databaskonfiguration (t.ex. initial filstorlek, autotillväxtstorlek, skapande, modifiering eller radering av användarobjekt), ta en fullständig säkerhetskopia av modelldatabasen omedelbart.

Eftersom alla användarobjekt som skapas i modelldatabaserna skapas på alla användardatabaser, var noga med att bara lägga till nödvändiga objekt. Annars kommer massor av onödiga objekt att skapas på alla användardatabaser, och du kommer att lägga mycket tid på att sortera dem och rensa dina databaser.

Konfigurera parametrarna för initial filstorlek och autotillväxt för data- och loggfilerna. Det hjälper till att hantera data- och loggfilstorlekarna i användardatabaserna bättre och förbättra prestanda.

MSDB-databas

MSDB-systemdatabasen lagrar nedanstående kritiska information i systemtabellerna:

SQL Server Agent-relaterade objekt som jobb, jobbhistorik, varningar, operatörer, proxyservrar, etc.
SQL Server-funktioner som Service Broker och Database Mail med konfigurations- och historikdetaljer.
SQL-serversäkerhetskopiering och återställningsinformation lagras i msdb-databastabellerna.
Konfigurationer för loggfrakt, replikeringsagentprofiler och datainsamlare.
Underhållsplaner, SSIS-paket och en del andra detaljer.

Med andra ord lagrar msdb-systemdatabasen all viktig information relaterad till SQL Server Agent Services och vissa andra relaterade tjänster.

Rekommenderade metoder för msdb-databasen

MSDB-databasen lagrar mycket viktig konfigurationsinformation relaterad till SQL Server-agenter, jobb och databaspost. Den lagrar också historiska detaljer. Därför bör vi implementera nedanstående metoder när vi hanterar msdb-databasen:

I en SQL Server-instans med många databaser eller jobb konfigurerade, kommer storleken på msdb-databasen att öka kontinuerligt under en tid. Därför bör fullständiga säkerhetskopior implementeras för msdb-databaserna dagligen tillsammans med andra användardatabaser. Om msdb tar emot mycket viktig information kan vi ändra återställningsmodellen för msdb-databasen till Full och sedan implementera Backup av transaktionslogg också.

Även om SQL Server tillåter användare att skapa användarobjekt på msdb-databasen, rekommenderas det att inte skapa några användartabeller eller objekt i msdb-databasen och öka storleken på msdb-databasen ytterligare.

Utför regelbunden rengöring av msdb-systemtabeller för att hålla msdb-databasens storlek under kontroll och undvika prestandapåverkan av att ha enorma data över flera tabeller.

Tempdb-databas

tempdb-systemdatabasen kan betraktas som ett globalt arbetsområde tillgängligt för alla användare som är anslutna till SQL Server-instansen för att utföra sina SELECT eller andra operationer .

Tempdb-databasen kommer att innehålla nedanstående objekttyper medan användare utför sina operationer:

Tillfälliga objekt skapade explicit av användare kan vara antingen lokala eller globala temporära tabeller och index, tabellvariabler, tabeller som används i tabellvärderade funktioner och markörer.
Interna objekt skapade av databasmotorn, till exempel:
- Arbetstabeller som används för mellanliggande resultat för spolar, markörer, sorteringar och temporära stora objekt (LOB)
- Arbetsfiler för Hash Join- eller Hash-aggregatoperationer
- Mellanliggande sorteringsresultat vid hantering av att skapa eller bygga om index om SORT_IN_TEMPDB är inställt på PÅ och andra operationer som GROUP BY, ORDER BY eller UNION-frågor
Versionsbutiker som stöder radversionshantering har antingen gemensam versionsbutik eller online-indexversionsbutik.

Närhelst SQL Server-tjänsten startar eller startar om kommer tempdb-databasen att skapas på nytt med hjälp av modelldatabasen. Således är tempdb den enda systemdatabasen som inte kan säkerhetskopieras .

Om vi försöker säkerhetskopiera det får vi felmeddelanden:

Eftersom vi använder tempdb i nästan alla användaroperationer, utgör denna databas en betydande prestandaflaskhals i flera versioner av SQL Server. Från och med SQL Server 2016 fanns det flera optimeringstekniker implementerade av Microsoft – vi kommer att diskutera dem senare.

Innan vi går in på de rekommenderade metoderna för tempdb-databasen, låt oss ta en snabb titt på dess datafiler under standardkonfigurationen som visas nedan:

För min nuvarande SQL Server-instans har vi 4 datafiler och en loggfil för tempdb-databasen.

Från och med SQL Server 2016 har vi SQL Server-installationsprogrammet som låter oss lägga till flera filer till tempdb. Ovanstående 4 filer med en initial storlek på 8 MB och Autogrowth-storlek på 64 MB skapades med standardalternativen som visas nedan.

Om vi har en enda datafil i tempdb-databasen, försöker alla logiska kärnor som är tillgängliga på servern komma åt samma datafil för tempdb, vilket resulterar i en prestandaflaskhals.

Att ha flera datafiler kommer logiskt att associera vissa kärnor till en enda fil. Därför har vi mindre stridigheter om tempdb-datafiler. Detta kommer att förbättra prestandapåverkan på tempdb-datafilerna.

Rekommenderade metoder för tempdb-databasen

Eftersom tempdb-databasen är som ett globalt arbetsområde för alla användaraktiviteter, ökar tempdb-storleken baserat på användaraktiviteterna. Det kan vara en prestandaflaskhals för hela SQL Server-instansen.

Därför bör vi implementera följande metoder:

Placera tempdb-data- och loggfilerna på högpresterande lagring för att få högre IOPS för bättre prestanda.
Se till att tempdb-databasen är uppdelad i flera datafiler för att minska konflikter och undvika prestandaflaskhalsar på tempdb-databasen.
- Om antalet logiska kärnor är mindre än 8 kan vi ha en tempdb-datafil per logisk kärna. I vår testinstans hade vi 4 logiska kärnor. Därför borde 4 datafiler på tempdb vara tillräckligt.
- Om antalet logiska kärnor är fler än 8, börja med 8 datafiler och öka med 4 datafiler om konflikter och prestandaproblem observeras i tempdb-databasen.
- Om antalet logiska kärnor i en server är 32 eller 64, kan vi börja med 8 datafiler. Det betyder att 4 kärnor eller 8 kärnor är logiskt associerade för en enda datafil.
  
  För mer klarhet om flera tempdb-datafiler skulle jag rekommendera dig Paul Randals utmärkta artikel.
Se till att tempdb-datafiler är konfigurerade med optimal initial filstorlek. Helst bör detta uppnås genom ett försök och fel. Tempdb med optimal initial filstorlek tenderar att växa färre gånger jämfört med tempdb konfigurerad med den mindre initiala filstorleken som tenderar att växa flera gånger vilket leder till fragmentering. Till exempel, i den aktuella konfigurationen, är alla filer konfigurerade med en initial filstorlek på 8 MB som är för liten för att hantera SQL Workloads. Använd därför Trial and Error-metoden och ställ in den ursprungliga filstorleken till 512 MB eller 1 GB, eller något annat värde.
Se till att alla tempdb-datafiler är inställda på samma filstorlek. Egenskaper för automatisk tillväxt måste definieras lika. I vårt scenario är alla filer inställda på 64 MB autotillväxt. Att ställa in Autogrowth-storleken till 512 MB eller 1 GB, eller något annat lämpligt värde, hjälper till att minska frekvent autotillväxt på tempdb-datafiler.
Se till att den ursprungliga filstorleken och autotillväxten för tempdb-loggfilen är konfigurerade till ett optimalt värde som liknar tempdb-datafiler. Eftersom återställningsmodellen för tempdb är inställd på Enkel som standard och inte kan ändras, bör det vara tillräckligt att konfigurera den ursprungliga filstorleken och autogrowth-egenskapen för tempdb-loggfilen.

Tempdb är avgörande för SQL Server-instansernas prestanda. Vi kommer att ta en detaljerad titt på de vanliga problemen med tempdb och hur man krymper det optimalt i våra nästa artiklar.

Resursdatabas i SQL Server

Resurssystemdatabasen är den enda skrivskyddade systemdatabasen som inte är listad under systemdatabaser i SSMS som tidigare.

Databas-ID (dbid) av resursdatabaser över alla instanser kommer att vara 32767 vilket också är det maximala antalet databaser som stöds inom en SQL Server-instans. Det kan frågas från sys.sysaltfiles system DMV. Utför SELECT-frågan nedan på sys.sysaltfiles returnerar resultatuppsättningen som visar var resursdatabasens data och loggfiler finns:

Vi kan se fysiska filer av resursdatabasen tillgängliga i ovan nämnda sökväg. Ändringsdatumet anger tidpunkten för installationen av SQL Server-instansen eller senaste gången Service Packs (SP) eller Cumulative Update (CU) tillämpas på denna instans.

Resursdatabasen innehåller alla systemobjekt, såsom sys.objects , sys.databases , sys.sysaltfiles , etc. fysiskt inuti den. Denna databas listar logiskt alla dessa objekt under sys-schemat över alla tillgängliga databaser i instansen . Eftersom resursdatabasen är skrivskyddad kan inga användarobjekt eller data skapas på den.

Resurssystemdatabasen introducerades från och med SQL Server 2005 för att göra SQL Server-uppgraderingen antingen till en ny version av SP eller CU snabbare. Innan det alternativet introducerades innebar alla sådana uppgraderingar och uppdateringar att ändringar skulle gälla i alla databaser, vilket gjorde uppgraderingsprocessen mer komplicerad och tidskrävande. Nu uppgraderar eller ersätter alla SQL Server-versionsuppgraderingar eller SP- eller CU-uppdateringar bara resursdatabasen.

Eftersom resursdatabasen är skrivskyddad och inte är synlig för användare, kräver den inget användaringripande. Om du vill inkludera säkerhetskopieringsresursdatabas i din planering för hög tillgänglighet eller katastrofåterställning, gör du bara en säkerhetskopia av filerna mssqlsystemresource.mdf och mssqlsystemresource.ldf efter att ha stoppat SQL Server Services (SQL Server-tjänsten tillåter inte att kopiera filerna medan SQL Server Service är igång) och spara den på en säker plats. Se till att du inte uppdaterar den på någon instans av SQL Server som körs med en annan version av SP- eller CU-nivåer, eftersom det kan orsaka oväntade problem.

Distributionsdatabas i SQL Server

Distributionssystemdatabasen är hjärtat i replikering. Användare kan skapa eller konfigurera distributionsdatabas som en del av replikeringsinställningen med hjälp av antingen Configure Distribution Wizard eller Create Publication Wizard. Vi beskrev stegen för att skapa distributionsdatabasen i detalj som en del av min tidigare artikel om SQL Server Transactional Replication Internals.

Rekommenderade metoder för distributionsdatabasen

Eftersom distributionsdatabasen är väsentlig för replikeringsfunktionaliteten bör vi implementera följande metoder:

Flytta distributionsdatabasen Data och loggfiler till enheten med bra IOPS för att undvika problem med distributionsprestanda.

Konfigurera egenskaperna för initial filstorlek och autotillväxt för distributionsdatabasen till ett bättre värde för att undvika fragmenteringsproblem.

Inkludera distributionsdatabasen i databasens fullständiga backup-underhållsjobb.

Inkludera distributionsdatabaser i indexunderhållsjobben för att undvika fragmentering och prestandaproblem.

I min artikel om SQL Server Transactional Replication internals hittar du också rekommendationer om andra effektiva metoder.

Slutsats

Tack för att du gick igenom ännu en kraftfull artikel!

Jag hoppas att det hjälpte dig att klargöra essensen och syftena med SQL Server-systemdatabaserna och lära dig de bästa metoderna för att undvika prestandaproblem i dessa databaser.