Suggerimento per la progettazione di database SQL Server di grandi dimensioni

Stiamo creando un database in MSSQL 2008 R2 Standard in cui memorizzeremo un gran numero di record. Stimiamo oltre 200 milioni di record in una tabella ogni anno e stiamo principalmente INSERENDO con pochissimi AGGIORNAMENTI o ELIMINA i dati. È un sistema di archiviazione dei dati in cui inseriamo record storici su base giornaliera. Genereremo diversi tipi di rapporti su questo record storico su richiesta dell'utente, quindi abbiamo alcune preoccupazioni e richiedono input e consigli tecnici.

• Qual è il modo migliore per gestire questo tipo di tabelle e database di archivio?

Ecco la mia opinione:

1. Se si verificano pochissimi aggiornamenti / eliminazioni, è possibile aumentare il fattore di riempimento pagina al 95%. Ciò farà risparmiare spazio e legge. Fai dei test però.
2. Suddividere la tabella in base a un'ampia categoria come l'anno.
3. Metti queste partizioni su diversi filegroup.

200 milioni di righe all'anno non sono particolarmente grandi (a meno che le righe non siano insolitamente grandi). È necessario prestare attenzione ai solidi principi di progettazione del database (normalizzazione) e utilizzare funzionalità standard come l'indicizzazione e il partizionamento. Ovviamente anche l'hardware giusto è importante.

Non ci sono abbastanza informazioni qui per dare consigli specifici. Prendi in considerazione l'assunzione di qualcuno se ritieni di aver bisogno di aiuto con la progettazione e l'implementazione dettagliate.

• Assicurati che il tuo design renda possibile che i tuoi inserti siano sempre alla fine della tabella. Suggerimento Indice cluster.

• Hai solo pochissimi indici non cluster che supportano i rapporti che devi fare per mantenerli al minimo. Questi rapporti sono pregenerati? se sì, considera questa domanda: va bene se la generazione del rapporto richiede 2 ore? (senza indice) o 1min (con indice). Forse è ok lasciare che il report impieghi 2 ore per avere un indice in meno? o forse no? Se il rapporto non è pregenerato bene, questa è un'altra domanda, poiché agli utenti non piace attendere e potrebbe essere necessario implementare più indici per supportare i rapporti.

• Da come descrivi questo database sembra che ti aspetti molte righe e che i dati si aggiungeranno e cresceranno molto. Hai considerato come eseguire il backup di questo sistema? Riconosco che la maggior parte dei dati sarà la stessa e aggiungerò solo nuovi? Non conosco i requisiti aziendali di questo sistema, ma a me sembra che tra un anno o due questo potrebbe essere un database di dimensioni considerevoli e potresti avere problemi a fare molti backup completi. Considerare di effettuare un backup completo con periodici (settimanali?) E differenziali (giornalieri?) E registri delle transazioni (ogni ora?) Naturalmente come ho detto non conosco i requisiti aziendali, forse non hai bisogno di tutti i backup in ogni momento? Le dimensioni possono essere un problema nei sistemi di archiviazione.