
Photo by
golchiki
知識があっても実務では…
仕事で対処した問題について。
〈前提条件〉
業務系システムの自社パッケージソフトで、サーバはオンプレミス。
データベースはSQLServer。
ユーザー規模は20名以下で、複数拠点。
〈問題発生〉
検索処理したら「クエリの時間切れ」というエラーが出る。
他ユーザーも処理が終わらないなど不具合がある。
これが、数ヵ月に1度。
〈応急対策〉
SQLServer上でセッション確認して強制終了
〈原因究明〉
対象ユーザーより規模の大きい会社では、同様のエラーが起きていなかったため、相違点を調査。
Wi-Fiなど通信環境の問題なども考えられたが、はっきりせず。
SSMSの拡張イベントで、収集対象のイベントを設定し、次回発生時のログ取得に期待。
その後、事象発生したタイミングで確認するとデッドロックのログが。
中身を見ると、典型的なパターン。
画面①
A→B→C の順にアップデート
画面②
A→C→B の順にアップデート
〈恒久対策〉
上述の通り、アップデートの順序が悪いことが明らかなので、処理順を修正してリリース。
もしかたら、これ以外の原因もあるかもやけど、1つ原因を潰せた。
〈思ったこと〉
ログをみると、教科書の例にのってるくらい明らかにデッドロックが起こる処理。
知識として、デッドロックは知っていたけど設計・製造時には考えられてなかったな。
この事例を通して、必死に調査することで、知識が経験として吸収された感じ。
でも、複数画面に分かって処理する場合、どうやって回避するように組むんだろう?
テーブルに優先順位をつけるとか?
そこんとこ、まだまだ勉強中…