Attualmente stiamo riscontrando alcuni problemi di prestazioni poiché il nostro database sta diventando troppo grande. Ci sono dati memorizzati negli ultimi 10 anni e non vedo un motivo per cui i dati più vecchi di 2 anni debbano essere archiviati nelle stesse tabelle dei nuovi dati.

Ora, poiché non ho un'esperienza molto profonda nell'amministrazione dei database, sto cercando i modi migliori per archiviare i vecchi dati.

Informazioni

• Ci sono circa 310'000'000 record nel database in totale.

• Il database ha bisogno di 250 GB sul disco rigido.

• La versione Server è SQL Server 2008 con livello di compatibilità SQL Server 2005 (90), ma stiamo pianificando presto l'aggiornamento a SQL Server 2012

Ho pensato a due possibilità:

Nuovo database

Creare un database simile a quello sul server di produzione e inserire tutti i vecchi dati nel nuovo database.

• Svantaggio: poiché i server collegati non sono consentiti nel nostro ambiente, sarebbe difficile unire i vecchi dati se necessario

Schema di storia

Creare un nuovo schema fe [hist] con le stesse tabelle del database di produzione. Inserisci tutti i vecchi dati in queste nuove tabelle nel nuovo schema.

• Vantaggio: facile accesso, se in futuro sarebbero necessari vecchi dati

• Preferisci una delle soluzioni rispetto all'altra?
  • Perché?
• Ci sono possibilità migliori?
• Esistono strumenti esistenti con cui questo compito è facilmente possibile?
• Qualche altro pensiero?

Grazie in anticipo

modificare

Domanda aggiuntiva:

La tabella di archivio appena creata avrebbe bisogno anche di chiavi primarie / esterne?

O dovrebbero avere solo le colonne ma senza chiavi / vincoli?

Penso che la risposta a molte delle tue domande sia che dipende. Quali problemi di prestazioni stai riscontrando? Sembra insolito che un database abbia problemi di prestazioni solo da dimensioni crescenti a 250 GB.

Forse le tue query eseguono scansioni di tabelle sull'intera tabella dei fatti anche quando è necessaria solo una piccola parte (ad esempio l'ultimo anno) dell'intervallo di date? Se esiste una query particolare che è molto importante ottimizzare, considerando di pubblicare lo schema, la query e un piano di esecuzione effettivo in un'altra domanda per vedere se può essere ottimizzato.

Preferisci una delle soluzioni rispetto all'altra?

In genere preferisco il database di cronologia e penso che Guy descriva buone ragioni per questo nella sua risposta .

Lo svantaggio principale che vedo per un database di cronologia (al contrario di uno schema) è che non puoi più usare chiavi esterne per la tua tabella di archivio. Questo può andare bene per te, ma è qualcosa di cui essere consapevoli.

Lo svantaggio elencato per questo approccio non è accurato; sarete in grado di eseguire query su più database sullo stesso server facilmente e Query Optimizer in genere gestisce molto bene le query tra database.

Ci sono possibilità migliori?

Se è necessario interrogare regolarmente i dati di archivio, potrei prendere in considerazione il partizionamento della tabella per data . Tuttavia, si tratta di un grande cambiamento che può comportare molte implicazioni in termini di prestazioni, sia positive (ad es. Eliminazione delle partizioni, caricamento più efficiente dei dati) che negative (ad es. Ricerche singleton più lente, maggiore potenziale di inclinazione dei thread nelle query parallele). Quindi non prenderei questa decisione alla leggera se si tratta di un database molto utilizzato.

La tabella di archivio appena creata avrebbe bisogno anche di chiavi primarie / esterne? O dovrebbero avere solo le colonne ma senza chiavi / vincoli?

Consiglierei di avere almeno la chiave primaria e gli indici univoci in modo da poter ottenere i vantaggi di integrità dei dati che forniscono. Ad esempio, ciò ti impedirà di inserire accidentalmente un anno di dati nella tabella della cronologia due volte. E come vantaggio secondario può migliorare le prestazioni se è necessario interrogare la tabella della cronologia.

Qualche altro pensiero?

Dal momento che stai utilizzando la versione Enterprise e stai pianificando l'aggiornamento a SQL 2008+, potresti prendere in considerazione la compressione dei dati per questa tabella. La compressione ridurrà sicuramente lo spazio su disco, ma a seconda delle risorse del disco e della CPU del server può anche migliorare le prestazioni della query per le letture riducendo l'I / O del disco e migliorando l'utilizzo della memoria (più dati si inseriscono contemporaneamente nella cache).

Preferirei avere uno schema cronologico o un secondo database storico su un server collegato ogni giorno. Risparmia i costi di licenza è più facile da gestire e interrogare. È quindi possibile utilizzare uno schema più semplice e rilasciare alcuni degli indici rendendo più piccolo il database

Ma poiché hai l'edizione enterprise hai la terza opzione che è quella di partizionare le tue tabelle che, una volta messe in atto, rendono più semplice l'archiviazione dei dati e l'interrogazione dei vecchi dati è trasparente per i tuoi utenti e non dovrai apportare modifiche alle applicazioni .

Nella mia esperienza, un secondo database sarebbe la scelta preferita per due motivi.

1. È possibile ripristinare i dati da un backup storico, quindi eliminare le tabelle e gli indici non necessari.
2. Puoi spostarlo su un altro server a scopo di reporting, questo ha i vantaggi di non usare le risorse del server primario

Dovresti comunque eliminare tutti i dati storici dal database primario ma questo potrebbe essere programmato in.

Ignorando la licenza per ora perché non è lì che passo il mio tempo.

IMHO, il database di archivio è più semplice da implementare e mantenere. Sono entità distinte, liberamente accoppiate. Lo spostamento dei dati e i controlli di carico / risorse hanno confini chiari. Può facilmente passare a un'istanza o un server diverso per una migliore gestione delle prestazioni e il costo non è un grosso problema. Nota che il più semplice! = Sforzo più economico o minimo. In realtà ha un po 'più di compiti ma sono tutti compiti semplici con due importanti eccezioni:

1. applicazione dei vincoli: niente come i vincoli tra database in SQL Server, quindi è necessario decidere se si tratta di un malfunzionamento.
2. le query tra database utilizzano query distribuite che dipendono ancora da OLEDB che è obsoleto. Ciò significa che potresti riscontrare problemi con nuovi tipi di dati, inoltre se riscontri problemi di prestazioni, è improbabile che vengano mai corretti

Lo schema di archivio o solo la tabella di archivio è un po 'più complesso da implementare ma molto più facile da usare. Tutti gli oggetti nello stesso database indicano che non è necessario replicare e mantenere i controlli di accesso. Nessuna query tra database che semplifica l'ottimizzazione delle prestazioni, il monitoraggio, la risoluzione dei problemi, ecc ...

Il partizionamento delle tabelle è un'ottima soluzione e offre molti dei vantaggi di una tabella / schema di archivio ma fornisce trasparenza agli utenti / query. Detto questo, è il più complesso da implementare e richiede cure continue che non sono facili per un principiante.

Alcune considerazioni importanti:

• Le query restituiscono regolarmente dati storici / a freddo o si accede raramente ai dati a freddo?
• I dati storici sono immutabili o vengono aggiornati / eliminati regolarmente?
• Le righe di 310m sono "moderate" (assumendo tutto in 1 tabella) a seconda delle dimensioni della riga. Hai dati sulla dimensione della riga? Quanti GB è quella fila di 310m?
• Qual è il tasso di crescita di quella tabella?
• Sei in grado di modificare il codice dell'applicazione e le sue query SQL?

Queste sono considerazioni importanti in quanto possono avere un impatto significativo sulla soluzione scelta o potrebbero non consentire determinate soluzioni. Ad esempio, se i dati storici vengono modificati / aggiornati regolarmente (più di una volta alla settimana), l'utilizzo di un database separato significa che è necessario utilizzare DTC per tali query o gestire manualmente la sicurezza delle transazioni (non banale per garantire sempre la correttezza). Il costo è significativamente superiore ai dati storici immutabili.

Inoltre, se stai pensando di aggiornare, prendi in considerazione il 2016 e la nuova funzionalità di Database estensibile: https://msdn.microsoft.com/en-us/library/dn935011.aspx

Preferirei suddividere il database in un database logico separato per i seguenti motivi:

1. Requisiti delle risorse

Suddividendolo in un database separato, può essere archiviato su un'unità diversa e monitorato a una velocità diversa rispetto ai dati di produzione principali.

2. Prestazioni

Suddividendo i dati in un database separato, il database di produzione principale viene ridotto di dimensioni, favorendo le prestazioni complessive.

3. Backup più semplici

Il backup dei dati archiviati potrebbe non essere considerato essenziale come i record 'live / current' nel database SQL principale. Ciò può significare che il backup dei dati archiviati potrebbe essere eseguito meno spesso. Anche a causa della natura sequenziale della modalità di registrazione dei dati archiviati, potrebbe essere possibile eseguire il backup di sezioni del database archiviato una volta e poi mai più. Ad esempio, una volta che i dati di archivio sono stati scritti nel database di modifica degli archivi per il 2014, tali dati non verranno più modificati.

Nota: penso che la risposta a molte delle tue domande dipenda tutto dalle circostanze, dalla natura dei dati e dai problemi di prestazione che stavi riscontrando.