Q&A
「いつもは300msで終わる処理」というのはどのような性質のものですか？
「事象が発生しているときにselectしているテーブルはない」けれども
「いつもは300msで終わる処理」が1.2秒ほどかかっているということですか？
ハードディスクの容量やメモリの使用状況等も確認すべき、ぐらいです。
SQL Serverの再起動は実施しましたか？
いずれにしてもこの質問内容で答えられることはあまりないと思われます。
SQL Serverで、急に処理が遅くなり、しばらくすると戻っている事象がおきています。2年以上問題ありませんでしたが、急に発生しております。
(お客様の環境で発生していて、いろいろテストできず、どこを調べれば良いか分からず困っています）
DB作成して最初のアクセスで長いのが急に発生して２～３時間(数分の場合もあり)、その後普通のスピードに戻る感じです。
情報が漠然として申し訳ないですが、SQL Serverの設定など実施すること、調査することなど助言等いただけないでしょうか
発生している問題／状況
SQL Server 2017を使用して処理を行っているのですが、先日より、急に処理が遅くなり、1～2時間するといつも通り戻るような事象がおきています
最初は30分程度戻ったのですが、今は2時間くらい立っても戻らず、しばらくするといつの間にか戻っているような状態です。先日は急に遅延が発生し、5分後に急に戻り、更に20分後に再度遅くなってそこから1時間復旧せず、4～50分程度放置して確認したら戻っていました。
主に全体から検索するようなSELECT文で遅延が発生しているようですが、まだ確証はありません。
（遅延している例：SELECT TOP 1 * FROM XXXXX WHERE DATE=20220127 AND NO=1 AND KUBUN<>9、NOを変更しながらSELECT実施）
遅延が発生している時に、全く同じデータを上記のような同じSELECT文で処理して遅延が発生していて、何故か急にいつも通りの処理時間に戻ったりしています。
試したこと・確認したこと
・SQL Server Profilerで見ると、いつもは300ms以下で終わる処理が1.2秒ほどかかるようになっていました。(もっと遅くなる場合もありました）
・統計情報の更新・実行プランのキャッシュクリアを行ってみましたが、現象が再発しています
・ハードディスク容量やメモリ容量は問題なし。パフォーマンスモニタで見ても特に高負荷ではない。
・ＨＤＤのエラーやRAIDのエラーは発生していない。
・SQL Serverの再起動、サーバーの再起動、サービスの再起動を行ったが改善せず。
・データベースの行テーブルを5Ｇ、ログを4Ｇに拡張。
INDEXの断片化は30％を超えるものはほとんど無かったのですが、とりあえず30％を超えるものは再構築、10％以上30未満のものは再構成したが、再発。（数分発生した後復旧）
環境
SQL Server 2017 Expressをサーバー2019上に構築
LAN経由でログインし、Windows10上で使用
2年以上使用して問題なかったが、急に発生
サイズの大きなテーブルは2つ
１つは65万件（インデックス領域約6M、データ領域約768M）
１つは38万件（インデックス領域約3.5M、データ領域約428M）
情報が不足していてすいません。
確認した内容の記載が漏れていました。
・ハードディスク容量やメモリ容量は問題なし。パフォーマンスモニタで見ても特に高負荷ではない。
・SQL Serverの再起動、サーバーの再起動、サービスの再起動を行ったが改善せず。
どこを調査すれば良いか困窮していて、質問内容もつたなく申し訳ないです。
すごく気になる問題ですね。
「SQL Server Profilerで見ると」とのことですので、検索した時に上位にヒットする@ITの連載記事などの調査もしてみてのことですかね。
原因不明の処理遅延が「不定期」に発生する（パフォーマンストラブル）：SQL Serverトラブルシューティング（49）（1/2 ページ） - ＠IT
https://atmarkit.itmedia.co.jp/ait/articles/1706/05/news001.html
* 発生する時刻に規則性はありますか？
* 「先日より」の直前に何か変更しました？
ロックのような待ちが発生しているというより、負荷の高い処理が動いていて遅いという感じですかね？
(見当違いでしたらすみません・・)
情報にあるページは参照しておりましたが、解決に至っていない状況です。
発生時刻に特に規則性は無く、特に変更もしていない状況です。
今まで特に問題なく動いていたのに、急に遅くなる事象になったので、負荷の高い処理ということもなさそうですが、そのあたりも再度調べてみます。
情報ありがとうございます。
「いつもは300msで終わる処理」というのはどのような性質のものですか？
「事象が発生しているときにselectしているテーブルはない」けれども
「いつもは300msで終わる処理」が1.2秒ほどかかっているということですか？
↑このあたりにご回答していただけないでしょうか？
またローカル（SQL Serverが起動しているサーバ上）で実行した時と
ネットワーク越しに実行しても速度に違いはないのですか？
質問して頂いたのに回答不足ですいません。
「いつもは300msで終わる処理」というのは、
「SELECT TOP 1 * FROM XXXXX WHERE DATE=20220127 AND KUBUN<>9」
のような感じで、同じ日付のデータからあるデータが9以外の最初の1件を取得するものです
これをネットワーク経由で実施しているのですが、遅いときは同じデータを取得しているのに1.2秒以上かかっています。
また、「事象が発生しているときにselectしているテーブルはない」のでは無く、「事象が発生している時にSELECTしているテーブルの断片化は30％を超えていない」と言うことです。
わかりにくくてすいません。
また、遅いときはローカルで実行しても遅い状態でした。
現在は念のためIndexの断片化が30％を超えているものを再構築、10％以上30％未満のものを再構成して様子を見ているところです。
「いつもは300msで終わる処理」について、実行プランは通常時と遅い時で変わるでしょうか？
(INDEXの断片化などの調査もしているようですので同じですかね・・)
https://docs.microsoft.com/ja-jp/sql/relational-databases/performance/display-an-actual-execution-plan?view=sql-server-ver15
関係ないかもしれませんが、アプリケーションの構成についてもご記載いただけますでしょうか？
ユーザーは何かしらのクライアントのアプリケーションがあって、それを使用して遅いと感じて調査依頼があった感じでしょうか？
(ユーザーが直接SQL Serverを参照しているわけではないですよね)
実行プランの差は確認していませんでした。（知識が足りず、すいません）
再発して欲しくはないですが、もし再発したら確認出来るか調べておきます。
アプリは、サーバにあるSQL Serverを参照／更新するクライアントアプリをユーザーが操作しています。
ある一連の処理で通常なら2～3秒で終わるのが10秒もかかって運用に支障が出ている状態です。
その一連の処理を調べたら、上記のようなSELECT処理が遅く、そのPCが悪いのかと思ったら他のPCでの別処理（データを検索／集計するような処理）でも発生して、サーバー上でのSSMSでも遅いことが分かり、、、といった感じです。
キーを指定しただけのSELECT文やUPDATEなどは遅くないようなのですが。
知識不足でネットを調べながら試している状態です（そんな状態で使っていることも問題なのですが、急に遅くなったり戻ったりする事象は初めてで、、、）
ハードディスク自体にエラーがあるか故障していることはないですか？
システムログなどでディスクエラーがあったりなど。
可能であればchkdskなどをコマンドで実施してみるといいかもしれません。
RAID環境ではあるのですが、一応chkdskは実施してみます。
ありがとうございます。
RAIDのユーティリティとかでエラーはないのですか？
ディスクエラーやRAIDのエラーは未確認でした。念のため確認してみます（来週以降になりますが）
ご指摘ありがとうございます。
ディスクエラーやRAIDのエラーはありませんでした。
また、本日も現象が再発しています（今日は数分で復旧しました。。。）
見当違いかもしれませんが・・
色々可能性を考えてみました。
> SQL Server 2017 Expressをサーバー2019上に構築
あまり注意して見ていなかったところでしたが、Expressエディションだったのですね。
個人的に過去に見てきたデータベースサーバーでは、メモリがかなり搭載されていたものばかりで、それが当たり前の印象でしたが、Expressエディションではハードウェアの性能も制限されてしまうようですね(メモリ以外にも)。
解決が困難そうでしたらMicrosoftのサポートにも問い合わせした方が良いのかな？とも思いましたが、Expressエディションだとそういったこともできないですかね？
> ・ハードディスク容量やメモリ容量は問題なし。パフォーマンスモニタで見ても特に高負荷ではない。
Expressエディションということで、SQL Server自体が高負荷であっても(ハードウェアの性能が制限された範囲内の高負荷)、OSのパフォーマンスモニターまで表面化することがないという可能性もありそうかな？と思いました。
(すみません、サーバー自体のスペックなど把握せずに書いています・・)
> SQL Serverで、急に処理が遅くなり、しばらくすると戻っている事象がおきています。
処理が遅くなっている(それが継続している)のであれば、その処理自体に問題があるように思いますが、しばらくすると戻っているということですので、その処理自体より他からの影響を受けてその処理が遅くなっている可能性もあるのかな？と思いました。
sousukeさんがご記載されている「事象が発生しているときにselectしているテーブルはない」かどうかを早めに切り分けしておいた方が良さそうに思いました。
負荷が高いSQLを特定できそうな記事のリンクを記載してみます、こちらを試してみたらどうでしょうか。
(その原因がアプリケーションから発行されるSQLであれば調査しやすそうな印象ですが、SQL Server自体の処理{トランザクションログが〜・・・など}だと調査が難しそうな印象がしました)
https://dev.intra-mart.jp/sqlserver_sql_trace/
https://memorandom-nishi.hatenablog.jp/entry/2017/03/14/003302
> 2年以上使用して問題なかったが、急に発生
ではありますが、データが増えたことによって、潜在的にパフォーマンスに問題があったSQLの問題が顕在化する、という可能性もあるのかな？と思いました。
(「急に」というのはちょっと理解に苦しむところがあるかもしれませんが・・)
---
Oracleがデファクトスタンダードな時代にSQLのパフォーマンスチューニングをしたことがありましたが、今の時代は自動的に行われるのでしょうかね・・？
自分自身が負の遺産になってしまっているかな？という恐怖も感じつつ、コメントを書いている次第です・・
(パフォーマンスの調査の参考にできそうなリンクを記載してみます)
https://docs.microsoft.com/ja-jp/sql/relational-databases/performance/monitor-and-tune-for-performance?view=sql-server-ver15
https://docs.microsoft.com/ja-jp/sql/relational-databases/automatic-tuning/automatic-tuning?view=sql-server-ver15
https://docs.microsoft.com/ja-jp/learn/paths/optimize-query-performance-sql-server/?WT.mc_id=DP-MVP-4033504
https://qiita.com/Masayuki_Ozawa/items/d482c5b64b22198e564f
https://qiita.com/kazuho39/items/26e242b6087ed43fe01b
https://qiita.com/kazuho39/items/0d3e617661670311ea05
いろいろ考えて頂きありがとうございます。
提示頂いた情報を確認してみます。
なお、SQL文の方も遅延箇所等で共通点や関連等ないかなどいろいろ調べて見ます。
あと、次に顕著な遅延がでた場合は、サイズが大きいテーブルのデータをCSVで待避しているので、少々削減して暫定的な効果があるのか試そうと考えています
(追加情報があったら状況欄などに追記していきます）
その後頻度は低いですが再発しているため、データ数削減して様子見中です
なお、処理が遅くなったあとまた戻るという今回の事象とは結びつかない気もしますが、遅くなっている処理の一部のSQLにキー指定が足りない箇所があったのでそれは修正して後日確認予定です
（これにより、遅くなったとしてもその遅さが抑えられると思いますが、元々の遅くなったり戻ったりという事象の原因は不明のままです）
回答1件
0
自己解決
何故遅くなった処理が急に元に戻るのかは不明ですが、以下の対処をすることで、遅くなる事象は回避できているようです。
1．DBのキーが全て指定されているか確認する
（今回は、データが全て同じ物がキーになっているテーブルがあり、そこでキー指定が漏れていました）
2．全体のデータ量を減らす。
よく分からない状況なのに回答案をフォローしていただいた sousukeさん xg63ex2bさんありがとうございました。
投稿2022/04/21 01:58
総合スコア40
あなたの回答
tips
プレビュー
