MS SQL Server melambat seiring waktu?

Adakah di antara Anda yang pernah mengalami yang berikut ini, dan apakah Anda sudah menemukan solusinya:

Sebagian besar back-end situs web kami adalah MS SQL Server 2005. Setiap minggu atau dua minggu situs mulai berjalan lebih lambat - dan saya melihat pertanyaan membutuhkan waktu lebih lama dan lebih lama untuk diselesaikan dalam SQL. Saya memiliki pertanyaan yang ingin saya gunakan:

USE master
select text,wait_time,blocking_session_id AS "Block",
percent_complete, * from sys.dm_exec_requests 
CROSS APPLY sys.dm_exec_sql_text(sql_handle)  AS s2 order by start_time asc

Yang cukup berguna ... ini memberikan snapshot dari semua yang berjalan pada saat itu terhadap server SQL Anda. Yang menyenangkan adalah meskipun CPU Anda dipatok 100% untuk beberapa alasan dan Activity Monitor menolak memuat (saya yakin sebagian dari Anda sudah ada di sana) kueri ini masih kembali dan Anda dapat melihat kueri apa yang membunuh DB Anda.

Ketika saya menjalankan ini, atau Monitor Aktivitas pada saat SQL mulai melambat saya tidak melihat pertanyaan khusus yang menyebabkan masalah - mereka SEMUA berjalan lebih lambat di seluruh papan. Jika saya memulai kembali Layanan MS SQL maka semuanya baik-baik saja, itu mempercepat - selama satu atau dua minggu sampai terjadi lagi.

Tidak ada yang dapat saya pikirkan telah berubah, tetapi ini baru dimulai beberapa bulan yang lalu ... Gagasan?

--Ditambahkan

Harap perhatikan bahwa ketika pelambatan basis data ini terjadi, tidak masalah jika kami mendapatkan 100 ribu halaman yang dilihat satu jam (waktu yang sibuk) atau 10 ribu halaman yang dilihat satu jam (waktu lambat), semua pertanyaan membutuhkan waktu lebih lama untuk diselesaikan daripada biasanya. Server tidak benar-benar di bawah tekanan - CPU tidak tinggi, penggunaan disk tampaknya tidak di luar kendali ... rasanya seperti indeks fragmentasi atau semacamnya tetapi itu tampaknya tidak menjadi kasus.

Sejauh menempelkan hasil kueri yang saya tempelkan di atas, saya benar-benar tidak bisa melakukannya. Kueri di atas mencantumkan login pengguna yang melakukan tugas, seluruh permintaan, dll. Dan saya benar-benar tidak ingin membagikan nama-nama database, tabel, kolom, dan info masuk online saya:) ... I dapat memberi tahu Anda bahwa kueri yang berjalan pada saat itu adalah normal, kueri standar untuk situs kami yang berjalan sepanjang waktu, tidak ada yang keluar dari norma.

- Raja 24

Sudah sekitar dua minggu sejak reboot terakhir. Saya membuat beberapa perubahan: Saya menemukan beberapa pertanyaan di mana kami banyak menggunakan tabel temp yang sama sekali tidak perlu dan membuat pengembang kami mengubah cara mereka melakukannya. Saya menyesuaikan ukuran beberapa database yang terus-menerus (perlahan tapi pasti) tumbuh menjadi ukuran yang cerdas untuk pertumbuhan mereka. Saya menyesuaikan pengaturan autogrowth untuk semuanya juga agar lebih cerdas (mereka SEMUA diatur ke pertumbuhan 1MB). Terakhir saya membersihkan MSDB sedikit. Kami melakukan pengiriman log dan benar-benar tidak perlu menyimpan poin cadangan bertahun-tahun, saya telah menulis beberapa skrip yang membuatnya hanya beberapa bulan. Saya akan terus memperbarui utas ini, karena masih terlalu dini untuk mengetahui apakah masalahnya sudah terpecahkan.

Kami menemukannya. Ternyata itu sebenarnya server web yang memiliki masalah dengan salah satu kumpulan aplikasi itu. Itu akan terjebak menjalankan set pertanyaan yang sama berulang-ulang (yang kebetulan berurusan dengan tabel temp) Itu hanya akan berulang dan akhirnya menyebabkan server SQL menjadi sedih. Setelah kumpulan mesin / aplikasi yang menyinggung ini ditemukan dan 'meletakkan' semuanya diselesaikan.

Anda harus bertanya pada diri sendiri, apa yang terjadi pada layanan SQL restart? Banyak hal, tetapi ada dua poin yang relevan muncul di pikiran:

1) Memori SQL dibebaskan.

Its mungkin (tidak yakin bagaimana mungkin), bahwa jika pengaturan MaxMemory Anda diatur terlalu tinggi, bahwa layanan SQL tumbuh menggunakan semua memori yang tersedia, dan Windows mulai swap hal-hal penting untuk swap file. Periksa untuk memastikan bahwa MaxMemory diatur ke nilai yang masuk akal, meninggalkan memori tambahan yang cukup untuk apa pun yang perlu dijalankan pada kotak itu (apakah itu server SQL khusus? Atau apakah juga server aplikasi?)

2) TempDB dibangun kembali dari ukuran standar.

Periksa ukuran file tempdb default Anda, terutama ukuran default dan interval pertumbuhan file TempDB Log. Jika interval pertumbuhan diatur terlalu rendah, maka log dapat membangun beberapa fragmentasi internal yang luar biasa, yang secara dramatis dapat memperlambat penggunaan normal. Lihat ini dua artikel blog sangat baik oleh Kimberly Tripp.

