目覚ましの 30分前に起きる。
手洗いに行って、また寝る。Zzzzzz・・・・。
　目覚ましが鳴る。目覚ましを止めて寝つづける。
Zzzzzz・・・・いかんいかん。

　会社に行って今日も仕事C の作業。
　基幹DB のテスト用の DB で、昨日テストで変更したデータを
元に戻す Query を実行・・・したら、Query が誤っていて、そのテーブルの
全データの更新をしに行ってしまった(爆)。
しかも、その更新の対象のテーブルには変更の履歴を
取るためのトリガがセットしてある。
そして、SQLPlus ではなく、Third Pirty制の
「Object Browser」というツールを使っていた。
このツール、Query を投げると、終わるまで、
帰ってこない。う〜〜〜〜。
考えあぐねて、とりあえず、「Object Browser」を強制終了。
で、再度「Object Browser」を起動して接続。こんどは
ちゃんと目的のデータだけを更新するようにして Query実行。
・・・帰ってこない。再度強制終了。
再度「Object Browser」を起動して Session情報を見てみる。
「Object Browser」を強制終了したときの Session が
残っていたので、Session を Kill した。
で、再度Query を実行。・・・やっぱり帰ってこない。
Session の情報を見ると、Session が「Killed」にはなっていたが、
まだ一覧には残っていた。
で、ロックの情報を見ると、Kill した Session が
ロックを保持したままだった。
・・・一所懸命ロールバックしているんかなぁ・・・。
会社に置いてあった Oracle の運用に関する本を見ると、
デッドロック障害の場合は Shutdown Abort してから
Startup すればいいと書いてあった。
この場合はデッドロックではないが・・・。
と、とりあえず、しばらく様子を見よう。
ロールバックをしているのならばいつか終わるやろ。(逃避行動モード)
もともと、即座に Query を中断できない
「Object Browser」が悪いんやぁ。(責任転嫁モード)

　さて、仕事C の例外対応で、基幹DB に登録する処理まわりの
続行ができなくなったので、他の部分を進められるかを検討し、
印刷帳票の例外への対応部分が進められそうだと着手し始める。
・・・って、ロックが解放されたら分かるように
「オブジェクトブラウザ」を立ち上げ、
ロックの情報の画面を表示させとこう。
情報の更新は手動でしないといけないが。
・・・・? ロックの情報が表示されない? Session も消えてる?
試しに、更新の Query を実行・・・動いた♪
トラブル発生から1時間半、なんとか復旧してくれたようだ。
えらいぞ、Oracle。で、やっと、基幹DB に登録する処理まわりの作業の続行。

　お昼は「北海道チーズ蒸しケーキ」と「ウイダーインゼリー」。
・・・なぜか、机のうえに、「ウイダーインゼリー」が2個ある。
いままでの日記で、実際には食べてないのに
「ウイダーインゼリー」を食べたと書いている日があるな(爆)

　午後も仕事C の作業。
基幹DB への登録処理部分の作業を続けて、一応できた。
で、基幹DB への登録がうまく行っているか、
「Object Browser」で確認。・・・うまくいってないやん。
・・・って?あら?? テーブルを結合せずに表示させたらちゃんと値が入っている??
Query を変えて・・・なんじゃぁ、範囲外の値ですって、
そんな値が入っている訳ないやんかぁ(ぎゃおぉおぉおぉん)
で、同じ Query の SQLPlus で表示させると、
ちゃんと値が入っていた。
「オブジェクトブラウザ」が Bug っているやんかぁ。ばっきゃろ〜。
で、最新版を Download してくる。バージョンがずいぶん上がっているようだ。
・・・しかし、Bug は直ってなかった。うぐぐぐ。
・・・そして、これが後に重大なトラブルを
引き起こすきっかけとなる。(責任転嫁モード)

　さて、データが正しく登録されているか、どうやって確認するか?
う〜〜〜、SQLPlus の出力じゃ見難いからなぁ・・・。
グリッドが欲しいが、「ObjectBrowser」が使えないし・・・。
Access でリンクテーブルを使う? Excel に出す?う〜〜〜。
・・・あ、Oracle の DB を SQL Server にリンクしているので、
Query Analyzer で Openquery文を使えば表示できるやん♪。
・・・ってんで、データがちゃんと入っていることを確認し、
また、テスト環境ではなく、実環境で本物の基幹DB に接続し、
基幹DB 内の例外処理時のデータとの比較もした。
・・・後で考えたら、このとき、本物の基幹DB のデータと
比較しなければならない必然性は無かった・・・。
・・・で、ここで、実環境に接続したことが後で問題を引き起こす。
この場では比較が終われば実環境に接続した
MDI の子ウィンドウは閉じたが。

　で、とりあえず、基幹DB に登録する部分の処理まわりは終了。
次は印刷帳票の対応。作業の区切りで、一旦すべてのウィンドウを閉じた。

で、印刷してみたが、Data の作成時に追加しておいた方が
いい情報があることが判明し、
例外処理用に追加したテーブルにフィールドを追加することにする。

　終業時間になって、マクドに買い出し。

ちょっと休憩してから再度作業開始。
テーブルを更新する Script を生成し、Query Analyzer を起動して実行。
でストアドプロシージャも対応させて更新。
で、テスト用のデータを作成。うむ、うまくいっているようだ。
で、基幹DB に登録。クライアントから実行しよう。
・・・あらら? 登録する情報が違うぞ?

・・・ぎゃあぁあぁあぁあぁあぁ、

　実環境でテスト用データを作っていたぁ(爆)。
ちゃ、ちゃんと、Clean Up Code があって、
元にもどす様にしているから、実際には破損はしていないはずだよな。
クエリアナライザで基幹DB にデータを登録するストアドプロシージャを
実行してないから基幹DB には全く手をつけてないよな?
だいじょうぶだよな、多分・・・・。
Query Analyze は起動時の接続で前回の接続時に設定したサーバーを
Default で表示する。で、先の例外データの確認のために
実環境のサーバーに接続したというのが残っていて、
テスト用のサーバーではなく、実環境の方のサーバーに
接続してしまっていたのだった。
・・・もとはと言えば、グリッドで値を正しく表示しなかった
「Object Browser」が悪いんだぁ。(責任転嫁モード)
ま、まぁ、大丈夫だろう・・・。

　気を取り直して、テストデータをテスト環境に作る。
で、クライアントの Access Project のレポートが
印刷する際に参照するスノーフレークのワークテーブルのデータを
作成するストアドプロシージャを例外に対応させる。
う〜ん、いまいち。大幅に作りなおす必要があるなぁ・・・。

で、今日はおしまいにする。23時を回っている。

　帰りに天下一品でラーメン。
家に帰って、「Mr.Driller」をしばらくする。
チャットしながら日記を書こうと思ったが、
眠くて中断して寝た。
　明日も会社に行かないとなぁ・・・