データベース管理者の概念

このページのスクリプト・コンテンツはナビゲーションのみを目的としており、いかなる方法においても内容を変更するものではありません。

この部では、データベース管理者の業務、ツールおよび不可欠な知識について説明します。

データベース管理者の業務

データベース管理者(DBA)の主要な役割は、企業データをユーザーに対して利用可能にすることです。

DBAは、アプリケーションがデータベースを効率よく使用できるよう、開発者と緊密に連携する必要があり、また、物理リソースを適切に保ち、効率よく使用できるよう、システム管理者と緊密に連携する必要があります。

Oracle DBAは、Oracle AI Databaseアーキテクチャおよびデータベースの機能を理解している必要があります。DBAは、次のタスクを実行します。

ユーザーのタイプ、ロール、および責任は、データベース環境によって決まります。小規模なデータベースでは、DBAが1人の場合があります。一方、非常に大規模なデータベースでは、セキュリティ管理者、バックアップ・オペレータ、アプリケーション管理者など、複数のスペシャリストがDBAの仕事を分担する場合があります。

関連情報:

データベース管理者向けのツール

Oracleでは、データベースを管理するためのいくつかのツールを提供しています。

この項では、一般的に使用されるいくつかのツールについて説明します。

Oracle Enterprise Manager

Oracle Enterprise Manager (Enterprise Manager)は、Oracleデータベース、Exadataデータベース・マシン、Fusion Middleware、Oracle applications、サーバー、ストレージおよびOracle以外のハードウェアおよびソフトウェアの管理を提供するWebベースのシステム管理ツールです。

Oracle Enterprise Manager Cloud Control

Oracle Enterprise Manager Cloud Control (Cloud Control)は、Webベースのインタフェースで、これにより管理者は、Oracleテクノロジ・スタックおよび非Oracleコンポーネント全体を完全に監視できます。

高速アプリケーション通知(FAN)のコンポーネントが使用できなくなったり、パフォーマンスの問題が発生したりする場合があります。この場合、Cloud Controlに自動生成されたアラートが表示されるため、管理者が適切なリカバリ・アクションを実行できます。

Cloud Controlのコンポーネントには、次のものがあります。

関連情報:

Oracle Enterprise Manager Database Express 12c

Oracle Enterprise Manager Database Express (EM Express)は、Oracleデータベース内に組み込まれたWeb管理製品です。特別なインストールまたは管理は必要ありません。

EM Expressには、Cloud Controlの主要なパフォーマンス管理および基本管理のページが含まれます。これらのページには、次のものがあります。

これらの機能には、オンラインではEM Expressコンソールを介してアクセスでき、オフラインではActive Reportsテクノロジを介してアクセスできます。アーキテクチャ上の観点から見ると、EM Expressには中間層またはミドルウェア・コンポーネントがなく、データベース・サーバーでのオーバーヘッドはごくわずかになることは確実です。

EM Expressを使用すると、ユーザー・セキュリティの管理、データベース・メモリーおよび記憶域の管理など、管理タスクを実行できます。また、データベースのパフォーマンスおよびステータス情報を表示できます。

関連項目: EM Expressを使用したデータベースの管理方法を学習するには、『Oracle AI Databaseパフォーマンス・チューニング・スタート・ガイド』を参照

SQL*Plus

SQL*Plusは、Oracle AI Databaseのすべてのインストール時に含まれる、対話型のバッチ問合せツールです。

これには、データベースへの接続時にクライアントとして機能するコマンドライン・ユーザー・インタフェースが備わっています。SQL*Plusには独自のコマンドと環境があります。ここでは、SQL、PL/SQL、SQL*Plus、オペレーティング・システム・コマンドを入力および実行し、次のタスクを実行できます。

SQL*Plusを使用してレポートを対話形式で作成したり、バッチ・プロセスとしてレポートを生成したり、結果をテキスト・ファイル、画面、HTMLファイルに出力してインターネットで閲覧できます。HTML出力機能を使用して動的にレポートを生成できます。

関連項目: SQL*Plusについてさらに学習するには、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください

データベースのインストールおよび構成ツール

Oracleでは、Oracle AI Databaseソフトウェアのインストール・タスクおよび構成タスクを簡単にするためのいくつかのツールを提供しています。

次の表に、サポートされているツールを示します。

表1データベースのインストールおよび構成ツール

ツール 摘要 詳細を表示するには
Oracle Universal Installer (OUI) OUIは、Oracle AI Databaseソフトウェアを表示、インストールおよびアンインストールできるGUIユーティリティであります。オンライン・ヘルプがあり、ガイドに従ってインストールできます。 インストールをガイドするオンライン・ヘルプ
Database Upgrade Assistant(DBUA) DBUAを使用すると、対話形式のガイドに従ってデータベースをアップグレードし、新規リリースに応じてデータベースを構成できます。DBUAでは、通常は手動で実行されるタスクをすべて実行することによって、アップグレードを自動化します。DBUAでは、表領域やオンラインREDOログなどの構成オプションに対して推奨を作成します。 DBUAを使用したデータベースのアップグレード方法を学習するには、『Oracle AI Database 2日でデータベース管理者』を参照してください
Database Configuration Assistant (DBCA) DBCAには、データベースを作成し、構成するためのグラフィカル・インタフェースおよびガイド付きワークフローが用意されています。このツールを使用すると、Oracle提供のテンプレートからデータベースを作成したり、独自のデータベースやテンプレートを作成できます。 DBCAを使用したデータベースの作成方法を学習するには、『Oracle AI Database管理者ガイド』を参照

Oracle Netの構成および管理ツール

Oracle Net Servicesは、分散型異機種間コンピューティング環境において、企業全体の接続性ソリューションを提供します。Oracle NetはOracle Net Servicesのコンポーネントであり、クライアント・アプリケーションからデータベースへのネットワーク・セッションも確立できます。

次のツールを使用して、Oracle Net Servicesを構成および管理できます。

関連情報:

データの移動および分析ツール

Oracle AI Databaseでは、データの移動および分析を支援するいくつかのユーティリティを提供しています。

