Tindak lanjut dari Summer Performance Palooza 2013

Pada tanggal 27 Juni, PASS Performance Virtual Chapter mengadakan 2013 Summer Performance Palooza – semacam PASS 24 Jam yang diperkecil, tetapi hanya berfokus pada topik yang terkait dengan kinerja. Saya memberikan sesi berjudul, "10 Kebiasaan Buruk yang Dapat Membunuh Kinerja", membahas 10 konsep berikut:

1. PILIH *
2. Indeks buta
3. Tidak ada awalan skema
4. Opsi kursor default
5. awalan sp_
6. Membiarkan cache membengkak
7. Tipe data lebar
8. Default SQL Server
9. Menggunakan fungsi secara berlebihan
10. "Berfungsi di mesin saya"

Anda mungkin ingat beberapa topik ini dari presentasi seperti ceramah "Kebiasaan Buruk dan Praktik Terbaik" saya atau webinar Penyesuaian Kueri mingguan yang saya selenggarakan bersama Kevin Kline dari awal Juni hingga minggu ini. (Omong-omong, 6 video itu akan tersedia pada awal Agustus di YouTube.)

Sesi saya memiliki 351 peserta, dan saya mendapat umpan balik yang bagus. Saya ingin membahas beberapa di antaranya.

Pertama, masalah konfigurasi:Saya menggunakan mikrofon baru, dan tidak tahu bahwa setiap penekanan tombol akan terdengar seperti guntur. Saya telah mengatasi masalah itu dengan penempatan periferal yang lebih baik, tetapi saya ingin meminta maaf kepada semua orang yang terpengaruh olehnya.

Selanjutnya, unduhan; dek dan sampel diposting ke lokasi acara. Mereka ada di bagian bawah halaman, tetapi Anda juga dapat mengunduhnya di sini.

Akhirnya, berikut ini adalah daftar pertanyaan yang diposting selama sesi, dan saya ingin memastikan bahwa saya menjawab pertanyaan apa pun yang tidak terjawab selama tanya jawab langsung. Saya minta maaf karena saya telah memeras ini hanya dalam waktu kurang dari sebulan , tapi ada ada banyak pertanyaan, dan saya tidak ingin memublikasikannya sebagian.

J: Anda harus mendekati ini berdasarkan kasus per kasus, karena ini akan sangat bergantung pada berbagai faktor (termasuk kerumitan rencana). Perhatikan juga bahwa Anda dapat melakukan kompilasi ulang tingkat pernyataan sehingga hanya pernyataan yang terpengaruh yang harus menerima pukulan, bukan keseluruhan modul. Paul White mengingatkan saya bahwa orang sering 'memperbaiki' parameter sniffing dengan RECOMPILE , tetapi terlalu sering itu berarti WITH RECOMPILE gaya 2000 daripada OPTION (RECOMPILE) yang jauh lebih baik , yang tidak hanya membatasi dirinya pada pernyataan, tetapi juga memungkinkan penyematan parameter, yang WITH RECOMPILE tidak. Jadi, jika Anda akan menggunakan RECOMPILE untuk menggagalkan sniffing parameter, tambahkan ke pernyataan, bukan modul.

J: Seperti di atas, ini akan tergantung pada biaya dan kerumitan rencana dan tidak ada cara untuk mengatakan, "Ya, akan selalu ada pencapaian kinerja yang besar." Anda juga harus yakin untuk membandingkannya dengan alternatifnya.

J: Saya tidak yakin apa artinya "dapat dibaca di dunia nyata". Jika Anda ingin output dalam format tertentu, Anda biasanya lebih baik mengonversi ke string di sisi klien. C# dan sebagian besar bahasa lain yang mungkin Anda gunakan di tingkat presentasi lebih dari mampu memformat keluaran tanggal/waktu dari database dalam format regional apa pun yang Anda inginkan.

