常駐先で、ORACLEデータベースの管理やってます。ORACLE Platinum10g、データベーススペシャリスト保有してます。データベースの話をメインにしたいです

【小説 エンジニアの事故記録】第四十二話 彼女のために

»

 渚沙と付き合うことになった。
 その事実は幸一郎を俄然やる気にさせた。
 将来のことに思いを馳せた。
 あの夜、行けなかった虹の端公園に行って......
 それから......

(なんとしても、この試練を乗り越えて見せる)

 目の前で俯いたままの彼女をチラ見した。
 小山の言葉に従った渚沙は、幸一郎と付き合うことになり落ち込んでいるようにも見える。

(付き合ってみれば僕の良さがわかるさ)

 ドーパミンでまくりの覚醒した頭で考えた。

---------------------------------------------------------------------
「また小山君と私と君の三人で仕事が出来るよ」
---------------------------------------------------------------------

 渚沙がさっきそう言ったのを思い出した。
 その言葉で、トップギアに入った幸一郎は閃いた。 

「確か......このデータベースは三台で構成されたRACだよな」

 自分に言い聞かせるようにそう呟いた。

(三台......三人......協力すれば速い......)

「分かったぞ!」

 小山と渚沙が幸一郎の方に振り向いた。
 幸一郎は二人に向かって自分の考えを説明した。

「データベースサーバ三台を同時に使って、データをインポートすれば1/3の時間で済むはず」

 実績としては10GByteのデータをインポートするのに30分掛かっている。
 30GByteのデータを入れるのには単純計算で1時間半掛かることになる。

「それは、データベースサーバ一台でインポート処理をしてるからなんだ」

 幸一郎は頭の中で以下のような図を描きながら二人に説明した。

■データベースサーバ一台でインポート処理した場合

imp1台.png

「だが、データベースサーバ三台で同時にインポート処理すれば30分で完了出来る」

 サーバ一台につき10GByteずつ同時にインポートするようにコマンドを作る。
 そのコマンドを各サーバで同時に実行すれば、1/3の時間で済む。
 幸い、NASにあるダンプファイルは三台のデータベースサーバからそれぞれ参照することが出来る。
 三台協力して行えばリソースをフル活用できるうえに時間の短縮にもなるという訳だ。

 幸一郎は頭の中で以下のような図を描きながら二人に説明した。

■データベースサーバ三台でインポート処理した場合

imp3台.png

「10GByteをどうやって均等に割り当てるんだ?」
「石川さんが毎朝データベースから自動取得しているUSER_SEGMENTSの情報があるんだ。そこにテーブルごとのデータ量が載っている」

 幸一郎はその情報を元に、300個ある業務テーブルを三つのグループに分別した。
 テーブルのデータ量を元に、各グループが10GByteずつになるように割り当てるテーブルを調整した。
 だいたい一グループあたり100テーブル前後割当たった。
 そして、出来上がった三つのグループをimpdp文に割り当てた。

 ■データベースサーバ一号機で実行
 「impdp adm/adm directory=DUMPDIR dumpfile=ORACLE_DATA.dmp logfile=ORACLE_DATA_imp_grp1.log content=data_only tables=<1グループ目のテーブル> status=60」

 ■データベースサーバ二号機で実行
 「impdp adm/adm directory=DUMPDIR dumpfile=ORACLE_DATA.dmp logfile=ORACLE_DATA_imp_grp2.log content=data_only tables=<2グループ目のテーブル> status=60」

 ■データベースサーバ三号機で実行
 「impdp adm/adm directory=DUMPDIR dumpfile=ORACLE_DATA.dmp logfile=ORACLE_DATA_imp_grp3.log content=data_only tables=<3グループ目のテーブル> status=60」


---------------------------------------------------------------------

 月曜日、23時10分。

「この三つを並列に流す」

 幸一郎はそう言うとTeraTermを三つ起動し、データベースサーバ一号機から三号機まで接続した。
 そして、それぞれのTeraTermで三つのimpdp文を実行した。
 小山はコマンドが流れ出したことを確認すると、こう言った。

「予想だと、終わるのは30分後の23時40分。予定より10分遅れるな。その分、業務確認の時間が10分足りなくなる。どうするかな......」

 腕を組んで考えている。
 インポートは23時30分に完了する予定だった。
 その後の業務動作確認を24時までに完了することを、お客と約束している。
 つまり今日中に復旧完了させなければならない。
 小山はしばらく沈黙していたが、何か閃いたかのように目を見開いた。

「インポートが完了したテーブルを報告して行ってくれ」
「分かった」

 幸一郎は小山が何をしようとしているか分からなかったが、この際、理由を聴く時間すらもったいないと思った。
 ログからインポートが完了したテーブルの名前を挙げていった。

「よし、在庫確認画面の動作確認が出来るな」

 そう言うと『魔の端末』から本番システムにログインし在庫確認画面まで移動した。

「この端末もこんな時は役に立つんだよな。吉田課長、一緒にチェックしましょう」

 小山は吉田課長をダブルチェックの相手に選び、在庫確認画面の動作確認を始めた。
 課長は大人しくチェックリストにチェックを入れている。
 あれほど工数が掛かると嫌っていた小山のやり方に従っている。
 動作確認が終わったらしく、幸一郎の元に戻って来た。

「どんどんインポート出来てる?」
「ああ。えっと......」

 幸一郎が読み上げたテーブルを聴き終えると、

「次は売上履歴画面だな」

 そう言うと、また『魔の端末』に戻っていった。
 どうやら彼はインポートが終わったテーブルがどの業務機能と紐づいているか完璧に把握しているらしい。
 復旧が完璧に終わらずとも、こうやってインポート作業と並列で動作確認することで業務確認時間の短縮を試みているようだ。

(すげえぜ......)

 小山を尊敬の眼差しで見ている自分に、幸一郎はしばらく気付かなかった。
 他のメンバーも彼の働きぶりに感嘆している。

「さすが、だ」

 普段は文句ばかり言う富永も、小山に対しては褒め言葉しか思い浮かばないようだ。

「小山君......」

 渚沙は頬を紅くして、じっと彼を見ている。
 幸一郎はそんな彼女に対して「付き合ってる僕の方を見てくれ」と言いたくなった。

「次は?」
「い、いや......」
「どうした?」
「インポートが、と、止まってる」
「インポートが止まってる?」

 幸一郎の言葉を小山は復唱した。

「ログを見てるんだけど、さっきから進んでないんだ」

 ログにはインポートが完了したテーブルの名前とレコード数が表示される。
 コマンド実行当初は順調にデータがデータベースに投入されていた。
 それを裏付けるかのように、ログには次々テーブル名が表示されていた。
 だが、今は行き止まりにでも突き当たったかのようにピタリとログの出力が止まっている。
 それは、データベースサーバ一号機だけじゃない。
 二号機も三号機も止まっている。
 すわなち、それは、三台のデータベースサーバ全てのインポート処理が止まっていることを意味していた。
 残すテーブルは各サーバごとに5個ある。

「あとちょっとなのに......」

 小山は顎に手を当てて考え込んだ。

「もしかして......」

 幸一郎はsqlplusでデータベースにアクセスし、データが格納されるGYOMU_DATA表領域の空き容量を確認した。

「表領域の容量にはまだ余裕がありそうだな」

 表領域がの空き容量が足りずにデータがインポート出来ない訳では無いらしい。
 23時40分過ぎた。
 この時間までにインポートが終わる予定だった。
 業務動作確認を24時までには全てを終わらせなければならない。
 周りのメンバーが幸一郎を取り囲むようにして集まって来た。

「大竹君」
「大竹さん」

 ディスプレイを前に眉間にしわを寄せ考え込む幸一郎の背中を押すように、みんなが彼の名を呼んだ。

(そうだ。みんなの力を借りてここまで来れた。何としてもこれを終わらせるんだ)

「あと少し。ここまでやれたんだから、何とかなるよ」

 渚沙が横でそう言ってくれた。

(渚沙......)

 幸一郎は自分の彼女の顔を横目で見た。
 まっすぐ伸びた黒い長い髪、長いまつ毛の下に大きな黒い瞳が浮かんでいる。
 そんな彼女を一瞬でも見た幸一郎は、決心した。

(彼女のためにも)

 それは、もちろん自分のためでもあったが。

「大竹、お前が主役なんだ」

 小山が幸一郎の肩に手を乗せてそう言った。

「データベースの王になれ」
「小山......」

 幸一郎はデータベースの動きを頭の中でシミュレーションした。

(考えろ......これがきっと最後なんだ)

 幸一郎はこれほど仕事に対して真剣に臨んだことは無かった。
 常に目の前の仕事は自分の本当にやりたいこととは違うと思いながら仕事をしていた。
 それは幸一郎から真剣さというものを奪って行った。
 こんな態度では自分のやりたいことなんて見つからない。
 真にやりたいことは、苦難の中から自分で見つけ出すものだということに気付いた。

(これが僕のやりたいことか!)

 そう悟った。

 この短時間でデータベースの挙動を脳みその皴に染み渡る程に、考え抜いた。

(インポートのプロセスが死んでいるという事か?)

 psコマンドでインポートの処理を行っているimpdpプロセスを確認した。
 しかし、プロセスは存在した。

(プロセスが生きているということは処理自体は死んでいない......となると何かが原因で止まっているだけ。インポートは内部的にデータベースに対してinsertでデータ処理を行っているようなものだ。データ処理を行えばundo表領域やアーカイブを出力するはず)

 データベースにアクセスし、undo表領域の使用率を確認した。
 まだ空き容量に余裕がある。
 次にアーカイブログの出力先であるNASにcdコマンドで移動した。

「cd /NAS/oracle/archive」

 石川からは、ここにデータベースサーバ三台分のアーカイブログが出力されると聞いている。
 lsコマンドでどれくらいアーカイブログが出力されているか確認した。

「おおぉ!」

 幸一郎がインポート処理を行っている時間帯に500MByteのアーカイブログが100ファイル出力されていた。
 合計で50GByte出力したことになる。
 dfコマンドを実行し、アーカイブログの出力先であるディスクの使用率を確認した。

「100%か」

 横で見ていた小山がそう呟いた。
 アーカイブログの出力先であるディスクは100GByte確保してある。
 今回のインポート処理を行う前から50GByteのアーカイブログが存在した。
 だが、インポート処理を行うことにより50GByteが新たに出力されて容量をパンクさせたのだ。
 幸一郎はその裏付けを取るためにalertログをtailコマンドで開いた。
 アーカイブログが出力出来ない旨のエラーメッセージが出力されている。

「出力先が一杯でアーカイブログが吐けずに、インポート処理が止まってたってことか!」

 幸一郎はやっと停止した原因を掴んだ。
 時間は23時50分。
 あと10分しかない。

「空きを作るしかないな」

 小山がそう言ったのを聴いた幸一郎は、出力されたアーカイブのリストを見てこう言った。

「消そう」

 それを聴いた吉田課長は驚いた様子でこう言った。

「大丈夫なのか? 消したら直前の状態まで戻せないんだろう?」

 リストアしたデータベースを障害直前の状態まで戻すにはアーカイブログでリカバリする必要がある。
 そのアーカイブログが無くなるということはリカバリが出来なくなるということだ。

「このインポートを終わらせるのが優先です。それに日次バックアップが使い物にならない今、ここにあるアーカイブログは不要です」

 幸一郎はそう言うとrmコマンドでアーカイブログをすべて削除した。
 その瞬間、インポート文は一気に流れ出した。

「動作確認の続きを!」

 小山がインポートの完了を確認すると、最後に残った業務画面の確認を吉田課長に依頼した。

つづく

Comment(2)

コメント

VBA使い

40話で、CPUがフル稼働で、ディスクには待ちがない、というので救われましたね。
もしNASのI/Oがボトルネックだったらどうすんだろ?
それとも、論理バックアップからのインポートはCPUに負荷がかかるのかな?

湯二

VBA使いさん、いつもコメントありがとうございます。
考察もありがとうございます。

パラレルのインポートは、作業時間を短くしてほしい移行作業などで、実際の業務で何度かやったことあります。

お話では、
ダンプファイル一個に対して三台同時に参照に行くわけです。
そのダンプファイルを格納しているNASにI/Oが集中することになります。
となると、NASのI/O性能次第でお話の内容が変わってしまうわけです。
性能が悪ければバッドエンドです。
幸い性能的には三パラレルでアクセスされても問題ないNASだったので、真のエンディングに向うことが出来ました。
という、後付けです。

>論理バックアップからのインポートはCPUに負荷がかかるのかな?

論理でも物理でも、I/O待ちが少なければCPUが仕事してくれる分、負荷は高く見えるかもしれません。

コメントを投稿する