たとえば、データベース・ユーティリティを使用して、次のことを実行できます。

表2データの移動および分析のタスク

タスク 詳細を表示するには
オペレーティング・システム・ファイルからOracle AI Databaseの表にデータをロードします 「SQL*Loader」
あるデータベースから別のデータベースにデータおよびメタデータを移動する 『Oracle Data Pump Export and Import』
SQLインタフェースを介してREDOログ・ファイルを問い合せる 「Oracle LogMiner」
Oracle AI Databaseデータの管理 「ADRコマンド・インタプリタ(ADRCI)」

その他のタスクには、DBVERIFYユーティリティを使用したオフライン・データベースまたはデータファイルに対する物理データ構造の整合性チェックの実行や、DBNEWIDユーティリティを使用した運用データベースのデータベース識別子(DBID)またはデータベース名の変更などがあります。

注意:

関連情報:

SQL*Loader

SQL*Loaderは、データ・ファイルと呼ばれる外部ファイル(内部的なデータベースのデータ・ファイルと混同しないでください)からデータベース表にデータをロードする。SQL*Loaderには、データファイル内のデータの形式にほとんど制限のない強力なデータ解析エンジンがあります。

SQL*Loaderを使用して、次のことが可能です。

一般的なSQL*Loaderセッションでは、SQL*Loaderの制御ファイルと1つ以上のデータ・ファイルが入力に使用されます。出力は、Oracleデータベース、ログ・ファイル、不良ファイル、および場合によっては廃棄ファイルです。次の図に、典型的なSQL*Loaderセッションのフローを示します。

図1: SQL*Loaderセッション

画像cncpt271.gifの説明

SQL*Loaderエクスプレス・モードを使用することもでき、次の例のように、SQL*Loaderコマンドでtableパラメータを指定するとアクティブになります。

% sqlldr hr table=employees

制御ファイルが使用できないため、SQL*Loaderが使用しやすくなります。制御ファイルを解析するかわりに、SQL*Loaderでは表列定義を使用して、入力データ型を確認します。SQL*Loaderは、文字セット、フィールド・デリミタ、そしてデータ・ファイル、ログ・ファイルおよび不良ファイルの名前など、複数のデフォルト推測を作成します。デフォルト値の多くは、コマンドライン・パラメータでオーバーライドできます。

関連情報:

Oracle Data Pumpのエクスポートおよびインポート

Oracle Data Pumpにより、データベース間でデータとメタデータを高速で移動できます。

このテクノロジは、次のOracle AI Databaseデータ移動ユーティリティのベースとなります。

Oracle Data Pumpは、次のような部分から構成されています。

次の図に、Oracle Data PumpをSQL*Loaderおよび外部表と統合する方法を示します。図に示すように、SQL*Loaderは外部表APIおよびData Pump APIに統合され、データを外部表にロードします。Oracle Enterprise Manager Cloud Control (Cloud Control)やトランスポータブル表領域などのクライアントでは、Oracle Data Pumpインフラストラクチャを使用できます。

図2: Oracle Data Pumpアーキテクチャ

画像cncpt261.pngの説明

関連情報:

Oracle LogMiner

Oracle LogMinerを使用すると、SQLインタフェースを介してREDOログ・ファイルを問い合せることができます。

REDOログ・ファイルに含まれるデータの使用方法を次に示します。

LogMinerには、コマンドライン・インタフェースまたはEnterprise Managerの一部であるOracle LogMiner Viewer GUIを介してアクセスできます。

関連項目: LogMinerについてさらに学習するには、『Oracle AI Databaseユーティリティ』を参照してください

ADRコマンド・インタプリタ(ADRCI)

ADRCIは、問題の調査、ヘルス・チェック・レポートの表示、および最初の障害データのパッケージ化とOracle Supportへのアップロードを可能にするコマンドライン・ユーティリティです。

また、このユーティリティでは、自動診断リポジトリ(ADR)内のトレース・ファイルの名前を表示したり、アラート・ログを表示できます。ADRCIには、対話形式またはスクリプト内で使用できる豊富なコマンド・セットが用意されています。

関連情報:

データベース管理者のためのトピック

この項では、他の箇所で説明されていないDBAに不可欠なトピックについて説明します。

バックアップとリカバリ

バックアップおよびリカバリとは、メディア障害またはユーザー・エラーによるデータ損失に対するデータベースの保護に関連する、一連の概念、プロシージャおよび計画です。

バックアップとは、データのコピーです。バックアップには、データファイル、サーバー・パラメータ・ファイル、制御ファイルなど、データベースの重要な部分が含まれる場合があります。バックアップおよびリカバリが必要になる一例として、ディスク・ドライブの障害によりデータファイルが失われた場合などがあります。失われたファイルのバックアップが存在する場合は、ファイルをリストアおよびリカバリできます。データの損失が発生した前の状態へのリストアにかかわる操作は、メディア・リカバリと呼ばれます。

この項では、次のトピックについて説明します:

関連情報:

バックアップおよびリカバリ方法

Recovery Managerとユーザーによる管理方法のいずれかを使用して、Oracleデータベースをバックアップ、リストアおよびリカバリできます。

この2つのアプローチの主な違いは次のとおりです。

関連情報:

Recovery Managerのアーキテクチャ

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は、外部にあるリカバリ・カタログをバックアップ・メタデータで更新できます。

図3: RMANアーキテクチャ

画像cncpt318.gifの説明

使用するバックアップおよびリカバリ方法に関係なく、Oracleでは高速リカバリ領域を構成することをお薦めします。このデータベース管理されるディレクトリ、ファイル・システムまたはOracle ASMディスク・グループは、アクティブな制御ファイル、オンラインおよびアーカイブREDOログ・ファイル、バックアップなど、バックアップ・ファイルおよびリカバリ・ ファイルを一元化します。Oracle AI Databaseのリカバリ・コンポーネントは、高速リカバリ領域と対話し、データベースのリカバリ可能性を保証します。

関連情報:

データベース・バックアップ

データベース・バックアップは、物理または論理のいずれかです。

物理バックアップはバックアップおよびリカバリ方針の中心概念であり、物理データベース・ファイルのコピーです。物理バックアップを作成するには、RMANユーティリティを使用する方法と、オペレーティング・システムのユーティリティを使用する方法があります。

これに対して、論理バックアップには、表、ストアド・プロシージャおよびその他の論理データが含まれます。Data Pump ExportなどのOracle AI Databaseユーティリティを使用して論理データを抽出し、バイナリ・ファイルに格納できます。論理バックアップは、物理バックアップを補足できます。

物理バックアップは粒度が粗く、トランスポータビリティが制限されていますが、非常に高速です。論理バックアップは粒度が細かく、トランスポータビリティは完全ですが、物理バックアップより低速です。

データベース全体のバックアップと部分バックアップ

データベース全体のバックアップとは、データベース内のすべてのデータファイルと制御ファイルのバックアップのことだ。これは最も一般的なタイプのバックアップです。

部分データベース・バックアップには、個々の表領域またはデータファイルであるデータベースのサブセットが含まれます。表領域バックアップとは、表領域内のすべてのデータファイルまたは複数の表領域内のすべてのデータのバックアップです。一貫性の有無にかかわらず、表領域バックアップが有効なのは、データベースがARCHIVELOGモードで稼働している場合のみで、これは、リストア後の表領域とデータベースの他の領域との一貫性を保つにはREDOが必要となるためです。

一貫性バックアップと非一貫性バックアップ

データベース全体のバックアップは、一貫性バックアップか非一貫性バックアップのいずれかです。

一貫性バックアップでは、すべての読取り/書込みデータファイルおよび制御ファイルのチェックポイント SCNが同じであり、このSCNまでのすべての変更が確実にこれらのファイルに格納されます。このタイプのバックアップでは、リストア後にリカバリする必要はありません。

データベースの一貫性バックアップは、一貫性が保たれた状態停止した後にのみ実行できます。これは、NOARCHIVELOGモードで稼働しているデータベースに対して有効な唯一のバックアップ・オプションです。他のバックアップ・オプションでは、一貫性のためメディア・リカバリを必要としますが、これはアーカイブREDOログ・ファイルを適用しなければ不可能です。ノート: REDOを適用せずにデータベース全体の一貫性バックアップをリストアすると、バックアップ後に実行されたトランザクションはすべて失われます。

非一貫性バックアップでは、読込み/書込みデータファイルおよび制御ファイルのチェックポイントSCNが同じであるという保証はなく、変更が失われる場合があります。バックアップを実行している間もデータファイルが変更されることがあるため、すべてのオンライン・バックアップは必然的に非一貫性です。

非一貫性バックアップは、データベースを完全に保護するためのバックアップを作成するためにデータベースを停止する必要がないため、優れた可用性を提供します。ARCHIVELOGモードでデータベースを実行する場合、アーカイブREDOログおよびデータファイルをバックアップする場合は、非一貫性バックアップを堅実なバックアップおよびリカバリ計画の基礎とできます。

関連情報:

バックアップ・セットとイメージ・コピー

RMANのBACKUPコマンドでは、イメージ・コピーまたはバックアップ・セットが生成されます。

バックアップ・タイプは次のように異なります。

関連項目:バックアップ・セットおよびイメージ・コピーについてさらに学習するには、『Oracle AI Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

データ修復

データベースの通常の機能が停止するような問題、およびI/O処理に影響を及ぼす問題は数多くありますが、一般的に、DBAが介入してデータを修復する必要があるのは一部の問題のみです。

データの修復は、通常、次の場合に必要です。

一般的に、これらの問題の解決方法は複数あります。この項では、これらの解決方法について説明します。

関連情報:

Oracle Flashback Technology

Oracle AI Databaseでは、Oracle Flashback Technologyと呼ばれる機能グループが提供されており、バックアップをリストアせずに、過去のデータの状態を表示することや、バックアップに応じてデータを前後に巻き戻すことができます。

データベースの変更内容にもよりますが、フラッシュバック機能では、メディア・リカバリよりも迅速に、可用性に及ぼす影響も少なく、不要な変更を元に戻すことができます。バックアップおよびリカバリに最適なフラッシュバック機能には、次のものがあります。

関連情報:

ブロック・メディアのリカバリ

ブロック・メディア・リカバリは、データファイルをオンラインの状態に保ったまま、破損データ・ブロックをリストアしてリカバリするテクニックです。

ブロック破損とは、認識されているOracle形式ではないデータ・ブロック、または内容の一貫性が内部で保持されていないデータ・ブロックです。ブロックの破損を検出したときに、破損が少数のブロックのみに限定されている場合は、データファイル・リカバリよりもブロック・リカバリが適しています。

関連情報:

データファイルのリカバリ

データファイル・リカバリは、消失または破損した現行のデータファイルまたは制御ファイルを修復します。また、表領域がOFFLINE NORMALオプションを設定せずにオフラインになったときに消失した変更をリカバリします。

データファイルまたは制御ファイルのバックアップをリストアする場合、またはデータファイルがOFFLINE NORMALオプションを設定せずにオフラインになった場合は、メディア・リカバリが必要です。オンライン・データファイルがメディア・リカバリを必要とする場合、またはメディア・リカバリを必要とするデータファイルをメディア・リカバリの完了までオンラインにできない場合、データベースはオープンできません。

データファイルまたは制御ファイルの物理バックアップをリストアするには、それを再構築してOracle AI Databaseで使用可能にします。バックアップのリカバリとは、アーカイブREDOログ・ファイルを適用して、消失した変更を再構築することです。RMANでは、前回のバックアップ後に変更されたデータ・ブロックのみを含む増分バックアップを使用して、データファイルをリカバリすることもできます。

変更がオンライン・ファイルに自動的に適用されるインスタンス・リカバリとは異なり、メディア・リカバリでは、ユーザーによる起動が必要であり、リストアされたバックアップにアーカイブREDOログ・ファイルが適用されます。データファイルのメディア・リカバリは、オフライン・データファイルか、データベース・インスタンスによりオープンされていないデータベースのデータファイルにのみ機能します。

データファイル・メディア・リカバリは、すべての変更を適用するかどうかで異なります。

関連情報:

Zero Data Loss Recovery Appliance

クラウド規模のZero Data Loss Recovery Appliance (リカバリ・アプライアンスとして一般的に知られている)は、企業におけるすべてのOracleデータベースのデータ損失とバックアップのオーバーヘッドを大幅に削減するためのエンジニアド・システムである。

リカバリ・アプライアンスはRMANと統合されており、クラウド規模で耐障害性の高いハードウェアと記憶域を使用して、多数のデータベースに対する集中管理されたバックアップとリカバリの計画をデプロイします。リカバリ・アプライアンスでは、継続してバックアップのリカバリ可能性が検証されます。

リカバリ・アプライアンスの利点

集中管理されたリカバリ・アプライアンスは大部分のデータベース・バックアップとリストア処理を実行し、記憶域使用率、パフォーマンス、およびバックアップの管理性の効率を高めます。

主な利点は次のとおりです。

リカバリ・アプライアンス環境

保護対象のデータベースは、データをリカバリ・アプライアンスにバックアップするクライアント・データベースである。

次の図に、6つの保護対象データベースと2つのリカバリ・アプライアンスを含むサンプルの環境を示します。それぞれのデータベースは、そのバックアップにZero Data Loss Recovery Applianceバックアップ・モジュール(リカバリ・アプライアンス・バックアップ・モジュール)を使用します。このモジュールはRMANがネットワーク経由でバックアップをリカバリ・アプライアンスに転送する、Oracle提供のSBTライブラリです。

図4: リカバリ・アプライアンス環境

図amagd_vm_025.pngの説明

リカバリ・アプライアンスごとに存在するリカバリ・アプライアンス・メタデータのデータベースは、リカバリ・カタログに保存されているメタデータを管理します。バックアップをリカバリ・アプライアンスに送信する保護対象データベースはすべて、このリカバリ・カタログを使用する必要があります。バックアップは、Oracle ASMディスク・グループ・セットであるリカバリ・アプライアンスの記憶域の場所にあります。ノート:データベースは、リカバリ・アプライアンスをバックアップ・リポジトリとしては使用せずに、リカバリ・カタログとして使用することがあります。

管理者はCloud Controlを使用して環境を管理および監視します。Cloud Controlでは、バックアップが存在する場所(ディスク、テープまたは別のリカバリ・アプライアンス)にかかわらず、各データベースの バックアップ・ライフサイクル全体を一眼で把握することができます。

メモリー管理

メモリー管理では、データベースでの需要の変化に応じて、Oracleインスタンスのメモリー構造の最適なサイズを維持する必要があります。初期化パラメータ設定により、SGAおよびインスタンスPGAメモリーの管理方法が決まります。図22-5に、メモリー管理オプションのデシジョン・ツリーを示します。次の各項では、各オプションの詳細を説明します。

図5: メモリー管理方法

画像cncpt242.gifの説明

自動メモリー管理

自動メモリー管理では、Oracle AI DatabaseによりSGAおよびインスタンスPGAメモリーが完全に自動管理されます。最もシンプルなこの方法を使用することをお薦めします。

ユーザー指定の制御は、ターゲット・メモリー・サイズ初期化パラメータ(MEMORY_TARGET)と、オプションの最大メモリー・サイズ初期化パラメータ(MEMORY_MAX_TARGET)のみです。Oracle AI Databaseは、ターゲット・メモリー・サイズに合わせて調整され、必要に応じて、SGAとインスタンスPGAの間でメモリーを再配布します。

SGAには、インメモリー列ストア(IM列ストア)またはmemoptimizeプールを含めることができます(いずれもオプションです)。使用するメモリー管理方法にかかわらず、IM列ストアのサイズ設定にはINMEMORY_SIZE初期化パラメータを使用し、memoptimizeプールのサイズ設定にはMEMOPTIMIZE_POOL_SIZE初期化パラメータを使用します。IM列ストアのサイズとmemoptimizeプールはメモリー・ターゲットに含まれますが、自動サイズ変更アルゴリズムによる管理対象ではありません。たとえば、MEMORY_TARGETを5 GBに設定し、INMEMORY_SIZEを1 GBに設定した場合、全体的なメモリー・ターゲットは5 GB (6 GBではない)で、INMEMORY_SIZEは常に1 GBです。

次の図に、オンライン・ユーザーにより発行されたジョブを必要に応じて処理したり、バッチ・ジョブを処理するデータベースを示します。自動メモリー管理を使用すると、データベースは実行するジョブのタイプに応じて、自動的にラージ・プールとデータベース・バッファ・キャッシュのサイズを調整します。以下の図にはIM列ストアおよびメモリー最適化領域は示されていない点に注意してください。

図6: 自動メモリー管理

画像cncpt256.gifの説明

DBCAでデータベースを作成し、基本インストール・オプションを選択した場合、Oracle AI Databaseではデフォルトで自動メモリー管理が有効化されます。

関連情報:

SGAの共有メモリー管理

自動共有メモリー管理を使用してSGAサイズを設定するか、手動でSGAコンポーネントをチューニングすることで、SGAのサイズを手動で制御できます。

自動メモリー管理が有効でない場合、システムはSGAに共有メモリー管理を使用します。共有メモリー管理では、次のいずれかのモードを選択できます。

関連情報:

インスタンスPGAのメモリー管理

自動メモリー管理が有効でない場合は、Oracle AI Databaseは自動または手動のいずれかのPGAメモリー管理を使用します。

PGAメモリーの管理には、次のモードを指定できます。

関連項目: PGAメモリー管理について学習するには、『Oracle AI Databaseパフォーマンス・チューニング・ガイド』を参照してください

メモリー管理方法の概要

メモリー管理は、自動または手動のいずれかです。

自動メモリー管理を有効化しない場合は、SGAおよびPGAのそれぞれに対して個別にメモリー管理方法を構成する必要があります。ノート:自動メモリー管理がデータベース・インスタンス全体に対して無効の場合、Oracle Databaseではデフォルトで、自動PGAメモリー管理が有効になります。

次の表には、INMEMORY_SIZE初期化パラメータとMEMOPTIMIZE_POOL_SIZE初期化パラメータが含まれています。どちらも、オプションのメモリー領域を制御します。

表3メモリー管理方法

インスタンス SGA PGA 摘要 初期化パラメータ
自動 なし なし 1つのインスタンス・ターゲット・サイズに基づいてインスタンスのサイズがチューニングされます。

次のように設定します。

  • データベース・インスタンスの合計メモリー・ターゲット・サイズ(MEMORY_TARGET)

  • (オプション)データベース・インスタンスの最大メモリー・サイズ(MEMORY_MAX_TARGET)

  • SGA内のIM列ストアのオプションのサイズ(INMEMORY_SIZE)

なし 自動 自動

SGAはSGAターゲットに基づいて自動的にチューニングされます。

PGAはPGAターゲットに基づいて自動的にチューニングされます。

次のように設定します。

  • SGAのターゲット・サイズ(SGA_TARGET)

  • (オプション)SGAの最大サイズ(SGA_MAX_SIZE)

  • SGA内のIM列ストアのオプションのサイズ(INMEMORY_SIZE)

  • オプションでSGAのmemoptimizeプールのサイズ(MEMOPTIMIZE_POOL_SIZE)

  • PGA集計ターゲット・サイズ(PGA_AGGREGATE_TARGET)脚注1

データベースによってPGA_AGGREGATE_LIMIT初期化パラメータが自動的に構成されます。このパラメータは手動で設定できます。

なし 自動 手動

SGAはSGAターゲットに基づいて自動的にチューニングされます。

PGAは、各タイプのSQL演算子の作業領域の最大サイズを指定し、手動で制御します

次のように設定します。

  • SGAのターゲット・サイズ(SGA_TARGET)

  • (オプション)SGAの最大サイズ(SGA_MAX_SIZE)

  • SGA内のIM列ストアのオプションのサイズ(INMEMORY_SIZE)

  • オプションでSGAのmemoptimizeプールのサイズ(MEMOPTIMIZE_POOL_SIZE)

  • SORT_AREA_SIZE、HASH_AREA_SIZE、BITMAP_MERGE_AREA_SIZEなどのPGA作業領域パラメータ
なし 手動 自動

SGAは個々のコンポーネント・サイズを設定し、手動で制御します。

PGAはPGAターゲットに基づいて自動的にチューニングされます。

次のように設定します。

  • 共有プール・サイズ(SHARED_POOL_SIZE)

  • バッファ・キャッシュ・サイズ(DB_CACHE_SIZE)

  • ラージ・プール・サイズ(LARGE_POOL_SIZE)

  • Javaプール・サイズ(JAVA_POOL_SIZE)

  • SGA内のIM列ストアのオプションのサイズ(INMEMORY_SIZE)

  • オプションでSGAのmemoptimizeプールのサイズ(MEMOPTIMIZE_POOL_SIZE)

  • PGA集計ターゲット・サイズ(PGA_AGGREGATE_TARGET)脚注2

データベースによってPGA_AGGREGATE_LIMIT初期化パラメータが自動的に構成されます。このパラメータは手動で設定できます。

なし 手動 手動

SGAコンポーネント・サイズを手動で構成する必要があります。

PGAは各タイプのSQL演算子の作業領域の最大サイズを指定し、手動で制御します。

SGAコンポーネント・サイズを手動で構成する必要があります。次のように設定します。

  • 共有プール・サイズ(SHARED_POOL_SIZE)

  • バッファ・キャッシュ・サイズ(DB_CACHE_SIZE)

  • ラージ・プール・サイズ(LARGE_POOL_SIZE)

  • Javaプール・サイズ(JAVA_POOL_SIZE)

  • SGA内のIM列ストアのオプションのサイズ(INMEMORY_SIZE)

  • オプションでSGAのmemoptimizeプールのサイズ(MEMOPTIMIZE_POOL_SIZE)

  • SORT_AREA_SIZE、HASH_AREA_SIZE、BITMAP_MERGE_AREA_SIZEなどのPGA作業領域パラメータ

脚注1

データベースによってPGA_AGGREGATE_LIMIT初期化パラメータが自動的に構成されます。このパラメータを手動で設定するように選択することもできます。

脚注2

データベースによってPGA_AGGREGATE_LIMIT初期化パラメータが自動的に構成されます。このパラメータを手動で設定するように選択することもできます。

関連項目:自動メモリー管理が使用できないプラットフォームもありますので、『Oracle AI Database管理者ガイド』を参照してください。

リソース管理およびタスクのスケジューリング

Oracle AI Databaseには、リソースの管理およびユーザーへの影響を軽減するためのタスクのスケジュールに役立つツールが用意されています。

多数のユーザーがアクティブになるデータベースでは、リソース管理がデータベース管理の重要な部分になります。過度にリソースを消費するセッションのため、他のセッションの処理が停止することがあります。このため、最適なタイミングでタスクを実行するようタスクをスケジューリングする方法が問題となります。Oracle AI Databaseでは、これらの問題を解決するためのツールを提供しています。

データベース・リソース・マネージャ

Oracle AI Database Resource Manager(リソース・マネージャ)は、ユーザー・アカウント、アプリケーション、およびサービスに割り当てるデータベース・リソースを細かく制御します。リソース・マネージャは、主にゲートキーパーとして機能し、他のジョブを高速で実行できるように一部のジョブを低速で実行します。

DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用することで、オペレーティング・システムでは十分に管理できない次の多くのリソース割当ての問題が解決されます。

リソース・マネージャは、データベースでのハードウェア・リソース割当ておよびデータベース内の処理の優先順位付けの操作性を向上することによって、前述の問題に対応します。セッションをセッション属性に基づいてグループに分類し、これらのグループにリソースを割り当てることで、ハードウェアの利用率を最適化できます。リソース・マネージャを使用して、PDBメモリー消費の制限を設定できます。

