Manajemen sumber daya di kumpulan elastis yang padat

  • Artikel

Berlaku untuk:Azure SQL Database

Kumpulan elastis Azure SQL Database adalah solusi hemat biaya untuk mengelola banyak database dengan berbagai penggunaan sumber daya. Semua database dalam kumpulan elastis memiliki alokasi sumber daya yang sama, seperti CPU, memori, rangkaian pekerja, ruang penyimpanan,tempdb, dengan asumsi bahwa hanya sebagian database di kumpulan yang akan menggunakan sumber daya komputasi pada waktu tertentu. Asumsi ini memungkinkan kumpulan elastis hemat biaya. Daripada membayar semua sumber daya yang mungkin dibutuhkan setiap database individu, pelanggan membayar set sumber daya yang jauh lebih kecil, dibagikan di antara semua database di kumpulan.

Tata kelola sumber daya

Berbagi sumber daya mengharuskan sistem untuk mengontrol penggunaan sumber daya dengan hati-hati untuk meminimalkan efek "tetangga yang berisik", di mana database dengan penggunaan sumber daya tinggi mempengaruhi database lain dalam kumpulan elastis yang sama. Azure SQL Database mencapai tujuan ini dengan menerapkan tata kelola sumber daya. Pada saat yang sama, sistem harus menyediakan sumber daya yang memadai untuk fitur-fitur seperti ketersediaan tinggi dan pemulihan bencana (HADR), pencadangan dan pemulihan, pemantauan, Penyimpanan Kueri, Penyetelan otomatis, dll. agar berfungsi dengan andal.

Tujuan desain utama kumpulan elastis adalah agar hemat biaya. Karena alasan itulah, sistem sengaja memungkinkan pelanggan untuk membuat kumpulan padat, yaitu kumpulan dengan jumlah database mendekati atau maksimum yang diizinkan, tetapi dengan alokasi sumber daya komputasi yang moderat. Untuk alasan yang sama, sistem tidak memesan semua sumber daya yang mungkin diperlukan untuk proses internalnya, tetapi mengizinkan berbagi sumber daya antara proses internal dan beban kerja pengguna.

Pendekatan ini memungkinkan pelanggan untuk menggunakan kumpulan elastis yang padat untuk mencapai performa yang memadai dan penghematan biaya utama. Namun, jika beban kerja terhadap banyak database dalam kumpulan padat cukup intens, ketidakcocokan sumber daya menjadi signifikan. Ketidakcocokan sumber daya mengurangi performa beban kerja pengguna, dan dapat berdampak negatif pada proses internal.

Penting

Dalam kumpulan padat dengan banyak database aktif, mungkin tidak mungkin untuk meningkatkan jumlah database dalam kumpulan hingga maksimum yang didokumentasikan untuk kumpulan elastis DTU dan vCore.

Jumlah database yang dapat ditempatkan di kumpulan padat tanpa menyebabkan ketidakcocokan sumber daya dan masalah performa tergantung jumlah database yang aktif bersamaan, dan pada penggunaan sumber daya oleh beban kerja pengguna di setiap database. Jumlah ini dapat berubah seiring waktu saat beban kerja pengguna berubah.

Selain itu, jika min vCore per database, atau min DTU per pengaturan database diatur ke nilai yang lebih besar dari 0, jumlah maksimum database dalam kolam akan secara implisit terbatas. Untuk informasi selengkapnya, lihat Properti database untuk kumpulan database vCore dan Properti database untuk kumpulan database DTU.

Ketika ketidakcocokan sumber daya terjadi di kumpulan yang padat, pelanggan dapat memilih satu atau beberapa tindakan berikut untuk menguranginya:

  • Menyetel beban kerja kueri untuk mengurangi penggunaan sumber daya, atau menyebarkan penggunaan sumber daya di beberapa database dari waktu ke waktu.
  • Kurangi kepadatan kumpulan dengan memindahkan beberapa database ke kumpulan lain, atau dengan menjadikannya database mandiri.
  • Tingkatkan skala kumpulan untuk mendapatkan lebih banyak sumber daya.

Untuk saran mengenai cara menerapkan dua tindakan terakhir, lihat Rekomendasi operasional di artikel ini nanti. Mengurangi manfaat ketidakcocokan sumber daya baik beban kerja pengguna maupun proses internal, dan memungkinkan sistem mempertahankan tingkat layanan yang diharapkan dengan andal.

Memantau penggunaan sumber daya

Untuk menghindari penurunan kinerja karena ketidakcocokan sumber daya, pelanggan yang menggunakan kumpulan elastis yang padat harus secara proaktif memantau penggunaan sumber daya, dan mengambil tindakan tepat waktu jika peningkatan ketidakcocokan sumber daya mulai memengaruhi beban kerja. Pemantauan berkelanjutan penting karena penggunaan sumber daya dalam kumpulan berubah dari waktu ke waktu, karena perubahan beban kerja pengguna, perubahan volume dan distribusi data, perubahan kepadatan kumpulan, dan perubahan dalam layanan Azure SQL Database.

Azure SQL Database menyediakan beberapa metrik yang relevan untuk jenis pemantauan ini. Melebihi nilai rata-rata yang direkomendasikan untuk setiap metrik menunjukkan ketidakcocokan sumber daya di kumpulan, dan harus ditangani menggunakan salah satu tindakan yang disebutkan sebelumnya.

Untuk mengirim peringatan saat pemanfaatan sumber daya kumpulan (CPU, IO data, IO log, pekerja, dll.) melebihi ambang, pertimbangkan untuk membuat peringatan melalui portal Microsoft Azure atau cmdlet PowerShell Add-AzMetricAlertRulev2. Ketika memantau kumpulan elastis, pertimbangkan juga untuk membuat peringatan untuk database individual di kumpulan jika diperlukan dalam skenario Anda. Untuk skenario sampel kumpulan elastis pemantauan, lihat Memantau dan mengelola performa Azure SQL Database di aplikasi SaaS multi-penyewa.

