Keterangan tentang opsi pemulihan bencana untuk Microsoft SQL Server

Artikel ini membahas berbagai solusi untuk memulihkan data dari Microsoft SQL Server database, 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 di 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 perangkat keras atau perangkat 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 dari 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 di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:

Keuntungan dan kerugian dari penggunaan failover clustering

Keuntungan

Kerugian

• Anda dikenakan biaya yang lebih besar. Pemeliharaan dua server adalah dua kali biaya pemeliharaan server tunggal. Karena Anda harus menjaga dua server pada saat yang sama, lebih mahal untuk menginstal dan mempertahankan berkerumun node.
• Server harus berada di lokasi yang sama. Jika 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 cluster server perangkat. Oleh karena itu, meskipun itu mungkin, terbaik untuk tidak menggunakan secara 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 tabel tingkat.

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

Database mirroring

Database mirroring terutama solusi perangkat lunak untuk meningkatkan ketersediaan database. Anda hanya dapat menerapkan mencerminkan 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 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 sisanya berisi salinan identik dari data.

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

Keuntungan

• Baca kinerja meningkat karena Anda dapat tersebar aktivitas semua node.
• Menggabungkan kinerja pembaruan, 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 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 tipe sinkronisasi berlangganan replikasi dukungan 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
• Transactional 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 pada 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 update 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 meja dan views. Itu juga termasuk perubahan keamanan seperti pengguna baru yang diciptakan dan setiap izin perubahan.
• Anda dapat mengembalikan 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 tabel dan menolak perubahan yang tersisa.
• Ada tidak otomatis failover aplikasi. Ketika server utama gagal karena dari bencana, server siaga tidak Failover secara otomatis. Oleh karena itu, Anda harus secara eksplisit redirect 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 di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang pengiriman log, kunjungi Web site Microsoft berikut:

Transactional replication with scripts

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

Anda dapat berlangganan mendorong untuk menegakkan Transactional replication with scripts antara dua server dengan server utama sebagai penerbit dan server siaga sebagai pelanggan. Transactional 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 transactional replication with scripts untuk menjaga server siaga hangat hanya ketika Anda tidak menerapkan skema perubahan atau Anda tidak menerapkan perubahan lain ke database seperti perubahan keamanan replikasi yang tidak mendukung.

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

Keuntungan dan kerugian dari penggunaan transactional replication with scripts

Keuntungan

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

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

Kerugian

• Skema perubahan atau keamanan perubahan yang dilakukan di penerbit setelah mendirikan replikasi tidak akan tersedia di pelanggan.
• Distributor di transactional replication with scripts menggunakan terbuka Koneksi database 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. MENGEMBALIKAN 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 di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:

Backup dan restore fitur

Backup dan Restore fitur SQL Server menyediakan penting menjaga untuk membantu melindungi data penting yang Anda menyimpan dalam SQL Server database. Anda dapat membuat salinan database (salinan cadangan) dengan menggunakan cadangan dan Memulihkan fitur, dan kemudian menyimpan salinan database di lokasi yang dilindungi dari kegagalan server yang menjalankan contoh dari potensi SQL Server. Jika Anda mengalami kegagalan sistem database atau database korupsi, Anda dapat menggunakan salinan cadangan untuk kembali menciptakan database atau untuk memulihkan database.

Ketika Anda rencana pemulihan bencana dengan menggunakan cadangan dan Memulihkan fitur, juga menentukan bagaimana kritis data dalam database. Selain itu, menentukan persyaratan pemulihan untuk database. Untuk contoh, menentukan persyaratan restorasi berikut:

• Titik yang Anda memulihkan database untuk. Anda harus memutuskan yang berikut dua Anda ingin melakukan:
  Memulihkan database untuk kondisi malam sebelum kegagalan.
  Memulihkan database untuk kondisi titik waktu sedekat mungkin ke waktu dari kegagalan.
• Berapa lama database dapat menjadi tidak tersedia. Apakah Anda harus memulihkan database segera.

Setelah Anda menentukan persyaratan pemulihan, Anda dapat merencanakan cadangan proses yang mempertahankan seperangkat backup untuk memenuhi persyaratan

