Tanya Jawab Umum untuk Administrator Replikasi

Berlaku untuk: SQL ServerAzure SQL Managed Instance

Pertanyaan dan jawaban berikut memberikan panduan tentang berbagai tugas yang dihadapi oleh administrator database yang direplikasi.

Mengonfigurasi Replikasi

Apakah aktivitas perlu dihentikan pada database saat diterbitkan?

Tidak. Aktivitas dapat berlanjut pada database saat publikasi sedang dibuat. Ketahuilah bahwa memproduksi rekam jepret dapat intensif sumber daya, jadi yang terbaik adalah menghasilkan rekam jepret selama periode aktivitas yang lebih rendah pada database (secara default rekam jepret dihasilkan saat Anda menyelesaikan Wizard Publikasi Baru).

Apakah tabel terkunci selama pembuatan rekam jepret?

Lamanya waktu kunci diambil tergantung pada jenis replikasi yang digunakan:

• Untuk publikasi gabungan, Agen Rekam Jepret tidak mengambil kunci apa pun.

• Untuk publikasi transaksional, secara default Agen Rekam Jepret hanya mengambil kunci selama fase awal pembuatan rekam jepret.

• Untuk publikasi rekam jepret, Agen Rekam Jepret mengambil kunci selama seluruh proses pembuatan rekam jepret.

Karena kunci mencegah pengguna lain memperbarui tabel, Agen Rekam Jepret harus dijadwalkan untuk dijalankan selama periode aktivitas yang lebih rendah pada database, terutama untuk publikasi rekam jepret.

Kapan langganan tersedia; kapan database langganan dapat digunakan?

Langganan tersedia setelah snapshot diterapkan ke database langganan. Meskipun database langganan dapat diakses sebelum ini, database tidak boleh digunakan sampai setelah rekam jepret diterapkan. Gunakan Monitor Replikasi untuk memeriksa status pembuatan rekam jepret dan aplikasi:

• Rekam jepret dihasilkan oleh Agen Rekam Jepret. Lihat status pembuatan rekam jepret pada tab Agen untuk publikasi di Monitor Replikasi. Untuk informasi selengkapnya, lihat Lihat informasi dan lakukan tugas menggunakan Monitor Replikasi.

• Rekam jepret diterapkan oleh Agen Distribusi atau Agen Penggabungan. Lihat status aplikasi rekam jepret di halaman Agen Distribusi atau Agen Penggabungan pada Monitor Replikasi. Untuk informasi selengkapnya, lihat Melihat informasi dan melakukan tugas menggunakan Replikasi Monitor.

Apa yang terjadi jika Agen Rekam Jepret belum selesai saat Agen Distribusi atau Penggabungan dimulai?

Ini tidak akan menyebabkan kesalahan jika Agen Distribusi atau Agen Penggabungan berjalan pada saat yang sama dengan Agen Rekam Jepret. Namun, Anda harus mengetahui hal-hal berikut:

• Jika Agen Distribusi atau Agen Penggabungan dikonfigurasi untuk berjalan terus-menerus, agen menerapkan snapshot secara otomatis setelah Snapshot Agent selesai.

• Jika Agen Distribusi atau Agen Penggabungan dikonfigurasi untuk berjalan sesuai jadwal atau sesuai permintaan, dan tidak ada rekam jepret yang tersedia saat agen berjalan, agen akan dimatikan dengan pesan yang menyatakan bahwa rekam jepret belum tersedia. Anda harus menjalankan agen lagi untuk menerapkan rekam jepret setelah Agen Rekam Jepret selesai. Untuk informasi selengkapnya tentang menjalankan agen, lihat Menyinkronkan Langganan Push, Menyinkronkan Langganan Pull, dan Konsep Executable Agen Replikasi.

Haruskah saya membuat skrip konfigurasi replikasi saya?

Ya. Membuat skrip konfigurasi replikasi adalah bagian penting dari rencana pemulihan bencana apa pun untuk topologi replikasi. Untuk informasi selengkapnya tentang pembuatan skrip, lihat Scripting Replication.

Model pemulihan apa yang diperlukan pada database yang direplikasi?

Replikasi berfungsi dengan baik menggunakan salah satu model pemulihan: sederhana, bulk-logged, atau penuh. Replikasi gabungan melacak perubahan dengan menyimpan informasi dalam tabel metadata. Replikasi transaksional melacak perubahan dengan menandai log transaksi, tetapi proses penandaan ini tidak terpengaruh oleh model pemulihan.

Mengapa replikasi menambahkan kolom ke tabel yang direplikasi; apakah tabel tersebut akan dihapus jika tabel tidak diterbitkan?

Untuk melacak perubahan, replikasi penggabungan dan replikasi transaksional dengan langganan pembaruan antrean harus dapat mengidentifikasi setiap baris secara unik di setiap tabel yang diterbitkan. Untuk mencapai hal ini:

• Replikasi penggabungan menambahkan kolom rowguid pada setiap tabel, kecuali tabel sudah memiliki kolom bertipe data uniqueidentifier dengan properti ROWGUIDCOL telah disetel (dalam hal ini kolom tersebut digunakan). Jika tabel dihilangkan dari publikasi, kolom rowguid dihapus; jika kolom yang ada digunakan untuk pelacakan, kolom tidak dihapus.

• Jika publikasi transaksional mendukung pembaruan langganan antrean, replikasi menambahkan kolom msrepl_tran_version ke setiap tabel. Jika tabel dihilangkan dari publikasi, kolom msrepl_tran_version tidak dihapus.

• Filter tidak boleh menyertakan rowguidcol yang digunakan oleh replikasi untuk mengidentifikasi baris. Secara default ini adalah kolom yang ditambahkan pada saat Anda menyiapkan replikasi penggabungan dan diberi nama rowguid.

Bagaimana cara mengelola batasan pada tabel yang diterbitkan?

Ada sejumlah masalah yang perlu dipertimbangkan mengenai batasan pada tabel yang diterbitkan:

• Replikasi transaksional memerlukan batasan kunci utama pada setiap tabel yang diterbitkan. Replikasi penggabungan tidak memerlukan kunci primer, tetapi jika ada, kunci tersebut harus direplikasi. Replikasi rekam jepret tidak memerlukan kunci primer.