Nama metrik Deskripsi Nilai rata-rata yang direkomendasikan
avg_instance_cpu_percent Pemanfaatan CPU dari proses SQL yang terkait dengan kumpulan elastis, sebagaimana diukur oleh sistem operasi yang mendasarinya. Tersedia di tampilan sys.dm_db_resource_stats di setiap database, dan di tampilan sys.elastic_pool_resource_stats dalam database master. Metrik ini juga dikeluarkan ke Azure Monitor, tempat metrik diberi namasql_instance_cpu_percent, dan dapat dilihat di portal Microsoft Azure. Nilai ini sama untuk setiap database dalam kumpulan elastis yang sama. Di bawah 70%. Lonjakan pendek sesekali hingga 90% dapat diterima.
max_worker_percent Pemanfaatan utas pekerja. Disediakan untuk setiap database di kumpulan elastis, serta untuk kumpulan itu sendiri. Ada batasan yang berbeda pada jumlah utas pekerja di tingkat database, dan pada tingkat kumpulan, jadi sebaiknya Anda memantau metrik ini di kedua tingkat. Tersedia di tampilan sys.dm_db_resource_stats di setiap database, dan di tampilan sys.elastic_pool_resource_stats dalam database master. Metrik ini juga dikeluarkan ke Azure Monitor, tempat metrik diberi namaworkers_percent, dan dapat dilihat di portal Microsoft Azure. Di bawah 80%. Lonjakan hingga 100% akan menyebabkan upaya koneksi dan kueri gagal.
avg_data_io_percent Pemanfaatan IOPS untuk membaca dan menulis IO fisik. Disediakan untuk setiap database di kumpulan elastis, serta untuk kumpulan itu sendiri. Ada batasan yang berbeda pada jumlah IOPS di tingkat database, dan pada tingkat kumpulan, jadi sebaiknya Anda memantau metrik ini di kedua tingkat. Tersedia di tampilan sys.dm_db_resource_stats di setiap database, dan di tampilan sys.elastic_pool_resource_stats dalam database master. Metrik ini juga dikeluarkan ke Azure Monitor, tempat metrik diberi namaphysical_data_read_percent, dan dapat dilihat di portal Microsoft Azure. Di bawah 80%. Lonjakan pendek sesekali hingga 100% dapat diterima.
avg_log_write_percent Pemanfaatan throughput untuk log transaksi tulis IO. Disediakan untuk setiap database di kumpulan elastis, serta untuk kumpulan itu sendiri. Ada batasan yang berbeda pada throughput log di tingkat database, dan pada tingkat kumpulan, jadi sebaiknya Anda memantau metrik ini di kedua tingkat. Tersedia di tampilan sys.dm_db_resource_stats di setiap database, dan di tampilan sys.elastic_pool_resource_stats dalam database master. Metrik ini juga dikeluarkan ke Azure Monitor, tempat metrik diberi namalog_write_percent, dan dapat dilihat di portal Microsoft Azure. Saat metrik ini mendekati 100%, semua modifikasi database (pernyataan INSERT, UPDATE, DELETE, MERGE, SELECT … INTO, BULK INSERT, dll.) akan menjadi lebih lambat. Di bawah 90%. Lonjakan pendek sesekali hingga 100% dapat diterima.
oom_per_second Laju kesalahan di luar memori (OOM) dalam kumpulan elastis, yang merupakan indikator tekanan memori. Tersedia di tampilan sys.dm_resource_governor_resource_pools_history_ex. Lihat Contoh sampel kueri untuk menghitung metrik ini. Untuk informasi selengkapnya, lihat batas sumber daya untuk kumpulan elastis menggunakan DTU atau kumpulan elastis menggunakan vCores, dan Memecahkan masalah kesalahan memori dengan Azure SQL Database. Jika Anda menemukan kesalahan memori habis, tinjau sys.dm_os_out_of_memory_events. 0
avg_storage_percent Total ruang penyimpanan yang digunakan oleh data di semua database dalam kumpulan elastis. Tidak menyertakan ruang kosong dalam file database. Tersedia di tampilan sys.elastic_pool_resource_stats dalam database master. Metrik ini juga dikeluarkan ke Azure Monitor, tempat metrik diberi namastorage_percent, dan dapat dilihat di portal Microsoft Azure. Di bawah 80%. Dapat mendekati 100% untuk kumpulan tanpa pertumbuhan data.
avg_allocated_storage_percent Total ruang penyimpanan yang digunakan oleh file database dalam penyimpanan di semua database dalam kumpulan elastis. Menyertakan ruang kosong dalam file database. Tersedia di tampilan sys.elastic_pool_resource_stats dalam database master. Metrik ini juga dikeluarkan ke Azure Monitor, tempat metrik diberi namaallocated_data_storage_percent, dan dapat dilihat di portal Microsoft Azure. Di bawah 90%. Dapat mendekati 100% untuk kumpulan tanpa pertumbuhan data.
tempdb_log_used_percent Pemanfaatan ruang log transaksi dalam database tempdb. Meskipun objek sementara yang dibuat dalam satu database tidak terlihat di database lain di kumpulan elastis yang sama, tempdb adalah sumber daya bersama untuk semua database dalam kumpulan yang sama. Transaksi yang berjalan lama atau tanpa sumber di tempdb dimulai dari satu database di kumpulan dapat menggunakan sebagian besar log transaksi, dan menyebabkan kegagalan kueri di database lain di kumpulan yang sama. Berasal dari tampilan sys.dm_db_log_space_usage dan sys.database_files. Metrik ini juga dikeluarkan ke Azure Monitor, dan dapat dilihat di portal Microsoft Azure. Lihat Contoh sampel kueri untuk mengembalikan nilai saat ini dari metrik ini. Di bawah 50%. Lonjakan sesekali hingga 80% dapat diterima.

Selain metrik ini, Azure SQL Database menyediakan tampilan yang mengembalikan batas tata kelola sumber daya aktual, serta tampilan tambahan yang mengembalikan statistik pemanfaatan sumber daya di tingkat pusat sumber daya, dan di tingkat grup beban kerja.

Melihat nama Deskripsi
sys.dm_user_db_resource_governance Mengembalikan pengaturan konfigurasi dan kapasitas aktual yang digunakan oleh mekanisme tata kelola sumber daya dalam database atau kumpulan elastis saat ini.
sys.dm_resource_governor_resource_pools Mengembalikan informasi tentang status pusat sumber daya saat ini, konfigurasi kumpulan sumber daya saat ini, dan statistik kumpulan sumber daya kumulatif.
sys.dm_resource_governor_workload_groups Mengembalikan statistik grup beban kerja kumulatif dan konfigurasi grup beban kerja saat ini. Tampilan ini dapat digabungkan dengan sys.dm_resource_governor_resource_pools di kolom pool_id untuk mendapatkan informasi pusat sumber daya.
sys.dm_resource_governor_resource_pools_history_ex Mengembalikan statistik penggunaan pusat sumber daya untuk riwayat terbaru, berdasarkan jumlah snapshot yang tersedia. Setiap baris mewakili satu interval waktu. Durasi interval disediakan di kolom duration_ms. Kolom delta_ mengembalikan perubahan dalam setiap statistik selama interval.
sys.dm_resource_governor_resource_pools_history_ex Mengembalikan statistik penggunaan grup beban kerja untuk riwayat terbaru, berdasarkan jumlah snapshot yang tersedia. Setiap baris mewakili satu interval waktu. Durasi interval disediakan di kolom duration_ms. Kolom delta_ mengembalikan perubahan dalam setiap statistik selama interval.

Tip

Untuk mengkueri properti ini dan tampilan manajemen dinamis lainnya menggunakan prinsipal selain administrator server, tambahkan prinsipal ini ke ##MS_ServerStateReader##peran server.

Tampilan ini dapat digunakan untuk memantau pemanfaatan sumber daya dan memecahkan masalah ketidakcocokan sumber daya dalam waktu dekat secara real-time. Beban kerja pengguna pada replika sekunder utama dan dapat dibaca, termasuk geo-replika, diklasifikasikan ke dalam pusat sumber SloSharedPool1 daya dan grup beban kerja UserPrimaryGroup.DBId[N], di mana N merupakan singkatan dari nilai ID database.

Selain memantau pemanfaatan sumber daya saat ini, pelanggan yang menggunakan kumpulan padat dapat mempertahankan data pemanfaatan sumber daya historis di penyimpanan data terpisah. Data ini dapat digunakan dalam analisis prediktif untuk mengelola pemanfaatan sumber daya secara proaktif berdasarkan tren historis dan musiman.

Rekomendasi operasional

Biarkan ruang kepala sumber daya yang cukup. Jika terjadi ketidaksesuaian sumber daya dan penurunan performa, mitigasinya mungkin melibatkan pemindahan beberapa database dari kumpulan elastis yang terkena dampak, atau meningkatkan skala kumpulan, seperti yang disebutkan sebelumnya. Namun, tindakan ini memerlukan sumber daya komputasi tambahan untuk diselesaikan. Khususnya, untuk kumpulan Premium dan Bisnis Kritis, tindakan ini memerlukan transfer semua data untuk database yang dipindahkan, atau untuk semua database di kumpulan elastis jika kumpulan ditingkatkan skalanya. Transfer data adalah operasi yang berjalan lama dan padat sumber daya. Jika kolam sudah berada di bawah tekanan sumber daya tinggi, operasi mitigasi itu sendiri akan menurunkan performa lebih jauh. Dalam kasus yang ekstrem, mungkin tidak mungkin untuk menyelesaikan ketidakcocokan sumber daya melalui pemindahan database atau peningkatan kumpulan karena sumber daya yang diperlukan tidak tersedia. Dalam hal ini, mengurangi beban kerja kueri untuk sementara pada kumpulan elastis yang terpengaruh mungkin menjadi satu-satunya solusi.

Pelanggan yang menggunakan kumpulan padat harus memonitor tren pemanfaatan sumber daya seperti yang dijelaskan sebelumnya, dan mengambil tindakan mitigasi sementara metrik tetap dalam rentang yang direkomendasikan dan masih ada sumber daya yang cukup di kumpulan elastis.

Pemanfaatan sumber daya tergantung beberapa faktor yang berubah dari waktu ke waktu untuk setiap database dan setiap kumpulan elastis. Mencapai rasio harga/ performa yang optimal di kumpulan padat membutuhkan pemantauan dan penyesuaian yang berkelanjutan, yaitu memindahkan database dari kumpulan yang lebih banyak digunakan ke kumpulan yang kurang dimanfaatkan, dan membuat kumpulan baru yang diperlukan untuk mengakomodasi peningkatan beban kerja.

Catatan

Untuk kumpulan elastis DTU, metrik eDTU di tingkat kumpulan bukan merupakan MAX atau SUM dari penggunaan database individual. Hal ini didapatkan dari penggunaan berbagai metrik tingkat kumpulan. Batas sumber daya tingkat kumpulan mungkin lebih tinggi daripada batas tingkat database individu, sehingga ada kemungkinan bahwa database individu dapat mencapai batas sumber daya tertentu (CPU, data IO, log IO, dsb.), bahkan saat pelaporan eDTU untuk kumpulan mengindikasikan bahwa tidak ada batas yang tercapai.

Jangan pindahkan database "panas". Jika ketidakcocokan sumber daya di tingkat kumpulan terutama disebabkan oleh sejumlah kecil database yang sering digunakan, sebaiknya Anda memindahkan database ini ke kumpulan yang kurang digunakan, atau menjadikannya database mandiri. Namun, melakukan ini saat database masih sering digunakan tidak dianjurkan, karena operasi pemindahan akan semakin menurunkan performa, baik untuk database yang dipindahkan, dan untuk seluruh kumpulan. Sebagai gantinya, tunggu sampai pemanfaatan tinggi mereda, atau pindahkan database yang kurang digunakan untuk meringankan tekanan sumber daya di tingkat kumpulan. Namun memindahkan database dengan pemanfaatan yang sangat rendah tidak memberikan manfaat apa pun dalam kasus ini, karena tidak mengurangi pemanfaatan sumber daya di tingkat kumpulan secara material.

Buat database baru di kumpulan "karantina". Dalam skenario di mana database baru sering dibuat, seperti aplikasi yang menggunakan model penyewa per database, ada risiko database baru yang ditempatkan ke dalam kumpulan elastis yang ada secara tiba-tiba akan menggunakan sumber daya yang signifikan dan memengaruhi database lain dan proses internal di kumpulan. Untuk mengurangi risiko ini, buat kumpulan "karantina" terpisah dengan alokasi sumber daya yang cukup besar. Gunakan kumpulan ini untuk database baru dengan pola penggunaan sumber daya yang belum diketahui. Setelah database dibiarkan di kumpulan ini untuk siklus bisnis, seperti seminggu atau sebulan, dan penggunaan sumber dayanya diketahui, database dapat dipindahkan ke kumpulan dengan kapasitas yang cukup untuk mengakomodasi penggunaan sumber daya tambahan ini.

Memantau ruang yang digunakan dan dialokasikan. Ketika dialokasikan ruang kumpulan (ukuran total semua file database dalam penyimpanan untuk semua database dalam kumpulan) mencapai ukuran kumpulan maksimum, kesalahan di luar ruang dapat terjadi. Jika tren ruang yang dialokasikan tinggi dan berada di jalur untuk mencapai ukuran kumpulan maksimum, opsi mitigasi meliputi:

  • Memindahkan beberapa database keluar dari kumpulan untuk mengurangi total ruang yang dialokasikan
  • Menciutkan file database untuk mengurangi ruang kosong yang dialokasikan dalam file
  • Meningkatkan skala kumpulan ke tujuan layanan dengan ukuran kumpulan maksimum yang lebih besar

Jika digunakan ruang kumpulan (ukuran total data di semua database dalam kumpulan, tidak termasuk ruang kosong dalam file) tren tinggi dan berada di jalur untuk mencapai ukuran kumpulan maksimum, opsi mitigasi meliputi:

  • Memindahkan beberapa database keluar dari kumpulan untuk mengurangi total ruang yang digunakan
  • Memindahkan (mengarsipkan) data di luar database, atau menghapus data yang tidak lagi diperlukan
  • Menerapkan kompresi data
  • Meningkatkan skala kumpulan ke tujuan layanan dengan ukuran kumpulan maksimum yang lebih besar