Anda hanya dapat memulihkan database untuk kondisi titik waktu di mana Anda melakukan backup terbaru. Transaksi yang terjadi setelah cadangan yang mungkin hilang. Oleh karena itu, Microsoft menyarankan Anda menggunakan fitur Backup dan Restore hanya untuk non-misi-kritis database aplikasi.

Keuntungan dan kerugian dari penggunaan Backup dan restore fitur

Keuntungan

• Anda dapat membuat database untuk media yang dapat dipindahkan untuk membantu melindungi terhadap kegagalan disk.
• Anda tidak harus bergantung pada jaringan seperti yang Anda lakukan ketika Anda menggunakan failover clustering atau log pengiriman.

Kerugian

• Ketika Anda membuat cadangan database, Anda tidak dapat melakukan operasi seperti tabel penciptaan, penciptaan indeks database menyusut, atau nonlogged operasi.
• Jika terjadi kegagalan, Anda mungkin kehilangan data terbaru.
• Jika bencana terjadi, Anda harus secara manual memulihkan database.

Catatan Sebelum Anda menggunakan prosedur Backup dan Restore di produksi lingkungan, terbaik untuk menguji secara menyeluruh prosedur ini di tes lingkungan.

Untuk informasi lebih lanjut tentang fitur Backup dan Restore, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang Backup dan Restore fitur, kunjungi Web site Microsoft berikut:

Disk redundansi data dengan menggunakan array yang berlebihan independen disk (RAID)

SERANGAN menyimpan data berlebihan di beberapa disk untuk menyediakan lebih besar keandalan dan kurang downtime untuk server. Tingkat RAID 0, 1, dan 5 umumnya digunakan sebagai opsi pemulihan untuk SQL Server. RAID teknologi yang disebutkan memungkinkan kegagalan dan penggantian akibat satu disk tanpa server akan offline. Jika terjadi beberapa disk kegagalan, data tidak dapat dipulihkan. Oleh karena itu, Microsoft menyarankan agar Anda menggabungkan manajemen data berlebihan dengan prosedur Backup dan Restore untuk membantu memastikan bahwa bahwa Anda tidak kehilangan data jika hardware kegagalan atau bencana lain terjadi.

RAID 0 menggunakan striping teknologi untuk akses cepat sedangkan RAID 1 menggunakan teknologi mirroring untuk kehandalan data. Teknik umum yang digunakan dalam manajemen basis data relasional melibatkan menggunakan RAID 0 dan RAID 1 bersama-sama. Dalam teknik ini, dua identik bergaris array drive terus-menerus diperbarui sehingga informasi yang disimpan di kedua array adalah sama. Jika satu array gagal, array lain secara otomatis mengambil alih sampai array asli dibawa kembali online.

RAID 5 (juga dikenal sebagai striping dengan keseimbangan) menggunakan array satu bergaris disk dengan bit paritas ditulis bersama data. Ketika disk satu gagal, parity bit dapat digunakan untuk menghitung data yang hilang sampai Anda mengganti disk. Ketika Anda mengganti disk, Anda dapat menggunakan paritas informasi dan data yang tersisa untuk menciptakan kembali data dari gagal disk dan menyalin data dibuat ulang ke disk baru. Semua ini operasi terjadi tanpa downtime sistem database. SERANGAN menyediakan banyak lainnya pilihan dan fitur bagi Anda untuk membantu memastikan bahwa sistem database Anda pengalaman sebagai sedikit downtime mungkin.

Keuntungan dan kerugian dari penggunaan RAID

Keuntungan

Kerugian

• Mungkin butuh waktu lama untuk memulihkan data.
• Jika multi disk gagal, Anda mungkin tidak dapat memulihkan data yang berharga.

Untuk informasi lebih lanjut tentang serangan, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis 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 di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang failover clustering, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang Backup dan Restore fitur, kunjungi Web site Microsoft berikut:Untuk informasi lebih lanjut tentang fitur Backup dan Restore, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang teks lengkap katalog folder dan file, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft: