Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP-UX   >  Knowledge-on-Demand  >  特別企画

Oracle 環境向け高速化ツール“ODM”で
「rawデバイスの悩み」を解消しよう

特別企画:HP-UX11i v3 新世代ミッションクリティカルOSへ 第4回

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
特別企画:HP-UX11i v3 新世代ミッションクリティカルOSへ 第4回  Oracle 環境向け高速化ツール“ODM”で「rawデバイスの悩み」を解消しよう
Oracleの構築では常識となっているrawデバイスは、同時にさまざまな「管理のしにくさ」の原因ともなっている。そうした中、「rawデバイスのパフォーマンス」と「ファイルシステムの管理性」の双方を“いいとこ取り”したソリューションが現れた。それが、「HP Serviceguard Storage Management Suite for HP-UX(SG SMS)」に含まれるOracle環境向け高速化ツール「Oracle Disk Manager(ODM)」である。Oracleデータベースの構築は「rawデバイス」で――そんな“常識”も、いまや変わりつつあるようだ。
Oracle 環境向け高速化ツール“ODM”で「rawデバイスの悩み」を解消しよう
「rawデバイス」の常識が変わる?
SG SMSとOracle Disk Manager
2007年7月
テクニカルライター 吉川 和巳
ページ: 1   2   |   次へ 

「rawデバイス」の常識が変わる?

Oracleデータベース(以下、Oracle)の構築は「rawデバイス」で――そんな“常識”も、いまや変わりつつあるようだ。 ご存じのとおり、Oracleでは、データを格納する方法として、以下のいずれかから選択できる。

  • OSのファイルシステム
  • rawデバイス

例えば前者のファイルシステムを選択した場合、Oracleはファイルシステム上に通常のファイルを作成し、その中にレコードを格納する。これに対し、後者の「rawデバイス」では、OSのファイルシステムを作成しない“生(raw)”のディスク・パーティションを利用する。つまり、OSのファイルシステムを介さずに、Oracleがディスクに直接アクセスし、データを記録する形態である。

rawデバイスとファイルシステム
図1:rawデバイスとファイルシステム

Oracleの構築においてファイルシステムよりもrawデバイスが好まれる理由は、リレーショナル・データベース(RDB)というソフトウェアの性質を考えれば明らかだ。RDBは、リレーショナル・モデルに基づいて、「テーブル」や「レコード」といった論理単位でデータを管理するソフトウェアである。大量のレコードを効率的に検索するためのメカニズムや、テーブルの読み書きを高速化するバッファ(Oracleで言えばSGA)をそなえる。これに対しOSのファイルシステムは、ツリー構造(ディレクトリ)に基づいて、「ファイル」という論理単位でデータを管理するソフトウェア。多数のファイルを効率よく管理し、ファイルの読み書きを高速に実行するためのバッファを提供する。

このように、データベースとファイルシステムはデータ・モデルや目的が異なるうえ、キャッシュ機構もそれぞれが個別に備えている。つまり、Oracleのデータをファイルシステム上に保存することは、「英語をいったんフランス語に訳してから日本語に訳す」ようなものなのだ。とりわけ、ファイルシステムとOracleのそれぞれのバッファ機構が重複することによるオーバーヘッドは大きい。

そこで、ファイルシステムを介さずに、Oracleが独自のフォーマットでディスク上にデータを記録する方法がrawデバイスである。rawデバイスを用いてOracleを構築した場合、Oracle独自の形式でディスク・パーティション上に直接データを配置する。よって上述の二度手間を省き、パフォーマンスが大幅に向上するのである。どうしてもパフォーマンスを考慮する必要のある実運用での環境下では、rawデバイスを選択してOracleを構築することの方が一般的であると言えるだろう。


rawデバイスは管理しにくい

しかし、rawデバイスには「管理しにくい」という大きなデメリットがある。ファイルシステムを持たないため、OSからは「ディスク上のひとつのボリューム」としか認識されない。よってrawデバイスに対してシェルから操作できることと言えば、ボリューム単位でのバックアップ/リストアくらいだ。データの一覧表示や移動、コピーといった簡単な操作も、すべてOracle上の管理コマンドで実施する必要が生じる。

データの管理に通常のシェルが使えないことの弊害は大きい。緊急時のリカバリ作業のみならず、日常の運用業務でさえ、Oracle管理のスキルを持つコストの高い管理者が必要となる。また、他のアプリケーションに対しては有用な運用管理用のシェル・スクリプトやツール群も、rawデバイスに対してはほとんど役に立たない。よって、システムを構成する数あるミドルウェアやアプリケーション、ツール群の中でも、Oracleだけを特別扱いする必要が生じる。またOracle内部でも、ログ・ファイルや設定ファイル、Oracleのバイナリ・ファイルなどはファイルシステムで管理する。よってそれらのバックアップやリストアは、rawデバイスとは個別に実施しなければならない。

そのうえrawデバイスには、ファイルシステムのようなパーミッションの概念がない。したがって管理者のちょっとしたオペレーション・ミスによって、rawデバイス全体を上書きしたり削除したりする可能性もある。ディレクトリの概念もないので、rawデバイスの数が多い構成では管理が煩雑となる。

さらにrawデバイスの利用時には、データベースがオンラインの状態で領域を動的に拡張することができない。そのため、個々のテーブルについてレコード件数の増加にともないどの程度の領域が消費されるか、あらかじめ厳密に見積っておく必要が生じる。もしrawデバイスの領域を使い切ったら、サービスを止めての拡張作業が必要になる。これに対し、例えばHP-UXのオプション機能「OnlineJFS」では、アプリケーションの稼働中にもファイルシステム領域の動的拡張が可能だ。サービスを止めずとも、必要に応じてディスクを追加するだけで、さらに多くのデータを格納可能になる。したがって複数のテーブルをひとつのファイルシステム上に集約して一括管理でき、上述のような厳密な見積もりや面倒なメンテナンス作業は不要だ。

このように、Oracleの構築では常識とされてきたrawデバイスも、振り返ってみればさまざまな弊害を生み出していることがわかる。そうしたなか、「rawデバイスのパフォーマンス」と「ファイルシステムの管理性」の双方を“いいとこ取り”したソリューションが現れた。それが、「HP Serviceguard Storage Management Suite for HP-UX(SG SMS)」に含まれるツール「Oracle Disk Manager(ODM)」である。

特別企画一覧 ページ: 1   2   |   次へ  次のページへ

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項