Keterangan tentang opsi pemulihan bencana untuk Microsoft SQL Server

Artikel ini membahas berbagai solusi untuk memulihkan data dari database Microsoft SQL Server, jika terjadi bencana. Artikel ini juga membahas keuntungan dan kerugian dari setiap solusi.

Pemulihan bencana adalah proses yang dapat Anda gunakan untuk membantu memulihkan informasi sistem dan data, jika terjadi bencana.

Beberapa contoh bencana termasuk alami atau buatan manusia bencana seperti api, atau teknis bencana seperti dua-disk kegagalan dalam berlebihan Array dari independen disk (RAID) 5 array.

Disaster recovery planning adalah pekerjaan yang dikhususkan untuk mempersiapkan semua tindakan yang harus terjadi sebagai respons terhadap bencana. Perencanaan termasuk pilihan strategi untuk membantu memulihkan berharga data. Pilihan strategi pemulihan bencana yang tepat tergantung pada kebutuhan bisnis Anda.

Catatan Solusi yang dibahas dalam artikel ini hanya menyediakan deskripsi umum teknologi yang dapat Anda gunakan. Ini umum deskripsi adalah untuk membandingkan berbagai metode pemulihan bencana dan rencana pemulihan bencana. Sebelum Anda memutuskan mana solusi pemulihan bencana terbaik bagi Anda, pastikan bahwa Anda melihat masing-masing bencana disarankan solusi pemulihan secara lebih rinci. Setelah berdiskusi setiap pemulihan bencana solusi, artikel ini berisi link di mana Anda dapat menemukan informasi tambahan tentang solusi itu.

Failover clustering

Microsoft SQL Server 2000 failover clustering dirancang untuk Failover secara otomatis jika terjadi kegagalan peranti penangkap keras atau peranti penangkap lunak kegagalan. Anda dapat menggunakan SQL Server 2000 failover clustering untuk menciptakan failover cluster untuk satu contoh dari SQL Server 2000 atau untuk beberapa contoh untuk SQL Server 2000. Failover clustering memungkinkan sistem database untuk secara otomatis beralih pengolahan dari suatu contoh dari SQL Server dari server gagal untuk bekerja server. Oleh karena itu, failover clustering sangat membantu jika sistem operasi terjadi kegagalan atau jika Anda melakukan upgrade yang direncanakan sistem database sumber daya. Juga, failover clustering meningkatkan ketersediaan server tanpa downtime.

Karena failover clustering dirancang untuk server tinggi ketersediaan dengan hampir tidak ada server downtime, node berkerumun harus secara geografis dekat satu sama lain. Failover clustering mungkin tidak berguna jika terjadi kegagalan array disk.

Catatan Untuk menerapkan failover clustering, Anda harus menginstal Microsoft SQL Server 2000 Enterprise Edition.

sistem operasi berikut mendukung failover clustering:

• Microsoft Windows NT 4.0, Enterprise Edition
• Microsoft Windows 2000 Advanced Server
• Microsoft Windows 2000 Datacenter Server
• Microsoft Windows Server 2003, Enterprise Edisi
• Microsoft Windows Server 2003, Datacenter Edisi

sistem operasi ini mencakup komponen diinstal, Microsoft Cluster layanan (MSCS). Untuk menerapkan failover clustering SQL Server, Anda harus menginstal MSCS.

Untuk informasi lebih lanjut tentang MSCS dan instalasi, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:

Keuntungan dan kerugian dari penggunaan failover clustering

Keuntungan

Kerugian

• Anda dikenakan biaya yang lebih besar. Pemeliharaan dua server adalah dua kali biaya mempertahankan sebuah server tunggal. Karena Anda harus mempertahankan dua server pada saat yang sama, lebih mahal untuk menginstal dan mempertahankan berkerumun node.
• Server harus berada di lokasi yang sama. Jika cabang-cabang organisasi di seluruh dunia dan kumpulan aktif/aktif harus menjadi dilaksanakan di cabang-cabang, jaringan dan infrastruktur penyimpanan yang Anda harus menggunakan sangat berbeda dari standar kuorum peranti penangkap cluster server. Oleh karena itu, meskipun itu mungkin, terbaik untuk tidak menggunakan geografis server jauh.
• Anda telah tidak ada perlindungan terhadap larik disk kegagalan.
• Failover clustering tidak memungkinkan Anda untuk membuat failover cluster di database tingkat atau di database objek tingkat, seperti Daftar Tabel tingkat.

Untuk informasi lebih lanjut tentang failover clustering, kunjungi Web site Microsoft berikut:Untuk informasi lebih lanjut tentang failover clustering, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang kebijakan dukungan Microsoft untuk SQL Server failover cluster, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:

Database mirroring

Database mirroring terutama solusi peranti penangkap lunak untuk meningkatkan ketersediaan database. Anda hanya dapat menerapkan mirroring secara per database. Mirroring hanya bekerja dengan database yang menggunakan model pemulihan penuh. Model sederhana dan login massal pemulihan tidak mendukung database mirroring. Oleh karena itu, semua operasi massal selalu sepenuhnya login. Database mirroring bekerja dengan tingkat kompatibilitas mundur database didukung setiap.

Keuntungan dan kerugian dari penggunaan database mirroring

Keuntungan

• Database mirroring meningkatkan perlindungan data.
• Database mirroring meningkatkan ketersediaan database.
• Database mirroring meningkatkan ketersediaan basis produksi selama upgrade.

Kerugian

• Cermin database harus identik dengan basis utama. Sebagai contoh, semua benda, login, dan izin harus identik.
• Database mirroring melibatkan transfer informasi dari satu komputer ke komputer lain melalui jaringan. Oleh karena itu, keamanan informasi bahwa transfer SQL Server sangat penting.

Peer-to-peer replikasi transaksional

Peer-to-peer replikasi transaksional dirancang untuk aplikasi yang mungkin membaca atau mungkin memodifikasi data dalam database yang berpartisipasi dalam replikasi. Selain itu, jika server host database tidak tersedia, Anda dapat memodifikasi aplikasi untuk lalu lintas rute ke server yang tersisa. Server sisa berisi kopi karbon identik dari data.

Keuntungan dan kerugian dari menggunakan peer-to-peer replikasi transaksional

Keuntungan

• Baca kinerja meningkat karena Anda dapat tersebar aktivitas semua node.
• Agregat pembaruan kinerja, masukkan kinerja dan menghapus kinerja untuk topologi yang menyerupai kinerja satu simpul karena semua perubahan disebarkan ke semua node.

Kerugian

• Peer-to-peer replikasi ini tersedia hanya dalam SQL Server 2005 Enterprise Edition.
• Semua peserta database harus berisi identik skema dan data.
• Kami merekomendasikan bahwa setiap node menggunakan database distribusi sendiri. Konfigurasi ini menghilangkan potensi SQL Server 2005 untuk memiliki satu titik dari kegagalan.
• Anda tidak dapat menyertakan Daftar Tabel dan objek lain dalam beberapa rekan-rekan publikasi dalam database publikasi tunggal.
• Anda harus memiliki sebuah publikasi yang diaktifkan untuk peer-to-peer replikasi sebelum Anda membuat langganan apapun.
• Anda harus menginisialisasi langganan dengan menggunakan cadangan atau dengan menetapkan nilai jenis sinkronisasi langganan untuk replikasi mendukung hanya.
• Peer-to-peer replikasi transaksional tidak memberikan deteksi konflik atau resolusi konflik.
• Kami merekomendasikan bahwa Anda tidak menggunakan identitas kolom.

Pemeliharaan siaga hangat Server

Anda dapat membuat dan memelihara server siaga hangat dengan menggunakan baik metode berikut:

• Log pengiriman
• Replication with scripts

Informasi lebih lanjut tentang masing-masing dari dua metode berikut.

Log pengiriman

Log pengiriman disertakan dalam kit sumber daya Microsoft SQL Server 7.0, dan itu sepenuhnya didirikan di Microsoft SQL Server 2000 Enterprise Edition dan pada Microsoft SQL Server 2000 pengembang edisi. Log pengiriman menggunakan server siaga yang tidak digunakan pada operasi biasa. A server siaga ini berguna untuk membantu memulihkan data jika terjadi bencana. Kamu bisa hanya menggunakan log pengiriman di tingkat database. Anda tidak dapat menggunakannya pada contoh tingkat.

Ketika server siaga memulihkan log transaksi, database dalam modus eksklusif dan tidak dapat digunakan. Namun, Anda dapat menjalankan batch pelaporan pekerjaan antara pengembalian log transaksi atau Database konsol Perintah (DBCC) cek untuk terus-menerus memverifikasi integritas siaga server. Untuk aplikasi seperti server dukungan keputusan yang memerlukan terus-menerus pemrosesan pada database server, log pengiriman adalah tidak sesuai pilihan.

Latency di server siaga didasarkan pada bagaimana sering Backup log transaksi diambil di server utama dan kemudian diterapkan pada server siaga. Jika server utama gagal, Anda mungkin kehilangan perubahan yang dibuat oleh transaksi yang terjadi setelah transaksi terakhir Anda log cadangan.

Sebagai contoh, jika backup log transaksi diambil setiap 10 menit, transaksi selama terbaru 10 menit mungkin hilang. Ini tidak selalu berarti bahwa pembaruan data yang dibuat untuk utama Server selama periode latency akan hilang. Biasanya, baru update di log transaksi utama dapat pulih dan diterapkan pada server siaga hangat dengan hanya penundaan dalam beralih dari server utama ke siaga server. Tujuan utama dari log pengiriman adalah untuk menjaga server siaga hangat. Jika menjaga server siaga hangat adalah tujuan utama Anda, log pengiriman adalah cenderung lebih tepat daripada solusi lain bahwa artikel ini membahas.

Keuntungan dan kerugian dari menggunakan log pengiriman

Keuntungan

• Anda dapat memulihkan semua database kegiatan. Pemulihan termasuk benda yang dibuat seperti Daftar Tabel dan pandangan. Itu juga termasuk perubahan keamanan seperti pengguna baru yang diciptakan dan setiap izin perubahan.
• Anda dapat gulung balik database lebih cepat. Pemulihan database dan log transaksi ini didasarkan pada tingkat rendah halaman format. Oleh karena itu, log pengiriman mempercepat proses restorasi dan mengakibatkan cepat pemulihan data.

Kerugian

• Database tidak dapat digunakan selama proses pemulihan karena database dalam modus eksklusif di server siaga.
• Ada kurangnya rincian. Selama restorasi proses, semua perubahan dalam server utama diterapkan pada siaga server. Anda tidak dapat menggunakan log pengiriman untuk menerapkan perubahan untuk beberapa Daftar Tabel dan menolak perubahan yang tersisa.
• Ada tidak otomatis failover aplikasi. Ketika server utama gagal karena bencana, server siaga tidak Failover secara otomatis. Oleh karena itu, Anda harus secara eksplisit mengarahkan aplikasi yang menyambung ke server utama untuk siaga (failover) server.

Catatan Jika tujuan utama Anda adalah untuk menjaga server siaga hangat, Microsoft menganjurkan agar Anda menggunakan log pengiriman. Server siaga hangat mencerminkan semua transaksi yang terjadi pada server utama. Namun, Anda tidak dapat menggunakan server siaga ketika server utama tersedia.

Untuk informasi lebih lanjut tentang bagaimana mengkonfigurasi server siaga hangat dengan menggunakan log pengiriman, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang pengiriman log, kunjungi Web site Microsoft berikut:

Replication with scripts

Anda juga dapat menggunakan replication with scripts untuk mempertahankan hangat server siaga. Replication with scripts bereplikasi data pada satu server (penerbit) ke server lain (pelanggan) dengan latensi kurang daripada log pengiriman. Anda dapat menerapkan replication with scripts pada objek database tingkat seperti tingkat tabel atak. Oleh karena itu, Microsoft menyarankan agar Anda menggunakan replication with scripts ketika Anda memiliki lebih sedikit data untuk melindungi, dan Anda harus memiliki rencana pemulihan yang cepat.

Anda dapat langganan mendorong untuk menegakkan replication with scripts antara dua server dengan server utama sebagai penerbit dan server siaga sebagai pelanggan. Replication with scripts memastikan data replikasi. Ketika penerbit gagal, pelanggan dapat digunakan.

Solusi ini rentan terhadap kegagalan penerbit dan pelanggan pada waktu yang sama. Dalam skenario seperti ini, Anda tidak dapat melindungi data. Dalam semua skenario lain seperti kegagalan distributor atau pelanggan, lebih baik untuk mensinkronisasi ulang data dalam pelanggan dengan data di penerbit.

Anda harus menggunakan replication with scripts untuk menjaga server siaga hangat hanya ketika Anda tidak menerapkan skema perubahan atau Anda tidak menerapkan perubahan lain untuk seperti perubahan keamanan database replikasi yang tidak mendukung.

Catatan Replikasi tidak dirancang untuk pemeliharaan hangat siaga server. Dengan replikasi, Anda dapat menggunakan data replikasi di pelanggan menghasilkan laporan. Anda juga dapat menggunakan replikasi untuk kegunaan umum lain tanpa harus melakukan pemrosesan pada penerbit relatif sibuk.

Keuntungan dan kerugian dari penggunaan replication with scripts

Keuntungan

• Anda dapat membaca data pelanggan sementara Anda menerapkan perubahan.
• Perubahan diterapkan dengan latensi kurang.
  
  Catatan Keuntungan ini mungkin tidak sahih jika baik berikut ini benar:
  • Replikasi agen tidak diatur ke berkesinambungan.
  • Replikasi agen berhenti karena kesalahan yang mungkin terjadi selama replikasi.

Replication with scripts mungkin memerlukan waktu lebih lama untuk menerapkan perubahan karena besar batch update harus dilakukan selama replikasi.

Kerugian

• Skema perubahan atau perubahan keamanan yang dilakukan di penerbit setelah mendirikan replikasi tidak akan tersedia di pelanggan.
• Distributor di replication with scripts menggunakan terbuka koneksi pangkalan data konektivitas (ODBC) atau sambungan OLE Database (OLEDB) untuk mendistribusikan data. Namun, log pengiriman menggunakan transaksi MEMULIHKAN tingkat rendah Transact-SQL pernyataan untuk mendistribusikan log transaksi. gulung balik TRANSAKSI pernyataan jauh lebih cepat daripada koneksi ODBC atau OLEDB sambungan.
• Biasanya, beralih server menghapus replikasi konfigurasi. Oleh karena itu, Anda harus mengkonfigurasi replikasi dua kali:
  Ketika Anda beralih ke pelanggan.
  Ketika Anda beralih kembali ke penerbit.
• Jika bencana terjadi, Anda harus secara manual beralih server oleh mengarahkan semua aplikasi ke pelanggan.

Untuk informasi lebih lanjut tentang replikasi, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:

Untuk men-download versi terbaru dari SQL Server 2000 buku Online, kunjungi Web site Microsoft berikut:Untuk informasi lebih lanjut tentang pilihan pemulihan bencana lain, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang failover clustering, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang pencadangan dan pemulihan fitur, kunjungi Web site Microsoft berikut:Untuk informasi lebih lanjut tentang fitur pencadangan dan pemulihan, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang teks lengkap katalog folder dan file, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft: