Salin database dengan Sql Server 2005

1

Situasi saya adalah sebagai berikut: Saya memiliki database produksi Sql Server 2005. Sekali sehari saya ingin menduplikasi database ini ke database failover lain yang ada di server contoh yang sama. Saya tidak ingin database ini disinkronkan lebih dari sekali sehari (tidak ada mirroring, misalnya). Saya tahu saya bisa melakukan ini dengan backup / restore tetapi bertanya-tanya apakah ada solusi satu langkah untuk melakukan ini.

Adakah yang tahu cara yang baik untuk melakukan ini tanpa backup / restore?

— Mike Gates
sumber

1

Jadi, apa yang akan terjadi pada basis data "disinkronkan" setelah perubahan dibuat dan itu saatnya untuk melakukan sinkronisasi ulang? Apakah Anda ingin menghapus semuanya dan menyinkronkan kembali?

— Anon246

2

Mengapa Anda ingin menghindari backup / restore?

Anda bisa membuat skrip cadangan dan memulihkan perintah dan membuatnya sebagai pekerjaan SQL, sehingga itu berjalan secara otomatis. Apakah ada yang akan terhubung ke database salinan selama operasi normal? (karena itu dapat menyebabkan masalah dengan pemulihan)

— seperti kode
sumber

Saya ingin menghindari backup / restore karena alasan yang sama bahwa ketika saya ingin menyalin file dari satu tempat ke tempat lain saya tidak ingin berurusan dengan lokasi file "di antara" ... sepertinya pekerjaan yang tidak perlu! Alasan terkait lainnya adalah bahwa melakukan pencadangan / pengembalian memerlukan izin pada disk yang melampaui izin basis data individual dari database yang terlibat. Saya tidak ingin kredensial pengguna melakukan tindakan ini setelah membaca dan menulis izin ke disk jika itu tidak perlu.

Untuk menjawab pertanyaan kedua Anda, tidak akan ada yang terhubung ke database saat salinan ini dilakukan.

Pengguna tidak harus memiliki izin pada disk untuk membuat cadangan / memulihkan - hanya mesin basis data yang membutuhkan izin tersebut - Anda dapat memberikan pengguna akses untuk melakukan pencadangan, atau lebih baik lagi, jadwalkan semuanya di Agen seperti yang disarankan oleh codeulike

— Mike DeFehr

Hmmm ... saya tidak tahu itu. Saya hanya sadar bahwa untuk melakukan backup / restore itu tidak cukup untuk menjadi DbOwner di kedua database.

Backup adalah teman Anda, jangan takut! Tampaknya tidak perlu untuk memiliki file cadangan tambahan yang terlibat, tetapi mesin SQL melakukan banyak hal pintar selama pencadangan untuk memastikan cadangan konsisten. Karenanya pembaruan dapat terus dilakukan ke database saat sedang didukung. Salinan / tempel sistem file sederhana (jika fitur seperti itu ada untuk database sql langsung) tidak akan menawarkan perlindungan semacam itu. Lepaskan, salin, pasang kembali akan menghilangkan file cadangan dari persamaan, tetapi sumber database tidak dapat digunakan saat terlepas.

— codeulike

1

Ada dua cara untuk menyalin database grosir: backup / restore dan lepas / pasang - tidak satu pun dari proses satu langkah, dan backup / restore pasti akan lebih disukai mengingat skenario yang Anda jelaskan.

Jika database "failover" perlu dijaga online saat sedang diperbarui, Anda cukup terjebak dengan replikasi. Namun, karena basis data berada pada contoh yang sama, Anda bisa menggunakan kueri basis-data untuk memindahkan data.

Saya benci untuk pergi keluar batas pertanyaan, tetapi database "failover" pada contoh yang sama seperti produksi tidak memberikan banyak cara toleransi kesalahan. Kegagalan macam apa yang ingin Anda lindungi?

