DBのバックアップ容量が想定以上に増えているケースは珍しくない。その原因の1つは、DB管理者とインフラ担当者との間にある“ギャップ”だ。この問題を解消し、バックアップ容量を劇的に削減する手法を紹介したい。
日々発生する膨大なデータを、いかにして安全かつ効率的にバックアップするか――。これは、データベース(DB)の運用において忘れてはならない重要なテーマだといえる。しかし、システム運用の現場では、うまく業務が回っていないケースが決して少なくない。その原因の1つが、DB管理者とITインフラ担当者の間に存在する“ギャップ”である。
システム運用の現場は、DBとインフラで管理者が分かれている場合が一般的だ。DB管理者はDBの設計やチューニングに注力し、バックアップはITインフラ担当者に依頼するというのが通常の役割分担だといえる。しかしこのような運用では、バックアップ対象の変更やデータリストア時の対応に時間を要し、それがDB管理者のフラストレーションにつながってしまう。その結果、DB管理者は自分自身の業務効率化や機会損失防止のため、ITインフラ担当者が行うバックアップとは別に、独自のバックアップ運用を行うようになる。これがバックアップ運用の効率を著しく悪化させる可能性があるのだ。
例えば、Oracle Database上にある100GバイトのDBを、DB管理者がRMANコマンドで、2世代分独自にバックアップしているケースを考えてみよう。
DB用のボリュームには、元DBと2世代分のバックアップ、合計300Gバイトのデータが存在する。ITインフラ担当者は、プライマリストレージの中でこのボリュームのクローンを作成し、ここからバックアップを作成する。わずか100GバイトのDBをバックアップするために、合計800Gバイトものストレージが費やされることが分かる。これは大きな無駄だといえるだろう。
DB管理者とITインフラ担当者の間の“ギャップ”を解消し、このような無駄を排除するにはどうしたらいいのか。本稿では最新技術を活用することで、この問題を解決する方法を紹介する。
Copyright © ITmedia, Inc. All Rights Reserved.
提供:ノックス株式会社
アイティメディア営業企画/制作:TechTargetジャパン編集部