• Secara default, batasan kunci utama, indeks, dan batasan pemeriksaan direplikasi ke Pelanggan.

• Opsi NOT FOR REPLICATION ditentukan secara default untuk batasan kunci asing dan batasan cek; batasan diberlakukan untuk operasi pengguna tetapi tidak untuk operasi agen.

Untuk informasi tentang mengatur opsi skema yang mengontrol apakah batasan direplikasi, lihat Menentukan Opsi Skema.

Bagaimana cara mengelola kolom identitas?

Replikasi menyediakan manajemen rentang identitas otomatis untuk topologi replikasi yang menyertakan pembaruan di Pengikut. Untuk informasi selengkapnya, lihat Mereplikasi Kolom Identitas.

Dapatkah objek yang sama diterbitkan dalam publikasi yang berbeda?

Ya, tapi dengan beberapa batasan. Untuk informasi selengkapnya, lihat bagian "Menerbitkan Tabel di Lebih dari Satu Publikasi" dalam topik Menerbitkan Data dan Objek Database.

Bisakah beberapa publikasi menggunakan database distribusi yang sama?

Ya. Tidak ada batasan jumlah atau jenis publikasi yang dapat menggunakan database distribusi yang sama. Semua publikasi dari Penerbit tertentu harus menggunakan database Distributor dan distribusi yang sama.

Jika Anda memiliki beberapa publikasi, Anda dapat mengonfigurasi beberapa database distribusi di Distributor untuk memastikan bahwa data yang mengalir melalui setiap database distribusi berasal dari satu publikasi. Gunakan kotak dialog Properti Distributor atau sp_adddistributiondb (Transact-SQL) untuk menambahkan database distribusi. Untuk informasi selengkapnya tentang mengakses kotak dialog, lihat Menampilkan dan Mengubah Properti Distributor dan Penerbit.

Bagaimana cara menemukan informasi tentang Distributor dan Penerbit, seperti objek mana dalam database yang diterbitkan?

Informasi ini tersedia melalui SQL Server Management Studio, dan sejumlah prosedur tersimpan replikasi. Untuk informasi selengkapnya, lihat Skrip Informasi Distributor dan Penerbit.

Apakah replikasi mengenkripsi data?

Tidak. Replikasi tidak mengenkripsi data yang disimpan dalam database atau ditransfer melalui jaringan. Untuk informasi selengkapnya, lihat bagian "Enkripsi" dari topik Tampilkan dan ubah pengaturan keamanan replikasi.

Bagaimana cara mereplikasi data melalui Internet?

Replikasi data melalui Internet menggunakan:

• Jaringan Privat Virtual (VPN - Virtual Private Network). Untuk informasi selengkapnya, lihat Menerbitkan Data melalui Internet Menggunakan VPN.

• Opsi Sinkronisasi web untuk replikasi penggabungan. Untuk informasi selengkapnya, lihat Sinkronisasi Web untuk Replikasi Penggabungan.

Semua jenis replikasi Microsoft SQL Server dapat mereplikasi data melalui VPN, tetapi Anda harus mempertimbangkan sinkronisasi Web jika Anda menggunakan replikasi penggabungan.

Apakah replikasi dilanjutkan jika koneksi terputus

Ya. Pemrosesan replikasi dilanjutkan pada titik yang ditinggalkannya jika koneksi terputus. Jika Anda menggunakan replikasi penggabungan melalui jaringan yang tidak dapat diandalkan, pertimbangkan untuk menggunakan rekaman logis, yang memastikan perubahan terkait diproses sebagai unit. Untuk informasi selengkapnya, lihat Kelompokkan Perubahan pada Baris Terkait dengan Catatan Logis.

Apakah replikasi berfungsi melalui koneksi bandwidth rendah? Apakah menggunakan kompresi?

Ya, replikasi bekerja melalui koneksi bandwidth rendah. Untuk koneksi melalui TCP/IP, ia menggunakan kompresi yang disediakan oleh protokol tetapi tidak memberikan pemadatan tambahan. Untuk koneksi sinkronisasi Web melalui HTTPS, ia menggunakan kompresi yang disediakan oleh protokol dan juga pemadatan tambahan file XML yang digunakan untuk mereplikasi perubahan.

Dapatkah saya mengonfigurasi replikasi jika saya tersambung ke server dengan menggunakan alamat IP?

Tidak, replikasi hanya berfungsi saat Anda menggunakan nama server yang sebenarnya. Dimulai di SQL Server Management Studio (SSMS) 18.0 (dan versi yang lebih baru), replikasi dapat dikonfigurasi dengan menggunakan nama server dan nomor port yang sebenarnya.

Login dan Kepemilikan Objek

Apakah login dan kata sandi direplikasi?

Tidak. Anda dapat membuat paket SSIS untuk mentransfer login dan kata sandi dari Penerbit ke satu atau beberapa Pelanggan.

Apa itu skema dan bagaimana mereka direplikasi?

Dimulai dengan Microsoft SQL Server 2005 (9.x), skema memiliki dua arti:

• Definisi objek, seperti CREATE TABLE pernyataan. Secara bawaan, replikasi menyalin definisi semua objek yang direplikasi ke Subskriptor.

• Namespace tempat objek dibuat: <Database>.<Skema>.<Objek>. Skema didefinisikan menggunakan CREATE SCHEMA pernyataan .

• Replikasi memiliki perilaku default berikut di Wizard Publikasi Baru sehubungan dengan skema dan kepemilikan objek:

• Untuk artikel dalam publikasi gabungan dengan tingkat kompatibilitas 90 atau lebih tinggi, publikasi rekam jepret, dan publikasi transaksi: secara default, pemilik objek di Pelanggan sama dengan pemilik objek yang sesuai di Penerbit. Jika skema yang memiliki objek tidak ada di Subscriber, skema tersebut dibuat secara otomatis.

• Untuk artikel dalam publikasi gabungan dengan tingkat kompatibilitas yang lebih rendah dari 90: secara default, pemilik dibiarkan kosong dan ditentukan sebagai dbo selama pembuatan objek pada Subscriber.

