MS SQL Serverは時間の経過とともに遅くなりますか？

次のいずれかを経験し、解決策を見つけましたか。

私たちのウェブサイトのバックエンドの大部分はMS SQL Server 2005です。毎週または2週間、サイトの実行が遅くなり、SQLでのクエリの完了に時間がかかります。使用したいクエリがあります。

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

これはかなり便利です... SQLサーバーに対してその時点で実行されているすべてのスナップショットを提供します。なんらかの理由でCPUが100％に固定されていて、Activity Monitorがロードを拒否している場合でも（一部のユーザーはそこにいると思います）、このクエリは引き続き返され、どのクエリがDBを強制終了しているのかを確認できます。

これを実行したり、SQLの速度が低下し始めたときにアクティビティモニターを実行したりすると、問題の原因となっている特定のクエリが表示されません。MS SQLサービスを再起動すると、すべてが正常になり、速度が速くなります-再び発生するまで1〜2週間。

何も変わったことはないと思いますが、これはほんの数ヶ月前に始まったばかりです…アイデア？

-追加

このデータベースの速度低下が発生した場合、1時間に10万ページビュー（1日のビジー時間）または1時間に1万ページビュー（遅い時間）を取得しても、すべてのクエリの完了に通常より長い時間がかかることに注意してください。サーバーは本当にストレスを受けていません-CPUは高くありません、ディスク使用量は制御不能ではないようです...それはインデックスの断片化または一種のようなもののように感じますが、それはそうではないようです場合。

上に貼り付けたクエリの結果を貼り付ける限り、実際にはできません。上記のクエリは、タスクを実行するユーザーのログイン、クエリ全体などを一覧表示します。データベース、テーブル、列、およびログインの名前をオンラインで渡したくありません：）... Iその時点で実行されているクエリは、常時実行されている通常の標準クエリであり、標準的なものではありません。

-3月24日

前回の再起動から約2週間になります。いくつかの変更を加えました。一時テーブルを頻繁に使用していて、まったく不要なクエリをいくつか見つけ、開発者にその方法を変更させました。常に（ゆっくりと確実に）成長しているいくつかのデータベースのサイズを、その成長に合わせてインテリジェントなサイズに調整しました。すべての自動拡張の設定も調整して、よりインテリジェントになりました（すべてが1 MBの拡張に設定されていました）。最後に、MSDBを少しクリーンアップしました。私たちはログ配布を行っており、何年も何年にもわたるバックアップポイントを保持する必要はありませんでした。これを数か月だけに保つスクリプトをいくつか作成しました。問題がまだ解決されているかどうかを判断するには時期尚早なので、このスレッドを更新し続けます。

我々はそれを見つけた。実際には、アプリケーションプールの1つに問題があったのはWebサーバーでした。同じクエリのセットを何度も繰り返し実行するとスタックします（たまたま一時テーブルで処理されていました）。ループしてループし、最終的にSQLサーバーを悲しくします。この問題のあるマシン/アプリプールが見つかり、すべて「解決」されました。

SQLサービスの再起動時に何が起こるか自問する必要がありますか？多くのことですが、2つの関連する点が頭に浮かびます：

1）SQLメモリが解放されます。

MaxMemoryの設定が高すぎると、SQLサービスが利用可能なすべてのメモリを使用するようになり、Windowsが重要なものをスワップファイルにスワップし始める可能性があります（その可能性はわかりません）。MaxMemoryが適切な値に設定されていることを確認し、そのボックスで実行する必要がある他のすべてのメモリを十分に残します（専用のSQLサーバーですか、それともアプリサーバーですか？）

2）TempDBはデフォルトサイズから再構築されます。

デフォルトのtempdbファイルのサイズ、特にTempDBログファイルのデフォルトのサイズと拡張間隔を確認します。成長間隔の設定が低すぎると、ログが信じられないほどの内部断片化を構築し、通常の使用を大幅に遅くする可能性があります。Kimberly Trippによるこれら 2つの優れたブログ記事を参照してください。

一時テーブルまたはカーソルを多用していますか？カーソルが閉じられ、正しく割り当て解除されていることを確認してください。また、リンクサーバーにも注意してください。古いリンクされたInformixサーバーにはバグのあるドライバーを使用する必要があり、定期的にサーバーを再起動する必要があることを意味します。

変に見える場合は、変を探してください。

SQLサーバーの設定を調整してもWindowsタスクマネージャーを試すことができない場合は、[プロセス]タブに移動し、[オプション]> [列]> [CPU時間]、[ハンドル]、[読み取り]、[書き込み]、その他、およびメモリオプションを追加します。

プロセスリストに戻ります。各列について、最高から最低まで並べ替え、上位5つのプロセスを確認します。異常なことはありますか？たとえば、プロセスのメモリリークには、奇妙な数のハンドルが含まれます。2秒ごとにDCSLoaderプロセスにハンドルを追加する* kiプリンターがいくつかあります。数週間後、マシンは多くの空きメモリとCPUをリストしますが、100,000のハンドルを持つプロセスはほとんどマウスポインタを動かしません。

スケジュールされたタスクのリストも確認してください。AVに.mdfファイルをスキャンしないように伝えます。

デイブ、

待機統計を確認しましたか？上記で与えたクエリは 'last_wait_type'列をリストします。その列には、クエリが待機しているもの（ネットワーク、CPUなど）に関する詳細が含まれる場合があります。

バックアップの「復旧モデル」がフルの場合、DBのバックアップを取り、次にトランザクションログのバックアップをとることで、事態は改善されますか？ディスク領域が不足しているシステムでは、この種のことが問題を説明している可能性があります。

私はあなたと非常によく似た構成（16Gb、32Gbにアップグレード、テラバイトのディスクを搭載したMD1000、デュアルクアッドコアxeon）を持っているようです。

私は、過去にそのような奇妙な問題を診断役立っている唯一のものはあるbeta_lockinfo Erland Sommarskogによります。遅い時間に実行して比較してください。

また、SP2以前のSQL 2005で非常に多くの問題がありましたが、SP3は本当に安定しています。

これがより有用な情報を与えることを願っています：

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

dbに問題がないことを確認します。

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

ログスペースに注意してください：

DBCC SQLPERF(LOGSPACE)

拡張が進行しているのを見れば、間違いなく速度が低下します。これを実行すると、ログスペースがますます100％に近づくのがわかります。その後、ログが拡大し、パーセンテージはスペースが増えるにつれて縮小します。うまくいけば、バックアップが開始されてログがクリアされるまで、それが拡大することは決してありません。

ほとんど馬鹿な設定。起こります。

• 最初に、実際に定期的にインデックスデフラグを定期的に実行する必要があります。バックアップを作成する直前または直後に、アクティビティとしてスケジュールします。

• 次に、データベースを自動拡張しないでください。特に、自動圧縮しないでください。負荷に応じて、自動拡張/自動圧縮は基本的に自殺設定です。

これほどSQL Serverの速度が低下することはほとんどありません。厳しいストレスのもとで、そのクエリの結果を投稿できますか？その時点でSQL Serverが過負荷になることはありませんか？