Reporting Services dengan Grup Ketersediaan AlwaysOn (SQL Server)

Berlaku untuk:SQL Server

Artikel ini berisi informasi tentang mengonfigurasi Reporting Services agar berfungsi dengan grup ketersediaan AlwaysOn (AG) di SQL Server. Tiga skenario untuk menggunakan Reporting Services dan grup ketersediaan AlwaysOn adalah database untuk sumber data laporan, database server laporan, dan desain laporan. Fungsionalitas yang didukung dan konfigurasi yang diperlukan berbeda untuk tiga skenario.

Salah satu manfaat utama penggunaan grup ketersediaan Always On dengan sumber data Reporting Services adalah bahwa Anda dapat menggunakan replika sekunder yang dapat dibaca sebagai sumber data pelaporan, sementara pada saat yang sama replika sekunder tersebut berfungsi sebagai failover bagi basis data utama.

Untuk informasi umum tentang grup ketersediaan AlwaysOn, lihat Tanya Jawab Umum AlwaysOn untuk SQL Server 2012 (.. . /.. /.. /sql-server/index.yml).

Persyaratan untuk menggunakan Reporting Services dan Grup Ketersediaan AlwaysOn

SQL Server Reporting Services dan Power BI Report Server menggunakan .NET Framework 4.0 dan mendukung properti string koneksi untuk grup ketersediaan Always On yang digunakan dengan sumber data.

Untuk menggunakan grup ketersediaan Always On dengan Reporting Services 2014 atau versi sebelumnya, Anda perlu mengunduh dan menginstal hotfix untuk .NET 3.5 SP1. Hotfix ini menambahkan dukungan pada SQL Client untuk fitur AG serta dukungan untuk properti string koneksi ApplicationIntent dan MultiSubnetFailover. Jika Hotfix tidak diinstal di setiap komputer yang menghosting server laporan, maka pengguna yang mencoba mempratinjau laporan melihat pesan kesalahan yang mirip dengan yang berikut ini, dan pesan kesalahan akan ditulis ke log pelacakan server laporan:

Pesan kesalahan: "Kata kunci tidak didukung 'applicationintent'"

Pesan terjadi saat Anda menyertakan salah satu properti grup ketersediaan AlwaysOn di string koneksi Reporting Services, tetapi server tidak mengenali properti . Pesan kesalahan yang dicatat terlihat saat Anda memilih tombol 'Uji Koneksi' di antarmuka pengguna Reporting Services dan saat Anda mempratinjau laporan jika kesalahan jarak jauh diaktifkan di server laporan.

Untuk informasi selengkapnya tentang perbaikan yang diperlukan, lihat perbaikan KB 2654347A memperkenalkan dukungan untuk fitur AlwaysOn dari SQL Server 2012 ke .NET Framework 3.5 SP1.

Untuk informasi tentang persyaratan grup ketersediaan AlwaysOn lainnya, lihat Prasyarat, Pembatasan, dan Rekomendasi untuk Grup Ketersediaan AlwaysOn (SQL Server).

Catatan

File konfigurasi Reporting Services seperti RSreportserver.config tidak didukung sebagai bagian dari fungsionalitas grup ketersediaan AlwaysOn. Jika Anda membuat perubahan secara manual pada file konfigurasi di salah satu server laporan, Anda harus memperbarui replika secara manual.

Melaporkan Sumber Data dan Grup Ketersediaan

Perilaku sumber data Reporting Services berdasarkan grup ketersediaan AlwaysOn dapat bervariasi tergantung pada bagaimana administrator Anda telah mengonfigurasi lingkungan AG.

Untuk menggunakan grup ketersediaan Always On untuk sumber data laporan, Anda perlu mengonfigurasi string koneksi sumber data laporan agar menggunakan nama DNS Listener grup ketersediaan. Sumber data yang didukung adalah sebagai berikut:

  • Sumber data ODBC menggunakan SQL Native Client.

  • Klien SQL, dengan hotfix .NET yang diterapkan pada server laporan.

