SQL Server Sandbox

Saya mencoba menyiapkan kotak pasir untuk pengembang laporan kami untuk pekerjaan mereka. Rencana saya saat ini adalah "mengatur ulang" database setiap malam, tetapi saya tidak yakin bagaimana cara melakukannya. Apa yang saya maksud dengan reset adalah bahwa pada dasarnya saya ingin menjatuhkan tabel pengguna, tampilan, prosedur tersimpan, dll dari semua kecuali satu database di server. Saya kira pilihan lain adalah dengan menjatuhkan dan membuat ulang basis data juga, tetapi saya cukup yakin itu berarti menyesali akses ke semua grup / orang AD yang tepat juga.

Saya benar-benar tidak tahu apa yang akan menjadi cara terbaik untuk melakukan hal ini jadi saya berharap beberapa dari Anda akan dapat memberikan beberapa ide / saran yang bagus. Terima kasih.

Untuk kejelasan, kami pada dasarnya ingin melakukan ini dengan database kami: http://try.discourse.org/t/this-site-is-a-sandbox-it-is-reset-every-day/57 . Satu-satunya perbedaan adalah bahwa kami tidak ingin membuat ulang pengguna kami setiap hari.

Versi:
Edisi SQL Server 2008 : Pengembang & Perusahaan

sql-server sql-server-2008

— Kittoes0124
sumber

Jawaban:

Gagasan lain adalah dengan hanya mengatur pekerjaan malam yang melakukan backup copy_only dan mengembalikannya di server dev (atau di server yang sama, jika Anda hanya memiliki satu, tetapi itu mungkin bukan ide bagus). Yang menyenangkan tentang ini adalah bahwa pengembalian dapat pergi ke server apa pun (atau beberapa server), dan dapat sepenuhnya dipisahkan dari aktivitas apa pun pada basis data primer.

Di server 1:

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

Di server 2:

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

Anda mungkin juga perlu menambahkan MOVEperintah jika tata letak disk antara server berbeda (atau jika Anda meletakkan salinan di server yang sama).

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';

Jika Anda memulihkan di server yang sama, Anda seharusnya tidak memiliki masalah dengan pengguna. Jika Anda mengembalikan ke server yang berbeda, pengguna Anda akan ada tetapi login tingkat server mungkin tidak. Ada skrip untuk memperbaikinya , dan fitur baru di SQL Server 2012 ( Contained Databases ) yang menghilangkan masalah sama sekali.

— Aaron Bertrand
sumber

Kami memiliki dev / prod tetapi dev adalah satu-satunya server di mana ini akan terjadi. Prod hanya untuk proses prod-ready.

— Kittoes0124

Ini adalah solusi yang akan saya pilih, hanya perlu diingat bahwa dalam kebanyakan kasus Anda tidak ingin hanya menyalin produksi ke lingkungan dev. Harap sediakan ukuran (skrip?), Yang akan, misalnya, menghapus atau mengaburkan alamat email pengguna, detail kontak, dll. Anda tidak ingin devs Anda mulai mengirim email ke pengguna secara tidak sengaja.

— zeroDivisible

Karena Anda memiliki instance dengan mesin Enterprise Edition, saya akan menggunakan snapshot database .

Ini akan memungkinkan Anda untuk dengan cepat dan mudah mengembalikan segala perubahan yang dilakukan pada siang hari, tanpa harus mengembalikan seluruh database.

Perhatikan bahwa jika pengembang berencana untuk melakukan pemuatan data besar (sepertinya tidak?), Maka ini mungkin tidak sesuai.

— Jon Seigel
sumber

Mengapa itu tidak pantas jika mereka melakukan beban data besar? Milik kami mungkin memuat katakan .... 8 juta baris 100 kolom setiap sekarang (bahkan jika "seharusnya" tidak menjadi) tetapi kami tidak selalu ingin mencegah mereka melakukannya. Yang benar-benar kita pedulikan adalah bahwa semuanya akan nuked pada akhirnya.

— Kittoes0124

@Kittoes karena snapshot harus dipertahankan ketika sumber data berubah. Perlu menarik halaman yang ada dari sumber jika sumber berubah, sehingga mempertahankan tampilan "sebelum". Itu tidak melakukan itu sampai data sumber berubah (snapshot menggunakan file jarang yang kosong kecuali untuk delta). Perawatan ini bisa menjadi sangat mahal. Lihat cara kerja snapshot basis data .

— Aaron Bertrand

@ AaronBertrand Ok, jadi jika basis data tumbuh hingga 8GB selama sehari maka ketika snapshot dikembalikan semua data baru akan dihapus tetapi basis data akan tetap berukuran 8GB? Atau apakah saya salah paham?

— Kittoes0124

@Kittoes snapshot hanya-baca, jadi Anda hanya dapat memuat data baru ke basis data sumber. Jika Anda menambahkan 8GB di siang hari, itu tidak akan terlihat oleh snapshot. Ketika Anda mengembalikan / menjatuhkan snapshot, basis data sumber akan tetap memiliki data 8GB dan akan berukuran sesuai dengan itu. Jika Anda kemudian mengambil snapshot lain, data baru akan terlihat. Jika Anda menghapus 8GB di siang hari, itu akan ditambahkan ke snapshot.

— Aaron Bertrand

@Kitto jika Anda bermaksud membatalkan unduhan data 8GB dengan kembali ke titik waktu pengambilan foto, ya harus mengembalikan file data ke ukuran semula (apakah Anda benar-benar ingin memiliki file kecil lagi jadi Anda bisa autogrow lebih banyak saat memuat 8GB lagi besok adalah masalah lain). Tapi saya belum menguji skenario itu secara eksplisit. Dan seperti artikel yang saya tautkan dengan menyebutkan, ini tidak selalu sangat mudah, karena juga bergantung pada keandalan penyimpanan yang mendasarinya. Cadangan adalah cara yang lebih aman untuk melakukan itu.

— Aaron Bertrand

Biarkan saya menambahkan beberapa sen untuk melihat apakah itu membantu Anda:

Di perusahaan saya, kami memiliki situasi yang sama bahwa setiap malam pengembang ingin menyegarkan basis data yang telah mereka gunakan sepanjang hari. Ini berarti bahwa kita memiliki satu set database yang Dev tidak menyentuh - katakanlah A dan satu set database yang tepat menyalin A tetapi mereka melakukan hal-hal mereka tetapi ingin mendapatkan segar setiap malam - memungkinkan katakanlah B . Ini terjadi pada 1 instance server tunggal.

Apa yang saya terapkan adalah PROSES KEMBALI MALAM untuk mencapai ini. Di bawah ini adalah cara kerjanya:

Buat tabel driver dengan daftar database yang perlu dipulihkan setiap malam (seperti yang telah Anda sebutkan).

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

Kemudian Anda dapat menulis beberapa TSQL yang akan mengulang daftar database dari tabel di atas dan kemudian melakukan pemulihan dan mencatat keberhasilan atau kegagalan dalam Hasil dan sedikit 1 = Lulus atau 0 = Gagal. Enabled_YN akan menentukan apakah database itu perlu dipulihkan atau tidak.

Jika ada lebih banyak database yang akan ditambahkan di masa depan maka Anda harus memasukkannya dalam tabel dan mengatur bit enabled_YN menjadi Y (diaktifkan).

Dengan cara ini prosesnya akan lebih fleksibel dan mudah dikelola.

Jika Anda ingin SQL yang saya tulis (saya yakin, Anda akan dapat menulisnya :-)), cukup ping saya atau tambahkan komentar dan saya akan membagikannya.

HTH

— Kin Shah
sumber