SQL Server System Database Vedligeholdelse

SQL Server-installation opretter som standard flere systemdatabaser pr. instans for at vedligeholde og administrere den instans. I denne artikel vil vi undersøge disse systemdatabaser og forstå deres ansvar.

SQL-serversystemdatabaser

I SQL Server oprettes systemdatabaser under installationsprocessen for at gemme de SQL Server-instansspecifikke konfigurationsdetaljer, så de fungerer normalt. Hver installation af SQL Server opretter minimum 5 systemdatabaser og 1 replikeringsrelateret systemdatabase ved navn distributionsdatabase som vil blive oprettet af brugere, hvis replikering er konfigureret i det pågældende tilfælde. Hver systemdatabase har sit formål, og vi vil undersøge dette i detaljer senere i denne artikel.

Systemdatabaserne er:

Master – Installeret som standard
Msdb – Installeret som standard
Model – Installeret som standard
Tempdb – Installeret som standard
Ressource – Installeret som standard . Introduceret i SQL Server 2005 og tilgængelig i senere SQL Server-versioner og derfor ikke tilgængelig i SQL Server 2000 og tidligere versioner.
Distribution – Oprettet af brugerhandling . Brugere kan oprette distributionsdatabasen for at konfigurere replikering.

For at se systemdatabasen installeret i SQL Server, kan vi bruge SSMS.

Opret forbindelse til din SQL Server-instans, udvid Databaser > Systemdatabaser :

Har du bemærket, at ressourcen mangler databasen på ovenstående liste? Sagen er, at ressourcedatabasen er en speciel systemdatabase, der ikke er opført i SSMS Object Explorer. Vi kan dog forespørge om ressourcedatabasedetaljerne fra et system DMV ved navn sys.sysaltfiles og udfør forespørgslen:

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

I resultaterne kan vi se systemdatabaserne i rækkefølge:master, tempdb, model, msdb, distribution , og endelig dbid 32767 som er en ressourcedatabase. Denne ressourcedatabase viser dog ikke noget databasenavn, da den ikke har en post i sys.databases . Jeg har udelukket et par brugerdatabaser mellem dbid 5 og 11 og inkluderet AdventureWorks_REPL som et eksempel for at vise, at DMV også kan vise brugerdatabaser. Vi vil gå mere i detaljer om ressourcedatabasen og andre systemdatabaser senere.

SQL-systemdatabaserestriktioner

Da systemdatabaser indeholder kritiske systemkonfigurationsdetaljer, bør der være passende sikkerhedsforanstaltninger på plads for at undgå utilsigtet sletning af data. Derfor har systemdatabaser nedenstående begrænsninger sammenlignet med brugerdatabaser:

Systemdatabaser kan ikke tages offline

Vi kan tage en brugerdatabase offline ved at bruge kommandoen ALTER DATABASE som vist nedenfor:

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

Men hvis vi forsøger at tage nogen af systemdatabaserne OFFLINE ved hjælp af ovenstående kommando, vil vi modtage en fejl som vist nedenfor:

Systemdatabaser kan ikke slettes

Mens vi kan droppe brugerdatabaserne ved at udføre kommandoen DROP DATABASE

DROP DATABASE AdventureWorks

Hvis vi forsøger at SLIPPE nogen af systemdatabaserne, vil vi modtage fejlen som vist nedenfor:

Ejer af systemdatabaser kan ikke ændres

Ejeren af systemdatabasen er sa som standard. Det kan ikke ændres. Forsøg på at omdøbe systemdatabaseejeren vil fremprovokere fejl.

Der er dog en undtagelse. Det er muligt at ændre ejeren af msdb database.

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

Databasenavn på systemdatabaser kan ikke ændres

Hvis vi forsøger at omdøbe systemdatabaserne, får vi en fejlmeddelelse som vist nedenfor:

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

Sammenstilling af systemdatabaser kan ikke ændres

Systemdatabaser oprettes med det sorteringsnavn, der er valgt under installationen af SQL Server. Når først det er installeret, kan samlingen af systemdatabaser ikke ændres. Den eneste måde at ændre systemdatabasesorteringen på er at geninstallere SQL Server-forekomsten med den korrekte sortering.

Primær filgruppe af systemdatabaser kan ikke indstilles til READ_ONLY-tilstand

Da systemdatabasen fanger kritiske oplysninger relateret til SQL Server-instanser, tillader SQL Server ikke, at de primære datafiler, der findes i den primære filgruppe, sættes som skrivebeskyttet .

Skift datafangstfunktion kan ikke aktiveres på systemdatabaser

Denne funktion bruges til at spore hver DML-ændring, der sker på en database på de sporede tabeller. Hvis vi forsøger at aktivere funktionen Change Data Capture på nogen systemdatabaser, vil fejlen finde sted:

use master
GO
exec sys.sp_cdc_enable_db

Nu hvor vi er klar over forskellen mellem systemdatabaser og brugerdatabaser, kan vi undersøge formålene med hver systemdatabase mere detaljeret.

Masterdatabase i SQL Server

Hovedsystemdatabasen indeholder nøglekonfigurationsdetaljer relateret til SQL Server-forekomsten . SQL Server er afhængig af dem, når den starter en bestemt instans. Hvis det af en eller anden grund er umuligt at starte masterdatabasen, kan SQL Server-instansen heller ikke starte.

Disse nøgledetaljer, der er gemt i masterdatabasen, inkluderer login-konti, linkede serverdetaljer, slutpunkter, systemkonfigurationsindstillinger og detaljer om alle brugerdatabaser.

Nu kommer spørgsmålet. Hvordan ved SQL Server-tjenesten, hvor data og logfiler i masterdatabasen er tilgængelige? Svaret ligger i opstartskonfigurationsparametrene for SQL Server-tjenesten.

For at se opstartskonfigurationsparametrene for en SQL Server-instans skal vi først kende til det indbyggede værktøj kaldet SQL Server Configuration Manager . Det hjælper med at administrere alle SQL Server-relaterede tjenester af alle instanser, der er tilgængelige på den bestemte server. For at se disse data skal du åbne SQL Server Configuration Manager, og den vil vise listen som vist nedenfor:

Klik på SQL Server Services for at se listen over tilgængelige tjenester på denne server eller pc:

Vent et øjeblik! Det ser bekendt ud for services.msc viser alle tjenester, der er tilgængelige på serveren, men viser kun SQL Server-relaterede tjenester.

Lad os åbne services.msc for at se, hvordan det ser ud og kontrollere forskellene på tværs af SQL Server Configuration Manager og services.msc at sammenligne, hvilken der er bedst.

SQL Server Configuration Manager viser proces-id'et for de tjenester, der kører i øjeblikket. Vi kunne ikke finde det i services.msc . Selvfølgelig kan vi få disse oplysninger fra Windows Task Manager, men SQL Server Configuration Manager hjalp os med at se dette et enkelt sted.

Lad os nu tage en detaljeret visning. Højreklik på SQL Server-tjenesten fra services.msc . Du vil se nedenstående menuer:Generelt , Log på , Gendannelse , og afhængigheder .

Fra SQL Server Configuration Manager skal du højreklikke på SQL Server(MSSQLSERVER) service> Egenskaber . Den viser nedenstående menuer – Log på, service. FileStream, Advanced, Alwayson OnHigh Availability og Opstartsparametre .

Opstartsparametrene af tjenesten, som gemmer placeringen af masterdatabasedata og logfiler var kun tilgængelig i SQL Server Configuration Manager .

Klik på Opstartsparametre for at se detaljerne – for Eksisterende Parametre . Du vil se følgende information:

Den fysiske placering af masterdatabasen Datafil
Den fysiske placering af masterdatabasen Transaktionslogfil
Den fysiske placering af ErrorLog-mappen hvor fejl relateret til SQL Server Service er placeret.

Vi kan tilføje flere opstartsparametre som Enkeltbrugertilstand (-m) osv. Til det skal vi angive de nødvendige værdier i Angiv en opstartsparameter og klik på Tilføj .

Vi har bemærket, at SQL Server Configuration Manager ikke kun viser avancerede detaljer, men også giver os mulighed for at lave en masse avancerede konfigurationer relateret til SQL Server-service. Derfor vil jeg personligt anbefale at bruge SQL Server Configuration Manager til at stoppe/starte SQL Server-relaterede tjenester sammenlignet med standardindstillingen Services.msc.

Anbefalet praksis for masterdatabase

Da masterdatabasen gemmer kritiske detaljer om SQL Server-forekomsten, anbefales det at følge den bedste praksis under håndtering af databasen.

Hver konfigurationsændring på en forekomst af SQL Server vil blive gemt i masterdatabasen. Du skal derfor altid lave en fuld sikkerhedskopi af masterdatabasen for at gendanne til den seneste status i tilfælde af, at vi gendanner masterdatabasen fra den fulde backup efter behov.

Selvom SQL Server tillader brugere at oprette brugertabeller eller andre objekter i masterdatabasen, anbefales det ikke at gøre det. Masterdatabasen skal forblive enkel og ren. Hvis du har brug for at oprette brugerobjekter i masterdatabasen, bør du lave fuld sikkerhedskopiering af masterdatabasen oftere.

SQL-serveren understøtter Opstartsprocedureindstillingen at udføre visse Stored Procedures ved start af en SQL Server-instans. Den bruger sp_procoption procedure. Vær forsigtig, mens du bruger denne mulighed, fordi det kan påvirke opstartstiden for SQL Server-instansen at have en ikke-optimal kode eller rekursiv logik.

Hvis SQL Server ikke kunne starte på grund af problemer med masterdatabasen, skal vi gendanne masterdatabasen fra den sidst kendte gode backup.

Modeldatabase i SQL Server

Som navnet indikerer, er Modelsystemdatabasen fungerer som en model eller skabelon for enhver oprettelse af brugerdatabaser med hensyn til filstien, den oprindelige størrelse, indstillinger for automatisk vækst og gendannelsesmodellen og andre konfigurationsmuligheder .

Alle brugerobjekter som tabeller, procedurer osv., der oprettes i modeldatabaserne, vil også blive oprettet automatisk på tværs af nye brugerdatabaser i den SQL Server-instans.

Lad os bekræfte dette ved at lave en ny tabel i modeldatabasen:

Lad os kontrollere, om denne tabel er til stede i modeldatabasen:

Modeldatabasen gemmer også standardfilstien for brugerdatabaser som vist nedenfor i Databaseegenskaber af msdb database.

I henhold til den aktuelle konfiguration, Oprindelig filstørrelse af begge Data og Logfiler er indstillet til 8 MB med automatisk vækst for dem begge sat til 64 MB.

Hvis du har brug for at oprette en brugerdatabase i en anden filsti i stedet for modeldatabasens filplacering, kan vi ændre den i Serveregenskaber af den SQL Server-instans.

I SSMS skal du højreklikke på Server > Egenskaber > Databaseindstillinger . Se databasens standardplaceringer:

Skift filstien til den ønskede sti, og klik på OK . Brugerdatabasen Data og Log filer vil blive oprettet i den nye sti, du har angivet.

Lad os oprette en ny database med navnet model_test og kontroller den nye database Data- og Logfilstier sammen med Initial- og Autogrowth-filegenskaberne og model_verify tabel på den nye database.

Lad os bekræfte model_testen Data- og logfilstier. Højreklik på model_testen database> Egenskaber > Filer :

Som vi kan se, er Data og Log filer af model_test databasen oprettes i henhold til stien, der er tilgængelig i modeldatabasen. Den oprindelige filstørrelsesværdi for data- og logfilerne er 8 MB. Autogrowth-værdien er 64 MB. Disse værdier matcher konfigurationen af modeldatabasen.

Nu vil vi kontrollere, om model_verify tabellen oprettes i model_testen database. Vi kan se denne nye database.

Udover tabeller gælder dette for visninger, lagrede procedurer, funktioner og alle objekter, der er oprettet i modeldatabaserne.

Anbefalet praksis for modeldatabase

Da modeldatabasen fungerer som en skabelon for enhver ny brugerdatabaseoprettelse, bør vi implementere nedenstående praksis, når vi håndterer den:

Når du ønsker at implementere ændringer i modeldatabasekonfigurationen (f.eks. initial filstørrelse, autovækststørrelse, oprettelse, ændring eller sletning af brugerobjekter), skal du tage en fuld sikkerhedskopi af modeldatabasen med det samme.

Da alle brugerobjekter, der er oprettet i modeldatabaserne, er oprettet på alle brugerdatabaser, skal du sørge for kun at tilføje nødvendige objekter. Ellers vil der blive oprettet masser af unødvendige objekter på alle brugerdatabaser, og du vil bruge meget tid på at sortere dem og rense dine databaser.

Konfigurer parametrene for den oprindelige filstørrelse og autovækst for data- og logfilerne. Det hjælper med at administrere data- og logfilstørrelserne i brugerdatabaserne bedre og forbedre ydeevnen.

MSDB-database

MSDB-systemdatabasen gemmer nedenstående kritiske oplysninger på tværs af systemtabellerne:

SQL Server Agent-relaterede emner som job, jobhistorik, advarsler, operatører, proxyer osv.
SQL Server-funktioner som Service Broker og Database Mail med konfigurations- og historikdetaljerne.
SQL Server Backup og Restore detaljer gemmes inde i msdb-databasetabellerne.
Logforsendelseskonfigurationer, replikeringsagentprofiler og dataindsamlerkonfigurationer.
Vedligeholdelsesplaner, SSIS-pakker og nogle andre detaljer.

Med andre ord gemmer msdb-systemdatabasen al kritisk information relateret til SQL Server Agent Services og nogle andre relaterede tjenester.

Anbefalet praksis for msdb-database

MSDB-databasen gemmer en masse kritiske konfigurationsoplysninger relateret til SQL Server Agents, Jobs og Database Mail. Det gemmer også historiske detaljer. Derfor bør vi implementere nedenstående praksis, når vi håndterer msdb-databasen:

I en SQL Server-instans med mange databaser eller job konfigureret ud, vil størrelsen af msdb-databasen stige kontinuerligt over nogen tid. Derfor bør fuld sikkerhedskopiering implementeres for msdb-databaserne dagligt sammen med andre brugerdatabaser. Hvis msdb modtager en masse kritisk information, så kan vi ændre gendannelsesmodellen for msdb-databasen til Fuld og derefter også implementere Transaction Log Backup.

Selvom SQL Server tillader brugere at oprette brugerobjekter på msdb-databasen, anbefales det ikke at oprette nogen brugertabeller eller -objekter i msdb-databasen og øge størrelsen af msdb-databasen yderligere.

Udfør regelmæssig oprydning af msdb-systemtabeller for at holde msdb-databasestørrelsen under kontrol og undgå ydeevnepåvirkningerne ved at have enorme data på tværs af flere tabeller.

Tempdb-database

tempdb-systemdatabasen kan betragtes som et globalt arbejdsområde, der er tilgængeligt for alle brugere, der er tilsluttet SQL Server-instansen for at udføre deres SELECT eller andre operationer .

Tempdb-databasen vil indeholde nedenstående objekttyper, mens brugerne udfører deres handlinger:

Midlertidige objekter, der er oprettet eksplicit af brugere, kan enten være lokale eller globale midlertidige tabeller og indekser, tabelvariabler, tabeller brugt i tabelværdierede funktioner og markører.
Interne objekter oprettet af databasemotoren, såsom:
- Arbejdstabeller, der bruges til mellemresultater for spoler, markører, sorteringer og midlertidige store objekter (LOB)
- Arbejdsfiler til Hash Join- eller Hash-aggregatoperationer
- Mellem sorteringsresultater under håndtering af oprettelse eller genopbygning af indekser, hvis SORT_IN_TEMPDB er indstillet til TIL og andre operationer såsom GROUP BY, ORDER BY eller UNION-forespørgsler
Versionsbutikker, der understøtter Row-versionering, har enten almindelig versionsbutik eller online indeksversionsbutik.

Hver gang SQL Server-tjenesten starter eller genstarter, vil tempdb-databasen blive oprettet på ny ved hjælp af modeldatabasen. Således er tempdb den eneste systemdatabase, der ikke kan sikkerhedskopieres .

Hvis vi forsøger at tage backup af det, vil vi modtage fejl:

Da vi bruger tempdb i næsten alle brugeroperationer, udgør denne database en betydelig ydeevneflaskehals på tværs af flere versioner af SQL Server. Fra SQL Server 2016 var der adskillige optimeringsteknikker implementeret af Microsoft – vi vil diskutere dem senere.

Inden vi går ind i den anbefalede praksis for tempdb-databasen, lad os tage et hurtigt kig på dens datafiler under standardkonfigurationen som vist nedenfor:

For min nuværende SQL Server-instans har vi 4 datafiler og en logfil til tempdb-databasen.

Fra SQL Server 2016 har vi SQL Server-installationsprogrammet, der giver os mulighed for at tilføje flere filer til tempdb. Ovenstående 4 filer med en startstørrelse på 8 MB og Autogrowth-størrelse på 64 MB blev oprettet ved hjælp af standardindstillingerne vist nedenfor.

Hvis vi har en enkelt datafil i tempdb-databasen, forsøger alle logiske kerner på serveren at få adgang til den samme datafil af tempdb, hvilket resulterer i en flaskehals i ydeevnen.

At have flere datafiler vil logisk knytte visse kerner til en enkelt fil. Således har vi mindre strid om tempdb-datafiler. Dette vil forbedre ydeevnepåvirkningen på tempdb-datafilerne.

Anbefalet praksis for tempdb-databasen

Da tempdb-databasen er som et globalt arbejdsområde for alle brugeraktiviteter, øges tempdb-størrelsen baseret på brugeraktiviteterne. Det kan være en flaskehals i ydeevnen for hele SQL Server-instansen.

Derfor bør vi implementere følgende praksis:

Placer tempdb-data- og logfilerne på højtydende lagring for at få højere IOPS for bedre ydeevne.
Sørg for, at tempdb-databasen er opdelt i flere datafiler for at reducere stridigheder og undgå ydeevneflaskehalse på tempdb-databasen.
- Hvis antallet af logiske kerner er mindre end 8, kan vi have én tempdb-datafil pr. logisk kerne. I vores testforekomst havde vi 4 logiske kerner. Derfor burde 4 datafiler på tempdb være tilstrækkeligt.
- Hvis antallet af logiske kerner er mere end 8, skal du starte med 8 datafiler og øge med 4 datafiler, hvis der observeres problemer med strid og ydeevne på tempdb-databasen.
- Hvis antallet af logiske kerner i en server er 32 eller 64, kan vi starte med 8 datafiler. Det betyder, at 4 kerner eller 8 kerner er forbundet logisk for en enkelt datafil.
  
  For mere klarhed om flere tempdb-datafiler vil jeg anbefale dig Paul Randals fremragende artikel.
Sørg for, at tempdb-datafiler er konfigureret med optimal initial filstørrelse. Ideelt set bør dette opnås via en trial and error tilgang. Tempdb med optimal initial filstørrelse har en tendens til at vokse færre gange sammenlignet med tempdb konfigureret med den mindre oprindelige filstørrelse, som har tendens til at vokse flere gange, hvilket fører til fragmentering. For eksempel, i den aktuelle konfiguration er alle filer konfigureret med en initial filstørrelse på 8 MB, som er for lille til at håndtere SQL Workloads. Anvend derfor Trial and Error-metoden og indstil den oprindelige filstørrelse til 512 MB eller 1 GB eller en anden værdi.
Sørg for, at alle tempdb-datafiler er indstillet til samme filstørrelse. Auto-vækst egenskaber skal defineres ens. I vores scenarie er alle filer sat til 64 MB autogrowth. Indstilling af Autogrowth-størrelsen til 512 MB eller 1 GB eller enhver anden passende værdi hjælper med at reducere hyppig autovækst på tempdb-datafiler.
Sørg for, at den oprindelige filstørrelse og autovækst for tempdb-logfilen er konfigureret til en optimal værdi svarende til tempdb-datafiler. Da gendannelsesmodellen for tempdb er indstillet til Simple som standard og ikke kan ændres, burde det være tilstrækkeligt at konfigurere den oprindelige filstørrelse og autogrowth-egenskaben for tempdb-logfilen.

