windows での oracle database : ベスト・プラクティスと将来の方向性

51

Upload: brittany-herring

Post on 02-Jan-2016

333 views

Category:

Documents


2 download

DESCRIPTION

Windows での Oracle Database : ベスト・プラクティスと将来の方向性. Alex Keh Principal Product Manager, Server Technologies. 議題. Oracle Database 11g :新機能 サポートされるオペレーティング・システム データベース・アーキテクチャ Windows のベスト・プラクティス( 32 ビットと 64 ビット) 診断性 CPU 使用率の最適化 ネットワークの最適化 ファイル I/O の最適化 32 ビット Windows のベスト・プラクティス - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性
Page 2: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

< ここに画像を挿入 >

Windows での Oracle Database : ベスト・プラクティスと将来の方向性 Alex KehPrincipal Product Manager, Server Technologies

Page 3: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

議題

• Oracle Database 11g :新機能• サポートされるオペレーティング・システム• データベース・アーキテクチャ• Windows のベスト・プラクティス( 32 ビットと 64

ビット)• 診断性• CPU 使用率の最適化• ネットワークの最適化• ファイル I/O の最適化

• 32 ビット Windows のベスト・プラクティス• 64 ビット Windows のベスト・プラクティス

Page 4: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

< ここに画像を挿入 >

Oracle Database 11g :新機能

Page 5: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

Windows で最適なパフォーマンスを最良の価格で

• TPC-C 価格性能比カテゴリにて全プラットフォームのトップに• Windows の Oracle Database 11g

• …TPC-C 性能比カテゴリでもオラクルが 1 位に

TPC-C の価格性能比カテゴリ 11g SQL 2005

ベンチマーク最高順位 1 位 3 位

価格 /tpmC $0.73 $0.84

tpmC 102,454 82,774

公開日         07/9/12   07/3/27

TPC-C の価格性能比カテゴリ 11g SQL 2005

ベンチマーク最高順位 1 位 3 位

価格 /tpmC $0.73 $0.84

tpmC 102,454 82,774

公開日         07/9/12   07/3/27

2007/11/29 時点 HP ProLiant ML350G5 は 102,454 tpmC 、 $.73/tpmC 、公開日 2007/12/31 。 HP Integrity Superdome Server は 4,092,799 tpmC 、 $2.93 tpmC 、公開日 2007/8/6

( TPC-C 性能比 1 位獲得)。 出典: Transaction Processing Performance Council ( TPC ) www.tpc.org

Page 6: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

Active Directory と Windows セキュリティ

• データベース登録と名前解決• OS 認証による Active Directory への認証接続をサポート

• Kerberos 認証 • より強力な暗号化アルゴリズム( DES3 、 AES 、 RC4 )

• MS KDC サポートのデフォルト暗号化タイプに対応 • デフォルトで DNS ドメイン名を Kerberos REALM 名とし

て使用 • MS の異なるドメイン間設定で Oracle データベースに

Kerberos 認証を使用• Kerberos ユーザー名で 30 文字制限を廃止

Page 7: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

• Oracle Volume Shadow Copy Service ( VSS )ライターは Windows VSS と透過的に統合• Oracle VSS ライターは自動で Oracle DB にインストール• VSS リクエスタで Oracle データベースを自動オンライン・ポイ

ント・イン・タイム・コピー

• 簡単なバックアップとリカバリ手順• 移動可能なスナップショットで別のサーバーへオフ

ロード・バックアップとレポートを実施• Oracle Recovery Manager ( Oracle RMAN )とフ

ラッシュ・リカバリ領域との統合• リストア・ファイルへのインテリジェントな事後ストア処理

• 例:ファイルのリカバリ、必要なディレクトリ作成後にマウント / 非マウント・モードでインスタンスを起動

• VSS フレームワークでシャドウ・コピーされたアーカイブ・ログの自動削除

Oracle VSS ライター

Page 8: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

• ネットワーク接続ストレージ( NAS )はネットワーク・ファイル・システム( NFS )を使用

• Oracle Database 11g は Windows NFS v3 への直接アクセスを提供• Oracle Disk Manager ライブラリの DB カーネルの一部

• ほぼすべてのプラットフォームと NFS サーバーに共通の Oracle NFS インタフェース

• Oracle が使用する特定の I/O パターンにカスタマイズ• OS の多くのソフトウェア層をバイパス

• Kernel NFS をネイティブ・サポートしない Windowsでとくに便利

