Bagikan melalui


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

  1. Lakukan pencadangan database lengkap pada setiap database utama.

    Untuk informasi selengkapnya, lihat Membuat Pencadangan Database Lengkap (SQL Server).

  2. 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.

Satu server sekunder dan tidak ada server monitor

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:

  1. 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 nama Failover_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.

  2. Di server sekunder:

    1. 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.

    2. 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.

    3. 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.

    4. Failover database dengan mengalihkan klien dari server utama asli (server A) ke server sekunder online (server B).

    5. 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:

Untuk Beralih Kembali ke Instans Server Utama Asli
  1. 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
    
  2. 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.

  3. Pulihkan cadangan log ekor, Switchback_AW_20080315.trn, pada database utama asli (di server A) menggunakan WITH RECOVERY untuk membuat database online.

  4. 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.

  1. 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.

  2. Cadangkan log dari database utama baru (di server B).

  3. Pulihkan cadangan log ke instans server sekunder baru (server A) menggunakan WITH NORECOVERY. Operasi pemulihan pertama memperbarui database ke SQL Server 2014.

  4. 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).

  5. 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.

Dua server sekunder dan tanpa server monitor

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

  1. Tingkatkan semua instans server sekunder (server B dan server C).

  2. Dapatkan ekor log transaksi database utama (di server A), dan buat database offline, dengan mencadangkan log transaksi menggunakan WITH NORECOVERY.

  3. Di server sekunder tempat Anda berencana untuk melakukan failover (server B), bawa database sekunder online, dengan memulihkan cadangan log menggunakan WITH RECOVERY.

  4. 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.

  5. 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).

  6. Tingkatkan server utama asli (server A).

  7. Pada database tempat Anda melakukan failover database utama sementara (di server B), cadangkan log transaksi secara manual menggunakan WITH NORECOVERY. Ini membuat database offline.

  8. 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.

  9. 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