Sunting: Apa yang mungkin Anda cari, kemudian (jika Anda berada di edisi perusahaan 2005+), adalah snapshot basis data seperti yang disarankan JMusgrove. Anda dapat mengambil snapshot kapan saja, lalu mengembalikan database ke snapshot itu jika diperlukan. Cuplikan hanya baca-saja sampai dan kecuali Anda mengembalikannya. Lihat artikel MSDN ini tentang Mengembalikan ke Database Snapshot . Saya akan menyarankan bahwa itu antara snapshot dan cadangan / pengembalian.

— Mike DeFehr
sumber

Agak rumit :) Aplikasi menggunakan database juga menggunakan penyimpanan sistem file yang harus disinkronkan dengan keadaan database. Jika filesystem rusak, basis data tidak berguna. Dalam hal ini, saya perlu memutar kembali ke status database / sistem file yang valid. Toleransi kesalahan instance server database itu sendiri ditangani secara terpisah.

0

Seperti yang disarankan codeulike, ada apa dengan backup dan restore. Kedengarannya seperti cocok semantik terdekat untuk apa yang Anda coba lakukan.

Cukup banyak tindakan yang dapat Anda lakukan di SQL Server Management Studio memiliki opsi untuk menghasilkan skrip untuk melakukan tindakan, daripada benar-benar melakukan tindakan di sana dan kemudian.

Cari tombol Script di bagian atas setiap jendela sembul. Sisanya mudah - hanya membuat naskah menggunakan blok bangunan yang dibuat untuk Anda oleh SSMS dan membuat pekerjaan SQL Server untuk diotomatisasi.

— Tomfanning
sumber

Saya tahu saya bisa melakukan ini. Saya hanya ingin perintah sederhana "COPY DATABASE DB_A, DB_B" yang dapat saya gunakan tanpa harus khawatir tentang semua opsi yang datang dengan cadangan / pemulihan.

0

Apakah ada kebutuhan untuk salinan yang dihasilkan untuk dimodifikasi dengan cara apa pun, atau akankah salinan read-only cukup? Jika yang terakhir, Anda dapat menggunakan snapshot basis data untuk menghasilkan "salinan" database - dan ini cukup banyak adalah proses satu langkah seperti yang diuraikan dalam artikel Technet ini

Contoh:

CREATE DATABASE myCopy ON (
    NAME = originalLogicalName,
    FILENAME = 'path\to\new\snapshotfile'
) AS SNAPSHOT OF myOriginal

Jika yang pertama, maka pendekatan satu langkah sedikit lebih rumit. Untuk database sederhana tanpa prosedur tersimpan, hubungan kompleks, dll, Anda bisa membuat paket SSIS (pekerjaan DTS) untuk menyalin data dari satu database ke yang lain - tetapi itu bisa menjadi sangat berantakan dengan sangat cepat.

— JMusgrove
sumber

Basis data baru tidak dapat dibaca hanya. Itu harus berfungsi dengan cara yang sama seperti database asli.

0

Satu cara replikasi Snapshot dapat diatur. Itu akan pergi dari sumber ke tujuan, sekali sehari ketika Anda menjadwalkannya Setelah itu di server tujuan, tujuan akan berfungsi persis seperti sumbernya. Namun setiap perubahan yang Anda buat ke tujuan akan hilang ketika replikasi berikutnya terjadi karena pada waktu yang dijadwalkan berikutnya sumber akan menimpa tujuan.

Jadi, jika tujuan Anda adalah salinan sumber sehingga pengembang Anda dapat meretas di database dengan data nyata di dalamnya dan tidak masalah jika ditimpa ketika salinan berikutnya terjadi, maka ini akan bekerja untuk Anda.

— SpaceManSpiff
sumber

0

Mengapa tidak menyiapkan replikasi snapshot? Jadikan produksi DB publikasi, dan cadangan berlangganan? Atur replikasi agar muncul setiap 24 jam, dan Anda sudah siap.

DB yang direplikasi juga akan memiliki semua properti dan izin prod DB, sehingga bisa dilampirkan sebagai prod tanpa masalah.

— DanBig
sumber