Keterangan tentang opsi pemulihan bencana untuk Microsoft SQL Server

Terjemahan Artikel Terjemahan Artikel
ID Artikel: 822400 - Melihat produk di mana artikel ini berlaku.
Perbesar semua | Perkecil semua

Pada Halaman ini

RINGKASAN

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:
259267Microsoft Cluster layanan Instalasi sumber daya

Keuntungan dan kerugian dari penggunaan failover clustering

Keuntungan
Anda memiliki ketersediaan tinggi server. Failover clustering secara otomatis terjadi jika server utama gagal.
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:
.aspx http://msdn2.Microsoft.com/en-us/library/aa174512 (SQL.80)
Untuk informasi lebih lanjut tentang failover clustering, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
243218Instalasi agar SQL Server 2000 Enterprise Edition pada Microsoft Cluster Server
822250 Dukungan WebCast: Microsoft SQL Server 2000 failover clustering prosedur pemulihan bencana
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:
327518Kebijakan dukungan Microsoft untuk SQL Server failover cluster

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:
323135Microsoft SQL Server 2000 - cara mengatur log pengiriman (putih)
325220 Dukungan WebCast: Microsoft SQL Server 2000 log pengiriman
Untuk informasi lebih lanjut tentang pengiriman log, kunjungi Web site Microsoft berikut:
.aspx http://msdn2.Microsoft.com/en-us/library/aa213785 (SQL.80)

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:
195757pertanyaan yang sering diajukan - SQL Server 7.0 - replikasi

pencadangan dan pemulihan fitur

pencadangan dan pemulihan fitur SQL Server menyediakan penting menjaga untuk membantu melindungi data penting yang Anda menyimpan di SQL Server database. Anda dapat membuat kopi karbon database (salinan cadangan) dengan menggunakan cadangan dan Memulihkan fitur, dan kemudian menyimpan kopi karbon 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 kemudian dapat menggunakan kopi rekam cadang 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 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 pencadangan dan pemulihan hanya untuk non-misi-kritis database aplikasi.

Keuntungan dan kerugian dari penggunaan pencadangan dan pemulihan fitur

Keuntungan
  • Anda dapat membuat database ke 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 Daftar 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 pencadangan dan pemulihan di produksi lingkungan, terbaik untuk menguji secara menyeluruh prosedur ini di tes lingkungan.

Untuk informasi lebih lanjut tentang fitur pencadangan dan pemulihan, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
325257Dukungan WebCast: SQL Database Server 2000 pemulihan: pencadangan dan pemulihan
281122 Deskripsi memulihkan backup file dan filegroup dalam SQL Server
Untuk informasi lebih lanjut tentang pencadangan dan pemulihan fitur, kunjungi Web site Microsoft berikut:
.aspx http://msdn2.Microsoft.com/en-us/library/aa196617 (SQL.80)
.aspx http://msdn2.Microsoft.com/en-us/library/aa196685 (SQL.80)
.aspx http://msdn2.Microsoft.com/en-us/library/aa178143 (SQL.80)

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 beberapa disk kegagalan terjadi, data tidak dapat dipulihkan. Oleh karena itu, Microsoft menyarankan agar Anda menggabungkan manajemen data berlebihan dengan prosedur pencadangan dan pemulihan 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 yang 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-sama dengan data. Ketika setiap satu disk gagal, parity bit dapat digunakan untuk menghitung data 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
Anda tidak kehilangan data jika setiap satu disk gagal.
Kerugian
  • Mungkin diperlukan 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 berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
100110Ikhtisar berlebihan array disk murah (RAID)

REFERENSI

Untuk men-download versi terbaru dari SQL Server 2000 buku Online, kunjungi Web site Microsoft berikut:
http://www.Microsoft.com/downloads/details.aspx?FamilyID=8E2DFC8D-C20E-4446-99A9-B7F0213F8BC5
Untuk informasi lebih lanjut tentang pilihan pemulihan bencana lain, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
307775Disaster recovery artikel untuk Microsoft SQL Server
Untuk informasi lebih lanjut tentang failover clustering, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
195761pertanyaan yang sering diajukan - SQL Server 7.0 - Failover
260758 pertanyaan yang sering diajukan - SQL Server 2000 - Failover clustering
274446 Upgrade ke SQL Server 2000 failover solusi yang direkomendasikan untuk semua non - SQL Server 2000 virtual server
280743 Windows clustering dan secara geografis terpisah situs
Untuk informasi lebih lanjut tentang pencadangan dan pemulihan fitur, kunjungi Web site Microsoft berikut:
http://technet.Microsoft.com/en-us/library/cc966495.aspx
Untuk informasi lebih lanjut tentang fitur pencadangan dan pemulihan, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
253817Cara membuat cadangan log transaksi terakhir ketika master dan file database rusak di SQL Server
314546 Bagaimana memindahkan database antara komputer yang menjalankan SQL Server
Untuk informasi lebih lanjut tentang teks lengkap katalog folder dan file, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
240867Bagaimana untuk memindahkan, menyalin, dan cadangan teks lengkap katalog folder dan file

Properti

ID Artikel: 822400 - Kajian Terakhir: 03 Juli 2012 - Revisi: 3.0
Berlaku bagi:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Standard Edition
Kata kunci: 
kbdisasterrec kbreplication kbreplmgr kbclustering kbinfo kbmt KB822400 KbMtid
Penerjemahan Mesin
PENTING: Artikel ini diterjemahkan menggunakan perangkat lunak mesin penerjemah Microsoft dan bukan oleh seorang penerjemah. Microsoft menawarkan artikel yang diterjemahkan oleh seorang penerjemah maupun artikel yang diterjemahkan menggunakan mesin sehingga Anda akan memiliki akses ke seluruh artikel baru yang diterbitkan di Pangkalan Pengetahuan (Knowledge Base) dalam bahasa yang Anda gunakan. Namun, artikel yang diterjemahkan menggunakan mesin tidak selalu sempurna. Artikel tersebut mungkin memiliki kesalahan kosa kata, sintaksis, atau tata bahasa, hampir sama seperti orang asing yang berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab terhadap akurasi, kesalahan atau kerusakan yang disebabkan karena kesalahan penerjemahan konten atau penggunaannya oleh para pelanggan. Microsoft juga sering memperbarui perangkat lunak mesin penerjemah.
Klik disini untuk melihat versi Inggris dari artikel ini: 822400

Berikan Masukan

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com