リソースは、データベース管理者が指定したリソース・プランに従ってユーザーに割り当てられます。リソース・プランは、リソース要件に従ってグループ化されたユーザー・セッションである、リソース・コンシューマ・グループ間でのリソースの分配方法を指定します。リソース・プラン・ディレクティブは、リソース・コンシューマ・グループをプランに関連付け、グループにリソースを割り当てる方法を指定します。図22-7に、昼間にOLTPアプリケーションとレポート・アプリケーションを同時に実行する組織で使用する簡単なリソース・プランを示します。現在アクティブなプランDAYTIMEによって、3つのリソース・コンシューマ・グループにCPUリソースが割り当てられます。具体的には、CPUタイムの75%がOLTPに、15%がREPORTSに、残りの10%がOTHER_GROUPSに割り当てられています。

図7: 簡単なリソース・プラン

画像admin078.gifの説明

リソース・マネージャで解決できる問題の1つは、SQLモニターを使用して監視できるランナウェイ問合せです。リソース・マネージャを使用すると、ランナウェイSQL文を特定して対応するためのしきい値を指定できます。たとえば、CPU時間、経過時間、物理I/Oまたは論理I/Oのしきい値と、コンシューマ・グループの各前面プロセスによるPGA使用量を指定できます。リソース・マネージャは対応として、優先度の低いコンシューマ・グループへの切替え、SQL文の終了、またはしきい値違反のログ記録を行うことができます。

関連情報:

CPU管理

Oracle AI Database 26ai以降、Oracleは、サーバー上のすべてのデータベース・インスタンス間で動作するCPUリソース管理の代替方法を提供します。

以前のリリースでは、データベース・インスタンス内で動作する、CPUリソース管理の1つの方法が提供されていました。Oracle AI Database 26ai以降では、RESOURCE_MANAGER_CPU_SCOPEを設定してCPUリソース管理の範囲を制御できます。このパラメータを使用すると、2つの制御方法から選択することができます。

RESOURCE_MANAGER_CPU_SCOPEをSERVER_WIDEに設定すると、サーバー・レベルのインスタンス間のCPUリソース管理が有効になります。Oracle AI Database 26aiで導入されたこの方法は、複数のデータベース・インスタンスが1人のLinuxサーバーを共有する場合に使用できます。これにより、サーバー上のすべてのデータベース・インスタンスにわたるCPUリソース管理が可能になります。この方法を使用すると、Oracleは、目的のCPU共有およびCPU使用率制限を使用してLinux制御グループ(cgroups)を自動的に構成し、データベース・セッションを適切なcgroupに配置します。

RESOURCE_MANAGER_CPU_SCOPEは、デフォルトでINSTANCE_ONLYに設定されます。

関連情報:

Oracle Scheduler

Oracle Scheduler (スケジューラ)を使用すると、データベース管理者とアプリケーション開発者はデータベース環境で各種タスクが発生する時期と場所を制御することができます。

スケジューラには、企業向けの複雑なスケジューリング機能が用意されており、次の操作を実行できます。

プログラム・オブジェクト(プログラム)には、引数のデフォルト値を含む、スケジューラで実行されるコマンドに関するメタデータが含まれます。スケジュール・オブジェクト(スケジュール)には、実行日時および反復パターンに関する情報が含まれます。ジョブ・オブジェクト(ジョブ)は、プログラムをスケジュールに対応付けます。実行するジョブおよびその時間を定義するには、プログラム、スケジュール、およびジョブ間の関係を割り当てます。

スケジューラは、DBMS_SCHEDULER PL/SQLパッケージ内の一連のファンクションおよびプロシージャとして実装されています。このパッケージまたはEnterprise Managerを使用して、スケジューラ・オブジェクトを作成および操作します。スケジューラ・オブジェクトは標準データベース・オブジェクトであるため、システム権限およびオブジェクト権限により、これらのオブジェクトへのアクセスを制御できます。図22-8に、スケジューラの基本アーキテクチャを示します。ジョブ表はすべてのジョブのコンテナであり、各データベースに1つの表を持っています。ジョブ・コーディネータ・バックグラウンド・プロセスは、必要に応じて自動的に起動および停止します。ジョブ子プロセスは、ジョブの実行時間になるとジョブ・コーディネータによって起動されます。子プロセスはジョブ表からメタデータを収集し、ジョブを実行します。

図8: スケジューラ・コンポーネント

画像admin062.gifの説明

関連情報:

パフォーマンスおよびチューニング

DBAは、対象とするOracle Databaseのパフォーマンスを適切に保つ責任を担っています。一般的に、パフォーマンス上の問題は、許容されないレスポンス時間(特定のワークロードを完了するためにかかる時間)またはスループット(特定の時間内で完了できる作業量)によって発生します。

典型的な問題が生じるのは、以下のような場合です。

チューニングの一般的な目標は通常、レスポンス時間の短縮、スループットの向上、またはその両方です。具体的で測定可能な目標は、「指定されたSELECT文のレスポンス時間を5秒以下に短縮する」ことです。この目標を達成できるかどうかは、DBAが制御できる要因とできない要素によって変わります。一般的に、チューニングは、データベース・リソースを可能なかぎり効率的に使用することによって、具体的かつ測定可能、および達成可能なチューニング目標を達成するための作業です。

Oracleパフォーマンス・メソッドは、データベース内のボトルネックの識別と解消、および効率的なSQL文の開発に基づいています。Oracleパフォーマンス・メソッドには、次のタスクが含まれます。

この項では、アドバイザの使用など、Oracle AI Databaseパフォーマンス・チューニングの基本的な事柄を説明します。Oracle AI Databaseアドバイザは、領域、パフォーマンスおよびUNDO管理を含んだ広範囲に及んだデータベース管理の主要な問題の解決に対し、特別なアドバイスを提供します。

データベースの自己監視

データベースは通常の処理を実行しながら、問題の発生時にすぐに問題を検知できるように自己を監視しています。Oracle AI Databaseでは、サーバー生成アラートを送信して、差し迫った問題を通知できます。

