データベースエンジニアやってます。

キャリア | スキル

» 2016/02/02

常駐先で、小さいものはメガ単位、大きいものは数十テラ単位のデータベースを管理しています。
コラムでは、主にデータベースに関する知識や経験をお伝えできればと思います。
まずは、データベースエンジニアがどういったものか、私の場合について説明します。

■まず、データベースってなに？
ITの仕事をしてる人以外と話すときに、よく聞かれます。
そんな時は一言で、説明をしています。
「宝の山です。」
個人情報や企業のデータがお金になる世の中です。
流出したり、破損したら損害賠償ものです。
そういう意味から、宝だなあと思っています。
その宝を守るのがデータベースエンジニアです。

■プログラマから、データベースエンジニアに
軽く自己紹介をします。
2000年問題の年に、大学を卒業して、ITの仕事を初めてから、もう15年くらい経ちました。
月日が流れるのは早いものです。
最初の7年間は、プログラマをしていました。
PowerBuilderという、余りメジャーでない言語をやってました。
その頃のデータベースとの関わるのは、SQLを通してデータを引っ張ってくる時だけでした。
次の8年間は、データベースエンジニアとして、主にORACLEデータベースを設計したり、管理しています。
現在も引き続き、データベースエンジニアをしています。

■データベースエンジニアの一日
・障害がない日
　9:00             出社
　9:00-9:30     ミーティング
　9:30-12:00   メール読み書き、開発データベースメンテナンス作業、業務チームのSQLレビューに参加
　12:00-13:00 お昼休み
　13:00-17:30 メール読み書き、データベース設計、サポート問い合わせ
　
何もなければ、17:30に帰れます。
良い職場、良い仕事だと思います。何もなければ。

・障害が発生した日
  3:00            電話が鳴りだす。

　3:01            電話に出る。
　                   プロジェクトマネージャから「本番環境のデータベースが止まったみたいです。」との連絡を受ける。

　3:10-3:30    タクシーで現場に向かう。
　3:30-3:40    保守端末から、本番データベースに接続し、本当にデータベースが死んでいるか確認する。
　3:40-3:50    データベースは死んでいないが、メモリがいっぱいで、死んでるのと同じだと分かる。
　                  プロジェクトマネージャに、データベースの停止をしてから復旧してよいか判断をあおる。
　3:50-4:30    復旧作業。
　4:30-5:00    障害原因調査、サポート問い合わせ。
　5:00-6:00    お客様のところに謝りに行く。
　6:00-23:00  サポートとのやり取りや、サポートに問い合わせるための情報収集、報告書作成、再発防止策検討。

何かあると、その程度にもよりますが、普段のまったりモードから、阿修羅モードに変わります。

■データベースは死ぬ
データベースが動かない、死んだという状況は、システム停止と同じことです。
データにアクセスできないのだから当然です。
データベースを死なせないために、設計・構築の時点から、パラメータ設定や、ディスク、メモリ容量などに気を使います。
上席者、有識者のレビューもしっかり受けます。
もちろん構築後のテストもしっかり行います。
それでも、データベースは死ぬときは死にます。
原因としては、やっぱり実運用してみて初めて発生することが原因だったり、データベースソフトウエア自体の潜在的なバグ
だったり。
あとは、ディスクの経年劣化によるデータ破損とか。
全ての結果には原因があるはずです。
ただ、データベースが落ちた後、その原因を調査するのは骨の折れる作業です。
データベースが落ちた時に出力されるログは、大概落ちた瞬間を捉えたものばかりだからです。
落ちるぞー、落ちるぞーの兆候がログから分かるときもありますが、分からないことのほうが多い。
結局、再現待ちとなることが多いです。
そんな悠長なことを言ってる時間はないので、開発環境で、どういう場合に再現するか試したり、日替わりで本番データベースの
健康状態を監視する日々が始まります、、、

■データベースあるある
ORACLEデータベースに関しては、以下のような起こってはいけないことが度々起こります。
　・大量データ処理で、アーカイブログいっぱいになって、データベース停止。
　・大量データのDELETEで、UNDO表領域がいっぱいになって、処理がロールバック。
　・データ件数が多いテーブル同士を結合して、一時表領域いっぱいになって、処理失敗。
　・ある日性能が突然悪くなる。次の日良くなる。次の日悪くなる。以下、繰り返し。
　・実は、日時バックアップがexpコマンドで取得したダンプだった。
　・接続数が予想より多すぎて、サーバのメモリが足りず新規接続が出来なくなる。
　・本番と開発環境を間違えて、本番環境をシャットダウン。
　・さんざん調査した挙句、ORACLEのバグだった。
　・バージョンアップする度に、機能が自動化されていき、ブラックボックスが増える。

その時どうした、どうなったといった詳細については、おいおいコラムにしていきたいと思います。

■データベースエンジニアに課せられた使命
不死身のデータベースを作ることです。

■データベースは私の師匠
データベースは奥が深いです。
また、データベースは覚えなきゃいけない範囲も広いなあと思います。
と言うのも、データベースにはネットワークもOSもアプリケーションも色々と密接に絡んでくるからです。
応答が遅くなった原因は、効率の悪いSQLでは無く、ネットワーク遅延だったとか。
データベースに関するプロセスのメモリがリークしてサーバメモリを圧迫するとか。
CPU高負荷が原因で、データベースエラーが発生とか。
データベースのエラーから調査を進めていくと、データベース以外が原因だったということがあります。
データベースが我儘言うときほど、学ぶことが多いです。
色んなことを学ばせてくれる師匠のような存在です。

■データベースエンジニアは
何か起きると、まっさきに疑われる確率が高いのがデータベースです。
万が一死んだ時は、地獄が待っています。
でも、自分の設計で思い通り動いたときは、愛おしいものです。
障害が起きないことが1,2カ月と続き、それが当たり前となることもあります。
データベースエンジニアとしては退屈ですが、それが皆にとって、一番いいことなのです。