J: Sebagian besar DMV hanya berlaku sejak layanan terakhir dimulai, dan bahkan yang lain dapat dihapus lebih sering (bahkan sesuai permintaan – baik secara tidak sengaja maupun sengaja). Cache paket, tentu saja, dalam fluks konstan, dan paket AFAIK yang keluar dari cache tidak mempertahankan jumlah sebelumnya jika mereka muncul kembali. Jadi, bahkan ketika Anda melihat paket di cache, saya tidak 100% yakin Anda dapat mempercayai jumlah penggunaan yang Anda temukan.

Karena itu, yang mungkin Anda cari adalah sys.dm_exec_cached_plans.usecounts dan Anda juga dapat menemukan sys.dm_exec_procedure_stats.execution_count untuk membantu melengkapi informasi untuk prosedur di mana pernyataan individu dalam prosedur tidak ditemukan dalam cache.

J: Perhatian utama seputar ini adalah kemampuan untuk menggunakan sintaks tertentu, seperti OUTER APPLY atau variabel dengan fungsi bernilai tabel. Saya tidak mengetahui adanya kasus di mana menggunakan kompatibilitas yang lebih rendah memiliki dampak langsung pada kinerja, tetapi beberapa hal yang biasanya direkomendasikan adalah untuk membangun kembali indeks dan memperbarui statistik (dan untuk membuat vendor Anda mendukung tingkat kompatibilitas yang lebih baru ASAP). Saya telah melihatnya menyelesaikan penurunan kinerja yang tidak terduga dalam sejumlah besar kasus, tetapi saya juga mendengar beberapa pendapat bahwa hal itu tidak perlu dan bahkan mungkin tidak bijaksana.