アラートは、問題が発生した場合、または毎秒物理読取りまたはSQLレスポンス時間などのメトリックの予想値とデータが一致しない場合に、自動的に生成されます。メトリックとは、累積的な統計における変化の割合のことです。サーバー生成アラートは、ユーザー指定のしきい値に基づいて、またはイベントの発生に従って生成されるように設定できます。

サーバー生成アラートは問題を特定するだけでなく、報告された問題の解決方法も推奨します。たとえば、高速リカバリ領域の不足を通知するアラートでは、不要になった古いバックアップを削除するか、追加のディスク領域を追加するように推奨されます。

関連項目: 『Oracle AI Database管理者ガイド』

自動ワークロード・リポジトリ(AWR)

自動ワークロード・リポジトリ(AWR)は、システム、セッション、個々のSQL文、セグメントおよびサービスの累積統計など、履歴パフォーマンス・データを保存するリポジトリである。

AWR統計は、パフォーマンスのチューニングなどの基礎となります。AWRは問題の検出とチューニングに利用されるデータベース統計を自動的に集計し、データベースの自己管理において重要な役割を果します。

次の図に示すように、データベースは最新のAWR統計をSGAに格納します。デフォルトでは、MMONプロセスは、1時間ごとに統計を収集し、AWRスナップショットを作成します。AWRスナップショットは、ある時点で取得されたパフォーマンス統計セットです。データベースは、スナップショットをSYSAUX表領域を書き込みます。AWRは、スナップショット領域を管理し、構成可能なスナップショット保存ポリシーに従って古いスナップショットをパージします。

図9: 自動ワークロード・リポジトリ(AWR)

画像cncpt279.gifの説明

AWRベースラインは統計率の集合であり、通常、ピーク負荷時にはシステムが良好に動作していたときに取得されたものが使用されます。一対または一定の範囲のAWRスナップショットをベースラインとして指定できます。AWRレポートを使用して、パフォーマンスが低下したときに取得した統計とベースラインを比較することによって問題を診断できます。

AutoTaskと呼ばれる自動メンテナンス・インフラストラクチャは、Oracle DatabaseがどのようにAWRを使用して自己管理を行っているかを示します。AWRデータを分析することによって、AutoTaskはメンテナンス・タスクの必要性を判断し、必要なメンテナンス・タスクがOracle Schedulerメンテナンス・ウィンドウで実行されるようにスケジュールします。タスクの例としては、オプティマイザの統計の収集や自動セグメント・アドバイザの実行があります。

関連情報:

自動データベース・モニター(ADDM)

AWR (自動ワークロード・リポジトリ)で取得された統計を使用して、ADDMは、データベース・パフォーマンスを自動的および予防的に診断し、識別された問題の解決方法を決定します。ADDMは手動でも実行できます。Automatic Database Diagnostic Monitor (ADDM)はOracle Databaseに組み込まれているセルフアドバイザです。

ADDMでは、コンポーネント間の共通判断尺度として時間を使用し、システムのパフォーマンスに対して総合的にアプローチします。ADDMは、最も時間のかかっているOracle Databaseの領域を特定します。たとえば、データベースが使用可能なデータベース・バッファの待機に長時間費やしていると想定します。ADDMは、単に症状を示すのではなく、問題を掘り下げて根本原因を特定し、その問題がOracle Database全体に及ぼす影響を報告します。プロセス中のオーバーヘッドは、最小限に抑えられています。

ほとんどの場合、ADDMは解決策を推奨し、パフォーマンス向上の予想を数量化します。たとえば、ADDMはハードウェア、データベース構成、データベース・スキーマまたはアプリケーションを変更するよう推奨します。ADDMは、推奨を行う場合、時間的な利点を報告します。時間を尺度として使用することによって、問題と推奨の利点を比較検討できます。

潜在的なパフォーマンスの問題報告に加え、ADDMは、問題のないデータベース領域を示します。I/Oやメモリーなど、データベース・パフォーマンスに大きな影響を与えないサブコンポーネントは、初期段階で分類ツリーから除かれます。ADDMではこれらのサブコンポーネントがリストされるため、管理者はそれらの領域での処理による成果が少ないことを速やかに理解できます。

関連項目: 『Oracle AI Databaseパフォーマンス・チューニング・スタート・ガイド』および『Oracle AI Databaseパフォーマンス・チューニング・ガイド』

アクティブ・セッション履歴(ASH)

アクティブ・セッション履歴(ASH)では、アクティブなデータベース・セッションが毎秒サンプリングされ、データがメモリーおよび永続ストレージに書き込まれます。ASHはデータベース自己管理フレームワークの重要な部分であり、パフォーマンス上の問題を診断する場合に役立ちます。

インスタンス・レベルで統計を集計する自動ワークロード・リポジトリ(AWR)とは異なり、ASHはセッション・レベルで統計を集計します。アクティブ・セッションとは、CPUを使用しているセッションで、アイドル待機クラスのイベントを待機していないセッションのことです。

Enterprise ManagerまたはSQLスクリプトを使用してASHレポートを生成し、指定した期間に集計されたセッション統計を取得できます。ASHレポートは、次の目的に使用できます。

たとえば、10:00 p.m.から10:02 p.m.の間にデータベースの速度が低下したという報告をあるユーザーから受け取ったとします。ただし、10:00 p.m.から11:00 p.m.までのAWRスナップショット間隔では、2分間のパフォーマンス低下は短すぎて、ADDMの結果には表示されません。ASHレポートは、このような一過性の問題の原因を特定する場合に役立ちます。

関連項目: 『Oracle AI Databaseパフォーマンス・チューニング・スタート・ガイド』および『Oracle AI Databaseパフォーマンス・チューニング・ガイド』

アプリケーションとSQLチューニング

Oracle Databaseは、SQLのチューニング処理を完全に自動化します。

ADDMは、システム・リソースを大量に使用し、それが原因でパフォーマンス上の問題を引き起こすSQL文を識別します。さらに、CPUと共有メモリーの使用量の観点で上位を占めるSQL文は、AWRに自動的に格納されます。高い負荷のSQL文の識別は、自動的に実施されるため、人的な介入は不要です。

