【Oracle】DBの処理が遅延する問題について - 30代半ばの事務職員がITエンジニアになった話

Oracleで先月までは順調に動いていた
プロシージャが急に動作が遅くなった
ときの話

トラブル対応がいちばんの技術向上
とちょくちょく聞き、その通りだと思うけど
やっぱり自分で手を動かしてこそのこと
だとも思うのであって

今回直接トラブル対応したのは委託先
逐一報告を受けていたものの
内容を把握しきれたわけではなかったりして
(まだまだ知らないことがたくさんあるなぁ…)

たぶん、ほっとくと
このまま記憶が流されてしまいそうなので
覚えた専門用語をを書き留めておこう

あまりわかってないが故に
かいつまんで言うと

Oracleデータベースは
SQLを流したときに
いちばん早く処理できる
方法を自分で考えてくれるらしい

「統計情報」に早く処理できる方法を
探しに行って、考えたパターンが「実行計画」

ここで見つけたこれは早いぜ、っていう
「実行計画」のパターンをいくつか
ストックしておいて
似たSQLがきたときに早く処理できるように
しておく、このストックを
「共有プール」と呼んでいるらしい

実行計画の履歴を取っておくことができる機能
過去の実行計画を復旧したいときに必要

でもデフォルトで設定されているわけではなく
今回のような問題が起きたときに
あわてて設定しても時すでに遅し

導入時など先人たちが残してくれていればラッキー
なければ終了、、ということ

読んで字のごとくと思うけど
いまいちイメージがわかない
で調べると
CommitやRollbackをするまでは
テーブルがロック状態になるらしい

つまりアプリ側で
何かを入力する画面を開く
⇒テーブルロックを意図的にかける
入力画面で保存ボタンを押す
⇒Commitでロック解除
ということなのだろう

月末の締め処理などの際に
ロックをかけて編集できないように
することもあるとのこと

今回の処理遅延はまさしく
月末処理だったので
テーブルロックの解除を試行
結果、効果なし
あとからよく考えたらそりゃそうだ

これも文字通りOracleを起動すると
いちばん最初に読み込まれるもの

メモリをどれくらいまで使っていいとか
キャッシュの制限値とかを指定できる
のでこの辺の数値を最大まで許可するようにして
改善を試みる、がこれも効果なし

統計情報の再取得、共有プールの実行計画削除
などなど考えられる手段を試したのち
最後の手段、再起動
これでキャッシュ系に起因する問題なら
ほとんど解決するようだけど
残念ながら効果なし…
これでダメだとなかなかしんどい

遅延している原因を追究して
とあるViewの読み込みに時間が
かかっていることが判明

なのでViewの不要な項目を除外することで
処理の改善が図れて結果的にはOKだけど
直接原因に対する対策ではないので
なにか釈然としない

実は前回の同様の処理に比べて処理元の
データが極端に少なくなっている部分があり、

データを抽出するときって
１件でも検索結果があるときに比べて
検索結果が0件のときにえらく時間がかかることが
あるような気がする

ので、プロシージャのなかで
ループで検索結果0件の抽出を
繰り返していたりしたら
積もり積もって全体の処理が遅くなるのでは
とにらんでいるのだが
真相はたぶんうやむやになって消えていくのだろう