Reporting Services dengan Grup Ketersediaan AlwaysOn (SQL Server)

  • Artikel

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.

Manfaat utama menggunakan grup ketersediaan AlwaysOn dengan sumber data Reporting Services adalah menggunakan replika sekunder yang dapat dibaca sebagai sumber data pelaporan sementara, pada saat yang sama, replika sekunder menyediakan failover untuk database 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 grup ketersediaan AlwaysOn string koneksi properti untuk digunakan dengan sumber data.

Untuk menggunakan grup ketersediaan AlwaysOn dengan Reporting Services 2014, dan yang lebih lama, Anda perlu mengunduh dan menginstal perbaikan untuk .NET 3.5 SP1. Perbaikan menambahkan dukungan ke SQL Client untuk fitur AG dan dukungan 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 ion' 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 AlwaysOn untuk sumber data laporan, Anda perlu mengonfigurasi sumber data laporan string koneksi adalah menggunakan nama DNS Listener grup ketersediaan. Sumber data yang didukung adalah sebagai berikut:

  • Sumber data ODBC menggunakan SQL Native Client.

  • Klien SQL, dengan perbaikan .NET diterapkan ke 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 tiga replika di mana sumber data Reporting Services string koneksi 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 ion 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 ion 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: judul ---: sertakan deskripsi file: sertakan penulis file: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: include ms.custom: include fileReport Builder 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 dalam judul ---: sertakan deskripsi file: sertakan penulis file: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: menyertakan ms.custom: menyertakan fileReport 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: judul ---: menyertakan deskripsi file: termasuk penulis file: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: include ms.custom: include fileReport Builder and SQL Server Data Tools (SSDT) use the .NET framework 4.0 and support Always On availability groups string koneksi properties.

  • Pratinjau mode jarak jauh atau server: Jika setelah menerbitkan laporan ke server laporan atau menggunakan pratinjau dalam judul ---: sertakan deskripsi file: sertakan penulis file: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: include ms.custom: include fileReport Builder, 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 pada 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. Hingga tindakan ini selesai, beberapa fitur server laporan mungkin tidak berfungsi dengan benar setelah failover grup ketersediaan AlwaysOn.

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_Alerting

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

  • ReportServer

  • ReportServerTempDB

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 mengonfigurasinya dalam grup ketersediaan yang sama sehingga failover dan pulih sebagai satu set. Pertimbangkan skenario berikut:

  • Anda memulihkan atau failover ke salinan database konten yang belum menerima pembaruan terbaru yang sama dengan yang diterima 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.

Menyiapkan 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 Nama Database Server Laporan di manajer konfigurasi Reporting Services. Untuk mode SharePoint, ubah nama server Database untuk aplikasi layanan Reporting Services.

Langkah-langkah untuk menyelesaikan pemulihan bencana Database Server Laporan

Langkah-langkah berikut perlu diselesaikan setelah failover grup ketersediaan AlwaysOn 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. Verifikasi bahwa laporan dapat berjalan terhadap replika utama baru.

Laporkan Perilaku Server Saat Failover Terjadi

Saat melaporkan failover database server dan Anda telah memperbarui lingkungan server laporan untuk menggunakan replika utama baru, ada beberapa masalah operasional yang dihasilkan dari 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 termasuk langganan, jadwal, dan rekam jepret Reporting Services.

Baca juga