Windows で の Oracle Database 11g
アーキテクチャ
Oracle テクニカル・ホワイト・ペーパー
2007 年 7 月
Windows での Oracle Database 11g アーキテクチャ
概要 ... 3
はじめに ... 3
Windows での Oracle Database アーキテクチャ ... 4
スレッド･モデル... 4
サービス... 5
スケーラビリティの強化... 5
4GB RAM Tuning（4GT） ... 6
Very Large Memory（VLM）... 6
ラージ・ページ ... 7
アフィニティと優先順位の設定 ... 8
ファイル I/O の強化 ... 9
クラスタ・ファイル・システム ... 9
64 ビット・ファイル I/O ... 9
RAW ファイルのサポート ... 9
Direct Network File System クライアント - 11g の新機能 ... 10
64 ビットの Windows オペレーティング・システム... 11
Windows での Oracle Database 11g アーキテクチャ
概要
Oracle Database 11g for Windows は、エンタープライズ・スケーラビリティ、信頼 性、および高いパフォーマンスを必要とする配置に最適なデータベース・ソリュー ションです。このホワイト・ペーパーでは、Windows での Oracle データベースの アーキテクチャについて説明するとともに、UNIX および Linux 上の Oracle デー タベースとの違いを明らかにします。
スレッド・ベースのネイティブ Windows サービス・モデルを使用することで、 Oracle Database 11g は高いパフォーマンスとスケーラビリティを実現します。 Oracle データベースは、ラージ・ページや NUMA サポートなど、Windows オペレー ティング・システムや基盤となるハードウェアの高度な機能と緊密に統合されて います。大容量メモリ、大容量ファイルと RAW ファイル、およびグリッド・コ ンピューティングに対するサポートを通じて、Oracle はエンタープライズ･クラス のパフォーマンスを実現します。
Oracle データベースは、32 ビットおよび 64 ビットの Windows オペレーティング・ システムで認証されています。32 ビットの Oracle データベースは、Windows Vista を含む標準 x86 ハードウェアを使用した 32 ビット Windows でサポートされてい ます。64 ビットの Oracle データベースは、Windows x64（AMD64/EM64T）およ び Windows Itanium オペレーティング・システム上で実行されます。64 ビット・ ハードウェアが提供するスケーラビリティとパフォーマンスは、32 ビット・シス テムを上回ります。
はじめに
Oracle データベースは、Windows プラットフォームにおける主要データベース・ ソリューションの 1 つになりました。Oracle は初めから Windows で最高のパフォー マンスを発揮し、もっとも緊密に統合されたデータベースを提供することを目標 としてきました。そのため、市場をリードする UNIX データベース・テクノロジー から Windows プラットフォームへの移行に早い時期から投資をおこなっていまし た。1993 年、Oracle は Windows NT 向けの初のリレーショナル・データベースを 発売しました。 オラクルは、常に Windows オペレーティ ング・システムへの徹底した取組みを続 け て き ま し た 。 1993 年 、オラクル は Windows NT 向けの初のリレーショナ ル・データベースを発売しました。デー タベースに特定の変更を加えることで、 Windows でのパフォーマンスとユーザビ リティを向上させました。 当初、Oracle の開発努力は Windows でのデータベース・パフォーマンス向上とアーキテクチャの最適化に集中していました。Oracle7 on Windows NT では、Windows プラットフォームに固有の機能を活用するように再設計がおこなわれました。こ れらの機能には、ネイティブ・スレッド・サポートやパフォーマンス・モニター およびイベント・ビューアなどの Windows 管理ツールとの統合が含まれます。 Windows での Oracle データベースは、基本レベルのオペレーティング・システム 統合から、Itanium や AMD64/EM64T システムなどの Windows プラットフォーム が提供するより高度なサービスの使用へと発展してきました。オラクルは常に新 しい Windows テクノロジーを採用し、活用し続けています。このホワイト・ペー
パーでは、Windows での Oracle Database 11g アーキテクチャについて詳しく説明 します。また、Windows 向けのデータベース機能を向上させる技術革新について 説明しますが、すべてのハードウェア・プラットフォームに適用される機能は対 象としていません。
Windows での Oracle Database アーキテクチャ
Windows 上で実行される場合においても、Oracle Database 11g は、オラクルがサ ポートする各種の Linux および UNIX プラットフォーム上で提供される機能と同 じ機能を備えています。ただし、データベースとオペレーティング・システム間 のインタフェースは、Windows が提供する固有サービスの利点を活用するために 大幅に変更されています。したがって、Windows での Oracle Database 11g は、UNIX コード・ベースをそのまま Windows に移植したものではありません。データベー スが Windows の機能を最大限活用し、アプリケーション構築の基盤システムとし ての Oracle データベースが安定性および信頼性に優れた高いパフォーマンスを発 揮できるようにするため、大幅なエンジニアリング作業が実施されています。
Oracle Database 11g は、Windows 上で も Linux や UNIX 上と同様の機能を提供 します。ただし、内部では、Windows 固 有のオペレーティング・システム機能の 利点を活用して、パフォーマンス、信頼 性、および安定性を向上させるために大 幅な作業が実施されています。
スレッド･モデル
Windows での Oracle Database 11g を UNIX 上の Oracle データベースと比較した場 合、もっとも顕著なアーキテクチャ上の変更はプロセス・ベース・サーバーから スレッド・ベース・サーバーへの変換です。UNIX の場合、Oracle はプロセスを使 用して、データベース・ライター（DBW0）、ログ・ライター（LGWR）、ディ スパッチャ、共有サーバーなどのバックグラウンド・タスクを実装します。さら に、データベースへの各専用接続により、そのセッションの代わりに別のオペレー ティング・システム・プロセスが作成されます。しかし、Windows の場合はこれ らすべてのプロセスが 1 つの大規模プロセス内にスレッドとして実装されます。 つまり、それぞれの Oracle データベース・インスタンスに対して、Windows で実 行されるプロセスは Oracle データベース・サーバー自体の 1 つのみになります （注：Windows 上には、Oracle Enterprise Manager Database Console など、そのほか のデータベース・サービス用に別の Oracle プロセスが存在します。）このプロセ スの内部には多数のスレッドが実行されており、各スレッドが UNIX アーキテク チャにおける 1 つのプロセスに相当します。したがって、UNIX 上のあるインス タンスにおいて 100 個の Oracle プロセスが実行されているとすると、Windows 上 では 1 つのプロセス内の 100 個のスレッドによって同じワークロードが処理され ることになります。 Windows での Oracle データベース・アー キテクチャは、プロセスではなくスレッ ドに基づいています。スレッドによって、 コンテキスト切替えが迅速になり、共有 メモリを使用しない SGA 割当て作業は 大幅に簡素化され、新規接続の作成時間 が短縮され、全体的なメモリ使用が削減 されます。 データベースに接続しているクライアント・アプリケーションは、操作上、この データベース・アーキテクチャの変更による影響は受けません。内部のプロセス・ アーキテクチャはスレッド・ベース・アプローチに変わりましたが、データベー スが Windows 上でもそのほかのプラットフォーム上と同様に動作するよう、あら ゆる努力がおこなわれています。 スレッド・ベース・アーキテクチャへ移行しようとした本来の動機は、Windows NT 向けの最初のリリースで発生したパフォーマンスの問題に起因しています。この 問題は、プロセス間で共有されたファイルを処理する際に発生しました。単純に スレッド・ベース・アーキテクチャへ変換しただけで、そのほかのコードを変更 しなくても、Windows NT でこの特定のボトルネックが解消されたため、パフォー マンスは飛躍的に向上しました。アーキテクチャの変更に対する本来の動機付け はもはや存在しませんが、非常に優れた安定性と保守性が明らかになったため、 Oracle ではスレッド・アーキテクチャの使用が継続されました。
スレッド・アーキテクチャには別の利点もあります。スレッド間でのオペレーティ ング・システム・コンテキストの切替えはプロセス間とは対照的に迅速であり、 システム・グローバル領域（SGA）の割当てルーチンも、共有メモリを使用する 必要がないため格段に容易です。また、スレッドはプロセスよりも迅速に作成さ れるため、新規接続の作成にかかる時間が短縮されます。スレッドはプロセスよ りも多くのデータ構造を共有するため、メモリ使用が削減できます。最後に、ス レッド・ベース・モデルには、プロセス・ベース・モデルよりも"Windows 的"で あるという認識があります。 内部的には、スレッド・モデルの実装コードはコンパクトであり、Oracle コード の本体から遠く分離されています。スレッド・モデルの実装に必要なインフラス トラクチャ全体が、20 未満のモジュールによって提供されています。さらに、例 外ハンドラの使用とリソースの追跡および割当て解除をおこなうルーチンによっ て堅牢性が強化されました。これらのおかげで、Windows アプリケーション上の Oracle データベースは、リソース・リークやプログラムの動作不良による停止な しで、24 時間 365 日の要件を満たすことができます。
サービス
スレッド･ベースであることに加えて、Oracle Database 11g は一般的な Windows プ ロセスではありません。Oracle Database 11g は Windows サービスであり、基本的 にはバックグラウンド・プロセスです。このプロセスはオペレーティング・シス テムに登録されており、起動時に Windows によって開始され、特定のセキュリ ティ・コンテキスト内で実行されます。システムの再起動時にデータベースを自 動的に開始するため、Oracle をサービスに変換する必要がありました。サービス は開始するためにユーザー・インタラクションを必要としないからです。Oracle データベース・サービスが開始されるとき、一般的な Oracle スレッドはいずれも プロセス内で実行されていません。そのかわり、プロセスは基本的に初期接続と SQL*Plus からの起動リクエストを待ちます。このリクエストにより、フォアグラ ウンド・スレッドが開始され、その後、最終的にバックグラウンド・スレッドと SGA が作成されます。データベースが停止されると作成されたすべてのスレッド は終了しますが、プロセス自体は引き続き実行され、次の接続要求と起動コマン ドを待ちます。Oracle データベース・サービスだけでなく、SQL*Plus を自動的に 起動し、クライアントが使用できるようにデータベースの開始とオープンをおこ なうサポートも追加されました。 Oracle データベースは Windows サービ スとして実行されるバックグラウンド・ プロセスであり、Windows の起動時に開 始されます。
Oracle Net Listener もユーザーがデータベースに接続する前に実行中でなければな らないため、サービスとして実装されています。上述のとおり、これらすべての 実装事項はクライアントからデータベースへの接続方法や使用方法になんら影響 を与えませんが、Windows データベース管理者にとっては非常に重要です。
スケーラビリティの強化
Windows での Oracle Database 11g が目指すおもな目標の 1 つは、スケーラビリティ、
スループット、データベース処理能力を向上させるために、オペレーティング・ システム・テクノロジーとハードウェア・テクノロジーを最大活用することです。 長年にわたって、Oracle データベースは 常に大規模ユーザーをサポートするよう に 構 築 さ れ て き ま し た 。 Oracle Real Application Clusters は、複数マシンを 1 つのデータベースとしてクラスタリング することで、ユーザー数の増加とスルー プットの向上を可能にします。
Windows 上で多数のデータベース接続ユーザーをサポートするために、多くの活 動が実施されてきました。Oracle7 バージョン 7.2 の時代に、すでに本番環境で Windows NT 上の単一データベース・インスタンスへの同時接続が 1,000 を超える 顧客がいました。時が経過するにつれユーザー数は増加し、2,000 を優に上回る ユーザーが本番環境の単一ノード上の単一データベース・インスタンスに同時接 続できるようになりました。Oracle 共有サーバー・アーキテクチャを使用した場 合、Oracle データベース・プロセス内で実行されるスレッド数は制限されますが、 単一データベース・インスタンスに対して 10,000 を上回る同時接続が達成されて います。さらに、ネットワークの多重化と接続プーリング機能を利用すると、さ らに多くのユーザーで単一データベース・インスタンスに接続する大規模構成が 実現できます。 近年では、Itanium または AMD64/EM64T といった新しい 64 ビット・ハードウェ アと Oracle Real Application Clusters（Oracle RAC）を利用することで、Windows データベース管理者はさらにユーザー数を増やすことができます。64 ビットにお ける改良点については後述します。Oracle RAC では、複数のサーバー・マシンか ら同じデータベース・ファイルにアクセスできるため、ユーザー接続数を増やす と同時にスループットも向上できます。また、RAC クラスタの追加ノードとして 汎用ハードウェアを追加できるため、Oracle RAC は費用効率に優れた方法で拡張 と高可用性を実現できるソリューションとしてよく知られています。Windows で は、問題を発生させずに RAC クラスタを 23 ノードまで拡張した事例が複数あり ます。
4GB RAM Tuning（4GT）
クラスタリングや 64 ビット Windows が有効な選択肢ではない場合、32 ビット Windows システム上で使用可能なリソースを最大化する必要があります。32 ビッ トの Windows 2000 Server（Advanced Edition および Datacenter Edition）と 32 ビッ トの Windows Server 2003（Enterprise Edition および Datacenter Edition）には、4GB RAM Tuning（4GT）と呼ばれる機能が含まれています。この機能を利用すると、 使用メモリの多い Windows アプリケーションから、デフォルトの 2GB ではなく 最大 3GB のメモリに直接アクセスできます。Oracle データベースにとっての明ら かなメリットは、50%多いメモリがデータベースで使用できるようになり、SGA サイズや接続数を増加できる点です。この機能はバージョン 7.3.4 以降のすべての Oracle データベース・サーバー・リリースでサポートされており、標準の Oracle インストールに変更を加える必要はありません。唯一必要な設定変更は、Windows の boot.ini ファイルで/3GB フラグが使用されていることを確認することです。 Windows での Oracle データベースは、 4GB RAM Tuning、Very Large Memory、 Address Windowing Extensions などの各 種手法を通じて大容量メモリへのアクセ スをサポートします。Oracle では使用可 能な最大メモリである 64GB まで使用で きるため、スケーラビリティとスルー プットに優れたユーザー・エクスペリエ ンスを提供できます。Very Large Memory（VLM）
ハイメモリの 32 ビット Windows アプリケーションでよく使用される重要なメモ リ・チューニング機能の Very Large Memory（VLM）は、もともと Oracle8i でサポー トされていました。Windows 2000 以上で使用可能な VLM を利用することで、 Windows 上の Oracle データベースは、通常の 32 ビット Windows に課せられる 3GB のアドレス空間制約を打破できます。具体的には、相当する物理メモリをサポー トするマシンおよびオペレーティング・システム上で実行されている場合、単一 データベース・インスタンスから最大 64GB のデータベース・バッファにアクセ スできます。Oracle Database 11g において、VLM サポートはデータベース・カー ネル内のデータベース・バッファ・キャッシュ・コードと非常に緊密に統合され ているため、データベース・バッファとして使用可能な大容量 RAM を非常に効
率的に使用できます。データベースに構成するバッファ数を増やすことで、メモ リ内にキャッシュされるデータも増やせます。これにより、メモリからのデータ 取得よりも大幅にパフォーマンスの低いディスク I/O の回数を削減できます。ま た、この機能を使用することで、データベースのスループットとパフォーマンス の向上につながります。
Windows での Oracle Database 11g は、内部的に Address Windowing Extensions （AWE）を活用しています。AWE は、Windows 2000 以上のオペレーティング・シ ステムに組み込まれています。AWE は API コールのセットであり、従来の 32 ビッ ト Windows アプリケーションで一般的に使用可能であった 3GB を超える RAM へ のアプリケーション・アクセスを可能にします。AWE インタフェースは Intel Xeon アーキテクチャの利点を活用することで、マシン内のすべてのメモリに対して、 マップ/アンマップの迅速なインタフェースを提供します。したがって、4GB を超 えるメモリにアクセスする際、アプリケーションは直接メモリにアクセスしてい るわけではありません。要求されたデータベース・バッファが 4GB を超えるメモ リ領域にある場合、32 ビットのデータベースからアクセスできるようにするには この領域から 4GB 以下のメモリ領域にマップする必要があります。この場合、直 接的なメモリ・アクセスよりパフォーマンスが低下しますが、ディスクを使用す るよりも大幅に早くなります。 AWE コールにより、データベース・バッファの使用量を大幅に増加することが可 能になり、バッファ合計で最大 64GB まで使用できます。これは純粋にメモリ内 部の変更であり、データベース・ファイル自体は変更または修正されていません。
ラージ・ページ
ラージ・ページ・サポートは、32 ビットと 64 ビットの Windows Server 2003 上で、 メモリ使用の多いデータベース・インスタンスのパフォーマンスを向上させます。 Oracle データベースはこの機能を利用することで、プロセッサ・メモリを割り当 てるリソースの使用を効率化できます。ラージ・ページ・サポートが有効である 場合、とくにシステム CPU からメモリ内の Oracle データベース・バッファへのア クセスが迅速化されます。Oracle は、Windows で提供されているラージ・ページ・ サポートを利用します。ラージ・ページ・サイズは、32 ビット Windows で Physical Address Extension（PAE）が有効である場合は 2MB、PAE が無効である場合は 4MB です。また、Windows x64 では 2MB、Windows Itanium では 16MB のページ・サイ ズになります。ラージ・ページは SGA 用に使用されます。バッファ・キャッシュ、 共有プール、ラージ・プールを含むすべての SGA コンポーネントは、これらのラー ジ・ページから割り当てられます。 ラージ・ページ・サポートは、メモリ使 用の多いデータベース・アプリケーショ ンのパフォーマンスを向上させます。こ れは、とくにバッファ・キャッシュ・サ イズが数 GB である場合に有効です。 この機能は Oracle バッファ・キャッシュのサイズが数 GB である場合、とくに有 効です。サイズの小さい構成でもラージ・ページの使用による効果はありますが、 データベースが大量のメモリにアクセスする場合ほど大きなものではありません。 この新機能を有効にするには、Windows レジストリの Oracle キーでレジストリ変 数 ORA_LPENABLE を 1 に設定します。アフィニティと優先順位の設定
Oracle データベースでは、Windows 上で実行しているデータベース・プロセスと そのプロセス内の個々のスレッドに対して、優先順位とアフィニティの両方の設 定変更がサポートされています。 データベース管理者は、パフォーマンス を向上させるために、特定の Oracle ス レッドに対して CPU アフィニティと優 先順位を割り当てることができます。 データベース管理者は、レジストリ設定で ORACLE_PRIORITY の値を変更するこ とで、個々のバックグラウンド・スレッドとフォアグラウンド・スレッド全体に 対して異なる Windows 優先順位を割り当てることができます。同様に、Oracle プ ロセス全体の優先順位を変更することもできます。これにより、パフォーマンス が多少向上する場合があります。たとえば、大量のログ・ファイル・アクティビ ティが発生するアプリケーションの場合、LGWR スレッドの優先順位を上げるこ とで負荷の処理を効率化できます。また、レプリケーションを多用している場合、 リモート・データベースとの間でデータのリフレッシュをおこなうスレッドの優 先順位を上げます。 ORACLE_PRIORITY 設定とよく似ていますが、データベース管理者は ORACLE_ AFFINITY レジストリ設定を使用して、Oracle プロセス全体またはプロセス内の 個別スレッドをシステム上の特定の CPU や CPU グループに対して割り当てるこ とができます。この設定によってもパフォーマンスを向上できる場合があります。 たとえば、CPU 間における移動をおこなわないように DBW0 を 1 つの CPU に固 定すると、パフォーマンスがわずかに向上する場合があります。また、システム 上で別のアプリケーションを実行している場合、ORACLE_AFFINITY を使用して Oracle を使用可能な CPU のサブセットに限定することで、そのほかのアプリケー ションが実行する時間を確保できます。Non-Uniform Memory Access（NUMA）
Windows Server 2003 では Non-Uniform Memory Access（NUMA）へのサポートが 追加されたため、Oracle はハイエンドの NUMA ハードウェアをさらに活用できる ようになりました。このハードウェアでは、1 台の大容量物理サーバーが複数の コンピューティング・"ノード"で構成されています。NUMA マシン内の各ノード は物理 RAM の異なる部分に異なる速度でアクセスするため、データベースが NUMA マシンのトポロジを特定し、スケジューリング、メモリ割当て、および内 部操作を適宜調整することが不可欠です。 Oracle データベースは NUMA ハード ウェアを自動的に検知し、NUMA ノード のアフィニティを効率的に利用するよう に自身を最適化します。
NUMA マシン上で実行される場合、Oracle データベースは起動時に ORACLE_ AFFINITY に適切なデフォルト値を自動設定して、マシンリソースの利用効率を 最大化します。また、SGA および PGA のメモリ割当ては、サーバー上のあらゆ る"ノード"からできる限り効率的にメモリ・アクセスがおこなえるように、NUMA を意識した方法で実行されます。最後に、これもパフォーマンス向上を目的とし て、データベース・ライター・スレッドの数がノードごとに 1 つになるように設 定されています。
ファイル I/O の強化
Oracle データベース・コードにおいて多くの労力が費やされたもう 1 つの分野は、 クラスタ・ファイル、大容量ファイル、RAW ファイルのサポートに関係していま す。Oracle Cluster File System は、Oracle Database 11g の重要な部分を占めており、 Oracle クラスタの管理とインストールを簡素化します。すべての Windows 機能を 最大活用するため、データベースは 64 ビット・ファイル I/O をサポートしていま す。これにより、4GB を超えるサイズのファイルを使用できます。さらに、Windows 上で Oracle RAC と単一インスタンス・データベースを使用したパフォーマンスの 向上を実現するため、物理 RAW ファイルおよび論理 RAW ファイルのデータ・ファ イル、ログ・ファイル、および制御ファイルとしての使用がサポートされます。 Windows での Oracle データベースはク ラスタ・ファイル・システムをサポート しているため、管理が容易になります。 64 ビット・ファイル I/O サポートにより、 4GB を超えるファイル・サイズが使用で きます。未フォーマットのディスク・パー ティションである RAW ファイルのサ ポートにより、従来のファイル・システ ムと比べてパフォーマンスが向上します。
クラスタ・ファイル・システム
Oracle RAC の管理性は、Oracle Cluster File System（Oracle CFS）によって大幅に 改善されました。Oracle CFS はとくに Oracle RAC で使用するために開発されまし た。Oracle RAC 実行ファイルは、Oracle CFS または RAW ファイル上にインストー ルされます。後者の場合、クラスタの各ノード上で少なくとも 1 つのデータベー ス・インスタンスを実行します。Oracle CFS に 1 つの Oracle ホームをインストー ルしている場合、データベースは共有ストレージ、一般的にはストレージ・アレ イ上に存在します。Oracle CFS により、クラスタ内のすべてのノードから Oracle ソフトウェアにアクセスできますが、いずれのノードからも制御することはでき ません。すべての CFS マシンがすべてのデータに対して等しくアクセス可能であ り、どのようなトランザクションでも処理できます。このように、Oracle RAC と Oracle CFS の組合せによりインスタンスと管理が簡素化されると同時に、データ ベース・ソフトウェアの完全な冗長性が保証されます。
64 ビット・ファイル I/O
内部的には、すべての Oracle データベースのファイル I/O ルーチンで 64 ビット・ ファイル・オフセットがサポートされています。つまり、データ・ファイル、ロ グ・ファイル、制御ファイルに関して、ほかのプラットフォームにあるような 2GB または 4GB のファイル・サイズ制限はありません。実際にあるのは、すべてのプ ラットフォームに共通の一般的な Oracle の制限です。これらの制限には、ファイ ル当たりの最大データベース・ブロック数 400 万、最大ブロック・サイズ 16KB、 データベース当たりの最大ファイル数 64K などがあります。これらの値を掛け合 わせると、Windows でのデータベース・ファイルの最大サイズは 64GB になると 計算されますが、サポートされる合計データベース・サイズの最大値は（データ ベース・ブロックが 16KB の場合）4 ペタバイトです。RAW ファイルのサポート
UNIX と同様、Windows でも RAW ファイルの概念がサポートされます。RAW ファ
イルは基本的にフォーマットされていないディスク・パーティションであり、1 つの大容量ファイルとして使用できます。RAW ファイルは未フォーマットのパー ティションであるため、ファイル・システムによるオーバーヘッドがないという 利点があります。結果的に、データベース・ファイルやログ・ファイルに RAW ファイルを使用するとわずかながらパフォーマンスが向上します。しかし、標準 の Windows コマンドは RAW ファイルの操作やバックアップをサポートしていな いため、RAW ファイルを使用するマイナス面として管理性が低下します。したがっ て、通常 RAW ファイルは、最適なパフォーマンスを必要とする非常に高度なイ
ンストールにおいて、Oracle Real Application Clusters によってのみ使用されます。 RAW ファイルを使用するための Oracle 要件はファイル名のみであり、どのドラ イブやパーティションをファイルとして使用するかを指定します。たとえば、ファ イル名が¥¥.¥PhysicalDrive3 である場合、3 番目の物理ドライブをデータベースの 一部の物理 RAW ファイルとして使用することを意味します。また、¥¥.¥log_file_1 というファイルは、分かりやすいように別名を割り当てられた RAW ファイルの 例です。別名は、Oracle Object Link Manager（Oracle OLM）を使用して割り当てる ことができます。Oracle OLM は使いやすいグラフィカル・インタフェースを提供 しており、再起動後もクラスタ間におよぶリンクを維持します。Oracle で RAW ファイル名を指定する場合、正しいパーティション番号またはドライブ文字を選 択するように注意する必要があります。データベースにファイルが追加されると、 指定されたドライブがすでに NTFS や FAT フォーマット済みドライブであっても、 Oracle は単純にこのドライブに上書きをおこなうためです。
Oracle にとって、RAW ファイルはそのほかの Oracle データベース・ファイルとな んら変わりはありません。RAW ファイルはそのほかのファイルと同様に扱われ、 Oracle Recovery Manager からバックアップやリストアを実行できます。
Direct Network File System クライアント - 11g の新機能
Oracle Database 11g では、Oracle Direct Network File System クライアントを使用し て、ネットワーク・ファイル・システム（NFS）バージョン 3 サーバーに直接ア クセスできます。
この機能は、Oracle データベース・カーネルの一部として Oracle Disk Manager ラ イブラリ内に実装されています。ネットワーク接続ストレージ（NAS）ベースの システムは、NFS を使用してデータにアクセスします。以前の Oracle リリースで NAS ストレージ・デバイスにアクセスするには、オペレーティング・システムが 提供するカーネル・ネットワーク・ファイル・システム・ドライバが使用されて いました。このドライバを Oracle で効率的に正しく使用するには、特定の設定が 必要であり、構成パラメータが正しく指定されていない場合、以下の問題が発生 していました。 • NFS クライアントはプラットフォーム間での一貫性に欠けており、オペ レーティング・システムのリリース間でも異なっていました。 • 構成パラメータのチューニングが困難でした。20 以上の NFS パラメータ があり、プラットフォーム間で微妙に異なっていました。 • NFS クライアント・スタックは、汎用目的で設計されたものでした。そ のため、Oracle にとって不要なファイル属性管理などの機能が含まれてい ました。
Oracle Direct Network File System は、データベース・カーネル内に NFS バージョ ン 3 プロトコルを実装しています。これにより、管理が容易になるとともに、予 測可能でよりよいパフォーマンスを実現できます。この新機能を使用するおもな メリットは、以下のとおりです。 • NFS サーバーに対する入力パスと出力パスを完全に制御できるため、パ フォーマンスが予測可能になり、構成管理が簡素化されるとともに、優 れた診断がおこなえます。 • カーネル・ネットワーク・ファイル･システム層のボトルネックやリソー ス制限が回避されます。ただし、依然としてネットワーク通信モジュー ル用にカーネルは使用されます。
• すべてのホスト・プラットフォームとサポートされている NFS サーバー 上で使用できるように、Oracle 向けの共通の NFS インタフェースが提供さ れます。 • NFS サーバーに対する複数接続間でのロード・バランシングと、同時実 効性の高い非同期入出力操作を実現する強力なパイプラインにより、パ フォーマンスが向上します。
64 ビットの Windows オペレーティング・システム
64 ビットの Windows およびハードウェアは、Oracle データベースのパフォーマン スとスケーラビリティに新たな飛躍をもたらします。64 ビットの Windows プラッ トフォームには、AMD64 および Intel EM64T プラットフォームと Intel Itanium プ ラットフォームの 2 種類があります。前者は Windows x64 オペレーティング・シ ステムを使用します。両方のプラットフォームにおいて、32 ビットの場合より優 れたスケーラビリティと高いパフォーマンスが実現されます。 Oracle データベース・アーキテクチャの スケーラビリティに関する次の大きな一 歩は、64 ビットの AMD64/EM64T および Itanium プラットフォームへの移行によっ て達成されました。Oracle データベース はすでに別の 64 ビット・プラットフォー ムに移植されているため、64 ビットの Windows への移行は安定性と性能に優れ たデータベースをもたらします。 オラクルは、これらの 64 ビット・プラットフォームに対する徹底した取組みを続けてきました。Itanium と AMD64/EM64T の両方で、64 ビット Windows に対応し たデータベース開発者向けリリースを最初に販売したのはオラクルです。オラク ルは 64 ビット Windows コンピューティングの道を開き続け、Itanium 向けの 64 ビット Windows Server 2003 の発売当日に Oracle データベースの製品バージョンを リリースしました。オラクルの開発チームは、両方の 64 ビット･ハードウェアと オペレーティング・システム上でのデータベースの最適な動作を保証すべく、 Microsoft、Intel、および AMD と緊密な協力を続けてきました。 UNIX プラットフォームでの 64 ビット Oracle データベースでも同じことですが、 Windows での 64 ビット Oracle データベースは 32 ビット・データベースと比較す ると、多数の接続を処理し、大幅に多くのメモリを割り当て、非常に優れたスルー プットを実現します。64 ビット・システムでより多く使用可能になったキャッシュ とメモリにより、Oracle のパフォーマンスとスケーラビリティは大幅に向上しま した。32 ビット・システムのような 4GB のメモリ制限はもはや存在しないため、 64 ビット Oracle は大規模トランザクション処理やビジネス・インテリジェンス・ アプリケーションに最適です。さらに、64 ビット・アーキテクチャで実現した並 列性、スケジューリング、およびスループットの向上が Oracle に恩恵をもたらし ました。これらのパフォーマンス向上はすべて、透過的に Oracle データベースで 利用できます。このため、既存のデータベース配置でコードを変更する必要はあ りません。 64 ビットに移行したことで得られたパフォーマンス向上に加えて、Oracle に導入 された主要なパフォーマンス改善の 1 つにプロファイルに基づく最適化（PGO） があります。Intel の 64 ビット Windows コンパイラを使用した場合、Oracle デー タベースは Itanium と AMD64/EM64T の両方で典型的な顧客ワークロードに対し て最適に動作するよう設計されています。シミュレートされた顧客ワークロード をコンパイル時に使用することで、フィードバック・ループがコンパイラに提供 され、もっとも使用されるコード・パスともっとも使用されないコード・パスが 分析されます。コンパイラは、この情報に基づいて、64 ビット・ハードウェアで の実行時に効率が上がるようにコード・パスを配置します。Oracle では、ほかに 変更を加えずに PGO を使用しただけで約 15～20%のパフォーマンス向上が確認さ れています。PGO による改善は既存アプリケーションにとって透過的であるため、 コード変更は必要ありません。
32 ビットから 64 ビット Oracle への移行パスは非常に簡単です。データベースの 再作成が不要であるばかりでなく、フル・エクスポートやフル・インポートも必 要ありません。現在のデータ・ファイルを新しいシステムにコピーし、64 ビット・ バージョンの Oracle をインストールした上で、通常どおりにデータベースを開始 し、いくつかの SQL スクリプトを実行してデータ・ディクショナリを更新するだ けでいいのです。 アーキテクチャ上の観点から見ると、現在の実績あるスレッド・ベース・アーキ テクチャが 64 ビット版で使用されています。結果的に、新しい 64 ビット Oracle ソフトウェアの作成には、再コンパイル、再リンク、再テスト、そして新バージョ ンの再リリースが伴いました。基盤となるオペレーティング・システムの API は 実質的に同じであったため、64 ビットへの移行において加えられた新規コードは ほとんどありません。また、Oracle データベースはすでに別の 64 ビット・オペレー ティング・システムに移植されているため、64 ビットへの移行は簡単なプロセス であり、短期間で品質と安定性に優れた製品が提供されます。 AMD64/EM64T を使用する利点の 1 つは、同一システム上で 32 ビットから 64 ビッ トへ容易にアプリケーションを移行できる点にあります。このハードウェアを使 用すると、32 ビット Windows 上で、32 ビットの Oracle データベース・サーバー およびクライアントを実行できます。または、64 ビット・モードでオペレーティ ング・システムを実行し、Oracle クライアントは 32 ビット・モードのまま、その ほかのアプリケーションを 64 ビットに変換することもできます。さらに、Windows x64 上ですべての Oracle を 64 ビットに完全移行することもできます。これらのオ プションにより、同じマシン上で複数のアプリケーションを実行している場合、 32 ビットから 64 ビットへの容易な移行パスが提供されます。顧客は、64 ビット へのアプリケーション移行を時差式に実行できます。
結論
Oracle Database 11g for Windows は、UNIX データベース・サーバーの移植版から、 Windows オペレーティング・システムおよび基盤となるハードウェアのサービス と機能を最大活用する統合ネイティブ・アプリケーションへと進化しました。 Oracle は、アプリケーション構築基盤としての安定性に優れた高機能プラット フォームを提供しながら、パフォーマンス、スケーラビリティ、および機能性を 向上し続けます。オラクルは、32 ビットと 64 ビットの両方の Windows プラット フォームで最高の性能を発揮するデータベースを提供するために全力を尽くして います。
Windows での Oracle データベースについて、詳しくは下記の Web サイトを参照し てください。
テクニカル-http://www.oracle.com/technology/global/jp/tech/windows/index.html ビジネス-http://www.oracle.com/lang/jp/technologies/microsoft/index.html
Windows での Oracle Database 11g アーキテクチャ 2007 年 7 月
著者：David Colello
共著者：Alex Keh、Ravi Thammaiah Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口： 電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com
Copyright © 2007, Oracle. All rights reserved.
本文書は情報提供のみを目的として提供されており、ここに記載される内容 は予告なく変更されることがあります。本文書は一切間違いがないことを保 証するものではなく、さらに、口述による明示または法律による黙示を問わ ず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含 み、いかなる他の保証や条件も提供するものではありません。オラクル社は 本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的ま たは間接的に確立される契約義務はないものとします。本文書はオラクル社 の書面による許可を前もって得ることなく、いかなる目的のためにも、電子 または印刷を含むいかなる形式や手段によっても再作成または送信すること はできません。Oracle は米国 Oracle Corporation およびその子会社、関連会 社の登録商標です。その他の名称はそれぞれの会社の商標です。
