[DB Interview]
Oracle 10gへの移行を決断すべきか?(中編)
@IT編集局
上島 康夫
2005/2/8
Oracle 10g R1が日本市場に投入されてから1年弱。2005年夏にはR2(リリース2)も登場する。「エンタープライズ・グリッド・コンピューティング」を標ぼうした新製品は、ユーザーにどう受け入れられたのか。R2では何が変わるのか。現時点でのOracle 10gを取り巻く最新状況を3回にわたってレポートする。
2005年夏にリリース予定のOracle 10g R2(以下、R2)で強化・拡張される主な機能を取り上げよう。以下は、日本オラクル マーケティング本部 システム製品マーケティンググループのディレクター 杉崎 正之氏、担当マネージャ 根岸 徳彰氏に行ったインタビューの内容を編集局でまとめたものである。
■R2はOracle 10gの完成形
杉崎氏によれば、R2は基本的にOracle 10gの完成形あるいは最終形という位置付けになるという。つまり、次期バージョン(Oracle 11gなど)までは、このR2をメンテナンスしていくのみで、R3をリリースする予定はない。R2によってオラクルが主張してきたエンタープライズ・グリッドのアーキテクチャが完成するという主張だ。
R2では製品機能の全般にわたって性能強化、拡張が行われている。R1に盛り込んだ可用性、パフォーマンス、運用管理の容易さなどの新機能や機能強化をさらに前進させることがR2の主眼だという。その中でも注目すべき機能を4点に絞って紹介する。
Oracle Data Guard - Fault Tolerant Standby
R2での機能強化として、ユーザーから最も要望が強かったものがOracle Data Guardだったという。R1でのOracle Data Guardは、アクティブ/スタンバイのHA(ハイアベイラビリティ:高可用性)構成時に、アクティブ側の変更ログをスタンバイ側に同期転送できる。同期ログ転送ができない他社のデータベース製品では、変更ログをためておいて、例えば1分に1回などでスタンバイ側に転送するが、ログをためている途中で障害が発生すると、最新の情報はスタンバイ側に反映されない。
図 Oracle Data Guard - Fault Tolerant Standby R1で実現されていた同期ログ転送に加え、R2ではストレージやネットワークなどの障害時に自動フェイルオーバーされる機能が追加される。RACと併用することで可用性がさらに高まるだろう。 |
Oracleはスタンバイ側に同期ログ転送できるのでより障害に強いアーキテクチャなのだが、R1までは障害発生時のフェイルオーバーは手動で操作する必要があった。R2では自動フェイルオーバーを可能にする機能拡張を行う。例えば、ストレージ系で障害が発生したり、RAC(Real Application Clusters)で運用しているすべてのサーバ・インスタンスで障害が発生した場合でも、自動的に「アクティブ」から「スタンバイ」へフェイルオーバーされ、そのまま運用を続けられる。また、障害を起こしたアクティブ側のデータベースは、リカバリ終了後に自動的に再構成される。障害発生時の運用管理コストを大幅に軽減させる機能強化だ。
ASM(Automatic Storage Management - Release 2)
ASMはデータベース本体に組み込まれたストレージ管理ツールで、クラスタ内の各ノードに分断されたストレージを1つの巨大なプールとして扱えるようにし、さらにストレージのパフォーマンス・チューニングも自動化する管理ツールである。これによって、データベース管理者が行うディスクの再配置といった作業は、一切必要なくなる。R1で導入されたASMは、「安いハードウェアや安いストレージを使ってください」というオラクルからのメッセージといえるだろう。データベース製品に内蔵されたストレージ管理ソフトウェアと安価なハードウェアの組み合わせは、サードパーティ製の高価なストレージ・ソリューションを必要としなくなる。
R1でのASMでは、ファイルサーバなどからOracleのファイルシステムが見えにくくなって、若干運用がやりづらくなった。例えば、Oracleのファイルの中身を見るのに、SELECT文を使ってデータを取得しないと、どのファイルがどこにあるか分からない。実はEnterprise Managerでは確認できるのだが、それを使っていないユーザーからは、不便だというフィードバックがあったそうだ。
これに対し、R2ではASMによって管理されているOracleのファイルや設定が、簡単に確認できるようなストレージ可視化機能を提供するという。
Oracle Backup
Oracleがバージョンアップしてもすぐに購入を決めないユーザーは、バックアップ・ソフトウェアなど周辺機器や周辺ツールが新バージョンに対応していない点を指摘するそうだ。データベース・システムに必要なすべての製品が新バージョンに短時間で対応する環境を作るには、いっそ従来サードパーティ製品に頼っていた部分をOracle本体に組み込んでしまえばいい、というのが最近のオラクルの戦略らしい。上述のASMと同様、R1ではバックアップ・ソフトウェアとして「Recovery Manager」が統合されている。
Recovery ManagerはR1ではストレージへのバックアップのみの対応にとどまっているが、R2からはテープへのバックアップにも対応するという。これで完全にサードパーティ製のバックアップ・ソフトウェアは必要なくなる。
Transparent Data Encryption
Oracle9iまでは、データの暗号化はDES(Data Encryption Standard)、Triple DES、AES(Advanced Encryption Standard)を利用できた。一方、IBMのDB2はRC4(Ron's Code 4)で暗号化できる。RC4は基本的にネットワークに流れるデータの暗号化に適したアーキテクチャで、DES、Triple DES、AESはどちらかというとストレージに蓄積されたデータなど静的なデータの暗号化に適している。ユーザーからの要望に応えてOracleはR1からRC4にも対応した。
とはいえ、R1までの暗号化は、PL/SQLのパッケージを使って、データが来るたびにパッケージを呼び出してデータを格納する仕組みだった。ワンクッション余計な処理が加わるため、それが面倒で暗号化を導入しないという声もあったという。
R2では、テーブルの作成時などに、暗号化するデータを指定できるようになる。つまり、アプリケーションからは透過的にデータの暗号化が行えるのだ。暗号化されたデータは、SELECT文で取得する際に「キー」を付けないとデータを見ることができない。さらにバックアップ・データも暗号化されるので、例えばバックアップ・テープを車に置いたままその場を離れて盗難に遭うといったケースでも、データを保護できるようになる。2005年4月に施行される「個人情報保護法」に向け、企業のセキュリティ対策はデータの流出防止に関心が集まっているようだが、このようなデータそのものを暗号化する手法も有効だろう。
参考記事 @IT Security&Trustフォーラム
DBセキュリティ虎の巻
「第1回 個人情報データ保護の思考回路」
RACのロードバランシング機能向上
R1までのRACのロードバランシング機能は、透過的アプリケーション・フェイル・オーバー(TAF)という機能でサーバ負荷を振り分けていた。仮に2ノードでRACを稼働させていたとすると、自動的にロードバランスするのはクライアント・アプリケーション側のことで、サーバ側の負荷分散は、サーバとクライアントの中間層でセッション数を判断し、2つのサーバへ順番に処理を割り振り分ける単純なアルゴリズムだった。つまり2ノードで10個のセッションをつなげる場合、ノード1とノード2に各5セッションずつ均等に割り振る。もし、ノード2に割り振られた5セッション中の3セッションが処理を終了して切断されると、現在のセッション数はノード1が5個、ノード2は2個となる。そうであってもTAFは両ノードに順番に新しいセッションを割り当てていた。つまりセッション数にばらつきが生じていたのである。
R2のロードバランシング機能では、サーバの現在の負荷を感知して、より負荷の少ないノードにつなげるように進化するそうだ。つまり、ノード1が5セッション、ノード2が2セッションなら、ノード2に優先して新規セッションを割り当てる。負荷分散がよりインテリジェントに処理されることで、RACのパフォーマンス向上を期待できるだろう。
◇
このようにR2の主な機能拡張は、トータルコスト削減、高可用性、セキュリティ、パフォーマンス向上など、全方位にわたって施されていることが分かる。全体的に見て、スキルの高いDBAを用意できない中小規模ユーザー向けの機能に重点を置いていることが分かる。次回では、Oracle
10gから導入された自動パフォーマンス・チューニング機能について、杉崎氏、根岸氏との一問一答をお届けしよう。(次回に続く)
Index | |
[DB Interview] Oracle 10gへの移行を決断すべきか? |
|
前編 ・Oracle 10gへの移行は進んでいるのか ・Oracle 10gでは何が変わったのか |
|
中編 ・R2はOracle 10gの完成形 |
|
後編 ・GUIツールはプロ用のツールとして通用するのか ・Oracleはどこへ向かっているのか |
[DB Interview] |
- Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか (2017/7/26)
データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します - ドメイン参加後、SQL Serverが起動しなくなった (2017/7/24)
本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します - さらに高度なSQL実行計画の取得」のために理解しておくべきこと (2017/7/21)
日本オラクルのデータベーススペシャリストが「DBAがすぐ実践できる即効テクニック」を紹介する本連載。今回は「より高度なSQL実行計画を取得するために、理解しておいてほしいこと」を解説します - データベースセキュリティが「各種ガイドライン」に記載され始めている事実 (2017/7/20)
本連載では、「データベースセキュリティに必要な対策」を学び、DBMSでの「具体的な実装方法」や「Tips」などを紹介していきます。今回は、「各種ガイドラインが示すコンプライアンス要件に、データベースのセキュリティはどのように記載されているのか」を解説します
|
|