データベースの「例外」について考える

情シスをいきなり襲う「例外」というエラー

皆さんの会社にも「会計システム」、「生産管理システム」、「在庫管理システム」などなどいろんな「なんとかシステム」が仕事の中心にあると思います。

そんな普段使いのシステムで「例外が発生しました」と表示されて、処理が止まる。
「ファ!?」ってなりますよね。そして、情シスの皆さんも慣れていないと「ファ!?」ってなります。

業務で使用する「なんとかシステム」と呼ばれる類には「データベース」が使用されています。
最近ではビッグデータの流行りもありNoSQL系のデータベースがもてはやされていますが
やっぱりローカルの会社ではまだまだリレーションDBが主流です。

パッケージで売っている「なんとか大臣」や「なんとか奉行」をそのまま使用している、という場合は今回のエラーはそんなにお目にかかることは無いと思いますが、
「基幹業務パッケージ」なんて物が世に出る前から作り込みでシステム構築している場合はこの「例外」さんはよくお目にかかることになると思います。

だいたいこんな感じで情シスに文句が来るのではないでしょうか

• 昨日まで出力できていた帳票が今日印刷しようと思ったらエラーで出なくなった！
• （月次締めとかデータ更新とか）処理をしたら帳票が出なくなった！
• 初めて発生するパターンの帳票を入力したが、入力後からエラーになった！

で、「システムで何かやったんじゃないのか!?」というお約束の接尾語が付いてくる、という感じです。

もし、情シス側で修正作業やDBバージョンアップなどを行っていて翌日からそんな現象が発生した、というのであれば実施した修正作業を疑うことになりますが、特に何も作業していないのに現象が発生するのであれば、9割方は入力されたデータに問題があります。

「例外」が出たらデータを疑え

エラーであれ、例外であれ、エラーはエラーです。
但し、「例外」と出た場合は重篤なエラーでは無いです。ハード的には問題が無いですが、ソースコードに書いてある通りに進んだら変なとこにぶち当たった、というイメージです。
データベース上でよくある「例外」はこんなあたりでよく引っ掛かります。

この辺りをヒントに何が起こっているのか紐解きます。

よく「ソースコードに間違いがあるのでは？」とか「ロジックにバグがあるんじゃないの？」とか言われちゃうこともありますが、

• クレームが来るまでは問題無く動いていた
• 他の業務では問題なく動いている

と考えれば、いきなりコードが改ざんされるなんてことは考えられません。基本クローズドなシステムにいたずらソースコードを仕込める人なんて雇ってるベンダーか情シスのあなた以外にいませんし、正直そんなハッキング誰得？という話です。

きっかけとなった集計処理では「データを集める」→「合計なり平均なり」→「並べ替えて帳票テンプレに当て込む」という流れがほとんどかと思います。
この工程の中で引っかかりそうなデータはないか、を見極めていくことになります。その上でソースコードに誤りがあるなら直すまでですが、いきなりソースコードを睨むよりデータを見た方が解決時間は早くなると思います。

ここから先は推理タイムです

エラーに絡みそうなテーブルを眺めて、他と明らかに違う内容が入っているデータが無いか眺めてみましょう。
ウチではデータベースにOracleとSQLを使用しているので、"SQL Developer"でデータベースの中身を見ています。

仮にデータベースの中身を見ることについて、あまり経験がなく自信が無くても、勉強だと思って眺めることはしてみましょう。問題の切り分けくらいはできます。

もし、やっぱり恐い、データベースを見ることができない、見ることができるのはベンダーさんだけという場合は、帳票の出力範囲指定などを組み合わせて使って、どの状態の帳票が出ないのかを調べます。

などいろんなパターンを試して出るパターンと出ないパターンを切り分けます。
そこまで切り分けてからベンダーさんにパスする。これだけでもベンダーさんは丸投げされるよりだいぶ助かります。

【エラー事例】今まで「例外」エラーの原因となったこと。

