記事カテゴリ

ユーザー機能


 2024年5月 4日(土) 14:05 JST

問題解決ってそれでいいの?

  • 投稿者:
  • 表示回数
    3,804
問題解決、特に急いでいるときの問題解決までとは、「問題の原因調査行動を取りつつ問題解決の方法を探し、その中から最も効率的な解決策を実施」すればいいと考えている。
解決策は一つである必要はないし、できれば複数用意できればそれに越したことはないと思う。さらに押し進めると、原状の回復が早急に望まれている場合には、とりあえず対応もあるだろうし、複数の解決策を並行で用意すれば結果的に実施されない解決策もあると思う。
しかし、問題解決の複数の解決策を複数同時に適用するのは、原因がわからなくなったり、そもそも複数の解決策の互いの影響があるかもしれないので避けるべきだと思う。

複数の解決策を平行で準備するのは問題がないはずだ、そのはずなのに、この手順では担当者から不満が出る。
担当者曰く、「一つの解決策の実装中に横で他の解決策の話が行われると、この解決策は必要ないのか?」と。
今日、今まで動いていたプログラムが動かなくなった。


お昼にリーダーから一言、「データベース応答無かったら一定期間で切断する方法はない?」と相談があった。
データベース接続は BDE で行っており、接続先データベースは Oracle、BDE は Oracle ドライバだとタイムアウトの設定がないので、他の手段を使うしかない。
マルチスレッドで監視 か TCP/IP のタイムアウト、SQL*net でもタイムアウトの設定が設定できるとか...

相談の結果今回はとりあえず、スレッドで接続してメインスレッドで一定時間で接続が確立されていなかったら、切ることになった。他の担当者はマルチスレッドは難しいと言っていたので、とりあえずサンプルを作ってテストすることになった。

サンプルが完成したところで改めてなぜ応答が返ってこないのか確認したところ、DBリンクしているSQLでDBリンク先がオフラインだと応答が返ってこないとか....
それって、Oracle 側の問題じゃないの?Oracle 側で設定してよ...

しかも、それの状況すら間違ってるし...
本当はプログラム内の SQL の Prepair で落ちてた。いろいろ調査した結果を整理すると、
  1. Prepair で無反応になる
  2. 昨日までは正常に動作していた
  3. プログラムは変更されていない
  4. 変更点としては、OSのパッチが適用された
  5. 平SQLでは正常に動作する>パラメータクエリだけがダメ(SQL Plus、Database Expolorerで確認)
  6. 他のSQLも問題なく実行出来る(他のパラメータSQLも)
  7. テスト機では今でも同じプログラムが正常に動作する。
  8. 本番機とテスト機の差は、Oracle のバージョンが微妙に違う

以上の状況と、お客さんが「とりあえず動くようにして、問題調査は明日以降でもいいよと」言っていたので、3人で相談して
とりあえず他の担当者にパラメータクエリのパラメータを埋め込みにしてもらって平SQLで動くように変更してもらった。
それが、そのとき考えられる中で一番労力がかからず、しかもうまくいく可能性が一番高いように思えた。
(Database Explorer は Delphi で作られているとのこと、ちなみに、Database Desktop は Delphi ではない。)

その横の席で、リーダーと根本の原因を探り始めた。
Linux カーネルと Oracle の相性か?そんなことがあり得るのか?と言う推測がリーダーから、くろねこの頭にあったのは、 Oracle の構文解析がなぜ失敗しているのか相性が原因でパーサーが構文解析のパーサーが動かない?と言うのも思ったが、それは状況別に別モジュールになっていない限り、たぶんないと思うとすぐに自己否定された。

上記のの対策が終わらぬ間にその横で、リーダーに「SQLパーサーの動きがが変わったんなら、View に対して絞り込みする方法もやってみるとうまくいくかもしれませんね...」とか話してみた。
リーダーは調査しながらも、とりあえず View を作ってくれた。

そんな中、「Linux のカーネルパッチを適用したのなら、Oracle を落としてない?」と聞いてみたところ、Oracle の再起動を行っているとのこと。
「じゃあ、メモリにあった構文解析のための情報ってなくなってるよね、馬鹿になったんじゃない?」と話をしてみた。
その話を聞いていたお客さんが、「それなら、ヒントを与えればうまくいくじゃないの?」と、で SQL にルールベースの指定をしてみると、正常に動作する。(ちなみに元の SQL に戻して正常に動いた。しかしこれは一度ヒントを与えた SQL で学習したからだと結論づけた)

結局、ルールベースの SQL で本番は行くことにした。そんな中、お客さんから一言「今回の問題の回避策って無いよね」、いや無い訳じゃないけど...「テストする際に一回データベースを再起動しておけば発見できたかもしれませんね。」と返しておいた。リーダーからは「現実的じゃないな」と、確かにハード面の費用とか結構かかるけどね...

問題の解決が終わろうとしてたころ、他の担当者から「横で他の解決策の話をされると、この解決策は必要ないのか?と思う」と、「いろいろ試す前にホワイトボードに方法を全部書かないと...」とつっこみが...
後者はまだわかるんだけど、前者はちょっとねわかるけどその方法がだめなときの次の手を準備するのは仕方ないんじゃ無いの?と言うのが正直な気持ちだった。

トラックバック

このエントリのトラックバックURL:
https://www.blackcat.xyz/trackback.php/post_85

以下のコメントは、その投稿者が所有するものでサイト管理者はコメントに関する責任を負いません。