550 likes | 1.32k Views
Windows での Oracle Database : ベスト・プラクティスと将来の方向性. Alex Keh Principal Product Manager, Server Technologies. 議題. Oracle Database 11g :新機能 サポートされるオペレーティング・システム データベース・アーキテクチャ Windows のベスト・プラクティス( 32 ビットと 64 ビット) 診断性 CPU 使用率の最適化 ネットワークの最適化 ファイル I/O の最適化 32 ビット Windows のベスト・プラクティス
E N D
WindowsでのOracle Database: ベスト・プラクティスと将来の方向性 Alex Keh Principal Product Manager, Server Technologies
議題 • Oracle Database 11g:新機能 • サポートされるオペレーティング・システム • データベース・アーキテクチャ • Windowsのベスト・プラクティス(32ビットと64ビット) • 診断性 • CPU使用率の最適化 • ネットワークの最適化 • ファイルI/Oの最適化 • 32ビットWindowsのベスト・プラクティス • 64ビットWindowsのベスト・プラクティス
<ここに画像を挿入> Oracle Database 11g:新機能
Windowsで最適なパフォーマンスを最良の価格で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 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
Active DirectoryとWindowsセキュリティ • データベース登録と名前解決 • OS認証によるActive Directoryへの認証接続をサポート • Kerberos認証 • より強力な暗号化アルゴリズム(DES3、AES、RC4) • MS KDCサポートのデフォルト暗号化タイプに対応 • デフォルトでDNSドメイン名をKerberos REALM名として使用 • MSの異なるドメイン間設定でOracleデータベースにKerberos認証を使用 • Kerberosユーザー名で30文字制限を廃止
Oracle VSSライター • Oracle Volume Shadow Copy Service(VSS)ライターはWindows VSSと透過的に統合 • Oracle VSSライターは自動でOracle DBにインストール • VSSリクエスタでOracleデータベースを自動オンライン・ポイント・イン・タイム・コピー • 簡単なバックアップとリカバリ手順 • 移動可能なスナップショットで別のサーバーへオフロード・バックアップとレポートを実施 • Oracle Recovery Manager(Oracle RMAN)とフラッシュ・リカバリ領域との統合 • リストア・ファイルへのインテリジェントな事後ストア処理 • 例:ファイルのリカバリ、必要なディレクトリ作成後にマウント/非マウント・モードでインスタンスを起動 • VSSフレームワークでシャドウ・コピーされたアーカイブ・ログの自動削除
WindowsでのOracle Direct NFS Client • ネットワーク接続ストレージ(NAS)はネットワーク・ファイル・システム(NFS)を使用 • Oracle Database 11gはWindows NFS v3への直接アクセスを提供 • Oracle Disk ManagerライブラリのDBカーネルの一部 • ほぼすべてのプラットフォームとNFSサーバーに共通のOracle NFSインタフェース • Oracleが使用する特定のI/Oパターンにカスタマイズ • OSの多くのソフトウェア層をバイパス • Kernel NFSをネイティブ・サポートしないWindowsでとくに便利 • 利点:高パフォーマンス、容易な管理性、簡易化されたチューニング、より優れた診断性
Oracle Direct NFS • 低コストのNICでOracle Direct NFSを線形に拡張可能 • リンク・アグリゲーションをサポートする高価なスイッチは不要Oracleがスイッチの代わりにロードバランシングを実施 • パラレル・ネットワーク・パスで、より多くのNICによる、より多くの帯域を確保 • Oracle Direct NFSはローエンドからハイエンドまでのデータベース・サーバーで優れたソリューション
Grid Control for Microsoft Servers システム対象範囲の体系的な拡張方法 • おもな利点:一元管理 • GCで新コンポーネントの監視と管理を実現 • Windowsホスト管理 • MOMコネクタ • Microsoftプラグイン: • Exchange • SQL Server • Active Directory • .NET Framework • IIS
GC for Microsoft Exchange Server • Grid Control 10.2.0.4で新規に提供 • 管理エージェントから自動導入 • OTNからのダウンロードは不要 • 検出 • 組織、ルーティング・グループ、Microsoft Exchange Server • 監視 • インバウンドおよびアウトバウンドのMTA/SMTP/情報ストア接続 • メッセージ・トラフィック • インバウンド/アウトバウンド・キュー • リソース使用率
GC for Microsoft Exchange Server • レポート • 標準搭載 • 構成データ • Exchangeリンク • Exchangeコネクタ • Exchangeクラスタ・リソース • Active Directory
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アラートを関連づけ
<ここに画像を挿入> サポートされるWindowsオペレーティング・システム
Windows 32ビットプラットフォームのサポート 予定 – その時点の最新DBパッチセットを利用可能
Windows 64ビットプラットフォームのサポート TBD – 未定、今後発表予定
<ここに画像を挿入> Windowsアーキテクチャ上のOracleデータベース
SGAは DBバッファ、 ログ・バッファ 共有プール、 ほかのメモリの 割当てを含む アーキテクチャ:スレッド・モデル Oracleプロセス SGA 3GB または 8TB (総サイズ) 各スレッドは PGAやスタック、 ほかのメモリの 割当てで構成 バックグラウンド・スレッドとフォアグラウンド・スレッド コード
データベース・アーキテクチャ • スレッド・モデル • Oracleプロセス・アーキテクチャの直接ポートではない • データベース・インスタンスごとの最大メモリは3GB(32ビット)または8TB(64ビット) • VLMサポートにより32ビットで3GB以上を実現 • Windowsのサービス・プロセスとして実行 • オペレーティング・システムの制限以外は、メモリ、接続、リソースの制限なし
Windows Server 2003における Oracleの機能強化 • ラージ・ページ・サポート • 大容量のメモリを必要とするインスタンスの場合、ラージ・ページ・サポートでパフォーマンスを向上可能 • レジストリ・パラメータORA_LPENABLEを1に設定 • 32ビット – デフォルトは4KB – 2MB • Itanium – デフォルトは8KB – 16MB • x64 – デフォルトは8KB – 2MB • メモリ/スケジューリングでNUMAをサポート • データベースはノード構成に基づき、メモリとスケジュールをインテリジェントに割当て • ベスト・プラクティス:AMDのNUMAはパッチ10.2.0.2 P5から対応
<ここに画像を挿入> 32ビットおよび64ビットWindowsのベスト・プラクティス
11gクライアントの診断性 • ADRとの統合 • OCIとネットトレースおよびロギングではADRをデフォルトで使用 • クライアント側のマルチスレッドでの診断性コンテキストをサポート • 最初の障害の取得 • クライアントおよびサーバーのトレース・ファイルの相関性 • one-off診断パッチの削減 • 構造ダンプ機能
クライアント特性 • 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でサード・パーティのドライバを設定
CPUチューニング • OracleはOSを通じて全プロセッサを使用する • ORACLE_AFFINITYレジストリ値を設定し、どのスレッドをどのプロセッサで実行するかOracleに指示可能(全インスタンスに同様の設定) • Oracle Database Resource Managerで異なるクラスのユーザーにCPU使用率を設定 • たとえば、ゴールド・カスタマーでCPUの50%を、シルバー・カスタマーで30%、残りで20%を使用するようDBに設定するなど • スレッドの優先度はORACLE_PRIORITY変数でレジストリに設定可能
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>
ネットワークのベスト・プラクティス • システムごとに1リスナーを使用 • Windows Serverのデフォルトのキュー・サイズは50 – LISTENER.ORAのQUEUESIZEパラメータで増加 – ログイン・ストーム時のエラーを防止 • リスナー・ログイン・ストーム・ハンドラ • LISTENER.ORAのサーバー側で構成可能(RATE_LIMIT = <max conn/sec>) • ログイン・ストームが問題になっている場合のみ使用
ネットワークのベスト・プラクティス • 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に合わせて設定しないこと
ネットワークのベスト・プラクティス:共有サーバーvs専用サーバーネットワークのベスト・プラクティス:共有サーバーvs専用サーバー • 専用サーバーは最高のパフォーマンスを提供 • 各クライアント接続は独自のスレッドを保持 • メモリ使用率はサーバー・スレッドごとに2~4MB • OracleはOLTPベンチマークで専用サーバーを使用 • メモリ使用により、スケーラビリティに限界あり • 共有サーバーは大量のメモリを節約 • アイドル接続でもメモリをあまり消費せず • ディスパッチャが共有サーバーへリクエストを渡すことで待機時間発生 • 大量のアイドルをもつ大量の接続数で効果的
ネットワークのベスト・プラクティス:共有サーバーvs専用サーバーネットワークのベスト・プラクティス:共有サーバーvs専用サーバー • 推奨事項 • 十分な物理メモリがある場合は専用サーバーを使用 • それ以外では、一定の期間アイドルになる可能性のあるセッションすべてで共有サーバーを使用 • 少数の高パフォーマンス接続/問合せでは、専用サーバーを使用
ネットワークのベスト・プラクティス:共有サーバーの使用ネットワークのベスト・プラクティス:共有サーバーの使用 • クライアント接続は事前に起動されたサーバー・スレッドを共有 • リソースを無駄にする専用アイドル・スレッドなし • 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つのディスパッチャを使用する • 詳細は『ネットワーク管理者ガイド』を参照
ネットワークのベスト・プラクティス:データベース常駐接続プールネットワークのベスト・プラクティス:データベース常駐接続プール • Oracle専用サーバーをプール • サーバー側接続プールを中間層システムとプロセス全体で共有 • 全サーバー構成に共存 • 専用サーバー、共有サーバー、Oracle RAC • データベース・サーバーに無数のクライアント・プロセスが接続しており、各プロセスが短期間データベース・サーバー・セッションを維持する必要がある場合に便利 • テスト環境では、2GBデータベース・サーバーに対して10,000接続のサポートを実現 • プーリングはオプションでDBAによりサーバーで有効化される • クライアント接続文字列には、(SERVER=POOLED)も必要
ネットワークのベスト・プラクティス: 接続タイムアウト • クライアント側の接続タイムアウト:接続文字列に複数のアドレスがあるとき、迅速なフェイルオーバーを実現 • TCP.CONNECT_TIMEOUT – 11gの機能 - 数秒で実施 – 非デフォルト設定 • SQLNET.OUTBOUND_CONNECT_TIMEOUT – 10gR2以上 – 非デフォルト設定 • 両方のタイムアウトは、個別または同時に実行可能 • サーバー側の接続タイムアウト: • SQLNET.INBOUND_CONNECT_TIMEOUT – 10gR1以上 - 10gR2および11gではデフォルトで60秒に設定、10gR1では非デフォルト設定 • 上記のクライアント側の接続タイムアウトと併用可能
ネットワークのベスト・プラクティス • SQLNET.AUTHENTICATION_SERVICES=(NTS) • SQLNET.ORAのデフォルト値で、OS認証に必要( connect / as SYSDBA ) • サーバー側ではデフォルトのままで使用する • SecureFile LOBを使用 • ネット・スタック最適化は基盤ハードウェアに制限されるスループットを最大に引き上げる
ファイル・システムのベスト・プラクティス • ASMを使用 – 単一インスタンスまたはOracle RACを問わず – 10.1.0.4以上を使用 • 利点 • データファイルの移動が不要 • 表領域のオフライン化が不要 • 停止時間なしでディスクを追加
メモリのベスト・プラクティス • 11g:SGAとPGAの組合せに対する自動管理にMEMORY_TARGETを使用 • 10g以上: • SGA_TARGETパラメータでSGAメモリを制御 • PGA_AGGREGATE_TARGETパラメータでPGAメモリを制御
<ここに画像を挿入> 32ビットWindowsのベスト・プラクティス
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を参照
メモリ監視 • メモリ使用率の監視の主要項目: • Perfmon - oracle.exeのVirtual Bytesで、プロセスが使用する総メモリ量を監視 • Total Pool Non-Paged Bytes– メモリ・カウンタ • 128MBまで増大すると、オペレーティング・システムが不安定になる • 増えすぎる場合、メモリ・リークを確認 • Free System Page Table Entries (PTE) – メモリ・カウンタ • 7500以下にならないよう監視 • boot.iniの/USERVA=2560スイッチで防止
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を参照
Windows Server 2003 メモリ制限(32ビット) Standard Edition: 4GB Enterprise Edition: 32GB Datacenter Edition: 64GB 32ビット:VLMサポート RAM の残り O/Sそのほかのアプリ SGA 3GB データベース・スレッド/ メモリ コード
32ビット:VLMサポート DBで利用可能な拡張 メモリはAWEコール 経由でバッファリング AWEコールのメモリは DBバッファでのみ使用。割り当てられたAWEメモリ量はdb_block_sizeに db_block_buffersを掛けた数に相当。 RAM の残り O/Sそのほかのアプリ AWEメモリ内のDBバッファ へのWindow Oracleオペレーティング・システム・プロセス。通常は3GBのアドレス空間に制限。VLMを使用すると、Oracleはデータベース・バッファに12GBまで使用可能。 3GB SGA - DBバッファ コード
AWEの実装 • OracleでAWEを使用するには、初期化パラメータUSE_INDIRECT_DATA_BUFFERSを追加 • DB_CACHE_SIZEの代わりにDB_BLOCK_BUFFERSを使用 • AWEにおいて、データベースのバッファ・キャッシュは約12GBまで増大可能 • AWE_WINDOW_MEMORYのデフォルト値は1GB • 詳しくはMetalink Note 225349.1を参照
32ビット・メモリのベスト・プラクティス • Automatic Workload Repository(AWR)を使用してキャッシュ・ヒット比率やshared_poolステータスなどを監視値が大きくなりすぎないよう注意 • AWEを実装する際、AWEを使用すると自動メモリ管理機能が無効になることに注意(USE_INDIRECT_DATA_BUFFERSが設定されていると、SGA_TARGETは使用不可)
<ここに画像を挿入> 64ビットWindowsのベスト・プラクティス
64ビットWindowsのベスト・プラクティス • Windows Server 2003ではSP 2を使用し、Windowsのパフォーマンス・バグを回避 • アーキテクチャに対して適切なOracleの64ビット版を実行 • 例:AMD64/EM64T版の64ビットOracle、またはItanium版のOracle • 32ビットOracle DBは64ビット・プラットフォームでサポートなし • 32ビット・クライアントはWindows x64でサポート • ラージ・ページに対応
Windowsカスタマーとオラクル製品 “ “ “ “ “ “ Windows環境で23ノードのOracle RACクラスタをテストし、問題なく稼働することを確認 オラクルは、よりスケーラブルで信頼性の高いデータベース製品を提供するこれにより、比較的低コストでハイエンドのクラスタリング機能を実現 オラクルでは、最高クラスのパフォーマンスを提供しながら、Oracleの機能性を大幅に向上するシステムをデプロイできる ” “ Oracle Enterprise Manager Grid Controlにより、データセンター内の全データベースを1人で管理可能に ” ” ” Daniel BeuoyDBテクノロジー・ディレクター Russ DonnanCIO Russ Donnan, 、CIO Pete Goutmannテクノロジー副社長
追加情報 • Windows Server Center • http://otn.oracle.com/windows • Windowsおよび.NETブログ • http://cshay.blogspot.com/ • 質問 • alex.keh@oracle.com
本書は、弊社の一般的な製品の方向性に関する概要を説明するものです。 また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。 本書は、マテリアルやコード、機能の提供を確約するものではなく、また、購買を決定する際の判断材料とはなりえません。 オラクルの製品に関して記載されている機能の開発、リリース、および時期については、弊社の裁量により決定いたします。