Banyak administrator database menemukan diri mereka harus mendukung contoh SQL Server Reporting Services (SSRS), atau setidaknya database backend yang diperlukan untuk SSRS. Selama bertahun-tahun SSRS dibundel dengan penginstalan SQL Server, yang membantu menambah kebingungan seputar lisensi dan dukungan untuk produk, jadi mulai dengan SSRS 2017, paket penginstalan untuk Layanan Pelaporan adalah unduhan terpisah.

Artikel ini akan mencakup banyak area yang perlu diperhatikan oleh administrator basis data untuk melisensikan, memulihkan, dan menyetel penginstalan Layanan Pelaporan dengan benar. Topik ini berlaku untuk Layanan Pelaporan SQL Server serta Server Laporan Power BI.

Lisensi

Instalasi dan dukungan SSRS dapat membingungkan. Layanan pelaporan dapat diinstal sebagai instans mandiri pada server khusus, pada instans yang sama seperti SQL Server, atau dalam penyebaran skala (khusus Edisi Perusahaan). Setiap instans di mana SSRS diinstal dalam produksi memerlukan lisensi SQL Server, serta melisensikan instans SQL Server tempat database ReportServer dan ReportServerTempDB berada.

Cara saya ingin menjelaskan cara melisensikan Reporting Services adalah dengan memikirkan layanan pelaporan sebagai aplikasi yang menggunakan SQL Server di bagian belakang. Pada hari-hari awal SSRS, persyaratannya adalah juga menginstal dan mengkonfigurasi Layanan Informasi Internet (IIS). SSRS 2008 membawa komponen tersebut ke dalam modul layanan pelaporan. Sangat umum untuk melihat SSRS dan MSSQL diinstal pada instance yang sama karena lisensi dan ini dapat bekerja dengan baik untuk implementasi yang lebih kecil. Untuk penerapan yang lebih besar, biasanya melihat server layanan pelaporan khusus dengan ReportServer dan ReportServerTempDB pada SQL Server terkonsolidasi. Untuk penginstalan yang sangat besar, penerapan scale-out digunakan untuk menyediakan penyeimbangan beban layanan server pelaporan. Dalam penerapan scale-out, setiap instance di farm harus dilisensikan.

Pemulihan

Dalam setiap model penyebaran, peran administrator database adalah memastikan bahwa SSRS stabil, dapat diandalkan, dan dapat dipulihkan. Bagian yang dapat dipulihkan adalah sesuatu yang menyebabkan beberapa masalah DBA. Database ReportServer dienkripsi dan operasi tertentu memerlukan pemulihan kunci simetris. Jika terjadi kegagalan dan database harus dipulihkan ke server lain, nama akun layanan Windows Server Laporan atau kata sandi diubah, nama komputer diubah, Anda bermigrasi ke server lain, atau Anda menambahkan server baru ke skala- keluar konfigurasi, Anda akan diminta untuk mengembalikan kunci enkripsi. Kecuali jika kunci dicadangkan, semua data yang dilindungi, seperti string koneksi dan kata sandi, tidak dapat didekripsi. Saya telah menemukan bahwa banyak DBA tidak menyadari hal ini sampai terlambat. Kunci dapat dicadangkan dan dipulihkan secara manual menggunakan Manajer Konfigurasi Layanan Pelaporan, menggunakan utilitas rskeymgmt.exe, atau menggunakan PowerShell. Secara teknis Anda hanya perlu mencadangkan satu salinan kunci simetris.

Database ReportServer dan ReportServerTempDB adalah database SQL Server dan harus menjadi bagian dari proses pencadangan reguler, sama seperti database pengguna lainnya. ReportServer harus menggunakan model pemulihan penuh sedangkan ReportServerTempDB dapat menggunakan model pemulihan sederhana. Secara teknis, ReportServerTempDB dapat dibuat ulang oleh skrip jika terjadi bencana, namun Layanan Pelaporan tidak dapat dimulai tanpa ReportServerTempDB. DBA akrab dengan memulihkan database, daripada mencari skrip untuk membuat ulang database. Tidak seperti tempdb database sistem, ReportServerTempDB tidak dibuat ulang saat startup. Praktik terbaik untuk DBA adalah dengan memperlakukan ReportServer dan ReportServerTempDB seperti database pengguna lainnya.

Ada file konfigurasi yang menyimpan pengaturan aplikasi yang juga harus dicadangkan. Ini mungkin dicakup oleh cadangan tingkat OS Anda; namun, DBA harus memastikan file-file ini dicadangkan setelah konfigurasi awal dan/atau setelah ekstensi kustom diterapkan. File-file ini terdiri dari:

Rsreportserver.config
Rssvrpolicy.config
Rsmgrpolicy.config
Reportingservciesservice.exe.config
Web.config
Machine.config

Pertimbangan untuk membuat cadangan file Desainer Laporan Anda seperti; File .rdl, .rds, .dv, .ds, rptproj, dan .sln harus diberikan.

Opsi Penyetelan

Tuning SSRS sangat mirip dengan aplikasi lainnya. Pengguna mengeksekusi laporan dari server aplikasi yang berkomunikasi dengan database. Perbedaan besar adalah Anda memiliki server aplikasi (Layanan Pelaporan) dengan databasenya sendiri, tetapi laporan tersebut memiliki sumber data yang terhubung ke database pengguna lain. DBA harus menyesuaikan kesehatan infrastruktur Layanan Pelaporan secara keseluruhan serta menyesuaikan laporan aktual.

Infrastruktur Layanan Pelaporan

Latensi disk untuk ReportServer dan ReportServerTempDB sangat penting. Tergantung pada beban kerja, database tersebut mungkin perlu ditempatkan pada disk yang lebih cepat. Cache hasil laporan disimpan dalam database ReportServerTempDB dan kinerja I/O dapat menjadi masalah di sini.

Beban kerja Layanan Pelaporan dapat menentukan bahwa instans Layanan Pelaporan tambahan diperlukan untuk menangani beban kerja tersebut. Penerapan scale-out memerlukan lisensi Edisi Perusahaan. Manfaat penerapan scale-out termasuk memberi pelanggan penyeimbangan beban untuk throughput yang lebih tinggi, ketersediaan tinggi, serta kemampuan untuk mengelompokkan pemrosesan server laporan.

Manfaatkan Snapshot di tempat yang masuk akal. Jika Anda memiliki laporan yang menggunakan data lama, pertimbangkan untuk menggunakan Snapshot sehingga tampilan berikutnya dari laporan tersebut menggunakan Snapshot daripada harus membuat seluruh laporan lagi.

Langganan Berbasis Data dapat digunakan untuk menjalankan laporan dan mengirimkan konten berdasarkan basis pelanggan dan sesuai jadwal. Berdasarkan jadwal, banyak dari laporan ini dapat dijalankan setelah pemrosesan data selesai, jauh sebelum pengguna tiba di tempat kerja, dalam waktu yang tidak terlalu sibuk untuk lingkungan.

DBA harus terbiasa dengan logging eksekusi karena dapat membantu mengidentifikasi laporan yang dapat menjadi kandidat untuk caching serta laporan yang harus dilihat untuk peningkatan kinerja berdasarkan pemrosesan eksekusi. Logging eksekusi memberikan wawasan tentang hal-hal seperti seberapa sering laporan dijalankan, format yang paling banyak diminta, dan persentase pemrosesan yang terkait dengan fase proses laporan. Data ini dapat diakses menggunakan tampilan bawaan untuk ExecutionLog, ExecutionLog2, dan ExecutionLog3.

Penyetelan Umum

Untuk database pengguna yang digunakan oleh laporan dan instans yang menyimpan ReportServer dan ReportServerTempDB, Anda ingin melacak dan kinerja dasar. Anda perlu memantau penggunaan memori/disk/CPU, I/O jaringan, penggunaan tempdb, menunggu, dan penghitung lainnya untuk mengetahui apa yang normal untuk keseluruhan beban kerja sistem tersebut. Jika pengguna mulai melaporkan masalah, Anda harus dapat mengetahui apakah penggunaan saat ini normal atau tidak. Jika Anda tidak memantaunya, bagaimana Anda bisa mengukurnya?

Selain pemantauan dan baseline, praktik terbaik yang diterima industri harus ada misalnya. Saya telah membahas pengaturan memori, pemeliharaan indeks, statistik, MAXDOP, dan ambang biaya untuk paralelisme dalam artikel sebelumnya, Common SQL Server Mishaps.

Keajaiban nyata untuk membuat laporan berjalan lebih cepat adalah mengoptimalkan laporan itu. Laporan pada dasarnya hanyalah kueri lain. Untuk menyesuaikan laporan yang lambat, itu biasanya berarti Anda perlu membuat indeks untuk laporan tertentu atau menyesuaikan kode di dalam laporan. Jika ini adalah laporan yang mengenai database OLTP, maka membuat indeks untuk laporan dapat memengaruhi sistem OLTP dengan menggunakan lebih banyak ruang, menghasilkan I/O tambahan untuk pembaruan, penyisipan, dan penghapusan, dan menimbulkan overhead tambahan untuk mempertahankan indeks tersebut. Anda harus menyeimbangkan risiko vs. imbalan. Beberapa pelanggan dapat memisahkan database pelaporan dari OLTP dengan menggunakan replikasi transaksional dan ini memungkinkan untuk mengindeks database pelaporan tanpa mempengaruhi database OTLP.

Meskipun Anda dapat melacak penggunaan laporan menggunakan ExecutionLog, Anda harus meneliti instance database pengguna untuk kueri berbiaya tinggi dan berjalan lama untuk peluang penyetelan juga. DMV dan Query Store juga sangat membantu, tetapi alat pemantauan seperti SQL Sentry bisa jauh lebih kuat dan fleksibel. SQL Sentry tidak memiliki "dasbor Layanan Pelaporan", tetapi Anda dapat membuat tampilan kalender acara SSRS, dengan mudah memfilter metrik dan laporan bawaan untuk fokus pada aktivitas SSRS, dan membuat Kondisi Penasihat yang kuat untuk memantau aspek yang tepat dari Layanan Pelaporan yang Anda pedulikan (dan tidak ada suara yang tidak Anda pedulikan). Bahkan jika Anda tidak menjalankan SSRS pada mesin SQL Server, Anda masih dapat menggunakan Win Sentry untuk mendapatkan wawasan kinerja yang kaya tentang proses saat ini dan riwayat aktivitas tingkat layanan.

Kesimpulan

Tuning Layanan Pelaporan SQL Server memiliki beberapa karakteristik unik, namun penyetelan kinerja standar masih berlaku untuk mengoptimalkan laporan dan memantau database ReportServer dan ReportServerTempDB. Mencadangkan kunci enkripsi diperlukan untuk pemulihan bencana atau upaya migrasi. Untuk lebih memahami penggunaan laporan, DBA harus mulai menggunakan ExcecutionLog.