Sandbox di SQL Server


9

Sto tentando di impostare una sandbox per i nostri sviluppatori di report per il loro lavoro. Il mio piano attuale è di "resettare" il database ogni sera ma non sono sicuro di come procedere. Ciò che intendo per reset è che voglio essenzialmente eliminare qualsiasi tabella utente, vista, stored procedure, ecc. Da tutti i database tranne uno sul server. Suppongo che un'altra opzione sarebbe quella di eliminare e ricreare anche il database, ma sono abbastanza sicuro che significherebbe regredire l'accesso a tutti i gruppi / persone AD appropriati.

Non so davvero quale sarebbe il modo migliore per farlo, quindi spero che alcuni di voi saranno in grado di fornire alcune buone idee / suggerimenti. Grazie.

Per chiarezza, vogliamo essenzialmente farlo con il nostro database: http://try.discourse.org/t/this-site-is-a-sandbox-it-is-reset-every-day/57 . L'unica differenza è che non vogliamo ricreare i nostri utenti ogni giorno.

Versione: SQL Server 2008
Edition: Developer & Enterprise

Risposte:


8

Un'altra idea sarebbe quella di impostare semplicemente un lavoro notturno che esegua un backup copy_only e lo ripristini sul server dev (o sullo stesso server, se ne hai solo uno, ma potrebbe non essere una grande idea). La cosa bella di questo è che il ripristino può andare su qualsiasi server (o più server) e può essere completamente disaccoppiato da qualsiasi attività sul database primario.

Sul server 1:

BACKUP DATABASE db TO DISK = '\\someshare\file.bak' 
  WITH COPY_ONLY, INIT, COMPRESSION;

Sul server 2:

RESTORE DATABASE db_dev FROM DISK = '\\someshare\file.bak'
  WITH REPLACE, RECOVERY;

Potrebbe essere necessario aggiungere anche MOVEcomandi se il layout del disco tra i server è diverso (o se si inserisce la copia sullo stesso server).

RESTORE DATABASE db_dev FROM DISK = '\\someshare\file.bak'
  WITH REPLACE, RECOVERY,
  MOVE 'data_file_name' TO 'D:\somepath\somefile.mdf',
  MOVE 'log_file_name'  TO 'E:\somepath\somefile.ldf';

Se stai ripristinando sullo stesso server, non dovresti avere problemi con gli utenti. Se esegui il ripristino su un altro server, i tuoi utenti esisteranno ma gli accessi a livello di server potrebbero non esserlo. Esistono degli script per risolvere questo problema e una nuova funzionalità in SQL Server 2012 ( Database contenuti ) che elimina del tutto il problema.


Abbiamo dev / prod ma dev è l'unico server in cui ciò accadrà. Prod è solo per processi pronti all'uso.
Kittoes0124,

Questa è la soluzione che sceglierei, ti prego di tenere presente che nella maggior parte dei casi non vuoi semplicemente copiare la produzione nell'ambiente di sviluppo. Ti preghiamo di disporre di una misura (script?) Che, ad esempio, rimuova o oscuri gli indirizzi e-mail degli utenti, i dettagli di contatto, ecc. Non vuoi che i tuoi sviluppatori inizino a inviare accidentalmente e-mail agli utenti.
zero Divisibile il

5

Dal momento che hai un'istanza con il motore Enterprise Edition, vorrei usare gli snapshot del database .

Ciò ti consentirà di ripristinare rapidamente e facilmente tutte le modifiche apportate durante il giorno, senza dover ripristinare l'intero database.

Nota che se gli sviluppatori stanno pianificando di caricare grandi quantità di dati (sembra che non lo siano?), Ciò potrebbe non essere appropriato.


Perché non sarebbe appropriato se avessero caricato grandi quantità di dati? La nostra potrebbe caricare diciamo .... 8 milioni di righe di 100 colonne ogni tanto (anche se "non dovrebbero" esserlo) ma non vogliamo necessariamente impedire loro di farlo. Tutto ciò che ci interessa davvero è che alla fine della giornata tutto venga rovinato.
Kittoes0124,

2
@Kittoes perché un'istantanea deve essere mantenuta quando i dati di origine cambiano. Deve estrarre le pagine esistenti dalla fonte se la fonte cambia, in modo da mantenere la vista "prima". Non lo fa fino a quando i dati di origine non cambiano (un'istantanea utilizza un file sparse vuoto ad eccezione dei delta). Questa manutenzione può diventare piuttosto costosa. Scopri come funzionano le istantanee del database .
Aaron Bertrand

@AaronBertrand Ok, quindi se il database cresce fino a 8 GB durante il giorno, quando viene ripristinata l'istantanea tutti i nuovi dati verrebbero rimossi ma il database avrebbe comunque dimensioni di 8 GB? O sto fraintendendo?
Kittoes0124,

@Kittoes un'istantanea è di sola lettura, quindi sarai in grado di caricare solo nuovi dati nel database di origine. Se aggiungi 8 GB durante il giorno, non sarà visibile all'istantanea. Quando si ripristina / elimina l'istantanea, il database di origine avrà ancora 8 GB di dati e verrà ridimensionato di conseguenza. Se si esegue quindi un'altra istantanea, i nuovi dati saranno visibili. Se rimuovi 8 GB durante il giorno, verrà aggiunto all'istantanea.
Aaron Bertrand

1
@Kittoes se vuoi dire che vuoi annullare il caricamento dei dati da 8 GB ripristinando il momento in cui è stata scattata l'istantanea, sì, dovrebbe riportare i tuoi file di dati nella dimensione in cui erano (se vuoi davvero avere di nuovo i file piccoli così puoi semplicemente aumentare di nuovo l'autogrow quando carichi di nuovo 8 GB domani è un altro problema). Ma non ho testato questo scenario esplicitamente. E come l'articolo che ho collegato alle menzioni, questo non è necessariamente infallibile, poiché dipende anche dall'affidabilità dello storage sottostante. Un backup è un modo più sicuro per farlo.
Aaron Bertrand

0

Vorrei aggiungere i miei pochi centesimi per vedere se ti aiuta:

Nella mia azienda abbiamo la stessa situazione che ogni notte gli sviluppatori vogliono aggiornare i database che hanno utilizzato durante il giorno. Questo significa che abbiamo un insieme di database che Dev di non toccare - Diciamo A e un altro insieme di database che sono copia esatta A, ma che fanno la loro roba, ma vogliono essere rinfrescato ogni notte - consente di dire B . Questo accade su 1 singola istanza del server.

Ciò che ho implementato è un PROCESSO DI RIPRISTINO NOTTURNO per raggiungere questo obiettivo. Di seguito è come funziona:

Crea una tabella dei driver con un elenco di database che devono essere ripristinati ogni sera (come hai già detto).

Tabella: nightly_restore (OriginalDB, RestoreDB, backuplocation, enabled_YN, Results, PASS_FAIL)

Quindi è possibile scrivere un TSQL che scorrerà l'elenco dei database dalla tabella sopra e quindi eseguirà i ripristini e registrerà qualsiasi esito positivo o negativo in Risultati e un bit 1 = Pass o 0 = Fail. Enabled_YN determinerà se il database deve essere ripristinato o meno.

Se ci saranno più database che verranno aggiunti in futuro, dovrai semplicemente inserirli nella tabella e impostare il bit enabled_YN su Y (abilitato).

In questo modo il processo sarà più flessibile e gestibile.

Se vuoi l'SQL che ho scritto (ne sono sicuro, sarai in grado di scriverlo :-)), inviami un ping o aggiungi un commento e lo condividerò.

HTH

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.