いろいろやってみるにっき

てきとーに生きている奴の日記

https化に伴い、表示できなくなっているリンクについて修復中。
2018年から遡って修正し、2015年分まで修正完了。


主キーしかないシステムのおもひで

名推理が出た。

 

まとめにはそもそもの発端が無い。

togetter.com

 

最初はマイナンバーカードへの懸念だったはず。

 

暴走のきっかけはコレのはず。

で、発端のリプがこれ。

で、リプライに対する引用リツイートがこれ。

そしてこうつながる。失敬だな。

まだ続く。この罵倒意味がわからない。上のリプライからこう来るつながりがわからん。罵倒できるポイントが無いのに罵倒するとか狂人じゃん。

まだ続く。「落とす」か?公開鍵。なんか勘違いしてねえか?

 

まあ普通はこうなる。

 

 

主キーをマイナンバーシステム全部を開くことができる魔法の鍵だと思った理由はコレじゃないかと。

 

これでマイナンバーカードの話していたのに、いつの間にかマイナンバーのRDBの話(単一のそんなものはシステムを分散させているので存在しない)をしている変な人について、一定の解が出た。。

公開鍵、秘密鍵の話振られても券面にマイナンバー書いてあるじゃないか脆弱性ガーになるわけが。普通は公開鍵、秘密鍵の話振られたら、暗号化方式とか鍵長とかICチップの耐タンパ性とかそういう話をするんだが。某システムでDES使う時に、古い雑誌に載ってたDESのソースコード使った話する?

 

あと、マイナンバーに関連するシステムにメインフレームが入っていたら構造型DB(IBMのIMSとか)を使っているかもしれないってことは想像もしてないだろうな。流石に業務やデータの特性的にKey Value(NoSQLとか)やドキュメント型DB(MongoDBとか)は使ってないと思うけど。

 

ここからが本題。昔話をする。本題までが長すぎる。

ある日、親会社の課長に呼ばれて水道橋のある古い雑居ビルに行くことになった。下記のプロジェクトから逃亡したあと、

shigeo-t.hatenablog.com

千葉ニュータウンに飛ばされて通勤片道3時間で死にそうなので3か月で逃亡したあとの話。

 

課長曰く「1帳票出すのに23分掛かる。いくらなんでも遅すぎる。なんとかしてくれ。」「あと、アプリの改造は無しな。」

 

アプリの製造はウチのアプリ開発部門、SEはウチなんだけど実質ウチの子会社が担当というプロジェクトだった。当然データベース担当も子会社の奴。ただ、そいつはデータベースの専門家を名乗っていて、オレより3~5歳位若い奴だった。しかも、もう他のサイトに行ってる。

 

使われているのはOracle 7か8、多分7だったと思う。そして、サーバはWindows NT4.0サーバ。

 

その頃UNIXマシンばかり触ってたので、うっわ、これがNTかよって思ったけど、遅いのはOSやWindows NT用サーバ機が原因ではなかった。サーバOSとして考えたら操作性は最悪だったけど。

 

タイトル通り、主キーしか無かったw。データベースの専門家は何の専門家だったんだろう。帳票作成もとんでもなく遅かったけど、オンラインアプリも遅いってことが分かり、全体的にチューニングすることにした。

 

一旦脱線するけど、このお客さん夕方5時過ぎるとほぼ毎日職場の流しで魚を焼き始め酒盛りする楽しい職場だった。水道橋でドーム近くなのに。オレらも誘われたけど、毎日応じるわけにも行かず腹減らしながら残業してた。魚焼くっていっても乾物じゃなく生サンマとか生イカとか生サバである。まあたまには干物も焼いてたけど。

 

話を戻す。オレはこういう経験している程度にはOracle知ってた。

shigeo-t.hatenablog.com

最初に見たのはOracleに割り振っているメモリ。デフォルト値だったw。サーバの搭載メモリに合わせてギリギリまでアップ。

次はデータの物理的な配置。これは、ディスクの本数が少ないのであまり分けられないけど、これも物理I/Oが分散するように再配置。国際問題になりそうだった時はUNIXマシンでrawディスク使ってたけど、NTではどうもできなさそう(できたかもしれないけど、今みたいにネットですぐに情報検索できなくて時間切れ)なので、NTFS上に置いたまま。

 

まあ、ここまでは1日でできた。問題はそれでもそんなには改善していない。件の帳票作成が23分から12分ちょっとになった程度である。実務的に遅いという意味では五十歩百歩である。しかも、ちょうど。何か数字を言われたら「ちょうど~?」って聞き返すのが磁石永沢の持ちネタなので是非覚えて帰って頂きたい。使い方としては、

  「日本の人口は1億2千人だよ」

  「ちょうど~?」

です。絶対に丁度じゃない数字を振られた時に使う。

 

次にインデックスの作成状況を見た。無い。ほとんど無い。つまりタイトル通りである。クソ遅い理由がよく分かった。

 

「アプリの改造は無しな。」という条件付きなので、どういうSQLを出しているのかCOBOLだったかCだったかのアプリを見せてもらい、どんなSELECT文かを書き出す。それでSELECTのWHERE句に合わせてINDEXを作成して性能を見る。またANALYZEして統計情報を集める。

さらにバッチ処理では素でSQL発行している奴もあるので、そこにはヒントも追加する。この「アプリの改造は無しな。」はアプリ部隊に追加作業を出したくない(=追加費用0)っていう意味なので、オレがバッチファイルを直す分にはOK。

 

こうして、オンライン処理も速くなり、件の帳票も1分程度まで短くなった。なお、1分程度の内訳だが3秒がデータベースアクセスで、残りがCrystal Reportsの生成だった。

ja.wikipedia.org

 

Crystal Reports部分のチューニングまで言われなくてよかった。実務上、1分ならまあいいかって感じだったし。Crystal ReportsがSAPに買われたのは知らんかった。

 

結局、件の帳票については22分のDBアクセスを3秒まで短縮できたことになる。

 

この「データベースの専門家」とは、この後も何度も対戦して全部勝ったけど、オレは別にデータベースの専門家ではない。

  • 某総研でデータウェアハウス用のデータベースの選定を行うにあたり、自社の直属じゃない上司に呼ばれて行ってOracleのチューニング。「データベースの専門家」は親会社の誇るDBMSを担当、あと知らない人が(会ってない)Red Brickを担当。Oracleが選定された。
  • 同じく某今は亡き損保会社からオレが受注した案件で、「データベースの専門家」をデータベース担当者として付けられたけど、性能測定したら全然ダメだったので休日に夜間作業して全部作り直した。やったことはメモリチューニングとI/Oの分散。
  • 同じく某今は亡き損保会社からオレが受注した後続案件で、それぞれ別のサブシステムの構築を担当し、オレと部下の人は1日で終わって仙台の牛タン食って翌日残作業片付けて帰ったけど、そいつらは3日経ってもサーバ立ち上がらず。だって、そいつらスクリプト流してはタバコ吸いに行って戻ってきたらエラーで落ちててそれ直してまたタバコみたいな感じで作業。データセンタなので喫煙所遠いw。オレも当時は喫煙者だったけど、面倒だから1回しか行かなかった(場所教えてもらっただけ)。
    オレたちは横浜の開発環境で環境構築したものをDDSに吸い上げて持ち込み、本番環境に落とし込んで開発環境と本番環境の違いだけを修正した。そいつらも同じ手順できるはずだったんだけど、なぜかクリーンインストールで失敗連続を選んでた。

 

みたいな。なんか他にもあった気がするけどまあいいか。

shigeo-t.hatenablog.com

shigeo-t.hatenablog.com