SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

直近開催のイベントはこちら!

Data Tech 2022

2022年12月8日(木)10:00~15:50

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ

使えないバックアップとはおさらばしよう

 前回はOracle Database 12c(以下、12c)のオプティマイザ新機能について解説しました。今回は、より細かいリカバリが可能になったバックアップ関連の新機能を紹介します。

そのバックアップ、本当に戻せますか?

 機密情報を扱い、情報システムの中心とも言えるデータベースにとって、バックアップは欠かすことのできない重要な要素です。現在ではWebサービスやソーシャル・ネットワークなど、あらゆる場面で日常的にデータベースが使われる時代になっているため、データ損失によって多額の金銭的損害が発生するだけでなく、企業に対するマイナス・イメージが即座に伝播してしまいます。

 ハードウェアの故障やオペレーション・ミスなどのリスクを抱えるデータベースにとって、バックアップはまさに保険とも言える存在ですが、バックアップさえ取得していれば安心かというと、決してそのようなことはありません。バックアップは戻す(リストアまたはリカバリする※1)ために取得するものなので、「何を」「どこまで」「どうやって」戻すのかというリカバリ要件をきちんと考えておく必要があります。これをやらないと、使えもしないバックアップを日々量産し続けることになってしまいます。

 (※1) Oracle Databaseでは、バックアップしたファイルを再配置することを「リストア」、そのファイルに変更履歴を適用してデータを回復させることを「リカバリ」と呼びます。

 しかし実際には、こうしたリカバリ要件の検討を十分にできないままデータベースを運用しているケースが数多く存在します。以下のグラフは、弊社にて実施したリカバリの課題に関するアンケート結果をまとめたものです。意外なことに「リカバリを試したことがない」という回答が過半数を超えています。一度も障害が発生していなかったり、リカバリを試せる環境がないなど事情は様々ですが、有事の際にリカバリできないリスクを抱えているデータベースは少なくないようです。

弊社調査による、リカバリの課題
▲弊社調査による、リカバリの課題

 具体的な失敗例を見てみましょう。A社のデータベースはアーカイブログ・モードで運用されており、毎日夜間バッチの前にRecovery Manager(以下、RMAN)による全体バックアップ(物理バックアップ)を取得しています。これまで一度も障害が発生していませんでしたが、ある日オペレーション・ミスにより誤って当日分と翌日分の夜間バッチが続けて実行されてしまいました。事前に作成しておいた翌日分のジョブを、流し忘れと勘違いして実行してしまったのです。これにより、いくつかの表が本来ではありえない状態に更新されてしまいました。

 事態に気づいた担当者はすぐにジョブをキャンセルし、データベースのサポートに電話します。誤って更新された表だけを元に戻す方法がないか問い合わせましたが、サポートからは表領域のリストア・リカバリを案内されました。幸い手順書があったので問題なくコマンドを実行できたものの、表領域のサイズが大きすぎてリストアに時間がかかってしまい、翌朝の営業開始に間に合いませんでした。

バックアップの失敗例 (image03.png)
▲バックアップの失敗例

 A社のバックアップには2つの問題点があります。1つはリストアに必要な時間を把握できていなかったことです。せっかくバックアップを取得していても、決められた時間内にリストアできないのでは全く意味がありません。特にデータベースのサイズが大きい場合は、それに比例してリストア時間が長くならないような手法を検討するべきです。

 もう1つは、リストア・リカバリの単位が大きすぎることです。データベース全体が壊れてしまうような障害ならまだしも、オペレーション・ミスによっていくつかの表を更新しただけで大規模なリストアが必要になるようでは、効率が良いとは言えません。

 後者の解決策としては、Data Pumpによる論理バックアップや、フラッシュバック機能の利用などがあります。もしこれらを利用できれば、今回のようなオペレーション・ミスが発生したとしても短時間で対処することができます。ただし、RMANの物理バックアップが不要になるわけではないので、結果的にバックアップを2重で持ってしまうという欠点もあります。実際の運用でも、物理バックアップと論理バックアップを併用しているケースは珍しくありませんが、バックアップの時間が延びたり、バックアップ先の容量が不足したりといった新たな問題を抱えることになります。

次のページ
バックアップのムリ、ムダをなくす

この記事は参考になりましたか?

  • Facebook
  • Twitter
  • Pocket
  • note
移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ連載記事一覧

もっと読む

この記事の著者

関 俊洋(セキ トシヒロ)

株式会社アシスト データベース技術本部 データベース・エバンジェリストデータベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やソリューションの立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆や講演活動を行っている。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/5889 2014/06/13 00:00

Job Board

PR

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

2022年12月8日(木)10:00~15:50

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング