SSISDB on Always On AG Causing SQL Server Upgrade Failures? Error 945 Explained
Artikel ini bertujuan untuk membantu Anda dalam memecahkan masalah yang terjadi ketika pembaruan kumulatif (CU) atau paket layanan (SP) untuk Microsoft SQL Server melaporkan kode kesalahan 945 saat Anda menjalankan skrip upgrade database. Masalah ini secara khusus muncul dalam konfigurasi Always On Availability Group (AG) yang melibatkan database katalog SQL Server Integration Services (SSISDB). Memahami gejala, penyebab, dan resolusi sangat penting untuk menjaga lingkungan SQL Server Anda tetap sehat dan berfungsi.
Gejala¶
Ketika Anda menerapkan CU atau SP ke instance SQL Server Anda, proses Setup mungkin gagal dan menghasilkan pesan kesalahan berikut:
Wait on the Database Engine recovery handle failed. Check the SQL Server error log for potential causes.
Pesan kesalahan generik ini menunjukkan bahwa proses upgrade mengalami masalah selama fase pemulihan mesin database. Untuk mendapatkan pemahaman yang lebih dalam tentang penyebab kegagalan tersebut, Anda perlu memeriksa log kesalahan SQL Server.
Selain pesan kesalahan di atas, log kesalahan SQL Server mungkin mencatat entri kesalahan yang lebih spesifik yang menyoroti masalah yang mendasarinya. Entri kesalahan ini seringkali memberikan informasi penting mengenai tahap upgrade yang gagal dan database tertentu yang terlibat. Contoh entri kesalahan yang mungkin Anda temui adalah:
Database 'master' is upgrading script 'SSIS_hotfix_install.sql' from level 201331031 to level 201331592.
Error: 945, Severity: 14, State: 2.
Database 'SSISDB' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step 'SSIS_hotfix_install.sql' encountered error 945, state 2, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Error: 3417, Severity: 21, State: 3.
Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.
SQL Server shutdown has been initiated
Log kesalahan ini mengungkapkan beberapa poin penting:
- Skrip Upgrade: Proses upgrade mencoba menjalankan skrip
SSIS_hotfix_install.sqlpada databasemaster. Skrip ini merupakan bagian dari proses upgrade untuk SQL Server Integration Services (SSIS). - Error 945: Kesalahan utama adalah kesalahan 945 yang terkait dengan database
SSISDB. Pesan kesalahan spesifik menunjukkan bahwaSSISDBtidak dapat dibuka karena file yang tidak dapat diakses atau memori atau ruang disk yang tidak mencukupi. - Kegagalan Upgrade Skrip Master: Karena kesalahan 945 pada
SSISDB, upgrade skrip untuk databasemastergagal. Ini adalah masalah serius karena databasemastersangat penting untuk operasi SQL Server. - Kegagalan Pemulihan Master dan Shutdown: Kegagalan untuk mengupgrade database
mastermengakibatkan kegagalan pemulihan databasemaster. Akibatnya, SQL Server tidak dapat berjalan dan memulai proses shutdown.
Rangkaian kesalahan ini menunjukkan bahwa masalah upgrade berakar pada ketidakmampuan untuk mengakses atau mengupgrade database SSISDB, yang kemudian memicu efek domino yang menyebabkan kegagalan upgrade master dan akhirnya shutdown SQL Server.
Penyebab¶
Penyebab utama kegagalan upgrade ini terletak pada konfigurasi Always On Availability Group (AG) ketika database katalog SQL Server Integration Services (SSISDB) ditambahkan ke dalamnya. Untuk memahami mengapa hal ini menyebabkan masalah, penting untuk mempertimbangkan bagaimana proses upgrade dan Always On AG berinteraksi.
Proses upgrade SQL Server, termasuk penerapan CU atau SP, memerlukan database untuk berada dalam mode pengguna tunggal selama fase upgrade skrip. Mode pengguna tunggal memastikan bahwa hanya proses upgrade yang memiliki akses eksklusif ke database, mencegah konflik dan memastikan integritas perubahan skema dan data.
Namun, database yang merupakan bagian dari Always On Availability Group dirancang untuk menjadi database multi-pengguna untuk mendukung replikasi dan ketersediaan tinggi. Availability Group mengharuskan database tetap online dan tersedia untuk beberapa koneksi klien untuk memastikan failover dan redundansi yang lancar.
Konflik muncul selama proses upgrade karena persyaratan mode pengguna tunggal bertentangan dengan sifat multi-pengguna database ketersediaan. Ketika proses upgrade mencoba menempatkan database dalam mode pengguna tunggal, terutama SSISDB yang merupakan bagian dari AG, proses tersebut menghadapi kendala. Database ketersediaan, termasuk SSISDB, tidak dapat diupgrade saat online dan merupakan bagian dari Availability Group.
Selama instalasi upgrade, semua database ketersediaan, termasuk SSISDB, secara otomatis diambil offline oleh Availability Group. Meskipun database offline, mereka tidak diupgrade selama proses upgrade standar. Kegagalan untuk mengupgrade SSISDB ini menyebabkan kesalahan 945 yang teramati, yang kemudian menghambat upgrade database master dan menyebabkan kegagalan instalasi secara keseluruhan.
Singkatnya, penyebabnya adalah kombinasi dari:
- SSISDB dalam Always On AG: Database
SSISDBdikonfigurasi sebagai bagian dari Availability Group. - Persyaratan Mode Pengguna Tunggal Upgrade: Proses upgrade memerlukan database untuk berada dalam mode pengguna tunggal.
- Konflik dengan Database Ketersediaan: Database ketersediaan harus multi-pengguna dan tidak dapat diupgrade saat online dalam AG.
- Database Offline Tidak Diupgrade: Database ketersediaan diambil offline tetapi tidak diupgrade selama upgrade standar.
Untuk informasi lebih lanjut dan pemahaman yang lebih dalam tentang topik ini, Anda dapat merujuk ke dokumentasi resmi Microsoft mengenai Upgrading SSISDB in an availability group. Meskipun tautan khusus mungkin tidak disertakan di sini sesuai instruksi, mencari frasa ini di situs web dokumentasi Microsoft akan memberikan wawasan tambahan.
Resolusi¶
Untuk mengatasi masalah kegagalan upgrade yang disebabkan oleh SSISDB dalam Always On Availability Group, Anda perlu mengambil langkah-langkah spesifik untuk memastikan bahwa database SSISDB diupgrade dengan benar. Sayangnya, artikel asli tidak menyediakan langkah-langkah resolusi spesifik. Namun, berdasarkan pemahaman penyebabnya, kita dapat menyimpulkan pendekatan umum untuk menyelesaikan masalah ini.
Solusinya pada dasarnya melibatkan memisahkan SSISDB dari Availability Group untuk sementara waktu selama proses upgrade, memungkinkan database untuk diupgrade secara terpisah, dan kemudian menggabungkannya kembali ke Availability Group setelah upgrade berhasil diselesaikan.
Meskipun langkah-langkah rinci mungkin bervariasi tergantung pada konfigurasi spesifik dan versi SQL Server Anda, berikut adalah alur kerja umum yang dapat Anda ikuti:
-
Failover Availability Group: Lakukan failover Availability Group yang berisi SSISDB ke replika sekunder. Ini akan menjadikan replika sekunder sebagai replika utama yang baru. Langkah ini penting untuk memastikan bahwa perubahan konfigurasi dilakukan pada replika yang tepat.
-
Hapus SSISDB dari Availability Group: Pada replika utama yang baru (sebelumnya sekunder), hapus database SSISDB dari Availability Group. Ini akan mengeluarkan SSISDB dari manajemen Availability Group dan memungkinkan modifikasi langsung. Berhati-hatilah saat melakukan langkah ini dan pastikan Anda memahami implikasinya untuk ketersediaan tinggi SSISDB sementara.
-
Terapkan CU atau SP: Terapkan pembaruan kumulatif (CU) atau paket layanan (SP) ke instance SQL Server. Sekarang SSISDB tidak lagi menjadi bagian dari Availability Group, proses upgrade seharusnya dapat mengupgrade database SSISDB tanpa konflik.
-
Upgrade SSISDB (Jika Diperlukan): Dalam beberapa kasus, Anda mungkin perlu menjalankan langkah-langkah upgrade tambahan khusus untuk SSISDB setelah menerapkan CU atau SP. Dokumentasi Microsoft untuk upgrade SSISDB dalam Availability Group akan memberikan panduan khusus tentang langkah-langkah tambahan yang mungkin diperlukan. Periksa dokumentasi resmi untuk langkah-langkah upgrade khusus versi.
-
Tambahkan Kembali SSISDB ke Availability Group: Setelah upgrade berhasil diselesaikan, tambahkan kembali database SSISDB ke Availability Group. Ini akan mengembalikan SSISDB ke konfigurasi ketersediaan tinggi yang diinginkan.
-
Failback Availability Group (Opsional): Jika Anda ingin mengembalikan replika utama asli sebagai replika utama, lakukan failback Availability Group ke replika utama asli.
Penting untuk dicatat bahwa langkah-langkah di atas adalah panduan umum. Langkah-langkah yang tepat dan urutannya mungkin berbeda tergantung pada lingkungan SQL Server Anda. Selalu konsultasikan dokumentasi resmi Microsoft untuk langkah-langkah yang tepat dan praktik terbaik untuk mengupgrade SSISDB dalam Always On Availability Group untuk versi SQL Server spesifik Anda.
Selain itu, sangat disarankan untuk menguji proses upgrade di lingkungan non-produksi yang menyerupai lingkungan produksi Anda sebelum menerapkan perubahan apa pun ke sistem produksi. Pengujian di lingkungan non-produksi membantu mengidentifikasi potensi masalah dan memastikan proses upgrade yang lancar di lingkungan produksi.
Dengan memahami penyebab kesalahan 945 selama upgrade SQL Server dengan SSISDB dalam Always On AG dan mengikuti langkah-langkah resolusi yang disarankan, Anda dapat berhasil mengupgrade instance SQL Server Anda dan menjaga ketersediaan tinggi database SSISDB Anda. Ingatlah untuk selalu merujuk pada dokumentasi resmi dan melakukan pengujian menyeluruh sebelum menerapkan perubahan upgrade apa pun di lingkungan produksi Anda.
Jika Anda memiliki pengalaman lain dengan kesalahan upgrade SSISDB dalam Always On AG atau memiliki tips pemecahan masalah tambahan, jangan ragu untuk berbagi di bagian komentar di bawah!
Post a Comment