Tempdb er afgørende for SQL Server-instansens ydeevne. Vi tager et detaljeret kig på de hyppige problemer, som tempdb støder på, og hvordan man formindsker det optimalt i vores næste artikler.

Ressourcedatabase i SQL Server

Resource System-databasen er den eneste skrivebeskyttede systemdatabase, der ikke er opført under systemdatabaser i SSMS som tidligere set.

Database-id'et (dbid) af ressourcedatabaser på tværs af alle instanser vil være 32767, hvilket også er det maksimale antal databaser, der understøttes i en SQL Server-instans. Det kan forespørges fra sys.sysaltfiles system DMV. Udførelse af nedenstående SELECT-forespørgsel på sys.sysaltfiles returnerer resultatsættet viser, hvor data- og logfilerne i ressourcedatabasen er placeret:

Vi kan se fysiske filer af ressourcedatabasen tilgængelige i den ovennævnte sti. Ændringsdatoen angiver tidspunktet for installationen af SQL Server-instansen eller sidste gang Service Packs (SP) eller Cumulative Update (CU) anvendes på denne instans.

Ressourcedatabasen indeholder alle systemobjekter, såsom sys.objects , sys.databases , sys.sysaltfiles osv. fysisk inde i det. Denne database viser logisk alle disse objekter under sys-skemaet på tværs af alle tilgængelige databaser i instansen . Da ressourcedatabasen er skrivebeskyttet, kan der ikke oprettes brugerobjekter eller data på den.

Ressourcesystemdatabasen blev introduceret fra SQL Server 2005 for at gøre SQL Server-opgraderingen enten til en ny version af SP eller CU hurtigere. Før denne mulighed blev introduceret, betød alle sådanne opgraderinger og opdateringer, at ændringer ville gælde på tværs af alle databaser, hvilket gjorde opgraderingsprocessen mere kompliceret og tidskrævende. Nu opgraderer eller erstatter enhver SQL Server-versionsopgradering eller SP- eller CU-opdatering blot ressourcedatabasen.

Da ressourcedatabasen er skrivebeskyttet og ikke synlig for brugerne, kræver den ingen brugerindgriben. Hvis du ønsker at inkludere backup ressourcedatabase i din High Availability- eller Disaster Recovery-planlægning, skal du blot lave en sikkerhedskopi af filerne mssqlsystemresource.mdf og mssqlsystemresource.ldf efter at have stoppet SQL Server Services (SQL Server-tjenesten tillader ikke at kopiere filerne, mens SQL Server Service er oppe og køre), og gem den på et sikkert sted. Vær dobbelt omhyggelig med ikke at opdatere den på nogen forekomst af SQL Server, der kører med en anden version af SP- eller CU-niveauer, da det kan forårsage uventede problemer.

Distributionsdatabase i SQL Server

Distributionssystemdatabasen er hjertet i replikering. Brugere kan oprette eller konfigurere distributionsdatabase som en del af replikeringsopsætningen ved hjælp af enten Konfigurer distributionsguide eller Opret udgivelsesguide. Vi beskrev trinene til oprettelse af distributionsdatabasen i detaljer som en del af min tidligere artikel om SQL Server Transactional Replication Internals.

Anbefalet praksis for distributionsdatabasen

Da distributionsdatabasen er afgørende for replikeringsfunktionaliteten, bør vi implementere følgende praksis:

Flyt distributionsdatabasen Data og logfiler til drevet med god IOPS for at undgå problemer med distributionens ydeevne.

Konfigurer egenskaberne for initial filstørrelse og autovækst for distributionsdatabasen til en bedre værdi for at undgå fragmenteringsproblemer.

Inkluder distributionsdatabase til vedligeholdelsesjob for fuld backup af databasen.

Inkluder distributionsdatabaser til indeksvedligeholdelsesjob for at undgå fragmentering og ydeevneproblemer.

I min artikel om SQL Server Transactional Replication internals finder du også anbefalinger om anden effektiv praksis.

Konklusion

Tak, fordi du gik igennem endnu en kraftfuld artikel!

Jeg håber, det hjalp dig med at afklare essensen og formålene med SQL Server-systemdatabaserne og lære den bedste praksis for at undgå ydeevneproblemer på disse databaser.