Manutenzione dei database di sistema di SQL Server

L'installazione di SQL Server per impostazione predefinita crea diversi database di sistema per istanza per mantenere e amministrare tale istanza. In questo articolo esamineremo questi database di sistema e ne comprenderemo le responsabilità.

Database di sistema di SQL Server

In SQL Server, i database di sistema vengono creati durante il processo di installazione per archiviare i dettagli di configurazione specifici dell'istanza di SQL Server per funzionare normalmente. Ogni installazione di SQL Server crea un minimo di 5 database di sistema e 1 database di sistema correlato alla replica denominato database di distribuzione che verrà creato dagli utenti se la replica è configurata in quell'istanza. Ogni database di sistema ha il suo scopo e lo esamineremo in dettaglio più avanti in questo articolo.

I database di sistema sono:

Master – Installato per impostazione predefinita
Msdb – Installato per impostazione predefinita
Modello – Installato per impostazione predefinita
Tempdb – Installato per impostazione predefinita
Risorsa – Installato per impostazione predefinita . Introdotto in SQL Server 2005 e disponibile nelle versioni successive di SQL Server e quindi non disponibile in SQL Server 2000 e versioni precedenti.
Distribuzione – Creato dall'azione dell'utente . Gli utenti possono creare il database di distribuzione per configurare la replica.

Per visualizzare il database di sistema installato in SQL Server, possiamo utilizzare SSMS.

Connettiti alla tua istanza di SQL Server, espandi Database > Database di sistema :

Hai notato che la Risorsa database manca nell'elenco sopra? Il fatto è che il database delle risorse è un database di sistema speciale che non è elencato in SSMS Object Explorer. Tuttavia, possiamo interrogare i dettagli del database delle risorse da un DMV di sistema denominato sys.sysaltfiles ed eseguire la query:

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

Nei risultati, possiamo vedere i database di sistema in ordine:master, tempdb, model, msdb, distribuzione e, infine, il dbid 32767 che è un database di risorse. Tuttavia, questo database di risorse non mostra alcun nome di database poiché non ha una voce in sys.databases . Ho escluso un paio di database utente tra dbid 5 e 11 e ho incluso AdventureWorks_REPL come esempio per mostrare che DMV può visualizzare anche i database degli utenti. Analizzeremo più in dettaglio il database delle risorse e altri database di sistema in seguito.

Restrizioni per i database di sistema SQL

Poiché i database di sistema contengono dettagli di configurazione del sistema critici, dovrebbero essere messe in atto misure di sicurezza adeguate per evitare l'eliminazione accidentale dei dati. Pertanto, i database di sistema hanno le seguenti restrizioni rispetto ai database utente:

Impossibile portare offline i database di sistema

Possiamo portare offline un database utente utilizzando il comando ALTER DATABASE come mostrato di seguito:

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

Tuttavia, se proviamo a portare OFFLINE uno qualsiasi dei database di sistema utilizzando il comando precedente, riceveremo un errore come mostrato di seguito:

I database di sistema non possono essere eliminati

Mentre possiamo eliminare i database degli utenti eseguendo il comando DROP DATABASE

DROP DATABASE AdventureWorks

Se proviamo a eliminare uno qualsiasi dei database di sistema, riceveremo l'errore come mostrato di seguito:

Il proprietario dei database di sistema non può essere modificato

Il proprietario del database di sistema è sa per impostazione predefinita. Non può essere cambiato. I tentativi di rinominare il proprietario del database di sistema provocheranno errori.

Tuttavia, c'è un'eccezione. È possibile modificare il proprietario del msdb banca dati.

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

Il nome del database dei database di sistema non può essere modificato

Se proviamo a rinominare i database di sistema, riceveremo un messaggio di errore come mostrato di seguito:

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

Il confronto dei database di sistema non può essere modificato

I database di sistema vengono creati con il nome di confronto scelto durante l'installazione di SQL Server. Una volta installato, il confronto dei database di sistema non può essere modificato. L'unico modo per modificare le regole di confronto dei database di sistema consiste nel reinstallare l'istanza di SQL Server con le regole di confronto corrette.

Impossibile impostare il filegroup primario dei database di sistema in modalità READ_ONLY

Poiché il database di sistema acquisisce informazioni critiche relative alle istanze di SQL Server, SQL Server non consente di impostare i file di dati primari che risiedono nel filegroup primario come sola lettura .

Non è possibile abilitare la funzione di acquisizione dati di modifica sui database di sistema

Questa funzione viene utilizzata per tenere traccia di ogni modifica DML che si verifica su un database nelle tabelle tracciate. Se proviamo ad abilitare la funzione Modifica acquisizione dati su qualsiasi database di sistema, si verificherà l'errore:

use master
GO
exec sys.sp_cdc_enable_db

Ora che abbiamo chiarito la differenza tra database di sistema e database utente, possiamo esaminare gli scopi di ciascun database di sistema in modo più dettagliato.

Database principale in SQL Server

Il database del sistema principale contiene i dettagli di configurazione chiave relativi all'istanza di SQL Server . SQL Server si basa su di essi quando avvia un'istanza particolare. Se per qualche motivo è impossibile avviare il database master, neanche l'istanza di SQL Server può essere avviata.

Questi dettagli chiave archiviati nel database principale includono gli account di accesso, i dettagli del server collegato, gli endpoint, le impostazioni di configurazione del sistema e i dettagli su tutti i database utente.

Ora arriva la domanda. In che modo il servizio SQL Server sa dove sono disponibili i dati e i file di registro del database master? La risposta sta nei parametri di configurazione di avvio del servizio SQL Server.

Per visualizzare i parametri di configurazione di avvio di un'istanza di SQL Server, è necessario innanzitutto conoscere lo strumento integrato denominato Gestione configurazione di SQL Server . Aiuta a gestire tutti i servizi relativi a SQL Server di tutte le istanze disponibili sul server specifico. Per visualizzare questi dati, apri Gestione configurazione SQL Server e visualizzerà l'elenco come mostrato di seguito:

Fare clic su Servizi SQL Server per visualizzare l'elenco dei Servizi disponibili su questo Server o PC:

Aspetta un secondo! Sembra familiare a services.msc elencando tutti i servizi disponibili nel server ma visualizzando solo i servizi correlati a SQL Server.

Apriamo services.msc per vedere come appare e verificare le differenze tra Gestione configurazione SQL Server e services.msc per confrontare quale è migliore.

Gestione configurazione SQL Server Visualizza l'ID processo dei servizi attualmente in esecuzione. Non siamo riusciti a trovarlo in services.msc . Naturalmente, possiamo ottenere queste informazioni da Task Manager di Windows, ma SQL Server Configuration Manager ci ha aiutato a visualizzarle in un unico posto.

Ora, diamo una visione dettagliata. Fare clic con il pulsante destro del mouse sul servizio SQL Server da services.msc . Vedrai i menu seguenti:Generale , Accedi , Recupero e Dipendenze .

Da Gestione configurazione SQL Server, fare clic con il pulsante destro del mouse su SQL Server(MSSQLSERVER) servizio> Proprietà . Elenca i menu seguenti:Accedi, Servizio. FileStream, Advanced, AlwaysonOnHigh Availability e Parametri di avvio .

I Parametri di avvio del Servizio che archivia la posizione dei dati del database principale e dei file di registro era disponibile solo in SQL Server Configuration Manager .

Fare clic su Parametri di avvio per visualizzare i dettagli – per Esistente Parametri . Vedrai le seguenti informazioni:

La posizione fisica del database principale File di dati
La posizione fisica del database principale File di registro delle transazioni
La posizione fisica della Cartella ErrorLog dove si trovano gli errori relativi al servizio SQL Server.

Possiamo aggiungere più parametri di avvio come Modalità utente singolo (-m) , ecc. Per questo, dobbiamo specificare i valori necessari in Specifica un parametro di avvio e fai clic su Aggiungi .

Abbiamo notato che SQL Server Configuration Manager non mostra solo dettagli avanzati, ma ci consente anche di eseguire molte configurazioni avanzate relative al servizio SQL Server. Pertanto, consiglierei personalmente di utilizzare Gestione configurazione SQL Server per arrestare/avviare i servizi relativi a SQL Server rispetto all'opzione predefinita Services.msc.

Pratiche consigliate per il database principale

Poiché il database master archivia i dettagli critici sull'istanza di SQL Server, si consiglia di seguire le procedure consigliate durante la gestione del database.

Ogni modifica alla configurazione su un'istanza di SQL Server verrà archiviata nel database master. Pertanto, è sempre necessario eseguire un backup completo del database master per ripristinare lo stato più recente nel caso in cui si stia ripristinando il database master dal backup completo, come richiesto.

Anche se SQL Server consente agli utenti di creare tabelle utente o altri oggetti nel database master, non è consigliabile farlo. Il database principale dovrebbe rimanere semplice e pulito. Se devi creare oggetti utente nel database master, dovresti eseguire backup completi del database master con maggiore frequenza.

SQL Server supporta l'Opzione procedura di avvio per eseguire determinate stored procedure all'avvio di un'istanza di SQL Server. Utilizza sp_procoption procedura. Prestare attenzione durante l'utilizzo di questa opzione perché la presenza di un codice non ottimale o di una logica ricorsiva potrebbe influire sul tempo di avvio dell'istanza di SQL Server.

Se non è stato possibile avviare SQL Server a causa di problemi con il database master, è necessario ripristinare il database master dall'ultimo backup valido noto.

Modello di database in SQL Server

Come indica il nome, il database di sistema del modello funge da modello o modello per qualsiasi creazione di database utente in termini di percorso del file, dimensione iniziale, impostazioni di crescita automatica e modello di ripristino e altre opzioni di configurazione .

Tutti gli oggetti utente come tabelle, procedure e così via creati nei database del modello verranno creati automaticamente anche nei nuovi database utente in quell'istanza di SQL Server.

Verifichiamolo creando una nuova tabella nel database del modello:

Verifichiamo se questa tabella è presente nel database del modello:

Il database del modello memorizza anche il percorso file predefinito dei database utente, come mostrato di seguito in Proprietà database del msdb banca dati.

Secondo la configurazione attuale, la dimensione del file iniziale di entrambi i Dati e File di registro è impostato su 8 MB con crescita automatica per entrambi impostato su 64 MB.

Se è necessario creare un database utente in un percorso file diverso anziché nel percorso del file del database modello, è possibile modificarlo in Proprietà server di quell'istanza di SQL Server.

In SSMS, fai clic con il pulsante destro del mouse su Server > Proprietà > Impostazioni database . Visualizza le posizioni predefinite del database:

Modificare il percorso del file nel percorso desiderato e fare clic su OK . Il database degli utenti Dati e Registro i file verranno creati nel nuovo percorso fornito.

Creiamo un nuovo database chiamato model_test e controlla i nuovi percorsi del file Data e Log del database insieme alle proprietà dei file Initial e Autogrowth e model_verify tabella sul nuovo database.

Verifichiamo il model_test Percorsi dei file di dati e di registro. Fare clic con il pulsante destro del mouse su model_test database> Proprietà > File :

Come possiamo vedere, i Dati e Registro file del model_test database vengono creati in base al percorso disponibile nel database del modello. Il valore della dimensione del file iniziale dei file di dati e registro è 8 MB. Il valore della crescita automatica è 64 MB. Questi valori corrispondono alla configurazione del database del modello.

Ora verificheremo se il model_verify la tabella viene creata nel model_test Banca dati. Possiamo vedere questo nuovo database.

Oltre alle tabelle, questo vale per viste, stored procedure, funzioni e qualsiasi oggetto creato nei database del modello.

Pratiche consigliate per il database modello

Poiché il database modello funge da modello per qualsiasi creazione di un nuovo database utente, dovremmo implementare le pratiche seguenti quando lo gestiamo:

Ogni volta che desideri implementare qualsiasi modifica nella configurazione del database del modello (ad es. Dimensione file iniziale, Dimensione dell'aumento automatico, creazione, modifica o eliminazione di oggetti utente), esegui immediatamente un backup completo del database del modello.

Poiché tutti gli oggetti utente creati nei database modello vengono creati su qualsiasi database utente, fare attenzione ad aggiungere solo gli oggetti richiesti. In caso contrario, verranno creati molti oggetti non necessari su tutti i database degli utenti e trascorrerai molto tempo a ordinarli e pulire i tuoi database.

Configura i parametri Dimensione file iniziale e Crescita automatica per i file di dati e di registro. Aiuta a gestire meglio le dimensioni dei file di dati e di registro nei database degli utenti e migliorare le prestazioni.

Database MSDB

Il database di sistema msdb memorizza le seguenti informazioni critiche nelle tabelle di sistema:

Elementi relativi a SQL Server Agent come lavori, cronologie lavori, avvisi, operatori, proxy e così via
Funzionalità di SQL Server come Service Broker e Database Mail con i dettagli di configurazione e cronologia.
I dettagli di backup e ripristino di SQL Server sono archiviati nelle tabelle del database msdb.
Configurazioni di log shipping, profili dell'agente di replica e configurazioni del servizio di raccolta dati.
Piani di manutenzione, pacchetti SSIS e altri dettagli.

In altre parole, il database di sistema msdb archivia tutte le informazioni critiche relative a SQL Server Agent Services e ad altri servizi correlati.

Pratiche consigliate per il database msdb

Il database msdb memorizza molte informazioni di configurazione critiche relative agli agenti, ai processi e alla posta del database di SQL Server. Memorizza anche dettagli storici. Pertanto, dovremmo implementare le pratiche seguenti quando si ha a che fare con il database msdb:

In un'istanza di SQL Server con molti database o processi configurati, la dimensione del database msdb aumenterà continuamente nel corso del tempo. Pertanto, i backup completi dovrebbero essere implementati quotidianamente per i database msdb insieme ad altri database utente. Se msdb riceve molte informazioni critiche, possiamo modificare il modello di ripristino del database msdb su Completo e quindi implementare anche il backup del registro delle transazioni.

Anche se SQL Server consente agli utenti di creare oggetti utente nel database msdb, si consiglia di non creare tabelle o oggetti utente nel database msdb e aumentare ulteriormente le dimensioni del database msdb.

Esegui una pulizia regolare delle tabelle di sistema msdb per tenere sotto controllo le dimensioni del database msdb ed evitare l'impatto sulle prestazioni di avere dati enormi su più tabelle.

Database Tempdb

Il database di sistema tempdb può essere considerato come un'area di lavoro globale disponibile per tutti gli utenti connessi all'istanza di SQL Server per eseguire le proprie operazioni SELECT o altre .

Il database Tempdb conterrà i tipi di oggetto seguenti mentre gli utenti eseguono le loro operazioni:

Gli oggetti temporanei creati in modo esplicito dagli utenti possono essere tabelle e indici temporanei locali o globali, variabili di tabella, tabelle utilizzate nelle funzioni con valori di tabella e cursori.
Oggetti interni creati dal Motore di database, ad esempio:
- Tabelle di lavoro utilizzate per risultati intermedi per spool, cursori, ordinamenti e oggetti temporanei di grandi dimensioni (LOB)
- File di lavoro per operazioni Hash Join o Hash aggregate
- Risultati di ordinamento intermedi durante la creazione o la ricostruzione di indici se SORT_IN_TEMPDB è impostato su ON e altre operazioni come query GROUP BY, ORDER BY o UNION
Negozi di versioni che supportano la funzione di controllo delle versioni di riga sia un archivio di versioni comuni che un archivio di versioni di build di indici online.

Ogni volta che il servizio SQL Server viene avviato o riavviato, il database tempdb verrà creato nuovamente con l'aiuto del database modello. Pertanto, tempdb è l'unico database di sistema di cui non è possibile eseguire il backup .

Se proviamo a eseguirne il backup, riceveremo errori:

Poiché utilizziamo tempdb in quasi tutte le operazioni utente, questo database pone un notevole collo di bottiglia delle prestazioni in diverse versioni di SQL Server. A partire da SQL Server 2016, sono state implementate diverse tecniche di ottimizzazione da parte di Microsoft, di cui parleremo più avanti.

Prima di entrare nelle pratiche consigliate per il database tempdb, diamo una rapida occhiata ai suoi file di dati nella configurazione predefinita come mostrato di seguito:

Per la mia attuale istanza di SQL Server, abbiamo 4 file di dati e un file di registro per il database tempdb.

A partire da SQL Server 2016, abbiamo il programma di installazione di SQL Server che ci consente di aggiungere più file a tempdb. I 4 file precedenti con una dimensione iniziale di 8 MB e una dimensione di crescita automatica di 64 MB sono stati creati utilizzando le opzioni predefinite mostrate di seguito.

Se abbiamo un singolo file di dati nel database tempdb, tutti i core logici disponibili nel server tentano di accedere allo stesso file di dati di tempdb, provocando un collo di bottiglia delle prestazioni.

Avere più file di dati assocerà logicamente determinati core a un singolo file. Pertanto, abbiamo una contesa minore sui file di dati tempdb. Ciò migliorerà l'impatto sulle prestazioni dei file di dati tempdb.

Procedure consigliate per il database tempdb

Poiché il database tempdb è come un'area di lavoro globale per tutte le attività dell'utente, la dimensione del tempdb aumenta in base alle attività dell'utente. Può essere un collo di bottiglia delle prestazioni per l'intera istanza di SQL Server.

Quindi, dovremmo implementare le seguenti pratiche:

Posiziona i file di registro e dati tempdb in uno storage ad alte prestazioni per ottenere IOPS più elevati e prestazioni migliori.
Assicurarsi che il database tempdb sia suddiviso in più file di dati per ridurre i conflitti ed evitare colli di bottiglia delle prestazioni nel database tempdb.
- Se il numero di core logici è inferiore a 8, possiamo avere un file di dati tempdb per core logico. Nella nostra istanza di test, avevamo 4 core logici. Quindi, 4 file di dati su tempdb dovrebbero essere sufficienti.
- Se il numero di core logici è superiore a 8, iniziare con 8 file di dati e aumentare di 4 file di dati se si osservano conflitti e problemi di prestazioni nel database tempdb.
- Se il numero di core logici in un server è 32 o 64, possiamo iniziare con 8 file di dati. Significa che 4 core o 8 core sono associati logicamente per un singolo file di dati.
  
  Per maggiore chiarezza su più file di dati tempdb, ti consiglio l'eccellente articolo di Paul Randal.
Assicurarsi che i file di dati tempdb siano configurati con una dimensione del file iniziale ottimale. Idealmente, ciò dovrebbe essere ottenuto tramite un approccio per tentativi ed errori. Tempdb con la dimensione del file iniziale ottimale tende a crescere meno volte rispetto a tempdb configurato con la dimensione del file iniziale inferiore che tende a crescere più volte causando la frammentazione. Ad esempio, nella configurazione corrente, tutti i file sono configurati con una dimensione del file iniziale di 8 MB che è troppo piccola per gestire i carichi di lavoro SQL. Pertanto, applica l'approccio di prova ed errore e imposta la dimensione del file iniziale su 512 MB o 1 GB o un altro valore.
Assicurati che tutti i file di dati tempdb siano impostati sulla stessa dimensione del file. Le proprietà di autocrescita devono essere definite allo stesso modo. Nel nostro scenario, tutti i file sono impostati su 64 MB di crescita automatica. L'impostazione della dimensione della crescita automatica su 512 MB o 1 GB o qualsiasi altro valore appropriato aiuta a ridurre la crescita automatica frequente sui file di dati tempdb.
Assicurarsi che la dimensione del file iniziale e la crescita automatica per il file di registro tempdb siano configurati su un valore ottimale simile ai file di dati tempdb. Poiché il modello di ripristino di tempdb è impostato su Semplice per impostazione predefinita e non può essere modificato, la configurazione della dimensione del file iniziale e della proprietà di crescita automatica del file di registro tempdb dovrebbe essere sufficiente.

Tempdb è fondamentale per le prestazioni dell'istanza di SQL Server. Daremo uno sguardo dettagliato ai problemi frequenti affrontati su tempdb e come ridurlo in modo ottimale nei nostri prossimi articoli.

Database delle risorse in SQL Server

Il database del sistema di risorse è l'unico database di sistema di sola lettura che non è elencato nei database di sistema in SSMS come visto in precedenza.

L'ID database (dbid) di database di risorse in tutte le istanze sarà 32767, che è anche il numero massimo di database supportati all'interno di un'istanza di SQL Server. Può essere interrogato da sys.sysaltfiles sistema DMV. Esecuzione della query SELECT di seguito su sys.sysaltfiles restituirà il insieme di risultati mostrando dove si trovano i file di dati e di registro del database delle risorse:

Possiamo vedere i file fisici del database delle risorse disponibili nel percorso sopra menzionato. La data di modifica indica l'ora dell'installazione dell'istanza di SQL Server o l'ultima volta che i Service Pack (SP) o l'aggiornamento cumulativo (CU) sono stati applicati a questa istanza.

Il database delle risorse contiene tutti gli oggetti di sistema, come sys.objects , sys.database , sys.sysaltfiles , ecc. fisicamente al suo interno. Questo database elenca logicamente tutti questi oggetti sotto lo schema sys in tutti i database disponibili nell'istanza . Poiché il database delle risorse è di sola lettura, non è possibile creare oggetti o dati utente su di esso.

Il database del sistema di risorse è stato introdotto a partire da SQL Server 2005 per rendere più veloce l'aggiornamento di SQL Server a una nuova versione di SP o CU. Prima di introdurre tale opzione, tutti questi aggiornamenti e aggiornamenti significavano che le modifiche si applicavano a tutti i database, rendendo il processo di aggiornamento più complicato e dispendioso in termini di tempo. Ora, qualsiasi aggiornamento della versione di SQL Server o aggiornamento SP o CU aggiorna o sostituisce semplicemente il database delle risorse.

Poiché il database delle risorse è di sola lettura e non è visibile agli utenti, non richiede alcun intervento da parte dell'utente. Se desideri includere il backup del database delle risorse nella pianificazione della disponibilità elevata o del ripristino di emergenza, è sufficiente eseguire un backup dei file mssqlsystemresource.mdf e mssqlsystemresource.ldf dopo aver interrotto i servizi SQL Server (il servizio SQL Server non consentirà di copiare i file mentre SQL Server Service è attivo e in esecuzione) e salvalo in un luogo sicuro. Prestare doppia attenzione a non aggiornarlo su nessuna istanza di SQL Server in esecuzione con una versione diversa di livelli SP o CU, poiché potrebbe causare problemi imprevisti.

Database di distribuzione in SQL Server

Il database del sistema di distribuzione è il cuore di Replica. Gli utenti possono creare o configurare il database di distribuzione come parte dell'impostazione della replica con l'aiuto di Configurazione guidata distribuzione o Creazione guidata pubblicazione. Abbiamo descritto in dettaglio i passaggi per la creazione del database di distribuzione come parte del mio precedente articolo sugli interni della replica transazionale di SQL Server.

Pratiche consigliate per il database di distribuzione

Poiché il database di distribuzione è essenziale per la funzionalità di replica, è necessario implementare le seguenti pratiche:

Sposta il database di distribuzione e i file di registro sull'unità con un buon IOPS per evitare problemi di prestazioni di distribuzione.

Configura le proprietà Dimensione file iniziale e Crescita automatica del database di distribuzione su un valore migliore per evitare problemi di frammentazione.

Includi il database di distribuzione nei processi di manutenzione del backup completo del database.

Includi i database di distribuzione nei lavori di manutenzione dell'indice per evitare problemi di frammentazione e prestazioni.

Nel mio articolo sugli interni della replica transazionale di SQL Server, troverai anche consigli su altre pratiche efficienti.

Conclusione

Grazie per aver letto un altro articolo ricco di energia!

Spero che ti abbia aiutato a chiarire l'essenza e gli scopi dei database di sistema di SQL Server e ad apprendere le best practice per evitare problemi di prestazioni su questi database.