ちなみに、ウチでは今までこんな原因で例外が発生していました。近い症状があれば参考にしてみてください。

集計の手順をオペレータがすっ飛ばした

集計の手順をオペレータがすっ飛ばしたことで、本来データが入るところに入らないまま次のステップに進んだ。その後の処理内の割り算で"Null"を割り算したので"0で割ってますよ"と怒られた、というエラーです。

どの業務でも、「〇×処理」をやってから「〇×集計」をやる、というボタンを押す手順が決まっているパターンがあると思います。
普段なら問題なく手順通り行われるのに、

等の理由でイレギュラーな動きになる。よくあることです。
特に作り込み系システムでは手戻りの想定が甘い事がよくあります。
また、手作りシステムだからという理由で
「今回だけだからなんとかして！」とか
「システムだろ！なんとかしろよ！」
なんてことも横行しがちです。

簡単に手戻りできる状態のシステムをコンプライアンス的にどう見るかは後に語ることとして、現状を回すのであれば手順違いで入らなかったデータ、違う出力になってしまったデータを直すなり消すなりで解決することでしょう。

伝票入力時にもう使用していない項目にデータ入力した。

項目の送信先テーブルではその項目の列は廃止されているので「そんな列ありませんよ」で例外エラーというパターン。
昔から使用してきて、修正を積み重ねてきたシステムでは考えられます。仕事の内容が変わり、お役御免となる入力項目。けど、

「使わなくなったメニューを消すだけでもお金かかるし。入力しなきゃいいだけだから放置しておいてもいいよね！」

という当時のケチ根性が後のエラーを引き起こす好例です。
このようなエラーが起きてから
「なんで不必要なメニューを削除しなかったんだ！？」
と今はいない元担当の替わりに怒られる、なんてことはよくある話です。

この場合は、余計なデータは他の正常データを見習って処理します。

• Nullにしておく
• Delフラグを立てる
• 当たり障りのない文字を入れておいてごまかす

Delフラグや回避文字は0だったり1だったり半角スペースだったり。開発者によって様々です。臨機応変で。
正常データの真似をすればエラー回避できるのではないでしょうか。

もちろん、どんな処置をしたのかは後々の根本解決の為にもメモは残しておきましょう。

「金額は千円単位で入力」と言うところに円単位で入力

しかもそんなときに限ってすっごい高額だったので集計時に合計が桁あふれ。
入力項目の桁数としてはMaxギリギリで入力できるから入力画面ではパスされるが、集計したら、集計先のテーブルで有効桁数を越してしまったというパターン。
入力担当者が人事異動で変わったばかりで細かい申し送りまでされてない、なんてタイミングでよく発生します。
正しい金額に直してあげれば直りますが、もしシステム上、現場で直せる段階にいるならば現場に修正させることをお勧めします。
極力データベースから直接直すことは避け、動いているシステムのメニューで直しましょう。

伝票修正で誤入力

ウチで実際あったのは、伝票修正時に日付を変更したが西暦8桁入力（例"20210401"）を西暦6桁で入力した(例"210401")ので変換されて"00210401"となって西暦21年に購入することになってエラーというパターン。
普通であれば、こんな入力は「入力に誤りがあります」みたいなエラーで訂正を求めるロジックが入っているのですが、今回のパターンは、経理サイドがたまに使用する「データメンテナンス画面」でのこと。強い権限を持った人でないとメニューすら表示されない、いろいろメンテできる画面なので、入力ミスをエラーで止める仕組み作りが甘い設計になっていて、エラーを出さずに登録されてしまった、という流れでした。

というのがほぼ定石です。

入ってきた原因がソースコードのエラー、という事はあると思いますが、まずはデータを正しい状態に直す。
再発防止策としてソースコードを修正する。
特に月次締めの締め切りに追われる切羽詰まった状態の時は、データに注目して応急処置策を第一に探してみましょう。