• Untuk artikel dalam publikasi Oracle: secara default, pemilik ditentukan sebagai dbo.

• Untuk artikel dalam publikasi yang menggunakan cuplikan mode karakter (yang digunakan untuk Pelanggan SQL Server non-SQL dan Pelanggan SQL Server Compact): secara default, pemilik dibiarkan kosong. Pemilik secara otomatis ditetapkan ke pemilik yang berhubungan dengan akun yang digunakan oleh Agen Distribusi atau Agen Penggabungan untuk terhubung ke Subscriber.

Pemilik objek dapat diubah melalui kotak dialog Properti Artikel - Artikel> dan melalui prosedur tersimpan berikut: sp_addarticle, sp_addmergearticle, sp_changearticle, dan sp_changemergearticle. Untuk informasi selengkapnya, lihat Menampilkan dan Mengubah Properti Publikasi, Menentukan Artikel, serta Menampilkan dan Mengubah Properti Artikel.

Bagaimana pemberian pada database langganan dikonfigurasi agar sesuai dengan pemberian pada database publikasi?

Secara default, replikasi tidak menjalankan pernyataan GRANT pada database langganan. Jika Anda ingin izin pada database langganan cocok dengan yang ada di database publikasi, gunakan salah satu metode berikut:

• Jalankan perintah GRANT langsung di database langganan.

• Gunakan skrip pasca-rekam jepret untuk menjalankan pernyataan. Untuk informasi selengkapnya, lihat Menjalankan Skrip Sebelum dan Sesudah Rekam Jepret Diterapkan.

• Gunakan prosedur tersimpan sp_addscriptexec untuk menjalankan pernyataan.

Apa yang terjadi pada izin yang diberikan dalam database langganan jika langganan diinisialisasi ulang?

Secara default, objek pada Subscriber dihilangkan dan dibuat ulang ketika berlangganan diinisialisasi ulang, yang menyebabkan semua izin yang diberikan untuk objek-objek tersebut menjadi batal. Ada dua cara untuk menangani hal ini:

• Terapkan kembali pemberian setelah reinisialisasi menggunakan teknik yang dijelaskan di bagian sebelumnya.

• Tentukan bahwa objek tidak boleh dihilangkan saat langganan diinisialisasi ulang. Sebelum reinisialisasi, entah:

  • Jalankan sp_changearticle atau sp_changemergearticle. Tentukan nilai 'pre_creation_cmd' (sp_changearticle) atau 'pre_creation_command' (sp_changemergearticle) untuk parameter @property dan nilai 'none', 'delete' atau 'truncate' untuk parameter @value.

  • Dalam kotak dialog Properti Artikel - <Artikel> di bagian Objek Tujuan, pilih nilai Pertahankan objek yang ada tidak berubah, Hapus data. Jika artikel memiliki filter baris, hapus hanya data yang cocok dengan filter. atau Potong semua data di objek yang ada untuk opsi Tindakan jika nama sedang digunakan. Untuk informasi selengkapnya tentang mengakses kotak dialog ini, lihat Menampilkan dan Mengubah Properti Publikasi.

Pemeliharaan Database

Mengapa saya tidak bisa menjalankan TRUNCATE TABLE pada tabel yang diterbitkan?

TRUNCATE TABLE adalah pernyataan DDL yang tidak mencatat penghapusan baris individual dan tidak mengaktifkan pemicu DML. Ini tidak diizinkan karena replikasi tidak dapat melacak perubahan yang disebabkan oleh operasi: replikasi transaksional melacak perubahan melalui log transaksi; gabungkan replikasi melacak perubahan melalui pemicu DML pada tabel yang diterbitkan.

Apa efek menjalankan perintah sisipkan massal pada database yang direplikasi?

Untuk replikasi transaksional, penyisipan massal dilacak dan direplikasi seperti penyisipan lainnya. Untuk replikasi penggabungan, Anda harus memastikan bahwa metadata pelacakan perubahan diperbarui dengan benar.

Apakah ada pertimbangan replikasi untuk pencadangan dan pemulihan?

Ya. Ada sejumlah pertimbangan khusus untuk database yang terlibat dalam replikasi. Untuk informasi selengkapnya, lihat Mencadangkan dan Memulihkan Database yang Direplikasi.

Apakah replikasi memengaruhi ukuran log transaksi?

Replikasi gabungan dan replikasi snapshot tidak memengaruhi ukuran log transaksi, tetapi replikasi transaksional bisa memengaruhi. Jika database menyertakan satu atau beberapa publikasi transaksional, log tidak dipotong sampai semua transaksi yang relevan dengan publikasi telah dikirimkan ke database distribusi. Jika log transaksi tumbuh terlalu besar, dan Agen Pembaca Log berjalan secara terjadwal, pertimbangkan untuk mempersingkat interval antara eksekusi. Atau, atur untuk berjalan dalam mode berkelanjutan. Jika diatur untuk berjalan dalam mode berkelanjutan (default), pastikan dijalankan. Untuk informasi lebih lanjut tentang memeriksa informasi status Agen Pembaca Log, lihat bagian Menampilkan informasi dan melakukan tugas menggunakan Monitor Replikasi.

Selain itu, jika Anda telah mengatur opsi 'sinkronkan dengan cadangan' pada database publikasi atau database distribusi, log transaksi tidak terpotong sampai semua transaksi telah dicadangkan. Jika log transaksi tumbuh terlalu besar, dan Anda memiliki opsi ini yang ditetapkan, pertimbangkan untuk mempersingkat interval antara cadangan log transaksi. Untuk informasi selengkapnya tentang mencadangkan dan memulihkan database yang terlibat dalam replikasi transaksional, lihat Strategi untuk Mencadangkan dan Memulihkan Snapshot dan Replikasi Transaksional.

Bagaimana cara membangun ulang indeks atau tabel dalam database yang direplikasi?

Ada berbagai mekanisme untuk membangun kembali indeks. Semuanya dapat digunakan tanpa pertimbangan khusus untuk replikasi, dengan pengecualian berikut: kunci primer diperlukan pada tabel dalam publikasi transaksional, sehingga Anda tidak dapat menghilangkan dan membuat ulang kunci utama pada tabel ini.

