Bagaimana saya bisa tahu jika kinerja SQL Server DB saya terbatas pada perangkat keras?


8

Menguji aplikasi saat ini di bawah beban pengguna tunggal - karena data pengujian telah meningkat ke ukuran produksi (400k-2M baris per tabel), beberapa SELECT sp tidak lagi cukup cepat (dengan data uji terbatas, masing-masing <30 ms, sekarang 100-200ms, tetapi ada beberapa, jadi penundaan menjadi jelas di UI).


Hampir dijamin menjadi kode dan desain, bukan perangkat keras ...
gbn

Jika pertanyaan Anda dapat memanfaatkan Fungsi Analitik, sql server 2000 jelas terbatas pada perangkat lunak.
bernd_k

Yah, itu tidak sepenuhnya perangkat keras setidaknya - saya menempatkan contoh 2008 Express berdampingan pada mesin uji. 2000 kali masih dalam kisaran yang sama, 2008 kali semuanya <20 ms. Pelayan sepertinya tidak menjelaskan perbedaannya. Setelah menghapus statistik dan pada tes aplikasi yang identik, 2000 memiliki PAGEIOLATCH_SH menunggu waktu 2,48s, rata-rata menunggu 4ms. 2008 memiliki 2.14, rata-rata menunggu 2 ms. Mana yang lebih baik, tetapi tidak menjelaskan peningkatan 10 kali lipat dalam waktu respons aktual - apakah hanya dalam peningkatan mesin generik dari 2000 hingga 2008 yang tidak tercermin dalam statistik?
Pastymage

Jawaban:


8

Anda bisa menggunakannya DBCC SQLPERF("waitstats"). Ini akan mengembalikan waktu tunggu dari tugas apa yang ditunggu oleh server SQL Anda. Penjelasan terperinci dari setiap konter dapat ditemukan online. Anda dapat menggunakan informasi ini untuk mencari tahu kemacetan Anda.

Juga, nyalakan statistik klien di penganalisa permintaan untuk melihat waktu tunggu di sisi klien.

Saya mengasumsikan Anda perangkat keras tidak berubah sejak pengujian awal Anda, jadi karena mereka konstan, saya tidak akan meragukannya.


Saya mengambil beberapa pertanyaan untuk memesan dan memfilter info yang relevan dari waitstats, dan itu tidak memberi tahu saya banyak (lihat komentar saya pada item asli).
Pastymage

@Astymage juga mencoba menjalankan sp_updatestats di SQL 2000 DB Anda. Mereka mencoba kueri lagi dan melihat apakah ada peningkatan kinerja.
StanleyJohns

Tidak, persis sama. Ditto untuk penggunaan pembaruan DBCC.
Pastymage

2

Pikiran:

  • perangkat keras hampir tidak pernah menjadi masalah: desain dan kode yang buruk
  • selalu menguji dengan kualitas dan kuantitas data yang hampir berproduksi

Beberapa solusi:

Jalankan indeks DMV yang hilang untuk melihat, well, indeks yang hilang:

SELECT 
  migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure, 
  'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle) 
  + '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']'
  + ' ON ' + mid.statement 
  + ' (' + ISNULL (mid.equality_columns,'') 
    + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END 
    + ISNULL (mid.inequality_columns, '')
  + ')' 
  + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
  migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) > 10
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

... dan pertanyaan DMV paling mahal

SELECT TOP 20
    qs.sql_handle,
    qs.execution_count,
    qs.total_worker_time AS Total_CPU,
    total_CPU_inSeconds = --Converted from microseconds
    qs.total_worker_time/1000000,
    average_CPU_inSeconds = --Converted from microseconds
    (qs.total_worker_time/1000000) / qs.execution_count,
    qs.total_elapsed_time,
    total_elapsed_time_inSeconds = --Converted from microseconds
    qs.total_elapsed_time/1000000,
    st.text,
    qp.query_plan
FROM
    sys.dm_exec_query_stats AS qs
        CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
        CROSS apply sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY qs.total_worker_time DESC

Jika tidak, pertanyaan SO ini memiliki tip bagus dari saya dan jenis rep tinggi SQL lainnya: https://stackoverflow.com/q/4118156/27535 (Saya tidak akan menyalin / menempelkan semua 3 jawaban agak panjang)


DMV itu bagus untuk tahun 2005+ tetapi tidak berfungsi pada tahun 2000.
SqlSandwiches

@SqlSandwiches: oops, melewatkan itu.
gbn

Mencoba ini pada contoh Express 2008 yang saya atur - dm_exec_query_stats sepertinya tidak ada?
Pastymage

1

Catat sumber daya sistem atau lihat pengelola tugas untuk melihat berapa banyak sumber daya sistem yang digunakan oleh proses.


1

Hal yang menarik yang harus dipertimbangkan adalah versi MSSQL 2000 yang berjalan

Ada empat versi binari

  1. Mengekspresikan
  2. Standar
  3. Profesional
  4. Perusahaan

Masing-masing versi memiliki batasan dalam hal RAM dan CPU.

Perlu ditelusuri kemungkinan bahwa jumlah data yang disimpan saat ini hanya melampaui kemampuan versi MSSQL 2000 karena permintaan yang membutuhkan lebih banyak RAM untuk memenuhi kueri / subkueri atau pemanfaatan CPU yang tidak memadai. Anda mungkin perlu memutakhirkan versi biner ke versi MSSQL 2000 Entrprise (mungkin jauh karena seberapa lama versi MSSQL Anda) atau versi terbaik yang mampu dibeli dengan anggaran Anda.

Anda bahkan mungkin ingin keluar dari MSSQL 2000 karena 2008 adalah yang terbaru dan memiliki dukungan saat ini tersedia. Sekali lagi, ini bisa menjadi masalah anggaran. Jika Anda sudah menggunakan Enterprise, atau anggaran Anda tidak memungkinkan untuk peningkatan besar apa pun, sekarang Anda dapat menjelajahi DB Statistics atau Desain DB.

Penafian: Saya bukan SQL Server DBA


Memutakhirkan ke 2008 tampaknya merupakan perbaikan cepat, karena bahkan 2008 Express dengan CPU 1 GB, batas RAM 1 GB telah sepenuhnya menyelesaikan masalah. Tetap saja, saya ingin mengerti mengapa / bagaimana ...
Pastymage
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.