Pendapat DDL tentang TempDB

Saya memiliki SQL Server 2005 Standard x64 yang mengalami masalah dengan anggapan TempDB DDL selama beberapa bulan terakhir. Server akan mengalami pertengkaran tentang sumber daya menunggu 2: 1: 103 (jenis menunggu adalah PAGELATCH_EX).

Masalah ini tampaknya terjadi secara sporadis ketika server berada di bawah beban yang layak. Saya telah memantau tingkat "Temp Tables for Destruction" dan dapat melonjak hingga 5.000+ saat kami mengalami masalah PAGELATCH_EX pada 2: 1: 103. Dari apa yang telah saya baca, penghitung ini seharusnya merupakan 0 mayoritas waktu, tetapi milik kami tampaknya tetap berada di antara 300-1100 mayoritas waktu. Penghitung hanya masuk ke 0 ketika ada sangat sedikit pengguna di sistem.

Bagaimana saya bisa mempersempit apa yang menyebabkan pertikaian DDL pada tempdb tanpa harus mencari jarum di tumpukan jerami?

Saya telah melihat masalah ini dan perbaikan terbaru yang akhirnya dirilis untuk memperbaikinya sebenarnya adalah akibat langsung dari kasus saya dengan Microsoft CSS. Tidak ada artikel KB publik untuk perbaikan. Pastikan Anda telah menerapkan Paket Layanan 4 dan pembaruan kumulatif terbaru untuk SQL Server (pada saat penulisan, itu adalah Pembaruan Kumulatif # 3 (9.00.5259) ).

Sampai perbaikan terbaru dirilis, saran Microsoft adalah berhenti membuat tabel #temp (seperti KB # 916086 ). Karena ini akan berarti penulisan ulang lusinan dan banyak prosedur pelaporan, solusi dalam kasus saya (terlepas dari jejak bendera atau tata letak file temp) adalah untuk memulai kembali cluster kami setiap akhir pekan. Yuck.

Untuk melacak penggunaan tempdb, ada beberapa skrip yang dapat membantu, mis. Lihat sp_whoIsActive Adam Machanic , khususnya:

• sp_whoisactive: Menganalisis Tempdb Contention
• Bagaimana cara mengidentifikasi kueri mana yang mengisi log transaksi tempdb?

Dan juga skrip ini (dan yang ada di komentar) dari @SQLSoldier:

• Breaking Down TempDB Contention

Saya akan memastikan semua kursor Anda menggunakan LOCAL STATIC READ_ONLY FORWARD_ONLY(lihat ini dan ini ), dan lihat apakah ada pertanyaan mahal yang diketahui yang menggunakan tabel #temp / @table variabel, CTE, atau mungkin berisi jenis yang tidak perlu atau mengarah pada hash joins ... semuanya dapat berkontribusi pada masalah (saya ragu Anda akan menemukan satu penyebab emas). Perbaikan sweeping termudah sebagai titik awal "bang-for-your-buck" adalah dengan menggunakan opsi kursor yang tepat dan murah daripada default.

Sementara itu saya akan (a) menginstal CU # 3 dan (b) memanggil PSS. Beri tahu mereka bahwa Anda setelah perbaikan yang sangat spesifik yang telah dikonfirmasi sebagai bug dan dirilis ke pengguna lain sebagai perbaikan terbaru pribadi: "VSTS # 109112 - Penurunan suhu temp table tidak menskala untuk beban kerja tertentu." Anda mungkin harus membayar biaya kasus pada awalnya tetapi, karena ini adalah bug, biayanya harus dikembalikan.

Anda mungkin perlu melacak bendera 1118

Lihat dulu mitos-mitos Paul Randal tentang tempdb , dan artikel TF 1118-nya juga

TF dijelaskan di sini di KB 328551

Saya tidak punya pengalaman langsung tentang ini tetapi kedengarannya seperti apa yang saya baca

Saya berasumsi bahwa Anda sudah membagi data-file TempDB Anda untuk mencoba meredakan pertengkaran (melalui pra-produksi terlebih dahulu jelas). Jika Anda lebih berani, pertimbangkan jejak bendera yang oleh Paul Randal merujuk secara resmi: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230) -tempdb-harus-selalu-punya-satu-data-file-per-prosesor-core.aspx

Dalam hal apa yang menyebabkan rasa sakit, Anda perlu melakukan beberapa pekerjaan investigasi:

• Apakah ini baru saja mulai terjadi? apa yang telah berubah
• Apakah server di bawah tekanan memori, jadi harus dilakukan di TempDB?
• apakah ada proses DBA seperti CheckDB, atau pengindeksan ulang online, berjalan?
• Apakah level isolasi yang lebih eksotis digunakan, atau broker layanan? lihat di sys.databases

Ada pertanyaan yang bagus di bagian bawah dokumen Microsoft TempDB ini untuk mencoba mencari tahu apa yang menggunakan tempdb: http://technet.microsoft.com/en-gb/library/cc966545.aspx

Jika Anda masih mencari untuk melacak ini, saya baru-baru ini memiliki masalah kinerja yang sama anehnya dengan drop tabel sinkron. Jika Anda memiliki sejumlah besar database (> 100 atau lebih) pada contoh sql yang menjalankan SQL 2005 dan Anda memiliki banyak tabel temp membuat dan menjatuhkan pernyataan Anda bisa mendapatkan tetes tabel temp lambat. Memeriksa jumlah baris yang dikembalikan dari sys.dm_db_index_usage_stats dapat langsung mengesampingkannya sebagai pelakunya.

Artikel KB menjelaskan masalahnya. http://support.microsoft.com/kb/2003031

Performa kueri berkurang ketika sys.dm_db_index_usage_stats memiliki banyak baris

Pertimbangkan skenario berikut:

Di Microsoft SQL Server 2005, Anda sering melakukan operasi DDL yang melibatkan menjatuhkan dan rekreasi banyak tabel (terutama tabel sementara di database tempdb). Anda memiliki banyak entri (100.000 atau lebih) di sys.dm_db_index_usage_stats dynamic management view (DMV).

Diambil dari jawaban yang saya terima untuk pertanyaan ini. Ada beberapa detail lagi di sana. Tabel temp lambat turun dalam sql 2005