今週唯一のトラブルシューティング

久しぶりのトラブル。処理遅延。

テストの時は1時間くらいで終わった処理が2時間経っても終わらず、
いつ終わるかもわからないので、プロセスをkillして、
他の処理を流しています、と。

センターに駆けつけて、SQLの実行計画をみてみる。悪くなさそう。
IO待ちとか？
STATSPACKが見れればいいんだけど、権限がない。
権限持ってるお客さんも今日はいない、と。
(RDBMSはOracle9iでコストベースオプティマイザ)

テーブルとインデックスのLAST ANALYZEDを見ても、
テストの時と変わっていない。

仕方がないので、12多重になっている処理の多重度を32に上げて実行。

確かに遅い。とにかく遅い。
SQLトレースを見ると、フェッチにすごい時間がかかっていて
経過時間とCPU時間がほぼ一緒。
物理IOもほぼ発生していない。

やりようがない。。
フェッチのサイズがデフォルトの10のままなので、
ALTER SESSION文でもう少しでかくしてあげれば
ちっとは早くなると思うけど、
以前早かったものが遅くなった理由にはならない。

30分くらい実行したところで、処理時間(フェッチした行数)から
算数したら、2時間半くらいで処理が終了しそうなので、
2時間半くらいなら運用的にも問題なさそうなので、
この処理はとりあえずこのまま終わらせて、
後続の他の似たような処理が動くまで待つ事に。

後続処理は早い。全然違う。CPU時間だけ。。
1行あたりに取得するブロック数もほぼ同じ。

さて、どうしたもんかなぁと思いつつ、
その処理自体はあと2〜3回動いて捨ててしまうプログラムらしいので、
まぁ、いいか、なんていう。

でも、気になる。
なんでなんだろう。

とりあえず、来月もウォッチだなぁ。

会社のとある研修で

画面間の引継ぎ情報の設計どうする？っていうネタ。

クライアントでhiddenで持つとか。
サーバー側で持つとか。
データベースで持つとか。

新人の頃のプロジェクトでは、クライアントで持ってました。
2〜3年目の頃のプロジェクトでは、データベースで持ってました。
最近やってるPJでは、クッキー＋サーバー側で持ってます。

冗長構成でフェールオーバーなんていう、セッションレプリケーションは
サーバーとして、そういう仕掛けを持ってたりするので、
それ使っちゃうのが一番楽チンだ、とか。

ワークショップやってて面白かったところ

• -

① 一覧画面→詳細画面→｢キャンセル｣ボタンで一覧画面に戻す

　一覧画面は1〜50件まで、51〜100件まで、、
　なんていう風な制御になってるとして。

　｢キャンセル｣ボタン押されたら、どうやって戻す？っていう。

　・データベースにもう1回取りにいく
　→その間にデータベースの件数の増減の影響を受けて、
　　例えば50件目のレコードを選択してたとしたら、
　　それが51件目になってしまったら、そのページに自分が選択した
　　レコードは表示されていない
　　⇒夜間バッチでしかデータベースの情報が変わらないようなものだったら
　　　いいのかもしれないですけどね。
　　　あとは、必ず1ページ目(1〜50件)に戻すようにする、とか。

　・キャッシュに持つ
　→50件分くらいだったらよくね？
　　⇒キー情報だけキャッシュに持たせて、
　　　画面表示情報はその時に取得させるような仕掛け作れば。

• -

② 同一プロセスで複数画面(タブとかCtrl+Nとか)対応

　何もしないと後勝ちになってしまう。
　[画面1]で数量が2。
　[画面2]で数量が1。
　[画面2]を表示したのが後だとして、
　でも登録ボタンを押したのが[画面1]だったとすると、
　オペレーションした人は数量は2だと思ってるのに、
　実際登録された内容は数量1っていう。

　・登録ボタンを押す画面表示にIDを付ける
　→登録ボタンがある画面を表示するときにIDを振って
　　それをセッションに保持してから
　　クライアントにレスポンスを返す。
　　クライアントはhiddenフィールドにそれを保持して
　　登録ボタンが押されたら、hiddenフィールドからリクエストされたIDと
　　セッションのIDが一緒じゃなかったらダメ。
　　⇒ブラウザの戻るボタン禁止令？

この1年半くらい、ほぼバッチばかりやっていたので。
久しぶりにこういうこと考えました。

Amazonとか、どうなってんだろうって。
こういう仕掛けは自力で考えるのもいいですけど、
どこでも似たようなことやってるんだから、
それに従っちゃうのが一番なのかな、、と思うのですが。。