Latihan - Skalakan kinerja beban kerja Anda

10 menit

Dalam latihan ini, Anda akan mengalami masalah yang Anda temui di latihan pertama dan meningkatkan performa dengan menskalakan lebih banyak CPU untuk Azure SQL Database. Anda akan menggunakan database yang Anda sebarkan di latihan sebelumnya.

Anda dapat menemukan semua skrip untuk latihan ini di folder 04-Performance\monitor_and_scale di repositori GitHub yang Anda kloning atau file zip yang Anda unduh.

Meningkatkan kinerja Azure SQL

Untuk menskalakan kinerja untuk masalah yang tampaknya merupakan masalah kapasitas CPU, Anda harus memutuskan apa opsi Anda lalu melanjutkan untuk menskalakan CPU dengan menggunakan antarmuka yang disediakan untuk Azure SQL.

Tentukan cara menskalakan kinerja. Karena beban kerja terikat CPU, salah satu cara untuk meningkatkan performa adalah dengan meningkatkan kapasitas atau kecepatan CPU. Pengguna SQL Server harus pindah ke komputer lain atau mengonfigurasi ulang VM untuk mendapatkan lebih banyak kapasitas CPU. Dalam beberapa kasus, bahkan administrator SQL Server mungkin tidak memiliki izin untuk membuat perubahan penskalaan ini. Proses ini mungkin memakan waktu dan bahkan memerlukan migrasi database.

Untuk Azure, Anda dapat menggunakan ALTER DATABASE, Azure CLI, atau portal Azure untuk meningkatkan kapasitas CPU tanpa migrasi database di bagian pengguna.
Dengan menggunakan portal Microsoft Azure, Anda dapat melihat opsi bagaimana Anda dapat mengukur lebih banyak sumber daya CPU. Dari panel Gambaran Umum database Anda, pilih tingkat Harga untuk penyebaran saat ini. Tingkat Harga memungkinkan Anda untuk mengubah tingkat layanan dan jumlah vCores.
Di sini Anda dapat melihat opsi untuk mengubah atau menskalakan sumber daya komputasi. Untuk Tujuan Umum,Anda dapat dengan mudah meningkatkan hingga sesuatu seperti 8 vCores.

Anda juga dapat menggunakan metode berbeda untuk menskalakan beban kerja Anda.
Untuk latihan ini, sehingga Anda bisa melihat perbedaan yang tepat dalam laporan, Anda harus terlebih dahulu menghapus Penyimpanan Kueri. Di SQL Server Management Studio (SSMS), pilih database AdventureWorks dan gunakan menu File Buka>File.> Buka skrip flushhquerystore.sql di SQL Server Management Studio dalam konteks database AdventureWorks. Jendela editor kueri Anda akan terlihat seperti teks berikut:
```
EXEC sp_query_store_flush_db;
```
Pilih Jalankan untuk menjalankan batch T-SQL ini.

Catatan

Menjalankan kueri sebelumnya akan menghapus bagian dalam memori dari data Penyimpanan Kueri ke disk.
Buka skrip get_service_objective.sql di SSMS. Jendela editor kueri Anda akan terlihat seperti teks berikut:
```
SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
FROM sys.dm_user_db_resource_governance;
GO
SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
GO
```
Ini adalah metode untuk mengetahui tingkat layanan Anda dengan menggunakan T-SQL. Harga atau tingkat layanan juga dikenal sebagai tujuan layanan. Pilih Jalankan untuk menjalankan batch T-SQL.

Untuk penyebaran Azure SQL Database saat ini, hasil Anda akan terlihat seperti gambar berikut ini:

Perhatikan istilah slo_name digunakan untuk tujuan layanan. slo adalah singkatan dari tujuan tingkat layanan.

Berbagai slo_name nilai tidak didokumenkan, tetapi Anda dapat melihat dari nilai string bahwa database ini menggunakan tingkat layanan tujuan umum dengan dua vCore:

Catatan

SQLDB_OP_... adalah string yang digunakan untuk Business Critical.

Saat Anda melihat dokumentasi ALTER DATABASE, perhatikan kemampuan untuk memilih penyebaran SQL Server target Anda untuk mendapatkan opsi sintaks yang tepat. Pilih Database SQL database tunggal/kumpulan elastis untuk melihat opsi untuk Azure SQL Database. Untuk mencocokkan skala komputasi yang Anda temukan di portal, Anda memerlukan tujuan layanan 'GP_Gen5_8'.
Ubah tujuan layanan bagi database untuk menskalakan lebih banyak CPU. Buka skrip modify_service_objective.sql di SSMS dan jalankan batch T-SQL. Jendela editor kueri Anda akan terlihat seperti teks berikut:
```
ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
```
Pernyataan ini segera kembali, tetapi penskalaan sumber daya komputasi terjadi di latar belakang. Skala kecil ini harus memakan waktu kurang dari satu menit, dan untuk waktu yang singkat database offline untuk membuat perubahan efektif. Anda dapat memantau perkembangan aktivitas penskalaan ini dengan menggunakan portal Microsoft Azure.

Di Object Explorer, di bawah folder Database Sistem, klik kanan database master dan pilih Kueri Baru. Jalankan kueri ini di jendela editor kueri SQL Server Management Studio:

SELECT * FROM sys.dm_operation_status;

Ini adalah cara lain untuk memantau kemajuan perubahan untuk tujuan layanan untuk Azure SQL Database. Tampilan manajemen dinamis (DMV) ini memaparkan riwayat perubahan pada database dengan ALTER DATABASE ke tujuan layanan. Ini menunjukkan kemajuan aktif perubahan.

Berikut ini contoh output DMV ini dalam format tabel, setelah Anda menjalankan pernyataan ALTER DATABASE sebelumnya:

Item	Value
Aktivitas Sesi	97F9474C-0334-4FC5-BFD5-337CDD1F9A21
resource_type	0
resource_type_desc	Database
major_resource_id	AdventureWorks
minor_resource_id
operasi	MENGUBAH DATABASE
state	1
state_desc	SEDANG_BERLANGSUNG
persen_selesai	0
kode_kesalahan	0
desk_error
keparahan_error	0
status_kesalahan	0
waktu_mulai	[tanggal waktu]
waktu_modifikasi_terakhir	[tanggal waktu]

Selama perubahan untuk tujuan layanan, kueri diizinkan terhadap database hingga perubahan akhir diterapkan. Aplikasi tidak dapat terhubung untuk jangka waktu yang sangat singkat. Untuk Azure SQL Managed Instance, perubahan tingkatan memungkinkan kueri dan koneksi, tetapi mencegah semua operasi database, seperti pembuatan database baru. Dalam kasus ini, Anda menerima pesan galat berikut: "Operasi tidak dapat diselesaikan karena perubahan tingkat layanan sedang berlangsung untuk instans terkelola '[server]'. Silakan tunggu hingga operasi yang sedang berlangsung selesai, lalu coba kembali."

Setelah ini selesai, gunakan kueri sebelumnya yang tercantum dari get_service_objective.sql di SSMS untuk memverifikasi bahwa tujuan layanan baru atau tingkat layanan 8 vCore telah berlaku.

Jalankan beban kerja setelah peningkatan

Sekarang database memiliki kapasitas CPU lebih banyak, mari kita jalankan beban kerja yang kami lakukan dalam latihan sebelumnya untuk mengamati apakah ada peningkatan kinerja.

Sekarang setelah penskalaan selesai, periksa apakah durasi beban kerja lebih cepat dan apakah menunggu sumber daya CPU telah menurun. Jalankan beban kerja lagi dengan menggunakan perintah sqlworkload.cmd yang Anda jalankan di latihan sebelumnya.
Menggunakan SQL Server Management Studio, jalankan kueri yang sama dari latihan pertama modul ini untuk mengamati hasil dari skrip dmdbresourcestats.sql:
```
SELECT * FROM sys.dm_db_resource_stats;
```
Anda akan melihat bahwa rata-rata penggunaan sumber daya CPU telah menurun dari penggunaan hampir 100 persen pada latihan sebelumnya. Biasanya, sys.dm_db_resource_stats menampilkan satu jam aktivitas. Mengubah ukuran database menyebabkan sys.dm_db_resource_stats reset.
Menggunakan SQL Server Management Studio, jalankan kueri yang sama dari latihan pertama modul ini untuk mengamati hasil dari skrip dmexecrequests.sql.
```
SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
FROM sys.dm_exec_requests er
INNER JOIN sys.dm_exec_sessions es
ON er.session_id = es.session_id
AND es.is_user_process = 1;
```
Anda akan melihat bahwa ada lebih banyak kueri dengan status BERJALAN. Ini berarti pekerja kami memiliki lebih banyak kapasitas CPU untuk dieksekusi.
Amati durasi beban kerja baru. Durasi beban kerja dari sqlworkload.cmd sekarang harus jauh lebih sedikit, dan harus sekitar 25-30 detik.

Mengamati laporan Penyimpanan Kueri

Mari kita lihat laporan Query Store yang sama seperti yang kita lakukan di latihan sebelumnya.

Menggunakan teknik yang sama seperti latihan pertama dalam modul ini, lihat laporan Kueri Penggunaan Sumber Daya Teratas dari SQL Server Management Studio:

Anda sekarang akan melihat dua kueri (query_id). Ini adalah kueri yang sama, tetapi muncul query_id sebagai nilai yang berbeda di Penyimpanan Kueri, karena operasi skala memerlukan restart dan kueri harus diolah ulang. Anda dapat melihat dalam laporan, durasi keseluruhan dan rata-rata secara signifikan lebih sedikit.
Lihat juga laporan Statistik Tunggu Kueri dan pilih bilah tunggu CPU. Anda dapat melihat waktu tunggu rata-rata keseluruhan untuk kueri kurang, dan itu adalah persentase yang lebih rendah dari keseluruhan durasi. Ini adalah indikasi yang baik bahwa CPU tidak sebanyak hambatan sumber daya ketika database memiliki jumlah vCores yang lebih rendah:
Anda dapat menutup semua laporan dan jendela editor kueri. Biarkan SSMS tersambung, karena Anda akan membutuhkannya di latihan berikutnya.

Mengamati perubahan dari Azure Metrics

Buka database AdventureWorks di portal Azure, dan lihat tab Pemantauan di panel Gambaran Umum lagi untuk Pemanfaatan Komputasi:

Perhatikan bahwa durasi lebih singkat untuk pemanfaatan CPU tinggi, yang berarti penurunan keseluruhan sumber daya CPU yang diperlukan untuk menjalankan beban kerja.
Bagan ini bisa agak menyesatkan. Dari menu Pemantauan , gunakan Metrik, lalu atur Metrik ke batas CPU. Bagan perbandingan CPU terlihat lebih seperti berikut ini:

Tip

Jika Anda terus meningkatkan vCores untuk database ini, Anda dapat meningkatkan kinerja hingga ambang batas di mana semua kueri memiliki banyak sumber daya CPU. Ini tidak berarti Anda harus mencocokkan jumlah vCores dengan jumlah pengguna bersamaan dari beban kerja Anda. Selain itu, Anda dapat mengubah Tingkat Harga untuk menggunakan Tingkat Komputasi Tanpa Server, alih-alih Disediakan. Ini membantu Anda mencapai pendekatan yang lebih berskala otomatis untuk beban kerja. Misalnya, jika Anda memilih nilai vCore minimum 2 untuk beban kerja ini dan nilai vCore maksimum 8, beban kerja ini akan segera diskalakan ke 8 vCore.

Pada latihan berikutnya, Anda akan mengamati masalah performa dan menyelesaikannya dengan menerapkan praktik terbaik untuk performa aplikasi.

Lanjutkan

Latihan - Skalakan kinerja beban kerja Anda

Meningkatkan kinerja Azure SQL

Jalankan beban kerja setelah peningkatan

Mengamati laporan Penyimpanan Kueri

Mengamati perubahan dari Azure Metrics

Saran dan Komentar