| Oracle® Database概要 12c リリース1 (12.1) B71299-09 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
データベース管理者(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)は、Webベースのシステム管理ツールで、Oracleデータベース、Exadataデータベース・マシン、Fusion Middleware、Oracleアプリケーション、サーバー、記憶域、非Oracleハードウェアおよびソフトウェアを管理します。
Oracle Enterprise Manager Cloud Control (Cloud Control)は、Webベースのインタフェースで、これにより管理者は、Oracleテクノロジ・スタックおよび非Oracleコンポーネント全体を完全に監視できます。高速アプリケーション通知(FAN)のコンポーネントが使用できない、またはパフォーマンスの問題が発生した場合、Cloud Controlには自動生成されたアラートが表示されるので、管理者は適切なリカバリ処置を行えます。
Cloud Controlのコンポーネントには、次のものがあります。
Oracle Management Service (OMS)
OMS機能は、Cloud Controlのインタフェースを提供するJ2EEアプリケーションのセットで、すべてのOracle管理エージェントと連係して監視情報を処理し、Enterprise Managerリポジトリを永続的なデータ・ストアとして使用します。
これらのエージェントは、各監視対象ホストにデプロイされているプロセスで、ホスト上のすべてのターゲットを監視し、この情報をOMSに送信し、ホストおよびターゲットのメンテナンスを行います。
リポジトリは、Oracleデータベース内のスキーマで、Cloud Controlによって管理される管理者、ターゲットおよびアプリケーションに関するあらゆる情報が格納されています。
関連項目:
Cloud Controlを使用したデータベースの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
Cloud Controlのオンライン・ヘルプを参照してください。
Oracle Enterprise Manager Database Express (EM Express)は、Oracleデータベース内に組み込まれたWeb管理製品です。特別なインストールまたは管理は必要ありません。
EM Expressには、Cloud Controlの主要なパフォーマンス管理および基本管理のページが含まれます。これらのページには、次のものがあります。
データベースのホームページ
リアルタイムSQL監視
ASH分析
これらの機能には、オンラインではEM Expressコンソールを介してアクセスでき、オフラインではActive Reportsテクノロジを介してアクセスできます。アーキテクチャから見ると、EM Expressには中間層またはミドルウェア・コンポーネントがなく、データベース・サーバーでのオーバーヘッドがごくわずかになることは確実です。
EM Expressを使用すれば、ユーザー・セキュリティの管理、データベース・メモリーおよび記憶域の管理などの管理タスクを実行できます。また、データベースのパフォーマンスおよびステータス情報を表示できます。
関連項目:
EM Expressを使用したデータベースの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
SQL*Plusは、すべてのOracle Databaseのインストール時に含まれる、対話型のバッチ問合せツールです。このツールには、データベースへの接続時にクライアントとして機能する、コマンドライン・ユーザー・インタフェースがあります。
SQL*Plusは独自のコマンドと環境を持っています。ここでは、SQL、PL/SQL、SQL*Plus、オペレーティング・システム・コマンドを入力および実行し、次のタスクを実行できます。
問合せ結果の書式設定、計算の実行、保存および印刷
表定義およびオブジェクト定義の検証
バッチ・スクリプトの開発および実行
データベースの管理
SQL*Plusを使用して、対話的なレポート生成、バッチ処理としてのレポート生成、およびテキスト・ファイル、スクリーンまたはインターネットでの閲覧用のHTMLファイルへの結果の出力が可能です。HTML出力機能を使用するとレポートを動的に生成できます。
関連項目:
SQL*Plusの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。
Oracleでは、Oracle Databaseソフトウェアのインストール・タスクおよび構成タスクを簡略化するためのいくつかのツールを提供しています。
これらのツールは次のとおりです。
Oracle Universal Installer(OUI)
OUIは、Oracle Databaseソフトウェアを表示、インストールおよびアンインストールするためのGUIユーティリティです。オンライン・ヘルプがあり、ガイドに従ってインストールできます。
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
このツールは、ソフトウェアのインストール時に自動的に実行されます。アシスタントでは、リスナー名、プロトコル・アドレス、ネーミング・メソッド、tnsnames.oraファイル内のネット・サービス名、ディレクトリ・サーバーの使用などの基本ネットワーク・コンポーネントをインストール時に構成できます。
リスナー制御ユーティリティ
リスナー制御ユーティリティを使用すると、クライアント接続を受信するリスナーを構成できます。ユーティリティには、Enterprise Managerから、またはスタンドアロンのコマンドライン・アプリケーションとしてアクセスできます。
Oracle Connection Manager制御ユーティリティ
このコマンドライン・ユーティリティを使用すると、Oracle Connection Manager (ルーターの一種で、クライアント接続リクエストは、このルーターを経由して次のホップに送信されたり、データベースに直接送信されます)を管理できます。ユーティリティ・コマンドを使用して、基本的な管理機能を1つ以上のOracle Connection Managerに対して実行できます。さらに、パラメータの設定を表示および変更できます。
関連項目:
Oracle Net Servicesツールの詳細は、『Oracle Database Net Services管理者ガイド』および『Oracle Database Net Servicesリファレンス』を参照してください。
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*Loaderデータファイルおよび制御ファイルは、Oracle Databaseデータファイルおよび制御ファイルとは関連付けられていません。
ロード操作の様々な制御
たとえば、データの選択的なロード、データのキャラクタ・セットの指定、SQL関数によるデータの操作、指定の列への一意のシーケンシャル・キー値の生成が可能です。また、複雑なエラー・レポートも生成できます。
従来型パス、ダイレクト・パスまたは外部表ロードの使用
従来型パスによるロードでは、表にデータを移入するときにSQL INSERT文を実行します。一方、ダイレクト・パスのINSERTでは、データ・ブロックをフォーマットし、それをデータ・ファイルに直接書き込むことによって、データベースのオーバーヘッドを大幅に軽減します。直接書き込む場合は、最高水位標(HWM)よりも高いブロックで処理され、データベース・バッファ・キャッシュを経由せずに、ディスクに直接書き込まれます。直接読み取る場合も、バッファ・キャッシュを経由せずに、ディスクからPGAに直接読み取ります。
外部表ロードでは、データ・ファイルに含まれているデータの外部表が作成されます。ロード処理では、INSERT文が実行され、データ・ファイルのデータがターゲット表に挿入されます。
典型的なSQL*Loaderセッションは、SQL*Loader制御ファイルと1つ以上のデータファイルを入力として使用します。出力は、Oracle Database、ログ・ファイル、不良ファイル、および存在する場合は廃棄ファイルです。次の図に、典型的なSQL*Loaderセッションのフローを示します。
SQL*Loaderエクスプレス・モードを使用することもでき、次の例のように、SQL*Loaderコマンドでtableパラメータを指定するとアクティブになります。
% sqlldr hr table=employees
制御ファイルが使用できないため、SQL*Loaderが使用しやすくなります。制御ファイルを解析するかわりに、SQL*Loaderでは表列定義を使用して、入力データ型を確認します。SQL*Loaderは、キャラクタ・セット、フィールド・デリミタ、そしてデータ・ファイル、ログ・ファイルおよび不良ファイルの名前など、複数のデフォルト推測を作成します。デフォルト値の多くは、コマンドライン・パラメータでオーバーライドできます。
関連項目:
SQL*Loaderの詳細は、Oracle Databaseユーティリティを参照してください
Oracle Data Pumpにより、データベース間でデータとメタデータを高速で移動できます。
このテクノロジは、次のOracle Databaseデータ移動ユーティリティのベースとなります。
データ・ポンプ・エクスポート(エクスポート)
エクスポートは、データとメタデータをダンプ・ファイル・セットと呼ばれる一連のオペレーティング・システム・ファイルにアンロードするユーティリティです。ダンプ・ファイル・セットは、表データ、データベース・オブジェクトのメタデータおよび制御情報を含む1つ以上のバイナリ・ファイルから構成されています。
データ・ポンプ・インポート(インポート)
インポートは、エクスポートされたダンプ・ファイル・セットをデータベースにロードするユーティリティです。また、インポートを使用すると、ソース・データベースから中間ファイルなしで宛先データベースに直接ロードすることができ、エクスポート操作とインポート操作を同時に実行することで全体の所要時間が短縮されます。
Oracle Data Pumpは、次のような部分から構成されています。
expdpおよびimpdpコマンドライン・クライアント
これらのクライアントは、DBMS_DATAPUMPパッケージに対してコールし、Oracle Data Pump操作を実行します。
DBMS_DATAPUMP PL/SQLパッケージ(データ・ポンプAPIとも呼ばれる)
このAPIによって、高速でインポートおよびエクスポートされます。
DBMS_METADATA PL/SQLパッケージ(メタデータAPIとも呼ばれる)
メタデータのすべてのロードおよびアンロード・プロセスでこのAPIが使用され、オブジェクト定義がXML形式で格納されます。
次の図に、Oracle Data PumpをSQL*Loaderおよび外部表と統合する方法を示します。図に示すように、SQL*Loaderは外部表APIおよびData Pump APIに統合され、データを外部表にロードします。Oracle Enterprise Manager Cloud Control (Cloud Control)やトランスポータブル表領域などのクライアントでは、Oracle Data Pumpインフラストラクチャを使用できます。
関連項目:
Oracle Data Pumpの概要は、『Oracle Databaseユーティリティ』を参照してください。
DBMS_DATAPUMPおよびDBMS_METADATAの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください
Oracle LogMinerを使用すると、SQLインタフェースを介してREDOログ・ファイルを問い合せることができます。REDOログ・ファイルに含まれるデータの使用方法を次に示します。
アプリケーション・レベルで発生したエラーなど、データベースの論理的な破損の開始時点を特定します。
ユーザー・エラーを検出します。
トランザクション・レベルでファイングレイン・リカバリを実行するために必要な操作を判断します。
傾向分析を使用して、更新および挿入頻度の最も高い表を判断できます。
REDOログ・ファイルに対するLogMinerの包括的なリレーショナル・インタフェースを使用して、システムの動作を分析し、データベースの使用状況を監査します。
LogMinerには、コマンドライン・インタフェースまたはEnterprise Managerの一部であるOracle LogMiner Viewer GUIを介してアクセスできます。
関連項目:
LogMinerの詳細は、『Oracle Databaseユーティリティ』を参照してください。
ADRCIは、問題の調査、ヘルス・チェック・レポートの表示、最初の障害データのパッケージ化およびOracleサポートへのアップロードに使用するコマンドライン・ユーティリティです。
また、このユーティリティでは、自動診断リポジトリ(ADR)内のトレース・ファイル名やアラート・ログを表示できます。ADRCIには、対話形式またはスクリプトで使用できる豊富なコマンド・セットが用意されています。
関連項目:
ADRおよびADRCIの詳細は、『Oracle Databaseユーティリティ』および『Oracle Database管理者ガイド』を参照してください。
「データベース管理者および開発者向けのトピック」では、開発者とDBAの両方にとって重要なトピックについて説明します。この項では、他の箇所で説明されていないDBAに不可欠なトピックについて説明します。
この項には次のトピックが含まれます:
バックアップおよびリカバリとは、メディア障害またはユーザー・エラーによるデータ損失からのデータベース保護に関連する、一連の概念、プロシージャ、計画です。一般的に、バックアップおよびリカバリ計画の目的は、データベースをデータ損失から保護し、失われたデータを再構築することです。
バックアップとは、データのコピーです。バックアップには、データファイル、サーバー・パラメータ・ファイル、制御ファイルなど、データベースの重要な部分を含めることができます。バックアップおよびリカバリが必要になる一例として、ディスク・ドライブの障害によりデータファイルが失われた場合などがあります。失われたファイルのバックアップが存在する場合は、ファイルをリストアおよびリカバリできます。データの損失が発生する前の状態へのリストアにかかわる操作は、メディア・リカバリと呼ばれます。
この項には次のトピックが含まれます:
関連項目:
バックアップおよびリカバリの概念およびタスクの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
Microsoft Windowsでデータベースをバックアップおよびリカバリするためのボリューム・シャドウ・コピー・サービス(VSS)アプリケーションの使用方法の詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください
Recovery Managerとユーザーによる管理方法のいずれかを使用して、Oracleデータベースをバックアップ、リストアおよびリカバリできます。
この2つのアプローチの主な違いは次のとおりです。
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を使用するかわりに、バックアップおよびファイルのリストアの場合はLinuxのddコマンド、メディア・リカバリの場合はSQL*PlusのRECOVERコマンドなど、オペレーティング・システムのコマンドを使用できます。Oracleでは、ユーザー管理のバックアップおよびリカバリが全面的にサポートされていますが、RMANの方がOracle Databaseと統合されており、管理が簡素化されているため、RMANを使用することをお薦めします。
関連項目:
バックアップおよびリカバリ・ソリューションの概要は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください
Oracle Secure Backupの概要は、『Oracle Secure Backup管理者ガイド』を参照してください。
RMANおよびOracle Secure Backupには、コマンドラインおよびEnterprise Manager Cloud Control (Cloud Control)の両方からアクセスできます。
Cloud Controlには、グラフィカルなフロント・エンドと、RMAN用のスケジューリング機能が用意されています。ジョブ・パラメータを入力したら、ジョブ・スケジュールを指定します。Cloud ControlによってRMANが指定した時刻に指定した間隔で繰り返し実行され、バックアップおよびリカバリの操作が実行されます。Cloud Controlは、一連のウィザードによってRMANにアクセスできます。これらのウィザードは、データベース、使用可能なバックアップおよびデータ・リカバリの目的の分析に基づいて、様々なリカバリ手順を提供します。
Cloud Controlを使用することによって、この章で説明する簡単なリストアおよびリカバリの例を実行できます。また、Point-in-TimeリカバリやOracle Flashback操作などのより高度なリストアおよびリカバリ方法を使用して、メディア障害およびユーザー・エラーを効率的に修復することもできます。Cloud Controlを使用した方が、多くの場合、RMANコマンドライン・クライアントより簡単です。
次の図に、RMANアーキテクチャのサンプルを示します。Cloud Controlからアクセス可能なRMANクライアントは、ターゲット・データベースのサーバー・セッションを使用して、データをディスクまたはテープにバックアップします。RMANは、外部にあるリカバリ・カタログをバックアップ・メタデータで更新できます。
どちらのバックアップおよびリカバリ方法を使用する場合でも、高速リカバリ領域を構成することをお薦めします。このデータベースによって管理されるディレクトリ、ファイルシステムまたはOracle ASMディスク・グループは、アクティブな制御ファイル、オンラインおよびアーカイブREDOログ・ファイル、バックアップなどのバックアップ・ファイルおよびリカバリ・ファイルを一元化します。Oracle Databaseのリカバリ・コンポーネントは、高速リカバリ領域と対話し、データベースのリカバリ可能性を保証します。
関連項目:
Recovery Managerによるバックアップおよびリカバリの実行方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください
高速リカバリ領域の設定および管理方法は、『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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください
Oracle Databaseでは、Oracle Flashbackテクノロジと呼ばれる機能グループが提供されており、バックアップをリストアせずに、過去のデータの状態を表示したり、特定の時間に応じてデータを前後に巻き戻すことができます。
データベースの変更内容にもよりますが、フラッシュバック機能では、メディア・リカバリよりも迅速に、可用性に及ぼす影響も少なく、不要な変更を元に戻すことができます。バックアップおよびリカバリに最適なフラッシュバック機能には、次のものがあります。
フラッシュバック・データベース
非CDBでは、Oracle Databaseを以前の時点まで巻き戻し、論理データの破損やユーザー・エラーによる問題を解決できます。フラッシュバック・データベースは、Data Guard、データ・リカバリ・アドバイザの補完、およびクローン・データベースの同期化にも使用できます。フラッシュバック・データベースではファイル上でメディア・リカバリはリストアまたは実行されないため、これを使用してディスク・クラッシュなどのメディア障害を修正することはできません。
フラッシュバック表
1つのSQL文で、指定した時点まで表を巻き戻しできます。表データとともに、関連する索引、トリガーおよび制約をリストアでき、データベースはオンライン状態で、指定された表に対する変更のみが取り消されます。フラッシュバック表は、不良ディスクやデータ・セグメントと索引の非一貫性など、物理的な破損には対応していません。
フラッシュバック・ドロップ
DROP TABLE操作の効果を無効にできます。フラッシュバック・ドロップは、ポイント・イン・タイム・リカバリなどのリカバリ・メカニズムより大幅に高速であり、最近のトランザクションの損失や停止時間も発生しません。
関連項目:
フラッシュバック機能の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
FLASHBACK DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』および『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
データ・リカバリ・アドバイザ・ツールは、データ障害を自動的に診断して、適切な修復オプションを提示し、ユーザーのリクエストに基づいて修復を実行します。データ・リカバリ・アドバイザは、自動データ修復用の集中管理ツールを提供することによって、Oracle Databaseの管理性および信頼性を向上し、リカバリ時間を短縮します。
データベースには、チェックを実行するための状態モニター・フレームワークがあります。チェッカは、データベースまたはそのコンポーネントの状態を評価するために状態モニターに登録されている操作またはプロシージャです。状態の評価はデータ整合性チェックと呼ばれ、事後対応的または事前対応的に実行できます。
障害とは、データ整合性チェックにより検出される永続的なデータ破損のことです。障害は通常、対処的に検出されます。破損データが関与するデータベースの操作はエラーとなりますが、これにより自動的にデータ整合性チェックが起動され、エラーに関連する障害がないかデータベースが検索されます。障害が診断された場合、その障害はデータベースにより自動リポジトリ(ADR)に記録されます。
障害がデータベースにより検出され、ADRに保存されると、データ・リカバリ・アドバイザは最善の修復オプションおよびデータベースへの影響を自動的に判断します。通常、データ・リカバリ・アドバイザは、それぞれの障害または障害グループに対して手動および自動の両方の修復オプションを生成します。
データ・リカバリ・アドバイザは、自動修復オプションを提示する前に、修復を完了するために必要なメディア・コンポーネントが使用可能かどうか、およびそのオプションが特定の環境に適しているかどうかを検証します。自動修復を選択すると、Oracle Databaseによって自動的に修復されます。データ・リカバリ・アドバイザは、修復の成功を確認し、該当する障害をクローズします。
関連項目:
データ・リカバリ・アドバイザの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
データファイル・リカバリは、消失または破損した現行のデータファイルまたは制御ファイルを修復します。また、表領域がOFFLINE NORMALオプションを設定せずにオフラインになったときに消失した変更をリカバリします。
データファイルまたは制御ファイルのバックアップをリストアする場合、またはデータファイルがOFFLINE NORMALオプションを設定せずにオフラインになった場合は、メディア・リカバリが必要です。オンライン・データファイルのメディア・リカバリが必要な場合は、データベースをオープンできず、また、メディア・リカバリが完了するまでは、メディア・リカバリを必要とするデータファイルはオンライン化できません。
データファイルまたは制御ファイルの物理バックアップのリストアとは、それを再構築してOracle Databaseで使用可能にすることです。バックアップのリカバリとは、アーカイブREDOログ・ファイルを適用して、消失した変更を再構築することです。RMANでは、前回のバックアップ後に変更されたデータ・ブロックのみを含む増分バックアップを使用して、データファイルをリカバリすることもできます。
変更がオンライン・ファイルに自動的に適用されるインスタンス・リカバリとは異なり、メディア・リカバリでは、ユーザーによる起動が必要であり、リストアされたバックアップにアーカイブREDOログ・ファイルが適用されます。データファイルのメディア・リカバリは、オフライン・データファイルか、データベース・インスタンスによりオープンされていないデータベースのデータファイルにのみ機能します。
データファイル・メディア・リカバリは、すべての変更を適用するかどうかで異なります。
完全リカバリ
完全リカバリでは、アーカイブREDOログとオンラインREDOログに含まれるREDO変更すべてがバックアップに適用されます。通常、完全メディア・リカバリは、メディア障害によりデータファイルまたは制御ファイルが破損した後に実行します。完全リカバリは、データベース、表領域またはデータファイルに対して実行できます。
不完全リカバリ
不完全リカバリはデータベース・ポイント・イン・タイム・リカバリとも呼ばれ、データベースの以前のバージョンを生成します。この場合、リストアされたバックアップ以後に生成されたREDOすべてを適用するわけではありません。通常、データベースのポイント・イン・タイム・リカバリは、Oracle Flashback Databaseを使用できないときにユーザー・エラーを取り消す場合に実行します。
不完全リカバリを実行するには、リカバリが必要な時点より前に作成されたバックアップからデータファイルをすべてリストアし、リカバリの完了時にRESETLOGSオプションを指定してデータベースをオープンする必要があります。ログをリセットすると、新しくログ順序1からログ順序番号のストリームが開始します。
注意:
現行のデータファイルが利用可能な場合は、DBPITRのかわりにフラッシュバック・データベースを使用できます。
表領域のポイント・イン・タイム・リカバリ(TSPITR)機能を使用すると、1つ以上の表領域をデータベースの残りの部分より古い時点までリカバリできます。
関連項目:
メディア・リカバリの概念の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください
クラウド規模のZero Data Loss Recovery Appliance (リカバリ・アプライアンスとして一般的に知られています)は、企業におけるすべてのOracleデータベースのデータ損失とバックアップのオーバーヘッドを大幅に削減するためのエンジニアド・システムです。
リカバリ・アプライアンスはRMANと統合されており、クラウド規模で耐障害性の高いハードウェアと記憶域を使用して、多数のデータベースに対する集中管理されたバックアップとリカバリの計画をデプロイします。リカバリ・アプライアンスでは、継続してバックアップのリカバリ可能性が検証されます。
集中管理されたリカバリ・アプライアンスは大部分のデータベース・バックアップとリストア処理を実行し、記憶域使用率、パフォーマンス、およびバックアップの管理性の効率を高めます。
主な利点は次のとおりです。
データ損失の解消
リカバリ・アプライアンスでは、次のようなテクノロジを使用して、データ・センターのほとんどのデータベースで発生するデータ損失の可能性を解消します。
リアルタイムREDOトランスポートと呼ばれる、保護対象データベースのSGAからリカバリ・アプライアンスへのREDO変更の継続的な転送
リモート・リカバリ・アプライアンスへのレプリケーション
集中管理されたリカバリ・アプライアンスによる自動テープ・バックアップ
エンドツーエンドのデータベース・ブロック検証
最小バックアップのオーバーヘッド
データベース・サーバーのバックアップ・オーバーヘッドは、リカバリ・アプライアンスへオフロードすることによって最小化し、リカバリ・アプライアンスでは統一されたディスク・プールで複数のデータベースのバックアップを管理します。RMANの永久的増分バックアップ計画には、初期レベル0のリカバリ・アプライアンスへのバックアップ作成が含まれており、その後の増分バックアップはすべてレベル1です。リカバリ・アプライアンスでは、レベル0とレベル1のバックアップを組み合せて仮想完全バックアップを作成します。リカバリ・アプライアンスではブロック・レベルで継続的にバックアップを圧縮、重複解除、および検証します。
エンドツーエンド・データ保護の可視性の向上
Cloud Controlでは、RMANバックアップが開始されてからディスクまたはテープに格納されるまで、またはダウンストリーム・リカバリ・アプライアンスへレプリケートされるまでの、リカバリ・アプライアンスが管理するバックアップ・ライフサイクルに対して完全なエンドツーエンドのビューが提供されます。Enterprise Manager for Zero Data Loss Recovery Applianceプラグイン(リカバリ・アプライアンス・プラグイン)をインストールすると、監視と管理が可能になります。
クラウド規模の保護
リカバリ・アプライアンスがサポートするデータベースは、数十から数百、あるいは数千にのぼります。このアーキテクチャの主なコンポーネントは次のとおりです。
リカバリ・アプライアンスでは、保護ポリシーによって管理を簡素化し、このポリシーに関連する各データベースに対して強制されるリカバリ・ウィンドウ目標を定義します。保護ポリシーでは、データベースを共通する特性を持つ階層のグループとしてまとめると、管理性が向上します。
リカバリ・アプライアンスでは保護ポリシーにより、保護対象の各データベースのリカバリ・ウィンドウ目標に応じたバックアップ記憶域領域を管理します。このデータベース指向の詳細な記憶域領域の管理方法により、サード・パーティ・アプライアンスと同様に、記憶域ボリューム・レベルで領域を管理する必要がなくなります。
リカバリ・アプライアンスは、記憶域リソースを単純なモジュラ形式で加算し、バックアップ・トラフィック、記憶域使用量、およびデータベース数の増加に対応するように調整できます。
保護対象データベースは、データをリカバリ・アプライアンスにバックアップするクライアント・データベースです。
次の図に、6つの保護対象データベースと2つのリカバリ・アプライアンスを含むサンプルの環境を示します。それぞれのデータベースは、バックアップにZero Data Loss Recovery Applianceバックアップ・モジュール(リカバリ・アプライアンス・バックアップ・モジュール)を使用します。このモジュールはRMANがネットワーク経由でバックアップをリカバリ・アプライアンスに転送する、Oracle提供のSBTライブラリです。
それぞれのリカバリ・アプライアンスにあり、リカバリ・カタログに保存されているメタデータを管理するリカバリ・アプライアンス・メタデータ・データベース。バックアップをリカバリ・アプライアンスに送信する保護対象データベースはすべて、このリカバリ・カタログを使用する必要があります。バックアップは、Oracle ASMディスク・グループ・セットであるリカバリ・アプライアンスの記憶域の場所にあります。
注意:
データベースでは、バックアップ・リポジトリとしてではなく、リカバリ・カタログとしてリカバリ・アプライアンスが使用されることがあります。
管理者はCloud Controlを使用して環境を管理および監視します。Cloud Controlでは、各データベースのバックアップ・ライフサイクル全体、およびバックアップがディスク、テープ、または別のリカバリ・アプライアンスのどこにあるかが「1枚ガラス」のビューで提供されます。
関連項目:
製品の詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。
メモリー管理では、データベースの変化に応じて、Oracleインスタンスのメモリー構造を最適なサイズに維持します。初期化パラメータ設定により、SGAおよびインスタンスPGAメモリーの管理方法が決まります。
図20-5に、メモリー管理オプションのディシジョン・ツリーを示します。次の各項では、各オプションの詳細を説明します。
関連項目:
SGAおよびPGAの詳細は、「メモリー・アーキテクチャ」を参照してください
自動メモリー管理では、Oracle DatabaseによりSGAおよびインスタンスPGAメモリーが完全に自動管理されます。最もシンプルなこの方法を使用することをお薦めします。
ユーザー指定の制御は、ターゲット・メモリー・サイズ初期化パラメータ(MEMORY_TARGET)と、オプションの最大メモリー・サイズ初期化パラメータ(MEMORY_MAX_TARGET)のみです。Oracle Databaseは、ターゲット・メモリー・サイズに自動的にチューニングし、必要に応じて、SGAとインスタンスPGA間でメモリーを再配布します。
Oracle Database 12cリリース1 (12.1.0.2)以降は、SGAにインメモリー列ストア(IM列ストア)と呼ばれるオプションのメモリー領域が含まれます。使用するメモリー管理方法にかかわらず、IM列ストアはINMEMORY_SIZE初期化パラメータで別個にサイズ設定する必要があります。IM列ストアのサイズはメモリー・ターゲットにおいて考慮する必要がありますが、自動領域サイズ再設定アルゴリズムの一部ではありません。このため、MEMORY_TARGETを5GBに設定し、INMEMORY_SIZEを1GBに設定した場合、メモリー・ターゲット全体は5GBで(6GBではない)INMEMORY_SIZEは常に1GBです。
図20-6に、オンライン・ユーザーにより発行されたジョブを必要に応じて処理したり、バッチ・ジョブを処理するデータベースを示します。自動メモリー管理を使用すると、データベースは実行するジョブのタイプに応じて、自動的にラージ・プールとデータベース・バッファ・キャッシュのサイズを調整します。
DBCAを使用してデータベースを作成し、基本インストール・オプションを選択した場合、Oracle Databaseではデフォルトで自動メモリー管理が有効化されます。
関連項目:
自動メモリー管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
自動メモリー管理が有効でない場合、システムはSGAに共有メモリー管理を使用します。共有メモリー管理では、次のいずれかのモードを選択できます。
自動共有メモリー管理
このモードは、自動メモリー管理が無効になっている場合のデフォルトで、SGAのサイズをより直接的に制御できます。データベースは、SGAの合計サイズをターゲット・サイズにチューニングし、動的にSGAコンポーネントのサイズをチューニングします。サーバー・パラメータ・ファイルを使用している場合、Oracle Databaseでは、自動チューニングされたコンポーネントのサイズがデータベース・インスタンス停止後も保持されます。
手動共有メモリー管理
このモードでは、個々のSGAコンポーネントのサイズをいくつか設定し、処理ごとに個々のSGAコンポーネントを手動でチューニングします。個々のSGAコンポーネントのサイズを完全に制御できます。自動メモリー管理および自動共有メモリー管理が両方とも無効になっている場合は、このモードがデフォルトになります。
注意:
自動メモリー管理が無効になっている場合、データベースはユーザー・ワークロードに応じて共有プールとバッファ・キャッシュの相対サイズを自動的に調整することがあります。
関連項目:
共有メモリー管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
手動モード中の自動サイズ変更の詳細は、My Oracle Supportノート1269139.1を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1269139.1
自動メモリー管理が有効でない場合は、Oracle Databaseは自動または手動のPGAメモリー管理を使用します。
PGAメモリーの管理には、次のモードを指定できます。
自動PGAメモリー管理
自動メモリー管理(MEMORY_TARGET)が無効で、PGA_AGGREGATE_TARGETが0(ゼロ)以外の値に設定されている場合、データベースは自動PGAメモリー管理を使用します。このモードでは、PGA_AGGREGATE_TARGETによってインスタンスPGAの柔軟なターゲット・サイズが指定されます。ターゲットが柔軟であるのは、PGAではなく一時領域を使用するように選択できる特定タイプのメモリー割当てにのみ適用されるためです。データベースは、このターゲットに対してインスタンスPGAのサイズをチューニングし、個々のPGAのサイズを動的にチューニングします。ターゲット・サイズを明示的に設定しない場合は、適切なデフォルト値がデータベースによって自動的に構成されます。
PGA_AGGREGATE_LIMIT初期化パラメータは、PGAメモリーに対してインスタンス全体の厳しい制限を動的に設定します。パラメータは変化するメモリーの状態に対応するため、明示的にパラメータ値を設定する必要はありません。デフォルトでは、PGA_AGGREGATE_LIMITは次の値より大きい値に設定されます。
2GB
PGA_AGGREGATE_TARGET初期化パラメータ設定の200%
(PROCESSES初期化パラメータ設定の値) * 3MB
PGA_AGGREGATE_LIMITの値が、物理メモリー・サイズの120%からSGAの合計サイズを引いた値を超えることはできません。
バックグラウンド・プロセスでは、PGAサイズとPGA_AGGREGATE_LIMITで設定された制限とを定期的に比較します。制限に達した場合または制限を超過した場合、このプロセスでは、最もチューニング不可なPGAメモリーを使用してセッションのコールを終了します。これらのセッションによっても十分なメモリーが解放されない場合、それらも終了されます。
手動PGAメモリー管理
自動メモリー管理が無効で、PGA_AGGREGATE_TARGETが0(ゼロ)に設定されている場合、手動PGA管理がデフォルトになります。Oracle Databaseの以前のリリースでは、DBAが作業領域の最大サイズをSQL演算子(ソートやハッシュ結合など)のタイプごとに手動で指定する必要がありました。しかし、ワークロードは常に変化するため、この技法は非常に困難であることがわかりました。Oracle Databaseでは手動によるPGAメモリー管理もサポートされていますが、自動メモリー管理を使用することをお薦めします。
関連項目:
PGAメモリー管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
メモリー管理は、自動または手動のいずれかで実行します。
自動メモリー管理を有効化しない場合は、SGAおよびPGAのそれぞれに対して個別にメモリー管理方法を構成する必要があります。
注意:
自動メモリー管理がデータベース・インスタンス全体に対して無効の場合、Oracle Databaseではデフォルトで、自動PGAメモリー管理が有効になります。
次の表に、Oracle Database 12cリリース1 (12.1.0.2)から使用可能なINMEMORY_SIZE初期化パラメータを示します。IM列ストアはオプションですが、有効化するにはINMEMORY_SIZEパラメータが必要です。
図20-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コンポーネントサイズを手動で構成する必要があります。設定項目:
|
脚注1
データベースによってPGA_AGGREGATE_LIMIT初期化パラメータが自動的に構成されます。このパラメータを手動で設定するように選択することもできます。
脚注2
データベースによってPGA_AGGREGATE_LIMIT初期化パラメータが自動的に構成されます。このパラメータを手動で設定するように選択することもできます。
関連項目:
自動メモリー管理が使用できないプラットフォームもあります。『Oracle Database管理者ガイド』を参照してください。
多数のユーザーがアクティブになるデータベースでは、リソース管理がデータベース管理の重要な部分になります。過度にリソースを消費するセッションのため、他のセッションの処理が停止することがあります。このため、最適なタイミングでタスクを実行するようタスクをスケジューリングする方法が問題となります。Oracle Databaseでは、これらの問題を解決するためのツールを提供しています。
Oracle Database Resource Manager(リソース・マネージャ)は、ユーザー・アカウント、アプリケーション、およびサービスに割り当てるデータベース・リソースを細かく制御します。リソース・マネージャは、主にゲートキーパーとして機能し、他のジョブを高速で実行できるように一部のジョブを低速で実行します。
DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用することで、オペレーティング・システムでは十分に管理できない次の多くのリソース割当ての問題が解決されます。
過度のオーバーヘッド
非効率的なスケジューリング
不適当なリソースの割当て
データベース固有のリソース管理ができない状態
リソース・マネージャは、データベースでのハードウェア・リソース割当ておよびデータベース内の処理の優先順位付けの操作性を向上することによって、前述の問題に対応します。セッションをセッション属性に基づいてグループに分類し、これらのグループにリソースを割り当てることによって、ハードウェアの利用率を最適化できます。
リソースは、データベース管理者が指定するリソース・プランに従ってユーザーに割り当てられます。リソース・プランは、リソース要件に従ってグループ化されたユーザー・セッションである、リソース・コンシューマ・グループ間でのリソースの分配方法を指定します。リソース・プラン・ディレクティブは、リソース・コンシューマ・グループにプランを関連付け、グループへのリソースの割当て方法を指定します。
図20-7に、昼間にOLTPアプリケーションとレポート・アプリケーションを同時に実行する組織で使用する簡単なリソース・プランを示します。現在、DAYTIMEのプランがアクティブになっており、3つのリソース・コンシューマ・グループ間でCPUリソースを割り当てます。具体的には、CPUタイムの75%がOLTPに、15%がREPORTSに、残りの10%がOTHER_GROUPSに割り当てられています。
リソース・マネージャで解決できる問題の1つは、暴走クエリーです。リソース・マネージャを使用すると、ランナウェイSQL文を特定するためのしきい値と、それらの文に対応するアクションを指定できます。CPU時間、経過時間、物理I/Oまたは論理I/Oのしきい値を指定できます。アクションを優先度の低いコンシューマ・グループに切り替えて、SQL文を終了したり、しきい値の違反をログに記録することができます。SQLモニターを使用してランナウェイ問合せを監視できます。
関連項目:
リソース・マネージャの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください
DBMS_RESOURCE_MANAGER PL/SQLパッケージの使用方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
Oracle Scheduler(スケジューラ)を使用すると、データベース管理者とアプリケーション開発者はデータベース環境で各種タスクが発生する時期と場所を制御できます。
スケジューラには、企業向けの複雑なスケジューリング機能が用意されており、次の操作を実行できます。
時間またはイベントに基づくジョブ実行スケジュール
ビジネス要件をモデル化する方法によるジョブ・プロセスのスケジュール
ジョブの管理と監視
クラスタ環境におけるジョブの実行と管理
プログラム・オブジェクト(プログラム)には、引数のデフォルト値を含む、スケジューラで実行されるコマンドに関するメタデータが含まれます。スケジュール・オブジェクト(スケジュール)には、実行日時および反復パターンに関する情報が含まれます。ジョブ・オブジェクト(ジョブ)は、プログラムをスケジュールに対応付けます。実行するジョブおよびその時間を定義するには、プログラム、スケジュール、およびジョブ間の関係を割り当てます。
スケジューラは、DBMS_SCHEDULER PL/SQLパッケージ内の一連のファンクションおよびプロシージャとして実装されています。このパッケージまたはEnterprise Managerを使用して、スケジューラ・オブジェクトを作成および操作します。スケジューラ・オブジェクトは標準データベース・オブジェクトであるため、システム権限およびオブジェクト権限により、これらのオブジェクトへのアクセスを制御できます。
図20-8に、スケジューラの基本アーキテクチャを示します。ジョブ表はすべてのジョブのコンテナであり、データベースごとにあります。ジョブ・コーディネータ・バックグラウンド・プロセスは、必要に応じて自動的に起動および停止します。ジョブ・スレーブは、ジョブの実行時間になるとジョブ・コーディネータによって起動されます。スレーブはジョブ表からメタデータを収集し、ジョブを実行します。
関連項目:
スケジューラの詳細は、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 SQLチューニング・ガイドを参照してください
データベースは通常の処理を実行しながら、問題の発生時にすぐに問題を検知できるように自己を監視しています。Oracle Databaseでは、サーバー生成アラートを送信して、ユーザーに緊急の問題を通知できます。
アラートは問題が発生した場合、または毎秒の物理読取りやSQLレスポンス時間などのメトリックの予想値とデータが一致しない場合に自動的に生成されます。メトリックは、累積統計の変化率です。サーバー生成アラートは、ユーザー指定のしきい値に基づいて、またはイベントの発生に従って生成されるように設定できます。
サーバー生成アラートは問題を特定するのみでなく、報告した問題の解決方法も推奨します。たとえば、高速リカバリ領域の不足を通知するアラートでは、不要になった古いバックアップを削除するか、追加のディスク領域を追加するように推奨されます。
関連項目:
『Oracle Database管理者ガイド』
自動ワークロード・リポジトリ(AWR)は、システム、セッション、個々のSQL文、セグメント、およびサービスの累積統計などの履歴パフォーマンス・データを格納するリポジトリです。
AWR統計は、パフォーマンスのチューニングなどの基礎となります。AWRは問題の検出とチューニングに利用されるデータベース統計を自動的に集計し、データベースの自己管理において重要な役割を果します。
次の図に示すように、データベースは最新のAWR統計をSGAに格納します。デフォルトでは、MMONプロセスは、1時間ごとに統計を収集し、AWRスナップショットを作成します。AWRスナップショットは、ある時点で取得されたパフォーマンス統計のセットです。データベースは、スナップショットをSYSAUX表領域に書き込みます。AWRは、スナップショット領域を管理し、構成可能なスナップショット保存ポリシーに従って古いスナップショットをパージします。
AWRベースラインは統計率の集合であり、通常、ピーク負荷時にシステムが良好に動作していたときに取得したものが使用されます。一対または一定の範囲のAWRスナップショットをベースラインとして指定できます。AWRレポートを使用して、パフォーマンスが低下したときに取得した統計とベースラインを比較することによって問題を診断できます。
AutoTaskと呼ばれる自動メンテナンス・インフラストラクチャは、Oracle DatabaseがどのようにAWRを使用して自己管理を行っているかを示します。AWRデータを分析することによって、AutoTaskはメンテナンス・タスクの必要性を判断し、必要なメンテナンス・タスクがOracle Schedulerメンテナンス・ウィンドウで実行されるようにスケジュールします。メンテナンス・タスクの例として、オプティマイザの統計の集計や自動セグメント・アドバイザの実行があります。
関連項目:
AWRの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください
自動メンテナンス・タスクの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください
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レポートは、次の目的に使用できます。
自動データベース診断モニター(ADDM)によって識別されない短期間のパフォーマンス上の問題の分析
時間、セッション、モジュール、処理、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文の過去の実行統計が考慮され、その文に対するオプティマイザ設定がカスタマイズされます。
関連項目:
『Oracle Database 2日でパフォーマンス・チューニング・ガイド』およびOracle Database SQLチューニング・ガイド
SQLアクセス・アドバイザは、データ・アクセス・パスを最適化する方法についてのアドバイスを提供します。具体的には、パーティション、マテリアライズド・ビュー、索引、マテリアライズド・ビュー・ログを使用してデータベース・パフォーマンスを向上させる方法が推奨されます。
パーティションや索引などのスキーマ・オブジェクトは、複雑でデータ処理集中型の問合せを最適化する場合に必要不可欠です。ただし、これらのオブジェクトの作成と管理には、多大な時間と領域が必要になることがあります。SQLアクセス・アドバイザでは、指定されたワークロードに対応するデータ構造を推奨し、この推奨をパフォーマンス目標の達成に役立てることができます。
SQLアクセス・アドバイザは、ウィザードを使用してEnterprise Managerから実行するか、DBMS_ADVISORパッケージを使用して実行できます。DBMS_ADVISORは、任意のPL/SQLプログラムからコール可能な分析およびアドバイザ用のファンクションおよびプロシージャの集合です。
関連項目:
『Oracle Database 2日でパフォーマンス・チューニング・ガイド』およびOracle Database SQLチューニング・ガイド
SQL計画管理は、データベースで確認済の計画のみが使用されるように、オプティマイザで実行計画を自動的に管理できる予防的なメカニズムです。このメカニズムにより、承認された1つ以上の繰返し可能なSQL文の計画セットである、SQL計画ベースラインを構築できます。ベースラインの効果は、オプティマイザによる選択がベースライン内の確認済計画に限定されることです。
Oracle Database 12cから、データベースでは、適応SPMを使用できるようになりました。SPM展開アドバイザは、スケジュールされたメンテナンス・ウィンドウで毎日実行され、すべての承認されていない計画をランク付けし、ウィンドウの期間内にできるだけ多くの計画のテスト実行を行います。SPM展開アドバイザは、SQL計画ペースラインで最もコストの低い承認済計画を選択し、承認されていない各計画と比較します。承認されていない計画が既存の承認済の計画よりもパフォーマンスが高い場合、アドバイザが自動的にその計画を承認します。そうでない場合、アドバイザでは、その計画を未承認のままにして、最後の確認日を更新します。
関連項目:
SQL計画管理の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください
