MSDB è un database di sistema utilizzato da SQL Server. MSDB archivia tutti i tipi di dati, come la cronologia di backup e ripristino, la cronologia dei processi di SQL Agent, la cronologia del monitoraggio della spedizione dei registri, i pacchetti SSIS, i dati di Ottimizzazione guidata motore di database e i dati delle code di Service Broker. Proprio come i database utente, msdb necessita di una manutenzione regolare, comprese le ottimizzazioni degli indici e, soprattutto, l'eliminazione regolare.
Cronologia backup e ripristino
Per impostazione predefinita, non esiste un metodo per eliminare o eliminare il backup e ripristinare la cronologia da msdb. Viene conservato per sempre fino a quando non si imposta un processo manuale o automatizzato per eliminare i dati. Non eliminando questi dati, msdb continuerà a crescere, il che significa che la lettura e la scrittura su quelle tabelle possono diventare più lente e influire sulla velocità dei processi di backup.
La maggior parte degli strumenti di terze parti e delle soluzioni di manutenzione affidabili includono processi per cancellare la cronologia di backup e ripristino per evitare che questo diventi un problema. Un modo semplice per sapere se stai eliminando la cronologia dei backup o meno è interrogare direttamente msdb:
SELECT CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server,
msdb.dbo.backupset.database_name,
msdb.dbo.backupset.backup_finish_date,
CASE msdb..backupset.type
WHEN 'D' THEN 'Database'
WHEN 'L' THEN 'Log'
END AS backup_type
FROM msdb.dbo.backupmediafamily
INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id
ORDER BY msdb.dbo.backupset.backup_finish_date; Se disponi di una cronologia di backup o ripristino che risale a più di 90 giorni fa, dovresti verificare se esiste un requisito normativo che impone di conservare le informazioni storiche su tali backup per un periodo specifico. Se non c'è un requisito, dovresti prendere in considerazione l'eliminazione dei dati più vecchi di un certo periodo di tempo. La cronologia di backup non è necessaria per ripristinare i database e consigliamo di eliminarla regolarmente per mantenere msdb a dimensioni ragionevoli. Mantenere 90 giorni o meno è l'intervallo che in genere consiglio ai clienti.
Per impostare un processo per eliminare il backup e ripristinare la cronologia, crea un processo che esegua sp_delete_backuphistory stored procedure in msdb e passargli un parametro date. La procedura memorizzata eliminerà tutti i backup e la cronologia di ripristino precedenti alla data fornita. È inoltre possibile creare un piano di manutenzione del database e utilizzare l'attività di pulizia della cronologia.
Consulente per l'ottimizzazione del motore di database
Ottimizzazione guidata motore di database, noto anche come DTA, è uno strumento che gli sviluppatori e gli amministratori di database possono utilizzare per ottimizzare un database. DTA sfrutta il database msdb per archiviare la cronologia di ottimizzazione e altri oggetti di supporto.
Trovo regolarmente resti di DTA in msdb sui server di produzione dei clienti. Quando trovo queste tabelle, le interrogo direttamente per determinare se DTA è ancora in uso. Fortunatamente, devo ancora trovare un client che esegua attivamente DTA rispetto alla produzione, poiché può influire in modo significativo sulle prestazioni. Una volta che confermo e comunico con il client, elimino le tabelle DTA da msdb. In alcuni casi questo libera più gigabyte di spazio. Per precauzione, mi prendo anche il tempo per spiegare l'impatto sulle prestazioni che l'esecuzione di DTA contro la produzione può causare e incoraggiare i miei clienti a fare qualsiasi uso futuro su un server di sviluppo.
Agente SQL Server
A volte, troverò un cliente che ha inavvertitamente deselezionato la casella per limitare le dimensioni del registro della cronologia dei lavori. Questo è un errore facile da commettere se si dispone di un server occupato e il registro continua a scorrere così rapidamente da non avere alcuna cronologia dei processi utile a cui fare riferimento durante la risoluzione dei problemi dei processi di SQL Server Agent. Un approccio migliore consiste nell'aumentare la dimensione massima del registro della cronologia dei lavori (in righe) a un valore molto più elevato anziché lasciarla crescere senza limitazioni.
Nei casi in cui i clienti avevano una crescita del lavoro illimitata, la tabella sysjobhistory era diventata eccessivamente grande e doveva essere eliminata. Il modo migliore per eliminare la cronologia è utilizzare sp_purge_jobhistory e passare un parametro di data. La procedura memorizzata eliminerà tutta la cronologia dei lavori precedente alla data fornita. Se è necessario mantenere un numero minimo di giorni di cronologia di SQL Server Agent, limitare il registro della cronologia dei processi in base alle righe non è efficace. Invece, non limitare la dimensione del registro della cronologia dei lavori e pianificare anche un lavoro che eseguirà sp_purge_jobhistory e passerà un parametro di data per il numero minimo di giorni di cronologia dei lavori necessari. È comune utilizzare un valore di 14 o 30 giorni.
Intermediario di servizi
Di recente ho riscontrato un problema con un client in cui msdb era cresciuto fino a 14 GB di dimensione. Dopo un tentativo di aggiornare l'istanza a un Service Pack corrente, l'aggiornamento non è riuscito nell'applicazione degli script a msdb e ha causato una nuova crescita esponenziale di msdb. Dopo alcune ricerche abbiamo scoperto che Service Broker era abilitato per le notifiche di eventi ma non era configurato correttamente. Per oltre un anno le notifiche di eventi sono state messe in coda, ma non sono state instradate.
Nel controllare sys.transmission_queue ho scoperto che il broker di servizi nel database di destinazione non era disponibile e il broker di servizi era disabilitato dal punto di vista amministrativo. Ho quindi controllato per vedere quali notifiche di eventi sono state impostate eseguendo una query su sys.server_events_notifications e ho trovato solo una voce:cattura tutti gli eventi del registro degli errori. Ho quindi interrogato sys.transmissions_queue per vedere quanti eventi erano in coda e ho trovato diversi milioni di record lì.
Dopo aver discusso questo con il cliente e aver spiegato i risultati, abbiamo convenuto che la migliore linea d'azione era eliminare la notifica dell'evento e cancellare la coda corrente creando un nuovo broker. Per fare ciò ho eseguito ALTER DATABASE msdb SET NEW_BROKER. Questo è stato fatto dopo ore e dopo un buon backup completo di msdb.
Dopo aver cancellato la coda di trasmissione e rimosso l'evento, sono stato in grado di ridurre msdb da 14 GB a 300 MB. Prima di correggere questo problema, il database msdb presentava la latenza del disco più alta nell'istanza e il client presentava deadlock regolari. Dopo aver implementato questa modifica, così come altre ottimizzazioni, l'esperienza utente del client è notevolmente migliorata.
Spedizione log
All'inizio della mia carriera di DBA ho ereditato un server di consolidamento che aveva alcune centinaia di database che erano stati inviati a un server secondario in un altro data center. Questo server era attivo e funzionante da diversi anni e spediva i log ogni 15 minuti. Non solo questa istanza soffriva di non eliminare la cronologia di backup, ma non cancellava correttamente la cronologia di monitoraggio di Log Shipping. Dopo aver eliminato la cronologia di backup e verificato le dimensioni di msdb, mostrava ancora più spazio utilizzato di quanto avrebbe dovuto. Ho eseguito uno script per mostrarmi la dimensione totale di ogni tabella e ho scoperto che il log_shipping_monitor_history_detail il tavolo era molto grande. In questo caso sono stato in grado di eseguire sp_cleanup_log_shipping_history per eliminare la cronologia e riportare msdb alle dimensioni normali.
Indicizzazione
L'ottimizzazione degli indici in msdb è importante tanto quanto i database degli utenti. Molte volte ho trovato clienti che stanno ottimizzando i database degli utenti ma non i database di sistema. Poiché il database msdb è ampiamente utilizzato da SQL Server Agent, Log Shipping, Service Broker, SSIS, backup e ripristino e altri processi, gli indici possono diventare molto frammentati. Assicurati che i tuoi lavori di ottimizzazione dell'indice includano anche i tuoi database di sistema, o almeno msdb. Ho visto le ottimizzazioni degli indici liberare diversi gigabyte di spazio da indici altamente frammentati all'interno di msdb.
Riepilogo
Trascurare msdb può influire negativamente sulle prestazioni dell'ambiente. È fondamentale monitorare le dimensioni di msdb, nonché i processi che lo utilizzano, per garantire che funzioni in modo ottimale. La cronologia di backup e ripristino è il motivo più comune per cui il database msdb si gonfia, tuttavia Ottimizzazione guidata motore di database, cronologia di SQL Server Agent, broker di servizi, distribuzione dei log e mancanza di manutenzione dell'indice possono tutti contribuire alla crescita eccessiva di msdb e influire sulle prestazioni di il database.
