Special
» 2017年06月01日 18時00分 公開

DBA必読! 開発/運用管理がもっと楽になる:12c R2の「現場で役立つ」新機能は? コーソルのエキスパートのお勧めはコレ! (2/4)

[PR/@IT]
PR

「PDBホットクローニング」「異種キャラクタセットPDBの混在」にも対応

椛沢 マルチテナント関連で、ほかに便利な機能強化はありますか?

渡部 村田さんは12c R2のβプログラムに参加していたよね。特に気に入った機能は何かな?

村田 「PDBホットクローニング」はすごい機能ですよ。本番システムに影響を与えずに開発を進めるために、本番環境とは別に開発環境を用意しているケースは多いと思います。ただ、システムがサービスインしてある程度の期間が経過すると、本番環境と開発環境の相違が大きくなり、それが円滑な開発作業の妨げになることがありますね。

椛沢 そうなのですか?

村田 テーブルや索引の定義、テーブルに格納するデータを本番環境と同じ状態に保つのは、とても骨が折れる作業なのよ。その理由は、基本的にデータベース管理者(DBA)が手作業で対応する必要があるからなの。特にテーブルに格納されるデータについては、バッチプログラムなどで自動的に更新されるシステムもあるから、DBAがそれらを把握しておくのはとても大変。でも、PDBホットクローニングを使えば、本番データベースを止めずに、開発用のデータベースを簡単に作れるのよ。

photo

椛沢 新卒研修でデータベースを止めずにバックアップを取得できる機能があることを知って感動したのですが、クローンも作れるようになったのですね。Oracle Databaseはやっぱりすごい!

photo

村田 すごいでしょ〜。しかも、それだけじゃないのよ。PDBホットクローニングでは、「REFRESH」というコマンドを使うと、一度クローニングしたデータベースの同期を繰り返し自動的に行うこともできるの。DBAにとっては本当にありがたい機能だと思うわ。

高村 なるほど〜。ほかにお勧めの新機能はありますか?

渡部 ちょっと地味な機能だけれど、「PDB Character Set」がうれしいユーザーは少なくないんじゃないかな。1つのCDBでシフトJISや日本語EUCといった異なるキャラクタセットのPDBを混在させられるようになったんだ。

photo

高村 へ〜、たくさんのデータベースをマルチテナント機能で統合するのに欠かせない新機能ですね。ところで、どうしてさまざまなキャラクタセットが存在するのでしょうか? 今日の状況を踏まえると、Unicodeに統一しても良さそうに思うのですが……。

渡部 それについては「歴史的な事情」と説明する他ないね。一般的に、一度作ったデータベースはシステムが動いている間はずっと使い続けられるから、どうしても開発当時の事情を引きずってしまうんだよ。それに、データベースはさまざまなアプリケーションからアクセスされるので、後から大幅な変更を加えづらいという理由もある。キャラクタセットを変更する際にはアプリケーションの修正とテストで大変な作業が発生するし、ビジネス上のメリットに直結するケースも少ないので、できれば避けたい作業と判断されてしまうのは仕方がないのかもしれないね。

高村 確かに、そうですね……。でも、12c R2ではデータベースを長期間使い続けていくことを考慮した機能強化も行われていると知って、少し安心しました。

Oracle Data Guardによる大規模データベース同期が、よりスマートに

椛沢 そういえば、最近「Oracle Data Guard」を使うプロジェクトに関わることが多かったのですが、12c R2ではOracle Data Guardに関して何か新しい機能は追加されていますか?

渡部 Oracle Data Guardに関するものとしては、NOLOGGING操作を実行した後にフィジカルスタンバイデータベースをリカバリーする機能が追加されたね。この機能を使うと、大量のデータをロードする際に一般的に使われているNOLOGGING操作で発生する「スタンバイデータベースのブロック破損」を簡単に復旧できるんだ。

photo

椛沢 えっ! Oracle Data Guardで同期している環境でNOLOGGING操作を実行すると、スタンバイデータベースのブロックが破損してしまうのですか?

渡部 そうなんだ。もちろん、これはディスク障害などで発生するブロック破損とは意味合いが違うものなんだけれどね。

 Oracle Data Guardの一般的な使用形態であるフィジカルスタンバイでは、スタンバイデータベースの更新を適用するためにREDOログの転送と適用を行うことは知っているよね。このREDOログの出力を意図的に行わないのがNOLOGGING操作で、主な目的はデータロードの高速化だ。ただし、REDOログを出力しないということは、更新内容をプライマリーデータベースからスタンバイデータベースに伝搬するための情報がなくなることを意味する。そのため、ブロックが破損したままになることがあるんだよ。

椛沢 なるほど、意図的に破損を許容しているのですね。ブロックの破損を直すのは簡単なのですか?

渡部 バックアップからのリストアが必要だから、結構大変な作業になるね。日常的な管理に組み込むには抵抗があるかな……というのがこれまでの話。12c R2ではバックアップからリストアすることなく、コマンド1つでブロック破損を修正できるようになったんだよ。

椛沢 コマンド1つで済むのならば、日常的な管理業務にも組み込めそうですね。でも、そもそもNOLOGGING操作を使わない方法はないのですか?

渡部 大量のデータをロードする際にNOLOGGING操作を使わないと、膨大なREDOログの記録・転送が発生し、スタンバイデータベースへの更新適用が遅延してしまう。トレードオフの側面もあるけれど、一般的にはNOLOGGING操作を行った上で、12c R2で新機能として導入された「RECOVER DATABASE NONLOGGED BLOCK;」を使うほうが良いと思うね。

Copyright© 2017 ITmedia, Inc. All Rights Reserved.


提供:日本オラクル株式会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2017年6月30日

人気記事ランキング

本日月間

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。