Il modo migliore per deframmentare / compattare un database per scopi di archiviazione

Abbiamo un'istanza di SQL Server utilizzata per l'archiviazione della posta elettronica (per gentile concessione di un pacchetto di archiviazione di terze parti). Ogni tanto, il software viene trasferito su un nuovo database vuoto. Lo abbiamo fatto trimestralmente in passato, ma ora stiamo cercando di farlo mensilmente. La quantità di dati archiviati è di circa 15-20 GB al mese e la maggior parte dei dati risiede solo in una manciata di tabelle (di solito 2 - 4).

Una volta passato a un nuovo database, quello vecchio viene utilizzato in modo strettamente di sola lettura. Quello che mi piacerebbe fare è ottimizzarlo in un file di dati bello e stretto, con tutte le tabelle / indici contigui e con un fattore di riempimento molto elevato, e non molto spazio vuoto alla fine del file di dati. Inoltre, stiamo usando Standard Edition su questo server, con tutte le limitazioni che ciò implica (altrimenti userei già la compressione dei dati).

Alcune possibilità che mi vengono in mente:

1. RICOSTRUISCI / Riorganizza gli indici, DBCC SHRINKFILE (Okay, questa non è un'opzione sensata, dal momento che DBCC SHRINKFILE frammenterà il piscio da qualsiasi cosa tocchi, ma lo includo per completezza.)
2. Crea un nuovo database con le statistiche automatiche disattivate. Script e ricrea tutte le tabelle dal database di origine. Utilizzare bcp per esportare / importare i dati nel nuovo database, in ordine di chiave cluster. Scrive e ricrea tutti gli indici. Ricalcola tutte le statistiche con la scansione completa.
3. Crea un nuovo database con le statistiche automatiche disattivate. Script e ricrea tutte le tabelle dal database di origine. Utilizzare SSIS o T-SQL per trasferire i dati nel nuovo database. Scrive e ricrea tutti gli indici. Ricalcola tutte le statistiche con la scansione completa.

Il passaggio finale in ogni caso sarebbe impostare il database in modalità di sola lettura.

Quali altre opzioni buone / migliori ci sono per farlo? La mia preoccupazione è spostare i dati in modo tale da preservare un elevato fattore di riempimento e in modo logicamente contiguo.

Modificare:

Vorrei ricordare che circa il 75% dei dati sembra essere archiviato in colonne di immagini (LOB).

Per eliminare la frammentazione fisica nei file, è possibile spostare l'indice cluster con drop esistente in un nuovo filegroup. Poiché saranno RO, li rendono tutti fillfactor al 100% in quanto non è necessario spazio per gli inserti, le suddivisioni di pagina causate dagli aggiornamenti.

Ciò consentirebbe anche di eseguire un ripristino frammentario e di portare il database online molto rapidamente se si decide di passare all'Enterprise. Enterprise inoltre consente gli indici columnstore oltre a ridurre notevolmente il tempo di query per questi dati di sola lettura, che è un enorme raccordo.

È possibile utilizzare l'opzione shrinkfile una volta prima di passare alla lettura solo senza problemi seri con la frammentazione per rimuovere lo spazio alla fine del file come desiderato.

In una nota a margine, basta verificare che si stiano utilizzando gli ultimi tipi di dati per i tuoi LOBS. cioè nvarchar (max) o varchar (max) invece di ntext o text, varbinary (max) invece di image?

Ho riscontrato un problema simile con uno strumento di terze parti che utilizzava anche un tipo di dati immagine per archiviare dati non strutturati e l'ho risolto convertendo la colonna per utilizzare filestream . Dovrai eseguire alcuni test per assicurarti che l'app funzioni ancora come previsto, ma ciò ti darà la possibilità di scrivere il tuo processo di archiviazione che sposta i tuoi dati in un db di archivio in modo efficiente.