string koneksi juga dapat berisi properti koneksi AlwaysOn baru yang mengonfigurasi permintaan kueri laporan untuk menggunakan replika sekunder untuk pelaporan baca-saja. Penggunaan replika sekunder untuk permintaan pelaporan mengurangi beban pada replika utama baca-tulis. Ilustrasi berikut adalah contoh konfigurasi AG dengan tiga replika, di mana string koneksi sumber data Reporting Services telah dikonfigurasi dengan ApplicationIntent=ReadOnly. Dalam contoh ini, permintaan kueri laporan dikirim ke replika sekunder dan bukan replika utama.

Berikut ini adalah contoh string koneksi, di mana [AvailabilityGroupListenerName] adalah Nama DNS Listener yang dikonfigurasi saat replika dibuat:

Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2022; ApplicationIntent=ReadOnly

Tombol Uji Koneksi di antarmuka pengguna Reporting Services memvalidasi apakah koneksi dapat dibuat tetapi tidak akan memvalidasi konfigurasi AG. Misalnya jika Anda menyertakan ApplicationIntent dalam string koneksi ke server yang bukan bagian dari AG, parameter tambahan diabaikan dan tombol Uji Koneksi hanya akan memvalidasi koneksi yang dapat dibuat ke server yang ditentukan.

Bergantung pada bagaimana laporan Anda dibuat dan diterbitkan akan menentukan di mana Anda mengedit string koneksi:

  • Mode asli: Gunakan portal web untuk sumber data bersama dan laporan yang sudah diterbitkan ke server laporan mode asli.

  • Mode SharePoint: Gunakan halaman konfigurasi SharePoint dalam pustaka dokumen untuk laporan yang sudah diterbitkan ke server SharePoint.

  • Desain Laporan: Pembuat Laporan atau SQL Server Data Tools (SSDT) saat Anda membuat laporan baru. Lihat bagian 'Desain Laporan' di artikel ini atau informasi selengkapnya.

Sumber Daya Tambahan:

Pertimbangan: Replika sekunder biasanya akan mengalami penundaan dalam menerima perubahan data dari replika utama. Faktor-faktor berikut dapat memengaruhi latensi pembaruan antara replika primer dan sekunder:

  • Jumlah replika sekunder. Penundaan meningkat dengan setiap replika sekunder ditambahkan ke konfigurasi.

  • Lokasi geografis dan jarak antara replika primer dan sekunder. Misalnya penundaan biasanya lebih besar jika replika sekunder berada di pusat data yang berbeda daripada jika berada di bangunan yang sama dengan replika utama.

  • Konfigurasi mode ketersediaan untuk setiap replika. Mode ketersediaan menentukan apakah replika utama menunggu untuk melakukan transaksi pada database hingga replika sekunder telah menulis transaksi ke disk. Untuk informasi selengkapnya, lihat bagian 'Mode Ketersediaan' dari Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server).

Saat menggunakan sekunder baca-saja sebagai sumber data Reporting Services, penting untuk memastikan bahwa latensi pembaruan data memenuhi kebutuhan pengguna laporan.

Grup Desain dan Ketersediaan Laporan

Saat merancang laporan di Report Builder atau proyek laporan di SQL Server Data Tools (SSDT), pengguna dapat mengonfigurasi sumber data laporan string koneksi untuk berisi properti koneksi baru yang disediakan oleh grup ketersediaan AlwaysOn. Dukungan untuk properti koneksi baru bergantung pada tempat pengguna mempratinjau laporan.

  • Pratinjau lokal: Report Builder dan SQL Server Data Tools (SSDT) menggunakan .NET Framework 4.0 dan mendukung properti string koneksi untuk grup ketersediaan Always On.

  • Pratinjau mode jarak jauh atau server: Jika setelah menerbitkan laporan ke server laporan atau menggunakan pratinjau di Pembuat Laporan, Anda melihat kesalahan yang mirip dengan yang berikut ini, ini adalah indikasi bahwa Anda mempratinjau laporan terhadap server laporan dan Hotfix .NET Framework 3.5 SP1 untuk grup ketersediaan AlwaysOn belum diinstal di server laporan.

Pesan kesalahan: "Kata kunci tidak didukung 'applicationintent'"

Melaporkan Database Server dan Grup Ketersediaan

Reporting Services dan Power BI Report Server menawarkan dukungan terbatas untuk menggunakan grup ketersediaan AlwaysOn dengan database server laporan. Database server laporan dapat dikonfigurasi di AG untuk menjadi bagian dari replika; namun Reporting Services tidak akan secara otomatis menggunakan replika yang berbeda untuk database server laporan ketika failover terjadi. Penggunaan MultiSubnetFailover dengan database server laporan tidak didukung.

Tindakan manual atau skrip otomatisasi kustom perlu digunakan untuk menyelesaikan failover dan pemulihan. Sampai langkah-langkah ini selesai dilakukan, beberapa fitur pada server laporan mungkin tidak berfungsi dengan benar setelah failover grup ketersediaan Always On.

Catatan

Saat merencanakan failover dan pemulihan bencana untuk database server laporan, disarankan agar Anda selalu mencadangkan salinan kunci enkripsi server laporan.

Perbedaan antara Mode Asli SharePoint

Bagian ini meringkas perbedaan antara bagaimana mode SharePoint dan server laporan mode asli berinteraksi dengan grup ketersediaan AlwaysOn.

Server laporan SharePoint membuat 3 database untuk setiap aplikasi layanan Reporting Services yang Anda buat. Koneksi ke database server laporan dalam mode SharePoint dikonfigurasi di Administrasi Pusat SharePoint saat Anda membuat aplikasi layanan. Nama default database menyertakan GUID yang terkait dengan aplikasi layanan. Berikut ini adalah contoh nama database, untuk server laporan mode SharePoint:

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Pemberitahuan

Server laporan mode asli menggunakan 2 basis data. Berikut ini adalah contoh nama database, untuk server laporan mode asli:

  • ReportServer

  • ReportServerTempDB

Catatan

Saat Anda mengonfigurasi Reporting Services untuk bekerja dengan grup ketersediaan (AG), model pemulihan untuk database ReportServerTemp berubah menjadi Penuh. Akibatnya, ada skenario di mana ReportServerTemp database terus tumbuh dalam ukuran. Ini adalah praktik terbaik untuk menghapus ReportServerTemp database dari konfigurasi AG Anda, dan mengatur model pemulihan ke Sederhana. Database ReportServerTemp hanya menyimpan data sementara. Menghapusnya dari AG tidak memengaruhi Layanan Pelaporan (Reporting Services).

Mode asli tidak mendukung atau menggunakan database Pemberitahuan dan fitur terkait. Anda mengonfigurasi server laporan mode asli di Reporting Services Configuration Manager. Untuk mode SharePoint, Anda mengonfigurasi nama database aplikasi layanan untuk menjadi nama "titik akses klien" yang Anda buat sebagai bagian dari konfigurasi SharePoint. Untuk informasi selengkapnya tentang mengonfigurasi SharePoint dengan grup ketersediaan AlwaysOn, lihat Mengonfigurasi dan mengelola grup ketersediaan SQL Server untuk SharePoint Server (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)).

Catatan

Server laporan mode SharePoint menggunakan proses sinkronisasi antara database aplikasi layanan Reporting Services dan database konten SharePoint. Penting untuk mempertahankan database server laporan dan database konten bersama-sama. Anda harus mempertimbangkan untuk mengonfigurasi semuanya ke dalam grup ketersediaan yang sama sehingga dapat beralih otomatis dan dipulihkan sebagai satu kesatuan. Pertimbangkan skenario berikut:

  • Anda memulihkan atau melakukan failover ke salinan database konten yang belum menerima pembaruan terkini yang sama seperti yang telah diterima oleh database server laporan.
  • Proses sinkronisasi Reporting Services akan mendeteksi perbedaan antara daftar item dalam database konten dan database server laporan.
  • Proses sinkronisasi akan menghapus atau memperbarui item dalam database konten.

Siapkan Database Server Laporan untuk Grup Ketersediaan

Berikut ini adalah langkah-langkah dasar menyiapkan dan menambahkan database server laporan ke grup ketersediaan AlwaysOn:

  • Buat Grup Ketersediaan Anda dan konfigurasikan nama DNS Listener.

  • Replika Utama: Konfigurasikan database server laporan untuk menjadi bagian dari satu grup ketersediaan dan buat replika utama yang menyertakan semua database server laporan.

  • Replika Sekunder: Buat satu atau beberapa replika sekunder. Pendekatan umum untuk menyalin database dari replika utama ke replika sekunder adalah memulihkan database ke setiap replika sekunder menggunakan 'RESTORE WITH NORECOVERY'. Untuk informasi selengkapnya tentang membuat replika sekunder dan memverifikasi sinkronisasi data berfungsi, lihat Memulai Pergerakan Data pada Database Sekunder Always On (SQL Server).

  • Kredensial Server Laporan: Anda perlu membuat kredensial server laporan yang sesuai pada replika sekunder yang Anda buat di primer. Langkah-langkah yang tepat bergantung pada jenis autentikasi apa yang Anda gunakan di lingkungan Reporting Services Anda; Akun layanan Window Reporting Services, akun pengguna Windows, atau autentikasi SQL Server. Untuk informasi selengkapnya, lihat Mengonfigurasi Koneksi Database Server Laporan (SSRS Configuration Manager)

  • Perbarui koneksi database untuk menggunakan Nama DNS Listener. untuk server laporan mode asli, ubah Report Server Database Name di Configuration Manager Reporting Services. Untuk mode SharePoint, ubah nama server Database untuk aplikasi layanan Reporting Services.

Langkah-langkah untuk menyelesaikan pemulihan bencana database Report Server

Langkah-langkah berikut perlu dilakukan setelah failover grup ketersediaan Always On ke replika sekunder:

  1. Hentikan instans layanan Agen SQL yang sedang digunakan oleh mesin database utama yang menghosting database Reporting Services.

  2. Mulai layanan SQL Agent di komputer yang merupakan replika utama baru.

  3. Hentikan layanan Server Laporan.

    Jika server laporan dalam mode asli, hentikan server laporan Windows menggunakan manajer konfigurasi Reporting Services.

    Jika server laporan dikonfigurasi untuk mode SharePoint, hentikan layanan bersama Reporting Services di Administrasi Pusat SharePoint.

  4. Mulai layanan server laporan atau layanan SharePoint Reporting Services.

  5. Pastikan laporan dapat dijalankan pada replika utama baru.

Laporkan Perilaku Server Saat Failover Terjadi

Ketika database server laporan mengalami failover dan Anda telah memperbarui lingkungan server laporan untuk menggunakan replika utama yang baru, ada beberapa masalah operasional yang timbul akibat proses failover dan pemulihan. Dampak masalah ini bervariasi tergantung pada beban Reporting Services pada saat failover serta lamanya waktu yang diperlukan grup ketersediaan AlwaysOn untuk melakukan failover ke replika sekunder dan bagi administrator server laporan untuk memperbarui lingkungan pelaporan untuk menggunakan replika utama baru.

  • Eksekusi pemrosesan latar belakang dapat terjadi lebih dari sekali karena logika coba lagi dan ketidakmampuan server laporan untuk menandai pekerjaan terjadwal sebagai selesai selama periode failover.

  • Eksekusi pemrosesan latar belakang yang biasanya dipicu untuk dijalankan selama periode failover tidak akan terjadi karena SQL Server Agent tidak akan dapat menulis data ke database server laporan dan data ini tidak akan disinkronkan ke replika utama baru.

  • Setelah failover database selesai dan setelah layanan server laporan dimulai ulang, pekerjaan SQL Server Agent akan dibuat ulang secara otomatis. Hingga pekerjaan agen SQL dibuat ulang, eksekusi latar belakang apa pun yang terkait dengan pekerjaan SQL Server Agent tidak akan diproses. Ini mencakup langganan, jadwal, dan cuplikan di Reporting Services.

Lihat juga

  • Last updated on