• 利点:高パフォーマンス、容易な管理性、簡易化されたチューニング、より優れた診断性

Windows での Oracle Direct NFS Client

Page 9: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

• 低コストの NIC で Oracle Direct NFS を線形に拡張可能• リンク・アグリゲーションをサポートする高価なスイッチは

不要Oracle がスイッチの代わりにロードバランシングを実施

• パラレル・ネットワーク・パスで、より多くの NIC による、より多くの帯域を確保

• Oracle Direct NFS はローエンドからハイエンドまでのデータベース・サーバーで優れたソリューション

Oracle Direct NFS

Page 10: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

Grid Control for Microsoft Servers システム対象範囲の体系的な拡張方法

• おもな利点:一元管理• GC で新コンポーネントの

監視と管理を実現• Windows ホスト管理• MOM コネクタ• Microsoft プラグイン:

• Exchange• SQL Server• Active Directory• .NET Framework• IIS

Page 11: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

GC for Microsoft Exchange Server

• Grid Control 10.2.0.4 で新規に提供• 管理エージェントから自動導入

• OTN からのダウンロードは不要

• 検出 • 組織、ルーティング・グループ、 Microsoft Exchange Server

• 監視• インバウンドおよびアウトバウンドの MTA/SMTP/ 情報ストア接続• メッセージ・トラフィック• インバウンド / アウトバウンド・キュー• リソース使用率

Page 12: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

GC for Microsoft Exchange Server

• レポート• 標準搭載

• 構成データ• Exchange リンク• Exchange コネクタ• Exchange クラスタ・リソース• Active Directory

Page 13: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

GC for Microsoft Exchange Server

Page 14: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

Management Connector for Microsoft Operations Manager (MOM)

• Oracle Enterprise Manager への MOM アラートの選択的な送信を実現• イベント・ルールと解決状態による自動および手動アラー

ト送信

• MOM 変更時に Oracle Enterprise Manager を自動更新

• Oracle Enterprise Manager 内の柔軟なモデリング・オプション• 一般的な MOM 管理ホスト・ターゲット• MOM コンピュータを Oracle EM 内の個別ターゲットにマッ

ピング• 既存の Oracle EM ターゲットに MOM アラートを関連づけ

Page 15: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

< ここに画像を挿入 >

サポートされる Windows オペレーティング・システム

Page 16: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

Windows 32 ビットプラットフォームのサポート

オペレーティング・システム 9i R2 10g R1 10g R2 11g

Windows 2000 はい はい はい はい

Windows XP Professional はい はい はい はい

Windows Server 2003 はい はい はい はい

Windows Vista いいえ いいえ はい はい

Windows Server 2008 いいえ いいえ 予定 予定

予定 – その時点の最新 DB パッチセットを利用可能

Page 17: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

Windows 64 ビットプラットフォームのサポート

オペレーティング・システム

9i R2 10g R1 10g R2 11g

Itanium版Windows Server 2003

はい はい はい TBD

x64版Windows XP およびWindows Server 2003

いいえ いいえ はい はい

x64 システム対応Windows Vista

いいえ いいえ 予定 はい

x64 システム対応Windows Server 2008

いいえ いいえ 予定 予定

Itanium版Windows Server 2008

いいえ いいえ TBD TBD

TBD – 未定、今後発表予定

Page 18: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

< ここに画像を挿入 >

Windows アーキテクチャ上のOracle データベース

Page 19: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

アーキテクチャ:スレッド・モデル

Oracle プロセス

3GB または8TB

(総サイズ)

コード

SGA

SGA はDB バッファ、ログ・バッファ共有プール、ほかのメモリの割当てを含む

各スレッドはPGAやスタック、ほかのメモリの割当てで構成

バックグラウンド・スレッドとフォアグラウンド・スレッド

Page 20: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

データベース・アーキテクチャ

• スレッド・モデル• Oracle プロセス・アーキテクチャの直接ポートではない

• データベース・インスタンスごとの最大メモリは3GB ( 32 ビット)または 8TB ( 64 ビット)• VLM サポートにより 32 ビットで 3GB以上を実現

• Windows のサービス・プロセスとして実行• オペレーティング・システムの制限以外は、メモリ、

接続、リソースの制限なし

Page 21: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

• ラージ・ページ・サポート• 大容量のメモリを必要とするインスタンスの場合、ラージ・

ページ・サポートでパフォーマンスを向上可能• レジストリ・パラメータ ORA_LPENABLE を 1 に設定• 32 ビット – デフォルトは 4KB – 2MB• Itanium – デフォルトは 8KB – 16MB• x64 – デフォルトは 8KB – 2MB

• メモリ / スケジューリングで NUMA をサポート• データベースはノード構成に基づき、メモリとスケジュール

をインテリジェントに割当て• ベスト・プラクティス: AMD の NUMA はパッチ 10.2.0.2

P5 から対応

Windows Server 2003 における Oracle の機能強化

Page 22: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

< ここに画像を挿入 >

32 ビットおよび 64 ビットWindows のベスト・プラクティス

Page 23: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

11g クライアントの診断性

• ADR との統合• OCI とネットトレースおよびロギングでは ADR をデ

フォルトで使用• クライアント側のマルチスレッドでの診断性コンテキ

ストをサポート• 最初の障害の取得• クライアントおよびサーバーのトレース・ファイルの相関性

• one-off 診断パッチの削減• 構造ダンプ機能

Page 24: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

クライアント特性

• V$SESSION_CONNECT_INFO/GV$_SESSION_CONNECT_INF• CLIENT_CHARSET (NLS character set)• CLIENT_CONNECTION (同機種 / 異機種)• CLIENT_OCI_LIBRARY (ホーム・ベース、 Oracle Instant

Client Full/Light )• CLIENT_VERSION (クライアントの RSF バージョン)• CLIENT_DRIVER ( OCI/JDBC/その他)

• OCI_ATTR_DRIVER_NAME でサード・パーティのドライバを設定

Page 25: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

CPU チューニング

• Oracle は OS を通じて全プロセッサを使用する• ORACLE_AFFINITY レジストリ値を設定し、どのス

レッドをどのプロセッサで実行するか Oracle に指示可能(全インスタンスに同様の設定)

• Oracle Database Resource Manager で異なるクラスのユーザーに CPU 使用率を設定• たとえば、ゴールド・カスタマーで CPU の 50% を、シル

バー・カスタマーで 30% 、残りで 20% を使用するよう DBに設定するなど

• スレッドの優先度は ORACLE_PRIORITY 変数でレジストリに設定可能

Page 26: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

CPU チューニング – 高 CPU の診断

• Process Explorer :スレッドへドリルダウン• 高 CPU のスレッド ID を取得して問合せを実行• SELECT a.spid, b.username FROM v$process a,

v$session b WHERE a.addr= b.paddr AND a.spid = <thread number>

Page 27: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

ネットワークのベスト・プラクティス

• システムごとに 1 リスナーを使用• Windows Server のデフォルトのキュー・サイズは 50

– LISTENER.ORA の QUEUESIZE パラメータで増加 – ログイン・ストーム時のエラーを防止

• リスナー・ログイン・ストーム・ハンドラ• LISTENER.ORA のサーバー側で構成可能( RATE_LIMIT =

<max conn/sec> )• ログイン・ストームが問題になっている場合のみ使用

Page 28: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

ネットワークのベスト・プラクティス

• SQLNET.ORA または TNSNAMES.ORA の SDU_SIZEを増やす• SQL*Net パケット・サイズを制御• 11g のデフォルト SDU_SIZE は 8K

• バルク・データの転送シナリオでは、 sqlnet.ora またはtnsnames.ora の SDU_SIZE を増やす

• サイズは 32K まで増加可能• 11g および 10g クライアントとサーバーの混在環境では、いず

れかに設定された SDU_SIZE の低い値が採用される( 11g以前のデフォルトは 2K )• 10g では、 SDU_SIZE を 8K以上に増やす

• よくある誤解: MTU に合わせて設定しないこと

Page 29: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

ネットワークのベスト・プラクティス:共有サーバー vs専用サーバー

• 専用サーバーは最高のパフォーマンスを提供• 各クライアント接続は独自のスレッドを保持• メモリ使用率はサーバー・スレッドごとに 2~ 4MB• Oracle は OLTP ベンチマークで専用サーバーを使用• メモリ使用により、スケーラビリティに限界あり

• 共有サーバーは大量のメモリを節約• アイドル接続でもメモリをあまり消費せず• ディスパッチャが共有サーバーへリクエストを渡すことで待機

時間発生• 大量のアイドルをもつ大量の接続数で効果的

Page 30: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

ネットワークのベスト・プラクティス:共有サーバー vs専用サーバー

• 推奨事項• 十分な物理メモリがある場合は専用サーバーを使用• それ以外では、一定の期間アイドルになる可能性のあるセッ

ションすべてで共有サーバーを使用

• 少数の高パフォーマンス接続 /問合せでは、専用サーバーを使用

Page 31: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

ネットワークのベスト・プラクティス:共有サーバーの使用

• クライアント接続は事前に起動されたサーバー・スレッドを共有• リソースを無駄にする専用アイドル・スレッドなし

• tnsnames.ora にてクライアント上で共有サーバーを有効化(DESCRIPTION=

(ADDRESS=(PROTOCOL=tcp)

(HOST=sales-server)(PORT=1521))

(CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (SERVER=shared) ))

• サーバーの init.ora パラメータを修正して共有サーバーを有効化• おおよそのガイドライン: 500 セッションごとに 20 または 30

の共有サーバーを準備し、そこからチューニングする• 50~ 100 セッションごとに 1つのディスパッチャを使用する• 詳細は『ネットワーク管理者ガイド』を参照

Page 32: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

ネットワークのベスト・プラクティス:データベース常駐接続プール

• Oracle専用サーバーをプール• サーバー側接続プールを中間層システムとプロセス全体で共有• 全サーバー構成に共存

• 専用サーバー、共有サーバー、 Oracle RAC• データベース・サーバーに無数のクライアント・プロセスが接

続しており、各プロセスが短期間データベース・サーバー・セッションを維持する必要がある場合に便利

• テスト環境では、 2GB データベース・サーバーに対して10,000 接続のサポートを実現

• プーリングはオプションで DBA によりサーバーで有効化される

• クライアント接続文字列には、 (SERVER=POOLED) も必要

Page 33: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

ネットワークのベスト・プラクティス:

接続タイムアウト• クライアント側の接続タイムアウト:接続文字列に複数

のアドレスがあるとき、迅速なフェイルオーバーを実現• TCP.CONNECT_TIMEOUT – 11g の機能 - 数秒で実施 – 非デ

フォルト設定• SQLNET.OUTBOUND_CONNECT_TIMEOUT – 10gR2以上 – 非

デフォルト設定• 両方のタイムアウトは、個別または同時に実行可能

• サーバー側の接続タイムアウト:• SQLNET.INBOUND_CONNECT_TIMEOUT – 10gR1以上 - 10gR2

および 11g ではデフォルトで 60秒に設定、 10gR1 では非デフォルト設定

• 上記のクライアント側の接続タイムアウトと併用可能

Page 34: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

ネットワークのベスト・プラクティス

• SQLNET.AUTHENTICATION_SERVICES=(NTS) • SQLNET.ORA のデフォルト値で、 OS 認証に必要( connect /

as SYSDBA ) • サーバー側ではデフォルトのままで使用する

• SecureFile LOB を使用• ネット・スタック最適化は基盤ハードウェアに制限されるス

ループットを最大に引き上げる

Page 35: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

ファイル・システムのベスト・プラクティス

• ASM を使用 – 単一インスタンスまたは Oracle RAC を問わず – 10.1.0.4以上を使用

• 利点• データファイルの移動が不要• 表領域のオフライン化が不要• 停止時間なしでディスクを追加

Page 36: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

メモリのベスト・プラクティス

• 11g : SGA と PGA の組合せに対する自動管理にMEMORY_TARGET を使用

• 10g以上:• SGA_TARGET パラメータで SGA メモリを制御• PGA_AGGREGATE_TARGET パラメータで PGA メモリ

を制御

Page 37: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

< ここに画像を挿入 >

32 ビット Windows のベスト・プラクティス

Page 38: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

32 ビット・メモリのベスト・プラクティス

• boot.ini ファイルに /3GB スイッチを追加し、 Oracle プロセスで利用できるアドレス可能なメモリを増大

multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Advanced Server"

/fastdetect /3GB

• サーバーをリブートして有効化• オペレーティング・システムの不安定性を防止するため、カーネル・メモリを詳しく監視すること

• Metalink Notes 46001.1 と 297498.1 を参照• Microsoft KB記事の 297812 を参照

Page 39: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

メモリ監視

• メモリ使用率の監視の主要項目:• Perfmon - oracle.exe の Virtual Bytes で、プロセスが使用す

る総メモリ量を監視• Total Pool Non-Paged Bytes– メモリ・カウンタ

• 128MB まで増大すると、オペレーティング・システムが不安定になる

• 増えすぎる場合、メモリ・リークを確認• Free System Page Table Entries ( PTE ) – メモリ・カウ

ンタ• 7500以下にならないよう監視• boot.ini の /USERVA=2560 スイッチで防止

Page 40: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

ORASTACK の使用

• Oracle プロセス内の各スレッドには 1MB のスタック領域が予約されている

• ほとんどのシステムに影響を与えず、 500KB まで削減可能C:\ orastack tnslsnr.exe 500000

C:\ orastack oracle.exe 500000

• tnslsnr.exe と oracle.exe両方でかならず実行• Orastack 実行前にプロセスを停止• パッチ適用の場合、 Orastack の再実行が必要• 500KB で問題ないか、かならずシステムをテストすること• 詳しくは Metalink Note 46001.1 を参照

Page 41: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

32 ビット: VLM サポート

SGA

コード

RAM の残り

O/Sそのほかのアプリ

3GB

Windows Server 2003 メモリ制限( 32 ビット)

Standard Edition :4GB

Enterprise Edition :32GB

Datacenter Edition :64GB

データベース・スレッド /メモリ

Page 42: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

32 ビット: VLM サポート

RAM の残り

SGA - DB バッファ

コード

AWE コールのメモリはDB バッファでのみ使用。割り当てられた AWE メモリ量は db_block_sizeにdb_block_buffers を掛けた数に相当。

O/Sそのほかのアプリ

3GB

AWE メモリ内の DB バッファへの Window

DB で利用可能な拡張メモリは AWE コール経由でバッファリング

Oracle オペレーティング・システム・プロセス。通常は 3GB のアドレス空間に制限。 VLM を使用すると、 Oracle はデータベース・バッファに 12GBまで使用可能。

Page 43: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

AWE の実装

• Oracle で AWE を使用するには、初期化パラメータUSE_INDIRECT_DATA_BUFFERS を追加

• DB_CACHE_SIZE の代わりにDB_BLOCK_BUFFERS を使用

• AWE において、データベースのバッファ・キャッシュは約 12GB まで増大可能

• AWE_WINDOW_MEMORY のデフォルト値は 1GB• 詳しくは Metalink Note 225349.1 を参照

Page 44: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

32 ビット・メモリのベスト・プラクティス

• Automatic Workload Repository ( AWR )を使用してキャッシュ・ヒット比率や shared_pool ステータスなどを監視値が大きくなりすぎないよう注意

• AWE を実装する際、 AWE を使用すると自動メモリ管理機能が無効になることに注意( USE_INDIRECT_DATA_BUFFERS が設定されていると、 SGA_TARGET は使用不可)

Page 45: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

< ここに画像を挿入 >

64 ビット Windows のベスト・プラクティス

Page 46: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

64 ビット Windows のベスト・プラクティス

• Windows Server 2003 では SP 2 を使用し、 Windows のパフォーマンス・バグを回避

• アーキテクチャに対して適切な Oracle の 64 ビット版を実行• 例: AMD64/EM64T版の 64 ビット Oracle 、または Itanium版の

Oracle

• 32 ビット Oracle DB は 64 ビット・プラットフォームでサポートなし

• 32 ビット・クライアントは Windows x64 でサポート

• ラージ・ページに対応

Page 47: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

““

Russ Donnan, 、CIO

“ “

オラクルは、よりスケーラブルで信頼性の高いデータベース製品を提供するこれにより、比較的低コストでハイエンドのクラスタリング機能を実現

Pete Goutmannテクノロジー副社長

Windows カスタマーとオラクル製品

“オラクルでは、最高クラスのパフォーマンスを提供しながら、 Oracle の機能性を大幅に向上するシステムをデプロイできる

Russ DonnanCIO

”Daniel BeuoyDB テクノロジー・ディレクター

Windows環境で 23ノードの Oracle RAC クラスタをテストし、問題なく稼働することを確認

“Oracle Enterprise Manager Grid Control により、データセンター内の全データベースを 1人で管理可能に

Page 48: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

追加情報

• Windows Server Center• http://otn.oracle.com/windows

• Windows および .NET ブログ• http://cshay.blogspot.com/

• 質問• [email protected]

Page 49: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性

本書は、弊社の一般的な製品の方向性に関する概要を説明するものです。 また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。 本書は、マテリアルやコード、機能の提供を確約するものではなく、また、購買を決定する際の判断材料とはなりえません。オラクルの製品に関して記載されている機能の開発、リリース、および時期については、弊社の裁量により決定いたします。

Page 50: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性
Page 51: Windows での Oracle Database :  ベスト・プラクティスと将来の方向性