| Oracle® Database概要 11gリリース2 (11.2) B56306-06 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
データベース管理者(DBA)の主要な役割は、企業データをユーザーに対して利用可能にすることです。DBAは、アプリケーションがデータベースを効率よく使用できるよう、開発者と緊密に連携する必要があり、また、物理リソースを適切に保ち、効率よく使用できるよう、システム管理者と緊密に連携する必要があります。
Oracle DBAは、Oracle Databaseアーキテクチャおよびデータベースの機能を理解している必要があります。DBAは、次のタスクを実行します。
Oracle Databaseソフトウェアのインストール、アップグレードおよびパッチ適用
要件の確認、論理設計(概念モデル)の作成および物理データベース設計を含む、データベースの設計
Oracle Databaseの作成
バックアップやリカバリ計画の開発およびテスト、Oracle Databaseの定期バックアップ、障害発生時のリカバリ
クライアントがデータベースに接続するためのネットワーク環境の構成
データベースの起動および停止
データベースの記憶域の管理
ユーザーおよびセキュリティの管理
表、索引、ビューなどのデータベース・オブジェクトの管理
データベースのパフォーマンスの監視およびチューニング
重大なデータベース・エラーが発生した場合の調査、診断データの収集、Oracleサポート・サービスへの報告
新しいデータベース機能の評価およびテスト
前述のタスク、および他の多くのタスクの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。
ユーザーのタイプ、ロール、および責任は、データベース環境によって決まります。小規模なデータベースでは、DBAが1人の場合があります。一方、非常に大規模なデータベースでは、セキュリティ管理者、バックアップ・オペレータ、アプリケーション管理者など、複数のスペシャリストがDBAの仕事を分担する場合があります。
Oracleでは、データベースを管理するためのいくつかのツールを提供しています。この項では、一般的に使用される次のツールについて説明します。
Oracle Enterprise Manager(Enterprise Manager)は、データベース環境を集中管理するためのシステム管理ツールです。Enterprise Managerは、グラフィカル・コンソール、Oracle Management Server、Oracle Intelligent Agent、共通サービスおよび管理ツールを組み合せることで、Oracle製品の包括的なシステム管理プラットフォームを提供します。
WebベースのEnterprise Manager Database Control(Database Control)は、Oracle Database管理における主要ツールです。このツールは、Oracle Databaseとともにインストールされます。Database Controlを使用すると、次のような管理タスクを実行できます。
データベースの診断、変更およびチューニング
管理タスクを容易にするための関連ターゲットのグループ化、他の管理者とのタスクの共有、様々な時間間隔でのタスクのスケジューリング
OracleホームへのOracle Net Servicesの構成および管理(「Oracleネットワーク・アーキテクチャの概要」を参照)
統合されたOracleおよびサード・パーティ製のツールの起動
下図に、Database Controlのデータベース・ホームページを示します。ページ上部に配列されたサブページ・リンクを使用すると、パフォーマンス、可用性およびその他のデータベース管理ページにアクセスできます。データベース・ホームページのサブセクションには、データベースの環境および状態に関する情報が表示されます。
次の図に、Enterprise Managerの基本アーキテクチャを示します。管理リポジトリはデータベースに格納されます。エージェントと管理サービスは両方ともデータベースのホスト上で実行されます。Database Control Consoleは、管理サービスにセキュアに接続できる任意のWebブラウザから実行できます。
|
関連項目: Enterprise Managerを使用したデータベースの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。 |
SQL*Plusは、すべてのOracle Databaseのインストール時に含まれる、対話型のバッチ問合せツールです。このツールには、データベースへの接続時にクライアントとして機能する、コマンドライン・ユーザー・インタフェースがあります。
SQL*Plusは独自のコマンドと環境を持っています。ここでは、SQL、PL/SQL、SQL*Plus、オペレーティング・システム・コマンドを入力および実行し、次のタスクを実行できます。
問合せ結果の書式設定、計算の実行、保存および印刷
表定義およびオブジェクト定義の検証
バッチ・スクリプトの開発および実行
データベースの管理
SQL*Plusを使用して、対話的なレポート生成、バッチ処理としてのレポート生成、およびテキスト・ファイル、スクリーンまたはインターネットでの閲覧用のHTMLファイルへの結果の出力が可能です。HTML出力機能を使用するとレポートを動的に生成できます。
|
関連項目: SQL*Plusの詳細は、『Oracle Database 2日でデータベース管理者』および『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。 |
Oracleでは、Oracle Databaseソフトウェアのインストール・タスクおよび構成タスクを簡略化するためのいくつかのツールを提供しています。これらのツールは次のとおりです。
Oracle Universal Installer(OUI)
OUIは、Oracle Databaseソフトウェアを表示、インストールおよびアンインストールするためのGUIユーティリティです。オンライン・ヘルプがあり、ガイドに従ってインストールできます。Oracle Databaseソフトウェアのインストール方法の詳細は、『Oracle Databaseインストレーション・ガイド』を参照してください。
Database Upgrade Assistant(DBUA)
DBUAを使用すると、対話形式のガイドに従ってデータベースをアップグレードし、新規リリースに応じてデータベースを構成できます。DBUAでは、通常は手動で実行されるタスクをすべて実行することによって、アップグレードを自動化します。DBUAでは、表領域やオンラインREDOログなどの構成オプションに対して推奨設定を作成します。DBUAを使用したデータベースのアップグレード方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
Database Configuration Assistant(DBCA)
DBCAには、データベースを作成し、構成するためのグラフィカル・インタフェースおよびガイド付きワークフローが用意されています。このツールを使用すると、Oracle提供のテンプレートからデータベースを作成したり、独自のデータベースやテンプレートを作成できます。DBCAを使用したデータベースの作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle Net Servicesにより、分散、異機種間コンピューティング環境において、企業全体の接続性が確保されます。Oracle NetはOracle Net Servicesのコンポーネントであり、クライアント・アプリケーションからデータベースへのネットワーク・セッションも確立できます。次のツールを使用して、Oracle Net Servicesを構成および管理できます。
Oracle Net Manager
このツールを使用すると、ローカル・クライアントまたはサーバー・ホスト上のOracleホームにOracle Net Servicesを構成できます。Oracle Net Managerを使用して、ネーミング、ネーミング・メソッド、プロファイルおよびリスナーを設定できます。Oracle Net Managerは、Oracle Enterprise Manager Consoleを使用して起動するか、独立したアプリケーションとして起動できます。
Oracle Net Configuration Assistant
このツールは、ソフトウェアのインストール時に自動的に実行されます。Oracle Net Configuration Assistantでは、リスナー名、プロトコル・アドレス、ネーミング・メソッド、tnsnames.oraファイル内のネット・サービス名、ディレクトリ・サーバーの使用などの基本ネットワーク・コンポーネントをインストール時に構成できます。
リスナー制御ユーティリティ
リスナー制御ユーティリティを使用すると、クライアント接続を受信するリスナーを構成できます(「Oracle Net Listener」を参照)。ユーティリティには、Enterprise Managerから、またはスタンドアロンのコマンドライン・アプリケーションとしてアクセスできます。
Oracle Connection Manager制御ユーティリティ
このコマンドライン・ユーティリティを使用すると、Oracle Connection Manager(ルーターの一種で、クライアント接続リクエストは、このルーターを経由して次のホップに送信されたり、データベースに直接送信されます)を管理できます。ユーティリティ・コマンドを使用して、基本的な管理機能を1つ以上のOracle Connection Managerに対して実行できます。さらに、パラメータの設定を表示および変更できます。
|
関連項目:
|
Oracle Databaseでは、データベースでの移動および分析を支援するいくつかのユーティリティを提供しています。たとえば、データベース・ユーティリティを使用して、次のことを実行できます。
オペレーティング・システム・ファイルからOracle Database表へのデータのロード(「SQL*Loader」を参照)
一方のデータベースから他方のデータベースへのデータおよびメタデータの移動(「Oracle Data Pumpエクスポートおよびインポート」を参照)
SQLインタフェースを介したREDOログ・ファイルの問合せ(「Oracle LogMiner」を参照)
Oracle Database診断データの管理(「ADRコマンド・インタプリタ(ADRCI)」を参照)
その他のタスクには、DBVERIFYユーティリティを使用したオフライン・データベースまたはデータファイルに対する物理データ構造の整合性チェックの実行や、DBNEWIDユーティリティを使用した運用データベースのデータベース識別子(DBID)またはデータベース名の変更などがあります。
|
関連項目: DBVERIFYおよびDBNEWIDの詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
SQL*Loaderは、データファイルと呼ばれる外部ファイルからデータベース表にデータをロードします。強力なデータ解析エンジンによって、あらゆるデータ形式のデータファイルに対応できます。SQL*Loaderでは、次のタスクを実行できます。
複数のデータファイルから複数の表へのデータのロード
ロードするデータは、SQL*Loaderデータファイルに格納します。SQL*Loader制御ファイルはテキスト・ファイルであり、このファイルには、SQL*Loaderがデータの格納場所、解析方法、解釈方法、挿入場所などを決定するときに使用するDDL命令が含まれています。
ロード操作の様々な制御
たとえば、データの選択的なロード、データのキャラクタ・セットの指定(「キャラクタ・セット」を参照)、SQL関数によるデータの操作、指定の列への一意のシーケンシャル・キー値の生成が可能です。また、複雑なエラー・レポートも生成できます。
従来型パスによるロードまたはダイレクト・パス・ロード
従来型パスによるロードでは、表にデータを移入するときにSQL INSERT文を実行します。一方、ダイレクト・パス・ロードでは、データ・ブロックをフォーマットし、それをデータベース・ファイルに直接書き込むことによって、データベースのオーバーヘッドを大幅に軽減します。直接書き込む場合は、最高水位標よりも高いブロックで処理され、データベース・バッファ・キャッシュを経由せずに、ディスクに直接書き込まれます。直接読み取る場合も、バッファ・キャッシュを経由せずに、ディスクからPGAに直接読み取ります。
典型的なSQL*Loaderセッションは、SQL*Loader制御ファイルと1つ以上のデータファイルを入力として使用します。出力は、Oracle Database、ログ・ファイル、不良ファイル、および存在する場合は廃棄ファイルです。図18-1に、典型的なSQL*Loaderセッションのフローを示します。
|
関連項目: SQL*Loaderの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseユーティリティ』を参照してください。 |
Oracle Data Pumpにより、データベース間でデータとメタデータを高速で移動できます。このテクノロジは、次のOracle Databaseデータ移動ユーティリティのベースとなります。
データ・ポンプ・エクスポート(エクスポート)
エクスポートは、データとメタデータをダンプ・ファイル・セットと呼ばれる一連のオペレーティング・システム・ファイルにアンロードするユーティリティです。ダンプ・ファイル・セットは、表データ、データベース・オブジェクトのメタデータおよび制御情報を含む1つ以上のバイナリ・ファイルから構成されています。
データ・ポンプ・インポート(インポート)
インポートは、エクスポートされたダンプ・ファイル・セットをデータベースにロードするユーティリティです。また、インポートを使用すると、ソース・データベースから中間ファイルなしで宛先データベースに直接ロードすることができ、エクスポート操作とインポート操作を同時に実行することで全体の所要時間が短縮されます。
Oracle Data Pumpは、次のような部分から構成されています。
expdpおよびimpdpコマンドライン・クライアント
これらのクライアントは、DBMS_DATAPUMPパッケージに対してコールし、Oracle Data Pump操作を実行します(「PL/SQLパッケージ」を参照)。
DBMS_DATAPUMP PL/SQLパッケージ(データ・ポンプAPIとも呼ばれる)
このAPIによって、高速でインポートおよびエクスポートされます。
DBMS_METADATA PL/SQLパッケージ(メタデータAPIとも呼ばれる)
このAPIには、オブジェクト定義がXML形式で格納されており、メタデータのすべてのロードおよびアンロード・プロセスで使用されます。
図18-2に、Oracle Data PumpをSQL*Loaderおよび外部表と統合する方法を示します。図に示すように、SQL*Loaderは外部表APIおよびデータ・ポンプAPIに統合され、データを外部表にロードします(「外部表」を参照)。Database Controlなどのクライアントおよびトランスポータブル表領域は、Oracle Data Pumpインフラストラクチャを使用できます。
|
関連項目:
|
Oracle LogMinerを使用すると、SQLインタフェースを介してREDOログ・ファイルを問い合せることができます。REDOログ・ファイルに含まれるデータの使用方法を次に示します。
アプリケーション・レベルで発生したエラーなど、データベースの論理的な破損の開始時点を特定します。
ユーザー・エラーを検出します。
トランザクション・レベルでファイングレイン・リカバリを実行するために必要な操作を判断します。
傾向分析を使用して、更新および挿入頻度の最も高い表を判断できます。
REDOログ・ファイルに対するLogMinerの包括的なリレーショナル・インタフェースを使用して、システムの動作を分析し、データベースの使用状況を監査します。
LogMinerには、コマンドライン・インタフェースまたはEnterprise Managerの一部であるOracle LogMiner Viewer GUIを介してアクセスできます。
|
関連項目: LogMinerの詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
ADRCIは、問題の調査、ヘルス・チェック・レポートの表示、新たな障害の診断データのパッケージおよびそのOracleサポートへのアップロードに使用するコマンドライン・ユーティリティです。また、このユーティリティでは、自動診断リポジトリ(ADR)内のトレース・ファイル名やアラート・ログを表示できます。ADRCIには、対話形式またはスクリプトで使用できる豊富なコマンド・セットが用意されています。
第17章では、開発者とDBAの両方にとって重要なトピックについて説明します。この項では、他の箇所で説明されていないDBAに不可欠なトピックについて説明します。
この項には次のトピックが含まれます:
バックアップおよびリカバリとは、メディア障害またはユーザー・エラーによるデータ損失からのデータベース保護に関連する、一連の概念、プロシージャ、計画です。一般的に、バックアップおよびリカバリ計画の目的は、データベースをデータ損失から保護し、失われたデータを再構築することです。
バックアップとは、データのコピーです。バックアップには、データファイル、サーバー・パラメータ・ファイル、制御ファイルなど、データベースの重要な部分を含めることができます。バックアップおよびリカバリが必要になる一例として、ディスク・ドライブの障害によりデータファイルが失われた場合などがあります。失われたファイルのバックアップが存在する場合は、ファイルをリストアおよびリカバリできます。メディア・リカバリとは、データの損失が発生する前の状態へのリストアにかかわる操作を意味します。
|
関連項目: バックアップとリカバリの概念およびタスクの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
次の方法を使用すると、Oracle Databaseをバックアップおよびリカバリできます。
RMANは、Oracle Databaseと統合し、バックアップおよびリカバリ・アクティビティを実行するためのOracle Databaseユーティリティで、たとえば、履歴バックアップ・メタデータのリポジトリをバックアップ対象のすべてのデータベースの制御ファイルに保持できます。RMANでは、リカバリ・カタログと呼ばれる集中管理されるバックアップ・リポジトリを別のデータベースに保持することもできます。RMANはOracle Databaseの機能であるため、別途インストールする必要はありません。
RMANは、Oracle Secure Backupと統合されており、Oracle Secure Backupを使用すると、ファイルシステム・データおよびOracle Databaseファイルを保護する、信頼性の高いテープ・バックアップの集中管理が可能となります。Oracle Secure Backup SBTインタフェースでは、RMANを使用したデータベース・ファイルのテープおよびAmazon S3などのインターネット・ベースのWebサービスへのバックアップ、およびこれらの媒体からのデータベース・ファイルのリストアが可能になります。Oracle Secure Backupでは、SANおよびSCSI環境のほとんどすべてのテープ・ドライブおよびテープ・ライブラリがサポートされています。
RMANおよびOracle Secure Backupには、コマンドラインとEnterprise Managerの両方からアクセスできます。
ユーザーによる管理方法
RMANを使用するかわりに、バックアップおよびファイルのリストアの場合はLinuxのddコマンド、メディア・リカバリの場合はSQL*PlusのRECOVERコマンドなど、オペレーティング・システムのコマンドを使用できます。Oracleでは、ユーザー管理のバックアップおよびリカバリが全面的にサポートされていますが、RMANの方がOracle Databaseと統合されており、管理が簡素化されているため、RMANを使用することをお薦めします。
図18-3に、基本的なRMANアーキテクチャを示します。Enterprise Managerからアクセス可能なRMANクライアントは、ターゲット・データベースのサーバー・セッションを使用して、データをディスクまたはテープにバックアップします。RMANは、外部にあるリカバリ・カタログをバックアップ・メタデータで更新できます。
どちらのバックアップおよびリカバリ方法を使用する場合でも、高速リカバリ領域を構成することをお薦めします。このデータベースによって管理されるディレクトリ、ファイルシステムまたはOracle ASMディスク・グループは、アクティブな制御ファイル、オンラインおよびアーカイブREDOログ・ファイル、バックアップなどのバックアップ・ファイルおよびリカバリ・ファイルを一元化します。Oracle Databaseのリカバリ・コンポーネントは、高速リカバリ領域と対話し、データベースのリカバリ可能性を保証します。
|
関連項目:
|
データベース・バックアップは、物理または論理のいずれかです。物理バックアップはバックアップおよびリカバリ方針の中心概念であり、物理データベース・ファイルのコピーです。物理バックアップを作成するには、RMANユーティリティを使用する方法と、オペレーティング・システムのユーティリティを使用する方法があります。
これに対して、論理バックアップには、表やストアド・プロシージャなどの論理データが含まれます。Oracle Databaseのデータ・ポンプ・エクスポートなどのユーティリティを使用し、論理データを抽出してバイナリ・ファイルに格納できます。論理バックアップは、物理バックアップを補足できます。
物理バックアップは粒度が粗く、トランスポータビリティが制限されていますが、非常に高速です。論理バックアップは粒度が細かく、トランスポータビリティは完全ですが、物理バックアップより低速です。
|
関連項目: 物理バックアップおよび論理バックアップの概要は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
データベース全体のバックアップとは、データベース内の各データファイルと制御ファイルのバックアップのことです。これは最も一般的なタイプのバックアップです。
部分データベース・バックアップには、個々の表領域またはデータファイルであるデータベースのサブセットが含まれます。表領域バックアップとは、1つまたは複数の表領域内のすべてのデータファイルのバックアップのことです。一貫性の有無にかかわらず、表領域バックアップが有効なのは、データベースがARCHIVELOGモードで稼働している場合のみで、これは、リストア後の表領域とデータベースの他の領域との一貫性を保つにはREDOが必要となるためです。
データベース全体のバックアップは、一貫性バックアップか非一貫性バックアップのいずれかです。一貫性バックアップでは、すべての読取り/書込みデータファイルおよび制御ファイルのチェックポイントSCNが同じであり、このSCNまでのすべての変更が確実にこれらのファイルに格納されます。このタイプのバックアップでは、リストア後にリカバリする必要はありません。
データベースの一貫性バックアップは、一貫性が保たれた状態で停止した後にのみ実行でき(「停止モード」を参照)、NOARCHIVELOGモードで稼働しているデータベースで有効な唯一のバックアップ・オプションです。他のバックアップ・オプションでは、一貫性のためメディア・リカバリを必要としますが、これはアーカイブREDOログ・ファイルを適用しなければ不可能です。
|
注意: REDOを適用せずにデータベース全体の一貫性バックアップをリストアすると、バックアップ後に実行されたトランザクションはすべて失われます。 |
非一貫性バックアップでは、読込み/書込みデータファイルおよび制御ファイルのチェックポイントSCNが同じであるという保証はなく、変更が失われる場合があります。バックアップを実行している間もデータファイルが変更されることがあるため、すべてのオンライン・バックアップは必然的に非一貫性です。
データベースを完全保護するバックアップの作成にデータベースを停止する必要がないため、非一貫性バックアップには優れた可用性があります。ARCHIVELOGモードでデータベースを実行する場合、アーカイブREDOログおよびデータファイルをバックアップする場合は、非一貫性バックアップを堅実なバックアップおよびリカバリ計画の基礎とできます。
|
関連項目: 非一貫性バックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
RMANのBACKUPコマンドでは、イメージ・コピーまたはバックアップ・セットが生成されます。イメージ・コピーとは、データファイル、制御ファイルまたはアーカイブREDOログ・ファイルをビット単位でディスク上に複製したものです。オペレーティング・システムのユーティリティまたはRMANを使用して物理ファイルのイメージ・コピーを作成し、いずれかのツールを使用してファイルをリストアできます。
|
注意: オペレーティング・システムによるコピーとは異なり、RMANではファイル内のブロックが検証され、イメージ・コピーがRMANリポジトリに記録されます。 |
RMANは、バックアップ・セットと呼ばれる独自の形式のバックアップを作成することもできます。バックアップ・セットには、1つ以上のデータファイル、アーカイブREDOログ・ファイル、制御ファイル、または1つのサーバー・パラメータ・ファイルからのデータが格納されます。バックアップ・セットの最小単位は、バックアップ・ピースと呼ばれるバイナリ・ファイルです。バックアップ・セットは、RMANがテープ・ドライブなどのシーケンシャル・デバイスへバックアップを書き込むための唯一の方法です。
バックアップ・セットを使用すると、テープ・デバイスが連続して動作できるようになります。たとえば、RMANでは、低速、中速および高速の各ディスクのブロックを1つのバックアップ・セットに結合することにより、テープ・デバイス内の入力ブロックを一定に保つことができます。ディスクのイメージ・コピーは、段階的な更新や所定の位置でのリカバリが可能であるため、役に立ちます。
|
関連項目: バックアップ・セットおよびイメージ・コピーの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
データベースの通常の機能が停止するような問題、およびI/O処理に影響を及ぼす問題は数多くありますが、一般的に、DBAが介入してデータを修復する必要があるのは次の場合のみです。
メディア障害
メディア障害は、データベース外部の問題により、データベースでファイルの読取りまたは書込みができない場合に発生します。一般的なメディア障害には、ヘッド・クラッシュなどの物理的な障害、およびデータベース・ファイルの上書き、削除または破損が含まれます。メディア障害は、ユーザーまたはアプリケーションのエラーより頻度は低いですが、リカバリ計画を堅実にするには、これに備えておく必要があります。
ユーザー・エラー
不適切な更新、表の内容の削除またはデータベース・オブジェクトの削除など、ユーザーまたはアプリケーションによって、データベースに不要な変更が加えられる場合があります(「人為的エラー」を参照)。適切なバックアップおよびリカバリ計画では、データベースの可用性に対する影響を最小化し、DBAの労力を最低限に抑えて、必要な状態にデータベースを戻すことができます。
一般的に、これらの問題の解決方法は複数あります。この項では、これらの解決方法について説明します。
|
関連項目: データ修復の概念の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
データ・リカバリ・アドバイザ・ツールは、データ障害を自動的に診断して、適切な修復オプションを提示し、ユーザーのリクエストに基づいて修復を実行します。データ・リカバリ・アドバイザは、自動データ修復用の集中管理ツールを提供することによって、Oracle Databaseの管理性および信頼性を向上し、リカバリ時間を短縮します。
データベースには、状態モニターと呼ばれる、診断チェックを実行するためのフレームワークがあります。チェッカは、データベースまたはそのコンポーネントの状態を評価するために状態モニターに登録されている診断操作またはプロシージャです。状態評価はデータ整合性チェックとも呼ばれ、対処的または予防的に起動できます。
障害とは、データ整合性チェックにより検出される永続的なデータ破損のことです。障害は通常、対処的に検出されます。破損データが関与するデータベースの操作はエラーとなりますが、これにより自動的にデータ整合性チェックが起動され、エラーに関連する障害がないかデータベースが検索されます。障害が診断された場合、その障害はデータベースにより自動診断リポジトリ(ADR)に記録されます。
障害がデータベースにより検出され、ADRに保存されると、データ・リカバリ・アドバイザは最善の修復オプションおよびデータベースへの影響を自動的に判断します。通常、データ・リカバリ・アドバイザは、それぞれの障害または障害グループに対して手動および自動の両方の修復オプションを生成します。
データ・リカバリ・アドバイザは、自動修復オプションを提示する前に、修復を完了するために必要なメディア・コンポーネントが使用可能かどうか、およびそのオプションが特定の環境に適しているかどうかを検証します。自動修復を選択すると、Oracle Databaseによって自動的に修復されます。データ・リカバリ・アドバイザ・ツールは、修復の成功を確認し、該当する障害をクローズします。
|
関連項目: データ・リカバリ・アドバイザの使用方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Oracle Databaseでは、Oracle Flashbackテクノロジと呼ばれる機能グループが提供されており、バックアップをリストアせずに、過去のデータの状態を表示したり、特定の時間に応じてデータを前後に巻き戻すことができます。データベースの変更内容にもよりますが、フラッシュバック機能では、メディア・リカバリよりも迅速に、可用性に及ぼす影響も少なく、不要な変更を元に戻すことができます。
バックアップおよびリカバリに最適なフラッシュバック機能には、次のものがあります。
フラッシュバック・データベース
Oracle Databaseを以前の時点まで巻き戻し、論理データの破損やユーザー・エラーによる問題を解決できます。フラッシュバック・データベースは、Data Guard、データ・リカバリ・アドバイザの補完、およびクローン・データベースの同期化にも使用できます。フラッシュバック・データベースではファイル上でメディア・リカバリはリストアまたは実行されないため、これを使用してディスク・クラッシュなどのメディア障害を修正することはできません。
フラッシュバック表
1つのSQL文で、指定した時点まで表を巻き戻しできます。表データとともに、関連する索引、トリガーおよび制約をリストアでき、データベースはオンライン状態で、指定された表に対する変更のみが取り消されます。フラッシュバック表は、不良ディスクやデータ・セグメントと索引の非一貫性など、物理的な破損には対応していません。
フラッシュバック・ドロップ
DROP TABLE操作の効果を無効にできます。フラッシュバック・ドロップは、ポイント・イン・タイム・リカバリなどのリカバリ・メカニズムより大幅に高速であり、最近のトランザクションの損失や停止時間も発生しません。
|
関連項目:
|
ブロック破損とは、認識されているOracle形式ではないデータ・ブロック、または内容の一貫性が内部で保たれていないデータ・ブロックです(「データ破損」を参照)。ブロック・メディア・リカバリは、データファイルをオンラインの状態に保ったまま、破損データ・ブロックをリストアしてリカバリするテクニックです。破損が少数のブロックのみに限定されている場合は、データファイル・リカバリよりもブロック・リカバリが適しています。
|
関連項目: ブロック・メディア・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
データファイル・リカバリは、消失または破損した現行のデータファイルまたは制御ファイルを修復します。また、表領域がOFFLINE NORMALオプションを設定せずにオフラインになったときに消失した変更をリカバリします。
データファイルまたは制御ファイルのバックアップをリストアする場合、またはデータファイルがOFFLINE NORMALオプションを設定せずにオフラインになった場合は、メディア・リカバリが必要です。オンライン・データファイルのメディア・リカバリが必要な場合は、データベースをオープンできず、また、メディア・リカバリが完了するまでは、メディア・リカバリを必要とするデータファイルはオンライン化できません。
データファイルまたは制御ファイルの物理バックアップのリストアとは、それを再構築してOracle Databaseで使用可能にすることです。バックアップのリカバリとは、アーカイブREDOログ・ファイルを適用することで、消失した変更を再構築することです。RMANでは、前回のバックアップ後に変更されたブロックのみを含む増分バックアップを使用して、データファイルをリカバリすることもできます。
変更がオンライン・ファイルに自動的に適用されるインスタンス・リカバリとは異なり、メディア・リカバリでは、ユーザーによる起動が必要であり、リストアされたバックアップにアーカイブREDOログ・ファイルが適用されます。データファイルのメディア・リカバリは、オフライン・データファイルか、インスタンスによりオープンされていないデータベースのデータファイルにのみ機能します。
データファイル・メディア・リカバリは、すべての変更を適用するかどうかで異なります。
完全リカバリ
完全リカバリでは、アーカイブ・ログとオンライン・ログに含まれるREDO変更すべてがバックアップに適用されます。通常、完全メディア・リカバリは、メディア障害によりデータファイルまたは制御ファイルが破損した後に実行します。完全リカバリは、データベース、表領域またはデータファイルに対して実行できます。
不完全リカバリ
不完全リカバリはデータベース・ポイント・イン・タイム・リカバリとも呼ばれ、データベースの以前のバージョンを生成します。この場合、リストアされたバックアップ以後に生成されたREDOすべてを適用するわけではありません。通常、データベースのポイント・イン・タイム・リカバリは、フラッシュバック・データベースを使用できないときにユーザー・エラーを取り消す場合に実行します。
不完全リカバリを実行するには、リカバリが必要な時点より前に作成されたバックアップからデータファイルをすべてリストアし、リカバリの完了時にRESETLOGSオプションを指定してデータベースをオープンする必要があります。ログをリセットすると、新しくログ順序1からログ順序番号のストリームが開始します。
|
注意: 現行のデータファイルが利用可能な場合は、DBPITRのかわりにフラッシュバック・データベースを使用できます。 |
表領域のポイント・イン・タイム・リカバリ(TSPITR)機能を使用すると、1つ以上の表領域をデータベースの残りの部分より古い時点までリカバリできます。
|
関連項目:
|
メモリー管理では、データベースの変化に応じて、Oracleインスタンスのメモリー構造を最適なサイズに維持します。初期化パラメータ設定により、SGAおよびインスタンスPGAメモリーの管理方法が決まります。
図18-4に、メモリー管理オプションのディシジョン・ツリーを示します。次の各項では、各オプションの詳細を説明します。
自動メモリー管理では、Oracle DatabaseによりSGAおよびインスタンスPGAメモリーが完全に自動管理されます。最もシンプルなこの方法を使用することをお薦めします。
ユーザー指定の制御は、ターゲット・メモリー・サイズ初期化パラメータ(MEMORY_TARGET)と、オプションの最大メモリー・サイズ初期化パラメータ(MEMORY_MAX_TARGET)のみです。Oracle Databaseは、ターゲット・メモリー・サイズに自動的にチューニングし、必要に応じて、SGAとインスタンスPGA間でメモリーを再配布します。
図18-5に、オンライン・ユーザーにより発行されたジョブを必要に応じて処理したり、バッチ・ジョブを処理するデータベースを示します。自動メモリー管理を使用すると、データベースは実行するジョブのタイプに応じて、自動的にラージ・プールとデータベース・バッファ・キャッシュのサイズを調整します。
DBCAを使用してデータベースを作成し、基本インストール・オプションを選択した場合、デフォルトでは自動メモリー管理が有効化されます。
|
関連項目: 自動メモリー管理の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。 |
自動メモリー管理が有効でない場合、システムはSGAに共有メモリー管理を使用します。共有メモリー管理では、次のいずれかのモードを選択できます。
自動共有メモリー管理
このモードは、自動メモリー管理が無効になっている場合のデフォルトで、SGAのサイズをより直接的に制御できます。データベースは、SGAの合計サイズをターゲット・サイズにチューニングし、動的にSGAコンポーネントのサイズをチューニングします。サーバー・パラメータ・ファイルを使用すると、自動的にチューニングされたコンポーネントのサイズが、インスタンスを停止した後もOracle Databaseに記憶されます。
手動共有メモリー管理
このモードでは、個々のSGAコンポーネントのサイズをいくつか設定し、処理ごとに個々のSGAコンポーネントを手動でチューニングします。個々のSGAコンポーネントのサイズを完全に制御できます。自動メモリー管理および自動共有メモリー管理が両方とも無効になっている場合は、このモードがデフォルトになります。
|
注意: 自動メモリー管理が無効になっている場合、データベースはユーザー・ワークロードに応じて共有プールとバッファ・キャッシュの相対サイズを自動的に調整することがあります。 |
|
関連項目: 共有メモリー管理の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。 |
自動メモリー管理が有効でない場合、PGAメモリー管理に次のモードを選択できます。
自動PGAメモリー管理
自動メモリー管理が無効で、PGA_AGGREGATE_TARGETが0(ゼロ)以外の値に設定されている場合、データベースは自動PGAメモリー管理を使用します。このモードでは、PGA_AGGREGATE_TARGETによってインスタンスPGAのターゲット・サイズが指定されます。データベースは、ターゲットに対してインスタンスPGAのサイズをチューニングし、個々のPGAのサイズを動的にチューニングします。ターゲット・サイズを明示的に設定しない場合は、適切なデフォルト値がデータベースによって自動的に構成されます。
手動PGAメモリー管理
自動メモリー管理が無効で、PGA_AGGREGATE_TARGETが0(ゼロ)に設定されている場合、手動PGA管理がデフォルトになります。Oracle Databaseの以前のリリースでは、DBAが作業領域の最大サイズをSQL演算子(ソートやハッシュ結合など)のタイプごとに手動で指定する必要がありました。しかし、ワークロードは常に変化するため、この技法は非常に困難であることがわかりました。Oracle Databaseでは手動によるPGAメモリー管理もサポートされていますが、自動メモリー管理を使用することをお薦めします。
|
関連項目: PGAメモリー管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
表18-1で、各メモリー管理方法を説明します。自動メモリー管理を有効化しない場合は、SGAおよびPGAのそれぞれに対して個別にメモリー管理方法を構成する必要があります。
|
注意: 自動メモリー管理を有効化しない場合、インスタンスPGAに対しては自動PGAメモリー管理がデフォルトの方法となります。 |
図18-1 メモリー管理方法
| インスタンス | SGA | PGA | 説明 | 初期化パラメータ |
|---|---|---|---|---|
|
自動 |
N/A |
N/A |
1つのインスタンス・ターゲット・サイズに基づいてインスタンスのサイズがチューニングされます。 |
設定項目:
|
|
N/A |
自動 |
自動 |
SGAはSGAターゲットに基づいて自動的にチューニングされます。 PGAはPGAターゲットに基づいて自動的にチューニングされます。 |
設定項目:
|
|
N/A |
自動 |
手動 |
SGAはSGAターゲットに基づいて自動的にチューニングされます。 PGAは各タイプのSQL演算子の作業領域の最大サイズを指定し、手動で制御します。 |
設定項目:
|
|
N/A |
手動 |
自動 |
SGAは個々のコンポーネント・サイズを設定し、手動で制御します。 PGAはPGAターゲットに基づいて自動的にチューニングされます。 |
設定項目:
|
|
N/A |
手動 |
手動 |
SGAコンポーネントサイズを手動で構成する必要があります。 PGAは各タイプのSQL演算子の作業領域の最大サイズを指定し、手動で制御します。 |
SGAコンポーネントサイズを手動で構成する必要があります。設定項目:
|
|
関連項目: 自動メモリー管理が使用できないプラットフォームもあります。『Oracle Database管理者ガイド』を参照してください。 |
多数のユーザーがアクティブになるデータベースでは、リソース管理がデータベース管理の重要な部分になります。過度にリソースを消費するセッションのため、他のセッションの処理が停止することがあります。このため、最適なタイミングでタスクを実行するようタスクをスケジューリングする方法が問題となります。Oracle Databaseでは、これらの問題を解決するためのツールを提供しています。
Oracle Database Resource Manager(リソース・マネージャ)は、ユーザー、アプリケーション、およびサービスに割り当てるデータベース・リソースを細かく制御するためのインフラストラクチャです。リソース・マネージャを使用することで、オペレーティング・システムでは十分に管理できない次の多くのリソース割当ての問題が解決されます。
過度のオーバーヘッド
非効率的なスケジューリング
不適当なリソースの割当て
データベース固有のリソース管理ができない状態
リソース・マネージャは、データベースでのハードウェア・リソース割当ての操作性を向上し、データベース内の処理の優先順位付けを可能にすることによって、これらの問題に対応します。セッションをセッション属性に基づいてグループに分類し、これらのグループにリソースを割り当てることによって、ハードウェアの利用率を最適化できます。
リソースは、データベース管理者が指定するリソース・プランに従ってユーザーに割り当てられます。リソース・プランは、リソース要件に従ってグループ化されたユーザー・セッションである、リソース・コンシューマ・グループ間でのリソースの分配方法を指定します。リソース・プラン・ディレクティブは、リソース・コンシューマ・グループにプランを関連付け、グループへのリソースの割当て方法を指定します。
図18-6に、昼間にOLTPアプリケーションとレポート・アプリケーションを同時に実行する組織で使用する簡単なリソース・プランを示します。現在、DAYTIMEのプランがアクティブになっており、3つのリソース・コンシューマ・グループ間でCPUリソースを割り当てます。具体的には、CPUタイムの75%がOLTPに、15%がREPORTSに、残りの10%がOTHER_GROUPSに割り当てられています。
|
関連項目: リソース・マネージャの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Scheduler(スケジューラ)を使用すると、データベース管理者とアプリケーション開発者はデータベース環境で各種タスクが発生する時期と場所を制御できます。スケジューラには、企業向けの複雑なスケジューリング機能が用意されており、次の操作を実行できます。
時間またはイベントに基づくジョブ実行スケジュール
ビジネス要件をモデル化する方法によるジョブ・プロセスのスケジュール
ジョブの管理と監視
クラスタ環境におけるジョブの実行と管理
プログラム・オブジェクト(プログラム)には、引数のデフォルト値を含む、スケジューラで実行されるコマンドに関するメタデータが含まれます。スケジュール・オブジェクト(スケジュール)には、実行日時および反復パターンに関する情報が含まれます。ジョブ・オブジェクト(ジョブ)は、プログラムをスケジュールに対応付けます。実行するジョブおよびその時間を定義するには、プログラム、スケジュール、およびジョブ間の関係を割り当てます。
スケジューラは、DBMS_SCHEDULER PL/SQLパッケージ内の一連のファンクションおよびプロシージャとして実装されています。このパッケージまたはEnterprise Managerを使用して、スケジューラ・オブジェクトを作成および操作します。スケジューラ・オブジェクトは標準データベース・オブジェクトであるため、システム権限およびオブジェクト権限により、これらのオブジェクトへのアクセスを制御できます。
図18-7に、スケジューラの基本アーキテクチャを示します。ジョブ表はすべてのジョブのコンテナであり、データベースごとにあります。ジョブ・コーディネータ・バックグラウンド・プロセスは、必要に応じて自動的に起動および停止します。ジョブ・スレーブは、ジョブの実行時間になるとジョブ・コーディネータによって起動されます(「ジョブ・キュー・プロセス(CJQ0およびJnnn)」を参照)。スレーブはジョブ表からメタデータを収集し、ジョブを実行します。
|
関連項目: スケジューラの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
DBAは、対象とするOracle Databaseのパフォーマンスを適切に保つ責任を担っています。一般的に、パフォーマンス上の問題は、許容されないレスポンス時間(特定のワークロードを完了するためにかかる時間)またはスループット(特定の時間内で完了できる作業量)によって発生します。一般的な問題には、次のものがあります。
CPUのボトルネック
サイズ設定が小さすぎるメモリー構造
I/O能力に関連する問題
効率の悪いまたは負荷が大きいSQL文
SQL文のチューニング後の予期しないパフォーマンスの低下
同時実行性および競合に関連する問題
データベース構成に関連する問題
チューニングの一般的な目標は通常、レスポンス時間の短縮、スループットの向上、またはその両方です。具体的に測定可能な目標の例としては、指定のSELECT文のレスポンス時間を5秒以下に短縮するなどがあります。この目標を達成できるかどうかは、DBAが制御できる要素とできない要素によって変わります。一般的に、チューニングとは、データベース・リソースを可能なかぎり効率的に使用することによって、具体的で測定可能、および達成可能なチューニング目標を達成するための作業のことです。
Oracleパフォーマンス・メソッドは、データベース内のボトルネックの特定と解消、および効率的なSQL文の開発に基づいています。Oracleパフォーマンス・メソッドには、次のタスクが含まれます。
チューニング前の準備
定期的なデータベースの予防的チューニング
ユーザーからのパフォーマンス上の問題報告に対応するデータベースのチューニング
負荷の高いSQL文の識別、チューニング、および最適化
この項では、アドバイザの使用など、Oracle Databaseパフォーマンス・チューニングの基本的な事柄について説明します。Oracle Databaseアドバイザは、領域、パフォーマンス、UNDO管理など、幅広い分野を網羅し、データベース管理に関係した主要な問題の対処方法について具体的なアドバイスを提供します。
|
関連項目: Oracleパフォーマンス・メソッドの実施方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
データベースは通常の処理を実行しながら、問題の発生時にすぐに問題を検知できるように自己を監視しています。Oracle Databaseでは、サーバー生成アラートを送信して、ユーザーに緊急の問題を通知できます。
アラートは問題が発生した場合、または毎秒の物理読取りやSQLレスポンス時間などのメトリックの予想値とデータが一致しない場合に自動的に生成されます。メトリックは、累積統計の変化率です。サーバー生成アラートは、ユーザー指定のしきい値に基づいて、またはイベントの発生に従って生成されるように設定できます。
サーバー生成アラートは問題を特定するのみでなく、報告した問題の解決方法も推奨します。たとえば、高速リカバリ領域の不足を通知するアラートでは、不要になった古いバックアップを削除するか、追加のディスク領域を追加するように推奨されます。
|
関連項目: 『Oracle Database管理者ガイド』 |
自動ワークロード・リポジトリ(AWR)は、システム、セッション、個々のSQL文、セグメント、およびサービスの累積統計などの履歴パフォーマンス・データを格納するリポジトリです。これらの統計は、パフォーマンスのチューニングなどの基礎となります。AWRは問題の検出とチューニングに利用されるデータベース統計を自動的に集計し、データベースの自己管理において重要な役割を果します。
図18-8に示すように、データベースは最新のAWR統計をSGAに格納します。デフォルトでは、MMONプロセスによって1時間ごとに統計が集計され、AWRスナップショットが作成されます(「管理性モニター・プロセス(MMONおよびMMNL)」を参照)。スナップショットは、ある時点で取得されたパフォーマンス統計のセットです。データベースは、スナップショットをSYSAUX表領域に書き込みます。AWRは、スナップショット領域を管理し、構成可能なスナップショット保存ポリシーに従って古いスナップショットをパージします。
AWRベースラインは統計率の集合であり、通常、ピーク負荷時にシステムが良好に動作していたときに取得したものが使用されます。一対または一定の範囲のAWRスナップショットをベースラインとして指定できます。AWRレポートを使用して、パフォーマンスが低下したときに取得した統計とベースラインを比較することによって問題を診断できます。
AutoTaskと呼ばれる自動メンテナンス・インフラストラクチャは、Oracle DatabaseがどのようにAWRを使用して自己管理を行っているかを示します。AWRデータを分析することによって、AutoTaskはメンテナンス・タスクの必要性を判断し、必要なメンテナンス・タスクがOracle Schedulerメンテナンス・ウィンドウで実行されるようにスケジュールします。メンテナンス・タスクの例として、オプティマイザの統計の集計や自動セグメント・アドバイザの実行があります。
|
関連項目:
|
自動データベース診断モニター(ADDM)は、Oracle Databaseに組み込まれている自己診断アドバイザです。AWRで取得された統計を使用して、ADDMは自動的かつ予防的にデータベース・パフォーマンスを診断し、識別された問題の解決方法を判断します。ADDMは手動でも実行できます。
ADDMでは、コンポーネント間の共通判断尺度として時間を使用し、システムのパフォーマンスに対して総合的にアプローチします。ADDMは、最も時間のかかっているOracle Databaseの領域を特定します。たとえば、データベースが使用可能なデータベース・バッファの待機に長時間費やしていると想定します。ADDMは、単に症状を示すのではなく、問題を掘り下げて根本原因を特定し、その問題がOracle Database全体に及ぼす影響を報告します。診断プロセス中のオーバーヘッドは、最小限に抑えられています。
ほとんどの場合、ADDMは解決策を推奨し、パフォーマンス向上の予想を数量化します。たとえば、ADDMはハードウェア、データベース構成、データベース・スキーマまたはアプリケーションを変更するよう推奨します。ADDMは、推奨を行う場合、時間的な利点を報告します。時間を尺度として使用することによって、問題と推奨の利点を比較検討できます。
潜在的なパフォーマンスの問題報告に加え、ADDMは、問題のないデータベース領域を示します。I/Oやメモリーなど、データベース・パフォーマンスに大きな影響を与えないサブコンポーネントは、初期段階で分類ツリーから除かれます。ADDMではこれらのサブコンポーネントがリストされるため、管理者はそれらの領域での処理による成果が少ないことを速やかに理解できます。
|
関連項目: 『Oracle Database 2日でパフォーマンス・チューニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』 |
アクティブ・セッション履歴(ASH)は、アクティブなデータベース・セッションを毎秒サンプリングし、データをメモリーおよび永続ストレージに書き込みます。ASHはデータベース自己管理フレームワークの重要な部分であり、パフォーマンス上の問題を診断する場合に役立ちます。
インスタンス・レベルで統計を集計するAWRとは異なり、ASHはセッション・レベルで統計を集計します。アクティブ・セッションは、CPUを使用しており、アイドル待機クラスのイベントを待機していないセッションです。
Enterprise ManagerまたはSQLスクリプトを使用してASHレポートを生成し、指定した期間に集計されたセッション統計を取得できます。ASHレポートは、次の目的に使用できます。
時間、セッション、モジュール、処理、SQL IDなどの各種ディメンションまたはその組合せで範囲を絞った、または目標に応じたパフォーマンスの分析
たとえば、10:00 p.m.から10:02 p.m.の間にデータベースの速度が低下したという報告をあるユーザーから受け取ったとします。ただし、10:00 p.m.から11:00 p.m.までのAWRスナップショット間隔では、2分間のパフォーマンス低下は短すぎて、ADDMの結果には表示されません。ASHレポートは、このような一過性の問題の原因を特定する場合に役立ちます。
|
関連項目: 『Oracle Database 2日でパフォーマンス・チューニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』 |
Oracle Databaseは、SQLのチューニング処理を完全に自動化します。ADDMは、システム・リソースを大量に使用し、それが原因でパフォーマンス上の問題を引き起こすSQL文を識別します。さらに、CPUと共有メモリーの使用量の観点で上位を占めるSQL文は、AWRに自動的に格納されます。高い負荷のSQL文の識別は、自動的に実施されるため、人的な介入は不要です。
自動SQLチューニングは、SQLチューニング・アドバイザを介して提供されます。SQLチューニング・アドバイザは、システム・メンテナンス・ウィンドウでメンテナンス・タスクとして自動的に実行されます。それぞれの自動実行中、アドバイザはデータベース内の負荷の大きいSQL問合せを選択し、これらの問合せに対するチューニングの推奨設定を生成します。
SQLチューニング・アドバイザの推奨設定は、次のカテゴリに分類されます。
統計分析
SQLプロファイリング
アクセス・パス分析
SQL構造分析
SQLプロファイルには、SQL文に固有の追加の統計が含まれており、これによりオプティマイザは改良した実行計画を作成できます。基本的には、SQLプロファイルが問合せを分析する方法です。アクセス・パス分析とSQL構造分析は、開発中のアプリケーションや社内の本番アプリケーションをチューニングする場合に役立ちます。
SQLチューニング・アドバイザの主要な利点は、外部ツールではなく、オプティマイザからソリューションが提供されることです(「オプティマイザの概要」を参照)。このため、チューニングは実行計画とSQLパフォーマンスを担当するデータベース・コンポーネントによって実行されます。チューニング処理では、SQL文の過去の実行統計が考慮され、その文に対するオプティマイザ設定がカスタマイズされます。
|
関連項目: 『Oracle Database 2日でパフォーマンス・チューニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』 |
SQLアクセス・アドバイザは、データ・アクセス・パスを最適化する方法についてのアドバイスを提供します。具体的には、パーティション、マテリアライズド・ビュー、索引、マテリアライズド・ビュー・ログを使用してデータベース・パフォーマンスを向上させる方法が推奨されます。
パーティションや索引などのスキーマ・オブジェクトは、複雑でデータ処理集中型の問合せを最適化する場合に必要不可欠です。ただし、これらのオブジェクトの作成と管理には、多大な時間と領域が必要になることがあります。SQLアクセス・アドバイザでは、指定されたワークロードに対応するデータ構造を推奨し、この推奨をパフォーマンス目標の達成に役立てることができます。
SQLアクセス・アドバイザは、SQLアクセス・アドバイザ・ウィザードを使用してEnterprise Managerから実行するか、DBMS_ADVISORパッケージの起動によって実行できます。DBMS_ADVISORパッケージは、どのPL/SQLプログラムからでもコール可能な、分析およびアドバイス用の一連のファンクションおよびプロシージャで構成されます。
|
関連項目: 『Oracle Database 2日でパフォーマンス・チューニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』 |
