web-dev-qa-db-ja.com

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

sql-serversql-server-2005
8
Dave Holland

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

3
Dave Holland

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

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

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

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

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

2
BradC

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

1
MartW

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

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

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

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

0
jqa

デイブ、

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

0
SQLRockstar

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

私が過去にそのような奇妙な問題を診断するのを助けた唯一のことは、Erland Sommarskogによる beta_lockinfo です。遅い時間に実行して比較してください。

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

0
Ricardo Pardini

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

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％に近づくのがわかります。その後、ログが拡大し、パーセンテージはスペースが増えるにつれて縮小します。うまくいけば、バックアップが開始されてログがクリアされるまで、それが拡大することは決してありません。

0
Simon Hughes

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

0
djangofan