Bagaimana cara menambahkan atau mengubah indeks pada database publikasi dan langganan?

Indeks dapat ditambahkan di Penerbit atau Pelanggan tanpa pertimbangan khusus untuk replikasi (ketahuilah bahwa indeks dapat memengaruhi performa). CREATE INDEX dan ALTER INDEX tidak direplikasi, jadi jika Anda menambahkan atau mengubah indeks di, misalnya, Penerbit, Anda harus membuat penambahan atau perubahan yang sama di Pelanggan jika Anda ingin indeks tercermin di sana.

Bagaimana cara memindahkan atau mengganti nama file untuk database yang terlibat dalam replikasi?

Dalam versi SQL Server sebelum SQL Server 2005 (9.x), memindahkan atau mengganti nama file database diperlukan untuk melepaskan dan memasang kembali database. Karena database yang direplikasi tidak dapat dilepaskan, replikasi harus dihapus dari database ini terlebih dahulu. Dimulai dengan SQL Server 2005 (9.x), Anda dapat memindahkan atau mengganti nama file tanpa melepaskan dan melampirkan ulang database, tanpa berpengaruh pada replikasi. Untuk informasi selengkapnya tentang memindahkan dan mengganti nama file, lihat MENGUBAH DATABASE (Transact-SQL).

Bagaimana cara menghilangkan tabel yang sedang direplikasi?

Pertama-tama hapus artikel dari publikasi menggunakan sp_droparticle, sp_dropmergearticle, atau kotak dialog Publication Properties - <Publication>, dan kemudian hapus dari database menggunakan DROP <Object>. Anda tidak dapat menghapus artikel dari rekam jepret atau publikasi transaksi setelah langganan ditambahkan; Anda harus menghilangkan langganan terlebih dahulu. Untuk informasi selengkapnya, lihat Menambahkan Artikel ke dan Menghapus Artikel dari Publikasi yang Ada.

Bagaimana cara menambahkan atau meletakkan kolom pada tabel yang diterbitkan?

SQL Server mendukung berbagai perubahan skema pada objek yang diterbitkan, termasuk menambahkan dan menghilangkan kolom. Misalnya, jalankan ALTER TABLE … DROP COLUMN di Publisher, dan pernyataan direplikasi ke Subscriber lalu dijalankan untuk menghapus kolom. Pelanggan yang menjalankan versi SQL Server sebelum SQL Server 2005 (9.x) mendukung penambahan dan penurunan kolom melalui prosedur tersimpan sp_repladdcolumn dan sp_repldropcolumn. Untuk informasi selengkapnya, lihat Membuat Perubahan Skema pada Database Publikasi.

Pemeliharaan Replikasi

Bagaimana cara menentukan apakah data di Pelanggan disinkronkan dengan data di Publisher?

Gunakan validasi. Laporan validasi tentang apakah Penerima tertentu disinkronkan dengan Penerbit. Untuk informasi selengkapnya, lihat Memvalidasi Data yang Direplikasi. Validasi tidak memberikan informasi tentang baris mana, jika ada, yang tidak disinkronkan dengan benar, tetapi utilitas tablediff melakukannya.

Bagaimana cara menambahkan tabel ke publikasi yang sudah ada?

Tidak perlu menghentikan aktivitas pada database publikasi atau langganan untuk menambahkan tabel (atau objek lain). Tambahkan tabel ke publikasi melalui kotak dialog Publication Properties - <Publication> atau prosedur tersimpan sp_addarticle dan sp_addmergearticle. Untuk informasi selengkapnya, lihat Menambahkan Artikel ke dan Menghapus Artikel dari Publikasi yang Ada.

Bagaimana cara menghapus tabel dari publikasi?

Hapus tabel dari publikasi menggunakan sp_droparticle, sp_dropmergearticle, atau kotak dialog Pengaturan Publikasi - Publikasi. Anda tidak dapat menghapus artikel dari rekam jepret atau publikasi transaksi setelah langganan ditambahkan; Anda harus menghilangkan langganan terlebih dahulu. Untuk informasi selengkapnya, lihat Menambahkan Artikel ke dan Menghapus Artikel dari Publikasi yang Ada.

Tindakan apa yang mengharuskan langganan diinisialisasi ulang?

Ada sejumlah perubahan artikel dan publikasi yang mengharuskan langganan diinisialisasi ulang. Untuk informasi selengkapnya, lihat Mengubah Properti Publikasi dan Artikel.

Tindakan apa yang menyebabkan rekam jepret tidak valid?

Ada sejumlah perubahan artikel dan publikasi yang membatalkan rekam jepret dan mengharuskan rekam jepret baru dibuat. Untuk informasi selengkapnya, lihat Mengubah Properti Publikasi dan Artikel.

Bagaimana cara menghapus replikasi?

Tindakan yang diperlukan untuk menghapus replikasi dari database bergantung pada apakah database berfungsi sebagai database publikasi, database langganan, atau keduanya.

Bagaimana cara menentukan apakah ada transaksi atau baris yang akan direplikasi?

Untuk replikasi transaksional, gunakan prosedur tersimpan atau tab Perintah yang Tidak Didistribusikan di Monitor Replikasi. Untuk informasi selengkapnya, lihat Menampilkan Perintah yang Direplikasi dan Informasi Lain di Database Distribusi (Pemrograman Transact-SQL Replikasi) dan Menampilkan informasi dan melakukan tugas menggunakan Monitor Replikasi.

Untuk replikasi penggabungan, gunakan prosedur tersimpan sp_showpendingchanges. Untuk informasi selengkapnya, lihat sp_showpendingchanges (Transact-SQL).

Seberapa tertinggal Agen Distribusi? Haruskah saya menginisialisasi ulang?

Gunakan prosedur tersimpan sp_replmonitorsubscriptionpendingcmds atau tab Perintah yang Tidak Didistribusikan di Monitor Replikasi. Prosedur tersimpan dan tampilan tab:

• Jumlah perintah dalam database distribusi yang belum dikirimkan ke Pelanggan yang dipilih. Perintah terdiri dari satu pernyataan bahasa manipulasi data (DML) Transact-SQL atau satu pernyataan bahasa definisi data (DDL).

• Perkiraan jumlah waktu untuk mengirimkan perintah kepada Pelanggan. Jika nilai ini lebih besar dari jumlah waktu yang diperlukan untuk menghasilkan dan menerapkan snapshot ke Pelanggan, pertimbangkan untuk melakukan inisialisasi ulang pada Pelanggan. Untuk informasi selengkapnya, lihat Menginisialisasi ulang Langganan.

Untuk informasi selengkapnya, lihat sp_replmonitorsubscriptionpendingcmds (Transact-SQL) dan Melihat informasi dan melakukan tugas menggunakan Replication Monitor.

Replikasi dan Fitur Database Lainnya

Apakah replikasi berfungsi bersama dengan pengiriman log dan pencerminan database?

Ya. Untuk informasi selengkapnya, lihat Pengiriman dan Replikasi Log (SQL Server) dan Pencerminan dan Replikasi Database (SQL Server).

Apakah replikasi berfungsi bersama dengan pengklusteran?

Ya. Tidak ada pertimbangan khusus yang diperlukan karena semua data disimpan pada satu set disk pada kluster.

Bagaimana cara memecahkan masalah solusi pihak ketiga berdasarkan replikasi SQL?

Sebaiknya hubungi vendor pihak ketiga untuk masalah apa pun guna menerima dukungan. Umumnya, jika masalah ini diisolasi oleh vendor sebagai masalah replikasi inti yang merupakan bagian dari SQL Server, maka Dukungan Microsoft akan dilibatkan untuk memberikan bantuan lebih lanjut.

Lihat Juga

Praktik Terbaik untuk Administrasi Replikasi

Berlaku untuk: SQL ServerAzure SQL Managed Instance

Pertanyaan dan jawaban berikut memberikan panduan tentang berbagai tugas yang dihadapi oleh administrator database yang direplikasi.

Tidak. Aktivitas dapat berlanjut pada database saat publikasi sedang dibuat. Ketahuilah bahwa memproduksi rekam jepret dapat intensif sumber daya, jadi yang terbaik adalah menghasilkan rekam jepret selama periode aktivitas yang lebih rendah pada database (secara default rekam jepret dihasilkan saat Anda menyelesaikan Wizard Publikasi Baru).

Lamanya waktu kunci diambil tergantung pada jenis replikasi yang digunakan:

• Untuk publikasi gabungan, Agen Rekam Jepret tidak mengambil kunci apa pun.

• Untuk publikasi transaksional, secara default Agen Rekam Jepret hanya mengambil kunci selama fase awal pembuatan rekam jepret.

• Untuk publikasi rekam jepret, Agen Rekam Jepret mengambil kunci selama seluruh proses pembuatan rekam jepret.

Karena kunci mencegah pengguna lain memperbarui tabel, Agen Rekam Jepret harus dijadwalkan untuk dijalankan selama periode aktivitas yang lebih rendah pada database, terutama untuk publikasi rekam jepret.

Langganan tersedia setelah snapshot diterapkan ke database langganan. Meskipun database langganan dapat diakses sebelum ini, database tidak boleh digunakan sampai setelah rekam jepret diterapkan. Gunakan Monitor Replikasi untuk memeriksa status pembuatan rekam jepret dan aplikasi:

• Rekam jepret dihasilkan oleh Agen Rekam Jepret. Lihat status pembuatan rekam jepret pada tab Agen untuk publikasi di Monitor Replikasi. Untuk informasi selengkapnya, lihat Lihat informasi dan lakukan tugas menggunakan Monitor Replikasi.

• Rekam jepret diterapkan oleh Agen Distribusi atau Agen Penggabungan. Lihat status aplikasi rekam jepret di halaman Agen Distribusi atau Agen Penggabungan pada Monitor Replikasi. Untuk informasi selengkapnya, lihat Melihat informasi dan melakukan tugas menggunakan Replikasi Monitor.

Ini tidak akan menyebabkan kesalahan jika Agen Distribusi atau Agen Penggabungan berjalan pada saat yang sama dengan Agen Rekam Jepret. Namun, Anda harus mengetahui hal-hal berikut:

• Jika Agen Distribusi atau Agen Penggabungan dikonfigurasi untuk berjalan terus-menerus, agen menerapkan snapshot secara otomatis setelah Snapshot Agent selesai.

• Jika Agen Distribusi atau Agen Penggabungan dikonfigurasi untuk berjalan sesuai jadwal atau sesuai permintaan, dan tidak ada rekam jepret yang tersedia saat agen berjalan, agen akan dimatikan dengan pesan yang menyatakan bahwa rekam jepret belum tersedia. Anda harus menjalankan agen lagi untuk menerapkan rekam jepret setelah Agen Rekam Jepret selesai. Untuk informasi selengkapnya tentang menjalankan agen, lihat Menyinkronkan Langganan Push, Menyinkronkan Langganan Pull, dan Konsep Executable Agen Replikasi.

Ya. Membuat skrip konfigurasi replikasi adalah bagian penting dari rencana pemulihan bencana apa pun untuk topologi replikasi. Untuk informasi selengkapnya tentang pembuatan skrip, lihat Scripting Replication.

Replikasi berfungsi dengan baik menggunakan salah satu model pemulihan: sederhana, bulk-logged, atau penuh. Replikasi gabungan melacak perubahan dengan menyimpan informasi dalam tabel metadata. Replikasi transaksional melacak perubahan dengan menandai log transaksi, tetapi proses penandaan ini tidak terpengaruh oleh model pemulihan.

Untuk melacak perubahan, replikasi penggabungan dan replikasi transaksional dengan langganan pembaruan antrean harus dapat mengidentifikasi setiap baris secara unik di setiap tabel yang diterbitkan. Untuk mencapai hal ini:

• Replikasi penggabungan menambahkan kolom rowguid pada setiap tabel, kecuali tabel sudah memiliki kolom bertipe data uniqueidentifier dengan properti ROWGUIDCOL telah disetel (dalam hal ini kolom tersebut digunakan). Jika tabel dihilangkan dari publikasi, kolom rowguid dihapus; jika kolom yang ada digunakan untuk pelacakan, kolom tidak dihapus.

• Jika publikasi transaksional mendukung pembaruan langganan antrean, replikasi menambahkan kolom msrepl_tran_version ke setiap tabel. Jika tabel dihilangkan dari publikasi, kolom msrepl_tran_version tidak dihapus.

• Filter tidak boleh menyertakan rowguidcol yang digunakan oleh replikasi untuk mengidentifikasi baris. Secara default ini adalah kolom yang ditambahkan pada saat Anda menyiapkan replikasi penggabungan dan diberi nama rowguid.

Ada sejumlah masalah yang perlu dipertimbangkan mengenai batasan pada tabel yang diterbitkan:

• Replikasi transaksional memerlukan batasan kunci utama pada setiap tabel yang diterbitkan. Replikasi penggabungan tidak memerlukan kunci primer, tetapi jika ada, kunci tersebut harus direplikasi. Replikasi rekam jepret tidak memerlukan kunci primer.

• Secara default, batasan kunci utama, indeks, dan batasan pemeriksaan direplikasi ke Pelanggan.

• Opsi NOT FOR REPLICATION ditentukan secara default untuk batasan kunci asing dan batasan cek; batasan diberlakukan untuk operasi pengguna tetapi tidak untuk operasi agen.

Untuk informasi tentang mengatur opsi skema yang mengontrol apakah batasan direplikasi, lihat Menentukan Opsi Skema.

Replikasi menyediakan manajemen rentang identitas otomatis untuk topologi replikasi yang menyertakan pembaruan di Pengikut. Untuk informasi selengkapnya, lihat Mereplikasi Kolom Identitas.

Ya, tapi dengan beberapa batasan. Untuk informasi selengkapnya, lihat bagian "Menerbitkan Tabel di Lebih dari Satu Publikasi" dalam topik Menerbitkan Data dan Objek Database.

Ya. Tidak ada batasan jumlah atau jenis publikasi yang dapat menggunakan database distribusi yang sama. Semua publikasi dari Penerbit tertentu harus menggunakan database Distributor dan distribusi yang sama.

Jika Anda memiliki beberapa publikasi, Anda dapat mengonfigurasi beberapa database distribusi di Distributor untuk memastikan bahwa data yang mengalir melalui setiap database distribusi berasal dari satu publikasi. Gunakan kotak dialog Properti Distributor atau sp_adddistributiondb (Transact-SQL) untuk menambahkan database distribusi. Untuk informasi selengkapnya tentang mengakses kotak dialog, lihat Menampilkan dan Mengubah Properti Distributor dan Penerbit.

Informasi ini tersedia melalui SQL Server Management Studio, dan sejumlah prosedur tersimpan replikasi. Untuk informasi selengkapnya, lihat Skrip Informasi Distributor dan Penerbit.

Tidak. Replikasi tidak mengenkripsi data yang disimpan dalam database atau ditransfer melalui jaringan. Untuk informasi selengkapnya, lihat bagian "Enkripsi" dari topik Tampilkan dan ubah pengaturan keamanan replikasi.

Replikasi data melalui Internet menggunakan:

• Jaringan Privat Virtual (VPN - Virtual Private Network). Untuk informasi selengkapnya, lihat Menerbitkan Data melalui Internet Menggunakan VPN.

• Opsi Sinkronisasi web untuk replikasi penggabungan. Untuk informasi selengkapnya, lihat Sinkronisasi Web untuk Replikasi Penggabungan.

Semua jenis replikasi Microsoft SQL Server dapat mereplikasi data melalui VPN, tetapi Anda harus mempertimbangkan sinkronisasi Web jika Anda menggunakan replikasi penggabungan.

Ya. Pemrosesan replikasi dilanjutkan pada titik yang ditinggalkannya jika koneksi terputus. Jika Anda menggunakan replikasi penggabungan melalui jaringan yang tidak dapat diandalkan, pertimbangkan untuk menggunakan rekaman logis, yang memastikan perubahan terkait diproses sebagai unit. Untuk informasi selengkapnya, lihat Kelompokkan Perubahan pada Baris Terkait dengan Catatan Logis.

Ya, replikasi bekerja melalui koneksi bandwidth rendah. Untuk koneksi melalui TCP/IP, ia menggunakan kompresi yang disediakan oleh protokol tetapi tidak memberikan pemadatan tambahan. Untuk koneksi sinkronisasi Web melalui HTTPS, ia menggunakan kompresi yang disediakan oleh protokol dan juga pemadatan tambahan file XML yang digunakan untuk mereplikasi perubahan.

Tidak, replikasi hanya berfungsi saat Anda menggunakan nama server yang sebenarnya. Dimulai di SQL Server Management Studio (SSMS) 18.0 (dan versi yang lebih baru), replikasi dapat dikonfigurasi dengan menggunakan nama server dan nomor port yang sebenarnya.

Tidak. Anda dapat membuat paket SSIS untuk mentransfer login dan kata sandi dari Penerbit ke satu atau beberapa Pelanggan.

Dimulai dengan Microsoft SQL Server 2005 (9.x), skema memiliki dua arti:

• Definisi objek, seperti CREATE TABLE pernyataan. Secara bawaan, replikasi menyalin definisi semua objek yang direplikasi ke Subskriptor.

• Namespace tempat objek dibuat: <Database>.<Skema>.<Objek>. Skema didefinisikan menggunakan CREATE SCHEMA pernyataan .

• Replikasi memiliki perilaku default berikut di Wizard Publikasi Baru sehubungan dengan skema dan kepemilikan objek:

• Untuk artikel dalam publikasi gabungan dengan tingkat kompatibilitas 90 atau lebih tinggi, publikasi rekam jepret, dan publikasi transaksi: secara default, pemilik objek di Pelanggan sama dengan pemilik objek yang sesuai di Penerbit. Jika skema yang memiliki objek tidak ada di Subscriber, skema tersebut dibuat secara otomatis.

• Untuk artikel dalam publikasi gabungan dengan tingkat kompatibilitas yang lebih rendah dari 90: secara default, pemilik dibiarkan kosong dan ditentukan sebagai dbo selama pembuatan objek pada Subscriber.

• Untuk artikel dalam publikasi Oracle: secara default, pemilik ditentukan sebagai dbo.

• Untuk artikel dalam publikasi yang menggunakan cuplikan mode karakter (yang digunakan untuk Pelanggan SQL Server non-SQL dan Pelanggan SQL Server Compact): secara default, pemilik dibiarkan kosong. Pemilik secara otomatis ditetapkan ke pemilik yang berhubungan dengan akun yang digunakan oleh Agen Distribusi atau Agen Penggabungan untuk terhubung ke Subscriber.

Pemilik objek dapat diubah melalui kotak dialog Properti Artikel - Artikel> dan melalui prosedur tersimpan berikut: sp_addarticle, sp_addmergearticle, sp_changearticle, dan sp_changemergearticle. Untuk informasi selengkapnya, lihat Menampilkan dan Mengubah Properti Publikasi, Menentukan Artikel, serta Menampilkan dan Mengubah Properti Artikel.

Secara default, replikasi tidak menjalankan pernyataan GRANT pada database langganan. Jika Anda ingin izin pada database langganan cocok dengan yang ada di database publikasi, gunakan salah satu metode berikut:

• Jalankan perintah GRANT langsung di database langganan.

• Gunakan skrip pasca-rekam jepret untuk menjalankan pernyataan. Untuk informasi selengkapnya, lihat Menjalankan Skrip Sebelum dan Sesudah Rekam Jepret Diterapkan.

• Gunakan prosedur tersimpan sp_addscriptexec untuk menjalankan pernyataan.

Secara default, objek pada Subscriber dihilangkan dan dibuat ulang ketika berlangganan diinisialisasi ulang, yang menyebabkan semua izin yang diberikan untuk objek-objek tersebut menjadi batal. Ada dua cara untuk menangani hal ini:

• Terapkan kembali pemberian setelah reinisialisasi menggunakan teknik yang dijelaskan di bagian sebelumnya.

• Tentukan bahwa objek tidak boleh dihilangkan saat langganan diinisialisasi ulang. Sebelum reinisialisasi, entah:

  • Jalankan sp_changearticle atau sp_changemergearticle. Tentukan nilai 'pre_creation_cmd' (sp_changearticle) atau 'pre_creation_command' (sp_changemergearticle) untuk parameter @property dan nilai 'none', 'delete' atau 'truncate' untuk parameter @value.

  • Dalam kotak dialog Properti Artikel - <Artikel> di bagian Objek Tujuan, pilih nilai Pertahankan objek yang ada tidak berubah, Hapus data. Jika artikel memiliki filter baris, hapus hanya data yang cocok dengan filter. atau Potong semua data di objek yang ada untuk opsi Tindakan jika nama sedang digunakan. Untuk informasi selengkapnya tentang mengakses kotak dialog ini, lihat Menampilkan dan Mengubah Properti Publikasi.

TRUNCATE TABLE adalah pernyataan DDL yang tidak mencatat penghapusan baris individual dan tidak mengaktifkan pemicu DML. Ini tidak diizinkan karena replikasi tidak dapat melacak perubahan yang disebabkan oleh operasi: replikasi transaksional melacak perubahan melalui log transaksi; gabungkan replikasi melacak perubahan melalui pemicu DML pada tabel yang diterbitkan.

Untuk replikasi transaksional, penyisipan massal dilacak dan direplikasi seperti penyisipan lainnya. Untuk replikasi penggabungan, Anda harus memastikan bahwa metadata pelacakan perubahan diperbarui dengan benar.

Ya. Ada sejumlah pertimbangan khusus untuk database yang terlibat dalam replikasi. Untuk informasi selengkapnya, lihat Mencadangkan dan Memulihkan Database yang Direplikasi.

Replikasi gabungan dan replikasi snapshot tidak memengaruhi ukuran log transaksi, tetapi replikasi transaksional bisa memengaruhi. Jika database menyertakan satu atau beberapa publikasi transaksional, log tidak dipotong sampai semua transaksi yang relevan dengan publikasi telah dikirimkan ke database distribusi. Jika log transaksi tumbuh terlalu besar, dan Agen Pembaca Log berjalan secara terjadwal, pertimbangkan untuk mempersingkat interval antara eksekusi. Atau, atur untuk berjalan dalam mode berkelanjutan. Jika diatur untuk berjalan dalam mode berkelanjutan (default), pastikan dijalankan. Untuk informasi lebih lanjut tentang memeriksa informasi status Agen Pembaca Log, lihat bagian Menampilkan informasi dan melakukan tugas menggunakan Monitor Replikasi.

Selain itu, jika Anda telah mengatur opsi 'sinkronkan dengan cadangan' pada database publikasi atau database distribusi, log transaksi tidak terpotong sampai semua transaksi telah dicadangkan. Jika log transaksi tumbuh terlalu besar, dan Anda memiliki opsi ini yang ditetapkan, pertimbangkan untuk mempersingkat interval antara cadangan log transaksi. Untuk informasi selengkapnya tentang mencadangkan dan memulihkan database yang terlibat dalam replikasi transaksional, lihat Strategi untuk Mencadangkan dan Memulihkan Snapshot dan Replikasi Transaksional.

Ada berbagai mekanisme untuk membangun kembali indeks. Semuanya dapat digunakan tanpa pertimbangan khusus untuk replikasi, dengan pengecualian berikut: kunci primer diperlukan pada tabel dalam publikasi transaksional, sehingga Anda tidak dapat menghilangkan dan membuat ulang kunci utama pada tabel ini.

Indeks dapat ditambahkan di Penerbit atau Pelanggan tanpa pertimbangan khusus untuk replikasi (ketahuilah bahwa indeks dapat memengaruhi performa). CREATE INDEX dan ALTER INDEX tidak direplikasi, jadi jika Anda menambahkan atau mengubah indeks di, misalnya, Penerbit, Anda harus membuat penambahan atau perubahan yang sama di Pelanggan jika Anda ingin indeks tercermin di sana.