J: Tidak, setidaknya dalam hal kinerja, satu pengecualian di mana SELECT * tidak masalah adalah ketika digunakan di dalam EXISTS ayat. Tapi mengapa Anda menggunakan * di sini? Saya lebih suka menggunakan EXISTS (SELECT 1 ... – pengoptimal akan memperlakukannya dengan cara yang sama, tetapi pengoptimal mendokumentasikan kode sendiri dan memastikan bahwa pembaca memahami subkueri tidak mengembalikan data apa pun (bahkan jika mereka melewatkan EXISTS besar di luar). Beberapa orang menggunakan NULL , dan saya tidak tahu mengapa saya mulai menggunakan 1, tetapi saya menemukan NULL sedikit tidak intuitif juga.

*Catatan* Anda harus berhati-hati, jika Anda mencoba menggunakan EXISTS (SELECT * di dalam modul yang terikat skema:

CREATE VIEW dbo.ThisWillNotWork
WITH SCHEMABINDING
AS
  SELECT BusinessEntityID
    FROM Person.Person AS p
	WHERE EXISTS (SELECT * FROM Sales.SalesOrderHeader AS h
	  WHERE h.SalesPersonID = p.BusinessEntityID);

Anda mendapatkan kesalahan ini:

Namun mengubahnya menjadi SELECT 1 bekerja dengan baik. Jadi mungkin itu argumen lain untuk menghindari SELECT * bahkan dalam skenario itu.

J: Mungkin ada ratusan dalam berbagai bahasa. Seperti konvensi penamaan, standar pengkodean adalah hal yang sangat subjektif. Tidak masalah konvensi apa yang Anda putuskan paling cocok untuk Anda; jika Anda suka tbl awalan, gila! Lebih suka Pascal daripada bigEndian, lakukanlah. Ingin mengawali nama kolom Anda dengan tipe data, seperti intCustomerID , aku tidak akan menghentikanmu. Yang lebih penting adalah Anda mendefinisikan konvensi dan menggunakannya *secara konsisten.*

Yang mengatakan, jika Anda menginginkan pendapat saya, saya tidak akan kekurangannya.

J: Saya tidak tahu ada rencana untuk menghentikan XACT_ABORT jadi itu harus terus bekerja dengan baik. Terus terang saya tidak melihat ini sering digunakan sekarang karena kami memiliki TRY / CATCH (dan THROW pada SQL Server 2012).

J: Saya tidak menguji ini, tetapi dalam banyak kasus mengganti fungsi skalar dengan fungsi bernilai tabel sebaris dapat berdampak besar pada kinerja. Masalah yang saya temukan adalah bahwa membuat sakelar ini dapat menjadi pekerjaan besar pada sistem yang ditulis sebelum APPLY ada, atau masih dikelola oleh orang-orang yang belum menganut pendekatan yang lebih baik ini.

J: Dua hal yang terlintas dalam pikiran:(1) penundaan berkaitan dengan waktu kompilasi atau (2) penundaan berkaitan dengan jumlah data yang dimuat untuk memenuhi kueri, dan pertama kali harus berasal dari disk dan bukan memori. Untuk (1) Anda dapat menjalankan kueri di SQL Sentry Plan Explorer dan bilah status akan menunjukkan kepada Anda waktu kompilasi untuk pemanggilan pertama dan selanjutnya (meskipun satu menit tampaknya agak berlebihan untuk ini, dan tidak mungkin). Jika Anda tidak menemukan perbedaan apa pun, mungkin itu hanya sifat sistem:memori tidak cukup untuk mendukung jumlah data yang Anda coba muat dengan kueri ini dalam kombinasi dengan data lain yang sudah ada di kumpulan buffer. Jika Anda tidak yakin salah satu dari ini adalah masalahnya, lihat apakah dua eksekusi yang berbeda benar-benar menghasilkan rencana yang berbeda – jika ada perbedaan, poskan rencana tersebut ke answer.sqlperformance.com dan kami akan dengan senang hati memeriksanya . Bahkan menangkap rencana aktual untuk kedua eksekusi menggunakan Plan Explorer dalam kasus apa pun juga dapat memberi tahu Anda tentang perbedaan dalam I/O dan dapat mengarah ke tempat SQL Server menghabiskan waktunya pada proses pertama yang lebih lambat.

J: Tidak, menurut saya pengaturan Optimize for ad hoc beban kerja tidak akan membantu skenario ini, karena sniffing parameter menyiratkan bahwa eksekusi berikutnya dari rencana yang sama digunakan untuk parameter yang berbeda dan dengan perilaku kinerja yang sangat berbeda. Optimalkan untuk beban kerja ad hoc digunakan untuk meminimalkan dampak drastis pada cache paket yang dapat terjadi jika Anda memiliki banyak pernyataan SQL yang berbeda. Jadi, kecuali jika Anda berbicara tentang dampak pada cache paket dari banyak pernyataan berbeda yang Anda kirim ke sp_executesql – yang tidak akan dicirikan sebagai parameter sniffing – saya rasa bereksperimen dengan OPTION (RECOMPILE) mungkin memiliki hasil yang lebih baik atau, jika Anda mengetahui nilai parameter yang *melakukan* menghasilkan hasil yang baik di berbagai kombinasi parameter, gunakan OPTIMIZE FOR . Jawaban dari Paul White ini dapat memberikan wawasan yang jauh lebih baik.

J: Tentu, cukup sertakan OPTION (RECOMPILE) dalam teks SQL dinamis:

DBCC FREEPROCCACHE;
 
USE AdventureWorks2012;
GO
SET NOCOUNT ON;
GO
 
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderHeader;';
GO
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderDetail OPTION (RECOMPILE);'
GO
 
SELECT t.[text], p.usecounts
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.[plan_handle]) AS t
WHERE t.[text] LIKE N'%Sales.' + 'SalesOrder%';

Hasil:1 baris menampilkan Sales.SalesOrderHeader pertanyaan.

Sekarang, jika ada pernyataan dalam kumpulan TIDAK menyertakan OPTION (RECOMPILE) , paket mungkin masih di-cache, hanya saja tidak dapat digunakan kembali.

DBCC FREEPROCCACHE(0x06.....);