Oracle® Database

管理者ガイド

11g リリース2(11.2)

B56301-08(原本部品番号:E25494-07)

2015年5月

Oracle Database管理者ガイド, 11g リリース2(11.2)

B56301-08

Copyright © 2001, 2015, Oracle and/or its affiliates.All rights reserved.

原本著者: Steve Fogel

原本協力著者: Caroline Johnston, Sheila Moore, Tony Morales, Padmaja Potineni, Randy Urbano, Lance Ashdown, Janis Greenberg

協力者: D.Austin、B.Baddepudi、H.Baer、C.Baird、M.Bauer、E.Belden、A.Chaudhry、J.Creighton、S.Datta、M.Dilman、J.Draaijer、M.Fallen、A.Ganesh、GP Gongloor、V.Goorah、S.Gupta、W.Hodak、P.Huey、C.Iyer、B.Khaladkar、B.Krishnan、V.Krishnaswamy、B.Kuchibhotla、S.Kumar、V.Kumar、P.Lane、A.Lee、B.Lee、S. K. Lee、C.Lei、Y.Li、I.Listvinsky、B.Llewellyn、B.Lundhild、S.Lynn、R.Mani、V.Marwah、C.McGregor、M.Minhas、K.Mohan、V.Moore、N.Mukherjee、S.Muthulingam、G.Ngai、A.Raghavan、M.Ramacher、R.Ramkissoon、Y.Sarig、S.Shankar、B.Sinha、V.Srihari、D.Steiner、J.Stern、M.Stewart、M.Subramaniam、A.Tran、A.Tsukerman、K.Umamageswaran、E.Voss、D. M. Wong、P.Youn、W.Zhang

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このマニュアルに記載されている新機能

- 管理者ガイドに記載されているOracle Database 11g リリース2(11.2.0.3)の新機能

- 管理者ガイドに記載されているOracle Database 11g リリース2(11.2.0.2)の新機能

- 管理者ガイドに記載されているOracle Database 11g リリース2(11.2.0.1)の新機能

第I部 基本データベース管理

1 データベース管理スタート・ガイド

- Oracle Databaseユーザーのタイプ

- データベース管理者

- セキュリティ管理者

- ネットワーク管理者

- アプリケーション開発者

- アプリケーション管理者

- データベース・ユーザー

- データベース管理者のタスク

- タスク1: データベース・サーバー・ハードウェアの評価

- タスク2: Oracle Databaseソフトウェアのインストール

- タスク3: データベースの計画

- タスク4: データベースの作成とオープン

- タスク5: データベースのバックアップ

- タスク6: システム・ユーザーの登録

- タスク7: データベース設計の実装

- タスク8: 実行データベースのバックアップ

- タスク9: データベースのパフォーマンス・チューニング

- タスク10: パッチのダウンロードとインストール

- タスク11: 追加ホストへのロール・アウト

- データベースに対するコマンドとSQLの発行

- SQL*Plusについて

- SQL*Plusを使用したデータベースへの接続

- 手順1: コマンド・ウィンドウのオープン

- 手順2: オペレーティング・システムの環境変数の設定

- 手順3: SQL*Plusの起動

- 手順4: SQL*PlusのCONNECT文の発行

- Oracle Databaseソフトウェアのリリースの識別

- リリース番号の形式

- データベースのバージョン番号

- データベースのメンテナンス・リリース番号

- Fusion Middlewareリリース番号

- コンポーネント固有のリリース番号

- プラットフォーム固有のリリース番号

- 現行のリリース番号のチェック

- データベース管理者のセキュリティと権限の概要

- データベース管理者のオペレーティング・システム・アカウント

- 管理ユーザー・アカウント

- SYS

- SYSTEM

- DBAロール

- データベース管理者の認証

- 管理権限

- SYSDBAとSYSOPER

- 管理権限での接続: 例

- データベース管理者の認証方式の選択

- セキュリティで保護されていないリモート接続

- ローカル接続およびセキュリティで保護されたリモート接続

- オペレーティング・システム認証の使用

- OSDBAとOSOPER

- オペレーティング・システム認証を使用するための準備

- オペレーティング・システム認証を使用した接続

- パスワード・ファイル認証の使用

- パスワード・ファイル認証を使用するための準備

- パスワード・ファイル認証を使用した接続

- パスワード・ファイルの作成とメンテナンス

- ORAPWDを使用したパスワードの作成

- ORAPWDコマンドライン引数の説明

- パスワード・ファイルの共有と無効化

- パスワード・ファイルへのユーザーの追加

- SYSDBAおよびSYSOPER権限の付与と取消し

- パスワード・ファイル・メンバーの表示

- パスワード・ファイルのメンテナンス

- パスワード・ファイルのユーザー数の追加

- パスワード・ファイルの削除

- データ・ユーティリティ

2 Oracle Databaseの作成および構成

- Oracle Databaseの作成の概要

- データベースを作成する前の考慮点

- データベース作成計画

- 作成の前提条件

- DBCAを使用したデータベースの作成

- 対話型DBCAを使用したデータベースの作成

- 非対話型(サイレント)DBCAを使用したデータベースの作成

- CREATE DATABASE文を使用したデータベースの作成

- 手順1: インスタンス識別子(SID)の指定

- 手順2: 必要な環境変数が設定されていることの確認

- 手順3: データベース管理者の認証方式の選択

- 手順4: 初期化パラメータ・ファイルの作成

- 手順5: (Windowsの場合のみ)インスタンスの作成

- 手順6: インスタンスへの接続

- 手順7: サーバー・パラメータ・ファイルの作成

- 手順8: インスタンスの起動

- 手順9: CREATE DATABASE文の発行

- 手順10: 追加の表領域の作成

- 手順11: スクリプトの実行によるデータ・ディクショナリ・ビューの作成

- 手順12: (オプション)スクリプトの実行による追加オプションのインストール

- 手順13: データベースのバックアップ

- 手順14: (オプション)インスタンスの自動起動の有効化

- CREATE DATABASE文の句の指定

- データベースの保護: ユーザーSYSおよびSYSTEMのパスワードの指定

- ローカル管理のSYSTEM表領域の作成

- SYSAUX表領域の概要

- 自動UNDO管理の使用: UNDO表領域の作成

- デフォルト永続表領域の作成

- デフォルト一時表領域の作成

- データベース作成時のOracle Managed Filesの作成

- データベース作成時のbigfile表領域のサポート

- デフォルトの表領域タイプの指定

- デフォルトの表領域タイプの上書き

- データベースのタイム・ゾーンとタイム・ゾーン・ファイルの指定

- データベースのタイム・ゾーンの設定

- データベースのタイム・ゾーン・ファイルの概要

- データベースのタイム・ゾーン・ファイルの指定

- FORCE LOGGINGモードの指定

- FORCE LOGGING句の使用

- FORCE LOGGINGモードのパフォーマンスに関する考慮点

- 初期化パラメータの指定

- 初期化パラメータと初期化パラメータ・ファイルの概要

- テキスト形式の初期化パラメータ・ファイル

- 初期化パラメータ・ファイルのサンプル

- グローバル・データベース名の決定

- DB_NAME初期化パラメータ

- DB_DOMAIN初期化パラメータ

- 高速リカバリ領域の指定

- 制御ファイルの指定

- データベース・ブロック・サイズの指定

- DB_BLOCK_SIZE初期化パラメータ

- 非標準ブロック・サイズ

- 最大プロセス数の指定

- DDLロック・タイムアウトの指定

- UNDO領域管理方法の指定

- UNDO_MANAGEMENT初期化パラメータ

- UNDO_TABLESPACE初期化パラメータ

- COMPATIBLE初期化パラメータの概要

- ライセンスに関するパラメータの設定

- サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

- サーバー・パラメータ・ファイルの概要

- サーバー・パラメータ・ファイルへの移行

- サーバー・パラメータ・ファイルの作成

- SPFILE初期化パラメータ

- 初期化パラメータ値の変更

- 初期化パラメータ値の設定または変更

- 初期化パラメータ値のクリア

- サーバー・パラメータ・ファイルのエクスポート

- サーバー・パラメータ・ファイルのバックアップの作成

- 失われたまたは破損したサーバー・パラメータ・ファイルのリカバリ

- パラメータ設定の表示

- データベース・サービスでのアプリケーション・ワークロードの管理

- データベース・サービスの理解

- データベース・サービスの作成

- データベース・サービスのデータ・ディクショナリ・ビュー

- データベースを作成した後の考慮点

- セキュリティに関する考慮点

- 透過的データ暗号化の有効化

- 安全性の高い外部パスワード・ストアの作成

- Oracle Databaseサンプル・スキーマのインストール

- CloneDBを使用したデータベースのクローニング

- CloneDBを使用したデータベースのクローニングの概要

- CloneDBを使用したデータベースのクローニング

- CloneDBを使用したデータベースのクローニング後

- データベースの削除

- データベースのデータ・ディクショナリ・ビュー

3 起動と停止

- データベースの起動

- データベースの起動オプションの概要

- SQL*Plusを使用したデータベースの起動

- Recovery Managerを使用したデータベースの起動

- Oracle Enterprise Managerを使用したデータベースの起動

- SRVCTLを使用したデータベースの起動

- 起動時における初期化パラメータの指定

- 初期化パラメータ・ファイルおよび起動の概要

- デフォルト以外のサーバー・パラメータ・ファイルを使用したSQL*Plusでの起動

- デフォルト以外のサーバー・パラメータ・ファイルを使用したSRVCTLでの起動

- データベース・サービスの自動起動の概要

- インスタンス起動の準備

- インスタンスの起動

- インスタンスを起動し、データベースをマウントしてオープンする方法

- インスタンスを起動するが、データベースをマウントしない方法

- インスタンスを起動し、データベースをマウントする方法

- 起動時にインスタンスへのアクセスを制限する方法

- インスタンスを強制的に起動する方法

- インスタンスを起動し、データベースをマウントして、完全メディア・リカバリを開始する方法

- オペレーティング・システム起動時にデータベースを自動的に起動する方法

- リモート・インスタンスを起動する方法

- データベースの可用性の変更

- インスタンスにデータベースをマウントする方法

- クローズしているデータベースをオープンする方法

- データベースを読取り専用モードでオープンする方法

- オープンしているデータベースへのアクセスを制限する方法

- データベースの停止

- NORMALモードによる停止

- IMMEDIATEモードによる停止

- TRANSACTIONALモードによる停止

- ABORTモードによる停止

- 停止のタイムアウト

- データベースの静止

- データベースの静止状態への変更

- 通常操作へのシステムのリストア

- インスタンスの静止状態の表示

- データベースの一時停止と再開

4 Oracle Databaseの自動再起動の構成

- Oracle Restartの理解

- Oracle Restartの概要

- 起動の依存性の概要

- Oracle Restartを使用した起動と停止の概要

- Oracle Restartの起動と停止の概要

- Oracle Restart構成

- Oracle RestartとOracle Data Guardとの統合

- Oracle Restartとの高速アプリケーション通知

- 高速アプリケーション通知の概要

- サービスとFANにおけるアプリケーションの高可用性

- Oracle Restartの構成

- SRVCTLの実行準備

- SRVCTLのヘルプの表示

- Oracle Restart構成へのコンポーネントの追加

- SRVCTLを使用したコンポーネントの追加

- Oracle Enterprise Manager Database Controlを使用したコンポーネントの追加

- Oracle Restart構成からのコンポーネントの削除

- Oracle Restartでのコンポーネント管理の無効化と有効化

- コンポーネント・ステータスの表示

- コンポーネントのOracle Restart構成の表示

- コンポーネントのOracle Restart構成の変更

- Oracle Restart構成の環境変数の管理

- 環境変数の設定と設定解除

- 環境変数の表示

- SRVCTLを使用したデータベース・サービスの作成と削除

- Oracle Restart環境でのFANイベントの有効化

- プライマリ・データベースとスタンバイ・データベースの接続のフェイルオーバーの自動化

- クライアントでの高速接続フェイルオーバーの有効化

- JDBCクライアントでの高速接続フェイルオーバーの有効化

- Oracle Call Interfaceクライアントでの高速接続フェイルオーバーの有効化

- ODP.NETクライアントでの高速接続フェイルオーバーの有効化

- Oracle Restartで管理されているコンポーネントの起動と停止

- Oracle Restartで管理されているコンポーネントのSRVCTLを使用した起動と停止

- Oracle Restartによって管理されているデータベースのOracle Enterprise Managerを使用した起動

- メンテナンス操作のためのOracle Restartの停止および再起動

- Oracle RestartのSRVCTLコマンド・リファレンス

- add

- srvctl add asm

- srvctl add database

- srvctl add listener

- srvctl add ons

- srvctl add service

- config

- srvctl config asm

- srvctl config database

- srvctl config listener

- srvctl config ons

- srvctl config service

- disable

- srvctl disable asm

- srvctl disable database

- srvctl disable diskgroup

- srvctl disable listener

- srvctl disable ons

- srvctl disable service

- enable

- srvctl enable asm

- srvctl enable database

- srvctl enable diskgroup

- srvctl enable listener

- srvctl enable ons

- srvctl enable service

- getenv

- srvctl getenv asm

- srvctl getenv database

- srvctl getenv listener

- modify

- srvctl modify asm

- srvctl modify database

- srvctl modify listener

- srvctl modify ons

- srvctl modify service

- remove

- srvctl remove asm

- srvctl remove database

- srvctl remove diskgroup

- srvctl remove listener

- srvctl remove ons

- srvctl remove service

- setenv

- srvctl setenv asm

- srvctl setenv database

- srvctl setenv listener

- start

- srvctl start asm

- srvctl start database

- srvctl start diskgroup

- srvctl start home

- srvctl start listener

- srvctl start ons

- srvctl start service

- status

- srvctl status asm

- srvctl status database

- srvctl status diskgroup

- srvctl status home

- srvctl status listener

- srvctl status ons

- srvctl status service

- stop

- srvctl stop asm

- srvctl stop database

- srvctl stop diskgroup

- srvctl stop home

- srvctl stop listener

- srvctl stop ons

- srvctl stop service

- unsetenv

- srvctl unsetenv asm

- srvctl unsetenv database

- srvctl unsetenv listener

- CRSCTLコマンド・リファレンス

- check

- config

- disable

- enable

- start

- stop

5 プロセスの管理

- 専用サーバー・プロセスと共有サーバー・プロセスの概要

- 専用サーバー・プロセス

- 共有サーバー・プロセス

- データベース常駐接続プーリングの理解

- DRCP、専用サーバーおよび共有サーバーの比較

- データベース常駐接続プーリングの使用に関する制限事項

- Oracle Databaseの共有サーバー構成

- 共有サーバー用初期化パラメータ

- 共有サーバーのメモリー管理

- 共有サーバーの使用可能化

- SHARED_SERVERSの値の決定

- 共有サーバー・プロセス数の削減

- 共有サーバー・プロセス数の制限

- 共有サーバー・セッション数の制限

- 共有メモリーの保護

- ディスパッチャの構成

- DISPATCHERS初期化パラメータの属性

- ディスパッチャ数の決定

- 初期ディスパッチャ数の設定

- ディスパッチャ数の変更

- 特定のディスパッチャ・プロセスの停止

- 共有サーバーの使用禁止

- 共有サーバーのデータ・ディクショナリ・ビュー

- データベース常駐接続プーリングの構成

- データベース常駐接続プーリングを使用可能にする方法

- データベース常駐接続プーリングの接続プールの構成

- データベース常駐接続プーリングのデータ・ディクショナリ・ビュー

- Oracle Databaseバックグラウンド・プロセスの概要

- SQLのパラレル実行用プロセスの管理

- パラレル実行サーバーの概要

- セッションのパラレル実行の変更

- SQLのパラレル実行を使用禁止にする方法

- SQLのパラレル実行を使用可能にする方法

- SQLのパラレル実行の強制

- 外部プロシージャのプロセスの管理

- 外部プロシージャの概要

- 外部プロシージャ・コールを有効化するためのDBAのタスク

- セッションの停止

- 停止するセッションの識別

- アクティブ・セッションの停止

- 非アクティブ・セッションの停止

- プロセスおよびセッションのデータ・ディクショナリ・ビュー

6 メモリーの管理

- メモリー管理について

- メモリー・アーキテクチャの概要

- 自動メモリー管理の使用

- 自動メモリー管理の概要

- 自動メモリー管理の有効化

- 自動メモリー管理の監視およびチューニング

- メモリーの手動構成

- 自動共有メモリー管理の使用

- 自動共有メモリー管理の概要

- SGAのコンポーネントおよびグラニュル

- 最大SGAサイズの設定

- SGAターゲット・サイズの設定

- 自動共有メモリー管理を使用可能にする方法

- 自動共有メモリー管理の詳細説明

- 手動共有メモリー管理の使用

- 手動共有メモリー管理を使用可能にする方法

- バッファ・キャッシュ初期化パラメータの設定

- 共有プール・サイズの指定

- ラージ・プール・サイズの指定

- Javaプール・サイズの指定

- Streamsプール・サイズの指定

- 結果キャッシュの最大サイズの指定

- その他のSGA初期化パラメータの指定

- 自動PGAメモリー管理の使用

- 手動PGAメモリー管理の使用

- Database Smart Flash Cacheの構成

- フラッシュ・キャッシュを構成する場合

- フラッシュ・キャッシュのサイズの設定

- フラッシュ・キャッシュのメモリーのチューニング

- フラッシュ・キャッシュの初期化パラメータ

- Oracle Real Application Clusters環境のフラッシュ・キャッシュ

- メモリー管理の参考情報

- 自動メモリー管理をサポートするプラットフォーム

- メモリー管理のデータ・ディクショナリ・ビュー

7 ユーザーの管理とデータベースのセキュリティ保護

- データベースに対するセキュリティ・ポリシー設定の重要性

- ユーザーとリソースの管理

- ユーザー権限とロールの管理

- データベース・アクティビティの監査

- 事前定義のユーザー・アカウント

8 データベースの動作の監視

- エラーおよびアラートの監視

- トレース・ファイルおよびアラート・ログを使用したエラーの監視

- トレース・ファイル・サイズの制御

- Oracle Databaseがトレース・ファイルに書き込む時期の制御

- 共有サーバー・セッション用トレース・ファイルの読込み

- サーバー生成アラートを使用したデータベースの動作の監視

- サーバー生成アラートのしきい値の設定と取得

- サーバー生成アラートの表示

- サーバー生成アラートのデータ・ディクショナリ・ビュー

- パフォーマンスの監視

- ロックの監視

- 待機イベントの監視

- パフォーマンス監視のデータ・ディクショナリ・ビュー

9 診断データの管理

- Oracle Databaseの障害診断インフラストラクチャの概要

- 障害診断インフラストラクチャの概要

- インシデントおよび問題の概要

- インシデントのフラッド制御

- トポロジ全体に関連する問題

- 障害診断インフラストラクチャのコンポーネント

- 自動診断リポジトリ(ADR)

- アラート・ログ

- トレース・ファイル、ダンプおよびコア・ファイル

- ADRのその他の内容

- Enterprise Managerサポート・ワークベンチ

- ADRCIコマンドライン・ユーティリティ

- 自動診断リポジトリの構造、内容および場所

- 問題の調査、レポートおよび解決

- 問題の調査、レポートおよび解決のロードマップ

- タスク1: Enterprise Managerでのクリティカル・エラー・アラートの表示

- タスク2: 問題の詳細の表示

- タスク3: (オプション)追加の診断情報の収集

- タスク4: (オプション)サービス・リクエストの作成

- タスク5: 診断データのパッケージ化とOracleサポート・サービスへのアップロード

- タスク6: サービス・リクエストの追跡および修復の実施

- タスク7: インシデントのクローズ

- Enterprise Managerサポート・ワークベンチを使用した問題の表示

- ユーザー報告の問題の作成

- アラート・ログの表示

- トレース・ファイルの検索

- 状態モニターを使用したヘルス・チェックの実行

- 状態モニターの概要

- 状態モニター・チェックの概要

- ヘルス・チェックのタイプ

- ヘルス・チェックの手動実行

- DBMS_HM PL/SQLパッケージを使用したヘルス・チェックの実行

- Enterprise Managerを使用したヘルス・チェックの実行

- チェッカ・レポートの表示

- Enterprise Managerを使用したレポートの表示

- DBMS_HMを使用したレポートの表示

- ADRCIユーティリティを使用したレポートの表示

- 状態モニターのビュー

- ヘルス・チェック・パラメータの参考情報

- SQL修復アドバイザを使用したSQLエラーの修復

- SQL修復アドバイザの概要

- SQL修復アドバイザの実行

- SQLパッチの表示、無効化または削除

- データ・リカバリ・アドバイザを使用したデータ破損の修復

- カスタム・インシデント・パッケージの作成、編集およびアップロード

- インシデント・パッケージの概要

- インシデント・パッケージ内の関係付けられた診断データの概要

- クイック・パッケージングとカスタム・パッケージングの概要

- 相関パッケージの概要

- カスタム・パッケージングを使用した問題のパッケージ化とアップロード

- インシデント・パッケージの表示と変更

- パッケージの詳細の表示

- 「パッケージのカスタマイズ」ページへのアクセス

- インシデント・パッケージ・ファイルの編集(コピー・アウトとコピー・イン)

- インシデント・パッケージへの外部ファイルの追加

- インシデント・パッケージ・ファイルの削除

- インシデント・パッケージのアクティビティ・ログの表示と更新

- 相関パッケージの作成、編集およびアップロード

- 相関パッケージの削除

- インシデント・パッケージのプリファレンスの設定

10 Oracle Enterprise Manager Database Controlの管理

- Database Controlの概要

- Enterprise Managerのディレクトリについて

- インストール中およびインストール後のDatabase Controlの構成

- 構成オプションの概要

- インストール時のDatabase Controlの構成

- DBCAを使用したDatabase Controlの構成

- EMCAを使用したDatabase Controlの構成

- EMCAパラメータの入力ファイルの使用方法

- Database Controlで使用されるポートの指定

- Oracle RACでのEMCAの使用方法

- Database Controlの管理

- Database Controlプロセスの起動と停止

- データベース・ホームページへのアクセス

- Database Control管理ユーザーの作成

- Database Controlに対するアクセス権限の管理ユーザー以外のユーザーへの付与

- Database Controlのプリファレンスの設定

- Database Controlのプリファレンスについて

- ブラックアウト期間の定義

- 優先資格証明の設定

- Oracle RAC環境でのDatabase Controlの管理

- Oracle RAC環境でDatabase Controlが実行されていることの検証

- emkey.oraファイルのバックアップ

- Database Controlオブジェクトの削除と作成

- Database Controlオブジェクトの削除

- オプション1: EMCAスクリプトを使用したDatabase Control構成ファイルの削除

- オプション2: EMCAスクリプトを使用したDatabase Control構成ファイルおよびリポジトリ・オブジェクトの削除

- オプション3: EMCAスクリプトを使用したDatabase Controlリポジトリの削除

- オプション4: 手動によるDatabase Control構成ファイルの削除

- オプション5: RepManagerを使用したDatabase Controlリポジトリの削除

- Database Controlオブジェクトの作成

- オプション1: DB Control構成ファイルの作成

- オプション2: Database Controlリポジトリ・オブジェクトおよび構成ファイルの作成

- オプション3: クローニングしたデータベース・ホーム用のDatabase Controlリポジトリ・オブジェクトおよび構成ファイルの作成

- Database Controlの再作成または再構成

- オプション1: Database Control構成ファイルのみの再作成(リポジトリはそのまま)

- オプション2: Database Control構成ファイルおよびリポジトリの再作成

- EMCAトラブルシューティングのヒント

- データベースのリスナー・ポート変更後のEMCAの使用方法

- 11g リリース2 Grid Control Agentへのアップグレード

- データベース・ホスト名またはIPアドレス変更時のEMCAの使用方法

- TNS構成が変更された場合のEMCAの使用方法

- デスクトップ・クラス・インストールでのEMCAの使用方法

- EMCAエラー・メッセージの処理

- 指定した範囲のポートの割当てに失敗しました

- リスナーが起動していないか、データベース・サービスがリスナーに登録されていません。

第II部 Oracle Databaseの構造と記憶域

11 制御ファイルの管理

- 制御ファイルの概要

- 制御ファイルのガイドライン

- 制御ファイルのファイル名の指定

- 異なるディスク上での制御ファイルの多重化

- 制御ファイルのバックアップ

- 制御ファイルのサイズ管理

- 制御ファイルの作成

- 初期制御ファイルの作成

- 制御ファイルの追加コピーの作成、名前変更および再配置

- 新しい制御ファイルの作成

- 新しい制御ファイルを作成する場合

- CREATE CONTROLFILE文

- 新しい制御ファイルの作成手順

- 制御ファイル作成後のトラブルシューティング

- 欠落したファイルや余分なファイルのチェック

- CREATE CONTROLFILEでのエラー処理

- 制御ファイルのバックアップ

- 現行のコピーを使用した制御ファイルのリカバリ

- 制御ファイルのコピーを使用した制御ファイル破損からのリカバリ

- 制御ファイルのコピーを使用した永続的なメディア障害からのリカバリ

- 制御ファイルの削除

- 制御ファイルのデータ・ディクショナリ・ビュー

12 REDOログの管理

- REDOログの概要

- REDOスレッド

- REDOログの内容

- Oracle DatabaseによるREDOログへの書込み

- アクティブ(カレント)および非アクティブなREDOログ・ファイル

- ログ・スイッチとログ順序番号

- REDOログの計画

- REDOログ・ファイルの多重化

- REDOログの障害への対処

- 有効な構成と無効な構成

- 異なるディスクへのREDOログ・メンバーの配置

- REDOログ・ファイルのサイズの計画

- REDOログ・ファイルのブロック・サイズの計画

- 適切なREDOログ・ファイル数の選択

- アーカイブ・タイムラグの制御

- ARCHIVE_LAG_TARGET初期化パラメータの設定

- ARCHIVE_LAG_TARGETの設定に影響する要因

- REDOログ・グループおよびメンバーの作成

- REDOログ・グループの作成

- REDOログ・メンバーの作成

- REDOログ・メンバーの再配置および名前変更

- REDOログ・グループおよびメンバーの削除

- ログ・グループの削除

- REDOログ・メンバーの削除

- ログ・スイッチの強制

- REDOログ・ファイル内のブロックの検証

- REDOログ・ファイルの初期化

- REDOログのデータ・ディクショナリ・ビュー

13 アーカイブREDOログの管理

- アーカイブREDOログの概要

- NOARCHIVELOGモードとARCHIVELOGモードの選択

- NOARCHIVELOGモードによるデータベースの実行

- ARCHIVELOGモードによるデータベースの実行

- アーカイブの制御

- 初期データベース・アーカイブ・モードの設定

- データベース・アーカイブ・モードの変更

- 手動アーカイブの実行

- アーカイバ・プロセス数の調整

- アーカイブ先の指定

- アーカイブ先の初期化パラメータの設定

- 方法1: LOG_ARCHIVE_DEST_nパラメータの使用

- 方法2: LOG_ARCHIVE_DESTおよびLOG_ARCHIVE_DUPLEX_DESTの使用

- アーカイブ先の状態の理解

- 代替アーカイブ先の指定

- ログ転送モードの概要

- 通常転送モード

- スタンバイ転送モード

- アーカイブ先の障害管理

- 正常なアーカイブ先の最小数の指定

- 必須およびオプションのアーカイブ先の指定

- 正常なアーカイブ先の数の指定: 使用例

- 障害アーカイブ先への再アーカイブ

- ARCHIVELOGプロセスによって生成されるトレース出力の制御

- アーカイブREDOログに関する情報の表示

- アーカイブREDOログ・ビュー

- ARCHIVE LOG LISTコマンド

14 表領域の管理

- 表領域を管理するためのガイドライン

- 複数の表領域の使用

- ユーザーに対する表領域割当て制限の割当て

- 表領域の作成

- ローカル管理表領域

- ローカル管理表領域の作成

- ローカル管理表領域のセグメント領域管理の指定

- bigfile表領域

- bigfile表領域の作成

- bigfile表領域の識別

- 圧縮された表領域

- 暗号化された表領域

- 一時表領域

- ローカル管理の一時表領域の作成

- bigfile一時表領域の作成

- 一時表領域の領域使用情報の表示

- 複数の一時表領域: 表領域グループの使用

- 表領域グループの作成

- 表領域グループのメンバーの変更

- デフォルト一時表領域としての表領域グループの割当て

- 表領域の非標準のブロック・サイズの指定

- REDOレコードの書込みの制御

- 表領域の可用性の変更

- 表領域のオフライン化

- 表領域のオンライン化

- 読取り専用表領域の使用

- 表領域を読取り専用にする方法

- 読取り専用表領域を書込み可能にする方法

- WORMデバイスでの読取り専用表領域の作成

- 読取り専用表領域内にあるデータファイルのオープンの遅延

- 表領域の変更とメンテナンス

- 表領域のサイズの拡大

- ローカル管理表領域の変更

- bigfile表領域の変更

- ローカル管理の一時表領域の変更

- ローカル管理の一時表領域の縮小

- 表領域の名前変更

- 表領域の削除

- SYSAUX表領域の管理

- SYSAUX表領域に含まれる占有データの監視

- SYSAUX表領域内外への占有データの移動

- SYSAUX表領域のサイズの制御

- ローカル管理表領域の問題の診断と修復

- 使用例1: 割当て済ブロックが空き(オーバーラップなし)とマークされているときのビットマップの修復

- 使用例2: 破損したセグメントの削除

- 使用例3: オーバーラップがレポートされたビットマップの修復

- 使用例4: ビットマップ・ブロックのメディア破損の訂正

- 使用例5: ディクショナリ管理表領域からローカル管理表領域への移行

- ローカル管理表領域へのSYSTEM表領域の移行

- データベース間での表領域のトランスポート

- トランスポータブル表領域の概要

- プラットフォーム間での表領域のトランスポート

- トランスポータブル表領域の使用に関する制限事項

- トランスポータブル表領域の互換性に関する注意事項

- データベース間で表領域をトランスポートする手順および例

- タスク1: プラットフォームがサポートされているかどうかの確認とendiannessの判別

- タスク2: 自己完結型の表領域セットの選択

- タスク3: トランスポータブル表領域セットの生成

- タスク4: 表領域セットのトランスポート

- タスク5: (オプション)表領域を読取り/書込みモードに戻す

- タスク6: 表領域セットのインポート

- トランスポータブル表領域の使用: 使用例

- データ・ウェアハウスのためのパーティションのトランスポートと連結

- 構造化データのCDでの公開

- 複数データベースで同じ表領域を読取り専用でマウントする方法

- トランスポータブル表領域を使用した履歴データのアーカイブ

- トランスポータブル表領域を使用したTSPITRの実行

- データベースのトランスポータブル表領域を使用したプラットフォーム間の移動

- 表領域のデータ・ディクショナリ・ビュー

- 例1: 表領域とデフォルト記憶域パラメータの表示

- 例2: データファイルとデータベースの対応する表領域の表示

- 例3: 各表領域の空き領域(エクステント)の統計の表示

15 データファイルおよび一時ファイルの管理

- データファイルを管理するためのガイドライン

- データファイル数の決定

- DB_FILES初期化パラメータの値の決定

- データファイルを表領域に追加するときの制限事項の考慮

- パフォーマンスへの影響の考慮

- データファイルのサイズ設定

- 適切なデータファイルの配置

- REDOログ・ファイルから分離したデータファイルの格納

- データファイルの作成および表領域への追加

- データファイルのサイズ変更

- データファイルの自動拡張機能の使用可能および使用禁止

- 手動によるデータファイルのサイズ変更

- データファイルの可用性の変更

- ARCHIVELOGモードでデータファイルをオンライン化またはオフライン化する方法

- NOARCHIVELOGモードでデータファイルをオフライン化する方法

- 表領域内のすべてのデータファイルおよび一時ファイルの可用性の変更

- データファイルの名前変更と再配置

- 単一の表領域のデータファイルを名前変更および再配置する手順

- 単一の表領域のデータファイルを名前変更する手順

- 単一の表領域のデータファイルを再配置する手順

- 複数の表領域のデータファイルを名前変更および再配置する手順

- データファイルの削除

- データファイル内のデータ・ブロックの検証

- データベース・サーバーを使用したファイルのコピー

- ファイルのローカル・ファイル・システムへのコピー

- サード・パーティ・ファイル転送

- ファイル転送とDBMS_SCHEDULERパッケージ

- 拡張ファイル転送メカニズム

- ファイルと物理デバイスのマッピング

- Oracle Databaseのファイル・マッピング・インタフェースの概要

- Oracle Databaseのファイル・マッピング・インタフェースの動作

- ファイル・マッピングの構成要素

- マッピング構造

- マッピング構造の例

- 構成ID

- Oracle Databaseのファイル・マッピング・インタフェースの使用方法

- ファイル・マッピングの有効化

- DBMS_STORAGE_MAPパッケージの使用

- ファイル・マッピング・ビューからの情報の取得

- ファイル・マッピングの例

- 例1: 1つのデバイスにまたがるすべてのデータベース・ファイルのマッピング

- 例2: ファイルから対応するデバイスへのマッピング

- 例3: データベース・オブジェクトのマッピング

- データファイルのデータ・ディクショナリ・ビュー

16 UNDOの管理

- UNDOの概要

- 自動UNDO管理の概念

- 自動UNDO管理の概要

- UNDOの保存期間

- UNDOの保存期間の自動チューニング

- 保存期間の保証

- UNDOの保存期間のチューニングとアラートしきい値

- チューニング済UNDO保存期間の追跡

- 最小UNDO保存期間の設定

- 固定サイズのUNDO表領域のサイズ変更

- UNDOアドバイザのPL/SQLインタフェース

- UNDO表領域の管理

- UNDO表領域の作成

- CREATE DATABASEを使用したUNDO表領域の作成

- CREATE UNDO TABLESPACE文の使用

- UNDO表領域の変更

- UNDO表領域の削除

- UNDO表領域の切替え

- UNDO領域に対するユーザー割当ての確立

- UNDO表領域に対する領域のアラートしきい値の管理

- 自動UNDO管理への移行

- UNDO領域のデータ・ディクショナリ・ビュー

17 Oracle Managed Filesの使用

- Oracle Managed Filesの概要

- Oracle Managed Filesの使用対象

- 論理ボリューム・マネージャの概要

- ファイル・システムの概要

- Oracle Managed Filesの使用上の利点

- Oracle Managed Filesと既存の機能

- Oracle Managed Filesの作成および使用の有効化

- DB_CREATE_FILE_DEST初期化パラメータの設定

- DB_RECOVERY_FILE_DESTパラメータの設定

- DB_CREATE_ONLINE_LOG_DEST_n初期化パラメータの設定

- Oracle Managed Filesの作成

- Oracle Managed Filesの命名方法

- データベース作成時のOracle Managed Filesの作成

- データベース作成時の制御ファイルの指定

- データベース作成時のREDOログ・ファイルの指定

- データベース作成時のSYSTEM表領域およびSYSAUX表領域用データファイルの指定

- データベース作成時のUNDO表領域データファイルの指定

- データベース作成時のデフォルト一時表領域用一時ファイルの指定

- Oracle Managed Filesを使用したCREATE DATABASE文の例

- Oracle Managed Filesを使用した表領域用データファイルの作成

- CREATE TABLESPACE: 例

- CREATE UNDO TABLESPACE: 例

- ALTER TABLESPACE: 例

- Oracle Managed Filesを使用した一時表領域用一時ファイルの作成

- CREATE TEMPORARY TABLESPACE: 例

- ALTER TABLESPACE... ADD TEMPFILE: 例

- Oracle Managed Filesを使用した制御ファイルの作成

- NORESETLOGSキーワードを使用したCREATE CONTROLFILE: 例

- RESETLOGSキーワードを使用したCREATE CONTROLFILE: 例

- Oracle Managed Filesを使用したREDOログ・ファイルの作成

- ALTER DATABASE ADD LOGFILE文の使用

- ALTER DATABASE OPEN RESETLOGS文の使用

- Oracle Managed Filesを使用したアーカイブ・ログの作成

- Oracle Managed Filesの操作

- データファイルおよび一時ファイルの削除

- REDOログ・ファイルの削除

- ファイルの名前変更

- スタンバイ・データベースの管理

- Oracle Managed Filesの使用例

- 使用例1: 多重REDOログを含むデータベースの作成および管理

- 使用例2: データベース領域と高速リカバリ領域を含むデータベースの作成と管理

- 使用例3: 既存のデータベースへのOracle Managed Filesの追加

第III部 スキーマ・オブジェクト

18 スキーマ・オブジェクトの管理

- 一度の操作で複数の表やビューを作成する方法

- 表、索引およびクラスタの分析

- DBMS_STATSを使用した表および索引統計の収集

- 表、索引、クラスタおよびマテリアライズド・ビューの妥当性チェック

- 表とクラスタの連鎖行のリスト

- CHAINED_ROWS表の作成

- 表内の移行行または連鎖行の解消

- 表とクラスタの切捨て

- DELETEの使用

- DROPとCREATEの使用

- TRUNCATEの使用

- トリガーの使用可能および使用禁止

- トリガーを使用可能にする方法

- トリガーを使用禁止にする方法

- 整合性制約の管理

- 整合性制約の状態

- 制約を使用禁止にする方法

- 制約を使用可能にする方法

- 妥当性チェックなしで使用可能な制約の状態

- 整合性制約の効率的な使用: 手順

- 定義時の整合性制約の設定

- 定義時に制約を使用禁止にする方法

- 定義時に制約を使用可能にする方法

- 既存の整合性制約の変更、名前変更または削除

- 使用可能状態の制約を使用禁止にする方法

- 制約名の変更

- 制約の削除

- 制約チェックの遅延

- すべての制約を遅延に設定する方法

- コミットのチェック(オプション)

- 制約例外のレポート

- 制約情報の表示

- スキーマ・オブジェクトの名前変更

- オブジェクト依存性の管理

- オブジェクト依存性とオブジェクトの無効化の概要

- DDLを使用した手動による無効なオブジェクトの再コンパイル

- PL/SQLパッケージのプロシージャを使用した手動による無効なオブジェクトの再コンパイル

- オブジェクトの名前解決の管理

- 異なるスキーマへの切替え

- エディションの管理

- エディションおよびエディションに基づく再定義の概要

- エディションに基づく再定義のためのDBAのタスク

- データベースのデフォルトのエディションの設定

- データベースのデフォルト・エディションの問合せ

- データベース・サービスのエディション属性の設定

- データベース・サービス作成時のエディション属性の設定

- 既存のデータベース・サービスのエディション属性の設定

- エディションの使用

- エディションのデータ・ディクショナリ・ビュー

- スキーマ・オブジェクト情報の表示

- PL/SQLパッケージを使用したスキーマ・オブジェクト情報の表示

- スキーマ・オブジェクトのデータ・ディクショナリ・ビュー

- 例1: スキーマ・オブジェクトのタイプ別表示

- 例2: ビューとシノニムの依存性の表示

19 スキーマ・オブジェクトの領域の管理

- 表領域のアラートの管理

- アラートしきい値の設定

- アラートの表示

- 制限事項

- 再開可能領域割当ての管理

- 再開可能領域割当ての概要

- 再開可能領域割当ての動作

- 再開可能な操作

- 訂正可能なエラー

- 再開可能領域割当てと分散処理

- パラレル実行と再開可能領域割当て

- 再開可能領域割当ての有効化および無効化

- RESUMABLE_TIMEOUT初期化パラメータの設定

- ALTER SESSIONを使用した再開可能領域割当ての有効化と無効化

- LOGONトリガーを使用したデフォルト再開可能モードの設定

- 一時停止文の検出

- ユーザーへの通知: AFTER SUSPENDシステム・イベントおよびトリガー

- ビューを使用した一時停止文情報の取得

- DBMS_RESUMABLEパッケージの使用方法

- 操作一時停止アラート

- 再開可能領域割当ての例: AFTER SUSPENDトリガーの登録

- 使用できない領域の再生

- 再生可能な未使用領域の理解

- セグメント・アドバイザの使用

- 自動セグメント・アドバイザ

- 手動によるセグメント・アドバイザの実行

- セグメント・アドバイザの結果の表示

- 自動セグメント・アドバイザの構成

- 自動セグメント・アドバイザ情報の表示

- オンラインによるデータベース・セグメントの縮小

- 未使用領域の割当て解除

- 未使用オブジェクト記憶域の削除

- データ型の領域使用の理解

- スキーマ・オブジェクトの領域使用情報の表示

- PL/SQLパッケージを使用したスキーマ・オブジェクトの領域使用情報の表示

- スキーマ・オブジェクトの領域使用のデータ・ディクショナリ・ビュー

- 例1: セグメント情報の表示

- 例2: エクステント情報の表示

- 例3: 表領域内の空き領域(エクステント)の表示

- データベース・オブジェクトの容量計画

- 表の領域使用の見積り

- 索引の領域使用の見積り

- オブジェクト増加傾向の取得

20 表の管理

- 表について

- 表を管理するためのガイドライン

- 作成前の表の設計

- 作成する表のタイプの指定

- 各表の位置の指定

- 表作成のパラレル化

- 表作成時のNOLOGGINGの使用

- 表圧縮の使用

- 表圧縮に関連のある例

- 圧縮とパーティション表

- 表が圧縮されているかどうかの確認

- 圧縮されている行の確認

- 圧縮レベルの変更

- 圧縮表の列の追加と削除

- ハイブリッド列圧縮表のエクスポートおよびインポート

- ハイブリッド列圧縮表のリストア

- 圧縮表に関する注意およびその他の制限事項

- 圧縮表のパック

- 機密データを格納する列の暗号化

- セグメント作成の遅延の理解

- セグメントのマテリアライズ

- 表サイズの見積りと見積りに応じた計画

- 表作成時の制限事項

- 表の作成

- 例: 表の作成

- 一時表の作成

- 表作成のパラレル化

- 表のロード

- 表のロード方法

- ダイレクト・パスINSERTを使用したINSERTパフォーマンスの向上

- ダイレクト・パスINSERTの概要

- ダイレクト・パスINSERTの動作

- ダイレクト・パスINSERTを使用したデータのロード

- ダイレクト・パスINSERTのロギング・モードの指定

- ダイレクト・パスINSERTのその他の考慮事項

- 従来型のインサートを使用した表のロード

- DMLエラー・ロギングを使用したバルクINSERT失敗の回避

- エラー・ロギング表の書式

- エラー・ロギング表の作成

- エラー・ロギングの制限事項と注意

- 表に関する統計の自動収集

- 表の変更

- ALTER TABLE文を使用する理由

- 表の物理属性の変更

- 新規セグメントまたは表領域への表の移動

- 表の記憶域の手動割当て

- 既存の列定義の変更

- 表の列の追加

- 圧縮表への列の追加

- 仮想列の追加

- 表の列名の変更

- 表の列の削除

- 表から列を削除する方法

- 列に未使用マークを付ける方法

- 未使用列の削除

- 圧縮表の列の削除

- 表を読取り専用モードにする方法

- 表のオンライン再定義

- 表のオンライン再定義の機能

- DBMS_REDEFINITIONを使用したオンライン再定義の実行

- 列マッピング文字列の作成

- 依存オブジェクトの自動作成

- 依存オブジェクトの手動による作成

- 再定義プロセスの結果

- 中間での同期化の実行

- エラー後の表のオンライン再定義の強制終了およびクリーン・アップ

- 表のオンライン再定義に関する制限事項

- 単一パーティションのオンライン再定義

- 単一パーティションのオンライン再定義のルール

- 表のオンライン再定義の例

- DBMS_REDEFINITIONパッケージに必要な権限

- エラーが発生した表の変更の調査と取消し

- Oracle Flashback Tableを使用した表のリカバリ

- 表の削除

- フラッシュバック・ドロップの使用とリサイクル・ビンの管理

- リサイクル・ビンの概要

- リサイクル・ビンの有効化と無効化

- リサイクル・ビン内のオブジェクトの表示と問合せ

- リサイクル・ビン内のオブジェクトのパージ

- リサイクル・ビンからの表のリストア

- 索引構成表の管理

- 索引構成表の概要

- 索引構成表の作成

- 例: 索引構成表の作成

- 索引構成表に対する制限

- オブジェクト型を含む索引構成表の作成

- しきい値の選択と監視

- INCLUDING句の使用

- 索引構成表作成のパラレル化

- キー圧縮の使用

- 索引構成表のメンテナンス

- 索引構成表の変更

- 索引構成表の移動(再作成)

- 索引構成表に対する2次索引の作成

- 2次索引作成の構文

- 論理ROWIDの物理的不確定要素のメンテナンス

- ビットマップ索引

- 索引構成表の分析

- 索引構成表のオプティマイザ統計の収集

- 索引構成表の構造の検証

- 索引構成表でのORDER BY句の使用

- 索引構成表の標準的な表への変換

- 外部表の管理

- 外部表の概要

- 外部表の作成

- 外部表の変更

- 外部表の前処理

- 外部表の削除

- 外部表のシステム権限およびオブジェクト権限

- 表のデータ・ディクショナリ・ビュー

21 索引の管理

- 索引について

- 索引を管理するためのガイドライン

- 表データ挿入後の索引の作成

- 正しい表および列への索引付け

- パフォーマンスのための索引列の順序付け

- 表当たりの索引数の制限

- 不必要な索引の削除

- 索引およびセグメント作成の遅延

- 索引サイズの見積りと記憶域パラメータの設定

- 各索引の表領域の指定

- 索引作成のパラレル化

- 索引作成時のNOLOGGINGの使用

- 使用禁止または不可視索引の使用について

- 索引の結合と再作成に関するコストと利点の検討

- 制約を使用禁止または削除する前のコストの検討

- 索引の作成

- 索引の明示的な作成

- 一意索引の明示的な作成

- 制約に対応付けられた索引の作成

- 制約に対応付けられた索引に対する記憶域オプションの指定

- 制約に対応付けられた索引の指定

- 大きな索引の作成

- オンラインでの索引の作成

- ファンクション索引の作成

- キー圧縮型索引の作成

- 使用禁止索引の作成

- 不可視索引の作成

- 索引の変更

- 索引の記憶域特性の変更

- 既存の索引の再作成

- 索引の使用禁止化

- 索引の不可視化

- 索引の名前変更

- 索引の使用状況の監視

- 索引の領域使用の監視

- 索引の削除

- 索引のデータ・ディクショナリ・ビュー

22 クラスタの管理

- クラスタの概要

- クラスタを管理するためのガイドライン

- クラスタに適した表の選択

- クラスタ・キーに適した列の選択

- 平均クラスタ・キーとその対応行が必要とする領域の指定

- 各クラスタとクラスタ索引の行の位置の指定

- クラスタ・サイズの見積りと記憶域パラメータの設定

- クラスタの作成

- クラスタ化表の作成

- クラスタ索引の作成

- クラスタの変更

- クラスタ化表の変更

- クラスタ索引の変更

- クラスタの削除

- クラスタ化表の削除

- クラスタ索引の削除

- クラスタのデータ・ディクショナリ・ビュー

23 ハッシュ・クラスタの管理

- ハッシュ・クラスタの概要

- ハッシュ・クラスタを使用する場合

- ハッシングが有効な状況

- ハッシングが不利な状況

- ハッシュ・クラスタの作成

- ソートされたハッシュ・クラスタの作成

- 単一表ハッシュ・クラスタの作成

- ハッシュ・クラスタ内の領域使用の制御

- キーの選択

- HASH ISパラメータの設定

- SIZEパラメータの設定

- HASHKEYSパラメータの設定

- ハッシュ・クラスタ内の使用領域の制御

- ハッシュ・クラスタに必要なサイズの見積り

- ハッシュ・クラスタの変更

- ハッシュ・クラスタの削除

- ハッシュ・クラスタのデータ・ディクショナリ・ビュー

24 ビュー、順序およびシノニムの管理

- ビューの管理

- ビューについて

- ビューの作成

- 結合ビュー

- ビュー作成時の問合せ定義の展開

- エラー付きビューの作成

- ビューの置換

- 問合せでのビューの使用

- 結合ビューの更新

- キー保存表

- DML文と結合ビュー

- 外部結合が含まれるビューの更新

- UPDATABLE_COLUMNSビューの使用

- ビューの変更

- ビューの削除

- 順序の管理

- 順序の概要

- 順序の作成

- 順序の変更

- 順序の使用

- 順序の参照

- 順序番号のキャッシュ

- 順序の削除

- シノニムの管理

- シノニムの概要

- シノニムの作成

- DML文でのシノニムの使用

- シノニムの削除

- ビュー、順序およびシノニムのデータ・ディクショナリ・ビュー

25 破損データの修復

- データ・ブロック破損を修復するオプション

- DBMS_REPAIRパッケージの内容

- DBMS_REPAIRプロシージャ

- 制約と制限事項

- DBMS_REPAIRパッケージの使用方法

- タスク1: 破損の検出とレポート

- DBMS_REPAIR: CHECK_OBJECTおよびADMIN_TABLESプロシージャの使用

- DB_VERIFY: オフライン・データベース・チェックの実行

- ANALYZE: 破損のレポート

- DB_BLOCK_CHECKING初期化パラメータ

- タスク2: DBMS_REPAIRの使用に伴うコストと利点の評価

- タスク3: オブジェクトの使用可能化

- 破損の修復: FIX_CORRUPT_BLOCKSおよびSKIP_CORRUPT_BLOCKSプロシージャの使用

- 破損ブロックをスキップする操作の意味

- タスク4: 破損の修復および失われたデータの再作成

- DUMP_ORPHAN_KEYSプロシージャを使用したデータのリカバリ

- SEGMENT_FIX_STATUSプロシージャを使用したセグメント・ビットマップの修正

- DBMS_REPAIRの例

- 例: 修復表または孤立キー表の作成

- 例: 修復表の作成

- 例: 孤立キー表の作成

- 例: 破損の検出

- 例: 破損ブロックの修正

- 例: 破損データ・ブロックを指す索引エントリの検索

- 例: 破損ブロックのスキップ

第IV部 データベース・リソースの管理とタスクのスケジューリング

26 自動データベース・メンテナンス・タスクの管理

- 自動化メンテナンス・タスクの概要

- メンテナンス・ウィンドウの概要

- 自動化メンテナンス・タスクの構成

- すべてのメンテナンス・ウィンドウに対するメンテナンス・タスクの有効化と無効化

- 特定のメンテナンス・ウィンドウに対するメンテナンス・タスクの有効化と無効化

- メンテナンス・ウィンドウの構成

- メンテナンス・ウィンドウの変更

- 新規メンテナンス・ウィンドウの作成

- メンテナンス・ウィンドウの削除

- 自動化メンテナンス・タスクに対するリソース割当ての構成

- 自動化メンテナンス・タスクに対するリソース割当ての概要

- 自動化メンテナンス・タスクに対するリソース割当ての変更

- 自動化メンテナンス・タスクの参照情報

- 事前定義のメンテナンス・ウィンドウ

- 自動化メンテナンス・タスクのデータベース・ディクショナリ・ビュー

27 Oracle Database Resource Managerを使用したリソースの管理

- Oracle Database Resource Managerの概要

- リソース・マネージャが提供するワークロード管理のソリューション

- リソース・マネージャの要素

- リソース・コンシューマ・グループの概要

- リソース・プラン・ディレクティブの概要

- リソース・プランの概要

- 例: 単純なリソース・プラン

- サブプランの概要

- 例: サブプランを含むリソース・プラン

- リソース・マネージャの管理権限の概要

- リソース・コンシューマ・グループへのセッションの割当て

- リソース・コンシューマ・グループへのセッション割当ての概要

- 初期リソース・コンシューマ・グループの割当て

- コンシューマ・グループへのセッションのマッピング・ルールの指定

- コンシューマ・グループへのセッションのマッピング・ルールの概要

- コンシューマ・グループのマッピング・ルールの作成

- コンシューマ・グループのマッピング・ルールの変更と削除

- マッピング・ルールの優先度の作成

- リソース・コンシューマ・グループの切替え

- 手動によるリソース・コンシューマ・グループの切替え

- ユーザーまたはアプリケーションに対する手動によるコンシューマ・グループの切替えの有効化

- リソース・コンシューマ・グループの自動切替えの指定

- マッピング・ルールを使用した自動切替えの指定

- リソース制限の設定による自動切替えの指定

- スイッチ特権の付与と取消し

- スイッチ特権の付与

- スイッチ特権の取消し

- リソース・マネージャによって管理されるリソースのタイプ

- CPU

- 並列度制限

- パラレル・ターゲット率

- パラレル・ターゲット率を使用したパラレル・ステートメント・キューイングの管理

- パラレル・キューのタイムアウト

- キューイングを備えたアクティブ・セッション・プール

- コンシューマ・グループの自動切替え

- SQLの取消しとセッションの終了

- 実行時間制限

- UNDOプール

- アイドル時間制限

- 単純なリソース・プランの作成

- 複雑なリソース・プランの作成

- ペンディング・エリアの概要

- ペンディング・エリアの作成

- リソース・コンシューマ・グループの作成

- リソース・プランの作成

- RATIO CPU割当て方法の概要

- リソース・プラン・ディレクティブの作成

- リソース・プラン・ディレクティブの相互作用

- ペンディング・エリアの妥当性チェック

- ペンディング・エリアの発行

- ペンディング・エリアのクリア

- Oracle Database Resource Managerの有効化とプランの切替え

- 各種の方法を組み合せたOracle Database Resource Managerの例

- 複数レベルのプランの例

- 最大使用率の制限属性を使用した例

- 各種のリソース割当て方法を使用した例

- ディレクティブ属性を使用したパラレル・ステートメントの管理の例

- オラクル社が提供する複合ワークロード・プラン

- 単一サーバーにおける複数のデータベース・インスタンスの管理

- インスタンス・ケージングの概要

- インスタンス・ケージングの有効化

- コンシューマ・グループ、プランおよびディレクティブのメンテナンス

- コンシューマ・グループの更新

- コンシューマ・グループの削除

- プランの更新

- プランの削除

- リソース・プラン・ディレクティブの更新

- リソース・プラン・ディレクティブの削除

- データベース・リソース・マネージャの構成とステータスの表示

- ユーザーまたはロールに権限付与されたコンシューマ・グループの表示

- プラン情報の表示

- セッションの現行コンシューマ・グループの表示

- 現在アクティブなプランの表示

- Oracle Database Resource Managerの監視

- オペレーティング・システムのリソース制御との相互作用

- オペレーティング・システムのリソース制御を使用するためのガイドライン

- Oracle Database Resource Managerの参照情報

- 事前定義のリソース・プランおよびコンシューマ・グループ

- 事前定義のコンシューマ・グループ・マッピング・ルール

- リソース・マネージャのデータ・ディクショナリ・ビュー

28 Oracle Schedulerの概要

- Oracle Schedulerの概要

- ジョブおよびスケジューラ・オブジェクトのサポートの概要

- プログラム

- スケジュール

- ジョブ

- 宛先

- 宛先およびスケジューラ・エージェントの概要

- File Watcher

- 資格証明

- チェーン

- ジョブ・クラス

- ウィンドウ

- ウィンドウの重複

- グループ

- 宛先グループ

- ウィンドウ・グループ

- ジョブに関する追加説明

- ジョブ・カテゴリ

- データベース・ジョブ

- 外部ジョブ

- 複数の宛先のジョブ

- チェーン・ジョブ

- デタッチ済ジョブ

- 軽量ジョブ

- ジョブ・インスタンス

- ジョブ引数

- プログラム、ジョブおよびスケジュールの関連

- スケジューラのアーキテクチャ

- ジョブ表

- ジョブ・コーディネータ

- ジョブ・コーディネータの処理

- スケジューラ・ジョブ・プロセスの最大数

- ジョブの実行方法

- ジョブの完了後

- Real Application Clusters環境におけるスケジューラの使用

- スケジューラ使用時のサービス・アフィニティ

- スケジューラによるOracle Data Guardのサポート

- Oracle Schedulerとエディション

29 Oracle Schedulerを使用したジョブのスケジューリング

- スケジューラ・オブジェクトとそのネーミングの概要

- ジョブの作成、実行および管理

- ジョブのタスクとそのプロシージャ

- ジョブの作成

- ジョブ作成の概要

- ジョブの処理とジョブ・スケジュールの指定

- ジョブの資格情報とジョブの宛先の指定

- 複数の宛先のジョブの作成

- ジョブ引数の設定

- ジョブ属性の追加設定

- デタッチ済ジョブの作成

- 単一トランザクションでの複数ジョブの作成

- 外部ジョブの手法

- ジョブの変更

- ジョブの実行

- ジョブの停止

- 外部ジョブの停止

- チェーン・ジョブの停止

- ジョブの削除

- ジョブの無効化

- ジョブの有効化

- ジョブのコピー

- 外部ジョブのstdoutとstderrの表示

- ジョブを定義するためのプログラムの作成および管理

- プログラムのタスクとそのプロシージャ

- プログラムの作成

- プログラム引数の定義

- プログラムの変更

- プログラムの削除

- プログラムの無効化

- プログラムの有効化

- ジョブを定義するためのスケジュールの作成および管理

- スケジュールのタスクとそのプロシージャ

- スケジュールの作成

- スケジュールの変更

- スケジュールの削除

- 繰返し間隔の設定

- スケジューラのカレンダ指定構文の使用方法

- PL/SQL式の使用方法

- PL/SQL式とカレンダ指定構文の動作の相違点

- 繰返し間隔と夏時間

- イベントを使用したジョブの開始

- イベントの概要

- アプリケーションによって呼び出されたイベントによるジョブの開始

- イベントベースのジョブの作成

- イベントベースのジョブの変更

- イベント・スケジュールの作成

- イベント・スケジュールの変更

- イベントベースのジョブにイベント・メッセージを渡す方法

- ファイルがシステムに到着したことによるジョブの開始

- File Watcherの概要

- リモート・システムからのファイルの到着イベントの有効化

- File WatcherおよびFile Watcherジョブの作成

- ファイルの到着の例

- File Watcherの管理

- File Watcherの情報の表示

- ジョブ・チェーンの作成と管理

- チェーンのタスクとそのプロシージャ

- チェーンの作成

- チェーン・ステップの定義

- チェーンへのルールの追加

- チェーン・ルールの評価間隔の設定

- チェーンの有効化

- チェーン用のジョブの作成

- チェーンの削除

- チェーンの実行

- チェーン・ルールの削除

- チェーンの無効化

- チェーン・ステップの削除

- チェーンの停止

- 個々のチェーン・ステップの停止

- チェーンの一時停止

- チェーン・ステップのスキップ

- チェーンの一部実行

- 実行中のチェーンの監視

- 停止状態チェーンの処理

- ジョブの優先度付け

- ジョブ・クラスのジョブ優先度の管理

- ジョブ・クラスのタスクとそのプロシージャ

- ジョブ・クラスの作成

- ジョブ・クラスの変更

- ジョブ・クラスの削除

- ジョブ・クラス内でのジョブの相対的な優先度の設定

- ウィンドウを使用したジョブ・スケジューリングとジョブ優先度の管理

- ウィンドウのタスクとそのプロシージャ

- ウィンドウの作成

- ウィンドウの変更

- ウィンドウのオープン

- ウィンドウのクローズ

- ウィンドウの削除

- ウィンドウの無効化

- ウィンドウの有効化

- ウィンドウ・グループを使用したジョブ・スケジューリングとジョブ優先度の管理

- ウィンドウ・グループのタスクとそのプロシージャ

- ウィンドウ・グループの作成

- ウィンドウ・グループの削除

- ウィンドウ・グループへのメンバーの追加

- ウィンドウ・グループからのメンバーの削除

- ウィンドウ・グループの有効化

- ウィンドウ・グループの無効化

- リソース・マネージャを使用したジョブ間のリソース割当て

- ジョブに対するリソース割当ての例

- ジョブの監視

- ジョブ・ログの表示

- 実行詳細

- ジョブおよびジョブ・クラスのロギング・レベルの優先度

- 複数の宛先のジョブの監視

- スケジューラによって呼び出されるイベントによるジョブ状態の監視

- イベントの概要

- イベントを呼び出すようにジョブを変更する方法

- ジョブの状態イベントのアプリケーションでの使用

- 電子メール通知によるジョブ状態の監視

- 電子メール通知の概要

- ジョブに対する電子メール通知の追加

- ジョブに対する電子メール通知の削除

- 電子メール通知情報の表示

30 Oracle Schedulerの管理

- Oracle Schedulerの構成

- Oracle Schedulerの権限の構成

- スケジューラのプリファレンスの設定

- Oracle Scheduler Agentを使用したリモート・ジョブの実行

- リモート・ジョブを実行するためのデータベースの設定の有効化と無効化

- リモート・ホストでのスケジューラ・エージェントのインストールと構成

- スケジューラ・エージェントによるタスクの実行

- スケジューラの監視と管理

- 現在アクティブなウィンドウとリソース・プランの表示

- 現在実行中のジョブに関する情報の検索

- ウィンドウ・ログおよびジョブ・ログの監視と管理

- ジョブ・ログ

- ウィンドウ・ログ

- ログのパージ

- スケジューラ・セキュリティの管理

- スケジューラのインポート/エクスポート

- スケジューラのトラブルシューティング

- ジョブが実行されない

- ジョブの状態の概要

- ジョブ・ログの表示

- リモート・ジョブのトラブルシューティング

- 障害後のジョブ・リカバリの概要

- プログラムが無効化される

- ウィンドウの有効化に失敗する

- スケジューラの使用例

- ジョブ・クラスの作成例

- 属性の設定例

- チェーンの作成例

- イベントに基づくジョブとスケジュールの作成例

- Oracle Data Guard環境でのジョブの作成例

- スケジューラの参照情報

- スケジューラ権限

- スケジューラのデータ・ディクショナリ・ビュー

第V部 分散データベースの管理

31 分散データベースの概念

- 分散データベース・アーキテクチャ

- 同機種間分散データベース・システム

- 分散データベースと分散処理

- 分散データベースとレプリケート・データベース

- 異機種間分散データベース・システム

- 異機種間サービス

- Transparent Gatewayエージェント

- Generic Connectivity

- クライアント/サーバー・データベース・アーキテクチャ

- データベース・リンク

- データベース・リンクの概要

- 共有データベース・リンクの概要

- データベース・リンクを使用する理由

- データベース・リンク内のグローバル・データベース名

- ループバック・データベース・リンクとしてのグローバル名

- データベース・リンクの名前

- データベース・リンクのタイプ

- データベース・リンクのユーザー

- 接続ユーザー・データベース・リンク

- 固定ユーザー・データベース・リンク

- 現行ユーザー・データベース・リンク

- データベース・リンクの作成: 例

- スキーマ・オブジェクトとデータベース・リンク

- データベース・リンクを使用したスキーマ・オブジェクトの命名

- リモート・スキーマ・オブジェクトへのアクセスに必要な認可

- スキーマ・オブジェクトのシノニム

- スキーマ・オブジェクトの名前解決

- データベース・リンクの制限事項

- 分散データベースの管理

- サイト自律性

- 分散データベースのセキュリティ

- データベース・リンクを介した認証

- パスワードなしの認証

- ユーザー・アカウントおよびロールのサポート

- ユーザーと権限の集中管理

- データの暗号化

- データベース・リンクの監査

- 管理ツール

- Enterprise Manager

- サード・パーティ製管理ツール

- SNMPサポート

- 分散システムでのトランザクション処理

- リモートSQL文

- 分散SQL文

- リモート文と分散型の文の共有SQL

- リモート・トランザクション

- 分散トランザクション

- 2フェーズ・コミット・メカニズム

- データベース・リンクの名前解決

- グローバル・データベース名が完全なときの名前解決

- グローバル・データベース名が部分的なときの名前解決

- グローバル・データベース名をまったく指定しないときの名前解決

- 名前解決のための検索の終了

- スキーマ・オブジェクトの名前解決

- グローバル・オブジェクトの名前解決の例: 完全なオブジェクト名

- グローバル・オブジェクトの名前解決の例: 部分的なオブジェクト名

- ビュー、シノニムおよびプロシージャでのグローバル名前解決

- グローバル名を変更したときに起こる動作

- グローバル名の変更例

- 分散データベース・アプリケーションの開発

- 分散データベース・システムにおける透過性

- 位置の透過性

- SQLおよびCOMMITの透過性

- レプリケーションの透過性

- リモート・プロシージャ・コール(RPC)

- 分散問合せの最適化

- 分散環境でのキャラクタ・セットのサポート

- クライアント/サーバー環境

- 同機種間分散環境

- 異機種間分散環境

32 分散データベースの管理

- 分散システムでのグローバル名の管理

- グローバル・データベース名の書式の理解

- グローバル・ネーミング施行の判断

- グローバル・データベース名の参照

- グローバル・データベース名のドメインの変更

- グローバル・データベース名の変更: 使用例

- データベース・リンクの作成

- データベース・リンクの作成に必要な権限の取得

- リンク・タイプの指定

- プライベート・データベース・リンクの作成

- パブリック・データベース・リンクの作成

- グローバル・データベース・リンクの作成

- リンク・ユーザーの指定

- 固定ユーザー・データベース・リンクの作成

- 接続ユーザーおよび現行ユーザー・データベース・リンクの作成

- リンク名に含まれるサービス名を指定するための接続修飾子の使用

- 共有データベース・リンクの使用

- 共有データベース・リンクの使用の判断

- 共有データベース・リンクの作成

- 共有データベース・リンクの構成

- 専用サーバーへの共有リンクの作成

- 共有サーバーへの共有リンクの作成

- データベース・リンクの管理

- データベース・リンクのクローズ

- データベース・リンクの削除

- プライベート・データベース・リンクの削除手順

- パブリック・データベース・リンクの削除手順

- アクティブ・データベース・リンクの接続数の制限

- データベース・リンク情報の表示

- データベース内のリンクの判断

- オープンしているリンク接続の判断

- 位置の透過性の作成

- ビューを使用した位置の透過性の作成

- シノニムを使用した位置の透過性の作成

- シノニムの作成

- 権限とシノニムの管理

- プロシージャを使用した位置の透過性の作成

- ローカル・プロシージャを使用したリモート・データの参照

- ローカル・プロシージャを使用したリモート・プロシージャのコール

- ローカル・シノニムを使用したリモート・プロシージャの参照

- プロシージャと権限の管理

- 文の透過性の管理

- 分散データベースの管理: 例

- 例1: パブリック固定ユーザーのデータベース・リンクの作成

- 例2: パブリック固定ユーザーの共有データベース・リンクの作成

- 例3: パブリック接続ユーザーのデータベース・リンクの作成

- 例4: パブリック接続ユーザーの共有データベース・リンクの作成

- 例5: パブリック現行ユーザーのデータベース・リンクの作成

33 分散データベース・システムのアプリケーション開発

- アプリケーション・データの分散の管理

- データベース・リンクにより確立される接続の制御

- 分散システムの参照整合性の維持

- 分散問合せのチューニング

- 連結インライン・ビューの使用

- コストベース最適化の使用

- コストベース最適化の動作の仕組み

- コストベース最適化の設定

- ヒントの使用

- NO_MERGEヒントの使用

- DRIVING_SITEヒントの使用

- 実行計画の分析

- 実行計画の生成

- 実行計画の表示

- リモート・プロシージャのエラー処理

34 分散トランザクションの概念

- 分散トランザクションの概要

- DMLおよびDDLトランザクション

- トランザクション制御文

- 分散トランザクションのセッション・ツリー

- クライアント

- データベース・サーバー

- ローカル・コーディネータ

- グローバル・コーディネータ

- コミット・ポイント・サイト

- 分散トランザクションのコミットの仕組み

- コミット・ポイント強度

- 2フェーズ・コミット・メカニズム

- 準備フェーズ

- 準備フェーズでの応答のタイプ

- 準備フェーズの手順

- コミット・フェーズ

- コミット・フェーズの手順

- グローバル・データベースの一貫性の保証

- 情報消去フェーズ

- インダウト・トランザクション

- インダウト・トランザクションの自動解決

- 準備フェーズ中の障害

- コミット・フェーズ中の障害

- インダウト・トランザクションの手動解決

- インダウト・トランザクションのシステム変更番号の関連性

- 分散トランザクション処理: 事例

- 第1段階: クライアント・アプリケーションによるDML文の発行

- 第2段階: Oracle Databaseによるコミット・ポイント・サイトの判別

- 第3段階: グローバル・コーディネータによる準備応答の送信

- 第4段階: コミット・ポイント・サイトによるコミット

- 第5段階: コミット・ポイント・サイトによるグローバル・コーディネータへのコミットの通知

- 第6段階: グローバルおよびローカル・コーディネータによる全ノードへのコミットの要求

- 第7段階: グローバル・コーディネータとコミット・ポイント・サイトによるコミットの完了

35 分散トランザクションの管理

- ノードのコミット・ポイント強度の指定

- トランザクションの命名

- 分散トランザクション情報の表示

- 準備完了トランザクションのID番号と状態の判断

- インダウト・トランザクションのセッション・ツリーのトレース

- インダウト・トランザクションの処理方法の決定

- 2フェーズ・コミットに関する問題の検出

- 手動上書きを実行するかどうかの判断

- トランザクション・データの分析

- コミットまたはロールバックされたノードの特定

- トランザクション・コメントの確認

- トランザクション・アドバイスの確認

- インダウト・トランザクションの手動上書き

- インダウト・トランザクションの手動コミット

- トランザクションIDのみを使用したコミット

- システム変更番号(SCN)を使用したコミット

- インダウト・トランザクションの手動ロールバック

- データ・ディクショナリからの保留行のパージ

- PURGE_LOST_DB_ENTRYプロシージャの実行

- DBMS_TRANSACTIONを使用する時期の判断

- インダウト・トランザクションの手動コミット: 例

- 手順1: ユーザーからのフィードバックの記録

- 手順2: DBA_2PC_PENDINGの問合せ

- グローバル・トランザクションIDの判断

- トランザクションの状態の判断

- コメントまたはアドバイスの確認

- 手順3: ローカル・ノードでのDBA_2PC_NEIGHBORSの問合せ

- データベースのロールとデータベース・リンク情報の取得

- コミット・ポイント・サイトの判別

- 手順4: 全ノードでのデータ・ディクショナリ・ビューの問合せ

- salesでのペンディング・トランザクションの状態の確認

- salesでのコーディネータとコミット・ポイント・サイトの判別

- HQでのペンディング・トランザクションの状態の確認

- 手順5: インダウト・トランザクションのコミット

- 手順6: DBA_2PC_PENDINGを使用したMIXED結果のチェック

- ロックによるデータ・アクセスの障害

- トランザクションのタイムアウト

- インダウト・トランザクションによるロック

- 分散トランザクション障害のシミュレーション

- 分散トランザクションの強制障害

- RECOの有効化と無効化

- 読込み一貫性の管理

第VI部 付録

A Oracle Database 11gリリース2におけるDBMS_JOBのサポート

- DBMS_JOBの概要

- DBMS_JOBの構成

- DBMS_JOBとOracle Schedulerの使用

- DBMS_JOBからOracle Schedulerへの移行

- ジョブの作成

- ジョブの変更

- ジョブ・キューからのジョブの削除

索引

図一覧

- 1-1 Oracle Databaseのリリース番号の例

- 1-2 データベース管理者の認証方式

- 5-1 Oracle Databaseの専用サーバー・プロセス

- 5-2 Oracle Databaseの共有サーバー・プロセス

- 6-1 Oracle Databaseのメモリー構造

- 9-1 ADR内の製品/コンポーネント・タイプのサブディレクトリ

- 9-2 データベース・インスタンスのADRディレクトリ構造

- 9-3 問題の調査、レポートおよび解決のためのワークフロー

- 9-4 データベース・ホームページの「アラート」セクション

- 9-5 Enterprise Managerの「サポート・ワークベンチ」ホームページ

- 9-6 「カスタム・パッケージング: パッケージの選択」ページ

- 9-7 「パッケージのカスタマイズ」ページ

- 9-8 「ファイルのコピー・アウト」ページ

- 9-9 「パッケージのカスタマイズ」ページの「ファイル」サブページ

- 10-1 リリース11g以降の管理サービス・ホームのディレクトリ構造

- 10-2 リリース10gの管理ホームのディレクトリ構造

- 12-1 LGWRによるREDOログ・ファイルの再利用

- 12-2 多重REDOログ・ファイル

- 12-3 多重REDOログ・ファイルの有効な構成と無効な構成

- 13-1 ARCHIVELOGモードでのREDOログ・ファイルの使用

- 15-1 ファイル・マッピングの構成要素

- 15-2 マッピング構造の図

- 19-1 「表」ページ

- 19-2 「アドバイザ・セントラル」ページ

- 19-3 「セグメント・アドバイザ推奨」ページ

- 19-4 「推奨事項の詳細」ページ

- 21-1 索引の結合

- 22-1 クラスタ化表データ

- 27-1 単純なリソース・プラン

- 27-2 サブプランを含むリソース・プラン

- 27-3 複数レベルのプラン・スキーマ

- 27-4 サブプランおよびコンシューマ・グループに最大使用率が設定されたリソース・プラン

- 28-1 複数のブランチを持つチェーン

- 28-2 ジョブに割り当てるリソースの定義に役立つウィンドウ

- 28-3 ウィンドウとリソース・プラン(例1)

- 28-4 ウィンドウとリソース・プラン(例2)

- 28-5 プログラム、ジョブおよびスケジュール間の関連

- 28-6 スケジューラの構成要素

- 28-7 Oracle RACのアーキテクチャとスケジューラ

- 28-8 サービス・アフィニティとスケジューラ

- 29-1 ステップ3で一時停止したチェーン

- 29-2 リソース・プランの例

- 31-1 同機種間分散データベース

- 31-2 Oracle Databaseの分散データベース・システム

- 31-3 データベース・リンク

- 31-4 ネットワーク化されたデータベースの階層的な配置

- 31-5 グローバル・ユーザーのセキュリティ

- 31-6 クライアント/サーバー環境におけるNLSパラメータの設定

- 31-7 同機種環境におけるNLSパラメータの設定

- 31-8 異機種環境におけるNLSパラメータの設定

- 32-1 専用サーバー・プロセスへの共有データベース・リンク

- 32-2 共有サーバーへの共有データベース・リンク

- 32-3 ビューと位置の透過性

- 34-1 分散システム

- 34-2 セッション・ツリーの例

- 34-3 コミット・ポイント・サイト

- 34-4 コミット・ポイント強度とコミット・ポイント・サイトの決定

- 34-5 準備フェーズ中の障害

- 34-6 コミット・フェーズ中の障害

- 34-7 セッション・ツリーの定義

- 34-8 コミット・ポイント・サイトの判別

- 34-9 準備メッセージの送信と確認

- 34-10 ノードへのコミットの指示

- 35-1 インダウト分散トランザクションの例

表一覧

- 1-1 UNIX、LinuxおよびWindowsにおけるパスワード・ファイルに必要な名前と場所

- 2-1 データベース計画タスク

- 2-2 推奨される最低限の初期化パラメータ

- 2-3 UNIX、Linux、WindowsにおけるPFILEおよびSPFILEのデフォルトの名前と場所

- 4-1 Oracle Restartで自動的に再起動されるOracleコンポーネント

- 4-2 作成操作とOracle Restart構成

- 4-3 削除操作とOracle Restart構成

- 4-4 イベント・レコード・パラメータと説明

- 4-5 FANパラメータおよび一致するデータベースの署名

- 4-6 SRVCTLを起動するOracleホームの決定

- 4-7 SRVCTLコマンドの概要

- 4-8 コンポーネント・キーワードと略称

- 4-9 srvctl addの概要

- 4-10 srvctl add asmのオプション

- 4-11 srvctl add databaseのオプション

- 4-12 srvctl add listenerのオプション

- 4-13 srvctl add onsのオプション

- 4-14 srvctl add serviceのオプション

- 4-15 srvctl configの概要

- 4-16 srvctl config asmのオプション

- 4-17 srvctl config databaseのオプション

- 4-18 srvctl config listenerのオプション

- 4-19 srvctl config serviceのオプション

- 4-20 srvctl disableの概要

- 4-21 srvctl disable databaseのオプション

- 4-22 srvctl disable diskgroupのオプション

- 4-23 srvctl disable listenerのオプション

- 4-24 srvctl disable onsのオプション

- 4-25 srvctl disable serviceのオプション

- 4-26 srvctl enableの概要

- 4-27 srvctl enable databaseのオプション

- 4-28 srvctl enable diskgroupのオプション

- 4-29 srvctl enable listenerのオプション

- 4-30 srvctl enable onsのオプション

- 4-31 srvctl enable serviceのオプション

- 4-32 srvctl getenvの概要

- 4-33 srvctl getenv asmのオプション

- 4-34 srvctl getenv databaseのオプション

- 4-35 srvctl getenv listenerのオプション

- 4-36 srvctl modifyの概要

- 4-37 srvctl modify asmのオプション

- 4-38 srvctl modify databaseのオプション

- 4-39 srvctl modify listenerのオプション

- 4-40 srvctl modify onsのオプション

- 4-41 srvctl modify serviceのオプション

- 4-42 srvctl removeの概要

- 4-43 srvctl remove asmのオプション

- 4-44 srvctl remove databaseのオプション

- 4-45 srvctl remove diskgroupのオプション

- 4-46 srvctl remove listenerのオプション

- 4-47 srvctl remove onsのオプション

- 4-48 srvctl remove serviceのオプション

- 4-49 srvctl setenvおよびsrvctl unsetenvの概要

- 4-50 srvctl setenv databaseのオプション

- 4-51 srvctl setenv databaseのオプション

- 4-52 srvctl setenv listenerのオプション

- 4-53 srvctl startの概要

- 4-54 srvctl start asmのオプション

- 4-55 srvctl start databaseのオプション

- 4-56 srvctl start diskgroupのオプション

- 4-57 srvctl start homeのオプション

- 4-58 srvctl start listenerのオプション

- 4-59 srvctl start onsのオプション

- 4-60 srvctl start serviceのオプション

- 4-61 srvctl statusの概要

- 4-62 srvctl status asmのオプション

- 4-63 srvctl status databaseのオプション

- 4-64 srvctl status diskgroupのオプション

- 4-65 srvctl status homeのオプション

- 4-66 srvctl status listenerのオプション

- 4-67 srvctl status serviceのオプション

- 4-68 srvctl stopの概要

- 4-69 srvctl stop asmのオプション

- 4-70 srvctl stop databaseのオプション

- 4-71 srvctl stop diskgroupのオプション

- 4-72 srvctl stop homeのオプション

- 4-73 srvctl stop listenerのオプション

- 4-74 srvctl stop onsのオプション

- 4-75 srvctl stop serviceのオプション

- 4-76 srvctl unsetenvコマンドの概要

- 4-77 srvctl unsetenv asmのオプション

- 4-78 srvctl unsetenv databaseのオプション

- 4-79 srvctl unsetenv listenerのオプション

- 4-80 CRSCTLコマンドの概要

- 4-81 crsctl stop hasのオプション

- 5-1 専用サーバー、共有サーバーおよびデータベース常駐接続プーリング

- 5-2 データベース常駐接続プーリングの構成パラメータ

- 5-3 データベース常駐接続プーリングのデータ・ディクショナリ・ビュー

- 5-4 Oracle Databaseバックグラウンド・プロセス

- 6-1 グラニュル・サイズ

- 6-2 自動サイズ設定SGAコンポーネントと対応するパラメータ

- 6-3 SGA_TARGETの領域を使用する手動サイズ設定SGAコンポーネント

- 6-4 フラッシュ・キャッシュの初期化パラメータ

- 9-1 Oracle DatabaseのADRホームのパス・コンポーネント

- 9-2 ADRホーム・サブディレクトリ

- 9-3 V$DIAG_INFOビューのデータ

- 9-4 V$DIAG_CRITICAL_ERRORビューのデータ

- 9-5 クリティカル・エラーの修復に役立つOracleアドバイザ

- 9-6 「データ・ブロックの整合性チェック」のパラメータ

- 9-7 「REDOの整合性チェック」のパラメータ

- 9-8 「UNDOセグメントの整合性チェック」のパラメータ

- 9-9 「トランザクションの整合性チェック」のパラメータ

- 9-10 「ディクショナリの整合性チェック」のパラメータ

- 10-1 EMCAコマンドライン操作

- 10-2 EMCAコマンドライン・フラグ

- 10-3 EMCAコマンドライン・パラメータ

- 13-1 使用例1のLOG_ARCHIVE_MIN_SUCCEED_DESTの値

- 13-2 使用例2のLOG_ARCHIVE_MIN_SUCCEED_DESTの値

- 14-1 互換性の最低要件

- 18-1 エディションに基づく再定義のためのDBAのタスク

- 19-1 セグメント・アドバイザに関連するDBMS_ADVISORパッケージ・プロシージャ

- 19-2 DBMS_ADVISOR.CREATE_OBJECTの入力

- 19-3 DBMS_ADVISOR.SET_TASK_PARAMETERの入力

- 19-4 セグメント・アドバイザの結果の種類

- 19-5 セグメント・アドバイザの結果: 要約

- 20-1 表圧縮方法

- 20-2 表の圧縮の特徴

- 20-3 エラーを説明する必須列

- 20-4 エラー・ロギング表の列のデータ型

- 20-5 外部表のALTER TABLE句

- 21-1 索引の結合と再作成に関するコストと利点

- 25-1 破損検出方法の比較

- 26-1 事前定義のメンテナンス・ウィンドウ

- 26-2 自動化メンテナンス・タスクのデータベース・ディクショナリ・ビュー

- 27-1 3つのレベルがある単純なリソース・プラン

- 27-2 最大使用率の制限が適用された3つのレベルがあるリソース・プラン

- 27-3 パラレル・ステートメント・ディレクティブが設定されたリソース・プラン

- 27-4 事前定義のリソース・プラン

- 27-5 事前定義のリソース・コンシューマ・グループ

- 27-6 事前定義のコンシューマ・グループ・マッピング・ルール

- 27-7 リソース・マネージャのデータ・ディクショナリ・ビュー

- 28-1 ローカル外部ジョブに対するデフォルトの資格証明

- 29-1 ジョブのタスクとそのプロシージャ

- 29-2 資格証明および宛先のタスクとそのプロシージャ

- 29-3 プログラムのタスクとそのプロシージャ

- 29-4 スケジュールのタスクとそのプロシージャ

- 29-5 アプリケーションによって呼び出されるイベントに対するイベント・タスクとそのプロシージャ

- 29-6 チェーンのタスクとそのプロシージャ

- 29-7 チェーン・ステップのstate属性の値

- 29-8 ジョブ・クラスのタスクとそのプロシージャ

- 29-9 ウィンドウのタスクとそのプロシージャ

- 29-10 ウィンドウ・グループのタスクとそのプロシージャ

- 29-11 ジョブのロギング・レベル

- 29-12 複数の宛先のジョブを対象としたスケジューラ・データ・ディクショナリ・ビューの内容

- 29-13 スケジューラによって呼び出されるジョブ状態イベントのタイプ

- 30-1 schagentのオプション

- 30-2 ジョブの状態

- 30-3 スケジューラのシステム権限

- 30-4 スケジューラのオブジェクト権限

- 30-5 スケジューラのビュー

- 35-1 DBA_2PC_PENDING

- 35-2 DBA_2PC_NEIGHBORS

はじめに

このマニュアルでは、Oracle Databaseを作成、構成および管理する方法について説明します。

「はじめに」の内容は次のとおりです。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このマニュアルは、次のタスクを実行するデータベース管理者を対象にしています。

- 1つ以上のOracle Databaseの作成および構成

- Oracle Databaseの監視およびチューニング

- Oracle Databaseに対する日常的なメンテナンス操作の監視

- 表、索引、ビューなどのスキーマ・オブジェクトの作成およびメンテナンス

- システム・ジョブおよびユーザー・ジョブのスケジュール

- 問題の診断、修復およびレポート

このマニュアルを使用するにあたって、リレーショナル・データベースの概念を理解しておく必要があります。また、Oracle Databaseを実行するオペレーティング・システム環境についても知っておく必要があります。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

- 『Oracle Database 2日でデータベース管理者』

- 『Oracle Database概要』

- 『Oracle Database SQL言語リファレンス』

- 『Oracle Databaseリファレンス』

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

- 『Oracle Automatic Storage Management管理者ガイド』

- 『Oracle Database VLDBおよびパーティショニング・ガイド』

- 『Oracle Databaseエラー・メッセージ』

- 『Oracle Database Net Services管理者ガイド』

- 『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

- 『Oracle Databaseパフォーマンス・チューニング・ガイド』

- 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』

- 『Oracle Database PL/SQL言語リファレンス』

- 『SQL*Plus ユーザーズ・ガイドおよびリファレンス』

このマニュアルの例の多くは、Oracle Databaseのインストール時に基本インストール・オプションを選択した場合にデフォルトでインストールされるサンプル・スキーマを使用しています。スキーマの作成方法および使用方法については、『Oracle Databaseサンプル・スキーマ』を参照してください。

表記規則

このマニュアルでは、次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このマニュアルに記載されている新機能

ここでは、このマニュアルに記載されているOracle Database 11g リリース2の新機能について説明し、追加情報の参照先を示します。

この項の内容は次のとおりです。

- 管理者ガイドに記載されているOracle Database 11g リリース2(11.2.0.3)の新機能

- 管理者ガイドに記載されているOracle Database 11g リリース2(11.2.0.2)の新機能

- 管理者ガイドに記載されているOracle Database 11g リリース2(11.2.0.1)の新機能

管理者ガイドに記載されているOracle Database 11g リリース2(11.2.0.3)の新機能

- CloneDBを使用したデータベースのcopy-on-writeクローニング
CloneDBを使用してデータベースをクローニングする場合、Oracle Databaseはcopy-on-writeテクノロジに基づいてCloneDBデータベースにファイルを作成できるため、ディスク上に追加の記憶域が必要となるのは、CloneDBデータベースで変更されたブロックに対してのみとなります。

「CloneDBを使用したデータベースのクローニング」を参照してください。

- ハイブリッド列圧縮
ハイブリッド列圧縮により、ダイレクト・パス・ロードが行われるデータに高度な圧縮レベルが提供されます。この新しい圧縮機能は、更新頻度の低いデータに推奨されます。ハイブリッド列圧縮は、パーティション、表および表領域のレベルで指定できます。また、希望の圧縮レベルを指定して、ディスク使用量とCPUオーバーヘッドの間のトレードオフ関係を適切に調整することもできます。アプリケーションに対する適切な圧縮レベルを決定するために圧縮アドバイザを使用できます。

「表圧縮の使用」を参照してください。

管理者ガイドに記載されているOracle Database 11g リリース2(11.2.0.2)の新機能

- パーティション・オブジェクトのセグメント作成の遅延

- セグメント作成の遅延が、パーティション・オブジェクトだけでなく、非パーティション・オブジェクトにも適用されるようになりました。
「セグメント作成の遅延の理解」を参照してください。

- DBMS_SPACE_ADMIN.DROP_EMPTY_SEGMENTSプロシージャを使用して、以前のリリースから移行した空の表からセグメントを削除できます。
「未使用オブジェクト記憶域の削除」を参照してください。

- TRUNCATE文のDROP ALL STORAGE句を使用して、表のセグメントの割当てを解除できます。
「TRUNCATEの使用」を参照してください。

- DBMS_SPACE_ADMIN.MATERIALIZE_DEFERRED_SEGMENTSプロシージャを使用して、セグメント作成が遅延された表、パーティション、および依存オブジェクトのセグメントをマテリアライズできます。
「セグメントのマテリアライズ」を参照してください。

- パーティション表の第1エクステント・サイズに新たに導入されたデフォルトにより、パフォーマンスが向上します。
パーティション表のすべての新規セグメントについて、第1エクステントのデフォルトのサイズが64KBではなく8MBになりました。このことは、パーティション表に対する挿入と問合せのパフォーマンス向上に役立ちます。パーティション表の初期サイズが大きくても、十分なデータが挿入されると、領域消費は以前のリリースと同じになります。このデフォルトは、表の記憶域句にINITIALサイズを設定して上書きできます。この新しいデフォルトは、表パーティションおよびLOBパーティションにのみ適用されます。

- NOLOGGINGダイレクト・パス・インサートのパフォーマンスを向上させるために新たに導入された初期化パラメータ
制御ファイルの定期更新を無効にして、リカバリ不能なダイレクト・パス・インサートのパフォーマンスを大幅に向上させることができるようになりました。このことを行うには、新たに導入されたDB_UNRECOVERABLE_SCN_TRACKING初期化パラメータをFALSEに設定します。ただし、これらの制御ファイルの更新を無効化してリカバリ不能なダイレクト・パス・インサートを実行すると、データファイルが現在リカバリ不能かどうかをデータベースに問い合せて正確に判断できなくなります。

「ロギングなしダイレクト・パスINSERT」を参照してください。

- Oracle Schedulerで改善された電子メール通知機能
Oracle Scheduler電子メール通知のプリファレンスに、指定のSMTPサーバーに対する認証およびSSLプロトコルまたはTLSプロトコルを指定するオプションが追加されました。

「スケジューラのプリファレンスの設定」を参照してください。

- データベース・サービスのエディション属性
データベース・サービスの作成時にそのエディション属性を設定したり、既存のデータベース・サービスのエディション属性を変更できます。

「データベース・サービスのエディション属性の設定」を参照してください。

- Oracle Database Resource Managerの拡張

- コンシューマ・グループごとにパラレル・ステートメント・アクティビティを制限し、パラレル・ステートメント・キュー内のパラレル・ステートメントの優先度を設定し、パラレル・ステートメント・キューでのパラレル・ステートメントの待機時間を制限して、パラレル・ステートメントのパフォーマンスを最適化できます。
パラレル・ステートメント・キューイングを使用すると、指定した並列度で文を実行するのに十分なリソースがデータベースにないときも、パラレル・ステートメントを効率的に管理できます。パラレル・ステートメントを発行したとき、そのパラレル・ステートメントの実行に必要なリソースがパラレル・ステートメントの割当て先のデータベースまたはコンシューマ・グループに指定されたパラレル・ステートメント・アクティビティの制限を超えている場合、パラレル・ステートメントはパラレル・ステートメント・キューに追加されます。パラレル・ステートメント・キューイングでは、リソース・プランで指定された優先度およびリソース割当てに従って、複数のパラレル・ステートメント・ワークロードも管理できます。

関連項目:

- 「パラレル・ターゲット率」

- 「パラレル・キューのタイムアウト」

- 「ディレクティブ属性を使用したパラレル・ステートメントの管理の例」

- 各リソース・プランに対する毎分ごとのメトリックを使用してCPU使用を追跡できます。また、リソース・マネージャが使用可能になっていない場合でも、コンシューマ・グループのリソース使用率を監視できるため、リソース・マネージャの潜在的影響を確認できます。
「V$RSRCMGRMETRIC」を参照してください。

管理者ガイドに記載されているOracle Database 11g リリース2(11.2.0.1)の新機能

- Oracle Restartは、障害発生後にデータベースを自動的に再起動することで、データベースの可用性を向上させます。
Oracle Restartを構成すると、ハードウェアまたはソフトウェア障害の後、またはデータベース・ホスト・コンピュータの再起動後に、データベース、リスナー、Oracle Automatic Storage Managementインスタンスおよびその他のOracleコンポーネントが自動的に再起動されるようにできます。

第4章「Oracle Databaseの自動再起動の構成」を参照してください。

- エディションに基づく再定義により、アプリケーション開発者およびDBAは、アプリケーションの停止時間をごくわずかまたはゼロに抑えてアプリケーションをアップグレードできます。
エディションと呼ばれる新しいデータベース構造は、新しいコードのインストールやデータの変更が実行中の本番アプリケーションから認識されないようにするためのプライバシ・メカニズムを提供します。必要なすべての変更をプライベートで実行した後、変更内容をユーザーに対して使用可能にすることができます。エディションに基づく再定義をサポートするために、エディショニング・ビューと呼ばれる新しいタイプのビューと、crosseditionトリガーと呼ばれる新しいタイプのトリガーが導入されています。

「エディションの管理」を参照してください。

- データベース・スマート・フラッシュ・キャッシュ
データベース・スマート・フラッシュ・キャッシュはオプションのメモリー・コンポーネントで、データベースがSolarisまたはOracle Linux上で稼働している場合に追加できます。これはSGA常駐バッファ・キャッシュで、データベース・ブロックに対するレベル2のキャッシュを提供します。これにより、応答時間と全体的なスループットを向上できます。

「メモリー・アーキテクチャの概要」を参照してください。

- 自動セグメント・アドバイザによって、OLTP圧縮を表に使用することを指示する推奨事項が戻されるようになりました。
「使用できない領域の再生」を参照してください。

- セグメント作成の遅延
ローカルで管理されている表領域に非パーティションのヒープ構成表を作成する場合、表セグメントの作成が最初の行の挿入時まで遅延されます。

「セグメント作成の遅延の理解」を参照してください。

- Oracle Databaseファイル・システム
Oracle Databaseファイル・システムでは、データベース表に格納されているファイルおよびディレクトリの最上部に、標準のファイル・システム・インタフェースを作成します。

詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

- Oracle Schedulerの拡張機能

- リモート・データベース・ジョブ: 同じホスト上またはリモート・ホスト上の別のデータベース・インスタンスで、ストアド・プロシージャやPL/SQL無名ブロックを実行するジョブを作成できるようになりました。ターゲット・データベースとして、任意のOracle Databaseリリースを使用できます。
「データベース・ジョブ」を参照してください。

- 複数の宛先のジョブ: ジョブを複数の場所で実行し、そのジョブのすべてのインスタンスを単一の中核データベースから制御および監視できるようになりました。これは、ジョブの作成時に複数の宛先を指定することによって実行できます。宛先には、ローカル・ホスト、ローカル・データベース、リモート・ホスト(リモート外部ジョブの場合)またはリモート・データベース(リモート・データベース・ジョブの場合)を指定できます。
「複数の宛先のジョブ」を参照してください。

- File Watcher: File Watcherと呼ばれる新しいスケジューラ・オブジェクトを使用すると、ローカル・システムまたはリモート・システムにファイルが到着したときにジョブが開始されるようにする場合に、スケジューラを簡単に構成できます。
「ファイルがシステムに到着したことによるジョブの開始」を参照してください。

- 電子メール通知: ジョブの特定の状態イベント発生時に1人以上の受信者に自動的に電子メールを送信するようにスケジューラを構成できます。これにより、ジョブが完了したときに、失敗または無効であるかどうか、割り当てられた実行時間を超過しているかどうかなどが電子メールで受信できるようになります。
「電子メール通知によるジョブ状態の監視」を参照してください。

- データベース・リソース・マネージャの拡張機能

- インスタンス・ケージング
Oracle Databaseでは、複数のデータベース・インスタンスを実行するマルチCPUサーバー上でCPU割当てを管理する方法が提供されるようになりました。インスタンス・ケージングによって、1つのデータベース・インスタンスが使用できる最大CPU数が制限されます。1つのインスタンスがCPUにバインドされると、リソース・マネージャは、現在のリソース・プランに基づいてCPU割当てを開始します。このように、インスタンス・ケージングとリソース・マネージャは連携して機能し、複数のインスタンスで目的とするサービス・レベルを実現できるようにサポートします。

「単一サーバーにおける複数のデータベース・インスタンスの管理」を参照してください。

- リソース・プラン・ディレクティブの新しいMAX_UTILIZATION_LIMIT属性を使用すると、CPU使用の絶対上限をリソース・コンシューマ・グループに設定できます。この絶対上限は、プランでのあらゆるCPU自動再配分に優先します。

- 新しいORACLE_FUNCTIONコンシューマ・グループ・マッピング・ルール・タイプ、およびデータ・ポンプとRMAN用の事前定義された新しいマッピング・ルール。
データ・ポンプによってデータのロードを実行するセッション、またはRMANによってバックアップ操作やコピー操作を実行するセッションは、事前定義されたコンシューマ・グループに自動的にマッピングされるようになりました。

「事前定義のコンシューマ・グループ・マッピング・ルール」を参照してください。

- Oracle Exadataによるデータ・ウェアハウス操作をサポートするための、新しいサンプル・リソース・プランおよびリソース・コンシューマ・グループ
「事前定義のリソース・プランおよびコンシューマ・グループ」を参照してください。

- ダイレクト・ロード操作用のみ、またはすべての(OLTP)操作用の表圧縮を指定するための新規SQLコマンド構文。
「表圧縮の使用」を参照してください。

- フラッシュ・リカバリ領域が高速リカバリ領域に名前変更されました。

- ユーザー指定のプリプロセッサ・プログラムで外部表を前処理できます。
前処理プログラムを使用すると、アクセス・ドライバでサポートされていない形式のファイルに格納されているデータを利用できます。たとえば、圧縮形式で格納されているデータにアクセスできます。ORACLE_LOADERアクセス・ドライバに対して解凍プログラムを指定すると、アクセス・ドライバでデータが処理される際にデータを解凍できます。

「外部表の前処理」を参照してください。

- アーカイブ・ログで最大30個のスタンバイ・データベースがサポートされます。

- IPバージョン6がサポートされています。
Oracle Databaseのコンポーネントおよびユーティリティで、長さ128ビットのインターネット・プロトコル・バージョン6(IPv6)のアドレスがサポートされています。SQL*Plusで簡易接続方法を使用してIPv6アドレスを指定できます。

「SQL*Plusを使用したデータベースへの接続」を参照してください。

- パフォーマンスを低下させることなく、セクター・サイズが4KBのディスク・ドライブにREDOログを格納できます。
REDOログ・ファイルで新しい4KBのブロック・サイズを使用すると、オンラインREDOログをセクター・サイズが4KBの新しい大容量ディスクに格納でき、パフォーマンス低下も発生しません。新しいブロック・サイズにより、ログ・ファイルの書込みがセクターの位置に確実に揃えられます。

「REDOログ・ファイルのブロック・サイズの計画」を参照してください。

- 障害診断インフラストラクチャのコンポーネントであるEnterprise Managerサポート・ワークベンチで、Oracle Automatic Storage Managementインスタンスでのクリティカル・エラーの調査、レポートおよび解決がサポートされます。
第9章「診断データの管理」を参照してください。

第I部

基本データベース管理

第I部では、データベース管理者が担当する作業の概要を示し、基本的なデータベース管理タスクを実行する方法を説明します。次の章で構成されます。

- 第1章「データベース管理スタート・ガイド」

- 第2章「Oracle Databaseの作成および構成」

- 第3章「起動と停止」

- 第4章「Oracle Databaseの自動再起動の構成」

- 第5章「プロセスの管理」

- 第6章「メモリーの管理」

- 第7章「ユーザーの管理とデータベースのセキュリティ保護」

- 第8章「データベースの動作の監視」

- 第9章「診断データの管理」

- 第10章「Oracle Enterprise Manager Database Controlの管理」

1 データベース管理スタート・ガイド

この章の内容は、次のとおりです。

- Oracle Databaseユーザーのタイプ

- データベース管理者のタスク

- データベースに対するコマンドとSQLの発行

- Oracle Databaseソフトウェアのリリースの識別

- データベース管理者のセキュリティと権限の概要

- データベース管理者の認証

- パスワード・ファイルの作成とメンテナンス

- データ・ユーティリティ

Oracle Databaseユーザーのタイプ

ユーザーのタイプとその役割および責任は、データベース・サイトによって異なります。小規模のサイトでは、1名のデータベース管理者を配置して、アプリケーション開発者およびユーザー向けのデータベースを管理できます。大規模なサイトでは、データベース管理者の役割を複数の人および複数の専門グループに分割する必要があります。

データベース管理者

各データベースには、少なくとも1名のDBAが必要です。Oracle Databaseシステムは規模が大きく、多数のユーザーによって使用される可能性があります。したがって、1名の担当者ではデータベースを管理できないため、複数のDBAでグループを編成して役割を分担します。

データベース管理者が担当するタスクは次のとおりです。

- Oracle Databaseサーバーとアプリケーション・ツールをインストールおよびアップグレードします。

- データベース・システムにシステム記憶域を割り当て、将来の記憶域要件を計画します。

- アプリケーション開発者がアプリケーションを設計した後、プライマリ・データベースの記憶域構造(表領域)を作成します。

- アプリケーション開発者がアプリケーションを設計した後、プライマリ・オブジェクト(表、ビュー、索引)を作成します。

- アプリケーション開発者から得た情報に基づき、必要に応じてデータベース構造を修正します。

- ユーザーを登録し、システム・セキュリティをメンテナンスします。

- Oracleのライセンス契約に従っていることを確認します。

- データベースに対するユーザー・アクセスを制御し、監視します。

- データベースのパフォーマンスを監視し、最適化します。

- データベース情報のバックアップおよびリカバリの計画を立てます。

- テープ上のアーカイブ済データをメンテナンスします。

- データベースをバックアップおよびリストアします。

- 技術サポートについてOracleサポート・サービスに連絡します。

セキュリティ管理者

サイトによっては、データベースに1名以上のセキュリティ管理者が必要です。セキュリティ管理者は、ユーザーの登録、データベースに対するユーザー・アクセスの制御と監視およびシステム・セキュリティのメンテナンスを実施します。したがって、サイトにセキュリティ管理者が別にいる場合、DBAはこれらの業務に対する役割を持ちません。セキュリティ管理者の業務の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

ネットワーク管理者

サイトによっては、1名以上のネットワーク管理者がいる場合があります。たとえば、ネットワーク管理者は、Oracle Net ServicesなどのOracleネットワーク製品を管理します。ネットワーク管理者の業務の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

関連項目:
分散環境でのネットワーク管理の詳細は、第I部「分散データベースの管理」を参照してください

アプリケーション開発者

アプリケーション開発者は、データベース・アプリケーションを設計し、実装します。アプリケーション開発者が担当するタスクは、次のとおりです。

- データベース・アプリケーションを設計、開発します。

- アプリケーションのためのデータベース構造を設計します。

- アプリケーションに対する記憶域要件を見積ります。

- アプリケーションのためのデータベース構造の変更を指定します。

- データベース管理者にこのような情報を伝えます。

- 開発中にアプリケーションをチューニングします。

- 開発中にアプリケーションに対するセキュリティ手段を確立します。

アプリケーション開発者は、これらのタスクの一部をDBAと協力して実施する場合があります。アプリケーション開発タスクの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

アプリケーション管理者

Oracle Databaseのサイトでは、特定のアプリケーションを管理するために1名以上のアプリケーション管理者が必要な場合があります。アプリケーションごとに専門の管理者を置く場合があります。

データベース・ユーザー

データベース・ユーザーは、アプリケーションまたはユーティリティを介してデータベースと対話します。一般ユーザーが担当するタスクは、次のとおりです。

- 許された範囲でデータを入力、修正および削除します。

- データのレポートを作成します。

データベース管理者のタスク

次のタスクは、Oracle Databaseを設計、実装およびメンテナンスするためのアプローチの優先度を表しています。

タスク1: データベース・サーバー・ハードウェアの評価

タスク2: Oracle Databaseソフトウェアのインストール

タスク3: データベースの計画

タスク4: データベースの作成とオープン

タスク5: データベースのバックアップ

タスク6: システム・ユーザーの登録

タスク7: データベース設計の実装

タスク8: 実行データベースのバックアップ

タスク9: データベースのパフォーマンス・チューニング

タスク10: パッチのダウンロードとインストール

タスク11: 追加ホストへのロール・アウト

次の項で、これらのタスクについて説明します。

注意:
新しいリリースにアップグレードする場合は、既存の本番環境(ソフトウェアとデータベースの両方)のバックアップを作成してからインストールしてください。既存の本番データベースの保存方法については、『Oracle Databaseアップグレード・ガイド』を参照してください。

タスク1: データベース・サーバー・ハードウェアの評価

使用可能なコンピュータ・リソースを、Oracle Databaseとそのアプリケーションで最大限に活用するための評価を行います。この評価では、次のような情報を明らかにする必要があります。

- Oracle製品に使用可能なディスク・ドライブ数

- Oracle製品に使用可能な専用テープ・ドライブ数(テープ・ドライブがある場合)

- Oracle Databaseインスタンスで使用可能なメモリーの量(システムの構成マニュアルを参照)

タスク2: Oracle Databaseソフトウェアのインストール

データベース管理者は、Oracle Databaseサーバーのソフトウェアとすべてのフロントエンド・ツール、およびデータベースにアクセスするデータベース・アプリケーションをインストールします。分散処理環境インストールでは、データベースが中核となるコンピュータ(データベース)によって制御され、データベース・ツールとアプリケーションがリモート・マシン(クライアント)で実行される場合があります。このような場合は、Oracle Databaseを実行するコンピュータに、リモート・システムを接続するために必要なOracle Netコンポーネントもインストールする必要があります。

インストールするソフトウェアの詳細は、「Oracle Databaseソフトウェアのリリースの識別」を参照してください。

関連項目:
インストールの特定の要件や指示の詳細は、次のマニュアルを参照してください。

- 使用しているオペレーティング・システム固有のOracleマニュアル

- フロントエンド・ツールおよびOracle Netドライバのインストレーション・ガイド

タスク3: データベースの計画

データベース管理者は、次のことを計画する必要があります。

- データベースの論理記憶域構造

- データベース全体の設計

- データベースのバックアップ計画

重要なことは、データベースの論理記憶域構造が、システムのパフォーマンスと様々なデータベース管理操作にどのように影響を及ぼすかについて計画することです。たとえば、データベースの表領域を作成する前に、表領域を構成するデータファイルの数、各表領域に格納される情報のタイプ、およびデータファイルが物理的に格納されるディスク・ドライブについて把握しておく必要があります。データベース構造の論理記憶域全体を計画する際は、実際にデータベースを作成し、稼働したときに、この構造によって生じる影響を考慮します。次の項目について、データベースの論理記憶域構造が及ぼす影響を検討してください。

- Oracle Databaseを実行しているコンピュータのパフォーマンス

- データ・アクセス操作中のデータベースのパフォーマンス

- データベースのバックアップおよびリカバリの手順の効率

データベース・オブジェクトのリレーショナル設計と、各オブジェクトの記憶特性について計画します。オブジェクトを作成する前に、オブジェクトと各オブジェクトの物理記憶域間の関連について計画を立てることによって、1つの単位としてのデータベースのパフォーマンスを直接制御できます。データベースの拡張計画についても必ず検討してください。

分散データベース環境では、この計画段階が非常に重要です。頻繁にアクセスされるデータの物理的な位置が、アプリケーションのパフォーマンスに大きな影響を及ぼします。

計画段階中に、データベースのバックアップ計画を作成します。バックアップの効率を改善するために、必要に応じて論理記憶域やデータベースの設計を変更します。

リレーショナル・データベース設計および分散データベース設計については、このマニュアルでは取り扱っていません。このような設計上の問題は、業界標準として認められている資料を参照してください。

データベースの論理記憶域構造、オブジェクトおよび整合性制約の作成方法は、第I部「Oracle Databaseの構造と記憶域」および第I部「スキーマ・オブジェクト」を参照してください。

タスク4: データベースの作成とオープン

データベース設計が完了すると、データベースを作成し、オープンできます。データベースを作成するには、Database Configuration Assistantを使用してインストール時に作成する方法と、データベースを作成するためのスクリプトを用意する方法があります。

データベースの作成方法については第2章「Oracle Databaseの作成および構成」を、データベース起動時のガイドラインについては第3章「起動と停止」を参照してください。

タスク5: データベースのバックアップ

データベース構造の作成後、データベースに対して予定していたバックアップ計画を実行します。追加のREDOログ・ファイルを作成し、データベース全体の最初のバックアップ(オンラインまたはオフライン)を作成して、その後の定期的なデータベース・バックアップをスケジュールします。

関連項目:
『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

タスク6: システム・ユーザーの登録

データベース構造のバックアップが完了した後、Oracleのライセンス契約に従ってデータベースのユーザーを登録し、登録したユーザーに対して適切な権限とロールを付与できます。このタスクのガイドラインについては、第7章「ユーザーの管理とデータベースのセキュリティ保護」を参照してください。

タスク7: データベース設計の実装

データベースを作成して起動し、システム・ユーザーを登録した後、必要なすべての表領域を作成して、計画したデータベースの論理構造を実装できます。表領域の作成を完了すると、データベース・オブジェクトを作成できます。

データベースの論理記憶域構造とオブジェクトの作成方法は、第I部「Oracle Databaseの構造と記憶域」および第I部「スキーマ・オブジェクト」を参照してください。

タスク8: 実行データベースのバックアップ

データベースがすべて実装されたときに、再度バックアップを作成します。定期的にバックアップを作成するようにスケジュールし、また、データベース構造の変更を実装した直後にも必ずデータベースのバックアップを作成するようにします。

タスク9: データベースのパフォーマンス・チューニング

データベースのパフォーマンスの最適化は、DBAの日常的な作業の1つです。Oracle Databaseでは、各種ユーザー・グループへのリソースの割当てを制御できるよう、データベース・リソース管理機能が提供されています。データベース・リソース・マネージャについては、第27章「Oracle Database Resource Managerを使用したリソースの管理」を参照してください。

関連項目:
データベースとアプリケーションのチューニング方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

タスク10: パッチのダウンロードとインストール

インストール後および定期的に、パッチをダウンロードしてインストールします。パッチは単一の暫定パッチおよびパッチ・セット(またはパッチ・リリース)として使用できます。暫定パッチは個々のソフトウェアの不具合を修正するもので、使用中のインストールに必要な場合と必要ではない場合があります。パッチ・リリースは、すべての顧客に適用される不具合の修正の集合です。パッチ・リリースにはリリース番号が付けられています。たとえば、Oracle Database 11.2.0.1をインストールした場合、最初のパッチ・リリースのリリース番号は11.2.0.2です。

関連項目:
パッチのダウンロードおよびインストールの手順は、使用中のプラットフォームの『Oracle Databaseインストレーション・ガイド』を参照してください。

タスク11: 追加ホストへのロール・アウト

Oracle Databaseのインストールを正しく構成し、チューニングし、パッチを適用してテストした後、そのインストールを他のホストにロール・アウトする必要がある場合があります。ロール・アウトは、次のような場合に行います。

- 複数の本番データベース・システムがある場合。

- 本番システムと同じ開発システムやテスト・システムを作成する場合。

追加の各ホストでインストール、チューニングおよびパッチ適用を実行するかわりに、テスト済のOracle Databaseインストールを他のホストにクローニングすると、時間を節約でき、不整合をなくすことができます。次の2種類のクローニングを使用できます。

- Oracleホームのクローニング: Oracleホーム・ディレクトリとサブディレクトリの構成済およびパッチ適用済バイナリのみが宛先のホストにコピーされ、新しい環境にあわせて調整されます。その後、このクローニングしたホームを使用してインスタンスを起動し、データベースを作成できます。
Enterprise ManagerのOracleホームのクローニング・ツールを使用すると、Oracleホームを1つ以上の宛先ホストにクローニングできます。また、提供されているスクリプトのセットとOracle Universal Installerを使用して、Oracleホームを手動でクローニングすることもできます。

- データベースのクローニング: データベース・ファイルや初期化パラメータなどのチューニング済のデータベースが、既存のOracleホーム(おそらくクローニングしたホーム)にクローニングされます。
Enterprise Managerのデータベースのクローニング・ツールを使用すると、Oracleデータベース・インスタンスを既存のOracleホームにクローニングできます。

関連項目:

- Oracleソフトウェアのクローニングの詳細は、『Oracle Universal InstallerおよびOpatchユーザーズ・ガイドfor Windows and UNIX』を参照してください。

- データベースのクローニングの手順は、Enterprise Managerのオンライン・ヘルプを参照してください。

データベースに対するコマンドとSQLの発行

Oracle Databaseとのやり取りは主にSQL文を発行して行います。Oracle Databaseでは、データベースの起動と停止およびデータベース設定の変更などのコマンドを含む、SQLのスーパーセットもサポートされています。これらのSQL文やコマンドをOracle Databaseに発行する方法は3つあります。

- SQL*Plusのコマンドライン・インタフェースを使用する直接的な方法

- Oracle Enterprise Managerのグラフィカル・ユーザー・インタフェースを使用する間接的な方法
Oracle Enterprise Manager(Enterprise Manager)を使用すると、使いやすいグラフィカル・インタフェースを使用してデータベースを管理できます。SQL文やコマンドは、Enterprise Managerが内部的に発行します。

詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- SQL Developerを使用する直接的な方法
開発者はSQL Developerを使用してデータベース・スキーマとアプリケーションの作成およびテストをしますが、SQL Developerはデータベースの管理作業にも使用できます。

詳細は、『Oracle Database 2日で開発者ガイド』を参照してください。

ここでは、SQL*Plusを使用して、SQL文とコマンドをデータベースに対して発行する方法について説明します。内容は次のとおりです。

- SQL*Plusについて

- SQL*Plusを使用したデータベースへの接続

SQL*Plusの概要

SQL*PlusはOracle Databaseへの主要なコマンドライン・インタフェースです。SQL*Plusは、データベースの起動と停止、データベース初期化パラメータの設定、ユーザーの作成と管理、データベース・オブジェクト(表や索引など)の作成と変更、データの挿入と更新、SQL問合せの実行などを行うために使用します。

SQL文とコマンドを発行する前に、データベースに接続する必要があります。SQL*Plusでは、ローカル接続またはリモート接続が可能です。ローカル接続とは、SQL*Plusを実行しているのと同じコンピュータで動作しているOracle Databaseに接続することです。リモート接続とは、リモート・コンピュータで動作しているOracle Databaseにネットワークを介して接続することです。そのようなデータベースはリモート・データベースと呼ばれます。Oracle Databaseの完全インストール、Oracle ClientのインストールまたはInstant Clientのインストールを行うと、ローカル・コンピュータにSQL*Plus実行可能ファイルが提供されます。

関連項目:
『SQL*Plus ユーザーズ・ガイドおよびリファレンス』

SQL*Plusを使用したデータベースへの接続

Oracle Databaseのコンポーネントは、次のとおりです。

- プロセスとメモリーの集合体であるOracle Databaseインスタンス

- ユーザー・データとシステム・データが格納された一連のディスク・ファイル

SQL*Plusを使用して接続するときには、Oracleインスタンスに接続します。それぞれのインスタンスには、システムID(SID)とも呼ばれるインスタンスIDがあります。ホスト・コンピュータ上に複数のOracleインスタンスが存在し、各インスタンスがそれぞれのデータファイル・セットを持つ可能性があるため、接続先のインスタンスを特定する必要があります。ローカル接続の場合は、オペレーティング・システムの環境変数を設定してインスタンスを識別します。リモート接続では、ネットワーク・アドレスとデータベース・サービス名を指定して、インスタンスを識別します。ローカル接続とリモート接続のいずれの場合も、環境変数を設定して、SQL*Plusの実行可能ファイルをオペレーティング・システムが検出できるようにし、実行可能ファイルにサポート・ファイルとスクリプトへのパスを設定する必要があります。このため、SQL*Plusを使用してOracleインスタンスに接続するには、次の手順を完了する必要があります。

手順1: コマンド・ウィンドウのオープン
手順2: オペレーティング・システムの環境変数の設定
手順3: SQL*Plusの起動
手順4: SQL*PlusのCONNECT文の発行

関連項目:
Oracleインスタンスに関するバックグラウンド情報は、『Oracle Database概要』を参照してください。

手順1: コマンド・ウィンドウのオープン

プラットフォームで必要な処理を実行して、オペレーティング・システムのコマンドを入力できるウィンドウを開きます。

手順2: オペレーティング・システムの環境変数の設定

プラットフォームによっては、SQL*Plusを起動する前に、環境変数を設定するか少なくとも正しく設定されていることを確認することが必要な場合があります。

たとえば、ほとんどのプラットフォームでは、ORACLE_SIDとORACLE_HOMEを設定する必要があります。さらに、PATH環境変数にORACLE_HOME/binディレクトリを含めるように設定することもお薦めします。一部のプラットフォームでは、さらに環境変数の設定が必要な場合があります。

- UNIXおよびLinuxプラットフォームでは、オペレーティング・システムのコマンドを入力して環境変数を設定する必要があります。

- Windowsプラットフォームでは、Windowsレジストリ内のORACLE_HOMEとORACLE_SIDにOracle Universal Installer(OUI)によって値が自動的に割り当てられます。

インストール時にデータベースを作成しなかった場合は、レジストリ内のORACLE_SIDがOUIによって設定されないため、後でデータベースを作成するときに、ORACLE_SID環境変数をコマンド・ウィンドウから設定する必要があります。

UNIXおよびLinuxのインストールには、oraenvとcoraenvの2つのスクリプトが含まれています。このスクリプトを使用すると、これらの環境変数を容易に設定できます。詳細は、管理者リファレンスfor UNIX Systemsを参照してください。

いずれのプラットフォームでも、異なるOracleホームを使用するインスタンス間で切り替える場合は、ORACLE_HOME環境変数を変更する必要があります。同じOracleホームを複数のインスタンスで共有している場合は、インスタンスを切り替えるときにORACLE_SIDのみを変更する必要があります。

環境変数およびインスタンスの切替え方法の詳細は、『Oracle Databaseインストレーション・ガイド』または使用しているオペレーティング・システムの管理ガイドを参照してください。

例1-1 UNIXの環境変数の設定(Cシェル)

setenv ORACLE_SID orcl
setenv ORACLE_HOME /u01/app/oracle/product/11.2.0/db_1
setenv LD_LIBRARY_PATH $ORACLE_HOME/lib:/usr/lib:/usr/dt/lib:/usr/openwin/lib:/usr/ccs/lib

例1-2 Windowsの環境変数の設定

SET ORACLE_SID=orawin2

例1-2では、ORACLE_HOMEおよびORACLE_SIDがレジストリに設定されているが、別のインスタンスに接続するにはORACLE_SIDのレジストリ値を上書きする必要があると仮定しています。

Windowsでは、コマンド・プロンプト・ウィンドウで設定した環境変数値でレジストリの値が上書きされます。

手順3: SQL*Plusの起動

SQL*Plusを起動する手順は、次のとおりです。

1. 次のいずれかを実行します。

- PATH環境変数にORACLE_HOME/binが含まれていることを確認します。

- ORACLE_HOME/binディレクトリに移動します。

2. 次のコマンドを入力します(UNIXとLinuxでは大/小文字が区別されます)。

sqlplus /nolog

手順4: SQL*PlusのCONNECT文の発行

最初にOracleインスタンスに接続するか別のユーザーとして再接続するには、SQL*PlusのCONNECT文を発行します。CONNECT文の構文は、次のとおりです。

CONN[ECT] [logon] [AS {SYSOPER | SYSDBA}]

logonの構文は、次のとおりです。

{username | /}[@connect_identifier] [edition={edition_name | DATABASE_DEFAULT}]

usernameを入力すると、パスワードの入力を求めるプロンプトがSQL*Plusによって表示されます。パスワードは入力しても画面には表示されません。

次の表で、CONNECT文の構文の構成要素を説明します。

構文の構成要素

説明

/

接続要求の外部認証を呼び出します。このタイプの認証では、データベース・パスワードは使用しません。最も一般的な外部認証方式はオペレーティング・システム認証で、この方式では、特定のホスト・ユーザー・アカウントを使用してホスト・オペレーティング・システムにログインすることで、データベース・ユーザーの認証を行います。また、Oracleウォレットまたはネットワーク・サービスを使用して、外部認証を実行することもできます。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。「オペレーティング・システム認証の使用」も参照してください。

AS {SYSOPER | SYSDBA}

SYSOPERまたはSYSDBAのいずれかのシステム権限でデータベース・ユーザーが接続されていることを示します。この権限で接続できるのは、事前定義された特定の管理ユーザーまたはパスワード・ファイルに追加されているユーザーのみです。詳細は、「管理権限」を参照してください。

username

有効なデータベース・ユーザー名。usernameをデータ・ディクショナリと一致させて、ユーザー・パスワードの入力を求めることによって、データベースが接続要求を認証します。

connect_identifier (1)

リモート接続用のOracle Net接続識別子。正確な構文はOracle Netの構成によって異なります。省略すると、SQL*Plusはローカル・インスタンスへの接続を試みます。
一般的な接続識別子はnet service nameです。この識別子は、Oracle Net接続記述子(ネットワーク・アドレスとデータベース・サービス名)の別名です。通常、この別名はローカル・コンピュータのtnsnames.oraファイルで解決されますが、他の方法でも解決できます。

接続識別子の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

connect_identifier (2)

別の方法として、接続識別子で簡易接続の構文も使用できます。簡易接続では、クライアント(ローカル)コンピュータでOracle Net Servicesを設定しなくても、すぐにTCP/IP接続が可能になります。
接続識別子用の簡易接続の構文は次のとおりです(前後の二重引用符も必要です)。

"host[:port][/service_name][:server][/instance_name]"

説明:

- hostは、リモート・データベースがあるコンピュータのホスト名またはIPアドレスです。
IPバージョン4(IPv4)およびIPバージョン6(IPv6)の両方のアドレスに対応しています。IPv6アドレスは大カッコで囲む必要があります。IPv6アドレスの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- portはhostのOracle Netリスナーがデータベース接続をリスニングするTCPポートです。省略すると1521になります。

- service_nameは、接続先のデータベース・サービス名です。リモート・ホスト上のNet Servicesのリスナー構成でデフォルトのサービスが指定されている場合は省略可能です。デフォルトのサービスが構成されていない場合は、service_nameを指定する必要があります。通常、各データベースではグローバル・データベース名と同じ名前の標準サービスが提供され、グローバル・データベース名はDB_NAMEとDB_DOMAIN初期化パラメータで次のように構成されます。

DB_NAME.DB_DOMAIN

DB_DOMAINがNULLの場合は、標準サービス名はDB_NAMEのみです。たとえば、DB_NAMEがorclでDB_DOMAINがus.example.comの場合、標準サービス名はorcl.us.example.comです。

詳細は、「データベース・サービスでのアプリケーション・ワークロードの管理」を参照してください。

- serverはサービス・ハンドラのタイプです。有効な値は、dedicated、sharedおよびpooledです。省略されている場合、サーバーのデフォルトのタイプはリスナーによって選択されます。構成されている場合は共有サーバー、それ以外の場合は専用サーバーです。

- instance_nameは、接続先のインスタンスです。サービス名とインスタンス名の両方を指定することもできますが、通常、このような指定はOracle Real Application Clusters (Oracle RAC)環境でのみ行います。Oracle RAC環境または単一インスタンス環境で、インスタンス名のみを指定した場合は、デフォルトのデータベース・サービスに接続されます。デフォルトのサービスがlistener.oraファイルに構成されていない場合は、エラーが生成されます。インスタンス名はinstance_name初期化パラメータから取得できます。

簡易接続の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

edition={edition_name | DATABASE_DEFAULT}

新規のデータベース・セッションを開始するエディションを指定します。エディションを指定した場合はそのエディションが必ず存在する必要があり、また、エディションに対するUSE権限が必要になります。この句が指定されていない場合は、セッションではデータベースのデフォルトのエディションが使用されます。
エディションおよびエディションに基づく再定義の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

例1-3

次の簡単な例では、ユーザーSYSTEMでローカル・データベースに接続します。SQL*Plusによって、ユーザーSYSTEMのパスワードの入力が求められます。

connect system

例1-4

次の例では、SYSDBA権限のユーザーSYSでローカル・データベースに接続します。SQL*Plusによって、ユーザーSYSのパスワードの入力が求められます。

connect sys as sysdba

ユーザーSYSとして接続するときには、AS SYSDBAを指定して接続する必要があります。

例1-5

次の例では、オペレーティング・システム認証を使用してSYSDBA権限でローカルに接続します。

connect / as sysdba

例1-6

この例では、簡易接続の構文を使用し、ユーザーsalesadminとして、ホストdbhost.example.comで動作するリモート・データベースに接続します。Oracle Netリスナー(リスナー)は、デフォルト・ポート(1521)でリスニングしています。データベース・サービスは、sales.example.comです。SQL*Plusによって、ユーザーsalesadminのパスワードの入力が求められます。

connect salesadmin@"dbhost.example.com/sales.example.com"

例1-7

次の例は、サービス・ハンドラのタイプが指定されていること以外は例1-6と同じです。

connect salesadmin@"dbhost.example.com/sales.example.com:dedicated"

例1-8

次の例は、デフォルト・ポート番号ではない1522でリスナーがリスニングしていること以外は例1-6と同じです。

connect salesadmin@"dbhost.example.com:1522/sales.example.com"

例1-9

この例は例1-6とほぼ同じで、ホスト名のかわりにホストのIPアドレスが使用されている点のみが異なります。

connect salesadmin@"192.0.2.5/sales.example.com"

例1-10

この例では、IPv6アドレスを使用して接続します。角括弧で囲まれている点に注意してください。

connect salesadmin@"[2001:0DB8:0:0::200C:417A]/sales.example.com"

例1-11

次の例では、接続先のインスタンスを指定し、データベース・サービス名を省略します。デフォルトのデータベース・サービスが指定されている必要があり、それ以外の場合はエラーが生成されます。インスタンスのみを指定する場合はサービス・ハンドラのタイプを指定できないことに注意してください。

connect salesadmin@"dbhost.example.com//orcl"

例1-12

次の例では、ユーザーsalesadminとして、ネット・サービス名sales1によって指定されたデータベース・サービスにリモート接続します。SQL*Plusによって、ユーザーsalesadminのパスワードの入力が求められます。

connect salesadmin@sales1

例1-13

次の例では、外部認証を使用して、ネット・サービス名sales1によって指定されたデータベース・サービスにリモート接続します。

connect /@sales1

例1-14

次の例では、外部認証を使用してSYSDBA権限で、ネット・サービス名sales1によって指定されたデータベース・サービスにリモート接続します。

connect /@sales1 as sysdba

例1-15

次の例では、ユーザーsalesadminとして、ネット・サービス名sales1によって指定されたデータベース・サービスにリモート接続します。データベース・セッションは、rev21エディションで開始されます。SQL*Plusによって、ユーザーsalesadminのパスワードの入力が求められます。

connect salesadmin@sales1 edition=rev21

関連項目:

- 「オペレーティング・システム認証の使用」

- データベース・サービスの詳細は、「データベース・サービスでのアプリケーション・ワークロードの管理」を参照してください。

- CONNECT文の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

- ネット・サービス名の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- listener.oraでのデフォルトのサービスの定義方法は、『Oracle Database Net Servicesリファレンス』を参照してください。

Oracle Databaseソフトウェアのリリースの識別

Oracle Databaseは継続的に開発が進められ、メンテナンスが必要なため、定期的に新リリースが作成されています。すべての顧客が、新リリースを最初に利用したり、既存のリリースに対する特定のメンテナンスを必要とするわけではありません。この結果、複数の製品リリースが同時に存在することになります。

特定のリリースを完全に識別するには、5つの番号が必要です。以降の項では、各番号の意味について説明します。

リリース番号の形式

Oracleで使用されているリリースの命名体系を理解するために、Oracle Databaseのリリース番号11.2.0.1.0を例として説明します。

図1-1 Oracle Databaseのリリース番号の例

注意:
リリース9.2からは、Oracle Databaseのメンテナンス・リリースはリリース番号の2番目の数字の変更で示されます。以前のリリースでは、3番目の数字が特定のメンテナンス・リリースを示していました。

データベースのバージョン番号

最初の数字は、最も一般的な識別子です。ソフトウェアの主要な新バージョン(大きな新機能など)を表します。

データベースのメンテナンス・リリース番号

2番目の数字は、メンテナンス・リリース・レベルを表します。新機能がいくつか含まれている場合もあります。

Fusion Middlewareリリース番号

3番目の数字には、Oracle Fusion Middlewareのリリース・レベルが反映されます。

コンポーネント固有のリリース番号

4番目の数字では、コンポーネント固有のリリース・レベルが識別されます。コンポーネントが異なると、ここに表示される数値も異なることがあります。これは、コンポーネントのパッチ・セットや仮リリースなどに基づきます。

プラットフォーム固有のリリース番号

5番目の数字では、プラットフォーム固有のリリースが識別されます。通常、これはパッチ・セットです。異なるプラットフォームに同等のパッチ・セットが必要な場合、この数字は影響を受けるプラットフォーム間で同じになります。

現行のリリース番号のチェック

現在インストールされているOracle Databaseのリリースを識別し、使用している他のデータベース・コンポーネントのリリース・レベルを確認するには、データ・ディクショナリ・ビューPRODUCT_COMPONENT_VERSIONを問い合せます。問合せの例を次に示します。(コンポーネント・レベルの情報は、V$VERSIONビューを問い合せて確認することもできます。)他の製品のリリース・レベルは、データベース・サーバーと関係なく増加する場合があります。

COL PRODUCT FORMAT A40
COL VERSION FORMAT A15
COL STATUS FORMAT A15
SELECT * FROM PRODUCT_COMPONENT_VERSION;

PRODUCT                                  VERSION     STATUS
---------------------------------------- ----------- -----------
NLSRTL                                   11.2.0.0.1  Production
Oracle Database 11g Enterprise Edition   11.2.0.0.1  Production
PL/SQL                                   11.2.0.0.1  Production
...

オラクル社にソフトウェアの問題を報告する際は、この問合せの結果を伝えることが重要です。

データベース管理者のセキュリティと権限の概要

Oracle Database管理者の管理タスクを実行するには、データベースとそのデータベースが稼働するサーバーのオペレーティング・システムで特定の権限が必要です。データベース管理者アカウントへのアクセスは厳しく管理する必要があります。

この項の内容は次のとおりです。

- データベース管理者のオペレーティング・システム・アカウント

- 管理ユーザー・アカウント

データベース管理者のオペレーティング・システム・アカウント

データベースに対する管理業務の多くを実行するには、オペレーティング・システム・コマンドを実行できる必要があります。Oracle Databaseが稼働するオペレーティング・システムによって異なりますが、オペレーティング・システムにアクセスするには、オペレーティング・システム・アカウント(ID)が必要になります。その場合、そのオペレーティング・システム・アカウントに対しては、他のデータベース・ユーザーには不要なオペレーティング・システム権限やアクセス権(Oracle Databaseソフトウェアのインストールの実行など)が必要になります。Oracle Databaseファイルを自分のアカウント内に格納する必要はありませんが、それらに対するアクセス権は必要です。

関連項目:
使用しているオペレーティング・システム固有のOracleマニュアルを参照してください。データベース管理者のアカウントの作成方法は、オペレーティング・システムによって異なります。

管理ユーザー・アカウント

Oracle Databaseのインストール時には、次の2つの管理ユーザー・アカウントが自動的に作成されます。

- SYS(デフォルトのパスワード: CHANGE_ON_INSTALL)

- SYSTEM(デフォルトのパスワード: MANAGER)

注意:
Oracle Universal Installer(OUI)およびDatabase Configuration Assistant(DBCA)では、SYSおよびSYSTEMのパスワードの入力が要求され、それぞれデフォルトのパスワードである"change_on_install"または"manager"は受け入れられません。
データベースを手動で作成する場合は、これらのデフォルト・パスワードを使用しないで、SYSとSYSTEMのパスワードをデータベースの作成時に指定することをお薦めします。詳細は、「データベースの保護: ユーザーSYSおよびSYSTEMのパスワードの指定」を参照してください。

日常的な管理タスクを実施するときに使用する管理者ユーザーを最低1つ追加作成し、そのユーザーに適切な管理ロールを付与してください。これらの目的のためにSYSおよびSYSTEMを使用しないでください。

セキュリティ拡張に関する注意:
このリリースのOracle Databaseと以降のリリースで、デフォルトのデータベース・ユーザー・アカウントのセキュリティを確保するために、セキュリティ機能が拡張されています。このリリースのセキュリティ・チェックリストは、『Oracle Databaseセキュリティ・ガイド』にあります。このチェックリストを参照し、その内容に従ってデータベースを構成してください。

SYS

Oracle Databaseを作成すると、ユーザーSYSが自動的に作成され、DBAロールが付与されます。

データベースのデータ・ディクショナリの実表とビューはすべて、SYSスキーマに格納されます。これらの実表およびベース・ビューはOracle Databaseを操作する際に重要となります。データ・ディクショナリの整合性を保持するには、SYSスキーマ内の表をデータベースのみで操作します。ユーザーやDBAはそれらの表を修正したり、ユーザーSYSのスキーマ内に表を作成しないでください。(ただし、必要に応じてデータ・ディクショナリ設定の記憶域パラメータを変更することは可能です。)

ほとんどのデータベース・ユーザーに対して、SYSアカウントによるOracle Databaseへの接続を禁止する必要があります。

SYSTEM

Oracle Databaseを作成すると、ユーザーSYSTEMも自動的に作成され、DBAロールが付与されます。

このユーザー名SYSTEMを使用して、管理情報を表示する追加表とビュー、および各種のOracle Databaseのオプションとツール製品で使用される内部表とビューが作成されます。管理ユーザー以外のユーザーに関係する表の格納に、SYSTEMスキーマを使用しないでください。

DBAロール

事前に定義されたDBAロールは、Oracle Databaseのインストールで自動的に作成されます。このロールには、ほとんどのデータベース・システム権限が含まれています。このため、DBAロールは実際のDBAにのみ付与してください。

注意:
DBAロールには、SYSDBAまたはSYSOPERシステム権限が含まれていません。これらは、データベースとインスタンスの起動や停止など、基本的なデータベース管理タスクの実行を管理者に許可する特別な管理権限です。これらのシステム権限については、「管理権限」を参照してください。

データベース管理者の認証

DBAは、データベースの起動や停止などの特別な操作を実行します。これらの操作はDBAのみが実行する必要があるため、DBAのユーザー名には安全性の高い認証方式が必要です。

この項の内容は次のとおりです。

- 管理権限

- データベース管理者の認証方式の選択

- オペレーティング・システム認証の使用

- パスワード・ファイル認証の使用

管理権限

管理者が基本的なデータベース操作を実行するために必要な管理権限は、SYSDBAおよびSYSOPERという2つの特別なシステム権限によって付与されます。必要な認可レベルに応じて、どちらか一方の権限をDBAに付与する必要があります。

注意:
SYSDBAおよびSYSOPERは、データベースがオープンでないときもデータベース・インスタンスにアクセスできるシステム権限です。これらの権限の制御は、完全にデータベース機能の範囲外にあります。
SYSDBAとSYSOPER権限も、他の方法では権限を付与できない特定のデータベース操作を実行するための接続の一種とみなすことができます。たとえば、SYSDBA権限がある場合は、CONNECT AS SYSDBAを指定することでデータベースに接続できます。

SYSDBAとSYSOPER

SYSDBAおよびSYSOPERシステム権限で許可されている操作は、次のとおりです。

システム権限

許可されている操作

SYSDBA

- STARTUPおよびSHUTDOWN操作の実行

- ALTER DATABASE: オープン、マウント、バックアップまたはキャラクタ・セットの変更

- CREATE DATABASE

- DROP DATABASE

- CREATE SPFILE

- ALTER DATABASE ARCHIVELOG

- ALTER DATABASE RECOVER

- RESTRICTED SESSION権限を含む

実際は、このシステム権限を使用することにより、ユーザーSYSとして接続できます。

SYSOPER

- STARTUPおよびSHUTDOWN操作の実行

- CREATE SPFILE

- ALTER DATABASE OPEN/MOUNT/BACKUP

- ALTER DATABASE ARCHIVELOG

- ALTER DATABASE RECOVER(完全リカバリのみ。UNTIL TIME|CHANGE|CANCEL|CONTROLFILEなど、不完全リカバリの形式では、SYSDBAで接続する必要があります。)

- RESTRICTED SESSION権限を含む

この権限を使用すると、ユーザー・データの表示を除く基本操作を実行できます。

これらの権限の使用を許可する方法は、使用する認証方式によって異なります。

SYSDBAまたはSYSOPER権限で接続した場合は、一般的にユーザー名に対応付けられているスキーマではなく、デフォルトのスキーマで接続します。このスキーマは、SYSDBAの場合はSYS、SYSOPERの場合は、PUBLICです。

管理権限での接続: 例

この例では、ユーザーがSYSDBAシステム権限で接続したときに、他のスキーマ(SYS)に割り当てられることを説明します。SYSDBAシステム権限が付与されているサンプル・ユーザーoeが、次の文を発行したとします。

CONNECT oe
CREATE TABLE admin_test(name VARCHAR2(20));

後で、ユーザーoeが次の文を発行します。

CONNECT oe AS SYSDBA
SELECT * FROM admin_test;

ユーザーoeは次のエラー・メッセージを受け取ります。

ORA-00942: table or view does not exist

SYSDBAで接続しているため、ユーザーoeは現在SYSスキーマを参照していますが、表はoeスキーマに作成されています。

関連項目:

- 「オペレーティング・システム認証の使用」

- 「パスワード・ファイル認証の使用」

データベース管理者の認証方式の選択

DBAは、他のユーザーと同様に(アカウント・パスワードを使用して)、データ・ディクショナリを介してデータベース管理者を認証できます。Oracle Database 11g リリース1からは、データベース・パスワードは大/小文字が区別されることに注意してください。(SEC_CASE_SENSITIVE_LOGON初期化パラメータをFALSEに設定すると、大/小文字の区別を無効にして、リリース11gより前の動作に戻すことができます。)

通常のデータ・ディクショナリ認証に加えて、SYSDBAまたはSYSOPER権限のあるDBAの認証には、次の方法を使用できます。

- オペレーティング・システム(OS)認証

- パスワード・ファイル

- Oracle Internet Directoryなどのネットワーク・ベースの認証サービスを使用した厳密認証

これらの方式は、データベースが起動していない場合や使用できない場合にデータベース管理者を認証する際に必要になります。(データベースが使用可能な場合にも使用できます。)

ここからは、オペレーティング・システム認証とパスワード・ファイル認証について説明します。ネットワーク・ベースの認証を使用してデータベース管理者を認証する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

注意:

- これらの認証方式は、旧バージョンのOracle Databaseで提供されていたCONNECT INTERNAL構文にかわるものです。CONNECT INTERNALは現在サポートされていません。

- オペレーティング・システム認証は、パスワード・ファイル認証より優先されます。オペレーティング・システム認証の要件を満たしている場合は、パスワード・ファイルを使用している場合でもオペレーティング・システム認証によって認証されます。

データベースと同じシステム上でデータベースをローカルで管理するか、または単一のリモート・クライアントから複数の異なるデータベースを管理するかによって、選択が決まります。図1-2は、データベース管理者用に選択できる認証方式を示しています。

図1-2 データベース管理者の認証方式

リモート・データベース管理の場合は、Oracle Net関連マニュアルを参照して、セキュリティで保護された接続を使用しているかどうかを判断してください。TCP/IPやDECnetなどの最も一般的な接続プロトコルは、セキュリティによって保護されていません。

関連項目:

- ネットワーク・ベースの認証を使用してデータベース管理者を認証する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- 『Oracle Database Net Services管理者ガイド』

セキュリティで保護されていないリモート接続

セキュリティで保護されていない接続で、権限を持つユーザーとしてOracle Databaseに接続するには、パスワード・ファイルによる認証を受ける必要があります。パスワード・ファイル認証を使用すると、SYSDBAまたはSYSOPERシステム権限を付与されたデータベース・ユーザー名を追跡管理するために、パスワード・ファイルが使用されます。この認証方式については、「パスワード・ファイル認証の使用」を参照してください。

ローカル接続およびセキュリティで保護されたリモート接続

ローカル接続またはセキュリティで保護されたリモート接続で、権限を持つユーザーとしてOracle Databaseに接続するには、次の2通りの方法があります。

- データベースにパスワード・ファイルがあり、ユーザーがSYSDBAまたはSYSOPERシステム権限を付与されている場合は、パスワード・ファイルを使用して接続し、認証を受けることができます。

- サーバーでパスワード・ファイルを使用していない場合や、ユーザーにSYSDBAおよびSYSOPER権限が付与されていないためにパスワード・ファイルにアクセスできない場合は、オペレーティング・システム認証を使用できます。ほとんどのオペレーティング・システムでは、データベース管理者の認証には、データベース管理者のオペレーティング・システム・ユーザー名を特別なグループ(通常は、OSDBAというグループ)に配置する必要があります。このグループのユーザーには、SYSDBA権限が付与されます。類似グループのOSOPERは、ユーザーにSYSOPER権限を付与する場合に使用します。

オペレーティング・システム認証の使用

ここでは、オペレーティング・システムを使用した管理者の認証方法について説明します。

OSDBAとOSOPER

2つの特別なオペレーティング・システム・グループのいずれかにメンバーシップがあると、DBAは、データベースのユーザー名とパスワードを使用するかわりに、オペレーティング・システムを経由してデータベースに対する認証を行うことができます。このことはオペレーティング・システム認証と呼ばれます。一般的に、これらのオペレーティング・システム・グループはOSDBAおよびOSOPERと呼ばれます。各グループはデータベースのインストール・プロセスで作成され、特定の名前が割り当てられます。デフォルトの名前は、次の表に示すようにオペレーティング・システムによって異なります。

オペレーティング・システム・グループ

UNIXユーザー・グループ

Windowsユーザー・グループ

OSDBA

dba

ORA_DBA

OSOPER

oper

ORA_OPER

Oracle Universal Installerではデフォルトの名前が使用されますが、この名前は上書きできます。上書きする理由の1つは、同じホスト・コンピュータ上で複数のインスタンスが実行されている場合です。各インスタンスのプリンシパルDBAを異なるユーザーにする場合は、各インスタンスに対して異なるOSDBAグループを作成することによって、各インスタンスのセキュリティを高めることができます。たとえば、同じホスト上の2つのインスタンスについて、1つ目のインスタンスのOSDBAグループの名前をdba1とし、2つ目のインスタンスのOSDBAの名前をdba2にできます。1人目のDBAはdba1のみのメンバーとし、2人目のDBAはdba2のみのメンバーとします。これにより、オペレーティング・システム認証を使用すると、各DBAは割り当てられたインスタンスに対してのみ接続できます。

OSDBAまたはOSOPERグループでのメンバーシップは、データベースへの接続に次のように影響します。

- データベースへの接続時に、OSDBAグループに属するユーザーがAS SYSDBAを指定した場合、そのユーザーは、SYSDBAシステム権限でデータベースに接続します。

- データベースへの接続時に、OSOPERグループに属するユーザーがAS SYSOPERを指定した場合、そのユーザーは、SYSOPERシステム権限でデータベースに接続します。

- これらのオペレーティング・システム・グループに属していないユーザーがSYSDBAまたはSYSOPERとして接続しようとした場合、CONNECTコマンドを発行するとエラーが発生します。

関連項目:
OSDBAおよびOSOPERグループの作成方法の詳細は、使用しているオペレーティング・システム固有のOracleマニュアルを参照してください。

オペレーティング・システム認証を使用するための準備

オペレーティング・システムを使用して管理ユーザーを認証するには、次の手順を実行する必要があります。

1. ユーザーのオペレーティング・システム・アカウントを作成します。

2. オペレーティング・システムで定義されたOSDBAまたはOSOPERグループにアカウントを追加します。

オペレーティング・システム認証を使用した接続

次のどちらかのSQL*Plusコマンドを入力すると、ユーザーが管理ユーザーとして認証され、ローカル・データベースに接続できます。

CONNECT / AS SYSDBA
CONNECT / AS SYSOPER

セキュリティで保護された接続を介したリモート・オペレーティング・システム認証がサポートされているのは、Windowsプラットフォームのみです。リモート・データベースのネット・サービス名を指定する必要があります。

CONNECT /@net_service_name AS SYSDBA
CONNECT /@net_service_name AS SYSOPER

クライアント・コンピュータとデータベース・ホスト・コンピュータの両方がWindowsドメイン上にあることが必要です。

関連項目:

- 「SQL*Plusを使用したデータベースへの接続」

- CONNECTコマンドの構文は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

パスワード・ファイル認証の使用

ここでは、パスワード・ファイル認証を使用した管理ユーザーの認証方法について説明します。

パスワード・ファイル認証を使用するための準備

パスワード・ファイル認証を使用して管理ユーザーを認証するには、次の手順を実行する必要があります。

1. 作成していない場合は、次のようにORAPWDユーティリティを使用してパスワード・ファイルを作成します。

ORAPWD FILE=filename ENTRIES=max_users

詳細は、「パスワード・ファイルの作成とメンテナンス」を参照してください。

注意:

- Oracle Databaseのインストール・プロセスでDatabase Configuration Assistant(DBCA)を起動した場合は、DBCAによってパスワード・ファイルが作成されます。

- Oracle Database 11g リリース1からは、IGNORECASE = Yというコマンドライン引数を組み込まないかぎり、パスワード・ファイル内のパスワードは大/小文字が区別されます。

2. REMOTE_LOGIN_PASSWORDFILE初期化パラメータをEXCLUSIVEに設定します。(この値がデフォルトです。)

注意:
REMOTE_LOGIN_PASSWORDFILEは静的な初期化パラメータであるため、変更するにはデータベースを再起動する必要があります。

3. ユーザーSYS(または管理権限を持つ他のユーザー)としてデータベースに接続します。

4. データベース内にユーザーが存在しない場合は、ユーザーを作成し、パスワードを割り当てます。
Oracle Database 11g リリース1からは、データベース・パスワードは大/小文字が区別されることに注意してください。(SEC_CASE_SENSITIVE_LOGON初期化パラメータをFALSEに設定すると、大/小文字の区別を無効にして、リリース11gより前の動作に戻すことができます。)

5. 次のコマンドを入力して、ユーザーにSYSDBAまたはSYSOPERシステム権限を付与します。

GRANT SYSDBA to oe;

この文を実行すると、パスワード・ファイルにユーザーが追加され、AS SYSDBAとして接続できるようになります。

関連項目:
パスワード・ファイルの作成とメンテナンスの方法は、「パスワード・ファイルの作成とメンテナンス」を参照してください。

パスワード・ファイル認証を使用した接続

SQL*PlusのCONNECTコマンドを使用すると、管理ユーザーが認証され、ローカルまたはリモート・データベースに接続できます。接続時には、ユーザー名とパスワード、およびAS SYSDBAまたはAS SYSOPER句を指定します。Oracle Database 11g リリース1からは、IGNORECASE = Yオプションを指定してパスワード・ファイルを作成しないかぎり、パスワードは大/小文字が区別されます。

たとえば、ユーザーoeはSYSDBA権限を付与されているため、次のコマンドで接続できます。

CONNECT oe AS SYSDBA

しかし、ユーザーoeはSYSOPER権限を付与されていないため、次のコマンドは失敗します。

CONNECT oe AS SYSOPER

注意:
オペレーティング・システム認証は、パスワード・ファイル認証より優先されます。具体的には、ユーザーがそのオペレーティング・システムのOSDBAまたはOSOPERグループのメンバーであるときに、SYSDBAまたはSYSOPERとして接続すると、指定したユーザー名/パスワードにかかわらず、関連付けられている管理権限で接続されます。
ユーザーがOSDBAグループにもOSOPERグループにも属しておらず、パスワード・ファイルにも指定されていない場合、SYSDBAまたはSYSOPERとして接続しようとすると失敗します。

関連項目:

- 「SQL*Plusを使用したデータベースへの接続」

- CONNECTコマンドの構文は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

パスワード・ファイルの作成とメンテナンス

パスワード・ファイル作成ユーティリティORAPWDを使用して、パスワード・ファイルを作成できます。一部のオペレーティング・システムでは、標準インストール時にこのファイルを作成できます。

この項の内容は次のとおりです。

- ORAPWDを使用したパスワードの作成

- パスワード・ファイルの共有と無効化

- パスワード・ファイルへのユーザーの追加

- パスワード・ファイルのメンテナンス

関連項目:

- 「パスワード・ファイル認証の使用」

- 「データベース管理者の認証方式の選択」

ORAPWDを使用したパスワードの作成

ORAPWDコマンドの構文は次のとおりです。

ORAPWD FILE=filename [ENTRIES=numusers] [FORCE={Y|N}] [IGNORECASE={Y|N}]

次の表にコマンドの引数がまとめられています。

引数

説明

FILE

パスワード・ファイルに割り当てる名前。完全なパスを指定する必要があります。ファイル名のみを指定した場合、ファイルはカレント・ディレクトリに書き込まれます。

ENTRIES

(オプション)ファイルに指定できる最大エントリ(ユーザー・アカウント)数。

FORCE

(オプション)yの場合は、既存のパスワード・ファイルが上書きされます。

IGNORECASE

(オプション)yの場合、パスワードは大/小文字が区別されません。

等号(=)文字の前後にスペースは使用できません。

SYSのパスワードの入力を求めるコマンド・プロンプトが表示され、作成されたパスワード・ファイルにそのパスワードが保存されます。

例

次のコマンドを使用すると、orapworclという名前のパスワード・ファイルが作成されます。このパスワード・ファイルでは、30人までの権限を持つユーザーと各ユーザー固有のパスワードを設定できます。

orapwd FILE=orapworcl ENTRIES=30

ORAPWDコマンドライン引数の説明

次の項では、ORAPWDコマンドライン引数について説明します。

FILE

この引数には、作成するパスワード・ファイルの名前を設定します。ファイルにはフルパス名を指定する必要があります。これは必須の引数です。

パスワード・ファイルに必要なファイル名は、オペレーティング・システムによって異なります。一部のオペレーティング・システムでは、パスワード・ファイルを特定の形式で作成して特定のディレクトリに格納する必要があります。また、環境変数を使用してパスワード・ファイルの名前と位置を指定できるオペレーティング・システムもあります。

表1-1は、UNIX、LinuxおよびWindowsプラットフォームにおいてパスワード・ファイルに必要な名前と場所を示しています。その他のプラットフォームについては、プラットフォーム固有のマニュアルを参照してください。

表1-1 UNIX、LinuxおよびWindowsにおけるパスワード・ファイルに必要な名前と場所

プラットフォーム

必要な名前

必要な場所

UNIXとLinux

orapwORACLE_SID

ORACLE_HOME/dbs

Windows

PWDORACLE_SID.ora

ORACLE_HOME\database

たとえば、SIDがorcldwのデータベース・インスタンスの場合、パスワード・ファイルの名前は、Linuxではorapworcldwとなり、WindowsではPWDorcldw.oraとなります。

Oracle Real Application Clusters環境で、環境変数がパスワード・ファイルのパスに設定される必要があるプラットフォームでは、各インスタンスの環境変数は同じパスワード・ファイルを指し示す必要があります。

注意:
パスワード・ファイルやパスワード・ファイルの位置を特定する環境変数の保護は、システムのセキュリティにとって非常に重要です。パスワード・ファイルや環境変数にアクセスできるユーザーは、接続に対するセキュリティを脅かす潜在的な可能性を持っています。

ENTRIES

この引数には、パスワード・ファイルで受け入れるエントリの数を指定します。この数は、データベースにSYSDBAまたはSYSOPERとして接続できるユーザーの数に対応します。ORAPWDユーティリティでは、オペレーティング・システム・ブロックが一杯になるまでパスワード・エントリの割当てが継続されるため、実際にはユーザー数より多くのエントリを入力できます。たとえば、オペレーティング・システムのブロック・サイズが512バイトの場合は、4つのパスワード・エントリが格納されます。そのため、割り当てられたパスワード・エントリの数は常に4の倍数になります。

パスワード・ファイルにユーザーを追加したり、パスワード・ファイルからユーザーを削除したりすると、エントリは再利用されます。REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVEを指定し、ユーザーにSYSDBAおよびSYSOPER権限を付与する場合、この引数は必須です。

注意:
割り当てられたパスワード・エントリ数を超える場合は、新しいパスワード・ファイルを作成する必要があります。この必要が発生しないように、今後必要になると思われるよりも多くのエントリを割り当ててください。

FORCE

この引数をYに設定すると、既存のパスワード・ファイルを上書きできます。同じ名前のパスワード・ファイルがすでに存在している場合に、この引数を省略するかまたはNに設定すると、エラーが返されます。

IGNORECASE

この引数をyに設定すると、パスワードは大/小文字が区別されません。つまり、ログイン時にユーザーが指定するパスワードとパスワード・ファイル内のパスワードを比較するときに、大/小文字は無視されます。

関連項目:
パスワードの大/小文字区別の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

パスワード・ファイルの共有と無効化

初期化パラメータREMOTE_LOGIN_PASSWORDFILEを使用して、パスワード・ファイルが複数のOracle Databaseインスタンス間で共有されるかどうかを制御します。このパラメータを使用して、パスワード・ファイル認証を無効にすることもできます。REMOTE_LOGIN_PASSWORDFILEで認識される値は、次のとおりです。

- NONE: このパラメータをNONEに設定すると、Oracle Databaseはパスワード・ファイルが存在しない場合と同じように動作します。つまり、セキュリティで保護されていない接続では、権限付きの接続は許可されません。

- EXCLUSIVE: (デフォルト) EXCLUSIVEのパスワード・ファイルは、1つのデータベースの1つのインスタンスのみが使用できます。EXCLUSIVEのファイルのみ変更を行うことができます。EXCLUSIVEのパスワード・ファイルを使用すると、ユーザーの追加、変更および削除を行えます。また、ALTER USERコマンドを使用して、SYSのパスワードを変更できます。

- SHARED: SHAREDパスワード・ファイルは、同じサーバーで稼働している複数のデータベース、またはOracle Real Application Clusters(Oracle RAC)データベースの複数のインスタンスで使用できます。SHAREDパスワード・ファイルは変更できません。したがって、SHAREDパスワード・ファイルにはユーザーを追加できません。ユーザーを追加しようとしたり、SYSのパスワードあるいはSYSDBAまたはSYSOPER権限のあるユーザーのパスワードを変更しようとすると、エラーが生成されます。REMOTE_LOGIN_PASSWORDFILEがEXCLUSIVEに設定されている間に、SYSDBAまたはSYSOPERシステム権限を必要とするすべてのユーザーをパスワード・ファイルに追加する必要があります。すべてのユーザーを追加した後で、REMOTE_LOGIN_PASSWORDFILEをSHAREDに変更すると、ファイルを共有できます。
このオプションは、複数のデータベースまたはOracle RACデータベースを管理する場合に役立ちます。

REMOTE_LOGIN_PASSWORDFILEがEXCLUSIVEまたはSHAREDに設定されているときに、パスワード・ファイルが欠落している場合は、REMOTE_LOGIN_PASSWORDFILEをNONEに設定した場合と同じです。

注意:
REMOTE_LOGIN_PASSWORDFILEがSHAREDに設定されている場合、SYSのパスワードは変更できません。パスワードを変更しようとすると、エラー・メッセージが発行されます。

管理者パスワードとデータ・ディクショナリとの同期の維持

REMOTE_LOGIN_PASSWORDFILE初期化パラメータをNONEからEXCLUSIVEまたはSHAREDに変更した場合、または別のSYSパスワードを使用してパスワード・ファイルを再作成した場合、データ・ディクショナリ内のパスワードとSYSユーザーのパスワード・ファイルが同じになるようにする必要があります。

SYSパスワードを同期化するには、ALTER USER文を使用してSYSパスワードを変更します。ALTER USER文により、ディクショナリとパスワード・ファイルのパスワードは更新されて同期化されます。

SYSDBAまたはSYSOPER権限を使用してログインするSYS以外のユーザーのパスワードを同期化するには、次に示すように、ユーザーの権限を取り消して再度付与する必要があります。

1. SYSDBA権限を付与されているすべてのユーザーを特定します。

SELECT USERNAME FROM V$PWFILE_USERS WHERE USERNAME != 'SYS' AND SYSDBA='TRUE';

2. これらのユーザーのSYSDBA権限を取り消して再度付与します。

REVOKE SYSDBA FROM non-SYS-user;
GRANT SYSDBA TO non-SYS-user;

3. SYSOPER権限を付与されているすべてのユーザーを特定します。

SELECT USERNAME FROM V$PWFILE_USERS WHERE USERNAME != 'SYS' AND SYSOPER='TRUE';

4. これらのユーザーのSYSOPER権限を取り消して再度付与します。

REVOKE SYSOPER FROM non-SYS-user;
GRANT SYSOPER TO non-SYS-user;

パスワード・ファイルへのユーザーの追加

ユーザーにSYSDBAまたはSYSOPER権限を付与すると、そのユーザーの名前と権限情報がパスワード・ファイルに追加されます。データベースにEXCLUSIVEパスワード・ファイルがない場合、つまり、初期化パラメータREMOTE_LOGIN_PASSWORDFILEがNONEまたはSHAREDであるか、パスワード・ファイルが欠落している場合は、これらの権限を付与しようとするとエラーが発行されます。

ユーザーがこの2つの権限のうち1つでも持っている間は、そのユーザーの名前がパスワード・ファイルに残っています。これらの権限を両方とも取り消すと、Oracle Databaseによって、そのユーザーはパスワード・ファイルから削除されます。

パスワード・ファイルを作成した新規ユーザーの追加方法

パスワード・ファイルを作成して新規ユーザーを追加するには、次の手順を実行します。

1. 「ORAPWDを使用したパスワードの作成」に記載されている指示に従って、パスワード・ファイルを作成します。

2. REMOTE_LOGIN_PASSWORDFILE初期化パラメータをEXCLUSIVEに設定します。(デフォルト値。)

注意:
REMOTE_LOGIN_PASSWORDFILEは静的な初期化パラメータであるため、変更するにはデータベースを再起動する必要があります。

3. 次の例に示すように、SYSDBA権限で接続し、プロンプトが表示されたらSYSのパスワードを入力します。

CONNECT SYS AS SYSDBA

4. 必要であれば、インスタンスを起動してデータベースを作成します。または、既存のデータベースをマウントしてオープンします。

5. 必要に応じて、ユーザーを登録します。DBA自身、および必要に応じて他のユーザーにSYSDBAまたはSYSOPER権限を付与します。この後の「SYSDBAおよびSYSOPER権限の付与と取消し」を参照してください。

SYSDBAおよびSYSOPER権限の付与と取消し

データベースでEXCLUSIVEパスワード・ファイルを使用している場合は、次の例に示すように、GRANT文を使用して、ユーザーにSYSDBAまたはSYSOPERシステム権限を付与します。

GRANT SYSDBA TO oe;

ユーザーのSYSDBAまたはSYSOPERシステム権限を取り消すには、次のようにREVOKE文を使用します。

REVOKE SYSDBA FROM oe;

SYSDBAとSYSOPERは最も強力なデータベース権限であるため、GRANT文でWITH ADMIN OPTIONは使用しません。つまり、権限受領者が、さらに別のユーザーにSYSDBAまたはSYSOPER権限を付与することはできません。現在SYSDBAとして接続しているユーザーのみが、別のユーザーのSYSDBAまたはSYSOPERシステム権限を付与したり取り消すことができます。ロールはデータベースが起動してから使用できるようになるため、これらの権限はロールには付与できません。SYSDBAおよびSYSOPERデータベース権限と、オペレーティング・システムのロールを混同しないでください。

関連項目:
システム権限の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

パスワード・ファイル・メンバーの表示

SYSDBA、SYSOPER、SYSASMのいずれかのシステム権限を付与されているユーザーを確認するには、V$PWFILE_USERSビューを使用します。このビューで表示される列は、次のとおりです。

列

説明

USERNAME

パスワード・ファイルで認識されるユーザー名。

SYSDBA

この列の値がTRUEの場合、そのユーザーはSYSDBAシステム権限でログインできます。

SYSOPER

この列の値がTRUEの場合、そのユーザーはSYSOPERシステム権限でログインできます。

SYSASM

この列の値がTRUEの場合、そのユーザーはSYSASMシステム権限でログインできます。

注意:
SYSASMは、Oracle Automatic Storage Managementインスタンスにのみ有効です。

パスワード・ファイルのメンテナンス

この項の内容は、次のとおりです。

- パスワード・ファイルがいっぱいになった場合の、パスワード・ファイルのユーザー数の追加

- パスワード・ファイルの削除

パスワード・ファイルのユーザー数の追加

ユーザーにシステム権限SYSDBAまたはSYSOPERを付与しようとしたときに、ファイルが満杯であるためにエラーが出力された場合は、よりサイズの大きいデータベース・パスワード・ファイルを作成し、ユーザーに再度権限を付与する必要があります。

パスワード・ファイルの置換

パスワード・ファイルを置換するには、次の手順を実行します。

1. V$PWFILE_USERSビューを問い合せて、どのユーザーがSYSDBAまたはSYSOPER権限を持っているかを確認します。

2. 既存のパスワード・ファイルを削除します。

3. 「ORAPWDを使用したパスワードの作成」の指示に従って、ORAPWDユーティリティを使用してパスワード・ファイルを新しく作成します。ENTRIESパラメータには、必要と思われる数よりも大きい数を指定してください。

4. 「パスワード・ファイルへのユーザーの追加」の指示に従います。

パスワード・ファイルの削除

ユーザー認証にパスワード・ファイルを使用する必要がなくなったと判断した場合は、パスワード・ファイルを削除して、REMOTE_LOGIN_PASSWORDFILE初期化パラメータを必要に応じてNONEにリセットできます。このファイルを削除した後は、オペレーティング・システムによって認証されたユーザーのみがSYSDBAまたはSYSOPERデータベース管理の操作を実行できます。

データ・ユーティリティ

Oracle Databaseのデータのメンテナンスに役立つOracleユーティリティが用意されています。

SQL*Loader

SQL*Loaderは、Oracle Databaseのデータベース管理者とその他のユーザーの両方が使用します。これは、標準的なオペレーティング・システム・ファイル(テキスト形式やCデータ形式のファイルなど)からデータベース表にデータをロードします。

エクスポート・ユーティリティとインポート・ユーティリティ

データ・ポンプ・ユーティリティを使用すると、データをアーカイブしたり、Oracle Database間でデータを移動できます。また、従来のインポート(IMP)およびエクスポート(EXP)ユーティリティを使用して、以前のリリースとの間でデータをインポートおよびエクスポートできます。

関連項目:
これらのユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

2 Oracle Databaseの作成および構成

この章の内容は、次のとおりです。

- Oracle Databaseの作成の概要

- DBCAを使用したデータベースの作成

- CREATE DATABASE文を使用したデータベースの作成

- CREATE DATABASE文の句の指定

- 初期化パラメータの指定

- サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

- データベース・サービスでのアプリケーション・ワークロードの管理

- データベースを作成した後の考慮点

- CloneDBを使用したデータベースのクローニング

- データベースの削除

- データベースのデータ・ディクショナリ・ビュー

関連項目:

- 基礎となるオペレーティング・システム・ファイルがOracle Databaseサーバーによって自動的に作成および管理されるデータベースの作成方法の詳細は、第17章「Oracle Managed Filesの使用」を参照してください。

- Oracle Real Application Clusters(Oracle RAC)環境でのデータベース作成に関する情報は、使用しているプラットフォーム固有のOracle Real Application Clustersインストレーション・ガイドを参照してください。

Oracle Databaseの作成の概要

この項で説明されているガイドラインの一部を使用してデータベースを計画した後、グラフィカル・ツールまたはSQLコマンドを使用してデータベースを作成できます。通常は、Oracle Databaseソフトウェアのインストール時にデータベースを作成します。ただし、インストール後にもデータベースを作成できます。インストール後にデータベースを作成する理由には、次のものがあります。

- Oracle Universal Installer(OUI)を使用してソフトウェアのみをインストールして、データベースを作成しなかったため。

- 既存のOracle Databaseと同じホスト・コンピュータに別のデータベース(およびデータベース・インスタンス)を作成するため。この場合、この章では、新しいデータベースが既存のデータベースと同じOracleホームを使用すると仮定します。OUIを再度実行すれば、新しいOracleホームにデータベースを作成することもできます。

- データベースのコピー(クローン)を作成するため。

データベースを作成する具体的な方法には、次の方法があります。

- Database Configuration Assistant(DBCA)グラフィカル・ツールを使用。
「DBCAを使用したデータベースの作成」を参照してください。

- CREATE DATABASE SQL文を使用
「CREATE DATABASE文を使用したデータベースの作成」を参照してください。

データベースを作成する前の考慮点

データベースの作成では、いくつかのオペレーティング・システム・ファイルを準備することで、それらのファイルをOracle Databaseとしてまとめて動作できるようにします。データベースは、データファイルの数やアクセスするインスタンスの数にかかわらず、1回のみ作成します。データベースの作成では、既存のデータベース内の情報を消去し、同じ名前と物理構造を持つ新規データベースを作成することもできます。

この項の内容は、次のとおりです。

- データベース作成計画

- 作成の前提条件

データベース作成計画

データベースの作成を準備するには、調査と綿密な計画が必要です。表2-1に、推奨する処理を示します。

表2-1 データベース計画タスク

アクション

追加情報

データベース表と索引を計画し、それらが必要とする領域を見積ります。

第I部「Oracle Databaseの構造と記憶域」

第I部「スキーマ・オブジェクト」

データベースを構成する基礎となるオペレーティング・システム・ファイルのレイアウトを計画します。ファイルを適切に分散すると、ファイル・アクセス時のI/Oが分散されるため、データベースのパフォーマンスを大幅に向上できます。Oracleソフトウェアをインストールしてデータベースを作成するときにI/Oを分散させるには、いくつかの方法があります。たとえば、REDOログ・ファイルを異なるディスクに配置したり、ストライプ化を使用できます。競合が少なくなるようにデータファイルを配置できます。また、データの密度(データ・ブロック当たりの行数)を制御できます。高速リカバリ領域を作成する場合は、データファイルとは異なる記憶デバイスに配置することをお薦めします。

この計画タスクを大幅に簡素化するには、データベース記憶域を構成するオペレーティング・システム・ファイルの作成および管理に、Oracle Managed Filesおよび自動ストレージ管理の使用を検討します。

第17章「Oracle Managed Filesの使用」

『Oracle Automatic Storage Management管理者ガイド』

『Oracle Databaseパフォーマンス・チューニング・ガイド』

『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

該当のOracle Databaseインストレーション・ガイドなど、使用しているオペレーティング・システム固有のOracleマニュアル。

グローバル・データベース名を選択します。ネットワーク構造内のデータベースの名前と位置で構成されます。グローバル・データベース名を作成するには、DB_NAMEとDB_DOMAINの両方の初期化パラメータを設定します。

「グローバル・データベース名の決定」

初期化パラメータ・ファイルに含まれる初期化パラメータについて理解します。特にサーバー・パラメータ・ファイルの概要と操作について理解します。サーバー・パラメータ・ファイルを使用すると、初期化パラメータをサーバー側のディスク・ファイルに永続的に格納して管理できます。

「初期化パラメータと初期化パラメータ・ファイルの概要」

「サーバー・パラメータ・ファイルの概要」

『Oracle Databaseリファレンス』

データベース・キャラクタ・セットを選択します。

データ・ディクショナリ内のデータも含め、すべての文字データは、そのデータベースのキャラクタ・セットに格納されます。データベースの作成時には、データベース・キャラクタ・セットを指定します。

詳細は、「キャラクタ・セットの選択」を参照してください。

『Oracle Databaseグローバリゼーション・サポート・ガイド』

データベースでサポートする必要のあるタイム・ゾーンを検討します。

Oracle Databaseでは、2つのタイム・ゾーン・ファイルのいずれかが、有効なタイム・ゾーンのソースとして使用されます。デフォルトのタイム・ゾーン・ファイルはtimezlrg_11.datです。これには、小さいタイム・ゾーン・ファイルtimezone_11.datより、多くのタイム・ゾーンが含まれています。

「データベースのタイム・ゾーン・ファイルの指定」

データベースの標準ブロック・サイズを選択します。このサイズはデータベースの作成時にDB_BLOCK_SIZE初期化パラメータによって指定しますが、データベースの作成後は変更できません。

標準ブロック・サイズは、SYSTEM表領域およびその他の大部分の表領域で使用されます。また、表領域の作成時に、最大4つの非標準ブロック・サイズを指定できます。

「データベース・ブロック・サイズの指定」

セクター・サイズが4KBのディスク上にオンラインREDOログ・ファイルを格納する場合は、REDOログのブロック・サイズを手動で指定する必要があるかどうかを確認します。

「REDOログ・ファイルのブロック・サイズの計画」

SYSAUX表領域の適切な初期サイズを決定します。

「SYSAUX表領域の概要」

SYSTEM以外のユーザーに対してはデフォルトの表領域を使用し、データベース・オブジェクトがSYSTEM表領域に誤って保存されないようにします。

「デフォルト永続表領域の作成」

UNDOデータを管理するために、UNDO表領域を使用します。

第16章「UNDOの管理」

バックアップおよびリカバリ計画を作成し、データベースを障害から保護します。重要な点として、多重化による制御ファイルの保護、適切なバックアップ・モードの選択、およびオンラインREDOログとアーカイブREDOログの管理があげられます。

第12章「REDOログの管理」

第13章「アーカイブREDOログの管理」

第11章「制御ファイルの管理」

『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

インスタンスの起動と停止、データベースのマウントとオープンの原理およびオプションについて理解します。

第3章「起動と停止」

キャラクタ・セットの選択

データベース・キャラクタ・セットとして、AL32UTF8をお薦めします。AL32UTF8とは、Unicode標準であるUTF-8エンコードに対してOracleで使用している名前です。Unicode標準は、現在世界で使用されている言語のほとんどをサポートする汎用キャラクタ・セットです。Unicode標準を使用することは、データベース処理を含め、すべての多言語テクノロジにおいて不可欠です。

データベースが作成され、本番データが累積された後にデータベース・キャラクタ・セットを変更することは、時間がかかる複雑なプロジェクトになります。そのため、インストール時に適切なキャラクタ・セットを選択することが重要です。データベースに現在多言語データが格納されていなくても、数年内に多言語データを格納する予定がある場合、通常は、データベース・キャラクタ・セットにAL32UTF8を選択することのみが、適切な判断となります。

ただし、UNIX、LinuxおよびMicrosoft Windowsの各プラットフォーム用のOracle Universal Installer (OUI)とDatabase Configuration Assistant (DBCA)で使用されるデフォルトのキャラクタ・セットは、AL32UTF8ではなく、ANSIコード・ページと呼ばれるMicrosoft Windowsキャラクタ・セットです。キャラクタ・セットは、OUIまたはDBCAを起動したオペレーティング・システム・セッションの現在の言語(ロケール)に基づいて選択されます。言語が英語(アメリカ)または西ヨーロッパ言語のいずれかである場合には、デフォルトのキャラクタ・セットはWE8MSWIN1252です。各Microsoft Windows ANSIコード・ページには、1つの言語または限定された言語のグループ(西ヨーロッパ言語のみ、東ヨーロッパ言語のみ、日本語のみなど)のデータのみを格納できます。

クライアント・ワークステーションのプラットフォームとしてMicrosoft Windowsが普及しているため、UNIXおよびLinuxの各プラットフォームで作成されたデータベースの場合にも、Microsoft Windowsのキャラクタ・セットがデフォルトとなっています。Oracle Clientライブラリでは、データベース・キャラクタ・セットと、Windows以外のクライアント・アプリケーションで使用されるキャラクタ・セットとの間で必要なキャラクタ・セット変換が自動的に実行されます。

また、提示されたキャラクタ・セットのリストから、使用する他の任意のキャラクタ・セットを選択することもできます。このオプションは、アプリケーション・ベンダーで必要な特定のキャラクタ・セットを選択したり、データベースに接続しているすべてのクライアントが共通して使用しているキャラクタ・セットを選択するときに使用できます。

AL32UTF8はマルチバイト・キャラクタ・セットであるため、WE8MSWIN1252などのシングルバイト・データベース・キャラクタ・セットに比べると、文字データに対するデータベースでの処理が若干遅くなることがあります。使用する文字がASCIIの対象外である大部分の言語について、その言語のテキストに必要な記憶領域をみると、その言語をサポートしているレガシー・キャラクタ・セットを使用した場合よりもAL32UTF8を使用した場合の方が大きくなります。記憶領域が大きくなるのは、英語以外の文字データに関してのみです。Unicodeでは、汎用性や柔軟性があるために、通常はこうした過剰な負担が生じます。

注意:
バージョン8.1.7以前のOracle Databaseクライアントおよびサーバーとの互換性のために必要であるか、またはアプリケーション・ベンダーから明示的に要求された場合以外は、UTF8という名称のキャラクタ・セットをデータベース・キャラクタ・セットとして使用しないでください。名称は似ていますが、UTF8はUnicodeエンコーディングUTF-8の適切な実装ではありません。UTF-8処理が予期されている場合にUTF8キャラクタ・セットが使用されると、データの消失およびセキュリティの問題が発生する場合があります。このことは、XMLやURLアドレスなどのWeb関連データに特に該当します。

作成の前提条件

新しいデータベースを作成するには、次の前提条件を満たす必要があります。

- 必要なOracleソフトウェアがインストールされていること。これには、オペレーティング・システム固有の各環境変数の設定、およびソフトウェアとデータベース・ファイルのディレクトリ構造の設定が含まれます。

- Oracle Databaseインスタンスを起動するために十分なメモリーが使用可能であること。

- Oracle Databaseを実行するコンピュータ上に、設計したデータベースのための十分なディスク記憶域が使用可能であること。

各前提条件については、オペレーティング・システム固有の『Oracle Databaseインストレーション・ガイド』を参照してください。Oracle Universal Installerを使用すると、表示される手順に従ってインストールでき、環境変数、ディレクトリ構造および認可の設定に関するヘルプが表示されます。

DBCAを使用したデータベースの作成

Database Configuration Assistant(DBCA)はほとんど自動化されており、DBCAが完了するとデータベースが使用可能状態になるので、この方法でデータベースを作成することをお薦めします。選択したインストール・タイプによっては、Oracle Universal Installer(OUI)からDBCAを起動できます。また、Oracle Databaseをインストール後は、スタンドアロン・ツールとして、いつでもDBCAを起動できます。

DBCAは、対話型モードまたは非対話型(サイレント)モードで実行できます。対話型モードには、データベースを作成して構成するためのグラフィカル・インタフェースおよびガイド付きワークフローが用意されています。非対話型(サイレント)モードでは、データベース作成スクリプトを記述できます。DBCAを非対話型(サイレント)モードで実行するには、コマンドライン引数またはレスポンス・ファイル、あるいはその両方を指定します。

対話型DBCAを使用したデータベースの作成

対話型DBCAを使用したデータベースの作成方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

非対話型(サイレント)DBCAを使用したデータベースの作成

非対話型(サイレント)モードのDBCAの使用方法の詳細は、使用しているプラットフォームのインストレーション・ガイドの付録Aを参照してください。

次の例では、DBCAにコマンドライン引数を渡してデータベースを作成しています。

dbca -silent -createDatabase -templateName General_Purpose.dbc
-gdbname ora11g -sid ora11g -responseFile NO_VALUE -characterSet AL32UTF8
-memoryPercentage 30 -emConfiguration LOCAL

Enter SYSTEM user password:
password
Enter SYS user password:
password
Copying database files
1% complete
3% complete
...

完全なサイレント操作が実行されるように、stdoutをファイルにリダイレクトできます。ただし、その場合はコマンドライン引数またはレスポンス・ファイルに管理アカウントのパスワードを入力する必要があります。

DBCAコマンドライン引数の概要のヘルプを表示するには、次のコマンドを入力します。

dbca -help

デフォルトなど、引数の詳細は、配布媒体に同梱されているレスポンス・ファイル・テンプレートを参照してください。このファイルの名前と場所は、使用しているプラットフォームのインストレーション・ガイドの付録Aに記載されています。

CREATE DATABASE文を使用したデータベースの作成

手動でデータベースを作成する場合は、CREATE DATABASE SQL文を使用します。DBCAのかわりにこの文を使用する利点は、スクリプト内からデータベースを作成できることです。

CREATE DATABASE文を使用する場合は、実行可能なデータベースを作成する前に他の処理が必要です。この処理には、データ・ディクショナリ表のビューの作成、標準PL/SQLパッケージのインストールなどがあります。これらの処理には、提供されたスクリプトを実行します。

データベース作成用の既存のスクリプトがある場合は、Oracle Databaseの新機能を利用するために、これらのスクリプトの編集を検討してください。

この項の手順が適用できるのは、単一インスタンスのインストールの場合のみです。Oracle RACデータベースの作成手順の詳細は、使用しているプラットフォーム固有のOracle Real Application Clusters(Oracle RAC)インストレーション・ガイドを参照してください。

注意:
単一インスタンスとは、単一のホスト・コンピュータに存在できるOracleインスタンスが1つのみであるという意味ではありません。実際には、複数のOracleインスタンス(および関連するデータベース)を、単一のホスト・コンピュータで実行できます。単一インスタンスのデータベースとは、1つのOracleインスタンスのみがアクセスするデータベースのことですが、これに対して、Oracle RACデータベースには、複数ノードの複数Oracleインスタンスが同時にアクセスします。Oracle RACの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

CREATE DATABASE文を使用してデータベースを作成するには、次の手順を実行します。次の例では、mynewdbというデータベースを作成します。

手順1: インスタンス識別子(SID)の指定

手順2: 必要な環境変数が設定されていることの確認

手順3: データベース管理者の認証方式の選択

手順4: 初期化パラメータ・ファイルの作成

手順5: (Windowsの場合のみ)インスタンスの作成

手順6: インスタンスへの接続

手順7: サーバー・パラメータ・ファイルの作成

手順8: インスタンスの起動

手順9: CREATE DATABASE文の発行

手順10: 追加の表領域の作成

手順11: スクリプトの実行によるデータ・ディクショナリ・ビューの作成

手順12: (オプション)スクリプトの実行による追加オプションのインストール

手順13: データベースのバックアップ

手順14: (オプション)インスタンスの自動起動の有効化

ヒント:
Oracle Automatic Storage Management (Oracle ASM)を使用してディスク記憶域を管理している場合は、これらの手順を実行する前に、Oracle ASMインスタンスを起動してディスク・グループを構成する必要があります。自動ストレージ管理の詳細は、Oracle Automatic Storage Management管理者ガイドを参照してください。

手順1: インスタンス識別子(SID)の指定

インスタンスに対して一意のOracleシステム識別子(SID)を決定し、コマンド・ウィンドウを開いて、環境変数ORACLE_SIDを設定します。後続の手順では、このコマンド・ウィンドウを使用します。

ORACLE_SIDは、後で作成して同じホスト・コンピュータで同時に実行する他のOracle Databaseインスタンスと区別するために使用されます。ORACLE_SIDでの有効な文字に関する制約はプラットフォーム固有です。一部のプラットフォームでは、SIDの大/小文字が区別されます。

注意:
一般的には、SIDはデータベース名と等しくなるように設定します。データベース名に指定できるのは最大8文字までです。詳細は、『Oracle Databaseリファレンス』のDB_NAME初期化パラメータに関する説明を参照してください。

次のUNIXおよびLinuxオペレーティング・システムの例では、「手順6: インスタンスへの接続」で接続するインスタンスのSIDを設定しています。

- Bourne、Bash、またはKornシェルの場合:

ORACLE_SID=mynewdb
export ORACLE_SID

- Cシェルの場合:

setenv ORACLE_SID mynewdb

次の例では、Windowsオペレーティング・システム用のSIDを設定しています。

set ORACLE_SID=mynewdb

関連項目:
Oracleインスタンスに関するバックグラウンド情報は、『Oracle Database概要』を参照してください。

手順2: 必要な環境変数が設定されていることの確認

プラットフォームによっては、環境変数を設定するか少なくとも正しく設定されていることを確認するまで、(「手順6: インスタンスへの接続」で必要な)SQL*Plusを起動できない場合があります。

たとえば、ほとんどのプラットフォームでは、ORACLE_SIDとORACLE_HOMEを設定する必要があります。さらに、PATH変数にORACLE_HOME/binディレクトリを含めるように設定することもお薦めします。UNIXおよびLinuxプラットフォームでは、これらの環境変数を手動で設定する必要があります。Windowsプラットフォームでは、Windowsレジストリ内のORACLE_HOMEとORACLE_SIDにOUIが値を自動的に割り当てます。インストール時にデータベースを作成しなかった場合は、レジストリ内のORACLE_SIDをOUIが設定しないため、後でデータベースを作成するときにORACLE_SID環境変数を設定する必要があります。

手順3: データベース管理者の認証方式の選択

データベースを作成するには、作成するユーザーが認証を受け、適切なシステム権限が付与されている必要があります。必要な権限を付与された管理者として認証されるには、次の方法があります。

- パスワード・ファイルによる方法

- オペレーティング・システム認証による方法

この手順では、認証方式を決定します。

パスワード・ファイルによる認証方法を使用するには、「パスワード・ファイルの作成とメンテナンス」の説明に従ってパスワード・ファイルを作成します。オペレーティング・システム認証による方法を使用するには、必ずオペレーティング・システムの適切なユーザー・グループのメンバーになっているユーザー・アカウントでホスト・コンピュータにログインします。たとえば、UNIXおよびLinuxプラットフォームでは、通常dbaユーザー・グループを使用します。Windowsプラットフォームでは、Oracleソフトウェアをインストールするユーザーが、必要なユーザー・グループに自動的に配置されます。

関連項目:

- 「データベース管理者のセキュリティと権限の概要」

- パスワード・ファイルとオペレーティング・システム認証の詳細は、「データベース管理者の認証」を参照してください。

手順4: 初期化パラメータ・ファイルの作成

Oracleインスタンスの起動時に、初期化パラメータ・ファイルが読み込まれます。このファイルには、テキスト・エディタで作成して変更できるテキスト・ファイルか、データベースにより作成されて動的に変更されるバイナリ・ファイルを使用できます。バイナリ・ファイル(こちらの使用を推奨)は、サーバー・パラメータ・ファイルと呼ばれます。ここで示す手順では、テキスト形式の初期化パラメータ・ファイルを作成します。後述の手順で、テキスト・ファイルからサーバー・パラメータ・ファイルを作成します。

テキスト形式の初期化パラメータ・ファイルを作成する方法の1つは、「初期化パラメータ・ファイルのサンプル」に記載されているサンプルを編集する方法です。

初期化パラメータのファイルを手動で作成する場合は、少なくとも表2-2に記載されているパラメータが含まれているようにしてください。記載されていない他のすべてのパラメータにはデフォルトの値があります。

表2-2 推奨される最低限の初期化パラメータ

パラメータ名

必須

注意

DB_NAME

はい

データベース識別子。CREATE DATABASE文で使用される値に対応している必要があります。最大で8文字です。

CONTROL_FILES

いいえ

推奨されています。提供されていない場合は、データベース・インスタンスにより初期化パラメータ・ファイルと同じ場所に制御ファイルが作成されます。このパラメータを提供することで制御ファイルを多重化できます。詳細は、「初期制御ファイルの作成」を参照してください。

MEMORY_TARGET

いいえ

インスタンスにより使用されるメモリーの合計容量を設定し、自動メモリー管理を有効にします。このパラメータのかわりに他の初期化パラメータを選択して、メモリーの使用をより詳細に手動で制御することもできます。「メモリーの手動構成」を参照してください。

操作を容易にするために、デフォルトのファイル名を使用して、Oracle Databaseのデフォルトの場所に初期化パラメータ・ファイルを配置します。このようにすることにより、Oracle Databaseが初期化パラメータ・ファイルのデフォルトの場所を自動的に参照するため、データベースの起動時にSTARTUPコマンドのPFILE句を指定する必要がなくなります。

使用しているプラットフォームの初期化パラメータ・ファイルのデフォルトのファイル名や場所など、初期化パラメータおよび初期化パラメータ・ファイルの詳細は、「初期化パラメータと初期化パラメータ・ファイルの概要」を参照してください。

関連項目:

- 「初期化パラメータの指定」

- すべての初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

手順5: (Windowsの場合のみ)インスタンスの作成

Windowsプラットフォームでは、インスタンスが存在しない場合には、インスタンスに接続する前に手動で作成する必要があります。ORADIMコマンドを実行すると、新しいWindowsサービスが作成されて、Oracleインスタンスが作成されます。

インスタンスを作成する手順は、次のとおりです。

- Windowsのコマンド・プロンプトで、次のコマンドを入力します。

oradim -NEW -SID sid -STARTMODE MANUAL -PFILE pfile

sidは対象のSID(mynewdbなど)、pfileはテキスト形式の初期化パラメータ・ファイルへの完全パスです。このコマンドでは、インスタンスは作成されますが起動されません。

注意:
この時点では、-STARTMODE引数をAUTOに設定しないでください。設定すると新しいインスタンスが起動され、まだ存在しないデータベースをマウントしようとします。必要な場合は、手順14でこのパラメータをAUTOに変更できます。

ORADIMコマンドの詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』のOracle Databaseインスタンスの管理にORADIMを使用する方法に関する項を参照してください。

手順6: インスタンスへの接続

SQL*Plusを起動して、SYSDBAシステム権限でOracle Databaseインスタンスに接続します。

- パスワード・ファイルによる認証を使用するには、次のコマンドを入力してプロンプトが表示された後、SYSパスワードを入力します。

$ sqlplus /nolog
SQL> CONNECT SYS AS SYSDBA

- オペレーティング・システム認証を使用するには、次のコマンドを入力します。

$ sqlplus /nolog
SQL> CONNECT / AS SYSDBA

SQL*Plusが次のメッセージを表示します。

Connected to an idle instance.

注意:
SQL*Plusが次のようなメッセージを表示する場合があります。

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

その場合には、インスタンスがすでに起動されています。間違ったインスタンスに接続している可能性があります。EXITコマンドを使用してSQL*Plusを終了し、ORACLE_SIDが正しく設定されていることを確認して、この手順を繰り返してください。

手順7: サーバー・パラメータ・ファイルの作成

サーバー・パラメータ・ファイルを使用すると、ALTER SYSTEMコマンドを使用して初期化パラメータを変更でき、変更内容はデータベースを停止して起動した後も持続します。サーバー・パラメータ・ファイルは、編集済のテキスト形式の初期化ファイルから作成します。

次のSQL*Plusコマンドでは、テキスト形式の初期化パラメータ・ファイル(PFILE)がデフォルトの場所のデフォルトのファイル名で読み込まれ、テキスト形式の初期化パラメータ・ファイルからサーバー・パラメータ・ファイル(SPFILE)が作成されて、SPFILEがデフォルトのSPFILE名でデフォルトの場所に書き込まれます。

CREATE SPFILE FROM PFILE;

デフォルトのファイル名と場所を使用していない場合は、PFILEとSPFILEの両方のファイル名とパスワードを指定することもできます。

ヒント:
サーバー・パラメータ・ファイルを有効にするには、データベースを再起動する必要があります。

注意:
この時点でのサーバー・パラメータ・ファイルの作成はオプションですが、作成することをお薦めします。サーバー・パラメータ・ファイルを作成しないと、インスタンスが起動されるたびにテキスト形式の初期化パラメータ・ファイルが引き続き読み込まれます。
重要: Oracle Managed Filesを使用しており、初期化パラメータ・ファイルにCONTROL_FILESパラメータが指定されていない場合には、CREATE DATABASE文でデータベースの制御ファイルが作成されるときに制御ファイルの場所と名前を保存できるように、この時点でサーバー・パラメータ・ファイルを作成しておく必要があります。詳細は、「データベース作成時のOracle Managed Filesの作成」を参照してください。

関連項目:

- 「サーバー・パラメータ・ファイルを使用した初期化パラメータの管理」

- CREATE SPFILEコマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

手順8: インスタンスの起動

データベースをマウントせずにインスタンスを起動します。通常、この方法で起動するのはデータベースの作成時またはメンテナンス時のみです。STARTUPコマンドで、NOMOUNT句を指定します。この例では、初期化パラメータ・ファイルまたはサーバー・パラメータ・ファイルがデフォルトの場所に配置されているため、PFILE句の指定は不要です。

STARTUP NOMOUNT

この時点で、インスタンス・メモリーが割り当てられて、インスタンスのプロセスが起動されます。データベース自体はまだ存在しません。

関連項目:

- STARTUPコマンドの使用方法は、第3章「起動と停止」を参照してください。

- 「サーバー・パラメータ・ファイルを使用した初期化パラメータの管理」

手順9: CREATE DATABASE文の発行

新しいデータベースを作成するには、CREATE DATABASE文を使用します。

例1

次の文では、データベースmynewdbを作成します。このデータベース名は、初期化パラメータ・ファイルのDB_NAMEパラメータと同じにする必要があります。この例では、次のことを想定しています。

- 初期化パラメータ・ファイルのCONTROL_FILESパラメータには、制御ファイルの数と場所が指定されています。

- ディレクトリ/u01/app/oracle/oradata/mynewdbが存在します。

- ディレクトリ/u01/logs/myおよび/u02/logs/myが存在します。

CREATE DATABASE mynewdb
USER SYS IDENTIFIED BY sys_password
USER SYSTEM IDENTIFIED BY system_password
LOGFILE GROUP 1 ('/u01/logs/my/redo01a.log','/u02/logs/my/redo01b.log') SIZE 100M BLOCKSIZE 512,
GROUP 2 ('/u01/logs/my/redo02a.log','/u02/logs/my/redo02b.log') SIZE 100M BLOCKSIZE 512,
GROUP 3 ('/u01/logs/my/redo03a.log','/u02/logs/my/redo03b.log') SIZE 100M BLOCKSIZE 512
MAXLOGFILES 5
MAXLOGMEMBERS 5
MAXLOGHISTORY 1
MAXDATAFILES 100
CHARACTER SET AL32UTF8
NATIONAL CHARACTER SET AL16UTF16
EXTENT MANAGEMENT LOCAL
DATAFILE '/u01/app/oracle/oradata/mynewdb/system01.dbf' SIZE 325M REUSE
SYSAUX DATAFILE '/u01/app/oracle/oradata/mynewdb/sysaux01.dbf' SIZE 325M REUSE
DEFAULT TABLESPACE users
DATAFILE '/u01/app/oracle/oradata/mynewdb/users01.dbf'
SIZE 500M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
DEFAULT TEMPORARY TABLESPACE tempts1
TEMPFILE '/u01/app/oracle/oradata/mynewdb/temp01.dbf'
SIZE 20M REUSE
UNDO TABLESPACE undotbs
DATAFILE '/u01/app/oracle/oradata/mynewdb/undotbs01.dbf'
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

次の特性を持つデータベースが作成されます。

- データベースにはmynewdbという名前が付けられます。グローバル・データベース名はmynewdb.us.example.comになり、ドメイン部分(us.example.com)は、初期化パラメータ・ファイルから取得されます。「グローバル・データベース名の決定」を参照してください。

- CONTROL_FILES初期化パラメータ(データベース作成前に初期化パラメータ・ファイルに設定)で指定された3つの制御ファイルが作成されます。「初期化パラメータ・ファイルのサンプル」および「制御ファイルの指定」を参照してください。

- ユーザー・アカウントSYSとSYSTEMのパスワードが指定した値に設定されます。リリース11gからは、パスワードの大/小文字が区別されます。SYSおよびSYSTEMのパスワードを指定する2つの句は、このリリースのOracle Databaseではオプションです。ただし、いずれか一方の句を指定した場合は、もう一方の句も指定する必要があります。これらの句の使用方法の詳細は、「データベースの保護: ユーザーSYSおよびSYSTEMのパスワードの指定」を参照してください。

- 新しいデータベースには、LOGFILE句で指定されているように、REDOログ・ファイルのグループが3つあり、各グループには2つのメンバーが含まれます。MAXLOGFILES、MAXLOGMEMBERSおよびMAXLOGHISTORYは、REDOログの制限を定義します。「適切なREDOログ・ファイル数の選択」を参照してください。REDOログのブロック・サイズは、ディスクの物理セクターと同じサイズである512バイトに設定されています。ブロック・サイズを物理セクター・サイズと同じ(デフォルト)にする場合には、BLOCKSIZE句はオプションです。通常のセクター・サイズおよびブロック・サイズは512です。BLOCKSIZEに設定可能な値は512、1024および4096です。新しいディスクでセクター・サイズが4KBの場合には、オプションでBLOCKSIZEを4096に指定します。詳細は、「REDOログ・ファイルのブロック・サイズの計画」を参照してください。

- MAXDATAFILESによって、このデータベースでオープンできるデータファイルの最大数が指定されます。この数は、制御ファイルの初期サイズに影響を及ぼします。

注意:
データベースの作成時に、制限をいくつか設定できます。これらの制限には、オペレーティング・システムの制限によって制限され、その影響を受けるものがあります。たとえば、MAXDATAFILESを設定すると、Oracle Databaseは、初期のデータベースにデータファイルが1つしかなくても、制御ファイルにMAXDATAFILES個のファイル名を格納できるだけの領域を割り当てます。ただし、制御ファイルの最大サイズは制限されており、オペレーティング・システムによって異なるので、CREATE DATABASE文のパラメータをすべて理論的な最大値で設定できるとはかぎりません。
データベース作成時に制限を設定する方法の詳細は、『Oracle Database SQL言語リファレンス』および使用しているオペレーティング・システム固有のOracleマニュアルを参照してください。

- このデータベースにデータを格納する際は、AL32UTF8キャラクタ・セットが使用されます。

- NATIONAL CHARACTER SETとしてAL16UTF16キャラクタ・セットが指定されます。このキャラクタ・セットは、特にNCHAR、NCLOBまたはNVARCHAR2として定義された列にデータを格納する際に使用されます。

- DATAFILE句で指定したとおりに、SYSTEM表領域(オペレーティング・システム・ファイル/u01/app/oracle/oradata/mynewdb/system01.dbfからなる)が作成されます。指定した名前のファイルがすでに存在する場合は上書きされます。

- SYSTEM表領域はローカル管理の表領域として作成されます。「ローカル管理のSYSTEM表領域の作成」を参照してください。

- SYSAUX DATAFILE句で指定したとおりに、SYSAUX表領域(オペレーティング・システム・ファイル/u01/oracle/oradata/mynewdb/sysaux01.dbfからなる)が作成されます。「SYSAUX表領域の概要」を参照してください。

- DEFAULT TABLESPACE句により、指定した名前で、このデータベース用のデフォルト永続表領域が作成されます。

- DEFAULT TEMPORARY TABLESPACE句により、指定した名前で、このデータベース用のデフォルト一時表領域が作成されます。「デフォルト一時表領域の作成」を参照してください。

- UNDO TABLESPACE句によって、UNDO表領域が指定の名前で作成されます。このUNDO表領域には、初期化パラメータ・ファイルでUNDO_MANAGEMENT=AUTOを指定した場合に、このデータベース用のUNDOデータが格納されます。このパラメータを省略すると、デフォルトではAUTOになります。「自動UNDO管理の使用: UNDO表領域の作成」を参照してください。

- このCREATE DATABASE文ではARCHIVELOG句が指定されていないため、初期状態ではREDOログ・ファイルはアーカイブされません。これはデータベース作成時の慣例です。後でALTER DATABASE文を使用して、ARCHIVELOGモードに切り替えることができます。mynewdbのアーカイブに関連する初期化パラメータ・ファイル内の初期化パラメータは、LOG_ARCHIVE_DEST_1およびLOG_ARCHIVE_FORMATです。第13章「アーカイブREDOログの管理」を参照してください。

ヒント:

- CREATE DATABASE文で使用しているディレクトリがすべて存在することを確認します。CREATE DATABASE文ではディレクトリは作成されません。

- Oracle Managed Filesを使用していない場合は、すべてのTABLESPACE句にDATAFILE句またはTEMPFILE句を指定する必要があります。

- データベースの作成に失敗した場合は、アラート・ログを参照すると、失敗の原因とその対処措置を判別できます。「アラート・ログの表示」を参照してください。プロセス番号を含むエラー・メッセージが表示される場合は、そのプロセスのトレース・ファイルを調べます。そのプロセス番号がトレース・ファイル名に含まれているトレース・ファイルを探します。詳細は、「トレース・ファイルの検索」を参照してください。

- CREATE DATABASE文を失敗後に再発行するには、最初にインスタンスを停止してから、前のCREATE DATABASE文で作成されたファイルを削除する必要があります。

例2

この例では、より簡単なCREATE DATABASE文を使用できる、Oracle Managed Filesを使用したデータベースの作成例を示します。Oracle Managed Filesを使用するには、初期化パラメータDB_CREATE_FILE_DESTを設定する必要があります。このパラメータは、データベースで作成されて自動的に名前が付けられる様々なデータベース・ファイル用のベース・ディレクトリを定義します。次の文は、初期化パラメータ・ファイルにこのパラメータを設定する例を示しています。

DB_CREATE_FILE_DEST='/u01/app/oracle/oradata'

Oracle Managed Filesおよび次のCREATE DATABASE文を使用すると、SYSTEM表領域とSYSAUX表領域および文に指定されている追加の表領域がデータベースによって作成され、すべてのデータファイル、制御ファイルおよびREDOログ・ファイルのデフォルト・サイズとプロパティが選択されます。この方法で設定されるこれらのプロパティおよび他のデフォルト・データベース・プロパティは本番環境には適さない場合があるため、生成された設定を調べて必要に応じて変更することをお薦めします。

CREATE DATABASE mynewdb
USER SYS IDENTIFIED BY sys_password
USER SYSTEM IDENTIFIED BY system_password
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE temp
UNDO TABLESPACE undotbs1
DEFAULT TABLESPACE users;

ヒント:
CREATE DATABASE文が失敗する場合で手順7を完了していない場合は、予期しない方法で初期化パラメータが設定されている、このインスタンス用の既存のサーバー・パラメータ・ファイル(SPFILE)がないかを確認します。たとえば、すべての制御ファイルへの完全パスがSPFILEに設定されている場合は、それらの制御ファイルが存在しないと、CREATE DATABASE文が失敗します。不必要なSPFILEを削除した後は、必ずインスタンスを停止して(STARTUP NOMOUNTを指定して)再起動します。詳細は、「サーバー・パラメータ・ファイルを使用した初期化パラメータの管理」を参照してください。

関連項目:

- 「CREATE DATABASE文の句の指定」

- 「データベース作成時のOracle Managed Filesの作成」

- 第17章「Oracle Managed Filesの使用」

- CREATE DATABASE文で指定できる句およびパラメータ値の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

手順10: 追加の表領域の作成

データベースを稼働させるには、アプリケーション・データ用に追加の表領域を作成する必要があります。次のサンプル・スクリプトは、追加の表領域を作成します。

CREATE TABLESPACE apps_tbs LOGGING
DATAFILE '/u01/app/oracle/oradata/mynewdb/apps01.dbf'
SIZE 500M REUSE AUTOEXTEND ON NEXT  1280K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL;
-- create a tablespace for indexes, separate from user tablespace (optional)
CREATE TABLESPACE indx_tbs LOGGING
DATAFILE '/u01/app/oracle/oradata/mynewdb/indx01.dbf'
SIZE 100M REUSE AUTOEXTEND ON NEXT  1280K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL;

表領域の作成方法の詳細は、第14章「表領域の管理」を参照してください。

手順11: スクリプトの実行によるデータ・ディクショナリ・ビューの作成

データ・ディクショナリ・ビュー、シノニムおよびPL/SQLパッケージの作成およびSQL*Plusの適切な稼働に必要なスクリプトを実行します。

SQL*Plusで、SYSDBA管理権限でOracle Databaseインスタンスに接続します。

@?/rdbms/admin/catalog.sql
@?/rdbms/admin/catproc.sql
@?/rdbms/admin/utlrp.sql

SQL*Plusで、SYSTEMユーザーとしてOracle Databaseインスタンスに接続します。

@?/sqlplus/admin/pupbld.sql

アットマーク(@)はSQL*Plusスクリプトを実行するコマンドの省略記述です。疑問符(?)はOracleホーム・ディレクトリを表すSQL*Plusの変数です。次の表に、スクリプトの説明を示します。

スクリプト

説明

CATALOG.SQL

データ・ディクショナリ表のビュー、動的パフォーマンス・ビューおよび多くのビューに対するパブリック・シノニムを作成します。シノニムにPUBLICアクセスを付与します。

CATPROC.SQL

PL/SQLに必要なスクリプトやPL/SQLとともに使用されるスクリプトをすべて実行します。

UTLRP.SQL

パッケージ、プロシージャおよび型も含めて、無効な状態となっているすべてのPL/SQLモジュールを再コンパイルします。

PUPBLD.SQL

SQL*Plusに必要です。SQL*Plusがユーザーのコマンドを使用禁止にできるようにします。

手順12: (オプション)スクリプトの実行による追加オプションのインストール

必要に応じて、他のスクリプトも実行できます。実行するスクリプトは、使用またはインストール対象として選択する機能とオプションによって異なります。使用可能なスクリプトは、『Oracle Databaseリファレンス』を参照してください。

このデータベースとともに稼働する他のOracle製品をインストールする場合は、それらの製品のインストール方法を参照してください。製品によっては、追加のデータ・ディクショナリ表を作成する必要があります。通常は、これらの表を作成して、データベースのデータ・ディクショナリにロードするためのコマンド・ファイルが提供されます。

インストールを計画している製品のインストールと管理の方法は、製品固有のOracleマニュアルを参照してください。

手順13: データベースのバックアップ

メディア障害が発生した場合にリカバリするための完全なファイル・セットが確実に存在するように、データベースの全体バックアップを作成してください。データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

手順14: (オプション)インスタンスの自動起動の有効化

ホスト・コンピュータの再起動時に、Oracleインスタンスが自動的に起動されるように構成する必要がある場合があります。詳細は、オペレーティング・システムのドキュメントを参照してください。たとえばWindowsでは、次のコマンドを使用して、コンピュータの再起動時にデータベース・サービスがインスタンスを起動するように構成します。

ORADIM -EDIT -SID sid -STARTMODE AUTO -SRVCSTART SYSTEM [-SPFILE]

自動再起動時にインスタンスがSPFILEを読み込むようにする場合は、-SPFILE引数を使用する必要があります。

関連項目:

- 第4章「Oracle Databaseの自動再起動の構成」

- ORADIMコマンドの詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』のOracle Databaseインスタンスの管理にORADIMを使用する方法に関する項を参照してください。

CREATE DATABASE文の句の指定

CREATE DATABASE文を実行すると、Oracle Databaseはいくつかの操作を実行します。実際の操作は、CREATE DATABASE文で指定した句、および初期化パラメータの設定に応じて実行されます。Oracle Databaseが最低限実行する操作は、次のとおりです。

- データベース用のデータファイルの作成

- データベース用の制御ファイルの作成

- データベース用のREDOログ・ファイルの作成とARCHIVELOGモードの設定

- SYSTEM表領域の作成

- SYSAUX表領域の作成

- データ・ディクショナリの作成

- データベースへのデータの格納に使用するキャラクタ・セットの設定

- データベース・タイム・ゾーンの設定

- データベースのマウントとオープン

この項では、CREATE DATABASE文の複数の句について説明します。これには、「手順9: CREATE DATABASE文の発行」で説明した句と、その他の句が含まれます。ここで説明するCREATE DATABASE句の多くは、データベースの作成と管理を簡素化するために使用できます。

この項の内容は、次のとおりです。

- データベースの保護: ユーザーSYSおよびSYSTEMのパスワードの指定

- ローカル管理のSYSTEM表領域の作成

- SYSAUX表領域の概要

- 自動UNDO管理の使用: UNDO表領域の作成

- デフォルト一時表領域の作成

- データベース作成時のOracle Managed Filesの作成

- データベース作成時のbigfile表領域のサポート

- データベースのタイム・ゾーンとタイム・ゾーン・ファイルの指定

- FORCE LOGGINGモードの指定

データベースの保護: ユーザーSYSおよびSYSTEMのパスワードの指定

CREATE DATABASE文でユーザーSYSおよびSYSTEMのパスワード指定に使用する句は、次のとおりです。

- USER SYS IDENTIFIED BY password

- USER SYSTEM IDENTIFIED BY password

これらの句を省略すると、これらのユーザーにはそれぞれデフォルトのパスワードchange_on_installおよびmanagerが割り当てられます。デフォルトのパスワードが使用された場合は、そのことを示すレコードがアラート・ログに書き込まれます。データベースを保護するには、データベース作成直後にALTER USER文を使用して、これらのパスワードを変更する必要があります。

これらの句は、このリリースのOracle Databaseではオプションですが、指定することをお薦めします。デフォルトのパスワードは一般に知られており、後で変更するのを怠ると、データベースを悪意のユーザーによる攻撃に対して無防備な状態で放置することになります。

パスワードを選択するときには、リリース11g以降ではパスワードの大/小文字が区別されることに注意してください。また、使用中のデータベースにパスワード形式の要件が設定されている場合もあります。詳細は、『Oracle Databaseセキュリティ・ガイド』のOracle Databaseによるパスワードの複雑度の検証方法に関する項を参照してください。

関連項目:
「セキュリティに関する考慮点」

ローカル管理のSYSTEM表領域の作成

CREATE DATABASE文にEXTENT MANAGEMENT LOCAL句を指定すると、ローカル管理のSYSTEM表領域を作成できます。この文を正常に実行するには、COMPATIBLE初期化パラメータを10.0.0以上に設定する必要があります。EXTENT MANAGEMENT LOCAL句を指定しない場合は、デフォルトでディクショナリ管理のSYSTEM表領域が作成されます。ディクショナリ管理表領域は非推奨です。

ローカル管理のSYSTEM表領域を指定してデータベースを作成する場合にOracle Managed Filesを使用していない場合は、次の条件が満たされているかどうかを確認してください。

- DEFAULT TEMPORARY TABLESPACE句をCREATE DATABASE文に指定

- UNDO TABLESPACE句をCREATE DATABASE文に指定

関連項目:

- SYSTEM表領域に対してEXTENT MANAGEMENT LOCALを指定する場合のDEFAULT TEMPORARY TABLESPACE句およびUNDO TABLESPACE句の使用に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 「ローカル管理表領域」

- 「ローカル管理表領域へのSYSTEM表領域の移行」

SYSAUX表領域の概要

SYSAUX表領域はデータベース作成時に必ず作成されます。SYSAUX表領域は、SYSTEM表領域の予備の表領域として機能します。これは、以前に固有の表領域を必要としていたOracle Databaseの多くの機能と製品に対するデフォルトの表領域であるため、データベースに必要な表領域の数が削減されます。また、SYSTEM表領域の負荷も軽減されます。

SYSAUX表領域に対して指定できるのはデータファイルの属性のみで、CREATE DATABASE文でSYSAUX DATAFILE句を使用して指定します。SYSAUX表領域の必須属性は、Oracle Databaseによって設定され、次のような属性があります。

- PERMANENT

- READ WRITE

- EXTENT MANAGMENT LOCAL

- SEGMENT SPACE MANAGMENT AUTO

これらの属性は、ALTER TABLESPACE文で変更できず、変更しようとするとエラーが発生します。SYSAUX表領域の削除や名前変更はできません。

SYSAUX表領域のサイズは、SYSAUXを使用するデータベース・コンポーネントのサイズにより決定します。V$SYSAUX_OCCUPANTSビューを問い合せることにより、これらのコンポーネントのリストを表示できます。これらのコンポーネントの初期サイズに基づいて、SYSAUX表領域には、データベース作成時に最低限400MB必要です。SYSAUX表領域の領域要件は、データベースが完全にデプロイされた後、その使用状況やワークロードによって増加します。SYSAUX表領域の領域消費を継続的に管理する方法の詳細は、「SYSAUX表領域の管理」を参照してください。

SYSTEM表領域に対してDATAFILE句を指定している場合は、SYSAUX DATAFILE句も指定する必要があり、指定しない場合は、CREATE DATABASE文が失敗します。この要件は、Oracle Managed Files機能が使用可能な場合は適用されません(「データベース作成時のOracle Managed Filesの作成」を参照してください)。

SYSAUX表領域のセキュリティ属性はSYSTEM表領域と同じです。

注意:
このマニュアルでは、データベース作成時のSYSAUXデータベースの作成について説明しています。SYSAUX表領域を必要としないOracle Databaseのリリースからアップグレードするときは、アップグレード・プロセス時にSYSAUX表領域を作成する必要があります。この操作については、『Oracle Databaseアップグレード・ガイド』を参照してください。

関連項目:
「SYSAUX表領域の管理」

自動UNDO管理の使用: UNDO表領域の作成

自動UNDO管理ではUNDO表領域が使用されます。自動UNDO管理を使用可能にするには、初期化パラメータ・ファイルでUNDO_MANAGEMENT初期化パラメータをAUTOに設定します。このパラメータを省略すると、デフォルトでデータベースが自動UNDO管理になります。このモードでは、UNDOデータがUNDO表領域に格納され、Oracle Databaseによって管理されます。UNDO表領域を定義して名前を付けるには、データベース作成時にCREATE DATABASE文にUNDO TABLESPACE句を指定する必要があります。この句を省略して自動UNDO管理を使用可能にすると、SYS_UNDOTBSという名前のデフォルトのUNDO表領域が作成されます。

関連項目:

- 「UNDO領域管理方法の指定」

- UNDO表領域の作成と使用の詳細は、第16章「UNDOの管理」を参照してください。

デフォルト永続表領域の作成

CREATE DATABASE文でDEFAULT TABLESPACE句を指定すると、データベースのデフォルト永続表領域が作成されます。この表領域には、Oracle Databaseによって、別の永続表領域が明示的に指定されていないSYSTEM以外のユーザーが割り当てられます。この句を指定しない場合、SYSTEM以外のユーザーに対するデフォルトの永続表領域はSYSTEM表領域です。デフォルトの永続表領域を作成することをお薦めします。

関連項目:
CREATE DATABASEおよびALTER DATABASEのDEFAULT TABLESPACE句の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

デフォルト一時表領域の作成

CREATE DATABASE文でDEFAULT TEMPORARY TABLESPACE句を指定すると、データベースにデフォルトの一時表領域が作成されます。Oracle Databaseは、この表領域を、一時表領域が明示的に割り当てられていないユーザーに対して一時表領域として割り当てます。

一時表領域または表領域グループは、CREATE USER文で明示的にユーザーに割り当てることができます。ただし、それを行わない場合は、デフォルトの一時表領域がデータベースに指定されていないと、これらのユーザーには一時表領域としてSYSTEM表領域がデフォルトで割り当てられます。一時データをSYSTEM表領域に格納するのはよい方法ではなく、すべてのユーザーに一時表領域を個別に割り当てるのは非効率的です。したがって、CREATE DATABASEのDEFAULT TEMPORARY TABLESPACE句の使用をお薦めします。

注意:
ローカル管理のSYSTEM表領域を指定すると、そのSYSTEM表領域は一時表領域として使用できません。この場合は、デフォルトの一時表領域を作成する必要があります。この動作については、「ローカル管理のSYSTEM表領域の作成」を参照してください。

関連項目:

- CREATE DATABASEおよびALTER DATABASEのDEFAULT TEMPORARY TABLESPACE句の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 一時表領域の作成と使用については、「一時表領域」を参照してください。

- 一時表領域グループの作成と使用については、「複数の一時表領域: 表領域グループの使用」を参照してください。

データベース作成時のOracle Managed Filesの作成

Oracle Managed Files機能を使用すると、CREATE DATABASE文に指定する句とパラメータの数を最小限に抑えることができます。この機能を使用するには、Oracle Databaseによってファイルが作成および管理されるディレクトリまたはOracle Automatic Storage Management(Oracle ASM)ディスク・グループのいずれかを指定します。

初期化パラメータ・ファイルにDB_CREATE_FILE_DEST、DB_CREATE_ONLINE_LOG_DEST_nまたはDB_RECOVERY_FILE_DEST初期化パラメータを設定すると、データベースの基礎となるオペレーティング・システム・ファイルをOracle Databaseで作成および管理できます。指定した初期化パラメータおよびCREATE DATABASE文で指定した句に応じて、次のデータベース構造のオペレーティング・システム・ファイルがOracle Databaseによって自動的に作成および管理されます。

- 表領域とそのデータファイル

- 一時表領域とその一時ファイル

- 制御ファイル

- REDOログ・ファイル

- アーカイブREDOログ・ファイル

- フラッシュバック・ログ

- ブロック・チェンジ・トラッキング・ファイル

- RMANバックアップ

関連項目:
高速リカバリ領域を作成する初期化パラメータの設定方法については、「高速リカバリ領域の指定」を参照してください。

次のCREATE DATABASE文で、Oracle Managed Files機能の動作を示します。必要な初期化パラメータは指定されているとします。

CREATE DATABASE mynewdb
USER SYS IDENTIFIED BY sys_password
USER SYSTEM IDENTIFIED BY system_password
EXTENT MANAGEMENT LOCAL
UNDO TABLESPACE undotbs
DEFAULT TEMPORARY TABLESPACE tempts1
DEFAULT TABLESPACE users;

- SYSTEM表領域はローカル管理の表領域として作成されます。EXTENT MANAGEMENT LOCAL句を指定しないと、SYSTEM表領域はディクショナリ管理の対象として作成されますが、この方法はお薦めしません。

- DATAFILE句が指定されていないため、SYSTEM表領域用のOracle Managed Filesのデータファイルが作成されます。

- LOGFILE句が指定されていないため、Oracleが管理するREDOログ・ファイルのグループが2つ作成されます。

- SYSAUX DATAFILEが指定されていないため、SYSAUX表領域用のOracle Managed Filesのデータファイルが作成されます。

- UNDO TABLESPACE句およびDEFAULT TABLESPACE句にDATAFILE副次句が指定されていないため、これらの各表領域用にOracle Managed Filesのデータファイルが作成されます。

- DEFAULT TEMPORARY TABLESPACE句にTEMPFILE副次句が指定されていないため、Oracle Managed Filesの一時ファイルが作成されます。

- 初期化パラメータ・ファイルにCONTROL_FILES初期化パラメータが指定されていない場合は、Oracle Managed Filesの制御ファイルも作成されます。

- サーバー・パラメータ・ファイル(「サーバー・パラメータ・ファイルを使用した初期化パラメータの管理」を参照)を使用している場合は、適切な初期化パラメータが自動的に設定されます。

関連項目:

- Oracle Managed Files機能と使用方法の詳細は、第17章「Oracle Managed Filesの使用」を参照してください。

- 自動ストレージ管理の詳細は、Oracle Automatic Storage Management管理者ガイドを参照してください。

データベース作成時のbigfile表領域のサポート

Oracle Databaseでは、bigfile表領域を作成できるようにすることで、表領域の管理を簡素化し、大規模なデータベースのサポートを可能にしています。bigfile表領域に含めることができるファイルは1つのみですが、そのファイルには最大40億ブロックまで設定できます。1つのOracle Databaseのデータファイルの最大数は制限されています(通常は64000ファイル)。したがって、bigfile表領域によって、Oracle Databaseの記憶域容量が大幅に増加します。

この項では、bigfile表領域のサポートを可能にするCREATE DATABASE文の句について説明します。

関連項目:
bigfile表領域の詳細は、「bigfile表領域」を参照してください。

デフォルトの表領域タイプの指定

CREATE DATABASE文のSET DEFAULT...TABLESPACE句によって、後続のCREATE TABLESPACE文でこのデータベースに使用される表領域のデフォルト・タイプが決定します。SET DEFAULT BIGFILE TABLESPACEまたはSET DEFAULT SMALLFILE TABLESPACEを指定します。この句を省略すると、デフォルトでは、従来のタイプのOracle Database表領域であるsmallfile表領域が作成されます。smallfile表領域には最大1022ファイルを含めることができ、それぞれ400万ブロックまで設定できます。

bigfile表領域によってデータファイルがユーザーに対して完全に透過的になるため、bigfile表領域を使用するとOracle Managed Filesの機能がさらに強化されます。ALTER TABLESPACE文のSQL構文は、基礎となるデータファイルではなく表領域で操作を実行できるように拡張されています。

表領域のデフォルト・タイプがbigfile表領域であることを指定するには、「データベース作成時のOracle Managed Filesの作成」に示したCREATE DATABASE文を次のように変更します。

CREATE DATABASE mynewdb
USER SYS IDENTIFIED BY sys_password
USER SYSTEM IDENTIFIED BY system_password
SET DEFAULT BIGFILE TABLESPACE
UNDO TABLESPACE undotbs
DEFAULT TEMPORARY TABLESPACE tempts1;

デフォルトの表領域タイプをデータベース作成後に動的に変更するには、ALTER DATABASE文のSET DEFAULT TABLESPACE句を使用します。

ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE;

データベースの現行のデフォルト一時表領域タイプを判断するには、DATABASE_PROPERTIESデータ・ディクショナリ・ビューを次のように問い合せます。

SELECT PROPERTY_VALUE FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME = 'DEFAULT_TBS_TYPE';

デフォルトの表領域タイプの上書き

SYSTEMおよびSYSAUX表領域は、常にデフォルトの表領域タイプで作成されます。ただし、UNDOおよびDEFAULT TEMPORARY表領域のデフォルトの表領域タイプは、CREATE DATABASE操作時に、明示的に上書きできます。

たとえば、次のように指定すると、デフォルトの表領域タイプがsmallfileのデータベースで、bigfileのUNDO表領域を作成できます。

CREATE DATABASE mynewdb
...
BIGFILE UNDO TABLESPACE undotbs
DATAFILE '/u01/oracle/oradata/mynewdb/undotbs01.dbf'
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

次のように指定すると、デフォルトの表領域タイプがbigfileのデータベースで、smallfileのDEFAULT TEMPORARY表領域を作成できます。

CREATE DATABASE mynewdb
SET DEFAULT BIGFILE TABLESPACE
...
SMALLFILE DEFAULT TEMPORARY TABLESPACE tempts1
TEMPFILE '/u01/oracle/oradata/mynewdb/temp01.dbf'
SIZE 20M REUSE
...

データベースのタイム・ゾーンとタイム・ゾーン・ファイルの指定

この項の内容は次のとおりです。

- データベースのタイム・ゾーンの設定

- データベースのタイム・ゾーン・ファイルの概要

- データベースのタイム・ゾーン・ファイルの指定

データベースのタイム・ゾーンの設定

データベースの作成時にデータベースのタイム・ゾーンを設定するには、CREATE DATABASE文でSET TIME_ZONE句を使用します。データベースのタイム・ゾーンを設定しない場合は、デフォルトでホスト・オペレーティング・システムのタイム・ゾーンに設定されます。

セッションのデータベース・タイム・ゾーンを変更するには、ALTER SESSION文でSET TIME_ZONE句を使用します。

関連項目:
データベース・タイム・ゾーンの設定の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

データベースのタイム・ゾーン・ファイルの概要

Oracleホーム・ディレクトリのサブディレクトリには、次の2つのタイム・ゾーン・ファイルがあります。タイム・ゾーン・ファイルには有効なタイム・ゾーン名が含まれています。タイム・ゾーンごとに次の情報も含まれています。

- 協定世界時(UTC)からのオフセット。

- 夏時間への移行時間。

- 標準時間と夏時間の略称。

デフォルトのタイム・ゾーン・ファイルはORACLE_HOME/oracore/zoneinfo/timezlrg_11.datです。タイム・ゾーン数の少ないタイム・ゾーン・ファイルはORACLE_HOME/oracore/zoneinfo/timezone_11.datにあります。

ファイル内で、データベースで使用されているタイム・ゾーン名を表示するには、次の問合せを実行します。

SELECT * FROM V$TIMEZONE_NAMES;

関連項目:
タイム・ゾーン・ファイルの管理および選択の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

データベースのタイム・ゾーン・ファイルの指定

情報を共有しているすべてのデータベースが同じタイム・ゾーン・データファイルを使用する必要があります。

データベース・サーバーでは、定義数が多いタイム・ゾーン・ファイルが常にデフォルトで使用されます。定義数の少ないタイム・ゾーン・ファイルをクライアントで使用し、すべてのデータが定義数の少ないファイルのリージョンのみを参照することがわかっている場合、クライアントのORA_TZFILE環境変数をクライアントのtimezone_version.datファイルのフルパス名に設定できます。ここでversionは、データベース・サーバーによって使用されているタイム・ゾーン・ファイルのバージョンです。

デフォルトの定義数の多いタイム・ゾーン・ファイルをクライアントですでに使用している場合、定義数の少ないタイム・ゾーン・ファイルに変更するのは実用的ではありません。データベースに、定義数の少ないファイルには含まれていないタイム・ゾーンのデータが含まれている可能性があるためです。

FORCE LOGGINGモードの指定

一部のデータ定義言語文(CREATE TABLEなど)では、NOLOGGING句を使用できますが、ある種のデータベース操作ではデータベースREDOログにREDOレコードが生成されません。NOLOGGING句を設定すると、データベース・リカバリ・メカニズム外で容易にリカバリできる操作は高速化されますが、メディア・リカバリとスタンバイ・データベースに悪影響を与える可能性があります。

Oracle Databaseでは、DDL文にNOLOGGINGが指定されていても、REDOレコードを強制的に書き込ませることができます。データベースでは、一時表領域と一時セグメントのREDOレコードは生成されないため、FORCE LOGGINGはオブジェクトに影響を与えません。

関連項目:
NOLOGGINGモードで実行できる操作の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

FORCE LOGGING句の使用

データベースをFORCE LOGGINGモードにするには、CREATE DATABASE文でFORCE LOGGING句を使用します。この句を指定しない場合、データベースはFORCE LOGGINGモードになりません。

データベースの作成後に、ALTER DATABASE文を使用してデータベースをFORCE LOGGINGモードにします。この文は、ロギングなしの直接書込みがすべて完了するまで待機するため、完了までに長時間かかる可能性があります。

次のSQL文を使用すると、FORCE LOGGINGモードを取り消すことができます。

ALTER DATABASE NO FORCE LOGGING;

データベースに対してFORCE LOGGINGを指定するかどうかに関係なく、表領域レベルでFORCE LOGGINGまたはNO FORCE LOGGINGを選択的に指定できます。ただし、FORCE LOGGINGモードがデータベースに対して有効になっている場合、表領域の設定より優先されます。データベースに対して有効になっていない場合、個々の表領域の設定が実行されます。データベース全体をFORCE LOGGINGモードにするか、または個々の表領域をFORCE LOGGINGモードにすることをお薦めしますが、一度に両方の設定を行わないでください。

FORCE LOGGINGモードは、データベースの永続属性です。つまり、データベースが停止され、再起動されても、同じロギング・モードのままです。ただし、制御ファイルを再作成すると、CREATE CONTROL FILE文でFORCE LOGGING句を指定しないかぎり、データベースはFORCE LOGGINGモードで再起動しません。

関連項目:
表領域の作成にFORCE LOGGING句を使用する方法の詳細は、「REDOレコードの書込みの制御」を参照してください。

FORCE LOGGINGモードのパフォーマンスに関する考慮点

FORCE LOGGINGモードは、ある程度のパフォーマンスの低下を伴います。主として完全メディア・リカバリを確実に行うためにFORCE LOGGINGを指定し、アクティブになっているスタンバイ・データベースがない場合は、次の点を考慮する必要があります。

- 発生すると思われるメディア障害の数

- ロギングなしの直接書込みをリカバリできない場合のダメージの重大度

- FORCE LOGGINGモードによるパフォーマンスの低下は許容範囲内かどうか

データベースがNOARCHIVELOGモードで稼働している場合、通常はFORCE LOGGINGモードにする利点はありません。NOARCHIVELOGモードではメディア・リカバリが不可能であるため、FORCE LOGGINGと組み合せて使用する場合は、ほとんど利点がなく、パフォーマンスが低下する可能性があります。

初期化パラメータの指定

ここでは、新しいデータベースを作成する前に追加または編集できるいくつかの基本的な初期化パラメータについて説明します。この章では、次の項目について説明します。

- 初期化パラメータと初期化パラメータ・ファイルの概要

- グローバル・データベース名の決定

- 高速リカバリ領域の指定

- 制御ファイルの指定

- データベース・ブロック・サイズの指定

- 最大プロセス数の指定

- DDLロック・タイムアウトの指定

- UNDO領域管理方法の指定

- COMPATIBLE初期化パラメータの概要

- ライセンスに関するパラメータの設定

関連項目:

- デフォルト設定など、すべての初期化パラメータに関する説明は、『Oracle Databaseリファレンス』を参照してください。

- メモリー管理に関係する初期化パラメータの説明は、第6章「メモリーの管理」を参照してください。

初期化パラメータと初期化パラメータ・ファイルの概要

Oracleインスタンスの起動時に、初期化パラメータ・ファイルから初期化パラメータが読み込まれます。このファイルでは、少なくともDB_NAMEパラメータを指定する必要があります。他のすべてのパラメータにはデフォルトの値があります。

初期化パラメータ・ファイルは、読取り専用のテキスト・ファイル(PFILE)または読取り/書込みのバイナリ・ファイルです。

バイナリ・ファイルはサーバー・パラメータ・ファイルと呼ばれています。サーバー・パラメータ・ファイルを使用すると、ALTER SYSTEMコマンドを使用して初期化パラメータを変更でき、変更内容は停止して起動した後も持続します。また、Oracle Databaseによる自己チューニングの基礎ともなります。このため、サーバー・パラメータ・ファイルを使用することをお薦めします。サーバー・パラメータ・ファイルは、編集済のテキスト形式の初期化ファイルから手動で作成するか、またはデータベースを作成するDatabase Configuration Assistant(DBCA)を使用して自動的に作成できます。

サーバー・パラメータ・ファイルを手動で作成する前に、テキスト形式の初期化パラメータ・ファイルを使用してインスタンスを起動できます。起動時に、Oracleインスタンスは最初にデフォルトの場所でサーバー・パラメータ・ファイルを検索し、見つからない場合は、テキスト形式の初期化パラメータ・ファイルを検索します。また、STARTUPコマンドの引数としてテキスト形式の初期化パラメータ・ファイルを指定すると、既存のサーバー・パラメータ・ファイルを上書きすることもできます。

テキスト形式の初期化パラメータ・ファイルのデフォルトのファイル名と場所は、次の表のとおりです。

プラットフォーム

デフォルト名

デフォルトの場所

UNIXとLinux

initORACLE_SID.ora
たとえば、mynewdbデータベースの初期化パラメータ・ファイル名は次のようになります。

initmynewdb.ora

ORACLE_HOME/dbs

Windows

initORACLE_SID.ora

ORACLE_HOME\database

初めてOracle Databaseを作成する場合は、変更するパラメータ値の数を最小限にとどめておくことをお薦めします。データベースと環境に慣れてから、多数の初期化パラメータをALTER SYSTEM文で動的にチューニングします。テキスト形式の初期化パラメータ・ファイルを使用している場合、現行のインスタンスについてのみ変更できます。これを永続的にするには、初期化パラメータ・ファイル内で手動で更新する必要があり、更新しない場合は、次回データベースを停止して起動すると変更内容が失われます。サーバー・パラメータ・ファイルを使用している場合、ALTER SYSTEM文で行った初期化パラメータ・ファイルの変更内容は、停止して起動した後も持続します。

関連項目:

- DB_NAMEパラメータの詳細は、「グローバル・データベース名の決定」を参照してください。

- 「サーバー・パラメータ・ファイルを使用した初期化パラメータの管理」

- 「初期化パラメータ・ファイルおよび起動の概要」

テキスト形式の初期化パラメータ・ファイル

テキスト形式の初期化パラメータ・ファイル(PFILE)には、次のいずれかの書式の名前/値ペアを含める必要があります。

- 値を1つのみ受け入れるパラメータの場合

parameter_name=value

- 1つ以上の値を受け入れるパラメータの場合(CONTROL_FILESパラメータなど)

parameter_name=(value[,value] ...)

文字列型のパラメータ値は、一重引用符(')で囲む必要があります。ファイル名の大/小文字区別が有効となるのは、ホスト・オペレーティング・システムで有効な場合のみです。

複数の値を受け入れるパラメータの場合、アラート・ログから名前/値ペアを簡単にコピーして貼り付けられるように、複数行でパラメータを繰り返すことができます。この場合、各行には異なる値が含まれます。

control_files='/u01/app/oracle/oradata/orcl/control01.ctl'
control_files='/u01/app/oracle/oradata/orcl/control02.ctl'
control_files='/u01/app/oracle/oradata/orcl/control03.ctl'

複数の値を受け入れないパラメータを繰り返した場合、最後に指定した値のみが有効です。

関連項目:

- テキスト形式の初期化パラメータ・ファイルの内容と構文の詳細は、『Oracle Databaseリファレンス』を参照してください。

- 「アラート・ログ」

初期化パラメータ・ファイルのサンプル

Oracle Databaseには通常、適切な値が設定されたテキスト形式の初期化パラメータのサンプルが用意されています。構成やオプション、およびデータベースのチューニング計画によっては、オラクル社が提供するこれらの初期化パラメータを編集し、他の初期化パラメータを追加することが可能です。

テキスト形式の初期化パラメータ・ファイルのサンプルはinit.oraという名前で、ほとんどのプラットフォームの次の場所にあります。

ORACLE_HOME/dbs

サンプル・ファイルの内容は、次のとおりです。

##############################################################################
# Example INIT.ORA file
#
# This file is provided by Oracle Corporation to help you start by providing
# a starting point to customize your RDBMS installation for your site.
#
# NOTE: The values that are used in this file are only intended to be used
# as a starting point. You may want to adjust/tune those values to your
# specific hardware and needs. You may also consider using Database
# Configuration Assistant tool (DBCA) to create INIT file and to size your
# initial set of tablespaces based on the user input.
###############################################################################

# Change '<ORACLE_BASE>' to point to the oracle base (the one you specify at
# install time)

db_name='ORCL'
memory_target=1G
processes = 150
audit_file_dest='<ORACLE_BASE>/admin/orcl/adump'
audit_trail ='db'
db_block_size=8192
db_domain=''
db_recovery_file_dest='<ORACLE_BASE>/flash_recovery_area'
db_recovery_file_dest_size=2G
diagnostic_dest='<ORACLE_BASE>'
dispatchers='(PROTOCOL=TCP) (SERVICE=ORCLXDB)'
open_cursors=300
remote_login_passwordfile='EXCLUSIVE'
undo_tablespace='UNDOTBS1'
# You may want to ensure that control files are created on separate physical
# devices
control_files = (ora_control1, ora_control2)
compatible ='11.2.0'

グローバル・データベース名の決定

グローバル・データベース名は、ユーザー指定のローカル・データベース名と、ネットワーク構造内でのデータベースの位置で構成されます。データベース名のローカル名コンポーネントはDB_NAME初期化パラメータによって決定し、ネットワーク構造内のドメイン(論理的な位置)はオプションで指定できるDB_DOMAINパラメータによって決定します。これら2つのパラメータの設定を組み合せて、ネットワーク内で一意となるデータベース名を形成する必要があります。

たとえば、test.us.example.comというグローバル・データベース名を持つデータベースを作成するには、新しいパラメータ・ファイルのパラメータを次のように編集します。

DB_NAME = test
DB_DOMAIN = us.example.com

ALTER DATABASE RENAME GLOBAL_NAME文を使用すると、データベースのGLOBAL_NAMEを変更できます。ただし、最初にDB_NAMEおよびDB_DOMAIN初期化パラメータを変更し、制御ファイルを再作成した後に、データベースを停止して再起動する必要があります。制御ファイルの再作成は、ALTER DATABASE BACKUP CONTROLFILE TO TRACEコマンドで簡単に行えます。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

関連項目:
データベース名の別の変更手段であるDBNEWIDユーティリティの使用方法は、『Oracle Databaseユーティリティ』を参照してください。

DB_NAME初期化パラメータ

DB_NAMEには、8文字以内のテキスト文字列を設定する必要があります。DB_NAMEに指定した名前は、データベースの作成時に、データベースのデータファイル、REDOログ・ファイルおよび制御ファイルに記録されます。データベース・インスタンスの起動時に、(パラメータ・ファイル内の)DB_NAMEパラメータの値と制御ファイル内のデータベース名が一致しないと、データベースは起動しません。

DB_DOMAIN初期化パラメータ

DB_DOMAINは、データベースが作成されるネットワーク・ドメインを指定するテキスト文字列です。作成しようとしているデータベースが分散データベース・システムの一部である場合は、データベースを作成する前に、この初期化パラメータに特に注意してください。このパラメータはオプションです。

関連項目:
分散データベースの詳細は、第I部「分散データベースの管理」を参照してください

高速リカバリ領域の指定

高速リカバリ領域とは、Oracle Databaseでバックアップおよびリカバリに関連するファイルを格納および管理できる場所のことです。これは、現在のデータベース・ファイル(データファイル、制御ファイルおよびオンラインREDOログ)の場所であるデータベース領域とは別です。

高速リカバリ領域を指定するには、次の初期化パラメータを使用します。

- DB_RECOVERY_FILE_DEST: 高速リカバリ領域の場所。ディレクトリ、ファイル・システムまたは自動ストレージ管理(Oracle ASM)のディスク・グループです。RAWファイル・システムにはできません。
Oracle Real Application Clusters(Oracle RAC)環境では、この位置はクラスタ・ファイル・システム、Oracle ASMディスク・グループ、またはNFSを介して構成された共有ディレクトリであることが必要です。

- DB_RECOVERY_FILE_DEST_SIZE: 高速リカバリ領域で使用される最大総バイト数を指定します。この初期化パラメータは、DB_RECOVERY_FILE_DESTを使用可能にする前に指定する必要があります。

Oracle RAC環境では、これら2つのパラメータの設定がすべてのインスタンスで同じであることが必要です。

これらのパラメータは、LOG_ARCHIVE_DESTおよびLOG_ARCHIVE_DUPLEX_DESTパラメータの値を設定している場合は使用可能にできません。高速リカバリ領域を設定する前に、これらのパラメータを使用禁止にする必要があります。かわりに、LOG_ARCHIVE_DEST_nパラメータの値を設定できます。ローカルのアーカイブ先が設定されておらず、LOG_ARCHIVE_DEST_1の値が設定されていない場合は、LOG_ARCHIVE_DEST_1パラメータは、高速リカバリ領域を指し示すように暗黙的に設定されます。

高速リカバリ領域によってデータベースのバックアップ操作およびリカバリ操作が簡素化されるため、この領域を使用することをお薦めします。

関連項目:
高速リカバリ領域の作成方法と使用方法については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

制御ファイルの指定

CONTROL_FILES初期化パラメータでは、データベースに対して1つ以上の制御ファイル名を指定します。CREATE DATABASE文を実行すると、CONTROL_FILESパラメータに記述した制御ファイルが作成されます。

初期化パラメータ・ファイルにCONTROL_FILESを指定しないと、オペレーティング・システム固有のデフォルト・ファイル名を使用して、初期化パラメータ・ファイルと同じディレクトリにOracle Databaseが制御ファイルを作成します。Oracle Managed Filesが使用可能な場合は、Oracle Managed Filesの制御ファイルが作成されます。

データベース用の制御ファイルを作成するときに新しいオペレーティング・システム・ファイルを作成する場合は、CONTROL_FILESパラメータに記述されているファイル名が現在のシステム上に存在するいずれのファイル名とも一致しないことを確認してください。データベース用の制御ファイルを作成するときに既存のファイルを再利用または上書きする場合は、CONTROL_FILESパラメータに記述されているファイル名が、現在のシステム上に存在するファイル名と一致することを確認し、CREATE DATABASE文にCONTROLFILE REUSE句を指定します。

データベースごとに、少なくとも2つの制御ファイルを別々の物理ディスク・ドライブに格納して使用することをお薦めします。

関連項目:

- 第11章「制御ファイルの管理」

- 「データベース作成時のOracle Managed Filesの作成」

データベース・ブロック・サイズの指定

DB_BLOCK_SIZE初期化パラメータは、データベースの標準ブロック・サイズを指定します。このブロック・サイズはSYSTEM表領域に使用され、その他の表領域ではデフォルトで使用されます。Oracle Databaseは、最大4つの非標準ブロック・サイズをサポートします。

DB_BLOCK_SIZE初期化パラメータ

標準ブロック・サイズには、最も一般的に使用するブロック・サイズを選択します。多くの場合、設定が必要なブロック・サイズはこれのみです。通常、DB_BLOCK_SIZEは4Kまたは8Kに設定します。このパラメータの値を指定しないと、オペレーティング・システム固有のデフォルト・データ・ブロック・サイズが使用されますが、大抵の場合、このデフォルト・ブロック・サイズで十分です。

データベースの作成後は、データベースを再作成する以外にブロック・サイズを変更する方法はありません。データベースのブロック・サイズがオペレーティング・システムのブロック・サイズと異なる場合は、データベースのブロック・サイズがオペレーティング・システムのブロック・サイズの倍数であることを確認してください。たとえば、使用しているオペレーティング・システムのブロック・サイズが2KB(2048バイト)の場合、次のDB_BLOCK_SIZE初期化パラメータの設定は有効です。

DB_BLOCK_SIZE=4096

データ・ブロック・サイズを大きくすると、ディスクとメモリーのI/O(データのアクセスと格納)の効率が向上します。したがって、次の条件に該当する場合は、オペレーティング・システムのブロック・サイズより大きいブロック・サイズの指定を考慮してください。

- Oracle Databaseが大容量メモリーと高速ディスク・ドライブを装備した大型コンピュータ・システム上にある場合。たとえば、莫大なハードウェア資源を有するメインフレーム・コンピュータによって制御されるデータベースは、通常4KB以上のデータ・ブロック・サイズを使用します。

- Oracle Databaseが動作するオペレーティング・システムのブロック・サイズが小さい場合。たとえば、オペレーティング・システムのブロック・サイズが1KBで、この値がデフォルトのデータ・ブロック・サイズと一致する場合、データベースは通常の処理で過度のディスクI/Oを実行している可能性があります。この場合にパフォーマンスを最高にするには、データベース・ブロックを複数のオペレーティング・システム・ブロックから構成する必要があります。

関連項目:
デフォルトのブロック・サイズの詳細は、オペレーティング・システム固有のOracleマニュアルを参照してください。

非標準ブロック・サイズ

CREATE TABLESPACE文でBLOCKSIZE句を指定すると、非標準のブロック・サイズを持つ表領域を作成できます。これらの非標準ブロック・サイズには、2の累乗である2KB、4KB、8KB、16KB、32KBのいずれかを指定します。最大ブロック・サイズに関するプラットフォーム固有の制限が適用されるので、プラットフォームによっては、これらのサイズの一部は指定できない場合があります。

非標準ブロック・サイズを使用する場合は、使用するすべての非標準ブロック・サイズについて、SGAメモリーのバッファ・キャッシュ領域内にサブキャッシュを構成する必要があります。これらのサブキャッシュの構成に使用する初期化パラメータについては、「自動共有メモリー管理の使用」を参照してください。

データベースに複数のブロック・サイズを指定できる機能は、特にデータベース間で表領域をトランスポートする場合に役立ちます。たとえば、OLTP環境から、8KBの標準ブロック・サイズを使用するデータ・ウェアハウス環境に、4KBのブロック・サイズを使用する表領域をトランスポートできます。

注意:
32KBのブロック・サイズは、64ビットのプラットフォームでのみ有効です。

注意:
セクター・サイズが4KBのディスクを使用している場合、パフォーマンスが低下する可能性があるため、2KBのブロック・サイズを指定することはお薦めしません。詳細は、「REDOログ・ファイルのブロック・サイズの計画」を参照してください。

関連項目:

- 「表領域の作成」

- 「データベース間での表領域のトランスポート」

最大プロセス数の指定

Oracle Databaseに同時に接続できるオペレーティング・システム・プロセスの最大数は、PROCESSES初期化パラメータによって決定します。このパラメータの値は、最低でも各バックグラウンド・プロセスごとに1つ、および各ユーザー・プロセスごとに1つです。バックグラウンド・プロセスの数は、使用しているデータベースの機能によって異なります。たとえば、アドバンスト・キューイングまたはファイル・マッピング機能を使用している場合は、追加のバックグラウンド・プロセスが必要です。自動ストレージ管理を使用している場合は、データベース・インスタンス用に追加プロセスを3つ追加します。

50のユーザー・プロセスを実行する予定の場合は、PROCESSES初期化パラメータの値を70に見積もって設定することをお薦めします。

DDLロック・タイムアウトの指定

データ定義言語(DDL)文は非ブロッキングまたはブロッキングのいずれかで、どちらのタイプのDDL文にも内部構造の排他ロックが必要です。DDL文の実行時にこのようなロックが使用できない場合、非ブロッキングDDL文とブロッキングDDL文の動作は異なります。

- 非ブロッキングDDLは、DDLの影響を受けるオブジェクトを参照している同時DMLトランザクションがすべてコミットするかロール・バックするまで待機します。

- ブロッキングDDLは、ロックが使用できるようになった直後に実行していれば成功するような場合でも失敗します。

ブロッキングDDL文でロックを待機できるようにするには、DDLロック・タイムアウトを指定します。これは、DDLコマンドが必要なロックを待機する秒数であり、この秒数を超えるとDDL文は失敗します。

DDLロック・タイムアウトを指定するには、DDL_LOCK_TIMEOUTパラメータを使用します。設定可能なDDL_LOCK_TIMEOUTの値の範囲は、0から1,000,000です。デフォルトは0です。DDL_LOCK_TIMEOUTは、ALTER SESSION文を使用して、システム・レベルまたはセッション・レベルで設定できます。

注意:
DDL_LOCK_TIMOUTパラメータは、非ブロッキングDDL文に作用しません。

関連項目:

- 『Oracle Databaseリファレンス』

- 『Oracle Database SQL言語リファレンス』

UNDO領域管理方法の指定

すべてのOracle Databaseには、データベースの変更を取り消すために使用する情報の管理方法が必要です。これらの情報は、主にコミットされる前のトランザクションの処理レコードから構成されます。これらのレコードを総称してUNDOデータと呼びます。この項では、UNDO表領域を使用する自動UNDO管理用の環境を設定する方法について説明します。

関連項目:
第16章「UNDOの管理」

UNDO_MANAGEMENT初期化パラメータ

UNDO_MANAGEMENT初期化パラメータでは、インスタンスを自動UNDO管理モード(UNDOがUNDO表領域に格納されます)で起動するかどうかを指定します。自動UNDO管理モードを使用可能にするには、このパラメータをAUTOに設定します。リリース11gからは、パラメータを省略するかNULLにすると、デフォルトでAUTOになります。

UNDO_TABLESPACE初期化パラメータ

インスタンスを自動UNDO管理モードで起動すると、そのインスタンスは、UNDOデータを格納するためのUNDO表領域を選択しようとします。自動UNDO管理モードでデータベースが作成されている場合は、デフォルトのUNDO表領域(システム生成のSYS_UNDOTBS表領域またはユーザー指定のUNDO表領域)が、インスタンス起動時に使用されるUNDO表領域となります。インスタンスに対するこのデフォルトは、UNDO_TABLESPACE初期化パラメータに値を指定することで上書きできます。このパラメータは特に、Oracle Real Application Clusters環境のインスタンスに特定のUNDO表領域を割り当てる際に役立ちます。

UNDO表領域がUNDO_TABLESPACE初期化パラメータによって指定されていない場合は、データベース内で最初に使用可能なUNDO表領域が選択されます。使用可能なUNDO表領域がない場合、インスタンスはUNDO表領域のない状態で起動し、UNDOデータはSYSTEM表領域に書き込まれます。このモードでは実行しないようにしてください。

注意:
CREATE DATABASE文を使用してデータベースを作成するときには、UNDO_TABLESPACEパラメータを初期化パラメータ・ファイルに指定しないでください。かわりに、UNDO TABLESPACE句をCREATE DATABASE文に指定します。

COMPATIBLE初期化パラメータの概要

COMPATIBLE初期化パラメータによって、ディスクのファイル形式に影響を与える機能の使用をデータベースで使用可能または使用不可にできます。たとえば、Oracle Database 11g リリース2(11.2)データベースを作成しても、初期化パラメータ・ファイルにCOMPATIBLE=10.0.0を指定すると、11.2との互換性が必要な機能の使用を試行した場合にエラーが生成されます。これは、データベースが10.0.0互換性レベルにあるとみなされているためです。

COMPATIBLE初期化パラメータを変更することによって、データベースの互換性レベルを上げることができます。このようにすると、設定した互換性レベルよりも低いレベルではデータベースを起動できなくなりますが、互換性を上げる前の時点にPoint-in-Timeリカバリを実行することはできます。

COMPATIBLEパラメータのデフォルト値は、主要な最新リリースの番号です。

注意:

- Oracle Database 11g リリース2(11.2)では、COMPATIBLEパラメータのデフォルト値は11.2.0.0.0です。最小値は10.0.0です。デフォルト値を使用してOracle Databaseを作成すると、このリリースのすべての新機能をすぐに使用できますが、データベースはダウングレードできなくなります。

- このパラメータをALTER SYSTEM文を使用してサーバー・パラメータ・ファイル(SPFILE)に設定する場合、SCOPE=SPFILEを指定し、データベースを再起動して変更を有効にする必要があります。

関連項目:

- データベースの互換性とCOMPATIBLE初期化パラメータの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

- 『Oracle Databaseリファレンス』

- データベースのPoint-in-Timeリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

ライセンスに関するパラメータの設定

注意:
Oracleでは、同時セッションの数によるライセンス提供がなくなりました。したがって、LICENSE_MAX_SESSIONSおよびLICENSE_SESSIONS_WARNING初期化パラメータは不要のため、非推奨になりました。

指名ユーザー・ライセンスを使用している場合、Oracle Databaseではこの形式のライセンスを施行できます。データベース内に作成するユーザーの数に対して、制限を設定できます。この制限に達すると、それ以上のユーザーは作成できません。

注意:
このメカニズムでは、データベースにアクセスする人がそれぞれ一意のユーザー名を持ち、ユーザー名を共有していないものと想定しています。したがって、指名ユーザー・ライセンスによってOracleのライセンス契約に従っていることを保証できるように、複数のユーザーが同じ名前を使用してログインすることを許可しないでください。

データベースに作成するユーザー数を制限するには、次の例に示すように、そのデータベースの初期化パラメータ・ファイルにLICENSE_MAX_USERS初期化パラメータを設定します。

LICENSE_MAX_USERS = 200

サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

Oracle Databaseの初期化パラメータは、テキスト形式の初期化パラメータ・ファイルに格納されていました。管理性を向上させるために、データベースを起動および停止している間も持続するバイナリ形式のサーバー・パラメータ・ファイルによる初期化パラメータのメンテナンスを選択できます。ここでは、サーバー・パラメータ・ファイルの概要を示し、各パラメータ格納方式を使用した初期化パラメータの管理方法について説明します。この項の内容は、次のとおりです。

- サーバー・パラメータ・ファイルの概要

- サーバー・パラメータ・ファイルへの移行

- サーバー・パラメータ・ファイルの作成

- SPFILE初期化パラメータ

- 初期化パラメータ値の変更

- 初期化パラメータ値のクリア

- サーバー・パラメータ・ファイルのエクスポート

- サーバー・パラメータ・ファイルのバックアップの作成

- 失われたまたは破損したサーバー・パラメータ・ファイルのリカバリ

- パラメータ設定の表示

サーバー・パラメータ・ファイルの概要

サーバー・パラメータ・ファイルは、Oracle Databaseサーバーが稼働するシステムで管理される初期化パラメータのリポジトリと考えられます。これは、サーバー側の初期化パラメータ・ファイルとして設計されています。サーバー・パラメータ・ファイルに格納された初期化パラメータは持続性があり、インスタンスの実行中に加えられたパラメータへの変更はインスタンスの停止から起動までの間も持続します。この配置によって、ALTER SYSTEM文による変更を持続させるために、初期化パラメータを手動で更新する必要がなくなります。また、Oracle Databaseサーバーによる自己チューニングの基礎ともなります。

最初のサーバー・パラメータ・ファイルは、CREATE SPFILE文を使用して、テキスト形式の初期化パラメータ・ファイルから作成します。(Database Configuration Assistantで直接作成することもできます。)サーバー・パラメータ・ファイルは、テキスト・エディタで編集できないバイナリ・ファイルです。Oracle Databaseには、サーバー・パラメータ・ファイル内のパラメータの設定を表示および変更するために、他のインタフェースが用意されています。

注意:
テキスト・エディタでバイナリ形式のサーバー・パラメータ・ファイルをオープンし、そのテキストを表示することは可能ですが、手動で編集しないでください。手動で編集すると、ファイルが破損します。また、インスタンスが起動できなくなり、たとえインスタンスが起動しても失敗します。

PFILE句を指定せずにSTARTUPコマンドを発行すると、Oracleインスタンスは、オペレーティング・システム固有のデフォルトの位置でサーバー・パラメータ・ファイルを検索し、そのファイルから初期化パラメータの設定を読み込みます。サーバー・パラメータ・ファイルが見つからない場合は、テキスト形式の初期化パラメータ・ファイルを検索します。サーバー・パラメータ・ファイルがあってもテキスト形式の初期化パラメータ・ファイルの設定を優先する場合は、STARTUPコマンドの発行時にPFILE句を指定する必要があります。サーバー・パラメータ・ファイルを使用してインスタンスを起動する方法の詳細は、「データベースの起動」を参照してください。

サーバー・パラメータ・ファイルへの移行

現在、テキスト形式の初期化パラメータ・ファイルを使用している場合は、次の手順に従ってサーバー・パラメータ・ファイルに移行します。

1. 初期化パラメータ・ファイルがクライアント・システム上にある場合は、FTPなどを使用して、クライアント・システムからサーバー・システムにファイルを転送してください。

注意:
Oracle Real Application Clusters環境でサーバー・パラメータ・ファイルに移行する場合は、インスタンス固有のすべての初期化パラメータ・ファイルを、1つの初期化パラメータ・ファイルに結合する必要があります。この操作の方法、およびOracle Real Application Clustersのインストールの一部であるインスタンスでサーバー・パラメータ・ファイルを使用する際の固有の処理については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』および使用しているプラットフォーム固有のOracle Real Application Clustersインストレーション・ガイドを参照してください。

2. CREATE SPFILE FROM PFILE文を使用して、デフォルト位置にサーバー・パラメータ・ファイルを作成します。詳細は、「サーバー・パラメータ・ファイルの作成」 を参照してください。
この文を実行すると、テキスト形式の初期化パラメータ・ファイルが読み込まれて、サーバー・パラメータ・ファイルが作成されます。CREATE SPFILE文を発行するために、データベースを起動する必要はありません。

3. インスタンスを起動または再起動します。
インスタンスはデフォルト位置にある新規SPFILEを検出し、そのファイルを使用して起動します。

サーバー・パラメータ・ファイルの作成

サーバー・パラメータ・ファイルを作成するには、CREATE SPFILE文を使用します。この文を実行するには、SYSDBAまたはSYSOPERシステム権限が必要です。

注意:
Database Configuration Assistantを使用してデータベースを作成した場合は、サーバー・パラメータ・ファイルが自動的に作成されます。

CREATE SPFILE文は、インスタンスの起動前後に実行できます。ただし、すでにサーバー・パラメータ・ファイルを使用してインスタンスを起動している場合に、インスタンスで現在使用されているのと同じサーバー・パラメータ・ファイルを再作成しようとすると、エラーが発生します。

サーバー・パラメータ・ファイル(SPFILE)は、既存のテキスト形式の初期化パラメータ・ファイルまたはメモリーから作成できます。メモリーからのSPFILEの作成では、実行中のインスタンス内の初期化パラメータの現行値をSPFILEにコピーします。

次の例では、テキスト形式の初期化パラメータ・ファイル/u01/oracle/dbs/init.oraからサーバー・パラメータ・ファイルを作成しています。この例ではSPFILEの名前を指定していないため、ファイルは、表2-3に示したプラットフォーム固有のデフォルトの名前と場所で作成されます。

CREATE SPFILE FROM PFILE='/u01/oracle/dbs/init.ora';

次の例では、名前と場所を指定してサーバー・パラメータ・ファイルを作成しています。

CREATE SPFILE='/u01/oracle/dbs/test_spfile.ora'
FROM PFILE='/u01/oracle/dbs/test_init.ora';

次の例では、メモリー内の初期化パラメータの現行値から、デフォルトの場所にサーバー・パラメータ・ファイルを作成しています。

CREATE SPFILE FROM MEMORY;

デフォルトのSPFILE名と場所を使用するか、SPFILE名と場所を指定するかどうかに関係なく、同じ名前のSPFILEがその場所にすでに存在する場合は、警告メッセージなしに上書きされます。

テキスト形式の初期化パラメータ・ファイルからSPFILEを作成すると、初期化パラメータ・ファイル内のパラメータ設定と同じ行に記述されているコメントもSPFILEで管理されます。他のコメントはすべて無視されます。

SPFILEの名前と格納場所には、データベースによるデフォルト設定を使用することをお薦めします。これにより、データベースの管理が容易になります。たとえば、STARTUPコマンドはこのデフォルトの場所を想定して、SPFILEを読み込みます。

表2-3は、UNIX、LinuxおよびWindowsのプラットフォームごとに、テキスト形式の初期化パラメータ・ファイル(PFILE)とサーバー・パラメータ・ファイル(SPFILE)の両方のデフォルトの名前と場所を示しています(Oracle Automatic Storage Management(Oracle ASM)を使用する場合と使用しない場合について)。この表では、SPFILEをファイルと想定しています。RAWデバイスの場合、デフォルトの名前は論理ボリューム名またはパーティション・デバイスの名前となり、デフォルトの場所も異なります。

表2-3 UNIX、LinuxおよびWindowsにおけるPFILEおよびSPFILEのデフォルトの名前と場所

プラットフォーム

PFILEのデフォルト名

SPFILEのデフォルト名

PFILEのデフォルトの場所

SPFILEのデフォルトの場所

UNIXとLinux

initORACLE_SID.ora

spfileORACLE_SID.ora

OH/dbs、またはデータファイルと同じ場所脚注1

Oracle ASMを使用しない場合:

OH/dbsまたはデータファイルと同じ場所脚注1

Oracle ASMを使用する場合:

データファイルと同じディスク・グループ脚注2

Windows

initORACLE_SID.ora

spfileORACLE_SID.ora

OH\database

Oracle ASMを使用しない場合:

OH\database

Oracle ASMを使用する場合:

データファイルと同じディスク・グループ脚注2

脚注1OHはOracleホーム・ディレクトリを示す

脚注2DBCAを使用して作成されたデータベースを想定

注意:
起動時に、インスタンスは最初にspfileORACLE_SID.oraという名前のSPFILEを検索し、見つからない場合はspfile.oraを検索します。spfile.oraを使用すると、すべてのReal Application Clusters(Oracle RAC)インスタンスで同じサーバー・パラメータ・ファイルを使用できます。
いずれのSPFILEも見つからない場合、インスタンスはテキスト形式の初期化パラメータ・ファイルinitORACLE_SID.oraを検索します。

デフォルトの場所以外の場所にSPFILEを作成する場合は、デフォルトのPFILEの場所に、そのサーバー・パラメータ・ファイルを指し示すスタブPFILEを作成する必要があります。詳細は、「データベースの起動」を参照してください。

Oracle ASMが存在する場合にDBCAを使用してデータベースを作成すると、DBCAによってSPFILEはOracle ASMディスク・グループ内に配置され、このスタブPFILEも作成されます。

SPFILE初期化パラメータ

SPFILE初期化パラメータには、現在のサーバー・パラメータ・ファイルの名前を指定します。データベースでデフォルトのサーバー・パラメータ・ファイルが使用されている場合(つまり、PFILEパラメータを指定せずにSTARTUPコマンドを発行した場合)、SPFILEの値はサーバーによって内部的に設定されます。SQL*PlusコマンドのSHOW PARAMETERS SPFILE(またはパラメータの値を問い合せる他の方法)を使用すると、現在使用中のサーバー・パラメータ・ファイルの名前が表示されます。

初期化パラメータ値の変更

ALTER SYSTEM文を使用すると、初期化パラメータ値を設定、変更またはデフォルトにリストアできます。テキスト形式の初期化パラメータ・ファイルを使用している場合、現行のインスタンスに対するパラメータの値のみALTER SYSTEM文で変更されます。これは、ディスク上のテキスト形式の初期化パラメータを自動的に更新するメカニズムがないためです。以後のインスタンスに渡すためには、ディスク上の初期化パラメータを手動で更新する必要があります。サーバー・パラメータ・ファイルを使用している場合は、このような制限はありません。

初期化パラメータには、次の2種類があります。

- 動的な初期化パラメータ: 現行のOracle Databaseインスタンスに対して変更できます。変更は即時に有効になります。

- 静的な初期化パラメータ: 現行のインスタンスに対して変更できません。これらのパラメータはテキスト形式の初期化パラメータまたはサーバー・パラメータ・ファイルで変更し、変更を有効にするにはデータベースを再起動する必要があります。

初期化パラメータ値の設定または変更

初期化パラメータ値を設定または変更するには、ALTER SYSTEM文でSET句を指定します。また、次の表のように、変更の適用範囲を指定する場合は、オプションのSCOPE句を指定します。

SCOPE句

説明

SCOPE = SPFILE

サーバー・パラメータ・ファイルのみに変更が適用されます。次のような効果があります。

- 変更は現行インスタンスには適用されません。

- 動的パラメータと静的パラメータの両方について、次の起動時に変更が有効になり、以後持続します。

静的パラメータでは、SCOPE指定のみ使用できます。

SCOPE = MEMORY

メモリーのみに変更が適用されます。次のような効果があります。

- 変更は現行インスタンスに適用され、即時に有効になります。

- 動的パラメータの場合は、変更が即時に有効になりますが、サーバー・パラメータ・ファイルは更新されないので、変更は持続しません。

静的パラメータでは、この指定は使用できません。

SCOPE = BOTH

サーバー・パラメータ・ファイルとメモリーの両方に変更が適用されます。次のような効果があります。

- 変更は現行インスタンスに適用され、即時に有効になります。

- 動的パラメータの場合は、サーバー・パラメータ・ファイルが更新されるので、変更が持続します。

静的パラメータでは、この指定は使用できません。

インスタンスがサーバー・パラメータ・ファイルを使用して起動していない場合にSCOPE=SPFILEまたはSCOPE=BOTHを指定すると、エラーが発生します。デフォルトは、インスタンス起動時にサーバー・パラメータ・ファイルを使用した場合はSCOPE=BOTH、テキスト形式の初期化パラメータ・ファイルを使用した場合はMEMORYになります。

動的パラメータの場合は、DEFERREDキーワードを指定することもできます。このキーワードを指定すると、これから確立するセッションでのみ変更が有効になります。

SCOPEをSPFILEまたはBOTHに指定した場合は、オプションのCOMMENT句を使用すると、パラメータの更新にテキスト文字列を関連付けることができます。サーバー・パラメータ・ファイルにコメントが記述されます。

次の文は、接続を中断するまでのログイン試行の最大失敗回数を変更します。ここにはコメントが含まれており、変更をサーバー・パラメータ・ファイルにのみ適用することを明示しています。

ALTER SYSTEM SET SEC_MAX_FAILED_LOGIN_ATTEMPTS=3
COMMENT='Reduce from 10 for tighter security.'
SCOPE=SPFILE;

次の例では、属性のリストをとる複雑な初期化パラメータを設定しています。値を設定するパラメータは、LOG_ARCHIVE_DEST_n初期化パラメータです。この文によって、このパラメータの既存の設定を変更するか、または新しいアーカイブ先を作成できます。

ALTER SYSTEM
SET LOG_ARCHIVE_DEST_4='LOCATION=/u02/oracle/rbdb1/',MANDATORY,'REOPEN=2'
COMMENT='Add new destination on Nov 29'
SCOPE=SPFILE;

値がパラメータのリストで構成されている場合は、位置または序数によって個々の属性を編集することはできません。パラメータを更新するたびに、完全な値のリストを指定する必要があります。これによって、新しいリストで古いリストが完全に置換されます。

初期化パラメータ値のクリア

ALTER SYSTEM RESETコマンドを使用すると、インスタンスの起動に使用したSPFILEの初期化パラメータの設定をクリア(削除)できます。SCOPE=MEMORYおよびSCOPE=BOTHはいずれも指定できません。SCOPE = SPFILE句は必要ありませんが、指定してもかまいません。

次回のデータベース起動時にデフォルト値が使用されるように、SPFILEのパラメータをクリアできます。

関連項目:
ALTER SYSTEMコマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

サーバー・パラメータ・ファイルのエクスポート

CREATE PFILE文を使用すると、サーバー・パラメータ・ファイル(SPFILE)をテキスト形式の初期化パラメータ・ファイルにエクスポートできます。このエクスポートは、次のような場合に必要になる場合があります。

- 診断のために、現在インスタンスで使用しているすべてのパラメータのリストを作成する場合。これは、SQL*PlusのSHOW PARAMETERSコマンド、あるいはV$PARAMETERまたはV$PARAMETER2ビューの選択と同じです。

- 最初にエクスポートし、結果のテキスト・ファイルを編集してから、CREATE SPFILE文を使用して再作成するという手順で、サーバー・パラメータ・ファイル&spfile;を変更する場合。

PFILE句にエクスポート・ファイルを指定して、インスタンスを起動することもできます。

CREATE PFILE文を実行するには、SYSDBAまたはSYSOPERシステム権限が必要です。エクスポート・ファイルは、データベース・サーバー・システム上に作成されます。そこには、パラメータ設定と同じ行に記述されているパラメータに関するコメントがすべて含まれます。

次の例では、SPFILEからテキスト形式の初期化パラメータ・ファイルを作成しています。

CREATE PFILE FROM SPFILE;

この例ではファイル名を指定していないため、プラットフォーム固有のデフォルト・サーバー・パラメータ・ファイルから、プラットフォーム固有の名前で初期化パラメータ・ファイルが作成されます。

次の例では、サーバー・パラメータ・ファイルからテキスト形式の初期化パラメータ・ファイルを作成していますが、複数のファイル名が指定されています。

CREATE PFILE='/u01/oracle/dbs/test_init.ora'
FROM SPFILE='/u01/oracle/dbs/test_spfile.ora';

注意:
メモリー内の初期化パラメータの現行値からPFILEを作成する方法もあります。次は、必要なコマンドの例です。

CREATE PFILE='/u01/oracle/dbs/test_init.ora' FROM MEMORY;

サーバー・パラメータ・ファイルのバックアップの作成

サーバー・パラメータ・ファイル(SPFILE)をエクスポートして、そのバックアップを作成できます。詳細は「サーバー・パラメータ・ファイルのエクスポート」を参照してください。データベースのバックアップおよびリカバリ計画がRecovery Manager(RMAN)を使用して実装されている場合は、RMANを使用してSPFILEのバックアップを作成できます。SPFILEのバックアップは、データベースのバックアップ作成時にRMANにより自動的に作成されますが、RMANを使用すると現在アクティブになっているSPFILEのバックアップも作成できます。

関連項目:
『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

失われたまたは破損したサーバー・パラメータ・ファイルのリカバリ

サーバー・パラメータ・ファイル(SPFILE)が失われるかまたは破損した場合は、現行インスタンスが失敗するか、またはデータベース・インスタンス起動時の次回の試行が失敗する可能性があります。SPFILEをリカバリする方法は複数あります。

- インスタンスが実行中の場合は、次のコマンドを発行して、メモリー内の初期化パラメータの現行値からSPFILEを再作成します。

CREATE SPFILE FROM MEMORY;

このコマンドでは、SPFILEはデフォルトの場所にデフォルトの名前で作成されます。新しい名前を使用して、または指定した場所にSPFILEを作成することもできます。例については、「サーバー・パラメータ・ファイルの作成」を参照してください。

- 有効なテキスト形式の初期化パラメータ・ファイル(PFILE)がある場合は、次のコマンドを使用してPFILEからSPFILEを再作成します。

CREATE SPFILE FROM PFILE;

このコマンドは、PFILEがデフォルトの場所にあり、デフォルトの名前であると想定しています。PFILEがデフォルト以外の場所にあるか、デフォルト以外の名前の場合に使用するコマンド構文については、「サーバー・パラメータ・ファイルの作成」を参照してください。

- バックアップからSPFILEをリストアします。
詳細は、「サーバー・パラメータ・ファイルのバックアップの作成」を参照してください。

- これらのいずれの方法も使用できない状況の場合は、次の手順を実行します。

1. アラート・ログのパラメータ値のリストからテキスト形式の初期化パラメータ・ファイル(PFILE)を作成します。
インスタンスの起動時に、起動に使用された初期化パラメータがアラート・ログに書き込まれます。このセクションを(XMLタグが含まれていない)テキスト・バージョンのアラート・ログからコピーして、新規PFILEに貼り付けることができます。

詳細は、「アラート・ログの表示」を参照してください。

2. PFILEからSPFILEを作成します。
詳細は、「サーバー・パラメータ・ファイルの作成」 を参照してください。

パラメータ更新時の読取り/書込みエラー

パラメータの更新時にサーバー・パラメータ・ファイルの読込みまたは書込みでエラーが発生した場合は、アラート・ログにエラーが記録されて、サーバー・パラメータ・ファイルに対する後続のパラメータ更新がすべて無視されます。この時点では、次の処理のいずれかを実行できます。

- インスタンスを停止し、この項の前述の説明に従ってサーバー・パラメータ・ファイルをリカバリした後、インスタンスを再起動します。

- 後続のパラメータ更新を持続的にするための処置を講じない場合は、データベースの実行を継続します。

パラメータ設定の表示

パラメータの設定は、次の表に示すように、いくつかの方法で表示できます。

方法

説明

SHOW PARAMETERS

このSQL*Plusコマンドを使用すると、現行セッションで有効な初期化パラメータの値が表示されます。

SHOW SPPARAMETERS

このSQL*Plusコマンドを使用すると、サーバー・パラメータ・ファイル(SPFILE)の初期化パラメータの値が表示されます。

CREATE PFILE

このSQL文は、SPFILEまたは現在のインメモリー設定からテキスト形式の初期化パラメータ・ファイル(PFILE)を作成します。PFILEはテキスト・エディタで表示できます。

V$PARAMETER

このビューを使用すると、現行セッションで有効な初期化パラメータの値が表示されます。

V$PARAMETER2

このビューを使用すると、現行セッションで有効な初期化パラメータの値が表示されます。各リスト・パラメータ値が別々の行に出力されるため、このビューの方がリスト・パラメータ値を容易に識別できます。

V$SYSTEM_PARAMETER

このビューを使用すると、インスタンスで有効な初期化パラメータの値が表示されます。新しいセッションは、インスタンス全体の値からパラメータ値を継承します。

V$SYSTEM_PARAMETER2

このビューを使用すると、インスタンスで有効な初期化パラメータの値が表示されます。新しいセッションは、インスタンス全体の値からパラメータ値を継承します。各リスト・パラメータ値が別々の行に出力されるため、このビューの方がリスト・パラメータ値を容易に識別できます。

V$SPPARAMETER

このビューを使用すると、SPFILEの現在の内容が表示されます。インスタンスでSPFILEが使用されていない場合は、ISSPECIFIED列にFALSEが返されます。

関連項目:
ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベース・サービスでのアプリケーション・ワークロードの管理

この項の内容は次のとおりです。

- データベース・サービスの理解

- データベース・サービスの作成

- データベース・サービスのデータ・ディクショナリ・ビュー

データベース・サービスの理解

データベース・サービス(サービス)は、Oracle Databaseでワークロードを管理するための論理的な抽象概念です。サービスは、ワークロードを互いに共通の要素を持たないグループに分割します。各サービスは、一般的な属性、サービス・レベルしきい値および優先度でワークロードを表します。グループ化は作業の属性に基づいて行われますが、これらの属性には、使用するアプリケーション機能、アプリケーション機能を実行する場合の優先度、管理の対象となるジョブ・クラス、アプリケーション機能またはジョブ・クラスで使用するデータの範囲などが含まれていることがあります。たとえば、Oracle E-Business Suiteでは、総勘定元帳、売掛金勘定、受注など、職務ごとにサービスを定義します。データベース・サービスを構成するとき、一意のグローバル名、関連するパフォーマンス目標および関連する重要性を各サービスに指定します。これらのサービスは、Oracle Databaseと緊密に統合され、データ・ディクショナリに保持されます。

接続要求には、データベース・サービス名を指定できます。このように、中間層アプリケーションおよびクライアントとサーバーのアプリケーションでは、サービスをTNS接続データ内の接続の一部として指定することで、サービスを利用します。サービス名が指定されておらず、Net Servicesファイルlistener.oraにデフォルト・サービスが指定されている場合は、デフォルト・サービスを使用して接続されます。

サービスを使用すると、ワークロードの構成、管理、有効化と無効化を実行でき、さらに単一エンティティとして測定できます。これらの作業は、Database Configuration Assistant(DBCA)、Net Configuration Assistant(NetCA)およびOracle Enterprise Managerなどの標準的なツールを使用して実行できます。Enterprise Managerは、表示と操作に関するサービスを全体としてサポートし、必要な場合はインスタンス・レベルへのドリルダウンをサポートしています。

Oracle Real Application Clusters(Oracle RAC)環境では、サービスは1つ以上のインスタンスにまたがり、トランザクション・パフォーマンスに基づいたワークロードの均衡化に役立ちます。これによって、エンドツーエンドの無人リカバリ、ワークロードによるロール変更、位置の完全な透過性が可能となります。また、Oracle RACを使用すると、Enterprise Manager、DBCAおよびServer Control Utility(SRVCTL)で複数のサービス機能を管理できます。

サービスは、パフォーマンス・チューニングに追加のディメンションも提供します。すべてのセッションを匿名で共有している大部分のシステムでは、「サービスとSQL」によるチューニングで「セッションとSQL」によるチューニングを置換できます。サービスを使用することで、ワークロードが表示可能および測定可能となります。リソースの使用と待機は、アプリケーションがその起因となっています。また、サービスに割り当てたリソースは、ロードの増減にあわせて調整できます。この動的なリソース割当てによって、要求の発生に対応した費用効率の高いソリューションが可能となります。たとえば、サービスを自動的に測定し、そのパフォーマンスをサービス・レベルのしきい値と比較できます。パフォーマンス違反はEnterprise Managerにレポートされるため、自動ソリューションまたはスケジュールされたソリューションを実行できます。

Oracle Database機能のいくつかは、サービスをサポートしています。自動ワークロード・リポジトリ(AWR)は、サービスのパフォーマンスを管理します。AWRには、実行時間、待機クラスおよびサービスで使用されたリソースも含めて、サービスのパフォーマンスが記録されます。AWRは、サービス応答時間がしきい値を超えた場合、警告をアラートします。動的なビューには、現在のサービス・パフォーマンスのメトリックが時間の履歴単位でレポートされます。各サービスには、応答時間とCPU使用に関するサービス品質のしきい値があります。

さらに、データベース・リソース・マネージャでは、サービスをコンシューマ・グループにマッピングできます。これによって、サービスの優先度を他のサービスと関連させて自動的に管理できます。コンシューマ・グループを使用すると、比率またはリソース使用量の観点から相対的な優先順序を定義できます。詳細は、第27章「Oracle Database Resource Managerを使用したリソースの管理」および具体的には「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照してください。

また、サービスのエディション属性を指定することもできます。エディションを使用すると、データベース内に同じオブジェクトの複数のバージョンを保持できます。あるサービスにエディション属性を指定すると、そのサービスを指定する後続のすべての接続が、このエディションを初期セッション・エディションとして使用します。詳細は、「データベース・サービスのエディション属性の設定」を参照してください。

エディションをサービス属性として指定すると、リソース使用の管理が容易になります。たとえば、1つのエディションに関連付けられた複数のサービスを1つのOracle RAC環境における個別のインスタンスに配置でき、データベース・リソース・マネージャは、リソース・プランを対応するサービスに関連付けることによって、異なるエディションで使用されているリソースを管理できます。

サービスには、アプリケーション、アプリケーション機能およびデータの範囲が、機能サービスまたはデータ依存サービスとして記述されています。機能サービスは最も一般的なワークロードのマッピングです。特定の機能を使用する複数のセッションはまとめてグループ化されます。これに対して、データ依存ルーティングは、データ・キーに基づいてセッションをサービスにルーティングします。作業要求のサービスへのマッピングは、アプリケーション・サーバーとTPモニターのオブジェクト関連マッピング・レイヤーで発生します。たとえば、Oracle RACでは、データベースが共有されているため、これらの範囲は要求に基づいて完全に動的にできます。

また、Oracle RACデータベースには、事前接続のアプリケーション・サービスを定義できます。事前接続のサービスは、複数のインスタンスにまたがって、障害時にサービスをサポートします。この事前接続のサービスは、TAF事前接続モードをサポートし、Oracle RAC使用時には透過的に管理されます。

アプリケーションにより使用されるサービスに加えて、Oracle Databaseでは、2つの内部サービスもサポートされています。SYS$BACKGROUNDはバックグラウンド・プロセスのみで使用され、SYS$USERSはサービスに関連していないユーザー・セッションに対するデフォルトのサービスです。

サービスを使用するために、アプリケーション・コードを変更する必要はありません。クライアント側の作業は、指定したサービスへ接続できます。Oracle Scheduler、パラレル実行、Oracle Streamsアドバンスト・キューイングなどのサーバー側での作業では、ワークロード定義の一部としてサービス名を設定します。サービス下で実行される作業要求は、そのサービスのパフォーマンスしきい値を継承し、サービスの一部として測定されます。

Oracle Schedulerでは、ジョブ・クラスの作成時にオプションでサービスを割り当てることができます。実行中に複数のジョブがジョブ・クラスに割り当てられ、サービス内で複数のジョブ・クラスを実行できます。ジョブ・クラスとともにサービスを使用することで、ジョブ・スケジューラによって実行される作業が、ワークロード管理とパフォーマンス・チューニングに対して示されます。

パラレル問合せとパラレルDMLの場合、問合せコーディネータは他のクライアントと同じようにサービスに接続します。パラレル問合せプロセスは、実行中そのサービスを継承します。問合せが終了した時点で、パラレル実行プロセスはデフォルトのサービスに戻ります。

関連項目:

- Oracle Schedulerの詳細は、第29章「Oracle Schedulerを使用したジョブのスケジューリング」を参照してください。

- Oracle RAC環境でのサービスの利用の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- サービスへの接続の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

データベース・サービスの作成

データベース・サービスの作成方法はデータベースの構成によっていくつかあります。

データベース・サービスの作成方法は、次のとおりです。

- 単一インスタンスのデータベースをOracle Restartで管理している場合は、SRVCTLユーティリティを使用してデータベース・サービスを作成します。

srvctl add service -d db_unique_name -s service_name

- Oracle Restartで管理していない単一インスタンスのデータベースでは、次のいずれかを実行します。

- SERVICE_NAMESパラメータに希望するサービス名を追加します。

- DBMS_SERVICE.CREATE_SERVICEパッケージ・プロシージャをコールします。

- (オプション)サービス属性をOracle Enterprise ManagerまたはDBMS_SERVICE.MODIFY_SERVICEで定義します。

関連項目:

- Oracle Restartの詳細は、第4章「Oracle Databaseの自動再起動の構成」を参照してください。

- DBMS_SERVICEパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- Oracle RAC環境でのサービスの作成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

データベース・サービスのデータ・ディクショナリ・ビュー

サービス情報は、次のサービス固有のビューで参照できます。

- DBA_SERVICES

- ALL_SERVICESまたはV$SERVICES

- V$ACTIVE_SERVICES

- V$SERVICE_STATS

- V$SERVICE_EVENT

- V$SERVICE_WAIT_CLASSES

- V$SERV_MOD_ACT_STATS

- V$SERVICE_METRICS

- V$SERVICE_METRICS_HISTORY

次の追加ビューにも、サービスに関する情報が表示されます。

- V$SESSION

- V$ACTIVE_SESSION_HISTORY

- DBA_RSRC_GROUP_MAPPINGS

- DBA_SCHEDULER_JOB_CLASSES

- DBA_THRESHOLDS

関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベースを作成した後の考慮点

「DBCAを使用したデータベースの作成」または「CREATE DATABASE文を使用したデータベースの作成」で説明されているように、データベースの作成後は、インスタンスが稼働しておりデータベースがオープンしているので、通常どおりにデータベースを使用できます。他の処理も実行できますが、この項ではその処理の一部について説明します。

セキュリティに関する考慮点

このリリースのOracle Databaseでは、データベースのセキュリティを確保するためにいくつかの機能が拡張されました。このリリースのセキュリティ・ガイドラインは、『Oracle Databaseセキュリティ・ガイド』にあります。これらのガイドラインを参照し、その内容に従ってデータベースを構成してください。

データベースを作成した後は、Oracle Identity Managementが活用できるように構成できます。構成方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

新しく作成したデータベースには、データベースの管理にとって重要なユーザー・アカウントが少なくとも3つ(SYS、SYSTEMおよびSYSMAN)あります。認可されたユーザーのみが使用する追加の管理アカウントが提供されています。これらのアカウントを、オラクル社が提供するパスワードを認識している未認可ユーザーによる使用から保護するには、それぞれのパスワードを期限切れにすることで最初にアカウントをロックします。データベース管理者には、これらのアカウントのロック解除とリセットを行う責任があります。

新規の各Oracle Databaseインストールで作成される事前定義のユーザー・アカウントの全リストは、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

注意:
データベースへの不当なアクセスを防ぎ、データベースの整合性を保護するには、データベースの作成時に、ユーザー・アカウントSYSとSYSTEMに対して新しいパスワードを指定することが重要です。パスワードを指定するには、手動でデータベースを作成するときに次のCREATE DATABASE句を指定するか、またはDBCAを使用してデータベースを作成します。

- USER SYS IDENTIFIED BY

- USER SYSTEM IDENTIFIED BY

関連項目:

- ユーザーSYSおよびSYSTEMの詳細は、「管理ユーザー・アカウント」を参照してください。

- 新しいユーザーの追加方法とパスワードの変更方法は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- ユーザー・アカウントのロック解除に使用するALTER USER文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

透過的データ暗号化の有効化

透過的データ暗号化は、個々のデータベース列をデータファイルに格納する前に暗号化するか、表領域全体を暗号化する機能です。ユーザーが、オペレーティング・システムのツールを使用してデータファイルの内容を直接参照することによって、データベース・アクセス制御メカニズムを迂回しようとした場合でも、透過的データ暗号化によって、このようなユーザーが機密情報を参照できないようにします。

CREATE TABLE権限のあるユーザーは、暗号化対象の表の列を1つ以上選択できます。データは、データファイルおよび監査ログ(監査がオンの場合)内で暗号化されます。適切な権限のあるデータベース・ユーザーは、データを暗号化されていない形式で表示できます。透過的データ暗号化の有効化および無効化の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

関連項目:

- 「機密データを格納する列の暗号化」

- 「暗号化された表領域」

安全性の高い外部パスワード・ストアの作成

アプリケーションでデータベースに接続するためにパスワード資格証明が使用される大規模なデプロイメントでは、この資格証明をクライアント側のOracleウォレットに格納できます。Oracle Walletは、資格証明の認証および署名の格納に使用されるセキュアなソフトウェア・コンテナです。

クライアント側のOracleウォレットにデータベース・パスワード資格証明を格納することで、ユーザー名とパスワードをアプリケーション・コード、バッチ・ジョブまたはスクリプトに埋め込む必要がなくなります。この結果、スクリプトやアプリケーション・コードに記述したパスワードが外部にさらされる危険性が低くなり、ユーザー名とパスワードを変更するたびにコードを変更する必要がないため、メンテナンスが簡素化されます。また、アプリケーション・コードを変更する必要がないため、これらのユーザー・アカウントのパスワード管理ポリシーをさらに簡単に規定できるようになります。

外部パスワード・ストアを使用するようにクライアントを構成すると、アプリケーションでは、次の構文を使用してパスワード認証を使用しているデータベースに接続できます。

CONNECT /@database_alias

このCONNECT文では、データベース・ログイン資格証明を指定する必要はありません。かわりに、データベース・ログイン資格証明はクライアントのウォレットで検索されます。

関連項目:

- 『Oracle Databaseセキュリティ・ガイド』

- 『Oracle Database Advanced Security管理者ガイド』

Oracle Databaseサンプル・スキーマのインストール

Oracle Databaseの配布媒体には、各種のSQLファイルが格納されています。このSQLファイルでは、システムの試用、SQLの学習、追加の表、ビュー、シノニムの作成などが可能です。

Oracle Databaseには、Oracle Database機能の理解に役立つサンプル・スキーマが含まれています。Oracle Databaseに関するすべてのマニュアルと研修資料は、更新時にサンプル・スキーマ環境に変換されます。

サンプル・スキーマはDatabase Configuration Assistantによって自動的にインストールするか、手動でインストールできます。スキーマとインストール手順の詳細は、『Oracle Databaseサンプル・スキーマ』を参照してください。

CloneDBを使用したデータベースのクローニング

この項の内容は次のとおりです。

- CloneDBを使用したデータベースのクローニングの概要

- CloneDBを使用したデータベースのクローニング

- CloneDBを使用したデータベースのクローニング後

CloneDBを使用したデータベースのクローニングの概要

多くの場合、テスト目的またはその他の目的で本番データベースをクローニングすることが必要となります。本番データベースをクローニングする一般的な理由は、次のとおりです。

- データベースを使用する新規アプリケーションのデプロイ、または既存のアプリケーションの更新

- データベースを実行するシステムでの、オペレーティング・システムのアップグレード計画

- データベース・インストール用の新しい記憶域

- レポート

- 古いデータの分析

新しいアプリケーションをデプロイする前、オペレーティング・システムのアップグレードを実行する前、または新しい記憶域を使用する前に、新しい状況でデータベースが適切に動作することを確認するために徹底的にテストすることが必要です。クローニングは、本番データファイルのコピーを1つ以上のテスト環境に作成することで実行できますが、通常、これらのコピーを割り当てて管理するために、大量の記憶域が必要となります。

CloneDBを使用すると、データファイルを複数の異なる場所にコピーしなくても、データベースを複数回クローニングできます。Oracle Databaseでは、かわりにcopy-on-writeテクノロジを使用してCloneDBデータベースにファイルを作成するため、ディスク上に追加の記憶域が必要となるのは、CloneDBデータベースで変更されたブロックのみとなります。

この方法でデータベースをクローニングすると、次の利点があります。

- テスト目的で必要となる記憶域の量が削減されます。

- 様々な目的のために複数のデータベース・クローンを迅速に作成できます。

CloneDBデータベースは、データベース・バックアップのデータファイルを使用します。バックアップ・データファイルを使用すると、CloneDBインスタンスによる本番データファイルへのアクセスが行われず、CPUやI/Oリソースなどの本番データベースのリソースに対するCloneDBインスタンスによる競合が発生しません。

注意:

- CloneDBの機能は、Oracle Database 11gリリース2(11.2.0.3)からサポートされるようになりました。

- CloneDB機能は、パフォーマンス・テスト向けではありません。

CloneDBを使用したデータベースのクローニング

データベースをクローニングするには、次の前提条件を満たしている必要があります。

- 各CloneDBデータベースはDirect NFSクライアントを使用する必要があり、本番データベースのバックアップはNFSボリューム上に存在する必要があります。
Direct NFSクライアントにより、Oracle Databaseは、オペレーティング・システム・カーネルのNFSクライアントを使用するかわりに、ネットワーク接続記憶域(NAS)デバイスに直接アクセスできます。このCloneDBデータベース機能は、Direct NFSクライアントをサポートするプラットフォームで使用可能です。

Direct NFSクライアントの詳細は、使用しているオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

- CloneDBデータベースの変更されたブロックを追跡するには、少なくとも2MBの追加システム・グローバル領域(SGA)メモリーが必要です。
第6章「メモリーの管理」を参照してください。

- データベース・バックアップ用および各CloneDBデータベースの変更されたブロック用の記憶域が必要となります。
データベース・バックアップに必要な記憶域は、バックアップの実行に使用する方法によって異なります。単一の全体RMANバックアップでは、最も多くの記憶域が必要となります。ストレージ・アプライアンスの機能を使用して実行される記憶域スナップショットは、そのストレージ・アプライアンスの要件に従います。単一のバックアップで複数のCloneDBデータベースをサポートできます。

各CloneDBデータベースで必要となる記憶域の量は、そのデータベースの書込みアクティビティによって異なります。変更される各ブロックには、記憶域の使用可能な1つのブロックが必要となります。したがって、必要となる合計記憶域は、一定期間にCloneDBデータベースで変更されるブロックの数によって異なります。

この項では、1つのCloneDBデータベースを作成するための手順について説明し、これらのサンプル・データベースおよびディレクトリを使用します。

- 本番データベースPROD1のOracleホームは/u01/prod1/oracleです。

- データベース・バックアップのファイルは/u02/oracle/backup/prod1にあります。

- CloneDBデータベースCLONE1のOracleホームは/u03/clone1/oracleです。

CloneDBを使用してデータベースをクローニングする手順は、次のとおりです。

1. 本番データベースのバックアップを作成します。次のバックアップ・オプションがあります。

- オンライン・バックアップ
オンライン・バックアップを実行する場合は、本番データベースがARCHIVELOGモードになっており、必要なすべてのアーカイブREDOログ・ファイルが保存され、CloneDBデータベース環境にアクセスできることを確認します。

- 全体オフライン・バックアップ
全体オフライン・バックアップを実行する場合は、バックアップ・ファイルがCloneDBデータベース環境にアクセスできることを確認します。

- データベース・ファイルをコピーするバックアップ
BACKUP AS COPYをRMANで指定すると、RMANは各ファイルを、ディスクに作成されたデータベース・ファイルのビットごとのコピーであるイメージ・コピーとしてコピーします。イメージ・コピーは、LinuxのcpやWindowsのCOPYなどのオペレーティング・システム・コマンドで作成したコピーと同じですが、RMANのリポジトリに記録されるため、RMANで使用できます。RMANを使用すると、データベースがオープンしている間にイメージ・コピーを作成できます。コピーされたデータベース・ファイルがCloneDBデータベース環境にアクセスできることを確認します。

データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

2. テキスト形式の初期化パラメータ・ファイル(PFILE)がない場合は、作成します。
サーバー・パラメータ・ファイル(SPFILE)を使用する場合は、本番データベース上で次の文を実行して、PFILEを作成します。

CREATE PFILE FROM SPFILE;

3. 本番データベースをクローニングするためのSQLスクリプトを作成します。

後の手順で、CloneDBデータベースを作成するために、1つ以上のSQLスクリプトを使用します。SQLスクリプトを作成するには、オラクル社が提供するclonedb.plと呼ばれるPerlスクリプトを使用するか、またはSQLスクリプトを手動で作成できます。

clonedb.pl Perlスクリプトを使用するには、次の手順を実行します。

1. オペレーティング・システムのプロンプトで、次の環境変数を設定します。
MASTER_COPY_DIR - 手順1で作成したバックアップが含まれるディレクトリを指定します。このディレクトリには、本番データベースのデータファイルのバックアップのみが含まれていることを確認します。

CLONE_FILE_CREATE_DEST - データファイル、ログ・ファイル、制御ファイルなど、CloneDBデータベース・ファイルが作成されるディレクトリを指定します。

CLONEDB_NAME - CloneDBデータベースの名前を指定します。

S7000_TARGET - バックアップ用のファイル・システムを提供するNFSホストおよびCloneDBデータベースがSun Storage 7000である場合は、ホストの名前を指定します。それ以外の場合は、この環境変数を設定しないでください。この環境変数は、記憶域スナップショットを使用してクローニングを実行する必要がある場合にのみ設定します。この変数を設定せずに、Direct NFSクライアントにS7000ストレージ・アレイを使用できます。

2. clonedb.pl Perlスクリプトを実行します。

Oracle Database 11g リリース2(11.2.0.4)以上のデータベースの場合、スクリプトは$ORACLE_HOME/rdbms/installディレクトリにあります。

Oracle Database 11g リリース2(11.2.0.3)のデータベースの場合は、https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1210656.1のMy Oracle Support Note 1210656.1 (「Clone your dNFS Production Database for Testing」)からスクリプトをダウンロードします。

Perlスクリプトclonedb.plの構文は次のとおりです。

perl clonedb.pl prod_db_pfile [sql_script1] [sql_script2]

次のオプションを指定します。

prod_db_pfile - 本番データベースのPFILEのフルパスを指定します。

sql_script1 - clonedb.plによって生成された最初のSQLスクリプトの名前を指定します。デフォルトはcrtdb.sqlです。

sql_script2 - clonedb.plによって生成された2番目のSQLスクリプトの名前を指定します。デフォルトはdbren.sqlです。

clonedb.plスクリプトは、本番データベースのPFILEをCloneDBデータベースのディレクトリにコピーします。また、CloneDBデータベースの作成に使用する2つのSQLスクリプトも作成します。

3. clonedb.pl Perlスクリプトにより生成された2つのSQLスクリプトを確認し、必要に応じて変更します。

4. CloneDBデータベース環境の初期化パラメータを変更し、ファイルを保存します。
CloneDBデータベース環境固有の初期化パラメータ(SGAサイズ、PGAターゲット、CPUの数などを制御するパラメータなど)を変更します。CLONEDBパラメータをTRUEに設定する必要があり、初期化パラメータ・ファイルにこのパラメータが含まれています。初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

5. SQL*Plusで、CloneDBデータベースにSYSDBA管理権限で接続します。

6. clonedb.pl Perlスクリプトで生成されたSQLスクリプトを実行します。
たとえば、スクリプトでデフォルト名を使用する場合は、SQLプロンプトで次のスクリプトを実行します。

crtdb.sql
dbren.sql

SQLスクリプトを手動で作成するには、次の手順を実行します。

1. SYSDBAまたはSYSBACKUP管理権限でデータベースに接続します。
「SQL*Plusを使用したデータベースへの接続」を参照してください。

2. 次の手順を実行して、本番データベースからバックアップ制御ファイル・スクリプトを生成します。

次のSQL文を実行します。

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

この文により、制御ファイルを作成するSQL文を含むトレース・ファイルが生成されます。CREATE CONTROLFILE文を含むトレース・ファイルは、DIAGNOSTIC_DEST初期化パラメータで指定されたディレクトリに格納されます。データベース・アラート・ログでこのトレース・ファイルの名前と場所を確認します。

3. 手順bで生成したトレース・ファイルを開き、トレース・ファイル内のSTARTUP NOMOUNT文とCREATE CONTROLFILE文を新しいSQLスクリプトにコピーします。

4. 手順cで作成した新しいSQLスクリプトを次の方法で編集します。

データベースの名前を、作成するCloneDBデータベースの名前に変更します。たとえば、PROD1をCLONE1に変更します。

ログ・ファイルの場所を、CloneDBデータベース環境のディレクトリに変更します。たとえば、/u01/prod1/oracle/dbs/t_log1.fを/u03/clone1/oracle/dbs/t_log1.fに変更します。

データファイルの場所を、バックアップの場所に変更します。たとえば、/u01/prod1/oracle/dbs/t_db1.fを/u02/oracle/backup/prod1/t_db1.fに変更します。

次に、ALTER DATABASE BACKUP CONTROLFILE TO TRACE文で生成された元の文の例を示します。

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "PROD1" NORESETLOGS  ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 1
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/u01/prod1/oracle/dbs/t_log1.f'  SIZE 25M BLOCKSIZE 512,
GROUP 2 '/u01/prod1/oracle/dbs/t_log2.f'  SIZE 25M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/u01/prod1/oracle/dbs/t_db1.f',
'/u01/prod1/oracle/dbs/t_ax1.f',
'/u01/prod1/oracle/dbs/t_undo1.f',
'/u01/prod1/oracle/dbs/t_xdb1.f',
'/u01/prod1/oracle/dbs/undots.dbf'
CHARACTER SET WE8ISO8859P1
;

次に、新しいSQLスクリプトの変更された文の例を示します。

STARTUP NOMOUNT PFILE=/u03/clone1/oracle/dbs/clone1.ora
CREATE CONTROLFILE REUSE DATABASE "CLONE1" RESETLOGS  ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 1
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/u03/clone1/oracle/dbs/t_log1.f'  SIZE 25M BLOCKSIZE 512,
GROUP 2 '/u03/clone1/oracle/dbs/t_log2.f'  SIZE 25M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/u02/oracle/backup/prod1/t_db1.f',
'/u02/oracle/backup/prod1/t_ax1.f',
'/u02/oracle/backup/prod1/t_undo1.f',
'/u02/oracle/backup/prod1/t_xdb1.f',
'/u02/oracle/backup/prod1/undots.dbf'
CHARACTER SET WE8ISO8859P1
;

データファイルで取得した記憶域レベルのスナップショットがある場合は、RMANバックアップ・ファイル名を記憶域スナップショット名に置き換えることができます。

5. SQLスクリプトを編集した後、そのスクリプトをCloneDBデータベース環境にアクセスできる場所に保存します。

新しいSQLスクリプトの名前および保存場所をメモします。このスクリプトは、後続の手順で実行します。この例では、スクリプトの名前はcreate_clonedb1.sqlであると想定しています。

6. テキスト形式の初期化パラメータ・ファイル(PFILE)を、本番データベース環境からCloneDBデータベース環境にコピーします。
たとえば、テキスト形式の初期化パラメータ・ファイルを/u01/prod1/oracle/dbsから/u03/clone1/oracle/dbsにコピーします。ファイルの名前および場所は、変更したSQLスクリプトのSTARTUP NOMOUNTコマンドで指定した名前と場所に一致する必要があります。手順dの例では、ファイルは/u03/clone1/oracle/dbs/clone1.oraです。

7. CloneDBデータベース環境の初期化パラメータを変更し、ファイルを保存します。
CLONEDBパラメータを追加し、このパラメータがTRUEに設定されていることを確認します。CloneDBデータベース環境に固有の他のすべての初期化パラメータ(SGAサイズ、PGAターゲット、CPUの数などを制御するパラメータなど)を変更します。初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

8. SQL*Plusで、CloneDBデータベースにSYSDBA管理権限で接続します。

9. 手順eで保存したSQLスクリプトを実行します。
たとえば、SQL*Plusで次のように入力します。

@create_clonedb1.sql

10. バックアップの場所の各データファイルで、DBMS_DNFSパッケージのCLONEDB_RENAMEFILEプロシージャを実行し、CloneDBデータベース環境の適切な場所を指定します。
たとえば、バックアップ・データファイルが/u02/oracle/backup/prod1/t_db1.fで、CloneDBデータベース・データファイルが/u03/clone1/oracle/dbs/t_db1.fである場合は、次のプロシージャを実行します。

BEGIN
DBMS_DNFS.CLONEDB_RENAMEFILE(
srcfile  => '/u02/oracle/backup/prod1/t_db1.f',
destfile => '/u03/clone1/oracle/dbs/t_db1.f');
END;
/

DBMS_DNFSパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

4. CloneDBデータベースをオンライン・バックアップから作成した場合は、CloneDBデータベースをリカバリします。全体オフライン・バックアップまたはBACKUP AS COPYバックアップを実行した場合、この手順は必要ありません。
たとえば、次のSQL文をCloneDBデータベースで実行します。

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

この文により、バックアップが実行されたときのアーカイブREDOログ・ファイルを求められます。

5. 次のSQL文を実行して、データベースをオープンします。

ALTER DATABASE OPEN RESETLOGS;

CloneDBデータベースを使用する準備ができました。

本番データベースの追加のCloneDBデータベースを作成するには、手順3から5を各CloneDBデータベースに対して繰り返します。

CloneDBを使用したデータベースのクローニング後

CloneDBデータベースを作成した後、本番データベースを使用するほとんどすべての方法でそのデータベースを使用できます。最初は、CloneDBデータベースは各データファイルに対して最小限の記憶域を使用します。CloneDBデータベースの行に対して変更を加えると、記憶域がオンデマンドで割り当てられます。

同じバックアップ・ファイルを使用して、複数のCloneDBデータベースを作成できます。このバックアップは、RMANまたは記憶域レベルのスナップショットによって取得できます。データファイルで取得した記憶域レベルのスナップショットがある場合は、RMANバックアップ・ファイル名を記憶域スナップショット名に置き換えることができます。

V$CLONEDFILEビューを使用して、CloneDBデータベースの各データファイルに関する情報を表示できます。この情報には、バックアップのデータファイル名、CloneDBデータベースでの対応するデータファイル名、バックアップ・ファイルから読み取られたブロック数、バックアップ・ファイルに対して発行された要求の数が含まれます。

CloneDBデータベースはバックアップ・ファイルをバックエンド記憶域として使用するため、これらのバックアップ・ファイルは、実行するために各CloneDBデータベースで使用可能である必要があります。バックアップ・ファイルが使用不可能になると、CloneDBデータベースはエラーを返します。

CloneDBデータベースの使用が完了した後、CloneDBデータベース環境を破棄できます。CloneDBデータベース環境のすべてのファイルは、本番データベース環境またはバックアップ環境に影響を与えずに削除できます。

関連項目:
V$CLONEDFILEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベースの削除

データベースの削除には、データファイル、REDOログ・ファイル、制御ファイルおよび初期化パラメータ・ファイルの削除も含まれます。

警告:

データベースを削除すると、そのデータベースに含まれるすべてのデータが削除されます。

データベースを削除するには、次の手順を実行します。

- 次の文を発行します。

DROP DATABASE;

DROP DATABASE文では、まず、すべての制御ファイルと制御ファイルに記述されている他のすべてのデータベース・ファイルが削除されます。その後、データベース・インスタンスが停止されます。

DROP DATABASE文の使用に成功するには、排他的に、制限モードでデータベースをマウントしておく必要があります。

DROP DATABASE文は、アーカイブ・ログ・ファイル、およびデータベースのコピーまたはバックアップには影響を与えません。これらのファイルを削除する場合は、RMANを使用することをお薦めします。データベースがRAWディスク上にある場合、そのRAWディスクにある実際の特殊ファイルは削除されません。

Database Configuration Assistantを使用してデータベースを作成した場合は、データベースおよびファイルの削除にこのツールを使用できます。

関連項目:
「データベースの可用性の変更」

データベースのデータ・ディクショナリ・ビュー

「パラメータ設定の表示」にリストしたビューの他に、次のビューを使用してデータベースの内容や構造に関する情報を参照できます。

ビュー

説明

DATABASE_PROPERTIES

永続的なデータベース・プロパティが表示されます。

GLOBAL_NAME

グローバル・データベース名が表示されます。

V$DATABASE

制御ファイル内のデータベース情報が表示されます。

3 起動と停止

この章の内容は、次のとおりです。

- データベースの起動

- データベースの可用性の変更

- データベースの停止

- データベースの静止

- データベースの一時停止と再開

関連項目:
Oracle Real Application Clusters環境に固有の追加情報は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

データベースの起動

データベースの起動時には、そのデータベースのインスタンスを作成し、データベースの状態を確認します。インスタンスは通常、データベースをマウントおよびオープンすることで起動します。これによって、有効なユーザーはデータベースに接続して通常のデータ・アクセス操作を実行できます。ここでは、他の起動方法についても説明します。

この項の内容は、次のとおりです。

- データベースの起動オプションの概要

- 初期化パラメータ・ファイルおよび起動の概要

- データベース・サービスの自動起動の概要

- インスタンス起動の準備

- インスタンスの起動

データベースの起動オプションの概要

Oracle Restartを使用していない場合は、SQL*Plus、Recovery ManagerまたはEnterprise Managerを使用してデータベース・インスタンスを起動できます。Oracle Restartでデータベースを管理している場合は、SRVCTLを使用してデータベースを起動する方法をお薦めします。

Oracle Restartの詳細は、第4章「Oracle Databaseの自動再起動の構成」を参照してください。

SQL*Plusを使用したデータベースの起動

SQL*Plusセッションを開始し、管理者権限でOracle Databaseに接続すると、STARTUPコマンドを発行できます。このマニュアルでは、SQL*Plusを使用するこの方法について詳細に説明します。

Recovery Managerを使用したデータベースの起動

Recovery Manager(RMAN)を使用して、STARTUPおよびSHUTDOWNコマンドを実行する方法もあります。この方法を選択するのは、RMAN環境でSQL*Plusを起動しない場合です。

関連項目:
RMAN STARTUPコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

Oracle Enterprise Managerを使用したデータベースの起動

Oracle Enterprise Managerは、起動や停止も含めたデータベースの管理に使用できます。Enterprise Managerは、GUIコンソール、エージェント、共有サービスおよびOracleのツール製品を組み合せて、Oracle製品の管理のために統合された包括的なシステム管理プラットフォームを提供します。Enterprise Manager Database ControlはOracleデータベースの管理に特化したEnterprise Managerの機能で、これを使用するとコマンドライン操作のかわりにGUIインタフェースを使用して、このマニュアルで説明されている機能を実行できます。

関連項目:

- 『Oracle Enterprise Manager概要』

- 『Oracle Database 2日でデータベース管理者』

ここからは、SQL*Plusを使用してデータベース・インスタンスを起動する方法について説明します。

SRVCTLを使用したデータベースの起動

Oracle Restartがインストールされてデータベース用に構成されている場合は、SRVCTLを使用してデータベースを起動することをお薦めします。そうすると、次の処理が確実に実行されます。

- データベースが依存する任意のコンポーネント(Oracle Automatic Storage ManagementやOracle Netリスナーなど)が、適切な順序で最初に自動起動します。

- データベースはOracle Restart構成の設定に従って起動します。そのような設定の例は、サーバー・パラメータ・ファイルの場所です。

- データベースのOracle Restart構成に格納された環境変数は、インスタンス起動前に設定されます。

詳細は、「srvctl start database」および「Oracle Restartで管理されているコンポーネントの起動と停止」を参照してください。

起動時における初期化パラメータの指定

データベースは、インスタンスを起動するために、サーバー・パラメータ・ファイル(SPFILE)またはテキスト形式の初期化パラメータ・ファイル(PFILE)からインスタンス構成パラメータ(初期化パラメータ)を読み込む必要があります。

データベースは、デフォルトの場所でこれらのファイルを検索します。これらのファイルにデフォルト以外の場所を指定することも可能で、その方法は、データベースの起動にSQL*Plusを使用するか(Oracle Restartを使用していない場合)、SRVCTLを使用するか(データベースをOracle Restartで管理している場合)によって異なります。

この項の内容は、次のとおりです。

- 初期化パラメータ・ファイルおよび起動の概要

- デフォルト以外のサーバー・パラメータ・ファイルを使用したSQL*Plusでの起動

- デフォルト以外のサーバー・パラメータ・ファイルを使用したSRVCTLでの起動

関連項目:
初期化パラメータ、初期化パラメータ・ファイルおよびサーバー・パラメータ・ファイルの詳細は、第2章「Oracle Databaseの作成および構成」を参照してください。

初期化パラメータ・ファイルおよび起動の概要

データベース・インスタンスを起動すると、データベースは、プラットフォーム固有のデフォルトの場所にあるSPFILEから初期化パラメータの読込みを試行します。SPFILEが見つからない場合は、テキスト形式の初期化パラメータ・ファイルを検索します。

表2-3に、PFILEおよびSPFILEのデフォルトの名前と場所を示します。

プラットフォーム固有のデフォルトの場所では、Oracle Databaseは次の順序でファイル名を検査し、初期化パラメータ・ファイルを検索します。

1. spfileORACLE_SID.ora

2. spfile.ora

3. initORACLE_SID.ora

最初の2つのファイルはSPFILEであり、3つ目はテキスト形式の初期化パラメータ・ファイルです。DBCAによってOracle Automatic Storage Managementディスク・グループにSPFILEが作成されている場合、データベースではそのディスク・グループ内のSPFILEが検索されます。

注意:
spfile.oraファイルがこの検索パスに含まれているのは、Oracle Real Application Clusters環境では、すべてのインスタンスの初期化パラメータ設定が1つのサーバー・パラメータ・ファイルに格納されるためです。サーバー・パラメータ・ファイルにはインスタンス固有の格納場所はありません。
Oracle Real Application Clusters環境のサーバー・パラメータ・ファイルの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

ユーザー(またはDatabase Configuration Assistant)が作成したサーバー・パラメータ・ファイルをテキスト形式の初期化パラメータ・ファイルで上書きする場合は、SQL*Plusを使用してSTARTUPコマンドのPFILE句を指定すると、その初期化パラメータ・ファイルを識別できます。

STARTUP PFILE = /u01/oracle/dbs/init.ora

デフォルト以外のサーバー・パラメータ・ファイル: デフォルト以外のサーバー・パラメータ・ファイル(SPFILE)とは、デフォルトの場所以外の場所に存在するSPFILEです。通常は、インスタンスをデフォルト以外のSPFILEで起動する必要はありません。ただし、そうする必要がある場合は、SRVCTL (Oracle Restartを使用)およびSQL*Plusのいずれでも実行できます。これらについては、この項で後ほど説明します。

初期化ファイルとOracle Automatic Storage Management: 通常、Oracle Automatic Storage Management(Oracle ASM)を使用しているデータベースには、デフォルト以外のSPFILEがあります。Database Configuration Assistant(DBCA)を使用してOracle ASMを使用するようにデータベースを構成すると、DBCAによってOracle ASMディスク・グループ内にデータベース・インスタンスのSPFILEが作成され、ローカル・ファイル・システム内のデフォルトの場所に、そのSPFILEを指し示すテキスト形式の初期化パラメータ・ファイル(PFILE)が作成されます(次の項を参照)。

デフォルト以外のサーバー・パラメータ・ファイルを使用したSQL*Plusでの起動

SQL*Plusでは、PFILE句を使用して、デフォルト以外のサーバー・パラメータ・ファイルでインスタンスを起動できます。

SQL*Plusでデフォルト以外のサーバー・パラメータ・ファイルを使用して起動する方法は次のとおりです。

1. SPFILEパラメータのみを記述した1行のテキスト形式の初期化パラメータ・ファイルを作成します。パラメータの値には、デフォルト以外のサーバー・パラメータ・ファイルの場所を指定します。
たとえば、次のパラメータのみを記述したテキスト形式の初期化パラメータ・ファイル/u01/oracle/dbs/spf_init.oraを作成します。

SPFILE = /u01/oracle/dbs/test_spfile.ora

注意:
従来のテキスト形式の初期化パラメータ・ファイルで、サーバー・パラメータ・ファイルを設定するためにIFILE初期化パラメータを使用することはできません。この場合は、必ずSPFILE初期化パラメータを使用してください。

2. この初期化パラメータ・ファイルを指定して、インスタンスを起動します。

STARTUP PFILE = /u01/oracle/dbs/spf_init.ora

SPFILEはデータベース・ホスト・コンピュータに存在している必要があります。したがって、前述の方法は、クライアント・システムからSPFILEを使用するデータベースを起動する手段にもなります。また、クライアント・システムがクライアント側で初期化パラメータ・ファイルを維持する必要もなくなります。クライアント・システムがSPFILEパラメータが含まれている初期化パラメータ・ファイルを読み込むと、その値をサーバーに渡し、そこで指定されたSPFILEが読み込まれます。

デフォルト以外のサーバー・パラメータ・ファイルを使用したSRVCTLでの起動

データベースがOracle Restartで管理されている場合は、データベースのOracle Restart構成でSPFILEの場所オプションを設定または変更することにより、デフォルト以外のSPFILEの場所を指定できます。

SRVCTLでデフォルト以外のサーバー・パラメータ・ファイルを使用して起動する方法は次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のコマンドを入力します。

srvctl modify database -d db_unique_name -p spfile_path

db_unique_nameは、データベースのDB_UNIQUE_NAME初期化パラメータの設定と一致している必要があります。

3. 次のコマンドを入力します。

srvctl start database -d db_unique_name [options]

詳細は、「Oracle RestartのSRVCTLコマンド・リファレンス」を参照してください。

データベース・サービスの自動起動の概要

データベースがOracle Restartで管理されている場合は、個々のデータベース・サービス(サービス)ごとに起動オプションを構成できます。サービスの管理ポリシーをAUTOMATIC(デフォルト)に設定した場合は、SRVCTLを使用してデータベースを起動するとサービスが自動的に起動します。管理ポリシーをMANUALに設定した場合、サービスは自動起動されず、SRVCTLを使用して手動で起動する必要があります。MANUALを設定しても、サービスは実行中にOracle Restartで監視され、障害が発生すると再起動されます。

データベースがOracle Restartで管理されているOracle Data Guard(Data Guard)環境では、Oracle Restart構成でサービスにData Guardロールを割り当てることにより、サービスの自動起動をさらに制御できます。サービスの管理ポリシーがAUTOMATICであり、割り当てられているいずれかのロールがデータベースの現行のロールに一致する場合にのみ、手動でデータベースを起動するとサービスが自動的に起動されます。

サービスに対してData Guardロールの管理ポリシーを設定する構文は、「srvctl add service」および「srvctl modify service」を参照してください。

注意:
Oracle Restartを使用する場合は、SRVCTLを使用してデータベース・サービスを作成することをお薦めします。

インスタンス起動の準備

注意:
次の手順は、Oracle Restartを使用していないインストール用です。データベースをOracle Restartで管理している場合は、「Oracle Restartで管理されているコンポーネントの起動と停止」の手順に従ってください。

SQL*Plusを使用してデータベース・インスタンスを起動する前に、次の準備手順を実行する必要があります。

1. データベースが依存するOracleコンポーネントが起動されたことを確認します。
たとえば、データベースのデータがOracle Automatic Storage Management(Oracle ASM)のディスク・グループに格納される場合は、Oracle ASMインスタンスが実行中であること、および必要なディスク・グループがマウントされていることを確認してください。また、データベースが起動する前にOracle Netリスナーを起動することをお薦めします。

2. オペレーティング・システム認証を使用する場合は、OSDBAグループのメンバーとしてデータベース・ホスト・コンピュータにログインします。
詳細は、「オペレーティング・システム認証の使用」を参照してください。

3. 環境変数が目的のOracleインスタンスに接続するように設定されていることを確認します。詳細は、「データベースに対するコマンドとSQLの発行」を参照してください。

4. データベースに接続せずに、SQL*Plusを起動します。

SQLPLUS /NOLOG

5. SYSDBAとしてOracle Databaseに接続します。

CONNECT username AS SYSDBA

—or—

CONNECT / AS SYSDBA

データベースに接続され、データベース・インスタンスを起動する準備が完了します。

関連項目:
CONNECT、STARTUPおよびSHUTDOWNコマンドの説明と構文は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

インスタンスの起動

Oracle Restartを使用していない場合は、SQL*PlusのSTARTUPコマンドを使用してOracle Databaseインスタンスを起動します。Oracle Restartでデータベースを管理している場合は、srvctl start databaseコマンドを使用することをお薦めします。

いずれの場合も、次のような様々なモードでインスタンスを起動できます。

- NOMOUNT: データベースをマウントせずにインスタンスを起動します。この場合、データベースへのアクセスは禁止され、通常はデータベース作成または制御ファイルの再作成時にのみ使用されます。

- MOUNT: インスタンスを起動し、データベースをマウントするが、クローズしたままにするモード。この状態では、一部のDBAアクティビティは可能ですが、データベースへの汎用アクセスはできません。

- OPEN: インスタンスを起動し、データベースをマウントしてオープンするモード。この操作を非制限モードで実行してユーザー全員にアクセスを許可するか、制限モードで実行してDBAのみにアクセスを許可できます。

- FORCE: 起動時または停止時に問題が発生した後にインスタンスを強制的に起動するモード。

- OPEN RECOVER: インスタンスを起動し、直後に完全メディア・リカバリを開始するモード。

注意:
共有サーバー・プロセスを介してデータベースに接続してデータベースのインスタンスを起動することはできません。

次の例では、DBAがインスタンスを起動できるいくつかの状態を具体的に説明します。STARTUPコマンドの句の結合時やsrvctl start databaseコマンドの起動オプションの結合時は、いくつかの制限が適用されます。

注意:
制御ファイル、データベース・ファイルまたはREDOログ・ファイルが使用できない場合は、インスタンスの起動で問題が発生することがあります。データベースをマウントするときにCONTROL_FILES初期化パラメータで指定された1つ以上のファイルが存在しない場合、またはオープンできない場合は、Oracle Databaseによって警告メッセージが返され、データベースはマウントされません。 データベースをオープンするときに、1つ以上のデータファイルまたはREDOログ・ファイルを使用できない場合、またはオープンできない場合、データベースは警告メッセージを返し、データベースをオープンしません。

関連項目:

- STARTUPコマンドの構文の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

- Oracle Restartで管理されるデータベースの起動手順は、「Oracle Restartで管理されているコンポーネントの起動と停止」を参照してください。

インスタンスを起動し、データベースをマウントしてオープンする方法

通常のデータベース操作とは、インスタンスを起動し、データベースをマウントおよびオープンすることを意味します。このモードでは、有効なユーザーがデータベースに接続して、データ・アクセス操作を実行できます。

次のコマンドは、インスタンスを起動し、デフォルトの場所から初期化パラメータを読み込んで、データベースをマウントおよびオープンします。

SQL*Plus

SRVCTL(Oracle Restartを使用している場合)

STARTUP

srvctl start database -d db_unique_name

db_unique_nameはDB_UNIQUE_NAME初期化パラメータと一致します。

インスタンスを起動するが、データベースをマウントしない方法

インスタンスは、データベースをマウントしなくても起動できます。通常、この方法で起動するのはデータベースの作成時のみです。次のコマンドのいずれかを使用します。

SQL*Plus

SRVCTL(Oracle Restartを使用している場合)

STARTUP NOMOUNT

srvctl start database -d db_unique_name -o nomount

インスタンスを起動し、データベースをマウントする方法

インスタンスを起動し、データベースをオープンしないでマウントして、特定のメンテナンス操作を実行できます。たとえば、次のようなタスクの実行時は、データベースのマウントは必要ですが、オープンはしないでください。

- REDOログ・アーカイブ・オプションの有効化および無効化。詳細は、第13章「アーカイブREDOログの管理」を参照してください。

- 全データベース・リカバリの実行。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

次のコマンドは、インスタンスを起動してデータベースをマウントしますが、データベースはクローズしたままです。

SQL*Plus

SRVCTL(Oracle Restartを使用している場合)

STARTUP MOUNT

srvctl start database -d db_unique_name -o mount

起動時にインスタンスへのアクセスを制限する方法

インスタンスの使用を管理担当者にのみ許可し、一般データベース・ユーザーの使用を禁止するには、制限モードでインスタンスを起動して、オプションでデータベースをマウントおよびオープンします。次のいずれかのタスクを実行する必要があるときは、このインスタンス起動モードを使用してください。

- データのエクスポートまたはインポートを実行する場合

- SQL*Loaderを使用してデータをロードする場合

- 一時的に一般ユーザーがデータを使用できないようにする場合

- 特定の移行またはアップグレード操作を実行する場合

通常、CREATE SESSIONシステム権限を持つすべてのユーザーが、オープンしているデータベースに接続できます。データベースを制限モードでオープンすると、CREATE SESSIONおよびRESTRICTED SESSIONシステム権限の両方を持つユーザーのみがデータベースへのアクセスを許可されます。データベース管理者のみにRESTRICTED SESSIONシステム権限が付与されている必要があります。さらに、インスタンスが制限モードの場合、データベース管理者はOracle Netリスナーからリモートでインスタンスにアクセスすることはできませんが、インスタンスが実行されているシステムからローカルでインスタンスにアクセスすることのみ可能です。

次のコマンドは、制限モードでインスタンスを起動します(データベースをマウントしてオープンします)。

SQL*Plus

SRVCTL(Oracle Restartを使用している場合)

STARTUP RESTRICT

srvctl start database -d db_unique_name -o restrict

MOUNT、NOMOUNTおよびOPENモードと制限モードを組み合せて使用できます。

RESTRICTED SESSION機能を無効にするには、ALTER SYSTEM文を使用します。

ALTER SYSTEM DISABLE RESTRICTED SESSION;

データベースを非制限モードでオープンし、後でアクセス制限が必要であると判明した場合は、ALTER SYSTEM文を使用して制限できます。詳細は、「オープンしているデータベースへのアクセスを制限する方法」を参照してください。

関連項目:
ALTER SYSTEM文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

インスタンスを強制的に起動する方法

通常と異なる状況では、データベース・インスタンスを起動しようとしたときに、問題が発生することがあります。次の問題が発生している場合以外は、データベースを強制的に起動しないでください。

- 現行インスタンスをSHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALコマンドで停止できない場合

- インスタンス起動時に問題が発生した場合。

このような問題が発生した場合、次のいずれかのコマンドを指定して新しいインスタンスを起動(必要に応じて、データベースをマウントおよびオープン)すると、通常は問題を解決できます。

SQL*Plus

SRVCTL(Oracle Restartを使用している場合)

STARTUP FORCE

srvctl start database -d db_unique_name -o force

インスタンスの実行中にFORCEモードを使用すると、ABORTモードでインスタンスを停止した後に再起動します。この場合、メッセージ「インスタンス"abort"の停止中」に続いて「ORACLEインスタンス"normal"の起動中」がアラート・ログに表示されます。

関連項目:
現行インスタンスの強制終了による影響の詳細は、「ABORTモードによる停止」を参照してください。

インスタンスを起動し、データベースをマウントして、完全メディア・リカバリを開始する方法

メディア・リカバリが必要な場合は、次のいずれかのコマンドを使用すると、インスタンスを起動し、データベースをインスタンスにマウントして、リカバリ処理を自動的に開始できます。

SQL*Plus

SRVCTL(Oracle Restartを使用している場合)

STARTUP OPEN RECOVER

srvctl start database -d db_unique_name -o "open,recover"

必要ない場合にリカバリを実行しようとすると、Oracle Databaseによってエラー・メッセージが表示されます。

オペレーティング・システム起動時にデータベースを自動的に起動する方法

多くのサイトでは、システムの起動直後に1つ以上のOracle Databaseインスタンスとデータベースを自動的に起動する手順を使用しています。そのための手順は、オペレーティング・システムによって異なります。自動起動の詳細は、オペレーティング・システム固有のOracleマニュアルを参照してください。

Oracle Database 11g リリース2以降で、データベースの自動起動を構成する方法としてお薦めする(およびプラットフォームに依存しない)方法は、Oracle Restartです。詳細は、第4章「Oracle Databaseの自動再起動の構成」を参照してください。

リモート・インスタンスを起動する方法

ローカルのOracle Databaseサーバーが分散データベースの一部を構成している場合は、リモート・インスタンスとデータベースを起動できます。リモート・インスタンスの起動と停止の手順は、通信プロトコルとオペレーティング・システムによって大きく異なります。

データベースの可用性の変更

データベースの可用性を変更できます。可用性の変更は、メンテナンス上の理由やデータベースを読取り専用にするために行う場合があります。次の各項では、データベースの可用性を変更する方法について説明します。

- インスタンスにデータベースをマウントする方法

- クローズしているデータベースをオープンする方法

- データベースを読取り専用モードでオープンする方法

- オープンしているデータベースへのアクセスを制限する方法

インスタンスにデータベースをマウントする方法

特定の管理操作を実行する場合は、データベースを起動してインスタンスにマウントし、クローズしたままにする必要があります。そのためには、インスタンスを起動してデータベースをマウントします。

あらかじめ起動したインスタンスにデータベースをマウントするには、次のように、SQL文ALTER DATABASEでMOUNT句を指定します。

ALTER DATABASE MOUNT;

関連項目:
データベースをマウントし、クローズしておくことが必要な操作(およびインスタンスの起動とデータベースのマウントを一度に実行する手順)の詳細は、「インスタンスを起動し、データベースをマウントする方法」を参照してください。

クローズしているデータベースをオープンする方法

データベースをオープンすることによって、マウントされ、クローズしているデータベースを一般的な用途のために使用可能にできます。マウントされたデータベースをオープンするには、ALTER DATABASE SQL文でOPEN句を使用します。

ALTER DATABASE OPEN;

この文の実行後は、CREATE SESSIONシステム権限を持つ有効なOracle Databaseユーザーであれば、誰でもデータベースに接続できます。

データベースを読取り専用モードでオープンする方法

データベースを読取り専用モードでオープンすると、オープンしたデータベースを問い合せることができますが、その間にデータの内容がオンラインで変更されることはありません。これにより、データファイルとREDOログ・ファイルにデータが書き込まれないことが保証されますが、データベース・リカバリや、REDOを生成せずにデータベースの状態を変更する操作が制限されることはありません。たとえば、データファイルをオフラインとオンラインの間で切り替えてもデータの内容には影響しないため、このような切替えは可能です。

ディスク・ソートの実行時など、読取り専用モードでデータベースを問い合せるときに一時表領域を使用する場合、問合せの発行者には、デフォルト一時表領域としてローカル管理表領域が割り当てられている必要があります。割り当てられていない場合は、問合せが失敗します。詳細は、「ローカル管理の一時表領域の作成」を参照してください。

次の文では、データベースが読取り専用モードでオープンします。

ALTER DATABASE OPEN READ ONLY;

また、次のように読取り/書込みモードでデータベースをオープンすることもできます。

ALTER DATABASE OPEN READ WRITE;

ただし、読取り/書込みはデフォルトのモードです。

注意:
RESETLOGS句とREAD ONLY句は併用できません。

読取り専用データベースの制約

- 読取り専用データベースに対してアプリケーションを実行中は、データベース・オブジェクトへ書き込まないでください。たとえば、アプリケーションは、グローバルな一時表を含むデータベース表に対して行の挿入、削除、更新またはマージを実行する際に、データベース・オブジェクトに書き込みます。アプリケーションは、データベースの順序を操作する際にデータベース・オブジェクトに書き込みます。また、アプリケーションは行のロック、EXPLAIN PLANの実行またはDDLの実行の際にデータベース・オブジェクトに書き込みます。オラクル社が提供するPL/SQLパッケージのファンクションとプロシージャの多くは(DBMS_SCHEDULERなど)、データベース・オブジェクトに書き込みます。アプリケーションがこれらのファンクションとプロシージャのいずれかをコールする場合、または前述の操作のいずれかを実行する場合、アプリケーションからデータベース・オブジェクトへ書込みが実行されるため、読取り専用ではありません。

- 読取り専用データベースで実行する場合は、1つのデータベース・リンクを使用する進行中のトランザクションをコミットまたはロールバックしてから、別のデータベース・リンクを使用する必要があります。これは、最初のデータベース・リンクで汎用的なSELECT文を実行し、トランザクションが現在読取り専用である場合も当てはまります。

- 読取り専用データベースではPL/SQLストアド・プロシージャをコンパイルまたは再コンパイルできません。リモート・プロシージャ・コールが原因のPL/SQLの無効化を最小限に抑えるには、読取り専用データベースに対してリモート・プロシージャ・コールを実行するセッションではREMOTE_DEPENDENCIES_MODE=SIGNATUREを使用します。

- 読取り専用データベースで一度もコールされたことがないリモート・プロシージャ(読取り専用のリモート・プロシージャであっても)は、そのデータベースから起動できません。この制約は、無名PL/SQLブロックの中およびSQL文の中のリモート・プロシージャ・コールに当てはまります。ストアド・プロシージャ内にリモート・プロシージャ・コールを指定するか、またはデータベース内のリモート・プロシージャを読取り専用にする前に起動できます。

関連項目:
ALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

オープンしているデータベースへのアクセスを制限する方法

すでに実行中のインスタンスを制限モードにするには、SQL文のALTER SYSTEMでENABLE RESTRICTED SESSION句を指定します。この文が正常に完了した後は、RESTRICTED SESSION権限を持っているユーザーのみが新しい接続を開始できます。SYSDBAとして接続するユーザー、またはDBAロールを使用して接続するユーザーにはこの権限があります。

実行中インスタンスを制限モードにすると、ユーザー・セッションは終了されないか、終了された場合は影響を受けます。したがって、インスタンスを制限モードにした場合は、管理タスクを実行する前に現行のユーザー・セッションをすべて停止(終了)することを考慮します。

インスタンスの制限モードを解除するには、ALTER SYSTEMでDISABLE RESTRICTED SESSION句を指定します。

関連項目:

- ユーザー・セッションを停止する方法は、「セッションの停止」を参照してください。

- インスタンスを制限モードにする理由は、「起動時にインスタンスへのアクセスを制限する方法」を参照してください。

データベースの停止

Oracle Restartを使用していない場合、データベース・インスタンスを停止するには、SQL*PlusでSYSOPERまたはSYSDBAとして接続し、SHUTDOWNコマンドを発行します。Oracle Restartでデータベースを管理している場合は、srvctl stop databaseコマンドを使用してデータベースを停止する方法をお薦めします。

停止処理が完了するまで、データベース停止を開始したセッションに制御が戻されません。停止処理の進行中に接続しようとするユーザーは、次のようなメッセージを受け取ります。

ORA-01090: shutdown in progress - connection is not permitted

注意:
共有サーバー・プロセスを介してデータベースに接続している場合は、データベースを停止できません。

データベースには、複数の停止モード(NORMAL、IMMEDIATE、TRANSACTIONALおよびABORT)があります。一部の停止モードでは、データベースを実際に停止する前に、特定のイベント(トランザクションの完了またはユーザーによる切断など)の発生を待機します。これらのイベントに対するタイムアウト間隔は1時間です。

詳細は、次の項を参照してください。

- NORMALモードによる停止

- IMMEDIATEモードによる停止

- TRANSACTIONALモードによる停止

- ABORTモードによる停止

- 停止のタイムアウト

関連項目:
Oracle Restartの詳細は、第4章「Oracle Databaseの自動再起動の構成」を参照してください。

NORMALモードによる停止

データベースを通常の状況で停止するには、次のいずれかのコマンドを使用します。

SQL*Plus

SRVCTL(Oracle Restartを使用している場合)

SHUTDOWN [NORMAL]

srvctl stop database -d db_unique_name -o normal

SQL*Plus SHUTDOWNコマンドのNORMAL句はオプションです(これがデフォルトの停止方法であるため)。SRVCTLの場合、-oオプションを省略すると、停止操作はデータベースのOracle Restart構成に格納されている停止オプションに従って進行します。デフォルトの停止オプションはIMMEDIATEです。

通常のデータベース停止では、次のように処理が進みます。

- 文が発行された後は、新しい接続は許可されません。

- データベースは、停止する前に、現在データベースに接続しているすべてのユーザーによるデータベースからの切断を待機します。

次にデータベースを起動するときに、インスタンス・リカバリ手順は必要ありません。

IMMEDIATEモードによる停止

データベースの即時停止は、次のような状況のときにのみ使用します。

- 自動バックアップおよび無人バックアップを開始する場合

- 電源が間もなく停止する場合

- データベースやデータベース・アプリケーションの一部が異常に動作している場合で、ユーザーにログオフを依頼できない場合、またはユーザーがログオフできない場合

データベースを即時に停止するには、次のいずれかのコマンドを使用します。

SQL*Plus

SRVCTL(Oracle Restartを使用している場合)

SHUTDOWN IMMEDIATE

srvctl stop database -d db_unique_name -o immediate

このデータベース停止では、次のように処理が進みます。

- 文が発行されると、新しい接続は許可されず、新しいトランザクションは開始できません。

- すべての未コミットのトランザクションは、ロールバックされます。(長くかかる未コミットのトランザクションが存在する場合、この停止方法ではその名前に反して即座に終了しない場合があります。)

- Oracle Databaseは、現在データベースに接続しているユーザーが切断されるのを待機しません。アクティブなトランザクションは暗黙的にロールバックされ、接続中のユーザーはすべて切断されます。

次にデータベースを起動するときに、インスタンス・リカバリ手順は必要ありません。

TRANSACTIONALモードによる停止

アクティブ・トランザクションを完了してから、計画どおりにインスタンスを停止する場合は、次のいずれかのコマンドを使用します。

SQL*Plus

SRVCTL(Oracle Restartを使用している場合)

SHUTDOWN TRANSACTIONAL

srvctl stop database -d db_unique_name -o transactional

このデータベース停止では、次のように処理が進みます。

- 文が発行されると、新しい接続は許可されず、新しいトランザクションは開始できません。

- すべてのトランザクションが完了すると、まだインスタンスに接続されているすべてのクライアントが切断されます。

- この時点で、インスタンスはSHUTDOWN IMMEDIATE文を発行した場合と同じように停止します。

次にデータベースを起動するときに、インスタンス・リカバリ手順は必要ありません。

TRANSACTIONALオプションによる停止では、クライアントの作業内容が失われずに済み、すべてのユーザーがログオフする必要がなくなります。

ABORTモードによる停止

データベース・インスタンスを強制終了することによって、データベースをただちに停止できます。この停止方法は、次の場合を除いてできるだけ使用を避けてください。

データベース、もしくはそのアプリケーションの1つが不適切に機能していて、かつ他のいずれの停止モードも作動しない場合。

- データベースをただちに停止する必要がある(たとえば、電源遮断が1分以内に発生することがわかっている)場合。

- データベース・インスタンスを起動するときに問題が発生した場合。

トランザクションとユーザーの接続を強制終了してデータベースを停止する必要がある場合は、次のいずれかのコマンドを使用します。

SQL*Plus

SRVCTL(Oracle Restartを使用している場合)

SHUTDOWN ABORT

srvctl stop database -d db_unique_name -o abort

このデータベース停止では、次のように処理が進みます。

- 文が発行されると、新しい接続は許可されず、新しいトランザクションは開始できません。

- Oracle Databaseによって処理されている現行のクライアントSQL文はただちに終了します。

- コミットされていないトランザクションはロールバックされません。

- Oracle Databaseは、現在データベースに接続しているユーザーが切断されるのを待機しません。接続中のユーザーはすべて暗黙的に切断されます。

次にデータベースを起動するときに、自動インスタンス・リカバリ手順が必要になります。

停止のタイムアウト

ユーザーによる切断またはトランザクションの完了を待機する停止モードには、待機時間に制限があります。停止をブロックするすべてのイベントが1時間以内に発生しない場合、停止操作は「ORA-01013: ユーザーによって現行の操作の取消しがリクエストされました」というメッセージを表示して強制終了されます。また、このメッセージは停止プロセスを中断した場合(たとえばCTRL-Cを押した場合など)にも表示されます。インスタンスの停止を中断しようとしないことをお薦めします。停止プロセスが完了してから、インスタンスを再起動してください。

ORA-01013が発生した後は、インスタンスが予測できない状態になると考える必要があります。このため、SHUTDOWNコマンドを再発行して、停止プロセスを継続する必要があります。後続のSHUTDOWNコマンドが引き続き失敗する場合は、SHUTDOWN ABORTコマンドを発行してインスタンスを停止する必要があります。その後でインスタンスを再起動できます。

データベースの静止

データベースを、DBAによるトランザクション、問合せ、フェッチまたはPL/SQL文の実行のみ許可された状態にすることが必要な場合があります。このような状態は、システム上でDBA以外によるトランザクション、問合せ、フェッチまたはPL/SQL文が実行されていないという意味で、静止状態と呼びます。

注意:
静止中のデータベースに関するこの項の説明では、DBAがユーザーSYSまたはSYSTEMとして定義されています。DBAロールを持つユーザーなどの他のユーザーには、ALTER SYSTEM QUIESCE DATABASE文の発行や、データベース静止後の処理の継続は許可されていません。

データベースを静止状態にすることで、管理者は、それ以外の状態では安全に実行できない処理を実行できます。次の処理を実行できます。

- 同時ユーザー・トランザクションが同じオブジェクトにアクセスした場合に失敗する処理。たとえば、データベース表のスキーマの変更や、NOWAITロックが必要な既存表への列の追加などがこれに該当します。

- 同時ユーザー・トランザクションによって好ましくない中間影響を受けるアクション、たとえば表を最初にエクスポートしてから削除し、最後にインポートする場合のような、複数の手順からなる表の再編成処理など。表が削除された後であっても、インポートされる前に同時ユーザーが表にアクセスしようとすると、状況を正確に認識できません。

データベースの静止機能がない場合は、データベースを停止し、制限モードで再度オープンする必要があります。これは、特に24時間、365日の可用性が必要なシステムにとっては重大な制限です。データベースの静止によって、ユーザーに対する遮断とデータベースの停止と再起動に伴う停止時間を最小限にできるため、制限が大幅に緩和されます。

データベースが静止中の場合、DBA以外のセッションがアクティブにならないようにするために、データベース・リソース・マネージャの機能が使用されています。したがって、この文が有効な間に現行のリソース・プランを変更しようとすると、その処理はシステムが静止解除されるまでキューに待機します。データベース・リソース・マネージャの詳細は、第27章「Oracle Database Resource Managerを使用したリソースの管理」を参照してください。

データベースの静止状態への変更

データベースを静止状態にするには、次のSQL文を発行します。

ALTER SYSTEM QUIESCE RESTRICTED;

DBA以外のアクティブなセッションは、非アクティブになるまで処理が継続されます。アクティブなセッションとは、トランザクション、問合せ、フェッチまたはPL/SQL文を現在実行しているセッション、または現在なんらかの共有リソース(エンキューなど)を保持しているセッションです。非アクティブなセッションがアクティブになることはできません。たとえば、ユーザーが非アクティブなセッションを強制的にアクティブにしようとしてSQL問合せを発行すると、その問合せは停止したようになります。後でデータベースが静止解除されると、セッションが再開され、ブロックされていた処理が実行されます。

DBA以外のセッションがすべて非アクティブになると、ALTER SYSTEM QUIESCE RESTRICTED文が完了し、データベースは静止状態となります。Oracle Real Application Clusters環境でこの文を発行すると、文を発行したインスタンスだけでなく、すべてのインスタンスが影響を受けます。

ALTER SYSTEM QUIESCE RESTRICTED文は、アクティブなセッションが非アクティブになるまで、長時間待機する場合があります。V$BLOCKING_QUIESCEビューを問い合せると、静止操作をブロックしているセッションを判別できます。このビューでは、1つの列SID(セッションID)のみが返されます。これをV$SESSIONと結合すると、次の例のように、セッションに関する詳細を取得できます。

select bl.sid, user, osuser, type, program
from v$blocking_quiesce bl, v$session se
where bl.sid = se.sid;

これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベース静止の要求を中断した場合、またはアクティブなセッションがすべて静止する前にセッションが異常終了した場合は、Oracle Databaseによって、この文による部分的な影響がすべて自動的に取り消されます。

複数のOracle Call Interface (OCI)の連続したフェッチによって問合せが実行されている場合、ALTER SYSTEM QUIESCE RESTRICTED文はすべてのフェッチが完了するまで待機しません。現行のフェッチの完了のみを待機します。

専用サーバー接続の場合も、共有サーバー接続の場合も、この文の発行後、DBA以外のユーザーがログインしようとすると、その処理はデータベース・リソース・マネージャによってすべてキューに送られ、進行しません。ユーザーにはログインが停止したように見えます。データベースが静止解除されると、ログインは再開されます。

文を発行したセッションが終了しても、データベースは静止状態のままです。DBAは、データベースを静止解除される文を明示的に発行するために、データベースにログインする必要があります。

注意:
データベースが静止状態の場合でも、Oracle Databaseのバックグラウンド・プロセスが内部の目的のために更新を実行している可能性があるため、データベースが静止状態の場合はコールド・バックアップを実行できません。また、オンライン・データファイルのヘッダーは引き続きアクセス可能に見えます。このファイル・ヘッダーの状態は、データベースが正しく停止された場合とは異なります。ただし、データベースが静止状態の間でも、オンライン・バックアップ操作は実行できます。

通常操作へのシステムのリストア

次の文は、データベースを通常の操作にリストアさせます。

ALTER SYSTEM UNQUIESCE;

DBA以外のアクティビティの処理がすべて許可されます。Oracle Real Application Clusters環境では、データベースを静止した場合と同じセッションまたは同じインスタンスでこの文を発行する必要はありません。ALTER SYSTEM UNQUIESCE文を発行したセッションが異常終了した場合、Oracle Databaseサーバーは静止解除を確実に完了します。

インスタンスの静止状態の表示

V$INSTANCEビューのACTIVE_STATE列を問い合せると、インスタンスの現在の状態を表示できます。列の値は、次のいずれかになります。

- NORMAL: 通常の静止していない状態。

- QUIESCING: 静止途中の状態。DBA以外の一部のセッションがアクティブな状態です。

- QUIESCED: 静止状態。DBA以外のセッションは非アクティブで、許可されていない状態です。

データベースの一時停止と再開

ALTER SYSTEM SUSPEND文は、データファイル(ファイル・ヘッダーとファイル・データ)および制御ファイルへの入出力(I/O)をすべて停止します。一時停止状態によって、I/Oに干渉されずにデータベースのバックアップを作成できます。データベースを一時停止すると、実行中のすべてのI/O操作の完了が許可され、新しいデータベース・アクセスはキューに待機した状態になります。

SUSPENDコマンドは、インスタンスに固有ではありません。Oracle Real Application Clusters環境では、あるシステムでSUSPENDコマンドを発行すると、内部ロッキング・メカニズムを通じてインスタンス間で停止要求が伝播し、特定のクラスタのアクティブ・インスタンスがすべて停止します。ただし、あるインスタンスの一時停止中に新しいインスタンスを起動すると、新しいインスタンスは一時停止されません。

通常のデータベース操作を再開するには、ALTER SYSTEM RESUME文を使用します。SUSPENDコマンドとRESUMEコマンドは、異なるインスタンスから発行できます。たとえば、インスタンス1、2および3の実行中に、インスタンス1からALTER SYSTEM SUSPEND文を発行した場合は、インスタンス1、2または3から同様にRESUME文を発行できます。

一時停止/再開機能は、ディスクやファイルをミラー化してそのミラーを分割できるシステムで役立ち、バックアップとリストアの代替ソリューションを提供します。書込み中に既存のデータベースからミラー化されたディスクを分割できないシステムを使用している場合は、この一時停止/再開機能を使用すると容易に分割できます。

一時停止したデータベースのコピーにはコミット前の更新が含まれるため、一時停止/再開機能は通常の停止操作の簡易版ではありません。

注意:
表領域をホット・バックアップ・モードに設定する代替手段としてALTER SYSTEM SUSPEND文を使用しないでください。データベースの一時停止操作ではなく、ALTER TABLESPACE BEGIN BACKUP文を使用してください。

次の文は、ALTER SYSTEM SUSPEND/RESUMEの使用方法を示しています。データベースの状態を確認するために、V$INSTANCEビューを問い合せています。

SQL> ALTER SYSTEM SUSPEND;
System altered
SQL> SELECT DATABASE_STATUS FROM V$INSTANCE;
DATABASE_STATUS
---------
SUSPENDED

SQL> ALTER SYSTEM RESUME;
System altered
SQL> SELECT DATABASE_STATUS FROM V$INSTANCE;
DATABASE_STATUS
---------
ACTIVE

関連項目:
データベースの一時停止/再開機能を使用してデータベースをバックアップする方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

4 Oracle Databaseの自動再起動の構成

Oracle Restart機能を使用してOracle Databaseを構成すると、ハードウェアまたはソフトウェアに障害が発生した後やデータベース・ホスト・コンピュータが再起動した場合は常に、データベース、リスナーおよびその他のOracleコンポーネントを自動的に再起動できます。

この章の内容は、次のとおりです。

- Oracle Restartの理解

- Oracle Restartの構成

- Oracle Restartで管理されているコンポーネントの起動と停止

- メンテナンス操作のためのOracle Restartの停止および再起動

- Oracle RestartのSRVCTLコマンド・リファレンス

- CRSCTLコマンド・リファレンス

Oracle Restartの理解

この項の内容は次のとおりです。

- Oracle Restartの概要

- 起動の依存性の概要

- Oracle Restartを使用した起動と停止の概要

- Oracle Restartの起動と停止の概要

- Oracle Restart構成

- Oracle RestartとOracle Data Guardとの統合

- Oracle Restartとの高速アプリケーション通知

Oracle Restartの概要

Oracle Restartを使用すると、Oracle Databaseの可用性が向上します。Oracle Restartをインストールすると、ハードウェアまたはソフトウェアに障害が発生した後やデータベース・ホスト・コンピュータが再起動した場合は常に、様々なOracleコンポーネントを自動的に再起動できます。表4-1にこれらのコンポーネントを示します。

表4-1 Oracle Restartで自動的に再起動されるOracleコンポーネント

構成要素

注意

データベース・インスタンス

Oracle Restartは1台のホスト・コンピュータで複数のデータベースに対応できます。

Oracle Netリスナー

-

データベース・サービス

インストール時に作成されたデフォルトのサービスは、Oracle Databaseによって自動的に管理されるため、含まれません。また、データベースの作成時に作成されるデフォルトのサービスも含まれません。

Oracle Automatic Storage Management(Oracle ASM)インスタンス

-

Oracle ASMディスク・グループ

ディスク・グループの再起動はディスク・グループのマウントを指します。

Oracle Notification Services(ONS)

スタンドアロン・サーバー環境では、高速アプリケーション通知(FAN)を介したプライマリ・データベースとスタンバイ・データベース間の接続のフェイルオーバーを自動化するために、Oracle Data GuardのインストールでONSを使用できます。ONSは、フェイルオーバーの際にFANイベントを統合されているクライアントに送信するサービスです。

Oracle Restartでは定期的にチェック操作を実行し、前述のコンポーネントの状態を監視します。コンポーネントのチェックが失敗すると、そのコンポーネントは停止され、再起動されます。

Oracle Restartはスタンドアロン・サーバー(非クラスタ化)環境でのみ使用します。Oracle Real Application Clusters(Oracle RAC)環境では、Oracle Clusterwareによってコンポーネントを自動再起動する機能が提供されます。

Oracle Restartは、Oracle Databaseホームとは別にインストールするOracle Grid Infrastructureホームから実行されます。Oracle Gridインフラストラクチャ・ホームのインストールの詳細は、ご使用のプラットフォームの『Oracle Databaseインストレーション・ガイド』を参照してください。

関連項目:

- 「Oracle Restartの構成」

- Oracle Automatic Storage Managementの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

起動の依存性の概要

Oracle Restartでは、Oracleコンポーネントがコンポーネントの依存性に従って正しい順序で起動されます。たとえば、データベース・ファイルがOracle ASMディスク・グループに格納されている場合、データベース・インスタンスの起動前に、Oracle ASMインスタンスが起動されて必要なディスク・グループがマウントされていることが確認されます。同様に、コンポーネントの停止が必要な場合、依存コンポーネントが最初に正常に停止されることが確認されます。

Oracle Restartでは、データベース・インスタンスとOracle Netリスナー(リスナー)の間の弱い依存性も管理されます。データベース・インスタンスが起動される際に、Oracle Restartがリスナーの起動を試みます。リスナーの起動に失敗しても、データベースは引き続き起動されます。後でリスナーに障害が発生した場合、Oracle Restartはデータベース・インスタンスを停止および再起動しません。

Oracle Restartを使用した起動と停止の概要

Oracle Restartでは、必要に応じて様々なOracleコンポーネントを自動的に再起動したり、ユーザーがシステムを手動で停止したとき、Oracleコンポーネントを適切な順序で自動的に停止します。ただし、個別のOracleコンポーネントを手動で起動または停止する場合があります。Oracle Restartには、Oracle Restartで管理されているコンポーネントを手動で開始および停止する場合に使用する、Server Control(SRVCTL)ユーティリティが含まれています。Oracle Restartの使用中は、コンポーネントの開始と停止をSRVCTLを使用して手動で実行することをお薦めします。

SRVCTLを使用してコンポーネントを停止した後は、障害が発生してもそのコンポーネントはOracle Restartで自動再起動されません。SRVCTLを使用してそのコンポーネントを起動すると、そのコンポーネントでは再度自動再起動が利用できます。

SQL*Plus、リスナー制御ユーティリティ(LSNRCTL)、ASMCMDなどのOracleユーティリティはOracle Restartに統合されています。SQL*Plusを使用してデータベースを停止した場合、Oracle Restartではこの操作をデータベース障害とは解釈せず、データベースは再起動されません。同様に、SQL*PlusまたはASMCMDを使用してOracle ASMインスタンスを停止した場合、Oracle Restartで再起動されません。

SRVCTLを使用したコンポーネントの起動とSQL*Plus(または別のユーティリティ)を使用した起動の重大な相違を次に示します。

- SRVCTLを使用してコンポーネントを起動すると、このコンポーネントが依存するコンポーネントが最初に正しい順序で自動起動されます。

- SQL*Plus(または別のユーティリティ)を使用してコンポーネントを起動すると、依存性チェーンの他のコンポーネントは自動起動されません。このコンポーネントが依存するコンポーネントが起動されていることを確認する必要があります。

さらに、Oracle Restartで管理されているすべてのコンポーネントを、指定したOracleホームで1つのコマンドを使用して起動および停止できます。OracleホームはOracle DatabaseホームまたはOracle Gridインフラストラクチャ・ホームです。この機能はパッチのインストール時に役立ちます。

関連項目:
「Oracle Restartで管理されているコンポーネントの起動と停止」

Oracle Restartの起動と停止の概要

CRSCTLユーティリティでは、Oracle Restartを起動および停止します。また、CRSCTLユーティリティを使用して、Oracle高可用性サービスを有効化または無効化できます。Oracle RestartではOracle高可用性サービスを使用して、Oracle Restartで管理されているすべてのコンポーネントを自動的に起動および停止します。たとえば、Oracle高可用性サービス・デーモンでは、データベース、リスナーおよびOracle ASMインスタンスを自動的に起動します。Oracle高可用性サービスを無効にした場合、ノードの再起動時に、Oracle Restartで管理されているコンポーネントは起動されません。

通常、Oracleのインストールで実行されているすべてのOracleソフトウェアを停止する必要がある場合にCRSCTLユーティリティを使用します。たとえば、パッチをインストールするか、オペレーティング・システムのメンテナンスを実行する際にOracle Restartの停止が必要になる場合があります。メンテナンスの完了後、CRSCTLユーティリティを使用してOracle Restartを起動します。

関連項目:
CRSCTLユーティリティの使用方法は、「メンテナンス操作のためのOracle Restartの停止および再起動」を参照してください。

Oracle Restart構成

Oracle Restartでは、管理するすべてのOracleコンポーネントのリストと、各コンポーネントの構成情報を保持します。この情報全体をOracle Restart構成と呼びます。コンポーネントがOracle Restartで起動される場合、そのコンポーネントの構成情報に従って起動されます。たとえば、Oracle Restart構成にはデータベースのサーバー・パラメータ・ファイル(SPFILE)の場所や、リスナーがリスニングするTCPポートなどが含まれています。

Oracle Restartをインストールし、Database Configuration Assistant(DBCA)でデータベースを作成した場合、データベースはDBCAによってOracle Restart構成に自動的に追加されます。DBCAによってデータベースが起動されると、データベースと他のコンポーネント間で必要な依存性(データベースがデータを格納するディスク・グループなど)が確立され、Oracle Restartでのデータベースの管理が開始されます。

SRVCTLコマンドを使用すると、Oracle Restart構成にコンポーネントを手動で追加および削除できます。たとえば、データベースがすでに実行されているホストにOracle Restartをインストールした場合、SRVCTLを使用してそのデータベースをOracle Restart構成に追加できます。コンポーネントを手動でOracle Restart構成に追加してSRVCTLを使用して起動すると、そのコンポーネントはOracle Restartで管理されるようになり、必要に応じて再起動されます。

注意:
Oracle Restart構成へのコンポーネントの追加は、Oracle Restartを使用したコンポーネントの登録とも呼ばれます。

他のSRVCTLコマンドを使用すると、Oracle Restartで管理されているコンポーネントのステータスと構成を表示したり、コンポーネントの管理を一時的に無効にした後再度有効にするなどの操作を実行できます。

Oracle Restartのインストール時、Oracleコンポーネントを作成する多くの操作によりOracle Restart構成にコンポーネントが自動的に追加されます。表4-2に、作成操作、および作成されたコンポーネントが自動的に追加されるかどうかを示します。

表4-2 作成操作とOracle Restart構成

作成操作

作成されたコンポーネントが自動的にOracle Restart構成に追加されるかどうか。

OUIまたはDBCAを使用してデータベースを作成します。

はい

CREATE DATABASE SQL文を使用してデータベースを作成します。

いいえ

OUI、DBCAまたはASMCAを使用してOracle ASMインスタンスを作成します。

はい

ディスク・グループ(メソッド)を作成します。

はい

NETCAを使用してリスナーを追加します。

はい

SRVCTLを使用してデータベース・サービスを作成します。

はい

SERVICE_NAMES初期化パラメータを変更してデータベース・サービスを作成します。脚注1

いいえ

DBMS_SERVICE.CREATE_SERVICEを使用してデータベース・サービスを作成します。

いいえ

スタンバイ・データベースを作成します。

いいえ

脚注1Oracle Restartの使用中はお薦めしません

表4-3に、削除操作と、削除されたコンポーネントがOracle Restart構成からも自動的に削除されるかどうかを示します。

表4-3 削除操作とOracle Restart構成

操作

削除されたコンポーネントがOracle Restart構成から自動的に削除されるかどうか。

DBCAを使用してデータベースを削除します。

はい

オペレーティング・システムのコマンドでデータベース・ファイルを削除し、データベースを削除します。脚注1

いいえ

NETCAを使用してリスナーを削除します。

はい

Oracle ASMディスク・グループを削除します(任意の方法)。

はい

SRVCTLを使用してデータベース・サービスを削除します。

はい

他の方法でデータベース・サービスを削除します。

いいえ

脚注1お薦めしません。

Oracle RestartとOracle Data Guardとの統合

Oracle RestartはOracle Data Guard(Data Guard)およびOracle Data Guard Broker(ブローカ)と統合されています。ロール変更リクエストに対応してデータベースの停止と再起動が必要になった場合、正しい順序で(依存性を考慮して)Oracle Restart構成の設定に従ってデータベースが停止され、再起動されます。Data Guardロールが遷移した後、新しいデータベース・ロールで実行するように構成されているデータベース・サービスがすべてアクティブになっており、新しいロールで実行するように構成されていないサービスがすべて停止していることもOracle Restartによって確認されます。

また、Oracle Restart構成では次のコンポーネントのData Guard関係の構成オプションをサポートします。

- データベース: Oracle Restart構成にデータベースを追加する場合、データベースの現在のData Guardロールを指定できます(PRIMARY、PHYSICAL_STANDBY、LOGICAL_STANDBYまたはSNAPSHOT_STANDBY)。ブローカを使用して後でロールを変更すると、Oracle Restartではデータベースの構成を新しいロールで自動的に更新します。ブローカを使用せずにデータベース・ロールを変更した場合、Oracle Restart構成でデータベースのロールを手動で変更して新しいロールを反映させる必要があります。

- データベース・サービス: データベース・サービスをOracle Restart構成に追加する場合、サービスに1つ以上のData Guardロールを指定できます。この構成オプションが設定された場合、サービス・ロールの1つが現在のデータベース・ロールに一致する場合にのみ、データベースのオープン時にサービスは起動されます。

関連項目:

- Oracle Data Guardの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 「Oracle Restartとの高速アプリケーション通知」

- 「プライマリ・データベースとスタンバイ・データベースの接続のフェイルオーバーの自動化」

Oracle Restartとの高速アプリケーション通知

スタンドアロン・サーバー環境では、高速アプリケーション通知(FAN)の高可用性イベントを公開するために、Oracle RestartでOracle Notification Services(ONS)およびOracleアドバンスト・キューが使用されます。統合されているOracle Clientは、FANを使用して、サービスまたはインスタンスが停止した場合に高速通知をクライアントに提供します。クライアントは、プライマリ・データベースとスタンバイ・データベース間のデータベース接続のフェイルオーバーを自動化できます。

この項では、ONSおよびFANがOracle Restartで動作する方法について説明します。内容は次のとおりです。

- 高速アプリケーション通知の概要

- サービスとFANにおけるアプリケーションの高可用性

- 計画外停止の管理

- 計画停止の管理

- 高速アプリケーション通知の高可用性イベント

- 高速アプリケーション通知のコールアウトの使用

- 高速アプリケーション通知と統合されているOracle Client

関連項目:
『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』

高速アプリケーション通知の概要

FANは、UPイベントやDOWNイベントなどのステータス変更を含めた構成の変更について他のプロセスに通知するためにOracle Restartで使用できる通知メカニズムです。FANには、インスタンスまたはサーバーで障害が発生した場合に、実行中のトランザクションを即座に終了する機能が備えられています。統合されているOracle Clientは、イベントおよび応答を受信します。アプリケーションによる応答は、エラーをユーザーに伝播するか、またはトランザクションを再実行しアプリケーション・ユーザーからエラーをマスクすることによって実行されます。DOWNイベントが発生すると、統合されているクライアントでは、終了されたデータベースへの接続が即座にクリーン・アップされます。UPイベントが発生すると、クライアントでは新しいプライマリ・データベース・インスタンスへの新しい接続が作成されます。

Oracle Restartでは、管理対象のインスタンスまたはサービスが起動または停止するたびに、FANイベントが公開されます。フェイルオーバーの後、Oracle Data Guard Broker(ブローカ)によってFANイベントが公開されます。FANイベントは次の方法で使用できます。

- Oracle Database JDBC、Universal Connection Pool for Java、Oracle Call InterfaceおよびOracle Database ODP.NETのいずれかのOracle統合データベース・クライアントを使用している場合は、プログラムを変更することなくOracle RestartでFANを使用できます。これらのクライアントには、フェイルオーバー後に自動的に新規プライマリ・データベースに接続する高速接続フェイルオーバー(FCF)を構成できます。

- FANのサーバー側コールアウトをデータベース層で構成できます。

プライマリ・データベース障害などのDOWNイベントでは、新しいプライマリ・データベースにできるだけ早くフェイルオーバーできるようにするため、FANからクライアントへの通知が即座に実行されます。クライアントではタイムアウトが発生するまで待機しません。クライアントに対する通知は即座に実行され、クライアントは通知された時点でフェイルオーバーするように構成しておく必要があります。

UPイベントでは、サービスおよびインスタンスが起動されている場合、アプリケーションが追加のリソースを即時に利用できるように、新しい接続を作成できます。

また、サーバー側のコールアウトを介して、FANを使用して次の操作を実行することもできます。

- ステータス情報のログへの記録

- リソースの起動に失敗した場合のDBAの呼出しまたはチケットのオープン

- サービスと同じ場所に配置する必要がある外部依存アプリケーションの自動的な起動

FANイベントの公開には、ONSおよびOracle Streamsアドバンスト・キューイングのキューが使用されます。キューは、サーバーを構成するときに自動的に構成されます。ONSはSRVCTLコマンドを使用して手動で構成する必要があります。

Connection Manager(CMAN)およびOracle Net ServicesのリスナーはFANイベントと統合されているため、CMANおよびリスナーでは、障害が発生したデータベースに対する接続要求が誤って送信されないように、障害が発生したインスタンスによって提供されるサービスを即座に登録解除できます。

関連項目:

- Oracle Data Guard環境におけるFANイベントの詳細は、『Oracle Data Guard Broker』を参照してください。

- クライアントのフェイルオーバーに関するMaximum Availability Architecture(MAA)ホワイト・ペーパー
http://www.oracle.com/technetwork/database/features/availability/maa-090890.html

サービスとFANにおけるアプリケーションの高可用性

Oracle Databaseはサービスの可用性の維持に重点を置いています。Oracle Restartでは、Oracleサービスが常に使用できるように設定されています。Oracle Restartではデータベースおよびそのサービスが監視され、構成時にFANを使用してイベント通知が送信されます。

計画外停止の管理

Oracle Restartでは、停止を検出すると、障害が発生したコンポーネントを孤立させ、依存コンポーネントをリカバリします。障害が発生したコンポーネントがデータベース・インスタンスの場合は、Oracle Data Guardがスタンバイ・データベースにフェイルオーバーした後、新しいプライマリ・データベース上のOracle Restartによって、現在のロールで定義されたサービスが開始されます。

FANイベントは、Oracle RestartおよびOracle Data Guard Brokerによって、ONSとアドバンスト・キューイングを介して公開されます。また、FANコールアウトを使用して通知を実行することもできます。

注意:
Oracle Restartでは、コールアウトの実行順序は保証されません。コールアウトは非同期で実行され、スケジュールは変動します。

Oracle Restartでは、データベースだけでなく、リスナーやOracle Automatic Storage Management (Oracle ASM)プロセスなどのサブシステムの再起動も含めた、再起動およびリカバリが自動的に行われます。FANコールアウトを使用して、障害管理システムに障害を報告して、修復ジョブを起動できます。

計画停止の管理

Oracle Restartには、プライマリ・データベースのシャットダウンが必要となる修復、アップグレードおよび変更向けに、アプリケーション・ユーザーに対するサービス停止を最小限に抑えるための、サービスを無効化および有効化するインタフェースが備えられています。Oracle RestartとともにOracle Data Guard Brokerを使用すると、計画停止の期間中、データベース・サービスがプライマリからスタンバイにフェイルオーバーするように調整できます。処理が完了した後、サービスを通常の動作に戻すことができます。

サービスの管理ポリシーによって、データベースの再起動時にサービスを自動的に開始するかどうかが制御されます。サービスの管理ポリシーをAUTOMATICに設定すると、自動的に再起動されます。サービスの管理ポリシーをMANUALに設定すると、手動で開始する必要があります。

関連項目:
「コンポーネントのOracle Restart構成の変更」

高速アプリケーション通知の高可用性イベント

表4-4に、FANイベント・レコード・パラメータとイベント・タイプに続き、イベント・プロパティの名前と値のペアを示します。イベント・タイプは常に最初のエントリであり、タイムスタンプは常に最後のエントリとなります。次の例では、名前と値のペアの名前はFan event type(service_member)に示され、名前と値のペアの値はPropertiesに示されています。

FAN event type: service_member
Properties: version=1.0 service=ERP database=FINPROD instance=FINPROD host=node1 status=up

表4-4 イベント・レコード・パラメータと説明

パラメータ

説明

VERSION

イベント・レコードのバージョン。リリースの変更を識別するために使用されます。

EVENT TYPE

SERVICE、SERVICE_MEMBER、DATABASE、INSTANCE、NODE、ASM、SRV_PRECONNECT。データベースおよびインスタンス・タイプには、DB_UNIQUE_NAME.DB_DOMAINなどのデータベース・サービスが示されます。

DATABASE UNIQUE NAME

サービスをサポートしている一意のデータベースを示し、DB_UNIQUE_NAME初期化パラメータの値と一致します。このパラメータのデフォルト値は、初期化パラメータDB_NAMEの値です。

INSTANCE

サービスをサポートしているインスタンスの名前であり、ORACLE_SIDの値と一致します。

NODE NAME

サービスをサポートしているノードまたは停止したノードの名前であり、Cluster Synchronization Services(CSS)で認識されるノード名と一致します。

SERVICE

サービス名であり、DBA_SERVICESのサービスと一致します。

STATUS

値は、UP、DOWN、NOT_RESTARTING、PRECONN_UP、PRECONN_DOWNおよびUNKNOWNです。

REASON

Data_Guard_Failover、Failure、Dependency、User、Autostart、Restart。

CARDINALITY

すべてのUPイベントに含まれている、現在アクティブなサービス・メンバー数を示します。

TIMESTAMP

通知イベントをオーダーする場合に使用するローカル・タイム・ゾーン。

表4-5に示すように、FANレコードは各セッションのデータベースの署名と一致します。

表4-5 FANパラメータおよび一致するデータベースの署名

FANパラメータ

一致するOracle Databaseの署名

SERVICE

sys_context('userenv', 'service_name')

DATABASE UNIQUE NAME

sys_context('userenv', 'db_unique_name')

INSTANCE

sys_context('userenv', 'instance_name')

NODE NAME

sys_context('userenv', 'server_host')

高速アプリケーション通知のコールアウトの使用

FANコールアウトは、高可用性イベントが発生したときにOracle Restartで即座に実行されるサーバー側の実行可能ファイルです。FANコールアウトを使用すると、イベントが発生したとき、次のようなアクティビティを自動化できます。

- 障害追跡チケットのオープン

- ページャへのメッセージの送信

- 電子メールの送信

- サーバー側のアプリケーションの起動および停止

- 各イベントの発生とともにロギングすることによるアップタイム・ログのメンテナンス

FANコールアウトを使用するには、プライマリおよびスタンバイの両方のデータベース・サーバーのディレクトリgrid_home/racg/usrcoに実行可能ファイルを配置します。スクリプトを使用している場合は、実行可能ファイルの最初の行にシェルを設定します。次に、grid_home/racg/usrco/callout.shコールアウトのサンプル・ファイルを示します。

#! /bin/ksh
FAN_LOGFILE= [your path name]/admin/log/`hostname`_uptime.log
echo $* "reported="`date` >> $FAN_LOGFILE &

次に、前述の例の出力を示します。

NODE VERSION=1.0 host=sun880-2 status=nodedown reason=
timestamp=08-Oct-2004 04:02:14 reported=Fri Oct 8 04:02:14 PDT 2004

表4-5に示すように、FANレコードは各セッションのデータベースの署名と一致します。この情報を使用して、FANイベント・データと一致するセッションで処理を行います。

関連項目:
コールアウトおよびイベントの詳細は、表4-4を参照してください。

高速アプリケーション通知と統合されているOracle Client

Oracle Restartデータベースへの接続に使用される多くの一般的なOracle Clientドライバは、FANと統合されています。そのため、FANを使用する最も簡単な方法は、Oracle統合クライアントを使用することです。

CMANセッション・プール、Oracle Call Interface、Universal Connection Pool for Java、JDBC simplefan APIおよびODP.NET接続プールを使用できます。この機能は、使用可能なプライマリ・データベースにアプリケーションからいつでも一貫して接続できるようにすることを目的としています。

関連項目:
「プライマリ・データベースとスタンバイ・データベースの接続のフェイルオーバーの自動化」

Oracle Restartの構成

スタンドアロン・サーバー用にOracle GridインフラストラクチャをインストールすることによってOracle Restartをインストールしてからデータベースを作成すると、データベースがOracle Restart構成に自動的に追加され、必要に応じて自動的に再起動されます。しかし、データベースがすでに存在するホスト・コンピュータにOracle Restartをインストールした場合、データベース、リスナー、Oracle Automatic Storage Management(Oracle ASM)インスタンスおよびその他のコンポーネントをOracle Restart構成に手動で追加する必要があります。

Oracle Restartでデータベースを管理するよう構成した後、次の作業が必要なことがあります。

- Oracle Restart構成に他のコンポーネントを追加します。

- Oracle Restart構成からコンポーネントを削除します。

- 1つ以上のコンポーネントのOracle Restartでの管理を一時停止します。

- 個々のコンポーネントのOracle Restart構成オプションを変更します。

この項では、これらおよび他のタスクを行うために使用するSRVCTLコマンドについて説明します。内容は次のとおりです。

- SRVCTLの実行準備

- SRVCTLのヘルプの表示

- Oracle Restart構成へのコンポーネントの追加

- Oracle Restart構成からのコンポーネントの削除

- Oracle Restartでのコンポーネント管理の無効化と有効化

- コンポーネント・ステータスの表示

- コンポーネントのOracle Restart構成の表示

- コンポーネントのOracle Restart構成の変更

- Oracle Restart構成の環境変数の管理

- SRVCTLを使用したデータベース・サービスの作成と削除

- Oracle Restart環境でのFANイベントの有効化

- プライマリ・データベースとスタンバイ・データベースの接続のフェイルオーバーの自動化

- クライアントでの高速接続フェイルオーバーの有効化

関連項目:
「Oracle Restartの理解」

SRVCTLの実行準備

次の項のタスクでは、SRVCTLユーティリティを実行する必要があります。正しいOracleホームからSRVCTLを実行していること、および正しいユーザー・アカウントでホスト・コンピュータにログインしていることを確認する必要があります。表4-6は、SRVCTLで構成できるコンポーネントを示しており、SRVCTLを実行する必要があるOracleホームをコンポーネントごとに示しています。

表4-6 SRVCTLを起動するOracleホームの決定

構成対象コンポーネント

SRVCTLを起動するOracleホーム

データベース、データベース・サービス

データベース・ホーム

Oracle ASMインスタンス、ディスク・グループ、リスナー脚注1、ONS

Oracle Gridインフラストラクチャ・ホーム

脚注1 Oracle Gridインフラストラクチャ・ホームからリスナーが起動されたと仮定しています。既存のデータベースにOracle Restartをインストールした場合は、リスナーがデータベース・ホームから起動されている場合があるため、その場合はデータベース・ホームからSRVCTLを起動します。

SRVCTLの実行を準備する手順は、次のとおりです。:

1. 表4-6を使用して、SRVCTLを実行する必要があるOracleホームを決定します。

2. Oracle Restart構成を変更するSRVCTLコマンド(add、remove、enable、disableなど)を実行する場合、次のいずれかを実施します。

- UNIXおよびLinuxの場合、手順1で決定したOracleホームをインストールしたユーザーとしてデータベース・ホスト・コンピュータにログインします。

- Windowsの場合、管理者としてログインします。

上記以外の場合、任意のユーザーとしてホスト・コンピュータにログインします。

3. SRVCTLコマンドの入力に使用するコマンド・ウィンドウを開きます。
コマンドを入力するには、SRVCTLプログラムがPATH環境変数で指定されていることを確認する必要があります。指定されていない場合は、プログラムに絶対パスを入力できます。

SRVCTLのヘルプの表示

SRVCTLユーティリティのオンライン・ヘルプが利用できます。

SRVCTLのオンライン・ヘルプを表示する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のコマンドを入力します。

srvctl

詳細なヘルプを表示するには、次のコマンドを入力します。

srvctl -h

特定コマンドの詳細なヘルプを表示するには、次のように入力します。

srvctl command -h

たとえば、addコマンドのヘルプおよび各コンポーネント・タイプの様々なオプションに関するヘルプを表示するには、次のように入力します。

srvctl add -h

特定のコンポーネント・タイプに対する特定のコマンドに関する詳細なヘルプを表示するには、次のように入力します。

srvctl command object -h

たとえば、データベース・サービスの追加に関するヘルプを表示するには、次のコマンドを入力します。

srvctl add service -h

SRVCTLコマンドのリストは表4-7を、コンポーネントのリストは表4-8をそれぞれ参照してください。

Oracle Restart構成へのコンポーネントの追加

ほとんどの場合、Oracle Restartを実行しているホストでOracleコンポーネントを作成すると、Oracle Restart構成にコンポーネントが自動的に追加されます。(表4-2を参照。)その後、コンポーネントは必要に応じて自動的に再起動されます。

次の場合、SRVCTLを使用してOracle Restart構成にコンポーネントを手動で追加する必要があります。

- データベースの作成後にOracle Restartをインストールします。

- CREATE DATABASE SQL文を使用して、同じホスト・コンピュータにOracle Databaseを追加で作成します。

- DBMS_SERVICE.CREATE_SERVICEパッケージ・プロシージャを使用してデータベース・サービスを作成します。(SRVCTLを使用することをお薦めします。)

注意:
Oracle Restart構成へのコンポーネントの追加は、Oracle Restartを使用したコンポーネントの登録とも呼ばれます。

Oracle Restart構成にコンポーネントを追加してもそのコンポーネントは起動されません。起動するには、srvctl startコマンドを使用する必要があります。

また、Oracle Enterprise Manager Database Control(Database Control)を使用して、データベースまたはリスナーをOracle Restart構成に追加してもかまいません。SRVCTLとDatabase Controlを使用する方法は次の項で説明しています。

- SRVCTLを使用したコンポーネントの追加

- Oracle Enterprise Manager Database Controlを使用したコンポーネントの追加

注意:
Oracle Restartの構成に手動でデータベースを追加する場合は、そのデータベースのOSDBAグループのメンバーとしてOracle Gridインフラストラクチャ・ソフトウェアの所有者を追加することも必要となります。これは、Gridインフラストラクチャ・コンポーネントが、データベースを起動および停止するために、データベースにSYSDBAとして接続できる必要があるためです。
たとえば、Gridインフラストラクチャをインストールしたホスト・ユーザーの名前がgridで、新しいデータベースのOSDBAグループの名前がdbaである場合、ユーザーgridはdbaグループのメンバーであることが必要です。

関連項目:

- 「Oracle Restartで管理されているコンポーネントの起動と停止」

- 「OSDBAとOSOPER」

SRVCTLを使用したコンポーネントの追加

SRVCTLを使用してOracle Restart構成にコンポーネントを追加する場合、コンポーネントのオプション構成設定を指定できます。

SRVCTLを使用してOracle Restart構成にコンポーネントを追加する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のコマンドを入力します。

srvctl add object options

objectは表4-8に示したコンポーネントの1つです。各コンポーネントに利用できるオプションについては、SRVCTLのaddコマンドを参照してください。

例4-1 データベースの追加

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースを追加します。必須の-oオプションではOracleホームの場所を指定します。-cオプションでは単一インスタンスのデータベースを指定します。

srvctl add database -d dbcrm -o /u01/app/oracle/product/11.2.0/dbhome_1 -c SINGLE

例4-2 データベース・サービスの追加

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースに対し、crmbatchという新しいデータベース・サービスを作成し、Oracle Restart構成に追加します。

srvctl add service -d dbcrm -s crmbatch

他の例については、「SRVCTLを使用したデータベース・サービスの作成と削除」を参照してください。

例4-3 デフォルト・リスナーの追加

この例ではOracle Restart構成にデフォルト・リスナーを追加します。

srvctl add listener

関連項目:
「Oracle RestartのSRVCTLコマンド・リファレンス」

Oracle Enterprise Manager Database Controlを使用したコンポーネントの追加

Oracle Enterprise Manager Database Control(Database Control)を使用した場合、Oracle Restart構成にデータベース・インスタンスとリスナーのみを追加できます。

Database Controlを使用してデータベース・インスタンスを追加する手順は、次のとおりです。

1. 必要なデータベース・インスタンスのデータベース・ホームページにアクセスします。
詳細は、『Oracle Database 2日でデータベース管理者』のデータベース・ホームページへのアクセスに関する項を参照してください。

2. 「高可用性」セクションの「Oracle Restart」ラベルの横で、「無効」リンクをクリックします。

注意:
「Oracle Restart」ラベルに「有効」と表示されている場合、データベースはすでにOracle Restartで管理されているため、続行する必要はありません。

3. ホスト資格証明がプロンプトで要求された場合は、データベースOracleホームをインストールしたユーザーの資格証明を入力して「ログイン」をクリックします。

4. 確認ページで「続行」をクリックします。

Database Controlを使用してリスナーを追加する手順は、次のとおりです。

1. 必要なデータベース・インスタンスのデータベース・ホームページにアクセスします。
詳細は、『Oracle Database 2日でデータベース管理者』のデータベース・ホームページへのアクセスに関する項を参照してください。

2. 「一般」セクションの「リスナー」ラベルの横にあるリンクをクリックします。

3. 「高可用性」セクションの「Oracle Restart」ラベルの横で、「無効」リンクをクリックします。

注意:
「Oracle Restart」ラベルに「有効」と表示されている場合、リスナーはすでにOracle Restartで管理されているため、続行する必要はありません。

4. 確認ページで「続行」をクリックします。

Oracle Restart構成からのコンポーネントの削除

Oracleでお薦めする方法を使用してOracleコンポーネントを削除した場合、そのコンポーネントはOracle Restart構成からも自動的に削除されます。たとえば、Database Configuration Assistant (DBCA)を使用してデータベースを削除すると、DBCAによって、Oracle Restart構成からデータベースが削除されます。同様に、Oracle Net Configuration Assistant(NETCA)を使用してリスナーを削除すると、NETCAによって、Oracle Restart構成からリスナーが削除されます。他の例については、表4-3を参照してください。推奨以外の方法や手動でOracleコンポーネントを削除する場合、最初にSRVCTLを使用してOracle Restart構成からコンポーネントを削除する必要があります。そうしないと、エラーが発生することがあります。

Oracle Restart構成からコンポーネントを削除する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のコマンドを入力します。

srvctl remove object [options]

objectは表4-8に示したコンポーネントの1つです。各コンポーネントに利用できるオプションについては、SRVCTLのremoveコマンドを参照してください。

例4-4 データベースの削除

この例ではDB_UNIQUE_NAMEがdbcrmであるデータベースを削除します。

srvctl remove database -d dbcrm

関連項目:
「Oracle RestartのSRVCTLコマンド・リファレンス」

Oracle Restartでのコンポーネント管理の無効化と有効化

Oracle Restartでのコンポーネント管理は一時的に無効にできます。この機能を実行するケースの1つとして、コンポーネントのメンテナンスを実行する場合があります。たとえば、コンポーネントの修復が必要な場合、障害の発生時やホスト・コンピュータの再起動時にコンポーネントを自動的に再起動しない方がよいことがあります。

メンテナンスの完了後、コンポーネントの管理を再度有効にできます。

コンポーネントを無効にすると、次のようになります。

- 自動的に再起動しなくなります。

- 依存性によって自動的に起動しなくなります。

- SRVCTLで起動できません。

- このリソースに依存するコンポーネントは、自動的に開始または再起動しなくなります。

コンポーネントの自動再起動を無効または有効にする手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のいずれかを実行します。

- コンポーネントを無効にするには、次のコマンドを入力します。

srvctl disable object [options]

- コンポーネントを有効にするには、次のコマンドを入力します。

srvctl enable object [options]

objectを表4-8に示したコンポーネントの1つと置き換えます。各コンポーネントに利用できるオプションについては、SRVCTLのdisableコマンドおよびenableコマンドを参照してください。

例4-5 データベースの自動再起動の無効化

この例ではDB_UNIQUE_NAMEがdbcrmであるデータベースの自動再起動を無効にします。

srvctl disable database -d dbcrm

例4-6 Oracle ASMディスク・グループの自動再起動の無効化

この例では、recoveryというOracle ASMディスク・グループの自動再起動を無効にします。

srvctl disable diskgroup -g recovery

例4-7 Oracle ASMディスク・グループの自動再起動の有効化

この例では、recoveryというディスク・グループの自動再起動を再度有効にします。

srvctl enable diskgroup -g recovery

関連項目:
「Oracle RestartのSRVCTLコマンド・リファレンス」

コンポーネント・ステータスの表示

SRVCTLを使用すると、Oracle Restartで管理されているコンポーネントの実行ステータス(実行中または実行していない)を表示できます。一部のコンポーネントでは、他の情報も表示されます。

コンポーネント・ステータスを表示する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のコマンドを入力します。

srvctl status object [options]

objectは表4-8に示したコンポーネントの1つです。各コンポーネントに利用できるオプションについては、SRVCTLのstatusコマンドを参照してください。

例4-8 データベースのステータスの表示

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのステータスを表示します。

srvctl status database -d dbcrm

Database is running.

関連項目:
「Oracle RestartのSRVCTLコマンド・リファレンス」

コンポーネントのOracle Restart構成の表示

SRVCTLを使用すると、任意のコンポーネントのOracle Restart構成を表示できます。Oracle Restartではコンポーネント・タイプごとに異なる構成情報を保持します。SRVCTLコマンドの1形式を使用して、Oracle Restartで管理されているコンポーネントのリストを取得できます。

コンポーネントの構成を表示する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のコマンドを入力します。

srvctl config object options

objectは表4-8に示したコンポーネントの1つです。各コンポーネントに利用できるオプションについては、SRVCTLのconfigコマンドを参照してください。

例4-9 Oracle Restartで管理されているすべてのデータベースのリストの表示

srvctl config database

dbcrm
orcl

例4-10 特定のデータベースの構成の表示

この例では、DB_UNIQUE_NAMEがorclであるデータベースの構成を表示します。

srvctl config database -d orcl

Database unique name: orcl
Database name: orcl
Oracle home: /u01/app/oracle/product/11.2.0/dbhome_1
Oracle user: oracle
Spfile: +DATA/orcl/spfileorcl.ora
Domain: us.example.com
Start options: open
Stop options: immediate
Database role:
Management policy: automatic
Disk Groups: DATA
Services: mfg,sales

関連項目:
「Oracle RestartのSRVCTLコマンド・リファレンス」

コンポーネントのOracle Restart構成の変更

SRVCTLを使用して、コンポーネントのOracle Restart構成を変更できます。たとえば、Oracle Restartがリスナーを起動したときにリスナーがリスニングするポート番号や、Oracle Restartがデータベースを起動する際に指し示すサーバー・パラメータ・ファイル(SPFILE)を変更できます。

コンポーネントのOracle Restart構成を変更する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のコマンドを入力します。

srvctl modify object options

objectは表4-8に示したコンポーネントの1つです。各コンポーネントに利用できるオプションについては、SRVCTLのmodifyコマンドを参照してください。

例4-11 データベースのOracle Restart構成の変更

DB_UNIQUE_NAMEがdbcrmであるデータベースの場合、次のコマンドを使用すると、管理ポリシーはMANUALに、起動オプションはNOMOUNTに変更されます。

srvctl modify database -d dbcrm -y MANUAL -s NOMOUNT

MANUAL管理ポリシーを設定すると、データベース・ホスト・コンピュータの再起動時にデータベースが自動的に起動されなくなります。ただし、Oracle Restartでデータベースの監視が継続され、データベースに障害が発生すると再起動されます。

関連項目:

- 「コンポーネントのOracle Restart構成の表示」

- 「Oracle RestartのSRVCTLコマンド・リファレンス」

Oracle Restart構成の環境変数の管理

Oracle Restart構成には環境変数の名前と値のペアを格納できます。通常、Oracleデータベースを起動する前に環境変数(ORACLE_HOMEとORACLE_SIDを除く)を設定する場合、これらの環境変数値をOracle Restart構成に設定できます。次のコンポーネントの個々の構成には任意の数の環境変数を格納できます。

- データベース・インスタンス

- リスナー

- Oracle ASMインスタンス

前述のコンポーネントの1つがOracle Restartで起動されると、そのコンポーネントの環境変数はコンポーネント構成に格納された値に最初に設定されます。Oracleコンポーネントで使用される環境変数はこの方法で設定できますが、この機能の主な対象はオペレーティング・システムの環境変数です。

次の項では、環境変数の設定、設定解除および表示の手順を説明しています。

- 環境変数の設定と設定解除

- 環境変数の表示

注意:
この機能はORACLE_HOME、ORACLE_SIDなどの標準環境変数の設定には使用しないでください。これらの環境変数はOracle Restartで自動的に設定されます。

環境変数の設定と設定解除

SRVCTLを使用して、コンポーネントに対するOracle Restart構成の環境変数値を設定したり、設定を解除します。

構成の環境変数の設定または設定解除を実行する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のいずれかを実行します。

- 構成の環境変数を設定するには、次のコマンドを入力します。

srvctl setenv {asm|database|listener} options

- 構成から環境変数を削除するには、次のコマンドを入力します。

srvctl unsetenv {asm|database|listener} options

各コンポーネントに利用できるオプションについては、SRVCTLのsetenvコマンドおよびunsetenvコマンドを参照してください。

例4-12 データベース環境変数の設定

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのOracle Restart構成にNLS_LANGおよびAIX AIXTHREAD_SCOPE環境変数を設定します。

srvctl setenv database -d dbcrm -t "NLS_LANG=AMERICAN_AMERICA.AL32UTF8,
AIXTHREAD_SCOPE=S"

関連項目:
「Oracle RestartのSRVCTLコマンド・リファレンス」

環境変数の表示

SRVCTLを使用して、コンポーネントに対するOracle Restart構成の環境変数の値を表示します。

構成の環境変数値を表示する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のコマンドを入力します。

srvctl getenv {database|listener|asm} options

各コンポーネントに利用できるオプションについては、SRVCTLのgetenvコマンドを参照してください。

例4-13 データベースのすべての環境変数の表示

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのOracle Restart構成にある環境変数を取得および表示します。

srvctl getenv database -d dbcrm

dbcrm:
NLS_LANG=AMERICAN_AMERICA
AIXTHREAD_SCOPE=S
GCONF_LOCAL_LOCKS=1

例4-14 データベースの特定の環境変数の表示

この例では、同じデータベースのOracle Restart構成からNLS_LANGおよびAIXTHREAD_SCOPE環境変数を取得および表示します。

srvctl getenv database -d dbcrm -t "NLS_LANG,AIXTHREAD_SCOPE"

dbcrm:
NLS_LANG=AMERICAN_AMERICA
AIXTHREAD_SCOPE=S

関連項目:
「Oracle RestartのSRVCTLコマンド・リファレンス」

SRVCTLを使用したデータベース・サービスの作成と削除

Oracle Restartを使用してデータベースを管理する場合、データベース・サービスの作成と削除にはSRVCTLを使用することをお薦めします。SRVCTLを使用してデータベース・サービスを追加すると、サービスはOracle Restart構成に自動的に追加され、サービスとデータベース間の依存性が確立されます。したがって、サービスの起動時にデータベースが起動されていない場合、Oracle Restartで最初にデータベースが起動されます。

SRVCTLを使用してデータベース・サービスを削除すると、サービスはOracle Restart構成からも削除されます。

SRVCTLを使用してデータベース・サービスを作成する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のコマンドを入力します。

srvctl add service -d db_unique_name -s service_name [options]

データベース・サービスが作成され、Oracle Restart構成に追加されます。利用できるオプションについては、srvctl add serviceコマンドを参照してください。

例4-15 データベース・サービスの作成

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースに対してcrmbatchという新しいデータベース・サービスを作成します。

srvctl add service -d dbcrm -s crmbatch

例4-16 ロールベースのデータベース・サービスの作成

この例では、crmbatchデータベース・サービスを作成し、PHYSICAL_STANDBYのData Guardロールを割り当てます。dbcrmデータベースの現在のロールがフィジカル・スタンバイである場合にのみ、このサービスは自動的に起動されます。

srvctl add service -d dbcrm -s crmbatch -l PHYSICAL_STANDBY

SRVCTLを使用してデータベース・サービスを削除する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のコマンドを入力します。

srvctl remove service -d db_unique_name -s service_name [-f]

データベース・サービスがOracle Restart構成から削除されます。-f(強制)フラグがあると、サービスが実行中の場合でも削除されます。このフラグがないと、サービスが実行の場合にはエラーが発生します。

関連項目:
「Oracle RestartのSRVCTLコマンド・リファレンス」

Oracle Restart環境でのFANイベントの有効化

Oracle Restartを有効にして高速アプリケーション通知(FAN)イベントを公開するには、Oracle Restartサーバーおよび統合されているクライアントを含むOracle Notification Services(ONS)ネットワークを作成する必要があります。このクライアントには、Oracle Connection Manager(CMAN)、Java Database Connectivity(JDBC)およびUniversal Connection Pool(UCP)クライアントを含めることができます。Oracle Call InterfaceまたはODP.NETクライアントを使用している場合は、サービスに対してOracle Advanced Queuing(AQ)HA通知を有効にする必要があります。また、ONSがサーバー上で稼働している必要があります。

Oracle Restart環境でFANイベントを有効にする手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. データベースがすでにOracle Restartで管理されていない場合は、データベースをOracle Restart構成に追加します。「Oracle Restart構成へのコンポーネントの追加」を参照してください。

3. ONSを構成に追加します。

srvctl add ons

ONSは、追加時には無効になっています。

4. ONSを有効にします。

srvctl enable ons

5. ONSを起動します。

srvctl start ons

6. Oracle Restart構成にサービスを追加します。
Oracle Call InterfaceおよびODP.NETクライアントについては、データベース・キューを有効にするため-qオプションがTRUEに設定されていることを確認します。

「SRVCTLを使用したデータベース・サービスの作成と削除」を参照してください。

7. 各クライアントで高速接続フェイルオーバーを有効化します。「クライアントでの高速接続フェイルオーバーの有効化」を参照してください。

関連項目:
「Oracle RestartのSRVCTLコマンド・リファレンス」

プライマリ・データベースとスタンバイ・データベースの接続のフェイルオーバーの自動化

Oracle RestartおよびOracle Data Guardのプライマリ・データベースとスタンバイ・データベースを使用する構成では、スイッチオーバーまたはフェイルオーバーの際にデータベース・サービスがプライマリからスタンバイに自動的にフェイルオーバーします。Oracle Notification Services(ONS)を使用すると、プライマリ・データベースとスタンバイ・データベース間におけるサービスのフェイルオーバーをクライアントに即座に通知できます。Oracle Data Guard Brokerでは、フェイルオーバーが発生すると、高速アプリケーション通知(FAN)を使用してクライアントに通知が送信されます。統合されているOracle Clientでは、接続が自動的にフェイルオーバーされ、アプリケーションによって障害をエンド・ユーザーからマスクできます。

接続のフェイルオーバーを自動化するには、Oracle Restartサーバーおよび統合されているクライアント(CMAN、リスナー、JDBCおよびUCP)を含むONSネットワークを作成する必要があります。Oracle Call InterfaceまたはODP.NETクライアントを使用している場合は、Oracleアドバンスト・キューイングのキューを有効にする必要があります。サービスのフェイルオーバーを自動化するには、データベースおよびサービスをOracle RestartとOracle Data Guard Brokerで管理する必要があります。

プライマリ・データベースとスタンバイ・データベース間におけるサービスのフェイルオーバーを自動化する手順は、次のとおりです。

1. Oracle Data Guard Brokerでプライマリ・データベースとスタンバイ・データベースを構成します。『Oracle Data Guard Broker』を参照してください。

2. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

3. プライマリ・サーバー上のOracle Restart構成にプライマリ・データベースが追加されていない場合は、追加します。データベース・ロールには、PRIMARYを指定してください。「Oracle Restart構成へのコンポーネントの追加」を参照してください。

4. スタンバイ・サーバー上のOracle Restart構成にスタンバイ・データベースが追加されていない場合は、追加します。適切なスタンバイ・データベース・ロールを指定してください。

5. プライマリ・データベース・サーバーおよびスタンバイ・データベース・サーバーの両方で、FANイベントを有効にします。「Oracle Restart環境でのFANイベントの有効化」を参照してください。

6. プライマリ・データベースおよびスタンバイ・データベース上のOracle Restart構成のデータベースに接続するためにクライアントで使用するサービスを追加します。サービスを追加する場合は、次のことを確認してください。

- サービスごとに、-lオプションが適切なロールに設定されていること

- ODP.NETまたはOracle Call Interfaceを使用している場合は、-qオプションがTRUEに設定されていること

「SRVCTLを使用したデータベース・サービスの作成と削除」を参照してください。

7. 各クライアントで高速接続フェイルオーバーを有効化します。「クライアントでの高速接続フェイルオーバーの有効化」を参照してください。

関連項目:
「Oracle RestartのSRVCTLコマンド・リファレンス」

クライアントでの高速接続フェイルオーバーの有効化

スタンバイ・データベースが存在する構成では、Oracle Notification Services(ONS)をOracle Restart構成に追加した後でサービスに対してOracle Advanced Queuing(AQ)HA通知を有効にすると、クライアントで高速接続フェイルオーバーを有効化できます。クライアントでは、高速アプリケーション通知(FAN)イベントを受信し、Oracle Data Guardのフェイルオーバーの後で現在のプライマリ・データベースへの接続を再配置できます。ONSの追加については、「プライマリ・データベースとスタンバイ・データベースの接続のフェイルオーバーの自動化」を参照してください。

スタンバイ・データベースが構成されていないデータベースでも、クライアントのFANイベントを構成できます。フェイルオーバーが発生した場合、データベースへの接続を再試行するようにクライアントを構成できます。障害が発生したデータベースはOracle Restartによって再起動されるため、データベースが再起動した時点でクライアントは再接続できます。この項の例で示すように、接続文字列に適切な遅延と再試行を確実にプログラムしてください。

Oracle Restart構成では、次のタイプのクライアントで高速接続を有効化できます。

- JDBCクライアントでの高速接続フェイルオーバーの有効化

- Oracle Call Interfaceクライアントでの高速接続フェイルオーバーの有効化

- ODP.NETクライアントでの高速接続フェイルオーバーの有効化

JDBCクライアントでの高速接続フェイルオーバーの有効化

Oracle Universal Connection PoolでFANを有効にすると、クライアントで高速接続フェイルオーバー(FCF)が有効になります。アプリケーションでは、シックまたはシンのいずれかのJDBCクライアントを使用してFCFを使用できます。

JDBCクライアントを構成するには、データソースに対して最初のgetConnection()要求を行う前に、FastConnectionFailoverEnabledプロパティを設定します。高速接続フェイルオーバーを有効にすると、接続キャッシュ内のすべての接続にフェイルオーバーが適用されます。アプリケーションでConnection Cache Managerを使用して接続キャッシュを明示的に作成する場合は、まずFastConnectionFailoverEnabledを設定する必要があります。

この項では、Universal Connection Poolを使用してJDBCのFCFを有効にする方法について説明します。シックJDBCクライアントで高速接続フェイルオーバーを有効にする場合は、クライアントおよびサービスの両方で透過アプリケーション・フェイルオーバー(TAF)を有効にしないでください。シンまたはシックJDBCクライアントでFCFを有効にすると、受信用の接続プールが有効になり、すべてのFANイベントが処理されます。

JDBCクライアントで高速接続フェイルオーバーを有効にする手順は、次のとおりです。

1. 次の例に示すように、キャッシュ対応のデータソースで、データソース・プロパティFastConnectionFailoverEnabledをtrueに設定して、Oracle JDBCの暗黙的な接続キャッシュでFANを有効にします。

PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setONSConfiguration("nodes=primaryhost:6200,standbyhost:6200");
pds.setFastConnectionFailoverEnabled(true);
pds.setURL("jdbc:oracle:thin:@(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=primaryhost)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=standbyhost)(PORT=1521))
(CONNECT_DATA=(service_name=service_name)))");

......

この例では、primaryhostはプライマリ・データベースのサーバーであり、standbyhostはスタンバイ・データベースのサーバーです。

アプリケーションのCLASSPATHには、ucp.jarとons.jarの両方が必要です。

注意:
データソースに変更を加えずにFANを有効にするには、システム・プロパティ-D oracle.jdbc.FastConnectionFailover=trueを使用します。

2. アプリケーションを開始する際に、ons.jarファイルがアプリケーションのCLASSPATHに存在することを確認してください。ons.jarファイルは、Oracle Clientのインストールの一部です。

関連項目:
『Oracle Database JDBC開発者ガイド』

Oracle Call Interfaceクライアントでの高速接続フェイルオーバーの有効化

Oracle Call Interfaceクライアントは、Oracle Restart高可用性FANイベントの発生時に通知を受信して応答するように登録することで、高速接続フェイルオーバー(FCF)を有効にできます。これにより、Oracle Call Interfaceのセッション・フェイルオーバーのレスポンス時間が向上し、中断した接続を接続プールおよびセッション・プールから削除できます。この機能は、透過アプリケーション・フェイルオーバー(TAF)、接続プールまたはセッション・プールを使用するものも含めたOracle Call Interfaceアプリケーションで動作します。

まず、高可用性イベントのサービスを有効にして、アドバンスト・キューイングのALERT_QUEUEを自動的に移入する必要があります。アプリケーションでTAFを使用している場合は、サービスのTAF設定を有効にします。Oracle Restartデータベースに接続するようにクライアント・アプリケーションを構成します。クライアントでは、イベントが発生するたびに使用されるコールバックを登録できます。これにより、接続障害の検出に要する時間が軽減されます。

Oracle Call Interfaceでは、DOWNイベントの処理時に次の操作が行われます。

- クライアントで影響を受ける接続が終了し、エラーが戻されます。

- Oracle Call Interface接続プールおよびOracle Call Interfaceセッション・プールから接続が削除されます。
セッション・プールでは各セッションが接続プールの物理接続にマップされており、接続ごとに複数のセッションが存在できます。

- TAFが構成されている場合は、接続がフェイルオーバーされます。

TAFが構成されていない場合は、クライアントのみがエラーを受信します。

注意:
Oracle Call Interfaceでは、UPイベントは管理されません。

Oracle Call Interfaceクライアントで高速接続フェイルオーバーを有効化する手順は、次のとおりです。

1. 使用しているサービスで、SRVCTLのmodifyコマンドを使用してサービスの値を設定することによって、アドバンスト・キューイング通知が有効になっていることを確認します。次に例を示します。

srvctl modify service -d proddb -s gl.us.example.com -q true -l primary -e select -m basic -z 5 -w 180 -j long

2. 次に示すように、環境作成時にOCI_EVENTSを有効にします。

( OCIEnvCreate(...) )

3. クライアント・アプリケーションをクライアント・スレッドまたはオペレーティング・システムのライブラリにリンクします。

4. オプションとして、クライアントのEVENTコールバックを登録します。

5. クライアントですべてのプライマリ・ホストとスタンバイ・ホストがADDRESS_LISTに含まれているOracle Net接続記述子が使用されていることを確認します。次に例を示します。

gl =
(DESCRIPTION =
(CONNECT_TIMEOUT=10)(RETRY_COUNT=3)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = BOSTON1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = CHICAGO1)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA=
(SERVICE_NAME=gl.us.example.com)))

アラート情報を表示するには、DBA_OUTSTANDING_ALERTSおよびDBA_ALERT_HISTORYビューを問い合せます。

関連項目:

- 『Oracle Call Interfaceプログラマーズ・ガイド』

- TAFの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

ODP.NETクライアントでの高速接続フェイルオーバーの有効化

Oracle Data Provider for .NET(ODP.NET)接続プールでは、サービスが停止したことを示す通知をサブスクライブできます。DOWNイベントが発生すると、インスタンスが停止する接続プール内のセッションがOracle Databaseによってクリーン・アップされ、有効でなくなる接続がODP.NETによって事前に処理されます。

ODP.NETクライアントで高速接続フェイルオーバーを有効にする手順は、次のとおりです。

1. 次の例に示すように、SRVCTLのmodify serviceコマンドを使用して、アドバンスト・キューイング通知を有効にします。

srvctl modify service –d dbname –s gl –q true, -j long

2. .Net Application経由で接続されるユーザーに対して、次のコマンドを実行します。user_nameはユーザー名です。

execute DBMS_AQADM.GRANT_QUEUE_PRIVILEGE('DEQUEUE','SYS.SYS$SERVICE_METRICS', user_name);

3. FAN高可用性イベントをサブスクライブすることによって、ODP.NET接続プールの高速接続フェイルオーバーを有効にします。HAイベント接続文字列属性を接続時にtrueに設定します。プーリング属性はtrue (デフォルト)に設定する必要があります。次にこれらの設定の例を示します。user_nameはユーザーの名前、passwordはユーザーのパスワードを表します。

// C#
using System;
using Oracle.DataAccess.Client;

class HAEventEnablingSample
{
static void Main()
{
OracleConnection con = new OracleConnection();

// Open a connection using ConnectionString attributes
// Also, enable "load balancing"
con.ConnectionString =
"User Id=user_name;Password=password;Data Source=oracle;" +
"Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" +
"HA Events=true;Incr Pool Size=5;Decr Pool Size=2";

con.Open();

// Create more connections and perform work against the database here.

// Dispose OracleConnection object
con.Dispose();
}
}

4. クライアントですべてのプライマリ・ホストとスタンバイ・ホストがADDRESS_LISTに含まれているOracle Net接続記述子が使用されていることを確認します。次に例を示します。

gl =
(DESCRIPTION =
(CONNECT_TIMEOUT=10)(RETRY_COUNT=3)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = BOSTON1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = CHICAGO1)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA=
(SERVICE_NAME=gl.us.example.com)))

関連項目:

- ODP.NETの詳細は、『Oracle Data Provider for .NET開発者ガイド』を参照してください。

- 「Oracle RestartのSRVCTLコマンド・リファレンス」

Oracle Restartで管理されているコンポーネントの起動と停止

Oracle Restartの使用中にコンポーネントを開始し停止する場合、次の理由により、SRVCTLユーティリティを使用することをお薦めします。

- SRVCTLを使用してコンポーネントを起動すると、このコンポーネントが依存しているコンポーネントがOracle Restartで最初に起動されます。SRVCTLを使用してコンポーネントを停止すると、Oracle Restartで最初に依存コンポーネントを停止できます。

- SRVCTLでは常にOracle Restart構成に従ってコンポーネントを起動します。他の方法でコンポーネントを起動すると、Oracle Restart構成に従わない可能性があります。
たとえば、Oracle Restart構成にデータベースを追加したときにサーバー・パラメータ・ファイル(SPFILE)の場所を指定し、この場所がSPFILEのデフォルトの場所ではなかった場合、SQL*Plusを使用してデータベースを起動すると、構成に指定されたSPFILEが使用されないことがあります。

データベース・インスタンスの構成オプションの表は、srvctl add databaseコマンドを参照してください。

- SRVCTLを使用してコンポーネントを起動すると、コンポーネントのOracle Restart構成に格納されている環境変数が設定されます。
詳細は、「Oracle Restart構成の環境変数の管理」を参照してください。

また、Oracle Enterprise Manager Database Control(Database Control)を使用して、Oracle Restartで管理されているデータベースを起動することもできます。SRVCTLとDatabase Controlを使用する方法は次の項で説明しています。

- Oracle Restartで管理されているコンポーネントのSRVCTLを使用した起動と停止

- Oracle Restartによって管理されているデータベースのOracle Enterprise Managerを使用した起動

Oracle Restartで管理されているコンポーネントのSRVCTLを使用した起動と停止

SRVCTLを使用して、Oracle Restartで管理されているコンポーネントを起動および停止できます。

SRVCTLを使用してOracle Restartで管理されているコンポーネントを起動または停止する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. 次のいずれかを実行します。

- コンポーネントを起動にするには、次のコマンドを入力します。

srvctl start object [options]

- コンポーネントを停止するには、次のコマンドを入力します。

srvctl stop object [options]

objectは表4-8に示したコンポーネントの1つです。各コンポーネントに利用できるオプションについては、SRVCTLのstartコマンドおよびstopコマンドを参照してください。

例4-17 データベースの起動

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースを起動します。

srvctl start database -d dbcrm

例4-18 データベースNOMOUNTの起動

この例では、データベースをマウントせずにデータベース・インスタンスを起動します。

srvctl start database -d dbcrm -o nomount

例4-19 デフォルト・リスナーの起動

この例では、デフォルト・リスナーを起動します。

srvctl start listener

例4-20 指定されたリスナーの起動

この例では、crmlistenerというリスナーを起動します。

srvctl start listener -l crmlistener

例4-21 データベース・サービスの起動

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのデータベース・サービスbizdevとsupportを起動します。データベースが起動されていない場合、Oracle Restartで最初にデータベースが起動されます。

srvctl start service -d dbcrm -s "bizdev,support"

例4-22 Oracle ASMディスク・グループの起動(マウント)

この例では、Oracle ASMディスク・グループdataとrecoveryを起動(マウント)します。このコマンドを実行するユーザーはOSASMグループのメンバーであることが必要です。

srvctl start diskgroup -g "data,recovery"

例4-23 データベースの停止

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースを停止します。停止オプション(-o)が指定されていないため、データベースはOracle Restart構成の停止オプションに従って停止します。デフォルトの停止オプションはIMMEDIATEです。

srvctl stop database -d dbcrm

例4-24 ABORTオプションを使用したデータベースの停止

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのSHUTDOWN ABORTを実行します。

srvctl stop database -d dbcrm -o abort

関連項目:
SRVCTLのstartコマンド

Oracle Restartによって管理されているデータベースのOracle Enterprise Managerを使用した起動

Oracle Enterprise Manager Database Control(Database Control)を使用すると、Oracle Restartを使用してデータベースを起動できます。

Oracle Enterprise Managerを使用して、Oracle Restartで管理されているデータベースを起動する手順は、次のとおりです。

1. 必要なデータベース・インスタンスのデータベース・ホームページにアクセスします。
詳細は、『Oracle Database 2日でデータベース管理者』のデータベース・ホームページへのアクセスに関する項を参照してください。

2. 「起動」をクリックします。
資格証明の起動/停止ページが表示されます。

3. 次の資格証明を入力します。

1. データベースOracleホームをインストールしたユーザーについては、ホスト・コンピュータの資格証明を入力します。

2. ユーザー名SYSおよびインストール時にSYSに割り当てられたパスワードから構成されるデータベース資格証明を入力します。

3. 「接続モード」リストで、値SYSOPERを選択します。

4. (オプション)このページが次回表示されるときに自動的にこれらの資格証明を入力する場合、「優先資格証明として保存」オプションを選択します。

5. 「OK」をクリックします。
「起動タイプの選択」ページが表示されます。

6. Oracle Restartとともにデータベースを起動するには、「依存するリソースとともにデータベースを起動」を選択します。
これにより、Oracle Automatic Storage Managementインスタンスなどのデータベースが依存するリソースが、データベースの起動前に正常に起動されるようになります。

7. 「OK」をクリックします。
「確認」ページが表示されます。

8. 「はい」をクリックします。
「起動/停止: アクティビティ情報」ページが表示され、データベースが起動中であることが示されます。起動が完了すると、ログイン・ページが表示されます。

9. データベース(およびDatabase Control)へログインします。
データベースのホームページで、データベース・インスタンスのステータスが稼働中であることが表示されます。

メンテナンス操作のためのOracle Restartの停止および再起動

OracleホームのいくつかのコンポーネントがOracle Restartで管理されている場合、Oracle RestartおよびOracle Restartで管理されているコンポーネントをOracleホーム内で停止できます。また、Oracle Restartを無効にして、ノードが再起動した場合にOracle Restartが再起動しないようにすることもできます。この設定は、Oracleホームを含むメンテナンスを実行する場合(パッチのインストールなど)に必要となることがあります。メンテナンス操作の完了後、Oracle Restartを有効にして再起動し、Oracle Restartで管理されているコンポーネントをOracleホーム内で再起動できます。

停止と起動の操作にはSRVCTLユーティリティとCRSCTLユーティリティを使用します。

- stop home SRVCTLコマンドでは、Oracle Restartで管理されているすべてのコンポーネントを、指定したOracleホーム内で停止します。start home SRVCTLコマンドではこれらのコンポーネントを起動します。OracleホームはOracle DatabaseホームまたはOracle Gridインフラストラクチャ・ホームです。
homeオブジェクトを使用すると、-sオプションで指定した状態ファイルによって各コンポーネントの状態が追跡されます。stopおよびstatusコマンドでは状態ファイルを作成します。startコマンドでは状態ファイルを使用して再起動するコンポーネントを特定します。

さらに、status homeコマンドを使用して、Oracle Restartで管理されているコンポーネントのステータスを確認できます。

- stop CRSCTLコマンドはOracle Restartを停止し、disable CRSCTLコマンドはOracle Restartで管理されるコンポーネントが自動的に再起動しないようにします。enable CRSCTLコマンドは自動再起動を有効にし、start CRSCTLコマンドはOracle Restartを再起動します。

パッチのインストール中にOracleホームのコンポーネントを停止および起動する手順は、次のとおりです。

1. 「SRVCTLの実行準備」で説明したように、SRVCTLの実行を準備します。

2. Oracle Restartで管理されているコンポーネントをOracleホーム内で停止するには、次のSRVCTLユーティリティを使用します。

srvctl stop home -o oracle_home -s state_file [-t stop_options] [-f]

ここで、oracle_homeはOracleホームの完全なパスを表し、state_fileは状態ファイルの完全なパスを表します。Oracleホームの状態情報は、指定した状態ファイルに記録されます。状態ファイルの場所は、手順7で指定する必要があるのでメモしておいてください。

Oracle Gridインフラストラクチャ・ホームのコンポーネントを停止する前に、依存するOracle Databaseホームのコンポーネントを先に停止する必要があります。

3. Oracle Gridインフラストラクチャ・ホームにパッチを適用している場合は、Oracle Restartを無効にして停止します。それ以外の場合は、手順4に進みます。
Oracle Restartを無効にして停止するには、CRSCTLユーティリティを使用して次のコマンドを実行します。

crsctl disable has

crsctl stop has

4. メンテナンス操作を実行します。

5. Oracle Restartで管理されているコンポーネントの自動再起動を有効にするには、次のCRSCTLユーティリティを使用します。

crsctl enable has

6. Oracle Restartを起動するには、次のCRSCTLユーティリティを使用します。

crsctl start has

7. 手順2で停止されたコンポーネントを起動するには、次のSRVCTLユーティリティを使用します。

srvctl start home -o oracle_home -s state_file

状態ファイルは、手順2で指定した状態ファイルと一致している必要があります。

8. また、Oracle Restartで管理されているコンポーネントのステータスをOracleホーム内で確認するには、次のSRVCTLユーティリティを使用します。

srvctl status home -o oracle_home -s state_file

例4-25 Oracle Restartで管理されているコンポーネントのOracleホーム内での停止

srvctl stop home -o /u01/app/oracle/product/11.2.0/dbhome_1 -s /usr1/or_state

例4-26 Oracle Restartで管理されているコンポーネントのOracleホーム内での起動

srvctl start home -o /u01/app/oracle/product/11.2.0/dbhome_1 -s /usr1/or_state

例4-27 Oracle Restartで管理されているコンポーネント・ステータスのOracleホーム内での表示

srvctl status home -o /u01/app/oracle/product/11.2.0/dbhome_1 -s /usr1/or_state

関連項目:

- srvctl stop homeコマンド

- srvctl status homeコマンド

- srvctl start homeコマンド

- 「CRSCTLコマンド・リファレンス」

Oracle RestartのSRVCTLコマンド・リファレンス

ここでは、Oracle Restartに固有のSRVCTLコマンドの構文とオプションに関して詳しく説明します。SRVCTLコマンドの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

SRVCTLコマンドの構文とオプションの概要

SRVCTLでは、次のコマンド構文が想定されます。

srvctl command object options

説明:

- commandはstart、stop、removeなどの動詞です。詳細なリストは、表4-7を参照してください。

- objectはデータベース、リスナーなど、SRVCTLコマンドの実行対象コンポーネントです。コンポーネントの略称も使用できます。コンポーネントとその略称の詳細なリストは、表4-8を参照してください。

- optionsは、コマンドの追加パラメータを使用できるように、前述のコマンドの組合せの使用範囲を拡大します。たとえば、-dオプションはデータベースの一意名が後に続くことを示し、-sオプションはデータベース・サービス名のカンマ区切りリストが後に続くことを示しています。

注意:
Windowsプラットフォームでカンマ区切りのリストを指定する場合、リストを二重引用符で囲む必要があります("...,...")。また、リスト・メンバーにシェルのメタ文字が含まれている場合、UNIXとLinuxプラットフォームでも二重引用符を使用する必要があります。

大/小文字の区別 SRVCTL コマンドおよびコンポーネントでは、大/小文字が区別されます。オプションでは大/小文字が区別されます。データベースとデータベース・サービス名では大/小文字が区別されず、大/小文字が保持されます。

表4-7 SRVCTLコマンドの概要

コマンド

説明

add

Oracle Restart構成にコンポーネントを追加します。

config

コンポーネントのOracle Restart構成を表示します。

disable

Oracle Restartでのコンポーネントの管理を無効にします。

enable

Oracle Restartでのコンポーネントの管理を再度有効にします。

getenv

データベース、Oracle ASMインスタンスまたはリスナーのOracle Restart構成にある環境変数を表示します。

modify

コンポーネントのOracle Restart構成を変更します。

remove

Oracle Restart構成からコンポーネントを削除します。

setenv

データベース、Oracle ASMインスタンスまたはリスナーのOracle Restart構成に環境変数を設定します。

start

指定したコンポーネントを起動します。

status

指定したコンポーネントの実行ステータスを表示します。

stop

指定したコンポーネントを停止します。

unsetenv

データベース、Oracle ASMインスタンスまたはリスナーのOracle Restart構成にある環境変数の設定を解除します。

SRVCTLコンポーネントの概要

表4-8に、SRVCTLコマンドのobject部分に使用できるキーワードを示します。各コンポーネント・キーワードの完全名と略称のいずれかを使用できます。

表4-8 コンポーネント・キーワードと略称

構成要素

略称

説明

asm

asm

Oracle ASMインスタンス

database

db

データベース・インスタンス

diskgroup

dg

Oracle ASMディスク・グループ

ファイル・システム

ファイル・システム

Oracle ASMファイル・システム

ホーム

ホーム

OracleホームまたはOracle Clusterwareホーム

リスナー

lsnr

Oracle Netリスナー

サービス

serv

データベース・サービス

ons

ons

Oracle Notification Services(ONS)

関連項目:
表4-1「Oracle Restartで自動的に再起動されるOracleコンポーネント」

add

srvctl addコマンドでは、指定したコンポーネントをOracle Restart構成に追加します。また、必要に応じてコンポーネントのOracle Restart構成パラメータを設定します。コンポーネントを追加した後、Oracle Restartで管理が開始され、コンポーネントは必要に応じて再起動されます。

srvctl add操作を実行するには、適切なユーザー・アカウントを使用してデータベース・ホスト・コンピュータにログインする必要があります。詳細は、「SRVCTLの実行準備」を参照してください。

表4-9 srvctl addの概要

コマンド

説明

srvctl add asm

Oracle ASMインスタンスを追加します。

srvctl add database

データベースを追加します。

srvctl add listener

リスナーを追加します。

srvctl add ons

ONS(Oracle Data Guard BrokerとともにOracle Data Guard構成で使用)を追加します。

srvctl add service

Oracle Restartで管理されているデータベース・サービスを追加します。

注意:
Oracle ASM ディスク・グループには、srvctl addコマンドはありません。ディスク・グループは、初回マウント時に自動的にOracle Restart構成に追加されます。Oracle Restart構成からディスク・グループを削除した後に再度追加する場合は、SQL*Plusを使用してOracle ASMインスタンスに接続し、ALTER DISKGROUP...MOUNTコマンドを使用します。

srvctl add asm

Oracle Restart構成にOracle ASMインスタンスを追加します。

構文およびオプション

srvctl add asmコマンドは次の構文で使用します。

srvctl add asm [-l listener_name [-p spfile] [-d asm_diskstring]]

表4-10 srvctl add asmのオプション

オプション

説明

-l listener_name

Oracle ASMが登録する必要があるリスナーの名前。このリスナーとの弱い依存性が確立されます。(Oracle ASMインスタンスを起動する前に、リスナーの起動が試行されます。リスナーが起動しない場合でも、Oracle ASMインスタンスは起動されます。後でリスナーに障害が発生した場合、Oracle RestartでOracle ASMは再起動されません。)

省略すると、デフォルトでlistenerというリスナーに設定されます。

-p spfile

データベースのサーバー・パラメータ・ファイルのフルパス。省略すると、デフォルトのSPFILEが使用されます。

-d asm_diskstring

Oracle ASMディスク・グループ検出文字列。Oracle ASM検出文字列は、Oracle ASMインスタンスによって検出されるディスクのセットを制限する文字列のカンマ区切りリストです。検出文字列には、ワイルドカード文字を含めることができます。文字列のいずれかに一致するディスクのみが検出されます。

例

次に、このコマンドの例を示します。

srvctl add asm -l crmlistener

関連項目:
Oracle ASMのディスク・グループ検出文字列の詳細は、Oracle Automatic Storage Management管理者ガイドを参照してください。

srvctl add database

Oracle Restart構成にデータベースを追加します。

Oracle Restart構成にデータベースを追加した後、データベースからOracle ASMディスク・グループのデータにアクセスした場合、データベースとディスク・グループ間の依存性が作成されます。その後、データベースの起動前にディスク・グループがマウントされていることがOracle Restartで確認されます。

ただし、Oracle Restart構成にデータベースを追加するときにデータベースとOracle ASMインスタンスが実行されていない場合、SRVCTLコマンドに-aオプションを指定して、データベースとディスク・グループ間の依存性を手動で確立する必要があります。この後の例を参照してください。

注意:
Oracle Restartの構成に手動でデータベースを追加する場合は、そのデータベースのOSDBAグループのメンバーとしてOracle Gridインフラストラクチャ・ソフトウェアの所有者を追加することも必要となります。これは、Gridインフラストラクチャ・コンポーネントが、データベースを起動および停止するために、データベースにSYSDBAとして接続できる必要があるためです。
たとえば、Gridインフラストラクチャをインストールしたホスト・ユーザーの名前がgridで、新しいデータベースのOSDBAグループの名前がdbaである場合、ユーザーgridはdbaグループのメンバーであることが必要です。

構文およびオプション

srvctl add databaseコマンドは次の構文で使用します。

srvctl add database -d db_unique_name -o oracle_home [-m domain_name]
[-c  {RACONENODE | RAC | SINGLE}] [-n db_name] [-i instance_name]
[-p spfile] [-s start_options] [-t stop_options]
[-r {PRIMARY | PHYSICAL_STANDBY | LOGICAL_STANDBY | SNAPSHOT_STANDBY}]
[-y {automatic | manual}] [-a disk_group_list]

表4-11 srvctl add databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-o Oracle_home

データベースのOracleホームのフルパス。

-m domain_name

データベースのドメイン。DB_DOMAIN初期化パラメータに一致する必要があります。

-c {RACONENODE | RAC | SINGLE}

追加するデータベースのタイプ(Oracle RAC One Node、Oracle RACまたは単一のインスタンス)。-x node_nameオプションを指定しない場合のデフォルトはRACで、-cオプションのデフォルトはSINGLEです。

Oracle Restart構成にデータベースを追加するときは、SINGLEを指定する必要があります。

-n db_name

指定する場合、DB_NAME初期化パラメータの設定に一致する必要があります。DB_NAMEが-dオプションで指定された一意の名前と異なる場合、このオプションを指定する必要があります。

-i instance_name

インスタンス名。

インスタンス名が-dオプションで指定された一意の名前と異なる場合、このオプションを指定する必要があります。たとえば、一意の名前にアンダースコアが含まれていて、インスタンス名がアンダースコアを省略している場合、このパラメータを使用してインスタンス名を指定します。

注意: -iオプションは、Oracle Databaseリリース11.2.0.3以上のデータベースでのみ使用可能です。

-p spfile

データベースのサーバー・パラメータ・ファイルのフルパス。省略すると、デフォルトのSPFILEが使用されます。

-s start_options

データベースの起動オプション(OPEN、MOUNTまたはNOMOUNT)。省略すると、デフォルトでOPENに設定されます。

-t stop_options

データベースの停止オプション(NORMAL、IMMEDIATE、TRANSACTIONALまたはABORT)。省略すると、デフォルトでIMMEDIATEに設定されます。

-r {PRIMARY | PHYSICAL_STANDBY | LOGICAL_STANDBY | SNAPSHOT_STANDBY}

データベースの現在のロール(PRIMARY、PHYSICAL_STANDBY、SNAPSHOT_STANDBYまたはLOGICAL_STANDBY)。Oracle Data Guard環境でのみ適用できます。

-y {AUTOMATIC | MANUAL}

データベースの管理ポリシー。AUTOMATIC(デフォルト)データベースは、データベース・ホスト・コンピュータの再起動時に以前の実行状態(起動または停止)へ自動的に戻ります。MANUALの場合、データベース・ホスト・コンピュータの再起動時にデータベースは自動的には再起動されません。MANUALを設定しても、データベースは実行中にOracle Restartで監視され、障害が発生すると再起動されます。

-a disk_group_list

データベースが依存するディスク・グループのリスト。Oracle Restartでは、データベースを起動する前にこれらのディスク・グループがマウントされていることを確認します。このオプションは、データベースの追加時にデータベース・インスタンスとOracle ASMインスタンスが起動されていなかった場合にのみ必要です。それ以外の場合、データベースとディスク・グループ間の依存性は自動的に記録されています。

例

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースを追加します。

srvctl add database -d dbcrm -o /u01/app/oracle/product/11.2.0/dbhome_1

この例では、同じデータベースを追加し、データベースおよびディスク・グループDATAとRECOVERY間の依存性も確立します。

srvctl add database -d dbcrm -o /u01/app/oracle/product/11.2.0/dbhome_1
-a "DATA,RECOVERY"

関連項目:

- 「Oracle RestartとOracle Data Guardとの統合」

- 『Oracle Data Guard概要および管理』

srvctl add listener

Oracle Restart構成にリスナーを追加します。

構文およびオプション

srvctl add listenerコマンドは次の構文で使用します。

srvctl add listener [-l listener_name] [-p endpoints] [-s] [-o Oracle_home]

表4-12 srvctl add listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、デフォルトでLISTENERに設定されます。

-p endpoints

カンマ区切りのTCPポートまたはリスナー・エンドポイント。省略すると、デフォルトでTCP:1521になります。endpointsの構文は次のとおりです。

"[TCP:]port[, ...] [/IPC:key] [/NMP:pipe_name] [/TCPS:s_port] [/SDP:port]"

-s

指定されたエンドポイントとのポートの不一致のチェックをスキップします。

-o Oracle_home

リスナーのOracleホーム。省略すると、Oracle Gridインフラストラクチャ・ホームが想定されます。

例

次のコマンドでは、データベースOracleホームから実行され、TCPポート1522をリスニングしているリスナー(LISTENER)を追加します。

srvctl add listener -p TCP:1522 -o /u01/app/oracle/product/11.2.0/dbhome_1

srvctl add ons

Oracle Restart構成にONSを追加します。

Oracle Data Guardのフェイルオーバーの後で高速アプリケーション通知(FAN)イベントの送信を有効にするには、ONSをOracle Restart構成に追加する必要があります。

ONSは、Oracle Restart構成に追加した時点では無効になっています。有効にするには、srvctl enable onsコマンドを使用します。

関連項目:
「srvctl enable ons」

構文およびオプション

srvctl add onsコマンドは次の構文で使用します。

srvctl add ons [-e em_port] [-l ons_local_port] [-r ons_remote_port] [-t host[:port],[host[:port]...]] [-v]

表4-13 srvctl add onsのオプション

オプション

説明

-e em_port

Oracle Enterprise ManagerのONSリスニング・ポート。デフォルトは2016です。

-l ons_local_port

ローカル・クライアント接続のONSリスニング・ポート。デフォルトは6100です。

-r ons_remote_port

リモート・ホストからの接続用のONSリスニング・ポート。デフォルトは6200です。

-t host[:port],[host[:port],...

ONSネットワークの一部であるリモート・ホストのhost:portのペアのリスト。

注意: リモート・ホストのportが指定されていない場合、ons_remote_portが使用されます。

-v

詳細出力。

srvctl add service

Oracle Restart構成にデータベース・サービスを追加します。データベース・サービスがない場合、データベース・サービスを作成します。DBMS_SERVICE PL/SQLパッケージを使用するよりも、この方法でサービスを作成することをお薦めします。

構文およびオプション

srvctl add serviceコマンドは次の構文で使用します。

srvctl add service -d db_unique_name -s service_name
[-l [PRIMARY][,PHYSICAL_STANDBY][,LOGICAL_STANDBY][,SNAPSHOT_STANDBY]]
[-y {AUTOMATIC | MANUAL}] [-e {NONE | SESSION | SELECT}] [-m {NONE | BASIC}]
[-w integer] [-z integer] [-j {SHORT | LONG}]
[-B {SERVICE_TIME | THROUGHPUT | NONE}] [-q {TRUE | FALSE}] -t edition_name

表4-14 srvctl add serviceのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-s service_name

データベース・サービス名

-l [PRIMARY][,PHYSICAL_STANDBY][,LOGICAL_STANDBY][,SNAPSHOT_STANDBY]

サービス・ロールのリスト。Oracle Data Guard環境でのみ適用できます。このオプションを指定すると、データベースのオープン時に、サービス・ロールの1つが現在のデータベース・ロールに一致する場合にのみサービスが起動されます。

-y {AUTOMATIC | MANUAL}

サービスの管理ポリシー。AUTOMATIC(デフォルト)の場合、サービスは計画された再起動(SRVCTLを使用)または障害の後、データベースの再起動時に自動的に起動されます。ただし、自動再起動はサービス・ロールの影響も受けます(-lオプション)。MANUALの場合、データベースの計画された再起動(SRVCTLを使用)時にサービスは自動的には再起動されません。MANUALを設定しても、サービスは実行中にOracle Restartで監視され、障害が発生すると再起動されます。

-e {NONE |SESSION | SELECT}

フェイルオーバーのタイプ。スタンドアロン・サーバーの場合は、Oracle Data Guard環境でのみ適用できます。

-m {NONE | BASIC}

フェイルオーバーの方法。スタンドアロン・サーバーの場合は、Oracle Data Guard環境でのみ適用できます。

-w integer

フェイルオーバーの遅延。スタンドアロン・サーバーの場合は、Oracle Data Guard環境でのみ適用できます。

-z integer

フェイルオーバーの再試行。スタンドアロン・サーバーの場合は、Oracle Data Guard環境でのみ適用できます。

-j {SHORT | LONG}

接続ロード・バランシングの目標。

-B {SERVICE_TIME | THROUGHPUT | NONE}

ランタイム・ロード・バランシングの目標。

-q {TRUE | FALSE}

Oracleアドバンスト・キューイング(AQ)HA通知を送信します。スタンドアロン・サーバーの場合は、Oracle Data Guard環境でのみ適用できます。

-t edition_name

サービスの初期セッション・エディション

サービスにエディションを指定すると、そのサービスを指定するそれ以降のすべて接続で、初期セッション・エディションとしてこのエディションが使用されます。ただし、セッション接続で異なるエディションを指定した場合は、そのセッション接続で指定したエディションが初期セッション・エディションとして使用されます。

SRVCTLは、指定されたエディション名を検証しません。接続中、接続ユーザーは指定されたエディションのUSE権限を持っている必要があります。そのエディションが存在しないか、接続ユーザーが指定されたエディションのUSE権限を持たない場合は、エラーが発生します。

例

この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのsalesサービスを追加します。dbcrmがPRIMARYモードである場合にのみ、サービスが起動されます。

srvctl add service -d dbcrm -s sales -l PRIMARY

関連項目:

- このコマンドのオプションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_SERVICEパッケージに関する項を参照してください。

- 「Oracle RestartとOracle Data Guardとの統合」

- 『Oracle Data Guard概要および管理』

config

srvctl configコマンドでは、指定したコンポーネントまたはコンポーネント・セットのOracle Restart構成を表示します。

表4-15 srvctl configの概要

コマンド

説明

srvctl config asm

Oracle ASMインスタンスのOracle Restart構成情報を表示します。

srvctl config database

指定したデータベースのOracle Restart構成情報を表示するか、またはOracle Restartで管理されているすべてのデータベースをリストします。

srvctl config listener

すべてのリスナーまたは指定したリスナーのOracle Restart構成情報を表示します。

srvctl config ons

ONSの現在の構成情報を表示します。

srvctl config service

指定したデータベースについて、指定したデータベース・サービスまたはすべてのデータベース・サービスのOracle Restart構成情報を表示します。

srvctl config asm

Oracle ASMインスタンスのOracle Restart構成情報を表示します。

構文およびオプション

srvctl config asmコマンドは次の構文で使用します。

srvctl config asm [-a]

表4-16 srvctl config asmのオプション

オプション

説明

-a

有効/無効ステータスも表示します。

例

次に、このコマンドの例を示します。

srvctl config asm -a

asm home: /u01/app/oracle/product/11.2.0/grid
ASM is enabled.

srvctl config database

指定したデータベースのOracle Restart構成情報を表示します。または、Oracle Restartで管理されているすべてのデータベースを示します。

構文およびオプション

srvctl config databaseコマンドは次の構文で使用します。

srvctl config database [-d db_unique_name [-a]]

表4-17 srvctl config databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-a

有効/無効ステータスも表示します。

例

このコマンドの次の例では、Oracle Restartで管理されているすべてのデータベースを表示します。

srvctl config database

dbcrm
orcl

このコマンドの次の例では、DB_UNIQUE_IDがorclであるデータベースの構成および有効/無効ステータスを表示します。

srvctl config database -d orcl -a

Database unique name: orcl
Database name: orcl
Oracle home: /u01/app/oracle/product/11.2.0/dbhome_1
Oracle user: oracle
Spfile: +DATA/orcl/spfileorcl.ora
Domain: us.example.com
Start options: open
Stop options: immediate
Database role:
Management policy: automatic
Disk Groups: DATA
Services: mfg,sales
Database is enabled

srvctl config listener

Oracle Restartで管理されているすべてのリスナーまたは指定したリスナーのOracle Restart構成情報を表示します。

構文およびオプション

srvctl config listenerコマンドは次の構文で使用します。

srvctl config listener [-l listener_name]

表4-18 srvctl config listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、Oracle Restartで管理されているすべてのリスナーの構成情報が表示されます。

例

この例では、デフォルト・リスナーの構成情報と有効/無効ステータスを表示します。

srvctl config listener

Name: LISTENER
Home: /u01/app/oracle/product/11.2.0/dbhome_1
End points: TCP:1521
Listener is enabled.

srvctl config ons

ONSの現在の構成情報を表示します。

構文およびオプション

srvctl config onsコマンドは次の構文で使用します。

srvctl config ons

srvctl config service

指定したデータベースについて、指定したデータベース・サービスまたはOracle Restartで管理されているすべてのデータベース・サービスのOracle Restart構成情報を表示します。

構文およびオプション

srvctl config serviceコマンドは次の構文で使用します。

srvctl config service -d db_unique_name [-s service_name] [-a]

表4-19 srvctl config serviceのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-s service_name

データベース・サービス名。省略すると、SRVCTLによって、Oracle Restartで管理されているすべてのデータベース・サービスの構成情報が表示されます。

-a

詳細な構成情報が表示されます。

例

次に、このコマンドの例を示します。

srvctl config service -d dbcrm -s sales

Service name: sales
Service is enabled
Cardinality: SINGLETON
Disconnect: true
Service role: PRIMARY
Management policy: automatic
DTP transaction: false
AQ HA notifications: false
Failover type: NONE
Failover method: NONE
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: NONE
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition: e2

disable

コンポーネントを無効にし、そのコンポーネントのOracle Restartでの管理を一時停止します。srvctl disableコマンドは、コンポーネントを修復するかメンテナンス用に停止する必要があり、自動再起動しない場合に使用します。コンポーネントを無効にすると、次のようになります。

- 自動的に再起動しなくなります。

- 依存性によって自動的に起動しなくなります。

- SRVCTLで起動できません。

srvctl disable操作を実行するには、適切なユーザー・アカウントを使用してデータベース・ホスト・コンピュータにログインする必要があります。詳細は、「SRVCTLの実行準備」を参照してください。

関連項目:
enableコマンド

表4-20 srvctl disableの概要

コマンド

説明

srvctl disable asm

Oracle ASMインスタンスを無効にします。

srvctl disable database

データベースを無効にします。

srvctl disable diskgroup

Oracle ASMディスク・グループを無効にします。

srvctl disable listener

指定したリスナーまたはすべてのリスナーを無効にします。

srvctl disable ons

ONSを無効にします。

srvctl disable service

指定したデータベースの1つ以上のデータベース・サービスを無効にします。

srvctl disable asm

Oracle ASMインスタンスを無効にします。

構文およびオプション

srvctl disable asmコマンドは次の構文で使用します。

srvctl disable asm

srvctl disable database

指定したデータベースを無効にします。

構文およびオプション

srvctl disable databaseコマンドは次の構文で使用します。

srvctl disable database -d db_unique_name

表4-21 srvctl disable databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

例

次に、このコマンドの例を示します。

srvctl disable database -d dbcrm

srvctl disable diskgroup

Oracle ASMディスク・グループを無効にします。

構文およびオプション

srvctl disable diskgroupコマンドは次の構文で使用します。

srvctl disable diskgroup -g diskgroup_name

表4-22 srvctl disable diskgroupのオプション

オプション

説明

-g diskgroup_name

ディスク・グループ名。

例

次に、このコマンドの例を示します。

srvctl disable diskgroup -g DATA

srvctl disable listener

指定したリスナーまたはすべてのリスナーを無効にします。

構文およびオプション

srvctl disable listenerコマンドは次の構文で使用します。

srvctl disable listener [-l listener_name]

表4-23 srvctl disable listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、すべてのリスナーが無効になります。

例

次に、このコマンドの例を示します。

srvctl disable listener -l crmlistener

srvctl disable ons

ONSを無効にします。

構文およびオプション

srvctl disable onsコマンドは次の構文で使用します。

srvctl disable ons -v

表4-24 srvctl disable onsのオプション

オプション

説明

-v

詳細出力。

srvctl disable service

1つ以上のデータベース・サービスを無効にします。

構文およびオプション

srvctl disable serviceコマンドは次の構文で使用します。

srvctl disable service -d db_unique_name -s service_name_list

表4-25 srvctl disable serviceのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-s service_name_list

データベース・サービス名のカンマ区切りのリスト。

例

次の例では、データベース・サービスsalesとmfgを無効にします。

srvctl disable service -d dbcrm -s sales,mfg

enable

srvctl enableコマンドでは、指定した無効なコンポーネントを再度有効にして、次の処理を実行できるようにします。

- Oracle Restartで自動再起動します。

- 依存性を介して自動起動します。

- SRVCTLを使用して手動で起動します。

コンポーネントがすでに有効になっている場合、コマンドは無視されます。

Oracle Restart構成にコンポーネントを追加すると、コンポーネントはデフォルトで有効になります。

srvctl enable操作を実行するには、適切なユーザー・アカウントを使用してデータベース・ホスト・コンピュータにログインする必要があります。詳細は、「SRVCTLの実行準備」を参照してください。

表4-26 srvctl enableの概要

コマンド

説明

srvctl enable asm

Oracle ASMインスタンスを有効化します。

srvctl enable database

データベースを有効にします。

srvctl enable diskgroup

Oracle ASMディスク・グループを有効にします。

srvctl enable listener

指定したリスナーまたはすべてのリスナーを有効にします。

srvctl enable ons

ONSを有効にします。

srvctl enable service

指定したデータベースの1つ以上のデータベース・サービスを有効にします。

関連項目:
disableコマンド

srvctl enable asm

Oracle ASMインスタンスを有効化します。

構文およびオプション

srvctl enable asmコマンドは次の構文で使用します。

srvctl enable asm

srvctl enable database

指定したデータベースを有効にします。

構文およびオプション

srvctl enable databaseコマンドは次の構文で使用します。

srvctl enable database -d db_unique_name

表4-27 srvctl enable databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

例

次に、このコマンドの例を示します。

srvctl enable database -d dbcrm

srvctl enable diskgroup

Oracle ASMディスク・グループを有効にします。

構文およびオプション

srvctl enable diskgroupコマンドは次の構文で使用します。

srvctl enable diskgroup -g diskgroup_name

表4-28 srvctl enable diskgroupのオプション

オプション

説明

-g diskgroup_name

ディスク・グループ名。

例

次に、このコマンドの例を示します。

srvctl enable diskgroup -g DATA

srvctl enable listener

指定したリスナーまたはすべてのリスナーを有効にします。

構文およびオプション

srvctl enable listenerコマンドは次の構文で使用します。

srvctl enable listener [-l listener_name]

表4-29 srvctl enable listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、すべてのリスナーが有効になります。

例

次に、このコマンドの例を示します。

srvctl enable listener -l crmlistener

srvctl enable ons

ONSを有効にします。

構文およびオプション

srvctl enable onsコマンドは次の構文で使用します。

srvctl enable ons -v

表4-30 srvctl enable onsのオプション

オプション

説明

-v

詳細出力。

srvctl enable service

指定したデータベースの1つ以上のデータベース・サービスを有効にします。

構文およびオプション

srvctl enable serviceコマンドは次の構文で使用します。

srvctl enable service -d db_unique_name -s service_name_list

表4-31 srvctl enable serviceのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-s service_name_list

データベース・サービス名のカンマ区切りのリスト。

例

次の例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのデータベース・サービスsalesとmfgを有効にします。

srvctl enable service -d dbcrm -s "sales,mfg"

getenv

データベース、リスナーまたはOracle ASMインスタンスのOracle Restart構成から環境変数とその値を取得して表示します。

表4-32 srvctl getenvの概要

コマンド

説明

srvctl getenv asm

Oracle ASMインスタンスに対して構成された環境変数を表示します。

srvctl getenv database

指定したデータベース・インスタンスに対して構成された環境変数を表示します。

srvctl getenv listener

指定したリスナーに対して構成された環境変数を表示します。

関連項目:

- setenvコマンド

- unsetenvコマンド

- 「Oracle Restart構成の環境変数の管理」

srvctl getenv asm

Oracle ASMインスタンスに対して構成された環境変数を表示します。

構文およびオプション

srvctl getenv asmコマンドは次の構文で使用します。

srvctl getenv asm [-t name_list]

表4-33 srvctl getenv asmのオプション

オプション

説明

-t name_list

表示する環境変数名のカンマ区切りのリスト。省略すると、SRVCTLによって、Oracle ASMに対して構成されたすべての環境変数が表示されます。

例

次の例では、Oracle ASMインスタンスに対して構成されたすべての環境変数を表示します。

srvctl getenv asm

srvctl getenv database

指定したデータベースに対して構成された環境変数を表示します。

構文およびオプション

srvctl getenv databaseコマンドは次の構文で使用します。

srvctl getenv database -d db_unique_name [-t name_list]

表4-34 srvctl getenv databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-t name_list

表示する環境変数名のカンマ区切りのリスト。省略すると、SRVCTLによって、構成されたすべての環境変数が表示されます。

例

次の例では、DB_UNIQUE_NAMEがdbcrmであるデータベースに対して構成されたすべての環境変数を表示します。

srvctl getenv database -d dbcrm

srvctl getenv listener

指定したリスナーに対して構成された環境変数を表示します。

構文およびオプション

srvctl getenv listenerコマンドは次の構文で使用します。

srvctl getenv listener [-l listener_name] [-t name_list]

表4-35 srvctl getenv listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、SRVCTLによって、すべてのリスナーの環境変数が表示されます。

-t name_list

表示する環境変数名のカンマ区切りのリスト。省略すると、SRVCTLによって、構成されたすべての環境変数が表示されます。

例

次の例では、crmlistenerというリスナーに対して構成されたすべての環境変数を表示します。

srvctl getenv listener -l crmlistener

modify

コンポーネントのOracle Restart構成を変更します。変更内容は、コンポーネントが次に再起動されたときに反映されます。

srvctl modify操作を実行するには、適切なユーザー・アカウントを使用してデータベース・ホスト・コンピュータにログインする必要があります。詳細は、「SRVCTLの実行準備」を参照してください。

表4-36 srvctl modifyの概要

コマンド

説明

srvctl modify asm

Oracle ASMの構成の変更

srvctl modify database

データベースの構成の変更

srvctl modify listener

指定したリスナーまたはすべてのリスナーの構成を変更します。

srvctl modify ons

ONSを変更します。

srvctl modify service

データベース・サービスの構成を変更します。

srvctl modify asm

Oracle ASMインスタンスのOracle Restart構成を変更します。

構文およびオプション

srvctl modify asmコマンドは次の構文で使用します。

srvctl modify asm [-l listener_name] [-p spfile] [-d asm_diskstring]

表4-37 srvctl modify asmのオプション

オプション

説明

-l listener_name

Oracle ASMが登録する必要があるリスナーの名前。このリスナーとの弱い依存性が確立されます。(Oracle Restartでは、Oracle ASMを起動する前にこのリスナーの起動を確認します。)

-p spfile

データベースのサーバー・パラメータ・ファイルのフルパス。省略すると、デフォルトのSPFILEが使用されます。

-d asm_diskstring

Oracle ASMディスク・グループ検出文字列。Oracle ASM検出文字列は、Oracle ASMインスタンスによって検出されるディスクのセットを制限する文字列のカンマ区切りリストです。検出文字列には、ワイルドカード文字を含めることができます。文字列のいずれかに一致するディスクのみが検出されます。

例

次に、このコマンドの例を示します。

srvctl modify asm -l crmlistener

関連項目:
Oracle ASMのディスク・グループ検出文字列の詳細は、Oracle Automatic Storage Management管理者ガイドを参照してください。

srvctl modify database

データベースのOracle Restart構成を変更します。

構文およびオプション

srvctl modify databaseコマンドは次の構文で使用します。

srvctl modify database -d db_unique_name [-o oracle_home] [-u oracle_user]
[-m domain_name] [-n db_name] [-i instance_name]
[-p spfile] [-s start_options]
[-t stop_options] [-r {PRIMARY | PHYSICAL_STANDBY | LOGICAL_STANDBY |
SNAPSHOT_STANDBY}] [-y {automatic | manual}] [-a disk_group_list] [-z]

表4-38 srvctl modify databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-u oracle_user

Oracleホーム・ディレクトリを所有するOracleユーザーの名前。

-z

Oracle ASMディスク・グループに対するデータベースの依存性を削除します。

(他のオプション)

表4-11を参照してください。

例

次の例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのロールをLOGICAL_STANDBYに変更します。

srvctl modify database -d dbcrm -r logical_standby

関連項目:

- 「Oracle RestartとOracle Data Guardとの統合」

- 『Oracle Data Guard概要および管理』

srvctl modify listener

指定したリスナーまたはすべてのリスナーのOracle Restart構成を変更します。

構文およびオプション

srvctl modify listenerコマンドは次の構文で使用します。

srvctl modify listener [-l listener_name] [-p endpoints] [-o Oracle_home]

表4-39 srvctl modify listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、すべてのリスナー構成が変更されます。

-p endpoints

カンマ区切りのTCPポートまたはリスナー・エンドポイント。endpointsの構文は次のとおりです。

"[TCP:]port[, ...] [/IPC:key] [/NMP:pipe_name] [/TCPS:s_port] [/SDP:port]"

-o Oracle_home

リスナーの新しいOracleホーム。

例

この例では、crmlistenerというリスナーがリスニングしているTCPポートを変更します。

srvctl modify listener -l crmlistener -p TCP:1522

srvctl modify ons

ONSを変更します。

構文およびオプション

srvctl modify onsコマンドは次の構文で使用します。

srvctl modify ons [-e em_port] [-l ons_local_port] [-r ons_remote_port] [-t host[:port],[host[:port]...]] [-v]

表4-40 srvctl modify onsのオプション

オプション

説明

-e em_port

Oracle Enterprise ManagerのONSリスニング・ポート。デフォルトは2016です。

-l ons_local_port

ローカル・クライアント接続のONSリスニング・ポート。

-r ons_remote_port

リモート・ホストからの接続用のONSリスニング・ポート。

-t host[:port],[host[:port],...

ONSネットワークの一部であるリモート・ホストのhost:portのペアのリスト。

注意: リモート・ホストのportが指定されていない場合、ons_remote_portが使用されます。

-v

詳細出力。

srvctl modify service

データベース・サービスのOracle Restart構成を変更します。

注意:
構成変更は必要最小限にすること、およびオンライン・サービス変更の進行中は他のサービス操作を実行しないことをお薦めします。

構文およびオプション

srvctl modify serviceコマンドは次の構文で使用します。

srvctl modify service -d db_unique_name -s service_name]
[-l [PRIMARY][,PHYSICAL_STANDBY][,LOGICAL_STANDBY][,SNAPSHOT_STANDBY]]
[-y {AUTOMATIC | MANUAL}] [-e {NONE | SESSION | SELECT}] [-m {NONE | BASIC}]
[-w integer] [-z integer] [-j {SHORT | LONG}]
[-B {SERVICE_TIME | THROUGHPUT | NONE}] [-q {TRUE | FALSE}] -t edition_name

表4-41 srvctl modify serviceのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-s service_name

サービス名。

-t edition_name

サービスの初期セッション・エディション

このオプションを指定しない場合、サービスのエディションは変更されません。

このオプションが指定されているものの、edition_nameが空である場合、エディションはNULLに設定されます。NULLのエディションには効果がありません。

サービスにエディションを指定すると、そのサービスを指定するそれ以降のすべて接続で、初期セッション・エディションとしてこのエディションが使用されます。ただし、セッション接続で異なるエディションを指定した場合は、そのセッション接続で指定したエディションが初期セッション・エディションとして使用されます。

SRVCTLは、指定されたエディション名を検証しません。接続中、接続ユーザーは指定されたエディションのUSE権限を持っている必要があります。そのエディションが存在しないか、接続ユーザーが指定されたエディションのUSE権限を持たない場合は、エラーが発生します。

(他のオプション)

表4-14を参照してください。

例

次のコマンドでは、DB_UNIQUE_NAMEがdbcrmであるデータベースで、supportというデータベース・サービスのOracle Data Guardロールをstandbyに変更します。

srvctl modify service -d dbcrm -s support -l standby

remove

Oracle Restart構成から指定したコンポーネントを削除します。コンポーネントはOracle Restartで管理されなくなります。コンポーネントの環境変数設定も削除されます。

Oracle Restart構成からコンポーネントを削除する前に、SRVCTLを使用してコンポーネントを停止する必要があります。コンポーネントは削除前に無効にすることをお薦めしますが、必須ではありません。

srvctl remove操作を実行するには、適切なユーザー・アカウントを使用してデータベース・ホスト・コンピュータにログインする必要があります。詳細は、「SRVCTLの実行準備」を参照してください。

表4-42 srvctl removeの概要

コマンド

説明

srvctl remove asm

Oracle ASMインスタンスを削除します。

srvctl remove database

データベースを削除します。

srvctl remove diskgroup

Oracle ASMディスク・グループを削除します。

srvctl remove listener

リスナーを削除します。

srvctl remove ons

ONSを削除します。

srvctl remove service

1つ以上のデータベース・サービスを削除します。

関連項目:

- stopコマンド

- disableコマンド

srvctl remove asm

Oracle ASMインスタンスを削除します。

構文およびオプション

srvctl remove asmコマンドは次の構文で使用します。

srvctl remove asm  [-f]

表4-43 srvctl remove asmのオプション

オプション

説明

-f

Oracle ASMを使用するディスク・グループおよびデータベースが存在する場合、またはOracle ASMインスタンスが実行中の場合でも、強制的に削除します。

例

次に、このコマンドの例を示します。

srvctl remove asm

srvctl remove database

データベースを削除します。最初に確認のプロンプトを表示します。

構文およびオプション

srvctl remove databaseコマンドは次の構文で使用します。

srvctl remove database -d db_unique_name [-f] [-y] [-v]

表4-44 srvctl remove databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-f

強制。実行中でもデータベースを削除します。

-y

確認のプロンプトを表示せず、即時削除します。

-v

詳細出力。成功または失敗のメッセージが表示されます。

例

次に、このコマンドの例を示します。

srvctl remove database -d dbcrm

srvctl remove diskgroup

Oracle ASMディスク・グループを削除します。

構文およびオプション

srvctl remove diskgroupコマンドは次の構文で使用します。

srvctl remove diskgroup -g diskgroup_name [-f]

表4-45 srvctl remove diskgroupのオプション

オプション

説明

-g diskgroup_name

ディスク・グループ名。

-f

強制。ファイルが開いていてもディスク・グループを削除します。

例

この例では、DATAというディスク・グループを削除します。このディスク・グループでファイルが開いている場合、エラーが返されます。

srvctl remove diskgroup -g DATA

srvctl remove listener

指定したリスナーまたはすべてのリスナーを削除します。

構文およびオプション

srvctl remove listenerコマンドは次の構文で使用します。

srvctl remove listener [-l listener_name] [-a] [-f]

表4-46 srvctl remove listenerのオプション

オプション

説明

-l listener_name

削除するリスナーの名前。省略すると、デフォルトのLISTENERが使用されます。

-a

すべてのリスナーを削除します。

-f

強制。データベースで使用されていてもリスナーを削除します。

例

次のコマンドではリスナーlsnr01を削除します。

srvctl remove listener -l lsnr01

srvctl remove ons

ONSを削除します。

構文およびオプション

srvctl remove onsコマンドは次のように使用します。

srvctl remove ons -f -v

表4-47 srvctl remove onsのオプション

オプション

説明

-f

強制。有効なONSも削除します。

-v

詳細出力。

srvctl remove service

指定したデータベース・サービスを削除します。

構文およびオプション

srvctl remove serviceコマンドは次のように使用します。

srvctl remove service -d db_unique_name -s service_name]

表4-48 srvctl remove serviceのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-s service_name

サービス名。

例

次に、このコマンドの例を示します。

srvctl remove service -d dbcrm -s sales

setenv

setenvコマンドでは、データベース、リスナーまたはOracle ASMインスタンスのOracle Restart構成に環境変数の値を設定します。

srvctl setenv操作を実行するには、適切なユーザー・アカウントを使用してデータベース・ホスト・コンピュータにログインする必要があります。詳細は、「SRVCTLの実行準備」を参照してください。

表4-49 srvctl setenvおよびunsetenvの概要

コマンド

説明

srvctl setenv asm

Oracle ASMインスタンスのOracle Restart構成に環境変数を設定します。

srvctl setenv database

データベース・インスタンスのOracle Restart構成に環境変数を設定します。

srvctl setenv listener

指定したリスナーまたはすべてのリスナーのOracle Restart構成に環境変数を設定します。

関連項目:

- getenvコマンド

- unsetenvコマンド

- 「Oracle Restart構成の環境変数の管理」

srvctl setenv asm

Oracle ASMインスタンスのOracle Restart構成に環境変数の値を設定します。Oracle Restartでは、インスタンスを起動する前に、環境変数を構成に格納された値に設定します。

構文およびオプション

srvctl setenv asmコマンドは次の構文で使用します。

srvctl setenv asm {-t name=val[,name=val,...] | -T name=val}

表4-50 srvctl setenv databaseのオプション

オプション

説明

-t name=val[,name=val,...]

環境変数の名前と値のペアのカンマ区切りのリスト。

-T name=val

単一環境変数をカンマや他の特殊文字を含む値に設定可能にする

例

次の例では、AIXオペレーティング・システムの環境変数AIXTHREAD_SCOPEをOracle ASMインスタンスの構成に設定します。

srvctl setenv asm -t AIXTHREAD_SCOPE=S

srvctl setenv database

データベース・インスタンスのOracle Restart構成に環境変数の値を設定します。Oracle Restartでは、インスタンスを起動する前に、環境変数を構成に格納された値に設定します。

構文およびオプション

srvctl setenv databaseコマンドは次の構文で使用します。

srvctl setenv database -d db_unique_name {-t name=val[,name=val,...] |
-T name=val}

表4-51 srvctl setenv databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-t name=val[,name=val,...]

環境変数の名前と値のペアのカンマ区切りのリスト。

-T name=val

単一環境変数をカンマや他の特殊文字を含む値に設定可能にする

例

次の例では、DB_UNIQUE_NAMEがdbcrmであるデータベースの構成にLANG環境変数を設定します。

srvctl setenv database -d dbcrm -t LANG=en

srvctl setenv listener

リスナーのOracle Restart構成に環境変数の値を設定します。Oracle Restartでは、リスナーを起動する前に、環境変数を構成に格納された値に設定します。

構文およびオプション

srvctl setenv listenerコマンドは次の構文で使用します。

srvctl setenv listener [-l listener_name] {-t name=val[,name=val,...] |
-T name=val}

表4-52 srvctl setenv listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、すべてのリスナー構成に指定した環境変数が設定されます。

-t name=val[,name=val,...]

環境変数の名前と値のペアのカンマ区切りのリスト。

-T name=val

単一環境変数をカンマや他の特殊文字を含む値に設定可能にする

例

次の例では、AIXオペレーティング・システムの環境変数AIXTHREAD_SCOPEをcrmlistenerというリスナーの構成に設定します。

srvctl setenv listener -l crmlistener -t AIXTHREAD_SCOPE=S

start

指定したコンポーネントを起動します。

表4-53 srvctl startの概要

コマンド

説明

srvctl start asm

Oracle ASMインスタンスを起動します。

srvctl start database

指定したデータベースを起動します。

srvctl start diskgroup

指定したOracle ASMディスク・グループを起動(マウント)します。

srvctl start home

Oracle Restartで管理されているすべてのコンポーネントを、指定したOracleホーム内で起動します。

srvctl start listener

指定したリスナーまたはOracle Restartで管理されているすべてのリスナーを起動します。

srvctl start ons

ONSを起動します。

srvctl start service

指定したデータベース・サービスを起動します。

関連項目:
「Oracle Restartで管理されているコンポーネントの起動と停止」

srvctl start asm

Oracle ASMインスタンスを起動します。

このコマンドでは、SRVCTLは"/ as sysasm"で接続して操作を実行します。このような操作を実行するには、Oracle Gridインフラストラクチャ・ホームの実行可能ファイルの所有者がOSASMグループのメンバーであることが必要です。また、コマンドを実行するユーザーもOSASMグループに属する必要があります。

構文およびオプション

srvctl start asmコマンドは次の構文で使用します。

srvctl start asm [-o start_options]

表4-54 srvctl start asmのオプション

オプション

説明

-o start_options

起動コマンドのオプションのカンマ区切りのリスト(OPEN、MOUNT、NOMOUNTまたはFORCE)。省略すると、デフォルトで通常の起動(OPEN)に設定されます。

例

この例では、Oracle ASMインスタンスを起動します。その後、ASM_DISKGROUPS初期化パラメータで指定されたディスク・グループをマウントします。

srvctl start asm

この例では、ディスク・グループをマウントせずにOracle ASMインスタンスを起動します。

srvctl start asm -o nomount

srvctl start database

指定したデータベース・インスタンスを起動します。

このコマンドでは、SRVCTLは"/ as sysdba"で接続して操作を実行します。このような操作を実行するには、データベースOracleホームのOracle実行可能ファイルの所有者がOSDBAグループ(たとえば、UNIXおよびLinuxのdbaグループ)のメンバーであることが必要です。また、コマンドを実行するユーザーもOSDBAグループに属する必要があります。

構文およびオプション

srvctl start databaseコマンドは次の構文で使用します。

srvctl start database -d db_unique_name [-o start_options]

表4-55 srvctl start databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-o start_options

起動コマンドのオプションのカンマ区切りのリスト(たとえば、OPEN、MOUNT、NOMOUNT、RESTRICTなど)。

注意:

- このコマンド・パラメータではPFILEオプションまたはQUIETオプションをサポートしていませんが、他のすべてのデータベース起動オプションをサポートしています。

- 起動オプションに複数の語を指定する場合(read only、read writeなど)、語をスペースで区切り、一重引用符('')で囲みます。たとえば'read only'とします。
関連項目: 起動オプションの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

例

次に、このコマンドの例を示します。

srvctl start database -d dbcrm -o nomount

srvctl start diskgroup

Oracle ASMディスク・グループを起動(マウント)します。

構文およびオプション

srvctl start diskgroupコマンドは次の構文で使用します。

srvctl start diskgroup -g diskgroup_name

表4-56 srvctl start diskgroupのオプション

オプション

説明

-g diskgroup_name

ディスク・グループ名。

例

次に、このコマンドの例を示します。

srvctl start diskgroup -g DATA

srvctl start home

Oracle Restartで管理されているすべてのコンポーネントを、指定したOracleホーム内で起動します。OracleホームはOracle DatabaseホームまたはOracle Gridインフラストラクチャ・ホームです。

このコマンドではsrvctl stop homeによって停止されたコンポーネントを起動します。このコマンドでは指定した状態ファイルの情報を使用して、起動するコンポーネントを特定します。

注意:
このコマンドは、Oracleホームにパッチをインストールした後にコンポーネントを再起動するときに使用します。

構文およびオプション

srvctl start homeコマンドは次の構文で使用します。

srvctl start home -o oracle_home -s state_file

表4-57 srvctl start homeのオプション

オプション

説明

-o

Oracleホームの完全なパス。

-s

状態ファイルの完全なパス。状態ファイルにはOracleホームにあるコンポーネントの現在の状態情報が入ります。srvctl stop homeコマンドまたはsrvctl status homeコマンドが実行されると、このファイルが作成されます。

srvctl start listener

指定したリスナーまたはすべてのリスナーを起動します。

構文およびオプション

srvctl start listenerコマンドは次の構文で使用します。

srvctl start listener [-l listener_name]

表4-58 srvctl start listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、Oracle Restartで管理されているすべてのリスナーが起動されます。

例

次に、このコマンドの例を示します。

srvctl start listener -l listener

srvctl start ons

ONSを起動します。

構文およびオプション

srvctl start onsコマンドは次の構文で使用します。

srvctl start ons -v

表4-59 srvctl start onsのオプション

オプション

説明

-v

詳細出力。

srvctl start service

指定したデータベース・サービスを起動します。

構文およびオプション

srvctl start serviceコマンドは次の構文で使用します。

srvctl start service -d db_unique_name [-s service_name_list] [-o start_options]

表4-60 srvctl start serviceのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-s service_name_list

サービス名のカンマ区切りリスト。このサービス名リストはオプションであり、指定しないと、SRVCTLでデータベースのサービスがすべて起動されます。

-o start_options

データベースを最初に起動する必要がある場合、データベースの起動オプション(OPEN、MOUNT、NOMOUNTなど)。

例

次の例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのsalesデータベース・サービスを起動します。

srvctl start service -d dbcrm -s sales

status

指定したコンポーネントまたはコンポーネント・セットの実行ステータスを表示します。

表4-61 srvctl statusの概要

コマンド

説明

srvctl status asm

Oracle ASMインスタンスの実行ステータスを表示します。

srvctl status database

データベースの実行ステータスを表示します。

srvctl status diskgroup

Oracle ASMディスク・グループの実行ステータスを表示します。

srvctl status home

Oracle Restartで管理されているすべてのコンポーネントの実行ステータスを、指定したOracleホーム内で表示します。

srvctl status listener

指定したリスナーまたはOracle Restartで管理されているすべてのリスナーの実行ステータスを表示します。

srvctl status ons

ONSの実行ステータスを表示します。

srvctl status service

1つ以上のサービスの実行ステータスを表示します。

srvctl status asm

Oracle ASMインスタンスの実行ステータスを表示します。

構文およびオプション

srvctl status asmコマンドは次の構文で使用します。

srvctl status asm [-a]

表4-62 srvctl status asmのオプション

オプション

説明

-a

有効/無効ステータスも表示します。

例

次に、このコマンドの例を示します。

srvctl status asm

ASM is running on dbhost

srvctl status database

指定したデータベースの実行ステータスを表示します。

構文およびオプション

srvctl status databaseコマンドは次の構文で使用します。

srvctl status database -d db_unique_name [-f] [-v]

表4-63 srvctl status databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-f

データベースが無効な場合、メッセージを表示します。

-v

詳細出力。実行中のデータベース・サービスを一覧表示します。

例

次に、このコマンドの例を示します。

srvctl status database -d dbcrm -v

Database dbcrm is running with online services mfg,sales

srvctl status diskgroup

Oracle ASMディスク・グループの実行ステータスを表示します。

構文およびオプション

srvctl status diskgroupコマンドは次の構文で使用します。

srvctl status diskgroup -g diskgroup_name [-a]

表4-64 srvctl status diskgroupのオプション

オプション

説明

-g diskgroup_name

ディスク・グループ名。

-a

有効/無効ステータスも表示します。

例

次に、このコマンドの例を示します。

srvctl status diskgroup -g DATA

Disk Group DATA is running on dbhost

srvctl status home

Oracle Restartで管理されているすべてのコンポーネントの実行ステータスを、指定したOracleホーム内で表示します。OracleホームはOracle DatabaseホームまたはOracle Gridインフラストラクチャ・ホームです。

このコマンドではコンポーネントの現在のステータスを指定した状態ファイルに書き込みます。

構文およびオプション

srvctl status homeコマンドは次の構文で使用します。

srvctl status home -o oracle_home -s state_file

表4-65 srvctl status homeのオプション

オプション

説明

-o

Oracleホームの完全なパス。

-s

状態ファイルの完全なパス。

srvctl status listener

指定したリスナーまたはOracle Restartで管理されているすべてのリスナーの実行ステータスを表示します。

構文およびオプション

srvctl status listenerコマンドは次の構文で使用します。

srvctl status listener -l listener_name

表4-66 srvctl status listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、すべてのリスナーのステータスが表示されます。

例

次に、このコマンドの例を示します。

srvctl status listener -l crmlistener

Listener CRMLISTENER is running on dbhost

srvctl status ons

ONSの実行ステータスを表示します。

構文およびオプション

srvctl status onsコマンドは次の構文で使用します。

srvctl status ons

srvctl status service

1つ以上のデータベース・サービスの実行ステータスを表示します。

構文およびオプション

srvctl status serviceコマンドは次の構文で使用します。

srvctl status service -d db_unique_name [-s service_name_list] [-f] [-v]

表4-67 srvctl status serviceのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-s service_name_list

サービス名のカンマ区切りリスト。省略すると、指定されたデータベースの全データベース・サービスのステータスが一覧表示されます。

-f

サービスが無効な場合、メッセージを表示します。

-v

詳細出力。

例

次の例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのサービスsalesの実行のステータスを表示します。

srvctl status service -d dbcrm -s sales

Service sales is running on dbhost

stop

指定したコンポーネントを停止します。

srvctl stopコマンドを発行した後にコンポーネントを停止状態のままにする場合、コンポーネントを無効にします。disableコマンドを参照してください。

注意:
コンポーネントを停止しても無効にしていない場合は、計画された別の操作の結果として再起動されることがあります。つまり、停止されたコンポーネントは障害の結果として再起動されることはありませんが、srvctl startコマンドで依存コンポーネントが起動されると、起動されることがあります。

表4-68 srvctl stopの概要

コマンド

説明

srvctl stop asm

Oracle ASMインスタンスを停止します。

srvctl stop database

指定したデータベース・インスタンスを停止します。

srvctl stop diskgroup

指定したOracle ASMディスク・グループを停止(ディスマウント)します。

srvctl stop home

Oracle Restartで管理されているすべてのコンポーネントを、指定したOracleホーム内で停止します。

srvctl stop listener

指定したリスナーまたはすべてのリスナーを停止します。

srvctl stop ons

ONSを停止します。

srvctl stop service

指定したデータベース・サービスを停止します。

関連項目:
「Oracle Restartで管理されているコンポーネントの起動と停止」

srvctl stop asm

Oracle ASMインスタンスを停止します。

構文およびオプション

srvctl stop asmコマンドは次の構文で使用します。

srvctl stop asm [-o stop_options] [-f]

表4-69 srvctl stop asmのオプション

オプション

説明

-o stop_options

停止操作のオプション(NORMAL、TRANSACTIONAL、IMMEDIATE、ABORTなど)。

-f

強制。ディスク・グループが現在起動済(マウント済)の場合は、指定しておく必要があります。このオプションを指定すると、Oracle ASMを停止する前に、SRVCTLがディスク・グループを停止できるようになります。依存関係にある各データベース・インスタンスも停止オプションに従って停止されますが、構成されている停止オプションが失敗した場合は、ABORTオプションで停止されます。

例

次に、このコマンドの例を示します。

srvctl stop asm -o abort -f

srvctl stop database

データベースを停止します。

構文およびオプション

srvctl stop databaseコマンドは次の構文で使用します。

srvctl stop database -d db_unique_name [-o stop_options] [-f]

表4-70 srvctl stop databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-o stop_options

SHUTDOWNコマンド・オプション(NORMAL、TRANSACTIONAL、IMMEDIATE、ABORTなど)。デフォルトはIMMEDIATEです。

-f

強制。データベース、そのサービス、およびそのサービスに依存するリソースを停止します。

例

次に、このコマンドの例を示します。

srvctl stop database -d dbcrm

srvctl stop diskgroup

Oracle ASMディスク・グループを停止(ディスマウント)します。

構文およびオプション

srvctl stop diskgroupコマンドは次の構文で使用します。

srvctl stop diskgroup -g diskgroup_name [-f]

表4-71 srvctl stop diskgroupのオプション

オプション

説明

-g diskgroup_name

ディスク・グループ名。

-f

強制。ディスク・グループの一部のファイルが開いている場合でも、ディスク・グループをディスマウントします。

例

この例では、DATAというディスク・グループを停止します。このディスク・グループでファイルが開いている場合、エラーが返されます。

srvctl stop diskgroup -g DATA

srvctl stop home

Oracle Restartで管理されているすべてのコンポーネントを、指定したOracleホーム内で停止します。OracleホームはOracle DatabaseホームまたはOracle Gridインフラストラクチャ・ホームです。

このコマンドでは指定した状態ファイルで停止したコンポーネントを特定します。

注意:

- Oracle Gridインフラストラクチャ・ホームのコンポーネントを停止する前に、依存するOracle Databaseホームのコンポーネントを停止します。

- このコマンドは、Oracleホームにパッチをインストールする前にコンポーネントを停止するときに使用します。

構文およびオプション

srvctl stop homeコマンドは次の構文で使用します。

srvctl stop home -o oracle_home -s state_file [-t stop_options] [-f]

表4-72 srvctl stop homeのオプション

オプション

説明

-o

Oracleホームの完全なパス。

-s

状態ファイルの完全なパス。

-t stop_options

データベースのSHUTDOWNコマンド・オプション(NORMAL、TRANSACTIONAL、IMMEDIATE、ABORTなど)。デフォルトはIMMEDIATEです。

-f

強制的に各コンポーネントを停止します。

srvctl stop listener

指定したリスナーまたはOracle Restartで管理されているすべてのリスナーを停止します。リスナーを停止しても、リスナーに登録されたデータベースは停止されません。

構文およびオプション

srvctl stop listenerコマンドは次の構文で使用します。

srvctl stop listener [-l listener_name] [-f]

表4-73 srvctl stop listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、Oracle Restartで管理されているすべてのリスナーが停止されます。

-f

強制。-fオプションを指定したstopコマンドをOracle Clusterwareに渡します。Oracle Clusterwareの-fオプションの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

例

次に、このコマンドの例を示します。

srvctl stop listener -l crmlistener

srvctl stop ons

ONSを停止します。

構文およびオプション

srvctl stop onsコマンドは次の構文で使用します。

srvctl stop ons -v

表4-74 srvctl stop onsのオプション

オプション

説明

-v

詳細出力。

srvctl stop service

1つ以上のデータベース・サービスを停止します。

構文およびオプション

srvctl stop serviceコマンドは次の構文で使用します。

srvctl stop service -d db_unique_name [-s service_name_list] [-f]

表4-75 srvctl stop serviceのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-s service_name_list

データベース・サービス名のカンマ区切りのリスト。サービス名リストを指定しない場合、SRVCTLによって、データベースのすべてのサービスが停止されます。

-f

強制。このオプションでは、停止したすべてのサービスのセッションが即座に切断されます。コミットされていないトランザクションはロールバックされます。このオプションを指定しないと、アクティブなセッションはサービスに接続されたままになりますが、それ以上サービスには接続できなくなります。

例

次の例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのsalesデータベース・サービスを停止します。

srvctl stop service -d dbcrm -s sales

unsetenv

unsetenvコマンドでは、データベース、リスナーまたはOracle ASMインスタンスのOracle Restart構成から1つ以上の環境変数を削除します。

srvctl unsetenv操作を実行するには、適切なユーザー・アカウントを使用してデータベース・ホスト・コンピュータにログインする必要があります。詳細は、「SRVCTLの実行準備」を参照してください。

表4-76 srvctl unsetenvコマンドの概要

コマンド

説明

srvctl unsetenv asm

Oracle ASMインスタンスのOracle Restart構成から指定した環境変数を削除します。

srvctl unsetenv database

データベースのOracle Restart構成から指定した環境変数を削除します。

srvctl unsetenv listener

指定したリスナーまたはすべてのリスナーのOracle Restart構成から指定した環境変数を削除します。

関連項目:

- setenvコマンド

- getenvコマンド

- 「Oracle Restart構成の環境変数の管理」

srvctl unsetenv asm

Oracle ASMインスタンスのOracle Restart構成から指定した環境変数を削除します。

構文およびオプション

srvctl unsetenv asmコマンドは次の構文で使用します。

srvctl unsetenv asm -t name_list

表4-77 srvctl unsetenv asmのオプション

オプション

説明

-t name_list

削除する環境変数のカンマ区切りのリスト

例

次の例では、AIXオペレーティング・システムの環境変数AIXTHREAD_SCOPEをOracle ASMインスタンスの構成から削除します。

srvctl unsetenv asm -t AIXTHREAD_SCOPE

srvctl unsetenv database

指定したデータベースのOracle Restart構成から指定した環境変数を削除します。

構文およびオプション

srvctl unsetenv databaseコマンドは次のように使用します。

srvctl unsetenv database -d db_unique_name -t name_list

表4-78 srvctl unsetenv databaseのオプション

オプション

説明

-d db_unique_name

データベースの一意の名前。DB_UNIQUE_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEが指定されていない場合、このオプションはDB_NAME初期化パラメータの設定に一致する必要があります。DB_UNIQUE_NAMEのデフォルト設定ではDB_NAMEの設定を使用します。

-t name_list

削除する環境変数のカンマ区切りのリスト

例

次の例では、DB_UNIQUE_NAMEがdbcrmであるデータベースのOracle Restart構成からAIXTHREAD_SCOPE環境変数を削除します。

srvctl unsetenv database -d dbcrm -t AIXTHREAD_SCOPE

srvctl unsetenv listener

指定したリスナーまたはすべてのリスナーのOracle Restart構成から指定した環境変数を削除します。

構文およびオプション

srvctl unsetenv listenerコマンドは次の構文で使用します。

srvctl unsetenv listener [-l listener_name] -t name_list

表4-79 srvctl unsetenv listenerのオプション

オプション

説明

-l listener_name

リスナー名。省略すると、すべてのリスナーの構成から指定した環境変数が削除されます。

-t name_list

削除する環境変数のカンマ区切りのリスト

例

次の例では、crmlistenerというリスナーのリスナー構成からAIXオペレーティング・システムの環境変数AIXTHREAD_SCOPEを削除します。

srvctl unsetenv listener -l crmlistener -t AIXTHREAD_SCOPE

CRSCTLコマンド・リファレンス

ここでは、Oracle Restartに関係するCRSCTLコマンドの構文に関して詳しく説明します。

注意:
これらのCRSCTLコマンドを実行するには、rootユーザーであるか、またはOracle Gridインフラストラクチャの所有者である必要があります。

CRSCTLコマンド構文の概要

CRSCTLでは、次のコマンド構文が想定されます。

crsctl command has

commandはstart、stop、enableなどの動詞です。hasオブジェクトはOracle高可用性サービスを示します。コマンドの詳細なリストは、表4-80を参照してください。

大/小文字の区別

CRSCTLコマンドとコンポーネントでは大/小文字が区別されません。

表4-80 CRSCTLコマンドの概要

コマンド

説明

check

Oracle Restartの状態を表示します。

config

Oracle Restartの構成を表示します。

disable

Oracle Restartの自動再起動を無効化します。

enable

Oracle Restartの自動再起動を有効化します。

start

Oracle Restartを起動します。

stop

Oracle Restartを停止します。

check

Oracle Restartの状態を表示します。

構文およびオプション

crsctl check has

config

Oracle Restartの構成を表示します。

構文およびオプション

crsctl config has

disable

Oracle Restartの自動再起動を無効化します。

構文およびオプション

crsctl disable has

enable

Oracle Restartの自動再起動を有効化します。

構文およびオプション

crsctl enable has

start

Oracle Restartを起動します。

構文およびオプション

crsctl start has

stop

Oracle Restartを停止します。

構文およびオプション

crsctl stop has [-f]

表4-81 crsctl stop hasのオプション

オプション

説明

-f

強制。Oracle Restartで管理されるリソースがまだ実行中の場合は、それらのリソースを正常に停止しようとします。リソースを正常に停止できない場合は、リソースを強制的に停止しようとします。

たとえば、Oracle ASMインスタンスが実行中の場合、SHUTDOWN IMMEDIATEではOracle ASMインスタンスを正常に停止しようとしますが、SHUTDOWN ABORTではOracle ASMインスタンスを強制的に停止しようとします。

-fオプションが指定されていない場合、このコマンドはOracle Restartで管理されるリソースを正常に停止しようとしますが、強制的に停止しようとはしません。

5 プロセスの管理

この章の内容は、次のとおりです。

- 専用サーバー・プロセスと共有サーバー・プロセスの概要

- データベース常駐接続プーリングの理解

- Oracle Databaseの共有サーバー構成

- データベース常駐接続プーリングの構成

- Oracle Databaseバックグラウンド・プロセスの概要

- SQLのパラレル実行用プロセスの管理

- 外部プロシージャのプロセスの管理

- セッションの停止

- プロセスおよびセッションのデータ・ディクショナリ・ビュー

専用サーバー・プロセスと共有サーバー・プロセスの概要

Oracle Databaseでは、インスタンスに接続されているユーザー・プロセスの要求を処理するために、サーバー・プロセスが作成されます。サーバー・プロセスには、次の2つのプロセスがあります。

- 専用サーバー・プロセス。単一のユーザー・プロセスのみを処理します。

- 共有サーバー・プロセス。複数のユーザー・プロセスを処理できます。

データベースでは、専用サーバー・プロセスは常に使用可能な状態ですが、共有サーバーは、1つ以上の初期化パラメータを特別に設定して、構成および使用可能にする必要があります。

専用サーバー・プロセス

図5-1「Oracle Databaseの専用サーバー・プロセス」は、専用サーバー・プロセスの動作の仕組みを示しています。この図では、専用サーバー・プロセスを介して、2つのユーザー・プロセスがデータベースに接続されています。

一般的には、共有サーバーを使用し、ディスパッチャを介して接続することをお薦めします。これは、図5-2「Oracle Databaseの共有サーバー・プロセス」に図示されています。共有サーバー・プロセスは、実行中のインスタンスに必要なプロセスの数を少なくできるため、効率が向上します。

ただし、次の状況では、ユーザーと管理者は、専用サーバー・プロセスを使用して明示的にインスタンスに接続する必要があります。

- バッチ・ジョブを実行する場合(たとえば、ジョブがサーバー・プロセスに対して持つアイドル時間がほとんどないか、まったくない場合)

- Recovery Manager(RMAN)を使用して、データベースをバックアップ、リストアまたはリカバリする場合

Oracle Databaseが共有サーバー用に構成されている場合に専用サーバー接続を要求するには、専用サーバーを使用するように構成されているネット・サービス名を使用して接続する必要があります。具体的に言うと、ネット・サービス名の接続記述子にSERVER=DEDICATED句を含めます。

関連項目:
専用サーバー接続を要求する方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

図5-1 Oracle Databaseの専用サーバー・プロセス

共有サーバー・プロセス

専用サーバー・プロセスを使用した注文入力システムを例にとって考えてみます。顧客が注文受付に電話で商品を注文すると、担当者はその注文をデータベースに入力します。取引のほとんどの間、担当者は顧客と電話で話しています。この間、サーバー・プロセスは必要ないため、担当者のユーザー・プロセス専用のサーバー・プロセスはアイドル状態のままです。アイドル状態のサーバー・プロセスはシステム・リソースを保持しているため、他の担当者が注文を入力する際にシステムのパフォーマンスが低下します。

共有サーバー・アーキテクチャでは、接続ごとに専用サーバー・プロセスは必要ありません(図5-2を参照)。

図5-2 Oracle Databaseの共有サーバー・プロセス

共有サーバー構成を使用する場合、クライアントのユーザー・プロセスはディスパッチャに接続します。ディスパッチャは複数のクライアント接続を同時にサポートできます。各クライアント接続はバーチャル・サーキットにバインドされており、これはディスパッチャが使用する共有メモリーの1つで、クライアント・データベースの接続要求および応答を目的としています。ディスパッチャは、リクエストが到着するとバーチャル・サーキットを共通キューに配置します。

アイドル状態の共有サーバー・プロセスは、共通キューからバーチャル・サーキットを選択して要求を処理し、そのバーチャル・サーキットを解放して、共通キューから別のバーチャル・サーキットを取り出します。このアプローチでは、小さいサーバー・プロセス・プールで大量のクライアントを処理することが可能です。専用サーバー・モデルと比較した共有サーバー・アーキテクチャの大きな利点は、システム・リソースが少なくて済むため、ユーザー数の増加に対応できることです。

さらにリソース管理を向上するために、共有サーバーに接続プーリングを構成できます。接続プーリングを使用すると、データベース・サーバーがプロトコル接続をタイムアウトし、それらの接続でアクティブなセッションを処理できるようになり、ディスパッチャがサポートできるユーザー数が増加します。さらに、共有サーバーにセッション多重化を構成し、これによってオペレーティング・システムのリソースを節約するために、単一のネットワーク接続で通信用の複数のセッションを結合します。

共有サーバー・アーキテクチャには、Oracle Net Servicesが必要です。共有サーバーを使用するユーザー・プロセスは、Oracle Databaseインスタンスと同じシステム上にある場合でも、必ずOracle Net Servicesを介して接続してください。

関連項目:
共有サーバーの詳細は、接続プーリングやセッションの多重化などの機能も含めて、『Oracle Database Net Services管理者ガイド』を参照してください。

データベース常駐接続プーリングの理解

データベース常駐接続プーリング(DRCP)は、データベース接続を取得し、比較的短時間の処理を実行した後、データベース接続を解放するような一般的なWebアプリケーション使用に対して、データベース・サーバーの接続プールを提供します。DRCPは専用サーバーをプールします。プール・サーバーは、サーバー・フォアグラウンド・プロセスとデータベース・セッションの組合せに相当します。

DRCPは、中間層プロセス内のスレッド間で接続を共有する中間層接続プールを補完します。また、DRCPを使用すると、同じ中間層ホスト上の中間層プロセス間、および異なる中間層ホスト上の中間層プロセス間でもデータベース接続を共有できます。この結果、大量のクライアント接続をサポートするために必要となる基本データベース・リソースが大幅に減少するため、データベース層のメモリー・フットプリントが縮小し、中間層とデータベース層の両方のスケーラビリティが向上します。すぐに使用できるサーバーのプールを保持することで、クライアント接続の作成と切断のコストが削減されるという利点もあります。

DRCPは、中間層接続プーリングを実行できない(PHP/Apacheなどの)マルチプロセスのシングル・スレッド・アプリケーション・サーバーを含むアーキテクチャに特に適しています。データベースは、DRCPを使用すると同時接続の数を数万まで増やすことができます。

注意:
Windowsプラットフォームでは、SQLNET.AUTHENTICATION_SERVICESパラメータ値のnts設定がDRCPでサポートされていません。

関連項目:

- DRCPの詳細は、『Oracle Database概要』を参照してください。

- DRCPセッションを取得する場合に使用できるオプションの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

データベース常駐接続プーリングを使用する場合

データベース常駐接続プーリングは、複数のクライアントがデータベースにアクセスする場合で、次のいずれかに該当する場合に有効です。

- 大量のクライアント接続を最小限のメモリー使用でサポートする必要がある場合。

- 複数の類似クライアント・アプリケーションがあり、セッションの共有または再利用が可能な場合。
類似アプリケーションとは、同じデータベース資格証明で接続し、同じスキーマを使用するアプリケーションです。

- クライアント・アプリケーションでデータベース接続を取得し、比較的短時間の処理を実行した後、データベース接続を解放する場合。

- クライアント要求にまたがるセッション・アフィニティが必要ない場合。

- クライアント側に複数のプロセスおよび複数のホストが存在する場合。

データベース常駐接続プーリングの利点

データベース常駐接続プーリングの使用には次の利点があります。

- 複数の中間層クライアント・アプリケーション間でリソースを共有できます。

- リソース使用量が減少するため、データベースおよびアプリケーションのスケーラビリティが向上します。

データベース常駐接続プーリングおよびLOGON/LOGOFFトリガー

LOGONトリガーは、DRCPで認証が実施されるたびに、または新規セッションが作成されるたびに起動します。

LOGOFFトリガーは、DRCPでログオフされるたび、またセッションが破棄されると起動します。このため、LOGOFFトリガーは、アイドル時間制限のために、セッションが終了すると起動します。

関連項目:

- 『Oracle Database PL/SQL言語リファレンス』

- 『Oracle Databaseセキュリティ・ガイド』

DRCP、専用サーバーおよび共有サーバーの比較

表5-1に、専用サーバー、共有サーバーおよびデータベース常駐接続プーリングの相違点を示します。

表5-1 専用サーバー、共有サーバーおよびデータベース常駐接続プーリング

専用サーバー

共有サーバー

データベース常駐接続プーリング

クライアント要求を受け取ると、クライアント用に新規サーバー・プロセスとセッションが作成されます。

クライアントから最初の要求を受け取ると、ディスパッチャ・プロセスによって要求が共通キューに入れられます。要求は使用可能な共有サーバー・プロセスによって取り出されます。その後のクライアントと共有サーバー・プロセス間の通信はディスパッチャ・プロセスによって管理されます。

クライアントから最初の要求を受け取ると、接続ブローカによって使用可能なプール・サーバーが選択され、そのプール・サーバーにクライアント接続が渡されます。

使用可能なプール・サーバーがない場合は、接続ブローカによって作成されます。プールが最大サイズに達した場合、クライアント要求は、プール・サーバーが使用可能になるまで待機キューに入れられます。

データベース・リソースを解放すると、セッションおよびサーバー・プロセスが終了します。

データベース・リソースを解放すると、セッションが終了します。

データベース・リソースを解放すると、プール・サーバーがプールに解放されます。

メモリー要件は、サーバー・プロセスとセッションの数に比例します。クライアントごとに1つのサーバーと1つのセッションが存在します。

メモリー要件は、共有サーバーとセッションの合計に比例します。クライアントごとに1つのセッションが存在します。

メモリー要件は、プール・サーバーとそのセッションの数に比例します。プール・サーバーごとに1つのセッションが存在します。

セッション・メモリーはPGAから割り当てられます。

セッション・メモリーはSGAから割り当てられます。

セッション・メモリーはPGAから割り当てられます。

専用サーバー、共有サーバーおよびデータベース常駐接続プーリングのメモリー使用量の例

各セッションに必要なメモリーが400KB、各サーバー・プロセスに必要なメモリーが4MBであるアプリケーションについて考えます。プール・サイズは100で、使用される共有サーバーの数は100です。

5000のクライアント接続がある場合、各構成で使用されるメモリーは次のようになります。

- 専用サーバー
使用メモリー = 5000 X (400KB + 4MB) = 22GB

- 共有サーバー
使用メモリー = 5000 X 400KB + 100 X 4MB = 2.5GB

2.5GBのうち2GBはSGAから割り当てられます。

- データベース常駐接続プーリング
使用メモリー = 100 X (400KB + 4MB) + (5000 X 35KB)= 615MB

ブローカへの各接続のコストは、約35KBです。

データベース常駐接続プーリングの使用に関する制限事項

プール・サーバーを使用して接続されている場合、次の処理を実行することはできません。

- データベースの停止

- データベース常駐接続プールの停止

- 接続済ユーザーのパスワードの変更

- データベース常駐接続プールへの共有データベース・リンクを使用した接続

- 暗号化、証明書など、アドバンスト・セキュリティ・オプション(ASO)のオプションの使用

- OCI_MIGRATEオプションを使用した直接的な、またはOCIConnectionPoolを介した間接的なサーバー側での移行可能セッションの使用

プール内のDDL前のセッションはまだDDL後のクライアントに渡される可能性があるため、プール内のデータベース・ユーザーに関係するDDL文の実行には注意が必要です。たとえば、ユーザーを削除する場合、そのユーザーのセッションがプール内に存在せず、そのユーザーとして認証されたブローカへの接続がないことを確認します。

明示的なロールが使用可能であり、プールに解放されるセッションは、後でデフォルトのログイン・ロールを必要とする(同じユーザーの)接続に渡される可能性があります。明示的なロールのあるセッションは解放せずに、かわりにセッションを終了してください。

Oracle Databaseの共有サーバー構成

この項では、共有サーバーを使用可能にする方法、および共有サーバーの初期化パラメータを設定または変更する方法を説明します。内容は次のとおりです。

- 共有サーバー用初期化パラメータ

- 共有サーバーのメモリー管理

- 共有サーバーの使用可能化

- ディスパッチャの構成

- 共有サーバーの使用禁止

- 共有サーバーのデータ・ディクショナリ・ビュー

関連項目:

- 「専用サーバー・プロセスと共有サーバー・プロセスの概要」

- ALTER SYSTEM文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

共有サーバー用初期化パラメータ

共有サーバー操作を制御する初期化パラメータは、次のとおりです。

- SHARED_SERVERS: 起動する初期共有サーバー数および最低限保持する共有サーバー数を指定します。共有サーバーを使用するための必須パラメータはこのパラメータのみです。

- MAX_SHARED_SERVERS: 同時に実行可能な共有サーバーの最大数を指定します。

- SHARED_SERVER_SESSIONS: 同時に実行可能な共有サーバー・ユーザー・セッションの合計数を指定します。このパラメータを設定すると、専用サーバーのユーザー・セッションを確保することが可能になります。

- DISPATCHERS: 共有サーバー・アーキテクチャのディスパッチャ・プロセスを構成します。

- MAX_DISPATCHERS: 同時に実行できるディスパッチャ・プロセスの最大数を指定します。このパラメータは、現在は無視できます。将来のリリースで、同時接続数によってディスパッチャ数が自動的にチューニングされるようになるまで使用しません。

- CIRCUITS: 受信および発信用のネットワーク・セッションに使用可能なバーチャル・サーキットの合計数を指定します。

関連項目:
これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

共有サーバーのメモリー管理

共有サーバーが動作するには、共有プールまたはラージ・プールにユーザー・グローバル領域(UGA)が必要です。同時セッション数が少ないインストールでは、通常、これらのシステム・グローバル領域(SGA)コンポーネントのデフォルト・サイズで十分です。ただし、セッション数が多い場合は、共有サーバーに対応できるようにメモリーをチューニングする必要があります。

ガイドラインは、『Oracle Databaseパフォーマンス・チューニング・ガイド』のメモリーの構成と使用に関する項を参照してください。

共有サーバーの使用可能化

共有サーバーを使用可能にするには、SHARED_SERVERS初期化パラメータに0(ゼロ)より大きい値を設定します。他の共有サーバー初期化パラメータの設定は不要です。共有サーバーが動作するには最低1つのディスパッチャが必要であるため、構成されていない場合でも、ディスパッチャは起動されます。ディスパッチャについては、「ディスパッチャの構成」を参照してください。

共有サーバーを動的に起動するには、ALTER SYSTEM文を使用してSHARED_SERVERSパラメータに0(ゼロ)以外の値を設定するか、またはデータベースの起動時にSHARED_SERVERSを初期化パラメータ・ファイルに組み込みます。SHARED_SERVERSが初期化パラメータ・ファイルに組み込まれていない場合、または値が0(ゼロ)に設定されている場合、共有サーバーはデータベースの起動時に使用可能になりません。

注意:
SHARED_SERVERSがデータベースの起動時に初期化パラメータ・ファイルに組み込まれていない場合でも、DISPATCHERSが組み込まれ、少なくとも1つのディスパッチャが指定されていると、共有サーバーは使用可能になります。この場合、SHARED_SERVERSのデフォルトは1です。
SHARED_SERVERSとDISPATCHERSのいずれも初期化ファイルに組み込まれていない場合は、インスタンスが起動された後にDISPATCHERSパラメータを単に変更しても共有サーバーを起動することはできません。共有サーバーを起動するには、SHARED_SERVERSを0(ゼロ)以外の値に変更する必要があります。

注意:
Database Configuration Assistant(DBCA)でOracle Databaseを作成した場合、DBCAによってOracle XML DB(XDB)のディスパッチャが構成されます。これは、HTTPやFTPなどのXDBプロトコルには共有サーバーが必要になるためです。これにより、SHARED_SERVERの値は1になります。共有サーバーは使用可能ですが、この構成では、XDBサービスに接続して共有サーバーを使用できるのは1つのセッションのみです。共有サーバーを標準的なデータベース・セッション(SQL文を発行)に対応できるようにするには、ディスパッチャ構成を追加するか、既存の構成をXDB固有ではない構成に置き換える必要があります。手順については、「ディスパッチャの構成」を参照してください。

SHARED_SERVERSの値の決定

SHARED_SERVERS初期化パラメータは、インスタンスの起動時に作成する共有サーバーの最小数を指定します。インスタンスの起動後は、既存の共有サーバーがビジーになる頻度と要求キューの長さに基づいて、Oracle Databaseが共有サーバーの数を動的に調整します。

標準的なシステムでは、共有サーバーの数は、10接続ごとに共有サーバー1つという割合で安定します。OLTPアプリケーションでは、要求率が低い場合、または要求に対してサーバー使用の比率が低い場合は、接続数/サーバー数の割合が高くなります。対照的に、要求率が高いか、要求に対してサーバー使用の比率が大きいアプリケーションの場合は、接続数/サーバー数の割合が低くなります。

PMON(プロセス・モニター)バックグラウンド・プロセスは、SHARED_SERVERSで指定された値を下回る状態まで共有サーバーを終了させることはできません。したがって、このパラメータを使用すると、偶発的な負荷の変動のためにPMONが共有サーバーを終了および再起動することがなくなるため、負荷が安定し、システムへの過負荷を最小にできます。

システムの平均的な負荷がわかっている場合は、SHARED_SERVERSを最適な値に設定できます。次に、このパラメータの使用方法の例を示します。

1000人の従業員が勤務するテレマーケティング・センターでデータベースが使用されているとします。従業員は、平均して勤務時間の90%を顧客との電話応対に費やし、レコードの検索と更新には10%のみ費やしています。従業員が顧客と電話をしている間に共有サーバーが終了し、データベースにアクセスしたときに再び起動することがないように、DBAは最適な共有サーバー数として100を指定しています。

ただし、すべての勤務時間帯で同じ数の従業員が勤務しているわけではありません。夜間の時間帯は200人の従業員で十分です。SHARED_SERVERSは動的なパラメータであるため、DBAは、夜間の共有サーバーの数を20に減らし、バッチ・ジョブなどの他のタスクにリソースが解放されるようにします。

共有サーバー・プロセス数の削減

最低限アクティブに保つ必要がある共有サーバーの数を削減するには、SHARED_SERVERSパラメータを小さい値に動的に設定します。設定後は、共有サーバー数がSHARED_SERVERSパラメータの値に減少するまで、非アクティブになる共有サーバーにはPMONによって終了のマークが付けられます。

次の文は、共有サーバーの数を減らす例です。

ALTER SYSTEM SET SHARED_SERVERS = 5;

SHARED_SERVERSを0(ゼロ)に設定すると、共有サーバーは使用禁止になります。詳細は、「共有サーバーの使用禁止」を参照してください。

共有サーバー・プロセス数の制限

MAX_SHARED_SERVERSパラメータは、PMONによって自動的に作成される共有サーバーの最大数を指定します。デフォルト値はありません。値が指定されていない場合、PMONは次の制限内で、負荷によって必要とされる共有サーバーを可能なかぎり起動します。

- プロセスの制限(PROCESSES初期化パラメータによって設定)

- 最小空きプロセス・スロット数(少なくとも総プロセス・スロット数の1/8、またはPROCESSESが24未満に設定されている場合は2スロット)

- システム・リソース

注意:
Windows NTの場合、各サーバーは共通プロセス内のスレッドであるため、MAX_SHARED_SERVERSを大きい値に設定する場合は注意が必要です。

SHARED_SERVERSの値が、MAX_SHARED_SERVERSの値より優先されます。したがって、SHARED_SERVERSをMAX_SHARED_SERVERSより大きい値に設定すると、MAX_SHARED_SERVERSの値を超える数の共有サーバーをPMONに起動させることができます。その後は、MAX_SHARED_SERVERSの値をSHARED_SERVERSより大きい値に動的に変更することで、共有サーバー数に新しい上限を設定できます。

共有サーバー数を制限する主な理由は、メモリーやCPUタイムなどのリソースを他のプロセス用に確保しておくためです。たとえば、前述のテレマーケティング・センターの例について考えてみます。

DBAは、夜間のバッチ・ジョブ用にリソースの2/3を確保しようとします。DBAは、MAX_SHARED_SERVERSの値を最大プロセス数(PROCESSES)の1/3より小さい値に設定します。この設定によって、DBAは、すべての従業員がデータベースに同時にアクセスした場合でも、バッチ・ジョブは専用サーバーに接続でき、従業員の要求処理後に共有サーバーが停止するまで待機する必要がないことを確認します。

共有サーバー数を制限するもう1つの理由は、多数のサーバー・プロセスが同時に実行されることによって、大量のスワッピングが発生してシステムの処理速度が低下しないようにするためです。ただし、この場合はMAX_SHARED_SERVERSよりPROCESSESが上限として機能します。

この他にも、共有サーバー数を制限する理由として、テスト、デバッグ、パフォーマンス分析およびチューニングがあります。たとえば、特定のユーザー・コミュニティを効率的にサポートするために必要な共有サーバーの数を調べるために、MAX_SHARED_SERVERSの値を非常に小さい数に設定しておき、ユーザーが応答時間の遅延を認識しない数まで増やすことができます。

共有サーバー・セッション数の制限

SHARED_SERVER_SESSIONS初期化パラメータは、同時共有サーバー・ユーザー・セッションの最大数を指定します。動的パラメータであるこのパラメータを設定すると、データベース・セッションを専用サーバー用に確保できます。この結果、データベースのバックアップやリカバリなど、専用サーバーを必要とする管理タスクが共有サーバー・セッションによって専有されることはありません。

このパラメータにデフォルト値はありません。値が指定されていない場合は、SESSIONS初期化パラメータの制限範囲内で共有サーバー・セッションが必要に応じて作成されます。

共有メモリーの保護

CIRCUITSパラメータによって、共有メモリーに作成可能なバーチャル・サーキットの許容最大数が設定されます。このパラメータにデフォルトはありません。値が指定されていない場合は、DISPATCHERS初期化パラメータおよびシステム・リソースの制限範囲内でサーキットが必要に応じて作成されます。

ディスパッチャの構成

DISPATCHERS初期化パラメータは、共有サーバー・アーキテクチャ内のディスパッチャ・プロセスを構成します。共有サーバーが動作するためには、最低1つのディスパッチャ・プロセスが必要です。ディスパッチャを指定せずに、SHARED_SERVERを0(ゼロ)以外の値に設定して共有サーバーを使用可能にすると、デフォルトで、Oracle Databaseによって1つのディスパッチャがTCPプロトコル用に作成されます。この構成に相当する初期化パラメータDISPATCHERSの明示的設定は次のとおりです。

dispatchers="(PROTOCOL=tcp)"

次のいずれかの条件に適合する場合は、DISPATCHERS初期化パラメータを使用して、追加のディスパッチャを構成できます。

- TCP/IP以外のプロトコルを構成する必要がある場合。DISPATCHERSパラメータの次のいずれかの属性でプロトコル・アドレスを構成します。

- ADDRESS

- DESCRIPTION

- PROTOCOL

- 次のオプションのディスパッチャ属性を1つ以上構成する場合。

- DISPATCHERS

- CONNECTIONS

- SESSIONS

- TICKS

- LISTENER

- MULTIPLEX

- POOL

- SERVICE

注意:
このパラメータの構成には、Database Configuration Assistantが役立ちます。

DISPATCHERS初期化パラメータの属性

この項では、DISPATCHERS初期化パラメータで指定可能な属性について簡単に説明します。

プロトコル・アドレスは必須です。プロトコル・アドレスは次の属性を1つ以上使用して指定します。

属性

説明

ADDRESS

ディスパッチャがリスニングするエンドポイントのネットワーク・プロトコル・アドレスを指定します。

DESCRIPTION

ネットワーク・プロトコル・アドレスなど、ディスパッチャがリスニングするエンドポイントのネットワークの説明を指定します。構文は、次のとおりです。

(DESCRIPTION=(ADDRESS=...))

PROTOCOL

ディスパッチャによってリスニング・エンドポイントが生成されるネットワーク・プロトコルを指定します。次に例を示します。

(PROTOCOL=tcp)

プロトコル・アドレスの構文の詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

次の属性は、この構成が使用するディスパッチャ数を指定します。これはオプションで、デフォルトは1です。

属性

説明

DISPATCHERS

起動する初期ディスパッチャの数を指定します。

次の属性は、構成の各ディスパッチャのネットワーク属性に関する情報をインスタンスに通知します。これらの属性はすべてオプションです。

属性

説明

CONNECTIONS

各ディスパッチャに対して許容されるネットワーク接続の最大数を指定します。

SESSIONS

各ディスパッチャに対して許容されるネットワーク・セッションの最大数を指定します。

TICKS

TICKの継続時間(秒数)を指定します。TICKは、接続プールのタイムアウトを指定できる時間単位です。接続プーリングに使用されます。

LISTENER

PMONプロセスがディスパッチャ情報を登録するリスナーの別名を指定します。ネーミング・メソッドによって解決される別名を設定してください。

MULTIPLEX

Oracle Connection Managerのセッションの多重化機能を使用可能にする場合に使用します。

POOL

接続プーリングを使用可能にする場合に使用します。

SERVICE

ディスパッチャがリスナーに登録するサービス名を指定します。

完全な属性名または先頭の3文字以上で構成されたサブストリングを指定できます。たとえば、SESSIONS=3、SES=3、SESS=3またはSESSI=3のように指定できます。

関連項目:
DISPATCHERS初期化パラメータの属性の詳細は、『Oracle Databaseリファレンス』を参照してください。

ディスパッチャ数の決定

オペレーティング・システムに対して各プロセスごとに可能な接続数を把握した後、インスタンス起動時に各ネットワーク・プロトコルに対して作成する初期ディスパッチャの数を、次の式を使用して計算します。

Number of dispatchers =
CEIL ( max. concurrent sessions / connections for each dispatcher )

CEILは、最も近い整数に切り上げた結果を返します。

たとえば、各プロセスごとに970の接続数をサポートできるシステムがある場合に、次の最大セッション数を仮定します。

- TCP/IPを介して最大4,000のセッションが同時に接続します。

- SSL付きTCP/IPを介して最大2,500のセッションが同時に接続します。

この場合は、次のように、TCP/IP用のDISPATCHERS属性には最低で5ディスパッチャ(4000÷970)を、SSL付きTCP/IP用には最低で3ディスパッチャ(2500÷970)を設定する必要があります。

DISPATCHERS='(PROT=tcp)(DISP=5)', '(PROT=tcps)(DISP=3)'

パフォーマンスによっては、ディスパッチャ数の調整が必要となる場合があります。

初期ディスパッチャ数の設定

複数のディスパッチャ構成を指定するには、DISPATCHERSに文字列のカンマ区切りのリストを設定するか、初期化ファイルに複数のDISPATCHERSパラメータを指定します。DISPATCHERSを複数回指定する場合、各行は初期化パラメータ・ファイル内で互いに隣接している必要があります。内部では、Oracle Databaseによって、INDEX値(0(ゼロ)から開始)が各DISPATCHERSパラメータに割り当てられます。このDISPATCHERSパラメータは、後で、ALTER SYSTEM文の中で索引番号を使用して参照できます。

次に、DISPATCHERS初期化パラメータの設定例をいくつか示します。

例: 標準: これは、DISPATCHERS初期化パラメータの標準的な設定例です。

DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=2)"

例: ディスパッチャに使用されるIPアドレスの強制 次の仮定的な例では、指定されたIPアドレスでリスニングする2つのディスパッチャが作成されます。アドレスは、インスタンスが存在するホストの有効なIPアドレスである必要があります。(ホストに複数のIPアドレスを構成できます。)

DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(HOST=144.25.16.201))(DISPATCHERS=2)"

例: ディスパッチャが使用するポートの設定: ディスパッチャで特定のポートをリスニング・エンドポイントとして使用するには、次のようにPORT属性を追加します。

DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(PORT=5000))"
DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(PORT=5001))"

ディスパッチャ数の変更

インスタンス内のディスパッチャ・プロセスの数を制御できます。共有サーバー数と異なり、ディスパッチャ数は自動的に変更されません。ディスパッチャの数は、明示的にALTER SYSTEM文で変更します。このリリースのOracle Databaseでは、ディスパッチャ数をMAX_DISPATCHERSパラメータで指定された制限よりも大きい数に増加できます。MAX_DISPATCHERSは将来のリリースで考慮される予定です。

次のビューを監視し、ディスパッチャ・プロセスの負荷を判別します。

- V$QUEUE

- V$DISPATCHER

- V$DISPATCHER_RATE

関連項目:
これらのビューを監視してディスパッチャの負荷とパフォーマンスを判別する方法については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

これらのビューによって、ディスパッチャ・プロセスに対する負荷が一貫して高いことが判明した場合は、追加のディスパッチャ・プロセスを起動してユーザー要求をルーティングすることで、パフォーマンスを改善できます。逆に、ディスパッチャの負荷が一貫して低い場合は、ディスパッチャの数を少なくすることにより、パフォーマンスを改善できます。

インスタンスの実行中にディスパッチャの数を動的に変更するには、ALTER SYSTEM文を使用して、既存のディスパッチャ構成に対するDISPATCHERS属性の設定を変更します。新規のディスパッチャ構成を追加して、異なるネットワーク属性でディスパッチャを起動することもできます。

特定のディスパッチャ構成に対するディスパッチャ数を少なくしても、ディスパッチャが即時に削除されるわけではありません。Oracle Databaseは、ユーザーの切断にあわせてDISPATCHERSで指定した制限数に達するまでディスパッチャを停止します。

たとえば、初期化パラメータ・ファイルの次のDISPATCHERS設定でインスタンスが起動されたとします。

DISPATCHERS='(PROT=tcp)(DISP=2)', '(PROT=tcps)(DISP=2)'

TCP/IPプロトコル用のディスパッチャ数を2から3に増やし、SSL付きTCP/IPプロトコル用のディスパッチャ数を2から1に減らすには、次の文を発行します。

ALTER SYSTEM SET DISPATCHERS = '(INDEX=0)(DISP=3)', '(INDEX=1)(DISP=1)';

または

ALTER SYSTEM SET DISPATCHERS = '(PROT=tcp)(DISP=3)', '(PROT=tcps)(DISP=1)';

注意:
(DISP=1)を指定する必要はありません。1はDISPATCHERSパラメータのデフォルト値のため、これはオプションです。

現在起動しているTCP/IP用のディスパッチャ・プロセスが2以下の場合は、新しいプロセスが作成されます。SSL付きTCP/IP用のディスパッチャ・プロセスが現在複数起動している場合は、接続ユーザーの切断にあわせて余分なプロセスが停止されます。

TCP/IPプロトコル用のディスパッチャ数は変更しないで、接続プーリングをサポートする別のTCP/IPディスパッチャを追加すると仮定します。この場合は次の文を入力します。

ALTER SYSTEM SET DISPATCHERS = '(INDEX=2)(PROT=tcp)(POOL=on)';

INDEX属性は、新規ディスパッチャ構成を追加するために必要です。前述の文で(INDEX=2)を省略すると、INDEX 0のTCP/IPディスパッチャ構成が接続プーリングをサポートするように変更され、その構成に対するディスパッチャ数が、ディスパッチャ数(属性DISPATCHERS)が指定されていない場合のデフォルトである1に減らされます。

ディスパッチャ数変更時の注意

- INDEXキーワードを使用すると、変更するディスパッチャ構成を識別できます。このINDEXを指定しないと、指定したDESCRIPTION、ADDRESSまたはPROTOCOLと一致する最初のディスパッチャ構成が変更されます。既存のディスパッチャ構成の中で一致するものが見つからなかった場合は、新しいディスパッチャが追加されます。

- INDEX値の範囲は0からn-1で、nは現行のディスパッチャ構成の数です。ALTER SYSTEM文でINDEX値にnを指定すると(nは現行のディスパッチャ構成の数)、新しいディスパッチャ構成が追加されます。

- 現行のディスパッチャ構成の値、つまり、ディスパッチャの数や接続プーリングを使用できるかなどを確認するには、V$DISPATCHER_CONFIG動的パフォーマンス・ビューを問い合せます。ディスパッチャが関連付けられているディスパッチャ構成を確認するには、V$DISPATCHERビューのCONF_INDX列を問い合せます。

- ディスパッチャ構成のDESCRIPTION、ADDRESS、PROTOCOL、CONNECTIONS、TICKS、MULTIPLEXおよびPOOL属性を変更しても、その変更は既存のディスパッチャには反映されず、新しいディスパッチャにのみ反映されます。したがって、構成に関連付けられているすべてのディスパッチャに対して変更を反映するには、DISPATCHERSパラメータを変更した後で、既存のディスパッチャを強制的に停止し、新しく指定したプロパティに配置された新しいディスパッチャをデータベースで起動する必要があります。
LISTENER属性とSERVICES属性は、同じ制約の対象となりません。これらの属性は、変更した構成に関連付けられている既存のディスパッチャに適用されます。SESSIONS属性は、その値が減らされた場合のみ、既存のディスパッチャに適用されます。反対に値が増加された場合は、新しく起動されるディスパッチャにのみ適用されます。

特定のディスパッチャ・プロセスの停止

ALTER SYSTEM文では、ディスパッチャを停止してディスパッチャの数を少なくする判断は、データベースが行います。別の方法として、特定のディスパッチャ・プロセスを停止できます。停止するディスパッチャ・プロセスの名前を識別するには、V$DISPATCHER動的パフォーマンス・ビューを使用します。

SELECT NAME, NETWORK FROM V$DISPATCHER;

各ディスパッチャは、Dnnn形式の名前で一意に識別されます。

ディスパッチャD002を停止するには、次の文を発行します。

ALTER SYSTEM SHUTDOWN IMMEDIATE 'D002';

IMMEDIATEキーワードを指定すると、ディスパッチャによる新規接続の受入れが停止し、データベースはそのディスパッチャを介した既存のすべての接続を即時に終了します。すべてのセッションがクリーン・アップされてから、ディスパッチャ・プロセスが停止します。IMMEDIATEを指定しなかった場合、ディスパッチャは、接続ユーザーがすべて切断され、接続がすべて終了するまで待ってから停止します。

共有サーバーの使用禁止

共有サーバーを無効にするには、SHARED_SERVERSを0に設定します。この操作は、ALTER SYSTEM文を使用して動的に行うことができます。共有サーバーを無効にすると、新しいクライアントは共有モードで接続できなくなります。ただし、Oracle Databaseではすべての共有サーバーの接続がクローズされるまで一部の共有サーバーが保持されます。保持される共有サーバーの数は、SHARED_SERVERSの変更前の設定で指定されていた数、またはMAX_SHARED_SERVERSパラメータの値のいずれか小さい値です。SHARED_SERVERSとMAX_SHARED_SERVERSの両方が0(ゼロ)に設定されている場合は、すべての共有サーバーが停止し、残りの共有サーバー・クライアントからの要求は、SHARED_SERVERSまたはMAX_SHARED_SERVERSの値が再度引き上げられるまでキューで待機します。

ディスパッチャを一度停止して、すべての共有サーバー・クライアントを切断するには、次の文を入力します。

ALTER SYSTEM SET DISPATCHERS = '';

共有サーバーのデータ・ディクショナリ・ビュー

次のビューは、共有サーバー構成情報の取得やパフォーマンスの監視に使用できます。

ビュー

説明

V$DISPATCHER

名前、ネットワーク・アドレス、状態、各種使用統計、索引番号などのディスパッチャ・プロセス情報を提供します。

V$DISPATCHER_CONFIG

ディスパッチャに関する構成情報を提供します。

V$DISPATCHER_RATE

ディスパッチャ・プロセスのレート統計が含まれています。

V$QUEUE

共有サーバー・メッセージ・キューについての情報が含まれています。

V$SHARED_SERVER

共有サーバーについての情報が含まれています。

V$CIRCUIT

バーチャル・サーキットについての情報が含まれています。バーチャル・サーキットとは、ディスパッチャおよびサーバーを介したデータベースへのユーザー接続です。

V$SHARED_SERVER_MONITOR

共有サーバーのチューニング情報が含まれています。

V$SGA

各種のシステム・グローバル領域(SGA)グループに関するサイズ情報が含まれています。この情報は、共有サーバーのチューニング時に役立ちます。

V$SGASTAT

チューニングに役立つSGA関連の詳細な統計情報が含まれています。

V$SHARED_POOL_RESERVED

共有プール内で予約済のプールと領域をチューニングする際に役立つ統計リストが含まれています。

関連項目:

- これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- 共有サーバーの監視とチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

データベース常駐接続プーリングの構成

データベース・サーバーは、データベース常駐接続プーリングを使用できるように事前に構成されています。ただし、この機能は、接続プールを起動して明示的に使用可能にする必要があります。

この項の内容は次のとおりです。

- データベース常駐接続プーリングを使用可能にする方法

- データベース常駐接続プーリングの接続プールの構成

- データベース常駐接続プーリングのデータ・ディクショナリ・ビュー

関連項目:
「データベース常駐接続プーリングの理解」

データベース常駐接続プーリングを使用可能にする方法

Oracle Databaseには、SYS_DEFAULT_CONNECTION_POOLと呼ばれるデフォルトの接続プールがあります。デフォルトでは、このプールは作成されますが起動はされません。データベース常駐接続プーリングを使用可能にするには、接続プールを明示的に起動する必要があります。

データベース常駐接続プーリングを使用可能にする手順は、次のとおりです。

1. 「データベース常駐接続プールの起動」の説明に従って、データベース常駐接続プールを起動します。

2. 「接続プールへのクライアント接続要求のルーティング」の説明に従って、クライアント接続要求を接続プールにルーティングします。

データベース常駐接続プールの起動

接続プールを起動する手順は、次のとおりです。

1. SQL*Plusを起動して、SYSユーザーとしてデータベースに接続します。

2. 次のコマンドを発行します。

SQL> EXECUTE DBMS_CONNECTION_POOL.START_POOL();

起動されると、接続プールは明示的に停止されるまでこの状態のままです。接続プールは、データベース・インスタンスが再起動されると、インスタンスの停止時点でアクティブだった場合は自動的に再起動されます。

Oracle Real Application Clusters(Oracle RAC)環境では、インスタンスを使用して接続プールを管理できます。プール構成に対する変更は、すべてのOracle RACインスタンスで適用されます。

接続プールへのクライアント接続要求のルーティング

クライアント・アプリケーションでは、接続文字列で接続タイプをPOOLEDに指定する必要があります。

次の例は、クライアントをデータベース常駐接続プールに接続する簡単な接続文字列を示しています。

examplehost.company.com:1521/books.company.com:POOLED

次の例は、クライアントをデータベース常駐接続プールに接続するTNS接続記述子を示しています。

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=myhost)
(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=sales)
(SERVER=POOLED)))

データベース常駐接続プーリングを使用禁止にする方法

データベース常駐接続プーリングを使用禁止にするには、接続プールを明示的に停止する必要があります。次の手順を実行します。

1. SQL*Plusを起動して、SYSユーザーとしてデータベースに接続します。

2. 次のコマンドを発行します。

SQL> EXECUTE DBMS_CONNECTION_POOL.STOP_POOL();

関連項目:
DBMS_CONNECTION_POOLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

注意:
データベース常駐接続プールを使用禁止にする操作は、サーバーに渡されたすべてのクライアント要求が完了しないと完了できません。

データベース常駐接続プーリングの接続プールの構成

接続プールはデフォルトのパラメータ値を使用して構成されます。DBMS_CONNECTION_POOLパッケージ内のプロシージャを使用すると、使用方法に応じて接続プールを構成できます。Oracle Real Application Clusters(Oracle RAC)環境では、構成パラメータは各Oracle RACインスタンスに適用されます。

表5-2に、接続プール用に構成可能なパラメータを示します。

表5-2 データベース常駐接続プーリングの構成パラメータ

パラメータ名

説明

MINSIZE

プール内のプール・サーバーの最小数。デフォルト値は4です。

MAXSIZE

プール内のプール・サーバーの最大数。デフォルト値は40です。

接続プールでは、プールされたサーバーの5%が認証のために保持され、少なくとも1つのプールされたサーバーが認証のために常時保持されます。このパラメータを設定する場合は、認証と接続の両方に十分なプール・サーバーがあることを確認します。

INCRSIZE

クライアント・アプリケーション要求の受取り時にサーバーが使用可能でない場合にプールが増分されるプール・サーバーの数。デフォルト値は2です。

SESSION_CACHED_CURSORS

各プール・サーバー・セッションでキャッシュするセッション・カーソルの数。デフォルト値は50です。

INACTIVITY_TIMEOUT

プール・サーバーがプールでアイドル状態のままで待機する最大時間(秒数)。この時間を過ぎると、サーバーは終了される。デフォルト値は300です。

このパラメータはプールがMINSIZEの場合は適用されません。

MAX_THINK_TIME

クライアントがプールからプール・サーバーを取得した後で非アクティブ状態でいる最大時間(秒数)。クライアント・アプリケーションが、プールからプール・サーバーを取得した後、MAX_THINK_TIMEで指定した時間内にデータベース・コールを発行しない場合、プール・サーバーは解放されてクライアント接続が終了します。デフォルト値は120です。

MAX_USE_SESSION

プール・サーバーがプールから取得されプールに解放される回数。デフォルト値は500000です。

MAX_LIFETIME_SESSION

プール・サーバーがプールに存在している時間(秒数)。デフォルト値は86400です。

NUM_CBROK

クライアント要求を処理するために作成される接続ブローカの数。デフォルト値は1です。

複数の接続ブローカ・プロセスを作成すると、大量のクライアント・アプリケーションがある場合に、クライアント接続要求の負荷を分散できます。

MAXCONN_CBROK

各接続ブローカで処理できる最大接続数。

デフォルト値は40000です。ただし、データベースがインストールされているプラットフォームで許可される最大接続がデフォルト値より少ない場合は、MAXCONN_CBROKを使用して設定した値はその値で上書きされます。

MAXCONN_CBROKで指定した接続数がサポートされるように、オペレーティング・システムのプロセスごとのファイル記述子に関する制限は十分大きい値に設定してください。

CONFIGURE_POOLプロシージャの使用

DBMS_CONNECTION_POOLパッケージのCONFIGURE_POOLプロシージャを使用すると、拡張オプションを指定して接続プールを構成できます。このプロシージャは通常、接続プールのすべてのパラメータを変更する必要がある場合に使用します。

ALTER_PARAMプロシージャ

DBMS_CONNECTION_POOLパッケージのALTER_PARAMプロシージャを使用すると、特定の構成パラメータを他のパラメータに影響を与えることなく変更できます。たとえば、次のコマンドでは、使用されるプール・サーバーの最小数が変更されます。

SQL> EXECUTE DBMS_CONNECTION_POOL.ALTER_PARAM ('','MINSIZE','10');

次の例では、各接続ブローカで処理できる最大接続数が50000に変更されます。

SQL> EXECUTE DBMS_CONNECTION_POOL.ALTER_PARAM ('','MAXCONN_CBROK','50000');

このコマンドを実行する前に、データベースがインストールされているプラットフォームで許可される最大接続数がMAXCONN_CBROKに設定した値未満でないことを確認します。

たとえば、Linuxでは、/etc/security/limits.confファイルに次のエントリがあると、ユーザーtest_userに許可される最大接続数は30000となります。

test_user HARD NOFILE 30000

各接続ブローカで処理できる最大接続数を50000に設定するには、最初にlimits.confファイルの値を50000以上の値に変更します。

接続プールのデフォルト設定のリストア

接続プールのパラメータを変更した後でデフォルトのプール設定に戻す場合は、DBMS_CONNECTION_POOLパッケージのRESTORE_DEFAULTプロシージャを使用します。接続プールの設定をデフォルトに戻すコマンドは、次のとおりです。

SQL> EXECUTE DBMS_CONNECTION_POOL.RESTORE_DEFAULTS();

関連項目:
DBMS_CONNECTION_POOLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

データベース常駐接続プーリングのデータ・ディクショナリ・ビュー

表5-3に、データベース常駐接続プーリングに関する情報を提供するデータ・ディクショナリ・ビューを示します。これらのビューを使用すると、接続プールに関する情報を取得し、データベース常駐接続プーリングのパフォーマンスを監視できます。

表5-3 データベース常駐接続プーリングのデータ・ディクショナリ・ビュー

ビュー

説明

DBA_CPOOL_INFO

プール・ステータス、接続の最大数と最小数、アイドル・セッションのタイムアウトなど、接続プールに関する情報が含まれます。

V$CPOOL_CONN_INFO

接続ブローカへの各接続に関する情報が含まれます。

V$CPOOL_STATS

セッション要求の数、要求と一致するセッションがプールで検出された回数、セッション要求の合計待機時間など、プール統計が含まれます。

V$CPOOL_CC_STATS

プールの接続クラス・レベルの統計が含まれます。

関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

Oracle Databaseバックグラウンド・プロセスの概要

マルチプロセスのOracle Databaseシステムでは、最高のパフォーマンスを提供し、多くのユーザーが同時に使用できるように、バックグラウンド・プロセスが使用されています。バックグラウンド・プロセスでは、ユーザー・プロセスごとに実行される複数のデータベース・プログラムによって処理される機能が統合されます。バックグラウンド・プロセスは、非同期的にI/Oを実行して他のOracle Databaseプロセスを監視することによって、並列性を高め、パフォーマンスと信頼性を向上させます。

表5-4に基礎的なバックグラウンド・プロセスを示しますが、これらの多くはこのドキュメントの他の項で詳細に説明されています。追加のデータベース機能やオプションを使用している場合、これ以外のバックグラウンド・プロセスも実行される場合があります。次に例を示します。

- Oracle Streamsアドバンスト・キューイングを使用している場合は、キュー・モニター(QMNn)・バックグラウンド・プロセスが存在します。

- また、データファイルをストレージ・サブシステムの物理デバイスにマッピングするためにFILE_MAPPING初期化パラメータを指定している場合は、FMONプロセスが存在します。

- Oracle Automatic Storage Management(Oracle ASM)を使用している場合は、Oracle ASM固有の追加のバックグラウンド・プロセスが存在します。

表5-4 Oracle Databaseバックグラウンド・プロセス

プロセス名

説明

データベース・ライター(DBWn)

データベース・ライターは、変更があったブロックをデータベース・バッファ・キャッシュからデータファイルに書き込みます。Oracle Databaseでは、最大36のデータベース・ライター・プロセス(DBW0からDBW9およびDBWaからDBWj)を使用できます。DBWnプロセスの数は、DB_WRITER_PROCESSES初期化パラメータで指定します。データベースは、CPU数とプロセッサ・グループ数に基づいて、この初期化パラメータに適切なデフォルト設定を選択またはユーザー指定の設定を調整します。

DB_WRITER_PROCESSES初期化パラメータの設定の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

ログ・ライター(LGWR)

ログ・ライター・プロセスは、ディスクにREDOログ・エントリを書き込みます。REDOログ・エントリは、システム・グローバル領域(SGA)のREDOログ・バッファに生成される。LGWRは、REDOログ・ファイルにREDOログ・エントリを順番に書き込む。データベースに多重化されたREDOログがある場合、LGWRはREDOログ・ファイルのグループにREDOログ・エントリを書き込む。ログ・ライター・プロセスの詳細は、第12章「REDOログの管理」を参照してください。

チェックポイント(CKPT)

システム・グローバル領域内で変更があったすべてのデータベース・バッファは、特定の時点でDBWnによってデータファイルに書き込まれます。このイベントはチェックポイントと呼ばれます。チェックポイント・プロセスは、最新のチェックポイントを示すために、チェックポイントでDBWnにシグナルを出し、データベースのすべてのデータファイルと制御ファイルを更新する役割を持ちます。

システム・モニター(SMON)

システム・モニターは、障害の発生したインスタンスの再起動時にリカバリを実行します。Oracle Real Application Clustersデータベースでは、1つのインスタンスのSMONプロセスが、障害を起こした他のインスタンスのインスタンス・リカバリを実行できます。また、SMONにより、不要になった一時セグメントがクリーン・アップされ、ファイル読込みエラーやオフライン・エラーのためにシステム障害時やインスタンス・リカバリ時にスキップされた停止後のトランザクションがリカバリされます。これらのトランザクションは、表領域またはファイルがオンラインに戻るときに、SMONによって最後にリカバリされます。

プロセス・モニター(PMON)

プロセス・モニターは、ユーザー・プロセスが失敗したときにプロセス・リカバリを実行します。PMONは、キャッシュをクリーン・アップし、プロセスで使用されていたリソースを解放する役割を持ちます。また、PMONは、ディスパッチャ・プロセス(この表で後述)とサーバー・プロセスをチェックし、障害がある場合は再起動します。

アーカイバ(ARCn)

REDOログ・ファイルは、ログ・ファイルが一杯になるか、ログ・スイッチが発生すると、1つ以上のアーカイバ・プロセスによってアーカイブ記憶域にコピーされます。アーカイバ・プロセスについては、第13章「アーカイブREDOログの管理」を参照してください。

リカバラ(RECO)

リカバラ・プロセスは、ネットワーク障害やシステム障害が原因で分散データベース内で保留されている分散トランザクションを解決するために使用されます。ローカルRECOは一定周期でリモート・データベースへの接続を試み、保留中の分散トランザクションのローカル部分のコミットまたはロールバックを自動的に完了させる。このプロセスの詳細と開始方法は、第35章「分散トランザクションの管理」を参照してください。

ディスパッチャ(Dnnn)

ディスパッチャはオプションのバックグラウンド・プロセスで、共有サーバー構成の使用時にのみ存在します。共有サーバーの詳細は、前述の「Oracle Databaseの共有サーバー構成」を参照してください。

関連項目:
Oracle Databaseバックグラウンド・プロセスの完全なリストは、『Oracle Databaseリファレンス』を参照してください。

SQLのパラレル実行用プロセスの管理

注意:
この項に記載されているパラレル実行機能は、Oracle Database Enterprise Editionで利用できます。

この項では、SQL文のパラレル実行の管理方法について説明します。この構成では、Oracle Databaseによって、SQL文の処理作業を複数のパラレル・プロセスに分割できます。

多数のSQL文の実行をパラレル化できます。並列度は、単一の処理に対応付け可能なパラレル実行サーバーの数で表されます。並列度は、次の要素によって決まります。

- 文のPARALLEL句

- 問合せ内で参照されているオブジェクトの場合は、オブジェクトが作成または変更されたときに使用されたPARALLEL句

- 文に挿入されたパラレル・ヒント

- データベースによって決定されたデフォルト

SQLのパラレル実行の使用例は、「表作成のパラレル化」を参照してください。

この項の内容は、次のとおりです。

- パラレル実行サーバーの概要

- セッションのパラレル実行の変更

関連項目:

- パラレル・ヒントの使用方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

パラレル実行サーバーの概要

インスタンスが起動すると、Oracle Databaseによって、パラレル操作に使用可能なパラレル実行サーバーのプールが作成されます。パラレル実行コーディネータと呼ばれるプロセスがパラレル実行サーバーのプールの実行をディスパッチし、これらすべてのパラレル実行サーバーからユーザーへの結果の送信を調整します。

PARALLEL_MAX_SERVERS初期化パラメータのデフォルト値は0(ゼロ)より大きい値に設定されているため、パラレル実行サーバーはデフォルトで使用可能です。これらのプロセスは、並列化を利用できる様々なOracle Databaseの機能によって使用されます。関連する初期化パラメータは、データベースによって大半のユーザー用にチューニングされますが、必要に応じて環境にあわせて変更できます。簡単にチューニングできるように、一部のパラメータは動的に変更できます。

並列化は、トランザクション・リカバリ、レプリケーション、SQL実行など、様々な機能で使用できます。ここで説明しているSQLのパラレル実行の場合、1つの文の実行フェーズ全体を通して、複数のパラレル・サーバー・プロセスが対応付けられます。文の処理が完了すると、その文に対応付けられていたプロセスが他の文を処理できるようになります。

関連項目:
パラレル実行の使用に関する詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

セッションのパラレル実行の変更

セッションのSQLのパラレル実行は、ALTER SESSION文を使用して制御できます。

SQLのパラレル実行を使用禁止にする方法

SQLのパラレル実行は、ALTER SESSION DISABLE PARALLEL DML|DDL|QUERY文で使用禁止にできます。この文を発行した後は、後続のすべてのDML(INSERT、UPDATE、DELETE)、DDL(CREATE、ALTER)または問合せ(SELECT)操作がシリアルに実行されます。関係する表または索引にパラレル属性が指定されている場合でも、それとは無関係に文はシリアルに実行されます。ただし、PARALLELヒントが指定された文は、セッションの設定を無効にします。

次の文は、パラレルDDL操作を使用禁止にします。

ALTER SESSION DISABLE PARALLEL DDL;

SQLのパラレル実行を使用可能にする方法

SQLのパラレル実行は、ALTER SESSION ENABLE PARALLEL DML|DDL|QUERY文で使用可能にできます。その後、PARALLEL句またはパラレル・ヒントを文に対応付けると、そのDML文、DDL文または問合せ文はパラレルで実行されます。DDL文と問合せ文のパラレル実行はデフォルトで使用可能です。

DML文は、ALTER SESSION文を明示的に発行して、パラレルDMLを使用可能にした場合のみパラレル化できます。

ALTER SESSION ENABLE PARALLEL DML;

SQLのパラレル実行の強制

ALTER SESSION FORCE PARALLEL DML|DDL|QUERY文を発行すると、後続のすべてのDML、DDLまたは問合せ文をパラレルで実行するように強制できます。また、特定の並列度を強制的に適用して、後続の文に対応付けられたPARALLEL句を無効にできます。この文で並列度を指定しなかった場合は、デフォルトの並列度が使用されます。パラレル実行を強制すると、SQL文のパラレル・ヒントが無効になります。

次の文は、後続の文のパラレル実行を強制し、優先する並列度を5に設定します。

ALTER SESSION FORCE PARALLEL DDL PARALLEL 5;

外部プロシージャのプロセスの管理

この項の内容は次のとおりです。

- 外部プロシージャの概要

- 外部プロシージャ・コールを有効化するためのDBAのタスク

外部プロシージャの概要

外部プロシージャはC、C++、Javaその他の言語で記述されているプロシージャであり、データベースの外部でコンパイルおよび格納された後、別のプログラムからコールされます。たとえば、PL/SQLプログラム・ユニットから、特別な用途の処理に必要な1つ以上のCルーチンをコールできます。

これらのコール可能ルーチンは、Dynamic Link Library(DLL)またはJavaクラス・メソッドの場合はライブラリ・ユニットに格納されており、ベース言語で登録されています。Oracle Databaseには、コール仕様という特別な用途のインタフェースが用意されており、ユーザーはこのインタフェースを使用して他の言語から外部プロシージャをコールできます。

ユーザー・セッションによって外部プロシージャが呼び出されると、データベースによって外部プロシージャ・エージェントがデータベースのホスト・コンピュータ上で開始されます。エージェントのデフォルトの名前はextprocです。各セッションには専用エージェントがあります。セッションが終了すると、データベースではそのエージェントを終了します。

ユーザー・アプリケーションは、外部プロシージャ・エージェントに対してDLLまたはライブラリ・ユニットの名前、外部プロシージャの名前およびすべての関連するパラメータを渡します。次に、外部プロシージャ・エージェントはDLLまたはライブラリ・ユニットをロードして外部プロシージャを実行し、外部プロシージャから返された値をアプリケーションに返送します。

関連項目:
外部プロシージャの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

外部プロシージャ・コールを有効化するためのDBAのタスク

外部プロシージャ・コールを有効にするには、次のDBAタスクが必要となる場合があります。

- extprocエージェントを起動するためのリスナーの構成
デフォルトでは、extprocはデータベースによって起動されます。次の状況では、リスナーによってextprocが起動されるように、このデフォルト構成を変更する必要があります。

- マルチスレッドのextprocエージェントを使用する場合

- データベースがWindowsにおいて共有サーバー・モードで実行されている場合

- LIBRARY指定のAGENT句またはPROCEDUREまたはFUNCTION指定のAGENT IN句によって、外部プロシージャが異なるextprocエージェントにリダイレクトされる場合

デフォルト構成を変更する方法は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』の「複数のプログラミング言語を使用したアプリケーション開発」、環境の設定に関する項を参照してください。

- ライブラリの管理、またはライブラリの管理に関連のある権限の付与
DLLには、ライブラリと呼ばれるスキーマ・オブジェクトを経由してアクセスする必要があります。セキュリティを確保するために、デフォルトではDBAロールを持つユーザーのみがライブラリを作成および管理できます。このため、DBAは次のことを依頼される場合があります。

- CREATE LIBRARY文を使用して、開発者が必要とするライブラリ・オブジェクトを作成します。

- 開発者への次の権限の付与: CREATE LIBRARY、CREATE ANY LIBRARY、ALTER ANY LIBRARY、EXECUTE ANY LIBRARYおよびEXECUTE ON library_name。

これらの権限の明示的付与は、信頼できるユーザーに対してのみ行ってください。決してPUBLICロールに対して付与しないでください。ライブラリにPL/SQLインタフェースを作成する場合、EXECUTE権限のみをPL/SQLインタフェースに付与してください。基礎となるライブラリにEXECUTEを付与しないでください。PL/SQLインタフェースを作成するには、ライブラリに対するEXECUTEオブジェクト権限が必要です。ただし、ユーザーは自らのスキーマに対しては自動的にこの権限を持っています。ライブラリに対してEXECUTEオブジェクト権限を明示的に付与する必要はほとんどりません。

関連項目:
CREATE LIBRARY文の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

セッションの終了

時々、現行のユーザー・セッションを停止する必要があります。たとえば、管理操作を実行する場合に、すべての管理セッション以外のセッションを停止する必要があります。ここでは、セッションの停止の様々な要素について説明します。この項の内容は、次のとおりです。

- 停止するセッションの識別

- アクティブ・セッションの停止

- 非アクティブ・セッションの停止

セッションが停止すると、そのセッションのアクティブ・トランザクションがロールバックされ、そのセッションが保持していたリソース(ロックやメモリー領域など)がただちに解放されて、他のセッションで使用可能になります。

SQL文ALTER SYSTEM KILL SESSIONを使用して、現行のセッションを停止します。次の文は、システム識別子が7でシリアル番号が15のセッションを停止します。

ALTER SYSTEM KILL SESSION '7,15';

停止するセッションの識別

停止するセッションを識別するには、セッションの索引番号とシリアル番号を指定します。セッションのシステム識別子(SID)とシリアル番号を識別するには、V$SESSION動的パフォーマンス・ビューを問い合せます。たとえば、次の問合せはユーザーjwardのすべてのセッションを識別します。

SELECT SID, SERIAL#, STATUS
FROM V$SESSION
WHERE USERNAME = 'JWARD';

SID    SERIAL#    STATUS
-----  ---------  --------
7         15  ACTIVE
12         63  INACTIVE

Oracle Databaseに対してSQLコールを実行しているとき、セッションはACTIVEです。データベースに対してSQLコールを実行していないとき、セッションはINACTIVEです。

関連項目:
セッションの状態値については、『Oracle Databaseリファレンス』を参照してください。

アクティブ・セッションの停止

セッションの停止時にユーザー・セッションがトランザクションを処理している場合(STATUSがACTIVE)、トランザクションはロールバックされ、ユーザーはただちに次のメッセージを受け取ります。

ORA-00028: your session has been killed

ユーザーが、ORA-00028のメッセージを受け取った後、データベースに再接続する前に追加の文を実行すると、Oracle Databaseは次のメッセージを返します。

ORA-01012: not logged on

ネットワークI/Oやトランザクションのロールバックを実行している場合は、アクティブ・セッションを中断できません。そのセッションは、操作が完了するまで停止できません。この場合、セッションは、停止するまですべてのリソースを保持します。また、セッションを停止させるためにALTER SYSTEM文を発行したセッションは、対象のセッションが停止するまで最大60秒待機します。中断できなかった操作が1分経過しても終了しない場合、ALTER SYSTEM文の発行者は、セッションが停止されることを示すマークが設定されたというメッセージを受け取ります。停止マークが付けられたセッションは、V$SESSIONでの状態(STATUS)がKILLEDになり、サーバー(SERVER)がPSEUDO以外の値になります。

非アクティブ・セッションの停止

停止時にセッションがOracle Databaseに対してSQLコールを実行していない場合(STATUSがINACTIVE)、ORA-00028のメッセージはただちには返されません。このメッセージは、その後ユーザーが停止したセッションを使用しようとしたときに返されます。

非アクティブ・セッションを停止すると、V$SESSIONビューのセッションのSTATUSがKILLEDになります。停止したセッションの行は、ユーザーが再びそのセッションを使用しようとしてORA-00028のメッセージを受け取った後で、V$SESSIONから削除されます。

次の例では、非アクティブ・セッションを停止しています。最初にV$SESSIONを問い合せてセッションのSIDとSERIAL#を識別してから、セッションを停止しています。

SELECT SID,SERIAL#,STATUS,SERVER
FROM V$SESSION
WHERE USERNAME = 'JWARD';

SID    SERIAL#   STATUS     SERVER
-----  --------  ---------  ---------
7        15  INACTIVE   DEDICATED
12        63  INACTIVE   DEDICATED
2 rows selected.

ALTER SYSTEM KILL SESSION '7,15';
Statement processed.

SELECT SID, SERIAL#, STATUS, SERVER
FROM V$SESSION
WHERE USERNAME = 'JWARD';

SID    SERIAL#   STATUS     SERVER
-----  --------  ---------  ---------
7        15  KILLED     PSEUDO
12        63  INACTIVE   DEDICATED
2 rows selected.

プロセスおよびセッションのデータ・ディクショナリ・ビュー

次の表に、プロセスとセッションの管理に役立つデータ・ディクショナリ・ビューを示します。

ビュー

説明

V$PROCESS

現在アクティブになっているプロセスの情報が含まれています。

V$SESSION

現行のセッションごとにセッション情報がリストされます。

V$SESS_IO

各ユーザー・セッションのI/O統計情報が含まれています。

V$SESSION_LONGOPS

6秒(絶対時間)以上実行されていた各種操作の状態が表示されます。現在、状態が表示される操作は、多数のバックアップおよびリカバリ機能、統計収集および問合せの実行などです。Oracle Databaseのリリースごとにさらに操作が追加されます。

V$SESSION_WAIT

各セッションの現在または最後の待機が表示されます。

V$SESSION_WAIT_HISTORY

各アクティブ・セッションの最後の10個の待機イベントがリストされます。

V$WAIT_CHAINS

ブロックされたセッションに関する情報が表示されます。

V$SESSTAT

システム統計情報が含まれています。

V$RESOURCE_LIMIT

一部のシステム・リソースについて、現行および最大のグローバル・リソース使用率が表示されます。

V$SQLAREA

共有SQL領域に関する統計情報が含まれています。SQL文字列ごとに1行ずつ含まれます。メモリー内にあり、解析済で、実行準備のできているSQL文に関する統計情報も提供します。

6 メモリーの管理

この章の内容は、次のとおりです。

- メモリー管理について

- メモリー・アーキテクチャの概要

- 自動メモリー管理の使用

- メモリーの手動構成

- Database Smart Flash Cacheの構成

- メモリー管理の参考情報

メモリー管理について

メモリー管理には、データベースの変更に応じたOracle Databaseインスタンス・メモリー構造の最適なサイズのメンテナンスが含まれます。管理する必要があるメモリー構造は、システム・グローバル領域(SGA)とインスタンス・プログラム・グローバル領域(インスタンスPGA)です。

Oracle Databaseでは様々なメモリー管理方法がサポートされており、これらは初期化パラメータの設定で選択されます。自動メモリー管理と呼ばれる方法をお薦めします。

自動メモリー管理

リリース11gから、Oracle DatabaseはSGAメモリーとインスタンスPGAメモリーを完全に自動的に管理できるようになりました。インスタンスで使用される合計メモリー・サイズを指定するだけで、Oracle Databaseが必要に応じてSGAとインスタンスPGAの間でメモリーを動的に交換し、処理ニーズに対応します。この機能を自動メモリー管理と呼びます。このメモリー管理の方法では、データベースは個別SGAコンポーネントのサイズと個別PGAのサイズも動的にチューニングします。

手動メモリー管理

個々のメモリー・コンポーネントのサイズをより直接的に制御する場合は、自動メモリー管理を使用禁止にして、手動メモリー管理用にデータベースを構成できます。手動メモリー管理として使用できる方法はいくつかあります。これらの方法には、自動の部分が、ある度合で残っているものがあります。それらの方法では、DBAに要求される作業量および知識量が異なります。次の方法があります。

- 自動共有メモリー管理: SGA用

- 手動共有メモリー管理: SGA用

- 自動PGAメモリー管理: インスタンスPGA用

- 手動PGAメモリー管理: インスタンスPGA用

これらのメモリー管理方法については、この章で後述します。

注意:
メモリーを管理する最も簡単な方法は、Oracle Enterprise Managerのグラフィカル・ユーザー・インタフェースを使用することです。
Enterprise Managerを使用してメモリーを管理する手順は、次のとおりです。

1. 次のいずれかを実行します。
- Oracle Enterprise Manager Database Controlを使用している場合は、データベース・ホームページにアクセスします。手順については、『Oracle Database 2日でデータベース管理者』を参照してください。

- Oracle Enterprise Manager Grid Controlを使用している場合は、対象のデータベース・ターゲットに進みます。データベース・ホームページが表示されます。

2. ページの上部で、「サーバー」をクリックし、「サーバー」ページを表示します。

3. 「データベース構成」セクションで、「メモリー・アドバイザ」をクリックします。

関連項目:
メモリーの自動管理および手動管理の様々な方法については、『Oracle Database概要』を参照してください。

メモリー・アーキテクチャの概要

Oracle Databaseに関連する基本的なメモリー構造は、次のような領域で構成されています。

- システム・グローバル領域(SGA)
SGAは、SGAコンポーネントと呼ばれる共有メモリー構造のグループで、1つのOracle Databaseインスタンスに関するデータと制御情報が保存されています。SGAは、すべてのサーバー・プロセスとバックグラウンド・プロセスで共有されます。SGAに格納されるデータには、キャッシュ・データ・ブロックや共有SQL領域などがあります。

- プログラム・グローバル領域(PGA)
PGAは、サーバー・プロセスのデータおよび制御情報が含まれるメモリー領域です。これはサーバー・プロセスの開始時にOracle Databaseによって作成される非共有メモリーです。PGAへのアクセスは、サーバー・プロセスごとに排他的です。各サーバー・プロセスごとに1つのPGAが存在します。バックグラウンド・プロセスにも独自のPGAが割り当てられます。Oracle Databaseインスタンスに連結されるすべてのバックグラウンドおよびサーバー・プロセスに割り当てられるPGAメモリーの合計はインスタンスPGAメモリー合計と呼ばれ、個々のPGAの集合はインスタンスPGA合計、または単にインスタンスPGAと呼ばれます。

図6-1に、これらのメモリー構造の関係を示します。

図6-1 Oracle Databaseのメモリー構造

データベースがSolarisまたはOracle Linux上で稼働している場合、オプションで別のメモリー・コンポーネント、Database Smart Flash Cache (フラッシュ・キャッシュ)もオプションで追加できます。フラッシュ・キャッシュは、SGAに常駐するバッファ・キャッシュの拡張機能で、データベース・ブロックにレベル2のキャッシュを提供します。特に読取りが集中するオンライン・トランザクション処理(OLTP)のワークロードで、応答時間と全体的なスループットを改善できます。フラッシュ・キャッシュは、フラッシュ・メモリーを使用するソリッド状態の記憶装置である1つ以上のフラッシュ・ディスク装置に常駐します。

フラッシュ・キャッシュは、一般的に、メイン・メモリーの増設よりも経済的であり、かつ、ディスク・ドライブよりもはるかに高速です。

関連項目:

- Oracle Databaseインスタンスのメモリー・アーキテクチャの詳細は、『Oracle Database概要』を参照してください。

- 「Database Smart Flash Cacheの構成」

自動メモリー管理の使用

ここでは、Oracle Databaseの自動メモリー管理機能のバックグラウンド情報を提供し、この機能を使用可能にする方法を示します。この章では、次の項目について説明します。

- 自動メモリー管理の概要

- 自動メモリー管理の有効化

- 自動メモリー管理の監視およびチューニング

自動メモリー管理の概要

インスタンス・メモリーを管理する最も単純な方法は、Oracle Databaseインスタンスで自動的に管理およびチューニングされるようにすることです。これを実行するには、ほとんどのプラットフォームの場合、ターゲット・メモリー・サイズ初期化パラメータ(MEMORY_TARGET)とオプションで最大メモリー・サイズ初期化パラメータ(MEMORY_MAX_TARGET)のみを設定します。インスタンスによって使用される合計メモリーはMEMORY_TARGETの値に基づき、相対的に一定なままとなり、メモリーはインスタンスによってシステム・グローバル領域(SGA)とインスタンス・プログラム・グローバル領域(インスタンスPGA)の間で自動的に配分されます。メモリー要件の変化に応じて、メモリーはインスタンスによってSGAとインスタンスPGAの間で動的に再配分されます。

自動メモリー管理が有効化されていない場合は、SGAとインスタンスPGAの両方を手動でサイズ設定する必要があります。

MEMORY_TARGET初期化パラメータは動的であるため、データベースの再起動なしにいつでもMEMORY_TARGETを変更できます。MEMORY_MAX_TARGETは動的ではなく、誤ってMEMORY_TARGETを高く設定しすぎないための上限として機能し、今後インスタンス・メモリーの合計を増加する際に、データベース・インスタンス用に十分なメモリーを確保するために使用されます。また、一部のSGAコンポーネントは簡単に縮小できないか、または最小サイズに抑える必要があるため、インスタンスではユーザーがMEMORY_TARGETの設定を低くしすぎないようにします。

Database Configuration Assistant(DBCA)を使用してデータベースを作成する際に基本インストール・オプションを選択した場合は、自動メモリー管理が使用可能になります。拡張インストールを選択した場合は、Database Configuration Assistant(DBCA)を使用して自動メモリー管理を選択できます。

注意:
LOCK_SGA初期化パラメータがTRUEに設定されている場合は、自動メモリー管理を使用可能にできません。このパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

関連項目:

- 「自動メモリー管理をサポートするプラットフォーム」

自動メモリー管理の有効化

データベースの作成時に(DBCAで適切なオプションを選択して、またはCREATE DATABASE SQL文に適切な初期化パラメータを設定して)自動メモリー管理を使用可能にしなかった場合は、後で自動メモリー管理を使用可能にできます。自動メモリー管理を有効化する場合は、データベースを停止して再起動する必要があります。

自動メモリー管理を使用可能にする手順は、次のとおりです。

1. SQL*Plusを起動して、SYSDBAユーザーとしてデータベースに接続します。
手順については、「SQL*Plusを使用したデータベースへの接続」および「データベース管理者の認証」を参照してください。

2. MEMORY_TARGETの最小値を次の方法で計算します。

1. 次のSQL*Plusコマンドを入力して、SGA_TARGETおよびPGA_AGGREGATE_TARGETの現行サイズを確認します。

SHOW PARAMETER TARGET

SQL*Plusによって、すべての初期化パラメータの値が、パラメータ名にTARGETが付加されて表示されます。

NAME                                 TYPE        VALUE
------------------------------------ ----------- ----------------
archive_lag_target                   integer     0
db_flashback_retention_target        integer     1440
fast_start_io_target                 integer     0
fast_start_mttr_target               integer     0
memory_max_target                    big integer 0
memory_target                        big integer 0
parallel_servers_target              integer     16
pga_aggregate_target                 big integer 90M
sga_target                           big integer 272M

2. 次の問合せを実行して、データベースの起動以降に割り当てられた最大インスタンスPGAを確認します。

select value from v$pgastat where name='maximum PGA allocated';

3. 手順2bおよびPGA_AGGREGATE_TARGETの問合せの結果を比較して最大値を算定します。この値にSGA_TARGETを加算します。

memory_target = sga_target + max(pga_aggregate_target, maximum PGA allocated)

たとえば、前述のようにSGA_TARGETが272M、PGA_AGGREGATE_TARGETが90Mで、割当て済の最大PGAが120Mと確認された場合、MEMORY_TARGETは392M(272M + 120M)以上にする必要があります。

3. 使用するMEMORY_TARGETの値を選択します。

この値は、手順2で計算した最小値にするか、または使用可能な物理メモリーが十分ある場合はこれより大きい値を使用できます。

4. MEMORY_MAX_TARGET初期化パラメータについては、予測可能な範囲で、データベースに割り当てる予定の最大メモリー量に決定します。つまり、SGAとインスタンスPGAサイズの合計に対する最大値を決定します。この値は、前述の手順で選択したMEMORY_TARGETの値以上に設定できます。

5. 次のいずれかを実行します。

- Oracle Databaseインスタンスをサーバー・パラメータ・ファイルを使用して起動(Database Configuration Assistant(DBCA)を使用してデータベースを作成した場合のデフォルト)した場合は、次のコマンドを入力します。

ALTER SYSTEM SET MEMORY_MAX_TARGET = nM SCOPE = SPFILE;

nは手順4で計算した値です。

SCOPE = SPFILE句を指定すると、サーバー・パラメータ・ファイル内の値のみが設定され、実行中のインスタンスに対する値は設定されません。MEMORY_MAX_TARGETは動的な初期化パラメータではないため、このSCOPE句を組み込む必要があります。

- インスタンスをテキスト形式の初期化パラメータ・ファイルを使用して起動した場合は、ファイルを手動で編集して次の文を組み込みます。

memory_max_target = nM
memory_target = mM

nは手順4で決定した値、mは手順3で決定した値です。

注意:
テキスト形式の初期化パラメータ・ファイルでは、MEMORY_MAX_TARGETの行を省略してMEMORY_TARGETの値を指定した場合、データベースによって、MEMORY_MAX_TARGETはMEMORY_TARGETの値に自動的に設定されます。MEMORY_TARGETの行を省略してMEMORY_MAX_TARGETの値を含める場合、MEMORY_TARGETパラメータのデフォルトは0になります。起動後、MEMORY_MAX_TARGETの値を超えないかぎり、MEMORY_TARGETを0以外の値に動的に変更できます。

6. データベースを停止して再起動します。
手順については、第3章「起動と停止」を参照してください。

7. Oracle Databaseインスタンスをサーバー・パラメータ・ファイルを使用して起動した場合は、次のコマンドを入力します。

ALTER SYSTEM SET MEMORY_TARGET = nM;
ALTER SYSTEM SET SGA_TARGET = 0;
ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 0;

nは手順3で決定した値です。

注意:
この手順では、SGAとインスタンスPGAのサイズが必要に応じて制限なくチューニングされるように、SGA_TARGETとPGA_AGGREGATE_TARGETを0(ゼロ)に設定するように指示しています。これらのパラメータ値を0(ゼロ)に設定する文を削除し、いずれかまたは両方の値を正数にしておくことができます。この場合、値はSGAまたはインスタンスPGAのサイズの最小値として機能します。

関連項目:

- 「自動メモリー管理の概要」

- 「メモリー・アーキテクチャの概要」

- ALTER SYSTEM SQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

自動メモリー管理の監視およびチューニング

動的なパフォーマンス・ビューV$MEMORY_DYNAMIC_COMPONENTSに、SGAとインスタンスPGAの合計サイズなど、動的にチューニングされたすべてのメモリー・コンポーネントの現行サイズが示されます。

ビューV$MEMORY_TARGET_ADVICEでは、MEMORY_TARGET初期化パラメータに対するチューニング・アドバイスが提供されます。

SQL>  select * from v$memory_target_advice order by memory_size;

MEMORY_SIZE MEMORY_SIZE_FACTOR ESTD_DB_TIME ESTD_DB_TIME_FACTOR    VERSION
----------- ------------------ ------------ ------------------- ----------
180                 .5          458               1.344          0
270                .75          367              1.0761          0
360                  1          341                   1          0
450               1.25          335               .9817          0
540                1.5          335               .9817          0
630               1.75          335               .9817          0
720                  2          335               .9817          0

MEMORY_SIZE_FACTORが1の行には、MEMORY_TARGET初期化パラメータで設定されたメモリーの現行サイズ、および現行のワークロードを完了するために必要なDB時間の量が示されています。上下の行の結果には、いくつかのMEMORY_TARGETの代替サイズが示されています。各代替サイズについて、サイズ・ファクタ(現行サイズの乗数)、MEMORY_TARGETパラメータが代替サイズに変更された場合に現行のワークロードを完了するために必要な見積DB時間が示されます。合計メモリー・サイズがMEMORY_TARGETの現行サイズより小さい場合は、見積DB時間が増加していることに注意してください。また、この例では、合計メモリー・サイズを450MBより大きくしても効果がないことに注意してください。ただし、ワークロード全体がまだ実行されていない場合、この状況は変わる可能性があります。

Enterprise Managerには、MEMORY_TARGETの最適なサイズを選択できる使いやすいグラフィカル・メモリー・アドバイザが用意されています。詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

関連項目:

- これらの動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- DB時間の定義については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

メモリーの手動構成

個々のメモリー・コンポーネントのサイズをより直接的に制御する場合は、自動メモリー管理を使用禁止にして、手動メモリー管理用にデータベースを構成できます。SGAおよびインスタンスPGAについて、それぞれ2つの異なる手動メモリー管理方法があります。

SGAの2つの手動メモリー管理方法では、DBAに要求される作業量および知識量が異なります。自動共有メモリー管理では、SGAのターゲット・サイズと最大サイズを設定します。設定後、データベースによって、SGAの合計サイズが指定したターゲットに適合するように設定され、多数のSGAコンポーネントのサイズが動的にチューニングされます。手動共有メモリー管理では、複数の個別SGAコンポーネントのサイズを設定することで、SGA全体のサイズを決定します。その後、個別SGAコンポーネントを継続的に手動でチューニングします。

インスタンスPGAに関しては、自動PGAメモリー管理があり、インスタンスPGAのターゲット・サイズを設定します。設定後、データベースによって、インスタンスPGAのサイズが指定したターゲットに適合するように設定され、個々のPGAのサイズが動的にチューニングされます。また、手動PGAメモリー管理では、各タイプのSQL演算子(ソートやハッシュ結合など)のタイプごとに作業領域の最大サイズを設定します。このメモリー管理方法は、サポートされていますがお薦めしません。

次の各項では、これらの手動メモリー管理方法すべてについて詳細に説明します。

- 自動共有メモリー管理の使用

- 手動共有メモリー管理の使用

- 自動PGAメモリー管理の使用

- 手動PGAメモリー管理の使用

関連項目:
Oracle Databaseのメモリー管理方法の概要は、『Oracle Database概要』を参照してください。

自動共有メモリー管理の使用

この項の内容は次のとおりです。

- 自動共有メモリー管理の概要

- SGAのコンポーネントおよびグラニュル

- 最大SGAサイズの設定

- SGAターゲット・サイズの設定

- 自動共有メモリー管理を使用可能にする方法

- 自動共有メモリー管理の詳細説明

関連項目:

- SGAのコンポーネントのチューニング方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

自動共有メモリー管理の概要

自動共有メモリー管理によってSGAメモリー管理が簡素化されます。SGA_TARGET初期化パラメータを使用してインスタンスに使用可能なSGAメモリーの合計量を指定すると、Oracle Databaseによって、メモリーが最も効率的に使用されるように、このメモリーが様々なSGAコンポーネントに自動的に配分されます。

自動共有メモリー管理が使用可能な場合、様々なSGAコンポーネントのサイズは自由に変更され、ワークロードのニーズにあわせてチューニングされるため、追加構成の必要はありません。データベースによって、必要に応じて使用可能なメモリーが様々なコンポーネントに自動的に配分されるため、システムでは使用可能なすべてのSGAメモリーを最大限に使用できます。

サーバー・パラメータ・ファイル(SPFILE)を使用している場合、データベースでは、自動チューニングされたSGAコンポーネントのサイズがインスタンス停止後も保持されます。このため、データベース・インスタンスでは、インスタンスが起動するたびにワークロードの特性を再度認識する必要がありません。インスタンスでは、以前のインスタンスの情報に基づいて、前回インスタンスが停止した時点でのワークロードを継続して評価できます。

SGAのコンポーネントおよびグラニュル

SGAは、特定のクラスのメモリー割当て要求を満たすために使用されるメモリーのプールであるいくつかのメモリー・コンポーネントで構成されます。メモリー・コンポーネントの例として、共有プール(SQLおよびPL/SQL実行のメモリー割当てに使用)、Javaプール(Javaオブジェクトおよびその他のJava実行メモリーに使用)、およびバッファ・キャッシュ(キャッシュ・ディスク・ブロックに使用)などがあります。すべてのSGAコンポーネントがグラニュルという単位で領域を割当ておよび割当て解除します。Oracle Databaseは、各SGAコンポーネントに対するグラニュルの内部数でSGAメモリーの使用状況を追跡します。

SGAの動的コンポーネント用のメモリーは、グラニュル単位で割り当てられます。グラニュル・サイズは、インスタンスが起動するときに要求されるSGAメモリーの量によって決まります。グラニュル・サイズは、SGA_MAX_SIZE初期化パラメータの値に基づいています。表6-1は、SGAメモリーの様々な量でのグラニュル・サイズを示しています。

表6-1 グラニュル・サイズ

SGAメモリーの量

グラニュル・サイズ

1GB以下

4MB

1GBより大きく8GB以下

16MB

8GBより大きく16GB以下

32MB

16GBより大きく32GB以下

64MB

32GBより大きく64GB以下

128MB

64GBより大きく128GB以下

256MB

128GBよりも大きい

512MB

一部にプラットフォーム依存性が存在する場合があります。詳細は、使用しているオペレーティング・システム固有のマニュアルを参照してください。

V$SGAINFOビューを問い合せると、インスタンスで使用中のグラニュル・サイズを確認できます。SGAのすべてのコンポーネントに、同じグラニュル・サイズが使用されます。

コンポーネントに対してグラニュル・サイズの倍数でないサイズを指定すると、そのサイズは最も近い倍数に繰り上げられます。たとえば、グラニュル・サイズが4MBの場合にDB_CACHE_SIZEを10MBとして指定すると、実際には12MBが割り当てられます。

関連項目:
SGA_MAX_SIZE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

最大SGAサイズの設定

インスタンスの存続期間中のSGAの最大サイズは、SGA_MAX_SIZE初期化パラメータによって決まります。バッファ・キャッシュ、共有プール、ラージ・プール、JavaプールおよびStreamsプールのサイズに影響を与える初期化パラメータは動的に変更できますが、これらのサイズとSGAの他のコンポーネント(固定SGA、可変SGAおよびREDOログ・バッファ)のサイズとの合計が、SGA_MAX_SIZEで指定された値を超えるような変更はできません。

SGA_MAX_SIZEが指定されていない場合は、初期化時に指定またはデフォルト設定されたコンポーネントすべての合計がデフォルト値として選択されます。SGA_MAX_SIZEに指定した値が、データベースの初期化時に、すべてのコンポーネントに対してパラメータ・ファイルで明示的にまたはデフォルトで割り当てたメモリーの合計より少ない場合、SGA_MAX_SIZEの設定は無視され、このパラメータに対する適切な値が選択されます。

SGAターゲット・サイズの設定

自動共有メモリー管理機能を有効にするには、SGA_TARGETパラメータを0(ゼロ)以外の値に設定します。このパラメータにより、SGAの合計サイズが設定されます。これは、個別のコンポーネントのセットの割当てメモリーを制御するパラメータにかわるもので、これらは必要に応じて自動的かつ動的にサイズ調整(チューニング)されるようになりました。

注意:
自動共有メモリー管理が機能するには、STATISTICS_LEVEL初期化パラメータがTYPICAL(デフォルト)またはALLに設定されている必要があります。

表6-2に、SGA_TARGETが設定されると自動的にサイズ変更されるSGAコンポーネントを示します。各SGAコンポーネントについては、関連する初期化パラメータを示します。

表6-2 自動サイズ設定SGAコンポーネントと対応するパラメータ

SGAコンポーネント

初期化パラメータ

固定SGAおよびOracle Databaseインスタンスに必要なその他の内部割当て

N/A

共有プール

SHARED_POOL_SIZE

ラージ・プール

LARGE_POOL_SIZE

Javaプール

JAVA_POOL_SIZE

バッファ・キャッシュ

DB_CACHE_SIZE

Streamsプール

STREAMS_POOL_SIZE

表6-3にリストされているパラメータは、設定された場合、SGA_TARGETからメモリーを取得しますが、表6-2にリストされたコンポーネントに使用されるメモリーは残されます。

表6-3 SGA_TARGETの領域を使用する手動サイズ設定SGAコンポーネント

SGAコンポーネント

初期化パラメータ

ログ・バッファ

LOG_BUFFER

KEEPバッファ・キャッシュおよびRECYCLEバッファ・キャッシュ

DB_KEEP_CACHE_SIZE

DB_RECYCLE_CACHE_SIZE

非標準ブロック・サイズ・バッファ・キャッシュ

DB_nK_CACHE_SIZE

SGA_TARGETを0(ゼロ)以外の値に設定する以外に、自動サイズ設定SGAコンポーネントの完全な自動チューニングを使用可能にするために、表6-2に示されているすべての初期化パラメータを0(ゼロ)に設定する必要があります。

または、自動サイズ設定SGAコンポーネントを0(ゼロ)以外の値に設定すると、その値がSGAチューニング中のコンポーネントの最小設定として使用されます。詳細は後に説明します。

注意:
より簡単に自動共有メモリー管理を使用可能にするには、Oracle Enterprise Managerを使用します。自動共有メモリー管理を使用可能にし、合計SGAサイズを設定すると、Enterprise ManagerによってALTER SYSTEM文が自動的に生成され、SGA_TARGETが指定したサイズに設定され、自動サイズ設定SGAコンポーネントがすべて0(ゼロ)に設定されます。
SQL*Plusを使用してSGA_TARGETを設定する場合は、自動サイズ設定SGAコンポーネントを0(ゼロ)または最小値に設定する必要があります。

SGAおよび仮想メモリー

ほとんどのシステムで最適なパフォーマンスを実現するには、SGA全体が実メモリーに収まる必要があります。実メモリーに収まらず、その一部を格納するために仮想メモリーが使用される場合は、データベース・システム全体のパフォーマンスが大幅に低下する可能性があります。これは、オペレーティング・システムによってSGAの一部でページング(ディスクの読取りおよび書込み)が実行されるためです。

ページング・アクティビティを監視する方法は、使用しているオペレーティング・システムのマニュアルを参照してください。また、Enterprise Managerの「ホスト」ページの「パフォーマンス」プロパティ・ページからページング・アクティビティを表示することもできます。

SGAターゲット・サイズの監視およびチューニング

V$SGAINFOビューでは、様々なSGAコンポーネントの現行のチューニング・サイズに関する情報が提供されます。

V$SGA_TARGET_ADVICEビューでは、SGA_TARGETの値の決定に役立つ情報が提供されます。

SQL> select * from v$sga_target_advice order by sga_size;

SGA_SIZE SGA_SIZE_FACTOR ESTD_DB_TIME ESTD_DB_TIME_FACTOR ESTD_PHYSICAL_READS
---------- --------------- ------------ ------------------- -------------------
290              .5       448176              1.6578             1636103
435             .75       339336              1.2552             1636103
580               1       270344                   1             1201780
725            1.25       239038               .8842              907584
870             1.5       211517               .7824              513881
1015            1.75       201866               .7467              513881
1160               2       200703               .7424              513881

このビューの情報は、自動メモリー管理用のV$MEMORY_TARGET_ADVICEビューで提供される情報と同じです。このビューについては、「自動メモリー管理の監視およびチューニング」を参照してください。

Enterprise Managerには、SGA_TARGETの最適なサイズを選択できる使いやすいグラフィカル・メモリー・アドバイザが用意されています。詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

関連項目:
これらの動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

自動共有メモリー管理を使用可能にする方法

自動共有メモリー管理(ASMM)を使用可能にする手順は、手動共有メモリー管理からASMMに変更するか、自動メモリー管理からASMMに変更するかによって異なります。

手動共有メモリー管理からASMMに変更する手順は、次のとおりです。

1. 次の問合せを実行してSGA_TARGETの値を取得します。

SELECT (
(SELECT SUM(value) FROM V$SGA) -
(SELECT CURRENT_SIZE FROM V$SGA_DYNAMIC_FREE_MEMORY)
) "SGA_TARGET"
FROM DUAL;

2. テキスト形式の初期化パラメータ・ファイルを編集してデータベースを再起動するか、または次の文を発行してSGA_TARGETの値を設定します。

ALTER SYSTEM SET SGA_TARGET=value [SCOPE={SPFILE|MEMORY|BOTH}]

valueは手順1で計算した値、またはすべてのSGAコンポーネント・サイズの合計とSGA_MAX_SIZEの間の値です。ALTER SYSTEM文とそのSCOPE句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

3. 次のいずれかを実行します。

- より完全な自動チューニングを行うには、表6-2に記載されている自動サイズ設定SGAコンポーネントの値を0(ゼロ)に設定します。このためには、テキスト形式の初期化パラメータ・ファイルを編集するか、またはALTER SYSTEM文を発行します。

- 1つ以上の自動サイズ設定SGAコンポーネントの最小サイズを制御するには、これらのコンポーネントのサイズを目的の値に設定します。(詳細は、次の項を参照してください。)その他の自動サイズ設定SGAコンポーネントの値を0(ゼロ)に設定します。このためには、テキスト形式の初期化パラメータ・ファイルを編集するか、またはALTER SYSTEM文を発行します。

自動メモリー管理からASMMに変更する手順は、次のとおりです。

1. MEMORY_TARGET初期化パラメータを0(ゼロ)に設定します。

ALTER SYSTEM SET MEMORY_TARGET = 0;

データベースによって、現在のSGAメモリー割当てに基づいてSGA_TARGETが設定されます。

2. 次のいずれかを実行します。

- より完全な自動チューニングを行うには、表6-2に記載されている自動サイズ設定SGAコンポーネントのサイズを0(ゼロ)に設定します。このためには、テキスト形式の初期化パラメータ・ファイルを編集するか、またはALTER SYSTEM文を発行します。

- 1つ以上の自動サイズ設定SGAコンポーネントの最小サイズを制御するには、これらのコンポーネントのサイズを目的の値に設定します。(詳細は、次の項を参照してください。)その他の自動サイズ設定SGAコンポーネントのサイズを0(ゼロ)に設定します。このためには、テキスト形式の初期化パラメータ・ファイルを編集するか、またはALTER SYSTEM文を発行します。

例

たとえば、手動共有メモリー管理用にインスタンスのパラメータが現在次のように構成されていて、SGA_MAX_SIZEが1200Mに設定されているとします。

- SHARED_POOL_SIZE = 200M

- DB_CACHE_SIZE = 500M

- LARGE_POOL_SIZE = 200M

また、問合せが次のような結果であるとします。

問合せ

結果

SELECT SUM(value) FROM V$SGA

1200M

SELECT CURRENT_SIZE FROM V$SGA_DYNAMIC_FREE_MEMORY

208M

Oracle Enterprise Managerで合計SGAサイズを992Mに設定するか、次の文を発行することによって、自動共有メモリー管理を利用できます。

ALTER SYSTEM SET SGA_TARGET = 992M;
ALTER SYSTEM SET SHARED_POOL_SIZE = 0;
ALTER SYSTEM SET LARGE_POOL_SIZE = 0;
ALTER SYSTEM SET JAVA_POOL_SIZE = 0;
ALTER SYSTEM SET DB_CACHE_SIZE = 0;
ALTER SYSTEM SET STREAMS_POOL_SIZE = 0;

992Mは、1200M - 208Mから算出された値です。

自動共有メモリー管理の詳細説明

この項では、自動共有メモリー管理について詳細に説明します。内容は次のとおりです。

- 自動サイズ設定SGAコンポーネントの最小値の設定

- SGA_TARGETの動的変更

- 自動サイズ設定コンポーネントのパラメータの変更

- 手動サイズ設定コンポーネントのパラメータの変更

自動サイズ設定SGAコンポーネントの最小値の設定

自動サイズ設定SGAコンポーネントに対応するパラメータに最小値を指定して、これらのコンポーネントのサイズをある程度制御できます。この設定は、特定のコンポーネントで最低限のメモリーが確保されていないとアプリケーションが正しく動作しないことがわかっている場合に便利です。コンポーネントに対してSGA領域の最小量を指定するには、対応する初期化パラメータの値を設定します。

1つ以上の自動サイズ設定コンポーネントの最小サイズを手動で制限すると、動的な調整に使用されるメモリーの合計量が減少します。この量が減少すると、システムがワークロードの変動に適応するシステムの機能が次々に制限されます。したがって、この方法は特別な場合を除いてお薦めしません。デフォルトの自動管理は、システム・パフォーマンスおよび使用可能なリソースの使用が最大になるように動作します。

SGA_TARGETの動的変更

SGA_TARGETパラメータは、SGA_MAX_SIZEパラメータに指定された値まで動的に増やすことができ、減らすこともできます。SGA_TARGETの値を減らした場合は、メモリーを解放する1つ以上の自動調整コンポーネントがシステムによって識別されます。SGA_TARGETは、1つ以上の自動調整コンポーネントがその最小サイズに達するまで減らすことができます。Oracle Databaseでは、SGA_TARGETの最小許容値を決定するときに、自動サイズ設定コンポーネントに設定された値、SGA_TARGET領域を使用する手動サイズ設定コンポーネント、CPUの数など、いくつかの要因が考慮されます。

SGA_TARGETが変更されたときに、消費される物理メモリーの量の変更は、オペレーティング・システムによって異なります。動的共有メモリーをサポートしない一部のUNIXプラットフォームでは、SGAで使用される物理メモリーはSGA_MAX_SIZEパラメータの値と同じです。SGA_TARGETをSGA_MAX_SIZEより小さい値に設定した場合、このようなプラットフォームでは実際の利点はありません。したがって、これらのプラットフォームでは、SGA_MAX_SIZEを設定しないことをお薦めします。

SolarisやWindowsなどの他のプラットフォームでは、SGAで消費される物理メモリーはSGA_TARGETと同じです。

たとえば、次のような構成環境とします。

- SGA_MAX_SIZE = 1024M

- SGA_TARGET = 512M

- DB_8K_CACHE_SIZE = 128M

この例では、SGA_TARGETは1024Mまでサイズを増やすことができ、自動サイズ設定コンポーネントの1つ以上がその最小サイズに達するまでサイズを減らすこともできます。正確な値は、システムのCPU数などの環境要因によって決定します。ただし、DB_8K_CACHE_SIZEの値は常に128Mで固定です。

注意:
自動共有メモリー管理機能を使用可能にする場合、データベースを起動する前に、SGA_TARGETを0(ゼロ)以外の目的の値に設定しておくことをお薦めします。SGA_TARGETを0(ゼロ)から0(ゼロ)以外の値に動的に変更しても、共有プールを縮小できない場合があるため、目的の結果が得られないことがあります。起動後も、必要に応じてSGA_TARGETの値を動的に増減できます。

自動サイズ設定コンポーネントのパラメータの変更

SGA_TARGETが設定されていない場合、自動共有メモリー管理機能は使用できません。したがって、すべてのコンポーネント・パラメータのサイズ変更に関するルールは以前のリリースの場合と同じです。ただし、自動共有メモリー管理が有効な場合は、自動的にサイズ変更したコンポーネントについて手動で指定したサイズが、そのコンポーネントの下限のサイズとして機能します。この制限は、対応するパラメータの値を変更することで動的に変更できます。

特定のSGAコンポーネントに指定したサイズの下限が、現在のサイズより小さい場合、そのコンポーネントのサイズはすぐには変更されません。新しい設定は自動チューニング・アルゴリズムを将来において減少した最小サイズに制限するのみです。たとえば、次のような構成を考えてみます。

- SGA_TARGET = 512M

- LARGE_POOL_SIZE = 256M

- 現在の実際のラージ・プール・サイズ = 284M

この例では、LARGE_POOL_SIZEの値をコンポーネントの実際の現在のサイズよりも大きい値に増加すると、増加した最小サイズに対応するように、システムによってコンポーネントが拡大されます。たとえば、LARGE_POOL_SIZEの値を300Mに増加すると、ラージ・プールが300Mに達するまで増分的に増加されます。サイズ変更をすると、1つ以上の自動チューニングされたコンポーネントが影響を受けます。LARGE_POOL_SIZEの値を200に減少すると、そのコンポーネントのサイズはすぐには変更されません。新しい設定は、後のラージ・プール・サイズの削減のみを200Mに制限します。

手動サイズ設定コンポーネントのパラメータの変更

手動サイズ設定コンポーネントのパラメータも動的に変更できます。ただし、最小サイズは設定しないで、パラメータの値によって、対応するコンポーネントの正確なサイズを指定します。手動サイズ設定コンポーネントのサイズを増やすと、余分なメモリーが1つ以上の自動サイズ設定コンポーネントから削除されます。手動サイズ設定コンポーネントのサイズを減らすと、解放されたメモリーが複数の自動サイズ設定コンポーネントに提供されます。

たとえば、次のような構成を考えてみます。

- SGA_TARGET = 512M

- DB_8K_CACHE_SIZE = 128M

この例のDB_8K_CACHE_SIZEを16M増やして144Mにすると、その16Mが、自動サイズ設定コンポーネントから削除されます。同様に、DB_8K_CACHE_SIZEを16M減らして112Mにすると、その16Mが、自動サイズ設定コンポーネントに提供されます。

手動共有メモリー管理の使用

自動メモリー管理または自動共有メモリー管理を使用しない場合は、いくつかのSGAコンポーネントのサイズを手動で構成し、データベース・ワークロードの変更に基づいてこれらのサイズを監視およびチューニングする必要があります。ここでは、これらのSGAコンポーネントのサイズを制御するパラメータの設定ガイドラインを提供します。

DBCAを使用してデータベースを作成し、手動共有メモリー管理を選択した場合、バッファ・キャッシュ、共有プール、ラージ・プールおよびJavaプールのサイズを入力する必須フィールドがDBCAで表示されます。次に、対応する初期化パラメータが、作成されるサーバー・パラメータ・ファイル(SPFILE)に設定されます。かわりにデータベースをCREATE DATABASE SQL文とテキスト初期化パラメータ・ファイルで作成した場合、次のいずれかを実行します。

- SGAコンポーネント・サイズを設定する初期化パラメータの値を指定します。

- テキスト形式の初期化ファイルからSGAコンポーネント・サイズのパラメータを削除します。サイズを設定していないコンポーネントに対しては、Oracle Databaseによって適切なデフォルトが選択されます。

この項の内容は次のとおりです。

- 手動共有メモリー管理を使用可能にする方法

- バッファ・キャッシュ初期化パラメータの設定

- 共有プール・サイズの指定

- ラージ・プール・サイズの指定

- Javaプール・サイズの指定

- Streamsプール・サイズの指定

- 結果キャッシュの最大サイズの指定

- その他のSGA初期化パラメータの指定

手動共有メモリー管理を使用可能にする方法

手動共有メモリー管理自体を使用可能にする初期化パラメータはありません。自動メモリー管理と自動共有メモリー管理の両方を使用禁止にすることによって、手動共有メモリー管理が事実上使用可能になります。

手動共有メモリー管理を使用可能にする手順は、次のとおりです。

1. MEMORY_TARGET初期化パラメータを0(ゼロ)に設定します。

2. SGA_TARGET初期化パラメータを0(ゼロ)に設定します。

次に、以降の項の説明に従って、様々なSGAコンポーネントの値を設定する必要があります。

バッファ・キャッシュ初期化パラメータの設定

SGAコンポーネントであるバッファ・キャッシュのサイズは、バッファ・キャッシュ初期化パラメータによって決まります。これらのパラメータを使用して、データベースで使用される各ブロック・サイズのキャッシュ・サイズを指定します。これらの初期化パラメータはすべて動的です。

バッファ・キャッシュのサイズはパフォーマンスに影響を及ぼします。一般に、キャッシュ・サイズを大きくすると、ディスクの読取りと書込みの回数が少なくなります。ただし、キャッシュを大きくすると、メモリーを過度に消費してページングやスワッピングが発生する可能性があります。

Oracle Databaseでは、データベース内で複数のブロック・サイズがサポートされます。非標準のブロック・サイズを設定した表領域を作成する場合は、これらの表領域を格納するための非標準のブロック・サイズ・バッファを構成する必要があります。SYSTEM表領域には標準のブロック・サイズが使用されます。標準のブロック・サイズを指定するには、初期化パラメータDB_BLOCK_SIZEを設定します。指定できる値は2Kから32Kです。

データベースで複数のブロック・サイズを使用する場合は、DB_CACHE_SIZEと、少なくとも1つのDB_nK_CACHE_SIZEパラメータを設定する必要があります。Oracle Databaseは、DB_CACHE_SIZEパラメータに適切なデフォルト値を割り当てますが、DB_nK_CACHE_SIZEパラメータはデフォルトで0(ゼロ)に設定され、追加のブロック・サイズ・キャッシュは構成されません。

非標準のブロック・サイズ・バッファのサイズおよび数は、次のパラメータによって指定します。

DB_2K_CACHE_SIZE
DB_4K_CACHE_SIZE
DB_8K_CACHE_SIZE
DB_16K_CACHE_SIZE
DB_32K_CACHE_SIZE

各パラメータは、対応するブロック・サイズのキャッシュ・サイズを指定します。

注意:

- 最大ブロック・サイズに関するプラットフォーム固有の制限が適用されるため、プラットフォームによっては、これらのサイズの一部は指定できない場合があります。

- 32KBのブロック・サイズは、64ビットのプラットフォームでのみ有効です。

関連項目:
「表領域の非標準のブロック・サイズの指定」

ブロック・サイズおよびキャッシュ・サイズの設定例

DB_BLOCK_SIZE=4096
DB_CACHE_SIZE=1024M
DB_2K_CACHE_SIZE=256M
DB_8K_CACHE_SIZE=512M

この例では、パラメータDB_BLOCK_SIZEは、データベースの標準ブロック・サイズを4Kに設定しています。標準ブロック・サイズ・バッファのキャッシュ・サイズは1024MBです。また、2KBおよび8KBのキャッシュ・サイズがそれぞれ256MBと512MBで構成されます。

注意:
DB_nK_CACHE_SIZEパラメータを使用して、標準ブロック・サイズのキャッシュ・サイズを指定することはできません。DB_BLOCK_SIZEの値がnKBの場合にDB_nK_CACHE_SIZEを設定しても無効です。標準ブロック・サイズのキャッシュ・サイズは、常にDB_CACHE_SIZEの値によって決まります。

キャッシュのサイズは制限されているため、ディスク上のすべてのデータをキャッシュに格納することはできません。キャッシュが一杯の場合、その後キャッシュ・ミスが発生すると、新しいデータ用の領域を空けるために、Oracle Databaseはキャッシュにすでに存在する使用済データをディスクに書き込みます。(バッファが使用済でない場合、新しいブロックをバッファに読み込む前にディスクに書き込む必要はありません。)ディスクに書き込まれ、上書きされた結果がその後アクセスされると、さらにキャッシュ・ミスが発生します。

キャッシュのサイズは、データを要求したときにキャッシュ・ヒットになる確率に影響します。キャッシュが大きい場合は、要求されたデータがキャッシュに入っている可能性が高くなります。キャッシュのサイズを大きくすると、データ要求がキャッシュ・ヒットになる確率が高くなります。

インスタンスの実行中も、データベースを停止せずにバッファ・キャッシュのサイズを変更できます。この操作にはALTER SYSTEM文を使用します。

個々のキャッシュ・コンポーネントのサイズおよび保留中のサイズ変更操作を追跡するには、固定ビューV$BUFFER_POOLを使用します。

複数バッファ・プール

異なるバッファ・プールを持つデータベース・バッファ・キャッシュを構成して、バッファ・キャッシュ内にデータを保持するか、またはデータ・ブロックの使用直後に新しいデータがバッファを使用できるようにするかを指定できます。その後、特定のスキーマ・オブジェクト(表、クラスタ、索引およびパーティション)を適切なバッファ・プールに割り当て、キャッシュからデータ・ブロックをエージ・アウトする方法を制御できます。

- KEEPバッファ・プールでは、スキーマ・オブジェクトのデータ・ブロックがメモリーに保持されます。

- RECYCLEバッファ・プールでは、データ・ブロックが不要になるとすぐにメモリーから除去されます。

- DEFAULTバッファ・プールには、いずれのバッファ・プールにも割り当てられていないスキーマ・オブジェクトのデータ・ブロックと、明示的にDEFAULTプールに割り当てられたスキーマ・オブジェクトのデータ・ブロックが含まれます。

KEEPバッファ・プールとRECYCLEバッファ・プールを構成する初期化パラメータは、DB_KEEP_CACHE_SIZEとDB_RECYCLE_CACHE_SIZEです。

注意:
複数バッファ・プールは、標準ブロック・サイズに対してのみ使用可能です。非標準ブロック・サイズのキャッシュには、1つのDEFAULTプールのみ使用できます。

関連項目:
バッファ・キャッシュのチューニング方法、および複数バッファ・プールの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

共有プール・サイズの指定

SHARED_POOL_SIZE初期化パラメータは、SGAのコンポーネントである共有プールのサイズを指定または調整する動的なパラメータです。Oracle Databaseによって適切なデフォルト値が選択されます。

Oracle Database 10g リリース1より前のリリースでは、割り当てられる共有プール・メモリーの量は、SHARED_POOL_SIZE初期化パラメータの値に、インスタンスの起動時に計算された内部SGAオーバーヘッドの量を加算した値と等しい値でした。内部SGAオーバーヘッドとは、他の複数の初期化パラメータの値に基づいて起動時にOracle Databaseによって割り当てられるメモリーです。このメモリーは、SGAの様々なサーバー・コンポーネントの状態を維持するために使用されます。たとえば、SHARED_POOL_SIZEパラメータが64MBに設定されていて、計算された内部SGAオーバーヘッドの値が12MBである場合、共有プールの実際のサイズは64+12=76MBですが、SHARED_POOL_SIZEパラメータの値は64MBと表示されます。

Oracle Database 10g リリース1以降では、内部SGAオーバーヘッドのサイズは、ユーザー指定のSHARED_POOL_SIZEの値に含まれます。つまり、自動メモリー管理または自動共有メモリー管理を使用していない場合、起動時に割り当てられる共有プール・メモリーの量はSHARED_POOL_SIZE初期化パラメータの値と等しくなり、グラニュル・サイズの倍数に丸められます。したがって、このパラメータには、必要な共有プール・サイズに内部SGAオーバーヘッドを加えた値を設定する必要があります。前述の例の場合、SHARED_POOL_SIZEパラメータが起動時に64MBに設定されているとすると、内部SGAオーバーヘッドの値が変わっていなければ、起動後に使用可能な共有プールの値は、64-12=52MBになります。起動後に共有プール・メモリーとして有効な値を64MB維持するには、SHARED_POOL_SIZEパラメータを64+12=76MBに設定する必要があります。

Oracle Database 10gリリース1よりも前のリリースから移行する場合、Oracle Database 11g移行ユーティリティにより、このパラメータの新しい値が、アップグレード前の環境での内部SGAオーバーヘッド値とこのパラメータの以前の値に基づいて推奨されます。Oracle Database 10g以降では、SGAの内部オーバーヘッド(共有プールの起動オーバーヘッドとも呼ばれます)の正確な値をV$SGAINFOビューから問い合せることができます。また、手動共有メモリー管理モードでは、SHARED_POOL_SIZEのユーザー指定値が内部SGAオーバーヘッドの要件に対応できないほど小さい場合は、Oracle Databaseによって起動時にORA-00371エラーが生成され、SHARED_POOL_SIZEパラメータの推奨値が表示されます。Oracle Database 11gで自動共有メモリー管理を使用すると、共有プールは自動的にチューニングされ、ORA-00371エラーも生成されません。

結果キャッシュと共有プール・サイズ

結果キャッシュのメモリーは共有プールから取得されます。したがって、結果キャッシュの最大サイズを大きくする場合は、共有プールのサイズ設定時にこのサイズを考慮する必要があります。

関連項目:
「結果キャッシュの最大サイズの指定」

ラージ・プール・サイズの指定

LARGE_POOL_SIZE初期化パラメータは、SGAのコンポーネントであるラージ・プールのサイズを指定または調整する動的なパラメータです。ラージ・プールは、SGAのオプションのコンポーネントです。ラージ・プールを作成する場合は、LARGE_POOL_SIZEパラメータを設定する必要があります。ラージ・プールの構成方法は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

Javaプール・サイズの指定

JAVA_POOL_SIZE初期化パラメータは、SGAのコンポーネントであるJavaプールのサイズを指定または調整する動的なパラメータです。Oracle Databaseによって適切なデフォルト値が選択されます。Javaプールの構成方法は、『Oracle Database Java開発者ガイド』を参照してください。

Streamsプール・サイズの指定

STREAMS_POOL_SIZE初期化パラメータは、SGAのコンポーネントであるStreamsプールのサイズを指定または調整する動的なパラメータです。STREAMS_POOL_SIZEが0(ゼロ)に設定されている場合、Oracle Streams製品では、メモリーが必要時にバッファ・キャッシュからStreamsプールに転送されます。詳細は、『Oracle Streamsレプリケーション管理者ガイド』のStreamsプールの説明を参照してください。

結果キャッシュの最大サイズの指定

RESULT_CACHE_MAX_SIZE初期化パラメータは、SGAの結果キャッシュ・コンポーネントの最大サイズを指定する動的なパラメータです。通常、デフォルトの最大サイズは、SGAが使用可能な合計メモリーと使用中のメモリー管理方式に基づいてデータベースによって選択されるため、このパラメータを指定する必要はありません。現在のデフォルト最大サイズを調べるには、RESULT_CACHE_MAX_SIZEパラメータの値を表示します。この最大サイズを変更するには、ALTER SYSTEM文でRESULT_CACHE_MAX_SIZEを設定するか、テキスト初期化パラメータ・ファイルでこのパラメータを指定します。いずれの場合も、値は近似の32Kの倍数に切り上げられます。

インスタンスの起動時にRESULT_CACHE_MAX_SIZEが0(ゼロ)の場合、結果キャッシュは使用禁止です。使用可能にするには、RESULT_CACHE_MAX_SIZEを0(ゼロ)以外の値に設定して(またはテキスト形式の初期化パラメータ・ファイルからこのパラメータを削除してデフォルトの最大サイズを取得して)、データベースを再起動する必要があります。

結果キャッシュが使用禁止の状態でデータベースを起動した後、ALTER SYSTEM文を使用してRESULT_CACHE_MAX_SIZEを0(ゼロ)以外の値に設定し、その後データベースを再起動していない場合、RESULT_CACHE_MAX_SIZEパラメータの値を問い合せると、結果キャッシュが使用禁止状態のままでも0(ゼロ)以外の値が返されます。したがって、RESULT_CACHE_MAX_SIZEの値は、結果キャッシュが使用可能かどうかを判断する最も信頼できる方法ではありません。かわりに、次の問合せを使用できます。

SELECT dbms_result_cache.status() FROM dual;

DBMS_RESULT_CACHE.STATUS()
---------------------------------------------
ENABLED

結果キャッシュのメモリーは共有プールから取得されるため、結果キャッシュの最大サイズを大きくする場合は、共有プールのサイズを大きくすることも考慮する必要があります。

ビューV$RESULT_CACHE_STATISTICSおよびPL/SQLパッケージのプロシージャDBMS_RESULT_CACHE.MEMORY_REPORTでは、結果キャッシュに現在割り当てられているメモリー量の判断に役立つ情報が表示されます。

PL/SQLパッケージのファンクションDBMS_RESULT_CACHE.FLUSHでは、結果キャッシュがクリアされ、すべてのメモリーが共有プールに解放されます。

関連項目:

- 結果キャッシュの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- DBMS_RESULT_CACHEパッケージのプロシージャとファンクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- V$RESULT_CACHE_STATISTICSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- クラスタ・データベースのRESULT_CACHE_MAX_SIZEの設定方法は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

その他のSGA初期化パラメータの指定

いくつかの追加の初期化パラメータを設定して、SGAのメモリー使用方法を制御できます。

物理メモリー

LOCK_SGAパラメータをTRUEに設定すると、SGA全体が物理メモリーにロックされます。このパラメータは自動メモリー管理では使用できません。

SGA開始アドレス

SHARED_MEMORY_ADDRESSパラメータとHI_SHARED_MEMORY_ADDRESSでは、実行時のSGAの開始アドレスが指定されます。これらのパラメータはほとんど使用されません。64ビットのプラットフォームの場合、HI_SHARED_MEMORY_ADDRESSでは、64ビット・アドレスの上位32ビットが指定されます。

拡張バッファ・キャッシュ・メカニズム

USE_INDIRECT_DATA_BUFFERSパラメータは、4GBを超える物理メモリーをサポートする32ビット・プラットフォームで、拡張バッファ・キャッシュ・メカニズムを使用可能にします。この大容量の物理メモリーをサポートしていないプラットフォームでは、このパラメータは無視されます。このパラメータは、自動メモリー管理または自動共有メモリー管理と組み合せて使用することはできません。

関連項目:

- これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- 「自動メモリー管理の使用」

- 「自動共有メモリー管理の使用」

自動PGAメモリー管理の使用

デフォルトで、Oracle Databaseでは、インスタンスPGA専用のメモリーの合計量が自動的かつグローバルに管理されます。この量は、初期化パラメータPGA_AGGREGATE_TARGETを設定することによって制御できます。Oracle Databaseでは、すべてのデータベース・サーバー・プロセスとバックグラウンド・プロセスに割り当てられるPGAメモリーの合計量がこのターゲット値を超えないようにします。

DBCAを使用してデータベースを作成する場合は、合計インスタンスPGAの値を指定できます。その後、DBCAによって、作成されるサーバー・パラメータ・ファイル(SPFILE)に、PGA_AGGREGATE_TARGET初期化パラメータが設定されます。合計インスタンスPGAを指定しない場合は、DBCAによって適切なデフォルト値が選択されます。

CREATE DATABASE SQL文とテキスト形式のパラメータ・ファイルを使用してデータベースを作成する場合は、PGA_AGGREGATE_TARGETの値を指定できます。このパラメータを省略すると、データベースによってデフォルト値が選択されます。

自動PGAメモリー管理を使用すると、すべての専用サーバー・セッションに対するSQL作業領域のサイズが自動で設定され、これらのセッションについてはすべての*_AREA_SIZE初期化パラメータが無視されます。特定の時期に、インスタンス上のアクティブな作業領域で使用可能なPGAメモリーの合計量がパラメータPGA_AGGREGATE_TARGETから自動的に導出されます。この量は、PGA_AGGREGATE_TARGETの値から、他の目的で割り当てられたPGAメモリー(例: セッション・メモリー)を減算した値に設定されます。結果のPGAメモリーは、その特定のメモリー要件に基づいて個々のアクティブな作業領域に割り当てられます。

PGAメモリーの使用統計を提供する動的なパフォーマンス・ビューが用意されています。これらの統計のほとんどは、PGA_AGGREGATE_TARGETが設定されると使用可能になります。

- 作業領域メモリーの割当ておよび使用に関する統計は、次の動的パフォーマンス・ビューで表示できます。

V$SYSSTAT

V$SESSTAT

V$PGASTAT

V$SQL_WORKAREA

V$SQL_WORKAREA_ACTIVE

- V$PROCESSビューの次の3つの列では、Oracle Databaseプロセスによって割り当てられ使用されているPGAメモリーがレポートされます。

PGA_USED_MEM

PGA_ALLOC_MEM

PGA_MAX_MEM

注意:
自動PGAメモリー管理方法は、専用および共有のサーバー・プロセスによって割り当てられた作業領域に適用されます。専用および共有サーバー・モードでのPGAメモリー割当ての詳細は、『Oracle Database概要』を参照してください。

関連項目:

- この項に記載したビューの詳細は、『Oracle Databaseリファレンス』 を参照してください。

- これらのビューの使用方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

手動PGAメモリー管理の使用

Oracle Databaseでは、SQL作業領域を手動でチューニングする手動PGAメモリー管理がサポートされています。

Oracle Database 10gより前のリリースでは、データベース管理者がパラメータSORT_AREA_SIZE、HASH_AREA_SIZE、BITMAP_MERGE_AREA_SIZEおよびCREATE_BITMAP_AREA_SIZEを設定することで、SQL作業領域の最大サイズを制御していました。しかし、最大作業領域サイズは、データ入力サイズとシステム内でアクティブな作業領域の合計数から選択するのが理想であるため、これらのパラメータの設定は困難です。これら2つの要因は、作業領域および時間により大幅に変動します。このため、各種*_AREA_SIZEパラメータを最適な状況でチューニングすることは困難です。

このような理由から、自動PGAメモリー管理を使用可能にしておくことをお薦めします。

SQL作業領域を手動でチューニングする場合は、WORKAREA_SIZE_POLICY初期化パラメータをMANUALに設定する必要があります。

注意:
初期化パラメータWORKAREA_SIZE_POLICYは、セッション・レベルおよびシステム・レベルのパラメータで、設定できる値はMANUALまたはAUTOの2つのみです。デフォルトはAUTOです。PGA_AGGREGATE_TARGETを設定した後、メモリー管理モードを自動と手動の間で切り替えることができます。WORKAREA_SIZE_POLICYがAUTOに設定されている場合、*_AREA_SIZEパラメータの設定は無視されます。

Database Smart Flash Cacheの構成

ここでは、Database Smart Flash Cache(フラッシュ・キャッシュ)について説明します。この項の内容は、次のとおりです。

- フラッシュ・キャッシュを構成する場合

- フラッシュ・キャッシュのサイズの設定

- フラッシュ・キャッシュのメモリーのチューニング

- フラッシュ・キャッシュの初期化パラメータ

- Oracle Real Application Clusters環境のフラッシュ・キャッシュ

関連項目:
フラッシュ・キャッシュについては「メモリー・アーキテクチャの概要」を参照してください。

フラッシュ・キャッシュを構成する場合

次のすべてが該当する場合は、フラッシュ・キャッシュの追加を検討してください。

- データベースがSolarisまたはOracle Linuxオペレーティング・システムで実行されています。フラッシュ・キャッシュは、これらのオペレーティング・システムでのみサポートされます。

- 自動ワークロード・リポジトリ(AWR)レポートまたはSTATSPACKレポートのバッファ・プール・アドバイザセクションには、バッファ・キャッシュのサイズを2倍にすると効果的であることが示されています。

- db file sequential readは上位待機イベントです。

- 手元に予備のCPUがあります。

注意:
フラッシュ・キャッシュを複数のインスタンスで共有することはできません。

フラッシュ・キャッシュのサイズの設定

一般的に、フラッシュ・キャッシュのサイズはバッファ・キャッシュのサイズの2から10倍に設定します。乗数を2未満にすると、効果がありません。自動共有メモリー管理を使用している場合は、フラッシュ・キャッシュをSGA_TARGETのサイズの2から10倍にしてください。この計算に使用するSGA_TARGETのサイズは、フル・サイズではなく、その80%でも十分です。

フラッシュ・キャッシュのメモリーのチューニング

バッファ・キャッシュからフラッシュ・キャッシュにデータベース・ブロックを移動するたびに、そのブロックに関する少量のメタデータがバッファ・キャッシュに保持されます。単一インスタンス・データベースの場合、このメタデータによって、約100バイトが消費されます。Oracle Real Application Clusters(Oracle RAC)データベースの場合は、約200バイト消費されます。このため、フラッシュ・キャッシュを追加するときには、この余分なメモリー要件を考慮する必要があります。

- 手動でメモリーを管理している場合は、フラッシュ・キャッシュに収まるデータベース・ブロックの数に100(Oracle RACの場合は200)を乗じた値とほぼ等しくなるまでバッファ・キャッシュのサイズを増やしてください。

- 自動メモリー管理を使用している場合は、前述のアルゴリズムを使用して、MEMORY_TARGETのサイズを増やしてください。先にMEMORY_MAX_TARGETのサイズを増やすことが必要になる場合があります。

- 自動共有メモリー管理を使用している場合は、SGA_TARGETのサイズを増やしてください。

また、フラッシュ・キャッシュを使用するOracle RACデータベースでは、グローバル・キャッシュ・サービス(GCS)リソース用に共有プールに追加メモリーを割り当てる必要があります。各GCSリソースは、共有プールに約208バイト必要です。

注意:
バッファ・キャッシュ・サイズを増やさなくても、フラッシュ・キャッシュを追加できます。この場合、バッファ・キャッシュの有効サイズが減少します。ただし、この損失分はサイズの大きいフラッシュ・キャッシュを使用することによって相殺できます。

関連項目:

- 「メモリー管理について」

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

フラッシュ・キャッシュの初期化パラメータ

表6-4では、フラッシュ・キャッシュの構成に使用する初期化パラメータについて説明しています。

表6-4 フラッシュ・キャッシュの初期化パラメータ

パラメータ

説明

db_flash_cache_file

フラッシュ・キャッシュが含まれるファイルのパスおよびファイル名を、オペレーティング・システムのファイル・システムまたはOracle Automatic Storage Managementディスク・グループ内で指定します。ファイルが存在しない場合は、起動時にデータベースによって作成されます。ファイルはフラッシュ・ディスク装置に常駐する必要があります。フラッシュ・キャッシュをディスク・ドライブ(スピンドル)に構成すると、パフォーマンスが低下する可能性があります。

次に、db_flash_cache_fileの有効な値の例を示します。

/dev/fioa1

db_flash_cache_size

フラッシュ・キャッシュのサイズを指定します。フラッシュ・ディスク・デバイスの物理メモリー・サイズ以下である必要があります。nGというように、ギガバイト(GB)数で示します。たとえば、16GBのフラッシュ・キャッシュを指定するには、db_flash_cache_sizeを16Gに設定します。

フラッシュ・キャッシュを無効にするには、ALTER SYSTEMを使用してdb_flash_cache_sizeを0(ゼロ)に設定します。また、ALTER SYSTEMを使用してフラッシュ・キャッシュを元のサイズに戻して再度フラッシュ・キャッシュを有効にすることもできます。ただし、フラッシュ・キャッシュのサイズを動的に変更することはできません。

Oracle Real Application Clusters環境のフラッシュ・キャッシュ

フラッシュ・キャッシュは、Oracle Real Application Clusters環境のすべてのインスタンスに構成するか、どのインスタンスにも構成しないようにする必要があります。

メモリー管理の参考情報

ここでは、メモリー管理に関する次の参考情報を提供します。

- 自動メモリー管理をサポートするプラットフォーム

- メモリー管理のデータ・ディクショナリ・ビュー

自動メモリー管理をサポートするプラットフォーム

次のプラットフォームでは自動メモリー管理がサポートされます。自動メモリー管理は、SGAおよびPGAのサイズを自動的にチューニングするOracle Databaseの機能で、パフォーマンスを最適化するために、要求に応じてメモリーが領域間で再配分されます。

- Linux

- Solaris

- Windows

- HP-UX

- AIX

メモリー管理のデータ・ディクショナリ・ビュー

次の動的パフォーマンス・ビューには、メモリー管理に関する情報が表示されます。

ビュー

説明

V$SGA

システム・グローバル領域(SGA)に関する要約情報が表示されます。

V$SGAINFO

様々なSGAコンポーネントのサイズ、グラニュル・サイズおよび空きメモリーなど、SGAに関するサイズ情報が表示されます。

V$SGASTAT

共有プール、ラージ・プール、JavaプールおよびStreamsプール内に割り当てられているメモリーの量に関する詳細情報が表示されます。

V$PGASTAT

PGAメモリー使用統計と、自動PGAメモリー・マネージャが使用可能な場合(PGA_AGGREGATE_TARGETが設定されている場合)はその統計が表示されます。V$PGASTATでの累積値は、インスタンスの起動以降に蓄積されます。

V$MEMORY_DYNAMIC_COMPONENTS

自動調整された静的なすべてのメモリー・コンポーネントの現在のサイズに関する情報と、各コンポーネントで発生した最後の操作(例: 拡大または縮小)が表示されます。

V$SGA_DYNAMIC_COMPONENTS

すべてのSGAコンポーネントの現在のサイズと各コンポーネントの最後の操作が表示されます。

V$SGA_DYNAMIC_FREE_MEMORY

将来の動的なSGAサイズ変更操作に使用可能なSGAメモリーの容量に関する情報が表示されます。

V$MEMORY_CURRENT_RESIZE_OPS

現在進行中のサイズ変更操作に関する情報が表示されます。サイズ変更の操作は、SGA、インスタンスPGAまたは動的なSGAコンポーネントの拡大または縮小です。

V$SGA_CURRENT_RESIZE_OPS

現在進行中の動的SGAコンポーネントのサイズ変更操作に関する情報が表示されます。

V$MEMORY_RESIZE_OPS

SGA_TARGETおよびPGA_AGGREGATE_TARGETに対する自動拡張および縮小操作も含めて、最後に完了した800件のメモリー・コンポーネント・サイズ変更操作に関する情報が表示されます。

V$SGA_RESIZE_OPS

最後に完了した800件のSGAコンポーネント・サイズ変更操作に関する情報が表示されます。

V$MEMORY_TARGET_ADVICE

自動メモリー管理を使用可能にした場合、MEMORY_TARGETのチューニングに役立つ情報が表示されます。

V$SGA_TARGET_ADVICE

SGA_TARGETのチューニングに役立つ情報が表示されます。

V$PGA_TARGET_ADVICE

PGA_AGGREGATE_TARGETのチューニングに役立つ情報が表示されます。

関連項目:
メモリー管理ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

7 ユーザーの管理とデータベースのセキュリティ保護

この章の内容は、次のとおりです。

- データベースに対するセキュリティ・ポリシー設定の重要性

- ユーザーとリソースの管理

- ユーザー権限とロールの管理

- データベース・アクティビティの監査

- 事前定義のユーザー・アカウント

データベースに対するセキュリティ・ポリシー設定の重要性

すべてのデータベースに対してセキュリティ・ポリシーを設定することが重要です。セキュリティ・ポリシーによって、不慮または不正によるデータの破壊またはデータベース・インフラストラクチャの損傷からデータベースを保護する方法が設定されます。

各データベースに、データベースのセキュリティ・ポリシーを実装および維持するセキュリティ管理者と呼ばれる管理者を設定します。データベース・システムが小さい場合は、データベース管理者がセキュリティ管理者を担当することもできます。ただし、データベース・システムが大きい場合は、指定したユーザーまたはユーザーのグループが単独でセキュリティ管理者として担当することもあります。

データベースに対するセキュリティ・ポリシー設定の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

ユーザーとリソースの管理

データベースに接続するには、各ユーザーが、データベースに事前に定義された有効なユーザー名を指定する必要があります。ユーザーにはアカウントが設定され、ユーザーに関する情報がデータベース・ディクショナリに格納されている必要があります。

データベース・ユーザー(アカウント)を作成するときは、ユーザーに関する次の属性を指定します。

- ユーザー名

- 認証方式

- デフォルト表領域

- 一時表領域

- その他の表領域および割当て制限

- ユーザー・プロファイル

ユーザーの作成および管理方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

ユーザー権限とロールの管理

権限とロールは、ユーザーのデータへのアクセスおよび実行可能なSQL文のタイプを制御するために使用します。次の表は、権限とロールの、3つのタイプを示しています。

タイプ

説明

システム権限

通常は管理者によってのみ付与される、システムが定義する権限。これらの権限は、ユーザーによる特定のデータベース操作の実行を許可します。

オブジェクト権限

システムによって定義された権限。特定のオブジェクトへのアクセスを制御します。

ロール

権限や他のロールの集合。システムによって定義されたロールも存在しますが、大部分は管理者によって作成されます。権限や他のロールをグループ化するロールによって、複数の権限またはロールをユーザーに容易に付与できます。

権限とロールを付与する権限を所有しているユーザーは、権限とロールを他のユーザーに付与できます。権限とロールの付与は、管理者レベルで開始します。データベースの作成時に、管理ユーザーSYSが作成され、システム権限およびOracle Databaseで事前定義されたロールがすべて付与されます。次に、ユーザーSYSは、権限とロールを他のユーザーに付与し、そのユーザーが別のユーザーに対して特定の権限を付与できる権限を与えることもできます。

ユーザーの権限とロールの管理方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

データベース・アクティビティの監査

選択したユーザーのデータベース操作は、管理者が実行した操作も含めて、監視および記録できます。データベース監査を実装する理由はいくつかあります。データベース監査の基本情報と方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

事前定義のユーザー・アカウント

Oracle Databaseには、いくつかの事前定義のユーザー・アカウントが用意されています。次の3種類の事前定義のアカウントがあります。

- 管理アカウント(SYS、SYSTEM、SYSMANおよびDBSNMP)
SYSおよびSYSTEMの詳細は、「DBAのセキュリティと権限の概要」を参照してください。SYSMANは、Oracle Enterprise Managerの管理タスクの実行に使用されます。DBSNMPアカウントは、データベースを監視および管理するためにEnterprise Managerの管理エージェントで使用されます。これらのアカウントは削除することができません。

- サンプル・スキーマのアカウント
これらのアカウントは、Oracle Databaseのマニュアルや説明書の例で使用されます。たとえば、HR、SH、OEなどがあります。これらのアカウントは、使用する前にロックを解除して、パスワードを再設定する必要があります。

- 内部アカウント
個々のOracle Database機能またはコンポーネントが独自のスキーマを持てるよう、これらのアカウントが作成されます。内部のアカウントを削除しないでください。また内部のアカウントでログインしないでください。

関連項目:
事前定義のアカウントの表は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

8 データベースの動作の監視

データベースの動作を定期的に監視することは重要です。監視することによって、気付いていないエラーの情報を取得できるのみでなく、データベースの正常な動作について理解を深めることもできます。正常な動作を理解しておくことで、なんらかの誤りがある場合に状況を容易に認識できるようになります。

この章の内容は、次のとおりです。

- エラーおよびアラートの監視

- パフォーマンスの監視

エラーおよびアラートの監視

次の項では、データベースのエラーおよびアラートを監視する方法について説明します。内容は次のとおりです。

- トレース・ファイルおよびアラート・ログを使用したエラーの監視

- サーバー生成アラートを使用したデータベースの動作の監視

注意:
データベースのエラーおよびアラートを監視する最も簡単で最適な方法は、Enterprise Managerのデータベース・ホームページを使用することです。この項で説明するのは、データ・ディクショナリ・ビュー、PL/SQLパッケージおよびその他のコマンドライン機能を使用する別の監視方法です。

トレース・ファイルおよびアラート・ログを使用したエラーの監視

各サーバー・プロセスとバックグラウンド・プロセスは、対応するトレース・ファイルに情報を書き込むことができます。プロセスによって内部エラーが検出されると、エラー情報が関連トレース・ファイルにダンプされます。トレース・ファイルに書き込まれる情報の一部はデータベース管理者用であり、その他の情報はOracleサポート・サービス用です。また、トレース・ファイルの情報は、アプリケーションとインスタンスのチューニングにも使用されます。

注意:
クリティカル・エラーの場合は、自動診断リポジトリにインシデントおよびインシデント・ダンプも作成されます。詳細は、第9章「診断データの管理」を参照してください。

アラート・ログはメッセージとエラーの履歴ログであり、次の項目が含まれます。

- 発生したすべての内部エラー(ORA-00600)、ブロック破損エラー(ORA-01578)およびデッドロック・エラー(ORA-00060)

- たとえば、CREATE/ALTER/DROP文、STARTUP/SHUTDOWN文、ARCHIVELOG文などの管理操作

- 共有サーバーとディスパッチャ・プロセスの機能に関係するメッセージとエラー

- マテリアライズド・ビューの自動リフレッシュ中に発生したエラー

- データベースとインスタンスの起動時点でデフォルト以外の値があったすべての初期化パラメータの値

Oracle Databaseは、オペレータのコンソール上に情報を表示するかわりに(一部のシステムではコンソール上に情報を表示する)、アラート・ログを使用して、これらの操作を記録します。操作が成功すると、タイムスタンプとともに「completed」というメッセージがアラート・ログに書き込まれます。

アラート・ログは、XML形式ファイルとテキスト形式ファイルの両方として維持されます。いずれの形式のアラート・ログもテキスト・エディタで表示でき、XML形式のファイルはADRCIユーティリティを使用してXMLタグが削除された状態で表示できます。

バックグラウンド・プロセスでエラーが発生していないかどうかを確認するために、インスタンスのアラート・ログとトレース・ファイルを定期的にチェックします。たとえば、ログ・ライター・プロセス(LGWR)でログ・グループのメンバーに書き込むことができないと、LGWRトレース・ファイルとアラート・ログに、問題の内容を示すエラー・メッセージが書き込まれます。このようなエラー・メッセージが見つかった場合は、メディアまたはI/Oの問題が発生しているため、ただちに解決する必要があります。

Oracle Databaseは、他の重要な統計に加えて、初期化パラメータの値もアラート・ログに書き込みます。

バックグラウンドおよびサーバー・プロセスのアラート・ログおよびすべてのトレース・ファイルは自動診断リポジトリに書き込まれ、これらの場所はDIAGNOSTIC_DEST初期化パラメータで指定されます。トレース・ファイル名はオペレーティング・システム固有ですが、通常、各ファイルにはそれを書き込むLGWRやRECOなどのプロセスの名前が含まれます。

関連項目:

- 自動診断リポジトリの詳細は、第9章「診断データの管理」を参照してください。

- アラート・ログの詳細は、「アラート・ログ」を参照してください。

- 「アラート・ログの表示」

- ADRCIユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

- トレース・ファイルの名前の詳細は、オペレーティング・システム固有のOracleマニュアルを参照してください。

トレース・ファイル・サイズの制御

すべてのトレース・ファイル(アラート・ログを除く)の最大サイズは、ファイルを指定のオペレーティング・システム・ブロック数に制限する初期化パラメータMAX_DUMP_FILE_SIZEを使用して制御できます。アラート・ログのサイズを制御するには、不要になったファイルを手動で削除する必要があります。削除しないと、ファイルが引き続き追加されます。

インスタンスの実行中にアラート・ログを削除しても問題はありませんが、削除する前にアラート・ログのアーカイブ・コピーを作成してください。このアーカイブ・コピーは、インスタンス履歴の調査を必要とする問題が発生したときに役立ちます。

Oracle Databaseがトレース・ファイルに書き込む時期の制御

バックグラウンド・プロセスは適宜、トレース・ファイルに情報を書き込みます。ARCnバックグラウンド・プロセスの場合は、生成されるトレース情報の量とタイプを初期化パラメータで制御できます。この動作については、「ARCHIVELOGプロセスによって生成されるトレース出力の制御」を参照してください。他のバックグラウンド・プロセスには、このような柔軟性はありません。

クリティカル・エラーが発生したときは必ず、サーバー・プロセスのためにトレース・ファイルに情報が書き込まれます。また、初期化パラメータSQL_TRACE = TRUEを設定すると、SQLトレース機能が有効になり、インスタンスに対するすべてのSQL文の処理についてパフォーマンス統計が生成され、自動診断リポジトリに書き込まれます。

必要に応じて、サーバー・プロセスに対するトレース・ファイルの生成を要求できます。SQL文ALTER SESSION SET SQL_TRACEを使用すると、SQL_TRACE初期化パラメータの現行の値にかかわらず、対応するサーバー・プロセスのために各セッションのトレース・ロギングを使用可能または使用禁止にできます。次の例は、特定のセッションに対してSQLトレース機能を使用可能にします。

ALTER SESSION SET SQL_TRACE TRUE;

セッションのSQLトレースを制御するには、DBMS_SESSIONまたはDBMS_MONITORパッケージを使用します。

注意:
サーバー・プロセスのSQLトレース機能は、著しいシステム・オーバーヘッドを引き起こし、パフォーマンスに重大な影響を及ぼします。このため、統計を収集するときにのみ、この機能を使用可能にしてください。

関連項目:

- クリティカル・エラー(インシデントと呼ばれます)のデータベースによる処理方法の詳細は、第9章「診断データの管理」を参照してください。

共有サーバー・セッション用トレース・ファイルの読込み

共有サーバーが使用可能な場合、ディスパッチャを使用している各セッションは共有サーバー・プロセスにルーティングされ、セッションのトレースが有効になっている場合(またはエラーが発生した場合)のみ、トレース情報がサーバー・トレース・ファイルに書き込まれます。そのため、ディスパッチャを使用して接続していた特定のセッションのトレースを追跡する場合、複数の共有サーバー・トレース・ファイルを調べる必要がある場合があります。これを容易にするため、Oracleではコマンドライン・ユーティリティ・プログラムtrcsessを用意しており、これを使用すると特定のユーザー・セッションに関連のあるすべてのトレース情報が1箇所にまとめられ、情報が時間の順に並べられます。

関連項目:
SQLトレース機能の使用方法、およびTKPROFとtrcsessを使用して、生成されたトレース・ファイルを解析する方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

サーバー生成アラートを使用したデータベースの動作の監視

サーバー生成アラートとは、切迫した問題に関するOracle Databaseサーバーからの通知です。この通知には、問題を修正するための提案が含まれていることがあります。問題の状況が解決した場合も通知が発行されます。

アラートは、問題が発生した場合や次のようなメトリックに予期した値に対してデータが一致しない場合に自動的に生成されます。

- 秒当たりの物理読込み数

- 秒当たりのユーザー・コミット数

- SQLサービス応答時間

サーバー生成アラートは、しきい値レベルに基づいて、または単純にイベントの発生に基づいて生成されるように設定できます。しきい値ベースのアラートは、しきい値の警告およびクリティカル・レベルの両方でトリガーできます。これらのレベルの値には、顧客定義または内部値のいずれをも使用でき、一部のアラートには、必要に応じて変更可能な、デフォルトのしきい値レベルが設定されています。たとえばデフォルトで、サーバー生成アラートは領域使用状況について、領域の使用率が85%の警告レベルまたは97%のクリティカルしきい値レベルを超過すると生成されます。しきい値レベルに基づかないアラートには、次のようなものがあります。

- スナップショットが古すぎます

- 再開可能セッションが一時停止されました

- Recovery Area Space Usage

アラート・メッセージは、ユーザーSYSが所有する事前定義された永続キューALERT_QUEに送信されます。Oracle Enterprise Managerはこのキューを読込み、未処理のサーバー・アラートの通知を送信したり、場合によっては問題を修正するためのアクションを推奨します。アラートはEnterprise Managerのデータベース・ホームページに表示され、選択した管理者に電子メールまたはページャ通知を送信するように構成できます。アラートをアラート・キューに書き込めない場合、アラートに関するメッセージがOracle Databaseのアラート・ログに書き込まれます。

バックグラウンド・プロセスは、自動ワークロード・リポジトリにデータを定期的にフラッシュして、メトリック値の履歴を取得します。アラート履歴表とALERT_QUEは、システムによって一定の間隔で自動的にパージされます。

サーバー生成アラートのしきい値の設定と取得

サーバー・アラート・メトリックのしきい値設定は、DBMS_SERVER_ALERT PL/SQLパッケージのSET_THRESHOLDおよびGET_THRESHOLDプロシージャを使用して表示および変更できます。次の各項では、これらのプロシージャの使用例を示します。

- しきい値レベルの設定

- しきい値情報の取得

注意:
しきい値を設定および取得する最も便利な方法は、Enterprise Managerのグラフィカル・インタフェースを使用することです。詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

関連項目:
DBMS_SERVER_ALERTパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

しきい値レベルの設定

次の例は、SET_THRESHOLDプロシージャを使用して、インスタンスに対する各ユーザー・コールのCPU時間にしきい値を設定する方法を示しています。

DBMS_SERVER_ALERT.SET_THRESHOLD(
DBMS_SERVER_ALERT.CPU_TIME_PER_CALL, DBMS_SERVER_ALERT.OPERATOR_GE, '8000',
DBMS_SERVER_ALERT.OPERATOR_GE, '10000', 1, 2, 'inst1',
DBMS_SERVER_ALERT.OBJECT_TYPE_SERVICE, 'main.regress.rdbms.dev.us.example.com');

この例では、各ユーザー・コールのCPU時間が8,000マイクロ秒を超えた場合は警告アラートが、各ユーザー・コールのCPU時間が10,000マイクロ秒を超えた場合はクリティカル・アラートが発行されます。次の引数が指定されています。

- CPU_TIME_PER_CALLは、メトリック識別子を指定しています。サポートされるメトリックのリストは、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 観察期間は1分に設定しています。条件がしきい値を逸脱し、ここに指定した期間(分単位)にわたって逸脱状態が継続すると、アラートが発行されます。

- 連続発生回数は2回に設定しています。ここに指定した回数分メトリック値がしきい値に違反すると、アラートが生成されます。

- インスタンスの名前はinst1に設定しています。

- 定数DBMS_ALERT.OBJECT_TYPE_SERVICEは、しきい値が設定されるオブジェクト型を指定します。この例では、サービス名はmain.regress.rdbms.dev.us.example.comです。

しきい値情報の取得

しきい値を取得するには、GET_THRESHOLDプロシージャを使用します。次に例を示します。

DECLARE
warning_operator         BINARY_INTEGER;
warning_value            VARCHAR2(60);
critical_operator        BINARY_INTEGER;
critical_value           VARCHAR2(60);
observation_period       BINARY_INTEGER;
consecutive_occurrences  BINARY_INTEGER;
BEGIN
DBMS_SERVER_ALERT.GET_THRESHOLD(
DBMS_SERVER_ALERT.CPU_TIME_PER_CALL, warning_operator, warning_value,
critical_operator, critical_value, observation_period,
consecutive_occurrences, 'inst1',
DBMS_SERVER_ALERT.OBJECT_TYPE_SERVICE, 'main.regress.rdbms.dev.us.example.com');
DBMS_OUTPUT.PUT_LINE('Warning operator:       ' || warning_operator);
DBMS_OUTPUT.PUT_LINE('Warning value:          ' || warning_value);
DBMS_OUTPUT.PUT_LINE('Critical operator:      ' || critical_operator);
DBMS_OUTPUT.PUT_LINE('Critical value:         ' || critical_value);
DBMS_OUTPUT.PUT_LINE('Observation_period:     ' || observation_period);
DBMS_OUTPUT.PUT_LINE('Consecutive occurrences:' || consecutive_occurrences);
END;
/

DBA_THRESHOLDSビューを使用して、特定のしきい値設定をチェックすることもできます。次に例を示します。

SELECT metrics_name, warning_value, critical_value, consecutive_occurrences
FROM DBA_THRESHOLDS
WHERE metrics_name LIKE '%CPU Time%';

サーバー生成アラートの表示

サーバー生成アラートを表示する最も簡単な方法は、Enterprise Managerのデータベース・ホームページにアクセスすることです。次の説明では、これらのアラートを表示する別の方法を示します。

Enterprise Manager以外の独自のツールを使用してアラートを表示する場合は、ALERT_QUEをサブスクライブして、ALERT_QUEを読み取り、アラートにしきい値レベルを設定した後にアラート通知を表示する必要があります。エージェントを作成して、ALERT_QUEにエージェントをサブスクライブするには、DBMS_AQADMパッケージのCREATE_AQ_AGENTおよびADD_SUBSCRIBERプロシージャを使用します。

保護されたALERT_QUEのキューで待機しているメッセージにアクセスできるのは、サブスクライブしているエージェントに関連付けられたユーザーのみであるため、データベース・ユーザーをサブスクライブしているエージェントに関連付ける必要があります。また、そのユーザーにエンキュー権限を付与する必要があります。DBMS_AQADMパッケージのENABLE_DB_ACCESSおよびGRANT_QUEUE_PRIVILEGEプロシージャを使用します。

必要な場合は、DBMS_AQ.REGISTERプロシージャに登録して、アラートがALERT_QUEにエンキューされたときに非同期通知を受信できます。通知は、電子メール、HTTPポストまたはPL/SQLプロシージャの形式にできます。

アラート・メッセージの読込みには、DBMS_AQ.DEQUEUEプロシージャまたはOCIAQDeqコールを使用できます。メッセージをデキューした後、DBMS_SERVER_ALERT.EXPAND_MESSAGEプロシージャを使用して、メッセージのテキストをオープンします。

関連項目:
DBMS_AQパッケージとDBMS_AQADMパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

サーバー生成アラートのデータ・ディクショナリ・ビュー

次のデータ・ディクショナリ・ビューは、サーバー生成アラートに関する情報を提供します。

ビュー

説明

DBA_THRESHOLDS

インスタンスに定義されているしきい値設定をリストします。

DBA_OUTSTANDING_ALERTS

データベースで未処理のアラートを示します。

DBA_ALERT_HISTORY

消去されたアラートの履歴をリストします。

V$ALERT_TYPES

各アラートのグループやタイプなどの情報を提供します。

V$METRICNAME

メトリックの名前、識別子およびシステム・メトリックに関する他の情報が含まれています。

V$METRIC

システム・レベルのメトリック値が含まれています。

V$METRIC_HISTORY

システム・レベルのメトリック値の履歴が含まれています。

関連項目:
静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

パフォーマンスの監視

データベース・パフォーマンスの監視の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。ここでは、このガイドに記載されていない詳細を含む追加の内容について説明します。

- ロックの監視

- 待機イベントの監視

- パフォーマンス監視のデータ・ディクショナリ・ビュー

ロックの監視

ロック は、同じリソースにアクセスしている複数のトランザクション間で破壊的な相互作用が起きないようにするメカニズムです。リソースは、表や行などのユーザー・オブジェクト、またはメモリー内の共有データ構造やデータ・ディクショナリ行など、ユーザーに対して表示されないシステム・オブジェクトの場合があります。SQL文の実行中にOracle Databaseが必要なロックを自動的に取得および管理するため、ユーザーが特に意識する必要はありません。ただし、手動でデータをロックすることも可能です。

互いにロックしたデータを2人以上のユーザーが待機している場合は、デッドロックが発生する可能性があります。デッドロックによって、一部のトランザクションが続行できなくなります。Oracle Databaseは、デッドロック状況を自動的に検出し、そのデッドロックに関係している文の1つをロールバックしてデッドロック状況を解決し、競合している行ロックの一方を解放します。

Oracle Databaseは、デッドロックを回避するように設計されているため、デッドロックは頻繁には発生しません。最も多いデッドロックは、トランザクションがデータベースのデフォルトのロックを明示的に無視する場合です。デッドロックはデータベースのパフォーマンスに影響を与える可能性があるため、ロックを監視できるスクリプトとビューが用意されています。

utllockt.sqlスクリプトは、ロックを待機しているシステム上のセッションとそのロックをツリー形式で表示します。このスクリプト・ファイルの位置は、オペレーティング・システムによって異なります。

第2のスクリプトcatblock.sqlはutllockt.sqlに必要なロック・ビューを作成するスクリプトであるため、utllockt.sqlを実行する前に実行する必要があります。

関連項目:

- 「パフォーマンス監視のデータ・ディクショナリ・ビュー」

- ロックの詳細は、『Oracle Database概要』を参照してください。

待機イベントの監視

待機イベントとは、イベントの完了を待機してから処理を続行する必要があることを示す統計で、サーバー・プロセスによって増分されます。セッションは、入力の待機、オペレーティング・システムによるディスクへの書込みなどのサービス完了の待機、ロックまたはラッチの待機など、様々な理由で待機することがあります。

セッションがリソースを待機している場合、そのセッションでは効率的な作業が実行されていません。待機の多くはソースに関係しています。待機イベントのデータによって、ラッチの競合、バッファの競合、I/Oの競合など、パフォーマンスに影響を与える可能性がある様々な問題の兆候が明らかになります。

このために、待機イベントの統計を表示するビューが用意されています。これらのビューの説明およびインスタンスをチューニングする際のビューの役割については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

パフォーマンス監視データ・ディクショナリ・ビュー

ここでは、Oracle Databaseインスタンスの監視に使用できるいくつかのデータ・ディクショナリ・ビューについて説明します。これらのビューは一般的なものです。プロセス固有の他のビューについては、そのプロセスに関する項を参照してください。

ビュー

説明

V$LOCK

現在Oracle Databaseによって保持されているロックと、未処理のロック要求またはラッチ要求が表示されます。

DBA_BLOCKERS

別のセッションが待機しているオブジェクトのロックを保持しているセッションが表示されます。

DBA_WAITERS

ロックされているオブジェクトを待機しているセッションが表示されます。

DBA_DDL_LOCKS

データベース内のすべてのDDLロックおよびDDLロックに対する未処理の要求すべてが表示されます。

DBA_DML_LOCKS

データベース内のすべてのDMLロックおよびDMLロックに対する未処理の要求すべてが表示されます。

DBA_LOCK

データベース内のすべてのロックまたはラッチ、およびロックまたはラッチに対する未処理の要求すべてが表示されます。

DBA_LOCK_INTERNAL

保持しているロックまたはラッチごとに1行、ロックまたはラッチの未処理要求ごとに1行の情報が表示されます。

V$LOCKED_OBJECT

システム上のすべてのトランザクションが獲得したすべてのロックがリストされます。

V$SESSION_WAIT

アクティブ・セッションが待機しているリソースまたはイベントが表示されます。

V$SYSSTAT

システム統計情報が含まれています。

V$RESOURCE_LIMIT

一部のシステム・リソースについて、現行および最大のグローバル・リソース使用率が表示されます。

V$SQLAREA

共有SQL領域に関する統計情報が、SQL文字列ごとに1行ずつ含まれています。また、メモリー内にあり、解析済で、実行準備のできているSQL文に関する統計情報も提供します。

V$LATCH

非親ラッチの統計情報と、親ラッチのサマリー統計情報が含まれています。

関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

9 診断データの管理

リリース11g以降のOracle Databaseは、診断データを収集して管理するための高度な障害診断インフラストラクチャを備えています。診断データには、以前のリリースにも含まれていたトレース・ファイル、ダンプおよびコア・ファイルに加えて、顧客やOracleサポート・サービスが問題を迅速かつ効率的に識別、調査、追跡、解決できる新しいタイプの診断データが含まれています。

この章の内容は、次のとおりです。

- Oracle Databaseの障害診断インフラストラクチャの概要

- 問題の調査、レポートおよび解決

- Enterprise Managerサポート・ワークベンチを使用した問題の表示

- ユーザー報告の問題の作成

- アラート・ログの表示

- トレース・ファイルの検索

- 状態モニターを使用したヘルス・チェックの実行

- SQL修復アドバイザを使用したSQLエラーの修復

- データ・リカバリ・アドバイザを使用したデータ破損の修復

- カスタム・インシデント・パッケージの作成、編集およびアップロード

Oracle Databaseの障害診断インフラストラクチャの概要

ここでは、Oracle Databaseの障害診断インフラストラクチャに関するバックグラウンド情報を説明します。内容は次のとおりです。

- 障害診断インフラストラクチャの概要

- インシデントおよび問題の概要

- 障害診断インフラストラクチャのコンポーネント

- 自動診断リポジトリの構造、内容および場所

障害診断インフラストラクチャの概要

障害診断インフラストラクチャは、問題の防止、検出、診断および解決に役立ちます。特に対象とする問題はクリティカル・エラーで、これには、コードの不具合、メタデータの破損、顧客データの破損によって生じるエラーなどがあります。

クリティカル・エラーが発生すると、そのエラーにはインシデント番号が割り当てられ、エラーの診断データ(トレース・ファイルなど)が即座に取得され、その番号でタグ付けされます。このデータは、自動診断リポジトリ(ADR) (データベースの外部のファイルベースのリポジトリ)に格納され、後からインシデント番号によって取得して分析できます。

障害診断インフラストラクチャの目的は次のとおりです。

- 初期障害の診断

- 問題の防止

- 問題が検出された後の損害および中断の抑制

- 問題の診断時間の短縮

- 問題の解決時間の短縮

- 顧客とOracleサポートのやり取りの簡略化

これらの目的を達成するための主要なテクノロジは、次のとおりです。

- 初期障害発生時の診断データの自動取得: クリティカル・エラーの場合は、初期障害時にエラー情報を取得することによって、問題の早期解決と停止時間の短縮の可能性が飛躍的に増大します。常時機能しているメモリーベースのトレース・システムは、多くのデータベース・コンポーネントから診断データを事前に収集するため、問題の根本原因を特定するのに役立ちます。このような事前の診断データは、飛行機の「ブラック・ボックス」フライト・レコーダで収集されるデータに類似しています。問題が検出されると、アラートが生成されて、障害診断インフラストラクチャがアクティブになり、診断データが取得されて格納されます。診断データは、データベースの外部にあるリポジトリに格納され(したがって、データベースが停止した場合でもデータを使用できます)、コマンドライン・ユーティリティおよびEnterprise Managerを使用して簡単にアクセスできます。

- 標準化されたトレース形式: すべてのデータベース・コンポーネント間でトレース形式を標準化することによって、DBAおよびOracleサポート・サービス担当者は単一のツール・セットを使用して問題を分析できます。問題の診断はさらに容易となり、停止時間は短縮されます。

- ヘルス・チェック: クリティカル・エラーが検出されると、障害診断インフラストラクチャでは1つ以上のヘルス・チェックが実行され、クリティカル・エラーの詳細な分析が実行されます。ヘルス・チェックの結果は、エラーについて収集された他の診断データに追加されます。各ヘルス・チェックでは、データ・ブロックの破損、UNDOおよびREDOの破損、データ・ディクショナリの破損などが検出されます。DBAは、定期的にまたは必要に応じてこれらのヘルス・チェックを手動で起動できます。

- インシデント・パッケージ化サービス(IPS)およびインシデント・パッケージ: IPSを使用すると、クリティカル・エラーに関する診断データ(トレース、ダンプ、ヘルス・チェック・レポートなど)を自動的かつ容易に収集し、それらのデータをzipファイルにパッケージ化してOracleサポートに転送できます。クリティカル・エラーに関するすべての診断データは、そのエラーのインシデント番号でタグ付けされるため、分析に必要なファイルを判別するためにトレース・ファイルやその他のファイルを検索する必要はなく、インシデント・パッケージング・サービスにより必要なファイルが自動的に特定され、zipファイルに追加されます。zipファイルを作成する前に、IPSはまず、インシデント・パッケージという中間論理構造(パッケージ)に診断データを収集します。パッケージは自動診断リポジトリに格納されます。必要に応じて、この中間論理構造にアクセスして、その内容を表示および修正したり、詳細な診断データをいつでも追加または削除でき、さらに準備ができたらパッケージからzipファイルを作成できます。これらの手順が完了すれば、Oracleサポートにアップロードするzipファイルの準備は完了です。

- データ・リカバリ・アドバイザ: データ・リカバリ・アドバイザはデータベースのヘルス・チェックおよびRMANに統合され、データ破損の問題の表示、各問題の程度の評価(クリティカル、高優先度、低優先度)、問題の影響の説明、修復オプションの推奨、顧客が選択したオプションの実行可能性チェック、および修復プロセスの自動化を実行します。

- SQLテスト・ケース・ビルダー: 多くのSQL関連の問題では、再現可能なテスト・ケースの取得が、問題の迅速な解決にとって重要な要因となります。問題とそれが発生した環境に関する可能なかぎりの情報を収集することは困難で時間がかかる場合がありますが、SQLテスト・ケース・ビルダーは、この収集作業を自動化します。迅速に収集された情報をOracleサポート・サービスにアップロードすると、サポート担当者は問題を簡単かつ正確に再現できます。

関連項目:

- SQLテスト・ケース・ビルダーの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

インシデントおよび問題の概要

クリティカル・エラーの診断と解決を容易にするために、障害診断インフラストラクチャには、問題とインシデントというOracle Databaseの概念が導入されています。

問題とは、データベース・インスタンス、Oracle Automatic Storage Management(Oracle ASM)インスタンス、またはその他のOracle製品やコンポーネントにおけるクリティカル・エラーです。クリティカル・エラーには、内部エラー(ORA-00600など)やその他の深刻なエラー(ORA-07445(オペレーティング・システム例外)またはORA-04031(共有プールのメモリー不足))が含まれます。問題はADRで追跡されます。各問題には、問題を説明する文字列である問題キーがあります。これには、エラー・コード(ORA 600など)、場合によってはさらに1つ以上のエラー・パラメータが含まれます。

インシデントとは、問題の1回の発生です。問題(クリティカル・エラー)が複数回発生すると、インシデントはそれぞれの発生分に対して作成されます。インシデントには日時が記録され、自動診断リポジトリ(ADR)で追跡されます。各インシデントは、ADR内で一意の数値であるインシデントIDによって識別されます。インシデントが発生すると、データベースでは次の処理が実行されます。

- アラート・ログにエントリを作成します。

- Oracle Enterprise Manager (Enterprise Manager)にインシデント・アラートを送信します。

- インシデントに関する初期障害診断データをダンプ・ファイルの形式(インシデント・ダンプ)で収集します。

- インシデント・ダンプをインシデントIDにタグ付けします。

- そのインシデント用に作成されたADRサブディレクトリにインシデント・ダンプを格納します。

クリティカル・エラーの診断と解決は、通常、インシデント・アラートから開始されます。インシデント・アラートは、Enterprise Managerのデータベース・ホームページまたはOracle Automatic Storage Managementのホームページに表示されます。また、データベース・ホームページは、Oracle ASMインスタンスやその他のOracle製品またはコンポーネントのクリティカル・アラートを「関連アラート」セクションに表示します。アラートを表示した後、問題および関連するインシデントは、Enterprise ManagerまたはADRCIコマンドライン・ユーティリティを使用して表示できます。

次の項ではインシデントおよび問題について詳細に説明します。

- インシデントのフラッド制御

- トポロジ全体に関連する問題

関連項目:

- 「Enterprise Managerサポート・ワークベンチを使用した問題の表示」

- 「問題の調査、レポートおよび解決」

- 「ADRCIコマンドライン・ユーティリティ」

インシデントのフラッド制御

問題によって、短期間の間に数十、場合によっては数百ものインシデントが生成されることも考えられます。その場合、生成される診断データが多すぎて、ADRの領域が大量に消費され、問題の診断および解決に手間がかかることにもなります。このような理由から、障害診断インフラストラクチャでは、特定のしきい値に達すると、インシデントの生成にフラッド制御が適用されます。フラッド制御されたインシデントとは、アラート・ログ・エントリは作成されてADRに記録されるが、インシデント・ダンプは生成されないインシデントです。フラッド制御インシデントは、診断データによりシステムに過大な負荷をかけることなく、クリティカル・エラーが継続的に発生していることを知らせる手段となります。Enterprise ManagerまたはADRCIのコマンドライン・ユーティリティを使用してインシデントを表示するときは、フラッド制御されたインシデントを表示するか非表示にするかを選択できます。

インシデントのフラッド制御のしきい値レベルは事前定義されており、変更できません。しきい値レベルは次のように定義されています。

- 1時間に同じ問題キーに対して5つのインシデントが発生した場合、その問題キーに対する後続のインシデントはフラッド制御されます。その問題キーに対するインシデントの通常(非フラッド制御)の記録は、次の1時間から再開されます。

- 1日に同じ問題キーに対して25のインシデントが発生した場合、その問題キーに対する後続のインシデントはフラッド制御されます。その問題キーに対するインシデントの通常の記録は、翌日から再開されます。

さらに、1時間に同じ問題キーに対して50のインシデントが発生した場合、または1日に同じ問題キーに対して250のインシデントが発生した場合、その問題キーに対する後続のインシデントはADRに記録されません。この場合は、後続のインシデントが記録されないことを示すメッセージがアラート・ログに書き込まれます。問題キーに対してインシデントが継続して生成されている間は、1時間または1日が経過するまで、10分ごとにこのメッセージがアラート・ログに追加されます。1時間または1日が経過すると、その問題キーに対するインシデントの通常の記録が再開されます。

トポロジ全体に関連する問題

データベース・インスタンスで識別されるすべての問題については、診断能力フレームワークによって、Oracle Databaseインストールのトポロジ全体に関連する問題が識別できます。単一インスタンス環境では、関連する問題はローカルのOracle ASMインスタンスで識別できます。Oracle RAC環境では、関連する問題はデータベース・インスタンスまたは他のノード上のOracle ASMインスタンスで識別できます。問題を調査する場合、関連する問題の情報を表示して収集できます。

問題が指定期間内に発生したり、同じ実行コンテキスト識別子を共有している場合、その問題は元の問題に関連しています。実行コンテキスト識別子(ECID)は、後からデータを取得するためにOracle DatabaseにコールするOracle Fusion Middlewareへのコールなど、Oracleソフトウェア・スタックを介した単一のコールに対するタグ付けおよび追跡のために使用されるグローバルに一意の識別子です。通常、ECIDは中間層で生成され、Oracle Call Interface (OCI)の属性としてデータベースに渡されます。Oracleソフトウェア・スタックの複数の層に単一のコールによる障害が存在する場合、生成された問題には同じECIDがタグ付けされるため、相関関係を確認できます。さらに、源になっている問題が発生した層を判別できます。

障害診断インフラストラクチャのコンポーネント

障害診断インフラストラクチャの主要なコンポーネントは次のとおりです。

- 自動診断リポジトリ(ADR)

- アラート・ログ

- トレース・ファイル、ダンプおよびコア・ファイル

- ADRのその他の内容

- Enterprise Managerサポート・ワークベンチ

- ADRCIコマンドライン・ユーティリティ

自動診断リポジトリ(ADR)

ADRは、データベース診断データ(トレース、ダンプ、アラート・ログ、状態モニターのレポートなど)のファイルベース・リポジトリです。複数のインスタンスや製品にまたがる一元化されたディレクトリ構造を持っています。リリース11g以降では、データベース、Oracle Automatic Storage Management(Oracle ASM)、リスナー、およびその他のオラクル社の製品やコンポーネントは、すべての診断データをADRに格納します。各製品のインスタンスはそれぞれ、診断データをADR内の独自のホーム・ディレクトリの下に配置します。たとえば、共有記憶域とOracle ASMを使用するOracle Real Application Clusters環境では、各データベース・インスタンスと各Oracle ASMインスタンスにADRホーム・ディレクトリがあります。ADRの統一されたディレクトリ構造、製品およびインスタンス間で一貫性のある診断データ形式、および統一されたツール・セットにより、ユーザーおよびOracleサポートは、複数のインスタンス間の診断データの相関関係を確認して分析できます。

注意:
リリース11g以降のOracle Databaseでは、アラート・ログを含むすべての診断データがADRに格納されるため、初期化パラメータのBACKGROUND_DUMP_DESTとUSER_DUMP_DESTが非推奨になりました。これらのパラメータは、ADRの場所を指定する初期化パラメータDIAGNOSTIC_DESTに置き換えられています。

関連項目:
DIAGNOSTIC_DESTパラメータとADRホームの詳細は、「自動診断リポジトリの構造、内容および場所」を参照してください。

アラート・ログ

アラート・ログは、データベースのメッセージとエラーの発生順のログのXMLファイルです。これはADRに格納され、次のものに関するメッセージが含まれます。

- クリティカル・エラー(インシデント)

- 管理操作(データベースの起動と停止、データベースのリカバリ、表領域の作成や削除など)。

- マテリアライズド・ビューの自動リフレッシュ中に発生したエラー

- その他のデータベース・イベント

アラート・ログは、Enterprise ManagerおよびADRCIユーティリティを使用して、テキスト形式(XMLタグは削除されます)で表示できます。また、下位互換性のためにADRに格納されたテキスト形式のアラート・ログもあります。ただし、テキスト形式は構造化されておらず、リリースごとに変更される場合があるため、アラート・ログの内容の解析はXML形式で行うことをお薦めします。

関連項目:

- 「ADRCIコマンドライン・ユーティリティ」

- 「アラート・ログの表示」

トレース・ファイル、ダンプおよびコア・ファイル

トレース・ファイル、ダンプおよびコア・ファイルには、問題の調査に使用する診断データが含まれています。これらはADRに格納されます。

トレース・ファイル

各サーバー・プロセスとバックグラウンド・プロセスは、対応するトレース・ファイルに情報を書き込むことができます。トレース・ファイルはプロセスの存続期間にわたって定期的に更新され、プロセスの環境、ステータス、アクティビティおよびエラーに関する情報を格納できます。さらに、プロセスでクリティカル・エラーが検出されると、そのエラーに関する情報が関連のトレース・ファイルに書き込まれます。トレース・ファイルはSQLトレース機能によっても作成され、各SQL文のパフォーマンス情報が提供されます。SQLトレース機能は、セッションまたはインスタンスに対して使用可能にできます。

トレース・ファイルの名前は、プラットフォームに依存します。通常、データベース・バックグラウンド・プロセスのトレース・ファイル名には、Oracle SID、バックグラウンド・プロセス名およびオペレーティング・システムのプロセス番号が含まれ、サーバー・プロセスのトレース・ファイル名には、Oracle SID、「ora」の文字列、およびオペレーティング・システムのプロセス番号が含まれます。ファイル拡張子は.trcです。たとえば、サーバー・プロセスのトレース・ファイル名は、orcl_ora_344.trcのようになります。トレース・ファイルは、対応するトレース・マップ(.trm)ファイルを伴う場合があり、このファイルにはトレース・ファイルの構造情報が含まれていて、検索やナビゲーションに使用されます。

Oracle Databaseには、トレース・ファイルの分析に役立つツールが用意されています。アプリケーション・トレース機能、SQLトレース機能およびトレース・ツールの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

関連項目:
「トレース・ファイルの検索」

ダンプ

ダンプは、特殊なタイプのトレース・ファイルです。ダンプでは、通常、1つのイベント(インシデントなど)に対応して1回だけ診断データが出力されますが、トレースでは、多くの場合、診断データが連続して出力されます。インシデントが発生すると、データベースは、そのインシデント用に作成されたインシデント・ディレクトリに1つ以上のダンプを書き込みます。インシデントのダンプには、ファイル名にインシデント番号も付きます。

コア・ファイル

コア・ファイルには、メモリー・ダンプがポート固有の形式ですべてバイナリで格納されます。コア・ファイル名は、文字列「core」とオペレーティング・システム・プロセスIDで構成されます。コア・ファイルを使用するのはOracleサポート・サービスのエンジニアのみです。プラットフォームによっては、コア・ファイルがない場合があります。

ADRのその他の内容

ADRには、前の各項で説明したファイルに加えて、状態モニター・レポート、データ修復レコード、SQLテスト・ケース、インシデント・パッケージなどが格納されます。これらのコンポーネントについては、この章で後述します。

Enterprise Managerサポート・ワークベンチ

Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)は、使いやすいグラフィカル・インタフェースで問題(クリティカル・エラー)を調査およびレポートできる機能で、場合によってはその問題を修復することもできます。サポート・ワークベンチでは、セルフサービス方式で、初期障害の診断データの収集、サポート・リクエスト番号の取得、および診断データのOracleサポートへのアップロードを最小限の労力と非常に短い時間で行えるので、問題の解決にかかる時間を短縮できます。また、サポート・ワークベンチでは、SQL関連の問題やデータ破損の問題などを解決できるOracleアドバイザへの容易なアクセスを推奨および提供します。

ADRCIコマンドライン・ユーティリティ

ADRコマンド・インタプリタ(ADRCI)は、問題の調査、ヘルス・チェック・レポートの表示、および初期障害診断データのパッケージ化を、すべてコマンドライン環境内で実行できるユーティリティです。その後、このパッケージをOracleサポートにアップロードできます。また、ADRCIを使用すると、ADRに格納されているトレース・ファイルの名前の表示、およびアラート・ログの表示(XMLタグは削除されます)を、フィルタ処理の有無を選択して実行できます。

ADRCIの詳細は、『Oracle Databaseユーティリティ』を参照してください。

自動診断リポジトリの構造、内容および場所

自動診断リポジトリ(ADR)は、データベースの外部に格納されているディレクトリ構造です。そのため、データベースが停止しているときに問題の診断に使用できます。

ADRのルート・ディレクトリはADRベースと呼ばれます。その場所はDIAGNOSTIC_DEST初期化パラメータによって設定されます。このパラメータを省略するかNULLのままにすると、データベースでは起動時にDIAGNOSTIC_DESTを次のように設定します。

- 環境変数ORACLE_BASEが設定されている場合、DIAGNOSTIC_DESTはORACLE_BASEで指定されたディレクトリに設定されます。

- 環境変数ORACLE_BASEが設定されていない場合、DIAGNOSTIC_DESTはORACLE_HOME/logに設定されます。

ADRベース内では、複数のADRホームが存在することがあり、各ADRホームは、特定のOracle製品やコンポーネントの特定のインスタンスに対するすべての診断データ(トレース、ダンプ、アラート・ログなど)のルート・ディレクトリです。たとえば、Oracle ASMを使用するOracle Real Application Clusters環境では、各データベース・インスタンス、Oracle ASMインスタンスおよびリスナーにADRホームがあります。

ADRホームは、製品またはコンポーネントのタイプに基づいて名前が付けられたADRベース・サブディレクトリにあります。図9-1は、これらのトップレベルのサブディレクトリを示しています。

図9-1 ADR内の製品/コンポーネント・タイプのサブディレクトリ

注意:
構成に応じて、ADRに追加のサブディレクトリが作成される場合もあります。一部の製品では、期限切れの診断データがADRから自動的にパージされます。その他の製品の場合は、ADRCIユーティリティPURGEコマンドを一定の間隔で使用して、期限切れの診断データをパージできます。

各ADRホームの場所は、ADRの基本ディレクトリから始まる次のパスで指定されます。

diag/product_type/product_id/instance_id

例として、表9-1に、Oracle Databaseインスタンスの様々なパス・コンポーネントの値を示します。

表9-1 Oracle DatabaseのADRホームのパス・コンポーネント

パス・コンポーネント

Oracle Databaseの値

product_type

rdbms

product_id

DB_UNIQUE_NAME

instance_id

SID

たとえば、SIDとデータベースの一意の名前が両方ともorclbiのデータベースと同じ場合、ADRホームの場所は次のようになります。

ADR_base/diag/rdbms/orclbi/orclbi/

同様に、単一インスタンス環境におけるOracle ASMインスタンスへのADRホームのパスは、次のとおりです。

ADR_base/diag/asm/+asm/+asm/

ADRホーム・サブディレクトリ

各ADRホーム・ディレクトリ内には、診断データが含まれるサブディレクトリがあります。表9-2に、これらのサブディレクトリの一部とその内容を示します。

表9-2 ADRホーム・サブディレクトリ

サブディレクトリ名

目次

alert

XML形式のアラート・ログ。

cdump

コア・ファイル。

incident

複数のサブディレクトリ。各サブディレクトリは特定のインシデントにちなんで名付けられ、それぞれにそのインシデントにのみ関係するダンプが含められる

trace

バックグラウンドおよびサーバー・プロセスのトレース・ファイル、SQLトレース・ファイル、およびテキスト形式のアラート・ログ。

(その他)

ADRホームのその他のサブディレクトリ。インシデント・パッケージ、状態監視レポートおよびその他の情報が格納される

図9-2に、データベース・インスタンスのADRのディレクトリ階層全体を示します。

図9-2 データベース・インスタンスのADRディレクトリ構造

Oracle Real Application Clusters環境でのADR

Oracle Real Application Clusters(Oracle RAC)環境では、ADRベースはノードごとに独自のローカル記憶域に設定するか、ADRベースは共有記憶域に設定できます。ADRCIを使用して、すべてのインスタンスから集計された診断データを1つのレポートに表示できます。

Oracle ClientにおけるADR

インストールされたOracle Clientには、Oracle Clientコンポーネントのクリティカルな障害に関連する診断データのADRが含まれます。Oracle ClientとともにADRCIユーティリティがインストールされており、これにより、診断データを確認して、Oracleサポートにアップロードするためにパッケージ化できます。

V$DIAG_INFOビューを使用したADRの場所の表示

V$DIAG_INFOビューには、現在のOracle Databaseインスタンスにとって重要なADRの場所がすべてリストされます。

SELECT * FROM V$DIAG_INFO;

INST_ID NAME                  VALUE
------- --------------------- -------------------------------------------------------------
1 Diag Enabled          TRUE
1 ADR Base              /u01/oracle
1 ADR Home              /u01/oracle/diag/rdbms/orclbi/orclbi
1 Diag Trace            /u01/oracle/diag/rdbms/orclbi/orclbi/trace
1 Diag Alert            /u01/oracle/diag/rdbms/orclbi/orclbi/alert
1 Diag Incident         /u01/oracle/diag/rdbms/orclbi/orclbi/incident
1 Diag Cdump            /u01/oracle/diag/rdbms/orclbi/orclbi/cdump
1 Health Monitor        /u01/oracle/diag/rdbms/orclbi/orclbi/hm
1 Default Trace File    /u01/oracle/diag/rdbms/orclbi/orclbi/trace/orcl_ora_22769.trc
1 Active Problem Count  8
1 Active Incident Count 20

次の表で、このビューに表示されるいくつかの情報を説明します。

表9-3 V$DIAG_INFOビューのデータ

名前

説明

ADR Base

ADRベースのパス

ADR Home

現行データベース・インスタンスのADRホームのパス

Diag Trace

バックグラウンド・プロセスのトレース・ファイル、サーバー・プロセスのトレース・ファイル、SQLトレース・ファイル、およびテキスト形式のアラート・ログの場所

Diag Alert

XML形式のアラート・ログの場所

Default Trace File

現行セッションのトレース・ファイルへのパス

V$DIAG_CRITICAL_ERRORビューを使用したクリティカル・エラーの表示

V$DIAG_CRITICAL_ERRORには、現在のOracle Databaseリリースでクリティカル・エラーとして指定されている、内部エラー以外のすべてのエラーがリストされます。内部エラーは常にクリティカル・エラーとして指定されているため、このビューに内部エラーはリストされません。

次の例は、Oracle Database 11g リリース2 (11.2.0.2)でのV$DIAG_CRITICAL_ERRORビューの出力を示しています。

SELECT * FROM V$DIAG_CRITICAL_ERROR;

FACILITY   ERROR
---------- ----------------------------------------------------------------
ORA        7445
ORA        4030
ORA        4031
ORA        29740
ORA        255
ORA        355
ORA        356
ORA        239
ORA        240
ORA        494
ORA        3137
ORA        227
ORA        353
ORA        1578
ORA        32701
ORA        32703
ORA        29770
ORA        29771
ORA        445
ORA        25319
OCI        3106
OCI        3113
OCI        3135

次の表で、このビューに表示される情報を説明します。

表9-4 V$DIAG_CRITICAL_ERRORビューのデータ

列

説明

FACILITY

そのエラーをレポート可能な機能(Oracle Database (ORA)、Oracle Call Interface (OCI)など)

ERROR

エラー番号

関連項目:
内部エラーの詳細は、「インシデントおよび問題の概要」を参照してください。

問題の調査、レポートおよび解決

ここでは、Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用して、問題(クリティカル・エラー)を調査およびレポートし、場合によってはその問題を修復する方法について説明します。最初に、実行する必要がある一般的なタスクを要約した「ロードマップ」を示します。

注意:
この項で説明するタスクは、すべてEnterprise Managerベースです。すべてのタスク(または同等のタスク)は、ADRCIコマンドライン・ユーティリティ、PL/SQLパッケージ(DBMS_HM、DBMS_SQLDIAGなど)、およびその他のソフトウェア・ツールを使用して実行できます。ADRCIユーティリティの詳細は『Oracle Databaseユーティリティ』を、PL/SQLパッケージの詳細は『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

関連項目:
問題とその診断データの詳細は、「Oracle Databaseの障害診断インフラストラクチャの概要」を参照してください。

問題の調査、レポートおよび解決のロードマップ

問題の調査は、Enterprise Managerの「サポート・ワークベンチ」ホームページから開始できます。ただし、標準的なワークフローはデータベースのホームページのクリティカル・エラー・アラートから始まります。この項では、そのワークフローの概要について説明します。

図9-3に、問題を調査およびレポートし、場合によってはその問題を修復するためのタスクを示します。

図9-3 問題の調査、レポートおよび解決のためのワークフロー

タスクの説明を次に示します。この後の項では、各タスクについて詳しく説明します。

- タスク1: Enterprise Managerでのクリティカル・エラー・アラートの表示
最初に、Enterprise Managerでデータベースのホームページにアクセスし、クリティカル・エラー・アラートを確認します。詳細を表示するアラートを選択し、「問題の詳細」ページに進みます。

- タスク2: 問題の詳細の表示
問題の詳細を検証し、その問題に対して記録されたすべてのインシデントのリストを表示します。自動的に実行された状態チェックの結果を表示します。

- タスク3: (オプション)追加の診断情報の収集
必要に応じて、追加のヘルス・チェックまたは他の診断を実行します。SQL関連エラーの場合は、必要に応じてSQLテスト・ケース・ビルダーを起動して、SQL問題に関連する必要なすべてのデータを収集し、Oracleサポート・サービスで問題を再現できる方法で情報をパッケージ化します。

- タスク4: (オプション)サービス・リクエストの作成
必要に応じて、My Oracle Supportでサービス・リクエストを作成し、問題情報にサービス・リクエスト番号を追加して記録します。この手順をスキップした場合、サービス・リクエストは後で作成するか、サポート・ワークベンチで作成することができます。

- タスク5: 診断データのパッケージ化とOracleサポート・サービスへのアップロード
問題のために収集された診断データを自動的にパッケージ化してOracleサポートにアップロードするガイド付きワークフロー(ウィザード)を起動します。

- タスク6: サービス・リクエストの追跡と修復の実装
オプションとして、サービス・リクエストのアクティビティ・ログをサポート・ワークベンチでメンテナンスします。Oracleアドバイザを実行して、SQLエラーまたは破損データを修復します。

- タスク7: インシデントのクローズ
問題に対する1つ、複数またはすべてのインシデントのステータスを「クローズ」に設定します。

関連項目:
「Enterprise Managerサポート・ワークベンチを使用した問題の表示」

タスク1: Enterprise Managerでのクリティカル・エラー・アラートの表示

問題(クリティカル・エラー)を調査するプロセスでは、最初にデータベース・ホームページまたはOracle Automatic Storage Managementホームページでクリティカル・エラー・アラートを検討します。

クリティカル・エラー・アラートを表示するには、次のようにします。

1. Enterprise Managerのデータベース・ホームページにアクセスします。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。

2. 次の手順のうち1つを実行してクリティカル・エラー・アラートを表示します。クリティカル・エラー・アラートは「重大度」列に赤の×印で表示され、「カテゴリ」列に「インシデント」というテキストが表示されます。

- 「アラート」セクションでアラートを表示します。
「アラート」を表示するには、「アラート」ヘッダーの横にある表示/非表示アイコンをクリックすることが必要な場合があります。

- 「関連アラート」セクションでアラートを表示します。
「ターゲット名」は、クリティカル・エラーが発生したOracle製品またはコンポーネントを示します。詳細は、「トポロジ全体に関連する問題」を参照してください。

- 次の手順を実行して、Oracle ASMインスタンスのクリティカル・アラートを表示します。

1. 「一般」セクションで「ASM」ラベルの横にあるリンクをクリックします。

2. 自動ストレージ管理ホームページで下にスクロールして「アラート」セクションを表示します。

図9-4 データベース・ホームページの「アラート」セクション

3. 「メッセージ」列で、調査するクリティカル・エラー・アラートのメッセージをクリックします。
「インシデント」ページまたは「データ障害」ページが表示されます。このページには次の内容が表示されます。

- 問題に関する情報(問題のインシデント数を含む)

- 過去24時間に発生したクリティカル・エラーに関する「パフォーマンスとクリティカル・エラー」時間グラフ(データベース・インスタンスのみ)。

- アラートの詳細(重大度、タイムスタンプ、メッセージを含む)

- アラートをクリアしたり、アラートに関するコメントを記録するためのコントロール。

4. 「パフォーマンスとクリティカル・エラー」時間グラフがあればこれを検討し、パフォーマンスの問題とクリティカル・エラーの間の関連をメモします。アラートはクリアしてもかまいませんが、コメントを付けて残しておくこともできます。

タスク2: 問題の詳細の表示

「問題の詳細」ページを表示して調査を続行します。

問題の詳細を表示するには、次のようにします。

1. 「インシデント」ページまたは「データ障害」ページで、「問題の詳細の表示」をクリックします。
問題の詳細ページにインシデント・サブページが表示されます。

2. (オプション)次のどちらか、または両方を実行します。

- 「調査と解決」セクションの「セルフ・サービス」タブの「診断」で「トポロジ全体に関連する問題」をクリックします。
ローカルのOracle Automatic Storage Management(Oracle ASM)インスタンス、またはOracle Real Application Clusters環境における他のノード上のデータベースまたはOracle ASMインスタンスにおける関連する問題を示すページが表示されます。Enterprise Managerのデータベース・ホームページ上の「関連アラート」セクションにクリティカル・アラートが表示されている場合は、この手順をお薦めします。

詳細は、「トポロジ全体に関連する問題」を参照してください。

- これらの手順を実行してインシデントの詳細を表示します。

1. 「インシデント」サブページ内でインシデントを選択してから、「表示」をクリックします。

2. (オプション)「インシデントの詳細」ページで、「チェッカ結果」をクリックして「チェッカ結果」サブページを表示します。
このページには、クリティカル・エラー検出時に自動的に実行された状態チェックの結果が表示されます。

詳細は、「状態モニターを使用したヘルス・チェックの実行」を参照してください。

タスク3: (オプション)追加の診断情報の収集

次のアクティビティを実行して、問題に関する追加の診断情報を収集します。この追加情報は、Oracleサポートにアップロードされる診断データに自動的に追加されます。これらのアクティビティの実行に関して不明な点がある場合は、Oracleサポートの担当者に確認してください。

- 追加のヘルス・チェックを手動で起動します。
「状態モニターを使用したヘルス・チェックの実行」を参照してください。

- SQLテスト・ケース・ビルダーを起動します。
詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

タスク4: (オプション)サービス・リクエストの作成

ここでは、Oracleサポート・サービスへのサービス・リクエストを作成し、サービス・リクエスト番号を問題情報とともに記録できます。このタスクをスキップした場合は、タスク5で、サポート・ワークベンチでドラフトのサービス・リクエストが自動的に作成されます。

サービス・リクエストを作成するには、次のようにします。

1. 「問題の詳細」ページの「調査と解決」セクションで、「My Oracle Support and Researchに移動」をクリックします。
新しいブラウザ・ウィンドウで「My Oracle Supportのサインインと登録」ページが表示されます。

注意:
「問題の詳細」ページに戻る場合の手順は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

2. My Oracle Supportにログインし、通常の方法でサービス・リクエストを作成します。
(オプション)次の手順のためにサービス・リクエスト番号(SR#)を覚えておきます。

3. (オプション)問題の詳細ページに戻り、次の手順を実行します。

1. 「サマリー」セクションで、「SR#」ラベルの横にある「編集」ボタンをクリックします。

2. SR#を入力してから、「OK」をクリックします。

SR#が問題の詳細ページに記録されます。この情報は参照専用です。

タスク5: 診断データのパッケージ化とOracleサポート・サービスへのアップロード

このタスクでは、サポート・ワークベンチのクイック・パッケージング・プロセスを使用して、問題に関する診断情報をパッケージ化し、Oracleサポート・サービスにアップロードします。クイック・パッケージングは、最小限の手順をガイド付きワークフロー(ウィザード)にまとめたものです。ウィザードを使用して、1つの問題に対してインシデント・パッケージ(パッケージ)を作成し、そのパッケージからZIPファイルを作成してアップロードします。ただし、クイック・パッケージングでは、アップロードする診断情報の編集やその他のカスタマイズは行えません。ただし、クイック・パッケージングを使用すると、直接的かつ簡単な方法で診断データをパッケージ化してアップロードできます。

診断情報に含まれる機密データの編集や削除、追加のユーザー・ファイル(アプリケーション構成ファイルやスクリプトなど)の同封、その他のカスタマイズをアップロード前に実行するには、(手動のプロセスと手順が多い)カスタム・パッケージング・プロセスを使用する必要があります。手順については、「カスタム・インシデント・パッケージの作成、編集およびアップロード」を参照してください。このタスク5の手順のかわりにその手順を行う場合は、その手順を行い、完了してから「タスク6: サービス・リクエストの追跡と修復の実装」に進んでください。

注意:
サポート・ワークベンチはOracle Configuration Managerを使用して診断データをアップロードします。Oracle Configuration Managerがインストールされていなかったり、適切に構成されていないと、アップロードに失敗する場合があります。この場合、メッセージが表示され、Oracleサポートへファイルを手動でアップロードするように要求されます。アップロードは、My Oracle Supportを使用して手動で実行できます。
Oracle Configuration Managerの詳細は、『Oracle Configuration Managerインストレーションおよび管理ガイド』を参照してください。

診断データをパッケージ化してOracleサポートにアップロードするには、次のようにします。

1. 問題の詳細ページの「調査と解決」セクションで、「クイック・パッケージ」をクリックします。
「クイック・パッケージ」ウィザードの「新規パッケージの作成」ページが表示されます。

注意:
「問題の詳細」ページに戻る場合の手順は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

2. 必要に応じて、パッケージ名と説明を入力します。

3. ページの残りのフィールドに必要事項を入力します。問題に対してサービス・リクエストをすでに作成している場合は、「新規サービス・リクエスト(SR)の作成」の横にある「いいえ」を選択します。
「はい」を選択すると、「クイック・パッケージング」ウィザードでドラフトのサービス・リクエストが作成されます。後でMy Oracle Supportにログインして、このサービス・リクエストの詳細を入力する必要があります。

4. 「次」をクリックし、「クイック・パッケージング」ウィザードの残りのページに進みます。
作成されたパッケージは、クイック・パッケージング・ウィザードの手順の完了後も引き続きサポート・ワークベンチで使用できます。カスタム・パッケージング操作を使用してパッケージを変更し(新規インシデントの追加など)、後でパッケージを再アップロードできます。「インシデント・パッケージの表示と変更」を参照してください。

タスク6: サービス・リクエストの追跡および修復の実施

診断情報をOracleサポート・サービスにアップロードした後は、様々なアクティビティを実行してサービス・リクエストを追跡し、追加の診断情報を収集して、修復を実装できます。このアクティビティには次のものがあります。

- 問題情報にOracleバグ番号を追加します。
そのためには、問題の詳細ページで「バグ#」ラベルの横にある「編集」ボタンをクリックします。この情報は参照専用です。

- 問題のアクティビティ・ログにコメントを追加します。
このアクティビティは、組織内の他のDBAと問題ステータスや履歴情報を共有する場合に実行します。たとえば、Oracleサポート・サービスとの対話の結果を記録できます。コメントを追加する手順は、次のとおりです。

1. 「Enterprise Managerサポート・ワークベンチを使用した問題の表示」で説明するように、該当する問題の「問題の詳細」ページにアクセスします。

2. 「アクティビティ・ログ」をクリックして、アクティビティ・ログ・サブページを表示します。

3. 「コメント」フィールドにコメントを入力し、「コメントの追加」をクリックします。
コメントがアクティビティ・ログに記録されます。

- 新規に発生したインシデントをパッケージ化して再アップロードします。
このアクティビティには、「カスタム・インシデント・パッケージの作成、編集およびアップロード」で説明するように、カスタム・パッケージング方法を使用する必要があります。

- ヘルス・チェックを実行します。
「状態モニターを使用したヘルス・チェックの実行」を参照してください。

- 推奨されるOracleアドバイザを実行して修復を実施します。
推奨されたアドバイザには、次のいずれかの方法でアクセスします。

- 問題の詳細ページ: 「調査と解決」セクションの「セルフ・サービス」タブ

- 「サポート・ワークベンチ」ホームページ: 「チェッカ結果」サブページ

- 「インシデントの詳細」ページ: 「チェッカ結果」サブページ

表9-5に、クリティカル・エラーの修復に役立つアドバイザを示します。

表9-5 クリティカル・エラーの修復に役立つOracleアドバイザ

アドバイザ

対象となるクリティカル・エラー

参照先

データ・リカバリ・アドバイザ

破損ブロック、破損または欠落しているファイル、その他のデータ障害

「データ・リカバリ・アドバイザを使用したデータ破損の修復」

SQL修復アドバイザ

SQL文エラー

「SQL修復アドバイザを使用したSQLエラーの修復」

関連項目:
「インシデントの詳細」ページの「チェッカ結果」サブページを表示する手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

タスク7: インシデントのクローズ

特定のインシデントの処理が終了した場合は、そのインシデントをクローズできます。デフォルトでは、クローズされたインシデントは問題の詳細ページに表示されません。

クローズされたかどうかにかかわらず、インシデントはすべて30日後にパージされます。インシデントのパージはインシデントの詳細ページで無効化できます。

インシデントをクローズする手順は、次のとおりです。

1. 「サポート・ワークベンチ」ホームページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

2. 目的の問題を選択して「表示」をクリックします。
問題の詳細ページが表示されます。

3. クローズするインシデントを選択して「閉じる」をクリックします。
「確認」ページが表示されます。

4. 必要に応じてコメントを入力し、「OK」をクリックします。

Enterprise Managerサポート・ワークベンチを使用した問題の表示

すべての問題を表示したり、特定の期間内に発生した問題のみを表示するには、Enterprise Managerの「サポート・ワークベンチ」ホームページ(図9-5)を使用します。

図9-5 Enterprise Managerの「サポート・ワークベンチ」ホームページ

「サポート・ワークベンチ」ホームページ(データベースまたはOracle ASM)にアクセスする手順は、次のとおりです。

1. Enterprise Managerのデータベース・ホームページにアクセスします。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。

2. 次のいずれかを実行します。

- 「診断サマリー」セクションで「アクティブなインシデント」ラベルの横にある数字リンクをクリックします。

- トップページで「ソフトウェアとサポート」をクリックしてから「サポート」の「サポート・ワークベンチ」をクリックします。

データベース・インスタンスの「サポート・ワークベンチ」ホームページに「問題」サブページが表示されます。デフォルトでは、過去24時間の問題が表示されます。

3. Oracle ASMインスタンスの「サポート・ワークベンチ」ホームページを表示するには、「関連リンク」セクションの「サポート・ワークベンチ(+ASM_hostname)」リンクをクリックします。

問題とインシデントの表示方法

1. 「サポート・ワークベンチ」ホームページの「表示」リストから希望する期間を選択します。すべての問題を表示するには、「すべて」を選択します。

2. (オプション)「パフォーマンスとクリティカル・エラー」セクションが非表示の場合は、セクション・ヘッダーに隣接する表示/非表示アイコンをクリックするとセクションが表示されます。
このセクションでは、パフォーマンスの変化とインシデントの発生の関連を表示できます。

3. (オプション)「詳細」列の下の「表示」をクリックして、特定の問題に関するすべてのインシデントのリストを表示します。次に、インシデントIDをクリックして、インシデントの詳細ページを表示します。

特定の問題の詳細を表示するには、次の手順を実行します。

1. サポート・ワークベンチのホームページで、問題を選択して「表示」をクリックします。
問題の詳細ページにインシデント・サブページが表示されます。「インシデント」サブページには、オープンしてダンプが生成された(つまり、フラッド制御されていない)すべてのインシデントが表示されます。

2. (オプション)オープン状態のインシデントとクローズしたインシデントの両方を表示するには、「ステータス」リストで「すべてのインシデント」を選択します。通常のインシデントとフラッド制御されているインシデントの両方を表示するには、「ダンプされたデータ」リストで「すべてのインシデント」を選択します。

3. (オプション)インシデントの詳細を表示するには、インシデントを選択して「表示」をクリックします。
インシデントの詳細ページが表示されます。

4. (オプション)「インシデントの詳細」ページで、インシデントのチェッカ結果を表示するには、「チェッカ結果」をクリックします。

5. (オプション)インシデントの詳細ページに、そのインシデントに対して実行可能なユーザー・アクションを表示するには、「追加の診断」をクリックします。各ユーザー・アクションにより、インシデントまたはその問題に関する追加の診断情報を収集できます。

関連項目:
「インシデントのフラッド制御」

ユーザー報告の問題の作成

システムで生成された問題(内部でデータベースに生成されたクリティカル・エラー)は、自動的に自動診断リポジトリ(ADR)に追加され、サポート・ワークベンチ内で追跡されます。サポート・ワークベンチから、それらの問題に関する追加の診断データを収集し、それをOracleサポートにアップロードできたり、場合によっては問題を解決することもでき、それらはすべて「問題の調査、レポートおよび解決」で説明されている使いやすいワークフローに記載されています。

気づいた問題を同じワークフローで処理できるように、その問題を手動でADRに追加する場合があります。このような問題の例には、自動データベース診断モニター(ADDM)で診断されなかったグローバル・データベースのパフォーマンスに関する問題があります。サポート・ワークベンチは、このようなユーザー報告の問題を作成して処理するメカニズムを備えています。

ユーザー報告の問題を作成する手順は、次のとおりです。

1. 「サポート・ワークベンチ」ホームページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

2. 「関連リンク」で「ユーザー報告の問題の作成」をクリックします。
「ユーザー報告の問題の作成」ページが表示されます。

3. リストされている問題のタイプのいずれかと問題が一致する場合は、その問題のタイプを選択して「推奨アドバイザの実行」をクリックし、Oracleアドバイザを実行して問題の解決を試みます。

4. 推奨アドバイザで問題が解決しない場合、またはアドバイザを実行しなかった場合は、次のいずれかを実行します。

- リストされている問題のタイプのいずれかと問題が一致する場合は、その問題のタイプを選択して「問題の作成の続行」をクリックします。

- リストされている問題のタイプのいずれかと問題が一致しない場合は、問題のタイプ「上記のいずれでもない」を選択して説明を入力し、「問題の作成の続行」をクリックします。

問題の詳細ページが表示されます。

5. 「問題の詳細」ページの手順に従います。
詳細は、「問題の調査、レポートおよび解決」を参照してください。

関連項目:
問題とADRの詳細は、「Oracle Databaseの障害診断インフラストラクチャの概要」を参照してください。

アラート・ログの表示

アラート・ログは、テキスト・エディタ、Enterprise ManagerまたはADRCIユーティリティを使用して表示できます。

Enterprise Managerを使用してアラート・ログを表示する手順は、次のとおりです。

1. Enterprise Managerのデータベース・ホームページにアクセスします。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。

2. 「関連リンク」で「アラート・ログの内容」をクリックします。
「アラート・ログの内容の表示」ページが表示されます。

3. 表示するエントリの数を選択して「実行」をクリックします。

テキスト・エディタを使用してアラート・ログを表示する手順は、次のとおりです。

1. SQL*PlusまたはSQL Developerなどの問合せツールを使用して、データベースに接続します。

2. 「V$DIAG_INFOビューを使用したADRの場所の表示」に示すV$DIAG_INFOビューを問い合せます。

3. XMLタグがないテキストのみのアラート・ログを表示する手順は、次のとおりです。

1. V$DIAG_INFO問合せ結果からDiag Traceエントリに対応するパスをメモし、ディレクトリをそのパスに変更します。

2. テキスト・エディタを使用して、alert_SID.logファイルをオープンします。

4. XML形式のアラート・ログを表示する手順は、次のとおりです。

1. V$DIAG_INFO問合せ結果からDiag Alertエントリに対応するパスをメモし、ディレクトリをそのパスに変更します。

2. テキスト・エディタを使用して、log.xmlファイルをオープンします。

関連項目:
ADRCIユーティリティを使用してテキスト形式(XMLタグは削除されます)のアラート・ログを表示し、そのアラート・ログに対して問合せを実行する方法については、『Oracle Databaseユーティリティ』を参照してください。

トレース・ファイルの検索

トレース・ファイルは、自動診断リポジトリ(ADR)内の各ADRホーム下にあるtraceディレクトリに格納されます。このディレクトリ内の個々のトレース・ファイルを検索するには、データ・ディクショナリ・ビューを使用します。たとえば、現行セッションのトレース・ファイルへのパス、または各Oracle Databaseプロセスのトレース・ファイルへのパスを検索できます。

現行セッションのトレース・ファイルを検索する手順は、次のとおりです。

- 次の問合せを発行します。

SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Default Trace File';

トレース・ファイルへのフルパスが返されます。

現行インスタンスのすべてのトレース・ファイルを検索する手順は、次のとおりです。

- 次の問合せを発行します。

SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

現在のインスタンスのADRトレース・ディレクトリへのパスが返されます。

各Oracle Databaseプロセスのトレース・ファイルを特定する手順は、次のとおりです。

- 次の問合せを発行します。

SELECT PID, PROGRAM, TRACEFILE FROM V$PROCESS;

関連項目:

- 「自動診断リポジトリの構造、内容および場所」

- 『Oracle Databaseユーティリティ』のADRCI SHOW TRACEFILEコマンドに関する項

状態モニターを使用したヘルス・チェックの実行

ここでは、状態モニターとその使用方法を説明します。この章では、次の項目について説明します。

- 状態モニターの概要

- ヘルス・チェックの手動実行

- チェッカ・レポートの表示

- 状態モニターのビュー

- ヘルス・チェック・パラメータの参考情報

状態モニターの概要

リリース11g以降のOracle Databaseは、データベースに対して診断チェックを実行する、状態モニターと呼ばれるフレームワークを備えています。

状態モニター・チェックの概要

状態モニター・チェック(チェッカ、ヘルス・チェックまたはチェックとも呼ばれます)では、データベースの様々なレイヤーとコンポーネントが検証されます。ヘルス・チェックでは、ファイルの破損、物理ブロックおよび論理ブロック破損、UNDOおよびREDOの破損、データ・ディクショナリの破損などが検出されます。また、ヘルス・チェックの結果のレポートが生成され、多くの場合、問題を解決するための推奨事項が示されます。ヘルス・チェックは次の2つの方法で実行できます。

- リアクティブ: 障害診断インフラストラクチャでは、クリティカル・エラーの内容に応じてヘルス・チェックを自動的に実行できます。

- 手動: DBAは、DBMS_HM PL/SQLパッケージまたはEnterprise Managerインタフェースのいずれかを使用して、ヘルス・チェックを手動で実行できます。必要に応じて定期的にチェッカを実行できますが、Oracleサポートがサービス・リクエストについて共同で作業しているときにチェッカの実行をお願いさせていただくこともあります。

状態モニター・チェックでは、結果、推奨事項およびその他の情報が自動診断リポジトリ(ADR)に格納されます。

ヘルス・チェックは次の2つのモードで実行できます。

- DBオンライン・モードは、データベースがオープン状態(つまり、OPENモードまたはMOUNTモード)のときは、チェックを実行できることを意味します。

- DBオフライン・モードは、インスタンスは使用可能だがデータベース自体がクローズ(つまり、NOMOUNTモード)している場合にチェックを実行できることを意味します。

DBオンライン・モードでは、すべてのヘルス・チェックを実行できます。DBオフライン・モードで使用できるのは、REDOの整合性チェックとDB構造の整合性チェックのみです。

関連項目:
「自動診断リポジトリ(ADR)」

ヘルス・チェックのタイプ

状態モニターでは次のチェックが実行されます。

- DB構造の整合性チェック: このチェックではデータベース・ファイルの整合性が検証され、これらのファイルがアクセス不可、破損状態または不整合の場合はエラーが報告されます。データベースがマウント・モードまたはオープン・モードの場合は、制御ファイルに列記されたログ・ファイルとデータファイルがチェックされます。データベースがNOMOUNTモードの場合は、制御ファイルのみがチェックされます。

- データ・ブロックの整合性チェック: このチェックではチェックサム・エラー、先頭/末尾の不一致、ブロック内の論理的不整合などのディスク・イメージ・ブロック破損が検出されます。ほとんどの破損はブロック・メディア・リカバリを使用して修復できます。破損ブロック情報はV$DATABASE_BLOCK_CORRUPTIONビューでも取得されます。このチェックではブロック間またはセグメント間の破損は検出されません。

- REDOの整合性チェック: このチェックではアクセス可能性と破損についてREDOログの内容がスキャンされ、可能な場合はアーカイブ・ログもスキャンされます。REDOの整合性チェックではアーカイブ・ログやREDOの破損などのエラーが報告されます。

- UNDOセグメントの整合性チェック: このチェックでは、論理的なUNDO破損が検出されます。UNDO破損の場所を特定した後、このチェックではPMONおよびSMONを使用して、破損したトランザクションのリカバリを試みます。このリカバリに失敗した場合、状態モニターは破損の情報をV$CORRUPT_XID_LISTに格納します。ほとんどのUNDO破損は、コミットを強制実行することで解決できます。

- トランザクションの整合性チェック: このチェックは、1つの特定トランザクションのみがチェックされることを除いて、UNDOセグメントの整合性チェックと同じです。

- ディクショナリの整合性チェック: このチェックでは、tab$、col$などのコア・ディクショナリ・オブジェクトの整合性が検証されます。次の操作を実行します。

- 各ディクショナリ・オブジェクトに対するディクショナリ・エントリの内容が確認されます。

- 行間レベルのチェックが実行され、ディクショナリの行で論理的制約が適用されていることが確認されます。

- オブジェクト関係のチェックが実行され、ディクショナリ・オブジェクト間で親子関係が規定されていることが確認されます。

ディクショナリの整合性チェックは、次のディクショナリ・オブジェクトに対して実行されます。

tab$、clu$、fet$、uet$、seg$、undo$、ts$、file$、obj$、ind$、icol$、col$、user$、con$、cdef$、ccol$、bootstrap$、objauth$、ugroup$、tsq$、syn$、view$、typed_view$、superobj$、seq$、lob$、coltype$、subcoltype$、ntab$、refcon$、opqtype$、dependency$、access$、viewcon$、icoldep$、dual$、sysauth$、objpriv$、defrole$およびecol$

ヘルス・チェックの手動実行

状態モニターでは、次の2つの方法でヘルス・チェックを手動で実行できます。

- DBMS_HM PL/SQLパッケージを使用する方法

- 「アドバイザ・セントラル」ページの「チェッカ」サブページにあるEnterprise Managerインタフェースを使用する方法

DBMS_HM PL/SQLパッケージを使用したヘルス・チェックの実行

ヘルス・チェックを実行するためのDBMS_HMプロシージャはRUN_CHECKです。RUN_CHECKをコールするには、次のようにチェック名と実行名を指定します。

BEGIN
DBMS_HM.RUN_CHECK('Dictionary Integrity Check', 'my_run');
END;
/

ヘルス・チェック名のリストを取得するには、次の問合せを実行します。

SELECT name FROM v$hm_check WHERE internal_check='N';

NAME
----------------------------------------------------------------
DB Structure Integrity Check
Data Block Integrity Check
Redo Integrity Check
Transaction Integrity Check
Undo Segment Integrity Check
Dictionary Integrity Check

ほとんどのヘルス・チェックに入力パラメータを指定できます。パラメータ名と説明はV$HM_CHECK_PARAMビューを使用して表示できます。一部のパラメータは必須ですが、オプションのパラメータもあります。オプションのパラメータを省略すると、デフォルトが使用されます。次の問合せでは、すべてのヘルス・チェックのパラメータ情報が表示されます。

SELECT c.name check_name, p.name parameter_name, p.type,
p.default_value, p.description
FROM v$hm_check_param p, v$hm_check c
WHERE p.check_id = c.id and c.internal_check = 'N'
ORDER BY c.name;

入力パラメータは、セミコロン(;)で区切られた名前/値のペアとしてinput_params引数で渡されます。次の例では、トランザクションIDをパラメータとして「トランザクションの整合性チェック」に渡す方法を示します。

BEGIN
DBMS_HM.RUN_CHECK (
check_name   => 'Transaction Integrity Check',
run_name     => 'my_run',
input_params => 'TXN_ID=7.33.2');
END;
/

関連項目:

- 「ヘルス・チェック・パラメータの参考情報」

- DBMS_HMの使用例の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

Enterprise Managerを使用したヘルス・チェックの実行

Enterprise Managerは、状態モニター・チェッカを実行するためのインタフェースを備えています。

Enterprise Managerを使用して状態モニター・チェッカを実行する手順は、次のとおりです。

1. データベース・ホームページにある「関連リンク」セクションで、「アドバイザ・セントラル」をクリックします。

2. 「チェッカ」をクリックして「チェッカ」サブページを表示します。

3. 「チェッカ」セクションで、実行するチェッカをクリックします。

4. 入力パラメータの値を入力するか、オプション・パラメータの場合は空白のままにしてデフォルトを使用します。

5. 「実行」をクリックし、パラメータを確認して「実行」を再度クリックします。

チェッカ・レポートの表示

チェッカを実行した後は、その実行内容のレポートを表示できます。レポートには、結果、推奨事項およびその他の情報が含まれます。このレポートは、Enterprise Manager、ADRCIユーティリティまたはDBMS_HM PL/SQLパッケージを使用して表示できます。次の表に、各表示方法で使用可能なレポート形式を示します。

レポートの表示方法

使用可能なレポート形式

Enterprise Manager

HTML

DBMS_HM PL/SQLパッケージ

HTML、XMLおよびテキスト

ADRCIユーティリティ

XML

チェッカの実行結果(結果、推奨事項およびその他の情報)はADRに格納されますが、レポートはすぐに生成されません。DBMS_HM PL/SQLパッケージまたはEnterprise Managerを使用してレポートを要求したときに、レポートがまだ生成されていない場合は、最初にADR内のチェッカ実行データからレポートが生成され、現行インスタンス用のADRホームのHMサブディレクトリにXML形式でレポート・ファイルとして格納された後に、レポートが表示されます。レポートがすでに生成されている場合は、そのレポートが表示されます。ADRCIユーティリティを使用する場合、レポートがまだ生成されていないときは、最初にレポート・ファイルを生成するためのコマンドを実行し、次にその内容を表示するためのコマンドを実行する必要があります。

チェッカ・レポートは、Enterprise Managerを使用して表示することをお薦めします。次の各項では、各表示方法の手順を説明します。

- Enterprise Managerを使用したレポートの表示

- DBMS_HMを使用したレポートの表示

- ADRCIユーティリティを使用したレポートの表示

関連項目:
「自動診断リポジトリ(ADR)」

Enterprise Managerを使用したレポートの表示

Enterprise Managerを使用して、特定のチェッカ実行の状態モニター・レポートと結果を表示できます。

Enterprise Managerを使用して実行結果を表示する手順は、次のとおりです。

1. データベース・ホームページにアクセスします。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。

2. 「関連リンク」セクションで、「アドバイザ・セントラル」をクリックします。

3. 「チェッカ」をクリックして「チェッカ」サブページを表示します。

4. 表示するチェッカ実行の実行名をクリックします。
「実行の詳細」ページにチェッカ実行の結果が表示されます。

5. 「実行」をクリックして「実行」サブページを表示します。
チェッカ実行に関する詳細な情報が表示されます。

6. 「レポートの表示」をクリックして、チェッカ実行のレポートを表示します。
レポートが新規のブラウザ・ウィンドウに表示されます。

DBMS_HMを使用したレポートの表示

状態モニター・チェッカ・レポートは、DBMS_HMパッケージ・ファンクションGET_RUN_REPORTを使用して表示できます。このファンクションを使用すると、HTML、XMLまたはテキスト形式のレポートを要求できます。デフォルトはテキスト形式で、次にSQL*Plusの例を示します。

SET LONG 100000
SET LONGCHUNKSIZE 1000
SET PAGESIZE 1000
SET LINESIZE 512
SELECT DBMS_HM.GET_RUN_REPORT('HM_RUN_1061') FROM DUAL;

DBMS_HM.GET_RUN_REPORT('HM_RUN_1061')
-----------------------------------------------------------------------

Run Name                     : HM_RUN_1061
Run Id                       : 1061
Check Name                   : Data Block Integrity Check
Mode                         : REACTIVE
Status                       : COMPLETED
Start Time                   : 2007-05-12 22:11:02.032292 -07:00
End Time                     : 2007-05-12 22:11:20.835135 -07:00
Error Encountered            : 0
Source Incident Id           : 7418
Number of Incidents Created  : 0

Input Paramters for the Run
BLC_DF_NUM=1
BLC_BL_NUM=64349

Run Findings And Recommendations
Finding
Finding Name  : Media Block Corruption
Finding ID    : 1065
Type          : FAILURE
Status        : OPEN
Priority      : HIGH
Message       : Block 64349 in datafile 1:
'/u01/app/oracle/dbs/t_db1.f' is media corrupt
Message       : Object BMRTEST1 owned by SYS might be unavailable
Finding
Finding Name  : Media Block Corruption
Finding ID    : 1071
Type          : FAILURE
Status        : OPEN
Priority      : HIGH
Message       : Block 64351 in datafile 1:
'/u01/app/oracle/dbs/t_db1.f' is media corrupt
Message       : Object BMRTEST2 owned by SYS might be unavailable

関連項目:
DBMS_HMパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ADRCIユーティリティを使用したレポートの表示

ADRCIユーティリティを使用して、状態モニター・チェッカ・レポートを作成および表示できます。

ADRCIを使用してチェッカ・レポートを作成および表示する手順は、次のとおりです。

1. オペレーティング・システム環境変数(ORACLE_HOMEなど)が適切に設定されていることを確認し、次のコマンドをオペレーティング・システムのコマンド・プロンプトに入力します。

ADRCI

ユーティリティが起動し、次のプロンプトが表示されます。

adrci>>

必要に応じて、現行のADRホームを変更できます。すべてのADRホームをリストするにはSHOW HOMESコマンドを、現行のADRホームを変更するにはSET HOMEPATHコマンドを使用します。詳細は、『Oracle Databaseユーティリティ』を参照してください。

2. 次のコマンドを入力します。

show hm_run

このコマンドによって、ADRリポジトリに登録されている(V$HM_RUNに格納された)すべてのチェッカ実行がリストされます。

3. レポートを作成するチェッカ実行を検索し、チェッカ実行名をメモします。このチェッカ実行のレポートがすでに生成されている場合は、REPORT_FILEフィールドにファイル名が表示されます。レポートが生成されていない場合は、次のコマンドを実行してレポートを生成します。

create report hm_run run_name

4. レポートを表示するには、次のコマンドを入力します。

show report hm_run run_name

関連項目:
「自動診断リポジトリ(ADR)」

状態モニターのビュー

チェッカ・レポートを要求するかわりに、レポートが作成されたADRデータを直接問い合せると、特定のチェッカ実行の結果を表示できます。このデータは、V$HM_RUN、V$HM_FINDINGおよびV$HM_RECOMMENDATIONの各ビューを使用して表示できます。

次の例では、V$HM_RUNビューを問い合せて、チェッカ実行の履歴を表示します。

SELECT run_id, name, check_name, run_mode, src_incident FROM v$hm_run;

RUN_ID NAME         CHECK_NAME                         RUN_MODE SRC_INCIDENT
---------- ------------ ---------------------------------- -------- ------------
1 HM_RUN_1     DB Structure Integrity Check       REACTIVE            0
101 HM_RUN_101   Transaction Integrity Check        REACTIVE         6073
121 TXNCHK       Transaction Integrity Check        MANUAL              0
181 HMR_tab$     Dictionary Integrity Check         MANUAL              0
.
.
.
981 Proct_ts$    Dictionary Integrity Check         MANUAL              0
1041 HM_RUN_1041  DB Structure Integrity Check       REACTIVE            0
1061 HM_RUN_1061  Data Block Integrity Check         REACTIVE         7418

次の例では、RUN_ID 1061を指定してV$HM_FINDINGビューを問い合せ、リアクティブなデータ・ブロック・チェックの結果詳細を取得します。

SELECT type, description FROM v$hm_finding WHERE run_id = 1061;

TYPE          DESCRIPTION
------------- -----------------------------------------
FAILURE       Block 64349 in datafile 1: '/u01/app/orac
le/dbs/t_db1.f' is media corrupt

FAILURE       Block 64351 in datafile 1: '/u01/app/orac
le/dbs/t_db1.f' is media corrupt

関連項目:

- 「ヘルス・チェックのタイプ」

- V$HM_*ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ヘルス・チェック・パラメータの参考情報

次の表では、パラメータが必要なヘルス・チェック用のパラメータを説明します。デフォルト値が(なし)のパラメータは必須です。

表9-6 「データ・ブロックの整合性チェック」のパラメータ

パラメータ名

タイプ

デフォルト値

説明

BLC_DF_NUM

数値

(なし)

ブロック・データ・ファイル番号

BLC_BL_NUM

数値

(なし)

データ・ブロック番号

表9-7 「REDOの整合性チェック」のパラメータ

パラメータ名

タイプ

デフォルト値

説明

SCN_TEXT

テキスト

0

最新の良好なREDOのSCN(既知の場合)

表9-8 「UNDOセグメントの整合性チェック」のパラメータ

パラメータ名

タイプ

デフォルト値

説明

USN_NUMBER

テキスト

(なし)

UNDOセグメント番号

表9-9 「トランザクションの整合性チェック」のパラメータ

パラメータ名

タイプ

デフォルト値

説明

TXN_ID

テキスト

(なし)

トランザクションID

表9-10 「ディクショナリの整合性チェック」のパラメータ

パラメータ名

タイプ

デフォルト値

説明

CHECK_MASK

テキスト

ALL

可能な値は次のとおりです。

- COLUMN_CHECKS: 列のチェックのみを実行します。コア・テーブル内の列レベルの制約を検証します。

- ROW_CHECKS: 行のチェックのみを実行します。コア・テーブル内の行レベルの制約を検証します。

- REFERENTIAL_CHECKS: 参照チェックのみを実行します。コア・テーブル内の参照の制約を検証します。

- ALL: すべてのチェックを実行します。

TABLE_NAME

テキスト

ALL_CORE_TABLES

チェックする単一のコア・テーブルの名前。省略すると、すべてのコア・テーブルがチェックされます。

SQL修復アドバイザを使用したSQLエラーの修復

ほとんど発生しませんが、SQL文がクリティカル・エラーで失敗した場合は、SQL修復アドバイザを実行して失敗した文を修復できます。

この項の内容は次のとおりです。

- SQL修復アドバイザの概要

- SQL修復アドバイザの実行

- SQLパッチの表示、無効化または削除

SQL修復アドバイザの概要

SQL修復アドバイザは、重大なエラーが発生してSQL文が失敗した場合に実行します。このアドバイザによって、文が分析され、多くの場合、文を修復するためにパッチの適用が推奨されます。リコメンデーションを実装すると、適用されたSQLパッチによって、問合せオプティマイザで将来実行する場合の代替実行計画が選択され、失敗が回避されます。

SQL修復アドバイザの実行

SQL修復アドバイザは、サポート・ワークベンチの「問題の詳細」ページから実行します。この項の説明は、SQL文によるクリティカル・エラーの通知をすでに受け取り、「問題の調査、レポートおよび解決」で説明したワークフローに従っていることを前提としています。

SQL修復アドバイザを実行する手順は、次のとおりです。

1. 失敗したSQL文に関連する問題の「問題の詳細」ページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

2. 「調査と解決」セクションの「セルフ・サービス」タブにある「解決」ヘッダーで、「SQL修復アドバイザ」をクリックします。

3. 「SQL修復アドバイザ」ページで次の手順を実行します。

1. 必要な場合は現在のタスク名を変更し、必要に応じてタスクの説明を入力し、アドバイザ・タスクのオプションの時間制限を変更またはクリアし、設定を調整してアドバイザを即時に実行するか、後の日時に実行するかをスケジュールします。

2. 「発行」をクリックします。

「処理中」ページが表示されます。その少し後に「SQL修復結果」ページが表示されます。

「SQLパッチ」列のチェック・マークは、推奨事項があることを示します。この列にチェック・マークがない場合は、SQL修復アドバイザがSQL文に対してパッチを提示できなかったことを意味します。

注意:
「SQL修復結果」ページが表示されない場合は、表示するために次の手順を実行します。

1. データベース・ホームページに移動します。

2. 「関連リンク」の下の「アドバイザ・セントラル」をクリックします。

3. 「アドバイザ・セントラル」ページの「結果」リストで、SQL修復アドバイザの最新エントリを探します。

4. そのエントリを選択して「結果の表示」をクリックします。

4. 推奨事項がある場合は、「SQLパッチ」列にチェック・マークが表示されます。推奨事項を参照するには、「表示」をクリックします。
「修復の推奨」ページに、文に対する推奨パッチが表示されます。

5. 「実装」をクリックします。
「SQL修復結果」ページに戻り、確認メッセージが表示されます。

6. (オプション)「SQLワークシートを使用して検証」をクリックして、SQLワークシートの文を実行し、パッチによって文が正常に修復したことを検証します。

SQLパッチの表示、無効化または削除

SQL修復アドバイザを使用してSQLパッチを適用した後は、そのSQLパッチを表示してパッチが適用されたことを確認したり、パッチを無効化または削除できます。パッチを削除する理由の1つに、後続リリースのOracle Databaseをインストールし、パッチを適用したSQL文でエラーが発生した不具合が修正されている場合があります。

SQLパッチを表示、無効化または削除する手順は、次のとおりです。

1. Enterprise Managerのデータベース・ホームページにアクセスします。
Oracle Enterprise Manager Database Controlの場合、手順については『Oracle Database 2日でデータベース管理者』を参照してください。Oracle Enterprise Manager Grid Controlの場合は、対象のデータベース・ターゲットに進みます。

2. ページの上部で、「サーバー」をクリックし、「サーバー」ページを表示します。

3. 「問合せオプティマイザ」セクションで、「SQL計画管理」をクリックします。
「SQL計画管理」ページが表示されます。このページの詳細は、オンライン・ヘルプを参照してください。

4. ページの上部にある「SQLパッチ」をクリックして「SQLパッチ」サブページを表示します。
「SQLパッチ」サブページに、データベース内のすべてのSQLパッチが表示されます。

5. 関連するSQLテキストを検証して、特定のパッチを検索します。
SQLテキストをクリックして、その文の完全なテキストを表示します。

6. パッチを無効化するには、パッチを選択して「無効化」をクリックします。
確認メッセージが表示され、パッチのステータスがDISABLEDに変更されます。後でパッチを再び有効にするには、パッチを選択して「有効化」をクリックします。

7. パッチを削除するには、パッチを選択して「削除」をクリックします。
確認メッセージが表示されます。

関連項目:
「SQL修復アドバイザの概要」

データ・リカバリ・アドバイザを使用したデータ破損の修復

データ・ブロックの破損、UNDO破損、データ・ディクショナリの破損などを修復するには、データ・リカバリ・アドバイザを使用します。データ・リカバリ・アドバイザはEnterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)、状態モニターおよびRMANユーティリティに統合され、データ破損の問題の表示、各問題の程度の評価(クリティカル、高優先度、低優先度)、問題の影響の説明、修復オプションの推奨、顧客が選択したオプションの実行可能性チェック、および修復プロセスの自動化を実行します。

ここでは、サポート・ワークベンチからアドバイザにアクセスする方法をいくつか説明します。データ・リカバリ・アドバイザは、次の情報を表示したときにサポート・ワークベンチによって自動的に推奨され、サポート・ワークベンチからアクセスできます。

- データ破損またはその他のデータ障害に関連する問題の詳細。

- データ破損またはその他のデータ障害に関連するヘルス・チェック結果。

データ・リカバリ・アドバイザは「アドバイザ・セントラル」ページからも使用できます。このページへのリンクは、データベース・ホームページおよび「パフォーマンス」ページの「関連リンク」セクションにあります。

注意:
データ・リカバリ・アドバイザを使用できるのは、SYSDBAとして接続している場合のみです。

サポート・ワークベンチからデータ・リカバリ・アドバイザにアクセスする方法は次のとおりです。

- 「問題の詳細」ページからのアクセス

「調査と解決」セクションの「データ・リカバリ・アドバイザ」リンクをクリックします。

このページへのアクセス手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

- 「サポート・ワークベンチ」ホームページの「チェッカ結果」サブページからのアクセス

1つ以上のデータ破損結果を選択して、「リカバリ・アドバイザの起動」をクリックします。

「サポート・ワークベンチ」ホームページへのアクセス手順については、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

関連項目:
データ・リカバリ・アドバイザの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

カスタム・インシデント・パッケージの作成、編集およびアップロード

Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用して、カスタム・インシデント・パッケージを作成、編集およびアップロードできます。カスタム・インシデント・パッケージにより、Oracleサポート・サービスに送信する診断データを詳細に制御できます。

この項の内容は、次のとおりです。

- インシデント・パッケージの概要

- カスタム・パッケージングを使用した問題のパッケージ化とアップロード

- インシデント・パッケージの表示と変更

- 相関パッケージの作成、編集およびアップロード

- 相関パッケージの削除

- インシデント・パッケージのプリファレンスの設定

関連項目:
「Oracle Databaseの障害診断インフラストラクチャの概要」

インシデント・パッケージの概要

診断データをカスタマイズしてOracleサポート・サービスにアップロードするには、最初に、インシデント・パッケージ(パッケージ)と呼ばれる中間論理構造にデータを収集します。パッケージは自動診断リポジトリ(ADR)に格納されているメタデータの集合で、ADR内外の診断データファイルやその他のファイルを指し示します。パッケージを作成するときは、そのパッケージに追加する問題を1つ以上選択します。次に、サポート・ワークベンチによって、選択した問題に関連する問題情報、インシデント情報および診断データ(トレース・ファイル、ダンプなど)がパッケージに自動的に追加されます。1つの問題に対して多数のインシデント(同じ問題の多数の発生)が存在する場合があるため、デフォルトでは、各問題の最初の3つと最後の3つのインシデントのみがパッケージに追加され、発生から90日を超えるインシデントは除外されます。このデフォルトの数は、サポート・ワークベンチの「インシデント・パッケージング構成」ページで変更できます。

パッケージが作成されたら、あらゆるタイプの外部ファイルをパッケージに追加し、パッケージから選択したファイルを削除し、重要なデータを削除するパッケージ内の選択したファイルを編集できます。パッケージの内容を追加および削除する場合は、パッケージのメタデータのみが変更されます。

診断データをOracleサポート・サービスにアップロードする準備ができたら、最初に、パッケージのメタデータで参照されるすべてのファイルを含めてZIPファイルを作成します。次に、Oracle Configuration Managerを使用してそのZIPファイルをアップロードします。

注意:
Oracle Configuration Managerをインストールしていないか、適切に構成していない場合は、My Oracle Supportを使用してZIPファイルを手動でアップロードする必要があります。
Oracle Configuration Managerの詳細は、『Oracle Configuration Managerインストレーションおよび管理ガイド』を参照してください。

次の各項では、パッケージの詳細を説明します。

- インシデント・パッケージ内の関係付けられた診断データの概要

- クイック・パッケージングとカスタム・パッケージングの概要

- 相関パッケージの概要

関連項目:

- 「カスタム・パッケージングを使用した問題のパッケージ化とアップロード」

- 「インシデント・パッケージの表示と変更」

インシデント・パッケージ内の関係付けられた診断データの概要

問題を診断するには、問題に直接関連する診断データのみでなく、直接関連するデータと相関する診断データも調べる必要がある場合があります。診断データは、時間、プロセスIDまたはその他の基準によって関係付けることができます。たとえば、インシデントの検証では、そのインシデントの5分後に発生したインシデントの検証も役立つ場合があります。同様に、インシデントの診断データには、インシデント発生時に実行されていたOracle Databaseプロセスのトレース・ファイルが含まれていることは明確ですが、元のプロセスに関連する他のプロセスのトレース・ファイルを含めることが役に立つ場合もあります。

このため、問題とそれに関連するインシデントがパッケージに追加されるときは、同時に、関連するトレース・ファイルとともに関係付けられたインシデントが追加されます。

パッケージの物理ファイルを作成する過程で、サポート・ワークベンチはインシデント・パッケージング・サービスを要求してパッケージをファイナライズします。ファイナライズとは、パッケージ内のインシデントに時間で関係付けられた追加のトレース・ファイル、および他の診断情報(アラート・ログ、ヘルス・チェッカ・レポート、SQLテスト・ケース、構成情報など)をパッケージに追加することを意味します。そのため、ZIPファイル内のファイル数が、サポート・ワークベンチでパッケージ・コンテンツとして表示されたファイルの数より多くなる場合があります。

インシデント・パッケージング・サービスは一連のルールに従って、既存のパッケージ・データに関係付けるADR内のトレース・ファイルを決定します。一部のルールは、Enterprise Managerの「インシデント・パッケージング構成」ページで変更できます。

当初のパッケージ・データと関係付けられた追加データには機密情報が含まれている可能性があるため、Oracleサポート・サービスにアップロードする前に、このような機密情報を含むファイルを削除または編集することが重要です。このため、サポート・ワークベンチでは、パッケージをファイナライズするコマンドを独立した操作として実行できます。パッケージを手動でファイナライズした後は、パッケージ・コンテンツを検証し、ファイルを削除または編集してから、ZIPファイルを生成してアップロードできます。

注意:
パッケージのファイナライズは、パッケージがクローズして変更不可になることではありません。ファイナライズしたパッケージには、引続き診断データを追加できます。また、同じパッケージを複数回ファイナライズすることもできます。ファイナライズするたびに、関係付けられた新しいデータが追加されます。

関連項目:
「インシデント・パッケージのプリファレンスの設定」

クイック・パッケージングとカスタム・パッケージングの概要

Enterprise Managerサポート・ワークベンチには、インシデント・パッケージを作成してアップロードする方法として、クイック・パッケージング方法とカスタム・パッケージング方法があります。

クイック・パッケージング: 最小限のステップがある自動化された方法で、ガイド付きワークフロー(ウィザード)に編成されています。1つの問題を選択してパッケージ名と説明を入力し、パッケージ・コンテンツのアップロードを即時に実行するか、指定の日時に実行するかをスケジュールします。サポート・ワークベンチでは、問題に関連する診断データを自動的にパッケージに追加してファイナライズし、ZIPファイルを作成してアップロードします。この方法では、パッケージ・ファイルを追加、編集または削除したり、SQLテスト・ケースなどの他の診断データを追加することはできません。ただし、この方法は、初期障害診断データをOracleサポート・サービスにアップロードする最も簡単かつ迅速な方法です。クイック・パッケージングは、「問題の調査、レポートおよび解決」で示すワークフローで使用される方法です。

クイック・パッケージングが完了した後、ウィザードで作成されたパッケージはそのまま残ることに注意してください。このパッケージは、カスタム・パッケージング操作を使用して後で変更し、手動で再アップロードできます。

カスタム・パッケージング: 手順が多く、より詳細な手動の方法です。これは、パッケージング・プロセスの詳細な制御を行うエキスパートのサポート・ワークベンチ・ユーザーを対象としています。カスタム・パッケージングでは、1つ以上の問題のある新規パッケージを作成、または1つ以上の問題を既存のパッケージに追加できます。これらの各種の操作を新規または更新されたパッケージで実行でき、これには次の操作が含まれます。

- 問題やインシデントを追加または削除できます。

- パッケージに対してトレース・ファイルを追加、編集または削除できます。

- 任意のタイプの外部ファイルを追加または削除できます。

- その他の診断データ(SQLテスト・ケースなど)を追加できます。

- パッケージを手動でファイナライズしてからパッケージ・コンテンツを表示して、機密データを編集または削除する必要があるか、ファイルを削除してパッケージ・サイズを縮小する必要があるかを決定できます。

これらの操作には、Oracleサポートに送信する診断情報が十分であることを確認するまで、数日間かかる場合があります。

カスタム・パッケージングでは、ZIPファイルの作成とOracleサポート・サービスへのアップロードを、2つの独立したステップとして実行できます。各ステップは、即時に実行するか、日時をスケジュールして実行できます。

関連項目:
クイック・パッケージング方法の手順については、「タスク5: 診断データのパッケージ化とOracleサポート・サービスへのアップロード」を参照してください。

相関パッケージの概要

相関パッケージは、関連する問題に対して診断データのパッケージングおよびアップロードのための手段を提供します。「トポロジ全体に関連する問題」で示すとおり、データベース・インスタンスの問題に関連する問題が他のデータベース・インスタンスやOracle Automatic Storage Managementインスタンスにもある場合があります。データベース・インスタンスの問題に対するパッケージ(メイン・パッケージ)を作成およびアップロードした後、関連する問題についての相関パッケージを作成およびアップロードできます。これは、Enterprise Managerのサポート・ワークベンチのカスタム・パッケージング・ワークフローでのみ実行できます。

関連項目:
「相関パッケージの作成、編集およびアップロード」

カスタム・パッケージングを使用した問題のパッケージ化とアップロード

Enterprise Managerサポート・ワークベンチ(サポート・ワークベンチ)を使用して、カスタム・インシデント・パッケージ(パッケージ)を作成およびアップロードできます。アップロードする前に、診断データ・ファイルをパッケージから手動で追加、編集、および削除できます。

カスタム・パッケージングを使用して問題をパッケージ化およびアップロードする手順は、次のとおりです。

1. 「サポート・ワークベンチ」ホームページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

2. (オプション)パッケージに含める各問題について、問題に関連付けられているサービス・リクエスト番号(SR#)を指定します(ある場合)。指定するには、各問題について次の手順を実行します。

1. 「サポート・ワークベンチ」ホームページの下部にある「問題」サブページで、問題を選択して「表示」をクリックします。

注意:
問題のリストに対象の問題がみつからない場合、または問題数が多くてスクロールできない場合は、「表示」リストから期間を選択して「実行」をクリックします。対象の問題を選択して「表示」をクリックします。

問題の詳細ページが表示されます。

2. SR#ラベルの横にある「編集」をクリックし、サービス・リクエスト番号を入力して、「OK」をクリックします。
「問題の詳細」ページにサービス・リクエスト番号が表示されます。

3. ページの上部にあるロケータ・リンクで「サポート・ワークベンチ」をクリックし、「サポート・ワークベンチ」ホームページに戻ります。

3. 「サポート・ワークベンチ」ホームページで、パッケージ化する問題を選択して「パッケージ」をクリックします。
「パッケージング・モードの選択」ページが表示されます。

注意:
パッケージング・プロセスでは、関係付けられた追加の問題を自動的に選択してパッケージに追加できます。関係付けられた問題の例には、選択した問題の数分後に発生した問題があります。詳細は、「インシデント・パッケージ内の関係付けられた診断データの概要」を参照してください。

4. 「カスタム・パッケージング」オプションを選択して「続行」をクリックします。
「カスタム・パッケージング: パッケージの選択」ページが表示されます。

図9-6 「カスタム・パッケージング: パッケージの選択」ページ

5. 次のいずれかを実行します。

- 新規パッケージを作成するには、「新規パッケージの作成」オプションを選択し、パッケージ名と説明を入力して「OK」をクリックします。

- 選択した問題を既存のパッケージに追加するには、「既存パッケージからの選択」オプションを選択し、更新するパッケージを選択して「OK」をクリックします。

「パッケージのカスタマイズ」ページが表示されます。選択するパッケージ・タスクのセレクションに加え、パッケージに含まれている問題およびインシデントが表示されます。新しいパッケージまたは更新した既存パッケージに対して実行できます。

図9-7 「パッケージのカスタマイズ」ページ

6. (オプション)「パッケージング・タスク」セクションで、リンクをクリックして1つ以上のパッケージング・タスクを実行します。または、「パッケージのカスタマイズ」ページとそのサブページにある他のコントロールを使用して、パッケージを操作します。完了後に「パッケージのカスタマイズ」ページに戻ります。
いくつかの一般的なパッケージング・タスクの手順については、「インシデント・パッケージの表示と変更」を参照してください。

7. 「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションで、「Oracleサポートに送信」ヘッダー下にある「コンテンツ準備の終了」をクリックしてパッケージをファイナライズします。
パッケージに含まれるファイルのリスト(または部分的なリスト)が表示されます。(これには少し時間がかかる場合があります。)リストには、相関診断情報を含むかどうかを識別し、終了プロセスによって追加されたファイルが含まれます。

パッケージのファイナライズの定義については、「インシデント・パッケージ内の関係付けられた診断データの概要」を参照してください。

8. 「ファイル」リンクをクリックして、パッケージ内のすべてのファイルを表示します。リストを検証して、公開できない機密データのファイルがあるかどうかを確認します。該当するファイルがみつかった場合は、そのファイルを除外(削除)または編集します。
ファイルを編集および削除する手順については、「インシデント・パッケージ・ファイルの編集(コピー・アウトとコピー・イン)」および「インシデント・パッケージ・ファイルの削除」を参照してください。

ファイルの内容を表示するには、ファイルの表の右側の列にある眼鏡アイコンをクリックします。ホスト資格証明を入力します(要求された場合)。

注意:
通常、トレース・ファイルはOracle内部でのみ使用します。

9. 「アップロード・ファイルの生成」をクリックします。
「アップロード・ファイルの生成」ページが表示されます。

10. 「全体」または「増分」オプションを選択して、全パッケージのZIPファイルまたは増加分パッケージのZIPファイルを生成します。
全パッケージのZIPファイルの場合は、常にパッケージのすべてのコンテンツ(元のコンテンツおよび関係付けられたすべてのデータ)がZIPファイルに追加されます。

増加分パッケージのZIPファイルの場合は、同じパッケージのZIPファイルが最後に作成された時点以降に新規追加または変更された診断情報のみがZIPファイルに追加されます。たとえば、パッケージに対して生成された物理ファイルにトレース・ファイルが最後に追加された時点以降にトレース情報がそのトレース・ファイルに追加された場合は、そのトレース・ファイルが増加分パッケージのZIPファイルに追加されます。逆に、パッケージに対して最後にアップロードした時点以降にトレース・ファイルを変更していない場合、そのトレース・ファイルは増加分パッケージのZIPファイルに追加されません。

注意:
パッケージに対してアップロード・ファイルが作成されていない場合、「増分」オプションは使用不可になります。

11. ファイル作成を即時実行するか、後の日時に実行するかをスケジュールして(「即時」または「後で」を選択)、「発行」をクリックします。
ファイル作成ではシステム・リソースを大量に使用する場合があるため、ファイルの作成は、システム使用量が少ない時期にスケジュールすることをお薦めします。

「処理中」ページが表示され、ZIPファイルが作成されます。処理が完了すると、確認ページが表示されます。

注意:
ZIPファイルが作成されると、パッケージは自動的にファイナライズされます。

12. 「OK」をクリックします。
「パッケージのカスタマイズ」ページに戻ります。

13. 「Oracleに送信」をクリックします。
「アップロード・ファイルの表示/送信」ページが表示されます。

14. (オプション)相関パッケージを作成してオラクル社に送信するには、「相関パッケージの送信」リンクをクリックします。
「相関パッケージの作成、編集およびアップロード」を参照してください。相関パッケージに対する作業が完了した後、ページの上部にある「パッケージの詳細」リンクをクリックし、「パッケージのカスタマイズ」をクリックし、次に、再度「Oracleに送信」をクリックして、「アップロード・ファイルの表示/送信」ページに戻ります。

15. アップロードするZIPファイルを選択して「Oracleに送信」をクリックします。
「Oracleに送信」ページが表示されます。選択したZIPファイルが表にリストされます。

16. 要求されたMy Oracle Support情報を入力します。「新規サービス・リクエスト(SR)の作成」の横にある「はい」または「いいえ」を選択します。「はい」を選択すると、ドラフトのサービス・リクエストが作成されます。この場合は、後でMy Oracle Supportにログインして、サービス・リクエストの詳細を入力する必要があります。「いいえ」を選択した場合は、既存のサービス・リクエスト番号を入力します。

17. アップロードを即時または後の日時にスケジュールして、「発行」をクリックします。
「処理中」ページが表示されます。アップロードが正常に完了した場合は、確認ページが表示されます。アップロードが完了できなかった場合は、エラー・ページが表示されます。エラー・ページには、ZIPファイルをOracleに手動でアップロードするように要求するメッセージが表示される場合があります。その場合の手順については、Oracleサポート・サービス担当者に問い合せてください。

18. 「OK」をクリックします。
「アップロード・ファイルの表示/送信」ページに戻ります。「送信時刻」列で、アップロードしたファイルのステータスをチェックします。

注意:
サポート・ワークベンチでは、Oracle Configuration Managerを使用して物理ファイルをアップロードします。Oracle Configuration Managerがインストールされていなかったり、適切に構成されていないと、アップロードに失敗する場合があります。失敗した場合は、ファイルをOracleサポート・サービスに手動でアップロードするように要求するメッセージが、パッケージのZIPファイルへのパスとともに表示されます。アップロードは、My Oracle Supportを使用して手動で実行できます。
Oracle Configuration Managerの詳細は、『Oracle Configuration Managerインストレーションおよび管理ガイド』を参照してください。

19. (オプション)相関パッケージを作成およびアップロードします。
手順については、「相関パッケージの作成、編集およびアップロード」を参照してください。

関連項目:

- 「インシデントおよび問題の概要」

- 「インシデント・パッケージの概要」

- 「クイック・パッケージングとカスタム・パッケージングの概要」

インシデント・パッケージの表示と変更

カスタム・パッケージング方法を使用してインシデント・パッケージを作成した後は、Oracleサポート・サービスへのアップロード前に、そのパッケージのコンテンツを表示または変更できます。さらに、クイック・パッケージング方法を使用して診断データをパッケージ化してアップロードした後は、サポート・ワークベンチで作成したパッケージのコンテンツを表示または変更して、パッケージを再アップロードできます。パッケージを変更するには、パッケージ・タスクの選択対象から選択しますが、それらのほとんどは「パッケージのカスタマイズ」ページで使用できます。(図9-7を参照。)

この項では、最も一般的なパッケージ・タスクの一部について説明します。内容は次のとおりです。

- インシデント・パッケージ・ファイルの編集(コピー・アウトとコピー・イン)

- インシデント・パッケージへの外部ファイルの追加

- インシデント・パッケージ・ファイルの削除

- インシデント・パッケージのアクティビティ・ログの表示と更新

また、次の各項では、パッケージの詳細の表示方法、特定のパッケージの「パッケージのカスタマイズ」ページにアクセスする方法について説明します。

- パッケージの詳細の表示

- 「パッケージのカスタマイズ」ページへのアクセス

関連項目:

- 「インシデント・パッケージの概要」

- 「カスタム・パッケージングを使用した問題のパッケージ化とアップロード」

パッケージの詳細の表示

「パッケージの詳細」ページには、パッケージ内のインシデント、トレース・ファイルおよびその他のファイルに関する情報が表示され、アクティビティ・ログを表示してパッケージに追加できます。

パッケージの詳細を表示する手順は、次のとおりです。

1. 「サポート・ワークベンチ」ホームページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

2. 「パッケージ」リンクをクリックして「パッケージ」サブページを表示します。
自動診断リポジトリ(ADR)に現時点で格納されているパッケージのリストが表示されます。

3. (オプション)表示するパッケージの数を減らすには、リストの上部にある「検索」フィールドにテキストを入力して「実行」をクリックします。
パッケージ名に検索テキストが含まれているパッケージがすべて表示されます。全パッケージのリストを表示するには、「パッケージ」リンクを再度クリックします。

4. 「パッケージ名」列で、対象のパッケージのリンクをクリックします。
「パッケージの詳細」ページが表示されます。

「パッケージのカスタマイズ」ページへのアクセス

「パッケージのカスタマイズ」ページでは、各種のパッケージング・タスク(問題の追加および削除、パッケージ・ファイルの追加、削除および修正(編集)、パッケージのZIPファイルの生成およびアップロードなど)を実行します。

「パッケージのカスタマイズ」ページにアクセスする手順は、次のとおりです。

1. 「パッケージの詳細の表示」で説明するように、特定のパッケージの「パッケージの詳細」ページにアクセスします。

2. 「パッケージのカスタマイズ」をクリックします。
「パッケージのカスタマイズ」ページが表示されます。図9-7を参照してください。

インシデント・パッケージ・ファイルの編集(コピー・アウトとコピー・イン)

サポート・ワークベンチを使用すると、インシデント・パッケージ内の1つ以上のファイルを編集できます。この作業は、ファイル内の機密データを削除または上書きする場合に必要です。パッケージ・ファイルを編集するには、最初にパッケージから宛先ディレクトリにファイルをコピー・アウトし、テキスト・エディタまたは他のユーティリティを使用して編集してから、そのファイルをパッケージにコピーし直して、元のパッケージ・ファイルを上書きします。

次の手順では、パッケージがすでに作成されて診断データが格納されていることを前提としています。

インシデント・パッケージ・ファイルを編集する手順は、次のとおりです。

1. 対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。

2. 「パッケージング・タスク」セクションで、「ユーザー・データの修正」ヘッダー下にある「コンテンツ編集のためのファイルのコピー・アウト」をクリックします。
ファイルのコピー・アウト・ページが表示されます。ファイルをコピーできるホスト名が表示されます。

図9-8 「ファイルのコピー・アウト」ページ

3. 次のいずれかを実行して、ファイルの宛先ディレクトリを指定します。

- 「宛先フォルダ」フィールドにディレクトリ・パスを入力します。

- 「宛先フォルダ」フィールドの横にある懐中電灯アイコンをクリックして、次の手順を実行します。

1. ホスト資格証明がプロンプトで要求された場合は、ファイルのコピー・アウト先のホストの資格証明を入力して、「OK」をクリックします。(「優先資格証明として保存」を選択すると次回から資格証明を要求するプロンプトが表示されなくなります)。

2. 「参照および選択: ファイルまたはディレクトリ」ウィンドウで、ディレクトリ・リンクをクリックしてディレクトリ階層の下位に移動するか、「パス」ラベルの横にあるディレクトリ名をクリックしてディレクトリ階層の上位に移動して、対象の宛先ディレクトリを検索します。

リストに表示するディレクトリの数を減らすには、「検索」フィールドに検索テキストを入力して「実行」をクリックします。ディレクトリ名に検索テキストが含まれているディレクトリがすべて表示されます。

3. 対象の宛先ディレクトリを選択して「選択」をクリックします。
「参照および選択: ファイルまたはディレクトリ」ウィンドウがクローズし、選択したディレクトリへのパスが「ファイルのコピー・アウト」ページの「宛先フォルダ」フィールドに表示されます。

4. 「コピー・アウトするファイル」で、対象のファイルを選択して「OK」をクリックします。

注意:
対象のファイルがみつからない場合は、別のページにある場合があります。「次」リンクをクリックして、次のページを表示します。対象のファイルがみつかるまで、「次」をクリックし続けるか、ファイル番号のリスト(「次」リンクの左側)から番号を選択します。ファイルを選択して「OK」をクリックします。

「パッケージのカスタマイズ」ページに戻ると、コピー・アウトされたファイルをリストした確認メッセージが表示されます。

5. テキスト・エディタまたは他のユーティリティを使用して、ファイルを編集します。

6. 「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションで、「ユーザー・データの修正」ヘッダー下にある「コンテンツ置換えのためのファイルのコピー・イン」をクリックします。
ファイルのコピー・イン・ページが表示されます。コピーしたファイルが表示されます。

7. コピー・インするファイルを選択して「OK」をクリックします。
ファイルがパッケージにコピー・インされて、既存のファイルが上書きされます。「パッケージのカスタマイズ」ページに戻ると、コピー・インされたファイルをリストした確認メッセージが表示されます。

インシデント・パッケージへの外部ファイルの追加

インシデント・パッケージには、任意のタイプの外部ファイルを追加できます。

外部ファイルをインシデント・パッケージに追加する手順は、次のとおりです。

1. 対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。

2. 「ファイル」リンクをクリックして「ファイル」サブページを表示します。

図9-9 「パッケージのカスタマイズ」ページの「ファイル」サブページ

このページでは、パッケージに対してファイルを追加または削除できます。

3. 「外部ファイルの追加」をクリックします。
外部ファイルの追加ページが表示されます。これには選択したファイルからホスト名が表示されます。

4. 次のいずれかを実行して、追加するファイルを指定します。

- 「ファイル名」フィールドに、ファイルへのフルパスを入力します。

- 「ファイル名」フィールドの横にある懐中電灯アイコンをクリックして、次の手順を実行します。

1. ホスト資格証明がプロンプトで要求された場合は、外部ファイルが存在するホストの資格証明を入力して、「OK」をクリックします。(「優先資格証明として保存」を選択すると次回から資格証明を要求するプロンプトが表示されなくなります)。

2. 「参照および選択: ファイルまたはディレクトリ」ウィンドウで、ディレクトリ・リンクをクリックしてディレクトリ階層の下位に移動するか、「パス」ラベルの横にあるディレクトリ名をクリックしてディレクトリ階層の上位に移動して、対象のファイルを検索します。

リストに表示するファイルまたはディレクトリの数を減らすには、「検索」フィールドに検索テキストを入力して「実行」をクリックします。ファイル名またはディレクトリ名に検索テキストが含まれているファイルまたはディレクトリがすべて表示されます。

3. 「選択」列で、対象のファイルをクリックして選択し、「選択」をクリックします。
「参照および選択」ウィンドウがクローズし、選択したファイルへのパスが「外部ファイルの追加」ページの「ファイル名」フィールドに表示されます。

5. 「OK」をクリックします。
「パッケージのカスタマイズ」ページに戻ると、「ファイル」サブページが表示されます。これで、選択したファイルがファイル・リストに表示されます。

インシデント・パッケージ・ファイルの削除

インシデント・パッケージから任意のタイプのファイルを1つ以上削除できます。

インシデント・パッケージ・ファイルを削除する手順は、次のとおりです。

1. 対象のインシデント・パッケージの「パッケージのカスタマイズ」ページにアクセスします。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。

2. 「ファイル」リンクをクリックして「ファイル」サブページを表示します。
パッケージに含まれているファイルのリストが表示されます。

パッケージの物理ファイルをまだ生成していない場合、すべてのパッケージ・ファイルがリストに表示されます。すでに物理ファイルを生成している場合、ファイル・リストの上部に「表示」リストが表示されます。ここで、増分パッケージのコンテンツのみを表示するか、パッケージの内容すべてを表示するかを選択できます。デフォルトではパッケージの内容の増分を表示します。このデフォルト設定では、パッケージの物理ファイルが最後に生成されたとき以降に作成または変更されたパッケージ・ファイルのみが表示されます。すべてのパッケージ・ファイルを表示するには、「表示」リストから「全パッケージ・コンテンツ」を選択します。

3. 削除するファイルを選択して「除外」をクリックします。

注意:
対象のファイルがみつからない場合は、別のページにある場合があります。「次」リンクをクリックして、次のページを表示します。対象のファイルがみつかるまで、「次」をクリックし続けるか、ファイル番号のリスト(「次」リンクの左側)から番号を選択します。ファイルを選択して「削除」をクリックします。

インシデント・パッケージのアクティビティ・ログの表示と更新

サポート・ワークベンチでは、インシデント・パッケージごとにアクティビティ・ログが保持されます。パッケージに対して実行したほとんどのアクティビティ(ファイルの追加や削除、パッケージのZIPファイルの作成など)はログに記録されます。独自のノートをログに追加することもできます。特に、これは、複数のデータベース管理者がパッケージを使用している場合に役立ちます。

インシデント・パッケージのアクティビティ・ログを表示および更新する手順は、次のとおりです。

1. 対象のインシデント・パッケージの「パッケージの詳細」ページにアクセスします。
手順については、「「パッケージのカスタマイズ」ページへのアクセス」を参照してください。

2. 「アクティビティ・ログ」リンクをクリックして、「アクティビティ・ログ」サブページを表示します。
アクティビティ・ログが表示されます。

3. 独自のノートをアクティビティ・ログに追加するには、「ノート」フィールドにテキストを入力して「ノートの追加」をクリックします。
ノートの日時が記録され、リストに追加されます。

相関パッケージの作成、編集およびアップロード

Oracleサポート・サービスにパッケージをアップロードした後、1つ以上の相関パッケージを作成およびアップロードできます。データベース・ホームページの「関連アラート」セクションにクリティカル・アラートが表示されている場合は上記をお薦めします。相関パッケージは、メイン・パッケージと呼ばれる元のパッケージと関連付けられています。メイン・パッケージには、データベース・インスタンス内で発生した問題が含まれます。相関パッケージには、他のインスタンス(Oracle ASMインスタンスやその他のデータベース・インスタンス)で発生した問題や、メイン・パッケージにある問題に関連する問題が含まれます。相関パッケージは、関連するインスタンスにそれぞれ1つのみ存在できます。

相関パッケージを作成、編集およびアップロードする手順は、次のとおりです。

1. メイン・パッケージの「パッケージの詳細」ページを表示します。
手順については、「パッケージの詳細の表示」を参照してください。

2. 「パッケージの詳細」ページ上で「パッケージのカスタマイズ」をクリックします。

3. 「パッケージのカスタマイズ」ページの「パッケージング・タスク」セクションの「追加の診断データ」で、「相関パッケージの作成/更新」をクリックします。
図9-7を参照してください。

4. 「相関パッケージ」ページの「相関パッケージ」で、インシデントのあるインスタンスを1つ以上選択して「作成」をクリックします。
確認メッセージが表示され、新規に作成された相関パッケージのパッケージIDが「ID」列に表示されます。

5. 相関パッケージを作成したインスタンスを選択し、「コンテンツ準備の終了」をクリックします。
確認メッセージが表示されます。

6. (オプション)次の手順で相関パッケージを表示および編集します。

1. パッケージIDをクリックしてパッケージを表示します。
資格証明を要求された場合は、「ログイン」をクリックします。

2. 「パッケージの詳細」ページで「ファイル」をクリックしてパッケージ内のファイルを表示します。

3. 「パッケージのカスタマイズ」をクリックして、「インシデント・パッケージの表示と変更」に示すカスタマイズのタスクのうち必要なものを実行します。

7. アップロードするそれぞれの相関パッケージについて、「アップロード・ファイルの生成」をクリックします。

8. オラクル社に送信するそれぞれの相関パッケージについて、「Oracleに送信」をクリックします。

注意:
「Oracleに送信」が使用できない場合は、そのインスタンスに対して関連付けられたインシデントはありません。

関連項目:

- 「相関パッケージの概要」

- 「トポロジ全体に関連する問題」

相関パッケージの削除

相関パッケージは、そのパッケージを作成したターゲットのEnterprise Managerサポート・ワークベンチで削除します。たとえば、Oracle ASMインスタンス・ターゲットに対して相関パッケージを作成した場合は、そのOracle ASMインスタンスのサポート・ワークベンチにアクセスします。

相関パッケージを削除する手順は、次のとおりです。

1. 相関パッケージを作成したターゲットのサポート・ワークベンチにアクセスします。

ヒント:
サポート・ワークベンチのページ下部の「関連リンク」セクションを参照してください。または、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

2. 「パッケージ」をクリックして「パッケージ」のサブページを表示します。

3. リストから、相関パッケージを検索します。パッケージの説明を表示し、相関パッケージであることを確認します。

4. パッケージを選択して「削除」をクリックします。

5. 確認ページで「はい」をクリックします。

関連項目:

- 「相関パッケージの概要」

- 「トポロジ全体に関連する問題」

インシデント・パッケージのプリファレンスの設定

ここでは、インシデント・パッケージのプリファレンスを設定する手順について説明します。インシデント・パッケージのプリファレンスの例には、インシデント情報を保持する日数や、各問題のパッケージに含める最初と最後のインシデント数などがあります。(デフォルトでは、問題のインシデントが多数存在する場合、最初の3つと最後の3つのインシデントのみがパッケージ化されます。)これらのインシデントやその他のインシデント・パッケージのプリファレンスは、Enterprise ManagerまたはADRCIユーティリティを使用して変更できます。

Enterprise Managerを使用してインシデント・パッケージのプリファレンスを設定する手順は、次のとおりです。

1. 「サポート・ワークベンチ」ホームページにアクセスします。
詳細は、「Enterprise Managerサポート・ワークベンチを使用した問題の表示」を参照してください。

2. ページの下部にある「関連リンク」セクションで、「インシデント・パッケージング構成」をクリックします。
「インシデント・パッケージング構成の表示」ページが表示されます。「ヘルプ」をクリックして、このページの設定の説明を表示します。

3. 「編集」をクリックします。
「インシデント・パッケージング構成の編集」ページが表示されます。

4. 設定を編集し、「OK」をクリックして変更を適用します。

関連項目:

- 「インシデント・パッケージの概要」

- 「インシデントおよび問題の概要」

- タスク5: 診断データのパッケージ化とOracleサポート・サービスへのアップロード

- ADRCIの詳細は、『Oracle Databaseユーティリティ』を参照してください。

10 Oracle Enterprise Manager Database Controlの管理

この章の内容は、次のとおりです。

- Database Controlの概要

- インストール中およびインストール後のDatabase Controlの構成

- Database Controlの管理

- Oracle RAC環境でのDatabase Controlの管理

- Database Controlオブジェクトの削除と作成

- EMCAトラブルシューティングのヒント

Database Controlの概要

この章では、WebベースのインタフェースとしてOracleデータベースを管理するための主要ツールとなる、Oracle Enterprise Manager Database Control(Database Control)の機能および管理について説明します。Database Controlを使用すると、スキーマ・オブジェクト(表、ビュー、索引など)の作成、ユーザー・セキュリティの管理、データベースのメモリーとストレージの管理、データベースのバックアップとリカバリ、データのインポートとエクスポートなどの管理タスクを実行できます。また、データベースのパフォーマンスおよびステータス情報を表示できます。

Oracle Databaseソフトウェアをインストールし、データベースを作成またはアップグレードしてネットワークを構成すると、データベースの管理にDatabase Controlを使用できます。また、Database Controlには、パフォーマンス・アドバイザとSQL*LoaderやRecovery Manager(RMAN)などのOracleユーティリティの両方に対するインタフェースも備えられています。

Oracleは、Oracle Enterprise Manager管理パッケージ、管理プラグイン、および特定の環境でのOracle Enterprise Manager機能拡張用に購入できるその他の製品をそれぞれ個別のライセンスで提供しています。

Enterprise Managerのディレクトリについて

Oracle Databaseをインストールすると、デフォルトでDatabase Controlもインストールされます。このため、Oracle Databaseのインストール手順を実行すると、Enterprise Managerのディレクトリおよびファイルが$ORACLE_HOMEディレクトリにインストールされます。

特に、Database Controlを制御するために必要なemctlコマンドが、$ORACLE_HOME/binディレクトリにインストールされます。

管理エージェントおよび管理サービスのサポート・ファイルは、Oracle Databaseをインストールするとき、2つの場所にインストールされます。

- データベースのすべてのインスタンスに共通し、共有されるファイルは、次のディレクトリに格納されます。

- $ORACLE_HOME/sysman
たとえば、管理ファイルは管理対象となるタイプおよび管理エージェント構成タスクの実行に使用されるスクリプトを定義するファイルであり、$ORACLE_HOME/sysman/adminディレクトリに格納されます。

- データベースの各インスタンスに固有のファイルは、次のディレクトリに格納されます。

- $ORACLE_HOME/hostname_dbuniquename/(単一インスタンス・データベースの場合)

- $ORACLE_HOME/nodename_dbuniquename/(Oracle Real Application Clusters(Oracle RAC)データベースの場合)

注意:
Oracle Database 10gでは、データベースの各インスタンスに固有のファイルは、Oracle Database 10gホームの次のディレクトリに格納されます。

- $ORACLE_HOME/hostname_sid/(単一インスタンス・データベースの場合)

- $ORACLE_HOME/nodename_sid/(Oracle RACデータベースの場合)

この章のこれ以降では、$ORACLE_HOME/hostname_dbuniquename/と$ORACLE_HOME/nodename_dbuniquenameは互いに読み替えることができます。(データベースのリリース10gの場合、ディレクトリは$ORACLE_HOME/hostname_sid/および$ORACLE_HOME/nodename_sid/です)。いずれのパスも同じ概念、つまり特定のデータベース・インスタンスのEnterprise Managerディレクトリを表します。両者の違いは、$ORACLE_HOME/hostname_dbuniquename/が単一インスタンス・データベースに使用されるのに対して、$ORACLE_HOME/nodename_dbuniquename/はクラスタ(Oracle RAC)データベースに使用されることです。クラスタ・データベースでは、nodenameはノードのパブリック名を表し、クラスタ環境のCluster Ready Services(CRS)を構成するときに指定した名前になります。

たとえば、データベース・ホスト名がmgmt1.example.comであり、データベース名のシステム識別子がdb11である場合、そのインスタンスの管理エージェントおよび管理サービスのログ・ファイルは次のディレクトリにインストールされます。

$ORACLE_HOME/mgmt1.example.com_db11/sysman/log/

hostname_dbuniquenameディレクトリがOracleホーム・ディレクトリに存在しない場合は、Database Controlがデータベース・インスタンス用に構成されていないことを示します。Oracle Databaseリリース10gでは、ディレクトリはhostname_sidであることに注意してください。

また、Database ControlをJ2EEアプリケーションとしてデプロイするために必要なファイルが、$ORACLE_HOME/oc4j/j2ee/ディレクトリ構造にインストールされます。Database Controlは、Oracle Application Server Containers for J2EE(OC4J)のスタンドアロン・バージョンを使用してデプロイされるJ2EEアプリケーションです。OC4J_DBConsoleディレクトリには、OracleホームにデプロイされたDatabase Controlインスタンスごとにデータベース固有のデプロイメント・ディレクトリを作成するときに使用されるテンプレート・ファイルが含まれています。

インストール・ファイルおよび構成ファイルは、$ORACLE_HOMEディレクトリの次のサブディレクトリに格納されます。

- cfgtoollogs/dbua

- cfgtoollogs/rconfig

- cfgtoollogs/dbca

- cfgtoollogs/emca

図10-1に、Oracle Database 11g リリース2以降で一般的なOracleホーム・ディレクトリの重要なEnterprise Managerディレクトリの場所を示します。hostname_dbuniquenameは単一インスタンス・データベース用の場所であり、クラスタ・データベースのパスはnodename_dbuniquenameという形式で表されています。

図10-1 リリース11g以降の管理サービス・ホームのディレクトリ構造

図10-2に同じように、Oracle Databaseリリース10gのOracleホーム・ディレクトリのEnterprise Managerディレクトリのディレクトリ構造を示します。

図10-2 リリース10gの管理ホームのディレクトリ構造

インストール中およびインストール後のDatabase Controlの構成

次の各項では、インストールするときにDatabase Controlを構成する方法、およびインストール後にDatabase Controlを構成する方法について説明します。

構成オプションの概要

データベース管理者がDatabase Control環境を構成するときに使用できる製品、ツールおよびユーティリティを次に示します。

- Oracle Universal Installer
Oracle Universal Installer(OUI)は、Oracleソフトウェアおよびオプションをインストールするユーティリティです。これによりOracle Database Configuration Assistantが自動的に開始され、データベースがインストールされます。

- DBCA
Oracle Database Configuration Assistant (DBCA)は、Oracleから提供されているテンプレートからデータベースを作成するユーティリティです。また、あらかじめ構成されているシード・データベースをコピーして独自のデータベースを作成できるため、新しいデータベースの生成とカスタマイズにかかる時間と手間を軽減できます。

- Database Upgrade Assistant
Database Upgrade Assistantは、既存のデータベースを新しいリリースのOracle Databaseにアップグレードする際に使用するツールです。

- Net Configuration Assistant
Net Configuration Assistant(NETCA)は、Oracle Databaseネットワークのクリティカル・コンポーネントであるリスナーとネーミング・メソッドを構成する場合に使用するユーティリティです。

インストール時のDatabase Controlの構成

Oracle Databaseのインストール中にデータベースを作成する場合は、Oracle Enterprise ManagerのGrid ControlコンソールまたはDatabase Controlコンソールで管理できるようにデータベースを構成できます。

管理オプションとしてGrid Controlコンソールを選択するには、Oracle Management Serviceがネットワーク・ホストにインストールされている必要があります。また、データベースをインストールするホストにOracle Management Agentがインストールされている必要もあります。このようにしない場合は、Grid Controlコンソールのオプションを使用できないため、Database Controlでデータベースを管理することを選択する必要があります。

Oracleのほとんどのインストール・タイプでは、インストール中にデータベースを作成する場合、管理オプションとしてDatabase ControlまたはGrid Controlのいずれかを選択する必要があります。

ただし、次のいずれかの方法を使用してデータベースを作成する場合は、Database Controlを構成しないことを選択できます。

- Enterprise EditionまたはStandard Editionのインストール中に、「詳細」データベース構成オプションを選択する方法

- インストール後のDBCAの実行

Oracle Database 11gインスタンスのインストール時にDatabase Controlを構成しない場合は、Oracleホーム・ディレクトリにhostname_dbuniquenameディレクトリが作成されません。リリース10gデータベースをインストールする場合は、Oracleホーム・ディレクトリにhostname_sidディレクトリが作成されません。

DBCAを使用したDatabase Controlの構成

Database Controlで管理できるように既存のOracleデータベースを構成するための主要な方法は、DBCAを使用することです。DBCAを使用すると、新しいデータベースを作成したり、既存のデータベースを再構成することができます。

関連項目:
DBCAを使用して新規データベース・インスタンスを作成する方法の詳細は、『Oracle Database 2日でデータベース管理者』のOracleソフトウェアのインストールおよびデータベースの構築に関する項を参照し、DBCAを使用したOracle RACの例は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

DBCAを使用して、Database Controlで管理できるようにデータベースを再構成するには、次の手順を実行します。

1. Oracleソフトウェアのインストールとデータベースの作成および実行が許可されている管理グループのメンバーとしてデータベース・ホストにログインします。

2. DBCAを起動し、ディレクトリを$ORACLE_HOME/binディレクトリに変更し、次のコマンドを入力します。

$ ./dbca

DBCAの「ようこそ」ページが表示されます。

3. 「操作」ページに進み、「データベース・オプションの構成」を選択します。

4. 「データベース」ページに進み、構成するデータベースを選択します。

5. 「管理オプション」ページに進み、次のオプションを選択します。

- Enterprise Managerによるデータベースの構成

- データベース管理にDatabase Controlを使用

6. 電子メール通知と日次バックアップの有効化に関する、任意のオプションを選択します。
Enterprise Managerの通知および日次バックアップの詳細を参照するには、「管理オプション」ページの「ヘルプ」をクリックしてください。

7. 「終了」ボタンが使用可能になるまで続行します。

8. 「終了」をクリックして、Database Controlを使用するようにデータベースを再構成します。
DBCAによるデータベースの再構成が終了すると、Oracleホームに新しいサブディレクトリが作成されます。データベースのリリース11g以降、このディレクトリは次のような命名形式になり、構成したデータベースに固有のDatabase Controlの構成ファイルおよび状態ファイルが保存されます。

hostname_dbuniquename

ただし、クラスタ・データベースの場合、ディレクトリの命名形式は次のようになります。

nodename_dbuniquename。

Oracle Database 10gでは、この新規サブディレクトリの命名形式は次のようになります。

hostname_sid

Oracle Database 10gの場合と同様に、クラスタ・データベースのディレクトリの命名形式は次のようになります。

nodename_sid

次に例を示します。

mycluster1.example.com_myNewDB

EMCAを使用したDatabase Controlの構成

DBCAを使用してOracle 11g リリース2(11.2)を構成する場合は、DBCAに備えられているグラフィカル・ユーザー・インタフェースを使用して、Database Controlの各種オプションを選択したり、データベースの他の側面を構成できます。

一方、オペレーティング・システムのコマンドラインを使用してDatabase Controlを構成するには、Enterprise Manager Configuration Assistant(EMCA)を使用できます。

注意:
EMCAを使用してDatabase Controlを構成するとき、データベースが使用できなくなり、ユーザーがデータベースに接続できなくなったり、データベースに対する操作を実行できなくなる場合があります。

EMCAを使用してDatabase Controlを構成するには、次の手順を実行します。

1. ORACLE_HOME環境変数に管理するデータベースのOracleホームを指定します。

2. ディレクトリを$ORACLE_HOME/binディレクトリに変更します。

3. 次のコマンドを入力してEMCAを起動します。コマンドには、オプションとして表10-1「EMCAコマンドライン操作」に示すコマンドライン引数を指定できます。

$ ./emca

EMCAのコマンドラインに含めた引数によっては、EMCAnによりDatabase Controlの構成に必要な情報の入力を求められます。

たとえば、データベースの自動日次バックアップを実行するようにDatabase Controlを構成するには、次のコマンドを入力します。

$ ./emca -config dbcontrol db -backup

EMCAコマンドは、次の形式で入力します。

emca [operation] [mode] [flags] [parameters]

注意:
Oracle Automatic Storage Management (ASM)を使用して単一インスタンス・データベース用にDatabase Controlを構成するときには、EMCAコマンドにパラメータは必要ありません。次のコマンドを実行してDatabase Controlを構成すると、Oracle ASMインスタンスが自動的に検出されます。

$ emca -config dbcontrol db -repos create

表10-1では、有効な実行操作とモードを説明し、オプションのパラメータを括弧内に示します。表10-2では、フラグとその動作を説明し、表10-3にオプションのパラメータの詳細を示します。EMCAパラメータの形式は、[-parameterName parameterValue]です。コマンドラインで複数のパラメータを組み合せて使用できます。

表10-1 EMCAコマンドライン操作

コマンド

説明

emca -h | --h | -help | --help

このオプションは、EMCAユーティリティのヘルプ・メッセージを表示する場合に使用します。表10-1、表10-2および表10-3で説明したオプションと、指定できる有効なパラメータが表示されます。

emca –version

EMCAに関連付けられているバージョン情報を出力します。

emca -config dbcontrol db [-repos (create | recreate)] [-cluster] [-silent] [-backup] [parameters]

データベースに対してDatabase Controlを構成します。Database Controlリポジトリの作成(再作成)、自動バックアップの構成、クラスタ・データベースでの対象操作の実行などのオプションがあります。

emca -config centralAgent (db | asm) [-cluster] [-silent] [parameters]

データベース・インスタンスまたはOracle ASMインスタンスに対する集中エージェント管理を構成します。この操作をクラスタ環境で実行するオプションなどがあります。この操作により、Oracle Enterprise ManagerのGrid Controlコンソールで集中管理できるようにデータベースが構成されます。このオプションを使用するには、Enterprise ManagerのOracle Management Serviceコンポーネントをネットワーク・ホストに事前にインストールしておく必要があります。また、データベースを実行しているホストにOracle Management Agentをインストールする必要があります。

emca -config all db [-repos (create | recreate)] [-cluster] [-silent] [-backup] [parameters]

データベースに対してDatabase Controlと集中エージェント管理の両方を構成します。指定可能な構成オプションは、前述のオプションと同様です。

emca -deconfig dbcontrol db [-repos drop] [-cluster] [-silent] [parameters]

データベースに対するDatabase Controlの構成を解除します。Database Controlリポジトリの削除、クラスタ・データベースでの対象操作の実行などのオプションがあります。たとえば、このコマンドは、削除予定のデータベースからDatabase Control構成を削除する場合に使用します。そのような場合は、Database Control構成を削除してからデータベースを物理的に削除します。この操作では、実際のデータベースまたはそのデータ・ファイルは削除されません。

emca -deconfig centralAgent (db | asm) [-cluster] [-silent] [parameters]

データベース・インスタンスまたはOracle ASMインスタンスに対する集中エージェント管理の構成を解除します。この操作をクラスタ環境で実行するオプションなどがあります。たとえば、このコマンドは、削除予定のデータベースから集中エージェント管理の構成を削除する場合に使用します。そのような場合は、集中エージェント管理の構成を削除してからデータベースを物理的に削除します。この操作では、実際のデータベースまたはそのデータ・ファイルは削除されません。

emca -deconfig all db [-repos drop] [-cluster] [-silent] [parameters]

データベースに対するDatabase Controlと集中エージェント管理の両方の構成を解除します。指定可能な構成解除オプションは、前述のオプションと同様です。

emca -addNode (db | asm) [-silent] [parameters]

データベースまたはASMの記憶域の新しいクラスタ・インスタンスに対してEnterprise Managerを構成します。詳細は、「Oracle RACでのEMCAの使用方法」を参照してください。このオプションは、リリース11gにのみ適用されます。

emca -deleteNode (db | asm) [-silent] [parameters]

今後削除する予定のノード用に構成されたEnterprise Managerの構成を解除します。詳細は、「Oracle RACでのEMCAの使用方法」を参照してください。このオプションは、Oracle Databaseリリース11gにのみ適用されます。

emca -addInst (db | asm) [-silent] [parameters]

管理者が管理するデータベースまたはOracle ASM記憶域の新たに追加されるクラスタ・インスタンス用にEnterprise Managerを構成します。このパラメータには、追加するインスタンスのSIDを指定します。詳細は、「Oracle RACでのEMCAの使用方法」を参照してください。

emca -deleteInst (db | asm) [-silent] [parameters]

管理者が管理するデータベースまたはOracle ASM記憶域の新たに削除されるクラスタ・インスタンス用に構成されたEnterprise Managerの構成を解除します。このパラメータには、削除するインスタンスのSIDを指定します。詳細は、後の「Oracle RACでのEMCAの使用方法」を参照してください。

emca -reconfig ports [-cluster] [parameters]

Database Controlのポートを明示的に再割当てします。この操作をクラスタ環境で実行するオプションなどがあります。詳細は、「Database Controlで使用されるポートの指定」を参照してください。

emca -reconfig dbcontrol -cluster [-silent] [parameters]

クラスタ・データベースに対してDatabase Controlのデプロイメントを再構成します。このコマンドは、-clusterオプションとともに使用する必要があります。詳細は、「Oracle RACでのEMCAの使用方法」を参照してください。

emca -displayConfig dbcontrol -cluster [-silent] [parameters]

クラスタ環境内のDatabase Controlの現行のデプロイメント構成に関する情報を表示します。このコマンドは、-clusterオプションとともに使用する必要があります。詳細は、「Oracle RACでのEMCAの使用方法」を参照してください。

emca -upgrade (db | asm | db_asm) [-cluster] [-silent] [parameters]

以前のリリースのEnterprise Managerの構成を現在のリリースにアップグレードします。この操作は、Oracle DatabaseまたはOracle ASMに対して個別に実行したり、Oracle DatabaseとOracle ASMのインスタンスに対して同時に実行できます。この操作によって、データベースまたはOracle ASMの実際のインスタンスがアップグレードされたり、Enterprise Managerソフトウェアがアップグレードされることはありません。かわりに、指定したインスタンスの構成ファイルがアップグレードされ、現行のバージョンのEnterprise Managerソフトウェアと互換性を持つようになります。EMCAは、ホスト上のすべてのOracleホームを調べて、指定したデータベースまたはOracle ASMターゲット、あるいはその両方のインスタンスをすべてアップグレードすることを試みます(これは、リスナー・ポートやOracleホームなどターゲット・プロパティに変更が加えられている可能性もあるためです)。

emca -restore (db | asm | db_asm) [-cluster] [-silent] [parameters]

現行のバージョンのEnterprise Manager構成を以前のバージョンに戻します。これは、-upgradeオプションの逆です(また、この操作によって加えられた変更は元に戻されます)。

emca -migrate -from dbcontrol -to centralAgent [-repos drop] [-cluster] [-silent] [parameters]

Database Controlから集中エージェントにEnterprise Manager構成を移行します。

表10-2 EMCAコマンドライン・フラグ

フラグ

説明

db

データベース(クラスタ・データベースを含む)に対して操作を実行します。このオプションは、Oracle ASMを使用してデータ・ファイルを格納するデータベースに対して使用します。データベースがOracle ASMを使用している場合、(-upgradeと-restoreを除き)前に説明した構成に関するすべての操作およびモードがこのことを自動的に検出し、変更をデータベースとOracle ASMインスタンスの両方に適用します。

asm

Oracle ASMのみのインスタンス(クラスタOracle ASMインスタンスを含む)に対して操作を実行します。

db_asm

このフラグは、-upgradeおよび-restoreモードでのみ使用できます。Oracle DatabaseインスタンスおよびOracle ASMインスタンスに対してアップグレード操作またはリストア操作を実行します。データベース・インスタンスとOracle ASMインスタンスは、別々にアップグレードまたはリストアできます(つまり、Oracle ASMインスタンスをアップグレードする場合、そのASMインスタンスがサービスを提供するデータベース・インスタンスをアップグレードする必要はありません)。したがって、Enterprise Managerの構成は、データベースおよびそれに対応するOracle ASMインスタンスに対して別々にアップグレードまたはリストアできます。

-repos create

新しいDatabase Control管理リポジトリを作成します。

-repos drop

現行のDatabase Control管理リポジトリを削除します。

-repos recreate

現在のDatabase Control管理リポジトリを削除し、新規にリポジトリを再作成します。

-cluster

クラスタ・データベース・インスタンスまたはOracle ASMインスタンスに対して操作を実行します。

-silent

追加情報の入力を求めるプロンプトを表示せずに操作を実行します。このモードが指定されている場合、必須パラメータはすべてコマンドラインに入力するか、または–respFile引数を使用して入力ファイルに指定する必要があります。使用可能なパラメータのリストは、コマンドラインでemca -helpと入力すると確認できます。

-backup

データベースに対して自動バックアップを構成します。EMCAによって日次自動バックアップのオプションの入力を求めるプロンプトが表示されます。データベース・ファイルのバックアップには、Enterprise Managerのデフォルトの設定が使用されます。

注意: このオプションを使用すると、EMCAはdb_recovery_file_dest初期化パラメータの値を使用して、自動バックアップ用のフラッシュバック・リカバリ領域を特定します。このパラメータが設定されていない場合は、EMCAでエラーが発生します。この設定は、Database Controlの「メンテナンス」ページを使用して後で変更できます。詳細は、Database Controlのオンライン・ヘルプを参照してください。

表10-3 EMCAコマンドライン・パラメータ

パラメータ

説明

-respFile

構成操作の実行中にEMCAで使用されるパラメータが記述された入力ファイルのパスを指定します。詳細は、「EMCAパラメータの入力ファイルの使用方法」を参照してください。

-SID

データベースのシステム識別子。

-PORT

データベースにサービスを提供するリスナーのポート番号。

-ORACLE_HOME

データベースのOracleホーム(絶対パス)。

-ORACLE_HOSTNAME

ローカル・データベースのホスト名。

-LISTENER_OH

リスナーが実行されるOracleホーム。データベースが実行されているものとは異なるOracleホームからリスナーが実行される場合は、パラメータLISTENER_OHを指定する必要があります。

-HOST_USER

ホスト・システムのユーザー名(自動バックアップの場合)。

-HOST_USER_PWD

ホスト・システムのユーザー・パスワード(自動バックアップの場合)。

-BACKUP_SCHEDULE

HH:MMの形式で指定した日次自動バックアップのスケジュール。

-EMAIL_ADDRESS

通知用の電子メール・アドレス。

-MAIL_SERVER_NAME

通知に使用される送信メール(SMTP)サーバー。

-ASM_OH

Oracle ASM Oracleホーム。

-ASM_SID

Oracle ASMインスタンスのシステム識別子。

-ASM_PORT

Oracle ASMインスタンスにサービスを提供するリスナーのポート番号。

-ASM_USER_ROLE

Oracle ASMインスタンスに接続するためのユーザー・ロール。

-ASM_USER_NAME

Oracle ASMインスタンスに接続するためのユーザー名。

-ASM_USER_PWD

Oracle ASMインスタンスに接続するためのパスワード。

-DBSNMP_PWD

DBSNMPユーザーのパスワード。

-SYSMAN_PWD

SYSMANユーザーのパスワード。

-SYS_PWD

SYSユーザーのパスワード。

-SRC_OH

Enterprise Manager構成をアップグレードまたはリストアするデータベースのOracleホーム。

-DBCONTROL_HTTP_PORT

このパラメータは、WebブラウザにDatabase Controlコンソールを表示する際に使用するポートを指定する場合に使用します。詳細は、「Database Controlで使用されるポートの指定」を参照してください。

-AGENT_PORT

このパラメータは、Database ControlのManagement Agentポートを指定する場合に使用します。詳細は、「Database Controlで使用されるポートの指定」を参照してください。

-RMI_PORT

このパラメータは、Database ControlのRMIポートを指定する場合に使用します。詳細は、「Database Controlで使用されるポートの指定」を参照してください。

-JMS_PORT

このパラメータは、Database ControlのJMSポートを指定する場合に使用します。詳細は、「Database Controlで使用されるポートの指定」を参照してください。

-CLUSTER_NAME

クラスタ名(クラスタ・データベース用)。

-DB_UNIQUE_NAME

データベースの一意の名前(クラスタ・データベース用)。

-SERVICE_NAME

データベースのサービス名(クラスタ・データベース用)。

-EM_NODE

Database Controlコンソールを実行するノード(クラスタ・データベース用)。詳細は、「Oracle RACでのEMCAの使用方法」を参照してください。

-EM_NODE_LIST

エージェントのみの構成用ノードのカンマ区切りリストであり、データを-EM_NODEにアップロードします。詳細は、「Oracle RACでのEMCAの使用方法」を参照してください。

-EM_SWLIB_STAGE_LOC

ソフトウェア・ライブラリの場所。

-PORTS_FILE

使用するポートが記載された静的ファイルへのパス。デフォルト値は${ORACLE_HOME}/install/staticports.iniです。

EMCAパラメータの入力ファイルの使用方法

EMCAの実行時に表示される一連のプロンプトに応答するかわりに、-respFile引数を使用して入力ファイルを指定できます。作成する入力ファイルは、次の例の形式と同様の形式にする必要があります。

PORT=1521
SID=DB
DBSNMP_PWD=xpE234D
SYSMAN_PWD=KDOdk432

作成したEMCA入力ファイルは、コマンドラインで次のように使用できます。

$ ./emca -config dbcontrol db -respFile input_file_path

たとえば、日次バックアップを実行し、Database Control管理リポジトリを作成するようにDatabase Controlを構成するには、例10-1に示すような入力ファイルを作成し、オペレーティング・システム・プロンプトに次のコマンドを入力します。

$ ./emca -config dbcontrol db -repos create -backup -respFile input_file_path

例10-1 EMCA入力ファイルの例

PORT=1521
SID=DB
DBSNMP_PWD=dow3l224
SYSMAN_PWD=squN3243
HOST_USER=johnson
HOST_USER_PWD=diTf32of
SYS_PWD=qlKj4352
BACKUP_SCHEDULE=06:30

Database Controlで使用されるポートの指定

Oracle Databaseをインストールするか、またはEMCAでDatabase Controlを構成した当初、Database Controlではデフォルトのシステム・ポートが使用されます。たとえば、次の例に示すように、デフォルトではポート1158を使用してDatabase Controlにアクセスします。

http://host.domain:1158/em

これは、Internet Assigned Numbers Authority(IANA)によってDatabase Controlに割り当てられているデフォルト・ポートです。同様に、IANAによって割り当てられているDatabase Controlエージェントのデフォルト・ポートは3938です。

EMCAを使用してDatabase Controlを初めて構成する場合にデフォルト・ポート以外のポートを使用するには、次のEMCAコマンドライン引数を使用します。また、Database Controlの構成後に、次のコマンドを使用してポートを明示的に割り当てることもできます。

$ emca -reconfig ports [-cluster]

注意:
また、Oracle Databaseをインストールして構成した後、次のEMCAコマンドライン引数を使用して、Database Controlを構成することもできます。

次に、Database Controlの標準的なポート割当てを制御するEMCAコマンドライン引数の概要を示します。

- -DBCONTROL_HTTP_PORT port_number
このポートは、Database Controlコンソールを示すURLで使用します。たとえば、このポートを5570に設定した場合、次のURLを使用してDatabase Controlコンソールを表示できます。

http://host.domain:5570/em

- -RMI_PORT port_number
このポートは、Database Controlに必須のJ2EEソフトウェアに含まれるRemote Method Invocation(RMI)システムで使用されます。Database Control用に特定のポートを構成する場合には、デフォルト・ポートを変更できます。デフォルト・ポート(1521)以外のポートを使用するときは、emca reconfigコマンドとともに-RMI_PORTオプションまたは-JMS_PORTオプションを使用します。

- -JMS_PORT port_number
このポートは、Database Controlに必要なJ2EEソフトウェアの一部であるOC4J Java Message Service(JMS)で使用されます。Database Control用に特定のポートを構成する場合には、デフォルト・ポートを変更できます。デフォルト・ポート(1521)以外のポートを使用するときは、emca reconfigコマンドとともに-RMI_PORTオプションまたは-JMS_PORTオプションを使用します。

- -AGENT_PORT port_number
このポートは、Database Controlのデータベースの監視と管理を行うDatabase Control Management Agentで使用されます。

Oracle RACでのEMCAの使用方法

各EMCAコマンドはOracle RAC環境で使用できますが、クラスタの設定には一部のコマンドのみを適用できます。EMCAを使用してクラスタ・コマンドを実行するには、ほぼすべてのEMCA動作モードで使用できるクラスタ・フラグを使用します。

EMCAを使用してOracle RACのDatabase Controlを構成する場合は、クラスタ内のインスタンスごとにDatabase Controlを構成します。ただし、デフォルトではDatabase Controlコンソールはローカル・ノードでのみ起動します。クラスタ内の他のすべてのノードでは、Enterprise Managerエージェントのみが起動されます。これは、Database Controlコンソールによって、データベースへの複数の接続がオープンされるためです。クラスタ内のそれぞれのホストでコンソールのインスタンスが実行されていると、32ノード環境または64ノード環境で開くことができる接続の最大数を容易に超過することがあります。

この状況を回避するため、Database Controlはローカル・ノードでのみ起動します。他のすべてのノードでエージェントの起動と停止に使用するコマンドは、emctl start dbconsoleとemctl stop dbconsoleのみです。各リモート・エージェントによって、それぞれのデータがローカル・ノードで稼働しているコンソールにアップロードされるため、そのコンソールからクラスタ内のすべてのターゲットの監視および管理を実行できます。Oracle RACデータベースの各インスタンスに次のサブディレクトリが作成され、ここでnodenameはクラスタ内のノード名、dbuniquenameはリリース11g以降のデータベースのデータベース・インスタンス名です。

$ORACLE_HOME/nodename_dbuniquename

Oracle Databaseリリース10gの場合、nodenameはクラスタ内のノードの名前であり、sidはデータベース・インスタンス名です。

$ORACLE_HOME/nodename_sid

ただし、Database Controlで構成された既存のOracle RACデータベースを最新のリリースにアップグレードしても、既存のDatabase Control構成が保持されることに注意してください。既存のDatabase Controlには、各クラスタ・ノードで稼働しているDatabase Controlが含まれています。このコンソールは、引き続き各ノードで起動されます。

リリース11g以降のデータベースの既存の構成を変更するには次のコマンドを使用しますが、ここでnodenameはノードのパブリック名、node_listはデータベースが構成されているノードのカンマ区切りリストです。

$ emca -reconfig dbcontrol –cluster –EM_NODE nodename -EM_NODE_LIST node_list

リリース10gデータベースの既存の構成を変更するには次のコマンドを使用しますが、ここでnodenameはノードのパブリック名、SID_listはデータベース・システム識別子を記載したカンマ区切りリストです。

$ emca -reconfig dbcontrol –cluster –EM_NODE nodename -EM_SID_LIST SID_list

注意:
Oracle RAC環境でDatabase Controlを構成するときは、SCANリスナーの構成は必須です。

このコマンドは、現在のDatabase Control設定を再構成し、次の処理を順に実行します。

注意:
特に指定がないかぎり、次の処理のコマンド・オプションはすべてリリース11g以降のデータベースを表しています。リリース10gデータベースでの相違点は、そのつど付記します。

1. Database Controlコンソールがnodename で起動されます(起動されていない場合)。

2. node_list(リリース10gデータベースではSID_list)に記載されたデータベース・インスタンスを監視する各エージェントをリダイレクトして、各エージェントがnodenameで実行中のコンソールにそれぞれのデータをアップロードするようにします。また、nodenameでデータベース・インスタンスを監視する各エージェントは、それぞれのデータをローカル・コンソールにもアップロードします。コマンドラインにコマンド・オプション-EM_NODEまたは-EM_NODE_LIST(リリース10gデータベースの場合は-EM_SID_LIST)を入力しないと、その入力を求められます。

-EM_NODEの入力を求められたときに入力しないと、デフォルトでローカル・ノードを指定したことになります。-EM_NODE_LIST(リリース10gデータベースの場合は、-EM_SID_LIST)を指定しないと、デフォルトでデータベースが構成されているすべてのノードを指定したことになります。

このコマンドを使用すると、複数のノードでコンソールを起動できます。たとえば、node1、node2、node3、node4、node5、node6、node7、node8の各ノードからなる8ノード・クラスタでは、次のコマンドを連続して実行できます。

$ emca -reconfig dbcontrol –cluster –EM_NODE node1 -EM_NODE_LIST node2,node3,node4
$ emca -reconfig dbcontrol –cluster –EM_NODE node5 -EM_NODE_LIST node6,node7,node8

リリース10gデータベースの場合は、次のコマンドを連続して実行します。

$ emca -reconfig dbcontrol –cluster –EM_NODE node1 -EM_SID_LIST sid2,sid3,sid4
$ emca -reconfig dbcontrol –cluster –EM_NODE node5 -EM_SID_LIST sid6,sid7,sid8

この例では、2つのDatabase Controlコンソール( node1 で1つ、 node5 で1つ)が実行されます。クラスタ内のすべてのターゲットは、いずれのコンソールからでも管理および監視できます。

現在のクラスタ構成の詳細を参照するには、次のコマンドを実行してください。

$ emca -displayConfig dbcontrol –cluster

前述のコマンドを実行すると、クラスタ・データベースの一意のデータベース名の入力が求められます。現在の構成が画面に出力され、コンソールが実行されているノードと、各エージェントがアップロードしているコンソールが示されます。

クラスタの新たに追加されるノード用にEnterprise Managerを構成するには、次のコマンドを入力します。

$ emca -addNode db

管理者が管理するデータベースまたはOracle ASM記憶域の新しいクラスタ・インスタンス用にEnterprise Managerを構成するには、次のコマンドを入力します。

$ emca -addInst db

Oracle Databaseリリース11gの場合、クラスタ・ポリシーで管理するデータベースでよく使用される別の操作として、クラスタ・ノードの追加と削除をあげることができます。新規ノードを追加した後、EMCAを実行し、emca -addNode dbコマンドを使用して、ノードに対するDatabase Controlまたは集中エージェント管理を構成できます。EMCAを実行すると、Enterprise Managerは、他のクラスタ・データベース・インスタンスと一貫性のある方法で管理できるように構成されるのみとなります。

Oracle Databaseリリース10gおよび11の場合、クラスタ・データベースではデータベース・インスタンスを作成および削除できます。新規インスタンスを作成した後で、EMCAを実行し、そのインスタンスに対してemca -addInst dbコマンドを使用すると、Database Controlまたは集中エージェント管理を構成できます。EMCAを実行しても、実際のデータベース・インスタンスは作成されません。Enterprise Managerの構成のみを行い、残りのクラスタ・データベース・インスタンスと一貫性のとれた方法でインスタンスを管理できるようにします。

リリース11g以降で、新規ノードに対してEnterprise Managerを構成する場合は、ノードの追加後にのみEMCAコマンドを実行します。また、Enterprise Managerが構成済であるクラスタのノードからコマンドを実行します。その既存ノードのEnterprise Managerの構成設定が、コマンドを実行すると新規ノードに伝播されるためです。-addNodeオプションはOracle RAC環境でのみ使用できるため、コマンドラインで-clusterオプションを使用する必要はありません。

emca -addNode dbコマンドを実行した後、ノードおよびデータベースに対してノード名およびデータベースの一意の名前を入力します。次に例を示します。

Node name: node2
Database Unique Name: EM102

同様に、リリース10gおよび11gのデータベースで、新規インスタンスに対してEnterprise Managerを構成する場合、EMCAコマンドを実行するのはインスタンスを作成した後のみです。また、これらの構成設定が新規インスタンスに伝播されるように、クラスタに関連付けられたデータベース・インスタンスに対してEnterprise Managerを構成したクラスタ内のノードからコマンドを実行します。新規インスタンスが作成されたノードからは、このコマンドを実行しないでください。このオプションはOracle RAC環境でのみ使用できるため、コマンドラインで-clusterオプションを使用する必要はありません。emca -addInst dbコマンドを実行した後、ノードおよびデータベースに対して次の情報を入力します。

Node name: node2
Database Unique Name: EM102
Database SID: EM1022

リリース11g以降の場合、クラスタから削除する特定のノード用に構成されたEnterprise Managerの構成を解除するには、削除するそのノードとは別のノードにログインし、emca -deleteNode dbコマンドを使用します。このコマンドを実行すると、Enterprise Manager構成が削除され、ノードでのEnterprise Managerによるインスタンスの管理ができなくなります。EMCAコマンドを実行してから、実際のクラスタ・ノードを削除するようにします。このオプションはOracle RAC環境でのみ使用できるため、コマンドラインで-clusterオプションを使用する必要はありません。

Oracle Databaseリリース10gの場合、(一般的にデータベース・インスタンスが削除される前に)特定のデータベース・インスタンス用に構成されたEnterprise Managerの構成を解除するには、構成の逆の操作を実行するemca -deleteInst dbコマンドを使用します。EMCAを実行しても、データベース・インスタンスは削除されず、その後Enterprise Managerを使用してインスタンスを管理できないように、Enterprise Manager構成が削除されるのみです。

このEMCAコマンドは、実際のクラスタ・データベース・インスタンスを削除する前に実行してください。また、データベース・インスタンスを削除するノードではなく、別のノードからコマンドを実行してください。このオプションはOracle RAC環境でのみ使用できるため、コマンドラインで-clusterオプションを使用する必要はありません。

詳細は、表10-1で説明しているEMCAコマンドライン操作を参照してください。

注意:
コマンドemca -clusterを使用して、Oracle RACに対してDatabase Controlを構成する場合は、環境変数TNS_ADMINをすべてのクラスタ・ノードで確認してください。各ノードでTNS_ADMINの設定が異なる場合は、ターゲットのリスナーを正しく構成できません。この場合、emca -clusterコマンドを実行する前に、すべてのクラスタ・ノードでTNS_ADMINに同じ値を設定してください。

Database Controlの管理

ここでは、Database Controlでデータベースを管理する場合に実行できるアクティビティについて簡単に説明します。次の各項では、Oracleデータベースの管理に使用できるタスクについて説明します。

- Database Controlプロセスの起動と停止

- データベース・ホームページへのアクセス

- Database Control管理ユーザーの作成

- Database Controlに対するアクセス権限の管理ユーザー以外のユーザーへの付与

- Database Controlのプリファレンスの設定

Database Controlプロセスの起動と停止

ブラウザからDatabase Controlにアクセスするには、Database Controlコンソール・プロセスのdbconsoleがデータベースのホスト・コンピュータで稼働している必要があります。dbconsoleプロセスはインストール後に自動的に起動します。ただし、システムを再起動する必要がある場合は、このプロセスをコマンドラインから手動で起動するか、Windowsのサービスとして起動できます。また、コマンドを実行して、このプロセスを停止したり、そのステータスを表示できます。このプロセスが停止した場合は、Database Controlを使用する前に、このプロセスを手動で再起動する必要があります。コマンドラインからデータベースを起動または停止したり、dbconsoleプロセスのステータスを表示する手順は、次のとおりです。

1. 『Oracle Database 2日でデータベース管理者』の「オペレーティング・システムの環境変数の構成」の説明に従って、オペレーティング・システムの環境変数を構成します。

2. 次のいずれかを実行します。

- プロセスを開始するには、次のコマンドを実行します。

$ ./emctl start dbconsole

- プロセスを停止するには、次のコマンドを実行します。

$ ./emctl stop dbconsole

- プロセスの状態を表示するには、次のコマンドを実行します。

$ ./emctl status dbconsole

注意:
ORACLE_UNQNAME環境変数の設定を求められた場合は、この変数を設定し、emctlコマンドを再度実行します。変数をデータベースの一意の名前(DB_UNIQUE_NAMEデータベース・パラメータの値)に設定します。DB_UNIQUE_NAMEの一般的な値はorclです。

Microsoft WindowsでDatabase Controlをサービスとして起動または停止する手順は、次のとおりです。

1. 次のいずれかを実行します。

- Windows XPおよびWindows Server 2003では、「スタート」をクリックし、「コントロール パネル」を選択します。

- Windows 2000 Serverでは、「スタート」をクリックし、「設定」を選択し、「コントロール パネル」を選択します。

コントロール パネル・ウィンドウが開きます。

2. 「管理ツール」アイコンをダブルクリックし、「サービス」アイコンをダブルクリックします。
サービス・ウィンドウが開きます。

Oracle DatabaseサービスはOracleで始まります。このサービスはOracleDBConsolesidとしてリストされ、ここでsidはデータベース・インスタンスのシステム識別子(SID)です。「ステータス」列にプロセスのステータスが表示されます。

3. OracleDBConsolesidサービスをダブルクリックします(リリース10gの場合)。OracleDBConsoledbuniquenameサービスをダブルクリックします(リリース11gの場合)。
「サービスのプロパティ」ウィンドウが開きます。

4. 起動タイプ・リストで、「手動」か「自動」のいずれかが選択されていることを確認します。

5. 次のいずれかを実行します。

- サービスを開始するには、「開始」をクリックし、「OK」をクリックします。

- サービスを停止するには、「停止」をクリックし、「OK」をクリックします。

データベースのホームページのアクセス

データベース・ホームページは、Database Controlのメインのデータベース管理ページです。

データベースのホームページにアクセスするには、次の手順を実行します。

1. dbconsoleプロセスがデータベースのホスト・コンピュータ上で実行されていることを確認してください。
「Database Controlプロセスの起動と停止」を参照してください。

2. Webブラウザで次のURLを入力します。

https://hostname:portnumber/em

たとえば、comp42.example.comという名前のホスト・コンピュータにデータベースをインストールしたと想定します。また、使用するEnterprise ManagerコンソールのHTTPポート番号が1158であるとします。この場合は、次のURLを入力します。

https://comp42.example.com:1158/em

Oracle Databaseを最近インストールした場合、LinuxおよびUNIXシステムでは$ORACLE_HOME/install/portlist.iniファイルを表示してDatabase Controlのポート番号を確認できます。それ以外の場合は、ORACLE_$HOME/Oracle_sid/sysman/config/emd.propertiesファイルでREPOSITORY_URLを検索してDatabase Controlのポート番号を確認でき、ここで、Oracle_sidはデータベース・インスタンスのシステム識別子(SID)です。

データベースを起動するには、次の作業を行う必要があります。

1. 「起動/停止」をクリックし、ホスト・ログインのユーザー名およびパスワードを入力し、データベース・ログインのユーザー名およびパスワードを入力します。
データベースのユーザー名およびパスワードの場合、SYSおよびインストール時に指定したパスワードを入力します。

2. 「OK」をクリックしてデータベース・インスタンスを起動し、「確認」ページで「はい」をクリックしてオープン・モードでデータベースを起動します。

3. Database Controlにアクセス権限のあるユーザー・アカウントでデータベースにログインします。
このユーザーは、最初はSYSまたはSYSTEMのいずれかで、データベースのインストール時に指定したパスワードを使用します。

SYSTEMアカウントを使用して日常の管理タスクを実行できるものの、Oracleデータベース管理用のユーザー・アカウントを別途作成して、データベース・アクティビティを監視できるようにすることをお薦めします。データベースをバックアップ、リカバリまたはアップグレードするには、SYSDBAユーザーとしてログインする必要があります。

Database Controlに、データベース・ホーム・ページが表示されます。

ページの最上部のサブページ・リンクを使用して、パフォーマンス、可用性およびその他のデータベース管理ページにアクセスできます。これらのページで提供される機能については、このマニュアルの他の項で説明しています。

データベース・ホームページの様々なセクションでは、データベースの環境および状態について説明します。たとえば、「アラート」セクションおよび「診断サマリー」セクションには、データベースの操作に影響を及ぼすエラーおよびパフォーマンスに関する問題が示されます。ここに示されたリンクをクリックすると、問題領域に関する詳細を参照できる以外に、場合によっては問題解決の推奨事項を入手できます。詳細は、『Oracle Database 2日でデータベース管理者』の「データベースの監視およびチューニング」を参照してください。

Database Control管理ユーザーの作成

SYS、SYSTEM、SYSMANのいずれかのユーザー・アカウントを使用してDatabase Controlにログインすると、Database Controlスーパーユーザーとしてログインしたことになります。これらのアカウントには、Database Controlの管理に必要なロールおよび権限が自動的に付与されます。Database Control管理タスクの例は、次のとおりです。

- 他のDatabase Control管理者の作成。

- 電子メールおよびその他の通知メソッドの構成。

- 表領域の領域使用率やSQLレスポンス時間など、データベース・メトリックのアラートしきい値の設定。

- 適用するデータベース・ポリシーの選択。ポリシーに違反する場合にDatabase Controlにアラートを表示可能(ポリシーの例として、「システム・ユーザー以外は SYSTEM または SYSAUX 表領域をデフォルト表領域として使用できない」などがあります)。

- ブラックアウトの定義。ブラックアウトとは、メンテナンス操作によって監視データに偏りが発生したり、無用なアラートが生成されないように、データベース監視を一時停止する期間のことです。

Database Control自体を管理する権限を十分に持ち、SYSおよびSYSTEMユーザーの高度のデータベース管理権限を持たないDatabase Control管理ユーザーを作成します。これにより、他のDatabase Control管理者から要求される最小限の権限を割り当てることができ、データベース・セキュリティにとってベスト・プラクティスです。また、Database Control管理アカウントを作成でき、データベース管理タスクを実行するまで、SYSまたはSYSTEMとしてログインすることを回避できます。

次の手順を使用すると、Database Control管理権限を既存のデータベース・ユーザーに割り当てたり、新規にDatabase Control管理ユーザーを作成できます。新しいDatabase Control管理ユーザーを作成する場合は、そのユーザーに対してデータベースのユーザー・アカウントが作成されます。どのシステム権限、オブジェクト権限、またはロールをユーザーに付与するか、また必要であれば、どのシステム権限、オブジェクト権限、またはロールでデータベース管理タスクを実行するかを決定する必要があります。

Database Control管理ユーザーを作成する手順は、次のとおりです。

1. いずれかのDatabase Controlページのページ上部で、「設定」をクリックします。
Enterprise Manager構成ページが表示されます。このページには設定の概要ページが表示されます。

2. 左にあるナビゲーション・バーで、「管理者」をクリックします。
管理者ページが表示されます。

3. 「作成」をクリックします。
管理者の作成: プロパティ・ページが表示されます。

4. 「名前」フィールドに既存のデータベース・ユーザーの名前を入力するか、フィールドの横にある懐中電灯アイコンをクリックして既存のデータベース・ユーザーを選択します。

5. データベースの電子メールの通知を設定する場合のみ、この管理者の電子メールアドレスを1つ以上入力します。

6. 「確認」をクリックし、入力した情報の概要を説明するページを表示します。

7. 「終了」をクリックして、Database Control管理ユーザーとしてデータベース・ユーザーを構成します。
リストに新しい管理者が示されている管理者ページが表示されます。

Database Controlに対するアクセス権限の管理ユーザー以外のユーザーへの付与

データベース管理者は、SYSまたはSYSTEMユーザー・アカウントを使用してDatabase Controlにログインし、管理タスクおよびその他のタスクを実行できます。非管理ユーザーがDatabase Controlにログインする可能性もあります。たとえば、アプリケーション開発者はDatabase Controlインタフェースを利用して、表、索引、ビューなどの作成または変更を行う必要があります。これらのユーザーがログインできるようにするには、ユーザーにDatabase Controlへのアクセス権限を付与する必要があります。管理ユーザー以外のユーザーにDatabase Controlへのアクセス権限を付与するには、SELECT_CATALOG_ROLEロールを付与する必要があります。

Database Controlのプリファレンスの設定

ここでは、Database Controlのユーザー・プリファレンスの設定について説明します。

Database Controlのプリファレンスの設定について

Database Controlを使用すると、次のようなユーザー・プリファレンスを設定できます。

- 通知
Database Controlから自分宛に電子メールでアラートを送信できます。アラートはデータベースが望ましくない状態にあり注意が必要であることを通知します。デフォルトで、データベースのホームページにはすべてのアラートが表示されます。ただし、電子メール通知を使用するには設定が必要です。アラートの内容および通知の設定の詳細は、『Oracle Database 2日でデータベース管理者』の「データベースの監視およびチューニング」、直接アラート通知の設定に関する項を参照してください。

- ブラックアウト管理
ブラックアウト中、Database Controlはデータベース監視データを収集せず、アラートを送信しません。ブラックアウトでは、不要なアラートの受信や監視データの偏りを避けながら、スケジュールされたメンテナンスをデータベースに対して実行できます。

たとえば、データの収集をデータベースのバックアップ時またはハードウェアのアップグレード時に停止できます。このような期間に監視を続けると、収集されたデータには、日常的な操作の結果とは異なる傾向およびその他の監視情報が表示されます。より正確で、長期間のデータベース・パフォーマンスの情報を得るために、ブラックアウトを使用すると、これらの特殊なケースをデータ分析から除外できます。詳細は、『Oracle Database 2日でデータベース管理者』の「データベース管理スタート・ガイド」、ブラックアウト期間の定義に関する項を参照してください。

- 優先資格証明
Database Controlはバックアップなど、多くのルーチンの管理タスクを自動的に実行できます。Database Controlに組み込まれたジョブ・スケジューリング・システムを使用して、これらのルーチン・タスクを実行できます。環境をセキュアに保つために、Enterprise Managerの自動実行のタスクの設定ではホスト・コンピュータおよびデータベースのログイン情報を入力することが必要です。この情報をジョブやタスクを作成または実行するたびに入力することを回避するために、Database Controlではこの情報を優先資格証明として保存できます。優先資格証明は暗号化モードでデータベースに格納され、不正なアクセスから保護されます。詳細は、「優先資格証明の設定」を参照してください。

ブラックアウト期間の定義

1回のみまたは繰返しのブラックアウト期間を1つ以上定義できます。この期間中、Database Controlはデータベース監視データを収集せず、アラートを送信しません。

ブラックアウト期間を定義するには、次の手順を実行します。

1. いずれかのDatabase Controlページのページ上部で、「設定」をクリックします。
Enterprise Manager構成ページが表示されます。このページには設定の概要ページが表示されます。

2. 左側のペインにある「ブラックアウト」をクリックします。
ブラックアウト・ページが表示されます。

3. 「作成」をクリックして、「ブラックアウトの作成」ウィザードを開始します。
「ブラックアウトの作成: プロパティ」ページが表示されます。

4. 必要に応じて、デフォルトのブラックアウト名を任意の名前に置換します。

5. 必要に応じて、「コメント」フィールドに、ブラックアウトの目的を入力します。

6. 「理由」リストで最も適切なブラックアウトの理由を選択します。

7. 「使用可能なターゲット」セクションの「タイプ」リストで、「データベース・インスタンス」を選択します。
データベース・インスタンスの完全修飾名が、「使用可能なターゲット」リストに表示されます。

8. 「使用可能なターゲット」リストで、インスタンスを選択し、「移動」アイコンをクリックします。インスタンス名をダブルクリックすることもできます。
インスタンス名が、「使用可能なターゲット」リストから「選択したターゲット」リストに移動します。

9. 「次へ」をクリックします。
「ブラックアウトの作成: スケジュール」ページが表示されます。

10. 「ブラックアウトの作成: スケジュール」ページで、次の処理を実行します。

1. 「開始」セクションで、ブラックアウトをすぐに行うか、後で行うかスケジュールします。

2. 「期間」セクションでは、ブラックアウトの期間が表示されます。

3. ブラックアウトを定期的に繰り返すには、「繰返し」セクションで、「繰返し」リストから繰返し頻度を選択します。それ以外の場合、デフォルト値の「繰返しなし」を使用します。

11. 「次へ」をクリックします。
確認ページが表示されます。

入力した項目を確認します。「戻る」をクリックして設定を変更します。

12. 「終了」をクリックします。
ブラックアウト・ページに「確認」ヘッダーが表示されて、新しいブラックアウト期間がリストに示されます。

優先資格証明の設定

優先資格証明を設定すると、資格証明が求められる通常の状況で、Database Controlによってホスト・コンピュータおよびデータベース・ログインの資格証明が自動的に入力されます。資格証明が必要なジョブを実行しようとした場合も、これらの資格証明がDatabase Controlによって入力されます。

データベース優先資格証明を設定するには、次の手順を実行します。

1. いずれかのDatabase Controlページで、ページ上部の「プリファレンス」をクリックします。
「プリファレンス」ページが表示されます。

2. 左ペインの「優先資格証明」をクリックします。
「優先資格証明」ページが開き、ターゲットの表が表示されます。

3. データベース・インスタンスの表の行にある「資格証明の設定」の下のアイコンをクリックします。
データベースの優先資格証明ページが表示されます。

4. 次の資格証明情報を入力します。

- 「ユーザー名」/「パスワード」および「SYSDBAユーザー名」/「SYSDBAパスワード」のデータベース資格証明

- 「ホスト・ユーザー名」/「ホストのパスワード」のホスト資格証明

たとえば、通常はユーザーSYSTEMとして接続し、SYSDBAアクセスにはSYSアカウントを使用し、ホスト・ユーザー名にはoracleを使用することがあります。

注意:
ホスト・ユーザーには、データベース・バックアップなどのバックグラウンド・ジョブを実行するための特定のホスト権限が必要な場合があります。たとえば、UNIXおよびLinuxでは、ホスト・ユーザーはOSDBAグループ(一般的にはdba)に属している必要があります。Windowsでは、ホスト・ユーザーはAdministratorsグループのメンバーであり、「Log on as Batch Job」ログイン権限が付与されている必要があります。詳細は、ご使用のプラットフォームのマニュアルを参照してください。

5. 「テスト」をクリックし、資格証明をテストします。
確認メッセージには資格証明が検証可能かどうかが表示されます。

6. 変更を適用するには、「適用」をクリックします。

Oracle RAC環境でのDatabase Controlの管理

Oracle RACデータベースを作成し、データベース管理にDatabase Controlを選択した場合は、Database Controlが自動的にインストールされて構成されます。

この項の内容は、次のとおりです。

- Oracle RAC環境でDatabase Controlが実行されていることの検証

- emkey.oraファイルのバックアップ

Oracle RAC環境でDatabase Controlが実行されていることの検証

新規Oracle RAC環境でDatabase Controlが起動したことを検証する手順は、次のとおりです。

1. ORACLE_UNQNAME環境変数が、接続先データベースの一意の名前(たとえば、orcl)に設定されていることを確認します。また、次に示すように、ORACLE_HOME環境変数が、インストールしたOracle Databaseソフトウェアの場所に設定されていることを確認します。

$ export ORACLE_UNQNAME=orcl
$ echo $ORACLE_HOME
/u01/app/oracle/product/11.2.0/dbhome_1

$ echo $ORACLE_UNQNAME
orcl

2. $ORACLE_HOME/binディレクトリに移動します。

3. oracleユーザーとして次のコマンドを実行します。

./emctl status dbconsole

Enterprise Manager Control(EMCTL)ユーティリティにより、次に示すように、現在のノード上にあるDatabase Controlコンソールの現在の状態が表示されます。

Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2009 Oracle Corporation.  All rights reserved.
https://racnode1.example.com:1158/em/console/aboutApplication
Oracle Enterprise Manager 11g is running.
------------------------------------------------------------------
Logs are generated in directory /u01/app/oracle/product/11.2.0/dbhome_1/racnode1_orcl/sysman/log

4. EMCTLユーティリティにより、Database Controlが起動されていないことがレポートされた場合は、次のコマンドを使用して起動します。

$ ./emctl start dbconsole

標準的なインストールに従うと、Database Controlにより、データベースが作成されたノードからコンソール・ページを利用できるようになります。また、コンソールはクラスタのすべてのノード上にあるエージェントを監視します。ただし、EMCAを使用して、クラスタ内で複数のDatabase Controlコンソールが動作するようにEnterprise Managerを構成できます。

emkey.oraファイルのバックアップ

インストール中、Database Control管理リポジトリはセキュア・モードになります。emkey.oraファイルに格納されている暗号化キーを使用して、すべてのEnterprise Managerデータが暗号化されます。このファイルが破損しているか失われているためにバックアップからリストアできない場合は、既存のEnterprise Managerリポジトリを使用できなくなります。

emkey.oraファイルは、$ORACLE_HOME/node_name_Database_name/sysman/configディレクトリにあります。たとえば、racnode2サーバーの場合、orcl.example.comデータベースの暗号化キー・ファイルは/u01/app/oracle/product/11.2.0/dbhome_1/racnode2_orcl/sysman/config/emkey.oraにあります。

Database Controlオブジェクトの削除と作成

ここでは、Database Controlオブジェクトを削除および作成するプロセス、およびDatabase Controlで構成ファイルおよびリポジトリを再作成する方法について説明します。

Database Controlオブジェクトの削除

ここでは、Database Controlオブジェクトを削除するために必要な手順について説明します。Database Controlオブジェクトを削除する場合に使用できる6つのオプションを次に示します。

- オプション1: EMCAスクリプトを使用したDatabase Control構成ファイルの削除

- オプション2: EMCAスクリプトを使用したDatabase Control構成ファイルおよびリポジトリ・オブジェクトの削除

- オプション3: EMCAスクリプトを使用したDatabase Controlリポジトリの削除

- オプション4: 手動によるDatabase Control構成ファイルの削除

- オプション5: RepManagerを使用したDatabase Controlリポジトリの削除

オプション1: EMCAスクリプトを使用したDatabase Control構成ファイルの削除

EMCAスクリプトを使用してDatabase Control構成ファイルを削除するには、次のいずれかのコマンドを実行します。

単一インスタンス・データベースの場合:

$ $ORACLE_HOME/bin/emca -deconfig dbcontrol db

Oracle RACデータベースの場合:

$ $ORACLE_HOME/bin/emca -deconfig dbcontrol db –cluster

-deconfigオプションにより、Database Controlの構成が解除される前に、スケジューリングからEnterprise Managerジョブが削除されます。そうしない場合、Database Controlが削除されるときにEnterprise Managerジョブがスケジュールされていた場合に、(削除されない)リポジトリが破損したり不整合が発生する可能性があります。また、Database Controlの削除時にエラーが発生する可能性があります。

オプション2: EMCAスクリプトを使用したDatabase Control構成ファイルおよびリポジトリ・オブジェクトの削除

EMCAスクリプトを使用して、Database Control構成ファイルおよびリポジトリ・オブジェクトを削除できます。1つのコマンドで構成ファイルとリポジトリ・オブジェクトの両方を削除できます。

単一インスタンス・データベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -deconfig dbcontrol db -repos drop

Oracle RACデータベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -deconfig dbcontrol db -repos drop –cluster

注意:
このコマンドにより、データベースは停止モードになります。

オプション3: EMCAスクリプトを使用したDatabase Controlリポジトリの削除

次に示すコマンドを使用することによって、EMCAスクリプトを使用してDatabase Controlリポジトリを削除できます。

単一インスタンス・データベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca –repos drop

Oracle RACデータベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -repos drop -cluster

注意:
このコマンドにより、データベースは停止モードになります。

オプション4: 手動によるDatabase Control構成ファイルの削除

EMCAスクリプトを使用しDatabase Controlオブジェクトを削除する以外に、次のように手動でオブジェクトを削除できます。

ファイル・システムから次のディレクトリを削除します。

$ $ORACLE_HOME/hostname_sid

$ $ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_sid

Windowsでは、次のように、Database Controlサービスを削除する必要もあります。

1. regeditを実行します。

2. HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Servicesに移動します。

3. OracleDBConsolesidエントリを探して削除します。

また、Windows XPおよびWindows Server 2003では、コマンドラインから次の処理を実行できます。service_nameはDatabase Controlサービス名です(一般的にはOracleDBConsolesid)。

sc delete service_name

また、Microsoft社から、delsrv.exe実行可能ファイルを無料でダウンロードできます。

オプション5: RepManagerを使用したDatabase Controlリポジトリの削除

RepManagerを使用して、Database Controlリポジトリを削除できます。このオプションは、他のオプションほど完成されたものではありません。コマンドライン・オプションを使用してリポジトリを削除する方が適切です。また、RepManagerではDatabase Controlリポジトリを作成できません。

次のコマンドを実行します。

$ $ORACLE_HOME/sysman/admin/emdrep/bin/RepManager hostname listener_port sid -action drop

注意:
このコマンドにより、データベースは停止モードになります。

停止モードの詳細は、My Oracle Supportノート375946.1「EMCAを実行するとデータベースが停止する」および「DB Controlリポジトリ作成中に新規の接続または操作を実行できない」を参照してください。

Database Controlオブジェクトの作成

ここでは、Database Controlオブジェクトを作成するために使用できる3つのオプションについて説明します。

- オプション1: DB Control構成ファイルの作成

- オプション2: Database Controlリポジトリ・オブジェクトおよび構成ファイルの作成

- オプション3: クローニングしたデータベース・ホーム用のDatabase Controlリポジトリ・オブジェクトおよび構成ファイルの作成

オプション1: DB Control構成ファイルの作成

Database Controlオブジェクトの作成に使用できる最初のオプションは、Database Control構成ファイルを作成することです。次のコマンドを使用すると、リポジトリ作成プロセスを実行しないでファイルを作成できます。

単一インスタンス・データベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db

Oracle RACデータベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db -cluster

オプション2: Database Controlリポジトリ・オブジェクトおよび構成ファイルの作成

Database Controlオブジェクトの作成に使用できる2つ目のオプションは、Database Controlリポジトリ・オブジェクトおよび構成ファイルを作成することです。

単一インスタンス・データベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db -repos create

Oracle RACデータベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db -repos create –cluster

オプション3: クローニングしたデータベース・ホーム用のDatabase Controlリポジトリ・オブジェクトおよび構成ファイルの作成

Database Controlオブジェクトの作成に使用できる3つ目のオプションは、次のように、クローニングしたデータベース・ホーム用にDatabase Controlリポジトリ・オブジェクトおよび構成ファイルを作成することです。

単一インスタンス・データベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db -repos recreate

Oracle RACデータベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db -repos recreate -cluster

Database Controlの再作成または再構成

ここでは、Database Controlの再作成または再構成に使用できる2つのオプションについて説明します。

- オプション1: Database Control構成ファイルのみの再作成(リポジトリはそのまま)

- オプション2: Database Control構成ファイルおよびリポジトリの再作成

オプション1: Database Control構成ファイルのみの再作成(リポジトリはそのまま)

Database Controlの再作成に使用できる最初のオプションは、次のように、Database Control構成ファイルのみを再作成することです。

単一インスタンス・データベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db

Oracle RACデータベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db -cluster

オプション2: Database Control構成ファイルおよびリポジトリの再作成

Database Controlの再作成に使用できる2つ目のオプションは、Database Control構成ファイルおよびリポジトリを再作成することです。

単一インスタンス・データベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db -repos recreate

Oracle RACデータベースの場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db -repos recreate -cluster

注意:
このコマンドにより、データベースは停止モードになります。

EMCAのトラブルシューティングのヒント

次の各項では、EMCAを使用してDatabase Controlを構成しているときに考慮する必要があるトラブルシューティングのヒントについて説明します。

- データベースのリスナー・ポート変更後のEMCAの使用方法

- 11g リリース2 Grid Control Agentへのアップグレード

- データベース・ホスト名またはIPアドレス変更時のEMCAの使用方法

- TNS構成が変更された場合のEMCAの使用方法

- デスクトップ・クラス・インストールでのEMCAの使用方法

- EMCAエラー・メッセージの処理

データベースのリスナー・ポート変更後のEMCAの使用方法

Database Controlを構成した後でデータベースのリスナー・ポートを変更すると、データベースの状態がdownと表示されます。新規のリスナー・ポートを使用するようにDatabase Controlを再構成するには、-config dbcontrol db [-cluster]コマンドライン引数を使用してEMCAコマンドを実行します。

11g リリース2 Grid Control Agentのアップグレード

Oracle Enterprise Manager用に構成したOracle Database 11g リリース2データベースまたはOracle ASMインスタンス(Database ControlまたはGrid Control集中エージェント)をOracle Database 11g リリース2(11.2)データベースにアップグレードすると、該当するホスト上でアップグレードしたインスタンスを参照するすべてのEnterprise Managerターゲットが自動的に更新されます。このことが実行されるのは、アップグレードにおいてはインスタンスOracleホーム、ポートまたはその他のターゲットに関係するプロパティに変更が加えられるためです。ただし、ホスト上のこのようなターゲットの中には、Oracle Database 11g リリース2(11.2)Grid Control Agentによって管理されている場合、アップグレード中に正常に更新されないものもあります。

このようなターゲットを更新するには、アップグレードしたデータベース(またはOracle ASM)ターゲットのホームページで、「監視構成」をクリックします。「監視構成」ページでは、Oracleホームやリスナー・ポートなどのプロパティを正しい値に更新できます。

データベース・ホスト名またはIPアドレス変更時のEMCAの使用方法

データベース・ホスト名(ドメイン名を含む)またはIPアドレスが変更された場合は、Database Controlについて、構成を解除した後、emcaコマンドの-repos recreateフラグを使用して再構成します。たとえば、Database Controlを新規ホスト名で再作成するには、次の手順を実行します。

1. 環境でORACLE_HOSTNAME=old_hostnameを設定します。

2. 次のコマンドを実行して、古いdbconsoleの構成を解除します。
単一インスタンス・データベースの場合:

$ $ORACLE_HOME/bin/emca -deconfig dbcontrol db

Oracle RACの場合:

$ $ORACLE_HOME/bin/emca -deconfig dbcontrol db -cluster

3. 環境でORACLE_HOSTNAMEの設定を解除します。

4. 次のいずれかのコマンドを実行して、新規dbconsoleを構成します。
単一インスタンス・データベースの場合は、次のように入力します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db -repos recreate

Oracle RACの場合は、次のように入力します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db -repos recreate -cluster

TNS構成変更時のEMCAの使用方法

TNS構成が変更されたときには、環境変数を設定し、次のコマンドを実行します。

$ emca -config dbcontrol db

デスクトップ・クラス・インストールでのEMCAの使用方法

ホスト名がlocalhostであるデスクトップ・クラス・インストールの場合、
EMCA操作またはemctl操作を実行する前に、環境でORACLE_HOSTNAME=localhostを設定します。

EMCAエラー・メッセージの処理

次に、EMCAエラー・メッセージとその処理手順を示します。

指定した範囲のポートの割当てに失敗しました

次のことを確認します。

- ポートが使用中である場合は解放します。または、EMCAを使用してコマンドライン・オプションで空きポートを指定します。

- ファイアウォールで必要なポートを開き、コマンドラインで空きポートを指定してemca -config dbcontrol db [-cluster]コマンドを再実行します。

- /etc/hostsファイルを確認します。これには物理ホストのエントリが含まれている必要があります。物理ホスト名を確認するには、次のコマンドを入力します。
$ CMD>hostname

次の環境変数を設定します。

$ set ORACLE_HOSTNAME=上記コマンドの出力

次のコマンドを実行してみてください。

$ $ORACLE_HOME/bin/emca -config dbcontrol db

これらの手順を実行して環境変数を修正した後、–config dbcontrol dbコマンドを再実行して、ポートの割当てを再試行します。

リスナーが起動していないか、データベース・サービスがリスナーに登録されていません。

次のことを確認します。

- 指定したポートでリスナーが起動していない場合は、起動した後、EMCAスクリプトを再実行します。

- データベース・サービスがリスナーに登録されているかどうかをチェックしてください。登録されていない場合は、登録した後、EMCAスクリプトを再実行します。

- リスナーが物理ホスト名とは異なるホスト名で構成されている場合は、次のようにDatabase Controlを構成します。
$ set ORACLE_HOSTNAME=リスナー・ホスト

$ $ORACLE_HOME/bin/emca -config dbcontrol db

リスナー・ポートが変更された場合は、新規リスナー・ポートを提供してDatabase Controlを再構成します。

$ $ORACLE_HOME/bin/emca -config dbcontrol db

第II部

Oracle Databaseの構造と記憶域

第II部では、データベース構造を記憶域コンポーネントの観点から説明し、各コンポーネントの作成方法と管理方法について説明します。次の章で構成されます。

- 第11章「制御ファイルの管理」

- 第12章「REDOログの管理」

- 第13章「アーカイブREDOログの管理」

- 第14章「表領域の管理」

- 第15章「データファイルおよび一時ファイルの管理」

- 第16章「UNDOの管理」

- 第17章「Oracle Managed Filesの使用」

11 制御ファイルの管理

この章の内容は、次のとおりです。

- 制御ファイルの概要

- 制御ファイルのガイドライン

- 制御ファイルの作成

- 制御ファイル作成後のトラブルシューティング

- 制御ファイルのバックアップ

- 現行のコピーを使用した制御ファイルのリカバリ

- 制御ファイルの削除

- 制御ファイルのデータ・ディクショナリ・ビュー

関連項目:

- 制御ファイルの概要は、『Oracle Database概要』を参照してください。

- Oracle Databaseサーバーによって作成および管理される制御ファイルの作成方法は、第17章「Oracle Managed Filesの使用」を参照してください。

制御ファイルの概要

制御ファイルはデータベースの物理構造を記録した小さなバイナリ・ファイルであり、すべてのOracle Databaseに含まれています。制御ファイルには、次の情報が格納されています。

- データベース名

- 対応するデータファイルとREDOログ・ファイルの名前と位置

- データベース作成のタイムスタンプ

- 現行のログ順序番号

- チェックポイント情報

制御ファイルは、データベースがオープンしているときに必ずOracle Databaseサーバーが書き込めるように、使用可能にしておく必要があります。制御ファイルがないと、データベースがマウントできず、リカバリが困難になります。

Oracle Databaseの制御ファイルはデータベースとともに作成されます。デフォルトでは、データベースの作成時に、制御ファイルのコピーが少なくとも1つ作成されます。デフォルトで複数のコピーが作成されるオペレーティング・システムもあります。データベース作成時に、制御ファイルのコピーを2つ以上作成することをお薦めします。その後も、制御ファイルを失ったり、制御ファイル内の設定を変更する場合には、制御ファイルを作成できます。

制御ファイルのガイドライン

ここでは、データベースの制御ファイルを管理するためのガイドラインについて説明します。この項の内容は、次のとおりです。

- 制御ファイルのファイル名の指定

- 異なるディスク上での制御ファイルの多重化

- 制御ファイルのバックアップ

- 制御ファイルのサイズ管理

制御ファイルのファイル名の指定

制御ファイル名は、データベース初期化パラメータ・ファイルのCONTROL_FILES初期化パラメータを使用して指定します(「初期制御ファイルの作成」を参照してください)。インスタンスは起動時にすべてのリストされたファイルを認識して開き、データベースの動作中はインスタンスがすべてのリストされた制御ファイルに書き込み、ファイルを維持します。

データベースの作成前にCONTROL_FILESに対してファイルを指定しない場合は、次のように処理されます。

- Oracle Managed Filesを使用していない場合、データベースではデフォルトのファイル名で制御ファイルが作成されます。デフォルトのファイル名はオペレーティング・システムによって異なります。

- Oracle Managed Filesを使用している場合は、この機能を使用可能にするために設定した初期化パラメータによって制御ファイルの名前と位置が決定されます(第17章「Oracle Managed Filesの使用」を参照)。

- Oracle Automatic Storage Management(Oracle ASM)を使用している場合は、不完全なOracle ASMファイル名をDB_CREATE_FILE_DESTおよびDB_RECOVERY_FILE_DEST初期化パラメータに設定できます。Oracle ASMによって、制御ファイルが適切な場所に自動的に作成されます。詳細は、Oracle Automatic Storage Management管理者ガイドのOracle ASMファイル名に関する項、およびOracle ASMを使用するデータベースの作成に関する項を参照してください。

異なるディスク上での制御ファイルの多重化

Oracle Databaseには少なくとも2つの制御ファイルを作成し、各ファイルを異なる物理ディスクに配置するようにします。ディスク障害によって制御ファイルが破損した場合は、対応するインスタンスを必ず停止します。ディスク・ドライブを修復後、他のディスク上にある制御ファイルの正常なコピーを使用して破損した制御ファイルをリストアすると、インスタンスを再起動できます。この場合は、メディア・リカバリは不要です。

多重制御ファイルは、次のように動作します。

- データベースは、データベース初期化パラメータ・ファイルの初期化パラメータCONTROL_FILESにリストされているすべてのファイル名に対して、情報を書き込みます。

- データベースの稼働中に、CONTROL_FILESパラメータにリストされている最初のファイルのみデータベースによって読み込まれます。

- データベースの稼働中に制御ファイルのいずれかが使用できなくなった場合、インスタンスは動作不能になり、異常終了します。

注意:
データベースには最低2つ以上の制御ファイルを作成し、それらを異なる物理ディスク上に配置することをお薦めします。

制御ファイルを多重化する方法の1つは、REDOログが多重化されている場合、REDOログ・グループのメンバーが格納されているすべてのディスク・ドライブに制御ファイルのコピーを格納することです。このようにファイルを配置することによって、単一のディスク障害のために制御ファイルとREDOログ・グループがすべて失われる危険が少なくなります。

制御ファイルのバックアップ

制御ファイルのバックアップは非常に重要です。初期設定時およびデータベースの物理構造を変更したときは、必ずバックアップを作成してください。たとえば、次のような構造上の変更を行った場合は、バックアップを作成する必要があります。

- データファイルの追加、削除または名前変更

- 表領域の追加または削除、表領域の読取り/書込み状態の変更

- REDOログ・ファイルまたはREDOログ・グループの追加と削除

制御ファイルのバックアップ方法については、「制御ファイルのバックアップ」を参照してください。

制御ファイルのサイズ管理

制御ファイルのサイズを決定する主な要因は、対応するデータベースを作成したCREATE DATABASE文のMAXDATAFILES、MAXLOGFILES、MAXLOGMEMBERS、MAXLOGHISTORYおよびMAXINSTANCESパラメータに設定された値です。これらのパラメータの値を大きくすると、対応するデータベースの制御ファイルのサイズも大きくなります。

関連項目:

- 制御ファイルの最大サイズの詳細は、使用しているオペレーティング・システム固有のOracleマニュアルを参照してください。

- CREATE DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

制御ファイルの作成

ここでは、制御ファイルを作成する方法について説明します。この項の内容は、次のとおりです。

- 初期制御ファイルの作成

- 制御ファイルの追加コピーの作成、名前変更および再配置

- 新しい制御ファイルの作成

初期制御ファイルの作成

Oracle Databaseの初期制御ファイルは、CREATE DATABASE文を発行したときに作成されます。制御ファイルの名前は、データベースの作成時に使用される初期化パラメータ・ファイルのCONTROL_FILESパラメータで指定します。CONTROL_FILESで指定するファイル名はパスを含めて完全に指定する必要があり、オペレーティング・システムによって異なります。CONTROL_FILES初期化パラメータの例を次に示します。

CONTROL_FILES = (/u01/oracle/prod/control01.ctl,
/u02/oracle/prod/control02.ctl,
/u03/oracle/prod/control03.ctl)

指定した名前のファイルがデータベースの作成時に存在している場合、CREATE DATABASE文でCONTROLFILE REUSE句を指定しないとエラーが発生します。また、古い制御ファイルのサイズが新しい制御ファイルのSIZEパラメータと異なる場合、REUSE句は使用できません。

制御ファイルのサイズはOracle Databaseの一部のリリースでは異なり、制御ファイルで指定されるファイルの数が変更されるタイミングもリリースによって異なります。MAXLOGFILES、MAXLOGMEMBERS、MAXLOGHISTORY、MAXDATAFILESおよびMAXINSTANCESなどの構成パラメータは制御ファイルのサイズに影響します。

CONTROL_FILES初期化パラメータの値を後で変更して、制御ファイルを追加したり、既存の制御ファイルの名前や位置を変更できます。

関連項目:
制御ファイルの指定方法の詳細は、使用しているオペレーティング・システム固有のOracleマニュアルを参照してください。

制御ファイルの追加コピーの作成、名前変更および再配置

多重化のために制御ファイルのコピーを追加作成するには、既存の制御ファイルを新しい位置にコピーし、そのファイル名を制御ファイルのリストに追加します。同様に、制御ファイルの名前を変更するには、既存の制御ファイルを新しい名前や位置にコピーし、制御ファイル・リストのファイル名を変更します。どちらの場合も、作業中に制御ファイルが変更されないように、制御ファイルをコピーする前にデータベースを停止してください。

現行の制御ファイルの多重化コピーを追加、または制御ファイル名を変更する手順は、次のとおりです。

1. データベースを停止します。

2. オペレーティング・システムのコマンドを使用して、既存の制御ファイルを新しい位置にコピーします。

3. データベース初期化パラメータ・ファイルのCONTROL_FILESパラメータを編集して、新しい制御ファイル名を追加するか、または既存の制御ファイル名を変更します。

4. データベースを再起動します。

新しい制御ファイルの作成

ここでは、新しい制御ファイルを作成する場合とその方法について説明します。

新しい制御ファイルを作成する場合

次の状況の場合に、新しい制御ファイルを作成する必要があります。

- データベースの制御ファイルがすべて破損し、制御ファイルのバックアップがない場合。

- データベース名を変更する場合。
たとえば、分散環境でデータベース名が別のデータベース名と競合する場合は、データベース名を変更します。

注意:
データベース名とDBID(内部データベース識別子)は、DBNEWIDユーティリティを使用して変更できます。このユーティリティの使用の詳細は、『Oracle Databaseユーティリティ』を参照してください。

- 互換性レベルが10.2.0よりも前の値に設定されており、CREATE DATABASEまたはCREATE CONTROLFILEコマンドからの次のいずれかのパラメータに関係のあるデータベース構成の領域を変更する必要がある場合: MAXLOGFILES、MAXLOGMEMBERS、MAXLOGHISTORYおよびMAXINSTANCES。互換性が10.2.0以後の場合、このような変更の際も新しい制御ファイルを作成する必要はなく、制御ファイルは必要に応じて新しい構成情報に対応するように自動的に拡張されます。
たとえば、データベースの作成時、または制御ファイルの再作成時にMAXLOGFILESを3に設定したとします。そして、ALTER DATABASEコマンドを使用してデータベースに4つ目のREDOログ・ファイル・グループを追加するとします。互換性が10.2.0以後に設定されている場合、この変更は可能で、制御ファイルは新しいログ・ファイル情報に対応するように自動的に拡張されます。ただし、互換性が10.2.0よりも前に設定されている場合、ALTER DATABASEコマンドを実行するとエラーが発生し、先に新しい制御ファイルを作成する必要があります。

互換性レベルの詳細は、「COMPATIBLE初期化パラメータの概要」を参照してください。

CREATE CONTROLFILE文

CREATE CONTROLFILE文を使用して、データベースの新しい制御ファイルを作成できます。次の文は、prodデータベース(これまで別のデータベース名を使用していたデータベース)に対する新しい制御ファイルを作成します。

CREATE CONTROLFILE
SET DATABASE prod
LOGFILE GROUP 1 ('/u01/oracle/prod/redo01_01.log',
'/u01/oracle/prod/redo01_02.log'),
GROUP 2 ('/u01/oracle/prod/redo02_01.log',
'/u01/oracle/prod/redo02_02.log'),
GROUP 3 ('/u01/oracle/prod/redo03_01.log',
'/u01/oracle/prod/redo03_02.log')
RESETLOGS
DATAFILE '/u01/oracle/prod/system01.dbf' SIZE 3M,
'/u01/oracle/prod/rbs01.dbs' SIZE 5M,
'/u01/oracle/prod/users01.dbs' SIZE 5M,
'/u01/oracle/prod/temp01.dbs' SIZE 5M
MAXLOGFILES 50
MAXLOGMEMBERS 3
MAXLOGHISTORY 400
MAXDATAFILES 200
MAXINSTANCES 6
ARCHIVELOG;

注意:

- CREATE CONTROLFILE文は、指定したデータファイルとREDOログ・ファイルを破損する可能性があります。ファイル名を省略すると、そのファイルのデータが失われたり、データベース全体にアクセスできなくなる場合があります。この文を発行するときには十分に注意し、必ず「新しい制御ファイルの作成手順」の手順に従ってください。

- 新しい制御ファイルを作成する前にデータベースのFORCE LOGGINGを使用可能にしていて、この設定を引き続き有効にする場合は、CREATE CONTROLFILE文でFORCE LOGGING句を指定する必要があります。「FORCE LOGGINGモードの指定」を参照してください。

関連項目:
CREATE CONTROLFILE文の詳細な構文は、『Oracle Database SQL言語リファレンス』を参照してください。

新しい制御ファイルの作成手順

新しい制御ファイルを作成するには、次の手順を実行します。

1. データベースのデータファイルとREDOログ・ファイルすべてのリストを作成します。
「制御ファイルのバックアップ」に記載されている制御ファイルのバックアップの推奨事項に従っている場合は、現在のデータベース構造を反映するデータファイルとREDOログ・ファイルのリストがすでに作成されています。しかし、そのようなリストがない場合は、次の文を実行することでリストが生成されます。

SELECT MEMBER FROM V$LOGFILE;
SELECT NAME FROM V$DATAFILE;
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'control_files';

このようなリストが手元になく、制御ファイルが破損してデータベースをオープンできない場合は、データベースを構成するデータファイルとREDOログ・ファイルをすべて特定してください。新しい制御ファイルを作成すると、手順5で指定したファイル以外はリカバリできなくなります。さらに、SYSTEM表領域を構成するファイルが1つでも欠落していると、データベースをリカバリできないことがあります。

2. データベースを停止します。
データベースがオープンしている場合は、できるかぎり通常モードでデータベースを停止します。IMMEDIATE句またはABORT句は、他に方法がない場合にのみ使用してください。

3. データベースのすべてのデータファイルとREDOログ・ファイルをバックアップします。

4. 新しいインスタンスを起動します。ただし、データベースのマウントとオープンは行いません。

STARTUP NOMOUNT

5. CREATE CONTROLFILE文を使用して、データベースの新しい制御ファイルを作成します。

制御ファイルに加えて、REDOログ・グループも失ってしまった場合は、新しい制御ファイルの作成時にRESETLOGS句を指定します。この場合は、失ったREDOログをリカバリする必要があります(手順8)。データベースの名前を変更した場合は、必ずRESETLOGS句を指定してください。それ以外の場合は、NORESETLOGS句を選択してください。

6. 新しい制御ファイルのバックアップをオフラインの記憶デバイスに格納します。バックアップ作成の手順については、「制御ファイルのバックアップ」を参照してください。

7. データベースのCONTROL_FILES初期化パラメータを編集し、手順5で作成してデータベースの一部となったすべての制御ファイルを指定します(バックアップ制御ファイルは含めません)。データベースの名前を変更する場合、インスタンスのパラメータ・ファイルのDB_NAMEパラメータを編集して新しい名前を指定します。

8. 必要に応じて、データベースをリカバリします。データベースをリカバリしない場合は、手順9にスキップしてください。

リカバリの一部として制御ファイルを作成している場合は、データベースをリカバリしてください。NORESETLOGS句を使用して新しい制御ファイルを作成した場合(手順5)は、クローズ状態の完全なデータベース・リカバリ操作によってデータベースをリカバリできます。

RESETLOGS句を使用して新しい制御ファイルを作成した場合は、USING BACKUP CONTROL FILEを指定する必要があります。オンラインまたはアーカイブREDOログあるいはデータファイルが失われた場合は、これらのファイルのリカバリ手順に従ってください。

関連項目:
データベースのリカバリ、および失われた制御ファイルのリカバリ方法については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

9. 次のいずれかの方法で、データベースをオープンします。

- リカバリを実行しなかった場合、または手順8でクローズ状態の完全なデータベース・リカバリを実行した場合は、通常の手順でデータベースをオープンします。

ALTER DATABASE OPEN;

- 制御ファイルの作成時にRESETLOGSを指定した場合は、ALTER DATABASE文でRESETLOGSを指定します。

ALTER DATABASE OPEN RESETLOGS;

これでデータベースはオープンされ、使用可能になります。

制御ファイル作成後のトラブルシューティング

CREATE CONTROLFILE文を実行した後で、エラーが発生する場合があります。ここでは、制御ファイルに関連する最も一般的なエラーについて説明します。

- 欠落したファイルや余分なファイルのチェック

- CREATE CONTROLFILEでのエラー処理

欠落したファイルや余分なファイルのチェック

新しい制御ファイルを作成し、それを使用してデータベースをオープンした後、アラート・ログをチェックして、データ・ディクショナリと制御ファイルの間で不整合(データ・ディクショナリにはデータファイルがあるが、制御ファイルには含まれていないなど)が検出されていないかを確認してください。

データ・ディクショナリ内にはデータファイルが存在していて、新しい制御ファイルには含まれていない場合、データベースは制御ファイル内にMISSINGnnnn(nnnnは10進数のファイル番号)という名前のプレースホルダ・エントリを作成します。制御ファイル内のMISSINGnnnnには、オフラインであること、およびメディア・リカバリを必要とすることを示すフラグが設定されます。

MISSINGnnnnに対応する実際のデータファイルが読取り専用または通常のオフラインである場合、MISSINGnnnnの名前を実際のデータファイルの名前に変更することによってデータファイルにアクセス可能になります。MISSINGnnnnに対応するデータファイルが読取り専用または通常のオフラインではない場合、データファイルはメディア・リカバリを必要としますが、RESETLOGSの結果これができないため、名前の変更操作によってデータファイルをアクセス可能にできません。この場合、データファイルを含む表領域を削除する必要があります。

反対に、制御ファイルに指定されているデータファイルがデータ・ディクショナリに存在しない場合、データベースは新しい制御ファイルからそのファイルへの参照を削除します。どちらの場合も、検出された状態を通知するメッセージがアラート・ログに書き込まれます。

CREATE CONTROLFILEでのエラー処理

新しい制御ファイルの作成後、データベースをマウントしてオープンしようとしたときにOracle Databaseでエラー(通常、ORA-01173、ORA-01176、ORA-01177、ORA-01215、ORA-01216のいずれか)が出力された場合、そのエラーの最も可能性の高い原因は、CREATE CONTROLFILE文でファイルを省略したか、またはリストに示されていないファイルを指定したかのいずれかです。この場合は、手順3で作成したバックアップのファイルをリストアし、正しいファイル名を使用して手順4以降を再実行してください。

制御ファイルのバックアップ

制御ファイルをバックアップするには、ALTER DATABASE BACKUP CONTROLFILE文を使用します。次の2つのオプションがあります。

- 次の文を使用して、制御ファイルをバイナリ・ファイル(既存の制御ファイルの複製)にバックアップを作成します。

ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/backup/control.bkp';

- 後で制御ファイルの再作成に使用できるSQL文を生成します。

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

このコマンドによってSQLスクリプトがトレース・ファイルに書き込まれ、これを取得および編集して制御ファイルを再作成できます。トレース・ファイルの名前と場所は、アラート・ログで調べられます。

関連項目:

- 制御ファイルのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 「アラート・ログの表示」

現行のコピーを使用した制御ファイルのリカバリ

ここでは、現行のバックアップまたは多重化コピーから制御ファイルをリカバリする方法について説明します。

制御ファイルのコピーを使用した制御ファイル破損からのリカバリ

この手順では、CONTROL_FILESパラメータで指定されている制御ファイルの1つが破損し、制御ファイルのディレクトリにはまだアクセス可能で、制御ファイルの多重化コピーがある場合を想定しています。

1. インスタンスを停止してから、オペレーティング・システム・コマンドを使用して、破損した制御ファイルに正常なコピーを上書きします。

% cp /u03/oracle/prod/control03.ctl  /u02/oracle/prod/control02.ctl

2. SQL*Plusを起動してデータベースをオープンします。

SQL> STARTUP

制御ファイルのコピーを使用した永続的なメディア障害からのリカバリ

この手順では、永続的なメディア障害のために、CONTROL_FILESパラメータで指定されている制御ファイルの1つにアクセスできず、制御ファイルの多重化コピーがある場合を想定しています。

1. インスタンスを停止してから、オペレーティング・システム・コマンドを使用して、制御ファイルの現行のコピーをアクセス可能な新しい位置にコピーします。

% cp /u01/oracle/prod/control01.ctl  /u04/oracle/prod/control03.ctl

2. 初期化パラメータ・ファイルのCONTROL_FILESパラメータを編集し、破損したファイルの位置を新しい位置に置き換えます。

CONTROL_FILES = (/u01/oracle/prod/control01.ctl,
/u02/oracle/prod/control02.ctl,
/u04/oracle/prod/control03.ctl)

3. SQL*Plusを起動してデータベースをオープンします。

SQL> STARTUP

多重制御ファイルがある場合は、CONTROL_FILES初期化パラメータを編集することで、データベースを迅速に起動できます。破損した制御ファイルをCONTROL_FILES設定から削除すると、即時にデータベースを再起動できます。次に、破損した制御ファイルを再作成し、CONTROL_FILES初期化パラメータにリカバリした制御ファイルを設定してから、データベースを停止し、再起動します。

制御ファイルの削除

たとえば、制御ファイルの位置が不適切な場合は、データベースからその制御ファイルを削除できます。ただし、データベースには常に少なくとも2つの制御ファイルが存在する必要があります。

1. データベースを停止します。

2. データベース初期化パラメータ・ファイルのCONTROL_FILESパラメータを編集して、古い制御ファイル名を削除します。

3. データベースを再起動します。

注意:
この操作では、不要な制御ファイルをディスクから物理的に削除することはできません。データベースから制御ファイルを削除した後、オペレーティング・システムのコマンドを使用して不要なファイルを削除してください。

制御ファイルのデータ・ディクショナリ・ビュー

次のビューには、制御ファイルに関する情報が表示されます。

ビュー

説明

V$DATABASE

制御ファイル内のデータベース情報が表示されます。

V$CONTROLFILE

制御ファイル名が一覧表示されます。

V$CONTROLFILE_RECORD_SECTION

制御ファイルのレコード・セクションに関する情報が表示されます。

V$PARAMETER

CONTROL_FILES初期化パラメータで指定されている制御ファイルの名前が表示されます。

この例では、制御ファイル名が一覧表示されます。

SQL> SELECT NAME FROM V$CONTROLFILE;

NAME
-------------------------------------
/u01/oracle/prod/control01.ctl
/u02/oracle/prod/control02.ctl
/u03/oracle/prod/control03.ctl

12 REDOログの管理

この章の内容は、次のとおりです。

- REDOログの概要

- REDOログの計画

- REDOログ・グループおよびメンバーの作成

- REDOログ・メンバーの再配置および名前変更

- REDOログ・グループおよびメンバーの削除

- ログ・スイッチの強制

- REDOログ・ファイル内のブロックの検証

- REDOログ・ファイルの初期化

- REDOログのデータ・ディクショナリ・ビュー

関連項目:
Oracle Databaseサーバーによって作成および管理されるREDOログ・ファイルの詳細は、第17章「Oracle Managed Filesの使用」を参照してください。

REDOログの概要

リカバリ操作にとって最も重要な構造であるREDOログは、2つ以上の事前に割り当てられたファイルで構成されており、データベースへの変更があるたびにその変更内容が格納されます。Oracle Databaseの各インスタンスには、インスタンス障害の場合にデータベースを保護するためにREDOログが関連付けられています。

REDOスレッド

複数のデータベース・インスタンスに関する内容では、各データベース・インスタンスのREDOログはREDOスレッドとも呼ばれます。標準的な構成では、Oracle Databaseにアクセスするデータベース・インスタンスは1つのみであるため、スレッドは1つしか存在しません。ただし、Oracle Real Application Clusters環境では、複数のインスタンスが単一のデータベースに同時にアクセスし、各インスタンスが専用のREDOスレッドを持ちます。各インスタンスが別々のREDOスレッドを使用するため、1つのセットのREDOログ・ファイルで競合が回避され、その結果、潜在的なパフォーマンスのボトルネックを解消できます。

この章では、標準的な単一インスタンスのOracle Databaseで、REDOログを構成して管理する方法について説明します。文のすべての説明と例では、スレッド番号を1と想定します。Oracle Real Application Clusters環境におけるREDOログ・グループについては、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

REDOログの内容

REDOログ・ファイルには、REDOレコードが書き込まれます。REDOレコードはREDOエントリとも呼ばれ、変更ベクトル(データベース内の単一ブロックに加えられた変更の記述)のグループからなっています。たとえば、従業員表の給与値を変更する場合は、その表のデータ・セグメント・ブロック、UNDOセグメント・データ・ブロックおよびUNDOセグメントのトランザクション表の変更内容を記述する変更ベクトルを含むREDOレコードが生成されます。

REDOエントリには、UNDOセグメントなど、データベースに対するすべての変更の再構築に使用できるデータが記録されます。したがって、REDOログによってロールバック・データも保護されます。REDOデータベースを使用してデータベースをリカバリすると、データベースはREDOレコード内の変更ベクトルを読み込んで変更内容を関連ブロックに適用します。

REDOレコードは、循環方式でシステム・グローバル領域(SGA)のREDOログ・バッファに入れられ(「Oracle DatabaseによるREDOログへの書込み」を参照)、データベースのバックグラウンド・プロセスであるログ・ライター(LGWR)によってREDOログ・ファイルの1つに書き込まれます。トランザクションがコミットされると、LGWRによってそのトランザクションのREDOレコードがSGAのREDOログ・バッファからREDOログ・ファイルに書き込まれ、コミットされた各トランザクションのREDOレコードを識別するためにシステム変更番号(SCN)が割り当てられます。特定のトランザクションに対応付けられたすべてのREDOログ・レコードがディスク上のオンライン・ログに安全に書き込まれた場合にのみ、ユーザー・プロセスはトランザクションがコミットされたことを示す通知を受け取ります。

また、REDOレコードは、対応するトランザクションがコミットされる前にREDOログ・ファイルに書き込むこともできます。REDOログ・バッファが一杯になるか、別のトランザクションがコミットされると、一部のREDOレコードがコミットされていない可能性があっても、LGWRはREDOログ・バッファ内のすべてのREDOログ・エントリをREDOログ・ファイルにフラッシュします。データベースでは、必要に応じて、これらの変更をロールバックできます。

Oracle DatabaseによるREDOログへの書込み

データベースのREDOログは、2つ以上のREDOログ・ファイルから構成されます。データベースでは、一方のファイルのアーカイブ中にも(データベースがARCHIVELOGモードのとき)、他方のファイルが常に書込み可能であることを保証するために、最低2つのファイルを必要とします。詳細は、「アーカイブREDOログの管理」を参照してください。

LGWRは、REDOログ・ファイルに循環方式で書き込みます。つまり、現行のREDOログ・ファイルが一杯になると、LGWRは次に使用可能なREDOログ・ファイルへの書込みを開始します。使用可能な最後のREDOログ・ファイルが一杯になると、LGWRは最初のREDOログ・ファイルに戻って書込みを行い、再び循環を開始します。図12-1は、REDOログ・ファイルへの循環方式の書込みを示しています。各ラインの隣の番号は、LGWRが各REDOログ・ファイルに書き込む順序を示しています。

一杯になったREDOログ・ファイルは、アーカイブが使用可能になっているかどうかに応じて、LGWRで再利用できます。

- アーカイブが使用禁止になっている場合(データベースがNOARCHIVELOGモードのとき)、一杯になったREDOログ・ファイルは、そこに記録された変更がデータファイルに書き込まれた後に使用可能になります。

- アーカイブが有効(データベースがARCHIVELOGモード)の場合は、記録された変更がデータファイルに書き込まれ、さらにそのファイルがアーカイブされた後、一杯になったREDOログ・ファイルをLGWRで使用できるようになります。

図12-1 LGWRによるREDOログ・ファイルの再利用

アクティブ(カレント)および非アクティブなREDOログ・ファイル

Oracle Databaseは、REDOログ・ファイルを一度に1つのみ使用して、REDOログ・バッファから書き込まれたREDOレコードを格納します。LGWRが書込み中のREDOログ・ファイルを現行のREDOログ・ファイルと呼びます。

インスタンス・リカバリに必要なREDOログ・ファイルをアクティブなREDOログ・ファイルと呼びます。また、インスタンス・リカバリには不要なREDOログ・ファイルを非アクティブなREDOログ・ファイルと呼びます。

アーカイブを使用可能にしている場合は(データベースがARCHIVELOGモードのとき)、いずれかのアーカイバ・バックグラウンド・プロセス(ARCn)によって内容がアーカイブされるまで、データベースはアクティブなオンライン・ログ・ファイルの再利用または上書きができません。アーカイブが使用禁止になっている場合(データベースがNOARCHIVELOGモードのとき)は、最後のREDOログ・ファイルが一杯になって非アクティブになると、LGWRは順序内の次のログ・ファイルを上書きして書込みを継続します。

ログ・スイッチとログ順序番号

ログ・スイッチは、データベースが、あるREDOログ・ファイルへの書込みを終了して他のファイルへの書込みを開始するポイントです。現行のREDOログ・ファイルが完全に一杯になり、引き続き次のREDOログ・ファイルへの書込みが必要になると、通常はログ・スイッチが発生します。ただし、ログ・スイッチは、現行のREDOログ・ファイルが完全に一杯になっているかどうかに関係なく、定期的に発生するように構成できます。ログ・スイッチは、手動で強制的に発生させることもできます。

Oracle Databaseは、ログ・スイッチが発生してLGWRが書込みを開始するたびに、各REDOログ・ファイルに新しいログ順序番号を割り当てます。データベースがREDOログ・ファイルをアーカイブしても、そのファイルのログ順序番号は変わりません。一巡して再び使用可能になったREDOログ・ファイルには、次に使用可能なログ順序番号が割り当てられます。

各オンラインREDOログ・ファイルまたはアーカイブREDOログ・ファイルは、そのログ順序番号で一意に識別されます。クラッシュ、インスタンスまたはメディア・リカバリ時に、データベースでは、必要なアーカイブおよびREDOログ・ファイルのログ順序番号を使用して、REDOログ・ファイルが昇順で正しく適用されます。

REDOログの計画

ここでは、データベース・インスタンスのREDOログを構成するときに考慮する必要があるガイドラインについて説明します。この項の内容は、次のとおりです。

- REDOログ・ファイルの多重化

- 異なるディスクへのREDOログ・メンバーの配置

- REDOログ・ファイルのサイズの計画

- REDOログ・ファイルのブロック・サイズの計画

- 適切なREDOログ・ファイル数の選択

- アーカイブ・タイムラグの制御

REDOログ・ファイルの多重化

REDOログそのものに関わる障害から保護するために、Oracle Databaseでは多重REDOログ、つまりREDOログの2つ以上の同一のコピーを異なる場所に自動的に維持する機能を使用できます。これを最大限に活用するには、これらの場所は異なるディスク上に置きます。ただし、REDOログのすべてのコピーが同じディスク上にあっても、冗長性によってI/Oエラー、ファイル破損などに対して保護されます。REDOログ・ファイルを多重化すると、LGWRによって同じREDOログ情報が複数の同一のREDOログ・ファイルに書き込まれるため、REDOログの単一の障害箇所は問題になりません。

多重化を実装するには、REDOログ・ファイルのグループを作成します。グループは、REDOログ・ファイルとその多重化されたコピーで構成されます。それぞれの同一コピーはグループのメンバーと呼ばれます。各REDOログ・グループは、グループ1、グループ2のように数値で定義されます。

図12-2 多重REDOログ・ファイル

図12-2では、A_LOG1とB_LOG1はどちらもグループ1のメンバーで、A_LOG2とB_LOG2はどちらもグループ2のメンバーです。同じグループの各メンバーは同じサイズである必要があります。

LGWRによって割り当てられる同一のログ順序番号で示されるように、ログ・ファイル・グループの各メンバーは同時にアクティブ(LGWRによって同時に書き込まれる)になります。図12-2では、最初にLGWRはA_LOG1およびB_LOG1の両方に同時に書き込みます。次にA_LOG2およびB_LOG2の両方に同時に書き込み、以下同様に続きます。LGWRでは、異なるグループのメンバー(たとえばA_LOG1とB_LOG2)に同時に書き込まれることはありません。

注意:
REDOログ・ファイルは多重化することをお薦めします。これは、リカバリが必要になったときにログ・ファイルのデータが失われていると、致命的な事態を招くおそれがあるためです。REDOログを多重化すると、データベースの実行時のI/Oの量が増加するため注意してください。構成によっては、これによってデータベース・パフォーマンス全体が影響を受けます。

REDOログの障害への対処

LGWRがグループのメンバーに書き込めない場合、データベースはそのメンバーにINVALIDを示すマークを付け、LGWRトレース・ファイルとデータベース・アラート・ログに、アクセス不可能ファイルの問題を示すエラー・メッセージを書き込みます。REDOログ・メンバーが使用不可能な場合のLGWR固有の処理は、次の表に示すように、使用不可能になった理由によって決定します。

条件

LGWRの処理

LGWRがグループ内の最低1つのメンバーに正常に書き込める場合

通常どおり書込みが行われます。LGWRはグループのうち使用可能なメンバーにのみ書き込み、使用不可のメンバーは無視します。

グループをアーカイブする必要があるため、LGWRがログ・スイッチの発生時に次のグループにアクセスできない場合

データベース操作は、グループが使用可能になるか、グループがアーカイブされるまで一時的に停止します。

メディア障害のため、ログ・スイッチの発生時にLGWRが次のグループのどのメンバーにもアクセスできない場合

Oracle Databaseはエラーを返し、データベース・インスタンスは停止します。この場合は、データベース上でREDOログ・ファイルの損失からのメディア・リカバリを実行する必要があります。
データベースのチェックポイントが損失したREDOログを超えて移動した場合、そのREDOログに記録されたデータは、データベースによってデータファイルに保存されているため、メディア・リカバリは必要ありません。アクセスできないREDOログ・グループのみ削除してください。データベースによって不良ログがアーカイブされていない場合は、ALTER DATABASE CLEAR LOGFILE UNARCHIVEDを使用してアーカイブを使用禁止にしてから、ログを削除してください。

LGWRが書込み中に、グループのすべてのメンバーに突然アクセスできなくなった場合

Oracle Databaseはエラーを返し、データベース・インスタンスは即座に停止します。この場合は、メディア・リカバリを実行する必要があります。ログのドライブを不注意からオフにした場合など、ログを含むメディアが実際には失われていなければ、メディア・リカバリは不要です。この場合は、ドライブをオンに戻して、データベースで自動インスタンス・リカバリを実行します。

有効な構成と無効な構成

ほとんどの場合、多重REDOログを対称にします(すべてのREDOログのグループに同じ数のメンバーを使用します)。ただし、データベースにとっては、多重REDOログが対称である必要はありません。たとえば、1つのグループには1つのメンバーのみを含め、他のグループには2つのメンバーを含められます。この構成によって、一時的に一部のREDOログ・メンバーに影響を与えても他のメンバーに影響が及ばないようなディスク障害に対して保護できます。

インスタンスのREDOログに関する唯一の要件は、最低2つのグループを持つことです。図12-3に、多重REDOログに有効な構成と無効な構成を示します。2番目の構成は、グループが1つしかないため無効です。

図12-3 多重REDOログ・ファイルの有効な構成と無効な構成

異なるディスクへのREDOログ・メンバーの配置

多重REDOログ・ファイルを設定する場合は、グループのメンバーを異なる物理ディスク上に配置します。このようにすると、1つのディスクで障害が発生しても、LGWRが使用できなくなるのはグループの1つのメンバーのみで、それ以外のメンバーは引き続きLGWRにアクセスできるので、インスタンスは継続して機能します。

REDOログをアーカイブする場合は、バックグラウンド・プロセスLGWRとARCn間の競合をなくすために、REDOログ・メンバーを複数のディスクに分散します。たとえば、多重化REDOログ・メンバーのグループが2つある場合(二重化REDOログ)、各メンバーを異なるディスクに配置し、アーカイブ先を5つ目のディスクに設定します。このようにすると、LGWR(メンバーへの書込み)とARCn(メンバーの読込み)間の競合は発生しません。

データ・ブロックやREDOレコードの書込み時の競合を減らすために、データファイルもREDOログ・ファイルとは異なるディスク上に配置することをお薦めします。

REDOログ・ファイルのサイズの計画

REDOログ・ファイルのサイズを設定するときは、REDOログをアーカイブするかどうかを考慮してください。REDOログ・ファイルのサイズは、一杯になったグループを1つのオフライン記憶メディア(テープやディスクなど)にアーカイブできるとともに、そのメディア上の未使用領域が最小になるように設定します。たとえば、一杯になった1つのREDOログ・グループを1本のテープにアーカイブし、そのテープの記憶容量の49%が未使用のまま残っているとします。この場合は、REDOログ・ファイルのサイズを小さくして、テープごとに2つずつREDOログ・グループがアーカイブされるように構成することをお薦めします。

同一の多重REDOログ・グループのメンバーは、すべて同じサイズにする必要があります。異なるグループのメンバーは異なるサイズにすることができます。ただし、グループ間でファイル・サイズを変えても特に利点はありません。ログ・スイッチ間にチェックポイントが発生するように設定していない場合は、グループのサイズを同一に設定して、チェックポイントが一定の間隔で発生することを保証してください。

REDOログ・ファイルの最小サイズは4MBです。

関連項目:
使用しているオペレーティング・システム固有のOracleマニュアルを参照してください。REDOログ・ファイルのデフォルトのサイズは、オペレーティング・システムによって異なります。

REDOログ・ファイルのブロック・サイズの計画

2KBから32KBの間で設定可能なデータベース・ブロック・サイズと異なり、REDOログ・ファイルではディスクの物理セクター・サイズと同じブロック・サイズが常にデフォルトとなります。これは通例として512バイトです。

新しい大容量ディスク・ドライブでは、ECC機能およびフォーマット効率向上のために4KBのセクター・サイズを提供しているものもあります。Oracle Databaseプラットフォームの大部分では、この大きい方のセクター・サイズを検出できます。その後、データベースはブロック・サイズが4KBのREDOログ・ファイルをそれらのディスク上に自動的に作成します。

ただし、4KBのブロック・サイズでは、REDO時のディスク領域の消費が増加します。実際に、4KBのブロックと512バイトのブロックではREDO時のディスク領域の消費量は大幅に異なります。V$SESSTATおよびV$SYSSTATビューに格納されている統計を表示して、REDO時のディスク領域の消費量を判別できます。

SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo wastage';

NAME                                  VALUE
-------------------------------- ----------
redo wastage                       17941684

REDO時のディスク領域の消費を増やさないようにするために、エミュレーションモードのディスク(ディスクのインタフェースにおいて512バイトのセクター・サイズをエミュレートする、セクター・サイズが4KBのディスク・ドライブ)を使用している場合は、REDOログのブロック・サイズに512バイトまたは一部のプラットフォームで1KBを指定し、デフォルトの4KBをオーバーライドできます。ただし、REDOログの書込みが4KBの物理セクターの始まりの位置と揃えられていない場合は、パフォーマンスが大幅に低下します。4KBの物理セクターで512バイトのスロット8つのうち7つの位置が揃っていないために、通常はパフォーマンスの低下が発生します。このため、セクター・サイズが4Kのエミュレーションモード・ディスク上でREDOログのブロック・サイズを計画する場合には、パフォーマンスおよびディスク領域の消費のバランスを検討する必要があります。

Oracle Database 11gリリース2以降では、CREATE DATABASE、ALTER DATABASE、およびCREATE CONTROLFILE文内のキーワードBLOCKSIZEによって、オンラインREDOログ・ファイルのブロック・サイズを指定できます。使用可能なブロック・サイズは512、1024、および4096です。

次の文は、ブロックサイズが512バイトのREDOログ・ファイルのグループを追加します。BLOCKSIZE 512の句は、セクター・サイズが512バイトのディスクでは有効ですが、必須ではありません。セクター・サイズが4KBのエミュレーションモードのディスクでは、BLOCKSIZE 512の句がデフォルトの4KBをオーバーライドします。

ALTER DATABASE orcl ADD LOGFILE
GROUP 4 ('/u01/logs/orcl/redo04a.log','/u01/logs/orcl/redo04b.log')
SIZE 100M BLOCKSIZE 512 REUSE;

REDOログ・ファイルのブロック・サイズを確認するには、次の問合せを実行します。

SQL> SELECT BLOCKSIZE FROM V$LOG;

BLOCKSIZE
---------
512

関連項目:

- ALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- V$SESSTATおよびV$SYSSTATビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

適切なREDOログ・ファイル数の選択

データベース・インスタンスに対するREDOログ・ファイルの適切な数を決定する最良の方法は、様々な構成をテストすることです。最適な構成では、LGWRがREDOログ情報を書き込むのを妨げない最小の数がグループ数になります。

データベース・インスタンスに必要なグループが2つのみの場合もあります。また、LGWRが使用可能な再利用グループが常に存在するようにするため、データベース・インスタンスにグループを追加する必要がある場合もあります。テスト中に、現行のREDOログ構成に問題がないかどうかを確認するには、LGWRトレース・ファイルおよびデータベース・アラート・ログの内容を調べるのが最も容易です。チェックポイントが未完了か、またはグループがアーカイブされていないため、LGWRが頻繁にグループを待機することをメッセージが示す場合は、グループを追加してください。

インスタンスのREDOログ構成を設定または変更する前に、REDOログ・ファイル数を制限するパラメータを検討してください。次のパラメータは、データベースに追加できるREDOログ・ファイルの数を制限します。

- CREATE DATABASE文のMAXLOGFILESパラメータは、データベース当たりのREDOログ・ファイルの最大グループ数を決定します。グループの値は1からMAXLOGFILESです。互換性レベルが10.2.0より前に設定されている場合、この上限値を変更する唯一の方法はデータベースまたは制御ファイルを再作成することです。したがって、データベースを作成する前にこの上限値を十分検討してください。互換性が10.2.0以上に設定されている場合は、MAXLOGFILES制限を超えることが可能で、制御ファイルは必要に応じて拡張されます。CREATE DATABASE文にMAXLOGFILESパラメータが指定されていない場合は、オペレーティング・システム固有のデフォルト値が使用されます。

- CREATE DATABASE文のMAXLOGMEMBERSパラメータは、グループに含まれるメンバーの最大値を決定します。この上限値を変更する唯一の方法は、MAXLOGFILESの場合と同様、データベースまたは制御ファイルを再作成することです。したがって、データベースを作成する前にこの上限値を十分検討してください。CREATE DATABASE文にMAXLOGMEMBERSパラメータが指定されていない場合は、オペレーティング・システムのデフォルト値が使用されます。

関連項目:

- MAXLOGFILESパラメータおよびMAXLOGMEMBERSパラメータのデフォルト値と有効な値については、オペレーティング・システム固有のOracleマニュアルを参照してください。

- 『Oracle Databaseパフォーマンス・チューニング・ガイド』

アーカイブ・タイムラグの制御

すべての有効なREDOログ・スレッドが定期的に現在のログを切り替えるように強制できます。プライマリ/スタンバイ・データベース構成では、REDOログをプライマリ・サイトにアーカイブし、その後スタンバイ・データベースに送信することによって変更がスタンバイ・データベースに反映されます。スタンバイ・データベースは、プライマリ・データベースのREDOログの変更がアーカイブされたREDOログにアーカイブされ、送信されるまで待機する必要があるため、スタンバイ・データベースに適用されている変更は、プライマリ・データベースで発生している変更から遅れることになります。この遅延を制限するために、ARCHIVE_LAG_TARGET初期化パラメータを設定できます。このパラメータを設定して、遅延時間を秒単位で指定できます。

ARCHIVE_LAG_TARGET初期化パラメータの設定

ARCHIVE_LAG_TARGET初期化パラメータを設定すると、データベースはインスタンスの現行のREDOログを定期的に調べます。次の条件が満たされると、インスタンスはログを切り替えます。

- カレント・ログがn秒前に作成され、カレント・ログのアーカイブ見積り時間がm秒(この時間はカレント・ログで使用されているREDOブロック数に比例する)の場合に、n+mがARCHIVE_LAG_TARGET初期化パラメータの値を超えている。

- カレント・ログにREDOレコードが含まれている。

Oracle Real Application Clusters環境では、他のスレッドが遅れている場合、前述の条件を検出したインスタンスによって他のスレッドも切り替えられ、ログがアーカイブされます。これは、Oracle Real Application Clustersで2つのノードを持つプライマリ/セカンダリ構成を実行しているときのように、クラスタ内に他のインスタンスよりも稼働率の低いインスタンスがある場合に特に有効です。

ARCHIVE_LAG_TARGET初期化パラメータは、データベースの現在のログの持続時間の上限を秒単位で指定します。予測されるアーカイブ時間も考慮されるため、これは厳密なログ切替え時間ではありません。

次の初期化パラメータ設定では、ログ・スイッチ間隔を30分(標準的な値)に設定します。

ARCHIVE_LAG_TARGET = 1800

0(ゼロ)を指定すると、時間ベースのログ・スイッチ機能は使用禁止になります。これがデフォルトの設定です。

スタンバイ・データベースが存在していなくても、ARCHIVE_LAG_TARGET初期化パラメータを設定できます。たとえば、強制的にログ・スイッチを発生させてアーカイブを行うために、ARCHIVE_LAG_TARGET初期化パラメータを設定できます。

ARCHIVE_LAG_TARGETは動的パラメータで、ALTER SYSTEM SET文を使用して設定できます。

注意:
Oracle Real Application Clusters環境では、すべてのインスタンスのARCHIVE_LAG_TARGETパラメータに同じ値を指定する必要があります。異なる値を設定すると、予測できない動作が発生します。

ARCHIVE_LAG_TARGETの設定に影響する要因

ARCHIVE_LAG_TARGETパラメータを設定するかどうか、またはその設定値を決定するには、次の要因を考慮してください。

- 切替え(およびアーカイブ)に伴うオーバーヘッド

- ログが一杯になったときに発生する通常のログ・スイッチの頻度

- スタンバイ・データベースで許容できるREDO損失の量

指定した間隔より短い頻度ですでにログ・スイッチが自然に発生している状況では、ARCHIVE_LAG_TARGETを設定しても特に利点はありません。ただし、REDOの生成速度が一定でない場合は、時間間隔を指定することで、各カレント・ログが使用される時間範囲の上限を設定できます。

ARCHIVE_LAG_TARGET初期化パラメータに極端に小さい値を指定すると、パフォーマンスに悪影響を及ぼすことがあります。これは、小さい値によって頻繁にログ・スイッチが発生するためです。このパラメータには、プライマリ・データベースのパフォーマンスを低下させないように適切な値を設定してください。

REDOログ・グループおよびメンバーの作成

データベースのREDOログを事前に計画し、データベースの作成時に必要なREDOログ・ファイルのグループとメンバーをすべて作成してください。しかし、グループやメンバーの追加作成が必要な状況もあります。たとえば、REDOログにグループを追加することによって、REDOログ・グループの可用性の問題を解決できます。

新たにREDOログ・グループおよびメンバーを作成するには、ALTER DATABASEシステム権限が必要です。データベースには、最大MAXLOGFILES個までグループを作成できます。

関連項目:
ALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

REDOログ・グループの作成

REDOログ・ファイルの新しいグループを作成するには、SQL文ALTER DATABASEでADD LOGFILE句を指定します。

次の文は、データベースに新しいREDOログ・グループを追加します。

ALTER DATABASE
ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 100M;

注意:
新しいログ・メンバーのフルパス名を入力し、その場所を指定してください。指定しない場合、オペレーティング・システムに応じて、ファイルがデータベース・サーバーのデフォルト・ディレクトリまたはカレント・ディレクトリのいずれかに作成されます。

また、次のようにGROUP句を使用して、グループの識別番号を指定することもできます。

ALTER DATABASE
ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo')
SIZE 100M BLOCKSIZE 512;

グループ番号を使用することによって、REDOログ・グループの管理がより簡単になります。ただし、グループ番号には1からMAXLOGFILESの範囲の値を使用する必要があります。REDOログ・ファイルのグループ番号をスキップする(つまり、グループに10、20、30などの番号を付ける)と、データベースの制御ファイル内で不要な領域が消費されてしまうため、グループ番号はスキップしないでください。

前の文でのBLOCKSIZE句はオプションです。詳細は、「REDOログ・ファイルのブロック・サイズの計画」を参照してください。

REDOログ・メンバーの作成

完全なREDOログ・ファイルのグループを作成する必要がない場合もあります。つまり、グループはすでに存在しているが、そのグループの1つ以上のメンバーが(ディスク障害などにより)削除されたために完全ではない場合です。このような場合は、既存のグループに新しいメンバーを追加できます。

既存のグループ用に新しいREDOログ・メンバーを作成するには、SQL文ALTER DATABASEでADD LOGFILE MEMBER句を指定します。次の文は、REDOログ・グループ2に新しいREDOログ・メンバーを追加します。

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;

ファイル名は指定する必要がありますが、サイズを指定する必要はありません。新しいメンバーのサイズは、既存グループのメンバーのサイズによって決まります。

ALTER DATABASE文を使用するときは、次の例のように、TO句にグループの他のメンバーをすべて指定することによって、目的のグループを選択的に識別できます。

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo'
TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');

注意:
オペレーティング・システム上のファイルを作成する位置を指定するには、新しいログ・メンバーのファイル名を絶対パスで指定してください。そうしないと、ファイルはオペレーティング・システムごとに異なるデータベースのデフォルトのディレクトリまたはカレント・ディレクトリに作成されます。また、新しいログ・メンバーの状態はINVALIDとして表示されるので注意してください。これは正常であり、最初に使用するときにアクティブ(空白)に変更されます。

REDOログ・メンバーの再配置および名前変更

オペレーティング・システムのコマンドを使用してREDOログを再配置し、ALTER DATABASE文を使用してデータベースにそのREDOログの新しい名前(位置)を通知できます。たとえば、REDOログ・ファイルが現在保存されているディスクを削除する場合や、データファイルや複数のREDOログ・ファイルが同一のディスク上に格納されていて、競合を少なくするためにそれらを分離する場合に、この手順が必要となります。

REDOログ・メンバーの名前を変更するには、ALTER DATABASEシステム権限が必要です。さらに、ファイルを目的の位置にコピーするためのオペレーティング・システム権限と、データベースをオープンしてバックアップするための権限が必要となることもあります。

REDOログを再配置したり、データベースにその他の構造上の変更を加えたりする前には、各操作の実行中に発生する問題に備えて、データベース全体のバックアップを作成してください。また、今後発生する可能性のある問題に備えて、一連のREDOログ・ファイルを名前変更または再配置した後、ただちにデータベースの制御ファイルのバックアップを作成してください。

REDOログを再配置する手順は、次のとおりです。これらの手順では、次の状況を想定しています。

- ログ・ファイルは、diskaおよびdiskbという2つのディスク上にあります。

- REDOログは多重化されています。最初のグループはメンバー/diska/logs/log1a.rdoと/diskb/logs/log1b.rdoからなり、2番目のグループはメンバー/diska/logs/log2a.rdoと/diskb/logs/log2b.rdoからなっています。

- diskaにあるREDOログ・ファイルをdiskcに再配置する必要があります。新しいファイル名には新しい位置が反映され、/diskc/logs/log1c.rdoおよび/diskc/logs/log2c.rdoとなります。

REDOログ・メンバーの名前変更の手順

1. データベースを停止します。

SHUTDOWN

2. REDOログ・ファイルを新しい位置にコピーします。
REDOログ・メンバーなどのオペレーティング・システム・ファイルは、適切なオペレーティング・システム・コマンドを使用してコピーする必要があります。ファイルのコピーに関する説明は、オペレーティング・システム固有のマニュアルを参照してください。

注意:
SQL*PlusのHOSTコマンドを使用すると、既存のSQL*Plusを終了せずにオペレーティング・システム・コマンドを使用してファイルをコピーできます(その他のオペレーティング・システムのコマンドも実行できます)。HOSTという語のかわりに1文字を使用するオペレーティング・システムもあります。たとえば、UNIXでは感嘆符(!)が使用できます。

次の例では、オペレーティング・システム・コマンド(UNIX)を使用して、REDOログ・メンバーを新しい位置に移動しています。

mv /diska/logs/log1a.rdo /diskc/logs/log1c.rdo
mv /diska/logs/log2a.rdo /diskc/logs/log2c.rdo

3. データベースを起動して、マウントします。ただし、オープンはしません。

CONNECT / as SYSDBA
STARTUP MOUNT

4. REDOログ・メンバーの名前を変更します。
ALTER DATABASE文でRENAME FILE句を使用して、データベースのREDOログ・ファイルの名前を変更します。

ALTER DATABASE
RENAME FILE '/diska/logs/log1a.rdo', '/diska/logs/log2a.rdo'
TO '/diskc/logs/log1c.rdo', '/diskc/logs/log2c.rdo';

5. 通常の操作を実行するためにデータベースをオープンします。
REDOログの変更は、データベースがオープンされたときに有効となります。

ALTER DATABASE OPEN;

REDOログ・グループおよびメンバーの削除

場合によっては、REDOログ・メンバーを含むグループ全体を削除できます。たとえば、インスタンスのREDOログのグループ数を少なくする場合などです。また、1つ以上の特定のREDOログ・メンバーの削除が必要になる場合もあります。たとえば、ディスク障害が発生した場合は、アクセスできないファイルに書き込まれないように、障害のあったディスク上のREDOログ・ファイルをすべて削除します。これ以外にも、特定のREDOログ・ファイルが不要になることがあります。たとえば、適切ではない位置にファイルを配置した場合です。

ログ・グループの削除

REDOログ・グループを削除するには、ALTER DATABASEシステム権限が必要です。REDOログ・グループを削除する前に、次の制限と注意点について検討してください。

- グループ内のメンバー数にかかわらず、インスタンスには少なくとも2つのREDOログ・ファイルのグループが必要です。(1つのグループは1つ以上のメンバーから構成されます。)

- REDOログ・グループは、非アクティブである場合にのみ削除できます。カレントのグループを削除する必要がある場合は、最初にログ・スイッチを発生させる必要があります。

- 削除する前に、REDOログ・グループがアーカイブされていることを確認します(アーカイブが使用可能になっている場合)。アーカイブされているかどうかを確認するには、V$LOGビューを使用します。

SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;

GROUP# ARC STATUS
--------- --- ----------------
1 YES ACTIVE
2 NO  CURRENT
3 YES INACTIVE
4 YES INACTIVE

SQL文ALTER DATABASEにDROP LOGFILE句を指定して、REDOログ・グループを削除します。

次の文は、REDOログ・グループ3を削除します。

ALTER DATABASE DROP LOGFILE GROUP 3;

データベースからREDOログ・グループを削除するときは、Oracle Managed Files機能を使用していないかぎり、オペレーティング・システム・ファイルはディスクから削除されません。より正確に言えば、対応するデータベースの制御ファイルが更新されて、そのグループのメンバーがデータベース構造から削除されます。REDOログ・グループを削除した後は、この処理が正常に終了したことを確認してから、適切なオペレーティング・システム・コマンドを使用して、削除したREDOログ・ファイルを実際に削除します。

Oracle Managed Files機能を使用している場合は、オペレーティング・システム・ファイルのクリーン・アップが自動的に実行されます。

REDOログ・メンバーの削除

REDOログ・メンバーを削除するには、ALTER DATABASEシステム権限が必要です。各REDOログ・メンバーを削除する前に、次の制限と注意点について検討してください。

- REDOログ・ファイルを削除することにより、多重REDOログ・ファイルを一時的に非対称にしても問題はありません。たとえば、多重化したREDOログ・ファイルのグループを使用している場合、他のすべてのグループにメンバーが2つずつ残っていても、あるグループのメンバーを1つ削除できます。ただし、すべてのグループに少なくともメンバーが2つ存在するように、この状態をただちに訂正し、REDOログの単一の障害箇所が発生する可能性を取り除いてください。

- グループ内のメンバー数にかかわらず、インスタンスには常に、少なくとも2つの有効なREDOログ・ファイル・グループが必要です。(1つのグループは1つ以上のメンバーから構成されます。)削除するメンバーがグループの最後の有効なメンバーである場合は、他のメンバーが有効にならないかぎり、そのメンバーを削除できません。REDOログ・ファイルの状態を確認するには、V$LOGFILEビューを使用します。REDOログ・ファイルは、データベースがアクセスできないとINVALIDになります。データベースがそのログ・ファイルを完全でない、または正しくないと判断すると、そのログ・ファイルはSTALEになります。この失効したログ・ファイルは、次にそのグループがアクティブ・グループになったときに、再び有効になります。

- REDOログ・メンバーは、アクティブまたはカレント・グループの一部ではない場合のみ削除できます。アクティブ・グループのメンバーを削除する場合は、最初にログ・スイッチを発生させます。

- メンバーを削除する前に、そのREDOログ・メンバーが属するグループがアーカイブされていることを確認します(アーカイブが使用可能になっている場合)。アーカイブされているかどうかを確認するには、V$LOGビューを使用します。

非アクティブである特定のREDOログ・メンバーを削除するには、ALTER DATABASE文でDROP LOGFILE MEMBER句を指定します。

次の文は、REDOログ/oracle/dbs/log3c.rdoを削除します。

ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';

データベースからREDOログ・メンバーを削除しても、オペレーティング・システム・ファイルはディスクから削除されません。より正確に言えば、対応するデータベースの制御ファイルが更新されて、データベース構造からメンバーが削除されます。REDOログ・ファイルを削除した後は、この処理が正常に終了したことを確認してから、適切なオペレーティング・システム・コマンドを使用して、削除したREDOログ・ファイルを実際に削除します。

アクティブ・グループのメンバーを削除するには、最初にログ・スイッチを発生させる必要があります。

ログ・スイッチの強制

ログ・スイッチは、LGWRがあるREDOログ・グループへの書込みを中止して、別のログ・グループへの書込みを開始するときに発生します。デフォルトでは、現行のREDOログ・ファイル・グループが一杯になると、ログ・スイッチが自動的に発生します。

REDOログのメンテナンス操作を実行するために、ログ・スイッチを強制的に発生させて、現在アクティブなグループを非アクティブの状態に変更できます。たとえば、現在アクティブなグループを削除する場合は、アクティブでない状態になるまでそのグループを削除できません。また、現在アクティブなグループのメンバーが完全に一杯になる前に、特定の時点でそのグループをアーカイブする必要がある場合にも、ログ・スイッチの強制的な実行が必要です。このオプションは、一杯になるまで長い時間を必要とする大きなREDOログ・ファイルが含まれた構成で有効です。

ログ・スイッチを強制するには、ALTER SYSTEM権限が必要です。ALTER SYSTEM文でSWITCH LOGFILE句を指定します。

次の文は、ログ・スイッチを強制します。

ALTER SYSTEM SWITCH LOGFILE;

REDOログ・ファイル内のブロックの検証

データベースは、チェックサムを使用してREDOログ・ファイル内のブロックを検証するように構成できます。初期化パラメータDB_BLOCK_CHECKSUMをTYPICAL(デフォルト)に設定すると、ディスクに書き込まれる各データベース・ブロック(カレント・ログに書き込まれている各REDOログ・ブロックを含む)に対するチェックサムが計算されます。チェックサムは、ブロックのヘッダーに格納されます。

Oracle Databaseは、チェックサムを使用してREDOログ・ブロック内の破損を検出します。リカバリ処理中にREDOログ・ブロックがアーカイブ・ログから読み込まれるとき、およびブロックがアーカイブ・ログ・ファイルに書き込まれるとき、そのブロックの検証が行われます。破損が検出されると、エラーが発生しアラート・ログに書き込まれます。

REDOログ・ブロックのアーカイブ時に破損が検出されると、システムは、グループ内の別のメンバーからそのブロックを読み込もうとします。REDOログ・グループ内のすべてのメンバーでブロックが破損していると、アーカイブ処理は継続できません。

DB_BLOCK_CHECKSUMパラメータの値は、ALTER SYSTEM文で動的に変更できます。

注意:
DB_BLOCK_CHECKSUMを使用可能にすると、わずかなオーバーヘッドとデータベースのパフォーマンスの低下が発生します。データベースのパフォーマンスを監視して、パフォーマンスを犠牲にしてでもデータ・ブロックのチェックサムを使用して破損を検出する利点があるかを判断してください。

関連項目:
DB_BLOCK_CHECKSUM初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

REDOログ・ファイルの初期化

データベースがオープンしている間にREDOログ・ファイルが破損し、その結果アーカイブが継続できなくなり、データベース・アクティビティが停止することがあります。このような状況では、ALTER DATABASE CLEAR LOGFILE文を使用して、データベースを停止せずにファイルを再初期化できます。

次の文は、REDOログ・グループ3のログ・ファイルを初期化します。

ALTER DATABASE CLEAR LOGFILE GROUP 3;

この文は、REDOログの削除が不可能な次の2つの状況に対応できます。

- ログ・グループが2つのみの場合

- 破損したREDOログ・ファイルがカレント・グループに属する場合

破損したREDOログ・ファイルがアーカイブされていない場合は、この文にUNARCHIVEDキーワードを使用します。

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;

この文によって、破損したREDOログは初期化され、アーカイブを回避できます。初期化されたREDOログは、アーカイブされていなくても使用できます。

バックアップのリカバリに必要なログ・ファイルを初期化すると、そのバックアップからのリカバリ処理ができなくなります。データベースは、そのバックアップからのリカバリ処理ができないことを示すメッセージをアラート・ログに書き込みます。

注意:
アーカイブされていないREDOログ・ファイルを初期化する場合は、データベースのバックアップをもう1つ作成する必要があります。

オフライン表領域をオンラインにするために必要な、アーカイブされていないREDOログを初期化するには、ALTER DATABASE CLEAR LOGFILE文でUNRECOVERABLE DATAFILE句を指定します。

オフライン表領域をオンラインにするために必要なREDOログを初期化すると、その表領域は二度とオンラインにはできません。表領域を削除するか、不完全リカバリを実行する必要があります。正常にオフライン化された表領域には、リカバリは必要ありません。

REDOログのデータ・ディクショナリ・ビュー

次のビューには、REDOログに関する情報が表示されます。

ビュー

説明

V$LOG

制御ファイルのREDOログ・ファイル情報が表示されます。

V$LOGFILE

REDOログ・グループとメンバーおよびメンバーの状態を識別します。

V$LOG_HISTORY

ログの履歴情報が含まれます。

次の問合せは、データベースのREDOログに関する制御ファイル情報を返します。

SELECT * FROM V$LOG;

GROUP# THREAD#   SEQ   BYTES  MEMBERS  ARC STATUS     FIRST_CHANGE# FIRST_TIM
------ ------- ----- -------  -------  --- ---------  ------------- ---------
1       1 10605 1048576        1  YES ACTIVE          11515628 16-APR-00
2       1 10606 1048576        1  NO  CURRENT         11517595 16-APR-00
3       1 10603 1048576        1  YES INACTIVE        11511666 16-APR-00
4       1 10604 1048576        1  YES INACTIVE        11513647 16-APR-00

グループのすべてのメンバーの名前を表示するには、次の問合せを使用します。

SELECT * FROM V$LOGFILE;

GROUP#   STATUS  MEMBER
------  -------  ----------------------------------
1           D:\ORANT\ORADATA\IDDB2\REDO04.LOG
2           D:\ORANT\ORADATA\IDDB2\REDO03.LOG
3           D:\ORANT\ORADATA\IDDB2\REDO02.LOG
4           D:\ORANT\ORADATA\IDDB2\REDO01.LOG

メンバーのSTATUSが空白の場合、そのファイルは使用中です。

関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

13 アーカイブREDOログの管理

この章の内容は、次のとおりです。

- アーカイブREDOログの概要

- NOARCHIVELOGモードとARCHIVELOGモードの選択

- アーカイブの制御

- アーカイブ先の指定

- ログ転送モードの概要

- アーカイブ先の障害管理

- ARCHIVELOGプロセスによって生成されるトレース出力の制御

- アーカイブREDOログに関する情報の表示

関連項目:

- Oracle Databaseサーバーによって作成および管理されるアーカイブREDOログの作成方法は、第17章「Oracle Managed Filesの使用」を参照してください。

- Oracle Real Application Clusters環境でのアーカイブに固有の情報については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

アーカイブREDOログの概要

Oracle Databaseでは、書込み済のREDOログ・ファイル・グループを、アーカイブREDOログと総称される1つ以上のオフラインの保存先に保存できます。REDOログ・ファイルをアーカイブREDOログ・ファイルに変更するプロセスは、アーカイブと呼ばれます。このプロセスを実行できるのは、データベースがARCHIVELOGモードで動作している場合のみです。自動または手動アーカイブを選択できます。

アーカイブREDOログ・ファイルは、REDOログ・グループの書込み済メンバーのいずれかのコピーです。REDOログ・グループの同一メンバーのREDOエントリ、および一意のログ順序番号が含まれています。たとえば、REDOログを多重化しており、グループ1に同一のメンバー・ファイルa_log1とb_log1が含まれている場合、アーカイバ・プロセス(ARCn)によってこれらのメンバー・ファイルのうちの1つがアーカイブされます。a_log1が破損した場合でも、ARCnは同一のb_log1をアーカイブできます。アーカイブREDOログには、アーカイブを有効にした後に作成されたすべてのグループのコピーが含まれます。

データベースがARCHIVELOGモードで稼働しているときは、REDOログ・グループがアーカイブされないかぎり、ログ・ライター・プロセス(LGWR)はREDOログ・グループを再利用(上書き)できません。自動アーカイブが使用可能な場合は、バックグラウンド・プロセスARCnによってアーカイブ操作が自動的に実行されます。データベースは必要に応じて複数のアーカイバ・プロセスを起動して、一杯になったREDOログのアーカイブが遅れないようにします。

アーカイブREDOログは、次の操作に使用できます。

- データベースのリカバリ

- スタンバイ・データベースの更新

- LogMinerユーティリティを使用したデータベースの履歴情報の取得

関連項目:
アーカイブREDOログの使用方法は、次のマニュアルを参照してください。

- 『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

- スタンバイ・データベースの設定とメンテナンスは、『Oracle Data Guard概要および管理』を参照してください。

- LogMinerのPL/SQLパッケージの使用方法は、『Oracle Databaseユーティリティ』を参照してください。

NOARCHIVELOGモードとARCHIVELOGモードの選択

ここでは、データベースをNOARCHIVELOGモードまたはARCHIVELOGモードで稼働する際の考慮点について説明します。この項の内容は、次のとおりです。

- NOARCHIVELOGモードによるデータベースの実行

- ARCHIVELOGモードによるデータベースの実行

一杯になったREDOログ・ファイル・グループをアーカイブ可能にするかどうかは、データベース上で実行されているアプリケーションの可用性と信頼性の要件によって決まります。ディスク障害の発生時にもデータベース内のデータが失われないようにする場合は、ARCHIVELOGモードを使用します。一杯になったREDOログ・ファイルをアーカイブすると、管理作業が増えます。

NOARCHIVELOGモードによるデータベースの実行

データベースをNOARCHIVELOGモードで実行すると、REDOログはアーカイブされません。データベースの制御ファイルは、グループが一杯になってもアーカイブする必要がないことを示します。したがって、ログ・スイッチが発生して、一杯になったグループがアクティブでなくなると、そのグループはLGWRで再利用できるようになります。

NOARCHIVELOGモードでは、データベースはインスタンス障害からは保護されますが、メディア障害からは保護されません。オンラインREDOログ・グループに格納されているデータベースへの最新の変更のみをインスタンスのリカバリに使用できます。データベースがNOARCHIVELOGモードのときにメディア障害が発生した場合、最後にデータベース全体のバックアップを行った時点までのデータベースをリストアできます。そのバックアップ以降のトランザクションはリカバリできません。

NOARCHIVELOGモードでは、オンラインでの表領域のバックアップを実行できず、また、データベースがARCHIVELOGモードだった際に作成したオンラインの表領域バックアップも使用できません。NOARCHIVELOGモードで運用しているデータベースをリストアする場合、使用できるバックアップは、データベースのクローズ中に作成したデータベース全体のバックアップのみです。そのため、データベースをNOARCHIVELOGモードで稼働する場合は、定期的かつ頻繁にデータベース全体のバックアップを実行する必要があります。

ARCHIVELOGモードによるデータベースの実行

データベースをARCHIVELOGモードで実行する場合は、REDOログのアーカイブを使用可能にします。データベースの制御ファイルは、一杯になったREDOログ・ファイルのグループがアーカイブされるまでは、LGWRでこのグループを再使用できないことを示します。一杯になったグループは、ログ・スイッチの発生直後からアーカイブに使用できます。

一杯になったグループのアーカイブには、次のような利点があります。

- データベースのバックアップ、オンラインREDOログおよびアーカイブREDOログ・ファイルが揃っていると、オペレーティング・システムやディスクに障害が発生しても、コミットされたすべてのトランザクションをリカバリできることが保証されます。

- アーカイブ・ログを使用可能にしておく場合、データベースがオープンされていて、システムが正常に使用できるときに実行したバックアップを使用できます。

- オリジナル・データベースのアーカイブREDOログを絶えずスタンバイ・データベースに適用することで、スタンバイをオリジナルとともに最新の状態に保つことができます。

一杯になったREDOログ・ファイルを自動的にアーカイブするようにインスタンスを構成する方法と、手動でアーカイブする方法があります。通常は、自動アーカイブの方が便利で効率的です。図13-1は、アーカイバ・プロセス(この図ではARC0)によって、いっぱいになったREDOログ・ファイルがデータベースのアーカイブREDOログに書き込まれる過程を示しています。

分散データベース内のデータベースをすべてARCHIVELOGモードで操作している場合は、調整式分散データベース・リカバリを実行できます。ただし、分散データベース内のデータベースのいずれかがNOARCHIVELOGモードで操作されている場合、(すべてのデータベースの整合性を維持するために)グローバルな分散データベースのリカバリは、NOARCHIVELOGモードで操作しているデータベース全体の最新のバックアップによって制限されます。

図13-1 ARCHIVELOGモードでのREDOログ・ファイルの使用

ヒント:
アーカイブREDOログ・ファイルとそれに対応するデータベース・バックアップは、ローカル・ディスクからテープなどの永続的なオフライン記憶メディアに移動しておくことをお薦めします。アーカイブ・ログは主としてデータベース・リカバリに使用されるため、プライマリ・データベースに障害が発生した場合でも、これらのログが安全であることを保証する必要があります。

アーカイブの制御

この項では、データベースのアーカイブ・モードを設定する方法と、アーカイブ・プロセスを制御する方法について説明します。次の内容について説明します。

- 初期データベース・アーカイブ・モードの設定

- データベース・アーカイブ・モードの変更

- 手動アーカイブの実行

- アーカイバ・プロセス数の調整

関連項目:
アーカイブ・モードの制御に関する追加情報は、オペレーティング・システム固有のOracleマニュアルを参照してください。

初期データベース・アーカイブ・モードの設定

初期のアーカイブ・モードは、CREATE DATABASE文でデータベース作成の一部として設定します。多くの場合、このプロセスで生成されるREDO情報はアーカイブする必要がないため、データベース作成時にはNOARCHIVELOGモード(デフォルト)を使用できます。初期のアーカイブ・モードを変更するかどうかは、データベースの作成後に決定します。

ARCHIVELOGモードを指定した場合は、アーカイブREDOログ・ファイルのアーカイブ先を初期化パラメータで指定する必要があります(「アーカイブ先の初期化パラメータの設定」を参照)。

データベース・アーカイブ・モードの変更

データベース・アーカイブ・モードを変更するには、ALTER DATABASE文でARCHIVELOG句またはNOARCHIVELOG句を使用します。また、データベース・アーカイブ・モードを変更するには、管理者権限(AS SYSDBA)でデータベースに接続する必要があります。

次の手順は、データベース・アーカイブ・モードをNOARCHIVELOGからARCHIVELOGに切り替えます。

1. データベース・インスタンスを停止します。

SHUTDOWN IMMEDIATE

データベースがオープンされている場合は、アーカイブ・モードを切り替える前にクローズし、対応するインスタンスを停止する必要があります。メディア・リカバリを必要とするデータファイルがある場合は、モードをARCHIVELOGからNOARCHIVELOGに変更できません。

2. データベースをバックアップします。
データベースに重要な変更をする前に、データベースのデータを保護するため必ずバックアップを作成してください。このバックアップは、NOARCHIVELOGモードでのデータベースの最終バックアップとなり、ARCHIVELOGモードへの切替え中に問題が生じた場合に使用できます。データベース・バックアップの作成については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

3. 初期化パラメータ・ファイルを編集して、アーカイブREDOログ・ファイルのアーカイブ先を初期化パラメータで指定します(「アーカイブ先の初期化パラメータの設定」を参照)。

4. 新しいインスタンスを起動し、データベースをマウントします。オープンはしません。

STARTUP MOUNT

アーカイブを使用可能または使用禁止にするには、データベースをマウントして、オープンしないようにする必要があります。

5. データベース・アーカイブ・モードを変更します。通常の操作を実行するためにデータベースをオープンします。

ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

6. データベースを停止します。

SHUTDOWN IMMEDIATE

7. データベースをバックアップします。
データベースのアーカイブ・モードを変更すると、制御ファイルが更新されます。変更後は、すべてのデータベース・ファイルと制御ファイルのバックアップを作成する必要があります。以前のバックアップはNOARCHIVELOGモードで作成されているため、使用できなくなります。

関連項目:
Real Application Clusters使用時のアーカイブ・モード切替えの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

手動アーカイブの実行

「ARCHIVELOGモードによるデータベースの実行」で説明したように、通常は、自動アーカイブの方が便利で効率的です。ただし、データベースの構成は手動アーカイブでのみ実行できます。データベースを手動アーカイブ・モードで操作するには、「データベース・アーカイブ・モードの変更」で説明した手順に従いますが、手順5のALTER DATABASE文を次の文で置き換えます。

ALTER DATABASE ARCHIVELOG MANUAL;

データベースを手動ARCHIVELOGモードで操作している場合は、一杯になったREDOログ・ファイルの非アクティブ・グループをアーカイブしないと、データベース操作が一時的に停止する可能性があります。一杯になったREDOログ・グループを手動でアーカイブするには、管理者権限を使用して接続してください。データベースがマウントされているか、オープンしていることを確認します。手動アーカイブを実行するには、ALTER SYSTEM文でARCHIVE LOG句を指定します。次の文は、アーカイブされていないログ・ファイルをすべてアーカイブします。

ALTER SYSTEM ARCHIVE LOG ALL;

手動アーカイブ・モードを使用している場合、アーカイブ先にスタンバイ・データベースは指定できません。

また、自動アーカイブが使用可能な場合でも、一杯になったREDOログ・メンバーの非アクティブ・グループを別の位置に再度アーカイブする場合などに手動アーカイブを使用できます。この場合は、手動アーカイブが完了していなくてもインスタンスではREDOログ・グループを再利用できるため、ファイルが上書きされる場合があります。このような場合は、アラート・ログにエラー・メッセージが書き込まれます。

アーカイバ・プロセス数の調整

LOG_ARCHIVE_MAX_PROCESSES初期化パラメータは、データベースが最初に起動するARCnプロセスの数を指定します。デフォルトのプロセス数は4です。

追加のARCnプロセスの起動に伴う実行時のオーバーヘッドを回避するには、LOG_ARCHIVE_MAX_PROCESSES初期化パラメータを設定して、インスタンス起動時に開始するARCnプロセスの数(最大30)を指定できます。LOG_ARCHIVE_MAX_PROCESSESパラメータは動的で、ALTER SYSTEM文を使用して変更できます。

次の文は、データベースが起動時に6つのARCnプロセスを起動するようにデータベースを構成します。

ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=6;

また、この文は現在実行中のインスタンスにただちに影響します。ここでは現在実行されているARCnプロセスの数を増加または減少させて6にします。

アーカイブ先の指定

REDOログをアーカイブする前に、アーカイブ先を指定し、アーカイブ先の様々な状態を理解する必要があります。「アーカイブREDOログに関する情報の表示」に示す動的パフォーマンス・ビュー(V$)を使用して、必要なすべてのアーカイブ情報を参照できます。

この項の内容は次のとおりです。

- アーカイブ先の初期化パラメータの設定

- アーカイブ先の状態の理解

- 代替アーカイブ先の指定

アーカイブ先の初期化パラメータの設定

REDOログのアーカイブ先を単一の場所にするか、または複数の場所にするかを選択できます。アーカイブ先は、ローカル(ローカル・ファイル・システムまたはOracle Automatic Storage Management(Oracle ASM)ディスク・グループ内)またはリモート(スタンバイ・データベース上)を選択できます。複数の場所にアーカイブする場合は、一杯になった各REDOログ・ファイルのコピーが各アーカイブ先に書き込まれます。これらの冗長コピーは、アーカイブ先のいずれかで障害が発生した場合でもアーカイブ・ログを常に使用可能にするのに役立ちます。

単一の場所にアーカイブするには、LOG_ARCHIVE_DEST初期化パラメータを使用してアーカイブ先を指定します。複数の場所にアーカイブするには、LOG_ARCHIVE_DEST_n初期化パラメータを使用して2箇所以上の場所にアーカイブするか、またはLOG_ARCHIVE_DESTおよびLOG_ARCHIVE_DUPLEX_DEST初期化パラメータを使用してプライマリおよびセカンダリのアーカイブ先にのみアーカイブすることを選択できます。

ローカル・アーカイブ先の場合、ローカル・ファイル・システムまたはOracle ASMディスク・グループ以外に、高速リカバリ領域にアーカイブできます。データベースは高速リカバリ領域を使用して、バックアップおよびリカバリに関連する様々なファイルを格納し、それらのディスク領域を自動的に管理します。高速リカバリ領域の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

通常、アーカイブ・ログのアーカイブ先はデータベース計画で決定し、データベースのインストール時にアーカイブ先の初期化パラメータを設定します。ただし、ALTER SYSTEMコマンドを使用して、データベースの実行後にアーカイブ先を動的に追加または変更できます。アーカイブ先の変更は、次のログ・スイッチ(自動または手動)で有効になります。

次の表にアーカイブ先の選択肢の要約を示します。この後の各項で、詳細を説明します。

方法

初期化パラメータ

ホスト

例

1

LOG_ARCHIVE_DEST_n
説明:

nは、1から31の整数です。アーカイブ先の1から10はローカルまたはリモートの場所として使用可能です。11から31はリモートのアーカイブ先としてのみ使用可能です。

ローカルまたはリモート

LOG_ARCHIVE_DEST_1 = 'LOCATION = /disk1/arc'
LOG_ARCHIVE_DEST_2 = 'LOCATION=/disk2/arc'

LOG_ARCHIVE_DEST_3 = 'SERVICE=standby1'

2

LOG_ARCHIVE_DESTおよび
LOG_ARCHIVE_DUPLEX_DEST

ローカルのみ

LOG_ARCHIVE_DEST = '/disk1/arc'
LOG_ARCHIVE_DUPLEX_DEST ='/disk2/arc'

方法1: LOG_ARCHIVE_DEST_nパラメータの使用

LOG_ARCHIVE_DEST_nパラメータ(nは1から31の整数)を使用して、1から31の異なるアーカイブ・ログのアーカイブ先を指定します。末尾に番号が付いた各パラメータによって、特定のアーカイブ先を一意に識別します。

LOG_ARCHIVE_DEST_nの位置は、次の表に示すキーワードを使用して指定します。

キーワード

指定内容

例

LOCATION

ローカル・ファイル・システムの位置またはOracle ASMディスク・グループ

LOG_ARCHIVE_DEST_n = 'LOCATION=/disk1/arc'
LOG_ARCHIVE_DEST_n = 'LOCATION=+DGROUP1/orcl/arc_1'

LOCATION

高速リカバリ領域

LOG_ARCHIVE_DEST_n = 'LOCATION=USE_DB_RECOVERY_FILE_DEST'

SERVICE

Oracle Netのサービス名を介したリモート・アーカイブ。

LOG_ARCHIVE_DEST_n = 'SERVICE=standby1'

LOCATIONキーワードを使用する場合は、次のいずれかを指定します。

- オペレーティング・システムのローカル・ファイル・システムの有効なパス名

- Oracle ASMディスク・グループ

- 高速リカバリ領域を示すキーワードUSE_DB_RECOVERY_FILE_DEST

SERVICEを指定した場合、Oracle Netがスタンバイ・データベースの接続記述子に解決できるネット・サービス名を提供します。この接続記述子には、リモート・データベースへの接続に必要な情報が含まれています。

LOG_ARCHIVE_DEST_n初期化パラメータを使用してアーカイブREDOログのアーカイブ先を設定する手順は、次のとおりです。

1. LOG_ARCHIVE_DEST_n初期化パラメータを設定し、1から31のアーカイブ先を指定します。たとえば、次のように入力します。

LOG_ARCHIVE_DEST_1 = 'LOCATION = /disk1/archive'
LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive'
LOG_ARCHIVE_DEST_3 = 'LOCATION = +RECOVERY/orcl/arc_3'

スタンバイ・データベースにアーカイブする場合は、SERVICEキーワードを使用して有効なネット・サービス名を指定します。たとえば、次のように入力します。

LOG_ARCHIVE_DEST_4 = 'SERVICE = standby1'

2. オプションで、スレッド番号をファイル名の一部に含めるために%tを、ログ順序番号を含めるために%sを、RESETLOGS ID (ub4で表されるタイムスタンプ値)を含めるために%rを使用して、LOG_ARCHIVE_FORMAT初期化パラメータを設定します。ファイル名の左に0(ゼロ)を埋め込むには、大文字(%T、%Sおよび%R)を使用します。

注意:
COMPATIBLE初期化パラメータが10.0.0以上に設定されている場合は、LOG_ARCHIVE_FORMATパラメータを指定するときに、リセットログID(%r)の指定が必要です。このパラメータのデフォルトは、オペレーティング・システムによって異なります。
データベースのインカネーションは、RESETLOGSオプションを指定してデータベースをオープンすると変更されます。%rを指定すると、アーカイブREDOログ・ファイル名からリセットログIDが取得されます。このリカバリ方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

次に、LOG_ARCHIVE_FORMATの設定例を示します。

LOG_ARCHIVE_FORMAT = arch_%t_%s_%r.arc

この設定では、スレッド1、ログ順序番号100、101および102、リセットログID 509210197について次のようなアーカイブ・ログが生成されます。リセットログIDが同一の場合は、すべてのファイルが同じデータベース・インカネーションに含まれることを示します。

/disk1/archive/arch_1_100_509210197.arc,
/disk1/archive/arch_1_101_509210197.arc,
/disk1/archive/arch_1_102_509210197.arc

/disk2/archive/arch_1_100_509210197.arc,
/disk2/archive/arch_1_101_509210197.arc,
/disk2/archive/arch_1_102_509210197.arc

/disk3/archive/arch_1_100_509210197.arc,
/disk3/archive/arch_1_101_509210197.arc,
/disk3/archive/arch_1_102_509210197.arc

方法2: LOG_ARCHIVE_DESTおよびLOG_ARCHIVE_DUPLEX_DESTの使用

最大2つのアーカイブ先ディレクトリを指定するには、LOG_ARCHIVE_DESTパラメータを使用して1次アーカイブ先を指定し、必要に応じてLOG_ARCHIVE_DUPLEX_DESTで2次アーカイブ先を指定します。アーカイブ先は、ローカルである必要があります。データベースでは、REDOログはどちらかのパラメータで指定したすべてのアーカイブ先ディレクトリにアーカイブされます。

方法2を使用する手順は、次のとおりです。

1. LOG_ARCHIVE_DESTおよびLOG_ARCHIVE_DUPLEX_DESTパラメータにアーカイブ先を指定します(ALTER SYSTEM文を使用して、LOG_ARCHIVE_DUPLEX_DESTを動的に指定することもできます)。たとえば、次のように入力します。

LOG_ARCHIVE_DEST = '/disk1/archive'
LOG_ARCHIVE_DUPLEX_DEST = '/disk2/archive'

2. 方法1の手順2で説明したように、LOG_ARCHIVE_FORMAT初期化パラメータを設定します。

注意:
高速リカバリ領域を構成し(DB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZEパラメータを設定)、ローカル・アーカイブ先を指定しない場合、データベースによって自動的に高速リカバリ領域はローカル・アーカイブ先として選択され、LOG_ARCHIVE_DEST_1はUSE_DB_RECOVERY_FILE_DESTに設定されます。

警告:

アーカイブ・ログのアーカイブ先に常に十分なディスク領域があることを確認する必要があります。データベースがログ・ファイルをアーカイブする際にディスクが一杯であるというエラーが発生すると、致命的なエラーとなり、データベースが応答しなくなります。アラート・ログでディスクが一杯であるというメッセージを確認できます。

関連項目:

- REDOログのアーカイブ制御に使用される初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- スタンバイ・アーカイブ先の指定に使用するLOG_ARCHIVE_DEST_n初期化パラメータの使用方法は、『Oracle Data Guard概要および管理』を参照してください。この初期化パラメータには他にも指定できるキーワードがありますが、このマニュアルでは説明されていません。

- ネット・サービス名および接続記述子についての説明は、『Oracle Database Net Services管理者ガイド』を参照してください。

- 高速リカバリ領域の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

アーカイブ先の状態の理解

各アーカイブ先は次のような可変特性を持っており、これらの特性によってその状態が決まります。

- Valid/Invalid: ディスクの位置またはサービス名情報が指定されているかどうか、およびそれらが有効かどうかを示します。

- Enabled/Disabled: 位置の使用可能状態と、データベースがアーカイブ先を使用できるかどうかを示します。

- Active/Inactive: アーカイブ先へのアクセスに問題があったかどうかを示します。

これらの特性は、何通りかの組合せが可能です。インスタンスの各アーカイブ先について現在の状態などの情報を取得するには、V$ARCHIVE_DESTビューを問い合せます。

LOG_ARCHIVE_DEST_STATE_n(nは1から31の整数)初期化パラメータを使用すると、指定したアーカイブ先(n)の使用可能状態を制御できます。

- ENABLEは、アーカイブ先としてデータベースが使用できることを示します。

- DEFERは、その位置が一時的に使用禁止になっていることを示します。

- ALTERNATEは、代替アーカイブ先を示します。代替アーカイブ先の使用可能状態はDEFERです。その親アーカイブ先に障害が発生すると、代替アーカイブ先の使用可能状態はENABLEになります。ALTERNATEは、LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31のアーカイブ先には指定できません。

代替アーカイブ先の指定

別のアーカイブ先に障害が発生した場合にのみ、ある場所がアーカイブ先になるように指定する場合は、その場所を代替アーカイブ先にできます。ローカルとリモート両方のアーカイブ先を代替アーカイブ先にできます。次の例では、LOG_ARCHIVE_DEST_4がLOG_ARCHIVE_DEST_3の代替アーカイブ先になります。

ALTER SYSTEM SET LOG_ARCHIVE_DEST_4 = 'LOCATION=/disk4/arch';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3 = 'LOCATION=/disk3/arch MAX_FAILURE=1
ALTERNATE=LOG_ARCHIVE_DEST_4';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=ALTERNATE;

SQL> SELECT dest_name, status, destination FROM v$archive_dest;

DEST_NAME               STATUS    DESTINATION
----------------------- --------- ----------------------------------------------
LOG_ARCHIVE_DEST_1      VALID     /disk1/arch
LOG_ARCHIVE_DEST_2      VALID     /disk2/arch
LOG_ARCHIVE_DEST_3      VALID     /disk3/arch
LOG_ARCHIVE_DEST_4      ALTERNATE /disk4/arch

ログ転送モードの概要

アーカイブ・ログをアーカイブ先に転送する場合のモードには、ノーマル・アーカイブ転送およびスタンバイ転送という2つのモードがあります。ノーマル転送では、ファイルはローカル・ディスクに転送されます。スタンバイ転送では、ファイルはネットワークを介してローカルまたはリモートのスタンバイ・データベースに転送されます。

通常転送モード

通常転送モードでは、アーカイブ先はデータベースの別のディスク・ドライブです。この構成では、アーカイブがインスタンスに必要な他のファイルと競合せず、短時間で完了します。アーカイブ先は、LOG_ARCHIVE_DEST_nまたはLOG_ARCHIVE_DESTパラメータで指定します。

スタンバイ転送モード

スタンバイ転送モードでは、アーカイブ先はローカルまたはリモートのスタンバイ・データベースです。

注意:
ローカル・ディスク上でスタンバイ・データベースをメンテナンスすることも可能ですが、スタンバイ・データベースはリモート・サイトでメンテナンスし、最大限の障害対策を講じることをお薦めします。

関連項目:

- 『Oracle Data Guard概要および管理』

- サービス名を使用してリモート・データベースに接続する方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

アーカイブ先の障害管理

アーカイブ先で発生した障害が、自動アーカイブ・モードで操作している場合のエラー原因となることがあります。Oracle Databaseには、アーカイブ先の障害に関連する問題を最小限に抑えるためのプロシージャが用意されています。次の各項では、それらのプロシージャについて説明します。

- 正常なアーカイブ先の最小数の指定

- 障害アーカイブ先への再アーカイブ

正常なアーカイブ先の最小数の指定

オプションの初期化パラメータ LOG_ARCHIVE_MIN_SUCCEED_DEST=nによって、データベースがオンライン・ログ・ファイルを再利用できるようになるまでにREDOログ・グループを正常にアーカイブすることが必要なアーカイブ先の最小数が決定されます。デフォルト値は1です。nの有効値は、二重化を使用する場合は1から2、多重化を使用する場合は1から31です。

必須およびオプションのアーカイブ先の指定

LOG_ARCHIVE_DEST_nパラメータを使用すると、アーカイブ先としてOPTIONAL(デフォルト)またはMANDATORYを指定できます。LOG_ARCHIVE_MIN_SUCCEED_DEST=nパラメータでは、すべてのMANDATORYアーカイブ先と、非スタンバイのOPTIONALアーカイブ先をいくつか使用して、LGWRがオンライン・ログを上書きできるかどうかが判断されます。次のルールが適用されます。

- アーカイブ先としてMANDATORY属性を指定しないと、OPTIONALが指定されます。

- ローカル・アーカイブ先を少なくとも1つは指定する必要があります。この場合は、OPTIONALまたはMANDATORYを宣言できます。

- MANDATORY属性は、LOG_ARCHIVE_DEST_1からLOG_ARCHIVE_DEST_10のアーカイブ先にのみ指定できます。

- LOG_ARCHIVE_MIN_SUCCEED_DESTの最小値は1なので、LOG_ARCHIVE_MIN_SUCCEED_DEST=nの値を指定すると、Oracle Databaseでは、少なくとも1つのローカル・アーカイブ先がMANDATORYとして扱われます。

- LOG_ARCHIVE_MIN_SUCCEED_DESTには、アーカイブ先の数を超える値や、MANDATORYのアーカイブ先の数とOPTIONALのローカル・アーカイブ先の数との合計を超える値は指定できません。

- MANDATORYのアーカイブ先にDEFERを指定した場合で、アーカイブ・ログがスタンバイ・サイトに転送されないままオンライン・ログが上書きされるときは、ログを手動でスタンバイ・サイトに転送する必要があります。

アーカイブ・ログを二重化する場合は、LOG_ARCHIVE_DESTおよびLOG_ARCHIVE_DUPLEX_DESTパラメータを使用して、アーカイブ先が必須かオプションかを指定できます。次のルールが適用されます。

- LOG_ARCHIVE_DESTによって宣言されたアーカイブ先は必須です。

- LOG_ARCHIVE_DUPLEX_DESTによって宣言されたアーカイブ先は、LOG_ARCHIVE_MIN_SUCCEED_DEST = 1であればオプション、LOG_ARCHIVE_MIN_SUCCEED_DEST = 2であれば必須です。

正常なアーカイブ先の数の指定: 使用例

LOG_ARCHIVE_DEST_nおよびLOG_ARCHIVE_MIN_SUCCEED_DESTパラメータの関係は、使用例を見ると理解しやすくなります。

オプションのローカル・アーカイブ先へのアーカイブ例

この例では、それぞれOPTIONALとして宣言している3つのローカル・アーカイブ先にアーカイブします。表13-1に、この場合のLOG_ARCHIVE_MIN_SUCCEED_DEST=nに考えられる値を示します。

表13-1 使用例1のLOG_ARCHIVE_MIN_SUCCEED_DESTの値

値

意味

1

データベースは、最低1つのOPTIONALのアーカイブ先へのアーカイブに成功した場合のみログ・ファイルを再利用できます。

2

データベースは、最低2つのOPTIONALのアーカイブ先へのアーカイブに成功した場合のみログ・ファイルを再利用できます。

3

データベースは、OPTIONALのすべてのアーカイブ先へのアーカイブに成功した場合のみログ・ファイルを再利用できます。

4以上

エラーです。値がアーカイブ先数を超えています。

この例は、LOG_ARCHIVE_DEST_nパラメータを使用してアーカイブ先を明示的にMANDATORYに設定していない場合でも、LOG_ARCHIVE_MIN_SUCCEED_DESTが1、2または3に設定されていれば、データベースは必ずこれらの位置の1つ以上に正常にアーカイブすることを示しています。

必須およびオプションのアーカイブ先へのアーカイブ例

次のような状況を考えてみます。

- MANDATORYのアーカイブ先は2つ指定されている。

- OPTIONALのアーカイブ先は2つ指定されている。

- アーカイブ先は、いずれもスタンバイ・データベースではない。

表13-2に、LOG_ARCHIVE_MIN_SUCCEED_DEST=nに考えられる値を示します。

表13-2 使用例2のLOG_ARCHIVE_MIN_SUCCEED_DESTの値

値

意味

1

データベースは、この値を無視してMANDATORYのアーカイブ先の数(この例では2)を使用します。

2

データベースは、OPTIONALのアーカイブ先へのアーカイブに失敗しても、ログ・ファイルを再利用できます。

3

データベースは、最低1つのOPTIONALのアーカイブ先へのアーカイブに成功した場合のみログを再利用できます。

4

データベースは、OPTIONALのアーカイブ先へのアーカイブに両方とも成功した場合のみログを再利用できます。

5以上

エラーです。値がアーカイブ先数を超えています。

この例は、アーカイブ先が少なくなるようにLOG_ARCHIVE_MIN_SUCCEED_DESTを設定した場合でも、データベースはその設定とは無関係に、MANDATORYとして指定されているアーカイブ先に必ずアーカイブすることを示しています。

障害アーカイブ先への再アーカイブ

LOG_ARCHIVE_DEST_nパラメータのREOPEN属性を使用して、エラーの発生後にARCnが障害アーカイブ先への再アーカイブを試行するかどうかと、その時期を指定します。REOPENは、OPENエラーのみでなく、すべてのエラーに適用されます。

REOPEN=nでは、ARCnが障害アーカイブ先の再オープンを試行するまでの最小秒数を設定します。nのデフォルト値は300秒です。値に0(ゼロ)を指定すると、REOPEN属性はオフになり、ARCnは障害発生後にアーカイブを試行しません。REOPENキーワードを指定しない場合、ARCnはエラー発生後にアーカイブ先を再オープンしません。

REOPENを使用して、ARCnが再接続とアーカイブ・ログ転送を試行する回数を指定することはできません。REOPENは成功または失敗で終了します。

OPTIONALアーカイブ先にREOPENを指定すると、データベースはエラーがある場合にオンライン・ログを上書きできます。MANDATORYのアーカイブ先にREOPENを指定すると、正常にアーカイブできない場合に本番データベースの機能が停止します。この状況では、次の方法を検討してください。

- 障害アーカイブ先に手動でアーカイブする。

- アーカイブ先を遅延させる、アーカイブ先をオプションとして指定する、サービスを変更するのいずれかの方法によってアーカイブ先を変更する。

- アーカイブ先を削除する。

REOPENキーワードを使用する場合は、次の点に注意してください。

- ARCnは、ログ・ファイルの先頭からアーカイブ操作を開始する場合にのみ、アーカイブ先を再オープンし、実行中の操作の途中で再オープンすることはありません。ARCnは、常に先頭からログ・コピーを再試行します。

- 特定の時間またはデフォルト設定でREOPENを指定した場合、ARCnは記録されたエラー発生時刻からREOPEN間隔が経過した時刻が現在時刻より前かどうかをチェックします。現在時刻より前であれば、ARCnはログ・コピーを再試行します。

- REOPEN句は、ACTIVE=TRUEのアーカイブ先状態に影響を及ぼします。VALIDおよびENABLED状態は変化しません。

ARCHIVELOGプロセスによって生成されるトレース出力の制御

バックグラウンド・プロセスは適宜、トレース・ファイルに情報を書き込みます。(詳細は、「トレース・ファイルおよびアラート・ログを使用したエラーの監視」を参照してください。)ARCHIVELOGプロセスの場合は、トレース・ファイルに書き込む出力を制御できます。制御するには、LOG_ARCHIVE_TRACE初期化パラメータを設定してトレース・レベルを指定します。設定可能な値は、次のとおりです。

トレース・レベル

意味

0

アーカイブ・ログのトレースは出力されません。これがデフォルトです。

1

REDOログ・ファイルのアーカイブを追跡します。

2

アーカイブ・ログのアーカイブ先ごとにアーカイブ状態を追跡します。

4

アーカイブ操作のフェーズを追跡します。

8

アーカイブ・ログのアーカイブ先のアクティビティを追跡します。

16

アーカイブ・ログのアーカイブ先の詳細アクティビティを追跡します。

32

アーカイブ・ログのアーカイブ先パラメータの変更を追跡します。

64

ARCnプロセスの状態のアクティビティを追跡します。

128

FAL(フェッチ・アーカイブ・ログ)サーバー関連のアクティビティを追跡します。

256

将来のリリースでサポートされる予定です。

512

非同期のLGWRアクティビティを追跡します。

1024

RFS物理クライアントを追跡します。

2048

ARCn/RFSハートビートを追跡します。

4096

リアルタイム適用を追跡します。

8192

REDO適用アクティビティ(メディア・リカバリまたはフィジカル・スタンバイ)を追跡します。

パラメータ値として、必要な各トレース・レベルの合計を設定することにより、トレース・レベルを組み合せることができます。たとえば、LOG_ARCHIVE_TRACE=12に設定すると、トレース・レベル8および4の出力が生成されます。また、プライマリ・データベースとスタンバイ・データベースには、異なる値を設定できます。

LOG_ARCHIVE_TRACEパラメータのデフォルト値は0(ゼロ)です。このレベルでは、エラー条件が発生すると、ARCHIVELOGプロセスによって適切なアラートおよびトレース・エントリが生成されます。

このパラメータの値は、ALTER SYSTEM文で動的に変更できます。次に例を示します。

ALTER SYSTEM SET LOG_ARCHIVE_TRACE=12;

この方法で行った変更は、次回のアーカイブ操作の開始時に有効になります。

関連項目:
このパラメータをスタンバイ・データベースで使用する方法については、『Oracle Data Guard概要および管理』を参照してください。

アーカイブREDOログに関する情報の表示

アーカイブREDOログに関する情報を表示するには、動的パフォーマンス・ビューまたはARCHIVE LOG LISTコマンドを使用します。

この項の内容は次のとおりです。

- アーカイブREDOログ・ビュー

- ARCHIVE LOG LISTコマンド

アーカイブREDOログ・ビュー

アーカイブREDOログに関して役立つ情報を含む動的パフォーマンス・ビューがいくつかあります。次の表に要約を示します。

動的パフォーマンス・ビュー

説明

V$DATABASE

データベースがARCHIVELOGモードとNOARCHIVELOGモードのいずれであるか、およびMANUAL(アーカイブ・モード)が指定されているかどうかが表示されます。

V$ARCHIVED_LOG

制御ファイルに格納されたアーカイブ・ログ履歴情報が表示されます。リカバリ・カタログを使用している場合は、RC_ARCHIVED_LOGビューにも同様の情報が含まれます。

V$ARCHIVE_DEST

現行インスタンス、すべてのアーカイブ先、各アーカイブ先の現行の値、モードおよび状態が表示されます。

V$ARCHIVE_PROCESSES

インスタンスの各アーカイブ・プロセスの状態情報が表示されます。

V$BACKUP_REDOLOG

アーカイブ・ログのバックアップ情報が含まれます。リカバリ・カタログを使用している場合は、RC_BACKUP_REDOLOGビューにも同様の情報が含まれます。

V$LOG

データベースのREDOログ・グループをすべて表示し、その中でアーカイブする必要があるグループを示します。

V$LOG_HISTORY

アーカイブ済ログや各アーカイブ・ログのSCN範囲などのログ履歴情報が含まれます。

たとえば、次の問合せでは、アーカイブする必要があるREDOログ・グループが表示されます。

SELECT GROUP#, ARCHIVED
FROM SYS.V$LOG;

GROUP#     ARC
--------   ---
1   YES
2   NO

現行のアーカイブ・モードを確認するには、V$DATABASEビューを問い合せます。

SELECT LOG_MODE FROM SYS.V$DATABASE;

LOG_MODE
------------
NOARCHIVELOG

関連項目:
動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ARCHIVE LOG LISTコマンド

SQL*PlusコマンドのARCHIVE LOG LISTを使用して、接続されているインスタンスのアーカイブ情報を表示します。次に例を示します。

SQL> ARCHIVE LOG LIST

Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            D:\oracle\oradata\IDDB2\archive
Oldest online log sequence     11160
Next log sequence to archive   11163
Current log sequence           11163

この表示は、現行インスタンスのアーカイブREDOログの設定に関して必要なすべての情報を示します。

- このデータベースは現在ARCHIVELOGモードで操作されています。

- 自動アーカイブは使用可能です。

- アーカイブREDOログのアーカイブ先は、D:\oracle\oradata\IDDB2\archiveです。

- 一杯になったREDOログ・グループのうち、最も古いものの順序番号は11160です。

- 一杯になったREDOログ・グループのうち、次にアーカイブされるものの順序番号は11163です。

- 現行のREDOログ・ファイルの順序番号は11163です。

関連項目:
ARCHIVE LOG LISTコマンドの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

14 表領域の管理

この章の内容は、次のとおりです。

- 表領域を管理するためのガイドライン

- 表領域の作成

- 表領域の非標準のブロック・サイズの指定

- REDOレコードの書込みの制御

- 表領域の可用性の変更

- 読取り専用表領域の使用

- 表領域の変更とメンテナンス

- 表領域の名前変更

- 表領域の削除

- SYSAUX表領域の管理

- ローカル管理表領域の問題の診断と修復

- ローカル管理表領域へのSYSTEM表領域の移行

- データベース間での表領域のトランスポート

- 表領域のデータ・ディクショナリ・ビュー

関連項目:

- データベース構造、領域管理、表領域およびデータファイルの詳細は、『Oracle Database概要』を参照してください。

- Oracle Databaseサーバーによって作成および管理されるデータファイルと一時ファイルの作成方法は、第17章「Oracle Managed Filesの使用」を参照してください。

表領域を管理するためのガイドライン

表領域は、関連する論理構造をグループ化するデータベース記憶域です。データベースのデータファイルは表領域に格納されます。Oracle Databaseの表領域を使用して作業する前に、次の各項で説明するガイドラインについて理解してください。

- 複数の表領域の使用

- ユーザーに対する表領域割当て制限の割当て

複数の表領域の使用

データベース操作を実行する際に複数の表領域を使用すると、システムの柔軟性が向上します。データベースに複数の表領域があるときには、次のことが可能です。

- ユーザー・データをデータ・ディクショナリ・データから分離し、I/Oの競合を減らす。

- あるアプリケーションのデータを別のアプリケーションのデータから分離し、表領域をオフライン化する必要が生じた場合に、複数のアプリケーションが影響を受けないようにする。

- I/Oの競合を低減するために、異なるディスク・ドライブ上に異なる表領域のデータファイルを配置する。

- 別の表領域をオンライン状態に維持しながら、個々の表領域をオフライン化して、全体の可用性を高める。

- 高い更新アクティビティ、読取り専用アクティビティ、一時セグメント記憶域など、異なるタイプのデータベース利用のために異なる表領域を確保することによって、表領域利用を最適化する。

- 表領域のバックアップを個別に作成する。

一部のオペレーティング・システムでは、同時にオープン可能なファイルの数に制限が設けられています。このような制限によって、同時にオンライン化可能な表領域の数に影響が出ることがあります。そのため、使用しているオペレーティング・システムの制限を超えないように、表領域を効率よく計画する必要があります。表領域はデータベースの要件を満たすために必要な数だけ作成し、構成するファイル数もできるかぎり少なくなるようにしてください。表領域のサイズを大きくする必要がある場合は、小さいデータファイルを多数作成するのではなく、1つまたは2つの大きなデータファイルを追加するか、または自動拡張を使用可能にしてデータファイルを作成します。

これらの要素を考慮に入れてデータを再検討し、データベース設計に必要となる表領域の数を決定してください。

ユーザーに対する表領域割当て制限の割当て

表、クラスタ、マテリアライズド・ビュー、索引およびその他のオブジェクトを作成しようとするユーザーには、そのオブジェクトを作成するための権限と、そのオブジェクトのセグメントを格納する表領域の割当て制限(領域の許容または制限)を付与します。

注意:
パッケージ、プロシージャ、ファンクションなどのPL/SQLオブジェクトの場合、ユーザーにはオブジェクトを作成する権限のみが必要です。これらのPL/SQLオブジェクトを作成するための、明示的な表領域割当ては必要ありません。

関連項目:
ユーザーの作成方法および表領域割当て制限の割当て方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

表領域の作成

表領域を作成する場合、表領域を格納するデータベースを作成する必要があります。どのデータベースでも、重要な表領域はSYSTEM表領域で、ここにはデータ・ディクショナリやシステム・ロールバック・セグメントなど、データベース・サーバー機能の基本となる情報が格納されます。SYSTEM表領域は、データベース作成時に最初に作成される表領域です。これは他のすべての表領域と同様に管理されますが、より高いレベルの権限が必要であり、また一部制限事項があります。たとえば、SYSTEM表領域の名前変更、削除、オフライン化は実行できません。

SYSAUX表領域は、データベースの作成時に必ず作成され、SYSTEM表領域の補助表領域として機能します。これには、様々なOracle製品および機能で使用されるスキーマが格納されるため、各製品で独自の表領域を持つ必要がなくなります。SYSTEM表領域と同様に、SYSAUX表領域を管理するためにはより高いレベルのセキュリティが必要で、この表領域の名前変更や削除はできません。SYSAUX表領域の管理については、「SYSAUX表領域の管理」を参照してください。

表領域を作成する手順はオペレーティング・システムによって異なりますが、必ず最初に、オペレーティング・システムを使用して、データファイルが割り当てられるディレクトリ構造を作成する必要があります。ほとんどのオペレーティング・システムでは、新しい表領域を作成するとき、またはデータファイルを加えて既存の表領域を変更するときに、データファイルのサイズと完全なファイル名を指定します。新しい表領域を作成するとき、または既存の表領域を変更するときは、いずれの場合も、データベースは、指定されたとおりにデータファイルを自動的に割り当てて、フォーマットします。

新しい表領域を作成するには、SQL文CREATE TABLESPACEまたはCREATE TEMPORARY TABLESPACEを使用します。表領域を作成するには、CREATE TABLESPACEシステム権限が必要です。後で、ALTER TABLESPACEまたはALTER DATABASE文を使用して、この表領域を変更できます。そのためには、ALTER TABLESPACEまたはALTER DATABASEシステム権限が必要です。

また、CREATE UNDO TABLESPACE文を使用して、UNDOレコードを格納するために特別に設計されたUNDO表領域と呼ばれる特殊なタイプの表領域を作成できます。これらは、データベースが生成するレコードで、リカバリや読込み一貫性のために、またはROLLBACK文の要求を受けて、データベースの変更をロールバックまたは取り消す際に使用されます。UNDO表領域の作成および管理の詳細は、第16章「UNDOの管理」を参照してください。

永続表領域および一時表領域の作成とメンテナンスについては、次の各項で説明します。

- ローカル管理表領域

- bigfile表領域

- 圧縮された表領域

- 暗号化された表領域

- 一時表領域

- 複数の一時表領域: 表領域グループの使用

関連項目:

- データベース作成時に作成される表領域の詳細は、第2章「Oracle Databaseの作成および構成」および使用しているオペレーティング・システムのOracle Databaseインストレーション・ガイドを参照してください。

- CREATE TABLESPACE、CREATE TEMPORARY TABLESPACE、ALTER TABLESPACEおよびALTER DATABASEの各文の構文とセマンティクスの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 非標準のブロック・サイズを持つ表領域の作成に必要な初期化パラメータの詳細は、「データベース・ブロック・サイズの指定」を参照してください。

ローカル管理表領域

ローカル管理表領域では、その表領域内のすべてのエクステント情報がビットマップを使用して追跡されるため、次のような利点があります。

- 領域操作が高速かつ同時に実行されます。領域の割当てと割当て解除によって、ローカル管理のリソース(ヘッダー・ファイルに格納されているビットマップ)が変更されます。

- パフォーマンスが向上します。

- ローカル管理の一時表領域ではUNDOやREDOが生成されないため、読取り可能なスタンバイ・データベースを使用できます。

- AUTOALLOCATE句を指定すると、データベースで適切なエクステント・サイズが自動的に選択されるため、領域割当てが簡素化されます。

- 必要な情報はファイル・ヘッダーとビットマップ・ブロックに格納されるため、データ・ディクショナリに対するユーザーの依存性が低下します。

- ローカル管理表領域では、使用可能エクステントを結合する必要はありません。

SYSTEM表領域も含めて、すべての表領域をローカルに管理できます。

DBMS_SPACE_ADMINパッケージによって、ローカル管理表領域のメンテナンス手順が提供されます。

関連項目:

- 「ローカル管理のSYSTEM表領域の作成」、「ローカル管理表領域へのSYSTEM表領域の移行」および「ローカル管理表領域の問題の診断と修復」

- 単一データファイルまたは一時ファイルのみ格納される、別のタイプのローカル管理表領域を作成する方法の詳細は、「bigfile表領域」を参照してください。

- DBMS_SPACE_ADMINパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ローカル管理表領域の作成

ローカル管理表領域を作成するには、CREATE TABLESPACE文のEXTENT MANAGEMENT句にLOCALを指定します。これは新しい永続表領域に対するデフォルトですが、AUTOALLOCATE句またはUNIFORM句を指定するには、EXTENT MANAGEMENT LOCAL句を指定する必要があります。AUTOALLOCATE句(デフォルト)を指定してデータベースでエクステントを自動的に管理するか、または表領域を特定サイズ(UNIFORM)の均一エクステントで管理するかを指定できます。

様々なサイズのオブジェクトが表領域に含まれ、異なるエクステント・サイズの多数のエクステントが必要と予測される場合は、AUTOALLOCATEを選択してください。領域の割当てと割当て解除を厳密に制御しなくてもよい場合は、AUTOALLOCATEを選択すると表領域の管理作業が簡素化されます。この設定では、ある程度の領域が無駄になるという短所もありますが、ほとんどの場合、Oracle Databaseによって領域が管理されるという利点の方が重要です。

未使用領域の厳密な制御が必要で、オブジェクトに割り当てられる領域、エクステントの数とサイズを正確に予測できる場合は、UNIFORMを選択してください。この設定によって、表領域から使用できない領域がなくなります。

エクステント管理のタイプを明示的に指定しない場合は、Oracle Databaseによってエクステント管理が次のように判断されます。

- CREATE TABLESPACE文にDEFAULT記憶域句を指定しない場合、データベースでは自動割当てのローカル管理表領域が作成されます。

- CREATE TABLESPACE文にDEFAULT記憶域句を指定した場合、データベースでは次のことが考慮されます。

- MINIMUM EXTENT句を指定した場合、MINIMUM EXTENT、INITIALおよびNEXTの値が等しく、PCTINCREASEの値が0 (ゼロ)かどうかが評価されます。その場合、データベースにより、エクステント・サイズ = INITIALで均一なローカル管理表領域が作成されます。MINIMUM EXTENT、INITIALおよびNEXTパラメータの値が等しくない場合、またはPCTINCREASEが0(ゼロ)でない場合は、指定したエクステント記憶域パラメータが無視され、自動割当てのローカル管理表領域が作成されます。

- MINIMUM EXTENT句を指定しなかった場合、データベースは、INITIALおよびNEXTの記憶域値が等しく、PCTINCREASEが0(ゼロ)であるかどうかのみを評価します。その場合、表領域はローカル管理で均一です。それ以外の場合は、ローカル管理の表領域が作成され、自動的に割り当てられます。

次の文は、ローカル管理表領域lmtbsbを作成し、AUTOALLOCATEを指定しています。

CREATE TABLESPACE lmtbsb DATAFILE '/u02/oracle/data/lmtbsb01.dbf' SIZE 50M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE;

AUTOALLOCATEを指定すると、表領域はシステム管理になり、最小エクステント・サイズは64KBとなります。

AUTOALLOCATEのかわりにUNIFORMを指定すると、表領域は均一サイズのエクステントで管理されます。このサイズは、UNIFORMのSIZE句で指定できます。SIZEを指定しないと、デフォルト・サイズは1MBになります。

次の例は、均一の128Kエクステントを持つ表領域を作成します。(2Kブロックを使用するデータベースでは、各エクステントは64のデータベース・ブロックに相当します。)それぞれの128Kエクステントは、このファイルのエクステント・ビットマップ内のビットとして表されます。

CREATE TABLESPACE lmtbsb DATAFILE '/u02/oracle/data/lmtbsb01.dbf' SIZE 50M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;

EXTENT MANAGEMENT LOCALを明示的に指定する場合は、DEFAULTの記憶域句、MINIMUM EXTENTまたはTEMPORARYを指定できません。ローカル管理の一時表領域を作成するには、CREATE TEMPORARY TABLESPACE文を使用します。

注意:
ローカル管理表領域にデータファイルを割り当てる場合は、ユーザー領域の一部である、領域管理に使用されるメタデータ(エクステント・ビットマップまたは領域ヘッダー・セグメント)用の領域を考慮する必要があります。たとえば、エクステント管理句でUNIFORM句を指定し、その際にSIZEパラメータを省略した場合、デフォルトのエクステント・サイズは1MBです。この場合、データファイルに指定されたサイズは1MBよりも大きい(最低1ブロックとビットマップの領域を足したもの)必要があります。

ローカル管理表領域のセグメント領域管理の指定

ローカル管理表領域では、Oracle Databaseでセグメント領域の管理に使用できる方法には、自動と手動の2つがあります。手動セグメント領域管理では、「空きリスト」と呼ばれるリンクされたリストを使用してセグメント内の空き領域を管理しますが、自動セグメント領域管理では、ビットマップを使用します。自動セグメント領域管理の方がより効率的な方法で、すべての新しい永続ローカル管理表領域のデフォルトです。

自動セグメント領域管理では、手動セグメント領域管理に比べて領域の使用効率が向上します。また、ユーザー数やインスタンス数の増加につれて拡張されるという点で自己チューニング型です。Oracle Real Application Clusters環境の場合、自動セグメント領域管理ではインスタンスに対する領域の動的アフィニティに対処できます。さらに、多くの標準的な処理負荷の場合、自動セグメント領域管理を使用したアプリケーションのパフォーマンスは、手動セグメント領域管理を使用して適切にチューニングされたアプリケーションよりも優れています。

自動セグメント領域管理は新しい永続ローカル管理表領域のデフォルトですが、SEGMENT SPACE MANAGEMENT AUTO句を使用して明示的に使用可能にできます。

次の文は、自動セグメント領域管理を行うlmtbsb表領域を作成します。

CREATE TABLESPACE lmtbsb DATAFILE '/u02/oracle/data/lmtbsb01.dbf' SIZE 50M
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;

SEGMENT SPACE MANAGEMENT MANUAL句を指定すると、自動セグメント領域管理を使用禁止にできます。

表領域の作成時に指定するセグメント領域管理方法は、その後表領域に作成されたすべてのセグメントに対して適用されます。表領域のセグメント領域管理モードは変更できません。

注意:

- エクステント管理をLOCAL UNIFORMに設定する場合は、各エクステントに5以上のデータベース・ブロックがあることを確認する必要があります。

- エクステント管理をLOCAL AUTOALLOCATEに設定する場合、およびデータベースのブロック・サイズが16KB以上の場合は、最小で5ブロック(64KBに切り上げられる)のエクステントが作成され、セグメント領域管理が管理されます。

- SYSTEM表領域に自動セグメント領域管理を指定することはできません。

自動セグメント領域管理を使用するローカル管理表領域は、単一ファイル表領域、つまり、bigfile表領域(「bigfile表領域」を参照)としても作成できます。

bigfile表領域

bigfile表領域は、単一で非常に大きい(最大40億ブロック)データファイルを持つ可能性がある表領域です。これに対して、従来のsmallfile表領域には複数のデータファイルを格納できますが、各データファイルは大きくありません。bigfile表領域の利点は、次のとおりです。

- 8000ブロックを持つbigfile表領域には、32TBのデータファイルを格納できます。32000ブロックを持つbigfile表領域には、128TBのデータファイルを格納できます。1つのOracle Databaseのデータファイルの最大数は制限されています(通常は64000ファイル)。したがって、bigfile表領域によって、Oracle Databaseの記憶域容量が大幅に増加します。

- bigfile表領域を使用すると、データベースに必要なデータファイルの数を減らすことができます。また、別の利点として、CREATE DATABASE文とCREATE CONTROLFILE文のDB_FILES初期化パラメータとMAXDATAFILESパラメータを調整すると、データファイル情報に必要なSGA領域の量と制御ファイルのサイズを削減できます。

- bigfile表領域によるデータファイルの透過性によって、データベース管理が簡素化されます。ALTER TABLESPACE文のSQL構文を使用すると、基礎となる各データファイルではなく表領域で操作を実行できます。

bigfile表領域は、自動セグメント領域管理を指定したローカル管理表領域でのみサポートされます。ただし、ローカル管理のUNDO表領域、一時表領域およびSYSTEM表領域の3つは例外です。

注意:

- bigfile表領域は、ストライプ化やRAID、および動的に拡張可能な論理ボリュームをサポートする、自動ストレージ管理(Oracle ASM)などの論理ボリューム・マネージャとともに使用することを目的にしています。

- パラレル問合せ実行およびRMANのバックアップ・パラレル化で問題が生じる可能性があるため、ストライプ化をサポートしていないシステムにはbigfile表領域を作成しないでください。

- 表領域の容量が制限される場合があるため、大規模なファイル・サイズをサポートしていないプラットフォームでbigfile表領域を使用することはお薦めしません。サポートされているファイルの最大サイズの詳細は、ご使用のオペレーティング・システム固有のドキュメントを参照してください。

bigfile表領域の作成

bigfile表領域を作成するには、CREATE TABLESPACE文のBIGFILEキーワード(CREATE BIGFILE TABLESPACE...)を指定します。Oracle Databaseは、自動セグメント領域管理を指定したローカル管理表領域を自動的に作成します。この文には、EXTENT MANAGEMENT LOCALおよびSEGMENT SPACE MANAGEMENT AUTOを必要に応じて指定できます。ただし、EXTENT MANAGEMENT DICTIONARYまたはSEGMENT SPACE MANAGEMENT MANUALを指定すると、データベースはエラーを返します。この文の残りの構文はCREATE TABLESPACE文と同じですが、指定できるのは1つのデータファイルのみです。次に例を示します。

CREATE BIGFILE TABLESPACE bigtbs
DATAFILE '/u02/oracle/data/bigtbs01.dbf' SIZE 50G
...

SIZEは、キロバイト(KB)、メガバイト(MB)、ギガバイト(GB)またはテラバイト(TB)で指定できます。

データベース作成時にデフォルトの表領域タイプをBIGFILEに設定している場合は、CREATE TABLESPACE文にBIGFILEキーワードを指定する必要はありません。この場合、bigfile表領域はデフォルトで作成されます。

データベース作成時にデフォルトの表領域タイプをBIGFILEに設定しておきながら、従来の表領域(smallfile)を作成する場合は、CREATE SMALLFILE TABLESPACE文を指定すると、デフォルトの表領域タイプよりも作成する表領域が優先されます。

関連項目:
「データベース作成時のbigfile表領域のサポート」

bigfile表領域の識別

次のビューには、表領域をbigfile表領域として識別するBIGFILE列が含まれています。

- DBA_TABLESPACES

- USER_TABLESPACES

- V$TABLESPACE

bigfile表領域は、その単一データファイルの相対ファイル番号によっても識別できます。その番号は、ほとんどのプラットフォームで1024ですが、OS/390では4096です。

圧縮された表領域

表領域内に作成されるすべての表がデフォルトで圧縮されるように指定できます。DEFAULTキーワードを使用し、その後に表の作成時に使用する圧縮タイプ句を1つ指定して、表圧縮のタイプを指定します。

次の文は、表領域内に作成されるすべての文で、特に指定がないかぎりOLTP圧縮が使用されることを示しています。

CREATE TABLESPACE ... DEFAULT COMPRESS FOR OLTP ... ;

デフォルトの表領域圧縮指定は、その表領域に表を作成するときに上書きできます。

関連項目:

- 表圧縮の様々なタイプの詳細は、「表圧縮の使用」を参照してください。

- デフォルトの圧縮タイプで表領域を作成するときに使用する正確な構文は、『Oracle Database SQL言語リファレンス』を参照してください。

暗号化された表領域

永続表領域を暗号化して機密データを保護できます。表領域の暗号化はアプリケーションに対して完全に透過的であるため、アプリケーションの変更は不要です。暗号化表領域では、主にデータベース以外の手段による未承認のアクセスからデータを保護します。たとえば、あるOracle Databaseから別のOracle Databaseに移動するため、または格納用のオフサイト施設に移動するために暗号化された表領域をバックアップ・メディアに書き込むと、表領域は暗号化されたままになります。また、暗号化表領域では、データベースのセキュリティ機能を回避して、オペレーティング・システムのファイル・システムから直接データベース・ファイルにアクセスしようとするユーザーからデータを保護します。

表領域の暗号化によって、すべてのセキュリティ問題に対処できるわけではありません。たとえば、データベース内からのアクセスは制御できません。暗号化された表領域に格納されているオブジェクトに対する権限が付与されたユーザーは、追加のパスワードやキーを指定せずにそれらのオブジェクトにアクセスできます。

表領域を暗号化すると、すべての表領域ブロックが暗号化されます。暗号化は、表、クラスタ、索引、LOB(BASICFILEとSECUREFILE)、表パーティション、索引パーティションなどを含むすべてのセグメント・タイプに対してサポートされています。

注意:
暗号化された表領域に格納されているSECUREFILE LOBに対してLOB暗号化を使用する必要はありません。

最大限のセキュリティを確保するために、暗号化された表領域のデータは、UNDO表領域、REDOログおよび一時表領域に書き込まれる場合は自動的に暗号化されます。暗号化されたUNDO表領域や一時表領域を明示的に作成する必要はなく、実際、これらの表領域タイプに暗号化を指定することはできません。

異なる表領域に別のパーティションがあるパーティション表およびパーティション索引表の場合は、同じ表または索引で、暗号化された表領域と暗号化されていない表領域の両方を使用できます。

表領域暗号化はOracle Databaseの透過的データ暗号化機能を使用しますが、この機能を使用するには、データベースのマスター暗号化鍵を保存するためにOracleウォレットを作成する必要があります。暗号化された表領域を作成する場合、および暗号化データを格納または取得する場合は、ウォレットがオープンしている必要があります。ウォレットは、オープンするとすべてのセッションで使用可能になり、明示的にクローズするか、データベースが停止されるまではオープンしたままになります。

表領域を暗号化するには、COMPATIBLE初期化パラメータを11.1.0以上に設定した状態でデータベースをオープンする必要があります。Oracle Database 11g リリース2の新規インストールでは、COMPATIBLEのデフォルト設定は11.2.0です。表領域を作成できるユーザーは、暗号化された表領域も作成できます。

透過的データ暗号化では、次に示すAdvanced Encryption Standard(AES)アルゴリズムやTriple Data Encryption Standard(3DES)アルゴリズムなど、業界標準の暗号化アルゴリズムがサポートされています。

- AES256

- AES192

- AES128

- 3DES168

暗号化キーの長さはアルゴリズム名で示されています。たとえば、AES128アルゴリズムでは128ビットのキーが使用されます。表領域の作成時に使用するアルゴリズムを指定し、異なる表領域で別々のアルゴリズムを使用できます。理論上は、キーの長さが長くなるほどセキュリティが強化されますが、その分、CPUオーバーヘッドがかかります。アルゴリズムをCREATE TABLESPACE分で指定しなかった場合、AES128がデフォルトです。表領域の暗号化にはディスク領域オーバーヘッドは発生しません。

例

次の文では、デフォルトの暗号化アルゴリズムを使用して暗号化された表領域を作成しています。

CREATE TABLESPACE securespace
DATAFILE '/u01/app/oracle/oradata/orcl/secure01.dbf' SIZE 100M
ENCRYPTION
DEFAULT STORAGE(ENCRYPT);

次の文では、AES256アルゴリズムを使用して同じ表領域を作成しています。

CREATE TABLESPACE securespace
DATAFILE '/u01/app/oracle/oradata/orcl/secure01.dbf' SIZE 100M
ENCRYPTION USING 'AES256'
DEFAULT STORAGE(ENCRYPT);

制限事項

暗号化された表領域の制限事項は、次のとおりです。

- 既存の表領域は、ALTER TABLESPACE文で暗号化できません。ただし、データ・ポンプまたはSQL文(CREATE TABLE AS SELECTやALTER TABLE MOVEなど)を使用して、既存の表データを暗号化された表領域に移動できます。

- 暗号化された表領域は、別のデータベースにトランスポートする際に制限を受けます。「トランスポータブル表領域の使用に関する制限事項」を参照してください。

- 暗号化された表領域が含まれたデータベースをリカバリする場合(SHUTDOWN ABORTの後、またはデータベース・インスタンスが停止する致命的なエラーの後など)は、リカバリ・プロセスがデータ・ブロックとREDOを復号化できるように、データベースのマウントの後にOracleウォレットをオープンしてからデータベースをオープンする必要があります。

また、透過的データ暗号化に関する一般的な制限事項は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

表領域の暗号化情報の問合せ

DBA_TABLESPACESとUSER_TABLESPACESのデータ・ディクショナリ・ビューには、ENCRYPTEDという列が含まれています。表領域が暗号化されている場合は、この列にYESと表示されます。

V$ENCRYPTED_TABLESPACESビューには、現在暗号化されているすべての表領域がリストされます。次の問合せでは、暗号化された表領域の名前と暗号化アルゴリズムが表示されます。

SELECT t.name, e.encryptionalg algorithm
FROM  v$tablespace t, v$encrypted_tablespaces e
WHERE t.ts# = e.ts#;

NAME                           ALGORITHM
------------------------------ ---------
SECURESPACE                    AES256

関連項目:

- 透過的データ暗号化の詳細およびウォレットを作成して開く手順は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

- 表領域全体を暗号化する代替方法は、「機密データを格納する列の暗号化」を参照してください。

- Oracle Real Application Clusters環境でOracleウォレットを使用する方法については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- CREATE TABLESPACE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

一時表領域

一時表領域には、セッションの間のみ存続する一時データが格納されます。一時表領域を使用すると、メモリーに格納できない複数のソート操作の同時実行性を改善し、ソート時の領域管理操作の効率を改善できます。

一時表領域は、次の情報を格納するために使用します。

- 中間ソート結果

- 一時表と一時索引

- 一時LOB

- 一時Bツリー

特定のインスタンスのソート操作はすべて、一時表領域内の1つのソート・セグメントを共有し、ソート・セグメントは、一時領域を必要とするソート操作を実行する各インスタンスに存在します。ソート・セグメントは、一時表領域を使用してソート処理を実行する最初の文によってインスタンスの起動後に作成され、停止時にのみ解放されます。

デフォルトでは、新規にOracle Databaseをインストールするたびに、TEMPという単一の一時表領域が作成されます。追加の一時表領域は、CREATE TABLESPACE文で作成できます。一時表領域を各データベース・ユーザーに割り当てるには、CREATE USER文またはALTER USER文を使用します。複数のユーザーが単一の一時表領域を共有できます。

一時表領域には、オブジェクトを明示的に作成できません。

注意:
前述の説明の例外は、一時表です。一時表を作成すると、一時表を新規の一時表領域内に作成する場合を除き、その行はデフォルト一時表領域に格納されます。詳細は、「一時表の作成」を参照してください。

デフォルト一時表領域

一時表領域が明示的に割り当てられていないユーザーは、データベースのデフォルト一時表領域(新規インストールではTEMP)を使用します。データベースのデフォルト一時表領域は次のコマンドで変更できます。

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE tablespace_name;

データベースの現行のデフォルト一時表領域を判断するには、次の問合せを実行します。

SELECT PROPERTY_NAME, PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE
PROPERTY_NAME='DEFAULT_TEMP_TABLESPACE';

PROPERTY_NAME              PROPERTY_VALUE
-------------------------- ------------------------------
DEFAULT_TEMP_TABLESPACE    TEMP

一時表領域の領域割当て

一時表領域のソート・セグメントの領域割当てと割当て解除は、V$SORT_SEGMENTビューを使用して表示できます。V$TEMPSEG_USAGEビューでは、そのセグメント内の現行のソート・ユーザーが識別されます。

一時表領域を使用するソート操作が完了しても、ソート・セグメントに割り当てられたエクステントの割当ては解除されず、エクステントには、使用可能マークおよび再利用可能マークが付けられます。DBA_TEMP_FREE_SPACEビューには、各一時表領域の割当済領域の合計と空き領域が表示されます。詳細は、「一時表領域の領域使用情報の表示」を参照してください。大量の未使用領域があるローカル管理の一時表領域は手動で縮小できます。詳細は、「ローカル管理の一時表領域の縮小」を参照してください。

関連項目:

- ユーザーの作成方法および一時表領域の割当て方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- デフォルト一時表領域の詳細は、『Oracle Database概要』を参照してください。

- V$SORT_SEGMENT、V$TEMPSEG_USAGEおよびDBA_TEMP_FREE_SPACEの各ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- ソートのチューニングの説明は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

ローカル管理の一時表領域の作成

ローカル管理表領域では、領域の管理がより簡単で効率的であるため、一時表領域には理想的です。ローカル管理の一時表領域では、一時表領域外のデータを変更せず、一時表領域データのREDOを生成しない一時ファイルが使用されます。このため、読取り専用データベースまたはスタンバイ・データベースでディスク上ソート操作を実行できます。

一時ファイルの情報を表示するには、データファイルの場合とは異なるビューも使用します。V$TEMPFILEおよびDBA_TEMP_FILESビューは、V$DATAFILEおよびDBA_DATA_FILESビューに相当します。

ローカル管理の一時表領域を作成するには、CREATE TEMPORARY TABLESPACE文を使用します。この文を発行するには、CREATE TABLESPACEシステム権限が必要です。

次の文では、各エクステントが16MBの一時表領域が作成されます。16MBの各エクステント(標準ブロック・サイズが2KBのときは8000個のブロックに相当)は、このファイルのビットマップに1ビットで表されます。

CREATE TEMPORARY TABLESPACE lmtemp TEMPFILE '/u02/oracle/data/lmtemp01.dbf'
SIZE 20M REUSE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16M;

すべての一時表領域は均一サイズのローカル管理エクステントを使用して作成されるため、一時表領域の場合、エクステント管理句はオプションです。SIZEのデフォルトは1MBです。SIZEに別の値を指定するには、前述の文を使用できます。

注意:
オペレーティング・システムによっては、一時ファイルのブロックが実際にアクセスされるまで、一時ファイル用の領域が割り当てられない場合があります。領域の割当ての遅延のため、一時ファイルの作成およびサイズ変更が速くなります。ただし、後で一時ファイルが使用されるときに、十分なディスク領域を使用可能にする必要があります。使用しているシステムでデータベースがこのように一時ファイルを割り当てているかどうかは、オペレーティング・システムのマニュアルを参照して判断してください。

bigfile一時表領域の作成

通常の表領域と同様に、単一ファイル(大型ファイル)の一時表領域を作成できます。単一ファイルの一時表領域を作成するには、CREATE BIGFILE TEMPORARY TABLESPACE文を使用します。bigfile表領域の詳細は、「bigfile表領域の作成」および「bigfile表領域の変更」の項を参照してください。ただし、データファイルのかわりに一時ファイルを使用する一時表領域を作成する点を考慮に入れてください。

一時表領域の領域使用情報の表示

DBA_TEMP_FREE_SPACEディクショナリ・ビューには、各一時表領域の領域使用に関する情報が表示されます。この情報には、割当て済領域と空き領域が含まれます。これらの統計を表示するには、次のコマンドを使用してこのビューを問い合せます。

SELECT * from DBA_TEMP_FREE_SPACE;

TABLESPACE_NAME                     TABLESPACE_SIZE ALLOCATED_SPACE FREE_SPACE
----------------------------------- --------------- --------------- ----------
TEMP                                250609664       250609664       249561088

複数の一時表領域: 表領域グループの使用

ユーザーは、一時表領域グループを使用して複数の表領域から一時領域を消費できます。単一の一時表領域ではなく表領域グループを使用することによって、ソート(特に多数のパーティションがある表でのソート)の結果を保持するのに1つの表領域では不十分な場合に発生する問題を回避できます。パラレル実行のサーバーで表領域グループを使用すると、1回のパラレル操作で複数の一時表領域を使用できます。

表領域グループには、次の特性があります。

- これには1つ以上の表領域が含まれます。1つのグループに含まれる表領域の数に明示的な制限はありません。

- 表領域のネームスペースを共有するため、表領域グループにはグループ内の表領域と同じ名前は付けられません。

- 表領域グループ名は、データベースにデフォルト一時表領域を割り当てるとき、またはユーザーに一時表領域を割り当てるときに表領域名が表示される場所に指定できます。

表領域グループは明示的に作成しません。表領域グループは、最初の一時表領域がグループに割り当てられると暗黙的に作成されます。また、表領域グループに含まれる最後の一時表領域がグループから削除されると、その表領域グループが削除されます。

DBA_TABLESPACE_GROUPSビューには、表領域グループとそのメンバーの表領域がリスト表示されます。

関連項目:
一時表領域または表領域グループのユーザーへの割当ての詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

表領域グループの作成

表領域グループは、CREATE TEMPORARY TABLESPACE文またはALTER TABLESPACE文にTABLESPACE GROUP句を指定したときに、指定した表領域グループが存在していない場合に暗黙的に作成されます。

たとえば、group1およびgroup2が両方とも存在しない場合は、次の文によってこの2つのグループが作成され、それぞれのグループには指定の表領域のみがメンバーとして含まれます。

CREATE TEMPORARY TABLESPACE lmtemp2 TEMPFILE '/u02/oracle/data/lmtemp201.dbf'
SIZE 50M
TABLESPACE GROUP group1;

ALTER TABLESPACE lmtemp TABLESPACE GROUP group2;

表領域グループのメンバーの変更

表領域を既存の表領域グループに追加するには、CREATE TEMPORARY TABLESPACE文またはALTER TABLESPACE文のTABLESPACE GROUP句で既存の表領域グループ名を指定します。

次の文は、表領域を既存のグループに追加します。これにより、表領域lmtemp3を作成してgroup1に追加します。その結果、group1には表領域lmtemp2とlmtemp3が含まれます。

CREATE TEMPORARY TABLESPACE lmtemp3 TEMPFILE '/u02/oracle/data/lmtemp301.dbf'
SIZE 25M
TABLESPACE GROUP group1;

次の文も表領域を既存のグループに追加しますが、この場合、表領域lmtemp2はすでにgroup1に属しているため、実質的にはgroup1からgroup2への移動となります。

ALTER TABLESPACE lmtemp2 TABLESPACE GROUP group2;

この結果、group2にはlmtempとlmtemp2が含まれ、group1にはtmtemp3のみが含まれます。

次の文を使用すると、表領域をグループから削除できます。

ALTER TABLESPACE lmtemp3 TABLESPACE GROUP '';

これによって、表領域lmtemp3はどのグループにも属さなくなります。さらに、group1に属するメンバーがなくなるため、group1は暗黙的に削除されます。

デフォルト一時表領域としての表領域グループの割当て

ALTER DATABASE...DEFAULT TEMPORARY TABLESPACE文を使用して、表領域グループをデータベースのデフォルト一時表領域として割り当てます。次に例を示します。

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE group2;

これで、明示的に一時表領域が割り当てられていないユーザーは表領域lmtempとlmtemp2を使用することになります。

表領域グループがデフォルト一時表領域に指定されている場合、そのグループのメンバーの表領域は削除できません。メンバーの表領域を削除するには、最初にその表領域を表領域グループから削除する必要があります。同様に、単一の一時表領域がデフォルト一時表領域に指定されている場合は、その一時表領域は削除できません。

表領域の非標準のブロック・サイズの指定

DB_BLOCK_SIZE初期化パラメータで指定された標準のデータベース・ブロック・サイズとは異なるブロック・サイズの表領域を作成できます。この機能によって、ブロック・サイズの異なる表領域をデータベース間でトランスポートできます。

CREATE TABLESPACE文のBLOCKSIZE句を使用して、データベースの標準とは異なるブロック・サイズを指定して表領域を作成できます。BLOCKSIZE句を正しく実行するためには、DB_CACHE_SIZEと、少なくとも1つのDB_nK_CACHE_SIZE初期化パラメータをすでに設定している必要があります。さらに、BLOCKSIZE句で指定する整数を1つのDB_nK_CACHE_SIZEパラメータの設定に対応付ける必要があります。冗長な指定になりますが、BLOCKSIZEをDB_BLOCK_SIZE初期化パラメータで指定されている標準のブロック・サイズと同じに指定することも可能です。

次の文は表領域lmtbsbを作成しますが、ブロック・サイズをDB_BLOCK_SIZE初期化パラメータで指定されている標準のデータベース・ブロック・サイズとは異なるサイズにします。

CREATE TABLESPACE lmtbsb DATAFILE '/u02/oracle/data/lmtbsb01.dbf' SIZE 50M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K
BLOCKSIZE 8K;

関連項目:

- 「データベース・ブロック・サイズの指定」

- DB_CACHE_SIZEおよびDB_nK_CACHE_SIZEのパラメータ設定の詳細は、「バッファ・キャッシュ初期化パラメータの設定」を参照してください。

- 「データベース間での表領域のトランスポート」

REDOレコードの書込みの制御

一部のデータベース操作については、データベースでREDOレコードを生成するかどうかを制御できます。REDOを使用しないと、メディア・リカバリはできません。ただし、REDOの生成を抑制するとパフォーマンスが改善されるため、簡単にリカバリできる操作に適している場合があります。たとえば、CREATE TABLE...AS SELECT文は、データベース障害やインスタンス障害が発生した場合に操作を繰り返すことができます。

これらの操作を表領域内のオブジェクトに対して実行するときにREDOを抑制するには、CREATE TABLESPACE文にNOLOGGING句を指定します。この句を指定しないか、かわりにLOGGINGを指定した場合は、表領域内のオブジェクトに変更が行われるとREDOが生成されます。一時セグメントや一時表領域の場合は、ロギング属性に関係なくREDOは生成されません。

表領域レベルで指定するロギング属性は、その表領域内で作成されるオブジェクトのデフォルト属性になります。このデフォルトのロギング属性は、CREATE TABLE文を使用するなど、スキーマ・オブジェクト・レベルでLOGGINGやNOLOGGINGを指定することで上書きできます。

スタンバイ・データベースがある場合は、NOLOGGING句を指定すると、そのスタンバイ・データベースの可用性と精度に問題が生じます。この問題を克服するために、FORCE LOGGINGモードを指定できます。CREATE TABLESPACE文にFORCE LOGGING句を指定すると、表領域内のオブジェクトを変更するすべての操作について、REDOレコードを強制的に生成させることができます。これにより、オブジェクト・レベルでの指定が上書きされます。

FORCE LOGGINGモードの表領域を別のデータベースにトランスポートすると、新しい表領域ではFORCE LOGGINGモードは維持されません。

関連項目:

- NOLOGGINGモードで実行できる操作の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- FORCE LOGGINGモードの詳細と、CREATE DATABASE文でFORCE LOGGING句を使用する効果の詳細は、「FORCE LOGGINGモードの指定」を参照してください。

表領域の可用性の変更

オンラインの表領域をオフライン化すると、一般的な使用を一時的に禁止にできます。データベースの残りの部分はオープンしていて使用可能であり、ユーザーはデータにアクセスできます。逆に、オフライン状態の表領域をオンライン化して、データベース・ユーザーがその表領域内のスキーマ・オブジェクトを使用できるようにすることもできます。表領域の可用性を変更するには、データベースをオープンする必要があります。

表領域の可用性を変更するには、ALTER TABLESPACE文を使用します。そのためには、ALTER TABLESPACEまたはMANAGE TABLESPACEシステム権限が必要です。

関連項目:
表領域内の各データファイルの可用性を変更する方法の詳細は、「データファイルの可用性の変更」を参照してください。

表領域のオフライン化

表領域は、次のような場合にオフライン化できます。

- データベースの一部のみを使用できないようにし、残りの部分には正常にアクセスできるようにする場合

- 表領域のバックアップをオフラインで実行する場合(ただし、表領域はオンラインでも、使用中でもバックアップ可能です)

- アプリケーションの更新またはメンテナンスを行う間、アプリケーションとその表グループを一時的にアクセス不可にする場合

- 表領域のデータファイルの名前の変更または再配置をする場合
詳細は、「データファイルの名前変更と再配置」を参照してください。

表領域をオフライン化すると、その関連ファイルがすべてオフライン化されます。

次の表領域はオフライン化できません。

- SYSTEM

- UNDO表領域

- 一時表領域

表領域をオフライン化する前に、その表領域がデフォルト表領域としてすでに割り当てられているユーザーの表領域割当ての変更を考慮してください。このようなユーザーは表領域がオフラインの間その中のオブジェクトにアクセスできないため、表領域割当ての変更をお薦めします。

ALTER TABLESPACE...OFFLINE文では、次のパラメータを指定できます。

句

説明

NORMAL

表領域のどのデータファイルにもエラー条件が存在していない場合は、この表領域を通常の方法でオフライン化できます。書込みエラーが発生していると、現時点では表領域のデータファイルをオフライン化することはできません。OFFLINE NORMALを指定すると、データベースは表領域のデータファイルすべてのチェックポイントを取ってから、それらのファイルをオフライン化します。NORMALはデフォルトです。

TEMPORARY

表領域の1つまたは複数のデータファイルについてエラー条件が存在している場合でも、表領域を一時的にオフライン化できます。OFFLINE TEMPORARYを指定すると、データベースはまだオフライン化されていないデータファイルのチェックポイントを取ってから、これらのファイルをオフライン化します。
オフラインになっているファイルがないときに表領域を一時的にオフライン化する場合は、表領域をオンラインに戻す前にメディア・リカバリを実行する必要はありません。しかし、表領域の1つまたは複数のファイルが書込みエラーのためにオフラインになっており、この表領域を一時的にオフライン化する場合は、表領域をオンラインに戻す前にリカバリする必要があります。

IMMEDIATE

データベースによりデータファイル上のチェックポイントがチェックされることなく、表領域をただちにオフラインにできます。OFFLINE IMMEDIATEを指定すると、表領域をオンライン化する前に表領域のメディア・リカバリが必要です。データベースがNOARCHIVELOGで稼働している場合は、表領域を即時にオフライン化することはできません。

注意:
表領域をオフライン化する必要がある場合は、可能なかぎりNORMAL句(デフォルト)を使用してください。この設定によって、不完全リカバリの後にALTER DATABASE OPEN RESETLOGS文を使用してREDOログ順序をリセットした場合でも、表領域をオンラインに戻すためのリカバリが不要になることが保証されます。

TEMPORARYは、表領域を通常の方法でオフライン化できないときのみ指定してください。この場合、エラーのためにオフライン化されたファイルのみをリカバリする必要があり、その後に表領域をオンライン化できます。IMMEDIATEは、NORMAL設定とTEMPORARY設定を試した後にのみ指定してください。

次の例では、users表領域を通常の方法でオフライン化しています。

ALTER TABLESPACE users OFFLINE NORMAL;

表領域のオンライン化

データベースがオープンされている場合は、いつでもOracle Database内の任意の表領域をオンライン化できます。通常、表領域は、データベース・ユーザーがその中のデータを使用できるようにオンラインになっています。

オンライン化しようとする表領域が、正常に(ALTER TABLESPACE OFFLINE文のNORMAL句を使用して)オフライン化されていない場合は、最初にメディア・リカバリをしないかぎりオンライン化できません。メディア・リカバリを実行しないと、エラーが返されて表領域はオフラインのままになります。

関連項目:
メディア・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

次の文は、users表領域をオンライン化します。

ALTER TABLESPACE users ONLINE;

読取り専用表領域の使用

表領域を読取り専用にすると、表領域のデータファイルに対して書込み操作ができなくなります。読取り専用表領域の主な目的は、データベース内の大規模かつ静的部分のバックアップおよびリカバリを実行しなくて済むようにすることです。また、読取り専用表領域は、ユーザーが履歴データを変更できないように履歴データを完全に保護する手段でもあります。表領域を読取り専用にすると、その表領域内のすべての表はユーザーの更新権限レベルに関係なく更新できません。

注意:
表領域は、それが作成されたデータベース内でしかオンライン化できないため、読取り専用にすること自体でアーカイブ要件やデータ公開要件を満たすことはできません。ただし、「データベース間での表領域のトランスポート」で説明するように、トランスポータブル表領域機能を使用すると、これらの要件を満たすことができます。

表や索引などの項目は読取り専用表領域から削除できますが、読取り専用表領域内のオブジェクトは作成または変更できません。ALTER TABLE...ADDまたはALTER TABLE...MODIFYなど、データ・ディクショナリ内のファイル記述を更新する文は実行できますが、新しい記述は表領域を読取り/書込み用にするまでは使用できません。

読取り専用表領域は、他のデータベースにトランスポートすることもできます。読取り専用表領域は更新できないため、CD-ROMまたはWrite Once-Read Many(WORM)デバイスに格納できます。

内容は次のとおりです。

- 表領域を読取り専用にする方法

- 読取り専用表領域を書込み可能にする方法

- WORMデバイスでの読取り専用表領域の作成

- 読取り専用表領域内にあるデータファイルのオープンの遅延

関連項目:
「データベース間での表領域のトランスポート」

表領域を読取り専用にする方法

すべての表領域は、最初は読取り/書込み用として作成されます。表領域を読取り専用に変更するには、ALTER TABLESPACE文でREAD ONLYキーワードを使用します。そのためには、ALTER TABLESPACEまたはMANAGE TABLESPACEシステム権限が必要です。

表領域を読取り専用にするには、あらかじめ次の条件を満たす必要があります。

- 表領域は必ずオンラインにする。これにより、表領域に適用する必要のあるUNDO情報がないことが保証されます。

- 表領域をアクティブなUNDO表領域またはSYSTEM表領域にしない。

- 表領域を現行のオンライン・バックアップに含めない(オンライン・バックアップは、終了時に表領域内にあるすべてのデータファイルのヘッダー・ファイルを更新するためです)。

- 表領域を一時表領域にできない。

読取り専用表領域のデータにアクセスする際のパフォーマンスを向上させるため、表領域を読取り専用にする直前に、表領域内の表のブロックすべてにアクセスする問合せを発行することをお薦めします。各表に対してSELECT COUNT (*)などの単純な問合せを実行しておくと、それ以降、表領域のデータ・ブロックに最も効率的にアクセスできるようになります。これによって、最後にブロックを変更したトランザクションの状態をデータベースが確認する必要がなくなるからです。

次の文は、flights表領域を読取り専用にします。

ALTER TABLESPACE flights READ ONLY;

データベースのトランザクション処理中に、ALTER TABLESPACE...READ ONLY文を発行できます。この文が発行されると、表領域は一時的に読取り専用モードになり、ALTERコマンドは、既存のトランザクションがコミットまたはロールバックにより完了するまで待機します。表領域に対するそれ以後のDML操作は許可されず、DML文でそれ以降の変更をしようとすると、エラーが返されます。

ALTER TABLESPACE...READ ONLY文は、戻る前に、表領域に対する変更が保留中またはコミット解除されたトランザクション、およびこの文の発行前に開始されたトランザクションがコミットまたはロールバックされるのを待機します。文の発行前に開始されたトランザクションがアクティブなままであっても、表領域に対する変更をロールバックしてセーブポイントまでロールバックすると、文はこのアクティブ・トランザクションを待機しなくなります。

ALTER TABLESPACE文の完了までに長時間かかる場合は、読取り専用状態になるのを妨げているトランザクションを識別できます。次に、それらのトランザクションの所有者に通知し、必要に応じてトランザクションを終了させるかどうかを決定できます。

次の例では、ALTER TABLESPACE...READ ONLY文に対応するトランザクション・エントリが識別され、そのセッション・アドレス(saddr)が表示されます。

SELECT SQL_TEXT, SADDR
FROM V$SQLAREA,V$SESSION
WHERE V$SQLAREA.ADDRESS = V$SESSION.SQL_ADDRESS
AND SQL_TEXT LIKE 'alter tablespace%';

SQL_TEXT                                 SADDR
---------------------------------------- --------
alter tablespace tbs1 read only          80034AF0

各アクティブ・トランザクションの開始システム変更番号(SCN)は、V$TRANSACTIONビューに格納されています。このビューを開始SCNの昇順でソートして表示すると、トランザクションが実行順にリストされます。前述の例の場合は、読取り専用文のトランザクション・エントリのセッション・アドレスがわかっているので、V$TRANSACTIONビューで特定できます。開始SCNよりも小さい番号を持つトランザクション(以前に実行されたトランザクションを示します)はすべて、表領域の停止とその後の読取り専用状態になるのを妨げている可能性があります。

SELECT SES_ADDR, START_SCNB
FROM V$TRANSACTION
ORDER BY START_SCNB;

SES_ADDR START_SCNB
-------- ----------
800352A0       3621   --> waiting on this txn
80035A50       3623   --> waiting on this txn
80034AF0       3628   --> this is the ALTER TABLESPACE statement
80037910       3629   --> don't care about this txn

この時点で、ブロックしているトランザクションの所有者を見つけることができます。

SELECT T.SES_ADDR, S.USERNAME, S.MACHINE
FROM V$SESSION S, V$TRANSACTION T
WHERE T.SES_ADDR = S.SADDR
ORDER BY T.SES_ADDR

SES_ADDR USERNAME             MACHINE
-------- -------------------- --------------------
800352A0 DAVIDB               DAVIDBLAP             --> Contact this user
80035A50 MIKEL                LAB61                 --> Contact this user
80034AF0 DBA01                STEVEFLAP
80037910 NICKD                NICKDLAP

表領域を読取り専用にした後は、その表領域のバックアップをただちに作成することをお薦めします。表領域は読取り専用になっているかぎり変更できないため、それ以後のバックアップは不要です。

関連項目:
『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

読取り専用表領域を書込み可能にする方法

表領域を書込み可能に変更するには、ALTER TABLESPACE文でREAD WRITEキーワードを指定します。そのためには、ALTER TABLESPACEまたはMANAGE TABLESPACEシステム権限が必要です。

表領域を読取り/書込み用にするには、前提条件として、表領域のみでなく、そのすべてのデータファイルをオンライン化する必要があります。データファイルをオンライン化するには、ALTER DATABASE文のDATAFILE...ONLINE句を使用します。データファイルの現行の状態を確認するには、V$DATAFILEビューを使用します。

次の文は、flights表領域を書込み可能にします。

ALTER TABLESPACE flights READ WRITE;

読取り専用表領域を書込み可能にすると、データファイルの制御ファイル・エントリが更新されるため、読取り専用バージョンのデータファイルをリカバリの開始点として使用できます。

WORMデバイスでの読取り専用表領域の作成

CD-ROMまたはWORMデバイスに読取り専用表領域を作成する手順は、次のとおりです。

1. 別のデバイスに書込み可能表領域を作成します。その表領域に属するオブジェクトを作成して、データを挿入します。

2. 表領域を読取り専用に変更します。

3. 表領域のデータファイルをWORMデバイスにコピーします。ファイルをコピーするには、オペレーティング・システムのコマンドを使用します。

4. 表領域をオフライン化します。

5. データファイルの名前を、WORMデバイスにコピーしたファイルと一致するように変更します。これには、RENAME DATAFILE句を指定したALTER TABLESPACE文を使用します。データファイルの名前を変更すると、制御ファイルに記述されているこれらのファイルの名前も変更されます。

6. 表領域をオンライン化します。

読取り専用表領域内にあるデータファイルのオープンの遅延

大規模データベースのほとんどが、アクセス速度の遅いデバイスや階層形式の記憶デバイス上にある読取り専用表領域に格納されている場合は、READ_ONLY_OPEN_DELAYED初期化パラメータをTRUEに設定することを検討する必要があります。これにより、読取り専用表領域内のデータファイルは、そこに格納されたデータの読取り試行時に初めてアクセスされるため、主にデータベースのオープンなど、特定の操作が高速になります。

READ_ONLY_OPEN_DELAYED=TRUEに設定すると、次のような副次的な影響があります。

- オープン時には、読取り専用の欠落ファイルや不良ファイルが検出されません。アクセスしようとしたときに初めて検出されます。

- ALTER SYSTEM CHECK DATAFILESでは、読取り専用ファイルはチェックされません。

- ALTER TABLESPACE...ONLINEおよびALTER DATABASE DATAFILE...ONLINEでは、読取り専用ファイルはチェックされません。最初のアクセス時にのみチェックされます。

- V$RECOVER_FILE、V$BACKUPおよびV$DATAFILE_HEADERは、読取り専用ファイルにアクセスしません。読取り専用ファイルは結果リスト上に「DELAYED OPEN」というエラーで示され、他の列の値は0(ゼロ)になります。

- V$DATAFILEは読取り専用ファイルにアクセスしません。読取り専用ファイルにはサイズ「0」がリストされます。

- V$RECOVERY_LOGは読取り専用ファイルにアクセスしません。リカバリに必要な可能性があるログは、リストに追加されません。

- ALTER DATABASE NOARCHIVELOGは読取り専用ファイルにアクセスしません。リカバリが必要な読取り専用ファイルがある場合でも、処理が継続します。

注意:

- RECOVER DATABASEおよびALTER DATABASE OPEN RESETLOGSは、パラメータ値に関係なく、すべての読取り専用データファイルに引き続きアクセスします。これらの操作で読取り専用ファイルへのアクセスを回避する場合は、該当ファイルをオフライン化します。

- バックアップ制御ファイルを使用すると、一部のファイルの読取り専用状態が不正確になる場合があります。これにより、これらの操作の一部で予期しない結果が返されることがあります。この状況には注意が必要です。

表領域の変更とメンテナンス

ここでは、表領域の変更とメンテナンスに関する事項について説明します。

この項の内容は次のとおりです。

- 表領域のサイズの拡大

- ローカル管理表領域の変更

- bigfile表領域の変更

- ローカル管理の一時表領域の変更

- ローカル管理の一時表領域の縮小

表領域のサイズの拡大

表領域のサイズを増やすには、表領域のデータファイルのサイズを増やすか、またはデータファイルを追加します。詳細は、「データファイルのサイズ変更」および「データファイルの作成および表領域への追加」を参照してください。

また、データファイルおよびbigfile表領域に対して自動ファイル拡張(AUTOEXTEND)を有効にできます。詳細は、「データファイルの自動拡張機能の使用可能および使用禁止」を参照してください。

ローカル管理表領域の変更

ローカル管理表領域をローカル管理の一時表領域に変更したり、セグメント領域の管理方法を変更することはできません。ローカル管理表領域では、使用可能エクステントを結合する必要はありません。ただし、次のような操作の場合は、ALTER TABLESPACE文をローカル管理表領域に対して使用できます。

- データファイルを追加する場合。次に例を示します。

ALTER TABLESPACE lmtbsb
ADD DATAFILE '/u02/oracle/data/lmtbsb02.dbf' SIZE 1M;

- 表領域の可用性(ONLINE/OFFLINE)を変更する場合。「表領域の可用性の変更」を参照してください。

- 表領域を読取り専用または読取り/書込み用にする場合。「読取り専用表領域の使用」を参照してください。

- データファイルの名前を変更したり、表領域内のデータファイルのサイズの自動拡張を使用可能または使用禁止にする場合。第15章「データファイルおよび一時ファイルの管理」を参照してください。

bigfile表領域の変更

ALTER TABLESPACE文の次の2つの句は、bigfile表領域使用時におけるデータファイルの透過性をサポートします。

- RESIZE: RESIZE句を使用すると、bigfile表領域内の単一データファイルを参照せずに、そのデータファイルのサイズを絶対サイズに変更できます。次に例を示します。

ALTER TABLESPACE bigtbs RESIZE 80G;

- AUTOEXTEND(ADD DATAFILE句の範囲外で使用):
bigfile表領域では、ADD DATAFILE句の範囲外でAUTOEXTEND句を使用できます。次に例を示します。

ALTER TABLESPACE bigtbs AUTOEXTEND ON NEXT 20G;

bigfile表領域に対してADD DATAFILE句を指定すると、エラーが発生します。

ローカル管理の一時表領域の変更

注意:
ALTER TABLESPACE文にTEMPORARYキーワードを指定して、ローカル管理の永続表領域をローカル管理の一時表領域に変更することはできません。ローカル管理の一時表領域を作成するには、CREATE TEMPORARY TABLESPACE文を使用する必要があります。

次の例に示すとおり、ALTER TABLESPACEを使用すると、一時ファイルを追加したり、オフライン化またはオンライン化できます。

ALTER TABLESPACE lmtemp
ADD TEMPFILE '/u02/oracle/data/lmtemp02.dbf' SIZE 18M REUSE;

ALTER TABLESPACE lmtemp TEMPFILE OFFLINE;
ALTER TABLESPACE lmtemp TEMPFILE ONLINE;

注意:
一時表領域はオフライン化できません。かわりに、一時ファイルをオフライン化します。V$TEMPFILEビューには、一時ファイルのオンライン化の状態が表示されます。

ALTER DATABASE文を使用すると、一時ファイルを変更できます。

次の文では、一時ファイルをオフラインにしてから、オンラインに戻しています。前述の例の最後の2つのALTER TABLESPACE文と同様に動作します。

ALTER DATABASE TEMPFILE '/u02/oracle/data/lmtemp02.dbf' OFFLINE;
ALTER DATABASE TEMPFILE '/u02/oracle/data/lmtemp02.dbf' ONLINE;

次の文では、一時ファイルのサイズが変更されます。

ALTER DATABASE TEMPFILE '/u02/oracle/data/lmtemp02.dbf' RESIZE 18M;

次の文では、一時ファイルが削除され、オペレーティング・システム・ファイルが削除されます。

ALTER DATABASE TEMPFILE '/u02/oracle/data/lmtemp02.dbf' DROP
INCLUDING DATAFILES;

この一時ファイルが属していた表領域は残ります。アラート・ログには、一時ファイルが削除されたことを示すメッセージが書き込まれます。オペレーティング・システム・エラーによってファイルが削除されなかった場合でも文は正常終了しますが、エラーを示すメッセージがアラート・ログに書き込まれます。

ALTER DATABASE文を使用して、既存の一時ファイルの自動拡張を使用可能または使用禁止にしたり、一時ファイル名を変更することもできます。必要な構文は、『Oracle Database SQL言語リファレンス』を参照してください。

注意:
一時ファイルの名前を変更するには、一時ファイルをオフライン化し、オペレーティング・システムのコマンドを使用して、その一時ファイルを名前変更または再配置します。次に、ALTER DATABASE RENAME FILEコマンドを使用してデータベースの制御ファイルを更新します。

ローカル管理の一時表領域の縮小

データベースで大規模なソート操作を実行すると、一時表領域が増大し、ディスク領域の容量が大幅に占有される場合があります。ソート操作が完了しても余分になった領域は解放されず、使用可能マークと再利用可能マークが付けられるのみです。したがって、単一の大規模なソート操作を実行すると、ソート操作の完了後に大量の割当て済一時領域が未使用のままになります。このため、データベースでは、ローカル管理の一時表領域を縮小して未使用領域を解放できます。

一時表領域を縮小する場合は、ALTER TABLESPACE文のSHRINK SPACE句を使用します。一時表領域の特定の一時ファイルを縮小する場合は、ALTER TABLESPACE文のSHRINK TEMPFILE句を使用します。縮小すると、表領域または一時ファイルの他の属性を維持しながら可能なかぎり空き領域を解放します。オプションのKEEP句は、表領域または一時ファイルの最小サイズを定義します。

縮小はオンライン操作です。これは、ユーザー・セッションは必要に応じてソート・エクステントの割当てを継続でき、すでに実行中の問合せは影響を受けないことを意味します。

次の例では、20MBのサイズを確保しながら、ローカル管理の一時表領域のlmtmp1を縮小しています。

ALTER TABLESPACE lmtemp1 SHRINK SPACE KEEP 20M;

次の例では、ローカル管理の一時表領域lmtmp2の一時ファイルlmtemp02.dbfを縮小しています。KEEP句を省略しているため、データベースでは、一時ファイルを最小可能サイズまで縮小することを試みます。

ALTER TABLESPACE lmtemp2 SHRINK TEMPFILE '/u02/oracle/data/lmtemp02.dbf';

表領域の名前変更

永続表領域または一時表領域の名前は、ALTER TABLESPACE文のRENAME TO句を使用して変更できます。たとえば、次の文はusers表領域の名前を変更します。

ALTER TABLESPACE users RENAME TO usersts;

表領域の名前を変更すると、データ・ディクショナリ、制御ファイルおよび(オンライン)データファイル・ヘッダー内でその表領域名への参照がすべて更新されます。表領域IDは変更されないため、たとえば、その表領域がユーザーのデフォルト表領域の場合、DBA_USERSビューには名前が変更された表領域がユーザーのデフォルト表領域として表示されます。

この文の操作では、次の点に注意してください。

- COMPATIBLEパラメータは、10.0.0以上に設定する必要があります。

- 名前を変更する表領域がSYSTEM表領域またはSYSAUX表領域の場合、名前は変更されず、エラーが発生します。

- 表領域内のデータファイルがオフラインの場合、または表領域がオフラインの場合、その表領域の名前は変更されず、エラーが発生します。

- 表領域が読取り専用の場合、データファイル・ヘッダーは更新されません。これは破損とはみなされませんが、データファイル・ヘッダーの名前が変更されなかったことを示すメッセージがアラート・ログに書き込まれます。データ・ディクショナリと制御ファイルは更新されます。

- 表領域がデフォルト一時表領域の場合は、データベース・プロパティ表内の対応するエントリが更新され、DATABASE_PROPERTIESビューに新しい名前が表示されます。

- 表領域がUNDO表領域で、次の条件が満たされると、サーバー・パラメータ・ファイル(SPFILE)の表領域名は新しい表領域名に変更されます。

- サーバー・パラメータ・ファイルを使用して、インスタンスを起動した場合。

- 表領域名がインスタンスに対してUNDO_TABLESPACEで指定されている場合。

従来の初期化パラメータ・ファイル(PFILE)を使用している場合は、初期化パラメータ・ファイルを手動で変更する必要があることを示すメッセージがアラート・ログに書き込まれます。

表領域の削除

表領域とその内容が不要になった場合は、その表領域と内容(表領域に含まれるセグメント)をデータベースから削除できます。表領域を削除するには、DROP TABLESPACEシステム権限が必要です。

注意:
削除された表領域のデータはリカバリできません。そのため、削除しようとしている表領域に含まれているデータはすべて、将来的に必要のないことを確認してください。また、表領域をデータベースから削除する直前および直後に、データベースの完全バックアップを作成する必要があります。誤って表領域を削除した場合や、今後表領域を削除した後にデータベースに問題が発生した場合にデータベースをリカバリできるように、データベースをバックアップすることをお薦めします。

表領域を削除すると、対応付けられたデータベースの制御ファイル中のファイル・ポインタのみが削除されます。必要に応じて、削除された表領域を構成していたオペレーティング・システム・ファイル(データファイル)を削除するようにOracle Databaseに指示することもできます。表領域の削除と同時にデータファイルを削除するようにデータベースに指示しない場合は、後でオペレーティング・システムの適切なコマンドを使用して削除する必要があります。

アクティブなセグメントを含む表領域は削除できません。たとえば、表領域内の表が現在使用されている場合、またはコミットされていないトランザクションをロールバックする必要があるUNDOデータが表領域に含まれている場合、その表領域は削除できません。表領域はオンラインでもオフラインでもかまいませんが、削除する前にオフラインにすることをお薦めします。

表領域を削除するには、DROP TABLESPACE文を使用します。、次の文はusers表領域を、その中のセグメントも含めて削除します。

DROP TABLESPACE users INCLUDING CONTENTS;

表領域が空の場合(表、ビューまたは他の構造が格納されていない場合)は、INCLUDING CONTENTS句を指定する必要はありません。CASCADE CONSTRAINTS句を使用すると、表領域内の表の主キーと一意キーを参照する別の表領域の表から、すべての参照整合性制約を削除できます。

表領域の削除と同時に表領域に対応付けられたデータファイルを削除するには、INCLUDING CONTENTS AND DATAFILES句を使用します。次の文は、users表領域とそれに対応付けられているデータファイルを削除します。

DROP TABLESPACE users INCLUDING CONTENTS AND DATAFILES;

アラート・ログには、削除された各データファイルのメッセージが書き込まれます。オペレーティング・システム・エラーによってファイルが削除されなかった場合でもDROP TABLESPACE文は正常終了しますが、エラーを示すメッセージがアラート・ログに書き込まれます。

関連項目:
「データファイルの削除」

SYSAUX表領域の管理

SYSAUX表領域は、データベースの作成時に、SYSTEM表領域の補助表領域としてインストールされます。これまで個別に表領域を作成して使用していた一部のデータベースのコンポーネントは、SYSAUX表領域に含まれるようになりました。

SYSAUX表領域が使用不可能になった場合でも、データベースのコア機能は実行可能です。SYSAUX表領域を使用しているデータベース機能はエラーとなるか、機能が制限される可能性があります。

SYSAUX表領域に含まれる占有データの監視

SYSAUX表領域の登録済占有データのリストは、「SYSAUX表領域の概要」を参照してください。これらのコンポーネントはSYSAUX表領域を使用し、SYSAUX表領域を占有する方法がインストール時に提供されます。

SYSAUX表領域の占有データは、V$SYSAUX_OCCUPANTSビューを使用して監視できます。このビューには、SYSAUX表領域の占有データに関する次の情報がリスト表示されます。

- 占有データの名前

- 占有データの説明

- スキーマ名

- 移動プロシージャ

- 現行の領域使用

ビュー情報は、占有データ別にメンテナンスされます。

関連項目:
V$SYSAUX_OCCUPANTSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

SYSAUX表領域内外への占有データの移動

コンポーネントのインストール時には、コンポーネントをSYSAUXに常駐させないように指定することもできます。また、後でコンポーネントを指定の表領域に再配置する必要が生じた場合、そのコンポーネントについては、V$SYSAUX_OCCUPANTSビューで指定した移動プロシージャを使用して移動を実行できます。

移動プロシージャを使用すると、コンポーネントを他の表領域からSYSAUX表領域に移動することもできます。

SYSAUX表領域のサイズの制御

SYSAUX表領域は、いくつかのデータベース・コンポーネントによって占有され、その合計サイズはそれらのコンポーネントが消費する領域によって決定します。同様に、コンポーネントが消費する領域は、使用される機能およびデータベース・ワークロードの性質によって決定します。

SYSAUX表領域を最も大きく占有するのは自動ワークロード・リポジトリ(AWR)です。AWRが消費する領域は、特定の時間におけるシステム内でのアクティブなセッションの数、スナップショット間隔、履歴データ保存期間など、いくつかの要因によって決定します。同時にアクティブなセッションが平均10ある標準的なシステムでは、AWRデータ用として約200から300MBの領域が必要になる場合があります。

次の表に、システム構成と予測される負荷に基づいてSYSAUX表領域のサイズを設定するためのガイドラインを示します。

パラメータ/推奨設定

小型

中型

大型

CPU数

2

8

32

同時実行セッションの数

10

20

100

ユーザー・オブジェクト数: 表および索引

500

5,000

50,000

デフォルト構成で安定した状態での予測SYSAUXのサイズ

500MB

2GB

5GB

AWRのサイズを制御するには、スナップショット間隔と履歴データ保存期間を変更します。AWRのスナップショット間隔と保存期間の管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

SYSAUX表領域のもう1つの主要な占有データは、埋込みのOracle Enterprise Managerリポジトリです。このリポジトリはOracle Enterprise Manager Database Controlで使用され、そのメタデータが格納されます。このリポジトリのサイズは、データベース・アクティビティ、およびリポジトリに格納された構成関連情報によって異なります。

他のデータベース・コンポーネントが消費するSYSAUX表領域の領域サイズは、関連する機能(Oracle TextやOracle Streamsなど)を使用中の場合のみ大きくなります。このような機能を使用していない場合、これらのコンポーネントはSYSAUX表領域のサイズに大きく影響しません。

ローカル管理表領域の問題の診断と修復

Oracle Databaseには、DBMS_SPACE_ADMINパッケージが組み込まれています。このパッケージは、ローカル管理表領域の問題の診断と修復に使用するサポートの集まりです。

DBMS_SPACE_ADMINパッケージのプロシージャ

次の表に、DBMS_SPACE_ADMINパッケージに含まれるプロシージャを示します。各プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

プロシージャ

説明

ASSM_SEGMENT_VERIFY

自動セグメント領域管理が使用可能な表領域内に作成されたセグメントの整合性を検証します。sid_ora_process_id.trcという名前のダンプ・ファイルを、V$DIAG_INFOビューのDiag Traceエントリに対応する位置に出力します。
手動セグメント領域管理が指定されている表領域には、SEGMENT_VERIFYを使用します。

ASSM_TABLESPACE_VERIFY

自動セグメント領域管理が使用可能な表領域の整合性を検証します。sid_ora_process_id.trcという名前のダンプ・ファイルを、V$DIAG_INFOビューのDiag Traceエントリに対応する位置に出力します。
手動セグメント領域管理が指定されている表領域には、TABLESPACE_VERIFYを使用します。

DROP_EMPTY_SEGMENTS

空の表か、または表のパーティションと依存オブジェクトからセグメントを削除します。

MATERIALIZE_DEFERRED_SEGMENTS

セグメント作成の遅延およびその依存オブジェクトがある表および表のパーティションのセグメントをマテリアライズします。

SEGMENT_CORRUPT

セグメントを破損または有効としてマークし、適切なエラーのリカバリを可能にします。

SEGMENT_DROP_CORRUPT

現在破損としてマークされているセグメントを削除します(領域の再生なし)。

SEGMENT_DUMP

特定のセグメントのセグメント・ヘッダーおよびビットマップ・ブロックを、V$DIAG_INFOビューのDiag Traceエントリに対応する位置にあるsid_ora_process_id.trcという名前のダンプ・ファイルにダンプします。オプションで、セグメント・ヘッダーおよびビットマップ・ブロック・サマリーを含む簡略化したダンプ(各ブロックの空き領域率が含まれていない)を選択できます。

SEGMENT_VERIFY

セグメントのエクステント・マップの一貫性を検証します。

TABLESPACE_FIX_BITMAPS

適切なDBA範囲(エクステント)にビットマップ内で使用可能マークまたは使用済マークを付けます。

TABLESPACE_FIX_SEGMENT_STATES

移行が停止した表領域内のセグメントの状態を修正します。

TABLESPACE_MIGRATE_FROM_LOCAL

ローカル管理表領域を、ディクショナリ管理表領域に移行します。

TABLESPACE_MIGRATE_TO_LOCAL

ディクショナリ管理表領域をローカル管理表領域に移行します。

TABLESPACE_REBUILD_BITMAPS

適切なビットマップを再作成します。

TABLESPACE_REBUILD_QUOTAS

特定の表領域の割当て制限を再作成します。

TABLESPACE_RELOCATE_BITMAPS

ビットマップを指定の保存先に再配置します。

TABLESPACE_VERIFY

表領域内のセグメントについて、ビットマップとエクステント・マップが同期していることを検証します。

次の使用例では、DBMS_SPACE_ADMINパッケージを使用して問題を診断し、解決できる代表的な状況について説明します。

注意:
前述の一部のプロシージャは、正しく使用しないとデータが消失してリカバリ不能になる場合があります。これらのプロシージャに不明な点がある場合は、Oracleサポート・サービスと共同で作業を行ってください。

関連項目:

- DBMS_SPACE_ADMINパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 「V$DIAG_INFOビューを使用したADRの場所の表示」

使用例1: 割当て済ブロックが空き(オーバーラップなし)とマークされているときのビットマップの修復

TABLESPACE_VERIFYプロシージャの使用時に、ビットマップ内で「空き」マークが付いているブロックがセグメントに割り当てられても、セグメント間のオーバーラップがレポートされていないことが検出された場合。

この使用例では、次のタスクを実行してください。

1. SEGMENT_DUMPプロシージャをコールして、管理者がそのセグメントに割り当てた範囲をダンプします。

2. 範囲ごとに、TABLESPACE_EXTENT_MAKE_USEDオプションを指定してTABLESPACE_FIX_BITMAPSプロシージャをコールし、領域に使用済のマークを付けます。

3. TABLESPACE_REBUILD_QUOTASをコールして割当て制限を再作成します。

使用例2: 破損したセグメントの削除

ビットマップに「空き」マークが付いたセグメント・ブロックがあるため、セグメントを削除できない場合。このセグメントには、自動的に「破損」マークが付けられます。

この使用例では、次のタスクを実行してください。

1. SEGMENT_VERIFY_EXTENTS_GLOBALオプションを指定してSEGMENT_VERIFYプロシージャをコールします。オーバーラップがレポートされない場合は、手順2から5までを実行します。

2. SEGMENT_DUMPプロシージャをコールして、そのセグメントに割り当てられたデータ・ブロック・アドレス範囲をダンプします。

3. 範囲ごとに、TABLESPACE_EXTENT_MAKE_FREEオプションを指定してTABLESPACE_FIX_BITMAPSプロシージャをコールし、領域に「空き」のマークを付けます。

4. SEGMENT_DROP_CORRUPTをコールしてSEG$エントリを削除します。

5. TABLESPACE_REBUILD_QUOTASをコールして割当て制限を再作成します。

使用例3: オーバーラップがレポートされたビットマップの修復

TABLESPACE_VERIFYプロシージャで、いくつかオーバーラップがレポートされる場合。前の内部エラーに基づいて、一部の実データを削除する必要があります。

この場合、表t1などの削除するオブジェクトを選択してから、次のタスクを実行します。

1. t1がオーバーラップしているすべてのオブジェクトのリストを作成します。

2. 表t1を削除します。必要に応じて、SEGMENT_DROP_CORRUPTプロシージャをコールしてフォローアップします。

3. t1がオーバーラップしていたすべてのオブジェクトに対して、SEGMENT_VERIFYプロシージャをコールします。必要に応じて、TABLESPACE_FIX_BITMAPSプロシージャをコールして該当するビットマップに使用済を示すマークを付けます。

4. TABLESPACE_VERIFYプロシージャを再度実行し、問題が解決したかどうかを検証します。

使用例4: ビットマップ・ブロックのメディア破損の訂正

ビットマップ・ブロックの集合にメディア破損がある場合。

この使用例では、次のタスクを実行してください。

1. すべてのビットマップ・ブロック、または1つしか破損していない場合はそのブロックに対して、TABLESPACE_REBUILD_BITMAPSプロシージャをコールします。

2. TABLESPACE_REBUILD_QUOTASをコールして割当て制限を再作成します。

3. TABLESPACE_VERIFYプロシージャをコールして、ビットマップの整合性を検証します。

使用例5: ディクショナリ管理表領域からローカル管理表領域への移行

TABLESPACE_MIGRATE_TO_LOCALプロシージャを使用して、ディクショナリ管理表領域をローカル管理表領域に移行する場合。この操作はオンラインで実行されますが、領域管理操作は移行が完了するまでブロックされます。このため、移行処理中にデータの読取りや変更はできますが、大量のデータをロードする場合は追加のエクステントの割当てが必要になるため、操作がブロックされる場合があります。

データベースのブロック・サイズは2KB、表領域tbs_1の既存のエクステント・サイズは10、50および10,000ブロック(それぞれ使用済、使用済および使用可能)とします。MINIMUM EXTENT値は20KB(10ブロック)です。システムにビットマップの割当て単位を選択させることができます。MINIMUM EXTENTを超えない範囲の最大公分母であることから、10ブロックの値が選択されます。

tbs_1をローカル管理表領域に変換する文は、次のとおりです。

EXEC DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('tbs_1');

割当て単位のサイズを指定する場合は、必ずシステムによって計算される単位サイズの因数にします。

ローカル管理表領域へのSYSTEM表領域の移行

DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCALプロシージャを使用して、SYSTEM表領域をディクショナリ管理からローカル管理に移行します。

移行を実行する前に、次の条件を満たす必要があります。

- データベースのデフォルト一時表領域がSYSTEMではないこと。

- ディクショナリ管理表領域にロールバック・セグメントがないこと。

- ローカル管理表領域に1つ以上のオンライン・ロールバック・セグメントがあるか、自動UNDO管理を使用している場合は、UNDO表領域がオンラインになっていること。

- UNDO領域を含む表領域(つまり、ロールバック・セグメントを含む表領域またはUNDO表領域)を除き、すべての表領域が読取り専用モードになっていること。

- SYSAUX表領域がオフラインであること。

- システムが制限モードになっていること。

- データベースのコールド・バックアップがあること。

コールド・バックアップを除き、前述のすべての条件はTABLESPACE_MIGRATE_TO_LOCALプロシージャにより施行されます。

次の文は、この移行を実行します。

SQL> EXECUTE DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL('SYSTEM');

注意:
SYSTEM表領域をローカル管理に移行すると、データベース内のディクショナリ管理表領域を読取り/書込み用にできなくなります。ディクショナリ管理表領域を読取り/書込みモードで使用する必要がある場合は、これらの表領域をローカル管理に移行してから、SYSTEM表領域を移行することをお薦めします。

データベース間での表領域のトランスポート

ここでは、データベース間で表領域をトランスポートする方法について説明します。この項の内容は、次のとおりです。

- トランスポータブル表領域の概要

- プラットフォーム間での表領域のトランスポート

- トランスポータブル表領域の使用に関する制限事項

- トランスポータブル表領域の互換性に関する注意事項

- データベース間で表領域をトランスポートする手順および例

- トランスポータブル表領域の使用: 使用例

注意:
トランスポータブル表領域セットを生成するには、Oracle Databaseリリース8i以上のEnterprise Editionを使用する必要があります。ただし、Oracle Database 8i以上であれば、どのエディションでもトランスポータブル表領域セットを同じプラットフォーム上のOracle Databaseにインポートできます。トランスポータブル表領域セットを別のプラットフォーム上のOracle Databaseにインポートするには、両方のデータベースの互換性が10.0.0以上に設定されている必要があります。リリース・レベル全体にわたる表領域のトランスポートでのデータベース互換性の詳細は、「トランスポータブル表領域の互換性に関する注意事項」を参照してください。

トランスポータブル表領域の概要

トランスポータブル表領域機能を使用すると、表領域セットを別のOracle Databaseにコピーできます。

注意:
この方法で表領域をトランスポートする場合は、トランスポート処理が完了するまで、トランスポート対象の表領域を読取り専用モードにする必要があります。これが望ましくない場合は、トランスポータブル表領域をバックアップ機能から使用できます。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

トランスポートする表領域は、ディクショナリ管理表領域またはローカル管理表領域のいずれかになります。Oracle9iから、トランスポートする表領域を移動先データベースの標準ブロック・サイズと同じブロック・サイズにする必要がなくなりました。

トランスポータブル表領域を使用したデータの移動は、同じデータのエクスポート/インポートまたはアンロード/ロードを使用するより高速で実行されます。これは、実際のすべてのデータを含むデータファイルが単に移動先にコピーされるためで、表領域オブジェクトのメタデータのみを新規データベースにトランスポートするには、データ・ポンプを使用します。

注意:
Oracle Database 11g リリース1からは、トランスポータブル表領域に対してデータ・ポンプを使用する必要があります。XMLTypeデータをデータベース・バージョン10g リリース2以前に下位移行できるのは、元のインポート・ユーティリティ(IMP)とエクスポート・ユーティリティ(EXP)を使用できる環境がある場合のみです。これらのユーティリティの詳細は『Oracle Databaseユーティリティ』を、XMLTypesの詳細は『Oracle XML DB開発者ガイド』を参照してください。

トランスポータブル表領域機能は、次のような場合に役立ちます。

- データ・ウェアハウス表のパーティションをエクスポートおよびインポートする場合

- 構造化データをCDで公開する場合

- 読取り専用バージョンの複数の表領域を複数のデータベースにコピーする場合

- 履歴データをアーカイブする場合

- 表領域のPoint-in-Timeリカバリ(TSPITR)を実行する場合

これらの使用例の説明は、「トランスポータブル表領域の使用: 使用例」を参照してください。

表領域をトランスポートする方法は、次の2通りあります。

- 手動で、この項で説明されている手順を実行します。これには、SQL*Plus、RMANおよびData Pumpへのコマンドの発行が含まれます。

- Enterprise Managerの「表領域のトランスポート」ウィザードの使用。
「表領域のトランスポート」ウィザードを実行する手順は、次のとおりです。

1. EXP_FULL_DATABASEロールを持つユーザーでEnterprise Managerにログインします。

2. データベース・ホームページで、「データ移動」をクリックして「データ移動」ページを表示します。

3. 「データベース・ファイルの移動」で、「表領域のトランスポート」をクリックします。

関連項目:
データ・ウェアハウス環境でトランスポータブル表領域を使用する方法の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

プラットフォーム間での表領域のトランスポート

Oracle Databaseリリース10gから、プラットフォーム間で表領域のトランスポートが可能になりました。この機能を使用すると、次のことが可能になります。

- データベースをプラットフォーム間で移行できます。

- コンテンツ・プロバイダは、簡単にかつ効率的に構造化データを公開し、別のプラットフォームでOracle Databaseを実行している顧客に配布できます。

- データ・ウェアハウス環境からデータ・マート(多くの場合、小規模プラットフォームで実行されている)へのデータの配布を簡素化できます。

- 異なるオペレーティング・システムまたはプラットフォーム上のOracle Databaseインストール間で読取り専用表領域を共有できます。この場合、次の各項で説明するように、それらのプラットフォームおよびendiannessが同じプラットフォームからストレージ・システムにアクセスできることが前提となります。

多くのプラットフォーム(すべてではありません)では、クロス・プラットフォームでの表領域のトランスポートがサポートされます。V$TRANSPORTABLE_PLATFORMビューを問い合せると、サポートされているプラットフォームを参照して、各プラットフォームのendian形式(バイトの並び順)を確認できます。次の問合せを実行すると、プラットフォーム間での表領域のトランスポートがサポートされているプラットフォームが表示されます。

SQL> COLUMN PLATFORM_NAME FORMAT A36
SQL> SELECT * FROM V$TRANSPORTABLE_PLATFORM ORDER BY PLATFORM_NAME;

PLATFORM_ID PLATFORM_NAME                        ENDIAN_FORMAT
----------- ------------------------------------ --------------
6 AIX-Based Systems (64-bit)           Big
16 Apple Mac OS                         Big
19 HP IA Open VMS                       Little
15 HP Open VMS                          Little
5 HP Tru64 UNIX                        Little
3 HP-UX (64-bit)                       Big
4 HP-UX IA (64-bit)                    Big
18 IBM Power Based Linux                Big
9 IBM zSeries Based Linux              Big
10 Linux IA (32-bit)                    Little
11 Linux IA (64-bit)                    Little
13 Linux x86 64-bit                     Little
7 Microsoft Windows IA (32-bit)        Little
8 Microsoft Windows IA (64-bit)        Little
12 Microsoft Windows x86 64-bit         Little
17 Solaris Operating System (x86)       Little
20 Solaris Operating System (x86-64)    Little
1 Solaris[tm] OE (32-bit)              Big
2 Solaris[tm] OE (64-bit)              Big

19 rows selected.

ソースおよび移動先のプラットフォームでendiannessが異なる場合は、ソースまたは移動先のプラットフォームで、トランスポートする表領域を移行先の形式に変換する手順を追加する必要があります。両方のプラットフォームでendiannessが同じ場合は変換する必要はなく、表領域は同じプラットフォーム上にある場合と同様にトランスポートできます。

表領域を別のプラットフォームにトランスポートする前に、その表領域が属するプラットフォームをデータファイル・ヘッダーで識別する必要があります。互換性が10.0.0以上に設定されているOracle Databaseでは、データファイルの読取りまたは書込みを1回以上実行することによってプラットフォームを識別できます。

トランスポータブル表領域の使用に関する制限事項

表領域をトランスポートする場合は、次の制限事項に注意してください。

- トランスポート元とトランスポート先のデータベースで、互換性のあるデータベース・キャラクタ・セットを使用している必要があります。つまり、次のいずれかが当てはまる必要があります。

- ソース・データベースとターゲット・データベースのデータベース・キャラクタ・セットが同じです。

- ソース・データベース・キャラクタ・セットがターゲット・データベース・キャラクタ・セットの厳格な(バイナリ)サブセットであり、かつ、次の3つの条件が満たされています。

- トランスポート元のデータベースが、バージョン10.1.0.3以降です。

- トランスポート対象の表領域に、文字長セマンティクスが使用される表の列が含まれていないか、またはソースとターゲットの両方のデータベースにおいて、データベース・キャラクタ・セットの最大文字幅が同じです。

- トランスポート対象の表領域にはCLOBデータ型の列が含まれていないか、またはトランスポート元とトランスポート先のデータベースにおいて、データベース・キャラクタ・セットが両方ともシングルバイトであるか、両方ともマルチバイトです。

- ソース・データベース・キャラクタ・セットがターゲット・データベース・キャラクタ・セットの厳格な(バイナリ)サブセットであり、かつ、次の2つの条件が満たされています。

- トランスポート元のデータベースが、バージョン10.1.0.3以前です。

- ソース・データベースとターゲット・データベース・キャラクタ・セットにおいて、最大文字幅が同じです。

- トランスポート元とトランスポート先のデータベースで、互換性のある各国語キャラクタ・セットを使用している必要があります。具体的には、次の内容のいずれかを満たしている必要があります。

- ソースとターゲットのデータベースの各国語キャラクタ・セットが同じです。

- トランスポート元のデータベースはバージョン10.1.0.3以降であり、トランスポート対象の表領域にはNCHAR、NVARCHAR2、NCLOBのデータ型の列が含まれていません。

注意:
Oracle Databaseによって認識されるキャラクタ・セット間のサブセットとスーパーセットの関係は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

- トランスポート先のデータベースに同じ名前の表領域が含まれている場合は、表領域をトランスポートできません。ただし、トランスポート操作を実行する前に、トランスポート対象の表領域またはトランスポート先の表領域のいずれかの名前を変更できます。

- 基礎となるオブジェクトを持つオブジェクト(マテリアライズド・ビューなど)またはオブジェクトを含むオブジェクト(パーティション表など)は、それらのオブジェクトがすべて表領域セットに含まれている場合のみトランスポートできます。

- 暗号化された表領域には、次の制限事項があります。

- マスター暗号化キーがOracleウォレットではなく、ハードウェア・セキュリティ・モジュール(HSM)デバイスに格納されている場合を除き、暗号化された表領域をトランスポートする前に、Oracleウォレットを宛先データベースに手動でコピーする必要があります。ウォレットをコピーすると、ウォレットのパスワードは宛先データベースでも同じになります。ただし、宛先データベースでパスワードを変更して、各データベースに独自のウォレット・パスワードを設定することをお薦めします。HSMデバイス、Oracleウォレットの位置の決定、およびOracle Wallet Managerを使用したウォレット・パスワードの変更の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- 透過的データ暗号化用のOracleウォレットがすでに存在するデータベースには、暗号化された表領域をトランスポートできません。この場合は、Oracle Data Pumpを使用して表領域のスキーマ・オブジェクトをエクスポートし、宛先データベースにインポートする必要があります。必要に応じて、Oracle Data Pump機能を利用してデータのエクスポートおよびインポート時にデータの暗号化を保持できます。詳細は、『Oracle Databaseユーティリティ』を参照してください。

- 暗号化された表領域は、endiannessが異なるプラットフォームにはトランスポートできません。

- ブロックの暗号化を使用していない表領域であっても、暗号化列のある表が含まれている場合はトランスポートできません。Oracle Data Pumpを使用して、表領域のスキーマ・オブジェクトをエクスポートおよびインポートする必要があります。Oracle Data Pump機能を利用すると、データのエクスポートおよびインポート時にデータの暗号化を保持できます。詳細は、『Oracle Databaseユーティリティ』を参照してください。

- Oracle Database 10g リリース2からは、XMLTypeを含む表領域をトランスポートできます。Oracle Database 11g リリース1からは、XMLTypeを含む表領域の表領域メタデータをエクスポートおよびインポートする場合は、データ・ポンプを使用する必要があります。
次の問合せでは、XMLTypeを含む表領域のリストが返されます。

select distinct p.tablespace_name from dba_tablespaces p,
dba_xml_tables x, dba_users u, all_all_tables t where
t.table_name=x.table_name and t.tablespace_name=p.tablespace_name
and x.owner=u.username

XMLTypeの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

XMLTypeを含む表領域のトランスポートには、次の制限事項があります。

- 移動先データベースにXML DBがインストールされている必要があります。

- XMLType表が参照するスキーマをXML DB標準スキーマにすることはできません。

- XMLType表が参照するスキーマには循環依存性を設定できません。

- 行レベルでセキュリティが設定されたXMLType表は、エクスポートまたはインポートできないためサポートされていません。

- トランスポートされたXMLType表のスキーマが移動先データベース内に存在しない場合は、スキーマがインポートおよび登録されます。移動先データベースにスキーマが存在する場合は、ignore=yオプションを設定しないと、エラーが返されます。

- XMLType表が別のスキーマに依存するスキーマを使用している場合、依存しているスキーマはエクスポートされません。そのスキーマが移動先データベースにすでに存在する場合のみ、インポートが成功します。

他の制限事項は次のとおりです。

SYSTEM表領域オブジェクト: SYSTEM表領域またはユーザーSYSが所有するオブジェクトはトランスポートできません。これに該当するオブジェクトは、PL/SQL、Javaクラス、コールアウト、ビュー、シノニム、ユーザー、権限、ディメンション、ディレクトリ、順序などです。

OPAQUE型: 解釈がアプリケーション固有で、データベースに対して不透明なタイプ(RAW、BFILEなど)は、トランスポートできますが、クロス・プラットフォームのトランスポート操作では変換されません。このタイプの実際の構造はアプリケーションのみが認識するため、このタイプが新規プラットフォームに移動した後、アプリケーションではendiannessの問題に対処する必要があります。OPAQUE型を使用するタイプとオブジェクトも、直接的または間接的にこの制限の影響を受けます。

浮動小数点数: BINARY_FLOAT型およびBINARY_DOUBLE型は、データ・ポンプを使用してトランスポートできます。

トランスポータブル表領域の互換性に関する注意事項

Oracle Databaseでは、トランスポータブル表領域セットを作成するときに、移動先データベースで実行する必要のある最も低い互換性レベルが計算されます。このレベルのことを、トランスポータブル・セットの互換性レベルと呼びます。Oracle Database 11gからは、移動先データベースが同じプラットフォーム上にあるか別のプラットフォーム上にあるかに関係なく、表領域は同等以上の互換性が設定されたデータベースに常にトランスポートできます。トランスポータブル・セットの互換性レベルが移動先データベースの互換性レベルよりも高い場合は、エラーが通知されます。

次の表に、様々な使用例でのソース表領域と移動先表領域の互換性の最低要件を示します。ソース・データベースと移動先データベースの互換性設定は同一である必要はありません。

表14-1 互換性の最低要件

トランスポートの使用例

互換性の最低設定

ソース・データベース

移動先データベース

同じプラットフォーム上のデータベース間

8.0

8.0

データベース・ブロック・サイズが移動先データベースと異なる表領域

9.0

9.0

異なるプラットフォーム上のデータベース間

10.0

10.0

データベース間で表領域をトランスポートする手順および例

次のタスクのリストでは、表領域のトランスポート処理の概要を示します。各タスクの詳細は、後続の例で示します。

注意:
この方法でトランスポータブル表領域を生成する場合は、表領域を一時的に読取り専用にする必要があります。この方法が望ましくない場合は、代替方法として、トランスポータブル表領域をバックアップ機能から使用できます。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

1. V$TRANSPORTABLE_PLATFORMビューを問い合せて両方のプラットフォームのendian形式をチェック(クロス・プラットフォームでのトランスポートの場合)
同じプラットフォームに表領域セットをトランスポートしている場合は、このタスクを無視してください。

2. 自己完結型の表領域セットを選択します。

3. ソース・データベースで、表領域セットを読取り専用モードにしてから、トランスポータブル表領域セットを生成します。
トランスポータブル表領域セット(トランスポータブル・セット)は、トランスポートされる表領域セットのデータファイルと、そのセットの構造情報(メタデータ)を含むエクスポート・ファイルから構成されます。データ・ポンプを使用してエクスポートを実行します。

endiannessがソース・プラットフォームとは異なるプラットフォームに表領域セットをトランスポートする場合は、表領域セットを移動先プラットフォームのendiannessに変換する必要があります。ソース側での変換はこの手順にあるプロシージャで実行でき、移動先側での変換はタスク4の一部として実行できます。

4. 表領域セットをトランスポートします。
データファイルとエクスポート・ファイルを移動先データベースへアクセス可能な場所にコピーします。

endiannessがソース・プラットフォームとは異なるプラットフォームに表領域セットをトランスポートし、ソース側で表領域セットを移動先プラットフォームのendiannessに変換していない場合は、ここで移動先側での変換を実行します。

5. (オプション)表領域を読取り/書込みモードに戻します。

6. 移動先データベースで、表領域セットをインポートします。
データ・ポンプ・ユーティリティを起動して、表領域セットのメタデータをインポートします。

例

表領域をトランスポートするタスクについては、次のデータファイルと表領域を想定した例で詳細に説明します。

表領域

データファイル

sales_1

/u01/app/oracle/oradata/salesdb/sales_101.dbf

sales_2

/u01/app/oracle/oradata/salesdb/sales_201.dbf

タスク1: プラットフォームがサポートされているかどうかの確認とendiannessの判別

このタスクは、ソース・プラットフォームとは異なるプラットフォームに表領域セットをトランスポートする場合にのみ実行する必要があります。

ソース・プラットフォームとは異なるプラットフォームに表領域セットをトランスポートする場合は、ソースおよび移動先のプラットフォームの両方でプラットフォーム間の表領域トランスポートがサポートされているかどうかを確認し、ぞれぞれのプラットフォームのendiannessを判別します。両方のプラットフォームのendiannessが同じ場合、変換は必要ありません。同じでない場合は、ソース・データベースまたは移動先データベースのどちらかで表領域を変換する必要があります。

sales_1およびsales_2を異なるプラットフォームにトランスポートする場合は、各プラットフォームで次の問合せを実行できます。問合せで行が返される場合、そのプラットフォームではプラットフォーム間の表領域トランスポートがサポートされています。

SELECT d.PLATFORM_NAME, ENDIAN_FORMAT
FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d
WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME;

ソース・プラットフォームでの問合せの結果は次のとおりです。

PLATFORM_NAME                      ENDIAN_FORMAT
---------------------------------- --------------
Solaris[tm] OE (32-bit)            Big

移動先プラットフォームからの結果は、次のとおりです。

PLATFORM_NAME                      ENDIAN_FORMAT
---------------------------------- --------------
Microsoft Windows IA (32-bit)      Little

この問合せ結果によって、endian形式が異なっているため、表領域セットをトランスポートする場合に変換が必要であることがわかります。

タスク2: 自己完結型の表領域セットの選択

トランスポータブル・セット内のオブジェクトとセット外のオブジェクトとの間に、論理的または物理的な依存関係が存在することがあります。 トランスポートできるのは、自己完結した表領域セットのみです。この場合、自己完結とは、表領域セット内から外部への参照がないことを意味します。次に、自己完結した表領域に違反する例を示します。

- 表領域セット内に、そのセットに含まれない表に関する索引が含まれている場合。

注意:
表に対応する索引が表領域セットの外部にある場合は、違反になりません。

- パーティション表の一部が表領域セットに含まれている場合。
コピーする表領域セットは、パーティション化した表のすべてのパーティションが含まれている状態、またはまったく含まれていない状態にしてください。パーティション表のサブセットをトランスポートするには、パーティションを表に変換する必要があります。

パーティションの変換の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- 参照整合性制約がセット境界を越えて別の表を指している場合。
表領域セットをトランスポートするときには、参照整合性制約を含めるかどうかを選択できます。ただし、そうすることによって、表領域セットの自己完結性に影響を与える場合があります。制約をトランスポートしなければ、その制約はポインタとはみなされません。

- 表領域セット内の表に、そのセットに含まれないLOBを指すLOB列が含まれている場合

- ユーザーAが登録されたXML DBスキーマ(*.xsd)にユーザーBが登録されたグローバル・スキーマをインポートする際、ユーザーAのデフォルト表領域が表領域A、ユーザーBのデフォルト表領域が表領域Bで、表領域Aのみが表領域セットに含まれている場合。

表領域セットが自己完結型かどうかを判断するには、オラクル社が提供するパッケージDBMS_TTSのTRANSPORT_SET_CHECKプロシージャをコールします。このプロシージャを実行するには、EXECUTE_CATALOG_ROLEロール(最初はSYSに付与されている)を付与されている必要があります。

DBMS_TTSパッケージをコールするときは、自己完結かどうかを調べるトランスポータブル・セットの表領域のリストを指定します。制約を含むかどうかを指定することもできます。厳密または完全な完結であるかを調べる場合は、TTS_FULL_CHECKパラメータをTRUEに設定する必要があります。

厳密または完全な完結のチェックは、トランスポータブル・セットから外部への参照のみではなく、外部からトランスポータブル・セットへの参照も捕捉する必要がある場合に実行します。依存オブジェクトがトランスポータブル・セットに完全に含まれているか、またはトランスポータブル・セットの外部にのみ存在することが必要な場合は、表領域のPoint-in-Timeリカバリ(TSPITR)を実行します。

たとえば、表tを含んでいるが、その索引iを含んでいない表領域に対してTSPITRを実行すると、トランスポート後に索引とデータの整合性がなくなるため、これは違反になります。完全完結チェックを実行することにより、トランスポータブル・セットからの依存関係またはトランスポータブル・セットへの依存関係がないことが保証されます。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のTSPITRの例を参照してください。

注意:
デフォルトでは、トランスポータブル表領域は、完全完結しているかどうかではなく自己完結しているかどうかがチェックされます。

次の文を使用して、表領域sales_1およびsales_2が自己完結しているかどうかを、参照整合性制約を考慮して(TRUEを指定して)調べます。

EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK('sales_1,sales_2', TRUE);

このPL/SQLパッケージを起動した後に、TRANSPORT_SET_VIOLATIONSビューからすべての違反を選択して表示できます。表領域セットが自己完結している場合、このビューは空になります。次の例は、表領域セットの境界を超えている外部キー定数dept_fkと、表領域セットに部分的に含まれているパーティション表jim.salesという、2つの違反がある場合を示しています。

SQL> SELECT * FROM TRANSPORT_SET_VIOLATIONS;

VIOLATIONS
---------------------------------------------------------------------------
Constraint DEPT_FK between table JIM.EMP in tablespace SALES_1 and table
JIM.DEPT in tablespace OTHER
Partitioned table JIM.SALES is partially contained in the transportable set

これらの違反は、sales_1およびsales_2をトランスポータブルにする前に解決する必要があります。次のタスクで説明するように、整合性制約違反を回避するための選択肢の1つとして、整合性制約をエクスポートしない方法があります。

関連項目:

- DBMS_TTSパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- TSPITRにおけるDBMS_TTSパッケージの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

タスク3: トランスポータブル表領域セットの生成

トランスポートする表領域セットが自己完結型であることを確認した後に、次の手順を実行してトランスポータブル表領域セットを生成します。

1. SQL*Plusを起動し、管理者として、あるいはALTER TABLESPACEまたはMANAGE TABLESPACEシステム権限を持つユーザーとしてデータベースに接続します。
手順は、「SQL*Plusを使用したデータベースへの接続」を参照してください。

2. セット内のすべての表領域を読取り専用にします。

SQL> ALTER TABLESPACE sales_1 READ ONLY;

Tablespace altered.

SQL> ALTER TABLESPACE sales_2 READ ONLY;

Tablespace altered.

3. ユーザーsystemとしてデータ・ポンプ・エクスポート・ユーティリティを起動し、トランスポータブル・セット内の表領域を指定します。

SQL> HOST

$ expdp system dumpfile=expdat.dmp directory=data_pump_dir
transport_tablespaces=sales_1,sales_2 logfile=tts_export.log

Password: password

エクスポート操作のモードを決定するTRANSPORT_TABLESPACESは、常に指定する必要があります。この例では、次のとおりです。

- DUMPFILEパラメータでは、作成する構造情報エクスポート・ファイルの名前をexpdat.dmpと指定します。

- DIRECTORYパラメータでは、オペレーティング・システムまたはOracle Automatic Storage Managementのダンプ・ファイルの場所を示すディレクトリ・オブジェクトを指定します。DIRECTORYオブジェクトはデータ・ポンプを起動する前に作成し、ディレクトリに対するREADおよびWRITEオブジェクト権限をPUBLICに付与する必要があります。CREATE DIRECTORYコマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

注意:
Oracle Databaseをインストールすると、ディレクトリ・オブジェクトDATA_PUMP_DIRが自動的に作成されます。このディレクトリへの読取りおよび書込みアクセス権がDBAロールに(したがって、ユーザーSYSおよびSYSTEMに)自動的に付与されます。DIRECTORYパラメータを省略した場合、DATA_PUMP_DIRがデフォルトのディレクトリとして使用されます。

- LOGFILEパラメータでは、エクスポート・ユーティリティによって書き込まれるログ・ファイルのファイル名を指定します。ログ・ファイルの書込み先はダンプ・ファイルと同じディレクトリです。

- コマンドラインでsystemアカウントのパスワードを指定しないと、EXPDPによってパスワードの入力を求めるプロンプトが表示されます。

- トリガーと索引は、デフォルトでエクスポート操作に含まれています。

表領域のトランスポート操作を厳密完結チェック付きで実行するには、次の例に示すように、TRANSPORT_FULL_CHECKパラメータを使用します。

expdp system dumpfile=expdat.dmp directory=data_pump_dir
transport_tablespaces=sales_1,sales_2 transport_full_check=y
logfile=tts_export.log

この場合は、データ・ポンプ・エクスポート・ユーティリティによって、トランスポータブル・セット内のオブジェクトとトランスポータブル・セット外のオブジェクトとの間に依存性がないことを検証します。トランスポートする表領域セットが自己完結していない場合、エクスポートは失敗し、トランスポータブル・セットが自己完結していないことがわかります。その後は、タスク2に戻ってすべての違反を解決する必要があります。

注意:
データ・ポンプ・ユーティリティを使用してエクスポートするのは、表領域のデータ・ディクショナリの構造情報(メタデータ)のみです。実際のデータはアンロードされないため、この操作は大規模な表領域セットの場合でも比較的早く完了します。

4. ログ・ファイルでエラーを確認し、移動先データベースにトランスポートする必要があるダンプ・ファイルとデータファイルを書き留めます。EXPDPでは、次のようなメッセージに、これらのファイルの名前とパスが出力されます。

******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_TRANSPORTABLE_01 is:
/u01/app/oracle/admin/salesdb/dpdump/expdat.dmp
******************************************************************************
Datafiles required for transportable tablespace SALES_1:
/u01/app/oracle/oradata/salesdb/sales_101.dbf
Datafiles required for transportable tablespace SALES_2:
/u01/app/oracle/oradata/salesdb/sales_201.dbf

5. 完了した後、終了してSQL*Plusに戻ります。

$ EXIT

関連項目:
データ・ポンプ・ユーティリティの使用方法は、『Oracle Databaseユーティリティ』を参照してください。

sales_1およびsales_2表領域を異なるプラットフォームにトランスポートする場合に、各プラットフォームのendiannessが異なるため、表領域セットをトランスポートする前に変換を行う場合は、sales_1およびsales_2を構成するデータファイルを変換します。

1. SQL*Plusからホスト・システムに戻ります。

SQL> HOST

2. RMANを起動して、ソース・データベースに接続します。

$ RMAN TARGET /

Recovery Manager: Release 11.2.0.0.1

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: salesdb (DBID=3295731590)

3. RMAN CONVERT TABLESPACEコマンドを使用してデータファイルを変換し、ソース・プラットフォーム上の一時的な場所に格納します。

この例では、一時的な場所はディレクトリ/tmpと想定し、すでに作成されているとします。変換されたデータファイルの名前は、システムによって割り当てられます。

RMAN> CONVERT TABLESPACE sales_1,sales_2
2> TO PLATFORM 'Microsoft Windows IA (32-bit)'
3> FORMAT '/tmp/%U';

Starting conversion at source at 30-SEP-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile conversion
input datafile file number=00007 name=/u01/app/oracle/oradata/salesdb/sales_101.dbf
converted datafile=/tmp/data_D-SALESDB_I-1192614013_TS-SALES_1_FNO-7_03jru08s
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:45
channel ORA_DISK_1: starting datafile conversion
input datafile file number=00008 name=/u01/app/oracle/oradata/salesdb/sales_201.dbf
converted datafile=/tmp/data_D-SALESDB_I-1192614013_TS-SALES_2_FNO-8_04jru0aa
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:25
Finished conversion at source at 30-SEP-08

関連項目:
RMANのCONVERTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

4. Recovery Managerを終了します。

RMAN> exit
Recovery Manager complete.

タスク4: 表領域セットのトランスポート

次の手順を実行します。

1. 表領域のデータファイルとエクスポート(ダンプ)ファイルの両方を、移動先データベースからアクセスできる場所にトランスポートします。このためには、次のいずれかを実行します。

- 表領域セットのendianness変換が必要ない場合、または表領域セットをすでに変換済の場合は、次のようにします。

1. ダンプ・ファイルを、DATA_PUMP_DIRディレクトリ・オブジェクトで指し示されているディレクトリ、または他の任意のディレクトリにトランスポートします。
DATA_PUMP_DIRの場所を判別するには、次の問合せを実行します。

SELECT * FROM DBA_DIRECTORIES WHERE DIRECTORY_NAME = 'DATA_PUMP_DIR';

OWNER      DIRECTORY_NAME   DIRECTORY_PATH
---------- ---------------- -----------------------------------
SYS        DATA_PUMP_DIR    C:\app\orauser\admin\orawin\dpdump\

2. データファイルを、移動先データベースの既存データファイルの場所にトランスポートします。
UNIXおよびLinuxプラットフォームでは、この場所は通常、/u01/app/oracle/oradata/SID/または+DISKGROUP/SID/datafile/です。

注意:
データファイルを変換した場合は、タスク3: トランスポータブル表領域セットの生成の手順3に示すとおり、そのデータファイルの新しい名前と場所をCONVERT TABLESPACEコマンドの出力で調べます。

- 移動先ホストへのトランスポート後にendianness変換を実行する場合は、次のようにします。

1. ダンプ・ファイルを、DATA_PUMP_DIRディレクトリ・オブジェクトで指し示されているディレクトリ、または他の任意のディレクトリにトランスポートします。

2. 移動先ホスト上の一時的な場所(/tmpやC:\TEMPなど)にデータファイルをトランスポートします。変換時に、変換されたデータファイルを、移動先データベースの既存データファイルの場所に移動できます。

ヒント:
ソースと移動先の両方がファイル・システムの場合は、次の機能を使用してトランスポートできます。

- フラット・ファイルをコピーする機能(オペレーティング・システムのコピー・ユーティリティやFTPなど)

- DBMS_FILE_TRANSFERパッケージ

- RMAN

- CDで配布する機能

ソースとターゲットのいずれかがOracle Automatic Storage Management (Oracle ASM)ディスク・グループの場合は、次の機能を使用できます。

- XML DBリポジトリの/sys/asm仮想フォルダ間でのFTP
詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- DBMS_FILE_TRANSFERパッケージ

- RMAN

注意:
UNIX ddユーティリティを使用してデータベース間でRAWデバイス・ファイルをコピーする場合は、注意が必要です。ddユーティリティは、ソースRAWデバイス・ファイル全体をコピーするために使用するか、またはソースRAWデバイス・ファイルの特定の範囲のみをコピーするようにオプションを指定して起動できます。
データファイルには非表示の制御情報も格納されているため、RAWデバイス・ファイルの実際のデータファイル・サイズを確認するのは困難です。したがって、ddユーティリティを使用する場合は、ソースRAWデバイス・ファイルの内容全体をコピーすることをお薦めします。

2. endiannessがソース・プラットフォームとは異なるプラットフォームに表領域セットをトランスポートし、表領域セットをまだ変換していない場合は、RMANで変換します。
次の例では、変換されたデータファイルがC:\app\orauser\oradata\orawin\(移動先データベースの既存データファイルの場所)に格納されます。

C:\>RMAN TARGET /

Recovery Manager: Release 11.2.0.0.1

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: ORAWIN (DBID=3462152886)

RMAN> CONVERT DATAFILE
2>'C:\Temp\sales_101.dbf',
3>'C:\Temp\sales_201.dbf'
4>TO PLATFORM="Microsoft Windows IA (32-bit)"
5>FROM PLATFORM="Solaris[tm] OE (32-bit)"
6>DB_FILE_NAME_CONVERT=
7>'C:\Temp\', 'C:\app\orauser\oradata\orawin\'
8> PARALLELISM=4;

データファイルは、表領域名ではなく、ファイル名で指定します。表領域のメタデータがインポートされるまで、移動先インスタンスでは対象の表領域名を認識できません。

ソースの場所、ターゲットの場所、あるいはその両方でOracle Automatic Storage Management(Oracle ASM)を使用しない場合、ソース・プラットフォームとターゲット・プラットフォームはオプションです。RMANでは、データファイルを調べてソース・プラットフォームを判別し、デフォルトのターゲット・プラットフォームは、変換を実行するホストのプラットフォームになります。

ソースおよびターゲットの場所の両方でOracle ASMを使用する場合は、DB_FILE_NAME_CONVERT句でソース・プラットフォームとターゲット・プラットフォームを指定する必要があります。

関連項目:
DBMS_FILE_TRANSFERパッケージを使用して、トランスポートされるファイルとそのメタデータをコピーする方法は、「データベース・サーバーを使用したファイルのコピー」を参照してください。

タスク5: (オプション)表領域を読取り/書込みモードに戻す

次のように、トランスポートした表領域をソース・データベースで再び読取り/書込みモードにします。

ALTER TABLESPACE sales_1 READ WRITE;
ALTER TABLESPACE sales_2 READ WRITE;

インポート・プロセスが成功したことを先に確認するために、このタスクを延期することができます。

タスク6: 表領域セットのインポート

注意:
表領域セットを受け取るデータベースの標準ブロック・サイズと異なるブロック・サイズの表領域をトランスポートする場合は、最初にDB_nK_CACHE_SIZE初期化パラメータ・エントリを受取り側データベースのパラメータ・ファイル内に設定する必要があります。
たとえば、ブロック・サイズが8KBの表領域を標準ブロック・サイズが4KBのデータベースにトランスポートする場合は、DB_8K_CACHE_SIZE初期化パラメータ・エントリをパラメータ・ファイルに含める必要があります。このエントリがすでにパラメータ・ファイルに含まれている場合は、ALTER SYSTEM SET文を使用してこのパラメータを設定できます。

DB_nK_CACHE_SIZE初期化パラメータの値の指定方法は、『Oracle Databaseリファレンス』を参照してください。

このタスクは、権限を持つ任意のユーザーが実行できます。表領域セットをインポートするには、次の手順を実行します。

1. データ・ポンプ・インポート・ユーティリティのimpdpを使用して、次のように表領域のメタデータをインポートします。

impdp system dumpfile=expdat.dmp directory=data_pump_dir
TRANSPORT_DATAFILES=
c:\app\orauser\oradata\orawin\sales_101.dbf,
c:\app\orauser\oradata\orawin\sales_201.dbf
remap_schema=sales1:crm1  remap_schema=sales2:crm2
logfile=tts_import.log

Password: password

この例では、次の指定を行います。

- DUMPFILEパラメータでは、インポートされる表領域のメタデータが含まれるエクスポート・ファイルを指定します。

- DIRECTORYパラメータでは、ダンプ・ファイルの場所を識別するディレクトリ・オブジェクトを指定します。

- TRANSPORT_DATAFILESパラメータによって、インポートする表領域が含まれるすべてのデータファイルを識別します。

- REMAP_SCHEMAパラメータによって、データベース・オブジェクトの所有権を変更します。REMAP_SCHEMAを指定しない場合、すべてのデータベース・オブジェクト(表や索引など)はソース・データベースと同じユーザー・スキーマ内で作成され、そのユーザーは移動先データベース内にすでに存在している必要があります。ユーザーが存在しない場合は、インポート・ユーティリティによってエラーが返されます。この例では、ソース・データベース内でsales1が所有している表領域セット内のオブジェクトは、表領域セットをインポートした後の移動先データベース内ではcrm1の所有となります。同様に、ソース・データベース内でsales2が所有しているオブジェクトは、移動先データベース内ではcrm2の所有となります。この場合、移動先データベースにユーザーsales1およびsales2が存在する必要はありませんが、ユーザーcrm1とcrm2が存在している必要があります。

- LOGFILEパラメータでは、インポート・ユーティリティによって書き込まれるログ・ファイルのファイル名を指定します。ログ・ファイルの書込み先はダンプ・ファイルの読取り元と同じディレクトリです。

この文が正常に実行されると、コピーするセット内のすべての表領域は読取り専用モードのままになります。インポート・ログ・ファイルを確認して、エラーが発生しなかったことを確認します。

多数のデータファイルを扱う場合、データファイル名のリストを文の行で指定することは煩雑です。また、文の行制限を超える場合もあります。このような場合には、インポート・パラメータ・ファイルを使用できます。たとえば、次のようにしてデータ・ポンプ・インポート・ユーティリティを起動できます。

impdp system parfile='par.f'

パラメータ・ファイルpar.fの内容は、次のとおりです。

DUMPFILE=expdat.dmp
DIRECTORY=data_pump_dir
TRANSPORT_DATAFILES=
C:\app\orauser\oradata\orawin\sales_101.dbf,
C:\app\orauser\oradata\orawin\sales_201.dbf
REMAP_SCHEMA=sales1:crm1  REMAP_SCHEMA=sales2:crm2
LOGFILE=tts_import.log

関連項目:
インポート・ユーティリティの使用方法は、『Oracle Databaseユーティリティ』を参照してください。

2. 必要に応じて、移動先データベースで表領域を読取り/書込みモードにします。

トランスポータブル表領域の使用: 使用例

次の各項では、トランスポータブル表領域の用途について説明します。

- データ・ウェアハウスのためのパーティションのトランスポートと連結

- 構造化データのCDでの公開

- 複数データベースで同じ表領域を読取り専用でマウントする方法

- トランスポータブル表領域を使用した履歴データのアーカイブ

- トランスポータブル表領域を使用したTSPITRの実行

データ・ウェアハウスのためのパーティションのトランスポートと連結

標準的な企業のデータ・ウェアハウスには、1つ以上の大きいファクト表が含まれています。これらのファクト表は、企業データ・ウェアハウスを履歴データベースにするために、日付別にパーティション化されていることがあります。この場合、索引を作成すると、スター・クエリーを高速化できます。履歴データベースから最も古いパーティションを削除するたびにグローバル索引を再作成しなくても済むように、この種の履歴パーティション表についてローカル索引を作成することをお薦めします。

たとえば、1か月分のデータをデータ・ウェアハウスに毎月ロードする場合を考えます。データ・ウェアハウスには、salesという大型のファクト表があり、次の列が含まれています。

CREATE TABLE sales (invoice_no NUMBER,
sale_year  INT NOT NULL,
sale_month INT NOT NULL,
sale_day   INT NOT NULL)
PARTITION BY RANGE (sale_year, sale_month, sale_day)
(partition jan98 VALUES LESS THAN (1998, 2, 1),
partition feb98 VALUES LESS THAN (1998, 3, 1),
partition mar98 VALUES LESS THAN (1998, 4, 1),
partition apr98 VALUES LESS THAN (1998, 5, 1),
partition may98 VALUES LESS THAN (1998, 6, 1),
partition jun98 VALUES LESS THAN (1998, 7, 1));

次のようにして、ローカルの非同一キー索引を作成します。

CREATE INDEX sales_index ON sales(invoice_no) LOCAL;

最初は、すべてのパーティションは空で、同じデフォルト表領域にあります。パーティションを毎月1つ作成し、パーティション表salesに連結する必要があります。

現在が1998年7月で、7月分の売上データをパーティション表にロードするとします。ステージング・データベース内で、新しい表領域ts_julを作成します。また、その表領域内で、sales表と同じ列タイプを持つ表jul_salesも作成します。表jul_salesは、CREATE TABLE ... AS SELECT文を使用して作成できます。jul_salesを作成して移入した後に、sales表内のローカル索引と同じ列に索引を付けて、この表の索引jul_sale_indexを作成することもできます。索引の作成後に、表領域ts_julをデータ・ウェアハウスにトランスポートします。

データ・ウェアハウスでは、7月分の売上データ用のsales表にパーティションを追加します。これにより、ローカルの非同一キー索引用にも1つのパーティションが作成されます。

ALTER TABLE sales ADD PARTITION jul98 VALUES LESS THAN (1998, 8, 1);

トランスポートされた表jul_salesを新しいパーティションに変換して、表salesに連結します。

ALTER TABLE sales EXCHANGE PARTITION jul98 WITH TABLE jul_sales
INCLUDING INDEXES
WITHOUT VALIDATION;

この文により、新しいデータがパーティション表に連結され、7月分の売上データが新しいパーティションjul98に格納されます。また、索引jul_sale_indexがsales表のローカル索引のパーティションに変換されます。この文では、構造情報を操作するだけであり、データベースのポインタを切り替えれば済むので、結果は即時に返されます。新しいパーティション内のデータが旧パーティション内のデータとオーバーラップしないことがわかっている場合は、WITHOUT VALIDATION句を指定してください。この句を指定しないと、新しいパーティションの範囲を検証するために、そこに含まれる新しいデータがすべて検査されます。

sales表のすべてのパーティションが同じステージング・データベースから取り込まれる場合(ステージング・データベースが破壊されることはありません)、変換文は常に成功します。ただし、一般に、パーティション表のデータが異なるデータベースから取り込まれる場合は、変換操作が失敗する可能性があります。たとえば、salesのjan98パーティションが同じステージング・データベースから取り込まれていない場合は、前述の変換操作が失敗して次のエラーが返されることがあります。

ORA-19728: data object number conflict between table JUL_SALES and partition JAN98 in table SALES

この競合を解決するには、次の文を発行して、競合しているパーティションを移動します。

ALTER TABLE sales MOVE PARTITION jan98;

次に、変換操作を再試行してください。

交換が成功した後は、jul_salesとjul_sale_indexを削除しても安全です(どちらも空になっています)。これで、7月分の売上データはデータ・ウェアハウスに正常にロードされたことになります。

構造化データのCDでの公開

トランスポータブル表領域を使用すると、構造化データをCDで公開できます。データ・プロバイダは、公開するデータを含む表領域をロードし、トランスポータブル・セットを生成し、トランスポータブル・セットをCDにコピーできます。これにより、このCDを配布できます。

顧客は、このCDを受け取ったら、CDからディスク記憶域にデータファイルをコピーすることなく、既存のデータベースにCDの内容を追加できます。たとえば、Windows NTシステムでD:ドライブがCDドライブであるとします。次のようにして、データファイルcatalog.fおよびエクスポート・ファイルexpdat.dmpを含むトランスポータブル・セットをインポートできます。

IMPDP system/password DUMPFILE=expdat.dmp DIRECTORY=dpump_dir
TRANSPORT_DATAFILES='D:\catalog.f'

CDは、データベースの稼働中に取り出すことができます。この場合、その表領域への後続の問合せでは、CD上のデータファイルをオープンできないことを示すエラーが返されます。ただし、このデータベースの他の部分への操作は影響を受けません。CDをドライブに戻すと、表領域は再び読込み可能になります。

CDを取り出すのは、読取り専用表領域のデータファイルを削除するのと同じことです。データベースを停止して再起動すると、削除されたデータファイルが見つからず、データベースをオープンできないことを示すメッセージが表示されます(初期化パラメータREAD_ONLY_OPEN_DELAYEDをTRUEに設定していない場合)。READ_ONLY_OPEN_DELAYEDがTRUEに設定されている場合は、トランスポートされた表領域を問い合せるときにのみ、このファイルが読み込まれます。したがって、CDから表領域をトランスポートする場合は、そのCDがデータベースに永続的に連結されないかぎり、常にREAD_ONLY_OPEN_DELAYED初期化パラメータをTRUEに設定しておく必要があります。

複数データベースで同じ表領域を読取り専用でマウントする方法

トランスポータブル表領域を使用すると、複数のデータベースで1つの表領域を読取り専用でマウントできます。これにより、データを別々のディスクに複製しなくても、異なるデータベースで同じデータを共有できます。表領域のデータファイルは、どのデータベースからもアクセス可能にする必要があります。データベースの破損を回避するために、表領域はマウント先のすべてのデータベース内で読取り専用のままにしてください。

次に、複数のデータベースで同じ表領域を読取り専用でマウントする方法を2つ示します。

- 表領域の元のデータベースが表領域を共有するデータベースと異なる場合。
ソース・データベースでトランスポータブル・セットを生成し、すべてのデータベースからアクセス可能なディスクにそのトランスポータブル・セットを格納し、その後、表領域をマウントする各データベースにメタデータをインポートします。

- 表領域が、その表領域を共有するデータベースの1つに属する場合。
データファイルがすでに共有ディスクに格納されているとします。表領域がすでに格納されているデータベース上で、この表領域を読取り専用にしてトランスポータブル・セットを生成し、データファイルは共有ディスク上の同じ位置に残したまま、表領域を他のデータベースにインポートします。

ディスクを複数のコンピュータからアクセス可能にするには、いくつかの方法があります。クラスタ・ファイル・システムまたはRAWディスクのいずれかを使用できます。ネットワーク・ファイル・システム(NFS)を使用することも可能ですが、NFSの停止中にユーザーが共有表領域を問い合せると、NFS操作がタイムアウトになるまでデータベースが停止することがあります。

後で、一部のデータベースから読取り専用表領域を削除できます。読取り専用表領域を削除しても、表領域のデータファイルは変更されません。したがって、削除操作によって表領域が破損することはありません。表領域をマウントしているデータベースが1つしかない場合を除き、表領域は読取り/書込み可能にしないでください。

トランスポータブル表領域を使用した履歴データのアーカイブ

トランスポータブル表領域セットは、任意のOracle Databaseにインポートできる自己完結したファイル・セットであるため、この章で説明するトランスポータブル表領域の手順を使用して、企業データ・ウェアハウスに旧データまたは履歴データをアーカイブできます。

関連項目:
詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

トランスポータブル表領域を使用したTSPITRの実行

トランスポータブル表領域を使用して、表領域のpoint-in-timeリカバリ(TSPITR)を実行できます。

関連項目:
トランスポータブル表領域を使用してTSPITRを実行する方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

データベースのトランスポータブル表領域を使用したプラットフォーム間の移動

トランスポータブル表領域機能を使用して異なるプラットフォーム間でデータベースを移動するには、移動先プラットフォームに新規データベースを作成して、すべてのユーザー表領域をトランスポートします。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

SYSTEM表領域はトランスポートできません。したがって、SYSTEM表領域に依存する順序、PL/SQLパッケージなどのオブジェクトはトランスポートできません。このため、移動先のデータベースにこれらのオブジェクトを手動で作成するか、またはデータ・ポンプを使用して、トランスポータブル表領域で移動できないオブジェクトをトランスポートする必要があります。

表領域のデータ・ディクショナリ・ビュー

次のデータ・ディクショナリ・ビューおよび動的パフォーマンス・ビューは、データベースの表領域に関して役立つ情報を提供します。

ビュー

説明

V$TABLESPACE

制御ファイルに記述されているすべての表領域の名前と番号。

V$ENCRYPTED_TABLESPACES

暗号化されたすべての表領域の名前と暗号化アルゴリズム。

DBA_TABLESPACES、USER_TABLESPACES

すべての(またはユーザーがアクセス可能な)表領域の説明。

DBA_TABLESPACE_GROUPS

表領域グループとそのグループに属する表領域。

DBA_SEGMENTS、USER_SEGMENTS

すべての(またはユーザーがアクセス可能な)表領域内のセグメントに関する情報。

DBA_EXTENTS、USER_EXTENTS

すべての(またはユーザーがアクセス可能な)表領域内のデータ・エクステントに関する情報。

DBA_FREE_SPACE、USER_FREE_SPACE

すべての(またはユーザーがアクセス可能な)表領域内の使用可能エクステントに関する情報。

DBA_TEMP_FREE_SPACE

各一時表領域の割当て済領域の合計と空き領域。

V$DATAFILE

所有する表領域の表領域番号など、すべてのデータファイルに関する情報。

V$TEMPFILE

所有する表領域の表領域番号など、すべての一時ファイルに関する情報。

DBA_DATA_FILES

表領域に属するファイル(データファイル)。

DBA_TEMP_FILES

一時表領域に属するファイル(一時ファイル)。

V$TEMP_EXTENT_MAP

ローカル管理の一時表領域すべての全エクステントに関する情報。

V$TEMP_EXTENT_POOL

ローカル管理の一時表領域の場合、キャッシュされ、各インスタンスで使用されている一時領域の状態。

V$TEMP_SPACE_HEADER

各一時ファイルの使用済領域/空き領域。

DBA_USERS

すべてのユーザーのデフォルト表領域と一時表領域。

DBA_TS_QUOTAS

すべてのユーザーの表領域割当て制限。

V$SORT_SEGMENT

特定インスタンス内のすべてのソート・セグメントに関する情報。このビューは、表領域がTEMPORARYタイプの場合にかぎり更新されます。

V$TEMPSEG_USAGE

一時または永続表領域のユーザーに使用される一時(ソート)セグメントの説明。

次に示すのは、これらのビューのごく一部の使用例です。

関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

例1: 表領域とデフォルト記憶域パラメータの表示

データベースに含まれるすべての表領域の名前とデフォルト記憶域パラメータをすべて表示するには、DBA_TABLESPACESビューに対して次の問合せを使用します。

SELECT TABLESPACE_NAME "TABLESPACE",
INITIAL_EXTENT "INITIAL_EXT",
NEXT_EXTENT "NEXT_EXT",
MIN_EXTENTS "MIN_EXT",
MAX_EXTENTS "MAX_EXT",
PCT_INCREASE
FROM DBA_TABLESPACES;

TABLESPACE  INITIAL_EXT  NEXT_EXT  MIN_EXT   MAX_EXT    PCT_INCREASE
----------  -----------  --------  -------   -------    ------------
RBS             1048576   1048576        2        40               0
SYSTEM           106496    106496        1        99               1
TEMP             106496    106496        1        99               0
TESTTBS           57344     16384        2        10               1
USERS             57344     57344        1        99               1

例2: データファイルとデータベースの対応する表領域の表示

データファイルの名前、サイズおよびデータベースの対応する表領域を表示するには、DBA_DATA_FILESビューに対して次の問合せを入力します。

SELECT  FILE_NAME, BLOCKS, TABLESPACE_NAME
FROM DBA_DATA_FILES;

FILE_NAME                                      BLOCKS  TABLESPACE_NAME
------------                               ----------  -------------------
/U02/ORACLE/IDDB3/DBF/RBS01.DBF                  1536  RBS
/U02/ORACLE/IDDB3/DBF/SYSTEM01.DBF               6586  SYSTEM
/U02/ORACLE/IDDB3/DBF/TEMP01.DBF                 6400  TEMP
/U02/ORACLE/IDDB3/DBF/TESTTBS01.DBF              6400  TESTTBS
/U02/ORACLE/IDDB3/DBF/USERS01.DBF                 384  USERS

例3: 各表領域の空き領域(エクステント)の統計の表示

データベース内の各表領域について、使用可能エクステントと結合アクティビティの統計を生成するには、次の問合せを入力します。

SELECT TABLESPACE_NAME "TABLESPACE", FILE_ID,
COUNT(*)    "PIECES",
MAX(blocks) "MAXIMUM",
MIN(blocks) "MINIMUM",
AVG(blocks) "AVERAGE",
SUM(blocks) "TOTAL"
FROM DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME, FILE_ID;

TABLESPACE    FILE_ID  PIECES   MAXIMUM    MINIMUM  AVERAGE    TOTAL
----------    -------  ------   -------    -------  -------   ------
RBS                 2       1       955        955      955      955
SYSTEM              1       1       119        119      119      119
TEMP                4       1      6399       6399     6399     6399
TESTTBS             5       5      6364          3     1278     6390
USERS               3       1       363        363      363      363

PIECESは表領域ファイル内の空き領域エクステント数、MAXIMUMおよびMINIMUMはデータベース・ブロック内の領域で連続する最大領域と最小領域、AVERAGEは空き領域があるエクステントの平均ブロック・サイズ、そしてTOTALは各表領域ファイル内の空き領域のブロック数を示します。新しいオブジェクトを作成しようとしているとき、またはセグメントを拡張予定であり、表領域に十分な領域があることを確かめるときに、この問合せを使用します。

15 データファイルおよび一時ファイルの管理

この章の内容は、次のとおりです。

- データファイルを管理するためのガイドライン

- データファイルの作成および表領域への追加

- データファイルのサイズ変更

- データファイルの可用性の変更

- データファイルの名前変更と再配置

- データファイルの削除

- データファイル内のデータ・ブロックの検証

- データベース・サーバーを使用したファイルのコピー

- ファイルと物理デバイスのマッピング

- データファイルのデータ・ディクショナリ・ビュー

注意:
一時ファイルは、一時表領域にのみ関連付けられたデータファイルの特殊なクラスです。この章で説明する内容は、相違点が示されている場合を除き、データファイルと一時ファイルの両方に適用されます。一時ファイルの詳細は、「ローカル管理の一時表領域の作成」を参照してください。

関連項目:

- Oracle Databaseサーバーによって作成および管理されるデータファイルと一時ファイルの作成方法は、第17章「Oracle Managed Filesの使用」を参照してください。

- 『Oracle Database概要』

データファイルを管理するためのガイドライン

データファイルは、データベース内に存在するすべての論理構造のデータを格納する、オペレーティング・システムの物理ファイルです。データファイルは、表領域ごとに明示的に作成する必要があります。

Oracle Databaseでは、データファイルを一意に識別するために使用される絶対ファイル番号と相対ファイル番号という2つの関連するファイル番号を各データファイルに割り当てます。この番号について、次の表で説明します。

ファイル番号のタイプ

説明

絶対

データベース内のデータファイルを一意に識別します。このファイル番号は、ファイル名を使用するかわりにデータファイルを参照する多くのSQL文で使用できます。絶対ファイル番号は、V$DATAFILEビューまたはV$TEMPFILEビューのFILE#列、あるいはDBA_DATA_FILESビューまたはDBA_TEMP_FILESビューのFILE_ID列で確認できます。

相対

表領域内のデータファイルを一意に識別します。小規模および中規模サイズのデータベースでは、多くの場合、相対ファイル番号と絶対ファイル番号は同じです。ただし、データベース内のデータファイル数が一定のしきい値(通常は1023)を超えている場合は、相対ファイル番号と絶対ファイル番号が異なります。bigfile表領域では、相対ファイル番号は常に1024(OS/390プラットフォームでは4096)です。

ここでは、データファイルの管理について説明します。この項の内容は、次のとおりです。

- データファイル数の決定

- データファイルのサイズ設定

- 適切なデータファイルの配置

- REDOログ・ファイルから分離したデータファイルの格納

データファイル数の決定

データベースのSYSTEM表領域およびSYSAUX表領域には、少なくとも1つのデータファイルが必要です。データベースにはこれ以外に、複数の表領域とそれに関連するデータファイルまたは一時ファイルが含まれている必要があります。データベースで作成するデータファイルの数に応じて、初期化パラメータの設定値およびCREATE DATABASE文の句の指定が決定します。

オペレーティング・システムによっては、Oracle Databaseに格納できるデータファイルの数が制限される場合があります。また、データファイル数およびその割当ての方法と場所によって、データベースのパフォーマンスが影響を受ける可能性があることを考慮してください。

注意:
データベース内のデータファイルの数を制御してその管理を簡素化する方法の1つが、bigfile表領域の使用です。bigfile表領域は1つの大型データファイルのみで構成され、大規模データベースを使用する場合、および論理ボリューム・マネージャを使用してオペレーティング・システム・ファイルを管理する場合に特に役立ちます。bigfile表領域については、「bigfile表領域」を参照してください。

データベースのデータファイルの数を決める際は、次のガイドラインを考慮してください。

DB_FILES初期化パラメータの値の決定

Oracle Databaseインスタンスが起動されると、DB_FILES初期化パラメータによって、データファイル情報のために確保するSGA領域の大きさと、それに伴ってそのインスタンスに作成可能な最大データファイル数が指定されます。この制限は、そのインスタンスが存続期間にわたって適用されます。DB_FILESの値は(初期化パラメータの設定を変更することによって)変更可能ですが、新しい値はインスタンスが停止されて再起動されるまで有効になりません。

DB_FILESの値を決めるときは、次の点を考慮してください。

- DB_FILESの値が小さすぎる場合は、最初にデータベースを停止しないと、DB_FILES制限を超えてデータファイルを追加できません。

- DB_FILESの値が大きすぎると、メモリーが不必要に消費されます。

データファイルを表領域に追加するときの制限事項の考慮

データファイルを従来のsmallfile表領域に追加するときには、次の制限事項があります。

- ほとんどのオペレーティング・システムでは、1つのプロセスで同時にオープンできるファイルの数に制限があります。オープン・ファイル数がオペレーティング・システム制限に達すると、それ以上データファイルを作成できなくなります。

- オペレーティング・システムでは、データファイルの数とサイズに制限があります。

- データベースでは、インスタンスによってオープンされるOracle Databaseのデータファイルの最大数が制限されます。この制限はオペレーティング・システムによって異なります。

- DB_FILES初期化パラメータで指定したデータファイルの数を超えることはできません。

- CREATE DATABASE文またはCREATE CONTROLFILE文を発行するときに、MAXDATAFILESパラメータによって制御ファイルのデータファイル部分の初期サイズを指定します。ただし、新しく追加するファイルの番号がMAXDATAFILESより大きくDB_FILES以下であれば、データファイルのセクションにより多数のファイルを格納できるように、制御ファイルが自動的に拡張されます。

パフォーマンスへの影響の考慮

表領域、そして最終的にはデータベースに格納されるデータファイルの数は、パフォーマンスに影響を与える可能性があります。

Oracle Databaseでは、オペレーティング・システムで定義されている制限よりも多くの数のデータファイルをデータベース内に作成できます。データベースのDBWnプロセスは、すべてのオンライン・データファイルをオープンできます。Oracle Databaseには、オープン・ファイル記述子をキャッシュとして処理し、オープン・ファイル記述子の数がオペレーティング・システムで定義されている制限に達したときに自動的にファイルをクローズする機能があります。この機能は、パフォーマンスに悪影響を与えるおそれがあります。できれば、オープン・ファイル記述子に関するオペレーティング・システムの制限を調整して、それがデータベース内のオンライン・データファイルの数より大きくなるようにしてください。

関連項目:

- オペレーティング・システムの制限の詳細は、オペレーティング・システム固有のOracleマニュアルを参照してください。

- CREATE DATABASE文またはCREATE CONTROLFILE文のMAXDATAFILESパラメータの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

データファイルのサイズ設定

表領域を作成するときは、データベース・オブジェクトの将来的なサイズを見積り、十分な数のデータファイルを作成する必要があります。必要に応じて、後で表領域に割り当てられたディスク領域のすべての容量(その結果としてデータベースの容量)を大きくするために、データファイルを作成して表領域に追加できます。可能であれば、データがすべてのデバイスに均等に配分されるように、データファイルを複数のデバイスに作成してください。

適切なデータファイルの配置

表領域の位置は、その表領域を構成するデータファイルの物理的な位置によって決まります。コンピュータのハードウェア資源を適切に使用してください。

たとえば、データベースを格納するためのディスク・ドライブが複数使用可能な場合は、競合の可能性のあるデータファイルを別のディスクに配置することを検討してください。このようにすると、ユーザーが情報を問い合せるときに両方のディスク・ドライブが同時に動作し、同時にデータを取得できます。

関連項目:
I/Oおよびデータファイルの配置の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

REDOログ・ファイルから分離したデータファイルの格納

データファイルは、データベースのREDOログ・ファイルが格納されているディスク・ドライブに格納しないでください。データファイルとREDOログ・ファイルが同じディスク・ドライブに格納されていて、このディスク・ドライブで障害が発生すると、これらのファイルをデータベースのリカバリ手順で使用できなくなります。

REDOログ・ファイルを多重化すると、全REDOログ・ファイルが失われる可能性が低くなるので、データファイルを一部のREDOログ・ファイルと同じドライブに格納できます。

データファイルの作成および表領域への追加

データファイルを作成して表領域を対応付けるには、次の表にリストされている文のいずれかを使用します。どの文でも、作成するデータファイルのファイル仕様を指定するか、またはOracle Managed Files機能を使用してデータベース・サーバーが作成し管理するファイルを作成できます。表には、データファイルの作成に使用する文の簡単な説明と、このマニュアル内に記載されている文の詳細説明への参照が示されています。

SQL文

説明

追加情報

CREATE TABLESPACE

表領域とそれを構成するデータファイルを作成します。

「表領域の作成」

CREATE TEMPORARY TABLESPACE

ローカル管理の一時表領域とそれを構成する一時ファイル(一時ファイルは特殊なデータファイルです)を作成します。

「ローカル管理の一時表領域の作成」

ALTER TABLESPACE ... ADD DATAFILE

データファイルを作成して表領域に追加します。

「ローカル管理表領域の変更」

ALTER TABLESPACE ... ADD TEMPFILE

一時ファイルを作成して一時表領域に追加します。

「ローカル管理の一時表領域の変更」

CREATE DATABASE

データベースとそれに関連付けられたデータファイルを作成します。

「CREATE DATABASE文を使用したデータベースの作成」

ALTER DATABASE ... CREATE DATAFILE

古いデータファイルにかわる新しい空のデータファイルを作成します(バックアップがない状態で失われたデータファイルを再作成する場合に役立ちます)。

『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

表領域に新しいデータファイルを追加するときにファイル名を完全に指定しないと、データファイルは、オペレーティング・システムに応じてデフォルトのデータベース・ディレクトリまたはカレント・ディレクトリに作成されます。データファイルには、常に完全修飾名を使用することをお薦めします。既存のファイルを再利用する場合以外は、新しいファイル名が他のファイルと競合しないことを確認してください。すでに削除済の旧ファイルは上書きされます。

データファイルを作成する文が失敗した場合は、作成されたオペレーティング・システム・ファイルがすべて削除されます。ただし、ファイル・システムやストレージ・サブシステムで発生する多数の潜在的なエラーが原因で、オペレーティング・システムのコマンドを使用した手動でのファイル削除が必要になる場合があります。

データファイルのサイズ変更

ここでは、データファイルのサイズを変更する様々な方法について説明します。この項の内容は、次のとおりです。

- データファイルの自動拡張機能の使用可能および使用禁止

- 手動によるデータファイルのサイズ変更

データファイルの自動拡張機能の使用可能および使用禁止

データファイルを作成するか、既存のデータファイルを変更して、データベースでより多くの領域が必要になった場合に自動的にサイズが増えるようにすることができます。ファイル・サイズは、指定された単位ずつ、指定の最大サイズまで増加します。

データファイルを自動的に拡張するように設定しておくと、次のような利点があります。

- 表領域で領域が足りなくなった場合に、管理者が即時に介入する必要性が減ります。

- エクステントの割当て失敗が原因でアプリケーションが停止または一時停止することがなくなります。

データファイルが自動的に拡張できるかどうかを確認するには、DBA_DATA_FILESビューを問い合せ、AUTOEXTENSIBLE列を調べます。

自動ファイル拡張を指定するには、次のSQL文を使用してデータファイルを作成するときにAUTOEXTEND ON句を指定します。

- CREATE DATABASE

- ALTER DATABASE

- CREATE TABLESPACE

- ALTER TABLESPACE

既存のデータファイルの自動ファイル拡張機能を使用可能または使用禁止にしたり、データファイルのサイズを手動で変更するには、ALTER DATABASE文を使用します。bigfile表領域では、ALTER TABLESPACE文を使用してこれらの操作を実行できます。

次の例は、users表領域に追加するデータファイルの自動拡張機能を使用可能にします。

ALTER TABLESPACE users
ADD DATAFILE '/u02/oracle/rbdb1/users03.dbf' SIZE 10M
AUTOEXTEND ON
NEXT 512K
MAXSIZE 250M;

NEXTの値は、データファイルの拡張時にこのファイルに追加される増分値の最小サイズです。MAXSIZEの値は、自動拡張可能なファイルの最大サイズです。

次の例は、データファイルの自動拡張機能を使用禁止にします。

ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/users03.dbf'
AUTOEXTEND OFF;

関連項目:
データファイルを作成または変更するためのSQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

手動によるデータファイルのサイズ変更

手動でデータファイルのサイズを増減させるには、ALTER DATABASE文を使用します。そのため、さらにデータファイルを追加しなくてもデータベースに領域を追加できます。この機能は、データベースで許容されているデータファイルの最大数に達することが懸念される場合に有効です。

bigfile表領域では、ALTER TABLESPACE文を使用して、データファイルのサイズを変更できます。bigfile表領域にはデータファイルを追加できません。

また、データファイルのサイズを手動で縮小することで、データベース内の未使用領域を再生できます。これは、領域要件の見積りの誤りを訂正する際に有効です。

次の例では、データファイル/u02/oracle/rbdb1/stuff01.dbfが250MBまで拡張されていることを想定しています。ただし、その表領域には現在小さなオブジェクトが格納されているので、データファイルのサイズを縮小できます。

次の文は、データファイル/u02/oracle/rbdb1/stuff01.dbfのサイズを縮小します。

ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf'
RESIZE 100M;

注意:
必ずしもファイルのサイズを指定した値まで縮小できるわけではありません。ファイルに格納されているデータ量が指定の縮小サイズよりも大きい場合は、エラーが戻されます。

データファイルの可用性の変更

個々のデータファイルまたは一時ファイルの可用性は、ファイルをオフラインにするか、オンラインにして変更できます。オフラインのデータファイルはデータベースに使用できず、オンライン化されるまでアクセスできません。

データファイルの可用性の変更には、次のような理由があります。

- データファイルのオフライン・バックアップを実行するため。

- データファイルの名前変更または再配置を行うため。最初にデータファイルをオフライン化するか、あるいは表領域をオフライン化する必要があります。

- データベースのデータファイルへの書込みに問題があり、データファイルが自動的にオフライン化された場合。この場合は、後で問題を解決してから、データファイルを手動でオンライン化できます。

- データファイルが破損または欠落している場合。データベースをオープンするには、その前にデータファイルをオフライン化する必要があります。

読取り専用表領域のデータファイルはオフライン化またはオンライン化ができますが、ファイルをオンライン化しても表領域の読取り専用状態に影響を与えることはありません。表領域が読取り/書込み可能な状態に戻るまで、このデータファイルには書き込めません。

注意:
表領域自体をオフライン化することによって、表領域のすべてのデータファイルを一時的に使用禁止にできます。表領域をオンラインに戻すには、表領域のこれらのファイルをそのままにしておく必要がありますが、「データファイルの名前変更と再配置」に示されている手順に類似する次の手順でファイルを再配置したり名前を変更できます。
詳細は、「表領域のオフライン化」を参照してください。

データファイルをオンライン化またはオフライン化するには、ALTER DATABASEシステム権限が必要です。ALTER TABLESPACE文を使用してすべてのデータファイルまたは一時ファイルをオフライン化するには、ALTER TABLESPACEまたはMANAGE TABLESPACEシステム権限が必要です。Oracle Real Application Clusters環境では、データベースを排他モードでオープンする必要があります。

ここでは、データファイルの可用性を変更する様々な方法について説明します。この項の内容は、次のとおりです。

- ARCHIVELOGモードでデータファイルをオンライン化またはオフライン化する方法

- NOARCHIVELOGモードでデータファイルをオフライン化する方法

- 表領域内のすべてのデータファイルおよび一時ファイルの可用性の変更

ARCHIVELOGモードでデータファイルをオンライン化またはオフライン化する方法

個々のデータファイルをオンライン化するには、DATAFILE句を指定してALTER DATABASE文を発行します。次の文は、指定したデータファイルをオンライン化します。

ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf' ONLINE;

これと同じファイルをオフライン化するには、次の文を発行します。

ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf' OFFLINE;

注意:
この形式のALTER DATABASE文を使用するには、データベースをARCHIVELOGモードにしてください。NOARCHIVELOGモードのときにデータファイルをオフライン化すると、ファイルが失われるおそれがあるので、この要件により、データファイルが誤って失われないようにします。

NOARCHIVELOGモードでデータファイルをオフライン化する方法

データベースがNOARCHIVELOGモードのときにデータファイルをオフライン化するには、DATAFILE句およびOFFLINE FOR DROP句を指定してALTER DATABASE文を使用します。

- OFFLINEキーワードを指定すると、破損しているかどうかに関係なくデータファイルにOFFLINEのマークが付くため、データベースをオープンできます。

- FOR DROPキーワードによって、データファイルが後で削除されるようにマークが付けられます。このようなデータファイルは、オンラインに戻すことはできません。

注意:
この操作では、実際にはデータファイルは削除されません。データ・ディクショナリには残っているので、次のいずれかの方法で削除する必要があります。

- ALTER TABLESPACE ... DROP DATAFILE文
OFFLINE FOR DROPの後、この方法はディクショナリ管理表領域のみに機能します。

- DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES文

- 前述の方法で失敗した場合は、オペレーティング・システム・コマンドを使用してデータファイルを削除します。この方法は、データ・ディクショナリのデータファイルおよび制御ファイルへの参照が残るため、望ましい方法ではありません。

次の文は、指定したデータファイルをオフライン化し、削除対象としてマークを付けます。

ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/users03.dbf' OFFLINE FOR DROP;

表領域内のすべてのデータファイルおよび一時ファイルの可用性の変更

ALTER TABLESPACE文で句を指定することにより、表領域内にあるすべてのデータファイルまたは一時ファイルのオンラインまたはオフラインの状態を変更できます。具体的には、オンライン/オフラインの状態に影響を与える文として次のものがあります。

- ALTER TABLESPACE ... DATAFILE {ONLINE|OFFLINE}

- ALTER TABLESPACE ... TEMPFILE {ONLINE|OFFLINE}

入力が必要なのは表領域名のみであり、個々のデータファイルや一時ファイルを入力する必要はありません。すべてのデータファイルまたは一時ファイルが影響を受けますが、表領域そのもののオンライン/オフラインの状態は変わりません。

ほとんどの場合、データベースがマウントされていれば、オープンしていなくても、前述のALTER TABLESPACE文を発行できます。ただし、表領域がSYSTEM表領域、UNDO表領域、またはデフォルト一時表領域である場合は、データベースをオープンしないでください。ALTER DATABASE DATAFILE文およびALTER DATABASE TEMPFILE文にもONLINE/OFFLINE句がありますが、これらの文では表領域のファイル名をすべて入力する必要があります。

この操作は表領域の可用性を変更するALTER TABLESPACE...ONLINE|OFFLINE文とは操作が異なるため、構文も異なります。ALTER TABLESPACE文は表領域だけでなくデータファイルもオフラインにしますが、一時表領域または一時ファイルの状態を変更するためには使用できません。

データファイルの名前変更と再配置

データファイルの名前を変更して、それらの名前や位置を変更できます。次の項では、その手順について説明します。

- 単一の表領域のデータファイルを名前変更および再配置する手順

- 複数の表領域のデータファイルを名前変更および再配置する手順

これらの手順を使用してデータファイルを名前変更および再配置すると、データベースの制御ファイルに記録されている、データファイルへのポインタのみが変更されます。これらの手順では、オペレーティング・システム・ファイルを物理的に名前変更したり、ファイルをオペレーティング・システム・レベルでコピーすることはありません。データファイルの名前変更と再配置には、複数の手順が必要です。手順と例題をよく理解してから実行してください。

単一の表領域のデータファイルを名前変更および再配置する手順

ここでは、単一の表領域のデータファイルを名前変更および再配置するための手順をいくつか示します。この手順を実行するには、ALTER TABLESPACEシステム権限が必要です。

関連項目:
データファイルの名前変更または再配置に備えて表領域をオフライン化する方法については、「表領域のオフライン化」を参照してください。

単一の表領域のデータファイルを名前変更する手順

単一の表領域のデータファイルの名前を変更する手順は、次のとおりです。

1. データファイルを含む表領域をオフライン化します。データベースはオープンしている必要があります。
次に例を示します。

ALTER TABLESPACE users OFFLINE NORMAL;

2. オペレーティング・システムを使用してデータファイルの名前を変更します。

3. ALTER TABLESPACE文にRENAME DATAFILE句を指定して、データベース内のファイル名を変更します。
たとえば、次の文はデータファイル/u02/oracle/rbdb1/user1.dbfおよび/u02/oracle/rbdb1/user2.dbfをそれぞれ/u02/oracle/rbdb1/users01.dbfおよび/u02/oracle/rbdb1/users02.dbfに名前変更します。

ALTER TABLESPACE users
RENAME DATAFILE '/u02/oracle/rbdb1/user1.dbf',
'/u02/oracle/rbdb1/user2.dbf'
TO '/u02/oracle/rbdb1/users01.dbf',
'/u02/oracle/rbdb1/users02.dbf';

古いデータファイルと新しいデータファイルを正しく識別するために、必ず完全なファイル名(パスを含む)を指定してください。特に、古いデータファイル名は、データ・ディクショナリのDBA_DATA_FILESビューに表示されるとおり、正確に指定してください。

4. データベースをバックアップします。データベースの構造を変更した後は、即時にデータベースの完全バックアップを実行してください。

5. ONLINE句を指定したALTER TABLESPACE文を使用して、この表領域をオンラインに戻します。

ALTER TABLESPACE users ONLINE

単一の表領域のデータファイルを再配置する手順

ここでは、データファイルを再配置する手順の例を示します。

想定する条件は、次のとおりです。

- オープンしているデータベースにusersという表領域が存在し、すべて同じディスク上に配置されたデータファイルによって構成されています。

- users表領域のデータファイルを、別の分離されたディスク・ドライブに再配置します。

- 現在、オープンしているデータベースに管理者権限で接続しています。

- データベースの現行のバックアップは取得済です。

次の手順を実行します。

1. 特定のファイルの名前やサイズが不明な場合は、データ・ディクショナリ・ビューDBA_DATA_FILESを問い合せて情報を取得できます。

SQL> SELECT FILE_NAME, BYTES FROM DBA_DATA_FILES
2> WHERE TABLESPACE_NAME = 'USERS';

FILE_NAME                                  BYTES
------------------------------------------ ----------------
/u02/oracle/rbdb1/users01.dbf              102400000
/u02/oracle/rbdb1/users02.dbf              102400000

2. データファイルを含む表領域をオフライン化します。

ALTER TABLESPACE users OFFLINE NORMAL;

3. オペレーティング・システムを使用し、データファイルを新しい位置にコピーして名前変更します。「データベース・サーバーを使用したファイルのコピー」で説明するDBMS_FILE_TRANSFERパッケージを使用して、ファイルをコピーできます。

注意:
SQL*PlusのHOSTコマンドを使用すると、SQL*Plusを一時的に終了し、オペレーティング・システムのコマンドを実行してファイルをコピーできます。

4. データベース内のデータファイルの名前を変更します。
users表領域を構成するファイルのデータファイル・ポインタは、対応付けられているデータベースの制御ファイルに記録されていますが、これらのポインタをこの時点で旧ファイル名から新ファイル名に変更する必要があります。

ALTER TABLESPACE...RENAME DATAFILE文を使用します。

ALTER TABLESPACE users
RENAME DATAFILE '/u02/oracle/rbdb1/users01.dbf',
'/u02/oracle/rbdb1/users02.dbf'
TO '/u03/oracle/rbdb1/users01.dbf',
'/u04/oracle/rbdb1/users02.dbf';

5. データベースをバックアップします。データベースの構造を変更した後は、即時にデータベースの完全バックアップを実行してください。

6. ONLINE句を指定したALTER TABLESPACE文を使用して、この表領域をオンラインに戻します。

ALTER TABLESPACE users ONLINE

複数の表領域のデータファイルを名前変更および再配置する手順

1つ以上の表領域のデータファイルは、ALTER DATABASE RENAME FILE文を使用して、名前変更および再配置できます。1回の操作で複数の表領域のデータファイルを名前変更または再配置する方法は、これ以外にありません。この手順を実行するには、ALTER DATABASEシステム権限が必要です。

注意:
SYSTEM表領域、デフォルト一時表領域、またはアクティブなUNDO表領域のデータファイルを名前変更または再配置する場合、これらの表領域はオフライン化できないため、このALTER DATABASE文を使用する必要があります。

複数の表領域のデータファイルの名前を変更する手順は、次のとおりです。

1. データベースがマウントされ、クローズされていることを確認します。

注意:
データベースは必要な場合クローズする必要はありませんが、データファイル(または一時ファイル)はオフラインにする必要があります。

2. オペレーティング・システムで新しい位置と名前を指定して、名前変更するデータファイルをコピーします。「データベース・サーバーを使用したファイルのコピー」で説明するDBMS_FILE_TRANSFERパッケージを使用して、ファイルをコピーできます。

3. ALTER DATABASEを使用して、データベースの制御ファイル内のファイル・ポインタの名前を変更します。
たとえば、次の文はデータファイル/u02/oracle/rbdb1/sort01.dbfおよび/u02/oracle/rbdb1/user3.dbfをそれぞれ/u02/oracle/rbdb1/temp01.dbfおよび/u02/oracle/rbdb1/users03.dbfに名前変更します。

ALTER DATABASE
RENAME FILE '/u02/oracle/rbdb1/sort01.dbf',
'/u02/oracle/rbdb1/user3.dbf'
TO '/u02/oracle/rbdb1/temp01.dbf',
'/u02/oracle/rbdb1/users03.dbf';

古いデータファイルと新しいデータファイルを正しく識別するために、必ず完全なファイル名(パスを含む)を指定してください。特に、古いデータファイル名は、DBA_DATA_FILESビューに表示されるとおり、正確に指定してください。

4. データベースをバックアップします。データベースの構造を変更した後は、即時にデータベースの完全バックアップを実行してください。

データファイルの削除

ALTER TABLESPACEコマンドのDROP DATAFILE句およびDROP TEMPFILE句を使用して、1つのデータファイルまたは一時ファイルを削除できます。データファイルは空である必要があります。(データファイルから割り当てられているエクステントが存在しない場合、そのデータファイルは空であるとみなされます。)データファイルまたは一時ファイルを削除すると、データ・ディクショナリおよび制御ファイルからそのデータファイルまたは一時ファイルへの参照が削除され、ファイル・システムまたはOracle Automatic Storage Management(Oracle ASM)ディスク・グループから物理ファイルが削除されます。

次の例では、Oracle ASMディスク・グループDGROUP1の別名example_df3.fで識別されたデータファイルを削除します。データファイルは表領域exampleに属します。

ALTER TABLESPACE example DROP DATAFILE '+DGROUP1/example_df3.f';

次の例では、表領域lmtempに属する一時ファイルlmtemp02.dbfを削除します。

ALTER TABLESPACE lmtemp DROP TEMPFILE '/u02/oracle/data/lmtemp02.dbf';

これは、次の文と同じです。

ALTER DATABASE TEMPFILE '/u02/oracle/data/lmtemp02.dbf' DROP
INCLUDING DATAFILES;

注意:
一時ファイルを使用しているセッションがある場合にその一時ファイルを削除しようとすると、エラーが返され、一時ファイルは削除されません。この場合、一時ファイルはオフライン化され、一時ファイルがオフラインの間は一時ファイルを使用しようとする問合せは失敗します。

ALTER TABLESPACE構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

データファイルの削除に関する制限事項

データファイルおよび一時ファイルの削除に関する制限事項は、次のとおりです。

- データベースはオープンしている必要があります。

- データファイルが空でない場合、そのファイルは削除できません。
空でなく、スキーマ・オブジェクトを削除しても空にできないデータファイルを削除する場合は、そのデータファイルを含む表領域を削除する必要があります。

- 表領域の最初のデータファイルまたは1つのみのデータファイルは削除できません。
したがって、bigfile表領域にはDROP DATAFILEは使用できません。

- ディクショナリ管理からローカル管理に移行した読取り専用表領域のデータファイルは削除できません。他のすべての読取り専用表領域からのデータファイルの削除はサポートされています。

- SYSTEM表領域のデータファイルは削除できません。

- ローカル管理表領域のデータファイルがオフラインの場合、そのファイルは削除できません。

関連項目:
表領域の削除

データファイル内のデータ・ブロックの検証

チェックサムを使用してデータ・ブロックを検証するようにデータベースを構成するには、初期化パラメータDB_BLOCK_CHECKSUMをTYPICAL(デフォルト)に設定します。これによって、DBWnプロセスおよびダイレクト・ローダーが各ブロックのチェックサムを計算し、ブロックをディスクに書き込むときにこのチェックサムをブロック・ヘッダーに格納します。

ブロックが読み込まれるときにチェックサムが検証されるのは、DB_BLOCK_CHECKSUMがTRUEに設定され、前回ブロックが書き込まれたときにチェックサムが格納されている場合のみです。破損が検出されると、メッセージORA-01578が返され、破損に関する情報がアラート・ログに書き込まれます。

DB_BLOCK_CHECKSUMパラメータの値は、ALTER SYSTEM文で動的に変更できます。このパラメータの設定に関係なく、SYSTEM表領域のデータ・ブロックは常にチェックサムを使用して検証されます。

関連項目:
DB_BLOCK_CHECKSUM初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベース・サーバーを使用したファイルのコピー

データベース内のファイルをコピーする場合、またはデータベース間でファイルを転送する場合(トランスポータブル表領域機能を使用して転送する場合など)は、必ずしもオペレーティング・システムを使用する必要はありません。これらの処理は、DBMS_FILE_TRANSFERパッケージ、またはStreamsの伝播を使用して行うこともできます。このマニュアルではStreamsの使用方法については説明していませんが、DBMS_FILE_TRANSFERパッケージの使用例は「ファイルのローカル・ファイル・システムへのコピー」に示しています。

DBMS_FILE_TRANSFERパッケージでは、ローカル・ファイル・システムまたはOracle Automatic Storage Management(Oracle ASM)ディスク・グループをファイル転送の移動元または移動先として使用できます。Oracle ASMへの転送またはOracle ASMからの転送に含めることができるのは、Oracle Databaseファイル(データファイル、一時ファイル、制御ファイルなど)のみです。

注意:
データベースによって変更されているファイルのコピーまたは転送にDBMS_FILE_TRANSFERパッケージを使用しないでください。コピーや転送に使用すると、ファイルの整合性がなくなる可能性があります。

UNIXシステムの場合、DBMS_FILE_TRANSFERパッケージで作成されたファイルの所有者は、インスタンスを実行するシャドウ・プロセスの所有者になります。通常、この所有者はORACLEです。DBMS_FILE_TRANSFERを使用して作成されたファイルは、常に、データベース内のすべてのプロセスによる書込みと読取りが可能ですが、そのようなファイルを直接読取りまたは書込みを行うのに必要な権限を持っていないユーザーは、システム管理者からのアクセスが必要な場合があります。

この項の内容は次のとおりです。

- ファイルのローカル・ファイル・システムへのコピー

- サード・パーティ・ファイル転送

- ファイル転送とDBMS_SCHEDULERパッケージ

- 拡張ファイル転送メカニズム

関連項目:

- 『Oracle Streams概要および管理』

- 「データベース間での表領域のトランスポート」

- DBMS_FILE_TRANSFERパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ファイルのローカル・ファイル・システムへのコピー

この項では、DBMS_FILE_TRANSFERパッケージのCOPY_FILEプロシージャを使用してファイルをローカル・ファイル・システムにコピーする例を示します。次の例では、/usr/admin/sourceディレクトリ内のdb1.datという名前のバイナリ・ファイルを、ローカル・ファイル・システムの/usr/admin/destinationディレクトリにdb1_copy.datという名前でコピーします。

1. 権限を付与でき、SQLを使用してディレクトリ・オブジェクトを作成できる管理ユーザーとしてSQL*Plusで接続します。

2. SQLコマンドCREATE DIRECTORYを使用して、コピー元ファイルが格納されるディレクトリのディレクトリ・オブジェクトを作成します。ディレクトリ・オブジェクトは、ディレクトリの別名に類似しています。たとえば、SOURCE_DIRというディレクトリ・オブジェクトを、使用しているコンピュータ・システムの/usr/admin/sourceディレクトリに対して作成するには、次の文を実行します。

CREATE DIRECTORY SOURCE_DIR AS '/usr/admin/source';

3. SQLコマンドCREATE DIRECTORYを使用して、バイナリ・ファイルがコピーされるディレクトリのディレクトリ・オブジェクトを作成します。たとえば、DEST_DIRというディレクトリ・オブジェクトを、使用しているコンピュータ・システムの/usr/admin/destinationディレクトリに対して作成するには、次の文を実行します。

CREATE DIRECTORY DEST_DIR AS '/usr/admin/destination';

4. COPY_FILEプロシージャを実行するユーザーに対して、必要な権限を付与します。この例では、strmadminユーザーがプロシージャを実行します。

GRANT EXECUTE ON DBMS_FILE_TRANSFER TO strmadmin;

GRANT READ ON DIRECTORY source_dir TO strmadmin;

GRANT WRITE ON DIRECTORY dest_dir TO strmadmin;

5. strmadminユーザーとして接続し、プロンプトが表示されたらユーザー・パスワードを入力します。

CONNECT strmadmin

6. COPY_FILEプロシージャを実行して、ファイルをコピーします。

BEGIN
DBMS_FILE_TRANSFER.COPY_FILE(
source_directory_object       =>  'SOURCE_DIR',
source_file_name              =>  'db1.dat',
destination_directory_object  =>  'DEST_DIR',
destination_file_name         =>  'db1_copy.dat');
END;
/

注意:
データベースによって変更されているファイルのコピーまたは転送にDBMS_FILE_TRANSFERパッケージを使用しないでください。コピーや転送に使用すると、ファイルの整合性がなくなる可能性があります。

サード・パーティ・ファイル転送

DBMS_FILE_TRANSFERパッケージのプロシージャは、通常、ローカル・プロシージャ・コールとして起動しますが、リモート・プロシージャ・コールとして起動することもできます。リモート・プロシージャ・コールとして起動すると、別のデータベースに接続している場合でも、データベース内のファイルをコピーできます。たとえば、次のリモート・プロシージャ・コールを実行すると、別のデータベースに接続していても、データベースDBでファイルをコピーできます。

DBMS_FILE_TRANSFER.COPY_FILE@DB(...)

また、リモート・プロシージャ・コールを使用すると、いずれのデータベースにも接続していなくても、2つのデータベース間でファイルをコピーできます。たとえば、データベースAに接続し、ファイルをデータベースBからデータベースCに転送できます。この場合、データベースAは、転送するファイルの転送元でも転送先でもないため、サード・パーティになります。

サード・パーティ・ファイル転送では、ファイルのプッシュとプルの両方が可能です。前述の例では、AからBまたはCへのデータベース・リンクがあり、そのデータベースから別のデータベースへのデータベース・リンクがある場合は、サード・パーティ・ファイル転送を実行できます。データベースAからBおよびC両方へのデータベース・リンクは必要ありません。

たとえば、AからBへのデータベース・リンクがあり、BからCへの別のデータベース・リンクがある場合は、データベースAで次のプロシージャを実行してファイルをBからCに転送できます。

DBMS_FILE_TRANSFER.PUT_FILE@B(...)

この構成では、ファイルをプッシュします。

または、AからCへのデータベース・リンクがあり、CからBへの別のデータベース・リンクがある場合は、データベースAで次のプロシージャを実行してファイルをBからCに転送できます。

DBMS_FILE_TRANSFER.GET_FILE@C(...)

この構成では、ファイルをプルします。

ファイル転送とDBMS_SCHEDULERパッケージ

DBMS_SCHEDULERパッケージを使用して、単一のデータベース内およびデータベース間でファイルを自動的に転送できます。DBMS_SCHEDULERパッケージではサード・パーティ・ファイル転送もサポートされています。スケジューラによって実行されるファイル転送が長時間実行される場合は、ファイルの読取りまたは書込みを行うデータベースでV$SESSION_LONGOPS動的パフォーマンス・ビューを使用してファイル転送を監視できます。スケジューラ・ジョブで使用するデータベース・リンクは、必ず固定ユーザー・データベース・リンクです。

再開可能なスケジューラ・ジョブを使用すると、特に断続的に障害が発生する場合に、ファイル転送の信頼性を自動的に改善できます。転送先ファイルがクローズする前にファイル転送が失敗した場合は、部分的に書き込まれた転送先ファイルがデータベースによって削除された後、ファイル転送を最初から再開できます。したがって、ジョブの残りの部分が再開可能な場合は、再開可能なスケジューラ・ジョブを使用してファイルを転送することを検討してください。スケジューラ・ジョブの詳細は、第29章「Oracle Schedulerを使用したジョブのスケジューリング」を参照してください。

注意:
再開可能な1つのジョブで複数のファイルを転送する場合は、すでに転送済のファイルと転送されていないファイルがある状態でジョブを再開する方法を検討する必要があります。

拡張ファイル転送メカニズム

DBMS_FILE_TRANSFERパッケージとDBMS_SCHEDULERパッケージの両方を使用すると、複雑なファイル転送メカニズムを作成できます。たとえば、転送するファイルのコピーが複数のデータベースに存在する場合は、ソースの可用性、ソースのロード、宛先データベースへの通信帯域幅などの要因を検討して、最初にアクセスするソース・データベース、および障害発生時にアクセスを試みるソース・データベースを決定します。この場合、それらの要因に関する情報を入手する必要があるため、要因を検討するメカニズムを構築する必要があります。

別の例として、ロードよりも完了時間が短いことが重要である場合は、複数のスケジューラ・ジョブを発行してファイル転送をパラレルで実行できます。また、ソース・データベースと転送先データベースのファイル・レイアウトに関する知識があれば、使用するI/Oデバイスが異なる場合のみ同時転送を実行またはスケジュールすることで、ディスクの競合を最小限にできます。

ファイルと物理デバイスのマッピング

データファイルが単なるファイル・システム・ファイルである環境や、RAWデバイス上で直接作成される環境では、表領域と基礎となるデバイスとの関連付けを調べるのは比較的容易です。Oracle Databaseには、ファイルとデバイスとのマッピングを提供するDBA_TABLESPACES、DBA_DATA_FILES、V$DATAFILEなどのビューが用意されています。これらのマッピングをデバイス統計と併用して、I/Oパフォーマンスを評価できます。

ただし、ホスト・ベースの論理ボリューム・マネージャ(LVM)と、Redundant Array of Inexpensive Disks(RAID)機能を提供する洗練されたストレージ・サブシステムの導入によって、ファイルからデバイスへのマッピングを判別するのが難しくなっています。最新ファイルがブラック・ボックスに隠れていると、そのファイルを判断するのが難しくなるため、問題が発生します。この項では、この問題を解決するためのOracle Databaseのアプローチについて説明します。

この項の内容は、次のとおりです。

- Oracle Databaseのファイル・マッピング・インタフェースの概要

- Oracle Databaseのファイル・マッピング・インタフェースの動作

- Oracle Databaseのファイル・マッピング・インタフェースの使用方法

- ファイル・マッピングの例

注意:
ここでは、Oracle Databaseのファイル・マッピング・インタフェースの概要と、DBMS_STORAGE_MAPパッケージおよび動的パフォーマンス・ビューを使用してファイルと物理デバイスのマッピングを公開する方法について説明します。Oracle Enterprise Managerを使用して、より簡単にこの機能にアクセスできます。それによって提供される使いやすいグラフィカル・インタフェースを使用して、ファイルと物理デバイスをマップできます。

Oracle Databaseのファイル・マッピング・インタフェースの概要

I/Oパフォーマンスを把握するには、ファイルが格納されている記憶域の階層の詳細を知る必要があります。Oracle Databaseには、ファイル、論理ビューの中間レイヤーおよび実際の物理デバイスのマッピング全体を表示するメカニズムが用意されています。この表示には、動的パフォーマンス・ビュー(V$ビュー)のセットが使用されます。これらのビューを使用すると、ファイル・ブロックがあるディスクを正確に特定できます。

これらのビューを作成するために、ストレージ・ベンダーは特定のI/Oスタック要素のマッピングを受け持つマッピング・ライブラリを提供する必要があります。データベースは、バックグラウンド・プロセスFMONによって起動される外部の非Oracle Databaseプロセスを介して、これらのライブラリと通信します。FMONは、マッピング情報の管理を受け持ちます。OracleにはPL/SQLパッケージDBMS_STORAGE_MAPが用意されており、このパッケージを使用して、マッピング・ビューを移入するマッピング操作を起動します。

注意:
ファイル・マッピング・インタフェースは、Windowsプラットフォームでは使用できません。

Oracle Databaseのファイル・マッピング・インタフェースの動作

この項では、Oracle Databaseのファイル・マッピング・インタフェースの構成要素と、インタフェースの動作について説明します。内容は次のとおりです。

- ファイル・マッピングの構成要素

- マッピング構造

- マッピング構造の例

- 構成ID

ファイル・マッピングの構成要素

次の図は、ファイル・マッピング・メカニズムの構成要素を示しています。

図15-1 ファイル・マッピングの構成要素

ここでは、これらの構成要素と、各構成要素が連動してマッピング・ビューを移入する動作について説明します。

- FMON

- 外部プロセス(FMPUTL)

- マッピング・ライブラリ

FMON

FMONは、FILE_MAPPING初期化パラメータがTRUEに設定されている場合に、データベースにより起動されるバックグラウンド・プロセスです。FMONの役割は、次のとおりです。

- SGAに格納されるマッピング情報を作成します。この情報は、次の構造で構成されます。

- ファイル

- ファイル・システムのエクステント

- 要素

- 副要素

これらの構造については、「マッピング構造」を参照してください。

- 次の原因で変更が発生した場合にマッピング情報をリフレッシュします。

- データファイル(サイズ)の変更

- データファイルの追加または削除

- 記憶域の構成変更(低頻度)

- マッピング情報をデータ・ディクショナリに保存して、起動操作と停止操作の間も持続する情報のビューを保持します。

- インスタンスの起動時にマッピング情報をSGAにリストアします。これにより、インスタンスを起動するたびにマッピング情報全体を再作成するという、高コストの操作が不要になります。

DBMS_STORAGE_MAPパッケージで起動されるプロシージャを使用すると、このマッピングを制御しやすくなります。

外部プロセス(FMPUTL)

FMONは外部の非Oracle DatabaseプロセスFMPUTLを起動し、このプロセスはベンダーが提供するマッピング・ライブラリと直接通信します。このプロセスは、I/Oスタックのすべてのレベルにマッピング・ライブラリが存在していれば、すべてのレベルを通じてマッピング情報を取得します。一部のプラットフォームでは、I/Oマッピング・スタックの全レベルを通じてマッピングするにはルート権限が必要であるため、外部プロセスのSETUIDビットをONに設定する必要があります。

この外部プロセスの役割は、マッピング・ライブラリを検出してアドレス空間に動的にロードすることです。

マッピング・ライブラリ

Oracle Databaseはマッピング・ライブラリを使用して、特定のマッピング・ライブラリが所有する要素のマッピング情報を検出します。これらのマッピング・ライブラリを通じて、個々のI/Oスタック要素に関する情報が伝達されます。この情報を使用して、ユーザーが問合せできる動的パフォーマンス・ビューが移入されます。

マッピングを完成するには、すべてのスタック・レベルにマッピング・ライブラリが存在する必要があり、各ライブラリがI/Oマッピング・スタックの独自部分を所有できます。たとえば、VERITAS VxVMライブラリはVERITASボリューム・マネージャに関連するスタック要素を所有し、EMCライブラリはI/Oマッピング・スタックのうちすべてのEMCストレージ固有レイヤーを所有します。

マッピング・ライブラリはベンダーから提供されます。ただし、現在、OracleにはEMCストレージ用のマッピング・ライブラリが用意されています。データベース・サーバーに使用可能なマッピング・ライブラリは、特殊ファイルfilemap.ora内で識別されます。

マッピング構造

この項では、マッピング構造とそのOracle Database表現について説明します。マッピング・ビューに表示される情報を解析するには、この情報を理解する必要があります。

マッピング情報を構成する基本構造は、次のとおりです。

- ファイル
すべてのマッピング構造は、ファイル・サイズ、ファイルを構成するファイル・システムのエクステント数およびファイル・タイプなど、ファイルの属性セットを提供します。

- ファイル・システムのエクステント
ファイル・システムのエクステントのマッピング構造では、1つの要素にあるブロックの連続するチャンクが記述されます。これには、デバイス・オフセット、エクステント・サイズ、ファイル・オフセット、タイプ(データまたはパリティ)およびエクステントが常駐する要素の名前が含まれます。

注意:
ファイル・システムのエクステントは、Oracle Databaseのエクステントとは異なります。ファイル・システムのエクステントは、そのファイル・システムで管理されるデバイスに書き込まれる連続する物理データ・ブロックです。Oracle Databaseのエクステントは、表領域エクステントなど、データベースで管理される論理構造です。

- 要素
要素のマッピング構造は、I/Oスタック内の記憶域コンポーネントを記述する抽象マッピング構造です。要素には、ミラー、ストライプ、パーティション、RAID5、連結要素およびディスクがあります。これらの構造は、マッピングのビルディング・ブロックです。

- 副要素
副要素のマッピング構造では、I/Oマッピング・スタック内のある要素と次の要素のリンクが記述されます。この構造には、副要素番号、サイズ、副要素が存在する要素の名前および要素のオフセットが含まれます。

次の例は、これらのマッピング構造すべてを示しています。

マッピング構造の例

XとYの2つのデータファイルで構成されるOracle Databaseを考えてみます。ファイルXとYはいずれも、ボリュームAにマウントされているファイル・システムに存在します。ファイルXは2つのエクステントによって構成され、ファイルYは1つのエクステントのみによって構成されています。

ファイルXの2つのエクステントとファイルYの1つのエクステントは、いずれも要素Aにマップされます。要素Aは、要素BおよびCにストライプ化されています。要素Aは、副要素B0とC1を介してそれぞれ要素BとCにマップされます。

要素Bは、要素D(物理ディスク)のパーティションで、副要素D0を介して要素Dにマップされます。

要素Cは、副要素E0とF1を介してそれぞれ要素EとF(両方とも物理ディスク)にまたがってミラー化されています。

図15-2は、すべてのマッピング構造を示しています。

図15-2 マッピング構造の図

この図が示すマッピング構造は、Oracle Databaseインスタンスのマッピング情報全体を記述するには十分であり、ファイル内の各論理ブロックをI/Oスタック内の各レベルで1つ(またはミラー化の場合は1つ以上)の(要素名、要素オフセットの)タプルにマップしていることに注意してください。

構成ID

構成IDでは、要素またはファイルに関連付けられたバージョン情報を取得します。ベンダーのライブラリには構成IDが用意されており、変更があるたびに更新されます。構成IDがなければ、データベースではマッピングに変更があったかどうかを指示できません。

構成IDには、次の2種類があります。

- 永続
この種の構成IDは、インスタンスが停止されても持続します。

- 非永続
この種の構成IDは、インスタンスが停止すると持続しません。データベースでは、インスタンスが稼働している間にのみマッピング情報をリフレッシュできます。

Oracle Databaseのファイル・マッピング・インタフェースの使用方法

ここでは、Oracle Databaseのファイル・マッピング・インタフェースの使用方法について説明します。内容は次のとおりです。

- ファイル・マッピングの有効化

- DBMS_STORAGE_MAPパッケージの使用

- ファイル・マッピング・ビューからの情報の取得

ファイル・マッピングの有効化

ファイル・マッピング機能を使用可能にする手順は、次のとおりです。

1. 32ビット・プラットフォームの場合は/opt/ORCLfmap/prot1_32/etcディレクトリ、64ビット・プラットフォームの場合は/opt/ORCLfmap/prot1_64/etcディレクトリに、有効なfilemap.oraファイルが存在することを確認します。

注意:
filemap.oraファイルの形式と内容についてはこの項で説明しますが、これはあくまでも参考情報です。filemap.oraファイルは、システムのインストール時にデータベースによって作成されます。ベンダーから独自ライブラリが提供されるまで、filemap.oraファイルのエントリは1つのみで、オラクル社が提供するEMCライブラリに関するものです。EMC Symmetrix配列が使用可能な場合のみ、このファイルを手動で変更する必要があり、このエントリのコメントを解除します。

filemap.oraファイルは、使用可能なすべてのマッピング・ライブラリが記述されている構成ファイルです。FMONを使用するには、filemap.oraファイルが存在し、マッピング・ライブラリへの有効なパスを指している必要があります。それ以外の場合は、正常に起動しません。

ライブラリごとに、次の行をfilemap.oraに含める必要があります。

lib=vendor_name:mapping_library_path

説明:

- vendor_nameには、EMC Symmetricライブラリの場合はOracleを指定します。

- mapping_library_pathには、マッピング・ライブラリのフルパスを指定します。

このファイル内のライブラリの順序がきわめて重要であることに注意してください。各ライブラリは、構成ファイル内での順序に基づいて問合せされます。

ファイル・マッピング・サービスは、使用可能なマッピング・ライブラリがなくても起動できます。filemap.oraファイルは、空であっても存在する必要があります。この場合、マッピング・サービスは、新しいマッピング情報を検出できないという制約を伴います。この種の構成で許可されるのは、リストア操作と削除操作のみです。

2. FILE_MAPPING初期化パラメータをTRUEに設定します。
このパラメータを設定するためにインスタンスを停止する必要はありません。次のALTER SYSTEM文を使用して設定できます。

ALTER SYSTEM SET FILE_MAPPING=TRUE;

3. 適切なDBMS_STORAGE_MAPマッピング・プロシージャを起動します。次の2つのオプションがあります。

- コールド・スタートの使用例では、Oracle Databaseが起動するのみで、まだマッピング操作は起動されていません。DBMS_STORAGE_MAP.MAP_ALLプロシージャを実行して、データベースに関連するI/Oサブシステム全体のマッピング情報を作成します。

- ウォーム・スタートの使用例では、マッピング情報はすでに作成されており、DBMS_STORAGE_MAP.MAP_SAVEプロシージャを起動してマッピング情報をデータ・ディクショナリに保存するかどうかをオプションで選択できます。(このプロシージャは、デフォルトでDBMS_STORAGE_MAP.MAP_ALL()内で起動します。)これにより、SGA内のすべてのマッピング情報がディスクに強制的にフラッシュされます。
データベースの再起動後に、DBMS_STORAGE_MAP.RESTORE()を使用してマッピング情報をSGAにリストアします。必要な場合は、DBMS_STORAGE_MAP.MAP_ALL()をコールしてマッピング情報をリフレッシュできます。

DBMS_STORAGE_MAPパッケージの使用

DBMS_STORAGE_MAPパッケージによってマッピング操作を制御できる。次の表に、使用可能な各種プロシージャを示します。

プロシージャ

用途

MAP_OBJECT

オブジェクト名、所有者およびタイプで識別されるデータベース・オブジェクトのマッピング情報を作成します。

MAP_ELEMENT

指定した要素のマッピング情報を作成します。

MAP_FILE

指定したファイル名のマッピング情報を作成します。

MAP_ALL

すべてのタイプのデータベース・ファイル(アーカイブ・ログ以外)のマッピング情報全体を作成します。

DROP_ELEMENT

指定した要素のマッピング情報を削除します。

DROP_FILE

指定したファイル名のファイル・マッピング情報を削除します。

DROP_ALL

このインスタンスのSGAからすべてのマッピング情報を削除します。

SAVE

マッピング全体の再生成に必要な情報をデータ・ディクショナリに保存します。

RESTORE

マッピング情報全体をデータ・ディクショナリからインスタンスの共有メモリーにロードします。

LOCK_MAP

このインスタンスのSGA内でマッピング情報をロックします。

UNLOCK_MAP

このインスタンスのSGA内でマッピング情報のロックを解除します。

関連項目:

- DBMS_STORAGE_MAPパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- DBMS_STORAGE_MAPパッケージの使用例は、「ファイル・マッピングの例」を参照してください。

ファイル・マッピング・ビューからの情報の取得

DBMS_STORAGE_MAPパッケージにより生成されたマッピング情報は、動的パフォーマンス・ビューで取得されます。次の表に、これらのビューの概要を示します。

ビュー

説明

V$MAP_LIBRARY

外部プロセスにより動的にロードされたすべてのマッピング・ライブラリのリストが含まれています。

V$MAP_FILE

インスタンスの共有メモリーにあるすべてのファイル・マッピング構造のリストが含まれています。

V$MAP_FILE_EXTENT

インスタンスの共有メモリーにあるすべてのファイル・システム・エクステントのマッピング構造のリストが含まれています。

V$MAP_ELEMENT

インスタンスのSGAにあるすべての要素マッピング構造のリストが含まれています。

V$MAP_EXT_ELEMENT

すべての要素マッピングの補足情報が含まれています。

V$MAP_SUBELEMENT

インスタンスの共有メモリーにあるすべての副要素マッピング構造のリストが含まれています。

V$MAP_COMP_LIST

すべての要素マッピング構造の補足情報が含まれています。

V$MAP_FILE_IO_STACK

ファイルの記憶域コンテナの階層配列が一連の行として表示されます。各行は1つの階層レベルを表します。

関連項目:
動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ただし、DBMS_STORAGE_MAP.MAP_OBJECTプロシージャにより生成された情報は、グローバルな一時表MAP_OBJECTに取得されます。この表には、オブジェクトの記憶域コンテナの階層配置が表示されます。この表の各行は、階層レベルを表します。MAP_OBJECT表の内容は、次のとおりです。

列

データ型

説明

OBJECT_NAME

VARCHAR2(2000)

オブジェクト名。

OBJECT_OWNER

VARCHAR2(2000)

オブジェクトの所有者

OBJECT_TYPE

VARCHAR2(2000)

オブジェクト型

FILE_MAP_IDX

NUMBER

ファイルの索引(V$MAP_FILE内のFILE_MAP_IDXに対応)

DEPTH

NUMBER

I/Oスタック内の要素の深さ

ELEM_IDX

NUMBER

要素に対応する索引。

CU_SIZE

NUMBER

要素上に連続して存在する、ファイルの論理ブロックの連続するセット(HKB単位)。

STRIDE

NUMBER

この要素上で連続しているファイル内の連続単位(CU)間のHKB数。RAID5ファイルとストライプ・ファイルに使用される。

NUM_CU

NUMBER

この要素上で相互に隣接していて、ファイル内でSTRIDE HKBで区切られている連続単位の数。RAID5の場合、連続単位数にはパリティ・ストライプも含まれる。

ELEM_OFFSET

NUMBER

要素オフセット(HKB単位)

FILE_OFFSET

NUMBER

ファイルの先頭から連続単位の先頭バイトまでのオフセット(HKB単位)

DATA_TYPE

VARCHAR2(2000)

データ型(DATA、PARITYまたはDATA AND PARITY)

PARITY_POS

NUMBER

パリティの位置。RAID5の場合のみ。このフィールドはパリティとデータ部分を区別するために必要である。

PARITY_PERIOD

NUMBER

パリティ間隔。RAID5の場合のみ。

ファイル・マッピングの例

次の例では、Oracle Databaseのファイル・マッピング機能の強力な機能について説明します。次のような機能があります。

- 特定のデバイスにまたがるすべてのデータベース・ファイルをマップする機能

- 特定のファイルを対応するデバイスにマップする機能

- I/Oスタックのすべてのレベルでブロックを配分するなど、特定のデータベース・オブジェクトをマップする機能

次の2つのデータファイルで構成されるOracle Databaseインスタンスを考えてみます。

- t_db1.f

- t_db2.f

この2つのファイルは、VERITAS VxVMホスト・ベースのストライプ化ボリューム/dev/vx/dsk/ipfdg/ipf-vol1にマウントされたSolaris UFSファイル・システム上で作成されており、このボリュームはEMC Symmetrix配列から外部化された次のホスト・デバイスで構成されているとします。

- /dev/vx/rdmp/c2t1d0s2

- /dev/vx/rdmp/c2t1d1s2

次の例では、MAP_ALL()操作を実行する必要があることに注意してください。

例1: 1つのデバイスにまたがるすべてのデータベース・ファイルのマッピング

次の問合せでは、/dev/vx/rdmp/c2t1d1s2ホスト・デバイスに関連付けられたすべてのOracle Databaseファイルが戻されます。

SELECT UNIQUE me.ELEM_NAME, mf.FILE_NAME
FROM V$MAP_FILE_IO_STACK fs, V$MAP_FILE mf, V$MAP_ELEMENT me
WHERE mf.FILE_MAP_IDX = fs.FILE_MAP_IDX
AND me.ELEM_IDX = fs.ELEM_IDX
AND me.ELEM_NAME = '/dev/vx/rdmp/c2t1d1s2';

問合せ結果は次のとおりです。

ELEM_NAME                 FILE_NAME
------------------------  --------------------------------
/dev/vx/rdmp/c2t1d1s2     /oracle/dbs/t_db1.f
/dev/vx/rdmp/c2t1d1s2     /oracle/dbs/t_db2.f

例2: ファイルから対応するデバイスへのマッピング

次の問合せでは、/oracle/dbs/t_db1.fデータファイルのトポロジ・グラフが表示されます。

WITH fv AS
(SELECT FILE_MAP_IDX, FILE_NAME FROM V$MAP_FILE
WHERE FILE_NAME = '/oracle/dbs/t_db1.f')
SELECT fv.FILE_NAME, LPAD(' ', 4 * (LEVEL - 1)) || el.ELEM_NAME ELEM_NAME
FROM V$MAP_SUBELEMENT sb, V$MAP_ELEMENT el, fv,
(SELECT UNIQUE ELEM_IDX FROM V$MAP_FILE_IO_STACK io, fv
WHERE io.FILE_MAP_IDX = fv.FILE_MAP_IDX) fs
WHERE el.ELEM_IDX = sb.CHILD_IDX
AND fs.ELEM_IDX = el.ELEM_IDX
START WITH sb.PARENT_IDX IN
(SELECT DISTINCT ELEM_IDX
FROM V$MAP_FILE_EXTENT fe, fv
WHERE fv.FILE_MAP_IDX = fe.FILE_MAP_IDX)
CONNECT BY PRIOR sb.CHILD_IDX = sb.PARENT_IDX;

表示されるトポロジ・グラフは次のとおりです。

FILE_NAME                    ELEM_NAME
-----------------------      -------------------------------------------------
/oracle/dbs/t_db1.f          _sym_plex_/dev/vx/rdsk/ipfdg/ipf-vol1_-1_-1
/oracle/dbs/t_db1.f              _sym_subdisk_/dev/vx/rdsk/ipfdg/ipf-vol1_0_0_0
/oracle/dbs/t_db1.f                  /dev/vx/rdmp/c2t1d0s2
/oracle/dbs/t_db1.f                      _sym_symdev_000183600407_00C
/oracle/dbs/t_db1.f                          _sym_hyper_000183600407_00C_0
/oracle/dbs/t_db1.f                          _sym_hyper_000183600407_00C_1
/oracle/dbs/t_db1.f              _sym_subdisk_/dev/vx/rdsk/ipfdg/ipf-vol1_0_1_0
/oracle/dbs/t_db1.f                  /dev/vx/rdmp/c2t1d1s2
/oracle/dbs/t_db1.f                      _sym_symdev_000183600407_00D
/oracle/dbs/t_db1.f                          _sym_hyper_000183600407_00D_0
/oracle/dbs/t_db1.f                          _sym_hyper_000183600407_00D_1

例3: データベース・オブジェクトのマッピング

この例では、scott.bonus表についてI/Oスタックの全レベルにおけるブロックの分散を表示します。

次のように、最初にMAP_OBJECT()操作を実行する必要があります。

EXECUTE DBMS_STORAGE_MAP.MAP_OBJECT('BONUS','SCOTT','TABLE');

問合せは次のとおりです。

SELECT io.OBJECT_NAME o_name, io.OBJECT_OWNER o_owner, io.OBJECT_TYPE o_type,
mf.FILE_NAME, me.ELEM_NAME, io.DEPTH,
(SUM(io.CU_SIZE * (io.NUM_CU - DECODE(io.PARITY_PERIOD, 0, 0,
TRUNC(io.NUM_CU / io.PARITY_PERIOD)))) / 2) o_size
FROM MAP_OBJECT io, V$MAP_ELEMENT me, V$MAP_FILE mf
WHERE io.OBJECT_NAME =  'BONUS'
AND   io.OBJECT_OWNER = 'SCOTT'
AND   io.OBJECT_TYPE =  'TABLE'
AND   me.ELEM_IDX = io.ELEM_IDX
AND   mf.FILE_MAP_IDX = io.FILE_MAP_IDX
GROUP BY io.ELEM_IDX, io.FILE_MAP_IDX, me.ELEM_NAME, mf.FILE_NAME, io.DEPTH,
io.OBJECT_NAME, io.OBJECT_OWNER, io.OBJECT_TYPE
ORDER BY io.DEPTH;

問合せの結果は次のとおりです。o_size列がKB単位で表されていることに注意してください。

O_NAME O_OWNER O_TYPE  FILE_NAME            ELEM_NAME                      DEPTH   O_SIZE
------ ------- ------  -------------------  -----------------------------  ------  ------
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  /dev/vx/dsk/ipfdg/ipf-vol1          0      20
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  _sym_plex_/dev/vx/rdsk/ipf          1      20
pdg/if-vol1_-1_-1
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  _sym_subdisk_/dev/vx/rdsk/          2      12
ipfdg/ipf-vol1_0_1_0
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  _sym_subdisk_/dev/vx/rdsk/ipf       2       8
dg/ipf-vol1_0_2_0
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  /dev/vx/rdmp/c2t1d1s2               3      12
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  /dev/vx/rdmp/c2t1d2s2               3       8
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  _sym_symdev_000183600407_00D        4      12
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  _sym_symdev_000183600407_00E        4       8
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  _sym_hyper_000183600407_00D_0       5      12
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  _sym_hyper_000183600407_00D_1       5      12
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  _sym_hyper_000183600407_00E_0       6       8
BONUS  SCOTT   TABLE   /oracle/dbs/t_db1.f  _sym_hyper_000183600407_00E_1       6       8

データファイルのデータ・ディクショナリ・ビュー

次のデータ・ディクショナリ・ビューは、データベースのデータファイルに関して役立つ情報を提供します。

ビュー

説明

DBA_DATA_FILES

属している表領域やファイルIDなど、各データファイルに関する記述情報が表示されます。ファイルIDを使用すると、他のビューと結合して詳細情報を得ることができます。

DBA_EXTENTS
USER_EXTENTS

DBAビューには、データベース内のすべてのセグメントを構成するエクステントが表示されます。エクステントを含むデータファイルのファイルIDが含まれます。USERビューには、現行ユーザーの所有するオブジェクトに属するセグメントのエクステントが表示されます。

DBA_FREE_SPACE
USER_FREE_SPACE

DBAビューには、すべての表領域の使用可能エクステントが表示されます。エクステントを含むデータファイルのファイルIDが含まれます。USERビューには、現行ユーザーからアクセス可能な表領域の使用可能エクステントが表示されます。

V$DATAFILE

制御ファイル内のデータファイル情報が含まれます。

V$DATAFILE_HEADER

データファイル・ヘッダーからの情報が含まれます。

ここでは、これらのビューの1つであるV$DATAFILEの使用例を示します。

SELECT NAME,
FILE#,
STATUS,
CHECKPOINT_CHANGE# "CHECKPOINT"
FROM   V$DATAFILE;

NAME                                      FILE#     STATUS       CHECKPOINT
--------------------------------          -----     -------       ----------
/u01/oracle/rbdb1/system01.dbf                1     SYSTEM              3839
/u02/oracle/rbdb1/temp01.dbf                  2     ONLINE              3782
/u02/oracle/rbdb1/users03.dbf                 3     OFFLINE             3782

FILE#には、各データファイルのファイル番号がリストされ、データベースとともに作成されたSYSTEM表領域の最初のデータファイルが常にファイル1になります。STATUSには、データファイルに関するその他の情報がリストされます。データファイルがSYSTEM表領域の一部である場合、そのステータスはSYSTEMです(リカバリが必要な場合を除く)。SYSTEM表領域以外のデータファイルがオンラインである場合、そのステータスはONLINEです。SYSTEM表領域以外のデータファイルがオフラインである場合、そのステータスはOFFLINEまたはRECOVERです。CHECKPOINTには、データファイルの最新チェックポイントで書き込まれた最後のSCN (システム変更番号)がリストされます。

関連項目:
これらのビューの完全な説明は、『Oracle Databaseリファレンス』を参照してください。

16 UNDOの管理

リリース11g からは、デフォルトのインストールで、Oracle DatabaseによってUNDOが自動的に管理されます。通常、DBAによる操作は不要です。ただし、インストールでOracle Flashback操作を使用する場合は、それらの操作が正常に終了するように、UNDO管理タスクをいくつか実行することが必要な場合があります。

この章の内容は、次のとおりです。

- UNDOの概要

- 自動UNDO管理の概念

- 最小UNDO保存期間の設定

- 固定サイズのUNDO表領域のサイズ変更

- UNDO表領域の管理

- 自動UNDO管理への移行

- UNDO領域のデータ・ディクショナリ・ビュー

関連項目:
Oracle Databaseによってデータファイルが作成および管理されるUNDO表領域の作成方法は、第17章「Oracle Managed Filesの使用」を参照してください。

UNDOの概要

Oracle Databaseでは、データベースの変更をロールバックまたは取り消すために使用する情報を作成して管理します。これらの情報は、主にコミットされる前のトランザクションの処理レコードから構成されます。これらのレコードを総称してUNDOと呼びます。

UNDOレコードは次の処理に使用されます。

- ROLLBACK文を発行したときのトランザクションのロールバック

- データベースのリカバリ

- 読込み一貫性の提供

- Oracle Flashback Queryを使用した過去のある時点のデータの分析

- Oracle Flashback機能を使用した論理的な破損のリカバリ

ROLLBACK文を発行すると、コミットされていないトランザクションによってデータベースに加えられた変更が、UNDOレコードを使用して取り消されます。データベース・リカバリ時は、REDOログからデータファイルに適用されたコミットされていない変更が、UNDOレコードを使用してすべて取り消されます。UNDOレコードは、あるユーザーがデータを変更しているときに同じデータに同時にアクセスしようとしている別のユーザーのために、そのデータの変更前のイメージを維持することによって読込み一貫性を提供します。

自動UNDO管理の概念

この項では、自動UNDO管理の概念について説明します。この項の内容は、次のとおりです。

- 自動UNDO管理の概要

- UNDOの保存期間

自動UNDO管理の概要

Oracleには、ロールバック情報と領域を管理するための、自動UNDO管理と呼ばれる完全に自動化されたメカニズムが用意されています。自動UNDO管理では、データベースによってUNDOセグメントがUNDO表領域で管理されます。リリース11g からは、新しくインストールされたデータベースに対して自動UNDO管理がデフォルト・モードになります。Database Configuration Assistant(DBCA)を使用してデータベースを作成すると、UNDOTBS1という自動拡張可能なUNDO表領域が自動的に作成されます。

UNDO表領域は明示的に作成することもできます。UNDO表領域の作成方法については、「UNDO表領域の作成」を参照してください。

インスタンスが起動すると、データベースは最初に使用可能になったUNDO表領域を自動的に選択します。使用可能なUNDO表領域がない場合、インスタンスはUNDO表領域なしで起動され、UNDOレコードはSYSTEM表領域に格納されます。これは推奨される状態ではなく、アラート・ログ・ファイルには、システムがUNDO表領域のない状態で稼働していることを伝える警告メッセージが書き込まれます。

データベースに複数のUNDO表領域があるときは、必要に応じて、起動時に特定のUNDO表領域を使用するように指定することもできます。これには、次の例のように、UNDO_TABLESPACE初期化パラメータを設定します。

UNDO_TABLESPACE = undotbs_01

初期化パラメータで指定された表領域が存在しない場合、STARTUPコマンドは失敗します。Oracle Real Application Clusters環境でUNDO_TABLESPACEパラメータを使用すると、インスタンスに特定のUNDO表領域を割り当てることができます。

データベースは手動UNDO管理モードでも稼働できます。このモードでは、UNDO領域がロールバック・セグメントを介して管理され、UNDO表領域は使用されません。

注意:
ロールバック・セグメントの領域管理は複雑です。データベースを自動UNDO管理モードのままにすることをお薦めします。

次に、UNDO管理用の初期化パラメータの概要を示します。

初期化パラメータ

説明

UNDO_MANAGEMENT

AUTOまたはNULLの場合は、自動UNDO管理を使用可能にします。MANUALの場合は、手動UNDO管理モードを設定します。デフォルトはAUTOです。

UNDO_TABLESPACE

自動UNDO管理モードの場合のみ有効です(オプション)。UNDO表領域の名前を指定します。データベースに複数のUNDO表領域があり、データベース・インスタンスで特定のUNDO表領域を使用するように指定する場合にのみ使用します。

自動UNDO管理が使用可能な場合は、初期化パラメータ・ファイルに手動UNDO管理に関するパラメータが含まれていても、それらは無視されます。

注意:
Oracle Databaseの以前のリリースでは、手動UNDO管理モードがデフォルトです。自動UNDO管理モードに変更するには、UNDO表領域を作成してからUNDO_MANAGEMENT初期化パラメータをAUTOに変更する必要があります。Oracle Databaseがリリース9i以上で、自動UNDO管理に変更する場合、手順については『Oracle Databaseアップグレード・ガイド』を参照してください。
UNDO_MANAGEMENT初期化パラメータがNULLの場合、リリース11g 以上では自動UNDO管理モードにデフォルト設定されますが、以前のリリースでは手動UNDO管理モードにデフォルト設定されます。したがって、以前のリリースをリリース11gにアップグレードする場合は注意が必要です。UNDO表領域のサイズの設定方法に関する情報など、自動UNDO管理モードに移行するための適切な方法については、『Oracle Databaseアップグレード・ガイド』を参照してください。

関連項目:
UNDO管理で使用する初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

UNDOの保存期間

トランザクションがコミットされると、ロールバックまたはトランザクション・リカバリの実行にUNDOデータは不要になります。しかし、長時間実行の問合せ中にデータ・ブロックの変更前のイメージを生成する場合は、読込み一貫性を保証するために古いロールバック情報が必要になることがあります。また、いくつかのOracle Flashback機能を正常に終了させるには、古いロールバック情報が必要になる場合があります。このため、古いロールバック情報をできるかぎり長い期間保存することをお薦めします。

自動UNDO管理が使用可能な場合は、常に現在のUNDO保存期間が存在します。これは、Oracle Databaseが古いロールバック情報を上書きするまでの最小保存期間です。現在のUNDO保存期間よりも古い(コミット済の)UNDO情報は期限切れと呼ばれ、この領域は新しいトランザクションによって上書きできるようになります。現在のUNDO保存期間内の古いUNDO情報は期限切れでないUNDO情報と呼ばれ、読取り一貫性およびOracle Flashback操作のために保存されます。

Oracle Databaseでは、UNDO表領域サイズとシステム・アクティビティに基づいて、UNDO保存期間を自動的にチューニングします。必要に応じてUNDO_RETENTION初期化パラメータを設定することで、最小UNDO保存期間(秒単位)を指定できます。次に、UNDO保存期間にこのパラメータが具体的にどのような影響を与えるかを説明します。

- 固定サイズのUNDO表領域の場合、UNDO_RETENTIONパラメータは無視されます。データベースでは、システム・アクティビティとUNDO表領域サイズに基づいて、常に最適な保存期間を確保するようにUNDO保存期間をチューニングします。詳細は、「UNDOの保存期間の自動チューニング」を参照してください。

- AUTOEXTENDオプションが有効なUNDO表領域の場合、データベースでは、UNDO_RETENTIONで指定された最小保存期間を維持しようとします。空き領域が少なくなると、期限切れでないロールバック情報を上書きするかわりに、表領域が自動的に拡張されます。自動拡張可能なUNDO表領域に対してMAXSIZE句が指定されている場合は、最大サイズに到達すると、データベースは期限切れでないロールバック情報の上書きを開始する場合があります。DBCAで自動的に作成されたUNDOTBS1表領域は、自動的に拡張します。

UNDOの保存期間の自動チューニング

Oracle Databaseでは、UNDO表領域の構成方法に基づいて、UNDO保存期間を自動的にチューニングします。

- UNDO表領域がAUTOEXTENDオプションで構成されている場合、データベースでは、UNDOの保存期間を、システムでアクティブな最長実行問合せより若干長くなるように動的にチューニングします。ただし、この保存期間は、Oracle Flashback操作に対応するには不十分な場合があります。Oracle Flashback操作で「スナップショットが古すぎます」エラーが発生する場合は、これらの操作をサポートするのに十分なUNDOデータが保存されるように、ユーザーが介入する必要があることを示しています。Oracle Flashback機能にさらに対応するには、UNDO_RETENTIONパラメータを予想される最長のOracle Flashback操作時間と同じ値に設定したり、UNDO表領域を固定サイズに変更することもできます。

- UNDO表領域が固定サイズの場合、データベースでは、表領域のサイズと現行のシステムの負荷に対して最適な保存期間を確保するように、UNDO保存期間を動的にチューニングします。通常、この最適な保存期間は、アクティブな最長実行問合せの期間よりもかなり長くなります。
UNDO表領域を固定サイズに変更する場合は、十分な大きさの表領域サイズを選択する必要があります。小さすぎるUNDO表領域サイズを選択すると、次の2つのエラーが発生する可能性があります。

- DMLが失敗する可能性。これは、新しいトランザクションに対するUNDOを格納するための十分な領域がないためです。

- 「スナップショットが古すぎます」というエラーが発生し、長時間実行問合せが失敗します。これは、UNDOデータが不足しているために読取り一貫性を維持できないことを意味します。

詳細は、「固定サイズのUNDO表領域のサイズ変更」を参照してください。

注意:
UNDO保存の自動チューニングは、LOBに対してサポートされていません。これは、LOBのロールバック情報がUNDO表領域ではなく、セグメント自体に格納されるためです。LOBの場合、データベースでは、UNDO_RETENTIONで指定された最小保存期間を維持しようとします。ただし、空き領域が少なくなると、期限切れでないLOBのロールバック情報が上書きされる場合があります。

関連項目:
「最小UNDO保存期間の設定」

保存期間の保証

長時間実行される問合せやOracle Flashback操作を正常に行うために、保存期間の保証を有効化できます。保存期間の保証を有効にすると、指定したUNDOの最小保存期間が保証され、UNDO表領域の領域不足によってトランザクションが失敗した場合でも、期限切れでないUNDOデータは上書きされません。保存期間の保証を有効にしないと、領域が十分でない場合、期限切れでないUNDOが上書きされる場合があるため、システムのUNDO保存期間が短くなります。このオプションはデフォルトでは無効です。

警告:

保存期間の保証を有効にすると、複数のDML操作が失敗する可能性があります。この機能は注意して使用してください。

保存期間の保証を有効にするには、CREATE DATABASE文またはCREATE UNDO TABLESPACE文を使用してUNDO表領域を作成するときに、そのUNDO表領域に対してRETENTION GUARANTEE句を指定します。または、後でこの句をALTER TABLESPACE文で指定することもできます。保存期間の保証を無効にするには、RETENTION NOGUARANTEE句を使用します。

DBA_TABLESPACESビューを使用して、UNDO表領域の保存期間の保証の設定を確認できます。RETENTION列には、GUARANTEE、NOGUARANTEEまたはNOT APPLY(NOT APPLYはUNDO表領域以外の表領域で使用)の値が表示されます。

UNDOの保存期間のチューニングとアラートしきい値

固定サイズのUNDO表領域を使用する場合、データベースでは、データベース統計とUNDO表領域のサイズに基づいて最適な保存期間を計算します。最適なUNDO管理を実現するために、データベースでは、UNDOの保存期間を、表領域サイズの100%ではなく、85%を基にチューニングするか、または使用済領域に対する警告アラートしきい値の率でチューニングするか、いずれか低い方に基づいてチューニングします。(警告アラートしきい値のデフォルトは85%ですが、変更が可能です。)したがって、UNDO表領域の警告アラートしきい値を85%未満に設定すると、チューニングされるUNDO保存期間の長さが短くなることがあります。表領域のアラートしきい値の詳細は、「表領域のアラートの管理」を参照してください。

チューニング済UNDO保存期間の追跡

現行の保存期間を判別するには、V$UNDOSTATビューのTUNED_UNDORETENTION列を問い合せます。このビューには、過去4日間における10分単位の統計収集間隔ごとに1行が表示されます。(4日以前のデータは、DBA_HIST_UNDOSTATビューに表示されます。)TUNED_UNDORETENTIONは秒数で表示されます。

select to_char(begin_time, 'DD-MON-RR HH24:MI') begin_time,
to_char(end_time, 'DD-MON-RR HH24:MI') end_time, tuned_undoretention
from v$undostat order by end_time;

BEGIN_TIME      END_TIME        TUNED_UNDORETENTION
--------------- --------------- -------------------
04-FEB-05 00:01 04-FEB-05 00:11               12100
...
07-FEB-05 23:21 07-FEB-05 23:31               86700
07-FEB-05 23:31 07-FEB-05 23:41               86700
07-FEB-05 23:41 07-FEB-05 23:51               86700
07-FEB-05 23:51 07-FEB-05 23:52               86700

576 rows selected.

V$UNDOSTATの詳細は、『Oracle Databaseリファレンス』を参照してください。

最小UNDO保存期間の設定

最小UNDO保存期間(秒単位)を指定するには、UNDO_RETENTION初期化パラメータを設定します。「UNDOの保存期間」で説明されているように、現行のUNDO保存期間はUNDO_RETENTIONよりも大きくなるように、または保存期間の保証が有効な場合を除き、空き領域が少ない場合はUNDO_RETENTIONよりも少なくなるように自動的にチューニングされます。

最小UNDO保存期間の設定方法

- 次のいずれかを実行します。

- 初期化パラメータ・ファイルでUNDO_RETENTIONを設定します。

UNDO_RETENTION = 1800

- UNDO_RETENTIONは、ALTER SYSTEM文を使用していつでも変更できます。

ALTER SYSTEM SET UNDO_RETENTION = 2400;

UNDO_RETENTIONパラメータの変更は即時に反映されますが、その効果は、現行のUNDO表領域に十分な領域がある場合のみ表れます。

固定サイズのUNDO表領域のサイズ変更

UNDO保存期間の動的チューニングは、通常、固定サイズのUNDO表領域に有効です。固定サイズの表領域を使用する場合は、UNDOアドバイザを使用すると、必要な容量を見積るのに役立ちます。UNDOアドバイザには、Enterprise ManagerまたはDBMS_ADVISOR PL/SQLパッケージを介してアクセスできます。このアドバイザには、Enterprise Managerを介してアクセスすることをお薦めします。Enterprise Managerを介してUNDOアドバイザを使用する方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

UNDOアドバイザは、自動ワークロード・リポジトリ(AWR)に収集されたデータに基づいて分析します。したがって、AWRで適切なワークロード統計を使用可能にし、UNDOアドバイザが正確な推奨事項を作成できるようにすることが重要です。新規作成したデータベースでは、適切な統計がすぐに使用できない場合があります。このような場合は、少なくとも1つのワークロード・サイクルが完了するまで、デフォルトの自動拡張可能なUNDO表領域を引き続き使用してください。

AWR統計の収集間隔と保存期間の調整は、アドバイザが作成する推奨事項の精度とタイプに影響します。詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

UNDOアドバイザを使用する場合は、最初に次の2つの値を見積ります。

- 最長実行問合せの予想される長さ
データベースによるワークロード・サイクルが完了すると、「自動UNDO管理」ページの「システム・アクティビティ」サブページにある「最長実行問合せ」フィールドを表示できます。

- Oracle Flashback操作に必要な最長間隔
たとえば、過去に最大48時間のOracle Flashback問合せを実行したと予想される場合、Oracle Flashback要件は48時間です。

次に、これら2つの値のうち最大値を選択し、その値をUNDOアドバイザへの入力として使用します。

UNDOアドバイザの実行によって、UNDO表領域のサイズは変更されません。アドバイザは推奨事項を単に返します。表領域のデータファイルを固定サイズに変更するには、ALTER DATABASE文を使用する必要があります。

次の例では、UNDO表領域にundotbs.dbfという自動拡張可能なデータファイルあると仮定します。この例では、表領域を300MBの固定サイズに変更します。

ALTER DATABASE DATAFILE '/oracle/dbs/undotbs.dbf' RESIZE 300M;
ALTER DATABASE DATAFILE '/oracle/dbs/undotbs.dbf' AUTOEXTEND OFF;

注意:
UNDO表領域を固定サイズにする場合は、まずデータベース作成後に十分な時間をかけて完全なワークロードを実行することをお薦めします。これにより、UNDO表領域がワークロードを処理するための必要最小限のサイズになります。その後、必要に応じてUNDOアドバイザを使用して、長時間実行される問合せやOracle Flashback操作に対応するために、UNDO表領域をどの程度拡大するかを決定します。

関連項目:
UNDOアドバイザを使用してUNDO表領域の最小サイズを計算する手順は、『Oracle Database 2日でデータベース管理者』を参照してください。

UNDOアドバイザのPL/SQLインタフェース

UNDOアドバイザをアクティブにするには、アドバイザ・フレームワークを使用してUNDOアドバイザ・タスクを作成します。次の例では、UNDO表領域を評価するためのUNDOアドバイザ・タスクを作成します。アドバイザの名前は'Undo Advisor'です。分析は自動ワークロード・リポジトリのスナップショットに基づいて実行され、このスナップショットは、START_SNAPSHOTパラメータとEND_SNAPSHOTパラメータを設定して指定する必要があります。次の例では、START_SNAPSHOTが1で、END_SNAPSHOTは2です。

DECLARE
tid    NUMBER;
tname  VARCHAR2(30);
oid    NUMBER;
BEGIN
DBMS_ADVISOR.CREATE_TASK('Undo Advisor', tid, tname, 'Undo Advisor Task');
DBMS_ADVISOR.CREATE_OBJECT(tname, 'UNDO_TBS', null, null, null, 'null', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'TARGET_OBJECTS', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'START_SNAPSHOT', 1);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'END_SNAPSHOT', 2);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'INSTANCE', 1);
DBMS_ADVISOR.execute_task(tname);
END;
/

アドバイザ・タスクを作成した後は、Enterprise Managerの自動データベース診断モニターに出力および推奨事項を表示できます。この情報は、DBA_ADVISOR_*データ・ディクショナリ・ビュー(DBA_ADVISOR_TASKS、DBA_ADVISOR_OBJECTS、DBA_ADVISOR_FINDINGS、DBA_ADVISOR_RECOMMENDATIONSなど)にも表示されます。

関連項目:

- 様々なアドバイザにアドバイザ・タスクを作成する例は、「セグメント・アドバイザの使用」を参照してください。

- DBA_ADVISOR_*データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

UNDO表領域の管理

この項では、UNDO表領域を管理する際に必要な手順について説明します。この項の内容は、次のとおりです。

- UNDO表領域の作成

- UNDO表領域の変更

- UNDO表領域の削除

- UNDO表領域の切替え

- UNDO領域に対するユーザー割当ての確立

- UNDO領域のデータ・ディクショナリ・ビュー

UNDO表領域の作成

Oracle Databaseリリース11g の新規インストールでは、Database Configuration Assistant(DBCA)によってUNDO表領域が自動的に作成されますが、UNDO表領域を手動で作成することが必要な場合があります。

UNDO表領域の作成には2つの方法があります。1つは、CREATE DATABASE文の発行時にUNDO表領域を作成する方法です。これは、データベースを新規作成中にインスタンスが自動UNDO管理モードで起動したとき(UNDO_MANAGEMENT = AUTO)に実行されます。もう1つは、既存のデータベースで使用する方法です。この場合はCREATE UNDO TABLESPACE文を使用します。

UNDO表領域にはデータベース・オブジェクトは作成できません。システム管理のUNDOデータ用に確保されています。

Oracle Databaseでは、単一ファイルUNDO表領域を作成できます。単一ファイル(bigfile)表領域については、「bigfile表領域」を参照してください。

CREATE DATABASEを使用したUNDO表領域の作成

CREATE DATABASE文でUNDO TABLESPACE句を使用すると、特定のUNDO表領域を作成できます。

次の文は、CREATE DATABASE文でのUNDO TABLESPACE句の使用例を示しています。ここでは、UNDO表領域にundotbs_01という名前を付け、/u01/oracle/rbdb1/undo0101.dbfという1つのデータファイルを割り当てています。

CREATE DATABASE rbdb1
CONTROLFILE REUSE
.
.
.
UNDO TABLESPACE undotbs_01 DATAFILE '/u01/oracle/rbdb1/undo0101.dbf';

CREATE DATABASEの実行中にUNDO表領域を正常に作成できない場合は、CREATE DATABASE操作全体が失敗します。データベース・ファイルをクリーン・アップし、エラーを訂正して、再度CREATE DATABASE操作を実行する必要があります。

また、データベース作成時に、CREATE DATABASE文を使用して単一ファイルUNDO表領域を作成できます。この動作については、「データベース作成時のbigfile表領域のサポート」を参照してください。

関連項目:
CREATE DATABASE文を使用してUNDO表領域を作成する構文については、『Oracle Database SQL言語リファレンス』を参照してください。

CREATE UNDO TABLESPACE文の使用

CREATE UNDO TABLESPACE文はCREATE TABLESPACE文とほぼ同じですが、UNDOキーワードを指定します。UNDO表領域の属性のほとんどはデータベースが決定しますが、データベース管理者はDATAFILE句を指定できます。

この例では、AUTOEXTENDオプションを使用してundotbs_02 UNDO表領域を作成しています。

CREATE UNDO TABLESPACE undotbs_02
DATAFILE '/u01/oracle/rbdb1/undo0201.dbf' SIZE 2M REUSE AUTOEXTEND ON;

複数のUNDO表領域を作成できますが、UNDO表領域は1つのみアクティブにできます。

関連項目:
CREATE UNDO TABLESPACE文を使用してUNDO表領域を作成する構文については、『Oracle Database SQL言語リファレンス』を参照してください。

UNDO表領域の変更

UNDO表領域を変更するには、ALTER TABLESPACE文を使用します。ただし、UNDO表領域のほとんどはシステムが管理しているため、考慮が必要になるのは次の操作のみです。

- データファイルの追加

- データファイル名の変更

- データファイルのオンライン化またはオフライン化

- データファイルのオープン状態のバックアップの開始または終了

- UNDOの保存期間の保証の有効化または無効化

DBAが変更可能な属性もこれらの属性のみです。

UNDO表領域が領域不足の場合、または領域不足の発生を防止する場合は、さらにファイルを追加したり、既存のデータファイルのサイズを変更できます。

次の例では、UNDO表領域undotbs_01にデータファイルを1つ追加しています。

ALTER TABLESPACE undotbs_01
ADD DATAFILE '/u01/oracle/rbdb1/undo0102.dbf' AUTOEXTEND ON NEXT 1M
MAXSIZE UNLIMITED;

ALTER DATABASE...DATAFILE文を使用すると、データファイルのサイズを変更または拡張できます。

関連項目:

- 「データファイルのサイズ変更」

- ALTER TABLESPACE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

UNDO表領域の削除

UNDO表領域を削除するには、DROP TABLESPACE文を使用します。次の例では、UNDO表領域undotbs_01を削除しています。

DROP TABLESPACE undotbs_01;

UNDO表領域は、現在どのインスタンスでも使用されていない場合にのみ削除できます。UNDO表領域に処理中のトランザクションが含まれている場合(トランザクションが失敗してまだリカバリされていない場合など)、DROP TABLESPACE文は失敗します。しかし、DROP TABLESPACEは、UNDO表領域に期限切れでない(保存期間内である)ロールバック情報が含まれている場合でもUNDO表領域を削除するため、既存の問合せでロールバック情報を必要とする場合は、UNDO表領域を削除しないように注意する必要があります。

UNDO表領域に対するDROP TABLESPACEは、DROP TABLESPACE...INCLUDING CONTENTSと同じように動作します。つまり、UNDO表領域の内容はすべて削除されます。

関連項目:
DROP TABLESPACE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

UNDO表領域の切替え

あるUNDO表領域から別のUNDO表領域に切り替えることができます。UNDO_TABLESPACE初期化パラメータは動的パラメータであるため、ALTER SYSTEM SET文を使用して新しいUNDO表領域を割り当てることができます。

次の文は、新しいUNDO表領域に切り替えます。

ALTER SYSTEM SET UNDO_TABLESPACE = undotbs_02;

undotbs_01が現行のUNDO表領域であるとすると、このコマンドが正常に実行された後、インスタンスはundotbs_01のかわりにundotbs_02をUNDO表領域として使用します。

切替え先の表領域が次のいずれかの条件を満たす場合はエラーがレポートされ、切替えは行われません。

- 表領域が存在しない場合

- 表領域がUNDO表領域ではない場合

- 表領域が別のインスタンスによってすでに使用されている場合(Oracle RAC環境のみ)

切替え操作が実行されている間、データベースはオンラインであり、このコマンドの実行中でもユーザー・トランザクションを実行できます。切替え操作が正常に完了すると、切替え操作開始後に開始されたすべてのトランザクションが新しいUNDO表領域内のトランザクション表に割り当てられます。

切替え操作は、古いUNDO表領域内のトランザクションがコミットされるまで待機しません。古いUNDO表領域内に未処理のトランザクションがある場合、古いUNDO表領域はPENDING OFFLINEモード(状態)になります。このモードでは、既存のトランザクションは引き続き実行できますが、新しいユーザー・トランザクションのUNDOレコードをこのUNDO表領域に格納することはできません。

UNDO表領域は、切替え操作が正常に完了した後も、このPENDING OFFLINEモードのまま存在できます。PENDING OFFLINEのUNDO表領域は、別のインスタンスが使用することも、削除することもできません。最終的に、すべてのアクティブなトランザクションがコミットされた後、UNDO表領域は自動的にPENDING OFFLINEモードからOFFLINEモードに移行します。それ以降は、他のインスタンスが(Oracle Real Application Clusters環境で)そのUNDO表領域を使用できます。

UNDO TABLESPACEのパラメータ値を「''」(2つの一重引用符)に設定した場合は、現行のUNDO表領域が次の使用可能なUNDO表領域に切り替えられます。使用可能なUNDO表領域がない場合もあるため、この文の使用には注意が必要です。

次の例では、現行のUNDO表領域の割当てを解除しています。

ALTER SYSTEM SET UNDO_TABLESPACE = '';

UNDO領域に対するユーザー割当ての確立

Oracle Database Resource Managerを使用すると、UNDO領域に対するユーザー割当てを確立できます。DBAは、データベース・リソース・マネージャのディレクティブUNDO_POOLを使用して、ユーザーのグループ(リソース・コンシューマ・グループ)が消費するUNDO表領域の量を制限できます。

UNDOプールは、コンシューマ・グループごとに指定できます。UNDOプールによって、コンシューマ・グループが生成できるUNDOの合計量が制御されます。コンシューマ・グループが生成するUNDOの合計量がそのUNDO制限を超えると、UNDOを生成している現行のUPDATEトランザクションが終了します。コンシューマ・グループの他のメンバーは、UNDO領域がプールから解放されるまで、新たに更新を実行できなくなります。

UNDO_POOLディレクティブが明示的に定義されていないときは、ユーザーは無制限にUNDO領域を使用できます。

関連項目:
第27章「Oracle Database Resource Managerを使用したリソースの管理」

UNDO表領域に対する領域のアラートしきい値の管理

Oracle Databaseでは、表領域に使用可能な領域が少なくなると事前にアラートが生成されるため、表領域のディスク領域の使用状況を管理するために役立ちます。UNDO表領域のアラートしきい値の設定方法は、「表領域のアラートの管理」を参照してください。

Oracle Databaseでは、UNDO領域の事前アラート以外に、「スナップショットが古すぎます」エラーが発生するような長時間実行される問合せがシステムにある場合にもアラートが生成されます。過剰にアラートが生成されるのを防ぐため、長時間実行される問合せのアラートは24時間以上の間隔をおいて発行されます。アラートが生成された場合は、Enterprise Managerの「UNDOアドバイザ」ページをチェックしてUNDO表領域に関する詳細情報を参照できます。

自動UNDO管理への移行

現在、ロールバック・セグメントを使用してUNDO領域を管理している場合は、データベースを自動UNDO管理に移行することをお薦めします。

手順については、『Oracle Databaseアップグレード・ガイド』を参照してください。

UNDO領域のデータ・ディクショナリ・ビュー

ここでは、自動UNDO管理モードにおいてUNDO領域に関する情報を表示する際に役立つビューについて説明し、いくつかの例を示します。ここで紹介したビュー以外にも、表領域やデータファイルの情報を表示するビューを使用して、情報を取得できます。これらのビューの詳細は、「データファイルのデータ・ディクショナリ・ビュー」を参照してください。

UNDO表領域に関する領域情報を取得するために、次の動的パフォーマンス・ビューが役立ちます。

ビュー

説明

V$UNDOSTAT

UNDO領域の監視とチューニングのための統計情報が含まれます。このビューは、現行の作業負荷に必要なUNDO領域の量を見積る際に利用できます。また、データベースはこの情報を使用して、システム内のUNDOの使用方法をチューニングします。このビューの情報は、自動UNDO管理モードでのみ意味があります。

V$ROLLSTAT

自動UNDO管理モードの場合、このビューの情報は、UNDO表領域内のUNDOセグメントの動作を反映します。

V$TRANSACTION

UNDOセグメント情報が含まれます。

DBA_UNDO_EXTENTS

UNDO表領域内の各エクステントの状態およびサイズを示します。

DBA_HIST_UNDOSTAT

V$UNDOSTAT情報の統計スナップショットが含まれます。詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

関連項目:
自動UNDO管理モードで使用するビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

V$UNDOSTATビューは、現行インスタンス内のUNDO領域におけるトランザクションの実行の効果を監視する際に役立ちます。UNDO領域の消費、トランザクションの同時実行性、UNDO保存期間のチューニング、インスタンス内の長時間実行される問合せの長さおよびSQL IDに関する統計が使用できます。

ビュー内の各行には、インスタンス内で10分ごとに収集された統計が表示されます。各行は、BEGIN_TIME列の値の降順で表示されます。各行は(BEGIN_TIME、END_TIME)でマークされた時間間隔に属します。各列は、その時間間隔中に特定の統計に関して収集されたデータを表します。ビューの最初の行は、現行の(部分的な)時間間隔に関する統計を示します。このビューには、4日サイクルによる合計576行が含まれます。

次の例は、V$UNDOSTATビューに対する問合せの結果を示したものです。

SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME,
TO_CHAR(END_TIME, 'MM/DD/YYYY HH24:MI:SS') END_TIME,
UNDOTSN, UNDOBLKS, TXNCOUNT, MAXCONCURRENCY AS "MAXCON"
FROM v$UNDOSTAT WHERE rownum <= 144;

BEGIN_TIME          END_TIME               UNDOTSN   UNDOBLKS   TXNCOUNT     MAXCON
------------------- ------------------- ---------- ---------- ---------- ----------
10/28/2004 14:25:12 10/28/2004 14:32:17          8         74   12071108          3
10/28/2004 14:15:12 10/28/2004 14:25:12          8         49   12070698          2
10/28/2004 14:05:12 10/28/2004 14:15:12          8        125   12070220          1
10/28/2004 13:55:12 10/28/2004 14:05:12          8         99   12066511          3
...
10/27/2004 14:45:12 10/27/2004 14:55:12          8         15   11831676          1
10/27/2004 14:35:12 10/27/2004 14:45:12          8        154   11831165          2

144 rows selected.

この例は、10/27/2004の14:35:12から24時間前までの間に、システムでUNDO領域がどのように消費されたのかを示しています。

17 Oracle Managed Filesの使用

この章の内容は、次のとおりです。

- Oracle Managed Filesの概要

- Oracle Managed Filesの作成および使用の有効化

- Oracle Managed Filesの作成

- Oracle Managed Filesの操作

- Oracle Managed Filesの使用例

Oracle Managed Filesの概要

Oracle Managed Filesを使用すると、Oracle Databaseの管理が簡素化されます。Oracle Managed Filesによって、DBAは、Oracle Databaseが含まれているオペレーティング・システム・ファイルを直接管理せずに済みます。Oracle Managed Filesでは、データベース・オブジェクト・レベルでデータベースがファイルを自動的に作成、命名および管理するファイル・システム・ディレクトリを指定します。たとえば、指定する必要があるのは作成する表領域のみで、DATAFILE句を使用して表領域のデータファイルの名前およびパスを指定する必要はありません。この機能は、論理ボリューム・マネージャ(LVM)とともに使用すると効果的です。

データベースでは内部的に標準ファイル・システム・インタフェースを使用し、必要に応じて、次のデータベース構造のファイルを作成および削除します。

- 表領域

- REDOログ・ファイル

- 制御ファイル

- アーカイブ・ログ

- ブロック・チェンジ・トラッキング・ファイル

- フラッシュバック・ログ

- RMANバックアップ

初期化パラメータによって、特定のタイプのファイルに使用するファイル・システム・ディレクトリを指定します。これにより、一意のOracle Managed Filesが作成され、不要になると削除されます。

この機能は、トレース・ファイル、監査ファイル、アラート・ログおよびコア・ファイルなどの管理ファイルの作成および命名には影響を与えません。

関連項目:
Oracle Managed Filesの機能を拡充するOracle Databaseの統合ファイル・システムおよびボリューム・マネージャであるOracle Automatic Storage Management(Oracle ASM)の詳細は、Oracle Automatic Storage Management管理者ガイドを参照してください。Oracle Managed Filesによって、ファイルは自動的に作成および管理されますが、Oracle ASMでは、ストライプ化、ソフトウェアのミラー化、動的な記憶域の構成などの追加機能を利用でき、サード・パーティ製の論理ボリューム・マネージャを購入する必要がありません。

Oracle Managed Filesの使用対象

Oracle Managed Filesは、次のタイプのデータベースに適しています。

- 次のものによってサポートされるデータベース

- ストライプ化/RAIDおよび動的に拡張可能な論理ボリュームをサポートする論理ボリューム・マネージャ

- サイズが大きく拡張可能なファイルを提供するファイル・システム

- ローエンド・データベースまたはテスト・データベース

Oracle Managed Files機能の目的は、RAWディスクを使用したシステムの管理を容易にすることではありません。この機能は、ディスク領域割当てについて、オペレーティング・システム機能との統合を実現します。オペレーティング・システムはRAWディスクの割当てをサポートしていない(割当ては手動で行う)ので、この機能は利用できません。ただし、Oracle Managed Filesでは(RAWディスクではなく)オペレーティング・システムのファイル・システムを使用する必要があるため、ディスク上のファイルの配置方法を管理できず、一部のI/Oをチューニングできなくなります。

論理ボリューム・マネージャの概要

論理ボリューム・マネージャ(LVM)は、大部分のオペレーティング・システムに付属するソフトウェア・パッケージです。論理ディスク・マネージャ(LDM)と呼ばれることもあります。これを使用すると、複数の物理ディスクの断片を単一の連続するアドレス空間に結合し、ソフトウェアの上位レイヤーに対して1つのディスクとして表示できます。LVMを使用することで、基礎となるどの物理ディスクよりも、論理ボリュームに優れた容量、パフォーマンス、信頼性および可用性の特性を持たせることができます。これらの特性を実装するために、ミラーリング、ストライピング、連結およびRAID 5などの技術が使用されています。

LVMの中には、論理ボリュームを作成後、そのボリュームの使用中に特性を変更できるものがあります。ボリュームはサイズ変更やミラー化できるだけでなく、別の物理ディスクに再配置することもできます。

ファイル・システムの概要

ファイル・システムとは、連続するディスク・アドレス空間内に構築されたデータ構造です。ファイル・マネージャ(FM)は、ファイル・システムを操作するソフトウェア・パッケージですが、これがファイル・システムと呼ばれる場合もあります。オペレーティング・システムには必ずファイル・マネージャが組み込まれています。ファイル・マネージャの主要なタスクは、ファイル・システム内のファイルにディスク領域への割当てまたは割当て解除です。

ファイル・システムを使用すると、多数のファイルにディスク領域を割り当てることができます。各ファイルは、Oracle Databaseなどのアプリケーションに連続するアドレス空間を提供するために作成されます。実際には、ファイル・システムのディスク領域の中でファイルは連続していない場合があります。ファイルは、作成、読取り、書込み、サイズ変更および削除ができます。各ファイルには対応する名前があり、ファイルを参照する際に使用します。

ファイル・システムは通常、LVMが作成する論理ボリュームの最上部に構築されます。したがって、特定のファイル・システム内にあるファイルはすべて、基盤となる論理ボリュームから継承された同じパフォーマンス、信頼性および可用性の特性を持ちます。ファイル・システムは、その中のすべてのファイルによって共有される、単一の記憶域のプールです。ファイル・システムの領域がなくなると、そのファイル・システム内にあるファイルを増やすことはできません。1つのファイル・システムで使用可能な領域が、他のファイル・システムの領域に影響を及ぼすことはありません。ただし、LVMとFMの組合せによっては、ファイル・システムの領域を追加または削除できます。

オペレーティング・システムは、複数のファイル・システムをサポートできます。別々のファイルに異なる記憶特性を与える場合や、使用可能なディスク領域を分割して互いに影響を及ぼさないプールを作成する場合に、複数のファイル・システムが作成されます。

Oracle Managed Filesの使用上の利点

Oracle Managed Filesを使用すると、次のような利点があります。

- データベースの管理が容易になります。
ファイル名を考えて、特定の記憶域要件を定義する必要はありません。一貫性のある一連のルールに基づいて、すべての関連ファイルが命名されます。記憶域の特性と記憶域を割り当てるプールは、ファイル・システムによって定義されます。

- 管理者による誤ったファイルの指定が原因で破損することが少なくなります。
Oracle Managed Filesとファイル名はすべて一意です。一般的によくある間違いは、2つの異なるデータベースで同じファイルを使用することであり、これが長時間にわたるシステム・ダウンを引き起こし、コミット済トランザクションが失われる原因となります。1つのファイルを参照するために2つの異なる名前を使用することは、重大な破損の原因となるもう1つの間違いです。

- 不要なファイルの存在によるディスク領域の浪費が減少します。
Oracle Databaseでは、Oracle Managed Filesが不要になったとき、古いファイルが自動的に削除されます。大規模なシステムでは、特定のファイルがまだ必要かどうか誰も確信できないという理由だけで、大量のディスク領域が浪費されています。これは、ディスク上の不要ファイルの削除という管理タスクを容易にし、ファイルを誤って削除することも防止します。

- テスト・データベースおよび開発データベースを容易に作成できます。
ファイル構造と命名について検討する時間を最小限にとどめることができ、実行するファイル管理タスクも従来より少なくて済みます。これにより、テスト・データベースまたは開発データベースの実際の要件を満たす作業に集中できます。

- 移植可能なサード・パーティ製ツールの開発が容易になります。
Oracle Managed Filesでは、SQLスクリプト内でオペレーティング・システム固有のファイル名を指定する必要がありません。

Oracle Managed Filesと既存の機能

Oracle Managed Filesを使用しても、既存の機能が不要になるわけではありません。既存データベースは、常に従来どおり操作できます。古いファイルはそれまでの方法で管理し、その一方で新しいファイルは管理ファイルとして作成できます。したがって、データベースにはOracle Managed Filesとそれ以外のファイルがともに存在する状態になります。

Oracle Managed Filesの作成および使用の有効化

次の表に、Oracle Managed Filesの使用を有効化する初期化パラメータを示します。

初期化パラメータ

説明

DB_CREATE_FILE_DEST

作成操作でファイル仕様を指定しなかった場合に、データベースによってデータファイルまたは一時ファイルが作成されるデフォルトのファイル・システム・ディレクトリまたはOracle ASMディスク・グループの場所を定義します。DB_CREATE_ONLINE_LOG_DEST_nを指定していない場合は、REDOログ・ファイルおよび制御ファイルのデフォルトの場所としても使用されます。

DB_CREATE_ONLINE_LOG_DEST_n

作成操作でファイル仕様を指定しなかった場合に、REDOログ・ファイルおよび制御ファイルが作成されるデフォルトのファイル・システム・ディレクトリまたはOracle ASMディスク・グループの場所を定義します。nを変更することによってこの初期化パラメータを複数回使用でき、nはREDOログ・ファイルまたは制御ファイルの多重化コピーを指定します。多重化コピーは最大5つまで指定できます。

DB_RECOVERY_FILE_DEST

データベースによってRMANによるバックアップ(フォーマット・オプションが使用されていない場合)、アーカイブ・ログ(他のローカル・アーカイブ先が構成されていない場合)およびフラッシュバック・ログが作成されるデフォルトのファイル・システム・ディレクトリまたはOracle ASMディスク・グループである高速リカバリ領域の場所を定義します。DB_CREATE_ONLINE_LOG_DEST_nを指定していない場合は、REDOログ・ファイルおよび制御ファイルまたはその多重コピーのデフォルトの場所としても使用されます。

これらのパラメータによって指定するファイル・システム・ディレクトリはすでに存在している必要があり、データベースによって作成されません。また、ディレクトリには、データベースによるファイルの作成権限が必要です。

ファイル作成操作で場所を明示的に指定しなかった場合は、必ずデフォルトの場所が使用されます。ファイル名はデータベースが作成するため、作成されたファイルはOracle Managed Filesになります。

これら2つの初期化パラメータはどちらも動的であり、ALTER SYSTEMまたはALTER SESSION文を使用して設定できます。

関連項目:

- 初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- 「Oracle Managed Filesの命名方法」

DB_CREATE_FILE_DEST初期化パラメータの設定

初期化パラメータ・ファイルにDB_CREATE_FILE_DEST初期化パラメータを設定して、データベースが次のファイルを作成するデフォルトの場所を識別できるようにします。

- データファイル

- 一時ファイル

- REDOログ・ファイル

- 制御ファイル

- ブロック・チェンジ・トラッキング・ファイル

ファイル・システム・ディレクトリの名前を指定して、これらに対するオペレーティング・システム・ファイルを作成するためのデフォルトの場所にします。次の例では、Oracle Managed Filesを作成する際に使用するデフォルトのディレクトリとして、/u01/app/oracle/oradataを設定しています。

DB_CREATE_FILE_DEST = '/u01/app/oracle/oradata'

DB_RECOVERY_FILE_DESTパラメータの設定

初期化パラメータ・ファイルにDB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZEパラメータを設定して、高速リカバリ領域のデフォルトの場所を識別できるようにします。高速リカバリ領域には、次が格納されます。

- REDOログ・ファイルまたはその多重コピー

- 制御ファイルまたはその多重コピー

- RMANバックアップ(データファイルのコピー、制御ファイルのコピー、バックアップ・ピース、制御ファイルの自動バックアップ)

- アーカイブ・ログ

- フラッシュバック・ログ

ファイル・システム・ディレクトリの名前を指定して、これらに対するオペレーティング・システム・ファイルを作成するためのデフォルトの場所にします。次に例を示します。

DB_RECOVERY_FILE_DEST = '/u01/app/oracle/fast_recovery_area'
DB_RECOVERY_FILE_DEST_SIZE = 20G

DB_CREATE_ONLINE_LOG_DEST_n初期化パラメータの設定

初期化パラメータ・ファイルにDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータを設定して、データベースが次のファイルを作成するデフォルトの場所を識別できるようにします。

- REDOログ・ファイル

- 制御ファイル

ファイル・システム・ディレクトリまたはOracle ASMディスク・グループの名前を指定して、これらに対するファイルを作成するためのデフォルトの場所にします。多重コピーを配置する場所は最大5つまで指定できます。

REDOログ・ファイルおよび制御ファイルの作成時のみ、このパラメータはDB_CREATE_FILE_DESTおよびDB_RECOVERY_FILE_DEST初期化パラメータで指定されたデフォルトの場所よりも優先されます。DB_CREATE_FILE_DESTパラメータを指定せず、DB_CREATE_ONLINE_LOG_DEST_nパラメータのみを指定している場合は、REDOログ・ファイルと制御ファイルのみがOracle Managed Filesとして作成されます。

少なくとも2つのパラメータを指定することをお薦めします。次に例を示します。

DB_CREATE_ONLINE_LOG_DEST_1 = '/u02/oradata'
DB_CREATE_ONLINE_LOG_DEST_2 = '/u03/oradata'

これによって、ファイルを多重化できるため、REDOログ・ファイルまたは制御ファイルの保存先のどちらかで障害が発生した場合のフォルト・トレランスが向上します。

Oracle Managed Filesの作成

次の条件のいずれかを満たしている場合で、作成操作でファイル仕様を指定しなかったときに、必要に応じてOracle DatabaseによってOracle Managed Filesが作成されます。

- 初期化パラメータ・ファイルに、DB_CREATE_FILE_DEST、DB_RECOVERY_FILE_DESTまたはDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータのいずれかを指定している場合

- DB_RECOVERY_FILE_DEST、DB_CREATE_FILE_DESTまたはDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータのいずれかを動的に設定するために、ALTER SYSTEM文を発行した場合

- DB_CREATE_FILE_DEST、DB_RECOVERY_FILE_DESTまたはDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータのいずれかを動的に設定するために、ALTER SESSION文を発行した場合

Oracle Managed Filesを作成する文がエラーを検出した場合、またはなんらかの障害のために完了しなかった場合は、その文によって作成されたOracle Managed Filesはすべて、エラーまたは障害のリカバリの一部として自動的に削除されます。ただし、ファイル・システムやストレージ・サブシステムで発生する多数の潜在的なエラーが原因で、オペレーティング・システムのコマンドを使用した手動でのファイル削除が必要になる場合があります。

内容は次のとおりです。

- Oracle Managed Filesの命名方法

- データベース作成時のOracle Managed Filesの作成

- Oracle Managed Filesを使用した表領域用データファイルの作成

- Oracle Managed Filesを使用した一時表領域用一時ファイルの作成

- Oracle Managed Filesを使用した制御ファイルの作成

- Oracle Managed Filesを使用したREDOログ・ファイルの作成

- Oracle Managed Filesを使用したアーカイブ・ログの作成

Oracle Managed Filesの命名方法

注意:
この項で説明する命名方法は、オペレーティング・システムのファイル・システムに作成されるファイルにのみ適用されます。Oracle Automatic Storage Management(Oracle ASM)ディスク・グループで作成されたファイルの命名方式の詳細は、Oracle Automatic Storage Management管理者ガイドを参照してください。

Oracle Managed Filesのファイル名は、ファイル命名に関するOptimal Flexible Architecture(OFA)標準に準拠しています。割り当てられた名前は、次の要件を満たしています。

- データベース・ファイルが他のすべてのファイルと容易に区別できます。

- 1つのデータベース・タイプのファイルが、他のデータベース・タイプのファイルと容易に区別できます。

- ファイルはファイル・タイプ固有の重要な属性に明確に関連付けられます。たとえば、データファイルの表領域への関連付けを容易にするためにデータファイル名に表領域名を含めたり、アーカイブ・ログ名にスレッド、順序および作成日を含めることが可能です。

同じ名前を持つOracle Managed Filesは1つもありません。Oracle Managed Filesの作成に使用される名前は、次の3つのソースから構成されます。

- デフォルトの作成場所。

- ファイルのタイプに基づいて選択されたファイル名テンプレート。テンプレートは、オペレーティング・システムのプラットフォームや、Oracle Automatic Storage Managementを使用しているかどうかによって異なります。

- Oracle Databaseまたはオペレーティング・システムによって作成された一意の文字列。これにより、ファイル作成によって既存のファイルが破損しないこと、および誤って他のファイルが選択されないことが保証されます。

特定の例として、Solarisファイル・システムにおけるOracle Managed Filesのファイル名の書式を次に示します。

destination_prefix/o1_mf_%t_%u_.dbf

説明:

- destination_prefixはdestination_location/db_unique_name/datafileです。
説明:

- destination_locationは、DB_CREATE_FILE_DESTに指定した場所です。

- db_unique_nameは、ターゲット・データベースのグローバルな一意の名前(DB_UNIQUE_NAME初期化パラメータ)です。DB_UNIQUE_NAMEパラメータがない場合は、DB_NAME初期化パラメータ値が使用されます。

- %tは表領域の名前を表します。

- %uは一意性を保証する8文字の文字列を表します。

たとえば、次のようなパラメータ設定を考えてみます。

DB_CREATE_FILE_DEST   = /u01/app/oracle/oradata
DB_UNIQUE_NAME = PAYROLL

この例のデータファイル名は次のようになります。

/u01/app/oracle/oradata/PAYROLL/datafile/o1_mf_tbs1_2ixh90q_.dbf

他のファイル・タイプの名前もほぼ同じです。他のプラットフォームでもファイル名はほぼ同じですが、各プラットフォームのネーミング規則の制約を受けます。

後続の例では、Solarisファイル・システムでOMFアーカイブ先として表示されるOracle Managed Filesの名前を使用します。

注意:
Oracle Managed Filesの名前は変更しないでください。Oracle Managed Filesは名前に基づいて識別されます。ファイル名を変更すると、データベースではOracle Managed Filesとして認識できなくなり、ファイルは適切に管理されません。

データベース作成時のOracle Managed Filesの作成

ここでは、Oracle Managed Files使用時のCREATE DATABASE文の処理について説明します。

注意:
この項で説明するルールとデフォルトは、Database Configuration Assistant(DBCA)によるデータベースの作成にも適用されます。DBCAでは、グラフィカル・インタフェースを使用してOracle Managed Filesを有効化し、この項で説明する初期化パラメータに対応するファイルの場所を指定できます。

関連項目:
CREATE DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

データベース作成時の制御ファイルの指定

データベース作成時には、CONTROL_FILES初期化パラメータによって指定されたファイルで、制御ファイルが作成されます。CONTROL_FILESパラメータが設定されておらず、Oracle Managed Filesの作成に必要な初期化パラメータが少なくとも1つ設定されている場合は、制御ファイルのデフォルトの保存先にOracle Managed Filesの制御ファイルが作成されます。デフォルトの保存先は、次の優先度に従って定義されます。

- DB_CREATE_ONLINE_LOG_DEST_n初期化パラメータで指定されている1つ以上の制御ファイル。最初のディレクトリに作成されたファイルが主制御ファイルになります。DB_CREATE_ONLINE_LOG_DEST_nが指定されている場合は、DB_CREATE_FILE_DESTまたはDB_RECOVERY_FILE_DEST(高速リカバリ領域)に制御ファイルは作成されません。

- DB_CREATE_ONLINE_LOG_DEST_nに値が指定されていない場合で、DB_CREATE_FILE_DESTおよびDB_RECOVERY_FILE_DESTの両方に値が設定されている場合は、それぞれの場所に1つの制御ファイルが作成されます。DB_CREATE_FILE_DESTに指定された場所が主制御ファイルの場所になります。

- DB_CREATE_FILE_DESTに対してのみ値が指定されている場合は、その場所に1つの制御ファイルが作成されます。

- DB_RECOVERY_FILE_DESTに対してのみ値が指定されている場合は、その場所に1つの制御ファイルが作成されます。

CONTROL_FILESパラメータが設定されておらず、これらの初期化パラメータがいずれも設定されていない場合は、Oracle Databaseのデフォルトのアクションはオペレーティング・システムによって異なります。最低1つの制御ファイルのコピーが、デフォルトの場所(オペレーティング・システムによって異なる)に作成されます。このようにして作成された制御ファイルのコピーはOracle Managed Filesではなく、初期化パラメータ・ファイルにCONTROL_FILES初期化パラメータを追加する必要があります。

Oracle Managed Filesの制御ファイルが作成された場合で、サーバー・パラメータ・ファイルが存在するときは、サーバー・パラメータ・ファイルにCONTROL_FILES初期化パラメータのエントリが追加されます。サーバー・パラメータ・ファイルが存在しない場合は、CONTROL_FILES初期化パラメータのエントリをテキスト形式の初期化パラメータ・ファイルに手動で追加する必要があります。

関連項目:
第11章「制御ファイルの管理」

データベース作成時のREDOログ・ファイルの指定

CREATE DATABASE文でLOGFILE句は必須でなく、単純にこれを省略するとOracle Managed FilesのREDOログ・ファイルが作成されます。LOGFILE句を省略すると、デフォルトのREDOログ・ファイルの保存先にREDOログ・ファイルが作成されます。デフォルトの保存先は、次の優先度に従って定義されます。

- DB_CREATE_ONLINE_LOG_DEST_nが設定されている場合は、指定された各ディレクトリにログ・ファイルのメンバーが作成されます。最大数はMAXLOGMEMBERS初期化パラメータの値です。

- DB_CREATE_ONLINE_LOG_DEST_nパラメータが設定されていない場合で、DB_CREATE_FILE_DESTおよびDB_RECOVERY_FILE_DEST初期化パラメータの両方が設定されているときは、それぞれの場所に1つのOracle Managed Filesのログ・ファイルのメンバーが作成されます。DB_CREATE_FILE_DESTアーカイブ先のログ・ファイルが最初のメンバーです。

- DB_CREATE_FILE_DEST初期化パラメータのみが指定されている場合は、その場所にログ・ファイルのメンバーが作成されます。

- DB_RECOVERY_FILE_DEST初期化パラメータのみが指定されている場合は、その場所にログ・ファイルのメンバーが作成されます。

Oracle Managed FilesのREDOログ・ファイルのデフォルト・サイズは100MBです。

オプションで、Oracle Managed FilesのREDOログ・ファイルを作成し、LOGFILE句を含めながらファイル名を省略することにより、デフォルト属性を上書きできます。REDOログ・ファイルも同様に作成されますが、異なる点は、CREATE DATABASEのLOGFILE句にファイル名が入力されておらず、Oracle Managed Filesの作成に必要な初期化パラメータが1つも提供されていない場合、CREATE DATABASE文が失敗することです。

関連項目:
第12章「REDOログの管理」

データベース作成時のSYSTEM表領域およびSYSAUX表領域用データファイルの指定

CREATE DATABASE文でDATAFILE句またはSYSAUX DATAFILE句は必須でなく、単純にこれを省略するとSYSTEM表領域およびSYSAUX表領域用のOracle Managed Filesのデータファイルが作成されます。DATAFILE句を省略すると、次の処理のいずれかが実行されます。

- DB_CREATE_FILE_DESTが設定されている場合は、SYSTEM表領域用およびSYSAUX表領域用のOracle Managed FilesのデータファイルがDB_CREATE_FILE_DESTディレクトリに1つずつ作成されます。

- DB_CREATE_FILE_DESTが設定されていない場合は、オペレーティング・システム固有の名前とサイズで、SYSTEM表領域のデータファイルおよびSYSAUX表領域のデータファイルが1つずつ作成されます。この方法で作成されたSYSTEM表領域のデータファイルまたはSYSAUX表領域のデータファイルはOracle Managed Filesではありません。

デフォルトでは、SYSTEMおよびSYSAUX表領域用を含めてOracle Managed Filesのデータファイルは100MBで、自動拡張可能です。自動拡張が必要な場合、データファイルは既存サイズまたは100MB単位(いずれか小さい方)で拡張されます。データファイルの指定時(CREATE操作またはALTER TABLESPACE操作時)に、STORAGE句のNEXTパラメータを使用して、自動拡張可能単位を明示的に指定することもできます。

必要に応じて、SYSTEM表領域用またはSYSAUX表領域用のOracle Managed Filesのデータファイルを作成し、デフォルトの属性を上書きできます。そのためには、ファイル名を省略し、上書きする属性を指定して、DATAFILE句を指定します。ファイル名を指定せずに、DB_CREATE_FILE_DESTパラメータを設定すると、SYSTEM表領域用またはSYSAUX表領域用のOracle Managed FilesのデータファイルがDB_CREATE_FILE_DESTディレクトリに作成され、指定した属性が上書きされます。ただし、ファイル名を指定せず、DB_CREATE_FILE_DESTパラメータを設定しないと、CREATE DATABASE文が失敗します。

Oracle Managed Filesのデフォルト属性を上書きする際、SIZE値が指定されており、AUTOEXTEND句が指定されていない場合、データファイルは自動拡張可能ではありません。

データベース作成時のUNDO表領域データファイルの指定

UNDO TABLESPACE句のDATAFILE副次句は必須でなく、ファイル仕様に必ずしもファイル名を指定する必要はありません。ファイル名を指定せず、DB_CREATE_FILE_DESTが設定されている場合は、Oracle Managed FilesのデータファイルがDB_CREATE_FILE_DESTディレクトリに作成されます。DB_CREATE_FILE_DESTが設定されていない場合は、構文エラーで文が失敗します。

UNDO TABLESPACE句自体は、CREATE DATABASE文のオプションです。この句を指定せず、自動UNDO管理モードが使用可能な場合(デフォルト)は、次のルールに従って、SYS_UNDOTSという名前のデフォルトのUNDO表領域が作成され、自動拡張可能な20MBのデータファイルが割り当てられます。

- DB_CREATE_FILE_DESTが設定されている場合は、指定されたディレクトリにOracle Managed Filesのデータファイルが作成されます。

- DB_CREATE_FILE_DESTが設定されていない場合は、オペレーティング・システム固有のデフォルトの場所にデータファイルが作成されます。

関連項目:
第16章「UNDOの管理」

データベース作成時のデフォルト一時表領域用一時ファイルの指定

DEFAULT TEMPORARY TABLESPACE句のTEMPFILE副次句は必須でなく、ファイル仕様に必ずしもファイル名を指定する必要はありません。ファイル名を指定せず、DB_CREATE_FILE_DESTパラメータが設定されている場合は、Oracle Managed Filesの一時ファイルがDB_CREATE_FILE_DESTディレクトリに作成されます。DB_CREATE_FILE_DESTが設定されていない場合は、構文エラーでCREATE DATABASE文が失敗します。

DEFAULT TEMPORARY TABLESPACE句自体はオプションです。この句を指定していない場合、デフォルト一時表領域は作成されません。

Oracle Managed Filesの一時ファイルのデフォルト・サイズは100MBです。このファイルは自動的に拡張可能で、最大サイズに制限はありません。

Oracle Managed Filesを使用したCREATE DATABASE文の例

ここでは、Oracle Managed Files機能を使用したCREATE DATABASE文の例を示します。

CREATE DATABASE: 例1 この例では、次のOracle Managed Filesを含むデータベースが作成されます。

- ディレクトリ/u01/app/oracle/oradataのSYSTEM表領域用データファイル。サイズは無制限に自動拡張可能です。

- ディレクトリ/u01/app/oracle/oradataのSYSAUX表領域用データファイル。サイズは無制限に自動拡張可能です。表領域は、自動セグメント領域管理によってローカルに管理されます。

- それぞれ100MBのメンバーを2つ含む2つのオンライン・ログ・グループ。/u02/oradataと/u03/oradataに1つずつ作成されます。

- 自動UNDO管理モードが使用可能の場合(デフォルト)は、ディレクトリ/u01/app/oracle/oradataのUNDO表領域用データファイル。サイズは20MBで、無制限に自動拡張可能です。SYS_UNDOTSという名前のUNDO表領域が作成されます。

- CONTROL_FILES初期化パラメータが指定されていない場合は、2つの制御ファイルが/u02/oradataと/u03/oradataに1つずつ作成されます。/u02/oradataの制御ファイルが主制御ファイルになります。

Oracle Managed Filesに関連する初期化パラメータ・ファイルで、次のパラメータを設定します。

DB_CREATE_FILE_DEST = '/u01/app/oracle/oradata'
DB_CREATE_ONLINE_LOG_DEST_1 = '/u02/oradata'
DB_CREATE_ONLINE_LOG_DEST_2 = '/u03/oradata'

SQLプロンプトから次の文を発行します。

CREATE DATABASE sample;

ローカル管理されるSYSTEM表領域を持つデータベースを作成するには、EXTENT MANAGEMENT LOCAL句を追加します。

CREATE DATABASE sample EXTENT MANAGEMENT LOCAL;

この句を使用しない場合は、SYSTEM表領域はディクショナリ管理されます。ローカル管理のSYSTEM表領域を作成することをお薦めします。

CREATE DATABASE: 例2 この例では、次のOracle Managed Filesを含むデータベースが作成されます。

- ディレクトリ/u01/app/oracle/oradataのSYSTEM表領域用データファイル。サイズは無制限に自動拡張可能です。

- ディレクトリ/u01/app/oracle/oradataのSYSAUX表領域用データファイル。サイズは無制限に自動拡張可能です。表領域は、自動セグメント領域管理によってローカルに管理されます。

- ディレクトリ/u01/app/oracle/oradataの2つのREDOログ・ファイル(各100MB)。これらは多重化されていません。

- ディレクトリ/u01/app/oracle/oradataのUNDO表領域用データファイル。サイズは20MBで、無制限に自動拡張可能です。SYS_UNDOTSという名前のUNDO表領域が作成されます。

- /u01/app/oracle/oradataの1つの制御ファイル。

この例では、次のように想定されています。

- 初期化パラメータ・ファイルにDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータは1つも指定されていません。

- 初期化パラメータ・ファイルにCONTROL_FILES初期化パラメータは指定されていません。

- 自動UNDO管理モードは使用可能になっています。

SQLプロンプトから次の文を発行します。

ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/u01/app/oracle/oradata';
CREATE DATABASE sample2 EXTENT MANAGEMENT LOCAL;

このデータベース構成は、本番データベースにはお薦めしません。この例は、非常にローエンドのデータベースか、単純なテスト・データベースを簡単に作成する方法を示しています。このデータベースの耐障害性を高めるには、制御ファイルを少なくとももう1つ作成し、REDOログを多重化する必要があります。

CREATE DATABASE: 例3 この例では、デフォルト一時表領域およびUNDO表領域用のOracle Managed Filesのファイル・サイズを指定しています。次のOracle Managed Filesを持つデータベースが作成されます。

- ディレクトリ/u01/app/oracle/oradataのSYSTEM表領域用データファイル(400MB)。SIZEが指定されているため、このファイルは自動拡張可能ではありません。

- ディレクトリ/u01/app/oracle/oradataのSYSAUX表領域用データファイル(200MB)。SIZEが指定されているため、このファイルは自動拡張可能ではありません。表領域は、自動セグメント領域管理によってローカルに管理されます。

- それぞれ100MBのメンバーを2つ含む2つのREDOログ・グループ。ディレクトリ/u02/oradataと/u03/oradataに1つずつ作成されます。

- デフォルト一時表領域dflt_tsに対して、ディレクトリ/u01/app/oracle/oradataの一時ファイル(10MB)。SIZEが指定されているため、このファイルは自動拡張可能ではありません。

- UNDO表領域undo_tsに対して、ディレクトリ/u01/app/oracle/oradataのデータファイル(100MB)。SIZEが指定されているため、このファイルは自動拡張可能ではありません。

- CONTROL_FILES初期化パラメータが指定されていない場合は、2つの制御ファイルがディレクトリ/u02/oradataと/u03/oradataに1つずつ作成されます。/u02/oradataの制御ファイルが主制御ファイルになります。

初期化パラメータ・ファイルで、次のパラメータを設定します。

DB_CREATE_FILE_DEST = '/u01/app/oracle/oradata'
DB_CREATE_ONLINE_LOG_DEST_1 = '/u02/oradata'
DB_CREATE_ONLINE_LOG_DEST_2 = '/u03/oradata'

SQLプロンプトから次の文を発行します。

CREATE DATABASE sample3
EXTENT MANAGEMENT LOCAL
DATAFILE SIZE 400M
SYSAUX DATAFILE SIZE 200M
DEFAULT TEMPORARY TABLESPACE dflt_ts TEMPFILE SIZE 10M
UNDO TABLESPACE undo_ts DATAFILE SIZE 100M;

関連項目:
「ローカル管理のSYSTEM表領域の作成」

Oracle Managed Filesを使用した表領域用データファイルの作成

ここでは、データファイルを作成する次の文について説明します。

- CREATE TABLESPACE

- CREATE UNDO TABLESPACE

- ALTER TABLESPACE ... ADD DATAFILE

表領域を作成するときは、永続表領域とUNDO表領域のいずれの場合も、DATAFILE句はオプションです。DATAFILE句を指定する場合、ファイル名はオプションです。DATAFILE句またはファイル名を省略すると、次のルールが適用されます。

- DB_CREATE_FILE_DEST初期化パラメータが設定されている場合は、パラメータで指定された場所にOracle Managed Filesのデータファイルが作成されます。

- DB_CREATE_FILE_DEST初期化パラメータが設定されていない場合は、データファイルを作成する文が失敗します。

ALTER TABLESPACE...ADD DATAFILE文で表領域にデータファイルを追加する場合、ファイル名はオプションです。ファイル名を省略すると、前の段落で説明したのと同じルールが適用されます。

デフォルトでは、永続表領域用のOracle Managed Filesのデータファイルのサイズは100MBです。このファイルは自動的に拡張可能で、最大サイズに制限はありません。ただし、DATAFILE句でSIZE値を指定する(AUTOEXTEND句は指定しない)ことによって、これらのデフォルトを上書きした場合、データファイルは自動拡張可能ではありません。

関連項目:

- 「データベース作成時のSYSTEM表領域およびSYSAUX表領域用データファイルの指定」

- 「データベース作成時のUNDO表領域データファイルの指定」

- 第14章「表領域の管理」

CREATE TABLESPACE: 例

ここでは、Oracle Managed Filesを持つ表領域の作成例をいくつか示します。

関連項目:
CREATE TABLESPACE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

CREATE TABLESPACE: 例1 次の例では、データファイルを作成するデフォルトの場所を/u01/oradataに設定してから、その場所のデータファイルを含む表領域tbs_1を作成します。データファイルは100MBで、無制限に自動拡張可能です。

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/u01/oradata';
SQL> CREATE TABLESPACE tbs_1;

CREATE TABLESPACE: 例2 この例では、ディレクトリ/u01/oradata上のデータファイルを含む表領域tbs_2を作成しています。データファイルの初期サイズは400 MBで、SIZE句が指定されているため自動拡張可能ではありません。

初期化パラメータ・ファイルで、次のパラメータを設定します。

DB_CREATE_FILE_DEST = '/u01/oradata'

SQLプロンプトから次の文を発行します。

SQL> CREATE TABLESPACE tbs_2 DATAFILE SIZE 400M;

CREATE TABLESPACE: 例3 この例では、ディレクトリ/u01/oradata上のデータファイルを含む表領域tbs_3を作成しています。作成されるデータファイルは初期サイズが100MB、最大サイズが800MBで自動拡張可能です。

初期化パラメータ・ファイルで、次のパラメータを設定します。

DB_CREATE_FILE_DEST = '/u01/oradata'

SQLプロンプトから次の文を発行します。

SQL> CREATE TABLESPACE tbs_3 DATAFILE AUTOEXTEND ON MAXSIZE 800M;

CREATE TABLESPACE: 例4 次の例では、データファイルを作成するデフォルトの場所を/u01/oradataに設定してから、そのディレクトリ上の2つのデータファイルを含む表領域tbs_4を作成しています。どちらのデータファイルも初期サイズは200MBで、SIZE値が指定されているため自動拡張可能ではありません。

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/u01/oradata';
SQL> CREATE TABLESPACE tbs_4 DATAFILE SIZE 200M, SIZE 200M;

CREATE UNDO TABLESPACE: 例

次の例では、ディレクトリ/u01/oradata上のデータファイルを含むUNDO表領域undotbs_1を作成しています。UNDO表領域用のデータファイルは100MBで、無制限に自動拡張可能です。

初期化パラメータ・ファイルで、次のパラメータを設定します。

DB_CREATE_FILE_DEST = '/u01/oradata'

SQLプロンプトから次の文を発行します。

SQL> CREATE UNDO TABLESPACE undotbs_1;

関連項目:
CREATE UNDO TABLESPACE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ALTER TABLESPACE: 例

この例では、自動拡張可能なOracle Managed Filesのデータファイルをtbs_1表領域に追加しています。データファイルは初期サイズが100MBで、最大サイズが800MBです。

初期化パラメータ・ファイルで、次のパラメータを設定します。

DB_CREATE_FILE_DEST = '/u01/oradata'

SQLプロンプトから次の文を入力します。

SQL> ALTER TABLESPACE tbs_1 ADD DATAFILE AUTOEXTEND ON MAXSIZE 800M;

関連項目:
ALTER TABLESPACE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

Oracle Managed Filesを使用した一時表領域用一時ファイルの作成

ここでは、一時ファイルを作成する次の文について説明します。

- CREATE TEMPORARY TABLESPACE

- ALTER TABLESPACE ... ADD TEMPFILE

一時表領域を作成する場合、TEMPFILE句はオプションです。TEMPFILE句を指定する場合、ファイル名はオプションです。TEMPFILE句またはファイル名を省略すると、次のルールが適用されます。

- DB_CREATE_FILE_DEST初期化パラメータが設定されている場合は、パラメータで指定された場所にOracle Managed Filesの一時ファイルが作成されます。

- DB_CREATE_FILE_DEST初期化パラメータが設定されていない場合は、一時ファイルを作成する文が失敗します。

ALTER TABLESPACE...ADD TEMPFILE文で表領域に一時ファイルを追加する場合、ファイル名はオプションです。ファイル名を省略すると、前の段落で説明したのと同じルールが適用されます。

Oracle Managed Filesのデフォルト属性を上書きする際、SIZE値が指定されており、AUTOEXTEND句が指定されていない場合、データファイルは自動拡張可能ではありません。

関連項目:
「データベース作成時のデフォルト一時表領域用一時ファイルの指定」

CREATE TEMPORARY TABLESPACE: 例

次の例では、データファイルを作成するデフォルトの場所を/u01/oradataに設定してから、その場所の一時ファイルを含む表領域temptbs_1を作成します。一時ファイルは100MBで、無制限に自動拡張可能です。

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/u01/oradata';
SQL> CREATE TEMPORARY TABLESPACE temptbs_1;

関連項目:
CREATE TABLESPACE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ALTER TABLESPACE... ADD TEMPFILE: 例

次の例では、データファイルを作成するデフォルトの場所を/u03/oradataに設定してから、デフォルトの場所のtemptbs_1という表領域に一時ファイルを追加しています。一時ファイルの初期サイズは100MBです。これは無制限に自動拡張可能です。

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/u03/oradata';
SQL> ALTER TABLESPACE TBS_1 ADD TEMPFILE;

関連項目:
ALTER TABLESPACE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

Oracle Managed Filesを使用した制御ファイルの作成

CREATE CONTROLFILE文を発行すると、CONTROL_FILES初期化パラメータによって指定されたファイルで、制御ファイルが作成(REUSEを指定した場合は再利用)されます。CONTROL_FILESパラメータが設定されていない場合は、制御ファイルのデフォルトの保存先に制御ファイルが作成されます。デフォルトの保存先は、「データベース作成時の制御ファイルの指定」に記載されている優先度によって決まります。

Oracle DatabaseによってOracle Managed Filesの制御ファイルが作成された場合で、サーバー・パラメータ・ファイルが存在するときは、サーバー・パラメータ・ファイルにCONTROL_FILES初期化パラメータが作成されます。サーバー・パラメータ・ファイルが存在しない場合は、CONTROL_FILES初期化パラメータを手動で作成して、初期化パラメータ・ファイルに追加する必要があります。

データベースのデータファイルがOracle Managed Filesの場合は、文のDATAFILE句に、そのファイルのデータベース生成ファイル名を指定する必要があります。

REDOログ・ファイルがOracle Managed Filesの場合は、NORESETLOGSまたはRESETLOGSキーワードによって、LOGFILE句に指定できるパラメータが決まります。

- NORESETLOGSキーワードを使用する場合は、Oracle Managed FilesのREDOログ・ファイル用に生成されるファイル名をLOGFILE句に指定する必要があります。

- RESETLOGSキーワードを使用する場合は、REDOログ・ファイル名をCREATE DATABASE文の場合と同様に指定できます。「データベース作成時のREDOログ・ファイルの指定」を参照してください。

Oracle Managed Filesを使用したCREATE CONTROLFILE文の使用例については、次の項を参照してください。

関連項目:

- CREATE CONTROLFILE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 「データベース作成時の制御ファイルの指定」

NORESETLOGSキーワードを使用したCREATE CONTROLFILE: 例

次のCREATE CONTROLFILE文は、Oracle Managed FilesのデータファイルおよびREDOログ・ファイルを含むデータベースでALTER DATABASE BACKUP CONTROLFILE TO TRACE文を発行したときに生成されます。

CREATE CONTROLFILE
DATABASE sample
LOGFILE
GROUP 1 ('/u01/oradata/SAMPLE/onlinelog/o1_mf_1_o220rtt9_.log',
'/u02/oradata/SAMPLE/onlinelog/o1_mf_1_v2o0b2i3_.log')
SIZE 100M,
GROUP 2 ('/u01/oradata/SAMPLE/onlinelog/o1_mf_2_p22056iw_.log',
'/u02/oradata/SAMPLE/onlinelog/o1_mf_2_p02rcyg3_.log')
SIZE 100M
NORESETLOGS
DATAFILE '/u01/oradata/SAMPLE/datafile/o1_mf_system_xu34ybm2_.dbf'
SIZE 100M,
'/u01/oradata/SAMPLE/datafile/o1_mf_sysaux_aawbmz51_.dbf'
SIZE 100M,
'/u01/oradata/SAMPLE/datafile/o1_mf_sys_undo_apqbmz51_.dbf'
SIZE 100M
MAXLOGFILES 5
MAXLOGHISTORY 100
MAXDATAFILES 10
MAXINSTANCES 2
ARCHIVELOG;

RESETLOGSキーワードを使用したCREATE CONTROLFILE: 例

次の文は、RESETLOGSオプションを指定したCREATE CONTROLFILE文の例です。DB_CREATE_FILE_DEST、DB_RECOVERY_FILE_DESTおよびDB_CREATE_ONLINE_LOG_DEST_nを組み合せて設定する必要があります。

CREATE CONTROLFILE
DATABASE sample
RESETLOGS
DATAFILE '/u01/oradata/SAMPLE/datafile/o1_mf_system_aawbmz51_.dbf',
'/u01/oradata/SAMPLE/datafile/o1_mf_sysaux_axybmz51_.dbf',
'/u01/oradata/SAMPLE/datafile/o1_mf_sys_undo_azzbmz51_.dbf'
SIZE 100M
MAXLOGFILES 5
MAXLOGHISTORY 100
MAXDATAFILES 10
MAXINSTANCES 2
ARCHIVELOG;

後で、ALTER DATABASE OPEN RESETLOGS文を発行して、REDOログ・ファイルを再作成する必要があります。この操作については、「ALTER DATABASE OPEN RESETLOGS文の使用」を参照してください。使用していたログ・ファイルがOracle Managed Filesである場合、そのファイルは削除されません。

Oracle Managed Filesを使用したREDOログ・ファイルの作成

REDOログ・ファイルはデータベース作成時に作成されます。また、次の文のどちらかを発行したときにも作成できます。

- ALTER DATABASE ADD LOGFILE

- ALTER DATABASE OPEN RESETLOGS

関連項目:
ALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ALTER DATABASE ADD LOGFILE文の使用

ALTER DATABASE ADD LOGFILE文を使用すると、現行のREDOログ・ファイルに後から新しいグループを追加できます。Oracle Managed Filesを使用している場合、ADD LOGFILE句のファイル名はオプションです。ファイル名を省略した場合は、ログ・ファイルのデフォルトの保存先にREDOログ・ファイルが作成されます。デフォルトの保存先は、「データベース作成時のREDOログ・ファイルの指定」に記載されている優先度によって決まります。

ファイル名を指定せず、Oracle Managed Filesの作成に必要な初期化パラメータが1つも指定されていない場合は、文はエラーを戻します。

Oracle Managed Filesのログ・ファイルのデフォルト・サイズは100MBです。

完全ファイル名を指定すると、REDOログ・ファイルのメンバーを引き続き追加および削除できます。

関連項目:

- 「データベース作成時のREDOログ・ファイルの指定」

- 「Oracle Managed Filesを使用した制御ファイルの作成」

新しいREDOログ・ファイルの追加: 例 次の例では、一方のメンバーがディレクトリ/u01/oradata、もう一方のメンバーが/u02/oradataに存在するログ・グループを作成します。各ログ・ファイルのサイズは100MBです。

初期化パラメータ・ファイルで、次のパラメータを設定します。

DB_CREATE_ONLINE_LOG_DEST_1 = '/u01/oradata'
DB_CREATE_ONLINE_LOG_DEST_2 = '/u02/oradata'

SQLプロンプトから次の文を発行します。

SQL> ALTER DATABASE ADD LOGFILE;

ALTER DATABASE OPEN RESETLOGS文の使用

前にRESETLOGSを指定して制御ファイルを作成しており、その際、ファイル名を指定しなかった場合、または存在しないファイル名を指定した場合は、ALTER DATABASE OPEN RESETLOGS文を発行したときに、REDOログ・ファイルが作成されます。制御ファイル内に何も指定されていない場合に、REDOログ・ファイルの格納ディレクトリを決めるルールは、「データベース作成時のREDOログ・ファイルの指定」に記載されているルールと同じです。

Oracle Managed Filesを使用したアーカイブ・ログの作成

アーカイブ・ログは、次の場合にDB_RECOVERY_FILE_DESTの場所に作成されます。

- ARCバックグラウンド・プロセスまたはLGWRバックグラウンド・プロセスがオンラインREDOログをアーカイブする場合。または、

- ALTER SYSTEM ARCHIVE LOG CURRENT文が発行された場合。

たとえば、次のパラメータ設定が初期化パラメータ・ファイルに含まれているとします。

DB_RECOVERY_FILE_DEST_SIZE = 20G
DB_RECOVERY_FILE_DEST      = '/u01/oradata'
LOG_ARCHIVE_DEST_1         = 'LOCATION=USE_DB_RECOVERY_FILE_DEST'

Oracle Managed Filesの操作

Oracle Managed Filesのファイル名は、既存のファイルを識別するためにファイル名が使用される場合ならいつでもSQL文で使用可能です。これらのファイル名は、他のファイル名と同様に制御ファイルと、またバックアップおよびリカバリにRecovery Manager (RMAN)を使用している場合はRMANカタログに格納されます。これらは、データファイルおよび一時ファイルの監視に使用される通常の固定および動的パフォーマンス・ビューで参照可能です(V$DATAFILEまたはDBA_DATA_FILESなど)。

次に、データベース生成ファイル名を使用した文の例を示します。

SQL> ALTER DATABASE
2> RENAME FILE '/u01/oradata/mydb/datafile/o1_mf_tbs01_ziw3bopb_.dbf'
3> TO '/u01/oradata/mydb/tbs0101.dbf';

SQL> ALTER DATABASE
2> DROP LOGFILE '/u01/oradata/mydb/onlinelog/o1_mf_1_wo94n2xi_.log';

SQL> ALTER TABLE emp
2> ALLOCATE EXTENT
3> (DATAFILE '/u01/oradata/mydb/datafile/o1_mf_tbs1_2ixfh90q_.dbf');

Oracle Managed Filesのデータファイル、一時ファイルおよび制御ファイルは、Oracle Managed Files以外の対応するファイルと同様にバックアップおよびリストアを実行できます。データベース生成ファイル名を使用しても、エクスポート・ファイルなどの論理バックアップ・ファイルの使用には影響しません。これは特に、表領域のPoint-in-Timeリカバリ(TSPITR)およびトランスポータブル表領域のエクスポート・ファイルにとって重要です。

Oracle Managed Filesの動作がOracle Managed Files以外のファイルと異なる場合があります。それらについては次の項で説明します。

データファイルおよび一時ファイルの削除

データベース管理ではないファイルとは異なり、Oracle Managed Filesのデータファイルまたは一時ファイルを削除すると、制御ファイルからファイル名が削除されて、ファイル・システムからファイルが自動的に削除されます。Oracle Managed Filesを削除する文は、次のとおりです。

- DROP TABLESPACE

- ALTER DATABASE TEMPFILE ... DROP

これらの文を使用して、いつでもOracle Managed Filesあるいはそれ以外のファイルを削除することもできます。

- ALTER TABLESPACE ... DROP DATAFILE

- ALTER TABLESPACE ... DROP TEMPFILE

REDOログ・ファイルの削除

Oracle Managed FilesのREDOログ・ファイルを削除すると、そのOracle Managed Filesが削除されます。削除するグループまたはメンバーを指定します。次の文は、REDOログ・ファイルを削除します。

- ALTER DATABASE DROP LOGFILE

- ALTER DATABASE DROP LOGFILE MEMBER

ファイルの名前変更

ファイルの名前を変更するには、次の文が使用されます。

- ALTER DATABASE RENAME FILE

- ALTER TABLESPACE ... RENAME DATAFILE

これらの文は、実際にはオペレーティング・システム上のファイルの名前を変更しませんが、そのかわりに制御ファイル内の名前が変更されます。変更前のファイルがOracle Managed Filesで、そのファイルが存在している場合は削除されます。この文を発行するときは、オペレーティング・システムのファイル名の規則を使用して各ファイルを指定する必要があります。

スタンバイ・データベースの管理

スタンバイ・データベースのデータファイル、制御ファイルおよびREDOログ・ファイルは、データベースで管理できます。プライマリ・データベースでOracle Managed Filesが使用されているかどうかは関係ありません。

スタンバイ・データベースのリカバリでデータファイルを作成するREDOを検出したとき、そのデータファイルがOracle Managed Filesの場合は、リカバリ・プロセスによって、ローカル・ファイル・システムのデフォルトの場所に空のファイルが作成されます。これにより、管理者が操作することなく、新しいファイルのREDOが即時に適用されます。

スタンバイ・データベースのリカバリで表領域を削除するREDOを検出した場合は、ローカル・ファイル・システム内にあるOracle Managed Filesのデータファイルがすべて削除されます。プライマリ・データベースでINCLUDING DATAFILESオプションを発行したかどうかは関係ありません。

Oracle Managed Filesの使用例

ここでは、使用例を示して、Oracle Managed Filesの使用方法をさらに詳しく説明します。

使用例1: 多重REDOログを含むデータベースの作成および管理

この使用例では、DBAが、データファイルとREDOログ・ファイルが異なるディレクトリに存在するデータベースを作成します。REDOログ・ファイルと制御ファイルは多重化されています。データベースはUNDO表領域を使用し、デフォルト一時表領域を持っています。このデータベースの作成とメンテナンスに関するタスクは、次のとおりです。

1. 初期化パラメータの設定
DBAは、データベースを作成する前に、初期化パラメータ・ファイルに3つの汎用的なファイル作成デフォルトを設定します。自動UNDO管理モード(デフォルト)も使用可能にします。

DB_CREATE_FILE_DEST = '/u01/oradata'
DB_CREATE_ONLINE_LOG_DEST_1 = '/u02/oradata'
DB_CREATE_ONLINE_LOG_DEST_2 = '/u03/oradata'
UNDO_MANAGEMENT = AUTO

DB_CREATE_FILE_DESTパラメータは、データファイルおよび一時ファイルのデフォルトのファイル・システム・ディレクトリを設定します。

DB_CREATE_ONLINE_LOG_DEST_1およびDB_CREATE_ONLINE_LOG_DEST_2パラメータは、REDOログ・ファイルと制御ファイルを作成するためのデフォルトのファイル・システム・ディレクトリを設定します。REDOログ・ファイルと制御ファイルは、2つのディレクトリの間で多重化されます。

2. データベースの作成
初期化パラメータの設定が完了すると、次の文でデータベースを作成できます。

SQL> CREATE DATABASE sample
2>   DEFAULT TEMPORARY TABLESPACE dflttmp;

DATAFILE句が指定されておらず、DB_CREATE_FILE_DEST初期化パラメータが設定されているため、SYSTEM表領域のデータファイルはデフォルトのファイル・システム(この使用例では/u01/oradata)に作成されます。ファイル名は、データベースによって一意に生成されます。データファイルは初期サイズが100MBで、無制限に自動拡張可能です。このファイルはOracle Managed Filesです。SYSAUX表領域についても同様のデータファイルが作成されます。

LOGFILE句が指定されていないため、2つのREDOログ・グループが作成されます。各グループにはそれぞれ2つのメンバーがあり、一方のメンバーはDB_CREATE_ONLINE_LOG_DEST_1、もう一方のメンバーはDB_CREATE_ONLINE_LOG_DEST_2に作成されます。ファイル名は、データベースによって一意に生成されます。ログ・ファイルのサイズは100MBです。ログ・ファイルのメンバーはOracle Managed Filesです。

同様に、CONTROL_FILES初期化パラメータが存在せず、2つのDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータが指定されているため、2つの制御ファイルが作成されます。DB_CREATE_ONLINE_LOG_DEST_1の場所に存在する制御ファイルが主制御ファイルで、DB_CREATE_ONLINE_LOG_DEST_2の場所に存在する制御ファイルは多重化コピーです。ファイル名は、データベースによって一意に生成されます。これらはOracle Managed Filesです。サーバー・パラメータ・ファイルがある場合、CONTROL_FILES初期化パラメータが生成されます。

自動UNDO管理モードが指定されていますが、UNDO表領域が指定されておらず、DB_CREATE_FILE_DEST初期化パラメータが設定されていないため、UNDOTBSという名前のデフォルトUNDO表領域がDB_CREATE_FILE_DESTによって指定されたディレクトリに作成されます。データファイルは20MBで、自動拡張可能です。これはOracle Managed Filesです。

最後に、dflttmpという名前のデフォルト一時表領域が指定されています。DB_CREATE_FILE_DESTがパラメータ・ファイルに含まれているため、dflttmpの一時ファイルがそのパラメータによって指定されたディレクトリに作成されます。一時ファイルは100MBで、無制限に自動拡張可能です。これはOracle Managed Filesです。

作成されたファイルを、生成ファイル名によるファイル・ツリーで表現すると次のようになります。

/u01
/oradata
/SAMPLE
/datafile
/o1_mf_system_cmr7t30p_.dbf
/o1_mf_sysaux_cmr7t88p_.dbf
/o1_mf_sys_undo_2ixfh90q_.dbf
/o1_mf_dflttmp_157se6ff_.tmp
/u02
/oradata
/SAMPLE
/onlinelog
/o1_mf_1_0orrm31z_.log
/o1_mf_2_2xyz16am_.log
/controlfile
/o1_mf_cmr7t30p_.ctl
/u03
/oradata
/SAMPLE
/onlinelog
/o1_mf_1_ixfvm8w9_.log
/o1_mf_2_q89tmp28_.log
/controlfile
/o1_mf_x1sr8t36_.ctl

内部的に生成されたファイル名は、通常のビューを選択して表示できます。次に例を示します。

SQL> SELECT NAME FROM V$DATAFILE;

NAME
----------------------------------------------------
/u01/oradata/SAMPLE/datafile/o1_mf_system_cmr7t30p_.dbf
/u01/oradata/SAMPLE/datafile/o1_mf_sysaux_cmr7t88p_.dbf
/u01/oradata/SAMPLE/datafile/o1_mf_sys_undo_2ixfh90q_.dbf

3 rows selected

3. 制御ファイルの管理
データベースの作成時に制御ファイルが作成され、パラメータ・ファイルにCONTROL_FILES初期化パラメータが追加されました。必要に応じて、DBAはCREATE CONTROLFILE文を使用して、データベース用の制御ファイルを再作成したり、新しい制御ファイルを作成できます。

DATAFILE句およびLOGFILE句には、正しいOracle Managed Filesのファイル名を指定する必要があります。ALTER DATABASE BACKUP CONTROLFILE TO TRACE文は、正しいファイル名を含むスクリプトを生成します。また、ファイル名は、V$DATAFILE、V$TEMPFILEおよびV$LOGFILEビューを選択して確認することもできます。次の例では、サンプル・データベースの制御ファイルを再作成しています。

CREATE CONTROLFILE REUSE
DATABASE sample
LOGFILE
GROUP 1('/u02/oradata/SAMPLE/onlinelog/o1_mf_1_0orrm31z_.log',
'/u03/oradata/SAMPLE/onlinelog/o1_mf_1_ixfvm8w9_.log'),
GROUP 2('/u02/oradata/SAMPLE/onlinelog/o1_mf_2_2xyz16am_.log',
'/u03/oradata/SAMPLE/onlinelog/o1_mf_2_q89tmp28_.log')
NORESETLOGS
DATAFILE '/u01/oradata/SAMPLE/datafile/o1_mf_system_cmr7t30p_.dbf',
'/u01/oradata/SAMPLE/datafile/o1_mf_sysaux_cmr7t88p_.dbf',
'/u01/oradata/SAMPLE/datafile/o1_mf_sys_undo_2ixfh90q_.dbf',
'/u01/oradata/SAMPLE/datafile/o1_mf_dflttmp_157se6ff_.tmp'
MAXLOGFILES 5
MAXLOGHISTORY 100
MAXDATAFILES 10
MAXINSTANCES 2
ARCHIVELOG;

この文で作成される制御ファイルは、データベースを作成したときに生成されたCONTROL_FILES初期化パラメータの指定どおりに配置されます。REUSE句が指定されているので、既存のファイルがすべて上書きされます。

4. REDOログの管理
REDOログ・ファイルの新しいグループを作成するには、DBAがALTER DATABASE ADD LOGFILE文を使用します。次の文は、DB_CREATE_ONLINE_LOG_DEST_1とDB_CREATE_ONLINE_LOG_DEST_2にメンバーを持つログ・ファイルを追加します。これらのファイルは、Oracle Managed Filesです。

SQL> ALTER DATABASE ADD LOGFILE;

ログ・ファイルのメンバーは、完全なファイル名を指定することにより、追加および削除できます。

GROUP句を使用して、ログ・グループを削除できます。次の例では、Oracle Managed Filesのログ・ファイルの各メンバーに対応するオペレーティング・システム・ファイルが自動的に削除されます。

SQL> ALTER DATABASE DROP LOGFILE GROUP 3;

5. 表領域の管理
sampleデータベースで今後表領域を作成する際、すべてのデータファイルがデフォルトで配置される記憶域は、DB_CREATE_FILE_DEST初期化パラメータで指定された場所(この使用例では/u01/oradata)です。ファイル名を指定せずにデータファイルを作成すると、そのファイルは初期化パラメータDB_CREATE_FILE_DESTで指定されたファイル・システムに配置されます。次に例を示します。

SQL> CREATE TABLESPACE tbs_1;

この文は、/u01/oradataを記憶域とする表領域を作成します。作成されるデータファイルは初期サイズが100MBで、無制限に自動拡張可能です。このデータファイルはOracle Managed Filesです。

表領域を削除すると、その表領域に対応するOracle Managed Filesも自動的に削除されます。次の文は、表領域とその格納に使用されているすべてのOracle Managed Filesを削除します。

SQL> DROP TABLESPACE tbs_1;

最初のデータファイルが一杯になっても、新しいデータファイルは自動的に作成されません。別のOracle Managed Filesのデータファイルを追加することによって、表領域を拡張できます。次の文は、DB_CREATE_FILE_DESTで指定された場所に別のデータファイルを追加します。

SQL> ALTER TABLESPACE tbs_1 ADD DATAFILE;

デフォルトのファイル・システムを変更するには、初期化パラメータを変更します。これによって既存のデータファイルが変更されることはありません。その後の作成にのみ影響します。これは次の文を使用して動的に実行できます。

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST='/u04/oradata';

6. REDO情報のアーカイブ
REDOログ・ファイルのアーカイブは、Oracle Managed FilesとOracle Managed Files以外のファイルの間で違いはありません。アーカイブするログ・ファイルのファイル・システム上のアーカイブ先は、LOG_ARCHIVE_DEST_n初期化パラメータで指定できます。ファイル名は、LOG_ARCHIVE_FORMATパラメータまたはそのデフォルトに基づいて生成されます。アーカイブ・ログはOracle Managed Filesではありません。

7. バックアップ、リストアおよびリカバリ
Oracle Managed Filesは標準オペレーティング・システム・ファイルと互換性があるため、オペレーティング・システム・ユーティリティを使用してバックアップまたはリストアを実行できます。データベースのバックアップ、リストアおよびリカバリを実行する既存の方法はすべて、Oracle Managed Filesに対しても機能します。

使用例2: データベース領域と高速リカバリ領域を含むデータベースの作成と管理

この使用例では、DBAが、制御ファイルおよびREDOログ・ファイルを多重化するデータベースを作成します。アーカイブ・ログとRMANによるバックアップは、高速リカバリ領域に作成されます。このデータベースの作成とメンテナンスに関するタスクは、次のとおりです。

1. 初期化パラメータの設定
DBAは、次の汎用的なファイル作成デフォルトを設定します。

DB_CREATE_FILE_DEST = '/u01/oradata'
DB_RECOVERY_FILE_DEST_SIZE = 10G
DB_RECOVERY_FILE_DEST = '/u02/oradata'
LOG_ARCHIVE_DEST_1 = 'LOCATION = USE_DB_RECOVERY_FILE_DEST'

DB_CREATE_FILE_DESTパラメータは、データファイル、一時ファイル、制御ファイルおよびREDOログのデフォルトのファイル・システム・ディレクトリを設定します。

DB_RECOVERY_FILE_DESTパラメータは、制御ファイル、REDOログおよびRMANによるバックアップのデフォルトのファイル・システム・ディレクトリを設定します。

LOG_ARCHIVE_DEST_1構成の'LOCATION=USE_DB_RECOVERY_FILE_DEST'は、アーカイブ・ログをDB_RECOVERY_FILE_DESTの場所にリダイレクトします。

DB_CREATE_FILE_DESTパラメータとDB_RECOVERY_FILE_DESTパラメータは、ログ・ファイルおよび制御ファイル作成用のデフォルトのディレクトリを設定します。REDOログ・ファイルと制御ファイルは、2つのディレクトリの間で多重化されます。

2. データベースの作成

3. 制御ファイルの管理

4. REDOログの管理

5. 表領域の管理
タスク2、3、4と5は使用例1と同じです。ただし、制御ファイルとREDOログは、DB_CREATE_FILE_DESTとDB_RECOVERY_FILE_DESTの場所の間で多重化されます。

6. REDOログ情報のアーカイブ
オンライン・ログのアーカイブは、Oracle Managed FilesとOracle Managed Files以外のファイルの間には違いはありません。DB_RECOVERY_FILE_DESTで作成されるアーカイブ・ログは、Oracle Managed Filesです。

7. バックアップ、リストアおよびリカバリ
Oracle Managed Filesは標準オペレーティング・システム・ファイルと互換性があるため、オペレーティング・システム・ユーティリティを使用してバックアップまたはリストアを実行できます。データベースのバックアップ、リストアおよびリカバリを実行する既存の方法はすべて、Oracle Managed Filesに対しても機能します。フォーマット・オプションが指定されていない場合、RMANによるすべてのディスクのバックアップは、DB_RECOVERY_FILE_DESTの場所に作成されます。バックアップはOracle Managed Filesです。

使用例3: 既存のデータベースへのOracle Managed Filesの追加

この例では、Oracle Managed Filesが含まれていない既存のデータベースに対して、DBAがOracle Managed Filesを含む新しい表領域を作成し、/u03/oradataディレクトリにその表領域を配置しようとしていると想定しています。

1. 初期化パラメータの設定
データファイルの自動作成を可能にするために、DB_CREATE_FILE_DEST初期化パラメータを、データファイルを作成するファイル・システム・ディレクトリに設定します。これは、次のように動的に実行できます。

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/u03/oradata';

2. 表領域の作成
DB_CREATE_FILE_DESTの設定が完了すると、CREATE TABLESPACE文からDATAFILE句を省略できます。データファイルは、DB_CREATE_FILE_DESTで指定された場所にデフォルトで作成されます。次に例を示します。

SQL> CREATE TABLESPACE tbs_2;

tbs_2表領域を削除すると、データファイルが自動的に削除されます。

第III部

スキーマ・オブジェクト

第III部では、Oracle Databaseでスキーマ・オブジェクトを作成および管理する方法を説明します。次の章で構成されます。

- 第18章「スキーマ・オブジェクトの管理」

- 第19章「スキーマ・オブジェクトの領域の管理」

- 第20章「表の管理」

- 第21章「索引の管理」

- 第22章「クラスタの管理」

- 第23章「ハッシュ・クラスタの管理」

- 第24章「ビュー、順序およびシノニムの管理」

- 第25章「破損データの修復」

18 スキーマ・オブジェクトの管理

この章の内容は、次のとおりです。

- 一度の操作で複数の表やビューを作成する方法

- 表、索引およびクラスタの分析

- 表とクラスタの切捨て

- トリガーの使用可能および使用禁止

- 整合性制約の管理

- スキーマ・オブジェクトの名前変更

- オブジェクト依存性の管理

- オブジェクトの名前解決の管理

- 異なるスキーマへの切替え

- エディションの管理

- スキーマ・オブジェクト情報の表示

一度の操作で複数の表やビューを作成する方法

CREATE SCHEMA文を使用すると、一度の操作で複数の表やビューを作成し、権限を付与できます。個々の表やビューの作成が失敗したり、権限の付与が失敗したりすると、文全体がロールバックされます。オブジェクトは作成されず、権限も付与されません。

具体的には、CREATE SCHEMA文には、CREATE TABLE、CREATE VIEWおよびGRANT文のみを含めることができます。指定した文を発行するための権限を持っている必要があります。実際にスキーマが作成されるのではなく、スキーマはCREATE USER文を使用してユーザーを作成したときに作成されます。そのかわりに、この文はスキーマを移入します。

次の文は、2つの表とそれらのデータを結合するビューを作成します。

CREATE SCHEMA AUTHORIZATION scott
CREATE TABLE dept (
deptno NUMBER(3,0) PRIMARY KEY,
dname VARCHAR2(15),
loc VARCHAR2(25))
CREATE TABLE emp (
empno NUMBER(5,0) PRIMARY KEY,
ename VARCHAR2(15) NOT NULL,
job VARCHAR2(10),
mgr NUMBER(5,0),
hiredate DATE DEFAULT (sysdate),
sal NUMBER(7,2),
comm NUMBER(7,2),
deptno NUMBER(3,0) NOT NULL
CONSTRAINT dept_fkey REFERENCES dept)
CREATE VIEW sales_staff AS
SELECT empno, ename, sal, comm
FROM emp
WHERE deptno = 30
WITH CHECK OPTION CONSTRAINT sales_staff_cnst
GRANT SELECT ON sales_staff TO human_resources;

CREATE SCHEMA文は、STORAGE句など、ANSIのCREATE TABLE文とCREATE VIEW文を拡張したOracle Database独自の機能をサポートしていません。

関連項目:
CREATE SCHEMA文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表、索引およびクラスタの分析

次の目的でスキーマ・オブジェクト(表、索引またはクラスタ)を分析します。

- 統計の収集と管理

- 記憶形式の妥当性の検証

- 表またはクラスタの移行行と連鎖行の識別

注意:
オプティマイザ統計の収集に、ANALYZEでCOMPUTE句およびESTIMATE句を使用しないでください。これらの句は非推奨になりました。かわりに、DBMS_STATSパッケージを使用します。このパッケージでは、パラレルでの統計の収集、パーティション化されたオブジェクトのグローバル統計の収集、その他の方法での統計収集の微調整を行うことができます。統計に依存するコストベース・オプティマイザでは、最終的にはDBMS_STATSを使用して収集された統計のみが使用されます。DBMS_STATSパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください。
コストベース・オプティマイザに関連しない統計収集には、ANALYZE文(DBMS_STATSではなく)を使用する必要があります。たとえば、次のような場合です。

- VALIDATE句、LIST CHAINED ROWS句の使用

- 空きリスト・ブロックの情報を収集する場合

内容は次のとおりです。

- DBMS_STATSを使用した表および索引統計の収集

- 表、索引、クラスタおよびマテリアライズド・ビューの妥当性チェック

- 表とクラスタの連鎖行のリスト

DBMS_STATSを使用した表および索引統計の収集

DBMS_STATSパッケージまたはANALYZE文を使用して、表、索引またはクラスタの物理記憶特性の統計を収集できます。これらの統計はデータ・ディクショナリに格納され、オプティマイザで使用して、分析対象オブジェクトにアクセスするSQL文に最も効率的な実行計画を選択できます。

オプティマイザ統計の収集には、より多様性のあるDBMS_STATSパッケージを使用することをお薦めしますが、空きブロックや平均容量など、オプティマイザに関連付けられていない統計の収集にはANALYZE文を使用する必要があります。

DBMS_STATSパッケージを使用すると、パラレル実行を利用した統計収集と統計の外部操作ができます。統計をデータ・ディクショナリ以外の表に格納し、オプティマイザに影響を与えずにその統計を操作できます。統計をデータベース間でコピーしたり、バックアップ・コピーを作成できます。

次のDBMS_STATSプロシージャにより、オプティマイザ統計を収集できます。

- GATHER_INDEX_STATS

- GATHER_TABLE_STATS

- GATHER_SCHEMA_STATS

- GATHER_DATABASE_STATS

関連項目:

- DBMS_STATSを使用してオプティマイザ統計を収集する方法は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- DBMS_STATSパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

表、索引、クラスタおよびマテリアライズド・ビューの妥当性チェック

表、索引、クラスタまたはマテリアライズド・ビューの構造の整合性を検証するには、VALIDATE STRUCTUREオプションを指定したANALYZE文を使用します。構造が有効な場合、エラーは返されません。しかし、構造が破損していると、エラー・メッセージが出力されます。

たとえば、ハードウェアやその他のシステムに障害が発生した場合、索引が破損し、正しく機能しなくなる可能性があります。索引の妥当性をチェックすると、索引内のすべてのエントリが、対応付けられた表の正しい行を示しているかを確認できます。索引が破損した場合は、その索引を削除して再作成できます。

表、索引またはクラスタが破損している場合は、削除して再作成する必要があります。マテリアライズド・ビューが破損している場合は、完全リフレッシュを実行し、問題が修正されたことを確認します。問題が修正されない場合は、マテリアライズド・ビューを削除して再作成します。

次の文は、emp表を分析します。

ANALYZE TABLE emp VALIDATE STRUCTURE;

CASCADEオプションを含めると、オブジェクトとすべての依存オブジェクト(索引など)の妥当性をチェックできます。次の文は、emp表と、それに対応付けられているすべての索引の妥当性をチェックします。

ANALYZE TABLE emp VALIDATE STRUCTURE CASCADE;

デフォルトでは、CASCADEオプションによって、完全な妥当性チェックが実行されます。この操作はリソースを消費する可能性があるため、FAST句を使用してより高速なバージョンの妥当性チェックを実行できます。このバージョンでは、最適化されたチェック・アルゴリズムを使用して破損の有無をチェックしますが、破損の詳細はレポートしません。FASTチェックで破損が検出された場合は、FAST句を指定せずにCASCADEオプションを使用すると、破損箇所を特定できます。次の文では、emp表と、それに対応付けられているすべての索引の妥当性チェックを高速に実行します。

ANALYZE TABLE emp VALIDATE STRUCTURE CASCADE FAST;

妥当性をチェックするオブジェクトに対してDMLを実行している間でも、オンラインで構造の妥当性をチェックするように指定できます。オブジェクトに影響を及ぼす実行中のDMLによって妥当性が包括的でなくなりますが、これはオンラインでANALYZEを実行できる柔軟性によって相殺されます。次の文は、emp表と、それに対応付けられているすべての索引の妥当性をオンラインでチェックします。

ANALYZE TABLE emp VALIDATE STRUCTURE CASCADE ONLINE;

関連項目:
ANALYZE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表とクラスタの連鎖行のリスト

表またはクラスタの連鎖行と移行行は、LIST CHAINED ROWS句を指定したANALYZE文を使用して検出できます。この文の結果は、LIST CHAINED ROWS句によって返される情報を受け入れるために明示的に作成した指定の表に格納されます。この結果は、行を更新するための領域が十分であるかどうかを判断するうえで役立ちます。

CHAINED_ROWS表の作成

ANALYZE...LIST CHAINED ROWS文によって返されるデータを格納する表を作成するには、UTLCHAIN.SQLまたはUTLCHN1.SQLスクリプトを実行します。これらのスクリプトは、データベースに付属しています。これらのスクリプトは、スクリプトを実行するユーザーのスキーマ内にCHAINED_ROWSという名前の表を作成します。

注意:
CHAINED_ROWS表を作成するためにどちらのスクリプトを実行するかは、データベースの互換性レベルと分析する表のタイプによって決まります。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

CHAINED_ROWS表を作成した後、ANALYZE文のINTO句にその表を指定します。たとえば、次の文は、CHAINED_ROWS表に、emp_deptクラスタ内の連鎖行に関する情報を含む行を挿入します。

ANALYZE CLUSTER emp_dept LIST CHAINED ROWS INTO CHAINED_ROWS;

関連項目:

- CHAINED_ROWS表の詳細は、『Oracle Databaseリファレンス』を参照してください。

- 過剰な行連鎖のある表についてのセグメント・アドバイザのレポート方法の詳細は、「セグメント・アドバイザの使用」を参照してください。

表内の移行行または連鎖行の解消

CHAINED_ROWS表の情報を使用すると、既存表内にある移行行と連鎖行を低減または解消できます。これには、次の手順を使用します。

1. ANALYZE文を使用して、移行行と連鎖行に関する情報を収集します。

ANALYZE TABLE order_hist LIST CHAINED ROWS;

2. 出力表を問い合せます。

SELECT *
FROM CHAINED_ROWS
WHERE TABLE_NAME = 'ORDER_HIST';

OWNER_NAME  TABLE_NAME  CLUST... HEAD_ROWID          TIMESTAMP
----------  ----------  -----... ------------------  ---------
SCOTT       ORDER_HIST       ... AAAAluAAHAAAAA1AAA  04-MAR-96
SCOTT       ORDER_HIST       ... AAAAluAAHAAAAA1AAB  04-MAR-96
SCOTT       ORDER_HIST       ... AAAAluAAHAAAAA1AAC  04-MAR-96

移行行または連鎖行がすべてリストされます。

3. 出力表の問合せによって、移行行または連鎖行が多数存在することがわかれば、以降の手順を実行して移行行を解消します。

4. 既存表と同じ列を持つ中間表を作成して、移行行と連鎖行を格納します。

CREATE TABLE int_order_hist
AS SELECT *
FROM order_hist
WHERE ROWID IN
(SELECT HEAD_ROWID
FROM CHAINED_ROWS
WHERE TABLE_NAME = 'ORDER_HIST');

5. 既存表から移行行と連鎖行を削除します。

DELETE FROM order_hist
WHERE ROWID IN
(SELECT HEAD_ROWID
FROM CHAINED_ROWS
WHERE TABLE_NAME = 'ORDER_HIST');

6. 中間表の行を既存表に挿入します。

INSERT INTO order_hist
SELECT *
FROM int_order_hist;

7. 中間表を削除します。

DROP TABLE int_order_history;

8. 手順1で収集した情報を出力表から削除します。

DELETE FROM CHAINED_ROWS
WHERE TABLE_NAME = 'ORDER_HIST';

9. 再度ANALYZE文を使用してから、出力表を問い合せます。

出力表に表示された行は連鎖しています。連鎖行を解消するには、データ・ブロックのサイズを大きくする以外にありません。すべての状況において連鎖を回避することはほぼ不可能です。多くの場合、LONG列や大きいCHAR列またはVARCHAR2列を持つ表では、連鎖の発生は避けられません。

表とクラスタの切捨て

表(またはクラスタ)は残したままで、内容が完全に空になるように、表のすべての行またはクラスタ化表のグループ内のすべての行を削除できます。たとえば、月ごとのデータが含まれている表では、各月の終わりにそのデータをアーカイブした後で、表を空にする(すべての行を削除する)必要があります。

表からすべての行を削除するには、次の3通りの方法があります。

- DELETE文を使用する。

- DROP文とCREATE文を使用する。

- TRUNCATE文を使用する。

次の項では、これらの方法について説明します。

DELETEの使用

DELETE文を使用して表の行を削除できます。たとえば、次の文はemp表からすべての行を削除します。

DELETE FROM emp;

DELETE文を使用するときに、表またはクラスタに多数の行が存在していると、それらの行を削除する際に相当のシステム・リソースが使用されます。たとえば、CPU時間、その表と対応付けられた索引のREDOログ領域、UNDOセグメント領域などのリソースが必要です。また、各行が削除されるときに、トリガーが起動される場合があります。結果的に空になる表またはクラスタに事前に割り当てられた領域は、行を削除してもそのオブジェクトに対応付けられたままです。DELETEを使用すると削除する行を選択できますが、TRUNCATEとDROPの場合はオブジェクト全体が削除されます。

関連項目:
DELETE文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

DROPとCREATEの使用

表を削除してから再作成します。たとえば、次の例では、emp表を削除してから再作成しています。

DROP TABLE emp;
CREATE TABLE emp ( ... );

表やクラスタを削除してから再作成すると、対応付けられた索引、整合性制約およびトリガーもすべて削除され、削除された表またはクラスタ化表に依存するオブジェクトはすべて無効になります。また、削除された表またはクラスタ化表に対する権限付与もすべて削除されます。

TRUNCATEの使用

TRUNCATE文を使用して表のすべての行を削除できます。たとえば、次の文はemp表を切り捨てます。

TRUNCATE TABLE emp;

TRUNCATE文を使用すると、表またはクラスタからすべての行を高速かつ効率的に削除できます。TRUNCATE文ではロールバック情報は生成されず、即時にコミットが実行されます。これはDDL文であるため、ロールバックはできません。TRUNCATE文は、切り捨てられる表に関連付けられた構造(制約およびトリガー)または認可には影響を与えません。また、TRUNCATE文では、表を切り捨てた後で、表に現在割り当てられている領域を、その表を含む表領域に戻すかどうかも指定できます。

自分のスキーマにある表またはクラスタは切り捨てることができます。DROP ANY TABLEシステム権限を持っているユーザーは、どのスキーマ内の表またはクラスタでも切り捨てることができます。

親キーを含む表またはクラスタ化表を切り捨てる際は、別の表で定義されているすべての参照外部キーを事前に使用禁止にする必要があります。自己参照制約を使用禁止にする必要はありません。

TRUNCATE文によって表から行を削除する場合、表に対応付けられているトリガーは起動されません。また、TRUNCATE文は、監査が使用可能の場合でも、DELETE文に対応するどのような監査情報も生成しません。そのかわりに、発行されたTRUNCATE文に対して、単一の監査レコードが生成されます。

ハッシュ・クラスタや、ハッシュ・クラスタまたは索引クラスタ内の表を個別に切り捨てることはできません。索引クラスタを切り捨てると、そのクラスタ内のすべての表からすべての行が削除されます。個々のクラスタ化表からすべての行を削除する必要がある場合は、DELETE文を使用するか、または表を削除してから再作成してください。

TRUNCATE文には、表またはクラスタに現在割り当てられている領域が、切捨て後、その表またはクラスタを含む表領域に返されるかどうかを制御するオプションがいくつか用意されています。

これらのオプションは対応する索引にも適用されます。表またはクラスタを切り捨てると、対応付けられた索引もすべて切り捨てられます。切り捨てられた表、クラスタまたは対応付けられた索引の記憶域パラメータは、切捨て後も変わりません。

TRUNCATEのオプションは、次のとおりです。

- デフォルトのオプションDROP STORAGEは、文実行後の表に割り当てられたエクステントの数をMINEXTENTSの元の設定まで減らします。解放されたエクステントはシステムに戻され、他のオブジェクトによって使用できます。

- DROP ALL STORAGEは、セグメントを削除します。TRUNCATE TABLE文に加えて、DROP ALL STORAGEはALTER TABLE TRUNCATE (SUB)PARTITION文にも適用されます。また、このオプションは切捨て対象のパーティションに対応付けられた依存オブジェクト・セグメントも削除します。
DROP ALL STORAGEは、クラスタには使用できません。

注意:
この機能は、Oracle Database 11g リリース2(11.2.0.2)から使用できるようになりました。

TRUNCATE TABLE emp DROP ALL STORAGE;

- REUSE STORAGEを指定すると、表またはクラスタに対して現在割り当てられているすべての領域は割り当てられたままになります。たとえば、次の文はemp_deptクラスタを切り捨てて、クラスタに対してそれまでに割り当てられているすべてのエクステントを、今後の挿入と削除のためにそのまま残します。

TRUNCATE CLUSTER emp_dept REUSE STORAGE;

関連項目:

- TRUNCATE TABLEおよびTRUNCATE CLUSTER文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 監査の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

トリガーの使用可能および使用禁止

データベース・トリガーとは、データベースに格納されており、表に行を追加するなどの特定の条件が発生したときにアクティブ化(起動)されるプロシージャです。トリガーを使用してデータベースの標準機能を補完することにより、データベース管理システムを高度にカスタマイズできます。たとえば、表に対するDML操作を制限するトリガーを作成して、通常の営業時間中に発行された文のみ許可できます。

データベース・トリガーは、表、スキーマまたはデータベースに対応付けることができます。データベース・トリガーは、次の場合に暗黙的に起動されます。

- 対応付けられている表に対してDML文(INSERT、UPDATE、DELETE)が実行されたとき

- データベースまたはスキーマ内のオブジェクトに対して、特定のDDL文(ALTER、CREATE、DROPなど)が実行されたとき

- 指定したデータベース・イベントが発生したとき(STARTUP、SHUTDOWN、SERVERERRORなど)

このリストがすべてではありません。トリガーを起動する文とデータベース・イベントの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

トリガーを作成するには、CREATE TRIGGER文を使用します。トリガーは、トリガー・イベントの前(BEFORE)、後(AFTER)またはトリガー・イベントのかわりに(INSTEAD OF)起動するように定義できます。次の文は、表scott.empに対してトリガーscott.emp_permit_changesを作成します。このトリガーは、指定されたいずれかの文が実行される前に起動します。

CREATE TRIGGER scott.emp_permit_changes
BEFORE
DELETE OR INSERT OR UPDATE
ON scott.emp
.
.
.
pl/sql block
.
.
.

後でDROP TRIGGER文を発行し、トリガーをデータベースから削除できます。

トリガーには、次の2つのモードがあります。

- 使用可能
トリガーが起動される文を発行したときに、トリガー制限(存在する場合)がTRUEと評価された場合は、使用可能トリガーによってトリガー本体が実行されます。デフォルトでは、トリガーを最初に作成したときに使用可能に設定されます。

- 使用禁止
トリガーが起動される文を発行したときに、トリガー制限(存在する場合)がTRUEと評価された場合でも、使用禁止トリガーはトリガー本体を実行しません。

ALTER TABLE文を使用してトリガーを使用可能または使用禁止にするには、表を所有しているか、表に対するALTERオブジェクト権限があるか、またはALTER ANY TABLEシステム権限があることが必要です。また、ALTER TRIGGER文を使用してトリガーを個別に使用可能または使用禁止にするには、トリガーを所有しているか、またはALTER ANY TRIGGERシステム権限を持っている必要があります。

関連項目:

- トリガーの詳細は、『Oracle Database概要』を参照してください。

- CREATE TRIGGER文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

- トリガーの作成と使用の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

トリガーを使用可能にする方法

使用禁止のトリガーを使用可能にするには、ENABLEオプションを指定したALTER TRIGGER文を使用します。たとえば、inventory表に定義されているreorderという使用禁止のトリガーを使用可能にするには、次の文を入力します。

ALTER TRIGGER reorder ENABLE;

ENABLE ALL TRIGGERSオプションを指定したALTER TABLE文を使用すれば、特定の表に定義されているトリガーをすべて使用可能にできます。たとえば、inventory表に定義されているトリガーをすべて使用可能にするには、次の文を入力します。

ALTER TABLE inventory
ENABLE ALL TRIGGERS;

関連項目:
ALTER TRIGGER文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

トリガーを使用禁止にする方法

次の条件のいずれか1つが成り立つ場合は、一時的にトリガーを使用禁止にすることを検討してください。

- トリガーの参照するオブジェクトが使用可能でない場合。

- 大規模なデータ・ロードを実行する際に、トリガーを起動せずに迅速にデータをロードする場合。

- トリガーが適用される表にデータをロードする場合。

トリガーを使用禁止にするには、DISABLEオプションを指定したALTER TRIGGER文を使用します。たとえば、inventory表に定義されているトリガーreorderを使用禁止にするには、次の文を入力します。

ALTER TRIGGER reorder DISABLE;

DISABLE ALL TRIGGERSオプションを指定したALTER TABLE文を使用すれば、表に関連するトリガーをすべて同時に使用禁止にできます。たとえば、inventory表に定義されているトリガーをすべて使用禁止にするには、次の文を入力します。

ALTER TABLE inventory
DISABLE ALL TRIGGERS;

整合性制約の管理

整合性制約とは、表の1つ以上の列に格納される値を制限するルールです。CREATE TABLE文またはALTER TABLE文に制約句を指定することにより、その制約の影響を受ける列と、制約の条件を識別できます。

ここでは、制約の概念と、整合性制約の定義および管理に使用するSQL文について説明します。この項の内容は、次のとおりです。

- 整合性制約の状態

- 定義時の整合性制約の設定

- 既存の整合性制約の変更、名前変更または削除

- 制約チェックの遅延

- 制約例外のレポート

- 制約情報の表示

関連項目:

- 整合性制約の詳細は、『Oracle Database概要』を参照してください。

- アプリケーションで整合性制約を使用する際の詳細と使用例については、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

整合性制約の状態

制約は、使用可能(ENABLE)と使用禁止(DISABLE)のいずれの状態にするかを指定できます。制約が使用可能になっている場合は、データベース内でデータが入力または更新されるときにチェックが行われ、制約に従っていないデータは入力されません。制約が使用禁止になっている場合は、ルールに従っていないデータでもデータベースに入力できます。

また、表の既存データが必ず制約に従うように指定できます(VALIDATE)。逆にNOVALIDATEを指定すると、既存データが制約に従っていることは保証されません。

表に定義されている整合性制約は、次のいずれかの状態にあります。

- ENABLE、VALIDATE

- ENABLE、NOVALIDATE

- DISABLE、VALIDATE

- DISABLE、NOVALIDATE

これらの状態の意味と組合せの結果の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。これらの結果の一部について説明しています。

制約を使用禁止にする方法

整合性制約によって定義したルールを施行するには、その制約を常に使用可能にしておく必要があります。しかし、次のような場合は、パフォーマンス上の理由から、表の整合性制約を一時的に使用禁止にすることを検討してください。

- 表に大量のデータをロードする場合

- 表に大規模な変更を加えるバッチ操作を実行する場合(たとえば、既存の番号に1000を加えてすべての従業員番号を変更する場合)

- 表を1つずつインポートまたはエクスポートする場合

これら3つの場合には、整合性制約を一時的に使用禁止にすることにより、操作のパフォーマンスを改善できます。これは、特にデータ・ウェアハウス構成に当てはまります。

制約が使用禁止である間は、その制約に違反するデータを入力できます。したがって、前述の操作を終了した後に、制約を必ず使用可能にする必要があります。

制約を使用可能にする方法

制約が使用可能になっている場合、制約に違反する行は表に挿入されません。しかし、制約が使用禁止の場合は、制約に違反する行でも表に挿入できます。このような行を制約の例外と呼びます。制約が妥当性チェックなしで使用可能な状態にある場合、制約が使用禁止になっていた間に入力された違反データはそのまま残っています。制約を妥当性チェック済の状態にするためには、制約に違反する行を更新または削除する必要があります。

制約を使用可能にするときに、特定の整合性制約に対する例外を指定できます。「制約例外のレポート」を参照してください。制約に違反している行はすべてEXCEPTIONS表に格納され、検証できます。

妥当性チェックなしで使用可能な制約の状態

制約が妥当性チェックなしで使用可能な状態にある場合、それ以後の文はすべて、制約に従っているかどうかがチェックされます。ただし、表の既存データはチェックされません。妥当性チェックなしで使用可能な状態の制約を持つ表には、無効なデータが含まれる可能性がありますが、無効なデータを新たに追加することはできません。妥当性チェックなしで使用可能な制約は、有効なオンライン・トランザクション処理(OLTP)データをアップロードしているデータ・ウェアハウス構成で役立ちます。

制約を使用可能にする場合に、妥当性チェックは必ずしも必要ではありません。妥当性チェックなしで制約を使用可能にする方が、妥当性チェックありで制約を使用可能にするよりはるかに高速です。また、すでに使用可能になっている制約の妥当性をチェックする場合、妥当性チェック中のDMLロックは必要ありません(すでに使用禁止にした制約の妥当性をチェックする場合とは異なります)。これは、制約の規定により、妥当性チェック中に違反データが挿入されないことが保証されているためです。したがって、妥当性チェックなしで使用可能にすれば、制約を使用可能にすることによって一般に生じる停止時間を短縮できます。

整合性制約の効率的な使用: 手順

整合性制約の状態を次の順序で使用したときに、最も大きな利点が得られます。

1. 使用禁止状態。

2. 操作(ロード、エクスポート、インポート)の実行。

3. 妥当性チェックなしで使用可能な状態。

4. 使用可能状態。

制約をこの順序で使用する際の利点は、次のとおりです。

- ロックが保持されません。

- すべての制約を同時に使用可能状態にすることができます。

- 制約を使用可能にする処理がパラレルで行われます。

- 表での同時アクティビティを実行できます。

定義時の整合性制約の設定

CREATE TABLE文またはALTER TABLE文で整合性制約を定義するときにENABLE/DISABLE句を指定して、その制約を使用可能/使用禁止、妥当性チェックあり/妥当性チェックなしの状態にできます。制約の定義時にENABLE/DISABLE句を指定しなければ、自動的にその制約は妥当性チェックありで使用可能な状態になります。

定義時に制約を使用禁止にする方法

次のCREATE TABLE文とALTER TABLE文は、整合性制約を定義して、使用禁止にします。

CREATE TABLE emp (
empno NUMBER(5) PRIMARY KEY DISABLE,   . . . ;

ALTER TABLE emp
ADD PRIMARY KEY (empno) DISABLE;

整合性制約を定義して使用禁止にするALTER TABLE文は、表の行がその整合性制約に違反しているために失敗することはありません。制約のルールが施行されていないので、制約の定義が許可されます。

定義時に制約を使用可能にする方法

次のCREATE TABLE文とALTER TABLE文は、整合性制約を定義して、使用可能にします。

CREATE TABLE emp (
empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY,   . . . ;

ALTER TABLE emp
ADD CONSTRAINT emp.pk PRIMARY KEY (empno);

整合性制約を定義して使用可能にするALTER TABLE文は、表の行が整合性制約に違反しているために失敗する場合があります。この場合、その文はロールバックされ、制約定義は格納されず、使用可能にもなりません。

UNIQUEまたはPRIMARY KEY制約を使用可能にすると、対応する索引が作成されます。

注意:
並列性を利用できるように制約を使用可能にする効率的な手順は、「整合性制約の効率的な使用: 手順」を参照してください。

関連項目:
「制約に対応付けられた索引の作成」

既存の整合性制約の変更、名前変更または削除

ALTER TABLE文では、制約を使用可能または使用禁止にする他、制約を変更または削除することもできます。制約を規定するためにUNIQUEまたはPRIMARY KEY索引が使用されている場合、その索引に対応する制約を削除または使用禁止にすると、明示的に指定しないかぎり、索引は削除されます。

使用可能な外部キーがPRIMARYまたはUNIQUEキーを参照している間は、PRIMARYキー制約またはUNIQUEキー制約、または索引を使用禁止にしたり削除することはできません。

使用可能状態の制約を使用禁止にする方法

次の文は、使用可能状態の整合性制約を使用禁止にします。2番目の文では、対応する索引を保持するように指定しています。

ALTER TABLE dept
DISABLE CONSTRAINT dname_ukey;

ALTER TABLE dept
DISABLE PRIMARY KEY KEEP INDEX,
DISABLE UNIQUE (dname, loc) KEEP INDEX;

次の文は、使用禁止状態の整合性制約を妥当性チェックなしで使用可能な状態にします。

ALTER TABLE dept
ENABLE NOVALIDATE CONSTRAINT dname_ukey;

ALTER TABLE dept
ENABLE NOVALIDATE PRIMARY KEY,
ENABLE NOVALIDATE UNIQUE (dname, loc);

次の文は、使用禁止状態の整合性制約を使用可能にするか、または妥当性チェックありの状態にします。

ALTER TABLE dept
MODIFY CONSTRAINT dname_key VALIDATE;

ALTER TABLE dept
MODIFY PRIMARY KEY ENABLE NOVALIDATE;

次の文は、使用禁止状態の整合性制約を使用可能にします。

ALTER TABLE dept
ENABLE CONSTRAINT dname_ukey;

ALTER TABLE dept
ENABLE PRIMARY KEY,
ENABLE UNIQUE (dname, loc);

UNIQUEキーまたはPRIMARY KEY制約、およびすべての依存するFOREIGN KEY制約を一度に使用禁止または削除するには、DISABLE句またはDROP句のCASCADEオプションを使用します。たとえば、次の文はPRIMARY KEY制約とこれに依存するFOREIGN KEY制約を使用禁止にします。

ALTER TABLE dept
DISABLE PRIMARY KEY CASCADE;

制約名の変更

ALTER TABLE...RENAME CONSTRAINT文を使用すると、表に対する既存の制約の名前を変更できます。新しい制約名には、ユーザーの既存の制約名と競合しない名前を指定する必要があります。

次の文は、表deptに対するdname_ukey制約の名前を変更します。

ALTER TABLE dept
RENAME CONSTRAINT dname_ukey TO dname_unikey;

制約名を変更しても、実表に対するすべての依存性は引き続き有効です。

RENAME CONSTRAINT句を使用すると、制約のシステム生成名を変更できます。

制約の削除

整合性制約は、規定するルールが成立しなくなった場合、またはその制約が不要になった場合に削除できます。制約を削除するには、ALTER TABLE文で次のいずれかの句を指定します。

- DROP PRIMARY KEY

- DROP UNIQUE

- DROP CONSTRAINT

次の2つの文は、整合性制約を削除します。2番目の文は、PRIMARY KEY制約に対応する索引を保持します。

ALTER TABLE dept
DROP UNIQUE (dname, loc);

ALTER TABLE emp
DROP PRIMARY KEY KEEP INDEX,
DROP CONSTRAINT dept_fkey;

FOREIGN KEYがUNIQUEまたはPRIMARY KEYを参照している場合は、DROP文にCASCADE CONSTRAINTS句を指定しないかぎり、制約を削除できません。

制約チェックの遅延

データベースが制約をチェックしたときに制約が満たされていない場合は、エラーが通知されます。制約の妥当性チェックは、トランザクションが終わるまで遅延できます。

SET CONSTRAINTS文を発行すると、トランザクションの実行中、または別のSET CONSTRAINTS文によってモードが再設定されるまで、SET CONSTRAINTSモードが継続します。

注意:

- SET CONSTRAINT文は、トリガーの内部では発行できません。

- 遅延可能な一意キーと主キーは、必ず非一意索引を使用する必要があります。

すべての制約を遅延に設定する方法

データ操作に使用するアプリケーションでは、実際にデータの処理を始める前にすべての制約を遅延に設定する必要があります。遅延可能制約をすべて遅延に設定するには、次のDML文を使用します。

SET CONSTRAINTS ALL DEFERRED;

注意:
SET CONSTRAINTS文は、現行のトランザクションにのみ適用されます。制約を作成したときに指定したデフォルトは、その制約が存在するかぎり保持されています。ALTER SESSION SET CONSTRAINTS文は、現行のセッションにしか適用されません。

コミットのチェック(オプション)

COMMITの発行直前にSET CONSTRAINTS ALL IMMEDIATE文を発行することにより、制約違反をチェックできます。制約になんらかの問題があると、この文は失敗し、エラーの原因となっている制約が識別されます。制約違反のままコミットすると、トランザクションはロールバックされ、エラー・メッセージが返されます。

制約例外のレポート

制約の妥当性チェック時に例外が存在すると、エラーが返され、整合性制約は妥当性チェックなしの状態のままになります。整合性制約の例外が存在しているために文が正常に実行されない場合、文はロールバックされます。例外が存在している場合は、制約の例外をすべて更新または削除するまで、制約の妥当性はチェックできません。

整合性制約に違反している行を判断するには、ENABLE句にEXCEPTIONSオプションを指定してALTER TABLE文を発行します。EXCEPTIONSオプションにより、例外を含むすべての行の行ID、表所有者、表名および制約名が指定した表に格納されます。

制約を使用可能にする前に、ENABLE句のEXCEPTIONSオプションからの情報を格納する適切な例外レポート表を作成する必要があります。例外表を作成するには、UTLEXCPT.SQLスクリプトまたはUTLEXPT1.SQLスクリプトを実行します。

注意:
EXCEPTIONS表を作成するためにどちらのスクリプトを実行するかは、分析する表のタイプによって決まります。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

これらのスクリプトのどちらを使用しても、EXCEPTIONSという名前の表が作成されます。また、スクリプトを変更して再実行すると、新たに別の名前の例外表を作成できます。

次の文は、dept表のPRIMARY KEYを検証します。例外が存在すると、EXCEPTIONS表に情報が挿入されます。

ALTER TABLE dept ENABLE PRIMARY KEY EXCEPTIONS INTO EXCEPTIONS;

dept表に重複する主キー値が存在し、deptのPRIMARY KEY制約の名前がsys_c00610である場合は、次の問合せによって例外が表示されます。

SELECT * FROM EXCEPTIONS;

次の例外が表示されます。

fROWID               OWNER      TABLE_NAME      CONSTRAINT
------------------  ---------  --------------  -----------
AAAAZ9AABAAABvqAAB  SCOTT      DEPT            SYS_C00610
AAAAZ9AABAAABvqAAG  SCOTT      DEPT            SYS_C00610

次の文および結果のように、例外レポート表およびマスター表の行を結合した詳細な問合せの実行により、特定の制約に違反している実際の行を表示できます。

SELECT deptno, dname, loc FROM dept, EXCEPTIONS
WHERE EXCEPTIONS.constraint = 'SYS_C00610'
AND dept.rowid = EXCEPTIONS.row_id;

DEPTNO     DNAME             LOC
---------- --------------    -----------
10         ACCOUNTING        NEW YORK
10         RESEARCH          DALLAS

制約に違反している行はすべて更新するか、または制約を含む表から削除する必要があります。例外を更新する場合は、制約に違反する値を、制約を満たす値またはNULLに変更します。マスター表の行を更新または削除した後、以後取得する例外レポートとの混同を避けるために、例外レポート表の例外に対応する行は削除します。マスター表と例外レポート表を更新する文は、トランザクションの一貫性を保証するために、同じトランザクション内で実行してください。

前述の例の例外を訂正するために、次のトランザクションを発行できます。

UPDATE dept SET deptno = 20 WHERE dname = 'RESEARCH';
DELETE FROM EXCEPTIONS WHERE constraint = 'SYS_C00610';
COMMIT;

例外管理の最終的な目的は、例外レポート表の例外をすべて取り除くことにあります。

注意:
制約が使用禁止になっている表の現在の例外を訂正している間に、他のユーザーが新しい例外を作成する文を発行する可能性があります。これを避けるには、例外を取り除く前に、制約にENABLE NOVALIDATEのマークを付けます。

関連項目:
EXCEPTIONS表の詳細は、『Oracle Databaseリファレンス』を参照してください。

制約情報の表示

表の制約定義を表示し、制約で指定されている列を識別できるように、次のビューが用意されています。

ビュー

説明

DBA_CONSTRAINTS
ALL_CONSTRAINTS

USER_CONSTRAINTS

DBAビューには、データベース内のすべての制約定義が表示されます。ALLビューには、現行ユーザーがアクセス可能な制約定義が表示されます。USERビューには、現行ユーザーが所有している制約定義が表示されます。

DBA_CONS_COLUMNS
ALL_CONS_COLUMNS

USER_CONS_COLUMNS

DBAビューには、制約で指定されているデータベース内のすべての列が表示されます。ALLビューには、制約で指定されていて、現行ユーザーがアクセス可能な列のみが表示されます。USERビューには、制約で指定されていて、現行ユーザーが所有している列のみが表示されます。

関連項目:
これらのビューの列の詳細は、『Oracle Databaseリファレンス』を参照してください。

スキーマ・オブジェクトの名前変更

オブジェクト名を変更するには、そのオブジェクトが自分のスキーマ内に存在する必要があります。スキーマ・オブジェクトは、次のいずれかの方法で名前を変更できます。

- オブジェクトを削除して再作成する。

- RENAME文を使用してオブジェクトの名前を変更する。

- ALTER ... RENAME文を使用してオブジェクトの名前を変更する(索引およびトリガーの場合)。

オブジェクトを削除して再作成する場合、そのオブジェクトに付与された権限はすべて失われます。オブジェクトを再作成するときに、再度権限を付与してください。

RENAME文を使用して、表、ビュー、順序またはそれらのプライベート・シノニムの名前を変更することもできます。RENAME文を使用すると、そのオブジェクトの整合性制約、索引および権限付与は新しい名前に引き継がれます。たとえば、次の文はsales_staffビューの名前を変更します。

RENAME sales_staff TO dept_30;

注意:
ストアドPL/SQLプログラム・ユニット、パブリック・シノニムまたはクラスタに対しては、RENAMEを使用できません。これらのオブジェクトの名前を変更するには、削除してから再作成してください。

スキーマ・オブジェクト名を変更する前に、次のような影響について検討する必要があります。

- 名前を変更されたオブジェクトに依存しているビューとPL/SQLプログラム・ユニットはすべて無効になるため、次に使用する前に再コンパイルする必要があります。

- 名前を変更されたオブジェクトのシノニムを使用すると、必ずエラーが返されます。

関連項目:
RENAME文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

オブジェクト依存性の管理

ここでは、オブジェクト依存性とオブジェクトの無効化に関するバックグラウンド情報を提供し、無効なオブジェクトを再検証する方法について説明します。この項の内容は、次のとおりです。

- オブジェクト依存性とオブジェクトの無効化の概要

- DDLを使用した手動による無効なオブジェクトの再コンパイル

- PL/SQLパッケージのプロシージャを使用した手動による無効なオブジェクトの再コンパイル

オブジェクト依存性とオブジェクトの無効化の概要

スキーマ・オブジェクトには、他のオブジェクトを参照するタイプのものがあります。たとえば、ビューには表または他のビューを参照する問合せが含まれ、PL/SQLサブプログラムは他のサブプログラムを起動し、静的SQLを使用して表やビューを参照します。他のオブジェクトを参照するオブジェクトは依存オブジェクトと呼ばれ、参照されるオブジェクトは参照オブジェクトと呼ばれます。これらの参照はコンパイル時に確立され、コンパイラで解決できない場合は、コンパイル中の依存オブジェクトが「無効」とマークされます。

Oracle Databaseには、依存オブジェクトが参照オブジェクトに関して常に最新であることを確認する自動メカニズムが用意されています。依存オブジェクトが作成されると、データベースによって、依存オブジェクトとその参照オブジェクト間の依存性が追跡されます。参照オブジェクトが依存オブジェクトに影響を与えるような方法で変更されると、依存オブジェクトには無効のマークが付けられます。無効になった依存オブジェクトは、参照オブジェクトの新しい定義で再コンパイルして使用できるようにする必要があります。再コンパイルは、無効な依存オブジェクトが参照されると自動的に実行されます。

無効化はデータベース上で稼働するアプリケーションに影響を及ぼすため、スキーマ・オブジェクトを無効化する可能性がある変更を理解しておくことが重要です。ここでは、オブジェクトが無効になる仕組み、無効なオブジェクトを識別する方法、および無効なオブジェクトの妥当性をチェックする方法について説明します。

オブジェクトの無効化

通常、正常に実行中のアプリケーションでは表構造の変更やビュー定義またはストアド・プロシージャ定義の変更は行われないため、標準的な稼働中アプリケーションでビューやストアド・プロシージャが無効になることは予期されていません。表、ビューまたはPL/SQLユニットへの変更は、パッチ・スクリプトまたは非定型DDL文を使用してアプリケーションにパッチを適用するとき、またはアップグレードするときに発生するのが一般的です。パッチが適用されて参照オブジェクトのセットが変更された後、依存オブジェクトが無効のまま残る場合があります。

データベース内の無効な一連のオブジェクトを表示するには、次の問合せを使用します。

SELECT object_name, object_type FROM dba_objects
WHERE status = 'INVALID';

スキーマ・オブジェクトが無効になると、Enterprise Managerのデータベース・ホームページにアラートが表示されます。

オブジェクトの無効化によって、アプリケーションは次の2つの影響を受けます。第1に、無効なオブジェクトは、再検証されるまでアプリケーションで使用できません。再検証によって、アプリケーション実行の待機時間が長くなります。無効なオブジェクトが多数ある場合は、初回実行時の待機時間が長時間になる可能性があります。第2に、プロシージャ、ファンクションまたはパッケージの無効化によって、そのプロシージャ、ファンクションまたはパッケージを同時に実行している他のセッションで例外が発生する可能性があります。アプリケーションを別のセッションで使用しているときにパッチを適用すると、アプリケーションを実行しているセッションによって、使用中のオブジェクトが無効化されたことが通知され、ORA-04061、ORA-04064、ORA-04065またはORA-04068の4つの例外のうちのいずれか1つが発生します。これらの例外は、パッチ適用後にアプリケーション・セッションを再起動して修正する必要があります。

適切なSQL文にCOMPILE句を指定して、スキーマ・オブジェクトを強制的に再コンパイルできます。詳細は、「DDLを使用した手動による無効なオブジェクトの再コンパイル」を参照してください。

無効なオブジェクトが多数存在することが判明している場合は、UTL_RECOMP PL/SQLパッケージを使用して一括再コンパイルを実行します。詳細は、「PL/SQLパッケージのプロシージャを使用した手動による無効なオブジェクトの再コンパイル」を参照してください。

次に、スキーマ・オブジェクトの無効化に関する一般的な規則をいくつか示します。

- 参照オブジェクトとその依存オブジェクトの間で、データベースは、依存関係に含まれる参照オブジェクトの要素を追跡します。たとえば、単一表のビューで表内の列のサブセットのみが選択された場合、それらの列のみが依存関係に含まれます。オブジェクトの各依存関係について、依存関係に含まれる要素の定義が変更されると(要素の削除も含む)、依存オブジェクトは無効になります。逆に、依存関係に含まれない要素の定義のみが変更された場合、依存オブジェクトは有効なままです。
したがって、開発者がスキーマ・オブジェクトの変更時に注意することにより、多くの場合、依存オブジェクトの無効化とそれによるデータベースへの不要な追加作業の発生を回避できます。

- 依存オブジェクトは連鎖的に無効になります。オブジェクトがなんらかの理由で無効になると、そのオブジェクトのすべての依存オブジェクトがただちに無効になります。

- スキーマ・オブジェクトに対するオブジェクト権限を取り消すと、依存オブジェクトは連鎖的に無効になります。

関連項目:
スキーマ・オブジェクトの依存性の詳細は、『Oracle Database概要』を参照してください。

DDLを使用した手動による無効なオブジェクトの再コンパイル

単一のスキーマ・オブジェクトを手動で再コンパイルするには、ALTER文を使用します。たとえば、パッケージ本体のPkg1を再コンパイルするには、次のDDL文を実行します。

ALTER PACKAGE pkg1 COMPILE REUSE SETTINGS;

関連項目:
様々なALTER文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

PL/SQLパッケージのプロシージャを使用した手動による無効なオブジェクトの再コンパイル

アプリケーションのアップグレードまたはパッチの適用に続いて、無効なオブジェクトを再検証して、オンデマンドのオブジェクト再検証で生じるアプリケーションの待ち時間を回避することをお薦めします。Oracleには、オブジェクトの再検証で役立つUTL_RECOMPパッケージが用意されています。RECOMP_SERIALプロシージャは、スキーマ名引数が指定されない場合、指定されたスキーマのすべての無効なオブジェクト、またはデータベース内のすべての無効なオブジェクトを再コンパイルします。RECOMP_PARALLELプロシージャも同様ですが、複数のCPUをパラレルに使用します。

例

次のPL/SQLブロックを実行して、データベース内の無効なオブジェクトすべてをパラレルに、依存順序に従って再検証します。

begin
utl_recomp.recomp_parallel();
end;
/

DBMS_UTILITYパッケージを使用して、無効なオブジェクトを個別に再検証することもできます。次のスクリプトは、HRスキーマのUPDATE_SALARYプロシージャを再検証するPL/SQLブロックです。

begin
dbms_utility.validate('HR', 'UPDATE_SALARY', namespace=>1);
end;
/

次のスクリプトは、パッケージ本体のHR.ACCT_MGMTを再検証するPL/SQLブロックです。

begin
dbms_utility.validate('HR', 'ACCT_MGMT', namespace=>2);
end;
/

関連項目:
UTL_RECOMPパッケージおよびDBMS_UTILITYパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

オブジェクトの名前解決の管理

SQL文で参照されるオブジェクト名は、ピリオドで区切られた複数の断片から構成できます。ここでは、データベースでオブジェクト名を解決する方法を説明します。

1. Oracle Databaseは、SQL文で参照される名前の最初の断片を識別しようとします。たとえば、scott.empの最初の断片はscottです。断片が1つしか存在しない場合、その断片は最初の断片とみなされます。

1. 現行スキーマ内で、オブジェクト名の最初の断片に一致するオブジェクトが検索されます。このようなオブジェクトが見つからない場合は、手順bに進みます。

2. オブジェクト名の最初の断片に一致するパブリック・シノニムが検索されます。このようなパブリック・シノニムが見つからない場合は、手順cに進みます。

3. データベースでは、オブジェクト名の最初の断片に一致するスキーマが検索されます。一致が見つかると、そのスキーマは完全修飾スキーマとなり、手順dに進みます。

手順cでスキーマが見つからない場合、オブジェクトは識別されず、データベースからエラーが返されます。

4. 完全修飾スキーマ内で、オブジェクト名の2番目の断片に一致するオブジェクトが検索されます。

2番目の断片が、前回識別されたスキーマ内のオブジェクトに対応しない場合、または2番目の断片がない場合は、データベースはエラーを返します。

2. スキーマ・オブジェクトは修飾されています。SQL文で与えられた名前の残りの断片は、見つかったオブジェクトの有効な部分に一致する必要があります。たとえば、名前がscott.emp.deptnoで、scottがスキーマとして識別され、empが表として識別された場合は、(empが表であるため)deptnoは列に対応する必要があります。また、empがパッケージとして識別された場合、deptnoはそのパッケージのパブリック定数、変数、プロシージャまたはファンクションに対応する必要があります。

分散データベースにおいて、グローバル・オブジェクト名が明示的またはシノニム内で間接的に使用されている場合、ローカル・データベースはローカルで参照を解決します。たとえば、シノニムをリモート表のグローバル・オブジェクト名として解決します。部分的に解決された文はリモート・データベースに転送され、前述の手順に従って、リモート・データベースでオブジェクトの解決が行われます。

データベースによる参照の解決方法の関係で、あるオブジェクトが、他のオブジェクトが存在しないことに依存している可能性があります。この状況が発生するのは、依存するオブジェクトが使用している参照の解析方法が、他のオブジェクトが存在しているときには異なる場合です。たとえば、次のような場合を考えてみます。

- 現時点では、companyスキーマに表empが含まれています。

- company.empに対してPUBLICシノニムempが作成され、company.empに対するSELECT権限がPUBLICロールに付与されます。

- jwardスキーマには、表またはプライベート・シノニムempは含まれていません。

- ユーザーjwardが、次の文を使用して自分のスキーマにビューを作成します。

CREATE VIEW dept_salaries AS
SELECT deptno, MIN(sal), AVG(sal), MAX(sal) FROM emp
GROUP BY deptno
ORDER BY deptno;

jwardがdept_salariesビューを作成すると、empへの参照は、jward.empを表、ビューまたはプライベート・シノニムとして検索し、いずれも見つからない場合はパブリック・シノニムempとして検索して見つけることで解決されます。その結果、jward.dept_salariesは、jward.empが存在しないことと、public.empが存在することに依存していることがわかります。

ここで、jwardが次の文を使用して自分のスキーマに新しいビューempを作成するとします。

CREATE VIEW emp AS
SELECT empno, ename, mgr, deptno
FROM company.emp;

jward.empの構造がcompany.empとは異なることに注意してください。

データベースは、オブジェクト定義内の参照を解決しようとする際に、新規の依存オブジェクトの、「存在しない」オブジェクト(存在していたとすると、オブジェクトの定義の解析を変えてしまうスキーマ・オブジェクト)への依存性に内部的に注目します。存在しないオブジェクトを後で作成する場合は、このような依存性に注意する必要があります。存在しないオブジェクトを作成する場合、依存オブジェクトを再コンパイルおよび検証できるようにすべての依存オブジェクトを無効化するとともに、依存するすべてのファンクション索引に使用禁止とマークする必要があります。

したがって、前述の例では、jward.empが作成されると、jward.dept_salariesはjward.empに依存するため無効になります。その後、jward.dept_salariesが使用されると、データベースはビューの再コンパイルを試みます。empへの参照を解決するときに、jward.empが見つかります(public.empは参照先のオブジェクトではなくなっています)。jward.empにはsal列がないため、ビューを置換するときにエラーが見つかり、ビューは無効のままになります。

要約すると、存在しないオブジェクトを後で作成する場合は、オブジェクトの解決中にチェックされる存在しないオブジェクトへの依存性を管理する必要があります。

関連項目:
分散データベースにおける名前解決の詳細は、「スキーマ・オブジェクトとデータベース・リンク」を参照してください。

異なるスキーマへの切替え

次の文は、現行セッションのスキーマを、この文で指定するスキーマ名に設定します。

ALTER SESSION SET CURRENT_SCHEMA = <schema name>

その後のSQL文では、修飾子が省略されている場合に、Oracle Databaseによって、このスキーマ名がスキーマ修飾子として使用されます。また、データベースでは、指定したスキーマの一時表領域が、一時データベース・オブジェクトのソート、結合および格納に使用されます。セッションには元の権限が保持され、前述のALTER SESSION文によって余分な権限は取得されません。

次の例では、プロンプトが表示されたらパスワードを入力します。

CONNECT scott
ALTER SESSION SET CURRENT_SCHEMA = joe;
SELECT * FROM emp;

empは識別されたスキーマではないため、表名はjoeスキーマのもとで解決されます。ただし、scottがjoe.emp表の選択権限を持たない場合、scottはSELECT文を実行できません。

エディションの管理

エディションに基づく再定義によりアプリケーションをアップグレードするアプリケーション開発者が、DBA権限を必要とするエディション関連のタスクを実行するように要求する場合があります。

この項の内容は、次のとおりです。

- エディションおよびエディションに基づく再定義の概要

- エディションに基づく再定義のためのDBAのタスク

- データベースのデフォルトのエディションの設定

- データベースのデフォルト・エディションの問合せ

- データベース・サービスのエディション属性の設定

- エディションの使用

- エディションのデータ・ディクショナリ・ビュー

エディションおよびエディションに基づく再定義の概要

エディションベースの再定義を使用すると、アプリケーションの使用中にアプリケーションのデータベース・オブジェクトをアップグレードできるため、停止時間を最小限に抑えることや解消することが可能です。これは、エディションと呼ばれるプライベート環境でデータベース・オブジェクトを変更(再定義)することによって実行します。すべての変更が実行およびテストされている場合のみ、アプリケーションの新バージョンをユーザーが使用できるようにしてください。

関連項目:
エディションに基づく再定義の詳細な説明は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

エディションに基づく再定義のためのDBAのタスク

表18-1に、通常はDBAにのみ付与される権限を必要とするエディション関連のタスクの要約を示します。DBAのロールを付与されているユーザーはこれらのタスクを実行可能です。

表18-1 エディションに基づく再定義のためのDBAのタスク

タスク

参照先

エディションを作成、変更、および削除する権限の付与または取消し

『Oracle Database SQL言語リファレンス』のCREATE EDITIONおよびDROP EDITIONコマンド

スキーマのエディションの有効化

『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』

データベースのデフォルト・エディションの設定

「データベースのデフォルトのエディションの設定」

データベース・サービスのエディション属性を設定します。

「データベース・サービスのエディション属性の設定」

データベースのデフォルトのエディションの設定

データベースには必ずデフォルトのエディションがあります。これは、接続時にエディションが明示的に示されない場合にデータベース・セッションが最初に使用するエディションです。

データベースのデフォルト・エディションを設定する手順は、次のとおりです。

1. データベースにALTER DATABASE権限を持つユーザーとして接続します。

2. 次の文を入力します。

ALTER DATABASE DEFAULT EDITION = edition_name;

関連項目:
「SQL*Plusを使用したデータベースへの接続」

データベースのデフォルト・エディションの問合せ

データベースのデフォルト・エディションは、データベースのプロパティとして格納されています。

データベースのデフォルト・エディションを問い合せる手順は、次のとおりです。

1. 任意のユーザーとしてデータベースに接続します。

2. 次の文を入力します。

SELECT PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE
PROPERTY_NAME = 'DEFAULT_EDITION';

PROPERTY_VALUE
------------------------------
ORA$BASE

注意:
プロパティ名のDEFAULT_EDITIONは大文字/小文字が区別されます。必ず大文字で入力してください。

データベース・サービスのエディション属性の設定

注意:
この機能は、Oracle Database 11g リリース2(11.2.0.2)から使用できるようになりました。

データベース・サービスの作成時にそのエディション属性を設定したり、既存のデータベース・サービスのエディション属性を変更できます。サービスのエディション属性を設定すると、クライアント接続やDBMS_SCHEDULERジョブなどサービスを指定する後続のすべての接続はこのエディションを初期セッション・エディションとして使用します。ただし、セッション接続に別のエディションが指定されている場合は、セッション接続に指定されているエディションがセッション・エディションに使用されます。データベース・サービスのエディション属性をチェックするには、ALL_SERVICESビューまたはDBA_SERVICESビューのEDITION列に問い合せます。

注意:
インスタンスのデータベース・サービスの数には、上限があります。この制限の詳細は、『Oracle Databaseリファレンス』を参照してください。

データベース・サービス作成時のエディション属性の設定

データベース・サービスのエディション属性を設定するには、「データベース・サービスの作成」の手順に従い、適切なオプションを使用します。

- 単一インスタンス・データベースをOracle Restartで管理している場合は、SRVCTLユーティリティを使用してデータベース・サービスを作成し、-tオプションを指定してそのエディション属性を設定します。
この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースを対象に、crmbatchという名前で新規データベース・サービスを作成し、データベース・サービスのエディション属性をe2に設定します。

srvctl add service -d dbcrm -s crmbatch -t e2

- 単一インスタンス・データベースをOracle Restartで管理していない場合は、DBMS_SERVICE.CREATE_SERVICEプロシージャを使用し、editionパラメータを指定してデータベース・サービスのエディション属性を設定します。

既存のデータベース・サービスのエディション属性の設定

既存のデータベース・サービスのエディション属性を設定するには、SRVCTLユーティリティまたはDBMS_SERVICEパッケージを使用します。

既存のデータベース・サービスのエディション属性を設定する手順は、次のとおりです。

1. データベース・サービスを停止します。

2. 適切なオプションを使用して、データベース・サービスのエディション属性を設定します。

- 単一インスタンス・データベースをOracle Restartで管理している場合は、SRVCTLユーティリティを使用してデータベース・サービスを変更し、-tオプションを指定してそのエディション属性を設定します。
この例では、DB_UNIQUE_NAMEがdbcrmであるデータベースを対象に、crmbatchという名前のデータベース・サービスを変更し、データベース・サービスのエディション属性をe3に設定します。

srvctl modify service -d dbcrm -s crmbatch -t e3

- 単一インスタンス・データベースをOracle Restartで管理していない場合は、DBMS_SERVICE.MODIFY_SERVICEプロシージャを使用し、editionパラメータを指定してデータベース・サービスのエディション属性を設定します。MODIFY_SERVICEプロシージャを実行するときには、modify_editionパラメータがTRUEに設定されていることを確認してください。

3. データベース・サービスを起動します。

関連項目:

- Oracle Restartを使用したデータベース・サービスの管理については、第4章「Oracle Databaseの自動再起動の構成」を参照してください。

- DBMS_SERVICEパッケージを使用したデータベース・サービスの管理の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

エディションの使用

特定のエディションのオブジェクトを表示または変更するには、最初にそのエディションを使用する必要があります。データベースに接続したときに、使用するエディションを指定できます。エディションを指定しない場合は、データベースのデフォルトのエディションでセッションが開始されます。異なるエディションを使用するには、次の文を発行します。

ALTER SESSION SET EDITION=edition_name;

次の文は、現在のエディションをe2に設定してから、ora$baseに設定します。

ALTER SESSION SET EDITION=e2;
...
ALTER SESSION SET EDITION=ora$base;

関連項目:

- エディションの使用および現在のエディションの判別方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- 「SQL*Plusを使用したデータベースへの接続」

エディションのデータ・ディクショナリ・ビュー

エディションの管理に役立つデータ・ディクショナリ・ビューがいくつかあります。次の表に、そのうちの3つを示します。詳細なリストは、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

ビュー

説明

*_EDITIONS

データベース内のすべてのエディションがリストされます。(注意: USER_EDITIONSは存在しません。)

*_OBJECTS

現在のエディションで表示可能な(実在するか、継承されている)データベースのすべてのオブジェクトを示します。

*_OBJECTS_AE

エディション全体のデータベース内にあるすべての実在のオブジェクトを示します。

スキーマ・オブジェクト情報の表示

Oracle DatabaseにはPL/SQLパッケージが用意されており、スキーマ・オブジェクト情報の表示に使用できるオブジェクトおよびデータ・ディクショナリ・ビューを作成したDDLを判断できます。特定のタイプのスキーマ・オブジェクトに固有のビューとパッケージは、関連する章に記載されています。ここでは、汎用的な性質を持ち、複数のスキーマ・オブジェクトに適用されるビューとパッケージについて説明します。

PL/SQLパッケージを使用したスキーマ・オブジェクト情報の表示

オラクル社が提供するPL/SQLパッケージDBMS_METADATA.GET_DDLを使用すると、スキーマ・オブジェクトに関するメタデータを(オブジェクトの作成に使用するDDLの形式で)取得できます。

関連項目:
DBMS_METADATAパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

例: DBMS_METADATAパッケージの使用

DBMS_METADATAパッケージは、スキーマ・オブジェクトの完全な定義を取得するための強力なツールです。これにより、あるオブジェクトのすべての属性を1回のパスで取得できます。オブジェクトは、その作成(再作成)に使用できるDDLで表されます。

次の文では、GET_DDLファンクションを使用して、現行スキーマ内にあるすべての表のDDLをフェッチし、ネストした表とオーバーフロー・セグメントを除外しています。また、SQL DDLで記憶域句が返されないようにするため、SET_TRANSFORM_PARAM(ハンドル値として「現行セッション用」を意味するDBMS_METADATA.SESSION_TRANSFORMをとる)を使用してそれを指定しています。セッション・レベルの変換パラメータは、最後にデフォルトにリセットされています。変換パラメータ値は、いったん設定すると、明示的にデフォルトにリセットされるまで有効です。

EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM(
DBMS_METADATA.SESSION_TRANSFORM,'STORAGE',false);
SELECT DBMS_METADATA.GET_DDL('TABLE',u.table_name)
FROM USER_ALL_TABLES u
WHERE u.nested='NO'
AND (u.iot_type is null or u.iot_type='IOT');
EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM(
DBMS_METADATA.SESSION_TRANSFORM,'DEFAULT');

DBMS_METADATA.GET_DDLからの出力はLONGデータ型です。SQL*Plusを使用している場合は、出力がデフォルトで切り捨てられる場合があります。出力が切り捨てられないようにするには、DBMS_METADATA.GET_DDL文を発行する前に、次のSQL*Plusコマンドを発行してください。

SQL> SET LONG 9999

スキーマ・オブジェクトのデータ・ディクショナリ・ビュー

次のビューには、スキーマ・オブジェクトに関する一般的な情報が表示されます。

ビュー

説明

DBA_OBJECTS
ALL_OBJECTS

USER_OBJECTS

DBAビューには、データベース内のすべてのスキーマ・オブジェクトが表示されます。ALLビューには、現行ユーザーがアクセス可能なオブジェクトが表示されます。USERビューには、現行ユーザーが所有しているオブジェクトが表示されます。

DBA_CATALOG
ALL_CATALOG

USER_CATALOG

データベース内にあるすべての表、ビュー、シノニムおよび順序の名前、タイプおよび所有者(USERビューでは所有者は表示されない)がリストされます。

DBA_DEPENDENCIES
ALL_DEPENDENCIES

USER_DEPENDENCIES

プロシージャ、パッケージ、ファンクション、パッケージ本体およびトリガーの間の依存性(データベース・リンクを持たないビューへの依存性など)がすべてリストされます。

関連項目:
データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

次に、これらのビューの使用例を示します。

- 例1: スキーマ・オブジェクトのタイプ別表示

- 例2: ビューとシノニムの依存性の表示

例1: スキーマ・オブジェクトのタイプ別表示

次の問合せは、問合せを発行しているユーザーが所有しているオブジェクトをすべてリストします。

SELECT OBJECT_NAME, OBJECT_TYPE
FROM USER_OBJECTS;

問合せの出力は次のとおりです。

OBJECT_NAME                OBJECT_TYPE
-------------------------  -------------------
EMP_DEPT                   CLUSTER
EMP                        TABLE
DEPT                       TABLE
EMP_DEPT_INDEX             INDEX
PUBLIC_EMP                 SYNONYM
EMP_MGR                    VIEW

例2: ビューとシノニムの依存性の表示

ビューまたはシノニムを作成するとき、ビューやシノニムはその基礎になるベース・オブジェクトに基づきます。ビューの依存性を明確にするには、ALL_DEPENDENCIES、USER_DEPENDENCIESおよびDBA_DEPENDENCIESデータ・ディクショナリ・ビューを使用します。シノニムのベース・オブジェクトのリストを表示するには、ALL_SYNONYMS、USER_SYNONYMSおよびDBA_SYNONYMSデータ・ディクショナリ・ビューを使用します。たとえば、次の問合せは、ユーザーjwardによって作成されたシノニムのベース・オブジェクトをリストします。

SELECT TABLE_OWNER, TABLE_NAME, SYNONYM_NAME
FROM DBA_SYNONYMS
WHERE OWNER = 'JWARD';

問合せの出力は次のとおりです。

TABLE_OWNER             TABLE_NAME   SYNONYM_NAME
----------------------  -----------  -----------------
SCOTT                   DEPT         DEPT
SCOTT                   EMP          EMP

19 スキーマ・オブジェクトの領域の管理

この章の内容は、次のとおりです。

- 表領域のアラートの管理

- 再開可能領域割当ての管理

- 使用できない領域の再生

- 未使用オブジェクト記憶域の削除

- データ型の領域使用の理解

- スキーマ・オブジェクトの領域使用情報の表示

- データベース・オブジェクトの容量計画

表領域のアラートの管理

Oracle Databaseでは、使用可能な領域が少なくなると事前にアラートで通知されるため、表領域のディスク領域を管理するのに役立ちます。デフォルトで、警告およびクリティカルの2つのアラートしきい値が定義されています。警告のしきい値は、領域が残り少なくなり始める境界値です。クリティカルのしきい値は、即時に注意を喚起する必要のある深刻な境界値です。データベースは、両方のしきい値でアラートを発行します。

ローカル管理表領域とディクショナリ管理表領域の両方に対してアラートしきい値を指定するには、次の2つの方法があります。

- パーセント・フルによる方法
警告のしきい値とクリティカルのしきい値の両方について、使用済領域が合計領域の一定割合以上になるとアラートが発行されます。

- 空き領域(KB単位)による方法
警告のしきい値とクリティカルのしきい値の両方について、空き領域が一定容量(KB)未満になるとアラートが発行されます。空き領域のしきい値は、表領域が大規模な場合に便利です。

ローカル管理表領域のアラートはサーバーで生成されます。ディクショナリ管理表領域の場合は、Enterprise Managerがこの機能を提供します。詳細は、「サーバー生成アラートを使用したデータベースの動作の監視」を参照してください。

新しい表領域には、次のようにアラートしきい値が割り当てられます。

- ローカル管理表領域: ローカル管理表領域を新規作成すると、データベースに定義されているデフォルトのしきい値がその表領域に割り当てられます。新しく作成されたデータベースには、警告のしきい値に85%使用済、クリティカルのしきい値に97%使用済のデフォルトが割り当てられます。新しいデータベースに対する空き領域のしきい値のデフォルトは、両方ともゼロ(無効)です。これらのデータベースのデフォルトは変更可能で、その手順については後で説明します。

- ディクショナリ管理表領域: ディクショナリ管理表領域を新規作成すると、Enterprise Managerのメトリック・カテゴリ「表領域の空き領域(MB)(ディクショナリ管理)」および「表領域使用率(%)(ディクショナリ管理)」の「その他すべて」にリストされているしきい値が割り当てられます。これらの値は、「メトリックとポリシー設定」ページで変更できます。

注意:
バージョン9.x以前から10.xにアップグレードしたデータベースでは、すべてのローカル管理表領域のアラートしきい値はデフォルトで0(ゼロ)に設定されます。この設定は、アラート・メカニズムを事実上使用禁止にして、新しく移行されたデータベースへの過剰なアラートを回避しています。

アラートしきい値の設定

各表領域には、パーセント・フルのしきい値のみ、空き領域のしきい値のみ、または同時に両方のしきい値タイプを設定できます。どちらのタイプのしきい値も、0(ゼロ)に設定すると無効になります。

理想的な警告のしきい値は、クリティカルのしきい値が発行される前に問題を解決できる時間を考慮して、早めにアラートを発行する設定です。クリティカルのしきい値は、ただちに処理してサービスの損失を回避できるよう十分早めにアラートを発行するように設定します。

ローカル管理表領域のアラートしきい値の設定方法

- 次のいずれかを実行します。

- Enterprise Managerの「表領域」ページを使用します。
手順については、『Oracle Database 2日でデータベース管理者』を参照してください。

- DBMS_SERVER_ALERT.SET_THRESHOLDパッケージ・プロシージャをコールします。
詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ディクショナリ管理表領域のアラートしきい値の設定方法

- Enterprise Managerの「表領域」ページを使用します。
手順については、『Oracle Database 2日でデータベース管理者』を参照してください。

例: ローカル管理表領域

次の例は、USERS表領域について空き領域のしきい値を10MB(警告)および2MB(クリティカル)に設定し、パーセント・フルのしきい値を無効にします。

BEGIN
DBMS_SERVER_ALERT.SET_THRESHOLD(
metrics_id              => DBMS_SERVER_ALERT.TABLESPACE_BYT_FREE,
warning_operator        => DBMS_SERVER_ALERT.OPERATOR_LE,
warning_value           => '10240',
critical_operator       => DBMS_SERVER_ALERT.OPERATOR_LE,
critical_value          => '2048',
observation_period      => 1,
consecutive_occurrences => 1,
instance_name           => NULL,
object_type             => DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE,
object_name             => 'USERS');

DBMS_SERVER_ALERT.SET_THRESHOLD(
metrics_id              => DBMS_SERVER_ALERT.TABLESPACE_PCT_FULL,
warning_operator        => DBMS_SERVER_ALERT.OPERATOR_GT,
warning_value           => '0',
critical_operator       => DBMS_SERVER_ALERT.OPERATOR_GT,
critical_value          => '0',
observation_period      => 1,
consecutive_occurrences => 1,
instance_name           => NULL,
object_type             => DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE,
object_name             => 'USERS');
END;
/

注意:
パーセント・フルのしきい値に0(ゼロ)以外の値を設定する場合は、「以上」演算子OPERATOR_GEを使用します。

データベースのデフォルトしきい値への表領域のリストア

ローカル管理表領域のアラートしきい値に明示的に値を設定した後は、その値をDBMS_SERVER_ALERT.SET_THRESHOLDを使用してNULLに設定することで、データベースのデフォルト値に戻すことができます。

データベースのデフォルトしきい値の変更

ローカルに管理されている表領域のデータベースのデフォルトしきい値を変更するには、前の例に示されているようにDBMS_SERVER_ALERT.SET_THRESHOLDを起動しますが、object_nameをNULLに設定します。データベースのデフォルトを使用するすべての表領域で、新しいデフォルトに切り替わります。

アラートの表示

アラートを表示するには、Enterprise Manager Database Controlのホームページにアクセスします。

ローカル管理表領域のアラートは、DBA_OUTSTANDING_ALERTSビューを使用して表示することもできます。詳細は、「サーバー生成アラートのデータ・ディクショナリ・ビュー」を参照してください。

制限事項

しきい値ベースのアラートには、次の制限があります。

- アラートは、オフラインまたは読取り専用モードのローカル管理表領域については発行されません。ただし、それらの表領域が読取り/書込みモードまたは使用可能になると、そのアラート・システムは再アクティブ化されます。

- 表領域をオフライン化または読取り専用モードにする場合は、しきい値を0(ゼロ)に設定して、表領域に対するアラートを使用禁止にする必要があります。後で表領域を再度オンライン化または読取り/書込みモードにする場合は、しきい値を再設定してアラートを再び使用可能にできます。

関連項目:

- サーバー生成アラートに関する一般的な詳細は、「サーバー生成アラートを使用したデータベースの動作の監視」を参照してください。

- DBMS_SERVER_ALERTパッケージのプロシージャとその使用方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 表領域内で使用されていない領域を再生する方法は、「使用できない領域の再生」を参照してください。

- リサイクル・ビン領域を再生する方法は、「リサイクル・ビン内のオブジェクトのパージ」を参照してください。

再開可能領域割当ての管理

Oracle Databaseでは、領域割当てが失敗した場合に大規模なデータベース処理を一時停止して、後で再開するための方法が提供されています。そのため、Oracle Databaseサーバーがユーザーにエラーを返すかわりに対処措置を講じることができます。エラー条件が訂正されると、一時停止していた処理が自動的に再開します。この機能のことを、再開可能領域割当てと呼びます。また、影響を受ける文のことを、再開可能文と呼びます。

この項の内容は次のとおりです。

- 再開可能領域割当ての概要

- 再開可能領域割当ての有効化および無効化

- 一時停止文の検出

- 操作一時停止アラート

- 再開可能領域割当ての例: AFTER SUSPENDトリガーの登録

再開可能領域割当ての概要

この項では、再開可能領域割当ての概要について説明します。再開可能領域割当ての動作方法および問合せ文とエラー条件の具体的な定義方法について説明します。

再開可能領域割当ての動作

再開可能領域割当ての動作の概要は、次のとおりです。詳細はこの後の各項で説明します。

1. 文が再開可能モードで実行されるのは、その文のセッションが、次のいずれかの処理によって再開可能領域割当てに対応している場合のみです。

- RESUMABLE_TIMEOUT初期化パラメータが0 (ゼロ)以外の値に設定されている場合に、ALTER SESSION ENABLE RESUMABLE文が実行前にセッション内で発行された。

- ALTER SESSION ENABLE RESUMABLE TIMEOUT timeout_value文が実行前にセッション内で発行され、timeout_valueが0 (ゼロ)以外の値である。

2. 次のいずれかの条件が成立すると、再開可能文が一時停止します(非再開可能文では、これらの条件に対応するエラーが通知されます)。

- 領域不足条件

- 最大エクステント数到達条件

- スペース割当制限超過条件。

3. 再開可能文の実行が一時停止すると、ユーザー指定の操作の実行、エラーの記録および文の実行状態の問合せを行うメカニズムがただちに動作します。再開可能文が一時停止すると、次の処理が実行されます。

- エラーがアラート・ログに記録されます。

- 一時停止された再開可能セッションのアラートが発行されます。

- ユーザーがAFTER SUSPENDシステム・イベントに対してトリガーを登録していた場合は、そのユーザー・トリガーが実行されます。ユーザー指定のPL/SQLプロシージャは、DBMS_RESUMABLEパッケージとDBA_RESUMABLEまたはUSER_RESUMABLEビューを使用して、エラー・メッセージ・データにアクセスできます。

4. 文が中断されると、自動的にトランザクションも中断されます。その結果、すべてのトランザクション・リソースが文の一時停止から再開までの間保持されます。

5. ユーザーの介入や他の問合せによってソート領域が解放されるなどの結果としてエラー条件が解決されると、一時停止していた文が自動的に実行を再開し、一時停止された再開可能セッションのアラートがクリアされます。

6. 一時停止した文は、DBMS_RESUMABLE.ABORT()プロシージャを使用して、強制的に例外を発生できます。このプロシージャは、DBAまたは文を発行したユーザーがコールできます。

7. RESUMABLE_TIMEOUT初期化パラメータまたはALTER SESSION ENABLE RESUMABLE TIMEOUT文で指定された一時停止のタイムアウト間隔は、再開可能文に対応付けられています。タイムアウト間隔内にエラー条件が解決されない場合は、タイムアウト間隔の間一時停止していた再開可能文がリストアされ、ユーザーに例外が返されます。

8. 再開可能文は、実行中に一時停止と再開を複数回繰り返すことができます。

再開可能な操作

再開可能な操作は、次のとおりです。

- 問合せ
一時領域(ソート領域)を使い果たしたSELECT文は、再開可能な実行の候補になります。Oracle Call Interface(OCI)の使用時は、OCIStmtExecute()およびOCIStmtFetch()の各コールが候補になります。

- DML
INSERT文、UPDATE文およびDELETE文が候補になります。それらを実行するために使用するインタフェースは何でもかまいません。OCI、SQLJ、PL/SQLまたは別のインタフェースを使用できます。また、外部表からのINSERT INTO...SELECTも再開可能にできます。

- インポート/エクスポート
SQL*Loaderについては、リカバリ可能なエラーの後に文が再開可能かどうかをコマンドライン・パラメータで制御します。

- DDL
次の文が、再開可能な実行の候補になります。

- CREATE TABLE ... AS SELECT

- CREATE INDEX

- ALTER INDEX ... REBUILD

- ALTER TABLE ... MOVE PARTITION

- ALTER TABLE ... SPLIT PARTITION

- ALTER INDEX ... REBUILD PARTITION

- ALTER INDEX ... SPLIT PARTITION

- CREATE MATERIALIZED VIEW

- CREATE MATERIALIZED VIEW LOG

訂正可能なエラー

訂正可能なエラーには、次の3つのクラスがあります。

- 領域不足条件
データベースの操作によって、表領域内の表、索引、一時セグメント、UNDOセグメント、クラスタ、LOB、表パーティションまたは索引パーティション用のエクステントをこれ以上取得できません。たとえば、次のエラーはこのカテゴリに属します。

ORA-01653 unable to extend table ... in tablespace ...
ORA-01654 unable to extend index ... in tablespace ...

- 最大エクステント数到達条件
表、索引、一時セグメント、UNDOセグメント、クラスタ、LOB、表パーティションまたは索引パーティション内のエクステント数が、オブジェクトで定義されている最大エクステント数に等しくなりました。たとえば、次のエラーはこのカテゴリに属します。

ORA-01631 max # extents ... reached in table ...
ORA-01632 max # extents ... reached in index ...

- スペース割当制限超過条件
ユーザーが自分に割り当てられている表領域内のスペース割当制限を超過しました。具体的には、次のエラーによって示されます。

ORA-01536 space quote exceeded for tablespace string

再開可能領域割当てと分散処理

分散環境で、ユーザーが再開可能領域割当てを有効または無効にした場合、またはDBAがRESUMABLE_TIMEOUT初期化パラメータを変更した場合、その影響を受けるのはローカルのインスタンスです。RESUMABLEはリモートで有効にできません。分散トランザクションで、リモート・インスタンスのセッションが一時停止されるのは、リモート・インスタンスがそのサイトでインスタンスまたはセッションに対してRESUMABLEをすでに有効にしている場合のみです。

パラレル実行と再開可能領域割当て

パラレル実行では、パラレル実行サーバー・プロセスの1つで訂正可能なエラーが発生した場合、そのサーバー・プロセスの実行が一時停止します。他のパラレル実行サーバー・プロセスでは、エラーが発生するまで、または一時停止したサーバー・プロセスに(直接または間接に)ブロックされるまで、個々のタスクの実行が継続されます。訂正可能なエラーが解決すると、一時停止したプロセスが実行を再開し、パラレル操作の実行は継続されます。一時停止したプロセスが終了した場合、パラレル操作は中断し、ユーザーに対してエラーが返されます。

異なるパラレル実行プロセスで、1つ以上の訂正可能なエラーが発生することがあります。この結果、AFTER SUSPENDトリガーが複数回、パラレルに発行される場合があります。また、あるパラレル実行サーバー・プロセスが一時停止中に他のパラレル実行サーバー・プロセスで訂正不可能なエラーが発生すると、一時停止していた文はただちに強制終了します。

パラレル実行については、すべてのパラレル実行コーディネータとサーバー・プロセスがDBA_RESUMABLEまたはUSER_RESUMABLEビューに独自のエントリを持っています。

再開可能領域割当ての有効化および無効化

再開可能領域割当ては、再開可能モードを有効にしたセッションの中で文を実行するときのみ可能です。

再開可能領域割当てがセッションで有効になるのは、ALTER SESSION ENABLE RESUMABLE文が実行され、そのセッションのRESUMABLE_TIMEOUT初期化パラメータが0 (ゼロ)以外の値に設定されている場合です。RESUMABLE_TIMEOUT初期化パラメータをシステム・レベルで設定すると、その設定は、タイムアウト値が指定されていないALTER SESSION ENABLE RESUMABLE文のデフォルトになります。ALTER SESSION ENABLE RESUMABLE文でタイムアウト値を指定すると、システム・デフォルトがオーバーライドされます。

ALTER SESSION ENABLE RESUMABLE文を実行しても、次の場合はセッションで再開可能領域割当てが無効になります。

- セッションでALTER SESSION ENABLE RESUMABLE文が実行されない場合。

- セッションでALTER SESSION DISABLE RESUMABLE文が実行された場合。

- セッションでALTER SESSION ENABLE RESUMABLE文が実行され、タイムアウト値が0 (ゼロ)の場合。

注意:
一時停止した文はなんらかのシステム・リソースを保持している可能性があるため、ユーザーが再開可能領域割当てを有効にして、再開可能文を実行するには、RESUMABLEシステム権限が付与されている必要があります。

RESUMABLE_TIMEOUT初期化パラメータの設定

RESUMABLE_TIMEOUT初期化パラメータを設定して、デフォルトのシステム全体のタイムアウト間隔を指定できます。たとえば、初期化パラメータ・ファイルでRESUMABLE_TIMEOUTパラメータを次のように設定すると、タイムアウト間隔は1時間に設定されます。

RESUMABLE_TIMEOUT  = 3600

このパラメータが0 (ゼロ)に設定された場合、タイムアウト値を指定しないでALTER SESSION ENABLE RESUMABLE文を実行するセッションでも、再開可能領域割当ては無効になります。

ALTER SYSTEM SET文を使用して、このパラメータの値をシステム・レベルで変更することもできます。たとえば、次の文では、タイムアウト値を指定しないでALTER SESSION ENABLE RESUMABLE文を実行するすべてのセッションに対して再開可能領域割当てを無効にします。

ALTER SYSTEM SET RESUMABLE_TIMEOUT=0;

ALTER SESSIONを使用した再開可能領域割当ての有効化と無効化

セッション内で、ユーザーはALTER SESSION SET文を発行してRESUMABLE_TIMEOUT初期化パラメータを設定し、再開可能領域割当てを有効にしてタイムアウト値を変更するか、または再開可能モードを無効にできます。

次のSQL文を使用して、デフォルトのシステムRESUMABLE_TIMEOUT値でセッションの再開可能モードを有効化できます。

ALTER SESSION ENABLE RESUMABLE;

再開可能モードを無効化するには、次の文を使用します。

ALTER SESSION DISABLE RESUMABLE;

新しいセッションのデフォルトの再開可能モードは無効です。

タイムアウト間隔や、再開可能文の識別に使用する名前も指定できます。次の項では、各操作について説明します。

関連項目:
「LOGONトリガーを使用したデフォルト再開可能モードの設定」

タイムアウト間隔の指定

介入操作が発生しなかった場合に一時停止した文がエラーとなるタイムアウト間隔は、再開可能モードを有効化するときに指定できます。次の文は、再開可能トランザクションが3600秒後にタイムアウトし、エラーになることを指定します。

ALTER SESSION ENABLE RESUMABLE TIMEOUT 3600;

TIMEOUTの値は、別のALTER SESSION ENABLE RESUMABLE文や他の手段によって変更されるまで、またはセッションが終了するまで有効です。RESUMABLE_TIMEOUT初期化パラメータが設定されていない場合、ENABLE RESUMABLE TIMEOUT句を使用して再開可能モードを有効にするときのデフォルトのタイムアウト間隔は7200秒になります。

関連項目:
再開可能領域割当てのタイムアウト間隔を変更するその他の方法の詳細は、「RESUMABLE_TIMEOUT初期化パラメータの設定」を参照してください。

再開可能文の命名

再開可能文は、名前で識別するように設定できます。次の文は、再開可能文に名前を割り当てます。

ALTER SESSION ENABLE RESUMABLE TIMEOUT 3600 NAME 'insert into table';

NAMEの値は、別のALTER SESSION ENABLE RESUMABLE文によって変更されるまで、またはセッションが終了するまで有効です。NAMEのデフォルト値は、'User username(userid), Session sessionid, Instance instanceid'です。

文の名前は、DBA_RESUMABLEビューおよびUSER_RESUMABLEビューで再開可能文を識別する際に使用します。

LOGONトリガーを使用したデフォルト再開可能モードの設定

RESUMABLE_TIMEOUT初期化パラメータを設定する以外に、デフォルトの再開可能モードを設定するもう1つの方法は、データベース・レベルのLOGONトリガーを登録して、再開可能を有効化してタイムアウト間隔を設定するように、ユーザーのセッションを変更する方法です。

注意:
再開可能文のデフォルトのモードとタイムアウトを変更する登録済トリガーが複数ある場合、その結果は予測できません。これは、トリガーの起動順序がOracle Databaseで保証されていないためです。

一時停止文の検出

再開可能文が一時停止するとき、クライアントにはエラーは通知されません。訂正処理を実行するため、Oracle Databaseではユーザーにエラーを通知して状況に関する情報を提供するかわりの手段が提供されています。

ユーザーへの通知: AFTER SUSPENDシステム・イベントおよびトリガー

再開可能文で訂正可能なエラーが発生すると、システムは内部的にAFTER SUSPENDシステム・イベントを生成します。ユーザーは、このイベントに対するトリガーをデータベース・レベルとスキーマ・レベルの両方で登録できます。ユーザーがこのシステム・イベントを処理するトリガーを登録した場合、トリガーはSQL文が一時停止した後に実行されます。

AFTER SUSPENDトリガー内部で実行されたSQL文は、再開不可能であり、かつ自律型です。トリガー内部で開始されたトランザクションは、SYSTEMロールバック・セグメントを使用します。これらの条件が課されるのは、デッドロックを回避し、文と同じエラー条件に直面する可能性を少なくするためです。

ユーザーはUSER_RESUMABLEビュー、DBA_RESUMABLEビューまたはDBMS_RESUMABLE.SPACE_ERROR_INFOファンクションをトリガー内部で使用して、再開可能文に関する情報を取得できます。

また、トリガーではDBMS_RESUMABLEパッケージをコールして、一時停止した文の終了や再開可能タイムアウト値の変更を実行できます。次の例では、DBMS_RESUMABLEをコールしてタイムアウトを3時間に設定する、システム全体で有効なAFTER SUSPENDトリガーを作成することによって、デフォルトのシステム・タイムアウトを変更します。

CREATE OR REPLACE TRIGGER resumable_default_timeout
AFTER SUSPEND
ON DATABASE
BEGIN
DBMS_RESUMABLE.SET_TIMEOUT(10800);
END;
/

関連項目:
トリガーとシステム・イベントの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

ビューを使用した一時停止文情報の取得

次のビューを問い合せることにより、再開可能文の状態に関する情報を取得できます。

ビュー

説明

DBA_RESUMABLE
USER_RESUMABLE

これらのビューには、現在実行中または一時停止しているすべての再開可能文に関する行が含まれます。これらは、再開可能文の実行状態を監視したり、再開可能文に関する特定の情報を取得するために、DBA、AFTER SUSPENDトリガーまたは別のセッションが使用できます。

V$SESSION_WAIT

ある文が一時停止すると、その文を起動したセッションは待機状態になります。このビューには、「文が一時停止され、エラーのクリアを待機しています」という内容のEVENT列を持つセッションに対して1行が挿入されます。

関連項目:
これらのビューに含まれる列の詳細は、『Oracle Databaseリファレンス』を参照してください。

DBMS_RESUMABLEパッケージの使用方法

DBMS_RESUMABLEパッケージは、再開可能領域割当ての管理に役立ちます。次のプロシージャを起動できます。

プロシージャ

説明

ABORT(sessionID)

このプロシージャは、一時停止した再開可能文を強制終了します。パラメータsessionIDは、文が実行されているセッションIDです。パラレルDML/DDLの場合、sessionIDはパラレルDML/DDLに参加している任意のセッションIDです。
Oracle Databaseでは、ABORT操作が常に正常終了することが保証されています。これは、AFTER SUSPENDトリガーの内部からでも外部からでもコールできます。

ABORTのコール元は、sessionIDを持つセッションの所有者、ALTER SYSTEM権限を持っているユーザー、DBA権限を持っているユーザーのいずれかである必要があります。

GET_SESSION_TIMEOUT(sessionID)

このファンクションは、sessionIDを持つセッションで設定されている再開可能領域割当ての現行のタイムアウト値を返します。タイムアウトは秒数で返されます。セッションが存在しない場合、このファンクションは-1を返します。

SET_SESSION_TIMEOUT(sessionID, timeout)

このプロシージャは、sessionIDを持つセッションに対して再開可能領域割当てのタイムアウト間隔を設定します。パラメータtimeoutの単位は秒数です。新しいtimeout設定は、即時にセッションに適用されます。セッションが存在しない場合は何も起こりません。

GET_TIMEOUT()

このファンクションは、現行セッションで設定されている再開可能領域割当ての現行のtimeout値を返します。戻される値は秒で示されます。

SET_TIMEOUT(timeout)

このプロシージャは、現行セッションに対して再開可能領域割当てのtimeout値を設定します。パラメータtimeoutの単位は秒数です。新しいタイムアウト設定はセッションに即時適用されます。

関連項目:
DBMS_RESUMABLEパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

操作一時停止アラート

再開可能セッションが一時停止されると、操作を完了するためにリソースを割り当てる必要があるオブジェクトに対して、操作一時停止アラートが発行されます。リソースが割り当てられて操作が完了すると、操作一時停止アラートはクリアされます。システム生成アラートの詳細は、「表領域のアラートの管理」を参照してください。

再開可能領域割当ての例: AFTER SUSPENDトリガーの登録

次の例では、システム全体で有効なAFTER SUSPENDトリガーを作成し、ユーザーSYSとしてデータベース・レベルで登録します。任意のセッションで再開可能文が一時停止すると、このトリガーは次の2つのうちどちらかの処理を実行します。

- UNDOセグメントが領域上限に達した場合は、メッセージがDBAに送られ、文が強制終了します。

- 他のリカバリ可能なエラーが発生した場合には、タイムアウト間隔が8時間にリセットされます。

この例で使用する文を次に示します。

CREATE OR REPLACE TRIGGER resumable_default
AFTER SUSPEND
ON DATABASE
DECLARE
/* declare transaction in this trigger is autonomous */
/* this is not required because transactions within a trigger
are always autonomous */
PRAGMA AUTONOMOUS_TRANSACTION;
cur_sid           NUMBER;
cur_inst          NUMBER;
errno             NUMBER;
err_type          VARCHAR2;
object_owner      VARCHAR2;
object_type       VARCHAR2;
table_space_name  VARCHAR2;
object_name       VARCHAR2;
sub_object_name   VARCHAR2;
error_txt         VARCHAR2;
msg_body          VARCHAR2;
ret_value         BOOLEAN;
mail_conn         UTL_SMTP.CONNECTION;
BEGIN
-- Get session ID
SELECT DISTINCT(SID) INTO cur_SID FROM V$MYSTAT;

-- Get instance number
cur_inst := userenv('instance');

-- Get space error information
ret_value :=
DBMS_RESUMABLE.SPACE_ERROR_INFO(err_type,object_type,object_owner,
table_space_name,object_name, sub_object_name);
/*
-- If the error is related to undo segments, log error, send email
-- to DBA, and abort the statement. Otherwise, set timeout to 8 hours.
--
-- sys.rbs_error is a table which is to be
-- created by a DBA manually and defined as
-- (sql_text VARCHAR2(1000), error_msg VARCHAR2(4000),
-- suspend_time DATE)
*/

IF OBJECT_TYPE = 'UNDO SEGMENT' THEN
/* LOG ERROR */
INSERT INTO sys.rbs_error (
SELECT SQL_TEXT, ERROR_MSG, SUSPEND_TIME
FROM DBMS_RESUMABLE
WHERE SESSION_ID = cur_sid AND INSTANCE_ID = cur_inst
);
SELECT ERROR_MSG INTO error_txt FROM DBMS_RESUMABLE
WHERE SESSION_ID = cur_sid and INSTANCE_ID = cur_inst;

-- Send email to receipient through UTL_SMTP package
msg_body:='Subject: Space Error Occurred

Space limit reached for undo segment ' || object_name ||
on ' || TO_CHAR(SYSDATE, 'Month dd, YYYY, HH:MIam') ||
'. Error message was ' || error_txt;

mail_conn := UTL_SMTP.OPEN_CONNECTION('localhost', 25);
UTL_SMTP.HELO(mail_conn, 'localhost');
UTL_SMTP.MAIL(mail_conn, 'sender@localhost');
UTL_SMTP.RCPT(mail_conn, 'recipient@localhost');
UTL_SMTP.DATA(mail_conn, msg_body);
UTL_SMTP.QUIT(mail_conn);

-- Abort the statement
DBMS_RESUMABLE.ABORT(cur_sid);
ELSE
-- Set timeout to 8 hours
DBMS_RESUMABLE.SET_TIMEOUT(28800);
END IF;

/* commit autonomous transaction */
COMMIT;
END;
/

使用できない領域の再生

この項では、使用できない領域の再生方法を説明し、再生に使用できる領域があるセグメントを特定するためのOracle Databaseコンポーネントである、セグメント・アドバイザの概要も説明します。この章では、次の項目について説明します。

- 再生可能な未使用領域の理解

- セグメント・アドバイザの使用

- オンラインによるデータベース・セグメントの縮小

- 未使用領域の割当て解除

再生可能な未使用領域の理解

時間の経過とともに、表領域内のオブジェクトを更新および削除すると、新しいデータに対して個別に再利用するには不十分な小さい空き領域が作成されます。このような空き領域は、断片化された空き領域と呼ばれます。

オブジェクトに断片化された空き領域があると、結果的に多くの無駄な領域が生じ、データベースのパフォーマンスに影響を与える場合があります。断片化を解消して領域を再生するには、オンラインによるセグメントの縮小を実行することをお薦めします。このプロセスは、最高水位標の下の断片化された空き領域を統合し、セグメントを圧縮します。圧縮すると最高水位標が移動し、その結果、最高水位標の上に新しい空き領域ができます。その後、この最高水位標よりも上の領域は、割当て解除されます。セグメントは、この操作の開始から終了までの大半で、問合せおよびDMLを使用でき、特別なディスク領域の割当ては不要です。

オンラインによるセグメントの縮小で利点を得られるセグメントを特定するには、セグメント・アドバイザを使用します。セグメント・アドバイザは、自動セグメント領域管理(ASSM)を備えたローカル管理表領域のセグメントに対してのみ使用できます。調査可能なセグメントの種類については、他にも制限があります。詳細は、「オンラインによるデータベース・セグメントの縮小」を参照してください。

再生可能な領域を含む表がオンラインによるセグメントの縮小に適していない場合、または領域の再生中に表の論理属性または物理属性を変更する場合は、セグメントの縮小にかわる手段として、表のオンライン再定義を使用できます。オンライン再定義は再編成とも呼ばれます。オンライン再定義は、オンラインによるセグメントの縮小とは異なり、別のディスク領域を割り当てる必要があります。詳細は、「表のオンライン再定義」を参照してください。

セグメント・アドバイザの使用

セグメント・アドバイザは、再生に使用できる領域があるセグメントを特定します。自動ワークロード・リポジトリ(AWR)の使用状況と増加に関する統計情報が調べられ、セグメントのデータがサンプリングされて、分析が実行されます。メンテナンス・ウィンドウの間に自動化メンテナンス・タスクとして実行されるように構成されていますが、オンデマンド(手動)で実行することもできます。セグメント・アドバイザの自動化メンテナンス・タスクのことを、自動セグメント・アドバイザと呼びます。

セグメント・アドバイザは、次の種類のアドバイスを生成します。

- セグメント・アドバイザにより、オブジェクトにかなりの量の空き領域があることが判断されると、オンラインによるセグメントの縮小が提案されます。自動セグメント領域管理のない表領域内の表の場合など、オブジェクトがセグメントの縮小に適さない表である場合は、オンラインによる表の再定義が提案されます。

- OLTP圧縮方法を使用して表を圧縮することで効果が期待できるとセグメント・アドバイザが判断した場合、そのことを推奨事項として表示します。(自動セグメント・アドバイザの場合のみ。「自動セグメント・アドバイザを参照してください。)

- セグメント・アドバイザにより、特定のしきい値を超える行連鎖のある表が検出されると、表に過剰な連鎖行があることが記録されます。

注意:
セグメント・アドバイザによるフラグ設定の対象は、行を長くする更新によって生じた行連鎖のタイプのみです。

領域管理のアラートを受け取った場合、または領域の再生を決定した場合は、セグメント・アドバイザを開始してください。

セグメント・アドバイザを使用する手順

1. 自動セグメント・アドバイザの結果を確認します。
自動セグメント・アドバイザを理解するには、この後の「自動セグメント・アドバイザ」を参照してください。結果の表示方法の詳細は、「セグメント・アドバイザの結果の表示」を参照してください。

2. (オプション)セグメント・アドバイザを手動で再実行し、個々のセグメントの更新結果を取得します。
この後の「手動によるセグメント・アドバイザの実行」を参照してください。

自動セグメント・アドバイザ

自動セグメント・アドバイザは、すべてのメンテナンス・ウィンドウ内で実行するように構成されている自動化メンテナンス・タスクです。

自動セグメント・アドバイザは、すべてのデータベース・オブジェクトを分析するわけではありません。かわりに、データベース統計を調査し、セグメント・データをサンプリングした後、次のような分析対象オブジェクトを選択します。

- 領域のクリティカルまたは警告のしきい値を超えた表領域

- アクティビティが最も多いセグメント

- 増加率が最も高いセグメント

また、自動セグメント・アドバイザでは、OLTP圧縮方法で圧縮した場合に節約できる領域の大きさを判断するために、10MB以上で、索引が3つ以上存在する表が評価されます。

分析対象オブジェクトが選択されても、セグメント・アドバイザがオブジェクトを処理する前にメンテナンス・ウィンドウが終了する場合、そのオブジェクトは、自動セグメント・アドバイザの次回の実行に組み込まれます。

自動セグメント・アドバイザによって分析対象として選択された表領域とセグメントのセットは変更できません。ただし、自動セグメント・アドバイザのタスクの有効化または無効化、自動セグメント・アドバイザの実行予定回数、または自動化メンテナンス・タスクのシステム・リソース使用率は変更できます。詳細は、「自動セグメント・アドバイザの構成」を参照してください。

関連項目:

- 「セグメント・アドバイザの結果の表示」

- 第26章「自動データベース・メンテナンス・タスクの管理」

- OLTP圧縮の詳細は、「表圧縮の使用」を参照してください。

手動によるセグメント・アドバイザの実行

セグメント・アドバイザは、Enterprise ManagerまたはPL/SQLパッケージのプロシージャ・コールを使用して、いつでも手動で実行できます。セグメント・アドバイザを手動で実行する理由には、次のものがあります。

- 自動セグメント・アドバイザが選択しなかった表領域またはセグメントを分析するため。

- 個々の表領域またはセグメントを再度分析して、最新の推奨事項を入手するため。

セグメント・アドバイザには、3種類のレベルでアドバイスを要求できます。

- セグメント・レベル: 非パーティション表、パーティション表のパーティションまたはサブパーティション、索引、またはLOB列など、単一のセグメントに対してアドバイスが生成されます。

- オブジェクト・レベル: 表や索引など、オブジェクト全体についてアドバイスが生成されます。オブジェクトがパーティション化されている場合は、オブジェクトのすべてのパーティションに対してアドバイスが生成されます。また、Enterprise Managerからセグメント・アドバイザを手動で実行する場合は、表の索引やLOBセグメントなど、オブジェクトの依存オブジェクトについてアドバイスを要求できます。

- 表領域レベル: 表領域のすべてのセグメントに対してアドバイスが生成されます。

表19-2にあるOBJECT_TYPE列は、アドバイスを要求できるオブジェクトのタイプを示しています。

Enterprise Managerを使用した手動によるセグメント・アドバイザの実行

Enterprise Managerを使用してセグメント・アドバイザを手動で実行するには、OEM_ADVISORロールが付与されている必要があります。セグメント・アドバイザを実行するには、次の2つの方法があります。

- セグメント・アドバイザ・ウィザードの使用
この方法を使用すると、表領域レベルまたはオブジェクト・レベルでアドバイスを要求できます。オブジェクト・レベルでは、表、索引、表パーティションおよび索引パーティションについてアドバイスを要求できます。

- スキーマ・オブジェクトを表示するページでの「セグメント・アドバイザの実行」コマンドの使用。
たとえば、(「スキーマ」ページからアクセス可能な)「表」ページに表のリストを表示する場合は、表を選択して「アクション」メニューから「セグメント・アドバイザの実行」コマンドを選択します。

図19-1 「表」ページ

この方法では、スキーマ・オブジェクトの依存オブジェクトをセグメント・アドバイザの実行対象に含めることができます。たとえば、表を選択して「セグメント・アドバイザの実行」コマンドを選択すると、パーティション、索引セグメント、LOBセグメントなど、表の依存オブジェクトが表示されます。依存オブジェクトを選択することで、そのオブジェクトを実行対象に指定できます。

両方の場合に、Enterprise Managerは、Oracle Database Schedulerジョブとしてセグメント・アドバイザ・タスクを作成します。即座に実行するようにジョブをスケジュールすることも、スケジューラが提供する高度なスケジューリング機能を利用することもできます。

セグメント・アドバイザ・ウィザードを使用してセグメント・アドバイザを手動で実行する手順

1. データベース・ホームページから、「関連リンク」の下の「アドバイザ・セントラル」をクリックします。
「アドバイザ・セントラル」ページが表示されます。(図19-2を参照してください。)

2. 「アドバイザ」の下の「セグメント・アドバイザ」をクリックします。
セグメント・アドバイザ・ウィザードの最初のページが表示されます。

3. セグメント・アドバイザのジョブをスケジュールするウィザードの各手順に従い、ウィザードの最終ページで「発行」をクリックします。
「アドバイザ・セントラル」ページが表示され、「結果」ヘッダーの下のリストの最初に新しいセグメント・アドバイザ・ジョブが表示されます。ジョブ・ステータスは、SCHEDULEDまたはRUNNINGになります。(自分のジョブが表示されない場合は、リストの上の検索フィールドを使用して表示してください。)

4. ジョブのステータスをチェックします。COMPLETEDでない場合は、ページの上部にある「リフレッシュ」ボタンを繰り返しクリックします。(ブラウザのリフレッシュ・アイコンは使用しないでください。)
ジョブ・ステータスがCOMPLETEDに変わった場合は、「選択」列をクリックしてジョブを選択し、「結果の表示」をクリックします。

図19-2 「アドバイザ・セントラル」ページ

関連項目:
スケジューラの高度なスケジューリング機能の詳細は、第29章「Oracle Schedulerを使用したジョブのスケジューリング」を参照してください。

PL/SQLを使用した手動によるセグメント・アドバイザの実行

セグメント・アドバイザは、DBMS_ADVISORパッケージを使用して実行することもできます。パッケージ・プロシージャを使用してセグメント・アドバイザのタスクを作成し、タスクの引数を設定してからタスクを実行します。そのためには、ADVISOR権限が必要です。表19-1に、セグメント・アドバイザに関連するプロシージャを示します。これらのプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

表19-1 セグメント・アドバイザに関連するDBMS_ADVISORパッケージ・プロシージャ

パッケージ・プロシージャ名

説明

CREATE_TASK

このプロシージャを使用して、セグメント・アドバイザのタスクを作成します。ADVISOR_NAMEパラメータの値に、'Segment Advisor'を指定します。

CREATE_OBJECT

このプロシージャを使用して、セグメント領域のアドバイス対象オブジェクトを識別します。このプロシージャのパラメータ値は、オブジェクト・タイプによって異なります。表19-2に、各オブジェクト・タイプのパラメータ値を示します。

注意: IOTオーバーフロー・セグメントについてアドバイスを要求するには、TABLE、TABLE PARTITIONまたはTABLE SUBPARTITIONのオブジェクト型を使用します。次の問合せを使用して、IOTのオーバーフロー・セグメントを検索し、CREATE_OBJECTで使用するオーバーフロー・セグメントの表名を判断します。

select table_name, iot_name, iot_type from dba_tables;

SET_TASK_PARAMETER

このプロシージャを使用して、必要なセグメント・アドバイスを指定します。表19-3に、このプロシージャに関連する入力パラメータを示します。リストされていないパラメータは、セグメント・アドバイザでは使用されません。

EXECUTE_TASK

このプロシージャを使用して、セグメント・アドバイザのタスクを実行します。

表19-2 DBMS_ADVISOR.CREATE_OBJECTの入力

入力パラメータ

OBJECT_TYPE

ATTR1

ATTR2

ATTR3

ATTR4

TABLESPACE

表領域名

NULL

NULL

未使用。NULLを指定します。

TABLE

スキーマ名

表名

NULL

未使用。NULLを指定します。

INDEX

スキーマ名

索引名

NULL

未使用。NULLを指定します。

TABLE PARTITION

スキーマ名

表名

表パーティション名

未使用。NULLを指定します。

INDEX PARTITION

スキーマ名

索引名

索引パーティション名

未使用。NULLを指定します。

TABLE SUBPARTITION

スキーマ名

表名

表サブパーティション名

未使用。NULLを指定します。

INDEX SUBPARTITION

スキーマ名

索引名

索引サブパーティション名

未使用。NULLを指定します。

LOB

スキーマ名

セグメント名

NULL

未使用。NULLを指定します。

LOB PARTITION

スキーマ名

セグメント名

LOBパーティション名

未使用。NULLを指定します。

LOB SUBPARTITION

スキーマ名

セグメント名

LOBサブパーティション名

未使用。NULLを指定します。

表19-3 DBMS_ADVISOR.SET_TASK_PARAMETERの入力

入力パラメータ

説明

可能な値

デフォルト値

time_limit

セグメント・アドバイザを実行する時間制限を秒単位で指定します。

任意の秒数。

UNLIMITED

recommend_all

セグメント・アドバイザですべてのセグメントについて結果を生成するかどうかを指定します。

TRUE: 領域再生の推奨事項に関係なく、指定されたすべてのセグメントに対して結果が生成されます。

FALSE: 領域再生の推奨事項を生成するオブジェクトに対してのみ結果が生成されます。

TRUE

例: 次の例は、DBMS_ADVISORプロシージャを使用して、サンプル表hr.employeesに対してセグメント・アドバイザを実行する方法を示しています。これらのパッケージ・プロシージャを実行するユーザーには、そのパッケージに対するオブジェクトのEXECUTE権限、またはADVISORシステム権限が必要です。

オブジェクト型TABLEをDBMS_ADVISOR.CREATE_OBJECTに渡すと、オブジェクト・レベルを要求したことになります。表がパーティション化されていない場合は、表セグメントが分析されます(索引またはLOBセグメントなどの依存セグメントは対象外です)。表がパーティション化されている場合は、すべての表パーティションが分析され、個別に結果と推奨事項が生成されます。

variable id number;
begin
declare
name varchar2(100);
descr varchar2(500);
obj_id number;
begin
name:='Manual_Employees';
descr:='Segment Advisor Example';

dbms_advisor.create_task (
advisor_name     => 'Segment Advisor',
task_id          => :id,
task_name        => name,
task_desc        => descr);

dbms_advisor.create_object (
task_name        => name,
object_type      => 'TABLE',
attr1            => 'HR',
attr2            => 'EMPLOYEES',
attr3            => NULL,
attr4            => NULL,
attr5            => NULL,
object_id        => obj_id);

dbms_advisor.set_task_parameter(
task_name        => name,
parameter        => 'recommend_all',
value            => 'TRUE');

dbms_advisor.execute_task(name);
end;
end;
/

セグメント・アドバイザの結果の表示

セグメント・アドバイザでは、様々な種類の結果(推奨事項、結果、処置、オブジェクト)が作成されます。次の方法で結果を表示できます。

- Enterprise Managerの使用

- DBA_ADVISOR_*ビューの問合せ

- DBMS_SPACE.ASA_RECOMMENDATIONSプロシージャのコール

表19-4に、様々な種類の結果および関連するDBA_ADVISOR_*ビューを示します。

表19-4 セグメント・アドバイザの結果の種類

結果の種類

関連するビュー

説明

推奨事項

DBA_ADVISOR_RECOMMENDATIONS

セグメントの縮小、再編成または圧縮が効果的な場合は、そのセグメントに対して推奨事項が生成されます。表19-5に、生成される結果および推奨事項の例を示します。

結果

DBA_ADVISOR_FINDINGS

結果とは、分析対象のセグメントでセグメント・アドバイザが観察した内容のレポートです。結果には、分析対象の各セグメントの使用領域と空き領域の統計情報が含まれます。すべての結果が推奨事項になるわけではありません。(推奨事項は少数でも、多くの結果がある場合もあります。)セグメント・アドバイザをPL/SQLを使用して手動で実行する際に、SET_TASK_PARAMETERプロシージャのrecommend_allを'TRUE'に指定すると、セグメントに対する推奨事項があってもなくても、分析の対象になる各セグメントに対する結果が生成されます。行連鎖アドバイスの場合、自動セグメント・アドバイザは結果のみを生成し、推奨事項は生成しません。自動セグメント・アドバイザに領域の再生に関する推奨事項がない場合、結果は生成されません。ただし、OLTP圧縮の効果が期待できる表に対しては、自動セグメント・アドバイザの結果が生成される場合があります。

処置

DBA_ADVISOR_ACTIONS

すべての推奨事項は、セグメントの縮小、オンライン再定義(再編成)または圧縮の実施を提案する処置に関連付けられます。DBA_ADVISOR_ACTIONSビューには、セグメントの縮小または表の圧縮を実行するために使用できるSQL、またはオブジェクトを再編成するための提案が表示されます。

オブジェクト

DBA_ADVISOR_OBJECTS

すべての結果、推奨事項および処置はオブジェクトに関連付けられています。表領域やパーティション表の場合のように、複数のセグメントをセグメント・アドバイザが分析する場合、分析対象のセグメントごとに1つのエントリがDBA_ADVISOR_OBJECTSビューに作成されます。表19-2には、分析対象のセグメントに関する情報を問い合せるための、このビューの列が定義されています。結果、推奨事項および処置のビューのオブジェクトを、このビューのオブジェクトと関係づけることができます。

関連項目:

- DBA_ADVISOR_*ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- DBMS_SPACE.ASA_RECOMMENDATIONSファンクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

Enterprise Managerを使用したセグメント・アドバイザの結果の表示

Oracle Enterprise Managerでは、自動セグメント・アドバイザの実行とセグメント・アドバイザの手動実行の両方についてセグメント・アドバイザの結果を表示できます。次の種類の結果を表示できます。

- すべての推奨事項(自動および手動によるセグメント・アドバイザの複数の実行)

- 自動セグメント・アドバイザの最新の実行での推奨事項

- 特定の実行での推奨事項

- 行連鎖の結果

自動セグメント・アドバイザの最新の実行で分析されたセグメントを一覧に表示することもできます。

Enterprise Managerを使用してセグメント・アドバイザの結果を表示する手順(すべての実行)

1. データベース・ホームページで、「領域サマリー」ヘッダーの下にある「セグメント・アドバイザ推奨」タイトルの横の数値リンクをクリックします。

「セグメント・アドバイザ推奨」ページが表示されます。推奨事項は、表領域別に編成されます。

図19-3 「セグメント・アドバイザ推奨」ページ

2. 推奨事項が提示されている場合は、表領域を選択し、次に「推奨事項の詳細」をクリックします。
「推奨事項の詳細」ページが表示されます。このページから推奨事項アクティビティ(縮小または再編成)を開始できます。

図19-4 「推奨事項の詳細」ページ

注意:
LOBなどのオブジェクトによっては、指定した「縮小」オプションを使用してサポートされません。かわりに、セグメント・アドバイザを使用して、再利用可能領域を確認し、縮小操作は手動で実行します。

ヒント:
リストのエントリは、再生可能領域の大きい順にソートされています。列ヘッダーをクリックすると、ソート順を変更したり、昇順から降順に変更できます。

Enterprise Managerを使用してセグメント・アドバイザの結果を表示する手順(自動セグメント・アドバイザの最新の実行)

1. データベース・ホームページで、「領域サマリー」ヘッダーの下にある「セグメント・アドバイザ推奨」タイトルの横の数値リンクをクリックします。
「セグメント・アドバイザ推奨」ページが表示されます。(図19-3を参照してください。)

2. 「表示」リストで、「最後の自動実行からの推奨事項」を選択します。

3. 推奨事項が提示されている場合は、表領域を選択し、「推奨事項の詳細」をクリックします。
「推奨事項の詳細」ページが表示されます。(図19-4を参照してください。)このページから推奨事項アクティビティ(縮小または再編成)を開始できます。

注意:
LOBなどのオブジェクトによっては、指定した「縮小」オプションを使用してサポートされません。かわりに、セグメント・アドバイザを使用して、再利用可能領域を確認し、縮小操作は手動で実行します。

Enterprise Managerを使用してセグメント・アドバイザの結果を表示する手順(特定の実行)

1. 「アドバイザ・セントラル」ページから開始します。
Enterprise Managerウィザードでセグメント・アドバイザを実行した場合は、セグメント・アドバイザのタスクを発行した後に「アドバイザ・セントラル」ページが表示されます。それ以外の場合は、データベース・ホームページの「関連リンク」の下にある「アドバイザ・セントラル」をクリックして、このページを表示します。

2. タスクが「結果」ヘッダーの下のリストに表示されていることを確認します。タスクがない場合は、次の手順を実行します(図19-2を参照)。

1. ページの「検索」セクションの「アドバイザ・タスク」の下にある「アドバイザ・タイプ」リストから「セグメント・アドバイザ」を選択します。

2. 「アドバイザ実行」リストで、「すべて」または該当する期間を選択します。

3. (オプション)タスク名を入力します。

4. 「実行」をクリックします。
「結果」セクションにセグメント・アドバイザのタスクが表示されます。

3. ジョブのステータスをチェックします。COMPLETEDでない場合は、ページの上部にある「リフレッシュ」ボタンを、タスクのステータスがCOMPLETEDになるまでクリックします。(ブラウザのリフレッシュ・アイコンは使用しないでください。)

4. タスク名をクリックします。
セグメント・アドバイザのタスクのページに、表領域別に編成された推奨事項が表示されます。

5. リストで表領域を選択して、「推奨事項の詳細」をクリックします。
「推奨事項の詳細」ページが表示されます。(図19-4を参照してください。)このページから推奨事項アクティビティ(縮小または再編成)を開始できます。

行連鎖の結果を表示する手順

1. データベース・ホームページで、「領域サマリー」ヘッダーの下にある「セグメント・アドバイザ推奨」タイトルの横の数値リンクをクリックします。
「セグメント・アドバイザ推奨」ページが表示されます。(図19-3を参照してください。)

2. 「関連リンク」ヘッダーの下にある「行チェーン分析」をクリックします。
「行チェーン分析」ページには、連鎖行があるすべてのセグメントと各連鎖行の割合が表示されます。

DBA_ADVISOR_*ビューの問合せによるセグメント・アドバイザの結果の表示

表19-5のヘッダーには、セグメント・アドバイザからの出力が表示されるDBA_ADVISOR_*ビューの列が示されます。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。この表に、考えられる出力の要約を示します。また、表19-2に、分析されたセグメントの情報が表示されるDBA_ADVISOR_OBJECTSビューの列を示します。

DBA_ADVISOR_*ビューを問い合せる前に、DBA_ADVISOR_TASKSのSTATUS列を問い合せることで、セグメント・アドバイザのタスクが完了していることを確認できます。

select task_name, status from dba_advisor_tasks
where owner = 'STEVE' and advisor_name = 'Segment Advisor';

TASK_NAME                      STATUS
------------------------------ -----------
Manual Employees               COMPLETED

次の例は、ユーザーSTEVEが発行したセグメント・アドバイザのすべての実行から結果を取得するために、DBA_ADVISOR_*ビューを問い合せる方法を示しています。

select af.task_name, ao.attr2 segname, ao.attr3 partition, ao.type, af.message
from dba_advisor_findings af, dba_advisor_objects ao
where ao.task_id = af.task_id
and ao.object_id = af.object_id
and ao.owner = 'STEVE';

TASK_NAME          SEGNAME      PARTITION       TYPE             MESSAGE
------------------ ------------ --------------- ---------------- --------------------------
Manual_Employees   EMPLOYEES                    TABLE            The free space in the obje
ct is less than 10MB.

Manual_Salestable4 SALESTABLE4  SALESTABLE4_P1  TABLE PARTITION  Perform shrink, estimated
savings is 74444154 bytes.

Manual_Salestable4 SALESTABLE4  SALESTABLE4_P2  TABLE PARTITION  The free space in the obje
ct is less than 10MB.

表19-5 セグメント・アドバイザの結果: 要約

DBA_ADVISOR_FINDINGSのMESSAGE列

DBA_ADVISOR_FINDINGSのMORE_INFO列

DBA_ADVISOR_RECOMMENDATIONSのBENEFIT_TYPE列

DBA_ADVISOR_ACTIONSのATTR1列

情報が不十分なため、推奨事項を作成できません。

-

-

-

オブジェクト内の空き領域が10MB以下です。

割当領域: xxx: 使用領域: xxx: 再利用可能領域 : xxx

-

-

オブジェクト内には空き領域がありますが、...のため縮小できません。

割当領域: xxx: 使用領域: xxx: 再利用可能領域 : xxx

-

-

オブジェクト内の空き領域は前回のエクステントのサイズ未満です。

割当領域: xxx: 使用領域: xxx: 再利用可能領域 : xxx

-

-

xxxバイトの節約が予測されるため、縮小を実行してください。

割当領域: xxx: 使用領域: xxx: 再利用可能領域 : xxx

xxxバイトの節約が予測されるため、縮小を実行してください。

実行するコマンド。例: ALTER object SHRINK SPACE;)

表schema.tableの行移動を有効にして縮小を実行してください。xxxバイトの節約が予測されるためです。

割当領域: xxx: 使用領域: xxx: 再利用可能領域 : xxx

表schema.tableの行移動を有効にして縮小を実行してください。xxxバイトの節約が予測されるためです。

実行するコマンド。例: ALTER object SHRINK SPACE;)

オブジェクトobjectの再編成を実行してください。xxxバイトの節約が予測されるためです。

(注意: これは、オンラインによるセグメントの縮小に適していない再生可能な領域を持つオブジェクトに対する結果です。)

割当領域: xxx: 使用領域: xxx: 再利用可能領域 : xxx

オブジェクトobjectの再編成を実行してください。xxxバイトの節約が予測されるためです。

再編成の実行

オブジェクトには、再編成によって削除できる連鎖行があります。

xxパーセントの連鎖行を再編成で削除できます。

-

-

オブジェクトobject_nameを圧縮してください。xxxバイトの節約が予測されるためです。

(この結果は、自動セグメント・アドバイザによってのみ生成されます)

オブジェクトobject_nameを圧縮してください。xxxバイトの節約が予測されるためです。

-

実行するコマンド。例: ALTER TABLE T1 COMPRESS FOR OLTP

この結果については、DBA_ADVISOR_ACTIONSのATTR2列も参照してください。

DBMS_SPACE.ASA_RECOMMENDATIONSを使用したセグメント・アドバイザの結果の表示

DBMS_SPACEパッケージのASA_RECOMMENDATIONSプロシージャは、自動セグメント・アドバイザの実行およびセグメント・アドバイザの手動実行に対する結果や推奨事項を含むネストされた表オブジェクトを返します。このプロシージャでは、必要な結合がすべて実行され、使用しやすい形式で情報が返されるため、このプロシージャを呼び出す方が、DBA_ADVISOR_*ビューで作業するより簡単な場合があります。

次の問合せは、自動セグメント・アドバイザの最新の実行による推奨事項と、推奨事項に従うための実行コマンドの例を戻します。

select tablespace_name, segment_name, segment_type, partition_name,
recommendations, c1 from
table(dbms_space.asa_recommendations('FALSE', 'FALSE', 'FALSE'));

TABLESPACE_NAME                SEGMENT_NAME                   SEGMENT_TYPE
------------------------------ ------------------------------ --------------
PARTITION_NAME
------------------------------
RECOMMENDATIONS
-----------------------------------------------------------------------------
C1
-----------------------------------------------------------------------------
TVMDS_ASSM                     ORDERS1                        TABLE PARTITION
ORDERS1_P2
Perform shrink, estimated savings is 57666422 bytes.
alter table "STEVE"."ORDERS1" modify partition "ORDERS1_P2" shrink space

TVMDS_ASSM                     ORDERS1                        TABLE PARTITION
ORDERS1_P1
Perform shrink, estimated savings is 45083514 bytes.
alter table "STEVE"."ORDERS1" modify partition "ORDERS1_P1" shrink space

TVMDS_ASSM_NEW                 ORDERS_NEW                     TABLE

Perform shrink, estimated savings is 155398992 bytes.
alter table "STEVE"."ORDERS_NEW" shrink space

TVMDS_ASSM_NEW                 ORDERS_NEW_INDEX               INDEX

Perform shrink, estimated savings is 102759445 bytes.
alter index "STEVE"."ORDERS_NEW_INDEX" shrink space

DBMS_SPACE.ASA_RECOMMENDATIONSの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

自動セグメント・アドバイザの構成

自動セグメント・アドバイザは自動化メンテナンス・タスクの1つです。そのため、このタスクの実行時に変更を加える場合は、Enterprise ManagerまたはPL/SQLパッケージ・プロシージャ・コールを使用できます。適切なリソース・プランを変更することで、タスクに割り当てられているリソースを制御することもできます。

これらはPL/SQLパッケージ・プロシージャをコールして変更できますが、Enterprise Managerを使用するほうがさらに簡単です。

Enterprise Managerを使用して自動セグメント・アドバイザのタスクを構成する手順

1. ユーザーSYSTEMでEnterprise Managerにログインします。

2. データベース・ホームページで、「領域サマリー」ヘッダーの下にある「セグメント・アドバイザ推奨」ラベルの横の数値リンクをクリックします。

「セグメント・アドバイザ推奨」ページが表示されます。

3. 「関連リンク」ヘッダーの下にある「自動化メンテナンス・タスク」リンクをクリックします。
自動化メンテナンス・タスク・ページが表示されます。

4. 「構成」をクリックします。
「自動化メンテナンス・タスク構成」ページが表示されます。

5. 自動セグメント・アドバイザを完全に無効化するには、「タスク設定」の下にある「セグメント・アドバイザ」ラベルの横の「無効」を選択して、「適用」をクリックします。

6. 特定のメンテナンス・ウィンドウの自動セグメント・アドバイザを無効化するには、「セグメント・アドバイザ」列の下の該当するチェック・ボックスの選択を解除し、「適用」をクリックします。

7. メンテナンス・ウィンドウの開始時間、終了時間および継続時間を変更するには、「ウィンドウ・グループの編集」をクリックします。
ウィンドウ・グループの編集ページが表示されます。メンテナンス・ウィンドウの名前をクリックして「編集」をクリックし、ウィンドウのスケジュールを変更します。

関連項目:

- 第26章「自動データベース・メンテナンス・タスクの管理」

自動セグメント・アドバイザ情報の表示

次のビューには、自動セグメント・アドバイザ固有の情報が表示されます。詳細は、『Oracle Databaseリファレンス』を参照してください。

ビュー

説明

DBA_AUTO_SEGADV_SUMMARY

このビューには、各行に1件ずつ自動セグメント・アドバイザの実行が要約されます。フィールドには、処理された表領域やセグメントの数、および作成された推奨事項の件数が表示されます。

DBA_AUTO_SEGADV_CTL

自動セグメント・アドバイザがセグメントの選択および処理に使用する制御情報が表示されます。各行には、単一のオブジェクト(表領域またはセグメント)に関する情報(オブジェクトが処理されたかどうか、処理された場合はオブジェクトを処理したタスクIDやその選択理由など)が格納されます。

オンラインによるデータベース・セグメントの縮小

Oracle Databaseセグメントの最高水位標の下の断片化された空き領域を再生するには、オンラインによるセグメントの縮小を使用します。セグメントの縮小の利点は、次のとおりです。

- データの縮小はキャッシュ利用の向上につながります。つまり、オンライン・トランザクション処理(OLTP)のパフォーマンスが改善されます。

- データが縮小されることで、全表スキャンを実行する際に必要なスキャン・ブロック数が少なくなります。つまり、意思決定支援システム(DSS)のパフォーマンスが改善されます。

セグメントの縮小は、オンラインで適切に機能する操作です。セグメント縮小のデータ移動フェーズでは、DML操作および問合せを発行できます。縮小操作の最後に領域が割当て解除される際は、短い時間ですが同時DML操作がブロックされます。索引は、縮小操作中も保持され、操作が完了した後も使用できます。セグメントの縮小では、余分なディスク領域の割当ては不要です。

セグメントの縮小では、最高水位標の上下両方の未使用領域を再生します。これに対して、領域の割当て解除では、最高水位標よりも上の未使用領域のみを再生します。縮小操作では、デフォルトの場合、セグメントを縮小して最高水位標を調整し、回復した領域が解放されます。

セグメントの縮小には、新しい位置への行の移動が必要です。したがって、最初に、縮小するオブジェクトの行を移動可能にし、オブジェクトに定義したROWIDベースのトリガーを無効にする必要があります。表内の行を移動可能にするには、ALTER TABLE ... ENABLE ROW MOVEMENTコマンドを使用します。

縮小操作は、自動セグメント領域管理(ASSM)を使用しているローカル管理表領域内のセグメントに対してのみ実行できます。ASSM表領域内では、次の表を除くすべてのセグメント・タイプがオンラインによるセグメントの縮小に適しています。

- IOTマッピング表

- ROWIDベースのマテリアライズド・ビューを備えた表

- ファンクション索引がある表

- SECUREFILE LOB

- 圧縮表

注意:
オンラインでデータベース・セグメントを縮小すると、依存データベース・オブジェクトが無効になることがあります。「オブジェクト依存性とオブジェクトの無効化の概要」を参照してください。

関連項目:
ALTER TABLEコマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

オンラインによるセグメントの縮小の起動

オンラインによるセグメントの縮小を起動する前に、セグメント・アドバイザの結果および推奨事項を表示します。詳細は、「セグメント・アドバイザの使用」を参照してください。

Oracle Enterprise ManagerまたはSQL*PlusのSQLコマンドを使用して、オンラインによるセグメントの縮小を起動します。ここからは、コマンドラインによる方法について説明します。

注意:
Enterprise Managerの「推奨事項の詳細」ページから、セグメントの縮小を直接起動できます。(図19-4を参照してください。)また、Enterprise Managerの個々の表に対してセグメントの縮小を起動するには、「表」ページに表を表示し、表を選択してから「アクション」リストで「セグメントの縮小」をクリックします。(図19-1を参照してください。)Enterprise Managerで同様の操作を実行すると、索引やマテリアライズド・ビューなどを縮小できます。

表、索引構成表、索引、パーティション、サブパーティション、マテリアライズド・ビューまたはマテリアライズド・ビュー・ログの領域を縮小できます。この縮小には、SHRINK SPACE句を指定したALTER TABLE、ALTER INDEX、ALTER MATERIALIZED VIEW文またはALTER MATERIALIZED VIEW LOG文を使用します。

次の2つの句を必要に応じて使用することで、縮小操作の処理方法を制御できます。

- COMPACT句を指定すると、セグメントの縮小操作を2つのフェーズに分割できます。COMPACTを指定すると、Oracle Databaseはセグメント領域の断片化を解消して表の行を縮小しますが、将来のある時点まで最高水位標のリセットおよび領域の割当て解除を延期します。このオプションは、操作に影響される可能性がある長時間実行される問合せがあり、再生されたブロックから読取りが試行される場合に役立ちます。断片化解消および縮小の結果は、第2のフェーズでデータの移動をやり直す必要がないように、ディスクに保存されます。第2のフェーズを完了するには、オフピーク時にCOMPACT句を指定せずにSHRINK SPACE句を再度発行します。

- CASCADE句を指定すると、オブジェクトのすべての依存セグメントにセグメントの縮小操作が拡張されます。たとえば、表セグメントを縮小する際にCASCADEを使用すると、表のすべての索引も縮小されます。(パーティション表のパーティションを縮小するためにCASCADEを指定する必要はありません。)指定したオブジェクトの依存セグメントのリストを表示するには、DBMS_SPACEパッケージのOBJECT_DEPENDENT_SEGMENTSプロシージャを実行できます。

DDL操作と同様に、セグメントの縮小によって、後続のSQL文が再度解析されることになります。これは、COMPACT句を指定しないかぎり、カーソルが無効になるためです。

例

表およびその依存セグメント(BASICFILE LOBセグメントを含む)のすべてを縮小します。

ALTER TABLE employees SHRINK SPACE CASCADE;

BASICFILE LOBセグメントのみを縮小します。

ALTER TABLE employees MODIFY LOB (perf_review) (SHRINK SPACE);

パーティション表の単一パーティションを縮小します。

ALTER TABLE customers MODIFY PARTITION cust_P1 SHRINK SPACE;

IOT索引セグメントとオーバーフロー・セグメントを縮小します。

ALTER TABLE cities SHRINK SPACE CASCADE;

IOTオーバーフロー・セグメントのみを縮小します。

ALTER TABLE cities OVERFLOW SHRINK SPACE;

関連項目:

- SHRINK SPACE句のあるALTER TABLE、ALTER INDEX、ALTER MATERIALIZED VIEWおよびALTER MATERIALIZED VIEW LOG文の構文と制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。

- LOBセグメントの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

未使用領域の割当て解除

未使用領域の割当てを解除する場合は、未使用の(最高水位標)データベース・セグメントの最後で未使用領域を解放して、表領域の他のセグメントで領域を使用できるようにします。

割当て解除の前に、セグメントの最高水位標の位置および未使用領域の量に関する情報を返す、DBMS_SPACEパッケージのUNUSED_SPACEプロシージャを実行できます。自動セグメント領域管理を備えたローカル管理表領域のセグメントの場合は、SPACE_USAGEプロシージャを使用すると、未使用領域に関するより正確な情報が得られます。

関連項目:
DBMS_SPACEパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

次の文は、セグメント(表、索引またはクラスタ)内の未使用領域の割当てを解除します。

ALTER TABLE table DEALLOCATE UNUSED KEEP integer;
ALTER INDEX index DEALLOCATE UNUSED KEEP integer;
ALTER CLUSTER cluster DEALLOCATE UNUSED KEEP integer;

KEEP句はオプションで指定でき、セグメントに保持される領域の量を指定できます。DBA_FREE_SPACEビューを調べることで、割当て解除された領域が開放されたことを確認できます。

関連項目:

- 未使用領域の割当て解除の構文とセマンティクスの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- DBA_FREE_SPACEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

未使用オブジェクト記憶域の削除

Oracle Database 11g リリース2 (11.2.0.2)以降のDBMS_SPACE_ADMINパッケージにはDROP_EMPTY_SEGMENTSプロシージャが含まれています。このプロシージャを使用すると、以前のリリースから移行された空の表およびパーティションのセグメントを削除できます。可能な場合には、索引セグメントなどの表の依存オブジェクトのセグメントもこれに含まれます。

次の例では、データベース内のすべての表から空のセグメントを削除しています。

BEGIN
DBMS_SPACE_ADMIN.DROP_EMPTY_SEGMENTS();
END;

次は、HR.EMPLOYEES表から依存オブジェクトを含め空のセグメントを削除しています。

BEGIN
DBMS_SPACE_ADMIN.DROP_EMPTY_SEGMENTS(
schema_name  => 'HR',
table_name   => 'EMPLOYEES');
END;

このプロシージャには、11.2との互換性が必要です。

関連項目:
このプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

データ型の領域使用の理解

表またはその他のデータ構造を作成する際には、必要となる領域の大きさを把握しておく必要があります。領域要件は、データ型ごとに異なります。『Oracle Database PL/SQL言語リファレンス』および『Oracle Database SQL言語リファレンス』には、データ型および領域要件の詳細な説明があります。

スキーマ・オブジェクトの領域使用情報の表示

Oracle Databaseには、スキーマ・オブジェクトの領域使用に関する情報を表示するためのデータ・ディクショナリ・ビューとPL/SQLパッケージが用意されています。特定のスキーマ・オブジェクトに固有のビューとパッケージは、このマニュアルの各オブジェクトに関連した章に記載されています。ここでは、汎用的な性質を持ち、複数のスキーマ・オブジェクトに適用されるビューとパッケージについて説明します。

PL/SQLパッケージを使用したスキーマ・オブジェクトの領域使用情報の表示

これらのDBMS_SPACEサブプログラムを使用すると、スキーマ・オブジェクトに関する次の情報を取得できます。

パッケージとプロシージャ/ファンクション

説明

DBMS_SPACE.UNUSED_SPACE

オブジェクト(表、索引またはクラスタ)の未使用領域に関する情報を返します。

DBMS_SPACE.FREE_BLOCKS

セグメントの空き領域が空きリストで管理されている(つまり、セグメント領域管理がMANUALである)オブジェクト(表、索引またはクラスタ)の空きデータ・ブロックに関する情報を返します。

DBMS_SPACE.SPACE_USAGE

セグメント領域管理がAUTOであるオブジェクト(表、索引またはクラスタ)の空きデータ・ブロックに関する情報を返します。

関連項目:
DBMS_SPACEパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

例: DBMS_SPACE.UNUSED_SPACEの使用

次のSQL*Plusの例では、DBMS_SPACEパッケージを使用して、未使用領域情報を取得しています。

SQL> VARIABLE total_blocks NUMBER
SQL> VARIABLE total_bytes NUMBER
SQL> VARIABLE unused_blocks NUMBER
SQL> VARIABLE unused_bytes NUMBER
SQL> VARIABLE lastextf NUMBER
SQL> VARIABLE last_extb NUMBER
SQL> VARIABLE lastusedblock NUMBER
SQL> exec DBMS_SPACE.UNUSED_SPACE('SCOTT', 'EMP', 'TABLE', :total_blocks, -
>    :total_bytes,:unused_blocks, :unused_bytes, :lastextf, -
>    :last_extb, :lastusedblock);

PL/SQL procedure successfully completed.

SQL> PRINT

TOTAL_BLOCKS
------------
5

TOTAL_BYTES
-----------
10240

...

LASTUSEDBLOCK
-------------
3

スキーマ・オブジェクトの領域使用のデータ・ディクショナリ・ビュー

次のビューには、スキーマ・オブジェクトの領域使用に関する情報が表示されます。

ビュー

説明

DBA_SEGMENTS
USER_SEGMENTS

DBAビューには、すべてのデータベース・セグメントに割り当てられている記憶域が表示されます。USERビューには、現行のユーザーのセグメントに割り当てられている記憶域が表示されます。

DBA_EXTENTS
USER_EXTENTS

DBAビューには、データベース内のすべてのセグメントを構成するエクステントが表示されます。USERビューには、現行のユーザーのセグメントを構成するエクステントが表示されます。

DBA_FREE_SPACE
USER_FREE_SPACE

DBAビューには、すべての表領域の使用可能エクステントが表示されます。USERビューには、ユーザーが割当て制限を持つ表領域の空き領域情報が表示されます。

次に、これらのビューの使用例を示します。

関連項目:
データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

例1: セグメント情報の表示

次の問合せは、スキーマhrの各索引セグメントの名前とサイズを返します。

SELECT SEGMENT_NAME, TABLESPACE_NAME, BYTES, BLOCKS, EXTENTS
FROM DBA_SEGMENTS
WHERE SEGMENT_TYPE = 'INDEX'
AND OWNER='HR'
ORDER BY SEGMENT_NAME;

問合せ出力は、次のとおりです。

SEGMENT_NAME              TABLESPACE_NAME    BYTES BLOCKS EXTENTS
------------------------- --------------- -------- ------ -------
COUNTRY_C_ID_PK           EXAMPLE            65536     32       1
DEPT_ID_PK                EXAMPLE            65536     32       1
DEPT_LOCATION_IX          EXAMPLE            65536     32       1
EMP_DEPARTMENT_IX         EXAMPLE            65536     32       1
EMP_EMAIL_UK              EXAMPLE            65536     32       1
EMP_EMP_ID_PK             EXAMPLE            65536     32       1
EMP_JOB_IX                EXAMPLE            65536     32       1
EMP_MANAGER_IX            EXAMPLE            65536     32       1
EMP_NAME_IX               EXAMPLE            65536     32       1
JHIST_DEPARTMENT_IX       EXAMPLE            65536     32       1
JHIST_EMPLOYEE_IX         EXAMPLE            65536     32       1
JHIST_EMP_ID_ST_DATE_PK   EXAMPLE            65536     32       1
JHIST_JOB_IX              EXAMPLE            65536     32       1
JOB_ID_PK                 EXAMPLE            65536     32       1
LOC_CITY_IX               EXAMPLE            65536     32       1
LOC_COUNTRY_IX            EXAMPLE            65536     32       1
LOC_ID_PK                 EXAMPLE            65536     32       1
LOC_STATE_PROVINCE_IX     EXAMPLE            65536     32       1
REG_ID_PK                 EXAMPLE            65536     32       1

19 rows selected.

例2: エクステント情報の表示

データベース内に現在割り当てられているエクステントに関する情報は、DBA_EXTENTSデータ・ディクショナリ・ビューに格納されています。たとえば、次の問合せによって、hrスキーマの各索引セグメントに割り当てられているエクステントとそれらのエクステントのサイズが識別されます。

SELECT SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, EXTENT_ID, BYTES, BLOCKS
FROM DBA_EXTENTS
WHERE SEGMENT_TYPE = 'INDEX'
AND OWNER='HR'
ORDER BY SEGMENT_NAME;

問合せ出力は、次のとおりです。

SEGMENT_NAME              SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID    BYTES BLOCKS
------------------------- ------------ --------------- --------- -------- ------
COUNTRY_C_ID_PK           INDEX        EXAMPLE                 0    65536     32
DEPT_ID_PK                INDEX        EXAMPLE                 0    65536     32
DEPT_LOCATION_IX          INDEX        EXAMPLE                 0    65536     32
EMP_DEPARTMENT_IX         INDEX        EXAMPLE                 0    65536     32
EMP_EMAIL_UK              INDEX        EXAMPLE                 0    65536     32
EMP_EMP_ID_PK             INDEX        EXAMPLE                 0    65536     32
EMP_JOB_IX                INDEX        EXAMPLE                 0    65536     32
EMP_MANAGER_IX            INDEX        EXAMPLE                 0    65536     32
EMP_NAME_IX               INDEX        EXAMPLE                 0    65536     32
JHIST_DEPARTMENT_IX       INDEX        EXAMPLE                 0    65536     32
JHIST_EMPLOYEE_IX         INDEX        EXAMPLE                 0    65536     32
JHIST_EMP_ID_ST_DATE_PK   INDEX        EXAMPLE                 0    65536     32
JHIST_JOB_IX              INDEX        EXAMPLE                 0    65536     32
JOB_ID_PK                 INDEX        EXAMPLE                 0    65536     32
LOC_CITY_IX               INDEX        EXAMPLE                 0    65536     32
LOC_COUNTRY_IX            INDEX        EXAMPLE                 0    65536     32
LOC_ID_PK                 INDEX        EXAMPLE                 0    65536     32
LOC_STATE_PROVINCE_IX     INDEX        EXAMPLE                 0    65536     32
REG_ID_PK                 INDEX        EXAMPLE                 0    65536     32

19 rows selected.

hrスキーマの場合は、複数のエクステントが割り当てられているセグメントはありません。

例3: 表領域内の空き領域(エクステント)の表示

データベース内の使用可能エクステント(どのセグメントにも割り当てられていないエクステント)に関する情報は、DBA_FREE_SPACEデータ・ディクショナリ・ビューに格納されています。たとえば、次の問合せは、SMUNDO表領域内の使用可能エクステントとして使用可能な空き領域を示します。

SELECT TABLESPACE_NAME, FILE_ID, BYTES, BLOCKS
FROM DBA_FREE_SPACE
WHERE TABLESPACE_NAME='SMUNDO';

問合せ出力は、次のとおりです。

TABLESPACE_NAME  FILE_ID    BYTES BLOCKS
--------------- -------- -------- ------
SMUNDO                 3    65536     32
SMUNDO                 3    65536     32
SMUNDO                 3    65536     32
SMUNDO                 3    65536     32
SMUNDO                 3    65536     32
SMUNDO                 3    65536     32
SMUNDO                 3   131072     64
SMUNDO                 3   131072     64
SMUNDO                 3    65536     32
SMUNDO                 3  3407872   1664

10 rows selected.

データベース・オブジェクトの容量計画

Oracle Databaseには、データベース・オブジェクトの容量を計画する方法が2つあります。

- Enterprise Managerの使用

- DBMS_SPACE PL/SQLパッケージの使用

ここでは、PL/SQLによる方法について説明します。Enterprise Managerを使用した容量計画の詳細は、Enterprise Managerのオンライン・ヘルプおよび『Oracle Database 2日でデータベース管理者』を参照してください。

DBMS_SPACEパッケージには、新しいオブジェクトのサイズを予測したり、既存のデータベース・オブジェクトのサイズを監視できる3つのプロシージャがあります。ここでは、これらのプロシージャについて説明します。この項の内容は、次のとおりです。

- 表の領域使用の見積り

- 索引の領域使用の見積り

- オブジェクト増加傾向の取得

表の領域使用の見積り

データベース表のサイズは、表領域の記憶域属性、表領域のブロック・サイズ、他の様々な要因によって大きく変化する可能性があります。DBMS_SPACEパッケージのCREATE_TABLE_COSTプロシージャを使用すると、表を作成する際の領域使用コストを予測できます。このプロシージャのパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

プロシージャには、2つの異形があります。第1の異形は、行の平均サイズを使用してサイズを見積ります。第2の異形は、列情報を使用して表のサイズを見積ります。両方の異形ともに入力として次の値が必要です。

- TABLESPACE_NAME: オブジェクトが作成される表領域。デフォルトはSYSTEM表領域です。

- ROW_COUNT: 表の予測行数。

- PCT_FREE: 更新の結果、既存の行を将来拡張するように各ブロックに確保する空き領域の割合(パーセンテージ)。

さらに、第1の異形には、AVG_ROW_SIZEの値も入力する必要があります。値は、予測された行サイズの平均をバイト単位で指定します。

また、第2の異形には、予想された各列値をCOLINFOSに指定する必要があります。この値は、属性COL_TYPE(列のデータ型)とCOL_SIZE(列の文字数またはバイト数)からなるオブジェクト型です。

このプロシージャでは、2つの値が戻ります。

- USED_BYTES: ブロック・メタデータ、PCT_FREE領域などのオーバーヘッドを含め、データとして使用される実際のバイト数。

- ALLOC_BYTES: 表領域のエクステントの特性を考慮してオブジェクトに割り当てられる予測した領域の大きさ。

注意:
Oracle Databaseのリリース11.2.0.2からは、パーティション表のすべての新規セグメントについて、第1エクステントのデフォルトのサイズが64KBではなく8MBになりました。このことは、パーティション表に対する挿入と問合せのパフォーマンス向上に役立ちます。パーティション表の初期サイズが大きくても、十分なデータが挿入されると、領域消費は以前のリリースと同じになります。このデフォルトは、表の記憶域句にINITIALサイズを設定して上書きできます。この新しいデフォルトは、表パーティションおよびLOBパーティションにのみ適用されます。

索引の領域使用の見積り

DBMS_SPACEパッケージのCREATE_INDEX_COSTプロシージャを使用すると、既存の表に索引を作成する際の領域使用コストを予測できます。

プロシージャには次の値を入力する必要があります。

- DDL: 索引を作成するCREATE INDEX文。このDDL文に指定する表は、既存の表であることが必要です。

- PLAN_TABLE(オプション): 使用するPLAN TABLEの名前。デフォルトはNULLです。

このプロシージャから戻る結果は、セグメントに対して収集された統計によって異なります。したがって、このプロシージャを実行する直前に必ず統計を取得してください。最近の統計がない状態でもエラーになりませんが、不適切な結果が戻る可能性があります。このプロシージャでは、次の値が戻ります。

- USED_BYTES: 実際の索引データを表すバイト数。

- ALLOC_BYTES: 表領域の索引に割り当てられる領域の大きさ。

オブジェクト増加傾向の取得

DBMS_SPACEパッケージ・プロシージャのOBJECT_GROWTH_TREND関数では、特定の時点におけるオブジェクトの領域使用が各行に記述された1行以上の表が作成されます。この関数は、自動ワークロード・リポジトリから領域使用の合計を取得するか、現在の領域使用を計算して、自動ワークロード・リポジトリから取得した領域使用の変更履歴と結合します。この関数のパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

関数には次の値を入力する必要があります。

- OBJECT_OWNER: オブジェクトの所有者。

- OBJECT_NAME: オブジェクトの名前。

- PARTITION_NAME: 適切な場合は、表または索引パーティションの名前を指定します。それ以外の場合は、NULLを指定します。

- OBJECT_TYPE: オブジェクトの種類。

- START_TIME: 増加傾向分析の開始を示すTIMESTAMP値。

- END_TIME: 増加傾向分析の終了を示すTIMESTAMP値。デフォルトはNOWです。

- INTERVAL: 関数が領域使用情報を取得するレポート間隔の長さ(分単位)。

- SKIP_INTERPOLATED: INTERVALの前後に記録された統計情報に基づいて、この関数が値を除外する('YES')かしない('NO')かを決定します。要求したレポート作成間隔と実際の記録間隔がどのように関連しているかをより明確に表示できるため、チャートではなく表として結果表が表示される場合には、この設定が便利です。

この関数は、1つの間隔のオブジェクトの領域使用情報が各行に示された表を返します。返される表が非常に大きい場合は、情報が作成されると同時に別のアプリケーションが使用できるように結果がパイプライン化されます。出力表には次の列があります。

- TIMEPOINT: レポート間隔の時間を示すTIMESTAMP値。
最も古いオブジェクトの記録統計よりも前のTIME値の記録は作成されません。

- SPACE_USAGE: オブジェクト・データとして実際に使用されているバイト数。

- SPACE_ALLOC: その時点で表領域のオブジェクトに割り当てられていたバイト数。

- QUALITY: 要求されたレポート間隔と実際の統計記録が一致している程度を示す値。オブジェクト・サイズ使用統計には保証されているレポート間隔はなく、実際のレポート間隔は時間の経過およびオブジェクトによって変わるため、この情報が役立ちます。
QUALITY列には、次の値が設定されます。

- GOOD: 記録されたタイムスタンプが入力パラメータに指定したINTERVALの10%以内で、TIMEの値が記録統計に常に基づいている場合。

- INTERPOLATED: 値はGOODの基準を満たしていないが、TIME値の前後の記録統計に基づいている場合。現在のインメモリー統計は、クラスタ内のすべてのインスタンスで収集でき、現時点の記録値として取り扱うことができます。

- PROJECTION: 表が作成された時点ではTIME値が未来であった場合。Oracle Real Application Clusters環境では、統計の記録ルールによって、どのオブジェクトが選択されるかを各インスタンスが独自に選択できるようになっています。

この関数から戻る出力は、Oracle RAC環境のすべてのインスタンスについて記録した値の集合です。各値は、GOODおよびINTERPOLATED値の組合せから計算できます。その値の少なくとも80%がGOODのインスタンス値から導出された場合、戻される集計値はGOODにマークされます。

20 表の管理

この章の内容は、次のとおりです。

- 表について

- 表を管理するためのガイドライン

- 表の作成

- 表のロード

- 表に関する統計の自動収集

- 表の変更

- 表のオンライン再定義

- エラーが発生した表の変更の調査と取消し

- Oracle Flashback Tableを使用した表のリカバリ

- 表の削除

- フラッシュバック・ドロップの使用とリサイクル・ビンの管理

- 索引構成表の管理

- 外部表の管理

- 表のデータ・ディクショナリ・ビュー

表について

表は、Oracle Databaseのデータ記憶域の基本単位です。データは、行および列に格納されます。表は、employeesなどの表名と一連の列で定義します。各列には列名(employee_id、last_name、job_idなど)、データ型(VARCHAR2、DATE、NUMBERなど)および幅を指定します。幅は、DATEデータ型の場合のようにデータ型によって事前に決定されている場合があります。NUMBERデータ型の列の場合は、幅ではなく、精度および位取りを定義します。行は、単一のレコードに対応する列情報の集合です。

表の各列にはルールを指定できます。これらのルールは整合性制約と呼ばれています。NOT NULLは、整合性制約の1つです。これは、各行の列に値を指定することを強制する制約です。

透過的データ暗号化を起動して、データを暗号化してから格納できます。ユーザーが、オペレーティング・システムのツールを使用してOracleデータファイルの内容を直接参照することによって、データベース・アクセス制御メカニズムを迂回しようとした場合でも、暗号化によって、このようなユーザーが機密データを参照できないようにします。

表には仮想列を含めることもできます。仮想列は表の他の列とほぼ同じですが、値が式を評価して導出される点が異なります。式には、同じ表からの列、制約、SQL関数およびユーザー定義PL/SQL関数を含めることができます。仮想列に明示的に書き込むことはできません。

列の型には、LOB、VARRAYおよびネストした表のように専用セグメントに格納されるものがあります。LOBとVARRAYはLOBセグメントに格納されますが、ネストした表は記憶表に格納されます。これらのセグメントに対してSTORAGE句を指定し、表レベルで指定した記憶域パラメータを上書きできます。

表を作成した後は、SQL文またはOracleのバルク・ロード・ユーティリティを使用してデータ行を挿入します。表データは、SQLを使用して問合せ、削除または更新できます。

関連項目:

- 表の概要は、『Oracle Database概要』を参照してください。

- Oracle Databaseのデータ型の説明は、『Oracle Database SQL言語リファレンス』を参照してください。

- 表の領域を管理するためのガイドラインは、第19章「スキーマ・オブジェクトの領域の管理」を参照してください。

- 整合性制約の指定や表の分析など、表の管理に関するその他の詳細は、第18章「スキーマ・オブジェクトの管理」を参照してください。

- 透過的データ暗号化の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

表を管理するためのガイドライン

ここでは、表を管理するときに従うべきガイドラインについて説明します。これらのガイドラインに従うことで、表の作成や表データのロード、更新および問合せを行うときに、表の管理が容易になり、パフォーマンスの向上にもつながります。

次の内容について説明します。

- 作成前の表の設計

- 作成する表のタイプの指定

- 各表の位置の指定

- 表作成のパラレル化

- 表作成時のNOLOGGINGの使用

- 表圧縮の使用

- 機密データを格納する列の暗号化

- セグメント作成の遅延の理解

- 表サイズの見積りと見積りに応じた計画

- 表作成時の制限事項

作成前の表の設計

通常、アプリケーション開発者は、表などのアプリケーションの要素を設計する必要があります。データベース管理者は、アプリケーション表を保持する、基礎となる表領域に対する属性の設定を担当します。DBAまたはアプリケーション開発者は(あるいは双方が協力して)、サイトの業務に基づいて実際の表の作成を担当します。

表を設計する場合は、アプリケーション開発者と協力し、次のガイドラインを考慮してください。

- 表、列、索引およびクラスタには、内容を表現する名前を使用します。

- 表名および列に略語を使用する場合や、単数形と複数形の使用には、一貫性を持たせます。

- COMMENTコマンドを使用して、各表とその列の意味を記載します。

- 各表は正規化します。

- 各列に適切なデータ型を選択します。

- 一部の表に仮想列を1つ以上追加した場合、アプリケーションに利点があるかどうかを検討します。

- 記憶域を節約するために、NULLを許可する列を最後に定義します。

- 記憶域を節約し、SQL文のパフォーマンスを最適化するために、適切な場合は必ず表をクラスタ化します。

表を作成する前に、整合性制約の使用についても判断します。表の列に整合性制約を定義することによって、データベースのビジネス・ルールを自動的に徹底できます。

作成する表のタイプの指定

作成できる表のタイプは次のとおりです。

表のタイプ

説明

通常の(ヒープ構成)表

この章の主な説明の対象でもある基本的で多目的な表です。この表のデータは、順序付けされていないコレクション(ヒープ)として格納されます。

クラスタ化表

クラスタ化表は、クラスタの一部である表です。クラスタとは、各表が共通の列を共有していて一緒に使用されるケースが多いために、同じデータ・ブロックを共有する表のグループです。
クラスタおよびクラスタ化表の詳細は、第22章「クラスタの管理」を参照してください。

索引構成表

通常の(ヒープ構成)表とは異なり、索引構成表のデータはBツリーの索引構造に主キー・ソート方式で格納されます。Bツリーの各索引エントリには、索引構成表の行の主キーの列値のみでなく、非キーの列値も格納されます。
索引構成表の詳細は、「索引構成表の管理」を参照してください。

パーティション表

パーティション表では、データをパーティションと呼ばれるさらに小さく管理が容易な単位に分割でき、さらにサブパーティションに分割することもできます。各パーティションには、圧縮の有効化または無効化、圧縮のタイプ、物理記憶域設定、表領域など別個の物理属性を指定できるため、可用性およびパフォーマンスをより適切にチューニングできる構造になります。さらに、各パーティションを個別に管理できるため、バックアップや管理が簡素化され、これらの処理に必要な時間を削減できます。
パーティション表の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

各表の位置の指定

新しい表を格納する表領域を識別するには、CREATE TABLE文にTABLESPACE句を指定します。パーティション表の場合は、各パーティションを格納する表領域をオプションとして指定できます。使用する表領域に対する適切なシステム権限と割当て権限があることを確認してください。CREATE TABLE文で表領域を指定しない場合は、作成したユーザーのデフォルト表領域内に表が作成されます。

新しい表を含む表領域を指定するときは、その選択が意味することを確実に理解しておいてください。各表の作成時に表領域を適切に指定することによって、データベース・システムのパフォーマンスが向上し、データベース管理に必要な時間を短縮できます。

次のように、表領域を指定しない場合や不適切な表領域を指定した場合は、パフォーマンスに影響を与えます。

- ユーザーのオブジェクトをSYSTEM表領域に作成すると、データ・ディクショナリ・オブジェクトとユーザー・オブジェクトの両方が同じデータファイルを求めて競合し、データベースのパフォーマンスが低下するおそれがあります。ユーザーのオブジェクトはSYSTEM表領域に格納しないでください。これを回避するには、データベースに表領域が作成される際に、すべてのユーザーにデフォルトの表領域が割り当てられていることを確認します。

- アプリケーションに関係する表をいろいろな表領域に無計画に格納すると、アプリケーションのデータ管理操作(バックアップやリカバリなど)に要する時間が増大する可能性があります。

表作成のパラレル化

CREATE TABLE文で副問合せ(AS SELECT)を使用して表を作成する際は、パラレル実行を使用できます。複数のプロセスが同時に動作して表を作成するため、表を作成するときのパフォーマンスが向上します。

表作成のパラレル化の説明は、「表作成のパラレル化」を参照してください。

表作成時のNOLOGGINGの使用

表を最も効率よく作成するには、CREATE TABLE...AS SELECT文でNOLOGGING句を使用します。NOLOGGING句を指定すると、表の作成中に最小限のREDO情報しか生成されません。これには、次のような利点があります。

- REDOログ・ファイルの領域を節約できます。

- 表の作成に要する時間が削減できます。

- 大規模な表のパラレル作成のパフォーマンスが向上します。

また、NOLOGGING句を指定することで、SQL*Loaderを使用した後続のダイレクト・ロードおよびダイレクト・ロードINSERT操作がロギングされなくなります。後続のデータ操作文(DML)文(UPDATE、DELETEおよび従来型パスの挿入)は、表のNOLOGGING属性の影響を受けず、REDOを生成します。

表の作成後にその表の損失(たとえば、表の作成に使用したデータにアクセスできなくなるなど)を避ける必要がある場合は、作成直後に表のバックアップを取得してください。一時的に使用するために作成する表など、そのような予防策が不要な場合もあります。

一般に、NOLOGGINGを指定して表を作成するときは、小規模な表より大規模な表の方が相対的にパフォーマンスの向上が大きくなります。小規模な表の場合は、NOLOGGINGを指定しても、表作成に要する時間にほとんど影響はありません。一方、大規模な表では、特に表作成をパラレル化したときにもパフォーマンスが著しく向上します。

表圧縮の使用

データベースが大きくなるにつれて、表圧縮の使用を検討してください。圧縮を使用すると、ディスク領域が節約され、データベース・バッファ・キャッシュのメモリー使用が削減されて、読込み中の問合せ実行速度が大幅に向上します。圧縮には、データのロードやDMLのためのCPUオーバーヘッドがかかります。ただし、この負荷はI/O要件の削減によって相殺される可能性があります。

表の圧縮は、アプリケーションに対して完全に透過的です。意思決定支援システム(DSS)、オンライン・トランザクション処理(OLTP)システムおよびアーカイブ・システムで役立ちます。

圧縮は、表領域、表またはパーティションに対して指定できます。表領域レベルで指定した場合、その表領域内に作成されるすべての表がデフォルトで圧縮されます。

圧縮は、表に対するデータの挿入、更新またはバルク・ロード中に実行できます。圧縮が許可される操作は次のとおりです。

- 単一行または単一配列の挿入および更新

- 次のダイレクト・パスINSERT方法

- ダイレクト・パスSQL*Loader

- CREATE TABLE AS SELECT文

- パラレルINSERT文

- APPENDまたはAPPEND_VALUESヒントを指定したINSERT文

Oracle Databaseでは、表の圧縮でいくつかの方法がサポートされます。これらの方法を表20-1にまとめます。

表20-1 表圧縮方法

表圧縮方法

圧縮レベル

CPUオーバーヘッド

アプリケーション

注意

基本圧縮

高

最小限

DSS

なし。

OLTP圧縮

高

最小限

OLTP、DSS

なし。

ウェアハウス圧縮(ハイブリッド列圧縮)

より高い

より高い

DSS

圧縮レベルとCPUオーバーヘッドは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します。

アーカイブ圧縮(ハイブリッド列圧縮)

最高

最高

アーカイブ

圧縮レベルとCPUオーバーヘッドは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します。

基本圧縮、ウェアハウス圧縮またはアーカイブ圧縮を使用する場合、圧縮はデータが表にバルク・ロードされるときにのみ実行されます。

OLTP圧縮を使用する場合、圧縮は、表に対するデータの挿入、更新またはバルク・ロード中に実行されます。圧縮が許可される操作は次のとおりです。

- 単一行または単一配列の挿入および更新
挿入および更新は即時に圧縮されません。すでに圧縮されているブロックを更新する場合、更新されない列は通常、圧縮されたままです。更新された列は、圧縮されていないブロックと同様に非圧縮形式で格納されます。更新された値は、ブロックがデータベース制御されたしきい値に達すると、再圧縮されます。挿入されたデータも、ブロック内のデータがデータベース制御されたしきい値に達すると、圧縮されます。

- 次のダイレクト・パスINSERT方法

- ダイレクト・パスSQL*Loader

- CREATE TABLE AS SELECT文

- パラレルINSERT文

- APPENDまたはAPPEND_VALUESヒントを指定したINSERT文

基本圧縮は、ダイレクト・パス・ロードによって挿入されたデータのみを圧縮し、制限されたデータ型およびSQL操作をサポートします。OLTP圧縮はOLTPアプリケーション向けで、すべてのSQL操作によって操作されたデータを圧縮します。

ウェアハウス圧縮とアーカイブ圧縮では、ハイブリッド列圧縮テクノロジが使用されるため、最高の圧縮レベルが実現します。ハイブリッド列圧縮テクノロジでは、行優先ストレージではなく、修正された形式の列指向ストレージが使用されます。これにより、データベースでは、同様のデータをまとめて格納できるため、圧縮アルゴリズムの効率性が向上します。データを更新する場合、ハイブリッド列圧縮ではより多くのCPUが使用され、将来の更新を迅速に行うために、更新された行は行形式に移動されます。このような最適化が行われるため、更新頻度の低いデータにのみこの圧縮機能を使用してください。

より高い圧縮レベルのハイブリッド列圧縮は、ダイレクト・パス・インサートが行われるデータでのみ実現されます。従来の挿入および更新もサポートされますが、その場合、行が列形式から行形式に移動され、圧縮レベルも低下します。

圧縮方法に関係なく、圧縮されたブロックに対するDELETE操作は、圧縮されていないブロックに対するDELETE操作と同じです。SQL DELETE操作によってデータ・ブロックで取得される領域はすべて、後続のSQL INSERT操作で再利用されます。ハイブリッド列圧縮テクノロジを使用すると、圧縮単位内の行がすべて削除された場合、圧縮単位内の領域は再利用に使用できます。

表20-2は、表の各圧縮方法の特徴を示しています。

表20-2 表の圧縮の特徴

表圧縮方法

CREATE/ALTER TABLEの構文

ダイレクト・パスINSERT

注意

基本圧縮

COMPRESS [BASIC]

行は基本圧縮方式で圧縮されます。

COMPRESSとCOMPRESS BASICは同等です。

ダイレクト・パス・インサートを使用せずに挿入された行と更新された行は圧縮されません。

OLTP圧縮

COMPRESS FOR OLTP

行はOLTP圧縮方式で圧縮されます。

ダイレクト・パス・インサートを使用せずに挿入された行と更新された行は、OLTP圧縮を使用して圧縮されます。

ウェアハウス圧縮(ハイブリッド列圧縮)

COMPRESS FOR QUERY [LOW|HIGH]

行はウェアハウス圧縮方式で圧縮されます。

この圧縮方式は高いCPUオーバーヘッドが発生する可能性があります。

更新された行およびダイレクト・パス・インサートを使用せずに挿入された行は、列形式ではなく行形式で格納されるため、圧縮レベルが低下します。

アーカイブ圧縮(ハイブリッド列圧縮)

COMPRESS FOR ARCHIVE [LOW|HIGH]

行はアーカイブ圧縮方式で圧縮されます。

この圧縮方式は高いCPUオーバーヘッドが発生する可能性があります。

更新された行およびダイレクト・パス・インサートを使用せずに挿入された行は、列形式ではなく行形式で格納されるため、圧縮レベルが低下します。

表圧縮の指定には、CREATE TABLE文のCOMPRESS句を使用します。既存の表で圧縮を有効にするには、ALTER TABLE文でこれらの句を使用します。この場合、圧縮を使用可能にした後で挿入または更新されたデータのみが圧縮されます。同様に、ALTER TABLE...NOCOMPRESS文を使用すると、既存の圧縮表に対する表圧縮を使用禁止にできます。この場合、すでに圧縮されているすべてのデータは圧縮されたままですが、新規データは圧縮されずに挿入されます。

COMPRESS FOR QUERY HIGHオプションは、デフォルトのデータ・ウェアハウス圧縮モードです。Exadataストレージでハイブリッド列圧縮を使用する場合に、高い圧縮レベルと優れたパフォーマンスが実現します。COMPRESS FOR QUERY LOWオプションは、ロード・パフォーマンスが非常に重要な環境で使用する必要があります。このオプションでは、COMPRESS FOR QUERY HIGHオプションで圧縮されたデータより高速にロードが行われます。

COMPRESS FOR ARCHIVE LOWオプションは、デフォルトのアーカイブ圧縮モードです。これにより、高い圧縮レベルが実現し、頻繁にアクセスしないデータに最適です。めったにアクセスされないデータに対しては、COMPRESS FOR ARCHIVE HIGHオプションを使用する必要があります。

DBMS_COMPRESSIONパッケージで提供される圧縮アドバイザを使用すると、特定の表に特定の圧縮方法を適用したときに予想される圧縮レベルを確認できます。

注意:
ハイブリッド列圧縮は、基礎となるストレージ・システムに依存します。詳細は、『Oracle Databaseライセンス情報』を参照してください。

関連項目:

- 表圧縮の概要は、『Oracle Database概要』を参照してください。

- 「圧縮された表領域」

表圧縮に関連のある例

次に示す例は、表圧縮に関連があります。

- 例20-1「OLTP表圧縮を使用した表の作成」

- 例20-2「基本表圧縮を使用した表の作成」

- 例20-3「ダイレクト・パス・インサートを使用した表への行の挿入」

- 例20-4「ウェアハウス圧縮を使用した表の作成」

- 例20-5「アーカイブ圧縮を使用した表の作成」

例20-1 OLTP表圧縮を使用した表の作成

次の例では、表ordersに対してOLTP表圧縮を使用可能にします。

CREATE TABLE orders  ...  COMPRESS FOR OLTP;

orders表のデータは、ダイレクト・パスINSERTおよび従来のDMLの両方で圧縮されます。

例20-2 基本表圧縮を使用した表の作成

次に示す同等の文では、データ・ウェアハウス内のファクト表であるsales_history表に対して基本表圧縮を使用可能にします。

CREATE TABLE sales_history  ...  COMPRESS BASIC;

CREATE TABLE sales_history  ...  COMPRESS;

この表には問合せが頻繁に実行されますが、DMLの実行は想定されていません。

例20-3 ダイレクト・パス・インサートを使用した表への行の挿入

この例では、ダイレクト・パスINSERTを使用してsales_history表に行を挿入する場合にAPPENDヒントを使用する方法を示しています。

INSERT /*+ APPEND */ INTO sales_history SELECT * FROM sales WHERE cust_id=8890;
COMMIT;

例20-4 ウェアハウス圧縮を使用した表の作成

この例では、表sales_historyでハイブリッド列圧縮を使用可能にします。

CREATE TABLE sales_history  ...  COMPRESS FOR QUERY;

表は、デフォルトのCOMPRESS FOR QUERY HIGHオプションを使用して作成されます。このオプションは、基本圧縮またはOLTP圧縮よりも高レベルの圧縮を実現します。ロード・パフォーマンスが重要であり、問合せが頻繁に表に対して実行され、DMLが予期されない場合に適しています。

例20-5 アーカイブ圧縮を使用した表の作成

次の例では、表sales_historyでハイブリッド列圧縮を使用可能にします。

CREATE TABLE sales_history  ...  COMPRESS FOR ARCHIVE;

表は、デフォルトのCOMPRESS FOR ARCHIVE LOWオプションを使用して作成されます。このオプションでは最高レベルの圧縮が実現され、頻繁にアクセスされないデータの場合に適しています。

圧縮とパーティション表

表には圧縮パーティションと非圧縮パーティションの両方を含めることができ、異なるパーティションでは異なる圧縮方法を使用できます。表に対する圧縮の設定とそのパーティションに対する設定が一致しない場合、パーティションについてはパーティションの設定が優先されます。

パーティションの圧縮方法を変更するには、次のどちらかを実行します。

- 新しいデータのみの圧縮方法を変更するには、ALTER TABLE ... MODIFY PARTITION ... COMPRESS ...を使用します。

- 新しいデータと既存のデータの両方の圧縮方法を変更するには、ALTER TABLE ... MOVE PARTITION ... COMPRESS ...または表のオンライン再定義のどちらかを使用します。

表が圧縮されているかどうかの確認

*_TABLESデータ・ディクショナリ・ビューで、圧縮表にはCOMPRESSION列にENABLEDと表示されます。パーティション表では、この列はNULLですが、*_TAB_PARTITIONSビューのCOMPRESSION列に、圧縮されているパーティションが表示されます。また、COMPRESS_FOR列には、表またはパーティションで使用中の圧縮方法が表示されます。

SQL> SELECT table_name, compression, compress_for FROM user_tables;

TABLE_NAME       COMPRESSION   COMPRESS_FOR
---------------- ------------  -----------------
T1               DISABLED
T2               ENABLED       BASIC
T3               ENABLED       OLTP
T4               ENABLED       QUERY HIGH
T5               ENABLED       ARCHIVE LOW

SQL> SELECT table_name, partition_name, compression, compress_for
FROM user_tab_partitions;

TABLE_NAME  PARTITION_NAME   COMPRESSION   COMPRESS_FOR
----------- ---------------- -----------   ------------------------------
SALES       Q4_2004          ENABLED       ARCHIVE HIGH
...
SALES       Q3_2008          ENABLED       QUERY HIGH
SALES       Q4_2008          ENABLED       QUERY HIGH
SALES       Q1_2009          ENABLED       OLTP
SALES       Q2_2009          ENABLED       OLTP

圧縮されている行の確認

ハイブリッド列圧縮表が更新されると、行はウェアハウス圧縮(QUERY HIGH)からOLTP圧縮または圧縮なしなどの低レベルの圧縮に変更されます。行の圧縮レベルを確認するには、DBMS_COMPRESSIONパッケージのGET_COMPRESSION_TYPEファンクションを使用します。

たとえば、次の問合せは、hr.employees表の行の圧縮タイプを返します。

SELECT DECODE(DBMS_COMPRESSION.GET_COMPRESSION_TYPE(
ownname => 'HR',
tabname => 'EMPLOYEES',
row_id  => 'AAAVEIAAGAAAABTAAD'),
1,  'No Compression',
2,  'Basic or OLTP Compression',
4,  'Hybrid Columnar Compression for Query High',
8,  'Hybrid Columnar Compression for Query Low',
16, 'Hybrid Columnar Compression for Archive High',
32, 'Hybrid Columnar Compression for Archive Low',
'Unknown Compression Type') compression_type
FROM DUAL;

表の行をサンプリングすることで、高レベルの圧縮ではなくなった行の割合を確認できます。ALTER TABLEまたはMOVE PARTITIONを使用すると、より高い圧縮レベルを指定できます。たとえば、行のうちの10パーセントが最高の圧縮レベルでなくなった場合、表を変更するか、パーティションを移動してより高い圧縮レベルを指定できます。

関連項目:
GET_COMPRESSION_TYPEの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

圧縮レベルの変更

パーティション、表または表領域の圧縮レベルは変更できます。たとえば、ある企業でその売上データにウェアハウス圧縮を使用している一方で、6か月より古い売上データにはめったにアクセスしないとします。売上データがその経過時間に基づいてパーティション化された表に格納されている場合、古いデータの圧縮レベルをアーカイブ圧縮に変更して、ディスク領域を解放できます。

表がパーティション化されている場合、DBMS_REDEFINITIONパッケージを使用して表の圧縮レベルを変更できます。このパッケージでは、表の再定義をオンラインで実行するために、再定義中に表のデータを保持する一時コピーを作成します。再定義される表は、再定義中でも引き続き問合せやDML文に対応できます。オンラインでの表の再定義に使用される空き領域の容量は、既存の表と新しい表の相対的な圧縮レベルに応じて変化します。DBMS_REDEFINITIONパッケージを使用する前に、システム上に十分なハード・ディスク領域が存在することを確認してください。

表がパーティション化されていない場合、ALTER TABLE...MOVE...COMPRESS FOR...文を使用して圧縮レベルを変更できます。ALTER TABLE...MOVE文では、コマンドの実行中に表に対するDML文は許可されません。

パーティションの圧縮レベルを変更するには、ALTER TABLE...MODIFY PARTITION文を使用します。表領域の圧縮レベルを変更するには、ALTER TABLESPACE文を使用します。

関連項目:

- ALTER TABLEコマンドの詳細は、「新規セグメントまたは表領域への表の移動」を参照してください。

- DBMS_REDEFINITIONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

圧縮表の列の追加と削除

圧縮表に列を追加する場合、次の制限が適用されます。

- 基本圧縮: 追加される列にはデフォルト値を指定できません。

- OLTP圧縮: 追加される列にデフォルト値を指定する場合、列はNOT NULLであることが必要です。デフォルト値が設定されたNULL値可能列の追加はサポートされません。

圧縮表の列を削除する場合、次の制限が適用されます。

- 基本圧縮: 列の削除はサポートされていません。

- OLTP圧縮: DROP COLUMNはサポートされていますが、長時間実行される解凍と再圧縮の操作を避けるために、データベースでは列が内部的にUNUSEDに設定されます。

ハイブリッド列圧縮表のエクスポートおよびインポート

ハイブリッド列圧縮表は、データ・ポンプのインポート・ユーティリティのimpdpコマンドを使用してインポートできます。デフォルトでは、impdpコマンドは表プロパティを保存し、インポートされた表はハイブリッド列圧縮表となります。ハイブリッド列圧縮をサポートしていない表領域では、impdpコマンドは失敗し、エラーが表示されます。表はexpdpコマンドでエクスポートすることもできます。

ハイブリッド列圧縮表は、impdpコマンドのTRANSFORM:SEGMENT_ATTRIBUTES=nオプション句を使用して、非圧縮表としてインポートできます。

非圧縮表またはOLTP圧縮表は、インポート中にハイブリッド列圧縮形式に変換できます。ハイブリッド列圧縮表でない表をハイブリッド列圧縮表に変換するには、次のようにします。

1. ALTER TABLESPACE ... SET DEFAULT COMPRESSコマンドを使用して、表領域のデフォルト圧縮を指定します。

2. インポート中にインポートされた表のSEGMENT_ATTRIBUTESオプションを上書きします。

関連項目:

- データ・ポンプのインポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

- ALTER TABLESPACEコマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ハイブリッド列圧縮表のリストア

ハイブリッド列圧縮表をバックアップからリストアする必要がある場合があります。表はハイブリッド列圧縮をサポートしているシステム、またはハイブリッド列圧縮をサポートしていないシステムにリストアできます。ハイブリッド列圧縮が含まれる表をハイブリッド列圧縮をサポートしているシステムにリストアする場合は、通常どおり、Oracle Recovery Manager (RMAN)を使用してファイルをリストアします。

ハイブリッド列圧縮表がハイブリッド列圧縮をサポートしていないシステムにリストアされている場合は、表をハイブリッド列圧縮からOLTP圧縮形式または非圧縮形式に変換する必要があります。表をリストアするには、次のようにします。

1. 環境に非圧縮形式またはOLTP圧縮形式のデータを保存するに十分なストレージがあることを確認します。

2. RMANを使用して、ハイブリッド列圧縮表領域をリストアします。

3. 次のいずれかのアクションを実行して、表をハイブリッド列圧縮からOLTP圧縮形式または非圧縮形式に変換します。

- 次の文を使用して、データ圧縮をハイブリッド列圧縮からCOMPRESS FOR OLTPに変更します。

ALTER TABLE table_name MOVE COMPRESS FOR OLTP;

- 次の文を使用して、データ圧縮をハイブリッド列圧縮からNOCOMPRESSに変更します。

ALTER TABLE table_name MOVE NOCOMPRESS;

- 各パーティションをNOCOMPRESSに変更するには、次の文を使用します。

ALTER TABLE table_name MOVE PARTITION partition_name NOCOMPRESS;

各パーティションは個別に変更します。

- 次の文を使用して、データをNOCOMPRESSに並列で移動します。

ALTER TABLE table_name MOVE NOCOMPRESS PARALLEL;

関連項目:

- RMANの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- ALTER TABLEコマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

圧縮表に関する注意およびその他の制限事項

圧縮表に関して、次の注意点や制限があります。

- オンラインによるセグメントの縮小は、圧縮表ではサポートされていません。

- この項で説明する表圧縮方法は、SecureFilesラージ・オブジェクト(LOB)には適用されません。SecureFiles LOBには独自の圧縮方法があります。詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

- 圧縮テクノロジではCPUを使用します。追加の負荷を処理するために使用可能なCPUが十分にあることを確認する必要があります。

- 基本圧縮で作成された表では、特に指定しないかぎり、PCT_FREEパラメータが自動的に0(ゼロ)に設定されます。

圧縮表のパック

基本圧縮またはハイブリッド列圧縮で圧縮した表で従来のDMLを使用すると、挿入および更新されるすべての行は非圧縮、または低レベルの圧縮形式で保存されます。このような行が圧縮されるように圧縮表をパックするには、ALTER TABLE MOVE文を使用できます。この操作には表の排他ロックが必要なため、この操作が完了するまで更新とロードを実行しないでください。このような状況が望ましくない場合は、表のオンライン再定義を使用できます。

関連項目:

- CREATE TABLE...COMPRESS文、ALTER TABLE...COMPRESS文、ALTER TABLE...MOVE文および制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 表のパーティション化の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- 「ダイレクト・パスINSERTを使用したINSERTパフォーマンスの向上」

- 「表のオンライン再定義」

機密データを格納する列の暗号化

機密データを格納する個々の表の列を暗号化できます。機密データには、社会保障番号、クレジット・カード番号、医療記録などがあります。列の暗号化は、アプリケーションに対して完全に透過的ですが、いくつか制限事項があります。

暗号化は、セキュリティの問題をすべて解決するわけではありませんが、ユーザーがデータベースのセキュリティ機能を迂回して、オペレーティング・システムのファイル・システムから直接データベース・ファイルにアクセスしようとした場合に、そのユーザーからデータを保護します。

列暗号化はOracle Databaseの透過的データ暗号化機能を使用しますが、この機能を使用するには、データベースのマスター暗号化鍵を保存するためにOracleウォレットを作成する必要があります。暗号化列を含む表を作成する場合、および暗号化データを格納または取得する場合は、ウォレットがオープンしている必要があります。ウォレットは、オープンするとすべてのセッションで使用可能になり、明示的にクローズするか、データベースが停止されるまではオープンしたままになります。

透過的データ暗号化では、次に示すAdvanced Encryption Standard(AES)アルゴリズムやTriple Data Encryption Standard(3DES)アルゴリズムなど、業界標準の暗号化アルゴリズムがサポートされています。

- AES256

- AES192

- AES128

- 3DES168

使用するアルゴリズムは表の作成時に選択します。表のすべての暗号化列で同じアルゴリズムが使用されます。デフォルトはAES192です。暗号化キーの長さはアルゴリズム名で示されています。たとえば、AES128アルゴリズムでは128ビットのキーが使用されます。

1つ以上の表にある多数の列を暗号化する場合は、かわりに表領域全体を暗号化してその表領域にこれらの表を格納することも考慮できます。表領域の暗号化でも同様に透過的データ暗号化機能が使用されますが、物理的なブロック・レベルで暗号化されるため、多数の列を暗号化するよりパフォーマンスが向上します。表領域レベルで暗号化する別の理由は、列暗号化の次の制限事項に対処するためです。

- COMPATIBLE初期化パラメータが10.2.0(透過的データ暗号化を使用可能にするための最小設定値)に設定されている場合、ソートまたはハッシュ結合に関与していて一時表領域に書き込まれる暗号化列のデータは、平文で書き込まれるため、攻撃にさらされます。一時表領域に書き込まれる暗号化データを暗号化されたままにするには、COMPATIBLEを11.1.0以上に設定する必要があります。なお、UNDO表領域またはREDOログに書き込まれる場合は、COMPATIBLEが10.2.0以上に設定されていれば、暗号化列のデータは暗号化されたままです。

- オブジェクト・データ型などの特定のデータ型は、列暗号化ではサポートされていません。

- 暗号化列がある表が含まれた表領域に対しては、トランスポータブル表領域機能を使用できません。

- その他の制限の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

関連項目:

- 「暗号化された表領域」

- 「例: 表の作成」

- 透過的データ暗号化の詳細およびウォレットを作成して開く手順は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- CREATE TABLE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- Oracle Real Application Clusters環境でOracleウォレットを使用する方法については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- 「データベース間での表領域のトランスポート」

セグメント作成の遅延の理解

Oracle Database 11g リリース2以降、ローカルで管理される表領域内にヒープ構成表を作成すると、最初の行が挿入されるまで表セグメントの作成が遅延されます。

さらに、セグメントの作成は、表のすべてのLOB列、表作成の一環として暗黙的に作成されたすべての索引、および後から明示的にその表に作成されたすべての索引に対して遅延されます。

注意:
リリース11.2.0.1では、パーティション表に対するセグメント作成の遅延はサポートされていません。この制限は、リリース11.2.0.2以降では除去されています。

この領域割当て方法の利点は次のとおりです。

- インストール時に何百もの表が作成され、その表の多くに一度もデータが移入されないようなアプリケーションで、ディスク領域が大幅に削減されます。

- アプリケーションのインストール時間が短縮されます。

最初の行が挿入される際に新しいセグメントを作成する必要があるため、パフォーマンスが多少低下します。

セグメント作成の遅延を有効にするには、互換性を11.2.0以上に設定する必要があります。

CREATE TABLE文に新たに導入された句は、次のとおりです。

- SEGMENT CREATION DEFERRED

- SEGMENT CREATION IMMEDIATE

これらの句は、セグメントの作成を遅延するDEFERRED_SEGMENT_CREATION初期化パラメータのデフォルト設定であるTRUEを上書きします。セグメントの作成の遅延を無効にするには、このパラメータをFALSEに設定します。

セグメント作成を遅延する設定で表を作成すると、新しい表が*_TABLESビューに表示されますが、その表のエントリは最初の行を入力するまで*_SEGMENTSビューに表示されません。

セグメント作成の遅延を確認するには、非パーティション表の場合は*_TABLES、*_INDEXES、*_LOBSの各ビュー、パーティション表の場合は*_TAB_PARTITIONS、*_IND_PARTITIONS、*_LOB_PARTITIONSの各ビューでSEGMENT_CREATED列を参照します。

注意:
この新しい割当て方法では、適切な容量計画を行い、表へのデータ移入時にセグメントの作成を処理できるだけの十分なディスク領域がデータベースにあるようにすることが重要です。「データベース・オブジェクトの容量計画」を参照してください。

次の例では2つの表を作成し、遅延セグメント作成を実現します。最初の表はSEGMENT CREATION DEFERRED句を使用します。最初はセグメントが作成されません。2番目の表はSEGMENT CREATION IMMEDIATE句を使用するため、セグメントが即時作成されます。

CREATE TABLE part_time_employees (
empno NUMBER(8),
name VARCHAR2(30),
hourly_rate NUMBER (7,2)
)
SEGMENT CREATION DEFERRED;

CREATE TABLE hourly_employees (
empno NUMBER(8),
name VARCHAR2(30),
hourly_rate NUMBER (7,2)
)
SEGMENT CREATION IMMEDIATE
PARTITION BY RANGE(empno)
(PARTITION empno_to_100 VALUES LESS THAN (100),
PARTITION empno_to_200 VALUES LESS THAN (200));

USER_SEGMENTSに対する次の問合せにより、HOURLY_EMPLOYEESの行はパーティションごとに1つずつ計2つ返されますが、PART_TIME_EMPLOYEESの行はこの表のセグメント作成が遅延されたため返されません。

SELECT segment_name, partition_name FROM user_segments;

SEGMENT_NAME         PARTITION_NAME
-------------------- ------------------------------
HOURLY_EMPLOYEES     EMPNO_TO_100
HOURLY_EMPLOYEES     EMPNO_TO_200

USER_TABLESビューには、PART_TIME_EMPLOYEESにセグメントがないことが示されます。

SELECT table_name, segment_created FROM user_tables;

TABLE_NAME                     SEGMENT_CREATED
------------------------------ ----------------------------------------
PART_TIME_EMPLOYEES            NO
HOURLY_EMPLOYEES               N/A

HOURLY_EMPLOYEES表がパーティション表である場合、SEGMENT_CREATED列はN/Aになっています。これは、USER_TABLESビューには、パーティション表のこの列に関する情報がないためです。次のように、USER_TAB_PARTITIONSビューから参照できます。

SELECT table_name, segment_created, partition_name
FROM user_tab_partitions;

TABLE_NAME           SEGMENT_CREATED      PARTITION_NAME
-------------------- -------------------- ------------------------------
HOURLY_EMPLOYEES     YES                  EMPNO_TO_100
HOURLY_EMPLOYEES     YES                  EMPNO_TO_200

次の文は、従業員をこれらの表に追加しています。

INSERT INTO hourly_employees VALUES (99, 'FRose', 20.00);
INSERT INTO hourly_employees VALUES (150, 'LRose', 25.00);

INSERT INTO part_time_employees VALUES (50, 'KReilly', 10.00);

前述のように同じSELECT文を繰り返すと、行データが挿入されるため、PART_TIME_EMPLOYEESにセグメントが作成されました。HOURLY_EMPLOYEESは前述のままです。

SELECT segment_name, partition_name FROM user_segments;

SEGMENT_NAME         PARTITION_NAME
-------------------- ------------------------------
PART_TIME_EMPLOYEES
HOURLY_EMPLOYEES     EMPNO_TO_100
HOURLY_EMPLOYEES     EMPNO_TO_200

SELECT table_name, segment_created FROM user_tables;

TABLE_NAME           SEGMENT_CREATED
-------------------- --------------------
PART_TIME_EMPLOYEES  YES
HOURLY_EMPLOYEES     N/A

USER_TAB_PARTITIONSビューに変更はありません。

関連項目:
セグメント作成の遅延に関する注意および制限は、『Oracle Database SQL言語リファレンス』を参照してください。

セグメントのマテリアライズ

Oracle Database 11g リリース2(11.2.0.2)からは、DBMS_SPACE_ADMINパッケージにはMATERIALIZE_DEFERRED_SEGMENTS()プロシージャが含まれています。このプロシージャを使用すると、セグメント作成の遅延が有効であるときに作成された表、表パーティションおよび依存オブジェクトのセグメントをマテリアライズできます。

最初から必要以上のセグメントを設定して不必要にデータベース・リソースを使用するのではなく、必要に応じてセグメントを追加できます。

次の例では、HRスキーマのEMPLOYEES表のセグメントをマテリアライズしています。

BEGIN
DBMS_SPACE_ADMIN.MATERIALIZE_DEFERRED_SEGMENTS(
schema_name  => 'HR',
table_name   => 'EMPLOYEES');
END;

関連項目:
このプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

表サイズの見積りと見積りに応じた計画

表を作成する前に表のサイズを見積ります。見積りは、なるべくデータベース計画の一部として実行します。データベース表のサイズと用途を確認することは、データベース計画の重要な部分です。

表の見積りサイズの合計と、索引、UNDO領域およびREDOログ・ファイルの見積りを使用して、作成するデータベースを格納するために必要なディスク容量を決定できます。この見積りによって、適切なハードウェアを購入できます。

見積ったサイズと個々の表サイズの増加率を使用すると、作成する表に最適な表領域の属性とその基礎となるデータファイルを的確に判断できます。これによって、表のディスク領域の管理が容易になり、表を使用するアプリケーションのI/Oパフォーマンスが向上します。

関連項目:
「データベース・オブジェクトの容量計画」

表作成時の制限事項

表の計画と使用に影響を与える可能性のある制限事項がいくつかあります。

- オブジェクト型を含む表は、Oracle8より古いバージョンのデータベースにインポートできません。

- エクスポートされた表は、異なるスキーマで同じ名前の付いた既存の表にマージできません。

- オリジナルのデータがデータベースにまだ存在するときは、型とエクステント表を異なるスキーマには移動できません。

- Oracle Databaseには、表が持つ列(またはオブジェクト型の属性)の合計数に制限があります。この制限の詳細は、『Oracle Databaseリファレンス』を参照してください。
ユーザー定義型のデータを含む表を作成すると、ユーザー定義型の列はその型データを格納するリレーショナル列にマップされます。これにより、追加のリレーショナル列が作成されます。これらのリレーショナル列は「非表示」で、DESCRIBE表の文では表示されず、SELECT *文でも返されません。したがって、オブジェクト表、REFの列を持つリレーショナル表、VARRAY、ネストした表またはオブジェクト型を作成するときは、データベースが表に対して実際に作成した列の合計数が、指定した数よりも多くなることがあるので注意してください。

関連項目:
ユーザー定義型の詳細は、Oracle Databaseオブジェクト・リレーショナル開発者ガイドを参照

表の作成

自分のスキーマに新しい表を作成するには、CREATE TABLEシステム権限が必要です。別のユーザーのスキーマに表を作成するには、CREATE ANY TABLEシステム権限が必要です。また、表の所有者には、その表を含む表領域に対する割当て制限またはUNLIMITED TABLESPACEシステム権限が必要です。

表はSQL文CREATE TABLEを使用して作成します。

この項の内容は次のとおりです。

- 例: 表の作成

- 一時表の作成

- 表作成のパラレル化

関連項目:
この章で説明しているCREATE TABLEなどのSQL文の正確な構文は、『Oracle Database SQL言語リファレンス』を参照してください。

例: 表の作成

次の文を発行すると、表admin_empがhrスキーマに作成され、admin_tbs表領域に格納されます。

CREATE TABLE hr.admin_emp (
empno      NUMBER(5) PRIMARY KEY,
ename      VARCHAR2(15) NOT NULL,
ssn        NUMBER(9) ENCRYPT USING 'AES256',
job        VARCHAR2(10),
mgr        NUMBER(5),
hiredate   DATE DEFAULT (sysdate),
photo      BLOB,
sal        NUMBER(7,2),
hrly_rate  NUMBER(7,2) GENERATED ALWAYS AS (sal/2080),
comm       NUMBER(7,2),
deptno     NUMBER(3) NOT NULL
CONSTRAINT admin_dept_fkey REFERENCES hr.departments
(department_id))
TABLESPACE admin_tbs
STORAGE ( INITIAL 50K);

COMMENT ON TABLE hr.admin_emp IS 'Enhanced employee table';

次に、この例について説明します。

- 表の複数の列で整合性制約が定義されています。

- STORAGE句では、第1エクステントのサイズが指定されています。この句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 1つの列(ssn)で、Oracle Databaseの透過的データ暗号化機能を使用した暗号化が定義されています。したがって、このCREATE TABLE文を正常に実行するためには、Oracleウォレットがオープンしている必要があります。

- photo列はデータ型がBLOBで、これはラージ・オブジェクト(LOB)と呼ばれるデータ型のセットのメンバーです。LOBは、準構造化データ(XMLツリーなど)および非構造化データ(カラー・イメージのビット・ストリームなど)の保存に使用されます。

- 1つの列(hrly_rate)が仮想列として定義されています。この列は、年収を2,080で除算して従業員の時給を計算しています。仮想列に関するルールの説明は、『Oracle Database SQL言語リファレンス』を参照してください。

- COMMENT文を使用して、表に関するコメントが格納されています。*_TAB_COMMENTSデータ・ディクショナリ・ビューを問い合せると、このようなコメントを取得できます。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

関連項目:

- 表の列に指定できるデータ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 「整合性制約の管理」

- 透過的データ暗号化およびOracleウォレットの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- LOBの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

一時表の作成

一時表は、複数のDML操作の実行によって作成されるため、結果セットがバッファリング(一時的に保存)されるアプリケーションに有用です。たとえば、次の場合を考えてみましょう。

Webベースの航空予約アプリケーションでは、顧客がオプションの旅程を複数作成できます。各旅程は一時表の行で表されます。アプリケーションは、旅程への変更を反映するように行を更新します。使用する旅程を顧客が決定すると、アプリケーションは、該当する旅程の行を永続表に移動します。

セッションの開始時から終了時まで旅程データはプライベートです。セッションの終了時に、オプションの旅程は削除されます。

一時表の定義はすべてのセッションで参照できますが、一時表内のデータを参照できるのは、そのデータを表に挿入するセッションのみです。

CREATE GLOBAL TEMPORARY TABLE文を使用して一時表を作成します。ON COMMIT句は、表内のデータがトランザクション固有(デフォルト)またはセッション固有のいずれであるかを示し、それぞれの意味は次のとおりです。

ON COMMIT設定

意味

DELETE ROWS

トランザクション固有の一時表を作成します。セッションは、表に最初に挿入するトランザクションを持つ一時表に対するバインドになります。バインドは、トランザクション終了時に消失します。表は、各コミット後に切捨て(すべての行を削除)が行われます。

PRESERVE ROWS

セッション固有の一時表を作成します。セッションは、セッション内で表に最初に挿入される一時表に対するバインドになります。このバインドは、セッションの最後で、またはセッション内で表に対するTRUNCATEが発行されることによって消去されます。表は、セッション終了時に切り捨てられます。

次の文では、トランザクション固有の一時表を作成しています。

CREATE GLOBAL TEMPORARY TABLE admin_work_area
(startdate DATE,
enddate DATE,
class CHAR(20))
ON COMMIT DELETE ROWS;

一時表には索引を作成できます。この索引も一時索引であり、索引内のデータのセッションまたはトランザクションの有効範囲は、基礎となる表のデータと同じです。

デフォルトで、一時表の行は、作成したユーザーのデフォルト一時表領域に保存されます。ただし、一時表の作成時にCREATE GLOBAL TEMPORARY TABLEのTABLESPACE句を使用することにより、一時表を別の表領域に割り当てることができます。この機能を使用することにより、一時表が使用する領域を節約できます。たとえば、多数の小さな一時表操作を実行する必要があり、デフォルトの一時表領域がソート操作用に構成されていて、かつ大きなエクステント・サイズを使用する場合、これらの小さな操作は大量の不必要なディスク領域を消費します。このような場合、小さいエクステント・サイズを持つ別の一時表領域を割り当てることをお薦めします。

次の2つの文では、エクステント・サイズが64KBで一時表領域が作成され、その表領域に新規の一時表が作成されます。

CREATE TEMPORARY TABLESPACE tbs_t1
TEMPFILE 'tbs_t1.f' SIZE 50m REUSE AUTOEXTEND ON
MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K;

CREATE GLOBAL TEMPORARY TABLE admin_work_area
(startdate DATE,
enddate DATE,
class CHAR(20))
ON COMMIT DELETE ROWS
TABLESPACE tbs_t1;

関連項目:
「一時表領域」

永続表とは異なり、一時表とその索引には、作成時にセグメントが自動的に割り当てられません。かわりに、最初にINSERT(またはCREATE TABLE AS SELECT)が実行されると、セグメントが割り当てられます。したがって、最初のINSERTの前に、SELECT、UPDATEまたはDELETEが実行されると、表が空に見えます。

既存の一時表でDDL操作(TRUNCATEを除く)が許可されるのは、その一時表にバインドされているセッションがない場合のみです。

トランザクションをロールバックすると、入力したデータは消失しますが、表定義はそのまま残ります。

トランザクション固有の一時表では、1回に1トランザクションのみが許可されます。単一のトランザクションに複数の自律型トランザクションがある場合、各自律型トランザクションは、直前のトランザクションのコミット直後にのみ表を使用できます。

一時表のデータは、その定義どおり一時的なため、一時表データのバックアップとリカバリはシステム障害のイベントでは使用できません。このような障害に備えて、一時表データを保存する代替方法を用意してください。

表作成のパラレル化

表の作成にAS SELECT句を指定して、別の表からデータを移入すると、パラレル実行を使用できます。CREATE TABLE...AS SELECT文には、CREATE部分(DDL)とSELECT部分(問合せ)の2つの部分があります。Oracle Databaseでは、この文の両方の部分をパラレル化できます。CREATEの部分がパラレル化されるのは、次の中の1つに該当する場合です。

- PARALLEL句がCREATE TABLE...AS SELECT文に含まれている。

- ALTER SESSION FORCE PARALLEL DDL文が指定されている。

問合せ部分がパラレル化されるのは、次のすべてに該当する場合です。

- 問合せにパラレル・ヒントの指定(PARALLELまたはPARALLEL_INDEX)が含まれるか、またはCREATEの部分にPARALLEL句が含まれているか、または問合せで参照されているスキーマ・オブジェクトにPARALLEL宣言が関連付けられている。

- 問合せに指定された少なくとも1つの表で、全表スキャンまたは複数のパーティションに及ぶ索引レンジ・スキャンが必要である。

表の作成をパラレル化した場合、その表には対応付けられたパラレル宣言(PARALLEL句)が付きます。表に対するその後のすべてのDMLまたは問合せでは、パラレル化が可能な場合、パラレル実行の使用が試みられます。

表の作成をパラレル化し、表圧縮を使用して圧縮形式で結果を格納する簡単な文を次に示します。

CREATE TABLE hr.admin_emp_dept
PARALLEL COMPRESS
AS SELECT * FROM hr.employees
WHERE department_id = 10;

この場合のPARALLEL句は、表の作成時に最適な数のパラレル実行サーバーを選択することをデータベースに指示しています。

関連項目:

- パラレル実行の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- 「SQLのパラレル実行用プロセスの管理」

表のロード

ここでは、データを表にロードするための手法について説明します。内容は、次のとおりです。

- 表のロード方法

- ダイレクト・パスINSERTを使用したINSERTパフォーマンスの向上

- 従来型のインサートを使用した表のロード

- DMLエラー・ロギングを使用したバルクINSERT失敗の回避

注意:
Oracle Databaseのリリース11.2.0.2からは、パーティション表のすべての新規セグメントについて、第1エクステントのデフォルトのサイズが64KBではなく8MBになりました。このことは、パーティション表に対する挿入と問合せのパフォーマンス向上に役立ちます。パーティション表の初期サイズが大きくても、十分なデータが挿入されると、領域消費は以前のリリースと同じになります。このデフォルトは、表の記憶域句にINITIALサイズを設定して上書きできます。この新しいデフォルトは、表パーティションおよびLOBパーティションにのみ適用されます。

表のロード方法

表にデータを挿入または初期ロードするには、いくつかの方法があります。最も一般的に使用される方法は、次のとおりです。

方法

説明

SQL*Loader

これは、外部ファイルからOracle Databaseの表にデータをロードするOracleのユーティリティ・プログラムです。
SQL*Loaderの詳細は、『Oracle Databaseユーティリティ』を参照してください。

CREATE TABLE ... AS SELECT文(CTAS)

このSQL文を使用すると、表を作成し、外部表を含む別の既存の表から選択したデータを移入できます。

INSERT文

INSERT文を使用すると、列値を指定するか、または外部表を含む別の既存の表からデータを選択する副問合せを指定することによって、行を表に追加できます。
INSERT文の1つの形式では、ダイレクト・パスINSERTが使用可能になり、これよってパフォーマンスを改善でき、バルク・ロードの際に役立ちます。「ダイレクト・パスINSERTを使用したINSERTパフォーマンスの向上」を参照してください。

大量のデータを挿入するときにエラーが発生した場合の文の終了およびロールバックを回避するには、DMLエラー・ロギングを指定して挿入できます。「DMLエラー・ロギングを使用したバルクINSERT失敗の回避」を参照してください。

MERGE文

MERGE文を使用すると、別の既存の表から行を選択することによって、行を表に挿入するか、または表の行を更新できます。新しいデータの行が、表にすでに存在している項目に対応している場合はUPDATEが実行され、対応する項目がない場合はINSERTが実行されます。

CREATE TABLE ...の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。AS SELECT、INSERTおよびMERGE文

注意:
このマニュアルに記載されている、表にデータを挿入する詳細と例は少数です。データ・ウェアハウスおよびアプリケーション開発に関するオラクル社のマニュアルには、表へのデータの挿入および操作に関する広範囲にわたる情報が記載されています。関連項目:

- 『Oracle Databaseデータ・ウェアハウス・ガイド』

- 『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』

関連項目:
「外部表の管理」

ダイレクト・パスINSERTを使用したINSERTパフォーマンスの向上

大量のデータをロードするときは、ダイレクト・パスINSERTを使用してロードのパフォーマンスを高めることができます。

この項の内容は次のとおりです。

- ダイレクト・パスINSERTの概要

- ダイレクト・パスINSERTの動作

- ダイレクト・パスINSERTを使用したデータのロード

- ダイレクト・パスINSERTのロギング・モードの指定

- ダイレクト・パスINSERTのその他の考慮事項

ダイレクト・パスINSERTの概要

Oracle Databaseでは、次の2つのいずれかの方法でデータが挿入されます。

- 従来型のINSERT処理では、表内の空き領域が再利用され、新規に挿入するデータと既存のデータが相互に配置されます。このような操作では、参照整合性制約も維持されます。

- ダイレクト・パスINSERT処理では、表内の既存データの後ろに挿入データが追加されます。データは、バッファ・キャッシュを回避してデータファイルに直接書き込まれます。表の空き領域は再利用されず、参照整合性制約は無視されます。ダイレクト・パスINSERTは従来型のインサートよりもパフォーマンスが大幅に優れています。

データベースは、1つのプロセスが文を実行するシリアル・モードか、同時に多数のプロセスが連携して1つのSQL文を実行するパラレル・モードでデータを挿入できます。後者はパラレル実行と呼ばれます。

ダイレクト・パスINSERTの利点は、次のとおりです。

- ダイレクト・パスINSERTでは、REDOおよびUNDOエントリのロギングを使用禁止にしてロード時間を削減できます。これに対して、従来型のインサート処理では空き領域を再利用し、参照整合性を維持するため、これらのエントリを常にロギングする必要があります。

- ダイレクト・パスINSERT処理は、パラレル・モードで実行する場合でも、トランザクションの原子性が保証されます。原子性は、パラレル・ダイレクト・パス・ロード(SQL*Loaderを使用)では保証されません。

パラレル・ダイレクト・パス・ロード実行時のSQL*LoaderとINSERT文の間の大きな違いの1つは、SQL*Loaderによるパラレル・ダイレクト・パス・ロード中にエラーが発生した場合、ロードは完了しますが、一部の索引にはロードの終了時にUNUSABLEのマークが付くことです。対照的に、パラレル・ダイレクト・パスINSERTの場合は、索引更新時にエラーが発生すると、文がロールバックされます。

注意:
従来のINSERT操作では、挿入中のNOT NULL制約の違反をチェックします。そのため、従来のINSERT操作のNOT NULL制約に違反すると、挿入時にエラーが返されます。ダイレクト・パスINSERT操作では、挿入前にNOT NULL制約の違反をチェックします。そのため、ダイレクト・パスINSERT操作のNOT NULL制約に違反した場合は、挿入前にエラーが返されます。

ダイレクト・パスINSERTの動作

ダイレクト・パスINSERTは、パーティション表と非パーティション表の両方で使用できます。

パーティション表または非パーティション表へのシリアル・ダイレクト・パスINSERT

単一のプロセスは、表セグメントまたは各パーティション・セグメントの現在の最高水位標を超えてもデータを挿入します。(最高水位標とは、ブロックがデータを受け取るためにフォーマットされたことのないレベルを指します。)COMMITが実行されると、最高水位標が新しい値に更新され、データがユーザーに表示可能になります。

パーティション表へのパラレル・ダイレクト・パスINSERT

この状況は、シリアル・ダイレクト・パスINSERTと類似しています。各パラレル実行サーバーが1つ以上のパーティションに割り当てられ、1つのパーティションでは1つのプロセスしか実行されません。各パラレル実行サーバー割り当てられたパーティション・セグメントの現在の最高水位標を超えてもデータを挿入します。COMMITが実行されると、各パーティション・セグメントの最高水位標が新しい値に更新され、データがユーザーに表示可能になります。

非パーティション表へのパラレル・ダイレクト・パスINSERT

各パラレル実行サーバーは、新しい一時セグメントを割り当て、その一時セグメントにデータを挿入します。COMMITを実行すると、パラレル実行コーディネータが新しい一時セグメントをプライマリ表セグメントにマージし、ユーザーにデータが表示されます。

ダイレクト・パスINSERTを使用したデータのロード

ダイレクト・パスINSERT SQL文を使用してパラレル・モードでデータを挿入するか、またはOracleのSQL*Loaderユーティリティをダイレクト・パス・モードで使用することによって、ダイレクト・パスINSERTを使用してデータをロードできます。ダイレクト・パスINSERTトは、シリアル・モードまたはパラレル・モードで実行できます。

SQL文を使用したシリアル・モード・インサート

SQLを使用したシリアル・モードでのダイレクト・パスINSERTは、次の方法でアクティブ化します。

- 副問合せを使用してINSERTを実行している場合は、INSERTキーワードの直後またはINSERT文の副問合せのSELECTキーワードの直後にある各INSERT文にAPPENDヒントを指定します。

- VALUES句を使用してINSERTを実行している場合は、INSERTキーワードの直後にある各INSERT文にAPPEND_VALUESヒントを指定します。VALUES句を使用するダイレクト・パスINSERTは、ロードする行が数百、数千またはさらに膨大な数になる場合の使用が最適です。一般的な使用例として、OCIを使用した配列の挿入があります。また、PL/SQLのFORALL文での挿入に使用する例もあります。

VALUES句を使用するINSERT文にAPPENDヒント(APPEND_VALUESヒントではなく)を指定すると、このAPPENDヒントは無視され、従来の挿入が実行されます。

ダイレクト・パスINSERTを実行するためにAPPENDヒントを使用する例を次に示します。

INSERT /*+ APPEND */ INTO sales_hist SELECT * FROM sales WHERE cust_id=8890;

次のPL/SQLコードの一部は、APPEND_VALUESヒントの使用例です。

FORALL i IN 1..numrecords
INSERT /*+ APPEND_VALUES */ INTO orderdata
VALUES(ordernum(i), custid(i), orderdate(i),shipmode(i), paymentid(i));
COMMIT;

SQL文を使用したパラレル・モード・インサート

パラレル・モードで挿入する場合は、ダイレクト・パスINSERTがデフォルトです。ただし、NOAPPEND PARALLELヒントを使用して、従来型のINSERTを使用したパラレル・モードでの挿入も実行できます。

パラレルDMLモードで実行するには、次の要件を満たす必要があります。

- Oracle Enterprise Editionがインストールされていること。

- セッションでパラレルDMLが使用可能であること。そのためには、次の文を発行します。

ALTER SESSION { ENABLE | FORCE } PARALLEL DML;

- 次の要件を最低1つ満たす必要があります。

- ターゲット標のパラレル属性を、作成時またはその後に指定すること。

- 各挿入操作に対してPARALLELヒントを指定すること。

- データベースの初期化パラメータPARALLEL_DEGREE_POLICYをAUTOに指定すること。

ダイレクト・パスINSERTを使用禁止にするには、各INSERT文にNOAPPENDヒントを指定します。この指定によって、パラレルDMLモードが無視されます。

注意:
ダイレクト・パスINSERTによって挿入したデータを、挿入した直後に問合せまたは変更することはできません。問合せまたは変更を試みると、ORA-12838エラーが発生します。新しく挿入したデータの読取りまたは変更を試みる前に、COMMIT文を発行する必要があります。

関連項目:

- 「従来型のインサートを使用した表のロード」

- ヒントの使用方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- INSERT文の副問合せ構文の詳細およびダイレクト・パスINSERTの使用に関する追加の制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。

ダイレクト・パスINSERTのロギング・モードの指定

ダイレクト・パスINSERTでは、インサート処理中のREDOおよびUNDO情報を記録するかどうかを選択できます。

- 作成時(CREATE文で)または作成後(ALTER文で)に、表、パーティション、索引またはLOB記憶域について、ロギング・モードを指定できます。

- 作成時または作成後にLOGGINGまたはNOLOGGINGを指定しないと、次のようにデフォルト設定されます。

- パーティションのロギング属性は、その表のロギング属性にデフォルト設定されます。

- 表または索引のロギング属性は、常駐している表領域のロギング属性にデフォルト設定されます。

- LOB記憶域のロギング属性は、LOB記憶域にCACHEを指定した場合はLOGGINGにデフォルト設定されます。CACHEを指定しなかった場合、ロギング属性はLOB値が常駐している表領域の属性にデフォルト設定されます。

- CREATE TABLESPACEまたはALTER TABLESPACE文で、表領域のロギング属性を設定します。

注意:
データベースまたは表領域がFORCE LOGGINGモードの場合、ダイレクト・パスINSERTは、ロギング設定に関係なく常にロギングされます。

ロギング付きダイレクト・パスINSERT

このモードでは、Oracle Databaseによってインスタンスの完全なREDOロギングおよびメディア・リカバリが実行されます。データベースがARCHIVELOGモードの場合は、REDOログをテープにアーカイブできます。データベースがNOARCHIVELOG モードの場合、インスタンスのクラッシュはリカバリできますが、ディスク障害はリカバリできません。

ロギングなしダイレクト・パスINSERT

このモードでは、Oracle DatabaseはデータをREDOまたはUNDOロギングなしでデータを挿入します。かわりにデータベースは少数のブロック範囲無効化REDOレコードをロギングし、定期的に最新の直接書込みに関する情報で制御ファイルを更新します。

ロギングなしダイレクト・パスINSERTを使用すると、パフォーマンスが向上します。ただし、後でメディア・リカバリを実行する必要がある場合は、REDOデータがロギングされていないため、無効化REDOレコードによって一連のブロックに論理的破損のマークが付きます。したがって、このようなインサート処理の後にはデータをバックアップすることが重要です。

Oracle Databaseのリリース11.2.0.2からは、制御ファイルの定期更新を無効にして、リカバリ不能なダイレクト・パス・インサートのパフォーマンスを大幅に向上させることができます。このことを行うには、DB_UNRECOVERABLE_SCN_TRACKING初期化パラメータをFALSEに設定します。ただし、これらの制御ファイルの更新を無効化してリカバリ不能なダイレクト・パス・インサートを実行すると、データファイルが現在リカバリ不能かどうかをデータベースに問い合せて正確に判断できなくなります。

関連項目:

- リカバリ不能なデータファイルの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 『Oracle Data Guard概要および管理』のリカバリ不能操作後にバックアップが必要かどうかの判断に関する項を参照してください。

ダイレクト・パスINSERTのその他の考慮事項

ダイレクト・パスINSERTを使用する際には、さらに次の考慮事項があります。

圧縮表

表が基本圧縮で作成されている場合は、ダイレクト・パスINSERTを使用して、表のデータをロード時に圧縮する必要があります。表がOLTP、ウェアハウスまたはアーカイブ圧縮で作成されている場合は、ダイレクト・パスINSERTによって最適な圧縮率が得られます。

詳細は、「表圧縮の使用」を参照してください。

ダイレクト・パスINSERTでの索引メンテナンス

索引がある(パーティションまたは非パーティション)表では、ダイレクト・パスINSERT処理の終了時に、Oracle Databaseが索引メンテナンスを実行します。この索引メンテナンスは、パラレル・ダイレクト・パスINSERTに対してはパラレル実行サーバーで、シリアル・ダイレクト・パスINSERTに対してはシングル・プロセスで実行されます。INSERT処理の前に索引を使用禁止にし、後で再作成することによって、索引メンテナンスでのパフォーマンスへの影響を回避できます。

関連項目:
「索引の使用禁止化」

ダイレクト・パスINSERTでの領域に関する考慮事項

ダイレクト・パスINSERTは、従来型パスINSERTよりも多くの領域を必要とします。

すべてのシリアル・ダイレクト・パスINSERT処理では、パーティション表へのパラレル・ダイレクト・パスINSERTと同様に、影響を受けるセグメントの最高水位標の上にデータが挿入されます。このため、追加の領域が必要となります。

非パーティション表へのパラレル・ダイレクト・パスINSERTは、各並列度ごとに一時セグメントを作成するため、より多くの領域を必要とします。非パーティション表が自動セグメント領域管理モードのローカル管理表領域にない場合は、NEXTおよびPCTINCREASE記憶域パラメータ、およびMINIMUM EXTENT表領域パラメータの値を変更して、一時セグメントに十分な(かつ過剰ではない)記憶域を用意してください。次の事項を考慮に入れ、これらのパラメータに値を選択します。

- 各エクステントのサイズは、さほど小さくありません(1MB以上)。この設定は、オブジェクト内のエクステント総数に影響を与えます。

- 各エクステントのサイズが小さいと、パラレルINSERTでは、必要以上に大きいセグメントで領域を無駄にすることになります。

これらのパラメータは、ダイレクト・パスINSERT処理の完了後に、シリアル処理に適した設定に再設定できます。

ダイレクト・パスINSERTでのロックに関する考慮事項

ダイレクト・パスINSERT中は、データベースは表(またはパーティション表のすべてのパーティション)に対して排他的ロックを取得します。その結果、ユーザーは同時挿入、更新、または削除操作を表に対して実行できず、同時索引作成および構築操作は許可されません。ただし、同時問合せはサポートされますが、問合せで返されるのは挿入操作前の情報のみです。

従来型のインサートを使用した表のロード

従来型のINSERT処理では、表内の空き領域が再利用され、新規に挿入するデータと既存のデータが相互に配置されます。このような操作では、参照整合性制約も維持されます。ダイレクト・パスINSERT操作と異なり、従来型のINSERT操作は表に対する排他的ロックを必要としません。

ダイレクト・パスINSERT操作に適用される他のいくつかの制約も、従来型のINSERT操作には該当しません。これらの制限事項については、『Oracle Database SQL言語リファレンス』を参照してください。

従来型のINSERT操作は、NOAPPENDヒントを使用して、シリアル・モードまたはパラレル・モードで実行できます。

従来型のINSERTをシリアル・モードで実行するためにNOAPPENDヒントを使用する例を次に示します。

INSERT /*+ NOAPPEND */ INTO sales_hist SELECT * FROM sales WHERE cust_id=8890;

従来型のINSERTをパラレル・モードで実行するためにNOAPPENDヒントを使用する例を次に示します。

INSERT /*+ NOAPPEND PARALLEL */ INTO sales_hist
SELECT * FROM sales;

パラレルDMLモードで実行するには、次の要件を満たす必要があります。

- Oracle Enterprise Editionがインストールされていること。

- セッションでパラレルDMLが使用可能であること。そのためには、次の文を発行します。

ALTER SESSION { ENABLE | FORCE } PARALLEL DML;

- 次の要件を最低1つ満たす必要があります。

- ターゲット標のパラレル属性を、作成時またはその後に指定すること。

- 各挿入操作に対してPARALLELヒントを指定すること。

- データベースの初期化パラメータPARALLEL_DEGREE_POLICYをAUTOに指定すること。

DMLエラー・ロギングを使用したバルクINSERT失敗の回避

副問合せでINSERT文を使用して表をロードすると、エラーが発生した場合は文が終了して文全体がロールバックされます。これは、時間とシステム・リソースを無駄に消費することになります。このようなINSERT文の場合は、DMLエラー・ロギング機能を使用することで、この状況を回避できます。

DMLエラー・ロギングを使用するには、データベースがDML操作中に検出したエラーを記録するエラー・ロギング表の名前を指定する文の句を追加します。このエラー・ロギング句をINSERT文に追加すると、特定のタイプのエラーで文が終了およびロールバックしなくなります。そのかわり、それぞれのエラーがロギングされ、文が続行します。その後、エラーの発生した行に対して修正アクションを取ることができます。

DMLエラー・ロギングは、INSERT、UPDATE、MERGEおよびDELETE文で機能します。ここでは、特にINSERT文について説明します。

DMLエラー・ロギングを使用してデータを挿入する手順は、次のとおりです。

1. エラー・ロギング表を作成します。(オプション)
表は、手動で作成するか、またはDBMS_ERRLOGパッケージを使用して自動的に作成できます。詳細は、「エラー・ロギング表の作成」を参照してください。

2. エラー・ロギング句を指定してINSERT文を実行します。この句は、次のように動作します。

- 必要に応じて、作成したエラー・ロギング表を参照します。エラー・ロギング表名を指定しない場合、データベースは、デフォルトの名前のエラー・ロギング表に記録します。デフォルトのエラー・ロギング表名は、ERR$_の後に、挿入対象となる表名の最初の25文字を付加した名前です。

- オプションで、エラーの原因となった文を識別するためにエラー・ログに追加されるタグ(丸括弧でくくられた数値または文字列リテラル)が含まれます。タグを省略すると、NULL値が使用されます。

- 必要に応じて、REJECT LIMIT副次句を指定します。
この副次句は、INSERT文が終了およびロールバックされるまでに検出が許可されるエラーの最大数を示します。UNLIMITEDも指定できます。デフォルトの拒否の上限は0(ゼロ)で、これは最初のエラーが検出されると、エラーがロギングされて文がロールバックされることを表します。パラレルDML操作の場合、拒否の制限はパラレル・サーバーごとに適用されます。

注意:
拒否の上限を超えて文がロールバックされた場合、エラー・ロギング表には、その時点までに記録されたログ・エントリが保持されます。

エラー・ロギング句の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

3. エラー・ロギング表を問い合せ、エラーの原因となった行に対する訂正処理を実行します。
エラー・ロギング表の構造は、後述の「エラー・ロギング表の書式」を参照してください。

例: 次の文は、DW_EMPL表に行を挿入し、ERR_EMPL表にエラーを記録します。タグ'daily_load'は、各ログ・エントリにコピーされます。エラー数が25を超えると、文が終了してロールバックされます。

INSERT INTO dw_empl
SELECT employee_id, first_name, last_name, hire_date, salary, department_id
FROM employees
WHERE hire_date > sysdate - 7
LOG ERRORS INTO err_empl ('daily_load') REJECT LIMIT 25

他の例は、『Oracle Database SQL言語リファレンス』および『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

エラー・ロギング表の書式

エラー・ロギング表は、次の2つの部分で構成されます。

- エラーを説明する一連の必須列。Oracleエラー番号の列は、この一例です。
表20-3に、これらのエラーを説明する列を示します。

- エラーの原因となった行のデータが格納される一連のオプション列。列名は、挿入対象の表(DML表)の列名に対応しています。
エラー・ロギング表のこの部分の列数は、0(ゼロ)、1または複数(最大でDML表の列数)の場合があります。DML表の列と同じ名前の列がエラー・ロギング表に存在する場合は、対応するデータが、障害のある挿入予定の行から、このエラー・ロギング表の列に書き込まれます。DML表の列に対応する列がエラー・ロギング表にない場合、その列は記録されません。エラー・ロギング表に、DML表の列と一致しない名前の列がある場合、その列は無視されます。

型変換エラーが発生する場合があるため、エラー・ロギング表のオプション列のデータ型は、データの消失または変換エラーなしで値を取得できる型である必要があります。(オプションのログの列がDML表の列と同じ型だった場合、問題の発生したデータをログに取得すると、エラーの原因となった同じデータ変換の問題が発生する可能性があります。)データベースは、変換エラーの原因となったデータについて、可能なかぎり意味のある値をロギングしようとします。値を導出できなかった場合、NULLが列にロギングされます。エラー・ロギング表への挿入時にエラーが発生すると、文が終了します。

表20-4に、DML表の各データ型について、使用を推奨するエラー・ロギング表の列のデータ型を示します。DBMS_ERRLOGパッケージを使用してエラー・ロギングを自動的に作成すると、これらの推奨データ型が使用されます。

表20-3 エラーを説明する必須列

列名

データ型

説明

ORA_ERR_NUMBER$

NUMBER

Oracleエラー番号

ORA_ERR_MESG$

VARCHAR2(2000)

Oracleエラー・メッセージのテキスト

ORA_ERR_ROWID$

ROWID

エラーとなった行のROWID(更新および削除の場合)

ORA_ERR_OPTYP$

VARCHAR2(2)

操作の種類: 挿入(I)、更新(U)、削除(D)

注意: MERGE操作のUPDATE句およびINSERT句のエラーは、UおよびIの値で区別されます。

ORA_ERR_TAG$

VARCHAR2(2000)

ユーザーがエラー・ロギング句に指定したタグの値

表20-4 エラー・ロギング表の列のデータ型

DML表の列の型

エラー・ロギング表の列の型

注意

NUMBER

VARCHAR2(4000)

変換エラーを記録できます。

CHAR/VARCHAR2(n)

VARCHAR2(4000)

情報の消失なしで値を記録します。

NCHAR/NVARCHAR2(n)

NVARCHAR2(4000)

情報の消失なしで値を記録します。

DATE/TIMESTAMP

VARCHAR2(4000)

情報の消失なしで値を記録します。デフォルトの日時書式マスクを使用して文字書式に変換します。

RAW

RAW(2000)

情報の消失なしで値を記録します。

ROWID

UROWID

ROWID型を記録します。

LONG/LOB

サポートしていません。

ユーザー定義型

サポートしていません。

エラー・ロギング表の作成

エラー・ロギング表は手動で作成できます。または、PL/SQLパッケージを使用して自動的に作成できます。

エラー・ロギング表の自動作成

エラー・ロギング表を自動作成するには、DBMS_ERRLOGパッケージを使用します。CREATE_ERROR_LOGプロシージャは、エラーを説明するための必須列および指定されたDML表の列をすべて備えたエラー・ロギング表を作成し、表20-4に示したデータ型マッピングを実行します。

次の文は、前述の例で使用したエラー・ロギング表を作成します。

EXECUTE DBMS_ERRLOG.CREATE_ERROR_LOG('DW_EMPL', 'ERR_EMPL');

DBMS_ERRLOGの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

手動によるエラー・ロギング表の作成

エラー・ロギング表を手動で作成するには、標準DDLを使用します。表の構造の要件は、「エラー・ロギング表の書式」を参照してください。エラーを説明するための必須列はすべて挿入する必要があります。列は順不同にできますが、必須列は表の最初の方の列に指定する必要があります。

エラー・ロギングの制限事項と注意

Oracle Databaseは、DML操作中に次のエラーを記録します。

- 列の値が大きすぎる場合

- 制約(NOT NULL制約、一意制約、参照制約、CHECK制約)違反の場合

- トリガー実行時にエラーが発生した場合

- 副問合せの列と表内の対応する列との間の型変換でエラーが発生した場合

- パーティション・マッピング・エラーの場合

- MERGE操作エラー(ORA-30926: MERGE操作の安定したセット行を取得できません。)

一部のエラーは記録されずに、DML操作の終了およびロールバックが実施されます。これらのエラーの一覧とDMLロギングの他の制約は、『Oracle Database SQL言語リファレンス』のINSERTに関する項でerror_logging_clauseの説明を参照してください。

領域に関する考慮事項

DMLエラー・ロギングを使用するには、その前に領域の要件について考慮する必要があります。挿入する表の領域のみでなく、エラー・ロギング表の領域も必要です。

セキュリティ

DMLエラー・ロギングを指定したINSERT文を発行するユーザーには、エラー・ロギング表に対するINSERT権限が必要です。

関連項目:
DMLエラー・ロギングの例は、『Oracle Database SQL言語リファレンス』および『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

表に関する統計の自動収集

PL/SQLパッケージDBMS_STATSを使用すると、コストベースの最適化に関する統計を生成および管理できます。このパッケージを使用して、統計の収集、変更、表示、エクスポート、インポートおよび削除ができます。また、すでに収集した統計を識別または命名する際も、このパッケージを使用できます。

以前は、DBMS_STATSを使用可能にし、CREATE(またはALTER) TABLE文でMONITORINGキーワードを指定して、表の統計を自動的に収集していました。Oracle Database 11gからは、MONITORINGおよびNOMONITORINGキーワードは非推奨になり、統計は自動的に収集されます。これらのキーワードを指定しても無視されます。

監視では、統計が最後に収集された時点以降表に対して実行されたINSERT、UPDATEおよびDELETEの概数が追跡されます。影響を受ける行数に関する情報は、SMONが周期的に(およそ3時間ごとに)データをデータ・ディクショナリに取り込むまで、システム・グローバル領域(SGA)に保持されます。このデータ・ディクショナリの情報は、DBA_TAB_MODIFICATIONS,ALL_TAB_MODIFICATIONSまたはUSER_TAB_MODIFICATIONSビューで表示可能です。データベースはこれらのビューを使用して、失効した統計を持つ表を識別します。

STATISTICS_LEVEL初期化パラメータのデフォルトはTYPICALで、これは自動統計収集機能を有効にします。自動統計収集とDBMS_STATSパッケージによって、オプティマイザは正確な実行計画を生成できます。STATISTICS_LEVEL初期化パラメータをBASICに設定すると、Oracle Database機能で必要とされる多くの重要な統計が収集されません。すべての表の監視を使用禁止にするには、STATISTICS_LEVEL初期化パラメータをBASICに設定します。自動統計収集とDBMS_STATSパッケージによって、オプティマイザは正確な実行計画を生成できます。

関連項目:

- STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- オプティマイザ統計の管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- DBMS_STATSパッケージの使用方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- スケジューラを使用して統計を自動的に収集する方法は、「自動化メンテナンス・タスクの概要」を参照してください。

表の変更

表を変更するにはALTER TABLE文を使用します。表を変更するには、その表が自分のスキーマに含まれているか、その表のALTERオブジェクト権限またはALTER ANY TABLEシステム権限のいずれかを持っている必要があります。

ALTER TABLE文の使用方法については、次の各項を参照してください。

- ALTER TABLE文を使用する理由

- 表の物理属性の変更

- 新規セグメントまたは表領域への表の移動

- 表の記憶域の手動割当て

- 既存の列定義の変更

- 表の列の追加

- 表の列名の変更

- 表の列の削除

- 表を読取り専用モードにする方法

注意:
表を変更する前に、表を変更した結果についてよく理解しておいてください。これらの結果については、『Oracle Database SQL言語リファレンス』のALTER TABLE句の説明を参照してください。
パッケージのビュー、マテリアライズド・ビュー、トリガー、ドメイン索引、ファンクション索引、CHECK制約、ファンクション、プロシージャが実表に依存する場合は、その実表または列を変更すると依存するオブジェクトに影響する可能性があります。データベースによる依存性管理の詳細は、「オブジェクト依存性の管理」を参照してください。

ALTER TABLE文を使用する理由

ALTER TABLE文は、表に影響を与える次の処理を実行するために使用できます。

- 物理的な特性(INITRANSまたは記憶域パラメータ)を変更する場合

- 表を新しいセグメントまたは表領域に移動する場合

- 明示的にエクステントを割り当てるか、未使用領域の割当てを解除する場合

- 列を追加、削除または名前変更する場合、あるいは既存の列定義(データ型、長さ、デフォルト値、NOT NULL整合性制約、列の式(仮想列の場合)および暗号化プロパティ)を変更する場合

- 表のロギング属性を変更する場合

- CACHE/NOCACHE属性を変更する場合

- 表に関連付けられている整合性制約を追加、変更または削除する場合

- 表に関連付けられている整合性制約またはトリガーを使用可能にするか、使用禁止にする場合

- 表の並列度を変更する場合

- 表の名前を変更する場合

- 表を読取り専用モードにする場合および読取り/書込みモードに戻す場合

- 索引構成表の特性を追加または変更する場合

- 外部表の特性を変更する場合

- LOB列を追加または変更する場合

- オブジェクト型、ネストした表またはVARRAYの列を追加または変更する場合

これらの多くのタスクについて、次の各項で説明します。

表の物理属性の変更

表のトランザクション・エントリ設定INITRANSを変更する場合、INITRANSの新しい設定は、その後表に割り当てられるデータ・ブロックにのみ適用されます。

記憶域パラメータINITIALとMINEXTENTSは変更できません。他の記憶域パラメータ(NEXT、PCTINCREASEなど)の新しい設定はすべて、その後に表に割り当てられるエクステントにのみ影響します。次に割り当てられるエクステントのサイズはNEXTおよびPCTINCREASEの現在の値によって決定され、これらのパラメータの以前の値には基づきません。

関連項目:
物理属性句と記憶域句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

新規セグメントまたは表領域への表の移動

ALTER TABLE...MOVE文を使用すると、非パーティション表のデータまたはパーティション表のパーティションのデータを新しいセグメントに再配置でき、オプションとして、割当て制限を持つ別の表領域への再配置もできます。また、この文によって、ALTER TABLEでは変更できないものも含めた、表またはパーティションのすべての記憶域属性を変更できます。さらに、ALTER TABLE...MOVE文をCOMPRESS句とともに使用することによって、新しいセグメントを表圧縮を使用して保存できます。

表を新規データファイルを含む新しい表領域に移動する重要な理由の1つは、列データの古いバージョン(セグメントの縮小、再編成または以前の表移動によってディスクの未使用部分に現在も残されているバージョン)が、オペレーティング・システム・ユーティリティなどを使用してデータベースのアクセス制御を迂回することによって参照される可能性をなくすためです。これは、透過的データ暗号化を追加して変更しようとしている列の場合は特に重要です。

注意:
ALTER TABLE...MOVE文では、文の実行中は表に対するDML操作が許可されません。表の移動中にも表に対してDMLを使用できるようにする場合は、「表のオンライン再定義」を参照してください。

次の文は、新しい記憶域パラメータを指定して、hr.admin_emp表を新しいセグメントおよび表領域に移動します。

ALTER TABLE hr.admin_emp MOVE
STORAGE ( INITIAL 20K
NEXT 40K
MINEXTENTS 2
MAXEXTENTS 20
PCTINCREASE 0 )
TABLESPACE hr_tbs;

表を移動すると、表の行のROWIDが変わります。これによって、表の索引にUNUSABLEのマークが付き、これらの索引を使用して表にアクセスするDMLに対しては、ORA-01502エラーが返されます。表の索引を削除または再作成する必要があります。同様に、表の統計は無効になるため、表を移動した後に新しい統計を収集する必要があります。

表にLOB列が含まれている場合は、この文を使用して、ユーザーが明示的に指定できるLOBデータと、表に関連したLOB索引セグメントを、表とともに移動できます。特に指定しない場合、デフォルトではLOBデータとLOB索引セグメントは移動されません。

関連項目:
透過的データ暗号化の詳細は、「機密データを格納する列の暗号化」を参照してください。

表の記憶域の手動割当て

Oracle Databaseは、必要に応じて表のデータ・セグメントに追加のエクステントを動的に割り当てます。ただし、表に追加のエクステントを明示的に割り当てることもできます。たとえば、Oracle Real Application Clusters環境で、表のエクステントを特定のインスタンスに対して明示的に割り当てることが可能です。

新しいエクステントは、ALTER TABLE...ALLOCATE EXTENT句を使用して表に割り当てることができます。

また、ALTER TABLE文のDEALLOCATE UNUSED句を使用して、未使用領域の割当てを明示的に解除することもできます。詳細は、「使用できない領域の再生」を参照してください。

既存の列定義の変更

既存の列定義を変更するには、ALTER TABLE...MODIFY文を使用します。列のデータ型、デフォルト値、列制約、列の式(仮想列の場合)または列の暗号化は変更できます。

既存のデータがすべて新しい長さを満たしている場合は、既存の列の長さを拡張または縮小できます。列は、バイト・セマンティクスからCHARセマンティクスに、あるいはその逆に変更できます。空でないCHAR列の長さを縮小するには、初期化パラメータBLANK_TRIMMING=TRUEを設定する必要があります。

データ型CHARの列長を拡張するために表を変更している場合、特に表の行数が多い場合は、この操作は時間がかかり、さらに相当な追加記憶域を必要とする可能性があります。これは、各行のCHAR値に空白を埋めて、新しい列長に合わせる必要があるためです。

関連項目:
表の列の変更の詳細およびその他の制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。

表の列の追加

既存の表に列を追加するには、ALTER TABLE...ADD文を使用します。

次の文は、hr.admin_emp表を変更して新しい列bonusを追加します。

ALTER TABLE hr.admin_emp
ADD (bonus NUMBER (7,2));

表に新しい列を追加すると、DEFAULT句を指定しないかぎり、その列は最初はNULLです。デフォルト値を指定すると、各行がデフォルト値で即時に更新されます。この処理に多少時間を要すること、および更新時には表に排他DMLロックがかかることに注意してください。表のタイプ(例: LOB列のない表)によっては、NOT NULL制約とデフォルト値の両方を指定すると、データベースによって列の追加操作が最適化され、表がDML用にロックされる時間が大幅に短縮されます。

NOT NULL制約付きの列を追加できるのは、表に行がまったく含まれていない場合、またはデフォルト値を指定する場合のみです。

関連項目:
表の列の追加に関するその他のルールおよび制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。

圧縮表への列の追加

表での基本圧縮を有効化する場合は、デフォルト値を指定しない場合にのみ、列を追加できます。

表でのOLTP圧縮を有効化する場合は、デフォルト値を指定してもしなくても、その表に列を追加できます。デフォルト値を指定する場合、列はNOT NULLであることが必要です。

関連項目:
「表圧縮の使用」

仮想列の追加

新しい列が仮想列の場合、値は列の式によって決定されます。(仮想列の値は問い合せられたときにのみ計算される点に注意してください。)

関連項目:

- 『Oracle Database概要』

- 仮想列の例については、「例: 表の作成」を参照

表の列名の変更

Oracle Databaseでは、表の既存の列の名前を変更できます。列名を変更するには、ALTER TABLE文のRENAME COLUMN句を使用します。新しい名前には、表の既存の列名と競合しない名前を指定する必要があります。RENAME COLUMN句とともに他の句は使用できません。

次の文は、hr.admin_emp表のcomm列の名前を変更します。

ALTER TABLE hr.admin_emp
RENAME COLUMN comm TO commission;

前述のように、表の列を変更すると、依存するオブジェクトが無効になる可能性があります。ただし、列名を変更すると、ファンクション索引とCHECK制約が引き続き有効になるように、関連するデータ・ディクショナリ表が更新されます。

また、Oracle Databaseでは列制約の名前も変更できます。この操作の説明は、「制約名の変更」を参照してください。

注意:
ALTER TABLEのRENAME TO句の構文はRENAME COLUMN句に似ていますが、表自体の名前変更に使用します。

表の列の削除

索引構成表などの表から、不要になった列を削除できます。これにより、データベースの領域を解放でき、データをエクスポート/インポートしてから索引と制約を再作成する必要がなくなります。

表からすべての列を削除したり、SYSが所有する表の列を削除することはできません。その場合はエラーが発生します。

関連項目:
表からの列の削除に関するその他の制限事項およびオプションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表から列を削除する方法

ALTER TABLE...DROP COLUMN文を発行すると、列記述子およびターゲット列に関連付けられているデータが表の各行から削除されます。1つの文で複数の列を削除できます。

次の文は、hr.admin_emp表から列を削除する操作の例を示しています。最初の文は、sal列のみを削除します。

ALTER TABLE hr.admin_emp DROP COLUMN sal;

次の文は、bonus列とcomm列を両方とも削除します。

ALTER TABLE hr.admin_emp DROP (bonus, commission);

列に未使用マークを付ける方法

大きい表のすべての行から列データを削除する際に所要時間が重要な場合は、ALTER TABLE...SET UNUSED文を使用できます。この文は1つ以上の列に未使用マークを付けますが、実際にターゲット列を削除したり該当列が占めるディスク領域をリストアすることはありません。ただし、未使用マークが付けられた列は、問合せやデータ・ディクショナリ・ビューに表示されなくなり、その名前が削除されて新しい列に再利用できるようになります。ほとんどの場合、その列に定義されている制約、索引および統計も削除されます。例外として、未使用とマークされたLOB列の内部索引は削除されません。

hiredate列とmgr列に未使用マークを付けるには、次の文を実行します。

ALTER TABLE hr.admin_emp SET UNUSED (hiredate, mgr);

後でALTER TABLE...DROP UNUSED COLUMNS文を発行し、未使用マークが付いている列を削除できます。表の特定列の明示的な削除文を発行すると、未使用列もターゲット表から削除されます。

データ・ディクショナリ・ビューUSER_UNUSED_COL_TABS、ALL_UNUSED_COL_TABSまたはDBA_UNUSED_COL_TABSを使用すると、未使用の列を含むすべての表を表示できます。COUNTフィールドには、表の未使用の列数が表示されます。

SELECT * FROM DBA_UNUSED_COL_TABS;

OWNER                       TABLE_NAME                  COUNT
--------------------------- --------------------------- -----
HR                          ADMIN_EMP                       2

外部表の場合は、SET UNUSED文がALTER TABLE DROP COLUMN文に透過的に変換されます。外部表はデータベース内でメタデータのみで構成されているため、DROP COLUMN文はSET UNUSED文の実行と同じことになります。

未使用列の削除

未使用の列に対して実行できるアクションはALTER TABLE...DROP UNUSED COLUMNS文のみです。表から未使用の列を物理的に削除し、ディスク領域を再生します。

次のALTER TABLE文では、オプションの句CHECKPOINTが指定されています。この句を指定すると、指定した行数(この場合は250行)が処理された後に、チェックポイントが適用されます。チェックポイントによって、列削除操作中に累積されるUNDOログの量が減少し、UNDO領域が使い果たされるおそれがなくなります。

ALTER TABLE hr.admin_emp DROP UNUSED COLUMNS CHECKPOINT 250;

圧縮表の列の削除

表でのOLTP圧縮を有効化する場合は、表の列を削除できます。基本圧縮のみを有効化する場合は、表の列を削除できません。

関連項目:
「表圧縮の使用」

表を読取り専用モードにする方法

表を読取り専用モードにするには、ALTER TABLE...READ ONLY文を使用し、表を読取り/書込みモードに戻すには、ALTER TABLE...READ WRITE文を使用します。読取り専用モードが有効な表の例に、構成表があります。アプリケーションに含まれている構成表が、インストール後変更されず、ユーザーによる変更を禁止する必要がある場合は、アプリケーションのインストール・スクリプトによって、これらの表を読取り専用モードにできます。

表を読取り専用モードにするには、その表に対するALTER TABLE権限、またはALTER ANY TABLE権限が必要です。また、COMPATIBLE初期化パラメータが11.1.0以上に設定されている必要があります。

次の例は、SALES表を読取り専用モードにします。

ALTER TABLE SALES READ ONLY;

次の例は、表を読取り/書込みモードに戻します。

ALTER TABLE SALES READ WRITE;

表が読取り専用モードの場合、表データの変更操作は許可されません。読取り専用表で許可されない操作は、次のとおりです。

- 表またはそのパーティションに対するすべてのDML操作

- TRUNCATE TABLE

- SELECT FOR UPDATE

- ALTER TABLE ADD/MODIFY/RENAME/DROP COLUMN

- ALTER TABLE SET COLUMN UNUSED

- ALTER TABLE DROP/TRUNCATE/EXCHANGE (SUB)PARTITION

- 読取り専用表が関係している型に対するALTER TABLE UPGRADE INCLUDING DATAまたはALTER TYPE CASCADE INCLUDING TABLE DATA

- オンライン再定義

- FLASHBACK TABLE

読取り専用表で許可される操作は、次のとおりです。

- SELECT

- CREATE/ALTER/DROP INDEX

- ALTER TABLE ADD/MODIFY/DROP/ENABLE/DISABLE CONSTRAINT

- 物理的なプロパティ変更のためのALTER TABLE

- ALTER TABLE DROP UNUSED COLUMNS

- ALTER TABLE ADD/COALESCE/MERGE/MODIFY/MOVE/RENAME/SPLIT (SUB)PARTITION

- ALTER TABLE MOVE

- ALTER TABLE ENABLE ROW MOVEMENTおよびALTER TABLE SHRINK

- RENAME TABLEおよびALTER TABLE RENAME TO

- DROP TABLE

- ALTER TABLE DEALLOCATE UNUSED

- ALTER TABLE ADD/DROP SUPPLEMENTAL LOG

関連項目:
ALTER TABLE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表のオンライン再定義

データベース・システムでは、次のような理由で表の構造を論理的または物理的に変更する必要が生じます。

- 問合せまたはDMLのパフォーマンスを改善するため

- アプリケーションの変更に対応するため

- 記憶域を管理するため

Oracle Databaseには、表の可用性に大きな影響を与えずに表の構造を変更できるメカニズムが用意されています。このメカニズムは、表のオンライン再定義と呼ばれます。表のオンライン再定義では、表を再定義する従来の方法に比べて、可用性が大幅に向上します。

オンラインで表を再定義している間も、その再定義プロセスの大部分で、問合せおよびDMLを使用してその表にアクセスできます。通常、表が排他モードでロックされるのは、そのサイズや再定義の複雑さに関係なくわずかな間のみで、ユーザーに対しては完全に透過的です。ただし、再定義中に数多くの同時DML操作がある場合、表をロックできるようになる前に、より長く待機することが必要になることがあります。待機によって、より多くの変更が元の表に対してコミットされるため、リフレッシュ時間と表がロックされている時間が長くなります。

表のオンライン再定義には、再定義の対象となる表が使用している領域とほぼ同等の空き領域が必要です。新しい列を追加する場合は、より多くの領域が必要になります。

表のオンライン再定義を実行するには、Enterprise Managerのオブジェクトの再編成ウィザードまたはDBMS_REDEFINITIONパッケージを使用します。

注意:
オブジェクトの再編成ウィザードを起動する手順は、次のとおりです。

1. Enterprise Managerの「表」ページで「選択」列をクリックし、再定義する表を選択します。

2. 「アクション」リストで、「再編成」を選択します。

3. 「実行」をクリックします。

この項では、DBMS_REDEFINITIONパッケージを使用したオンライン再定義について説明します。内容は次のとおりです。

- 表のオンライン再定義の機能

- DBMS_REDEFINITIONを使用したオンライン再定義の実行

- 再定義プロセスの結果

- 中間での同期化の実行

- エラー後の表のオンライン再定義の強制終了およびクリーン・アップ

- 表のオンライン再定義に関する制限事項

- 単一パーティションのオンライン再定義

- 表のオンライン再定義の例

- DBMS_REDEFINITIONパッケージに必要な権限

関連項目:
DBMS_REDEFINITIONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

表のオンライン再定義の機能

表のオンライン再定義では、次のことが可能です。

- 表またはクラスタの記憶域パラメータの変更

- 異なる表領域への表またはクラスタの移動

注意:
表を別の表領域に移動する際に、DMLでその表を使用する必要性がない場合は、より簡単なALTER TABLE MOVEコマンドを使用できます。「新規セグメントまたは表領域への表の移動」を参照してください。

- 表またはクラスタの1つ以上の列の追加、変更、または削除

- パーティション化サポートの追加または削除(非クラスタ化表のみ)

- パーティション構造の変更

- 同じスキーマ内の別の表領域へのパーティションの移動を含む、単一の表パーティションの物理的なプロパティの変更

- マテリアライズド・ビュー・ログまたはOracle Streamsアドバンスト・キューイングのキュー表の物理的なプロパティの変更

- パラレル問合せのサポートの追加

- 表またはクラスタの再作成による断片化の低減

注意:
多くの場合、オンラインによるセグメントの縮小が断片化を削減する簡単な方法です。「使用できない領域の再生」を参照してください。

- 通常の表(ヒープ構成表)から索引構成表へ、または索引構成表から通常の表への編成の変更。

- リレーショナル表からオブジェクト列を持つ表へ、またはオブジェクト列を持つ表からリレーショナル表への変換。

- オブジェクト表からリレーショナル表またはオブジェクト列を持つ表へ、あるいはリレーショナル表またはオブジェクト列を持つ表からオブジェクト表への変換。

DBMS_REDEFINITIONを使用したオンライン再定義の実行

表のオンライン再定義を実行するには、DBMS_REDEFINITIONパッケージを使用します。パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

オンラインで表を再定義する手順は、次のとおりです。

1. 再定義方法(キー別またはROWID別)を選択します。
キー別: 再定義に使用する主キーまたは疑似主キーを選択します。疑似主キーは、NOT NULL制約が指定されているすべての構成要素の列を備えた一意のキーです。この方法の場合、表の再定義前のバージョンと再定義後のバージョンの主キー列は同じになります。これはデフォルトの再定義方法であり、この方法を使用することをお薦めします。

ROWID別: キーが存在しない場合、この方法を使用します。この方法では、M_ROW$$という名前の非表示列が、表の再定義後のバージョンに追加されます。再定義の完了後、この列を削除するか、未使用としてマークすることをお薦めします。COMPATIBLEが10.2.0以上に設定されている場合、再定義の最終フェーズで自動的にこの列が未使用に設定されます。その後、ALTER TABLE ... DROP UNUSED COLUMNS文を使用して削除できます。

この方法は、索引構成表に対しては使用できません。

2. CAN_REDEF_TABLEプロシージャを起動して、表をオンラインで再定義できることを確認します。表がオンライン再定義の候補でない場合、このプロシージャは表をオンライン再定義できない理由を示すエラーを出力します。

3. 必要な論理属性と物理属性のすべてを備えた空の仮表を(再定義する表と同じスキーマ内に)作成します。削除される列の場合は、仮表の定義に含めないでください。列を追加する場合は、その列の定義を仮表に追加します。列を変更する場合は、必要なプロパティを備えた仮表にその列を作成します。
再定義する表の索引、制約、権限付与およびトリガーすべてを備えた仮表を作成する必要はありません。これらは、依存オブジェクトをコピーするときに手順7で定義します。

4. ROWIDによる方法でパーティション表を再定義する場合は、仮表での行移動を有効にします。

ALTER TABLE ... ENABLE ROW MOVEMENT;

5. (オプション)次の手順のパフォーマンスを改善するために、大きい表の再定義をパラレルで実行する場合は、次の文を発行します。

ALTER SESSION FORCE PARALLEL DML PARALLEL degree-of-parallelism;
ALTER SESSION FORCE PARALLEL QUERY PARALLEL degree-of-parallelism;

6. 次の情報を指定してSTART_REDEF_TABLEをコールし、再定義プロセスを開始します。

- 再定義する表のスキーマと表名

- 仮表名

- 再定義される表の列を仮表の列にマップする列マッピング文字列
詳細は、「列マッピング文字列の作成」を参照してください。

- 再定義方法
再定義方法を指定するために、パッケージ定数が用意されています。DBMS_REDEFINITION.CONS_USE_PKは、主キーまたは擬似主キーを使用して再定義が実行されるように指定するために使用します。DBMS_REDEFINITION.CONS_USE_ROWIDは、ROWIDを使用して再定義が実行されるように指定するために使用します。この引数を指定しない場合は、デフォルトの再定義方法(CONS_USE_PK)が使用されます。

- 行の順序に使用する列(オプション)

- パーティション名(パーティション表の単一のパーティションのみを再定義する場合)

このプロセスにはデータのコピー操作が含まれるため、多少の時間を要する可能性があります。再定義する表は、プロセスの開始から終了まで問合せおよびDMLで使用できます。

注意:

- DBA_REDEFINITION_OBJECTSビューを問い合せると、オンライン再定義に現在関連するオブジェクトをリストできます。

- なんらかの理由でSTART_REDEF_TABLEに失敗した場合は、ABORT_REDEF_TABLEをコールする必要があります。コールしないと、表を再定義する後続の試行でエラーが発生します。

7. 依存オブジェクト(トリガー、索引、マテリアライズド・ビュー・ログ、権限付与および制約など)および統計を、再定義される表から仮表へ、次の2つの方法のいずれかを使用してコピーします。方法1の方がより自動化されているため優先されますが、方法2の使用を選択する場合もあります。また、方法1では、表統計を仮表にコピーできます。

- 方法1: 依存オブジェクトの自動作成
COPY_TABLE_DEPENDENTSプロシージャを使用して、仮表に対する依存オブジェクトを自動的に作成します。このプロシージャは、依存オブジェクトの登録も実施します。依存オブジェクトを登録することで、これらのオブジェクトの個別情報とコピーされた複製を、再定義完了プロセスの一部として後で自動的にスワップできます。その結果、再定義が完了すると、依存オブジェクトの名前がオリジナルの依存オブジェクトと同じ名前になります。

詳細は、「依存オブジェクトの自動作成」を参照してください。

- 方法2: 依存オブジェクトの手動による作成
仮表に対する依存オブジェクトは、手動で作成して登録できます。詳細は、「依存オブジェクトの手動による作成」を参照してください。

注意:
Oracle Databaseリリース9iでは、トリガー、索引、権限付与および制限を仮表に手動で作成する必要がありましたが、まだその必要がある場合もあります。いずれの場合でも、仮表に関係のある参照制限(仮表が参照制約の親表または子表の場合)は、使用不可で作成される必要があります。オンライン再定義が完了した後、参照制限は自動的に使用可能になります。さらに、再定義プロセスが完了または中止されるまで、仮表に定義されたトリガーはまったく実行されません。

8. FINISH_REDEF_TABLEプロシージャを実行して、表の再定義を完了します。このプロシージャの実行中、元の表はそのデータ量とは無関係に、わずかな時間ですが排他モードでロックされます。ただし、FINISH_REDEF_TABLE部分は、保留中のDMLすべてがコミットされるのを待機してから、再定義を完了します。

9. 再定義にROWIDを使用したときに、COMPATIBLE初期化パラメータが10.1.0以下に設定されている場合は、再定義後の表に追加された非表示列(M_ROW$$)を削除するかUNUSEDに設定してください。

ALTER TABLE table_name SET UNUSED (M_ROW$$);

COMPATIBLEが10.2.0以上の場合は、再定義の完了時に非表示列が自動的にUNUSEDに設定されます。次に、ALTER TABLE ... DROP UNUSED COLUMNS文を使用して列を削除できます。

10. 仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。
仮表に対するアクティブな問合せの実行中に仮表を削除すると、ORA-08103エラー(「現在、指定したオブジェクトは存在しません。」)が発生する場合があります。

関連項目:
「表のオンライン再定義の例」

列マッピング文字列の作成

引数としてSTART_REDEF_TABLEに渡す列マッピング文字列には、カンマで区切られた列マッピングのペアのリストが含まれています。各ペアの構文は、次のとおりです。

[expression]  column_name

column_nameは、仮表の列を意味します。オプションのexpressionには、SQL(SELECT)文の式のルールに従って、再定義する表の列、定数、演算子、関数またはメソッド・コールなどを指定できます。ただし、使用できるのは、値がすぐに決定される単純な副次式、つまり、ある評価と次の評価で結果が変化しない副次式と、順序およびSYSDATEのみです。副問合せは使用できません。最も簡単な場合、式は再定義する表の列名のみで構成されます。

式を指定すると、その値は再定義の過程で仮表内の指定の列に配置されます。式を省略した場合は、再定義する表と仮表の両方にcolumn_nameという列が存在し、再定義する表にあるその列の値が仮表の同じ列に配置されていると想定されます。

たとえば、再定義する表のoverride列をoverride_commissionという名前に変更し、すべてのオーバーライド・コミッションを2%増加する場合、正しい列マッピングのペアは次のとおりです。

override*1.02  override_commission

列マッピング文字列に'*'またはNULLを指定すると、すべての列(名前は変更されない)が仮表に配置されることになります。それ以外の場合は、文字列で明示的に指定した列のみが仮表に配置されます。列マッピングのペアの順序は重要ではありません。

列マッピング文字列の例は、「表のオンライン再定義の例」を参照してください。

データの変換 列をマッピングする際は、いくつかの制限はありますが、データ型を変換できます。

'*'またはNULLを列マッピング文字列として指定した場合は、SQLで許可される暗黙的な変換のみがサポートされます。たとえば、CHARからVARCHAR2に、INTEGERからNUMBERに変換できます。

あるオブジェクト型から別のオブジェクト型への変換や、あるコレクション型から別のコレクション型への変換など、その他のデータ型変換を実行するには、変換を実行する式とともに列マッピングのペアを指定する必要があります。式には、CAST関数、TO_NUMBERなどの組込み関数、作成した変換関数などを指定できます。

依存オブジェクトの自動作成

仮表に対する依存オブジェクトを自動的に作成するには、COPY_TABLE_DEPENDENTSプロシージャを使用します。

num_errors出力引数をチェックすることで、依存オブジェクトのコピー中にエラーが発生したかどうかを検出できます。ignore_errors引数をTRUEに設定すると、COPY_TABLE_DEPENDENTSプロシージャは、オブジェクト作成時にエラーを検出しても、依存オブジェクトのコピーを続行します。DBA_REDEFINITION_ERRORSビューを問い合せることで、これらのエラーを確認できます。

エラーには、次のような理由があります。

- システム・リソースの不足

- 依存オブジェクトの再コーディングが必要となるような表の論理構造の変更。
この種のエラーの説明は、「表のオンライン再定義の例」の例3を参照してください。

ignore_errorsをFALSEに設定すると、COPY_TABLE_DEPENDENTSプロシージャは、エラーを検出すると、オブジェクトのコピーをただちに停止します。

エラーを修正してからCOPY_TABLE_DEPENDENTSプロシージャを再実行することで、依存オブジェクトのコピーを再試行できます。「依存オブジェクトの手動による作成」に説明されているように、オブジェクトを手動で作成し、それらを登録することもできます。COPY_TABLE_DEPENDENTSプロシージャは、必要に応じて何回でも使用できます。オブジェクトがすでに正常にコピーされている場合は、再度コピーされません。

依存オブジェクトの手動による作成

SQL*PlusまたはEnterprise Managerで、仮表に対する依存オブジェクトを手動で作成する場合は、REGISTER_DEPENDENT_OBJECTプロシージャを使用して依存オブジェクトを登録する必要があります。依存オブジェクトを登録すると、再定義の完了プロセスで、依存オブジェクト名を再定義前の名前にリストアできます。

COPY_TABLE_DEPENDENTSプロシージャによる依存オブジェクトのコピーがエラーとなり、手動による介入が必要な場合は、REGISTER_DEPENDENT_OBJECTプロシージャを使用します。

DBA_REDEFINITION_OBJECTSビューを問い合せることによって、登録されている依存オブジェクトを判断できます。このビューには、REGISTER_DEPENDENT_OBJECTプロシージャで明示的に登録、またはCOPY_TABLE_DEPENDENTSプロシージャで暗黙的に登録された依存オブジェクトが表示されます。このビューには、現在の情報のみが表示されます。

UNREGISTER_DEPENDENT_OBJECTプロシージャを使用すると、再定義している表および仮表に対する依存オブジェクトの登録を解除できます。

注意:
手動で作成する依存オブジェクトは、対応する元の依存オブジェクトと同一である必要はありません。たとえば、マテリアライズド・ビュー・ログを仮表に手動で作成する場合は、別の列を記録できます。また、仮表の依存オブジェクトが増減してもかまいません。

再定義プロセスの結果

再定義プロセスの最終的な結果は、次のようになります。

- 元の表は、仮表の列、索引、制約、権限付与、トリガーおよび統計を使用して再定義されます。

- REGISTER_DEPENDENT_OBJECTを明示的に使用するか、またはCOPY_TABLE_DEPENDENTSを暗黙的に使用して登録された依存オブジェクトは、自動的に名前が変更されるため、再定義した表の依存オブジェクト名は再定義の前と同じになります。

注意:
登録または自動コピーが行われていない依存オブジェクトの名前は、手動で変更する必要があります。

- 仮表に関与する参照制約は、再定義した表に関与して使用可能になります。

- (再定義前に)元の表に定義されていた索引、トリガー、マテリアライズド・ビュー・ログ、権限付与および制約がすべて仮表に移動し、ユーザーが仮表を削除したときに同時に削除されます。再定義する前に元の表に関与していた参照制約がすべて仮表に関与し、使用禁止になります。

- 一部のPL/SQLオブジェクト、ビュー、シノニムおよびその他の表依存オブジェクトが、無効になる場合があります。変更された表の要素に依存するオブジェクトのみが無効になります。たとえば、再定義で変更されなかった再定義表の列のみを問い合せるPL/SQLプロシージャは有効のままです。スキーマ・オブジェクトの依存性の詳細は、「オブジェクト依存性の管理」を参照してください。

中間での同期化の実行

START_REDEF_TABLEをコールして再定義プロセスを開始してからFINISH_REDEF_TABLEコールが完了するまでの間に、元の表に対して多数のDML文が実行される可能性があります。これが問題になることがわかっている場合は、定期的に仮表を元の表と同期化することをお薦めします。同期化には、SYNC_INTERIM_TABLEプロシージャをコールします。このプロシージャをコールすると、FINISH_REDEF_TABLEで再定義プロセスを完了するための時間が短縮されます。SYNC_INTERIM_TABLEをコールできる回数に制限はありません。

FINISH_REDEF_TABLEの実行中に元の表がロックされるわずかな時間は、SYNC_INTERIM_TABLEのコールの有無とは関係ありません。

エラー後の表のオンライン再定義の強制終了およびクリーン・アップ

再定義プロセス中にエラーが発生した場合、または再定義プロセスの終了を選択した場合は、ABORT_REDEF_TABLEをコールしてください。このプロシージャは、再定義プロセスに対応付けられた一時ログおよび一時表を削除します。このプロシージャをコールした後は、仮表とその依存オブジェクトを削除できます。

オンライン再定義プロセスの再起動が必要な場合は、最初にABORT_REDEF_TABLEをコールしないと、表を再定義する後続の試みでエラーが発生します。

表のオンライン再定義に関する制限事項

表のオンライン再定義には、次の制限が適用されます。

- 表を主キーまたは擬似主キー(すべてのコンポーネント列がNULLでない制約を持つ一意キーまたは制約)を使用して再定義する場合、再定義後の表でも同じ主キーまたは擬似主キー列を使用する必要があります。ROWIDを使用して再定義する表に、索引構成表を含めないでください。

- マテリアライズド・ビュー・ログが含まれている表を再定義した後に依存マテリアライズド・ビューをリフレッシュする場合は、完全リフレッシュを実行する必要があります。

- n-wayマスター構成でレプリケートされた表の再定義は可能ですが、水平サブセット化(表内の行のサブセット)、垂直サブセット化(表内の列のサブセット)または列変換は使用できません。

- 索引構成表のオーバーフロー表は、個別にオンライン再定義できません。

- ファイングレイン・アクセス・コントロール(行レベルのセキュリティ)が設定された表はオンライン再定義できません。

- Flashbackデータ・アーカイブが有効になっている表は、オンラインで再定義できません。Flashbackデータ・アーカイブを仮表に対して有効にはできません。

- BFILE列を持つ表は、オンライン再定義できません。

- 複数のLONG列を保持している表は、オンラインで再定義できますが、これらの列は、CLOBに変換する必要があります。また、LONG RAW列は、BLOBに変換する必要があります。LOB列を持つ表は、オンライン再定義可能です。

- パラレル実行のためのリソースが十分なシステムで、仮表がパーティション化されていない環境では、次の場合にのみ、LONG列からLOB列への再定義をパラレルで実行できます。

- 仮表へのLOB列の格納に使用するセグメントが、自動セグメント領域管理(ASSM)を使用できるローカル管理表領域に属している場合。

- 単一のLONG列から単一のLOB列への簡単なマッピングで、仮表に存在するLOB列が1つのみの場合。

仮表がパーティション化されている場合は、パラレル実行でパーティション化する通常の方法が適用されます。

- SYSおよびSYSTEMスキーマ内の表は、オンライン再定義できません。

- 一時表は再定義できません。

- 表内の行のサブセットは再定義できません。

- 仮表の列を元の表の列にマッピングするときに使用できるのは、値がすぐに決定される単純な式、順序およびSYSDATEのみです。たとえば、副問合せは使用できません。

- 新しい列を再定義の一部として追加しようとして、それらの列に列マッピングがない場合は、その再定義が完了するまでNOT NULLを宣言しないでください。

- 再定義しようとする表と仮表の間では参照制約を作成できません。

- 表の再定義は、NOLOGGINGモードでは実行できません。

- マテリアライズド・ビュー・ログおよびキュー表の場合、オンライン再定義は物理的なプロパティの変更に制限されます。水平サブセット化または垂直サブセット化が使用できず、列の変換もできません。列マッピング文字列に唯一有効な値はNULLです。

- 表に1つ以上のネストした表が含まれている場合、表に対するオンライン再定義は実行できません。

- VARRAYは、列マッピングにCAST演算子を使用してネストした表に変換できます。ただし、ネストした表をVARRAYに変換することはできません。

- DBMS_REDEFINITION.START_REDEF_TABLEプロシージャのcol_mappingパラメータ内の列に順序が含まれている場合、orderby_colsパラメータはNULLでなくてはなりません。

- 参照パーティション化によって複数の表が関連付けられている場合、異なるDBMS_REDEFINITIONセッションにおいてそれらの表でオンライン再定義を同時に実行することはできません。
参照パーティション化の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- オブジェクト表またはXMLType表のオンライン再定義は、他の表に再定義済の表を参照するREF列がある場合に、他の表のREFの参照先がない状態を引き起こす可能性があります。
REFの参照先がないことの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

単一パーティションのオンライン再定義

Oracle Database 10g リリース2からは、表の単一パーティションをオンラインで再定義できます。これは、異なる表領域にパーティションを移動する際に、移動中でもパーティションに対してDMLを使用できるようにする場合などに便利です。

この機能の別の用途は、表全体を再定義する際に、リソース要件を低減するために1度に1つのパーティションずつオンラインで再定義することです。たとえば、異なる表領域に非常に大きな表を移動するには、表を1度に1つのパーティションずつ移動することで、移動を完了するために必要な空き領域とUNDO領域を最小化できます。

単一パーティションの再定義は、次の点で表の再定義とは異なります。

- 依存オブジェクトをコピーする必要はありません。1つのパーティションを再定義する場合、COPY_TABLE_DEPENDENTSプロシージャの使用は有効ではありません。

- 仮表に対してローカル索引を手動で作成する必要があります。

- START_REDEF_TABLEには、NULLの列マッピング文字列が必要です。

- ROWIDによる方法を使用するときには、再定義の最終フェーズで、非表示列M_ROW$$が未使用に設定されるかわりに削除されます。

注意:
パーティションを別の表領域に移動する際に、DMLでそのパーティションを使用する必要性がない場合は、より簡単なALTER TABLE...MOVE PARTITION文を使用できます。
関連項目:

- 『Oracle Database VLDBおよびパーティショニング・ガイド』のパーティションの移動に関する項

- ALTER TABLE...MOVE PARTITION文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

単一パーティションのオンライン再定義のルール

単一パーティションを再定義するための基本的な仕組みは、データベースのパーティション交換機能(ALTER TABLE...EXCHANGE PARTITION)です。したがって、単一パーティションのオンライン定義のルールと制限事項は、この仕組みに基づいて決まります。一般的には、次の制限事項があります。

- 論理的な変更(列の追加や削除など)は許可されません。

- パーティション化する方法の変更(レンジ・パーティション化からハッシュ・パーティション化への変更など)は許可されません。

仮表を定義する際のルールは、次のとおりです。

- 再定義するパーティションが、レンジ、ハッシュまたはリスト・パーティションである場合は、非パーティションの仮表が必要です。

- 再定義するパーティションがレンジ-ハッシュ・コンポジット・パーティション表のレンジ・パーティションである場合は、ハッシュ・パーティション表の仮表が必要です。また、仮表のパーティション化キーは、レンジ-ハッシュ・パーティション表のサブパーティション化キーと同一であり、仮表のパーティション数は、再定義するレンジ・パーティションのサブパーティション数と同一であることが必要です。

- 再定義対象のパーティションがROWIDによる再定義方法を使用するハッシュ・パーティションである場合は、再定義を開始する前に、仮表での行移動を有効にする必要があります。

- 再定義するパーティションがレンジ-リスト・コンポジット・パーティション表のレンジ・パーティションである場合は、リスト・パーティション表の仮表が必要です。また、仮表のパーティション化キーは、レンジ-リスト・パーティション表のサブパーティション化キーと同一であり、仮表のリスト・パーティションの値リストは、再定義するレンジ・パーティションのリスト・サブパーティションの値リストと正確に一致している必要があります。

- 仮表を圧縮するよう定義する場合、ROWIDによる再定義ではなく、キーによる再定義を使用する必要があります。

次の補足ルールは、再定義する表がパーティション化された索引構成表である場合に適用されます。

- 仮表も索引構成されている必要があります。

- 元の表と仮表では、同じ列に対する主キーが同じ順序で保持されている必要があります。

- キー圧縮が使用可能な場合は、元の表と仮表の両方で、同じ接頭辞の長さでキー圧縮が使用可能になっている必要があります。

- オーバーフロー・セグメントがある場合は、元の表と仮表の両方にあるか、または両方にないことが必要です。マッピング表についても同様です。

- 元の表と仮表の両方で、LOB列に対して同じ記憶域属性が必要です。

関連項目:
『Oracle Database VLDBおよびパーティショニング・ガイド』のパーティションの交換に関する項

表のオンライン再定義の例

次の各例について、すべてのDBMS_REDEFINITIONサブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

例

説明

例1

新しい列を追加しパーティションを追加することで、表を再定義します。

例2

オブジェクト・データ型を使用して表を再定義します。

例3

手動で登録した依存オブジェクトを使用して表を再定義します。

例4

単一の表パーティションを異なる表領域に移動して表を再定義します。

例1

この例では、以前に作成した表hr.admin_empの再定義を示しますが、この表には、この時点で列empno、ename、jobおよびdeptnoのみが含まれています。表は次のようにして再定義します。

- 新しい列mgr、hiredate、salおよびbonusを追加します。(これらは元の表では存在しましたが、前の例で削除されました。)

- 新しい列bonusを0に初期化します。

- 列deptnoの値を10増やしています。

- 再定義された表をempnoの範囲でパーティション化します。

この再定義の手順は、次のとおりです。

1. 表がオンライン再定義の候補であることを確認します。この場合は、主キーまたは疑似主キーを使用して再定義が実行されるように指定します。

BEGIN
DBMS_REDEFINITION.CAN_REDEF_TABLE('hr','admin_emp',
DBMS_REDEFINITION.CONS_USE_PK);
END;
/

2. 仮表hr.int_admin_empを作成します。

CREATE TABLE hr.int_admin_emp
(empno      NUMBER(5) PRIMARY KEY,
ename      VARCHAR2(15) NOT NULL,
job        VARCHAR2(10),
mgr        NUMBER(5),
hiredate   DATE DEFAULT (sysdate),
sal        NUMBER(7,2),
deptno     NUMBER(3) NOT NULL,
bonus      NUMBER (7,2) DEFAULT(1000))
PARTITION BY RANGE(empno)
(PARTITION emp1000 VALUES LESS THAN (1000) TABLESPACE admin_tbs,
PARTITION emp2000 VALUES LESS THAN (2000) TABLESPACE admin_tbs2);

3. 再定義プロセスを開始します。

BEGIN
DBMS_REDEFINITION.START_REDEF_TABLE('hr', 'admin_emp','int_admin_emp',
'empno empno, ename ename, job job, deptno+10 deptno, 0 bonus',
dbms_redefinition.cons_use_pk);
END;
/

4. 依存オブジェクトをコピーします。(hr.int_admin_empに対するトリガー、索引、マテリアライズド・ビュー・ログ、権限付与および制約がある場合、それらは自動的に作成されます。)

DECLARE
num_errors PLS_INTEGER;
BEGIN
DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS('hr', 'admin_emp','int_admin_emp',
DBMS_REDEFINITION.CONS_ORIG_PARAMS, TRUE, TRUE, TRUE, TRUE, num_errors);
END;
/

このコールでは、ignore_errors引数がTRUEに設定されていることに注意してください。これは、仮表が主キー制約付きで作成されており、COPY_TABLE_DEPENDENTSによって、主キー制約と索引が元の表からコピーされる際にエラーが発生するためです。これらのエラーは無視できますが、後続の手順に記載されている問合せを実行して、他のエラーの存在を確認する必要があります。

5. DBA_REDEFINITION_ERRORSビューを問い合せて、エラーをチェックします。

SQL> select object_name, base_table_name, ddl_txt from
DBA_REDEFINITION_ERRORS;

OBJECT_NAME   BASE_TABLE_NAME  DDL_TXT
------------- ---------------- ------------------------------
SYS_C005836   ADMIN_EMP        CREATE UNIQUE INDEX "HR"."TMP$
$_SYS_C0058360" ON "HR"."INT_A
DMIN_EMP" ("EMPNO")

SYS_C005836   ADMIN_EMP        ALTER TABLE "HR"."INT_ADMIN_EM
P" ADD CONSTRAINT "TMP$$_SYS_C
0058360" PRIMARY KEY

これらのエラーは、仮表にある既存の主キー制約に起因しているため、無視できます。このアプローチでは、再定義後の表の主キー制約名と索引名が変更されていることに注意してください。別のアプローチを使用すると、エラーの発生と名前の変更を回避できますが、仮表は主キー制約なしで定義されることになります。この例の場合、主キー制約と索引は元の表からコピーされます。

注意:
最良のアプローチは、主キー制約付きで仮表を定義し、REGISTER_DEPENDENT_OBJECTを使用して主キー制約と索引を登録してから、COPY_TABLE_DEPENDENTSで残りの依存オブジェクトをコピーすることです。このアプローチでは、エラーが回避され、再定義した表には常に主キーがあり、依存オブジェクト名も変わりません。

6. 必要に応じて、仮表hr.int_admin_empを同期化します。

BEGIN
DBMS_REDEFINITION.SYNC_INTERIM_TABLE('hr', 'admin_emp', 'int_admin_emp');
END;
/

7. 再定義を完了します。

BEGIN
DBMS_REDEFINITION.FINISH_REDEF_TABLE('hr', 'admin_emp', 'int_admin_emp');
END;
/

この手順が終了するまでに、わずかな間のみ、表hr.admin_empが排他モードでロックされます。このコールの後、表hr.admin_empはhr.int_admin_emp表のすべての属性を持つように再定義されます。

8. 仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。

例2

この例では、列をオブジェクト属性に変更するために表を再定義します。再定義した表にオブジェクト型の新しい列を確保します。

元の表(CUSTOMER)の定義は、次のとおりです。

Name         Type
------------ -------------
CID          NUMBER            <- Primary key
NAME         VARCHAR2(30)
STREET       VARCHAR2(100)
CITY         VARCHAR2(30)
STATE        VARCHAR2(2)
ZIP          NUMBER(5)

新しいオブジェクトの型定義は、次のとおりです。

CREATE TYPE ADDR_T AS OBJECT (
street VARCHAR2(100),
city VARCHAR2(30),
state VARCHAR2(2),
zip NUMBER(5, 0) );

再定義の手順は、次のとおりです。

1. 表がオンライン再定義の候補であることを確認します。主キーまたは疑似主キーを使用して再定義が実行されるように指定します。

BEGIN
DBMS_REDEFINITION.CAN_REDEF_TABLE('STEVE','CUSTOMER',
DBMS_REDEFINITION.CONS_USE_PK);
END;
/

2. 仮表int_customerを作成します。

CREATE TABLE INT_CUSTOMER(
CID NUMBER,
NAME  VARCHAR2(30),
ADDR  ADDR_T);

仮表には主キーが定義されていないことに注意してください。手順5で依存オブジェクトがコピーされると、主キー制約と索引がコピーされます。

3. CUSTOMERは大きい表であるため、後続の手順のためにパラレル操作を指定します。

alter session force parallel dml parallel 4;
alter session force parallel query parallel 4;

4. 主キーを使用して再定義プロセスを開始します。

BEGIN
DBMS_REDEFINITION.START_REDEF_TABLE(
uname       => 'STEVE',
orig_table  => 'CUSTOMER',
int_table   => 'INT_CUSTOMER',
col_mapping => 'cid cid,  name name,
addr_t(street, city, state, zip) addr');
END;
/

addr_t(street, city, state, zip)は、オブジェクト・コンストラクタへのコールです。

5. 依存オブジェクトをコピーします。

DECLARE
num_errors PLS_INTEGER;
BEGIN
DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS(
'STEVE','CUSTOMER','INT_CUSTOMER',DBMS_REDEFINITION.CONS_ORIG_PARAMS,
TRUE, TRUE, TRUE, FALSE, num_errors, TRUE);
END;
/

このコールの最後の引数は、表の統計が仮表にコピーされることを意味します。

6. 必要に応じて、仮表を同期化します。

BEGIN
DBMS_REDEFINITION.SYNC_INTERIM_TABLE('STEVE', 'CUSTOMER', 'INT_CUSTOMER');
END;
/

7. 再定義を完了します。

BEGIN
DBMS_REDEFINITION.FINISH_REDEF_TABLE('STEVE', 'CUSTOMER', 'INT_CUSTOMER');
END;
/

8. 仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。

例3

この例では、依存オブジェクトを手動で作成および登録する必要がある場合を考えてみます。

表T1にはC1という列があり、再定義した後、この列をC2にするとします。C1には索引Index1があると想定します。この場合、COPY_TABLE_DEPENDENTSは、Index1に対応して、仮表に対する索引の作成を試行し、仮表には存在しない列C1に対して索引の作成を試行します。これは結果的にエラーとなります。したがって、列C2に対しては、索引を手動で作成して登録する必要があります。手順は、次のとおりです。

1. 仮表INT_T1を作成し、列C2に対して索引Int_Index1を作成します。

2. CAN_REDEF_TABLEを使用してT1がオンライン定義の候補であることを確認し、次にSTART_REDEF_TABLEを使用して再定義プロセスを開始します。

3. 元(Index1)と仮(Int_Index1)の依存オブジェクトを登録します。

BEGIN
DBMS_REDEFINITION.REGISTER_DEPENDENT_OBJECT(
uname         => 'STEVE',
orig_table    => 'T1',
int_table     => 'INT_T1',
dep_type      => DBMS_REDEFINITION.CONS_INDEX,
dep_owner     => 'STEVE',
dep_orig_name => 'Index1',
dep_int_name  => 'Int_Index1');
END;
/

4. COPY_TABLE_DEPENDENTSを使用して、残りの依存オブジェクトをコピーします。

5. 必要に応じて、仮表を同期化します。

6. 再定義を完了し、仮表を削除します。

例4

この例では、1つのパーティションの再定義を示します。レンジ・パーティション化されたsales tableの最も古いパーティションをTBS_LOW_FREQという名前の表領域に移動します。再定義するパーティションが含まれている表は、次のようにして定義します。

CREATE TABLE salestable
(s_productid NUMBER,
s_saledate DATE,
s_custid NUMBER,
s_totalprice NUMBER)
TABLESPACE users
PARTITION BY RANGE(s_saledate)
(PARTITION sal03q1 VALUES LESS THAN (TO_DATE('01-APR-2003', 'DD-MON-YYYY')),
PARTITION sal03q2 VALUES LESS THAN (TO_DATE('01-JUL-2003', 'DD-MON-YYYY')),
PARTITION sal03q3 VALUES LESS THAN (TO_DATE('01-OCT-2003', 'DD-MON-YYYY')),
PARTITION sal03q4 VALUES LESS THAN (TO_DATE('01-JAN-2004', 'DD-MON-YYYY')));

表には、次のように定義されたローカル・パーティション索引があります。

CREATE INDEX sales_index ON salestable
(s_saledate, s_productid, s_custid) LOCAL;

手順は、次のとおりです。次のプロシージャ・コールでは、パーティション名(part_name)という特別な引数に注目してください。

1. salestableが再定義の候補であることを確認します。

BEGIN
DBMS_REDEFINITION.CAN_REDEF_TABLE(
uname        => 'STEVE',
tname        => 'SALESTABLE',
options_flag => DBMS_REDEFINITION.CONS_USE_ROWID,
part_name    => 'sal03q1');
END;
/

2. TBS_LOW_FREQ表領域に仮表を作成します。これはレンジ・パーティションの再定義であるため、仮表は非パーティション表です。

CREATE TABLE int_salestable
(s_productid NUMBER,
s_saledate DATE,
s_custid NUMBER,
s_totalprice NUMBER)
TABLESPACE tbs_low_freq;

3. ROWIDを使用して再定義プロセスを開始します。

BEGIN
DBMS_REDEFINITION.START_REDEF_TABLE(
uname        => 'STEVE',
orig_table   => 'salestable',
int_table    => 'int_salestable',
col_mapping  => NULL,
options_flag => DBMS_REDEFINITION.CONS_USE_ROWID,
part_name    => 'sal03q1');
END;
/

4. 仮表に対してローカル索引を手動で作成します。

CREATE INDEX int_sales_index ON int_salestable
(s_saledate, s_productid, s_custid)
TABLESPACE tbs_low_freq;

5. 必要に応じて、仮表を同期化します。

BEGIN
DBMS_REDEFINITION.SYNC_INTERIM_TABLE(
uname      => 'STEVE',
orig_table => 'salestable',
int_table  => 'int_salestable',
part_name  => 'sal03q1');
END;
/

6. 再定義を完了します。

BEGIN
DBMS_REDEFINITION.FINISH_REDEF_TABLE(
uname      => 'STEVE',
orig_table => 'salestable',
int_table  => 'int_salestable',
part_name  => 'sal03q1');
END;
/

7. 仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。

次の問合せは、最も古いパーティションが新しい表領域に移動したことを示します。

select partition_name, tablespace_name from user_tab_partitions
where table_name = 'SALESTABLE';

PARTITION_NAME                 TABLESPACE_NAME
------------------------------ ------------------------------
SAL03Q1                        TBS_LOW_FREQ
SAL03Q2                        USERS
SAL03Q3                        USERS
SAL03Q4                        USERS

4 rows selected.

DBMS_REDEFINITIONパッケージに必要な権限

DBMS_REDEFINITIONパッケージの実行権限は、パッケージ内のサブプログラムの実行に必要です。DBMS_REDEFINITIONパッケージの実行権限は、EXECUTE_CATALOG_ROLEに付与されます。

さらに、パッケージを使用してユーザーのスキーマの表を再定義するには、ユーザーは次の権限を付与されている必要があります。

- CREATE TABLE

- CREATE MATERIALIZED VIEW

COPY_TABLE_DEPENDENTSプロシージャを実行するには、CREATE TRIGGER権限も必要です。

パッケージを使用して他のスキーマの表を再定義するには、ユーザーは次の権限を付与されている必要があります。

- CREATE ANY TABLE

- ALTER ANY TABLE

- DROP ANY TABLE

- LOCK ANY TABLE

- SELECT ANY TABLE

他のスキーマの表でCOPY_TABLE_DEPENDENTSを実行するには、次の追加権限が必要です。

- CREATE ANY TRIGGER

- CREATE ANY INDEX

エラーが発生した表の変更の調査と取消し

表に対してエラーが発生する変更を調査して取り消せるようにするために、Oracle Databaseには、データベース・オブジェクトの過去の状態を表示したり、Point-in-Timeメディア・リカバリを使用せずにデータベース・オブジェクトを以前の状態に戻すために使用できる一連の機能が用意されています。これらの機能はOracle Flashback機能と呼ばれており、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』で説明されています。

エラーが発生する変更を調査するために、複数のOracle Flashback問合せを使用して、特定の時点における行データを表示できます。さらに効率的な方法として、Oracle Flashback Version Queryを使用して、ある期間にわたる行への変更すべてを表示できます。この機能では、SELECT文にVERSIONS句を追加できるため、行の値への変更を表示するシステム変更番号(SCN)またはタイムスタンプの範囲を指定できます。この問合せでは、変更の原因となったトランザクションなど、関連するメタデータを返すこともできます。

エラーが発生するトランザクションを特定した後、Oracle Flashback Transaction Queryを使用して、そのトランザクションで実行された他の変更を特定できます。次に、Oracle Flashback Transactionを使用して、エラーが発生するトランザクションを取り消すことができます。(Oracle Flashback Transactionでは、依存するすべてのトランザクション、つまりエラーが発生するトランザクションと同じ行が関係する後続のトランザクションも取り消す必要があることに注意してください。)「Oracle Flashback Tableを使用した表のリカバリ」で説明されているOracle Flashback Tableも使用できます。

注意:
Oracle Flashback機能を使用するには、自動UNDO管理を使用している必要があります。「自動UNDO管理の概念」を参照してください。

関連項目:
Oracle Flashback機能の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

Oracle Flashback Tableを使用した表のリカバリ

Oracle Flashback Tableを使用すると、表を以前の時点の状態にリストアできます。この機能では、ユーザーまたはアプリケーションにより、誤って変更または削除された表のリカバリを行うための、迅速なオンラインによる解決方法が提供されています。多くの場合、Oracle Flashback Tableを使用することで、管理者がより複雑なポイント・イン・タイム・リカバリ操作を実行する必要はなくなります。

Oracle Flashback Tableでは次のことができます。

- 指定された表のすべてのデータが、タイムスタンプまたはSCNで表された以前の時点にリストアされます。

- リストア操作はオンラインで実行されます。

- アプリケーションがフラッシュバックされた表を使用して機能するために必要な索引、トリガー、制約など、表の属性すべてが自動的に維持されます。

- 分散環境におけるすべてのリモート状態が維持されます。たとえば、レプリケート表がフラッシュバックされる場合は、レプリケーションに必要な表の変更すべてが維持されます。

- 制約によって指定されているデータの整合性が維持されます。表は、表の制約すべてに違反していないことを条件にしてフラッシュバックされます。この制約には、FLASHBACK TABLE文の対象になっている表とFLASHBACK TABLE文の対象になっていない表との間に指定されている参照整合性制約も含まれます。

- フラッシュバック操作後も、元の表のデータは消失しません。後で、元の状態に戻すことができます。

注意:
Oracle Flashback Tableを使用するには、自動UNDO管理を使用している必要があります。「自動UNDO管理の概念」を参照してください。

関連項目:
FLASHBACK TABLE文の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

表の削除

不要になった表を削除するには、DROP TABLE文を使用します。削除する表は、自分のスキーマに含まれているか、またはDROP ANY TABLEシステム権限を持っている必要があります。

注意:
表を削除する前に、表を削除した結果についてよく理解しておいてください。

- 表を削除すると、その表定義はデータ・ディクショナリから削除されます。その結果、表のすべての行はアクセスできなくなります。

- 表に対応付けられている索引とトリガーは、すべて削除されます。

- 削除した表に依存しているビューとPL/SQLプログラム・ユニットはすべてそのまま残りますが、無効になります(使用できません)。データベースによる依存性管理の詳細は、「オブジェクト依存性の管理」を参照してください。

- 削除する表のシノニムはすべてそのまま残りますが、使用するとエラーが返されます。

- 削除した表に割り当てられていたエクステントは表領域の空き領域にすべて戻され、新しいエクステントまたは新しいオブジェクトを必要とするその他のオブジェクトによって再利用されます。クラスタ化表に対応する行はすべて、そのクラスタのブロックから削除されます。クラスタ化表の説明は、第22章「クラスタの管理」を参照してください。

次の文は、hr.int_admin_emp表を削除します。

DROP TABLE hr.int_admin_emp;

削除する表に、他の表の外部キーが参照している主キーまたは一意キーが含まれていて、その子表のFOREIGN KEY制約を削除する場合は、次のようにDROP TABLE文にCASCADE句を指定します。

DROP TABLE hr.admin_emp CASCADE CONSTRAINTS;

表を削除した場合、通常、その表に関連付けられている領域はデータベースによってすぐには解放されません。そのかわりに、データベースは表の名前を変更してリサイクル・ビンに入れるため、後に表が誤って削除されたことがわかった場合、FLASHBACK TABLE文を使用してリカバリできます。DROP TABLE文の発行時に、表に関連付けられている空間をすぐに解放する場合は、次の文に示すようにPURGE句を含めます。

DROP TABLE hr.admin_emp PURGE;

表を削除するかわりに、切捨てを使用する場合もあります。TRUNCATE文は、表からすべての行を削除するための高速で効率的な方法ですが、切り捨てる表に関連付けられた構造(列定義、制限、トリガーなど)または権限付与には影響しません。TRUNCATE文の説明は、「表とクラスタの切捨て」を参照してください。

フラッシュバック・ドロップの使用とリサイクル・ビンの管理

表を削除した場合、その表に関連付けられている領域はデータベースによってすぐには削除されません。データベースによってこの表の名前が変更され、すべての関連オブジェクトとともにリサイクル・ビンへ入れられますが、後に表が誤って削除されたことがわかった場合、リサイクル・ビンからリカバリすることができます。この機能はフラッシュバック・ドロップと呼ばれ、表のリストアにはFLASHBACK TABLE文が使用されます。この目的のためのFLASHBACK TABLE文の使用方法を説明する前に、リサイクル・ビンの機能と、その内容の管理方法を理解することが重要です。

この項の内容は次のとおりです。

- リサイクル・ビンの概要

- リサイクル・ビン内のオブジェクトの表示と問合せ

- リサイクル・ビン内のオブジェクトのパージ

- リサイクル・ビンからの表のリストア

リサイクル・ビンの概要

リサイクル・ビンとは、実際には、削除されたオブジェクトに関する情報を含んでいるデータ・ディクショナリ表です。削除された表および関連するオブジェクト(索引、制約、ネストした表など)は、削除されずにそのまま領域を使用します。この領域は、リサイクル・ビンから明確にパージされるまで、または、あまり可能性はありませんが、表領域の制約のためにデータベースによるパージが必要となるまでは、ユーザー領域の割当てにとって不利です。

ユーザーにSYSDBA権限がない場合、リサイクル・ビンの中でユーザーが所有するオブジェクトは、アクセス権があるオブジェクトのみであるため、各ユーザーには各自のリサイクル・ビンがあるとみなすことができます。リサイクル・ビンにある各自のオブジェクトは、次の文を使用して表示できます。

SELECT * FROM RECYCLEBIN;

表領域をその内容も含めて削除すると、表領域内のオブジェクトはリサイクル・ビンに配置されず、その表領域に配置されていたオブジェクトに対するリサイクル・ビン内のエントリはすべてパージされます。内容を含まない表領域を削除した場合、つまり空の表領域を削除した場合も、表領域内のオブジェクトに対するリサイクル・ビン内のエントリがすべてパージされます。同様に、それぞれの削除操作は次のように処理されます。

- ユーザーを削除すると、そのユーザーが所有しているオブジェクトはリサイクル・ビンには配置されず、リサイクル・ビン内のオブジェクトがすべてパージされます。

- クラスタを削除すると、そのメンバー表はリサイクル・ビンには配置されず、リサイクル・ビン内の古いメンバー表がすべてパージされます。

- タイプを削除すると、サブタイプなどの依存オブジェクトはリサイクル・ビンには配置されず、リサイクル・ビン内の古い依存オブジェクトがすべてパージされます。

リサイクル・ビン内のオブジェクト名の変更

削除された表をリサイクル・ビンに移動すると、その表とその表に関連するオブジェクトには、システムで生成された名前が割り当てられます。名前の変更は、複数の表が同じ名前の場合に発生する可能性がある、名前の競合を回避するために必要です。名前の変更は、次の状況で発生します。

- ユーザーが表を削除し、同じ名前で表を作成し、その後、作成した表を再度削除した場合。

- 2人のユーザーが同じ名前の表を持ち、両方のユーザーが各自の表を削除した場合。

名前変更の表記規則は、次のとおりです。

BIN$unique_id$version

説明:

- unique_idは、このオブジェクトに対する、26文字からなるグローバルに一意の識別子です。これによって、リサイクル・ビンの名前がすべてのデータベース全体で一意に識別されます。

- versionは、データベースによって割り当てられるバージョン番号です。

リサイクル・ビンの有効化と無効化

リサイクル・ビンが有効化されていると、削除した表とその依存オブジェクトはリサイクル・ビンに配置されます。リサイクル・ビンが無効になっている場合、削除された表およびその依存オブジェクトはリサイクル・ビンに配置されず、単純に削除されるため、リカバリするには他の手段(バックアップからのリカバリなど)を使用する必要があります。

リサイクルビンを無効にしても、リサイクルビンにすでにあるオブジェクトはパージされず、影響も受けません。デフォルトで、リサイクル・ビンは有効になっています。

リサイクル・ビンは、recyclebin初期化パラメータを変更して有効化および無効化できます。このパラメータは動的ではないため、ALTER SYSTEM文で変更したときにはデータベースの再起動が必要です。

リサイクル・ビンの無効化:

1. 次のいずれかの文を発行します。

ALTER SESSION SET recyclebin = OFF;

ALTER SYSTEM SET recyclebin = OFF SCOPE = SPFILE;

2. ALTER SYSTEMを使用した場合は、データベースを再起動します。

リサイクル・ビンの有効化:

1. 次のいずれかの文を発行します。

ALTER SESSION SET recyclebin = ON;

ALTER SYSTEM SET recyclebin = ON SCOPE = SPFILE;

2. ALTER SYSTEMを使用した場合は、データベースを再起動します。

関連項目:

- 初期化パラメータの詳細は、「初期化パラメータと初期化パラメータ・ファイルの概要」を参照してください。

- 動的な初期化パラメータおよび静的な初期化パラメータについては、「初期化パラメータ値の変更」を参照してください。

リサイクル・ビン内のオブジェクトの表示と問合せ

Oracle Databaseでは、リサイクル・ビンのオブジェクトに関する情報を取得する2種類の方法を提供しています。

ビュー

説明

USER_RECYCLEBIN

ユーザーはこのビューを使用して、リサイクル・ビンにある削除された自分のオブジェクトを表示できます。使用しやすいように、シノニムRECYCLEBINがあります。

DBA_RECYCLEBIN

管理者はこのビューを使用して、リサイクル・ビンにある削除されたすべてのオブジェクトを表示できます。

これらのビューの使用目的の1つは、次の例のように、削除したオブジェクトに対してデータベースが割り当てた名前を識別することにあります。

SELECT object_name, original_name FROM dba_recyclebin
WHERE owner = 'HR';

OBJECT_NAME                    ORIGINAL_NAME
------------------------------ --------------------------------
BIN$yrMKlZaLMhfgNAgAIMenRA==$0 EMPLOYEES

リサイクル・ビンの内容は、SQL*PlusのSHOW RECYCLEBINコマンドを使用して表示することもできます。

SQL> show recyclebin

ORIGINAL NAME    RECYCLEBIN NAME                OBJECT TYPE  DROP TIME
---------------- ------------------------------ ------------ -------------------
EMPLOYEES        BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TABLE        2003-10-27:14:00:19

リサイクル・ビンにあるオブジェクトは、他のオブジェクトと同じ要領で問い合せることができます。ただし、オブジェクトの名前は、リサイクル・ビンの中で識別されているとおりに指定する必要があります。次に例を示します。

SELECT * FROM "BIN$yrMKlZaVMhfgNAgAIMenRA==$0";

リサイクル・ビン内のオブジェクトのパージ

リサイクル・ビンから項目をリストアすることはないと判断した場合は、PURGE文を使用して、項目および関連するオブジェクトをリサイクル・ビンから削除し、記憶域を解放できます。実行するには、項目を削除する場合と同じ権限が必要です。

PURGE文を使用して表をパージする場合、リサイクル・ビンでの表の名前、または表の元の名前を使用できます。「リサイクル・ビン内のオブジェクトの表示と問合せ」で説明されているように、リサイクル・ビンでの名前はDBA_またはUSER_RECYCLEBINビューから取得できます。次の仮定的な例では、リサイクル・ビンに配置されたときにBIN$jsleilx392mk2=293$0に名前が変更された表hr.int_admin_empをパージします。

PURGE TABLE "BIN$jsleilx392mk2=293$0";

次の文を使用しても同様の結果となります。

PURGE TABLE int_admin_emp;

PURGE文を使用すると、指定の表領域からリサイクル・ビンのすべてのオブジェクトをパージ、または指定のユーザーに属する表領域オブジェクトのみをパージできます。次に例を示します。

PURGE TABLESPACE example;
PURGE TABLESPACE example USER oe;

次の文を使用することで、ユーザーは独自のオブジェクトのリサイクル・ビンをパージして、オブジェクトの領域を解放できます。

PURGE RECYCLEBIN;

SYSDBA権限がある場合は、前述の文のRECYCLEBINのかわりに、DBA_RECYCLEBINを指定することによって、リサイクル・ビン全体をパージできます。

また、PURGE文を使用して、リサイクル・ビンから索引をパージ、またはリサイクル・ビンから指定の表領域にあるすべてのオブジェクトをパージすることもできます。

関連項目:
PURGE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

リサイクル・ビンからの表のリストア

FLASHBACK TABLE ... TO BEFORE DROP文を使用すると、リサイクル・ビンからオブジェクトをリカバリできます。ごみ箱内の表の名前または元の表の名前のいずれかを指定できます。オプションのRENAME TO句を使用すると、表をリカバリするときに名前を変更できます。「リサイクル・ビン内のオブジェクトの表示と問合せ」で説明されているように、リサイクル・ビンでの名前はDBA_またはUSER_RECYCLEBINビューから取得できます。FLASHBACK TABLE ... TO BEFORE DROP文を使用するためには、表の削除に必要な権限と同じ権限が必要です。

次の例は、int_admin_emp表をリストアし、その表に新しい名前を割り当てます。

FLASHBACK TABLE int_admin_emp TO BEFORE DROP
RENAME TO int2_admin_emp;

表を複数回削除した場合、システムが生成するリサイクル・ビンでの名前が非常に有用です。たとえば、リサイクル・ビンにint2_admin_emp表の3つのバージョンがあり、2番目のバージョンをリカバリするとします。これを実行するには、2つのFLASHBACK TABLE文を実行するか、または次の例に示すように、リサイクル・ビンを問い合せ、適切なシステム生成名にフラッシュバックできます。問合せに作成時間を含めると、正しい表をリストアしていることを確認できます。

SELECT object_name, original_name, createtime FROM recyclebin;

OBJECT_NAME                    ORIGINAL_NAME   CREATETIME
------------------------------ --------------- -------------------
BIN$yrMKlZaLMhfgNAgAIMenRA==$0 INT2_ADMIN_EMP  2006-02-05:21:05:52
BIN$yrMKlZaVMhfgNAgAIMenRA==$0 INT2_ADMIN_EMP  2006-02-05:21:25:13
BIN$yrMKlZaQMhfgNAgAIMenRA==$0 INT2_ADMIN_EMP  2006-02-05:22:05:53

FLASHBACK TABLE "BIN$yrMKlZaVMhfgNAgAIMenRA==$0" TO BEFORE DROP;

依存オブジェクトのリストア

リサイクル・ビンから表をリストアすると、索引などの依存オブジェクトは元の名前が復元されず、システム生成のリサイクル・ビンの名前のままになります。元の名前をリストアするには、依存オブジェクトの名前を手動で変更する必要があります。依存オブジェクトの元の名前を手動でリストアする場合は、表をリストアする前に、各依存オブジェクトのリサイクル・ビン内のシステム生成の名前を書き留めておいてください。

次の例では、HRサンプル・スキーマから、削除した表JOB_HISTORYの索引の一部の元の名前をリストアします。この例では、HRユーザーとしてログインしていることを想定しています。

1. JOB_HISTORYの削除後、リサイクル・ビンからリストアする前に、次の問合せを実行します。

SELECT OBJECT_NAME, ORIGINAL_NAME, TYPE FROM RECYCLEBIN;

OBJECT_NAME                    ORIGINAL_NAME             TYPE
------------------------------ ------------------------- --------
BIN$DBo9UChtZSbgQFeMiAdCcQ==$0 JHIST_JOB_IX              INDEX
BIN$DBo9UChuZSbgQFeMiAdCcQ==$0 JHIST_EMPLOYEE_IX         INDEX
BIN$DBo9UChvZSbgQFeMiAdCcQ==$0 JHIST_DEPARTMENT_IX       INDEX
BIN$DBo9UChwZSbgQFeMiAdCcQ==$0 JHIST_EMP_ID_ST_DATE_PK   INDEX
BIN$DBo9UChxZSbgQFeMiAdCcQ==$0 JOB_HISTORY               TABLE

2. 次のコマンドを実行して表をリストアします。

FLASHBACK TABLE JOB_HISTORY TO BEFORE DROP;

3. 次の問合せを実行して、すべてのJOB_HISTORY索引がシステム生成のリサイクル・ビン名を保持していることを確認します。

SELECT INDEX_NAME FROM USER_INDEXES WHERE TABLE_NAME = 'JOB_HISTORY';

INDEX_NAME
------------------------------
BIN$DBo9UChwZSbgQFeMiAdCcQ==$0
BIN$DBo9UChtZSbgQFeMiAdCcQ==$0
BIN$DBo9UChuZSbgQFeMiAdCcQ==$0
BIN$DBo9UChvZSbgQFeMiAdCcQ==$0

4. 次のようにして、最初の2つの索引の元の名前をリストアします。

ALTER INDEX "BIN$DBo9UChtZSbgQFeMiAdCcQ==$0" RENAME TO JHIST_JOB_IX;
ALTER INDEX "BIN$DBo9UChuZSbgQFeMiAdCcQ==$0" RENAME TO JHIST_EMPLOYEE_IX;

システム生成の名前は、二重引用符で囲む必要があります。

索引構成表の管理

ここでは、索引構成表の管理について説明します。この項の内容は、次のとおりです。

- 索引構成表の概要

- 索引構成表の作成

- 索引構成表のメンテナンス

- 索引構成表に対する2次索引の作成

- 索引構成表の分析

- 索引構成表でのORDER BY句の使用

- 索引構成表の標準的な表への変換

索引構成表の概要

索引構成表は、プライマリBツリーの異形である記憶域編成を持っています。順序付けされていないコレクション(ヒープ)としてデータを格納する通常の(ヒープ構成)表とは異なり、索引構成表のデータはBツリーの索引構造に主キー・ソート方式で格納されます。索引構造の各リーフ・ブロックには、キー列と非キー列の両方が格納されます。

索引構成表の構造には、次の利点があります。

- 索引のみのスキャンで十分なため、主キーに対して高速にランダム・アクセスできます。また、索引構造以外に表記憶域がないため、新しい行の追加、行の更新、行の削除などにより表データを変更すると、索引構造の更新のみが実行されます。

- 行が主キー順にクラスタ化されているため、主キーに対して高速にレンジ・アクセスできます。

- 主キーの複製が回避されるため、記憶域の所要量を低く抑えられます。ヒープ構成表の場合、主キーは索引と基礎となる表の両方には格納されません。

索引構成表は、すべての表機能を備えています。制約、トリガー、LOB列とオブジェクト列、パーティション化、パラレル操作、オンライン再編成、およびレプリケーションなどの機能をサポートします。さらに、次の機能も提供します。

- キー圧縮

- オーバーフロー記憶域と固有の列配置

- ビットマップ索引を含めた2次索引。

高速な主キー・アクセスと高可用性を必要とするOLTPアプリケーションには、索引構成表が理想的です。たとえば、電子注文処理に使用される注文表の問合せおよびDMLは大部分が主キー・アクセスに基づいており、同時DMLの大量ボリュームが行の変更や索引での非効率な領域の使用の原因となり、再編成が頻繁に必要となります。索引構成表は、2次索引を無効化せずにオンラインで再編成できるため、ウィンドウの使用を制限される時間が大幅に短縮または排除されます。

索引構成表は、アプリケーション固有の索引構造をモデル化するのに適しています。たとえば、テキスト、イメージおよびオーディオ・データを含むコンテンツ・ベースの情報検索アプリケーションには、索引構成表を使用して有効にモデル化できる逆索引が必要です。インターネット検索エンジンの基本の構成要素は、索引構成表を使用してモデル化できる逆向きの索引です。

これらは、索引構成表のアプリケーションのほんの数例です。

関連項目:

- 索引構成表の詳細は、『Oracle Database概要』を参照してください。

- 索引構成表のパーティション化の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

索引構成表の作成

索引構成表を作成するには、CREATE TABLE文を使用します。ただし、追加情報を指定する必要があります。

- ORGANIZATION INDEX修飾子。これによって、索引構成表であることを示します。

- 主キー。主キーは、単一列主キーの場合は列制約句、複数列主キーの場合は表制約句によって指定します。

必要に応じて、次の情報を指定できます。

- OVERFLOW句。この句は、非キー列の一部を別のオーバーフロー・データ・セグメントに格納できるようにすることにより、Bツリー索引の稠密なクラスタを保ちます。

- PCTTHRESHOLD値。これは、オーバーフロー・セグメントが使用されている際、索引ブロックに保存される行の部分の最大サイズを、ブロック・サイズのパーセンテージとして定義します。この行サイズが最大値を超える行の列は、オーバーフロー・セグメントに格納されます。行は、列境界で先頭部分と後尾部分の2つの部分に分割されます。先頭部分は指定されたしきい値に収まり、索引リーフ・ブロックのキーとともに格納されます。後尾部分は1つ以上の行の部分としてオーバーフロー領域に格納されます。このようにして、索引エントリにはキー値、指定したしきい値に収まる非キー列値、および行の残りの部分へのポインタが含まれます。

- INCLUDING句。この句は、主キーとともに索引ブロックに格納される非キー列を指定するために使用できます。

例: 索引構成表の作成

次の文によって、索引構成表が作成されます。

CREATE TABLE admin_docindex(
token char(20),
doc_id NUMBER,
token_frequency NUMBER,
token_offsets VARCHAR2(2000),
CONSTRAINT pk_admin_docindex PRIMARY KEY (token, doc_id))
ORGANIZATION INDEX
TABLESPACE admin_tbs
PCTTHRESHOLD 20
OVERFLOW TABLESPACE admin_tbs2;

この例では、token列とdoc_id列で構成される主キーを使用して、admin_docindexという索引構成表を作成します。OVERFLOW句とPCTTHRESHOLD句では、行の長さが索引ブロック・サイズの20%を超えた場合に、そのしきい値を超えた列とその後のすべての列がオーバーフロー・セグメントに移動されるように指定しています。オーバーフロー・セグメントは、admin_tbs2表領域に格納されます。

関連項目:
索引構成表を作成する構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

索引構成表に対する制限

索引構成表の作成には、次の制限があります。

- 列の最大数は1000です。

- キー列と非キー列を含めて、行の索引部分の最大列数は255です。255個を超える列が必要な場合は、オーバーフロー・セグメントを使用する必要があります。

- 主キーに含めることができる最大列数は32です。

- PCTTHRESHOLDは1から50の範囲内である必要があります。デフォルトは50です。

- すべてのキー列は、指定したしきい値内に収まる必要があります。

- 行の最大サイズが索引ブロック・サイズの50%を超える場合に、オーバーフロー・セグメントを指定しないと、CREATE TABLE文が失敗します。

- 索引構成表に仮想列は設定できません。

オブジェクト型を含む索引構成表の作成

索引構成表は、オブジェクト型を格納できます。次の例は、オブジェクト型admin_typを作成し、オブジェクト型admin_typの列を含む索引構成表を作成しています。

CREATE OR REPLACE TYPE admin_typ AS OBJECT
(col1 NUMBER, col2 VARCHAR2(6));
CREATE TABLE admin_iot (c1 NUMBER primary key, c2 admin_typ)
ORGANIZATION INDEX;

オブジェクト型の索引構成表を作成することもできます。次に例を示します。

CREATE TABLE admin_iot2 OF admin_typ (col1 PRIMARY KEY)
ORGANIZATION INDEX;

次に、索引構成表がネストした表を効率的に格納する例を示します。ネストした表の列ごとに、ネストした表のすべての行を保持する記憶表が内部的に作成されます。

CREATE TYPE project_t AS OBJECT(pno NUMBER, pname VARCHAR2(80));
/
CREATE TYPE project_set AS TABLE OF project_t;
/
CREATE TABLE proj_tab (eno NUMBER, projects PROJECT_SET)
NESTED TABLE projects STORE AS emp_project_tab
((PRIMARY KEY(nested_table_id, pno))
ORGANIZATION INDEX)
RETURN AS LOCATOR;

ネストした表のシングル・インスタンスに属する行は、nested_table_id列で識別されます。ネストした表の列を格納するために通常の表が使用される場合、ネストした表の行は、一般的にクラスタ化が解除されます。ただし、索引構成表を使用する場合、ネストした表はnested_table_id列に基づいてクラスタ化できます。

関連項目:

- 索引構成表の作成に使用する構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- パーティション化された索引構成表の作成方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- オブジェクト型については、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。

しきい値の選択と監視

キー列とともに最初のいくつかの非キー列が頻繁にアクセスされる場合は、その非キー列を取り込めるしきい値を選択してください。

しきい値を選択した後、指定した値が適切な値であることを確認するために、表を監視できます。ANALYZE TABLE ... LIST CHAINED ROWS文を使用して、しきい値を超える行の数と、どの行がしきい値を超えているかを判断できます。

関連項目:

- 連鎖行の詳細は、「表とクラスタの連鎖行のリスト」を参照してください。

- ANALYZE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

INCLUDING句の使用

PCTTHRESHOLDの指定に加え、INCLUDING句を使用して、キー列とともに保存する非キー列を制御できます。データベースでは、索引リーフ・ブロックのINCLUDING句に指定された列とその列までのすべての非キー列が、指定したしきい値を超えないかぎり格納されます。INCLUDING句で指定された列を超えた非キー列は、すべてオーバーフロー領域に格納されます。INCLUDINGとPCTTHRESHOLD句が競合する場合、PCTTHRESHOLDが優先されます。

注意:
Oracle Databaseでは、主キー・ベースのアクセス効率を高めるために、索引構成表のすべての主キー列が、表の先頭に(キー順に)移動されます。次に例を示します。

CREATE TABLE admin_iot4(a INT, b INT, c INT, d INT,
primary key(c,b))
ORGANIZATION INDEX;

格納後の列順は、a b c dではなく、c b a dとなります。格納された列順に基づき、最後の主キー列はbになります。INCLUDING列には、最後の主キー列(この例ではb)と非キー列(つまり、格納後の列順でbの後の任意の列)のどちらでも指定できます。

次のCREATE TABLE文は、「例: 索引構成表の作成」で示した文と類似していますが、token_offsets列の値が常にオーバーフロー領域に格納される索引構成表を作成するように変更されています。

CREATE TABLE admin_docindex2(
token CHAR(20),
doc_id NUMBER,
token_frequency NUMBER,
token_offsets VARCHAR2(2000),
CONSTRAINT pk_admin_docindex2 PRIMARY KEY (token, doc_id))
ORGANIZATION INDEX
TABLESPACE admin_tbs
PCTTHRESHOLD 20
INCLUDING token_frequency
OVERFLOW TABLESPACE admin_tbs2;

この例では、索引リーフ・ブロック内のキー列値とともに、token_offsetsまでの非キー列のみ(この場合は1つの列のみ)が格納されます。

索引構成表作成のパラレル化

CREATE TABLE...AS SELECT文を使用すると、索引構成表を作成して、既存の表からその索引構成表にデータをロードできます。PARALLEL句を指定することによって、ロードをパラレルで実行できます。

次の文は、従来型の表hr.jobsから行を選択し、索引構成表をパラレルに作成します。

CREATE TABLE admin_iot3(i PRIMARY KEY, j, k, l)
ORGANIZATION INDEX
PARALLEL
AS SELECT * FROM hr.jobs;

この文によって、SQL*Loaderを使用するパラレル・バルク・ロードの代替手段が提供されます。

キー圧縮の使用

キー圧縮を使用して索引構成表を作成すると、キー列の接頭辞が同じ値で繰り返し格納されるのを避けることができます。

キー圧縮によって、索引キーは接頭辞および接尾辞エントリに分割されます。圧縮するために、接頭辞エントリは索引ブロック内のすべての接尾辞エントリ間で共有されます。このような共有によって、領域が大幅に節約され、各索引ブロックに格納できるキー数が増え、パフォーマンスが向上します。

キー圧縮を使用可能にするには、次の操作を行う際にCOMPRESS句を使用します。

- 索引構成表の作成

- 索引構成表の移動

また、接頭辞の長さをキー列の数で指定できます。これにより、キー列が接頭辞および接尾辞エントリにどのように分割されるかが決まります。

CREATE TABLE admin_iot5(i INT, j INT, k INT, l INT, PRIMARY KEY (i, j, k))
ORGANIZATION INDEX COMPRESS;

この文は、次の文と等価です。

CREATE TABLE admin_iot6(i INT, j INT, k INT, l INT, PRIMARY KEY(i, j, k))
ORGANIZATION INDEX COMPRESS 2;

値リスト(1,2,3)、(1,2,4)、(1,2,7)、(1,3,5)、(1,3,4)、(1,4,4)では、(1,2)、(1,3)の反復的な発生が圧縮されます。

また、次のように、圧縮に使用されるデフォルトの接頭辞の長さを変更することもできます。

CREATE TABLE admin_iot7(i INT, j INT, k INT, l INT, PRIMARY KEY (i, j, k))
ORGANIZATION INDEX COMPRESS 1;

値リスト(1,2,3)、(1,2,4)、(1,2,7)、(1,3,5)、(1,3,4)、(1,4,4)では、1の反復的な発生が圧縮されます。

圧縮は、次のように使用禁止にすることができます。

ALTER TABLE admin_iot5 MOVE NOCOMPRESS;

キー圧縮のアプリケーションは、株価など、単一の項目に属して一連のタイムスタンプを表す行を使用する時系列のアプリケーションで使用されます。索引構成表には、主キーに従って行をクラスタ化する機能があるため、このようなアプリケーションには効果的です。索引構成表を主キー(株式銘柄、タイムスタンプ)で定義することによって、時系列データを効率的に格納および操作できます。キー圧縮を採用した索引構成表を使用することによって、項目識別子(株式銘柄など)の反復的な発生を圧縮して、記憶域を大幅に節約できます。

関連項目:
キー圧縮の詳細は、『Oracle Database概要』を参照してください。

索引構成表のメンテナンス

索引構成表と通常の表の相違点は、物理的な構成のみです。論理的には、通常の表と同じように操作されます。INSERT、SELECT、DELETEおよびUPDATEの各文では、通常の表を指定する場合と同じように、索引構成表を指定できます。

索引構成表の変更

通常の表に使用可能な変更オプションはすべて索引構成表にも使用できます。使用可能なオプションには、ADD、MODIFY、DROP COLUMNSおよびCONSTRAINTSがあります。ただし、索引構成表の主キー制約は、削除、遅延または使用禁止にできません。

ALTER TABLE文を使用すると、主キー索引セグメントとオーバーフロー・データ・セグメントの物理属性と記憶域属性を変更できます。OVERFLOWキーワードより前に指定したすべての属性は、主キー索引セグメントに適用できます。OVERFLOWキーワードより後に指定したすべての属性は、オーバーフロー・データ・セグメントに適用できます。たとえば、次のようにして、主キー索引セグメントのINITRANSを4に、オーバーフロー・データ・セグメントのINITRANSを6に設定できます。

ALTER TABLE admin_docindex INITRANS 4 OVERFLOW INITRANS 6;

また、PCTTHRESHOLDおよびINCLUDING列の値も変更できます。後続の操作では、新しい設定を使用して、先頭部分とオーバーフローの後尾の部分に行が分割されます。たとえば、admin_docindex表のPCTHRESHOLDおよびINCLUDING列の値を次のように変更できます。

ALTER TABLE admin_docindex PCTTHRESHOLD 15 INCLUDING doc_id;

INCLUDING列をdoc_idに設定すると、その後のすべての列、つまりtoken_frequencyおよびtoken_offsetsはオーバーフロー・データ・セグメントに格納されます。

オーバーフロー・データ・セグメントなしで作成された索引構成表の場合は、ADD OVERFLOW句を使用してオーバーフロー・データ・セグメントを追加できます。たとえば、次のように表admin_iot3にオーバーフロー・セグメントを追加できます。

ALTER TABLE admin_iot3 ADD OVERFLOW TABLESPACE admin_tbs2;

索引構成表の移動(再作成)

索引構成表は主としてBツリー索引に格納されるため、増分更新の結果として断片化が生じることがあります。ただし、このような断片化は、ALTER TABLE...MOVE文を使用して索引を再作成することで低減できます。

次の文は、索引構成表admin_docindexを再作成します。

ALTER TABLE admin_docindex MOVE;

ONLINEキーワードを使用して、索引構成表をオンラインで再作成できます。OVERFLOWキーワードを指定すると、オーバーフロー・データ・セグメントが存在する場合はそれが再作成されます。たとえば、admin_docindex表を再作成し、オーバーフロー・データ・セグメントを再作成しない場合は、次のようにオンラインで移動します。

ALTER TABLE admin_docindex MOVE ONLINE;

admin_docindex表とオーバーフロー・データ・セグメントを再作成するには、次の文のように移動操作を実行します。この文は、表とオーバーフロー・データ・セグメントを新しい表領域に移動する方法も示しています。

ALTER TABLE admin_docindex MOVE TABLESPACE admin_tbs2
OVERFLOW TABLESPACE admin_tbs3;

次の最後の文で、LOB列(CLOB)を持つ索引構成表が作成されます。その後、この表はLOB索引とともに移動し、データ・セグメントが再作成され新しい表領域に移動します。

CREATE TABLE admin_iot_lob
(c1 number (6) primary key,
admin_lob CLOB)
ORGANIZATION INDEX
LOB (admin_lob) STORE AS (TABLESPACE admin_tbs2);
.
.
.
ALTER TABLE admin_iot_lob MOVE LOB (admin_lob) STORE AS (TABLESPACE admin_tbs3);

関連項目:
索引構成表のLOBの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

索引構成表に対する2次索引の作成

索引構成表に2次索引を作成することで、複数のアクセス・パスを提供できます。索引構成表の2次索引は、2つの点で通常の表の索引とは異なります。

- 索引構成表の2次索引には、物理的なROWIDではなく、論理的なROWIDが格納されます。論理的なROWIDの格納が必要な理由は、Bツリー索引の行にある本来の可動性のために、その行に永続的な物理アドレスがないためです。列の物理的な位置が変化しても、その論理的なROWIDは有効です。この効果の1つは、ALTER TABLE ... MOVEなどの表のメンテナンス操作によって2次索引が使用禁止状態にならないことです。

- 論理ROWIDにも、列が見つかる可能性があるデータベースのブロック・アドレスを識別する物理的な不確定要素が含まれています。物理的な不確定要素が正しい場合、2次キーが見つかると、2次索引スキャンによって単一の追加I/Oが生じます。パフォーマンスは、通常の表での2次索引スキャンの場合と同様です。

一意の2次索引、一意でない2次索引、機能ベースの2次索引およびビットマップ索引が、索引構成表の2次索引としてサポートされます。

2次索引作成の構文

次の文は、索引構成表docindexに2次索引を作成します、doc_idとtokenはキー列です。

CREATE INDEX Doc_id_index on Docindex(Doc_id, Token);

この2次索引によって、問合せ(次の文にあるdoc_idの述語に関係する問合せ)が効率的に処理されます。

SELECT Token FROM Docindex WHERE Doc_id = 1;

論理ROWIDの物理的不確定要素のメンテナンス

論理ROWIDには、不確定要素が作成される際に行のブロック位置を識別する不確定要素を含めることができます。完全なキー検索を実行するかわりに、不確定要素を使用してブロックが直接検索されます。ただし、新しい行が挿入されると、不確定要素は失効となる可能性があります。索引は論理ROWIDの主キー構成要素を介してそのまま使用できますが、行へのアクセスは遅くなります。

不確定要素の失効を監視するには、DBMS_STATSパッケージを使用して索引統計を収集します。既存の不確定要素が有効かどうかがチェックされ、有効な不確定要素を保持している行の割合がデータ・ディクショナリに記録されます。この統計は、DBA_INDEXESビュー(および関連するビュー)のPCT_DIRECT_ACCESS列に格納されます。

新しい不確定要素を取得するために、2次索引を再作成できます。索引構成表に対する2次索引の再作成には、通常の表に対する索引の再作成とは異なり、実表の読込みが必要です。不確定要素を修正する迅速で手軽な方法は、ALTER INDEX ... UPDATE BLOCK REFERENCES文を使用する方法です。この文はオンラインで実行されますが、DMLは基礎となる索引構成表でそのまま実行できます。

2次索引を再作成した後、あるいは不確定要素のブロック参照を更新した後は、索引統計を再度収集してください。

ビットマップ索引

索引構成表とともにマッピング表が作成される場合は、索引構成表でのビットマップ索引がサポートされます。ビットマップ索引を作成するには、索引構成表の作成に使用するCREATE TABLE文、または後でマッピング表を追加するALTER TABLE文に、MAPPING TABLE句を指定します。

関連項目:
マッピング表の説明は、『Oracle Database概要』を参照してください。

索引構成表の分析

通常の表と同様に、索引構成表の分析にはDBMS_STATSパッケージ、またはANALYZE文を使用します。

索引構成表のオプティマイザ統計の収集

オプティマイザ統計を収集するには、DBMS_STATSパッケージを使用します。

たとえば、次の文はhrスキーマの索引構成表countriesについて統計を収集します。

EXECUTE DBMS_STATS.GATHER_TABLE_STATS ('HR','COUNTRIES');

DBMS_STATSパッケージでは、主キー索引セグメントとオーバーフロー・データ・セグメントの両方が分析され、表の論理統計と物理統計が算出されます。

- 論理統計は、USER_TABLES、ALL_TABLESまたはDBA_TABLESを使用して問合せできます。

- 主キー索引セグメントの物理統計を問い合せるには、USER_INDEXES、ALL_INDEXESまたはDBA_INDEXES(および主キー索引名)を使用します。たとえば、表admin_docindexの主キー索引セグメントの物理統計は、次のようにして取得できます。

SELECT LAST_ANALYZED, BLEVEL,LEAF_BLOCKS, DISTINCT_KEYS
FROM DBA_INDEXES WHERE INDEX_NAME= 'PK_ADMIN_DOCINDEX';

- オーバーフロー・データ・セグメントの物理統計を問い合せるには、USER_TABLES、ALL_TABLESまたはDBA_TABLESを使用します。IOT_TYPE = 'IOT_OVERFLOW'で検索すると、オーバーフロー・エントリを識別できます。たとえば、admin_docindex表に対応付けられたオーバーフロー・データ・セグメントの物理属性は、次のようにして取得できます。

SELECT LAST_ANALYZED, NUM_ROWS, BLOCKS, EMPTY_BLOCKS
FROM DBA_TABLES WHERE IOT_TYPE='IOT_OVERFLOW'
and IOT_NAME= 'ADMIN_DOCINDEX';

関連項目:

- オプティマイザ統計の収集の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- DBMS_STATSパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

索引構成表の構造の検証

索引構成表の構造を検証、または連鎖行をリストするには、ANALYZE文を使用します。これらの操作は、このマニュアルの該当する項で説明されています。

- 「表、索引、クラスタおよびマテリアライズド・ビューの妥当性チェック」

- 「表とクラスタの連鎖行のリスト」

注意:
索引構成表の連鎖行をリストする場合は、特別な注意が必要です。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

索引構成表でのORDER BY句の使用

ORDER BY句が主キー列またはその接頭辞のみを参照する場合、行は主キー列でソートされた状態で返されるため、オプティマイザはソートのオーバーヘッドを回避します。

データはすでに主キーでソートされているので、次の2つの問合せはソートのオーバーヘッドを回避します。

SELECT * FROM admin_docindex2 ORDER BY token, doc_id;
SELECT * FROM admin_docindex2 ORDER BY token;

ただし、主キー列の接尾辞または非主キー列にORDER BY句がある場合は、別のソートが必要になります(他の2次索引が定義されていない場合)。

SELECT * FROM admin_docindex2 ORDER BY doc_id;
SELECT * FROM admin_docindex2 ORDER BY token_frequency;

索引構成表の標準的な表への変換

索引構成表を標準的な(ヒープ構成)表に変換するには、Oracleのインポート/エクスポート・ユーティリティ、あるいはCREATE TABLE...AS SELECT文を使用できます。

索引構成表を標準的な表に変換する手順は、次のとおりです。

- 従来型パスを使用して、索引構成表のデータをエクスポートします。

- 同じ定義で、標準的な表の定義を作成します。

- IGNORE=y(オブジェクト存在エラーを無視する)を指定して、索引構成表のデータをインポートします。

注意:
索引構成表を標準的な表に変換する前に、Oracle8より古いバージョンのエクスポート・ユーティリティでは索引構成表をエクスポートできないことに注意してください。

関連項目:
従来のIMPおよびEXPユーティリティとデータ・ポンプ・インポート/エクスポート・ユーティリティの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

外部表の管理

この項の内容は次のとおりです。

- 外部表の概要

- 外部表の作成

- 外部表の変更

- 外部表の前処理

- 外部表の削除

- 外部表のシステム権限およびオブジェクト権限

外部表の概要

Oracle Databaseでは、外部表内のデータへの読取り専用アクセスが可能です。外部表はデータベース内に存在しない表として定義されており、アクセス・ドライバが提供されていればどのようなフォーマットにすることもできます。外部表を記述するメタデータを提供することで、外部表内のデータをあたかも標準的なデータベース表内に存在しているデータのように公開できます。外部データは、SQLを使用して直接およびパラレルに問合せできます。

外部表のデータは、選択、結合、ソートなどが行えます。外部表のビューやシノニムも作成できます。ただし、外部表に対してDML操作(UPDATE、INSERTまたはDELETE)は実行できず、索引も作成できません。

外部表は、プラットフォームに依存しないフォーマット(オラクル社で開発され、Oracle Data Pumpで使用可能)に、任意のSELECT文の結果をアンロードするためのフレームワークを提供します。外部表は、データ・ウェアハウスで一般的な、抽出、変換およびロード(ETL)の基本タスクを実行する際に役立つ手段を提供します。

外部表のメタデータは、CREATE TABLE...ORGANIZATION EXTERNAL文を使用して定義します。外部表の定義は、外部データを最初にデータベースにロードしなくても外部データに対して任意のSQL問合せを実行できるビューとみなすことができます。表内の外部データを読み込むために実際に使用されているメカニズムが、アクセス・ドライバです。外部表を使用してデータをアンロードすると、SELECT文のデータ型に基づいてメタデータが自動的に作成されます。

Oracle Databaseでは、外部表のための2種類のアクセス・ドライバを提供しています。デフォルトのアクセス・ドライバはORACLE_LOADERで、Oracleのローダー・テクノロジを使用して外部ファイルからデータを読み込むことができます。ORACLE_LOADERアクセス・ドライバは、SQL*Loaderユーティリティの制御ファイル構文のサブセットであるデータ・マッピング機能を提供します。第2のアクセス・ドライバORACLE_DATAPUMPは、データをアンロード(つまり、データベースからデータを読み取り、1つ以上の外部ファイルで表された外部表にそのデータを挿入)してから、データをOracle Databaseに再ロードします。

注意:
ANALYZE文による外部表の統計収集はサポートされていません。かわりにDBMS_STATSパッケージを使用してください。

関連項目:

- 外部表に対する制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- アクセス・ドライバの詳細は、『Oracle Databaseユーティリティ』を参照してください。

- データ・ウェアハウス環境でETLに外部表を使用する方法の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- DBMS_STATSパッケージの使用方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

外部表の制限事項

外部表に関する制限事項は、次のとおりです。

- ANALYZE文による外部表の統計収集はサポートされていません。かわりにDBMS_STATSパッケージを使用してください。

- 仮想列はサポートされていません。

関連項目:

- 外部表に対する制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- アクセス・ドライバの詳細は、『Oracle Databaseユーティリティ』を参照してください。

- データ・ウェアハウス環境でETLに外部表を使用する方法の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- DBMS_STATSパッケージの使用方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

外部表の作成

外部表は、CREATE TABLE文でORGANIZATION EXTERNAL句を使用して作成します。この文は、データ・ディクショナリにメタデータのみを作成します。

注意:
外部表に仮想列は設定できません。

次の例では、外部表を作成してから、データをデータベース表にアップロードしています。あるいは、CREATE TABLE文のAS subquery句を指定し、外部表フレームワークを介してデータをアンロードできます。外部表のデータ・ポンプ・アンロードは、ORACLE_DATAPUMPアクセス・ドライバのみを使用できます。

例: 外部表の作成とデータのロード

この例では、外部表のデータはempxt1.datおよびempxt2.datという2つのテキスト・ファイルに存在します。

ファイルempxt1.datには、次のサンプル・データが収められています。

360,Jane,Janus,ST_CLERK,121,17-MAY-2001,3000,0,50,jjanus
361,Mark,Jasper,SA_REP,145,17-MAY-2001,8000,.1,80,mjasper
362,Brenda,Starr,AD_ASST,200,17-MAY-2001,5500,0,10,bstarr
363,Alex,Alda,AC_MGR,145,17-MAY-2001,9000,.15,80,aalda

ファイルempxt2.datには、次のサンプル・データが収められています。

401,Jesse,Cromwell,HR_REP,203,17-MAY-2001,7000,0,40,jcromwel
402,Abby,Applegate,IT_PROG,103,17-MAY-2001,9000,.2,60,aapplega
403,Carol,Cousins,AD_VP,100,17-MAY-2001,27000,.3,90,ccousins
404,John,Richardson,AC_ACCOUNT,205,17-MAY-2001,5000,0,110,jrichard

次のSQL文は、スキーマhrに外部表admin_ext_employeesを作成し、外部表からhr.employees表にデータをロードします。

CONNECT  /  AS SYSDBA;
-- Set up directories and grant access to hr
CREATE OR REPLACE DIRECTORY admin_dat_dir
AS '/flatfiles/data';
CREATE OR REPLACE DIRECTORY admin_log_dir
AS '/flatfiles/log';
CREATE OR REPLACE DIRECTORY admin_bad_dir
AS '/flatfiles/bad';
GRANT READ ON DIRECTORY admin_dat_dir TO hr;
GRANT WRITE ON DIRECTORY admin_log_dir TO hr;
GRANT WRITE ON DIRECTORY admin_bad_dir TO hr;
-- hr connects. Provide the user password (hr) when prompted.
CONNECT hr
-- create the external table
CREATE TABLE admin_ext_employees
(employee_id       NUMBER(4),
first_name        VARCHAR2(20),
last_name         VARCHAR2(25),
job_id            VARCHAR2(10),
manager_id        NUMBER(4),
hire_date         DATE,
salary            NUMBER(8,2),
commission_pct    NUMBER(2,2),
department_id     NUMBER(4),
email             VARCHAR2(25)
)
ORGANIZATION EXTERNAL
(
TYPE ORACLE_LOADER
DEFAULT DIRECTORY admin_dat_dir
ACCESS PARAMETERS
(
records delimited by newline
badfile admin_bad_dir:'empxt%a_%p.bad'
logfile admin_log_dir:'empxt%a_%p.log'
fields terminated by ','
missing field values are null
( employee_id, first_name, last_name, job_id, manager_id,
hire_date char date_format date mask "dd-mon-yyyy",
salary, commission_pct, department_id, email
)
)
LOCATION ('empxt1.dat', 'empxt2.dat')
)
PARALLEL
REJECT LIMIT UNLIMITED;
-- enable parallel for loading (good if lots of data to load)
ALTER SESSION ENABLE PARALLEL DML;
-- load the data in hr employees table
INSERT INTO employees (employee_id, first_name, last_name, job_id, manager_id,
hire_date, salary, commission_pct, department_id, email)
SELECT * FROM admin_ext_employees;

この例について、次の各段落で説明します。

この例で、最初の数行の文は、データソースを保存するオペレーティング・システム・ディレクトリ用のディレクトリ・オブジェクトと、アクセス・パラメータで指定される不良レコードやログ・ファイル用のディレクトリ・オブジェクトを作成します。また、必要に応じてREADまたはWRITEのディレクトリ・オブジェクト権限を付与する必要があります。

注意:
ディレクトリ・オブジェクトまたはBFILEを作成する場合は、次の条件が満たされているかどうかを確認してください。

- オペレーティング・システム・ファイルが、シンボリック・リンクまたはハード・リンクでないこと。

- Oracle Databaseのディレクトリ・オブジェクトに指定されているオペレーティング・システムのディレクトリ・パスが、既存のオペレーティング・システムのディレクトリ・パスであること。

- ディレクトリ・オブジェクトに指定されているオペレーティング・システムのディレクトリ・パスの構成要素に、シンボリック・リンクが含まれていないこと。

TYPE指定は、外部表のアクセス・ドライバを示します。アクセス・ドライバは、データベースに対する外部データを解析するAPIです。TYPE指定を省略した場合は、ORACLE_LOADERがデフォルトのアクセス・ドライバになります。AS subquery句を指定して、1つのOracle Databaseからデータをアンロードし、同一または異なるOracle Databaseに再ロードする場合は、ORACLE_DATAPUMPアクセス・ドライバを指定する必要があります。

ACCESS PARAMETERS句で指定するアクセス・パラメータは、データベースには不透明です。これらのアクセス・パラメータはアクセス・ドライバによって定義されるもので、データベースが外部表にアクセスするときにアクセス・ドライバに提供されます。ORACLE_LOADERアクセス・パラメータの詳細は、『Oracle Databaseユーティリティ』を参照してください。

PARALLEL句は、データソースに対するパラレル問合せを可能にします。パラレル化の最小単位はデフォルトではデータソースですが、データソース内部でのパラレル・アクセスは可能なかぎり実装されます。たとえば、PARALLEL=3と指定すると、データソースに対して複数のパラレル実行サーバーを稼働しておくことができます。しかし、データソース内部でのパラレル・アクセスは、次の条件がすべて成り立つ場合にのみ、アクセス・ドライバによって提供されます。

- メディアが、データソース内部でのランダムな位置指定をサポートしている。

- レコード境界をランダムな位置から検索できる。

- データファイルが、複数のチャンクに分割することが適切なほど十分大きい。

注意:
PARALLEL句の指定は、大量のデータを扱う場合にのみ有効です。データが大量でない場合には、PARALLEL句を指定すると悪影響を及ぼす可能性が高いので、お薦めできません。

REJECT LIMIT句は、外部データの問合せ中に発生する可能性のあるエラーの数に上限を設けないことを指定します。パラレル・アクセスの場合、REJECT LIMITが各パラレル実行サーバーに個別に適用されます。たとえば、REJECT LIMITに10を指定すると、各パラレル問合せプロセスで10個まで拒否が許可されます。このため、並行度が2、REJECT LIMITが10の場合、拒否が10個から20個の間で文が失敗する場合があります。1つのパラレル・サーバーで10個の拒否をすべて処理する場合、制限に達するため文が終了します。ただし、1つのパラレル実行サーバーが9個の拒否を処理し、もう1つのパラレル実行サーバーが9個の拒否を処理する場合、18個の拒否で文が成功します。したがって、パラレル問合せに関して正確に規定されるREJECT LIMITの値は、0 (ゼロ)およびUNLIMITEDのみです。

この例では、INSERT INTO TABLE文によって外部データソースからOracle Database SQLエンジンへのデータフローが生成され、そこでデータが処理されます。外部表ソースからのデータがアクセス・ドライバで解析されて外部表インタフェースに提供されると、外部データがその外部表現からOracle Databaseの内部データ型に変換されます。

関連項目:
外部表を作成するためのCREATE TABLE文の構文の詳細、および句の使用の制限は、『Oracle Database SQL言語リファレンス』を参照してください。

外部表の変更

外部表の特性を変更するには、表20-5のいずれかのALTER TABLE句を使用します。これ以外の句は使用できません。

表20-5 外部表のALTER TABLE句

ALTER TABLE句

説明

例

REJECT LIMIT

拒否の上限を変更します。デフォルト値は0です。

ALTER TABLE admin_ext_employees
REJECT LIMIT 100;

PROJECT COLUMN

アクセス・ドライバが後続の問合せで行の妥当性をチェックする方法を決定します。

- PROJECT COLUMN REFERENCED: アクセス・ドライバは、問合せの選択リストのみを処理します。この設定では、同一の外部表とは異なる列リストを問い合せたときに、一貫した行のセットが提供されない可能性があります。

- PROJECT COLUMN ALL: アクセス・ドライバは、外部表に定義されているすべての列を処理します。この設定では、外部表を問い合せたときに、常に一貫した行のセットが提供されます。これがデフォルトです。

ALTER TABLE admin_ext_employees
PROJECT COLUMN REFERENCED;

ALTER TABLE admin_ext_employees
PROJECT COLUMN ALL;

DEFAULT DIRECTORY

デフォルトのディレクトリ指定を変更します。

ALTER TABLE admin_ext_employees
DEFAULT DIRECTORY admin_dat2_dir;

外部表の前処理

注意:
PREPROCESSOR句を使用するときに考慮する必要があるセキュリティ上の注意事項があります。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

ユーザー指定のプリプロセッサ・プログラムで外部表を前処理できます。前処理プログラムを使用すると、アクセス・ドライバでサポートされていない形式のファイルにあるデータを利用できます。たとえば、圧縮形式で格納されているデータにアクセスできます。ORACLE_LOADERアクセス・ドライバに対して解凍プログラムを指定すると、アクセス・ドライバでデータが処理される際にデータを解凍できます。

前処理機能を使用するには、ORACLE_LOADERアクセス・ドライバのアクセス・パラメータでPREPROCESSOR句を指定する必要があります。プリプロセッサはディレクトリ・オブジェクトである必要があり、外部表にアクセスするユーザーには、そのディレクトリ・オブジェクトに対するEXECUTE権限が必要です。次の例にはPREPROCESSOR句が含まれており、ディレクトリとプリプロセッサ・プログラムを指定しています。

CREATE TABLE sales_transactions_ext
(PROD_ID NUMBER,
CUST_ID NUMBER,
TIME_ID DATE,
CHANNEL_ID CHAR,
PROMO_ID NUMBER,
QUANTITY_SOLD NUMBER,
AMOUNT_SOLD NUMBER(10,2),
UNIT_COST NUMBER(10,2),
UNIT_PRICE NUMBER(10,2))
ORGANIZATION external
(TYPE oracle_loader
DEFAULT DIRECTORY data_file_dir
ACCESS PARAMETERS
(RECORDS DELIMITED BY NEWLINE
CHARACTERSET AL32UTF8
PREPROCESSOR exec_file_dir:'zcat'
BADFILE log_file_dir:'sh_sales.bad_xt'
LOGFILE log_file_dir:'sh_sales.log_xt'
FIELDS TERMINATED BY "|" LDRTRIM
( PROD_ID,
CUST_ID,
TIME_ID,
CHANNEL_ID,
PROMO_ID,
QUANTITY_SOLD,
AMOUNT_SOLD,
UNIT_COST,
UNIT_PRICE))
location ('sh_sales.dat.gz')
)REJECT LIMIT UNLIMITED;

PREPROCESSOR句は、Oracle Database Vaultを使用しているデータベースには使用できません。

関連項目:

- PREPROCESSOR句の詳細は、『Oracle Databaseユーティリティ』を参照してください。

- PREPROCESSOR句のセキュリティ上の注意事項の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

外部表の削除

外部表の場合、DROP TABLE文によって、データベース内の表メタデータのみが削除されます。データベースの外に常駐する実際のデータには影響を与えません。

外部表のシステム権限およびオブジェクト権限

外部表のシステム権限およびオブジェクト権限は、標準的な表のサブセットになります。外部表に適用できるシステム権限は、次のものにかぎられます。

- CREATE ANY TABLE

- ALTER ANY TABLE

- DROP ANY TABLE

- SELECT ANY TABLE

外部表に適用できるオブジェクト権限は、次のものにかぎられます。

- ALTER

- SELECT

ただし、ディレクトリには次のオブジェクト権限が対応付けられています。

- READ

- WRITE

外部表では、データソースのあるディレクトリ・オブジェクトに対してREAD権限が必要であり、同時に、不良ファイル、ログ・ファイルまたは廃棄ファイルのあるディレクトリ・オブジェクトに対してWRITE権限が必要です。

表のデータ・ディクショナリ・ビュー

次のビューを使用して、表に関する情報にアクセスできます。

ビュー

説明

DBA_TABLES
ALL_TABLES

USER_TABLES

DBAビューには、データベース内のすべてのリレーショナル表が表示されます。ALLビューには、ユーザーがアクセス可能なすべての表が表示されます。USERビューは、ユーザーが所有する表のみに制限されます。これらのビューの一部の列には、DBMS_STATSパッケージまたはANALYZE文によって生成される統計が含まれます。

DBA_TAB_COLUMNS
ALL_TAB_COLUMNS

USER_TAB_COLUMNS

これらのビューには、データベース内の表の列、ビューおよびクラスタが表示されます。これらのビューの一部の列には、DBMS_STATSパッケージまたはANALYZE文によって生成される統計が含まれます。

DBA_ALL_TABLES
ALL_ALL_TABLES

USER_ALL_TABLES

これらのビューには、データベース内のすべてのリレーショナル表およびオブジェクト表が表示されます。オブジェクト表については、このマニュアルでは詳しく説明していません。

DBA_TAB_COMMENTS
ALL_TAB_COMMENTS

USER_TAB_COMMENTS

これらのビューには、表およびビューのコメントが表示されます。コメントは、COMMENT文を使用して入力します。

DBA_COL_COMMENTS
ALL_COL_COMMENTS

USER_COL_COMMENTS

これらのビューには、表およびビューの列のコメントが表示されます。コメントは、COMMENT文を使用して入力します。

DBA_EXTERNAL_TABLES
ALL_EXTERNAL_TABLES

USER_EXTERNAL_TABLES

これらのビューには、データベースで定義されている外部表の特定の属性がリストされます。

DBA_EXTERNAL_LOCATIONS
ALL_EXTERNAL_LOCATIONS

USER_EXTERNAL_LOCATIONS

これらのビューには、外部表のデータソースがリストされます。

DBA_TAB_HISTOGRAMS
ALL_TAB_HISTOGRAMS

USER_TAB_HISTOGRAMS

これらのビューには、表およびビューに関するヒストグラムが表示されます。

DBA_TAB_STATISTICS
ALL_TAB_STATISTICS

USER_TAB_STATISTICS

これらのビューには、表のオプティマイザ統計が格納されます。

DBA_TAB_COL_STATISTICS
ALL_TAB_COL_STATISTICS

USER_TAB_COL_STATISTICS

これらのビューは、関連するTAB_COLUMNSビューから抽出された列の統計およびヒストグラム情報を提供します。

DBA_TAB_MODIFICATIONS
ALL_TAB_MODIFICATIONS

USER_TAB_MODIFICATIONS

これらのビューには、表統計が最後に収集された時点以降変更された表が表示されます。これらのビューは即時には移入されず、ある程度の時間(通常は3時間)が経過した後に移入されます。

DBA_ENCRYPTED_COLUMNS
USER_ENCRYPTED_COLUMNS

ALL_ENCRYPTED_COLUMNS

これらのビューには、暗号化された表の列がリストされ、各列に使用している暗号化アルゴリズムがリストされます。

DBA_UNUSED_COL_TABS
ALL_UNUSED_COL_TABS

USER_UNUSED_COL_TABS

これらのビューには、ALTER TABLE ... SET UNUSED文によって未使用のマークが付けられた列を持つ表がリストされます。

DBA_PARTIAL_DROP_TABS
ALL_PARTIAL_DROP_TABS

USER_PARTIAL_DROP_TABS

これらのビューには、DROP COLUMN操作が一部完了している表がリストされます。これらの操作は、ユーザーによる中断やシステム障害が原因で不完全になることがあります。

例: 列情報の表示

_COLUMNS接尾辞で終わるビューのいずれかを使用すると、名前、データ型、長さ、精度、位取り、デフォルト・データ値などの列情報を表示できます。たとえば、次の問合せは、emp表とdept表のデフォルトの列値をすべてリストします。

SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, DATA_LENGTH, LAST_ANALYZED
FROM DBA_TAB_COLUMNS
WHERE OWNER = 'HR'
ORDER BY TABLE_NAME;

問合せの出力は次のとおりです。

TABLE_NAME           COLUMN_NAME          DATA_TYPE   DATA_LENGTH LAST_ANALYZED
-------------------- -------------------- ---------- ------------ -------------
COUNTRIES            COUNTRY_ID           CHAR                  2 05-FEB-03
COUNTRIES            COUNTRY_NAME         VARCHAR2             40 05-FEB-03
COUNTRIES            REGION_ID            NUMBER               22 05-FEB-03
DEPARTMENTS          DEPARTMENT_ID        NUMBER               22 05-FEB-03
DEPARTMENTS          DEPARTMENT_NAME      VARCHAR2             30 05-FEB-03
DEPARTMENTS          MANAGER_ID           NUMBER               22 05-FEB-03
DEPARTMENTS          LOCATION_ID          NUMBER               22 05-FEB-03
EMPLOYEES            EMPLOYEE_ID          NUMBER               22 05-FEB-03
EMPLOYEES            FIRST_NAME           VARCHAR2             20 05-FEB-03
EMPLOYEES            LAST_NAME            VARCHAR2             25 05-FEB-03
EMPLOYEES            EMAIL                VARCHAR2             25 05-FEB-03
.
.
.
LOCATIONS            COUNTRY_ID           CHAR                  2 05-FEB-03
REGIONS              REGION_ID            NUMBER               22 05-FEB-03
REGIONS              REGION_NAME          VARCHAR2             25 05-FEB-03

51 rows selected.

関連項目:

- これらのビューの完全な説明は、『Oracle Databaseリファレンス』を参照してください。

- オブジェクト表の詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。

- ヒストグラムおよび表の統計生成の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- 「表、索引およびクラスタの分析」

21 索引の管理

この章の内容は、次のとおりです。

- 索引について

- 索引を管理するためのガイドライン

- 索引の作成

- 索引の変更

- 索引の領域使用の監視

- 索引の削除

- 索引のデータ・ディクショナリ・ビュー

索引について

索引は表およびクラスタと関連付けられているオプション構造で、これにより表に対するSQL問合せをより迅速に実行できます。このマニュアルで、索引の使用により、索引がない場合よりも高速に情報を検索できるように、Oracle Databaseの索引は、表データへのより高速なアクセス・パスを提供します。索引は問合せをリライトすることなく使用できます。結果は同じですが、より高速に得られます。

Oracle Databaseは、補完的なパフォーマンス機能を持つ複数の索引付け方法を提供します。それらは次のとおりです。

- Bツリー索引: デフォルトの設定で、最も一般的です。

- Bツリー・クラスタ索引: 特にクラスタ用に定義します。

- ハッシュ・クラスタ索引: 特にハッシュ・クラスタ用に定義します。

- グローバル索引とローカル索引: パーティション表とパーティション索引に関連します。

- 逆キー索引: Oracle Real Application Clustersアプリケーションに最も役立ちます。

- ビットマップ索引: サイズが小さいので、小さい値の集合を持つ列に効果的です。

- ファンクション索引: 事前計算された関数や式の値を含みます。

- ドメイン索引: アプリケーションまたはカートリッジに固有の索引です。

索引は、対応付けられた表内のデータから論理的にも物理的にも独立しています。索引は独立した構造体であり、記憶域を必要とします。索引は、実表、データベース・アプリケーションまたはその他の索引に影響を与えることなく、作成または削除できます。索引に対応する表に対して行の挿入、更新および削除が発生すると、データベースは索引を自動的にメンテナンスします。索引を削除しても、すべてのアプリケーションは引き続き動作可能です。ただし、それまで索引が付けられていたデータへのアクセスが遅くなります。

関連項目:

- 索引の概要については、『Oracle Database概要』を参照してください。

- 第19章「スキーマ・オブジェクトの領域の管理」

索引を管理するためのガイドライン

ここでは、索引管理のガイドラインについて説明します。この項の内容は、次のとおりです。

- 表データ挿入後の索引の作成

- 正しい表および列への索引付け

- パフォーマンスのための索引列の順序付け

- 表当たりの索引数の制限

- 不必要な索引の削除

- 索引およびセグメント作成の遅延

- 索引サイズの見積りと記憶域パラメータの設定

- 各索引の表領域の指定

- 索引作成のパラレル化

- 索引作成時のNOLOGGINGの使用

- 使用禁止または不可視索引の使用について

- 索引の結合と再作成に関するコストと利点の検討

- 制約を使用禁止または削除する前のコストの検討

関連項目:

- Oracleが提供する各種索引付け方法の説明など、索引と索引付けの概念に関する情報は、『Oracle Database概要』を参照してください。

- ビットマップ索引の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- ドメイン固有のオペレータと索引付け方法の定義方法およびOracle Databaseサーバーへの統合方法については、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。

表データ挿入後の索引の作成

データは、通常、SQL*Loaderまたはインポート・ユーティリティを使用して表に挿入またはロードされます。データの挿入またはロードの後に表の索引を作成すると効率がよくなります。データのロード前に1つ以上の索引を作成すると、データベースに行が挿入されるたびに索引を更新する必要があります。

すでにデータが格納されている表に索引を作成するには、ソート領域が必要です。索引の作成ユーザーに割り当てられているメモリーから確保されるソート領域もあります。各ユーザーのソート領域の大きさは、初期化パラメータSORT_AREA_SIZEによって決まります。また、データベースでは、索引作成のときにのみユーザーの一時表領域に割り当てられる一時セグメントとの間でソート情報のスワップが行われます。

特定の条件下では、SQL*Loaderのダイレクト・パス・ロードを使用してデータを表にロードし、データがロードされたときに索引が作成されるようにすることも可能です。

関連項目:
SQL*Loaderを使用したダイレクト・パス・ロードの詳細は、『Oracle Databaseユーティリティ』を参照してください。

正しい表および列への索引付け

索引を作成するかどうか判断する際は、次のガイドラインを参考にしてください。

- 大きな表で頻繁に検索される行の割合が15%未満の場合は索引を作成してください。割合は、表スキャンの相対速度、および索引キーに対する行データの分散度によって大きく異なります。表スキャンが高速であるほど割合は低くなり、クラスタ化されている行データが多いほど割合は高くなります。

- 複数の表を結合するパフォーマンスを改善するには、結合に使用する列に索引を付けます。

注意:
主キーおよび一意キーには自動的に索引が作成されますが、外部キーには必要に応じて索引を作成できます。

- 小さい表に索引は不要です。問合せに時間がかかる場合は、表のサイズが大きくなっていることが考えられます。

索引付けに適した列

列のタイプによっては、索引を付ける方が望ましいものがあります。次のような特性を1つ以上持つ列には、索引の作成を検討してください。

- 一意の値が比較的多い。

- 値の範囲が広い(通常の索引が適している)。

- 値の範囲が狭い(ビットマップ索引が適している)。

- 列に多くのNULLが含まれているが、通常の問合せでは必ず値を持つ列を選択する。この場合は次の句を使用します。

WHERE COL_X > -9.99 * power(10,125)

この句は、次の句よりも適しています。

WHERE COL_X IS NOT NULL

これは、最初の句ではCOL_Xの索引を使用しているためです(COL_Xは数値列とします)。

索引付けに適さない列

次のような特性を持つ列は、索引付けには適していません。

- 列にNULLが多く含まれていて、NULL以外の値を検索することがない。

LONG列およびLONG RAW列には索引を作成できません。

仮想列

仮想列には、一意索引または非一意索引を作成できます。仮想列に定義された表の索引は、表のファンクション索引と同じです。

関連項目:
「ファンクション索引の作成」

パフォーマンスのための索引列の順序付け

CREATE INDEX文の列の順序は、問合せのパフォーマンスに影響を与えます。一般的には、最も頻繁に使用する列を最初に指定します。

たとえば、col1、col2およびcol3の各列にアクセスする問合せを高速にするために、列にまたがる単一の索引を作成すると、col1のみにアクセスする問合せ、またはcol1とcol2にアクセスする問合せが速くなります。しかし、col2のみにアクセスする問合せ、col3のみにアクセスする問合せ、およびcol2とcol3にアクセスする問合せは速くなりません。

注意:
先頭列のカーディナリティが非常に低い場合などには、データベースでは、このタイプの索引が使用されることがあります。索引スキップ・スキャンの詳細は、『Oracle Database概要』を参照してください。

表当たりの索引数の制限

表は、多数の索引を持つことができます。ただし、索引の数が多いほど、表を変更するときに発生するオーバーヘッドが増加します。特に、行を挿入したり削除したりするときは、その表の索引もすべて更新する必要があります。また、列を更新するときには、その列を含む索引もすべて更新する必要があります。

このように、表からデータを検索する速度とその表を更新する速度は二律背反的です。たとえば、表が主に読取り専用である場合、索引を増やすと有効ですが、表が頻繁に更新される場合は、索引を少なくすることをお薦めします。

不必要な索引の削除

次のような状況では、索引の削除を検討してください。

- 問合せを高速化しない。これには、たとえば表が非常に小さい場合や、表の行数は多いものの、索引エントリが非常に少ない場合などがあります。

- アプリケーションの問合せが索引を使用しない場合。

- 索引を再作成する前にいったん削除する必要がある場合。

関連項目:
「索引の使用状況の監視」

索引およびセグメント作成の遅延

索引セグメントの作成は、対応付けられた表でセグメント作成の遅延が発生すると、遅延されます。これは、索引セグメントの作成には対応付けられた表の動作が反映されるためです。

関連項目:
詳細は、「セグメント作成の遅延の理解」を参照してください。

索引サイズの見積りと記憶域パラメータの設定

索引を作成する前にそのサイズを見積っておくと、ディスク領域の計画と管理がいっそう容易になります。索引の見積りサイズの合計と、表、UNDO表領域およびREDOログ・ファイルの見積りを使用して、作成するデータベースを格納するために必要なディスク容量を決定できます。この見積りを利用して適切なハードウェアを購入できます。

個々の索引の見積りサイズを使用することで、索引が使用するディスク領域をより適切に管理できます。索引を作成するときに、適切な記憶域パラメータを設定し、その索引を使用するアプリケーションのI/Oパフォーマンスを改善できます。たとえば、索引を作成する前に最大サイズを予測したとします。次に索引の作成時に記憶域パラメータを設定すると、表データ・セグメントに対して割り当てられるエクステントが少なくなり、すべての索引データはディスク領域の比較的連続したセクションに格納されます。これにより、この索引に関するディスクのI/O操作にかかる時間が削減されます。

単一の索引エントリの最大サイズは、データ・ブロック・サイズのおよそ2分の1です。

索引を主キー制約または一意キー制約を規定するために使用する場合、その索引のために作成する索引セグメントの記憶域パラメータは、次のどちらかの方法で設定できます。

- ENABLE ... CREATE TABLE文またはALTER TABLE文のUSING INDEX句

- ALTER INDEX文のSTORAGE句

各索引の表領域の指定

索引はどの表領域にも作成できます。索引は、その索引を付けた表と同じ表領域にも、異なる表領域にも作成できます。表とその索引に対して同じ表領域を使用すると、(表領域やファイルのバックアップなどの)データベースのメンテナンスやアプリケーションの可用性確保の面で便利です。これは、すべての関連するデータが常にまとまってオンラインになっているためです。

表とその索引に対して(異なるディスク上にある)異なる表領域を使用すると、表と索引を同じ表領域に格納するよりも、パフォーマンスが向上します。これは、ディスクの競合が解消されるためです。表とその索引に対して異なる表領域を使用し、一方の(データまたは索引のいずれかを含む)表領域がオフラインになっている場合には、その表を参照している文が動作する保証はありません。

索引作成のパラレル化

表作成をパラレル化できるのと同様に、索引の作成もパラレル化できます。複数のプロセスが同時に動作して索引を作成するため、1つのサーバー・プロセスが順に索引を作成する場合よりも高速に索引を作成できます。

索引を並行して作成する場合、問合せサーバー・プロセスごとに別々の記憶域パラメータが使用されます。したがって、INITIAL値を5MB、並行度を12で索引を作成する場合は、作成時に60MB以上の記憶域を使用します。

関連項目:
パラレル実行の使用に関する詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

索引作成時のNOLOGGINGの使用

CREATE INDEX文でNOLOGGINGを指定すると、索引の作成時に最小限のREDOログ・レコードしか生成されません。

注意:
NOLOGGINGを使用して作成された索引はアーカイブされないため、索引作成後にバックアップを実行してください。

NOLOGGINGを使用して索引を作成すると、次のような利点があります。

- REDOログ・ファイルの領域を節約できます。

- 索引の作成に要する時間が削減できます。

- 大規模な索引のパラレル作成のパフォーマンスが向上します。

一般に、LOGGINGを指定しないで索引を作成した場合、小規模な索引より大規模な索引の方が相対的にパフォーマンスの向上が大きくなります。小規模な索引をLOGGINGを指定しないで作成しても、索引作成に要する時間にはほとんど影響しません。一方、大規模な索引では、特に索引作成のパラレル化もあわせて指定したときに、パフォーマンスが著しく向上します。

使用禁止または不可視索引の使用について

使用禁止または不可視索引は、バルク・ロードのパフォーマンスを向上させる場合、索引を削除する前に削除によって発生する影響をテストする場合、またはオプティマイザによるその索引の使用を停止する場合に使用します。

使用禁止索引

使用禁止索引は、オプティマイザで無視され、DMLではメンテナンスされません。索引を使用禁止にする理由の1つに、バルク・ロードのパフォーマンス向上があります。(行の挿入時にデータベースで索引のメンテナンスを実行する必要がないため、バルク・ロードが速くなります。)索引を削除した後に再度作成する場合はCREATE INDEX文のパラメータを正確に覚えておく必要がありますが、この方法では索引を使用禁止にした後に再構築できます。

使用禁止状態の索引を作成することも、既存の索引または索引パーティションに使用禁止のマークを付けることもできます。場合によっては、データベースで索引の構築中に障害が発生したときなどに、索引に使用禁止のマークが付けられることがあります。パーティション化された索引のパーティションのうちの1つを使用禁止にした場合、その索引の他のパーティションは有効なままです。

使用禁止の索引または索引パーティションを使用するには、再構築するか、または削除して再作成する必要があります。表を切り捨てると、使用禁止の索引が有効になります。

Oracle Database 11g リリース2以降、既存の索引を使用禁止にすると、その索引セグメントが削除されます。

使用禁止の索引の機能は、SKIP_UNUSABLE_INDEXESの初期化パラメータの設定により異なります。SKIP_UNUSABLE_INDEXESがTRUE(デフォルト)の場合は、次のようになります。

- 表に対するDML文は続行されますが、使用禁止索引のメンテナンスは実行されません。

- UNIQUE制約を規定する使用禁止索引がある場合は、DML文はエラーで終了します。

- パーティション化されていない索引では、オプティマイザはSELECT文のアクセス計画の作成時に使用禁止索引を考慮しません。唯一の例外は、索引がINDEX()のヒントで明示的に指定された場合です。

- パーティション化された索引に使用禁止のパーティションが1つ以上あるとき、削除可能な索引パーティションがあるかどうかを問合せのコンパイル時に判断できない場合は、オプティマイザではその索引を処理しません。これは、表がパーティション化されているかどうかにかかわらず同様です。唯一の例外は、索引がINDEX()のヒントで明示的に指定された場合です。

SKIP_UNUSABLE_INDEXESがFALSEの場合は、次のようになります。

- 使用禁止の索引または索引パーティションがある場合は、これらの索引または索引パーティションを更新するDML文はエラーで終了します。

- SELECT文は、使用禁止索引または使用禁止索引パーティションが存在しても、オプティマイザでアクセス計画に使用されない場合は、通常どおり実行されます。ただし、オプティマイザが使用禁止索引または使用禁止索引パーティションを使用する場合は、この文はエラーで終了します。

不可視索引

Oracle Database 11gリリース1以降、不可視索引を作成したり、既存の索引を不可視にできます。不可視索引は、セッションまたはシステム・レベルでOPTIMIZER_USE_INVISIBLE_INDEXES初期化パラメータを明示的にTRUEに設定しないかぎり、オプティマイザで無視されます。使用禁止索引と異なり、不可視索引はDML文中でも維持されます。パーティション化された索引は不可視にできますが、個別の索引パーティションを不可視にし、残りのパーティションを可視のままにすることはできません。不可視索引を使用して、次のことを実行できます。

- 索引を削除する前に、削除した状態をテストできます。

- アプリケーション全体に影響を与えずに、アプリケーションの特定の操作またはモジュールに対して一時的な索引構造を使用できます。

関連項目:

- 「使用禁止索引の作成」

- 「不可視索引の作成」

- 「索引の使用禁止化」

- 「索引の不可視化」

索引の結合と再作成に関するコストと利点の検討

不適切な索引サイズの設定やサイズの拡大によって、索引の断片化が生じることがあります。断片化を解消または低減するには、索引を再作成するか、索引を結合します。ただし、どちらの作業を行う場合も、事前に各選択肢のコストと利点を分析し、状況に最も有効な方法を選択してください。表21-1は、索引を再作成する場合と結合する場合のコストと利点を示しています。

表21-1 索引の結合と再作成に関するコストと利点

索引の再作成

索引の結合

索引を別の表領域に迅速に移動できる。

索引を別の表領域に移動することはできない。

多くのディスク領域を必要とし、コストが高い。

必要なディスク領域が少ないため、コストが低い。

新しいツリーを作成して、可能であればその高さを縮小する。

ツリーの同じブランチ内のリーフ・ブロックを結合する。

オリジナルの索引を削除せずに、記憶域パラメータと表領域パラメータを迅速に変更できる。

索引のリーフ・ブロックを迅速に解放できる。

再利用のために解放できるBツリー索引のリーフ・ブロックがある場合は、次の文を使用してそのようなリーフ・ブロックをマージできます。

ALTER INDEX vmoore COALESCE;

図21-1は、ALTER INDEX COALESCEが索引vmooreに与える影響を示しています。操作を実行する前は、最初の2つのリーフ・ブロックは50%使用されています。したがって、フラグメンテーションを削減して最初のブロック全体を使用しながら、2番目のブロックを解放することが可能になります。

図21-1 索引の結合

制約を使用禁止または削除する前のコストの検討

一意キーと主キーには対応する索引があるため、UNIQUE制約やPRIMARY KEY制約を使用禁止または削除するかどうかを検討するときには、索引の削除と作成にかかわるコストを分析してください。また、UNIQUEキー制約やPRIMARY KEY制約に対する索引が大きい場合には、その索引を削除して再作成するよりも、その制約を使用可能な状態のままにするほうが時間を節約できます。UNIQUE制約やPRIMARY KEY制約を削除または使用禁止にするときには、索引を保持するか削除するかを明示的に指定することもできます。

関連項目:
「整合性制約の管理」

索引の作成

ここでは、索引の作成方法について説明します。

注意:
これらの操作は、索引統計も収集します。

自分のスキーマ内に索引を作成する場合は、次のいずれかの条件のうち、少なくとも1つが満たされている必要があります。

- 索引を付ける表またはクラスタが、自分のスキーマに格納されている。

- 索引を付ける表に対するINDEX権限を持っている。

- CREATE ANY INDEXシステム権限を持っている。

別のスキーマ内に索引を作成する場合は、次のすべての条件が満たされている必要があります。

- CREATE ANY INDEXシステム権限を持っている。

- 目的のスキーマの所有者が、索引または索引パーティションを作成する表領域への割当て制限を持っているか、UNLIMITED TABLESPACEシステム権限を持っている。

この項の内容は次のとおりです。

- 索引の明示的な作成

- 一意索引の明示的な作成

- 制約に対応付けられた索引の作成

- 大きな索引の作成

- オンラインでの索引の作成

- ファンクション索引の作成

- キー圧縮型索引の作成

- 使用禁止索引の作成

- 不可視索引の作成

索引の明示的な作成

SQL文CREATE INDEXを使用して、索引を明示的に(整合性制約の他に)作成できます。次の文は、emp表のename列に対してemp_enameという名前の索引を作成します。

CREATE INDEX emp_ename ON emp(ename)
TABLESPACE users
STORAGE (INITIAL 20K
NEXT 20k);

索引に対して、複数の記憶域設定および1つの表領域が明示的に指定されています。索引に記憶域オプション(INITIALやNEXTなど)を指定しない場合、デフォルトの表領域または指定された表領域のデフォルトの記憶域オプションが自動的に使用されます。

関連項目:
CREATE INDEX文の構文と制限事項については、『Oracle Database SQL言語リファレンス』を参照してください。

一意索引の明示的な作成

索引は、一意にすることも、重複を許可することもできます。一意索引を使用すると、表の複数行のキー列に重複した値が入らないことが保証されます。非一意索引では、列の値にこのような制限はありません。

一意索引を作成するには、CREATE UNIQUE INDEX文を使用します。次の例では、一意索引を作成しています。

CREATE UNIQUE INDEX dept_unique_index ON dept (dname)
TABLESPACE indx;

別の方法として、目的の列にUNIQUE整合性制約を定義することもできます。データベースでは、一意のキーに対して自動的に一意索引を定義することによって、UNIQUE整合性制約を規定します。この詳細は次の項に記載されています。ただし、問合せのパフォーマンス向上のために必要な索引は、一意索引も含め、明示的に作成することをお薦めします。

関連項目:
パフォーマンス向上のための索引作成の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

制約に対応付けられた索引の作成

Oracle Databaseは、表にUNIQUEキー整合性制約またはPRIMARY KEY整合性制約を規定するために、一意キーまたは主キーの一意索引を作成します。この索引は、制約を使用可能にしたときに、データベースによって自動的に作成されます。CREATE TABLE文またはALTER TABLE文を発行して索引を作成する場合は、それ以外に必要なアクションはありませんが、必要に応じて、USING INDEX句を指定して索引作成を制御できます。これは、制約を定義して使用可能にする場合、および定義したが使用禁止にしていた制約を使用可能にする場合のどちらでも可能です。

UNIQUE制約またはPRIMARY KEY制約を使用可能にし、対応する索引を作成するには、表の所有者が索引を格納する表領域の割当て制限またはUNLIMITED TABLESPACEシステム権限を持っている必要があります。特に指定しないかぎり、制約に対応付けられた索引には、常に制約と同じ名前が付けられます。

注意:
並列性を利用できるように制約を使用可能にする効率的な手順は、「整合性制約の効率的な使用: 手順」を参照してください。

制約に対応付けられた索引に対する記憶域オプションの指定

USING INDEX句を使用すると、 UNIQUE制約またはPRIMARY KEY制約に対応する索引の記憶域オプションを設定できます。次のCREATE TABLE文は、PRIMARY KEY制約を使用可能にして、対応する索引の記憶域オプションを指定します。

CREATE TABLE emp (
empno NUMBER(5) PRIMARY KEY, age INTEGER)
ENABLE PRIMARY KEY USING INDEX
TABLESPACE users;

制約に対応付けられた索引の指定

UNIQUE制約およびPRIMARY KEY制約に対応付けられた索引をより明示的に制御する場合、データベースでは次のことが可能です。

- 制約を規定するために使用する既存の索引の指定

- 索引の作成と制約の規定に使用するCREATE INDEX文の指定

これらのオプションは、USING INDEX句を使用して指定します。次にいくつかの例を示します。

例1:

CREATE TABLE a (
a1 INT PRIMARY KEY USING INDEX (create index ai on a (a1)));

例2:

CREATE TABLE b(
b1 INT,
b2 INT,
CONSTRAINT bu1 UNIQUE (b1, b2)
USING INDEX (create unique index bi on b(b1, b2)),
CONSTRAINT bu2 UNIQUE (b2, b1) USING INDEX bi);

例3:

CREATE TABLE c(c1 INT, c2 INT);
CREATE INDEX ci ON c (c1, c2);
ALTER TABLE c ADD CONSTRAINT cpk PRIMARY KEY (c1) USING INDEX ci;

単一の文で制約とともに索引を作成し、同じ文でその索引を別の制約にも使用する場合、Oracleでは、索引を再使用する前に索引を作成するための句の再編成を試みます。

関連項目:
「整合性制約の管理」

大きな索引の作成

極端に大きい索引を作成するときは、次の手順を使用して、索引の作成に大きな一時表領域を割り当てることを検討してください。

1. CREATE TABLESPACE文またはCREATE TEMPORARY TABLESPACE文を使用して、新しい一時表領域を作成します。

2. ALTER USER文でTEMPORARY TABLESPACEオプションを指定して、この一時表領域を自分の新しい一時表領域として割り当てます。

3. CREATE INDEX文を使用して、索引を作成します。

4. DROP TABLESPACE文を使用して、この表領域を削除します。次にALTER USER文を使用して、自分の一時表領域を元の一時表領域に再設定します。

この手順により、通常使用している一時表領域(ほとんどの場合、共有されている)が極度に肥大化して今後のパフォーマンスに影響を及ぼす問題を回避できます。

索引のオンラインでの作成

索引をオンラインで作成および再作成できます。そのため、実表の索引を作成または再作成する際に、同時に実表も更新できます。索引の作成中にDML操作を実行できますが、DDL操作はできません。索引をオンラインで作成または再作成している最中のパラレル実行はサポートされません。

次の文は、オンラインでの索引作成操作を示しています。

CREATE INDEX emp_name ON emp (mgr, emp1, emp2, emp3) ONLINE;

注意:
オンライン索引ビルドが完了するまでの時間は、表のサイズおよび同時に実行しているDML文の数に比例することに注意してください。したがって、オンライン索引ビルドはDMLアクティビティが低いときに開始することをお薦めします。

関連項目:
「既存の索引の再作成」

ファンクション索引の作成

ファンクション索引を使用すると、関数や式から返される値を修飾する問合せが可能です。関数や式の値は、事前に計算されて索引に格納されます。

ユーザー定義のファンクションに基づく索引の場合は、従来型の索引を作成するための前提条件に加えて、これらのファンクションにDETERMINISTICのマークが設定されている必要があります。さらに、これらのファンクションを別のユーザーが所有している場合は、ファンクション索引で使用するすべてのユーザー定義ファンクションに対するEXECUTEオブジェクト権限を持っている必要があります。

注意:
CREATE INDEXでは、ファンクション索引で最後に使用された関数のタイムスタンプが格納されます。このタイムスタンプは、索引の妥当性チェック時に更新されます。ファンクション索引について表領域のPoint-in-Timeリカバリを実行する場合、索引で最後に使用された関数のタイムスタンプが索引に格納されたタイムスタンプより新しい場合は、その索引には無効を示すマークが設定されます。ANALYZE INDEX...VALIDATE STRUCTURE文を使用して、この索引の妥当性をチェックする必要があります。

ファンクション索引の具体例として、ファンクションarea(geo)に定義されているファンクション索引(area_index)を定義する次の文を示します。

CREATE INDEX area_index ON rivers (area(geo));

次のSQL文では、area(geo)がWHERE句で参照されているため、オプティマイザは索引area_indexの使用を考慮します。

SELECT id, geo, area(geo), desc
FROM rivers
WHERE Area(geo) >5000;

表の所有者は、ファンクション索引で使用されるファンクションに対してEXECUTE権限を持つ必要があります。

ファンクション索引は使用するファンクションに依存するため、ファンクションの変更時に無効にできます。ファンクションが有効な場合は、ALTER INDEX...ENABLE文を使用して、使用禁止になっているファンクション索引を使用可能にすることができます。ALTER INDEX...DISABLE文では、ファンクション索引を使用禁止にすることができます。ファンクションの本体で作業をする場合は、ファンクション索引を使用禁止にするか検討してください。

注意:
ファンクション索引を作成するかわりに、仮想列をターゲット表に追加して仮想列に索引を付けることができます。詳細は、「表の概要」を参照してください。

関連項目:

- ファンクション索引の詳細は、『Oracle Database概要』を参照してください。

- アプリケーションでファンクション索引を使用する際の詳細と使用例については、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

キー圧縮型索引の作成

キー圧縮を使用して索引を作成すると、キー列の接頭辞が同じ値で繰り返し格納されることを回避できます。

キー圧縮によって、索引キーは接頭辞および接尾辞エントリに分割されます。圧縮するために、接頭辞エントリは索引ブロック内のすべての接尾辞エントリ間で共有されます。このような共有によって、領域が大幅に節約され、各索引ブロックに格納できるキー数が増え、パフォーマンスが向上します。

キー圧縮は、次のような状況で役立ちます。

- ROWIDを追加してキーを一意にしている非一意索引がある場合。このような状況でキー圧縮を使用すると、重複キーは接頭辞エントリとして索引ブロックにROWIDなしで格納されます。残りの行は、ROWIDのみからなる接尾辞エントリとなります。

- 一意の複数列索引がある場合。

キー圧縮を使用可能にするには、COMPRESS句を使用します。また、接頭辞の長さをキー列の数で指定して、キー列が接頭辞および接尾辞エントリにどのように分割されるかを識別できます。たとえば、次の文は、索引リーフ・ブロックの重複するキーを圧縮します。

CREATE INDEX  emp_ename ON emp(ename)
TABLESPACE users
COMPRESS 1;

索引の再作成中にCOMPRESS句を指定することもできます。たとえば、次のようにして、再作成中に圧縮を使用禁止にすることができます。

ALTER INDEX emp_ename REBUILD NOCOMPRESS;

関連項目:
キー圧縮の詳細は、『Oracle Database概要』を参照してください。

使用禁止索引の作成

UNUSABLE状態の索引を作成した場合、オプティマイザで無視され、DMLではメンテナンスされません。使用禁止の索引を使用可能にする場合、再構築するか、または削除して再作成する必要があります。

索引がパーティション化されている場合、索引パーティションはすべてUNUSABLEとしてマークされます。

Oracle Database 11g リリース2以降、データベースは使用禁止索引の作成時に索引セグメントを作成しません。

次の手順では、使用禁止の索引を作成する方法と、データベースに索引に関する詳細を問い合せる方法を示します。

使用禁止索引を作成する手順は、次のとおりです。

1. 必要に応じて、索引を付ける表を作成します。
たとえば、次のように、hr.employees_partという名前でハッシュ・パーティション表を作成します。

sh@PROD> CONNECT hr
Enter password: **
Connected.

hr@PROD> CREATE TABLE employees_part
2    PARTITION BY HASH (employee_id) PARTITIONS 2
3    AS SELECT * FROM employees;

Table created.

hr@PROD> SELECT COUNT(*) FROM employees_part;

COUNT(*)
----------
107

2. キーワードUNUSABLEで索引を作成します。
次の例では、employees_partにローカル・パーティション索引を作成し、索引パーティションにp1_i_emp_enameおよびp2_i_emp_enameという名前を付け、p1_i_emp_enameを使用禁止にしています。

hr@PROD> CREATE INDEX i_emp_ename ON employees_part (employee_id)
2    LOCAL (PARTITION p1_i_emp_ename UNUSABLE, PARTITION p2_i_emp_ename);

Index created.

3. オプションで、データ・ディクショナリに問い合せて索引が使用禁止になっていることを確認できます。
次の例では、索引i_emp_enameとその2つのパーティションのステータスを問い合せて、パーティションp2_i_emp_enameのみが使用禁止になっていることを示しています。

hr@PROD> SELECT INDEX_NAME AS "INDEX OR PARTITION NAME", STATUS
2  FROM   USER_INDEXES
3  WHERE  INDEX_NAME = 'I_EMP_ENAME'
4  UNION ALL
5  SELECT PARTITION_NAME AS "INDEX OR PARTITION NAME", STATUS
6  FROM   USER_IND_PARTITIONS
7  WHERE  PARTITION_NAME LIKE '%I_EMP_ENAME%';

INDEX OR PARTITION NAME        STATUS
------------------------------ --------
I_EMP_ENAME                    N/A
P1_I_EMP_ENAME                 UNUSABLE
P2_I_EMP_ENAME                 USABLE

4. オプションで、データ・ディクショナリに問い合せて、パーティションの記憶域が存在するかどうかを確認できます。
たとえば、次の問合せは索引パーティションp2_i_emp_enameのみがセグメントを占有していることを示しています。p1_i_emp_enameは使用禁止として作成したため、セグメントが割り当てられませんでした。

hr@PROD> COL PARTITION_NAME FORMAT a14
hr@PROD> COL SEG_CREATED FORMAT a11
hr@PROD> SELECT p.PARTITION_NAME, p.STATUS AS "PART_STATUS",
2         p.SEGMENT_CREATED AS "SEG_CREATED",
3  FROM   USER_IND_PARTITIONS p, USER_SEGMENTS s
4  WHERE  s.SEGMENT_NAME = 'I_EMP_ENAME';

PARTITION_NAME PART_STA SEG_CREATED
-------------- -------- -----------
P2_I_EMP_ENAME USABLE   YES
P1_I_EMP_ENAME UNUSABLE NO

関連項目:

- 「使用禁止または不可視索引の使用について」

- 「索引の使用禁止化」

- 使用禁止索引の作成方法および制限事項の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

不可視索引の作成

不可視索引とは、セッションまたはシステム・レベルでOPTIMIZER_USE_INVISIBLE_INDEXES初期化パラメータを明示的にTRUEに設定しないかぎり、オプティマイザで無視される索引です。

不可視索引を作成する手順は、次のとおりです。

- CREATE INDEX文をINVISIBLEキーワードとともに指定します。
次の文は、emp表のename列に対してemp_enameという名前の不可視索引を作成します。

CREATE INDEX emp_ename ON emp(ename)
TABLESPACE users
STORAGE (INITIAL 20K
NEXT 20k)
INVISIBLE;

関連項目:

- 「使用禁止または不可視索引の使用について」

- 「索引の不可視化」

- 不可視索引の作成の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

索引の変更

索引を変更するには、その索引が自分のスキーマに含まれているか、またはALTER ANY INDEXシステム権限を持っている必要があります。ALTER INDEX文では、次の操作を実行できます。

- 既存の索引の再作成または結合

- 未使用領域の割当て解除または新規エクステントの割当て

- パラレル実行の指定(または指定解除)およびその並列度の変更

- 記憶域パラメータまたは物理属性の変更

- LOGGINGまたはNOLOGGINGの指定

- キー圧縮の使用可能または使用禁止の設定

- 索引へのUNUSABLEマークの設定

- 索引の不可視化

- 索引の名前変更

- 索引使用状況の監視の開始または停止

索引の列構造は変更できません。

これらの操作のいくつかについて、次の項で詳しく説明します。

- 索引の記憶域特性の変更

- 既存の索引の再作成

- 索引の使用禁止化

- 索引の不可視化

- 索引の使用状況の監視

関連項目:

- ALTER INDEX文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

索引の記憶域特性の変更

主キーと一意キーの整合性制約を規定するためにデータベースによって作成される索引も含めて、どの索引の記憶域パラメータも、ALTER INDEX文を使用して変更できます。たとえば、次の文はemp_ename索引を変更します。

ALTER INDEX emp_ename
STORAGE (NEXT 40);

パラメータINITIALとMINEXTENTSは変更できません。他の記憶域パラメータの新しい設定はすべて、その後に索引に割り当てられるエクステントにのみ影響します。

整合性制約を実装する索引では、ENABLE句のUSING INDEX副次句を指定したALTER TABLE文を発行することによって、記憶域パラメータを調整できます。たとえば、次の文は、表empに作成された索引の記憶域オプションを変更して、主キー制約を規定します。

ALTER TABLE emp
ENABLE PRIMARY KEY USING INDEX;

関連項目:
ALTER INDEX文の構文と制限事項については、『Oracle Database SQL言語リファレンス』を参照してください。

既存の索引の再作成

既存の索引を再作成する前に、表21-1の説明に従って、索引を再作成する方法と結合する方法のコストと利点を比較してください。

索引を再作成するときは、既存の索引をデータソースとして使用できます。このようにして索引を作成すると、記憶特性の変更や新しい表領域への移動ができます。既存のデータソースに基づいて索引を再作成すると、ブロック内の断片化も解消されます。索引を削除してからCREATE INDEX文を使用するよりも、既存の索引を再構築する方がパフォーマンスに優れています。

次の文は、既存の索引emp_nameを再作成します。

ALTER INDEX emp_name REBUILD;

REBUILD句は索引名の直後に使用し、他のオプションの前に置く必要があります。DEALLOCATE UNUSED句とともに使用することはできません。

索引はオンラインで再作成できます。オンラインで再作成することにより、再作成と同時に実表を更新できます。次の文は、emp_name索引をオンラインで再作成します。

ALTER INDEX emp_name REBUILD ONLINE;

別のユーザーのスキーマにオンラインで索引を再作成するには、さらに次のシステム権限が必要です。

- CREATE ANY TABLE

- CREATE ANY INDEX

注意:
オンラインでの索引の再作成には、別の方式による索引の再作成に比べ、処理できるキーの最大長に関して、より厳しい制限があります。オンラインでの再構築中にORA-1450(最大キー長を超過)エラーが発生した場合は、索引のオフラインでの再構築または結合を行うか、索引を削除してから再作成してください。

索引の再作成に必要な大きさの領域がない場合、かわりに索引を結合する方法が使用できます。索引の結合はオンライン操作です。

関連項目:

- 「オンラインでの索引の作成」

- 「索引の領域使用の監視」

索引の使用禁止化

索引を使用禁止にした場合、オプティマイザで無視され、DMLではメンテナンスされません。パーティション化された索引のパーティションのうちの1つを使用禁止にした場合、その索引の他のパーティションは有効なままです。

使用禁止の索引または索引パーティションを使用する場合は、事前に索引または索引パーティションを再作成するか、または削除した後再作成する必要があります。

次の手順では、索引および索引パーティションを使用禁止にする方法と、オブジェクトのステータスを問い合せる方法を示します。

索引を使用禁止にする手順は、次のとおりです。

1. データ・ディクショナリに問い合せて、既存の索引または索引パーティションが使用可能であるか、使用禁止であるかを確認します。
たとえば、次の問合せを発行します(スペースの節約のため出力を切り捨てています)。

hr@PROD> SELECT INDEX_NAME AS "INDEX OR PART NAME", STATUS, SEGMENT_CREATED
2  FROM   USER_INDEXES
3  UNION ALL
4  SELECT PARTITION_NAME AS "INDEX OR PART NAME", STATUS, SEGMENT_CREATED
5  FROM   USER_IND_PARTITIONS;

INDEX OR PART NAME             STATUS   SEG
------------------------------ -------- ---
I_EMP_ENAME                    N/A      N/A
JHIST_EMP_ID_ST_DATE_PK        VALID    YES
JHIST_JOB_IX                   VALID    YES
JHIST_EMPLOYEE_IX              VALID    YES
JHIST_DEPARTMENT_IX            VALID    YES
EMP_EMAIL_UK                   VALID    NO
.
.
.
COUNTRY_C_ID_PK                VALID    YES
REG_ID_PK                      VALID    YES
P2_I_EMP_ENAME                 USABLE   YES
P1_I_EMP_ENAME                 UNUSABLE NO

22 rows selected.

前述の出力は、索引パーティションp1_i_emp_enameのみが使用禁止であることを示しています。

2. 索引または索引パーティションを使用禁止にするには、UNUSABLEキーワードを指定します。
次の例では、索引emp_email_ukを使用禁止にしています。

hr@PROD> ALTER INDEX emp_email_uk UNUSABLE;

Index altered.

次の例では、索引パーティションp2_i_emp_enameを使用禁止にしています。

hr@PROD> ALTER INDEX i_emp_ename MODIFY PARTITION p2_i_emp_ename UNUSABLE;

Index altered.

3. オプションで、データ・ディクショナリに問い合せて、ステータス変更を確認できます。
たとえば、次の問合せを発行します(スペースの節約のため出力を切り捨てています)。

hr@PROD> SELECT INDEX_NAME AS "INDEX OR PARTITION NAME", STATUS,
2  SEGMENT_CREATED
3  FROM   USER_INDEXES
4  UNION ALL
5  SELECT PARTITION_NAME AS "INDEX OR PARTITION NAME", STATUS,
6  SEGMENT_CREATED
7  FROM   USER_IND_PARTITIONS;

INDEX OR PARTITION NAME        STATUS   SEG
------------------------------ -------- ---
I_EMP_ENAME                    N/A      N/A
JHIST_EMP_ID_ST_DATE_PK        VALID    YES
JHIST_JOB_IX                   VALID    YES
JHIST_EMPLOYEE_IX              VALID    YES
JHIST_DEPARTMENT_IX            VALID    YES
EMP_EMAIL_UK                   UNUSABLE NO
.
.
.
COUNTRY_C_ID_PK                VALID    YES
REG_ID_PK                      VALID    YES
P2_I_EMP_ENAME                 UNUSABLE NO
P1_I_EMP_ENAME                 UNUSABLE NO

22 rows selected.

i_emp_enameセグメントとemp_email_ukセグメントが消費している領域を問い合せると、どちらのセグメントも存在しなくなったことが示されます。

hr@PROD> SELECT SEGMENT_NAME, BYTES
2  FROM   USER_SEGMENTS
3  WHERE  SEGMENT_NAME IN ('I_EMP_ENAME', 'EMP_EMAIL_UK');

no rows selected

関連項目:

- 「使用禁止または不可視索引の使用について」

- 「使用禁止索引の作成」

- UNUSABLEキーワードの詳細および制限については、『Oracle Database SQL言語リファレンス』を参照してください。

索引の不可視化

不可視索引は、セッションまたはシステム・レベルでOPTIMIZER_USE_INVISIBLE_INDEXES初期化パラメータを明示的にTRUEに設定しないかぎり、オプティマイザで無視されます。索引を非表示にするのは、使用禁止または削除の代替手段です。個別の索引パーティションは不可視にできません。試みた場合はエラーとなります。

索引を不可視にする手順は、次のとおりです。

- 次のSQL文を発行します。

ALTER INDEX index INVISIBLE;

不可視状態の索引を可視にする手順は、次のとおりです。

- 次のSQL文を発行します。

ALTER INDEX index VISIBLE;

索引が可視か不可視かを判別する手順は、次のとおりです。

- USER_INDEXES、ALL_INDEXESまたはDBA_INDEXESディクショナリ・ビューの問合せを行います。
たとえば、索引ind1が不可視かどうかを判別するには、次の問合せを発行します。

SELECT INDEX_NAME, VISIBILITY FROM USER_INDEXES
WHERE INDEX_NAME = 'IND1';

INDEX_NAME   VISIBILITY
----------   ----------
IND1         VISIBLE

関連項目:

- 「使用禁止または不可視索引の使用について」

- 「不可視索引の作成」

索引の名前変更

索引の名前を変更するには、次の文を発行します。

ALTER INDEX index_name RENAME TO new_name;

索引の使用状況の監視

Oracle Databaseには、索引を監視し、それらが使用されているかどうかを判別する手段が用意されています。未使用の索引がある場合は、それを削除して不要な文によるオーバーヘッドを解消できます。

索引の使用状況の監視を開始するには、次の文を発行します。

ALTER INDEX index MONITORING USAGE;

その後、監視を停止するには、次の文を発行します。

ALTER INDEX index NOMONITORING USAGE;

監視中の索引について、それが使用されているかどうか確認するには、ビューV$OBJECT_USAGEを問い合せます。このビューにはUSED列があり、監視期間中に索引が使用されたかどうかによってYESまたはNOの値を持ちます。また、このビューには監視の開始時間と停止時間も記録され、MONITORING列(YES/NO)には使用状況の監視が現在アクティブであるかどうかが示されます。

MONITORING USAGEを指定するたびに、指定した索引のV$OBJECT_USAGEビューはリセットされます。前回の使用方法の情報はクリアまたはリセットされ、新しい開始時間が記録されます。NOMONITORING USAGEを指定すると、これ以上の監視は実行されず、監視期間の終了時間が記録されます。次にALTER INDEX...MONITORING USAGE文が発行されるまで、ビューの情報は変更されずに保持されます。

索引の領域使用の監視

索引のキー値が頻繁に挿入、更新および削除されると、時間が経つにつれて領域の効率性が失われることがあります。索引の領域の使用状況の効率性を定期的に監視するには、まずANALYZE INDEX...VALIDATE STRUCTURE文を使用し、次にINDEX_STATSビューを問い合せて索引構造を分析します。

SELECT PCT_USED FROM INDEX_STATS WHERE NAME = 'index';

索引の領域使用の割合は、どれくらい頻繁に索引キーが挿入、更新または削除されるかによって変化します。次の一連の操作を何度か実行し、索引の平均的な領域使用効率の履歴を作成してください。

- 統計分析

- 索引の検証

- PCT_USEDのチェック

- 索引の削除および再作成(または結合)

索引の領域使用がその平均を下回っているときは、索引を削除してから再作成または結合することによって、索引の領域を圧縮できます。

関連項目:
「表、索引およびクラスタの分析」

索引の削除

索引を削除するには、その索引が自分のスキーマに含まれているか、またはDROP ANY INDEXシステム権限を持っている必要があります。

索引を削除するのは、次のような場合です。

- 索引が不要になった場合。

- 対応する表に対して発行した問合せで、索引が予想されたパフォーマンスの改善を達成していない場合。たとえば、表が非常に小さい、または表には多くの行があるものの、索引エントリが非常に少ないなどがこれに該当します。

- アプリケーションに索引を使用するデータ問合せが含まれない場合。

- 索引が無効になり、再作成する前に削除する必要がある場合。

- 索引がかなり断片化し、再作成する前に削除する必要がある場合。

索引が削除されると、その索引のセグメントのエクステントはすべて、索引を含んでいる表領域に戻され、表領域内の他のオブジェクトで利用できます。

索引を削除する方法は、索引の作成方法、つまりCREATE INDEX文によって索引を明示的に作成したか、または表にキー制約を定義することによって索引を暗黙的に作成したかによって異なります。CREATE INDEX文を使用して明示的に作成した索引は、DROP INDEX文で削除できます。次の文は、emp_ename索引を削除します。

DROP INDEX emp_ename;

使用可能になっているUNIQUEキー制約やPRIMARY KEY制約に対応付けられた索引のみを削除することはできません。制約に対応付けられた索引を削除するには、制約自体を使用禁止にするかまたは削除します。

注意:
表を削除すると、対応する索引はすべて自動的に削除されます。

関連項目:

- DROP INDEX文の構文と制限事項については、『Oracle Database SQL言語リファレンス』を参照してください。

- 「整合性制約の管理」

- 索引の削除にかわる方法については、「索引の不可視化」を参照してください。

索引のデータ・ディクショナリ・ビュー

次のビューには、索引に関する情報が表示されます。

ビュー

説明

DBA_INDEXES
ALL_INDEXES

USER_INDEXES

DBAビューには、データベース内にあるすべての表の索引が表示されます。ALLビューには、ユーザーがアクセス可能なすべての表の索引が表示されます。USERビューは、ユーザーが所有する索引のみに制限されます。これらのビューの一部の列には、DBMS_STATSパッケージまたはANALYZE文によって生成される統計が含まれます。

DBA_IND_COLUMNS
ALL_IND_COLUMNS

USER_IND_COLUMNS

これらのビューには、表の索引の列が表示されます。これらのビューの一部の列には、DBMS_STATSパッケージまたはANALYZE文によって生成される統計が含まれます。

DBA_IND_EXPRESSIONS
ALL_IND_EXPRESSIONS

USER_IND_EXPRESSIONS

これらのビューには、表のファンクション索引の式が表示されます。

DBA_IND_PARTITIONS
ALL_IND_PARTITIONS

USER_IND_PARTITIONS

これらのビューには、各索引パーティションのパーティションレベルのパーティション化情報、パーティションの記憶域パラメータ、DBMS_STATSパッケージよって生成された様々なパーティション統計情報が表示されます。

DBA_IND_STATISTICS
ALL_IND_STATISTICS

USER_IND_STATISTICS

これらのビューには、索引のオプティマイザ統計が含まれています。

INDEX_STATS

最後に発行されたANALYZE INDEX...VALIDATE STRUCTURE文の情報が格納されています。

INDEX_HISTOGRAM

最後に発行されたANALYZE INDEX...VALIDATE STRUCTURE文の情報が格納されています。

V$OBJECT_USAGE

ALTER INDEX...MONITORING USAGE機能で生成された索引使用状況の情報が含まれます。

関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

22 クラスタの管理

この章の内容は、次のとおりです。

- クラスタの概要

- クラスタを管理するためのガイドライン

- クラスタの作成

- クラスタの変更

- クラスタの削除

- クラスタのデータ・ディクショナリ・ビュー

クラスタの概要

クラスタは、表データを格納するために選択可能なオプションの方法を提供します。クラスタは、同じデータ・ブロックを共有する表のグループで構成されています。表をグループ化する理由は、各表が共通の列を共有しており、一緒に使用されるケースが多いためです。たとえば、emp表とdept表がdeptno列を共有しているとします。emp表およびdept表をクラスタ化する場合(図22-1を参照)、Oracle Databaseでは、emp表およびdept表の各部門の行はすべて、物理的に同じデータ・ブロックに格納されます。

クラスタは、異なる表の関連する行を同じデータ・ブロックに格納します。そのため、クラスタを正しく使用することには、主に次のような利点があります。

- クラスタ化表の結合によって、ディスクI/Oが減少し、アクセス時間が改善されます。

- クラスタ・キーは、クラスタ化表が共有する列または列のグループです。最初にクラスタを作成するときに、クラスタ・キー列を指定します。その後、そのクラスタに追加する表を作成するたびに同じ列を指定します。各クラスタ・キー値は、その値が含まれている異なる表行数に関係なく、クラスタとクラスタ索引のそれぞれに1度しか格納されません。
したがって、関連する表と索引データをクラスタに格納する方が、クラスタ化されていない表形式の場合よりも、必要となる記憶域が削減される場合があります。たとえば、図22-1では、emp表とdept表の両方にある同じ値を含んでいる多数の行に対して、各クラスタ・キー(各deptno)が1回しか格納されていないことに注意してください。

クラスタを作成した後、クラスタ内に表を作成できます。ただし、クラスタ化表に行を挿入する前に、クラスタ索引を作成しておく必要があります。クラスタを使用しても、クラスタ化表での索引の追加作成に影響はなく、通常どおり作成および削除できます。

別々にアクセスされることの多い表には、クラスタを使用しないでください。

図22-1 クラスタ化表データ

関連項目:

- もう1つのタイプのクラスタ(ハッシュ・クラスタ)の詳細は、第23章「ハッシュ・クラスタの管理」を参照してください。

- この章のタスクを実行する前に、第19章「スキーマ・オブジェクトの領域の管理」を一読されることをお薦めします。

クラスタを管理するためのガイドライン

次の項では、クラスタを管理する際に考慮すべきガイドラインについて説明します。この項の内容は、次のとおりです。

- クラスタに適した表の選択

- クラスタ・キーに適した列の選択

- 平均クラスタ・キーとその対応行が必要とする領域の指定

- 各クラスタとクラスタ索引の行の位置の指定

- クラスタ・サイズの見積りと記憶域パラメータの設定

関連項目:

- クラスタの詳細は、『Oracle Database概要』を参照してください。

- どのようなときにクラスタを使用するかについてのガイドラインは、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

クラスタに適した表の選択

次のような条件が成り立つ場合は、表にクラスタを使用します。

- 表が主に問合せに使用される場合、つまり、主に挿入または更新に使用されない場合。

- 複数の表のレコードを頻繁に問い合せたり、結合する場合。

クラスタ・キーに適した列の選択

クラスタ・キー列の選択には注意が必要です。表を結合する問合せで複数列を使用する場合、クラスタ・キーはコンポジット・キーにします。一般に、適切なクラスタ索引を表す特性は、適切な索引を表す特性と同じです。適切な索引を表す特性の詳細は、「索引を管理するためのガイドライン」を参照してください。

適切なクラスタ・キーの条件は、1つのキー値に対応している行のグループで1つのデータ・ブロックがほぼ一杯になるような、一意の値を持つことです。クラスタ・キー値ごとの行が少なすぎると、領域を浪費し、結果的にパフォーマンスが低下します。共通の値を共有する行がわずかしかないクラスタ・キーは、クラスタを作成するときにSIZEに小さい値を指定しないかぎり、ブロック内の領域を浪費する可能性があります(「平均クラスタ・キーとその対応行が必要とする領域の指定」を参照してください)。

クラスタ・キー値ごとの行が多すぎると、そのキーを持つ行を見つけるために余分な検索が起こる可能性があります。クラスタ・キーの値があまりにも一般的な場合(たとえば、maleとfemaleといった性別など)は、過度の検索が発生し、クラスタ化していない場合よりパフォーマンスが低下するおそれがあります。

クラスタ索引は一意にできません。また、LONG型として定義されている列を含むことはできません。

平均クラスタ・キーとその対応行が必要とする領域の指定

CREATE CLUSTER文には、平均クラスタ・キーとその対応行が必要とするバイト数の見積りであるオプション句SIZEがあります。SIZEパラメータは、次のタスクを実行する際にデータベースによって使用されます。

- クラスタ化したデータ・ブロック内に収めることのできるクラスタ・キー(および対応する行)の数を見積る場合。

- クラスタ化したデータ・ブロックに配置するクラスタ・キーの数を制限する場合。これにより、クラスタ内のキーの格納効率が最大になります。

SIZEは、クラスタ・キーが使用できる領域を制限しません。たとえば、2つのクラスタ・キーが1つのデータ・ブロックに収まるようにSIZEが設定された場合、どちらのクラスタ・キーでも、その利用可能なデータ・ブロック領域をいくらでも使用できます。

デフォルトでは、データベースは1つのクラスタ・キーとそれに対応する行をそのクラスタのデータ・セグメントの1データ・ブロックに格納します。ブロック・サイズはオペレーティング・システムによって異なることがありますが、クラスタ化表が異なるシステム上にある他のデータベースにインポートされるときにも、ブロック当たり1つのキーというルールは守られます。

クラスタ・キー値に対応するすべての行を1つのブロック内に収めることができない場合は、ブロックをまとめて連鎖することにより、特定のキーを持つすべての値へのアクセスの高速化が図られます。クラスタ索引は、クラスタ・キー値と対応する行をそれぞれに含むブロックの連鎖の始点を示します。複数のキーが1つのブロックに収まるようなクラスタのSIZEである場合、ブロックは複数の連鎖に所属することがあります。

各クラスタとクラスタ索引の行の位置の指定

適切な権限と表領域割当て制限を持つユーザーであれば、現在オンライン状態の表領域内に新しいクラスタおよび関連するクラスタ索引を作成できます。新しいクラスタまたは索引を格納する表領域を識別するには、CREATE CLUSTER/INDEX文に必ずTABLESPACE句を指定します。

クラスタとそのクラスタ索引は、異なる表領域内に作成できます。実際、クラスタとその索引を、それぞれ異なる記憶デバイス上に格納された異なる表領域内に作成すると、ディスク競合を最小限に抑えて、表データと索引データを同時に検索できます。

クラスタ・サイズの見積りと記憶域パラメータの設定

クラスタを作成する前にクラスタ・サイズを見積る利点は、次のとおりです。

- クラスタの見積りサイズの合計と、索引およびREDOログ・ファイルの見積りを使用して、作成するデータベースを格納するために必要なディスク容量を決定できます。この見積りを利用して適切なハードウェアを購入できます。

- 個々のクラスタの見積りサイズを使用することで、クラスタが使用するディスク領域をより適切に管理できます。クラスタを作成するときに、適切な記憶域パラメータを設定し、そのクラスタを使用するアプリケーションのI/Oパフォーマンスを改善できます。

表をクラスタに配置する個別のCREATE文またはALTER文ではなく、CREATE CLUSTER句またはALTER CLUSTER文のSTORAGE句を使用してクラスタのデータ・セグメントの記憶域パラメータを設定します。クラスタ化された表の作成時または変更時に指定した記憶域パラメータは無視されます。クラスタに設定された記憶域パラメータは、表の記憶域パラメータを上書きします。

クラスタの作成

自分のスキーマにクラスタを作成するには、CREATE CLUSTERシステム権限とそのクラスタを格納する表領域に対する割当て制限を持っているか、またはUNLIMITED TABLESPACEシステム権限を持っている必要があります。

別のユーザーのスキーマにクラスタを作成するには、CREATE ANY CLUSTERシステム権限が必要です。さらに、所有者はそのクラスタを格納する表領域に対する割当て制限を持っているか、またはUNLIMITED TABLESPACEシステム権限を持っている必要があります。

クラスタを作成するには、CREATE CLUSTER文を使用します。次の文は、deptno列によってクラスタ化された、emp表とdept表を格納するクラスタemp_deptを作成します。

CREATE CLUSTER emp_dept (deptno NUMBER(3))
SIZE 600
TABLESPACE users
STORAGE (INITIAL 200K
NEXT 300K
MINEXTENTS 2
PCTINCREASE 33);

この例のようにINDEXキーワードを指定しない場合は、デフォルトで索引クラスタが作成されます。また、ハッシュ・パラメータ(HASHKEYS、HASH ISまたはSINGLE TABLE HASHKEYS)を指定すると、ハッシュ・クラスタを作成できます。ハッシュ・クラスタについては、第23章「ハッシュ・クラスタの管理」を参照してください。

クラスタ化表の作成

クラスタに表を作成するには、CREATE TABLEシステム権限またはCREATE ANY TABLEシステム権限のどちらかが必要です。なお、クラスタ内に表を作成するために、表領域割当て制限またはUNLIMITED TABLESPACEシステム権限は必要ありません。

クラスタに表を作成するには、CLUSTER句を指定したCREATE TABLE文を使用します。次の文を使用すると、emp_deptクラスタ内にemp表とdept表を作成できます。

CREATE TABLE emp (
empno NUMBER(5) PRIMARY KEY,
ename VARCHAR2(15) NOT NULL,
. . .
deptno NUMBER(3) REFERENCES dept)
CLUSTER emp_dept (deptno);

CREATE TABLE dept (
deptno NUMBER(3) PRIMARY KEY, . . . )
CLUSTER emp_dept (deptno);

注意:
クラスタ化表のスキーマは、CREATE TABLE文で指定できます。クラスタ化表は、そのクラスタを含むスキーマとは異なるスキーマに配置できます。また、列名は一致しなくてもかまいませんが、その構造は同じである必要があります。

関連項目:
クラスタ表を作成するCREATE TABLE文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

クラスタ索引の作成

クラスタ索引を作成するには、次の条件のいずれかが成り立つ必要があります。

- スキーマにクラスタが含まれている。

- CREATE ANY INDEXシステム権限を持っている。

どちらの場合も、クラスタ索引を格納する表領域に対する割当て制限またはUNLIMITED TABLESPACEシステム権限が必要です。

クラスタ索引は、クラスタ化表に行を挿入する前に作成する必要があります。次の文は、emp_deptクラスタに対するクラスタ索引を作成します。

CREATE INDEX emp_dept_index
ON CLUSTER emp_dept
TABLESPACE users
STORAGE (INITIAL 50K
NEXT 50K
MINEXTENTS 2
MAXEXTENTS 10
PCTINCREASE 33);

クラスタ索引句(ON CLUSTER)では、クラスタ索引を作成するクラスタemp_deptを識別します。この文では、クラスタとクラスタ索引の記憶域設定も明示的に指定しています。

関連項目:
クラスタ索引を作成するCREATE INDEX文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

クラスタの変更

クラスタを変更するには、そのクラスタが自分のスキーマに含まれているか、またはALTER ANY CLUSTERシステム権限を持っている必要があります。既存のクラスタを変更することにより、次の設定を変更できます。

- 物理属性(INITRANSおよび記憶域特性)

- クラスタ・キー値のすべての行を格納するために必要な平均使用可能空き領域(SIZE)

- デフォルトの並列度

また、クラスタに新しいエクステントを明示的に割り当てたり、クラスタの最後にある未使用のエクステントの割当てを解除できます。データベースは、必要に応じてクラスタのデータ・セグメントに追加のエクステントを動的に割り当てます。ただし、状況によっては、クラスタに追加のエクステントを明示的に割り当てることもできます。たとえば、Real Application Clustersを使用している場合、クラスタのエクステントを特定のインスタンスに明示的に割り当てることができます。クラスタに新しいエクステントを割り当てるには、ALLOCATE EXTENT句を指定したALTER CLUSTER文を使用します。

クラスタ・サイズ・パラメータ(SIZE)を変更すると、そのクラスタにすでに割り当てられているブロックと今後割り当てられるブロックを含め、そのクラスタが使用するすべてのデータ・ブロックに対して新しい設定が適用されます。すでに表に割り当てられているブロックは、即時ではなく、必要なときに再編成されます。

クラスタのトランザクション・エントリ設定INITRANSを変更すると、INITRANSの新しい設定は、その後クラスタに割り当てられるブロックにのみ適用されます。

記憶域パラメータINITIALとMINEXTENTSは変更できません。他の記憶域パラメータの新しい設定はすべて、その後にクラスタに割り当てられるエクステントにのみ影響します。

クラスタを変更するには、ALTER CLUSTER文を使用します。

関連項目:
ALTER CLUSTER文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

クラスタ化表の変更

クラスタ化表はALTER TABLE文を使用して変更できます。ただし、ALTER TABLE文でクラスタ化表に対してデータ・ブロック領域パラメータ、トランザクション・エントリ・パラメータまたは記憶域パラメータを設定すると、エラー・メッセージ(ORA-01771、クラスタ表に対するオプションが無効です。)が生成されます。データベースは、クラスタのパラメータをすべてのクラスタ化表に対して使用します。そのため、ALTER TABLE文は、クラスタ化表の列の追加または変更、クラスタ・キー以外の列の削除、整合性制約またはトリガーの追加、削除、有効化、無効化のみに使用できます。表の変更の詳細は、「表の変更」を参照してください。

関連項目:
ALTER TABLE文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

クラスタ索引の変更

クラスタ索引は、他の索引と同じように変更できます。「索引の変更」を参照してください。

注意:
クラスタ索引のサイズを見積るときには、索引が実際の行ではなく各クラスタ・キーに付いていることに注意してください。したがって、各キーは索引内に1度しか現れません。

クラスタの削除

クラスタ内の表が不要になった場合は、そのクラスタを削除できます。クラスタを削除すると、そのクラスタ内の表および対応するクラスタ索引も削除されます。クラスタのデータ・セグメントとクラスタ索引の索引セグメントの両方に属するすべてのエクステントは、それらを含んでいる表領域に戻され、その表領域内の他のセグメントで使用可能になります。

表を含まないクラスタとそのクラスタ索引を削除するには、DROP CLUSTER文を使用します。たとえば、次の文は空のクラスタemp_deptを削除します。

DROP CLUSTER emp_dept;

クラスタに1つ以上のクラスタ化表が含まれており、その表も同様に削除する場合は、次のように、DROP CLUSTER文にINCLUDING TABLES句を追加します。

DROP CLUSTER emp_dept INCLUDING TABLES;

INCLUDING TABLES句を指定していない場合に、クラスタに表が含まれていると、エラーが返されます。

クラスタ内の1つ以上の表が、クラスタ外の表のFOREIGN KEY制約によって参照される主キーまたは一意のキーを含んでいる場合、依存するFOREIGN KEY制約も削除しないと、そのクラスタを削除できません。これは、次の例に示すように、DROP CLUSTER文のCASCADE CONSTRAINTS句を使用すると容易に実行できます。

DROP CLUSTER emp_dept INCLUDING TABLES CASCADE CONSTRAINTS;

制約が存在している場合に、CASCADE CONSTRAINTS句を使用しないと、データベースはエラーを返します。

関連項目:
DROP CLUSTER文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

クラスタ化表の削除

クラスタを削除するには、そのクラスタが自分のスキーマに含まれているか、またはDROP ANY CLUSTERシステム権限を持っている必要があります。クラスタ化表をそのクラスタの所有者が所有していなくても、その表を含むクラスタを削除するために特別な権限は必要ありません。

クラスタ化表は、そのクラスタ、他のクラスタ化表またはクラスタ索引に影響を及ぼすことなく、個別に削除できます。クラスタ化表は、非クラスタ化表を削除する場合と同じように、DROP TABLE文を使用して削除します。「表の列の削除」を参照してください。

注意:
単一の表をクラスタから削除するときは、表の各行が個別に削除されます。クラスタ全体を最も効率よく削除するには、INCLUDING TABLES句を指定したDROP CLUSTER文を使用して、そのクラスタを表も含めて削除します。クラスタの残りの部分をそのままにしておく場合のみ、(DROP TABLE文を使用して)クラスタから表を個別に削除してください。

クラスタ索引の削除

クラスタ索引は、そのクラスタまたはクラスタ化表に影響を及ぼすことなく削除できます。ただし、クラスタ索引がなければクラスタ化表は使用できないため、クラスタへのアクセスを許可するにはクラスタ索引を再作成する必要があります。クラスタ索引は、断片化したクラスタ索引を再作成する過程で削除される場合があります。

注意:
ハッシュ・クラスタ索引は削除できません。

関連項目:
「索引の削除」

クラスタのデータ・ディクショナリ・ビュー

次のビューには、クラスタに関する情報が表示されます。

ビュー

説明

DBA_CLUSTERS
ALL_CLUSTERS

USER_CLUSTERS

DBAビューには、データベース内のすべてのクラスタが表示されます。ALLビューには、ユーザーがアクセス可能なすべてのクラスタが表示されます。USERビューは、ユーザーが所有するクラスタのみに制限されます。これらのビューの一部の列には、DBMS_STATSパッケージまたはANALYZE文によって生成される統計が含まれます。

DBA_CLU_COLUMNS
USER_CLU_COLUMNS

これらのビューでは、表の列とクラスタの列がマップされています。

関連項目:
これらのビューの完全な説明は、『Oracle Databaseリファレンス』を参照してください。

23 ハッシュ・クラスタの管理

この章の内容は、次のとおりです。

- ハッシュ・クラスタの概要

- ハッシュ・クラスタを使用する場合

- ハッシュ・クラスタの作成

- ハッシュ・クラスタの変更

- ハッシュ・クラスタの削除

- ハッシュ・クラスタのデータ・ディクショナリ・ビュー

ハッシュ・クラスタの概要

ハッシュ・クラスタに表を格納することは、データ検索のパフォーマンスを改善するための1つの選択肢です。ハッシュ・クラスタは、索引付きの非クラスタ化表または索引クラスタの代替手段を提供します。索引付きの表または索引クラスタでは、Oracle Databaseは、表内の行の位置を特定するために、別個の索引に格納しているキー値を使用します。ハッシングを使用するには、ハッシュ・クラスタを作成し、そこに表をロードします。表の行は物理的にはハッシュ・クラスタに格納され、ハッシュ関数の結果に従って検索されます。

Oracle Databaseはハッシュ関数を使用して、特定のクラスタ・キー値に基づく、ハッシュ値と呼ばれる数値の分布を生成します。ハッシュ・クラスタのキーは、索引クラスタのキーと同じように単一列キーでもコンポジット・キー(複数列キー)でもかまいません。ハッシュ・クラスタ内で行を検索または格納する場合、データベースは行のクラスタ・キー値にハッシュ関数を適用します。結果として生成されるハッシュ値はクラスタ内のデータ・ブロックに対応しており、データベースは、発行された文のかわりにそのデータ・ブロックに対して読取りまたは書込みを行います。

索引付きの表または索引クラスタ内の行を検索または格納するためには、少なくとも2回(通常はそれ以上)のI/Oを実行する必要があります。

- 1回以上のI/Oによる、索引内でのキー値の検索または格納

- 別のI/Oによる、表またはクラスタ内での行の読取りまたは書込み

一方、ハッシュ・クラスタでは、ハッシュ関数を使用して行の位置が特定されるので、I/Oは必要ありません。結果として、ハッシュ・クラスタ内の行の読込みや書込みに必要とされるのは最小限のI/O操作のみになります。

関連項目:
この章のタスクを実行する前に、第19章「スキーマ・オブジェクトの領域の管理」を一読されることをお薦めします。

ハッシュ・クラスタを使用する場合

ここでは、ハッシングが最も有効な場合と有効でない場合を対比することによって、ハッシュ・クラスタを使用すべき状況を判断する際に役立つ情報を提供します。ハッシングではなく索引を使用する場合は、表を個別に格納するのか、またはクラスタの一部として格納するのかを考慮してください。

注意:
ハッシングを使用する場合でも、クラスタ・キーを含む表のどの列にも異なる索引を設定できます。

ハッシングが有効な状況

ハッシングは、次のような状況で有効です。

- ほとんどの問合せが次のようなクラスタ・キーとの等式を含んでいる場合。

SELECT ... WHERE cluster_key = ...;

このような場合、等価条件内のクラスタ・キーがハッシュされ、対応するハッシュ・キーが通常1回の読込みで検索されます。それに対して、索引付きの表では、最初にキー値を索引内で検索する必要があり(通常複数回の読込み)、その後で行が表から読み込まれます(別の読込み)。

- ハッシュ・クラスタ内の表のサイズが最初から固定されていて、行数とそのクラスタ内の表が必要とする領域を決定できる場合。ハッシュ・クラスタ内の表でそのクラスタの初期割当てより多くの領域が必要な場合、オーバーフロー・ブロックが必要となるためにパフォーマンスがかなり低下するおそれがあります。

ハッシングが不利な状況

ハッシングは次のような状況では有効ではありません。

- ほとんどの問合せがクラスタ・キー値全体にわたって行を検索する場合。たとえば、全表スキャンや次のような問合せでは、ハッシュ関数は特定のハッシュ・キーの位置を決定するために使用できません。そのかわりに、全表スキャンと同等の機能を実行して問合せの行をフェッチする必要があります。

SELECT . . . WHERE cluster_key < . . . ;

索引では、キー値はその索引内で順序付けられており、問合せのWHERE句を満たすクラスタ・キー値を、比較的少ないI/Oで見つけることができます。

- 表が固定でなく、継続的に拡大する場合。表が無制限に拡大する場合、表(そのクラスタ)の存続期間にわたって必要な領域を事前に定義することはできません。

- アプリケーションが頻繁に表の全表スキャンを実行し、その表内でデータが散在している場合。この状況でハッシングを使用すると、全表スキャンの処理時間が長くなります。

- 最終的にハッシュ・クラスタが必要とする領域を事前に割り当てることができない場合。

ハッシュ・クラスタの作成

ハッシュ・クラスタを作成するには、HASHKEYS句を指定したCREATE CLUSTER文を使用します。次の文は、trialno列(クラスタ・キー)でクラスタ化されたクラスタをtrial_clusterという名前で作成します。

CREATE CLUSTER trial_cluster ( trialno NUMBER(5,0) )
TABLESPACE users
STORAGE ( INITIAL 250K
NEXT 50K
MINEXTENTS 1
MAXEXTENTS 3
PCTINCREASE 0 )
HASH IS trialno
HASHKEYS 150;

次の文は、trial_clusterハッシュ・クラスタにtrial表を作成します。

CREATE TABLE trial (
trialno NUMBER(5,0) PRIMARY KEY,
... )
CLUSTER trial_cluster (trialno);

索引クラスタの場合と同様に、ハッシュ・クラスタのキーは、単一列でもコンポジット・キー(複数列のキー)でもかまいません。前述の例では、trialno列がキーとなっています。

HASHKEYS値(この例では150)は、ハッシュ関数が生成できる一意のハッシュ値の数を指定し、制限します。指定した値は最も近い素数に丸められます。

HASH IS句を指定しない場合は、内部ハッシュ関数が使用されます。すでにクラスタ・キーがその範囲に均一に分布する一意識別子の場合は、内部ハッシュ関数を無視し、前述の例のようにクラスタ・キーをハッシュ値として指定できます。また、HASH IS句を使用して、ユーザー定義のハッシュ関数を指定することもできます。

ハッシュ・クラスタのクラスタ索引は作成できませんが、ハッシュ・クラスタ・キーに索引を作成する必要はありません。

次の項では、ハッシュ・クラスタ固有のCREATE CLUSTER文のパラメータの設定とそのガイドラインについて説明します。

- ソートされたハッシュ・クラスタの作成

- 単一表ハッシュ・クラスタの作成

- ハッシュ・クラスタ内の領域使用の制御

- ハッシュ・クラスタに必要なサイズの見積り

関連項目:
クラスタ内に表を作成する方法、索引とハッシュ・クラスタに共通するCREATE CLUSTER文のパラメータ設定のガイドライン、およびクラスタを作成するために必要な権限の追加情報は、第22章「クラスタの管理」を参照してください。

ソートされたハッシュ・クラスタの作成

ソートされたハッシュ・クラスタには、ハッシュ関数の各値に対応する行が、ソートされた順序で効率よくデータベースから返すことができるような方法で格納されます。常にソート順にデータを使用するアプリケーションの場合、ソートされたハッシュ・クラスタを使用することによって論理I/Oを最小化でき、これにより、より迅速にデータを取得できます。

ある電話会社では、1つの交換機を介した固定数の発信電話番号について、詳細な通話記録を保存するとします。各発信電話番号から、無制限の通話件数が発生する可能性があります。

アプリケーションは、通話が発信されると通話記録を保存します。各通話には、タイムスタンプによって識別される詳細な通話記録があります。たとえば、通話記録がタイムスタンプ0とともに保存され、続いて通話記録がタイムスタンプ1とともに格納されるというように保存されます。

各発信電話番号の請求書が生成されるときには、先入れ先出し(FIFO)で処理されます。次の表に、3つの発信電話番号について詳細な例を示します。

telephone_number

call_timestamp

6505551212

0, 1, 2, 3, 4, ...

6505551213

0, 1, 2, 3, 4, ...

6505551214

0, 1, 2, 3, 4, ...

次のSQL文では、telephone_number列がハッシュ・キーです。ハッシュ・クラスタは、call_timestampおよびcall_duration列でソートされます。この例では表定義のクラスタ化とソート用の列にクラスタ定義と同じ名前を使用していますが、これは必須ではありません。ハッシュ・キーの数は、10桁の電話番号に基づいています。

CREATE CLUSTER call_detail_cluster (
telephone_number NUMBER,
call_timestamp   NUMBER SORT,
call_duration    NUMBER SORT )
HASHKEYS 10000
HASH IS telephone_number
SIZE 256;

CREATE TABLE call_detail (
telephone_number     NUMBER,
call_timestamp       NUMBER   SORT,
call_duration        NUMBER   SORT,
other_info           VARCHAR2(30) )
CLUSTER call_detail_cluster (
telephone_number, call_timestamp, call_duration );

例23-1に示すように、call_detail表に行をFIFOで供給するとします。

例23-1 連続した順序で挿入されるデータ

INSERT INTO call_detail VALUES (6505551212, 0, 9, 'misc info');
INSERT INTO call_detail VALUES (6505551212, 1, 17, 'misc info');
INSERT INTO call_detail VALUES (6505551212, 2, 5, 'misc info');
INSERT INTO call_detail VALUES (6505551212, 3, 90, 'misc info');
INSERT INTO call_detail VALUES (6505551213, 0, 35, 'misc info');
INSERT INTO call_detail VALUES (6505551213, 1, 6, 'misc info');
INSERT INTO call_detail VALUES (6505551213, 2, 4, 'misc info');
INSERT INTO call_detail VALUES (6505551213, 3, 4, 'misc info');
INSERT INTO call_detail VALUES (6505551214, 0, 15, 'misc info');
INSERT INTO call_detail VALUES (6505551214, 1, 20, 'misc info');
INSERT INTO call_detail VALUES (6505551214, 2, 1, 'misc info');
INSERT INTO call_detail VALUES (6505551214, 3, 25, 'misc info');
COMMIT;

例23-2では、AUTOTRACEをONに設定し、call_detail表に電話番号6505551212のコール詳細を問い合せています。

例23-2 call_detailの問合せ

SQL> SET AUTOTRACE ON;
SQL> SELECT * FROM call_detail WHERE telephone_number = 6505551212;

TELEPHONE_NUMBER CALL_TIMESTAMP CALL_DURATION OTHER_INFO
---------------- -------------- ------------- ------------------------------
6505551212              0             9 misc info
6505551212              1            17 misc info
6505551212              2             5 misc info
6505551212              3            90 misc info

Execution Plan
----------------------------------------------------------
Plan hash value: 2118876266

----------------------------------------------------------------------
| Id  | Operation         | Name        | Rows  | Bytes | Cost (%CPU)|
----------------------------------------------------------------------
|   0 | SELECT STATEMENT  |             |     1 |    56 |     0   (0)|
|*  1 |  TABLE ACCESS HASH| CALL_DETAIL |     1 |    56 |            |
----------------------------------------------------------------------

例23-2の問合せでは、問合せプランにソートがない場合も、タイムスタンプ順に行が取得されます。

次に、既存の行を削除し、その同じ行を不規則な順序で挿入するとします。

DELETE FROM call_detail;
INSERT INTO call_detail VALUES (6505551213, 3, 4, 'misc info');
INSERT INTO call_detail VALUES (6505551214, 0, 15, 'misc info');
INSERT INTO call_detail VALUES (6505551212, 0, 9, 'misc info');
INSERT INTO call_detail VALUES (6505551214, 1, 20, 'misc info');
INSERT INTO call_detail VALUES (6505551214, 2, 1, 'misc info');
INSERT INTO call_detail VALUES (6505551213, 1, 6, 'misc info');
INSERT INTO call_detail VALUES (6505551213, 2, 4, 'misc info');
INSERT INTO call_detail VALUES (6505551214, 3, 25, 'misc info');
INSERT INTO call_detail VALUES (6505551212, 1, 17, 'misc info');
INSERT INTO call_detail VALUES (6505551212, 2, 5, 'misc info');
INSERT INTO call_detail VALUES (6505551212, 3, 90, 'misc info');
INSERT INTO call_detail VALUES (6505551213, 0, 35, 'misc info');
COMMIT;

call_detailに同じ問合せを再実行すると、ORDER BY句を指定していない場合でも、データベースから再度行がソート順に取得されます。データベース内部でソートが実行されるため、SORT ORDER BY操作は問合せプランに表示されません。

ここで、非クラスタ化表call_detail_nonclusteredを作成して、例23-1に示したものと同じ値をロードするとします。データをソート順に取得するには、次のようにORDER BY句を使用する必要があります。

SQL> SELECT * FROM call_detail_nonclustered WHERE telephone_number = 6505551212
2  ORDER BY call_timestamp, call_duration;

TELEPHONE_NUMBER CALL_TIMESTAMP CALL_DURATION OTHER_INFO
---------------- -------------- ------------- ------------------------------
6505551212              0             9 misc info
6505551212              1            17 misc info
6505551212              2             5 misc info
6505551212              3            90 misc info

Execution Plan
----------------------------------------------------------
Plan hash value: 2555750302

----------------------------------------------------------------------------------
|Id| Operation          | Name                     |Rows|Bytes|Cost (%CPU)|Time  |
----------------------------------------------------------------------------------
| 0| SELECT STATEMENT   |                          | 4  | 224 | 4 (25)| 00:00:01 |
| 1|  SORT ORDER BY     |                          | 4  | 224 | 4 (25)| 00:00:01 |
|*2|   TABLE ACCESS FULL| CALL_DETAIL_NONCLUSTERED | 4  | 224 | 3  (0)| 00:00:01 |
----------------------------------------------------------------------------------

前述のプランで示した非クラスタ化の場合、ソートを行うにはクラスタ化の場合よりもコストがかかります。ソートされたハッシュ・クラスタに格納されていない表では、行、バイト、コスト、時間のすべてが大きくなります。

単一表ハッシュ・クラスタの作成

表中の行への高速なアクセスを提供する単一表ハッシュ・クラスタを作成できます。ただし、この表はハッシュ・クラスタ内の唯一の表にする必要があります。ハッシュ・キーとデータ行の間に1対1のマッピングが必要となるためです。次の文は、クラスタ・キーvarietyを持つ単一表ハッシュ・クラスタpeanutを作成します。

CREATE CLUSTER peanut (variety NUMBER)
SIZE 512 SINGLE TABLE HASHKEYS 500;

HASHKEYS値は最も近い素数に丸められるため、このクラスタはそれぞれサイズ512バイトのハッシュ・キー値を最大503個持ちます。SINGLE TABLE句は、ハッシュ・クラスタにのみ有効です。また、必ずHASHKEYSも指定する必要があります。

関連項目:
CREATE CLUSTER文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

ハッシュ・クラスタ内の領域使用の制御

ハッシュ・クラスタを作成するときは、パフォーマンスと使用領域が最適になるように、クラスタ・キーを正しく選択し、HASH IS、SIZEおよびHASHKEYSの各パラメータを設定することが重要です。次に示すガイドラインでは、これらのパラメータを設定する方法について説明します。

キーの選択

正しいクラスタ・キーの選択は、クラスタ化表に対して最もよく発行される問合せのタイプによって決まります。たとえば、ハッシュ・クラスタ内のemp表について検討します。問合せが従業員番号によって行を頻繁に選択する場合、最適なクラスタ・キーはempno列です。問合せが部門によって行を頻繁に選択する場合、最適なクラスタ・キーはdeptno列です。単一の表を含むハッシュ・クラスタの場合は、通常、含まれる表の主キー全体をクラスタ・キーにします。

ハッシュ・クラスタのキーは、索引クラスタのキーと同じように単一列でもコンポジット・キー(複数列キー)でもかまいません。コンポジット・キーによるハッシュ・クラスタは、データベースの内部ハッシュ関数を使用する必要があります。

HASH ISパラメータの設定

HASH ISパラメータを指定するのは、クラスタ・キーがNUMBERデータ型の単一の列であり、均一に分布した整数を含む場合のみです。この条件を満たしていれば、それぞれの一意のクラスタ・キー値が衝突(同じハッシュ値を持つクラスタ・キーが2つ発生すること)せずに一意のハッシュ値にハッシュするように、クラスタ内に行を分散させることができます。この条件が当てはまらない場合は、この句を指定せずに内部ハッシュ関数を使用してください。

SIZEパラメータの設定

SIZEは、ハッシュ・キーに対応するすべての行を保持するために必要な領域の平均サイズに設定します。そのため、SIZEを適切に決定するには、格納するデータの特性をよく理解する必要があります。

- ハッシュ・クラスタに含まれている表が1つで、その表の行のハッシュ・キー値が一意(1つの値につき1行)である場合、SIZEはクラスタ内の平均の行サイズに設定できます。

- ハッシュ・クラスタが複数の表を含む場合、SIZEは代表的なハッシュ値に対応するすべての行を保持するために必要な領域の平均サイズに設定できます。

また、SIZEの見積り値を決定した後で、次の点を考慮してください。SIZEの値が小さい場合(データ・ブロックごとに5つ以上のハッシュ・キーを割り当てることができる場合)は、その値をCREATE CLUSTER文のSIZEに使用できます。しかし、SIZEの値が大きい場合(データ・ブロックごとに割当て可能なハッシュ・キーが4つ以下の場合)は、衝突の発生頻度を予測し、データ検索パフォーマンスと領域使用効率のどちらを重視するか検討する必要があります。

- ハッシュ・クラスタで内部ハッシュ関数を使用せず(HASH ISを指定した場合)、衝突がわずかであるか、または衝突のないことが予想される場合は、見積り値をそのままSIZEに設定できます。この場合、衝突は発生せず、領域は可能なかぎり効率的に使用されます。

- 挿入時に頻繁な衝突が予想される場合、行を格納するためにオーバーフロー・ブロックが割り当てられる可能性は高くなります。衝突が頻繁に起こる場合にブロックのオーバーフローの可能性を軽減し、最大のパフォーマンスを引き出すには、次のようにSIZEを調整する必要があります。

ブロック当たりの使用可能領域/算出されたSIZE

SIZEの設定

1

SIZE

2

SIZE + 15%

3

SIZE + 12%

4

SIZE + 8%

>4

SIZE

ただし、SIZEの値を過大に見積ると、クラスタ内の未使用領域を増やすことになります。領域効率がデータ検索のパフォーマンスよりも重要な場合は、前述の表で示した調整を無視して、SIZEに元の値を使用してください。

HASHKEYSパラメータの設定

ハッシュ・クラスタ内の行を最大限まで分散させるために、データベースはHASHKEYS値を最も近い素数に丸めます。

ハッシュ・クラスタ内の使用領域の制御

次に示す例では、クラスタ・キーを正しく選択し、HASH IS、SIZEおよびHASHKEYSの各パラメータを設定する方法を示します。すべての例において、データ・ブロック・サイズは2KBで、利用可能なデータ領域(ブロック・サイズからオーバーヘッドを差し引いた領域)の平均は各ブロックの1,950バイトとします。

ハッシュ・クラスタ内の使用領域の制御: 例1

ハッシュ・クラスタにemp表をロードすることになりました。ほとんどの問合せは、従業員番号によって従業員レコードを検索します。emp表の最大行数は常に10,000、平均の行サイズは55バイトと見積られています。

この場合は、empnoをクラスタ・キーにします。この列には一意の整数が格納されているので、内部ハッシュ関数は無視できます。SIZEは平均の行サイズ(55バイト)に設定できます。これにより、各データ・ブロックに34のハッシュ・キーが割り当てられます。HASHKEYSは、表の行数である10,000に設定できます。この値は、10,000より大きい最初の素数である10,007に切り上げられます。

CREATE CLUSTER emp_cluster (empno
NUMBER)
. . .
SIZE 55
HASH IS empno HASHKEYS 10000;

ハッシュ・クラスタ内の使用領域の制御: 例2

前述の例と同様の条件を考えます。ただし、この例では、ほとんどの場合、行が部門番号によって検索されるとします。平均10名の従業員を持つ部門が最大で1,000部門存在します。部門番号は10ずつ増加します(0、10、20、30、...)。

この場合は、deptnoをクラスタ・キーにします。この列には一様に分布する整数が格納されているので、内部ハッシュ関数は無視できます。事前に見積ったSIZE (各部門のすべての行を保持するために必要な領域の平均サイズ)は55 * 10バイト、つまり550バイトです。SIZEにこの値を使用して、各データ・ブロックに3つのハッシュ・キーのみを割り当てることができます。いくらかの衝突が予想される状況で、最大限のデータ検索パフォーマンスが必要な場合、オーバーフロー・ブロックを必要とする衝突を防ぐために、見積りのSIZEを少し変更してください。ここでは、SIZEを12%調整して620バイトにすることにより(「SIZE"SIZEパラメータの設定」を参照)、予想される衝突を考慮した上で行の領域をより多く確保できます。

HASHKEYSは、一意の部門番号の数である1,000に設定できます。この値は、1,000より大きい最初の素数である1,009に切り上げられます。

CREATE CLUSTER emp_cluster (deptno NUMBER)
. . .
SIZE 620
HASH IS deptno HASHKEYS 1000;

ハッシュ・クラスタに必要なサイズの見積り

索引クラスタの場合と同じように、ハッシュ・クラスタ内のデータに必要な記憶域を見積ることは重要です。

Oracle Databaseは、SIZEおよびHASHKEYSの設定に従って、ハッシュ表の格納に十分な領域の初期割当てを保証します。ハッシュ表サイズを考慮せずに記憶域パラメータINITIAL、NEXTおよびMINEXTENTSを設定した場合は、少なくともSIZE*HASHKEYSに達するまで増分(追加の)エクステントが割り当てられます。たとえば、データ・ブロック・サイズが2KB、各ブロックの使用可能なデータ領域(ブロック・サイズからオーバーヘッドを差し引いた領域)が約1,900バイトの場合に、CREATE CLUSTER文でSTORAGEパラメータとHASHパラメータを次のように指定したとします。

STORAGE (INITIAL 100K
NEXT 150K
MINEXTENTS 1
PCTINCREASE 0)
SIZE 1500
HASHKEYS 100

この例では、各データ・ブロックにハッシュ・キーを1つのみ割り当てることができます。そのため、ハッシュ・クラスタが必要とする初期領域は少なくとも200KB(100×2KB)です。しかし、記憶域パラメータの設定にはこの要件が考慮されていません。そのため、100KBの初期のエクステントと150KBの増分のエクステントがハッシュ・クラスタに割り当てられます。

一方、HASHパラメータが次のように指定されたとします。

SIZE 500 HASHKEYS 100

この場合、各データ・ブロックに3つのハッシュ・キーが割り当てられます。そのため、ハッシュ・クラスタが必要とする初期領域は少なくとも68KB(34×2KB)です。記憶域パラメータの初期設定はこの要件を満たしているため、100KBの初期エクステントがハッシュ・クラスタに割り当てられます。

ハッシュ・クラスタの変更

ハッシュ・クラスタは、ALTER CLUSTER文を使用して変更できます。

ALTER CLUSTER emp_dept . . . ;

ハッシュ・クラスタの変更に関係する問題は、「クラスタの変更」で説明されている索引クラスタを変更する場合と同じです。ただし、SIZE、HASHKEYSおよびHASH ISの各パラメータはALTER CLUSTER文に指定できません。これらのパラメータを変更するには、クラスタを再作成して、元のクラスタからデータをコピーする必要があります。

ハッシュ・クラスタの削除

ハッシュ・クラスタは、DROP CLUSTER文を使用して削除できます。

DROP CLUSTER emp_dept;

ハッシュ・クラスタ内の表は、DROP TABLE文を使用して削除されます。ハッシュ・クラスタとハッシュ・クラスタ内の表の削除についての問題は、索引クラスタの場合と同じです。

関連項目:
「クラスタの削除」

ハッシュ・クラスタのデータ・ディクショナリ・ビュー

次のビューには、ハッシュ・クラスタに関する情報が表示されます。

ビュー

説明

DBA_CLUSTERS
ALL_CLUSTERS

USER_CLUSTERS

DBAビューには、データベース内のすべてのクラスタ(ハッシュ・クラスタを含む)が表示されます。ALLビューには、ユーザーがアクセス可能なすべてのクラスタが表示されます。USERビューは、ユーザーが所有するクラスタのみに制限されます。これらのビューの一部の列には、DBMS_STATSパッケージまたはANALYZE文によって生成される統計が含まれます。

DBA_CLU_COLUMNS
USER_CLU_COLUMNS

これらのビューでは、表の列とクラスタの列がマップされています。

DBA_CLUSTER_HASH_EXPRESSIONS
ALL_CLUSTER_HASH_EXPRESSIONS

USER_CLUSTER_HASH_EXPRESSIONS

これらのビューには、ハッシュ・クラスタのハッシュ関数がリストされます。

関連項目:
これらのビューの完全な説明は、『Oracle Databaseリファレンス』を参照してください。

24 ビュー、順序およびシノニムの管理

この章の内容は、次のとおりです。

- ビューの管理

- 順序の管理

- シノニムの管理

- ビュー、順序およびシノニムのデータ・ディクショナリ・ビュー

ビューの管理

ここでは、ビューを管理する方法について説明します。この項の内容は、次のとおりです。

- ビューについて

- ビューの作成

- ビューの置換

- 問合せでのビューの使用

- 結合ビューの更新

- ビューの変更

- ビューの削除

ビューについて

ビューとは、表または表の組合せの論理表現です。本質的には、ビューは格納された問合せです。ビューのデータは、そのビューの基礎となる表から生成されます。この表を実表と呼びます。実表は、実際の表の場合もビュー自体の場合もあります。ビューに対して実行するすべての操作は、実際にはビューの実表に影響します。ビューの使用方法は、表の場合とほぼ同じです。通常の表と同様に、ビューに対する問合せ、更新、挿入および削除ができます。

ビューによって、他の表およびビューに常駐するデータの様々な表現(サブセットまたはスーパーセットなど)が可能です。ビューを使用すると、ユーザーの必要にあわせて調整したデータ表現ができます。

注意:
ビューの1つの特殊なタイプがエディショニング・ビューで、エディションに基づく再定義を使用したオンラインでのアプリケーションのアップグレードをサポートするためにのみ使用されるビューです。ビューの管理に関する項のここからは、エディショニング・ビューを除くすべてのビューについて説明します。エディショニング・ビューおよびエディションに基づく再定義の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

関連項目:
ビューの概要については、『Oracle Database概要』を参照してください。

ビューの作成

ビューを作成するには、次に示す要件を満たす必要があります。

- 自分のスキーマに新しいビューを作成するには、CREATE VIEWシステム権限が必要です。別のユーザーのスキーマ内にビューを作成するには、CREATE ANY VIEWシステム権限が必要です。これらの権限は明示的に取得するか、またはロールを介して取得できます。

- どのスキーマのビューであっても、その所有者は、ビュー定義で参照されるすべてのオブジェクトにアクセスする権限を明示的に付与されている必要があります。所有者がロールを介してこれらの権限を取得することはできません。また、ビューの機能は、ビューの所有者の権限によって決まります。たとえば、ビューの所有者にScottのemp表のINSERT権限しかない場合、emp表に新しい行を挿入するためにはビューを使用できますが、このビューの行を選択(SELECT)、更新(UPDATE)または削除(DELETE)するためには使用できません。

- ビューの所有者がビューにアクセスする権限を他のユーザーに付与しようとする場合は、ベース・オブジェクトに対するGRANT OPTION付きのオブジェクト権限、またはADMIN OPTION付きのシステム権限が必要です。

ビューを作成するには、CREATE VIEW文を使用します。ビューはそれぞれ、表、マテリアライズド・ビューまたは他のビューを参照する問合せによって定義されます。すべての副問合せと同様に、ビューを定義する問合せには、FOR UPDATE句を指定できません。

次の文は、emp表のデータのサブセットに対してビューを作成します。

CREATE VIEW sales_staff AS
SELECT empno, ename, deptno
FROM emp
WHERE deptno = 10
WITH CHECK OPTION CONSTRAINT sales_staff_cnst;

sales_staffビューを定義する問合せは、部門番号10の行のみを参照します。また、CHECK OPTIONは、そのビューが選択できない行に対してINSERT文およびUPDATE文を発行できないという制約(sales_staff_cnst)付きでビューを作成します。たとえば、次のINSERT文では、sales_staffビュー(部門番号が10の行のみを含む)を使用してemp表に行が正常に挿入されます。

INSERT INTO sales_staff VALUES (7584, 'OSTER', 10);

しかし、次のINSERT文は、sales_staffビューを使用しても選択できない部門番号30の行を挿入しようとしているため、エラーが返されます。

INSERT INTO sales_staff VALUES (7591, 'WILLIAMS', 30);

WITH READ ONLY句を指定してビューを作成できますが、これにより、このビューからは、実表の更新、挿入または削除ができなくなります。WITH句を指定しない場合、一部の制限を伴いますが、ビューは従来どおり更新可能です。

関連項目:
CREATE VIEW文の構文とセマンティクスの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

結合ビュー

FROM句で複数の実表またはビューを指定するビューを作成することもできます。この種のビューを結合ビューと呼びます。次の文は、emp表とdept表のデータを結合するdivision1_staffビューを作成します。

CREATE VIEW division1_staff AS
SELECT ename, empno, job, dname
FROM emp, dept
WHERE emp.deptno IN (10, 30)
AND emp.deptno = dept.deptno;

更新可能な結合ビューは、UPDATE、INSERTおよびDELETE操作が可能な結合ビューです。詳細は、「結合ビューの更新」を参照してください。

ビュー作成時の問合せ定義の展開

ビューが作成されるときに、Oracle Databaseは最上位のビュー問合せのワイルドカード(*)を列リストに展開します。結果の問合せデータ・ディクショナリに格納され、副問合せはそのまま残されます。展開された列リスト中の列名は引用符で囲まれており、これは、ベース・オブジェクトの列がもともと引用符付きで入力された可能性があり、問合せの構文を正しいものにするためには引用符が必要であることを示しています。

たとえば、deptビューが次のように作成される場合を想定します。

CREATE VIEW dept AS SELECT * FROM scott.dept;

データベースは、deptビューを定義している問合せを次のように格納します。

SELECT "DEPTNO", "DNAME", "LOC" FROM scott.dept;

エラー付きで作成されたビューでは、ワイルドカードは展開されません。エラーなしでビューがコンパイルされると、定義された問合せのワイルドカードが展開されます。

エラー付きビューの作成

CREATE VIEW文に構文エラーがない場合は、そのビューを定義している問合せを実行できなくても、データベースはビューを作成できます。この場合、ビューは、エラー付きで作成されたとみなされます。たとえば、存在しない表や既存の表の無効な列を参照するビューを作成するとき、またはビューの所有者が必要な権限を持っていないときでも、ビューを作成し、データ・ディクショナリに登録できます。ただし、そのビューは使用できません。

エラー付きのビューを作成するには、CREATE VIEW文のFORCE句を指定する必要があります。

CREATE FORCE VIEW AS ...;

デフォルトでは、エラー付きのビューはINVALIDとして作成されます。このようなビューを作成しようとすると、ビューがエラー付きで作成されたことを示すメッセージが返されます。状況が変化して無効なビューの問合せが実行可能になると、ビューは再コンパイルされ、有効(使用可能)になります。条件の変更とビューに及ぼす影響の詳細は、「オブジェクト依存性の管理」を参照してください。

ビューの置換

ビューを置換するには、ビューの削除および作成に必要なすべての権限が必要です。ビューの定義を変更する場合は、そのビューを置換する必要があり、ビューの定義の変更にALTER VIEW文は使用できません。次の方法でビューを置換できます。

- ビューを削除してから再作成します。

注意:
ビューを削除するときに、ロールおよびユーザーに付与された対応するオブジェクト権限はすべて取り消されます。ビューを再作成してから、再度権限を付与してください。

- OR REPLACE句を含むCREATE VIEW文によって、ビューを再定義します。OR REPLACE句は、ビューの現行の定義を置換し、現行のセキュリティ認可を保存します。たとえば、前述のように、sales_staffビューを作成し、いくつかのオブジェクト権限をロールと他のユーザーに付与した場合を想定します。ただし、ここではsales_staffビューを再定義して、WHERE句に指定されている部門番号を変更するものとします。この場合は、次の文によって、sales_staffビューの現行バージョンを置換できます。

CREATE OR REPLACE VIEW sales_staff AS
SELECT empno, ename, deptno
FROM emp
WHERE deptno = 30
WITH CHECK OPTION CONSTRAINT sales_staff_cnst;

ビューを置換する前に、次の影響を検討してください。

- ビューを置換することによって、データ・ディクショナリ内のビュー定義が置換されます。ビューによって参照される基礎となるオブジェクトは影響を受けません。

- 前のビューにはCHECK OPTIONで制約を定義していたが、新しいビュー定義には指定しない場合、その制約は削除されます。

- 置換されたビューに依存しているビューはすべて無効(使用不可)になります。また、ビューの新しいバージョンでの変更内容によっては、依存しているPL/SQLプログラム・ユニットも無効になる場合があります。たとえば、ビューのWHERE句のみが変更された場合、依存しているPL/SQLプログラム・ユニットは有効のままです。ただし、ビューの列数、列名またはデータ型が変更された場合は、依存しているPL/SQLプログラム・ユニットも無効になります。データベースによる依存性管理の詳細は、「オブジェクト依存性の管理」を参照してください。

問合せでのビューの使用

ビューに対して問合せを発行したり、INSERT、UPDATEまたはDELETE文を発行するためには、そのビューに対するSELECT、INSERT、UPDATEまたはDELETEの各オブジェクト権限を、明示的にまたはロールを介して持っている必要があります。

ビューは、表と同じ方法で問い合せることができます。たとえば、Division1_staffビューを問い合せるには、そのビューを参照する有効なSELECT文を入力します。

SELECT * FROM Division1_staff;

ENAME        EMPNO       JOB             DNAME
------------------------------------------------------
CLARK         7782       MANAGER         ACCOUNTING
KING          7839       PRESIDENT       ACCOUNTING
MILLER        7934       CLERK           ACCOUNTING
ALLEN         7499       SALESMAN        SALES
WARD          7521       SALESMAN        SALES
JAMES         7900       CLERK           SALES
TURNER        7844       SALESMAN        SALES
MARTIN        7654       SALESMAN        SALES
BLAKE         7698       MANAGER         SALES

一部の制限を伴いますが、ビューを使用して、実表に対する行の挿入、更新または削除ができます。次の文は、sales_staffビューを使用してemp表に新しい行を挿入します。

INSERT INTO sales_staff
VALUES (7954, 'OSTER', 30);

ビューに対するDML操作の制限では、次の基準がリストされている順に適用されます。

1. ビューの定義にSETまたはDISTINCT演算子、GROUP BY句またはグループ関数を含む問合せが使用されている場合、そのビューによる実表への行の挿入、更新または削除はできません。

2. ビューの定義にWITH CHECK OPTIONが使用されていて、行を実表から選択できない場合、そのビューによる実表への行の挿入または更新はできません。

3. DEFAULT句を持たないNOT NULL列がビューから省略されている場合、そのビューによる実表への行の挿入はできません。

4. ビューの作成にDECODE(deptno, 10, "SALES", ...)のような式が使用されている場合、そのビューによる実表への行の挿入または更新はできません。

sales_staffビューのWITH CHECK OPTIONで作成された制約によって許可されるのは、部門番号30を持つ行のemp表への挿入または更新のみです。一方、次の文(つまり、deptno列を除外する)でsales_staffビューが定義されるとします。

CREATE VIEW sales_staff AS
SELECT empno, ename
FROM emp
WHERE deptno = 10
WITH CHECK OPTION CONSTRAINT sales_staff_cnst;

このビュー定義を検討すると、既存のレコードのempnoまたはenameフィールドは更新できますが、ビューではdeptnoフィールドを変更できないため、sales_staffビューを介してemp表に行を挿入することはできません。deptnoフィールドにDEFAULT値10を定義していた場合は、挿入を実行できます。

ユーザーが無効なビューを参照しようとすると、次のエラー・メッセージが返されます。

ORA-04063: view 'view_name' has errors

このエラー・メッセージが返されるのは、ビューは存在しているが、問合せのエラーが原因で使用禁止状態の場合です(このビューが最初に作成されたときにあったエラーか、またはビューは正常に作成されたが、基礎となるオブジェクトが変更または削除されたために、後で使用禁止状態になったかは関係ありません)。

結合ビューの更新

更新可能な結合ビュー(変更可能な結合ビューと呼ぶこともあります)とは、SELECT文の最上位のFROM句に複数の表を含むビューで、WITH READ ONLY句の制限を受けないものです。

更新可能な結合ビューに関する規則を次の表に示します。これらの基準を満たすビューは、従来どおり更新可能とみなされます。

規則

説明

一般規則

結合ビューに対するINSERT、UPDATEまたはDELETE操作は、基礎となる実表を一度に1つしか変更できません。

UPDATE規則

結合ビューの更新可能な列はすべて、キー保存表の列にマップする必要があります。キー保存表については、「キー保存表」を参照してください。ビューの定義にWITH CHECK OPTION句が使用されている場合は、すべての結合列および繰返し表の列はいずれも更新できません。

DELETE規則

結合の中にキー保存表が1つしかない場合には、結合ビューから行を削除できます。このキー保存表は、FROM句で繰り返すことができます。ビューの定義にWITH CHECK OPTION句が使用されていて、キー保存表が繰り返される場合は、そのビューから行を削除できません。

INSERT規則

INSERT文では、明示的にも暗黙的にも非キー保存表の列を参照しないでください。結合ビューの定義にWITH CHECK OPTION句が使用されている場合は、INSERT文を使用できません。

結合ビュー内の列が従来どおり更新可能かどうかを示すデータ・ディクショナリ・ビューがあります。これらのビューの詳細は、「UPDATABLE_COLUMNSビューの使用」を参照してください。

注意:
結合ビューが従来どおり更新可能かどうかについては、いくつかのその他の制限と条件が影響します。これらの制限と条件については、『Oracle Database SQL言語リファレンス』のCREATE VIEW文の説明を参照してください。
ビューが従来どおり更新可能でない場合は、そのビューにINSTEAD OFトリガーを作成して更新可能にできます。トリガーの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

また、ビューが別のネストされたビュー上の結合である場合は、そのネストされたビューをトップレベル・ビューにマージ可能である必要があります。マージ可能なビューとマージ不可能なビューの詳細、およびオプティマイザによってビューを参照する文が最適化される方法の概要は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

ここでは、従来どおり更新可能な結合ビューの規則の例を示し、キー保存表について説明します。それぞれの例は、表に主キーと外部キーを明示的に定義した場合、または一意索引を定義した場合にのみ動作します。次の文は、empおよびdeptの制約が適切に設定された表定義を作成します。

CREATE TABLE dept (
deptno        NUMBER(4) PRIMARY KEY,
dname         VARCHAR2(14),
loc           VARCHAR2(13));

CREATE TABLE emp (
empno        NUMBER(4) PRIMARY KEY,
ename        VARCHAR2(10),
job          VARCHAR2(9),
mgr          NUMBER(4),
sal          NUMBER(7,2),
comm         NUMBER(7,2),
deptno       NUMBER(2),
FOREIGN KEY (DEPTNO) REFERENCES DEPT(DEPTNO));

また、前述の例の主キーと外部キーの制約を省略し、dept(deptno)にUNIQUE INDEXを作成した場合でも、後続の例は動作可能です。

次の文は、例で参照されるemp_dept結合ビューを作成します。

CREATE VIEW emp_dept AS
SELECT emp.empno, emp.ename, emp.deptno, emp.sal, dept.dname, dept.loc
FROM emp, dept
WHERE emp.deptno = dept.deptno
AND dept.loc IN ('DALLAS', 'NEW YORK', 'BOSTON');

キー保存表

キー保存表の概念は、結合ビューを更新するうえでの制限を理解するために重要です。表のすべてのキーが結合の結果のキーでもある場合、その表はキー保存になります。つまり、キー保存表とは、結合後もそのキーを保存している表のことです。

注意:
表をキー保存にするために、表の1つ以上のキーを選択する必要はありません。1つ以上のキーを選択した場合に、そのキーが結合の結果のキーであれば十分です。

表のキー保存特性は、表内の実際のデータには依存しません。これは、そのスキーマの特性です。たとえば、emp表で各部門に多くても1人の従業員しか含まれていない場合、empとdeptの結合の結果ではdeptnoは一意ですが、deptはキー保存表ではありません。

emp_deptからすべての行を選択すると、結果は次のようになります。

EMPNO      ENAME      DEPTNO  DNAME          LOC
---------- ---------- ------- -------------- -----------
7782 CLARK           10 ACCOUNTING     NEW YORK
7839 KING            10 ACCOUNTING     NEW YORK
7934 MILLER          10 ACCOUNTING     NEW YORK
7369 SMITH           20 RESEARCH       DALLAS
7876 ADAMS           20 RESEARCH       DALLAS
7902 FORD            20 RESEARCH       DALLAS
7788 SCOTT           20 RESEARCH       DALLAS
7566 JONES           20 RESEARCH       DALLAS
8 rows selected.

このビューでは、empnoがemp表のキー、および結合の結果のキーでもあるため、empがキー保存表です。deptnoはdept表のキーですが、結合のキーではないため、deptはキー保存表ではありません。

DML文と結合ビュー

一般規則では、結合ビューにおいて、UPDATE、INSERTまたはDELETE文では、基礎となる実表を1つしか変更できません。以降の例は、UPDATE、DELETEおよびINSERT文に固有の規則を示しています。

UPDATE文

次の例は、emp_deptビューを正常に変更するUPDATE文を示したものです。

UPDATE emp_dept
SET sal = sal * 1.10
WHERE deptno = 10;

次に示すUPDATE文は、emp_deptビューには使用できません。

UPDATE emp_dept
SET loc = 'BOSTON'
WHERE ename = 'SMITH';

この文はdept実表を変更しようとしますが、dept表はemp_deptビューのキー保存表でないため、エラー番号ORA-01779 「キー保存されていない表にマップする列は変更できません」が出力され、文を実行できません。

一般に、結合ビューの更新可能な列はすべて、キー保存表の列にマップする必要があります。ビューの定義にWITH CHECK OPTION句が使用されている場合は、すべての結合列およびビューで2回以上参照されている表から取得したすべての列はいずれも更新できません。

したがって、たとえばemp_deptビューの定義にWITH CHECK OPTIONが使用されている場合、次に示すUPDATE文は失敗します。

UPDATE emp_dept
SET deptno = 10
WHERE ename = 'SMITH';

結合列を更新しようとするため、この文は失敗となります。

関連項目:
UPDATE文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

DELETE文

結合の中にキー保存表が1つしかない場合には、結合ビューから削除できます。このキー保存表は、FROM句で繰り返すことができます。

次のDELETE文は、emp_deptビューに対して動作します。

DELETE FROM emp_dept
WHERE ename = 'SMITH';

emp_deptビューに対するこのDELETE文は、実表empに対するDELETE操作に変換でき、表empは結合ビュー内の唯一のキー保存表であるため、この文は有効です。

次のビューでは、2つのキー保存表がありますが、同じ表であるため、DELETE操作を実行できます。つまり、キー保存表が繰り返されています。この場合、この削除文は、FROMリストの最初の表(この例では、e1)で操作されます。

CREATE VIEW emp_emp AS
SELECT e1.ename, e2.empno, e2.deptno
FROM emp e1, emp e2
WHERE e1.empno = e2.empno;

ビューの定義にWITH CHECK OPTION句が使用されていて、キー保存表が繰り返される場合は、そのビューから行を削除できません。

CREATE VIEW emp_mgr AS
SELECT e1.ename, e2.ename mname
FROM emp e1, emp e2
WHERE e1.mgr = e2.empno
WITH CHECK OPTION;

関連項目:
DELETE文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

INSERT文

emp_deptビューに対する次のINSERT文は正常に動作します。

INSERT INTO emp_dept (ename, empno, deptno)
VALUES ('KURODA', 9010, 40);

変更されるキー保存実表は1つのみであり(emp)、40はdept表の有効なdeptnoであるため(つまり、emp表に対するFOREIGN KEY整合性制約を満たすため)、この文は動作します。

次のINSERT文は、実表empに対するUPDATEが失敗するのと同じ理由で失敗します。つまり、77というdeptnoが存在しないため、emp表に対するFOREIGN KEY整合性制約に違反します。

INSERT INTO emp_dept (ename, empno, deptno)
VALUES ('KURODA', 9010, 77);

次のINSERT文はエラー番号ORA-01776「結合ビューを介して複数の実表を変更できません。」が出力されて失敗します。

INSERT INTO emp_dept (empno, ename, loc)
VALUES (9010, 'KURODA', 'BOSTON');

INSERTは、暗黙的にも明示的にも、非キー保存表の列を参照できません。結合ビューの定義にWITH CHECK OPTION句が使用されている場合は、その結合ビューに対してINSERTを実行できません。

関連項目:
INSERT文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

外部結合が含まれるビューの更新

外部結合が含まれるビューは、変更可能な場合もあります。次に例を示します。

CREATE VIEW emp_dept_oj1 AS
SELECT empno, ename, e.deptno, dname, loc
FROM emp e, dept d
WHERE e.deptno = d.deptno (+);

文:

SELECT * FROM emp_dept_oj1;

結果:

EMPNO   ENAME      DEPTNO  DNAME          LOC
------- ---------- ------- -------------- -------------
7369    SMITH      40      OPERATIONS     BOSTON
7499    ALLEN      30      SALES          CHICAGO
7566    JONES      20      RESEARCH       DALLAS
7654    MARTIN     30      SALES          CHICAGO
7698    BLAKE      30      SALES          CHICAGO
7782    CLARK      10      ACCOUNTING     NEW YORK
7788    SCOTT      20      RESEARCH       DALLAS
7839    KING       10      ACCOUNTING     NEW YORK
7844    TURNER     30      SALES          CHICAGO
7876    ADAMS      20      RESEARCH       DALLAS
7900    JAMES      30      SALES          CHICAGO
7902    FORD       20      RESEARCH       DALLAS
7934    MILLER     10      ACCOUNTING     NEW YORK
7521    WARD       30      SALES          CHICAGO
14 rows selected.

emp_dept_oj1のemp実表の列は、empが結合の中のキー保存表であるため、ビューを介して変更可能です。

次のビューにも外部結合が含まれています。

CREATE VIEW emp_dept_oj2 AS
SELECT e.empno, e.ename, e.deptno, d.dname, d.loc
FROM emp e, dept d
WHERE e.deptno (+) = d.deptno;

文:

SELECT * FROM emp_dept_oj2;

結果:

EMPNO      ENAME      DEPTNO    DNAME          LOC
---------- ---------- --------- -------------- ----
7782       CLARK      10        ACCOUNTING     NEW YORK
7839       KING       10        ACCOUNTING     NEW YORK
7934       MILLER     10        ACCOUNTING     NEW YORK
7369       SMITH      20        RESEARCH       DALLAS
7876       ADAMS      20        RESEARCH       DALLAS
7902       FORD       20        RESEARCH       DALLAS
7788       SCOTT      20        RESEARCH       DALLAS
7566       JONES      20        RESEARCH       DALLAS
7499       ALLEN      30        SALES          CHICAGO
7698       BLAKE      30        SALES          CHICAGO
7654       MARTIN     30        SALES          CHICAGO
7900       JAMES      30        SALES          CHICAGO
7844       TURNER     30        SALES          CHICAGO
7521       WARD       30        SALES          CHICAGO
OPERATIONS     BOSTON
15 rows selected.

このビューでは、結合の結果のempno列がNULL(前述のSELECT文の最終行)になる可能性があるため、empはキー保存表ではなくなります。したがって、このビューでは、UPDATE、DELETEおよびINSERT操作を実行できません。

別のネストされたビュー上の外部結合を含むビューの場合は、表を含むビューがその外部ビューの最上位まですべてマージされる場合に、その表はキー保存になります。外部結合されているビューは現在、単純な場合にのみマージされます。次に例を示します。

SELECT col1, col2, ... FROM T;

ビューの選択リストには式がなく、WHERE句が存在しません。

次のビューのセットを考えてみます。

CREATE VIEW emp_v AS
SELECT empno, ename, deptno
FROM emp;
CREATE VIEW emp_dept_oj1 AS
SELECT e.*, Loc, d.dname
FROM emp_v e, dept d
WHERE e.deptno = d.deptno (+);

これらの例では、emp_vが単純なビューであるため、emp_vはemp_dept_oj1にマージされ、その結果empがキー保存表となります。ただし、次のようにemp_vが変更される場合もあります。

CREATE VIEW emp_v_2 AS
SELECT empno, ename, deptno
FROM emp
WHERE sal > 1000;

この場合は、WHERE句の存在により、emp_v_2がemp_dept_oj1にマージされず、その結果empはキー保存表ではなくなります。

ビューが更新可能かどうか不確かな場合は、USER_UPDATABLE_COLUMNSビューから選択することで確認できます。次に例を示します。

SELECT owner, table_name, column_name, updatable FROM USER_UPDATABLE_COLUMNS
WHERE TABLE_NAME = 'EMP_DEPT_VIEW';

ここでは、次のような出力が返されます。

OWNER       TABLE_NAME      COLUMN_NAM      UPD
----------  ----------      ----------      ---
SCOTT       EMP_DEPT_V      EMPNO           NO
SCOTT       EMP_DEPT_V      ENAME           NO
SCOTT       EMP_DEPT_V      DEPTNO          NO
SCOTT       EMP_DEPT_V      DNAME           NO
SCOTT       EMP_DEPT_V      LOC             NO
5 rows selected.

UPDATABLE_COLUMNSビューの使用

次の表に示すビューは、従来どおり更新可能な結合ビューを識別する際に利用できます。

ビュー

説明

DBA_UPDATABLE_COLUMNS

変更可能なすべての表とビューのすべての列が表示されます。

ALL_UPDATABLE_COLUMNS

ユーザーがアクセス可能で変更可能なすべての表とビューのすべての列が表示されます。

USER_UPDATABLE_COLUMNS

ユーザーのスキーマ内で変更可能なすべての表とビューのすべての列が表示されます。

次に、emp_deptビュー内の更新可能な列を示します。

SELECT COLUMN_NAME, UPDATABLE
FROM USER_UPDATABLE_COLUMNS
WHERE TABLE_NAME = 'EMP_DEPT';

COLUMN_NAME                    UPD
------------------------------ ---
EMPNO                          YES
ENAME                          YES
DEPTNO                         YES
SAL                            YES
DNAME                          NO
LOC                            NO

6 rows selected.

関連項目:
更新可能な列のビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ビューの変更

ALTER VIEW文は、無効なビューを明示的に再コンパイルする場合にのみ使用します。ビューの定義を変更する場合は、「ビューの置換」を参照してください。

ALTER VIEW文を使用すると、実際に使用する前に再コンパイル・エラーを調べることができます。ビューの実表の1つを変更したとき、変更がビューまたはそれに依存する他のオブジェクトに影響しないようにするには、そのビューを明示的に再コンパイルします。

ALTER VIEW文を使用するには、そのビューが自分のスキーマに含まれているか、またはALTER ANY TABLEシステム権限を持っている必要があります。

関連項目:
ALTER VIEW文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ビューの削除

自分のスキーマにあるビューはすべて削除できます。別のユーザーのスキーマ内にあるビューを削除するには、DROP ANY VIEWシステム権限が必要です。ビューを削除するには、DROP VIEW文を使用します。たとえば、次の文はemp_deptビューを削除します。

DROP VIEW emp_dept;

関連項目:
DROP VIEW文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

順序の管理

ここでは、順序の管理について説明します。この項の内容は、次のとおりです。

- 順序の概要

- 順序の作成

- 順序の変更

- 順序の使用

- 順序の削除

順序の概要

順序とは、複数のユーザーが一意の整数を生成するために使用できるデータベース・オブジェクトです。順序ジェネレータは順序番号を生成し、一意主キーの自動的な生成、および複数の行または表の間のキーの調整に使用できます。

順序がない場合、シーケンシャル値はプログラムによって生成されるのみです。新しい主キー値は、最後に生成された値を選択し、その値を増分することによって取得できます。この方法では、トランザクション中のロックが必要となるため、複数のユーザーが主キーの次の値を待機することになり、この待機をシリアライズと呼びます。開発者がこのような構成メンバーをアプリケーションに設定している場合は、順序へのアクセスに置き換えるように薦めてください。順序によってシリアライズが解消され、アプリケーションの同時実行性が改善されます。

関連項目:
順序の概要については、『Oracle Database概要』を参照してください。

順序の作成

自分のスキーマに順序を作成するには、CREATE SEQUENCEシステム権限が必要です。別のユーザーのスキーマ内に順序を作成するには、CREATE ANY SEQUENCE権限が必要です。

順序を作成するには、CREATE SEQUENCE文を使用します。たとえば、次の文は、emp表のempno列に対して従業員番号を生成するために使用する順序を作成します。

CREATE SEQUENCE emp_sequence
INCREMENT BY 1
START WITH 1
NOMAXVALUE
NOCYCLE
CACHE 10;

複数のパラメータを指定して、順序の機能を制御できます。これらのパラメータを使用して、順序の昇順または降順、順序の開始点、最大値と最小値、および順序値の間隔を指定できます。NOCYCLEオプションは、順序が最大値または最小値に達すると、それ以上の値を生成できなくなることを示します。

CACHE句は順序番号により高速にアクセスできるように、順序番号の集合をメモリーに事前割当てし、維持します。キャッシュ内の最後の順序番号が使用されると、別の順序の集合がキャッシュ内に読み込まれます。

順序番号の集合をキャッシュする場合に、順序番号がスキップされることがあります。たとえば、インスタンスが異常停止すると(たとえばインスタンス障害が発生したり、SHUTDOWN ABORT文が発行されたりすると)、キャッシュされているが使用されていない順序番号は失われます。また、使用されても保存されなかった順序番号も失われます。さらに、エクスポートとインポートの後、データベースがキャッシュされた順序番号をスキップすることもあります。詳細は、『Oracle Databaseユーティリティ』を参照してください。

関連項目:

- CREATE SEQUENCE文の構文については、『Oracle Database SQL言語リファレンス』を参照してください。

- Oracle Real Application Clusters環境で順序を使用する方法については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

順序の変更

順序を変更するには、スキーマに順序が含まれている必要があり、順序に対するALTERオブジェクト権限またはALTER ANY SEQUENCEシステム権限が必要です。順序を変更して、順序開始番号以外の順序番号の生成方法を定義するパラメータを変更できます。順序の開始点を変更するには、順序を削除し、再作成します。

順序を変更するには、ALTER SEQUENCE文を使用します。たとえば、次の文は、emp_sequenceを変更します。

ALTER SEQUENCE emp_sequence
INCREMENT BY 10
MAXVALUE 10000
CYCLE
CACHE 20;

関連項目:
ALTER SEQUENCE文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

順序の使用

順序を使用するには、順序が自分のスキーマに含まれているか、または別のユーザーの順序に対するSELECTオブジェクト権限が付与されている必要があります。 定義済の順序は、複数のユーザー(該当する順序を含む順序に対するSELECTオブジェクト権限を持つユーザー)が待機せずにアクセスおよび増分できます。順序を増分したトランザクションの完了を待機せずに、その順序は再び増分されます。

次の各項の例では、マスター/ディテール表の関係における順序の使用方法について説明します。顧客からの注文の情報を格納する2つの表orders_tab(マスター表)およびline_items_tab(ディテール表)で部分的に構成される注文入力システムを想定します。order_seqという名前の順序が、次の文で定義されます。

CREATE SEQUENCE Order_seq
START WITH 1
INCREMENT BY 1
NOMAXVALUE
NOCYCLE
CACHE 20;

順序の参照

順序は、NEXTVALおよびCURRVAL疑似列を使用して、SQL文内で参照できます。それぞれの新しい順序番号は、順序の疑似列NEXTVALへの参照によって生成され、現行の順序番号は、疑似列CURRVALを使用して繰り返し参照できます。

NEXTVALおよびCURRVALは、予約語またはキーワードではなく、SELECT、INSERTまたはUPDATEのようなSQL文の中で疑似列名として使用できます。

NEXTVALを使用した順序番号の生成

順序番号を生成して使用するには、seq_name.NEXTVALを参照します。たとえば、顧客からの発注を受けると想定します。順序番号は、値のリストの中で参照できます。次に例を示します。

INSERT INTO Orders_tab (Orderno, Custno)
VALUES (Order_seq.NEXTVAL, 1032);

または、順序番号は、UPDATE文のSET句の中で参照できます。次に例を示します。

UPDATE Orders_tab
SET Orderno = Order_seq.NEXTVAL
WHERE Orderno = 10112;

順序番号は、問合せまたは副問合せのSELECTの最も外側でも参照できます。次に例を示します。

SELECT Order_seq.NEXTVAL FROM dual;

定義されているように、order_seq.NEXTVALへの最初の参照が値1を返します。order_seq.NEXTVALを参照する後続の各文は、次の順序番号(2、3、4、. . .)を生成します。疑似列NEXTVALは、必要に応じた数の新しい順序番号を生成するために使用されます。ただし、各行に生成される順序番号は1つのみです。つまり、1つの文でNEXTVALが複数回参照される場合、最初の参照によって次の番号が生成され、文の中のすべての後続の参照によって同じ番号が返されます。

生成された順序番号は、その番号を生成したセッションに対してのみ使用可能です。トランザクションのコミットまたはロールバックには関係なく、order_seq.NEXTVALを参照する他のユーザーは一意の値を取得します。2人のユーザーが同時に同じ順序にアクセスしている場合、他方のユーザーも順序番号を生成しているため、各ユーザーが受け取る順序番号に食い違いが生じる可能性があります。

CURRVALを使用した順序番号の使用

自分のセッションの現在の順序値を使用または参照するには、seq_name.CURRVALを参照します。現行のユーザー・セッション(現行または既存のトランザクション内)でseq_name.NEXTVALが参照された場合のみ、CURRVALが使用されます。CURRVALは、同一文内で複数回の場合を含め、必要な回数だけ参照できます。次の順序番号は、NEXTVALが参照されると生成されます。前述の例を続けると、注文の明細項目を挿入することで、顧客からの発注を完了します。

INSERT INTO Line_items_tab (Orderno, Partno, Quantity)
VALUES (Order_seq.CURRVAL, 20321, 3);

INSERT INTO Line_items_tab (Orderno, Partno, Quantity)
VALUES (Order_seq.CURRVAL, 29374, 1);

前項で指定したINSERT文が、新しい順序番号347を生成した場合、この項の文で挿入された両方の行は注文番号347の行を挿入します。

NEXTVALおよびCURRVALの使用と制限事項

CURRVALおよびNEXTVALは、次の場所で使用できます。

- INSERT文のVALUES句

- SELECT文のSELECTリスト

- UPDATE文のSET句

CURRVALおよびNEXTVALは、次の場所では使用できません。

- 副問合せ

- ビューの問合せまたはマテリアライズド・ビューの問合せ

- DISTINCT演算子を指定したSELECT文

- GROUP BYまたはORDER BY句を指定したSELECT文

- UNION、INTERSECTまたはMINUS集合演算子を指定した別のSELECT文と組み合せたSELECT文

- SELECT文のWHERE句

- CHECK制約の条件

順序番号のキャッシュ

順序番号は、システム・グローバル領域(SGA)内の順序キャッシュに保持できます。順序キャッシュ内の順序番号へのアクセスは、順序番号をディスクから読み込むより高速です。

順序キャッシュは、複数のエントリで構成されています。各エントリには、単一の順序の順序番号を多数保持できます。

すべての順序番号に高速にアクセスするには、次のガイドラインに従ってください。

- 順序キャッシュが、アプリケーションによって同時に使用されるすべての順序を保持できるようにしてください。

- 順序キャッシュ内に保持された各順序の値の数を増やしてください。

順序キャッシュ内のエントリの数

アプリケーションが順序キャッシュ内の順序にアクセスする場合、順序番号は高速に読み込まれます。ただし、アプリケーションがキャッシュ内にない順序にアクセスする場合は、順序番号が使用される前に、順序がディスクからキャッシュに読み込まれる必要があります。

アプリケーションが多数の順序を同時に使用する場合は、順序キャッシュの大きさが不足して、すべての順序を保持できないことがあります。このような場合、順序番号へのアクセスにはディスク読取りが頻繁に必要になります。すべての順序に高速にアクセスするには、キャッシュに十分なエントリを用意し、アプリケーションが同時に使用するすべての順序を保持してください。

各順序キャッシュ・エントリ内の値の数

順序が順序キャッシュに読み込まれるとき、キャッシュ・エントリに順序値が生成および格納されます。その後、これらの値に高速にアクセスできます。キャッシュに格納される順序値の数は、CREATE SEQUENCE文のCACHEパラメータによって決まります。このパラメータのデフォルト値は20です。

次のCREATE SEQUENCE文はseq2順序を作成し、SEQUENCEキャッシュ内に50個の順序値を格納します。

CREATE SEQUENCE seq2
CACHE 50;

次に、seq2の最初の50個の値がキャッシュから読み込まれます。51番目の値がアクセスされると、次の50個の値がディスクから読み込まれます。

CACHEに上限を選択することにより、ディスクから順序キャッシュへの読取りを減らし、より長く連続する順序番号にアクセスできます。ただし、インスタンス障害が発生した場合は、キャッシュ内のすべての順序値が失われます。エクスポートの実行中にトランザクションが順序番号へのアクセスを続ける場合、エクスポートとインポートの後で、キャッシュされた順序番号がスキップされることもあります。

CREATE SEQUENCE文の中でNOCACHEオプションを使用する場合、順序値は順序キャッシュに格納されません。この場合は、順序にアクセスするたびにディスク読取りが必要となります。このようなディスク読取りにより、順序へのアクセスが遅くなります。次のCREATE SEQUENCE文はSEQ3順序を作成しますが、その値をキャッシュ内に格納しません。

CREATE SEQUENCE seq3
NOCACHE;

順序の削除

自分のスキーマ内の順序はどれでも削除できます。別のスキーマ内の順序を削除するには、DROP ANY SEQUENCEシステム権限が必要です。 不要になった順序は、DROP SEQUENCE文を使用して削除できます。たとえば、次の文はorder_seq順序を削除します。

DROP SEQUENCE order_seq;

順序を削除すると、その定義がデータ・ディクショナリから削除されます。順序のシノニムはそのまま残りますが、参照時にエラーが返されます。

関連項目:
DROP SEQUENCE文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

シノニムの管理

ここでは、シノニムの管理について説明します。この項の内容は、次のとおりです。

- シノニムの概要

- シノニムの作成

- DML文でのシノニムの使用

- シノニムの削除

シノニムの概要

シノニムは、スキーマ・オブジェクトの別名です。シノニムは、オブジェクトの名前および所有者をマスキングし、分散データベースのリモート・オブジェクトに対する位置の透過性を提供することで、一定レベルのセキュリティを提供できます。また、データベース・ユーザーにとって、シノニムは使いやすく、SQL文の複雑さが軽減されます。

シノニムを使用することで、基礎となるオブジェクトの名前変更または移動が可能になります。その場合、シノニムの再定義のみで、そのシノニムに基づくアプリケーションは変更しなくてもそのまま機能します。

パブリック・シノニムとプライベート・シノニムの両方を作成できます。パブリック・シノニムはPUBLICという名前の特別なユーザー・グループによって所有され、データベース内のすべてのユーザーがアクセスできます。プライベート・シノニムは、特定のユーザーのスキーマ内に含まれており、そのユーザーおよび基礎となるオブジェクトの権限受領者のみが使用できます。

シノニム自体は安全ではありません。シノニムのオブジェクト権限を付与した場合、実際には基礎となるオブジェクトの権限を付与することになり、そのシノニムはGRANT文でオブジェクトの別名としてのみ機能します。

関連項目:
シノニムの詳細は、『Oracle Database概要』を参照してください。

シノニムの作成

自分のスキーマに新しいプライベート・シノニムを作成するには、CREATE SYNONYMシステム権限が必要です。別のユーザーのスキーマ内にプライベート・シノニムを作成するには、CREATE ANY SYNONYM権限が必要です。パブリック・シノニムを作成するには、CREATE PUBLIC SYNONYMシステム権限が必要です。

シノニムを作成するには、CREATE SYNONYM文を使用します。CREATE SYNONYM文を正常に実行するために、基礎となるスキーマ・オブジェクトは必要なく、また、そのオブジェクトにアクセスする権限も不要です。次の文は、jwardのスキーマに含まれるemp表のパブリック・シノニムpublic_empを作成します。

CREATE PUBLIC SYNONYM public_emp FOR jward.emp

リモート・プロシージャまたはファンクションのシノニムを作成する場合は、そのリモート・プロシージャまたはファンクションのスキーマ名でリモート・オブジェクトを修飾する必要があります。また、リモート・オブジェクトが存在するデータベースに、ローカル・パブリック・シノニムを作成できますが、この場合は、プロシージャまたはファンクションへの後続のすべてのコールに、そのデータベース・リンクを含める必要があります。

関連項目:
CREATE SYNONYM文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

DML文でのシノニムの使用

基礎となるオブジェクトへのアクセスに必要な権限が、明示的に、使用可能なロールから、またはPUBLICから付与されている場合は、自分のスキーマまたはパブリック・シノニムに含まれるプライベート・シノニムを正常に使用できます。また、基礎となるオブジェクトについて必要なオブジェクト権限が付与されている場合は、別のスキーマ内のプライベート・シノニムを参照することもできます。

付与されているオブジェクト権限のみを使用して、別のユーザーのシノニムを参照できます。たとえば、jward.emp表に対するSELECT権限のみがあるときに、シノニムjward.employeeがjward.empに対して作成された場合は、jward.employeeシノニムの問合せはできますが、jward.employeeシノニムを使用した行の挿入はできません。

シノニムは、そのシノニムの基礎となるオブジェクトを参照するのと同じ方法で、DML文で参照できます。たとえば、employeeというシノニムが表またはビューを参照する場合は、次の文が有効になります。

INSERT INTO employee (empno, ename, job)
VALUES (emp_sequence.NEXTVAL, 'SMITH', 'CLERK');

fire_empというシノニムがスタンドアロン・プロシージャまたはパッケージ・プロシージャを参照する場合は、それをコマンドで実行できます。

EXECUTE Fire_emp(7344);

シノニムの削除

自分のスキーマ内のプライベート・シノニムはどれでも削除できます。別のユーザーのスキーマ内にあるプライベート・シノニムを削除するには、DROP ANY SYNONYMシステム権限が必要です。パブリック・シノニムを削除するには、DROP PUBLIC SYNONYMシステム権限が必要です。

不要になったシノニムを削除するには、DROP SYNONYM文を使用します。プライベート・シノニムを削除する場合は、PUBLICキーワードを省略します。パブリック・シノニムを削除する場合は、PUBLICキーワードを指定します。

たとえば、次の文はプライベート・シノニムempを削除します。

DROP SYNONYM emp;

次の文は、パブリック・シノニムpublic_empを削除します。

DROP PUBLIC SYNONYM public_emp;

シノニムを削除すると、その定義がデータ・ディクショナリから削除されます。削除したシノニムを参照するオブジェクトはすべて残ります。ただし、それらのオブジェクトは無効(使用不可)になります。シノニムの削除が他のスキーマ・オブジェクトに与える影響の詳細は、「オブジェクト依存性の管理」を参照してください。

関連項目:
DROP SYNONYM文の構文と詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ビュー、順序およびシノニムのデータ・ディクショナリ・ビュー

次のビューには、ビュー、シノニムおよび順序に関する情報が表示されます。

ビュー

説明

DBA_VIEWS
ALL_VIEWS

USER_VIEWS

DBAビューには、データベース内のすべてのビューが表示されます。ALLビューは、現行ユーザーがアクセスできるビューのみに制限されます。USERビューは、現行ユーザーが所有するビューのみに制限されます。

DBA_SYNONYMS
ALL_SYNONYMS

USER_SYNONYMS

これらのビューには、シノニムが表示されます。

DBA_SEQUENCES
ALL_SEQUENCES

USER_SEQUENCES

これらのビューには、順序が表示されます。

DBA_UPDATABLE_COLUMNS
ALL_UPDATABLE_COLUMNS

USER_UPDATABLE_COLUMNS

これらのビューには、更新可能な結合ビューの列がすべて表示されます。

関連項目:
これらのビューの完全な説明は、『Oracle Databaseリファレンス』を参照してください。

25 破損データの修復

この章の内容は、次のとおりです。

- データ・ブロック破損を修復するオプション

- DBMS_REPAIRパッケージの内容

- DBMS_REPAIRパッケージの使用方法

- DBMS_REPAIRの例

注意:
DBMS_REPAIRパッケージについて詳しくない場合は、このパッケージに含まれる修復プロシージャを実行する際に、Oracleサポート・サービスのアナリストと共同で作業することをお薦めします。

データ・ブロック破損を修復するオプション

Oracle Databaseには、データ・ブロックの破損を検出して修正するために、複数の方法が用意されています。その1つは、破損の検出後にオブジェクトを削除して再作成することです。しかし、この方法が必ずしも可能とはかぎらず、またそれが望ましくない場合もあります。データ・ブロックの破損が行のサブセットにかぎられている場合は、破損した行を除くすべてのデータを選択して表を再作成する方法があります。

また、DBMS_REPAIRパッケージを使用してデータ・ブロック破損を管理する方法もあります。DBMS_REPAIRを使用すると、表と索引の破損ブロックを検出して修復できます。オブジェクトは、再作成または修復の試行中でも続けて使用できます。

Recovery Manager (RMAN)のコマンドRECOVER BLOCKを使用して、破損したデータ・ブロックまたはデータ・ブロックのセットを修復することもできます。

注意:
データの損失を伴う破損の場合は、そのデータがデータベース・システム全体にどのように格納されているかを分析して理解する必要があります。修復の内容によっては、データを失ったり、論理的一貫性が損なわれる場合があります。このパッケージで提供される修復アプローチが特定の破損に対して適切かどうかを個々に判断する必要があります。

関連項目:
RMANのRECOVER BLOCKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

DBMS_REPAIRパッケージの内容

ここでは、DBMS_REPAIRパッケージに含まれているプロシージャと、その使用に伴う制約および制限事項について説明します。

関連項目:
DBMS_REPAIRプロシージャの構文、制限事項および例外の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

DBMS_REPAIRプロシージャ

次の表は、DBMS_REPAIRパッケージに含まれているプロシージャの一覧を示します。

プロシージャ名

説明

ADMIN_TABLES

修復表および孤立キー表の管理機能(作成、削除、パージ)を提供します。
注意: これらの表は常にSYSスキーマに作成されます。

CHECK_OBJECT

表または索引の破損を検出し、レポートします。

DUMP_ORPHAN_KEYS

破損データ・ブロック内の行を指す索引エントリをレポートします。

FIX_CORRUPT_BLOCKS

すでにCHECK_OBJECTプロシージャで破損ブロックとして識別されているブロックにソフトウェア破損を示すマークを付けます。

REBUILD_FREELISTS

オブジェクトの空きリストを再作成します。

SEGMENT_FIX_STATUS

セグメント領域管理がAUTOの場合に、ビットマップ・エントリの破損状態を修正する機能を提供します。

SKIP_CORRUPT_BLOCKS

このプロシージャを使用すると、表と索引のスキャン時に、破損マークが付いたブロックが無視されます。使用しない場合は、破損マークが付いたブロックが検出されたときにエラーORA-01578が返されます。

これらのプロシージャの詳細と使用例は、「DBMS_REPAIRの例」を参照してください。

制約と制限事項

DBMS_REPAIRプロシージャには、次の制約があります。

- LOBデータ型、ネストした表およびVARRAYを含む表はサポートされますが、表外格納の列は無視されます。

- クラスタは、SKIP_CORRUPT_BLOCKSおよびREBUILD_FREELISTSプロシージャではサポートされますが、CHECK_OBJECTプロシージャではサポートされません。

- 索引構成表およびLOB索引はサポートされません。

- グローバル一時表はサポートされていません。

- DUMP_ORPHAN_KEYSプロシージャは、ビットマップ索引またはファンクション索引には機能しません。

- DUMP_ORPHAN_KEYSプロシージャで処理される最大キー長は、3,950バイトです。

DBMS_REPAIRパッケージの使用方法

データ・ブロック破損に対処する手段としてDBMS_REPAIRを検討する場合は、次のアプローチに従うことをお薦めします。

- タスク1: 破損の検出とレポート

- タスク2: DBMS_REPAIRの使用に伴うコストと利点の評価

- タスク3: オブジェクトの使用可能化

- タスク4: 破損の修復および失われたデータの再作成

タスク1: 破損の検出とレポート

最初のタスクでは、破損を検出しレポートします。レポートでは、ブロックに関する問題が明らかになるだけでなく、それに対応する修復ディレクティブも識別されます。破損を検出するには、いくつかの方法があります。表25-1に、異なる検出方法を示します。

表25-1 破損検出方法の比較

検出方法

説明

DBMS_REPAIR PL/SQLパッケージ

指定した表、パーティションまたは索引のブロック・チェックを実行します。修復表に結果を移入します。

DB_VERIFYユーティリティ

オフライン・データベースでブロック・チェックを実行します。

ANALYZE TABLE SQL文

VALIDATE STRUCTUREオプションを指定すると、索引、表またはクラスタの構造の整合性がANALYZE TABLE文によって検証され、表と索引が同期しているかどうかがチェックまたは検証されます。

DB_BLOCK_CHECKING初期化パラメータ

DB_BLOCK_CHECKING=TRUEの場合は、実際に破損マークを付ける前に、破損ブロックが識別されます。チェックは、ブロックの変更時に実行されます。

DBMS_REPAIR: CHECK_OBJECTおよびADMIN_TABLESプロシージャの使用

CHECK_OBJECTプロシージャは、指定されたオブジェクトのブロック破損をチェックしてレポートします。索引と表に対するANALYZE...VALIDATE STRUCTURE文と同様に、索引とデータ・ブロックに対してブロック・チェックが実行されます。

CHECK_OBJECTでは、破損がレポートされるだけでなく、そのオブジェクトに対して後でFIX_CORRUPT_BLOCKSを実行した場合に行われる修正も識別されます。この情報は修復表への移入によって使用可能になるため、最初にADMIN_TABLESプロシージャで修復表を作成しておく必要があります。

CHECK_OBJECTプロシージャを実行した後は、修復表の簡単な問合せによってそのオブジェクトの破損および修復ディレクティブが表示されます。この情報に基づいて、レポートされた問題に最も適切な対処方法を評価できます。

DB_VERIFY: オフライン・データベース・チェックの実行

データ破損が発生した場合は、オフライン診断ユーティリティとしてDB_VERIFYを使用します。

関連項目:
DB_VERIFYの詳細は、『Oracle Databaseユーティリティ』を参照してください。

ANALYZE: 破損のレポート

ANALYZE TABLE...VALIDATE STRUCTURE文は、分析するオブジェクトの構造の妥当性をチェックします。オブジェクトの構造内で破損が検出されると、エラー・メッセージが表示されます。この場合、オブジェクトを削除して作成しなおす必要があります。

ANALYZE TABLE文のCASCADE句を使用すると、1回の操作で、表とすべての索引の構造をチェックできます。この操作ではリソースを大量に消費する可能性があるため、軽量なチェックを実行するFASTオプションを使用できます。詳細は、「表、索引、クラスタおよびマテリアライズド・ビューの妥当性チェック」を参照してください。

関連項目:

- ANALYZE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

DB_BLOCK_CHECKING初期化パラメータ

DB_BLOCK_CHECKING初期化パラメータをTRUEに設定すると、データベースのブロック・チェックを使用可能にすることができます。これにより、データ・ブロックおよび索引ブロックが変更された際には、必ずそのブロックの内部一貫性がチェックされます。DB_BLOCK_CHECKINGは、ALTER SYSTEM SET文で変更可能な動的パラメータです。システム表領域では、ブロック・チェックは常に使用可能になっています。

関連項目:
DB_BLOCK_CHECKING初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

タスク2: DBMS_REPAIRの使用に伴うコストと利点の評価

DBMS_REPAIRを使用する前に、その利害得失を検討する必要があります。また、破損オブジェクトの対応手段として使用可能な他のオプションも検討してください。次の質問に答えることから開始してください。

- 破損の範囲はどの程度ですか。
破損の有無と修復アクションの要不要を判断するには、CHECK_OBJECTプロシージャを実行して修復表を問い合せます。

- ブロック破損の対応手段として使用可能な他のオプションがありますか。この質問については、次の対応が可能かどうかを検討します。

- 他のソースからのデータが使用可能な場合は、そのオブジェクトを削除し、再作成して再移入する。

- CREATE TABLE...AS SELECT文を発行して、破損表から新しい表を作成する。

- SELECT文から破損行を除外して、破損を無視する。

- メディア・リカバリを実行する。

- DBMS_REPAIRを使用してオブジェクトを使用可能にした場合に、どのような論理的な破損や副作用が生じますか。それらの問題に対処できますか。そのためにはどんな作業が必要ですか。
破損マークが付いたブロックの行にはアクセスできない場合があります。また、正常にアクセスできる行が含まれているブロックでも、破損マークが付いている場合があります。

ブロックに破損マークが付いている場合は、参照整合性制約が壊れていることがあります。この場合は、制約を使用禁止にし、再び使用可能にすると、不整合がレポートされます。すべての問題を解決すれば、再び制約を使用できるようになります。

表にトリガーが定義されている場合は、論理的な破損が生じることがあります。たとえば、行を再度挿入したときに、挿入トリガーが起動されるかどうかを確認します。これらの問題に対処するには、インストレーションでどのトリガーがどのように使用されているかを理解する必要があります。

索引と表が同期化されていない場合は、DUMP_ORPHAN_KEYSプロシージャを実行して、破損データの再作成に役立つ情報をキーから取得します。次に、ALTER INDEX...REBUILD ONLINE文を発行し、表と索引を同期化します。

- 修復によってデータが失われる場合に、このデータを取り出すことができますか。
データ・ブロックに破損マークが付いている場合は、索引からデータを取り出すことができます。この情報を取り出すには、DUMP_ORPHAN_KEYSプロシージャを利用します。

タスク3: オブジェクトの使用可能化

DBMS_REPAIRを使用して表と索引のスキャン時に破損を無視することにより、オブジェクトを使用可能にします。

破損の修復: FIX_CORRUPT_BLOCKSおよびSKIP_CORRUPT_BLOCKSプロシージャの使用

DBMS_REPAIRの機能の適用範囲外にある破損をスキップする環境を設定し、それによって破損オブジェクトを使用可能にできます。

データ・ブロックに不良行がある場合のようにデータの損失を伴う破損の場合は、FIX_CORRUPT_BLOCKSプロシージャによって、そのようなブロックすべてに破損マークが付けられます。次に、破損マークが付いたブロックをスキップするSKIP_CORRUPT_BLOCKSプロシージャを実行できます。SKIP_FLAGパラメータがプロシージャに設定されている場合は、破損マークが付いているすべてのブロックが、表と索引のスキャンでスキップされます。これはメディアとソフトウェアの両方の破損ブロックに適用されます。

破損ブロックをスキップする操作の意味

索引と表が同期化されていない場合、ある問合せで索引のみをプローブし、後続の問合せで索引と表の両方をプローブするような状況下では、SET TRANSACTION READ ONLYトランザクションの一貫性が保たれないことがあります。表ブロックに破損マークが付いている場合、この2つの問合せは異なる結果を返すので、読取り専用トランザクションのルールに違反します。この場合の対処方法の1つとして、SET TRANSACTION READ ONLYトランザクション内で破損をスキップしないようにします。

これと同様の問題は、連鎖している行の選択時にも発生します。同じ行を問い合せても、破損にアクセスできる場合とできない場合があるため、異なった結果が生じます。

タスク4: 破損の修復および失われたデータの再作成

オブジェクトを使用可能にした後で、次の修復アクティビティを実行します。

DUMP_ORPHAN_KEYSプロシージャを使用したデータのリカバリ

DUMP_ORPHAN_KEYSプロシージャは、破損データ・ブロック内の行を指す索引エントリをレポートします。この種の索引エントリがすべて、破損のキーとROWIDを格納する孤立キー表に挿入されます。

索引エントリ情報を取り出した後、ALTER INDEX...REBUILD ONLINE文を使用して索引を再作成できます。

SEGMENT_FIX_STATUSプロシージャを使用したセグメント・ビットマップの修正

セグメントの空き領域がビットマップで管理されている場合(SEGMENT SPACE MANAGEMENT AUTO)は、このプロシージャを使用します。

このプロシージャは、対応するブロックの現在の内容に基づいてビットマップ・エントリの状態を再計算します。また、ビットマップ・エントリを特定の値に設定するように指定することもできます。通常は、状態が適切に再計算されるので、値を強制的に設定する必要はありません。

DBMS_REPAIRの例

この項の内容は次のとおりです。

- 例: 修復表または孤立キー表の作成

- 例: 破損の検出

- 例: 破損ブロックの修正

- 例: 破損データ・ブロックを指す索引エントリの検索

- 例: 破損ブロックのスキップ

例: 修復表または孤立キー表の作成

ADMIN_TABLEプロシージャは、修復表または孤立キー表の作成、パージまたは削除に使用します。

修復表は、CHECK_OBJECTプロシージャによって検出された破損の内容と、FIX_CORRUPT_BLOCKSプロシージャを実行した場合にこれらの破損がどのように処理されるかを示す情報を提供します。また、FIX_CORRUPT_BLOCKSプロシージャの実行が必要かを判断する際にも使用されます。

孤立キー表は、DUMP_ORPHAN_KEYSプロシージャの実行時に使用され、破損行を指す索引エントリが格納されます。DUMP_ORPHAN_KEYSプロシージャは、そのアクティビティをロギングし、索引情報を使用可能な形にして、孤立キー表に移入します。

例: 修復表の作成

次の例では、users表領域の修復表を作成しています。

BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'REPAIR_TABLE',
TABLE_TYPE => dbms_repair.repair_table,
ACTION     => dbms_repair.create_action,
TABLESPACE => 'USERS');
END;
/

修復表または孤立キー表それぞれについて、存在しなくなったオブジェクトに関連する行を除外するビューも作成されます。ビュー名は、修復表または孤立キー表の名前に対応しており、接頭辞DBA_が付いています(例: DBA_REPAIR_TABLE、DBA_ORPHAN_KEY_TABLE)。

次の問合せでは、users表領域に作成された修復表が表示されます。

DESC REPAIR_TABLE

Name                         Null?    Type
---------------------------- -------- --------------
OBJECT_ID                    NOT NULL NUMBER
TABLESPACE_ID                NOT NULL NUMBER
RELATIVE_FILE_ID             NOT NULL NUMBER
BLOCK_ID                     NOT NULL NUMBER
CORRUPT_TYPE                 NOT NULL NUMBER
SCHEMA_NAME                  NOT NULL VARCHAR2(30)
OBJECT_NAME                  NOT NULL VARCHAR2(30)
BASEOBJECT_NAME                       VARCHAR2(30)
PARTITION_NAME                        VARCHAR2(30)
CORRUPT_DESCRIPTION                   VARCHAR2(2000)
REPAIR_DESCRIPTION                    VARCHAR2(200)
MARKED_CORRUPT               NOT NULL VARCHAR2(10)
CHECK_TIMESTAMP              NOT NULL DATE
FIX_TIMESTAMP                         DATE
REFORMAT_TIMESTAMP                    DATE

例: 孤立キー表の作成

次の例は、users表領域の孤立キー表の作成方法を示しています。

BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'ORPHAN_KEY_TABLE',
TABLE_TYPE => dbms_repair.orphan_table,
ACTION     => dbms_repair.create_action,
TABLESPACE => 'USERS');
END;
/

次の問合せでは、孤立キー表の定義を表示しています。

DESC ORPHAN_KEY_TABLE

Name                         Null?    Type
---------------------------- -------- -----------------
SCHEMA_NAME                  NOT NULL VARCHAR2(30)
INDEX_NAME                   NOT NULL VARCHAR2(30)
IPART_NAME                            VARCHAR2(30)
INDEX_ID                     NOT NULL NUMBER
TABLE_NAME                   NOT NULL VARCHAR2(30)
PART_NAME                             VARCHAR2(30)
TABLE_ID                     NOT NULL NUMBER
KEYROWID                     NOT NULL ROWID
KEY                          NOT NULL ROWID
DUMP_TIMESTAMP               NOT NULL DATE

例: 破損の検出

CHECK_OBJECTプロシージャは、指定されたオブジェクトをチェックし、破損および修復ディレクティブに関する情報を修復表に移入します。オブジェクトの一部をチェックする場合は、必要に応じて、範囲、パーティション名またはサブパーティション名を指定できます。

妥当性チェックでは、オブジェクト内部でそれまでに破損マークが付けられていないブロックがすべてチェックされます。ブロックごとに、トランザクションおよびデータ・レイヤー部分の自己整合性がチェックされます。CHECK_OBJECTの実行中に、破損バッファ・キャッシュ・ヘッダーを持つブロックが検出されると、そのブロックはスキップされます。

scott.dept表に対するCHECK_OBJECTプロシージャの実行例を次に示します。

SET SERVEROUTPUT ON
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'SCOTT',
OBJECT_NAME => 'DEPT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
CORRUPT_COUNT =>  num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;
/

SQL*Plusには、1つの破損を示す次の行が出力されます。

number corrupt: 1

修復表を問い合せると、破損の説明および修復アクションに関する提案を含む情報が表示されます。

SELECT OBJECT_NAME, BLOCK_ID, CORRUPT_TYPE, MARKED_CORRUPT,
CORRUPT_DESCRIPTION, REPAIR_DESCRIPTION
FROM REPAIR_TABLE;

OBJECT_NAME                      BLOCK_ID CORRUPT_TYPE MARKED_COR
------------------------------ ---------- ------------ ----------
CORRUPT_DESCRIPTION
------------------------------------------------------------------------------
REPAIR_DESCRIPTION
------------------------------------------------------------------------------
DEPT                                    3            1 FALSE
kdbchk: row locked by non-existent transaction
table=0   slot=0
lockid=32   ktbbhitc=1
mark block software corrupt

まだ破損ブロックに破損マークが付いていないため、ここで重要なデータを抽出します。ブロックに破損マークが付けられた後は、そのブロック全体がスキップされます。

例: 破損ブロックの修正

CHECK_OBJECTプロシージャによって生成した修復表内の情報に基づいて、FIX_CORRUPT_BLOCKSプロシージャを使用し、指定したオブジェクトの破損ブロックを修正します。ブロックの変更前には、そのブロックがまだ破損状態にあるかどうかが確認されます。破損ブロックは、そのブロックにソフトウェア破損のマークを付けることによって修復されます。修復が実行されると、修復表内の対応する行がタイムスタンプ付きで更新されます。

次の例では、CHECK_OBJECTプロシージャによってレポートされた表scott.deptの破損ブロックを修正しています。

SET SERVEROUTPUT ON
DECLARE num_fix INT;
BEGIN
num_fix := 0;
DBMS_REPAIR.FIX_CORRUPT_BLOCKS (
SCHEMA_NAME => 'SCOTT',
OBJECT_NAME=> 'DEPT',
OBJECT_TYPE => dbms_repair.table_object,
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
FIX_COUNT=> num_fix);
DBMS_OUTPUT.PUT_LINE('num fix: ' || TO_CHAR(num_fix));
END;
/

SQL*Plusでは次の行が出力されます。

num fix: 1

次の問合せによって、修復が完了していることが確認されます。

SELECT OBJECT_NAME, BLOCK_ID, MARKED_CORRUPT
FROM REPAIR_TABLE;

OBJECT_NAME                      BLOCK_ID MARKED_COR
------------------------------ ---------- ----------
DEPT                                    3 TRUE

例: 破損データ・ブロックを指す索引エントリの検索

DUMP_ORPHAN_KEYSプロシージャは、破損データ・ブロック内の行を指す索引エントリをレポートします。索引エントリごとに、指定した孤立キー表に1行ずつ挿入されます。この孤立キー表は、事前に作成しておく必要があります。

この情報は、表内の失われた行を再作成する場合や診断に使用します。

注意:
このプロシージャは、修復表で識別された表に対応付けられている索引ごとに実行する必要があります。

この例では、pk_deptはscott.dept表の索引です。これがスキャンされて、破損したデータ・ブロックの行を指す索引エントリがあるかどうかが見極められます。

SET SERVEROUTPUT ON
DECLARE num_orphans INT;
BEGIN
num_orphans := 0;
DBMS_REPAIR.DUMP_ORPHAN_KEYS (
SCHEMA_NAME => 'SCOTT',
OBJECT_NAME => 'PK_DEPT',
OBJECT_TYPE => dbms_repair.index_object,
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
ORPHAN_TABLE_NAME=> 'ORPHAN_KEY_TABLE',
KEY_COUNT => num_orphans);
DBMS_OUTPUT.PUT_LINE('orphan key count: ' || TO_CHAR(num_orphans));
END;
/

次の出力は、孤立キーが3つあることを示しています。

orphan key count: 3

孤立キー表の索引エントリは、索引の再作成が必要であることを示しています。索引の再作成により、表プローブと索引プローブが同じ結果セットを返すことが保証されます。

例: 破損ブロックのスキップ

SKIP_CORRUPT_BLOCKSプロシージャは、指定されたオブジェクトの索引および表のスキャン時に破損ブロックをスキップするかしないかを指定します。オブジェクトが表であれば、スキップは表とその索引に適用されます。オブジェクトがクラスタのときは、クラスタ内のすべての表およびその各索引に適用されます。

次の例では、scott.dept表のソフトウェア破損ブロックのスキップを可能に設定しています。

BEGIN
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (
SCHEMA_NAME => 'SCOTT',
OBJECT_NAME => 'DEPT',
OBJECT_TYPE => dbms_repair.table_object,
FLAGS => dbms_repair.skip_flag);
END;
/

DBA_TABLESビューを使用してscottの表を問い合せると、表scott.deptのSKIP_CORRUPTが使用可能になっていることが示されます。

SELECT OWNER, TABLE_NAME, SKIP_CORRUPT FROM DBA_TABLES
WHERE OWNER = 'SCOTT';

OWNER                          TABLE_NAME                     SKIP_COR
------------------------------ ------------------------------ --------
SCOTT                          ACCOUNT                        DISABLED
SCOTT                          BONUS                          DISABLED
SCOTT                          DEPT                           ENABLED
SCOTT                          DOCINDEX                       DISABLED
SCOTT                          EMP                            DISABLED
SCOTT                          RECEIPT                        DISABLED
SCOTT                          SALGRADE                       DISABLED
SCOTT                          SCOTT_EMP                      DISABLED
SCOTT                          SYS_IOT_OVER_12255             DISABLED
SCOTT                          WORK_AREA                      DISABLED

10 rows selected.

第IV部

データベース・リソースの管理とタスクのスケジューリング

第IV部では、自動データベース・メンテナンス・タスク、データベース・リソースの管理およびタスクのスケジューリングについて説明します。次の章で構成されます。

- 第26章「自動データベース・メンテナンス・タスクの管理」

- 第27章「Oracle Database Resource Managerを使用したリソースの管理」

- 第28章「Oracle Schedulerの概要」

- 第29章「Oracle Schedulerを使用したジョブのスケジューリング」

- 第30章「Oracle Schedulerの管理」

26 自動データベース・メンテナンス・タスクの管理

Oracle Databaseでは、データベース管理者が通常実行する一般的なメンテナンス・タスクのうちのいくつかが自動化されました。これらの自動化メンテナンス・タスクは、システムの負荷が軽いと予測される時間帯に実行されます。管理者は、個々のメンテナンス・タスクを有効または無効にしたり、これらのタスクの実行時期やタスクに対するリソース割当てを構成できます。

この章の内容は、次のとおりです。

- 自動化メンテナンス・タスクの概要

- メンテナンス・ウィンドウの概要

- 自動化メンテナンス・タスクの構成

- メンテナンス・ウィンドウの構成

- 自動化メンテナンス・タスクに対するリソース割当ての構成

- 自動化メンテナンス・タスクの参照情報

注意:
この章では、PL/SQLパッケージを使用して、自動化メンテナンス・タスクを管理する方法について説明します。簡単な方法として、Enterprise Managerのグラフィカル・インタフェースを使用する方法があります。
Enterprise Managerを使用して自動メンテナンス・タスクを管理する手順は、次のとおりです。

1. データベース・ホームページにアクセスします。
手順の詳細は、『Oracle Database 2日でデータベース管理者』またはOracle Enterprise Manager Grid Controlのオンライン・ヘルプを参照してください。

2. データベース・ホームページで、「サーバー」をクリックして「サーバー」ページを表示します。

3. 「Oracle Scheduler」セクションで、メンテナンス・タスクを構成する場合は「自動化メンテナンス・タスク」をクリックし、メンテナンス・ウィンドウを構成する場合は「ウィンドウ」をクリックします。

自動化メンテナンス・タスクの概要

自動化メンテナンス・タスクとは、データベースのメンテナンス操作を実行するために、一定の間隔をおいて自動的に開始されるタスクです。問合せオプティマイザのスキーマ・オブジェクトに関する統計を収集するタスクなどはその一例です。自動化メンテナンス・タスクはメンテナンス・ウィンドウで実行されますが、これはシステム負荷が低い時間に発生するように設定された事前定義済の時間間隔です。管理者は、データベースのリソース使用パターンに基づいてメンテナンス・ウィンドウをカスタマイズしたり、特定のデフォルト・ウィンドウでの実行を禁止できます。独自のメンテナンス・ウィンドウを作成することもできます。

Oracle Databaseでは、3種類の自動化メンテナンス・タスクが事前定義されています。

- 自動オプティマイザ統計収集: データベース内に統計がないか、古い統計のみがあるすべてのスキーマ・オブジェクトに関するオプティマイザ統計を収集します。このタスクで収集された統計は、SQLの実行パフォーマンスを改善するためにSQL問合せオプティマイザによって使用されます。

関連項目:
自動統計収集の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- 自動セグメント・アドバイザ: 再生可能な領域が存在しているセグメントを識別し、それらのセグメントの断片化を解消する方法について推奨事項を生成します。
セグメント・アドバイザを手動で実行すると、最新の推奨事項を取得したり、自動セグメント・アドバイザで再生可能な領域を調査しなかったセグメントについて推奨事項を取得することもできます。

関連項目:
詳細は、「セグメント・アドバイザの使用」を参照してください。

- 自動SQLチューニング・アドバイザ: 高負荷のSQL文のパフォーマンスを調査し、それらの文のチューニング方法について推奨事項を生成します。このアドバイザは、SQLプロファイルの推奨事項を自動的に実装するように構成できます。

関連項目:
SQLチューニング・アドバイザの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

デフォルトでは、これら3種類の自動化メンテナンス・タスクは、すべてのメンテナンス・ウィンドウで実行するように構成されています。

メンテナンス・ウィンドウの概要

メンテナンス・ウィンドウは、自動化メンテナンス・タスクが実行される連続した時間間隔です。メンテナンス・ウィンドウは、MAINTENANCE_WINDOW_GROUPという名前のウィンドウ・グループに属するOracle Schedulerウィンドウです。スケジューラのウィンドウは、単純な繰返し間隔(毎週土曜の午前0時から午前6時の間など)の場合や複雑な間隔(会社の休業日を除いて、毎月最後の稼働日の午前0時から午前6時の間など)の場合があります。

メンテナンス・ウィンドウがオープンすると、Oracle Databaseでは、そのウィンドウでの実行がスケジュールされている各メンテナンス・タスクに対してOracle Schedulerのジョブが作成されます。各ジョブには、実行時に生成されるジョブ名が割り当てられます。自動化メンテナンス・タスクのジョブ名はすべてORA$ATで始まります。たとえば、自動セグメント・アドバイザのジョブには、ORA$AT_SA_SPC_SY_26という名前が指定されます。自動化メンテナンス・タスクのジョブが終了すると、そのジョブはOracle Schedulerのジョブ・システムから削除されます。ただし、スケジューラのジョブ履歴には記録が残ります。

注意:
ジョブ履歴を表示するには、SYSユーザーでログインする必要があります。

非常に長いメンテナンス・ウィンドウの場合、自動SQLチューニング・アドバイザを除くすべての自動化メンテナンス・タスクは4時間ごとに再起動されます。この機能によって、ウィンドウ・サイズに関係なく、メンテナンス・タスクが定期的に実行されます。

自動化メンテナンス・タスクのフレームワークは、データベースに定義されているメンテナンス・ウィンドウに依存しています。表26-1に、新規Oracle Databaseの各インストールで自動的に定義されるメンテナンス・ウィンドウのリストを示します。

関連項目:

- ウィンドウとグループの詳細は、「ジョブおよびスケジューラ・オブジェクトのサポートの概要」を参照してください。

自動化メンテナンス・タスクの構成

メンテナンス・ウィンドウのサブセットで特定のメンテナンス・タスクを有効または無効にするには、DBMS_AUTO_TASK_ADMIN PL/SQLパッケージを使用します。

この項の内容は次のとおりです。

- すべてのメンテナンス・ウィンドウに対するメンテナンス・タスクの有効化と無効化

- 特定のメンテナンス・ウィンドウに対するメンテナンス・タスクの有効化と無効化

すべてのメンテナンス・ウィンドウに対するメンテナンス・タスクの有効化と無効化

管理者は、1回の操作ですべてのメンテナンス・ウィンドウに対して特定の自動化メンテナンス・タスクを無効にできます。無効にするには、DBMS_AUTO_TASK_ADMIN PL/SQLパッケージのDISABLEプロシージャをwindow_name引数なしでコールします。たとえば、次のプロシージャを使用して自動SQLチューニング・アドバイザ・タスクを完全に無効にできます。

BEGIN
dbms_auto_task_admin.disable(
client_name => 'sql tuning advisor',
operation   => NULL,
window_name => NULL);
END;
/

このメンテナンス・タスクを再度有効にするには、次のようにENABLEプロシージャを使用します。

BEGIN
dbms_auto_task_admin.enable(
client_name => 'sql tuning advisor',
operation   => NULL,
window_name => NULL);
END;
/

client_name引数に使用するタスク名は、DBA_AUTOTASK_CLIENTデータベース・ディクショナリ・ビューにリストされています。

すべてのウィンドウに対して自動化メンテナンス・タスクすべてを有効または無効にするには、引数を指定せずにENABLEまたはDISABLEプロシージャをコールします。

EXECUTE DBMS_AUTO_TASK_ADMIN.DISABLE;

関連項目:

- 「自動化メンテナンス・タスクのデータベース・ディクショナリ・ビュー」

- DBMS_AUTO_TASK_ADMIN PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

特定のメンテナンス・ウィンドウに対するメンテナンス・タスクの有効化と無効化

デフォルトでは、すべてのメンテナンス・タスクが事前定義のすべてのメンテナンス・ウィンドウで実行されます。管理者は、特定のウィンドウに対してメンテナンス・タスクを無効にできます。次の例は、ウィンドウMONDAY_WINDOWでの自動SQLチューニング・アドバイザの実行を無効にしています。

BEGIN
dbms_auto_task_admin.disable(
client_name => 'sql tuning advisor',
operation   => NULL,
window_name => 'MONDAY_WINDOW');
END;
/

メンテナンス・ウィンドウの構成

事前定義のメンテナンス・ウィンドウをデータベース環境に適した時間に調整したり、新しいメンテナンス・ウィンドウを作成できます。メンテナンス・ウィンドウは、DBMS_SCHEDULER PL/SQLパッケージを使用してカスタマイズできます。

この項の内容は次のとおりです。

- メンテナンス・ウィンドウの変更

- 新規メンテナンス・ウィンドウの作成

- メンテナンス・ウィンドウの削除

メンテナンス・ウィンドウの変更

DBMS_SCHEDULER PL/SQLパッケージには、ウィンドウの属性を変更するためのSET_ATTRIBUTEプロシージャが含まれています。たとえば、次のスクリプトは、メンテナンス・ウィンドウSATURDAY_WINDOWの期間を4時間に変更します。

BEGIN
dbms_scheduler.disable(
name  => 'SATURDAY_WINDOW');
dbms_scheduler.set_attribute(
name      => 'SATURDAY_WINDOW',
attribute => 'DURATION',
value     => numtodsinterval(4, 'hour'));
dbms_scheduler.enable(
name => 'SATURDAY_WINDOW');
END;
/

ウィンドウを変更する際は、事前にDBMS_SCHEDULER.DISABLEサブプログラムを使用してそのウィンドウを無効にし、終了した後にDBMS_SCHEDULER.ENABLEを使用して再度有効にする必要があります。現在オープン中のウィンドウを変更した場合は、そのウィンドウの次回オープンまで変更内容が反映されません。

関連項目:
ウィンドウの変更の詳細は、「ウィンドウを使用したジョブ・スケジューリングとジョブ優先度の管理」を参照してください。

新規メンテナンス・ウィンドウの作成

新規メンテナンス・ウィンドウを作成するには、Oracle Schedulerのウィンドウを作成して、ウィンドウ・グループMAINTENANCE_WINDOW_GROUPに追加する必要があります。DBMS_SCHEDULER.CREATE_WINDOWパッケージ・プロシージャを使用してウィンドウを作成し、DBMS_SCHEDULER.ADD_GROUP_MEMBERプロシージャを使用して、この新規ウィンドウをウィンドウ・グループに追加します。

次の例は、EARLY_MORNING_WINDOWという名前のメンテナンス・ウィンドウを作成しています。このウィンドウは、午前5時から午前6時まで毎日1時間実行されます。

BEGIN
dbms_scheduler.create_window(
window_name     => 'EARLY_MORNING_WINDOW',
duration        =>  numtodsinterval(1, 'hour'),
resource_plan   => 'DEFAULT_MAINTENANCE_PLAN',
repeat_interval => 'FREQ=DAILY;BYHOUR=5;BYMINUTE=0;BYSECOND=0');
dbms_scheduler.add_group_member(
group_name  => 'MAINTENANCE_WINDOW_GROUP',
member      => 'EARLY_MORNING_WINDOW');
END;
/

関連項目:

- 「ウィンドウの作成」

- DBMS_SCHEDULERパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

メンテナンス・ウィンドウの削除

既存のメンテナンス・ウィンドウを削除するには、MAINTENANCE_WINDOW_GROUPウィンドウ・グループから該当するウィンドウを削除します。ウィンドウは存在し続けますが、自動化メンテナンス・タスクは実行されません。このウィンドウに割り当てられているOracle Schedulerの他のジョブは、引き続き通常どおりに実行されます。

次の例は、ウィンドウ・グループからEARLY_MORNING_WINDOWを削除しています。

BEGIN
DBMS_SCHEDULER.REMOVE_GROUP_MEMBER(
group_name  => 'MAINTENANCE_WINDOW_GROUP',
member      => 'EARLY_MORNING_WINDOW');
END;
/

関連項目:

- 「ウィンドウ・グループからのメンバーの削除」

- 「ウィンドウの削除」

- DBMS_SCHEDULERパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

自動化メンテナンス・タスクに対するリソース割当ての構成

ここでは、メンテナンス・ウィンドウに対するリソース割当てについて説明します。この項の内容は、次のとおりです。

- 自動化メンテナンス・タスクに対するリソース割当ての概要

- 自動化メンテナンス・タスクに対するリソース割当ての変更

関連項目:
第27章「Oracle Database Resource Managerを使用したリソースの管理」

自動化メンテナンス・タスクに対するリソース割当ての概要

デフォルトでは、事前定義のすべてのメンテナンス・ウィンドウで、リソース・プランDEFAULT_MAINTENANCE_PLANが使用されます。自動化メンテナンス・タスクは、そのサブプランORA$AUTOTASK_SUB_PLANのもとで実行されます。このサブプランによって、リソース割当て合計に対する配分が複数のメンテナンス・タスク間に均一に分割されます。

DEFAULT_MAINTENANCE_PLANには、次のリソース割当てが定義されています。

コンシューマ・グループ/サブプラン

レベル1

レベル2

最大使用率の制限

ORA$AUTOTASK_SUB_PLAN

-

25%

90

ORA$DIAGNOSTICS

-

5%

90

OTHER_GROUPS

-

70%

SYS_GROUP

75%

-

このプランでは、SYS_GROUPコンシューマ・グループのセッションが優先されます。(このグループのセッションは、SYSおよびSYSTEMのユーザー・アカウントで作成されたセッションです。)SYS_GROUPのセッションで使用されないリソース割当ては、プランの他のコンシューマ・グループやサブプランに属するセッションによって共有されます。この割当てでは、25%がメンテナンス・タスクに、5%が診断操作を実行するバックグラウンド・プロセスに、70%がユーザー・セッションに割り当てられます。ORA$AUTOTASK_SUB_PLANおよびORA$DIAGNOSTICSの最大使用率の制限は90です。つまり、CPUがアイドル状態であっても、このグループ/プランにはCPUリソースの90%を超える値を割り当てることができません。

自動化メンテナンス・タスクに対するリソース割当てを増減するには、DEFAULT_MAINTENANCE_PLANを調整します。詳細は、「自動化メンテナンス・タスクに対するリソース割当ての変更」を参照してください。

リソース・プランと同様に、コンシューマ・グループまたはサブプランによって使用されていない割当て部分は、他のコンシューマ・グループまたはサブプランで使用できます。データベース・リソース・マネージャは、CPUの100%が使用されるまで、リソース・プランによるリソース割当ての制限を開始しません。

注意:
DEFAULT_MAINTENANCE_PLANはデフォルトですが、任意のリソース・プランを任意のメンテナンス・ウィンドウに割り当てることができます。メンテナンス・ウィンドウのリソース・プランを変更する場合は、サブプランORA$AUTOTASK_SUB_PLANおよびコンシューマ・グループORA$DIAGNOSTICSが新しいプランに含まれていることを確認してください。

関連項目:
リソース・プランの詳細は、第27章「Oracle Database Resource Managerを使用したリソースの管理」を参照してください。

自動化メンテナンス・タスクに対するリソース割当ての変更

メンテナンス・ウィンドウ内の自動化メンテナンス・タスクに対するリソース割当てを変更するには、そのウィンドウのリソース・プランのサブプランORA$AUTOTASK_SUB_PLANに割り当てられているリソースの割合を変更する必要があります。(デフォルトでは、事前定義の各メンテナンス・ウィンドウのリソース・プランはDEFAULT_MAINTENANCE_PLANです。)また、プランのトップレベルでのリソース割当てが100%になるように、ウィンドウのリソース・プランの1つ以上のサブプランまたはコンシューマ・グループに対するリソース割当てを調整する必要があります。リソース割当ての変更の詳細は、第27章「Oracle Database Resource Managerを使用したリソースの管理」を参照してください。

自動化メンテナンス・タスクの参照情報

ここでは、自動化メンテナンス・タスクについて説明します。この項の内容は、次のとおりです。

- 事前定義のメンテナンス・ウィンドウ

- 自動化メンテナンス・タスクのデータベース・ディクショナリ・ビュー

事前定義のメンテナンス・ウィンドウ

デフォルトでは、7種類のメンテナンス・ウィンドウが事前定義されており、それぞれが曜日を表します。週末のメンテナンス・ウィンドウであるSATURDAY_WINDOWとSUNDAY_WINDOWは、平日のメンテナンス・ウィンドウよりも期間が長くなっています。ウィンドウ・グループMAINTENANCE_WINDOW_GROUPは、この7種類のウィンドウで構成されています。表26-1に、事前定義のメンテナンス・ウィンドウのリストを示します。

表26-1 事前定義のメンテナンス・ウィンドウ

ウィンドウ名

説明

MONDAY_WINDOW

月曜の午後10時に開始して午前2時に終了します。

TUESDAY_WINDOW

火曜の午後10時に開始して午前2時に終了します。

WEDNESDAY_WINDOW

水曜の午後10時に開始して午前2時に終了します。

THURSDAY_WINDOW

木曜の午後10時に開始して午前2時に終了します。

FRIDAY_WINDOW

金曜の午後10時に開始して午前2時に終了します。

SATURDAY_WINDOW

土曜の午前6時に開始して20時間後に終了します。

SUNDAY_WINDOW

日曜の午前6時に開始して20時間後に終了します。

自動化メンテナンス・タスクのデータベース・ディクショナリ・ビュー

表26-2に、自動化メンテナンス・タスクのデータベース・ディクショナリ・ビューに関する情報を示します。

表26-2 自動化メンテナンス・タスクのデータベース・ディクショナリ・ビュー

ビュー名

説明

DBA_AUTOTASK_CLIENT_JOB

自動化メンテナンス・タスク用に作成され、現在実行中のスケジューラのジョブに関する情報が含まれます。また、これらのジョブのターゲット・オブジェクトだけでなく、同じタスクを以前にインスタンス化したときの付加的な統計に関する情報も示します。この付加的なデータの一部は、一般的なスケジューラ・ビューから取得されます。

DBA_AUTOTASK_CLIENT

7日間および30日間の各自動化メンテナンス・タスクに関する統計データが表示されます。

DBA_AUTOTASK_JOB_HISTORY

自動化メンテナンス・タスクのジョブ実行履歴がリストされます。ジョブの実行が終了すると、このビューにジョブが追加されます。

DBA_AUTOTASK_WINDOW_CLIENTS

MAINTENANCE_WINDOW_GROUPに属するウィンドウが、各メンテナンス・タスクのウィンドウの「有効」または「無効」ステータスとともにリストされます。主に、Enterprise Managerで使用されます。

DBA_AUTOTASK_CLIENT_HISTORY

各自動化メンテナンス・タスクのジョブ実行回数について、ウィンドウ別に履歴が表示されます。この情報は、Enterprise Managerの「ジョブ履歴」ページで確認できます。

関連項目:
ビューの列の詳細は、「リソース・マネージャのデータ・ディクショナリ・ビュー」を参照してください。

27 Oracle Database Resource Managerを使用したリソースの管理

この章の内容は、次のとおりです。

- Oracle Database Resource Managerの概要

- リソース・コンシューマ・グループへのセッションの割当て

- リソース・マネージャによって管理されるリソースのタイプ

- 単純なリソース・プランの作成

- 複雑なリソース・プランの作成

- Oracle Database Resource Managerの有効化とプランの切替え

- 各種の方法を組み合せたOracle Database Resource Managerの例

- 単一サーバーにおける複数のデータベース・インスタンスの管理

- コンシューマ・グループ、プランおよびディレクティブのメンテナンス

- データベース・リソース・マネージャの構成とステータスの表示

- Oracle Database Resource Managerの監視

- オペレーティング・システムのリソース制御との相互作用

- Oracle Database Resource Managerの参照情報

注意:
この章では、PL/SQLパッケージ・プロシージャを使用してリソース・マネージャを管理する方法について説明します。リソース・マネージャを管理する簡単な方法は、Enterprise Managerのグラフィカル・ユーザー・インタフェースを使用することです。Enterprise Managerを使用してリソース・マネージャを管理する手順については、『Oracle Database 2日でデータベース管理者』を参照してください。

Oracle Database Resource Managerの概要

Oracle Database Resource Manager (リソース・マネージャ)を使用すると、システム・リソースやデータベース・リソースを求めて競合するデータベース内の複数のワークロードを管理できます。

次の各項では、リソース・マネージャの概要を説明します。

- リソース・マネージャが提供するワークロード管理のソリューション

- リソース・マネージャの要素

- リソース・マネージャによって管理されるリソースのタイプ

- リソース・マネージャの管理権限の概要

リソース・マネージャが提供するワークロード管理のソリューション

データベース・リソースの割当てがオペレーティング・システムによって決定される場合は、次のようなワークロードの管理に関する問題が生じることがあります。

- 過剰なオーバーヘッドの発生
過剰なオーバーヘッドは、サーバー・プロセスの数が多いときに、Oracle Databaseサーバー・プロセス間でオペレーティング・システムのコンテキストが切り替わることによって発生します。

- 非効率的なスケジューリング
オペレーティング・システムは、データベース・サーバーがラッチを保持している間にデータベース・サーバーのスケジュールを解除しますが、これは非効率的です。

- 不適当なリソースの割当て
オペレーティング・システムはタスク間の優先度付けができないため、すべてのアクティブなプロセスの間で均等にリソースを分配します。

- パラレル実行サーバーやアクティブ・セッションなど、データベース固有のリソースを管理できない

リソース・マネージャは、ハードウェア・リソースの割当て方法をデータベースで厳密に制御することによって、これらの問題を克服します。複数のコンカレント・ユーザー・セッションがあり、各セッションでは異なる優先度のジョブが実行される環境では、すべてのセッションが同等に処理されるわけではありません。リソース・マネージャを使用すると、セッション属性に基づいてセッションを複数のグループに分類し、それらのグループに対して、アプリケーション環境のハードウェア利用が最適化されるようにリソースを配分できます。

リソース・マネージャを使用すると、次のことが可能になります。

- システムにかかる負荷やユーザー数に関係なく、特定のセッションのCPUが最小量になることを保証します。

- 様々なユーザーおよびアプリケーションに、比率を指定してCPU時間を割り当てて、使用可能なCPUを分配します。データ・ウェアハウスの場合は、バッチ・ジョブよりもリレーショナル・オンライン分析処理(ROLAP)アプリケーションへの割当て率を高くできます。

- ユーザー・グループのメンバーが実行する処理の並列度を制限します。

- パラレル・ステートメント・キュー内のパラレル・ステートメントの順序を管理します。優先度の低いユーザー・グループからのパラレル・ステートメントよりも前に、重要なアプリケーションからのパラレル・ステートメントをエンキューできます。

- ユーザー・グループが使用できるパラレル・サーバーの数を制限します。これにより、使用可能なすべてのパラレル・サーバーが1つのユーザー・グループにのみ割り当てられることを回避できます。

- アクティブ・セッション・プールを作成します。アクティブ・セッション・プールは、ユーザー・グループ内で同時にアクティブにできる指定された最大数のユーザー・セッションで構成されています。最大数を超える追加セッションは実行待ちのキューに送られますが、キューで待機しているジョブが終了するまでのタイムアウト周期を指定できます。アクティブ・セッション・プールによって、リソースについて実際に競合するセッションの総数が制限されるため、アクティブなセッションの進行を早めることができます。

- 次の方法でリソース集中型のセッションまたはコールを管理します。

- グループが使用できるCPUの割合に絶対的な制限を設けます。

- セッションまたはコールによって使用されるCPUまたはI/Oが指定量を超過している状況を検出することによって、自動的に、セッションまたはコールを終了するか、またはCPUの割当てが少ないコンシューマ・グループに切り替えます。これにより、実質的にリソース集中型のセッションまたはコールの影響を軽減します。

- ある操作に対するオプティマイザの見積り実行時間が指定された制限を超える場合は、その操作が実行されないようにします。

- セッションのアイドル時間を制限します。この制限は、他のセッションをブロックしているセッションのみに限定することもできます。

- ワークロード要件の変更に基づいて、データベースで様々なリソース・プランを使用できます。インスタンスを停止して再起動しなくても、たとえば、昼間のリソース・プランから夜間のリソース・プランに変更するなど、リソース・プランを動的に変更できます。リソース・プランの変更は、Oracle Schedulerを使用してスケジュールすることもできます。詳細は、第28章「Oracle Schedulerの概要」を参照してください。

リソース・マネージャの要素

次の表に、リソース・マネージャの要素を示します。

要素

説明

リソース・コンシューマ・グループ

リソースの要件に基づいてグループ化されたセッションのグループ。リソース・マネージャは、個々のセッションではなくリソース・コンシューマ・グループにリソースを割り当てます。

リソース・プラン

リソース・コンシューマ・グループへのリソースの割当て方法を指定するディレクティブのコンテナ。特定のリソース・プランをアクティブ化することで、データベースによるリソースの割当て方法を指定します。

リソース・プラン・ディレクティブ

リソース・コンシューマ・グループを特定のプランに関連付け、そのリソース・コンシューマ・グループに対するリソースの割当て方法を指定します。

これらの要素の作成とメンテナンスには、DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用します。要素は、データ・ディクショナリ内の表に格納されます。要素に関する情報は、データ・ディクショナリ・ビューを使用して表示できます。

関連項目:
「リソース・マネージャのデータ・ディクショナリ・ビュー」

リソース・コンシューマ・グループの概要

リソース・コンシューマ・グループ(コンシューマ・グループ)とは、処理要件に基づいてグループ化されたユーザー・セッションの集合です。セッションが作成されると、そのセッションは、管理者が設定したマッピング・ルールに基づいてコンシューマ・グループに自動的にマップされます。データベース管理者(DBA)は、セッションを、異なるコンシューマ・グループに手動で切り替えることができます。同様に、アプリケーションでは、そのセッションを特定のコンシューマ・グループに切り替えるPL/SQLパッケージ・プロシージャを実行できます。

リソース・マネージャによるリソース(CPUなど)の割当て先は、コンシューマ・グループのみであるため、セッションがコンシューマ・グループのメンバーになると、そのリソース割当ては、コンシューマ・グループの割当てによって決定されます。

常にデータ・ディクショナリに存在する特別なコンシューマ・グループがあります。これらのグループは、変更したり削除することはできません。これらを次に示します。

- SYS_GROUP
これは、ユーザー・アカウントSYSまたはSYSTEMによって作成されたすべてのセッションの初期コンシューマ・グループです。この初期コンシューマ・グループは、コンシューマ・グループへのセッションのマッピング・ルールで上書きできます。

- OTHER_GROUPS
このコンシューマ・グループには、コンシューマ・グループに割り当てられていないすべてのセッションが含まれます。すべてのリソース・プランにOTHER_GROUPSへのディレクティブが含まれている必要があります。

関連項目:

- 表27-5 事前定義のリソース・コンシューマ・グループ

- 「コンシューマ・グループへのセッションのマッピング・ルールの指定」

リソース・プラン・ディレクティブの概要

リソース・マネージャは、現在アクティブなリソース・プランに属するリソース・プラン・ディレクティブ(ディレクティブ)のセットに従って、リソースをコンシューマ・グループに割り当てます。リソース・プランとそのリソース・プラン・ディレクティブは親子関係にあります。各ディレクティブは1つのコンシューマ・グループを参照し、現在アクティブなプランの2つのディレクティブで同じコンシューマ・グループを参照することはできません。

ディレクティブには、コンシューマ・グループへのリソース割当てを制限できる複数の方法があります。たとえば、CPUにおいてコンシューマ・グループが確保できるCPU全体の割合を制御したり、コンシューマ・グループ内でアクティブにできるセッションの総数を制限できます。詳細は、「リソース・マネージャによって管理されるリソースのタイプ」を参照してください。

リソース・プランの概要

各Oracle Databaseに事前定義されているリソース・プランの他に、リソース・プランは必要な数だけ作成できます。ただし、1度にアクティブにできるリソース・プランは1つのみです。リソース・プランがアクティブな場合は、その子の各リソース・プラン・ディレクティブが異なるコンシューマ・グループへのリソース割当てを制御します。各プランには、OTHER_GROUPSというコンシューマ・グループにリソースを割り当てるディレクティブが必要です。OTHER_GROUPSは、現在アクティブなプランの一部でないコンシューマ・グループに属しているすべてのセッションに適用されます。

注意:
「リソース・プラン」(または単に「プラン」)という用語はリソース・マネージャの1つの要素を示しますが、この章では、完全なリソース・プラン・スキーマ(リソース・プランの要素そのもの、そのリソース・プラン・ディレクティブ、ディレクティブによって参照されるコンシューマ・グループなど)を指す場合にも使用します。たとえば、この章でDAYTIMEリソース・プランに触れたときは、DAYTIMEというリソース・プラン要素を意味する場合も、DAYTIMEリソース・プランとそのディレクティブが定義する特定のリソース割当てスキーマを意味する場合もあります。したがって、簡潔に言えば、「DAYTIMEプランは、バッチ・アプリケーションよりも対話型アプリケーションに近い」といえます。

例: 単純なリソース・プラン

図27-1は、日中にオンライン・トランザクション処理(OLTP)アプリケーションとレポート・アプリケーションを同時に実行する組織の単純なリソース・プランを示しています。現在アクティブなプランDAYTIMEによって、3つのリソース・コンシューマ・グループにCPUリソースが割り当てられます。具体的には、CPUタイムの75%がOLTPに、15%がREPORTSに、残りの10%がOTHER_GROUPSに割り当てられています。

図27-1 単純なリソース・プラン

Oracle Databaseには、単純なリソース・プランを迅速に作成できるプロシージャ(CREATE_SIMPLE_PLAN)が用意されています。このプロシージャについては、「単純なリソース・プランの作成」を参照してください。

注意:
現在アクティブなリソース・プランは、CPU使用率が100%になるまで割当てを規定しません。CPU使用率が100%未満の場合、データベースはCPUによる制限を受けないため、すべてのセッションが必要なリソース割当てを獲得できるように割当てを規定する必要はありません。
さらに、割当てが規定されている場合は、あるコンシューマ・グループが使用していない割当てを、他のコンシューマ・グループが使用できます。前述の例では、OLTPグループが割当てをすべて使用していない場合、リソース・マネージャは、REPORTSグループまたはOTHER_GROUPSグループが、未使用の割当てを使用することを許可します。

サブプランの概要

リソース・プラン・ディレクティブ(ディレクティブ)は、コンシューマ・グループを参照するかわりに、別のリソース・プランを参照できます。この場合、そのプランはサブプランと呼ばれます。サブプラン自体に、リソースをコンシューマ・グループと他のサブプランに割り当てるディレクティブがあります。その場合、リソースの割当て方式は次のように機能します。トップレベルのリソース・プラン(現在アクティブなプラン)によって、リソースがコンシューマ・グループおよびサブプランに分割されます。次に、各サブプランによって、リソース割当て合計の一部がそのコンシューマ・グループとサブプランに割り当てられます。階層的なプランは、必要な数のサブプランを使用して作成できます。

リソース・サブプランは、リソース・プランを作成する方法と同じ方法で作成します。サブプランとしてのみ使用されるプランを作成するには、パッケージ・プロシージャDBMS_RESOURCE_MANAGER.CREATE_PLANでSUB_PLAN引数を使用します。

トップレベルのプランでは、サブプランを1回のみ参照できます。サブプランは、OTHER_GROUPSへのディレクティブを必要とせず、リソース・プランとして設定できません。

例: サブプランを含むリソース・プラン

この例では、Great Bread Companyによって、CPUリソースが図27-2のように割り当てられています。この図は、トップレベルのプラン(GREAT_BREAD)とその子すべてを示しています。わかりやすくするために、OTHER_GROUPSコンシューマ・グループを指定する要件は無視し、リソース・プラン・ディレクティブは(プランの一部であっても)省略されています。かわりに、ディレクティブが割り当てるCPUの比率を、プラン、サブプランおよびコンシューマ・グループ間を結ぶ線に沿って表示しています。

図27-2 サブプランを含むリソース・プラン

このGREAT_BREADプランでは、次のようにリソースを割り当てます。

- CPUリソースの20%をコンシューマ・グループMARKETに割り当てます。

- CPUリソースの60%をサブプランSALES_TEAMに割り当てます。このサブプランでは、リソースがWHOLESALEコンシューマ・グループとRETAILコンシューマ・グループ間で均等に分割されます。

- CPUリソースの20%をサブプランDEVELOP_TEAMに割り当てます。このサブプランでは、リソースがBREADコンシューマ・グループとMUFFINコンシューマ・グループ間で均等に分割されます。

サブプランまたはコンシューマ・グループは、複数の親を持つ場合があります。たとえば、MARKETグループがSALES_TEAMサブプランに含まれていた場合です。ただし、プラン内でループすることはできません。たとえば、SALES_TEAMサブプランには、GREAT_BREADプランを参照するディレクティブを設定できません。

関連項目:
複雑なリソース・プランの例は、「各種の方法を組み合せたOracle Database Resource Managerの例」を参照してください。

リソース・マネージャの管理権限の概要

リソース・マネージャを管理するには、システム権限ADMINISTER_RESOURCE_MANAGERが必要です。この権限(ADMINオプション付き)は、DBAロールを介してデータベース管理者に付与されます。

リソース・マネージャの管理者は、DBMS_RESOURCE_MANAGER PL/SQLパッケージ内のすべてのプロシージャを実行できます。

ADMINオプションを持つ管理者は、必要に応じて管理権限を他のユーザーまたはロールに付与できます。そうするには、DBMS_RESOURCE_MANAGER_PRIVS PL/SQLパッケージを使用します。次の表に、関連するパッケージ・プロシージャの一覧を示します。

プロシージャ

説明

GRANT_SYSTEM_PRIVILEGE

ユーザーまたはロールに、ADMINISTER_RESOURCE_MANAGERシステム権限を付与します。

REVOKE_SYSTEM_PRIVILEGE

ユーザーまたはロールから、ADMINISTER_RESOURCE_MANAGERシステム権限を取り消します。

次のPL/SQLブロックは、ユーザーHRに管理権限を付与しますが、HRにADMINオプションは付与しません。そのため、HRはDBMS_RESOURCE_MANAGERパッケージのすべてのプロシージャを実行できますが、HRはGRANT_SYSTEM_PRIVILEGEプロシージャを使用して他のユーザーに管理権限を付与することはできません。

BEGIN
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE(
GRANTEE_NAME   => 'HR',
PRIVILEGE_NAME => 'ADMINISTER_RESOURCE_MANAGER',
ADMIN_OPTION   => FALSE);
END;
/

この権限は、REVOKE_SYSTEM_PRIVILEGEプロシージャを使用して取り消すことができます。

注意:
ADMINISTER_RESOURCE_MANAGERシステム権限の付与または取消しは、DBMS_RESOURCE_MANAGER_PRIVSパッケージを使用する場合のみ行うことができます。SQLのGRANT文またはREVOKE文によって、付与したり取り消すことはできません。

関連項目:
リソース・マネージャのパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- DBMS_RESOURCE_MANAGER

- DBMS_RESOURCE_MANAGER_PRIVS

『Oracle Databaseセキュリティ・ガイド』では、ADMINオプションについて説明しています。

リソース・コンシューマ・グループへのセッションの割当て

ここでは、データベース管理者、ユーザーおよびアプリケーションがセッションをリソース・コンシューマ・グループに割り当てる際に使用できる自動および手動の方法について説明します。セッションがリソース・コンシューマ・グループに割り当てられると、Oracle Database Resource Manager(リソース・マネージャ)では、そのセッションに対するリソース割当てが管理の対象となります。

注意:
コンシューマ・グループに割り当てられていないセッションは、コンシューマ・グループOTHER_GROUPSに配置されます。

この項の内容は次のとおりです。

- リソース・コンシューマ・グループへのセッション割当ての概要

- 初期リソース・コンシューマ・グループの割当て

- コンシューマ・グループへのセッションのマッピング・ルールの指定

- リソース・コンシューマ・グループの切替え

- リソース・コンシューマ・グループの自動切替えの指定

- スイッチ特権の付与と取消し

リソース・コンシューマ・グループへのセッション割当ての概要

リソース・マネージャを有効にする前に、ユーザー・セッションをリソース・コンシューマ・グループに割り当てる方法を指定する必要があります。これを行うために、マッピング・ルールを作成すると、セッションの起動時に、セッション属性に基づいてリソース・マネージャによって自動的に各セッションがコンシューマ・グループに割り当てられるようにすることができます。セッションがその初期コンシューマ・グループに割り当てられ実行された後は、プロシージャをコールして、セッションを別のコンシューマ・グループに手動で切り替えることができます。この操作は、リソースを過剰に使用しているセッションを、よりリソース割当ての制限されたコンシューマ・グループに移動する必要がある場合などに実行します。また、ユーザーおよびアプリケーションにスイッチ特権を付与して、ユーザーおよびアプリケーションが、あるコンシューマ・グループから別のコンシューマ・グループに自分のセッションを切り替えることができるようにすることができます。

セッション属性に変更がある場合やセッションが指定のリソース使用制限を超える場合は、あるコンシューマ・グループから別の(通常は優先度の低い)コンシューマ・グループにセッションを自動的に切り替えることもできます。

初期リソース・コンシューマ・グループの割当て

セッションの初期コンシューマ・グループは、管理者が構成するマッピング・ルールによって決まります。マッピング・ルールの構成方法は、「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照してください。

コンシューマ・グループへのセッションのマッピング・ルールの指定

ここでは、コンシューマ・グループへのセッションのマッピング・ルールに関するバックグラウンド情報を提供し、ルールの作成方法と優先度の設定方法について説明します。この章では、次の項目について説明します。

- コンシューマ・グループへのセッションのマッピング・ルールの概要

- コンシューマ・グループのマッピング・ルールの作成

- コンシューマ・グループのマッピング・ルールの変更と削除

- マッピング・ルールの優先度の作成

コンシューマ・グループへのセッションのマッピング・ルールの概要

コンシューマ・グループへのセッションのマッピング・ルールを作成すると、次のことができます。

- セッションの初期コンシューマ・グループをセッション属性に基づいて指定できます。

- リソース・マネージャを使用して、実行中のセッションをセッション属性の変更に基づいて別のコンシューマ・グループに動的に切り替えることができます。

このマッピング・ルールは、セッション属性(ユーザー名、セッションがデータベースへの接続に使用したサービス、クライアント・プログラムの名前など)に基づいています。

マッピング・ルール間の競合を解決するために、リソース・マネージャでは、各ルールが優先度別に順序付けされます。たとえば、ユーザーSCOTTがSALESサービスを使用してデータベースに接続すると仮定します。あるマッピング・ルールには、ユーザーSCOTTがMED_PRIORITYコンシューマ・グループで起動することが記載され、別のルールには、SALESサービスに接続するセッションはHIGH_PRIORITYコンシューマ・グループで起動することが記載されている場合、この競合は、マッピング・ルールの優先度によって解決されます。

マッピング・ルールの基本となるセッション属性には、ログイン属性とランタイム属性の2つのタイプがあります。ログイン属性が有効なのは、セッションのログイン時、つまり、リソース・マネージャによってセッションの初期コンシューマ・グループが決定されるときのみです。ランタイム属性は、セッションのログイン中とログイン後に適用されます。ランタイム属性のいずれかを変更することによって、ログイン済セッションを別のコンシューマ・グループに再割当てできます。

コンシューマ・グループへのセッションの自動割当てを構成するには、SET_CONSUMER_GROUP_MAPPINGおよびSET_CONSUMER_GROUP_MAPPING_PRIプロシージャを使用します。これらのプロシージャに対してはペンディング・エリアを使用する必要があります。(ペンディング・エリアを作成してプロシージャを実行し、必要に応じてペンディング・エリアの妥当性をチェックしてから、そのペンディング・エリアを発行する必要があります。ペンディング・エリアの使用例は、「複雑なリソース・プランの作成」を参照してください。)

セッションは、マッピング・ルールを介して様々な時点で特定のコンシューマ・グループに自動的に切り替えられます。

- 最初のセッションのログイン時には、マッピング・ルールが評価されてそのセッションの初期グループが判別されます。

- セッション属性が新しい値に動的に変更されると(可能性があるのはランタイム属性のみ)、マッピング・ルールが再評価され、セッションが別のコンシューマ・グループに切り替わる場合があります。

事前定義のコンシューマ・グループ・マッピング・ルール

各Oracle Databaseには、事前定義のコンシューマ・グループ・マッピング・ルールのセットがあります。

- 「リソース・コンシューマ・グループの概要」で説明したように、ユーザー・アカウントSYSまたはSYSTEMによって作成されたすべてのセッションは、最初にSYS_GROUPコンシューマ・グループにマップされます。

- データ・ポンプを使用してデータ・ロードを実行するセッションまたはRMANを使用してバックアップまたはコピー操作を実行するセッションは、表27-6で指定されている事前定義のコンシューマ・グループに自動的にマップされます。

DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPINGプロシージャを使用して、これらの事前定義のマッピング・ルールを変更または削除できます。

関連項目:

- 「初期リソース・コンシューマ・グループの割当て」

- 「マッピング・ルールを使用した自動切替えの指定」

コンシューマ・グループのマッピング・ルールの作成

セッション属性と値のペアをコンシューマ・グループにマップするには、SET_CONSUMER_GROUP_MAPPINGプロシージャを使用します。このプロシージャのパラメータは、次のとおりです。

パラメータ

説明

ATTRIBUTE

セッション属性タイプ。パッケージ定数として指定されています。

VALUE

属性の値。

CONSUMER_GROUP

この属性と値のペアのマッピング先のコンシューマ・グループ。

ATTRIBUTEには、次のいずれかを指定できます。

属性

タイプ

説明

ORACLE_USER

ログイン

Oracle Databaseユーザー名。

SERVICE_NAME

ログイン

クライアントが接続の確立に使用したデータベース・サービス名。

CLIENT_OS_USER

ログイン

ログインしているクライアントのオペレーティング・システム・ユーザー名。

CLIENT_PROGRAM

ログイン

サーバーへのログインに使用されたクライアント・プログラム名。

CLIENT_MACHINE

ログイン

クライアントが接続に使用しているコンピュータ名。

CLIENT_ID

ログイン

セッションのクライアント識別子
クライアント識別子のセッション属性は、DBMS_SESSION.SET_IDENTIFIERプロシージャで設定します。

MODULE_NAME

ランタイム

DBMS_APPLICATION_INFO.SET_MODULEプロシージャによる設定、またはそれに相当するOCI属性の設定に従って現在実行されているアプリケーション内のモジュール名。

MODULE_NAME_ACTION

ランタイム

次のプロシージャのいずれかによる設定、またはそれに相当するOCI属性の設定に従って実行されている現行モジュールと処理の組合せ。

- DBMS_APPLICATION_INFO.SET_MODULE

- DBMS_APPLICATION_INFO.SET_ACTION

この属性にはモジュール名を指定し、その後ろにピリオド(.)および処理名を順に続けます(module_name.action_name)。

SERVICE_MODULE

ランタイム

service_name.module_nameの書式によるサービス名およびモジュール名の組合せ。

SERVICE_MODULE_ACTION

ランタイム

service_name.module_name.action_nameの書式によるサービス名、モジュール名および処理名の組合せ。

ORACLE_FUNCTION

ランタイム

RMANまたはデータ・ポンプ操作。有効な値はDATALOAD、BACKUPおよびCOPYです。これらの値それぞれに事前定義のマッピングがあります。セッションでこれらの機能のいずれかを実行している場合、事前定義のコンシューマ・グループに自動的にマップされます。詳細は、表27-6を参照してください。

たとえば、次のPL/SQLブロックでは、ログインするたびに、ユーザーSCOTTがDEV_GROUPコンシューマ・グループにマップされます。

BEGIN
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(DBMS_RESOURCE_MANAGER.ORACLE_USER, 'SCOTT', 'DEV_GROUP');
END;
/

この場合も、SET_CONSUMER_GROUP_MAPPINGプロシージャを実行する前にペンディング・エリアを作成する必要があります。

SET_CONSUMER_GROUP_MAPPINGプロシージャではvalueパラメータでほとんどの属性の値に対してワイルドカードを使用できます。ワイルドカードを使用して値を指定するには、SQLのLIKE演算子と同じセマンティクスを使用します。具体的には、ワイルドカードは次のセマンティクスを使用します。

- %は、複数文字のワイルドカード

- _は、1文字のワイルドカード

- \は、ワイルドカードをエスケープする

ワイルドカードが使用できるのは、属性が次のいずれかの場合のみです。

- CLIENT_OS_USER

- CLIENT_PROGRAM

- CLIENT_MACHINE

- MODULE_NAME

- MODULE_NAME_ACTION

- SERVICE_MODULE

- SERVICE_MODULE_ACTION

コンシューマ・グループのマッピング・ルールの変更と削除

コンシューマ・グループ・マッピング・ルールを変更するには、必要な属性と値のペアに対してSET_CONSUMER_GROUP_MAPPINGプロシージャを実行し、新しいコンシューマ・グループを指定します。ルールを削除するには、必要な属性と値のペアに対してSET_CONSUMER_GROUP_MAPPINGプロシージャを実行し、NULLのコンシューマ・グループを指定します。

マッピング・ルールの優先度の作成

競合するマッピング・ルールを解決するために、最も高い重要度のセッション属性から最も低いセッション属性まで優先度を設定できます。各属性に、1(最も高い重要度)から12(最も低い重要度)の一意の整数を設定するには、SET_CONSUMER_GROUP_MAPPING_PRIプロシージャを使用します。次の例は、この優先度の設定方法を示しています。

BEGIN
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING_PRI(
EXPLICIT => 1,
SERVICE_MODULE_ACTION => 2,
SERVICE_MODULE => 3,
MODULE_NAME_ACTION => 4,
MODULE_NAME => 5,
SERVICE_NAME => 6,
ORACLE_USER => 7,
CLIENT_PROGRAM => 8,
CLIENT_OS_USER => 9,
CLIENT_MACHINE => 10,
CLIENT_ID => 11);
END;
/

この例では、データベース・ユーザー名の優先度は7(重要度が低い)に設定され、モジュール名の優先度は5(重要度が高い)に設定されています。

注意:
SET_CONSUMER_GROUP_MAPPING_PRIでは、疑似属性EXPLICITを引数として含める必要があります。これは、1に設定する必要があります。これは、明示的なコンシューマ・グループの切替えに最も高い優先度が指定されていることを示します。『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』で詳細に説明されている次のパッケージ・プロシージャを使用して、コンシューマ・グループを明示的に切り替えます。

- DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP

- DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS

- DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER

マッピング・ルールの優先度がどのように機能するかを示すために、引き続き前の例を使用して、DEV_GROUPコンシューマ・グループへのユーザーSCOTTのマッピングの他に、次のようなモジュール名のマッピング・ルールがあると仮定します。

BEGIN
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(DBMS_RESOURCE_MANAGER.MODULE_NAME, 'EOD_REPORTS', 'LOW_PRIORITY');
END;
/

ユーザーSCOTTのセッションのアプリケーションによって、モジュール名がEOD_REPORTSに設定された場合、そのセッションはLOW_PRIORITYコンシューマ・グループに再割当てされます。これは、モジュール名マッピングの方が、データベース・ユーザー・マッピングより優先度が高いためです。

セッション属性の現在の優先度を確認するには、ビューDBA_RSRC_MAPPING_PRIORITYを問い合せます。

認可されていないクライアントがそのセッション属性を設定して優先度の高いコンシューマ・グループにクライアント自身をマッピングしないように、コンシューマ・グループに対してユーザー・スイッチ特権が適用されます。したがって、特定のセッションの属性がマッピング・ペアと一致した場合でも、指定したコンシューマ・グループに対するスイッチ特権がそのセッションに付与されていない場合は、そのマッピング・ルールは無視されます。

関連項目:

- DBMS_APPLICATION_INFO.SET_MODULEプロシージャによるモジュール名の設定の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 「スイッチ特権の付与と取消し」

リソース・コンシューマ・グループの切替え

この項では、セッションのリソース・コンシューマ・グループを切り替える方法について説明します。

この項の内容は次のとおりです。

- 手動によるリソース・コンシューマ・グループの切替え

- ユーザーまたはアプリケーションに対する手動によるコンシューマ・グループの切替えの有効化

手動によるリソース・コンシューマ・グループの切替え

DBMS_RESOURCE_MANAGER PL/SQLパッケージには、管理者が実行中のセッションのリソース・コンシューマ・グループを変更できるように、2つのプロシージャが用意されています。この2つのプロシージャでは、コーディネータのセッションに対応付けられたパラレル実行サーバー・セッションのコンシューマ・グループも変更できます。これらのプロシージャで行った変更は永続的ではなく、現行セッションのみに影響します。ユーザーの初期コンシューマ・グループも変更されません。

あるユーザーがCPUを過剰に使用している場合は、そのユーザーのセッションを停止(終了)するかわりに、ユーザーのコンシューマ・グループをリソースの割当てが低いグループに変更できます。

単一のセッションの切替え

SWITCH_CONSUMER_GROUP_FOR_SESSプロシージャは、指定したセッションを、指定したリソース・コンシューマ・グループに即時に移動します。このプロシージャを使用すると、セッションの優先度を実質的に変更できます。

次のPL/SQLブロックは、特定のセッションを新しいコンシューマ・グループに切り替えます。セッション識別子(SID)は17、セッション・シリアル番号(SERIAL#)は12345、新しいコンシューマ・グループはHIGH_PRIORITYコンシューマ・グループです。

BEGIN
DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS ('17', '12345',
'HIGH_PRIORITY');
END;
/

SID、セッション・シリアル番号、およびセッションの現行リソース・コンシューマ・グループは、V$SESSIONビューを使用して確認できます。

関連項目:
V$SESSIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ユーザーの全セッションの切替え

SWITCH_CONSUMER_GROUP_FOR_USERプロシージャは、指定したユーザー名に関連するすべてのセッションのリソース・コンシューマ・グループを変更します。次のPL/SQLブロックは、ユーザーHRに属しているすべてのセッションをLOW_GROUPコンシューマ・グループに切り替えます。

BEGIN
DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER ('HR',
'LOW_GROUP');
END;
/

ユーザーまたはアプリケーションに対する手動によるコンシューマ・グループの切替えの有効化

管理者は、ユーザーがDBMS_SESSIONパッケージのSWITCH_CURRENT_CONSUMER_GROUPプロシージャを使用して、現在のコンシューマ・グループを切り替えられるように、スイッチ特権をユーザーに付与できます。ユーザーが対話型セッション(SQL*Plusなど)でこのプロシージャを実行するか、アプリケーションでこのプロシージャをコールすることで、セッションを切り替え、実質的にその優先度を動的に変更できます。

ユーザーは、SWITCH_CURRENT_CONSUMER_GROUPプロシージャを使用して、スイッチ特権があるコンシューマ・グループにのみ切り替えることができます。他のプロシージャからこのプロシージャがコールされた場合、ユーザーはコール側のプロシージャの所有者がスイッチ特権を持っているコンシューマ・グループに切り替えることができます。

このプロシージャのパラメータは、次のとおりです。

パラメータ

説明

NEW_CONSUMER_GROUP

切替え先のコンシューマ・グループ。

OLD_CONSUMER_GROUP

切替え元のコンシューマ・グループの名前が戻ります。このパラメータは、後で元のコンシューマ・グループに再び切り替えるときに使用できます。

INITIAL_GROUP_ON_ERROR

切替えエラー発生時の動作を制御します。
TRUEに設定すると、エラーが発生した場合にユーザーは初期コンシューマ・グループに切り替わります。

FALSEの場合は、そのままエラーが出力されます。

次のSQL*Plusセッションは、新しいコンシューマ・グループへの切替え方法を示しています。出力パラメータold_groupの値が出力されているため、変更前のコンシューマ・グループ名がどのように保存されているかがわかります。

SET serveroutput on
DECLARE
old_group varchar2(30);
BEGIN
DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP('BATCH_GROUP', old_group, FALSE);
DBMS_OUTPUT.PUT_LINE('OLD GROUP = ' || old_group);
END;
/

次の行が出力されます。

OLD GROUP = OLTP_GROUP

リソース・マネージャでは、セッションをすでに配置されているコンシューマ・グループに切り替えるためにSWITCH_CURRENT_CONSUMER_GROUPプロシージャがコールされている場合でも、切替えが発生したとみなされます。

注意:
リソース・マネージャは、一般的なデータベース・ユーザー名を使用してアプリケーションにログインしている環境でも機能します。DBMS_SESSIONパッケージは、セッションの開始時、または特定のモジュールがコールされたときにセッションのコンシューマ・グループ割当てを切り替えるために使用できます。

関連項目:
DBMS_SESSIONパッケージのその他の例と詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

リソース・コンシューマ・グループの自動切替えの指定

特定の条件を満たしたときに、セッションを別のコンシューマ・グループに自動的に切り替えるように、リソース・マネージャを構成できます。自動切替えは、次の場合に実行されます。

- セッション属性が変更され、新しいマッピング・ルールが有効になった場合。

- セッションが、そのコンシューマ・グループに設定されているCPUまたはI/Oリソースの使用制限を超えた場合。

この項の内容は、次のとおりです。

- マッピング・ルールを使用した自動切替えの指定

- リソース制限の設定による自動切替えの指定

マッピング・ルールを使用した自動切替えの指定

セッションの実行中にセッション属性が変更されると、コンシューマ・グループへのセッションのマッピング・ルールが再評価されます。新しいルールが有効になると、セッションが別のコンシューマ・グループに移動されることがあります。詳細は、「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照してください。

リソース制限の設定による自動切替えの指定

ここでは、指定された制限を超えるCPUリソースまたはI/Oリソースを使用する、リソース集中型のセッションまたはコールの管理について説明します。リソース集中型のセッションはSQL問合せ、リソース集中型のコールはPL/SQLコールです。

コンシューマ・グループに対してリソース・プラン・ディレクティブを作成する場合は、そのグループのセッションに対してCPUおよびI/Oリソースの使用制限を指定できます。その後、セッション内の単一のコールが制限のいずれかを超過した場合に実行する処理を指定できます。次のような処理が考えられます。

- セッションを指定のコンシューマ・グループに動的に切り替えます。
通常、ターゲット・コンシューマ・グループは、より低いリソース割当てのコンシューマ・グループです。セッションのユーザーは、新しいコンシューマ・グループに対するスイッチ特権を持っている必要があり、持っていない場合は切替えを行えません。詳細は、「スイッチ特権の付与と取消し」を参照してください。

- セッションを停止(終了)します。

- セッションの現行のSQL文を中止します。

このタイプのセッション自動切替えに関連するリソース・プラン・ディレクティブの属性は、次のとおりです。

- SWITCH_GROUP

- SWITCH_TIME

- SWITCH_ESTIMATE

- SWITCH_IO_MEGABYTES

- SWITCH_IO_REQS

- SWITCH_FOR_CALL

これらの属性の詳細は、「リソース・プラン・ディレクティブの作成」を参照してください。

切替えは、実行中でリソースを使用しているセッション(ユーザー入力またはCPUサイクルを待機中でないセッション)に対して行われます。セッションが切り替えられた後は、アイドル状態になるまでターゲット・コンシューマ・グループで継続され、アイドル状態になると、元のコンシューマ・グループに切替えが戻されます。ただし、SWITCH_FOR_CALLがTRUEに設定されている場合、リソース・マネージャは、セッションがアイドル状態になるまで待機して元のリソース・コンシューマ・グループにセッションを戻す処理を行いません。かわりに、現在のトップレベルのコールが完了すると、セッションは戻されます。PL/SQLの場合、トップレベルのコールは、1つのコールとして処理されるPL/SQLブロック全体です。SQLの場合、トップレベルのコールは、個々のSQL文です。

リソース・マネージャは、コールの間隔が一定の時間を超えたセッションをアイドル状態とみなします。この時間間隔は設定できません。

SWITCH_FOR_CALLは、中間層のサーバーがセッション・プーリングを使用している3層アプリケーションの場合に有効です。

新しいグループのアクティブ・セッション・プールが一杯の場合も、切り替えたセッションは引き続き実行できます。このような状況では、コンシューマ・グループは、アクティブ・セッション・プールで指定された数より多いセッションを実行できます。

次に、リソース制限に基づいた自動切替えの例を示します。

例1

次のPL/SQLブロックはOLTPグループのリソース・プラン・ディレクティブを作成し、そのディレクティブはセッション内のコールのCPU時間が5秒を超えるとそのグループのすべてのセッションをLOW_GROUPコンシューマ・グループに切り替えます。この例は、予想外に時間がかかる問合せによって過剰なリソースが使用されないようにします。通常、切替え先のコンシューマ・グループは、より低いリソース割当てのコンシューマ・グループです。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN             => 'DAYTIME',
GROUP_OR_SUBPLAN => 'OLTP',
COMMENT          => 'OLTP group',
MGMT_P1          => 75,
SWITCH_GROUP     => 'LOW_GROUP',
SWITCH_TIME      => 5);
END;
/

例2

次のPL/SQLブロックはOLTPグループのリソース・プラン・ディレクティブを作成し、そのディレクティブはセッションでI/O要求が10,000を超えるか転送されたデータが2,500 MBを超えると、そのグループのすべてのセッションを一時的にLOW_GROUPコンシューマ・グループに切り替えます。問題を引き起こしているトップレベルのコールが完了すると、セッションは元のグループに戻されます。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                => 'DAYTIME',
GROUP_OR_SUBPLAN    => 'OLTP',
COMMENT             => 'OLTP group',
MGMT_P1             => 75,
SWITCH_GROUP        => 'LOW_GROUP',
SWITCH_IO_REQS      => 10000,
SWITCH_IO_MEGABYTES => 2500,
SWITCH_FOR_CALL     => TRUE);
END;
/

例3

次のPL/SQLブロックはREPORTINGグループのリソース・プラン・ディレクティブを作成し、そのディレクティブはCPUタイムが60秒を超えるすべてのセッションを停止(終了)します。この例は、リソース集中型の問合せによって過剰なリソースが使用されないようにします。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN             => 'DAYTIME',
GROUP_OR_SUBPLAN => 'REPORTING',
COMMENT          => 'Reporting group',
MGMT_P1          => 75,
SWITCH_GROUP     => 'KILL_SESSION',
SWITCH_TIME      => 60);
END;
/

関連項目:
「リソース・プラン・ディレクティブの作成」

スイッチ特権の付与と取消し

DBMS_RESOURCE_MANAGER_PRIVS PL/SQLパッケージを使用すると、ユーザー、ロールまたはPUBLICにスイッチ特権を付与したり取り消すことができます。スイッチ特権を使用すると、ユーザーまたはアプリケーションが、指定されているリソース・コンシューマ・グループにセッションを切り替えることができるようになります。また、データベースによって自動的に、コンシューマ・グループへのセッションのマッピング・ルール、またはリソース・プラン・ディレクティブのSWITCH_GROUPパラメータで指定されているコンシューマ・グループにセッションが切り替えられるようにすることもできます。このパッケージでは、スイッチ特権を取り消すこともできます。次の表に、関連するパッケージ・プロシージャの一覧を示します。

プロシージャ

説明

GRANT_SWITCH_CONSUMER_GROUP

ユーザー、ロールまたはPUBLICに、指定したリソース・コンシューマ・グループに切り替える許可を付与します。

REVOKE_SWITCH_CONSUMER_GROUP

ユーザー、ロールまたはPUBLICから、指定したリソース・コンシューマ・グループに切り替える許可を取り消します。

OTHER_GROUPSでは、スイッチ特権がPUBLICに付与されています。したがって、すべてのユーザーに、このコンシューマ・グループに対するスイッチ特権が自動的に付与されます。

関連項目:

- 「ユーザーまたはアプリケーションに対する手動によるコンシューマ・グループの切替えの有効化」

- 「リソース・コンシューマ・グループの自動切替えの指定」

スイッチ特権の付与

次の例では、コンシューマ・グループOLTPに切り替える権限をユーザーSCOTTに付与しています。

BEGIN
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP (
GRANTEE_NAME   => 'SCOTT',
CONSUMER_GROUP => 'OLTP',
GRANT_OPTION   =>  TRUE);
END;
/

ユーザーSCOTTには、OLTPのスイッチ特権を他のユーザーに付与する許可も付与されます。

特定のリソース・コンシューマ・グループに切り替えるロールに権限を付与すると、そのロールを付与されたユーザーおよびそのロールを有効にしているユーザーは、各自のセッションをそのコンシューマ・グループに切り替えることができます。

特定のコンシューマ・グループに切り替える許可をPUBLICに付与すると、だれでもそのグループに切り替えることができます。

GRANT_OPTION引数がTRUEの場合、コンシューマ・グループのスイッチ特権が付与されたユーザーは、そのコンシューマ・グループのスイッチ特権を他のユーザーに付与することもできます。

スイッチ特権の取消し

次の例では、コンシューマ・グループOLTPに切り替えるユーザーSCOTTの権限を取り消しています。

BEGIN
DBMS_RESOURCE_MANAGER_PRIVS.REVOKE_SWITCH_CONSUMER_GROUP (
REVOKEE_NAME   => 'SCOTT',
CONSUMER_GROUP => 'OLTP');
END;
/

特定のコンシューマ・グループに対するユーザーのスイッチ特権を取り消すと、そのユーザーがそのコンシューマ・グループに切り替えようとすると(手動での切替え、またはコンシューマ・グループのマッピング・ルールを使用した自動での切替えのいずれも)、失敗します。このユーザーのセッションは、自動的にOTHER_GROUPSに割り当てられます。

コンシューマ・グループに対するスイッチ特権をロールから取り消すと、そのロールを介してのみコンシューマ・グループのスイッチ特権を与えられているユーザーは、そのコンシューマ・グループに切り替えることができなくなります。

コンシューマ・グループに対するスイッチ特権をPUBLICから取り消すと、直接またはロールを介してスイッチ特権を明示的に割り当てられているユーザー以外は、そのコンシューマ・グループに切り替えることができなくなります。

リソース・マネージャによって管理されるリソースのタイプ

リソース・プラン・ディレクティブは、リソース・コンシューマ・グループまたはサブプランへのリソースの割当て方法を指定します。各ディレクティブでは、リソースをそのコンシューマ・グループまたはサブプランに割り当てるための複数の異なる方法を指定できます。次の各項では、これらのリソース割当て方法について簡単に説明します。

- CPU

- 並列度制限

- パラレル・ターゲット率

- パラレル・キューのタイムアウト

- キューイングを備えたアクティブ・セッション・プール

- コンシューマ・グループの自動切替え

- SQLの取消しとセッションの終了

- 実行時間制限

- UNDOプール

- アイドル時間制限

CPU

CPUリソースを管理するために、リソース・マネージャはリソースをコンシューマ・グループに割り当て、割り当てられたものの使用されなかったCPUリソースを再配分します。特定のコンシューマ・グループに割り当てることができるCPUリソースの量に制限を設定することもできます。

リソース・マネージャでは、次のリソース・プラン・ディレクティブ属性を使用して、CPUリソース割当てを制御できます。

- 管理属性

- 最大使用率の制限

管理属性

管理属性では、コンシューマ・グループおよびサブプランの間でのCPUリソースの割当て方法を指定します。複数レベル(最大8レベル)のCPUリソース割当てによって、プラン内でCPU使用の優先度を設定できます。レベル2のコンシューマ・グループとサブプランは、レベル1に割り当てられなかったリソース、またはレベル1に割り当てられたがレベル1のコンシューマ・グループまたはサブプランで完全には使用されなかったリソースを取得します。同様に、レベル3のリソース・コンシューマには、レベル1と2の割当ての一部が残っている場合のみ、リソースが割り当てられます。リソース・プランには、各コンシューマ・グループのリソース割当てのディレクティブが含まれ、割合およびレベルで構成されます。複数のレベルを使用すると、優先度を設定できるのみでなく、すべての主リソースと残りのリソースの使用方法を明示的に指定できます。

管理属性MGMT_Pn(nは1から8の整数)は、複数レベルのCPUリソース割当てを指定する場合に使用します。たとえば、MGMT_P1ディレクティブ属性を使用してレベル1でCPUリソース割当てを指定し、MGMT_P2ディレクティブ属性を使用してレベル2でリソース割当てを指定します。

パラレル・ステートメント・キューイングを制御するには、管理属性とともに、並列度制限やパラレル・ターゲット率などのパラレル・ステートメント・ディレクティブ属性を使用します。パラレル・ステートメント・キューイングが使用されている場合、管理属性はどのコンシューマ・グループが次のパラレル・ステートメントを発行できるかを決定するために使用されます。たとえば、コンシューマ・グループのMGMT_P1ディレクティブ属性を80に設定した場合、そのグループが次のパラレル・ステートメントを発行する確率は80%になります。

関連項目:
パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

また、管理属性を使用すると、Exadata I/OのCPUリソース割当てを指定できます。

関連項目:
Exadataの入出力に関する管理属性の使用の詳細は、Exadataのドキュメントを参照してください。

表27-1に、3つのレベルがある単純なリソース・プランを示します。

表27-1 3つのレベルがある単純なリソース・プラン

コンシューマ・グループ

レベル1のCPU割当て

レベル2のCPU割当て

レベル3のCPU割当て

HIGH_GROUP

80%

LOW_GROUP

50%

MAINT_SUBPLAN

50%

OTHER_GROUPS

100%

優先度の高いアプリケーションは、CPUの80%が割り当てられるHIGH_GROUPで実行されます。HIGH_GROUPはレベル1であるため、CPU使用率の優先度がありますが、最大でCPUの80%のみです。CPUの残りの20%は、レベル2のLOW_GROUPとMAINT_SUPLANによって50%ずつ共有されます。レベル1と2で未使用の割当ては、レベル3のOTHER_GROUPSで使用できます。OTHER_GROUPSには同じレベルに兄弟関係のあるコンシューマ・グループやサブプランがないため、100%が指定されます。

特定のレベル内で、CPU割当ては固定ではありません。特定のコンシューマ・グループまたはサブプランでの負荷に余裕がある場合、残りのCPUを残りのコンシューマ・グループまたはサブプランに割り当てることができます。したがって、レベルが1つのみの場合、あるコンシューマ・グループまたはサブプランが使用していない割当ては、兄弟関係のある他のコンシューマ・グループまたはサブプランに再配分できます。複数のレベルがある場合、未使用の割当ては次のレベルのコンシューマ・グループまたはサブプランに再配分されます。最後のレベルに未使用の割当てがある場合、それらの割当ては他のすべてのレベルに、それぞれに指定された割当てに比例して再配分できます。

未使用の割当ての1つのレベルから他のレベルへの再配分の例として、特定の期間で、HIGH_GROUPがCPUの25%のみを使用した場合、LOW_GROUPとMAINT_SUBPLANで75%を共有できます。レベル2での75%の未使用部分は、レベル3のOTHER_GROUPSが使用できるようになります。ただし、レベル3でOTHER_GROUPSにセッション・アクティビティがない場合は、レベル2での75%はプランの他のすべてのコンシューマ・グループおよびサブプランに比例で再配分できます。

最大使用率の制限

前の使用例で、他の部分が非アクティブであるために、LOW_GROUPがCPUの90%を取得したとします。重要ではないセッションにCPUを大量に使用させないために、LOW_GROUPがサーバーの90%を使用できないようにするとします。リソース・プラン・ディレクティブのMAX_UTILIZATION_LIMIT属性を使用して、この状況を防ぐことができます。

MAX_UTILIZATION_LIMIT属性は、リソース・コンシューマ・グループのCPU使用率に絶対上限を設定する場合に使用します。この絶対的な制限により、プラン内でのCPUの再配布は無視されます。

MAX_UTILIZATION_LIMIT属性の設定はオプションです。コンシューマ・グループに対するこの属性を省略した場合は、コンシューマ・グループが使用できるCPUの量に制限はありません。このため、他のすべてのアプリケーションがアイドル状態である場合、MAX_UTILIZATION_LIMITが設定されていないコンシューマ・グループに100%のCPUリソースを割り当てることができます。

レベルの制限を使用しないで、コンシューマ・グループのCPU使用率を制限する唯一の手段としてMAX_UTILIZATION_LIMIT属性を使用することもできます。

表27-2に、前のプランを変更したプランを示します。このプランでは、MAX_UTILIZATION_LIMITを使用して、CPU使用率の上限をLOW_GROUPの場合は75%、MAINT_SUBPLANの場合は50%、OTHER_GROUPSの場合は75%に設定します。(最大使用率の制限の合計が100%を超える場合があります。各制限は個別に適用されます。)

表27-2 最大使用率の制限が適用された3つのレベルがあるリソース・プラン

コンシューマ・グループ

レベル1のCPU割当て

レベル2のCPU割当て

レベル3のCPU割当て

最大使用率の制限

HIGH_GROUP

80%

LOW_GROUP

50%

75%

MAINT_SUBPLAN

50%

50%

OTHER_GROUPS

100%

75%

表27-2で説明する例では、HIGH_GROUPが特定の時間にCPUの10%のみを使用している場合、残りの90%をLOW_GROUPおよびMAINT_SUBPLANのコンシューマ・グループがレベル2で使用できます。LOW_GROUPがCPUの20%のみを使用している場合、70%をMAINT_SUBPLANに割り当てることができます。ただし、MAINT_SUBPLANではMAX_UTILIZATION_LIMITを50%に設定します。このため、より多くのCPUリソースが使用可能である場合も、サブプランMAINT_SUBPLANに属するコンシューマ・グループには50%を超えたCPUを割り当てることができません。

サブプランとそのサブプランに含まれているコンシューマ・グループの両方にMAX_UTILIZATION_LIMITを設定できます。このような場合、コンシューマ・グループの制限はサブプランとそのコンシューマ・グループに指定されている制限を使用して算出されます。たとえば、MAINT_SUBPLANには、コンシューマ・グループMAINT_GROUP1とMAINT_GROUP2が含まれています。MAINT_GROUP1のMAX_UTILIZATION_LIMITは40%に設定されています。ただし、MAINT_SUBPLANの制限は50%に設定されています。このため、コンシューマ・グループMAINT_GROUP1の制限は50%の40%、つまり20%になります。コンシューマ・グループとそのグループが属するサブプランの両方に制限が指定されている場合に、コンシューマ・グループのMAX_UTILIZATION_LIMITを計算する方法の例については、「例4 - コンシューマ・グループおよびサブプランに最大使用率の制限を指定する」を参照してください。

関連項目:

- 「リソース・プラン・ディレクティブの作成」

- 「各種の方法を組み合せたOracle Database Resource Managerの例」

並列度制限

管理者は、1つのコンシューマ・グループ内での操作に対して最大並列度を制限できます。並列度は、単一の処理に対応付けられるパラレル実行サーバーの数で表されます。PARALLEL_DEGREE_LIMIT_P1ディレクティブ属性は、コンシューマ・グループの並列度を指定する場合に使用します。

関連項目:
プロデューサ/コンシューマ操作での並列度の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

並列度制限は、コンシューマ・グループ内の1つの操作に対して適用されます(コンシューマ・グループ内のすべての操作の合計並列度は制限されません)。ただし、PARALLEL_DEGREE_LIMIT_P1とPARALLEL_TARGET_PERCENTAGEの両方のディレクティブ属性を組み合せて、任意の制御を行うことは可能です。PARALLEL_TARGET_PERCENTAGE属性の詳細は、「パラレル・ターゲット率」を参照してください。

パラレル・ターゲット率

単一のコンシューマ・グループが数多くのパラレル・ステートメントを起動することによって、使用可能なすべてのパラレル・サーバーが使用されることがあります。この場合、別のコンシューマ・グループから優先度の高いパラレル・ステートメントが実行されても、このグループにパラレル・サーバーを割り当てることができません。このような状況を回避するには、特定のコンシューマ・グループが使用できるパラレル・サーバーの数を制限します。

注意:
この機能は、Oracle Database 11gリリース2(11.2.0.2)以上で使用できます。

PARALLEL_TARGET_PERCENTAGEディレクティブ属性は、特定のコンシューマ・グループが使用できるパラレル・サーバー・プールの最大割合を指定する場合に使用します。特定のコンシューマ・グループで使用されているパラレル・サーバーの数は、そのコンシューマ・グループのすべてのセッションで使用されているパラレル・サーバーの合計となります。

関連項目:
パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

たとえば、PARALLEL_SERVERS_TARGET初期化パラメータによってパラレル・サーバーの総数が32に設定され、コンシューマ・グループMY_GROUPのPARALLEL_TARGET_PERCENTAGEディレクティブ属性が50%に設定されているとします。このコンシューマ・グループは、最大で32の50%、つまり16台のパラレル・サーバーを使用できます。

リソース・プランで管理属性(MGMT_P1、MGMT_P2など)が設定された場合は、管理属性ごとに別々のパラレル・ステートメント・キューが先入れ先出し(FIFO)キューとして管理されます。

リソース・プランで管理属性が設定されない場合は、1つのパラレル・ステートメント・キューがFIFOキューとして管理されます。

Oracle Real Application Clusters(Oracle RAC)環境の場合、パラレル・サーバーのターゲット数はすべてのOracle RACインスタンスでの(PARALLEL_TARGET_PERCENTAGE * PARALLEL_SERVERS_TARGET /100)の合計となります。あるコンシューマ・グループが上記で算出した数以上のパラレル・サーバーを使用している場合、そのコンシューマ・グループは制限値を超えているため、そのコンシューマ・グループのパラレル・ステートメントはキューされます。

コンシューマ・グループにOracle RACデータベース内で実行されているパラレル・ステートメントがない場合、最初のパラレル・ステートメントはPARALLEL_TARGET_PERCENTAGEで指定された制限を超えることができます。

注意:
Oracle Real Application Clusters(Oracle RAC)環境では、PARALLEL_TARGET_PERCENTAGE属性が単一のインスタンスではなくクラスタ全体に適用されます。

パラレル・ターゲット率を使用したパラレル・ステートメント・キューイングの管理

PARALLEL_TARGET_PERCENTAGE属性を使用すると、いつコンシューマ・グループからパラレル・ステートメントをキューできるかを指定できます。Oracle Databaseには、コンシューマ・グループごとにパラレル・ステートメント・キューが保持されます。

コンシューマ・グループからのパラレル・ステートメントは実行されず、そのかわり、次の条件が満たされた場合に、そのコンシューマ・グループのパラレル・ステートメント・キューに追加されます。

- PARALLEL_DEGREE_POLICYがAUTOに設定されています。
このパラメータをAUTOに設定すると、自動並列度(Auto DOP)、パラレル・ステートメント・キューイングおよびメモリー内パラレル実行が有効になります。

PARALLEL_DEGREE_POLICYがMANUALまたはLIMITEDに設定されているパラレル・ステートメントはただちに実行され、パラレル・ステートメント・キューに追加されません。

- すべてのコンシューマ・グループのアクティブなパラレル・サーバー数が、PARALLEL_SERVERS_TARGET初期化パラメータの設定を超えています。この条件は、PARALLEL_TARGET_PERCENTAGEを指定しているかどうかに関係なく適用されます。PARALLEL_TARGET_PERCENTAGEが指定されていない場合は、100%にデフォルト設定されます。

- コンシューマ・グループのアクティブなパラレル・サーバーの総数およびパラレル・ステートメントの並列度がアクティブなパラレル・サーバーのターゲット数を超えています。
アクティブなパラレル・サーバーのターゲット数は、次のように計算されます。

PARALLEL_TARGET_PERCENTAGE/100 * PARALLEL_SERVERS_TARGET

パラレル・キューのタイムアウト

パラレル・ステートメント・キューイングを使用すると、データベースにパラレル・ステートメントを実行するほどのリソースがない場合、そのステートメントは必要なリソースが使用可能になるまでキューで待機します。ただし、パラレル・ステートメントが意図した時間よりも長くパラレル・ステートメント・キューで待機する場合があります。このような状況を回避するには、パラレル・ステートメントがパラレル・ステートメント・キューで待機できる最大時間を指定します。

注意:
この機能は、Oracle Database 11gリリース2(11.2.0.2)以降で使用可能です。

PARALLEL_QUEUE_TIMEOUTディレクティブ属性を使用すると、パラレル・ステートメントがパラレル・ステートメント・キュー内でタイムアウトになるまで待機する最大時間を秒単位で指定できます。PARALLEL_QUEUE_TIMEOUT属性は、コンシューマ・グループごとに設定できます。この属性は、リソース・プランの他の管理属性(MGMT_P1、MGMT_P2など)を指定していなくても適用できます。

関連項目:
パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

注意:
パラレル・ステートメント・キューはクラスタ全体で機能するため、パラレル・ステートメント・キューに関連するすべてのディレクティブもクラスタ全体で機能します。

パラレル・ステートメントがタイムアウトすると、ステートメントの実行は次のエラー・メッセージで終了します。

ORA-07454: queue timeout, n second(s), exceeded

ワークロード単位で細かく管理する場合は、次のディレクティブ属性を使用する必要があります。

- MGMT_Pn
管理属性は、パラレル・ステートメント・キューから実行するパラレル・ステートメントをどのように選択するかを制御します。あるコンシューマ・グループのパラレル・ステートメントを別のグループよりも優先させるには、そのグループの管理属性の値を大きくします。

- PARALLEL_TARGET_PERCENTAGE

- PARALLEL_QUEUE_TIMEOUT

- PARALLEL_DEGREE_LIMIT_P1

関連項目:
すべてのパラレル・サーバー・ディレクティブ属性を組み合せて使用する方法の詳細は、「ディレクティブ属性を使用したパラレル・ステートメントの管理の例」を参照してください。

すべてのセッションでパラレル・サーバーの使用状況が監視されますが、設定したパラレル・サーバー・ディレクティブ属性はパラレル・ステートメント・キューイングが有効になっている(PARALLEL_DEGREE_POLICYがAUTOに設定されている)セッションにのみに影響を与えます。セッションのPARALLEL_DEGREE_POLICYがMANUALに設定されている場合、このセッションからのパラレル・ステートメントはキューされません。ただし、このようなセッションで使用されているパラレル・サーバーは、PARALLEL_TARGET_PERCENTAGEの制限の決定に使用されるカウントに数えられます。この制限を超えても、このセッションからのパラレル・ステートメントはキューされません。

キューイングを備えたアクティブ・セッション・プール

コンシューマ・グループ内で同時にアクティブにできるセッションの最大数を制御できます。この最大数によって、アクティブ・セッション・プールが定義されます。アクティブ・セッションとは、現在、トランザクションまたはSQL文を処理しているセッションです。具体的には、アクティブ・セッションは、ユーザー・エンキューを保持した状態でトランザクション内にあるか、またはオープン・カーソルを持ちつつ5秒を超える長さにわたりアイドル状態になっていないかのいずれかです。アクティブ・セッションは、セッションがブロックされている場合であっても(たとえば、I/O要求の完了の待機中など)、アクティブであるとみなされます。アクティブ・セッション・プールが一杯になると、コールの処理を試行しているセッションはキューに送られます。アクティブ・セッションが完了すると、キュー内の最初のセッションがキューから削除されて実行がスケジュールされます。また、実行キュー内のセッションがタイムアウトして、そのコールがエラーで終了されるまでの時間も指定できます。

OLTPワークロードにはアクティブ・セッションの制限を使用しないでください。また、接続プーリングまたはパラレル・ステートメント・キューイングを実装する目的でアクティブ・セッションの制限を使用しないでください。

パラレル・ステートメントを管理するには、PARALLEL_TARGET_PERCENTAGE属性および管理属性(MGMT_P1、MGMT_P2など)とともに、パラレル・ステートメント・キューイングを使用する必要があります。

コンシューマ・グループの自動切替え

この方法を使用すると、指定のコンシューマ・グループにセッションを自動的に切り替えるための基準を指定して、リソース割当てを制御できます。通常、この方法は、グループ内の典型的なセッションに対するリソース使用予測を上回ったセッションを、優先度の高いコンシューマ・グループ(システム・リソースを高い比率で使用するグループ)から優先度の低いコンシューマ・グループに切り替えるために使用します。

詳細は、「リソース制限の設定による自動切替えの指定」を参照してください。

SQLの取消しとセッションの終了

ディレクティブを指定すると、システム・リソースの使用量に基づいて、長時間実行SQL問合せを取り消したり、長時間実行セッションを終了できます。詳細は、「リソース制限の設定による自動切替えの指定」を参照してください。

実行時間制限

ある操作に許可される最大の実行時間を指定できます。ある操作についてデータベースが見積った実行時間が、指定された最大実行時間より長い場合、その操作はエラーを出力して終了します。このエラーはトラップ可能であり、操作は再スケジュールできます。

UNDOプール

UNDOプールは、コンシューマ・グループごとに指定できます。UNDOプールは、コンシューマ・グループが生成できる、コミットされていないトランザクションに対するUNDO合計量を制御します。コンシューマ・グループが生成するUNDOの合計量がそのUNDO制限を超えると、そのUNDOを生成している現行のデータ操作言語(DML)文が終了します。コンシューマ・グループの他のメンバーは、UNDO領域がプールから解放されるまで、新たにデータ操作を実行できません。

アイドル時間制限

セッションがアイドル状態のままでいられる時間(セッションが終了されるまでの時間)を指定できます。また、アイドル状態で他のセッションをブロックしているセッションに適用される、さらに厳密なアイドル時間制限も指定できます。

単純なリソース・プランの作成

CREATE_SIMPLE_PLANプロシージャを使用すると、多くの状況に対応できる単純なリソース・プランを迅速に作成できます。このプロシージャでは、1回のプロシージャ・コールの実行で、コンシューマ・グループを作成し、そのグループにリソースを割り当てることができます。このプロシージャを使用する際は、ペンディング・エリアの作成、各コンシューマ・グループの個別作成、リソース・プラン・ディレクティブの指定のために、後述のプロシージャをコールする必要はありません。

CREATE_SIMPLE_PLANプロシージャには、次の引数を指定します。

パラメータ

説明

SIMPLE_PLAN

計画の名前。

CONSUMER_GROUP1

1番目のグループのコンシューマ・グループ名

GROUP1_PERCENT

このグループに割り当てるCPUリソース

CONSUMER_GROUP2

2番目のグループのコンシューマ・グループ名

GROUP2_PERCENT

このグループに割り当てるCPUリソース

CONSUMER_GROUP3

3番目のグループのコンシューマ・グループ名

GROUP3_PERCENT

このグループに割り当てるCPUリソース

CONSUMER_GROUP4

4番目のグループのコンシューマ・グループ名

GROUP4_PERCENT

このグループに割り当てるCPUリソース

CONSUMER_GROUP5

5番目のグループのコンシューマ・グループ名

GROUP5_PERCENT

このグループに割り当てるCPUリソース

CONSUMER_GROUP6

6番目のグループのコンシューマ・グループ名

GROUP6_PERCENT

このグループに割り当てるCPUリソース

CONSUMER_GROUP7

7番目のグループのコンシューマ・グループ名

GROUP7_PERCENT

このグループに割り当てるCPUリソース

CONSUMER_GROUP8

8番目のグループのコンシューマ・グループ名

GROUP8_PERCENT

このグループに割り当てるCPUリソース

このプロシージャでは、最大8個のコンシューマ・グループを指定できます。サポート対象のリソース割当て方法は、CPUによる方法のみです。プランでは、EMPHASIS CPU割当てポリシー(デフォルト)が使用され、各コンシューマ・グループでは、ROUND_ROBINスケジューリング・ポリシー(これもデフォルト)が使用されます。プラン内の指定された各コンシューマ・グループには、レベル2のCPUパーセンテージが割り当てられます。このプランには、SYS_GROUP(ユーザーSYSおよびSYSTEM用にシステムによって定義された初期コンシューマ・グループ)とOTHER_GROUPSも暗黙的に含まれています。SYS_GROUPコンシューマ・グループには、レベル1でCPUの100%が割り当てられ、OTHER_GROUPSには、レベル3でCPUの100%が割り当てられます。

例: CREATE_SIMPLE_PLANプロシージャを使用した単純なプランの作成

次のスクリプトは、ユーザー指定の2つのコンシューマ・グループを備えた単純なリソース・プランを作成するPL/SQLブロックです。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => 'SIMPLE_PLAN1',
CONSUMER_GROUP1 => 'MYGROUP1', GROUP1_PERCENT => 80,
CONSUMER_GROUP2 => 'MYGROUP2', GROUP2_PERCENT => 20);
END;
/

この文を実行すると、次のプランが作成されます。

コンシューマ・グループ

レベル1

レベル2

レベル3

SYS_GROUP

100%

-

-

MYGROUP1

-

80%

-

MYGROUP2

-

20%

-

OTHER_GROUPS

-

-

100%

関連項目:

- EMPHASIS CPU割当てポリシーの詳細は、「リソース・プランの作成」を参照してください。

- ROUND_ROBINスケジューリング・ポリシーの詳細は、「リソース・コンシューマ・グループの作成」を参照してください。

- 「リソース・マネージャの要素」

複雑なリソース・プランの作成

複雑なリソース・プランが必要な場合は、ペンディング・エリアと呼ばれるステージング領域で、プランとそのディレクティブやコンシューマ・グループを作成し、そのプランの妥当性をチェックしてから、データ・ディクショナリに保存する必要があります。

複雑なリソース・プランの作成に必要な手順の概要は、次のとおりです。

注意:
複雑なリソース・プランとは、DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLANプロシージャでは作成できないリソース・プランを指します。

手順1: ペンディング・エリアを作成します。

手順2: コンシューマ・グループを作成、変更または削除します。

手順3: リソース・プランを作成します。

手順4: リソース・プラン・ディレクティブを作成します。

手順5: ペンディング・エリアの妥当性をチェックします。

手順6: ペンディング・エリアを発行します。

これらの手順は、DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを使用して完了します。この項の内容は、次のとおりです。

- ペンディング・エリアの概要

- ペンディング・エリアの作成

- リソース・コンシューマ・グループの作成

- リソース・プランの作成

- リソース・プラン・ディレクティブの作成

- ペンディング・エリアの妥当性チェック

- ペンディング・エリアの発行

- ペンディング・エリアのクリア

関連項目:

- 事前定義のコンシューマ・グループ・マッピング・ルール

- DBMS_RESOURCE_MANAGER PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 「リソース・マネージャの要素」

ペンディング・エリアの概要

ペンディング・エリアとは、現在実行中のアプリケーションに影響を与えることなく、新規リソース・プランの作成、既存のプランの更新、またはプランの削除を実行できるステージング領域です。ペンディング・エリアを作成すると、データベースによってペンディング・エリアが初期化され、既存のプランがペンディング・エリアにコピーされて、既存のプランを更新できるようになります。

ヒント:
ペンディング・エリアを作成した後、DBA_RSRC_PLANSデータ・ディクショナリ・ビューを問い合せてすべてのプランをリストすると、各プランについて2つのコピー(PENDINGステータスが付いているコピーと付いていないコピー)が表示されます。PENDINGステータスのプランには、ペンディング・エリアの作成後に実行した変更内容が反映されています。保留中の変更は、コンシューマ・グループの場合はDBA_RSRC_CONSUMER_GROUPSを使用して、リソース・プラン・ディレクティブの場合はDBA_RSRC_PLAN_DIRECTIVESを使用して表示できます。詳細は、「リソース・マネージャのデータ・ディクショナリ・ビュー」を参照してください。

変更を追加した後のペンディング・エリアは、発行する前に妥当性をチェックします。発行すると、保留中の変更内容がすべてデータ・ディクショナリに適用され、ペンディング・エリアはクリアされ、解除されます。

最初にペンディング・エリアを作成せずにプランを作成、更新または削除しようとすると(つまり、コンシューマ・グループまたはリソース・プラン・ディレクティブを作成、更新または削除しようとすると)、エラー・メッセージが表示されます。

ペンディング・エリアを発行しても、新しく作成したプランはアクティブ化されません(新しいプランまたは更新後のプランの情報がデータ・ディクショナリに格納されるだけです)。ただし、現在アクティブなプランを変更した場合、そのプランは新しいプラン定義で再アクティブ化されます。リソース・プランをアクティブ化する方法の詳細は、「Oracle Database Resource Managerの有効化とプランの切替え」を参照してください。

ペンディング・エリアを作成した後は、そのペンディング・エリアを発行またはクリアするか、ログアウトするまで、他のユーザーはペンディング・エリアを作成できません。

ペンディング・エリアの作成

ペンディング・エリアはCREATE_PENDING_AREAプロシージャを使用して作成します。

例: ペンディング・エリアの作成

次のスクリプトは、ペンディング・エリアを作成して初期化するPL/SQLブロックです。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
END;
/

リソース・コンシューマ・グループの作成

リソース・コンシューマ・グループを作成するには、CREATE_CONSUMER_GROUPプロシージャを使用します。次のパラメータを指定できます。

パラメータ

説明

CONSUMER_GROUP

コンシューマ・グループに割り当てる名前。

COMMENT

任意のコメント。

CPU_MTH

非推奨。MGMT_MTHを使用してください。

MGMT_MTH

コンシューマ・グループのセッション間でCPUを分配するためのリソース割当て方法。デフォルトは'ROUND-ROBIN'で、ラウンドロビン・スケジューラを使用して、セッションの適切な実行を保証します。'RUN-TO-COMPLETION'では、長時間実行セッションを他のセッションより先にスケジュールすることを指定します。この設定によって、長時間実行セッション(バッチ処理など)をより早く完了できるようになります。

例: リソース・コンシューマ・グループの作成

次のスクリプトは、グループ内のセッションにリソースを割り当てるデフォルトの方法(ROUND-ROBIN)を使用して、OLTPというコンシューマ・グループを作成するPL/SQLブロックです。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'OLTP',
COMMENT        => 'OLTP applications');
END;
/

関連項目:

- 「コンシューマ・グループの更新」

- 「コンシューマ・グループの削除」

リソース・プランの作成

リソース・プランを作成するには、CREATE_PLANプロシージャを使用します。次の表のパラメータを指定できます。最初の2つのパラメータは必須です。他のパラメータはオプションです。

パラメータ

説明

PLAN

グループに割り当てる名前。

COMMENT

任意の内容を表現するコメント。

CPU_MTH

非推奨。MGMT_MTHを使用してください。

ACTIVE_SESS_POOL_MTH

アクティブ・セッション・プールのリソース割当て方法。デフォルトのACTIVE_SESS_POOL_ABSOLUTEは、選択できる唯一の方法です。

PARALLEL_DEGREE_LIMIT_MTH

任意の操作について並列度の制限を指定するためのリソース割当て方法。デフォルトはPARALLEL_DEGREE_LIMIT_ABSOLUTEで、これは使用可能な唯一の方法です。

QUEUEING_MTH

キューイングのリソース割当て方法。キュー内の非アクティブ・セッションをキューから削除し、アクティブ・セッション・プールに追加する順序を制御します。デフォルトはFIFO_TIMEOUTで、これは使用可能な唯一の方法です。

MGMT_MTH

各コンシューマ・グループまたは各サブプランが取得するCPUの量を指定するためのリソース割当て方法。デフォルトの方法'EMPHASIS'は単一レベルまたは複数レベルのプラン用の方法で、コンシューマ・グループ間でのCPUの分配方法の指定にパーセンテージを使用します。'RATIO'は単一レベルのプラン用の方法で、CPUの分配方法の指定に割合を使用します。

SUB_PLAN

TRUEの場合は、プランをトップレベルのプランとして使用できません。サブプランとしてのみ使用できます。デフォルトはFALSEです。

例: リソース・プランの作成

次のスクリプトは、DAYTIMEというリソース・プランを作成するPL/SQLブロックです。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN(
PLAN    => 'DAYTIME',
COMMENT => 'More resources for OLTP applications');
END;
/

RATIO CPU割当て方法の概要

RATIO方法は、単一レベルのCPU割当てのみを使用する単純なプランを対象にした、代替のCPU割当て方法です。パーセンテージのかわりに、各コンシューマ・グループに与えるCPUの割合に対応する数を指定します。RATIO方法を使用するには、CREATE_PLANプロシージャのMGMT_MTH引数に'RATIO'を設定します。この方法を使用するプランの例は、「リソース・プラン・ディレクティブの作成」を参照してください。

関連項目:

- 「プランの更新」

- 「プランの削除」

リソース・プラン・ディレクティブの作成

リソース・プラン・ディレクティブを作成するには、CREATE_PLAN_DIRECTIVEプロシージャを使用します。各ディレクティブはプランまたはサブプランに属しており、リソースをコンシューマ・グループまたはサブプランに割り当てます。

注意:
リソース・プランとそのサブプランに属するディレクティブ全体で1回のみ、特定のサブプランを指定できます。
特定のコンシューマ・グループに対するディレクティブは、トップレベルのプランとそのサブプランで指定できます。ただし、リソース・プランとそのサブプランに対するディレクティブ全体で1回のみ、特定のコンシューマ・グループを指定することをお薦めします。

次のパラメータを指定できます。

パラメータ

説明

PLAN

ディレクティブが属しているリソース・プランの名前。

GROUP_OR_SUBPLAN

リソースを割り当てるコンシューマ・グループまたはサブプランの名前。

COMMENT

任意のコメント。

CPU_P1

非推奨。MGMT_P1を使用してください。

CPU_P2

非推奨。MGMT_P2を使用してください。

CPU_P3

非推奨。MGMT_P3を使用してください。

CPU_P4

非推奨。MGMT_P4を使用してください。

CPU_P5

非推奨。MGMT_P5を使用してください。

CPU_P6

非推奨。MGMT_P6を使用してください。

CPU_P7

非推奨。MGMT_P7を使用してください。

CPU_P8

非推奨。MGMT_P8を使用してください。

ACTIVE_SESS_POOL_P1

コンシューマ・グループ内で同時にアクティブにできるセッションの最大数を指定します。他のセッションは、非アクティブ・セッション・キューで実行を待機します。デフォルトはUNLIMITEDです。

QUEUEING_P1

非アクティブ・セッション・キュー内で実行を待機しているセッションがタイムアウトしてコールが中止されるまでの時間を秒数で指定します。デフォルトはUNLIMITEDです。

PARALLEL_DEGREE_LIMIT_P1

任意の操作の並列度を制限します。デフォルトはUNLIMITEDです。

SWITCH_GROUP

切替え基準が満たされた場合に、セッションの切替え先となるコンシューマ・グループを指定します。グループ名が'CANCEL_SQL'の場合は、切替え基準が満たされると、現在のコールは取り消されます。グループ名が'KILL_SESSION'の場合は、切替え基準が満たされると、そのセッションは強制終了します。デフォルトはNULLです。
グループ名が'CANCEL_SQL'の場合は、SWITCH_FOR_CALLパラメータは常にTRUEに設定され、ユーザー指定の設定は無効になります。

SWITCH_TIME

処理が実行されるまでにコールが実行可能な時間をCPU秒数で指定します。デフォルトはUNLIMITEDです。処理はSWITCH_GROUPで指定されます。

SWITCH_ESTIMATE

TRUEの場合は、各コールの実行時間が見積られ、実行時間の見積りがSWITCH_TIMEを超える場合は、コールを開始する前にセッションをSWITCH_GROUPに切り替えます。デフォルトはFALSEです。
実行時間の見積りはオプティマイザから取得されます。見積りの正確さは、様々な要因(特にオプティマイザ統計の品質)によって異なります。一般的に、統計には±10分未満の誤差があると考えてください。

MAX_EST_EXEC_TIME

コールに許可される最大の実行時間をCPU秒数で指定します。あるコールに対するオプティマイザの見積り実行時間がMAX_EST_EXEC_TIMEを超える場合、そのコールは実行されず、ORA-07455が発行されます。オプティマイザが判断しない場合は、このディレクティブの効果はありません。デフォルトはUNLIMITEDです。
見積りの正確さは、様々な要因(特にオプティマイザ統計の品質)によって異なります。

UNDO_POOL

コンシューマ・グループで生成される、コミットされていないトランザクションのUNDO合計量の最大値をKBで設定します。デフォルトはUNLIMITEDです。

MAX_IDLE_TIME

セッションの最大アイドル時間を秒数で示します。デフォルトはNULLで、無制限を意味します。

MAX_IDLE_BLOCKER_TIME

ブロックしているセッションの最大アイドル時間を秒数で示します。デフォルトはNULLで、無制限を意味します。

SWITCH_TIME_IN_CALL

非推奨。SWITCH_FOR_CALLを使用してください。

MGMT_P1

MGMT_MTHパラメータがEMPHASISに設定されているプランの場合は、レベル1のCPUパーセンテージを指定します。MGMT_MTHパラメータがRATIOに設定されている場合は、CPU使用の比重を指定します。MGMT_PnパラメータのデフォルトはすべてNULLです。

MGMT_P2

EMPHASISの場合は、レベル2のCPUパーセンテージを指定します。RATIOには適用しません。

MGMT_P3

EMPHASISの場合は、レベル3のCPUパーセンテージを指定します。RATIOには適用しません。

MGMT_P4

EMPHASISの場合は、レベル4のCPUパーセンテージを指定します。RATIOには適用しません。

MGMT_P5

EMPHASISの場合は、レベル5のCPUパーセンテージを指定します。RATIOには適用しません。

MGMT_P6

EMPHASISの場合は、レベル6のCPUパーセンテージを指定します。RATIOには適用しません。

MGMT_P7

EMPHASISの場合は、レベル7のCPUパーセンテージを指定します。RATIOには適用しません。

MGMT_P8

EMPHASISの場合は、レベル8のCPUパーセンテージを指定します。RATIOには適用しません。

SWITCH_IO_MEGABYTES

処理が実行される前に、セッションで移動(読取りおよび書込み)できるI/Oのサイズ(MB)を指定します。デフォルトはUNLIMITEDです。処理はSWITCH_GROUPで指定されます。

SWITCH_IO_REQS

処理が実行されるまでにセッションが実行可能なI/Oのリクエスト件数を指定します。デフォルトはUNLIMITEDです。処理はSWITCH_GROUPで指定されます。

SWITCH_FOR_CALL

TRUEの場合は、SWITCH_TIME、SWITCH_IO_MEGABYTESまたはSWITCH_IO_REQSに基づいて別のコンシューマ・グループに自動的に切り替えたセッションが、トップレベルのコールが完了した時に当初のコンシューマ・グループに戻されます。デフォルトはNULLです。

MAX_UTILIZATION_LIMIT

コンシューマ・グループに許可する絶対最大CPU使用率。この値は、すべてのレベルのCPU割当て(MGMT_P1からMGMT_P8)よりも優先され、未使用の割当てが再配分されるときの合計CPU使用率の制限にも適用されます。この属性を指定して、MGMT_P1からMGMT_P8をNULLにしておくことができます。

PARALLEL_TARGET_PERCENTAGE

特定のコンシューマ・グループが使用できるパラレル・サーバー・プールの最大割合を指定します。特定のコンシューマ・グループで使用されているパラレル・サーバーの数は、そのコンシューマ・グループのすべてのセッションで使用されているパラレル・サーバーの合計となります。

PARALLEL_QUEUE_TIMEOUT

パラレル・ステートメントがパラレル・ステートメント・キューで待機できる最大時間を秒単位で指定します。この時間を超えると、タイムアウトします。

例1:

次のスクリプトは、プランDAYTIMEのリソース・プラン・ディレクティブを作成するPL/SQLブロックです。(DAYTIMEプランおよびOLTPコンシューマ・グループがペンディング・エリアに作成済であることを前提としています。)

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN             => 'DAYTIME',
GROUP_OR_SUBPLAN => 'OLTP',
COMMENT          => 'OLTP group',
MGMT_P1          => 75);
END;
/

このディレクティブは、レベル1でのCPUリソースの75%をOLTPコンシューマ・グループに割り当てます。

図27-1にあるプランを完了するには、REPORTINGコンシューマ・グループを作成してから、次のPL/SQLブロックを実行します。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                     => 'DAYTIME',
GROUP_OR_SUBPLAN         => 'REPORTING',
COMMENT                  => 'Reporting group',
MGMT_P1                  => 15,
PARALLEL_DEGREE_LIMIT_P1 => 8,
ACTIVE_SESS_POOL_P1      => 4);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                     => 'DAYTIME',
GROUP_OR_SUBPLAN         => 'OTHER_GROUPS',
COMMENT                  => 'This one is required',
MGMT_P1                  => 10);
END;
/

このプランでは、コンシューマ・グループREPORTINGに対して操作の最大並列度が8に設定されていますが、他のコンシューマ・グループの並列度に制限はありません。また、このREPORTINGグループには、同時にアクティブにできるセッションの最大数が4に設定されています。

例2:

この例では、CPUの割当てにRATIO方式を使用し、使用率ではなく比率を使用します。アプリケーション・スイートで、「Gold」、「Silver」および「Bronze」の3つのサービス・レベルをクライアントに提供しているものとします。3つのコンシューマ・グループをGOLD_CG、SILVER_CGおよびBRONZE_CGという名前で作成し、次のリソース・プランを作成します。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN
(PLAN             => 'SERVICE_LEVEL_PLAN',
MGMT_MTH         => 'RATIO',
COMMENT          => 'Plan that supports three service levels');

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
(PLAN             => 'SERVICE_LEVEL_PLAN',
GROUP_OR_SUBPLAN => 'GOLD_CG',
COMMENT          => 'Gold service level customers',
MGMT_P1          => 10);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
(PLAN             => 'SERVICE_LEVEL_PLAN',
GROUP_OR_SUBPLAN => 'SILVER_CG',
COMMENT          => 'Silver service level customers',
MGMT_P1          => 5);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
(PLAN             => 'SERVICE_LEVEL_PLAN',
GROUP_OR_SUBPLAN => 'BRONZE_CG',
COMMENT          => 'Bronze service level customers',
MGMT_P1          => 2);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
(PLAN            => 'SERVICE_LEVEL_PLAN',
GROUP_OR_SUBPLAN => 'OTHER_GROUPS',
COMMENT          => 'Lowest priority sessions',
MGMT_P1          => 1);
END;
/

CPU割当ての割合は、GOLD_CG、SILVER_CG、BRONZE_CGおよびOTHER_GROUPSコンシューマ・グループに対して、それぞれ10:5:2:1の割合です。

セッションがGOLD_CGおよびSILVER_CGコンシューマ・グループにのみ存在する場合、CPU割当ての割合は、この2つのグループ間で10:5になります。

リソース・プラン・ディレクティブの相互作用

トップレベルのプランと複数のサブプランから同じコンシューマ・グループを参照する場合があります。このような場合は、複数のリソース・プラン・ディレクティブによって同じコンシューマ・グループが参照されます。このことは許可されますが、トップレベルのプランおよびそのいずれのサブプランからも同じコンシューマ・グループが参照されないようにすることをお薦めします。

複数のリソース・プラン・ディレクティブによって同じコンシューマ・グループが参照されている場合、次のルールが適用されます。

- コンシューマ・グループの並列度制限は、すべての入力値の最小になります。

- コンシューマ・グループのアクティブ・セッション・プールは、すべての入力値の合計になり、キューのタイムアウトは、すべての入力タイムアウト値の最小になります。

- コンシューマ・グループのUNDOプールは、すべての入力値の合計になります。

- 複数のSWITCH_TIME、SWITCH_IO_MEGABYTESまたはSWITCH_IO_REQSが存在する場合、Oracle Database Resource Manager (リソース・マネージャ)では、すべての入力値のうち最も制限が厳しいものが選択されます。具体的には、次のようになります。

- SWITCH_TIME = min(入力されるすべてのSWITCH_TIME値)

- SWITCH_IO_MEGABYTES = min(入力されるすべてのSWITCH_IO_MEGABYTES値)

- SWITCH_IO_REQS = min(入力されるすべてのSWITCH_IO_REQS値)

- SWITCH_ESTIMATE = FALSEよりもSWITCH_ESTIMATE = TRUEが優先する

注意:
両方のプラン・ディレクティブの切替え時間が同じで、切替えグループが異なる場合、切替え先のグループは、リソース・マネージャによって任意に決められた一方に固定されます。

- いずれかの入力値がTRUEの場合、SWITCH_FOR_CALLはTRUEです。

- 最大推定実行時間は、すべての入力値のうち最も制限が厳しいものになります。具体的には、次のようになります。
MAX_EST_EXEC_TIME = min(入力されるすべてのMAX_EST_EXEC_TIME値)

- 最大アイドル時間は、すべての入力値の最小になります。

- 最大アイドル・ブロッカ時間は、すべての入力値の最小になります。

関連項目:

- 「リソース・プラン・ディレクティブの更新」

- 「リソース・プラン・ディレクティブの削除」

ペンディング・エリアの妥当性チェック

ペンディング・エリアで変更を追加しているときは、いつでもVALIDATE_PENDING_AREAをコールして、そのペンディング・エリアの妥当性を確認できます。

従う必要がある規則は、次のとおりです。これらの規則が妥当性チェック・プロシージャによってチェックされます。

- プランにループを含めることはできません。ループが発生するのは、サブプランに、プラン階層ではそのサブプランの上位となるプランを参照するディレクティブが含まれている場合です。たとえば、サブプランはトップレベルのプランを参照できません。

- プラン・ディレクティブで参照されるプランやリソース・コンシューマ・グループは、すべて存在している必要があります。

- すべてのプランに、プランまたはリソース・コンシューマ・グループを指すプラン・ディレクティブが必要です。

- 特定のレベルの全パーセンテージの合計は、100以下であることが必要です。

- アクティブなインスタンスで現在トップレベルのプランとして使用されているプランは、削除できません。

- 次のパラメータは、リソース・コンシューマ・グループを参照するプラン・ディレクティブでのみ使用できます。他のリソース・プランを参照するプラン・ディレクティブでは使用できません。

- PARALLEL_DEGREE_LIMIT_P1

- ACTIVE_SESS_POOL_P1

- QUEUEING_P1

- SWITCH_GROUP

- SWITCH_TIME

- SWITCH_ESTIMATE

- SWITCH_IO_REQS

- SWITCH_IO_MEGABYTES

- MAX_EST_EXEC_TIME

- UNDO_POOL

- MAX_IDLE_TIME

- MAX_IDLE_BLOCKER_TIME

- SWITCH_FOR_CALL

- MAX_UTILIZATION_LIMIT

- アクティブなプランに含まれるリソース・コンシューマ・グループ数は、28以内にする必要があります。また、プランは最大28の子を持つことができます。

- プランとリソース・コンシューマ・グループには、異なる名前を使用する必要があります。

- アクティブなプラン内のどこかに、OTHER_GROUPSのプラン・ディレクティブが存在する必要があります。これによって、現在のアクティブ・プラン内に含まれるコンシューマ・グループのいずれにも属していないセッションに、OTHER_GROUPSのディレクティブで指定したリソースが割り当てられます。

これらの規則のいずれかに違反すると、VALIDATE_PENDING_AREAからエラー・メッセージが返されます。その場合は、変更を加えて問題を修正し、プロシージャを再度コールできます。

プラン・ディレクティブによって参照されない孤立したコンシューマ・グループを作成できます。これによって、当面は使用しないものの、将来的に実装するプランの一部となる、コンシューマ・グループを作成できます。

例: ペンディング・エリアの妥当性チェック

次のスクリプトは、ペンディング・エリアの妥当性をチェックするPL/SQLブロックです。

BEGIN
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
END;
/

関連項目:
「ペンディング・エリアの概要」

ペンディング・エリアの発行

変更の妥当性チェックを完了した後は、SUBMIT_PENDING_AREAプロシージャをコールして変更内容をアクティブにします。

SUBMITプロシージャでは妥当性チェックも実行されるため、妥当性チェック・プロシージャを別個にコールする必要はありません。ただし、プランを大幅に変更している場合は、通常、変更の妥当性チェックを段階的に実施する方が問題のデバッグ作業が容易になります。ペンディング・エリア内のすべての変更について妥当性チェックが成功するまで、変更は発行されません(つまり、アクティブになりません)。

SUBMIT_PENDING_AREAプロシージャは、変更の妥当性チェックとコミットに成功すると、ペンディング・エリアをクリア(解除)します。

注意:
VALIDATE_PENDING_AREAが正常に終了しても、SUBMIT_PENDING_AREAのコールが失敗する場合があります。これが起こるのは、VALIDATE_PENDING_AREAをコールしてからSUBMIT_PENDING_AREAをコールするまでの間に、削除しようとしているプランがインスタンスによってロードされた場合などです。

例: ペンディング・エリアの発行

次のスクリプトは、ペンディング・エリアを発行するPL/SQLブロックです。

BEGIN
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

関連項目:
「ペンディング・エリアの概要」

ペンディング・エリアのクリア

ペンディング・エリアを随時クリアするためのプロシージャも用意されています。次のスクリプトは、変更のすべてをペンディング・エリアからクリアし、ペンディング・エリアを解除するPL/SQLブロックです。

BEGIN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
END;
/

CLEAR_PENDING_AREAをコールした後、再び変更を実施するには、その前にCREATE_PENDING_AREAプロシージャをコールする必要があります。

関連項目:
「ペンディング・エリアの概要」

Oracle Database Resource Managerの有効化とプランの切替え

Oracle Database Resource Manager(リソース・マネージャ)を有効にするには、RESOURCE_MANAGER_PLAN初期化パラメータを設定します。このパラメータは、トップレベルのプランを指定し、現行のインスタンスで使用するプランを識別します。このパラメータでプランを指定しない場合、リソース・マネージャは有効になりません。

デフォルトでは、後で説明するように、事前に構成されているメンテナンス・ウィンドウの期間中を除き、リソース・マネージャは有効ではありません。

テキスト形式の初期化パラメータ・ファイルに次のように記述すると、データベースの起動時にリソース・マネージャがアクティブ化され、トップレベルのプランがmydb_planとして設定されます。

RESOURCE_MANAGER_PLAN = mydb_plan

DBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャまたはALTER SYSTEM文を使用して、リソース・マネージャをアクティブ化(または解除)したり、現行のトップレベル・プランを変更することもできます。

次のSQL文は、トップレベルのプランをmydb_planに設定し、リソース・マネージャをアクティブ化します(アクティブ化されていない場合)。

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'mydb_plan';

指定したプランがデータ・ディクショナリに存在しない場合は、エラー・メッセージが返されます。

Oracle Schedulerのウィンドウでのリソース・マネージャの自動有効化

リソース・プランを指定するOracle Schedulerのウィンドウがオープン状態の場合、リソース・マネージャは自動的にアクティブ化されます。スケジューラのウィンドウがクローズ状態の場合、そのウィンドウに関連付けられているリソース・プランは無効で、スケジューラのウィンドウがオープンする前に実行されていたリソース・プランが再度有効になります。(ウィンドウのオープン前に有効なリソース・プランがなかった場合、リソース・マネージャは無効になります。)したがって、ウィンドウのリソース・プランはあらゆるインスタンスで有効になります。

デフォルトでは、MAINTENANCE_WINDOW_GROUPウィンドウ・グループのメンバーである事前定義済のスケジューラ・ウィンドウであり、DEFAULT_MAINTENANCE_PLANリソース・プランを指定するメンテナンス・ウィンドウの間に一連の自動化されたメンテナンス・タスクが実行されることに注意してください。そのため、リソース・マネージャは、メンテナンス・ウィンドウ中にデフォルトでアクティブ化されます。必要な場合は、これらのメンテナンス・ウィンドウを変更して、別のリソース・プランを使用できます。

注意:
メンテナンス・ウィンドウに関連付けられたプランを変更する場合は、サブプランORA$AUTOTASK_SUB_PLANおよびコンシューマ・グループORA$DIAGNOSTICSが新しいプランに含まれていることを確認してください。

関連項目:

- 「ウィンドウ」

- 第26章「自動データベース・メンテナンス・タスクの管理」

Oracle Schedulerのウィンドウでのプラン切替えの無効化

場合によっては、スケジューラのウィンドウ境界でのリソース・マネージャ・プランの自動変更は、望ましくない可能性があります。たとえば、終了する必要のある重要なタスクがあり、リソース・マネージャ・プランにタスクの優先度を設定してある場合、設定を変更するまでは同じプランのままであることを想定しています。しかし、スケジューラのウィンドウはプランの設定後にアクティブになるため、タスクの実行中にリソース・マネージャ・プランが変更される可能性があります。

この状況を回避するには、次のSQL文に示すように、RESOURCE_MANAGER_PLAN初期化パラメータをシステムに必要なプランの名前に設定し、その名前の前に「FORCE:」を付加します。

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:mydb_plan';

接頭辞FORCEを使用することで、現行のリソース・プランの変更は、データベース管理者がRESOURCE_MANAGER_PLAN初期化パラメータの値を変更した場合のみ可能であることを示します。この制限を解除するには、プラン名の前に「FORCE:」を付加せずに、そのコマンドを再実行します。

DBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャには同様の機能があります。

関連項目:
DBMS_RESOURCE_MANAGER.SWITCH_PLANの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

リソース・マネージャの無効化

リソース・マネージャを無効にするには、次の手順を完了します。

1. 次のSQL文を発行します。

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';

2. すべてのOracle Schedulerのウィンドウからリソース・マネージャの関連を削除します。
そのためには、resource_plan属性のリソース・プランを参照するすべてのスケジューラのウィンドウについて、DBMS_SCHEDULER.SET_ATTRIBUTEプロシージャを使用して、resource_planを空の文字列('')に設定します。SYSユーザーでログインしていない場合は、SYSスキーマ名を使用してウィンドウ名を修飾します。スケジューラのウィンドウは、DBA_SCHEDULER_WINDOWSデータ・ディクショナリ・ビューで表示できます。詳細は、「ウィンドウの変更」および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

注意:
デフォルトでは、すべてのメンテナンス・ウィンドウがDEFAULT_MAINTENANCE_PLANリソース・プランを参照します。リソース・マネージャを完全に無効にするには、すべてのメンテナンス・ウィンドウを変更してこのプランを削除する必要があります。ただし、自動化メンテナンス・タスクによるリソース使用が規制されなくなるため、他のセッションのパフォーマンスに悪影響を与える可能性があることに注意してください。メンテナンス・ウィンドウの詳細は、第26章「自動データベース・メンテナンス・タスクの管理」を参照してください。

各種の方法を組み合せたOracle Database Resource Managerの例

ここでは、リソース・プランの例をいくつか示します。ここで取り上げる例は、次のとおりです。

- 複数レベルのプランの例

- 最大使用率の制限属性を使用した例

- 各種のリソース割当て方法を使用した例

- ディレクティブ属性を使用したパラレル・ステートメントの管理の例

- オラクル社が提供する複合ワークロード・プラン

複数レベルのプランの例

次のスクリプトは、図27-3に示されている複数レベルのプランを作成するPL/SQLブロックです。デフォルトのリソース割当て方法の設定は、すべてのプランとリソース・コンシューマ・グループに使用されます。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'bugdb_plan',
COMMENT => 'Resource plan/method for bug users sessions');
DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'maildb_plan',
COMMENT => 'Resource plan/method for mail users sessions');
DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'mydb_plan',
COMMENT => 'Resource plan/method for bug and mail users sessions');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Online_group',
COMMENT => 'Resource consumer group/method for online bug users sessions');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Batch_group',
COMMENT => 'Resource consumer group/method for batch job bug users sessions');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Bug_Maint_group',
COMMENT => 'Resource consumer group/method for users sessions for bug db maint');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Users_group',
COMMENT => 'Resource consumer group/method for mail users sessions');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Postman_group',
COMMENT => 'Resource consumer group/method for mail postman');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Mail_Maint_group',
COMMENT => 'Resource consumer group/method for users sessions for mail db maint');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan',
GROUP_OR_SUBPLAN => 'Online_group',
COMMENT => 'online bug users sessions at level 1', MGMT_P1 => 80, MGMT_P2=> 0);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan',
GROUP_OR_SUBPLAN => 'Batch_group',
COMMENT => 'batch bug users sessions at level 1', MGMT_P1 => 20, MGMT_P2 => 0,
PARALLEL_DEGREE_LIMIT_P1 => 8);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan',
GROUP_OR_SUBPLAN => 'Bug_Maint_group',
COMMENT => 'bug maintenance users sessions at level 2', MGMT_P1 => 0, MGMT_P2 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan',
GROUP_OR_SUBPLAN => 'OTHER_GROUPS',
COMMENT => 'all other users sessions at level 3', MGMT_P1 => 0, MGMT_P2 => 0,
MGMT_P3 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
GROUP_OR_SUBPLAN => 'Postman_group',
COMMENT => 'mail postman at level 1', MGMT_P1 => 40, MGMT_P2 => 0);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
GROUP_OR_SUBPLAN => 'Users_group',
COMMENT => 'mail users sessions at level 2', MGMT_P1 => 0, MGMT_P2 => 80);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
GROUP_OR_SUBPLAN => 'Mail_Maint_group',
COMMENT => 'mail maintenance users sessions at level 2', MGMT_P1 => 0, MGMT_P2 => 20);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
GROUP_OR_SUBPLAN => 'OTHER_GROUPS',
COMMENT => 'all other users sessions at level 3', MGMT_P1 => 0, MGMT_P2 => 0,
MGMT_P3 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'mydb_plan',
GROUP_OR_SUBPLAN => 'maildb_plan',
COMMENT=> 'all mail users sessions at level 1', MGMT_P1 => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'mydb_plan',
GROUP_OR_SUBPLAN => 'bugdb_plan',
COMMENT => 'all bug users sessions at level 1', MGMT_P1 => 70);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

妥当性チェックはSUBMIT_PENDING_AREAによって暗黙的に実行されるので、直前のVALIDATE_PENDING_AREAのコールはオプションです。

図27-3 複数レベルのプラン・スキーマ

このプラン・スキーマでは、次のようにCPUリソースが割り当てられています。

- mydb_planでは、CPUの30%がmaildb_planサブプランに割り当てられ、70%がbugdb_planサブプランに割り当てられます。サブプランは両方ともレベル1です。mydb_plan自体にはレベル1の下にレベルがないため、レベル1で一方のサブプランが使用していないリソース割当ては、その兄弟サブプランが使用できます。したがって、maildb_planがCPUの20%のみを使用する場合、CPUの80%はbugdb_planが使用できます。

- maildb_planおよびbugdb_planでは、レベル1、2および3で割当てを定義します。これらのサブプランの各レベルは、その親プランmydb_planのレベルから独立しています。つまり、プラン・スキーマのすべてのプランとサブプランには、独自のレベル1、レベル2、レベル3などがあります。

- maildb_planに割り当てられたCPUの30%について、その40%(実質的にはCPU合計の12%)はレベル1のPostman_groupに割り当てられます。Postman_groupにはレベル1で兄弟がないため、レベル1では暗黙的に60%が残っています。この60%は、レベル2のUsers_groupとMail_Maint_groupがそれぞれ80%と20%の割合で共有します。この60%の他に、Users_groupとMail_Maint_groupは、レベル1のPostman_groupが使用していないリソース(40%の一部)も使用できます。

- 複数レベルのプランの場合、未使用のリソースは同じレベルの兄弟ではなく、次の下位レベルのコンシューマ・グループまたはサブプランに再割当てされるため、レベル2のUsers_groupとMail_Maint_groupのどちらでも使用されないCPUリソースはOTHER_GROUPSに割り当てられます。したがって、Users_groupが80%ではなく70%しか使用していない場合に、残りの10%をMail_Maint_groupが使用することはできません。この10%は、レベル3のOTHER_GROUPSのみが使用できます。

- bugdb_planサブプランに割り当てられたCPUの70%は、そのコンシューマ・グループに同様に割り当てられます。Online_groupまたはBatch_groupがその割当てのすべてを使用していない場合、残りはBug_Maint_groupが使用できます。Bug_Maint_groupがその割当てのすべてを使用していない場合、残りはOTHER_GROUPSに割り当てられます。

最大使用率の制限属性を使用した例

MAX_UTILIZATION_LIMITディレクティブ属性を使用すると、アプリケーションのCPU使用率を制限できます。この属性の一般的な使用例として、データベース統合をあげることができます。

データベースの統合では、次の処理が必要になる場合があります。

- あるアプリケーションが別のアプリケーションのパフォーマンスに及ぼす影響を管理します。
このパフォーマンスの影響を管理する方法として、アプリケーションごとにコンシューマ・グループを作成し、各コンシューマ・グループにリソースを割り当てる方法をあげることができます。

- 各アプリケーションの使用率を制限します。
一般的に、CPUリソースの特定の使用率を各コンシューマ・グループに割り当てること以外に、グループごとに最大CPU使用率を制限することが必要になる場合があります。この制限によって、他のすべてのコンシューマ・グループがアイドル状態のときに、あるコンシューマ・グループがすべてのCPUリソースを使用することを回避できます。

場合によっては、他のアプリケーションからのワークロードに関係なく、すべてのアプリケーション・ユーザーに一貫性のあるパフォーマンスを提供することが必要になる場合があります。そのためには、リソース・プランのコンシューマ・グループごとに最大使用率の制限を指定します。

次の例は、MAX_UTILIZATION_LIMITリソース・プラン・ディレクティブ属性を使用して次のことを行う方法を示しています。

- データベースCPU使用率の合計の制限

- リソース集中型の問合せの検査

- アプリケーションのCPU使用率の制限

- メンテナンス・ウィンドウの期間中のCPU使用率の制限

例1: 全体的なデータベースCPU使用率の制限

この例では、データベース負荷にかかわらず、Oracle Databaseからのシステム・ワークロードはCPUの90%を超えません。サーバーを共有する他のアプリケーション用にCPUの10%を残します。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

DBMS_RESOURCE_MANAGER.CREATE_PLAN(
PLAN    => 'MAXCAP_PLAN',
COMMENT => 'Limit overall database CPU');

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
PLAN              => 'MAXCAP_PLAN',
GROUP_OR_SUBPLAN  => 'OTHER_GROUPS',
COMMENT           => 'This group is mandatory',
MAX_UTILIZATION_LIMIT => 90);

DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

OTHER_GROUPSのプラン・ディレクティブ以外のプラン・ディレクティブはないため、すべてのセッションはOTHER_GROUPSにマップされます。

例2: リソース集中型の問合せの検査

この例では、リソース集中型の問合せは最大使用率の制限が20%のコンシューマ・グループに切り替えられ、ユーザーが介入するまでに使用されるリソース量は制限されます。リソース集中型の問合せとは、ここでは10分を超えるCPU時間を必要とする問合せとします。セッション・マッピング・ルールによってすべてのセッションはSTART_GROUPで開始されると想定します。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'START_GROUP',
COMMENT        => 'Sessions start here');

DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'QUARANTINE_GROUP',
COMMENT        => 'Sessions switched here to quarantine them');

DBMS_RESOURCE_MANAGER.CREATE_PLAN(
PLAN    => 'Quarantine_plan',
COMMENT => 'Quarantine runaway queries');

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
PLAN                  => 'Quarantine_plan',
GROUP_OR_SUBPLAN      => 'START_GROUP',
COMMENT               => 'Max CPU 10 minutes before switch',
MGMT_P1               => 75,
switch_group          => 'QUARANTINE_GROUP',
switch_time           => 600);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
PLAN                  => 'Quarantine_plan',
GROUP_OR_SUBPLAN      => 'OTHER_GROUPS',
COMMENT               => 'Mandatory',
MGMT_P1               => 25);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
PLAN                  => 'Quarantine_plan',
GROUP_OR_SUBPLAN      => 'QUARANTINE_GROUP',
COMMENT               => 'Limited CPU',
MGMT_P2               => 100,
MAX_UTILIZATION_LIMIT => 20);

DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

注意:
QUARANTINE_GROUPの最大使用率の制限を0(ゼロ)に設定して、リソース集中型の問合せを完全に検査できますが、このようにしないことをお薦めします。他のセッションが必要とするリソース(PGAメモリー、ロックなど)をリソース集中型の問合せが保持している場合、0(ゼロ)を割り当てる設定によりデッドロックが発生する場合があります。

例3: アプリケーションのCPUの制限

この例では、アプリケーション・セッションはマッピング・ルールによって4つのアプリケーション・グループのいずれかにマップされると想定します。各アプリケーション・グループには30%の最大使用率制限が割り当てられています。これにより、1つのアプリケーションのCPU使用率は30%に制限されます。MAX_UTILIZATION_LIMIT値の合計が100%を超えていますが、このことはすべてのアプリケーションが同時にアクティブにはならない状況において許容されます。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'APP1_GROUP',
COMMENT        => 'Apps group 1');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'APP2_GROUP',
COMMENT        => 'Apps group 2');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'APP3_GROUP',
COMMENT        => 'Apps group 3');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'APP4_GROUP',
COMMENT        => 'Apps group 4');

DBMS_RESOURCE_MANAGER.CREATE_PLAN(
PLAN    => 'apps_plan',
COMMENT => 'Application consolidation');

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'apps_plan',
GROUP_OR_SUBPLAN      => 'APP1_GROUP',
COMMENT               => 'Apps group 1',
MAX_UTILIZATION_LIMIT => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'apps_plan',
GROUP_OR_SUBPLAN      => 'APP2_GROUP',
COMMENT               => 'Apps group 2',
MAX_UTILIZATION_LIMIT => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'apps_plan',
GROUP_OR_SUBPLAN      => 'APP3_GROUP',
COMMENT               => 'Apps group 3',
MAX_UTILIZATION_LIMIT => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'apps_plan',
GROUP_OR_SUBPLAN      => 'APP4_GROUP',
COMMENT               => 'Apps group 4',
MAX_UTILIZATION_LIMIT => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'apps_plan',
GROUP_OR_SUBPLAN      => 'OTHER_GROUPS',
COMMENT               => 'Mandatory',
MAX_UTILIZATION_LIMIT => 20);

DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

4つすべてのアプリケーション・グループが割り当てられたCPU(この例では30%)を完全に使用できる場合は、各アプリケーション・グループに割り当てられる最小CPUは、すべてのアプリケーション・グループの制限全体に占めるアプリケーション・グループの制限の比率として計算されます。この例では、4つすべてのアプリケーション・グループに最大使用率の制限として30%が割り当てられています。このため、4つすべてのグループがそれぞれの制限を完全に使用する場合、各グループに対するCPU割当ては30/(30+30+30+30)で25%になります。

例4 - コンシューマ・グループおよびサブプランに最大使用率の制限を指定する

次の例では、図27-4に示すように、サブプランおよびそのサブプラン内のコンシューマ・グループに対してMAX_UTILIZATION_LIMITを設定した場合に、最大使用率の制限がどのように計算されるかについて説明します。わかりやすくするために、OTHER_GROUPSコンシューマ・グループを指定する要件は無視し、リソース・プラン・ディレクティブは(プランの一部であっても)省略されています。

図27-4 サブプランおよびコンシューマ・グループに最大使用率が設定されたリソース・プラン

次のPL/SQLブロックは、図27-4で説明するプランを作成します。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'APP1_GROUP',
COMMENT        => 'Group for application #1');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'APP2_OLTP_GROUP',
COMMENT        => 'Group for OLTP activity in application #2');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'APP2_ADHOC_GROUP',
COMMENT        => 'Group for ad-hoc queries in application #2');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
CONSUMER_GROUP => 'APP2_REPORT_GROUP',
COMMENT        => 'Group for reports in application #2');
DBMS_RESOURCE_MANAGER.CREATE_PLAN(
PLAN    => 'APPS_PLAN',
COMMENT => 'Plan for managing 3 applications');
DBMS_RESOURCE_MANAGER.CREATE_PLAN(
PLAN    => 'APP2_SUBPLAN',
COMMENT => 'Subplan for managing application #2',
SUB_PLAN => TRUE);
DBMS_RESOURCE_MANAGER.CREATE_PLAN(
PLAN    => 'APP2_REPORTS_SUBPLAN',
COMMENT => 'Subplan for managing reports in application #2',
SUB_PLAN => TRUE);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'APPS_PLAN',
GROUP_OR_SUBPLAN      => 'APP1_GROUP',
COMMENT               => 'Limit CPU for application #1 to 40%',
MAX_UTILIZATION_LIMIT => 40);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'APPS_PLAN',
GROUP_OR_SUBPLAN      => 'APP2_SUBPLAN',
COMMENT               => 'Limit CPU for application #2 to 40%',
MAX_UTILIZATION_LIMIT => 40);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'APP2_SUBPLAN',
GROUP_OR_SUBPLAN      => 'APP2_OLTP_GROUP',
COMMENT               => 'Limit CPU for OLTP to 90% of application #2',
MAX_UTILIZATION_LIMIT => 90);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'APP2_SUBPLAN',
GROUP_OR_SUBPLAN      => 'APP2_REPORTS_SUBPLAN',
COMMENT               => 'Subplan for ad-hoc and normal reports for application #2');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'APP2_REPORTS_SUBPLAN',
GROUP_OR_SUBPLAN      => 'APP2_ADHOC_GROUP',
COMMENT               => 'Limit CPU for ad-hoc queries to 50% of application #2 reports',
MAX_UTILIZATION_LIMIT => 50);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'APP2_REPORTS_SUBPLAN',
GROUP_OR_SUBPLAN      => 'APP2_REPORT_GROUP',
COMMENT               => 'Limit CPU for reports to 50% of application #2 reports',
MAX_UTILIZATION_LIMIT => 50);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN                  => 'APPS_PLAN',
GROUP_OR_SUBPLAN      => 'OTHER_GROUPS',
COMMENT               => 'No directives for default users');
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

この例では、コンシューマ・グループAPP1_GROUPおよびサブプランAPP2_SUBPLANの最大CPU使用率は、40%に設定されます。コンシューマ・グループAPP2_ADHOC_GROUPおよびAPP2_REPORT_GROUPの制限は、50%に設定されます。

サブプランAPP2_REPORTS_SUBPLANに指定されている制限がないため、その親サブプランAPP2_SUBPLANの制限を継承して40%になります。コンシューマ・グループAPP2_REPORT_GROUPの絶対上限は、その親サブプランの50%として計算され、その結果、40%の50%、つまり20%になります。

同じく、コンシューマ・グループAPP2_ADHOC_GROUPはサブプランAPP2_REPORTS_SUBPLANに含まれているため、その制限は親サブプランの割合として計算されます。コンシューマ・グループAPP2_ADHOC_GROUPの最大使用率の制限は40%の50%、つまり20%になります。

コンシューマ・グループAPP2_OLTP_GROUPの最大CPU使用率は、90%に設定されます。APP2_OLTP_GROUPの親サブプランAPP2_SUBPLANの制限は40%です。このため、グループAPP2_OLTP_GROUPの絶対上限は40%の90%、つまり36%になります。

各種のリソース割当て方法を使用した例

ここで示す例は、パッケージ化されたEnterprise Resource Planning(ERP)またはCustomer Relationship Management(CRM)アプリケーションをサポートするデータベース用のプランを表します。このような環境で必要な処理は多種多様です。大規模なパラレル問合せを含む長時間実行のバッチ・ジョブとともに、短いトランザクションや短い問合せが混在している場合があります。その目的は、バッチ・ジョブをパラレルに実行しながら、オンライン・トランザクション処理(OLTP)の適切な応答時間を得ることにあります。

次の表にプランがまとめられています。

グループ

CPUリソース割当て%

アクティブ・セッション・プール・パラメータ

コンシューマ・グループの自動切替え

最大見積り実行時間

UNDOプール

oltp

レベル1: 80%

切替え先グループ: batch
切替え時間: 3秒

200K

batch

レベル2: 100%

プール・サイズ: 5
タイムアウト: 600秒

--

3600秒

--

OTHER_GROUPS

レベル3: 100%

--

--

--

レベル1のoltpにCPUの80%のみを割り当てることで、batchには最低20%が保証され、さらに、oltpが使用しないCPUリソースを使用できます。ただし、OTHER_GROUPSに対するCPUリソースの保証はありません。それは、batchがその割当てのすべてを使用していない場合にのみ、CPUリソースを取得します。類似するプランでは、レベル1のoltpに80%、batchに20%が付与され、レベル2のOTHER_GROUPSには100%が付与されます。このプランでは、oltpが使用していないCPU割当てが、batchではなく、OTHER_GROUPSに付与されます。

次の文は、この表のプランをerp_planという名前で作成します。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'erp_plan',
COMMENT => 'Resource plan/method for ERP Database');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'oltp',
COMMENT => 'Resource consumer group/method for OLTP jobs');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'batch',
COMMENT => 'Resource consumer group/method for BATCH jobs');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan',
GROUP_OR_SUBPLAN => 'oltp', COMMENT => 'OLTP sessions', MGMT_P1 => 80,
SWITCH_GROUP => 'batch', SWITCH_TIME => 3, UNDO_POOL => 200);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan',
GROUP_OR_SUBPLAN => 'batch', COMMENT => 'BATCH sessions', MGMT_P2 => 100,
ACTIVE_SESS_POOL_P1 => 5, QUEUEING_P1 => 600, MAX_EST_EXEC_TIME => 3600);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan',
GROUP_OR_SUBPLAN => 'OTHER_GROUPS', COMMENT => 'mandatory', MGMT_P3 => 100);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

ディレクティブ属性を使用したパラレル・ステートメントの管理の例

一般的に、データ・ウェアハウス環境は、リソース要件が様々に異なる多様なユーザーで構成されています。処理要件が共通するユーザーは、コンシューマ・グループにグループ化されます。コンシューマ・グループURGENT_GROUPは、経営陣に重要な情報を提供するためのレポートを実行するユーザーで構成されています。このグループは、多数のパラレル問合せを生成します。コンシューマ・グループETL_GROUPに属するユーザーは、ソース・システムからデータをインポートし、抽出、変換、ロード(ETL)の各操作を実行します。グループOTHER_GROUPSには、非定型問合せを実行するユーザーが含まれています。パフォーマンスを最適に保つと同時に、このような多様なユーザー・グループの要件を管理する必要があります。

次のディレクティブ属性を使用すると、パラレル・ステートメントの実行を管理および最適化できます。

- MGMT_Pn

- PARALLEL_TARGET_PERCENTAGE

- PARALLEL_QUEUE_TIMEOUT

- PARALLEL_DEGREE_LIMIT_P1

表27-3に、データ・ウェアハウス・ユーザーのニーズを管理するために使用可能なプランDW_PLANのリソース割当てを示します。このプランには、コンシューマ・グループURGENT_GROUP、ETL_GROUPおよびOTHER_GROUPSが含まれています。この例は、1つのアプリケーションまたはコンシューマ・グループですべての使用可能なパラレル・サーバーを使用しないことが確実である場合のディレクティブ属性の使用例を示しています。

表27-3 パラレル・ステートメント・ディレクティブが設定されたリソース・プラン

コンシューマ・グループ

レベル1のCPU割当て

レベル2のCPU割当て

レベル3のCPU割当て

PARALLEL_DEGREE_LIMIT_P1

PARALLEL_TARGET_PERCENTAGE

PARALLEL_QUEUE_TIMEOUT

URGENT_GROUP

100%

12

ETL_GROUP

100%

8

50%

OTHER_GROUPS

100%

2

50%

360

この例では、パラメータPARALLEL_SERVERS_TARGETが64に設定されており、使用可能なパラレル・サーバーの数が64台ということになります。パラレル・ステートメントの実行に使用できるパラレル・サーバーの総数は64で、それを超えると、PARALLEL_DEGREE_POLICYがAUTOに設定されたURGENT_GROUPセッションはパラレル・ステートメント・キューに追加されます。ETL_GROUPおよびOTHER_GROUPSのPARALLEL_TARGET_PERCENTAGE属性は50%で、これらのグループが使用できるパラレル・サーバーの最大数は64の50%、つまり各グループとも32台のパラレル・サーバーを使用できます。

コンシューマ・グループからのパラレル・ステートメントがキューされるのは、PARALLEL_DEGREE_POLICYパラメータがAUTOに設定され、コンシューマ・グループのアクティブなサーバーの総数がPARALLEL_SERVERS_TARGETよりも高くなっている場合のみです。PARALLEL_DEGREE_POLICYがMANUALまたはLIMITEDに設定されている場合、パラレル・ステートメントは、十分な数のパラレル・サーバーが使用できるときにのみ、実行されます。このようなパラレル・ステートメントで使用されるパラレル・サーバーは、コンシューマ・グループで使用されるパラレル・サーバーの総数にカウントされます。ただし、パラレル・ステートメントはパラレル・ステートメント・キューに追加されません。

ヒント:
優先度が低いアプリケーションの場合、PARALLEL_DEGREE_LIMIT_P1およびPARALLEL_TARGET_PERCENTAGEに小さい値を設定するのが一般的です。

URGENT_GROUPSにはレベル1で100%が割り当てられているため、そのパラレル・ステートメントはパラレル・ステートメント・キューの他のコンシューマ・グループよりも前に常にキューされます。URGENT_GROUPSにはPARALLEL_TARGET_PERCENTAGEディレクティブ属性がありませんが、このグループのセッションによって発行されたステートメントは、そのステートメントを実行できるだけのパラレル・サーバーが使用可能でない場合にはキューされます。

PARALLEL_DEGREE_LIMIT_P1で表される並列度は、URGENT_GROUPの場合12に設定されます。このため、URGENT_GROUPからの各パラレル・ステートメントでは、最大12台のパラレル・サーバーを使用できます。同じく、ETL_GROUPからの各パラレル・ステートメントでは最大8台のパラレル・サーバーを使用でき、OTHER_GROUPSからの各パラレル・ステートメントでは2台のパラレル・サーバーを使用できます。

たとえば、ある時間にパラレル・ステートメントがETL_GROUPからのみ実行され、このパラレル・ステートメントによって、このグループで使用可能な32パラレル・サーバーのうち26が使用されているとします。このコンシューマ・グループからのセッションのPARALLEL_DEGREE_POLICYは、AUTOに設定されています。別のパラレル・ステートメントがPARALLEL_DEGREE_LIMIT_P1属性が8の設定でETL_GROUPから起動されても、ETL_GROUPで使用可能なパラレル・サーバーは、32-26=6パラレル・サーバーであるので、この問合せはすぐには実行されません。この新しいパラレル・ステートメントは、必要なパラレル・サーバー数がETL_GROUPで使用可能になるまでキューで待機します。

ETL_GROUPのパラレル・ステートメントの実行中、OTHER_GROUPSからパラレル・ステートメントが開始されたとします。このグループでは32台のパラレル・サーバーを使用できるので、パラレル・ステートメントは実行されます。

OTHER_GROUPSのPARALLEL_QUEUE_TIMEOUT属性は、360に設定されています。このため、このグループからのパラレル・ステートメントは、360秒間のみパラレル・サーバーのキューに残ることができます。この時間が経過すると、パラレル・ステートメントはキューから削除され、エラーORA-07454が返されます。

オラクル社が提供する複合ワークロード・プラン

Oracle Databaseには、事前定義済のリソース・プランMIXED_WORKLOAD_PLAN (バッチ操作よりも対話型の操作を優先するプラン)と、Oracleが推奨する必須のサブプランとコンシューマ・グループが用意されています。MIXED_WORKLOAD_PLANは、次のように定義されています。

グループまたはサブプラン

CPUリソース割当て

レベル1

レベル2

レベル3

コンシューマ・グループの自動切替え

最大並列度

BATCH_GROUP

100%

INTERACTIVE_GROUP

85%

切替え先グループ: BATCH_GROUP
切替え時間: 60秒

コールに対する切替え: TRUE

1

ORA$AUTOTASK_SUB_PLAN

5%

ORA$DIAGNOSTICS

5%

OTHER_GROUPS

5%

SYS_GROUP

100%

このプランのINTERACTIVE_GROUPは短いトランザクションを対象にしているため、60秒を超えるCPU時間を使用するコールは、長いバッチ操作を対象にしたBATCH_GROUPに自動的に切り替わります。

使用環境に適する場合は、この事前定義済のプランを使用できます。(このプランは変更したり、使用しない場合に削除できます。)BATCH_GROUPおよびINTERACTIVE_GROUPの名前に特別な意味はありません。この名前はグループの用途を反映しているだけで、ユーザーは任意に、これらのグループにアプリケーション・セッションをマップし、それに応じてCPUリソースの割当て使用率を調整して、使用する対話型アプリケーションおよびバッチ・アプリケーションにあわせた適切なリソース管理を実現できます。たとえば、対話型アプリケーションをINTERACTIVE_GROUPコンシューマ・グループの下で実行するには、ユーザー名、サービス名、プログラム名、モジュール名または処理に基づいて、このコンシューマ・グループに対話型アプリケーションのユーザー・セッションをマップする必要があります(「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照)。同じように、BATCH_GROUPにバッチ・アプリケーションをマップする必要があります。最後に、このプランを有効にする必要があります(「Oracle Database Resource Managerの有効化とプランの切替え」を参照)。

このプランの他のリソース・コンシューマ・グループとサブプランについては、表27-4および表27-5を参照してください。

単一サーバーにおける複数のデータベース・インスタンスの管理

Oracle Databaseには、複数のデータベース・インスタンスを実行する複数CPUサーバーでCPU割当てを管理する方法が用意されています。この方法はインスタンス・ケージングと呼ばれます。インスタンス・ケージングとOracle Database Resource Manager(リソース・マネージャ)が連携して、複数インスタンス間で必要なサービス・レベルをサポートします。

この項の内容は次のとおりです。

- インスタンス・ケージングの概要

- インスタンス・ケージングの有効化

インスタンス・ケージングの概要

1台のマルチCPU搭載サーバーで複数のOracle Databaseインスタンスを実行するように決定することがあります。その代表的な理由は、サーバーの統合、つまり使用できるハードウェア・リソースをより効率的に使用するためです。1台のサーバーで複数のインスタンスが実行されている場合、インスタンスはCPUリソースを競い合います。1つのリソース集中型のデータベース・インスタンスが、他のインスタンスのパフォーマンスを大きく低下させる場合があります。たとえば、16個のCPUのシステムで4つのデータベース・インスタンスが存在する場合に、ある1つのデータベース・インスタンスに大きな負荷がかかっている間、オペレーティング・システムによって、このインスタンスの実行にCPUの大半が使用される可能性があります。これにより、他の3つのインスタンスのパフォーマンスが低下することがあります。このようなCPU割当ては、オペレーティング・システムのみによって決定され、通常はユーザーが制御することはできません。

各データベース・インスタンスのCPU使用率を制限する簡単な方法は、インスタンス・ケージングを使用することです。インスタンス・ケージングは、初期化パラメータを使用して、インスタンスが同時に使用できるCPU数を制限する方法です。前の例で、インスタンス・ケージングを使用して4つのインスタンスそれぞれのCPU数を4に制限すると、1つのインスタンスによって他のインスタンスが妨害される可能性が低くなります。4つのCPUに制約されると、インスタンスはCPUにバインドされます。このとき、リソース・マネージャによって、インスタンスに対して設定したリソース・プランに基づき、様々なデータベース・セッション間でのCPUの割当てが開始されます。このように、インスタンス・ケージングとリソース・マネージャによって、単一サーバーで複数のインスタンスを管理する簡単で効果的な方法が提供されます。

サーバーのインスタンス・ケージングには、次の2つの一般的なアプローチがあります。

- オーバープロビジョニング: このアプローチは、開発システムやテスト・システムなどの重要度の低いデータベースや、負荷が少なく、かつ重要度の低い本番システムに対して使用します。このアプローチでは、各インスタンスのCPU制限の合計がシステム上の実際のCPU数を超過します。たとえば、4つのデータベース・インスタンスがある4 CPUシステムで、各インスタンスを3つのCPUに制限します。この方法でサーバーがオーバープロビジョンされると、インスタンスが相互にパフォーマンスに影響を及ぼします。ただし、インスタンス・ケージングによってその影響は制限され、パフォーマンスはある程度予測可能になります。ただし、インスタンスの1つに高負荷の期間がある場合、CPUでそれを処理できます。1つ以上のインスタンスが頻繁にアイドルまたは低負荷になる可能性があるため、このアプローチは重要度の低いシステムに適切です。

- パーティション化: このアプローチは、インスタンスが相互に妨害しないようにする必要がある、重要な本番システムに適しています。すべての割当ての合計がサーバー上のCPU数と等しくなるようにCPUを割り当てます。たとえば、16 CPUサーバー・システムで、最初のインスタンスに8つのCPU、2番目のインスタンスに4つのCPU、残りの2つのインスタンスに2つずつのCPUを割り当てます。CPUリソースを各データベース・インスタンス専用にすることによって、1つのインスタンスへの負荷が別のインスタンスに影響を及ぼすことがなくなり、各インスタンスは想定したとおりに実行されます。

最大使用率の制限が適用されたインスタンス・ケージングの使用

リソース・プランでインスタンス・ケージングを有効にし、最大使用率の制限を設定した場合、絶対上限は割り当てられたCPUリソースの割合として計算されます。

たとえば、インスタンス・ケージングを有効にし、CPU_COUNTを4に設定し、コンシューマ・グループの最大使用率の制限が50%である場合、コンシューマ・グループは4つのCPUの最大50%、つまり2つのCPUを使用できます。

インスタンス・ケージングの有効化

インスタンス・ケージングを有効化するには、サーバー上の各インスタンスに対して次の処理を実行します。

1. リソース・プランを割り当てることでリソース・マネージャを有効化し、MGMT_P1からMGMT_P8のパラメータを使用してリソース・プランにCPUディレクティブがあるようにします。
手順については、「Oracle Database Resource Managerの有効化とプランの切替え」を参照してください。

2. cpu_count初期化パラメータを設定します。
これは動的パラメータであり、次の文を使用して設定できます。

ALTER SYSTEM SET CPU_COUNT = 4;

コンシューマ・グループ、プランおよびディレクティブのメンテナンス

ここでは、Oracle Database Resource Manager(リソース・マネージャ)のコンシューマ・グループ、リソース・プランおよびリソース・プラン・ディレクティブをメンテナンスする方法について説明します。メンテナンス・タスクは、DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用して実行します。この章では、次の項目について説明します。

- コンシューマ・グループの更新

- コンシューマ・グループの削除

- プランの更新

- プランの削除

- リソース・プラン・ディレクティブの更新

- リソース・プラン・ディレクティブの削除

関連項目:

- 事前定義のコンシューマ・グループ・マッピング・ルール

- DBMS_RESOURCE_MANAGER PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

コンシューマ・グループの更新

コンシューマ・グループ情報を更新するには、UPDATE_CONSUMER_GROUPプロシージャを使用します。最初にペンディング・エリアを作成し、発行する前に、コンシューマ・グループを更新する必要があります。引数を指定せずにUPDATE_CONSUMER_GROUPプロシージャを実行すると、データ・ディクショナリ内のコンシューマ・グループ情報は変更されません。

コンシューマ・グループの削除

DELETE_CONSUMER_GROUPプロシージャは、指定されたコンシューマ・グループを削除します。最初にペンディング・エリアを作成し、発行する前に、コンシューマ・グループを削除する必要があります。コンシューマ・グループを削除すると、そのグループを初期コンシューマ・グループとして割り当てられているすべてのユーザーには、初期コンシューマ・グループとしてOTHER_GROUPSが割り当てられます。削除したコンシューマ・グループに属している現在実行中のセッションはすべて、コンシューマ・グループ・マッピング・ルールに基づいて新しいコンシューマ・グループに割り当てられます。マッピングでセッションのコンシューマ・グループが見つからなかった場合、そのセッションはOTHER_GROUPSに切り替わります。

リソース・プラン・ディレクティブが参照しているコンシューマ・グループは削除できません。

プランの更新

プラン情報を更新するには、UPDATE_PLANプロシージャを使用します。最初にペンディング・エリアを作成し、発行する前に、プランを更新する必要があります。引数を指定せずにUPDATE_PLANプロシージャを実行すると、データ・ディクショナリ内のプラン情報は変更されません。次のスクリプトは、COMMENTパラメータを更新するPL/SQLブロックです。

BEGIN
DBMS_RESOURCE_MANAGER.UPDATE_PLAN(
PLAN => 'DAYTIME',
NEW_COMMENT => '50% more resources for OLTP applications');
END;
/

プランの削除

DELETE_PLANプロシージャは、指定したプランと、それに対応付けられているすべてのプラン・ディレクティブを削除します。最初にペンディング・エリアを作成し、発行する前に、プランを削除する必要があります。

次のスクリプトは、great_breadプランとそのディレクティブを削除するPL/SQLブロックです。

BEGIN
DBMS_RESOURCE_MANAGER.DELETE_PLAN(PLAN => 'great_bread');
END;
/

削除したディレクティブが参照していたリソース・コンシューマ・グループは削除されませんが、great_breadプランとの関連は解除されます。

DELETE_PLAN_CASCADEプロシージャは、指定のプランとその子孫すべて(プラン・ディレクティブ、および必須のマークが付けられていないサブプランとリソース・コンシューマ・グループ)を削除します。エラーが発生したDELETE_PLAN_CASCADEはロールバックされ、プランは変更されません。

現在アクティブなプランは削除できません。

リソース・プラン・ディレクティブの更新

プラン・ディレクティブを更新するには、UPDATE_PLAN_DIRECTIVEプロシージャを使用します。最初にペンディング・エリアを作成し、発行する前に、リソース・プラン・ディレクティブを更新する必要があります。UPDATE_PLAN_DIRECTIVEプロシージャの引数を指定しない場合、ディレクティブ内の対応パラメータは変更されません。

次の例ではディレクティブにコメントを追加します。

BEGIN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE(
PLAN             => 'SIMPLE_PLAN1',
GROUP_OR_SUBPLAN => 'MYGROUP1',
NEW_COMMENT      => 'Higher priority'
);
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

コメントをクリアする(NULLにする)には、NULL文字列('')を渡します。数値のディレクティブ・パラメータをクリアする(0またはNULLにする)には、新しい値を-1に設定します。

BEGIN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE(
PLAN                  => 'SIMPLE_PLAN1',
GROUP_OR_SUBPLAN      => 'MYGROUP1',
NEW_MAX_EST_EXEC_TIME => -1
);
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

リソース・プラン・ディレクティブの削除

リソース・プラン・ディレクティブを削除するには、DELETE_PLAN_DIRECTIVEプロシージャを使用します。最初にペンディング・エリアを作成し、発行する前に、リソース・プラン・ディレクティブを削除する必要があります。

データベース・リソース・マネージャの構成とステータスの表示

Oracle Database Resource Manager (リソース・マネージャ)の現在の構成とステータスを表示するには、いくつかの静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューを使用できます。この項では、次の例を示します。

- ユーザーまたはロールに権限付与されたコンシューマ・グループの表示

- プラン情報の表示

- セッションの現行コンシューマ・グループの表示

- 現在アクティブなプランの表示

関連項目:
すべての静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ユーザーまたはロールに権限付与されたコンシューマ・グループの表示

DBA_RSRC_CONSUMER_GROUP_PRIVSビューには、ユーザーまたはロールに付与されているコンシューマ・グループが表示されます。具体的には、ユーザーまたはロールが属することが許可されているグループ、または切替え可能なグループが表示されます。たとえば、次に示すビューの場合、ユーザーSCOTTは常にSALESコンシューマ・グループで開始され、特定の付与によってMARKETINGグループに切り替えることが可能であり、さらにDEFAULT_CONSUMER_GROUP (OTHER_GROUPS)グループとLOW_GROUPグループはPUBLICに付与されているので、これらのグループに切り替えることができます。また、SCOTTは他のユーザーにSALESグループを付与できますが、MARKETINGグループは付与できません。

SELECT * FROM dba_rsrc_consumer_group_privs;

GRANTEE            GRANTED_GROUP                  GRANT_OPTION INITIAL_GROUP
------------------ ------------------------------ ------------ -------------
PUBLIC             DEFAULT_CONSUMER_GROUP         YES          YES
PUBLIC             LOW_GROUP                      NO           NO
SCOTT              MARKETING                      NO           NO
SCOTT              SALES                          YES          YES
SYSTEM             SYS_GROUP                      NO           YES

SCOTTには、DBMS_RESOURCE_MANAGER_PRIVSパッケージを使用してこれらのグループに切り替える機能がすでに付与されています。

プラン情報の表示

この例では、DBA_RSRC_PLANSビューを使用して、データベースに定義されているすべてのリソース・プランを表示します。すべてのプランのステータスは、ペンディング・エリアに存在しないことを意味するNULLです。

注意:
ペンディング・エリア内のプランのステータスはPENDINGです。ペンディング・エリア内のプランは編集中です。

SELECT plan,status,comments FROM dba_rsrc_plans;

PLAN                        STATUS   COMMENTS
--------------------------- -------- ----------------------------------------
DSS_PLAN                             Example plan for DSS workloads that prio...
ETL_CRITICAL_PLAN                    Example plan for DSS workloads that prio...
MIXED_WORKLOAD_PLAN                  Example plan for a mixed workload that p...
ORA$AUTOTASK_SUB_PLAN                Default sub-plan for automated maintenan...
DEFAULT_MAINTENANCE_PLAN             Default plan for maintenance windows tha...
DEFAULT_PLAN                         Default, basic, pre-defined plan that pr...
INTERNAL_QUIESCE                     Plan for quiescing the database.  This p...
INTERNAL_PLAN                        Internally-used plan for disabling the r...
ORA$AUTOTASK_HIGH_SUB_PLAN           Default sub-plan for high-priority, auto...

セッションの現行コンシューマ・グループの表示

V$SESSIONビューを使用すれば、セッションに現在割り当てられているコンシューマ・グループを表示できます。

SELECT sid,serial#,username,resource_consumer_group FROM v$session;

SID    SERIAL#  USERNAME                  RESOURCE_CONSUMER_GROUP
-----  -------  ------------------------  --------------------------------
11       136 SYS                       SYS_GROUP
13     16570 SCOTT                     SALES
...

現在アクティブなプランの表示

この例では、mydb_plan(前述の「複数レベルのプランの例」の例で作成したもの)をトップレベルのプランに設定します。次に、V$RSRC_PLANビューを問い合せて、現在アクティブなプランを表示します。このビューには、現在のトップレベルのプランとそのすべての子サブプランが表示されます。

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = mydb_plan;

System altered.

SELECT name, is_top_plan FROM v$rsrc_plan;

NAME             IS_TOP_PLAN
----------------------------
MYDB_PLAN        TRUE
MAILDB_PLAN      FALSE
BUGDB_PLAN       FALSE

Oracle Database Resource Managerの監視

次の動的パフォーマンス・ビューは、Oracle Database Resource Managerの設定結果の監視に役立ちます。

- V$RSRC_PLAN

- V$RSRC_CONSUMER_GROUP

- V$RSRC_SESSION_INFO

- V$RSRC_PLAN_HISTORY

- V$RSRC_CONS_GROUP_HISTORY

- V$RSRCMGRMETRIC

- V$RSRCMGRMETRIC_HISTORY

これらのビューには、次の情報が表示されます。

- 現在のステータス情報

- リソース・プランのアクティブ化の履歴

- リソース・コンシューマ・グループとセッションによるリソース使用とCPU待ちに関する現在の統計と履歴の統計

さらに、履歴統計は、DBA_HIST_RSRC_PLANおよびDBA_HIST_RSRC_CONSUMER_GROUPの各ビューを介して表示できます。これらのビューには、それぞれV$RSRC_PLAN_HISTORYとV$RSRC_CONS_GROUP_HISTORYの自動ワークロード・リポジトリ(AWR)スナップショットが含まれています。

チューニングに役立つように、V$RSRCMGRMETRICおよびV$RSRCMGRMETRIC_HISTORYの各ビューには、過去1時間に、CPU待ちに費やした時間とCPUの使用量が、コンシューマ・グループごとに分単位で表示されます。Enterprise Managerでは、これらのメトリックを「リソース・マネージャ統計」ページでグラフィカルに表示できます。

V$RSRC_PLAN このビューには、現在アクティブなリソース・プランとそのサブプランが表示されます。

SELECT name, is_top_plan FROM v$rsrc_plan;

NAME                             IS_TOP_PLAN
-------------------------------- -----------
DEFAULT_PLAN                     TRUE
ORA$AUTOTASK_SUB_PLAN            FALSE
ORA$AUTOTASK_HIGH_SUB_PLAN       FALSE

IS_TOP_PLANがTRUEのプランは、現在アクティブな(トップレベルの)プランです。他のプランは、トップレベルのプランのサブプランか、リスト内の他のサブプランのサブプランです。

このビューには、その他に次の情報なども含まれます。

- INSTANCE_CAGING列に、インスタンス・ケージングが有効であるかどうかが表示されます。

- CPU_MANAGED列に、CPUが管理されているかどうかが表示されます。

- PARALLEL_EXECUTION_MANAGED列に、パラレル・ステートメント・キューイングが有効であるかどうかが表示されます。

関連項目:
『Oracle Databaseリファレンス』

V$RSRC_CONSUMER_GROUP V$RSRC_CONSUMER_GROUPビューは、CPU、I/O、パラレル・サーバーなど、使用されているリソースを監視する場合に使用します。また、CPUリソースの管理、リソース集中型の問合せの管理、パラレル・ステートメント・キューイングなどに関連する統計を監視する場合にも使用できます。すべての統計は、プランがアクティブ化された時点からの累積です。

SELECT name, active_sessions, queue_length,
consumed_cpu_time, cpu_waits, cpu_wait_time
FROM v$rsrc_consumer_group;

NAME               ACTIVE_SESSIONS QUEUE_LENGTH CONSUMED_CPU_TIME  CPU_WAITS CPU_WAIT_TIME
------------------ --------------- ------------ ----------------- ---------- -------------
OLTP_ORDER_ENTRY                 1            0             29690        467          6709
OTHER_GROUPS                     0            0           5982366       4089         60425
SYS_GROUP                        1            0           2420704        914         19540
DSS_QUERIES                      4            2           4594660       3004         55700

前述の問合せ結果では、DSS_QUERIESコンシューマ・グループには、アクティブ・セッション・プールに4つのセッションがあり、2つのセッションがキューでアクティブ化を待機しています。

このビューの主な測定値はCPU_WAIT_TIMEです。この測定値は、リソース管理のために、コンシューマ・グループのセッションがCPUの割当てを待機していた合計時間を示します。この測定値には、ラッチまたはエンキューの競合、I/O待機などに起因する待機は含まれません。

関連項目:
『Oracle Databaseリファレンス』

V$RSRC_SESSION_INFO このビューは、1つ以上のセッションのステータスを監視する場合に使用します。このビューには、リソース・マネージャによるセッションへの影響が表示されます。次の情報が提供されます。

- セッションが現在属しているコンシューマ・グループ。

- セッションが当初属していたコンシューマ・グループ。

- コンシューマ・グループへのセッションのマップに使用されたセッション属性。

- セッションの状態(RUNNING、WAIT_FOR_CPU、QUEUEDなど)。

- メトリックに関する現在の統計と累積の統計(CPU使用、待機時間、待ち行列時間など)。現在の統計には、セッションが現在のコンシューマ・グループに所属してからの統計が反映されています。累積の統計には、セッションが作成された以降に所属したすべてのコンシューマ・グループでの統計が反映されています。

SELECT se.sid sess_id, co.name consumer_group,
se.state, se.consumed_cpu_time cpu_time, se.cpu_wait_time, se.queued_time
FROM v$rsrc_session_info se, v$rsrc_consumer_group co
WHERE se.current_consumer_group_id = co.id;

SESS_ID CONSUMER_GROUP     STATE     CPU_TIME CPU_WAIT_TIME QUEUED_TIME
------- ------------------ -------- --------- ------------- -----------
113 OLTP_ORDER_ENTRY   WAITING     137947         28846           0
135 OTHER_GROUPS       IDLE        785669         11126           0
124 OTHER_GROUPS       WAITING      50401         14326           0
114 SYS_GROUP          RUNNING        495             0           0
102 SYS_GROUP          IDLE         88054            80           0
147 DSS_QUERIES        WAITING     460910        512154           0

このビューのCPU_WAIT_TIMEには、V$RSRC_CONSUMER_GROUPビューと同様の意味がありますが、個々のセッションに適用されます。

このビューとV$SESSIONビューを結合して、さらに詳細なセッションに関する情報を表示できます。

関連項目:
『Oracle Databaseリファレンス』

V$RSRC_PLAN_HISTORY このビューには、インスタンスでリソース・プランが有効または無効になった日時が表示されます。各リソース・プランのアクティブ化または解除には連番が割り当てられます。このビューの各エントリについては、プランの各コンシューマ・グループに対応するエントリがV$RSRC_CONS_GROUP_HISTORYビューにあり、コンシューマ・グループの累積統計が表示されます。この2つのビューは、それぞれのSEQUENCE#列で結合しています。

SELECT sequence# seq, name plan_name,
to_char(start_time, 'DD-MON-YY HH24:MM') start_time,
to_char(end_time, 'DD-MON-YY HH24:MM') end_time, window_name
FROM v$rsrc_plan_history;

SEQ PLAN_NAME                  START_TIME      END_TIME        WINDOW_NAME
---- -------------------------- --------------- --------------- ----------------
1                            29-MAY-07 23:05 29-MAY-07 23:05
2 DEFAULT_MAINTENANCE_PLAN   29-MAY-07 23:05 30-MAY-07 02:05 TUESDAY_WINDOW
3                            30-MAY-07 02:05 30-MAY-07 22:05
4 DEFAULT_MAINTENANCE_PLAN   30-MAY-07 22:05 31-MAY-07 02:05 WEDNESDAY_WINDOW
5                            31-MAY-07 02:05 31-MAY-07 22:05
6 DEFAULT_MAINTENANCE_PLAN   31-MAY-07 22:05                 THURSDAY_WINDOW

PLAN_NAMEの下のNULL値は、プランがアクティブにならなかったことを示します。

このビューのAWRスナップショットはDBA_HIST_RSRC_PLANビューに格納されます。

関連項目:
『Oracle Databaseリファレンス』

V$RSRC_CONS_GROUP_HISTORY このビューは、時間の経過に従ってコンシューマ・グループ内でリソースがどのように共有されたかを理解するのに役立ちます。sequence#列は、V$RSRC_PLAN_HISTORYビューの同名の列に対応しています。そのため、コンシューマ・グループ統計の各行について、アクティブであったプランを判別できます。

SELECT sequence# seq, name, cpu_wait_time, cpu_waits,
consumed_cpu_time FROM v$rsrc_cons_group_history;

SEQ NAME                      CPU_WAIT_TIME  CPU_WAITS CONSUMED_CPU_TIME
---- ------------------------- ------------- ---------- -----------------
2 SYS_GROUP                         18133        691          33364431
2 OTHER_GROUPS                      51252        825         181058333
2 ORA$AUTOTASK_MEDIUM_GROUP            21          5           4019709
2 ORA$AUTOTASK_URGENT_GROUP            35          1            198760
2 ORA$AUTOTASK_STATS_GROUP              0          0                 0
2 ORA$AUTOTASK_SPACE_GROUP              0          0                 0
2 ORA$AUTOTASK_SQL_GROUP                0          0                 0
2 ORA$AUTOTASK_HEALTH_GROUP             0          0                 0
2 ORA$DIAGNOSTICS                       0          0           1072678
4 SYS_GROUP                         40344         85          42519265
4 OTHER_GROUPS                     123295       1040         371481422
4 ORA$AUTOTASK_MEDIUM_GROUP             1          4           7433002
4 ORA$AUTOTASK_URGENT_GROUP         22959        158          19964703
4 ORA$AUTOTASK_STATS_GROUP              0          0                 0
.
.
6 ORA$DIAGNOSTICS                       0          0                 0

このビューのAWRスナップショットはDBA_HIST_RSRC_CONSUMER_GROUPビューに格納されます。コンシューマ・グループ統計の各履歴セットについて、アクティブであったプランを判別するには、DBA_HIST_RSRC_CONSUMER_GROUPとDBA_HIST_RSRC_PLANを併用します。

関連項目:

- 『Oracle Databaseリファレンス』

- AWRの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

V$RSRCMGRMETRIC このビューを使用すると、セッション数の観点または過去1分間の使用状況の観点から、CPUメトリックをミリ秒単位で追跡できます。各コンシューマ・グループのリアルタイムなメトリックが提供されるため、ワークロードの実行中に、CPUリソースの使用状況を継続的に監視する場合に非常に便利です。

このビューを使用すると、コンシューマ・グループの最大CPU使用率と平均CPU使用率を、使用したCPU時間、CPU待ち時間、CPUを消費しているセッションの平均数、CPU割当てを待機しているセッションの数など他のコンシューマ・グループ設定と比較できます。たとえば、コンシューマ・グループが使用したCPUリソースの量およびコンシューマ・グループがリソース割当てを待機した期間を表示できます。または、各コンシューマ・グループから実行されているセッションの数とアクティブなセッションの総数とを対比できます。

CPU使用率でCPUの消費量を追跡するには、CPU_UTILIZATION_LIMIT列およびAVG_CPU_UTILIZATION列を使用します。AVG_CPU_UTILIZATION列には、コンシューマ・グループによるサーバーのCPUの平均使用率が表示されます。CPU_UTILIZATION_LIMIT列は、コンシューマ・グループが使用できるサーバーのCPUの最大割合を表します。この制限は、MAX_UTILIZATION_LIMITディレクティブ属性を使用して設定されます。

SELECT consumer_group_name, cpu_utilization_limit,
avg_cpu_utilization FROM v$rsrcmgrmetric;

CPUの消費量および制限量をミリ秒単位で追跡するには、CPU_CONSUMED_TIME列およびCPU_TIME_WAIT列を使用します。NUM_CPUS列は、リソース・マネージャが管理しているCPUの数を表します。

SELECT consumer_group_name, cpu_consumed_time,
cpu_wait_time, num_cpus FROM v$rsrcmgrmetric;

CPUの消費量および制限量をセッションの数で追跡するには、RUNNING_SESSIONS_LIMIT、AVG_RUNNING_SESSIONS、AVG_WAITING_SESSIONSの各列を使用します。RUNNING_SESSIONS_LIMIT列には、特定のコンシューマ・グループからいつでも実行できるセッションの最大数が表示されます。この制限は、コンシューマ・グループまたはコンシューマ・グループが含まれているサブプランに設定するMAX_UTILIZATION_LIMITディレクティブ属性で定義されます。コンシューマ・グループごとに、AVG_RUNNING_SESSIONS列にはCPUを消費しているセッションの平均数が表示され、AVG_WAITING_SESSIONS列にはCPUを待機しているセッションの平均数が表示されます。

SELECT sequence#, consumer_group_name, running_sessions_limit,
avg_running_sessions, avg_waiting_sessions FROM v$rsrcmgrmetric;

関連項目:
『Oracle Databaseリファレンス』

V$RSRCMGRMETRIC_HISTORY

V$RSRCMGRMETRIC_HISTORYの各列は、V$RSRCMGRMETRICと同じビューです。これらのビューの唯一の違いは、V$RSRCMGRMETRICには過去1分間のみのメトリックが含まれているのに対して、V$RSRCMGRMETRIC_HISTORYには過去60分間のメトリックが含まれていることです。

関連項目:
『Oracle Databaseリファレンス』

オペレーティング・システムのリソース制御との相互作用

多くのオペレーティング・システムではリソース管理ツールを提供しています。これらのツールの名前には、「workload manager」や「resource manager」などの語句が含まれており、管理者が定義したポリシーを使用して、単一のサーバー・リソースを複数のアプリケーションで共有できることを意図しています。たとえば、HP社のProcess Resource Managerや、Solaris Containers、ZonesおよびResource Poolsなどがあります。

オペレーティング・システムのリソース制御を使用するためのガイドライン

オペレーティング・システムによるリソース制御をOracle Databaseと併用する場合は、次のガイドラインに従って慎重に使用する必要があります。

- 1つのノードに複数のインスタンスがあり、それらの間でリソースを配分する場合は、各インスタンスを専用のオペレーティング・システム・リソース・マネージャ・グループまたは管理対象エンティティに割り当てる必要があります。管理対象エンティティの複数のインスタンスを実行するには、インスタンス・ケージングを使用して管理対象エンティティ内のCPUリソースをインスタンス間で配分する方法を管理します。Oracle Database Resource Managerは、CPUリソースを管理するときに、各インスタンスに対するCPUリソースが一定量であると予測します。インスタンス・ケージングを使用しない場合は、使用可能なCPUリソースは管理対象エンティティ内のCPUの数と同じであると予測します。インスタンス・ケージングを使用する場合、使用可能なCPUリソースはCPU_COUNT初期化パラメータの値と同じであると予測します。CPUリソースが想定よりも少ない場合、Oracle Database Resource Managerはリソース・プランでのリソース割当ての強制が有効になりません。インスタンス・ケージングの詳細は、「単一サーバーにおける複数のデータベース・インスタンスの管理」を参照してください。

- インスタンスのすべてのプロセスを実行している専用エンティティが、1つの優先度(リソース使用)レベルで実行されている必要があります。

- 専用エンティティに割り当てたCPUリソースは、数分に1回の割合を超える頻度では変更できません。
オペレーティング・システムのリソース・マネージャによって、Oracleインスタンスに割り当てられているCPUリソースが急激に変更された場合、Oracle Database Resource ManagerがCPUリソースを効果的に管理できないことがあります。特に、Oracleインスタンスに割り当てられているCPUリソースが2、3分未満の間隔で頻繁に変更されると、Oracleでは2、3分ごとにしかこのような変更をチェックしないため、Oracleで観測されない可能性があります。このような場合、Oracle Database Resource Managerで、実際の使用可能量より多くのCPUリソースが使用できると判断されて多すぎるプロセスがスケジュールされたり、実際の使用可能量より少ないCPUリソースしか使用できないと判断されて少なすぎるプロセスがスケジュールされる可能性があります。多すぎるプロセスがスケジュールされた場合、MAX_UTILIZATION_LIMITディレクティブを超えてしまい、CPUディレクティブが正しく規定されない可能性があります。少なすぎるプロセスがスケジュールされた場合、Oracleインスタンスによってサーバーのリソースが十分に使用されない可能性があります。

- プロセスの優先度管理が使用禁止になっている必要があります。

- 個々のデータベース・プロセスを異なる優先度レベルで管理する機能(例: UNIXプラットフォームでのniceコマンドの使用)は、サポートされていません。インスタンスがクラッシュするなど、重大な結果になる可能性があります。オペレーティング・システムのリソース制御を使用して、Oracle Databaseインスタンスが固定されているメモリーを管理できる場合も、同様に望ましくない結果となることが予想されます。

Oracle Database Resource Managerの参照情報

ここでは、Oracle Database Resource Manager(リソース・マネージャ)の参照情報を提供します。

- 事前定義のリソース・プランおよびコンシューマ・グループ

- 事前定義のコンシューマ・グループ・マッピング・ルール

- リソース・マネージャのデータ・ディクショナリ・ビュー

事前定義のリソース・プランおよびコンシューマ・グループ

各Oracle Databaseに事前定義されているリソース・プランを表27-4にリストし、リソース・コンシューマ・グループを表27-5にリストします。ビューDBA_RSRC_PLANSおよびDBA_RSRC_CONSUMER_GROUPSを問い合せることによって、これらの内容を確認できます。

次の問合せにより、プラン例DSS_PLANでのCPU割当てが表示されます。

SELECT group_or_subplan, mgmt_p1, mgmt_p2, mgmt_p3, mgmt_p4
FROM dba_rsrc_plan_directives WHERE plan = 'DSS_PLAN';

GROUP_OR_SUBPLAN                  MGMT_P1    MGMT_P2    MGMT_P3    MGMT_P4
------------------------------ ---------- ---------- ---------- ----------
SYS_GROUP                              75          0          0          0
DSS_CRITICAL_GROUP                      0         75          0          0
DSS_GROUP                               0          0         75          0
ETL_GROUP                               0          0          0         45
BATCH_GROUP                             0          0          0         45
ORA$DIAGNOSTICS                         0          5          0          0
ORA$AUTOTASK_SUB_PLAN                   0          5          0          0
OTHER_GROUPS                            0          0          0         10

表27-4 事前定義のリソース・プラン

リソース・プラン

説明

DEFAULT_MAINTENANCE_PLAN

メンテナンス・ウィンドウのデフォルト・プラン。このプランの詳細は、「自動化メンテナンス・タスクに対するリソース割当ての概要」を参照してください。メンテナンス・ウィンドウはOracle Schedulerの通常のウィンドウであるため、必要に応じて、それらに関連付けられているリソース・プランを変更できます。メンテナンス・ウィンドウのリソース・プランを変更する場合は、サブプランORA$AUTOTASK_SUB_PLANおよびコンシューマ・グループORA$DIAGNOSTICSが新しいプランに含まれていることを確認してください。

DEFAULT_PLAN

SYS_GROUP操作の優先度を設定し、自動化メンテナンス操作と診断操作に最小限のリソースを割り当てる基本のデフォルト・プラン。

DSS_PLAN

重要ではないDSS問合せやETL操作よりも重要なDSS問合せを優先させるデータ・ウェアハウス・プランの例。

ETL_CRITICAL_PLAN

DSS問合せよりもETL操作を優先させるデータ・ウェアハウス・プランの例。

INTERNAL_PLAN

リソース・マネージャの無効化用。内部使用専用。

INTERNAL_QUIESCE

データベースの静止用。このプランは直接アクティブ化できません。アクティブ化するにはQUIESCEコマンドを使用します。

MIXED_WORKLOAD_PLAN

バッチ操作よりも対話型操作を優先させる複合ワークロード・プランの例。詳細は、「オラクル社が提供する複合ワークロード・プラン」を参照してください。

表27-5 事前定義のリソース・コンシューマ・グループ

リソース・コンシューマ・グループ

説明

BATCH_GROUP

バッチ操作用のコンシューマ・グループ。プラン例MIXED_WORKLOAD_PLANによって参照されます。

DSS_CRITICAL_GROUP

重要なDSS問合せ用のコンシューマ・グループ。プラン例DSS_PLANおよびETL_CRITICAL_PLANによって参照されます。

DSS_GROUP

重要ではないDSS問合せ用のコンシューマ・グループ。プラン例DSS_PLANおよびETL_CRITICAL_PLANによって参照されます。

ETL_GROUP

ETLジョブ用のコンシューマ・グループ。プラン例DSS_PLANおよびETL_CRITICAL_PLANによって参照されます。

INTERACTIVE_GROUP

対話型OLTP操作用のコンシューマ・グループ。プラン例MIXED_WORKLOAD_PLANによって参照されます。

LOW_GROUP

優先度が低いセッション用のコンシューマ・グループ。

ORA$DIAGNOSTICS

クリティカル・エラーの発生時に診断ダンプを作成するデータベース・プロセスによって使用されるコンシューマ・グループ。

ORA$AUTOTASK_HEALTH_GROUP

将来使用するために予約されています。ORA$AUTOTASK_HIGH_SUB_PLANに組み込まれています。

ORA$AUTOTASK_MEDIUM_GROUP

優先度が中程度のメンテナンス・タスク用のコンシューマ・グループ。

ORA$AUTOTASK_SPACE_GROUP

自動セグメント・アドバイザのメンテナンス・タスク用のコンシューマ・グループ。ORA$AUTOTASK_HIGH_SUB_PLANに組み込まれています。

ORA$AUTOTASK_SQL_GROUP

自動SQLチューニング・アドバイザのメンテナンス・タスク用のコンシューマ・グループ。ORA$AUTOTASK_HIGH_SUB_PLANに組み込まれています。

ORA$AUTOTASK_STATS_GROUP

オプティマイザ統計収集のメンテナンス・タスク用のコンシューマ・グループ。ORA$AUTOTASK_HIGH_SUB_PLANに組み込まれています。

ORA$AUTOTASK_URGENT_GROUP

緊急のメンテナンス・タスク用のコンシューマ・グループ。

OTHER_GROUPS

明示的な初期コンシューマ・グループを持たないすべてのセッションのデフォルトのコンシューマ・グループは、コンシューマ・グループへのセッションのマッピング・ルールによってコンシューマ・グループにマップされないか、現在アクティブなリソース・プラン内にないコンシューマ・グループにマップされます。

OTHER_GROUPSは、すべてのプランで指定されているリソース・プラン・ディレクティブを保持する必要があります。これをマッピング・ルールによって明示的にセッションに割り当てることはできません。

SYS_GROUP

システム管理者用のコンシューマ・グループ。これは、ユーザー・アカウントSYSまたはSYSTEMによって作成されたすべてのセッションの初期コンシューマ・グループです。この初期コンシューマ・グループは、コンシューマ・グループへのセッションのマッピング・ルールで上書きできます。

事前定義のコンシューマ・グループ・マッピング・ルール

表27-6に、Oracle Databaseで事前定義されているコンシューマ・グループ・マッピング・ルールの要約を示します。ビューDBA_RSRC_GROUP_MAPPINGSを問い合せることで、これらのルールを確認できます。DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPINGプロシージャを使用して、これらのマッピング・ルールを変更または削除できます。

表27-6 事前定義のコンシューマ・グループ・マッピング・ルール

属性

値

マップされるコンシューマ・グループ

注意

ORACLE_USER

SYS

SYS_GROUP

ORACLE_USER

SYSTEM

SYS_GROUP

ORACLE_FUNCTION

BACKUP

BATCH_GROUP

セッションでは、RMANによるバックアップ操作が実行されます。操作が開始すると、セッションは自動的にBATCH_GROUPに切り替えられます。

ORACLE_FUNCTION

COPY

BATCH_GROUP

セッションでは、RMANによるコピー操作が実行されます。操作が開始すると、セッションは自動的にBATCH_GROUPに切り替えられます。

ORACLE_FUNCTION

DATALOAD

ETL_GROUP

セッションでは、データ・ポンプによるデータ・ロード操作が実行されます。操作が開始すると、セッションは自動的にETL_GROUPに切り替えられます。

関連項目:
「コンシューマ・グループへのセッションのマッピング・ルールの指定」

リソース・マネージャのデータ・ディクショナリ・ビュー

表27-7に、リソース・マネージャに関連付けられているビューをリストします。

表27-7 リソース・マネージャのデータ・ディクショナリ・ビュー

ビュー

説明

DBA_RSRC_CONSUMER_GROUP_PRIVS

USER_RSRC_CONSUMER_GROUP_PRIVS

DBAビューには、すべてのリソース・コンシューマ・グループと、それが付与されているユーザーおよびロールがリストされます。USERビューには、ユーザーに付与されたすべてのリソース・コンシューマ・グループがリストされます。

DBA_RSRC_CONSUMER_GROUPS

データベースに存在するすべてのリソース・コンシューマ・グループがリストされます。

DBA_RSRC_MANAGER_SYSTEM_PRIVS

USER_RSRC_MANAGER_SYSTEM_PRIVS

DBAビューには、リソース・マネージャのシステム権限が付与されているユーザーとロールがすべてリストされます。USERビューには、DBMS_RESOURCE_MANAGERパッケージのシステム権限が付与されているユーザーがすべてリストされます。

DBA_RSRC_PLAN_DIRECTIVES

データベースに存在するすべてのリソース・プラン・ディレクティブがリストされます。

DBA_RSRC_PLANS

データベースに存在するすべてのリソース・プランがリストされます。

DBA_RSRC_GROUP_MAPPINGS

すべてのセッション属性に対する様々なマッピングのペアがすべてリストされます。

DBA_RSRC_MAPPING_PRIORITY

各属性の現在のマッピング優先度がリストされます。

DBA_HIST_RSRC_PLAN

リソース・プランのアクティブ化に関する履歴情報が表示されます。このビューには、V$RSRC_PLAN_HISTORYのAWRスナップショットが含まれています。

DBA_HIST_RSRC_CONSUMER_GROUP

コンシューマ・グループに関する履歴統計情報が表示されます。このビューには、V$RSRC_CONS_GROUP_HISTORYのAWRスナップショットが含まれています。

DBA_USERS

USER_USERS

DBAビューには、データベースのすべてのユーザーに関する情報が含まれます。これには、各ユーザーの初期リソース・コンシューマ・グループが含まれます。USERビューには、現行ユーザーに関する情報が含まれます。これには、現行ユーザーの初期リソース・コンシューマ・グループが含まれます。

V$RSRC_CONS_GROUP_HISTORY

V$RSRC_PLAN_HISTORYビューの各エントリについて、プランの各コンシューマ・グループに対応するエントリが含まれており、コンシューマ・グループの累積統計が表示されます。

V$RSRC_CONSUMER_GROUP

アクティブなリソース・コンシューマ・グループに関する情報が表示されます。このビューは、チューニングに使用できます。

V$RSRCMGRMETRIC

過去1分間のリソース使用履歴と累積CPU待ち時間(リソース管理に起因するもの)がコンシューマ・グループごとに表示されます。

V$RSRCMGRMETRIC_HISTORY

過去1時間のリソース使用履歴と累積CPU待ち時間(リソース管理に起因するもの)がコンシューマ・グループごとに分単位で表示されます。新しいリソース・プランが有効な場合、履歴はクリアされます。

V$RSRC_PLAN

現在のアクティブ・リソース・プランの名前がすべて表示されます。

V$RSRC_PLAN_HISTORY

そのインスタンスでリソース・マネージャのプランがいつ有効または無効になったかが表示されます。時間の経過とともに、どのようにリソースがコンシューマ・グループ間で共有されていたかを理解するのに役立ちます。

V$RSRC_SESSION_INFO

各セッションについてリソース・マネージャの統計が表示されます。リソース・マネージャによるセッションへの影響が表示されます。チューニングに使用できます。

V$SESSION

現行セッションごとにセッション情報が表示されます。その中には、各現行セッションのリソース・コンシューマ・グループの名前が含まれます。

関連項目:
これらの各ビューの内容の詳細は、『Oracle Databaseリファレンス』を参照してください。

28 Oracle Schedulerの概要

この章の内容は、次のとおりです。

- Oracle Schedulerの概要

- ジョブおよびスケジューラ・オブジェクトのサポートの概要

- ジョブに関する追加説明

- スケジューラのアーキテクチャ

- スケジューラによるOracle Data Guardのサポート

- Oracle Schedulerとエディション

Oracle Schedulerの概要

数百または数千ものタスクのスケジューリングを簡素化するために、Oracle Databaseにはエンタープライズ・ジョブ・スケジューラであるOracle Schedulerが組み込まれています。Oracle Scheduler(スケジューラ)は、DBMS_SCHEDULER PL/SQLパッケージのプロシージャおよびファンクションにより実装されます。

スケジューラを使用すると、企業環境で様々なコンピューティング・タスクをいつどこで実施するかを制御できます。これらのタスクの効率的な管理および計画に役立ちます。多数の日常的なコンピューティング・タスクが手動で操作することなく確実に実行されるため、操作コストの削減、信頼性の高いルーチンの実現、人為的なエラーの最小化および必要期間の短縮が可能です。

スケジューラでは、洗練された柔軟なエンタープライズ・スケジューリング機能が提供されます。次のことを実行できます。

- データベース・プログラム・ユニットの実行
ローカル・データベースまたは1つ以上のリモートOracle Databaseで、プログラム・ユニット(PL/SQL無名ブロック、PL/SQLストアド・プロシージャおよびJavaストアド・プロシージャ)を実行できます。

- 外部実行可能ファイル(データベースの外部の実行可能ファイル)の実行
アプリケーション、シェル・スクリプト、バッチ・ファイルなどの外部実行可能ファイルをローカル・システムまたは1つ以上のリモート・システムで実行できます。リモート・システムにOracle Databaseをインストールする必要はありません。スケジューラ・エージェントのみが必要です。スケジューラ・エージェントは、Oracle Databaseがサポートするすべてのプラットフォームおよび他の一部のプラットフォームで使用できます。

- 次の方法によるジョブ実行のスケジュール。

- 時間ベースのスケジューリング
特定の日時に1回または繰り返し実行するようにジョブをスケジュールできます。「特定の休日を除き毎週月曜日と木曜日の午前3時」または「業務上の各四半期の最終水曜日」のように、複雑な繰返し間隔を定義できます。詳細は、「ジョブの作成、実行および管理」を参照してください。

- イベント・ベースのスケジューリング
システム・イベントまたはビジネス・イベントに対応してジョブを開始できます。アプリケーションは、イベントを検出するとスケジューラに通知します。送信された通知のタイプに応じて、スケジューラは特定のジョブを開始します。イベントベースのスケジューリングの例として、ファイルがシステムに着信した時点、在庫が事前に指定したレベルを下回った時点、またはトランザクションに失敗した時点でジョブを開始させる場合があります。Oracle Database 11g リリース2以降では、File Watcherと呼ばれるスケジューラ・オブジェクトによって、ファイルがリモート・システムに到着したときに開始するジョブの構成タスクが簡略化されます。詳細は、「イベントを使用したジョブの開始」を参照してください。

- 依存性スケジューリング
前の1つ以上のタスクの結果に基づいてタスクを実行するようにスケジューラを設定できます。ブランチやネストしたチェーンを含んだ複雑な依存性チェーンを定義できます。詳細は、「ジョブ・チェーンの作成と管理」を参照してください。

- ビジネス要件に基づくジョブの優先度付け。
スケジューラを使用すると、競合するジョブ間のリソース割当てを制御でき、ビジネス・ニーズに基づいてジョブ処理を調整できます。これは次の方法で実現されます。

- ジョブ・クラスによるリソースの制御
共通の特性や動作を共有するジョブは、ジョブ・クラスと呼ばれるさらに大きなエンティティにグループ化できます。クラス間に優先度を付けるには、各クラスに割り当てられるリソースを制御します。そのため、重要なジョブが優先され、ジョブの完了に必要なリソースを確保できます。たとえば、データ・ウェアハウスをロードする重要なプロジェクトがある場合は、複数のデータ・ウェアハウス・ジョブをすべて1つのクラスにまとめ、使用可能なリソースの割当て比率を高くすることによって、その他のジョブより優先的に実行できます。また、ジョブ・クラス内のジョブに相対的な優先度を割り当てることもできます。

- スケジュールに基づいたジョブの優先度の制御
スケジュールに基づいてジョブの優先度を変更できます。重要なジョブの定義は時間の経過とともに変化する場合があるため、スケジューラでは、期間ごとにジョブ間での優先度を変更することもできます。たとえば、データ・ウェアハウスのロードに使用される抽出、転送およびロード(ETL)のジョブが、オフピーク時に重要になり、ピーク時には重要にならない場合があります。また、業務上の四半期の終了時期に実行する必要があるジョブは、ETLジョブよりも優先させることが必要となる場合があります。このような場合は、各ジョブ・クラスに割り当てるリソースを変更して、クラス間での優先度を変更できます。詳細は、「ジョブ・クラスの作成」および「ウィンドウの作成」を参照してください。

- ジョブの管理と監視
作成から完了までの間にジョブが通過する複数の状態を管理および監視できます。スケジューラはアクティビティをログに記録して、Enterprise ManagerまたはSQLを使用してビューを問い合せることで、ジョブのステータスやジョブの最終実行時刻などの情報を簡単に追跡できるようにします。このビューからジョブとその実行内容に関する有益な情報が得られるため、これを使用してジョブをより適切にスケジュールし管理できます。たとえば、DBAは特定のユーザーの失敗ジョブをすべて簡単に追跡できます。「スケジューラのデータ・ディクショナリ・ビュー」を参照してください。

複数の宛先のジョブ(1つのデータベースで定義され、複数のリモート・ホストで実行されるジョブ)を作成する場合、宛先ごとにジョブの状態を個別に監視するか、または親ジョブの状態を全体的に監視できます。

ジョブを詳細に監視するために、スケジューラがイベント・キューに提供するジョブの状態変更通知をアプリケーションによってサブスクライブできます。また、スケジューラでは、ジョブの状態が変化したとき、電子メール通知を送信することもできます。

「スケジューラの監視と管理」を参照してください。

- クラスタ化された環境におけるジョブの実行と管理
クラスタは、同じタスクを実行するために連携して動作するデータベース・インスタンスのセットです。Oracle Real Application Clusters(Oracle RAC)は、アプリケーションを変更せずにスケーラビリティと信頼性を提供します。スケジューラは、このようなクラスタ化された環境でのジョブの実行を完全にサポートします。システムの負荷を均等にし、パフォーマンスを向上させるために、ジョブを実行するデータベース・サービスを指定することもできます。詳細は、「Real Application Clusters環境におけるスケジューラの使用」を参照してください。

ジョブおよびスケジューラ・オブジェクトのサポートの概要

スケジューラを使用するには、スケジューラ・オブジェクトを作成します。スキーマ・オブジェクトには、ジョブ・スケジューリングの内容、時期および場所を定義します。スケジューラ・オブジェクトにより、モジュール化された方法でタスクを管理できます。この方法のメリットの1つは、既存のタスクに類似する新規タスクを作成する際にオブジェクトを再利用できることです。

重要なスケジューラ・オブジェクトはジョブです。ジョブは、実行する処理、処理のスケジュール、処理が行われる場所を定義します。他のほとんどのスケジューラ・オブジェクトは、ジョブをサポートするために作成されます。

注意:
DBMS_JOBパッケージはOracle Schedulerジョブで置き換えられますが、下位互換性を保つために引き続きサポートされます。この章では、スケジューラ・ジョブのみを使用しているものと仮定します。両方を一度に使用しているか、DBMS_JOBからスケジューラ・ジョブに移行している場合は、付録A「Oracle Database 11gリリース2におけるDBMS_JOBのサポート」を参照してください。

スケジューラ・オブジェクトは次のとおりです。

- プログラム

- スケジュール

- ジョブ

- 宛先

- チェーン

- File Watcher

- 資格証明

- ジョブ・クラス

- ウィンドウ

- グループ

これらの各オブジェクトの詳細は、後で説明します。

スケジューラ・オブジェクトはスキーマに属しているため、オブジェクト権限を付与できます。ジョブ・クラス、ウィンドウおよびウィンドウ・グループのような一部のスケジューラ・オブジェクトは、ユーザーがSYSでない場合も常にSYSスキーマに作成されます。他のオブジェクトはすべて、ユーザー自身のスキーマまたは指定のスキーマに作成されます。

関連項目:

- 「スケジューラ権限」

プログラム

プログラム・オブジェクト(プログラム)では、スケジューラによって実行される内容が記述されます。プログラムの要素は次のとおりです。

- 処理: ストアド・プロシージャ名、オペレーティング・システムのファイル・システムにある実行可能ファイル(外部実行可能ファイル)の名前、PL/SQL無名ブロックのテキストなど。

- タイプ: STORED_PROCEDURE、PLSQL_BLOCKまたはEXTERNALがあり、EXTERNALは外部実行可能ファイルを示します。

- 引数の数: ストアド・プロシージャまたは外部実行可能ファイルが受け入れる引数の数。

プログラムはジョブとは別のエンティティです。ジョブは特定の時刻または特定のイベントの発生により実行されて、特定のプログラムを起動します。既存のプログラム・オブジェクトを指し示すジョブを作成できるため、様々なジョブが同じプログラムを使用して、別の時刻に別の設定でプログラムを実行できます。正しい権限があると、様々なユーザーが同じプログラムを再定義せずに使用できます。そのため、既存のプログラムのリストからユーザーが選択できるプログラム・ライブラリを作成できます。

プログラムで参照されるストアド・プロシージャまたは外部実行可能ファイルが引数を受け入れる場合は、これらの引数をプログラムの作成後に個別ステップで定義します。各引数のデフォルト値を定義することもできます。

関連項目:

- 「プログラムの作成」

- ジョブの概要については、「ジョブ」を参照してください。

スケジュール

スケジュール・オブジェクト(スケジュール)は、ジョブの実行時期と実行回数を指定します。スケジュールは複数のジョブで共有できます。たとえば、業務上の四半期の終了時期は、多くのジョブにとって共通の期間である可能性があります。ジョブの作成者は、新規のジョブを定義するたびに四半期の終了時期のスケジュールを定義するかわりに、名前付きのスケジュールを指し示すことができます。

スケジュールには、次の2種類があります。

- 時間スケジュール
時間スケジュールでは、ジョブを即時に実行するか、後で実行するようにスケジュールできます。時間スケジュールには、開始日時、オプションの終了日時およびオプションの繰返し間隔が含まれています。

- イベント・スケジュール
イベント・スケジュールでは、在庫がしきい値を下回った時点、またはファイルがシステムに到着した時点など、特定のイベントが発生した時点でジョブを実行するように指定できます。イベントの詳細は、「イベントを使用したジョブの開始」を参照してください。

関連項目:
「スケジュールの作成」

ジョブ

ジョブ・オブジェクト(ジョブ)は、ユーザー定義のタスクを記述するメタデータのコレクションです。実行される内容(処理)、タイミング(1回のみ、定期的なスケジュールまたはトリガー・イベント)、場所(宛先)および使用される資格証明を定義します。ジョブにはスキーマである所有者が存在し、ジョブはそのスキーマで作成されます。

1つ以上の宛先を指定して、ジョブが実行される場所を定義します。宛先もスケジューラ・オブジェクトであり、この項で後述します。宛先を指定しないと、ローカル・データベースでジョブが実行されるとみなされます。

ジョブの処理は、次のいずれかの方法で指定します。

- 実行するデータベース・プログラム・ユニットまたは外部実行可能ファイルをジョブ属性として指定する方法。この方法をジョブの処理のインライン指定と呼びます。

- 既存のプログラム・オブジェクト(プログラム)名をジョブ属性として指定し、実行するデータベース・プログラム・ユニットまたは外部実行可能ファイルをプログラムで指定する方法。ジョブ所有者には、プログラムに対するEXECUTE権限またはEXECUTE ANY PROGRAMシステム権限が必要です。

データベース・プログラム・ユニットを実行するジョブをデータベース・ジョブと呼びます。外部実行可能ファイルを実行するジョブを外部ジョブと呼びます。

ジョブ・スケジュールは、次のいずれかの方法で指定します。

- ジョブ・オブジェクトの属性を設定して開始日時、終了日時および繰返し間隔を定義するか、またはジョブを開始するイベントを定義する方法。この方法をスケジュールのインライン指定と呼びます。

- 開始日時、終了日時および繰返し間隔を定義する既存のスケジュール・オブジェクト(スケジュール)の名前をジョブ属性として指定するか、イベントを定義する方法。

ジョブの宛先は、次のいずれかの方法で指定します。

- 指定された単一の宛先オブジェクトをジョブ属性として指定する方法。この場合、ジョブは1つのリモートの場所で実行されます。

- 指定された宛先グループ(リモートの場所のリストと同じ)をジョブ属性として指定する方法。この場合、ジョブはすべてのリモートの場所で実行されます。

- 宛先属性を定義せずにジョブをローカルに実行する方法。ジョブは次のいずれかを実行します。

- ローカル・データベースのデータベース・プログラム・ユニット(ジョブが作成されたデータベース)

- ジョブ処理タイプに応じた、ローカル・ホストの外部実行可能ファイル

ジョブの資格証明は、次のいずれかの方法で指定します。

- ジョブ属性を名前付き資格証明オブジェクトとして指定する方法で、次のいずれかが含まれます。

- データベースのユーザー名とパスワード(データベース・ジョブの場合)

- ホスト・オペレーティング・システムのユーザー名とパスワード(外部ジョブの場合)

ジョブは、資格証明に指定されているユーザーとして実行されます。

- ジョブの資格証明属性をNULLのままにする方法。(表28-1を参照。)ジョブの所有者は、ジョブが作成されたスキーマです。

1つ以上のリモートの場所でデータベース・プログラム・ユニットを実行するジョブをリモート・データベース・ジョブと呼びます。1つ以上のリモートの場所で外部実行可能ファイルを実行するジョブをリモート外部ジョブと呼びます。

ジョブを作成して有効化した後は、スケジューラによりスケジュールに従って自動的にジョブが実行されるか、または指定のイベントが検出されたときに実行されます。ジョブの実行ステータスとジョブ・ログは、データ・ディクショナリ・ビューを問い合せることで確認できます。ジョブが複数の宛先で実行される場合は、各宛先でジョブの状態を問い合せることができます。

関連項目:

- 「宛先」

- 「ジョブに関する追加説明」

- 「ジョブの作成」

- 「スケジューラのデータ・ディクショナリ・ビュー」

宛先

宛先オブジェクト(宛先)は、ジョブを実行する場所を定義します。

宛先には、次の2種類があります。

- 外部宛先: リモート外部ジョブを実行するリモート・ホストの名前とIPアドレスを指定します。

- データベース宛先: リモート・データベース・ジョブを実行するリモート・データベース・インスタンスを指定します。

外部実行可能ファイルを実行するジョブ(外部ジョブ)では外部宛先を指定する必要があり、データベース・プログラム・ユニットを実行するジョブ(データベース・ジョブ)ではデータベース宛先を指定する必要があります。

ジョブの作成時に宛先を指定すると、その宛先でジョブが実行されます。宛先を指定しないと、ジョブが作成されたシステムでローカルに実行されます。

宛先のリストで構成される宛先グループを作成して、この宛先グループをジョブの作成時に参照することもできます。この場合、ジョブはグループのすべての宛先で実行されます。

注意:
宛先グループには、キーワードLOCALをグループ・メンバーとして含めることもでき、これはローカル・ホストまたはローカル・データベースでもジョブを実行することを示します。

関連項目:
「グループ」

別のユーザーによって作成された宛先を使用する場合に、オブジェクト権限は必要ありません。

宛先およびスケジューラ・エージェントの概要

宛先オブジェクトで指定されたリモートの場所でスケジューラ・エージェントが実行されており、かつ、ジョブを作成するデータベースにそのエージェントが登録されている必要があります。スケジューラ・エージェントを使用すると、ローカル・スケジューラとリモート・ホストとの通信や、リモート・ホストでのジョブの開始と停止が可能になり、リモート・ジョブの状態をローカル・データベースに戻すことができます。詳細は、「宛先の作成」を参照してください。

外部宛先

外部宛先を明示的に作成することはできません。外部宛先は、データベースにスケジューラ・エージェントを登録するとき、ローカル・データベースで作成されます。外部宛先に割り当てられる名前は、エージェント名と同じです。エージェント名はエージェントのインストール後に構成できますが、ホスト名の最初の部分(最初のドット区切りの前)であるデフォルトのエージェント名も使用できます。たとえば、dbhost1.us.example.comというホストにエージェントをインストールした場合、デフォルトのエージェント名はDBHOST1になります。

データベース宛先

データベース宛先は、DBMS_SCHEDULER.CREATE_DATABASE_DESTINATIONプロシージャを使用して作成します。

注意:
ローカル・ホストで複数のデータベース・インスタンスが実行されている場合は、他のインスタンスを指定してデータベース宛先を作成することによって、そのインスタンスでジョブを実行できます。したがって、リモート・データベース・インスタンスは、必ずしもリモート・ホストに存在している必要はありません。このような追加のインスタンスでリモート・データベース・ジョブを実行できるようにするには、ローカル・ホストでスケジューラ・エージェントが実行されている必要があります。

関連項目:

- 「宛先の作成」

- 「リモート・ホストでのSchedulerエージェントのインストールと構成」

File Watcher

あるファイルがシステムに到着するとスケジューラによってジョブが開始されるようにする場合、File Watcherオブジェクト(File Watcher)にはそのファイルの場所、名前および他のプロパティを定義します。ファイル・ウォッチャを作成し、次に、そのファイル・ウォッチャを参照する任意の数のイベントベースのジョブまたはイベント・スケジュールを作成します。ファイル・ウォッチャでは、指定されたファイルの到着を検出すると、到着イベントを呼び出します。ファイルの到着イベントによって開始されたジョブでは、新しく到着したファイルを示すイベント・メッセージを取得できます。

File Watcherでは、ローカル・システム(Oracle Databaseを実行しているホスト・コンピュータと同じ)またはリモート・システム(リモート・システムでスケジューラ・エージェントが稼働している場合)でファイルが監視されます。

File Watcherを使用するには、データベースのJava仮想マシン(JVM)コンポーネントをインストールする必要があります。

詳細は、「File Watcherの概要」を参照してください。

関連項目:
「File WatcherおよびFile Watcherジョブの作成」

資格証明

資格証明は、専用のデータベース・オブジェクトに格納されているユーザー名とパスワードのペアです。データベース・インスタンスまたはオペレーティング・システムで資格証明を使用してジョブが認証されると、ジョブを実行できます。資格証明には、次の用途があります。

- リモート・データベース・ジョブ: 資格証明には、データベースのユーザー名とパスワードが含まれます。リモート・データベース・ジョブで指定されるストアド・プロシージャまたはPL/SQLブロックは、このデータベース・ユーザーとして実行されます。

- 外部ジョブ(ローカルまたはリモート): 資格証明には、ホスト・オペレーティング・システムのユーザー名とパスワードが含まれています。ジョブの外部実行可能ファイルは、このユーザー名とパスワードを使用して実行されます。

- File Watcher: 資格証明には、ホスト・オペレーティング・システムのユーザー名とパスワードが含まれています。ファイルの到着イベントを処理するジョブは、このユーザー名とパスワードを使用して、到着したファイルにアクセスします。

データベース内の資格証明のリストを表示するには、*_SCHEDULER_CREDENTIALSビューを問い合せます。資格証明パスワードは不明瞭な状態で格納されるため、*_SCHEDULER_CREDENTIALSビューには表示されません。

関連項目:
「資格証明の作成」

チェーン

チェーンは、前の1つ以上のジョブの結果に応じて異なるジョブが開始される依存性スケジューリングを実装できる手段です。チェーンは、依存性ルールを使用して結合された複数のステップで構成されています。依存性ルールでは、ステップまたはチェーン自体の開始または停止に使用できる条件を定義します。条件には、前のステップの成功、失敗、完了コードまたは終了コードを使用できます。AND/ORなどの論理式を条件に使用することもできます。チェーンは、実行するタスクと、タスクの実行時期の選択に関して多くの可能なパスを持ち、ある意味でDecision Treeに似ています。

最も単純な形式のチェーンは、1つの目的のために互いにリンクされた複数のスケジューラ・プログラム・オブジェクト(プログラム)で構成されています。チェーンの例には、「プログラムAを実行してからプログラムBを実行するが、プログラムAとプログラムBの両方が正常に完了した場合にのみプログラムCを実行し、正常に完了しない場合は1時間待機してからプログラムDを実行する」などがあります。

チェーンの作成が必要な例として、融資申請を検証して承認した後に融資するなど、正常な取引のために様々なプログラムの結合を必要とする金融取引などがあります。

スケジューラ・ジョブは、単一のプログラム・オブジェクトを指し示すかわりにチェーンを指し示すことができます。その場合、ジョブはチェーンを開始する役割を持ちます。このジョブはチェーン・ジョブと呼ばれます。複数のチェーン・ジョブで同じチェーンを指し示すことができ、そのうちの複数のジョブを同時に実行することで、チェーンの様々な進捗ポイントで同じチェーンの複数インスタンスをそれぞれ作成できます。

チェーン内の各位置はステップと呼ばれます。通常は、最初の一連のチェーン・ステップを開始し、後続のステップは、1つ以上前のステップの完了に従って実行されます。各ステップは、次のいずれかを指し示します。

- プログラム・オブジェクト(プログラム)
プログラムでは、データベース・プログラム・ユニット(ストアド・プロシージャまたはPL/SQL無名ブロックなど)または外部実行可能ファイルを実行できます。

- 別のチェーン(ネストしたチェーン)
チェーンをネストするレベル数に制限はありません。

- イベント・スケジュール、インライン・イベントまたはFile Watcher
イベント・スケジュールを指し示すステップ、またはインライン・イベント指定を持つステップを開始した後、ステップは特定のイベントが呼び出されるまで待機します。同様に、File Watcherインラインを参照するステップ、またはFile Watcherを参照するイベント・スケジュールを指し示すステップは、ファイルの到着イベントが呼び出されるまで待機します。ファイルの到着イベントまたは他のタイプのイベントの場合、イベントが発生すると、このステップが完了し、イベント・ステップに依存するステップが実行可能になります。チェーン内のイベントの一般例は、承認や拒否のようなユーザーの介入です。

チェーン内の複数のステップは、同じプログラムまたはネストしたチェーンを起動できます。

各ステップには、ステップが実行されるデータベース宛先または外部宛先のいずれかを指定できます。宛先を指定しないと、ステップが元の(ローカル)データベースまたはローカル・ホストで実行されます。チェーン内の各ステップは、異なる宛先で実行できます。

図28-1に、複数のブランチを持つチェーンを示します。このチェーンでは、ルールが次のように定義されているとします。

- ステップ1が正常に完了した場合は、ステップ2を開始します。

- ステップ1が失敗してエラー・コード20100が戻された場合は、ステップ3を開始します。

- ステップ1が失敗して他のエラー・コードが戻された場合は、チェーンを終了します。

ステップ4、5、6および7の実行は、他のルールにより制御されます。

図28-1 複数のブランチを持つチェーン

チェーンを指し示しているジョブの実行中は、実行しているチェーンのすべてのステップについて現在の状態を監視できます。各ステップには、スケジューラによって、チェーン・ジョブと同じジョブ名と所有者を設定したステップ・ジョブが作成されます。各ステップ・ジョブにはさらに、そのジョブを一意に識別するためのサブ名があります。ステップ・ジョブ・サブ名は、ビュー*_SCHEDULER_RUNNING_JOBS、*_SCHEDULER_JOB_LOGおよび*_SCHEDULER_JOB_RUN_DETAILSにJOB_SUBNAME列として、*_SCHEDULER_RUNNING_CHAINSビューにSTEP_JOB_SUBNAME列として含まれています。

関連項目:
「ジョブ・チェーンの作成と管理」

ジョブ・クラス

通常、ジョブ・クラスを作成するのは、スケジューラ管理者のロールを持っている場合のみです。

ジョブ・クラスは、次の内容を実行します。

- メンバーのジョブへの同じ属性値セットの割当て
各ジョブ・クラスでは、ロギング・レベルなどの属性セットを指定します。ジョブをジョブ・クラスに割り当てると、そのジョブはこれらの属性を継承します。たとえば、全給与ジョブに対するログ・エントリのパージに関して、同じポリシーを指定できます。

- メンバーのジョブに対するサービス・アフィニティの設定
ジョブ・クラスのservice属性を、目的のデータベース・サービス名に設定できます。これにより、メンバー・ジョブを実行するReal Application Clusters環境のインスタンスを決定でき、必要に応じて、メンバー・ジョブに割り当てられているシステム・リソースも決定できます。詳細は、「スケジューラ使用時のサービス・アフィニティ」を参照してください。

- メンバーのジョブに対するリソース割当ての設定
各ジョブ・クラスでは、リソース・コンシューマ・グループを属性として指定できるため、ジョブ・クラスでは、データベース・リソース・マネージャとスケジューラ間のリンクが提供されます。このため、指定したコンシューマ・グループに属するメンバーのジョブには、現行のリソース・プランの設定に応じて、リソースが割り当てられます。

また、resource_consumer_group属性をNULLのままにし、ジョブ・クラスのservice属性を必要なデータベース・サービス名に設定できます。このサービスは、リソース・コンシューマ・グループにマップできます。resource_consumer_group属性とservice属性が設定されているときに、指定のサービスがリソース・コンシューマ・グループにマップされた場合は、resource_consumer_group属性に指定されているリソース・コンシューマ・グループが優先されます。

コンシューマ・グループに対するサービスのマッピングの詳細は第27章のOracle Database Resource Managerを使用したリソースの管理を参照してください。

- ジョブの優先度によるグループ化
同じジョブ・クラス内では、個々のジョブに対して1から5の優先度値を割り当てて、クラス内の2つのジョブが同時に起動するようにスケジュールされた場合に、優先度の高いジョブが優先されるように設定できます。こうすることで、重要度の高いジョブが適切なタイミングで完了するのを、重要度の低いジョブが妨げないようにできます。

2つのジョブに同じ優先値が割り当てられている場合は、開始日の早いジョブが優先されます。ジョブに優先度が割り当てられていない場合、そのジョブの優先度は3にデフォルト設定されます。

注意:
ジョブの優先度は、同じクラス内のジョブの間で優先度を付ける場合にのみ使用されます。
同じスケジュールを共有している場合でも、クラスA内の優先度の高いジョブが、クラスB内の優先度の低いジョブより先に開始されることは保証されません。異なるクラスのジョブ間の優先度付けは、現行のリソース・プランと、指定されたリソース・コンシューマ・グループまたは各ジョブ・クラスのサービス名に応じて異なります。

ジョブ・クラスを定義するときは、ジョブを機能別に分類してください。マーケティング、生産、販売、財務および人事など、同様のデータにアクセスするジョブをグループに分けることを考慮してください。

次の制限事項に注意してください。

- ジョブは必ず1つのクラスに属している必要があります。ジョブを作成するときは、そのジョブが属するクラスを指定できます。クラスを指定しない場合、ジョブは自動的にDEFAULT_JOB_CLASSクラスのメンバーになります。

- クラス内にジョブが存在している状態でクラスを削除するとエラーになります。クラスのメンバーであるジョブがまだ存在している場合でもクラスを強制的に削除することはできますが、そのクラスを参照しているジョブはすべて自動的に使用禁止になり、DEFAULT_JOB_CLASSクラスに割り当てられます。削除したクラスに属しているジョブの中ですでに実行中のジョブは、ジョブの開始時に判別されたクラスの設定のまま実行されます。

関連項目:
「ジョブ・クラスの作成」

ウィンドウ

通常、ウィンドウを作成するのは、スケジューラ管理者のロールを持っている場合のみです。

日または週などの様々な期間中に、ジョブを自動的に開始したり、複数のジョブ間のリソース割当てを変更するには、ウィンドウを作成します。ウィンドウは、午前12時から午前6時など、開始と終了が明確に定義された期間で表されます。

ウィンドウは、ジョブ・クラスを使用して、リソース割当てを制御します。各ウィンドウは、ウィンドウがオープンしたとき(アクティブになったとき)に、アクティブにするリソース・プランを指定し、各ジョブ・クラスは、リソース・コンシューマ・グループを指定するか、コンシューマ・グループにマップできるデータベース・サービスを指定します。したがって、ウィンドウ内で実行するジョブには、そのジョブ・クラスのコンシューマ・グループとウィンドウのリソース・プランに応じてリソースが割り当てられます。

図28-2に、2つのウィンドウが設定された稼働日を示します。この構成では、コンシューマ・グループ1にリンクしているジョブ・クラスに属するジョブが、午後よりも午前にリソースを多く使用しています。コンシューマ・グループ2にリンクしているジョブ・クラスのジョブは、この逆です。

図28-2 ジョブに割り当てるリソースの定義に役立つウィンドウ

リソース・プランおよびコンシューマ・グループの詳細は、第27章のOracle Database Resource Managerを使用したリソースの管理を参照してください。

各ウィンドウには、優先度を割り当てることができます。ウィンドウが重複する場合は、優先度の高いウィンドウが優先度の低いウィンドウより優先して選択されます。スケジューラは、ウィンドウの開始時間と終了時間に従って、各ウィンドウを自動的にオープンしたり、クローズします。

ジョブは、そのschedule_name属性でウィンドウを指定できます。スケジューラは、このウィンドウがオープンするとジョブを開始します。ウィンドウがすでにオープンしている場合にそのウィンドウを指し示す新規ジョブが作成されると、そのジョブはウィンドウが次回オープンするまで開始されません。

注意:
必要な場合は、現行のリソース・プランが切り替わらないように一時的にウィンドウをブロックできます。詳細は、「Oracle Database Resource Managerの有効化とプランの切替え」または『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャに関する項を参照してください。

関連項目:
「ウィンドウの作成」

ウィンドウの重複

お薦めする方法ではありませんが、ウィンドウは重複して設定できます。

一度にアクティブにできるウィンドウは1つのみであるため、ウィンドウが重複したときにどのウィンドウをアクティブにするかを判別するために、次のルールが使用されます。

- 同じ優先度のウィンドウが重複している場合は、アクティブなウィンドウがオープンしたままになります。ただし、優先度の高いウィンドウと重複している場合は、優先度の低いウィンドウがクローズし、優先度の高いウィンドウがオープンします。優先度の低いウィンドウを指定しているスケジュールを持つ現在実行中のジョブは、ジョブの作成時に割り当てた動作に従って停止される場合があります。

- ウィンドウの終了時に、定義されているウィンドウが複数ある場合は、優先度の最も高いウィンドウがオープンします。すべてのウィンドウの優先度が同じ場合は、残りの時間の比率の最も高いウィンドウがオープンします。

- 削除対象のオープン中のウィンドウは、自動的にクローズします。この時点で前述のルールが適用されます。

2つのウィンドウが重複した場合は、スケジューラのログにエントリが必ず記録されます。

ウィンドウの重複例

図28-3に、24時間スケジュールの場合のウィンドウ、リソース・プランおよび優先度の判別方法に関する一般的な例を示します。次の2つの例では、ウィンドウ1はリソース・プラン1に、ウィンドウ2はリソース・プラン2に関連付けられ、以下も同様に関連付けられているとします。

図28-3 ウィンドウとリソース・プラン(例1)

図28-3では、次の処理が発生します。

- 午前12時から午前4時
いずれのウィンドウもオープンしていないため、デフォルトのリソース・プランが有効です。

- 午前4時から午前6時
ウィンドウ1には低い優先度が割り当てられていますが、高い優先度のウィンドウが他に存在しないためウィンドウ1がオープンします。したがって、リソース・プラン1が有効です。

- 午前6時から午前9時
ウィンドウ1より優先度の高いウィンドウ3がオープンします。したがって、リソース・プラン3が有効です。

- 午前9時から午前11時
優先度が高いウィンドウがオープンしたために、ウィンドウ1は午前6時にクローズされましたが、この優先度の高いウィンドウが午前9時にクローズしたため、ウィンドウ1の元のスケジュールの2時間がウィンドウ1にまだ残っています。この残り2時間のためにそれが再オープンされ、リソース・プランが有効になります。

- 午前11時から午後2時
いずれのウィンドウもオープンしていないため、デフォルトのリソース・プランが有効です。

- 午後2時から午後3時
ウィンドウ2がオープンするため、リソース・プラン2が有効です。

- 午後3時から午後8時
ウィンドウ4の優先度はウィンドウ2と同じであるため、ウィンドウ2への割込みはなく、リソース・プラン2が有効です。

- 午後8時から午後10時
ウィンドウ4がオープンしているため、リソース・プラン4が有効です。

- 午後10時から午前12時
いずれのウィンドウもオープンしていないため、デフォルトのリソース・プランが有効です。

図28-4に、24時間スケジュールの場合のウィンドウ、リソース・プランおよび優先度の判別方法に関する別の例を示します。

図28-4 ウィンドウとリソース・プラン(例2)

図28-4では、次の処理が発生します。

- 午前12時から午前4時
デフォルトのリソース・プランが有効です。

- 午前4時から午前6時
ウィンドウ1には低い優先度が割り当てられていますが、高い優先度のウィンドウが他に存在しないためウィンドウ1がオープンします。したがって、リソース・プラン1が有効です。

- 午前6時から午前9時
ウィンドウ1より優先度の高いウィンドウ3がオープンします。ウィンドウ6は優先度の高い別のウィンドウがすでに有効であるためオープンしません。

- 午前9時から午前11時
午前9時の時点では、ウィンドウ5またはウィンドウ1の2つが選択対象です。両方とも優先度が低いため、残り継続時間の比率の大きさに基づいて選択されます。ウィンドウ1の総継続時間と比較して、ウィンドウ5の残り時間の比率の方が大きい状態です。たとえば、ウィンドウ1が午前11時30分まで延長された場合でも、ウィンドウ5の残り継続時間に対する比率が2/3×100%であるのに対して、ウィンドウ1は2.5/7×100%であるため比率が小さくなります。したがって、リソース・プラン5が有効になります。

グループ

グループは、スケジューラ・オブジェクトのリストを指定します。オブジェクトのリストを引数としてDBMS_SCHEDULERパッケージ・プロシージャに渡すかわりに、オブジェクトがメンバーとして含まれるグループを作成した後、グループ名をプロシージャに渡すことができます。

グループには、次の3種類があります。

- データベース宛先グループ: リモート・データベース・ジョブを実行するためのデータベース宛先がメンバーです。

- 外部宛先グループ: リモート外部ジョブを実行するための外部宛先がメンバーです。

- ウィンドウ・グループ: スケジューラのウィンドウがメンバーです。

グループ内のすべてのメンバーは同一タイプで、各メンバーが一意であることが必要です。

グループは、DBMS_SCHEDULER.CREATE_GROUPプロシージャを使用して作成します。

宛先グループ

ジョブを複数の宛先で実行する場合、データベース宛先グループまたは外部宛先グループを作成し、それをジョブのdestination_name属性に割り当てます。ジョブに複数の宛先を指定する場合は、宛先グループをジョブのdestination_nameとして指定する必要があります。

ウィンドウ・グループ

通常、ウィンドウ・グループを作成するのは、スケジューラ管理者のロールを持っている場合のみです。

ジョブのスケジュールで、ウィンドウを使いやすいようにグループ化できます。ウィンドウ・グループを使用すると、1日あるいは1週間などの間に複数期間実行するジョブを簡単にスケジュールできます。ジョブのschedule_name属性をこのウィンドウ・グループ名に設定すると、ウィンドウ・グループ内のウィンドウで指定されたすべての期間で、このジョブを実行できます。

たとえば、「Weekends」というウィンドウと「Weeknights」というウィンドウがある場合に、これらの2つのウィンドウを「Downtime」というウィンドウ・グループに追加できます。これにより、使用可能なリソースを高い割合で問合せに割り当てることができる時間帯(平日の夜と週末)のDowntimeウィンドウ・グループに問合せを実行するジョブをデータ・ウェアハウスのスタッフが作成できます。

ウィンドウ・グループのウィンドウがすでにオープンしているときに、そのウィンドウ・グループを指し示す新規ジョブが作成された場合、そのジョブはウィンドウ・グループの次のウィンドウがオープンするまで開始されません。

関連項目:

- 「複数の宛先のジョブに対する宛先グループの作成」

- 「ウィンドウ・グループの作成」

- 「ウィンドウ」

ジョブに関する追加説明

この項の内容は次のとおりです。

- ジョブ・カテゴリ

- ジョブ・インスタンス

- ジョブ引数

- プログラム、ジョブおよびスケジュールの関連

関連項目:

- 「ジョブの作成」

- 「ジョブ・ログの表示」

ジョブ・カテゴリ

スケジューラは、次のタイプのジョブをサポートしています。

- データベース・ジョブ

- 外部ジョブ

- 複数の宛先のジョブ

- チェーン・ジョブ

- デタッチ済ジョブ

- 軽量ジョブ

データベース・ジョブ

データベース・ジョブでは、PL/SQL無名ブロック、PL/SQLストアド・プロシージャおよびJavaストアド・プロシージャなどのOracle Databaseプログラム・ユニットが実行されます。処理がインラインで指定されているデータベース・ジョブの場合、job_typeは'PLSQL_BLOCK'または'STORED_PROCEDURE'に設定され、job_actionにはPL/SQL無名ブロックのテキストまたはストアド・プロシージャ名が含まれています。(プログラムがインラインで指定されているプログラム処理ではなく名前付きプログラム・オブジェクトである場合は、それに応じて対応するprogram_typeおよびprogram_actionを設定する必要があります。)

元のデータベース(ジョブが作成されたデータベース)で実行されるデータベース・ジョブをローカル・データベース・ジョブまたは単にジョブと呼びます。元のデータベース以外のターゲット・データベースで実行されるデータベース・ジョブをリモート・データベース・ジョブと呼びます。

ローカル・データベース・ジョブおよびリモート・データベース・ジョブの両方の実行結果を元のデータベースのジョブ・ログ・ビューに表示できます。

ローカル・データベース・ジョブ

ローカル・データベース・ジョブは、ジョブの所有者であるデータベース・ユーザーとして元のデータベースで実行されます。ジョブの所有者は、ジョブが作成されたスキーマの名前です。

リモート・データベース・ジョブ

リモート・データベース・ジョブのターゲット・データベースは、リモート・ホスト上のOracle Databaseまたは元のデータベースと同じホスト上の別のデータベース・インスタンスのどちらにもできます。リモート・データベース・ジョブは、ジョブのdestination_name属性に含まれる既存のデータベース宛先オブジェクトの名前を指定して識別します。

リモート・データベース・ジョブを作成するには、Oracle Database 11g リリース2以降が必要です。ただし、ジョブのターゲット・データベースとしては、任意のOracle Databaseリリースを使用できます。ターゲット・データベースに対するパッチは不要です。(ターゲット・データベース・ホストが元のデータベース・ホストと同じ場合でも)ターゲット・データベース・ホストにスケジューラ・エージェントをインストールして、元のデータベースにエージェントを登録する必要があるだけです。エージェントはOracle Client 11g リリース2以降からインストールする必要があります。

リモート・データベース・ジョブは、ターゲット・データベースで有効なユーザーとして実行する必要があります。必要なユーザー名とパスワードを、リモート・データベース・ジョブに割り当てた資格証明オブジェクトとともに指定します。

関連項目:

- 「資格証明」

- 「ジョブの作成」

- 「リモート・ジョブを実行するためのデータベースの設定の有効化と無効化」

- 「ジョブ・ログの表示」

外部ジョブ

外部ジョブでは、外部実行可能ファイルが実行されます。外部実行可能ファイルは、データベースの外部で実行されるオペレーティング・システム実行可能ファイルです。外部ジョブの場合、job_typeは'EXECUTABLE'と指定されています。(名前付きプログラムを使用している場合は、対応するprogram_typeが'EXECUTABLE'になります)。job_action(または対応するprogram_action)には、必要な外部実行可能ファイルのパス(コマンドライン引数を除く)が、オペレーティング・システムに依存したフルパスの形式で入ります。たとえば、/usr/local/bin/perlやC:\perl\bin\perlのようになります。

Windowsのバッチ・ファイルは直接実行できないため、コマンド・プロンプト(cmd.exe)で実行する必要があることに注意してください。

データベース・ジョブの場合と同様に、外部ジョブを作成する際にスキーマを割り当てることができます。割り当てたスキーマはジョブの所有者になります。外部ジョブをSYSスキーマに作成することもできますが、この方法はお薦めしません。

ローカル外部ジョブまたはリモート外部ジョブを作成するには、CREATE JOB権限とCREATE EXTERNAL JOB権限の両方が必要です。

外部実行可能ファイルは、オペレーティング・システム・ユーザーとして実行する必要があります。したがって、スケジューラでは、作成する外部ジョブにオペレーティング・システムの資格証明を割り当てることができます。リモート・データベース・ジョブの場合と同様に、これらの資格証明をスケジューラ資格証明オブジェクト(資格証明)で指定し、資格証明を外部ジョブに割り当てます。

外部ジョブには、ローカル外部ジョブとリモート外部ジョブの2つのタイプがあります。ローカル外部ジョブでは、そのジョブがスケジュールされているデータベースと同じコンピュータ上で外部実行可能ファイルが実行されます。リモート外部ジョブは、リモート・ホスト上の実行可能ファイルを実行します。リモート・ホストにはOracle Databaseは必要なく、スケジューラ・エージェントをインストールして登録するのみで十分です。

注意:
Windowsでは、外部実行可能ファイルを実行するホスト・ユーザーにLog on as a batch jobログオン権限を割り当てる必要があります。

次の項では、ローカル外部ジョブおよびリモート外部ジョブについて詳細に説明します。

- ローカル外部ジョブの概要

- リモート外部ジョブの概要

関連項目:

- 「資格証明」

- 「リモート・ジョブを実行するためのデータベースの設定の有効化と無効化」

ローカル外部ジョブの概要

ローカル外部ジョブでは、そのジョブがスケジュールされているOracle Databaseと同じコンピュータ上で外部実行可能ファイルが実行されます。このようなジョブでは、destination_nameジョブ属性がNULLになっています。

ローカル外部ジョブでは、stdoutおよびstderrの出力がディレクトリORACLE_HOME/scheduler/log内のログ・ファイルに書き込まれます。これらのファイルの内容は、DBMS_SCHEDULER.GET_FILEで取得できます。

ローカルの外部ジョブに資格証明を割り当てる必要はありませんが、セキュリティ向上のために割り当てることをお薦めします。資格証明を割り当てない場合、デフォルトの資格証明を使用してジョブが実行されます。表28-1に、様々なプラットフォームおよび様々なジョブ所有者のデフォルト資格証明を示します。

表28-1 ローカル外部ジョブに対するデフォルトの資格証明

SYSスキーマのジョブか

プラットフォーム

デフォルトの資格証明

はい

すべて

Oracle Databaseをインストールしたユーザー。

いいえ

UNIXとLinux

ファイルORACLE_HOME/rdbms/admin/externaljob.oraに指定されているrun-user属性およびrun-group属性の値

いいえ

Windows

OracleJobSchedulerSID Windowsサービスの実行ユーザー(ローカル・システム・アカウント、指名ローカル・ユーザーまたはドメイン・ユーザー)

注意: このサービスは手動で有効化して開始する必要があります。セキュリティ向上のため、ローカル・システム・アカウントのかわりに指名ユーザーを使用することをお薦めします。

注意:
デフォルト資格証明は以前のリリースのOracle Databaseとの互換性のために含まれており、将来のリリースでは非推奨になる可能性があります。そのため、すべてのローカル外部ジョブに資格証明を割り当てることをお薦めします。

資格証明が割り当てられていないローカル外部ジョブの実行を禁止するには、ORACLE_HOME/rdbms/admin/externaljob.oraファイルからrun_user属性を削除する(UNIXとLinuxの場合)か、OracleJobSchedulerサービスを停止します(Windowsの場合)。SYSスキーマ内のローカル外部ジョブは、これらのステップでは実行不可になりません。

関連項目:

- ローカル外部ジョブをサポートするためのインストール後の構成ステップについては、使用しているオペレーティング・システム固有のマニュアルを参照してください。

- 例29-8「ローカル外部ジョブの作成とstdoutの取得」

リモート外部ジョブの概要

リモート外部ジョブは、リモート・ホスト上の実行可能ファイルを実行します。リモート・ホストには、Oracle Databaseがインストールされている場合も、されていない場合もあります。特定のリモート・ホストでリモート外部ジョブを実行できるようにするには、リモート・ホストでスケジューラ・エージェントをインストールし、それをローカル・データベースで登録する必要があります。データベースは、外部実行可能ファイルを開始し、実行結果を取得するためにエージェントと通信します。

リモート外部ジョブを作成する場合、ジョブのdestination_name属性で既存の外部宛先オブジェクトの名前を指定します。

リモート外部ジョブでは、stdoutおよびstderrの出力がディレクトリAGENT_HOME/data/log内のログ・ファイルに書き込まれます。これらのファイルの内容は、DBMS_SCHEDULER.GET_FILEで取得できます。例29-8「ローカル外部ジョブの作成とstdoutの取得」には、stdoutの出力の取得方法が示されています。この例はローカル外部ジョブに関するものですが、メソッドはリモート外部ジョブの場合も同じです。

関連項目:

- 「資格証明」

- 「リモート・ジョブを実行するためのデータベースの設定の有効化と無効化」

複数の宛先のジョブ

複数の宛先のジョブとは、ジョブのインスタンスが複数のターゲット・データベースまたはホストで実行されても、中核となる1つのデータベースで制御および監視できるジョブのことです。複数のデータベースまたは複数のホストを管理する必要があるDBAまたはシステム管理者にとって、複数の宛先のジョブは管理が大幅に簡略化されます。複数の宛先のジョブでは、次の操作を行うことができます。

- ジョブを実行する必要のある複数のデータベースまたはホストの指定。

- 複数のターゲットでスケジュールされているジョブの1回の操作による変更。

- 1つ以上のリモート・ターゲットで実行しているジョブの停止。

- 各リモート・ターゲットでのジョブ・インスタンスの状態(実行中、完了、失敗など)の判断。

- ジョブ・インスタンスの集合の全体的な状態の判断。

複数の宛先のジョブは、特定の目的のための単一エンティティとみなしたり、別の目的のために独立して実行されるジョブの集合とみなすことができます。ジョブのメタデータを作成するときには、複数の宛先のジョブは単一エンティティのように見えます。ただし、ジョブ・インスタンスが実行されているときは、各ジョブのほぼ同一コピーであるジョブの集合とみなす方が適切です。ソース・データベースで作成されたジョブを親ジョブと呼び、様々な宛先で実行されるジョブ・インスタンスを子ジョブと呼びます。

複数の宛先のジョブを作成するには、宛先グループをジョブのdestination_name属性に割り当てます。ジョブは、スケジュールされた時間または指定のイベントの検出時に、グループ内のすべての宛先で実行されます。ローカル・ホストは、ジョブが実行される宛先に含めることができます。

ジョブの処理がデータベース・プログラム・ユニットの場合は、destination_name属性でデータベース宛先グループを指定する必要があります。データベース宛先グループのメンバーには、元の(ローカル)データベースを示すデータベース宛先とキーワードLOCALが含まれます。ジョブの処理が外部実行可能ファイルの場合は、destination_name属性で外部宛先グループを指定する必要があります。外部宛先グループのメンバーには、ローカル・ホストを示す外部宛先とキーワードLOCALが含まれます。

注意:
データベース宛先は、リモート・データベースを必ずしも参照する必要はありません。データベース宛先は、ジョブが作成されたデータベースと同じホストで実行している他のデータベースを参照できます。

複数の宛先のジョブとタイム・ゾーン

一部のジョブの宛先は、親ジョブが作成されたデータベース(元のデータベース)のタイムゾーンとは異なるタイムゾーンにある場合があります。この場合、ジョブの開始時刻は、常に元のデータベースのタイム・ゾーンを基にします。したがって、親ジョブをロンドン(英国)で作成して開始時刻を午後8時に指定し、宛先として東京、ロサンゼルス、ニューヨークを指定した場合、子ジョブはロンドン時刻の午後8時に開始します。すべての宛先での開始時刻は、システムの負荷の違いや再試行を必要とする問題などによって、多少のずれが発生する場合があります。

イベント・ベースの複数の宛先のジョブ

イベント・ベースの複数の宛先のジョブの場合、親ジョブがイベントをホストで検出すると、すべての子ジョブがすべての宛先で開始します。子ジョブは、それぞれのホストでイベントを検出しません。

関連項目:

- 「複数の宛先のジョブの作成」

- 「複数の宛先のジョブの監視」

- 「宛先グループ」

- 「イベントを使用したジョブの開始」

チェーン・ジョブ

チェーンは、依存性ベースのスケジューリングを可能にするスケジューラ・メカニズムです。最も単純な形式では、プログラム・オブジェクトのグループとプログラム・オブジェクト間の依存性が定義されます。ジョブは、単一のプログラム・オブジェクトを指し示すかわりにチェーンを指し示すことができます。その場合、ジョブはチェーンを開始する役割を持ちます。チェーン・ジョブの場合、job_typeは'CHAIN'として指定されます。

関連項目:

- 「チェーン」

- 「ジョブ・チェーンの作成と管理」

デタッチ済ジョブ

デタッチされたジョブを使用して、スケジューラとは独立して非同期に別のプロセスで実行されるスクリプトやアプリケーションを起動できます。通常、デタッチされたジョブは別のプロセスを起動してから終了します。終了時(ジョブ処理の完了時)に、デタッチされたジョブは実行状態のままになります。この実行状態は、このジョブが起動した非同期プロセスがまだアクティブであることを示しています。非同期プロセスは、その作業を完了するときに、データベースに接続して、ジョブを終了させるDBMS_SCHEDULER.END_DETACHED_JOB_RUNを呼び出す必要があります。

use_current_sessionパラメータがTRUEに設定されている場合、run_jobを使用して手動で実行をトリガーして、デタッチされたジョブを実行することはできません。

ジョブは、detached属性がTRUEに設定されているプログラム・オブジェクト(プログラム)(デタッチ済プログラム)を指している場合、デタッチ済です。

デタッチ済ジョブは、次の2つの場合に使用します。

- 必要以上にリソースを保持するため、起動した非同期プロセスが完了するまで待機することが実際的でない場合。
一例として、非同期Webサービスにリクエストを送信する場合があります。Webサービスが応答するのに何時間または何日もかかる場合があり、応答待ちの間、スケジューラ・ジョブ・スレーブを保留することはできません。(ジョブ・スレーブの詳細は、「スケジューラのアーキテクチャ」を参照してください。)

- プロセスによりデータベースが停止されるため、起動した非同期プロセスが完了するまで待機できない場合。
たとえば、スケジューラ・ジョブを使用して、データベースの停止、コールド・バックアップの作成およびデータベースの再起動を実行するRMANスクリプトを起動する場合です。例29-5を参照してください。

デタッチ済ジョブの動作は次のとおりです。

1. ジョブの開始時に、ジョブ・コーディネータによりジョブにジョブ・スレーブが割り当てられ、デタッチ済プログラムに定義されているプログラム処理がジョブ・スレーブにより実行されます。プログラム処理は、PL/SQLブロック、ストアド・プロシージャまたは外部実行可能ファイルのいずれかです。

2. プログラム処理は、別のスクリプトまたは実行可能ファイル(この例ではプロセスA)の即時リターン・コールを実行してから終了します。プログラム処理の動作は完了しているため、ジョブ・スレーブは終了しますが、ジョブは実行中の状態のまま残ります。

3. プロセスAにより処理が実行されます。データベースに対するDMLを実行する場合は、その処理をコミットする必要があります。処理が完了すると、プロセスAによりデータベースにログが記録され、END_DETACHED_JOB_RUNがコールされます。

4. デタッチ済ジョブが完了として記録されます。

実行中のデタッチ済ジョブを終了するには、STOP_JOBをコールする方法もあります。

関連項目:
デタッチ済ジョブを使用してデータベースのコールド・バックアップを実行する例は、「デタッチ済ジョブの作成」を参照してください。

軽量ジョブ

軽量ジョブは、多数の短時間のジョブを頻繁に実行する場合に使用します。特定の条件下では、軽量ジョブを使用してもパフォーマンスがあまり向上しない場合があります。

軽量ジョブには、次の特性があります。

- 標準ジョブとは異なり、スキーマ・オブジェクトではありません。

- スキーマ・オブジェクトを作成する際のオーバーヘッドを伴わないため、作成および削除に必要な時間が標準ジョブよりも大幅に短縮されます。

- セッションの平均作成時間が標準ジョブよりも短縮されます。

- ジョブのメタデータと実行時データに関して、ディスク上のフットプリントが小さくなります。

軽量ジョブを指定するには、job_styleジョブ属性を'LIGHTWEIGHT'に設定します。もう1つのジョブ・スタイルは、デフォルトの'REGULAR'です。

プログラムやスケジュールと同様に、標準ジョブはスキーマ・オブジェクトです。Oracle Database 11g リリース1より前のリリースでは、標準ジョブがスケジューラでサポートされる唯一のジョブ・スタイルでした。

通常のジョブは最も柔軟性がありますが、作成または削除されるときに多少のオーバーヘッドを伴います。ユーザーはジョブの権限を細かく制御でき、別のユーザーが所有するプログラムやストアド・プロシージャをジョブの処理として指定できます。

実行頻度が低い比較的少数のジョブを作成する必要がある場合は、軽量ジョブよりも標準ジョブが優先されます。

軽量ジョブでは、プログラム・オブジェクト(プログラム)を参照してジョブの処理を指定する必要があります。プログラムは軽量ジョブの作成時に有効化されている必要があり、プログラム・タイプは'PLSQL_BLOCK'または'STORED_PROCEDURE'であることが必要です。軽量ジョブはスキーマ・オブジェクトではないため、権限は付与できません。軽量ジョブは指定のプログラムから権限を継承します。したがって、プログラムに対して特定の権限セットを持つユーザーは、軽量ジョブに対して対応する権限を持つことになります。

関連項目:
軽量ジョブの作成例は、「ジョブの作成」および「スケジューラの使用例」を参照してください。

ジョブ・インスタンス

ジョブ・インスタンスは、ジョブの特定の実行を表します。1回だけ実行するようにスケジュールされているジョブには、1つのインスタンスのみがあります。繰返しスケジュールされているジョブおよびイベントが発生するたびに実行されるジョブには、複数のインスタンスがあり、ジョブの各実行がインスタンスを表します。たとえば、2009年10月8日火曜日のみに実行するようにスケジュールされているジョブには1つのインスタンスがあり、1週間毎日正午に実行されるジョブには7つのインスタンスがあり、ファイルがリモート・システムに到着すると実行されるジョブには、ファイル到着イベントごとに1つのインスタンスがあります。

複数の宛先のジョブには、宛先ごとに1つのインスタンスがあります。複数の宛先のジョブが繰返しスケジュールされている場合は、各宛先のジョブの実行ごとに1つのインスタンスがあります。

ジョブが作成されると、ジョブを表すエントリがスケジューラのジョブ表に1つのみ追加されます。ロギング・レベルの設定に応じて、ジョブが実行されるたびに、ジョブ・ログにエントリが追加されます。そのため、繰返しのスケジュールが設定されているジョブを作成すると、ジョブ・ビュー(*_SCHEDULER_JOBS)には1つのエントリが存在し、ジョブ・ログには複数のエントリが存在することになります。各ジョブ・インスタンスのログ・エントリは、ジョブの完了ステータス、開始時刻、終了時刻など、特定の実行に関する情報を提供します。ジョブの各実行には一意のログIDが割り当てられて、ジョブ・ログとジョブ実行詳細ビュー(*_SCHEDULER_JOB_LOGと*_SCHEDULER_JOB_RUN_DETAILS)の両方に表示されます。

関連項目:

- 「ジョブの監視」

- 「スケジューラのデータ・ディクショナリ・ビュー」

ジョブ引数

ジョブでプログラム・オブジェクト(プログラム)を参照する場合、ジョブ引数を指定してデフォルトのプログラム引数値を上書きするか、デフォルト値のないプログラム引数の値を提供できます。また、ジョブが指定するインライン処理(例: ストアド・プロシージャ)に対しても引数値を提供できます。

必要なプログラム引数値のすべてが、参照先のプログラム・オブジェクトにデフォルトとして定義されているか、またはジョブ引数として定義されるまで、ジョブは使用できません。

ジョブの一般的な例には、一連のレポートを夜間に実行するジョブがあります。様々な部門で様々なレポートが必要な場合は、このタスクのプログラムを、様々な部門の様々なユーザー間で共有できるように作成できます。このプログラム処理では、レポート・スクリプトが実行され、プログラムには1つの引数として、部門番号を設定します。各ユーザーはこのプログラムを指し示すジョブを作成し、部門番号をジョブ引数として指定できます。

関連項目:

- 「ジョブ引数の設定」

- 「プログラム引数の定義」

- 「ジョブの作成」

プログラム、ジョブおよびスケジュールの関連

実行内容と実行時期を定義するには、プログラム、ジョブおよびスケジュール間に関連を割り当てます。図28-5に、これらの関連の例を示します。

図28-5 プログラム、ジョブおよびスケジュール間の関連

図28-5を理解するために、表を分析する場合を考えてみます。この例では、プログラムP1がDBMS_STATSパッケージを使用して表を分析します。このプログラムには、表名に対する入力パラメータがあります。2つのジョブJ1とJ2は、両方とも同じプログラムを指し示していますが、別々の表名が指定されています。さらに、スケジュールS1には、毎日午前2時の実行時間を指定します。最終的な結果として、J1とJ2で名前が指定された2つの表は、毎日午前2時に分析されます。

J4は、すべての関連情報がそのジョブ自体に定義された自己完結のジョブで、他のエンティティを指し示していないことに注意してください。P2、P9およびS2は、必要に応じて、プログラムまたはスケジュールに関連を割り当てないままにできることを示しています。たとえば、年度末の在庫を計算するプログラムを作成し、一時的に、そのプログラムをどのジョブにも割り当てないままにできます。

スケジューラのアーキテクチャ

この項では、スケジューラのアーキテクチャについて説明します。この項の内容は、次のとおりです。

- ジョブ表

- ジョブ・コーディネータ

- ジョブの実行方法

- ジョブの完了後

- Real Application Clusters環境におけるスケジューラの使用

図28-6に、データベースによるジョブの処理方法を示します。

図28-6 スケジューラの構成要素

ジョブ表

ジョブ表はすべてのジョブのコンテナであり、データベースごとにあります。ジョブ表には、すべてのジョブに関する所有者名やロギング・レベルなどの情報が保存されています。この情報は、*_SCHEDULER_JOBSビューにあります。

ジョブはデータベース・オブジェクトであるため、累積されて多くの領域を使用する場合があります。これを回避するために、ジョブ・オブジェクトは、ジョブの完了後、デフォルトで自動的に削除されます。この動作は、auto_dropジョブ属性によって制御されます。

使用可能なジョブのビューと管理については、「スケジューラのデータ・ディクショナリ・ビュー」を参照してください。

ジョブ・コーディネータ

ジョブ・コーディネータは、データベースの制御のもと、ジョブ表の情報を使用してジョブ・スレーブを制御および起動します。

ジョブ・コーディネータ・バックグラウンド・プロセス(cjqNNN)は、必要に応じて自動的に起動および停止します。データベースの起動時に、ジョブ・コーディネータは起動されませんが、実行するジョブがあるかどうか、および近い将来開くウィンドウがあるかどうかをデータベースが監視します。ある場合は、コーディネータが起動されます。

実行中のジョブまたはウィンドウがある間は、コーディネータは継続的に実行されます。スケジューラが一定期間非アクティブな状態にあり、近い将来にスケジュールされたジョブまたはウィンドウがない場合、コーディネータは自動的に停止します。

ジョブ・コーディネータを起動するかどうかをデータベースが判断する際は、ジョブのサービス・アフィニティが考慮されます。たとえば、近い将来スケジュールされるジョブが1つのみで、4つのRACインスタンスのうち2つのみにサービス・アフィニティがあるジョブ・クラスにこのジョブが属している場合は、この2つのインスタンスのジョブ・コーディネータのみが起動されます。詳細は、「スケジューラ使用時のサービス・アフィニティ」を参照してください。

ジョブ・コーディネータの処理

ジョブ・コーディネータの機能は次のとおりです。

- ジョブ・スレーブを制御および起動します。

- ジョブ表を問い合せます。

- ジョブ表からジョブを定期的に取り出し、メモリー・キャッシュに格納します。この結果、ディスクへのトリップが減るため、パフォーマンスが向上します。

- メモリー・キャッシュからジョブを取り出し、実行するためにジョブ・スレーブに渡します。

- スレーブが不要になると、ジョブ・スレーブ・プールをクリーン・アップします。

- スケジュールされているジョブがないときは休止状態になります。

- 新規ジョブが実行されるとき、またはCREATE_JOBプロシージャを使用してジョブが作成されたときに起動します。

- データベースの異常停止後の起動時に、実行していたジョブをリカバリします。

ジョブ・コーディネータがジョブ表を確認する時間を設定する必要はありません。タイム・フレームはシステムで自動的に選択されます。

インスタンスごとに1つのジョブ・コーディネータが使用されます。これは、Oracle RAC環境の場合も同じです。

関連項目:
ジョブ・コーディネータの管理については、「スケジューラのデータ・ディクショナリ・ビュー」を参照してください。Oracle RACの情報については、「Real Application Clusters環境におけるスケジューラの使用」を参照してください。

スケジューラ・ジョブ・プロセスの最大数

コーディネータは、CPU負荷および処理中のジョブ数に基づいて、起動するジョブ・スレーブ数を自動的に決定します。JOB_QUEUE_PROCESSES初期化パラメータを使用して、スケジューラが起動できるジョブ・スレーブの数を制限できます。

ジョブの実行方法

ジョブ・スレーブは、発行されたジョブを実際に実行します。ジョブの実行時期になるとジョブ・コーディネータによって起動されます。ジョブ・スレーブは、ジョブ表からジョブを実行するためのメタデータを収集します。

処理のためにジョブが取り出されると、ジョブ・スレーブは次のことを実行します。

1. プログラム引数や権限情報など、ジョブの実行に必要なすべてのメタデータを収集します。

2. ジョブの所有者としてデータベース・セッションを開始し、トランザクションを開始した後に、ジョブの実行を開始します。

3. ジョブが完了すると、スレーブはトランザクションをコミットし、終了します。

4. セッションをクローズします。

ジョブの完了後

ジョブが終了すると、スレーブは次のことを実行します。

- 必要に応じて、ジョブを再スケジュールします。

- ジョブ表の状態を更新して、ジョブを完了するか、再スケジュールするかを反映します。

- エントリをジョブ・ログ表に挿入します。

- 実行回数を更新し、必要に応じて、失敗の回数と再試行の回数を更新します。

- クリーン・アップします。

- 新規作業を検索します(検出されない場合は休止状態になります)。

スケジューラは、必要に応じてスレーブ・プールを動的にサイズ変更します。

Real Application Clusters環境におけるスケジューラの使用

Oracle Real Application Clusters (Oracle RAC)環境では、スケジューラは、データベースごとに1つのジョブ表を使用し、インスタンスごとに1つのジョブ・コーディネータを使用します。ジョブ・コーディネータは相互に通信して情報を最新に保ちます。ジョブ・クラスにサービス・アフィニティがない場合、スケジューラは、使用可能なすべてのインスタンス間でジョブ・クラスのジョブの負荷を分散しようとしますが、ジョブ・クラスにサービス・アフィニティがある場合は、特定のサービスに割り当てられているインスタンス間で負荷を分散しようとします。

図28-7に、典型的なOracle RACアーキテクチャを示します。各インスタンスのジョブ・コーディネータは他のコーディネータと情報を交換します。

図28-7 Oracle RACのアーキテクチャとスケジューラ

スケジューラ使用時のサービス・アフィニティ

スケジューラを使用すると、ジョブを実行するデータベース・サービス(サービス・アフィニティ)を指定できます。これにより、インスタンスがダウンした場合に他のノードにサービスが必ず動的に割り当てられるため、インスタンス・アフィニティの場合よりも可用性がよくなります。インスタンス・アフィニティにはこの機能がないので、インスタンスがダウンすると、そのインスタンスへのアフィニティが指定されたジョブは、そのインスタンスがダウン状態から回復するまで実行されません。図28-8は、サービスおよびインスタンスの一般的な使用例を示しています。

図28-8 サービス・アフィニティとスケジューラ

図28-8では、サービスのプロパティが変更可能で、その変更はスケジューラによって自動的に認識されます。

各ジョブ・クラスで、データベース・サービスを指定できます。サービスの指定がない場合、このジョブ・クラスは、起動しているすべてのインスタンスへのマッピングが保証されている内部サービスに属します。

スケジューラによるOracle Data Guardのサポート

Oracle Database 11g リリース1からは、データベースがプライマリ・データベースかロジカル・スタンバイ・データベースかに基づいて、スケジューラがOracle Data Guard環境でジョブを実行できるようになりました。

フィジカル・スタンバイ・データベースの場合、スケジューラのオブジェクトに対する変更またはプライマリ・データベース上のスケジューラのジョブによるデータベースの変更は、他のデータベースの変更と同様にフィジカル・スタンバイに適用されます。

プライマリ・データベースおよびロジカル・スタンバイ・データベースの場合は、データベースがプライマリ・データベースまたはロジカル・スタンバイのロールの場合にのみ、ジョブを実行できるように指定できるという追加機能があります。これは、DBMS_SCHEDULER.SET_ATTRIBUTEプロシージャを使用して、database_roleジョブ属性を'PRIMARY'または'LOGICAL STANDBY'の2つの値のどちらかに設定して使用します。(両方のロールでジョブを実行するには、ジョブのコピーを作成して、1つのジョブのdatabase_roleを'PRIMARY'に設定し、もう1つのジョブでは'LOGICAL STANDBY'に設定します。)スイッチオーバーまたはフェイルオーバー時には、新しいロール固有のジョブを実行するようにスケジューラが自動的に切り替わります。プライマリ・データベースで障害が発生するまで正常に実行されたレコードを、フェイルオーバー時に使用できるように、ジョブ・イベント・ログにDMLが複製されます。

関連項目:

- database_role属性の設定例は、「属性の設定例」を参照してください。

- 「Oracle Data Guard環境でのジョブの作成例」

- 『Oracle Data Guard概要および管理』

Oracle Schedulerとエディション

スケジューラ・ジョブには、常にデータベースのデフォルト・エディションが使用されます。

関連項目:
エディションおよびエディションに基づく再定義の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

29 Oracle Schedulerを使用したジョブのスケジューリング

この章の内容は、次のとおりです。

- スケジューラ・オブジェクトとそのネーミングの概要

- ジョブの作成、実行および管理

- ジョブを定義するためのプログラムの作成および管理

- ジョブを定義するためのスケジュールの作成および管理

- イベントを使用したジョブの開始

- ジョブ・チェーンの作成と管理

- ジョブの優先度付け

- ジョブの監視

注意:
この章では、DBMS_SCHEDULERパッケージを使用してスケジューラ・オブジェクトを処理する方法について説明します。同じ作業をOracle Enterprise Managerを使用して実行できます。
DBMS_SCHEDULERの詳細は『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を、Oracle Schedulerの各ページの詳細はOracle Enterprise Managerのオンライン・ヘルプを参照してください。

スケジューラ・オブジェクトとそのネーミングの概要

Oracle Schedulerは、一連のスケジューラ・オブジェクトを作成および管理することにより操作します。各スケジューラ・オブジェクトは、[schema.]nameの形式の完全なデータベース・スキーマ・オブジェクトです。スケジューラ・オブジェクトは、データベース・オブジェクトの命名規則に正確に従い、他のデータベース・オブジェクトとSQLネームスペースを共有します。

SQLの命名規則に従ってDBMS_SCHEDULERパッケージのスケジューラ・オブジェクトに名前を付けます。デフォルトでは、二重引用符で囲まれていないかぎり、スケジューラ・オブジェクトの名前は大文字になります。たとえば、ジョブを作成する際に、job_name => 'my_job'はjob_name => 'My_Job'およびjob_name => 'MY_JOB'と同じですが、job_name => '"my_job"'とは異なります。スケジューラ・オブジェクト名のカンマ区切リストがDBMS_SCHEDULERパッケージ内で使用される場合も、これらの命名規則に従います。

関連項目:

- オブジェクトのネーミングの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 「ジョブおよびスケジューラ・オブジェクトのサポートの概要」

ジョブの作成、実行および管理

ジョブとは、スケジュールとプログラムの組合せに、プログラムに必要な追加の引数が指定されたものです。この項では、ジョブの基本的なタスクについて説明します。この項の内容は、次のとおりです。

- ジョブのタスクとそのプロシージャ

- ジョブの作成

- ジョブの変更

- ジョブの実行

- ジョブの停止

- ジョブの削除

- ジョブの無効化

- ジョブの有効化

- ジョブのコピー

- ジョブ・ログの表示

- 外部ジョブのstdoutとstderrの表示

関連項目:
ジョブの概要については、「ジョブ」を参照してください。

ジョブのタスクとそのプロシージャ

表29-1に、ジョブの一般的なタスクとそれに対応するプロシージャおよび権限を示します。

表29-1 ジョブのタスクとそのプロシージャ

タスク

プロシージャ

必要な権限

ジョブの作成

CREATE_JOBまたはCREATE_JOBS

CREATE JOBまたはCREATE ANY JOB

ジョブの変更

SET_ATTRIBUTEまたはSET_JOB_ATTRIBUTES

ALTERまたはCREATE ANY JOB、あるいは所有者

ジョブの実行

RUN_JOB

ALTERまたはCREATE ANY JOB、あるいは所有者

ジョブのコピー

COPY_JOB

ALTERまたはCREATE ANY JOB、あるいは所有者

ジョブの削除

DROP_JOB

ALTERまたはCREATE ANY JOB、あるいは所有者

ジョブの停止

STOP_JOB

ALTERまたはCREATE ANY JOB、あるいは所有者

ジョブの使用禁止

DISABLE

ALTERまたはCREATE ANY JOB、あるいは所有者

ジョブの使用可能化

ENABLE

ALTERまたはCREATE ANY JOB、あるいは所有者

権限の詳細は、「スケジューラ権限」を参照してください。

ジョブの作成

この項の内容は次のとおりです。

- ジョブ作成の概要

- ジョブの処理とジョブ・スケジュールの指定

- ジョブの資格情報とジョブの宛先の指定

- 複数の宛先のジョブの作成

- ジョブ引数の設定

- ジョブ属性の追加設定

- デタッチ済ジョブの作成

- 単一トランザクションでの複数ジョブの作成

- 外部ジョブの手法

ジョブ作成の概要

1つ以上のジョブを作成するには、DBMS_SCHEDULER.CREATE_JOBまたはDBMS_SCHEDULER.CREATE_JOBSプロシージャ、あるいはEnterprise Managerを使用します。単一のジョブを作成するには、CREATE_JOBプロシージャを使用します。このプロシージャを使用して、異なるオブジェクトに基づく様々なタイプの複数のジョブを作成するとオーバーロードになります。単一トランザクションに複数のジョブを作成する場合は、CREATE_JOBSプロシージャを使用してください。

自分のスキーマにジョブを作成するにはCREATE JOB権限が、SYS以外のすべてのスキーマにジョブを作成するにはCREATE ANY JOB権限が必要です。

作成される各ジョブに対して、ジョブ・タイプ、処理およびスケジュールを指定します。必要応じて、資格証明の名前、宛先や宛先グループ名、ジョブ・クラスおよび他の属性も指定できます。ジョブを有効にするとすぐに、スケジュールされた次の日付と時刻に、スケジューラによってジョブが自動的に実行されます。デフォルトでは、作成時にジョブは無効になっており、DBMS_SCHEDULER.ENABLEで有効にして実行する必要があります。CREATE_JOBプロシージャのenabled引数をTRUEに設定することもできます。その場合、ジョブを作成するとすぐに、スケジュールに従ってジョブを自動的に実行する準備が整います。

一部のジョブ属性はCREATE_JOBでは設定できないため、かわりにDBMS_SCHEDULER.SET_ATTRIBUTEで設定する必要があります。たとえば、ジョブにlogging_level属性を設定するには、CREATE_JOBをコールした後、SET_ATTRIBUTEをコールする必要があります。

schema.job_nameを指定すると、別のスキーマ内にジョブを作成できます。したがって、ジョブの作成者がジョブの所有者であるとはかぎりません。ジョブの所有者は、ジョブが作成されるスキーマを所有しているユーザーです。実行時のジョブのNLS環境は、そのジョブが作成された時点に存在していた環境です。

例29-1に、update_salesというデータベース・ジョブを作成する方法を示します。このジョブは、売上集計表を更新する、OPSスキーマ内のパッケージ・プロシージャをコールします。

例29-1 ジョブの作成

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name           =>  'update_sales',
job_type           =>  'STORED_PROCEDURE',
job_action         =>  'OPS.SALES_PKG.UPDATE_SALES_SUMMARY',
start_date         =>  '28-APR-08 07.00.00 PM Australia/Sydney',
repeat_interval    =>  'FREQ=DAILY;INTERVAL=2', /* every other day */
end_date           =>  '20-NOV-08 07.00.00 PM Australia/Sydney',
auto_drop          =>   FALSE,
job_class          =>  'batch_update_jobs',
comments           =>  'My new job');
END;
/

destination_name属性は指定されていないため、ジョブは作成元の(ローカル)データベースで実行されます。ジョブは、ジョブを作成したユーザーとして実行されます。

repeat_interval引数では、このジョブが終了日時に達するまで1日おきに実行されるように指定しています。繰返しジョブの実行回数を制限するもう1つの方法として、max_runs属性を正の数に設定する方法があります。

ジョブの作成時、デフォルトではジョブは使用禁止になっています。ジョブは、スケジューラによって自動的に実行される前に、DBMS_SCHEDULER.ENABLEで使用可能にする必要があります。

ジョブは、デフォルトでは完了後に自動的に削除されるように設定されています。auto_drop属性をFALSEに設定すると、ジョブは保持されます。繰返しジョブは、ジョブ終了日をすぎるか、最大実行回数(max_runs)または最大失敗回数(max_failures)に達するまでは自動削除されないことに注意してください。

作成したジョブは、*_SCHEDULER_JOBSビューを使用して問い合せることができます。

関連項目:
「ジョブの資格情報とジョブの宛先の指定」

ジョブの処理とジョブ・スケジュールの指定

CREATE_JOBプロシージャはオーバーロードになるため、複数の異なる使用方法があります。インラインのジョブの処理とジョブ・スケジュールの指定とも呼ばれ、例29-1に示すようなジョブの処理とジョブの繰返し間隔の指定に加えて、ジョブの処理を指定するプログラム・オブジェクト(プログラム)、繰返し間隔を指定するスケジュール・オブジェクト(スケジュール)、またはプログラムとスケジュールの両方を指し示すジョブを作成することもできます。次の各項で、これについて説明します。

- 名前付きプログラムを使用したジョブの作成

- 名前付きスケジュールを使用したジョブの作成

- 名前付きプログラムとスケジュールを使用したジョブの作成

関連項目:

- 「プログラム」

- 「スケジュール」

名前付きプログラムを使用したジョブの作成

ジョブの処理をインラインで記述するかわりに、名前付きプログラムを指し示してジョブを作成することもできます。名前付きプログラムを使用してジョブを作成するには、ジョブの作成時にCREATE_JOBプロシージャでprogram_nameの値を指定し、job_type、job_actionおよびnumber_of_argumentsの値は指定しません。

既存のプログラムを使用してジョブを作成するには、ジョブの所有者がプログラムの所有者であるか、プログラムに対するEXECUTE権限を持っている必要があります。次のPL/SQLブロックは、my_new_job1という標準ジョブを作成する名前付きプログラムが指定されたCREATE_JOBプロシージャの例です。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name          =>  'my_new_job1',
program_name      =>  'my_saved_program',
repeat_interval   =>  'FREQ=DAILY;BYHOUR=12',
comments          =>  'Daily at noon');
END;
/

次のPL/SQLブロックでは、軽量ジョブが作成されます。軽量ジョブは1つのプログラムを参照する必要があり、プログラム・タイプは'PLSQL_BLOCK'または'STORED_PROCEDURE'であることが必要です。さらに、プログラムはジョブの作成時に使用可能になっている必要があります。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name         =>  'my_lightweight_job1',
program_name     =>  'polling_prog_n2',
repeat_interval  =>  'FREQ=SECONDLY;INTERVAL=10',
end_date         =>  '30-APR-09 04.00.00 AM Australia/Sydney',
job_style        => 'LIGHTWEIGHT',
comments         => 'Job that polls device n2 every 10 seconds');
END;
/

名前付きスケジュールを使用したジョブの作成

ジョブのスケジュールをインラインで記述するかわりに、名前付きスケジュールを指し示してジョブを作成することもできます。名前付きスケジュールを使用してジョブを作成するには、ジョブの作成時にCREATE_JOBプロシージャでschedule_nameの値を指定し、start_date、repeat_intervalおよびend_dateの値は指定しません。

すべてのスケジュールはPUBLICに対するアクセス権限付きで作成されるため、任意の名前付きスケジュールを使用してジョブを作成できます。次のCREATE_JOBプロシージャには名前付きスケジュールがあり、my_new_job2という標準ジョブを作成します。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name                 =>  'my_new_job2',
job_type                 =>  'PLSQL_BLOCK',
job_action               =>  'BEGIN SALES_PKG.UPDATE_SALES_SUMMARY; END;',
schedule_name            =>  'my_saved_schedule');
END;
/

名前付きプログラムとスケジュールを使用したジョブの作成

ジョブは、名前付きプログラムと名前付きスケジュールの両方を指し示して作成することもできます。たとえば、次のCREATE_JOBプロシージャは、既存のプログラムmy_saved_program1および既存のスケジュールmy_saved_schedule1に基づいて、標準ジョブをmy_new_job3という名前で作成します。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name            =>  'my_new_job3',
program_name        =>  'my_saved_program1',
schedule_name       =>  'my_saved_schedule1');
END;
/

関連項目:

- 「ジョブを定義するためのプログラムの作成および管理」

- 「ジョブを定義するためのスケジュールの作成および管理」

- 「イベントを使用したジョブの開始」

ジョブの資格情報とジョブの宛先の指定

ローカル外部ジョブ、リモート外部ジョブおよびリモート・データベース・ジョブの場合、ジョブを実行するための資格証明を指定する必要があります。そのためには、資格証明オブジェクトを作成して、それをcredential_nameジョブ属性に割り当てます。

リモート外部ジョブおよびリモート・データベース・ジョブの場合は、宛先オブジェクトを作成してdestination_nameジョブ属性に割り当てることにより、ジョブの宛先を指定します。NULLのdestination_name属性が指定されたジョブは、ジョブが作成されたホストで実行されます。

この項の内容は次のとおりです。

- 資格証明および宛先のタスクとそのプロシージャ

- 資格証明の作成

- 宛先の作成

- 複数の宛先のジョブに対する宛先グループの作成

- 例: リモート・データベース・ジョブの作成

関連項目:

- 「資格証明」

- 「宛先」

- 「複数の宛先のジョブの作成」

資格証明および宛先のタスクとそのプロシージャ

表29-2に、資格証明および宛先のタスクとそのプロシージャおよび権限を示します。

表29-2 資格証明および宛先のタスクとそのプロシージャ

タスク

プロシージャ

必要な権限

資格証明の作成

CREATE_CREDENTIAL

CREATE JOBまたはCREATE ANY JOB

資格証明の削除

DROP_CREDENTIAL

CREATE ANY JOBまたは所有者であること

外部宛先の作成

(なし)

「宛先の作成」を参照

外部宛先の削除

DROP_AGENT_DESTINATION

MANAGE SCHEDULER

データベース宛先の作成

CREATE_DATABASE_DESTINATION

CREATE JOBまたはCREATE ANY JOB

データベース宛先の削除

DROP_DATABASE_DESTINATION

CREATE ANY JOBまたは所有者であること

宛先グループの作成

CREATE_GROUP

CREATE JOBまたはCREATE ANY JOB

宛先グループの削除

DROP_GROUP

CREATE ANY JOBまたは所有者であること

宛先グループへのメンバーの追加

ADD_GROUP_MEMBER

ALTERまたはCREATE ANY JOB、あるいは所有者

宛先グループからのメンバーの削除

REMOVE_GROUP_MEMBER

ALTERまたはCREATE ANY JOB、あるいは所有者

資格証明の作成

資格証明は、専用のデータベース・オブジェクトに格納されているユーザー名とパスワードのペアです。ジョブに資格証明を割り当てることによって、ジョブを実行する前にOracle Databaseまたはオペレーティング・システムで認証できるようにします。

資格証明を作成する手順は、次のとおりです。

- DBMS_SCHEDULER.CREATE_CREDENTIALプロシージャをコールします。

自分のスキーマに資格証明を作成するにはCREATE JOB権限が、SYS以外のスキーマに資格証明を作成するにはCREATE ANY JOB権限が必要です。資格証明を使用できるのは、資格証明のEXECUTE権限がジョブの所有者に付与されているジョブ、またはジョブの所有者が資格証明の所有者を兼ねているジョブのみです。資格証明は他のスキーマ・オブジェクトのようにスキーマに属しているため、資格証明に対する権限はGRANT SQL文を使用して付与します。

例29-2 資格証明の作成

BEGIN
DBMS_SCHEDULER.CREATE_CREDENTIAL('DW_CREDENTIAL', 'dwuser', 'dW001515');
END;
/

GRANT EXECUTE ON DW_CREDENTIAL TO salesuser;

データベース内の資格証明のリストを表示するには、*_SCHEDULER_CREDENTIALSビューを問い合せます。資格証明パスワードは不明瞭な状態で格納されるため、*_SCHEDULER_CREDENTIALSビューには表示されません。

関連項目:
資格証明の詳細は、「資格証明」を参照してください。

宛先の作成

宛先とは、ジョブを実行する場所を定義したスケジューラ・オブジェクトです。ジョブが実行される場所を指定するには、ジョブのdestination_name属性に単一の宛先または宛先グループを指定します。destination_name属性をNULLのままにすると、ジョブはローカル・ホスト(ジョブが作成されたホスト)で実行されます。

リモート外部ジョブが実行される場所を指定するには、外部宛先を使用します。リモート・データベース・ジョブが実行される場所を指定するには、データベース宛先を使用します。

別のユーザーが作成した宛先を使用するのにオブジェクト権限は必要ありません。

外部宛先を作成する手順は、次のとおりです。

- リモート・スケジューラ・エージェントをデータベースに登録します。
手順は、「リモート・ホストでのスケジューラ・エージェントのインストールと構成」を参照してください。

注意:
外部宛先を作成するためのDBMS_SCHEDULERパッケージ・プロシージャはありません。外部宛先は、リモート・エージェントを登録することによって暗黙的に作成します。
リモート・ジョブのターゲットとなるホストで他のデータベース・インスタンスを実行している場合は、ローカル・スケジューラ・エージェントも登録できます。この場合、ローカル・ホストを参照する外部宛先が作成されます。

外部宛先の名前は自動的にエージェント名に設定されます。外部宛先が作成されたかどうかを確認するには、DBA_SCHEDULER_EXTERNAL_DESTSビューまたはALL_SCHEDULER_EXTERNAL_DESTSビューを問い合せます。

データベース宛先を作成する手順は、次のとおりです。

- DBMS_SCHEDULER.CREATE_DATABASE_DESTINATIONプロシージャをコールします。
プロシージャの引数として外部宛先の名前を指定する必要があります。これにより、データベース宛先が指し示すリモート・ホストが指定されます。また、ネット・サービス名を指定したり、接続先のデータベース・インスタンスを識別する接続記述子を入力します。ネット・サービス名を指定した場合、その名前はローカルのtnsnames.oraファイルで解決される必要があります。データベース・インスタンスを指定しなかった場合、リモート・スケジューラ・エージェントは、エージェント構成ファイルに指定されているデフォルトのデータベースに接続されます。

データベース宛先を作成するには、CREATE JOBシステム権限が必要です。自身のスキーマ以外のスキーマにデータベース接続先を作成するには、CREATE ANY JOB権限が必要です。

例29-3 データベース宛先の作成

次の例では、DBHOST1_ORCLDWという名前のデータベース宛先を作成しています。この例では、次のことを想定しています。

- リモート・ホストdbhost1.example.comにスケジューラ・エージェントをインストールし、そのエージェントをローカル・データベースに登録していること。

- エージェント構成ファイル内のエージェント名の設定を変更していないこと。つまり、エージェント名および外部宛先の名前がデフォルトのDBHOST1に設定されていること。

- ローカル・ホスト上のNet Configuration Assistantを使用して、リモート・ホストdbhost1.example.comに存在するorcldwという名前のOracle Databaseインスタンスに対してtnsnames.ora内に接続記述子を作成していること。また、ORCLDWのネット・サービス名(別名)をこの接続記述子に割り当てていること。

BEGIN
DBMS_SCHEDULER.CREATE_DATABASE_DESTINATION (
destination_name     => 'DBHOST1_ORCLDW',
agent                => 'DBHOST1',
tns_name             => 'ORCLDW',
comments             => 'Instance named orcldw on host dbhost1.example.com');
END;
/

データベース宛先が作成されたかどうかを確認するには、*_SCHEDULER_DB_DESTSビューを問い合せます。

関連項目:

- 宛先の詳細は、「宛先」を参照してください。

- リモート外部ジョブとリモート・データベース・ジョブの詳細は、「ジョブ」を参照してください。

複数の宛先のジョブに対する宛先グループの作成

複数の宛先で実行するジョブを作成するには、宛先グループを作成して、そのグループをジョブのdestination_name属性に割り当てる必要があります。グループの作成時にグループ・メンバー(宛先)を指定することも、後でグループ・メンバーを追加することもできます。

宛先グループを作成する手順は、次のとおりです。

- DBMS_SCHEDULER.CREATE_GROUPプロシージャをコールします。

リモート外部ジョブの場合、EXTERNAL_DESTタイプのグループを指定し、すべてのグループ・メンバーを外部宛先にする必要があります。リモート・データベース・ジョブの場合、DB_DESTタイプのグループを指定し、すべてのメンバーをデータベース宛先にする必要があります。

宛先グループのメンバーは、次の形式で指定する必要があります。

[[schema.]credential@][schema.]destination

説明:

- credentialは、既存の資格証明の名前です。

- destinationは、既存のデータベース宛先または外部宛先の名前です。

接続先メンバーの資格証明部分はオプションです。省略すると、この接続先メンバーを使用するジョブはデフォルトの資格証明を使用します。

同じタイプの別のグループを宛先グループのメンバーとして含めることができます。グループの作成時に別のグループを含めた場合、その中に含まれるメンバーはスケジューラによって自動的に展開されます。

ジョブを実行する多数の宛先の1つとしてローカル・ホストを使用する場合、どちらのタイプの宛先グループのグループ・メンバーとしてもLOCALキーワードを指定できます。外部宛先グループの場合にかぎり、LOCALの前に資格証明の接頭辞を付けることができます。

グループの所有者は、そのグループを作成したユーザーです。自分のスキーマにグループを作成するにはCREATE JOBシステム権限が必要になり、別のスキーマにグループを作成するにはCREATE ANY JOBシステム権限が必要になります。SELECTをグループに付与することによって、グループのオブジェクト権限を他のユーザーに付与できます。

例29-4 データベース宛先グループの作成

次の例では、データベース宛先グループを作成しています。一部のメンバーには資格証明がないため、この宛先グループを使用するジョブではデフォルトの資格証明を使用する必要があります。

BEGIN
DBMS_SCHEDULER.CREATE_GROUP(
GROUP_NAME    => 'all_dbs',
GROUP_TYPE    => 'DB_DEST',
MEMBER        => 'oltp_admin@orcl, orcldw1, LOCAL',
COMMENTS      => 'All databases managed by me');
END;
/

次のコードでは、グループに別のメンバーを追加しています。

BEGIN
DBMS_SCHEDULER.ADD_GROUP_MEMBER(
GROUP_NAME    => 'all_dbs',
MEMBER        => 'dw_admin@orcldw2');
END;
/

関連項目:
グループの概要については、「グループ」を参照してください。

例: リモート・データベース・ジョブの作成

次の例では、ジョブのdestination_nameオブジェクトにデータベース宛先オブジェクトを指定することで、リモート・データベース・ジョブを作成しています。リモート・データベースでジョブを認証できるように、資格証明も指定する必要があります。この例では、例29-2で作成した資格証明および例29-3で作成したデータベース宛先を使用しています。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name            =>  'SALES_SUMMARY1',
job_type            =>  'STORED_PROCEDURE',
job_action          =>  'SALES.SALES_REPORT1',
start_date          =>  '15-JUL-09 11.00.00 PM Europe/Warsaw',
repeat_interval     =>  'FREQ=DAILY',
credential_name     =>  'DW_CREDENTIAL',
destination_name    =>  'DBHOST1_ORCLDW');
END;
/

複数の宛先のジョブの作成

複数の宛先で実行し、1箇所で管理するジョブを作成できます。このようにする代表的な理由としては、管理対象のすべてのデータベースでデータベース・メンテナンス・ジョブを実行することがあげられます。各データベースでジョブを作成するのではなく、ジョブを1つ作成し、そのジョブに対して複数の宛先を指定します。ジョブを作成したデータベース(local database)から、すべての場所のジョブのすべてのインスタンスの状態と結果を監視できます。

複数の宛先のジョブを作成する手順は、次のとおりです。

- DBMS_SCHEDULER.CREATE_JOBプロシージャをコールして、ジョブのdestination_name属性にデータベース宛先グループまたは外部宛先グループの名前を設定します。
一部の宛先グループ・メンバーに資格証明の接頭辞(スキーマ)が付いていない場合、ジョブにデフォルトの資格証明を割り当てます。

ジョブを実行する宛先の1つとしてローカル・ホストまたはローカル・データベースを使用するには、LOCALキーワードを宛先グループのメンバーの1つにする必要があります。

宛先グループのリストを取得するには、次の問合せを発行します。

SELECT owner, group_name, group_type, number_of_members FROM all_scheduler_groups
WHERE group_type = 'DB_DEST' or group_type = 'EXTERNAL_DEST';

OWNER           GROUP_NAME      GROUP_TYPE    NUMBER_OF_MEMBERS
--------------- --------------- ------------- -----------------
DBA1            ALL_DBS         DB_DEST                       4
DBA1            ALL_HOSTS       EXTERNAL_DEST                 4

次の例では、例29-4で作成したデータベース宛先グループを使用して、複数の宛先のデータベース・ジョブを作成しています。このジョブはシステム管理ジョブであるため、システム管理者権限を含む資格証明が使用されます。

BEGIN
DBMS_SCHEDULER.CREATE_CREDENTIAL('DBA_CREDENTIAL', 'dba1', 'sYs040533');
DBMS_SCHEDULER.CREATE_JOB (
job_name            =>  'MAINT_SET1',
job_type            =>  'STORED_PROCEDURE',
job_action          =>  'MAINT_PROC1',
start_date          =>  '15-JUL-09 11.00.00 PM Europe/Warsaw',
repeat_interval     =>  'FREQ=DAILY',
credential_name     =>  'DBA_CREDENTIAL',
destination_name    =>  'ALL_DBS');
END;
/

関連項目:

- 「複数の宛先のジョブ」

- 「複数の宛先のジョブの監視」

- 「グループ」

ジョブ引数の設定

ジョブの作成後、次の場合にジョブ引数の設定が必要な場合があります。

- インラインのジョブ処理が、引数を必要とするストアド・プロシージャまたはその他の実行可能ファイルの場合

- ジョブが名前付きプログラム・オブジェクトを参照していて、そのデフォルト・プログラム引数の1つ以上を上書きする場合

- ジョブが名前付きプログラム・オブジェクトを参照していて、そのプログラム引数の1つ以上にデフォルト値が割り当てられていない場合

ジョブ引数を設定するには、SET_JOB_ARGUMENT_VALUEまたはSET_JOB_ANYDATA_VALUEプロシージャ、あるいはEnterprise Managerを使用します。SET_JOB_ANYDATA_VALUEは、VARCHAR2文字列として表現できない複雑なデータ型に使用されます。

引数を必要とする場合があるジョブの例の1つに、開始日と終了日が必要なレポート作成プログラムを開始するジョブがあります。次のコード例では、レポート作成プログラムの2番目の引数である終了日のジョブ引数が設定されます。

BEGIN
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE (
job_name                => 'ops_reports',
argument_position       => 2,
argument_value          => '12-DEC-03');
END;
/

値がすでに設定されている引数についてこのプロシージャを使用すると、その引数は上書きされます。引数値を設定するには、引数名または引数の位置を使用します。引数名を使用するには、ジョブが名前付きプログラム・オブジェクトを参照し、そのプログラム・オブジェクト内で引数に名前が割り当てられている必要があります。プログラムがインラインで記述されている場合にサポートされるのは、位置による設定のみです。引数は、タイプがPLSQL_BLOCKのジョブに対してはサポートされません。

設定されている値を削除するには、RESET_JOB_ARGUMENTプロシージャを使用します。このプロシージャは、通常の引数およびANYDATA引数の両方に使用できます。

SET_JOB_ARGUMENT_VALUEでは、SQLタイプの引数のみがサポートされます。したがって、SQLタイプではない引数の値(ブール値など)は、プログラムまたはジョブ引数としてサポートされません。

関連項目:
「プログラム引数の定義」

ジョブ属性の追加設定

ジョブの作成後に、SET_ATTRIBUTEまたはSET_JOB_ATTRIBUTESプロシージャを使用して、追加のジョブ属性を設定したり、属性値を変更できます。また、Enterprise Managerを使用してジョブ属性を設定することもできます。ジョブ属性の多くはCREATE_JOBのコールを使用して設定できますが、destinationやcredential_nameなどの一部の属性は、ジョブの作成後にSET_ATTRIBUTEまたはSET_JOB_ATTRIBUTESを使用することによってのみ設定できます。

デタッチ済ジョブの作成

デタッチ済ジョブでは、detached属性がTRUEに設定されているプログラム・オブジェクト(プログラム)を指し示す必要があります。

例29-5 コールド・バックアップを実行するデタッチ済ジョブの作成

LinuxとUNIXに関する次の例では、データベースのコールド・バックアップを実行する夜間ジョブを作成しています。これには、3つのステップが含まれています。

ステップ1: RMAN起動スクリプトの作成

コールド・バックアップを実行するRMANスクリプトを呼び出すシェル・スクリプトを作成します。このシェル・スクリプトは$ORACLE_HOME/scripts/coldbackup.shに置かれます。これは、Oracle Databaseをインストールしたユーザー(通常はユーザーoracle)が実行できる必要があります。

#!/bin/sh

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1
export ORACLE_SID=orcl
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib

$ORACLE_HOME/bin/rman TARGET / @$ORACLE_HOME/scripts/coldbackup.rman
trace /u01/app/oracle/backup/coldbackup.out &
exit 0

ステップ2: RMANスクリプトの作成

コールド・バックアップを実行してからジョブを終了する、RMANスクリプトを作成します。このスクリプトは$ORACLE_HOME/scripts/coldbackup.rmanに置かれます。

run {
# Shut down database for backups and put into MOUNT mode
shutdown immediate
startup mount

# Perform full database backup
backup full format "/u01/app/oracle/backup/%d_FULL_%U" (database) ;

# Open database after backup
alter database open;

# Call notification routine to indicate job completed successfully
sql " BEGIN  DBMS_SCHEDULER.END_DETACHED_JOB_RUN(''sys.backup_job'', 0,
null); END; ";
}

ステップ3: ジョブの作成とデタッチ済プログラムの使用

次のPL/SQLブロックを発行します。

BEGIN
DBMS_SCHEDULER.CREATE_PROGRAM(
program_name   => 'sys.backup_program',
program_type   => 'executable',
program_action => '?/scripts/coldbackup.sh',
enabled        =>  TRUE);

DBMS_SCHEDULER.SET_ATTRIBUTE('sys.backup_program', 'detached', TRUE);

DBMS_SCHEDULER.CREATE_JOB(
job_name        => 'sys.backup_job',
program_name    => 'sys.backup_program',
repeat_interval => 'FREQ=DAILY;BYHOUR=1;BYMINUTE=0');

DBMS_SCHEDULER.ENABLE('sys.backup_job');
END;
/

関連項目:
「デタッチ済ジョブ」

単一トランザクションでの複数ジョブの作成

多数のジョブを作成する必要がある場合は、CREATE_JOBSプロシージャを使用すると、トランザクションのオーバーヘッドを減らしてパフォーマンスを改善できる可能性があります。例29-6に、このプロシージャを使用して単一トランザクションで複数のジョブを作成する方法を示します。

例29-6 単一トランザクションでの複数ジョブの作成

DECLARE
newjob sys.job_definition;
newjobarr sys.job_definition_array;
BEGIN
-- Create an array of JOB_DEFINITION object types
newjobarr := sys.job_definition_array();

-- Allocate sufficient space in the array
newjobarr.extend(5);

-- Add definitions for 5 jobs
FOR i IN 1..5 LOOP
-- Create a JOB_DEFINITION object type
newjob := sys.job_definition(job_name => 'TESTJOB' || to_char(i),
job_style => 'REGULAR',
program_name => 'PROG1',
repeat_interval => 'FREQ=HOURLY',
start_date => systimestamp + interval '600' second,
max_runs => 2,
auto_drop => FALSE,
enabled => TRUE
);

-- Add it to the array
newjobarr(i) := newjob;
END LOOP;

-- Call CREATE_JOBS to create jobs in one transaction
DBMS_SCHEDULER.CREATE_JOBS(newjobarr, 'TRANSACTIONAL');
END;
/

PL/SQL procedure successfully completed.

SELECT JOB_NAME FROM USER_SCHEDULER_JOBS;

JOB_NAME
------------------------------
TESTJOB1
TESTJOB2
TESTJOB3
TESTJOB4
TESTJOB5

5 rows selected.

関連項目:
「軽量ジョブ」

外部ジョブの手法

この項では、次の例を通して、外部ジョブに関するいくつかの実践的手法を示します。

- DOSコマンドを実行するローカル外部ジョブの作成

- ローカル外部ジョブの作成とstdoutの取得

例29-7 DOSコマンドを実行するローカル外部ジョブの作成

次の例に、Windows上でDOS組込みコマンド(この例ではmkdir)を実行するローカル外部ジョブの作成方法を示します。このジョブでは、/cオプションを指定してcmd.exeが実行されます。

BEGIN
DBMS_SCHEDULER.CREATE_JOB(
job_name             => 'MKDIR_JOB',
job_type             => 'EXECUTABLE',
number_of_arguments  => 3,
job_action           => '\windows\system32\cmd.exe',
auto_drop            => FALSE,
credential_name      => 'TESTCRED');

DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('mkdir_job',1,'/c');
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('mkdir_job',2,'mkdir');
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('mkdir_job',3,'\temp\extjob_test_dir');
DBMS_SCHEDULER.ENABLE('MKDIR_JOB');
END;
/

例29-8 ローカル外部ジョブの作成とstdoutの取得

LinuxおよびUNIX用のこの例では、ローカル外部ジョブを作成および実行してから、GET_FILEプロシージャを使用してジョブのstdout出力を取得する方法を示します。ローカル外部ジョブの場合、ORACLE_HOME/scheduler/logにあるログ・ファイルにstdout出力が保存されます。このパスをGET_FILEに指定する必要はなく、ログ・ビューでジョブの外部ログIDを問い合せて、最後に「_stdout」を追加したファイル名のみを指定します。

-- User scott must have CREATE JOB and CREATE EXTERNAL JOB privileges
grant create job, create external job to scott ;

connect scott/password
set serveroutput on

-- Create a credential for the job to use
exec dbms_scheduler.create_credential('my_cred','host_username','host_passwd')

-- Create a job that lists a directory. After running, the job is dropped.
begin
DBMS_SCHEDULER.CREATE_JOB(
job_name            => 'lsdir',
job_type            => 'EXECUTABLE',
job_action          => '/bin/ls',
number_of_arguments => 1,
enabled             => false,
auto_drop           => true,
credential_name     => 'my_cred');
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('lsdir',1,'/tmp');
DBMS_SCHEDULER.ENABLE('lsdir');
end;
/

-- Wait a bit for the job to run, and then check the job results.
select job_name, status, error#, actual_start_date, additional_info
from user_scheduler_job_run_details where job_name='LSDIR';

-- Now use the external log id from the additional_info column to
-- formulate the log file name and retrieve the output
declare
my_blob blob;
log_id varchar2(50);
begin
select regexp_substr(additional_info,'job[_0-9]*') into log_id
from user_scheduler_job_run_details where job_name='LSDIR';
dbms_lob.createtemporary(my_blob, false);
dbms_scheduler.get_file(
source_file     => log_id ||'_stdout',
credential_name => 'my_cred',
file_contents   => my_blob,
source_host     => null);
dbms_output.put_line(my_blob);
end;
/

注意:
リモート外部ジョブの場合、メソッドは同じですが次の違いがあります。

- ジョブのdestination_name属性を設定します。

- GET_FILEプロシージャにソース・ホストを指定します。

GET_FILEでは、ローカル外部ジョブとリモート外部ジョブの両方について、正しいホスト位置でログ・ファイルが自動的に検索されます。

関連項目:

- 外部認証の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- 「外部ジョブ」

- 「外部ジョブのstdoutとstderrの表示」

- 「外部ジョブの停止」

- 「リモート・ジョブのトラブルシューティング」

ジョブの変更

ジョブを変更するには、その属性を変更します。そのためには、SET_ATTRIBUTE、SET_ATTRIBUTE_NULLまたはSET_JOB_ATTRIBUTESパッケージ・プロシージャ、あるいはEnterprise Managerを使用します。ジョブ属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のCREATE_JOBプロシージャに関する項を参照してください。

すべてのジョブは変更可能で、ジョブ名以外のすべてのジョブ属性を変更できます。変更する際に実行中のジョブ・インスタンスがある場合、そのインスタンスはこのコールによる影響を受けません。このプロシージャによる変更は、今後実行されるジョブに対してのみ反映されます。

通常、データベースによって自動的に作成されたジョブは変更しないでください。データベースによって作成されたジョブには、ジョブのビューでTRUEに設定された列SYSTEMがあります。ジョブの属性は、*_SCHEDULER_JOBSビューで使用可能です。

実行中のジョブのジョブ属性も変更できます。ただし、その変更は、スケジュールされている次回のジョブ実行時まで反映されません。

SET_ATTRIBUTE、SET_ATTRIBUTE_NULLおよびSET_JOB_ATTRIBUTESプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

次の例では、ジョブupdate_salesのrepeat_intervalを毎週水曜日の1回に変更しています。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE (
name         =>  'update_sales',
attribute    =>  'repeat_interval',
value        =>  'freq=weekly; byday=wed');
END;
/

ジョブの実行

ジョブを実行するには、次の3つの方法があります。

- ジョブ・スケジュールに従って実行する方法: この場合、ジョブが有効であれば、スケジューラ・ジョブ・コーディネータによって自動的にジョブが取り出され、ジョブ・スレーブの制御下で実行されます。ジョブは、ジョブ所有者のユーザーとして、または資格証明のあるローカル外部ジョブの場合は、資格証明で指定したユーザーとして実行されます。ジョブが成功したかどうかを確認するには、ジョブ・ビュー(*_SCHEDULER_JOBS)またはジョブ・ログ(*_SCHEDULER_JOB_LOGおよび*_SCHEDULER_JOB_RUN_DETAILS)で問い合せる必要があります。ジョブ・スレーブおよびスケジューラ・アーキテクチャの詳細は、「ジョブの実行方法」を参照してください。

- イベントの発生時に実行する方法: イベント・キューで特定のイベントが受信されるか、File Watcherでファイル到着イベントが呼び出されると、使用可能になっているイベントベースのジョブが開始されます ( 「イベントを使用したジョブの開始」 を参照)。(「イベントを使用したジョブの開始」を参照してください。)または、資格証明を使用するローカル外部ジョブの場合は、資格証明内に指定されているユーザーとして実行されます。ジョブが成功したかどうかを確認するには、ジョブ・ビューまたはジョブ・ログを問い合せる必要があります。

- DBMS_SCHEDULER.RUN_JOBを呼び出して実行する方法: RUN_JOBプロシージャを使用して、ジョブをテストしたり、指定したスケジュール以外で実行できます。ジョブは非同期に実行できますが、これは前の2つのジョブ実行方法、つまり同期して実行する方法に類似しており、この方法ではRUN_JOBを呼び出したセッションにユーザーがログインするとジョブが実行されます。RUN_JOBのuse_current_session引数によって、ジョブが同期または非同期のどちらで実行されるかが決まります。
RUN_JOBでは、ジョブ名のカンマ区切りのリストを使用できます。

次の例では、2つのジョブを非同期で実行しています。

BEGIN
DBMS_SCHEDULER.RUN_JOB(
JOB_NAME            => 'DSS.ETLJOB1, DSS.ETLJOB2',
USE_CURRENT_SESSION => FALSE);
END;
/

注意:
スケジュールに従ってジョブを実行する場合は、RUN_JOBをコールする必要はありません。ジョブが使用可能であれば、スケジューラによって自動的に実行されます。

ジョブの停止

STOP_JOBプロシージャまたはEnterprise Managerを使用して、1つ以上の実行中のジョブを停止できます。STOP_JOBでは、ジョブ、ジョブ・クラスおよびジョブ宛先IDのカンマ区切リストを使用できます。ジョブ宛先IDは、スケジューラによって割り当てられる番号で、ジョブ、資格証明および宛先の一意の組合せを表します。これは、複数宛先のジョブの特定の子ジョブを識別して、その子のみを停止するのに便利な方法です。子ジョブのジョブ宛先IDは*_SCHEDULER_JOB_DESTSのビューから取得します。

ジョブ・クラスが指定されている場合、そのジョブ・クラス内の実行中のジョブはすべて停止されます。たとえば、次の文では、ジョブjob1、ジョブ・クラスdw_jobs内のすべてのジョブ、および複数の宛先のジョブに含まれる2つの子ジョブが停止されます。

BEGIN
DBMS_SCHEDULER.STOP_JOB('job1, sys.dw_jobs, 984, 1223');
END;
/

指定したジョブのインスタンスはすべて停止されます。ジョブの停止後、1回かぎりのジョブの状態はSTOPPEDに設定され、繰返しジョブの状態は、(次回のジョブ実行がスケジュールされているため)SCHEDULEDに設定されます。また、ジョブ・ログには、OPERATIONがSTOPPEDに設定され、ADDITIONAL_INFOがREASON="Stop job called by user: username"に設定されたエントリが作成されます。

デフォルトでは、スケジューラは割込みメカニズムを使用してジョブを正常に停止しようとします。この方法では、制御がスレーブ・プロセスに戻され、スレーブ・プロセスはジョブ実行の統計を収集できます。forceオプションがTRUEに設定されている場合、ジョブは即時に停止するため、そのジョブ実行について特定の実行時間の統計が使用できない場合があります。

チェーンを実行中のジョブを停止すると、実行中のすべてのステップが(各ステップでforceオプションをTRUEに設定してSTOP_JOBをコールすることによって)自動的に停止されます。

STOP_JOBのcommit_semantics引数を使用すると、複数のジョブが指定されている場合の結果および1つ以上のジョブを停止しようとしたときに発生するエラーを制御できます。この引数をABSORB_ERRORSに設定すると、エラーが発生した後もプロシージャを続行して、残りのジョブの停止試行を実行できる場合があります。エラーが発生したことがプロシージャによって示された場合は、エラーの内容を判断するために、ビューSCHEDULER_BATCH_ERRORSを問い合せることができます。コミット・セマンティクスの詳細は、「ジョブの削除」を参照してください。

STOP_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

注意:
ジョブが停止したときにロールバックされるのは、現行トランザクションのみです。これは、データの一貫性を損なう原因となる場合があります。

外部ジョブの停止

スケジューラを使用している場合、外部ジョブの実装者は、forceがFALSEに設定されたSTOP_JOBがコールされた場合に、その外部ジョブを正常にクリーン・アップするメカニズムを利用できます。次の説明は、すべてのプラットフォーム上で資格証明を使用せずに作成されたローカル外部ジョブと、UNIXおよびLinuxプラットフォーム上のリモート外部ジョブにのみ該当します。

UNIXおよびLinuxでは、スケジューラによって起動されたプロセスにSIGTERMシグナルが送信されます。外部ジョブの実装者は、割込みハンドラにSIGTERMをトラップし、ジョブの実装内容をすべてクリーン・アップして終了する必要があります。Windowsでは、forceがFALSEに設定されたSTOP_JOBは、Windows XP、Windows 2003およびそれ以降のオペレーティング・システムでのみサポートされます。これらのプラットフォームでは、スケジューラによって起動されるプロセスがコンソール・プロセスです。このプロセスを停止するために、スケジューラはCTRL_BREAKをプロセスに送信します。CTRL_BREAKは、SetConsoleCtrlHandler()ルーチンにハンドラを登録することによって処理できます。

チェーン・ジョブの停止

チェーンを指し示すジョブが停止すると、実行中のチェーンのステップがすべて停止します。

個々のチェーン・ステップの停止の詳細は、「個々のチェーン・ステップの停止」を参照してください。

ジョブの削除

1つ以上のジョブを削除するには、DROP_JOBプロシージャまたはEnterprise Managerを使用します。DROP_JOBでは、ジョブおよびジョブ・クラスのカンマ区切りリストを使用できます。ジョブ・クラスを指定すると、そのジョブ・クラスのすべてのジョブは削除されますが、ジョブ・クラス自体は削除されません。(ジョブ・クラスを削除するには、DROP_JOB_CLASSを使用します。ジョブ・クラスの削除方法の詳細は、「ジョブ・クラスの削除」を参照してください。)DROP_JOBでジョブ宛先IDを使用して複数宛先ジョブの子ジョブを削除することはできません。

次の文では、ジョブjob1とjob3、およびジョブ・クラスjobclass1とjobclass2内のすべてのジョブが削除されます。

BEGIN
DBMS_SCHEDULER.DROP_JOB ('job1, job3, sys.jobclass1, sys.jobclass2');
END;
/

プロシージャ・コール時にジョブが実行中の場合、ジョブの削除試行は失敗します。このデフォルトの動作は、forceまたはdeferオプションを設定することによって変更できます。

forceオプションをTRUEに設定すると、最初に、実行中のジョブの停止試行がスケジューラの割込みメカニズム(forceオプションをFALSEに設定してSTOP_JOBをコール)によって行われます。ジョブが正常に停止されると、次にそのジョブが削除されます。または、STOP_JOBをコールして最初にジョブを停止してから、DROP_JOBをコールすることもできます。STOP_JOBが失敗した場合は、forceオプションを設定してSTOP_JOBをコールできます(この場合、MANAGE SCHEDULER権限が必要です)。その後、そのジョブを削除できます。デフォルトでは、STOP_JOBおよびDROP_JOBプロシージャの両方で、forceはFALSEに設定されています。

deferオプションをTRUEに設定すると、実行中のジョブは完了してから削除されます。forceとdeferオプションは相互に排他的で、両方を設定するとエラーになります。

複数のジョブを削除するように指定する場合は、commit_semantics引数を使用して、いずれかのジョブでエラーが発生した場合の結果を決定します。この引数には、次の値を指定できます。

- STOP_ON_FIRST_ERROR(デフォルト): 最初のエラーでコールが戻り、エラー発生前に正常終了した削除操作がディスクにコミットされます。

- TRANSACTIONAL: 最初のエラーでコールが戻り、エラー発生前の削除操作がロールバックされます。forceがFALSEに設定されている必要があります。

- ABSORB_ERRORS: エラーへの対応が取り組まれ、残りのジョブの削除が試行されて、正常終了したすべての削除操作がコミットされます。

commit_semanticsを設定できるのは、job_nameリストにジョブ・クラスが含まれていない場合のみです。ジョブ・クラスを指定している場合は、デフォルトのコミット・セマンティクス(STOP_ON_FIRST_ERROR)が適用されます。

次の例では、deferオプションとTRANSACTIONALコミット・セマンティクスを使用して、ジョブmyjob1およびmyjob2を削除しています。

BEGIN
DBMS_SCHEDULER.DROP_JOB(
job_name         => 'myjob1, myjob2',
defer            => TRUE,
commit_semantics => 'TRANSACTIONAL');
END;
/

次の例では、ABSORB_ERRORSコミット・セマンティクスを示しています。プロシージャのコール時にmyjob1が実行されており、myjob2は実行されていないことを想定しています。

BEGIN
DBMS_SCHEDULER.DROP_JOB(
job_name         => 'myjob1, myjob2',
commit_semantics => 'ABSORB_ERRORS');
END;
/
Error report:
ORA-27362: batch API call completed with errors

SCHEDULER_BATCH_ERRORSビューを問い合せて、エラーの内容を判断できます。

SELECT object_name, error_code, error_message FROM scheduler_batch_errors;

OBJECT_NAME    ERROR CODE ERROR_MESSAGE
-------------- ---------- ---------------------------------------------------
STEVE.MYJOB1        27478 "ORA-27478: job "STEVE.MYJOB1" is running

USER_SCHEDULER_JOBSを確認すると、myjob2は正常に削除され、myjob1は残っていることがわかります。

DROP_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ジョブの無効化

1つ以上のジョブを無効(使用禁止)にするには、DISABLEプロシージャまたはEnterprise Managerを使用します。ジョブは他の理由で使用禁止になる場合もあります。たとえば、ジョブが属しているジョブ・クラスが削除されると、ジョブは使用禁止になります。また、ジョブが指し示しているプログラムまたはスケジュールのいずれかが削除された場合も使用禁止になります。ジョブが指し示しているプログラムまたはスケジュールが使用禁止の場合は、そのジョブ自体は使用禁止にならないため、スケジューラがジョブを実行しようとしたときに、エラーとなることに注意してください。

ジョブを使用禁止にするとは、ジョブのメタデータが存在してもジョブを実行できず、ジョブ・コーディネータがこれらのジョブを処理対象として取得しないことを意味します。ジョブが使用禁止になると、ジョブ表内のそのstateはdisabledに変更されます。

forceオプションをFALSEに設定してジョブを使用禁止にすると、ジョブが現在実行中の場合はエラーが返されます。forceがTRUEに設定されているときは、ジョブは使用禁止になりますが、現在実行中のインスタンスは完了できます。

commit_semanticsがSTOP_ON_FIRST_ERRORに設定されている場合は、最初のエラーでコールが戻り、エラー発生前に正常終了した使用禁止操作がディスクにコミットされます。commit_semanticsがTRANSACTIONALに、forceがFALSEに設定されている場合は、最初のエラーでコールが戻り、エラー発生前の使用禁止操作がロールバックされます。commit_semanticsがABSORB_ERRORSに設定されている場合は、エラーへの対応が取り組まれ、残りのジョブの使用禁止が試行されて、正常に終了したすべての使用禁止操作がコミットされます。エラーが発生したことがプロシージャによって示された場合は、エラーの内容を判断するために、ビューSCHEDULER_BATCH_ERRORSを問い合せることができます。

デフォルトでは、commit_semanticsはSTOP_ON_FIRST_ERRORに設定されています。

DISABLEプロシージャ・コールにジョブ名またはジョブ・クラス名のカンマ区切りのリストを指定することで、1回のコールで複数のジョブを使用禁止にすることもできます。たとえば、次の文では、ジョブとジョブ・クラスを組み合せて指定しています。

BEGIN
DBMS_SCHEDULER.DISABLE('job1, job2, job3, sys.jobclass1, sys.jobclass2');
END;
/

DISABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ジョブの有効化

1つ以上のジョブを有効(使用可能)にするには、ENABLEプロシージャまたはEnterprise Managerを使用します。このプロシージャを使用すると、ジョブは、ジョブ・コーディネータによって取り出され、処理されるようになります。ジョブは、デフォルトで使用禁止で作成されるため、実行するには使用可能にする必要があります。ジョブを使用可能にすると、妥当性チェックが実行されます。チェックに失敗すると、ジョブは使用可能になりません。

使用禁止のジョブを使用可能にすると、ジョブはスケジュールに従って実行を即時開始します。また、使用禁止のジョブを使用可能にすると、ジョブのRUN_COUNT、FAILURE_COUNTおよびRETRY_COUNT属性が再設定されます。

commit_semanticsがSTOP_ON_FIRST_ERRORに設定されている場合は、最初のエラーでコールが戻り、エラー発生前に正常終了した使用可能にする操作がディスクにコミットされます。commit_semanticsがTRANSACTIONALに設定されている場合は、最初のエラーでコールが戻り、エラー発生前の使用可能にする操作がロールバックされます。commit_semanticsがABSORB_ERRORSに設定されている場合は、エラーへの対応が取り組まれ、残りのジョブを使用可能にする操作が試行されて、正常に終了した使用可能にする操作がすべてコミットされます。エラーが発生したことがプロシージャによって示された場合は、エラーの内容を判断するために、ビューSCHEDULER_BATCH_ERRORSを問い合せることができます。

デフォルトでは、commit_semanticsはSTOP_ON_FIRST_ERRORに設定されています。

ENABLEプロシージャ・コールにジョブ名またはジョブ・クラス名のカンマ区切りのリストを指定することで、1回のコールで複数のジョブを使用可能にすることもできます。たとえば、次の文では、ジョブとジョブ・クラスを組み合せて指定しています。

BEGIN
DBMS_SCHEDULER.ENABLE ('job1, job2, job3,
sys.jobclass1, sys.jobclass2, sys.jobclass3');
END;
/

ENABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ジョブのコピー

ジョブをコピーするには、COPY_JOBプロシージャまたはEnterprise Managerを使用します。このコールによって、旧ジョブのすべての属性(ジョブ名以外)が新規ジョブにコピーされます。新規ジョブは使用禁止の状態で作成されます。

COPY_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

外部ジョブのstdoutとstderrの表示

資格証明が割り当てられている外部ジョブでは、stdoutとstderrがログ・ファイルに書き込まれます。ローカル外部ジョブでは、ディレクトリORACLE_HOME/scheduler/log内のログ・ファイルに書き込まれます。リモート外部ジョブでは、ディレクトリAGENT_HOME/data/log内のログ・ファイルに書き込まれます。これらのファイルの内容は、DBMS_SCHEDULER.GET_FILEで取得できます。ファイル名は、ジョブ・ログIDとそれに続く文字列_stdoutまたは_stderrで構成されています。ジョブのジョブ・ログIDを取得するには、*_SCHEDULER_JOB_RUN_DETAILSビューのADDITIONAL_INFO列を問い合せて、次のような名前/値ペアを解析します。

EXTERNAL_LOG_ID="job_71035_3158"

たとえば、ファイル名はjob_71035_3158_stdoutのようになります。例29-8「ローカル外部ジョブの作成とstdoutの取得」には、stdoutの出力の取得方法が示されています。この例はローカル外部ジョブに関するものですが、メソッドはリモート外部ジョブの場合も同じです。

また、ローカル外部ジョブまたはリモート外部ジョブによってstderrに出力が書き込まれる際は、最初の200バイトが*_SCHEDULER_JOB_RUN_DETAILSビューのADDITIONAL_INFO列に記録されます。この情報は、次のような名前/値ペアの形式で記録されます。

STANDARD_ERROR="text"

注意:
ADDITIONAL_INFO列には、複数の名前と値のペアを指定できます。順不同のため、STANDARD_ERRORの名前と値のペアを検索するには、フィールドを解析する必要があります。

関連項目:
DBMS_SCHEDULER.GET_FILEの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

ジョブを定義するためのプログラムの作成および管理

プログラムは、特定のタスクに関するメタデータの集まりです。必要に応じて、プログラムを使用してジョブの定義を支援できます。この項では、基本的なプログラム・タスクについて説明します。この項の内容は、次のとおりです。

- プログラムのタスクとそのプロシージャ

- プログラムの作成

- プログラムの変更

- プログラムの削除

- プログラムの無効化

- プログラムの有効化

関連項目:
プログラムの概要については、「プログラム」を参照してください。

プログラムのタスクとそのプロシージャ

表29-3に、プログラムの一般的なタスクとそれに対応するプロシージャおよび権限を示します。

表29-3 プログラムのタスクとそのプロシージャ

タスク

プロシージャ

必要な権限

プログラムの作成

CREATE_PROGRAM

CREATE JOBまたはCREATE ANY JOB

プログラムの変更

SET_ATTRIBUTE

ALTERまたはCREATE ANY JOB、あるいは所有者

プログラムの削除

DROP_PROGRAM

ALTERまたはCREATE ANY JOB、あるいは所有者

プログラムの使用禁止

DISABLE

ALTERまたはCREATE ANY JOB、あるいは所有者

プログラムの使用可能化

ENABLE

ALTERまたはCREATE ANY JOB、あるいは所有者

権限の詳細は、「スケジューラ権限」を参照してください。

プログラムの作成

プログラムを作成するには、CREATE_PROGRAMプロシージャまたはEnterprise Managerを使用します。デフォルトでは、プログラムは作成者のスキーマに作成されます。別のユーザーのスキーマにプログラムを作成するには、スキーマ名でプログラム名を修飾する必要があります。他のユーザーがこのプログラムを使用するには、プログラムに対するEXECUTE権限が必要です。このため、プログラムを作成したら、EXECUTE権限を付与する必要があります。my_program1というプログラムの作成例を次に示します。

BEGIN
DBMS_SCHEDULER.CREATE_PROGRAM (
program_name           => 'my_program1',
program_action         => '/usr/local/bin/date',
program_type           => 'EXECUTABLE',
comments               => 'My comments here');
END;
/

プログラムは、デフォルトで使用禁止状態で作成されるため、そのプログラムを指し示すジョブを使用可能にするには、プログラムを使用可能にする必要があります。

「プログラム引数の定義」に説明されているDEFINE_XXX_ARGUMENTプロシージャを使用してプログラムのすべての引数を指定する前に、引数が必要なプログラムを使用可能にしないでください。

プログラム引数の定義

プログラムを作成した後、プログラムの引数を定義できます。引数は、コーリング順序内の位置によって定義され、オプションで引数名とデフォルト値を指定できます。プログラム引数のデフォルト値が定義されていない場合は、そのプログラムを参照するジョブで引数の値を指定する必要があります。(ジョブで、デフォルト値を上書きすることもできます。)すべての引数値を指定しないと、ジョブを有効にできません。

プログラム引数値を設定するには、DEFINE_PROGRAM_ARGUMENTまたはDEFINE_ANYDATA_ARGUMENTプロシージャを使用します。DEFINE_ANYDATA_ARGUMENTは、ANYDATAオブジェクト内にカプセル化する必要がある複雑な型に使用されます。引数を必要とする場合があるプログラムの例の1つに、開始日と終了日が必要なレポート作成プログラムを開始するジョブがあります。次のコード例では、レポート作成プログラムの2番目の引数である終了日の引数が設定されます。この例では、SET_JOB_ANYDATA_VALUEやSET_JOB_ARGUMENT_VALUEなどの他のパッケージ・プロシージャから(位置ではなく)名前で引数を参照できるように、引数に名前が割り当てられています。

BEGIN
DBMS_SCHEDULER.DEFINE_PROGRAM_ARGUMENT (
program_name            => 'operations_reporting',
argument_position       => 2,
argument_name           => 'end_date',
argument_type           => 'VARCHAR2',
default_value           => '12-DEC-03');
END;
/

argument_type引数の有効な値はSQLデータ型のみであるため、ブールはサポートされていません。外部実行可能ファイルの場合、CHARやVARCHAR2などの文字列型のみを使用できます。

プログラム引数は、名前または位置で削除できます。次に例を示します。

BEGIN
DBMS_SCHEDULER.DROP_PROGRAM_ARGUMENT (
program_name            => 'operations_reporting',
argument_position       => 2);

DBMS_SCHEDULER.DROP_PROGRAM_ARGUMENT (
program_name            => 'operations_reporting',
argument_name           => 'end_date');
END;
/

一部の特殊なケースでは、プログラムのロジックがスケジューラの環境によって異なる場合があります。この目的のために、スケジューラには、プログラムに引数として渡すことができる事前定義のメタデータ引数がいくつかあります。たとえば、スケジュールがウィンドウ名である一部のジョブについては、ジョブの開始時にウィンドウがオープンしている時間の長さを認識していると便利です。これは、ウィンドウ終了時間をプログラムに対するメタデータ引数として定義すると可能です。

特定ジョブのメタデータに対するアクセス権限がプログラムに必要な場合は、プログラムの実行時にスケジューラによって値が指定されるように、DEFINE_METADATA_ARGUMENTプロシージャを使用して特別なメタデータ引数を定義できます。

関連項目:
「ジョブ引数の設定」

プログラムの変更

プログラムを変更するには、その属性を変更します。プログラムを変更するには、Enterprise ManagerまたはDBMS_SCHEDULER.SET_ATTRIBUTEおよびDBMS_SCHEDULER.SET_ATTRIBUTE_NULLパッケージ・プロシージャを使用します。プログラム属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_SCHEDULER.CREATE_PROGRAMプロシージャに関する項を参照してください。

変更したプログラムが、現在実行中のジョブで使用されている場合、そのジョブは変更操作前に定義されたプログラムで引き続き実行されます。

次の例では、プログラムmy_program1で実行される実行可能ファイルを変更しています。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE (
name           => 'my_program1',
attribute      => 'program_action',
value          => '/usr/local/bin/salesreports1');
END;
/

プログラムの削除

1つ以上のプログラムを削除するには、DROP_PROGRAMプロシージャまたはEnterprise Managerを使用します。

削除されたプログラムを指し示している実行中のジョブはDROP_PROGRAMコールの影響を受けず、実行を継続できます。プログラムを削除すると、プログラムに関連する引数もすべて削除されます。プログラム名のカンマ区切りのリストを指定することで、1回のコールで複数のプログラムを削除できます。たとえば、次の文では3つのプログラムが削除されます。

BEGIN
DBMS_SCHEDULER.DROP_PROGRAM('program1, program2, program3');
END;
/

DROP_PROGRAMプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

プログラムの無効化

1つ以上のプログラムを無効(使用禁止)にするには、DISABLEプロシージャまたはEnterprise Managerを使用します。プログラムが使用禁止になると、ステータスがdisabledに変更されます。使用禁止プログラムとは、メタデータが存在しても、このプログラムを指定したジョブを実行できないことを意味します。

使用禁止のプログラムを指し示している実行中のジョブはDISABLEコールの影響を受けず、実行を継続できます。プログラムが使用禁止になった場合でも、そのプログラムに関係する引数は影響を受けません。

プログラムは他の理由で使用禁止になる場合もあります。たとえば、プログラム引数が削除された場合やnumber_of_argumentsの変更ですべての引数を定義できなくなった場合などです。

DISABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

プログラムの有効化

1つ以上のプログラムを有効(使用可能)にするには、ENABLEプロシージャまたはEnterprise Managerを使用します。プログラムが使用可能になると、使用可能フラグがTRUEに設定されます。プログラムは、デフォルトで使用禁止で作成されるため、そのプログラムを指し示すジョブを使用可能にするには、プログラムを使用可能にする必要があります。プログラムが使用可能になる前に、処理が有効であること、およびすべての引数が定義されていることを確認するために妥当性チェックが実行されます。

ENABLEプロシージャ・コールにプログラム名のカンマ区切りのリストを指定することで、1回のコールで複数のプログラムを使用可能にできます。たとえば、次の文では3つのプログラムが使用可能になります。

BEGIN
DBMS_SCHEDULER.ENABLE('program1, program2, program3');
END;
/

ENABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ジョブを定義するためのスケジュールの作成および管理

必要に応じて、スケジュール・オブジェクト(スケジュール)を使用してジョブの実行時期を定義できます。スケジュールは、データベースにオブジェクトとして作成および保存することによってユーザー間で共有できます。

この項では、スケジュールの基本的なタスクについて説明します。この項の内容は、次のとおりです。

- スケジュールのタスクとそのプロシージャ

- スケジュールの作成

- スケジュールの変更

- スケジュールの削除

- 繰返し間隔の設定

関連項目:

- スケジュールの概要については、「スケジュール」を参照してください。

- ジョブ・リソース使用率を管理しながらジョブをスケジュールする方法は、「ウィンドウを使用したジョブ・スケジューリングとジョブ優先度の管理」および「ウィンドウ・グループを使用したジョブ・スケジューリングとジョブ優先度の管理」を参照してください。

スケジュールのタスクとそのプロシージャ

表29-4に、スケジュールの一般的なタスクとその処理に使用するプロシージャを示します。

表29-4 スケジュールのタスクとそのプロシージャ

タスク

プロシージャ

必要な権限

スケジュールの作成

CREATE_SCHEDULE

CREATE JOBまたはCREATE ANY JOB

スケジュールの変更

SET_ATTRIBUTE

ALTERまたはCREATE ANY JOB、あるいは所有者

スケジュールの削除

DROP_SCHEDULE

ALTERまたはCREATE ANY JOB、あるいは所有者

権限の詳細は、「スケジューラ権限」を参照してください。

スケジュールの作成

スケジュールを作成するには、CREATE_SCHEDULEプロシージャまたはEnterprise Managerを使用します。スケジュールは、そのスケジュールを作成するユーザーのスキーマ内に作成され、最初に作成した時点で使用可能です。また、別のユーザーのスキーマ内に作成できます。スケジュールが作成されると、他のユーザーもそのスケジュールを使用できます。スケジュールは、PUBLICへのアクセス権を伴って作成されます。このため、スケジュールへのアクセス権限を明示的に付与する必要はありません。次に、スケジュールの作成例を示します。

BEGIN
DBMS_SCHEDULER.CREATE_SCHEDULE (
schedule_name     => 'my_stats_schedule',
start_date        => SYSTIMESTAMP,
end_date          => SYSTIMESTAMP + INTERVAL '30' day,
repeat_interval   => 'FREQ=HOURLY; INTERVAL=4',
comments          => 'Every 4 hours');
END;
/

関連項目:

- CREATE_SCHEDULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 「イベント・スケジュールの作成」

スケジュールの変更

スケジュールを変更するには、SET_ATTRIBUTEおよびSET_ATTRIBUTE_NULLパッケージ・プロシージャまたはEnterprise Managerを使用します。スケジュールを変更すると、スケジュールの定義が変更されます。スケジュール名以外のすべての属性を変更できます。スケジュールの属性は、*_SCHEDULER_SCHEDULESビューで使用可能です。

スケジュールを変更しても、このスケジュールを使用している実行中のジョブとオープン中のウィンドウに影響を与えることはありません。変更が有効になるのは、次回のジョブ実行時またはウィンドウ・オープン時からです。

SET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

スケジュールの削除

スケジュールを削除するには、DROP_SCHEDULEプロシージャまたはEnterprise Managerを使用します。このプロシージャ・コールによって、スケジュール・オブジェクトがデータベースから削除されます。

DROP_SCHEDULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

繰返し間隔の設定

ジョブの繰返し時期および間隔を制御するには、ジョブ自体またはジョブが参照する名前付きスケジュールのrepeat_interval属性を設定します。repeat_intervalは、DBMS_SCHEDULERパッケージまたはEnterprise Managerで設定できます。

repeat_intervalの評価結果は、一連のタイムスタンプです。各タイムスタンプの時点で、スケジューラがジョブを実行します。ジョブまたはスケジュールの開始日も、タイムスタンプの結果セットの決定に役立つことに注意してください。(repeat_intervalの評価の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。)repeat_intervalに値を指定しないと、指定した開始日に1回のみジョブが実行されます。

ジョブが開始されるとすぐに、repeat_intervalが評価されて、次にスケジュールされるジョブの実行時刻が決定されます。ジョブがまだ実行されている間に、次にスケジュールされる実行時刻になる場合があります。ただし、ジョブの新しいインスタンスは、現在のジョブが完了するまで開始されません。

繰返し間隔を指定する方法は、次の2通りあります。

- スケジューラのカレンダ指定構文の使用方法

- PL/SQL式の使用方法

スケジューラのカレンダ指定構文の使用方法

ジョブの繰返し間隔を設定する主要な方法は、スケジューラのカレンダ指定式を使用してrepeat_interval属性を設定する方法です。repeat_intervalのカレンダ指定構文およびCREATE_SCHEDULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

カレンダ指定式の例

次に、簡単な繰返し間隔の例を示します。わかりやすくするために、開始日は評価結果に影響を与えないと仮定します。

毎週金曜日に実行(3つの例はすべて同等です。)

FREQ=DAILY; BYDAY=FRI;
FREQ=WEEKLY; BYDAY=FRI;
FREQ=YEARLY; BYDAY=FRI;

隔週金曜日に実行。

FREQ=WEEKLY; INTERVAL=2; BYDAY=FRI;

毎月末に実行。

FREQ=MONTHLY; BYMONTHDAY=-1;

毎月末の翌日に実行。

FREQ=MONTHLY; BYMONTHDAY=-2;

3月10日に実行(両方の例は同等です。)

FREQ=YEARLY; BYMONTH=MAR; BYMONTHDAY=10;
FREQ=YEARLY; BYDATE=0310;

10日おきに実行。

FREQ=DAILY; INTERVAL=10;

毎日午後4時、5時および6時に実行。

FREQ=DAILY; BYHOUR=16,17,18;

隔月15日に実行。

FREQ=MONTHLY; INTERVAL=2; BYMONTHDAY=15;

毎月29日に実行。

FREQ=MONTHLY; BYMONTHDAY=29;

毎月第2水曜日に実行。

FREQ=MONTHLY; BYDAY=2WED;

毎年最終金曜日に実行。

FREQ=YEARLY; BYDAY=-1FRI;

50時間おきに実行。

FREQ=HOURLY; INTERVAL=50;

隔月末に実行。

FREQ=MONTHLY; INTERVAL=2; BYMONTHDAY=-1;

毎月初めの3日間1時間おきに実行。

FREQ=HOURLY; BYMONTHDAY=1,2,3;

以降は、多少複雑な繰返し間隔の例です。

毎月最後の稼働日に実行(稼働日は月曜日から金曜日と仮定)。

FREQ=MONTHLY; BYDAY=MON,TUE,WED,THU,FRI; BYSETPOS=-1

会社の祝日を除く、毎月の最後の稼働日に実行(この例では、Company_Holidaysという既存の名前付きスケジュールを参照しています。)

FREQ=MONTHLY; BYDAY=MON,TUE,WED,THU,FRI; EXCLUDE=Company_Holidays; BYSETPOS=-1

毎週金曜日および会社の休業日の正午に実行。

FREQ=YEARLY;BYDAY=FRI;BYHOUR=12;INCLUDE=Company_Holidays

7月4日、メモリアル・デーおよびレイバー・デーの3つの祝日に実行(この例では、それぞれの祝日に対応する1日を定義したJUL4、MEMおよびLABの既存の3つの名前付きスケジュールを参照しています。)

JUL4,MEM,LAB

カレンダ指定式評価の例

繰返し間隔を"FREQ=MINUTELY;INTERVAL=2;BYHOUR=17; BYMINUTE=2,4,5,50,51,7;"に、開始日を28-FEB-2004 23:00:00に設定すると、次のスケジュールが生成されます。

SUN 29-FEB-2004 17:02:00
SUN 29-FEB-2004 17:04:00
SUN 29-FEB-2004 17:50:00
MON 01-MAR-2004 17:02:00
MON 01-MAR-2004 17:04:00
MON 01-MAR-2004 17:50:00
...

繰返し間隔を"FREQ=MONTHLY;BYMONTHDAY=15, -1"に、開始日を29-DEC-2003 9:00:00に設定すると、次のスケジュールが生成されます。

WED 31-DEC-2003 09:00:00
THU 15-JAN-2004 09:00:00
SAT 31-JAN-2004 09:00:00
SUN 15-FEB-2004 09:00:00
SUN 29-FEB-2004 09:00:00
MON 15-MAR-2004 09:00:00
WED 31-MAR-2004 09:00:00
...

繰返し間隔を"FREQ=MONTHLY;"に、開始日を29-DEC-2003 9:00:00に設定すると、次のスケジュールが生成されます。(BYMONTHDAY句がないため、開始日から日付が取得されることに注意してください。)

MON 29-DEC-2003 09:00:00
THU 29-JAN-2004 09:00:00
SUN 29-FEB-2004 09:00:00
MON 29-MAR-2004 09:00:00
...

カレンダ指定式の使用例

カレンダ指定構文を使用した次の例について考えてみます。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name             => 'scott.my_job1',
start_date           => '15-JUL-04 01.00.00 AM Europe/Warsaw',
repeat_interval      => 'FREQ=MINUTELY; INTERVAL=30;',
end_date             => '15-SEP-04 01.00.00 AM Europe/Warsaw',
comments             => 'My comments here');
END;
/

これにより、my_job1がscottに作成されます。7月15日に始めて実行されて、9月15日まで実行されます。このジョブの開始日は7月15日、終了日は9月15日で、30分おきに実行されます。

PL/SQL式の使用方法

カレンダ指定構文より複雑な機能が必要な場合は、PL/SQL式を使用できます。ただし、PL/SQL式はウィンドウまたは名前付きスケジュールでは使用できません。PL/SQL式は、日付またはタイムスタンプに評価される必要があります。これ以外に制限はないため、適切なプログラミングによって、あらゆる繰返し間隔を作成できます。例として、次の文を考えてみます。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name             => 'scott.my_job2',
start_date           => '15-JUL-04 01.00.00 AM Europe/Warsaw',
repeat_interval      => 'SYSTIMESTAMP + INTERVAL '30' MINUTE',
end_date             => '15-SEP-04 01.00.00 AM Europe/Warsaw',
comments             => 'My comments here');
END;
/

これにより、my_job1がscottに作成されます。7月15日に始めて実行されて、9月15日まで30分ごとに実行されます。repeat_intervalが、30分後の日付を返すSYSTIMESTAMP + INTERVAL '30' MINUTEに設定されているため、30分ごとにジョブが実行されます。

PL/SQL式とカレンダ指定構文の動作の相違点

カレンダ指定式とPL/SQL繰返し間隔の動作には、次のような重要な相違があります。

- 開始日
カレンダ指定構文を使用する場合、開始日は参照専用の日になります。そのため、スケジュールはこの日に有効になります。開始日にジョブが開始されるという意味ではありません。

PL/SQL式を使用した場合、開始日はジョブが最初に実行を開始した実際の時間を表します。

- 次回の実行時期
カレンダ指定構文を使用した場合、次回のジョブ実行時期は固定されています。

PL/SQL式を使用する場合、次にジョブが実行される時期は、ジョブの現在の実行の実際の開始時刻によって異なります。違いを示す例として、ジョブが午後2時に開始して、2時間ごとに繰り返すスケジュールになっている場合、カレンダ指定構文で繰返し間隔が指定されていると、ジョブは4時、6時などに繰り返し実行されます。PL/SQLを使用して、ジョブが2時10分に開始された場合、ジョブは4時10分に繰り返されますが、実際には次のジョブが4時11分に開始した場合は、後続の実行が6時11分になります。

これら2つの点を例で示すために、15-July-2003 1:45:00という開始日付が設定されていて、2時間ごとに繰り返す必要がある場合を考えます。"FREQ=HOURLY; INTERVAL=2; BYMINUTE=0;"というカレンダ指定構文では、次のスケジュールが生成されます。

TUE 15-JUL-2003  03:00:00
TUE 15-JUL-2003  05:00:00
TUE 15-JUL-2003  07:00:00
TUE 15-JUL-2003  09:00:00
TUE 15-JUL-2003  11:00:00
...

カレンダ式では、2時間おきの毎正時に繰返しを実行します。

一方、PL/SQL式"SYSTIMESTAMP + interval '2' hour"では、実行時間は次のようになります。

TUE 15-JUL-2003  01:45:00
TUE 15-JUL-2003  03:45:05
TUE 15-JUL-2003  05:45:09
TUE 15-JUL-2003  07:45:14
TUE 15-JUL-2003  09:45:20
...

繰返し間隔と夏時間

ジョブの繰返しでは、次回のジョブ実行時間のスケジュールは、タイム・ゾーン列のあるタイムスタンプに格納されます。カレンダ指定構文を使用する場合、タイム・ゾーンはstart_dateから取り出されます。start_dateが指定されていない場合の動作の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

PL/SQL式に基づいた繰返し間隔の場合、タイム・ゾーンはPL/SQL式が返すタイムスタンプの一部になっています。いずれの場合も、リージョン名を使用することが重要です。たとえば、"+2:00"のように絶対タイム・ゾーン・オフセットを指定するのではなく、"Europe/Istanbul"のように指定します。タイム・ゾーンがリージョン名で指定されている場合のみ、スケジューラはそのリージョンに適用される夏時間調整に従います。

イベントを使用したジョブの開始

この項の内容は次のとおりです。

- イベントの概要

- アプリケーションによって呼び出されたイベントによるジョブの開始

- ファイルがシステムに到着したことによるジョブの開始

関連項目:

- 「イベントに基づくジョブとスケジュールの作成例」

- プロセス・フローを正確に制御するためにチェーンでイベントを使用する方法は、「ジョブ・チェーンの作成と管理」を参照してください。

イベントの概要

イベントは、なんらかの処理または発生が検出されたことを、アプリケーションまたはシステム・プロセスが別のアプリケーションまたはシステム・プロセスに示すために送信するメッセージです。イベントは、1つのアプリケーションまたはプロセスによって呼び出され(送信)、1つ以上のアプリケーションまたはプロセスによって使用されます(受信)。

スケジューラでは、次の2種類のイベントが使用されます。

- アプリケーションによって呼び出されるイベント
アプリケーションは、スケジューラが使用するイベントを呼び出すことができます。スケジューラは、ジョブを開始することでこのイベントを処理します。たとえば、在庫が一定のしきい値を下回ったことを感知した在庫追跡システムでは、在庫の補充ジョブを開始するイベントを呼び出すことができます。

「アプリケーションによって呼び出されたイベントによるジョブの開始」を参照してください。

- File Watcherによって呼び出されるファイル到着イベント
File Watcher(Oracle Database 11g リリース2で導入されたスケジューラ・オブジェクト)を作成して、システムへのファイルの到着を監視できます。その後、File Watcherでファイルの存在が検出されたときに開始するジョブを構成できます。たとえば、チェーン店用のデータ・ウェアハウスでは、店舗内の店頭システムからアップロードされた日次売上レポートからデータがロードされます。データ・ウェアハウスのロード・ジョブは、新しい日次レポートが到着するたびに開始されます。

「ファイルがシステムに到着したことによるジョブの開始」を参照してください。

関連項目:

- アドバンスト・キューイングの詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。

- スケジューラによって呼び出されるジョブ状態変化イベントがアプリケーションで使用される仕組みの詳細は、「スケジューラによって呼び出されるイベントによるジョブ状態の監視」を参照してください。

アプリケーションによって呼び出されたイベントによるジョブの開始

アプリケーションで、ジョブを開始するようにスケジューラに通知するイベントを呼び出すことができます。この方法で開始されるジョブは、イベントベースのジョブと呼ばれます。日付、時間、繰り返し発生する情報を定義するかわりに、イベントを参照する名前付きスケジュールを作成できます。このようなスケジュール(イベント・スケジュール)が割り当てられたジョブは、イベントが呼び出されると実行されます。

ジョブの開始をスケジューラに通知するイベントを呼び出すために、アプリケーションは、このジョブの設定時に指定したOracle Streamsアドバンスト・キューイングのキューにメッセージをエンキューします。ジョブが開始されると、ジョブはオプションでイベントのメッセージ内容を取得できます。

イベントベースのジョブを作成するには、次の2つの追加属性を設定する必要があります。

- queue_spec
キュー仕様。アプリケーションがジョブ開始イベントを呼び出すためのメッセージをエンキューするキューの名前が含まれます。または、セキュアなキューの場合はキュー名の後にカンマとエージェント名が記述されます。

- event_condition
メッセージでジョブを開始するためにTRUEと評価される必要のあるメッセージ・プロパティに基づく条件式。この式では、Oracle Streams Advanced Queuingルールの構文を使用する必要があります。したがって、メッセージ・ペイロードがオブジェクト・タイプで、式のオブジェクト属性の前にtab.user_dataを付加した場合は、ユーザー・データ・プロパティを式に含めることができます。

ルールの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_AQADM.ADD_SUBSCRIBERプロシージャに関する項を参照してください。

次の例では、event_conditionが、午前0時から午前9時の間に発生する在庫不足イベントのみを選択するように設定されます。メッセージ・ペイロードはevent_typeとevent_timestampの2つの属性を持つオブジェクトであるとします。

event_condition = 'tab.user_data.event_type = ''LOW_INVENTORY'' and
extract hour from tab.user_data.event_timestamp < 9'

queue_specおよびevent_conditionは、インラインのジョブ属性として指定するか、またはこれらの属性を指定したイベント・スケジュールを作成し、ジョブからこのスケジュールを指し示すことができます。

注意:
スケジューラは、event_conditionに一致するイベントが発生するたびにイベントベースのジョブを実行します。ただし、デフォルトでは、ジョブがすでに実行されている間に発生したイベントは無視され、イベントは消費されますが別のジョブの実行がトリガーされることはありません。Oracle Database 11g リリース1以降では、ジョブ属性PARALLEL_INSTANCESをTRUEに設定することで、このデフォルト動作を変更できます。この場合、ジョブのインスタンスがイベントのすべてのインスタンスに対して起動され、すべてのジョブ・インスタンスが軽量ジョブになります。詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のSET_ATTRIBUTEプロシージャに関する項を参照してください。

表29-5に、アプリケーションによって呼び出される(スケジューラによって使用される)イベントに関する一般的な管理タスクとそれに対応するプロシージャを示します。

表29-5 アプリケーションによって呼び出されるイベントに対するイベント・タスクとそのプロシージャ

タスク

プロシージャ

必要な権限

イベントベースのジョブの作成

CREATE_JOB

CREATE JOBまたはCREATE ANY JOB

イベントベースのジョブの変更

SET_ATTRIBUTE

CREATE ANY JOB、あるいは変更対象のジョブの所有権またはそのジョブに対するALTER権限

イベント・スケジュールの作成

CREATE_EVENT_SCHEDULE

CREATE JOBまたはCREATE ANY JOB

イベント・スケジュールの変更

SET_ATTRIBUTE

CREATE ANY JOB、あるいは変更対象のスケジュールの所有権またはそのスケジュールに対するALTER権限

関連項目:
キューの作成およびメッセージのエンキュー方法は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。

イベントベースのジョブの作成

イベントベースのジョブを作成するには、CREATE_JOBプロシージャまたはEnterprise Managerを使用します。ジョブには、ジョブ属性としてイベント情報をインラインで組み込むか、またはイベント・スケジュールを指し示してイベント情報を指定できます。

時間スケジュールに基づくジョブと同様に、イベントベースのジョブは、ジョブ終了日をすぎるか、max_runsまたは最大失敗回数(max_failures)に達するまでは自動削除されません。

イベント情報をジョブ属性として指定する方法

イベント情報をジョブ属性として指定するには、CREATE_JOBの代替構文を使用して、queue_specおよびevent_condition属性を組み込みます。

次の例では、項目の在庫レベルが低しきい値レベルを下回ったことがアプリケーションからスケジューラに伝達されるときに開始されるジョブを作成しています。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name            =>  'process_lowinv_j1',
program_name        =>  'process_lowinv_p1',
event_condition     =>  'tab.user_data.event_type = ''LOW_INVENTORY''',
queue_spec          =>  'inv_events_q, inv_agent1',
enabled             =>  TRUE,
comments            =>  'Start an inventory replenishment job');
END;
/

CREATE_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

イベント情報をイベント・スケジュールで指定する方法

イベント情報をイベント・スケジュールで指定するには、ジョブのschedule_name属性にイベント・スケジュールの名前を設定する必要があります。次に例を示します。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name            =>  'process_lowinv_j1',
program_name        =>  'process_lowinv_p1',
schedule_name       =>  'inventory_events_schedule',
enabled             =>  TRUE,
comments            =>  'Start an inventory replenishment job');
END;
/

詳細は、「イベント・スケジュールの作成」を参照してください。

イベントベースのジョブの変更

イベントベースのジョブを変更するには、SET_ATTRIBUTEプロシージャを使用します。イベントをインラインで指定するジョブの場合、SET_ATTRIBUTEを使用してqueue_spec属性とevent_condition属性を別々に設定することはできません。かわりに、event_specと呼ばれる属性を設定し、イベント条件とキュー仕様を3番目と4番目の引数としてSET_ATTRIBUTEに渡す必要があります。

次に、event_spec属性の使用例を示します。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE ('my_job', 'event_spec',
'tab.user_data.event_type = ''LOW_INVENTORY''', 'inv_events_q, inv_agent1');
END;
/

SET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

イベント・スケジュールの作成

イベントに基づいたスケジュールを作成できます。作成したスケジュールは、複数のジョブに再利用できます。そのためには、CREATE_EVENT_SCHEDULEプロシージャまたはEnterprise Managerを使用します。次に、イベント・スケジュールの作成例を示します。

BEGIN
DBMS_SCHEDULER.CREATE_EVENT_SCHEDULE (
schedule_name     =>  'inventory_events_schedule',
start_date        =>  SYSTIMESTAMP,
event_condition   =>  'tab.user_data.event_type = ''LOW_INVENTORY''',
queue_spec        =>  'inv_events_q, inv_agent1');
END;
/

イベント・スケジュールを削除するには、DROP_SCHEDULEプロシージャを使用します。CREATE_EVENT_SCHEDULEの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

イベント・スケジュールの変更

イベント・スケジュールのイベント情報を変更する方法は、ジョブのイベント情報を変更する方法と同じです。詳細は、「イベントベースのジョブの変更」を参照してください。

次の例は、イベント・スケジュールのイベント情報を変更するためのSET_ATTRIBUTEプロシージャおよびevent_spec属性の使用方法を示しています。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE ('inventory_events_schedule', 'event_spec',
'tab.user_data.event_type = ''LOW_INVENTORY''', 'inv_events_q, inv_agent1');
END;
/

SET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

イベントベースのジョブにイベント・メッセージを渡す方法

メタデータの引数を介して、スケジューラは、イベントベースのジョブに対して、ジョブを開始したイベントのメッセージ内容を渡すことができます。次のルールが適用されます。

- ジョブは、タイプSTORED_PROCEDUREの名前付きプログラムを使用する必要があります。

- 名前付きプログラムの引数の1つがメタデータ引数であり、そのmetadata_attributeがEVENT_MESSAGEに設定されている必要があります。

- プログラムを実装するストアド・プロシージャには、名前付きプログラムのメタデータ引数に対応する位置に引数が必要です。引数の型は、アプリケーションがジョブ開始イベントをエンキューするキューのデータ型であることが必要です。

EVENT_MESSAGEメタデータ引数があるジョブをRUN_JOBプロシージャを使用して手動で実行した場合、その引数に渡される値はNULLです。

次の例は、イベント・メッセージの内容を受け取ることができるイベントベースのジョブを作成する方法を示しています。

create or replace procedure my_stored_proc (event_msg IN event_queue_type)
as
begin
-- retrieve and process message body
end;
/

begin
dbms_scheduler.create_program (
program_name => 'my_prog',
program_action=> 'my_stored_proc',
program_type => 'STORED_PROCEDURE',
number_of_arguments => 1,
enabled => FALSE) ;

dbms_scheduler.define_metadata_argument (
program_name => 'my_prog',
argument_position => 1 ,
metadata_attribute => 'EVENT_MESSAGE') ;

dbms_scheduler.enable ('my_prog');
exception
when others then raise ;
end ;
/

begin
dbms_scheduler.create_job (
job_name => 'my_evt_job' ,
program_name => 'my_prog',
schedule_name => 'my_evt_sch',
enabled => true,
auto_Drop => false) ;
exception
when others then raise ;
end ;
/

ファイルがシステムに到着したことによるジョブの開始

ファイルがローカル・システムまたはリモート・システムに到着したときにジョブを開始するようにスケジューラを構成できます。ジョブはイベントベースのジョブであり、ファイル到着イベントはFile Watcher(Oracle Database 11g リリース2で導入されたスケジューラ・オブジェクト)によって呼び出されます。

この項の内容は次のとおりです。

- File Watcherの概要

- リモート・システムからのファイルの到着イベントの有効化

- File WatcherおよびFile Watcherジョブの作成

- ファイルの到着の例

- File Watcherの管理

- File Watcherの情報の表示

File Watcherの概要

File Watcherは、ファイルがシステムに到着したことによってスケジューラでジョブが開始される場合の対象ファイルの場所、名前などのプロパティを定義したスケジューラ・オブジェクトです。ファイル・ウォッチャを作成し、次に、そのファイル・ウォッチャを参照する任意の数のイベントベースのジョブまたはイベント・スケジュールを作成します。File Watcherでは、指定されたファイルの到着、新たに到着したファイルを検出すると、到着イベントを呼び出します。

新たに到着したファイルとは、変更されているため、最新の実行またはFile Watcherジョブがターゲット・ファイル・ディレクトリの監視を開始した時間よりタイムスタンプが遅いファイルです。

File Watcherがファイルが新たに到着したものか否かを判断する方法は、UNIXコマンドls -lrtまたはWindows DOSコマンドdir /odを繰り返し実行してディレクトリ内の新しいファイルを監視するのと同じです。この両方のコマンドでは必ず、最近に変更されたファイルが最後にリストされます。つまり最も古いものが最初で最も新しいものが最後になります。

注意:
動作は次のとおりです。
UNIX mvコマンドはファイルの変更時間を変更しませんが、cpコマンドは変更します。

Windows move/pasteおよびcopy/pasteコマンドは、ファイルの変更時間を変更しません。そうするには、moveまたはcopyコマンドの後にDOSコマンドcopy /b file_name +,,を実行します。

CREATE_FILE_WATCHERプロシージャのsteady_state_durationパラメータ(『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照)は、File Watcherがファイルを検出したと判断するまでに、ファイルが未変更のままであることが必要な最小時間間隔を指定します。これは1時間を超えることはできません。パラメータがNULLの場合、内部値が使用されます。

ファイルの到着イベントによって開始されたジョブでは、新しく到着したファイルを示すイベント・メッセージを取得できます。このメッセージには、ファイルの検索、オープンおよび処理に必要な情報が含まれます。

File Watcherでは、ローカル・システム(Oracle Databaseを実行しているホスト・コンピュータ)またはリモート・システムでファイルを監視できます。リモート・システムではスケジューラ・エージェントが実行され、そのエージェントがデータベースに登録されている必要があります。

File Watcherでは、10分間隔でファイルの到着がチェックされます。この間隔は調整可能です。詳細は、「ファイルの到着を検出する間隔の変更」を参照してください。

スキーマにFile Watcherを作成するには、CREATE JOBシステム権限が必要です。自分のスキーマと異なるスキーマ(許可されないSYSスキーマ以外)にFile Watcherを作成するには、CREATE ANY JOBシステム権限が必要です。別のスキーマ内のジョブでFile Watcherを参照できるように、File Watcherに対するEXECUTEオブジェクト権限を付与できます。また、別のユーザーがFile Watcherを変更できるように、File Watcherに対するALTERオブジェクト権限を付与できます。

File Watcherを使用するには、データベースのJava仮想マシン(JVM)コンポーネントをインストールする必要があります。

リモート・システムからのファイルの到着イベントの有効化

リモート・システムからファイル到着イベントを受け取るには、そのシステムにスケジューラ・エージェントをインストールし、そのエージェントをデータベースに登録する必要があります。リモート・システムでファイル到着イベントを生成するのに、Oracle Databaseインスタンスが実行されている必要はありません。

リモート・システムでのファイル到着イベントの呼出しを有効にする手順は、次のとおりです。

1. リモート外部ジョブを実行するようにローカル・データベースを設定します。
詳細は、「リモート・ジョブを実行するためのデータベースの設定」を参照してください。

2. 最初のリモート・システムでスケジューラ・エージェントをインストール、構成、登録および起動します。
手順は、「リモート・ホストでのスケジューラ・エージェントのインストールと構成」を参照してください。

これにより、ローカル・データベースで管理されている外部宛先のリストにリモート・ホストが追加されます。

3. 追加の各リモート・システムに対して前述の手順を繰り返します。

File WatcherおよびFile Watcherジョブの作成

File Watcherを作成し、指定したファイルが到着したときに開始されるイベントベースのジョブを作成するには、次のタスクを実行します。

タスク1: 資格証明の作成

File Watcherでは、ホスト・オペレーティング・システムでファイルへのアクセスを認証するために使用されるスケジューラ資格証明オブジェクト(資格証明)が必要になります。資格証明を作成するために必要な権限の詳細は、「資格証明」を参照してください。

次の手順を実行します。

1. 監視対象ファイルにアクセスする必要があるオペレーティング・システム・ユーザーの資格証明を作成します。

BEGIN
DBMS_SCHEDULER.CREATE_CREDENTIAL('WATCH_CREDENTIAL', 'salesapps', 'sa324w1');
END;
/

2. File Watcherによって開始されるイベントベースのジョブを所有するスキーマに、資格証明に対するEXECUTEオブジェクト権限を付与します。

GRANT EXECUTE ON WATCH_CREDENTIAL to DSSUSER;

タスク2: File Watcherの作成

次の手順を実行します。

1. 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_SCHEDULER.CREATE_FILE_WATCHERプロシージャに関する項の説明に従って属性を割り当て、File Watcherを作成します。ファイル名にワイルドカード・パラメータを指定できます。DIRECTORY_PATH属性の「?」接頭辞は、Oracleホーム・ディレクトリへのパスを示します。NULLのdestinationはローカル・ホストを示します。リモート・ホストのファイルを監視するには、ビューALL_SCHEDULER_EXTERNAL_DESTSから取得できる有効な外部宛先名を指定します。

BEGIN
DBMS_SCHEDULER.CREATE_FILE_WATCHER(
FILE_WATCHER_NAME => 'EOD_FILE_WATCHER',
DIRECTORY_PATH    => '?/eod_reports',
FILE_NAME         => 'eod*.txt',
CREDENTIAL_NAME   => 'WATCH_CREDENTIAL',
DESTINATION       => NULL,
ENABLED           => FALSE);
END;
/

2. File Watcherを参照するイベントベースのジョブを所有するスキーマに、File Watcherに対するEXECUTEを付与します。

GRANT EXECUTE ON EOD_FILE_WATCHER to DSSUSER;

タスク3: プログラム・オブジェクトの作成とメタデータ引数の指定

アプリケーションでファイル到着イベント・メッセージの内容(ファイル名、ファイル・サイズなど)を取得できるように、スケジューラ・プログラム・オブジェクトを作成し、イベント・メッセージを参照するメタデータ引数を指定します。

次の手順を実行します。

1. プログラムを作成します。

BEGIN
DBMS_SCHEDULER.CREATE_PROGRAM(
PROGRAM_NAME        => 'DSSUSER.EOD_PROGRAM',
PROGRAM_TYPE        => 'STORED_PROCEDURE',
PROGRAM_ACTION      => 'EOD_PROCESSOR',
NUMBER_OF_ARGUMENTS => 1,
ENABLED             => FALSE);
END;
/

2. event_message属性を使用してメタデータ引数を定義します。

BEGIN
DBMS_SCHEDULER.DEFINE_METADATA_ARGUMENT(
PROGRAM_NAME       => 'DSSUSER.EOD_PROGRAM',
METADATA_ATTRIBUTE => 'event_message',
ARGUMENT_POSITION  => 1);
END;
/

3. プログラムで呼び出すストアド・プロシージャを作成します。
ファイル到着イベントを処理するストアド・プロシージャには、SYS.SCHEDULER_FILEWATCHER_RESULTタイプの引数(イベント・メッセージのデータ型)を指定する必要があります。この引数の位置は、定義済のメタデータ引数の位置と一致させる必要があります。これにより、プロシージャでこの抽象データ型の属性にアクセスして、到着したファイルに関する情報を把握できるようになります。

関連項目:

- DEFINE_METADATA_ARGUMENTプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- SYS.SCHEDULER_FILEWATCHER_RESULT型の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

タスク4: File Watcherを参照するイベントベースのジョブの作成

「イベントベースのジョブの作成」の説明に従ってイベントベースのジョブを作成します。ただし、queue_spec属性にキューの仕様を指定するかわりに、File Watcherの名前を指定してください。通常は、event_conditionジョブ属性をnullのままにしますが、必要に応じて条件を指定できます。

ジョブに対してqueue_spec属性を設定するかわりに、イベント・スケジュールを作成し、そのイベント・スケジュールのqueue_spec属性でFile Watcherを参照し、ジョブのschedule_name属性でそのイベント・スケジュールを参照できます。

次の手順を実行して、イベントベースのジョブを準備します。

1. ジョブを作成します。

BEGIN
DBMS_SCHEDULER.CREATE_JOB(
JOB_NAME        => 'DSSUSER.EOD_JOB',
PROGRAM_NAME    => 'DSSUSER.EOD_PROGRAM',
EVENT_CONDITION => NULL,
QUEUE_SPEC      => 'EOD_FILE_WATCHER',
AUTO_DROP       => FALSE,
ENABLED         => FALSE);
END;
/

2. ジョブによって前のイベントがすでに処理されていても、ファイル到着イベントの各インスタンスに対してジョブを実行する場合は、parallel_instances属性をTRUEに設定します。この設定を使用すると、ジョブは軽量ジョブとして実行され、ジョブの複数のインスタンスを迅速に開始できるようになります。イベントベースのジョブで別のイベントがすでに処理されている間に発生するFile Watcherイベントを破棄するには、parallel_instances属性をFALSE(デフォルト)のままにします。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE('DSSUSER.EOD_JOB','PARALLEL_INSTANCES',TRUE);
END;
/

この属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のSET_ATTRIBUTEに関する項を参照してください。

関連項目:

- 「イベント・スケジュールの作成」

- 「名前付きプログラムとスケジュールを使用したジョブの作成」

タスク5: すべてのオブジェクトの有効化

File Watcher、プログラムおよびジョブを有効にします。

BEGIN
DBMS_SCHEDULER.ENABLE('DSSUSER.EOD_PROGRAM,DSSUSER.EOD_JOB,EOD_FILE_WATCHER');
END;
/

ファイルの到着の例

この例では、イベントベースのジョブによって、各地からの日次売上レポートがローカル・ホストに到着するのを監視しています。各レポート・ファイルが到着すると、ストアド・プロシージャによりファイルに関する情報が取得され、eod_reportsという表に格納されます。その後、定期レポート集計ジョブにより、この表を問い合せて、すべての未処理ファイルを処理し、新たに処理したファイルを処理済としてマークできます。

ここでは、次のコードを実行するデータベース・ユーザーにSYS.SCHEDULER_FILEWATCHER_RESULTデータ型に対するEXECUTEが付与されていることを想定しています。

begin
dbms_scheduler.create_credential(
credential_name => 'watch_credential',
username        => 'pos1',
password        => 'jk4545st');
end;
/

create table eod_reports (when timestamp, file_name varchar2(100),
file_size number, processed char(1));

create or replace procedure q_eod_report
(payload IN sys.scheduler_filewatcher_result) as
begin
insert into eod_reports values
(payload.file_timestamp,
payload.directory_path || '/' || payload.actual_file_name,
payload.file_size,
'N');
end;
/

begin
dbms_scheduler.create_program(
program_name        => 'eod_prog',
program_type        => 'stored_procedure',
program_action      => 'q_eod_report',
number_of_arguments => 1,
enabled             => false);
dbms_scheduler.define_metadata_argument(
program_name        => 'eod_prog',
metadata_attribute  => 'event_message',
argument_position   => 1);
dbms_scheduler.enable('eod_prog');
end;
/

begin
dbms_scheduler.create_file_watcher(
file_watcher_name => 'eod_reports_watcher',
directory_path    => '?/eod_reports',
file_name         => 'eod*.txt',
credential_name   => 'watch_credential',
destination       => null,
enabled           => false);
end;
/

begin
dbms_scheduler.create_job(
job_name        => 'eod_job',
program_name    => 'eod_prog',
event_condition => 'tab.user_data.file_size > 10',
queue_spec      => 'eod_reports_watcher',
auto_drop       => false,
enabled         => false);
dbms_scheduler.set_attribute('eod_job','parallel_instances',true);
end;
/

exec dbms_scheduler.enable('eod_reports_watcher,eod_job');

File Watcherの管理

DBMS_SCHEDULER PL/SQLパッケージには、File Watcherの属性を有効化、無効化、削除および設定するためのプロシージャが用意されています。

この項の内容は、次のとおりです。

- File Watcherの有効化

- File Watcherの変更

- File Watcherの無効化および削除

- ファイルの到着を検出する間隔の変更

関連項目:
DBMS_SCHEDULER PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

File Watcherの有効化

File Watcherが無効になっている場合、「タスク5: すべてのオブジェクトの有効化」に示すように、DBMS_SCHEDULER.ENABLEを使用して有効にできます。

File Watcherを有効にできるのは、そのすべての属性が有効な値に設定され、File Watcherの所有者に指定の資格証明に対するEXECUTE権限が付与されている場合のみです。

File Watcherの変更

File Watcherの属性を変更するには、DBMS_SCHEDULER.SET_ATTRIBUTEおよびDBMS_SCHEDULER.SET_ATTRIBUTE_NULLパッケージ・プロシージャを使用します。File Watcherの属性の詳細は、CREATE_FILE_WATCHERプロシージャの説明を参照してください。

File Watcherの無効化および削除

File Watcherを無効にするにはDBMS_SCHEDULER.DISABLEを使用し、File Watcherを削除するにはDBMS_SCHEDULER.DROP_FILE_WATCHERを使用します。File Watcherに依存するジョブが存在する場合、File Watcherを無効にしたり、削除することはできません。このような場合に無効化または削除操作を強制するには、FORCE属性をTRUEに設定します。File Watcherの無効化または削除を強制すると、File Watcherに依存するジョブは無効になります。

ファイルの到着を検出する間隔の変更

File Watcherでは、デフォルトでは10分間隔でファイルの到着がチェックされます。この間隔は変更可能です。

ファイルの到着を検出する間隔を変更する手順は、次のとおりです。

1. SYSユーザーとしてデータベースに接続します。

2. 事前定義のスケジュールSYS.FILE_WATCHER_SCHEDULEのREPEAT_INTERVAL属性を変更します。有効なカレンダ指定構文を使用してください。
次の例では、ファイルの到着を検出する頻度を2分間隔に変更しています。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE('FILE_WATCHER_SCHEDULE', 'REPEAT_INTERVAL',
'FREQ=MINUTELY;INTERVAL=2');
END;
/

File Watcherの情報の表示

*_SCHEDULER_FILE_WATCHERSビューを問い合せることによって、File Watcherに関する情報を表示できます。

SELECT file_watcher_name, destination, directory_path, file_name, credential_name
FROM dba_scheduler_file_watchers;

FILE_WATCHER_NAME    DESTINATION          DIRECTORY_PATH       FILE_NAME  CREDENTIAL_NAME
-------------------- -------------------- -------------------- ---------- ----------------
MYFW                 dsshost.example.com  /tmp                 abc        MYFW_CRED
EOD_FILE_WATCHER                          ?/eod_reports        eod*.txt   WATCH_CREDENTIAL

関連項目:
*_SCHEDULER_FILE_WATCHERSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ジョブ・チェーンの作成と管理

ジョブ・チェーン(「チェーン」)は、結合した1つの目的のために互いにリンクされた一連の名前付きタスクです。チェーンは、前の1つ以上のジョブの結果に応じて異なるジョブが開始される依存性ベースのスケジューリングを実装できる手段です。

チェーンを作成して使用するには、次のタスクを実行します。

タスク

参照先

1. チェーン・オブジェクトを作成します。

チェーンの作成

2. チェーン内のステップを定義します。

チェーン・ステップの定義

3. ルールを追加します。

チェーンへのルールの追加

4. チェーンを使用可能にします。

チェーンの有効化

5. チェーンを指し示すジョブ(チェーン・ジョブ)を作成します。

チェーン用のジョブの作成

この項で説明する他の内容は、次のとおりです。

- チェーンのタスクとそのプロシージャ

- チェーンの削除

- チェーンの実行

- チェーン・ルールの削除

- チェーンの無効化

- チェーン・ステップの削除

- チェーンの停止

- 個々のチェーン・ステップの停止

- チェーンの一時停止

- チェーン・ステップのスキップ

- チェーンの一部実行

- 実行中のチェーンの監視

- 停止状態チェーンの処理

関連項目:

- チェーンの概要については、「チェーン」を参照してください。

- 「チェーンの作成例」

チェーンのタスクとそのプロシージャ

表29-6に、チェーンに関する一般的なタスクとそれに対応するプロシージャを示します。

表29-6 チェーンのタスクとそのプロシージャ

タスク

プロシージャ

必要な権限

チェーンの作成

CREATE_CHAIN

所有者の場合、CREATE JOB、CREATE EVALUATION CONTEXT、CREATE RULEおよびCREATE RULE SET。それ以外の場合、CREATE ANY JOB、CREATE ANY RULE、CREATE ANY RULE SETおよびCREATE ANY EVALUATION CONTEXT。

チェーンの削除

DROP_CHAIN

チェーンの所有権、あるいはチェーンに対するALTER権限またはCREATE ANY JOB権限。所有者以外の場合は、DROP ANY EVALUATION CONTEXTおよびDROP ANY RULE SETも必要です。

チェーンの変更

SET_ATTRIBUTE

チェーンの所有権、あるいはチェーンに対するALTER権限またはCREATE ANY JOB。

実行中チェーンの変更

ALTER_RUNNING_CHAIN

ジョブの所有権、あるいはジョブに対するALTER権限またはCREATE ANY JOB。

チェーンの実行

RUN_CHAIN

CREATE JOBまたはCREATE ANY JOB。また、新規ジョブの所有者には、チェーンに対するEXECUTE権限またはEXECUTE ANY PROGRAMが必要です。

チェーンへのルールの追加

DEFINE_CHAIN_RULE

チェーンの所有権、あるいはチェーンに対するALTER権限またはCREATE ANY JOB権限。CREATE RULE(チェーンの所有者の場合)、CREATE ANY RULE(チェーンの所有者以外の場合)。

チェーン内のルールの変更

DEFINE_CHAIN_RULE

チェーンの所有権、あるいはチェーンに対するALTER権限またはCREATE ANY JOB権限。チェーンの所有者以外の場合は、そのルールに対するALTER権限またはALTER ANY RULEが必要です。

チェーンからのルールの削除

DROP_CHAIN_RULE

チェーンの所有権、あるいはチェーンに対するALTER権限またはCREATE ANY JOB権限。DROP ANY RULE(チェーンの所有者以外の場合)。

チェーンの有効化

ENABLE

チェーンの所有権、あるいはチェーンに対するALTER権限またはCREATE ANY JOB。

チェーンの無効化

DISABLE

チェーンの所有権、あるいはチェーンに対するALTER権限またはCREATE ANY JOB。

ステップの作成

DEFINE_CHAIN_STEP

チェーンの所有権、あるいはチェーンに対するALTER権限またはCREATE ANY JOB。

ステップの削除

DROP_CHAIN_STEP

チェーンの所有権、あるいはチェーンに対するALTER権限またはCREATE ANY JOB。

ステップの変更(ステップへの追加の属性値の割当てを含む)

ALTER_CHAIN

チェーンの所有権、あるいはチェーンに対するALTER権限またはCREATE ANY JOB。

チェーンの作成

チェーンを作成するには、CREATE_CHAINプロシージャを使用します。最初に、必要な権限があることを確認してください。詳細は、「チェーンの各権限の設定」を参照してください。

CREATE_CHAINを使用してチェーン・オブジェクトを作成した後、チェーン・ステップおよびチェーン・ルールを別々に定義します。

次に、チェーンの作成例を示します。

BEGIN
DBMS_SCHEDULER.CREATE_CHAIN (
chain_name          => 'my_chain1',
rule_set_name       => NULL,
evaluation_interval => NULL,
comments            => 'My first chain');
END;
/

rule_set_nameおよびevaluation_interval引数は通常NULLのままです。evaluation_intervalでは、チェーン・ルールが評価される繰返し間隔を定義できます。rule_set_nameは、Oracle Streams内で定義されたルール・セットです。

関連項目:

- evaluation_interval属性の詳細は、「チェーンへのルールの追加」を参照してください。

- CREATE_CHAINの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- ルールおよびルール・セットの詳細は、『Oracle Streams概要および管理』を参照してください。

チェーン・ステップの定義

チェーン・オブジェクトの作成後、1つ以上のチェーン・ステップを定義します。各ステップは、次のいずれかを指し示します。

- スケジューラ・プログラム・オブジェクト(プログラム)

- 別のチェーン(ネストしたチェーン)

- イベント・スケジュール、インライン・イベントまたはFile Watcher

プログラムまたはネストしたチェーンを指し示すステップを定義するには、DEFINE_CHAIN_STEPプロシージャを使用します。次に、my_chain1に2つのステップを追加する例を示します。

BEGIN
DBMS_SCHEDULER.DEFINE_CHAIN_STEP (
chain_name      =>  'my_chain1',
step_name       =>  'my_step1',
program_name    =>  'my_program1');
DBMS_SCHEDULER.DEFINE_CHAIN_STEP (
chain_name      =>  'my_chain1',
step_name       =>  'my_step2',
program_name    =>  'my_chain2');
END;
/

ステップを定義する際に、名前付きプログラムまたはチェーンが存在している必要はありません。ただし、チェーンの実行時には存在して有効になっている必要があり、そうでないとエラーが発生します。

イベントの発生を待機するステップを定義するには、DEFINE_CHAIN_EVENT_STEPプロシージャを使用します。プロシージャの引数を使用して、イベント・スケジュールを指し示すか、インラインのキュー仕様およびイベント条件を組み込むか、またはFile Watcherの名前を指定できます。この例では、名前付きイベント・スケジュール内に指定されているイベントを待機する、3番目のチェーン・ステップが作成されます。

BEGIN
DBMS_SCHEDULER.DEFINE_CHAIN_EVENT_STEP (
chain_name           =>  'my_chain1',
step_name            =>  'my_step3',
event_schedule_name  =>  'my_event_schedule');
END;
/

イベント・ステップでは、ステップが開始されるまでそのイベントを待機することはありません。

ローカルの外部実行可能ファイルを実行するステップ

ローカルの外部実行可能ファイルを実行するステップを定義した後、次の例に示すように、ALTER_CHAINプロシージャを使用して、ステップに資格証明を割り当てる必要があります。

BEGIN
DBMS_SCHEDULER.ALTER_CHAIN('chain1','step1','credential_name','MY_CREDENTIAL');
END;
/

リモートの宛先で実行するステップ

リモート・ホストまたはリモート・データベース上のデータベース・プログラム・ユニットで外部実行可能ファイルを実行するステップを定義した後、次の例に示すように、ALTER_CHAINプロシージャを使用して、ステップに資格証明と宛先の両方を割り当てる必要があります。

BEGIN
DBMS_SCHEDULER.ALTER_CHAIN('chain1','step2','credential_name','DW_CREDENTIAL');
DBMS_SCHEDULER.ALTER_CHAIN('chain1','step2','destination_name','DBHOST1_ORCLDW');
END;
/

ステップを再開可能にする方法

データベース・リカバリ後、デフォルトでは、実行中だったステップがSTOPPEDとしてマークされ、チェーンが続行されます。ALTER_CHAINを使用してチェーン・ステップのrestart_on_recovery属性をTRUEに設定すると、これらのステップをデータベース・リカバリ後に自動的に再開するように指定できます。

DEFINE_CHAIN_STEP、DEFINE_CHAIN_EVENT_STEPおよびALTER_CHAINプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

関連項目:

- 「イベントの概要」

- 「File Watcherの概要」

- 「資格証明」

- 「宛先」

チェーンへのルールの追加

チェーンにルールを追加するには、DEFINE_CHAIN_RULEプロシージャを使用します。このプロシージャは、チェーンに追加する各ルールに対して1回ずつコールします。

チェーン・ルールでは、ステップの実行時期、およびステップ間の依存関係が定義されます。各ルールには条件と処理があります。ルールが評価されるときに、ルールの条件がTRUEに評価されると、その処理が実行されます。条件では、スケジューラ・チェーン条件の構文、またはSQLのWHERE句で有効な構文を使用できます。この構文には、ステップの完了ステータスなど、チェーン・ステップの属性への参照を組み込むことができます。標準な処理は、指定したステップを実行すること、またはステップのリストを実行することです。

チェーン・ルールはすべてまとまって機能し、チェーン全体の処理を定義します。チェーン・ジョブの開始時および各ステップの終了時に、次に実行される処理を判断するためにすべてのルールが評価されます。複数のルールにTRUE条件がある場合は、複数の処理を発生させることができます。チェーンのevaluation_interval属性を設定して、ルールを一定間隔で評価させることもできます。

条件は通常、1つ以上の先行するステップの結果に基づきます。たとえば、先行する2つのステップが成功した場合はあるステップを実行し、2つのステップのいずれかが失敗した場合には別のステップを実行する場合があります。

スケジューラのチェーン条件構文には、次の2つの書式があります。

stepname [NOT] {SUCCEEDED|FAILED|STOPPED|COMPLETED}
stepname ERROR_CODE {comparision_operator|[NOT] IN} {integer|list_of_integers}

条件をブール演算子AND、ORおよびNOT()と組み合せて条件式を作成できます。式にカッコを使用すると、評価順序を指定できます。

ステップに割り当てたプログラム内でRAISE_APPLICATION_ERROR PL/SQL文を使用して、ERROR_CODEを設定できます。この方法でプログラムにより設定されるエラー・コードは負の数値ですが、チェーン・ルール内でERROR_CODEをテストするときには正の数値をテストします。たとえば、プログラムに次の文が含まれている場合を考えます。

RAISE_APPLICATION_ERROR(-20100, errmsg);

チェーン・ルールの条件を次のように指定する必要があります。

stepname ERROR_CODE=20100

ステップ属性

次のリストに、SQL WHERE句の構文を使用する際に条件に含めることのできるステップ属性を示します。

completed
state
start_date
end_date
error_code
duration

completed属性はブール値で、state属性がSUCCEEDED、FAILEDまたはSTOPPEDのときにはTRUEです。

表29-7に、state属性に使用される値を示します。これらの値は、*_SCHEDULER_RUNNING_CHAINSビューのSTATE列で参照可能です。

表29-7 チェーン・ステップのstate属性の値

state属性の値

意味

NOT_STARTED

ステップのチェーンは実行中ですが、ステップはまだ開始されていません。

SCHEDULED

ルールによってAFTER句を使用してステップが開始されており、指定の待機時間はまだ満了していません。

RUNNING

ステップは実行中です。イベント・ステップの場合、ステップは開始されており、イベントを待機中です。

PAUSED

ステップのPAUSE属性がTRUEに設定されて、ステップが一時停止します。一時停止を解除しないと、それに依存するステップは開始できません。

SUCCEEDED

ステップは正常に完了しています。ステップのERROR_CODEは0(ゼロ)です。

FAILED

ステップはエラーで完了しました。ERROR_CODEは0(ゼロ)以外の値です。

STOPPED

ステップはSTOP_JOBプロシージャで停止されました。

STALLED

ステップはネストしたチェーンであり、停止されています。

SQL WHERE句の構文のルールと例は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDEFINE_CHAIN_RULEプロシージャに関する項を参照してください。

スケジューラ・チェーン条件の構文を使用した条件の例

次の例では、スケジューラ・チェーン条件の構文を使用しています。

次の条件を含んだルールによって開始されたステップは、form_validation_stepというステップが完了(SUCCEEDED、FAILEDまたはSTOPPED)すると開始されます。

form_validation_step COMPLETED

次の条件も同様ですが、条件が満たされるにはステップが成功する必要があることを示しています。

form_validation_step SUCCEEDED

次の条件では、エラーがあるかどうかをテストしています。ステップform_validation_stepが失敗して20001以外のエラー・コードが戻された場合は、TRUEになります。

form_validation_step FAILED AND form_validation_step ERROR_CODE != 20001

他の例は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDEFINE_CHAIN_RULEプロシージャに関する項を参照してください。

SQL WHERE構文を使用した条件の例

':step1.state=''SUCCEEDED'''

チェーンの開始

チェーン・ジョブの開始時にチェーンを開始できるように、少なくとも1つのルールに、常にTRUEに評価される条件が必要です。このための最も簡単な方法は、スケジュール・チェーン条件の構文を使用している場合は条件を'TRUE'に設定すること、またはSQL構文を使用している場合は条件を'1=1'に設定することです。

チェーンの終了

少なくとも1つのチェーン・ルールに、'END'のactionが含まれている必要があります。チェーン・ジョブは、END処理が含まれているルールの1つがTRUEに評価されるまでは完了しません。通常は、異なるEND処理が設定された別々のルールがあり、エラー・コードを伴う場合と伴わない場合があります。

チェーンに実行するステップがなくなるか、またはイベントの発生の待機中ではなく、END処理が含まれているルールでTRUEに評価されるルールがない(またはEND処理が設定されているルールがない)場合、チェーン・ジョブの状態はCHAIN_STALLEDになります。詳細は、「停止状態チェーンの処理」を参照してください。

ルールの定義例

次の例では、ステップstep1でチェーンを開始するルールおよびstep1の完了時にステップstep2を開始するルールを定義しています。rule_nameおよびcommentsはオプションですが、デフォルトでNULLになります。rule_nameを使用する場合は、DEFINE_CHAIN_RULEに対する別の呼出しで、そのルールを後で再定義できます。新しい定義で、以前の定義が上書きされます。

BEGIN
DBMS_SCHEDULER.DEFINE_CHAIN_RULE (
chain_name   =>   'my_chain1',
condition    =>   'TRUE',
action       =>   'START step1',
rule_name    =>   'my_rule1',
comments     =>   'start the chain');
DBMS_SCHEDULER.DEFINE_CHAIN_RULE (
chain_name   =>   'my_chain1',
condition    =>   'step1 completed',
action       =>   'START step2',
rule_name    =>   'my_rule2');
END;
/

関連項目:

- DEFINE_CHAIN_RULEプロシージャおよびスケジューラのチェーン条件構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 「チェーンの作成例」

チェーン・ルールの評価間隔の設定

スケジューラでは、チェーン・ジョブの開始時と各チェーン・ステップの終了時に、すべてのチェーン・ルールが評価されます。1時間に1回など、一定の時間間隔でもルールが評価されるようにチェーンを構成できます。この機能は、時間に基づいて、またはチェーン外部での発生に基づいてチェーン・ステップを開始するのに役立ちます。次に、いくつかの例を示します。

- チェーン・ステップがリソース集中型であるため、オフピーク時に実行する必要があるとします。ステップの条件として、別のステップの完了と午後6時から午前0時までの時間の両方を設定できます。スケジューラでは、この条件がTRUEになる時期を判別するために、ルールをその都度評価する必要があります。

- ステップが、チェーン外部にある他のプロセスから表にデータが到着するまで待機する必要があるとします。このステップの条件として、別のステップの完了と行を含む特定の表の両方を設定できます。スケジューラでは、この条件がTRUEになる時期を判別するために、ルールをその都度評価する必要があります。この条件はSQL WHERE句構文を使用し、次のようになります。

':step1.state=''SUCCEEDED'' AND select count(*) from oe.sync_table > 0'

チェーンの評価間隔を設定するには、チェーンの作成時にevaluation_interval属性を設定します。この属性のデータ型はINTERVAL DAY TO SECONDです。

BEGIN
DBMS_SCHEDULER.CREATE_CHAIN (
chain_name          => 'my_chain1',
rule_set_name       => NULL,
evaluation_interval => INTERVAL '30' MINUTE,
comments            => 'Chain with 30 minute evaluation interval');
END;
/

チェーンの有効化

チェーンを有効(使用可能)にするには、ENABLEプロシージャを使用します。ジョブでチェーンを実行するには、チェーンを使用可能にする必要があります。すでに使用可能なチェーンを使用可能にしてもエラーは戻りません。

次の例では、チェーンmy_chain1が使用可能になります。

BEGIN
DBMS_SCHEDULER.ENABLE ('my_chain1');
END;
/

ENABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

注意:
チェーンは、次の場合にスケジューラによって自動的に使用禁止にされます。

- いずれかのチェーン・ステップが指し示しているプログラムが削除されている場合

- いずれかのチェーン・ステップが指し示しているネストしたチェーンが削除されている場合

- いずれかのチェーン・イベント・ステップが指し示しているイベント・スケジュールが削除されている場合

チェーン用のジョブの作成

チェーンを実行するには、RUN_CHAINプロシージャを使用するか、タイプ'CHAIN'のジョブ(チェーン・ジョブ)を作成してスケジュールする必要があります。ジョブの処理では、次の例に示すように、チェーン名を参照する必要があります。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name        => 'chain_job_1',
job_type        => 'CHAIN',
job_action      => 'my_chain1',
repeat_interval => 'freq=daily;byhour=13;byminute=0;bysecond=0',
enabled         => TRUE);
END;
/

実行中のチェーン・ジョブの各ステップには、スケジューラによって、チェーン・ジョブと同じジョブ名と所有者を設定したステップ・ジョブが作成されます。各ステップ・ジョブにはさらに、そのジョブを一意に識別するためのサブ名があります。ジョブのサブ名は、ビュー*_SCHEDULER_RUNNING_JOBS、*_SCHEDULER_JOB_LOGおよび*_SCHEDULER_JOB_RUN_DETAILSに列として組み込まれます。また、次の場合を除いて、ジョブのサブ名は通常はステップ名と同じです。

- ネストされたチェーンの場合、現在のステップ名がすでにジョブのサブ名として使用されている場合があります。この場合、スケジューラは、'_N'をステップ名の最後に追加しますが、ここで、Nはジョブのサブ名を一意にするための整数を表します。

- ステップ・ジョブの作成時にエラーが発生した場合、スケジューラは、ジョブ・サブ名を'step_name_0'に設定して、ジョブ・ログ・ビュー(*_SCHEDULER_JOB_LOGおよび*_SCHEDULER_JOB_RUN_DETAILS)にFAILEDエントリを記録します。

関連項目:

- CREATE_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

- 事前にチェーン・ジョブを作成せずにチェーンを実行する別の方法は、「チェーンの実行」を参照してください。

チェーンの削除

DROP_CHAINプロシージャを使用して、ステップとルールを含めたチェーンを削除します。次に、チェーンmy_chain1を削除する例を示します。

BEGIN
DBMS_SCHEDULER.DROP_CHAIN (
chain_name   => 'my_chain1',
force        => TRUE);
END;
/

DROP_CHAINプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

チェーンの実行

次の2つのプロシージャを使用して、チェーンを即時に実行できます。

- RUN_JOB

- RUN_CHAIN

すでにチェーン用のチェーン・ジョブを作成している場合は、RUN_JOBプロシージャを使用してそのジョブを実行(したがってチェーンを実行)できますが、RUN_JOBのuse_current_session引数をFALSEに設定する必要があります。

RUN_CHAINプロシージャを使用すると、チェーンに対するチェーン・ジョブをあらかじめ作成することなく、チェーンを実行できます。また、RUN_CHAINを使用してチェーンの一部のみを実行することもできます。

RUN_CHAINは、指定したチェーンを実行する一時ジョブを作成します。ジョブ名を指定すると、その名前のジョブが作成されますが、それ以外の場合はデフォルトのジョブ名が割り当てられます。

開始ステップ・リストを指定すると、チェーンの実行開始時にそれらのステップのみが開始されます (通常開始されるステップは、それらがリスト内にない場合は実行されません)。開始ステップのリストが提供されない場合は、チェーンが通常どおり開始されます。つまり、初期評価が行われ、実行を開始するステップが判断されます。次に、チェーンmy_chain1を即時に実行する例を示します。

BEGIN
DBMS_SCHEDULER.RUN_CHAIN (
chain_name    =>  'my_chain1',
job_name      =>  'partial_chain_job',
start_steps   =>  'my_step2, my_step4');
END;
/

関連項目:

- 「チェーンの一部実行」

- RUN_CHAINプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

チェーン・ルールの削除

チェーンからルールを削除するには、DROP_CHAIN_RULEプロシージャを使用します。次に、my_rule1を削除する例を示します。

BEGIN
DBMS_SCHEDULER.DROP_CHAIN_RULE (
chain_name   =>   'my_chain1',
rule_name    =>   'my_rule1',
force        =>   TRUE);
END;
/

DROP_CHAIN_RULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

チェーンの無効化

チェーンを無効(使用禁止)にするには、DISABLEプロシージャを使用します。次に、my_chain1を使用禁止にする例を示します。

BEGIN
DBMS_SCHEDULER.DISABLE ('my_chain1');
END;
/

DISABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

注意:
チェーンは、次の場合にスケジューラによって自動的に使用禁止にされます。

- いずれかのチェーン・ステップが指し示しているプログラムが削除されている場合

- いずれかのチェーン・ステップが指し示しているネストしたチェーンが削除されている場合

- いずれかのチェーン・イベント・ステップが指し示しているイベント・スケジュールが削除されている場合

チェーン・ステップの削除

チェーンからステップを削除するには、DROP_CHAIN_STEPプロシージャを使用します。次に、my_chain2からmy_step2を削除する例を示します。

BEGIN
DBMS_SCHEDULER.DROP_CHAIN_STEP (
chain_name   =>   'my_chain2',
step_name    =>   'my_step2',
force        =>    TRUE);
END;
/

DROP_CHAIN_STEPプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

チェーンの停止

実行中のチェーンを停止するには、DBMS_SCHEDULER.STOP_JOBをコールして、チェーン・ジョブ(チェーンを開始したジョブ)の名前を渡します。チェーン・ジョブを停止すると、実行中のチェーンの全ステップが停止され、チェーンが終了します。

STOP_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

個々のチェーン・ステップの停止

個々のチェーン・ステップを停止するには2つの方法があります。

- ルールの条件を満たしたときに1つ以上のステップを停止するチェーン・ルールの作成。

- STOP_JOBプロシージャのコール
停止するステップごとに、スキーマ名、チェーン・ジョブ名およびステップ・ジョブ・サブ名を指定する必要があります。

BEGIN
DBMS_SCHEDULER.STOP_JOB('oe.chainrunjob.stepa');
END;
/

この例では、chainrunjobはチェーン・ジョブ名で、stepaはステップ・ジョブ・サブ名です。通常、ステップ・ジョブ・サブ名はステップ名と同じですが、異なる場合もあります。ステップ・ジョブ・サブ名は、*_SCHEDULER_RUNNING_CHAINSビューのSTEP_JOB_SUBNAME列から取得できます。

チェーン・ステップを停止すると、stateがSTOPPEDに設定され、チェーン・ルールが評価されて次に実行するステップが判別されます。

STOP_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

チェーンの一時停止

チェーン全体、またはチェーンの個別ブランチを一時停止できます。そのためには、DBMS_SCHEDULER.ALTER_CHAINまたはALTER_RUNNING_CHAINを使用して、1つ以上のステップのPAUSE属性をTRUEに設定します。チェーン・ステップを一時停止すると、チェーンの実行をそのステップの実行後に一時停止できます。

ステップを一時停止すると、そのステップの実行後にstate属性がPAUSEDに変わりますが、completed属性はFALSEのままです。そのため、一時停止したステップの完了に依存しているステップは実行されません。一時停止したステップのPAUSE属性をFALSEにリセットすると、state属性が完了状態(SUCCEEDED、FAILEDまたはSTOPPED)に設定され、一時停止したステップの完了を待機しているステップを実行できるようになります。

図29-1 ステップ3で一時停止したチェーン

図29-1では、ステップ3が一時停止されています。ステップ3の一時停止が解除されるまで、ステップ5は実行されません。ステップ2のみを一時停止した場合、ステップ4、6および7は実行されません。ただし、ステップ1、3および5は実行できます。いずれの場合も、チェーンのブランチを1つのみ一時停止することになります。

チェーン全体を一時停止するには、チェーンのステップをすべて一時停止します。チェーンの一時停止を解除するには、チェーン・ステップの1つ、多数またはすべての一時停止を解除します。図29-1のチェーンでは、ステップ1を一時停止すると、ステップ1の実行後にチェーン全体も一時停止します。

関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_SCHEDULER.ALTER_CHAINおよびDBMS_SCHEDULER.ALTER_RUNNING_CHAINプロシージャに関する項を参照してください。

チェーン・ステップのスキップ

チェーンの1つ以上のステップをスキップできます。そのためには、DBMS_SCHEDULER.ALTER_CHAINまたはALTER_RUNNING_CHAINを使用して、1つ以上のステップのSKIP属性をTRUEに設定します。ステップのSKIP属性がTRUEの場合、そのステップを実行するためのチェーン条件を満たすと、そのステップは実行されるかわりに、即時に成功した場合と同様に処理されます。SKIPをTRUEに設定しても、実行中のステップ、遅延後に実行するようにスケジュールされているステップまたは実行済のステップには影響しません。

ステップのスキップが特に役立つのは、チェーンのテスト時です。たとえば、図29-1に示したチェーンをテストする際に、ステップ7をスキップすると、このステップはネストしたチェーンであるため、テスト時間を大幅に短縮できます。

チェーンの一部実行

チェーンの一部のみを実行するには2つの方法があります。

- ALTER_CHAINプロシージャを使用して、1つ以上のステップに対してPAUSE属性をTRUEに設定してから、RUN_JOBでチェーン・ジョブを起動するか、RUN_CHAINでチェーンを起動します。一時停止しているステップに依存するステップは実行されません。(ただし、一時停止しているステップは実行されます。)
この方法のデメリットは、チェーンを将来実行する場合に備えて、影響を受けるステップのPAUSE属性の設定をFALSEに戻す必要があることです。

- RUN_CHAINプロシージャを使用して、実行しないステップをスキップし、チェーンの特定ステップのみを開始します。
この方法の方が簡単であり、ステップの開始前に初期状態を設定することもできます。

この2つの方法の両方を使用して、チェーンの開始時と終了時の両方でステップをスキップすることが必要な場合もあります。

詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のRUN_CHAINプロシージャに関する項を参照してください。

関連項目:
「チェーン・ステップのスキップ」

実行中のチェーンの監視

次の2つのビューを使用して、実行中のチェーンのステータスを表示できます。

*_SCHEDULER_RUNNING_JOBS
*_SCHEDULER_RUNNING_CHAINS

*_SCHEDULER_RUNNING_JOBSビューには、チェーン・ジョブに関する1行と実行中の各ステップに関する1行が含まれています。*_SCHEDULER_RUNNING_CHAINSビューには、各チェーン・ステップ(ネストしたチェーンを含む)に関する1行と、各ステップの実行ステータス(NOT_STARTED、RUNNING、STOPPED、SUCCEEDEDなど)が含まれています。

これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

停止状態チェーンの処理

ステップの完了時には、常にチェーン・ルールが評価され、次に実行するステップが判別されます。いずれのルールでも別のステップが開始されず、チェーンが終了せず、チェーンのevaluation_intervalがNULLの場合は、チェーンがstalled状態になります。チェーンが停止状態になっている場合、実行中のステップはありません。また、(指定の時間間隔だけ待機した後に)実行するようにスケジュールされているステップや、イベントを待機中のイベント・ステップもありません。この場合、チェーンを実行しているジョブの状態はCHAIN_STALLEDに設定されます。(ただし、ジョブは*_SCHEDULER_RUNNING_JOBSビューにリストされたままです)。

停止状態のチェーンの問題を解決するには、ビューALL_SCHEDULER_RUNNING_CHAINS(チェーン(ネストしたチェーンを含む)内のすべてのステップの状態が示されます)とビューALL_SCHEDULER_CHAIN_RULES(すべてのチェーン・ルールが含まれます)が使用されます。

ALTER_RUNNING_CHAINプロシージャを使用していずれかのステップのstateを変更すると、チェーンの実行を継続できます。たとえば、ステップ11がステップ9の正常終了まで待機してから開始するようになっており、状態の変更がこれに関係する場合、ステップ9のstateを'SUCCEEDED'に設定することもできます。

あるいは、1つ以上のルールが正しくない場合は、DEFINE_CHAIN_RULEプロシージャを使用して、(同じルール名を使用して)それらのルールを置換するか、または新規ルールを作成できます。新規および更新したルールは、実行中のチェーンと次回以降のすべてのチェーン実行に適用されます。ルールの追加または更新後は、停止状態のチェーン・ジョブでEVALUATE_RUNNING_CHAINを実行し、必要な処理をトリガーする必要があります。

ジョブの優先度付け

3つのスケジューラ・ジョブ(ジョブ・クラス、ウィンドウおよびウィンドウ・グループ)を使用して、Oracle Schedulerジョブに優先度を付けます。これらのオブジェクトでは、ジョブをデータベース・リソース・マネージャのコンシューマ・グループに関連付けることによって、ジョブに優先度を付けます。これにより、これらのジョブに割り当てられるリソースの量が制御されます。また、ジョブ・クラスでは、グループ内のすべてのジョブに同一のリソース・レベルが割り当てられている場合に、ジョブのグループ間に相対的な優先度を設定できます。

この項の内容は次のとおりです。

- ジョブ・クラスのジョブ優先度の管理

- ジョブ・クラス内でのジョブの相対的な優先度の設定

- ウィンドウを使用したジョブ・スケジューリングとジョブ優先度の管理

- ウィンドウ・グループを使用したジョブ・スケジューリングとジョブ優先度の管理

- リソース・マネージャを使用したジョブ間のリソース割当て

- ジョブに対するリソース割当ての例

関連項目:
第27章「Oracle Database Resource Managerを使用したリソースの管理」

ジョブ・クラスのジョブ優先度の管理

ジョブ・クラスでは、ジョブをグループ化して優先度を付けることができます。また、メンバー・ジョブに一連の属性値を簡単に割り当てることができます。ジョブ・クラスは、データベース・リソース・マネージャに関連するジョブ・クラス属性を通して各メンバー・ジョブの優先度に影響します。詳細は、「リソース・マネージャを使用したジョブ間のリソース割当て」を参照してください。

データベースとともに作成されるデフォルトのジョブ・クラスがあります。ジョブ・クラスを指定せずにジョブを作成すると、ジョブはこのデフォルトのジョブ・クラス(DEFAULT_JOB_CLASS)に割り当てられます。デフォルトのジョブ・クラスでは、EXECUTE権限がPUBLICに付与されているため、ジョブの作成権限を持つすべてのデータベース・ユーザーは、デフォルトのジョブ・クラスにジョブを作成できます。

この項では、ジョブ・クラスの基本的なタスクについて説明します。この項の内容は、次のとおりです。

- ジョブ・クラスのタスクとそのプロシージャ

- ジョブ・クラスの作成

- ジョブ・クラスの変更

- ジョブ・クラスの削除

関連項目:
ジョブ・クラスの概要については、「ジョブ・クラス」を参照してください。

ジョブ・クラスのタスクとそのプロシージャ

表29-8に、ジョブ・クラスの一般的なタスクとそれに対応するプロシージャおよび権限を示します。

表29-8 ジョブ・クラスのタスクとそのプロシージャ

タスク

プロシージャ

必要な権限

ジョブ・クラスの作成

CREATE_JOB_CLASS

MANAGE SCHEDULER

ジョブ・クラスの変更

SET_ATTRIBUTE

MANAGE SCHEDULER

ジョブ・クラスの削除

DROP_JOB_CLASS

MANAGE SCHEDULER

権限の詳細は、「スケジューラ権限」を参照してください。

ジョブ・クラスの作成

ジョブ・クラスを作成するには、CREATE_JOB_CLASSプロシージャまたはEnterprise Managerを使用します。ジョブ・クラスは、常にSYSスキーマに作成されます。

次の文では、すべての財務ジョブ用のジョブ・クラスが作成されます。

BEGIN
DBMS_SCHEDULER.CREATE_JOB_CLASS (
job_class_name             =>  'finance_jobs',
resource_consumer_group    =>  'finance_group');
END;
/

このジョブ・クラス内のすべてのジョブは、finance_groupリソース・コンシューマ・グループに割り当てられます。

ジョブ・クラスを問い合せるには、*_SCHEDULER_JOB_CLASSESビューを使用します。

関連項目:
「リソース・コンシューマ・グループの概要」

ジョブ・クラスの変更

ジョブ・クラスを変更するには、SET_ATTRIBUTEプロシージャまたはEnterprise Managerを使用します。また、ジョブ・クラス名以外のすべての属性を変更できます。ジョブ・クラスの属性は、*_SCHEDULER_JOB_CLASSESビューで使用可能です。

ジョブ・クラスを変更した場合、そのクラスに属する実行中のジョブには影響しません。この変更は、今後実行されるジョブに対してのみ有効です。

ジョブ・クラスの削除

1つ以上のジョブ・クラスを削除するには、DROP_JOB_CLASSプロシージャまたはEnterprise Managerを使用します。ジョブ・クラスの削除とは、そのジョブ・クラスのすべてのメタデータをデータベースから削除することです。

DROP_JOB_CLASSプロシージャ・コールにジョブ・クラス名のカンマ区切りのリストを指定することで、1回のコールで複数のジョブ・クラスを削除できます。たとえば、次の文では3つのジョブ・クラスが削除されます。

BEGIN
DBMS_SCHEDULER.DROP_JOB_CLASS('jobclass1, jobclass2, jobclass3');
END;
/

ジョブ・クラス内でのジョブの相対的な優先度の設定

SET_ATTRIBUTEプロシージャを使用して、同じジョブ・クラス内でジョブの相対的な優先度を変更できます。ジョブの優先度は、1を最も高い優先度として1から5の範囲で設定する必要があります。たとえば、次の文では、my_job1のジョブ優先度の設定が1に変更されます。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE (
name           =>   'my_emp_job1',
attribute      =>   'job_priority',
value          =>   1);
END;
/

属性が変更されたことを確認するには、次の文を発行します。

SELECT JOB_NAME, JOB_PRIORITY FROM DBA_SCHEDULER_JOBS;

JOB_NAME                       JOB_PRIORITY
------------------------------ ------------
MY_EMP_JOB                                3
MY_EMP_JOB1                               1
MY_NEW_JOB1                               3
MY_NEW_JOB2                               3
MY_NEW_JOB3                               3

システムにおけるジョブの全体的な優先度は、最初に、そのジョブのジョブ・クラスが割り当てられているリソース・コンシューマ・グループと現行のリソース・プランの組合せによって決定され、次に、ジョブ・クラス内の相対的な優先度によって決定されます。

関連項目:

- 「リソース・マネージャを使用したジョブ間のリソース割当て」

- SET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ウィンドウを使用したジョブ・スケジューリングとジョブ優先度の管理

ウィンドウを使用すると、異なる時間帯で別々のリソース・プランを自動的にアクティブにできます。ジョブを実行すると、そのジョブに割り当てられているリソースが、リソース・プランの変更時に変わることがわかります。ジョブは、そのschedule_name属性でウィンドウを指定できます。スケジューラは、このウィンドウがオープンしているジョブを開始します。ウィンドウには、ワークロード・サイクル中の様々な時間にオープンできるように、スケジュールが関連付けられます。

ウィンドウの主な属性は次のとおりです。

- スケジュール
ウィンドウが有効である時期を制御します。

- 継続時間
ウィンドウがオープンしている長さを制御します。

- リソース・プラン
ウィンドウのオープン時にアクティブ化されるリソース・プランの名前を設定します。

特定の時間に有効にできるウィンドウは1つのみです。ウィンドウはSYSスキーマに属します。

すべてのウィンドウ・アクティビティは、*_SCHEDULER_WINDOW_LOGビュー(ウィンドウ・ログと呼ばれます)に記録されます。ウィンドウ・ログの記録例は、「ウィンドウ・ログ」を参照してください。

この項では、ウィンドウの基本的なタスクについて説明します。この項の内容は、次のとおりです。

- ウィンドウのタスクとそのプロシージャ

- ウィンドウの作成

- ウィンドウの削除

- ウィンドウのオープン

- ウィンドウのクローズ

- ウィンドウの削除

- ウィンドウの無効化

- ウィンドウの有効化

関連項目:
ウィンドウの概要については、「ウィンドウ」を参照してください。

ウィンドウのタスクとそのプロシージャ

表29-9に、ウィンドウの一般的なタスクとその処理に使用するプロシージャを示します。

表29-9 ウィンドウのタスクとそのプロシージャ

タスク

プロシージャ

必要な権限

ウィンドウの作成

CREATE_WINDOW

MANAGE SCHEDULER

ウィンドウのオープン

OPEN_WINDOW

MANAGE SCHEDULER

ウィンドウのクローズ

CLOSE_WINDOW

MANAGE SCHEDULER

ウィンドウの変更

SET_ATTRIBUTE

MANAGE SCHEDULER

ウィンドウの削除

DROP_WINDOW

MANAGE SCHEDULER

ウィンドウの使用禁止

DISABLE

MANAGE SCHEDULER

ウィンドウの使用可能化

ENABLE

MANAGE SCHEDULER

権限の詳細は、「スケジューラ権限」を参照してください。

ウィンドウの作成

ウィンドウを作成するには、Enterprise ManagerまたはDBMS_SCHEDULER.CREATE_WINDOWパッケージ・プロシージャを使用します。パッケージ・プロシージャを使用する場合は、resource_planパラメータをNULLのままにできることです。この場合は、ウィンドウのオープン時に現行のプランが有効のままになります。

ウィンドウを作成するには、MANAGE SCHEDULER権限が必要です。

ウィンドウにスケジュールを指定する場合、スケジューラではそのスケジュールにウィンドウがすでに定義されているかどうかはチェックされません。したがって、複数のウィンドウが重複する場合があります。また、繰返し間隔としてPL/SQL式が設定されている名前付きスケジュールの使用は、ウィンドウに対してはサポートされていません。

ウィンドウ属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のCREATE_WINDOWプロシージャに関する項を参照してください。

次の例では、営業時間中にmixed_workload_planリソース・プランを有効にするdaytimeというウィンドウを作成しています。

BEGIN
DBMS_SCHEDULER.CREATE_WINDOW (
window_name      => 'daytime',
resource_plan    => 'mixed_workload_plan',
start_date       => '28-APR-09 08.00.00 AM',
repeat_interval  => 'freq=daily; byday=mon,tue,wed,thu,fri',
duration         => interval '9' hour,
window_priority  => 'low',
comments         => 'OLTP transactions have priority');
END;
/

ウィンドウが正しく作成されたことを検証するには、DBA_SCHEDULER_WINDOWSビューを問い合せます。次に、文の発行例を示します。

SELECT WINDOW_NAME, RESOURCE_PLAN, DURATION, REPEAT_INTERVAL FROM DBA_SCHEDULER_WINDOWS;

WINDOW_NAME   RESOURCE_PLAN         DURATION       REPEAT_INTERVAL
-----------   -------------------   -------------  ---------------
DAYTIME       MIXED_WORKLOAD_PLAN   +000 09:00:00  freq=daily; byday=mon,tue,wed,thu,fri

ウィンドウの変更

ウィンドウを変更するには、その属性を変更します。そのためには、SET_ATTRIBUTEおよびSET_ATTRIBUTE_NULLプロシージャまたはEnterprise Managerを使用します。変更するときは、WINDOW_NAME以外のすべてのウィンドウ属性を変更できます。ウィンドウ属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のCREATE_WINDOWプロシージャに関する項を参照してください。

ウィンドウを変更した場合、アクティブ・ウィンドウには影響しません。この変更は、次回ウィンドウをオープンするときからのみ有効になります。

すべてのウィンドウを変更できます。使用禁止のウィンドウを変更した場合は、変更した後も使用禁止のままです。使用可能なウィンドウは自動的に使用禁止になり、変更後、使用可能化プロセスで実行される妥当性チェックが成功した場合は再び使用可能になります。

SET_ATTRIBUTEおよびSET_ATTRIBUTE_NULLプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ウィンドウのオープン

ウィンドウがオープンすると、スケジューラは、ウィンドウの作成時に関連付けられたリソース・プランに切り替えます。ウィンドウのオープン時に実行中のジョブがある場合、そのジョブに割り当てられているリソースはリソース・プランの切替えによって変更される場合があります。

ウィンドウをオープンする方法は、次の2通りあります。

- ウィンドウのスケジュールに基づいたオープン

- OPEN_WINDOWプロシージャを使用した手動オープン
このプロシージャは、スケジュールとは関係なくウィンドウをオープンします。ウィンドウがオープンし、関連付けられたリソース・プランが即時に有効になります。手動でオープンできるのは、使用可能なウィンドウのみです。

OPEN_WINDOWプロシージャで、duration属性を使用して、ウィンドウがオープンしている時間の長さを指定できます。継続時間の型はINTERVAL DAY TO SECONDです。継続時間の指定がない場合、ウィンドウはそのウィンドウに保存されている通常の継続時間の間オープン状態です。

手動によるウィンドウのオープンは、通常のスケジュール・ウィンドウの実行には影響しません。

手動でオープンしたウィンドウをクローズする場合で、クローズするときに他のウィンドウもある場合、どのウィンドウをオープンするかを決定するために、オーバーラップ・ウィンドウのルールが適用されます。

すでにオープンしているウィンドウがある場合でも、OPEN_WINDOWコールまたはEnterprise ManagerでforceオプションをTRUEに設定すると、ウィンドウを強制的にオープンできます。

forceオプションがTRUEに設定されているときは、その時点でオープンしているウィンドウの優先度の方が高い場合でも、スケジューラはウィンドウを自動的にクローズします。この手動でオープンしたウィンドウの継続時間中は、Schedulerにより他のスケジュール・ウィンドウはオープンされません(より優先順位の高いウィンドウもオープンされません)。すでにオープンしているウィンドウをオープンできます。この場合、ウィンドウは、OPEN_WINDOWコマンドが発行された時点から、コールで指定された継続時間の間オープンしたままになります。

これを示す例を考えます。window1は、4時間の期間という設定で作成されました。もう2時間オープンしています。この時点でOPEN_WINDOW呼出しを使用してwindow1を再びオープンし、期間を指定しないと、window1には4時間という期間が設定されるため、もう4時間オープンすることになります。30分という期間を指定すると、ウィンドウは30分でクローズします。

ウィンドウがオープンすると、ウィンドウ・ログにエントリが作成されます。

現在のリソース・プランが、ALTER SYSTEM文FORCEオプションあるいはDBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャのallow_scheduler_plan_switches引数FALSEを使用して、手動で切り替えられたものである場合、ウィンドウでリソース・プランの切替えに失敗する可能性があります。この場合、リソース・プランの切替え失敗がウィンドウ・ログに書き込まれます。

OPEN_WINDOWおよびDBMS_RESOURCE_MANAGER.SWITCH_PLANプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ウィンドウのクローズ

ウィンドウをクローズする方法は、次の2通りあります。

- スケジュールに基づいたクローズ
ウィンドウは作成時に定義されたスケジュールに基づいてクローズします。

- CLOSE_WINDOWプロシージャを使用した手動クローズ
CLOSE_WINDOWプロシージャは、オープン中のウィンドウを期間終了前にクローズします。

ウィンドウはクローズすると無効になります。ウィンドウがクローズすると、スケジューラは、リソース・プランをそのウィンドウ期間外で有効だったリソース・プランに切り替えるか、またはウィンドウの重複がある場合は別のウィンドウに切り替えます。存在しないウィンドウ、またはオープンしていないウィンドウをクローズしようとすると、エラーが発生します。

実行中のジョブは、そのジョブが実行されているウィンドウがクローズした場合でも、stop_on_window_close属性がジョブの作成時にTRUEに設定されていないかぎりクローズしません。ただし、リソース・プランが変更される場合があるため、ジョブに割り当てられているリソースは変更される可能性があります。

実行中のジョブにスケジュールとしてウィンドウ・グループが設定されていると、そのジョブは、同じウィンドウ・グループのメンバーである別のウィンドウが元のウィンドウのクローズ時にアクティブになった場合、停止しません。これは、stop_on_window_close属性がTRUEに設定された状態でジョブが作成されている場合でも同じです。

ウィンドウがクローズ状態になると、ウィンドウ・ログDBA_SCHEDULER_WINDOW_LOGにエントリが追加されます。

CLOSE_WINDOWプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ウィンドウの削除

1つ以上のウィンドウを削除するには、DROP_WINDOWプロシージャまたはEnterprise Managerを使用します。ウィンドウが削除されると、そのウィンドウに関するすべてのメタデータが*_SCHEDULER_WINDOWSビューから削除されます。また、ウィンドウに対するすべての参照がウィンドウ・グループから削除されます。

DROP_WINDOWプロシージャにウィンドウ名またはウィンドウ・グループ名のカンマ区切りのリストを指定すると、1回のコールで複数のウィンドウを削除できます。たとえば、次の文ではウィンドウとウィンドウ・グループの両方が削除されます。

BEGIN
DBMS_SCHEDULER.DROP_WINDOW ('window1, window2, window3,
windowgroup1, windowgroup2');
END;
/

ウィンドウ・グループ名を指定した場合、ウィンドウ・グループ内のウィンドウは削除されますが、ウィンドウ・グループは削除されません。ウィンドウ・グループを削除するには、DROP_WINDOW_GROUPプロシージャを使用する必要があります。

DROP_WINDOWプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

ウィンドウの無効化

1つ以上のウィンドウを無効(使用禁止)にするには、DISABLEプロシージャまたはEnterprise Managerを使用します。そのため、ウィンドウはオープンしません。ただし、ウィンドウのメタデータは依然存在するため、再び使用可能に設定できます。DISABLEプロシージャは複数のスケジューラ・オブジェクトに対して使用されるため、ウィンドウを使用禁止にするときは、先頭にSYSを付ける必要があります。

ウィンドウは他の理由で使用禁止になる場合もあります。たとえば、ウィンドウはそのスケジュールの終了時に使用禁止になります。また、存在しないスケジュールをウィンドウが指し示している場合も使用禁止になります。

スケジュールとしてウィンドウが設定されているジョブがある場合、そのウィンドウは、プロシージャ・コールでforceをTRUEに設定しないかぎり、使用禁止にできません。デフォルトでは、forceはFALSEに設定されます。ウィンドウが使用禁止の場合、このウィンドウがスケジュールとして設定されているジョブを使用禁止にすることはできません。

DISABLEプロシージャ・コールにウィンドウ名またはウィンドウ・グループ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウを使用禁止にすることもできます。たとえば、次の文ではウィンドウとウィンドウ・グループの両方が使用禁止になります。

BEGIN
DBMS_SCHEDULER.DISABLE ('sys.window1, sys.window2,
sys.window3, sys.windowgroup1, sys.windowgroup2');
END;
/

DISABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ウィンドウの有効化

1つ以上のウィンドウを有効(使用可能)にするには、ENABLEプロシージャまたはEnterprise Managerを使用します。使用可能なウィンドウとは、オープン可能なウィンドウのことです。ウィンドウは、デフォルトでenabledで作成されます。ENABLEプロシージャを使用してウィンドウを使用可能にすると、妥当性チェックが実行され、このチェックが成功した場合のみウィンドウは使用可能になります。ウィンドウが使用可能になると、ウィンドウ・ログ表にログが記録されます。ENABLEプロシージャは複数のスケジューラ・オブジェクトに対して使用されるため、ウィンドウを使用可能にするときは、先頭にSYSを付ける必要があります。

ウィンドウ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウを使用可能にできます。たとえば、次の文では3つのウィンドウが使用可能になります。

BEGIN
DBMS_SCHEDULER.ENABLE ('sys.window1, sys.window2, sys.window3');
END;
/

ENABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ウィンドウ・グループを使用したジョブ・スケジューリングとジョブ優先度の管理

ウィンドウ・グループを使用すると、1日あるいは1週間などの間に複数期間実行するジョブを簡単にスケジュールできます。ウィンドウ・グループを作成してウィンドウをグループに加え、ウィンドウ・グループ名をジョブのschedule_name属性に設定すると、ジョブがウィンドウ・グループ内のすべてのウィンドウの指定期間に実行されます。

ウィンドウ・グループはSYSスキーマにあります。この項では、基本的なウィンドウ・グループ・タスクについて説明します。この項の内容は、次のとおりです。

- ウィンドウ・グループのタスクとそのプロシージャ

- ウィンドウ・グループの作成

- ウィンドウ・グループの削除

- ウィンドウ・グループへのメンバーの追加

- ウィンドウ・グループからのメンバーの削除

- ウィンドウ・グループの有効化

- ウィンドウ・グループの無効化

関連項目:
ウィンドウ・グループの概要については、「ウィンドウ・グループ」を参照してください。

ウィンドウ・グループのタスクとそのプロシージャ

表29-10に、ウィンドウ・グループの一般的なタスクとその処理に使用するプロシージャを示します。

表29-10 ウィンドウ・グループのタスクとそのプロシージャ

タスク

プロシージャ

必要な権限

ウィンドウ・グループの作成

CREATE_GROUP

MANAGE SCHEDULER

ウィンドウ・グループの削除

DROP_GROUP

MANAGE SCHEDULER

ウィンドウ・グループへのメンバーの追加

ADD_GROUP_MEMBER

MANAGE SCHEDULER

ウィンドウ・グループからのメンバーの削除

REMOVE_GROUP_MEMBER

MANAGE SCHEDULER

ウィンドウ・グループの有効化

ENABLE

MANAGE SCHEDULER

ウィンドウ・グループの無効化

DISABLE

MANAGE SCHEDULER

権限の詳細は、「スケジューラ権限」を参照してください。

ウィンドウ・グループの作成

ウィンドウ・グループを作成するには、DBMS_SCHEDULER.CREATE_GROUPプロシージャを使用して、グループ・タイプとしてWINDOWを指定します。グループのメンバー・ウィンドウは、グループの作成時に指定するか、または後でADD_GROUP_MEMBERプロシージャを使用して追加できます。ウィンドウ・グループは、他のウィンドウ・グループのメンバーになれません。ただし、メンバーを設定しないウィンドウ・グループは作成できます。

ウィンドウ・グループを作成し、存在しないメンバー・ウィンドウを指定すると、エラーが生成され、ウィンドウ・グループは作成されません。ウィンドウがすでにウィンドウ・グループのメンバーである場合、再度追加されることはありません。

ウィンドウ・グループはSYSスキーマで作成します。ウィンドウ・グループは、ウィンドウと同様に、PUBLICへのアクセス権を伴って作成されるため、ウィンドウ・グループへのアクセス権限は必要ありません。

次の文では、downtimeというウィンドウ・グループが作成され、2つのウィンドウ(weeknightsとweekends)が追加されます。

BEGIN
DBMS_SCHEDULER.CREATE_GROUP (
group_name   =>  'downtime',
group_type   =>  'WINDOW',
member       =>  'weeknights, weekends');
END;
/

ウィンドウ・グループの内容を確認するには、MANAGE SCHEDULER権限を持つユーザーとして次の問合せを発行します。

SELECT group_name, enabled, number_of_members FROM dba_scheduler_groups
WHERE group_type = 'WINDOW';

GROUP_NAME     ENABLED  NUMBER_OF_MEMBERS
-------------- -------- -----------------
DOWNTIME       TRUE                     2

SELECT group_name, member_name FROM dba_scheduler_group_members;

GROUP_NAME      MEMBER_NAME
--------------- --------------------
DOWNTIME        "SYS"."WEEKENDS"
DOWNTIME        "SYS"."WEEKNIGHTS"

ウィンドウ・グループの削除

1つ以上のウィンドウ・グループを削除するには、DROP_GROUPプロシージャを使用します。このプロシージャをコールすると、ウィンドウ・グループは削除されますが、ウィンドウ・グループのメンバーであるウィンドウは削除されません。ウィンドウ・グループ自体は削除せずに、ウィンドウ・グループのメンバーであるウィンドウをすべて削除するには、DROP_WINDOWプロシージャを使用し、そのコールにウィンドウ・グループ名を指定します。

DROP_GROUPプロシージャ・コールにウィンドウ・グループ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウ・グループを削除できます。各ウィンドウ・グループ名の前にSYSスキーマの接頭辞を付ける必要があります。たとえば、次の文では3つのウィンドウ・グループが削除されます。

BEGIN
DBMS_SCHEDULER.DROP_GROUP('sys.windowgroup1, sys.windowgroup2, sys.windowgroup3');
END;
/

ウィンドウ・グループへのメンバーの追加

ウィンドウ・グループにウィンドウを追加するには、ADD_GROUP_MEMBERプロシージャを使用します。

ウィンドウのカンマ区切りのリストを指定すると、1回のコールで複数のメンバーをウィンドウ・グループに追加できます。たとえば、次の文ではウィンドウ・グループwindow_group1に2つのウィンドウが追加されます。

BEGIN
DBMS_SCHEDULER.ADD_GROUP_MEMBER ('sys.windowgroup1','window2, window3');
END;
/

すでにオープンしているウィンドウがウィンドウ・グループに追加された場合、スケジューラは、ウィンドウ・グループ内の次のウィンドウがオープンするまで、このウィンドウ・グループを指し示すジョブを開始しません。

ウィンドウ・グループからのメンバーの削除

ウィンドウ・グループから1つ以上のウィンドウを削除するには、REMOVE_GROUP_MEMBERプロシージャを使用します。stop_on_window_closeフラグが設定されているジョブが停止するのは、ウィンドウがクローズするときのみです。オープン中のウィンドウをウィンドウ・グループから削除しても、この処理への影響はありません。

ウィンドウのカンマ区切りのリストを指定すると、1回のコールで複数のメンバーをウィンドウ・グループから削除できます。たとえば、次の文では2つのウィンドウが削除されます。

BEGIN
DBMS_SCHEDULER.REMOVE_GROUP_MEMBER('sys.window_group1', 'window2, window3');
END;
/

ウィンドウ・グループの有効化

1つ以上のウィンドウ・グループを有効(使用可能)にするには、ENABLEプロシージャを使用します。デフォルトでは、ウィンドウ・グループはENABLEDで作成されます。次に例を示します。

BEGIN
DBMS_SCHEDULER.ENABLE('sys.windowgroup1, sys.windowgroup2, sys.windowgroup3');
END;
/

ウィンドウ・グループの無効化

ウィンドウ・グループを無効(使用禁止)にするには、DISABLEプロシージャを使用します。ウィンドウ・グループがスケジュールとして使用禁止になっているジョブは、メンバー・ウィンドウがオープンしても実行されません。ウィンドウ・グループを使用禁止にしても、そのメンバー・ウィンドウは使用禁止になりません。

また、ウィンドウ・グループ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウ・グループを使用禁止にすることもできます。たとえば、次の文では3つのウィンドウ・グループが使用禁止になります。

BEGIN
DBMS_SCHEDULER.DISABLE('sys.windowgroup1, sys.windowgroup2, sys.windowgroup3');
END;
/

リソース・マネージャを使用したジョブ間のリソース割当て

データベース・リソース・マネージャ(リソース・マネージャ)は、データベース・セッション間のリソースの割当て方法を制御します。スケジューラ・ジョブのような非同期セッションだけでなく、ユーザー・セッションのような同期セッションも制御します。データベースのすべての「作業単位」をリソース・コンシューマ・グループにグループ化し、リソース・プランを使用して、様々なコンシューマ・グループ間のリソースの割当て方法を指定します。リソース・マネージャが割り当てる主なシステム・リソースはCPUです。

スケジューラ・ジョブの場合、最初に各ジョブをジョブ・クラスに割り当てて、次にジョブ・クラスをコンシューマ・グループに関連付けることによって、リソースが割り当てられます。その後、リソースは、コンシューマ・グループ内のスケジューラ・ジョブと他のセッションとの間で分配されます。また、ジョブ・クラス内のジョブに相対的な優先度を割り当てて、それに従ってそれらのジョブにリソースが分配されるようにすることもできます。

現行のリソース・プランはいつでも手動で変更できます。かわりに、スケジューラ・ウィンドウを作成することで現行のリソース・プランを変更することもできます。ウィンドウには、リソース・プラン属性があります。ウィンドウがオープンすると、現行のプランがウィンドウのリソース・プランに切り替えられます。

スケジューラは、完了に必要なリソースを確保できないまま同時に多数のジョブを実行するかわりに、少なくとも一部のジョブを完了できるように、同時に実行するジョブの数を制限しようとします。

スケジューラとリソース・マネージャは緊密に統合されています。ジョブ・コーディネータは、リソース・マネージャからデータベース・リソースの可用性を取得します。その情報に基づいて、コーディネータは、開始するジョブの数を決定します。実行するために十分なリソースがあるジョブ・クラスのジョブのみを起動します。コンシューマ・グループに割り当てられた最大リソースに到達したとリソース・マネージャが判断するまで、そのコンシューマ・グループにマップされた特定のジョブ・クラスのジョブをコーディネータが起動し続けます。そのため、実行準備が完了したジョブがジョブ表にあっても、ジョブを実行するリソースがないため、ジョブ・コーディネータに取り出されない場合があります。そのため、スケジュールされた正確な時刻にジョブが実行される保証はありません。コーディネータは、どのコンシューマ・グループにまだ使用可能なリソースがあるかに基づいて、ジョブ表からジョブを取り出します。

リソース・マネージャでは、実行中の各ジョブに割り当てられているリソースを指定のリソース・プランに基づいて継続的に管理します。リソース・マネージャが管理できるのはデータベースのプロセスのみであることに注意してください。リソースのアクティブな管理は、外部ジョブには適用されません。

注意:
リソース・マネージャがアクティブになるのは、CPU使用率が100%に近づいた場合のみです。

関連項目:
第27章「Oracle Database Resource Managerを使用したリソースの管理」

ジョブに対するリソース割当ての例

次の例は、リソースがジョブに割り当てられる方法を示しています。アクティブなリソース・プランの名前が「Night Plan」で、コンシューマ・グループDWにマップするJC1、コンシューマ・グループOLTPにマップするJC2およびデフォルト・コンシューマ・グループにマップするJC3の3つのジョブ・クラスがあるとします。図29-2は、このシナリオを簡単な図で表したものです。

図29-2 リソース・プランの例

このリソース・プランでは、ジョブ・クラスJC1に属するジョブが明らかに優先されます。コンシューマ・グループDWはリソースを60%取得するため、ジョブ・クラスJC1に属するジョブはリソースを60%取得します。コンシューマ・グループOLTPはリソースを30%取得するため、ジョブ・クラスJC2内のジョブはリソースを30%取得します。コンシューマ・グループOtherでは、他のすべてのコンシューマ・グループがリソースを10%取得することが指定されます。そのため、ジョブ・クラスJC3に属するすべてのジョブが、10%のリソースを共有し、リソースを最大10%取得できます。

あるコンシューマ・グループで未使用のリソースは、他のコンシューマ・グループで使用できます。したがって、ジョブ・クラスJC1のジョブが割当ての60%を完全に使用していない場合、その未使用部分はクラスJC2とJC3のジョブが使用できます。リソース・マネージャは、CPU使用が100%に達するまで、リソース使用の制限を開始しません。詳細は、第27章のOracle Database Resource Managerを使用したリソースの管理を参照してください。

ジョブの監視

スケジューラ・ジョブは、次のいくつかの方法で監視できます。

- ジョブ・ログの表示
ジョブ・ログには、*_SCHEDULER_JOB_LOGおよび*_SCHEDULER_JOB_RUN_DETAILSデータ・ディクショナリ・ビューが含まれます。

* = {DBA|ALL|USER}

「ジョブ・ログの表示」を参照してください。

- 追加のデータ・ディクショナリ・ビューの問合せ
DBA_SCHEDULER_RUNNING_JOBSやDBA_SCHEDULER_RUNNING_CHAINSなどのビューを問い合せて、実行中のジョブとチェーンのステータスおよび詳細を表示します。

- スケジューラからジョブ状態イベントを受け取るアプリケーションの作成
「スケジューラによって呼び出されるイベントによるジョブ状態の監視」を参照してください。

- 状態変化に応じて電子メール通知を送信するジョブの構成
「電子メール通知によるジョブ状態の監視」を参照してください。

ジョブ・ログの表示

ジョブの実行、状態変化および失敗について、ジョブ・ログ内の情報を表示できます。ジョブ・ログには、ローカル・ジョブとリモート・ジョブの両方の結果が示されます。ジョブ・ログは、次の2つのデータ・ディクショナリ・ビューとして実装されます。

- *_SCHEDULER_JOB_LOG

- *_SCHEDULER_JOB_RUN_DETAILS

スケジューラは、有効なロギング・レベルに応じて、ジョブの実行時、作成時、削除時、有効化時などにジョブ・ログ・エントリを作成できます。繰返しスケジュールが設定されたジョブの場合、スケジューラではジョブ・ログ(ジョブ・インスタンスごとに1つ)に複数のエントリが作成されます。各ログ・エントリは、ジョブの完了ステータスなど、特定の実行に関する情報を提供します。

次の例では、max_runs属性の値が4に設定されている繰返しジョブのジョブ・ログ・エントリを示しています。

SELECT job_name, job_class, operation, status FROM USER_SCHEDULER_JOB_LOG;

JOB_NAME         JOB_CLASS            OPERATION       STATUS
---------------- -------------------- --------------- ----------
JOB1             CLASS1               RUN             SUCCEEDED
JOB1             CLASS1               RUN             SUCCEEDED
JOB1             CLASS1               RUN             SUCCEEDED
JOB1             CLASS1               RUN             SUCCEEDED
JOB1             CLASS1               COMPLETED

ジョブまたはジョブ・クラスのlogging_level属性を設定することによって、ジョブ・ログに情報を書き込む頻度を制御できます。表29-11に、logging_levelに指定可能な値を示します。

表29-11 ジョブのロギング・レベル

ロギング・レベル

説明

DBMS_SCHEDULER.LOGGING_OFF

ロギングは実行されません。

DBMS_SCHEDULER.LOGGING_FAILED_RUNS

ジョブが失敗した場合にのみログ・エントリが作成されます。

DBMS_SCHEDULER.LOGGING_RUNS

ジョブが実行されるたびにログ・エントリが作成されます。

DBMS_SCHEDULER.LOGGING_FULL

ジョブが実行されるたびに、および作成、有効化、無効化、更新(SET_ATTRIBUTEを使用)、停止および削除など、ジョブに対して実行された操作ごとに、ログ・エントリが作成されます。

ジョブの実行に関するログ・エントリは、ジョブの実行が正常に完了するか、失敗するかまたは停止するまで作成されません。

次の例は、完全なジョブ・ライフサイクルのジョブ・ログ・エントリを示しています。この場合、ジョブ・クラスのロギング・レベルはLOGGING_FULLで、ジョブは非繰返しジョブです。最初に正常に実行された後、もう一度実行されるようにジョブが有効化されています。次に、停止され、削除されています。

SELECT to_char(log_date, 'DD-MON-YY HH24:MI:SS') TIMESTAMP, job_name,
job_class, operation, status FROM USER_SCHEDULER_JOB_LOG
WHERE job_name = 'JOB2' ORDER BY log_date;

TIMESTAMP            JOB_NAME  JOB_CLASS  OPERATION  STATUS
-------------------- --------- ---------- ---------- ---------
18-DEC-07 23:10:56   JOB2      CLASS1     CREATE
18-DEC-07 23:12:01   JOB2      CLASS1     UPDATE
18-DEC-07 23:12:31   JOB2      CLASS1     ENABLE
18-DEC-07 23:12:41   JOB2      CLASS1     RUN        SUCCEEDED
18-DEC-07 23:13:12   JOB2      CLASS1     ENABLE
18-DEC-07 23:13:18   JOB2                 RUN        STOPPED
18-DEC-07 23:19:36   JOB2      CLASS1     DROP

実行詳細

RUN、RETRY_RUNまたはRECOVERY_RUN操作に関する*_SCHEDULER_JOB_LOG内の行ごとに、*_SCHEDULER_JOB_RUN_DETAILSビューには対応する行があります。2つの異なるビューの行は、それぞれのLOG_ID列で関係付けられています。実行詳細ビューを参照して、ジョブが失敗した理由や停止された理由を判断できます。

SELECT to_char(log_date, 'DD-MON-YY HH24:MI:SS') TIMESTAMP, job_name, status,
SUBSTR(additional_info, 1, 40) ADDITIONAL_INFO
FROM user_scheduler_job_run_details ORDER BY log_date;

TIMESTAMP            JOB_NAME   STATUS    ADDITIONAL_INFO
-------------------- ---------- --------- ----------------------------------------
18-DEC-07 23:12:41   JOB2       SUCCEEDED
18-DEC-07 23:12:18   JOB2       STOPPED   REASON="Stop job called by user:'SYSTEM'
19-DEC-07 14:12:20   REMOTE_16  FAILED    ORA-29273: HTTP request failed ORA-06512

実行詳細ビューには、実際のジョブ開始時刻と継続時間も含まれています。

ジョブおよびジョブ・クラスのロギング・レベルの優先度

表29-11に示されている値を指定できるlogging_level属性が、ジョブとジョブ・クラスの両方にあります。ジョブ・クラスのデフォルト・ロギング・レベルはLOGGING_RUNSで、個々のジョブのデフォルト・レベルはLOGGING_OFFです。ジョブ・クラスのロギング・レベルが、クラス内のジョブのロギング・レベルよりも高い場合は、ジョブ・クラスのロギング・レベルが優先されます。そのため、デフォルトでは、すべてのジョブの実行がジョブ・ログに記録されます。

非常に短くて頻度の高いジョブの場合は、個々の実行をすべて記録すると負荷が非常に高くなるため、ロギングをオフに設定して、ジョブが失敗した場合にのみロギングが行われるように設定する場合もあります。ただし、特定のクラスのジョブで発生したすべての事象の完全な監査証跡を取得する必要がある場合には、そのクラスの完全なロギングを有効にします。

すべてのジョブの監査証跡が確実に作成されるようにするには、個々のジョブ作成者がロギングをオフにできないようにする必要があります。これをサポートするために、スケジューラではクラス別のレベルがジョブの情報を記録する最低レベルとなっています。ジョブ作成者は、個々のジョブに対するロギング・レベルを上げることはできますが、下げることはできません。したがって、個々のジョブのロギング・レベルをすべてLOGGING_OFFに設定すると、クラス内のすべてのジョブがクラスでの指定に従って記録されます。

この機能は、デバッグの目的で提供されています。たとえば、クラス別のレベルでジョブ実行を記録するように設定されているときに、ジョブ・レベルでロギングがオフにされた場合でも、スケジューラはジョブの実行を記録します。ただし、ジョブ作成者が完全ロギングをオンにしているときに、クラス別のレベルでは実行のみを記録するように設定されている場合は、ジョブの上位のロギング・レベルが優先され、この個別ジョブのすべての操作がログに記録されます。このように、エンド・ユーザーは、完全ロギングをオンにして自分のジョブをテストできます。

個々のジョブのロギング・レベルを設定するには、そのジョブについてSET_ATTRIBUTEプロシージャを使用する必要があります。たとえば、mytestjobというジョブの完全ロギングをオンにするには、次の文を発行します。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE (
'mytestjob', 'logging_level', DBMS_SCHEDULER.LOGGING_FULL);
END;
/

ジョブ・クラスのロギング・レベルを設定できるのは、MANAGE SCHEDULER権限を付与されているユーザーのみです。

関連項目:
ジョブ・クラスのロギング・レベルの設定の詳細は、「ウィンドウ・ログおよびジョブ・ログの監視と管理」を参照してください。

複数の宛先のジョブの監視

複数の宛先のジョブの場合、親ジョブの全体的な状態は子ジョブの結果に依存します。たとえば、すべての子ジョブが成功した場合、親ジョブの状態はSUCCEEDEDに設定されます。すべてが失敗した場合、親ジョブの状態はFAILEDに設定されます。一部が失敗し、一部が成功した場合、親ジョブの状態はSOME FAILEDに設定されます。

一部の宛先で子ジョブの開始が遅延するような状況では、親ジョブの状態がファイナライズされるまでに大幅な遅延が生じる可能性があります。複数の宛先のジョブが繰返しジョブの場合は、スケジュールされている次回の実行に進むジョブもあれば、前回の実行がまだ終了しないジョブが生じることもあります。この場合、親ジョブの状態はINCOMPLETEに設定されます。ただし、最終的には、遅延しているジョブも他の兄弟ジョブに追いつき、親ジョブの最終的な状態を決定できるようになります。

表29-12に、複数の宛先のジョブを対象としたジョブ監視ビューの内容を示します。

表29-12 複数の宛先のジョブを対象としたスケジューラ・データ・ディクショナリ・ビューの内容

ビュー名

目次

*_SCHEDULER_JOBS

親ジョブの1つのエントリ

*_SCHEDULER_RUNNING_JOBS

親ジョブの1つのエントリ(親ジョブが開始された場合)および実行中の子ジョブごとに1つのエントリ

*_SCHEDULER_JOB_LOG

親ジョブの1つのエントリ(親ジョブが開始された場合)(operation = 'MULTIDEST_START')、子ジョブごとに1つのエントリ(子ジョブが完了した場合)および親ジョブの1つのエントリ(最後の子ジョブが完了し、親が完了した場合)(operation = 'MULTIDEST_RUN')

*_SCHEDULER_JOB_RUN_DETAILS

子ジョブごとに1つのエントリ(子ジョブが完了した場合)および親ジョブの1つのエントリ(最後の子ジョブが完了し、親が完了した場合)

*_SCHEDULER_JOB_DESTS

親ジョブの宛先ごとに1つのエントリ

*_SCHEDULER_JOB_DESTSビューでは、各子ジョブに割り当てられている一意のジョブ宛先ID(job_dest_id)を調べることができます。このIDは、ジョブ、資格証明および宛先の一意の組合せを表します。このIDは、STOP_JOBプロシージャで使用できます。また、*_SCHEDULER_JOB_DESTSビューで各子ジョブのジョブ状態を監視できます。

関連項目:

- 「複数の宛先のジョブ」

- 「複数の宛先のジョブの作成」

- 「スケジューラのデータ・ディクショナリ・ビュー」

スケジューラによって呼び出されるイベントによるジョブ状態の監視

この項の内容は次のとおりです。

- イベントの概要

- イベントを呼び出すようにジョブを変更する方法

- ジョブの状態イベントのアプリケーションでの使用

イベントの概要

ジョブの状態が変化したときに、スケジューラがイベントを呼び出すようにジョブを構成できます。スケジューラは、ジョブの開始時、ジョブの完了時、ジョブがその割当ての実行時間を超えたときなどにイベントを呼び出します。イベントのコンシューマは、そのイベントに対応して処理を実行するアプリケーションです。たとえば、システムの負荷が高いために、スケジュールされた開始時間から30分を経過してもジョブが開始されない場合、スケジューラは、ハンドラのアプリケーションによって低優先度のジョブを停止させてシステム・リソースを解放するイベントを呼び出すことができます。スケジューラでは、ローカル(標準)・ジョブ、リモート・データベース・ジョブ、ローカル外部ジョブおよびリモート外部ジョブに対してジョブ状態イベントを呼び出すことができます。

表29-13に、スケジューラによって呼び出されるジョブ状態イベントのタイプを示します。

表29-13 スケジューラによって呼び出されるジョブ状態イベントのタイプ

イベント・タイプ

説明

job_all_events

イベントではなく、すべてのイベントを簡単に有効にするための定数です。

job_broken

ジョブ属性max_failuresで定義されている失敗回数を超えたため、ジョブは使用禁止になり、状態がBROKENに変更されました。

job_chain_stalled

チェーンを実行するジョブがCHAIN_STALLED状態になりました。実行中または実行がスケジュールされているステップがない場合にチェーンのevaluation_intervalをNULLに設定すると、実行中のチェーンは停止状態になります。手動で操作を行わないかぎり、チェーンは続行されません。

job_completed

max_runsまたはend_dateに達したため、ジョブが終了しました。

job_disabled

SchedulerまたはSET_ATTRIBUTEへのコールによってジョブが使用禁止になりました。

job_failed

エラーが発生したか、異常終了したため、ジョブが失敗しました。

job_over_max_dur

ジョブは、max_run_duration属性で指定した最大実行時間を超えました。

job_run_completed

ジョブの実行が、失敗、成功または停止しました。

job_sch_lim_reached

ジョブのスケジュール制限に達しました。ジョブ開始の遅延時間がジョブ属性schedule_limitの値を超えたため、ジョブは開始されませんでした。

job_started

ジョブが開始されました。

job_stopped

STOP_JOBへのコールによって、ジョブが停止されました。

job_succeeded

ジョブが正常に完了しました。

ジョブ状態イベントの呼出しを有効にするには、raise_eventsジョブ属性を設定します。デフォルトでは、ジョブはジョブ状態イベントを呼び出しません。

スケジューラは、Oracle Streamsアドバンスト・キューイングを使用してイベントを呼び出します。ジョブの状態の変更に関するイベントが発生すると、スケジューラは、メッセージをデフォルトのイベント・キューにエンキューします。アプリケーションは、このキューをサブスクライブし、イベント・メッセージをデキューして、適切な処理を行います。

ジョブに対するジョブの状態変化イベントを有効(使用可能)にすると、スケジューラは、メッセージをスケジューラ・イベント・キューSYS.SCHEDULER$_EVENT_QUEUEにエンキューすることによってこれらのイベントを呼び出します。このキューはセキュアなキューであるため、アプリケーションによっては、特定のユーザーがキューの操作を実行できるようにキューを構成する必要があります。セキュアなキューの詳細は、『Oracle Streams概要および管理』を参照してください。

スケジューラのイベント・キューが無制限に大きくなるのを防ぐために、デフォルトでは、スケジューラが呼び出したイベントは24時間で失効します。(失効したイベントはキューから削除されます。)SET_SCHEDULER_ATTRIBUTEプロシージャを使用して、event_expiry_timeスケジューラ属性を設定することで、この有効期間を変更できます。詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

イベントを呼び出すようにジョブを変更する方法

ジョブに対してジョブ状態イベントの呼出しを有効にするには、SET_ATTRIBUTEプロシージャを使用して、raise_eventsジョブ属性のビット・フラグをオンにします。各ビット・フラグは、イベントの呼出しの対象となる様々なジョブ状態を表します。たとえば、最下位ビットをオンにすることで、job startedイベントを呼び出すことができます。複数の状態変化イベント・タイプを1回のコールで使用可能にするには、必要なビット・フラグの値を加算し、その結果を引数としてSET_ATTRIBUTEに提供します。

次の例では、ジョブdw_reportsに対して複数の状態変更イベントを有効にしています。次のイベント・タイプが有効になっていますが、両方ともなんらかのエラーを示しています。

- JOB_FAILED

- JOB_SCH_LIM_REACHED

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE('dw_reports', 'raise_events',
DBMS_SCHEDULER.JOB_FAILED + DBMS_SCHEDULER.JOB_SCH_LIM_REACHED);
END;
/

注意:
raise_eventsジョブ属性を指定してJOB_OVER_MAX_DURイベントを使用可能にする必要はありません。このイベントは常に使用可能になっています。

関連項目:
ジョブ状態ビット・フラグの名前と値は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_SCHEDULER.SET_ATTRIBUTEに関する項を参照してください。

ジョブの状態イベントのアプリケーションでの使用

ジョブ状態イベントを使用するには、アプリケーションがスケジューラ・イベント・キューSYS.SCHEDULER$_EVENT_QUEUEをサブスクライブする必要があります。このキューはセキュアなキューであり、所有者はSYSです。あるユーザーについてこのキューのサブスクリプションを作成するには、次の処理を実行します。

1. SYSユーザーまたはMANAGE ANY QUEUE権限のあるユーザーでデータベースにログインします。

2. 新規または既存のエージェントを使用してキューをサブスクライブします。

3. パッケージ・プロシージャDBMS_AQADM.ENABLE_DB_ACCESSを次のように実行します。

DBMS_AQADM.ENABLE_DB_ACCESS(agent_name, db_username);

agent_nameは、イベント・キューのサブスクライブに使用したエージェントを表し、db_usernameは、サブスクリプションを作成する対象のユーザーです。

ユーザーにデキュー権限を付与する必要はありません。スケジューラ・イベント・キューに関するデキュー権限は、PUBLICに付与されます。

または、次の例に示すように、ユーザーがADD_EVENT_QUEUE_SUBSCRIBERプロシージャを使用してスケジューラ・イベント・キューをサブスクライブすることもできます。

DBMS_SCHEDULER.ADD_EVENT_QUEUE_SUBSCRIBER(subscriber_name);

この例のsubscriber_nameは、スケジューラ・イベント・キューのサブスクライブに使用されるOracle Streamsアドバンスト・キューイング(AQ)・エージェントの名前です。(NULLの場合は、呼出しユーザーのユーザー名でエージェントが作成されます。)このコールによって、スケジューラ・イベント・キューのサブスクリプションが作成され、指定エージェントを使用してデキューする許可がユーザーに付与されます。サブスクリプションはルールベースです。ルールによって、ユーザーが許可されるのは、所有するジョブが呼び出したイベントの参照のみで、その他のメッセージはすべて除外されます。サブスクリプションが使用可能になると、ユーザーは一定の間隔でメッセージをポーリングするか、またはメッセージが通知されるようにAQに登録できます。

詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。

スケジューラ・イベント・キュー

スケジューラ・イベント・キューSYS.SCHEDULER$_EVENT_QUEUEのタイプはscheduler$_event_infoです。このタイプの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

電子メール通知によるジョブ状態の監視

この項の内容は次のとおりです。

- 電子メール通知の概要

- ジョブに対する電子メール通知の追加

- ジョブに対する電子メール通知の削除

- 電子メール通知情報の表示

電子メール通知の概要

ジョブの状態が変化したときに電子メール通知を送信するようにジョブを構成できます。表29-13に、電子メールを送信できるジョブ状態イベントを示します。電子メール通知は、指定したジョブ状態イベントのリストに含まれる任意のイベントをトリガーとして、複数の受信者に送信できます。また、フィルタ条件を指定して、その条件に一致するジョブ状態イベントのみで通知を生成することもできます。メッセージの件名と本文の両方に、ジョブ所有者、ジョブ名、イベント・タイプ、エラー・コード、エラー・メッセージなどの変数を含めることができます。これらの変数の値は、電子メール通知が送信される前に、スケジューラによって自動的に設定されます。

単一のジョブに対して複数のジョブ状態電子メール通知を構成できます。これらの通知は、ジョブ状態イベント・リスト、受信者およびフィルタ条件によって区別できます。

たとえば、ジョブがエラー・コード600または700で失敗した場合は常に主任DBAとシニアDBAの1人に電子メールを送信するようにジョブを構成できます。また、同じジョブに対して、ジョブがスケジュールどおり開始されなかった場合は主任DBAのみに通知を送信するように構成することもできます。

電子メール通知を送信するようにジョブを構成するには、スケジューラ属性email_serverに、電子メールの送信に使用するSMTPサーバーのアドレスを設定する必要があります。また、必要に応じて、送信者未指定のジョブに対しては、スケジューラ属性email_senderに、デフォルトの送信者電子メール・アドレスを設定できます。

スケジューラでは、SMTPサーバーとの通信におけるSSLプロトコルおよびTLSプロトコルがサポートされています。また、認証を必要とするSMTPサーバーもサポートされています。

関連項目:
電子メール通知関連の属性の設定の詳細は、「スケジューラのプリファレンスの設定」を参照してください。

ジョブに対する電子メール通知の追加

ジョブに対する電子メール通知を追加するには、DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATIONパッケージ・プロシージャを使用します。

BEGIN
DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATION (
job_name   =>  'EOD_JOB',
recipients =>  'jsmith@example.com, rjones@example.com',
sender     =>  'do_not_reply@example.com',
subject    =>  'Scheduler Job Notification-%job_owner%.%job_name%-%event_type%',
body       =>   '%event_type% occurred at %event_timestamp%. %error_message%',
events     =>  'JOB_FAILED, JOB_BROKEN, JOB_DISABLED, JOB_SCH_LIM_REACHED');
END;
/

subjectおよびbody引数では、%文字で囲まれた変数が使用されています。複数の受信者および複数のイベントを指定した場合、指定したイベントのいずれかが呼び出されると各受信者に通知されます。これを確認するには、USER_SCHEDULER_NOTIFICATIONSビューを問い合せます。

SELECT JOB_NAME, RECIPIENT, EVENT FROM USER_SCHEDULER_NOTIFICATIONS;

JOB_NAME    RECIPIENT            EVENT
----------- -------------------- -------------------
EOD_JOB     jsmith@example.com   JOB_FAILED
EOD_JOB     jsmith@example.com   JOB_BROKEN
EOD_JOB     jsmith@example.com   JOB_SCH_LIM_REACHED
EOD_JOB     jsmith@example.com   JOB_DISABLED
EOD_JOB     rjones@example.com   JOB_FAILED
EOD_JOB     rjones@example.com   JOB_BROKEN
EOD_JOB     rjones@example.com   JOB_SCH_LIM_REACHED
EOD_JOB     rjones@example.com   JOB_DISABLED

ジョブに対して異なる通知を構成するたびに、ADD_JOB_EMAIL_NOTIFICATIONをコールします。job_nameとrecipientsの指定は必須です。他のすべての引数には、デフォルト値があります。デフォルトのsenderは、前の項で説明したように、スケジューラ属性によって定義されます。subject、bodyおよびevents引数のデフォルト値は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のADD_JOB_EMAIL_NOTIFICATIONプロシージャに関する項を参照してください。

次の例では、同じジョブに対して、異なるイベントに関する追加の電子メール通知を構成しています。この例では、sender、subjectおよびbody引数のデフォルト値をそのまま使用しています。

BEGIN
DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATION (
job_name         =>  'EOD_JOB',
recipients       =>  'jsmith@example.com',
events           =>  'JOB_OVER_MAX_DUR');
END;
/

この例では、events引数も省略して、イベントのデフォルト値をそのまま使用しています。

次の例は最初の例と類似していますが、この場合、フィルタ条件を使用して、エラー番号が600または700でジョブが失敗した場合にのみ電子メール通知を送信するように指定しています。

BEGIN
DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATION (
job_name         => 'EOD_JOB',
recipients       => 'jsmith@example.com, rjones@example.com',
sender           => 'do_not_reply@example.com',
subject          => 'Job Notification-%job_owner%.%job_name%-%event_type%',
body             =>  '%event_type% at %event_timestamp%. %error_message%',
events           => 'JOB_FAILED',
filter_condition => ':event.error_code=600 or :event.error_code=700');
END;
/

関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のADD_JOB_EMAIL_NOTIFICATIONプロシージャに関する項を参照してください。

ジョブに対する電子メール通知の削除

ジョブに対する電子メール通知を削除するには、DBMS_SCHEDULER.REMOVE_JOB_EMAIL_NOTIFICATIONパッケージ・プロシージャを使用します。

BEGIN
DBMS_SCHEDULER.REMOVE_JOB_EMAIL_NOTIFICATION (
job_name   =>  'EOD_JOB',
recipients =>  'jsmith@example.com, rjones@example.com',
events     =>  'JOB_DISABLED, JOB_SCH_LIM_REACHED');
END;
/

複数の受信者および複数のイベントを指定した場合、指定した各イベントの通知が各受信者に対して削除されます。前の項で説明したものと同じ問合せを実行した場合、結果は次のようになります。

SELECT JOB_NAME, RECIPIENT, EVENT FROM USER_SCHEDULER_NOTIFICATIONS;

JOB_NAME    RECIPIENT            EVENT
----------- -------------------- -------------------
EOD_JOB     jsmith@example.com   JOB_FAILED
EOD_JOB     jsmith@example.com   JOB_BROKEN
EOD_JOB     rjones@example.com   JOB_FAILED
EOD_JOB     rjones@example.com   JOB_BROKEN

REMOVE_JOB_EMAIL_NOTIFICATION引数を指定する場合、次のルールが別途適用されます。

- events引数をNULLのままにすると、指定した受信者に対して、すべてのイベントの通知が削除されます。

- recipients引数をNULLのままにすると、すべての受信者に対して、指定したイベントの通知が削除されます。

- recipientsとeventsの両方をNULLのままにすると、該当ジョブのすべての通知が削除されます。

- 今まで通知を作成したことのない受信者とイベントを指定した場合、エラーは生成されません。

関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のREMOVE_JOB_EMAIL_NOTIFICATIONプロシージャに関する項を参照してください。

電子メール通知情報の表示

前の項で説明したように、*_SCHEDULER_NOTIFICATIONSビューを問い合せることによって、現在の電子メール通知に関する情報を表示できます。

関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

30 Oracle Schedulerの管理

この章の内容は、次のとおりです。

- Oracle Schedulerの構成

- スケジューラの監視と管理

- スケジューラのインポート/エクスポート

- スケジューラのトラブルシューティング

- スケジューラの使用例

- スケジューラの参照情報

注意:
この章では、DBMS_SCHEDULERパッケージを使用してOracle Schedulerを管理する方法について説明します。同じ多数の作業をOracle Enterprise Managerを使用して実行できます。
DBMS_SCHEDULERの詳細は『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を、Oracle Schedulerの各ページの詳細はOracle Enterprise Managerのオンライン・ヘルプを参照してください。

Oracle Schedulerの構成

この項の内容は次のとおりです。

- Oracle Schedulerの権限の構成

- スケジューラのプリファレンスの設定

- Oracle Scheduler Agentを使用したリモート・ジョブの実行

Oracle Schedulerの権限の構成

Oracle Schedulerのすべての管理タスクを実行するには、SCHEDULER_ADMINロールが必要です。通常、データベース管理者(DBA)は、DBAロールの一部として、ADMINオプション付きでこのロールをすでに持っています。たとえば、ユーザーSYSおよびSYSTEMには、DBAロールが付与されます。このロールは、次の文を発行して別の管理者に付与できます。

GRANT SCHEDULER_ADMIN TO username;

SCHEDULER_ADMINロールは、権限を付与されたユーザーがコードを任意のユーザーとして実行できる強力なロールであるため、かわりにスケジューラの個々のシステム権限を付与することを考慮してください。オブジェクト権限とシステム権限は、標準的なSQL権限付与構文を使用して付与されます。例として、データベース管理者が次の文を発行したとします。

GRANT CREATE JOB TO scott;

この文が実行されると、scottは、自分のスキーマ内にジョブ、スケジュール、プログラム、File Watcherおよび資格証明を作成できます。別の例として、データベース管理者が次の文を発行したとします。

GRANT MANAGE SCHEDULER TO adam;

この文が実行されると、adamは、ウィンドウ、ジョブ・クラスまたはウィンドウ・グループを、作成、変更または削除できます。また、スケジューラ属性の設定と検索、およびスケジューラ・ログのパージもできます。

チェーンの各権限の設定

スケジューラ・チェーンでは、基礎となるOracle Streamsルール・エンジン・オブジェクトと、それに関連する権限を使用します。ユーザーが自分のスキーマにチェーンを作成するには、自分のスキーマにルール、ルール・セットおよび評価コンテキストを作成するためのルール・エンジン権限に加え、CREATE JOB権限が必要です。これらの権限は、次の文を発行することで付与できます。

GRANT CREATE RULE, CREATE RULE SET, CREATE EVALUATION CONTEXT TO user;

ユーザーが、別のスキーマにチェーンを作成するには、自分のスキーマ以外のスキーマにルール、ルール・セットおよび評価コンテキストを作成するためのルール・エンジン権限に加え、CREATE ANY JOB権限が必要です。これらの権限は、次の文を発行することで付与できます。

GRANT CREATE ANY RULE, CREATE ANY RULE SET,
CREATE ANY EVALUATION CONTEXT TO user;

各自のスキーマ以外のスキーマのチェーンを変更または削除するには、ルール、ルール・セットおよび評価コンテキストについて、対応する各システムのルール・エンジン権限が必要です。

関連項目:
チェーンの権限の詳細は、「チェーンのタスクとそのプロシージャ」を参照してください。

スケジューラのプリファレンスの設定

システム全体にわたる設定可能なスケジューラのプリファレンスがいくつかあります。SET_SCHEDULER_ATTRIBUTEプロシージャでスケジューラの属性を設定することにより、これらのプリファレンスを設定できます。これらの属性を設定するには、MANAGE SCHEDULER権限が必要です。属性は次のとおりです。

- default_timezone
この属性を設定することは非常に重要です。カレンダ構文式を使用する繰返しジョブおよびウィンドウには、繰返し間隔に使用するタイムゾーンに関する情報が必要です。「スケジューラのカレンダ指定構文の使用方法」を参照してください。通常は、start_dateからタイムゾーンを取得しますが、start_dateが指定されていない場合(珍しいことではありません)は、default_timezone Scheduler属性から取得します。

スケジューラは、default_timezoneの値をオペレーティング・システム環境から導出します。オペレーティング・システムから互換性のある値を検出できない場合、スケジューラはdefault_timezoneをNULLに設定します。

default_timezoneが正しく設定されていることを確認することは非常に重要であり、そうでない場合は正しく設定してください。これを確認するには、次の問合せを実行します。

SELECT DBMS_SCHEDULER.STIME FROM DUAL;

STIME
---------------------------------------------------------------------------
14-OCT-04 02.56.03.206273000 PM US/PACIFIC

確実に夏時間が適用されるようにするには、default_timezoneを、'-8:00'のような絶対タイム・ゾーン・オフセットではなく、リージョン名に設定することをお薦めします。たとえば、データベースが米国フロリダ州のマイアミにある場合は、次の文を発行します。

DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('default_timezone','US/Eastern');

同様に、データベースがパリにある場合は、この属性を'Europe/Warsaw'に設定します。有効なリージョン名のリストを表示するには、次の問合せを実行します。

SELECT DISTINCT TZNAME FROM V$TIMEZONE_NAMES;

default_timezone属性を適切に設定しないと、繰返しジョブや繰返しウィンドウに使用されるデフォルトのタイム・ゾーンは、SYSTIMESTAMPから取り出される絶対オフセット(データベースのオペレーティング・システム環境のタイム・ゾーン)となります。これは、start_dateが設定されていない繰返しジョブや繰返しウィンドウでは、夏時間調整が適用されないことになります。

- email_server
この属性には、ジョブの状態イベントに対する電子メール通知を送信するためにスケジューラで使用されるSMTPサーバーのアドレスを指定します。書式は次のとおりです。

host[:port]

説明:

- hostは、SMTPサーバーのホスト名またはIPアドレスです。

- portは、SMTPサーバーがリスニングするTCPポートです。指定しない場合は、デフォルト・ポート25が使用されます。

この属性が指定されていないか、NULLまたは無効なSMTPサーバー・アドレスに設定されていると、ジョブの状態に関する電子メール通知をスケジューラで送信できません。

- email_sender
この属性には、ジョブ状態の電子メール通知の送信者のデフォルト電子メール・アドレスを指定します。有効な電子メール・アドレスを指定する必要があります。この属性が設定されていないか、NULLに設定されている場合、送信者アドレスが指定されていないジョブ状態の電子メール通知では、電子メール・ヘッダーのFROMアドレスが指定されません。

- email_server_credential
この属性は、既存の資格証明オブジェクトのスキーマおよび名前を指定します。デフォルトはNULLです。

電子メール通知が送信されると、スケジューラはemail_server_credentialが指している資格証明オブジェクトを確認して、SYSがEXECUTEオブジェクト権限を持つ有効な資格証明オブジェクトであるかどうかを判断します。email_server属性に指定されているSMTPサーバーが認証を必要とする場合、スケジューラは指定された資格証明オブジェクトに格納されているユーザー名とパスワードを使用して電子メール・サーバーで認証します。

email_server_credentialを指定している場合、email_server属性には認証を必要とするSMTPサーバーを指定する必要があります。

email_server_credentialを指定していない場合、スケジューラでは認証が構成されていないSMTPサーバーを介して通知電子メールを送信できます。

注意:
この機能は、Oracle Database 11g リリース2(11.2.0.2)から使用できるようになりました。

- email_server_encryption
この属性は、このSMTPサーバー接続で暗号化が有効であるかどうかを示し、有効である場合には暗号化を開始する時点と使用するプロトコルも示します。

email_server_encryptionの値は、次のとおりです。

NONE: デフォルト値で、暗号化が有効でないことを示します。

SSL_TLS: 接続が確立された当初からSSLまたはTLSが使用されることを示します。両側から、どのプロトコルが最も安全であるかが判断されます。これが、このパラメータに最もよく使用される設定です。

STARTTLS: 暗号化なしで接続を開始するものの、STARTTLSコマンドの指示があると、電子メール・サーバーがTLSを使用して暗号化を開始することを示します。

注意:
この機能は、Oracle Database 11g リリース2(11.2.0.2)から使用できるようになりました。

- event_expiry_time
この属性を使用すると、スケジューラが生成したジョブの状態イベントが終了する(自動的にスケジューラ・イベント・キューからパージされる)までの時間(秒)を設定できます。NULLに設定すると、ジョブの状態イベントは24時間後に期限切れになります。

- log_history
この属性は、ジョブ・ログとウィンドウ・ログの両方のログ・エントリが保持される日数を制御します。これにより、ログが無制限に大きくなるのを防ぐことができます。有効値の範囲は、0から1000000です。0に設定すると、履歴は保持されません。デフォルト値は30です。ジョブ・クラスのlog_history属性に値を設定することにより、ジョブ・クラス・レベルでこの値をオーバーライドできます。

SET_SCHEDULER_ATTRIBUTEプロシージャの構文は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

Oracle Scheduler Agentを使用したリモート・ジョブの実行

Oracle Scheduler Agentを使用して、スケジューラは次の2種類のリモート・ジョブをスケジュールおよび実行できます。

- リモート・データベース・ジョブ: リモート・データベース・ジョブはOracle Scheduler Agentを介して実行する必要があります。リモート・データベースと同じホストにエージェントをインストールすることをお薦めします。
リモート・データベース・ジョブを実行する場合は、リリース11.2以降のスケジューラ・エージェントが必要です。

- リモート外部ジョブ: リモート外部ジョブは、スケジューラ・エージェントがインストールされているのと同じホストで実行されます。
リモート外部ジョブのみを実行する場合は、リリース11.1のスケジューラ・エージェントで十分です。

リモート外部ジョブが実行されるすべてのホストにスケジューラ・エージェントをインストールする必要があります。リモート・データベース・ジョブが実行されるリモート・データベースが動作するすべてのホストにスケジューラ・エージェントをインストールする必要があります。

リモート・ジョブが実行される各データベースでは、「リモート・ジョブを実行するためのデータベースの設定」の説明に従って、データベースとリモート・スケジューラ・エージェントの間のセキュアな通信を有効にするための初期設定を行う必要があります。

リモート・ジョブの有効化には、次の手順が含まれます。

1. リモート・ジョブを実行するためのデータベースの設定の有効化と無効化

2. リモート・ホストでのスケジューラ・エージェントのインストールと構成

3. スケジューラ・エージェントによるタスクの実行

関連項目:

- 「リモート外部ジョブの概要」

- リモート・データベース・ジョブの詳細は、「データベース・ジョブ」を参照してください。

リモート・ジョブを実行するためのデータベースの設定の有効化と無効化

この項の項目は次のとおりです。

- リモート・ジョブを実行するためのデータベースの設定

- リモート・ジョブの無効化

リモート・ジョブを実行するためのデータベースの設定

データベースでリモートのスケジューラ・エージェントを使用してジョブを実行するには、その前に、データベースを正しく構成し、そのエージェントをデータベースに登録しておく必要があります。この項では、データベースに必要なエージェント登録パスワードなどの構成について説明します。「スケジューラ・エージェントのデータベースへの登録」に示されているように、後でデータベースを登録します。

登録できるスケジューラ・エージェントの数を制限して、パスワードの有効期限を設定できます。

リモート・ジョブを作成および実行するデータベースごとに1回、次のすべての手順を実行します。

リモート・ジョブを作成および実行するデータベースを設定する手順は、次のとおりです。

1. 共有サーバーが使用可能であることを確認します。
「共有サーバーの使用可能化」を参照してください。

2. SQL*Plusを使用して、SYSユーザーとしてデータベースに接続します。

3. 次のコマンドを入力して、XML DBオプションがインストールされていることを確認します。

SQL> DESC RESOURCE_VIEW

XML DBがインストールされていない場合は、このコマンドで「オブジェクトが存在しません。」エラーが戻ります。

注意:
XML DBがインストールされていない場合は、先に進む前にXML DBをインストールする必要があります。

4. 次のように、データベースへのHTTP接続を有効にします。

1. Oracle XML DBM HTTPサーバーが有効であるかどうかを判断します。
次のコマンドを発行します。

SQL> SELECT DBMS_XDB.GETHTTPPORT() FROM DUAL;

この文が0を返した場合、Oracle XML DBM HTTPサーバーは無効になっています。

2. 0(ゼロ)以外のポートでOracle XML DB HTTPサーバーを有効にするには、SYSとしてログインし、次のコマンドを発行します。

SQL> EXEC DBMS_XDB.SETHTTPPORT (port);
SQL> COMMIT;

portは、データベースがHTTP接続をリスニングするTCPポート番号です。

portには1から65536の整数を指定しますが、UNIXおよびLinuxの場合は、1023より大きな値にします。まだ使用されていないポート番号を選択します。

注意:
これにより、Oracle Real Application ClustersデータベースのすべてのインスタンスでHTTP接続が使用可能になります。

5. 次のコマンドを使用して、スクリプトprvtrsch.plbを実行します。

SQL> @?/rdbms/admin/prvtrsch.plb

6. SET_AGENT_REGISTRATION_PASSプロシージャを使用して、スケジューラ・エージェントの登録パスワードを設定します。
次の例では、エージェント登録パスワードをmypasswordに設定します。

BEGIN
DBMS_SCHEDULER.SET_AGENT_REGISTRATION_PASS('mypassword');
END;
/

注意:
エージェント登録パスワードを設定するには、MANAGE SCHEDULER権限が必要です。SET_AGENT_REGISTRATION_PASSプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

実際の登録は、「スケジューラ・エージェントのデータベースへの登録」で行います。

リモート・ジョブの無効化

データベースのリモート・ジョブは、REMOTE_SCHEDULER_AGENTユーザーを削除することで、無効にできます。

リモート・ジョブを無効にする手順は、次のとおりです。

- 次のSQL文を発行します。

DROP USER REMOTE_SCHEDULER_AGENT CASCADE;

新規スケジューラ・エージェントの登録とリモート・ジョブの実行は、prvtrsch.plbを再度実行するまで無効(使用禁止)になります。

リモート・ホストでのスケジューラ・エージェントのインストールと構成

特定のホストでリモート・ジョブを実行する前に、この項の説明に従って、そのホスト上にスケジューラ・エージェントをインストールおよび構成し、「スケジューラ・エージェントによるタスクの実行」の説明に従って、スケジューラ・エージェントをホストで登録および起動しておく必要があります。スケジューラ・エージェントも、独自のOracleホームにインストールする必要があります。

スケジューラ・エージェントをリモート・ホストにインストールおよび構成するには、次の手順を実行します。

1. スケジューラ・エージェント・ソフトウェアをダウンロードまたは入手します。このソフトウェアはOracle Databaseクライアントのインストール・メディア(Databaseのインストール・メディア)に収録されており、次のサイトからオンラインで入手することもできます。
http://www.oracle.com/technology/software/products/database

2. 最初に、エージェントを登録するデータベースが正しく設定されていることを確認します。
手順は、「リモート・ジョブを実行するためのデータベースの設定の有効化と無効化」を参照してください。

3. スケジューラ・エージェントをインストールするホストにログインします。このホストがリモート・ジョブを実行します。

- Windowsの場合は、管理者としてログインします。

- UNIXおよびLinuxの場合は、スケジューラ・エージェントを実行する予定のユーザーとしてログインします。このユーザーに特別な権限は必要ありません。

4. Oracle Databaseクライアント製品のインストール・メディアからOracle Universal Installer(OUI)を実行します。

- Windowsの場合は、setup.exeを実行します。

- UNIXおよびLinuxの場合は、次のコマンドを使用します。

/directory_path/runInstaller

directory_pathは、Oracle Databaseクライアント製品のインストール・メディアへのパスです。

5. 「インストール・タイプの選択」ページで、「カスタム」を選択して、「次へ」をクリックします。

6. 「製品言語の選択」ページで、対象の言語を選択して、「次へ」をクリックします。

7. 「インストール場所の指定」ページで、エージェントの新しいOracleホームのパスを入力して、「次へ」をクリックします。

8. 「使用可能な製品コンポーネント」ページで、「Oracle Scheduler Agent」を選択して、「次へ」をクリックします。

9. 「Oracle Database Scheduler Agent」ページで、次の手順を実行します。

1. 「Scheduler Agentのホスト名」フィールドに、スケジューラ・エージェントをインストールするコンピュータのホスト名を入力します。

2. 「Scheduler Agentのポート番号」フィールドに、スケジューラ・エージェントが接続をリスニングするTCPポート番号を入力するか、デフォルトを使用して、「次へ」をクリックします。
1から65535の整数を選択します。UNIXおよびLinuxの場合は、1023より大きい値にする必要があります。選択するポート番号がまだ使用されていないことを確認します。

OUIで、一連の前提条件チェックが実行されます。前提条件チェックが失敗した場合は、問題を解決してから「次へ」をクリックします。

10. 「サマリー」ページで「終了」をクリックします。

11. (UNIXおよびLinuxのみ)OUIがスクリプトroot.shの実行を求めるプロンプトを表示したら、rootユーザーとして次のコマンドを入力します。

script_path/root.sh

このスクリプトは、エージェントのインストール用に選択したディレクトリに格納されています。

スクリプトが完了したら、「構成スクリプトの実行」ダイアログ・ボックスで「OK」をクリックします。

12. インストールが完了したら、「閉じる」をクリックしてOUIを終了します。

13. テキスト・エディタを使用して、スケジューラ・エージェントのホーム・ディレクトリにあるエージェント構成パラメータ・ファイルschagent.confのPORT=ディレクティブのポート番号を確認します。

14. リモート・ホスト上のファイアウォール・ソフトウェア、またはそのホストを保護する他のファイアウォールに、スケジューラ・エージェントに対応するための例外があることを確認します。

スケジューラ・エージェントによるタスクの実行

スケジューラ・エージェントは、外部ジョブとデータベース・ジョブをリモート・ホストでスケジュールおよび実行できるようにするスタンドアロン・プログラムです。スケジューラ・エージェントの起動と停止には、UNIXおよびLinuxではschagentユーティリティを使用し、WindowsではOracleSchedulerExecutionAgentサービスを使用します。

この項の項目は次のとおりです。

- schagentユーティリティについて

- Windowsでのスケジューラ・エージェントの使用

- スケジューラ・エージェントの起動

- スケジューラ・エージェントの停止

- スケジューラ・エージェントのデータベースへの登録

schagentユーティリティについて

実行可能ユーティリティschagentは、表30-1のオプションの指定に従って、Windows、UNIXおよびLinuxのエージェントに対する特定のタスクを実行します。

次の適切な構文およびオプションを指定して、schagentを使用します。

次に例を示します。

UNIXおよびLinux: AGENT_HOME/bin/schagent -status

Windows: AGENT_HOME/bin/schagent.exe -status

表30-1 schagentのオプション

オプション

説明

-start

スケジューラ・エージェントを開始します。

UNIXとLinuxのみ

-stop

スケジューラ・エージェントに現在実行中のすべてのジョブを停止するようにプロンプトを表示してから、実行を正常に停止します。

UNIXとLinuxのみ

-abort

最初にジョブを停止せずに、スケジューラ・エージェントを強制的に停止します。Oracle Database 11gリリース2以降。

UNIXとLinuxのみ

-status

ローカルに実行中のスケジューラ・エージェントに関する、バージョン、稼働時間、エージェントの起動以降に実行されたジョブの合計数、現在実行中のジョブの数およびその説明を返します。

-registerdatabase

エージェントのホスト・コンピュータでリモート・ジョブを実行する予定の基本データベースまたは追加データベースにスケジューラ・エージェントを登録します。

-unregisterdatabase

データベースからエージェントを登録解除します。

Windowsでのスケジューラ・エージェントの使用

Windowsのスケジューラ・エージェント・サービスは、インストール時に自動的に作成および起動されます。サービス名の末尾は、OracleSchedulerExecutionAgentになっています。

注意:
Oracle DatabaseがインストールされているWindowsコンピュータ上で実行され、資格証明なしのローカル外部ジョブの実行を管理するOracleJobSchedulerサービスと、このサービスを混同しないでください。

スケジューラ・エージェントの起動

次のコマンドを使用してスケジューラ・エージェントを起動します。

スケジューラ・エージェントを起動するには、次の手順を実行します。

- 次のいずれかを実行します。

- UNIXおよびLinuxの場合は、次のコマンドを実行します。

AGENT_HOME/bin/schagent -start

- Windowsの場合は、OracleSchedulerExecutionAgentで終わる名前のサービスを起動します。

スケジューラ・エージェントの停止

スケジューラ・エージェントを停止すると、スケジューラ・エージェントがあるホストでリモート・ジョブを実行できなくなります。

スケジューラ・エージェントを停止する手順は、次のとおりです。

- 次のいずれかを実行します。

- UNIXおよびLinuxでは、表30-1に説明されている-stopまたは-abortオプションのどちらかを指定してschagentユーティリティを実行します。

AGENT_HOME/bin/schagent -stop

- Windowsでは、OracleSchedulerExecutionAgentで終わる名前のサービスを停止します。これは-abortオプションに相当します。

スケジューラ・エージェントのデータベースへの登録

スケジューラ・エージェントの構成が終わるとすぐに、リモート・ジョブを実行する予定の1つ以上のデータベースでエージェントを登録できます。後でログインして、追加のデータベースにエージェントを登録することもできます。

1. すでにログアウトしている場合は、次の方法で、スケジューラ・エージェントを実行しているホストにログインします。

- Windowsの場合は、管理者としてログインします。

- UNIXおよびLinuxの場合は、スケジューラ・エージェントをインストールしたユーザーとしてログインします。

2. スケジューラ・エージェントを登録するデータベースごとに、次のコマンドを使用します。

- UNIXおよびLinuxの場合は、次のコマンドを実行します。

AGENT_HOME/bin/schagent -registerdatabase db_host db_http_port

- Windowsの場合は、次のコマンドを実行します。

AGENT_HOME/bin/schagent.exe -registerdatabase db_host db_http_port

説明:

- db_hostは、データベースがあるホストのホスト名またはIPアドレスです。Oracle Real Application Clusters環境では、任意のノードを指定できます。

- db_http_portは、データベースがリスニングするポート番号です(HTTP接続用)。このパラメータは、「リモート・ジョブを実行するためのデータベースの設定の有効化と無効化」で事前に設定しました。次のSQL文をデータベースに発行することにより、ポート番号を確認できます。

SELECT DBMS_XDB.GETHTTPPORT() FROM DUAL;

ポート番号が0のときは、HTTP接続が無効になっています。

「リモート・ジョブを実行するためのデータベースの設定の有効化と無効化」で設定したエージェント登録パスワードの入力を求めるプロンプトが表示されます。

3. エージェントのホストでリモート・ジョブを実行する追加データベースがある場合は、前の手順を繰り返します。

スケジューラの監視と管理

次の項では、スケジューラを監視および管理する方法について説明します。

- 現在アクティブなウィンドウとリソース・プランの表示

- 現在実行中のジョブに関する情報の検索

- ウィンドウ・ログおよびジョブ・ログの監視と管理

- スケジューラ・セキュリティの管理

現在アクティブなウィンドウとリソース・プランの表示

現在アクティブなウィンドウとそのウィンドウに関連付けられているプランを表示するには、次の文を発行します。

SELECT WINDOW_NAME, RESOURCE_PLAN FROM DBA_SCHEDULER_WINDOWS
WHERE ACTIVE='TRUE';

WINDOW_NAME                    RESOURCE_PLAN
------------------------------ --------------------------
MY_WINDOW10                    MY_RESOURCEPLAN1

アクティブなウィンドウがない場合は、次の文を発行するとアクティブなリソース・プランを表示できます。

SELECT * FROM V$RSRC_PLAN;

現在実行中のジョブに関する情報の検索

ジョブの状態を確認するには、次の文を発行します。

SELECT JOB_NAME, STATE FROM DBA_SCHEDULER_JOBS
WHERE JOB_NAME = 'MY_EMP_JOB1';

JOB_NAME                       STATE
------------------------------ ---------
MY_EMP_JOB1                    DISABLED

この場合は、ENABLEプロシージャを使用してジョブを使用可能にできます。表30-2に、ジョブの状態に関する有効値を示します。

表30-2 ジョブの状態

ジョブの状態

説明

disabled

ジョブは使用禁止です。

scheduled

ジョブは実行するようにスケジュールされています。

running

ジョブは現在実行中です。

completed

ジョブは完了しており、次回の実行はスケジュールされていません。

stopped

ジョブは1回実行するようにスケジュールされましたが、実行中に停止しました。

broken

ジョブは中断されました。

failed

ジョブは1回実行するようにスケジュールされ、失敗しました。

retry scheduled

ジョブは1回以上失敗し、再試行の実行がスケジュールされました。

succeeded

ジョブは1回実行するようにスケジュールされ、正常に完了しました。

chain_stalled

ジョブのタイプがチェーンで、実行されているステップ、実行がスケジュールされているステップおよびイベント待ちのイベント・ステップがなく、チェーンのevaluation_intervalがNULLに設定されています。手動で操作を行わないかぎり、チェーンは続行されません。

現在実行中のジョブの進行状況を確認するには、次の文を発行します。

SELECT * FROM ALL_SCHEDULER_RUNNING_JOBS;

CPU_USED列に有効なデータを表示するには、RESOURCE_LIMIT初期化パラメータをtrueに設定する必要があります。

リモートおよびローカルのすべての宛先ですべてのジョブの状態を確認するには、次の文を発行します。

SELECT * FROM DBA_SCHEDULER_JOB_DESTS;

実行中のチェーンの一部のジョブに関する情報を得るには、次の文を発行します。

SELECT * FROM ALL_SCHEDULER_RUNNING_CHAINS WHERE JOB_NAME='MY_JOB1';

cjqNNNの形式のプロセスを検索すると、ジョブ・コーディネータが実行中かどうかをチェックできます。

関連項目:

- *_SCHEDULER_RUNNING_JOBSおよびDBA_SCHEDULER_JOBSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- 「複数の宛先のジョブ」

ウィンドウ・ログおよびジョブ・ログの監視と管理

スケジューラは、ジョブ・ログとウィンドウ・ログという2種類のログをサポートしています。

ジョブ・ログ

ジョブの実行、状態変化および失敗について、ジョブ・ログ内の情報を表示できます。ジョブ・ログは、次の2つのデータ・ディクショナリ・ビューとして実装されます。

- *_SCHEDULER_JOB_LOG

- *_SCHEDULER_JOB_RUN_DETAILS

スケジューラがジョブに関して実行するロギングの量は、ジョブ・クラス・レベルと個別ジョブ・レベルの両方で制御できます。通常、クラス内のジョブに関するロギングを厳密に制御できるため、ロギングをクラス・レベルで制御します。

各種ロギング・レベルの定義と、ジョブとジョブ・クラスの間のロギング・レベルの優先度については、「ジョブ・ログの表示」を参照してください。デフォルトでは、ジョブ・クラスのロギング・レベルはLOGGING_RUNSで、すべてのジョブの実行がログに記録されます。

ジョブ・クラスを作成する際にlogging_level属性を設定するか、SET_ATTRIBUTEプロシージャを使用すると、後でロギング・レベルを変更できます。次の例では、myclass1ジョブ・クラスのジョブのロギング・レベルを、失敗した実行のみがログに記録されるLOGGING_FAILED_RUNSに設定しています。すべてのジョブ・クラスはSYSスキーマにあることに注意してください。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE (
'sys.myclass1', 'logging_level', DBMS_SCHEDULER.LOGGING_FAILED_RUNS);
END;
/

ジョブ・クラスのロギング・レベルを設定するには、MANAGE SCHEDULER権限が付与されている必要があります。

関連項目:

- ジョブ・ログの詳細と、ジョブ・ログ・ビューに対する問合せ例については、「ジョブ・ログの表示」を参照してください。

- ジョブ・ログ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- CREATE_JOB_CLASSおよびSET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- ログ・エントリの保存期間の設定については、「スケジューラのプリファレンスの設定」を参照してください。

ウィンドウ・ログ

スケジューラでは、次の操作が実行されるたびにウィンドウ・ログにエントリが1つ記録されます。

- ウィンドウの作成または削除

- ウィンドウのオープン

- ウィンドウのクローズ

- ウィンドウの重複

- ウィンドウの使用可能化または使用禁止

ウィンドウ・アクティビティのロギングには、ロギング・レベルはありません。

ウィンドウ・ログの内容を調べるには、DBA_SCHEDULER_WINDOW_LOGビューを問い合せます。次の文は、このビューの出力例を示しています。

SELECT log_id, to_char(log_date, 'DD-MON-YY HH24:MI:SS') timestamp,
window_name, operation FROM DBA_SCHEDULER_WINDOW_LOG;

LOG_ID TIMESTAMP            WINDOW_NAME       OPERATION
---------- -------------------- ----------------- --------
4 10/01/2004 15:29:23  WEEKEND_WINDOW    CREATE
5 10/01/2004 15:33:01  WEEKEND_WINDOW    UPDATE
22 10/06/2004 22:02:48  WEEKNIGHT_WINDOW  OPEN
25 10/07/2004 06:59:37  WEEKNIGHT_WINDOW  CLOSE
26 10/07/2004 22:01:37  WEEKNIGHT_WINDOW  OPEN
29 10/08/2004 06:59:51  WEEKNIGHT_WINDOW  CLOSE

DBA_SCHEDULER_WINDOWS_DETAILSビューは、以前はアクティブで現在はクローズ(完了)されているすべてのウィンドウに関する情報を提供します。次の文は、このビューの出力例を示しています。

SELECT LOG_ID, WINDOW_NAME, ACTUAL_START_DATE, ACTUAL_DURATION
FROM DBA_SCHEDULER_WINDOW_DETAILS;

LOG_ID WINDOW_NAME      ACTUAL_START_DATE                    ACTUAL_DURATION
---------- ---------------- ------------------------------------ ---------------
25 WEEKNIGHT_WINDOW 06-OCT-04 10:02.48.832438 PM PST8PDT +000 01:02:32
29 WEEKNIGHT_WINDOW 07-OCT-04 10.01.37.025704 PM PST8PDT +000 03:02:00

これらのビューの両方でログIDが対応しており、この例では、DBA_SCHEDULER_WINDOWS_DETAILSビューの行がDBA_SCHEDULER_WINDOW_LOGビューのCLOSE操作に対応しています。

関連項目:

- ウィンドウ・ログ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ログのパージ

ジョブ・ログおよびウィンドウ・ログが無計画に大きくならないように、SET_SCHEDULER_ATTRIBUTEプロシージャを使用して、保持する履歴の量(日数)を指定します。1日に1回、スケジューラは、指定した履歴期間より古いすべてのログ・エントリをジョブ・ログとウィンドウ・ログから自動的にパージします。デフォルトの履歴期間は30日です。たとえば、履歴期間を90日に変更する場合は、次の文を発行します。

DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('log_history','90');

一部のジョブ・クラスは他より重要です。そのため、クラス固有の設定を使用して、このグローバルな履歴設定をオーバーライドできます。たとえば、3つのジョブ・クラス(class1、class2およびclass3)があり、class1とclass3に対しては10日間のウィンドウ・ログの履歴を保存し、class2に対しては30日間保存するとします。これを実現するには、次の文を発行します。

DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('log_history','10');
DBMS_SCHEDULER.SET_ATTRIBUTE('class2','log_history','30');

ジョブ・クラスの作成時には、クラス別の履歴を設定することもできます。

チェーン実行のステップに関連したログ・エントリは、メインのチェーン・ジョブのエントリがパージされるまでパージされません。

手動でのログのパージ

PURGE_LOGプロシージャを使用して、ログを手動でパージできます。例として、ジョブ・ログとウィンドウ・ログの両方からすべてのエントリをパージする文を示します。

DBMS_SCHEDULER.PURGE_LOG();

別の例として、3日前より古いすべてのエントリをジョブ・ログからパージする文を示します。ウィンドウ・ログはこの文の影響を受けません。

DBMS_SCHEDULER.PURGE_LOG(log_history => 3, which_log => 'JOB_LOG');

次の文では、10日前より古いすべてのウィンドウ・ログ・エントリと、job1およびclass2内のジョブに関連する10日前より古いすべてのジョブ・ログ・エントリがパージされます。

DBMS_SCHEDULER.PURGE_LOG(log_history => 10, job_name => 'job1, sys.class2');

スケジューラ・セキュリティの管理

ジョブのスケジュールと実行にスケジューラを使用する必要がある通常のユーザーに対しては、CREATE JOBシステム権限を付与してください。システム・リソースを管理する必要があるデータベース管理者には、MANAGE SCHEDULERを付与してください。スケジューラに関するその他のシステム権限またはロールを付与するときは、十分に注意してください。特に、CREATE ANY JOBシステム権限と、この権限が含まれるSCHEDULER_ADMINロールは、コードを任意のユーザーで実行できるため、非常に強力です。これらの権限とロールの付与は、非常に強力な権限を持つロールまたはユーザーに限定してください。

セキュリティに関して特に重要な問題は、外部ジョブの処理です。外部ジョブの処理は、データベース外でジョブを実行する必要があるユーザーにのみ実行を許可してください。それらのユーザーには、CREATE EXTERNAL JOBシステム権限を付与する必要があります。スケジューラに関するセキュリティには、他に特別な要件はありません。セキュリティの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

注意:
Oracle Database 10g リリース1から10g リリース2以降にアップグレードすると、CREATE EXTERNAL JOBがCREATE JOB権限を持つすべてのユーザーとロールに対して自動的に付与されます。必要のないユーザーに対してはこの権限を取り消すことをお薦めします。

スケジューラのインポート/エクスポート

スケジューラ・オブジェクトをエクスポートするには、データ・ポンプ・ユーティリティ(impdpおよびexpdp)を使用します。スケジューラでは、以前のインポートおよびエクスポート・ユーティリティ(IMPおよびEXP)は使用できません。また、スケジューラ・オブジェクトは、データベースが読取り専用モードの間はエクスポートできません。

エクスポートでは、スケジューラ・オブジェクトの作成に使用されたDDLが生成されます。すべての属性がエクスポートされます。インポートが実行されると、すべてのデータベース・オブジェクトが新規データベースに再作成されます。すべてのスケジュールは、それぞれのタイム・ゾーンで格納され、新規データベース内で保持されます。たとえば、「サンフランシスコにあるデータベースの月曜日午後1時(太平洋沿岸標準時)」というスケジュールは、エクスポートされドイツでデータベースにインポートされた場合でも同じです。

スケジューラの資格証明はエクスポートされますが、セキュリティ上の理由で、これらの資格証明のパスワードはエクスポートされません。スケジューラの資格証明をインポートした後は、DBMS_SCHEDULERパッケージのSET_ATTRIBUTEプロシージャを使用してパスワードを再設定する必要があります。

関連項目:
データ・ポンプの詳細は、『Oracle Databaseユーティリティ』を参照してください。

スケジューラのトラブルシューティング

ここでは、トラブルシューティングに関する情報を提供します。この項の内容は、次のとおりです。

- ジョブが実行されない

- プログラムが無効化される

- ウィンドウの有効化に失敗する

ジョブが実行されない

ジョブはいくつかの理由で実行に失敗する場合があります。実行されなかった可能性のあるジョブのトラブルシューティングを開始するには、次の文を発行して、ジョブの状態を確認します。

SELECT JOB_NAME, STATE FROM DBA_SCHEDULER_JOBS;

標準的な出力は次のようになります。

JOB_NAME                       STATE
------------------------------ ---------
MY_EMP_JOB                     DISABLED
MY_EMP_JOB1                    FAILED
MY_NEW_JOB1                    DISABLED
MY_NEW_JOB2                    BROKEN
MY_NEW_JOB3                    COMPLETED

ジョブの状態の概要

ジョブが実行されない場合、次の4つの状態があります。

- 失敗したジョブ

- 中断されたジョブ

- 使用禁止のジョブ

- 完了したジョブ

失敗したジョブ

ジョブ表内のジョブのステータスがFAILEDの場合、そのジョブは実行がスケジュールされたが実行に失敗したことを示します。ジョブが再起動可能として指定されていた場合は、すべての再試行に失敗しています。

実行の途中でジョブが失敗すると、最後のトランザクションのみがロールバックされます。複数のトランザクションを実行するジョブの場合は、restartableをTRUEに設定するときに注意する必要があります。失敗したジョブを問い合せるには、*_SCHEDULER_JOB_RUN_DETAILSビューを問い合せます。

中断されたジョブ

中断されたジョブとは、特定の失敗数を超えたジョブです。この数はmax_failuresで設定され、変更できます。中断されたジョブは、ジョブ全体が中断されており、修正されるまで実行されません。デバッグとテストには、RUN_JOBプロシージャを使用できます。

中断されたジョブを問い合せるには、*_SCHEDULER_JOBSおよび*_SCHEDULER_JOB_LOGビューを問い合せます。

使用禁止のジョブ

ジョブは次の理由で使用禁止になる場合があります。

- 手動で使用禁止にされた場合

- ジョブが属しているジョブ・クラスが削除された場合

- ジョブが指し示しているプログラム、チェーンまたはスケジュールが削除された場合

- ウィンドウまたはウィンドウ・グループがジョブのスケジュールとなっているときに、そのウィンドウまたはウィンドウ・グループが削除された場合

完了したジョブ

ジョブは、end_dateまたはmax_runsに達すると完了します。(最近正常に完了したジョブが再度実行するようにスケジュールされると、ジョブの状態はSCHEDULEDになります。)

ジョブ・ログの表示

ジョブ・ログは、重要なトラブルシューティング・ツールです。詳細および手順は、「ジョブ・ログの表示」を参照してください。

リモート・ジョブのトラブルシューティング

リモート・ジョブは、リモート・ホスト上のスケジューラ・エージェントと正常にやり取りする必要があります。リモート・ジョブが実行されない場合は、まずDBA_SCHEDULER_JOBSビューとジョブ・ログを確認してください。次に、次の手順を実行します。

1. nslookupやpingなどのツールを使用して、リモート・システムがネットワーク上で到達可能であることを確認します。

2. GET_AGENT_VERSIONパッケージ・プロシージャをコールして、リモート・ホストでスケジューラ・エージェントの状態を確認します。

DECLARE
versionnum VARCHAR2(30);
BEGIN
versionnum := DBMS_SCHEDULER.GET_AGENT_VERSION('remote_host.example.com');
DBMS_OUTPUT.PUT_LINE(versionnum);
END;
/

エラーが生成された場合、エージェントがインストールされていないか、ローカル・データベースで登録されていない可能性があります。スケジューラ・エージェントのインストール、登録および起動手順は、「リモート・ジョブを実行するためのデータベースの設定の有効化と無効化」を参照してください。

障害後のジョブ・リカバリの概要

スケジューラは、次の場合に中断されたジョブのリカバリを試行します。

- データベースが異常停止した場合

- ジョブ・スレーブ・プロセスが強制終了したか、失敗した場合

- 外部ジョブの場合に、実行可能ファイルまたはスクリプトを起動する外部ジョブ・プロセスが強制終了したか、失敗した場合(UNIXでは、外部ジョブ・プロセスはextjobです。Windowsでは、外部ジョブ・サービスです。)

- 外部ジョブの場合に、エンド・ユーザーの実行可能ファイルまたはスクリプトを起動するプロセスが強制終了したか、失敗した場合。

ジョブ・リカバリは次のように実行されます。

- スケジューラにより、障害が発生したときに実行されていたジョブのインスタンスについて、ジョブ・ログにエントリが追加されます。ログ・エントリでは、OPERATIONはRUN、STATUSはSTOPPEDになっており、ADDITIONAL_INFOには次のいずれかが挿入されます。

- REASON=ジョブ・スレーブ・プロセスは終了しました

- REASON=ORA-01014: Oracleのシャットダウン処理中です。

- そのジョブのrestartableがTRUEに設定されている場合は、ジョブが再開されます。

- restartableがFALSEに設定されている場合は、次のようになります。

- ジョブが1回のみ実行されるジョブであり、auto_dropがTRUEに設定されている場合は、ジョブの実行が完了するとそのジョブは削除されます。

- ジョブが1回のみ実行されるジョブであり、auto_dropがFALSEに設定されている場合は、ジョブが使用禁止になり、そのジョブの状態stateはSTOPPEDに設定されます。

- ジョブが繰返しジョブの場合、スケジューラは次回のジョブの実行をスケジュールし、そのジョブの状態stateはSCHEDULEDに設定されます。

このリカバリ・プロセスの結果、ジョブが再開されると、新規実行はRECOVERY_RUN操作としてジョブ・ログに記録されます。

プログラムが無効化される

プログラムは、プログラム引数が削除された場合やnumber_of_argumentsの変更ですべての引数を定義できなくなった場合に使用禁止になります。

プログラムの詳細は、「ジョブを定義するためのプログラムの作成および管理」を参照してください。

ウィンドウの有効化に失敗する

ウィンドウは、次の場合に有効化できません。

- スケジュールの終了時にウィンドウが使用禁止にされた場合

- すでに存在しないスケジュールを指すウィンドウが使用禁止にされた場合

ウィンドウの詳細は、「ウィンドウを使用したジョブ・スケジューリングとジョブ優先度の管理」を参照してください。

スケジューラの使用例

このセクションのトピックは次のとおりです:

- ジョブ・クラスの作成例

- 属性の設定例

- チェーンの作成例

- イベントに基づくジョブとスケジュールの作成例

- Oracle Data Guard環境でのジョブの作成例

ジョブ・クラスの作成例

この項では、ジョブ・クラスの作成例をいくつか示します。ジョブ・クラスを作成するには、CREATE_JOB_CLASSプロシージャを使用します。

例30-1 ジョブ・クラスの作成

次の文ではジョブ・クラスが作成されます。

BEGIN
DBMS_SCHEDULER.CREATE_JOB_CLASS (
job_class_name              =>  'my_class1',
service                     =>  'my_service1',
comments                    =>  'This is my first job class');
END;
/

これにより、my_class1がSYSに作成されます。ここでは、my_service1というサービスが使用されています。ジョブ・クラスが作成されたことを確認するには、次の文を発行します。

SELECT JOB_CLASS_NAME FROM DBA_SCHEDULER_JOB_CLASSES
WHERE JOB_CLASS_NAME = 'MY_CLASS1';

JOB_CLASS_NAME
------------------------------
MY_CLASS1

例30-2 ジョブ・クラスの作成

次の文ではジョブ・クラスが作成されます。

BEGIN
DBMS_SCHEDULER.CREATE_JOB_CLASS (
job_class_name             =>  'finance_jobs',
resource_consumer_group    =>  'finance_group',
service                    =>  'accounting',
comments                   =>  'All finance jobs');
END;
/

これにより、finance_jobsがSYSに作成されます。finance_groupというリソース・コンシューマ・グループが割り当てられ、accountingサービス用のサービス・アフィニティが指定されています。accountingサービスがfinance_group以外のリソース・コンシューマ・グループにマップされている場合は、resource_consumer_group属性が優先されるので、このクラスのジョブはfinance_groupコンシューマ・グループで実行されることに注意してください。

関連項目:
CREATE_JOB_CLASSプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。詳細は、「ジョブ・クラスの作成」を参照してください。

属性の設定例

この項では、属性の設定例をいくつか示します。属性を設定するには、SET_ATTRIBUTEおよびSET_SCHEDULER_ATTRIBUTEプロシージャを使用します。

例30-3 繰返し間隔属性の設定

次の例では、my_emp_job1が日次で実行されるように頻度が再設定されます。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE (
name           =>   'my_emp_job1',
attribute      =>   'repeat_interval',
value          =>   'FREQ=DAILY');
END;
/

変更されたことを確認するには、次の文を発行します。

SELECT JOB_NAME, REPEAT_INTERVAL FROM DBA_SCHEDULER_JOBS
WHERE JOB_NAME =  'MY_EMP_JOB1';

JOB_NAME             REPEAT_INTERVAL
----------------     ---------------
MY_EMP_JOB1          FREQ=DAILY

例30-4 一連のジョブに対する複数のジョブ属性の設定

次の例では、5つの各ジョブに4つの異なる属性が設定されます。

DECLARE
newattr sys.jobattr;
newattrarr sys.jobattr_array;
j number;
BEGIN
-- Create new JOBATTR array
newattrarr := sys.jobattr_array();

-- Allocate enough space in the array
newattrarr.extend(20);
j := 1;
FOR i IN 1..5 LOOP
-- Create and initialize a JOBATTR object type
newattr := sys.jobattr(job_name => 'TESTJOB' || to_char(i),
attr_name => 'MAX_FAILURES',
attr_value => 5);
-- Add it to the array.
newattrarr(j) := newattr;
j := j + 1;
newattr := sys.jobattr(job_name => 'TESTJOB' || to_char(i),
attr_name => 'COMMENTS',
attr_value => 'Test job');
newattrarr(j) := newattr;
j := j + 1;
newattr := sys.jobattr(job_name => 'TESTJOB' || to_char(i),
attr_name => 'END_DATE',
attr_value => systimestamp + interval '24' hour);
newattrarr(j) := newattr;
j := j + 1;
newattr := sys.jobattr(job_name => 'TESTJOB' || to_char(i),
attr_name => 'SCHEDULE_LIMIT',
attr_value => interval '1' hour);
newattrarr(j) := newattr;
j := j + 1;
END LOOP;

-- Call SET_JOB_ATTRIBUTES to set all 20 set attributes in one transaction
DBMS_SCHEDULER.SET_JOB_ATTRIBUTES(newattrarr, 'TRANSACTIONAL');
END;
/

関連項目:
SET_SCHEDULER_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。「スケジューラのプリファレンスの設定」を参照してください。

チェーンの作成例

この項では、チェーンの作成例を示します。チェーンを作成するには、CREATE_CHAINプロシージャを使用します。チェーンを作成した後、DEFINE_CHAIN_STEPまたはDEFINE_CHAIN_EVENT_STEPプロシージャを使用してチェーンにステップを追加し、DEFINE_CHAIN_RULEプロシージャを使用してルールを定義します。

例30-5 チェーンの作成

次の例では、my_program2およびmy_program3の前にmy_program1を実行するチェーンが作成されます。my_program1の完了後、my_program2およびmy_program3は、並行して実行されます。

この例のユーザーには、CREATE EVALUATION CONTEXT、CREATE RULEおよびCREATE RULE SET権限が必要です。詳細は、「チェーンの各権限の設定」を参照してください。

BEGIN
DBMS_SCHEDULER.CREATE_CHAIN (
chain_name            =>  'my_chain1',
rule_set_name         =>  NULL,
evaluation_interval   =>  NULL,
comments              =>  NULL);
END;
/

--- define three steps for this chain. Referenced programs must be enabled.
BEGIN
DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain1', 'stepA', 'my_program1');
DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain1', 'stepB', 'my_program2');
DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain1', 'stepC', 'my_program3');
END;
/

--- define corresponding rules for the chain.
BEGIN
DBMS_SCHEDULER.DEFINE_CHAIN_RULE('my_chain1', 'TRUE', 'START stepA');
DBMS_SCHEDULER.DEFINE_CHAIN_RULE (
'my_chain1', 'stepA COMPLETED', 'Start stepB, stepC');
DBMS_SCHEDULER.DEFINE_CHAIN_RULE (
'my_chain1', 'stepB COMPLETED AND stepC COMPLETED', 'END');
END;
/

--- enable the chain
BEGIN
DBMS_SCHEDULER.ENABLE('my_chain1');
END;
/

--- create a chain job to start the chain daily at 1:00 p.m.
BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name        => 'chain_job_1',
job_type        => 'CHAIN',
job_action      => 'my_chain1',
repeat_interval => 'freq=daily;byhour=13;byminute=0;bysecond=0',
enabled         => TRUE);
END;
/

例30-6 チェーンの作成

次の例では、最初にmy_program1を実行してチェーンを作成します。正常に実行された場合はmy_program2、失敗した場合はmy_program3が実行されます。

BEGIN
DBMS_SCHEDULER.CREATE_CHAIN (
chain_name            => 'my_chain2',
rule_set_name         => NULL,
evaluation_interval   => NULL,
comments              => NULL);
END;
/

--- define three steps for this chain.
BEGIN
DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain2', 'step1', 'my_program1');
DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain2', 'step2', 'my_program2');
DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain2', 'step3', 'my_program3');
END;
/

--- define corresponding rules for the chain.
BEGIN
DBMS_SCHEDULER.DEFINE_CHAIN_RULE ('my_chain2', 'TRUE', 'START step1');
DBMS_SCHEDULER.DEFINE_CHAIN_RULE (
'my_chain2', 'step1 SUCCEEDED', 'Start step2');
DBMS_SCHEDULER.DEFINE_CHAIN_RULE (
'my_chain2', 'step1 COMPLETED AND step1 NOT SUCCEEDED', 'Start step3');
DBMS_SCHEDULER.DEFINE_CHAIN_RULE (
'my_chain2', 'step2 COMPLETED OR step3 COMPLETED', 'END');
END;
/

関連項目:
CREATE_CHAIN、DEFINE_CHAIN_STEPおよびDEFINE_CHAIN_RULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。「スケジューラのプリファレンスの設定」を参照してください。

イベントに基づくジョブとスケジュールの作成例

この項では、イベント・ベースのジョブおよびイベント・スケジュールの作成例を示します。イベント・ベースのジョブを作成するには、CREATE_JOBプロシージャを使用します。イベント・ベースのスケジュールを作成するには、CREATE_EVENT_SCHEDULEプロシージャを使用します。

これらの例では、アプリケーションでシステムにファイルが到着したことが検出されたときに、イベントをmy_events_qキューにエンキューするアプリケーションがあることを想定しています。

例30-7 イベント・ベースのスケジュールの作成

次の例では、午前9時前にファイルがシステムに到着したことを示すイベントをスケジューラが受信するたびに、ジョブの開始に使用可能なスケジュールを作成する方法を示しています。

BEGIN
DBMS_SCHEDULER.CREATE_EVENT_SCHEDULE (
schedule_name     =>  'scott.file_arrival',
start_date        =>  systimestamp,
event_condition   =>  'tab.user_data.object_owner = ''SCOTT''
and tab.user_data.event_name = ''FILE_ARRIVAL''
and extract hour from tab.user_data.event_timestamp < 9',
queue_spec        =>  'my_events_q');
END;
/

例30-8 イベント・ベースのジョブの作成

次の例では、ファイルがシステムに到着したことを示すイベントをスケジューラが受信したときに開始されるジョブを作成しています。

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name            =>  my_job,
program_name        =>  my_program,
start_date          =>  '15-JUL-04 1.00.00AM US/Pacific',
event_condition     =>  'tab.user_data.event_name = ''LOW_INVENTORY''',
queue_spec          =>  'my_events_q'
enabled             =>  TRUE,
comments            =>  'my event-based job');
END;
/

関連項目:
CREATE_JOBおよびCREATE_EVENT_SCHEDULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

Oracle Data Guard環境でのジョブの作成例

Oracle Data Guard環境では、スケジューラには、2つのデータベース・ロール(プライマリとロジカル・スタンバイ)に対する追加のサポートが含まれています。データベースのロールがプライマリの場合のみ、またはデータベースのロールがロジカル・スタンバイの場合のみ、ジョブが実行されるように構成できます。そのためには、database_role属性を設定します。この例では、両方のデータベース・ロールでジョブを実行できるようにする方法を説明します。ジョブのコピーを2つ作成し、それぞれに異なるdatabase_roleを割り当てる方法を使用します。

デフォルトでは、ジョブが実行されるのは、データベースのロールがそのジョブの作成時と同じロールの場合です。両方のロールで同じジョブを実行する手順は、次のとおりです。

1. ジョブをコピーします。

2. 新しいジョブを使用可能にします。

3. 新しいジョブのdatabase_role属性を必要なロールに変更します。

この例では、まずprimary_jobというジョブをプライマリ・データベースに作成しています。次に、このジョブのコピーを作成して、そのdatabase_role属性を「LOGICAL STANDBY」に設定しています。プライマリ・データベースがロジカル・スタンバイになった場合は、そのスケジュールに従ってジョブが引き続き実行されます。

ジョブをコピーした場合、新しいジョブは使用禁止になっているため、使用可能にする必要があります。

BEGIN DBMS_SCHEDULER.CREATE_JOB (
job_name       => 'primary_job',
program_name   => 'my_prog',
schedule_name  => 'my_sched');

DBMS_SCHEDULER.COPY_JOB('primary_job','standby_job');
DBMS_SCHEDULER.ENABLE(name=>'standby_job', commit_semantics=>'ABSORB_ERRORS');
DBMS_SCHEDULER.SET_ATTRIBUTE('standby_job','database_role','LOGICAL STANDBY');
END;
/

この例を実行すると、DBA_SCHEDULER_JOB_ROLESビューのデータは、次のようになります。

SELECT JOB_NAME, DATABASE_ROLE FROM DBA_SCHEDULER_JOB_ROLES
WHERE JOB_NAME IN ('PRIMARY_JOB','STANDBY_JOB');

JOB_NAME               DATABASE_ROLE
--------               ----------------
PRIMARY_JOB            PRIMARY
STABDBY_JOB            LOGICAL STANDBY

注意:
フィジカル・スタンバイ・データベースの場合、スケジューラのオブジェクトに対する変更またはプライマリ・データベース上のスケジューラのジョブによるデータベースの変更は、他のデータベースの変更と同様にフィジカル・スタンバイに適用されます。

スケジューラの参照情報

この項には、Oracle Schedulerの参考情報が説明されています。内容は次のとおりです。

- スケジューラ権限

- スケジューラのデータ・ディクショナリ・ビュー

スケジューラ権限

表30-3「スケジューラのシステム権限」および表30-4「スケジューラのオブジェクト権限」に、スケジューラの様々な権限を説明します。

表30-3 スケジューラのシステム権限

権限名

許可されている操作

CREATE JOB

自分のスキーマ内にジョブ、チェーン、スケジュール、プログラム、File Watcher、資格証明、宛先およびグループを作成できます。CREATE JOB権限がなくても、自分のスキーマ内でのこれらのオブジェクトの変更および削除はいつでも可能です。この場合、CREATE ANY JOB権限を持つ別のユーザーによって、スキーマ内にそのオブジェクトが作成されます。

CREATE ANY JOB

SYS以外の任意のスキーマ内でジョブ、チェーン、スケジュール、プログラム、File Watcher、資格証明、宛先およびグループを作成、変更および削除できます。これは非常に強力な権限で、権限受領者は任意の他のデータベース・ユーザーでPL/SQLコードを実行できるため、慎重に使用してください。

CREATE EXTERNAL JOB

この権限はデータベース外で実行するジョブを作成する場合に必要です。EXECUTABLEタイプのジョブの所有者、またはEXECUTABLEタイプのプログラムを指し示すジョブの所有者にはこの権限が必要です。EXECUTABLEタイプのジョブを実行する場合は、この権限およびCREATE JOB権限が必要です。リモート・ホストからファイルを取得したり、1つ以上のリモート・ホストにファイルを保存する場合も、この権限が必要です。

EXECUTE ANY PROGRAM

自分のジョブに任意のスキーマのプログラムまたはチェーンを使用できます。

EXECUTE ANY CLASS

自分のジョブを任意のジョブ・クラスの下で実行できます。

MANAGE SCHEDULER

これはスケジューラを管理するための最も重要な権限です。ジョブ・クラス、ウィンドウおよびウィンドウ・グループの作成、変更および削除、forceオプションによるジョブの停止を行えます。スケジューラ属性の設定と取得、スケジューラ・ログのパージ、データベースのエージェント・パスワードの設定も行えます。

表30-4 スケジューラのオブジェクト権限

権限名

許可されている操作

SELECT

SELECTをグループに付与することによって、グループのオブジェクト権限を他のユーザーに付与できます。

EXECUTE

この権限はプログラム、チェーン、File Watcher、資格証明およびジョブ・クラスのみに付与できます。EXECUTE権限では、ジョブのオブジェクトを参照できます。オブジェクトが自分のスキーマで作成されたのではない場合に、オブジェクトを表示することもできます。

ALTER

権限付与されているオブジェクトを変更または削除できます。変更操作には、プログラム引数の使用可能化、使用禁止化、定義または削除、ジョブ引数値の設定または再設定、およびジョブの実行などの操作が含まれます。ジョブ・タイプEXECUTABLEのジョブの制限付きの特定の属性は、ALTERオブジェクト権限を使用して変更できません。これには、job_type、job_action、number_of_arguments、event_spec、スケジュールとしてのPL/SQL日付関数の設定が含まれます。

プログラム、ジョブ、チェーン、File Watcherおよび資格証明の場合には、この権限により、これらのオブジェクトを所有しないスキーマを使用可能にして表示することもできます。この権限は、ジョブ、チェーン、プログラム、スケジュール、File Watcherおよび資格証明に対してのみ付与できます。他のタイプのスケジューラ・オブジェクトに対しては、MANAGE SCHEDULERシステム権限を付与する必要があります。

ALL

この権限では、指定したオブジェクトに対して他のすべてのオブジェクト権限で許可されている操作が可能です。これは、ジョブ、プログラム、チェーン、スケジュール、File Watcher、資格証明およびジョブ・クラスに付与できます。

注意:
別のユーザーによって作成された宛先オブジェクトを使用する場合に、オブジェクト権限は必要ありません。

SCHEDULER_ADMINロールは、表30-3に記載されているすべてのシステム権限付き(ADMINオプション付き)で作成されます。SCHEDULER_ADMINロールはDBA(ADMINオプション付き)に付与されます。

DBMS_SCHEDULERパッケージでは、ロールを通じてジョブやチェーンなどのSchedulerオブジェクトに対して付与される権限は無視されます。オブジェクト権限は、ユーザーに直接付与する必要があります。

SELECT ALL_SCHEDULER_*ビュー、SELECT USER_SCHEDULER_* ビュー、SELECT SYS.SCHEDULER$_JOBSUFFIX_S(ジョブ名生成用)、およびEXECUTE SYS.DEFAULT_JOB_CLASSの各オブジェクト権限が、PUBLICに付与されます。

スケジューラのデータ・ディクショナリ・ビュー

スケジューラの情報は、多数のビューで確認できます。次に、my_job1の完了したインスタンスに関する情報の表示例を示します。

SELECT JOB_NAME, STATUS, ERROR#
FROM DBA_SCHEDULER_JOB_RUN_DETAILS WHERE JOB_NAME = 'MY_JOB1';

JOB_NAME     STATUS           ERROR#
--------     --------------   ------
MY_JOB1      FAILURE           20000

表30-5に、スケジューラに関連付けられたビューを示します。*_SCHEDULER_JOBS、*_SCHEDULER_SCHEDULES、*_SCHEDULER_PROGRAMS、*_SCHEDULER_RUNNING_JOBS、*_SCHEDULER_JOB_LOGおよび *_SCHEDULER_JOB_RUN_DETAILSの各ビューは、ジョブの管理に特に役立ちます。スケジューラのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

注意:
次の表のビュー名の先頭にあるアスタリスクは、DBA、ALLまたはUSERで置換されます。

表30-5 スケジューラのビュー

ビュー

説明

*_SCHEDULER_CHAIN_RULES

すべてのチェーンについて、すべてのルールが表示されます。

*_SCHEDULER_CHAIN_STEPS

すべてのチェーンについて、すべてのステップが表示されます。

*_SCHEDULER_CHAINS

すべてのチェーンが表示されます。

*_SCHEDULER_CREDENTIALS

すべての資格証明が表示されます。

*_SCHEDULER_DB_DESTS

すべてのデータベース宛先が表示されます。

*_SCHEDULER_DESTS

すべてのデータベース宛先と外部宛先が表示されます。

*_SCHEDULER_EXTERNAL_DESTS

すべての外部宛先が表示されます。

*_SCHEDULER_FILE_WATCHERS

すべてのFile Watcherが表示されます。

*_SCHEDULER_GLOBAL_ATTRIBUTE

スケジューラ属性の現行値が表示されます。

*_SCHEDULER_GROUP_MEMBERS

すべてのグループのすべてのグループ・メンバーが表示されます。

*_SCHEDULER_GROUPS

すべてのグループが表示されます。

*_SCHEDULER_JOB_ARGS

すべてのジョブについて、すべての引数の設定値が表示されます。

*_SCHEDULER_JOB_CLASSES

すべてのジョブ・クラスが表示されます。

*_SCHEDULER_JOB_DESTS

これらのビューには、複数の宛先のジョブの子ジョブを含む、ローカル・ジョブとリモート宛先のジョブの両方の状態が表示されます。これらのビューからジョブ宛先ID (job_dest_id)を取得します。

*_SCHEDULER_JOB_LOG

設定されているロギング・レベルに応じて、ジョブの実行と状態変化が表示されます。

*_SCHEDULER_JOB_ROLES

Oracle Data Guardデータベース・ロールによるすべてのジョブが表示されます。

*_SCHEDULER_JOB_RUN_DETAILS

完了(失敗または成功)したすべてのジョブ実行が表示されます。

*_SCHEDULER_JOBS

すべてのジョブ(使用可能なジョブと使用禁止のジョブ)が表示されます。

*_SCHEDULER_NOTIFICATIONS

すべてのジョブの状態の電子メール通知が表示されます。

*_SCHEDULER_PROGRAM_ARGS

すべてのプログラムに定義されているすべての引数が、デフォルト値(存在する場合)とともに表示されます。

*_SCHEDULER_PROGRAMS

すべてのプログラムが表示されます。

*_SCHEDULER_RUNNING_CHAINS

実行中のすべてのチェーンが表示されます。

*_SCHEDULER_RUNNING_JOBS

現在実行中のすべてのジョブに関する状態情報が表示されます。

*_SCHEDULER_SCHEDULES

すべてのスケジュールが表示されます。

*_SCHEDULER_WINDOW_DETAILS

完了したすべてのウィンドウの実行が表示されます。

*_SCHEDULER_WINDOW_GROUPS

すべてのウィンドウ・グループが表示されます。

*_SCHEDULER_WINDOW_LOG

ウィンドウに行われた変更の状態がすべて表示されます。

*_SCHEDULER_WINDOWS

すべてのウィンドウが表示されます。

*_SCHEDULER_WINGROUP_MEMBERS

すべてのウィンドウ・グループのメンバーが、グループ・メンバーごとに1行ずつ表示されます。

第V部

分散データベースの管理

第V部では、分散データベース環境の管理について説明します。次の章で構成されます。

- 第31章「分散データベースの概念」

- 第32章「分散データベースの管理」

- 第33章「分散データベース・システムのアプリケーション開発」

- 第34章「分散トランザクションの概念」

- 第35章「分散トランザクションの管理」

31 分散データベースの概念

この章の内容は、次のとおりです。

- 分散データベース・アーキテクチャ

- データベース・リンク

- 分散データベースの管理

- 分散システムでのトランザクション処理

- 分散データベース・アプリケーションの開発

- 分散環境でのキャラクタ・セットのサポート

分散データベース・アーキテクチャ

分散データベース・システムを使用すると、アプリケーションはローカル・データベースおよびリモート・データベースのデータにアクセスできます。同機種間分散データベース・システムでは、個々のデータベースはOracle Databaseです。異機種間分散データベース・システムでは、少なくともデータベースの1つがOracle Database以外のデータベースです。分散データベースは、クライアント/サーバー・アーキテクチャを使用して情報の要求を処理します。

この項の内容は次のとおりです。

- 同機種間分散データベース・システム

- 異機種間分散データベース・システム

- クライアント/サーバー・データベース・アーキテクチャ

同機種間分散データベース・システム

同機種間分散データベース・システムとは、1つ以上のシステムに存在する2つ以上のOracle Databaseのネットワークを表します。図31-1は、hq、mfgおよびsalesの3つのデータベースを接続している分散システムを示しています。アプリケーションは、1つの分散環境内にある複数のデータベースのデータに同時にアクセスしたり、データを同時に変更できます。たとえば、ローカル・データベースmfgの製造(Mfg)クライアントから発行する1回の問合せによって、ローカル・データベースのproducts表のデータとリモート・データベースhqのdept表のデータを結合したデータを取得できます。

クライアント・アプリケーションに対して、データベースの位置とプラットフォームは透過的です。また、分散システム内のリモート・オブジェクトに対してユーザーがローカル・オブジェクトと同じ構文を使用してアクセスできるように、リモート・オブジェクトのシノニムを作成することもできます。たとえば、mfgデータベースに接続しているときにデータベースhqのデータにアクセスする場合は、リモートのdept表に対するシノニムをmfg上に作成することで、次の問合せを発行できます。

SELECT * FROM dept;

このように、分散システムではローカル・データベースと同様のデータ・アクセスが可能です。mfgのユーザーは、アクセスするデータがリモート・データベースに存在していることを知る必要はありません。

図31-1 同機種間分散データベース

Oracle Databaseの分散データベース・システムは、異なるバージョンのOracle Databaseで構成することが可能です。サポートされているOracle Databaseのリリースは、すべて分散データベース・システムに加わることができます。しかし、分散データベースを使用するアプリケーションでは、システムの各ノードで使用可能な機能を理解しておく必要があります。分散データベース・アプリケーションでは、Oracle Databaseでのみ使用可能なSQLの拡張をOracle7で実行できるかのような想定を行ってはなりません。

分散データベースと分散処理

分散データベースおよび分散処理という用語は密接に関連していますが、その意味は異なります。この2つの用語の定義は、次のとおりです。

- 分散データベース
分散システムを構成する一連のデータベース。アプリケーションからは単一のデータソースのように見えます。

- 分散処理
アプリケーションが自身のタスクをネットワーク内の異なるコンピュータ間に分散するときに発生する操作。たとえば、データベース・アプリケーションは通常、フロントエンド側のプレゼンテーション・タスクをクライアント・コンピュータに配置し、バックエンド側のデータベース・サーバーでデータベースへの共有アクセスを管理できるようにします。このことから、分散データベース・アプリケーション処理システムは、一般にクライアント/サーバー・データベース・アプリケーション・システムとも呼ばれます。

分散データベース・システムは、分散処理アーキテクチャを利用しています。たとえば、Oracle Databaseサーバーは、別のOracle Databaseサーバーが管理しているデータを要求するときにクライアントとして動作します。

分散データベースとレプリケート・データベース

分散データベース・システムおよびデータベース・レプリケーションという用語は関連していますが、その意味は異なります。純粋な(つまり、レプリケートされていない)分散データベースでは、すべてのデータとそれをサポートしているデータベース・オブジェクトの単一コピーが管理されています。通常、分散データベース・アプリケーションは、分散トランザクションを使用してローカルおよびリモートのデータにアクセスし、グローバル・データベースをリアルタイムで変更します。

注意:
このマニュアルでは、純粋な分散データベースについてのみ説明しています。

レプリケーションという用語は、分散システムに属している複数のデータベースの間でデータベース・オブジェクトをコピーし、管理する操作を指します。レプリケーションは分散データベース・テクノロジに依存していますが、データベース・レプリケーションを使用すると、純粋な分散データベース環境では得られないような利点をアプリケーションが利用できます。

一般に、レプリケーションを使用すると代替のデータ・アクセス手段が提供されるので、ローカル・データベースのパフォーマンスが向上し、アプリケーションの可用性が保護されます。たとえば、アプリケーションは、ネットワークの通信量を最小限に抑えてパフォーマンスの最大化を図るために、リモート・サーバーではなくローカル・データベースにアクセスできます。また、ローカル・サーバーに障害が発生しても、レプリケートされたデータを持つ他のサーバーにアクセスできれば、アプリケーションは引き続き実行できます。

関連項目:

- Oracle Databaseのレプリケーション機能の詳細は、『Oracle Databaseアドバンスト・レプリケーション』を参照してください。

- Oracle Streams、つまりデータベース間で情報を共有する別の方法については、『Oracle Streams概要および管理』を参照してください。

異機種間分散データベース・システム

異機種間分散データベース・システムでは、少なくともデータベースの1つがOracle Database以外のシステムです。アプリケーションにとって、異機種間分散データベース・システムは1つのローカルなOracle Databaseのように見えます。ローカルのOracle Databaseサーバーでは、データの分散と異機種性は隠されています。

Oracle Databaseサーバーは、Oracle Database以外のシステムへのアクセスに、Oracle異機種間サービスとエージェントを使用します。Oracle Database以外のデータ・ストアにOracle Transparent Gatewayを使用してアクセスする場合、エージェントはシステム固有のアプリケーションになります。たとえば、Oracle Database分散システムにSybaseデータベースを含める場合は、そのシステム内のOracle DatabaseがSybaseデータベースとやり取りできるように、Sybase固有のTransparent Gatewayを入手する必要があります。

Oracle Database以外のシステムがODBCまたはOLE DBプロトコルをサポートしている場合は、かわりにGeneric Connectivityを使用してOracle Database以外のデータ・ストアにアクセスできます。

注意:
このマニュアルでOracle異機種間サービスについて説明しているのは、この章の概要的な内容のみです。異機種間サービスの詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

異機種間サービス

異機種間サービスはOracle Databaseサーバー内部に統合されたコンポーネントであり、現在のOracle Transparent Gateway製品群を実現するためのテクノロジです。異機種間サービスは、Oracle Databaseゲートウェイ製品とその他の異機種間アクセス機能に対して共通のアーキテクチャと管理のメカニズムを提供します。また、以前にリリースされたほとんどのOracle Transparent Gatewayのユーザーに上位互換の機能を提供します。

Transparent Gatewayエージェント

Oracle Database以外の個々のシステムにアクセスする場合、異機種間サービスはTransparent Gatewayエージェントを使用して、Oracle Database以外の特定のシステムとのインタフェースの役目を果たします。エージェントはOracle Database以外のシステムに固有のものであり、システムのタイプごとに異なるエージェントが必要になります。

Transparent Gatewayエージェントは、Oracle Databaseサーバー内の異機種間サービス・コンポーネントを使用して、Oracle DatabaseシステムとOracle Database以外のシステムとの間のやり取りを容易にします。エージェントはOracle Databaseサーバーのかわりに、Oracle Database以外のシステムでSQLとトランザクション要求を実行します。

関連項目:
Transparent Gatewayの詳細は、オラクル社が提供するゲートウェイ固有のマニュアルを参照してください。

Generic Connectivity

Generic Connectivityを使用すると、異機種間サービスODBCエージェントまたは異機種間サービスOLE DBエージェントのどちらかを使用してOracle Database以外のデータ・ストアに接続できます。これらはどちらもOracle製品に標準機能として組み込まれています。ODBCまたはOLE DBの規格と互換性があれば、どのようなデータソースでもGeneric Connectivityエージェントを使用してアクセスできます。

Generic Connectivityの利点は、必ずしもシステム固有のエージェントを別途購入して構成する必要がないことです。ODBCドライバまたはOLE DBドライバを使用して、エージェントとインタフェースできます。ただし、一部のデータ・アクセス機能はTransparent Gatewayエージェントでしか利用できません。

クライアント/サーバー・データベース・アーキテクチャ

データベース・サーバーとはデータベースを管理するOracleソフトウェアのことであり、クライアントとはサーバーの情報を要求するアプリケーションのことです。ネットワーク内の各コンピュータはノードと呼ばれ、1つ以上のデータベースのホストとなることができます。分散データベース・システム内の各ノードは、状況に応じてクライアント、サーバー、あるいはその両方として機能します。

図31-2のhqデータベースのホストは、そのローカル・データに対して文が発行されたときはデータベース・サーバーとして機能します。たとえば、トランザクション内の2番目の文は、ローカルのdept表に対して文を発行しています。しかし、リモート・データに対して文が発行されたときはクライアントとして機能します。たとえば、トランザクション内の最初の文は、salesデータベース内のリモートの表empに対して発行されています。

図31-2 Oracle Databaseの分散データベース・システム

クライアントは、データベース・サーバーに直接または間接に接続できます。直接接続となるのは、クライアントがサーバーに接続し、そのサーバー上に存在するデータベースの情報にアクセスするときです。たとえば、図31-2のように、hqデータベースに接続してこのデータベースのdept表にアクセスする場合は、次の文を発行できます。

SELECT * FROM dept;

この場合は、リモート・データベースのオブジェクトにアクセスしていないので、問合せは直接になります。

これに対して、間接接続となるのは、クライアントがサーバーに接続した後、別の異なるサーバー上のデータベースに格納されている情報にアクセスするときです。たとえば、図31-2のように、hqデータベースに接続した後、リモートのsalesデータベースのemp表にアクセスする場合は、次の文を発行できます。

SELECT * FROM emp@sales;

この場合は、アクセスしようとしているオブジェクトが直接接続しているデータベース上にないため、問合せは間接になります。

データベース・リンク

分散データベース・システムの中心的な概念となるのが、データベース・リンクです。データベース・リンクは2つの物理データベース・サーバー間の接続であり、データベース・リンクを使用すると、クライアントから1つの論理データベースとしてこれらのサーバーにアクセスできます。

この項の内容は次のとおりです。

- データベース・リンクの概要

- データベース・リンクを使用する理由

- データベース・リンク内のグローバル・データベース名

- データベース・リンクの名前

- データベース・リンクのタイプ

- データベース・リンクのユーザー

- データベース・リンクの作成: 例

- スキーマ・オブジェクトとデータベース・リンク

- データベース・リンクの制限事項

データベース・リンクの概要

データベース・リンクは、あるOracle Databaseサーバーから別のデータベース・サーバーへの一方向の通信経路を定義するポインタです。リンク・ポインタは、実際にはデータ・ディクショナリ表内のエントリとして定義されます。リンクにアクセスするには、データ・ディクショナリ・エントリのあるローカル・データベースに接続する必要があります。

データベース・リンク接続が一方向であるということは、たとえばローカル・データベースAに接続しているクライアントはデータベースAに格納されているリンクを使用してリモート・データベースBの情報にアクセスできるが、データベースBに接続しているユーザーは同じリンクを使用してデータベースAのデータにアクセスできないことを意味します。データベースBのローカル・ユーザーがデータベースAのデータにアクセスする場合には、データベースBのデータ・ディクショナリに格納されるリンクを定義する必要があります。

データベース・リンク接続を使用することで、ローカル・ユーザーはリモート・データベースのデータにアクセスできるようになります。この接続を実現するためには、分散システム内の各データベースがネットワーク・ドメイン内で一意のグローバル・データベース名を持っていることが必要です。グローバル・データベース名は、分散システム内のデータベース・サーバーを一意に識別します。

図31-3は、ユーザーscottがグローバル名hq.example.comを使用して、リモート・データベースのemp表にアクセスしている例を示します。

図31-3 データベース・リンク

データベース・リンクには、プライベートとパブリックの2種類があります。プライベートの場合は、そのリンクを作成したユーザーのみがアクセスでき、パブリックの場合は、すべてのデータベース・ユーザーがアクセスできます。

データベース・リンクにおける原理的な違いの1つに、リモート・データベースにどのように接続するかという点があります。ユーザーは、次のタイプのリンクによってリモート・データベースにアクセスします。

リンクのタイプ

説明

接続ユーザー・リンク

ユーザーはユーザー自身として接続します。つまり、ユーザーにはローカル・データベースのアカウントと同じユーザー名およびパスワードを持つリモート・データベースのアカウントが必要です。

固定ユーザー・リンク

ユーザーは、リンク内で参照されるユーザー名とパスワードを使用して接続します。たとえば、Janeが、ユーザー名とパスワードscott/passwordでhqデータベースに接続する固定ユーザー・リンクを使用する場合、Janeはscottとして接続し、scottに直接付与されているhq内でのすべての権限と、hqデータベースでscottに付与されているすべてのデフォルト・ロールを持ちます。

現行ユーザー・リンク

ユーザーはグローバル・ユーザーとして接続します。ローカル・ユーザーは、ストアド・プロシージャのコンテキスト内では、グローバル・ユーザーのパスワードをリンク定義に格納せずに、グローバル・ユーザーとして接続できます。たとえば、JaneはScottが記述したプロシージャにアクセスでき、hqデータベース上のScottのアカウントとScottのスキーマにアクセスできます。現行ユーザー・リンクは、Oracle Advanced Securityの機能の1つです。

データベース・リンクを作成するには、CREATE DATABASE LINK文を使用します。リンクを作成した後、SQL文の中でリンクを使用してスキーマ・オブジェクトを指定できます。

関連項目:

- CREATE DATABASE文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。

- Oracle Advanced Securityの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

共有データベース・リンクの概要

共有データベース・リンクとは、ローカル・サーバー・プロセスとリモート・データベースの間のリンクのことです。複数のクライアント・プロセスが同じリンクを同時に使用できるので、共有データベース・リンクと呼ばれます。

ローカル・データベースがデータベース・リンクを介してリモート・データベースに接続するとき、どちらのデータベースも専用サーバー・モードまたは共有サーバー・モードのいずれかで稼働しています。可能な組合せを次の表に示します。

ローカル・データベースのモード

リモート・データベースのモード

専用

専用

専用

共有サーバー

共有サーバー

専用

共有サーバー

共有サーバー

共有データベース・リンクは、これら4つのどの構成でも確立できます。共有リンクは、通常のデータベース・リンクと次の点で異なります。

- データベース・リンクを介して同じスキーマ・オブジェクトにアクセスする異なるユーザーの間で、ネットワーク接続を共有できます。

- ユーザーが特定のサーバー・プロセスからリモート・サーバーに接続を確立するときに、そのプロセスからリモート・サーバーに対してすでに確立されている接続を再利用できます。接続を再利用するには、その接続が同じサーバー・プロセスから同じデータベース・リンクを使用して確立されている必要があります(セッションは異なっていてもかまいません)。非共有のデータベース・リンクでは、接続が複数のセッション間で共有されることはありません。

- 共有サーバー構成で共有データベース・リンクを使用すると、ネットワーク接続はローカル・サーバーの共有サーバー・プロセスの外部で直接に確立されます。ローカル共有サーバーでの非共有のデータベース・リンクでは、この接続はローカル・ディスパッチャを介して確立されるため、ローカル・ディスパッチャのためのコンテキスト・スイッチングが発生し、データがディスパッチャを経由することになります。

関連項目:
共有サーバーの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

データベース・リンクを使用する理由

データベース・リンクの大きな利点として、ユーザーがリモート・データベースにある他のユーザーのオブジェクトに対して、オブジェクトの所有者が持つ権限の制限内でアクセスできるという点があります。つまり、ローカル・ユーザーはリモート・データベースのユーザーにならなくても、リモート・データベースへのリンクにアクセスできます。

たとえば、従業員が経費精算書を買掛管理(A/P)アプリケーションに送信し、さらにA/Pアプリケーションを使用するユーザーが従業員に関する情報をhqデータベースから取得する必要がある場合を想定します。A/Pのユーザーは、必要な情報を取得するために、hqデータベースに接続してリモートのhqデータベース内のストアド・プロシージャを実行できます。A/Pのユーザーは、自分のジョブを実行するためにhqデータベースのユーザーになる必要はなく、プロシージャに記述されている制御された方法でhqの情報にアクセスできればそれで済みます。

関連項目:

- データベース・リンク・ユーザーの詳細は、「データベース・リンクのユーザー」を参照してください。

- パスワードを管理者以外のユーザーから隠す方法の詳細は、「データベース・リンク情報の表示」を参照してください。

データベース・リンク内のグローバル・データベース名

データベース・リンクの動作の仕組みを理解するには、まずグローバル・データベース名について理解する必要があります。分散データベース内の各データベースは、それぞれのグローバル・データベース名によって一意に識別されます。データベースは、DB_NAME初期化パラメータで指定された個々のデータベース名の前に、データベース作成時にDB_DOMAIN初期化パラメータで指定されたデータベース・ネットワーク・ドメインを付けることで、グローバル・データベース名を形成します。

たとえば、図31-4では、ネットワーク全体のデータベースを階層的な配置で表しています。

図31-4 ネットワーク化されたデータベースの階層的な配置

データベースの名前は、ツリーのリーフ(葉)から始まってルート(根)に至るまでの経路によって形成されます。たとえば、mfgデータベースは、comドメインのexample_toolsブランチのdivision3にあります。mfgのグローバル・データベース名は、ツリー内のノードを次のように連結して作成されます。

- mfg.division3.example_tools.com

複数のデータベースが1つの個別名を共有できますが、各データベースのグローバル・データベース名は一意にする必要があります。たとえば、ネットワーク・ドメインus.americas.example_auto.comとuk.europe.example_auto.comには、どちらにもsalesデータベースがあります。グローバル・データベース名の命名体系では、americas部門のsalesデータベースとeurope部門のsalesデータベースが次のように区別されます。

- sales.us.americas.example_auto.com

- sales.uk.europe.example_auto.com

関連項目:
グローバル・データベース名を指定および変更する方法の詳細は、「分散システムでのグローバル名の管理」を参照してください。

ループバック・データベース・リンクとしてのグローバル名

データベースのグローバル名は、データベース・リンクを明示的に作成せずに、ループバック・データベース・リンクとして使用できます。SQL文中のデータベース・リンクが現行データベースのグローバル名と一致すると、データベース・リンクは事実上無視されます。

たとえば、データベースのグローバル名がdb1.example.comであると想定します。このデータベース上で次のSQL文を実行します。

SELECT * FROM hr.employees@db1.example.com;

この場合、SQL文の@db1.example.comの部分が事実上無視されます。

データベース・リンクの名前

通常、データベース・リンクの名前は、参照先のリモート・データベースのグローバル・データベース名と同じです。たとえば、データベースのグローバル・データベース名がsales.us.example.comであれば、データベース・リンクの名前もsales.us.example.comになります。

初期化パラメータGLOBAL_NAMESをTRUEに設定すると、データベース・リンクの名前がリモート・データベースのグローバル・データベース名と同じになることが保証されます。たとえば、hqのグローバル・データベース名がhq.example.comで、GLOBAL_NAMESがTRUEの場合は、リンク名も必ずhq.example.comになります。データベースでチェックされるのはデータ・ディクショナリに保存されているグローバル・データベース名のドメイン部分で、初期化パラメータ・ファイルのDB_DOMAIN設定ではない点に注意してください(「グローバル・データベース名のドメインの変更」を参照)。

初期化パラメータGLOBAL_NAMESをFALSEに設定した場合は、グローバル・ネーミングを使用する必要はありません。データベース・リンクに自由に名前を付けられます。たとえば、hq.example.comへのデータベース・リンクにfooという名前を付けることができます。

注意:
グローバル・ネーミングはレプリケーションなどの多数の機能で必要になるため、グローバル・ネーミングの使用をお薦めします。

グローバル・ネーミングを有効にすると、データベース・リンクの名前がリンクの参照先であるデータベースのグローバル名と同じになるため、データベース・リンクは本質的に分散データベースのユーザーに対して透過的になります。たとえば、次の文は、リモート・データベースsalesへのデータベース・リンクをローカル・データベース内に作成します。

CREATE PUBLIC DATABASE LINK sales.division3.example.com USING 'sales1';

関連項目:
初期化パラメータGLOBAL_NAMESの指定の詳細は、『Oracle Databaseリファレンス』を参照してください。

データベース・リンクのタイプ

Oracle Databaseでは、プライベート、パブリックおよびグローバルのデータベース・リンクを作成できます。これらの基本的なリンク・タイプは、どのユーザーに対してリモート・データベースへのアクセスが許可されているかによって異なります。

タイプ

所有者

説明

プライベート

リンクを作成したユーザー。次のビューによって所有権データを表示できます。

- DBA_DB_LINKS

- ALL_DB_LINKS

- USER_DB_LINKS

ローカル・データベースの特定のスキーマにリンクを作成します。プライベート・データベース・リンクの所有者またはスキーマ内のPL/SQLサブプログラムのみが、このリンクを使用して、対応するリモート・データベース内のデータベース・オブジェクトにアクセスできます。

パブリック

PUBLICと呼ばれるユーザー。プライベート・データベース・リンクと同じビューによって所有権データを表示できます。

データベース全体にわたるリンクを作成します。データベース内のすべてのユーザーとPL/SQLサブプログラムが、パブリック・リンクを使用して、対応するリモート・データベース内のデータベース・オブジェクトにアクセスできます。

グローバル

PUBLICと呼ばれるユーザー。プライベート・データベース・リンクと同じビューによって所有権データを表示できます。

ネットワーク全体にわたるリンクを作成します。Oracleネットワークでディレクトリ・サーバーを使用すると、そのディレクトリ・サーバーは、ネットワーク内のすべてのOracle Databaseに対するグローバル・データベース・リンクを(ネット・サービス名として)自動的に作成および管理します。どのデータベースのユーザーとPL/SQLサブプログラムでも、グローバル・リンクを使用して、対応するリモート・データベース内のオブジェクトにアクセスできます。
注意: Oracle Databaseの以前のリリースでは、グローバル・データベース・リンクはデータベース・リンクと呼ばれ、Oracle Names Serverに登録されていました。Oracle Names Serverの使用は非推奨になりました。このマニュアルでのグローバル・データベース・リンクは、ディレクトリ・サーバーのネット・サービス名の使用を指します。

分散データベースで利用するデータベース・リンクのタイプは、システムを使用しているアプリケーションの仕様要件によって決まります。リンクの選択時には、次の機能を考慮してください。

リンクのタイプ

特徴

プライベート・データベース・リンク

このリンクは、パブリック・リンクやグローバル・リンクよりも安全です。その理由は、このリンクを使用してリモート・データベースにアクセスできるのが、プライベート・リンクの所有者と、同じスキーマ内のサブプログラムのみに限定されるためです。

パブリック・データベース・リンク

多数のユーザーがリモートのOracle Databaseへのアクセス・パスを必要とするときは、データベース内のすべてのユーザーが使用できる1つのパブリック・データベース・リンクを作成できます。

グローバル・データベース・リンク

Oracleネットワークでディレクトリ・サーバーを使用すると、管理者は、システムに存在するすべてのデータベースに対するグローバル・データベース・リンクを容易に管理できます。データベース・リンクの管理が集中化され、単純になります。

関連項目:

- 各タイプのデータベース・リンクの作成方法の詳細は、「リンク・タイプの指定」を参照してください。

- リンクに関する情報へのアクセス方法は、「データベース・リンク情報の表示」を参照してください。

データベース・リンクのユーザー

リンクを作成するときは、どのユーザーがリモート・データベースに接続してデータにアクセスする必要があるかを決めます。次の表は、データベース・リンクに関係するユーザーのカテゴリについて、それらの違いを説明したものです。

ユーザー・タイプ

説明

リンク作成構文のサンプル

接続ユーザー

固定のユーザー名およびパスワードが指定されていないデータベース・リンクにアクセスするローカル・ユーザー。SYSTEMが問合せでパブリック・リンクにアクセスする場合、接続ユーザーはSYSTEMであり、データベースはリモート・データベースのSYSTEMスキーマに接続します。
注意: 接続ユーザーは、必ずしもリンクを作成したユーザーである必要はありません。リンクにアクセスしようとしているすべてのユーザーが接続ユーザーになります。

CREATE PUBLIC DATABASE LINK hq USING 'hq';

現行ユーザー

CURRENT_USERデータベース・リンク内のグローバル・ユーザー。グローバル・ユーザーは、X.509証明書(SSL認証方式のエンタープライズ・ユーザー)またはパスワード(パスワード認証方式のエンタープライズ・ユーザー)によって認証される必要があり、リンクに関係する両方のデータベースのユーザーであることが必要です。現行ユーザー・リンクは、Oracle Advanced Securityオプションの機能の1つです。
グローバル・セキュリティの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

CREATE PUBLIC DATABASE LINK hq CONNECT TO CURRENT_USER using 'hq';

固定ユーザー

ユーザー名/パスワードがリンク定義の一部になっているユーザー。リンクに固定ユーザーが含まれている場合は、その固定ユーザーのユーザー名とパスワードがリモート・データベースへの接続に使用されます。

CREATE PUBLIC DATABASE LINK hq CONNECT TO jane IDENTIFIED BY password USING 'hq';

注意:
次のユーザーはデータベース・リンクのターゲット・ユーザーにはなれません: SYSおよびPUBLIC。

関連項目:
リンクを作成するユーザーを指定する方法の詳細は、「リンク・ユーザーの指定」を参照してください。

接続ユーザー・データベース・リンク

接続ユーザー・リンクには、接続文字列が対応付けられていません。接続ユーザー・リンクの利点は、リンクを参照するユーザーが同じユーザーとしてリモート・データベースに接続するため、資格証明がデータ・ディクショナリのリンク定義に格納されている必要がないことです。

接続ユーザー・リンクには、いくつかのデメリットがあります。これらのリンクでは、ユーザーが接続先のリモート・データベースのアカウントと権限を持っている必要があるため、管理者の権限管理作業が増えます。また、必要以上の権限をユーザーに与えることは、セキュリティの基本概念である最低限の権限、つまり「ユーザーにはユーザー自身のジョブの実行に必要な権限のみを与える」に反することになります。

接続ユーザー・データベース・リンクの使用許可を左右する要因はいくつかありますが、最も重要な要因として、ユーザーがパスワードを使用してデータベースで認証されるのか、またはオペレーティング・システムやネットワーク認証サービスによって外部認証されるのかという要因があります。ユーザーが外部認証される場合、接続ユーザー・リンクの使用許可も、リモート・データベースでユーザーのリモート認証が許可されるかどうか(REMOTE_OS_AUTHENT初期化パラメータの設定)によって異なります。

REMOTE_OS_AUTHENTパラメータは、次のように働きます。

REMOTE_OS_AUTHENTの値

結果

リモート・データベースに対してTRUE

外部認証方式のユーザーは、接続ユーザー・データベース・リンクを使用してリモート・データベースに接続できます。

リモート・データベースに対してFALSE

外部認証方式のユーザーは、Oracle Advanced Securityオプションでサポートされているセキュリティ保護されたプロトコルまたはネットワーク認証サービスを使用しないかぎり、接続ユーザー・データベース・リンクを使用してリモート・データベースに接続することはできません。

注意:
REMOTE_OS_AUTHENT初期化パラメータは非推奨です。これは、下位互換性のためにのみ残されています。

固定ユーザー・データベース・リンク

固定ユーザー・リンクの利点は、接続文字列で指定したユーザーのセキュリティ・コンテキストを使用して、プライマリ・データベースのユーザーをリモート・データベースに接続することです。たとえば、ローカル・ユーザーjoeは、固定ユーザーscottとパスワードpasswordを指定したパブリック・データベース・リンクをjoeのスキーマ内に作成できます。janeがこの固定ユーザー・リンクを使用して問合せを発行すると、ローカル・データベースのユーザーであるjaneが、scott/passwordとしてリモート・データベースに接続します。

固定ユーザー・リンクでは、接続文字列にユーザー名とパスワードが対応付けられています。ユーザー名とパスワードは、データ・ディクショナリ表の別のリンク情報に格納されます。

現行ユーザー・データベース・リンク

現行ユーザー・データベース・リンクは、グローバル・ユーザーを利用します。グローバル・ユーザーは、X.509証明書またはパスワードによって認証される必要があり、リンクに関係する両方のデータベースのユーザーであることが必要です。

CURRENT_USERリンクを実行するユーザーは、必ずしもグローバル・ユーザーである必要はありません。たとえば、janeがパスワードを使用して買掛金データベースに(グローバル・ユーザーとしてではなく)認証されている場合、ストアド・プロシージャにアクセスしてhqデータベースからデータを取得できます。プロシージャでは、現行ユーザー・データベース・リンクを使用して彼女をグローバル・ユーザーscottとしてhqに接続します。ユーザーscottはグローバル・ユーザーでSSLを介した証明書により認証されますが、janeは認証されません。

現行ユーザー・データベース・リンクによって、次のような結果になることに注意してください。

- 現行ユーザー・データベース・リンクがストアド・オブジェクト内からアクセスされていない場合、現行のユーザーはリンクにアクセスしている接続ユーザーと同じです。たとえば、scottが現行ユーザー・リンクを介してSELECT文を発行した場合、現行ユーザーはscottになります。

- プロシージャ、ビュー、トリガーなど、データベース・リンクにアクセスするストアド・オブジェクトを実行する場合、現行ユーザーとはストアド・オブジェクトを所有するユーザーで、オブジェクトをコールするユーザーではありません。たとえば、janeがプロシージャscott.p (scottが作成したプロシージャ)をコールし、コールされたプロシージャ内に現行ユーザー・リンクが表示された場合、scottがリンクの現行ユーザーになります。

- ストアド・オブジェクトが実行者権限のファンクション、プロシージャまたはパッケージである場合は、実行者の認可IDを使用してリモート・ユーザーとして接続します。たとえば、ユーザーjaneがプロシージャscott.p(scottによって作成された実行者権限のプロシージャ)をコールし、プロシージャscott.pの内部からリンクが確立される場合、リンクの現行ユーザーはjaneになります。

- データベースにエンタープライズ・ユーザーとして接続して、共有のグローバル・スキーマ内に存在するストアド・プロシージャで現行ユーザー・リンクを使用することはできません。たとえば、ユーザーjaneがデータベースhq上の共有スキーマguest内のストアド・プロシージャにアクセスする場合、リモート・データベースへのログオン用にこのスキーマ内の現行ユーザー・リンクは使用できません。

関連項目:

- データベース・リンクに関連するセキュリティ上の問題の詳細は、「分散データベースのセキュリティ」を参照してください。

- 『Oracle Database Advanced Security管理者ガイド』

- 実行者権限のファンクション、プロシージャまたはパッケージの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

データベース・リンクの作成: 例

データベース・リンクを作成するには、CREATE DATABASE LINK文を使用します。次の表は、ローカル・データベース内でリモートのsales.us.americas.example_auto.comデータベースへのデータベース・リンクを作成するSQL文の例です。

SQL文

接続先のデータベース

接続時のユーザー

リンク・タイプ

CREATE DATABASE LINK sales.us.americas.example_auto.com USING 'sales_us';

sales(ネット・サービス名sales_usを使用)

接続ユーザー

プライベート接続ユーザー

CREATE DATABASE LINK foo CONNECT TO CURRENT_USER USING 'am_sls';

sales(サービス名am_slsを使用)

現行グローバル・ユーザー

プライベート現行ユーザー

CREATE DATABASE LINK sales.us.americas.example_auto.com CONNECT TO scott IDENTIFIED BY password USING 'sales_us';

sales(ネット・サービス名sales_usを使用)

scott(パスワードpasswordを使用)

プライベート固定ユーザー

CREATE PUBLIC DATABASE LINK sales CONNECT TO scott IDENTIFIED BY password USING 'rev';

sales(ネット・サービス名revを使用)

scott(パスワードpasswordを使用)

パブリック固定ユーザー

CREATE SHARED PUBLIC DATABASE LINK sales.us.americas.example_auto.com CONNECT TO scott IDENTIFIED BY password AUTHENTICATED BY anupam IDENTIFIED BY password1 USING 'sales';

sales(ネット・サービス名salesを使用)

scott(パスワードpasswordを使用。認証用としてユーザー名anupamとパスワードpassword1を使用)

共有パブリック固定ユーザー

関連項目:

- リンクの作成方法の詳細は、「データベース・リンクの作成」を参照してください。

- CREATE DATABASE LINK文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

スキーマ・オブジェクトとデータベース・リンク

データベース・リンクを作成した後、リモート・データベースのオブジェクトにアクセスするSQL文を実行できます。たとえば、データベース・リンクfooを使用してリモート・オブジェクトempにアクセスするには、次の文を発行します。

SELECT * FROM emp@foo;

特定のリモート・オブジェクトにアクセスするには、リモート・データベース内での認可も必要です。

データベース・リンクを使用して適切な構成のオブジェクト名を作成することは、分散システムにおいて欠かせないデータ操作の1つです。

データベース・リンクを使用したスキーマ・オブジェクトの命名

Oracle Databaseは、グローバル・データベース名を使用してスキーマ・オブジェクトにグローバルな名前を付ける際、次のスキームを使用します。

schema.schema_object@global_database_name

説明:

- schemaは、データの論理構造(スキーマ・オブジェクト)の集まりです。スキーマはデータベース・ユーザーによって所有され、そのユーザーと同じ名前を持ちます。ユーザーはそれぞれ1つのスキーマを所有します。

- schema_objectは、表、索引、ビュー、シノニム、プロシージャ、パッケージ、データベース・リンクなどの論理データ構造です。

- global_database_nameは、リモート・データベースを一意に識別する名前です。この名前は、リモート・データベース初期化パラメータDB_NAMEとDB_DOMAINの連結と同じ必要があります(ただし、パラメータGLOBAL_NAMESがFALSEに設定されている場合は、任意の名前を使用できます)。

たとえば、ユーザーまたはアプリケーションは、データベースsales.division3.example.comへのデータベース・リンクを次のように使用して、リモート・データを参照できます。

SELECT * FROM scott.emp@sales.division3.example.com;  # emp table in scott's schema
SELECT loc FROM scott.dept@sales.division3.example.com;

GLOBAL_NAMESをFALSEに設定している場合は、sales.division3.example.comへのリンクに対して任意の名前を使用できます。たとえば、リンクfooをコールできます。次に、リモート・データベースに次のようにアクセスできます。

SELECT name FROM scott.emp@foo;  # link name different from global name

リモート・スキーマ・オブジェクトへのアクセスに必要な認可

リモート・スキーマ・オブジェクトにアクセスするには、リモート・データベース内でそのオブジェクトへのアクセス権を付与される必要があります。また、リモート・オブジェクトの更新、挿入または削除を実行するには、オブジェクトに対するSELECT権限と、UPDATE、INSERTまたはDELETE権限を付与される必要があります。データベースにはリモート記述機能がないため、ローカル・オブジェクトにアクセスする場合とは異なり、リモート・オブジェクトにアクセスするにはSELECT権限が必要です。データベースでは、構造を判断するためにリモート・オブジェクトのSELECT *を実行する必要があります。

スキーマ・オブジェクトのシノニム

Oracle Databaseでは、シノニムを作成して、データベース・リンク名をユーザーから隠すことができます。シノニムを使用すると、ローカル・データベースの表にアクセスする場合と同じ構文を使用して、リモート・データベースの表にアクセスできます。たとえば、リモート・データベース内の表に対して次の問合せを発行するとします。

SELECT * FROM emp@hq.example.com;

この場合、emp@hq.example.comに対応するシノニムempを作成すれば、同じデータにアクセスする際に次の問合せを発行できます。

SELECT * FROM emp;

関連項目:
データベース・リンクを使用して指定したオブジェクトのシノニムを作成する方法の詳細は、「シノニムを使用した位置の透過性の作成」を参照してください。

スキーマ・オブジェクトの名前解決

スキーマ・オブジェクトへのアプリケーション参照を解決する(このプロセスを名前解決と呼びます)ために、データベースではオブジェクト名を階層的に構成しています。たとえば、データベースでは、データベース内部の各スキーマは一意の名前を持ち、スキーマ内部では各オブジェクトが一意の名前を持つことが保証されています。そのため、スキーマ・オブジェクトの名前はデータベースの内部で常に一意になります。また、データベースはオブジェクトのローカル名へのアプリケーション参照を解決します。

分散データベースでは、表などのスキーマ・オブジェクトに対してシステム内のすべてのアプリケーションからアクセスが可能です。データベースは、グローバル・データベース名による階層ネーミング・モデルを拡張してグローバル・オブジェクト名を効果的に作成することによって、分散データベース・システム内のスキーマ・オブジェクトへの参照を解決します。たとえば、問合せでリモートの表を参照する場合は、その完全修飾名(表が存在しているデータベースを含む)を指定します。

たとえば、ローカル・データベースにユーザーSYSTEMとして接続するとします。

CONNECT SYSTEM@sales1

次に、データベース・リンクhq.example.comを使用して次の文を発行し、リモート・データベースhqのscottスキーマおよびjaneスキーマにあるオブジェクトにアクセスします。

SELECT * FROM scott.emp@hq.example.com;
INSERT INTO jane.accounts@hq.example.com (acc_no, acc_name, balance)
VALUES (5001, 'BOWER', 2000);
UPDATE jane.accounts@hq.example.com
SET balance = balance + 500;
DELETE FROM jane.accounts@hq.example.com
WHERE acc_name = 'BOWER';

データベース・リンクの制限事項

データベース・リンクを使用して次の操作を実行することはできません。

- リモート・オブジェクトへの権限の付与。

- 一部のリモート・オブジェクトに対するDESCRIBEの実行。ただし、次のリモート・オブジェクトはDESCRIBEをサポートしています。

- 表

- ビュー

- プロシージャ

- ファンクション

- リモート・オブジェクトの分析。

- 参照整合性の定義または規定。

- リモート・データベース内のユーザーへのロールの付与。

- リモート・データベースにおけるデフォルト以外のロールの取得。たとえば、janeがローカル・データベースに接続し、scottとして接続する固定ユーザー・リンクを使用したストアド・プロシージャを実行する場合、janeはリモート・データベースにおけるscottのデフォルト・ロールを受け取ります。janeは、SET ROLEを発行してデフォルト以外のロールを取得することはできません。

- SSL、パスワードまたはNTのシステム固有の認証によって認証されていない現行ユーザー・リンクの使用。

分散データベースの管理

ここでは、Oracle Databaseの分散データベース・システムにおけるデータベース管理について説明します。この項の内容は、次のとおりです。

- サイト自律性

- 分散データベースのセキュリティ

- データベース・リンクの監査

- 管理ツール

関連項目:

- 同機種システムの管理方法の詳細は、第32章「分散データベースの管理」を参照してください。

- 異機種間サービスの概念の詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

サイト自律性

サイト自律性とは、分散データベース内の各サーバーが他のすべてのデータベースから独立して管理されることを意味します。複数のデータベースが協調して動作する場合もありますが、各データベースはそれぞれ別々のデータ・リポジトリであり、個別に管理されます。Oracle Databaseの分散データベースのサイト自律性には、次のような利点があります。

- 独立性を維持する必要がある個々の企業またはグループの論理的な組織構造を、システムのノード群として反映できます。

- ローカル管理者がそれぞれ対応するローカル・データを管理します。したがって、個々のデータベース管理者の責任範囲が小さくなり、管理しやすくなります。

- 障害が単独で発生するため、分散データベースの他のノードに損傷を与える可能性が低くなります。1つのデータベース障害によってすべての分散操作が停止したり、パフォーマンスのボトルネックが生じることはありません。

- 孤立したシステム障害が発生した際、管理者は、システム内の他のノードとは独立してリカバリできます。

- 各ローカル・データベースにはデータ・ディクショナリが存在します。ローカル・データへのアクセスにグローバル・カタログは不要です。

- 各ノードで独立してソフトウェアをアップグレードできます。

Oracle Databaseでは分散データベース・システム内の各データベースを独立して管理できますが、システムのグローバルな要件を無視することのないようにしてください。たとえば、次のような作業が必要になることがあります。

- サーバー間接続を容易にするために作成したリンクをサポートするため、追加のユーザー・アカウントを各データベースに作成する。

- COMMIT_POINT_STRENGTHやOPEN_LINKSなどの追加の初期化パラメータを設定する。

分散データベースのセキュリティ

データベースでは、非分散データベース環境で使用できる次のセキュリティ機能が、分散データベース・システムでもすべてサポートされています。

- ユーザーおよびロールのパスワード認証。

- ユーザーおよびロール用の外部認証タイプ(接続ユーザー・リンク用のKerberosバージョン5など)。

- クライアント/サーバー間およびサーバー間接続におけるログイン・パケットの暗号化。

次の項では、Oracle Databaseの分散データベース・システムの構成時に考慮する必要がある内容について説明します。

- データベース・リンクを介した認証

- パスワードなしの認証

- ユーザー・アカウントおよびロールのサポート

- ユーザーと権限の集中管理

- データの暗号化

関連項目:
外部認証の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

データベース・リンクを介した認証

データベース・リンクにはプライベートとパブリックの2種類があり、それぞれについて認証ありの場合と認証なしの場合があります。パブリック・リンクを作成するには、リンク作成文でPUBLICキーワードを指定します。たとえば、次の文を発行できます。

CREATE PUBLIC DATABASE LINK foo USING 'sales';

認証ありのリンクを作成するには、データベース・リンク作成文でCONNECT TO句、AUTHENTICATED BY句、あるいはこれら両方の句を指定します。たとえば、次の文を発行できます。

CREATE DATABASE LINK sales CONNECT TO scott IDENTIFIED BY password USING 'sales';
CREATE SHARED PUBLIC DATABASE LINK sales CONNECT TO nick IDENTIFIED BY password1
AUTHENTICATED BY david IDENTIFIED BY password2 USING 'sales';

次の表は、ユーザーがリンクを介してリモート・データベースにアクセスする方法を示しています。

リンク・タイプ

認証済

セキュリティ・アクセス

プライベート

いいえ

データベースでは、リモート・データベースに接続するときに、ローカル・セッションから取得したセキュリティ情報(ユーザーID/パスワード)を使用します。そのため、このリンクは接続ユーザー・データベース・リンクです。2つのデータベース間で、パスワードが同期化されている必要があります。

プライベート

はい

ユーザーID/パスワードがローカル・セッションのコンテキストからではなく、リンク定義から取得されます。そのため、このリンクは固定ユーザー・データベース・リンクです。
この構成では、2つのデータベース間で異なるパスワードを使用できますが、ローカル・データベース・リンクのパスワードはリモート・データベースのパスワードと一致している必要があります。

パブリック

いいえ

動作はプライベートの非認証リンクとほぼ同じですが、すべてのユーザーがこのリモート・データベースへのポインタを参照できる点が異なります。

パブリック

はい

ローカル・データベースのすべてのユーザーがリモート・データベースにアクセスでき、すべてのユーザーが同じユーザーID/パスワードを使用して接続します。

パスワードなしの認証

接続ユーザーまたは現行ユーザーのデータベース・リンクを使用するときは、Kerberosなどの外部認証ソースを使用してエンドツーエンドのセキュリティを確立できます。エンドツーエンド認証では、資格証明がサーバー間で渡され、同じドメインに属するデータベース・サーバーによって資格証明を認証できます。たとえば、janeがローカル・データベースで外部認証されているときに、接続ユーザー・リンクを使用してリモート・データベースに彼女自身として接続しようとする場合、ローカル・サーバーからリモート・データベースにセキュリティ・チケットが渡されます。

ユーザー・アカウントおよびロールのサポート

分散データベース・システムでは、システムを使用するアプリケーションのサポートに必要なユーザー・アカウントおよびロールについて慎重に計画する必要があります。次の点に注意してください。

- サーバー間接続の確立に必要なユーザー・アカウントは、分散データベース・システムのすべてのデータベースで使用可能である必要があります。

- 分散データベース・アプリケーションのユーザーに対してアプリケーション権限を使用可能にするために必要なロールは、分散データベース・システムのすべてのデータベースに存在する必要があります。

分散データベース・システム内のノードに対応するデータベース・リンクを作成する際は、それらのリンクを使用するサーバー間接続をサポートするために、各サイトでどのユーザー・アカウントとロールが必要になるかを決めてください。

通常、分散環境では、ユーザーは多数のネットワーク・サービスへのアクセスが必要になります。個々のユーザーが個々のネットワーク・サービスにアクセスするために個別の認証を構成する必要があるときは、特に大規模なシステムの場合にセキュリティの管理が難しくなることがあります。

関連項目:
各種データベース・リンクをシステムでサポートするために使用可能にする必要があるユーザー・アカウントの詳細は、「データベース・リンクの作成」を参照してください。

ユーザーと権限の集中管理

データベースには、分散システムに関係するユーザーおよび権限を管理するための様々な手段が用意されています。たとえば、次のような方法があります。

- エンタープライズ・ユーザー管理。SSLを介して、またはパスワードを使用して認証されるグローバル・ユーザーを作成し、それらのユーザーと権限を独立したディレクトリ・サービスによってディレクトリ内で管理できます。

- ネットワーク認証サービス。この一般的な方法によって、分散環境のセキュリティ管理が容易になります。Oracle Advanced Securityオプションを使用することで、Oracle NetとOracle Databaseの分散データベース・システムのセキュリティを強化できます。Oracle以外の認証ソリューションの例としては、Windows NTのシステム固有の認証があります。

関連項目:

- 『Oracle Database Advanced Security管理者ガイド』

- 『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』

スキーマに依存するグローバル・ユーザー

ユーザーと権限を集中管理する方法の1つとして、次のユーザーを作成できます。

- 中央ディレクトリ内のグローバル・ユーザー

- グローバル・ユーザーが接続する必要のあるすべてのデータベース内のユーザー

たとえば、次のSQL文を使用してfredというグローバル・ユーザーを作成できます。

CREATE USER fred IDENTIFIED GLOBALLY AS 'CN=fred adams,O=Oracle,C=England';

この解決方法を使用すると、1つのグローバル・ユーザーを中央ディレクトリによって認証できます。

スキーマに依存するグローバル・ユーザーのソリューションでは、このユーザーがアクセスする必要のあるすべてのデータベースでfredと呼ばれるユーザーを作成する必要が生じるという結果になります。ユーザーの多くはアプリケーション・スキーマにアクセスする権限は必要とするものの、独自のスキーマは不要であるため、すべてのグローバル・ユーザーに対してデータベースごとに別個のアカウントを作成すると、大幅なオーバーヘッドが生じます。この問題のため、データベースでは、スキーマに依存しないユーザー(すべてのデータベースで単一の汎用的なスキーマにアクセスできるグローバル・ユーザー)もサポートされています。

スキーマに依存しないグローバル・ユーザー

データベースは、グローバル・ユーザーをエンタープライズ・ディレクトリ・サービスによって集中管理する機能をサポートしています。このディレクトリ内で管理されるユーザーのことを、エンタープライズ・ユーザーと呼びます。このディレクトリには、次のことに関する情報が格納されています。

- エンタープライズ・ユーザーが分散システムのどのデータベースにアクセスできるのか。

- エンタープライズ・ユーザーが各データベースのどのロールを使用できるのか。

- エンタープライズ・ユーザーが各データベースのどのスキーマに接続できるのか。

各データベースの管理者は、エンタープライズ・ユーザーが接続する必要のあるデータベースごとに各エンタープライズ・ユーザーのグローバル・ユーザー・アカウントを作成する必要はありません。そのかわりに、複数のエンタープライズ・ユーザーが共有スキーマと呼ばれる同じデータベース・スキーマに接続できます。

注意:
共有スキーマ内の現行ユーザー・データベース・リンクにはアクセスできません。

たとえば、jane、billおよびscottが全員、人事管理アプリケーションを使用しているとします。hqアプリケーション・オブジェクトは、hqデータベース上のguestスキーマにすべて格納されています。この場合、共有スキーマとして使用するローカル・グローバル・ユーザー・アカウントを作成できます。このグローバル・ユーザー名(共有スキーマ名)はguestです。jane、billおよびscottは、いずれもディレクトリ・サービスでエンタープライズ・ユーザーとして作成されます。また、彼らをディレクトリのguestスキーマにマップし、hqアプリケーションで別の認可を割り当てることもできます。

図31-5は、エンタープライズ・ディレクトリ・サービスを使用したグローバル・ユーザーのセキュリティの例を示しています。

図31-5 グローバル・ユーザーのセキュリティ

エンタープライズ・ディレクトリ・サービスに、hqおよびsalesのエンタープライズ・ユーザーに関する次の情報が格納されているとします。

データベース

ロール

スキーマ

エンタープライズ・ユーザー

hq

clerk1

guest

bill
scott

sales

clerk2

guest

jane
scott

また、hqおよびsalesのローカル管理者が次の文を発行したとします。

データベース

CREATE文

hq

CREATE USER guest IDENTIFIED GLOBALLY AS '';
CREATE ROLE clerk1 GRANT select ON emp;
CREATE PUBLIC DATABASE LINK sales_link CONNECT AS CURRENT_USER USING 'sales';

sales

CREATE USER guest IDENTIFIED GLOBALLY AS '';
CREATE ROLE clerk2 GRANT select ON dept;

ここで、salesに関係する分散トランザクションを実行するために、エンタープライズ・ユーザーscottがローカル・データベースhqへの接続を要求するとします。このとき、次の手順が実行されます(ただし、必ずしもこの順序どおりとはかぎりません)。

1. エンタープライズ・ユーザーscottが、SSLまたはパスワードを使用して認証されます。

2. ユーザーscottが次の文を発行します。

SELECT e.ename, d.loc
FROM emp e, dept@sales_link d
WHERE e.deptno=d.deptno;

3. データベースhqとsalesが、SSLを使用して相互に認証します。

4. データベースhqはエンタープライズ・ディレクトリ・サービスを問い合せて、エンタープライズ・ユーザーscottがhqにアクセスできるかどうかを判断し、scottがロールclerk1を使用してローカル・スキーマguestにアクセスできることを確認します。

5. データベースsalesはエンタープライズ・ディレクトリ・サービスを問い合せて、エンタープライズ・ユーザーscottがsalesにアクセスできるかどうかを判断し、scottがロールclerk2を使用してローカル・スキーマguestにアクセスできることを確認します。

6. エンタープライズ・ユーザーscottはsalesにログインし、ロールclerk2を使用してguestスキーマにアクセスします。そこでSELECTを発行し、必要な情報を取得してその情報をhqに送信します。

7. データベースhqは要求されたデータをsalesから受信し、それをクライアントscottに返します。

関連項目:
エンタープライズ・ユーザー・セキュリティの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

データの暗号化

Oracle Advanced Securityオプションでは、データが解読または改ざんされないように、Oracle Netとその関連製品でネットワーク・データの暗号化とチェックサムも使用できます。これにより、RSA Data Security社のRC4またはデータ暗号化規格(DES)暗号化アルゴリズムを使用して、データを不当な表示から保護します。

データが転送中に改ざん、削除または再現されなかったことを保証するために、Oracle Advanced Securityオプションのセキュリティ・サービスは、暗号的に安全なメッセージ・ダイジェストを生成し、ネットワーク上に送られる各パケットにそのダイジェストを含めることができます。

関連項目:
Oracle Advanced Securityオプションのこれらの機能およびその他の機能の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください。

データベース・リンクの監査

操作の監査は、常にローカルで実行する必要があります。つまり、適切な監査オプションがそれぞれのデータベースで設定されている場合は、ユーザーがローカル・データベース内で操作を実行し、データベース・リンクを介してリモート・データベースにアクセスすると、ローカルの操作はローカル・データベースで監査され、リモートの操作はリモート・データベースで監査されます。

リモート・データベースでは、正常終了した接続要求とその後のSQL文が別のサーバーからのものか、またはローカルに接続しているクライアントからのものかを判断することはできません。たとえば、次のような場合を考えてみます。

- 固定ユーザー・リンクhq.example.comにより、ローカル・ユーザーjaneがリモート・ユーザーscottとしてリモートのhqデータベースに接続します。

- ユーザーscottは、リモート・データベースで監査されます。

リモート・データベース・セッション中に実行される操作は、あたかもscottがhqにローカルに接続し、そこで同じ操作を実行しているかのように監査されます。janeがリモート・データベースで何を実行しているのかを監査する場合は、リモート・データベースで監査オプションを設定し、リンクに埋め込まれているユーザー名(この場合はhqデータベースのscott)の操作を捕捉する必要があります。

注意:
グローバル・ユーザーに対応するグローバル・ユーザー名を監査できます。

リモート・オブジェクトに対してローカルの監査オプションを設定することはできません。したがって、リモート・オブジェクトへのアクセスをリモート・データベースで監査することはできますが、データベース・リンクの使用は監査できません。

管理ツール

データベース管理者は、Oracle Databaseの分散データベース・システムを管理する際にいくつかのツールを選択できます。

- Enterprise Manager

- サード・パーティ製管理ツール

- SNMPサポート

Enterprise Manager

Enterprise Managerは、GUIを備えたOracle Databaseの管理ツールです。操作性に優れたインタフェースを介して、分散データベースの管理機能を提供します。Enterprise Managerは、次の操作に使用できます。

- 複数のデータベースの管理。Enterprise Managerを使用して、1つのデータベースを管理したり、複数のデータベースを同時に管理できます。

- データベース管理作業の集中化。世界中のあらゆる場所のあらゆるOracle Databaseプラットフォームで稼働しているローカルおよびリモートの両方のデータベースを管理できます。また、Oracle Netがサポートしている任意のネットワーク・プロトコルでこれらのOracle Databaseプラットフォームを接続できます。

- SQL、PL/SQLおよびEnterprise Managerコマンドの動的な実行。Enterprise Managerを使用して、文を入力、編集および実行できます。実行した文の履歴も保持されます。
これにより、それらの文を再入力しなくても再実行できるので、分散データベース・システムで非常に長い文を繰り返し実行する必要がある場合に特に便利です。

- グローバル・ユーザー、グローバル・ロール、エンタープライズ・ディレクトリ・サービスなどのセキュリティ機能の管理。

サード・パーティ製管理ツール

現在、Oracle Databaseおよびネットワークの管理に役立つ製品が、60を超える企業から150以上出荷されており、真にオープンな環境を実現しています。

SNMPサポート

Oracle Simple Network Management Protocol (SNMP)のサポートでは、ネットワーク管理機能以外に、任意のSNMPベースのネットワーク管理システムによってOracle Databaseサーバーを検索および問合せできるようにします。SNMPは、次に示す多数の一般的なネットワーク管理システムの基盤となる公認規格です。

- HP社のOpenView

- Digital社のPOLYCENTER Manager on NetView

- IBM社のNetView/6000

- Novell社のNetWare Management System

- SunSoft社のSunNet Manager

分散システムでのトランザクション処理

トランザクションとは、1人のユーザーが実行する1つ以上のSQL文によって構成された論理作業単位のことです。トランザクションは、ユーザーの最初に実行可能なSQL文で開始し、そのユーザーによってコミットまたはロールバックされたときに終了します。

リモート・トランザクションは、1つのリモート・ノードにアクセスする文のみで構成されます。分散トランザクションは、複数のノードにアクセスする文で構成されます。

次の項では、トランザクション処理における重要な概念を定義し、トランザクションが分散データベースのデータにアクセスする仕組みについて説明します。

- リモートSQL文

- 分散SQL文

- リモート文と分散型の文の共有SQL

- リモート・トランザクション

- 分散トランザクション

- 2フェーズ・コミット・メカニズム

- データベース・リンクの名前解決

- スキーマ・オブジェクトの名前解決

リモートSQL文

リモート問合せ文とは、そのすべてが同一のリモート・ノードに存在している1つ以上のリモート表から情報を選択する問合せのことです。たとえば、次の問合せは、リモートのsalesデータベースのscottスキーマにあるdept表のデータにアクセスします。

SELECT * FROM scott.dept@sales.us.americas.example_auto.com;

リモート更新文とは、そのすべてが同一のリモート・ノードに存在している1つ以上の表のデータを変更する更新のことです。たとえば、次の問合せは、リモートのsalesデータベースのscottスキーマにあるdept表を更新します。

UPDATE scott.dept@mktng.us.americas.example_auto.com
SET loc = 'NEW YORK'
WHERE deptno = 10;

注意:
リモート更新には1つ以上のリモート・ノードからデータを取得する副問合せを含めることができますが、更新は1つのリモート・ノードでのみ発生するため、その文はリモート更新として分類されます。

分散SQL文

分散問合せ文は、複数のノードから情報を取得します。たとえば、次の問合せは、ローカル・データベースのデータと同時にリモートのsalesデータベースのデータにもアクセスします。

SELECT ename, dname
FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;

分散更新文は、複数のノードのデータを変更します。分散更新を行うには、プロシージャやトリガーなど、異なるノードのデータにアクセスする複数のリモート更新を含むPL/SQLサブプログラム・ユニットを使用します。たとえば、次のPL/SQLプログラム・ユニットは、ローカル・データベースとリモートのsalesデータベースにある表を更新します。

BEGIN
UPDATE scott.dept@sales.us.americas.example_auto.com
SET loc = 'NEW YORK'
WHERE deptno = 10;
UPDATE scott.emp
SET deptno = 11
WHERE deptno = 10;
END;
COMMIT;

データベースによってプログラム内の文がリモート・ノードに送られると、それらの文の実行はユニットとして成功または失敗します。

リモート文と分散型の文の共有SQL

共有SQLを使用したリモート文または分散型の文の仕組みは、本質的にはローカル文の仕組みと同じです。SQLテキストは必ず一致している必要があり、参照先のオブジェクトも必ず一致している必要があります。可能であれば、任意の文または分解された問合せをローカルまたはリモートで処理するために共有SQL領域を使用できます。

関連項目:
共有SQLの詳細は、『Oracle Database概要』を参照してください。

リモート・トランザクション

リモート・トランザクションには1つ以上のリモート文があり、そのすべてが1つのリモート・ノードを参照しています。たとえば、次のトランザクションには2つの文があり、それぞれがリモートのsalesデータベースにアクセスします。

UPDATE scott.dept@sales.us.americas.example_auto.com
SET loc = 'NEW YORK'
WHERE deptno = 10;
UPDATE scott.emp@sales.us.americas.example_auto.com
SET deptno = 11
WHERE deptno = 10;
COMMIT;

分散トランザクション

分散トランザクションとは、1つ以上の文からなり、それらが個別に、またはグループとして、分散データベースの複数のノードのデータを更新するようなトランザクションのことです。たとえば、このトランザクションは、ローカル・データベースとリモートのsalesデータベースを更新します。

UPDATE scott.dept@sales.us.americas.example_auto.com
SET loc = 'NEW YORK'
WHERE deptno = 10;
UPDATE scott.emp
SET deptno = 11
WHERE deptno = 10;
COMMIT;

注意:
トランザクションのすべての文が1つのリモート・ノードのみを参照している場合、そのトランザクションは分散トランザクションではなくリモート・トランザクションです。

2フェーズ・コミット・メカニズム

データベースは、トランザクションが分散か非分散かにかかわらず、トランザクション内のすべての文がユニットとしてコミットまたはロールバックすることを保証します。実行中のトランザクションの結果は、すべてのノードの全トランザクションに対して不可視であり、このような透過性は、問合せや更新、リモート・プロシージャ・コールなど、あらゆるタイプの操作を含むトランザクションにおいて成り立つことが必要です。

非分散データベースにおけるトランザクション管理の一般的なメカニズムの詳細は、『Oracle Database概要』を参照してください。分散データベースでは、データベースはネットワーク上で同じ特性を持つトランザクション管理を連携させる必要があり、ネットワークやシステムに障害が発生しても、データ整合性を維持する必要があります。

データベースの2フェーズ・コミット・メカニズムは、分散トランザクションに関係するすべてのデータベース・サーバーが、そのトランザクション内の文のすべてをコミットするか、すべてをロールバックするかのどちらか一方のみになるように保証するものです。また、2フェーズ・コミット・メカニズムにより、整合性制約、リモート・プロシージャ・コールおよびトリガーによって実行される暗黙的なデータ操作言語(DML)操作が保護されます。

関連項目:
Oracle Databaseの2フェーズ・コミット・メカニズムの詳細は、第34章「分散トランザクションの概念」を参照してください。

データベース・リンクの名前解決

グローバル・オブジェクト名とは、データベース・リンクを使用して指定されたオブジェクトのことです。グローバル・オブジェクト名の必須構成要素は、次のとおりです。

- オブジェクト名

- データベース名

- ドメイン

次の表は、明示的に指定されるグローバル・データベース・オブジェクト名の構成要素を示しています。

文

オブジェクト

データベース

ドメイン

SELECT * FROM joan.dept@sales.example.com

dept

sales

example.com

SELECT * FROM emp@mktg.us.example.com

emp

mktg

us.example.com

SQL文にグローバル・オブジェクト名への参照が含まれていると、データベースでは、必ずグローバル・オブジェクト名の中で指定されているデータベース名と一致する名前を持つデータベース・リンクを検索します。たとえば、次の文を発行した場合を考えます。

SELECT * FROM scott.emp@orders.us.example.com;

この場合は、データベースによってorders.us.example.comというデータベース・リンクが検索されます。データベースはこの操作を実行して、指定されたリモート・データベースへのパスを判断します。

データベースは、一致するデータベース・リンクを常に次の順序で検索します。

1. SQL文を発行したユーザーのスキーマ内のプライベート・データベース・リンク。

2. ローカル・データベース内のパブリック・データベース・リンク。

3. グローバル・データベース・リンク(ディレクトリ・サーバーが使用可能な場合のみ)。

グローバル・データベース名が完全なときの名前解決

完全なグローバル・データベース名が指定された次のSQL文を発行するとします。

SELECT * FROM emp@prod1.us.example.com;

この場合は、データベース名(prod1)とドメイン構成要素(us.example.com)の両方を指定しているため、データベースは、プライベート、パブリックおよびグローバルのデータベース・リンクを検索します。データベースは、指定されたグローバル・データベース名に一致するリンクのみを検索します。

グローバル・データベース名が部分的なときの名前解決

ドメインの任意の一部を指定した場合、データベースでは、完全なグローバル・データベース名を指定したものとみなされます。SQL文で部分的なグローバル・データベース名を指定した場合(つまり、データベース構成要素のみを指定した場合)、データベースはDB_DOMAIN初期化パラメータ値をDB_NAME初期化パラメータ値の後に追加し、完全な名前を構成します。たとえば、次の文を発行した場合を考えます。

CONNECT scott@locdb
SELECT * FROM scott.emp@orders;

locdbのネットワーク・ドメインがus.example.comの場合、データベースはこのドメインをordersの後に追加し、orders.us.example.comという完全なグローバル・データベース名を構成します。データベースは、構築されたグローバル名のみに一致するデータベース・リンクを検索します。一致するリンクが見つからない場合、データベースはエラーを返し、SQL文は実行できません。

グローバル・データベース名をまったく指定しないときの名前解決

グローバル・オブジェクト名がローカル・データベース内のオブジェクトを参照していて、データベース・リンク名の指定に@記号が使用されていない場合、データベースは、オブジェクトがローカルであることを自動的に検出して検索を行わないか、またはデータベース・リンクを使用してオブジェクト参照を解決します。たとえば、次の文を発行した場合を考えます。

CONNECT scott@locdb
SELECT * from scott.emp;

2番目の文ではデータベース・リンク接続文字列を使用してグローバル・データベース名を指定していないため、データベースは、データベース・リンクを検索しません。

名前解決のための検索の終了

データベースは、最初に一致したデータベース・リンクが見つかったときに、必ずしも一致するデータベース・リンクの検索を停止するとはかぎりません。データベースは、リモート・データベースへの完全なパス(リモート・アカウントとサービス名の両方)がわかるまで、一致するプライベート、パブリックおよびネットワークのデータベース・リンクを検索します。

最初に一致したデータベース・リンクが見つかると、次の表に従ってリモート・スキーマが決定されます。

ユーザー操作

データベースの応答

例

CONNECT句は指定しないでください

接続ユーザー・データベース・リンクを使用します。

CREATE DATABASE LINK k1 USING 'prod'

CONNECT TO ... IDENTIFIED BY句を指定してください

固定ユーザー・データベース・リンクを使用します。

CREATE DATABASE LINK k2 CONNECT TO scott IDENTIFIED BY password USING 'prod'

CONNECT TO CURRENT_USER句が指定されている場合

現行ユーザー・データベース・リンクを使用します。

CREATE DATABASE LINK k3 CONNECT TO CURRENT_USER USING 'prod'

USING句は指定しないでください

データベース文字列を指定するリンクが見つかるまで検索します。一致するデータベース・リンクが見つかっても文字列がまったく識別されない場合、データベースはエラーを返します。

CREATE DATABASE LINK k4 CONNECT TO CURRENT_USER

完全なパスを決定した後、データベースはリモート・セッションを作成します(同じローカル・セッションのために同一の接続がまだオープンになっていない場合)。セッションがすでに存在している場合、データベースはそのセッションを再利用します。

スキーマ・オブジェクトの名前解決

ローカルのOracle Databaseが、SQL文を発行したローカル・ユーザーのために指定のリモート・データベースに接続した後も、あたかもリモート・ユーザーが対応するSQL文を発行したかのように、オブジェクトの解決処理が続きます。最初に一致したデータベース・リンクが見つかると、次の規則に従ってリモート・スキーマが決定されます。

指定したリンクのタイプ

オブジェクト解決の場所

固定ユーザー・データベース・リンク

リンク作成文で指定されたスキーマ

接続ユーザー・データベース・リンク

接続ユーザーのリモート・スキーマ

現行ユーザー・データベース・リンク

現行ユーザーのスキーマ

オブジェクトが見つからなかった場合、データベースはリモート・データベースのパブリック・オブジェクトをチェックします。オブジェクトを解決できなくても確立されたリモート・セッションは残りますが、SQL文は実行できず、エラーが返されます。

次に、分散データベース・システムにおけるグローバル・オブジェクトの名前解決の例を示します。以降のすべての例で、示しているようなことを想定します。

グローバル・オブジェクトの名前解決の例: 完全なオブジェクト名

この例では、データベースが完全なグローバル・オブジェクト名をどのように解決し、プライベートとパブリックの両方のデータベース・リンクを使用して、どのようにリモート・データベースへの適切なパスを決定するのかを示します。この例では、次のことを想定しています。

- リモート・データベースの名前は、sales.division3.example.comです。

- ローカル・データベースの名前は、hq.division3.example.comです。

- ディレクトリ・サーバーは使用できません。したがって、グローバル・データベース・リンクも使用できません。

- リモート表empは、スキーマtsmith内にあります。

次の文がscottによってローカル・データベースで発行された場合を考えます。

CONNECT scott@hq

CREATE PUBLIC DATABASE LINK sales.division3.example.com
CONNECT TO guest IDENTIFIED BY network
USING 'dbstring';

その後、JWARDが接続して次の文を発行するとします。

CONNECT jward@hq

CREATE DATABASE LINK sales.division3.example.com
CONNECT TO tsmith IDENTIFIED BY radio;

UPDATE tsmith.emp@sales.division3.example.com
SET deptno = 40
WHERE deptno = 10;

データベースは、最後の文を次のように処理します。

1. データベースは、jwardのUPDATE文で完全なグローバル・オブジェクト名が参照されていると判断します。したがって、一致する名前を持つデータベース・リンクの検索がローカル・データベース内で開始されます。

2. データベースは、一致するプライベート・データベース・リンクをスキーマjward内で検索します。しかし、プライベート・データベース・リンクjward.sales.division3.example.comは、リモートのsalesデータベースへの完全なパスを示しておらず、リモート・アカウントのみを示しています。そのため、データベースは、一致するパブリック・データベース・リンクを続いて検索します。

3. データベースは、パブリック・データベース・リンクをscottのスキーマ内で検索します。データベースは、このパブリック・データベース・リンクからネット・サービス名dbstringを取得します。

4. データベースは、一致するプライベートの固定ユーザー・データベース・リンクから取得したリモート・アカウントを結合して完全なパスを決定し、次に、ユーザーtsmith/radioとしてリモートのsalesデータベースに接続します。

5. これで、リモート・データベースは、emp表へのオブジェクト参照を解決できます。データベースはtsmithスキーマ内で検索を行い、参照先のemp表を検出します。

6. リモート・データベースは文の実行を完了し、その結果をローカル・データベースに返します。

グローバル・オブジェクトの名前解決の例: 部分的なオブジェクト名

この例では、データベースが部分的なグローバル・オブジェクト名をどのように解決し、プライベートとパブリックの両方のデータベース・リンクを使用してリモート・データベースへの適切なパスをどのように決定するのかを示します。

この例では、次のことを想定しています。

- リモート・データベースの名前は、sales.division3.example.comです。

- ローカル・データベースの名前は、hq.division3.example.comです。

- ディレクトリ・サーバーは使用できません。したがって、グローバル・データベース・リンクも使用できません。

- リモート・データベースsalesの表empはスキーマtsmith内にあり、スキーマscott内にはありません。

- リモート・データベースsalesにempというパブリック・シノニムが存在します。このシノニムは、リモート・データベースsalesのtsmith.empを指しています。

- 「グローバル・オブジェクトの名前解決の例: 完全なオブジェクト名」で示したパブリック・データベース・リンクが、ローカル・データベースhqにすでに作成されています。

CREATE PUBLIC DATABASE LINK sales.division3.example.com
CONNECT TO guest IDENTIFIED BY network
USING 'dbstring';

ローカル・データベースhqで次の文が発行された場合を考えます。

CONNECT scott@hq

CREATE DATABASE LINK sales.division3.example.com;

DELETE FROM emp@sales
WHERE empno = 4299;

データベースは、最後のDELETE文を次のように処理します。

1. データベースは、scottのDELETE文で部分的なグローバル・オブジェクト名が参照されていると感知します。ローカル・データベースのドメインを使用して、次のように完全なグローバル・オブジェクト名に拡張します。

DELETE FROM emp@sales.division3.example.com
WHERE empno = 4299;

2. データベースは、一致する名前を持つデータベース・リンクをローカル・データベース内で検索します。

3. データベースは、一致するプライベート接続ユーザー・リンクをスキーマscott内で検出しますが、そのプライベート・データベース・リンクにはパスがまったく示されていません。データベースは接続ユーザー名/パスワードをパスのリモート・アカウント部分として使用して、一致するパブリック・データベース・リンクを検索して検出します。

CREATE PUBLIC DATABASE LINK sales.division3.example.com
CONNECT TO guest IDENTIFIED BY network
USING 'dbstring';

4. データベースは、このパブリック・データベース・リンクからサービス名dbstringを取得します。この時点で、データベースは完全なパスを決定しました。

5. データベースは、リモート・データベースにscott/passwordとして接続して検索しますが、スキーマscott内でempというオブジェクトは検出しません。

6. リモート・データベースは、empというパブリック・シノニムを検索して見つけます。

7. リモート・データベースは文を実行し、その結果をローカル・データベースに返します。

ビュー、シノニムおよびプロシージャでのグローバル名前解決

ビュー、シノニムまたはPL/SQLプログラム・ユニット(プロシージャ、ファンクション、トリガーなど)は、グローバル・オブジェクト名によってリモートのスキーマ・オブジェクトを参照できます。グローバル・オブジェクト名が完全な場合、データベースは、グローバル・オブジェクト名を拡張せずにオブジェクトの定義を格納します。ただし、名前が部分的な場合、データベースは、ローカル・データベース名のドメインを使用してその名前を拡張します。

次の表は、ビュー、シノニムおよびプログラム・ユニットの部分的なグローバル・オブジェクト名を、データベースがいつ拡張するのかを示したものです。

ユーザー操作

データベースの応答

ビューの作成

部分的なグローバル名は拡張しません。定義内の問合せのテキストがそのままデータ・ディクショナリに格納されます。そのかわりに、ビューを使用する文が解析されるたびに、データベースは、部分的なグローバル・オブジェクト名を拡張します。

シノニムの作成

部分的なグローバル名が拡張されます。データ・ディクショナリに格納されるシノニムの定義には、拡張されたグローバル・オブジェクト名が含まれます。

プログラム・ユニットのコンパイル

部分的なグローバル名が拡張されます。

グローバル名を変更したときに起こる動作

グローバル名の変更は、部分的なグローバル・オブジェクト名を使用してリモート・データを参照するビュー、シノニムおよびプロシージャに影響を与える可能性があります。参照先データベースのグローバル名を変更すると、ビューおよびプロシージャは存在しないデータベースまたは正しくないデータベースを参照しようとすることがあります。ただし、シノニムは実行時にデータベース・リンク名を拡張しないので、何も変わりません。

グローバル名の変更例

たとえば、sales.uk.example.comおよびhq.uk.example.comという2つのデータベースを考えます。また、salesデータベースに次のビューとシノニムがあるとします。

CREATE VIEW employee_names AS
SELECT ename FROM scott.emp@hr;

CREATE SYNONYM employee FOR scott.emp@hr;

データベースは、employeeシノニム定義を拡張して、次のように保存します。

scott.emp@hr.uk.example.com

使用例1: 両方のデータベース名が変更された場合

最初に、営業および人事の両部門が米国に配置替えされるという状況を考えます。その結果、対応するグローバル・データベース名はどちらも次のように変更されます。

- sales.uk.example.comはsales.us.example.comになります。

- hq.uk.example.comはhq.us.example.comになります。

次の表は、グローバル名の変更前および変更後の問合せの拡張を示しています。

salesへの問合せ

変更前の拡張

変更後の拡張

SELECT * FROM employee_names

SELECT * FROM scott.emp@hr.uk.example.com

SELECT * FROM scott.emp@hr.us.example.com

SELECT * FROM employee

SELECT * FROM scott.emp@hr.uk.example.com

SELECT * FROM scott.emp@hr.uk.example.com

使用例2: 一方のデータベース名が変更された場合

この例では、営業部のみが米国に移動し、人事部は英国に留まるとします。その結果、対応するグローバル・データベース名はどちらも次のように変更されます。

- sales.uk.example.comはsales.us.example.comになります。

- hq.uk.example.comは変わりません

次の表は、グローバル名の変更前および変更後の問合せの拡張を示しています。

salesへの問合せ

変更前の拡張

変更後の拡張

SELECT * FROM employee_names

SELECT * FROM scott.emp@hr.uk.example.com

SELECT * FROM scott.emp@hr.us.example.com

SELECT * FROM employee

SELECT * FROM scott.emp@hr.uk.example.com

SELECT * FROM scott.emp@hr.uk.example.com

この場合、employee_namesビューを定義している問合せが、存在しないグローバル・データベース名に拡張されます。ただし、employeeシノニムは、引き続き正しいデータベースであるhq.uk.example.comを参照します。

分散データベース・アプリケーションの開発

分散システムでアプリケーション開発を行うと、非分散システムには当てはまらない問題が発生します。この項では、分散アプリケーション開発に関連する内容を示します。

- 分散データベース・システムにおける透過性

- リモート・プロシージャ・コール(RPC)

- 分散問合せの最適化

関連項目:
分散システム向けアプリケーションの開発方法の詳細は、第33章「分散データベース・システムのアプリケーション開発」を参照してください。

分散データベース・システムにおける透過性

Oracle Database分散データベース・システムを、システムを使用するユーザーに対して透過的にするアプリケーションを最小限の作業で開発できます。透過性の目的は、分散データベース・システムを単一のOracle Databaseであるかのように処理することです。その結果、分散データベース・アプリケーション開発を困難なものにし、ユーザーの生産性を損なう恐れのある複雑さがなくなり、システムの開発者やユーザーの負担が軽減します。

ここでは、分散データベース・システムにおける透過性についてさらに詳しく説明します。

位置の透過性

Oracle Databaseの分散データベース・システムには、アプリケーション開発者および管理者がデータベース・オブジェクトの物理的な位置をアプリケーションおよびユーザーから隠す機能があります。ユーザーが、アプリケーションの接続先ノードに関係なく、表などのデータベース・オブジェクトを一様に参照できるのには、位置の透過性が関係しています。位置の透過性には、次のようないくつかの利点があります。

- データベースのユーザーはデータベース・オブジェクトの物理的な位置を知る必要がないため、リモート・データへのアクセスが簡単になります。

- 管理者は、エンド・ユーザーや既存のデータベース・アプリケーションに影響を与えることなく、データベース・オブジェクトを移動できます。

通常、管理者および開発者は、アプリケーション・スキーマ内の表およびサポート・オブジェクトに対する位置の透過性を確立するために、シノニムを使用します。たとえば、次の文は、データベース内に別のリモート・データベース内の表に対応するシノニムを作成します。

CREATE PUBLIC SYNONYM emp
FOR scott.emp@sales.us.americas.example_auto.com;
CREATE PUBLIC SYNONYM dept
FOR scott.dept@sales.us.americas.example_auto.com;

これにより、リモート表にアクセスする際に次のような問合せを使用する必要がなくなります。

SELECT ename, dname
FROM scott.emp@sales.us.americas.example_auto.com e,
scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;

アプリケーションでは、リモート表の位置を考慮せずに、単純な問合せを発行できます。

SELECT ename, dname
FROM emp e, dept d
WHERE e.deptno = d.deptno;

シノニムの他にも、ビューおよびストアド・プロシージャを使用して、分散データベース・システムで動作するアプリケーションに対する位置の透過性を確立できます。

SQLおよびCOMMITの透過性

Oracle Databaseの分散データベース・アーキテクチャでは、問合せ、更新およびトランザクションの透過性も提供されています。たとえば、SELECT、INSERT、UPDATE、DELETEなどの標準のSQL文は、非分散データベース環境の場合とまったく同じように動作します。また、アプリケーションは、標準のSQL文であるCOMMIT、SAVEPOINTおよびROLLBACKを使用して、トランザクションを管理します。分散トランザクションを制御するために複雑なプログラミングやその他の特別な操作を行う必要はありません。

- 1つのトランザクション内の文からは任意の数のローカル表またはリモート表を参照できます。

- データベースでは、分散トランザクションに関係するノードがすべて同じ動作をすることが保証されており、それらのノードすべてがトランザクションをコミットまたはロールバックします。

- 分散トランザクションのコミット中にネットワークまたはシステムの障害が発生した場合、トランザクションは自動的かつ透過的、およびグローバルに解決されます。具体的には、ネットワークまたはシステムがリストアされると、すべてのノードがトランザクションをコミットまたはロールバックします。

データベースの内部では、コミットされた各トランザクションに対して、そのトランザクション内の文による変更を一意に識別するためのシステム変更番号(SCN)が対応付けられます。分散データベースでは、次のときに通信中のノードのSCNが調整されます。

- 1つ以上のデータベース・リンクによって表されるパスを使用して接続が確立されるとき。

- 分散SQL文が実行されるとき。

- 分散トランザクションがコミットされるとき。

特に、分散データベース・システムのノード間でSCNが調整されることにより、文とトランザクションの両方のレベルでグローバルな分散読込み一貫性が保証されることは大きな利点です。必要であれば、グローバルな時間ベースの分散リカバリを完了することもできます。

レプリケーションの透過性

データベースはまた、システムのノード間でデータを透過的にレプリケートするための機能も数多く備えています。Oracle Databaseのレプリケーション機能の詳細は、『Oracle Databaseアドバンスト・レプリケーション』を参照してください。

リモート・プロシージャ・コール(RPC)

開発者は、分散データベースで動作するアプリケーションをサポートするためのPL/SQLパッケージおよびプロシージャをコーディングできます。アプリケーションでは、ローカル・データベースでの処理を実行するためにローカル・プロシージャ・コールを実行でき、リモート・データベースでの処理を実行するためにRPCを実行できます。

プログラムがリモート・プロシージャをコールすると、ローカル・サーバーはすべてのプロシージャ・パラメータをコールされたリモートサーバーに渡します。 たとえば、次のPL/SQLプログラム・ユニットでは、リモートのsalesデータベースにあるパッケージ・プロシージャdel_empをコールし、パラメータ1257を渡します。

BEGIN
emp_mgmt.del_emp@sales.us.americas.example_auto.com(1257);
END;

RPCを正常に実行するためには、コール側プロシージャがリモート・サイトに存在し、接続しようとするユーザーがそのプロシージャを実行するための適切な権限を持っている必要があります。

分散データベース・システム対応のパッケージおよびプロシージャを開発する際、開発者は、どのプログラム・ユニットをリモートの位置で実行し、その結果をどのようにコール側アプリケーションに返すのかについて理解した上で、コードを記述する必要があります。

分散問合せの最適化

Oracle Databaseの機能の1つである分散問合せの最適化は、トランザクションの分散SQL文内で参照されているリモート表からデータを取得するときに、サイト間で必要となるデータ転送の量を減らします。

分散問合せの最適化では、コストベース最適化の設定を使用して、リモート表から必要なデータのみを抽出するSQL式が検索または生成され、抽出されたデータはリモート・サイト(場合によってローカル・サイト)で処理され、その結果がローカル・サイトに送信されて最終処理が行われます。表データすべてをローカル・サイトに転送して処理する際にかかる時間と比較して、この操作では必要なデータ転送量が削減されます。

DRIVING_SITE、NO_MERGE、INDEXなど、各種のコストベース・オプティマイザ・ヒントを使用することによって、Oracle Databaseがデータを処理する場所と、データへのアクセス方法を制御できます。

関連項目:
コストベースの最適化の詳細は、「コストベース最適化の使用」を参照してください。

分散環境でのキャラクタ・セットのサポート

Oracle Databaseは、クライアント、Oracle DatabaseサーバーおよびOracle Database以外のサーバーが異なるキャラクタ・セットを使用する環境をサポートしています。異機種環境のためにNCHARのサポートが提供されています。各国語サポート(NLS)および異機種間サービス(HS)に関連する各種の環境変数および初期化パラメータを設定することにより、異なるキャラクタ・セット間でのデータ変換を制御できます。

キャラクタの設定は、次のNLSおよびHSパラメータで定義されます。

パラメータ

環境

定義の対象

NLS_LANG(環境変数)

クライアント/サーバー

クライアント

NLS_LANGUAGE
NLS_CHARACTERSET

NLS_TERRITORY

クライアント/サーバー
非異機種間分散

異機種間分散

Oracle Databaseサーバー

HS_LANGUAGE

異機種間分散

Oracle以外のデータベース・サーバー
Transparent Gateway

NLS_NCHAR(環境変数)
HS_NLS_NCHAR

異機種間分散

Oracle Databaseサーバー
Transparent Gateway

関連項目:

- NLSパラメータの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

- HSパラメータの詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

クライアント/サーバー環境

クライアント/サーバー環境では、図31-6のように、クライアント・キャラクタ・セットをOracle Databaseサーバーのキャラクタ・セットと同じにするか、またはそのサブセットに設定します。

図31-6 クライアント/サーバー環境におけるNLSパラメータの設定

同機種間分散環境

同機種環境では、図31-7のように、クライアントとサーバーのキャラクタ・セットをメイン・サーバーのキャラクタ・セットと同じにするか、またはそのサブセットにします。

図31-7 同機種環境におけるNLSパラメータの設定

異機種間分散環境

異機種環境では、図31-8のように、クライアント、Transparent GatewayおよびOracle Database以外のデータソースの、グローバリゼーション・サポートのパラメータ設定をすべて同じにするか、またはデータベース・サーバーのキャラクタ・セットのサブセットにします。Transparent Gatewayは、グローバリゼーションを完全にサポートしています。

図31-8 異機種環境におけるNLSパラメータの設定

異機種環境では、異機種間サービス・テクノロジによって構築されたTransparent Gatewayのみが完全なNCHAR機能をサポートします。特定のTransparent GatewayがNCHARをサポートしているかどうかは、対象となるOracle Database以外のデータソースによって異なります。特定のTransparent GatewayによるNCHARサポートの処理方法の詳細は、システム固有のTransparent Gatewayのマニュアルを参照してください。

関連項目:
異機種間サービスの詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

32 分散データベースの管理

この章の内容は、次のとおりです。

- 分散システムでのグローバル名の管理

- データベース・リンクの作成

- 共有データベース・リンクの使用

- データベース・リンクの管理

- データベース・リンク情報の表示

- 位置の透過性の作成

- 文の透過性の管理

- 分散データベースの管理: 例

分散システムでのグローバル名の管理

分散データベース・システムでは、各データベースが一意のグローバル・データベース名を持ちます。グローバル・データベース名は、システム内のデータベースを一意に識別します。分散データベースでの主な管理作業として、グローバル・データベース名の作成と変更の管理があります。

この項の内容は次のとおりです。

- グローバル・データベース名の書式の理解

- グローバル・ネーミング施行の判断

- グローバル・データベース名の参照

- グローバル・データベース名のドメインの変更

- グローバル・データベース名の変更: 使用例

グローバル・データベース名の書式の理解

グローバル・データベース名は、データベース名とドメインの2つの構成要素から構成されます。データベース名とドメイン名は、データベースの作成時に次の初期化パラメータによって決まります。

構成要素

パラメータ

要件

例

データベース名

DB_NAME

文字数は必ず8文字以内です。

sales

データベースが存在するドメイン

DB_DOMAIN

インターネットの標準規則に従う必要があります。ドメイン名のレベルはドットで区切る必要があり、ドメイン名の順序は、左から右に向かってリーフからルートの順になります。

us.example.com

次に、有効なグローバル・データベース名の例を示します。

DB_NAME

DB_DOMAIN

グローバル・データベース名

sales

example.com

sales.example.com

sales

us.example.com

sales.us.example.com

mktg

us.example.com

mktg.us.example.com

payroll

example.org

payroll.example.org

DB_DOMAIN初期化パラメータが重要となるのは、データベースの作成時に、この初期化パラメータを(DB_NAMEパラメータと一緒に)使用して、データベースのグローバル名を構成するときだけです。この時点で、データベースのグローバル名はデータ・ディクショナリに格納されます。グローバル名を変更するには、初期化パラメータ・ファイル内のDB_DOMAINパラメータを変更するのではなく、ALTER DATABASE文を使用する必要があります。ただし、次回のデータベースの起動を行う前にDB_DOMAINパラメータを変更してドメイン名の変更を反映することをお薦めします。

グローバル・ネーミング施行の判断

ローカル・データベースのリンクに付ける名前は、ローカル・データベースがグローバル・ネーミングを施行するかどうかによって異なります。ローカル・データベースがグローバル・ネーミングを施行する場合は、リモート・データベースのグローバル・データベース名をリンクの名前として使用する必要があります。たとえば、ローカルのhqサーバーに接続していて、リモートのmfgデータベースへのリンクを作成する場合は、ローカル・データベースがグローバル・ネーミングを施行していれば、mfgのグローバル・データベース名をリンク名として使用する必要があります。

データベース・リンク名の一部としてサービス名を使用することもできます。たとえば、サービス名sn1とsn2を使用してデータベースhq.example.comに接続している場合、hqがグローバル・ネーミングを施行していれば、hqへのリンク名を次のように作成できます。

- HQ.EXAMPLE.COM@SN1

- HQ.EXAMPLE.COM@SN2

関連項目:
リンク名でのサービス名の使用の詳細は、「リンク名に含まれるサービス名を指定するための接続修飾子の使用」を参照してください。

グローバル・ネーミングがデータベースで施行されているかどうかを判断するには、データベースの初期化パラメータ・ファイルを調べるか、またはV$PARAMETERビューを問い合せます。たとえば、mfgでグローバル・ネーミングが施行されているかどうかを判断するには、mfgのセッションを開始して、次のglobalnames.sqlスクリプトを作成し、実行できます(出力例も含まれています)。

COL NAME FORMAT A12
COL VALUE FORMAT A6
SELECT NAME, VALUE FROM V$PARAMETER
WHERE NAME = 'global_names'
/

SQL> @globalnames

NAME         VALUE
------------ ------
global_names FALSE

グローバル・データベース名の参照

データベースのグローバル名を参照するには、データ・ディクショナリ・ビューGLOBAL_NAMEを使用します。たとえば、次の文を発行します。

SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
-------------------------------------------------------------------------------
SALES.EXAMPLE.COM

グローバル・データベース名のドメインの変更

データベースのグローバル名のドメインを変更するには、ALTER DATABASE文を使用します。データベースを作成した後に初期化パラメータDB_DOMAINを変更しても、グローバル・データベース名やデータベース・リンク名の解決には効果がありません。

次の例は、名前変更文の構文を示しています。ここで、databaseはデータベース名、domainはネットワーク・ドメインを表します。

ALTER DATABASE RENAME GLOBAL_NAME TO database.domain;

グローバル・データベース名のドメインを変更するには、次の手順を実行します。

1. 現行のグローバル・データベース名を確認します。たとえば、次の文を発行します。

SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
----------------------------------------------------------------------------
SALES.EXAMPLE.COM

2. ALTER DATABASE文を使用して、グローバル・データベース名を変更します。たとえば、次のように入力します。

ALTER DATABASE RENAME GLOBAL_NAME TO sales.us.example.com;

3. GLOBAL_NAME表を問い合せて、新しい名前を確認します。たとえば、次のように入力します。

SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
----------------------------------------------------------------------------
SALES.US.EXAMPLE.COM

グローバル・データベース名の変更: 使用例

この例では、ローカル・データベースのグローバル・データベース名のドメイン部分を変更します。また、部分指定のグローバル名を使用してデータベース・リンクを作成し、Oracle Databaseがその名前をどのように解決するのかを調べます。データベースは、初期化パラメータDB_DOMAINの値ではなく、ローカル・データベースの現行のグローバル・データベース名のドメイン部分を使用して部分名を解決することがわかります。

1. SALES.US.EXAMPLE.COMに接続してGLOBAL_NAMEデータ・ディクショナリ・ビューを問い合せ、現行のデータベース・グローバル名を確認します。

CONNECT SYSTEM@sales.us.example.com
SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
----------------------------------------------------------------------------
SALES.US.EXAMPLE.COM

2. V$PARAMETERビューを問い合せ、DB_DOMAIN初期化パラメータの現在の設定を調べます。

SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'db_domain';

NAME       VALUE
---------  -----------
db_domain  US.EXAMPLE.COM

3. 部分指定のグローバル名のみを使用して、hqデータベースへのデータベース・リンクを作成します。

CREATE DATABASE LINK hq USING 'sales';

データベースは、リンクで指定されたデータベース名にローカル・データベースのグローバル・データベース名のドメイン部分を追加して、このリンクのグローバル・データベース名を拡張します。

4. USER_DB_LINKSを問い合せて、データベースが部分指定のグローバル・データベース名を解決するために使用したドメイン名を確認します。

SELECT DB_LINK FROM USER_DB_LINKS;

DB_LINK
------------------
HQ.US.EXAMPLE.COM

この結果は、ローカル・データベースのグローバル・データベース名のドメイン部分がus.example.comであることを示しています。データベースは、データベース・リンク作成時の部分的なデータベース・リンク名を解決するために、このドメインを使用します。

5. salesデータベースが日本に移動するという通知を受けたので、salesデータベースをsales.jp.example.comに変更します。

ALTER DATABASE RENAME GLOBAL_NAME TO sales.jp.example.com;
SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
----------------------------------------------------------------------------
SALES.JP.EXAMPLE.COM

6. 再度V$PARAMETERを問い合せて、グローバル・データベース名のドメイン部分の名前を変更しても、DB_DOMAINの値が変更されていないことを確認します。

SELECT NAME, VALUE FROM V$PARAMETER
WHERE NAME = 'db_domain';

NAME       VALUE
---------  -----------
db_domain  US.EXAMPLE.COM

この結果は、DB_DOMAIN初期化パラメータの値がALTER DATABASE RENAME GLOBAL_NAME文とは関係がないことを示しています。ALTER DATABASE文は、DB_DOMAIN初期化パラメータではなく、グローバル・データベース名のドメインを決定します(それでも、新しいドメイン名が反映されるようにDB_DOMAINを変更することには意味があります)。

7. データベースsupplyへの別のデータベース・リンクを作成してから、USER_DB_LINKSを問い合せて、データベースがsupplyのグローバル・データベース名のドメイン部分をどのように解決するのかを確認します。

CREATE DATABASE LINK supply USING 'supply';
SELECT DB_LINK FROM USER_DB_LINKS;

DB_LINK
------------------
HQ.US.EXAMPLE.COM
SUPPLY.JP.EXAMPLE.COM

この結果は、データベースがドメインjp.example.comを使用して、部分指定のリンク名を解決していることを示しています。このドメインは、リンクがローカル・データベースのグローバル・データベース名のドメイン部分であるため作成されるときに使用されます。データベースは部分的なリンク名を解決するときに、DB_DOMAIN初期化パラメータの設定は使用しません。

8. 次に、前の情報が誤りで、salesはjp.example.comドメインではなくasia.jp.example.comドメインにあるという通知を受けました。そのため、グローバル・データベース名を次のように変更します。

ALTER DATABASE RENAME GLOBAL_NAME TO sales.asia.jp.example.com;
SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
----------------------------------------------------------------------------
SALES.ASIA.JP.EXAMPLE.COM

9. 再びV$PARAMETERを問い合せて、パラメータDB_DOMAINの設定を確認します。

SELECT NAME, VALUE FROM V$PARAMETER
WHERE NAME = 'db_domain';

NAME        VALUE
----------  -----------
db_domain   US.EXAMPLE.COM

この結果は、パラメータ・ファイル内のドメイン設定が、2つのALTER DATABASE RENAME文の発行前の時点の設定と同じであることを示しています。

10. 最後に、warehouseデータベースへのリンクを作成し、再度USER_DB_LINKSを問い合せて、データベースが部分指定のグローバル名をどのように解決するのかを調べます。

CREATE DATABASE LINK warehouse USING 'warehouse';
SELECT DB_LINK FROM USER_DB_LINKS;

DB_LINK
------------------
HQ.US.EXAMPLE.COM
SUPPLY.JP.EXAMPLE.COM
WAREHOUSE.ASIA.JP.EXAMPLE.COM

ここでもデータベースは、リンクの作成時にローカル・データベースのグローバル・データベース名のドメイン部分を使用して、部分的なリンク名を拡張していることがわかります。

注意:
supplyデータベース・リンクを訂正するには、必ずこのデータベース・リンクを削除してから再作成してください。

関連項目:
DB_NAMEおよびDB_DOMAIN初期化パラメータの指定の詳細は、『Oracle Databaseリファレンス』を参照してください。

データベース・リンクの作成

アプリケーションによるデータおよびスキーマ・オブジェクトへのアクセスを分散データベース・システム全体にわたってサポートするために、必要なデータベース・リンクをすべて作成する必要があります。この項の内容は次のとおりです。

- データベース・リンクの作成に必要な権限の取得

- リンク・タイプの指定

- リンク・ユーザーの指定

- リンク名に含まれるサービス名を指定するための接続修飾子の使用

データベース・リンクの作成に必要な権限の取得

データベース・リンクは、リモート・データベースのオブジェクトへのアクセスを可能にするローカル・データベース内のポインタです。プライベート・データベース・リンクを作成するには、あらかじめ適切な権限が付与されている必要があります。次の表は、どのリンク・タイプのデータベースに対してどの権限が必要なのかを示しています。

権限

データベース

この権限を必要とする操作

CREATE DATABASE LINK

ローカル

プライベート・データベース・リンクの作成。

CREATE PUBLIC DATABASE LINK

ローカル

パブリック・データベース・リンクの作成。

CREATE SESSION

リモート

任意タイプのデータベース・リンクの作成。

現在使用可能な権限を確認するには、ROLE_SYS_PRIVSを問い合せます。たとえば、次のprivs.sqlスクリプトを作成し、実行できます(出力例も含まれています)。

SELECT DISTINCT PRIVILEGE AS "Database Link Privileges"
FROM ROLE_SYS_PRIVS
WHERE PRIVILEGE IN ( 'CREATE SESSION','CREATE DATABASE LINK',
'CREATE PUBLIC DATABASE LINK')
/

SQL> @privs

Database Link Privileges
----------------------------------------
CREATE DATABASE LINK
CREATE PUBLIC DATABASE LINK
CREATE SESSION

リンク・タイプの指定

データベース・リンクを作成するときは、そのデータベース・リンクにアクセスするユーザーを決める必要があります。ここでは、3種類の基本的なリンク・タイプの作成方法について説明します。

- プライベート・データベース・リンクの作成

- パブリック・データベース・リンクの作成

- グローバル・データベース・リンクの作成

プライベート・データベース・リンクの作成

プライベート・データベース・リンクを作成するには、次の文を指定します。ここで、link_nameはグローバル・データベース名または任意のリンク名を表します。

CREATE DATABASE LINK link_name ...;

プライベート・データベース・リンクの例を次に示します。

SQL文

結果

CREATE DATABASE LINK supply.us.example.com;

リモートのsupplyデータベースへの、グローバル・データベース名を使用したプライベート・リンク。
リンクは、接続ユーザーのユーザーID/パスワードを使用します。そのため、scott(パスワード: password)が問合せの中でこのリンクを使用すると、リモート・データベースへの接続がscott/passwordとして確立されます。

CREATE DATABASE LINK link_2 CONNECT TO jane IDENTIFIED BY password USING 'us_supply';

サービス名us_supplyを持つデータベースへの、link_2という名前のプライベート固定ユーザー・リンク。このリンクは、接続ユーザーとは無関係に、jane/passwordというユーザーID/パスワードでリモート・データベースに接続します。

CREATE DATABASE LINK link_1 CONNECT TO CURRENT_USER USING 'us_supply';

サービス名us_supplyを持つデータベースへの、link_1という名前のプライベート・リンク。このリンクは、現行ユーザーのユーザーID/パスワードを使用してリモート・データベースにログインします。
注意: 現行ユーザーと接続ユーザーは異なる場合があります。また、現行ユーザーは、リンクに関係している両方のデータベースのグローバル・ユーザーであることが必要です(「データベース・リンクのユーザー」を参照)。現行ユーザー・リンクは、Oracle Advanced Securityオプションの一部です。

関連項目:
CREATE DATABASE LINKの構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

パブリック・データベース・リンクの作成

パブリック・データベース・リンクを作成するには、キーワードPUBLICを使用します。ここで、link_nameはグローバル・データベース名または任意のリンク名を表します。

CREATE PUBLIC DATABASE LINK link_name ...;

パブリック・データベース・リンクの例を次に示します。

SQL文

結果

CREATE PUBLIC DATABASE LINK supply.us.example.com;

リモートのsupplyデータベースへのパブリック・リンク。リンクは、接続ユーザーのユーザーID/パスワードを使用します。そのため、scott(パスワード: password)が問合せの中でこのリンクを使用すると、リモート・データベースへの接続がscott/passwordとして確立されます。

CREATE PUBLIC DATABASE LINK pu_link CONNECT TO CURRENT_USER USING 'supply';

サービス名supplyを持つデータベースへの、pu_linkという名前のパブリック・リンク。このリンクは、現行ユーザーのユーザーID/パスワードを使用してリモート・データベースにログインします。
注意: 現行ユーザーと接続ユーザーは異なる場合があります。また、現行ユーザーは、リンクに関係している両方のデータベースのグローバル・ユーザーであることが必要です(「データベース・リンクのユーザー」を参照)。

CREATE PUBLIC DATABASE LINK sales.us.example.com CONNECT TO jane IDENTIFIED BY password;

リモートのsalesデータベースへのパブリック固定ユーザー・リンク。このリンクは、jane/passwordというユーザーID/パスワードでリモート・データベースに接続します。

関連項目:
CREATE PUBLIC DATABASE LINKの構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

グローバル・データベース・リンクの作成

以前のリリースでは、グローバル・データベース・リンクはOracle Names Serverで定義していました。Oracle Names Serverは非推奨になりました。現在はディレクトリ・サーバーが使用できるようになり、データベースはネット・サービス名によって識別されるようになりました。このマニュアルでは、ディレクトリ・サーバーでのネット・サービス名によるデータベースの識別をグローバル・データベース・リンクと呼びます。

グローバル・データベース・リンクとして動作するディレクトリ・エントリの作成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

リンク・ユーザーの指定

データベース・リンクは、あるデータベースから別のデータベースへの通信経路を定義します。アプリケーションがデータベース・リンクを使用してリモート・データベースに接続するとき、Oracle Databaseはローカル・アプリケーションの要求にかわってリモート・データベース内でデータベース・セッションを確立します。

プライベートまたはパブリックのデータベース・リンクを作成する際、固定ユーザー、現行ユーザーおよび接続ユーザーのデータベース・リンクを作成することで、リモート・データベースのどのスキーマにリンクが接続を確立するのかを指定できます。

固定ユーザー・データベース・リンクの作成

固定ユーザー・データベース・リンクを作成するには、リモート・データベースへのアクセスに必要な資格証明(この場合はユーザー名とパスワード)をリンク定義に埋め込みます。

CREATE DATABASE LINK ... CONNECT TO username IDENTIFIED BY password ...;

固定ユーザー・データベース・リンクの例を次に示します。

SQL文

結果

CREATE PUBLIC DATABASE LINK supply.us.example.com CONNECT TO scott IDENTIFIED BY password;

リモートのsupplyデータベースへの、グローバル・データベース名を使用したパブリック・リンク。このリンクは、scott/passwordというユーザーID/パスワードでリモート・データベースに接続します。

CREATE DATABASE LINK foo CONNECT TO jane IDENTIFIED BY password USING 'finance';

サービス名financeを持つデータベースへの、fooという名前のプライベート固定ユーザー・リンク。このリンクは、jane/passwordというユーザーID/パスワードでリモート・データベースに接続します。

アプリケーションで固定ユーザー・データベース・リンクを使用するとき、ローカル・サーバーは必ずリモート・データベース内の固定リモート・スキーマへの接続を確立します。また、ローカル・サーバーはアプリケーションがリンクを使用してリモート・データベースにアクセスするときに、ネットワークを介して固定ユーザーの資格証明を送信します。

接続ユーザーおよび現行ユーザー・データベース・リンクの作成

接続ユーザーおよび現行ユーザー・データベース・リンクでは、リンク定義に資格証明が含まれません。リモート・データベースへの接続に使用する資格証明は、データベース・リンクを参照するユーザーや、アプリケーションが実行する操作によって異なります。

注意:
多くの分散アプリケーションでは、ユーザーがリモート・データベースでの権限を持つ必要はありません。これを実現する簡単な方法の1つは、固定ユーザーまたは現行ユーザーのデータベース・リンクを含むプロシージャを作成することです。この方法では、プロシージャにアクセスするユーザーに対して第三者の権限が一時的に付与されます。

接続ユーザーと現行ユーザーの区別に関する概念の詳細は、「データベース・リンクのユーザー」を参照してください。

接続ユーザー・データベース・リンクの作成

接続ユーザー・データベース・リンクを作成するには、CONNECT TO句を省略します。次の構文は、接続ユーザー・データベース・リンクを作成し、ここでdblinkはリンクの名前、net_service_nameはオプションの接続文字列を表します。

CREATE [SHARED] [PUBLIC] DATABASE LINK dblink ... [USING 'net_service_name'];

たとえば、接続ユーザー・データベース・リンクを作成するために、次の構文を使用します。

CREATE DATABASE LINK sales.division3.example.com USING 'sales';

現行ユーザー・データベース・リンクの作成

現行ユーザー・データベース・リンクを作成するには、リンク作成文でCONNECT TO CURRENT_USER句を使用します。現行ユーザー・リンクは、Oracle Advanced Securityオプションでのみ使用できます。

次の構文は、現行ユーザー・データベース・リンクを作成します。ここで、dblinkはリンクの名前、net_service_nameはオプションの接続文字列を表します。

CREATE [SHARED] [PUBLIC] DATABASE LINK dblink CONNECT TO CURRENT_USER
[USING 'net_service_name'];

たとえば、salesデータベースへの現行ユーザー・データベース・リンクを作成するには、次の構文を使用します。

CREATE DATABASE LINK sales CONNECT TO CURRENT_USER USING 'sales';

注意:
現行ユーザー・データベース・リンクを使用するには、リンクに関係している両方のデータベースで現行ユーザーがグローバル・ユーザーであることが必要です。

関連項目:
データベース・リンクの作成に関する構文情報の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

リンク名に含まれるサービス名を指定するための接続修飾子の使用

場合によっては、同じリモート・データベースを指すものの、異なる通信経路を使用してリモート・データベースへの接続を確立する同じタイプ(パブリックなど)のデータベース・リンクを複数作成する必要があります。次のような場合に、この方法が役立ちます。

- リモート・データベースがOracle Real Application Clusters構成の一部であり、そのためリモート・データベースの特定のインスタンスに接続を確立できるようにローカル・ノードで複数のパブリック・データベース・リンクを定義する場合。

- Oracle Databaseサーバーへの接続に、TCP/IPを使用するクライアントと、DECNETを使用するクライアントがある場合。

このような機能を容易にするため、データベースでは、データベース・リンクにオプションのサービス名を付加したデータベース・リンク名を作成できます。データベース・リンクを作成するときに、サービス名を@記号で区切って(たとえば、@sales)、データベース・リンク名の末尾の部分として指定します。この文字列は接続修飾子と呼ばれます。

たとえば、リモート・データベースhq.example.comがOracle Real Application Clusters環境で管理されているとします。hqデータベースには、hq_1およびhq_2という名前の2つのインスタンスがあります。ローカル・データベースで次のパブリック・データベース・リンクを作成して、hqデータベースのリモート・インスタンスへの経路を定義できます。

CREATE PUBLIC DATABASE LINK hq.example.com@hq_1
USING 'string_to_hq_1';
CREATE PUBLIC DATABASE LINK hq.example.com@hq_2
USING 'string_to_hq_2';
CREATE PUBLIC DATABASE LINK hq.example.com
USING 'string_to_hq';

最初の2つの例では、サービス名は単なるデータベース・リンク名の一部であることに注目してください。サービス名のテキストは必ずしも接続の確立方法を示しているわけではないため、この情報はUSING句のサービス名で指定されています。また、3番目の例では、サービス名がリンク名の一部として指定されていないことに注目してください。この場合も、サービス名がリンク名の一部として指定されたときと同じように、インスタンスはUSING文字列によって決定されます。

サービス名を使用して特定のインスタンスを指定するには、サービス名をグローバル・オブジェクト名の末尾に付けます。

SELECT * FROM scott.emp@hq.example.com@hq_1

この例では、2つのアットマーク(@)があることに注意してください。

共有データベース・リンクの使用

標準のデータベース・リンクを使用してリモート・サーバーを参照するアプリケーションはすべて、ローカル・データベースとリモート・データベースの間で接続を確立します。多くのユーザーがアプリケーションを同時に実行した場合、ローカル・データベースとリモート・データベースの間で多数の接続が発生する可能性があります。

共有データベース・リンクを使用すると、ローカル・サーバーとリモート・サーバーの間で必要なネットワーク接続の数を制限できます。

この項の内容は次のとおりです。

- 共有データベース・リンクの使用の判断

- 共有データベース・リンクの作成

- 共有データベース・リンクの構成

関連項目:
共有データベース・リンクの概要の詳細は、「共有データベース・リンクの概要」を参照してください。

共有データベース・リンクの使用の判断

アプリケーションおよび共有サーバーの構成を綿密に検討して、共有リンクを使用するかどうかを判断してください。簡単なガイドラインとして、データベース・リンクにアクセスするユーザー数がローカル・データベース内のサーバー・プロセス数よりもかなり多いと予測されるときは、共有データベース・リンクを使用します。

データベース・リンクに関して可能な3つの構成を次の表に示します。

リンク・タイプ

サーバー・モード

結果

非共有

専用/共有サーバー

アプリケーションで標準のパブリック・データベース・リンクを使用していて、100人のユーザーが同時に接続を要求した場合は、リモート・データベースへの直接ネットワーク接続が100必要になります。

共有

共有サーバー

ローカルの共有サーバー・モード・データベースに10の共有サーバー・プロセスが存在している場合、同じデータベース・リンクを使用するユーザーが100人いるときに必要となるリモート・サーバーへのネットワーク接続数は10以下になります。ローカルの各共有サーバー・プロセスが必要とするリモート・サーバーへの接続は、それぞれ1つで済む場合があります。

共有

専用

10のクライアントがローカルの専用サーバーに接続していて、各クライアントが同じ接続のセッションを10持っており(したがって全部で100のセッションを確立している)、各セッションで同じリモート・データベースを参照している場合、必要な接続は10で済みます。非共有データベース・リンクでは、100の接続が必要になります。

共有データベース・リンクは、必ずしもすべての状況で役立つとはかぎりません。たとえば、リモート・サーバーに接続するユーザーが1人のみの場合を考えます。このユーザーが共有データベース・リンクを定義し、ローカル・データベースに10個の共有サーバー・プロセスが存在する場合、このユーザーはリモート・サーバーへのネットワーク接続を最大10個必要とする可能性があります。ユーザーは個々の共有サーバー・プロセスを使用できるため、各プロセスはそれぞれリモート・サーバーへの接続を確立できます。

この場合、ネットワーク接続は1つしか必要ないため、明らかに非共有データベース・リンクの方が適しています。シングルユーザー環境では、共有データベース・リンクの使用はネットワーク接続の増加につながるため、共有リンクは、複数のユーザーが同じリンクを使用する必要がある場合にのみ使用します。通常、共有リンクはパブリック・データベース・リンクに使用しますが、複数のクライアントが同じローカル・スキーマにアクセスする場合(その結果、同じプライベート・データベース・リンクにアクセスする場合)はプライベート・データベース・リンクにも使用できます。

注意:
複数階層の環境では、共有データベース・リンクを使用してリモート・データベースに接続した場合、そのリモート・データベースは、移行不可能なデータベース・リンクを使用して別のデータベースにリンクできないという制約があります。このリンクには共有サーバーを使用するか、またはリンク自体が別の共有データベース・リンクである必要があります。

共有データベース・リンクの作成

共有データベース・リンクを作成するには、CREATE DATABASE LINK文でキーワードSHAREDを使用します。

CREATE SHARED DATABASE LINK dblink_name
[CONNECT TO username IDENTIFIED BY password]|[CONNECT TO CURRENT_USER]
AUTHENTICATED BY schema_name IDENTIFIED BY password
[USING 'service_name'];

キーワードSHAREDを使用するときは、必ずAUTHENTICATED BY句が必要です。AUTHENTICATED BYで指定されたスキーマがリモート・データベースに存在し、少なくとも、CREATE SESSION権限が付与されている必要があります。このスキーマの資格証明は、ローカル・データベースとリモート・データベース間での認証方式と考えることができます。これらの資格証明は、データベース・リンクのユーザーになりすまして情報に不当にアクセスしようとするクライアントから、リモート共有サーバー・プロセスを保護するために必要です。

共有データベース・リンクとの接続後、リモート・データベース上での操作は、AUTHENTICATED BYスキーマではなく、CONNECT TOユーザー、またはCURRENT_USERの権限で実行されます。

次の例では、scottとして接続し、linkuserとして認証される、salesデータベースへの固定ユーザー共有リンクを作成しています。

CREATE SHARED DATABASE LINK link2sales
CONNECT TO scott IDENTIFIED BY password
AUTHENTICATED BY linkuser IDENTIFIED BY ostrich
USING 'sales';

関連項目:
CREATE DATABASE LINK文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

共有データベース・リンクの構成

共有データベース・リンクは、次の方法で構成できます。

- 専用サーバーへの共有リンクの作成

- 共有サーバーへの共有リンクの作成

専用サーバーへの共有リンクの作成

図32-1に示す構成では、ローカル・サーバーの共有サーバー・プロセスは専用のリモート・サーバー・プロセスを所有しています。この構成の利点は、ローカルの共有サーバーとリモートの専用サーバーとの間に直接的なネットワーク・トランスポートが存在することです。ただし、余分なバックエンド・サーバー・プロセスが必要になるというデメリットもあります。

注意:
リモート・サーバーは、共有サーバーまたは専用サーバーのどちらか一方にできます。ローカル・サーバーとリモート・サーバーの間には専用の接続が存在します。リモート・サーバーが共有サーバーのときは、サービス名の定義にSERVER=DEDICATED句を使用することで、専用サーバー接続を強制できます。

図32-1 専用サーバー・プロセスへの共有データベース・リンク

共有サーバーへの共有リンクの作成

図32-2に示す構成では、リモート・サーバーで共有サーバー・プロセスを使用しています。この構成では、多数の専用サーバー・プロセスは必要ありませんが、リモート・サーバーのディスパッチャを経由する接続が必要になります。この場合、ローカル・サーバーとリモート・サーバーの両方を共有サーバーとして構成する必要があります。

図32-2 共有サーバーへの共有データベース・リンク

関連項目:
共有サーバー・オプションの詳細は、「共有サーバー・プロセス」を参照してください。

データベース・リンクの管理

この項の内容は次のとおりです。

- データベース・リンクのクローズ

- データベース・リンクの削除

- アクティブ・データベース・リンクの接続数の制限

データベース・リンクのクローズ

あるセッションでデータベース・リンクにアクセスする場合、そのセッションをクローズするまでリンクはオープンしたままです。リンクがオープンしているということは、そのリンクを介してアクセスしている各リモート・データベースのプロセスがアクティブであることを意味します。この状況では、次のような結果が生じます。

- 20人のユーザーがセッションをオープンしてローカル・データベースの同じパブリック・リンクにアクセスする場合、20のデータベース・リンク接続がオープンします。

- 20人のユーザーがセッションをオープンして各ユーザーがプライベート・リンクにアクセスする場合、20のデータベース・リンク接続がオープンします。

- 1人のユーザーがセッションを開始して20の異なるリンクにアクセスする場合、20のデータベース・リンク接続がオープンします。

セッションをクローズした後、セッションでアクティブだったリンクは自動的にクローズされます。ユーザーがリンクを手動でクローズする場合もあります。たとえば、次のようなときにリンクをクローズします。

- リンクによって確立されたネットワーク接続がアプリケーションでそれほど頻繁に使用されないとき。

- ユーザー・セッションを終了する必要があるとき。

リンクをクローズするには次の文を発行しますが、ここでlinknameはリンクの名前を表します。

ALTER SESSION CLOSE DATABASE LINK linkname;

この文は、現行セッションでアクティブなリンクのみをクローズします。

データベース・リンクの削除

データベース・リンクは、表やビューと同様に削除できます。リンクがプライベートの場合は、自分のスキーマ内に存在する必要があります。リンクがパブリックの場合は、DROP PUBLIC DATABASE LINKシステム権限が必要です。

構文は次のとおりです。ここで、dblinkはリンクの名前を表します。

DROP [PUBLIC] DATABASE LINK dblink;

プライベート・データベース・リンクの削除手順

1. SQL*Plusを使用して、ローカル・データベースに接続します。たとえば、次のように入力します。

CONNECT scott@local_db

2. USER_DB_LINKSを問い合せて、所有しているリンクを確認します。たとえば、次のように入力します。

SELECT DB_LINK FROM USER_DB_LINKS;

DB_LINK
-----------------------------------
SALES.US.EXAMPLE.COM
MKTG.US.EXAMPLE.COM
2 rows selected.

3. DROP DATABASE LINK文を使用して、目的のリンクを削除します。たとえば、次のように入力します。

DROP DATABASE LINK sales.us.example.com;

パブリック・データベース・リンクの削除手順

1. ローカル・データベースにDROP PUBLIC DATABASE LINK権限を持つユーザーとして接続します。たとえば、次のように入力します。

CONNECT SYSTEM@local_db AS SYSDBA

2. DBA_DB_LINKSを問い合せて、パブリック・リンクを確認します。たとえば、次のように入力します。

SELECT DB_LINK FROM DBA_DB_LINKS
WHERE OWNER = 'PUBLIC';

DB_LINK
-----------------------------------
DBL1.US.EXAMPLE.COM
SALES.US.EXAMPLE.COM
INST2.US.EXAMPLE.COM
RMAN2.US.EXAMPLE.COM
4 rows selected.

3. DROP PUBLIC DATABASE LINK文を使用して、目的のリンクを削除します。たとえば、次のように入力します。

DROP PUBLIC DATABASE LINK sales.us.example.com;

アクティブ・データベース・リンクの接続数の制限

静的な初期化パラメータOPEN_LINKSを使用すると、ユーザー・プロセスからリモート・データベースへの接続数を制限できます。このパラメータは、分散トランザクションにおいて1つのユーザー・セッションが同時に使用できるリモート接続数を制御します。

このパラメータを設定する際は、次の点を考慮してください。

- 設定値は、複数のデータベースを参照する1つのSQL文によって参照されるデータベースの数以上にします。

- 複数の分散データベースに継続してアクセスする場合は、設定値を大きくします。たとえば、3つのデータベースに定期的にアクセスする場合は、OPEN_LINKSを3以上に設定します。

- OPEN_LINKSのデフォルト値は4です。OPEN_LINKSを0(ゼロ)に設定した場合、分散トランザクションは許可されません。

関連項目:
OPEN_LINKS初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベース・リンク情報の表示

各データベースのデータ・ディクショナリには、そのデータベース内にあるデータベース・リンクの定義がすべて格納されています。データ・ディクショナリ表およびビューを使用して、リンクに関する情報を取得できます。この項の内容は次のとおりです。

- データベース内のリンクの判断

- オープンしているリンク接続の判断

データベース内のリンクの判断

次のビューには、ローカル・データベースで定義され、データ・ディクショナリに格納されているデータベース・リンクが表示されます。

ビュー

目的

DBA_DB_LINKS

データベース内のデータベース・リンクがすべてリストされます。

ALL_DB_LINKS

接続ユーザーがアクセス可能なデータベース・リンクがすべてリストされます。

USER_DB_LINKS

接続ユーザーが所有しているデータベース・リンクがすべてリストされます。

これらのデータ・ディクショナリ・ビューには、データベース・リンクに関する同じ基本情報が含まれていますが、いくつか例外もあります。

列

対象となるビュー

説明

OWNER

USER_*を除くすべて

データベース・リンクを作成したユーザー。リンクがパブリックの場合、ユーザーはPUBLICとしてリストされます。

DB_LINK

すべて

データベース・リンクの名前。

USERNAME

すべて

リンク定義に固定ユーザーが含まれている場合、この列には固定ユーザーのユーザー名が表示されます。固定ユーザーが含まれていない場合、この列はNULLになります。

PASSWORD

USER_*のみ

使用されません。下位互換性のためにのみ維持されています。

HOST

すべて

リモート・データベースへの接続に使用されるネット・サービス名。

CREATED

すべて

データベース・リンクの作成日時。

どのユーザーでもUSER_DB_LINKSを問い合せることで、そのユーザーが使用できるデータベース・リンクを判断できます。ALL_DB_LINKSビューまたはDBA_DB_LINKSビューを使用できるのは、追加の権限を持つユーザーのみです。

次のスクリプトは、DBA_DB_LINKSビューを問い合せて、リンク情報にアクセスします。

COL OWNER FORMAT a10
COL USERNAME FORMAT A8 HEADING "USER"
COL DB_LINK FORMAT A30
COL HOST FORMAT A7 HEADING "SERVICE"
SELECT * FROM DBA_DB_LINKS
/

ここでスクリプトが起動され、その出力結果が表示されます。

SQL>@link_script

OWNER      DB_LINK                        USER     SERVICE CREATED
---------- ------------------------------ -------- ------- ----------
SYS        TARGET.US.EXAMPLE.COM             SYS      inst1   23-JUN-99
PUBLIC     DBL1.UK.EXAMPLE.COM               BLAKE    ora51   23-JUN-99
PUBLIC     RMAN2.US.EXAMPLE.COM                       inst2   23-JUN-99
PUBLIC     DEPT.US.EXAMPLE.COM                        inst2   23-JUN-99
JANE       DBL.UK.EXAMPLE.COM                BLAKE    ora51   23-JUN-99
SCOTT      EMP.US.EXAMPLE.COM                SCOTT    inst2   23-JUN-99
6 rows selected.

オープンしているリンク接続の判断

自分のセッションで現在オープンしているデータベース・リンク接続がわかれば役に立つ場合があります。しかし、SYSDBAとして接続している場合には、ビューを問い合せてすべてのセッションでオープンしているすべてのリンクを判断することはできず、現在作業中のセッションのリンク情報にアクセスすることしかできません。

次のビューには、現行セッションで現在オープンしているデータベース・リンク接続が表示されます。

ビュー

目的

V$DBLINK

自分のセッションでオープンしているすべてのデータベース・リンク、つまり、IN_TRANSACTION列がYESに設定されているすべてのデータベース・リンクがリストされます。

GV$DBLINK

自分のセッションでオープンしているすべてのデータベース・リンクと対応するインスタンスがリストされます。このビューは、Oracle Real Application Clusters構成の使用時に役立ちます。

これらのデータ・ディクショナリ・ビューには、データベース・リンクに関する同じ基本情報が含まれていますが、1つ例外があります。

列

対象となるビュー

説明

DB_LINK

すべて

データベース・リンクの名前。

OWNER_ID

すべて

データベース・リンクの所有者。

LOGGED_ON

すべて

データベース・リンクが現在ログインされているかどうか。

HETEROGENEOUS

すべて

データベース・リンクが同機種間(NO)と異機種間(YES)のどちらであるか。

PROTOCOL

すべて

データベース・リンクの通信プロトコル。

OPEN_CURSORS

すべて

データベース・リンクでカーソルがオープンされているかどうか。

IN_TRANSACTION

すべて

コミットまたはロールバックがまだ完了していないトランザクションで、データベース・リンクがアクセスされているかどうか。

UPDATE_SENT

すべて

データベース・リンクで更新があったかどうか。

COMMIT_POINT_STRENGTH

すべて

データベース・リンクを使用しているトランザクションのコミット・ポイント強度。

INST_ID

GV$DBLINKのみ

ビュー情報が取得されたインスタンス。

たとえば、次のスクリプトを作成し、実行することで、オープンされているリンクを判断できます(出力例も含まれています)。

COL DB_LINK FORMAT A25
COL OWNER_ID FORMAT 99999 HEADING "OWNID"
COL LOGGED_ON FORMAT A5 HEADING "LOGON"
COL HETEROGENEOUS FORMAT A5 HEADING "HETER"
COL PROTOCOL FORMAT A8
COL OPEN_CURSORS FORMAT 999 HEADING "OPN_CUR"
COL IN_TRANSACTION FORMAT A3 HEADING "TXN"
COL UPDATE_SENT FORMAT A6 HEADING "UPDATE"
COL COMMIT_POINT_STRENGTH FORMAT 99999 HEADING "C_P_S"

SELECT * FROM V$DBLINK
/

SQL> @dblink

DB_LINK                   OWNID LOGON HETER PROTOCOL OPN_CUR TXN UPDATE  C_P_S
------------------------- ------ ----- ----- -------- ------- --- ------ ------
INST2.EXAMPLE.COM                 0 YES   YES    UNKN          0 YES YES       255

位置の透過性の作成

必要なデータベース・リンクの構成が完了した後、各種のツールを使用してデータベース・システムの分散的な性質をユーザーから隠すことができます。言い換えれば、ユーザーはリモート・オブジェクトに対してあたかもローカル・オブジェクトであるかのようにアクセスできるようになります。ここでは、分散機能をユーザーから隠す方法について説明します。

- ビューを使用した位置の透過性の作成

- シノニムを使用した位置の透過性の作成

- プロシージャを使用した位置の透過性の作成

ビューを使用した位置の透過性の作成

ローカル・ビューは、分散データベース・システムにおいてローカルおよびリモートの表に対する位置の透過性を提供できます。

たとえば、emp表がローカル・データベースに、dept表がリモート・データベースに、それぞれ格納されているとします。システムのユーザーに対してこれらの表を透過的にするために、ローカル・データとリモート・データを結合するビューをローカル・データベースに作成できます。

CREATE VIEW company AS
SELECT a.empno, a.ename, b.dname
FROM scott.emp a, jward.dept@hq.example.com b
WHERE a.deptno = b.deptno;

図32-3 ビューと位置の透過性

ユーザーはこのビューにアクセスするときに、データが物理的に格納されている場所や、複数の表のデータにアクセスしているかどうかについて知る必要はありません。したがって、ユーザーは必要な情報をより簡単に取得できます。たとえば、次の問合せは、ローカルおよびリモートの両方のデータベース表からのデータを提供します。

SELECT * FROM company;

ローカル・ビューの所有者は、リモート・ユーザーによってすでに付与されているローカル・ビューのオブジェクト権限のみを付与できます。(リモート・ユーザーはデータベース・リンクのタイプによって示されます)。これは、ローカル・データを参照するビューの権限の管理と似ています。

シノニムを使用した位置の透過性の作成

シノニムは、分散データベース・システム内での位置など、基礎となるオブジェクトの個別情報を隠すので、分散環境と非分散環境の両方で役立ちます。基礎となるオブジェクトを名前変更または移動する必要がある場合でも、シノニムを再定義するだけで済み、シノニムをベースとするアプリケーションは引き続き通常どおり動作します。また、分散データベース・システムのユーザーが使用するSQL文も、シノニムによって単純化されます。

シノニムの作成

次のもののシノニムを作成できます。

- 表

- タイプ

- ビュー

- マテリアライズド・ビュー

- 順序

- プロシージャ

- ファンクション

- パッケージ

シノニムはすべて、作成するデータベースのデータ・ディクショナリに格納されるスキーマ・オブジェクトです。シノニムでは、データベース・リンクを介したリモート表へのアクセスを簡単にするために、単一ワードでリモート・データにアクセスでき、それによって特定のオブジェクト名や位置をシノニムのユーザーから隠すことができます。

シノニムを作成するための構文は、次のとおりです。

CREATE [PUBLIC] synonym_name
FOR [schema.]object_name[@database_link_name];

説明:

- PUBLICは、すべてのユーザーがこのシノニムを使用できることを指定するキーワードです。このパラメータを省略するとシノニムがプライベートになり、作成者のみ使用可能になります。パブリック・シノニムは、CREATE PUBLIC SYNONYMシステム権限を持つユーザーのみが作成できます。

- synonym_nameには、ユーザーおよびアプリケーションが参照する代替オブジェクト名を指定します。

- schemaには、object_nameで指定されたオブジェクトのスキーマを指定します。このパラメータを省略すると、オブジェクトのスキーマとして作成者のスキーマが使用されます。

- object_nameには、表、ビュー、順序、マテリアライズド・ビュー、型、プロシージャ、ファンクションまたはパッケージのいずれかを適宜指定します。

- database_link_nameには、object_nameで指定されたオブジェクトが存在するリモート・データベースおよびスキーマを識別するデータベース・リンクを指定します。

シノニムには、そのスキーマ内に存在するオブジェクトの中で一意の名前を付ける必要があります。スキーマにスキーマ・オブジェクトがあり、同じ名前のパブリック・シノニムが存在する場合、データベースはスキーマを所有しているユーザーがその名前を参照するときに、常にスキーマ・オブジェクトの方を検索します。

例: パブリック・シノニムの作成

分散データベース・システム内のすべてのデータベースにおいて、hqデータベースに格納されているscott.emp表のパブリック・シノニムが定義されているとします。

CREATE PUBLIC SYNONYM emp FOR scott.emp@hq.example.com;

表scott.emp@hq.example.comの位置はパブリック・シノニムによって隠されているので、使用場所に依存しない従業員管理アプリケーションを設計できます。アプリケーション内のSQL文は、パブリック・シノニムempを参照して表にアクセスできます。

また、emp表をhqデータベースからhrデータベースに移動する場合も、システムのノードでパブリック・シノニムを変更するだけで済みます。従業員管理アプリケーションは、すべてのノードで引き続き正常に動作します。

権限とシノニムの管理

シノニムは、実際のオブジェクトへの参照です。特定のスキーマ・オブジェクトのシノニムにアクセスするユーザーは、元のスキーマ・オブジェクトそのものに対する権限を持っている必要があります。たとえば、ユーザーがシノニムにアクセスしようとして、そのシノニムが識別する表に対してユーザーが権限を持っていなければ、表またはビューが存在しないというエラーが発生します。

scottが、リモート・オブジェクトscott.emp@sales.example.comの別名としてローカル・シノニムempを作成したとします。scottは、このシノニムのオブジェクト権限を別のローカル・ユーザーに付与できません。この操作はsalesデータベースのリモートのemp表の権限の付与に相当しますが、これは許可されていないので、scottはこのシノニムのローカル権限を付与することはできません。この動作は、ローカルの表またはビューの別名であるシノニムの権限管理とは異なります。

したがって、シノニムを位置の透過性のために使用する場合、ローカル権限は管理できません。ベース・オブジェクトのセキュリティは、リモート・ノードですべて管理されます。たとえば、ユーザーadminはemp_synシノニムのオブジェクト権限を付与することはできません。

ビューやプロシージャの定義で参照されるデータベース・リンクとは異なり、シノニムで参照されるデータベース・リンクを解決する際は、シノニムへの参照が解析される時点で有効なスキーマが所有しているプライベート・リンクが最初に検索されます。したがって、オブジェクトの適切な解決を保証するには、基礎となるオブジェクトのスキーマをシノニムの定義の中で指定することが特に重要になります。

プロシージャを使用した位置の透過性の作成

プロシージャと呼ばれるPL/SQLプログラム・ユニットは、位置の透過性を提供できます。それには、次の方法があります。

- ローカル・プロシージャを使用したリモート・データの参照

- ローカル・プロシージャを使用したリモート・プロシージャのコール

- ローカル・シノニムを使用したリモート・プロシージャの参照

ローカル・プロシージャを使用したリモート・データの参照

プロシージャおよびファンクションには、スタンドアロンとパッケージのどちらの場合でも、リモート・データを参照するSQL文を含めることができます。たとえば、次の文で作成されるプロシージャを考えます。

CREATE PROCEDURE fire_emp (enum NUMBER) AS
BEGIN
DELETE FROM emp@hq.example.com
WHERE empno = enum;
END;

ユーザーまたはアプリケーションがfire_empプロシージャをコールするときに、リモート表が変更されようとしていることは見かけ上わかりません。

プロシージャ内の文でローカルのプロシージャ、ビューまたはシノニムを使用して間接的にリモート・データを参照するときは、2層目の位置の透過性が可能です。たとえば、次の文はローカル・シノニムを定義します。

CREATE SYNONYM emp FOR emp@hq.example.com;

このシノニムがあれば、次の文を使用してfire_empプロシージャを作成できます。

CREATE PROCEDURE fire_emp (enum NUMBER) AS
BEGIN
DELETE FROM emp WHERE empno = enum;
END;

表emp@hq.acme.comを名前変更または移動した場合でも、表を参照するローカル・シノニムを変更するだけで済みます。このプロシージャをコールするプロシージャやアプリケーションを変更する必要はありません。

ローカル・プロシージャを使用したリモート・プロシージャのコール

ローカル・プロシージャを使用してリモート・プロシージャをコールできます。リモート・プロシージャでは、要求されたデータ操作言語(DML)を実行できます。たとえば、scottがlocal_dbに接続して次のプロシージャを作成したとします。

CONNECT scott@local_db

CREATE PROCEDURE fire_emp (enum NUMBER)
AS
BEGIN
EXECUTE term_emp@hq.example.com;
END;

ここで、scottは、リモート・データベースに接続して次のリモート・プロシージャを作成するとします。

CONNECT scott@hq.example.com

CREATE PROCEDURE term_emp (enum NUMBER)
AS
BEGIN
DELETE FROM emp WHERE empno = enum;
END;

ユーザーまたはアプリケーションがlocal_dbに接続してfire_empプロシージャをコールすると、このプロシージャはさらにhq.example.comにあるリモートのterm_empプロシージャをコールします。

ローカル・シノニムを使用したリモート・プロシージャの参照

たとえば、scottがローカルのsales.example.comデータベースに接続して次のプロシージャを作成したとします。

CREATE PROCEDURE fire_emp (enum NUMBER) AS
BEGIN
DELETE FROM emp@hq.example.com
WHERE empno = enum;
END;

この後、ユーザーpeggyがsupply.example.comデータベースに接続し、scottがリモートのsalesデータベースで作成したプロシージャに対する次のシノニムを作成します。

SQL> CONNECT peggy@supply
SQL> CREATE PUBLIC SYNONYM emp FOR scott.fire_emp@sales.example.com;

supplyのローカル・ユーザーは、このシノニムを使用してsalesのプロシージャを実行できます。

プロシージャと権限の管理

ローカル・プロシージャに、リモート表またはリモート・ビューを参照する文が含まれているとします。ローカル・プロシージャの所有者はexecute権限をすべてのユーザーに付与できるため、任意のユーザーがプロシージャを実行して間接的にリモート・データにアクセスできるようにすることができます。

一般に、プロシージャはセキュリティの面で役に立ちます。プロシージャの中で参照されるオブジェクトの権限を明示的にコール側のユーザーに付与する必要はありません。

文の透過性の管理

データベースでは、次に示す標準のDML文でリモート表を参照することが可能です。

- SELECT (問合せ)

- INSERT

- UPDATE

- DELETE

- SELECT...FOR UPDATE(異機種間システムでは常にサポートされるとはかぎらない)

- LOCK TABLE

結合、集計、副問合せおよびSELECT...FOR UPDATEを含む問合せでは、ローカルおよびリモートの表およびビューをいくつでも参照できます。たとえば、次の問合せは2つのリモート表の情報を結合します。

SELECT e.empno, e.ename, d.dname
FROM scott.emp@sales.division3.example.com e, jward.dept@hq.example.com d
WHERE e.deptno = d.deptno;

同機種環境では、UPDATE、INSERT、DELETEおよびLOCK TABLE文は、ローカルおよびリモートの両方の表を参照できます。リモート・データを更新するためのプログラミングは不要です。たとえば、次の文はローカル・データベースのjwardスキーマのemp表から行を選択して、scott.salesスキーマのリモート表empに新しい行を挿入します。

INSERT INTO scott.emp@sales.division3.example.com
SELECT * FROM jward.emp;

文の透過性に関する制限事項

文の透過性には、いくつかの制限事項が適用されます。

- リモートのOracle Database以外のシステム上のオブジェクトを更新するデータ操作言語文では、ローカルのOracle Databaseのオブジェクトを参照できません。たとえば、次のような文を実行するとエラーになります。

INSERT INTO remote_table@link as SELECT * FROM local_table;

- 1つのSQL文において、参照されるすべてのLONGおよびLONG RAWの列、順序、更新済の表およびロック済の表は、同じノードに存在する必要があります。

- データベースでは、同機種システムにおけるリモートのデータ定義言語(DDL)文(CREATE、ALTER、DROPなど)は使用できません。ただし、次の例のようにDBMS_SQLパッケージのプロシージャのリモート実行を使用する場合を除きます。

DBMS_SQL.PARSE@link_name(crs, 'drop table emp', v7);

異機種間システムでは、パススルー機能によってDDLの実行が可能です。

- ANALYZE文のLIST CHAINED ROWS句は、リモート表を参照できません。

- 分散データベース・システムでは、SYSDATE、USER、UID、USERENVなどの環境に依存したSQLファンクションは、データベースによって、その文(または文の一部)が実行される場所にかかわらず、常にローカル・サーバーについて評価されます。

注意:
Oracle Databaseは、USERENVファンクションを問合せの用途でのみサポートしています。

- リモート・オブジェクトのアクセスに関連して、次のようなパフォーマンス上の制限事項があります。

- リモート・ビューは統計データを持ちません。

- パーティション表に対する問合せは、最適化されない場合があります。

- リモート表で考慮される索引の数は20以下です。

- コンポジット索引で使用される列の数は20以下です。

- Oracle Databaseの分散読込み一貫性の実装には制限があり、これによってあるノードが別のノードに対して古い状態になる可能性があります。問合せを実行したときに、読込み一貫性に従ってデータが取得されているにもかからわず、そのデータが古い場合があります。この問題の管理方法の詳細は、「読込み一貫性の管理」を参照してください。

関連項目:
DBMS_SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

分散データベースの管理: 例

ここでは、データベース・リンクの管理例を示します。

- 例1: パブリック固定ユーザーのデータベース・リンクの作成

- 例2: パブリック固定ユーザーの共有データベース・リンクの作成

- 例3: パブリック接続ユーザーのデータベース・リンクの作成

- 例4: パブリック接続ユーザーの共有データベース・リンクの作成

- 例5: パブリック現行ユーザーのデータベース・リンクの作成

例1: パブリック固定ユーザーのデータベース・リンクの作成

次の文では、ローカル・データベースにjaneとして接続し、データベースsalesに対してパブリック固定ユーザーscottのデータベース・リンクを作成しています。データベースには、ネット・サービス名sldbを介してアクセスします。

CONNECT jane@local

CREATE PUBLIC DATABASE LINK sales.division3.example.com
CONNECT TO scott IDENTIFIED BY password
USING 'sldb';

この文の実行後は、ローカル・データベースに接続する任意のユーザーが、sales.division3.example.comデータベース・リンクを使用してリモート・データベースに接続できます。各ユーザーは、リモート・データベースのスキーマscottに接続します。

ユーザーは、次のSQL問合せを発行して、scottのリモート・スキーマの表empにアクセスできます。

SELECT * FROM emp@sales.division3.example.com;

各アプリケーションまたはユーザー・セッションは、サーバーの共通アカウントへの接続をそれぞれ別々に作成します。リモート・データベースへの接続は、アプリケーションの実行中またはユーザー・セッションの継続期間中オープンしたままです。

例2: パブリック固定ユーザーの共有データベース・リンクの作成

次の例では、ローカル・データベースにdanaとして接続し、ネット・サービス名sldbを使用してsalesデータベースへのパブリック・リンクを作成しています。このリンクによって、リモート・データベースにscottとして接続でき、このユーザーがscottとして認証されます。

CONNECT dana@local

CREATE SHARED PUBLIC DATABASE LINK sales.division3.example.com
CONNECT TO scott IDENTIFIED BY password
AUTHENTICATED BY scott IDENTIFIED BY password
USING 'sldb';

ローカルの共有サーバーに接続する任意のユーザーがこのデータベース・リンクを使用し、共有サーバー・プロセスを介してリモートのsalesデータベースに接続できます。その後ユーザーは、scottスキーマの表を問い合せることができます。

前述の例では、ローカルの共有サーバーはリモート・サーバーへの接続を1つずつ確立できます。ローカルの共有サーバー・プロセスでsales.division3.example.comデータベース・リンクを介したリモート・サーバーへのアクセスが必要になると、そのたびにローカルの共有サーバー・プロセスは確立済のネットワーク接続を再利用します。

例3: パブリック接続ユーザーのデータベース・リンクの作成

次の例では、ローカル・データベースにlarryとして接続し、ネット・サービス名sldbを使用してデータベースへのパブリック・リンクを作成しています。

CONNECT larry@local

CREATE PUBLIC DATABASE LINK redwood
USING 'sldb';

ローカル・データベースに接続する任意のユーザーが、redwoodデータベース・リンクを使用できます。データベース・リンクを使用するローカル・データベースの接続ユーザーによって、リモート・スキーマが決まります。

接続ユーザーscottがデータベース・リンクを使用した場合、データベース・リンクはリモート・スキーマscottに接続します。接続ユーザーfoxがデータベース・リンクを使用した場合、データベース・リンクはリモート・スキーマfoxに接続します。

リモート・スキーマfoxがempスキーマ・オブジェクトを解決できない場合は、ローカル・データベースでローカル・ユーザーfoxが次の文を実行すると失敗します。つまり、sales.division3.example.comのfoxスキーマにempが表、ビューまたは(パブリック)シノニムとして存在しない場合は、エラーが返されます。

CONNECT fox@local

SELECT * FROM emp@redwood;

例4: パブリック接続ユーザーの共有データベース・リンクの作成

次の例では、ローカル・データベースにneilとして接続し、ネット・サービス名sldbを使用してsalesデータベースへの共有パブリック・リンクを作成しています。ユーザーは、crazy/horseというユーザーID/パスワードによって認証されます。次の文は、パブリック接続ユーザーの共有データベース・リンクを作成します。

CONNECT neil@local

CREATE SHARED PUBLIC DATABASE LINK sales.division3.example.com
AUTHENTICATED BY crazy IDENTIFIED BY horse
USING 'sldb';

ローカル・サーバーに接続する各ユーザーは、この共有データベース・リンクを使用してリモート・データベースに接続し、対応するリモート・スキーマの表を問い合せることができます。

ローカルの共有サーバー・プロセスは、それぞれリモート・サーバーへの接続を1つずつ確立します。ローカルのサーバー・プロセスでsales.division3.example.comデータベース・リンクを介したリモート・サーバーへのアクセスが必要になると、たとえ接続ユーザーが異なるユーザーであっても、そのたびにローカルの共有サーバー・プロセスは確立済のネットワーク接続を再利用します。

このデータベース・リンクが頻繁に使用されると、最終的にローカル・データベースのすべての共有サーバーがリモート接続を持つことになります。この時点で、新しいユーザーがこの共有データベース・リンクを使用しても、リモート・サーバーへの物理的な接続は新たに確立されません。

例5: パブリック現行ユーザーのデータベース・リンクの作成

次の例では、ローカル・データベースに接続ユーザーとして接続し、ネット・サービス名sldbを使用してsalesデータベースへのパブリック・リンクを作成しています。次の文は、パブリック現行ユーザーのデータベース・リンクを作成します。

CONNECT bart@local

CREATE PUBLIC DATABASE LINK sales.division3.example.com
CONNECT TO CURRENT_USER
USING 'sldb';

注意:
このリンクを使用するには、現行ユーザーがグローバル・ユーザーであることが必要です。

このデータベース・リンクの結果は、次のとおりです。

scottがリモートのemp表から1行を削除するローカル・プロシージャfire_empを作成し、fire_empの実行権限をfordに付与したとします。

CONNECT scott@local_db

CREATE PROCEDURE fire_emp (enum NUMBER)
AS
BEGIN
DELETE FROM emp@sales.division3.example.com
WHERE empno=enum;
END;

GRANT EXECUTE ON fire_emp TO ford;

ここで、fordはローカル・データベースに接続してscottのプロシージャを実行したとします。

CONNECT ford@local_db

EXECUTE PROCEDURE scott.fire_emp (enum 10345);

fordがプロシージャscott.fire_empを実行するとき、プロシージャはscottの権限のもとで実行されます。現行ユーザー・データベース・リンクが使用されているため、接続はfordのリモート・スキーマではなく、scottのリモート・スキーマに確立されます。scottはグローバル・ユーザーである必要がありますが、fordはグローバル・ユーザーでなくてもかまいません。

注意:
かわりに接続ユーザー・データベース・リンクが使用された場合、接続はfordのリモート・スキーマに確立されます。実行者権限と権限の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

scottのリモート・スキーマへの固定ユーザー・データベース・リンクを使用しても、同じ結果を得ることができます。

33 分散データベース・システムのアプリケーション開発

この章の内容は、次のとおりです。

- アプリケーション・データの分散の管理

- データベース・リンクにより確立される接続の制御

- 分散システムの参照整合性の維持

- 分散問合せのチューニング

- リモート・プロシージャのエラー処理

関連項目:
Oracle Database環境でのアプリケーション開発の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

アプリケーション・データの分散の管理

分散データベース環境では、データベース管理者と共同でデータの最適な格納場所を決めます。その際、次の点について考慮します。

- 個々の場所から転送されるトランザクション数

- 各ノードで使用されるデータ(表の部分)の量

- パフォーマンス特性とネットワークの信頼性

- 各種ノードの速度とディスクの容量

- ノードまたはリンクが使用できないときの重要度

- 表間の参照整合性の必要性

データベース・リンクにより確立される接続の制御

SQL文やリモート・プロシージャ・コールの中でグローバル・オブジェクト名が参照されると、ローカル・ユーザーにかわってデータベース・リンクがリモート・データベース内のセッションへの接続を確立します。リモートの接続とセッションは、それまでにローカルのユーザー・セッションに対して接続が確立されていない場合にのみ作成されます。

リモート・データベースとの間に確立された接続とセッションは、アプリケーションやユーザーによって明示的に終了されないかぎり、ローカル・ユーザーのセッションの間存続します。データベース・リンクを経由してSELECT文を発行すると、UNDOセグメントにトランザクション・ロックが設定されます。セグメントを再び解放するには、COMMIT文またはROLLBACK文を発行する必要があります。

アプリケーションで不要になった高コストの接続を切断するには、データベース・リンクを使用して確立されたリモート接続を終了することが有効です。 リモートの接続とセッションを終了するには、CLOSE DATABASE LINK句を指定したALTER SESSION文を使用します。たとえば、次のトランザクションを発行した場合を考えます。

SELECT * FROM emp@sales;
COMMIT;

次の文は、salesデータベース・リンクが指すリモート・データベース内のセッションを終了します。

ALTER SESSION CLOSE DATABASE LINK sales;

ユーザー・セッションのデータベース・リンク接続をクローズするには、ALTER SESSIONシステム権限が必要です。

注意:
データベース・リンクをクローズする前に、まずそのリンクを使用しているカーソルをすべてクローズし、次にそのリンクを使用している現行トランザクションがあればそのトランザクションを終了してください。

関連項目:
ALTER SESSION文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

分散システムの参照整合性の維持

たとえば、整合性制約違反など、分散型の文の一部が失敗した場合、データベースはエラー番号ORA-02055を返します。以降の文またはプロシージャ・コールは、ROLLBACKまたはROLLBACK TO SAVEPOINTが発行されるまで、エラー番号ORA-02067を返します。

返されたエラー・メッセージをすべてチェックするようにアプリケーションを設計し、分散更新の一部が失敗したことを示すエラー・メッセージがないかを確認します。失敗を検出した場合は、トランザクション全体をロールバックしてからアプリケーションの処理を進めるようにしてください。

データベースでは、宣言参照整合性の制約を分散システムのノード間で定義することは許可されていません。つまり、1つの表での宣言参照整合性の制約では、リモート表の主キーまたは一意キーを参照する外部キーを指定することはできません。ただし、トリガーを使用してノード間の親子の表関係を維持することは可能です。

トリガーを使用して分散データベースの複数のノードにまたがる参照整合性を定義する場合、ネットワーク障害により、親表へのアクセスだけでなく子表へのアクセスも制限される可能性があることに注意してください。たとえば、子表がsalesデータベースに存在し、親表がhqデータベースに存在すると想定します。2つのデータベース間のネットワーク接続に障害が発生すると、参照整合性トリガーがhqデータベース内の親表へアクセスする必要があるため、子表に対するDML文が処理(子表に行を挿入したり、子表の外部キーの値を更新するような処理)を進めることができない場合があります。

関連項目:
トリガーを使用した参照整合性の規定の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

分散問合せのチューニング

ローカルのOracle Databaseサーバーは、分散問合せを対応する数のリモート問合せに分割し、次に、その問合せを実行するためにリモート・ノードに送信します。リモート・ノードは問合せを実行し、その結果をローカル・ノードに返します。その後、ローカル・ノードは必要な後処理を行い、ユーザーまたはアプリケーションに結果を戻します。

問合せの処理が最適化されるようにアプリケーションを設計するには、いくつかの方法があります。この項の内容は次のとおりです。

- 連結インライン・ビューの使用

- コストベース最適化の使用

- ヒントの使用

- 実行計画の分析

注意:
SQLプロファイル、SQL計画ベースライン、SQLパッチおよび格納されたアウトラインなどのSQL管理オブジェクトは、問合せでデータベース・リンクを使用してリモート表を参照する場合に、想定したとおりに動作しないことがあります。たとえば、SQL計画管理で、問合せにSQL計画ベースラインを使用する場合、リモートで実行される問合せの部分は、SQL計画ベースラインが作成されたときとは違う計画を使用することがあります。

連結インライン・ビューの使用

分散問合せを最適化する最も効果的な方法は、リモート・データベースへのアクセスをできるだけ抑えて必要なデータのみを取得することです。

たとえば、分散問合せで5つのリモート表を2つの異なるリモート・データベースから参照し、複合フィルタ(WHERE r1.salary + r2.salary > 50000など)を使用するとします。この場合、リモート・データベースへのアクセスを1回にし、フィルタをリモート・サイトで適用するように問合せをリライトすることで、問合せのパフォーマンスを改善できます。このリライトにより、問合せを実行するサイトに転送されるデータの量が少なくなります。

リモート・データベースへのアクセスが1回になるように問合せをリライトするには、連結インライン・ビューを使用します。用語の定義は次のとおりです。

- 連結
同じデータベースにある2つ以上の表。

- インライン・ビュー
親のSELECT文の表に置き換えられるSELECT文。次のカッコで囲まれた部分の埋込みSELECT文がインライン・ビューの例です。

SELECT e.empno,e.ename,d.deptno,d.dname
FROM (SELECT empno, ename from
emp@orc1.world) e, dept d;

- 連結インライン・ビュー
1つのデータベースのみの複数の表からデータを選択するインライン・ビュー。これを使用すると、リモート・データベースにアクセスする時間が短縮されるため、分散問合せのパフォーマンスが向上します。

連結インライン・ビューを使用して分散問合せを構成し、分散問合せのパフォーマンスを改善することをお薦めします。Oracle Databaseのコストベース最適化を使用すると、分散問合せの多くが透過的にリライトされ、連結インライン・ビューによるパフォーマンスの向上が得られます。

コストベース最適化の使用

連結インライン・ビューによるクエリー・リライトに加えて、コストベース最適化の方法を使用すると、参照先の表から収集される統計とオプティマイザが実行する計算に従って分散問合せが最適化されます。

たとえば、コストベースの最適化によって次の問合せを分析します。この例では、表統計が使用できると仮定しています。CREATE TABLE文内の問合せが分析されます。

CREATE TABLE AS (
SELECT l.a, l.b, r1.c, r1.d, r1.e, r2.b, r2.c
FROM local l, remote1 r1, remote2 r2
WHERE l.c = r.c
AND r1.c = r2.c
AND r.e > 300
);

この文は、次のようにリライトされます。

CREATE TABLE AS (
SELECT l.a, l.b, v.c, v.d, v.e
FROM (
SELECT r1.c, r1.d, r1.e, r2.b, r2.c
FROM remote1 r1, remote2 r2
WHERE r1.c = r2.c
AND r1.e > 300
) v, local l
WHERE l.c = r1.c
);

インライン・ビューに別名vが割り当てられ、前述のSELECT文で表としてこの別名を参照できます。連結インライン・ビューを作成すると、リモート・サイトで実行される問合せの量が減少するため、コストのかかるネットワーク通信量を削減できます。

コストベース最適化の動作の仕組み

オプティマイザの主なタスクは、連結インライン・ビューを使用するように分散問合せをリライトすることです。この最適化は、次の3つの手順で実行されます。

1. マージ可能なビューがすべてマージされます。

2. オプティマイザが連結問合せブロックのテストを実行します。

3. オプティマイザが連結インライン・ビューを使用して問合せをリライトします。

問合せがリライトされた後、その問合せが実行され、データ・セットがユーザーに返されます。

コストベース最適化をユーザーに対して透過的に実行する場合は、複数の分散問合せのパフォーマンスを改善することはできません。特に、次のものが分散問合せに含まれている場合、コストベース最適化は効果がありません。

- 集計

- 副問合せ

- 複合SQL

これらの要素が1つでも分散問合せに含まれている場合は、問合せの修正方法と、分散問合せのパフォーマンスを改善するためのヒントの使用について、「ヒントの使用」を参照してください。

コストベース最適化の設定

分散問合せのパフォーマンス改善のためにコストベース最適化を使用するようにシステムを設定すると、その処理がユーザーに対して透過的になります。つまり、問合せの発行時に自動的に最適化が実行されます。

コストベースの最適化を利用するようにシステムを設定するには、次のタスクを完了する必要があります。

- 環境の設定

- 表の分析

環境の設定

OPTIMIZER_MODE初期化パラメータを設定し、インスタンスに最適化アプローチを選択するためのデフォルト動作を設定します。このパラメータは次の方法で設定できます。

- 初期化パラメータ・ファイルのOPTIMIZER_MODEパラメータを変更します。

- ALTER SESSION文を発行してセッション・レベルで設定します。

関連項目:
パラメータ・ファイルのOPTIMIZER_MODE初期化パラメータの設定と、コストベース最適化方法を使用するためのシステムの構成の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

表の分析

コストベース最適化で分散問合せのための最も効率的なパスが選択されるようにするには、問合せに関係する表の正確な統計を提供する必要があります。この操作には、DBMS_STATSパッケージを使用します。

注意:
DBMS_STATSプロシージャを実行するには、表に対してローカルに接続する必要があります。
まずリモート・サイトに接続し、次にDBMS_STATSプロシージャを実行する必要があります。

次のDBMS_STATSプロシージャを使用すると、特定のクラスのオプティマイザ統計を収集できます。

- GATHER_INDEX_STATS

- GATHER_TABLE_STATS

- GATHER_SCHEMA_STATS

- GATHER_DATABASE_STATS

たとえば、分散トランザクションが日常的にscott.dept表にアクセスするとします。コストベースのオプティマイザが引き続き最適な方法を確実に選択するように、次の文を実行します。

BEGIN
DBMS_STATS.GATHER_TABLE_STATS ('scott', 'dept');
END;

関連項目:

- 統計生成の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- DBMS_STATSパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ヒントの使用

文が十分に最適化されない場合は、ヒントを使用してコストベース最適化の機能を拡張できます。特に、独自の問合せを記述して連結インライン・ビューを使用する場合は、分散問合せがリライトされないようにコストベース・オプティマイザに指示を与えます。

また、データベース環境に関する特別な情報(統計、負荷、ネットワークおよびCPUの制限事項、分散問合せなど)を持っている場合は、ヒントを指定してコストベース最適化を適切に誘導できます。たとえば、データベース環境の情報に基づく連結インライン・ビューを使用して、独自に最適化した問合せを記述した場合は、NO_MERGEヒントを指定することにより、オプティマイザが問合せをリライトしないようにできます。

この手法は、分散問合せに集計、副問合せまたは複合SQLが含まれている場合に特に役立ちます。このタイプの分散問合せはオプティマイザによってリライトできないため、NO_MERGEを指定して、オプティマイザが「コストベース最適化の動作の仕組み」で説明されている手順を省略するように指示します。

DRIVING_SITEヒントを使用すると、リモート・サイトを問合せ実行サイトとして機能するように定義できます。この方法では、問合せがリモート・サイトで実行され、データがローカル・サイトに返されます。リモート・サイトにデータの大部分が格納されているときは、このヒントが特に役立ちます。

関連項目:
ヒントの使用の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

NO_MERGEヒントの使用

NO_MERGEヒントにより、データベースで非連結となる可能性があるSQL文とインライン・ビューがマージされないようにします(「ヒントの使用」を参照)。このヒントはSELECT文に埋め込み、インライン・ビューを引数として使用するSELECT文の先頭、またはインライン・ビューを定義する問合せブロック内のいずれかに記述できます。

/* with argument */

SELECT /*+NO_MERGE(v)*/ t1.x, v.avg_y
FROM t1, (SELECT x, AVG(y) AS avg_y FROM t2 GROUP BY x) v,
WHERE t1.x = v.x AND t1.y = 1;

/* in query block */

SELECT t1.x, v.avg_y
FROM t1, (SELECT /*+NO_MERGE*/ x, AVG(y) AS avg_y FROM t2 GROUP BY x) v,
WHERE t1.x = v.x AND t1.y = 1;

通常、このヒントは、データベース環境の情報に基づいて最適化した問合せを作成したときに使用します。

DRIVING_SITEヒントの使用

DRIVING_SITEヒントを使用すると、問合せが実行されるサイトを指定できます。コストベース最適化によって実行が行われる場所を決定することをお薦めしますが、オプティマイザを無効にする場合は、手動で実行サイトを指定できます。

DRIVING_SITEヒントを使用したSELECT文の例を次に示します。

SELECT /*+DRIVING_SITE(dept)*/ * FROM emp, dept@remote.com
WHERE emp.deptno = dept.deptno;

実行計画の分析

分散問合せのチューニングの際に重要なこととして、実行計画の分析があります。分析結果から得られるフィードバックは、データベースのテストと検証を行う上で重要な要素になります。計画を比較するときは、検証が特に重要になります。たとえば、コストベースの最適化によって分散問合せを最適化する実行計画を、ヒント、連結インライン・ビューおよびその他の方法を使用して問合せを手動で最適化する計画と比較します。

関連項目:
実行計画、EXPLAIN PLAN文およびその結果の解釈方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

実行計画の生成

データベース内に実行計画を格納する場所を準備すると、指定した問合せの計画を表示するための準備が完了します。SQL文を直接実行するかわりに、EXPLAIN PLAN FOR句に文を追加します。たとえば、次のような文を実行できます。

EXPLAIN PLAN FOR
SELECT d.dname
FROM dept d
WHERE d.deptno
IN (SELECT deptno
FROM emp@orc2.world
GROUP BY deptno
HAVING COUNT (deptno) >3
)
/

実行計画の表示

前述のSQL文を実行すると、実行計画がPLAN_TABLEに一時的に格納されます。実行計画の結果を表示するには、次のスクリプトを実行します。

@utlxpls.sql

注意:
utlxpls.sqlファイルは$ORACLE_HOME/rdbms/adminディレクトリにあります。

utlxpls.sqlスクリプトを実行すると、指定したSELECT文の実行計画が表示されます。結果は、次のように書式化されます。

Plan Table
-------------------------------------------------------------------------------
| Operation                 |  Name    |  Rows | Bytes|  Cost  | Pstart| Pstop |
-------------------------------------------------------------------------------
| SELECT STATEMENT          |          |       |      |        |       |      |
|  NESTED LOOPS             |          |       |      |        |       |      |
|   VIEW                    |          |       |      |        |       |      |
|    REMOTE                 |          |       |      |        |       |      |
|   TABLE ACCESS BY INDEX RO|DEPT      |       |      |        |       |      |
|    INDEX UNIQUE SCAN      |PK_DEPT   |       |      |        |       |      |
-------------------------------------------------------------------------------

独自の連結インライン・ビューを記述するか、またはヒントを使用して、分散問合せを手動で最適化しようとする場合は、手動最適化の前および後に実行計画を生成するのが最適です。これら両方の実行計画を使用することで、手動最適化の効果を比較し、必要に応じて変更を加え、分散問合せのパフォーマンスを改善できます。

リモート・サイトで実行されるSQL文を表示するには、次のSELECT文を実行します。

SELECT OTHER
FROM PLAN_TABLE
WHERE operation = 'REMOTE';

出力例を次に示します。

SELECT DISTINCT "A1"."DEPTNO" FROM "EMP" "A1"
GROUP BY "A1"."DEPTNO" HAVING COUNT("A1"."DEPTNO")>3

注意:
OTHER列の内容全体がうまく表示されない場合は、次のSQL*Plusコマンドを実行してください。

SET LONG 9999999

リモート・プロシージャのエラー処理

データベースがプロシージャをローカルまたはリモートの位置で実行するときには、次の4種類の例外が発生する可能性があります。

- PL/SQLのユーザー定義例外。この例外は、EXCEPTIONキーワードを使用して宣言する必要があります。

- PL/SQLの事前定義例外。NO_DATA_FOUNDキーワードなど。

- SQLエラー。ORA-00900やORA-02015など。

- RAISE_APPLICATION_ERROR()プロシージャを使用して生成されるアプリケーション例外。

ローカル・プロシージャを使用するときは、次のような例外ハンドラを記述して、これらのメッセージをトラップできます。

BEGIN
...
EXCEPTION
WHEN ZERO_DIVIDE THEN
/* ... handle the exception */
END;

WHEN句には例外名が必要です。RAISE_APPLICATION_ERRORで生成された例外など、例外が名前を持っていない場合は、PRAGMA_EXCEPTION_INITを使用して名前を割り当てることができます。次に例を示します。

DECLARE
null_salary EXCEPTION;
PRAGMA EXCEPTION_INIT(null_salary, -20101);
BEGIN
...
RAISE_APPLICATION_ERROR(-20101, 'salary is missing');
...
EXCEPTION
WHEN null_salary THEN
...
END;

リモート・プロシージャのコール中に、例外の処理をローカル・プロシージャの例外ハンドラで行うことができます。リモート・プロシージャはローカルのコール側プロシージャにエラー番号を返す必要があり、返すと前述の例に示すようにコール側プロシージャで例外が処理されます。PL/SQLのユーザー定義例外では、常に、ローカル・プロシージャにORA-06510が返されることに注意してください。

したがって、2つの異なるユーザー定義例外をエラー番号で区別することはできません。その他のリモート例外はすべて、ローカル例外と同じ方法で処理できます。

関連項目:
PL/SQLプロシージャの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

34 分散トランザクションの概念

この章の内容は、次のとおりです。

- 分散トランザクションの概要

- 分散トランザクションのセッション・ツリー

- 2フェーズ・コミット・メカニズム

- インダウト・トランザクション

- 分散トランザクション処理: 事例

分散トランザクションの概要

分散トランザクションは1つ以上の文からなり、それらが個別に、またはグループとして、分散データベースの複数ノードのデータを更新します。たとえば、図34-1に示すデータベース構成を考えます。

図34-1 分散システム

scottによって実行される次の分散トランザクションは、ローカルのsalesデータベース、リモートのhqデータベース、およびリモートのmaintデータベースを更新します。

UPDATE scott.dept@hq.us.example.com
SET loc = 'REDWOOD SHORES'
WHERE deptno = 10;
UPDATE scott.emp
SET deptno = 11
WHERE deptno = 10;
UPDATE scott.bldg@maint.us.example.com
SET room = 1225
WHERE room = 1163;
COMMIT;

注意:
トランザクションのすべての文が1つのリモート・ノードのみを参照している場合、そのトランザクションは分散トランザクションではなくリモート・トランザクションです。

分散トランザクションでは、次の2種類の操作が許可されます。

- DMLおよびDDLトランザクション

- トランザクション制御文

DMLおよびDDLトランザクション

分散トランザクションでサポートされているデータ操作言語(DML)およびデータ定義言語(DDL)操作は、次のとおりです。

- CREATE TABLE AS SELECT

- DELETE

- INSERT(デフォルトおよびダイレクト・ロード)

- UPDATE

- LOCK TABLE

- SELECT

- SELECT FOR UPDATE

DML文およびDDL文はパラレルに実行でき、ダイレクト・ロードINSERT文はシリアルに実行できます。ただし、次の制限に注意してください。

- リモート操作はすべてSELECT文である必要があります。

- これらの文は、別の分散トランザクション内の句であってはいけません。

- INSERT、UPDATEまたはDELETE文のtable_expression_clauseで参照される表がリモートの場合、実行はパラレルではなくシリアルになります。

- パラレルDML/DDLまたはダイレクト・ロードINSERTの発行後にリモート操作を実行することはできません。

- XAまたはOCIを使用してトランザクションを開始した場合、そのトランザクションはシリアルに実行されます。

- パラレル操作の実行元であるトランザクションで、ループバック操作を実行することはできません。たとえば、実際はローカル・オブジェクトのシノニムであるリモート・オブジェクトを参照することはできません。

- トランザクションでSELECT以外の分散操作を実行する場合、DMLはパラレル化されません。

トランザクション制御文

サポートされているトランザクション制御文は、次のとおりです。

- COMMIT

- ROLLBACK

- SAVEPOINT

関連項目:
これらのSQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

分散トランザクションのセッション・ツリー

分散トランザクションで文が発行されると、データベースはトランザクションに参加しているすべてのノードのセッション・ツリーを定義します。セッション・ツリーとは、セッション間の関係とセッションのロールを表す階層モデルです。セッション・ツリーの例を図34-2に示します。

図34-2 セッション・ツリーの例

分散トランザクションのセッション・ツリーに参加しているすべてのノードは、次に示すロールを1つ以上持ちます。

ロール

説明

クライアント

異なるノードに属するデータベース内の情報を参照するノード。

データベース・サーバー

別のノードからの情報の要求を受け取るノード。

グローバル・コーディネータ

分散トランザクションの実行元ノード。

ローカル・コーディネータ

他のノードのデータを強制的に参照して、自身のトランザクション部分を完了するノード。

コミット・ポイント・サイト

グローバル・コーディネータの指示に従ってトランザクションをコミットまたはロールバックするノード。

分散トランザクションのノードが果たすロールは、次の条件によって決まります。

- トランザクションがローカルとリモートのどちらであるか。

- ノードのコミット・ポイント強度(「コミット・ポイント・サイト」を参照)。

- 要求されたすべてのデータがノードで使用可能か、またはトランザクションを完了するために他のノードを参照する必要があるか。

- ノードが読取り専用かどうか。

クライアント

情報を別のノードのデータベースから参照するとき、ノードはクライアントとして機能します。参照先のノードはデータベース・サーバーです。図34-2のノードsalesは、warehouseデータベースおよびfinanceデータベースが稼働しているノードのクライアントです。

データベース・サーバー

データベース・サーバーは、クライアントがデータを要求する要求先データベースが稼働しているノードです。

図34-2では、salesノードのアプリケーションは、warehouseノードおよびfinanceノードのデータにアクセスする分散トランザクションを開始します。したがって、sales.example.comはクライアント・ノードのロールを持ち、warehouseおよびfinanceはどちらもデータベース・サーバーのロールを持ちます。この例では、アプリケーションでsalesデータベース内のデータも変更されているため、salesはデータベース・サーバーおよびクライアントです。

ローカル・コーディネータ

分散トランザクションにおいて自身のトランザクション部分を完了するために別のノードのデータを参照する必要があるノードは、ローカル・コーディネータと呼ばれます。図34-2で、salesは、直接参照しているノードwarehouseおよびfinanceを調整しているため、ローカル・コーディネータです。ノードsalesもトランザクションに関係しているすべてのノードを調整しているため、グローバル・コーディネータになります。

ローカル・コーディネータは、自身が直接やり取りするノードの間で次のようにトランザクションを調整する役目を果たします。

- これらのノード間でトランザクションのステータス情報を受け渡します。

- これらのノードに問合せを渡します。

- これらのノードから問合せを受け取り、他のノードに渡します。

- 問合せの結果を開始元のノードに返します。

グローバル・コーディネータ

分散トランザクションの実行元であるノードのことを、グローバル・コーディネータと呼びます。分散トランザクションを発行するデータベース・アプリケーションは、グローバル・コーディネータとして機能しているノードに直接接続します。たとえば、図34-2では、ノードsalesで発行されたトランザクションは、データベース・サーバーwarehouseおよびfinanceの情報を参照します。したがって、sales.example.comは、この分散トランザクションのグローバル・コーディネータになります。

グローバル・コーディネータは、セッション・ツリーの親またはルートになります。グローバル・コーディネータは、分散トランザクション処理中に次の操作を実行します。

- 分散トランザクションのすべてのSQL文やリモート・プロシージャ・コールなどを参照先のノードに直接送り、それによってセッション・ツリーを構成します。

- コミット・ポイント・サイト以外のすべての直接参照先ノードに対して、トランザクションの準備をするように指示します。

- すべてのノードの準備が正常に完了した場合に、トランザクションのグローバル・コミットを開始するようにコミット・ポイント・サイトに対して指示します。

- ノードから異常終了の応答があった場合に、トランザクションのグローバル・ロールバックを開始するようにすべてのノードに対して指示します。

コミット・ポイント・サイト

コミット・ポイント・サイトの役割は、グローバル・コーディネータの指示に従ってコミットまたはロールバックの操作を開始することです。システム管理者は、すべてのノードにコミット・ポイント強度を割り当てることで、セッション・ツリー内のノードの1つをコミット・ポイント・サイトとして必ず指定します。コミット・ポイント・サイトには、最も重要なデータを格納するノードを選択してください。

図34-3は、salesがコミット・ポイント・サイトとして機能している分散システムの例です。

図34-3 コミット・ポイント・サイト

コミット・ポイント・サイトは、分散トランザクションに関係する他のすべてのノードと次の点で区別されます。

- コミット・ポイント・サイトが準備完了状態に入ることはありません。そのため、コミット・ポイント・サイトに最も重要なデータが格納されている場合は、たとえ障害が起きたとしても、データがインダウトのままになることはありません。障害が発生すると、障害を起こしたノードは準備完了状態のままになり、インダウト・トランザクションが解決されるまで必要なロックが保持されます。

- コミット・ポイント・サイトは、トランザクションに関係している他のノードよりも先にコミットします。実際は、コミット・ポイント・サイトでの分散トランザクションの結果によって、すべてのノードでのトランザクションがコミットされるかロールバックされるかが決まり、他のノードはコミット・ポイント・サイトの指示に従います。グローバル・コーディネータは、すべてのノードでコミット・ポイント・サイトと同様にトランザクションが完了することを保証します。

分散トランザクションのコミットの仕組み

分散トランザクションは、コミット・ポイント以外のすべてのサイトで準備が完了した後、コミットされたとみなされますが、実際には、トランザクションはコミット・ポイント・サイトで先にコミットされています。コミット・ポイント・サイトのREDOログは、このノードで分散トランザクションがコミットされるとただちに更新されます。

コミット・ポイント・ログにはコミットの記録があります。そのため、たとえ参加中のノードの一部がまだ準備完了状態であり、それらのノードで実際にトランザクションがコミットされていない場合であっても、トランザクションはコミットされたとみなされます。同様に、コミット・ポイント・サイトでコミットが記録されていない場合は、分散トランザクションはコミットされていないとみなされます。

コミット・ポイント強度

データベース・サーバーには、必ずコミット・ポイント強度を割り当てる必要があります。データベース・サーバーが分散トランザクション内で参照される場合、そのコミット・ポイント強度の値によって、2フェーズ・コミットにおける役割が決まります。具体的には、このコミット・ポイント強度によって、どのノードが分散トランザクションのコミット・ポイント・サイトになり、他のすべてのノードより前にコミットするかが決まります。 この値を指定するには、初期化パラメータCOMMIT_POINT_STRENGTHを使用します。ここでは、データベースがコミット・ポイント・サイトを決定する仕組みについて説明します。

準備フェーズの冒頭で決定されるコミット・ポイント・サイトは、トランザクションに参加しているノードの中からのみ選択されます。次に示す一連のイベントが発生します。

1. データベースは、グローバル・コーディネータが直接参照しているノードの中で、最も高いコミット・ポイント強度を持つノードをコミット・ポイント・サイトとして選択します。

2. 最初に選択されたノードは、このトランザクションの情報を取得する必要のあるノードの中で、自身よりも高いコミット・ポイント強度を持っているノードがないかを判断します。

3. トランザクションで直接参照しているノードの中で最も高いコミット・ポイント強度を持つノードか、またはそのノードのサーバーの中でより高いコミット・ポイント強度を持つもののどちらかが、コミット・ポイント・サイトになります。

4. 最終的なコミット・ポイント・サイトが決定した後、グローバル・コーディネータは、トランザクションに参加しているすべてのノードに準備応答を送ります。

図34-4は、各ノードのコミット・ポイント強度(カッコ内の値)を示したセッション・ツリーの例です。また、コミット・ポイント・サイトとして選択されたノードも示しています。

図34-4 コミット・ポイント強度とコミット・ポイント・サイトの決定

コミット・ポイント・サイトを決定するときは、次の条件が適用されます。

- 読取り専用ノードは、コミット・ポイント・サイトにはなれません。

- グローバル・コーディネータが直接参照している複数のノードが同じコミット・ポイント強度を持っている場合、データベースはそれらのうちの1つをコミット・ポイント・サイトとして指定します。

- 分散トランザクションがロールバックで終了する場合は、準備フェーズとコミット・フェーズは不要です。したがって、データベースはコミット・ポイント・サイトを決定しません。そのかわりに、グローバル・コーディネータはROLLBACK文をすべてのノードに送り、分散トランザクションの処理を終了します。

図34-4のように、コミット・ポイント・サイトとグローバル・コーディネータがセッション・ツリーの異なるノードになることもあります。各ノードのコミット・ポイント強度は、最初に接続が確立されたときにコーディネータに渡されます。コーディネータは、2フェーズ・コミット時のコミット・ポイント・サイトを効率的に選択するために、自身が直接やり取りしている各ノードのコミット・ポイント強度を保持しています。そのため、コミットが発生するたびにコーディネータとノード間でコミット・ポイント強度を交換する必要がありません。

関連項目:

- ノードのコミット・ポイント強度の設定方法の詳細は、「ノードのコミット・ポイント強度の指定」を参照してください。

- 初期化パラメータCOMMIT_POINT_STRENGTHの詳細は、『Oracle Databaseリファレンス』を参照してください。

2フェーズ・コミット・メカニズム

ローカル・データベースのトランザクションとは異なり、分散トランザクションには複数のデータベースでのデータの変更が伴います。そのため、データベースは、トランザクションの変更のコミットまたはロールバックを自己完結単位として調整する必要があり、分散トランザクションの処理はより複雑になります。言い換えれば、トランザクション全体がコミットするか、またはトランザクション全体がロールバックするかのどちらかの結果になります。

データベースは、2フェーズ・コミット・メカニズムを使用することで、分散トランザクションにおけるデータの整合性を保証します。準備フェーズでは、トランザクション内の開始ノードが他の参加ノードに対して、トランザクションをコミットまたはロールバックすることを確約するように要求します。コミット・フェーズでは、開始ノードがすべての参加ノードに対して、トランザクションをコミットするように要求します。この結果が達成できない場合、すべてのノードはロールバックするように要求されます。

分散トランザクションに参加しているすべてのノードは、必ず同じ動作を実行します。つまり、ノードすべてがトランザクションをコミットするか、またはノードすべてがトランザクションをロールバックします。データベースは、分散トランザクションのコミットまたはロールバックを自動的に制御および監視しており、2フェーズ・コミット・メカニズムを使用してグローバル・データベース(トランザクションに参加しているデータベースの集まり)の整合性を維持します。このメカニズムは完全に透過的であり、ユーザーやアプリケーション開発者の側でプログラミングを行う必要はまったくありません。

コミット・メカニズムは、次の各フェーズで構成されています。データベースは、ユーザーが分散トランザクションをコミットすると、必ずこれらのフェーズを自動的に実行します。

フェーズ

説明

準備フェーズ

グローバル・コーディネータと呼ばれる開始ノードは、コミット・ポイント・サイト以外の参加ノードに対して、たとえ障害が起きた場合でもトランザクションをコミットまたはロールバックすることを確約するように要求します。準備ができないノードがある場合、トランザクションはロールバックされます。

コミット・フェーズ

すべての参加ノードが準備完了の応答をコーディネータに伝えると、コーディネータは、コミット・ポイント・サイトにコミットを要求します。コミット・ポイント・サイトのコミット後、コーディネータは、トランザクションをコミットするように他のすべてのノードに要求します。

情報消去フェーズ

グローバル・コーディネータは、トランザクションに関する情報を消去します。

この項の内容は次のとおりです。

- 準備フェーズ

- コミット・フェーズ

- 情報消去フェーズ

準備フェーズ

準備フェーズは、分散トランザクションのコミットにおける1番目のフェーズです。このフェーズでは、データベースがトランザクションを実際にコミットまたはロールバックすることはありません。ここでは、分散トランザクションで参照されているすべてのノード(「コミット・ポイント・サイト」で説明されているコミット・ポイント・サイトを除く)がコミットを準備するように指示されます。ノードは、準備を完了するために次の処理を実行します。

- REDOログの情報を記録し、それ以降障害が発生してもトランザクションをコミットまたはロールバックできるようにします。

- 変更済の表に分散ロックを設定し、読取りを防ぎます。

各ノードは、コミットの準備が完了したという応答をグローバル・コーディネータに伝えることによって、その後トランザクションをコミットまたはロールバックすることを確約しますが、トランザクションをコミットまたはロールバックするという決定を各ノードが一方的に下すわけではありません。この確約の意味は、この時点でインスタンス障害が発生した場合、ノードはオンライン・ログのREDOレコードを使用してデータベースをリカバリし、準備フェーズに戻すことができるということです。

注意:
ノードの準備完了後に発行した問合せは、すべてのフェーズが完了するまで、関連するロック済データにアクセスできません。この時間は、障害が発生しないかぎり問題にはなりません(「インダウト・トランザクションの処理方法の決定」を参照)。

準備フェーズでの応答のタイプ

準備を指示されたノードは、次の方法で応答できます。

応答

意味

Prepared

ノードのデータの変更が分散トランザクション内の文によって完了しており、ノードの準備が正常に完了しています。

読取り専用

ノードで変更されるデータがない(問合せのみ)か、または変更できないので、準備は不要です。

異常終了

ノードが正常に準備できません。

準備応答

ノードの準備が正常に完了すると、ノードは準備完了メッセージを発行します。このメッセージは、ノードの変更レコードがオンライン・ログに格納されており、ノードでコミットまたはロールバックのどちらかを実行できる準備が整っていることを示します。また、このメッセージによって、トランザクションに対して保持されているロックが障害発生時にも残ることが保証されます。

読取り専用応答

ノードが準備を要求されたときに、データベースにアクセスするSQL文がノードのデータを変更しない場合、ノードは読取り専用メッセージで応答します。このメッセージは、ノードがコミット・フェーズに参加しないことを示します。

分散トランザクションの全部または一部が読取り専用になるケースとして、次の3つがあります。

ケース

条件

結果

一部読取り専用

次のいずれかが発生した場合

- 1つ以上のノードで問合せのみが発行された。

- データが変更されない。

- トリガーの起動または制約違反のために変更がロールバックされた。

読取り専用ノードは、準備を要求されたときに自身のステータスを認識します。読取り専用ノードは、読取り専用応答をローカル・コーディネータに伝えます。この結果、データベースは読取り専用ノードを以降の処理から除外するので、コミット・フェーズがより高速に完了します。

準備フェーズでの完全な読取り専用

次のすべてが発生した場合

- データが変更されない。

- トランザクションがSET TRANSACTION READ ONLY文で開始されていない。

準備フェーズ時にすべてのノードが読取り専用であることを認識するので、コミット・フェーズは不要になります。グローバル・コーディネータにはすべてのノードが読取り専用かどうかわからないため、グローバル・コーディネータは引き続き準備フェーズを実行する必要があります。

2フェーズ・コミットなしの完全な読取り専用

次のすべてが発生した場合

- データが変更されない。

- トランザクションがSET TRANSACTION READ ONLY文で開始されている。

このトランザクションでは問合せのみが許可されるため、グローバル・コーディネータは、2フェーズ・コミットを実行する必要がありません。また、システム変更番号(SCN)の調整がノード間でグローバルに行われるため、他のトランザクションによる変更によってグローバル・トランザクション・レベルの読込み一貫性が損なわれることはありません。このトランザクションでは、UNDOセグメントは使用されません。

分散トランザクションが読取り専用に設定されている場合、そのトランザクションでUNDOセグメントは使用されません。多数のユーザーがデータベースに接続していて、ユーザーのトランザクションがREAD ONLYに設定されていない場合は、それらのトランザクションが問合せを実行するのみであっても、UNDO領域が割り当てられます。

異常終了時のエラー

ノードは、正常に準備できないときに次の処理を実行します。

1. トランザクションが現在保持しているリソースを解放し、トランザクションのローカル部分をロールバックします。

2. 分散トランザクション内で自身を参照しているノードに対し、異常終了メッセージで応答します。

これらの処理は、分散トランザクションに関係している他のノードに伝播します。これにより、他のノードはトランザクションをロールバックできるので、グローバル・データベースのデータの整合性が保証されます。この応答によって、「トランザクションに関係しているすべてのノードが同じ物理時間でトランザクションをすべてコミットするか、またはすべてロールバックする」という分散トランザクションの基本原則が守られます。

準備フェーズの手順

準備フェーズを完了するために、コミット・ポイント・サイトを除く各ノードは次の手順を実行します。

1. ノードは、自身の子(以降参照する各ノード)に対して、コミットの準備をするように要求します。

2. ノードは、トランザクションによって自分自身のデータまたは子のデータが変更されるかどうかをチェックします。データが変更されない場合、ノードは残りの手順を省略し、読取り専用応答を返します(「読取り専用応答」を参照)。

3. データが変更される場合、ノードはトランザクションのコミットに必要なリソースを割り当てます。

4. ノードは、トランザクションによる変更に対応するREDOレコードをREDOログに保存します。

5. ノードは、トランザクションに対して保持されているロックが障害発生時にも残ることを保証します。

6. ノードは、準備レスポンスを開始ノードに伝えます(「準備レスポンス」を参照)。あるいは、自身またはその子のいずれかが準備の試行に失敗した場合は、異常終了応答を伝えます(「異常終了時のエラー」を参照)。

これらの処理によって、ノードが後で自身のトランザクションをコミットまたはロールバックできることが保証されます。この後、準備完了ノードは、グローバル・コーディネータからCOMMITまたはROLLBACK要求を受け取るまで待機します。

各ノードの準備が完了した後、分散トランザクションはインダウトと呼ばれる状態になります(「インダウト・トランザクション」を参照)。すべての変更がコミットまたはロールバックされるまで、インダウト状態のままです。

コミット・フェーズ

コミット・フェーズは、分散トランザクションのコミットにおける2番目のフェーズです。このフェーズになる前に、分散トランザクションで参照されている、コミット・ポイント・サイト以外のすべてのノードが準備完了していること、つまり、トランザクションのコミットに必要なリソースを確保していることが保証されます。

コミット・フェーズの手順

コミット・フェーズは次の手順で構成されています。

1. グローバル・コーディネータは、コミット・ポイント・サイトにコミットを指示します。

2. コミット・ポイント・サイトは、コミットを実行します。

3. コミット・ポイント・サイトは、コミットが完了したことをグローバル・コーディネータに伝えます。

4. グローバル・コーディネータおよびローカル・コーディネータは、すべてのノードに対してトランザクションをコミットするように指示するメッセージを送ります。

5. 各ノードで、データベースは分散トランザクションのローカル部分をコミットし、ロックを解放します。

6. 各ノードで、データベースは、トランザクションのコミットが完了したことを示す追加のREDOエントリをローカルREDOログに記録します。

7. 各参加ノードは、自身のコミットが完了したことをグローバル・コーディネータに伝えます。

コミット・フェーズが完了するときは、分散システムの全ノードのデータについて一貫性が保たれています。

グローバル・データベースの一貫性の保証

コミットされた各トランザクションには、そのトランザクション内部のSQL文によって行われた変更を一意に識別するためのSCNが対応付けられます。SCNは、データベースのコミット済バージョンを一意に識別する内部的なタイムスタンプの役割を持ちます。

分散システムでは、次の処理がすべて発生したときに、通信中のノードのSCNが調整されます。

- 1つ以上のデータベース・リンクによって表されるパスを使用した接続の確立

- 分散SQL文の実行

- 分散トランザクションのコミット

特に、分散システムのノード間でSCNが調整されることにより、文とトランザクションの両方のレベルでグローバルな読込み一貫性が保証されるという利点があります。必要であれば、グローバルな時間ベースのリカバリを実行することもできます。

準備フェーズ時に、データベースは、トランザクションに関係しているすべてのノードで最も高いSCNを判断します。次に、コミット・ポイント・サイトにおいて最も高いSCNでトランザクションをコミットします。さらに、すべての準備完了ノードに対して、コミットの指示とともにコミットSCNを送ります。

関連項目:
読込み一貫性におけるタイム・ラグ問題の管理の詳細は、「読込み一貫性の管理」を参照してください。

情報消去フェーズ

参加ノードが自身のコミットの完了をコミット・ポイント・サイトに通知した後、コミット・ポイント・サイトは、トランザクションに関する情報を消去できます。次の手順が発生します。

1. すべてのノードのコミットが完了したことをグローバル・コーディネータから通知された後、コミット・ポイント・サイトは、このトランザクションに関するステータス情報を消去します。

2. コミット・ポイント・サイトは、ステータス情報を消去したことをグローバル・コーディネータに伝えます。

3. グローバル・コーディネータは、トランザクションに関する自分自身の情報を消去します。

インダウト・トランザクション

2フェーズ・コミット・メカニズムは、すべてのノードがコミットされるかまたはロールバックを一斉に実行することを保証します。システムやネットワークのエラーのために、3つのフェーズのいずれかが失敗した場合はどうなるのでしょうか。この場合、トランザクションはインダウトになります。

分散トランザクションは、次の要因によってインダウトになる可能性があります。

- Oracle Databaseソフトウェアを実行しているサーバー・システムがクラッシュした。

- 分散処理に関係している複数のOracle Database間のネットワーク接続が切断された。

- 未処理のソフトウェア・エラーが発生した。

システム、ネットワークまたはソフトウェアの問題が解決されると、RECOプロセスによってインダウト・トランザクションが自動的に解決されます。RECOがトランザクションを解決できるまで、データは読取りおよび書込みの両方についてロックされます。読取りをブロックするのは、データベースが問合せに対してどのバージョンのデータを表示すればよいかを判断できないためです。

この項の内容は次のとおりです。

- インダウト・トランザクションの自動解決

- インダウト・トランザクションの手動解決

- インダウト・トランザクションのシステム変更番号の関連性

インダウト・トランザクションの自動解決

データベースでは、多くの場合、インダウト・トランザクションは自動的に解決されます。たとえば、次の使用例においてlocalとremoteの2つのノードがあるとします。ローカル・ノードはコミット・ポイント・サイトです。ユーザーscottは、localに接続してlocalとremoteを更新する分散トランザクションを実行し、コミットします。

準備フェーズ中の障害

図34-5は、分散トランザクションの準備フェーズ中に障害が発生したときの一連のイベントを示しています。

図34-5 準備フェーズ中の障害

次の手順が発生します。

1. ユーザーSCOTTはLocalに接続して分散トランザクションを実行します。

2. グローバル・コーディネータ(この例ではコミット・ポイント・サイトを兼務)は、コミット・ポイント・サイト以外のすべてのデータベースに対して、コミットまたはロールバックの指示があったときにその動作を実行することを確約するように要求します。

3. remoteデータベースが、localに準備応答を発行する前にクラッシュします。

4. トランザクションは、リモート・サイトのリストア時に、RECOプロセスによって各データベースで最終的にロールバックされます。

コミット・フェーズ中の障害

図34-6は、分散トランザクションのコミット・フェーズ中に障害が発生したときの一連のイベントを示しています。

図34-6 コミット・フェーズ中の障害

次の手順が発生します。

1. ユーザーScottはlocalに接続して分散トランザクションを実行します。

2. グローバル・コーディネータ(この場合はコミット・ポイント・サイトを兼務)は、コミット・ポイント・サイト以外のすべてのデータベースに対して、コミットまたはロールバックの指示があったときにその動作を実行することを確約するように要求します。

3. コミット・ポイント・サイトは、コミットの確約を示す準備完了メッセージをremoteから受け取ります。

4. コミット・ポイント・サイトはトランザクションをローカルにコミットし、それからコミット・メッセージをremoteに送ってコミットを要求します。

5. remoteデータベースはコミット・メッセージを受け取りましたが、ネットワーク障害のために応答できません。

6. トランザクションは、ネットワークがリストアされた後、RECOプロセスによってリモート・データベースで最終的にコミットされます。

関連項目:
障害状況の説明と、2フェーズ・コミット中に障害が発生した場合のデータベースによる解決方法の詳細は、「インダウト・トランザクションの処理方法の決定」を参照してください。

インダウト・トランザクションの手動解決

次の場合のみ、インダウト・トランザクションを手動で解決する必要があります。

- インダウト・トランザクションが重要なデータまたはUNDOセグメントをロックしている場合。

- システム、ネットワークまたはソフトウェアの障害の原因をすぐに修復できない場合。

インダウト・トランザクションの解決が複雑になる場合があります。その場合は、次の手順を実行する必要があります。

- インダウト・トランザクションのトランザクション識別番号を特定します。

- DBA_2PC_PENDINGビューおよびDBA_2PC_NEIGHBORSビューを問い合せ、トランザクションに関係しているデータベースのコミットが完了しているかどうかを確認します。

- 必要であれば、COMMIT FORCE文を使用してコミットを強制実行するか、またはROLLBACK FORCE文を使用してロールバックを強制実行します。

関連項目:
インダウト・トランザクションの解決方法の詳細は、次の項を参照してください。

- 「インダウト・トランザクションの処理方法の決定」

- 「インダウト・トランザクションの手動上書き」

インダウト・トランザクションのシステム変更番号の関連性

SCNは、コミット済バージョンのデータベースの内部的なタイムスタンプです。Oracle Databaseサーバーは、SCNクロック値を使用することでトランザクションの一貫性を保証します。たとえば、ユーザーがトランザクションをコミットするとき、データベースはそのコミットのSCNをREDOログに記録します。

データベースは、SCNを使用して、異なるデータベース間での分散トランザクションを調整します。たとえば、データベースは、次のときにSCNを使用します。

1. アプリケーションがデータベース・リンクを使用して接続を確立するとき。

2. 分散トランザクションが、それに関係しているすべてのデータベースの中で最も高いグローバルSCNでコミットされるとき。

3. コミット・グローバルSCNが、トランザクションに関係しているすべてのデータベースに送られるとき。

SCNは、トランザクションが失敗した場合も含め、トランザクションの同期化されたコミット・タイムスタンプとして機能するため、分散トランザクションにとって非常に重要な存在です。トランザクションがインダウトになった場合、管理者はこのSCNを使用して、グローバル・データベースへの変更を調整できます。トランザクション・コミットのグローバルSCNは、分散リカバリの実行時など、後でトランザクションの識別に使用することもできます。

分散トランザクション処理: 事例

この使用例では、ある会社がsales.example.comおよびwarehouse.example.comという異なるOracle Databaseサーバーを持っています。ユーザーが売上レコードをsalesデータベースに挿入すると、対応付けられたレコードがwarehouseデータベースで更新されます。

この分散処理の事例では、次のことを示します。

- セッション・ツリーの定義。

- コミット・ポイント・サイトがどのように決定されるか。

- 準備メッセージがいつ送られるか。

- トランザクションがいつ実際にコミットされるか。

- トランザクションに関するどのような情報がローカルに格納されるか。

第1段階: クライアント・アプリケーションによるDML文の発行

営業部門で、営業担当がSQL*Plusを使用して売上注文を入力し、コミットします。アプリケーションは次のようなSQL文を発行し、salesデータベースに注文を入力して、warehouseデータベースのinventory表を更新します。

CONNECT scott@sales.example.com ...;
INSERT INTO orders ...;
UPDATE inventory@warehouse.example.com ...;
INSERT INTO orders ...;
UPDATE inventory@warehouse.example.com ...;
COMMIT;

これらのSQL文は単一の分散トランザクションの一部であり、発行されるすべてのSQL文がユニットとして成功または失敗することが保証されています。文をユニットとして扱うことにより、注文が設定されていても、注文を反映するように在庫が更新されていないという事態を防ぐことができます。実際は、トランザクションによってグローバル・データベースのデータの一貫性が保証されています。

トランザクションの各SQL文が実行されると、図34-7のようにセッション・ツリーが定義されます。

図34-7 セッション・ツリーの定義

トランザクションの次の点に注意してください。

- トランザクションを開始するのは、salesデータベースで実行されている注文入力アプリケーションです。したがって、分散トランザクションのグローバル・コーディネータは、sales.example.comになります。

- 注文入力アプリケーションは、新しい売上レコードをsalesデータベースに挿入し、warehouseデータベースのinventory表を更新します。したがって、ノードsales.example.comとwarehouse.example.comはどちらもデータベース・サーバーになります。

- sales.example.comはinventory表を更新するため、warehouse.example.comのクライアントになります。

この段階では、この分散トランザクションのセッション・ツリーの定義が完了します。ツリー内の各ノードは、必要なデータ・ロックを獲得して、ローカル・データを参照するSQL文を実行します。これらのロックは、SQL文の実行が完了した後も、2フェーズ・コミットが完了するまで保持されます。

第2段階: Oracle Databaseによるコミット・ポイント・サイトの判別

データベースは、COMMIT文の直後にコミット・ポイント・サイトを判別します。図34-8のように、グローバル・コーディネータのsales.example.comがコミット・ポイント・サイトとして判別されます。

関連項目:
コミット・ポイント・サイトの判別の詳細は、「コミット・ポイント強度」を参照してください。

図34-8 コミット・ポイント・サイトの判別

第3段階: グローバル・コーディネータによる準備応答の送信

準備段階では、次の手順が実行されます。

1. データベースがコミット・ポイント・サイトを判別した後、グローバル・コーディネータは、コミット・ポイント・サイトを除くセッション・ツリーの直接参照先のノードすべてに準備メッセージを送ります。この例では、準備を要求されるノードはwarehouse.example.comのみです。

2. ノードwarehouse.example.comは準備を試みます。トランザクション内のローカルに独立した部分をコミットし、自身のローカルREDOログにコミット情報を記録できることをノードが保証できれば、そのノードは正常に準備できます。この例では、sales.example.comがコミット・ポイント・サイトなので、warehouse.example.comのみが準備メッセージを受け取ります。

3. ノードwarehouse.example.comは、準備完了メッセージでsales.example.comに応答します。

各ノードが準備を終えると、準備を要求した側のノードに応答メッセージが送り返されます。応答に応じて、次のいずれかの動作が発生します。

- 準備を要求されたノードのいずれかが、グローバル・コーディネータに対して異常終了メッセージで応答した場合、グローバル・コーディネータはすべてのノードに対してトランザクションのロールバックを指示し、操作が完了します。

- 準備を要求されたすべてのノードがグローバル・コーディネータに対して準備完了メッセージまたは読取り専用メッセージで応答した場合、つまり、正常に準備できた場合は、グローバル・コーディネータがコミット・ポイント・サイトに対してトランザクションのコミットを要求します。

図34-9 準備メッセージの送信と確認

第4段階: コミット・ポイント・サイトによるコミット

コミット・ポイント・サイトによるトランザクションのコミットでは、次の手順が実行されます。

1. ノードsales.example.comは、warehouse.example.comの準備が完了しているという確認を受け取り、トランザクションをコミットするようにコミット・ポイント・サイトに指示します。

2. この時点で、コミット・ポイント・サイトはトランザクションをローカルにコミットし、この操作を自身のローカルREDOログに記録します。

warehouse.example.comがまだコミットを完了していない場合でも、このトランザクションの結果は事前に決まっています。言い換えれば、指定したノードのコミット機能が遅延したとしても、トランザクションはすべてのノードでコミットされます。

第5段階: コミット・ポイント・サイトによるグローバル・コーディネータへのコミットの通知

この段階では、次の手順が実行されます。

1. コミット・ポイント・サイトは、トランザクションがコミットされたことをグローバル・コーディネータに伝えます。この例ではコミット・ポイント・サイトとグローバル・コーディネータが同一のノードであるため、操作は必要ありません。コミット・ポイント・サイトは、トランザクションがコミットされたことを自身のオンライン・ログに記録しているため、この事実を把握しています。

2. グローバル・コーディネータは、分散トランザクションに関係している他のすべてのノードでトランザクションがコミットされたことを確認します。

第6段階: グローバルおよびローカル・コーディネータによる全ノードへのコミットの要求

トランザクション内のすべてのノードによるトランザクションのコミットでは、次の手順が実行されます。

1. コミット・ポイント・サイトでのコミットがグローバル・コーディネータに通知された後、グローバル・コーディネータは、直接参照している他のすべてのノードに対してコミットを指示します。

2. コミットの指示を受けたローカル・コーディネータは、次に自身のサーバーに対してコミットを指示し、以下同様にコミットの指示が伝播されます。

3. グローバル・コーディネータを含む各ノードは、トランザクションをコミットし、該当するREDOログ・エントリをローカルに記録します。各ノードのコミットが完了すると、そのトランザクションのためにローカルに保持されていたリソース・ロックが解放されます。

図34-10では、コミット・ポイント・サイトとグローバル・コーディネータを兼務しているsales.example.comが、トランザクションのローカルのコミットをすでに完了しています。この時点でsalesはwarehouse.example.comに対してトランザクションのコミットを指示します。

図34-10 ノードへのコミットの指示

第7段階: グローバル・コーディネータとコミット・ポイント・サイトによるコミットの完了

トランザクションのコミットの完了は、次の手順で実行されます。

1. すべての参照先ノードとグローバル・コーディネータがトランザクションのコミットを完了した後、グローバル・コーディネータはこれをコミット・ポイント・サイトに通知します。

2. このメッセージを待っていたコミット・ポイント・サイトは、この分散トランザクションに関するステータス情報を消去します。

3. コミット・ポイント・サイトは、完了したことをグローバル・コーディネータに伝えます。つまり、コミット・ポイント・サイトは、分散トランザクションのコミットに関する情報を保持しません。2フェーズ・コミットに関係しているすべてのノードでトランザクションのコミットが正常に完了すると、それらのノードで今後ノード自身のステータスを判断する必要はないため、このような処理が許可されます。

4. グローバル・コーディネータは、トランザクション自体に関する情報を消去することでトランザクションを完了します。

COMMITフェーズの完了後、分散トランザクションそのものが完了します。これまで説明した手順は、1秒以内に自動的に実行されます。

35 分散トランザクションの管理

この章の内容は、次のとおりです。

- ノードのコミット・ポイント強度の指定

- トランザクションの命名

- 分散トランザクション情報の表示

- インダウト・トランザクションの処理方法の決定

- インダウト・トランザクションの手動上書き

- データ・ディクショナリからの保留行のパージ

- インダウト・トランザクションの手動コミット: 例

- ロックによるデータ・アクセスの障害

- 分散トランザクション障害のシミュレーション

- 読込み一貫性の管理

ノードのコミット・ポイント強度の指定

分散トランザクションでどのノードが最初にコミットされるかは、最も高いコミット・ポイント強度を持つデータベースによって決まります。各ノードのコミット・ポイント強度を指定するときは、準備フェーズまたはコミット・フェーズ中に障害が発生した場合に最も重要なサーバーがブロックされないようにしてください。ノードのコミット・ポイント強度は、COMMIT_POINT_STRENGTH初期化パラメータによって指定します。

デフォルト値は、オペレーティング・システムによって異なります。値の範囲は、0(ゼロ)から255までの任意の整数です。たとえば、データベースのコミット・ポイント強度を200に設定するには、そのデータベースの初期化パラメータ・ファイルに次の行を追加します。

COMMIT_POINT_STRENGTH = 200

コミット・ポイント強度は、分散トランザクションでコミット・ポイント・サイトを決定する際にのみ使用されます。

データベースのコミット・ポイント強度を設定するときは、次の点を考慮してください。

- コミット・ポイント・サイトにはトランザクションのステータスに関する情報が格納されます。他のノードがトランザクションのステータスに関する情報を必要とする場合に備えて、コミット・ポイント・サイトには、信頼性が低下したり、使用できなくなったりする頻度の高いノードを使用しないでください。

- データベースのコミット・ポイント強度は、データベース内の重要な共有データの量に比例するように設定してください。たとえば、メインフレーム・コンピュータのデータベースは、一般にPCのデータベースよりも多くのデータをユーザー間で共有しています。したがって、メインフレームのコミット・ポイント強度は、PCのコミット・ポイント強度よりも高い値に設定します。

関連項目:
コミット・ポイントの概念の詳細は、「コミット・ポイント・サイト」を参照してください。

トランザクションの命名

トランザクションの命名が可能です。この機能は、特定の分散トランザクションを識別する際に便利であり、同じ目的のCOMMIT COMMENT文にかわるものです。

トランザクションに命名するにはSET TRANSACTION...NAME文を使用します。次に例を示します。

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
NAME 'update inventory checkpoint 0';

この例は、SERIALIZABLEに等しい分離レベルを持つ新しいトランザクションをユーザーが開始し、それに'update inventory checkpoint 0'という名前を付けたことを示しています。

分散トランザクションでは、トランザクションがコミットされるときに、名前が参加サイトに送られます。トランザクション名が存在する場合は、COMMIT COMMENTがあっても無視されます。

トランザクション名は、V$TRANSACTIONビューのNAME列に表示され、トランザクションがコミットされると、DBA_2PC_PENDINGビューのTRAN_COMMENTフィールドに表示されます。

分散トランザクション情報の表示

各データベースのデータ・ディクショナリには、オープンしているすべての分散トランザクションに関する情報が格納されています。データ・ディクショナリの表とビューを使用すると、トランザクションに関する情報を取得できます。この項の内容は次のとおりです。

- 準備完了トランザクションのID番号と状態の判断

- インダウト・トランザクションのセッション・ツリーのトレース

準備完了トランザクションのID番号と状態の判断

次のビューには、ローカル・データベースで定義され、データ・ディクショナリに格納されているデータベース・リンクが表示されます。

ビュー

目的

DBA_2PC_PENDING

インダウト分散トランザクションがすべてリストされます。このビューには、インダウト・トランザクションが移入されるまで何もデータが入っていません。トランザクションが解決された後、ビューはパージされます。

このビューは、特定のトランザクションIDのグローバル・コミット番号を判断するために使用します。このグローバル・コミット番号は、インダウト・トランザクションを手動で解決するときに使用できます。

関連性の最も高い列を次の表に示します(ビューのすべての列の詳細は、『Oracle Databaseリファレンス』を参照してください)。

表35-1 DBA_2PC_PENDING

列

説明

LOCAL_TRAN_ID

「integer.integer.integer」という書式のローカル・トランザクション識別子。

注意: 接続のLOCAL_TRAN_IDとGLOBAL_TRAN_IDが同じ場合、そのノードはトランザクションのグローバル・コーディネータです。

GLOBAL_TRAN_ID

global_db_name.db_hex_id.local_tran_idという書式のグローバル・データベース識別子で、db_hex_idはデータベースを一意に識別するために使用する8文字の16進数値です。この共通のトランザクションIDは、分散トランザクションのすべてのノードで同一です。

注意: 接続のLOCAL_TRAN_IDとGLOBAL_TRAN_IDが同じ場合、そのノードはトランザクションのグローバル・コーディネータです。

STATE

STATEに可能な値は、次のとおりです。

- Collecting
通常、このカテゴリは、グローバル・コーディネータまたはローカル・コーディネータにのみ適用されます。ノードは現在他のデータベース・サーバーから情報を収集中であり、その後ノード自身が準備できるかどうかが判断されます。

- Prepared
ノードは準備を完了していますが、そのことをローカル・コーディネータに準備完了メッセージで通知しているかどうかは不明です。しかし、コミット要求はまだ受け取っていません。ノードは準備完了状態にあり、トランザクションのコミットに必要なローカル・リソースのロックをすべて保持しています。

- Committed
ノード(任意のタイプ)はトランザクションのコミットを完了していますが、トランザクションに関係している他のノードが同じように完了していない可能性があります。つまり、トランザクションは1つ以上のノードでまだ保留しています。

- Forced Commit
ペンディング・トランザクションは、データベース管理者の判断で強制的にコミットできます。このエントリは、ローカル・ノードでトランザクションが手動でコミットされた場合に表示されます。

- Forced termination (rollback)
ペンディング・トランザクションは、データベース管理者の判断で強制的にロールバックできます。このエントリは、ローカル・ノードでこのトランザクションが手動でロールバックされた場合に表示されます。

MIXED

YESは、トランザクションの一部があるノードではコミットされ、別のノードではロールバックされたことを示します。

TRAN_COMMENT

トランザクションがコミットされると、トランザクション・コメントまたはトランザクション名(トランザクションに命名している場合)がこの列に設定されます。

HOST

ホスト・システムの名前。

COMMIT#

コミットされたトランザクションのグローバル・コミット番号。

DBA_2PC_PENDINGの関連情報を問い合せるには、次のスクリプトpending_txn_scriptを実行します(出力例も含まれています)。

COL LOCAL_TRAN_ID FORMAT A13
COL GLOBAL_TRAN_ID FORMAT A30
COL STATE FORMAT A8
COL MIXED FORMAT A3
COL HOST FORMAT A10
COL COMMIT# FORMAT A10

SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID, STATE, MIXED, HOST, COMMIT#
FROM DBA_2PC_PENDING
/

SQL> @pending_txn_script

LOCAL_TRAN_ID GLOBAL_TRAN_ID                 STATE    MIX HOST       COMMIT#
------------- ------------------------------ -------- --- ---------- ----------
1.15.870      HQ.EXAMPLE.COM.ef192da4.1.15.870  commit   no  dlsun183   115499

この出力は、ローカル・トランザクション1.15.870がこのノードではコミットを完了しているものの、他の1つ以上のノードで保留している可能性があることを示しています。LOCAL_TRAN_IDとGLOBAL_TRAN_IDのローカル部分が同じなので、このノードはトランザクションのグローバル・コーディネータです。

インダウト・トランザクションのセッション・ツリーのトレース

次のビューには、リモート・クライアントから受信されるインダウト・トランザクションと、リモート・サーバーに送信されるインダウト・トランザクションが表示されます。

ビュー

目的

DBA_2PC_NEIGHBORS

(リモート・クライアントからの)受信および(リモート・サーバーへの)送信インダウト分散トランザクションすべてがリストされます。また、ローカル・ノードがトランザクション内のコミット・ポイント・サイトであるかどうかも示します。
このビューには、インダウト・トランザクションが移入されるまで何もデータが入っていません。トランザクションが解決された後、ビューはパージされます。

トランザクションがインダウトのときは、セッション・ツリー内のどのノードがどのロールを実行しているのかを判断することが必要な場合があります。このビューを使用すると、次のことが判断できます。

- 特定のトランザクションのすべての受信接続と送信接続。

- ノードが特定のトランザクションのコミット・ポイント・サイトかどうか。

- ノードが特定のトランザクションのグローバル・コーディネータかどうか(ノードのローカル・トランザクションIDとグローバル・トランザクションIDが同じかどうかで判断する)。

関連性の最も高い列を次の表に示します(ビューのすべての列の詳細は、『Oracle Databaseリファレンス』を参照してください)。

表35-2 DBA_2PC_NEIGHBORS

列

説明

LOCAL_TRAN_ID

「integer.integer.integer」という書式のローカル・トランザクション識別子。

注意: 接続のLOCAL_TRAN_IDとGLOBAL_TRAN_ID.DBA_2PC_PENDINGが同じ場合、そのノードはトランザクションのグローバル・コーディネータです。

IN_OUT

受信トランザクションの場合はIN、送信トランザクションの場合はOUTです。

DATABASE

受信トランザクションの場合は、このローカル・ノードから情報を要求したクライアント・データベースの名前です。送信トランザクションの場合は、リモート・サーバーの情報へのアクセスに使用されたデータベース・リンクの名前です。

DBUSER_OWNER

受信トランザクションの場合は、リモート・データベース・リンクによる接続で使用されるローカル・アカウントです。送信トランザクションの場合は、データベース・リンクの所有者です。

INTERFACE

Cはコミット・メッセージ、Nは準備完了状態を示すメッセージまたは読取り専用コミットの要求のどちらかです。

IN_OUTがOUTの場合、Cは、接続のリモート側の子がコミット・ポイント・サイトであり、コミットと終了のどちらを実行するかを知っていることを意味します。Nは、ローカル・ノードの準備が完了したことをリモート・ノードに通知中であることを意味します。

IN_OUTがINの場合、Cは、送信接続のリモート側のローカル・ノードまたはデータベースがコミット・ポイント・サイトであることを表します。Nは、リモート・ノードの準備が完了したことをローカル・ノードに通知中であることを意味します。

DBA_2PC_PENDINGの関連情報を問い合せるには、次のスクリプトneighbors_scriptを実行します(出力例も含まれています)。

COL LOCAL_TRAN_ID FORMAT A13
COL IN_OUT FORMAT A6
COL DATABASE FORMAT A25
COL DBUSER_OWNER FORMAT A15
COL INTERFACE FORMAT A3
SELECT LOCAL_TRAN_ID, IN_OUT, DATABASE, DBUSER_OWNER, INTERFACE
FROM DBA_2PC_NEIGHBORS
/

SQL> CONNECT SYS@hq.example.com AS SYSDBA
SQL> @neighbors_script

LOCAL_TRAN_ID IN_OUT DATABASE                  DBUSER_OWNER    INT
------------- ------ ------------------------- --------------- ---
1.15.870      out    SALES.EXAMPLE.COM            SYS             C

この出力は、ローカル・ノードからリモート・サーバーsalesに、トランザクション1.15.870をコミットするように送信リクエストが送られたことを示しています。salesがトランザクションをコミットし、他にコミットしたノードがない場合は、常に最初にコミットするのがコミット・ポイント・サイトであるため、salesがコミット・ポイント・サイトになります。

インダウト・トランザクションの処理方法の決定

2フェーズ・コミットの間に障害が発生すると、トランザクションはインダウトになります。分散トランザクションがインダウトになる要因は、次のとおりです。

- Oracle Databaseソフトウェアを実行しているサーバー・システムがクラッシュした。

- 分散処理に関係している複数のOracle Database間のネットワーク接続が切断された。

- 未処理のソフトウェア・エラーが発生した。

関連項目:
インダウト・トランザクションの概念の詳細は、「インダウト・トランザクション」を参照してください。

ローカルのインダウト分散トランザクションは、手動で強制的にコミットまたはロールバックできます。この操作では一貫性の問題が生じる可能性があるため、特定の条件が成り立つとき以外は実行しないでください。

この項の内容は次のとおりです。

- 2フェーズ・コミットに関する問題の検出

- 手動上書きを実行するかどうかの判断

- トランザクション・データの分析

2フェーズ・コミットに関する問題の検出

分散トランザクションをコミットするユーザー・アプリケーションには、次のいずれかのエラー・メッセージによって問題が通知されます。

ORA-02050: transaction ID rolled back,
some remote dbs may be in-doubt
ORA-02053: transaction ID committed,
some remote dbs may be in-doubt
ORA-02054: transaction ID in-doubt

アプリケーションでこれらのエラーを受け取った場合は、トランザクションに関する情報を保存するようにしてください。この情報は、後で分散トランザクションの手動リカバリが必要になった場合に使用できます。

ネットワークまたはシステムの障害のために、任意のノードでインダウト分散トランザクションが1つ以上発生した場合でも、そのノードの管理者がなんらかの処理を実行する必要はありません。ネットワークやシステムの障害が解決した後、データベースの自動リカバリ機能によって、セッション・ツリーのすべてのノードが同じ結果になるように(つまり、すべてコミットされるかすべてロールバックされる)、すべてのインダウト・トランザクションの処理が透過的に完了します。

ただし、障害が長期にわたる場合には、トランザクションを強制的にコミットまたはロールバックすることで、ロックされたデータをすべて解放できます。アプリケーションは、この操作を想定しておく必要があります。

手動上書きを実行するかどうかの判断

特定のインダウト・トランザクションを手動でオーバーライドするのは、次のいずれかの条件が存在する場合のみです。

- インダウト・トランザクションが他のトランザクションに必要なデータをロックしている場合。この状況は、ORA-01591エラー・メッセージによってユーザーのトランザクションが妨げられたときに起こります。

- インダウト・トランザクションは、UNDOセグメントのエクステントが他のトランザクションによって使用されることを防ぎます。インダウト分散トランザクションのローカル・トランザクションIDの最初の部分は、データ・ディクショナリ・ビューDBA_2PC_PENDINGでリストされるUNDOセグメントのIDに対応します。

- 2フェーズ・コミットの各フェーズの完了を妨げている障害を許容される時間範囲内で訂正できない場合。このような例としては、通信ネットワークやデータベースの損傷など、リカバリに長い時間を要する障害があります。

通常、インダウト分散トランザクションをローカルで強制する場合は、別の場所の管理者と相談した上で決断する必要があります。判断を誤るとデータベースの一貫性が損われ、トレースが困難で手動での修正が必要となる恐れがあります。

これらの条件のいずれも当てはまらない場合、データベースの自動リカバリ機能を常に許可し、トランザクションを完了してください。しかし、前述のいずれかの条件に当てはまる場合には、インダウト・トランザクションのローカルでの修正を検討してください。

トランザクション・データの分析

トランザクションの強制完了を決めた場合は、次の目的に留意しながら、使用可能な情報を分析します。

コミットまたはロールバックされたノードの特定

DBA_2PC_PENDINGビューを使用し、トランザクションをコミットまたはロールバックしたノードを探します。トランザクションをすでに解決しているノードが見つかった場合は、そのノードで実行された処理に従うことができます。

トランザクション・コメントの確認

DBA_2PC_PENDINGのTRAN_COMMENT列に、対象の分散トランザクションに関するなんらかの情報が与えられていないかを確認します。COMMIT文のCOMMENT句にコメントが含まれているか、またはトランザクションに命名している場合は、トランザクションがコミットされると、トランザクション名がTRAN_COMMENTフィールドに設定されます。

たとえば、インダウト分散トランザクションのコメントで、トランザクションの開始元とタイプを示すことができます。

COMMIT COMMENT 'Finance/Accts_pay/Trans_type 10B';

また、この情報をトランザクション名として提供するために、SET TRANSACTION...NAME文を使用することも可能です。

関連項目:
「トランザクションの命名」

トランザクション・アドバイスの確認

DBA_2PC_PENDINGのADVICE列に、対象の分散トランザクションに関するなんらかの情報が与えられていないかを確認します。アプリケーションでALTER SESSION文のADVISE句を使用すれば、分散トランザクションの別々の部分を強制的にコミットまたはロールバックする際のアドバイスを規定できます。

準備フェーズ中に各ノードに送られたアドバイスは、現行トランザクション内でそのデータベースに対し最新のDML文が実行されたときに有効なアドバイスです。

たとえば、あるノードのemp表から別のノードのemp表に従業員レコードを移動する分散トランザクションを考えます。次の一連のSQL文を追加することによって、管理者が各ノードで個別にインダウト・トランザクションを強制的に完了した場合でも、トランザクションでレコードを保護できます。

ALTER SESSION ADVISE COMMIT;
INSERT INTO emp@hq ... ;    /*advice to commit at HQ */
ALTER SESSION ADVISE ROLLBACK;
DELETE FROM emp@sales ... ; /*advice to roll back at SALES*/

ALTER SESSION ADVISE NOTHING;

与えられたアドバイスに従ってインダウト・トランザクションを手動で強制的に完了すると、最悪の場合、各ノードに従業員レコードがコピーされ、消去できなくなる可能性があります。

インダウト・トランザクションの手動上書き

COMMIT文またはROLLBACK文に、FORCEオプションと、コミットまたはロールバックするインダウト・トランザクションのローカル・トランザクションIDまたはグローバル・トランザクションIDを示すテキスト文字列を指定します。

注意:
以降のすべての例で、トランザクションはローカル・ノードでコミットまたはロールバックされます。ローカルのペンディング・トランザクション表では、このトランザクションの行のSTATE列に強制コミットまたは強制終了の値が記録されます。

この項の内容は次のとおりです。

- インダウト・トランザクションの手動コミット

- インダウト・トランザクションの手動ロールバック

インダウト・トランザクションの手動コミット

トランザクションのコミットを試みる前に、適正な権限を持っていることを確認してください。次の要件に注意してください。

トランザクションをコミットするユーザー

必要な権限

管理者

FORCE TRANSACTION

別のユーザー

FORCE ANY TRANSACTION

トランザクションIDのみを使用したコミット

次のSQL文は、インダウト・トランザクションをコミットします。

COMMIT FORCE 'transaction_id';

変数transaction_idは、DBA_2PC_PENDINGデータ・ディクショナリ・ビューのLOCAL_TRAN_ID列またはGLOBAL_TRAN_ID列のどちらかで指定されているトランザクション識別子です。

たとえば、DBA_2PC_PENDINGを問い合せて、分散トランザクションのLOCAL_TRAN_IDが1:45.13であることを確認するとします。

そして、次のSQL文を発行し、このインダウト・トランザクションのコミットを強制実行します。

COMMIT FORCE '1.45.13';

システム変更番号(SCN)を使用したコミット

必要であれば、トランザクションを強制的にコミットするときに、トランザクションのSCNを指定することもできます。この機能を使用すると、他のノードでトランザクションがコミットされたときに割り当てられたSCNを使用して、インダウト・トランザクションをコミットできます。

これにより、障害が発生した場合でも、分散トランザクションのコミット時間の同期を保つことができます。SCNは、別のノードですでにコミットされた同じトランザクションのSCNが判別できるときのみ指定してください。

たとえば、次のグローバル・トランザクションIDを使用してトランザクションを手動でコミットするとします。

SALES.EXAMPLE.COM.55d1c563.1.93.29

まず、対象のトランザクションに関係しているリモート・データベースのDBA_2PC_PENDINGビューを問い合せます。次に、そのノードでトランザクションのコミットに使用されたSCNをメモします。そして、ローカル・ノードでトランザクションをコミットするときにこのSCNを指定します。たとえば、SCNが829381993の場合は、次の文を発行します。

COMMIT FORCE 'SALES.EXAMPLE.COM.55d1c563.1.93.29', 829381993;

関連項目:
COMMIT文の使用の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

インダウト・トランザクションの手動ロールバック

インダウト分散トランザクションのロールバックを試みる前に、適正な権限を持っていることを確認してください。次の要件に注意してください。

トランザクションをコミットするユーザー

必要な権限

管理者

FORCE TRANSACTION

別のユーザー

FORCE ANY TRANSACTION

次のSQL文は、インダウト・トランザクションをロールバックします。

ROLLBACK FORCE 'transaction_id';

変数transaction_idは、DBA_2PC_PENDINGデータ・ディクショナリ・ビューのLOCAL_TRAN_ID列またはGLOBAL_TRAN_ID列のどちらかで指定されているトランザクション識別子です。

たとえば、ローカル・トランザクションIDが2.9.4のインダウト・トランザクションをロールバックするには、次の文を使用します。

ROLLBACK FORCE '2.9.4';

注意:
インダウト・トランザクションをセーブポイントまでロールバックすることはできません。

関連項目:
ROLLBACK文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

データ・ディクショナリからの保留行のパージ

インダウト・トランザクションは、RECO(リカバラ・プロセス)によってリカバリされる前に、DBA_2PC_PENDING.STATE列にCOLLECTING、COMMITTEDまたはPREPAREDとして表示されます。COMMIT FORCEまたはROLLBACK FORCEを使用してインダウト・トランザクションを強制的に完了すると、FORCED COMMITまたはFORCED ROLLBACKの状態になることがあります。

自動リカバリでは通常、これらの状態にあるエントリが削除されます。唯一の例外として、リカバリ時に、トランザクション内の他のサイトと一貫性のない状態にある強制トランザクションが検出されるときがあります。この場合は、エントリが表内に残る可能性があり、DBA_2PC_PENDINGのMIXED列の値がYESになります。これらのエントリは、DBMS_TRANSACTION.PURGE_MIXEDプロシージャを使用してクリーン・アップできます。

リモート・データベースが永続的に失われたために自動リカバリが不可能な場合は、データベースを再作成しても再作成時に新しいデータベースIDが割り当てられるため、リカバリではそのデータベースを識別できません。このような場合、DBMS_TRANSACTIONパッケージのPURGE_LOST_DB_ENTRYプロシージャを使用してエントリをクリーン・アップする必要があります。このエントリによってデータベース・リソースが保持されることはないため、エントリのクリーン・アップを急ぐ必要はありません。

関連項目:
DBMS_TRANSACTIONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

PURGE_LOST_DB_ENTRYプロシージャの実行

エントリをデータ・ディクショナリから手動で削除するには、次の構文を使用します(ここで、trans_idはトランザクションの識別子を表します)。

DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('trans_id');

たとえば、保留中の分散トランザクション1.44.99をパージするには、SQL*Plusで次の文を入力します。

EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.44.99');

このプロシージャは、自動リカバリによってトランザクションを解決できないほどの大幅な再構成を行った場合にのみ実行してください。たとえば、次のような場合です。

- リモート・データベースが完全に失われた場合

- ソフトウェアを再構成した結果、2フェーズ・コミットの機能がなくなった場合

- TPMonitorなどの外部トランザクション・コーディネータからの情報が失われた場合

DBMS_TRANSACTIONを使用する時期の判断

次の表は、分散トランザクションに関する各種の状態と、それに対して管理者が実行すべき処理を示したものです。

STATE列

グローバル・トランザクションの状態

ローカル・トランザクションの状態

通常の処理

代替処理

Collecting

ロールバック

ロールバック

なし

PURGE_LOST_DB_ENTRY(自動リカバリでトランザクションを解決できない場合のみ)

Committed

Committed

Committed

なし

PURGE_LOST_DB_ENTRY(自動リカバリでトランザクションを解決できない場合のみ)

Prepared

不明

Prepared

なし

強制コミットまたは強制ロールバック

Forced commit

不明

Committed

なし

PURGE_LOST_DB_ENTRY(自動リカバリでトランザクションを解決できない場合のみ)

Forced rollback

不明

ロールバック

なし

PURGE_LOST_DB_ENTRY(自動リカバリでトランザクションを解決できない場合のみ)

Forced commit

混合

Committed

非一貫性部分を手動で削除してからPURGE_MIXEDを使用する

-

Forced rollback

混合

ロールバック

非一貫性部分を手動で削除してからPURGE_MIXEDを使用する

-

インダウト・トランザクションの手動コミット: 例

図35-1は、分散トランザクションのコミット中の障害を示しています。この障害例では、準備フェーズは完了しています。しかし、コミット・フェーズ時に、コミット・ポイント・サイトがトランザクションをコミットしていても、コミット・ポイント・サイトのコミット確認がグローバル・コーディネータに到達しません。インダウト・トランザクションは他のトランザクションにとっても重要なものであるため、在庫データはロックされており、アクセスできません。また、インダウト・トランザクションがコミットまたはロールバックされるまで、ロックが必ず保持されます。

図35-1 インダウト分散トランザクションの例

次の手順に従って、インダウト・トランザクションのローカル部分を手動で強制完了できます。詳細は、以降の項を参照してください。

手順1: ユーザーからのフィードバックの記録

手順2: DBA_2PC_PENDINGの問合せ

手順3: ローカル・ノードでのDBA_2PC_NEIGHBORSの問合せ

手順4: 全ノードでのデータ・ディクショナリ・ビューの問合せ

手順5: インダウト・トランザクションのコミット

手順6: DBA_2PC_PENDINGを使用したMIXED結果のチェック

手順1: ユーザーからのフィードバックの記録

インダウト・トランザクションのロックと競合を起こしているローカル・データベース・システムのユーザーは、次のエラー・メッセージを受け取ります。

ORA-01591: lock held by in-doubt distributed transaction 1.21.17

この場合、1.21.17はインダウト分散トランザクションのローカル・トランザクションIDです。どのインダウト・トランザクションを強制処理すればよいかを特定するために、問題を報告したユーザーからこのID番号を聞き、記録しておきます。

手順2: DBA_2PC_PENDINGの問合せ

SQL*Plusを使用してwarehouseに接続した後、ローカルのDBA_2PC_PENDINGデータ・ディクショナリ・ビューを問い合せて、インダウト・トランザクションに関する情報を取得します。

CONNECT SYS@warehouse.example.com AS SYSDBA
SELECT * FROM DBA_2PC_PENDING WHERE LOCAL_TRAN_ID = '1.21.17';

データベースは次の情報を返します。

Column Name            Value
---------------------- --------------------------------------
LOCAL_TRAN_ID          1.21.17
GLOBAL_TRAN_ID         SALES.EXAMPLE.COM.55d1c563.1.93.29
STATE                  prepared
MIXED                  no
ADVICE
TRAN_COMMENT           Sales/New Order/Trans_type 10B
FAIL_TIME              31-MAY-91
FORCE_TIME
RETRY_TIME             31-MAY-91
OS_USER                SWILLIAMS
OS_TERMINAL            TWA139:
HOST                   system1
DB_USER                SWILLIAMS
COMMIT#

グローバル・トランザクションIDの判断

グローバル・トランザクションIDは、分散トランザクションのすべてのノードで同一である共通のトランザクションIDです。次のような書式で記録されています。

global_database_name.hhhhhhhh.local_transaction_id

説明:

- global_database_nameは、グローバル・コーディネータのデータベース名です。

- hhhhhhhhは、グローバル・コーディネータの内部データベース識別子(16進値)です。

- local_transaction_idは、グローバル・コーディネータで割り当てられた、対応するローカル・トランザクションIDです。

グローバル・コーディネータでは、グローバル・トランザクションIDの最後の部分とローカル・トランザクションIDが一致します。この例では、これらの番号が一致していないため、warehouseがグローバル・コーディネータではないことがわかります。

LOCAL_TRAN_ID          1.21.17
GLOBAL_TRAN_ID         ... 1.93.29

トランザクションの状態の判断

このノードのトランザクションは、準備完了状態です。

STATE          prepared

したがって、warehouseは、自身のコーディネータからコミット要求またはロールバック要求が送られてくるのを待っています。

コメントまたはアドバイスの確認

トランザクションのコメントまたはアドバイスに、このトランザクションに関する情報が含まれている可能性があります。トランザクションに関する情報が含まれていれば、そのコメントを利用します。この例では、トランザクションのコメントに開始元とトランザクション・タイプが含まれています。

TRAN_COMMENT           Sales/New Order/Trans_type 10B

また、SET TRANSACTION...NAME文によって、トランザクション名として提供されている可能性もあります。

この情報から、トランザクションのローカル部分をコミットすべきか、またはロールバックすべきかを決める際に役立つ情報を得ることができます。インダウト・トランザクションに有益なコメントが付けられていない場合は、その他の管理作業を実行し、セッション・ツリーをトレースして、トランザクションをすでに解決しているノードを探す必要があります。

手順3: ローカル・ノードでのDBA_2PC_NEIGHBORSの問合せ

この手順の目的は、セッション・ツリーを探索してコーディネータを見つけ、最終的にグローバル・コーディネータに到達することです。それと同時に、トランザクションをすでに解決しているコーディネータが見つかる場合もあります。見つからない場合は、最終的にコミット・ポイント・サイトを探し出します(コミット・ポイント・サイトでは、常にインダウト・トランザクションが解決されています)。セッション・ツリーをトレースするには、各ノードのDBA_2PC_NEIGHBORSビューを問い合せます。

この例では、warehouseデータベースでこのビューを問い合せます。

CONNECT SYS@warehouse.example.com AS SYSDBA
SELECT * FROM DBA_2PC_NEIGHBORS
WHERE LOCAL_TRAN_ID = '1.21.17'
ORDER BY SESS#, IN_OUT;

Column Name            Value
---------------------- --------------------------------------
LOCAL_TRAN_ID          1.21.17
IN_OUT                 in
DATABASE               SALES.EXAMPLE.COM
DBUSER_OWNER           SWILLIAMS
INTERFACE              N
DBID                   000003F4
SESS#                  1
BRANCH                 0100

データベースのロールとデータベース・リンク情報の取得

DBA_2PC_NEIGHBORSビューは、インダウト・トランザクションに対応付けられた接続に関する情報を提供します。情報は、接続が受信(IN_OUT = in)か送信(IN_OUT = out)かによって異なります。

IN_OUT

意味

DATABASE

DBUSER_OWNER

in

このノードは別のノードのサーバーです。

このノードに接続しているクライアント・データベースの名前がリストされます。

インダウト・トランザクションに対応するデータベース・リンク接続のローカル・アカウントがリストされます。

out

このノードは他のサーバーのクライアントです。

リモート・ノードに接続しているデータベース・リンクの名前がリストされます。

インダウト・トランザクションのデータベース・リンクの所有者がリストされます。

この例では、IN_OUT列によって、warehouseデータベースがsalesクライアント(DATABASE列に示されている)のサーバーであることがわかります。

IN_OUT                 in
DATABASE               SALES.EXAMPLE.COM

warehouseへの接続は、swilliamsアカウント(DBUSER_OWNER列に示されている)からのデータベース・リンクを介して確立されています。

DBUSER_OWNER           SWILLIAMS

コミット・ポイント・サイトの判別

この他、INTERFACE列によって、ローカル・ノードまたは下位ノードがコミット・ポイント・サイトなのかどうかがわかります。

INTERFACE              N

INTERFACE列が示すように、warehouseもその子もコミット・ポイント・サイトではありません。

手順4: 全ノードでのデータ・ディクショナリ・ビューの問合せ

この時点で、各設置ノードの管理者に連絡を取り、グローバル・トランザクションIDを使用して手順2および3を繰り返すように各管理者に依頼できます。

注意:
これらのノードに別のネットワークを介して直接接続できる場合は、手順2および3を独力で実行できます。

たとえば、salesおよびhqで手順2および3を実行すると、次の結果が返されます。

salesでのペンディング・トランザクションの状態の確認

この段階では、salesの管理者がDBA_2PC_PENDINGデータ・ディクショナリ・ビューを問い合せます。

SQL> CONNECT SYS@sales.example.com AS SYSDBA
SQL> SELECT * FROM DBA_2PC_PENDING
> WHERE GLOBAL_TRAN_ID = 'SALES.EXAMPLE.COM.55d1c563.1.93.29';

Column Name            Value
---------------------- --------------------------------------
LOCAL_TRAN_ID          1.93.29
GLOBAL_TRAN_ID         SALES.EXAMPLE.COM.55d1c563.1.93.29
STATE                  prepared
MIXED                  no
ADVICE
TRAN_COMMENT           Sales/New Order/Trans_type 10B
FAIL_TIME              31-MAY-91
FORCE_TIME
RETRY_TIME             31-MAY-91
OS_USER                SWILLIAMS
OS_TERMINAL            TWA139:
HOST                   system1
DB_USER                SWILLIAMS
COMMIT#

salesでのコーディネータとコミット・ポイント・サイトの判別

次に、salesの管理者はDBA_2PC_NEIGHBORSを問い合せて、グローバル・コーディネータ、ローカル・コーディネータおよびコミット・ポイント・サイトを判別します。

SELECT * FROM DBA_2PC_NEIGHBORS
WHERE GLOBAL_TRAN_ID = 'SALES.EXAMPLE.COM.55d1c563.1.93.29'
ORDER BY SESS#, IN_OUT;

この問合せは、次の3行を返します。

- warehouseへの接続

- hqへの接続

- ユーザーが確立した接続

warehouse接続の行に対応する情報を、書式を変えて示すと次のようになります。

Column Name            Value
---------------------- --------------------------------------
LOCAL_TRAN_ID          1.93.29
IN_OUT                 OUT
DATABASE               WAREHOUSE.EXAMPLE.COM
DBUSER_OWNER           SWILLIAMS
INTERFACE              N
DBID                   55d1c563
SESS#                  1
BRANCH                 1

hq接続の行に対応する情報を、書式を変えて示すと次のようになります。

Column Name            Value
---------------------- --------------------------------------
LOCAL_TRAN_ID          1.93.29
IN_OUT                 OUT
DATABASE               HQ.EXAMPLE.COM
DBUSER_OWNER           ALLEN
INTERFACE              C
DBID                   00000390
SESS#                  1
BRANCH                 1

前の問合せから得られた情報によって、次のことがわかります。

- salesは、ローカル・トランザクションIDとグローバル・トランザクションIDが一致しているため、グローバル・コーディネータです。

- このノードからは送信接続が2つ確立されていますが、受信接続は確立されていません。したがって、salesは別のノードのサーバーではありません。

- コミット・ポイント・サイトは、hqまたはそのサーバーの1つです。

HQでのペンディング・トランザクションの状態の確認

この段階では、hqの管理者がDBA_2PC_PENDINGデータ・ディクショナリ・ビューを問い合せます。

SELECT * FROM DBA_2PC_PENDING@hq.example.com
WHERE GLOBAL_TRAN_ID = 'SALES.EXAMPLE.COM.55d1c563.1.93.29';

Column Name            Value
---------------------- --------------------------------------
LOCAL_TRAN_ID          1.45.13
GLOBAL_TRAN_ID         SALES.EXAMPLE.COM.55d1c563.1.93.29
STATE                  COMMIT
MIXED                  NO
ACTION
TRAN_COMMENT           Sales/New Order/Trans_type 10B
FAIL_TIME              31-MAY-91
FORCE_TIME
RETRY_TIME             31-MAY-91
OS_USER                SWILLIAMS
OS_TERMINAL            TWA139:
HOST                   SYSTEM1
DB_USER                SWILLIAMS
COMMIT#                129314

この時点で、トランザクションを解決しているノードが見つかりました。ビューが示しているように、このノードではコミットが完了しており、コミットID番号が割り当てられています。

STATE                  COMMIT
COMMIT#                129314

したがって、自分のローカル・データベースでインダウト・トランザクションを強制的にコミットできます。この調査結果を他の管理者に伝えれば、他の場所での解決に役立つ可能性があります。

手順5: インダウト・トランザクションのコミット

salesデータベースの管理者と連絡を取り、グローバルIDを使用してインダウト・トランザクションを手動でコミットするように依頼します。

SQL> CONNECT SYS@sales.example.com AS SYSDBA
SQL> COMMIT FORCE 'SALES.EXAMPLE.COM.55d1c563.1.93.29';

同時に、warehouseデータベースの管理者として、グローバルIDを使用してインダウト・トランザクションを手動でコミットします。

SQL> CONNECT SYS@warehouse.example.com AS SYSDBA
SQL> COMMIT FORCE 'SALES.EXAMPLE.COM.55d1c563.1.93.29';

手順6: DBA_2PC_PENDINGを使用したMIXED結果のチェック

トランザクションを手動で強制的にコミットまたはロールバックした後も、ペンディング・トランザクション表の対応する行はそのまま残っています。トランザクションの状態は、トランザクションをどのように強制完了したかに応じて変わります。

Oracle Databaseには、必ずペンディング・トランザクション表があります。これは、2フェーズ・コミットの各フェーズの進行に従って分散トランザクションに関する情報を格納する特別な表です。データベースのペンディング・トランザクション表は、DBA_2PC_PENDINGデータ・ディクショナリ・ビューを介して問い合せることができます(詳細は表35-1を参照)。

また、ペンディング・トランザクション表で特に重要なものとして、DBA_2PC_PENDING.MIXEDに示されるMIXED結果フラグがあります。ペンディング・トランザクションを強制的にコミットまたはロールバックする場合は、選択を誤る可能性があります。たとえば、ローカル管理者がトランザクションをロールバックしたにもかからわず、他のノードではそのトランザクションをコミットしてしまうといったことが考えられます。このような誤った判断は自動的に検出され、対応するペンディング・トランザクションのレコードに損傷フラグが設定されます(MIXED=yes)。

RECOバックグラウンド・プロセスは、ペンディング・トランザクション表の情報を使用して、インダウト・トランザクションの状態を最終決定します。また、管理者がペンディング・トランザクション表の情報を使用して、保留中の分散トランザクションの自動リカバリ手順を手動で上書きすることもできます。

RECOによって自動解決されたトランザクションはすべて、保留中のトランザクション表から削除される。また、管理者によって正しく解決されたインダウト・トランザクションに関する情報も、RECOが通信を再確立したときにチェックされて、すべてペンディング・トランザクション表から自動的に削除されます。ただし、管理者が解決したことによってノード間にまたがってMIXEDの結果が生じた行は、DBMS_TRANSACTIONS.PURGE_MIXEDを使用して手動で削除しないかぎり、関係しているすべてのノードのペンディング・トランザクション表にそのまま残ります。

ロックによるデータ・アクセスの障害

SQL文を発行すると、データベースは文を正常に実行するために必要なリソースのロックを試みます。しかし、要求されたデータが、コミットされていない他のトランザクションの文によって現在保持されていて、長時間ロックされたままになっていると、タイムアウトが発生します。

データ・アクセスの障害に関しては、次の事例について考慮してください。

- トランザクションのタイムアウト

- インダウト・トランザクションによるロック

トランザクションのタイムアウト

リモート・データベースのロックを必要とするDML文は、要求したデータのロックを別のトランザクションが所有している場合にブロックされる可能性があります。このようなロックによってSQL文の要求がブロックされ続けると、次の一連のイベントが発生します。

1. タイムアウトが発生します。

2. データベースは文をロールバックします。

3. データベースは次のエラー・メッセージをユーザーに返します。

ORA-02049: time-out: distributed transaction waiting for lock

トランザクションによってデータは変更されていないので、タイムアウトの結果として必要な処理はありません。アプリケーションでは、デッドロックが発生したものとして処理を継続してください。文を実行したユーザーは、後で同じ文の再実行を試みることができます。それでもロックが続く場合には、ユーザーは管理者に連絡して問題を報告してください。

インダウト・トランザクションによるロック

ローカル・データベースのロックを必要とする問合せまたはDML文は、インダウト分散トランザクションによるリソースのロックのために無期限にブロックされる可能性があります。この場合、データベースは次のエラー・メッセージを発行します。

ORA-01591: lock held by in-doubt distributed transaction identifier

この場合、データベースはSQL文をただちにロールバックします。文を実行したユーザーは、後で同じ文の再実行を試みることができます。ロックが持続する場合、ユーザーは管理者に連絡して、インダウト分散トランザクションのIDなども含めて問題を報告する必要があります。

2フェーズ・コミットの重要な部分の処理中に障害が発生する確率は低いため、このような状況が起こる可能性はほとんどありません。仮にこのような障害が発生した場合でも、ネットワーク障害やシステム障害から迅速にリカバリできれば、手動で介入しなくても問題は自動的に解決されます。したがって、この種の問題は、ユーザーやデータベース管理者に検出される前に解決されるのが普通です。

分散トランザクション障害のシミュレーション

分散トランザクションの障害は、次のような理由で強制的に発生させることができます。

- RECOがトランザクションのローカル部分を自動的に解決する様子を観察するため

- インダウト分散トランザクションの手動解決の演習を行い、その結果を観察するため

ここでは、使用可能な機能とその操作に必要な手順を説明します。

分散トランザクションの強制障害

COMMIT文のCOMMENTパラメータには、コメントを挿入できます。分散トランザクションの2フェーズ・コミットのフェーズ時に意図して障害を発生させるには、COMMENTパラメータに、次のコメントを挿入します。

COMMIT COMMENT 'ORA-2PC-CRASH-TEST-n';

コメント内のnには、次の整数のいずれかが入ります。

n

影響

1

収集後コミット・ポイントをクラッシュ

2

収集後コミット・ポイント・サイト以外をクラッシュ

3

準備前にクラッシュ(コミット・ポイント・サイト以外)

4

準備後にクラッシュ(コミット・ポイント・サイト以外)

5

コミット前にコミット・ポイント・サイトをクラッシュ

6

コミット後にコミット・ポイント・サイトをクラッシュ

7

コミット前にコミット・ポイント・サイト以外をクラッシュ

8

コミット後にコミット・ポイント・サイト以外をクラッシュ

9

情報消去前にコミット・ポイント・サイトをクラッシュ

10

情報消去前にコミット・ポイント・サイト以外をクラッシュ

たとえば、ローカルのコミット・ポイント強度がリモートのコミット・ポイント強度よりも高く、双方のノードが更新されている場合、次の文では、次のメッセージが返されます。

COMMIT COMMENT 'ORA-2PC-CRASH-TEST-7';

ORA-02054: transaction 1.93.29 in-doubt
ORA-02059: ORA_CRASH_TEST_7 in commit comment

この時点で、インダウト分散トランザクションがDBA_2PC_PENDINGビューに表示されます。対応している場合は、RECOがそのトランザクションを自動的に解決します。

RECOの有効化と無効化

Oracle DatabaseインスタンスのRECOバックグラウンド・プロセスは、分散トランザクションに伴う障害を自動的に解決します。ノードのRECOバックグラウンド・プロセスは、時間間隔を指数関数的に広げながら、インダウト分散トランザクションのローカル部分のリカバリを試みます。

RECOは、障害を起こしたトランザクションに関係している他のノードに対して、既存の接続を使用するか、または新しい接続を確立できます。接続が確立されると、RECOはすべてのインダウト・トランザクションを自動的に解決します。各データベースのペンディング・トランザクション表内にインダウト・トランザクションに対応している行があれば、自動的に削除されます。

ENABLE/DISABLE DISTRIBUTED RECOVERYオプションを指定してALTER SYSTEM文を使用すると、RECOを使用可能または使用禁止にできます。たとえば、RECOを一時的に使用禁止にして2フェーズ・コミットの障害を強制的に発生させ、インダウト・トランザクションを手動で解決できます。

次の文は、RECOを使用禁止にします。

ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY;

一方、次の文はRECOを使用可能にし、インダウト・トランザクションが自動的に解決されるようにします。

ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY;

読込み一貫性の管理

Oracle Databaseの分散読込み一貫性の実装には重要な制限事項があります。問題の原因は、各システムには独自のSCNがあり、データベースの内部的なタイムスタンプとして表示できることです。Oracle Databaseサーバーは、SCNを使用して、どのバージョンのデータが問合せから返されるかを判断します。

分散トランザクションのSCNは、各リモートSQL文の最後、および各トランザクションの最初と最後に同期化されます。2つのノード間の通信量が多く、特に分散更新がある場合には、この同期化が頻繁に実行されます。しかし、分散システムのSCNの絶対的な同期を保つための実用的な手段は存在しません。つまり、あるノードのSCNが別のノードのSCNと比べて幾分古くなるというような状況が常に存在します。

このようなSCNの食い違いから、実行した問合せがわずかに古いスナップショットを使用する可能性があり、その問合せ結果には、リモート・データベースに対する最新の変更が含まれていません。そのため、問合せを実行したときに、読込み一貫性に従ってデータが取得されているにもかからわず、そのデータが古い場合があります。そのような問合せによって取得したデータはすべて古いSCNに基づいているため、ローカルに実行した更新トランザクションによってリモート・ノードの2つの表が更新された場合、次回のリモート・アクセスで両方の表から選択したデータには、更新前のデータが含まれることになります。

SCNが食い違っているために起こりうる結果の1つとして、SELECT文が2つ連続している場合に、それら2つの文の間でDMLをまったく実行していなくても各文で異なるデータが取得されることがあります。たとえば、UPDATE文を発行して、リモート・データベースで更新をコミットしたとします。このリモート表に基づくビューに対してSELECT文を発行すると、ビューには更新された行が表示されません。次にSELECT文を発行するときは、更新された行が表示されます。

次の手法を使用すると、問合せの直前に2つのシステムのSCNが必ず同期化されます。

- SCNはリモート問合せの最後に同期化されるので、各リモート問合せの前に、同じサイトでSELECT * FROM DUAL@REMOTEというようなダミーのリモート問合せを実行します。

- SCNはすべてのリモート・トランザクションの最初に同期化されるので、リモート問合せを発行する前に、現行トランザクションをコミットまたはロールバックします。

第VI部

付録

第VI部には、Oracle Database管理者ガイドの付録が含まれます。次の章で構成されます。

- 付録A「Oracle Database 11gリリース2におけるDBMS_JOBのサポート」

A Oracle Database 11gリリース2におけるDBMS_JOBのサポート

この付録の内容は、次のとおりです。

- DBMS_JOBの概要

- DBMS_JOBからOracle Schedulerへの移行

DBMS_JOBの概要

DBMS_JOBは、ジョブのスケジュールに使用するPL/SQLパッケージです。これは、より強力で柔軟性のあるOracle Schedulerに置き換えられています。DBMS_JOBからOracle Schedulerに切り替えることをお薦めしますが、下位互換性を保つために、DBMS_JOBもサポートされています。

DBMS_JOBの構成

JOB_QUEUE_PROCESSES初期化パラメータには、ジョブの実行用に作成できるプロセスの最大数を指定します。Oracle Database 11gリリース1以降では、JOB_QUEUE_PROCESSESのデフォルトが1000になっています。ジョブ・コーディネータ・プロセスは、実行されるジョブ数と使用可能なリソースに基づいて、必要な数のジョブ・キュー・プロセスのみを起動します。JOB_QUEUE_PROCESSESにより低い数字を設定すると、ジョブ・キュー・プロセスの数を制限できます。

JOB_QUEUE_PROCESSESを0に設定すると、DBMS_JOBジョブおよびDBMS_SCHEDULERジョブが使用不可になります。

DBMS_JOBとOracle Schedulerの使用

DBMS_JOBとOracle Scheduler(スケジューラ)は、同じジョブ・コーディネータを使用して、ジョブ・スレーブを起動します。JOB_QUEUE_PROCESSES初期化パラメータを使用すると、DBMS_JOBとスケジューラの両方のジョブ・スレーブ数を制限できます。

JOB_QUEUE_PROCESSESが0の場合、DBMS_JOBとOracle Schedulerジョブの両方が無効になります。

関連項目:

- 第29章「Oracle Schedulerを使用したジョブのスケジューリング」

- 「スケジューラのプリファレンスの設定」

- JOB_QUEUE_PROCESSES初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

DBMS_JOBからOracle Schedulerへの移行

この項では、DBMS_JOBパッケージで作成されたジョブを取得し、DBMS_SCHEDULERパッケージを構成して制御するOracle Schedulerを使用してそれらをリライトする方法の例をいくつか示します。

ジョブの作成

次は、DBMS_JOBを使用してジョブを作成する例です。

VARIABLE jobno NUMBER;
BEGIN
DBMS_JOB.SUBMIT(:jobno, 'INSERT INTO employees VALUES (7935, ''SALLY'',
''DOGAN'', ''sally.dogan@examplecorp.com'', NULL, SYSDATE, ''AD_PRES'', NULL,
NULL, NULL, NULL);', SYSDATE, 'SYSDATE+1');
COMMIT;
END;
/

DBMS_SCHEDULERを使用した等価の文は、次のようになります。

BEGIN
DBMS_SCHEDULER.CREATE_JOB(
job_name          =>  'job1',
job_type          =>  'PLSQL_BLOCK',
job_action        =>  'INSERT INTO employees VALUES (7935, ''SALLY'',
''DOGAN'', ''sally.dogan@examplecorp.com'', NULL, SYSDATE,''AD_PRES'', NULL,
NULL, NULL, NULL);',
start_date        =>  SYSDATE,
repeat_interval   =>  'FREQ = DAILY; INTERVAL = 1');
END;
/

ジョブの変更

次は、DBMS_JOBを使用してジョブを変更する例です。

BEGIN
DBMS_JOB.WHAT(31, 'INSERT INTO employees VALUES (7935, ''TOM'', ''DOGAN'',
''tom.dogan@examplecorp.com'', NULL, SYSDATE,''AD_PRES'', NULL,
NULL, NULL, NULL);',
COMMIT;
END;
/

この文では、別の値を挿入するようにJOB1の処理が変更されます。DBMS_SCHEDULERを使用した等価の文は、次のようになります。

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE(
name          => 'JOB1',
attribute     => 'job_action',
value         => 'INSERT INTO employees VALUES (7935, ''TOM'', ''DOGAN'',
''tom.dogan@examplecorp.com'', NULL, SYSDATE, ''AD_PRES'', NULL,
NULL, NULL, NULL);',
END;
/

ジョブ・キューからのジョブの削除

次の例では、DBMS_JOBを使用してジョブを削除します。14144は実行されているジョブの番号です。

BEGIN
DBMS_JOB.REMOVE(14144);
COMMIT;
END;
/

DBMS_SCHEDULERを使用して、かわりに次のような文を発行します。

BEGIN
DBMS_SCHEDULER.DROP_JOB('myjob1');
END;
/

関連項目:

- DBMS_SCHEDULERパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 第29章「Oracle Schedulerを使用したジョブのスケジューリング」

索引
A B C D E F G H I J K L M N O P Q R S T U V W X

数字

2.3.11

2.3.11

A

異常終了時のエラー, 34.3.1.1.3

2フェーズ・コミット, 34.3.1.1.3

アカウント

DBAオペレーティング・システム・アカウント, 1.5.1

ユーザーSYSおよびSYSTEM, 1.5.2

ADD LOGFILE句

ALTER DATABASE文, 12.3.1

ADD LOGFILE MEMBER句

ALTER DATABASE文, 12.3.2

追加

列, 20.6.6

圧縮表の列, 20.6.6.1

ADMIN_TABLESプロシージャ

admin表の作成, 25.3.1.1

DBMS_REPAIRパッケージ, 25.2.1

例, 25.4.1.1, 25.4.1.2

ADMINISTER_RESOURCE_MANAGERシステム権限, 27.1.3 管理

スケジューラ, 30

管理

分散データベース, 32

管理者パスワード、パスワード・ファイルとデータ・ディクショナリの同期, 1.7.2 ADR

「自動診断リポジトリ」を参照

ADRベース, 9.1.4 ADRホーム, 9.1.4 ADRCIユーティリティ, 9.1.3.6 アドバイザ

データ修復, 9.1.1

UNDO, 16.4

AFTER SUSPENDシステム・イベント, 19.2.4.1 AFTER SUSPENDトリガー, 19.2.4.1

登録の例, 19.2.6

エージェント

異機種間サービス定義, 31.1.2

集計関数

分散データベースでの文の透過性, 32.7

アラート・ログ, 9.1.3.2

説明, 8.1.1

サイズ, 8.1.1.1

使用, 8.1.1

表示, 9.5

書き込む時期, 8.1.1.2

アラートしきい値

ローカル管理表領域の設定, 19.1.1

アラート

サーバー生成, 8.1.2

しきい値ベース, 8.1.2

表示, 19.1.2

ALL_DB_LINKSビュー, 32.5.1, 32.5.1 割当て

エクステント, 20.6.4

ALTER CLUSTER文

ALLOCATE EXTENT句, 22.4

ハッシュ・クラスタに使用, 23.4

索引クラスタに対して使用, 22.4

ALTER DATABASE ADD LOGFILE文

Oracle Managed Filesの使用, 17.3.6.1

ALTER DATABASE文

ADD LOGFILE句, 12.3.1

ADD LOGFILE MEMBER句, 12.3.2

ARCHIVELOG句, 13.3.2

CLEAR LOGFILE句, 12.8

CLEAR UNARCHIVED LOGFILE句, 12.2.1.1

データファイルのオンライン化またはオフライン化, 15.4.3

ユーザーが部分的に使用可能なデータベース, 3.2.1

DATAFILE...OFFLINE DROP句, 15.4.2

DROP LOGFILE句, 12.5.1

DROP LOGFILE MEMBER句, 12.5.2

MOUNT句, 3.2.1

NOARCHIVELOG句, 13.3.2

OPEN句, 3.2.2

READ ONLY句, 3.2.3

RENAME FILE句, 15.5.2

一時ファイルのオンライン化またはオフライン化, 15.4.3

UNRECOVERABLE DATAFILE句, 12.8

ALTER INDEX文

COALESCE句, 21.2.12

MONITORING USAGE句, 21.4.6

ALTER SEQUENCE文, 24.2.3 ALTER SESSION

再開可能領域割当ての有効化, 19.2.2.2

ALTER SESSION文

ADVISE句, 35.4.3.3

CLOSE DATABASE LINK句, 33.2

SET SQL_TRACE初期化パラメータ, 8.1.1.2

タイム・ゾーンの設定, 2.4.9.1

ALTER SYSTEM文

ARCHIVE LOG ALL句, 13.3.3

DISABLE DISTRIBUTED RECOVERY句, 35.9.2

ENABLE DISTRIBUTED RECOVERY句, 35.9.2

ENABLE RESTRICTED SESSION句, 3.2.4

データベース・リソース・マネージャの使用可能化, 27.6

QUIESCE RESTRICTED, 3.4.1

RESUME句, 3.5

SETのSCOPE句, 2.6.5.1

SET RESOURCE_MANAGER_PLAN, 27.6

SET SHARED_SERVERS初期化パラメータ, 5.3.3.2

初期化パラメータの設定, 2.6.5

SUSPEND句, 3.5

SWITCH LOGFILE句, 12.6

UNQUIESCE, 3.4.2

ALTER TABLE文

ADD(列)句, 20.6.6

ALLOCATE EXTENT句, 20.6.4

DEALLOCATE UNUSED句, 20.6.4

DISABLE ALL TRIGGERS句, 18.4.2

DISABLE整合性制約句, 18.5.3.1

DROP COLUMN句, 20.6.8.1

DROP整合性制約句, 18.5.3.3

DROP UNUSED COLUMNS句, 20.6.8.2

ENABLE ALL TRIGGERS句, 18.4.1

ENABLE整合性制約句, 18.5.3.1, 18.5.3.1

外部表, 20.13.3

MODIFY(列)句, 20.6.5

索引構成表の属性の変更, 20.12.3.1

MOVE句, 20.6.3, 20.6.3, 20.12.3.2

使用する理由, 20.6.1

RENAME COLUMN句, 20.6.7

SET UNUSED句, 20.6.8.2

ALTER TABLESPACE文

Oracle Managed Filesのデータファイルの追加, 例, 17.3.3.3

Oracle Managed Filesの一時ファイルの追加, 例, 17.3.4.2

ONLINE句、例, 14.5.2

READ ONLY句, 14.6.1

READ WRITE句, 14.6.2

RENAME DATAFILE句, 15.5.1.1

RENAME TO句, 14.8

データファイル/一時ファイルのオンライン化/オフライン化, 15.4.3

ALTER TRIGGER文

DISABLE句, 18.4.2

ENABLE句, 18.4.1

変更

イベント・スケジュール, 29.5.2.4

イベントベースのジョブ, 29.5.2.2

索引, 21.4

ジョブ・クラス, 29.7.1.3

ジョブ, 29.2.3

プログラム, 29.3.3

(スケジューラ)ウィンドウ, 29.7.3.3

スケジュール, 29.4.3

ANALYZE文

CASCADE句, 18.2.2

CASCADE句, FASTオプション, 18.2.2

破損のレポート, 25.3.1.3

連鎖行のリスト, 18.2.3

リモート表, 33.4.2.2.2

構造の妥当性チェック, 18.2.2, 25.3.1

スキーマ・オブジェクトの分析, 18.2 表の分析

分散処理, 33.4.2.2.2

APPENDヒント, 20.2.6.1 アプリケーションの開発

分散データベース, 31.5, 33, 33.5

分散データベースのアプリケーション開発, 33

実行計画の分析, 33.4.4

データベース・リンク, 接続の制御, 33.2

エラーの処理, 33.3, 33.5

リモート・プロシージャのエラーの処理, 33.5

データ分散の管理, 33.1

参照整合性制約の管理, 33.3

リモート接続の終了, 33.2

分散問合せのチューニング, 33.4

連結インライン・ビューを使用したチューニング, 33.4.1

コストベースの最適化の使用, 33.4.2

ヒントを使用した問合せのチューニング, 33.4.3

ARCHIVE_LAG_TARGET初期化パラメータ, 12.2.6.1 アーカイブREDOログ

代替アーカイブ先, 13.4.3

アーカイブ・モード, 13.3.2

データ・ディクショナリ・ビュー, 13.8.1

アーカイブ先の可用性の状態、制御, 13.4.2

アーカイブ先の状態, 13.4.2

アーカイブ先、指定, 13.4

障害アーカイブ先, 13.6

必須のアーカイブ先, 13.6.1.1

アーカイブ先の最小数, 13.6.1

多重化, 13.4.1

通常転送, 13.5

障害アーカイブ先への再アーカイブ, 13.6.2

アーカイブ先の使用例, 13.6.1.2

スタンバイ転送, 13.5

ステータス情報, 13.8.1

転送, 13.5

ARCHIVELOGモード, 13.2.2

利点, 13.2.2

アーカイブ, 13.2

自動アーカイブ, 13.2.2

定義, 13.2.2

分散データベース, 13.2.2

使用可能化, 13.3.2

手動アーカイブ, 13.2.2

実行, 13.2.2

切替え, 13.3.2

データファイルのオフラインとオンラインの切替え, 15.4.1

アーカイバ・プロセス

トレース出力(制御), 13.7

アーカイバ・プロセス(ARCn), 5.5 アーカイブ

代替アーカイブ先, 13.4.3

アーカイブ・モードの変更, 13.3.2

プロセス数の制御, 13.3.4

アーカイブ先の可用性の状態、制御, 13.4.2

アーカイブ先の障害, 13.6

アーカイブ先の状態, 13.4.2

手動, 13.3.3, 13.3.3

NOARCHIVELOGモード対ARCHIVELOGモード, 13.2

初期モードの設定, 13.3.1

障害アーカイブ先へ, 13.6.2

トレース出力、制御, 13.7

情報の表示, 13.8.1

アットマーク, 2.3.11 監査

データベース・リンク, 31.3.3

認証

データベース・リンク, 31.3.2.1

オペレーティング・システム, 1.6.3.2

方式の選択, 1.6.2

パスワード・ファイルの使用, 1.6.4.1

AUTO_TASK_CONSUMER_GROUP

リソース・マネージャ, 26.5

AUTOEXTEND, 15.3.1 AUTOEXTEND句

bigfile表領域, 14.7.3

自動診断リポジトリ, 9.1.1, 9.1.3.1

Oracle Client, 9.1.4

Oracle Real Application Clustersにおける, 9.1.4

構造, 内容および場所, 9.1.4

自動ファイル拡張, 15.3.1 自動メンテナンス・タスク

メンテナンス・ウィンドウへの割当て, 26.3.2

定義, 26.1

有効化と無効化, 26.3.1

事前定義, 26.1

リソース割当て, 26.5.1

スケジューラのジョブ名, 26.2

自動メモリー管理, 6.1

説明, 6.3.1

使用可能化, 6.3.2

サポートされるプラットフォーム, 6.6.1

自動セグメント領域管理, 14.2.1.2 自動UNDO管理, 2.4.4, 16.2, 16.2

移行, 16.6

B

バックグラウンド・プロセス, 5.5

FMON, 15.9.2.1.1

BACKGROUND_DUMP_DEST初期化パラメータ, 9.1.3.1 バックアップ

データベースの新規作成後, 2.3.13

アーカイブの影響, 13.2.1

バッチ・ジョブ, ユーザーの認証, 2.8.3 bigfile表領域

作成, 14.2.2.1

一時表領域の作成, 14.2.5.2

説明, 14.2.2

データベースのデフォルトの設定, 2.4.8.1

BLANK_TRIMMING初期化パラメータ, 20.6.5 BLOBデータ型, 20.3.1 ブロック・サイズ、REDOログ・ファイル, 12.2.4 BLOCKSIZE句

CREATE TABLESPACE, 14.3

バッファ・キャッシュ

拡張バッファ・キャッシュ(32ビット), 6.4.2.8.3

複数バッファ・プール, 6.4.2.2.2

バッファ・プール, 6.4.2.2.2 BUFFER_POOL_KEEP初期化パラメータ, 6.4.2.2.2 BUFFER_POOL_RECYCLE初期化パラメータ, 6.4.2.2.2 バッファ

SGAのバッファ・キャッシュ, 6.4.2.2

C

CACHEオプション

CREATE SEQUENCE文, 24.2.4.2.2

キャッシュ

バッファ

複数バッファ・プール, 6.4.2.2.2

順序番号, 24.2.4.2 カレンダ指定式, 29.4.5.1 カレンダ構文, 29.4.5.1 コール

リモート・プロシージャ, 31.5.2

容量計画

領域管理

容量計画, 19.7

CASCADE句

一意キーまたは主キーの削除時, 18.5.3.1

CATBLOCK.SQLスクリプト, 8.2.1 ユーザーの集中管理

分散システム, 31.3.2.4

チェーン条件構文, 29.6.4 チェーン・ルール, 29.6.4 チェーン・ステップ

定義, 29.6.3

連鎖行

表からの除去, 手順, 18.2.3.2

CHAINED_ROWS表

ANALYZE文による使用, 18.2.3.1

チェーン

作成, 29.6.2

ジョブの作成および管理, 29.6

ジョブの作成, 29.6.6

無効化, 29.6.10

削除, 29.6.7

ルールの削除, 29.6.9

有効化, 29.6.5

停止状態の処理, 29.6.18

実行中の監視, 29.6.17

概要, 28.2.7

一時停止, 29.6.14

実行, 29.6.8

権限の設定, 30.1.1

手順

一時停止, 29.6.14

スキップ, 29.6.15

停止, 29.6.12 個々のステップの停止, 29.6.13 変更ベクトル, 12.1.2 CHARデータ型

列の長さの拡張, 20.6.5

キャラクタ・セット

選択, 2.1.1.1

CHECK_OBJECTプロシージャ

DBMS_REPAIRパッケージ, 25.2.1

例, 25.4.2

破損の範囲の検索, 25.3.2

チェックポイント・プロセス(CKPT), 5.5 チェックサム

データ・ブロック, 15.7

REDOログ・ブロック, 12.7, 12.7

CLEAR LOGFILE句

ALTER DATABASE文, 12.8, 12.8

REDOログ・ファイルの初期化, 12.2.1.1, 12.8 クライアント/サーバー・アーキテクチャ

分散データベース, 31.1.3, 31.1.3

グローバリゼーション・サポート, 31.6.1

CloneDB, 2.9 clonedb.pl Perlスクリプト, 2.9.2 クローニング

データベース, 1.2.11, 2.9

Oracleホーム, 1.2.11

CLOSE DATABASE LINK句

ALTER SESSION文, 33.2

データベース・リンクのクローズ, 32.4.1 ウィンドウのクローズ, 29.7.3.5 クラスタ

説明, 22.1

エクステントの割当て, 22.4

変更, 22.4

分析, 18.2

クラスタ索引, 22.5

クラスタ・キー, 22.1, 22.2.2, 22.2.3

クラスタ化表, 22.1, 22.2.1, 22.3.1, 22.4.1, 22.5.1

クラスタ・キーの列, 22.2.2

作成, 22.3

データ・ディクショナリ・ビューの参照, 22.6

エクステントの割当て解除, 22.4

削除, 22.5

領域の見積り, 22.2.3, 22.2.5

管理のガイドライン, 22.2

ハッシュ・クラスタ, 23

位置, 22.2.4

権限, 22.3, 22.4, 22.5.1

表の選択, 22.2.1

単一表ハッシュ・クラスタ, 23.3.2

切捨て, 18.3

構造の妥当性チェック, 18.2.2

索引の結合

コスト, 21.2.12

コールド・バックアップ

デタッチ済Oracle Schedulerジョブを使用して実行, 29.2.2.7

連結インライン・ビュー

分散問合せのチューニング, 33.4.1

列の暗号化, 2.8.2 列

追加, 20.6.6

圧縮表への追加, 20.6.6.1

情報の表示, 20.14

削除, 20.6.8, 20.6.8.3

圧縮表での削除, 20.6.8.4

暗号化, 20.2.7, 20.6.3

長さの拡張, 20.6.5

定義の変更, 20.6.5

名前変更, 20.6.7

仮想, 20.1

仮想, 索引付け, 21.2.2

コマンド

発行, 1.3

COMMENT文, 20.14 コメント

問題のアクティビティ・ログへの追加, 9.2.7

COMMIT COMMENT文

分散トランザクションとの使用, 35.2, 35.4.3.2

コミット・フェーズ, 34.3.1, 34.5.4

2フェーズ・コミット, 34.3.2, 34.3.2.2

コミット・ポイント・サイト, 34.2.5

コミット・ポイント強度, 34.2.5.2, 35.1

判断, 34.2.5.2

分散トランザクション, 34.2.5, 34.2.5.2

データベースによる決定方法, 34.2.5.2

コミット・ポイント強度

定義, 34.2.5.2

指定, 35.1

COMMIT文

FORCE句, 35.5, 35.5.1.1, 35.5.2

強制的, 35.4.2

2フェーズ・コミット, 31.4.6

COMMIT_POINT_STRENGTH初期化パラメータ, 34.2.5.2, 35.1 トランザクションのコミット

分散トランザクションのコミット・ポイント・サイト, 34.2.5

互換性レベル, 2.5.9 COMPATIBLE初期化パラメータ, 2.5.9 コンポーネント

srvctlコンポーネント名と略称, 4.4

圧縮表

列の追加, 20.6.6.1

列の削除, 20.6.8.4

圧縮

レベル, 20.2.6

圧縮、表, 20.2.6 圧縮、表領域, 14.2.3 構成

Oracleデータベース, 2

Oracle Scheduler, 30.1

CONNECTコマンド

インスタンスの起動, 3.1.4

CONNECT INTERNAL

サポートの終了, 1.6.2

CONNECT文, SQL*Plus, 1.3.2.4 接続ユーザー・データベース・リンク, 32.2.3.2

メリットおよびデメリット, 31.2.7.1

定義, 31.2.7

例, 31.2.8

REMOTE_OS_AUTHENT初期化パラメータ, 31.2.7.1

接続

SQL*Plusを使用, 1.3.2

接続修飾子

データベース・リンク, 32.2.4

接続

リモートの終了, 33.2

制約

表作成時に使用禁止, 18.5.2.1

分散システム・アプリケーション開発の問題, 33.3

整合性制約の削除, 18.5.3.3

妥当性チェックなしで使用可能な状態, 18.5.1.3

使用可能にする例, 18.5.2.2

違反が存在する場合に使用可能にする, 18.5.1.3

例外, 18.5.1.2, 18.5.5

整合性制約の例外, 18.5.5

整合性制約の状態, 18.5.1

使用禁止時の索引の保持, 18.5.3

削除時の索引の保持, 18.5.3

ORA-02055制約違反, 33.3

名前変更, 18.5.3.2

表作成時に設定, 18.5.2

使用禁止にするとき, 18.5.1.1

「整合性制約」も参照

制御ファイル

追加, 11.3.2

サイズの変更, 11.3.1

データ・ディクショナリとの不一致, 11.4.1

作成, 11.1, 11.3, 11.3.3.2

Oracle Managed Filesとして作成, 17.3.5

Oracle Managed Filesとして作成, 例, 17.5.1

データ・ディクショナリ・ビューの参照, 11.8

デフォルト名, 2.5.4, 11.3.1

削除, 11.7

作成中のエラー, 11.4.2

ガイドライン, 11.2

多重制御ファイルの重要性, 11.2.2

初期作成, 11.3.1

位置, 11.2.2

ログ順序番号, 12.1.3.2

ミラー化, 2.5.4, 11.2.2

移動, 11.3.2

多重, 11.2.2

名前, 11.2.1

数, 11.2.2

既存のファイルの上書き, 2.5.4

再配置, 11.3.2

名前変更, 11.3.2

1つは必要, 11.1

サイズ, 11.2.4

データベース作成前に名前を指定, 2.5.4

トラブルシューティング, 11.4

起動時に使用不可能, 3.1.5

CONTROL_FILES初期化パラメータ

既存の制御ファイルの上書き, 2.5.4

ファイル名の指定, 11.2.1

データベース作成時, 2.5.4, 11.3.1

CONTROLFILE REUSE句, 2.5.4 ジョブのコピー, 29.2.9 coraenvおよびoraenv, 1.3.2.2 コア・ファイル, 9.1.3.3 破損

データ・ブロックの修復, 25.1

コストベースの最適化, 33.4.2

分散データベース, 31.5.3

ヒント, 33.4.3

分散問合せに対する使用, 33.4.2

CREATE BIGFILE TABLESPACE文, 14.2.2.1 CREATE BIGFILE TEMPORARY TABLESPACE文, 14.2.5.2 CREATE CLUSTER文

クラスタの作成, 22.3

例, 22.3

ハッシュ・クラスタ, 23.3

HASH IS句, 23.3, 23.3.3.2

HASHKEYS句, 23.3, 23.3.3.4

SIZE句, 23.3.3.3

CREATE CONTROLFILE文

説明, 11.3.3.2

不整合の検出, 11.4.1

Oracle Managed Filesとして作成, 例, 17.3.5, 17.5.1

NORESETLOGS句, 11.3.3.3

Oracle Managed Files, 使用, 17.3.5

RESETLOGS句, 11.3.3.3

CREATE DATABASE LINK句, 32.2.2.1 CREATE DATABASE文

CONTROLFILE REUSE句, 11.3.1

DEFAULT TEMPORARY TABLESPACE句, 2.3.9, 2.4.6

データベースの作成の例, 2.3.9

EXTENT MANAGEMENT LOCAL句, 2.4.2

MAXLOGFILESパラメータ, 12.2.5

MAXLOGMEMBERSパラメータ, 12.2.5, 12.2.5

SYS用のパスワード, 2.4.1

SYSTEM用のパスワード, 2.4.1

タイム・ゾーンの設定, 2.4.9.1

FORCE LOGGINGの指定, 2.4.10

SYSAUX DATAFILE句, 2.3.9

UNDO TABLESPACE句, 2.3.9, 2.4.4

UNDO表領域の作成, 16.5.1.1

Oracle Managed Filesの使用, 17.3.2

Oracle Managed Filesの使用, 例, 17.3.2.6, 17.5.1, 17.5.2

CREATE INDEX文

NOLOGGING, 21.2.10

ON CLUSTER句, 22.3.2

使用, 21.3.1

制約の指定, 21.3.3.1

CREATE PFILE FROM MEMORYコマンド, 2.6.7 CREATE SCHEMA文

複数の表とビュー, 18.1

CREATE SEQUENCE文, 24.2.2

CACHEオプション, 24.2.4.2.2

例, 24.2.4.2.2

NOCACHEオプション, 24.2.4.2.2

CREATE SPFILE文, 2.6.3 CREATE SYNONYM文, 24.3.2 CREATE TABLE文

AS SELECT句, 20.2.4, 20.3.3

CLUSTER句, 22.3.1

COMPRESS句, 20.12.2.7

一時表の作成, 20.3.2

例, 20.3.1

INCLUDING句, 20.12.2.5

索引構成表, 20.12.2

MONITORING句, 20.5

NOLOGGING句, 20.2.5

ORGANIZATION EXTERNAL句, 20.13.2

パラレル化, 20.3.3

PCTTHRESHOLD句, 20.12.2.4

TABLESPACE句、指定, 20.2.3

CREATE TABLESPACE文

BLOCKSIZE句、使用, 14.3

FORCE LOGGING句、使用, 14.4

Oracle Managed Filesの使用, 17.3.3

Oracle Managed Filesの使用, 例, 17.3.3.1

CREATE TEMPORARY TABLESPACE文, 14.2.5.1

Oracle Managed Filesの使用, 17.3.4

Oracle Managed Filesの使用, 例, 17.3.4.1

CREATE UNDO TABLESPACE文

Oracle Managed Filesの使用, 17.3.3

Oracle Managed Filesの使用, 例, 17.3.3.2

UNDO表領域の作成, 16.5.1.2

CREATE UNIQUE INDEX文

使用, 21.3.2

CREATE VIEW文

説明, 24.1.2

OR REPLACE句, 24.1.3

WITH CHECK OPTION, 24.1.2, 24.1.4

CREATE_SIMPLE_PLANプロシージャ

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

作成

Oracleデータベース, 2

チェーン, 29.6.2

制御ファイル, 11.3

データベース・サービス, 2.7.2

データベース, 2.1

イベント・スケジュール, 29.5.2.3

イベントベースのジョブ, 29.5.2.1

索引, 21.3

表データ挿入後, 21.2.1

整合性制約との対応付け, 21.3.3

NOLOGGING, 21.2.10

オンライン, 21.3.5

USING INDEX句, 21.3.3.1

ジョブ・クラス, 29.7.1.2 ジョブ, 29.2.2 プログラム, 29.3.2 スケジューラのウィンドウ, 29.7.3.2 スケジュール, 29.4.2 順序, 24.2.4.2.2, 24.2.4.2.2 ウィンドウ・グループ, 29.7.4.2 データファイルの作成, 15.2 データベース・リンクの作成, 32.2

接続ユーザー, 32.2.3.2.1

接続ユーザーの使用例, 32.8.3

現行ユーザー, 32.2.3.2.2

現行ユーザーの使用例, 32.8.5

例, 31.2.8

固定ユーザー, 32.2.3.1

固定ユーザーの使用例, 32.8.1, 32.8.2

必要な権限の取得, 32.2.1

プライベート, 32.2.2.1

パブリック, 32.2.2.2

リンク名内部のサービス名, 32.2.4

共有, 32.3

共有接続ユーザーの使用例, 32.8.4

タイプの指定, 32.2.2

データベースの作成

新しいデータベースのバックアップ, 2.3.13

デフォルト一時表領域, 指定, 2.4.6

例, 2.3.9

スクリプトによる手動, 2.1

デフォルト表領域タイプの上書き, 2.4.8.2

計画, 2.1.1

準備, 2.1.1

前提条件, 2.1.1.2

デフォルトの表領域タイプの設定, 2.4.8.1

bigfile表領域の指定, 2.4.8, 2.4.8.2

UNDO TABLESPACE句, 2.4.4

新リリースへのアップグレード, 2.1

Oracle Managed Filesの使用, 2.4.7, 17.3.2

DBCAを使用, 2.2

ローカル管理表領域, 2.4.2

順序の作成, 24.2.2 シノニムの作成, 24.3.2 ビューの作成, 24.1.2 資格証明, Oracle Scheduler

説明, 28.2.6

作成, 29.2.2.3.2

権限の付与, 28.2.6

クリティカル・エラー

診断, 9.1.1

CRSCTLユーティリティ

Oracle Restart, 4.1.4

現行ユーザー・データベース・リンク

メリットおよびデメリット, 31.2.7.3

共有スキーマではアクセスできない, 31.3.2.4.2

定義, 31.2.7

例, 31.2.8

スキーマへの非依存性, 31.3.2.4.2

CURRVAL疑似列, 24.2.4.1

制限, 24.2.4.1.3

カーソル

データベース・リンクのクローズ, 33.2

「パッケージのカスタマイズ」ページ, アクセス, 9.10.3.2 インシデント・パッケージのカスタマイズ, 9.10.3, 9.10.3.2

D

データ

外部表を使用したロード, 20.13.2

データ・ブロックの破損

修復, 25.1

データ・ブロック

サイズの変更, 2.5.5.1

非標準ブロック・サイズ, 2.5.5.2

クラスタで共有される, 22.1

サイズの指定, 2.5.5

標準ブロック・サイズ, 2.5.5

検証, 15.7

データ・ディクショナリ

制御ファイルとの不一致, 11.4.1

保留行のパージ, 35.6, 35.6.2

「ビュー」, 「データ・ディクショナリ」も参照

データの暗号化

分散システム, 31.3.2.5

データファイル・ヘッダー

表領域の名前変更時, 14.8

データファイル

表領域への追加, 15.2

オンラインとオフラインの切替え, 15.4

対応付けられた表領域のチェック, 14.14.2

データベースを使用したコピー, 15.8

作成, 15.2

Oracle Managed Filesの作成, 17.3, 17.3.6.2

データ・ディクショナリ・ビューの参照, 15.10

データベース管理者によるアクセス, 1.5.1

デフォルト・ディレクトリ, 15.2

定義, 15.1

削除, 14.9

削除, 15.4.2, 15.6

Oracle Managed Filesの削除, 17.4.1

ファイル番号, 15.1

ファイル名を完全に指定, 15.2

管理のガイドライン, 15.1

表領域の名前変更時のヘッダー, 14.8

OSファイル名の識別, 15.5.1.2

位置, 15.1.3

ファイルと物理デバイスのマッピング, 15.9

最小数, 15.1.1

MISSING, 11.4.1

オンライン, 15.4.2

Oracle Managed, 17

再配置, 15.5

名前変更, 15.5

再利用, 15.2

サイズ, 15.1.2

作成する文, 15.2

REDOログ・ファイルから分離した格納, 15.1.4

データベースのオープン時に使用不可能, 3.1.5

データ・ブロックの検証, 15.7

データ操作言語

分散トランザクションで許可される文, 31.4.1

データ・リカバリ・アドバイザ, データ破損の修復, 9.9 データ修復アドバイザ, 9.1.1 データベース

クローニング, 1.2.11, 2.9

作成, 2.1

作成および構成, 2

DBCAを使用した作成, 2.2

データ・ディクショナリ・ビューの参照, 2.11

起動, 3.1

データベース管理者

DBAロール, 1.5.2.3

オペレーティング・システム・アカウント, 1.5.1

パスワード・ファイル, 1.6.2.1

役割, 1.1.1

セキュリティと権限, 1.5

セキュリティ管理者との関係, 7.1

SYSおよびSYSTEMアカウント, 1.5.2

タスクの定義, 1.2

ユーティリティ,1.8

データベース・バッファ

複数バッファ・プール, 6.4.2.2.2

Database Configuration Assistant, 2.1

共有サーバー構成, 5.3.4

宛先データベース, Oracle Scheduler

説明, 28.2.4

作成, 29.2.2.3.3

データベース・ジョブ, Oracle Scheduler, 28.3.1.1 データベース・リンク

利点, 31.2.3

監査, 31.3.3

認証, 31.3.2.1

パスワードなしの認証, 31.3.2.2

クローズ, 32.4.1, 33.2

接続ユーザー, 31.2.7, 31.2.7.1, 32.2.3.2, 32.8.3

接続, オープンの判断, 32.5.2

接続の制御, 33.2

作成, 32.2, 32.8.1, 32.8.3, 32.8.4, 32.8.5

共有の作成, 32.3.2

作成, 例, 31.2.8

作成, 使用例, 32.8

現行ユーザー, 31.2.7, 31.2.7.3, 32.2.3.2

データ・ディクショナリのUSERビュー, 32.5.1

定義, 31.2.1

分散問合せ, 31.4.2

分散トランザクション, 31.4.5

削除, 32.4.2

グローバル・ネーミングの施行, 32.1.2

エンタープライズ・ユーザー, 31.3.2.4.2

固定ユーザー, 31.2.7, 31.2.7.2, 32.8.1

グローバル, 31.2.6

グローバル名, 31.2.4

ループバック, 31.2.4.1

グローバル・オブジェクト名, 31.4.7 エラーの処理, 33.3 接続数の制限, 32.4.3 リスト, 32.5.1, 35.3.1, 35.3.2 ループバック, 31.2.4.1 管理, 32.4 ネットワーク接続数の最小化, 32.3 名前解決, 31.4.7 名前, 31.2.5 プライベート, 31.2.6 パブリック, 31.2.6 参照整合性, 33.3 リモート・トランザクション, 31.4.1, 31.4.4 解決, 31.4.7 制限, 31.2.10 リモート・データベースにおけるロール, 31.2.10 スキーマ・オブジェクト, 31.2.9 リンク名内部で使用するサービス名, 32.2.4 共有, 31.2.2, 32.3.1, 32.3.3, 32.3.3.1, 32.3.3.2 共有SQL, 31.4.3 スキーマ・オブジェクトのシノニム, 31.2.9.3 分散問合せのチューニング, 33.4 ヒントによる問合せのチューニング, 33.4.3 連結インライン・ビューを使用したチューニング, 33.4.1 リンクのタイプ, 31.2.6 ユーザーのタイプ, 31.2.7 ユーザー, 指定, 32.2.3 コストベースの最適化の使用, 33.4.2 表示, 32.5, 32.5.1 データベース・オブジェクト

増加傾向の取得, 19.7.3

データベース・プログラム・ユニット, 定義, 28.1 データベース常駐接続プーリング, 5.2

利点, 5.2

構成パラメータ, 5.4.2

接続プールの構成, 5.4.2

データ・ディクショナリ・ビューの参照, 5.4.3

使用禁止, 5.4.1

使用可能化, 5.4.1

制限, 5.2.2

トリガー, 5.2

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

キューイングを備えたアクティブ・セッション・プール, 27.3.5

システム権限の管理, 27.1.3

オペレーティング・システムの制御, 27.12

コンシューマ・グループの自動切替え, 27.3.6

CREATE_SIMPLE_PLANプロシージャ, 27.4

データ・ディクショナリ・ビューの参照, 27.13.3

説明, 27.1

使用可能化, 27.6

実行時間制限, 27.3.8

リソース割当て方法, 27.5.3, 27.5.4, 27.5.4, 27.5.4, 27.5.4, 27.5.4, 27.5.4, 27.5.4, 27.5.4

リソース・コンシューマ・グループ, 27.1.2, 27.2, 27.5.3

リソース・プラン・ディレクティブ, 27.1.2, 27.5.5, 27.5.6

リソース・プラン, 27.1.2, 27.1.2.6, 27.3.1, 27.4, 27.6, 27.6, 27.7, 27.7.5

UNDOプール, 27.3.9

データベースの静止に使用, 3.4

プラン・スキーマ変更の妥当性チェック, 27.5.6

データベース・サービス

説明, 2.7.1

自動起動の制御, 3.1.3

データ・ディクショナリ・ビュー, 2.7.3

アプリケーション・ワークロードの管理, 2.7

データベース・サービス、作成, 2.7.2 データベース・スマート・フラッシュ・キャッシュ

構成およびチューニング, 6.5

概要, 6.2

データベース・ライター・プロセス

データ・ブロックのチェックサムの計算, 15.7

データベース・ライター・プロセス(DBWn), 5.5 DATABASE_PROPERTIESビュー

デフォルト一時表領域の名前変更, 14.8

データベース

管理, 1

分散の管理, 32

可用性の変更, 3.2

バックアップ, 2.3.13

制御ファイル, 11.2

デフォルト一時表領域, 指定, 2.4.6

削除, 2.10

分散システムでのグローバル・データベース名, 2.5.2.2

データベースのマウント, 3.1.5.3

インスタンスへのマウント, 3.2.1

名前, 説明, 2.5.2.1

名前, 競合, 2.5.2.1

クローズしているデータベースのオープン, 3.2.2

計画, 1.2.3

作成計画, 2.1.1

静止, 3.4

読取り専用, オープン, 3.2.3

リカバリ, 3.1.5.6

名前変更, 11.3.3.1, 11.3.3.2, 11.3.3.3

アクセスの制限, 3.2.4

再開, 3.5

停止, 3.3

制御ファイルの指定, 2.5.4

一時停止, 3.5

UNDO管理, 2.4.4

アップグレード, 2.1

ローカル管理表領域, 2.4.2

DB_BLOCK_CHECKING初期化パラメータ, 25.3.1, 25.3.1.4 DB_BLOCK_CHECKSUM初期化パラメータ, 15.7

REDOブロックのチェックの使用可能化, 12.7

DB_BLOCK_SIZE初期化パラメータ, 6.4.2.2

非標準のブロック・サイズ, 14.3

設定, 2.5.5

DB_CACHE_SIZE初期化パラメータ, 6.4.2.2.1

複数のブロック・サイズの指定, 14.3

DB_CREATE_FILE_DEST初期化パラメータ, 17.2

設定, 17.2.1

DB_CREATE_ONLINE_LOG_DEST_n初期化パラメータ, 17.2

設定, 17.2.3

DB_DOMAIN初期化パラメータ

データベース作成の設定, 2.5.2, 2.5.2.2

DB_FILES初期化パラメータ

値の決定, 15.1.1.1

DB_KEEP_CACHE_SIZE初期化パラメータ, 6.4.2.2.2 DB_NAME初期化パラメータ

データベース作成前の設定, 2.5.2

DB_nK_CACHE_SIZE初期化パラメータ, 6.4.2.2.1

複数のブロック・サイズの指定, 14.3

トランスポータブル表領域の使用, 14.13.5.6

DB_RECOVERY_FILE_DEST初期化パラメータ, 17.2

設定, 17.2.2

DB_RECYCLY_CACHE_SIZE初期化パラメータ, 6.4.2.2.2 DB_UNRECOVERABLE_SCN_TRACKING初期化パラメータ, はじめに, 20.4.2.4.2 DBA

「データベース管理者」を参照

DBAロール, 1.5.2.3 DBA_2PC_NEIGHBORSビュー, 35.3.2

セッション・ツリーのトレースのための使用, 35.3.2

DBA_2PC_PENDINGビュー, 35.3.1, 35.6, 35.7.6

インダウト・トランザクションをリストするための使用, 35.3.1

DBA_DB_LINKSビュー, 32.5.1, 32.5.1, 32.5.1 DBA_RESUMABLEビュー, 19.2.4.1 DBA_UNDO_EXTENTSビュー

UNDO表領域エクステント, 16.7

DBCA

「Database Configuration Assistant」を参照

DBMS_FILE_TRANSFERパッケージ

データファイルのコピー, 15.7

DBMS_JOB

説明, A.1

Oracle Schedulerへのジョブの移行, A.2

DBMS_METADATAパッケージ

GET_DDLファンクション, 18.11.1

オブジェクト定義に使用, 18.11.1

DBMS_REDEFINITIONパッケージ

オンライン再定義の実行, 20.7.2

必要な権限, 20.7.9, 20.7.9

DBMS_REPAIR

論理的な破損, 25.3.2

DBMS_REPAIRパッケージ

例, 25.4

制限, 25.2.2

プロシージャ, 25.2.1

使用, 25.3, 25.4.5

DBMS_RESOURCE_MANAGERパッケージ, 27.1.2, 27.1.3, 27.2.4.1

プロシージャ(の表), 27.1.3

DBMS_RESOURCE_MANAGER_PRIVSパッケージ, 27.1.3

プロシージャ(の表), 27.1.3

DBMS_RESUMABLEパッケージ, 19.2.4.3 DBMS_SCHEDULER.GET_FILE、外部ジョブのstdout取得に使用, 29.2.2.9 DBMS_SERVER_ALERTパッケージ

アラートしきい値の設定, 19.1

DBMS_SPACEパッケージ, 19.3.4

未使用領域に関する例, 19.6.1

FREE_BLOCKプロシージャ, 19.6.1

SPACE_USAGEプロシージャ, 19.6.1

UNUSED_SPACEプロシージャ, 19.6.1

DBMS_SPACE_ADMIN

DROP_EMPTY_SEGMENTSプロシージャ, 19.4

MATERIALIZE_DEFERRED_SEGMENTSプロシージャ, 20.2.9

DBMS_STATSパッケージ, 18.2.1

CREATE TABLEのMONITORING句, 20.5

DBMS_STORAGE_MAPパッケージ

ファイル・マッピング用に起動, 15.9.3.1

マッピング情報を表示するビュー, 15.9.3.3

DBMS_TRANSACTIONパッケージ

PURGE_LOST_DB_ENTRYプロシージャ, 35.6.1

DBVERIFYユーティリティ, 25.3.1, 25.3.1.2 DDLロック・タイムアウト, 2.5.7 DDL_LOCK_TIMEOUT初期化パラメータ, 2.5.7 DEALLOCATE UNUSED句, 19.3.4 未使用領域の割当て解除, 19.3

DBMS_SPACEパッケージ, 19.3.4

DEALLOCATE UNUSED句, 19.3.4

宣言参照整合性の制約, 33.3 専用サーバー・プロセス, 5.1.1

トレース・ファイル, 8.1.1

デフォルト一時表領域

名前変更, 14.8

デフォルト一時表領域

データベース作成時に指定, 2.3.9, 2.4.6

大型一時ファイルの指定, 2.4.8.2

データベース・リソース・マネージャのDEFAULT_CONSUMER_GROUP, 27.2.6, 27.9.2 セグメント作成の遅延

表, 20.2.8

索引, 21.2.6

セグメントの遅延

マテリアライズ, 20.2.9

定義

チェーン・ステップ, 29.6.3

依存性

スキーマ・オブジェクト間, 18.7

表示, 18.11.2.2

宛先, Oracle Scheduler

説明, 28.2.4

作成, 29.2.2.3.3

デタッチ済ジョブ, 28.3.1.5 DIAGNOSTIC_DEST初期化パラメータ, 8.1.1, 9.1.4 ディクショナリ管理表領域

ローカル管理へのSYSTEMの移行, 14.12

Digital社のPOLYCENTER Manager on NetView, 31.3.4.3 ダイレクト・パスINSERT

利点, 20.4.2.1

動作, 20.4.2.2

索引メンテナンス, 20.4.2.5.2

ロックに関する考慮事項, 20.4.2.5.4

ロギング・モード, 20.4.2.4

パラレルINSERT, 20.4.2.3.2

パラレル・ロードとパラレルINSERTとの比較, 20.4.2.1

領域に関する考慮事項, 20.4.2.5.3

無効化

チェーン, 29.6.10

ジョブ, 29.2.7

プログラム, 29.3.5

SQLパッチ, 9.8.3

ウィンドウ・グループ, 29.7.4.7

ウィンドウ, 29.7.3.7

リカバラ・プロセスを使用禁止にする方法, 35.9.2 ディスパッチャ・プロセス(Dnnn), 5.5 ディスパッチャ・プロセス, 5.3.4.3, 5.3.6 DISPATCHERS初期化パラメータ

属性の設定, 5.3.4.1

初期設定, 5.3.4.3

分散アプリケーション

データ分散, 33.1

分散データベース

管理の概要, 31.3

アプリケーション開発, 31.5, 33, 33.5

クライアント/サーバー・アーキテクチャ, 31.1.3

コミット・ポイント強度, 34.2.5.2

コストベースの最適化, 31.5.3

直接接続および間接接続, 31.1.3

分散処理, 31.1.1.1

分散問合せ, 31.4.2

分散更新, 31.4.2, 31.4.2

グローバル・データベース名の書式設定, 32.1.1

グローバル・オブジェクト名, 31.2.9.4, 32.1

グローバリゼーション・サポート, 31.6

位置の透過性, 31.5.1.1, 32.6

管理ツール, 31.3.4

読込み一貫性の管理, 35.10

ノード, 31.1.3

概要, 31.1.1

リモート・オブジェクトのセキュリティ, 32.6.1

リモート問合せとリモート更新, 31.4.1

レプリケート・データベース, 31.1.1.2

再開可能領域割当て, 19.2.1.4

ARCHIVELOGモードでの実行, 13.2.2

NOARCHIVELOGモードでの実行, 13.2.2

使用例, 32.8

スキーマ・オブジェクトの名前解決, 31.4.8

スキーマに依存するグローバル・ユーザー, 31.3.2.4.1

スキーマに依存しないグローバル・ユーザー, 31.3.2.4.2

セキュリティ, 31.3.2

サイト自律性, 31.3.1

SQLの透過性, 31.5.1.2

リモート・インスタンスの起動, 3.1.5.8

トランザクション処理, 31.4

透過性, 31.5.1

分散処理

分散データベース, 31.1.1.1

分散問合せ, 31.4.2

表の分析, 33.4.2.2.2

アプリケーション開発の問題, 33.4

コストベースの最適化, 33.4.2

最適化, 31.5.3

分散システム

データ暗号化, 31.3.2.5

分散トランザクション, 31.4.5

事例, 34.5

コミット・ポイント・サイト, 34.2.5

コミット・ポイント強度, 34.2.5.2, 35.1

コミット, 34.2.5.1

データベース・サーバー・ロール, 34.2.2

定義, 34.1

DMLおよびDDL, 34.1.1

障害, 35.8.1

グローバル・コーディネータ, 34.2.4

ローカル・コーディネータ, 34.2.3

ロック・タイムアウト間隔, 35.8

ロックされたリソース, 35.8

インダウトのロック, 35.8.2

インダウトの手動上書き, 35.4.2

ネーミング, 35.2, 35.4.3.2

セッション・ツリー, 34.2, 34.2.2, 34.2.3, 34.2.4, 34.2.5, 35.3.2

アドバイスの設定, 35.4.3.3

トランザクション制御文, 34.1.2

トランザクションのタイムアウト, 35.8.1

2フェーズ・コミット, 34.5, 35.4.1

データベース・リンクの表示, 35.3.1

分散更新, 31.4.2 DML

「データ操作言語」を参照

DMLエラー・ロギング, データの挿入, 20.4.4 DRIVING_SITEヒント, 33.4.3.2 DROP ALL STORAGE句, 18.3.3 DROP CLUSTER文

CASCADE CONSTRAINTS句, 22.5

クラスタの削除, 22.5

クラスタ索引の削除, 22.5

ハッシュ・クラスタの削除, 23.5

INCLUDING TABLES句, 22.5

DROP DATABASE文, 2.10 DROP LOGFILE句

ALTER DATABASE文, 12.5.1

DROP LOGFILE MEMBER句

ALTER DATABASE文, 12.5.2

DROP SYNONYM文, 24.3.4 DROP TABLE文

説明, 20.10

CASCADE CONSTRAINTS句, 20.10

クラスタ化表, 22.5.1

DROP TABLESPACE句, 14.9 削除

チェーン・ステップ, 29.6.11

チェーン, 29.6.7

列

未使用マークの設定, 20.6.8.2

未使用列の削除, 20.6.8.2

圧縮表の列, 20.6.8.4 データファイル, 15.6 データファイル, Oracle Managed, 17.4.1 データベース・リンク, 32.4.2 ジョブ・クラス, 29.7.1.4 ジョブ, 29.2.6 プログラム, 29.3.4 チェーンからのルール, 29.6.9 スケジュール, 29.4.4 SQLパッチ, 9.8.3 表

CASCADE句, 20.10

結果, 20.10

一時ファイル, 15.6

Oracle Managed, 17.4.1

ウィンドウ・グループ, 29.7.4.3 ウィンドウ, 29.7.3.6 DUMP_ORPHAN_KEYSプロシージャ, 25.3.2

同期のチェック, 25.3.2

DBMS_REPAIRパッケージ, 25.2.1

例, 25.4.4

データのリカバリ, 25.3.4.1

ダンプ, 9.1.3.3

E

ECID, 9.1.2.2

エディション

CONNECT文, 1.3.2.4

管理, 18.10

スケジューラ・ジョブ, 28.6

電子メール通知, スケジューラ, 29.8.4 EMCA

コマンドライン引数, 10.2.4

EMCA入力ファイルの例, 10.2.5

EMPHASISリソース割当て方法, 27.5.4 空の表

セグメントの削除, 19.4

有効化

チェーン, 29.6.5

ジョブ, 29.2.8

プログラム, 29.3.6

ウィンドウ・グループ, 29.7.4.6

ウィンドウ, 29.7.3.8

リカバラ・プロセスを使用可能にする方法

分散トランザクション, 35.9.2

暗号化

列, 20.2.7

表領域, 14.2.4

暗号化, 透過的データ, 2.8.2 エンタープライズ・ユーザー

定義, 31.3.2.4.2

環境変数

ORACLE_SID, 2.3.1

エラー・ロギング, DML

データの挿入, 20.4.4

エラー

アラート・ログ, 8.1.1

PRAGMA_EXCEPTION_INITによる名前の割当て, 33.5

クリティカル, 9.1.1

例外ハンドラ, 33.5

整合性制約違反, 33.3

ORA-00028, 5.8.2

ORA-01090, 3.3

ORA-01173, 11.4.2

ORA-01176, 11.4.2

ORA-01177, 11.4.2

ORA-01215, 11.4.2

ORA-01216, 11.4.2

ORA-01578, 15.7

ORA-01591, 35.8.2

ORA-02049, 35.8.1

ORA-02050, 35.4.1

ORA-02051, 35.4.1

ORA-02054, 35.4.1

RAISE_APPLICATION_ERROR()プロシージャ, 33.5

リモート・プロシージャ, 33.5

ロールバックが必要, 33.3

トレース・ファイル, 8.1.1

制御ファイル作成時, 11.4.2

データベース起動時, 3.1.5.5

インスタンス起動時, 3.1.5.5

イベント・メッセージ

イベントベースのジョブに渡す方法, 29.5.2.5

イベント・スケジュール

変更, 29.5.2.4

作成, 29.5.2.3

イベントベースのジョブ

変更, 29.5.2.2

作成, 29.5.2.1

イベント・メッセージを渡す方法, 29.5.2.5

イベント

スケジューラ・ジョブを開始するための使用, 29.5

イベント(スケジューラ)

概要, 29.5.1

例

プランおよびサブプランの最大使用率の制限の設定, 27.7.2

例

リソース・マネージャを使用したパラレル・ステートメント実行の管理, 27.7.4

例外ハンドラ, 33.5 EXCEPTIONキーワード, 33.5 例外

PRAGMA_EXCEPTION_INITによる名前の割当て, 33.5

整合性制約, 18.5.5

ユーザー定義, 33.5

実行

リモート外部ジョブ, 30.1.3

実行コンテキスト識別子, 9.1.2.2 実行計画

分散問合せのための分析, 33.4.4

エクスポート操作

制限モード, 3.1.5.4

式, カレンダ指定, 29.4.5.1 EXTENT MANAGEMENT LOCAL句

CREATE DATABASE, 2.4.2

エクステント

クラスタ・エクステントの割当て, 22.4

表への割当て, 20.6.4

データ・ディクショナリ・ビュー, 19.6.2

クラスタ・エクステントの割当て解除, 22.4

使用可能エクステントの表示, 19.6.2.3

外部宛先, Oracle Scheduler

説明, 28.2.4

作成, 29.2.2.3.3

外部ジョブ

stdoutとstderrの取得, 28.3.1.2.1, 28.3.1.2.2, 29.2.2.9, 29.2.10

外部ジョブ, Oracle Scheduler, 28.3.1.2 外部プロシージャ

プロセスの管理, 5.7.1

外部表

変更, 20.13.3

作成, 20.13.2

定義, 20.13.1

削除, 20.13.5

必要な権限, 20.13.6

データのアップロードの例, 20.13.2

F

高速リカバリ領域

アーカイブ・ログのアーカイブ先, 13.4.1.1

指定する初期化パラメータ, 2.5.3

Oracle Managed Files, 17.2

高速リカバリ領域

古い名前, はじめに

障害診断インフラストラクチャ, 9.1.1 ファイル・マッピング

例, 15.9.4

動作, 15.9.2

使用方法, 15.9.3

概要, 15.9.1

構造, 15.9.2.2

ビュー, 15.9.3.3

ファイル・システム

Oracle Managed Filesでの使用, 17.1.1.2

File Watcher

説明, 29.5.3.1

検出間隔の変更, 29.5.3.5

作成, 29.5.3.3

管理, 29.5.3.5

FILE_MAPPING初期化パラメータ, 15.9.3.1 ファイル名

Oracle Managed Files, 17.3.1

ファイル

Oracle Managed Filesの作成, 17.3, 17.3.6.2

ファイナライズ

インシデント・パッケージ, 定義, 9.10.1.1

FIX_CORRUPT_BLOCKSプロシージャ

DBMS_REPAIR, 25.2.1

例, 25.4.3

ブロックへの破損マークの設定, 25.3.3.1

固定ユーザー・データベース・リンク

メリットおよびデメリット, 31.2.7.2

作成, 32.2.3.1

定義, 31.2.7

例, 31.2.8

フラッシュ・キャッシュ

「Database Smart Flash Cache」を参照

フラッシュバック・ドロップ

説明, 20.11

リサイクル・ビンのパージ, 20.11.4

リサイクル・ビンの問合せ, 20.11.3

リサイクル・ビン, 20.11.1

オブジェクトのリストア, 20.11.5

フラッシュバック表

概要, 20.9

フラッド制御されたインシデント

定義, 9.1.2.1

表示, 9.3

FMONバックグラウンド・プロセス, 15.9.2.1.1 FMPUTL外部プロセス

ファイル・マッピングに使用, 15.9.2.1.2

FORCE句

COMMIT文, 35.5

ROLLBACK文, 35.5

FORCE LOGGING句

CREATE CONTROLFILE, 2.4.10.1

CREATE DATABASE, 2.4.10

CREATE TABLESPACE, 14.4

パフォーマンスに関する考慮点, 2.4.10.2

FORCE LOGGINGモード, 20.4.2.4 強制的

COMMITまたはROLLBACK, 35.3.1, 35.4.2

ログ・スイッチの強制, 12.6

ARCHIVE_LAG_TARGETの使用, 12.2.6

ALTER SYSTEM文, 12.6

情報消去フェーズ

2フェーズ・コミット, 34.3.3

空き領域

使用可能エクステントのリスト表示, 19.6.2.3

表領域, 14.14.3

ファンクション索引, 21.3.6

G

Generic Connectivity

定義, 31.1.2.3

グローバル・コーディネータ, 34.2.4

分散トランザクション, 34.2.4

グローバル・データベースの一貫性

分散データベース, 34.3.2.2

グローバル・データベース・リンク, 31.2.6

作成, 32.2.2.3

グローバル・データベース名

ドメインの変更, 32.1.4

データベース・リンク, 31.2.4

ループバック, 31.2.4.1

データベース・リンクの有効化, 31.2.5 グローバル・ネーミングの施行, 32.1.2 分散データベース名の書式設定, 32.1.1 変更の影響, 31.4.9.1 問合せ, 32.1.3 グローバル・オブジェクト名

データベース・リンク, 31.4.7

分散データベース, 32.1

グローバル・ユーザー, 32.8.5

分散データベースでのスキーマに依存する, 31.3.2.4.1

分散データベースでのスキーマに依存しない, 31.3.2.4.2

GLOBAL_NAMEビュー

グローバル・データベース名を判断するための使用, 32.1.3

GLOBAL_NAMES初期化パラメータ

データベース・リンク, 31.2.5

グローバリゼーション・サポート

クライアント/サーバー・アーキテクチャ, 31.6.1

分散データベース, 31.6

GRANT文

SYSOPER/SYSDBA権限, 1.7.3.1

権限とロールの付与

SYSOPER/SYSDBA権限, 1.7.3.1

グループ, Oracle Scheduler, 28.2.10 増加傾向

データベース・オブジェクト, 19.7.3

GV$DBLINKビュー, 32.5.2

H

ハッシュ・クラスタ

メリットおよびデメリット, 23.1

変更, 23.4

キーの選択, 23.3.3.1

索引クラスタと対比, 23.1

領域使用の制御, 23.3.3

作成, 23.3

データ・ディクショナリ・ビューの参照, 23.6

削除, 23.5

記憶域の見積り, 23.3.4

例, 23.3.3.5.1

ハッシュ関数, 23.1, 23.2.2, 23.3, 23.3.3.1, 23.3.3.2, 23.3.3.3

HASH IS句, 23.3, 23.3.3.2

HASHKEYS句, 23.3, 23.3.3.4

単一表, 23.3.2

SIZE句, 23.3.3.3

ソート, 23.3.1

ハッシュ関数

ハッシュ・クラスタ, 23.1

ヘルス・チェック, 9.1.1 状態モニター, 9.7

チェック, 9.7.1.1

レポートの生成, 9.7.3

実行, 9.7.2

レポートの表示, 9.7.3

ADRCIを使用したレポートの表示, 9.7.3.3

異機種間分散システム

定義, 31.1.2

異機種間サービス

概要, 31.1.2

HI_SHARED_MEMORY_ADDRESSパラメータ, 6.4.2.8.2 ヒント, 33.4.3

DRIVING_SITE, 33.4.3.2

NO_MERGE, 33.4.3.1

分散問合せのチューニングのための使用, 33.4.3

HP社のOpenView, 31.3.4.3 ハイブリッド列圧縮, 20.2.6

I

IBM社のNetView/6000, 31.3.4.3

インポート操作

制限モード, 3.1.5.4

インシデント・パッケージ

相関, 9.10.1.3

相関, 作成, 編集, およびアップロード, 9.10.4

相関, 削除, 9.10.5

カスタムの作成, 編集およびアップロード, 9.10

カスタマイズ, 9.10.3, 9.10.3.2

定義, 9.1.1

表示, 9.10.3.1

インシデント・パッケージング・サービス, 9.1.1 インシデント

説明, 9.1.2

フラッド制御された, 9.1.2.1

表示, 9.3

索引クラスタ

「クラスタ」を参照

索引

変更, 21.4

分析, 18.2

索引を作成する列の選択, 21.2.2

クラスタ索引, 22.3.2, 22.4.1, 22.5

結合, 21.2.12, 21.4.2

パフォーマンスのための列の順序, 21.2.3

作成, 21.3

データ・ディクショナリ・ビューの参照, 21.7

セグメント作成の遅延, 21.2.6

使用禁止ステータスの判別, 21.4.3, 21.4.3

制約の使用禁止および削除, 21.2.13

削除, 21.2.5, 21.6, 21.6

サイズの見積り, 21.2.7

領域使用の見積り, 19.7.2

一意索引の明示的な作成, 21.3.2

ファンクション, 21.3.6

管理のガイドライン, 21.1

不可視, 21.2.11, 21.2.11

制約の使用禁止時の保持, 18.5.3

制約の削除時の保持, 18.5.3

キー圧縮, 21.3.7

表当たりの制限, 21.2.4

領域使用の監視, 21.5

使用状況の監視, 21.4.6

索引作成のパラレル化, 21.2.9

再作成, 21.2.12, 21.4.2, 21.4.2

ダイレクト・パスINSERT後の再作成, 20.4.2.5.2

名前変更, 21.4.5

記憶域パラメータの設定, 21.2.7

縮小, 19.3.3

使用される領域, 21.5

作成のための文, 21.3.1

表領域, 21.2.8

一時セグメント, 21.2.1

使用禁止, 21.2.11, 21.3.8, 21.4.3

構造の妥当性チェック, 18.2.2

作成する場合, 21.2.2

索引構成表

分析, 20.12.5

AS副問合せ, 20.12.2.6

ヒープへの変換, 20.12.7

作成, 20.12.2

説明, 20.12.1

INCLUDING句, 20.12.2.5

キー圧縮, 20.12.2.7

メンテナンス, 20.12.3

ORDER BY句, 使用, 20.12.6

パラレル作成, 20.12.2.6

MOVE句を使用した再作成, 20.12.3.2

ネストした表の格納, 20.12.2.3

オブジェクト型の格納, 20.12.2.3

しきい値, 20.12.2.4

インダウト・トランザクション, 34.4

システム障害の後, 35.4.1

自動解決, 34.4.1, 34.4.1.1

処理方法の決定, 35.4

手動上書きを実行するかどうかの判断, 35.4.2

定義, 34.3.1.2

手動解決, 34.4.2

手動コミット, 35.5.1

手動コミット, 例, 35.7

手動上書き, 35.4.2, 35.5

手動上書き, 使用例, 35.7

手動ロールバック, 35.5.2

概要, 34.4

ペンディング・トランザクション表, 35.7.6

データ・ディクショナリからの行のパージ, 35.6, 35.6.2

リカバラ・プロセス, 35.9.2

ロールバック, 35.5, 35.5.1.1, 35.5.2, 35.5.2

SCN, 34.4.3

シミュレーション, 35.9

セッション・ツリーのトレース, 35.3.2

データベース・リンクの表示, 35.3.1

INITIALパラメータ

変更できない, 20.6.2

初期化パラメータ・ファイル

説明, 2.5.1

作成, 2.3.4

アラート・ログからのコピー・アンド・ペーストによる作成, 2.6.9

データベース作成用に作成, 2.3.4

データベース作成前に編集, 2.5

個々のパラメータ名, 2.5.2

使用例, 2.5.1.2

サーバー・パラメータ・ファイル, 2.6

初期化パラメータ・ファイル

デフォルトの場所, 3.1.2.1

検索順序, 3.1.2.1

初期化パラメータ

説明, 2.5.1

データベースの起動, 3.1.2.1

ARCHIVE_LAG_TARGET, 12.2.6.1

BUFFER_POOL_KEEP, 6.4.2.2.2

BUFFER_POOL_RECYCLE, 6.4.2.2.2

変更, 2.6.5.1

消去, 2.6.6

COMMIT_POINT_STRENGTH, 34.2.5.2, 35.1

CONTROL_FILES, 2.5.4, 2.5.4, 11.2.1, 11.3.1

DB_BLOCK_CHECKING, 25.3.1.4

DB_BLOCK_CHECKSUM, 12.7, 15.7

DB_BLOCK_SIZE, 2.5.5, 14.3

DB_CACHE_SIZE, 14.3

DB_DOMA, 2.5.2

DB_DOMAIN, 2.5.2.2

DB_FILES, 15.1.1.1

DB_NAME, 2.5.2

DB_nK_CACHE_SIZE, 14.3, 14.13.5.6

DISPATCHERS, 5.3.4.3

FILE_MAPPING, 15.9.3.1

バッファ・キャッシュ, 6.4.2.2

GLOBAL_NAMES, 31.2.5

HI_SHARED_MEMORY_ADDRESS, 6.4.2.8.2

LOCK_SGA, 6.4.2.8.1

LOG_ARCHIVE_DEST, 13.4.1

LOG_ARCHIVE_DEST_n, 13.4.1, 13.6.2

LOG_ARCHIVE_DEST_STATE_n, 13.4.2

LOG_ARCHIVE_MAX_PROCESSES, 13.3.4

LOG_ARCHIVE_MIN_SUCCEED_DEST, 13.6.1

LOG_ARCHIVE_TRACE, 13.7

MAX_DUMP_FILE_SIZE, 8.1.1.1

OPEN_LINKS, 32.4.3

PROCESSES, 2.5.6

REMOTE_LOGIN_PASSWORDFILE, 1.7.2

REMOTE_OS_AUTHENT, 31.2.7.1

リセット, 2.6.6

RESOURCE_MANAGER_PLAN, 27.6, 27.6

サーバー・パラメータ・ファイル, 2.6, 2.6.10

SET SQL_TRACE, 8.1.1.2

設定, 2.6.5.1

共有サーバー, 5.3.1

SHARED_MEMORY_ADDRESS, 6.4.2.8.2

SHARED_SERVERS, 5.3.3.2

SORT_AREA_SIZE, 21.2.1

SPFILE, 2.6.4, 3.1.2.2

SQL_TRACE, 8.1.1

STATISTICS_LEVEL, 20.5

UNDO_MANAGEMENT, 2.4.4

UNDO_TABLESPACE, 2.5.8.2, 16.2.1

USE_INDIRECT_DATA_BUFFERS, 6.4.2.8.3

INITRANSパラメータ

変更, 20.6.2

INSERT文

DMLエラー・ロギング, 20.4.4

インストール

パッチ, 1.2.10

インスタンス・ケージング, 27.8.1

最大使用率の制限, 27.8.1

インスタンス

強制終了, 3.3.4

即時停止, 3.3.2

通常の停止, 3.3.1

トランザクションのシャットダウン, 3.3.3

インスタンス, 複数使用のためのCPU管理, 27.8.1 整合性制約

使用禁止のコスト, 21.2.13

削除のコスト, 21.2.13

対応付けられた索引の作成, 21.3.3

表領域の削除, 14.9

ORA-02055制約違反, 33.3

「制約」も参照

INTERNALユーザー名

停止のための接続, 3.3

不可視索引, 21.2.11, 21.2.11 IOT

「索引構成表」を参照

IPS, 9.1.1

J

Java Message Service(JMS), 10.2.6

ジョブ・クラス

変更, 29.7.1.3

作成, 29.7.1.2

削除, 29.7.1.4

スケジューラ・ジョブ属性, リソース, および優先度の管理, 29.7.1

概要, 28.2.8

ジョブ・コーディネータ, 28.4.2 ジョブ宛先ID, 定義, 29.2.5, 29.8.2 ジョブ・ログ, スケジューラ

表示, 29.8.1

ジョブ・リカバリ(スケジューラ), 30.4.1.4 ジョブ・スケジューリング

依存性, 28.1

イベントベース, 28.1

時間ベース, 28.1

JOB_QUEUE_PROCESSES初期化パラメータ, 28.4.2.2, A.1.2 ジョブ

変更, 29.2.3

エディション, 28.6

コピー, 29.2.9

作成, 29.2.2

スケジューラの作成および管理, 29.2

チェーン用に作成, 29.6.6

資格証明, 28.2.6

データベース, 28.3.1.1

デタッチ済, 28.3.1.5

無効化, 29.2.7

削除, 29.2.6

電子メール通知, 29.8.4

有効化, 29.2.8

イベントベース, 29.5.2.1

外部, 28.3.1.2

軽量, 28.3.1.6

軽量、作成例, 29.2.2.2.1

監視, 29.8

スケジューラによって呼び出されるイベントによる監視, 29.8.3

複数の宛先, 28.3.2

子ジョブのステータス, 30.2.2

概要, 28.2.3 優先度, 29.7.2 リモート・データベース, 28.3.1.1 リモート外部

説明, 28.3.1.2.2

実行, 29.2.4 ファイルがシステムに到着したことによる開始, 29.5.3 アプリケーションによって呼び出されたイベントによる開始, 29.5.2 ステータス, 29.8, 30.6.2 停止, 29.2.5 リモートのトラブルシューティング, 30.4.1.3 実行中の情報の表示, 30.2.2 stdoutとstderrの表示, 29.2.10 結合ビュー

定義, 24.1.2.1

DELETE文, 24.1.5.2.2

キー保存表, 24.1.5.1

変更, 24.1.5

変更に関する規則, 24.1.5.2

更新, 24.1.5

結合

分散データベースでの文の透過性, 32.7

K

キー圧縮, 20.12.2.7

索引, 21.3.7

キー保存表

結合ビュー, 24.1.5.1

外部結合, 24.1.5.3

キー

クラスタ, 22.1, 22.2.3

L

ラージ・オブジェクト, 20.3.1

軽量ジョブ, 28.3.1.6

例, 29.2.2.2.1

作成例, 29.2.2.2.1

リンク

「データベース・リンク」を参照

LIST CHAINED ROWS句

ANALYZE文, 18.2.3.1

リスナー

srvctlを使用した削除, 4.4

データベース・リンクのリスト作成, 32.5.1, 35.3.1, 35.3.2 データのロード

外部表の使用, 20.13.2

LOB, 20.3.1 ローカル・コーディネータ, 34.2.3

分散トランザクション, 34.2.3

ローカル管理表領域, 14.2.1

自動セグメント領域管理, 14.2.1.2

DBMS_SPACE_ADMINパッケージ, 14.11

欠陥の検出と修復, 14.11

ディクショナリ管理からのSYSTEMの移行, 14.12

縮小、一時, 14.7.5

一時ファイル, 14.2.5.1

一時、作成, 14.2.5.1

分散データベースでの位置の透過性

シノニムを使用した作成, 32.6.2

ビューを使用した作成, 32.6.1

制限, 32.7

プロシージャの使用, 32.6.3.3

ロック・タイムアウト間隔

分散トランザクション, 35.8

LOCK_SGAパラメータ, 6.4.2.8.1 ロック

インダウト分散トランザクション, 35.8, 35.8.2

監視, 8.2.1

ログ

ウィンドウ(スケジューラ), 29.7.3

ログ順序番号

制御ファイル, 12.1.3.2

ログ・スイッチ

説明, 12.1.3.2

強制的, 12.6, 12.6

ログ順序番号, 12.1.3.2

多重REDOログ・ファイル, 12.2.1.1

権限, 12.6

ARCHIVE_LAG_TARGETの使用, 12.2.6

アーカイブ完了待ち, 12.2.1.1

ログ・ライター・プロセス(LGWR), 5.5

多重REDOログ・ファイル, 12.2.1.1

使用可能なオンラインREDOログ, 12.1.3

トレース・ファイル, 12.2.1.1

オンラインREDOログ・ファイルへの書込み, 12.1.3

LOG_ARCHIVE_DEST初期化パラメータ

アーカイブ先の指定に使用, 13.4.1

LOG_ARCHIVE_DEST_n初期化パラメータ, 13.4.1

REOPEN属性, 13.6.2

LOG_ARCHIVE_DEST_STATE_n初期化パラメータ, 13.4.2 LOG_ARCHIVE_DUPLEX_DEST初期化パラメータ

アーカイブ先の指定に使用, 13.4.1

LOG_ARCHIVE_MAX_PROCESSES初期化パラメータ, 13.3.4 LOG_ARCHIVE_MIN_SUCCEED_DEST初期化パラメータ, 13.6.1 LOG_ARCHIVE_TRACE初期化パラメータ, 13.7 LOGGING句

CREATE TABLESPACE, 14.4

ロギング・モード

ダイレクト・パスINSERT, 20.4.2.4

NOARCHIVELOGモード, 20.4.2.4.1

DBMS_REPAIRによる論理的な破損, 25.3.2 論理ボリューム・マネージャ

ファイルと物理デバイスのマッピング, 15.9, 15.9.4.3

Oracle Managed Filesでの使用, 17.1.1.1

LOGONトリガー

再開可能モードの設定, 19.2.3

ログ

ジョブ, 30.2.3

ウィンドウ(スケジューラ), 29.7.3, 30.2.3

LONG列, 32.7 LONG RAW列, 32.7

M

メンテナンス・タスク, 自動

「自動メンテナンス・タスク」を参照

メンテナンス・ウィンドウ

作成, 26.4.2

定義, 26.1

MAINTENANCE_WINDOW_GROUP, 26.2

変更, 26.4.1

事前定義, 26.6.1

削除, 26.4.3

スケジューラ, 26.2

管理

メモリー, 6

UNDO表領域に対する領域のアラートしきい値, 16.5.6

データファイルの管理, 15 順序の管理, 24.2.1 シノニムの管理, 24.3.1 表の管理, 20 ビューの管理, 24.1 手動アーカイブ

ARCHIVELOGモード, 13.3.3

手動上書き

インダウト・トランザクション, 35.5

セグメント遅延のマテリアライズ, 20.2.9 MAX_DUMP_FILE_SIZE初期化パラメータ, 8.1.1.1 MAXDATAFILESパラメータ

変更, 11.3.3.2

MAXINSTANCES, 11.3.3.2 MAXLOGFILESパラメータ

変更, 11.3.3.2

CREATE DATABASE文, 12.2.5

MAXLOGHISTORYパラメータ

変更, 11.3.3.2

MAXLOGMEMBERSパラメータ

変更, 11.3.3.2

CREATE DATABASE文, 12.2.5, 12.2.5

MAXTRANSパラメータ

変更, 20.6.2

メディア・リカバリ

アーカイブの影響, 13.2.1

メモリー

拡張バッファ・キャッシュ(32ビット), 6.4.2.8.3

管理, 6

アーキテクチャの概要, 6.2

システム・グローバル領域(SGA)

初期化パラメータ, 6.4.2.8

物理メモリーへのロック, 6.4.2.8.1

開始アドレス, 6.4.2.8.2

メモリー管理

説明, 6.1

自動, 6.1, 6.3.2

データ・ディクショナリ・ビューの参照, 6.6.2

MEMORY_MAX_TARGETパラメータ, 6.3.1 MEMORY_TARGETパラメータ, 6.3.1 移行行

表からの除去, 手順, 18.2.3.2

MINEXTENTSパラメータ

変更できない, 20.6.2

ミラー化したファイル

制御ファイル, 2.5.4, 11.2.2

オンラインREDOログ, 12.2.1.1

オンラインREDOログの位置, 12.2.2

オンラインREDOログのサイズ, 12.2.3

MISSINGデータファイル, 11.4.1 監視

パフォーマンス, 8.2

チェーンの実行, 29.6.17

MONITORING句

CREATE TABLE, 20.5

MONITORING USAGE句

ALTER INDEX文, 21.4.6

データベースのマウント, 3.1.5.3 制御ファイルの移動, 11.3.2 複数のインスタンス, CPUの管理, 27.8.1 複数の一時表領域, 14.2.6, 14.2.6.3 複数の宛先のジョブ, Oracle Scheduler, 28.3.2

子ジョブのステータス, 30.2.2

多重制御ファイル

重要性, 11.2.2

多重化

アーカイブREDOログ, 13.4.1

制御ファイル, 11.2.2

REDOログ・ファイル・グループ, 12.2.1

REDOログ・ファイル, 12.2.1, 12.2.1

N

分散データベースでの名前解決

データベース・リンク, 31.4.7

グローバル名の変更の影響, 31.4.9.1

プロシージャ, 31.4.9

スキーマ・オブジェクト, 31.2.9.4, 31.4.8

シノニム, 31.4.9

ビュー, 31.4.9

グローバル・データベース名が完全なとき, 31.4.7.1

グローバル・データベース名が部分的なとき, 31.4.7.2

グローバル・データベース名をまったく指定しないとき, 31.4.7.3

指名ユーザーの制限

初期設定, 2.5.10

ネットワーク

接続, 最小化, 32.3

分散データベースの使用, 31.1.1

NEXTパラメータ

変更, 20.6.2

NEXTVAL疑似列, 24.2.4.1, 24.2.4.1.1

制限, 24.2.4.1.3

NO_DATA_FOUNDキーワード, 33.5 NO_MERGEヒント, 33.4.3.1 NOARCHIVELOGモード

アーカイブ, 13.2

定義, 13.2.1

データファイルの削除, 15.4.2

LOGGINGモード, 20.4.2.4.1

メディア障害, 13.2.1

ホット・バックアップなし, 13.2.1

実行, 13.2.1

切替え, 13.3.2

データファイルのオフライン化, 15.4.2

NOCACHEオプション

CREATE SEQUENCE文, 24.2.4.2.2

NOLOGGING句

CREATE TABLESPACE, 14.4

NOLOGGINGモード

ダイレクト・パスINSERT, 20.4.2.4

通常転送モード

定義, 13.5.1

Novell社のNetWare Management System, 31.3.4.3

O

オブジェクト権限

外部表, 20.13.6

オブジェクト

「スキーマ・オブジェクト」を参照

オフライン表領域

優先度, 14.5.1

オフライン化, 14.5.1

OLTP表圧縮, 20.2.6 表のオンライン再定義, 20.7

強制終了およびクリーン・アップ, 20.7.5

例, 20.7.8

機能, 20.7.1

中間での同期化, 20.7.4

単一パーティションの再定義, 20.7.7

ルール, 20.7.7.1

制限, 20.7.6 DBMS_REDEFINITION, 20.7.2 オンラインREDOログ・ファイル

「オンラインREDOログ」を参照

オンラインREDOログ

グループの作成, 12.3

メンバーの作成, 12.3.2

データ・ディクショナリ・ビューの参照, 12.9

グループの削除, 12.5

メンバーの削除, 12.5

ログ・スイッチの強制, 12.6

構成のガイドライン, 12.2

INVALIDメンバー, 12.5.2

位置, 12.2.2

管理, 12

ファイルの移動, 12.4

ファイル数, 12.2.5

最適の構成, 12.2.5

ファイルの名前変更, 12.4

メンバーの名前変更, 12.4

ARCHIVE_LAG_TARGETの指定, 12.2.6

STALEメンバー, 12.5.2

「REDOログ・ファイル」も参照

セグメントのオンラインでの縮小, 19.3.3 OPEN_LINKS初期化パラメータ, 32.4.3 ウィンドウのオープン, 29.7.3.4 オペレーティング・システム認証, 1.6.3.2 オペレーティング・システム

データベース管理者の要件, 1.5.1

ファイルの名前変更と再配置, 15.5

ORA-01013エラー・メッセージ, 3.3.5 ORA-02055エラー

整合性制約違反, 33.3

ORA-02067エラー

ロールバックが必要, 33.3

ORA-12838エラー, ダイレクト・パス・インサート, 20.4.2.3.2 Oracle Call Interface

「OCI」を参照

Oracle Data Guard

スケジューラによるサポート, 28.5, 30.5.5

Oracle Database

リリース番号, 1.4.1

Oracle Databaseユーザー

タイプ, 1.1

Oracle Enterprise Manager, 3.1.1.3, 3.1.1.3 Oracleホーム

クローニング, 1.2.11

Oracle Managed Files

ネーミング, 17.3.1

使用例, 17.5

Oracle Managed Files

既存のデータベースへの追加, 17.5.3

動作, 17.4

利点, 17.1.2

CREATE DATABASE文, 17.3.2

作成, 17.3

制御ファイルの作成, 17.3.5

データファイルの作成, 17.3.3

オンラインREDOログ・ファイルの作成, 17.3.6

一時ファイルの作成, 17.3.4

説明, 17.1

データファイルの削除, 17.4.1

オンラインREDOログ・ファイルの削除, 17.4.2

一時ファイルの削除, 17.4.1

初期化パラメータ, 17.2

概要, 2.4.7

名前変更, 17.4.3

Oracle Managed Files機能

「Oracle Managed Files」を参照

Oracle Restart

説明, 4.1.1

構成

コンポーネントの追加, 4.2.3

変更, 4.2.8

コンポーネントの削除, 4.2.4

コンポーネント用の表示, 4.2.7

構成, 4.2 CRSCTLユーティリティ, 4.1.4 コンポーネント管理の無効化と有効化, 4.2.5 環境変数, 4.2.9 パッチ

インストール, 4.3

コンポーネントの登録, 4.2.3 起動, 4.1.4 管理されているコンポーネントの起動と停止, 4.3

Oracleホーム, 4.3

コンポーネントのステータス, 4.2.6 停止, 4.1.4 Oracle Scheduler

「スケジューラ」を参照

Oracle Scheduler Agent

Windowsの場合, 30.1.3.3.2

OracleSchedulerExecutionAgent, 30.1.3.3.2

タスク, 30.1.3.3

Windowsサービス, 30.1.3.3.2

Oracle Scheduler Agent, 30.1.3 Oracle Scheduler Agent

データベースへの登録, 30.1.3.3.5

Oracle Universal Installer, 2.1 Oracleウォレット, 14.2.4, 20.2.7 環境変数ORACLE_SID, 2.3.1 OracleSchedulerExecutionAgent, 30.1.3.3.2 oraenvおよびcoraenv, 1.3.2.2 ORAPWDユーティリティ, 1.7.1 ORGANIZATION EXTERNAL句

CREATE TABLE, 20.13.2

孤立キー表

作成の例, 25.4.1.2

OSDBAグループ, 1.6.3.1 OSOPERグループ, 1.6.3.1 OTHER_GROUPS

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

データベース・リソース・マネージャのOTHER_GROUPS, 27.5.5, 27.5.6, 27.7.5 外部結合, 24.1.5.3

キー保存表, 24.1.5.3

ウィンドウの重複, 28.2.9.1

P

パッケージ

「インシデント・パッケージ」を参照

パッケージ

DBMS_FILE_TRANSFER, 15.7

DBMS_METADATA, 18.11.1

DBMS_REDEFINITION, 20.7.2, 20.7.9, 20.7.9

DBMS_REPAIR, 25.2

DBMS_RESOURCE_MANAGER, 27.1.2, 27.1.3, 27.1.3, 27.2.4.1

DBMS_RESOURCE_MANAGER_PRIVS, 27.1.3, 27.1.3

DBMS_RESUMABLE, 19.2.4.3

DBMS_SPACE, 19.3.4, 19.6.1

DBMS_STATS, 18.2.1, 20.5

DBMS_STORAGE_MAP, 15.9.3.2, 15.9.3.3

問題のパッケージ化とアップロード, 9.10.2 パラレル実行

管理, 5.6

パラレル・ヒント, 5.6, 5.6

索引作成のパラレル化, 21.2.9

再開可能領域割当て, 19.2.1.5

パラレル・ヒント, 5.6, 5.6 パラレル・ステートメント実行

管理用のディレクティブ属性, 27.7.4

リソース・マネージャを使用した管理, 27.3.4

PARALLEL_DEGREE_LIMIT_ABSOLUTEリソース割当て方法, 27.5.4 表作成のパラレル化, 20.2.4, 20.3.3 パラメータ・ファイル

「初期化パラメータ・ファイル」を参照

パーティション表

パーティションのオンライン再定義, 20.7.7

ルール, 20.7.7.1

パスワード

CREATE DATABASE文のSYSTEMアカウント用の設定, 2.4.1

CREATE DATABASE文のSYSの設定, 2.4.1

パスワード・ファイル

ユーザーの追加, 1.7.3

作成, 1.7.1

ORAPWDユーティリティ, 1.7.1

削除, 1.7.4.2

REMOTE_LOGIN_PASSWORDの設定, 1.7.2

管理者パスワードとデータ・ディクショナリとの同期, 1.7.2

メンバーの表示, 1.7.3.2

パスワード・ファイル認証, 1.6.4.1 パスワード

大/小文字の区別, 1.6.2, 1.6.4.1, 1.6.4.2

SYSとSYSTEMのデフォルト, 1.5.2

パスワード・ファイル, 1.7.3

REMOTE_LOGIN_PASSWORDパラメータの設定, 1.7.2

パッチ

インストール, 1.2.10

Oracle Restart, 4.3

チェーンとチェーン・ステップの一時停止, 29.6.14 PCTINCREASEパラメータ, 20.6.2 データベース・リソース・マネージャのプランのペンディング・エリア, 27.5.8

プラン・スキーマ変更の妥当性チェック, 27.5.6

ペンディング・トランザクション表, 35.7.6 パフォーマンス

索引列の順序, 21.2.3

データファイルの位置, 15.1.3

監視, 8.2

PGA_AGGREGATE_TARGET初期化パラメータ, 6.4.3 データベース・リソース・マネージャのプラン・スキーマ, 27.3.1, 27.6, 27.9.4

プラン変更の妥当性チェック, 27.5.6

データベース・リソース・マネージャのプラン

例, 27.7

PL/SQL

置換されたビューおよびプログラム・ユニット, 24.1.3

PRAGMA_EXCEPTION_INITプロシージャ

例外名の割当て, 33.5

事前定義のユーザー・アカウント, 2.8.1 準備フェーズ

異常終了時のエラー, 34.3.1.1.3

2フェーズ・コミット, 34.3.1

準備応答, 34.3.1.1.1

読取り専用応答, 34.3.1.1.2

読取り専用ノードの認識, 34.3.1.1.2

ステップ, 34.3.1.2

準備/コミット・フェーズ

障害の影響, 35.8.1

障害, 35.4.1

ロックされたリソース, 35.8

ペンディング・トランザクション表, 35.7.6

準備応答

2フェーズ・コミット, 34.3.1.1.1

前提条件

データベースの作成, 2.1.1.2

主キー制約

対応する索引, 21.3.3.1

対応する索引の削除, 21.6

作成時に使用可能にする, 21.3.3

削除時の外部キー参照, 18.5.3.1

対応付けられた索引, 21.3.3

優先度

ジョブ, 29.7.2

プライベート・データベース・リンク, 31.2.6 プライベート・シノニム, 24.3.1 権限

REDOログ・グループの追加, 12.3

索引の変更, 21.4

表の変更, 20.6

データベース・リンクのクローズ, 33.2

データベース・リンクの作成, 32.2.1

表の作成, 20.3

表領域の作成, 14.2

データベース管理者, 1.5

表の削除, 20.10

索引の削除, 21.6

オンラインREDOログ・メンバーの削除, 12.5.2

REDOログ・グループの削除, 12.5.1

トリガーの使用可能および使用禁止, 18.4

外部表, 20.13.6

ログ・スイッチの強制, 12.6

プロシージャによる管理, 32.6.3.4

シノニムによる管理, 32.6.2.2

ビューによる管理, 32.6.1

手動アーカイブ, 13.3.3

名前変更オブジェクト, 18.6

REDOログ・メンバーの名前変更, 12.4

RESTRICTED SESSIONシステム権限, 3.1.5.4

スケジューラ, 30.6.1

順序, 24.2.2, 24.2.2, 24.2.5

チェーンの設定(スケジューラ), 30.1.1

シノニム, 24.3.2, 24.3.4

表領域のオフライン化, 14.5.1

切捨て, 18.3.3

ビューの使用, 24.1.4

順序の使用, 24.2.4

ビュー, 24.1.2, 24.1.3, 24.1.7

問題のアクティビティ・ログ

コメントの追加, 9.2.7

問題

説明, 9.1.2

コメントのアクティビティ・ログへの追加, 9.2.7

問題(クリティカル・エラー)

パッケージ化とアップロード, 9.10.2

プロシージャ

外部, 5.7.1

分散データベースでの位置の透過性, 32.6.3

分散データベースでの名前解決, 31.4.9

リモート・コール, 31.5.2

プロセス・モニター(PMON), 5.5 プロセス

「サーバー・プロセス」を参照

PROCESSES初期化パラメータ

データベース作成前の設定, 2.5.6

PRODUCT_COMPONENT_VERSIONビュー, 1.4.2 プログラム・グローバル領域(PGA), 6.2 プログラム・グローバル領域, 6.2 プログラム

変更, 29.3.3

作成, 29.3.2

作成および管理, スケジューラ・ジョブの定義, 29.3

無効化, 29.3.5

削除, 29.3.4

有効化, 29.3.6

概要, 28.2.1

パブリック・データベース・リンク, 31.2.6

接続ユーザー, 32.8.3

固定ユーザー, 32.8.1

パブリック固定ユーザーのデータベース・リンク, 32.8.1 パブリック・シノニム, 24.3.1 PURGE_LOST_DB_ENTRYプロシージャ

DBMS_TRANSACTIONパッケージ, 35.6.1

Q

問合せ

分散, 31.4.2

分散アプリケーション開発の問題, 33.4

位置の透過性, 31.5.1.2

リモート, 31.4.1

疑問符, 2.3.11 データベースの静止, 3.4 割当て制限

表領域, 14.1.2

R

RAISE_APPLICATION_ERROR()プロシージャ, 33.5

読込み一貫性

分散データベースでの管理, 35.10

読取り専用データベース

オープン, 3.2.3

読取り専用データベース

制約, 3.2.3

読取り専用応答

2フェーズ・コミット, 34.3.1.1.2

読取り専用表, 20.6.9 読取り専用表領域

名前変更時のデータファイル・ヘッダー, 14.8

データファイルのオープンの遅延, 14.6.4

読取り専用に設定, 14.6.1

書込み可能にする, 14.6.2

WORMデバイス, 14.6.3

Real Application Clusters

クラスタ用のエクステントの割当て, 22.4

順序番号, 24.2.2

オンラインREDOログのスレッド, 12.1.1

索引の再作成, 21.4.2

コスト, 21.2.12

オンライン, 21.4.2

未使用領域の再生, 19.3 RECOVER句

STARTUPコマンド, 3.1.5.6

リカバラ・プロセス

無効化, 35.9.2

分散トランザクションのリカバリ, 35.9.2

有効化, 35.9.2

ペンディング・トランザクション表, 35.9.2

リカバラ・プロセス(RECO), 5.5 リカバリ

スケジューラ・ジョブ, 30.4.1.4

リカバリ

新しい制御ファイルの作成, 11.3.3.2

Recovery Manager

データベースの起動, 3.1.1.2

インスタンスの起動, 3.1.1.2

リサイクル・ビン

説明, 20.11.1

パージ, 20.11.4

名前が変更されたオブジェクト, 20.11.1

オブジェクトのリストア, 20.11.5

表示, 20.11.3

オンラインでの表の再定義

「表のオンライン再定義」を参照

REDOログ・ファイル

アクティブ(カレント), 12.1.3.1

アーカイブ, 13.2

使用可能, 12.1.3

ブロック・サイズ、設定, 12.2.4

循環使用, 12.1.3

クリア, 12.2.1.1, 12.8

内容, 12.1.2

Oracle Managed Filesとして作成, 17.3.6

Oracle Managed Filesとして作成, 例, 17.5.1

グループの作成, 12.3

メンバーの作成, 12.3, 12.3.2

分散トランザクション情報, 12.1.3

グループの削除, 12.5

メンバーの削除, 12.5

グループのメンバー, 12.2.1

グループ、定義, 12.2.1

REDOログ内の数, 12.2.5

非アクティブ, 12.1.3.1, 12.1.3.1

インスタンス・リカバリ時の使用, 12.1

有効な構成と無効な構成, 12.2.1.2

LGWR, 12.1.3

ログ・スイッチ, 12.1.3.2

メンバーの最大数, 12.2.5

メンバー, 12.2.1

ミラー化、ログ・スイッチ, 12.2.1.1

多重, 12.2.1, 12.2.1, 12.2.1.1

オンライン、定義, 12.1

計画, 12.2, 12.2.5

REDOエントリ, 12.1.2

要件, 12.2.1.2

データベース作成時に指定, 17.3.2.2

データファイルから分離した格納, 15.1.4

スレッド, 12.1.1

データベースのオープン時に使用不可能, 3.1.5

ブロックの検証, 12.7

「REDOログ・ファイル」も参照

REDOログ

「オンラインREDOログ」を参照

「REDOログ・ファイル」を参照

REDOレコード, 12.1.2

LOGGINGとNOLOGGING, 14.4

参照整合性

分散データベース・アプリケーションの開発, 33.3

リリース番号の形式, 1.4.1 リリース, 1.4.1

Oracle Databaseのリリース番号のチェック, 1.4.2

制御ファイルの再配置, 11.3.2 リモート接続

SYSOPER/SYSDBAとして接続, 1.6.1

パスワード・ファイル, 1.7.2

リモート・データ

問合せ, 32.7

更新, 32.7

リモート・データベース・ジョブ, 28.3.1.1

スケジューラ・エージェントの設定, 30.1.3.2

リモート外部ジョブ

説明, 28.3.1.2.2

実行, 30.1.3

スケジューラ・エージェントの設定, 30.1.3.2

Remote Method Invocation(RMI), 10.2.6 リモート・プロシージャ・コール, 31.5.2, 31.5.2

分散データベース, 31.5.2

リモート問合せ

分散データベース, 31.4.1

リモート・トランザクション, 31.4.4

定義, 31.4.4

REMOTE_LOGIN_PASSWORDFILE初期化パラメータ, 1.7.2 REMOTE_OS_AUTHENT初期化パラメータ

接続ユーザー・データベース・リンク, 31.2.7.1

RENAME文, 18.6 制御ファイルの名前変更, 11.3.2 ファイルの名前変更

Oracle Managed Files, 17.4.3

索引の名前変更, 21.4.5 REOPEN属性

LOG_ARCHIVE_DEST_n初期化パラメータ, 13.6.2

修復表

作成の例, 25.4.1.1

データ・ブロック破損の修復

DBMS_REPAIR, 25.1

繰返し間隔, スケジュール, 29.4.5 RESIZE句

単一ファイル表領域用, 14.7.3

リソース割当て方法

アクティブ・セッション・プール, 27.5.4

ACTIVE_SESS_POOL_MTH, 27.5.4

CPU, 27.3.1

CPUリソース, 27.5.4, 27.5.4

EMPHASIS, 27.5.4

並列度の制限, 27.5.4

MAX_UTILIZATION_METHOD, 27.3.1

PARALLEL_DEGREE_LIMIT_ABSOLUTE, 27.5.4

PARALLEL_DEGREE_LIMIT_MTH, 27.5.4

PARALLEL_DEGREE_LIMIT_P1, 27.3.2

PARALLEL_QUEUE_TIMEOUT, 27.3.4

PARALLEL_TARGET_PERCENTAGE, 27.3.3

QUEUEING_MTH, 27.5.4

キューイング・リソース割当て方法, 27.5.4

ROUND-ROBIN, 27.5.3

リソース・コンシューマ・グループ, 27.1.2

変更, 27.2.4.1

作成, 27.5.3

DEFAULT_CONSUMER_GROUP, 27.2.6, 27.9.2

削除, 27.9.2

スイッチ特権の付与, 27.2.6

管理, 27.2, 27.2.4.2

OTHER_GROUPS, 27.1.2.1, 27.5.5, 27.5.6, 27.7.5

パラメータ, 27.5.3

スイッチ特権の取消し, 27.2.6.2

初期の設定, 27.2.2

セッションの切替え, 27.2.4.1.1

ユーザー・セッションの切替え, 27.2.4.1.2

SYS_GROUP, 27.7.5

更新, 27.9.1

リソース・マネージャ

AUTO_TASK_CONSUMER_GROUPコンシューマ・グループ, 26.5

パラレル・ステートメント実行の管理, 27.3.4

リソース・プラン・ディレクティブ, 27.1.2, 27.5.6

削除, 27.9.6

パラレル・ステートメント実行の管理, 27.7.4

指定, 27.5.5

更新, 27.9.5

リソース・プラン, 27.1.2, 27.1.2.6

作成, 27.4

DEFAULT_MAINTENANCE_PLAN, 26.5.1

DELETE_PLAN_CASCADE, 27.9.4

削除, 27.9.4

例, 27.7

パラメータ, 27.5.4

プラン・スキーマ, 27.3.1, 27.6, 27.9.4

SYSTEM_PLAN, 27.7.5

トップレベルのプラン, 27.5.6, 27.6

更新, 27.9.3

検証, 27.5.6

RESOURCE_MANAGER_PLAN初期化パラメータ, 27.6, 27.6 RESTRICTED SESSIONシステム権限

制限モード, 3.1.5.4

結果キャッシュ

共有プール・サイズ, 6.4.2.3.1

サイズの設定, 6.4.2.7

RESULT_CACHE_SIZE初期化パラメータ, 6.4.2.7 再開可能領域割当て

訂正可能なエラー, 19.2.1.3

一時停止文の検出, 19.2.4

無効化, 19.2.2

分散データベース, 19.2.1.4

有効化, 19.2.2

例, 19.2.6

再開可能文の動作, 19.2.1.1

文の命名, 19.2.2.2.2

パラレル実行, 19.2.1.5

再開可能な操作, 19.2.1.2

セッションのデフォルトとして設定, 19.2.3

タイムアウト間隔, 19.2.2.2.1, 19.2.4.1

RESUMABLE_TIMEOUT初期化パラメータ, 19.2.1.1

設定, 19.2.2.1

保存期間の保証(UNDOの場合), 16.2.2.2 表の変更の取消し, 20.8 RMAN

「Recovery Manager」を参照

ロール

DBAロール, 1.5.2.3

データベース・リンクを介した取得, 31.2.10

ROLLBACK文

FORCE句, 35.5, 35.5.1.1, 35.5.2

強制的, 35.4.2

ロールバック

ORA-02, 33.3

ROUND-ROBINリソース割当て方法, 27.5.3 行

連鎖行または移行行のリスト, 18.2.3

ルール

チェーンへの追加, 29.6.4

チェーンからの削除, 29.6.9

実行

チェーン, 29.6.8

ジョブ, 29.2.4

SQL修復アドバイザ, 9.8.2

S

サンプル・スキーマ

説明, 2.8.4

セーブポイント

インダウト・トランザクション, 35.5, 35.5.2

schagentユーティリティ, 30.1.3.3.1 スケジューラ

管理, 30

アーキテクチャ, 28.4

構成, 30.1

ジョブのための資格証明, 28.2.6

データ・ディクショナリ・ビューの参照, 30.6.2

電子メール通知, 29.8.4

使用例, 30.5

インポートとエクスポート, 30.3

メンテナンス・ウィンドウ, 26.2

監視と管理, 30.2

ジョブの監視, 29.8

オブジェクト, 28.2

概要, 28.1

タスクのスケジューリングに使用, 29

セキュリティ, 30.2.4

Oracle Data Guardのサポート, 28.5, 30.5.5

トラブルシューティング, 30.4

ジョブが実行されない, 30.4.1

RACでの使用, 28.4.5 スケジューラ・エージェント, 30.1.3

構成, 30.1.3.2

インストール, 30.1.3.2

設定, 30.1.3.2

スケジューラのカレンダ指定構文, 29.4.5.1 スケジューラのチェーン条件構文, 29.6.4 スケジューラ・オブジェクト, ネーミング, 29.1 スケジューラの権限の参照, 30.6.1 SCHEDULER_BATCH_ERRORSビュー, 29.2.6 スケジュール

変更, 29.4.3

作成, 29.4.2

作成および管理, スケジューラ・ジョブの定義, 29.4

削除, 29.4.4

概要, 28.2.2

データベース・タスクのスケジューリング, 29 スキーマ・オブジェクト

分析, 18.2

複数のオブジェクトの作成, 18.1

データ・ディクショナリ・ビューの参照, 18.11.2

DBMS_METADATAパッケージを使用した定義, 18.11.1

オブジェクト間の依存性, 18.7

分散データベース命名規則, 31.2.9.4

グローバル名, 31.2.9.4

タイプ別のリスト, 18.11.2.1

分散データベースでの名前解決, 31.2.9.4, 31.4.8

SQL文での名前解決, 18.8

名前変更する権限, 18.6

シノニムによる参照, 32.6.2.1

名前変更, 18.6, 18.6

構造の妥当性チェック, 18.2.2

情報の表示, 18.11, 19.6

スキーマ・オブジェクトの領域使用

データ・ディクショナリ・ビューの参照, 19.6.2

SCN

「システム変更番号」を参照

SCOPE句

ALTER SYSTEM SET, 2.6.5.1

スクリプト, ユーザーの認証, 2.8.3 SEC_CASE_SENSITIVE_LOGON初期化パラメータ, 1.6.2, 1.6.4.1 セキュリティ

データベースへのアクセス, 7.1

管理者, 7.1

分散データベースでのユーザーの集中管理, 31.3.2.4

データベース・セキュリティ, 7.1

分散データベース, 31.3.2

ポリシーの設定, 7

権限, 7.1

リモート・オブジェクト, 32.6.1

スケジュール, 30.2.4

シノニムの使用, 32.6.2.2

セグメント・アドバイザ, 19.3.2

スケジューラ・ジョブの構成, 19.3.2.4

Enterprise Managerでの起動, 19.3.2.2.1

PL/SQLによる起動, 19.3.2.2.2

手動による実行, 19.3.2.2

結果の表示, 19.3.2.3

ビュー, 19.3.2.5

SEGMENT_FIX_STATUSプロシージャ

DBMS_REPAIR, 25.2.1

セグメント

使用可能領域, 19.6.1

データ・ディクショナリ・ビュー, 19.6.2

未使用領域の割当て解除, 19.3

情報の表示, 19.6.2.1

空の表のための削除, 19.4

縮小, 19.3.3

SELECT文

FOR UPDATE句と位置の透過性, 32.7

SEQUENCE_CACHE_ENTRIESパラメータ, 24.2.4.2.2 順序

アクセス, 24.2.4

変更, 24.2.3

順序番号のキャッシュ, 24.2.4.2

作成, 24.2.2, 24.2.4.2.2, 24.2.4.2.2

CURRVAL, 24.2.4.1.2

データ・ディクショナリ・ビューの参照, 24.4

削除, 24.2.5

管理, 24.2.1

NEXTVAL, 24.2.4.1.1

Oracle Real Application Clusters, 24.2.2

SERVERパラメータ

ネット・サービス名, 32.3.3.1

サーバー・パラメータ・ファイル

作成, 2.6.3

定義, 2.6.1

エクスポート, 2.6.7

移行, 2.6.2

リカバリ, 2.6.9

RMANバックアップ, 2.6.8

初期化パラメータ値の設定, 2.6.5

SPFILE初期化パラメータ, 2.6.4

STARTUPコマンドの動作, 2.6.1

パラメータ設定の表示, 2.6.10

サーバー・プロセス

アーカイバ(ARCn), 5.5

バックグラウンド, 5.5

チェックポイント(CKPT), 5.5

データベース・ライター(DBWn), 5.5

専用, 5.1.1

ディスパッチャ(Dnnn), 5.5

ディスパッチャ, 5.3.4.3

ログ・ライター(LGWR), 5.5

ロックの監視, 8.2.1

プロセス・モニター(PMON), 5.5

リカバラ(RECO), 5.5

共有サーバー, 5.1.2

システム・モニター(SMON), 5.5

トレース・ファイル, 8.1.1

サーバー生成アラート, 8.1.2 サーバー

2フェーズ・コミットでのロール, 34.2.2

サービス名

データベース・リンク, 32.2.4

サービス

自動起動の制御, 3.1.3

SRVCTLとOracle Restartを使用した作成, 4.2.10

ロールベース, 3.1.3

分散トランザクションのセッション・ツリー

クライアント, 34.2.1

コミット・ポイント・サイト, 34.2.5, 34.2.5.2

データベース・サーバー, 34.2.2

定義, 34.2

グローバル・コーディネータ, 34.2.4

ローカル・コーディネータ, 34.2.3

トランザクションのトレース, 35.3.2

セッション

アクティブ, 5.8.2

非アクティブ, 5.8.3

トランザクションのアドバイスの設定, 35.4.3.3

停止, 5.8

SET TIME_ZONE句

ALTER SESSION, 2.4.9.1

CREATE DATABASE, 2.4.9.1

SET TRANSACTION文

トランザクションの命名, 35.2

SGA

「システム・グローバル領域」を参照

SGA_MAX_SIZE初期化パラメータ, 6.4.1.3 SGA_TARGET初期化パラメータ, 6.4.1.4 共有データベース・リンク

構成, 32.3.3

作成, 32.3.2

専用サーバー, リンクの作成, 32.3.3.1

使用するかどうかの判断, 32.3.1

例, 31.2.8

共有サーバー, リンクの作成, 32.3.3.2

SHAREDキーワード

CREATE DATABASE LINK句, 32.3.2

共有サーバー, 5.1.2

ディスパッチャの構成, 5.3.4

データ・ディクショナリ・ビューの参照, 5.3.6

無効化, 5.3.3.2, 5.3.5

初期化パラメータ, 5.3.1

トレース出力の解析, 8.1.1.3

最小サーバー数の設定, 5.3.3.2

プロセス用トレース・ファイル, 8.1.1

共有SQL

リモート文および分散型の文, 31.4.3

SHARED_MEMORY_ADDRESSパラメータ, 6.4.2.8.2 オンラインによるセグメントの縮小, 19.3.3 停止

デフォルト・モード, 3.3.1

SHUTDOWNコマンド

IMMEDIATE句, 3.3.2

中断, 3.3.5

NORMAL句, 3.3.1

サイレント・モード

DBCAを使用したデータベースの作成, 2.2.2

Simple Network Management Protocol(SNMP)のサポート

データベース管理, 31.3.4.3

単一ファイル表領域

説明, 14.2.2

単一インスタンス

定義, 2.3

単一表ハッシュ・クラスタ, 23.3.2 サイト自律性

分散データベース, 31.3.1

SKIP_CORRUPT_BLOCKSプロシージャ, 25.3.3.1

DBMS_REPAIR, 25.2.1

例, 25.4.5

チェーン・ステップのスキップ, 29.6.15 「スナップショットが古すぎます」エラー, 16.2.2.1 SORT_AREA_SIZE初期化パラメータ

索引作成, 21.2.1

領域

未使用の割当て解除, 19.3.4

未使用の再生, 19.3

領域割当て

再開可能, 19.2

領域管理

データ型, 領域の要件, 19.5

未使用領域の割当て解除, 19.3

セグメント・アドバイザ, 19.3

縮小セグメント, 19.3

SPACE_ERROR_INFOプロシージャ, 19.2.4.1 SPFILE初期化パラメータ, 2.6.4

クライアント・システムからの指定, 3.1.2.2

SQL

発行, 1.3

SQLエラー

SQL修復アドバイザを使用した修復, 9.8

SQLパッチ

使用禁止, 9.8.3

削除, 9.8.3

表示, 9.8.3

SQL修復アドバイザ

説明, 9.8.1

SQLエラーの修復, 9.8

実行, 9.8.2

SQL文

分散データベース, 31.4.1

SQLテスト・ケース・ビルダー, 9.1.1 SQL_TRACE初期化パラメータ

トレース・ファイル, 8.1.1

SQL*Loader

説明, 1.8

SQL*Plus, 1.3

説明, 1.3.1

接続, 1.3.2

起動, 3.1.4

データベースの起動, 3.1.1.1

インスタンスの起動, 3.1.1.1

SRVCTL

add asmコマンド, 4.4

addコマンド, 使用方法の説明, 4.4

add databaseコマンド, 4.4

add listenerコマンド, 4.4

add onsコマンド, 4.4

ディスク・グループの追加, 4.4

大/小文字の区別, 4.4, 4.4

コマンドの大/小文字の区別, 4.4, 4.4

コマンド・リファレンス, 4.4

コマンド, 大/小文字の区別, 4.4, 4.4

コンポーネント名, 4.4

config asmコマンド, 4.4

configコマンド, 使用方法の説明, 4.4

config databaseコマンド, 4.4

config listenerコマンド, 4.4

config onsコマンド, 4.4

config serviceコマンド, 4.4

データベース・サービスの作成と削除, 4.2.10

disable asmコマンド, 4.4

disableコマンド, 使用方法の説明, 4.4

disable databaseコマンド, 4.4

disable diskgroupコマンド, 4.4

disable listenerコマンド, 4.4

disable onsコマンド, 4.4

disable serviceコマンド, 4.4

enable asmコマンド, 4.4

enableコマンド, 使用方法の説明, 4.4

enable databaseコマンド, 4.4

enable diskgroupコマンド, 4.4

enable listenerコマンド, 4.4

enable onsコマンド, 4.4

enable serviceコマンド, 4.4

getenv asmコマンド, 4.4

getenvコマンド, 使用方法の説明, 4.4

getenv databaseコマンド, 4.4

getenv listenerコマンド, 4.4

ヘルプ, 4.2.2

modify asmコマンド, 4.4

modifyコマンド, 使用方法の説明, 4.4

modify databaseコマンド, 4.4

modify listenerコマンド, 4.4

modify onsコマンド, 4.4

modify serviceコマンド, 4.4

実行準備, 4.2.1

リファレンス, 4.4

remove asmコマンド, 4.4

removeコマンド, 使用方法の説明, 4.4

remove databaseコマンド, 4.4

remove diskgroupコマンド, 4.4

remove listenerコマンド, 4.4

remove onsコマンド, 4.4

remove serviceコマンド, 4.4

setenv asmコマンド, 4.4

setenvコマンド, 使用方法の説明, 4.4

setenv databaseコマンド, 4.4

setenv listenerコマンド, 4.4

start asmコマンド, 4.4

startコマンド, 使用方法の説明, 4.4

start databaseコマンド, 4.4

start diskgroupコマンド, 4.4

start homeコマンド, 4.4

start listenerコマンド, 4.4

start onsコマンド, 4.4

start serviceコマンド, 4.4

status asmコマンド, 4.4

statusコマンド, 使用方法の説明, 4.4

status databaseコマンド, 4.4

status diskgroupコマンド, 4.4

status homeコマンド, 4.4

status listenerコマンド, 4.4

status onsコマンド, 4.4

status serviceコマンド, 4.4

stop asmコマンド, 4.4

stopコマンド, 使用方法の説明, 4.4

stop databaseコマンド, 4.4

stop diskgroupコマンド, 4.4

stop homeコマンド, 4.4

stop listenerコマンド, 4.4

stop onsコマンド, 4.4

stop serviceコマンド, 4.4

unsetenv asmコマンド, 4.4

unsetenvコマンド, 使用方法の説明, 4.4

unsetenv databaseコマンド, 4.4

unsetenv listenerコマンド, 4.4

SRVCTL停止オプション

デフォルト, 3.3.1

STALE状態

REDOログ・メンバー, 12.5.2

停止状態チェーン(スケジューラ), 29.6.18 スタンバイ転送モード

定義, 13.5.2

データベースの起動, 3.1

強制的, 3.1.5.5

Oracle Enterprise Manager, 3.1.1.3

リカバリ, 3.1.5.6

Recovery Manager, 3.1.1.2

制限モード, 3.1.5.4

SQL*Plus, 3.1.1.1

制御ファイルを使用できない場合, 3.1.5

REDOログを使用できない場合, 3.1.5

インスタンスの起動

システム起動時に自動的に起動, 3.1.5.7

データベースのクローズとマウント, 3.1.5.3

データベース名の競合, 2.5.2.1

強制的, 3.1.5.5

データベースのマウントとオープン, 3.1.5.1

通常, 3.1.5.1

Oracle Enterprise Manager, 3.1.1.3

リカバリ, 3.1.5.6

Recovery Manager, 3.1.1.2

リモート・インスタンスの起動, 3.1.5.8

制限モード, 3.1.5.4

SQL*Plus, 3.1.1.1

制御ファイルを使用できない場合, 3.1.5

REDOログを使用できない場合, 3.1.5

データベースをマウントしない, 3.1.5.2

起動

SGAの割当て

起動, 6.4.2.8.2

データベース・サービス, 制御, 3.1.3 STARTUPコマンド

デフォルトの動作, 2.6.1

NOMOUNT句, 2.3.8

RECOVER句, 3.1.5.6

データベースの起動, 3.1.1.1, 3.1.5

分散データベースでの文の透過性

管理, 32.7

統計

表に関する自動収集, 20.5

STATISTICS_LEVEL初期化パラメータ

自動統計収集, 20.5

stderr

ローカル外部ジョブ, 28.3.1.2.1, 28.3.1.2.2, 29.2.10

取得, 28.3.1.2.1, 28.3.1.2.2, 29.2.10

stdout

ローカル外部ジョブ, 28.3.1.2.1, 28.3.1.2.2, 29.2.10

取得, 28.3.1.2.1, 28.3.1.2.2, 29.2.2.9, 29.2.10

ステップ, チェーン

削除, 29.6.11

停止

チェーン・ステップ, 29.6.13

チェーン, 29.6.12

ジョブ, 29.2.5

記憶域パラメータ

INITIAL, 20.6.2

INITRANS, 変更, 20.6.2

MAXTRANS, 変更, 20.6.2

MINEXTENTS, 20.6.2

NEXT, 20.6.2

PCTINCREASE, 20.6.2

ストレージ・サブシステム

ファイルと物理デバイスのマッピング, 15.9, 15.9.4.3

ストアド・プロシージャ

権限の管理, 32.6.3.4

リモート・オブジェクトのセキュリティ, 32.6.3.4

データベースに対するコマンドとSQLの発行, 1.3 副問合せ

リモート更新, 31.4.1

分散データベースでの文の透過性, 32.7

SunSoft社のSunNet Manager, 31.3.4.3 サポート・ワークベンチ, 9.1.3.5

Oracle ASMインスタンス, 9.3

問題を表示, 9.3

SWITCH LOGFILE句

ALTER SYSTEM文, 12.6

シノニム, 24.3.3

作成, 24.3.2, 32.6.2.1

データ・ディクショナリ・ビューの参照, 24.4

定義と作成, 32.6.2.1

依存性の表示, 18.11.2.2

削除, 24.3.4

例, 32.6.2.1

分散データベースでの位置の透過性, 32.6.2

管理, 24.3.1, 24.3.4

リモート・データベースでの権限の管理, 32.6.2.2

分散データベースでの名前解決, 31.4.9

プライベート, 24.3.1

パブリック, 24.3.1

リモート・オブジェクトのセキュリティ, 32.6.2.2

SYSアカウント

デフォルトのパスワード, 1.5.2

所有オブジェクト, 1.5.2.1

権限, 1.5.2.1

CREATE DATABASE文のパスワードの指定, 2.4.1

データベース・リソース・マネージャのSYS_GROUP, 27.7.5 SYSAUX表領域, 14.2

説明, 2.4.3

名前の変更できない, 14.8

データベース作成時に作成, 2.3.9, 2.4.3

DATAFILE句, 2.4.3

占有データの監視, 14.10.1

占有データの移動, 14.10.2

SYSDBAシステム権限

パスワード・ファイルへのユーザーの追加, , 1.7.3

データベースへの接続, 1.6.1.1

権限所有者の判別, 1.7.3.2

付与と取消し, 1.7.3.1

SYSOPERシステム権限

パスワード・ファイルへのユーザーの追加, , 1.7.3

データベースへの接続, 1.6.1.1

権限所有者の判別, 1.7.3.2

付与と取消し, 1.7.3.1

SYSTEMアカウント

デフォルトのパスワード, 1.5.2

所有オブジェクト, 1.5.2.2

CREATE DATABASE文のパスワードの指定, 2.4.1

システム変更番号

分散データベース・システムでの調整, 34.3.2.2

インダウト・トランザクション, 35.5.1.2

V$DATAFILEを使用した情報表示, 15.10

割り当てられる時期, 12.1.2

システム・グローバル領域, 6.2

順序番号キャッシュの保持

バッファ・キャッシュ・サイズの指定, 6.4.2.2

システム・モニター・プロセス(SMON), 5.5 システム権限

ADMINISTER_RESOURCE_MANAGER, 27.1.3

外部表, 20.13.6

SYSTEM表領域

名前の変更できない, 14.8

データベース作成時に作成, 2.3.9

ローカル管理表領域の作成, 2.3.9, 2.4.2

オフライン化することの制限, 15.4

作成されるとき, 14.2

データベース・リソース・マネージャのSYSTEM_PLAN, 27.7.5

T

表のサイズ

見積り, 19.7.1

表

説明, 20.1

列の追加, 20.6.6

エクステントの割当て, 20.6.4

変更, 20.6.1

物理属性の変更, 20.6.2

分析, 18.2

クラスタ(ハッシュ)

「ハッシュ・クラスタ」を参照

圧縮, 20.2.6 作成, 20.3 データ・ディクショナリ・ビューの参照, 20.14 セグメント作成の遅延, 20.2.8 作成前の設計, 20.2.1 削除, 20.10 列の削除, 20.6.8 サイズの見積り, 20.2.10 領域使用の見積り, 19.7.1 外部, 20.13 フラッシュバック・ドロップ, 20.11 フラッシュバック表, 20.9 管理のガイドライン, 20.2 ハッシュ・クラスタ化

「ハッシュ・クラスタ」を参照

列の長さの拡張, 20.6.5 索引構成表, 20.12 キー保存, 24.1.5.1 索引の制限, 21.2.4 管理, 20 列定義の変更, 20.6.5 移動, 20.6.3 作成のパラレル化, 20.2.4, 20.3.3 読取り専用, 20.6.9 オンライン再定義, 20.7 列名の変更, 20.6.7 エラーが発生した変更の調査と取消し, 20.8 作成時の制限事項, 20.2.11 記憶域パラメータの設定, 20.2.10 縮小, 19.3.3 場所の指定, 20.2.3 統計収集, 自動, 20.5 一時, 20.3.2 切捨て, 18.3 リカバリ不能(NOLOGGING), 20.2.5 構造の妥当性チェック, 18.2.2 表領域セット, 14.13.5.2 表領域

データファイルの追加, 15.2

ユーザー割当て制限の割当て, 14.1.2

自動拡張, 14.7.1

自動セグメント領域管理, 14.2.1.2

bigfile, 2.4.8, 14.2.2

デフォルト記憶域パラメータのチェック, 14.14.1

圧縮, 14.2.3

XMLTypeを含む, 14.13.3

データベース作成時にUNDO表領域を作成, 2.4.4, 2.4.8.2

データ・ディクショナリ・ビューの参照, 14.14

DBMS_SPACE_ADMINパッケージ, 14.11

デフォルト一時表領域, 作成, 2.4.6, 2.4.8.2

欠陥の検出と修復, 14.11

ローカル管理の問題の診断と修復, 14.11

ディクショナリ管理, 14.2.2.2

削除, 14.9

暗号化, 14.2.4

管理のガイドライン, 14.1

サイズの拡大, 14.7.1

ファイルのリスト, 14.14.2

空き領域のリスト, 14.14.3

ローカル管理, 14.2.1

ローカル管理のSYSTEM, 2.4.2

ローカル管理の一時, 14.2.5.1

位置, 15.1.3

ローカル管理へのSYSTEMの移行, 14.12

複数のブロック・サイズ, 14.13.5.6

WORMデバイス上, 14.6.3

Oracle Managed Files, 管理, 17.5.1, 17.5.2

デフォルト・タイプの上書き, 2.4.8.2

割当て制限、割当て, 14.1.2

読取り専用, 14.6

名前変更, 14.7, 14.8

デフォルト・タイプの設定, 2.4.8.1

単一ファイル, 2.4.8, 2.4.8.2, 14.2.2, 14.7.3

非標準のブロック・サイズの指定, 14.3

SYSAUX, 14.2, 14.8

SYSAUX作成, 2.4.3

SYSAUX、管理, 14.10

SYSTEM, 14.2, 14.2.1, 14.6.1, 14.12

通常のオフライン化, 14.5.1

一時オフライン化, 14.5.1

ローカル管理内の一時ファイル, 14.2.5.1

一時, 14.2.5, 14.2.6.3

一時bigfile, 14.2.5.2

大きな索引の作成用の一時, 21.3.4

トランスポータブル

「トランスポータブル表領域」を参照

UNDO, 16.1 複数を使用, 14.1.1 Oracle Managed Filesの使用, 17.3.3 一時ファイル, 14.2.5.1

Oracle Managed Filesとして作成, 17.3.4

削除, 15.6

Oracle Managed Filesの削除, 17.4.1

一時セグメント

索引作成, 21.2.1

一時表

表領域への割当て, 20.3.2

作成, 20.3.2

一時表領域, デフォルト

データベース作成時に指定, 17.3.2.5

一時表領域

変更, 14.7.4

bigfile, 14.2.5.2

作成, 14.2.5.1

グループ, 14.2.6

デフォルトの名前変更, 14.8

縮小、ローカル管理, 14.7.5

ユーザー・セッションの停止

アクティブなセッション, 5.8.2

セッションの識別, 5.8.1

アクティブでないセッション, 例, 5.8.3

アクティブでないセッション, 5.8.3

テスト・ケース

ビルダー, SQL, 9.1.1

スレッド

オンラインREDOログ, 12.1.1

しきい値ベースのアラート

Oracle Enterprise Managerでの管理, 8.1.2.1

しきい値ベースのアラート

サーバー生成, 8.1.2

しきい値

アラートの設定, 19.1.1

タイム・ゾーン

ファイル, 2.4.9.2

データベース用の設定, 2.4.9.1

トレース・ファイル, 9.1.3.3

位置, 8.1.1

ログ・ライター・プロセス, 12.2.1.1

サイズ, 8.1.1.1

使用, 8.1.1

書き込む時期, 8.1.1.2

トレース・ファイル, 検索, 9.6 トレース, 9.1.3.3 トレース

ARCHIVELOGプロセス, 13.7

トランザクション制御文

分散トランザクション, 34.1.2

トランザクション障害

シミュレーション, 35.9

トランザクション管理

概要, 34.3

トランザクション処理

分散システム, 31.4

トランザクション

データベース・リンクのクローズ, 33.2

分散および2フェーズ・コミット, 31.4.6

インダウト, 34.3.1.2, 34.4, 34.4.3, 35.4

分散の命名, 35.2, 35.4.3.2

リモート, 31.4.4

アーカイブREDOログの転送, 13.5 透過的データ暗号化, 2.8.2, 14.2.4, 20.2.7 トランスポータブル・セット

「トランスポータブル表領域セット」を参照

トランスポータブル表領域セット

定義, 14.13.5

トランスポータブル表領域, 14.13

互換性に関する注意事項, 14.13.4

バックアップ機能を使用, 14.13.1

概要, 14.13.1

制限, 14.13.3

複数のブロック・サイズ, 14.13.5.6

プロシージャ, 14.13.5

使用するとき, 14.13.6

Enterprise Managerのウィザード, 14.13.1

XMLType, 14.13.3

データベース間での表領域のトランスポート

「トランスポータブル表領域」を参照

トリガー

無効化, 18.4.2

有効化, 18.4.1

.trmファイル, 9.1.3.3 TRUNCATE文

DROP ALL STORAGE, 18.3.3

DROP STORAGE, 18.3.3

DROP STORAGE句, 18.3.3

REUSE STORAGE, 18.3.3

REUSE STORAGE句, 18.3.3

表の削除と対比, 20.10

チューニング

表の分析, 33.4.2.2.2

コストベースの最適化, 33.4.2

2フェーズ・コミット

事例, 34.5

コミット・フェーズ, 34.3.2, 34.5.4

説明, 31.4.6

問題の検出, 35.4.1

分散トランザクション, 34.3

例, 34.5

情報消去フェーズ, 34.3.3

インダウト・トランザクション, 34.4, 34.4.3

フェーズ, 34.3

準備フェーズ, 34.3.1, 34.3.1.2

読取り専用ノードの認識, 34.3.1.1.2

コミット・ポイント強度の指定, 35.1

コミット・フェーズの手順, 34.3.2.1

分散トランザクションのセッション・ツリーのトレース, 35.3.2

データベース・リンクの表示, 35.3.1

U

UNDOアドバイザ, 16.4

UNDO管理

自動, 16.2

説明, 16.1

初期化パラメータ, 16.2.1

UNDOの保存期間

自動チューニング, 16.2.2.1

説明, 16.2.2

保証, 16.2.2.2

設定, 16.3

UNDOセグメント

インダウト分散トランザクション, 35.4.2

UNDO領域

データ・ディクショナリ・ビューの参照, 16.7

UNDO領域の管理

自動UNDO管理モード, 16.2

UNDO表領域

管理, 16.5

領域のアラートしきい値の管理, 16.5.6

固定サイズのサイズ変更, 16.4

UNDO表領域

データベース作成時に指定, 17.3.2.4

UNDO表領域

変更, 16.5.2

作成, 16.5.1

データ・ディクショナリ・ビューの参照, 16.7

削除, 16.5.3

監視, 16.7

PENDING OFFLINE状態, 16.5.4

名前変更, 14.8

データベース作成時に指定, 2.3.9, 2.4.4, 2.4.8.2

統計, 16.7

切替え, 16.5.4

ユーザー割当て, 16.5.5

UNDO_MANAGEMENT初期化パラメータ, 2.4.4 UNDO_TABLESPACE初期化パラメータ

UNDO表領域, 2.5.8.2

インスタンスの起動, 16.2.1

UNIQUEキー制約

対応する索引, 21.3.3.1

対応する索引の削除, 21.6

作成時に使用可能にする, 21.3.3

削除時の外部キー参照, 18.5.3.1

対応付けられた索引, 21.3.3

UNRECOVERABLE DATAFILE句

ALTER DATABASE文, 12.8

使用禁止索引, 21.2.11 更新

位置の透過性, 31.5.1.2

データベースのアップグレード, 2.1 USE_INDIRECT_DATA_BUFFERSパラメータ, 6.4.2.8.3 ユーザー・アカウント

事前定義, 2.8.1, 7.5

ユーザー名

SYSとSYSTEM, 1.5.2

USER_DB_LINKSビュー, 32.5.1, 32.5.1 USER_DUMP_DEST初期化パラメータ, 9.1.3.1 USER_RESUMABLEビュー, 19.2.4.1 ユーザー

表領域割当て制限の割当て, 14.1.2

新規作成したデータベース, 2.8.1

数の制限, 2.5.10

事前定義, 2.8.1

セッション, 停止, 5.8.3

ユーティリティ

データベース管理者用, 1.8

SQL*Loader, 1.8

UTLCHAIN.SQLスクリプト

連鎖行のリスト, 18.2.3.1

UTLCHN1.SQLスクリプト

連鎖行のリスト, 18.2.3.1

UTLLOCKT.SQLスクリプト, 8.2.1

V

V$ARCHIVEビュー, 13.8

V$ARCHIVE_DESTビュー

アーカイブ先の状態の取得, 13.4.2

V$BLOCKING_QUIESCEビュー, 3.4.1 V$BUFFER_POOLビュー, 6.4.2.2.1 V$CLONEDFILEビュー, 2.9.3 V$DATABASEビュー, 13.8.1 V$DBLINKビュー, 32.5.2 V$DIAG_CRITICAL_ERROR view, 9.1.4 V$DIAG_INFOビュー, 9.1.4 V$DISPATCHERビュー

共有サーバー・ディスパッチャの監視, 5.3.4.4

V$DISPATCHER_RATEビュー

共有サーバー・ディスパッチャの監視, 5.3.4.4

V$ENCRYPTED_TABLESPACESビュー, 14.2.4, 14.14 V$INSTANCEビュー

データベースの静止状態の確認, 3.4.3

V$LOGビュー, 12.9, 13.8

アーカイブ状態の表示, 13.8

V$LOG_HISTORYビュー, 12.9 V$LOGFILEビュー, 12.9

ログ・ファイルの状態, 12.5.2

V$OBJECT_USAGEビュー

索引の使用状況の監視, 21.4.6

V$PWFILE_USERSビュー, 1.7.3.2 V$QUEUEビュー

共有サーバー・ディスパッチャの監視, 5.3.4.4

V$RESULT_CACHE_STATISTICSビュー, 6.4.2.7, 6.4.2.7 V$ROLLSTATビュー

UNDOセグメント, 16.7

V$SESSIONビュー, 5.8.3 V$SYSAUX_OCCUPANTSビュー

SYSAUX表領域の占有データ, 14.10.2

V$THREADビュー, 12.9 V$TIMEZONE_NAMESビュー

タイム・ゾーン表の情報, 2.4.9.2

V$TRANSACTIONビュー

UNDO表領域情報, 16.7

V$UNDOSTATビュー

UNDO表領域の統計, 16.7

V$VERSIONビュー, 1.4.2 VALIDATE STRUCTUREオプション

ANALYZE文, 18.2.2

VALIDATE STRUCTURE ONLINE句

ANALYZE文, 18.2.2

ブロックの検証

REDOログ・ファイル, 12.7

表示

アラート, 19.1.2

インシデント・パッケージの詳細, 9.10.3.1

SQLパッチ, 9.8.3

ビュー

作成, 24.1.2

エラー付きで作成, 24.1.2.3

データ・ディクショナリ

アーカイブREDOログ, 13.8.1

クラスタ, 22.6

制御ファイル, 11.8

データファイル, 15.10

データベース, 2.11

データベース常駐接続プーリング, 5.4.3

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

ハッシュ・クラスタ, 23.6

索引, 21.7

メモリー管理, 6.6.2

Oracle Scheduler, 30.6.2

REDOログ, 12.9

スキーマ・オブジェクト, 18.11.2

順序, 24.4

共有サーバー, 5.3.6

スキーマ・オブジェクトの領域使用, 19.6.2

シノニム, 24.4

表, 20.14

表領域, 14.14

UNDO領域, 16.7

ビュー, 24.4

データ・ディクショナリ・ビュー, 24.4 DBA_2PC_NEIGHBORS, 35.3.2 DBA_2PC_PENDING, 35.3.1 DBA_DB_LINKS, 32.5.1 DBA_RESUMABLE, 19.2.4.1 依存性の表示, 18.11.2.2 削除, 24.1.7 ファイル・マッピング・ビュー, 15.9.3.3 FOR UPDATE句, 24.1.2 無効, 24.1.4 結合

「結合ビュー」を参照

分散データベースでの位置の透過性, 32.6.1 管理, 24.1, 24.1.3 権限の管理, 32.6.1 分散データベースでの名前解決, 31.4.9 ORDER BY句, 24.1.2 リモート・オブジェクトのセキュリティ, 32.6.1 制限, 24.1.4 USER_RESUMABLE, 19.2.4.1 使用, 24.1.4 V$ARCHIVE, 13.8 V$ARCHIVE_DEST, 13.4.2 V$DATABASE, 13.8.1 V$LOG, 13.8 V$LOGFILE, 12.5.2 V$OBJECT_USAGE, 21.4.6 ワイルドカード, 24.1.2.2 WITH CHECK OPTION, 24.1.2 仮想列, 20.1

索引付け, 21.2.2

W

ウォレット、Oracle, 14.2.4, 20.2.7

ワイルドカード

ビュー, 24.1.2.2

ウィンドウ・グループ

作成, 29.7.4.2

無効化, 29.7.4.7

削除, 29.7.4.3

メンバーの削除, 29.7.4.5

有効化, 29.7.4.6

ジョブ・スケジューリングとジョブ優先度の管理, 29.7.4

概要, 28.2.10.2

ウィンドウ・ログ, 29.7.3 ウィンドウ(スケジューラ)

変更, 29.7.3.3

クローズ, 29.7.3.5

作成, 29.7.3.2

無効化, 29.7.3.7

削除, 29.7.3.6

有効化, 29.7.3.8

オープン, 29.7.3.4

重複, 28.2.9.1

概要, 28.2.9

ウィンドウ, ジョブ・スケジューリングとリソース割当ての管理, 29.7.3 ワークロード

データベース・サービスでの管理, 2.7

WORMデバイス

読取り専用表領域, 14.6.3

WRH$_UNDOSTATビュー, 16.7

X

XMLType

トランスポータブル表領域, 14.13.3

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。