Pertimbangan Desain SQL Server

Manajer Operasi Pusat Sistem bergantung pada Microsoft SQL Server untuk mendukung database audit operasional, gudang data, dan ACS. Database ini sangat penting dan dibuat selama penyebaran server manajemen pertama atau kolektor ACS di grup manajemen Anda.

Di lingkungan lab atau penyebaran skala kecil Operations Manager, SQL Server dapat dikolokasikan di server manajemen pertama dalam grup manajemen.

Dalam penyebaran terdistribusi skala menengah hingga perusahaan, instans SQL Server harus terletak di server mandiri khusus atau dalam konfigurasi ketersediaan tinggi SQL Server. Dalam kedua kasus, SQL Server harus sudah ada dan dapat diakses sebelum Anda memulai penginstalan server manajemen pertama atau pengumpul ACS.

Kami tidak merekomendasikan pemanfaatan database Operations Manager dari Instans SQL yang memiliki database aplikasi lain untuk menghindari potensi masalah dengan I/O dan pembatasan sumber daya perangkat keras lainnya.

Penting

Operations Manager tidak mendukung instans SQL dari Platform as a Service (PaaS), termasuk produk seperti Azure SQL Managed Instance atau Amazon Relational Database Service (AWS RDS). Silakan gunakan instans SQL Server yang diinstal pada komputer Windows. Satu-satunya pengecualian untuk ini adalah dalam Azure Monitor SCOM Managed Instance, yang menggunakan Azure SQL MI, dan tidak dapat dikonfigurasi ulang.

Persyaratan SQL Server

Versi SQL Server Enterprise & Standard Edition berikut didukung untuk penginstalan versi Manajer Operasi Pusat Sistem yang ada untuk menghosting Server Pelaporan, Operasional, Gudang Data, dan database ACS:

• SQL Server 2022 dengan Pembaruan Kumulatif minimum 11 (CU11) atau yang lebih baru seperti yang tersedia di sini
• SQL Server 2019 dengan Pembaruan Kumulatif minimum 8 (CU8) atau pembaruan yang lebih baru jika tersedia di sini
• SQL Server 2017 dengan pembaruan terbaru yang tersedia seperti yang tersedia di sini

Sebelum memutakhirkan SQL Server, lihat informasi peningkatan untuk informasi peningkatan 2017+ dan untuk SQL 2019.

Driver SQL Server

Driver SQL Server OLE DB dan ODBC perlu diinstal pada semua server manajemen dan server konsol web, karena komponen ini langsung berinteraksi dengan database dan driver ini memungkinkan akses tingkat API ke SQL.

Disarankan untuk menggunakan koneksi SQL Server terenkripsi; saat melakukannya, Anda perlu menginstal versi terbaru driver SQL:

• Driver Microsoft OLE DB versi terbaru.
• Microsoft ODBC Driver versi terbaru.

Informasi selengkapnya tentang mengonfigurasi enkripsi koneksi SQL dapat ditemukan di sini: Mengonfigurasi Mesin Database SQL Server untuk mengenkripsi koneksi

Jika tidak menggunakan koneksi SQL terenkripsi, gunakan rilis driver SQL sebelumnya yang tidak memberlakukan enkripsi:

• Microsoft ODBC Driver versi 17.10.6.
• Microsoft OLE DB Driver versi 18.7.4.

Pembaruan SQL Server

Masing-masing komponen SQL Server berikut yang mendukung infrastruktur Manajer Operasi harus berada di versi utama SQL Server yang sama:

• Instans mesin database SQL Server yang menghosting salah satu database Manajer Operasi, termasuk:
  • Manajer Operasi
  • OperationManagerDW
  • Database SSRS ReportServer dan ReportServerTempDB
• Instans SQL Server Reporting Services (SSRS).

Mode autentikasi SQL Server

Secara default, SQL beroperasi dalam konfigurasi autentikasi Mode Campuran. Namun, Operations Manager hanya menggunakan autentikasi Windows untuk berkomunikasi dengan SQL Server. Jika dibiarkan default, pengaturan Autentikasi Mode Campuran SQL akan tetap berfungsi jika tidak ada akun lokal yang memiliki peran db_owner. Akun lokal dengan peran db_owner diketahui menyebabkan masalah dengan Manajer Operasi.

Sangat disarankan untuk menghapus peran db_owner dari semua akun lokal sebelum menginstal produk dan tidak menambahkan peran db_owner ke akun lokal apa pun setelah penginstalan.

Pertimbangan lain

Pertimbangan perangkat keras dan perangkat lunak lainnya berlaku dalam perencanaan desain Anda:

• IT disarankan untuk memiliki disk SQL dalam format file NTFS.
• Anda harus memiliki setidaknya 1 GB ruang disk kosong untuk database operasional dan gudang data, ini diberlakukan pada saat pembuatan database. Perlu diingat bahwa pemanfaatan disk database akan tumbuh secara signifikan setelah penyiapan, pastikan untuk memiliki banyak ruang disk kosong di atas persyaratan dasar ini.
• .NET Framework 4 diperlukan.
• .NET Framework 4.8 didukung dari Operations Manager 2022.
• Server Pelaporan tidak didukung di Windows Server Core.
• Pengaturan kolase SQL Server harus menjadi salah satu jenis yang didukung seperti yang dijelaskan di bagian: pengaturan kolase SQL Server.
• Pencarian Teks Lengkap SQL Server diperlukan untuk semua instans mesin database SQL Server yang menghosting salah satu database Manajer Operasi.
• Opsi penginstalan Windows Server (Server Core, Server dengan Pengalaman Desktop, dan Nano Server) yang didukung oleh komponen database Manajer Operasi didasarkan pada opsi penginstalan apa yang didukung oleh SQL Server.

Untuk informasi selengkapnya, lihat bagian Persyaratan Perangkat Lunak & Perangkat Keras di bawah dokumentasi penginstalan dan perencanaan SQL Server di sini: Merencanakan penginstalan SQL Server

Pengaturan kolasi SQL Server

Kolase SQL Server dan Windows berikut ini didukung di System Center Operations Manager.

Nota

Untuk menghindari masalah kompatibilitas dalam membandingkan atau menyalin operasi, kami sarankan Anda menggunakan kolase yang sama untuk SQL dan Operations Manager DB.

