SQL Server2008のパフォーマンスが低い-新しいサーバーに移行した後の極端な速度低下
先週末、本番データベースを新しいサーバーに移動しました。これは、Windows Server 2008R2データセンターです。その上に、SQL Server 2008 Enterprise Edition64ビットの新しいインストールがあります。日曜日、移動が終了した後、すべてが正常に見えました。しかし、ユーザーが月曜日の朝にアプリケーションを使い始めると、物事はクロールまで遅くなり、それ以来遅くなっています。
チェック時に実行されているほとんどすべてのアクティブなプロセスが一時テーブルへの挿入であるため、問題をtempdbに限定したと思います。このクエリ：
SELECT '1' AS Number,GETDATE() AS Date INTO #Temp
Go
INSERT INTO #Temp
VALUES ('1', GETDATE())
GO 1000
新しい2008サーバーでは20秒かかりますが、SQL 2005を搭載した古いサーバーでは2〜3秒しかかかりません。
新しいサーバーには128GBのRAMが搭載されており、常にすべてのプロセスで合計35GBしか使用していません。古い本番サーバーでは、RAMの使用率は、ほとんど誰も使用していない場合でも、任意の時点で少なくとも50％であり、開発環境では約80％であり、正常です。新しいサーバー上のSQLServer2008が使用可能なRAMのごく一部しか使用していない理由がわかりません。
同じサイズの10個のデータファイルを使用するようにtempdbを再構成しました。以前は、コア/ファイルの比率が8：1の古いサーバーでは1でした。この新しいサーバーには48個のコアがあるため、コア/ファイルの比率は48:10でした。より多くのsrの1つ。ここでDBAは、tempdb用にさらに10個のセカンダリデータファイルと5個のログファイルを作成しましたが、これはまったく役に立たなかったようです。
Perfmonの合計メモリを確認しましたが、フラットライニングのようです。構成されているメモリに制限はないので、利用可能なすべてのものを使用する必要がありますよね？
Tempdbとメモリ使用量に関する質問への回答をグーグルで調べてみましたが、すべてのアドバイスは以前の2003サーバーまたは34ビットシステムを対象としているようです。 Windows Server 2008R2データセンターとSQLServer2008インスタンスに役立つ関連情報が見つかりません。
ネットワークの人もマイクロソフトに電話をかけようとしましたが、これまでのところ彼らは助けることができませんでした。
私を助けてください。私はそれがメモリ/ tempdbの問題であると本当に確信していますが、SQLが利用可能なすべてのメモリを使用するようにさせることができないようです。
あなたのシニアDBAは彼が何をしているのか知りません。残念ながら、複数のログファイルを追加してもパフォーマンスは向上しません。彼がログファイルがどのように機能するかを知らないのは残念です。ログファイルは順番に使用され、さらに5つのログファイルを追加すると、最初のログファイルが完全に使用されない限り、ログファイルは使用されなくなります。通常の日常業務では発生しません。
Tempdbに複数のデータファイルを追加することにより、MSFTと業界の専門家の間で推奨事項に関していくつかの矛盾があります。 MSFTはNiceを再生し、core：filesに1：1を推奨しますが、すべての場合に必要ではありません。業界の専門家によると、1：1/4から1：1/2で十分ですが、2：1：1（ページの空き容量、つまりPFSのボトルネック）と2：1：3（SGAMのボトルネック）に注意し、必要に応じてファイルの数。極端な場合には、コアの数よりも多くのファイルを追加する必要がありますが、その大きな「依存」です。
メモリの問題について、PageFileの使用率、ページの平均余命、バッファキャッシュのヒット率を確認しましたか。これらの数値が良好に見える場合は、この新しいサーバーに十分なストレスがかかっていない可能性があります。
Tempdb内のファイル数を変更する前に、待機統計情報を確認する必要があります。 24個のファイルが機能する場合は問題ありませんが、待機統計を調べて、tempdbがボトルネックであるかどうかを確認してください。 tempdbのボトルネックには2つの一般的なタイプがあることに注意してください（IO +割り当てボトルネック）。それが割り当てのボトルネックである場合は、TF1118を使用することもできます。
-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS
(SELECT wait_type, wait_time_ms / 1000. AS wait_time_s,
100. * wait_time_ms / SUM(wait_time_ms) OVER() AS pct,
ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS rn
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK'
,'SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR', 'LOGMGR_QUEUE','CHECKPOINT_QUEUE'
,'REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH','BROKER_TASK_STOP','CLR_MANUAL_EVENT'
,'CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT'
,'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP'))
SELECT W1.wait_type,
CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2
ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 99 OPTION (RECOMPILE); -- percentage threshold
やあみんな、すべての役立つアドバイスとリンクをありがとう。私は実際にはこのサーバーに対する管理者権限を持っておらず、SQLのみを持っているため、この情報の多くをシステム管理者に渡しました。金曜日以降、tempdbファイルを24個のデータファイルに再構築し、セカンダリデータファイルと余分なログファイルを削除したところ、非常に役立つようでした。金曜日の午後や週末はあまり負荷がかからなかったので、それだけで問題が解決したかどうかはわかりませんでした。
週末には、昨日まで気付かなかった作業がいくつかありました。彼らはSQLServer2005をサーバーといくつかのサービスパックにインストールしました。 （彼らはバックアップインスタンスを利用できるようにしたかったと思いますが、理由はよくわかりません）2005インスタンスがアクティブだったとき、RAMは通常のレベルまでのショットを使用します。 SQL Server 2005インスタンスが削除され、RAMの使用率は2008インスタンスでも高いままでした。これは良いことです。つまり、2008年に利用可能なすべてのRAMの使用を開始したかったのです。したがって、何かをキックスタートしたのが2005インスタンスなのか、それともサービスパックの1つなのか（現時点では必要ないはずの古いものでしたが）はわかりませんが、現在はRAM私たちもそれを望むところにあります。
特定の統計について全員に連絡しなかった場合は申し訳ありません。私は単なる中堅のDBAであり、この種のことをいじくり回しているビジネスは実際にはありません。おそらく、グーグルでtempdbのコア：ファイルの比率の問題を見つけたのは奇跡でした。
Tempdbのプライマリファイル構造が鍵だったと思います。だから、少なくともこれが同じ問題を抱えている他の誰かがポップアップするのに役立つことを願っています。