WindowsでのOracle Database 11gアーキテクチャ

Transcription

1 Windows での Oracle Database 11g アーキテクチャ Oracle テクニカル ホワイト ペーパー 2007 年 7 月

2 Windows での Oracle Database 11g アーキテクチャ 概要... 3 はじめに... 3 Windows での Oracle Database アーキテクチャ... 4 スレッド モデル... 4 サービス... 5 スケーラビリティの強化 GB RAM Tuning(4GT)... 6 Very Large Memory(VLM)... 6 ラージ ページ... 7 アフィニティと優先順位の設定... 8 ファイル I/O の強化... 9 クラスタ ファイル システム ビット ファイル I/O... 9 RAW ファイルのサポート... 9 Direct Network File System クライアント - 11g の新機能 ビットの Windows オペレーティング システム 結論 Windows での Oracle Database 11g アーキテクチャ 2

3 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 ビット システムを上回ります はじめに オラクルは 常に Windows オペレーティング システムへの徹底した取組みを続けてきました 1993 年 オラクルは Windows NT 向けの初のリレーショナル データベースを発売しました データベースに特定の変更を加えることで Windows でのパフォーマンスとユーザビリティを向上させました Oracle データベースは Windows プラットフォームにおける主要データベース ソリューションの 1 つになりました Oracle は初めから Windows で最高のパフォーマンスを発揮し もっとも緊密に統合されたデータベースを提供することを目標としてきました そのため 市場をリードする UNIX データベース テクノロジーから Windows プラットフォームへの移行に早い時期から投資をおこなっていました 1993 年 Oracle は Windows NT 向けの初のリレーショナル データベースを発売しました 当初 Oracle の開発努力は Windows でのデータベース パフォーマンス向上とアーキテクチャの最適化に集中していました Oracle7 on Windows NT では Windows プラットフォームに固有の機能を活用するように再設計がおこなわれました これらの機能には ネイティブ スレッド サポートやパフォーマンス モニターおよびイベント ビューアなどの Windows 管理ツールとの統合が含まれます Windows での Oracle データベースは 基本レベルのオペレーティング システム統合から Itanium や AMD64/EM64T システムなどの Windows プラットフォームが提供するより高度なサービスの使用へと発展してきました オラクルは常に新しい Windows テクノロジーを採用し 活用し続けています このホワイト ペー Windows での Oracle Database 11g アーキテクチャ 3

4 パーでは Windows での Oracle Database 11g アーキテクチャについて詳しく説明します また Windows 向けのデータベース機能を向上させる技術革新について説明しますが すべてのハードウェア プラットフォームに適用される機能は対象としていません Windows での Oracle Database アーキテクチャ Oracle Database 11g は Windows 上でも Linux や UNIX 上と同様の機能を提供します ただし 内部では Windows 固有のオペレーティング システム機能の利点を活用して パフォーマンス 信頼性 および安定性を向上させるために大幅な作業が実施されています Windows 上で実行される場合においても Oracle Database 11g は オラクルがサポートする各種の Linux および UNIX プラットフォーム上で提供される機能と同じ機能を備えています ただし データベースとオペレーティング システム間のインタフェースは Windows が提供する固有サービスの利点を活用するために大幅に変更されています したがって Windows での Oracle Database 11g は UNIX コード ベースをそのまま Windows に移植したものではありません データベースが Windows の機能を最大限活用し アプリケーション構築の基盤システムとしての Oracle データベースが安定性および信頼性に優れた高いパフォーマンスを発揮できるようにするため 大幅なエンジニアリング作業が実施されています スレッド モデル Windows での Oracle データベース アーキテクチャは プロセスではなくスレッドに基づいています スレッドによって コンテキスト切替えが迅速になり 共有メモリを使用しない SGA 割当て作業は大幅に簡素化され 新規接続の作成時間が短縮され 全体的なメモリ使用が削減されます 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 上でもそのほかのプラットフォーム上と同様に動作するよう あらゆる努力がおこなわれています スレッド ベース アーキテクチャへ移行しようとした本来の動機は Windows NT 向けの最初のリリースで発生したパフォーマンスの問題に起因しています この問題は プロセス間で共有されたファイルを処理する際に発生しました 単純にスレッド ベース アーキテクチャへ変換しただけで そのほかのコードを変更しなくても Windows NT でこの特定のボトルネックが解消されたため パフォーマンスは飛躍的に向上しました アーキテクチャの変更に対する本来の動機付けはもはや存在しませんが 非常に優れた安定性と保守性が明らかになったため Oracle ではスレッド アーキテクチャの使用が継続されました Windows での Oracle Database 11g アーキテクチャ 4

5 スレッド アーキテクチャには別の利点もあります スレッド間でのオペレーティング システム コンテキストの切替えはプロセス間とは対照的に迅速であり システム グローバル領域 (SGA) の割当てルーチンも 共有メモリを使用する必要がないため格段に容易です また スレッドはプロセスよりも迅速に作成されるため 新規接続の作成にかかる時間が短縮されます スレッドはプロセスよりも多くのデータ構造を共有するため メモリ使用が削減できます 最後に スレッド ベース モデルには プロセス ベース モデルよりも "Windows 的 " であるという認識があります 内部的には スレッド モデルの実装コードはコンパクトであり Oracle コードの本体から遠く分離されています スレッド モデルの実装に必要なインフラストラクチャ全体が 20 未満のモジュールによって提供されています さらに 例外ハンドラの使用とリソースの追跡および割当て解除をおこなうルーチンによって堅牢性が強化されました これらのおかげで Windows アプリケーション上の Oracle データベースは リソース リークやプログラムの動作不良による停止なしで 24 時間 365 日の要件を満たすことができます サービス Oracle データベースは Windows サービスとして実行されるバックグラウンド プロセスであり Windows の起動時に開始されます スレッド ベースであることに加えて Oracle Database 11g は一般的な Windows プロセスではありません Oracle Database 11g は Windows サービスであり 基本的にはバックグラウンド プロセスです このプロセスはオペレーティング システムに登録されており 起動時に Windows によって開始され 特定のセキュリティ コンテキスト内で実行されます システムの再起動時にデータベースを自動的に開始するため Oracle をサービスに変換する必要がありました サービスは開始するためにユーザー インタラクションを必要としないからです Oracle データベース サービスが開始されるとき 一般的な Oracle スレッドはいずれもプロセス内で実行されていません そのかわり プロセスは基本的に初期接続と SQL*Plus からの起動リクエストを待ちます このリクエストにより フォアグラウンド スレッドが開始され その後 最終的にバックグラウンド スレッドと SGA が作成されます データベースが停止されると作成されたすべてのスレッドは終了しますが プロセス自体は引き続き実行され 次の接続要求と起動コマンドを待ちます Oracle データベース サービスだけでなく SQL*Plus を自動的に起動し クライアントが使用できるようにデータベースの開始とオープンをおこなうサポートも追加されました Oracle Net Listener もユーザーがデータベースに接続する前に実行中でなければならないため サービスとして実装されています 上述のとおり これらすべての実装事項はクライアントからデータベースへの接続方法や使用方法になんら影響を与えませんが Windows データベース管理者にとっては非常に重要です スケーラビリティの強化 長年にわたって Oracle データベースは常に大規模ユーザーをサポートするように構築されてきました Oracle Real Application Clusters は 複数マシンを 1 つのデータベースとしてクラスタリングすることで ユーザー数の増加とスループットの向上を可能にします Windows での Oracle Database 11g が目指すおもな目標の 1 つは スケーラビリティ スループット データベース処理能力を向上させるために オペレーティング システム テクノロジーとハードウェア テクノロジーを最大活用することです Windows での Oracle Database 11g アーキテクチャ 5

6 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) Windows での Oracle データベースは 4GB RAM Tuning Very Large Memory Address Windowing Extensions などの各種手法を通じて大容量メモリへのアクセスをサポートします Oracle では使用可能な最大メモリである 64GB まで使用できるため スケーラビリティとスループットに優れたユーザー エクスペリエンスを提供できます クラスタリングや 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 サイズや接続数を増加できる点です この機能はバージョン 以降のすべての Oracle データベース サーバー リリースでサポートされており 標準の Oracle インストールに変更を加える必要はありません 唯一必要な設定変更は Windows の boot.ini ファイルで /3GB フラグが使用されていることを確認することです 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 を非常に効 Windows での Oracle Database 11g アーキテクチャ 6

7 率的に使用できます データベースに構成するバッファ数を増やすことで メモリ内にキャッシュされるデータも増やせます これにより メモリからのデータ取得よりも大幅にパフォーマンスの低いディスク 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 まで使用できます これは純粋にメモリ内部の変更であり データベース ファイル自体は変更または修正されていません ラージ ページ ラージ ページ サポートは メモリ使用の多いデータベース アプリケーションのパフォーマンスを向上させます これは とくにバッファ キャッシュ サイズが数 GB である場合に有効です ラージ ページ サポートは 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 コンポーネントは これらのラージ ページから割り当てられます この機能は Oracle バッファ キャッシュのサイズが数 GB である場合 とくに有効です サイズの小さい構成でもラージ ページの使用による効果はありますが データベースが大量のメモリにアクセスする場合ほど大きなものではありません この新機能を有効にするには Windows レジストリの Oracle キーでレジストリ変数 ORA_LPENABLE を 1 に設定します Windows での Oracle Database 11g アーキテクチャ 7

8 アフィニティと優先順位の設定 データベース管理者は パフォーマンスを向上させるために 特定の Oracle スレッドに対して CPU アフィニティと優先順位を割り当てることができます Oracle データベースでは Windows 上で実行しているデータベース プロセスとそのプロセス内の個々のスレッドに対して 優先順位とアフィニティの両方の設定変更がサポートされています データベース管理者は レジストリ設定で 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) Oracle データベースは NUMA ハードウェアを自動的に検知し NUMA ノードのアフィニティを効率的に利用するように自身を最適化します Windows Server 2003 では Non-Uniform Memory Access(NUMA) へのサポートが追加されたため Oracle はハイエンドの NUMA ハードウェアをさらに活用できるようになりました このハードウェアでは 1 台の大容量物理サーバーが複数のコンピューティング " ノード " で構成されています NUMA マシン内の各ノードは物理 RAM の異なる部分に異なる速度でアクセスするため データベースが NUMA マシンのトポロジを特定し スケジューリング メモリ割当て および内部操作を適宜調整することが不可欠です NUMA マシン上で実行される場合 Oracle データベースは起動時に ORACLE_ AFFINITY に適切なデフォルト値を自動設定して マシンリソースの利用効率を最大化します また SGA および PGA のメモリ割当ては サーバー上のあらゆる " ノード " からできる限り効率的にメモリ アクセスがおこなえるように NUMA を意識した方法で実行されます 最後に これもパフォーマンス向上を目的として データベース ライター スレッドの数がノードごとに 1 つになるように設定されています Windows での Oracle Database 11g アーキテクチャ 8

9 ファイル I/O の強化 Windows での Oracle データベースはクラスタ ファイル システムをサポートしているため 管理が容易になります 64 ビット ファイル I/O サポートにより 4GB を超えるファイル サイズが使用できます 未フォーマットのディスク パーティションである RAW ファイルのサポートにより 従来のファイル システムと比べてパフォーマンスが向上します Oracle データベース コードにおいて多くの労力が費やされたもう 1 つの分野は クラスタ ファイル 大容量ファイル RAW ファイルのサポートに関係しています Oracle Cluster File System は Oracle Database 11g の重要な部分を占めており Oracle クラスタの管理とインストールを簡素化します すべての Windows 機能を最大活用するため データベースは 64 ビット ファイル I/O をサポートしています これにより 4GB を超えるサイズのファイルを使用できます さらに Windows 上で Oracle RAC と単一インスタンス データベースを使用したパフォーマンスの向上を実現するため 物理 RAW ファイルおよび論理 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 ファイルは 最適なパフォーマンスを必要とする非常に高度なイ Windows での Oracle Database 11g アーキテクチャ 9

10 ンストールにおいて 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 サーバーに対する入力パスと出力パスを完全に制御できるため パフォーマンスが予測可能になり 構成管理が簡素化されるとともに 優れた診断がおこなえます カーネル ネットワーク ファイル システム層のボトルネックやリソース制限が回避されます ただし 依然としてネットワーク通信モジュール用にカーネルは使用されます Windows での Oracle Database 11g アーキテクチャ 10

11 すべてのホスト プラットフォームとサポートされている NFS サーバー上で使用できるように Oracle 向けの共通の NFS インタフェースが提供されます NFS サーバーに対する複数接続間でのロード バランシングと 同時実効性の高い非同期入出力操作を実現する強力なパイプラインにより パフォーマンスが向上します 64 ビットの Windows オペレーティング システム Oracle データベース アーキテクチャのスケーラビリティに関する次の大きな一歩は 64 ビットの AMD64/EM64T および Itanium プラットフォームへの移行によって達成されました Oracle データベースはすでに別の 64 ビット プラットフォームに移植されているため 64 ビットの Windows への移行は安定性と性能に優れたデータベースをもたらします 64 ビットの Windows およびハードウェアは Oracle データベースのパフォーマンスとスケーラビリティに新たな飛躍をもたらします 64 ビットの Windows プラットフォームには AMD64 および Intel EM64T プラットフォームと Intel Itanium プラットフォームの 2 種類があります 前者は Windows x64 オペレーティング システムを使用します 両方のプラットフォームにおいて 32 ビットの場合より優れたスケーラビリティと高いパフォーマンスが実現されます オラクルは これらの 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 による改善は既存アプリケーションにとって透過的であるため コード変更は必要ありません Windows での Oracle Database 11g アーキテクチャ 11

12 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 サイトを参照してください テクニカル- ビジネス- Windows での Oracle Database 11g アーキテクチャ 12

13 Windows での Oracle Database 11g アーキテクチャ 2007 年 7 月著者 :David Colello 共著者 :Alex Keh Ravi Thammaiah Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問い合わせ窓口 : 電話 : ファクシミリ : Copyright 2007, Oracle. All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は一切間違いがないことを保証するものではなく さらに 口述による明示または法律による黙示を問わず 特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み いかなる他の保証や条件も提供するものではありません オラクル社は本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle は米国 Oracle Corporation およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です