Menghindari server yang terlalu padat. Azure SQL Database mendukung hingga 5000 database per server. Pelanggan yang menggunakan kumpulan elastis dengan ribuan database dapat mempertimbangkan untuk menempatkan beberapa kumpulan elastis pada satu server, dengan jumlah total database hingga batas yang didukung. Namun, server dengan ribuan database menciptakan tantangan operasional. Operasi yang mengharuskan menghitung semua database di server, misalnya melihat database di portal, akan lebih lambat. Kesalahan operasional, seperti perubahan login tingkat server atau aturan firewall yang salah, akan memengaruhi sejumlah besar database. Penghapusan server yang tidak disengaja akan memerlukan bantuan dari Dukungan Microsoft untuk memulihkan database di server yang dihapus, dan akan menyebabkan pemadaman berkepanjangan untuk semua database yang terpengaruh.

Batasi jumlah database per server ke angka yang lebih rendah dari jumlah maksimum yang didukung. Dalam banyak skenario, menggunakan hingga 1000-2000 database per server optimal. Untuk mengurangi kemungkinan penghapusan server yang tidak disengaja, letakkan kunci penghapusan pada server atau grup sumber dayanya.

Contoh

Menampilkan pengaturan kapasitas database individu

Gunakan tampilan manajemen dinamis sys.dm_user_db_resource_governance untuk melihat pengaturan konfigurasi dan kapasitas aktual yang digunakan oleh tata kelola sumber daya dalam database atau kumpulan elastis saat ini. Untuk informasi selengkapnya, lihat sys.dm_user_db_resource_governance.

Jalankan kueri ini dalam database apa pun dalam kumpulan elastis. Semua database di kumpulan memiliki pengaturan tata kelola sumber daya yang sama.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Memantau konsumsi sumber daya kumpulan elastis secara keseluruhan

Gunakan tampilan katalog sistem sys.elastic_pool_resource_stats untuk memantau konsumsi sumber daya seluruh kumpulan. Untuk informasi selengkapnya, lihat sys.elastic_pool_resource_stats.

Sampel kueri ini harus dijalankan dalam database master server Azure SQL logis yang berisi kumpulan elastis yang diinginkan untuk menampilkan 10 menit terakhir.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Memantau konsumsi sumber daya database individu

Gunakan tampilan manajemen dinamis sys.dm_db_resource_stats untuk memantau konsumsi sumber daya database individu. Untuk informasi selengkapnya, lihat sys.dm_db_resource_stats. Terdapat satu baris untuk setiap 15 detik, bahkan jika tidak ada aktivitas di database. Data riwayat dipelihara selama kurang lebih satu jam.

Sampel kueri ini harus dijalankan dalam database yang diinginkan untuk menampilkan data selama 10 menit terakhir.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Untuk waktu retensi yang lebih lama dengan frekuensi yang lebih sedikit, pertimbangkan kueri berikut pada sys.resource_stats, jalankan di database master server logis Azure SQL. Untuk informasi selengkapnya, lihat sys.resource_stats (Azure SQL Database). Terdapat satu baris untuk setiap lima menit, dan data riwayat dipertahankan selama dua minggu.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Memantau pemanfaatan memori

Kueri ini menghitung metrik oom_per_second untuk setiap pusat sumber daya untuk riwayat terbaru, berdasarkan jumlah snapshot yang tersedia. Kueri sampel ini membantu mengidentifikasi jumlah rata-rata terbaru alokasi memori yang gagal dalam kumpulan. Kueri ini dapat dijalankan dalam database apa pun dalam kumpulan elastis.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Memantau pemanfaatan ruang log tempdb

Kueri ini mengembalikan nilai metrik tempdb_log_used_percent saat ini, memperlihatkan pemanfaatan relatif log transaksi relatif tempdb terhadap ukuran maksimum yang diizinkan. Kueri ini dapat dijalankan dalam database apa pun dalam kumpulan elastis.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Langkah berikutnya