Meningkatkan Pengiriman Log ke SQL Server 2014 (Transact-SQL)
Dimungkinkan untuk mempertahankan konfigurasi pengiriman log saat meningkatkan dari SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, atau SQL Server 2012 ke SQL Server 2014. Topik ini menjelaskan skenario alternatif dan praktik terbaik untuk meningkatkan konfigurasi pengiriman log.
Catatan
Kompresi cadangan diperkenalkan di SQL Server 2008 Enterprise. Konfigurasi pengiriman log yang ditingkatkan menggunakan opsi konfigurasi tingkat server default kompresi cadangan untuk mengontrol apakah kompresi cadangan digunakan untuk file cadangan log transaksi. Perilaku kompresi cadangan cadangan log dapat ditentukan untuk setiap konfigurasi pengiriman log. Untuk informasi selengkapnya, lihat Mengonfigurasi Pengiriman Log (SQL Server).
Lindungi Data Anda Sebelum Peningkatan
Sebagai praktik terbaik, kami sarankan Anda melindungi data Anda sebelum peningkatan pengiriman log.
Untuk melindungi data Anda
Lakukan pencadangan database lengkap pada setiap database utama.
Untuk informasi selengkapnya, lihat Membuat Pencadangan Database Lengkap (SQL Server).
Jalankan perintah DBCC CHECKDB pada setiap database utama.
Memutakhirkan Instans Server Monitor
Instans server monitor, jika ada, dapat ditingkatkan kapan saja.
Saat server monitor sedang ditingkatkan, konfigurasi pengiriman log terus berfungsi, tetapi statusnya tidak dicatat dalam tabel pada monitor. Pemberitahuan apa pun yang telah dikonfigurasi tidak akan dipicu saat server monitor sedang ditingkatkan. Setelah peningkatan, Anda dapat memperbarui informasi dalam tabel monitor dengan menjalankan prosedur tersimpan sistem sp_refresh_log_shipping_monitor .
Meningkatkan Konfigurasi Pengiriman Log dengan Server Sekunder Tunggal
Proses peningkatan yang dijelaskan di bagian ini mengasumsikan konfigurasi yang terdiri dari server utama dan hanya satu server sekunder. Konfigurasi ini diwakili dalam ilustrasi berikut, yang menunjukkan instans server utama, A, dan satu instans server sekunder, B.
Untuk informasi tentang meningkatkan beberapa server sekunder, lihat Meningkatkan Beberapa Instans Server Sekunder, nanti dalam topik ini.
Memutakhirkan Instans Server Sekunder
Proses peningkatan melibatkan peningkatan instans server sekunder dari konfigurasi pengiriman log SQL Server 2005 atau lebih tinggi ke SQL Server 2014 sebelum meningkatkan instans server utama. Selalu tingkatkan instans server sekunder terlebih dahulu. Jika server utama ditingkatkan sebelum server sekunder, pengiriman log akan gagal karena cadangan yang dibuat pada versi SQL Server yang lebih baru tidak dapat dipulihkan pada versi SQL Server yang lebih lama.
Pengiriman log berlanjut selama proses peningkatan karena server sekunder yang ditingkatkan terus memulihkan cadangan log dari SQL Server 2005 atau server utama yang lebih tinggi. Proses untuk meningkatkan instans server sekunder sebagian bergantung pada apakah konfigurasi pengiriman log memiliki beberapa server sekunder. Untuk informasi selengkapnya, lihat Meningkatkan Beberapa Instans Server Sekunder, nanti dalam topik ini.
Saat instans server sekunder sedang ditingkatkan, pekerjaan penyalinan dan pemulihan pengiriman log tidak berjalan, sehingga pencadangan log transaksi yang tidak disimpan akan terakumulasi. Jumlah akumulasi tergantung pada frekuensi pencadangan terjadwal di server utama. Selain itu, jika server monitor terpisah telah dikonfigurasi, peringatan mungkin dinaikkan yang menunjukkan pemulihan belum dilakukan lebih lama dari interval yang dikonfigurasi.
Setelah server sekunder ditingkatkan, pekerjaan agen pengiriman log dilanjutkan dan terus menyalin dan memulihkan cadangan log dari instans server utama, server A. Jumlah waktu yang diperlukan server sekunder untuk memperbarui database sekunder bervariasi, tergantung pada waktu yang diperlukan untuk meningkatkan server sekunder dan frekuensi cadangan di server utama.
Catatan
Selama peningkatan server, database sekunder tidak ditingkatkan ke database SQL Server 2014. Ini akan ditingkatkan hanya jika dibawa online.
Penting
Opsi PULIHKAN DENGAN SIAGA tidak didukung untuk database yang memerlukan peningkatan. Jika database sekunder yang ditingkatkan telah dikonfigurasi dengan menggunakan RESTORE WITH STANDBY, log transaksi tidak dapat lagi dipulihkan setelah peningkatan. Untuk melanjutkan pengiriman log pada database sekunder tersebut, Anda harus menyiapkan pengiriman log lagi di server siaga tersebut. Untuk informasi selengkapnya tentang opsi SIAGA, lihat ARGUMEN RESTORE (Transact-SQL).
Memutakhirkan Instans Server Utama
Saat merencanakan peningkatan, pertimbangan yang signifikan adalah jumlah waktu database Anda tidak akan tersedia. Skenario peningkatan paling sederhana melibatkan database yang tidak tersedia saat Anda meningkatkan server utama (skenario 1, di bawah).
Dengan biaya proses peningkatan yang lebih rumit, Anda dapat memaksimalkan ketersediaan database Anda dengan mengalihkan server utama SQL Server 2005 atau lebih tinggi ke server sekunder SQL Server 2014 sebelum meningkatkan server utama asli (skenario 2, di bawah). Ada dua varian skenario failover. Anda dapat beralih kembali ke server utama asli dan menyimpan konfigurasi pengiriman log asli. Atau, Anda dapat menghapus konfigurasi pengiriman log asli sebelum meningkatkan server utama asli dan kemudian membuat konfigurasi baru menggunakan server utama baru. Bagian ini menjelaskan kedua skenario ini.
Penting
Pastikan untuk meningkatkan instans server sekunder sebelum meningkatkan instans server utama. Untuk informasi selengkapnya, lihat Meningkatkan Instans Server Sekunder, sebelumnya dalam topik ini.
Skenario 1: Meningkatkan Instans Server Utama Tanpa Failover
Ini adalah skenario yang lebih sederhana, tetapi menyebabkan lebih banyak waktu henti daripada menggunakan failover. Instans server utama hanya ditingkatkan dan database tidak tersedia selama peningkatan ini.
Setelah server ditingkatkan, database secara otomatis dibawa kembali online, yang menyebabkannya ditingkatkan. Setelah database ditingkatkan, pekerjaan pengiriman log dilanjutkan.
Skenario 2: Meningkatkan Instans Server Utama dengan Failover
Skenario ini memaksimalkan ketersediaan dan meminimalkan waktu henti. Ini menggunakan failover terkontrol ke instans server sekunder, yang menjaga database tetap tersedia saat instans server utama asli ditingkatkan. Waktu henti terbatas pada waktu yang relatif singkat yang diperlukan untuk failover, bukan waktu yang diperlukan untuk meningkatkan instans server utama.
Meningkatkan instans server utama dengan failover melibatkan tiga prosedur umum: melakukan failover terkontrol ke server sekunder, meningkatkan instans server utama asli ke SQL Server 2014, dan menyiapkan pengiriman log pada instans server utama SQL Server 2014. Prosedur ini dijelaskan di bagian ini.
Penting
Jika Anda berencana untuk memiliki instans server sekunder sebagai instans server utama baru, Anda perlu menghapus konfigurasi pengiriman log. Pengiriman log perlu dikonfigurasi ulang dari primer baru ke sekunder baru, setelah instans server utama asli ditingkatkan. Untuk informasi selengkapnya, lihat Menghapus Pengiriman Log (SQL Server).
Prosedur 1: Melakukan Failover Terkontrol ke Server Sekunder
Failover terkontrol ke server sekunder:
Lakukan pencadangan log ekor secara manual dari log transaksi pada database utama yang menentukan WITH NORECOVERY. Pencadangan log ini menangkap rekaman log apa pun yang belum dicadangkan dan membuat database offline. Perhatikan bahwa saat database offline, pekerjaan pencadangan pengiriman log akan gagal.
Contoh berikut membuat cadangan
AdventureWorks
log ekor database di server utama. File cadangan diberi namaFailover_AW_20080315.trn
:BACKUP LOG AdventureWorks TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' WITH NORECOVERY; GO
Kami menyarankan agar Anda menggunakan konvensi penamaan file yang berbeda untuk membedakan file cadangan yang dibuat secara manual dari file cadangan yang dibuat oleh pekerjaan pencadangan pengiriman log.
Di server sekunder:
Pastikan bahwa semua cadangan yang diambil secara otomatis oleh pekerjaan pencadangan pengiriman log telah diterapkan. Untuk memeriksa pekerjaan pencadangan mana yang telah diterapkan, gunakan prosedur tersimpan sistem sp_help_log_shipping_monitor di server monitor atau di server utama dan sekunder. File yang sama harus dicantumkan di kolom last_backup_file, last_copied_file, dan last_restored_file . Jika salah satu file cadangan belum disalin dan dipulihkan, panggil pekerjaan penyalinan dan pemulihan agen secara manual untuk konfigurasi pengiriman log.
Untuk informasi tentang memulai pekerjaan, lihat Memulai Pekerjaan.
Salin Anda adalah file cadangan log akhir yang Anda buat di langkah 1 dari berbagi file ke lokasi lokal yang digunakan oleh pengiriman log di server sekunder.
Pulihkan cadangan log akhir yang menentukan WITH RECOVERY untuk membuat database online. Sebagai bagian dari dibawa online, database akan ditingkatkan ke SQL Server 2014.
Contoh berikut memulihkan cadangan
AdventureWorks
log ekor database pada database sekunder. Contohnya menggunakan opsi WITH RECOVERY, yang membawa database online:RESTORE LOG AdventureWorks FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' WITH RECOVERY; GO
Catatan
Untuk konfigurasi yang berisi lebih dari satu server sekunder, ada pertimbangan tambahan. Untuk informasi selengkapnya, lihat Meningkatkan Beberapa Instans Server Sekunder, nanti dalam topik ini.
Failover database dengan mengalihkan klien dari server utama asli (server A) ke server sekunder online (server B).
Berhati-hatilah bahwa log transaksi database sekunder tidak terisi saat database online. Untuk mencegah pengisian log transaksi, Anda mungkin perlu mencadangkannya. Jika demikian, kami sarankan Anda mencadangkannya ke lokasi bersama, berbagi cadangan, untuk membuat cadangan tersedia untuk dipulihkan pada instans server lainnya.
Prosedur 2: Tingkatkan Instans Server Utama Asli ke SQL Server 2014
Setelah Anda meningkatkan instans server utama asli ke SQL Server 2014, database masih akan offline dan dalam format .
Prosedur 3: Menyiapkan Pengiriman Log pada SQL Server 2014
Sisa proses peningkatan tergantung pada apakah pengiriman log masih dikonfigurasi, sebagai berikut:
Jika Anda telah menyimpan konfigurasi pengiriman log SQL Server 2005or yang lebih tinggi, beralih kembali ke instans server utama asli. Untuk informasi selengkapnya, lihat Beralih Kembali ke Instans Server Utama Asli, nanti di bagian ini.
Jika Anda menghapus konfigurasi pengiriman log sebelum failover, buat konfigurasi pengiriman log baru di mana instans server sekunder asli adalah instans server utama baru. Untuk informasi selengkapnya, lihat Untuk Menyimpan Instans Server Sekunder Lama Sebagai Instans Server Utama Baru, nanti di bagian ini.
Untuk Beralih Kembali ke Instans Server Utama Asli
Pada server utama sementara (server B), cadangkan ekor log menggunakan WITH NORECOVERY untuk membuat cadangan log ekor dan membuat database offline. Cadangan log ekor diberi nama
Switchback_AW_20080315.trn
. Misalnya:BACKUP LOG AdventureWorks TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' WITH NORECOVERY; GO
Jika ada cadangan log transaksi yang diambil pada database utama sementara, selain cadangan ekor yang Anda buat di langkah 1, pulihkan cadangan log tersebut menggunakan WITH NORECOVERY ke database offline di server utama asli (server A). Database ditingkatkan ke format SQL Server 2014 saat pencadangan log pertama dipulihkan.
Pulihkan cadangan log ekor,
Switchback_AW_20080315.trn
, pada database utama asli (di server A) menggunakan WITH RECOVERY untuk membuat database online.Failover kembali ke database utama asli (di server A) dengan mengalihkan klien ke server sekunder online dari server utama asli.
Setelah database online, konfigurasi pengiriman log asli akan dilanjutkan.
Untuk Menyimpan Instans Server Sekunder Lama Sebagai Instans Server Utama Baru
Buat konfigurasi pengiriman log baru menggunakan instans server sekunder lama, B, sebagai server utama dan instans server utama lama, A, sebagai server sekunder baru, sebagai berikut:
Penting
Konfigurasi pengiriman log lama seharusnya telah dihapus dari server utama asli pada awal proses sebelum mengambil cadangan log transaksi manual yang membuat database offline.
Untuk menghindari melakukan pencadangan lengkap dan pemulihan database di server sekunder baru (server A), terapkan cadangan log dari database utama baru ke database sekunder baru. Dalam konfigurasi contoh, ini melibatkan pemulihan cadangan log yang diambil di server B ke database di server A.
Cadangkan log dari database utama baru (di server B).
Pulihkan cadangan log ke instans server sekunder baru (server A) menggunakan WITH NORECOVERY. Operasi pemulihan pertama memperbarui database ke SQL Server 2014.
Konfigurasikan pengiriman log dengan server sekunder sebelumnya (server B) sebagai instans server utama.
Penting
Jika Anda menggunakan SQL Server Management Studio, tentukan bahwa database sekunder sudah diinisialisasi.
Untuk informasi selengkapnya, lihat Mengonfigurasi Pengiriman Log (SQL Server).
Failover database dengan mengalihkan klien dari server utama asli (server A) ke server sekunder online (server B).
Penting
Saat Anda melakukan failover ke database utama baru, Anda harus memastikan bahwa metadatanya konsisten dengan metadata database utama asli. Untuk informasi selengkapnya, lihat Mengelola Metadata Saat Membuat Database Tersedia di Instans Server Lain (SQL Server).
Meningkatkan Beberapa Instans Server Sekunder
Konfigurasi ini diwakili dalam ilustrasi berikut, yang menunjukkan instans server utama, A, dan dua instans server sekunder, B dan C.
Bagian ini membahas cara meningkatkan menggunakan failover lalu beralih kembali ke server utama asli. Saat meningkatkan instans utama dengan failover, prosesnya lebih kompleks ketika ada beberapa instans server sekunder. Dalam prosedur berikut, setelah semua server sekunder ditingkatkan, server utama gagal ke salah satu database sekunder yang ditingkatkan. Server utama asli ditingkatkan, dan pengiriman log gagal kembali ke server tersebut.
Penting
Selalu tingkatkan semua instans server sekunder sebelum Anda meningkatkan server utama.
Untuk meningkatkan menggunakan failover lalu beralih kembali ke server utama asli
Tingkatkan semua instans server sekunder (server B dan server C).
Dapatkan ekor log transaksi database utama (di server A), dan buat database offline, dengan mencadangkan log transaksi menggunakan WITH NORECOVERY.
Di server sekunder tempat Anda berencana untuk melakukan failover (server B), bawa database sekunder online, dengan memulihkan cadangan log menggunakan WITH RECOVERY.
Di setiap server sekunder lainnya (server C), biarkan database sekunder offline dengan memulihkan cadangan log menggunakan WITH NORECOVERY.
Catatan
Pekerjaan penyalinan dan pemulihan pengiriman log akan berjalan di server sekunder, tetapi pekerjaan tidak akan melakukan apa pun karena file cadangan log baru tidak akan ditempatkan pada berbagi cadangan.
Failover database dengan mengalihkan klien dari server utama asli (server A) ke server sekunder online (server B). Database online menjadi server utama sementara, menjaga database tetap tersedia saat server utama asli offline (server A).
Tingkatkan server utama asli (server A).
Pada database tempat Anda melakukan failover database utama sementara (di server B), cadangkan log transaksi secara manual menggunakan WITH NORECOVERY. Ini membuat database offline.
Pulihkan semua cadangan log transaksi yang Anda buat di database utama sementara (di server B) ke setiap database sekunder lainnya (di server C) menggunakan WITH NORECOVERY. Ini memungkinkan pengiriman log berlanjut dari database utama asli setelah peningkatannya, tanpa memerlukan pemulihan database penuh pada setiap database sekunder.
Pulihkan log transaksi dari server utama sementara (server B) ke database utama asli (di server A) menggunakan WITH RECOVERY.
Penyebaran Ulang Pengiriman Log
Jika Anda tidak ingin memigrasikan konfigurasi pengiriman log Anda menggunakan salah satu prosedur yang ditunjukkan di atas, Anda dapat menyebarkan ulang pengiriman log dari awal dengan menginisialisasi ulang database sekunder Anda dengan pencadangan penuh dan pemulihan database utama. Ini mungkin merupakan opsi yang diinginkan jika Anda memiliki database kecil atau jika ketersediaan tinggi tidak penting selama prosedur peningkatan.
Untuk informasi tentang mengaktifkan pengiriman log, lihat Mengonfigurasi Pengiriman Log (SQL Server).
Lihat juga
Pencadangan Log Transaksi (SQL Server)Terapkan Pencadangan Log Transaksi (SQL Server)Tabel Pengiriman Log dan Prosedur Tersimpan