Apakah Anda banyak menggunakan tabel atau kursor sementara? Periksa apakah ada kursor yang ditutup dan dialokasikan dengan benar. Juga hati-hati terhadap server yang ditautkan - kita harus menggunakan driver kereta untuk server Informix yang ditautkan lama dan itu secara berkala berarti kita harus me-reboot server.

Jika terlihat aneh maka cari yang aneh.

Jika men-tweak pengaturan sql server tidak membantu mencoba task manager windows: buka tab proses, lalu opsi> kolom> tambahkan waktu cpu, menangani, membaca, menulis, yang lain dan opsi memori.

Kembali ke daftar proses. Untuk setiap kolom urutkan berdasarkan tertinggi ke terendah dan lihat 5 proses teratas. Adakah yang luar biasa? misalnya kebocoran memori pada suatu proses akan memiliki jumlah pegangan yang aneh. Kami memiliki beberapa * ki printer yang menambahkan pegangan ke proses DCSLoader setiap 2 detik. Setelah beberapa minggu mesin daftar banyak memori bebas dan CPU tetapi proses dengan 100.000 pegangan dan hampir tidak akan menggerakkan pointer mouse.

Periksa daftar tugas terjadwal Anda juga. Beri tahu AV Anda untuk tidak memindai file .mdf.

Dave,

Sudahkah Anda memeriksa statistik tunggu? kueri yang Anda berikan di atas mencantumkan kolom 'last_wait_type'. kolom itu mungkin memiliki beberapa perincian mengenai apa yang ditunggu pertanyaan (jaringan, cpu, dll.)

Jika "Model Pemulihan" cadangan Anda LENGKAP, lalu apakah mengambil cadangan DB dan cadangan log transaksi akan meningkatkan segalanya? Pada sistem yang kehabisan ruang disk, hal semacam ini mungkin menjelaskan masalahnya.

Saya tampaknya memiliki konfigurasi yang sangat mirip dengan milik Anda (16Gb, ditingkatkan ke 32Gb, dan MD1000 dengan satu cakram cakram, xeon quadcore ganda).

Satu-satunya hal yang telah membantu saya mendiagnosis masalah aneh seperti itu di masa lalu adalah beta_lockinfo oleh Erland Sommarskog. Jalankan ketika waktu lambat dan bandingkan.

Juga saya sudah memiliki sejumlah masalah gila dengan SQL 2005 sebelum SP2, tetapi SP3 benar-benar stabil.

Semoga ini memberikan info yang lebih bermanfaat:

SELECT  D.text SQLStatement,
        A.Session_ID SPID,
        C.BlkBy,
        ISNULL(B.status, A.status) Status,
        A.login_name Login,
        A.host_name HostName,
        DB_NAME(B.Database_ID) DBName,
        B.command,
        ISNULL(B.cpu_time, A.cpu_time) CPUTime,
        ISNULL((B.reads + B.writes), (A.reads + A.writes)) DiskIO,
        A.last_request_start_time LastBatch,
        A.program_name
FROM    sys.dm_exec_sessions A
        LEFT JOIN sys.dm_exec_requests B
        ON A.session_id = B.session_id
        LEFT JOIN (
                   SELECT   A.request_session_id SPID,
                            B.blocking_session_id BlkBy
                   FROM     sys.dm_tran_locks AS A
                            INNER JOIN sys.dm_os_waiting_tasks AS B
                            ON A.lock_owner_address = B.resource_address
                  ) C
        ON A.Session_ID = C.SPID
        OUTER APPLY sys.dm_exec_sql_text(sql_handle) D
WHERE   DB_NAME(B.Database_ID) = 'YourDBName' -- Comment out line for all db's
ORDER BY ISNULL(B.cpu_time, A.cpu_time) + ISNULL((B.reads + B.writes), (A.reads + A.writes)) DESC

Pastikan db tidak masalah dengan:

DBCC CHECKDB -- Checks the allocation and structural integrity of all the objects in the specified database.
DBCC UPDATEUSAGE (bybox) -- Reports and corrects pages and row count inaccuracies in the catalog views

Mengawasi logspace dengan:

DBCC SQLPERF(LOGSPACE)

Jika Anda melihat ekspansi terjadi, itu pasti akan memperlambat segalanya. Jika Anda menjalankan ini, Anda akan melihat ruang log Anda semakin dekat dan lebih dekat ke 100%, maka log akan berkembang dan persentase akan menyusut karena mendapat ruang. Mudah-mudahan Anda tidak akan pernah melihatnya meluas sebelum cadangan Anda masuk dan membersihkan log.

Kebanyakan konfigurasi bodoh. Terjadi.

• Pertama, Anda harus benar-benar secara teratur menjalankan defrag indeks dalam menjalankan pemeliharaan. Jadwalkan sebagai aktivitas, tepat sebelum atau setelah Anda membuat cadangan.

• Kedua, jangan autogrow database Anda dan terutama jangan melakukan autoshrink. Tergantung pada beban autogrow / autoshrink pada dasarnya adalah pengaturan bunuh diri.

Tidak terlihat pelambatan SQL Server seperti itu. Bisakah Anda memposting hasil permintaan itu di bawah tekanan hugh? Yakin tidak ada di ujung Anda kelebihan SQL Server pada saat itu?