Come ripristinare un database di SQL Server e ridurne i file contemporaneamente?

Diciamo che ho un database SQL Server i cui file di dati sono stati creati con una dimensione iniziale di 100 GB, ma contiene solo 10 GB di dati. Un backup del database avrà quindi solo 10 GB di dimensione.

Voglio ripristinare questo backup su un server diverso (o un database diverso sullo stesso server), ma non voglio che occupi lo stesso spazio su disco di quello originale (100 GB), che è ciò che accade per impostazione predefinita.

Non riesco a ridurre il database originale prima di eseguire un backup (è un database di produzione e ha bisogno di molto spazio pre-allocato); Ho potuto compattare il database ripristinato dopo che il ripristino è fatto, ma vorrei davvero preferiscono avere non occupano 100 GB mentre si fa questo; inoltre, in questo specifico scenario non ho molto spazio libero su disco, quindi il ripristino non sta andando da nessuna parte.

Esiste un modo per ripristinare il database e occupare tanto spazio quanto i dati effettivi in ​​esso contenuti ?

No, scusa, assolutamente no. Ripristina ripristina i file così come erano nel backup. Schinking deve essere fatto dopo o prima di eseguire il backup.

Se sei a corto di spazio su disco, puoi inserire il file .bak in una condivisione di rete e ripristinarlo da lì. Dovrebbe funzionare se il tuo server sql è in esecuzione con un account di dominio e dare alla condivisione diritti sufficienti per leggere il file.

L'altra opzione che era precedentemente nel cestino dei dadi (ma utile solo se il tuo sql server 2008 r2 in esecuzione) è che SQL Server supporta la creazione di file di database direttamente su una condivisione senza dover usare una traccia traccia e posso dire per esperienza personale, funziona! Quindi puoi eseguire un ripristino WITH MOVE in una condivisione.

In generale, no. Alcune idee casuali che potrebbero esserti di aiuto o meno:

• A meno che non siano assolutamente necessari dati da quel backup specifico , è possibile creare un nuovo database (vuoto) della dimensione di destinazione e utilizzare copie in blocco (o SSIS) per inviare tutte le tabelle dal database corrente (attivo) nella copia.
• Esistono strumenti di terze parti (Redgate Compare, ad esempio) che possono aiutare ad automatizzare questo tipo di cose, se si tratta di più di un'operazione una tantum.
• Alcuni software di backup di terze parti (Quest Litespeed, ad esempio) hanno la possibilità di eseguire un " ripristino a livello di oggetto ", che può ripristinare singole tabelle o altri oggetti in un nuovo database (vuoto). Anche se il backup non è stato creato utilizzando Litespeed, credo che il prodotto dovrebbe funzionare su backup SQL nativi.

Infine, mi piace anche un po 'di "gomito" nei miei database di produzione, ma 90 GB liberi da 100 GB totali sembrano un po' estremi. I seguenti passaggi potrebbero darti ciò di cui hai bisogno e non dovrebbero influire sulla produzione:

1. Esegui un DBCC SHRINKFILE ('myfile.MDF', TRUNCATEONLY)file di dati di produzione per rilasciare temporaneamente qualsiasi spazio libero alla fine del file (un TRUNCATEONLY non richiede IO e non frammenta gli indici)
2. Se anche il file di registro è grande, esegui un DBCC SHRINKFILEfile di registro di produzione durante un periodo di scarsa attività, subito dopo aver eseguito un backup del registro.
3. Esegui il backup
4. Eseguire una ALTER DATABASE MODIFY FILEnuova espansione del file di dati di produzione alla dimensione originale.

Non ci dovrebbe essere alcun impatto sulla produzione usando questi passaggi. L'unico rischio è se alcuni dei dati si trovano proprio alla fine del file di dati da 100 GB, nel qual caso il passaggio (1) non rilascerà molto se non c'è spazio.