Kolasi SQL Server

• SQL_Latin1_General_CP1_CI_AS

Pengurutan Windows

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Tionghoa_Sederhana_Pinyin_100_CI_AS
• Penghitungan_Garis_Tionghoa_Tradisional_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Spanyol_Tradisional_CI_AS
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

Jika instans SQL Server Anda tidak dikonfigurasi dengan salah satu kolasi yang didukung yang tercantum sebelumnya, melakukan instalasi baru Manajer Operasi gagal. Namun, upgrade di tempat berhasil diselesaikan.

Konfigurasi firewall

Manajer Operasi bergantung pada SQL Server untuk menghosting databasenya dan platform pelaporan untuk menganalisis dan menyajikan data operasional historis. Peran server manajemen, Operasi, dan konsol Web harus berhasil berkomunikasi dengan SQL Server, dan penting untuk memahami jalur komunikasi dan port untuk mengonfigurasi lingkungan Anda dengan benar.

Jika merancang penyebaran terdistribusi yang menggunakan Grup Ketersediaan AlwaysOn SQL, ada pengaturan konfigurasi firewall tambahan yang perlu disertakan dalam strategi keamanan firewall Anda.

Tabel berikut mengidentifikasi port firewall yang diperlukan oleh SQL Server agar server manajemen dapat berkomunikasi dengan database:

Skenario	Pelabuhan	Arah	Peran Manajer Operasi
SQL Server menghosting database Manajer Operasi	TCP 1433 *	Masukan	server manajemen dan konsol Web (untuk Application Advisor dan Diagnostik Aplikasi)
Layanan Browser SQL Server	UDP 1434	Masukan	server manajemen
Koneksi Admin Khusus SQL Server	TCP 1434	Masukan	server manajemen
Port lain yang digunakan oleh SQL Server - Panggilan prosedur jarak jauh dari Microsoft (MS RPC) - Instrumentasi Manajemen Windows (WMI) - Koordinator Transaksi Terdistribusi Microsoft (MS DTC)	TCP 135	Masukan	server manajemen
Pendengar Grup Ketersediaan AlwaysOn SQL Server	Port yang dikonfigurasi oleh administrator	Masukan	server manajemen
SQL Server Reporting Services menghosting Pelaporan Server dari Operations Manager	TCP 80 (default)/443 (SSL)	Masukan	server manajemen dan konsol Operasi

Nota

Meskipun TCP 1433 adalah port standar untuk instans default Mesin Database, saat Anda membuat instans bernama di SQL Server mandiri atau telah menyebarkan SQL Always On Availability Group, port kustom ditentukan dan harus dicatat untuk referensi sehingga Anda dapat mengonfigurasi firewall dengan benar dan memasukkan informasi ini pada saat penyiapan.

Untuk gambaran umum yang lebih rinci tentang persyaratan firewall untuk SQL Server, lihat Mengonfigurasi Windows Firewall untuk Mengizinkan Akses SQL Server.

Pertimbangan kapasitas dan penyimpanan

Database Manajer Operasi

Database Manajer Operasi adalah database SQL Server yang berisi semua data yang diperlukan oleh Manajer Operasi untuk pemantauan sehari-hari. Ukuran dan konfigurasi server database sangat penting untuk performa keseluruhan grup manajemen. Sumber daya paling penting yang digunakan oleh database Operations Manager adalah subsistem penyimpanan, tetapi CPU dan RAM juga signifikan.

Faktor-faktor yang memengaruhi beban pada database Operations Manager meliputi:

• Tingkat pengumpulan data operasional.
  • Tingkat pengumpulan data operasional dipengaruhi oleh faktor-faktor seperti jumlah paket manajemen yang diimpor, jumlah agen yang ditambahkan, dan jenis komputer yang dipantau. Misalnya, agen yang memantau komputer desktop penting bisnis mengumpulkan lebih sedikit data dibandingkan dengan agen yang memantau server yang menjalankan SQL Server dengan beberapa database.
• Laju perubahan ruang instans.
  • Memperbarui data yang ada dalam database Operations Manager bersifat intensif sumber daya dibandingkan dengan menulis data operasional baru. Selain itu, ketika ada perubahan dalam data ruang instans, server manajemen perlu membuat lebih banyak kueri ke database untuk menghitung konfigurasi dan perubahan grup. Laju perubahan ruang instans meningkat saat mengimpor paket manajemen baru atau menambahkan agen baru ke grup manajemen.
• Jumlah Konsol Operasi dan koneksi SDK lainnya yang berjalan secara bersamaan juga memengaruhi beban pada database.
  • Setiap konsol Operasi membaca data dari database Operations Manager. Mengkueri data ini mengonsumsi sumber daya I/O penyimpanan dalam jumlah besar, waktu CPU, dan RAM. Konsol operasi yang menampilkan sejumlah besar data operasional dalam Tampilan Peristiwa, Tampilan Status, Tampilan Pemberitahuan, dan Tampilan Data Performa cenderung menyebabkan beban terbesar pada database.

Basis Data Manajer Operasi adalah titik kegagalan tunggal untuk grup pengelolaan, sehingga dapat memiliki ketersediaan tinggi dengan menggunakan konfigurasi failover yang didukung seperti SQL Server Always On Availability Groups atau Instans Kluster Failover.

Anda dapat menyiapkan dan meningkatkan database Operations Manager dengan penyiapan SQL Always-On yang ada tanpa perlu perubahan konfigurasi setelahnya.

Mengaktifkan SQL Broker pada database Operations Manager

Manajer Operasi Pusat Sistem bergantung pada SQL Server Service Broker untuk menerapkan semua operasi tugas. Jika SQL Server Service Broker dinonaktifkan, semua operasi tugas terpengaruh. Perilaku yang dihasilkan dapat bervariasi sesuai dengan tugas yang dimulai. Oleh karena itu, penting untuk memeriksa status SQL Server Service Broker setiap kali perilaku tak terduga diamati di sekitar tugas di Manajer Operasi Pusat Sistem.

Untuk mengaktifkan SQL Server Service Broker, ikuti langkah-langkah berikut:

1. Jalankan kueri SQL berikut untuk memeriksa apakah broker sudah diaktifkan, yang ditunjukkan oleh hasil 1 (satu) di bidang is_broker_enabled:

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. Jika nilai yang ditampilkan di bidang is_broker_enabled0 (nol), jalankan pernyataan SQL berikut untuk mengaktifkan broker:

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

Database Gudang Data untuk Manajer Operasi

Nota

Gudang Data Manajer Operasi juga disebut sebagai database "Gudang Data Pelaporan", atau hanya "Gudang Data" dalam beberapa dokumentasi.

System Center - Operations Manager menyisipkan data ke gudang data dalam hampir waktu nyata, sehingga penting untuk memiliki kapasitas yang memadai pada server ini yang mendukung penulisan semua data yang dikumpulkan ke gudang data. Seperti halnya database Operations Manager, sumber daya yang paling penting pada gudang data adalah subsistem I/O penyimpanan. Pada sebagian besar sistem, beban pada gudang data mirip dengan database Operations Manager, tetapi dapat bervariasi. Selain itu, beban kerja pada gudang data oleh pelaporan berbeda dengan beban yang diberikan pada database Operations Manager oleh penggunaan konsol Operasi.

Faktor-faktor yang memengaruhi beban pada gudang data meliputi:

• Tingkat pengumpulan data operasional.
  • Gudang data melakukan komputasi dan menyimpan data agregat, bersama dengan sejumlah data mentah yang terbatas, untuk memungkinkan pelaporan yang lebih efisien. Akibatnya, biaya pengumpulan data operasional ke gudang data sedikit lebih tinggi dibandingkan dengan database Operations Manager. Namun, biaya ini diimbangi oleh berkurangnya biaya pemrosesan data penemuan di gudang data dibandingkan dengan database Operations Manager.
• Jumlah pengguna pelaporan bersamaan atau pembuatan laporan terjadwal.
  • Setiap pengguna pelaporan dapat menambahkan beban yang signifikan pada sistem karena laporan sering meringkas data dalam volume besar. Kebutuhan kapasitas keseluruhan dipengaruhi oleh jumlah laporan yang dijalankan secara bersamaan dan jenis laporan yang dijalankan. Laporan yang mengkueri rentang tanggal besar atau sejumlah besar objek memerlukan sumber daya sistem tambahan.

Berdasarkan faktor-faktor ini, ada beberapa praktik yang direkomendasikan untuk dipertimbangkan saat mengukur gudang data:

• Pilih subsistem penyimpanan yang sesuai.
  • Karena gudang data adalah bagian integral dari aliran data keseluruhan melalui grup manajemen, memilih subsistem penyimpanan yang sesuai untuk gudang data adalah penting. Seperti halnya database Manajer Operasi, RAID 0 + 1 sering menjadi pilihan terbaik. Secara umum, subsistem penyimpanan untuk gudang data harus mirip dengan subsistem penyimpanan untuk database Operations Manager, dan panduan yang berlaku untuk database Operations Manager juga berlaku untuk gudang data.
• Pertimbangkan penempatan log data yang sesuai vs. log transaksi.
  • Adapun database Operations Manager, memisahkan data SQL dan log transaksi sering kali merupakan pilihan yang tepat saat Anda meningkatkan jumlah agen. Jika database Operations Manager dan gudang data terletak di server yang sama dan Anda ingin memisahkan data dan log transaksi, Anda harus menempatkan log transaksi untuk database Operations Manager pada volume fisik dan spindel disk terpisah dari gudang data untuk menerima manfaat apa pun. File data untuk database Operations Manager dan gudang data dapat berbagi volume fisik yang sama selama volume menyediakan kapasitas yang memadai dan performa I/O disk tidak berdampak negatif pada fungsionalitas pemantauan dan pelaporan.
• Pertimbangkan untuk menempatkan gudang data di server terpisah dari database Operations Manager.
  • Meskipun penyebaran skala yang lebih kecil sering dapat mengonsolidasikan database Operations Manager dan gudang data di server yang sama, ada baiknya untuk memisahkannya saat Anda meningkatkan jumlah agen dan volume data operasional yang masuk. Ketika gudang data dan Server Pelaporan berada di server terpisah dari database Manajer Operasi, Anda mengalami performa pelaporan yang lebih baik.

Database Gudang Data Operations Manager adalah satu-satunya sumber kegagalan untuk grup manajemen, sehingga dapat memiliki ketersediaan tinggi menggunakan konfigurasi failover yang didukung seperti SQL Server Always On Availability Groups atau Instans Kluster Failover.

SQL Server Always On (Fitur Keberlanjutan Tinggi)

Grup ketersediaan AlwaysOn SQL Server mendukung lingkungan failover untuk sekumpulan database pengguna yang diskrit (database ketersediaan). Setiap set database ketersediaan dihosting pada replika ketersediaan.

Dengan System Center 2016 dan versi yang lebih baru - Operations Manager, SQL Always On lebih disukai daripada klaster failover untuk menyediakan ketersediaan tinggi untuk database. Semua database kecuali penginstalan Reporting Services mode asli, yang menggunakan dua database untuk memisahkan penyimpanan data persisten dari persyaratan penyimpanan sementara, dapat dihosting di Grup Ketersediaan AlwaysOn.

Untuk menyiapkan grup ketersediaan, Anda menyebarkan kluster Windows Server Failover Clustering (WSFC) untuk menghosting replika ketersediaan, dan mengaktifkan Always On pada node kluster. Anda kemudian dapat menambahkan database SQL Server Manajer Operasi sebagai database ketersediaan.

• Pelajari selengkapnya tentang prasyarat AlwaysOn.
• Pelajari selengkapnya tentang menyiapkan WSFC untuk grup ketersediaan AlwaysOn.
• Pelajari selengkapnya tentang menyiapkan grup ketersediaan.

Saran

Dimulai dengan Operations Manager 2022, Anda dapat menyiapkan dan meningkatkan database Operations Manager dengan penyiapan SQL Always-On yang ada tanpa perlu perubahan konfigurasi pasca.

Untuk menyiapkan grup ketersediaan, Anda menyebarkan kluster Windows Server Failover Clustering (WSFC) untuk menghosting replika ketersediaan, dan mengaktifkan Always On pada node kluster. Anda kemudian dapat menambahkan database SQL Server Manajer Operasi sebagai database ketersediaan.

• Pelajari selengkapnya tentang prasyarat AlwaysOn.
• Pelajari selengkapnya tentang menyiapkan WSFC untuk grup ketersediaan AlwaysOn.
• Pelajari selengkapnya tentang menyiapkan grup ketersediaan.

Nota

Setelah menyebarkan Operations Manager pada simpul server SQL yang berpartisipasi dalam SQL Always On, untuk mengaktifkan keamanan ketat CLR, jalankan skrip SQL pada setiap database Operations Manager.

String multisubnet

Manajer Operasi tidak mendukung kata kunci string koneksi (MultiSubnetFailover=True). Karena grup ketersediaan memiliki nama pendengar (listener) (dikenal sebagai nama jaringan atau Titik Akses Klien dalam Manajer Kluster WSFC) yang bergantung pada beberapa alamat IP dari subnet yang berbeda, seperti ketika Anda menerapkan dalam konfigurasi failover lintas situs, permintaan koneksi dari server manajemen ke pendengar grup ketersediaan akan mengalami batas waktu koneksi.

Pendekatan yang direkomendasikan untuk mengatasi batasan ini dengan node server grup ketersediaan yang disebarkan di lingkungan multi-subnet adalah dengan:

1. Atur nama jaringan pendengar grup ketersediaan Anda untuk hanya mendaftarkan satu alamat IP aktif di DNS.
2. Konfigurasikan kluster untuk menggunakan nilai TTL rendah untuk catatan DNS terdaftar.

Pengaturan ini memungkinkan pemulihan dan resolusi nama kluster yang lebih cepat dengan alamat IP baru saat melakukan failover ke node di subnet yang berbeda.

Jalankan perintah PowerShell berikut pada salah satu simpul SQL untuk mengubah pengaturan ini:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

Jika Anda menggunakan Always On dengan nama pendengar, Anda juga harus membuat perubahan konfigurasi ini pada pendengar. Untuk informasi selengkapnya tentang mengonfigurasi listener grup ketersediaan, lihat dokumentasi di sini: Mengonfigurasi listener grup ketersediaan - SQL Server Always On.

Perintah PowerShell berikut dapat dijalankan pada simpul SQL yang saat ini menghosting pendengar untuk mengubah pengaturannya:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Ketika instans SQL AlwaysOn atau terkluster digunakan untuk ketersediaan tinggi, Anda harus mengaktifkan fitur pemulihan otomatis di server manajemen Anda untuk menghindari layanan Akses Data Manajer Operasi dimulai ulang kapan saja terjadi failover antar node. Untuk informasi konfigurasi, lihat artikel KB berikut ini Layanan Manajemen Pusat Sistem berhenti merespons setelah instans SQL Server offline.

Optimalkan SQL Server

Pengalaman dukungan telah menunjukkan bahwa masalah performa biasanya tidak disebabkan oleh pemanfaatan sumber daya yang tinggi (yaitu prosesor atau memori) dengan SQL Server itu sendiri; sebaliknya masalah ini terkait langsung dengan konfigurasi subsistem penyimpanan. Hambatan kinerja biasanya dikaitkan dengan tidak mengikuti konfigurasi yang direkomendasikan pada penyimpanan yang disediakan untuk instans database SQL Server. Contoh tersebut adalah:

• Alokasi spindle yang tidak cukup untuk LUN untuk mendukung persyaratan IO Operations Manager.
• Hosting log transaksi dan file database pada volume yang sama. Kedua beban kerja ini memiliki karakteristik IO dan latensi yang berbeda.
• Konfigurasi TempDB salah sehubungan dengan penempatan, ukuran, dan sebagainya.
• Ketidakselarasan partisi disk pada volume yang menghosting log transaksi database, file database, dan TempDB.
• Mengabaikan konfigurasi SQL Server dasar seperti menggunakan AUTOGROW untuk database dan file log transaksi, pengaturan MAXDOP untuk paralelisme kueri, membuat beberapa file data TempDB per inti CPU, dan sebagainya.

Konfigurasi penyimpanan adalah salah satu komponen penting untuk penyebaran SQL Server untuk Operations Manager. Server database cenderung sangat terikat I/O karena aktivitas baca dan tulis database yang ketat dan pemrosesan log transaksi. Pola perilaku I/O Operations Manager biasanya 80 menulis% dan 20 pembacaan%. Akibatnya, konfigurasi subsistem I/O yang tidak tepat dapat menyebabkan performa dan pengoperasian sistem SQL Server yang buruk dan menjadi terlihat di Operations Manager.

Penting untuk menguji desain SQL Server dengan melakukan pengujian throughput subsistem IO sebelum menyebarkan SQL Server. Pastikan bahwa pengujian ini dapat mencapai persyaratan IO Anda dengan latensi yang dapat diterima. Gunakan Utilitas Diskspd untuk mengevaluasi kapasitas I/O subsistem penyimpanan yang mendukung SQL Server. Artikel blog berikut, yang ditulis oleh anggota tim File Server dalam grup produk, memberikan panduan dan rekomendasi terperinci tentang cara melakukan pengujian stres menggunakan alat ini - DiskSpd, PowerShell, dan performa penyimpanan: mengukur IOP, throughput, dan latensi untuk disk lokal dan berbagi file SMB.

Ukuran unit alokasi NTFS

Penyelarasan volume, yang biasa disebut sebagai penyelarasan sektor, harus dilakukan pada sistem file (NTFS) setiap kali volume dibuat pada perangkat RAID. Kegagalan untuk melakukannya dapat menyebabkan penurunan performa yang signifikan dan paling umum merupakan hasil dari ketidakselarasan partisi dengan batas unit stripe. Ini juga dapat menyebabkan ketidakselarasan cache perangkat keras, yang mengakibatkan pemanfaatan cache array yang tidak efisien.

Saat memformat partisi yang digunakan untuk file data SQL Server, rekomendasinya adalah menggunakan ukuran unit alokasi 64 KB (yaitu, 65.536 byte) untuk data, log, dan TempDB. Namun, ketahuilah bahwa menggunakan ukuran unit alokasi lebih besar dari 4-KB mengakibatkan ketidakmampuan untuk menggunakan kompresi NTFS pada volume. Meskipun SQL Server mendukung data baca-saja pada volume terkompresi, tidak disarankan.

Memori cadangan

Nota

Banyak informasi di bagian ini berasal dari Jonathan Kehayias dalam posting blognya Berapa banyak memori yang sebenarnya dibutuhkan SQL Server saya? (sqlskills.com).

Tidak selalu mudah untuk mengidentifikasi jumlah memori fisik dan prosesor yang tepat untuk dialokasikan untuk SQL Server dalam mendukung System Center Operations Manager (atau untuk beban kerja lain di luar produk ini). Kalkulator ukuran yang disediakan oleh grup produk memberikan panduan berdasarkan skala beban kerja, tetapi rekomendasinya didasarkan pada pengujian yang dilakukan di lingkungan lab yang mungkin atau mungkin tidak selaras dengan beban kerja dan konfigurasi Anda yang sebenarnya.

SQL Server memungkinkan Anda mengonfigurasi jumlah memori minimum dan maksimum yang akan dicadangkan dan digunakan oleh prosesnya. Secara default, SQL Server dapat mengubah persyaratan memorinya secara dinamis berdasarkan sumber daya sistem yang tersedia. Pengaturan default untuk memori server min adalah 0, dan pengaturan default untuk memori server maks adalah 2.147.483.647 MB.

Masalah terkait performa dan memori dapat muncul jika Anda tidak menetapkan nilai yang sesuai untuk memori server maks . Banyak faktor memengaruhi berapa banyak memori yang perlu Anda alokasikan ke SQL Server untuk memastikan bahwa sistem operasi dapat mendukung proses lain yang berjalan pada sistem tersebut, seperti kartu HBA, agen manajemen, dan pemindaian real-time anti-virus. Jika tidak diatur memori yang cukup, sistem operasi (OS) dan SQL akan menggunakan swap ke disk. Hal ini dapat menyebabkan I/O disk meningkat, semakin mengurangi performa dan menciptakan efek domino yang membuat penurunan performa menjadi terlihat di Operations Manager.

Sebaiknya tentukan setidaknya 4 GB RAM untuk memori server min. Ini harus dilakukan untuk setiap simpul SQL yang menghosting salah satu database Operations Manager (operasional, gudang data, ACS).

Untuk memori server maksimum, kami sarankan Anda awalnya sebaiknya memesan total:

• RAM 1 GB untuk OS
• 1 GB RAM untuk setiap 4 GB RAM terpasang (hingga 16 GB RAM)
• Diperlukan tambahan 1 GB RAM untuk setiap 8 GB RAM yang diinstal, jika total RAM di atas 16 GB.

Setelah Anda mengatur nilai-nilai ini, pantau penghitung Memory\Available MBytes di Windows untuk menentukan apakah Anda dapat meningkatkan memori yang tersedia untuk SQL Server. Windows menandakan bahwa memori fisik yang tersedia hampir habis pada 96 MB, jadi idealnya penghitung tidak boleh berjalan lebih rendah dari sekitar 200-300 MB, untuk memastikan Anda memiliki buffer. Untuk server dengan RAM 256 GB atau lebih tinggi, pastikan tidak berjalan lebih rendah dari 1 GB.

Perlu diingat bahwa perhitungan ini mengasumsikan Bahwa Anda ingin SQL Server dapat menggunakan semua memori yang tersedia, kecuali Anda memodifikasinya untuk memperhitungkan aplikasi lain. Pertimbangkan persyaratan memori khusus untuk OS Anda, aplikasi lainnya, tumpukan utas SQL Server, dan alokator multipage lainnya. Rumus umumnya adalah ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), yang memori untuk tumpukan thread = ((max worker threads) (stack size)). Ukuran tumpukan adalah 512 KB untuk sistem x86, 2 MB untuk sistem x64, dan 4 MB untuk sistem IA64, serta Anda dapat menemukan nilai untuk thread pekerja maksimum di kolom "max_worker_count" dari "sys.dm_os_sys_info".

Pertimbangan ini juga berlaku untuk persyaratan memori agar SQL Server berjalan di komputer virtual. Karena SQL Server dirancang untuk menyimpan data di kumpulan buffer, dan menggunakan memori sebanyak mungkin, mungkin sulit untuk menentukan jumlah RAM ideal yang diperlukan. Saat mengurangi memori yang dialokasikan ke instans SQL Server, Anda dapat mencapai titik di mana jatah memori yang lebih rendah diperdagangkan untuk akses I/O disk yang lebih tinggi.

Untuk mengonfigurasi memori SQL Server di lingkungan yang mengalami over-provisioning, mulailah dengan memantau lingkungan dan metrik performa saat ini, termasuk Manajer Buffer SQL Server masa hidup halaman dan halaman membaca/detik serta disk fisik membaca/detik nilai. Jika lingkungan memiliki memori berlebih, masa hidup halaman akan meningkat dengan nilai satu setiap detik tanpa penurunan di bawah beban kerja, karena penembolokan; nilai halaman yang dibaca per detik oleh Pengelola Buffer SQL Server akan rendah setelah cache naik; dan nilai pembacaan disk per detik oleh Disk Fisik juga akan tetap rendah.

Setelah Anda memahami garis besar lingkungan, Anda dapat mengurangi memori server maks sebesar 1 GB, lalu melihat bagaimana dampaknya terhadap penghitung kinerja Anda (setelah pembilasan cache awal mereda). Jika metrik tetap dapat diterima, kurangi dengan 1 GB lain, lalu pantau lagi, ulangi seperti yang diinginkan hingga Anda menentukan konfigurasi yang ideal.

Untuk informasi selengkapnya, lihat opsi konfigurasi memori Server.

Optimalkan TempDB

Ukuran dan penempatan fisik database TempDB dapat memengaruhi performa Operations Manager. Misalnya, jika ukuran yang ditentukan untuk TempDB terlalu kecil, proses pemrosesan sistem mungkin akan dipakai untuk menambah ukuran TempDB secara otomatis ke ukuran yang diperlukan guna mendukung beban kerja setiap kali Anda memulai ulang instans SQL Server. Untuk mencapai performa TempDB yang optimal, kami merekomendasikan konfigurasi berikut untuk TempDB di lingkungan produksi:

• Atur model pemulihan TempDB ke SIMPLE.
  • Model ini secara otomatis memulihkan ruang log untuk menjaga persyaratan ruang tetap kecil.
• Pra-alokasikan ruang untuk semua file TempDB dengan mengatur ukuran file ke nilai yang cukup besar untuk mengakomodasi beban kerja umum di lingkungan. Ini mencegah TempDB berkembang terlalu sering, yang dapat memengaruhi performa. Database TempDB dapat diatur ke autogrow, tetapi ini harus digunakan untuk meningkatkan ruang disk untuk pengecualian yang tidak direncanakan.
• Buat file sebanyak yang diperlukan untuk memaksimalkan bandwidth disk.
  • Penggunaan beberapa file mengurangi persaingan penyimpanan TempDB dan menghasilkan skalabilitas yang lebih baik. Namun, jangan membuat terlalu banyak file karena dapat mengurangi performa dan meningkatkan overhead manajemen.
  • Sebagai pedoman umum, buat satu file data untuk setiap prosesor logis di server (memperhitungkan pengaturan masker afinitas apa pun) lalu sesuaikan jumlah file ke atas atau ke bawah seperlunya.
  • Sebagai aturan umum, jika jumlah prosesor logis kurang dari atau sama dengan 8, gunakan jumlah file data yang sama dengan prosesor logis.
    • Jika jumlah prosesor logis lebih besar dari 8, gunakan delapan file data dan kemudian jika pertikaian berlanjut, tingkatkan jumlah file data dengan kelipatan 4 (hingga jumlah prosesor logis) hingga pertikaian dikurangi ke tingkat yang dapat diterima atau buat perubahan pada beban kerja/kode.
    • Jika ketidakcocokan tidak berkurang, Anda mungkin harus meningkatkan jumlah file data lebih banyak.
• Buat setiap file data berukuran sama, memungkinkan performa pengisian proporsional yang optimal.
  • Ukuran file data yang sama sangat penting karena algoritma pengisian proporsional didasarkan pada ukuran file. Jika file data dibuat dengan ukuran yang tidak sama, algoritma pengisian proporsional akan cenderung menggunakan file terbesar lebih sering untuk alokasi GAM, bukannya mendistribusikan alokasi di antara semua file. Dengan demikian, hal ini mengesampingkan tujuan pembuatan beberapa file data.
• Letakkan database TempDB pada subsistem I/O cepat menggunakan solid-state drive untuk performa yang paling optimal.
  • Gunakan striping disk jika terdapat banyak disk yang terpasang secara langsung.
• Letakkan database TempDB pada disk yang berbeda dari yang digunakan oleh database pengguna.

Untuk mengonfigurasi TempDB, Anda dapat menjalankan kueri berikut atau mengubah propertinya di Management Studio.

USE [TempDB]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [TempDB] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'TempDB', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [TempDB] ADD FILE ( NAME = N'TempDB2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TempDB2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

Jalankan kueri T-SQL SELECT * from sys.sysprocesses untuk mendeteksi ketidakcocokan alokasi halaman untuk database TempDB. Dalam output tabel sistem, sumber daya tunggu dapat muncul sebagai "2:1:1" (Halaman PFS) atau "2:1:3" (Halaman Peta Alokasi Global Bersama). Tergantung pada tingkat ketidakcocokan, pengaturan ini dapat menyebabkan SQL Server tampak tidak responsif untuk waktu yang singkat. Pendekatan lain adalah memeriksa Tampilan Manajemen Dinamis [sys.dm_exec_request atau sys.dm_os_waiting_tasks]. Hasilnya menunjukkan bahwa permintaan atau tugas ini menunggu sumber daya TempDB dan memiliki nilai serupa seperti yang disorot sebelumnya saat Anda menjalankan kueri sys.sysprocesses.

Jika rekomendasi sebelumnya tidak secara signifikan mengurangi pertikaian alokasi dan ketidakcocokan ada di halaman SGAM, menerapkan bendera pelacakan-T1118 dalam parameter Startup untuk SQL Server sehingga bendera pelacakan tetap berlaku bahkan setelah SQL Server didaur ulang. Di bawah bendera pelacakan ini, SQL Server mengalokasikan tingkat penuh untuk setiap objek database, sehingga menghilangkan pertikaian pada halaman SGAM.

Nota

Bendera pelacakan ini memengaruhi setiap database pada instans SQL Server.

Tingkat paralelisme maks

Saran

Untuk praktik dan rekomendasi terbaik terbaru dari tim SQL Server, lihat dokumentasi mereka di sini: Mengatur tingkat maksimum opsi paralelisme untuk performa optimal

Konfigurasi default SQL Server untuk penyebaran ukuran kecil hingga menengah Manajer Operasi memadai untuk sebagian besar kebutuhan. Namun, ketika beban kerja grup manajemen meningkat ke arah skenario kelas perusahaan (biasanya lebih dari 2.000 sistem yang dikelola agen dan konfigurasi pemantauan tingkat lanjut, yang mencakup pemantauan tingkat layanan dengan transaksi sintetis tingkat lanjut, pemantauan perangkat jaringan, lintas platform, dan lain-lain), penting untuk mengoptimalkan konfigurasi SQL Server yang dijelaskan di bagian ini dari dokumen. Salah satu opsi konfigurasi yang tidak dibahas dalam panduan sebelumnya adalah MAXDOP.

Opsi konfigurasi tingkat paralelisme maksimum Microsoft SQL Server (MAXDOP) mengontrol jumlah prosesor yang digunakan untuk eksekusi kueri dalam rencana paralel. Opsi ini menentukan sumber daya komputasi dan thread yang digunakan untuk operator dari perencanaan kueri yang bekerja secara paralel. Bergantung pada apakah SQL Server disiapkan pada komputer multiproses simetris (SMP), komputer akses memori nonuniform (NUMA), atau prosesor berkemampuan hyperthreading, Anda harus mengonfigurasi tingkat maksimum opsi paralelisme dengan tepat.

Ketika SQL Server berjalan di komputer dengan lebih dari satu mikroprosesor atau CPU, SQL Server mendeteksi tingkat paralelisme terbaik, yaitu, jumlah prosesor yang digunakan untuk menjalankan satu pernyataan, untuk setiap eksekusi rencana paralel. Secara default, nilainya untuk opsi ini adalah 0, yang memungkinkan SQL Server menentukan tingkat paralelisme maksimum.

Prosedur dan kueri tersimpan yang telah ditentukan sebelumnya di Operations Manager karena berkaitan dengan operasional, gudang data, dan bahkan database audit tidak menyertakan opsi MAXDOP, karena tidak ada cara selama penginstalan untuk secara dinamis meminta berapa banyak prosesor yang disajikan ke sistem operasi, juga tidak mencoba untuk mengkodekan nilai untuk pengaturan ini, yang dapat memiliki konsekuensi negatif ketika kueri dijalankan.

Nota

Tingkat maksimum opsi konfigurasi paralelisme tidak membatasi jumlah prosesor yang digunakan SQL Server. Untuk mengonfigurasi jumlah prosesor yang digunakan SQL Server, gunakan opsi konfigurasi masker afinitas.

• Untuk server yang menggunakan lebih dari delapan prosesor, gunakan konfigurasi berikut: MAXDOP=8

• Untuk server yang menggunakan delapan atau lebih sedikit prosesor, gunakan konfigurasi berikut: MAXDOP=0 hingga N

  Saran

  Dalam konfigurasi ini, N mewakili jumlah prosesor.

• Untuk server yang memiliki NUMA yang dikonfigurasi, MAXDOP tidak boleh melebihi jumlah CPU yang ditetapkan ke setiap simpul NUMA.

• Untuk server yang mengaktifkan hyperthreading, nilai MAXDOP tidak boleh melebihi jumlah prosesor fisik.

• Untuk server yang memiliki NUMA yang dikonfigurasi dan hyperthreading diaktifkan, nilai MAXDOP tidak boleh melebihi jumlah prosesor fisik per simpul NUMA.

Anda dapat memantau jumlah pekerja paralel dengan mengkueri select * from sys.dm_os_tasks.

Dalam contoh ini, konfigurasi perangkat keras server adalah HP Blade G6 dengan prosesor inti 24 dan RAM 196 GB. Instans yang menghosting database Operations Manager memiliki pengaturan MAXMEM 64 GB. Setelah melakukan pengoptimalan yang disarankan di bagian ini, performa meningkat. Namun, kemacetan paralelisme kueri masih tetap ada. Setelah menguji nilai yang berbeda, performa paling optimal ditemukan dengan mengatur MAXDOP=4.

Ukuran database awal

Mencoba memperkirakan pertumbuhan database Operations Manager di masa mendatang, khususnya database gudang data dan operasional, dalam beberapa bulan pertama setelah penyebaran bukanlah latihan sederhana. Meskipun Operations Manager Sizing Helper cukup andal dalam memperkirakan potensi pertumbuhan berdasarkan rumus yang dikembangkan oleh grup produk melalui pengujian laboratorium mereka, alat ini tidak mempertimbangkan berbagai faktor yang dapat memengaruhi pertumbuhan dalam jangka pendek dan jangka panjang.

Ukuran database awal, seperti yang disarankan oleh Pembantu Ukuran, harus dialokasikan ke ukuran yang diprediksi untuk mengurangi fragmentasi dan overhead yang sesuai, yang dapat ditentukan pada waktu penyiapan untuk database Operasional dan Gudang Data. Jika selama penyiapan ruang penyimpanan tidak cukup tersedia, database dapat diperluas nanti dengan menggunakan SQL Management Studio dan kemudian diindeks ulang setelah itu untuk defragment dan mengoptimalkannya. Rekomendasi ini juga berlaku untuk database ACS.

Pemantauan proaktif pertumbuhan database operasional dan gudang data harus dilakukan pada siklus harian atau mingguan. Ini diperlukan untuk mengidentifikasi lonjakan pertumbuhan yang tidak terduga dan signifikan, dan mulai melakukan pemecahan masalah untuk menentukan kausalitas, baik oleh bug dalam alur kerja paket manajemen (yaitu, aturan penemuan, aturan pengumpulan performa atau peristiwa, atau aturan pemantauan atau peringatan) atau gejala lain dari paket manajemen yang tidak diidentifikasi selama fase pengujian dan jaminan kualitas dari proses manajemen rilis.

Penambahan ukuran otomatis database

Ketika ukuran file database yang dipesan menjadi penuh, SQL Server dapat secara otomatis meningkatkan ukuran dengan persentase atau dengan jumlah tetap. Selain itu, ukuran database maksimum dapat dikonfigurasi untuk mencegah mengisi semua ruang yang tersedia di disk. Secara default, database Operations Manager tidak dikonfigurasi dengan fitur autogrow yang diaktifkan; hanya database Data Warehouse dan ACS yang diaktifkan.

Hanya mengandalkan fitur autogrow sebagai langkah berjaga-jaga untuk mengantisipasi pertumbuhan yang tidak terduga. Autogrow memperkenalkan penalti performa yang harus dipertimbangkan saat berhadapan dengan database yang sangat transaksional. Penalti performa meliputi:

• Jika Anda tidak memberikan kenaikan pertumbuhan yang sesuai, fragmentasi file log atau database dapat terjadi.
• Jika Anda menjalankan transaksi yang memerlukan lebih banyak ruang log daripada yang tersedia, dan autogrow diaktifkan untuk log transaksi database tersebut, waktu yang dibutuhkan transaksi untuk diselesaikan akan mencakup waktu yang dibutuhkan log transaksi untuk tumbuh dengan jumlah yang dikonfigurasi.
• Jika Anda menjalankan transaksi besar yang memerlukan log untuk berkembang, transaksi lain yang memerlukan penulisan ke log transaksi juga harus menunggu sampai operasi perluasan selesai dilakukan.

Jika menggabungkan opsi autogrow dan autoshrink, ini dapat menimbulkan overhead yang tidak perlu. Pastikan bahwa ambang batas yang memicu operasi tumbuh dan menyusut tidak akan sering menyebabkan perubahan ukuran naik dan turun. Misalnya, Anda dapat menjalankan transaksi yang menyebabkan log transaksi tumbuh sebesar 100 MB pada saat diterapkan; beberapa waktu setelah itu penyusutan otomatis dimulai dan menyusutkan log transaksi sebesar 100 MB. Kemudian Anda menjalankan transaksi yang sama, dan itu menyebabkan log transaksi tumbuh sebesar 100 MB lagi. Dalam contoh itu, Anda membuat overhead yang tidak perlu dan berpotensi membuat fragmentasi file log, yang salah satunya dapat berdampak negatif pada performa.

Konfigurasikan kedua pengaturan ini dengan hati-hati. Konfigurasi tertentu benar-benar tergantung pada lingkungan Anda. Rekomendasi umumnya adalah meningkatkan ukuran database dengan jumlah tetap untuk mengurangi fragmentasi disk. Lihat, misalnya, gambar berikut, di mana database dikonfigurasi untuk tumbuh sebesar 1.024 MB setiap kali autogrow diperlukan.

Kebijakan failover kluster

Kluster Failover Windows Server adalah platform ketersediaan tinggi yang terus memantau koneksi jaringan dan kesehatan simpul-simpul dalam kluster. Jika node tidak dapat dijangkau melalui jaringan, maka tindakan pemulihan diambil untuk memulihkan dan membawa aplikasi dan layanan online pada node lain di kluster. Pengaturan bawaan dioptimalkan untuk kegagalan di mana terjadi kehilangan server sepenuhnya, yang dianggap sebagai kegagalan "berat". Ini akan menjadi skenario kegagalan yang tidak dapat diperbaiki seperti kegagalan perangkat keras tanpa cadangan atau sumber daya tanpa cadangan. Dalam situasi ini, server hilang dan tujuannya adalah untuk Failover Clustering mendeteksi kehilangan server dengan cepat dan segera beralih ke server lain dalam kluster. Untuk mencapai pemulihan cepat ini dari kegagalan keras, pengaturan default untuk pemantauan kesehatan kluster cukup agresif. Namun, mereka sepenuhnya dapat dikonfigurasi untuk memungkinkan fleksibilitas untuk berbagai skenario.

Pengaturan default ini memberikan kinerja terbaik bagi sebagian besar pelanggan; namun, ketika kluster direntangkan dari berjarak beberapa inci hingga mungkin bermil-mil terpisah, kluster tersebut berisiko lebih besar terpapar komponen jaringan yang lebih banyak dan berpotensi tidak dapat diandalkan di antara node. Faktor lain adalah kualitas server komoditas terus meningkat, ditambah dengan ketahanan tertambah melalui komponen redundan (seperti pasokan listrik ganda, tim NIC, dan I/O multi-jalur), jumlah kegagalan perangkat keras nonredundan berpotensi cukup jarang terjadi. Karena kegagalan keras mungkin kurang sering, beberapa pelanggan mungkin ingin menyetel kluster untuk kegagalan sementara, di mana kluster lebih tahan terhadap kegagalan jaringan singkat antara node. Dengan meningkatkan ambang kegagalan default, Anda dapat mengurangi sensitivitas terhadap masalah jaringan singkat yang berlangsung dalam waktu singkat.

Penting untuk dipahami bahwa tidak ada jawaban yang tepat di sini, dan pengaturan yang dioptimalkan dapat bervariasi menurut persyaratan bisnis dan perjanjian tingkat layanan spesifik Anda.

Virtualisasi SQL Server

Di lingkungan virtual, karena alasan performa, disarankan agar Anda menyimpan database operasional dan database gudang data pada penyimpanan terpasang langsung, dan bukan pada disk virtual. Anda dapat menggunakan utilitas Operations Manager Sizing Helper yang dirilis untuk Operations Manager 2012 untuk memperkirakan IOPS yang diperlukan dan menguji stres disk data Anda untuk memverifikasi. Performa penyimpanan dapat diuji dengan utilitas DiskSpd . Lihat juga panduan dukungan virtualisasi untuk Operations Manager sebagai tambahan wawasan tentang lingkungan 'Operations Manager' yang tervirtualisasi.

Model Always On dan model pemulihan

Meskipun tidak benar-benar pengoptimalan, pertimbangan penting mengenai Grup Ketersediaan AlwaysOn adalah fakta bahwa, berdasarkan desain, fitur ini mengharuskan database diatur dalam model pemulihan "Penuh". Artinya, log transaksi tidak pernah dibuang sampai pencadangan penuh dilakukan atau hanya log transaksi. Untuk alasan ini, strategi pencadangan bukan opsional tetapi bagian yang diperlukan dari desain AlwaysOn untuk database Operations Manager. Jika tidak, seiring waktu, disk yang berisi log transaksi terisi.

Strategi pencadangan harus memperhitungkan detail lingkungan Anda. Jadwal pencadangan umum diberikan dalam tabel berikut.

Jenis Cadangan	Jadwal
Log transaksi saja	Setiap satu jam
Penuh	Mingguan, Minggu pukul 03.00

Mengoptimalkan layanan pelaporan SQL Server

Instans Reporting Services bertindak sebagai proksi untuk akses ke data dalam database Gudang Data. Ini menghasilkan dan menampilkan laporan berdasarkan templat yang disimpan di dalam paket manajemen.

Peran Pelaporan Manajer Operasi tidak dapat diinstal secara berdampingan dengan versi sebelumnya dari peran Pelaporan dan harus diinstal dalam mode asli saja (mode terintegrasi SharePoint tidak didukung).

Di balik layar Reporting Services, ada instans Database SQL Server yang menghosting database ReportServer dan ReportServerTempDB. Rekomendasi umum mengenai penyetelan performa instans ini berlaku.

Nota

Dari SQL Server Reporting Services (SSRS) 2017 versi 14.0.600.1274 dan yang lebih baru, pengaturan keamanan default tidak mengizinkan pengunggahan ekstensi sumber daya. Ini mengakibatkan exception ResourceFileFormatNotAllowedException di Operations Manager selama penyebaran komponen pelaporan.

Untuk memperbaiki hal ini:

1. Buka SQL Management Studio.
2. Sambungkan ke instans Reporting Services Anda.
3. Klik kanan pada instans server di jendela Object Explorer.
4. Pilih properti .
5. Pilih Tingkat Lanjut di bilah sisi kiri.
6. Tambahkan *.* ke dalam daftar untuk AllowedResourceExtensionsForUpload.

Atau, Anda dapat menambahkan seluruh daftar ekstensi pelaporan Operations Manager ke dalam daftar izinkan di SSRS. Daftar dijelaskan dalam "Resolusi 2" di sini: laporan Operations Manager gagal menyebarkan

Langkah berikutnya

Untuk memahami cara mengonfigurasi hosting Gudang Data (Pelaporan) di belakang firewall, lihat Hubungkan Gudang Data (Pelaporan) Melalui Firewall.