11gリリース1（11.1）
E05765-03
 目次 |
 索引 |
| Oracle Database 概要 11gリリース1（11.1） E05765-03 |
|
Oracle Database 11gは、自己管理データベースに対するオラクル社の取組みにとって大きな進歩を示すものです。この製品によって、多くの日常的な管理作業が自動化され、パフォーマンス診断、SQLチューニング、領域管理、メモリー管理などの主要なDBA機能が大幅に簡素化されます。また、データベースの主要なコンポーネントの管理についてDBAをガイドする複数のアドバイザが導入され、潜在的なメリットとともに特定の推奨事項が提示されるようになりました。さらに、Oracle Database 11gは、問題を予測して事前にアラートを送信するため、対処的ではなく予防的なデータベース管理が容易となります。
この章の内容は、次のとおりです。
Oracle Universal Installerは、OracleのソフトウェアをインストールするためのGUIツールです。OUIを使用すると、総合的な前提条件（オペレーティング・システムのバージョン、ソフトウェア・パッチ、容量など）の確認、選択したソフトウェア・コンポーネントのインストール、インストール後のすべての構成の実施など、すべてのインストール作業が自動化されます。
インストールは、日常的な監視と管理に必要なインフラストラクチャを自動的に設定する自己完結型の処理です。Oracle Enterprise Manager Database Management Consoleは、管理者がデータベースの管理作業を開始できるように自動的に構成されます。手動による構成は必要ありません。Oracle Enterprise Manager Database Consoleには、アラート通知、ジョブ・スケジューリング、ソフトウェア管理も含めて、単一のデータベースを管理するための基本的な機能すべてが用意されています。さらに、データベース、リスナー、管理フレームワークなど、すべてのOracle Databaseサーバーのコンポーネントが自動的に起動および停止するように構成されます。
この項の内容は、次のとおりです。
データベース作成アシスタント（DBCA）は、データベース作成用のGUIツールです。DBCAを使用すると、スタンドアロン・データベース、Oracle Real Application Clustersデータベース、スタンバイ・データベースなど、データベースについて可能な構成をすべて作成できます。データベースの作成過程で、DBCAは、ディスク・ベースの自動バックアップの設定とデータベースのLDAPサーバー（使用可能な場合）への登録をガイドします。DBCAを使用して作成されたデータベースは、完全に設定され、あらゆる点で使用の準備が整います。
インスタント・クライアントは、OCI、OCCI、JDBC-OCIまたはODBCドライバを使用して作成した完全なOracleクライアント・アプリケーションをデプロイする最も簡単な方法です。インスタント・クライアントは、必要なOracleクライアント・ライブラリを一連の小さいファイルで提供します。インストールは、いくつかの共有ライブラリをクライアント・コンピュータのディレクトリにコピーする簡単なものです。このディレクトリに、オペレーティング・システムのライブラリ・パス変数（LD_LIBRARY_PATHやPATH）を介してアクセスできる場合、アプリケーションはインスタント・クライアント・モードで動作します。インスタント・クライアントによるデプロイメントにORACLE_HOME環境は不要です。また、完全なOracleクライアントのインストールで提供される多数のコードやデータファイルも不要です。したがって、クライアント・アプリケーションに要するディスク領域を大幅に削減します。完全なORACLE_HOME環境で実行する同一のアプリケーションと比較しても、インスタント・クライアントを使用してデプロイされたアプリケーションの機能やパフォーマンスに遜色はありません。
|
関連項目
|
Database Upgrade Assistant（DBUA）を使用すると、いくつかの簡単な質問に答えることで、Oracle Real Application Clusters（Oracle RAC）やスタンバイを含めたあらゆるデータベース構成をアップグレードできます。DBUAは、適切なリソースが使用可能であることを自動的に確認し、最も効率的な方法（アップグレード処理を開始する前のデータベースをバックアップし、廃止および非推奨の初期化パラメータを置換するなど）に従って、操作の正常な終了を確認します。
アップグレード処理は再開可能で、中断したところから自動的に再開できます。アップグレード処理にかかる時間を見積ることもできます。
Oracle Databaseには、様々な環境に応じて操作を最適化する多数の初期化パラメータが用意されています。ほとんどの場合はデフォルト値のままで十分で、明示的な設定を必要とするパラメータはごく少数です。
約30種類の基本的なパラメータがあります。それ以外のパラメータは、熟練したDBAが固有の要件にあわせてOracle Databaseの動作を調整するために確保されており、このような要件のないDBAには負担となりません。
データ・ポンプを使用すると、Oracle Databaseとの間でのデータやメタデータのロードとアンロードを大幅に高速化できます。ロードまたはアンロードの複数のパラレル・ストリームが最大のスループットとなるように、自動的に管理およびスケジュールされます。
トランスポータブル表領域機能により、複数のOracleデータベース間で表領域を迅速に移動できます。表領域の転送に必要なのは、データファイルのコピーと表領域構造情報の統合のみであるため、同じデータのエクスポート/インポートやアンロード/ロードより大幅に高速化されます。また、トランスポータブル表領域を使用すると索引データも移動できるため、表データをインポートまたはロードする際に必要な索引の再作成を回避できます。
データ・ポンプ機能とクロス・プラットフォーム・トランスポータブル表領域機能を併用すると、データベースとの間のデータ移動で使用できる強力で使いやすい高性能なツールとなります。
Oracle Databaseには洗練された自己管理インフラストラクチャがあります。これによって、データベースが自らを理解するための情報を取得し、この情報を使用してワークロードの変化に対応したり、潜在的な問題を自動的に解決します。自己管理インフラストラクチャの内容は、次のとおりです。
自動ワークロード・リポジトリ（AWR）は、問題の検出および自己チューニング用にOracle Databaseで使用されるパフォーマンス統計を含んだ、組込みリポジトリです。Oracle Databaseは、定期的に、その稼働統計とワークロード情報すべてのスナップショットを作成し、AWRにそのスナップショットを格納します。スナップショットに含まれるデータは、Automatic Database Diagnostic Monitor（ADDM）によって分析されます。スナップショット間の違いを比較し、システム負荷の影響に応じてどのSQL文を取得するか判断します。これにより、一定期間に取得が必要なSQL文の数が削減されます。デフォルトでは、スナップショットは1時間ごとに作成され、8日間AWRに格納され、その後自動的にパージされます。スナップショットの作成頻度および格納期間は、どちらも変更可能です。
特定の期間に作成されたスナップショットは、その他の類似したワークロード期間と比較するためベースラインに保存できます。ベースラインに含まれるスナップショットは、自動AWRパージ・プロセスからは除外され、無期限に保存されます。Oracle Databaseでは、固定ベースライン、変動ウィンドウ・ベースライン、ベースライン・テンプレートなど各種ベースラインを使用できます。固定ベースラインは、過去における連続した固定期間に対応します。システムが最適な状態で動作しているときに取得された固定ベースラインにより、パフォーマンスが低下している期間に取得されたその他のベースラインやスナップショットを比較し、時間の経過によるパフォーマンス低下を分析できます。変動ウィンドウ・ベースラインは、AWR保存期間内に存在するすべてのAWRデータに対応します。このベースラインは、AWR保存期間全体のAWRデータを使用してメトリックしきい値を計算できるため、適応しきい値を使用する場合に便利です。ベースライン・テンプレートを使用して、今後の連続した期間のベースラインを作成できます。ベースライン・テンプレートには単一と繰返しの2種類があります。単一のベースライン・テンプレートを使用して、今後の連続した単一の期間のベースラインを作成できます。将来取得する期間をあらかじめわかっている場合に便利なテンプレートです。繰返しのベースライン・テンプレートを使用すると、繰返し時間スケジュールに基づいてベースラインの作成および削除ができます。これは、Oracle Databaseで連続した期間を継続して自動的に取得する場合に便利なテンプレートです。
AWRはOracle Databaseの自己管理機能すべての基礎となっています。AWRは、データベースの使用状況の履歴をOracle Databaseに提供する情報源であり、この情報によってADDMは、潜在的なパフォーマンス上の問題を診断し、解決できます。
AWRに格納された情報を分析することで、データベースは、日常的なメンテナンス・タスクの必要性を識別できます。自動メンテナンス・タスクのインフラストラクチャ（AutoTask）によって、Oracle Databaseは、このような操作を自動的にスケジューリングできます。AutoTaskは、メンテナンス・ウィンドウと呼ばれるOracle Schedulerの一連のウィンドウで実行される自動メンテナンス・タスクをスケジューリングします。メンテナンス・ウィンドウは、Oracle Schedulerのウィンドウ・グループMAINTENANCE_WINDOW_GROUPのウィンドウです。
MAINTENANCE_WINDOW_GROUPには、デフォルトで、週の各曜日用のウィンドウが含まれています。平日用のウィンドウ（月曜から金曜）は、午後10時から4時間の間オープン（アクティブ）になるよう構成されます。週末用のウィンドウ（土曜と日曜）は、午前6時に開始され、その後20時間オープンになります。開始時刻と終了時刻、頻度、週当たりの実施日数など、これらのメンテナンス・ウィンドウのすべての属性をカスタマイズできます。また、グループからのメンテナンス・ウィンドウの追加および削除も可能です。
これらのメンテナンス・ウィンドウで、AutoTaskにより自動的にスケジューリングされるタスクは次のとおりです。
Oracle Enterprise ManagerまたはPL/SQLパッケージ・プロシージャを使用して、どのメンテナンス・ウィンドウでこれらのタスクのいずれを実行するかを調整できます。
通常のデータベース操作に対する自動メンテナンス・タスクの影響は、デフォルトでデータベース・リソース・マネージャのリソース計画によって制限されています。デフォルトの計画を修正するか、独自のリソース計画を作成し、システム全体のレベルまたは個々のメンテナンス・ウィンドウのレベルでそれらをアクティブ化することが可能です。AutoTaskにより、すべての自動メンテナンス・タスクが、特定のリソース・コンシューマ・グループに属するOracle Schedulerジョブとして実行されます。リソース・プランにより、これらのリソース・コンシューマ・グループに割り当てられるCPUリソースが制限されます。ユーザー・アプリケーションをリソース・コンシューマ・グループに割り当てることができるため、その他のメンテナンス・タスクに関連するものだけでなく、アプリケーションに関連するメンテナンス・タスクへのリソース割当ても調整できます。
|
関連項目
|
Oracle Databaseには、問題を防止、検出、診断および解決するための高度な障害診断性インフラストラクチャが含まれています。ターゲットとなる問題は、データベース・コードの不具合、メタデータの破損、顧客データの破損などが原因の重大なエラーです。この高度な障害診断性インフラストラクチャの目的は、次のとおりです。
これらの目的を達成するための鍵は、次のテクノロジです。
この項では、この新しいインフラストラクチャの次の2つのコンポーネントについて説明します。
自動診断リポジトリ（ADR）は、トレース、アラート・ログ、状態モニター・レポートなどデータベース診断データのファイルベース・リポジトリです。自動診断リポジトリのディレクトリ構造は、複数インスタンスおよび複数製品の間で統一されています。Oracle Database 11gから、データベース、自動ストレージ管理（ASM）およびその他のOracle製品やコンポーネントでは、すべての診断データはADRに保存されています。各製品の各インスタンスでは、診断データは固有のADRホーム・ディレクトリの下に保存されています。たとえば、共有記憶域とASMがあるOracle Real Application Clusters環境では、データベース・インスタンスとASMインスタンスにはそれぞれADR内にホーム・ディレクトリがあります。ADRの統合ディレクトリ構造、製品とインスタンス間における一貫性のある診断データ形式、および統合されたツール・セットによりユーザーとOracleサポートは、複数インスタンス間で診断データを相関付けて、分析できます。
DBAは、重大なエラーに関連するすべての診断データ（トレース、ヘルス・チェック・レポート、SQLテスト・ケース他）を自動的かつ簡単に収集し、Oracleサポートへの送信に適したzipファイルにパッケージ化できます。重大なエラーに関連する診断データにはすべてそのエラーのインシデント番号がタグ付けされているため、DBAがトレース・ファイルおよびその他のファイルを検索して分析が必要なファイルを決定する必要はありません。必要なファイルはすべて自動的にインシデント・パッケージ化サービスにより識別され、パッケージに追加されます。
空き領域不足などの自動的には解決できず、管理者への通知が必要な問題に対応するために、Oracle Databaseにはサーバー生成アラートが用意されています。Oracle Databaseが自らを監視してアラートを送信することで、タイミングのよい効率的な方法で管理者に問題を通知できます。
監視アクティビティは、データベースが通常の操作を実行するときに開始されます。したがって、問題が発生するとデータベースはただちにその問題に気付くことができます。Oracle Databaseが生成するアラートは、問題を通知するのみでなく、報告した問題の解決方法に関する推奨事項も提供します。これによって、問題を迅速に解決でき、潜在的な障害の防止に役立ちます。
Oracle Databaseには、データベース内の異なるサブシステムごとに多数のアドバイザが用意されています。これらのアドバイザは、対応するサブコンポーネントの操作をさらに最適化する方法を自動的に判断します。たとえば、SQLチューニング・アドバイザやSQLアクセス・アドバイザは、SQL文をより迅速に実行するための推奨事項を提供します。メモリー・アドバイザは、試行錯誤の方式に頼らずに、様々なメモリー・コンポーネントのサイズ設定を支援します。セグメント・アドバイザは、無駄な領域の再生の提案や領域使用の増加傾向の分析など、領域に関する問題を処理します。一方、UNDOアドバイザは、UNDO表領域の正しいサイズ設定をアドバイスします。様々なアドバイザがこの章全般にわたって説明されています。
複数のアドバイザが一貫した統一性のある方法で機能し、アドバイザ同士が相互にシームレスに対話できるように、Oracle Databaseにはアドバイザ・フレームワークが用意されています。アドバイザ・フレームワークは、アドバイザの起動と結果報告に関する一貫した方法を提供します。これらのアドバイザは、主にデータベースが自身のパフォーマンスを最適化するために使用しますが、特定のサブコンポーネントの機能を知るために、管理者が起動することもできます。
共有リソースまたはその他のOracle Databaseプロセス、セッションおよびトランザクションからのリクエスト・サービスへの制限付きアクセスの取得を試行するアクティブなエンティティは、ハングする可能性があります。ハング連鎖は、単一のプロセスがハングの原因となり、それぞれが次のプロセスが保持しているリソースを待機している複数のプロセスの連鎖です。
システムを使用できなくなるため、Oracle Databaseでハングが発生するとコスト面で多大な影響があります。ハングは、具体的には次のような問題の原因となります。
ハング・マネージャは、ハングを検出して分析し、必要な診断データを取得するOracle Databaseインフラストラクチャの1つです。ハング・マネージャは、Oracle RACデータベースおよび自動ストレージ管理（ASM）インスタンスでデフォルトで有効化されています。ハング・マネージャのデータはトレース・ファイルに出力されます。
AWR内にデータが取得されると、Automatic Database Diagnostic Monitor（ADDM）によって、Oracle Databaseは自らのパフォーマンスを診断し、識別された問題の解決方法を判断します。ADDMは、AWR統計の取得ごとに自動的に実行され、パフォーマンス診断データが使用可能になります。
ADDMは、AWRに取得されたデータを調査して分析し、システムの主要な問題を事前に判断します。ほとんどの場合、ADDMは解決策を提示し、予想されるメリットを数量化します。ADDMでは、コンポーネント間の共通判断尺度として時間を使用し、システムのパフォーマンスに対して総合的にアプローチします。ADDMは、システムが最も多く時間を消費している領域を識別します。ADDMは、単に症状を示すのではなく、問題を掘り下げて根本原因を識別し、その問題がシステム全体に及ぼす影響を報告します。推奨事項を提示する場合は、予想されるメリットを時間の観点から報告します。一貫して時間を使用することによって、複数の問題や推奨事項の影響を比較検討できます。
ADDMは、データベースが大部分の時間を費やしているアクティビティに注目し、複雑な問題を分類するツリーをドリルダウンします。ADDMが検出する一般的な問題は、次のとおりです。
潜在的なパフォーマンスの問題報告に加え、ADDMは、システムで問題のない領域も示します。I/Oやメモリーなど、システム・パフォーマンスに大きな影響を与えないサブコンポーネントは、初期段階で分類ツリーから除かれてリストされます。これによって、管理者は、それらのサブコンポーネントでの処理による成果が少ないことを速やかに理解できます。
パフォーマンスに関わる問題の解決策のために、膨大な量の診断データを収集し、データ分析に多くの時間を費やす必要はなくなりました。わずかなマウス操作のみで、ADDMが作成した推奨事項に従うことができます。
Oracle Databaseは、SQLのチューニング処理を完全に自動化します。ADDMは、システム・リソースを大量に使用し、それが原因でパフォーマンス上の問題を引き起こすSQL文を識別します。さらに、CPUと共有メモリーの使用量の観点で上位を占めるSQL文は、AWRに自動的に格納されます。このように、高い負荷のSQL文の識別は、Oracle Databaseで自動的に実施されるため、人的な介入は不要です。
Oracle Databaseは、リソース消費の点で上位を占めるSQL文を識別すると、自動SQLチューニング・アドバイザを使用してそのSQL文を自動的に分析し、解決策を示します。自動SQLチューニングは、SQLチューニング・アドバイザと呼ばれるアドバイザによって提供されます。SQLチューニング・アドバイザは、1つ以上のSQL文を入力情報として取得し、チューニング・アドバイスとともに適切にチューニングされた計画を作成します。SQLチューニング・アドバイザの起動以外に、管理者が行う作業はありません。
解決策は、事前定義のヒューリスティックスを使用して、外部ツールではなくオプティマイザから直接発行されます。これには次の利点があります。a）実行計画とSQLパフォーマンスの最終的な責任を負うシステム・コンポーネントによるチューニングが行われます。b）チューニング処理は完全にコスト・ベースで、問合せオプティマイザに対する変更と拡張の責任は当然オプティマイザが負います。c）チューニング処理ではSQL文の過去の実行統計が考慮され、その文に対するオプティマイザ設定がカスタマイズされます。d）問合せオプティマイザにとって有用と考えられるものに基づいて、通常の統計とともに補足情報が収集されます。
自動SQLチューニング・アドバイザの推奨事項は、次のカテゴリのいずれかに分類されます。
アクセス・パス分析とSQL構造分析は、管理者と開発者がアプリケーション・コードへのアクセス権を保持している、開発中のアプリケーションや社内の本番アプリケーションのパフォーマンスをチューニングする場合に役立ちます。
SQLアクセス・アドバイザは、指定されたワークロードのスキーマ設計を自動的に分析し、ワークロードに応じた索引、ファンクション索引、パーティションおよびマテリアライズド・ビューの作成、保持または削除を提案できます。単一文の使用例では、アドバイザは現行の文に影響する調整のみを推奨します。完全なビジネス・ワークロードについては、ワークロード全体に与える影響を考慮した後に推奨を行います。
推奨事項の生成中、SQLアクセス・アドバイザは、問合せに見込まれるパフォーマンスの改善に加えて、挿入、更新、削除などのデータ操作アクティビティに新しい索引、パーティションとマテリアライズド・ビューを追加することによる影響を考慮します。SQLアクセス・アドバイザがワークロードのフィルタ処理を完了した後、可能なすべての解決策を識別している間に、プロセスを非同期に中断し、その時点までの最適な解決策を取得できます。
SQLアクセス・アドバイザには、使いやすいインタフェースが用意されているため、システムに関する知識はほとんど必要ありません。本番システムからデータを収集し、SQLアクセス・アドバイザを実行できる別のコンピュータにデータを移動できるため、本番システムに影響を与えずにSQLアクセス・アドバイザを実行できます。
Oracle Databaseのメモリー管理では、自動または手動による、システム・グローバル領域（SGA）およびプログラム・グローバル領域（PGA）のメモリー・コンポーネントの動的なサイズ変更が可能です。
新しいデータベース・インストールは、デフォルトで、SGAおよびPGAの様々なコンポーネントを自動的にチューニングするよう構成されています。データベース・パラメータMEMORY_TARGETを変更するだけで、簡単かつ高レベルなメモリー割当ての調整を行うことができます。このパラメータを使用してデータベースにさらにシステム・メモリーを割り当てると、データベースは、最適なデータベース・パフォーマンスを実現するために様々なコンポーネントのサイズを自動的に調整します。
各コンポーネントのパフォーマンスは、Oracleデータベース・インスタンスで監視されます。インスタンスは、内部ビューと統計を使用して、自動的にサイズ設定されたコンポーネントにメモリーを適切に分配する方法を決定します。したがって、ワークロードの変化に応じて、新しいワークロードで最適なパフォーマンスとなるようにメモリーが再分配されます。データベースは、長期と短期の傾向を考慮しながら最適な分配を実現します。
各コンポーネントに最小値を指定することで、自動チューニングされたコンポーネントのサイズを部分的に制御できます。これは、特定のコンポーネントが正しく機能するためにアプリケーションで必要なメモリーの最小量がわかっている場合に役立ちます。
サーバー・パラメータ・ファイル（SPFILE）を使用している場合、自動チューニングされたコンポーネントのサイズは停止しても保持されます。したがって、システムは最後の停止で中断した場所から再開します。
複数のメモリー・コンポーネントに対する割当てをより細かく制御する場合は、手動メモリー管理を有効化します。現在のコンポーネント・サイズやこれらのサイズを変更することによる予想される影響が視覚的に表示される、一連のメモリー・アドバイザを利用できます。
共有プール・アドバイザでは、ライブラリ・キャッシュによる使用を追跡することで最適な共有プール・サイズが判断されます。ライブラリ・キャッシュに使用可能なメモリー容量は、Oracleデータベース・インスタンスの解析率に大きく影響することがあります。共有プール・アドバイザ統計は、ライブラリ・キャッシュ・メモリーに関する情報を提供します。これにより、共有プール・サイズの変更内容によって共有プール内のオブジェクトがエージ・アウトする影響を予想できます。
バッファ・キャッシュ・アドバイザでは、バッファ・キャッシュの最適サイズが判断されます。新規インスタンスに手動でメモリーを構成する際に、バッファ・キャッシュの適正サイズを知ることは困難です。通常は、最初にキャッシュ・サイズを見積った後、インスタンス上で代表的なワークロードを実行して関連統計を検査し、キャッシュ構成の過不足を調べます。バッファ・キャッシュ・アクティビティの検査には、多数の統計を使用できます。これには、V$DB_CACHE_ADVICEビューとバッファ・キャッシュ・ヒット率が含まれます。
Java Pool Advisorは、Javaに使用されるライブラリ・キャッシュ・メモリーに関する情報を提供し、Javaプールのサイズの変化が解析率に及ぼす影響を予測します。
ストリーム・プール・アドバイザでは、ストリーム・プールの最適サイズが判断されます。V$STREAMS_POOL_ADVICEビューでは、STREAMS_POOL_SIZEパラメータの様々な値における収容されるバイト数と収容されないバイト数が見積もられます。このビューを使用して、ストリームおよびロジカル・スタンバイ・データベースのSTREAMS_POOL_SIZEパラメータをチューニングできます。V$STREAMS_POOL_ADVICEビューおよびCPU使用率に関するAWRレポートは、ストリーム・パフォーマンスのチューニングに役立ちます。
プログラム・グローバル領域（PGA）アドバイザは、サーバーおよびバックグラウンド・プロセスのすべてのPGAに割り当てる合計メモリー量であるPGA_AGGREGATE_TARGETに対する適切な設定の判断に役立ちます。
|
関連項目
|
Oracle Databaseは、その領域使用を自動的に管理して、領域に関する潜在的な問題のアラートを送信し、可能な解決策を提案します。領域を容易に管理する上で役立つOracle Databaseの機能には、次のものがあります。
以前のリリースのOracle Databaseでは、ロールバック・セグメントを使用してUNDOを格納していました。これらのロールバック・セグメントの領域管理は複雑でした。自動UNDO管理により、UNDO表領域の領域が自動的に管理されるため、ロールバック・セグメントの管理の複雑さが解消されます。自動UNDO管理は、UNDOが上書きされるまでに保存される時間の長さも最適にチューニングします。UNDO保存の自動チューニングにより、古いUNDO情報が必要な長期間実行される問合せおよび一部のOracle Flashback機能の成功率が向上します。
データベースでロールバック・セグメントを使用するよう構成できますが、自動UNDO管理はデフォルトです。データベースのインストール時に、自動的に拡張するUNDO表領域が自動的に作成されます。
UNDO保存の自動チューニングでは、固定サイズのUNDO表領域を使用するとさらによい結果を得られます。この理由またはその他の理由でUNDO表領域を固定サイズに変更する場合には、UNDOアドバイザを使用して割り当てる適切な固定サイズを決定できます。長期間実行される問合せまたはOracle Flashback操作に必要なUNDO保存期間を指定すると、UNDOアドバイザにより必要なUNDO表領域のサイズが提示されます。UNDOアドバイザは、最も長時間実行する問合せとUNDO生成率を含めたシステム・アクティビティ統計に基づいて提案を行います。アドバイザ情報には、次の項目が含まれます。
関連項目
Oracle Managed Filesを使用すると、Oracleデータベースを構成するファイルを直接管理する必要がなくなります。Oracle Databaseでは、必要に応じて標準ファイル・システム・インタフェースを使用してファイルが作成および削除されます。これにより、データベース・ファイルの作成および削除という日常的なタスクが自動化されます。
Oracle Databaseでは、従来のディクショナリ・ベースの領域管理のみでなく、ビットマップを使用して表の空き領域を管理できます。実装がビットマップ化されるため、表の領域に関連するチューニングは大部分が不要になり、ピーク負荷時のパフォーマンスが改善されます。また、Oracle Databaseではデータファイルの自動拡張機能も用意されているため、ファイルは格納されているデータ量に基づいて自動的に拡張できます。これによって、データベース管理者は、全データベース・ファイルの領域使用率を手動で追跡して再編成する必要がなくなります。
Oracle Databaseでは、領域使用の監視に、他に影響しないタイミングのよいチェックが導入されています。一般的な領域の割当ておよび割当て解除操作の過程で、領域の使用状況が自動的に監視され、使用可能な空き領域が事前定義のしきい値を下回るとアラートが発行されます。領域監視機能はデフォルトで設定されており、パフォーマンスに影響することなく、すべての表領域タイプで一律に使用できます。また、Oracle Enterprise ManagerやSQLを使用しても同じ機能を使用できます。監視は、データベース内での領域の割当てや解放と並行して実行されるため、情報が必要な場合は、領域使用情報をただちに取得できることが保証されます。
通知は、サーバー生成アラートを使用して送信されます。データベース内の特定の領域に関連するイベントが発生すると、アラートがトリガーされます。たとえば、表領域の領域使用しきい値を超えた場合や再開可能セッションで領域不足状況が発生した場合は、アラートが発生します。アラートは、修正措置を講じるために即時に送信されます。アラート情報を受信して表領域に領域を追加することで、中断したところから一時停止操作を続行できます。
データベースには、デフォルトのアラートしきい値が設定されています。指定の表領域に対するデフォルトは上書きできます。また、Oracle Enterprise Managerを介してデータベース全体に新しいデフォルトを設定できます。
領域は、オブジェクトの領域要件を予測することが困難なため、あるいはオブジェクトの増加傾向を予測できないために、過剰に割り当てられる可能性があります。頻繁に更新される表では、結果的にセグメントに多数の内部断片化が発生し、行連鎖となる可能性もあります。これらの問題は、パフォーマンス低下の問題から領域損失の問題に至る多種多様な問題に発展する可能性があります。Oracle Databaseは、これらの難問に対応するために複数の機能を提供しています。
Oracle Databaseでは、指定された表のサイズを、その表の構造と推定行数に基づいて予測できます。これは、オブジェクトの作成や再作成の前にサイズを見積ることができる強力なWhat Ifツールです。表領域に異なるエクステント管理ポリシーがある場合は、内部断片化が最も少なくなるような表領域の判断に、このツールが役立ちます。
増加傾向レポートによって、容量計画の次のステップである増加計画に進みます。ほとんどのデータベース・システムは、時間が経つにつれて大きくなります。増加計画は、リソース・プロビジョニングの重要な側面です。Oracle Databaseは、このプロセスを支援するために、AWRに領域の使用履歴を記録し、この情報を使用して今後のリソース所要量を予測します。
Oracle Databaseには、領域使用を最適化するために、セグメントを縮小してデータを適切に再編成する機能があります。セグメントを縮小すると、表領域内の他のセグメントが未使用領域を使用できるようになり、問合せやDML操作のパフォーマンスが改善される可能性があります。
セグメントの縮小機能は、セグメント内で使用されている領域を圧縮し、空いた領域をセグメントから割当て解除します。割当て解除された領域は表領域に返され、その表領域の他のオブジェクトが使用できるようになります。データが点在している表は、全表スキャンでパフォーマンス上の問題が発生する可能性があります。縮小を実行することで、表のデータが圧縮され、セグメントの最高水位標が押し下げられます。これによって、全表スキャンの読取りブロック数が少なくなり、実行が高速化されます。
セグメントの縮小はオンラインで実行される操作です。セグメントを縮小している間も、縮小されている表に対して問合せおよびDML操作を実行できます。また、セグメントの縮小は適切に実施されます。これは、領域の圧縮と再生に関するオンラインによる表再定義の利点です。データベース内の1つまたはすべてのオブジェクトについて、夜間ジョブとしてセグメントの縮小をスケジューリングできます。その際、他の領域をデータベースに割り当てる必要はありません。
セグメントの縮小は、自動セグメント領域管理を使用している表領域内で行の移動が可能なヒープ、IOT、IOTオーバーフロー・セグメント、LOB、LOBセグメント、マテリアライズド・ビューおよび索引に対して実行されます。索引が設定されている表でセグメントの縮小を実行すると、圧縮のために行が移動してもその索引は自動的に保持されます。圧縮は純然たる物理操作であってアプリケーションには影響がないため、ユーザー定義のトリガーは起動されません。
縮小の候補となるセグメントを簡単に識別するために、Oracle Databaseはセグメント・アドバイザを自動的に実行し、データベース全体を評価します。セグメント・アドバイザは、個々のオブジェクトについて増加傾向分析を実行し、余分な領域がオブジェクトに残されているかを7日ごとに判断します。その後、領域の再生目標を使用して、縮小するオブジェクトの候補を選択します。
ワークロード・リポジトリ内の事前計算済統計の使用に加え、セグメント・アドバイザは、考慮中のオブジェクトをサンプリングして、そのオブジェクトに関する統計を絞り込みます。この操作にはリソースが必要ですが、より正確な分析の実行に使用できます。
セグメントの縮小によって行連鎖が少なくなり、Oracle Databaseではオンライン再定義を行って連鎖行を削除することが推奨されていますが、実際、セグメント・アドバイザにより、しきい値を上回るいくつかの連鎖行が検出されます。たとえば、更新の際に行サイズが増加して、ブロックに収容できない場合、セグメント・アドバイザは、セグメントを再編成してI/Oパフォーマンスを向上させることを推奨します。
|
関連項目
|
自動ストレージ管理（ASM）によって、Oracleデータベース・ファイル専用に構築されたファイル・システムとボリューム・マネージャの垂直統合が提供されます。ASMは、使用可能なすべてのリソースにわたってI/O負荷を分散してパフォーマンスを最適化し、手動によるI/Oチューニングの必要性を取り除きます（データベース・ファイルの分散によってホットスポットを回避します）。ASMでは、データベースを停止して記憶域割当てを調整せずにデータベース・サイズを拡大でき、動的データベース環境の管理に役立ちます。
ASMでは、ディスク・グループと呼ばれる記憶域プールを定義して、Oracleカーネルにより、そのディスク・グループでのデータベース・ファイルのファイル名および配置を管理できます。記憶域割当ては、CREATE DISKGROUP、ALTER DISKGROUPおよびDROP DISKGROUPなどのSQL文を使用して、ディスクの追加や削除などによって変更できます。ディスク・グループは、Oracle Enterprise ManagerおよびDatabase Configuration Assistant（DBCA）でも管理できます。
Oracle Databaseには、記憶域リソース用の簡素化された管理インタフェースが用意されています。ASMは、手動によるI/Oパフォーマンスのチューニングを排除します。記憶域は一連のディスク・グループに仮想化され、用意されている冗長性オプションにより、高水準の保護が使用可能になります。ASMをバランスの自動再調整と併用すると、連続した記憶域の構成変更が容易になります。データベース・ファイルは使用可能なすべての記憶域にまたがって分散され、パフォーマンスとリソース使用率が最適化されます。手動による格納操作が自動化されることで記憶域の管理オーバーヘッドが削減され、より多くの大規模データベースを効率的に管理できるようになります。
次の項では、ASMの基本概念について説明します。
ASMインスタンスは、ディスク・グループ内のディスクを管理する特殊なOracleインスタンスです。データベース・インスタンスからASMファイルにアクセスするには、ASMインスタンスを構成して実行する必要があります。データベースの作成にDatabase Configuration Assistantを使用した場合は、この構成が自動的に実行されます。ASMインスタンスでは、データベースをマウントできません。ASMインスタンスは、データベース・インスタンスのデータ・レイアウト調整のみを実行します。データベース・インスタンスは、ASMインスタンスにアクセスせずに、ディスク・グループ内のディスクに対してダイレクトI/Oを実行します。
ディスク・グループは、1つの論理単位として管理される1つ以上のASMディスクです。ディスク・グループのデータ構造は自己完結型で、ディスク・グループの一部のディスク領域を使用します。ディスク・グループ内のASMディスクは、データベースの稼働中に追加または削除できます。ディスク・グループの構成に変更があっても、そこに含まれる全ディスクへの均一のI/O負荷を保証するために、データ・バランスが再調整されます。
ASMでは、データベースで必要になるとファイルが作成されます。各ファイルには、末尾にドットで区切られた数値ペアが付いた完全修飾名が割り当てられます。ASMのファイル名には、よりわかりやすい別名を作成できます。ASMファイルの別名を調べるには、ASMインスタンスからV$ASM_ALIASデータ・ディクショナリ・ビューを問い合せます。ただし、通常、ユーザーがファイル名を知る必要はありません。
記憶域は、ディスク・グループからASMディスク単位で追加および削除されます。ASMディスクは、完全な物理ディスク、ストレージ・アレイからの論理ユニット番号（LUN）、またはNASフィルタで事前に作成されたファイルの場合があります。個々のASMディスクは、最適なI/Oパフォーマンスを取得するために相互に独立している必要があります。たとえば、ストレージ・アレイの場合は、一対のミラー化された物理ディスクであるハードウェアを表すLUNを、単一のASMディスクとしてASMに指定できます。
Oracle Databaseには、バックアップおよびリカバリの管理を容易にする複数の機能が用意されています。たとえば、次の機能があります。
Oracle Recovery Manager（RMAN）は、バックアップ操作とリカバリ操作を単純化して自動化し、パフォーマンスを改善する強力なツールです。Recovery Managerによって、一時的なバックアップ構成、ユーザー指定のリカバリ期間に基づくバックアップとアーカイブ・ログの自動管理、再起動可能なバックアップとリストア、テスト・リストア/リカバリが使用可能になります。 RMANでは、バックアップの存続期間を制御するリカバリ期間が実装されます。これにより、データベースまたは表領域のポイント・イン・タイム・リカバリを実行することで、論理エラーを検出して影響を受けるオブジェクトを修正するための期間を設定できます。また、Recovery Managerでは、リカバリ期間内にデータベースを特定の時点までリストアする上で不要になったバックアップは、自動的に期限切れになります。制御ファイルの自動バックアップでは、Recovery Managerリポジトリが使用不可能な場合にも、データベースをリストアまたはリカバリできます。
DBCAは、オンディスク・バックアップ手続きを自動的にスケジューリングできます。ユーザーに必要な唯一の作業は、自動バックアップを実行する時間枠を指定することです。リカバリに関連するすべてのファイルとアクティビティ用に統一されたOracleデータベース内の格納位置は、フラッシュ・リカバリ領域と呼ばれ、初期化パラメータDB_RECOVERY_FILE_DESTで定義できます。制御ファイル、アーカイブ・ログ・ファイル、フラッシュバック・ログ、Recovery Managerのバックアップなど、メディア障害からデータベースを完全にリカバリするために必要なファイルはすべて、フラッシュ・リカバリ領域の一部です。
Oracleデータベースのリカバリを高速化、単純化および自動化するには、フラッシュ・リカバリ領域に十分な領域を割り当てる必要があります。フラッシュ・リカバリは、この位置に格納されているファイルをインテリジェントな方法で実際に管理して、領域使用を最大にし、領域不足状況を可能なかぎり回避します。指定のRecovery Manager保存ポリシーに従って、フラッシュ・リカバリ領域では、その構成に基づいて不要になった古いバックアップやアーカイブ・ログが自動的に削除されます。
増分バックアップにより、前回のバックアップ以降に変更されたブロックのみをバックアップできます。ブロック・チェンジ・トラッキング機能が使用可能な場合、Oracle Databaseはすべてのデータベース変更の物理位置を記録します。Recovery Managerは、変更追跡ファイルを自動的に使用して、増分バックアップ時に読み取る必要があるブロックを判断し、そのブロックに直接アクセスしてバックアップします。これによって、日次バックアップに必要な時間が短縮され、ネットワークを介してバックアップを実行する際のネットワーク帯域幅を節約でき、バックアップ・ファイルの記憶域が削減されます。
増分バックアップを使用して、以前に作成されたバックアップを更新できます。次第に増加する更新されたバックアップを使用して、Recovery Managerの増分バックアップとデータファイルのイメージ・コピーをマージすると、増分バックアップで取得した変更を組み込んだ最新のバックアップを作成できます。データベース全体を繰返しバックアップする必要はありません。指定のデータベースに対して完全なデータベース・バックアップを1度作成し、その後は増分バックアップを使用することで、更新された完全なバックアップを保持できます。次第に増加する更新されたバックアップに基づくバックアップ方法によって、データベースのメディア・リカバリに必要な時間を最小限にできます。
Oracle Databaseでは、システム障害からの平均リカバリ時間（MTTR）を秒単位で指定することで、データベースの停止時間を適切に制御できます。ユーザーによるMTTRの指定と動的初期化パラメータを併用すると、データベースの可用性を改善できます。システム障害からのリカバリ所要時間に時間制限を設定すると、Oracle Databaseでは障害時にシステム上で実行されていたアプリケーション・アクティビティに関係なく、その時間内にシステムを再起動できることが自動的かつ透過的に確認されます。これにより、システム障害の発生後は最短時間で復旧できます。
オンライン・ログ・ファイルが小さいほど、DBWRでは増分チェックポイントが実行され、物理書込みが増えることになります。これはデータベースのランタイム・パフォーマンスを低下させる場合があります。また、FAST_START_MTTR_TARGETを設定すると、最小ログ・ファイル・サイズによってMTTRが必要とするよりも多くの増分チェックポイントが発生する場合があります。
ログ・ファイル・サイズ・アドバイザでは、現行のFAST_START_MTTR_TARGET設定とMTTR統計に基づいて最適の最小ログ・ファイル・サイズが決定されます。最小ログ・ファイル・サイズが最適とみなされるのは、FAST_START_MTTR_TARGETが必要とするよりも多数の増分チェックポイントを発生させない場合です。
MTTRアドバイザにより、余分な物理書込みに関して様々なMTTR設定がシステム・パフォーマンスに与える効果を評価できます。MTTRアドバイザが使用可能になっている場合は、システムで典型的なワークロードが実行された後に、V$MTTR_TARGET_ADVICEを問合せして、現行のMTTRでのキャッシュ書込み数に対する他のMTTR設定での予想キャッシュ書込み数の比率を表示できます。たとえば、比率1.2は、キャッシュ書込み数が20%増加することを示します。
様々なMTTR設定とそれに対応するキャッシュ書込み比を調べることで、リカバリおよびパフォーマンスのニーズに適合するMTTRの値を決定できます。V$MTTR_TARGET_ADVICEでも、直接の書込みなどの合計物理書込み数に関する比率と、読取りなどの合計I/Oに関する比率が表示されます。
Oracle Flashbackテクノロジによって、データを時間的な前後関係の中で表示できます。データベースがオンラインの間に、スキーマ・オブジェクトの過去のバージョンの問合せ、履歴データの問合せ、変更分析の実行、またはセルフサービスの修復を実施して、論理的な破損から情報をリカバリできます。
これによって、リカバリ方法とは変更されたデータの単なる操作となりました。エラーのリカバリにかかる時間は、誤りが作成された時間に等しくなります。
Oracle Enterprise Managerには、構成の変更や違いを検出し、強制的に最も効率的な構成パラメータ設定を規定する複数の強力な構成管理機能があります。これらの機能は、基礎となるホストおよびオペレーティング・システムにも適用されます。
Oracle Enterprise Managerは、最も効率的な方法によるパラメータ設定、セキュリティ設定、記憶域およびファイル領域の状況、および推奨機能の使用などについて、Oracleシステムすべての構成を継続的に監視します。基準に満たないシステムには、システム構成に固有の問題に関する詳細な説明とともに、フラグが自動的に設定されます。たとえば、自動UNDO管理やローカル管理表領域などの新しい機能を使用していない場合は、Oracle Enterprise Managerではそれらの機能を使用するようにアドバイスされます。システム構成の自動監視によって、最も効率的な構成管理が促進され、管理者のワークロードおよび可用性、パフォーマンスまたはセキュリティに関するリスクが軽減されます。
また、Oracle Enterprise Managerは、新しい重要なパッチ（セキュリティに関する重要なパッチなど）に関するアラートを発行し、そのパッチを必要とするすべてのシステムにフラグを設定します。さらに、インストールに使用可能な個別パッチを見つけるために、Oracle Enterprise Managerのパッチ・ウィザードを起動できます。
Oracle Databaseには、次のリソース管理機能があります。
データベース・リソース・マネージャには、Oracleデータベース・システム内での操作に優先順位を設定する機能が用意されています。オンライン・ユーザーについて応答時間を最短にするために、優先順位の高いコンシューマがリソースを取得しますが、バッチ・ジョブやレポートなど、優先順位の低いコンシューマの所要時間が長くなることがあります。このため、よりきめ細かいリソース制御が可能で、コンシューマ・グループについて自動コンシューマ・グループ切替え、アクティブ・セッションの最大数の制御、問合せ実行時間の見積りとUNDOプール割当て制限などの機能を提供します。
コンシューマ・グループごとに、同時にアクティブなセッションの最大数を指定できます。この制限に達すると、データベース・リソース・マネージャは以降の要求をすべてキューに入れ、それらの要求は既存のアクティブ・セッションが完了した後でのみ実行します。
データベース・リソース・マネージャを使用することで、オペレーティング・システムでは十分に管理できない次の多くのリソース割当ての問題が解決されます。
データベース・リソース・マネージャを使用して、次のことができます。
たとえば、データ・ウェアハウスでは、バッチ・ジョブよりもROLAP（リレーショナル・オンライン分析処理）アプリケーションに対するCPUの割合を高くする場合があります。共有記憶域が構成され、I/Oリソース管理が有効な場合は、データベースにより発行可能な1秒当たりの最大I/Oリクエスト数、または1秒当たりの最大MB数も設定できます。
このプールは、ユーザーが所属するグループ内で同時にアクティブになれるユーザー・セッションで指定された最大数で構成されます。最大数を超えるセッションは、実行待ちのキューに入りますが、キューに入れられたジョブが終了するまでのタイムアウト周期を指定できます。
特定のユーザー・グループのメンバーによって、実行時間、I/O使用量またはI/Oリクエスト数が指定された最大値を超えるセッションが作成された場合は、リソース要件の異なる別のユーザー・グループにセッションを自動的に切り替えることができます。
UNDOプールは、ユーザーが所属するグループが使用できるUNDO領域の総量からなります。
インスタンスを停止して再起動しなくても、セットアップ作業を業務時間中から夜間に変更するなど、方法を動的に変更できます。
企業全体の目標を達成するには、あるユーザーと他のユーザーが使用するリソースのバランスをとったり、処理に割り当てるシステム・リソースを重要度により分割します。
リソースは、データベース管理者が指定するリソース・プランに従ってユーザーに割り当てられます。次の用語は、リソース・プランを指定するのに使用します。
リソース・プランで、各ユーザー（リソース・コンシューマ・グループ）へのリソースの分配方法を指定します。
リソース・コンシューマ・グループを使用して、リソース要件ごとにユーザー・セッションをグループ化します。リソース・コンシューマ・グループは、ユーザー・ロールとは異なり、1人のデータベース・ユーザーが、異なるリソース・コンシューマ・グループに割り当てられた異なるセッションを持つことができます。
リソース割当て方法は、特定のリソースを割り当てる際に使用する方針を決めます。リソース割当て方法は、リソース・プランとリソース・コンシューマ・グループで使用されます。
リソース・プラン・ディレクティブは、各リソース割当て方法でパラメータを指定して、コンシューマ・グループを特定のプランに割り当て、コンシューマ・グループ間でリソースを分配するための手段です。
データベース・リソース・マネージャでは、プラン内にサブプランと呼ばれるプランも作成できます。サブプランでは、アプリケーションの複数のユーザー間でリソースをさらに副分割できます。
レベルは、利用可能なユーザー間で未使用のリソースの分配を指定するメカニズムを提供します。リソース割当ては、8レベルまで指定できます。
サービスとは、共通の属性、サービス・レベルのしきい値および優先順位を持つアプリケーション・グループまたは大規模なアプリケーションのサブセットを表します。アプリケーションの機能は、サービスで識別されるワークロードに分割できます。たとえば、Oracle E-Business Suiteでは、総勘定元帳、売掛管理、受注などのモジュールごとにサービスを定義できます。Oracle Mailでは、IMAPプロセス、ポストマン、ガベージ・コレクタ、モニターなどのサービスを定義できます。サービスの範囲は、Oracleデータベースまたはクラスタ内の複数データベースの1つ以上のインスタンスに及ぶことが可能です。また、1つのインスタンスで複数のサービスをサポートできます。
サービスを提供しているインスタンス数は、アプリケーションに対して透過的です。サービスは、競合するアプリケーションを管理するために単一のシステム・イメージを提供し、各ワークロードを1単位として管理できます。
中間層のアプリケーションおよびクライアントは、サービス名をTNS接続データの接続の一部として指定することで、サービスを選択します。たとえば、Webサーバーまたはアプリケーション・サーバーのデータ・ソースは、1つのサービスにルーティングするように設定されます。Net Easy*Connectionを使用すると、この接続に、サービス名とネットワーク・アドレスが含まれます。たとえば、サービス:IPのようになります。
スケジューラ、パラレル実行およびOracle Streams Advanced Queuingなど、サーバー側の作業では、サービス名がワークロード定義の一部として設定されます。スケジューラの場合、ジョブはジョブ・クラスに割り当てられ、ジョブ・クラスがサービス内で実行されます。パラレル実行およびパラレルDMLの場合は、問合せコーディネータがサービスに接続します。パラレル実行プロセスは、問合せの期間を通じてそのサービスを継承します。Oracle Streams Advanced Queuingの場合は、サービスを使用してストリーム・キューがアクセスされます。サービスのもとで実行中の作業は、サービスのしきい値と属性を継承し、サービスの一部として測定されます。
データベース・リソース・マネージャは、サービスをコンシューマ・グループおよび優先順位にバインドします。これによって、優先順位の順にデータベース内のサービスが管理されます。たとえば、優先順位の高いオンライン・ユーザーと優先順位の低い内部レポート・アプリケーションに対して個別のサービスを定義できます。同様に、ゴールド、シルバーおよびブロンズなどのサービスを定義して、同じアプリケーションの要求がサービスされる優先順位を設定できます。
システムに対して複数のサービスを計画する場合は、サービス間の相対優先順位を指定します。このようにして、データベース・リソース・マネージャは、最初に優先順位の最も高いサービスを処理し、次の優先順位のサービスが後に続くようにしています。
この項の内容は、次のとおりです。
AWRを使用すると、サービス用の新規集計ディメンションを使用してワークロードのパフォーマンスを分析できます。AWRは、すべてのサービスに関する応答時間とCPU使用メトリック、パフォーマンス統計とリソース統計の待機イベント、しきい値ベースのアラートおよびパフォーマンス索引を自動的にメンテナンスします。
サービス、モジュールおよび処理タグは、サーバーのサービス内で操作を識別します。（MODULEとACTIONはアプリケーションで設定されます。）エンド・ツー・エンドの監視で、サービス、モジュールおよび処理レベルによる集計とトレーシングを実行し、負荷が大きい操作を識別できます。Oracle Enterprise Managerは、応答時間とCPU使用のサービス品質しきい値を管理し、上位のサービスを監視し、各サービスで上位を占めるモジュールと処理へのドリルダウンを提供します。
AWRでは、サービス集計によるパフォーマンス管理は、セッションによる監視が意味を持たない場合に有意です。たとえば、接続プーリングまたはトランザクション処理モニターを使用するシステムでは、セッションが共有されるため、アカウンタビリティを実現するのは困難です。
サービス、モジュールおよび処理タグは、作業と処理フローを区別する大小の境界となります。この集計レベルにより、ともに実行されるSQLのグループを（サービス、モジュールおよび処理の各レベルで）チューニングできます。これらの統計は、サービス品質の管理、リソース使用の査定、サービス間の相対優先順位の調整、およびチューニングが必要な箇所の参照に使用できます。Oracle Real Application Clusters（Oracle RAC）を使用すると、現在のパフォーマンスに基づいて様々なインスタンス上でサービスをプロビジョニングできます。
接続時ルーチンとランタイム・ルーチンのアルゴリズムによって、サービスを提供しているインスタンス全体でワークロードのバランスが調整されます。サーバー側の接続ロード・バランシングのメトリックは、サービス・パフォーマンスを含めるように拡張されます。接続は、現在のサービス・パフォーマンスに従ってインスタンス全体で共有されます。ロード・バランシングにサービス・パフォーマンスを使用することで、サイズとワークロードが異なり、競合する優先順位を持つ複数のノードを解決できます。また、中断または障害が発生しているノードへの作業の送信を防止できます。
AWRは、サービス・パフォーマンスのメトリックを継続的に保持します。これらのメトリックは、中間層サーバーおよびTPモニターからのランタイム要求をOracle RACにルーティングする場合に使用できます。たとえば、Oracle JDBC接続プールは、サービスを提供しているインスタンスにランタイム要求をルーティングするときに、サービス・データを使用します。
Oracle RACは、サービスを使用して、割込みなしのデータベース操作を実現します。サービスは、Oracle RACをサポートする高可用性フレームワークであるOracle Clusterwareと緊密に統合されています。障害が発生すると、障害に影響されないノードおよびインスタンスで、割込みなしでサービスが続行されます。障害の影響を受けたサービスの要素は、Oracle Clusterwareによって速やかにリカバリされ、リカバリ・セッションは正常に稼働しているシステム全体で自動的にバランスが保たれます。
計画された休止の場合、Oracle RACには、サービスを再配置、使用禁止および使用可能にするためのインタフェースがあります。再配置は、サービスを別のインスタンスに移行し、必要な場合はセッションが切断されます。Oracle Clusterwareシステムが、メンテナンスまたは修復時に発生する予定外の障害に応答しないように、予定された休止の開始時に、メンテナンスが実行されるノードではサービスが使用禁止になります。サービスは、休止の終了時に使用可能になります。
サービス・ベースのこれらの操作をサービス・ベースのスキーマ・プリコンパイル（DBMS_SCHEMA_COPY）と組み合せることで、予定されている多数の休止による停止時間を最小限にします。たとえば、アプリケーションのアップグレード、オペレーティング・システムのアップグレード、ハードウェアのアップグレードや修理、ローリング・アップグレードが承認されたOracleのパッチ、およびパラメータの変更は、一度に1つ以上のサービスを分離して実装できます。
Oracle RACに組み込まれている継続的なサービスは、アプリケーションおよび中間層のサーバーにまで拡張されます。サービスの状態が変化（たとえば、起動、停止または再開不可）すると、新しいステータスがイベントおよびコールアウトを介して関連するサブスクライバに通知されます。アプリケーションは、障害を迅速に検出し、障害に対応する接続プールをバランシングし、障害の発生したコンポーネントが修復されたときに再度接続プールをバランシングするために、この通知を使用できます。たとえば、インスタンスでサービスを開始する場合は、ただちにそのサービスで作業をトリガーするためにイベントおよびコールアウトが使用されます。
インスタンスでサービスが停止すると、そのインスタンスでサービスを使用しているアプリケーションを中断するために、イベントが使用されます。通知を使用すると、TCPタイムアウトによるクライアントの待機を回避できます。イベントは、Oracle JDBC接続プール、Oracle Data Provider for .Net接続プール、および透過的アプリケーション・フェイルオーバー（TAF）などのOracle Call Interfaceに統合されます。
Oracle Data Guardを使用すると、本番サービスは本番サイトで提供されます。その他のスタンバイ・サイトでは、読取り専用モードでの動作中にレポート・サービスを提供できます。Oracle RACとData Guard Brokerの統合により、フェイルオーバー、スイッチオーバーおよび保護モードが変更されると、当初の本番サイトの本番サービスが解体され、新しい本番サイトに本番サービスが構築されます。サービスをローカルに管理するOracle Clusterwareと遷移を管理するData Guardの間では、コマンドの変更が制御されています。Data Guardの遷移が完了すると、Oracle Clusterwareは高可用性操作の管理を自動的に再開します。
|
関連項目
|
Oracle Databaseには、豊富な機能を備えたジョブ・スケジューラが組み込まれています。指定日時（平日の毎晩11:00など）または指定イベントの発生時（在庫が特定のレベルを下回ったときなど）に、実行するジョブをスケジューリングできます。会計四半期ごとの最後の勤務日などのカスタム・カレンダを定義できます。
DBMS_SCHEDULERパッケージまたはOracle Enterprise Managerを使用して、ジョブ、プログラムおよびスケジュールなどのスケジューラ・オブジェクトを作成および操作します。スケジューラ・オブジェクトは標準データベース・オブジェクトであるため、システム権限およびオブジェクト権限により、これらのオブジェクトへのアクセスを制御できます。
プログラム・オブジェクト（またはプログラム）には、引数のデフォルト値を含む、スケジューラで実行されるコマンドに関するメタデータが含まれます。スケジュール・オブジェクト（スケジュール）には、実行日時および反復パターンに関する情報が含まれます。ジョブ・オブジェクト（ジョブ）は、プログラムをスケジュールに対応付けるもので、スケジューラで操作する主要なオブジェクトです。同じプログラムを参照し、異なるスケジュールで実行される複数のジョブを作成できます。ジョブは、プログラム引数のデフォルト値を上書きする可能性があるため、複数のジョブが同じプログラムを参照できますが、異なる引数値を提供します。
スケジューラは、Oracle Enterprise ManagerおよびSQL*Plusから使用できる各種ビューで、ジョブの包括的なロギングを提供します。指定した状態変更が発生したときにイベントを発生させるジョブを構成できます。アプリケーションによりイベントを処理し、適切な処理を実行できます。たとえば、ジョブが異常終了した場合、スケジューラはDBAに電子メールをページングまたは送信できます。
スケジューラには連鎖も含まれています。連鎖とは、連携してタスクを実行する名前付きのステップのグループです。連鎖内の各ステップは1つのプログラム、副鎖またはイベントであり、各ステップが実行されるタイミングと、各ステップ間の依存性を決定するルールを指定します。連鎖の一例は、「プログラムAおよびBを実行します。ただし、プログラムAおよびBが正常に完了した場合のみプログラムCを実行し、それ以外の場合はプログラムDを実行します。」のようになります。
スケジューラはデータベース・リソース・マネージャに統合されています。スケジューラ・ジョブをリソース・コンシューマ・グループに対応付け、異なる時間に異なるリソース・プランを自動的にアクティブ化する、ウィンドウと呼ばれるスケジューラ・オブジェクトを作成できます。リソース・プランに変更がある場合、ジョブを実行すると、ジョブに割り当てられたリソース内の変更を参照できます。スケジューラ・ジョブでは、スケジューリングの際に、スケジュール・オブジェクトではなくウィンドウに名前を付けることができます。そのようなジョブは、名前付きのウィンドウが開かれる際に実行されます。また、ウィンドウはウィンドウ・グループにグループ化でき、スケジュール時にウィンドウ・グループに名前を付けることが可能です。そのようなジョブは、名前付きのウィンドウ・グループの任意のウィンドウが開かれる際に実行されます。
スケジューラには、企業向けの複雑なスケジューリング機能が用意されています。この機能を使用すると次の操作ができます。
ジョブ・スケジューラの最も基本的な機能は、ジョブの実行のスケジュールです。スケジューラでは、時間ベースとイベントベースの両方のスケジューリングがサポートされています。
時間ベースのスケジューリングを使用すると、ユーザーは固定した日時（2006年1月23日午前1時など）、繰返しスケジュール（毎週月曜日など）または定義済ルール（1か月おきの最終日曜日、感謝祭を定義する11月の第4木曜日など）を指定できます。
ユーザーは、既存のスケジュールを組み合せることで、最小限の労力で新しい複合スケジュールを作成できます。たとえば、休日および平日スケジュールがすでに定義されている場合、平日スケジュールから休日スケジュールを除外することで、勤務日スケジュールを簡単に作成できます。
企業では、通常のカレンダとは対照的に会計カレンダを使用する場合が多いため、会計四半期の最後の勤務日にジョブをスケジュールする必要があります。スケジューラでは、ユーザーが毎月最後の勤務日のみでなく、会計四半期ごとの最後の勤務日も定義できる、ユーザー定義の頻度がサポートされています。
イベントベースのスケジューリングでは、名前が意味するように、リアルタイムのイベントに基づいてジョブがトリガーされます。イベントは、ファイルの到着などシステムの状態の変化として定義されます。イベントに基づいてスケジューリングすると、ジョブを実行する日時について正確な時間が事前にわからない状況に対応できます。
スケジューラでは、シングルステップまたは複数ステップのジョブがサポートされています。複数ステップ・ジョブは、連鎖を使用して定義されます。連鎖は、依存性ルールを使用して結合された複数のステップで構成されます。各ステップはタスクを表すため、連鎖を使用すると、ユーザーはタスクAおよびタスクBが正常に完了した1時間後にタスクCを実行するなど、タスク間の依存性を指定できます。
スケジューラを使用すると、ビジネス要件をモデル化する方法でジョブを処理できます。限られたコンピューティング資源を競合するジョブ間で適切に割り当てることができるため、ビジネス・ニーズにあわせてジョブ処理を実行できます。共通の特性および動作を共有するジョブを、ジョブ・クラスと呼ばれる大きいエンティティにグループ化できます。クラス間の優先順位は、各クラスに割り当てるリソースを制御することで設定します。これにより、重要なジョブに優先順位が設定され、完了に必要となる十分なリソースが確実に割り当てられます。また、ジョブ・クラス内で各ジョブの優先順位を設定することも可能です。
スケジューラには、スケジュールに基づいて優先順位を変更する機能も用意されています。重要なジョブの定義は変化することがあるため、スケジューラを使用して随時異なるクラス優先順位を定義できます。
ジョブが作成されてから完了するまでには、複数の状態をたどります。すべてのスケジューラ・アクティビティは記録され、ジョブのステータスや完了時刻などの情報を容易に追跡できます。この情報はビューに格納されます。ビューの情報の問合せには、Oracle Enterprise ManagerまたはSQL問合せを使用できます。各ビューにはジョブとその実行に関する情報が表示され、ジョブの適切なスケジューリングと管理に役立ちます。たとえば、ユーザーscottに関して失敗したジョブをすべて容易に追跡できます。
ジョブの監視を容易にするために、ユーザーはスケジューラにフラグを設定して、予期しない動作が発生した場合にイベントを発生させ、指定したイベントが発生した場合に実行される処理を指定できます。たとえば、ジョブが失敗した場合、管理者に通知する必要があります。
クラスタとは、同じタスクを共同で実行するデータベース・インスタンスの集合です。Oracle Real Application Clustersは、アプリケーションを変更せずにスケーラビリティと信頼性を提供します。スケジューラは、このようなクラスタ環境におけるジョブの実行を全面的にサポートしています。システムの負荷バランスを調整してパフォーマンスを改善するために、ジョブを実行するサービスを指定することもできます。
|
 Copyright © 1993, 2008 Oracle Corporation. All Rights Reserved. |
|