Prendo spunto da alcune ricerche fatte sulla rete in merito alla manutenzione di database di grandi dimensioni per fissare alcuni punti che spero vi possano essere di aiuto quando i vostri database diventano dei VLDB :-)

    * Attivare la funzionalità di rilevamento delle pagine incomplete (Torn Page Detection) o Page Checksum (SQL Server 2005)
    * Verificate che l'auto-aggiornamento delle statistiche sia attivo
    * Attenzione alla frammentazione degli indici
          o La frammentazione logica penalizza soprattutto le prestazioni in lettura
          o Ricostruite o deframmentate gli indici che sono molto frammentati (> 30%)
          o La densità di pagina penalizza soprattutto il throughput dell'IO su disco e l'utilizzo della memoria
          o Bassa densità di pagina può essere sintomo di split di pagina, quindi approfondire l'analisi per verificare se è questo il caso
          o Se eseguite DBCC INDEXDEFRAG invece di DBREINDEX, aggiornate manualmente le statistiche al completamento del comando
          o Occhio ad operazioni di manutenzione massive sugli indici se usate Log Shipping o Database Mirroring
                - Risultano in maggiori dimensioni del backup del log (maggiore dimensione = maggiore durata del backup = maggiore occupazione di banda per inviare il log sul server di stand-by)
                - La ricostruzione degli indici viene sempre loggata quando è attivo Database Mirroring
          o Verificate periodicamente se tutti gli indici presenti sono necessari
          o Anche un VVVVLDB può essere soggetto a controllo di corruzione dei dati
                - http://blogs.msdn.com/sqlserverstorageengine/archive/2006/10/20/consistency-checking-options-for-a-vldb.aspx
                - Implementate un piano di disaster recovery !!!
                - ... e provate che funzioni prima di usarlo !!!
    * Fissate bene in mente i vostri SLA
          o http://blogs.msdn.com/sqlserverstorageengine/archive/tags/Service+Level+Agreements/default.aspx
    * Implementate una strategia di backup in linea con i vostri SLA
          o Ad esempio, il backup completo settimanale senza soluzioni di alta disponibilità non soddisfano uno SLA che non consente perdite di dati
    * Ottimizzate il tempdb
    * Fate attenzione alla modalità di gestione del transaction log
          o Ad esempio, in Full recovery mode se non fate il backup del log presto finirete lo spazio sul disco del log :-)
          o Non create più files di log - non serve
          o Monitorate la crescita del file di log ed ottimizzatene la dimensione ed il tasso di crescita
    * Non comprimete il database
          o http://blogs.msdn.com/sqlserverstorageengine/archive/2007/04/15/how-to-avoid-using-shrink-in-sql-server-2005.aspx
          o Lasciate pure attiva l'auto crescita dei files di database, ma gestite attivamente la dimensione iniziale ed il tasso di crescita (sp_helpdb eseguita giornalmente o settimanalmente vi indica il tasso di crescita del vostro db)