SQL Server: filegroup solo per tabelle di sistema?

11

Uno dei nostri standard aziendali è avere un filegroup / file separato per tabelle / indici utente. Questo è impostato come predefinito, quindi non è necessario qualificare le istruzioni CREATE TABLE.

Quindi sembra così

fileid 1 = tabelle di sistema, MDF
fileid 2 = t-log = LDF
fileid 3 = utente roba = NDF

Qualcuno qui può aiutarmi a capire la giustificazione originale del perché questo è stato richiesto?

Verrò pulito e dichiarerò che è voodoo. Am I wrong ...?

Modifica: sono a conoscenza di come utilizzare i filegroup per la separazione di indici / partizioni / archivi, nonché di come ripristinare frammentario. Questa domanda riguarda l'uso di un filegroup separato sullo stesso volume solo per le tabelle di sistema.

sql-server filegroups disk-structures

— GBN
fonte

9

Il libro di formazione 70-432 di Microsoft dice "Il motivo principale per non posizionare nessuno dei tuoi oggetti nel gruppo di file primario è quello di fornire il maggior isolamento possibile nell'I / O. I dati negli oggetti di sistema non cambiano con la stessa frequenza dei dati nei tuoi oggetti. Riducendo al minimo l'attività di scrittura nel file di dati primario, riduci la possibilità di introdurre la corruzione a causa di guasti hardware. Inoltre, poiché lo stato del filegroup primario determina anche lo stato del database, puoi aumentare la disponibilità del database minimizzando le modifiche apportate al filegroup primario. "

Quindi, prendilo come vuoi. Altri affermano che ciò non è necessario in determinate circostanze e ovviamente è più da mantenere. Ho pensato di fornire il ragionamento di Microsoft.

— Jared
fonte

Ragionevole, una giustificazione scritta per questo. Accetterò questo

— gbn

1

Un altro motivo è che un ripristino del database PARTIAL consente il ripristino del filegroup PRIMARY e di altri filegroup selezionati che consentono un ripristino più rapido di un VLDB progettato correttamente. Consentire il ripristino dei filegroup archiviati / secondari in un secondo momento.

— MartinC,

@MartinC: conosco ripristini parziali ecc., Ma non ho mai capito la logica di separare esplicitamente le tabelle di sistema. Filegroup per performamce, archiviazione, manutenzione, partizionamento ecc. Ma tabelle di sistema? Finora Jared ha offerto la migliore spiegazione ...

— gbn

Se il database nel suo insieme è molto grande, il filegroup primario potrebbe avere un backup più regolare rispetto ai dati principali. Il ripristino richiederebbe solo un backup del registro di coda e il ripristino del filegroup primario e dei registri delle transazioni poiché il backup del filegroup più la coda. Poiché le tabelle di sistema sono piccole, si tratterebbe di un processo di recupero più rapido rispetto a quello per l'intero database, in modo da ridurre i tempi di inattività in caso di problemi.

— MartinC,

12

Questo non è un guadagno in termini di prestazioni, ma c'è un guadagno di recupero da realizzare. Se si verifica un danneggiamento dei file nelle tabelle di sistema, il database viene perso. Se si conservano i dati utente in un gruppo di file (o gruppi) separato, è possibile ripristinare solo quei file mantenendo il resto del database online durante il ripristino (presupponendo Enterprise Edition qui).

Se questo è il motivo per cui lo affermano, non posso dire, ma questo sarebbe un vantaggio di avere più gruppi di file con solo gli oggetti di sistema nel filegroup PRIMARY.

Dovresti comunque calciare nella spazzatura per dire che AutoShrink dovrebbe essere abilitato.

— mrdenny
fonte

Per saperne di più, puoi cercare Ripristino frammentario online nella documentazione online.

— Brent Ozar,

1

Ho sempre pensato che questo sia anche voodoo dato che i 2 filegroup si trovano sullo stesso volume (su una SAN). Il rischio di corruzione è così elevato? (I DBA operativi effettivi impostano AutoShrink su false)

— gbn

Le probabilità sono che se c'è corruzione, sarà una singola pagina all'interno di un singolo file poiché l'archiviazione si interromperà durante la scrittura della pagina su disco. Qualcosa come il 99,9999% della corruzione del database è un problema di archiviazione. 1/2 del resto dei problemi è memoria insufficiente, il resto sono bug SQL. Man mano che i database diventano più grandi (multi-TB), questo diventa più importante, poiché il ripristino di un database multi-TB richiederà diversi giorni.

— mrdenny,

Non avrei ragione nel pensare che se gli oggetti di sistema si trovano solo nel filegroup primario di cui dovresti aver bisogno in futuro, sarai in grado di fare quanto segue. Crea x file aggiuntivi in un altro filegroup. Riempi proporzionalmente questi file migrando i tuoi dati dal tuo file di dati esistente?

— Ally Reilly,

4

Non sono sicuro di aver capito, stai chiedendo a qualcuno di giustificare il tuo standard aziendale? Penserei che chiunque abbia scritto quel documento sugli standard per la tua azienda sarebbe in grado di far luce sul perché ciò sarebbe stato fatto.

Detto questo, non è insolito per alcuni negozi voler separare i dati di sistema dai dati degli utenti. E se utilizzato in combinazione con set di dischi dedicati, è possibile ottenere alcuni miglioramenti delle prestazioni.

— SQLRockstar
fonte

Grazie. Non giustificarlo, ma spiegalo. Questo è lo stesso team di DB Engineering che dice che AutoShrink è attivo. Dato che le tabelle di sistema occupano pochi MB e saranno comunque in memoria, credi in qualche miglioramento delle prestazioni?

— gbn