Dalam versi SQL Server sebelum SQL Server 2005 (9.x), memindahkan atau mengganti nama file database diperlukan untuk melepaskan dan memasang kembali database. Karena database yang direplikasi tidak dapat dilepaskan, replikasi harus dihapus dari database ini terlebih dahulu. Dimulai dengan SQL Server 2005 (9.x), Anda dapat memindahkan atau mengganti nama file tanpa melepaskan dan melampirkan ulang database, tanpa berpengaruh pada replikasi. Untuk informasi selengkapnya tentang memindahkan dan mengganti nama file, lihat MENGUBAH DATABASE (Transact-SQL).

Pertama-tama hapus artikel dari publikasi menggunakan sp_droparticle, sp_dropmergearticle, atau kotak dialog Publication Properties - <Publication>, dan kemudian hapus dari database menggunakan DROP <Object>. Anda tidak dapat menghapus artikel dari rekam jepret atau publikasi transaksi setelah langganan ditambahkan; Anda harus menghilangkan langganan terlebih dahulu. Untuk informasi selengkapnya, lihat Menambahkan Artikel ke dan Menghapus Artikel dari Publikasi yang Ada.

SQL Server mendukung berbagai perubahan skema pada objek yang diterbitkan, termasuk menambahkan dan menghilangkan kolom. Misalnya, jalankan ALTER TABLE … DROP COLUMN di Publisher, dan pernyataan direplikasi ke Subscriber lalu dijalankan untuk menghapus kolom. Pelanggan yang menjalankan versi SQL Server sebelum SQL Server 2005 (9.x) mendukung penambahan dan penurunan kolom melalui prosedur tersimpan sp_repladdcolumn dan sp_repldropcolumn. Untuk informasi selengkapnya, lihat Membuat Perubahan Skema pada Database Publikasi.

Gunakan validasi. Laporan validasi tentang apakah Penerima tertentu disinkronkan dengan Penerbit. Untuk informasi selengkapnya, lihat Memvalidasi Data yang Direplikasi. Validasi tidak memberikan informasi tentang baris mana, jika ada, yang tidak disinkronkan dengan benar, tetapi utilitas tablediff melakukannya.

Tidak perlu menghentikan aktivitas pada database publikasi atau langganan untuk menambahkan tabel (atau objek lain). Tambahkan tabel ke publikasi melalui kotak dialog Publication Properties - <Publication> atau prosedur tersimpan sp_addarticle dan sp_addmergearticle. Untuk informasi selengkapnya, lihat Menambahkan Artikel ke dan Menghapus Artikel dari Publikasi yang Ada.

Hapus tabel dari publikasi menggunakan sp_droparticle, sp_dropmergearticle, atau kotak dialog Pengaturan Publikasi - Publikasi. Anda tidak dapat menghapus artikel dari rekam jepret atau publikasi transaksi setelah langganan ditambahkan; Anda harus menghilangkan langganan terlebih dahulu. Untuk informasi selengkapnya, lihat Menambahkan Artikel ke dan Menghapus Artikel dari Publikasi yang Ada.

Ada sejumlah perubahan artikel dan publikasi yang mengharuskan langganan diinisialisasi ulang. Untuk informasi selengkapnya, lihat Mengubah Properti Publikasi dan Artikel.

Ada sejumlah perubahan artikel dan publikasi yang membatalkan rekam jepret dan mengharuskan rekam jepret baru dibuat. Untuk informasi selengkapnya, lihat Mengubah Properti Publikasi dan Artikel.

Tindakan yang diperlukan untuk menghapus replikasi dari database bergantung pada apakah database berfungsi sebagai database publikasi, database langganan, atau keduanya.

Untuk replikasi transaksional, gunakan prosedur tersimpan atau tab Perintah yang Tidak Didistribusikan di Monitor Replikasi. Untuk informasi selengkapnya, lihat Menampilkan Perintah yang Direplikasi dan Informasi Lain di Database Distribusi (Pemrograman Transact-SQL Replikasi) dan Menampilkan informasi dan melakukan tugas menggunakan Monitor Replikasi.

Untuk replikasi penggabungan, gunakan prosedur tersimpan sp_showpendingchanges. Untuk informasi selengkapnya, lihat sp_showpendingchanges (Transact-SQL).

Gunakan prosedur tersimpan sp_replmonitorsubscriptionpendingcmds atau tab Perintah yang Tidak Didistribusikan di Monitor Replikasi. Prosedur tersimpan dan tampilan tab:

• Jumlah perintah dalam database distribusi yang belum dikirimkan ke Pelanggan yang dipilih. Perintah terdiri dari satu pernyataan bahasa manipulasi data (DML) Transact-SQL atau satu pernyataan bahasa definisi data (DDL).

• Perkiraan jumlah waktu untuk mengirimkan perintah kepada Pelanggan. Jika nilai ini lebih besar dari jumlah waktu yang diperlukan untuk menghasilkan dan menerapkan snapshot ke Pelanggan, pertimbangkan untuk melakukan inisialisasi ulang pada Pelanggan. Untuk informasi selengkapnya, lihat Menginisialisasi ulang Langganan.

Untuk informasi selengkapnya, lihat sp_replmonitorsubscriptionpendingcmds (Transact-SQL) dan Melihat informasi dan melakukan tugas menggunakan Replication Monitor.

Ya. Untuk informasi selengkapnya, lihat Pengiriman dan Replikasi Log (SQL Server) dan Pencerminan dan Replikasi Database (SQL Server).

Ya. Tidak ada pertimbangan khusus yang diperlukan karena semua data disimpan pada satu set disk pada kluster.

Sebaiknya hubungi vendor pihak ketiga untuk masalah apa pun guna menerima dukungan. Umumnya, jika masalah ini diisolasi oleh vendor sebagai masalah replikasi inti yang merupakan bagian dari SQL Server, maka Dukungan Microsoft akan dilibatkan untuk memberikan bantuan lebih lanjut.

Lihat Juga

Praktik Terbaik untuk Administrasi Replikasi