EXPLAIN PLAN文

EXPLAIN PLAN文などのツールを使用すると、オプティマイザが選択した実行計画を表示できます。

EXPLAIN PLANは、指定したSQLの問合せが現行のセッション内で実行された場合の、その問合せに対する問合せ計画を示します。その他のツールは、Oracle Enterprise ManagerとSQL*Plus AUTOTRACEコマンドです。

関連項目: EXPLAIN PLANについて学習するには、Oracle AI Database SQL言語リファレンスを参照してください。

オプティマイザ統計アドバイザ

オプティマイザ統計アドバイザは、現在の統計収集の状況、既存の統計収集ジョブの有効性、および収集された統計の品質を分析する診断ソフトウェアです。オプティマイザ統計アドバイザは、自動データベース診断モニター(ADDM)、SQLパフォーマンス・アナライザおよびその他のアドバイザと同じアドバイザ・フレームワークを使用します。

オプティマイザ統計アドバイザは、ベスト・プラクティスに依存する従来のアプローチに次の利点を提供します。

オプティマイザ統計アドバイザは、アドバイザがそのチェックを実行する際に使用するOracle提供の標準であるルールを維持します。ルールにより、現在の機能セットに基づいてOracleのベスト・プラクティスを体現します。ベスト・プラクティスをリリースからリリースに変更すると、オプティマイザ統計アドバイザ・ルールも変更します。このように、アドバイザは、常に最新の推奨事項を提供します。

オプティマイザ統計アドバイザは、統計収集プロセスを検査してから、ルール違反の結果のレポートを生成します。アドバイザが推奨を行い、その推奨に基づいてアクションを提案する場合、ユーザーはそのアクションを自動的に実装するか、編集可能かつ実行可能なPL/SQLスクリプトを生成することができます。

アドバイザ・タスクは、メンテナンス・ウィンドウで自動的に実行されますが、オンデンドで実行することもできます。

関連情報:

SQLチューニング・アドバイザ

自動SQLチューニングのインタフェースはSQLチューニング・アドバイザで、これはシステム・メンテナンス期間中にメンテナンス・タスクとして自動的に実行されます。

それぞれの自動実行中、アドバイザはデータベース内の負荷の大きいSQL問合せを選択し、これらの問合せに対するチューニングの推奨設定を生成します。

SQLチューニング・アドバイザの推奨設定は、次のカテゴリに分類されます。

SQLプロファイルには、SQL文に固有の追加統計が含まれており、これによりオプティマイザでは改良された実行計画を生成できます。基本的には、SQLプロファイルが問合せを分析する方法です。アクセス・パスとSQL構造分析は、開発中のアプリケーションや社内で本番アプリケーションをチューニングする場合に役立ちます。

SQLチューニング・アドバイザの主要な利点は、外部ツールではなく、オプティマイザからソリューションが提供されることです。このため、チューニングは実行計画とSQLパフォーマンスを担当するデータベース・コンポーネントによって実行されます。チューニング処理では、SQL文の過去の実行統計が考慮され、その文に対するオプティマイザ設定がカスタマイズされます。

関連情報:

SQLアクセス・アドバイザ

SQLアクセス・アドバイザを使用すると、SQL問合せ分析およびスキーマ・オブジェクトの最適化や問合せのチューニングの方法の決定に役立ちます。

SQLアクセス・アドバイザは、データ・アクセス・パスを最適化する方法についてのアドバイスを提供します。具体的には、パーティション、マテリアライズド・ビュー、索引、マテリアライズド・ビュー・ログを使用してデータベース・パフォーマンスを向上させる方法が推奨されます。

パーティションや索引などのスキーマ・オブジェクトは、複雑でデータ集中型の問合せを最適化するために必要不可欠です。ただし、これらのオブジェクトの作成およびメンテナンスには時間がかかり、領域要件も重要になります。SQLアクセス・アドバイザでは、指定されたワークロードに対応するデータ構造を推奨し、この推奨をパフォーマンス目標の達成に役立てることができます。

SQLアクセス・アドバイザは、ウィザードを使用してEnterprise Managerから実行するか、DBMS_ADVISORパッケージを使用して実行できます。DBMS_ADVISORは、任意のPL/SQLプログラムからコール可能な分析およびアドバイザ用のファンクションおよびプロシージャの集合です。

関連項目: 『Oracle AI Databaseパフォーマンス・チューニング・スタート・ガイド』および『Oracle AI Database SQLチューニング・ガイド』

SQL計画管理

SQL計画管理を使用してテスト済計画と検証済計画のみを実行することで、SQL実行計画を管理します。

SQL計画管理(SPM)展開アドバイザは、スケジュールされたメンテナンス・ウィンドウで毎日実行され、すべての承認されていない計画をランク付けし、できるだけ多くの計画のテスト実行を行います。SPM展開アドバイザは、SQL計画ペースラインで最もコストの低い確定済計画を選択し、承認されていない各計画と比較します。承認されていない計画が既存の承認済の計画よりもパフォーマンスが高い場合、アドバイザが自動的にその計画を承認します。

高頻度SPMが有効になっている場合、メンテナンス・ウィンドウ外の定期的なバックグラウンド・タスクでSPM展開アドバイザが実行され、よりタイムリなパフォーマンス改善が可能になります。高頻度タスクは大量のシステム・リソースを使用するSQL文を特定し、以前に使用したSQL実行計画の方が高いパフォーマンスを期待できるかどうかをチェックします。そうである場合、新しいSQL計画ベースラインが作成され、以前のSQL実行計画が強制されてSQLパフォーマンスの低下が修復されます。

Oracle Database 26ai以降では、SQL文で新しいSQL実行計画が使用される場合に、リアルタイムSPMによるパフォーマンス分析が即時に開始されます。以前に見られたSQL実行計画のパフォーマンスが高い場合は、バックグラウンド・タスクに依存せずに、新しいSQL計画ベースラインが即座に作成されます。

関連情報: