Oracle® Database

概要

11gリリース2(11.2)

B56306-06(原本部品番号:E40540-04)

2015年5月

Oracle Database概要, 11gリリース2(11.2)

B56306-06

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

原本著者: Lance Ashdown、Tom Kyte

原本協力者: Drew Adams、David Austin、Vladimir Barriere、Hermann Baer、David Brower、Jonathan Creighton、Bjørn Engsig、Steve Fogel、Bill Habeck、Bill Hodak、Yong Hu、Pat Huey、Vikram Kapoor、Feroz Khan、Jonathan Klein、Sachin Kulkarni、Paul Lane、Adam Lee、Yunrui Li、Bryn Llewellyn、Rich Long、Barb Lundhild、Neil Macnaughton、Vineet Marwah、Mughees Minhas、Sheila Moore、Valarie Moore、Gopal Mulagund、Paul Needham、Gregory Pongracz、John Russell、Vivian Schupmann、Shrikanth Shankar、Cathy Shea、Susan Shepard、Jim Stenoish、Juan Tellez、Lawrence To、Randy Urbano、Badhri Varanasi、Simon Watt、Steve Wertheimer、Daniel Wong

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

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

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

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 およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

内容

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

1 Oracle Databaseの概要

- リレーショナル・データベースの概要

- データベース管理システム(DBMS)

- リレーショナル・モデル

- リレーショナル・データベース管理システム(RDBMS)

- Oracle Databaseの歴史の概要

- スキーマ・オブジェクト

- 表

- 索引

- データ・アクセス

- Structured Query Language(SQL)

- PL/SQLとJava

- トランザクションの管理

- トランザクション

- データ同時実行性

- データ整合性

- Oracle Databaseアーキテクチャ

- データベースおよびインスタンス

- データベース記憶域構造

- データベース・インスタンス構造

- アプリケーションおよびネットワークのアーキテクチャ

- Oracle Databaseドキュメントのロードマップ

- 初級グループ

- 中級グループ

- 上級グループ

第I部 Oracleリレーショナル・データ構造

2 表と表クラスタ

- スキーマ・オブジェクトの概要

- スキーマ・オブジェクトのタイプ

- スキーマ・オブジェクトの格納

- スキーマ・オブジェクトの依存性

- SYSスキーマとSYSTEMスキーマ

- サンプル・スキーマ

- 表の概要

- 列と行

- 例: CREATE TABLE文とALTER TABLE文

- Oracleデータ型

- 整合性制約

- オブジェクト表

- 一時表

- 外部表

- 表の記憶域

- 表の圧縮

- 表クラスタの概要

- 索引付きクラスタの概要

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

3 索引と索引構成表

- 索引の概要

- 索引の特性

- Bツリー索引

- ビットマップ索引

- ファンクション索引

- アプリケーション・ドメイン索引

- 索引記憶域

- 索引構成表の概要

- 索引構成表の特性

- 行オーバーフロー領域付きの索引構成表

- 索引構成表の2次索引

4 パーティション、ビューおよびその他のスキーマ・オブジェクト

- パーティションの概要

- パーティションの特性

- パーティション表

- パーティション索引

- パーティション索引構成表

- ビューの概要

- ビューの特性

- 更新可能な結合ビュー

- オブジェクト・ビュー

- マテリアライズド・ビューの概要

- マテリアライズド・ビューの特性

- マテリアライズド・ビューのリフレッシュ方法

- クエリー・リライト

- 順序の概要

- 順序の特性

- 順序への同時アクセス

- ディメンションの概要

- ディメンションの階層構造

- ディメンションの作成

- シノニムの概要

5 データ整合性

- データ整合性の概要

- データ整合性を保証する方法

- 整合性制約の利点

- 整合性制約のタイプ

- NOT NULL整合性制約

- 一意制約

- 主キー制約

- 外部キー制約

- チェック制約

- 整合性制約の状態

- 変更されたデータおよび既存のデータのチェック

- 遅延可能制約

- 制約チェックの例

6 データ・ディクショナリと動的パフォーマンス・ビュー

- データ・ディクショナリの概要

- データ・ディクショナリの内容

- データ・ディクショナリの記憶域

- Oracle Databaseでのデータ・ディクショナリの使用方法

- 動的パフォーマンス・ビューの概要

- 動的パフォーマンス・ビューの内容

- 動的パフォーマンス・ビューの記憶域

- データベース・オブジェクト・メタデータ

第II部 Oracleデータ・アクセス

7 SQL

- SQLの概要

- SQLデータ・アクセス

- SQL規格

- SQL文の概要

- データ定義言語(DDL)文

- データ操作言語(DML)文

- トランザクション制御文

- セッション制御文

- システム制御文

- 埋込みSQL文

- オプティマイザの概要

- オプティマイザの使用

- オプティマイザ・コンポーネント

- アクセス・パス

- オプティマイザ統計

- オプティマイザ・ヒント

- SQL処理の概要

- SQL処理の段階

- Oracle DatabaseによるDML処理方法

- Oracle DatabaseによるDDLの処理方法

8 サーバー側プログラミング: PL/SQLとJava

- サーバー側プログラミングの概要

- PL/SQLの概要

- PL/SQLサブプログラム

- PL/SQLパッケージ

- PL/SQL無名ブロック

- PL/SQLの言語構造

- PL/SQLのコレクションとレコード

- PL/SQLの実行方法

- Oracle DatabaseにおけるJavaの概要

- Java仮想マシン(JVM)の概要

- Javaプログラミング環境

- トリガーの概要

- トリガーの利点

- トリガーのタイプ

- トリガーのタイミング

- トリガーの作成

- トリガーの実行

- トリガーの記憶域

第III部 Oracleトランザクションの管理

9 データの同時実行性と整合性

- データの同時実行性と整合性の概要

- マルチバージョン読取り一貫性

- ロックのメカニズム

- ANSI/ISOトランザクション分離レベル

- Oracle Databaseのトランザクション分離レベルの概要

- コミット読取り分離レベル

- シリアライズ可能分離レベル

- 読取り専用分離レベル

- Oracle Databaseのロック・メカニズムの概要

- ロック動作の概要

- ロックの使用

- ロック・モード

- ロック変換とロックの段階的拡大

- ロックの期間

- ロックとデッドロック

- 自動ロックの概要

- DMLロック

- DDLロック

- システム・ロック

- 手動データ・ロックの概要

- ユーザー定義ロックの概要

10 トランザクション

- トランザクションの概要

- サンプル・トランザクション: 口座の借方と貸方

- トランザクションの構造

- 文レベルの原子性

- システム変更番号(SCN)

- トランザクション制御の概要

- トランザクション名

- アクティブなトランザクション

- セーブポイント

- トランザクションのロールバック

- トランザクションのコミット

- 自律型トランザクションの概要

- 分散トランザクションの概要

- 2フェーズ・コミット

- インダウト・トランザクション

第IV部 Oracleデータベース記憶域構造

11 物理記憶域構造

- 物理記憶域構造の概要

- データベース・ファイル格納のメカニズム

- Oracle Automatic Storage Management(Oracle ASM)

- Oracle Managed Filesおよびユーザー管理ファイル

- データファイルの概要

- データファイルの使用

- 永続データファイルと一時データファイル

- オンライン・データファイルとオフライン・データファイル

- データファイルの構造

- 制御ファイルの概要

- 制御ファイルの使用

- 多重制御ファイル

- 制御ファイルの構造

- オンラインREDOログの概要

- オンラインREDOログの使用

- Oracle DatabaseでのオンラインREDOログの書込み方法

- オンラインREDOログの構造

12 論理記憶域構造

- 論理記憶域構造の概要

- 論理記憶域階層

- 論理領域管理

- データ・ブロックの概要

- データ・ブロックとオペレーティング・システム・ブロック

- データ・ブロックの形式

- データ・ブロックの圧縮

- データ・ブロック内の領域管理

- エクステントの概要

- エクステントの割当て

- エクステントの割当て解除

- エクステントの記憶域パラメータ

- セグメントの概要

- ユーザー・セグメント

- 一時セグメント

- UNDOセグメント

- セグメント領域と最高水位標

- 表領域の概要

- 永続表領域

- 一時表領域

- 表領域モード

- 表領域ファイル・サイズ

第V部 Oracleインスタンス・アーキテクチャ

13 Oracleデータベース・インスタンス

- Oracleデータベース・インスタンスの概要

- データベース・インスタンスの構造

- データベース・インスタンス構成

- インスタンスの起動と停止の概要

- インスタンスとデータベースの起動の概要

- データベースとインスタンスの停止の概要

- チェックポイントの概要

- チェックポイントの目的

- Oracle Databaseでチェックポイントが開始される時期

- インスタンス・リカバリの概要

- インスタンス・リカバリの目的

- Oracle Databaseでインスタンス・リカバリが実行される時期

- インスタンス・リカバリでのチェックポイントの重要性

- インスタンス・リカバリのフェーズ

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

- 初期化パラメータ

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

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

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

- 診断ファイルの概要

- 自動診断リポジトリ

- アラート・ログ

- トレース・ファイル

14 メモリー・アーキテクチャ

- Oracle Databaseのメモリー構造の概要

- 基本的なメモリー構造

- Oracle Databaseのメモリー管理

- ユーザー・グローバル領域の概要

- プログラム・グローバル領域の概要

- PGAの内容

- 専用サーバー・モードおよび共有サーバー・モードにおけるPGAの使用

- システム・グローバル領域の概要

- データベース・バッファ・キャッシュ

- REDOログ・バッファ

- 共有プール

- ラージ・プール

- Javaプール

- ストリーム・プール

- 固定SGA

- ソフトウェア・コード領域の概要

15 プロセス・アーキテクチャ

- プロセスの概要

- マルチ・プロセスOracle Databaseシステム

- プロセスのタイプ

- クライアント・プロセスの概要

- クライアントおよびサーバー・プロセス

- 接続とセッション

- サーバー・プロセスの概要

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

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

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

- 必須のバックグラウンド・プロセス

- オプションのバックグラウンド・プロセス

- スレーブ・プロセス

16 アプリケーションおよびネットワークのアーキテクチャ

- Oracleアプリケーション・アーキテクチャの概要

- クライアント/サーバー・アーキテクチャの概要

- 複数層アーキテクチャの概要

- グリッド・アーキテクチャの概要

- Oracleネットワーク・アーキテクチャの概要

- Oracle Net Servicesの動作

- Oracle Net Listener

- 専用サーバー・アーキテクチャ

- 共有サーバー・アーキテクチャ

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

- プログラム・インタフェースの概要

- プログラム・インタフェースの構造

- プログラム・インタフェース・ドライバ

- オペレーティング・システムの通信ソフトウェア

第VI部 Oracle Databaseの管理と開発

17 データベース管理者および開発者向けのトピック

- データベース・セキュリティの概要

- ユーザー・アカウント

- 認証

- 暗号化

- Oracle Data Redaction

- アクセス制御

- 監視

- 高可用性の概要

- 高可用性と計画外停止時間

- 高可用性と計画停止時間

- グリッド・コンピューティングの概要

- データベース・サーバー・グリッド

- データベース記憶域グリッド

- データ・ウェアハウスとビジネス・インテリジェンスの概要

- データ・ウェアハウスとOLTP

- データ・ウェアハウスのアーキテクチャ

- 抽出、変換、ロード(ETL)の概要

- ビジネス・インテリジェンス

- Oracleにおける情報統合の概要

- 統合されたアクセス

- 情報の共有

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

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

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

- Oracle Enterprise Manager

- SQL*Plus

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

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

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

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

- バックアップおよびリカバリ

- メモリーの管理

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

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

19 データベース開発者の概念

- データベース開発者の業務

- データベース開発者向けのツール

- SQL Developer

- Oracle Application Express

- Oracle JDeveloper

- Oracle JPublisher

- Oracle Developer Tools for Visual Studio .NET

- データベース開発者のためのトピック

- アプリケーション設計およびチューニングの原則

- クライアント側のデータベース・プログラミング

- グローバリゼーション・サポート

- 非構造化データ

用語集

索引

はじめに

このマニュアルでは、オブジェクト・リレーショナル・データベース管理システムであるOracleデータベース・サーバーの、アーキテクチャや概念という側面の概要を説明します。Oracleデータベース・サーバーがどのように機能しているのかを説明し、他のマニュアルで説明される多くの実用的な情報のための概念的な基盤を提供します。このマニュアルの情報は、すべてのオペレーティング・システム上で稼働するOracleデータベース・サーバーを対象にしています。

この章の内容は次のとおりです。

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Database概要』は、Oracle Databaseの新規ユーザーである技術者ユーザー(主にデータベース管理者とデータベース・アプリケーションの開発者)を対象にしています。このマニュアルの対象読者は、他のリレーショナル・データベース用アプリケーションの管理または開発の経験者です。

このマニュアルを使用するには、次の知識が必要です。

- リレーショナル・データベースの一般的な概念

- 第1章「Oracle Databaseの概要」の概念と用語

- Oracleを実行しているオペレーティング・システムの環境

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

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入の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 Database 2日でデータベース管理者』

- 『Oracle Database 2日で開発者ガイド』

他の関連ドキュメントの詳細は、「Oracle Databaseドキュメントのロードマップ」を参照してください。

Oracle Databaseマニュアル・セットに含まれるマニュアルの多くでは、Oracle Databaseのインストール時にデフォルトでインストールされるシード・データベースのサンプル・スキーマを使用しています。これらのスキーマがどのように作成されているか、およびその使用方法については、『Oracle Databaseサンプル・スキーマ』を参照してください。

表記規則

このマニュアルでは、次の表記規則が使用されます。

規則

意味

太字

太字は、操作に関連付けられているグラフィカル・ユーザー・インタフェース(GUI)要素、または本文中や用語集で定義されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、コード例、画面に表示されるテキストまたはユーザーが入力するテキストを示します。

1 Oracle Databaseの概要

この章では、Oracle Databaseの概要について説明します。この章の内容は次のとおりです。

- リレーショナル・データベースの概要

- スキーマ・オブジェクト

- データ・アクセス

- トランザクションの管理

- Oracle Databaseアーキテクチャ

- Oracle Databaseドキュメントのロードマップ

リレーショナル・データベースの概要

すべての組織には、その要件を満たすために格納および管理する必要のある情報があります。たとえば、会社では従業員の人事管理レコードを収集し、管理する必要があります。この情報は、必要とする人が使用できるようにする必要があります。情報システムとは、情報を格納および処理するための形式が定められたシステムです。

情報システムは、フォルダを収納した一連の段ボール箱とフォルダの格納および取出し方法に関するルールとすることもできます。ただし、今日のほとんどの企業はデータベースを使用して情報システムを自動化しています。データベースとは、1つの単位として取り扱われる編成されたデータの集合です。データベースは、データベース・アプリケーションで使用するための関連情報の収集、格納、および取出しを目的としています。

データベース管理システム(DBMS)

データベース管理システム(DBMS)とは、データの格納、編成および取得を制御するソフトウェアです。通常、DBMSの要素は次のとおりです。

- カーネル・コード
このコードでは、DBMS用のメモリーと記憶域を管理します。

- メタデータのリポジトリ
このリポジトリは、通常、データ・ディクショナリと呼ばれます。

- 問合せ言語
この言語を使用してデータにアクセスできます。

データベース・アプリケーションとは、データにアクセスして操作するためにデータベースと対話するソフトウェア・プログラムです。

第一世代のデータベース管理システムには次のタイプがありました。

- 階層
階層データベースは、データをツリー構造に編成したものです。ファイルシステムの構造と同様に、各親レコードが1つ以上の子レコードを持ちます。

- ネットワーク
ネットワーク・データベースは、レコードが1対多の関係ではなく多対多の関係を持つ点を除いて、階層データベースと同じです。

第一世代のデータベース管理システムでは、事前に定義された厳密な関係に基づいてデータが格納されていました。データ定義言語がなかったため、データ構造の変更は困難でした。また、これらのシステムには簡単な問合せ言語がなく、このことがアプリケーション開発の妨げになっていました。

リレーショナル・モデル

独創性に富んだ1970年の論文「A Relational Model of Data for Large Shared Data Banks」において、E. F. Codd氏は、数学的な集合理論に基づいてリレーショナル・モデルを定義しました。今日、最も普及しているデータベース・モデルはリレーショナル・モデルです。

リレーショナル・データベースとは、リレーショナル・モデルに準拠したデータベースです。リレーショナル・モデルには次の特徴があります。

- 構造
詳細に定義されたオブジェクトによって、データベースのデータの格納またはアクセスが行われます。

- 操作
明確に定義されたアクションによって、アプリケーションはデータベースのデータおよび構造を操作できます。

- 整合性規則
整合性規則は、データベースのデータおよび構造に対する操作を制御します。

リレーショナル・データベースでは、データは一連の単純なリレーションに格納されます。リレーションは一連のタプルです。タプルは、順不同の一連の属性値です。

表は、行(タプル)と列(属性)の形式でのリレーションの2次元表現です。表の各行は同じ一連の列を持ちます。リレーショナル・データベースは、データをリレーション(表)に格納するデータベースです。たとえば、リレーショナル・データベースで会社の従業員に関する情報を従業員表、部門表、および給与表に格納できます。

関連項目:
Codd氏の論文の要約と論文は、http://dl.acm.org/citation.cfm?id=362685を参照してください。

リレーショナル・データベース管理システム(RDBMS)

リレーショナル・モデルは、リレーショナル・データベース管理システム(RDBMS)の基礎です。基本的に、RDBMSはデータをデータベース内に移動して格納し、格納したデータを取り出してアプリケーションで操作できるようにします。RDBMSでは、次のように操作のタイプが区別されます。

- 論理演算
この場合、アプリケーションは、必要な内容を指定します。たとえば、従業員の名前を要求したり、従業員レコードを表に追加します。

- 物理演算
この場合、RDBMSは、どのように実行すべきかを判断して演算を実行します。たとえば、アプリケーションが表に問合せを実行すると、データベースの索引を使用して要求した行が検索され、データがメモリーに読み込まれ、その他多くの手順が実行されてからユーザーに結果が戻されます。RDBMSがデータの格納と取得を行うため、物理演算はデータベース・アプリケーションに対して透過的です。

Oracle DatabaseはRDBMSです。ユーザー定義型、継承、ポリモフィズムなどのオブジェクト指向機能を実装したRDBMSは、オブジェクト・リレーショナル・データベース管理システム(ORDBMS)と呼ばれます。Oracle Databaseはリレーショナル・モデルを拡張したオブジェクト・リレーショナル・モデルであり、複雑なビジネス・モデルをリレーショナル・データベースに格納できます。

Oracle Databaseの歴史の概要

現行バージョンのOracle Databaseは、30年以上にわたる革新的な開発の成果です。Oracle Databaseの発展における重要事項は次のとおりです。

- オラクル社の設立
1977年、Larry Ellison、Bob Miner、およびEd Oatesはソフトウェア開発研究所でコンサルタント業を始め、Relational Software, Inc.(RSI)となりました。1983年、RSIはOracle Systems Corporationとなり、その後Oracle Corporationになりました。

- 最初の市販RDBMS
1979年にRSIは、SQLベースの最初の市販RDBMSとしてOracle V2(バージョン2)を発表しました。これはリレーショナル・データベースの歴史において画期的な出来事でした。

- 移植性の高いOracle Databaseのバージョン
1983年にリリースされたOracleバージョン3は、メインフレーム、ミニコンピュータ、およびPC上で動作する最初のリレーショナル・データベースでした。このデータベースはC言語で記述されており、複数のプラットフォームにデータベースを移植することが可能になりました。

- 同時実行性制御、データ配分、およびスケーラビリティの拡張
バージョン4では、マルチバージョンの読取り一貫性が導入されました。1985年にリリースされたバージョン5では、クライアント/サーバー・コンピューティングおよび分散データベース・システムがサポートされました。バージョン6では、ディスクI/O、行ロック、スケーラビリティ、バックアップおよびリカバリに対する拡張が行われました。また、バージョン6では、SQLを手続き型に拡張した独自のPL/SQL言語の最初のバージョンが導入されました。

- PL/SQLストアド・プログラム・ユニット
1992年にリリースされたOracle7では、PL/SQLストアド・プロシージャおよびトリガーが導入されました。

- オブジェクトとパーティション化
Oracle8は、オブジェクト・リレーショナル・データベースとして1997年にリリースされ、多数の新しいデータ型をサポートしています。さらに、Oracle8で大規模な表のパーティション化がサポートされました。

- インターネット・コンピューティング
1999年にリリースされたOracle8i Databaseには、インターネット・プロトコルのネイティブ・サポートおよびサーバー側でのJavaサポートが備えられていました。Oracle8iはインターネット・コンピューティング用に設計され、複数層環境へのデータベースのデプロイが可能になりました。

- Oracle Real Application Clusters(Oracle RAC)
2001年のOracle9i Databaseでは、Oracle RACが導入され、複数のインスタンスによる単一データベースへの同時アクセスが可能になりました。さらに、Oracle XML Database(Oracle XML DB)ではXMLの格納および問合せの機能が導入されました。

- グリッド・コンピューティング
2003年のOracle Database 10gでは、グリッド・コンピューティングが導入されました。このリリースでは、組織は低コストの商用サーバーに基づくグリッド・インフラストラクチャを構築することにより、コンピューティング資源を仮想化できるようになりました。これは、データベースの自己管理および自己チューニングを実現することを目標としていました。Oracle Automatic Storage Management(Oracle ASM)では、データベース・ストレージ管理を仮想化および簡素化することによって、この目標の実現を支援しました。

- 管理性、診断性、および可用性
2007年にリリースされたOracle Database 11gでは、管理者および開発者が変化するビジネス要件に迅速に適応できるようにする多数の新機能が導入されました。適応の鍵は、情報を統合し、できるかぎり自動化を採用することで、情報インフラストラクチャを簡素化することです。

関連項目:
Oracle Databaseの発展をまとめた記事は、http://www.oracle.com/technetwork/issue-archive/2007/07-jul/o4730-090772.htmlを参照してください。

スキーマ・オブジェクト

RDBMSの特性の1つは、物理データ記憶域が論理データ構造から独立していることです。Oracle Databaseにおいて、データベース・スキーマとは、論理データ構造またはスキーマ・オブジェクトの集合です。データベース・スキーマはデータベース・ユーザーによって所有され、そのユーザー名と同じ名前を持ちます。

スキーマ・オブジェクトは、ユーザーが作成する構造であり、データベース内のデータを直接参照します。データベースは多くのタイプのスキーマ・オブジェクトをサポートしますが、最も重要なのは表と索引です。

スキーマ・オブジェクトは、データベース・オブジェクトの1種です。プロファイルやロールなど、一部のデータベース・オブジェクトは、スキーマに常駐しません。

関連項目:
「スキーマ・オブジェクトの概要」

表

表は従業員などのエンティティを表します。表は、employeesなどの表名と、列の集合で定義されます。通常は、表を作成するとき、各列に名前、データ型、および幅を指定します。

表は行の集合です。列は、表として記述されるエンティティの属性を識別し、行は、エンティティのインスタンスを識別します。たとえば、従業員というエンティティの属性は、従業員IDや姓の列に対応します。行は特定の従業員を識別します。

オプションで表の各列に対して規則を指定できます。これらの規則は整合性制約と呼ばれます。一例としてNOT NULLの整合性制約があります。この制約では、列のすべての行に値が含まれている必要があります。

関連項目:

- 「表の概要」

- 第5章「データ整合性」

索引

索引は、表の1つ以上の列に対して作成可能なオプションのデータ構造です。索引によってデータ検索のパフォーマンスが向上する場合があります。1つの要求を処理するとき、データベースでは、要求された行を効率よく見つけるために使用可能な索引を使用します。索引は、アプリケーションが特定の行または行範囲を頻繁に問い合せる場合に便利です。

索引は、データから論理的にも物理的にも独立しています。したがって、索引を削除または作成しても、表または他の索引に影響はありません。索引を削除しても、すべてのアプリケーションは機能し続けます。

関連項目:
「索引の概要」

データ・アクセス

DBMSの一般的な要件は、業界で受け入れられているデータ・アクセス言語の標準に準拠することです。

Structured Query Language(SQL)

SQLは、Oracle DatabaseなどのRDBMSとのインタフェースを提供する集合ベースの宣言型言語です。処理の実行方法を記述するC言語のような手続き型言語とは対照的に、SQLは非手続き型であり、何を実行するかを記述します。ユーザーは、求める結果(たとえば、現在の従業員の名前)を指定し、その結果をどのようにして導出するかは指定しません。SQLはリレーショナル・データベース用のANSI標準言語です。

Oracle Database内のデータの操作はすべて、SQL文を使用して実行されます。たとえば、SQLを使用して表を作成し、表内のデータを問い合せ、変更します。SQL文は非常に簡単な文ですが、強力なコンピュータ・プログラム、または命令と考えることができます。SQL文は、次のようなSQLテキストの文字列です。

SELECT first_name, last_name FROM employees;

SQL文を使用して次のタスクを実行できます。

- データの問合せ

- 表内の行の挿入、更新および削除

- オブジェクトの作成、置換、変更および削除

- データベースおよびそのオブジェクトへのアクセスの制御

- データベースの整合性と一貫性の保証

SQLでは、前述のタスクを1つの一貫した言語に統合します。Oracle SQLは、ANSI標準の1つの実装です。Oracle SQLでは、標準SQLを拡張した数多くの機能がサポートされています。

関連項目:
第7章「SQL」

PL/SQLとJava

PL/SQLは、Oracle SQLに対する手続きを拡張します。PL/SQLはOracle Databaseに統合されており、Oracle DatabaseのすべてのSQL文、関数、およびデータ型を使用できます。PL/SQLを使用すると、SQLプログラムのフローの制御、変数の使用、およびエラー処理プロシージャの作成を行うことができます。

PL/SQLの主な利点は、アプリケーション・ロジックをデータベースそのものに格納できることです。PL/SQLプロシージャまたはファンクションは、一連のSQL文と他のPL/SQL構文で構成され、グループとしてまとめてデータベースに格納されるスキーマ・オブジェクトであり、特定の問題を解決したり、一連の関連タスクを実行するために1つの単位として実行されます。サーバー側プログラミングの主な利点は、組込み機能を任意の場所にデプロイできることです。

Oracle Databaseは、Javaで作成されたプログラム単位も格納できます。Javaストアド・プロシージャは、SQLにパブリッシュされ、一般的な用途向けにデータベースに格納されるJavaメソッドです。既存のPL/SQLプログラムをJavaから呼び出したり、JavaプログラムをPL/SQLから起動できます。

関連項目:
第8章「サーバー側プログラミング: PL/SQLとJava」および「クライアント側のデータベース・プログラミング」

トランザクションの管理

Oracle Databaseはマルチユーザー・データベースとして設計されています。データベースは、複数のユーザーが互いのデータを破損することなく同時に作業できることを保証する必要があります。

トランザクション

RDBMSは、SQL文をグループ化して、すべての文がコミットされた(つまりデータベースに適用された)状態にするか、すべての文がロールバックされた(つまり取り消された)状態にできる必要があります。トランザクションは、1つ以上のSQL文を含むアトミックな論理作業単位です。

トランザクションが必要な例として、普通預金口座から当座預金口座への振替があります。振替は独立した次の操作で構成されます。

1. 普通預金口座の減額

2. 当座預金口座の増額

3. トランザクション・ジャーナルへのトランザクションの記録

Oracle Databaseは、3つの操作すべてが1つの単位として成功したこと、または失敗したことを保証します。たとえば、ハードウェア障害によってトランザクション内の文の1つを実行できなかった場合は、その他の文をロールバックする必要があります。

トランザクションは、Oracle Databaseとファイルシステムとの明らかな違いを示す機能の1つです。複数のファイルを更新する不可分な操作を実行する場合、その途中でシステム障害が発生すると、ファイル間の整合性が失われます。対照的に、トランザクションは、Oracle Databaseを矛盾のない1つの状態から矛盾のない別の状態に移行します。トランザクションの基本的な原則は、100かゼロかであり、不可分の操作はその全体が成功するかその全体が失敗します。

関連項目:
第10章「トランザクション」

データ同時実行性

マルチユーザーRDBMSの要件の1つに、同時実行性(同じデータに複数のユーザーが同時にアクセスすること)の制御があります。同時実行性が制御されていない場合、ユーザーがデータを不適切に変更し、データ整合性が損われることがあります。たとえば、あるユーザーが行を更新する一方で、別のユーザーがその行を同時に更新することがあります。

複数のユーザーが同じデータにアクセスした場合、同時実行性を管理する1つの方法は、ユーザーを待機させることです。ただし、DBMSの目標は待機時間をゼロまたはごくわずかまで減らすことです。データを変更するすべてのSQL文は、できるだけ干渉されない状態で処理する必要があります。破壊的な相互作用とは、不正確なデータの更新または基礎となるデータ構造の不正な変更を引き起こす相互作用であり、これを回避する必要があります。

Oracle Databaseは、ロックを使用してデータへの同時アクセスを制御します。ロックは、共有リソースにアクセスする複数のトランザクション間で、破壊的な相互作用が起きないようにするメカニズムです。ロックは、データ整合性を保証する場合に役立つ一方、データへの最大の同時アクセスを可能にします。

関連項目:
「Oracle Databaseのロック・メカニズムの概要」

データ整合性

Oracle Databaseでは、各ユーザーに対して、ユーザー自身のトランザクションによる変更および他のユーザーのトランザクションのコミットによる変更を反映した、整合性のあるデータのビューが表示される必要があります。たとえば、データベースは、あるトランザクションが別の同時トランザクションによるコミットされていない変更に遭遇した場合に発生する内容を保証しない読取りを禁止する必要があります。

Oracle Databaseでは、文レベルの読取り一貫性を常に適用することにより、1つの問合せによって戻されたデータがコミット済であり、ある特定の時点で一貫していることを保証しています。トランザクション分離レベルに応じて、この時点は文またはトランザクションが開始されたときになります。この時点は、フラッシュバック問合せ機能で明示的に指定できます。

データベースは、トランザクションのすべての問合せに対して、トランザクション・レベルの読取り一貫性と呼ばれる読取り一貫性を実現することもできます。この場合、トランザクション内の各文には同じ時点(トランザクション開始時)のデータが表示されます。

関連項目:

- 第9章「データの同時実行性と整合性」

- フラッシュバック問合せの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

Oracle Databaseアーキテクチャ

データベース・サーバーは、情報管理の鍵となります。一般的にサーバーでは、多数のユーザーが同時に同じデータへアクセスできるように、マルチユーザー環境において大量のデータが確実に管理されます。権限のないアクセスに対して保護機能を備えながら、障害のリカバリについても効率のよい解決方法を提供します。

データベースおよびインスタンス

Oracleデータベース・サーバーは、1つのデータベースと1つ以上のデータベース・インスタンス(通常は単にインスタンスと呼ばれる)で構成されます。インスタンスとデータベースは非常に密接に関連しているため、Oracleデータベースという用語が、インスタンスとデータベースの両方を示す場合があります。これらの用語の厳密な意味は次のとおりです。

- データベース
データベースは、ディスク上に配置された、データを格納する一連のファイルです。これらのファイルはデータベース・インスタンスとは別に存在できます。

- データベース・インスタンス
インスタンスは、データベース・ファイルを管理する一連のメモリー構造です。インスタンスは、システム・グローバル領域(SGA)と呼ばれる共有メモリー領域と、一連のバックグラウンド・プロセスで構成されます。インスタンスはデータベース・ファイルとは別に存在できます。

図1-1に、データベースとそのインスタンスを示します。インスタンスに対するそれぞれのユーザー接続に対して、クライアント・プロセスによって、アプリケーションが実行されます。各クライアント・プロセスは、独自のサーバー・プロセスに関連付けられています。サーバー・プールには、プログラム・グローバル領域(PGA)と呼ばれる独自のプライベート・セッション・メモリーがあります。

図1-1 Oracleインスタンスおよびデータベース

データベースは、物理的な観点と論理的な観点の両方から検討できます。物理データとは、オペレーティング・システム・レベルで表示可能なデータです。たとえば、Linuxのlsやpsなどのオペレーティング・システム・ユーティリティは、データベース・ファイルおよびプロセスをリスト表示できます。表などの論理データは、データベースに対してのみ意味を持ちます。Oracle Database内の表はSQL文でリスト表示できますが、オペレーティング・システム・ユーティリティでは表示できません。

データベースには物理構造と論理構造があります。物理構造と論理構造は分離されているので、論理記憶構造へのアクセスに影響を与えずに、データの物理記憶域を管理できます。たとえば、物理データベース・ファイルの名前を変更しても、このファイルにデータが格納されている表の名前は変更されません。

関連項目:
第13章「Oracleデータベース・インスタンス」

データベース記憶域構造

リレーショナル・データベースに不可欠なタスクはデータの格納です。この項では、Oracle Databaseで使用される物理および論理記憶域構造について簡単に説明します。

物理記憶域構造

物理データベース構造とは、データを格納するファイルです。SQLコマンドCREATE DATABASEを実行すると、次のファイルが作成されます。

- データファイル
すべてのOracleデータベースには、すべてのデータベース・データを含む1つ以上の物理データファイルがあります。表や索引などの論理データベース構造のデータは、データファイルに物理的に格納されます。

- 制御ファイル
すべてのOracleデータベースには、制御ファイルがあります。制御ファイルには、データベース名やデータベース・ファイルの名前と位置など、データベースの物理構造を指定したメタデータが含まれています。

- オンラインREDOログ・ファイル
すべてのOracle Databaseには、2つ以上のオンラインREDOログ・ファイルのセットからなるオンラインREDOログがあります。オンラインREDOログは、データに加えられた変更をすべて記録するREDOエントリ(REDOレコードとも呼ばれる)で構成されています。

Oracleデータベース・サーバーが機能するために重要なその他多くのファイルがあります。これらのファイルには、パラメータ・ファイルや診断ファイルがあります。バックアップ・ファイルとアーカイブREDOログ・ファイルは、バックアップおよびリカバリに重要なオフライン・ファイルです。

関連項目:
第11章「物理記憶域構造」

論理記憶域構造

この項では、論理記憶域構造について説明します。次の論理記憶域構造によって、Oracle Databaseのディスク領域の使用をきめ細かく制御できます。

- データ・ブロック
最少レベルとして、Oracleデータベースのデータはデータ・ブロックに格納されます。1つのデータ・ブロックは、ディスク上の特定のバイト数に対応します。

- エクステント
エクステントは、1回の割当てで取得される特定数の論理的に連続したデータ・ブロックで、特定タイプの情報の格納に使用されます。

- セグメント
セグメントは、ユーザー・オブジェクト(表や索引)、UNDOデータ、または一時データに割り当てられるエクステントの集合です。

- 表領域
データベースは、表領域と呼ばれる論理記憶域単位に分割されます。表領域はセグメントの論理コンテナです。各表領域には1つ以上のデータファイルが含まれます。

関連項目:
第12章「論理記憶域構造」

データベース・インスタンス構造

Oracleデータベースは、メモリー構造とプロセスを使用してデータベースの管理やアクセスを行います。すべてのメモリー構造は、RDBMSを構成するコンピュータのメイン・メモリー内に存在します。

アプリケーションがOracleデータベースに接続すると、データベース・インスタンスに接続されます。インスタンスは、SGAのみでなくその他のメモリー領域も割り当て、バックグラウンド・プロセスの他のプロセスも起動して、アプリケーションに対応します。

Oracle Databaseプロセス

プロセスは一連の処理を実行できるオペレーティング・システムのメカニズムです。オペレーティング・システムによっては、「ジョブ」、「タスク」または「スレッド」という用語を使用します。この説明の目的では、スレッドはプロセスと同等です。Oracleデータベース・インスタンスには次のタイプのプロセスがあります。

- クライアント・プロセス
これらのプロセスは、アプリケーション・プログラムまたはOracleツールのソフトウェア・コードを実行するために作成およびメンテナンスされます。ほとんどの環境ではクライアント・プロセス用に独立したコンピュータが使用されます。

- バックグラウンド・プロセス
これらのプロセスは、各クライアント・プロセスごとに実行されている複数のOracle Databaseプログラムが処理する機能を1つにまとめます。また、I/Oを非同期的に実行し、他のOracle Databaseプロセスを監視することにより、並列性を強化してパフォーマンスおよび信頼性を向上させます。

- サーバー・プロセス
これらのプロセスは、クライアント・プロセスと通信し、Oracle Databaseと対話してリクエストに対応します。

Oracleプロセスには、サーバー・プロセスとバックグラウンド・プロセスがあります。ほとんどの環境では、Oracleプロセスとクライアント・プロセスは別々のコンピュータ上で実行されます。

関連項目:
第15章「プロセス・アーキテクチャ」

インスタンスのメモリー構造

Oracle Databaseでは、プログラム・コード用のメモリー、ユーザー間で共有されるデータ、接続している各ユーザーのプライベート・データ領域などのために、メモリー構造が作成および使用されます。次のメモリー構造がインスタンスに関連付けられています。

- システム・グローバル領域(SGA)
SGAは、共有メモリー構造のグループであり、1つのデータベース・インスタンスに関するデータと制御情報が含まれています。SGAコンポーネントの例として、キャッシュ・データ・ブロックや共有SQL領域があります。

- プログラム・グローバル領域(PGA)
PGAは、サーバー・プロセスまたはバックグラウンド・プロセス用のデータや制御情報を含むメモリー領域です。PGAにアクセスできるのはプロセスのみです。それぞれのサーバー・プロセスおよびバックグラウンド・プロセスには専用のPGAがあります。

関連項目:
第14章「メモリー・アーキテクチャ」

アプリケーションおよびネットワークのアーキテクチャ

特定のコンピュータ・システムまたはネットワークを最大限に活用できるように、Oracle Databaseではデータベース・サーバーとクライアント・プログラムの間で処理を分割できます。RDBMSを実行しているコンピュータはデータベース・サーバーの処理を実行し、アプリケーションを実行しているコンピュータはデータの解釈と表示を行います。

アプリケーション・アーキテクチャ

アプリケーション・アーキテクチャは、データベース・アプリケーションがOracle Databaseに接続するコンピューティング環境を示します。データベースの最も一般的なアーキテクチャは、クライアント/サーバーと複数層の2種類です。

クライアント/サーバー・アーキテクチャでは、クライアント・アプリケーションは、データベース・サーバー上で実行される操作に関するリクエストを開始します。サーバーは、Oracle Databaseソフトウェアを実行し、同時実行の共有データ・アクセスに必要な機能を処理します。サーバーは、クライアントから発行されたリクエストを受け取って処理します。

従来の複数層アーキテクチャでは、1つ以上のアプリケーション・サーバーが操作の各部分を実行します。アプリケーション・サーバーには、アプリケーション・ロジックの大部分が含まれ、クライアントのデータ・アクセスを可能とし、多少の問合せ処理を実行することにより、データベースの負荷を軽減します。アプリケーション・サーバーは、クライアントと複数のデータベース間のインタフェースとして機能し、セキュリティ・レベルを高める役割を果します。

サービス指向アーキテクチャ(SOA)は、アプリケーション機能がサービスにカプセル化されている複数層アーキテクチャです。通常、SOAサービスはWebサービスとして実装されます。WebサービスはHTTP経由でアクセス可能なサービスであり、Webサービス記述言語(WSDL)やSOAPなどのXMLベースの規格に基づいています。

Oracle Databaseは、従来の複数層またはSOA環境においてWebサービス・プロバイダとして機能できます。

関連項目:

- 「複数層アーキテクチャの概要」

- データベースを使用したWebサービスの使用方法の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

ネットワーク・アーキテクチャ

Oracle Net Servicesは、データベースとネットワークの通信プロトコルとの間のインタフェースであり、分散処理と分散データベースの実現を支援します。通信プロトコルにより、ネットワーク上でのデータの送受信方法が定義されます。Oracle Net Servicesは、TCP/IP、HTTP、FTPおよびWebDAVなど、主要なネットワーク・プロトコルによる通信をすべてサポートしています。

Oracle NetはOracle Net Servicesのコンポーネントであり、クライアント・アプリケーションからデータベース・サーバーへのネットワーク・セッションを確立して維持します。ネットワーク・セッションの確立後は、Oracle Netはクライアント・アプリケーションとデータベース・サーバーのためのデータ伝達手段として機能し、これらの間でメッセージを交換します。Oracle Netは、ネットワーク内の各コンピュータに配置されているのでこれらのジョブを実行できます。

Net Servicesの重要なコンポーネントにOracle Net Listener(リスナーと呼ばれる)があり、独立したプロセスとしてデータベース・サーバーまたはネットワークの別の場所で実行されます。クライアント・アプリケーションは、リスナーに接続要求を送信し、リスナーはデータベース・サーバーに対するこれらの要求のトラフィックを管理します。接続が確立されると、クライアントとデータベースは直接通信します。

クライアント要求を処理するようにOracle Databaseを構成する最も一般的な方法は、次のとおりです。

- 専用サーバー・アーキテクチャ
各クライアント・プロセスは、専用サーバー・プロセスに接続します。サーバー・プロセスは、クライアントのセッションの継続中、その他のどのクライアントとも共有されません。それぞれの新規セッションに専用サーバー・プロセスが割り当てられます。

- 共有サーバー・アーキテクチャ
データベースは複数のセッションに対して共有プロセスのプールを使用します。クライアント・プロセスはディスパッチャと通信し、ディスパッチャは、クライアントごとに専用のサーバー・プロセスがなくても多数のクライアントが同じデータベース・インスタンスに接続できるようにするプロセスです。

関連項目:

- 「Oracleネットワーク・アーキテクチャの概要」

- Oracle Netアーキテクチャの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- データベースでのWebDAVの使用方法の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

Oracle Databaseドキュメントのロードマップ

この項では、このマニュアルの使用方法およびOracle Databaseマニュアル・セット全体での位置付けを説明します。

新規ユーザーの場合、Oracle Databaseドキュメント・ライブラリは難しく感じられることがあります。175冊を超えるマニュアルが用意されているだけでなく、多くのマニュアルが数百ページの長さに渡ります。ただし、ユーザーが必要とする情報をできるだけ効率よく見つけられるように、マニュアルは特定のアクセス・パスを使用して設計されています。

マニュアル・セットは、初級、中級、および上級の3つの層またはグループに分かれています。初級グループ(『Oracle Database 2日でデータベース管理者』、『Oracle Database 2日で開発者ガイド』、またはこのマニュアル)のマニュアルから始め、中級グループのマニュアル(2日でシリーズ)に進み、最後に上級マニュアル(マニュアル・セットの残りのマニュアル)に進みます。

初級グループ

技術者でOracle Databaseの新規ユーザーである場合は、初級グループのマニュアルを1冊以上、最初から最後まで読むことから始めてください。このグループの各マニュアルは、2日で読めるように設計されています。初級グループには、このマニュアルに加えて次のマニュアルがあります。

- 『Oracle Database 2日でデータベース管理者』
このマニュアルは、日常のデータベース管理タスクの実行方法を説明したタスクベースのDBA用クイック・スタートです。基本的なトラブルシューティングやパフォーマンス監視アクティビティの実行方法など、データベースの稼働を維持するために必要な、一般的なすべての管理タスクを実行する方法について説明しています。

- 『Oracle Database 2日で開発者ガイド』
このマニュアルは、SQLおよびPL/SQLでOracle Databaseの基本機能を使用する方法について説明した、タスクベースのデータベース開発者用クイック・スタート・ガイドです。

初級グループのマニュアルは密接に関連しており、そのために相互参照が多くなっています。たとえば、『Oracle Database概要』は、概念に基づいてタスクを実行する方法を学ぶことができるように、2日でシリーズのマニュアルを頻繁に参照しています。2日でシリーズのマニュアルでは、タスクの概念的な説明について、『Oracle Database概要』を頻繁に参照しています。

中級グループ

初級グループの次のステップは、中級グループです。このグループのマニュアルは、初級グループの「2日で」シリーズのマニュアルに含まれる情報を前提とし、それと同じ「2日で」という言葉が先頭に付いています。これらのマニュアルでは、初級マニュアルよりも詳細にトピックを説明し、また、特に重要なトピックについて説明しています。表1-1に示すように、「2日で」シリーズのマニュアルは、DBA向けのマニュアルと開発者向けのマニュアルに分かれています。

表1-1 中級グループ: 2日でシリーズのガイド

データベース管理者

データベース開発者

『Oracle Database 2日でパフォーマンス・チューニング・ガイド』

『Oracle Database Application Express 2日で開発者ガイド』

『Oracle Database 2日でReal Application Clustersガイド』

『Oracle Database 2日でJava開発者ガイド』

『Oracle Database 2日でデータ・ウェアハウス・ガイド』

『Oracle Database 2日で.NET開発者ガイド』

『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』

『Oracle Database 2日でPHP開発者ガイド』

『Oracle Database 2日でセキュリティ・ガイド』

上級グループ

中級グループの次のステップは、上級グループです。これらのマニュアルは、特定のトピックについて、2日でシリーズのマニュアルよりも詳細な情報を必要とする専門家ユーザーを対象としています。上級グループの必須のリファレンス・マニュアルは次のとおりです。

- 『Oracle Database SQL言語リファレンス』
このマニュアルは、Oracle SQLに関する最も確実な情報ソースです。

- 『Oracle Databaseリファレンス』
このマニュアルは、初期化パラメータ、データ・ディクショナリ・ビュー、および動的パフォーマンス・ビューに関する最も確実な情報ソースです。

上級ガイドは数が多いため、この項にすべてを示すことはできません。表1-2に、熟練したDBAおよび開発者の多くが使用するガイドを示します。

表1-2 上級グループ

データベース管理者

データベース開発者

『Oracle Database管理者ガイド』

『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』

『Oracle Databaseパフォーマンス・チューニング・ガイド』

『Oracle Database PL/SQL言語リファレンス』

『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』

『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

特定のユーザーが必要とする他の上級ガイドは、そのユーザーの担当業務の分野によって異なります。たとえば、セキュリティ担当者は通常、『Oracle Databaseセキュリティ・ガイド』を参照します。

第I部

Oracleリレーショナル・データ構造

この部では、データ整合性の規則を含むOracleデータベースの基本的なデータ構造、およびメタデータを格納する構造について説明します。

この部の構成は、次のとおりです。

- 第2章「表と表クラスタ」

- 第3章「索引と索引構成表」

- 第4章「パーティション、ビューおよびその他のスキーマ・オブジェクト」

- 第5章「データ整合性」

- 第6章「データ・ディクショナリと動的パフォーマンス・ビュー」

2 表と表クラスタ

この章では、スキーマ・オブジェクトの概要、および最も一般的なスキーマ・オブジェクトである表について説明します。

この章の内容は、次のとおりです。

- スキーマ・オブジェクトの概要

- 表の概要

- 表クラスタの概要

スキーマ・オブジェクトの概要

データベース・スキーマは、スキーマ・オブジェクトと呼ばれるデータ構造の論理コンテナです。スキーマ・オブジェクトの例には、表や索引があります。スキーマ・オブジェクトは、SQLで作成および操作します。

データベース・ユーザーは、パスワードと様々なデータベース権限を持ちます。各ユーザーは、ユーザーと同じ名前が付いた単一のスキーマを所有します。スキーマには、スキーマを所有するユーザーのデータが含まれています。たとえば、hrユーザーはhrスキーマを所有し、このスキーマにemployees表などのスキーマ・オブジェクトが含まれます。通常、本番データベースでは、スキーマ所有者は人ではなく、データベース・アプリケーションを表します。

スキーマ内の特定のタイプの各スキーマ・オブジェクトには、一意の名前が付きます。たとえば、hr.employeesはhrスキーマ内のemployees表を指します。図2-1に、hrという名前のスキーマ所有者とhrスキーマ内のスキーマ・オブジェクトを示します。

図2-1 hrスキーマ

関連項目:
ユーザーと権限の詳細は、「データベース・セキュリティの概要」を参照してください。

スキーマ・オブジェクトのタイプ

リレーショナル・データベースで最も重要なスキーマ・オブジェクトは、表です。表では、データは行に格納されます。

Oracle SQLでは、他にも次のような多数のタイプのスキーマ・オブジェクトを作成および操作できます。

- 索引
索引とは、表または表クラスタの索引付けされた各行のエントリを含むスキーマ・オブジェクトのことで、索引により行に直接かつ高速にアクセスできます。Oracle Databaseは、いくつかのタイプの索引をサポートしています。索引構成表は、データが索引の構造で格納される表です。第3章「索引と索引構成表」を参照してください。

- パーティション
パーティションとは、大規模な表や索引の断片のことです。各パーティションには独自の名前があり、独自の記憶特性を持つ場合があります。「パーティションの概要」を参照してください。

- ビュー
ビューとは、1つ以上の表または他のビューに含まれているデータの表現がカスタマイズされたものです。ビューは、ストアド・クエリーとみなすことができます。実際にはビューにデータは含まれていません。「ビューの概要」を参照してください。

- 順序
順序とは、複数のユーザーが整数を生成して共有できるユーザー作成オブジェクトのことです。通常、順序は主キー値の生成に使用されます。「順序の概要」を参照してください。

- ディメンション
ディメンションは、列セットのペア間の親子関係を定義するもので、この列セットに含まれるすべての列は、同じ表の列である必要があります。ディメンションは、主に顧客、製品および時刻などのデータを分類するために使用されます。「ディメンションの概要」を参照してください。

- シノニム
シノニムとは、他のスキーマ・オブジェクトの別名のことです。シノニムは単なる別名であるため、データ・ディクショナリ内の定義以外に記憶域は必要ありません。「シノニムの概要」を参照してください。

- PL/SQLサブプログラムとPL/SQLパッケージ
PL/SQLは、SQLに対するOracleの手続き型の拡張機能です。PL/SQLサブプログラムとは、一連のパラメータを使用して起動できる、名前付きPL/SQLブロックのことです。PL/SQLパッケージとは、論理的に関連するPL/SQLタイプ、変数およびサブプログラムをグループ化するものです。「PL/SQLサブプログラム」および「PL/SQLパッケージ」を参照してください。

データベースには他のタイプのオブジェクトも保存されており、SQL文で作成および操作できますが、スキーマには含まれていません。これらのオブジェクトには、データベース・ユーザー、ロール、コンテキストおよびディクショナリ・オブジェクトなどがあります。

関連項目:

- スキーマ・オブジェクトの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

- スキーマ・オブジェクトとデータベース・オブジェクトの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

スキーマ・オブジェクトの格納

一部のスキーマ・オブジェクトでは、セグメントと呼ばれる論理記憶域構造にデータを格納します。たとえば、パーティション化されていないヒープ構成表や索引では、セグメントを作成します。ビューや順序などの他のスキーマ・オブジェクトは、メタデータのみで構成されます。この項では、セグメントを持つスキーマ・オブジェクトについてのみ説明します。

Oracle Databaseでは、スキーマ・オブジェクトは表領域内に論理的に格納されます。スキーマと表領域には関連はなく、表領域は異なるスキーマのオブジェクトを含むことができ、スキーマの各オブジェクトは異なる表領域に含めることができます。各オブジェクトのデータは、物理的には、1つ以上のデータファイルに格納されます。

図2-2に、表と索引のセグメント、表領域およびデータファイルの可能な構成を示します。1つの表のデータ・セグメントが2つのデータファイル(両方とも同じ表領域の一部)にまたがっています。セグメントが複数の表領域にまたがることはできません。

図2-2 セグメント、表領域およびデータファイル

関連項目:

- 表領域とセグメントの詳細は、第12章「論理記憶域構造」を参照してください。

- スキーマ・オブジェクトの記憶域を管理する方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

スキーマ・オブジェクトの依存性

スキーマ・オブジェクトには、他のオブジェクトを参照し、スキーマ・オブジェクトの依存性を作成するものがあります。たとえば、ビューに表または他のビューを参照する問合せが含まれている場合や、PL/SQLサブプログラムが他のサブプログラムを起動する場合があります。オブジェクトAの定義がオブジェクトBを参照している場合、AはBに関する依存オブジェクト、BはAに関する参照オブジェクトです。

Oracle Databaseには、依存オブジェクトがその参照オブジェクトに関して常に最新であることを保証する自動メカニズムがあります。依存オブジェクトが作成されると、データベースは依存オブジェクトとその参照オブジェクトとの間の依存性を追跡します。参照オブジェクトに変更があり、依存オブジェクトがその影響を受ける可能性がある場合は、依存オブジェクトに無効のマークが付きます。たとえば、ユーザーが表を削除した場合、その表に基づくビューは使用できなくなります。

無効な依存オブジェクトを使用できるようにするには、その依存オブジェクトが参照オブジェクトの新しい定義で再コンパイルされる必要があります。再コンパイルは、無効な依存オブジェクトが参照されたときに自動的に実行されます。

スキーマ・オブジェクトでどのように依存性を作成できるかを示す例として、次のサンプル・スクリプトでは、表test_tableを作成し、この表を問い合せるプロシージャを作成します。

CREATE TABLE test_table ( col1 INTEGER, col2 INTEGER );

CREATE OR REPLACE PROCEDURE test_proc
AS
BEGIN
FOR x IN ( SELECT col1, col2 FROM test_table )
LOOP
-- process data
NULL;
END LOOP;
END;
/

次のようにプロシージャtest_procのステータスを問い合せると、プロシージャは有効であることが示されます。

SQL> SELECT OBJECT_NAME, STATUS FROM USER_OBJECTS WHERE OBJECT_NAME = 'TEST_PROC';

OBJECT_NAME STATUS
----------- -------
TEST_PROC   VALID

test_tableにcol3列を追加しても、プロシージャにはこの列に対する依存性がないため、その後もプロシージャは有効です。

SQL> ALTER TABLE test_table ADD col3 NUMBER;

Table altered.

SQL> SELECT OBJECT_NAME, STATUS FROM USER_OBJECTS WHERE OBJECT_NAME = 'TEST_PROC';

OBJECT_NAME STATUS
----------- -------
TEST_PROC   VALID

ただし、test_procプロシージャが依存しているcol1列のデータ型を変更すると、プロシージャは無効化されます。

SQL> ALTER TABLE test_table MODIFY col1 VARCHAR2(20);

Table altered.

SQL> SELECT OBJECT_NAME, STATUS FROM USER_OBJECTS WHERE OBJECT_NAME = 'TEST_PROC';

OBJECT_NAME STATUS
----------- -------
TEST_PROC   INVALID

次の例に示すように、プロシージャを実行または再コンパイルすると、プロシージャは再び有効になります。

SQL> EXECUTE test_proc

PL/SQL procedure successfully completed.

SQL> SELECT OBJECT_NAME, STATUS FROM USER_OBJECTS WHERE OBJECT_NAME = 'TEST_PROC';

OBJECT_NAME STATUS
----------- -------
TEST_PROC   VALID

関連項目:
スキーマ・オブジェクトの依存性を管理する方法の詳細は、『Oracle Database管理者ガイド』および『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

SYSスキーマとSYSTEMスキーマ

すべてのOracleデータベースには、デフォルトの管理アカウントが自動的に含まれています。管理アカウントは、高度な権限が付与され、データベースの起動と停止、メモリーと記憶域の管理、データベース・ユーザーの作成と管理などのタスクの実行を認可されたDBA専用のアカウントです。

管理アカウントSYSは、データベースが作成されたときに自動的に作成されます。このアカウントでは、すべてのデータベース管理機能を実行できます。SYSスキーマには、データ・ディクショナリの実表とビューが格納されています。これらの実表とビューは、Oracle Databaseの操作にとって重要です。SYSスキーマ内の表はデータベースによってのみ操作され、ユーザーからは決して変更されません。

SYSTEMアカウントも、データベースが作成されたときに自動的に作成されます。SYSTEMスキーマには、管理情報を表示する追加の表とビュー、およびOracle Databaseの様々なオプションとツールで使用される内部の表とビューが格納されます。SYSTEMスキーマは、管理ユーザー以外のユーザーが必要とする表の格納には決して使用しないでください。

関連項目:

- 「ユーザー・アカウント」および「管理者権限での接続」

- SYS、SYSTEMおよびその他の管理アカウントの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

サンプル・スキーマ

Oracleデータベースには、サンプル・スキーマが含まれることがあり、サンプル・スキーマとは、Oracleドキュメントや教材で共通のデータベース・タスクを説明できるように相互にリンクされた一連のスキーマのことです。hrスキーマは、従業員、部門、勤務地、職歴などの情報を含むサンプル・スキーマです。

図2-3は、hrスキーマに含まれる表のエンティティ関係ダイアグラムです。このマニュアルのほとんどの例では、このスキーマのオブジェクトを使用します。

図2-3 hrスキーマ

関連項目:
『Oracle Databaseサンプル・スキーマ』

表の概要

表は、Oracle Databaseにおけるデータ編成の基本単位です。表には、記録が必要な情報に関してなんらかの意味を持つエンティティが記述されます。たとえば、従業員がエンティティになることがあります。

Oracle Databaseの表は、次の基本カテゴリに分類されます。

- リレーショナル表
リレーショナル表は、単純な列で構成された最も一般的な表タイプです。例2-1に、リレーショナル表のCREATE TABLE文を示します。

- オブジェクト表
列は、オブジェクト型のトップレベルの属性に相当します。「オブジェクト表」を参照してください。

次の構成特性を持つリレーショナル表を作成できます。

- ヒープ構成表では、行は特定の順序で格納されません。デフォルトでは、CREATE TABLE文でヒープ構成表が作成されます。

- 索引構成表では、主キー値に従って行が整列されます。アプリケーションによっては、索引構成表によりパフォーマンスが強化され、ディスク領域をより効率的に使用できるものがあります。「索引構成表の概要」を参照してください。

- 外部表は読取り専用の表であり、これらのメタデータはデータベースに格納されますが、データはデータベースの外部に格納されます。「外部表」を参照してください。

表は永続または一時のいずれかです。永続表の定義とデータは、セッションをまたいで存続します。一時表の定義も永続表の定義と同様に存続しますが、データはトランザクションまたはセッションの期間中にのみ存在します。一時表は、複数の操作の実行によって結果を作成する場合があるために、結果セットを一時的に保持する必要があるアプリケーションで役立ちます。

この項には次のトピックが含まれます:

- 列と行

- 例: CREATE TABLE文とALTER TABLE文

- Oracleデータ型

- 整合性制約

- オブジェクト表

- 一時表

- 外部表

- 表の記憶域

- 表の圧縮

関連項目:
表の管理方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

列と行

表の定義には、表名と列の集合が含まれています。列は、表で示されるエンティティの属性を識別します。たとえば、employees表の列employee_idは、従業員エンティティの従業員ID属性を参照します。

通常は、表を作成するとき、各列に列名、データ型および幅を指定します。たとえば、employee_idのデータ型がNUMBER(6)である場合、この列に6桁以内の幅の数値データのみが格納されることを示します。幅は、DATEデータ型の場合のようにデータ型によって事前に決定されている場合があります。

表には、通常の列とは異なり、ディスク領域を使用しない仮想列を含めることができます。データベースによりユーザーが指定する一連の式または関数が計算され、必要に応じて仮想列から値が導出されます。たとえば、仮想列incomeが、salary列とcommission_pct列の関数になることがあります。

表の作成後に、SQL文を使用して行の挿入、問合せ、削除および更新ができます。行は、表内のレコードに対応する列情報の集まりです。たとえば、employees表の行には、特定の従業員の属性が記述されます。

関連項目:
仮想列の管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

例: CREATE TABLE文とALTER TABLE文

表を作成するOracle SQLコマンドは、CREATE TABLEです。例2-1に、hrサンプル・スキーマに含まれるemployees表のCREATE TABLE文を示します。この文では、employee_idおよびfirst_nameなどの列を指定し、各列にNUMBERまたはDATEなどのデータ型を指定します。

例2-1 CREATE TABLE employees

CREATE TABLE employees
( employee_id    NUMBER(6)
, first_name     VARCHAR2(20)
, last_name      VARCHAR2(25)
CONSTRAINT     emp_last_name_nn  NOT NULL
, email          VARCHAR2(25)
CONSTRAINT     emp_email_nn  NOT NULL
, phone_number   VARCHAR2(20)
, hire_date      DATE
CONSTRAINT     emp_hire_date_nn  NOT NULL
, job_id         VARCHAR2(10)
CONSTRAINT     emp_job_nn  NOT NULL
, salary         NUMBER(8,2)
, commission_pct NUMBER(2,2)
, manager_id     NUMBER(6)
, department_id  NUMBER(4)
, CONSTRAINT     emp_salary_min
CHECK (salary > 0)
, CONSTRAINT     emp_email_uk
UNIQUE (email)
) ;

例2-2に、employees表に整合性制約を追加するALTER TABLE文を示します。整合性制約はビジネス・ルールを適用し、無効な情報が表に入力されるのを防止します。

例2-2 ALTER TABLE employees

ALTER TABLE employees
ADD ( CONSTRAINT     emp_emp_id_pk
PRIMARY KEY (employee_id)
, CONSTRAINT     emp_dept_fk
FOREIGN KEY (department_id)
REFERENCES departments
, CONSTRAINT     emp_job_fk
FOREIGN KEY (job_id)
REFERENCES jobs (job_id)
, CONSTRAINT     emp_manager_fk
FOREIGN KEY (manager_id)
REFERENCES employees
) ;

例2-3に、hr.employees表の8つの行と6つの列を示します。

例2-3 employees表の行

EMPLOYEE_ID FIRST_NAME  LAST_NAME      SALARY COMMISSION_PCT DEPARTMENT_ID
----------- ----------- ------------- ------- -------------- -------------
100 Steven      King            24000                           90
101 Neena       Kochhar         17000                           90
102 Lex         De Haan         17000                           90
103 Alexander   Hunold           9000                           60
107 Diana       Lorentz          4200                           60
149 Eleni       Zlotkey         10500             .2            80
174 Ellen       Abel            11000             .3            80
178 Kimberely   Grant            7000            .15

例2-3の出力は、表、列および行に関する、次の重要な特徴のいくつかを示しています。

- 表の行には、1人の従業員の、名前、給与、部門などの属性が記述されます。たとえば、出力の最初の行には、Steven Kingという名前の従業員のレコードが表示されています。

- 列には、従業員の属性が記述されます。この例では、employee_id列が主キーであり、すべての従業員が一意の従業員IDで識別されることを意味します。2人の従業員が同じ従業員IDを持たないことが保証されます。

- 非キー列には、同じ値の行が含まれることがあります。この例では、従業員101と従業員102の給与の値が同じ17000です。

- 外部キー列は、同じ表または別の表の主キーや一意キーを参照します。この例では、department_idの90の値は、departments表のdepartment_id列に対応しています。

- フィールドは、行と列の交差部分です。フィールドには1つの値のみが含まれます。たとえば、従業員104の部門IDのフィールドには、値60が含まれています。

- フィールドには、値がないこともあります。この場合、フィールドにはNULL値が含まれることになります。従業員100のcommission_pct列の値はNULLですが、従業員149のこのフィールドの値は.2です。列にNULL値を入力できるのは、その列にNOT NULLまたは主キー整合性制約が定義されていない場合のみです。この場合、その列に値を持たない行は挿入できません。

関連項目:
CREATE TABLEの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

Oracleデータ型

列は、それぞれ特定の記憶域形式、制約および値の有効範囲に関連付けられたデータ型を持っています。値のデータ型により、固定された一連のプロパティが値に関連付けられます。これらのプロパティに従い、Oracle Databaseではあるデータ型の値を別のデータ型の値と異なる方法で扱います。たとえば、NUMBERデータ型の値は乗算できますが、RAWデータ型の値は乗算できません。

表の作成時には、その各列のデータ型を指定する必要があります。その後、列に挿入される各値は、その列のデータ型とみなされます。

Oracle Databaseには、いくつかの組込みデータ型が用意されています。最も一般的に使用されるデータ型は、次のカテゴリに分類されます。

- 文字データ型

- 数値データ型

- 日時データ型

- ROWIDデータ型

- 書式モデルとデータ型

組込みデータ型のその他の重要なカテゴリには、RAW、ラージ・オブジェクト(LOB)およびコレクションがあります。PL/SQLには、定数と変数のデータ型として、BOOLEAN、参照型、コンポジット型(レコード)およびユーザー定義型があります。

関連項目:

- 「LOBの概要」

- 組込みSQLデータ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- PL/SQLデータ型の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- 組込みデータ型の使用方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

文字データ型

文字データ型は、文字(英数字)データを文字列で格納します。最も一般的に使用される文字データ型がVARCHAR2で、文字データを最も効率よく格納できます。

バイト値は、文字コード体系(通常、キャラクタ・セットまたはコード・ページと呼ばれます)に対応します。データベースのキャラクタ・セットは、データベースの作成時に設定されます。キャラクタ・セットの例には、7ビットASCII、EBCDICおよびUnicode UTF-8があります。

文字データ型の長さセマンティクスは、バイト数または文字数で測定できます。バイト・セマンティクスは、文字列を一連のバイトとして取り扱うことを意味します。これは、文字データ型のデフォルトです。キャラクタ・セマンティクスは、文字列を一連の文字として取り扱うことを意味します。文字は技術的に、データベース・キャラクタ・セットのコード・ポイントです。

関連項目:

- 「キャラクタ・セット」

- 文字データ型の選択方法の詳細は、『Oracle Database 2日で開発者ガイド』および『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

VARCHAR2およびCHARデータ型

VARCHAR2データ型には、可変長の文字リテラルが格納されます。リテラルと定数値という用語は同義であり、固定のデータ値を指します。たとえば、'LILA'、'St. George Island'および'101'はすべて文字リテラルで、5001は数値リテラルです。文字リテラルは一重引用符で囲み、これにより、データベースでスキーマ・オブジェクト名と区別されます。

注意:
このマニュアルでは、テキスト・リテラル、文字リテラルおよび文字列という用語を同じ意味で使用します。

VARCHAR2の列を含む表の作成時には、文字列の最大長を指定します。例2-1では、last_name列にVARCHAR2(25)というデータ型が指定されており、これは、この列に最大25バイトの名前を格納できることを意味します。

それぞれの行で、列の値はOracle Databaseにより可変長のフィールドとして格納され、値が最大長を超えている場合は、データベースからエラーが戻されます。たとえば、シングルバイト・キャラクタ・セットで、ある行のlast_name列に10文字を入力すると、その行の列には25文字ではなく10文字(10バイト)のみが格納されます。VARCHAR2を使用することにより、領域の消費量を削減できます。

VARCHAR2とは異なり、CHARは、固定長の文字列を格納します。CHAR列を含む表の作成時には、列の文字列の長さを指定する必要があります。デフォルトは1バイトです。データベースは、空白を使用して指定された長さまで値を埋め込みます。

Oracle Databaseは、非空白埋め比較方法を使用してVARCHAR2値を比較し、空白埋め比較方法を使用してCHAR値を比較します。

関連項目:
空白埋め比較方法と非空白埋め比較方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

NCHARおよびNVARCHAR2データ型

NCHARとNVARCHAR2データ型は、Unicode文字データを格納します。Unicodeはユニバーサル・エンコードされたキャラクタ・セットであり、1つのキャラクタ・セットで任意の言語の情報を格納できます。NCHARは、各国語キャラクタ・セットに対応する固定長の文字列を格納し、NVARCHAR2は、可変長の文字列を格納します。

データベースの作成時に各国語キャラクタ・セットを指定します。NCHARデータ型とNVARCHAR2データ型のキャラクタ・セットは、AL16UTF16またはUTF8のいずれかにする必要があります。どちらのキャラクタ・セットでも、Unicodeエンコーディングが使用されます。

NCHARまたはNVARCHAR2の列で表を作成すると、最大サイズは、必ず文字長セマンティクスになります。文字長セマンティクスはNCHARまたはNVARCHAR2のデフォルトであり、その唯一の長さセマンティクスです。

関連項目:
Oracleのグローバリゼーション・サポート機能の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

数値データ型

Oracle Databaseの数値データ型には、固定小数点数、浮動小数点数、ゼロおよび無限大が格納されます。いくつかの数値データ型には操作結果の未定義を示す値も格納され、これは、非数値つまりNANと呼ばれます。

Oracle Databaseでは、数値データが可変長形式で格納されます。それぞれの値は科学表記法で格納され、指数を格納するために1バイトが使用されます。データベースでは、仮数(浮動小数点数の一部で、有効桁数を含む部分)を格納するために最大20バイトが使用されます。Oracle Databaseでは、先行ゼロと後続ゼロは格納されません。

NUMBERデータ型

NUMBERデータ型には、固定小数点数および浮動小数点数が格納されます。実質的には、どのような大きさの数値でも、データベースに格納可能です。Oracle Databaseが稼働するオペレーティング・システムであれば、相互にデータを移植することが可能です。数値データの格納が必要となるほとんどの場合で、NUMBERデータ型をお薦めします。

固定小数点数は、NUMBER(p,s)という形式で指定します。このpおよびsは、次の文字を示しています。

- 精度
精度は、全体の桁数を指定します。精度を指定しない場合、値は丸められずに、アプリケーションから提供されたとおりに列に格納されます。

- スケール
スケールは、小数点から最下位有効桁までの桁数を指定します。正のスケールは、小数点の右側から最下位有効桁まで(最下位有効桁を含む)の桁数を指定します。負のスケールは、小数点の左側から最下位有効桁まで(ただし、最下位有効桁を含まない)の桁数を指定します。NUMBER(6)のように、精度を指定してスケールを指定しない場合、スケールは0になります。

例2-1では、salary列はNUMBER(8,2)型であるため、精度は8でスケールは2です。したがって、100,000という給料は、データベースに100000.00という値で格納されます。

浮動小数点数

Oracle Databaseには、浮動小数点数専用にBINARY_FLOATおよびBINARY_DOUBLEという2つの数値データ型が用意されています。これらのデータ型は、NUMBERデータ型の基本機能をすべてサポートしています。ただし、NUMBERは10進精度を使用しますが、BINARY_FLOATおよびBINARY_DOUBLEは2進精度を使用します(2進精度により、算術計算が高速になり、通常は記憶域必要量が減少します)。

BINARY_FLOATとBINARY_DOUBLEは、近似値データ型です。どちらにも、10進値の正確な表現ではなく近似値表現が格納されます。たとえば、BINARY_DOUBLEまたはBINARY_FLOATでは、値0.1を正確に表現できません。この2つは、通常は科学関係の計算に使用されます。両者の動作は、JavaとXMLSchemaのデータ型FLOATおよびDOUBLEに似ています。

関連項目:
精度、スケールおよびその他の数値データ型の特性の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

日時データ型

日時データ型は、DATEとTIMESTAMPです。Oracle Databaseでは、タイムスタンプに対する包括的なタイムゾーン・サポートが提供されます。

DATEデータ型

DATEデータ型には、日付と時刻が格納されます。日時は、文字または数値のデータ型で表現できますが、DATEには、関連付けられた特別なプロパティがあります。例2-1のhire_date列には、DATEデータ型が指定されています。

データベースの内部では、日付が数字として格納されます。日付は、それぞれ世紀、年、月、日、時、分および秒に対応する7バイトの固定長フィールドに格納されます。

注意:
日付では算術演算が全面的にサポートされているため、数値の場合とまったく同様に日付を加算または減算できます。『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

データベースでは、指定された書式モデルに従って日付が表示されます。書式モデルは、日時の書式を文字列で記述する文字リテラルです。標準の日付書式はDD-MON-RRであり、日付が01-JAN-11の形式で表示されます。

RRは、YY(年の最後の2桁)と似ていますが、戻り値の世紀は、指定された2桁の年と現在の年の最後の2桁に応じて異なります。1999年の日付がデータベースに01-JAN-11と表示されるとします。日付書式にRRを使用する場合、11は2011を指しますが、日付書式にYYを使用する場合、11は1911を指します。デフォルト日付書式は、インスタンスとセッションのどちらのレベルでも変更できます。

Oracle Databaseでは、時刻はHH:MI:SSの24時間形式で格納されます。時刻部分に何も指定しない場合、デフォルトでは、日付フィールドの時刻部分は00:00:00 A.M.になります。時刻のみを入力した場合、日付部分のデフォルトは現在の月の1日になります。

関連項目:

- 世紀および日付の書式マスクの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- 日時書式コードの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

TIMESTAMPデータ型

TIMESTAMPデータ型は、DATEデータ型を拡張したものです。DATEデータ型に格納される情報に加え、小数秒が格納されます。TIMESTAMPデータ型は、イベントの順序を追跡する必要があるアプリケーションなどで、正確な時間を格納するために役立ちます。

DATETIMEデータ型のTIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEでは、タイム・ゾーンも認識されます。ユーザーがデータを選択すると、値はユーザー・セッションのタイム・ゾーンに調整されます。このデータ型は、複数の地理的地域にまたがって日付情報を収集および評価する場合に役立ちます。

関連項目:
タイムスタンプ列のデータの作成と入力を実行する構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ROWIDデータ型

データベースに格納されているすべての行にはアドレスがあります。Oracle Databaseでは、ROWIDデータ型にデータベース内の各行のアドレス(ROWID)が格納されます。ROWIDは、次のカテゴリに分類されます。

- 物理ROWIDは、ヒープ構成表、表クラスタ、および表パーティションや索引パーティションに行のアドレスを格納します。

- 論理ROWIDは、索引構成表に行のアドレスを格納します。

- 外部ROWIDは、ゲートウェイを介してアクセスされるDB2表などの外部表の識別子です。これは、Oracle Databaseの標準ROWIDではありません。

ユニバーサルROWIDまたはUROWIDと呼ばれるデータ型は、すべてのタイプのROWIDをサポートしています。

ROWIDの使用

Oracle Databaseでは、ROWIDを内部的に使用して索引が構築されます。最も一般的なタイプはBツリー索引で、この索引は、複数の範囲に分割され、順序付けられたキーのリストから構成されます。それぞれのキーは、高速アクセスのために、対応する行のアドレスを指すROWIDに結び付けられています。エンド・ユーザーとアプリケーション開発者は、次のような重要な用途にROWIDを使用することもできます。

- ROWIDは特定の行にアクセスする最も高速な方法です。

- ROWIDは表の編成を把握する機能を提供します。

- ROWIDは表の中の行の一意識別子です。

また、ROWIDデータ型を使用して定義した列を持つ表を作成することもできます。たとえば、データ型ROWIDの列を持つ例外表を定義して、整合性制約に違反する行のROWIDを格納できます。ROWIDデータ型を使用して定義されている列の動作は、値を更新できるなど、表の他の列と同様です。

ROWID疑似列

Oracleデータベースのそれぞれの表は、ROWIDという名前の疑似列を持っています。疑似列は、表の列に似ていますが、実際には表に格納されません。疑似列からの選択はできますが、疑似列の値を挿入、更新または削除することはできません。疑似列は、引数のないSQLファンクションにも似ています。引数のない関数は通常、結果セットの各行に同じ値を戻しますが、疑似列は通常、行ごとに異なる値を戻します。

ROWID疑似列の値は、各行のアドレスを表す文字列です。これらの文字列は、ROWIDデータ型です。SELECTまたはDESCRIBEを実行して表の構造をリストしても疑似列は表示されず、疑似列は領域も使用しません。ただし、それぞれの行のROWIDは、予約語ROWIDを列名として使用すると、SQL問合せで取得できます。

例2-4では、ROWID擬似列を問い合せて、employees表にある従業員100の行のROWIDを表示します。

例2-4 ROWID擬似列

SQL> SELECT ROWID FROM employees WHERE employee_id = 100;

ROWID
------------------
AAAPecAAFAAAABSAAA

関連項目:

- 「ROWID形式」

- アドレスによる行の識別方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- ROWIDデータ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

書式モデルとデータ型

書式モデルは、格納された日時または数値データの書式を文字列で記述する文字リテラルです。書式モデルによってデータベース内の値の内部表現が変更されることはありません。

文字列を日付または数値に変換する場合、データベースが文字列を解釈する方法は、書式モデルによって決まります。SQLでは、TO_CHAR関数とTO_DATE関数の引数として書式モデルを使用し、データベースから戻される値の書式またはデータベースに格納される値の書式を設定できます。

次の文は、部門80の従業員の給与を選択し、TO_CHAR関数を使用してそれらの給与を数値書式モデル'$99,990.99'で指定された書式の文字値に変換します。

SQL> SELECT last_name employee, TO_CHAR(salary, '$99,990.99')
2  FROM   employees
3  WHERE  department_id = 80 AND last_name = 'Russell';

EMPLOYEE                  TO_CHAR(SAL
------------------------- -----------
Russell                    $14,000.00

次の例では、TO_DATE関数で書式マスク'YYYY MM DD'を使用して採用日を更新し、文字列'1998 05 20'をDATE値に変換します。

SQL> UPDATE employees
2  SET hire_date = TO_DATE('1998 05 20','YYYY MM DD')
3  WHERE last_name = 'Hunold';

関連項目:
書式モデルの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

整合性制約

整合性制約とは、表の1つ以上の列の値を制限する名前付きの規則のことです。これらの規則により、表に無効なデータが入力されないようにします。また、特定の依存性が存在する場合、制約によって表の削除を回避できます。

制約が使用可能である場合、データベースは、入力または更新の時点でのデータをチェックします。制約に準拠しないデータの入力は阻止されます。制約が使用禁止にされている場合、制約に準拠していないデータがデータベースに入力される可能性があります。

例2-1のCREATE TABLE文には、last_name、email、hire_dateおよびjob_idの各列にNOT NULL制約が指定されています。これらの制約句により、列と制約の条件が識別されます。これらの制約は、指定された列にNULL値が含まれないことを保証します。たとえば、職務IDのない新しい従業員を挿入しようとすると、エラーが発生します。

制約は、表の作成時または作成後に作成できます。必要に応じて、一時的に制約を使用禁止にできます。データベースでは、制約はデータ・ディクショナリに格納されます。

関連項目:

- 整合性制約の詳細は、第5章「データ整合性」を参照してください。

- SQL制約句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

オブジェクト表

Oracleのオブジェクト型は、名前、属性およびメソッドを含むユーザー定義データ型です。オブジェクト型を使用すると、顧客や発注書などの実社会のエンティティをデータベース内のオブジェクトとしてモデル化できます。

オブジェクト型では論理構造が定義されますが、記憶域は作成されません。例2-5では、department_typという名前のオブジェクト型を作成します。

例2-5 オブジェクト型

CREATE TYPE department_typ AS OBJECT
( d_name     VARCHAR2(100),
d_address  VARCHAR2(200) );
/

オブジェクト表は、すべての行がオブジェクトを表す特殊な表です。例2-6のCREATE TABLE文は、オブジェクト型department_typのdepartments_obj_tという名前のオブジェクト表を作成します。この表の属性(列)は、オブジェクト型の定義から導出されます。INSERT文は、この表に行を挿入します。

例2-6 オブジェクト表

CREATE TABLE departments_obj_t OF department_typ;
INSERT INTO departments_obj_t
VALUES ('hr', '10 Main St, Sometown, CA');

リレーショナル列と同様に、オブジェクト表に含めることができるのは、表と同一の宣言された型のオブジェクト・インスタンスなど、1種類の行のみです。デフォルトで、オブジェクト表のすべての行オブジェクトに関連する論理オブジェクト識別子(OID)があり、この識別子によりオブジェクト表の行オブジェクトが一意に識別されます。オブジェクト表のOID列は、非表示の列です。

関連項目:

- Oracle Databaseのオブジェクト・リレーショナル機能の詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。

- CREATE TYPEの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

一時表

Oracle Databaseの一時表には、トランザクションまたはセッションの期間中にのみ存在するデータが保持されます。一時表内のデータはセッションのプライベートであり、各セッションが表示および変更できるのは、そのセッション自身のデータのみです。

一時表は、結果セットをバッファリングする必要があるアプリケーションで役立ちます。たとえば、スケジューリング・アプリケーションでは、大学生が学期のオプション・コースのスケジュールを作成できます。各スケジュールは、一時表の行によって表示されます。セッション中、スケジュール・データはプライベートです。学生がスケジュールを決定すると、アプリケーションは選択されたスケジュールの行を永続表に移します。セッションの終了時、一時表内のスケジュール・データは自動的に削除されます。

一時表の作成

一時表は、CREATE GLOBAL TEMPORARY TABLE文で作成されます。ON COMMIT句では、表データをトランザクション固有(デフォルト)とセッション固有のどちらにするかを指定します。

他の一部のリレーショナル・データベース内の一時表とは異なり、Oracleデータベースに一時表を作成する場合は、静的な表定義を作成します。一時表は、データ・ディクショナリに記述される永続オブジェクトですが、セッションで表にデータが挿入されるまでは空のように見えます。それぞれのPL/SQLストアド・プロシージャではなく、データベース自体に一時表を作成します。

一時表は静的に定義されるため、CREATE INDEX文を使用して一時表の索引を作成できます。一時表に作成された索引も一時的です。その索引のデータは、一時表のデータと同じセッションまたはトランザクション・スコープを持ちます。また、一時表のビューまたはトリガーを作成することも可能です。

関連項目:

- 一時表の作成および管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE GLOBAL TEMPORARY TABLEの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

- 「ビューの概要」および「トリガーの概要」

一時表でのセグメントの割当て

永続表と同様に、一時表はデータ・ディクショナリに定義されます。一時セグメントは、最初にデータが挿入されたときに割り当てられます。セッションでデータがロードされるまで、表は空のように見えます。一時セグメントは、トランザクション固有の一時表の場合はトランザクションの終了時に、セッション固有の一時表の場合はセッションの終了時に割当て解除されます。

関連項目:
「一時セグメント」

外部表

外部表では、外部ソースのデータに対して、データベース内の表にあるデータのようにアクセスできます。SQL、PL/SQLおよびJavaを使用して外部データを問い合せることができます。

外部表は、フラット・ファイルを問い合せる場合に便利です。たとえば、SQLベースのアプリケーションでテキスト・ファイル内のレコードにアクセスする必要があるとします。レコードは次の形式になっています。

100,Steven,King,SKING,515.123.4567,17-JUN-03,AD_PRES,31944,150,90
101,Neena,Kochhar,NKOCHHAR,515.123.4568,21-SEP-05,AD_VP,17000,100,90
102,Lex,De Haan,LDEHAAN,515.123.4569,13-JAN-01,AD_VP,17000,100,90

外部表を作成し、外部表の定義で指定した場所にファイルをコピーすると、SQLを使用してテキスト・ファイル内のレコードを問い合せることができます。

外部表は、データ・ウェアハウス環境で一般的なETLタスクを実行する場合にも役立ちます。たとえば、外部表を使用すると、ロード・フェーズと変換フェーズをパイプライン処理できるようになり、データベース内のデータに対してさらに処理を実行するために、データベース内でステージングする必要がなくなります。「データ・ウェアハウスとビジネス・インテリジェンスの概要」を参照してください。

外部表の作成

内部的には、外部表の作成はデータ・ディクショナリでのメタデータの作成を意味します。通常の表とは異なり、外部表にはデータベースに格納されているデータは示されず、外部でのデータの格納方法も示されません。かわりに、外部表のメタデータに外部表レイヤーでのデータベースに対するデータの表示方法が記述されています。

CREATE TABLE ... ORGANIZATION EXTERNAL文は、2つの部分に分かれています。外部表の定義には、列型を記述します。この定義は、外部データをデータベースにロードすることなくSQL問合せを実行できるビューに似ています。文の2番目の部分は、外部データを列にマップします。

外部表は、CREATE TABLE AS SELECTでORACLE_DATAPUMPアクセス・ドライバを指定して作成される場合を除き、読取り専用です。外部表の制限は、索引付けされた列、仮想列および列オブジェクトがサポートされないことです。

外部表のアクセス・ドライバ

アクセス・ドライバとは、データベースの外部データを解釈するAPIのことです。アクセス・ドライバはデータベースの内部で動作し、データベースはアクセス・ドライバを使用して外部表のデータを読み取ります。外部表の定義に合うようにデータファイルのデータに必要な変換を行うのは、アクセス・ドライバおよび外部表レイヤーの役割です。図2-4に外部データへのアクセス方法を示します。

図2-4 外部表

Oracleは、外部表用としてORACLE_LOADER(デフォルト)とORACLE_DATAPUMPアクセス・ドライバを用意しています。両方のドライバにとって、外部ファイルはOracleデータファイルではありません。

ORACLE_LOADERは、SQL*Loaderを使用した外部ファイルへの読取り専用アクセスを可能にします。ORACLE_LOADERドライバを使用して外部ファイルを作成または更新することや、外部ファイルへの追加を行うことはできません。

ORACLE_DATAPUMPドライバを使用すると、外部データをアンロードできます。この操作では、データベースからデータが読み取られ、1つ以上の外部ファイルで表される外部表にデータが挿入されます。外部ファイルが作成されると、データベースはデータの更新や外部ファイルへのデータの追加を実行できなくなります。このドライバを使用すると、外部データのロードも可能になり、外部表が読み取られ、そのデータがデータベースにロードされます。

関連項目:

- 外部表、外部接続およびディレクトリ・オブジェクトの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 外部表の詳細は、『Oracle Databaseユーティリティ』を参照してください。

- 外部表の作成と問合せの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表の記憶域

Oracle Databaseは、表領域のデータ・セグメントを使用して表データを保持します。「ユーザー・セグメント」で説明しているように、セグメントにはデータ・ブロックからなるエクステントが含まれています。

表のデータ・セグメント(表クラスタを扱っている場合はクラスタ用のデータ・セグメント)は、表所有者のデフォルト表領域、またはCREATE TABLE文で指定された表領域に配置されます。

表の編成

デフォルトでは、表はヒープとして編成され、データベースでは、ユーザーが指定する順序ではなく、最も収まりすいように行が配置されます。このため、ヒープ構成表は、順不同の行のコレクションとなります。ユーザーが行を追加すると、データベースではデータ・セグメントの最初の使用可能な空き領域に行が格納されます。挿入された順序どおりに行が取得されることは保証されていません。

注意:
ヒープ構成表では、異なる編成の原理が使用されます。「索引構成表の概要」を参照してください。

hr.departments表は、ヒープ構成表です。この表には、部門ID、部門名、管理者ID、所在地IDの列があります。行が挿入されると、データベースでは、それらの行が収まる位置に格納されます。表セグメント内のデータ・ブロックには、例2-7に示すように、順不同の行が含まれることがあります。

例2-7 departments表の行

50,Shipping,121,1500
120,Treasury,,1700
70,Public Relations,204,2700
30,Purchasing,114,1700
130,Corporate Tax,,1700
10,Administration,200,1700
110,Accounting,205,1700

1つの表内のすべての行は、列の順序が同一です。データベースでは、通常、CREATE TABLE文でリストされた順序で列が格納されますが、この順序は保証されません。たとえば、表にLONG型の列があると、Oracle Databaseでは、この列は必ず最後に行に格納されます。また、表に新しい列を追加すると、その新しい列は最後に格納されます。

表には仮想列を含めることができ、仮想列は通常の列とは異なり、ディスク上の領域を使用しません。データベースによりユーザーの指定する一連の式または関数が計算され、必要に応じて仮想列から値が導出されます。仮想列には、索引付け、統計の収集および整合性制約の作成が可能です。このため、仮想列は通常の列とほとんど同じです。

関連項目:
仮想列の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

行の格納

データベースでは、行がデータ・ブロックに格納されます。列数が256未満のデータを含む表の各行は、1つ以上の行断片に格納されます。

Oracle Databaseは、可能なかぎり各行を1つの行断片として格納します。ただし、行データのすべてを1つのデータ・ブロックに挿入できない場合、または既存の行が更新されてそのデータ・ブロックの容量を超えた場合、データベースは複数の行断片を使用して行を格納します(「データ・ブロックの形式」を参照)。

表クラスタ内の行には、クラスタ化されていない表の行と同じ情報が格納されます。また、表クラスタ内の行には、それらの行が属するクラスタ・キーを参照する情報も格納されます。

行断片のROWID

ROWIDとは、実際には行の10バイトの物理アドレスのことです。「ROWIDデータ型」で説明しているように、ヒープ構成表のすべての行にはその表で一意のROWIDがあり、これは行断片の物理アドレスに相当します。表クラスタの場合、同じデータ・ブロックにある異なる表の行のROWIDが同一の場合もあります。

Oracle Databaseでは、ROWIDを内部的に使用して索引が構築されます。たとえば、Bツリー索引のそれぞれのキーは、高速アクセスのために、対応する行のアドレスを指すROWIDに結び付けられています(「Bツリー索引」を参照)。物理ROWIDを使用すると、表の1つの行に最速でアクセスでき、データベースではわずか1回のI/Oで行を取得できます。

関連項目:
「ROWID形式」

NULL値の格納

NULLは、列に値がないことを示します。NULLは、データがない、不明である、または適切でないことを示します。

データ値を持つ2つの列の間にはさまれたNULLはデータベースに格納されます。このような場合、NULLには列の長さ(ゼロ)を格納する1バイトのみが必要となります。新しい行のヘッダーが前行の残りの列がNULLであることを示すため、行の末尾にあるNULLには記憶域は不要です。たとえば、表の最後の3列がNULLであれば、その3列にはデータは格納されません。

関連項目:
NULL値の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表の圧縮

データベースでは、表の圧縮を使用して、表に必要な記憶域を削減します。圧縮によりディスク領域を節約し、データベース・バッファ・キャッシュでのメモリー使用量を減らすことができ、場合によっては問合せ実行時間も短縮できます。表の圧縮は、データベース・アプリケーションに対して透過的です。

基本および高度な行圧縮

ディクショナリ・ベースの表圧縮は、ヒープ構成表に対する高い圧縮率を実現します。Oracle Databaseでは、次のタイプのディクショナリ・ベースの表圧縮をサポートしています。

- 基本表圧縮
このタイプの圧縮は、バルク・ロード操作向けのものです。データベースでは、従来型のDMLを使用して変更されたデータは圧縮されません。基本圧縮を実行するには、ダイレクト・パス・ロード(ALTER TABLE . . . MOVE操作)または表のオンライン再定義を使用する必要があります。

- 高度な行圧縮
このタイプの圧縮はOLTPアプリケーション向けで、すべてのSQL操作によって操作されたデータを圧縮します。

基本および高度な行圧縮の場合、データベースでは、圧縮された行は行優先形式で格納されます。この形式では、ある行のすべての列がまとめて格納され、それ以降の行も同様に行単位ですべての列がまとめて格納されます(図12-7を参照)。重複値は、ブロックの先頭に格納されているシンボル表の短い参照で置き換えられます。このため、非圧縮データを再作成するために必要な情報は、データ・ブロック自体に格納されます。

圧縮されたデータ・ブロックは、通常のデータ・ブロックとほぼ同じです。通常のデータ・ブロックに対して動作するデータベース機能のほとんどは、圧縮ブロックに対しても動作します。

表領域、表、パーティションまたはサブパーティション・レベルで圧縮を宣言できます。表領域レベルで指定した場合、その表領域に作成されたすべての表はデフォルトで圧縮されます。

次の文は、OLTP圧縮をorders表に適用します。

ALTER TABLE oe.orders COMPRESS FOR OLTP;

次の部分的なCREATE TABLE文の例では、1つのパーティションにOLTP圧縮を指定し、もう1つのパーティションに基本圧縮を指定しています。

CREATE TABLE sales (
prod_id     NUMBER     NOT NULL,
cust_id     NUMBER     NOT NULL, ... )
PCTFREE 5 NOLOGGING NOCOMPRESS
PARTITION BY RANGE (time_id)
( partition sales_2010 VALUES LESS THAN(TO_DATE(...)) COMPRESS BASIC,
partition sales_2011 VALUES LESS THAN (MAXVALUE) COMPRESS FOR OLTP );

関連項目:

- 圧縮データ・ブロックの形式の詳細は、「データ・ブロックの圧縮」を参照してください。

- 表圧縮の詳細は、『Oracle Database管理者ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- SQL*Loaderを使用したダイレクト・パス・ロードの詳細は、「SQL*Loader」を参照してください。

ハイブリッド列圧縮

ハイブリッド列圧縮では、行グループの同じ列がまとめてデータベースに格納されます。データ・ブロックのデータは行優先形式では格納されませんが、行および列の両方を組み合せた方法が使用されます。

同じデータ型で、類似した特性を持つ列データをまとめて格納することで、圧縮によって節減できる記憶域が大幅に増加します。データベースでは、任意のSQL操作によって処理されるデータを圧縮しますが、ダイレクト・パス・ロードでは圧縮レベルがより高くなります。データベース操作は圧縮オブジェクトに対して透過的に実行されるため、アプリケーションを変更する必要はありません。

ハイブリッド列圧縮のタイプ

基礎となるストレージがハイブリッド列圧縮をサポートしている場合は、必要に応じて次の圧縮タイプを指定できます。

- ウェアハウス圧縮
このタイプの圧縮は、記憶域の節減用に最適化されており、データ・ウェアハウス・アプリケーション向けです。

- オンライン・アーカイブ圧縮
このタイプの圧縮は、最大の圧縮レベル用に最適化されており、履歴データおよび変更されないデータ向けです。

ウェアハウスまたはオンライン・アーカイブ圧縮を実行するには、ダイレクト・パスのロード、ALTER TABLE . . . MOVE操作または表のオンライン再定義を使用する必要があります。

ハイブリッド列圧縮は、データ・ウェアハウス用またはExadataストレージ上の意思決定支援アプリケーション用に最適化されています。Exadataでは、ハイブリッド列圧縮を使用して圧縮された表の問合せパフォーマンスが最大化され、Exadataストレージ・サーバーに統合されている処理能力、メモリーおよびインフィニバンド・ネットワーク帯域幅の利点を活用できます。

その他のOracleストレージ・システムでは、ハイブリッド列圧縮がサポートされ、Exadataストレージと同様の領域の節減は可能ですが、Exadataストレージと同じレベルの問合せパフォーマンスは得られません。これらのストレージ・システムでは、まれにしかアクセスしない古いデータのインデータベースでのアーカイブには、ハイブリッド列圧縮が理想的です。

圧縮ユニット

ハイブリッド列圧縮では、行の集合を格納するために、圧縮ユニットと呼ばれる論理的な構造が使用されます。表にデータをロードする場合、データベースでは、行のグループは列形式で、それぞれの列の値としてまとめて圧縮されて格納されます。データベースでは、一連の行の列データが圧縮された後、そのデータが圧縮ユニットに収められます。

たとえば、ハイブリッド列圧縮をdaily_sales表に適用するとします。1日の終わりに、品目と販売数が表に移入され、品目IDと日付がコンポジット主キーになります。表2-1にdaily_sales内の行のサブセットを示します。

表2-1 サンプル表daily_sales

Item_ID

Date

Num_Sold

Shipped_From

Restock

1000

01-JUN-11

2

WAREHOUSE1

Y

1001

01-JUN-11

0

WAREHOUSE3

N

1002

01-JUN-11

1

WAREHOUSE3

N

1003

01-JUN-11

0

WAREHOUSE2

N

1004

01-JUN-11

2

WAREHOUSE1

N

1005

01-JUN-11

1

WAREHOUSE2

N

表2-1の行が1つの圧縮ユニットに格納されるとします。ハイブリッド列圧縮では、各列の値がまとめて格納され、その後で複数のアルゴリズムを使用してそれぞれの列が圧縮されます。データベースでは、列のデータ型、列内の実際の値のカーディナリティ、ユーザーの選択した圧縮レベルなどの様々な要因に基づいてアルゴリズムが選択されます。

図2-5に示すように、各圧縮ユニットは、複数のデータ・ブロックにまたがることができます。特定の列の値は、複数のブロックにまたがる場合とまたがらない場合があります。

図2-5 圧縮ユニット

ハイブリッド列圧縮は、行のロックと密接に関連しています(「行のロック(TX)」を参照)。非圧縮のデータ・ブロックで行の更新が発生した場合、更新される行のみがロックされます。これに対して、更新が圧縮ユニットのいずれかの行で発生した場合、データベースではそのユニットのすべての行をロックする必要があります。ハイブリッド列圧縮を使用している行を更新すると、ROWIDが変更されます。

注意:
表でハイブリッド列圧縮を使用する場合、Oracle DMLでは、比較的大きなデータ・ブロック(圧縮ユニット)がロックされるため、同時実行性が低下する可能性があります。

関連項目:

- ハイブリッド列圧縮のライセンス要件の詳細は、『Oracle Databaseライセンス情報』を参照してください。

- ハイブリッド列圧縮の使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

表クラスタの概要

表クラスタとは、共通の列を共有し、関連するデータを同じブロックに格納する表のグループのことです。表がクラスタ化されると、1つのデータ・ブロックに複数の表の行を含めることができます。たとえば、ブロックにemployees表とdepartments表のいずれか1つのみでなく、両方の表の行を格納できます。

クラスタ・キーとは、クラスタ化表で共有される1つ以上の列のことです。たとえば、employeesおよびdepartments表はdepartment_id列を共有しています。表クラスタの作成時と表クラスタに追加されるすべての表の作成時にクラスタ・キーを指定します。

クラスタ・キー値とは、特定の行のセットに対するクラスタ・キー列の値のことです。department_id=20などの同じクラスタ・キー値を含むすべてのデータは、物理的にまとめて格納されます。各クラスタ・キー値は、その値を持つ行がいくつかの表に含まれているとしても、クラスタとクラスタ索引にそれぞれ一度のみ格納されます。

たとえば、HR管理者が2つの書棚を使用しており、1つの書棚には従業員フォルダの箱があり、もう1つの書棚には部門フォルダの箱があるとします。ユーザーは、特定の部門に属する全従業員のフォルダを頻繁に問い合せます。管理者は、取り出しやすいようにすべての箱を1つの書棚に配置しなおします。管理者は、部門IDごとに箱を分割します。その結果、部門20に属する従業員のすべてのフォルダと部門20自体のフォルダが1つの箱に入り、部門100の従業員のフォルダと部門100のフォルダも別の箱に入り、他の部門のフォルダもそれぞれの箱に入ります。

ある複数の表が主に問合せの対象となり(ただし変更はできない)、これらの表のレコードが、頻繁に同時に問い合されるか、結合される場合は、表のクラスタ化を検討できます。表クラスタは、異なる表の関連した行を、同じデータ・ブロック内に格納するため、表クラスタを適切に使用すると、クラスタ化されていない表と比較して次のような利点があります。

- クラスタ化表を結合する場合のディスクI/Oが減少します。

- クラスタ化表を結合する場合のアクセス時間が改善されます。

- クラスタ・キー値が行ごとに繰り返し格納されないため、関連する表データと索引データの格納に必要な記憶域が少なくなります。

通常、表のクラスタ化は、次のような場合には適していません。

- 表が頻繁に更新される場合。

- 表の全表スキャンが頻繁に必要な場合。

- 表で切捨てが必要な場合。

関連項目:
表クラスタを使用する場合のガイドラインは、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

索引付きクラスタの概要

索引付きクラスタとは、索引を使用してデータを検索する表クラスタのことです。クラスタ索引とは、クラスタ・キーのBツリー索引のことです。クラスタ索引は、クラスタ化表に行を挿入する前に作成しておく必要があります。

例2-8に示すように、department_idという名前のクラスタ・キーを指定してクラスタemployees_departments_clusterを作成するとします。HASHKEYS句は指定されないため、このクラスタは索引付きクラスタになります。次に、このクラスタ・キーにidx_emp_dept_clusterという名前の索引を作成します。

例2-8 索引付きクラスタ

CREATE CLUSTER employees_departments_cluster
(department_id NUMBER(4))
SIZE 512;

CREATE INDEX idx_emp_dept_cluster ON CLUSTER employees_departments_cluster;

その後、次のように、このクラスタにemployees表とdepartments表を作成し、クラスタ・キーとしてdepartment_id列を指定します(省略記号は、列が指定される場所のマークです)。

CREATE TABLE employees ( ... )
CLUSTER employees_departments_cluster (department_id);

CREATE TABLE departments ( ... )
CLUSTER employees_departments_cluster (department_id);

最後に、employees表とdepartments表に行を追加します。データベースでは、employees表とdepartments表の各部門の行がすべて同じデータ・ブロックに物理的に格納されます。データベースでは、行がヒープに格納され、索引を使用してこれらの行が検索されます。

図2-6に、employeesとdepartmentsを含むemployees_departments_cluster表クラスタを示します。データベースでは、従業員20に属する従業員や部門110などの行がまとめて格納されます。表がクラスタ化されていない場合、データベースでは関連する行がまとめて格納されることは保証されません。

図2-6 クラスタ化表データ

Bツリー・クラスタ索引は、データを含むブロックのデータベース・ブロック・アドレス(DBA)にクラスタ・キー値を関連付けます。たとえば、キー20の索引エントリには、部門20の従業員のデータを含むブロックのアドレスが表示されます。

20,AADAAAA9d

クラスタ索引は、クラスタ化されていない表の索引と同様に個別に管理され、表クラスタとは別の表領域に存在することがあります。

関連項目:

- 「索引の概要」

- 索引付きクラスタの作成方法と管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE CLUSTERの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

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

ハッシュ・クラスタは、索引キーがハッシュ関数に置き換わることを除いて、索引付きクラスタと似ています。別個のクラスタ索引は存在しません。ハッシュ・クラスタでは、データが索引になります。

索引付きの表または索引付きのクラスタでは、Oracle Databaseは、別個の索引に格納されたキー値を使用して、表の行を見つけます。索引付きの表または表クラスタを検索または格納するには、次のようにデータベースは、最低2回のI/Oを実行する必要があります。

- 索引内でキー値を検索または格納するために1回以上のI/O

- 表または表クラスタ内の行を読取り/書込みするためにさらに1回のI/O

Oracle Databaseでは、ハッシュ・クラスタ内で行を検索または格納するため、ハッシュ関数を行のクラスタ・キー値に適用します。結果として得られるハッシュ値はクラスタ内の1つのデータ・ブロックに対応し、データベースにより、発行された文による読取り/書込みがそのデータ・ブロックに対して実行されます。

ハッシングは、データ検索のパフォーマンスを改善するために表データを格納するオプションの方法です。ハッシュ・クラスタは、次の条件が満たされている場合に便利です。

- 表の問合せが、表の変更よりもはるかに頻繁に行われる場合。

- ハッシュ・キー列に対する問合せの条件が、多くの場合、WHERE department_id=20のような等価条件である場合。このような問合せでは、クラスタ・キー値がハッシュ化されます。ハッシュ・キー値は、行が格納されているディスク領域を直接指します。

- 当然、ハッシュ・キーの数が多くなれば、キー値も一緒に格納されるためデータのサイズが大きくなります。

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

クラスタ・キーは、索引付きクラスタのキーと同様に、単一の列、またはクラスタ内の表が共有するコンポジット・キーです。ハッシュ・キー値は、クラスタ・キー列に挿入される実際の値または推定値です。たとえば、クラスタ・キーがdepartment_idの場合は、ハッシュ・キー値が10、20、30のような値になります。

Oracle Databaseでは、無数にあるハッシュ・キー値を入力として受け付け、限定された数のバケットに選別するハッシュ関数が使用されます。各バケットにはハッシュ値という一意の数値IDが付与されます。各ハッシュ値は、ハッシュ・キー値(部門10、20、30など)に対応する行の格納ブロックのデータベース・ブロック・アドレスにマップされます。

ハッシュ・クラスタを作成するときは、索引付きクラスタの場合と同じCREATE CLUSTER文を使用しますが、ハッシュ・キーを別途指定する必要があります。クラスタのハッシュ値の数はハッシュ・キーに応じて増減します。図2-9では、存在すると推測される部門数が100であるため、HASHKEYSが100に設定されています。

例2-9 ハッシュ・クラスタ

CREATE CLUSTER employees_departments_cluster
(department_id NUMBER(4))
SIZE 8192 HASHKEYS 100;

employees_departments_clusterの作成後に、そのクラスタ内にemployees表とdepartments表を作成できます。次に、例2-8で説明した索引付きクラスタの場合と同様に、ハッシュ・クラスタにデータをロードできます。

関連項目:
ハッシュ・クラスタの作成方法と管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

ハッシュ・クラスタの問合せ

ユーザーが入力するキー値をハッシュする方法は、ユーザーではなく、データベースが決定します。たとえば、ユーザーが次のような問合せを頻繁に実行し、p_idに様々な部門ID番号を入力するとします。

SELECT *
FROM   employees
WHERE  department_id = :p_id;

SELECT *
FROM   departments
WHERE  department_id = :p_id;

SELECT *
FROM   employees e, departments d
WHERE  e.department_id = d.department_id
AND    d.department_id = :p_id;

ユーザーがdepartment_id=20の従業員を問い合せた場合は、この値がバケット77にハッシュされます。department_id=10の従業員を問い合せた場合は、この値がバケット15にハッシュされます。データベースは、内部的に生成されるハッシュ値を使用して、問合せ対象の部署に対応する従業員行を格納したブロックを検索します。

図2-7は、ハッシュ・クラスタ・セグメントを水平方向に並べたブロック行として示しています。この図に示すように、1件の問合せにつき、1回のI/Oでデータを取得できます。

図2-7 ハッシュ・クラスタからのデータの取得

ハッシュ・クラスタの制限は、索引のないクラスタ・キーのレンジ・スキャンを使用できないことです(「索引レンジ・スキャン」を参照)。例 2-9で作成したハッシュ・クラスタに、独立した索引が存在しないものとします。IDが20から100の部門の問合せは、20から100の間のすべての取り得る値をハッシュしていないため、ハッシュ・アルゴリズムを使用できません。索引が存在しないため、データベースでは全体スキャンを実行する必要があります。

様々なハッシュ・クラスタ

単一表ハッシュ・クラスタとは、同時に1つの表のみをサポートするために最適化されたハッシュ・クラスタのバージョンのことです。ハッシュ・キーと行との間には、1対1のマッピングがあります。単一表ハッシュ・クラスタは、ユーザーが主キーを使用して表に迅速にアクセスする必要がある場合に便利です。たとえば、ユーザーがemployee_idを使用してemployees表の従業員レコードを頻繁に検索する場合などです。

ソート済のハッシュ・クラスタに、ハッシュ関数の各値に対応する行が格納されると、データベースは効率的に行を戻すことが可能になります。データベースは最適化されたソートを内部的に実行します。ソートされた状態のデータを常に使用するアプリケーションの場合は、この方式によりデータの取得が速くなる可能性があります。たとえば、アプリケーションがorders表のorder_date列で常にソートする場合が考えられます。

関連項目:
単一表ハッシュ・クラスタとソート済のハッシュ・クラスタの作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

ハッシュ・クラスタの記憶域

Oracle Databaseは、ハッシュ・クラスタのための領域を索引付きクラスタとは異なる方法で割り当てます。例2-9では、HASHKEYSに存在する可能性のある部門数を指定し、SIZEに各部門に関連付けられたデータのサイズを指定しています。次の式に従って記憶域領域の値が計算されます。

HASHKEYS * SIZE / database_block_size

したがって、図2-9のようにブロック・サイズが4096バイトの場合は、ハッシュ・クラスタに200以上のブロックが割り当てられます。

Oracle Databaseでは、クラスタに挿入可能なハッシュ・キー値の数に制限はありません。たとえば、HASHKEYSが100になっている場合でも、departments表に一意の部門を200個挿入することも可能です。ただし、ハッシュ値の数がハッシュ・キーの数よりも多くなると、ハッシュ・クラスタ取得の効率が悪くなります。

取得の問題について、図2-7でブロック100が部門20の行でまったく空きがない場合の例で説明します。ユーザーがdepartment_idが43の新しい部署をdepartments表に挿入します。部門の数がHASHKEYS値よりも大きいため、department_id 43はハッシュ値77にハッシュされますが、これは、department_id 20に使用されているハッシュ値と同じです。複数の入力値を同じ出力値にハッシュすることをハッシュ衝突と呼びます。

ユーザーが部門43のクラスタに行を挿入しようとしても、ブロック100はいっぱいであるため、行は格納されません。ブロック100は新しいオーバーフロー・ブロック(ここではブロック200とします)にリンクされ、その新しいブロックに挿入行が格納されます。つまり、ブロック100とブロック200の両方に、どちらの部門のデータも格納されている可能性があることになります。図2-8に示すように、部門20または部門43を問い合せると、ブロック100とその関連ブロックであるブロック200からデータが取得されるため、I/Oが2回必要になります。この問題を解決するには、別々のHASHKEYS値を持つクラスタを作成しなおす必要があります。

図2-8 ハッシュ衝突が発生している場合のハッシュ・クラスタからのデータの取得

関連項目:
ハッシュ・クラスタの領域を管理する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

3 索引と索引構成表

この章では、表の行へのアクセスを高速化できるスキーマ・オブジェクトである索引と、索引構造に格納される表である索引構成表について説明します。

この章の内容は、次のとおりです。

- 索引の概要

- 索引構成表の概要

索引の概要

索引は、表または表クラスタに関連するオプションの構造であり、索引によってデータ・アクセスを高速化できる場合があります。表の1つ以上の列に索引を作成することによって、場合によって、ランダムに分散している行の小さなセットを表から取得できるようになります。索引は、ディスクI/Oを削減するための様々な手段のうちの1つです。

ヒープ構成表に索引がない場合、そのデータベースでは、値の検索に全表スキャンを実行する必要があります。たとえば、索引がない場合、hr.departments表の位置2700の問合せでは、データベースは、すべての表ブロックのすべての行でこの値を検索する必要があります。データ量が増加すると、この方法では適切に対応できなくなります。

たとえば、ある人事管理マネージャが複数の段ボール箱を棚に置いて管理しているとします。従業員情報を収めたフォルダが、それらの箱にランダムに収納されています。従業員Whalen(ID 200)のフォルダは、1つ目の箱の下から10フォルダ目であり、King(ID 100)のフォルダは3つ目の箱の一番下にあります。マネージャがフォルダを見つけるには、1つ目の箱の一番下から一番上まですべてのフォルダを確認し、目的のフォルダが見つかるまで次の箱で同じことを繰り返します。アクセスを高速化するために、マネージャは従業員全員のIDとフォルダの位置を順にリストした索引を作成できます。

ID 100: Box 3, position 1 (bottom)
ID 101: Box 7, position 8
ID 200: Box 1, position 10
.
.
.

同様に、マネージャは従業員の姓や部門IDなどの個別の索引を作成できます。

通常、次のいずれかの場合は、列に索引を作成することを検討します。

- 索引付けされた列を頻繁に問い合せ、表内の合計行数に対して割合の小さい行数が戻される場合。

- 索引付けされた列に参照整合性制約が存在する場合。索引は、全表ロックを回避する手段ですが、親表の主キーを更新したり、親表に主キーをマージしたり、親表から主キーを削除する場合は必須です。

- 表に一意キー制約を適用し、索引およびすべての索引オプションを手動で指定する場合。

関連項目:
第5章「データ整合性」

索引の特性

索引は、関連するオブジェクトのデータから論理的にも物理的にも独立したスキーマ・オブジェクトです。そのため、索引を削除または作成しても、索引の表に物理的な影響はありません。

注意:
索引を削除しても、アプリケーションは引き続き機能します。ただし、索引設定されていたデータへのアクセスは低速になる場合があります。

索引の有無によって、SQL文の表現を変更する必要はありません。索引は、単一行のデータへの高速なアクセス・パスです。それは実行のスピードにのみ影響を与えます。索引の付いたデータ値では、索引はその値を含んでいる行の位置を直接示すポインタとして機能します。

作成された索引は、データベースによって自動的にメンテナンスされ、使用されます。また、行の追加、更新、削除など、データに対する変更が、関連するすべての索引に自動的に反映され、ユーザーによる操作は不要です。行が挿入されても、索引付きのデータ検索のパフォーマンスはほとんど一定です。ただし、表に対して数多くの索引が存在すると、データベースの索引も更新する必要があるため、DMLのパフォーマンスは低下します。

索引の特性は、次のとおりです。

- 使用可能性
索引は、使用可能(デフォルト)または使用禁止にできます。使用禁止索引はDML操作により維持されず、オプティマイザによって無視されます。使用禁止索引により、バルク・ロードのパフォーマンスが向上します。索引を削除し、後から再作成するかわりに、索引を使用禁止にし、後から再構築できます。使用禁止索引と索引パーティションは、領域を使用しません。使用可能索引を使用禁止にすると、データベースによりその索引セグメントが削除されます。

- 可視性
索引は、参照用(デフォルト)または非参照用にできます。非参照用索引はDML操作により維持され、デフォルトではオプティマイザで使用されません。索引を非表示にするのは、使用禁止または削除の代替手段です。非参照用索引は、索引を削除する前に削除をテストする場合や、アプリケーション全体に影響を与えることなく一時的に索引を使用する場合に特に役立ちます。

関連項目:

- 「オプティマイザの概要」

- 索引の管理方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

- 索引のチューニング方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

キーと列

キーとは、索引を作成できる列または式の集合です。 索引とキーという用語は同じ意味で使用されることがありますが、これらの用語には違いがあります。索引は、データベース内に格納される構造体であり、ユーザーはSQL文を使用して管理します。一方、キーは厳密に論理的な概念です。

次の文は、サンプル表oe.ordersのcustomer_id列に索引を作成します。

CREATE INDEX ord_customer_ix ON orders (customer_id);

この文では、customer_id列が索引キーです。索引自体はord_customer_ixという名前です。

注意:
主キーと一意キーには自動的に索引が作成されますが、外部キーにも索引を作成できます。

関連項目:
CREATE INDEXの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

コンポジット索引

コンポジット索引(連結索引とも呼ばれる)は、表の中の複数の列に対して作成される索引です。コンポジット索引の列は、データを取得する問合せにとって最も効果的な順序で指定する必要があり、表の中で隣接している必要はありません。

SELECT文のWHERE句でコンポジット索引のすべての列または列の先頭部分を参照する場合には、コンポジット索引によってデータの検索速度を向上させることができます。そのため、定義で使用する列の順序は重要です。通常、最も頻繁にアクセスされる列が最初になります。

たとえば、アプリケーションが頻繁にemployees表のlast_name、job_idおよびsalary列への問合せを発行するとします。また、last_nameはカーディナリティが高く、表の行数に比べて個別値の数が多いとします。次のような列の順序で、索引を作成します。

CREATE INDEX employees_ix
ON employees (last_name, job_id, salary);

3つの列すべて、last_name列のみ、またはlast_nameおよびjob_id列のみにアクセスする問合せは、この索引を使用します。この例では、last_name列にアクセスしない問合せは索引を使用しません。

注意:
先頭列のカーディナリティが非常に低い場合などには、データベースでは、この索引のスキップ・スキャンが使用されることがあります(「索引スキップ・スキャン」を参照)。

列の順列が索引ごとに異なる場合は、同じ表に複数の索引が存在してもかまいません。列の順列を個別に指定すると、同じ列を使用して複数の索引を作成できます。たとえば、次のSQL文では有効な順列を指定しています。

CREATE INDEX employee_idx1 ON employees (last_name, job_id);
CREATE INDEX employee_idx2 ON employees (job_id, last_name);

関連項目:
コンポジット索引の使用方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

一意索引と非一意索引

索引には、一意索引と非一意索引の2種類があります。一意索引を使用すると、表の複数行のキー列に重複した値が入らないことが保証されます。たとえば、複数の従業員が同じ従業員IDを持つことはできません。このため、一意索引の場合、データ値ごとにROWIDが1つ存在します。リーフ・ブロックのデータはキーのみによってソートされます。

非一意索引では、索引付けされた1つ以上の列に重複値が許可されます。たとえば、employees表のfirst_name列に、複数のMike値が含まれていてもかまいません。非一意索引の場合、ROWIDはソートされた順序でキーに含まれるため、非一意索引は索引キーとROWIDによってソートされます(昇順)。

Oracle Databaseでは、すべてのキー列がNULLの表の行には、索引は作成されません。ただし、ビットマップ索引の場合や、クラスタ・キーの列値がNULLの場合は例外です。

索引のタイプ

Oracle Databaseは、パフォーマンスの機能性を補足する複数の索引体系を提供しています。索引は次のように分類できます。

- Bツリー索引
これらの索引は標準索引タイプです。これらは主キーおよび高度に選択的な索引に適しています。Bツリー索引を連結索引として使用すると、索引付けされた列でソートされたデータを取得できます。Bツリー索引には次のサブタイプがあります。

- 索引構成表
索引構成表はデータ自体が索引であるため、ヒープ構成表とは異なります。「索引構成表の概要」を参照してください。

- 逆キー索引
このタイプの索引では、索引キーのバイトの並びが逆になり、たとえば、103は301として格納されます。バイトの並びを逆にすることにより、索引への挿入が多数のブロックに分散されます。「逆キー索引」を参照してください。

- 降順索引
このタイプの索引では、特定の列(1つまたは複数)のデータが降順で格納されます。「昇順索引と降順索引」を参照してください。

- Bツリークラスタ索引
このタイプの索引は、表クラスタ・キーに索引付けするために使用されます。キーは行を指し示すのではなく、クラスタ・キーに関連する行を含むブロックを指します。「索引付きクラスタの概要」を参照してください。

- ビットマップ索引とビットマップ結合索引
ビットマップ索引では、索引エントリはビットマップを使用して複数の行を指します。対照的に、Bツリー索引エントリは単一の行を指します。ビットマップ結合索引は、2つ以上の表を結合するためのビットマップ索引です。「ビットマップ索引」を参照してください。

- ファンクション索引
このタイプの索引に含まれる列は、UPPERファンクションなどのファンクションによって変換されるか、式に含まれます。Bツリー索引またはビットマップ索引はファンクション索引です。「ファンクション索引」を参照してください。

- アプリケーション・ドメイン索引
このタイプの索引は、ユーザーによってアプリケーション固有ドメインのデータ用に作成されます。物理索引は従来の索引構造を使用する必要はなく、表としてOracle Databaseに格納することも、ファイルとして外部に格納することもできます。「アプリケーション・ドメイン索引」を参照してください。

関連項目:
様々な索引タイプの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

Bツリー索引

Bツリー(バランス・ツリーの略)は、最も一般的なタイプのデータベース索引です。Bツリー索引は、複数の範囲に分割された順序付きの値リストです。Bツリーは、キーを行または行の範囲と関連付けることによって、完全一致や範囲検索など、広範囲の問合せに対して優れた検索パフォーマンスを提供します。

図3-1に、Bツリー索引の構造を示します。この例では、employees表の外部キー列であるdepartment_id列の索引を示しています。

図3-1 Bツリー索引の内部構造

ブランチ・ブロックとリーフ・ブロック

Bツリー索引には、検索用のブランチ・ブロックと、値を格納するリーフ・ブロックの2種類のブロックがあります。Bツリー索引の上位ブランチ・ブロックには、下位レベルの索引ブロックを指す索引データが含まれます。図3-1では、ルート・ブランチ・ブロックに0-40のエントリがあり、次のブランチ・レベルの左端のブロックを指しています。このブランチ・ブロックには、0-10や11-19などのエントリがあります。これらの各エントリは、それぞれの範囲に該当するキー値を含むリーフ・ブロックを指します。

すべてのリーフ・ブロックは自動的に同じ深さになるため、Bツリー索引はバランスが保たれます。したがって、索引のどの位置からでも、レコード検索にかかる時間はほぼ同じになります。索引の高さは、ルート・ブロックからリーフ・ブロックに達するまでに必要なブロックの数です。ブランチ・レベルは高さから1を引いた数です。図3-1では、索引の高さは3、ブランチ・レベルは2です。

ブランチ・ブロックには、2つのキーの分岐を決定する際に必要な、最小のキー接頭辞が格納されます。このテクニックを使用すると、データベースでは各ブランチ・ブロックにできるかぎり多くのデータを収納できます。ブランチ・ブロックには、キーを含む子ブロックへのポインタが含まれます。キーおよびポインタの数は、ブロックのサイズによって制限されます。

リーフ・ブロックには、すべての索引付きデータ値と、実際の行を検索するための対応するROWIDが含まれています。各エントリは(キー、ROWID)によってソートされます。リーフ・ブロック内では、キーとROWIDは兄弟関係にある左右のエントリにリンクされます。リーフ・ブロック自体も二重にリンクされます。図3-1では、左端のリーフ・ブロック(0-10)が2番目のリーフ・ブロック(11-19)にリンクされます。

注意:
文字データを持つ列の索引は、データベース・キャラクタ・セットにおける文字のバイナリ値を基盤にしています。

索引スキャン

索引スキャンの場合、データベースでは文に指定された索引付けされた列値を使用し、索引を読み込むことによって行を検索します。データベースでは、索引をスキャンして値を検索する場合、n回のI/Oでこの値を見つけます(nは、Bツリー索引の高さ)。これがOracle Database索引の基本原理です。

SQL文が索引付けされた列のみにアクセスする場合、データベースでは表ではなく索引から値を直接読み取ります。文が索引付けされた列に加えて列にもアクセスする場合、データベースではROWIDを使用して表の中の行を検索します。通常、データベースでは索引ブロックと表ブロックを交互に読み取って表データを取得します。

関連項目:
索引スキャンの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

全索引スキャン

全索引スキャンの場合、データベースでは索引全体を順に読み取ります。全索引スキャンは、SQL文の述語(WHERE句)が索引の列を参照している場合、および述語が指定されていない場合に使用できます。全スキャンでは、データが索引キーによって順序付けられるため、ソートが不要になります。

アプリケーションにより、次の問合せが実行されるとします。

SELECT department_id, last_name, salary
FROM   employees
WHERE  salary > 5000
ORDER BY department_id, last_name;

また、department_id、last_nameおよびsalaryが索引のコンポジット・キーであるとします。Oracle Databaseでは、ソートされた順序(部門IDおよび姓の順序)で索引を読み取り、salary属性でフィルタ処理して索引の全スキャンを実行します。これにより、データベースでは、問合せに含まれている列より多くの列を含むemployees表よりも小さいデータ・セットがスキャンされ、データのソートが不要になります。

たとえば、全スキャンによって次のような索引エントリが読み取られます。

50,Atkinson,2800,rowid
60,Austin,4800,rowid
70,Baer,10000,rowid
80,Abel,11000,rowid
80,Ande,6400,rowid
110,Austin,7200,rowid
.
.
.

高速全索引スキャン

高速全索引スキャンは、データベースが特定の順序に従わずに索引ブロックを読み取る全索引スキャンで、表にアクセスすることなく、索引自体の中のデータにアクセスします。

高速全索引スキャンは、次に示す2つの条件が満たされている場合に全表スキャンの代替となるスキャンです。

- 問合せに必要なすべての列が索引に含まれていること。

- すべてNULLの行が問合せの結果セットに現れないこと。この結果を保証するためには、索引内の少なくとも1つの列に次のいずれかが存在する必要があります。

- NOT NULL制約。

- 問合せの結果セットにNULLが含まれないように考え抜かれた、列に適用される条件。

たとえば、アプリケーションにより、ORDER BY句を含まない次の問合せが発行されるとします。

SELECT last_name, salary
FROM   employees;

last_name列にはNOT NULL制約があります。姓と給与が索引のコンポジット・キーである場合、高速全索引スキャンでは索引エントリを読み取って、要求された情報を取得できます。

Baida,2900,rowid
Zlotkey,10500,rowid
Austin,7200,rowid
Baer,10000,rowid
Atkinson,2800,rowid
Austin,4800,rowid
.
.
.

索引レンジ・スキャン

索引レンジ・スキャンは、索引の順序付きスキャンであり、次の特性があります。

- 索引の1つ以上の先頭列を条件に指定します。条件は、1つ以上の式および論理(ブール)演算子の組合せを指定し、TRUE、FALSEまたはUNKNOWNの値を戻します。

- 0個、1個、または複数の値を索引キーにできます。

データベースでは一般的に、索引レンジ・スキャンを選択的なデータへのアクセスに使用します。選択性は、問合せで選択される表の中の行の割合で、0は行がないことを表し、1はすべての行を表します。選択性は、問合せの述語(WHERE last_name LIKE 'A%'など)や述語の組合せに関連します。述語は、値が0に近付くほど選択性が高くなり、値が1に近付くほど選択性が低く(非選択性が高く)なります。

たとえば、姓がAで始まる従業員を問い合せるとします。last_name列に索引が作成されており、次のエントリがあるとします。

Abel,rowid
Ande,rowid
Atkinson,rowid
Austin,rowid
Austin,rowid
Baer,rowid
.
.
.

last_name列が述語に指定されており、それぞれの索引キーに複数のROWIDが考えられるため、データベースではレンジ・スキャンを使用できます。たとえば、Austinという姓の従業員が2人いた場合、2つのROWIDがキーAustinに関連付けられます。

索引レンジ・スキャンは、10から40のIDを持つ部門の問合せのように、両側に境界がある場合と、40より大きいIDの問合せのように片側のみに境界がある場合があります。索引をスキャンするには、データベースではリーフ・ブロックを後方または前方に移動します。たとえば、10から40のIDを求めるスキャンでは、最小キー値10以上を含む最初の索引リーフ・ブロックが検索されます。次に、40より大きい値が見つかるまで、スキャンはリンクされたリーフ・ノード・リストを水平に進みます。

索引の一意スキャン

索引レンジ・スキャンとは対照的に、索引の一意スキャンでは、索引キーに関連付けられたROWIDは0個または1個である必要があります。データベースでは、述語が等価演算子を使用して一意索引キーのすべての列を参照する場合に、一意スキャンが実行されます。索引の一意スキャンでは、2つ目のレコードがないことがわかっているため、最初のレコードが見つかるとただちに処理が停止します。

例として、ユーザーが次の問合せを実行するとします。

SELECT *
FROM   employees
WHERE  employee_id = 5;

employee_id列が主キーで、次のようなエントリで索引が作成されているとします。

1,rowid
2,rowid
4,rowid
5,rowid
6,rowid
.
.
.

この場合、データベースでは、索引の一意スキャンを使用してIDが5の従業員のROWIDが検索されます。

索引スキップ・スキャン

索引スキップ・スキャンでは、コンポジット索引の論理副索引を使用します。個別の索引を検索する場合と同様に、データベースでは単一の索引をスキップします。コンポジット索引の先頭列に含まれる個別値が少数であり、索引の先頭以外のキーに多数の個別値がある場合は、スキップ・スキャンが有効です。

コンポジット索引の先頭列が問合せの述語に指定されていない場合、データベースでは、索引スキップ・スキャンを選択できます。たとえば、sh.customers表の顧客に対して次の問合せを実行するとします。

SELECT * FROM sh.customers WHERE cust_email = 'Abbey@company.com';

customers表にはcust_genderという列があり、この列の値はMまたはFです。列(cust_gender、cust_email)にコンポジット索引が存在するとします。例3-1は、索引エントリの一部を示しています。

例3-1 コンポジット索引エントリ

F,Wolf@company.com,rowid
F,Wolsey@company.com,rowid
F,Wood@company.com,rowid
F,Woodman@company.com,rowid
F,Yang@company.com,rowid
F,Zimmerman@company.com,rowid
M,Abbassi@company.com,rowid
M,Abbey@company.com,rowid

cust_genderはWHERE句に指定されていませんが、データベースでは、この索引のスキップ・スキャンを使用できます。

スキップ・スキャンでは、論理副索引の数は、先頭列の個別値の数によって決定されます。例3-1では、先頭列に2つの可能な値があります。データベースでは、索引を、キーFを持つ1つの副索引と、キーMを持つ2つ目の副索引に論理的に分割します。

Abbey@company.comという電子メールを持つ顧客のレコードを検索するとき、データベースでは、値Fを持つ副索引を最初に検索し、次に、値Mを持つ副索引を検索します。その結果、データベースでは問合せが次のように処理されます。

SELECT * FROM sh.customers WHERE cust_gender = 'F'
AND cust_email = 'Abbey@company.com'
UNION ALL
SELECT * FROM sh.customers WHERE cust_gender = 'M'
AND cust_email = 'Abbey@company.com';

関連項目:
スキップ・スキャンの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

索引クラスタ化係数

索引クラスタ化係数は、姓などの索引付きの値を対象に、行の順序性を測定した指標です。行の記憶域の中でこの値に関する順序性がよいほど、クラスタ化係数は小さくなります。

クラスタ化係数は、索引を使用した表全体の読取りに必要な入出力回数のおおよその目安として使用できます。特徴は次のとおりです。

- クラスタ化係数が高いほど、大規模な索引のレンジ・スキャン実行時の入出力回数が増えます。索引エントリはランダムな表ブロックを指しているため、データベースは索引が示すデータを取得するために、同じブロックの読取りが何回も必要になることがあります。

- クラスタ化係数が低いほど、大規模な索引のレンジ・スキャン実行時の入出力回数が減ります。同じ範囲の中にある索引キーは同じブロックを指していることが多いため、データベースは同じブロックを何度も読み取る必要がありません。

クラスタ化係数は、索引スキャンと深い関連性があります。これは、クラスタ係数で次の事項を判断できるからです。

- データベースが大規模なレンジ・スキャンに索引を使用するかどうか

- 索引キーに対する表の編成の度合い

- 索引キーに従って行を順序付ける必要がある場合に、索引構成表、パーティション化、表クラスタのいずれを使用するのがよいか

たとえば、employees表が2つのデータ・ブロックに分かれているとします。表3-1は、2つのデータ・ブロック内の行を示しています(省略記号は省略したデータを示します)。

表3-1 Employees表内にある2つのデータ・ブロックの内容

データ・ブロック1

データ・ブロック2

100   Steven    King       SKING    ...
156   Janette   King       JKING    ...
115   Alexander Khoo       AKHOO    ...
.
.
.
116   Shelli    Baida      SBAIDA   ...
204   Hermann   Baer       HBAER    ...
105   David     Austin     DAUSTIN  ...
130   Mozhe     Atkinson   MATKINSO ...
166   Sundar    Ande       SANDE    ...
174   Ellen     Abel       EABEL    ...

149   Eleni     Zlotkey    EZLOTKEY  ...
200   Jennifer  Whalen     JWHALEN   ...
.
.
.
137   Renske    Ladwig     RLADWIG  ...
173   Sundita   Kumar      SKUMAR   ...
101   Neena     Kochar     NKOCHHAR ...

行は姓(太字の部分)の順序に従ってブロックに格納されています。たとえば、データ・ブロック1は、最後の行から先頭に向ってAbel、Andeと続き、先頭のSteven Kingまでアルファベット順に並んでいます。データ・ブロック2は、最後の行から先頭に向ってKochar、Kumarと続き、先頭のZlotkeyまでアルファベット順に並んでいます。

姓の列に索引が付けられているとします。それぞれの名前エントリが、ROWIDに相当します。索引エントリは概念的には次のようになります。

Abel,block1row1
Ande,block1row2
Atkinson,block1row3
Austin,block1row4
Baer,block1row5
.
.
.

社員IDの列に別の索引が付けられているとします。索引エントリは概念的には次のようになり、社員IDは、2つのブロック全体にわたり、ほぼランダムな場所に分散しています。

100,block1row50
101,block2row1
102,block1row9
103,block2row19
104,block2row39
105,block1row4
.
.
.

表3-2では、この2つの索引のクラスタ化係数を求めるために、ALL_INDEXESビューを問い合せています。EMP_NAME_IXのクラスタ化係数は低く、同じリーフ・ブロック内の隣接する索引エントリは、同じデータ・ブロック内の行を指す傾向があります。EMP_EMP_ID_PKのクラスタ化係数は高く、同じリーフ・ブロック内の隣接する索引エントリが、同じデータ・ブロック内の行を指すことはほとんどありません。

例3-2 クラスタ化係数

SQL> SELECT INDEX_NAME, CLUSTERING_FACTOR
2  FROM ALL_INDEXES
3  WHERE INDEX_NAME IN ('EMP_NAME_IX','EMP_EMP_ID_PK');

INDEX_NAME           CLUSTERING_FACTOR
-------------------- -----------------
EMP_EMP_ID_PK                       19
EMP_NAME_IX                          2

関連項目:
ALL_INDEXESの詳細は、『Oracle Databaseリファレンス』を参照してください。

逆キー索引

逆キー索引はBツリー索引の一種であり、列の順序は保ちながら、各索引キーのバイトを物理的に逆にします。たとえば、索引キーが20であり、このキーに対して標準Bツリー索引で格納される16進数の2バイトがC1,15である場合、逆キー索引では、バイトが15,C1として格納されます。

キーを逆にすると、Bツリー索引の右側にあるリーフ・ブロックの競合の問題が解決されます。この問題は、複数のインスタンスが同じブロックを繰り返し変更するOracle Real Application Clusters(Oracle RAC)データベースで特に深刻です。たとえば、orders表では、オーダーの主キーは順次キーです。クラスタ内の1つのインスタンスが注文20を追加し、別のインスタンスがオーダー21を追加し、各インスタンスが索引の右側にある同じリーフ・ブロックにキーを書き込みます。

逆キー索引では、バイト順を逆にすることにより、挿入が索引のすべてのリーフ・キー全体に分散されます。たとえば、標準キー索引では隣接する20や21などのキーは、離れた別々のブロックに格納されます。したがって、順次キーの挿入のためのI/Oは、より等分に分散されます。

索引のデータは格納されるときに列キーでソートされないため、逆キー配列を使用すると、場合によっては索引レンジ・スキャン問合せを実行できなくなります。たとえば、20より大きいオーダーIDを求める問合せを発行した場合、データベースではこのIDを含むブロックから開始できず、リーフ・ブロックが水平に処理されます。

関連項目:
逆キー索引の設計の考慮事項は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

昇順索引と降順索引

昇順索引では、Oracle Databaseのデータは昇順に格納されます。デフォルトでは、文字データは値の各バイトに含まれるバイナリ値に従って順序付けられ、数値データは最小の数から最大の数へ、日付は古い値から新しい値への順になります。

昇順索引の例として、次のSQL文を考えてみます。

CREATE INDEX emp_deptid_ix ON hr.employees(department_id);

Oracle Databaseでは、hr.employees表をdepartment_id列でソートします。department_idおよび対応するROWID値を、0から始まる昇順で昇順索引にロードします。索引を使用するとき、Oracle Databaseでは、ソートしたdepartment_id値が検索され、関連付けられたROWIDを使用して要求されたdepartment_id値を持つ行が検索されます。

CREATE INDEX文にDESCキーワードを指定すると、降順索引を作成できます。この場合、索引は指定された列(1つまたは複数)にデータを降順に格納します。図3-1のemployees.department_id列の索引が降順である場合、250を含むリーフ・ブロックがツリーの左側となり、0のブロックが右側になります。降順索引でのデフォルトの検索は、最大値から最小値への順です。

降順索引は、問合せで一部の列を昇順、他の列を降順でソートする場合に有効です。たとえば、last_name列およびdepartment_id列に対して、次のようにコンポジット索引を作成したとします。

CREATE INDEX emp_name_dpt_ix ON hr.employees(last_name ASC, department_id DESC);

ユーザーがhr.employeesに対して、昇順(AからZへ)の姓と降順(大きいIDから小さいIDへ)の部門IDを問い合せる場合、データベースではこの索引を使用してデータを検索するため、データをソートする余分な手順が不要になります。

関連項目:

- 昇順および降順の索引検索の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- CREATE INDEXのASCおよびDESCオプションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

キー圧縮

Oracle Databaseでは、キー圧縮を使用して、Bツリー索引または索引構成表の主キー列値の一部を圧縮できます。キー圧縮によって、索引に使用される領域が大幅に減少します。

通常、索引キーには、グループ化要素と一意要素という2つの要素があります。キー圧縮では、索引キーを、グループ化要素である接頭辞エントリと、一意要素またはほぼ一意要素である接尾辞エントリに分割します。データベースでは、圧縮するために、接頭辞エントリが索引ブロック内の接尾辞エントリ間で共有されます。

注意:
一意要素を持つようにキーを定義しなければ、データベースによってグループ化要素にROWIDが追加され、一意要素が提供されます。

デフォルトでは、一意索引の接頭辞は最後のキー列を除くすべてのキー列で構成され、非一意索引の接頭辞はすべてのキー列で構成されます。たとえば、oe.orders表に次のようなコンポジット索引を作成したとします。

CREATE INDEX orders_mod_stat_ix ON orders ( order_mode, order_status );

order_mode列およびorder_status列で多数の繰返し値が発生します。索引ブロックに、例3-3に示すエントリがあるとします。

例3-3 Orders表の索引エントリ

online,0,AAAPvCAAFAAAAFaAAa
online,0,AAAPvCAAFAAAAFaAAg
online,0,AAAPvCAAFAAAAFaAAl
online,2,AAAPvCAAFAAAAFaAAm
online,3,AAAPvCAAFAAAAFaAAq
online,3,AAAPvCAAFAAAAFaAAt

例3-3では、キー接頭辞は、order_modeとorder_statusの値を連結した値で構成されます。この索引がデフォルトのキー圧縮によって作成された場合、online,0やonline,2のような重複するキー接頭辞が圧縮されます。その結果、データベースでは次の例に示すように圧縮されます。

online,0
AAAPvCAAFAAAAFaAAa
AAAPvCAAFAAAAFaAAg
AAAPvCAAFAAAAFaAAl
online,2
AAAPvCAAFAAAAFaAAm
online,3
AAAPvCAAFAAAAFaAAq
AAAPvCAAFAAAAFaAAt

接尾辞エントリは、索引行の圧縮版を形成します。各接尾辞エントリは、同じ索引ブロックに格納されている接頭辞エントリを参照します。

別の方法として、圧縮型索引を作成するときに接頭辞の長さを指定できます。たとえば、接頭辞の長さを1と指定した場合、接頭辞はorder_modeとなり、接尾辞はorder_status,rowidとなります。例3-3の値の場合、索引では重複するonlineが次のように除外されます。

online
0,AAAPvCAAFAAAAFaAAa
0,AAAPvCAAFAAAAFaAAg
0,AAAPvCAAFAAAAFaAAl
2,AAAPvCAAFAAAAFaAAm
3,AAAPvCAAFAAAAFaAAq
3,AAAPvCAAFAAAAFaAAt

索引では、特定の接頭辞がリーフ・ブロックごとに1回のみ格納されます。圧縮されるのは、Bツリー索引のリーフ・ブロックのキーのみです。ブランチ・ブロックの場合、キーの接尾辞は切り捨てることができますが、キーは圧縮されません。

関連項目:

- 圧縮型索引の使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- パーティション索引でキー圧縮を使用する方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- CREATE INDEXのkey_compression句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ビットマップ索引

ビットマップ索引では、各索引キーのビットマップがデータベースに格納されます。従来型のBツリー索引では、1つの索引エントリは単一の行を指します。ビットマップ索引では、各索引キーに複数の行へのポインタが格納されます。

ビットマップ索引は、主にデータ・ウェアハウス用または問合せが多数の列を非定型方式で参照する環境用に設計されています。 ビットマップ索引が適している状況として、次のような状況があります。

- 索引付けされた列は、カーディナリティが低く、表の行数に比べて個別値の数が少なくなります。

- 索引付けされた表は、読取り専用であるか、DML文による重要な変更の対象外です。

データ・ウェアハウスの例として、sh.customer表にcust_gender列があるとすると、この列に指定される値は、MとFの2つのみです。特定の性別の顧客の数に対する問合せが一般的だとします。このような場合、customer.cust_gender列はビットマップ索引の候補になります。

ビットマップの各ビットは、存在するROWIDに対応します。ビットが設定されている場合は、対応するROWIDを持つ行にはキー値が含まれます。マッピング機能がビット位置を実際のROWIDに変換するため、別の内部表現が使用されていても、ビットマップ索引はBツリー索引と同じ機能を提供します。

単一の行の索引付けされた列が更新された場合、データベースによって、更新された行にマッピングされた個別のビットではなく索引キー・エントリ(たとえば、MまたはF)がロックされます。キーは多数の行を指すため、索引付きデータに対するDMLは、通常、これらの行をすべてロックします。このため、ビットマップ索引は多くのOLTPアプリケーションに適していません。

関連項目:

- パフォーマンスのためにビットマップ索引を使用する方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- データ・ウェアハウスでビットマップ索引を使用する方法の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

単一表でのビットマップ索引

例3-4に、sh.customers表の問合せを示します。この表の一部の列はビットマップ索引の候補です。

例3-4 customers表の問合せ

SQL> SELECT cust_id, cust_last_name, cust_marital_status, cust_gender
2  FROM   sh.customers
3  WHERE  ROWNUM < 8 ORDER BY cust_id;

CUST_ID CUST_LAST_ CUST_MAR C
---------- ---------- -------- -
1 Kessel              M
2 Koch                F
3 Emmerson            M
4 Hardy               M
5 Gowen               M
6 Charles    single   F
7 Ingram     single   F

7 rows selected.

cust_marital_statusおよびcust_gender列のカーディナリティは低く、cust_idおよびcust_last_nameのカーディナリティは低くありません。このため、ビットマップ索引はcust_marital_statusおよびcust_genderに適切といえます。その他の列には、ビットマップ索引は効果がありません。この場合は、一意のBツリー索引を使用する方が、表示と検索が効率的になります。

表3-2に、例3-4に示したcust_gender列の出力に対するビットマップ索引を示します。これは、各性別に対応する2つのビットマップからなります。

表3-2 サンプル・ビットマップ

値

行1

行2

行3

行4

行5

行6

行7

M

1

0

1

1

1

0

0

F

0

1

0

0

0

1

1

マッピング関数はビットマップの各ビットをcustomers表のROWIDに変換します。各ビットの値は、表内の対応する行の値に依存しています。たとえば、customers表の最初の行で性別がMであるため、M値のビットマップには、最初のビットとして1が含まれます。ビットマップcust_gender='M'の行2、6、および7のビットは、これらの行が値としてMを含まないため、0になります。

注意:
Bツリー索引とは異なり、ビットマップ索引は、完全にNULL値からなるキーを含む場合があります。NULLの索引作成は、集計関数COUNTによる問合せなど、一部のSQL文に使用できます。

顧客の人口統計を調べているアナリストが、女性顧客のうち独身者または離婚者はどれくらいいるかを尋ねてきたとします。この質問は、次のSQL問合せで表現できます。

SELECT COUNT(*)
FROM   customers
WHERE  cust_gender = 'F'
AND    cust_marital_status IN ('single', 'divorced');

ビットマップ索引を使用すると、表3-3に示すように、結果のビットマップから1の値の数を数え、この問合せを効率よく処理できます。基準に該当する顧客を識別するときは、Oracle Databaseでは結果のビットマップを使用して表にアクセスできます。

表3-3 サンプル・ビットマップ

値

行1

行2

行3

行4

行5

行6

行7

M

1

0

1

1

1

0

0

F

0

1

0

0

0

1

1

single

0

0

0

0

0

1

1

divorced

0

0

0

0

0

0

0

singleまたはdivorced、およびF

0

0

0

0

0

1

1

ビットマップ索引は、WHERE句に指定されたいくつかの条件に対応する索引を効率的にマージします。すべての条件ではなく一部の条件のみを満たす行は、表自体がアクセスされる前に除外されます。これによってレスポンス時間が短縮されます(多くの場合は大幅に改善されます)。

ビットマップ結合索引

ビットマップ結合索引は、2つ以上の表を結合するためのビットマップ索引です。索引は、表列の値ごとに、対応する行のROWIDを索引付きの表に格納します。対照的に、標準ビットマップ索引は単一表に対して作成されます。

ビットマップ結合索引は、制限を事前に実行するため、結合するデータのボリュームを削減する効率的な方法です。ビットマップ結合索引が役に立つ場合の例として、ユーザーが特定の職種の従業員数を頻繁に問い合せるとします。一般的な問合せは次のようになります。

SELECT COUNT(*)
FROM   employees, jobs
WHERE  employees.job_id = jobs.job_id
AND    jobs.job_title = 'Accountant';

この問合せでは、通常、jobs.job_titleの索引を使用してAccountantの行を検索し、次にjob_idの行を検索し、employees.job_idの索引を使用して一致する行を検索します。表のスキャンではなく索引自体からデータを取り出すには、次のようにビットマップ結合索引を作成できます。

CREATE BITMAP INDEX employees_bm_idx
ON     employees (jobs.job_title)
FROM   employees, jobs
WHERE  employees.job_id = jobs.job_id;

図3-2に示すように、索引キーはjobs.job_titleであり、索引付きの表はemployeesです。

図3-2 ビットマップ結合索引

概念的には、例3-5(サンプル出力を示しています)に示すSQL問合せのjobs.title列の索引はemployees_bm_idxです。索引のjob_titleキーは、employees表の行を指します。経理担当者の数を求める問合せでは、索引を使用すると、索引自体に要求された情報が含まれるため、employeesおよびjobs表へのアクセスを回避できます。

例3-5 employees表とjobs表の結合

SELECT jobs.job_title AS "jobs.job_title", employees.rowid AS "employees.rowid"
FROM   employees, jobs
WHERE  employees.job_id = jobs.job_id
ORDER BY job_title;

jobs.job_title                      employees.rowid
----------------------------------- ------------------
Accountant                          AAAQNKAAFAAAABSAAL
Accountant                          AAAQNKAAFAAAABSAAN
Accountant                          AAAQNKAAFAAAABSAAM
Accountant                          AAAQNKAAFAAAABSAAJ
Accountant                          AAAQNKAAFAAAABSAAK
Accounting Manager                  AAAQNKAAFAAAABTAAH
Administration Assistant            AAAQNKAAFAAAABTAAC
Administration Vice President       AAAQNKAAFAAAABSAAC
Administration Vice President       AAAQNKAAFAAAABSAAB
.
.
.

データ・ウェアハウスでは、結合条件は、ディメンション表の主キー列とファクト表の外部キー列の間の等価結合(等価演算子を使用する)になります。ビットマップ結合索引は、格納に関して、事前に結合をマテリアライズするマテリアライズド結合ビューよりもはるかに効率的な場合があります。

関連項目:
ビットマップ結合索引の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

ビットマップ記憶域構造

Oracle Databaseでは、Bツリー索引構造を使用して各索引付きキーのビットマップを格納します。たとえば、jobs.job_titleがビットマップ索引のキー列である場合、索引データは1つのBツリーに格納されます。個々のビットマップはリーフ・ブロックに格納されます。

jobs.job_title列に一意の値であるShipping Clerk、Stock Clerk、およびその他いくつかの値があるとします。この索引のビットマップ索引エントリには、次のコンポーネントがあります。

- 索引キーとしての職種

- ROWIDの範囲として小さいROWIDと大きいROWID

- 範囲内の特定のROWIDのビットマップ

その結果、この索引の索引リーフ・ブロックには次のようなエントリが含まれる場合があります。

Shipping Clerk,AAAPzRAAFAAAABSABQ,AAAPzRAAFAAAABSABZ,0010000100
Shipping Clerk,AAAPzRAAFAAAABSABa,AAAPzRAAFAAAABSABh,010010
Stock Clerk,AAAPzRAAFAAAABSAAa,AAAPzRAAFAAAABSAAc,1001001100
Stock Clerk,AAAPzRAAFAAAABSAAd,AAAPzRAAFAAAABSAAt,0101001001
Stock Clerk,AAAPzRAAFAAAABSAAu,AAAPzRAAFAAAABSABz,100001
.
.
.

ROWID範囲が異なるため、同じ職種が複数エントリに出現します。

セッションで、1人の従業員のジョブIDをShipping ClerkからStock Clerkに更新するとします。このような場合、セッションは古い値(Shipping Clerk)と新しい値(Stock Clerk)の索引キー・エントリに排他的にアクセスする必要があります。Oracle Databaseでは、UPDATEがコミットされるまで、これら2つのエントリで指し示された行がロックされます(ただし、Accountantまたはその他のキーで指し示された行はロックされません)。

ビットマップ索引のデータは1つのセグメントに格納されます。Oracle Databaseでは、各ビットマップを1つ以上の断片に格納します。各断片は単一データ・ブロックの一部を占めます。

関連項目:
「ユーザー・セグメント」

ファンクション索引

表に索引を設定する場合、その表の1つ以上の列を含むファンクションと式について、索引を作成できます。ファンクション索引では、1つ以上の列を含むファンクションや式の値が計算され、索引に格納されます。ファンクション索引はBツリー索引またはビットマップ索引のいずれかです。

索引作成に使用するファンクションには、算術式あるいはSQL関数、ユーザー定義のPL/SQLファンクション、パッケージ・ファンクション、またはCコールアウトを含む式を使用できます。たとえば、ファンクションでは2つの列の値を加算できます。

関連項目:

- ファンクション索引の作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- ファンクション索引の使用方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- ファンクション索引の制約および使用上の注意は、『Oracle Database SQL言語リファレンス』を参照してください。

ファンクション索引の使用方法

ファンクション索引は、WHERE句にファンクションを含む文を効率的に評価します。データベースでは、ファンクションが問合せに含まれている場合にのみ、ファンクション索引を使用します。ただし、INSERT文とUPDATE文の処理中には、データベースでは文を処理するために従来どおりファンクションを評価する必要があります。

たとえば、次のようなファンクション索引を作成したとします。

CREATE INDEX emp_total_sal_idx
ON employees (12 * salary * commission_pct, salary, commission_pct);

データベースでは、例3-6(部分的なサンプル出力を示しています)に示すような問合せを処理するときに、この索引を使用できます。

例3-6 算術式を含む問合せ

SELECT   employee_id, last_name, first_name,
12*salary*commission_pct AS "ANNUAL SAL"
FROM     employees
WHERE    (12 * salary * commission_pct) < 30000
ORDER BY "ANNUAL SAL" DESC;

EMPLOYEE_ID LAST_NAME                 FIRST_NAME           ANNUAL SAL
----------- ------------------------- -------------------- ----------
159 Smith                     Lindsey                   28800
151 Bernstein                 David                     28500
152 Hall                      Peter                     27000
160 Doran                     Louise                    27000
175 Hutton                    Alyssa                    26400
149 Zlotkey                   Eleni                     25200
169 Bloom                     Harrison                  24000

SQLファンクションUPPER(column_name)またはLOWER(column_name)でファンクション索引を定義すると、大文字/小文字を区別しない検索が容易になります。たとえば、employeesのfirst_name列に大文字/小文字が含まれるとします。hr.employees表に次のようなファンクション索引を作成します。

CREATE INDEX emp_fname_uppercase_idx
ON employees ( UPPER(first_name) );

emp_fname_uppercase_idx索引によって、次のような問合せが容易になります。

SELECT *
FROM   employees
WHERE  UPPER(first_name) = 'AUDREY';

ファンクション索引は、表の特定の行のみに索引を付ける場合にも役に立ちます。たとえば、sh.customers表のcust_valid列には、値としてIまたはAがあるとします。Aの行のみに索引を付けるには、A以外のすべての行に対してNULL値を戻すファンクションを作成できます。次のような索引を作成できます。

CREATE INDEX cust_valid_idx
ON customers ( CASE cust_valid WHEN 'A' THEN 'A' END );

関連項目:

- 言語索引の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

- SQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ファンクション索引による最適化

オプティマイザでは、WHERE句の式による問合せに、ファンクション索引に対する索引レンジ・スキャンを使用できます。レンジ・スキャンのアクセス・パスは、述語(WHERE句)の選択性が低い場合に特に便利です。例3-6では、式12*salary*commission_pctの索引が作成されていれば、オプティマイザは索引レンジ・スキャンを使用できます。

仮想列は、式から導出されるデータへのアクセスを高速化するために役立ちます。たとえば、仮想列annual_salを12*salary*commission_pctとして定義し、annual_salにファンクション索引を作成できます。

オプティマイザは、SQL文の式を解析し、文の式ツリーとファンクション索引を比較して、式のマッチングを実行します。この比較は大文字/小文字が区別され、ブランクは無視されます。

関連項目:

- 「オプティマイザの概要」

- 統計収集の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- 表への仮想列の追加方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

アプリケーション・ドメイン索引

アプリケーション・ドメイン索引は、アプリケーション固有のカスタマイズされた索引です。Oracle Databaseでは、次の操作を行うために拡張索引作成機能を提供しています。

- カスタマイズされた複合データ型(文書、空間データ、イメージ、ビデオ・クリップなど)の索引への対応(「非構造化データ」を参照)

- 特殊な索引作成方法の利用

アプリケーション固有の索引管理ルーチンを索引タイプ・スキーマ・オブジェクトとしてカプセル化し、オブジェクト型の表の列や属性のドメイン索引を定義できます。拡張索引作成機能により、アプリケーション固有の演算子を効率的に処理できます。

ドメイン索引の構造と内容は、カートリッジと呼ばれるアプリケーション・ソフトウェアによって制御されます。データベースは、ドメイン索引の作成、メンテナンス、および検索のために、このアプリケーションと対話します。索引構造そのものは、索引構成表としてデータベースに格納するか、ファイルとして外部に格納できます。

関連項目:
Oracle Databaseの拡張性アーキテクチャ内のデータ・カートリッジの使用方法の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。

索引記憶域

Oracle Databaseでは、索引データは索引セグメントに格納されます。データ・ブロックで索引データのために使用できる領域は、データ・ブロック・サイズから、ブロック・オーバーヘッド、エントリ・オーバーヘッド、ROWID、および索引が作成される値1つ当たり1バイトの合計を引いたものです。

索引セグメントの表領域は、所有者のデフォルト表領域またはCREATE INDEX文で明示的に指定された表領域です。管理を容易にするために、索引をその表とは別の表領域に格納できます。たとえば、索引のみを含む表領域は再構築できるため、これらの表領域をバックアップしないよう指定することによって、バックアップに必要な時間と記憶域を削減できます。

関連項目:
第12章「論理記憶域構造」

索引構成表の概要

索引構成表は、一種のBツリー索引構造に格納される表です。ヒープ構成表では、行は収まる位置に挿入されます。索引構成表では、行は表の主キーに定義された索引に格納されます。Bツリーの各索引エントリには、非キー列値も格納されます。したがって、索引はデータであり、データは索引です。アプリケーションは、ヒープ構成表と同じように、SQL文を使用して索引構成表を操作します。

たとえば、索引構成表について、人事管理マネージャが複数の段ボール箱を棚に置いて管理しているとします。それぞれの箱には1、2、3、4というように番号のラベルが付いていますが、箱は棚の中で順番に並んではいません。それぞれの箱には、次の箱が棚のどの位置にあるかを示すポインタがあります。

それぞれの箱には従業員レコードが入っているフォルダが収納されています。フォルダは従業員IDによってソートされています。従業員KingのIDは100で、それが最小のIDであるため、Kingのフォルダは箱1の一番下にあります。従業員101のフォルダは100の上、102は101の上というように、箱1がいっぱいになるまでフォルダが収められています。この並びにおける次のフォルダは、箱2の一番下になります。

この例の場合、フォルダを従業員IDで並べると、専用の索引をメンテナンスすることなく、フォルダを効率的に検索できます。ユーザーが従業員107、120、および122のレコードを要求していると想定します。1つの手順で索引を検索し、別の手順でフォルダを取り出すかわりに、マネージャは、フォルダを順番に検索し、個々のフォルダを見つかり次第取り出すことができます。

索引構成表は、主キーまたはそのキーの有効な接頭辞の使用により、表の行に対するアクセスを高速化します。リーフ・ブロックの行に非キー列が存在することにより、追加のデータ・ブロックI/Oが回避されます。たとえば、従業員100の給与は索引行自体に格納されます。さらに、行が主キーの順序で格納されるため、主キーまたは接頭辞によるレンジ・アクセスでは最小限のブロックI/Oが行われます。もう1つの利点は、個別の主キー索引の空間オーバーヘッドが回避されることです。

索引構成表は、関連したデータ断片をまとめて格納する必要がある場合や、データを特定の順序で物理的に格納する必要がある場合に役立ちます。このタイプの表は、情報検索、空間(「Oracle Spatialの概要」を参照)、およびOLAPアプリケーション(「OLAP」を参照)によく使用されます。

関連項目:

- 索引構成表の管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 索引構成表を使用してパフォーマンスを向上させる方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- CREATE TABLE ... ORGANIZATION INDEXの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

索引構成表の特性

データベース・システムは、Bツリー索引構造を操作することで、索引構成表に対するすべての操作を実行します。表3-4に、索引構成表とヒープ構成表の違いをまとめます。

表3-4 ヒープ構成表と索引構成表の比較

ヒープ構成表

索引構成表

ROWIDが行を一意に識別します。主キー制約はオプションで定義できます。

主キーが行を一意に識別します。主キー制約を定義する必要があります。

ROWID擬似列の物理ROWIDで2次索引を作成できます。

ROWID疑似列の論理ROWIDで2次索引を作成できます。

ROWIDによって個々の行に直接アクセスできます。

個々の行には、主キーによって間接的にアクセスします。

順次全表スキャンは、特定の順序ですべての行を戻します。

全索引スキャンまたは高速全索引スキャンは、特定の順序ですべての行を戻します。

他の表とともに表クラスタに格納できます。

表クラスタには格納できません。

LONGデータ型の列とLOBデータ型の列を格納できます。

LOB列は格納できますが、LONG列は格納できません。

仮想列を格納できます(サポートされているのはリレーショナル・ヒープ表のみです)。

仮想列は格納できません。

図3-3に、索引構成表departmentsの構造を示します。リーフ・ブロックには表の行が主キーの順序に従って格納されています。たとえば、最初のリーフ・ブロックの最初の値は、部門ID 20、部門名Marketing、マネージャID 201、および場所ID 1800を示しています。

図3-3 索引構成表

索引構成表では、すべてのデータが同じ構造に格納され、ROWIDを格納する必要がありません。図3-3に示すように、索引構成表のリーフ・ブロック1には、主キーの順序に従った次のようなエントリが含まれます。

20,Marketing,201,1800
30,Purchasing,114,1700

索引構成表のリーフ・ブロック2には次のようなエントリが含まれます。

50,Shipping,121,1500
60,IT,103,1400

主キーの順序になっている索引構成表の行をスキャンすると、ブロックが次の順序で読み取られます。

1. ブロック1

2. ブロック2

ヒープ構成表でのデータ・アクセスを索引構成表でのデータ・アクセスと比較するため、ヒープ構成表departmentsのセグメントのブロック1に、次のように行が格納されているとします。

50,Shipping,121,1500
20,Marketing,201,1800

ブロック2には同じ表の行が次のように格納されています。

30,Purchasing,114,1700
60,IT,103,1400

このヒープ構成表のBツリー索引リーフ・ブロックには、次のエントリが格納されています。最初の値は主キーであり、2つ目の値はROWIDです。

20,AAAPeXAAFAAAAAyAAD
30,AAAPeXAAFAAAAAyAAA
50,AAAPeXAAFAAAAAyAAC
60,AAAPeXAAFAAAAAyAAB

主キーの順序になっている表の行をスキャンすると、表セグメント・ブロックが次の順序で読み取られます。

1. ブロック1

2. ブロック2

3. ブロック1

4. ブロック2

したがって、この例のブロックI/Oの数は、索引構成の例での数の倍になります。

関連項目:

- 「表の編成」

- 「論理記憶域構造の概要」

行オーバーフロー領域付きの索引構成表

索引構成表を作成するとき、別のセグメントを行オーバーフロー領域として指定できます。索引構成表では、行全体を格納しているBツリー索引エントリは大きくなる場合があり、エントリを格納する別のセグメントが役立ちます。これに対し、Bツリー・エントリはキーとROWIDで構成されるため、通常は小さくなります。

行オーバーフロー領域を指定した場合、データベースでは索引構成表の行を次の部分に分割できます。

- 索引エントリ
この部分には、主キー列すべての列値、行のオーバーフロー部分を指す物理ROWID、およびオプションで一部の非キー列が含まれます。この部分は索引セグメントに格納されます。

- オーバーフロー部分
この部分には、残りの非キー列の列値が含まれます。この部分はオーバーフロー記憶域セグメントに格納されます。

関連項目:

- CREATE TABLEのOVERFLOW句を使用して行オーバーフロー領域を設定する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE TABLE ... OVERFLOWの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

索引構成表の2次索引

2次索引は、索引構成表の索引です。ある意味では、これは索引の索引です。2次索引は独立したスキーマ・オブジェクトであり、索引構成表とは別に格納されます。

「ROWIDデータ型」で説明しているように、Oracle Databaseでは、索引構成表に対して論理ROWIDと呼ばれる行識別子を使用します。論理ROWIDは、表の主キーをbase64でエンコードした表現です。論理ROWIDの長さは、主キーの長さに応じて異なります。

索引リーフ・ブロック内の行は、挿入によってブロック内またはブロック間で移動できます。ヒープ構成の行とは異なり、索引構成表の行は移行されません(「行の連鎖と移行」を参照)。索引構成表の行には永続的な物理アドレスがないため、データベースでは主キーに基づいて論理ROWIDを使用します。

たとえば、departments表が索引構成表であるとします。location_id列には各部門のIDが格納されます。表には次のように行が格納され、最後の値が場所IDになります。

10,Administration,200,1700
20,Marketing,201,1800
30,Purchasing,114,1700
40,Human Resources,203,2400

location_id列の2次索引には、次のような索引エントリが含まれる場合があります。カンマに続く値が論理ROWIDです。

1700,*BAFAJqoCwR/+
1700,*BAFAJqoCwQv+
1800,*BAFAJqoCwRX+
2400,*BAFAJqoCwSn+

2次索引は、主キーでも主キーの接頭辞でもない列を使用して、索引構成表への高速で効率的なアクセスを可能にします。たとえば、IDが1700より大きい部門名の問合せでは、2次索引を使用してデータ・アクセスを高速化できます。

関連項目:

- 索引構成表に2次索引を作成する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 索引構成表パーティションに2次索引を作成する方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

論理ROWIDと物理推測

2次索引では論理ROWIDを使用して表の行を検索します。論理ROWIDには、索引エントリの最初の作成時の物理ROWIDである物理推測が含まれます。Oracle Databaseは、物理推測を使用して、主キー検索をバイパスし、索引構成表のリーフ・ブロックを直接検証できます。行の物理位置が変化した場合、論理ROWIDは失効した物理推測が含まれていても引き続き有効です。

ヒープ構成表の場合、2次索引によるアクセスでは、行を含むデータ・ブロックをフェッチするために、2次索引のスキャンと付加的なI/Oが必要になります。索引構成表の場合、2次索引によるアクセスは、次のように物理推測を使用するかどうかと、その正確さに応じて異なります。

- 物理推測を使用しない場合、アクセスでは2次索引のスキャンとその後に主キー索引のスキャンという、2つの索引スキャンが行われます。

- 物理推測を使用する場合は、アクセスは物理推測の正確さに応じて異なります。

- 正確な物理推測を使用する場合、アクセス時には、2次索引スキャンと追加のI/Oによって行を含むデータ・ブロックがフェッチされます。

- 不正確な物理推測を使用する場合、アクセス時には2次索引スキャンとI/Oによって間違ったデータ・ブロック(物理推測が示すブロック)がフェッチされてから、主キー値による索引構成表の索引一意スキャンが実行されます。

索引構成表のビットマップ索引

索引構成表の2次索引は、ビットマップ索引にできます。「ビットマップ索引」で説明しているように、ビットマップ索引には各索引キーのビットマップが格納されます。

索引構成表にビットマップ索引が存在する場合、すべてのビットマップ索引はヒープ構成のマッピング表を使用します。マッピング表には索引構成表の論理ROWIDが格納されます。マッピング表の各行には対応する索引構成表の行の論理ROWIDが格納されます。

データベースでは、検索キーを使用してビットマップ索引にアクセスします。キーが見つかると、ビットマップのエントリは物理ROWIDに変換されます。ヒープ構成表の場合、この物理ROWIDは実表へのアクセスに使用されます。索引構成表の場合、この物理ROWIDはマッピング表へのアクセスに使用され、それにより、索引構成表へのアクセスに使用される論理ROWIDが取得されます。図3-4に、departments_iot表の問合せ用の索引アクセスを示します。

図3-4 索引構成表に対するビットマップ索引

注意:
索引構成表で行を移動すると、その索引構成表に作成されたビットマップ索引の使用禁止状態が変化します。

関連項目:
「行断片のROWID」

4 パーティション、ビューおよびその他のスキーマ・オブジェクト

最も重要かつ一般的に使用されるスキーマ・オブジェクトは表と索引ですが、データベースでは他のタイプの多数のスキーマ・オブジェクトもサポートされています。この章では、最も一般的なスキーマ・オブジェクトについて説明します。

この章の内容は、次のとおりです。

- パーティションの概要

- ビューの概要

- マテリアライズド・ビューの概要

- 順序の概要

- ディメンションの概要

- シノニムの概要

パーティションの概要

パーティション化により、大規模な表や索引をパーティションという、より小さく管理しやすい部分に分割できます。各パーティションは独自の名前を持つ独立したオブジェクトであり、独自の記憶特性を持つ場合があります。

パーティション化の例として、ある人事管理マネージャが複数の従業員フォルダを含む1つの大きな箱を管理しているとします。各フォルダは従業員の雇用日を示しています。特定の月に雇用された従業員に対する問合せが頻繁に行われます。このような要求を満たす1つのアプローチとして、箱の中に分散しているフォルダの位置を特定する索引を、従業員の雇用日に対して作成する方法があります。一方、パーティション化計画ではより小さな箱を多数使用して、指定した月に雇用された従業員のフォルダをそれぞれの箱に格納します。

より小さな箱の使用には、いくつかの利点があります。6月に雇用された従業員のフォルダを取り出すよう依頼された場合、人事管理マネージャは6月の箱を取り出します。さらに、いずれかの小さな箱が破損したとしても、他の小さな箱は引き続き使用できます。また、マネージャは1つの重い箱を移動するのではなく、複数の小さな箱を移動すればよいため、オフィスの移転も容易になります。

アプリケーションから見ると、スキーマ・オブジェクトは1つのみ存在します。パーティション表にアクセスするためにDML文を修正する必要はありません。パーティション化は様々なタイプのデータベース・アプリケーションで有効ですが、特に大量のデータを管理するアプリケーションで便利です。次のような利点があります。

- 可用性の向上
いずれかのパーティションが使用できない場合も、オブジェクトの使用には関係ありません。問合せオプティマイザは参照されないパーティションを問合せ計画から自動的に削除するため、パーティションが使用できない場合にも、問合せは影響を受けません。

- スキーマ・オブジェクトの管理の簡素化
パーティション・オブジェクトには、集中管理および個別管理のいずれも可能な要素があります。DDL文では、表全体または索引ではなくパーティションを操作できます。このため、索引または表の再作成など、リソース集中型のタスクを細分化できます。たとえば、一度に1つずつ表のパーティションを移動できます。問題が発生した場合は、表の移動ではなく、パーティションの移動のみを再実行します。また、パーティションを削除すると、DELETE文を多数実行する必要がなくなります。

- OLTPシステムの共有リソースの競合の軽減
一部のOLTPシステムでは、パーティションによって共有リソースの競合を軽減できます。たとえば、DMLを1つのセグメントではなく、多数のセグメントに分散します。

- データ・ウェアハウスでの問合せパフォーマンスの向上
データ・ウェアハウスでは、パーティションによって非定型問合せの処理を高速化できます。たとえば、100万行ある売上表を四半期ごとにパーティション化できます。

関連項目:
パーティション化の概要は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

パーティションの特性

表や索引の各パーティションは、列名、データ型、制約などの論理属性が同じである必要があります。たとえば、表内のすべてのパーティションが同じ列と制約の定義を共有し、索引内のすべてのパーティションが索引付けされた同じ列を共有します。ただし、パーティションが属する表スペースなど、各パーティションの物理属性は異なる場合があります。

パーティション・キー

パーティション・キーは、パーティション表の各行が属するパーティションを決定する1つ以上の列のセットです。各行は、単一パーティションに明示的に割り当てられます。

たとえば、sales表で、レンジ・パーティションのキーとしてtime_id列を指定できます。Oracle Databaseにより、この列の日付が指定された範囲内にあるかどうかに基づいてパーティションに行が割り当てられます。Oracle Databaseでは、パーティション・キーを使用して適切なパーティションに対して挿入、更新および削除操作が自動的に行われます。

パーティション化計画

Oracle Partitioningは、データベースによる個々のパーティションへのデータの配置方法を制御する、複数のパーティション化計画を提供します。基本的な計画は、レンジ・パーティション化、リスト・パーティション化およびハッシュ・パーティション化です。

単一レベル・パーティション化計画では、リスト・パーティションのみまたはレンジ・パーティションのみなど、データ配分方法を1つのみ使用します。コンポジット・パーティション化では、1つのデータ配分方法で表をパーティション化し、別のデータ配分方法を使用して、各パーティションをさらに小さなサブパーティションに分割します。たとえば、channel_idにリスト・パーティションを使用し、time_idにレンジ・サブパーティションを使用できます。

レンジ・パーティション化

レンジ・パーティション化では、Oracle Databaseはパーティション化キーの値の範囲に基づいて、行をパーティションにマップします。レンジ・パーティション化は、最も一般的なタイプのパーティション化であり、通常は日付とともに使用されます。

例4-1に示されているsales行をパーティション表に移入するとします。

例4-1 パーティション表のサンプル行セット

PROD_ID    CUST_ID TIME_ID   CHANNEL_ID   PROMO_ID QUANTITY_SOLD AMOUNT_SOLD
---------- ---------- --------- ---------- ---------- ------------- -----------
116      11393 05-JUN-99          2        999             1       12.18
40     100530 30-NOV-98          9         33             1       44.99
118        133 06-JUN-01          2        999             1       17.12
133       9450 01-DEC-00          2        999             1       31.28
36       4523 27-JAN-99          3        999             1       53.89
125       9417 04-FEB-98          3        999             1       16.86
30        170 23-FEB-01          2        999             1         8.8
24      11899 26-JUN-99          4        999             1       43.04
35       2606 17-FEB-00          3        999             1       54.94
45       9491 28-AUG-98          4        350             1       47.45

例4-2に示されている文を使用して、パーティション表としてtime_range_salesを作成します。time_id列がパーティション・キーです。

例4-2 レンジ・パーティション化された表

CREATE TABLE time_range_sales
( prod_id        NUMBER(6)
, cust_id        NUMBER
, time_id        DATE
, channel_id     CHAR(1)
, promo_id       NUMBER(6)
, quantity_sold  NUMBER(3)
, amount_sold    NUMBER(10,2)
)
PARTITION BY RANGE (time_id)
(PARTITION SALES_1998 VALUES LESS THAN (TO_DATE('01-JAN-1999','DD-MON-YYYY')),
PARTITION SALES_1999 VALUES LESS THAN (TO_DATE('01-JAN-2000','DD-MON-YYYY')),
PARTITION SALES_2000 VALUES LESS THAN (TO_DATE('01-JAN-2001','DD-MON-YYYY')),
PARTITION SALES_2001 VALUES LESS THAN (MAXVALUE)
);

その後、例4-1の行をtime_range_salesにロードします。図4-1に、4つのパーティションへの行の配分を示します。Oracle Databaseでは、PARTITION BY RANGE句に指定されたルールに従って、time_id値に基づいて各行のパーティションが選択されます。

図4-1 レンジ・パーティション

レンジ・パーティション・キーの値は、遷移ポイントと呼ばれるレンジ・パーティションの値の上限を決定します。図4-1では、SALES_1998パーティションに、パーティション化キーtime_idの値が遷移ポイント01-JAN-1999より小さい行が含まれています。

データベースでは遷移ポイントを超えるデータに対して、時間隔パーティションを作成します。時間隔パーティション化は、表に挿入されたデータがすべてのレンジ・パーティションを超える場合に、指定された範囲または間隔のパーティションを自動的に作成するようデータベースに指示するレンジ・パーティション化の拡張機能です。図4-1では、SALES_2001パーティションに、パーティション化キーtime_idの値が遷移ポイント01-JAN-2001と等しいか、それより大きい行が含まれています。

リスト・パーティション化

リスト・パーティション化の場合、Oracle Databaseでは、各パーティションのパーティション・キーとして離散値のリストが使用されます。リスト・パーティション化を使用して、特定のパーティションに対する個々の行のマップ方法を制御できます。リストを使用すると、データの識別に使用されるキーの並び順が目的にそぐわない場合に、関連するデータのセットをグループ化して整理できます。

例4-3に示されている文を使用して、リスト・パーティション表としてlist_salesを作成するとします。channel_id列がパーティション・キーです。

例4-3 リスト・パーティション化された表

CREATE TABLE list_sales
( prod_id        NUMBER(6)
, cust_id        NUMBER
, time_id        DATE
, channel_id     CHAR(1)
, promo_id       NUMBER(6)
, quantity_sold  NUMBER(3)
, amount_sold    NUMBER(10,2)
)
PARTITION BY LIST (channel_id)
(PARTITION even_channels VALUES (2,4),
PARTITION odd_channels VALUES (3,9)
);

その後、例4-1の行を表にロードします。図4-2に、2つのパーティションへの行の配分を示します。データベースでは、PARTITION BY LIST句に指定されたルールに従って、channel_id値に基づいて各行のパーティションが選択されます。channel_idの値が2または4である行はEVEN_CHANNELSパーティションに格納され、channel_idの値が3または9である行はODD_CHANNELSパーティションに格納されます。

図4-2 リスト・パーティション

ハッシュ・パーティション化

ハッシュ・パーティション化では、データベースがユーザー指定のパーティション・キーに適用するハッシング・アルゴリズムに基づいて、行をパーティションにマップします。行のマップ先は、データベースが行に適用する内部ハッシュ関数によって決定されます。ハッシュ・アルゴリズムは、各パーティションにほぼ同じ行数が含まれるように、行を複数のデバイスに均等に分散させるように設計されています。

ハッシュ・パーティション化は、大きな表を分割して管理しやすくする場合に役立ちます。1つの大きな表ではなく、複数のより小さい単位を管理します。1つのハッシュ・パーティションが失われても、残りのパーティションに影響はなく、個別にリカバリできます。また、ハッシュ・パーティション化は、更新時に競合が発生しやすいOLTPシステムにも役立ちます。たとえば、競合が発生しやすい1つのセグメントを複数の単位に分割し、各単位が個別に更新されるようにできます。

例4-4に示されている文を使用して、パーティション化されたhash_sales表を作成するとします。prod_id列がパーティション・キーです。

例4-4 ハッシュ・パーティション化された表

CREATE TABLE hash_sales
( prod_id        NUMBER(6)
, cust_id        NUMBER
, time_id        DATE
, channel_id     CHAR(1)
, promo_id       NUMBER(6)
, quantity_sold  NUMBER(3)
, amount_sold    NUMBER(10,2)
)
PARTITION BY HASH (prod_id)
PARTITIONS 2;

その後、例4-1の行を表にロードします。図4-3に、2つのパーティションへの行の配分の例を示します。これらのパーティションの名前は、システムによって生成されます。

ユーザーが行を挿入すると、データベースではすべてのパーティションへのランダムかつ均等な行の配分が試行されます。行をどのパーティションに配置するかは指定できません。データベースはハッシュ関数を適用し、関数の出力結果に基づいて、どのパーティションに行を格納するかを決定します。パーティションの数を変更すると、データベースでは再度すべてのパーティションにデータが配分されます。

図4-3 ハッシュ・パーティション

関連項目:

- パーティションの作成方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- CREATE TABLE ... PARTITION BYの例については、『Oracle Database SQL言語リファレンス』を参照してください。

パーティション表

パーティション表は1つ以上のパーティションで構成されており、パーティションは個別に管理され、他のパーティションから独立して機能できます。表はパーティション化または非パーティション化のいずれかの状態です。パーティション表が1つのパーティションのみで構成されている場合も、この表は、パーティションを追加できない非パーティション表とは異なります。「パーティションの特性」に、パーティション表の例を示してあります。

パーティション表は、1つ以上の表パーティション・セグメントで構成されています。hash_productsという名前のパーティション表を作成した場合、この表に表セグメントは割り当てられません。かわりに、データベースでは独自のパーティション・セグメントに各表パーティションのデータを格納します。各表パーティション・セグメントには表データの断片が含まれます。

ヒープ構成表の一部またはすべてのパーティションは圧縮形式で格納できます。圧縮すると領域を節約でき、問合せの実行を高速化できます。このため、圧縮は挿入および更新操作の量が少ないデータ・ウェアハウスなどの環境およびOLTP環境で役立つ場合があります。

表圧縮の属性は、表領域、表または表パーティションについて宣言できます。表領域レベルで宣言した場合、その表領域に作成される表はデフォルトで圧縮されます。表の圧縮属性を変更すると、変更はその表に格納される新規データにのみ適用されます。このため、1つの表またはパーティションには圧縮ブロックと非圧縮ブロックの両方を含むことができ、これにより、圧縮によってデータ・サイズが大きくならないことが保証されます。圧縮によってブロック・サイズが大きくなる場合、そのブロックに圧縮は適用されません。

関連項目:

- 「表の圧縮」および「セグメントの概要」

- データ・ウェアハウスでの表の圧縮の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

パーティション索引

パーティション索引とは、パーティション表のように、より小さく管理しやすい単位に分割された索引です。グローバル索引は索引の作成対象の表から独立してパーティション化されますが、ローカル索引 は表のパーティション化方法に自動的にリンクされます。パーティション表と同様、パーティション索引も管理性、可用性、パフォーマンスおよびスケーラビリティを改善します。

次の図に、索引パーティション化のオプションを示します。

関連項目:

- 「索引の概要」

- パーティション索引および使用する索引タイプの決定方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

ローカル・パーティション索引

ローカル・パーティション索引では、その表と同じパーティション数および同じパーティション・バウンドで、同じ列に対して索引がパーティション化されます。索引パーティションにあるすべてのキーが単一の表パーティションに格納された行のみを参照するように、各索引パーティションは、基礎となる表のパーティションと1対1で関連付けられます。この方法で、データベースは索引パーティションと関連する表パーティションを自動的に同期化し、表と索引の各ペアを独立させます。

ローカル・パーティション索引はデータ・ウェアハウス環境で共通のものです。ローカル索引には、次の利点があります。

- パーティションのデータを無効または使用不可能にするアクションは、該当のパーティションにのみ反映されるため、可用性が向上します。

- パーティションのメンテナンスが簡単になります。表パーティションを移動した場合、またはデータがパーティションをエージ・アウトした場合、再作成またはメンテナンスが必要となるのは、関連するローカル索引パーティションのみです。グローバル索引では、すべての索引パーティションを再作成またはメンテナンスする必要があります。

- パーティションのポイント・イン・タイム・リカバリが発生した場合は、索引をリカバリ時間までリカバリできます(「データファイル・リカバリ」を参照)。索引全体を再作成する必要はありません。

例4-4は、prod_id列をパーティション・キーとして使用して、パーティション化されたhash_sales表を作成する文を示しています。例4-5では、hash_sales表のtime_id列にローカル・パーティション索引を作成します。

例4-5 ローカル・パーティション索引

CREATE INDEX hash_sales_idx ON hash_sales(time_id) LOCAL;

図4-4では、hash_products表に2つのパーティションがあり、そのため、hash_sales_idxにも2つのパーティションがあります。各索引パーティションは異なる表パーティションに関連付けられています。索引パーティションSYS_P38は表パーティションSYS_P33の行を索引付けするのに対し、索引パーティションSYS_P39は表パーティションSYS_P34の行を索引付けします。

図4-4 ローカル索引のパーティション

パーティションは、明示的にローカル索引に追加することはできません。基礎となる表にパーティションを追加した場合のみ、新しいパーティションがローカル索引に追加されます。同様に、パーティションを明示的にローカル索引から削除することもできません。基礎となる表からパーティションを削除した場合のみ、ローカル索引のパーティションが削除されます。

他の索引の場合と同じように、ビットマップ索引もパーティション表に対して作成できます。ただし、ただ1つの制限として、ビットマップ索引はパーティション表に対してローカルであることが必要で、グローバル索引にはできません。グローバル・ビットマップ索引は、非パーティション表でのみサポートされます。

ローカルの同一キーおよび非同一キー索引

ローカル・パーティション索引は次のサブカテゴリに分類されます。

- ローカル同一キー索引
この索引の場合、パーティション・キーは索引定義の最初に配置されます。例4-2では、表がtime_idの範囲によってパーティション化されています。この表のローカル同一キー索引では、time_idがリストの最初の列になります。

- ローカル非同一キー索引
この索引の場合、パーティション・キーは索引付けされた列のリストの最初にはなく、またリスト内に存在する必要もありません。例4-5では、パーティション・キーproduct_idが最初に置かれていないため、索引はローカル非同一です。

これらの両方のタイプの索引で、パーティション絞込み(パーティション・プルーニングとも呼ばれる)を活用でき、この機能は、オプティマイザがパーティションを対象外とすることによって、データ・アクセスを高速化する場合に使用されます。問合せでパーティションを除外できるかどうかは、問合せの述語によって決まります。ローカル同一キー索引を使用する問合せでは、常に索引のパーティション絞込みが可能ですが、ローカル非同一キー索引を使用している問合せでは、絞込みはできない場合があります。

関連項目:
同一キー索引および非同一キー索引の使用方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

ローカル・パーティション索引の記憶域

表パーティションと同様に、ローカル索引パーティションは独自のセグメントに格納されます。各セグメントには、索引の総データの断片が含まれます。したがって、4つのパーティションから構成されるローカル索引は単一の索引セグメントではなく、4つの別々のセグメントに格納されます。

関連項目:
CREATE INDEX ... LOCALの例については、『Oracle Database SQL言語リファレンス』を参照してください。

グローバル・パーティション索引

グローバル・パーティション索引は、この索引の作成対象である基礎となる表とは別にパーティション化されたBツリー索引です。単一の索引パーティションは、任意またはすべての表パーティションを指す場合があり、その一方で、ローカル・パーティション索引では、索引パーティションと表パーティションの間に1対1のパリティが存在します。

一般的に、グローバル索引は高速アクセス、データ整合性および可用性が重要となるOLTPアプリケーションに役立ちます。OLTPシステムでは、employees.department_id列など1つのキーによって表がパーティション化される場合がありますが、アプリケーションではemployee_idまたはjob_idなどの多数の異なるキーによるデータへのアクセスが必要になる可能性があります。このような使用例では、グローバル索引が便利な場合があります。

グローバル索引は、レンジ・パーティション化またはハッシュ・パーティション化できます。レンジ・パーティション化の場合、データベースでは、列リストで指定した表の列の値範囲を基にグローバル索引をパーティション化します。ハッシュ・パーティション化の場合、データベースでは、パーティション・キー列の値を基にハッシュ関数を使用して行をパーティションに割り当てます。

たとえば、例4-2のtime_range_sales表にグローバル・パーティション索引を作成するとします。この表では、1998年の売上を含む行が1つのパーティションに格納され、1999年の売上を含む行は別のパーティションに格納されるというように、行が格納されます。例4-6では、channel_id列の範囲別にパーティション化されたグローバル索引を作成します。

例4-6 グローバル・パーティション索引

CREATE INDEX time_channel_sales_idx ON time_range_sales (channel_id)
GLOBAL PARTITION BY RANGE (channel_id)
(PARTITION p1 VALUES LESS THAN (3),
PARTITION p2 VALUES LESS THAN (4),
PARTITION p3 VALUES LESS THAN (MAXVALUE));

図4-5に示すように、グローバル索引パーティションには、複数の表パーティションをそれぞれ指すエントリを含めることができます。索引パーティションp1はchannel_idが2の行を指し、索引パーティションp2はchannel_idが3の行を指し、索引パーティションp3はchannel_idが4または9の行を指しています。

図4-5 グローバル・パーティション索引

関連項目:

- グローバル・パーティション索引の使用方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- CREATE INDEX ... GLOBALの例については、『Oracle Database SQL言語リファレンス』を参照してください。

パーティション索引構成表

索引構成表(IOT)に対してレンジ・パーティション化、リスト・パーティション化またはハッシュ・パーティション化を実行できます。パーティション化はIOTの管理性、可用性およびパフォーマンスの改善に役立ちます。さらに、IOTを使用するデータ・カートリッジも、格納したデータをパーティション化する機能を活用できます。

パーティション化したIOTには、次の特性がある点に注意してください。

- パーティション列は、主キー列のサブセットであることが必要です。

- 2次索引はローカルにもグローバルにもパーティション化できます。

- OVERFLOWデータ・セグメントは、常に表パーティションと同一レベルでパーティション化されます。

Oracle Databaseでは、パーティション化または非パーティション化された索引構成表のビットマップ索引がサポートされています。索引構成表のビットマップ索引の作成には、マッピング表が必要です。

関連項目:
「索引構成表の概要」

ビューの概要

ビューは、1つまたは複数の表の論理表現です。本質的には、ビューはストアド・クエリーです。ビューは、実表と呼ばれる基礎となる表からデータを導出します。実表には、表または他のビューを指定できます。ビュー上で実行されるすべての操作は、実際にその実表に影響します。多くの場合、ビューは表と同じように使用できます。

注意:
マテリアライズド・ビューは、標準のビューとは異なるデータ構造を使用します。「マテリアライズド・ビューの概要」を参照してください。

ビューを使用すると、様々なタイプのユーザーに合せてデータの表現形式を変化させることができます。通常、ビューは次の目的で使用されます。

- 事前に定義された行や列の集合のみにアクセスを限定して、表のセキュリティ・レベルを強化します。
たとえば、図4-6は、staffビューに実表employeesの列salaryまたはcommission_pctが含まれない仕組みを示しています。

- データの複雑さが隠されます。
たとえば、複数の表の関連した列または行を1つにまとめる結合によって、単一のビューを定義できます。ただし、ビューからは、この情報が複数の表から抽出されたものであるということはわかりません。1つの問合せで、表情報に対して複雑な計算を実行する場合もあります。これにより、ユーザーはビューに対して問い合せることができ、結合または計算の実行方法を知る必要がなくなります。

- 実表とは異なる視点からデータを提示します。
たとえば、ビューが基礎にしている表に影響を与えずに、ビューの列名を変更できます。

- 実表の定義の変更からアプリケーションを分離します。
たとえば、ビューを定義している問合せが表の4つの列の中の3つの列を参照している場合、たとえ5番目の列が追加されてもビューの定義は影響を受けないため、ビューを使用しているすべてのアプリケーションも影響を受けません。

ビューの使用例として、複数の列と膨大な行を持つhr.employees表について検討します。ユーザーがそのうちの5つの列または特定の行しか参照できないようにする場合は、次のようにビューを作成します。

CREATE VIEW staff AS
SELECT employee_id, last_name, job_id, manager_id, department_id
FROM   employees;

すべての副問合せと同様に、ビューを定義する問合せにFOR UPDATE句を含めることはできません。図4-6に、staffという名前のビューを示します。ビューが、実表の5つの列のみを表示していることに注目してください。

図4-6 ビュー

関連項目:

- ビューの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE VIEWの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

ビューの特性

表とは異なり、ビューには記憶域は割り当てられず、データが格納されることもありません。ビューは、参照する実表からデータを抽出または導出する問合せによって定義されます。ビューは他のオブジェクトを基盤としているため、データ・ディクショナリ.内でビューを定義する問合せ用の記憶域以外には記憶域が必要ありません。

ビューは、データベースによって自動的に操作される参照先のオブジェクトに依存します。たとえば、ビューの実表を削除してから再作成した場合、データベースは新しい実表がビュー定義と一致するかどうかを確認します。

ビューのデータ操作

ビューは表から導出されるため、ビューと表には多数の類似点があります。たとえば、ビューには表と同じように最大1000個の列を含めることができます。ユーザーはビューを問い合せることができ、いくつかの制限付きでビューに対してDMLを実行できます。ビューに対して実行される操作は、そのビューの実表のデータに影響し、実表の整合性制約とトリガーの対象になります。

次の例では、hr.employees表のビューを作成します。

CREATE VIEW staff_dept_10 AS
SELECT employee_id, last_name, job_id,
manager_id, department_id
FROM   employees
WHERE  department_id = 10
WITH CHECK OPTION CONSTRAINT staff_dept_10_cnst;

定義された問合せでは部門10の行のみを参照します。CHECK OPTIONは、ビューに対して発行されたINSERTおよびUPDATE文の結果が必ずビューで選択できる行になるよう、制約を持つビューを作成します。これにより、部門10の従業員の行は挿入できますが、部門30の行は挿入できません。

関連項目:
CREATE VIEW文の副問合せ制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ビュー内のデータへのアクセス方法

Oracle Databaseでは、ビューの定義は、ビューを定義する問合せテキストとしてデータ・ディクショナリに保存されます。SQL文でビューを参照すると、Oracle Databaseでは次のタスクが実行されます。

1. 可能な場合は常に、ビューに対する問合せとそのビューおよび基礎となるビューを定義する問合せをマージします。
Oracle Databaseにより、マージされた問合せは、ビューを参照せずに問合せを発行したものとして最適化されます。そのため、Oracle Databaseでは、列がビュー定義で参照されても、またはビューに対するユーザーの問合せで参照されても、参照される実表の列に対する索引を使用できます。

Oracle Databaseでは、ユーザーの問合せとビュー定義をマージできないこともあります。その場合、Oracle Databaseは参照された列の索引すべてを使用できるとはかぎりません。

2. 共有SQL領域内のマージ済の文を解析します。
Oracle Databaseでは、新しい共有SQL領域内のビューを参照する文は、既存の共有SQL領域に同様の文が含まれていない場合にのみ解析されます。したがって、ビューを使用すると、共有SQLに関連付けられているメモリーの使用量を減らせるという利点があります。

3. SQL文を実行します。

次の例に、ビューが問合せを受ける際のデータ・アクセスを示します。employeesおよびdepartments表を基にemployees_viewを作成するとします。

CREATE VIEW employees_view AS
SELECT employee_id, last_name, salary, location_id
FROM   employees JOIN departments USING (department_id)
WHERE  department_id = 10;

ユーザーはemployees_viewの次の問合せを実行します。

SELECT last_name
FROM   employees_view
WHERE  employee_id = 200;

Oracle Databaseはビューとユーザーの問合せをマージして、データ取得のために実行する次の問合せを構成します。

SELECT last_name
FROM   employees, departments
WHERE  employees.department_id = departments.department_id
AND    departments.department_id = 10
AND    employees.employee_id = 200;

関連項目:

- 問合せの最適化の詳細は、「オプティマイザの概要」および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- 「共有SQL領域」

更新可能な結合ビュー

結合ビューは、FROM句に複数の表またはビューのある1つのビューとして定義されます。例4-7では、staff_dept_10_30ビューがemployees表とdepartments表を結合し、部門10または30の従業員のみを含めるように指定しています。

例4-7 結合ビュー

CREATE VIEW staff_dept_10_30 AS
SELECT employee_id, last_name, job_id, e.department_id
FROM   employees e, departments d
WHERE  e.department_id IN (10, 30)
AND    e.department_id = d.department_id;

更新可能な結合ビューは変更可能な結合ビューとも呼ばれ、2つ以上の実表またはビューを含み、DMLの各操作が可能です。更新可能なビューはSELECT文のトップレベルのFROM句に複数の表を含み、WITH READ ONLY句で制限されません。

本質的に更新可能であるためには、ビューは複数の条件を満たす必要があります。たとえば、結合ビューに対するINSERT、UPDATEまたはDELETE操作では、1回に変更可能な実表は1つのみであることが一般的なルールです。次のUSER_UPDATABLE_COLUMNSデータ・ディクショナリ・ビューの問合せは、例4-7で作成されたビューが更新可能であることを示しています。

SQL> SELECT TABLE_NAME, COLUMN_NAME, UPDATABLE
2  FROM   USER_UPDATABLE_COLUMNS
3  WHERE  TABLE_NAME = 'STAFF_DEPT_10_30';

TABLE_NAME                     COLUMN_NAME                    UPD
------------------------------ ------------------------------ ---
STAFF_DEPT_10_30               EMPLOYEE_ID                    YES
STAFF_DEPT_10_30               LAST_NAME                      YES
STAFF_DEPT_10_30               JOB_ID                         YES
STAFF_DEPT_10_30               DEPARTMENT_ID                  YES

結合ビューの更新可能なすべての列が、キー保存表の列にマップされる必要があります。結合の問合せにおけるキー保存表とは、その問合せの出力で、基礎となる表の各行が最大1回のみ表示される表のことです。例4-7では、department_idがdepartments表の主キーであるため、employees表をキー保存表にして、employees表からの各行が結果セットに最高で1回のみ表示されます。departments表は、表内の各行が結果セットに複数回表示される可能性があるため、キー保存表ではありません。

関連項目:
結合ビューの更新方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

オブジェクト・ビュー

ビューが仮想表であるのと同様に、オブジェクト・ビューは仮想オブジェクト表です。ビュー内の各行はオブジェクトであり、オブジェクト・タイプのインスタンスです。オブジェクト型はユーザー定義データ型です。

リレーショナル・データは、オブジェクト型として格納されているかのように検索、更新、挿入および削除できます。また、オブジェクト、REFおよびコレクション(ネストした表とVARRAY)などのオブジェクト・データ型である列を持つビューを定義できます。

リレーショナル・ビューと同様、オブジェクト・ビューにはユーザーに表示されるデータのみを表示できます。たとえば、オブジェクト・ビューにITプログラマについてのデータは表示し、給与に関する機密データは除外することが可能です。次の例では、employee_typeオブジェクトを作成してから、このオブジェクトを基にしたビューit_prog_viewを作成しています。

CREATE TYPE employee_type AS OBJECT
(
employee_id  NUMBER (6),
last_name    VARCHAR2 (25),
job_id       VARCHAR2 (10)
);
/

CREATE VIEW it_prog_view OF employee_type
WITH OBJECT IDENTIFIER (employee_id) AS
SELECT  e.employee_id, e.last_name, e.job_id
FROM    employees e
WHERE   job_id = 'IT_PROG';

オブジェクト・ビューは、ビュー内のデータをリレーショナル表から取得し、この表がオブジェクト表として定義されているものとしてデータにアクセスできるため、プロトタイプ化、およびオブジェクト指向アプリケーションへの移行に便利です。オブジェクト指向アプリケーションは、既存の表を別の物理構造に変換せずに実行できます。

関連項目:

- オブジェクト・タイプとオブジェクト・ビューの詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。

- CREATE TYPEコマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

マテリアライズド・ビューの概要

マテリアライズド・ビューは、スキーマ・オブジェクトとして事前に格納またはマテリアライズされた問合せ結果です。問合せのFROM句では表、ビューおよびマテリアライズド・ビューの名前を指定できます。これらのオブジェクトは、総称として マスター表(レプリケーション用語)またはディテール表(データ・ウェアハウス用語)と呼ばれます。

マテリアライズド・ビューは、データの集計、計算、レプリケートおよび分配に使用されます。これらは、次のような様々なコンピューティング環境に適しています。

- データ・ウェアハウスでは、マテリアライズド・ビューを使用して、合計値や平均値など、集計関数から生成されたデータを計算し、格納できます。
サマリーは集計ビューで、結合および集計操作を事前に計算して結果を表に格納することで、問合せ時間が短縮されます。マテリアライズド・ビューは、サマリーと同じものです(「データ・ウェアハウスのアーキテクチャ(基本)」を参照)。また、マテリアライズド・ビューを使用して、集計操作の有無に関係なく、結合を計算できます。互換性がOracle9i以上に設定されていると、フィルタ選択を含む問合せにマテリアライズド・ビューを使用できます。

- マテリアライズド・ビューの レプリケーションでは、ある時点からの表の全体または一部のコピーがビューに含まれます。マテリアライズド・ビューは分散サイトにデータをレプリケートし、複数のサイトで実行される更新を同期化します。このレプリケーション形式は、データベースが常時ネットワークに接続されていない場合のフィールド・セールスなどの環境に適しています。

- モバイル・コンピューティング環境では、マテリアライズド・ビューを使用して、中央のサーバーからモバイル・クライアントにデータのサブセットをダウンロードし、中央のサーバーから定期的にリフレッシュし、クライアントで実行された更新を中央のサーバーに伝播できます。

レプリケーション環境では、マテリアライズド・ビューはマスター・データベースと呼ばれる別のデータベース内の表とデータを共有します。マテリアライズド・ビューに関連付けられたマスター・サイトの表がマスター表です。図4-7に、別のデータベース内のマスター表に基づく、1つのデータベース内のマテリアライズド・ビューを示します。マスター表を更新すると、マテリアライズド・ビューのデータベースにレプリケートされます。

図4-7 マテリアライズド・ビュー

関連項目:

- Oracle Streamsによるレプリケーションの詳細は、「情報の共有」を参照してください。

- マテリアライズド・ビューの使用方法の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』および『Oracle Databaseアドバンスト・レプリケーション』を参照してください。

- CREATE MATERIALIZED VIEW文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

マテリアライズド・ビューの特性

マテリアライズド・ビューには、非マテリアライズド・ビューおよび索引と同じ特性がいくつかあります。マテリアライズド・ビューは、次の点が索引に類似しています。

- 実際のデータを含み、記憶域を使用します。

- マスター表のデータに変更があった場合は、リフレッシュできます。

- クエリー・リライト操作に使用すると、SQLの実行効率が改善されます。

- その存在は、SQLアプリケーションとユーザーに対して透過的です。

マテリアライズド・ビューは他の表およびビューのデータを表す点において、非マテリアライズド・ビューに類似しています。索引とは異なり、ユーザーはSELECT文を使用してマテリアライズド・ビューを直接問合せできます。必要なリフレッシュのタイプによっては、DML文を使用してビューを更新することも可能です。

次の例では、shサンプル・スキーマの3つのマスター表に基づくマテリアライズド集計ビューを作成して、データを投入しています。

CREATE MATERIALIZED VIEW sales_mv AS
SELECT t.calendar_year, p.prod_id, SUM(s.amount_sold) AS sum_sales
FROM   times t, products p, sales s
WHERE  t.time_id = s.time_id
AND    p.prod_id = s.prod_id
GROUP BY t.calendar_year, p.prod_id;

次の例では、sales_mvのマスター表であるsales表を削除してから、sales_mvを問い合せます。行はマスター表のデータとは別に格納(マテリアライズ)されているため、問合せによってデータが選択されます。

SQL> DROP TABLE sales;

Table dropped.

SQL> SELECT * FROM sales_mv WHERE ROWNUM < 4;

CALENDAR_YEAR    PROD_ID  SUM_SALES
------------- ---------- ----------
1998         13  936197.53
1998         26  567533.83
1998         27  107968.24

マテリアライズド・ビューはパーティション化できます。マテリアライズド・ビューは、そのパーティション表および1つ以上の索引上で定義できます。

関連項目:
データ・ウェアハウスでマテリアライズド・ビューを使用する方法の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

マテリアライズド・ビューのリフレッシュ方法

データベースでは、マスター表の変更後にマテリアライズド・ビューをリフレッシュして、マテリアライズド・ビューのデータを管理します。リフレッシュ方法には、増分リフレッシュとしての高速リフレッシュまたは完全リフレッシュがあります。

マテリアライズド・ビューが事前作成表を参照しないかぎり、完全リフレッシュは、マテリアライズド・ビューが最初にBUILD IMMEDIATEとして定義されたときに行われます。リフレッシュを実行すると、マテリアライズド・ビューを定義する問合せも実行されます。この処理は、特にデータベースが大量のデータを読み取って処理する必要がある場合に遅くなることがあります。

高速リフレッシュにより、マテリアライズ・ビューを最初から再作成する必要がなくなります。このように変更内容のみを処理すると、リフレッシュ時間が非常に速くなります。マテリアライズド・ビューは、必要時に、または定期的にリフレッシュできます。また、マスター表と同じデータベース内のマテリアライズド・ビューは、トランザクションによってマスター表の変更がコミットされるたびにリフレッシュできます。

高速リフレッシュ方法を使用する場合、マスター表に対する変更はマテリアライズド・ビュー・ログまたはダイレクト・ローダー・ログに記録されます。マテリアライズド・ビュー・ログとは、マスター表に定義されているマテリアライズド・ビューの増分リフレッシュを実行できるように、マスター表の変更を記録するスキーマ・オブジェクトです。マテリアライズド・ビュー・ログは、それぞれ1つのマスター表に対応付けられています。マテリアライズド・ビュー・ログは、マスター表と同じデータベースおよびスキーマに格納されます。

関連項目:

- マテリアライズド・ビューのリフレッシュ方法の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- マテリアライズド・ビュー・ログの詳細は、『Oracle Databaseアドバンスト・レプリケーション』を参照してください。

クエリー・リライト

クエリー・リライトは、マスター表に関して記述されたユーザーのリクエストを、マテリアライズド・ビューを含み、同等の意味を持つリクエストに変換する最適化技術です。実表に大量のデータが含まれている場合には、集計および結合の計算は負荷が大きく、時間がかかります。マテリアライズド・ビューには事前に計算された集計と結合が含まれているため、クエリー・リライトはマテリアライズド・ビューを使用してすぐに問合せに応答できます。

オプティマイザ問合せトランスフォーマは、マテリアライズド・ビューを使用するために透過的にリクエストをリライトし、ユーザー操作およびSQL文によるマテリアライズド・ビューへの参照は必要ありません。クエリー・リライトは透過的であるため、アプリケーション・コードのSQLを無効にしなくても、マテリアライズド・ビューを追加または削除できます。

一般的に、ディテール表ではなくマテリアライズド・ビューを使用するクエリー・リライトでは、レスポンス時間が短縮されます。図4-8は、オリジナルまたはリライトされた問合せに対してデータベースが実行計画を生成し、最もコストの低い計画を選択する仕組みを示しています。

図4-8 クエリー・リライト

関連項目:

- 「オプティマイザの概要」

- クエリー・リライトの使用方法の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

順序の概要

順序とは、複数のユーザーが一意の整数を生成できるスキーマ・オブジェクトです。順序ジェネレータは、数値データ型に対してサロゲート・キーを生成するスケーラブルかつパフォーマンスの高い方法を提供します。

順序の特性

順序の定義には、次のように一般的な情報を指定します。

- 順序の名前

- 昇順または降順

- 数値の増分値

- データベースが、メモリー内に生成された一連の順序番号をキャッシュするかどうか

- 制限に到達したときに、順序を循環させるかどうか

次の例では、サンプル・スキーマoeに順序customers_seqを作成します。customers表に行が追加されると、アプリケーションはこの順序を使用して、顧客ID番号を付与します。

CREATE SEQUENCE customers_seq
START WITH      1000
INCREMENT BY    1
NOCACHE
NOCYCLE;

最初のcustomers_seq.nextvalの参照では、1000が戻されます。2回目には1001が戻されます。以降の各参照では、前回の参照よりも1大きい値が戻されます。

関連項目:

- 順序の管理方法の詳細は、『Oracle Database 2日で開発者ガイド』および『Oracle Database管理者ガイド』を参照してください。

- CREATE SEQUENCEの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

順序への同時アクセス

同じ順序ジェネレータから、複数の表に対して数値を生成できます。この方法により、データベースは自動的に主キーを生成して、複数の行または表にまたがるキーを統合できます。たとえば、順序はorders表およびcustomers表の主キーを生成できます。

順序ジェネレータは、ディスクI/Oのオーバーヘッドまたはトランザクション・ロックを発生させずに、一意の番号を生成するため、マルチ・ユーザー環境で便利です。たとえば、2人のユーザーがorders表に新しい行を同時に挿入するとします。順序を使用してorder_id列に一意の番号を生成すると、一方のユーザーは、他方のユーザーが注文番号を入力するのを待機する必要はありません。どちらのユーザーにも、順序により、正しい値が自動的に生成されるためです。

順序を参照する各ユーザーは、セッションで生成された最後の順序である現行の順序番号にアクセスできます。ユーザーは、文を発行して新しい順序番号を生成することも、セッションで最後に生成された現行の番号を使用することもできます。セッション内の文が順序番号を生成すると、その番号はこのセッションでのみ使用可能となります。最終的にロールバックされたトランザクションで生成されて使用された個々の順序番号はスキップされます。

注意:

アプリケーションが連続する番号を使用する場合、Oracleの順序は使用できません。独自に開発したコードを使用して、データベースのアクティビティをシリアライズする必要があります。

関連項目:
第9章「データの同時実行性と整合性」

ディメンションの概要

データ・ウェアハウスには通常、ディメンションとファクトという2つの重要な要素があります。ディメンションは、時刻、地理、製品、部門および販売チャネルなどのビジネス上の質問を指定する場合に使用される任意のカテゴリです。ファクトは、売上単位または利益などの特定のディメンション値のセットに関連付けられたイベントまたはエンティティです。

多次元要求の例には、次の処理が含まれます。

- 2010年と2011年について、州、国、地域というように地理ディメンションの集計レベルの昇順で全製品の総売上を表示します。

- 2010年と2011年における南アメリカの地域別経費を示す事業のクロス集計分析を作成します。可能な小計をすべて組み込みます。

- 自動車製品に関する2011年の販売収入に従って、アジアでの販売代理店の上位10社をリストし、そのコミッションのランキングを作成します。

多次元による多くの質問では、通常は時間、地理または予算にまたがって集計されたデータと、データ・セットの比較が必要になります。

ディメンションを作成すると、より広範囲でのクエリー・リライト機能の使用が許可されます。データベースでは、マテリアライズド・ビューを使用した透過的なクエリー・リライトによって、問合せのパフォーマンスを改善できます。

関連項目:
「データ・ウェアハウスとビジネス・インテリジェンスの概要」

ディメンションの階層構造

ディメンション表は列または列セットのペア間の階層関係を定義する論理構造です。ディメンションには、この論理構造に割り当てるデータ記憶域がありません。ディメンション情報がディメンション表に格納されるのに対して、ファクト情報は ファクト表に格納されます。

顧客ディメンション内では、顧客は都市、州、国、準地域、地域までロールアップできます。通常、データ分析はディメンション階層の高いレベルから開始され、必要に応じて徐々に階層がドリルダウンされます。

子レベルの値は、それぞれが親レベルの1つの値にのみ対応付けられます。階層関係は、ある階層レベルから次のレベルへの機能上の依存関係です。

関連項目:

- ディメンションの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- ディメンションの作成方法の詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

ディメンションの作成

ディメンションはSQL文を使用して作成されます。CREATE DIMENSION文では、次の事項を指定します。

- 複数のLEVEL句。それぞれがディメンション内の1列または列の集合を識別します。

- 1つ以上のHIERARCHY句。隣接するレベル間の親子関係を指定します。

- オプションのATTRIBUTE句。それぞれが個々のレベルに対応付けられている他の列または列セットを識別します。

次の文は、サンプル・スキーマshにcustomers_dimディメンションを作成するために使用されました。

CREATE DIMENSION customers_dim
LEVEL customer   IS (customers.cust_id)
LEVEL city       IS (customers.cust_city)
LEVEL state      IS (customers.cust_state_province)
LEVEL country    IS (countries.country_id)
LEVEL subregion  IS (countries.country_subregion)
LEVEL region     IS (countries.country_region)
HIERARCHY geog_rollup (
customer      CHILD OF
city          CHILD OF
state         CHILD OF
country       CHILD OF
subregion     CHILD OF
region
JOIN KEY (customers.country_id) REFERENCES country )
ATTRIBUTE customer DETERMINES
(cust_first_name, cust_last_name, cust_gender,
cust_marital_status, cust_year_of_birth,
cust_income_level, cust_credit_limit)
ATTRIBUTE country DETERMINES (countries.country_name);

ディメンション内の列は、同じ表のもの(非正規化)でも複数の表のもの(完全正規化または一部正規化)でもかまいません。たとえば、正規化されているtimeディメンションには、date表、month表およびyear表と、各date行をmonth行に、各month行をyear行に接続する結合条件を含めることができます。完全な非正規化のtimeディメンションでは、date、monthおよびyear列は同じ表に格納されます。正規化されているかどうかに関係なく、列相互の階層関係をCREATE DIMENSION文で指定する必要があります。

関連項目:

- ウェアハウス環境におけるディメンションの使用方法は、『Oracle Warehouse Builderデータ・モデリング、ETLおよびデータ・クオリティ・ガイド』を参照してください。

- CREATE DIMENSIONの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

シノニムの概要

シノニムとは、スキーマ・オブジェクトの別名です。たとえば、表またはビュー、順序、PL/SQLプログラム単位、ユーザー定義オブジェクト型または別のシノニムなどに対してシノニムを作成できます。シノニムは単なる別名であるため、データ・ディクショナリ内の定義以外に記憶域は必要ありません。

シノニムを使用すると、データベース・ユーザー側のSQL文を単純化できます。また、シノニムは、基礎となるスキーマ・オブジェクトのIDおよび場所を非表示にする場合にも便利です。基礎となるオブジェクトを改名または移動する必要がある場合、シノニムのみを再定義すればよいことになります。シノニムに基づくアプリケーションは、今後も変更なしに機能し続けることができます。

プライベート・シノニムとパブリック・シノニムの両方を作成できます。プライベート・シノニムは、特定のユーザーのスキーマに含まれており、そのユーザーが他のユーザーに対するシノニムの使用許可を制御します。パブリック・シノニムはPUBLICという名前の特別なユーザー・グループが所有しており、すべてのデータベース・ユーザーがアクセスできます。

例4-9では、データベース管理者がhr.employees表のpeopleという名前のパブリック・シノニムを作成しています。その後、ユーザーがoeスキーマに接続して、シノニムが参照する表内の行数をカウントしています。

例4-8 パブリック・シノニム

SQL> CREATE PUBLIC SYNONYM people FOR hr.employees;

Synonym created.

SQL> CONNECT oe
Enter password: password
Connected.

SQL> SELECT COUNT(*) FROM people;

COUNT(*)
----------
107

パブリック・シノニムではデータベースの統合が困難になるため、パブリック・シノニムは慎重に使用してください。例4-9に示すように、データベース内に存在するパブリック・シノニムpeopleは1つのみであるため、別の管理者がパブリック・シノニムpeopleの作成を試行すると失敗します。パブリック・シノニムを多用すると、アプリケーション間でネームスペースに競合が発生します。

例4-9 パブリック・シノニム

SQL> CREATE PUBLIC SYNONYM people FOR oe.customers;
CREATE PUBLIC SYNONYM people FOR oe.customers
*
ERROR at line 1:
ORA-00955: name is already used by an existing object

SQL> SELECT OWNER, SYNONYM_NAME, TABLE_OWNER, TABLE_NAME
2  FROM DBA_SYNONYMS
3  WHERE SYNONYM_NAME = 'PEOPLE';

OWNER      SYNONYM_NAME TABLE_OWNER TABLE_NAME
---------- ------------ ----------- ----------
PUBLIC     PEOPLE       HR          EMPLOYEES

シノニム自体は安全ではありません。シノニムに対してオブジェクト権限を付与すると、実際には基礎となるオブジェクトに権限を付与することになります。シノニムは、GRANT文のオブジェクトの別名としてのみ機能しています。

関連項目:

- シノニムの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE SYNONYMの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

5 データ整合性

この章では、整合性制約によって、データベースに関連するビジネス・ルールがどのように規定され、表への無効なエントリがどのように防止されるかについて説明します。

この章の内容は、次のとおりです。

- データ整合性の概要

- 整合性制約のタイプ

- 整合性制約の状態

関連項目:
「表の概要」

データ整合性の概要

ビジネス・ルールでは、常に真(true)となる必要がある、または常に偽(false)となる必要がある条件および関係を定義します。たとえば、各企業では、給与、従業員番号、在庫追跡などに関して独自のポリシーを定義します。データベース管理者やアプリケーション開発者が決定した規則に準拠し、データ整合性を維持するのは重要なことです。

データ整合性を保証する方法

データベース・アプリケーションを設計する場合、開発者は、データベースに格納するデータの整合性を保証するための様々なオプションを使用できます。このオプションには次のものがあります。

- トリガーされるストアド・データベース・プロシージャを使用して、ビジネス・ルールを規定します(「トリガーの概要」を参照)。

- ストアド・プロシージャを使用してデータへのアクセスを完全に制御します(「サーバー側プログラミングの概要」を参照)。

- データベース・アプリケーションのコードでビジネス・ルールを規定します。

- 列またはオブジェクト・レベルで定義される、データベースの値を制限する規則である、Oracle Databaseの整合性制約を使用します。

この章では、整合性制約の基本概念について説明します。

整合性制約の利点

整合性制約は、SQLを使用して作成および削除されるスキーマ・オブジェクトです。データ整合性を維持するために、使用できない場合を除いて、整合性制約を使用するようにしてください。データ整合性を維持する方法として、整合性制約には、次のような利点があります。

- 宣言の容易さ
SQL文を使用して整合性制約を定義するため、追加のプログラミングなしに表を定義または変更できます。SQL文は記述が容易で、プログラミングのエラーを避けられます。

- 規則の集中化
整合性制約は表に対して定義され、データ・ディクショナリに格納されます(「データ・ディクショナリの概要」を参照)。したがって、すべてのアプリケーションから入力されるデータは、同じ整合性制約を遵守する必要があります。規則が表レベルで変化した場合も、アプリケーションを変更する必要はありません。また、データベースによってSQL文がチェックされる前に、アプリケーションがデータ・ディクショナリのメタデータを使用して、すぐにユーザーに違反を通知することもできます。

- データをロードする場合の柔軟性
大量のデータをロードする場合は、パフォーマンスのオーバーヘッドを回避するために、整合性制約を一時的に無効にできます。データ・ロードが完了した後、整合性制約を再度有効にできます。

関連項目:

- データ整合性の維持方法の詳細は、『Oracle Database 2日で開発者ガイド』を参照してください。

- 整合性制約の管理の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

整合性制約のタイプ

Oracle Databaseでは、表と列の両方のレベルで制約を適用できます。列または属性の定義の一部として指定される制約は、表内指定と呼びます。表定義の一部として指定される制約は、表外指定と呼びます。

キーという用語は、複数のタイプの整合性制約の定義で使用されます。キーとは、特定タイプの整合性制約の定義に含まれる列または列の集合です。キーによって、リレーショナル・データベースの表と列の間の関連が示されます。キーの中にある個々の値を、キー値と呼びます。

表5-1に、制約のタイプを示します。表内指定であることが必要なNOT NULLを除き、どの制約も表内と表外のいずれかで指定できます。

表5-1 制約のタイプ

制約タイプ

説明

関連項目

NOT NULL

指定した列でのNULLを含む行の挿入または更新を許可または禁止します。

「NOT NULL整合性制約」

一意キー

同じ列または列の組合せで、複数の行が同じ値を持つことを禁止しますが、一部の値がNULLであることを許可します。

「一意制約」

主キー

NOT NULL制約と一意制約を結合します。同じ列または列の組合せで、複数の行が同じ値を持つことを禁止し、値がNULLであることを禁止します。

「主キー制約」

外部キー

列を外部キーに指定し、外部キーと、参照キーと呼ばれる主キーまたは一意キーの間の関係を確立します。

「外部キー制約」

チェック

指定した条件をデータベース値が満たしている必要があります。

「チェック制約」

REF

REF列の値で許可されるデータ操作のタイプ、およびその操作の結果として依存データが受ける影響について指示します。オブジェクト・リレーショナル・データベースでは、REFと呼ばれる組込みデータ型によって、指定したオブジェクト型の行オブジェクトへの参照がカプセル化されます。REF列に対する参照整合性制約によって、REFの行オブジェクトがあることが保証されます。

REF制約の詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。

関連項目:

- 「表の概要」

- 制約のタイプの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

NOT NULL整合性制約

NOT NULL制約がある場合、表の列値にNULLを使用できません。NULLは、値がないことを示します。デフォルトでは、表のすべての列でNULLを使用できます。

NOT NULL制約は、値が必須である列のためのものです。たとえば、hr.employees表ではlast_name列に値が必要です。姓なしで従業員の行を挿入しようとすると、次のエラーが発生します。

SQL> INSERT INTO hr.employees (employee_id, last_name) values (999, 'Smith');
.
.
.
ERROR at line 1:
ORA-01400: cannot insert NULL into ("HR"."EMPLOYEES"."LAST_NAME")

NOT NULL制約を持つ列は、行が1つも含まれていない表またはデフォルト値が指定された表にのみ追加できます。

関連項目:

- NOT NULL制約を表に追加する例については、『Oracle Database 2日で開発者ガイド』を参照してください。

- NOT NULL制約を使用する場合の制限については、『Oracle Database SQL言語リファレンス』を参照してください。

- NOT NULL制約の使用タイミングの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

一意制約

一意キー制約では、列(または列の集合)のすべての値が一意である必要があります。一意キー制約が設定されていると、表の行では、列(一意キー)または列の集合(コンポジット一意キー)で重複する値を持つことはありません。

注意:
キーという用語は、整合性制約で定義されている列のみを指します。データベースではキー列に対して索引を暗黙的に作成または再利用することで一意制約による規制を規定するため、一意キーという用語は一意キー制約または一意索引のシノニムとして誤用されることがあります。

一意キー制約は、任意の列に重複する値が格納されないようにする場合に適しています。一意制約は、(各表の行を一意に識別することが目的である)主キー制約とは異なり、通常は、一意であること以外の意味を持たない値が含まれています。一意キーの例には次のものがあります。

- 主キーが顧客番号である場合の、顧客電話番号

- 主キーが部門番号である場合の、部門名

例2-1に示すように、hr.employees表のemail列には一意キー制約が存在します。文の関連する部分は、次のとおりです。

CREATE TABLE employees    ( ...
, email          VARCHAR2(25)
CONSTRAINT   emp_email_nn  NOT NULL ...
, CONSTRAINT     emp_email_uk  UNIQUE (email) ... );

例5-1に示すように、emp_email_uk制約により、2人の従業員が同じ電子メール・アドレスを持つことはありません。

例5-1 一意制約

SQL> SELECT employee_id, last_name, email FROM employees WHERE email = 'PFAY';

EMPLOYEE_ID LAST_NAME                 EMAIL
----------- ------------------------- -------------------------
202 Fay                       PFAY

SQL> INSERT INTO employees (employee_id, last_name, email, hire_date, job_id)
1  VALUES (999,'Fay','PFAY',SYSDATE,'ST_CLERK');
.
.
.
ERROR at line 1:
ORA-00001: unique constraint (HR.EMP_EMAIL_UK) violated

NOT NULL制約も定義されている場合を除き、一意キー制約では、NULLは常に許可されます。このため、一意キー制約とNOT NULL制約の両方を持つ列が一般的に使用されます。これらの組合せにより、ユーザーは一意キーに必ず値を入力することになり、さらに新しい行データが既存の行データと競合することがなくなります。

注意:
複数の列に対する一意キー制約の検索メカニズムにより、一部がNULLのコンポジット一意キー制約の非NULL列で同一の値は許されません。

関連項目:

- 「一意索引と非一意索引」

- UNIQUE制約を表に追加する例については、『Oracle Database 2日で開発者ガイド』を参照してください。

主キー制約

主キー制約を設定すると、この制約の対象となる1つ以上の列グループの値によって、行が一意に識別されます。各表には1つの主キーを設定でき、この主キーによって行が識別され、行が重複しないことが保証されます。

主キーには、自然キーまたはサロゲート・キーを使用できます。自然キーは、表内の既存の属性から作成される、意味のある識別子です。たとえば、参照表の郵便番号を自然キーとして使用できます。これに対して、サロゲート・キーは、システムで生成され、値が増加する識別子で、この識別子によって表内での一意性が保たれます。通常、サロゲート・キーは順序によって生成されます。

Oracle Databaseでは、主キー制約の実装により、次のことが保証されます。

- 指定された列または列の集合の中に、2つの行が重複する値を持つことはありません。

- 主キー列では、NULLは許可されません。

主キーが必要となる典型的な状況は、従業員用の数値識別子です。各従業員は、一意のIDを持つ必要があります。従業員は、employees表の1つの行によってのみ記述する必要があります。

例5-1では、既存の従業員が従業員IDとして202を持っており、従業員IDが主キーであることが示されています。次に示す例では、同じ従業員IDを持つ従業員、およびIDを持たない従業員を追加します。

SQL> INSERT INTO employees (employee_id, last_name, email, hire_date, job_id)
1  VALUES (202,'Chan','ICHAN',SYSDATE,'ST_CLERK');
.
.
.
ERROR at line 1:
ORA-00001: unique constraint (HR.EMP_EMP_ID_PK) violated

SQL> INSERT INTO employees (last_name) VALUES ('Chan');
.
.
.
ERROR at line 1:
ORA-01400: cannot insert NULL into ("HR"."EMPLOYEES"."EMPLOYEE_ID")

データベースにより、索引を持つ主キー制約が規定されます。通常、列に対して作成された主キー制約によって、暗黙的に一意索引とNOT NULL制約が作成されます。この規則には、次の例外がある点に注意してください。

- 場合によっては、遅延可能制約を使用して主キーを作成する場合、生成された索引は一意ではありません。

注意:
CREATE UNIQUE INDEX文を使用すると、一意の索引を明示的に作成できます。

- 主キー制約の作成時に使用できる索引がある場合、新しい索引を暗黙的に作成するのではなく、制約はこの索引を再使用します。

デフォルトでは、暗黙的に作成された索引の名前が、主キー制約の名前になります。索引にはユーザー定義名を指定することもできます。制約の作成に使用するCREATE TABLE文またはALTER TABLE文にENABLE句を組み込んで、索引の記憶域オプションを指定できます。

関連項目:
表に主キー制約を追加する方法の詳細は、『Oracle Database 2日で開発者ガイド』および『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

外部キー制約

2つの表に1つ以上の共通の列が含まれる場合、Oracle Databaseでは、参照整合性制約とも呼ばれる外部キー制約を介して2つの表の間の関係を規定できます。この制約では、制約が定義される列の各値に対して、他の表と列を指定するもう一方の列の値が一致する必要があります。参照整合性規則の例としては、既存の部門にのみ従事できる従業員があります。

表5-2に、参照整合性制約に関連する用語を示します。

表5-2 参照整合性制約の用語

用語

定義

外部キー

制約の定義に含まれている列または列の集合のうち、参照キーを参照するもの。たとえば、employeesのdepartment_id列は外部キーであり、departmentsのdepartment_id列を参照します。

外部キーは、複数列として定義できます。ただし、コンポジット外部キーの列数とデータ型は、参照先のコンポジット主キーまたは一意キーと同じであることが必要です。

外部キーの値は、参照先の主キーまたは一意キーの値と一致するか、NULLであることが可能です。コンポジット外部キーのいずれかの列がNULLの場合、そのキーのNULL以外の部分は、親キーの対応部分と一致している必要はありません。

参照キー

表の一意キーまたは主キーで、外部キーによって参照されるキー。たとえば、departmentsのdepartment_id列は、employeesのdepartment_id列の参照キーです。

依存表または子表

外部キーを含む表。この表は、参照される一意キーまたは主キーにある値に依存しています。たとえば、employees表はdepartmentsの子です。

参照表または親表

子表の外部キーが参照する表。この表の参照キーによって、子表に対する特定の挿入または更新が許可されるかどうかが決まります。たとえば、departments表はemployeesの親です。

図5-1に、employees.department_id列の外部キーを示します。この列のすべての値が、departments.department_id列の値と一致することが保証されます。このため、employees.department_id列に間違った部門番号が存在することはありません。

図5-1 参照整合性制約

関連項目:
表に外部キー制約を追加する方法の詳細は、『Oracle Database 2日で開発者ガイド』および『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

自己参照型整合性制約

図5-2に、自己参照型整合性制約を示します。この場合、外部キーは同じ表の親キーを参照します。

図5-2では、参照型整合性制約によって、employees.manager_id列のすべての値が、employees.employee_id列の既存の値に対応するようになります。たとえば、従業員102の管理職がemployees表に存在する必要があります。この制約によって、間違った従業員番号がmanager_id列に存在する可能性がなくなります。

図5-2 単一表の参照制約

NULLと外部キー

リレーショナル・モデルでは、外部キーの値は、参照先の主キーまたは一意キーの値と一致するか、NULLであることが可能です。たとえば、ユーザーは部門IDを指定することなくhr.employeesに行を挿入できます。

コンポジット外部キーのいずれかの列がNULLの場合、そのキーのNULL以外の部分は、親キーの対応部分と一致している必要はありません。

親キーの修正と外部キー

親キーを削除するとき、外部キーと親キーの間の関係が影響を及ぼします。たとえば、あるユーザーが部門のレコードの削除を試行すると、この部門の従業員のレコードに何が起こるかについて説明します。

親キーが変更された場合、参照整合性制約では、子表の依存行に対して実行される次のアクションを指定できます。

- 削除または更新に対するアクションなし
通常、結果が参照整合性に違反する場合、ユーザーは参照キー値を変更できません。たとえば、employees.department_idがdepartmentsに対する外部キーであり、従業員が特定の部門に属す場合、この部門の行の削除を試行すると、制約に対する違反となります。

- 連鎖的な削除
参照キー値を含む行が削除された場合、子表のうち依存している外部キー値を含むすべての行も削除されます(DELETE CASCADE)。たとえば、departmentsの行を削除すると、この部門のすべての従業員の行が削除されます。

- NULLを設定する削除
参照キー値を含む行が削除された場合に、子表のうち依存している外部キー値を含むすべての行の値がNULLに設定されます(DELETE SET NULL)。たとえば、部門の行を削除すると、この部門のすべての従業員に関してdepartment_id列値がNULLに設定されます。

表5-3に、親表のキー値および子表の外部キー値に対する異なる参照アクションごとに可能なDML文の概要を示します。

表5-3 UPDATE NO ACTIONとDELETE NO ACTIONで許可されるDML文

DML文

親表に対して発行

子表に対して発行

INSERT

親キー値が一意であれば常に発行できます。

外部キーの値が親キーに存在するか、外部キーの一部またはすべてがNULLの場合にのみ発行できます。

UPDATE NO ACTION

文の実行後に、参照される親キー値のない行が子表内に残らない場合は発行できます。

文の実行後も新しい外部キー値によって参照キー値が参照される場合は発行できます。

DELETE NO ACTION

子表のどの行も親キー値を参照していない場合は発行できます。

常に発行可能

DELETE CASCADE

常に発行可能

常に発行可能

DELETE SET NULL

常に発行可能

常に発行可能

注意:
Oracle Databaseの外部キー整合性制約でサポートされていない他の参照アクションは、データベース・トリガーを使用して規定できます。「トリガーの概要」を参照してください。

関連項目:
ON DELETE句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

索引と外部キー

一般的に、ヒープ構成表には外部キーの索引付けをお薦めします。パーティション化されていない表での例外は、対応する一意キーまたは主キーの更新や削除が発生しないことが確実な場合です。

注意:
索引構成表および表クラスタなどのヒープ以外のデータ構造には、追加の考慮事項が適用されます。

子表で外部キーの索引付けを行うと、次の利点があります。

- 子表に対する完全表ロックが防止されます。かわりに、データベースは索引に対する行ロックを取得します。

- 子表の全表スキャンを行う必要がなくなります。例として、ユーザーがdepartments表から部門10のレコードを削除する場合を想定します。employees.department_idが索引付けされていない場合、データベースはemployeesをスキャンして、部門10に従業員が存在するかどうかを判断する必要があります。

関連項目:
「ロックと外部キー」および「索引の概要」

チェック制約

列または列の集合に対するチェック制約では、すべての行について、指定した条件がTRUEまたはUNKNOWNであることが必要です。DMLの結果で制約の条件がFALSEに評価される場合、そのSQL文はロールバックされます。

チェック制約の主な利点は、特殊な整合性規則を規定できることです。たとえば、チェック制約を使用すると、hr.employees表に次の規則を規定できます。

- salary列の値は10000以下である必要があります。

- commission列の値は、salaryの値以下である必要があります。

次の例では、employeesに最大給与制約を作成し、最大値を超える給与を含む行を文で挿入すると、どのようなことが起こるかを示します。

SQL> ALTER TABLE employees ADD CONSTRAINT max_emp_sal CHECK (salary < 10001);
SQL> INSERT INTO employees (employee_id,last_name,email,hire_date,job_id,salary)
1  VALUES (999,'Green','BGREEN',SYSDATE,'ST_CLERK',20000);
.
.
.
ERROR at line 1:
ORA-02290: check constraint (HR.MAX_EMP_SAL) violated

1つの列に、定義された列を参照する複数のチェック制約を設定できます。たとえば、salary列には、10000より大きい値を禁止する1つの制約と、500未満の値を禁止する別の制約を設定できます。

単一の列に対して複数のチェック制約が存在する場合は、その目的が競合しないように設計する必要があります。また、条件は特定の順序では評価されません。データベースでは、チェック条件が矛盾しないかどうかは検証されません。

関連項目:
チェック制約の制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

整合性制約の状態

制約定義の一部として、Oracle Databaseがいつどのようにして制約を規定するかを指定できます。これにより、制約状態が決定します。

変更されたデータおよび既存のデータのチェック

データベースでは、制約が既存のデータまたは将来のデータに適用されるかどうかを指定できます。制約が使用可能である場合、データベースは、入力または更新の時点での新規データをチェックします。制約に準拠しないデータをデータベースに入力することはできません。たとえば、employees.department_idに対してNOT NULL制約を使用可能にすると、将来のすべての行が部門IDを持ちます。制約が使用禁止である場合、表には制約に違反する行を入力できます。

既存のデータを検証する(VALIDATE)または検証しない(NOVALIDATE)ように制約を設定できます。VALIDATEを指定すると、既存のデータが制約に準拠している必要があります。たとえば、employees.department_idに対してNOT NULL制約を使用可能にし、この制約をVALIDATEに設定すると、既存のすべての行が部門IDを持つことをチェックできます。NOVALIDATEを指定すると、既存のデータは制約に準拠する必要はありません。

VALIDATEおよびNOVALIDATEの動作は、常に、制約が使用可能であるか使用禁止であるかどうかによって異なります。表5-4に、その関係の概要を示します。

表5-4 変更されたデータおよび既存のデータのチェック

変更されたデータ

既存のデータ

概要

ENABLE

VALIDATE

既存のデータと将来のデータは制約に準拠する必要があります。データが入力されている表に新しい制約を適用しようとすると、既存の行がその制約に違反する場合、エラーになります。

ENABLE

NOVALIDATE

データベースは制約をチェックしますが、制約はすべての行に関してTRUEである必要はありません。このため、既存の行が制約に違反している可能性はありますが、新しい行または変更された行は規則に準拠する必要があります。

DISABLE

VALIDATE

データベースでは制約が使用禁止になり、索引が削除されて、制約の対象となる列への変更が禁止されます。

DISABLE

NOVALIDATE

制約はチェックされず、TRUEでなくてもかまいません。

関連項目:
制約の状態の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

遅延可能制約

あらゆる制約は、遅延不可状態(デフォルト)または遅延可能状態のいずれかにあります。この状態によって、Oracle Databaseが妥当性を確認するためにどの時点で制約をチェックするかが決まります。次の図は、遅延可能制約のオプションを示します。

遅延不可制約

制約が遅延不可である場合、Oracle Databaseは、制約の妥当性チェックをトランザクションの最後まで遅延することはありません。かわりに、データベースでは各文の最後で制約をチェックします。制約に違反している場合、その文はロールバックします。

たとえば、employees.last_name列用に遅延不可のNOT NULL制約を作成するとします。ユーザーが姓のない行を挿入しようとすると、NOT NULL制約に違反しているため、データベースはただちに文をロールバックします。行は挿入されません。

遅延可能制約

遅延可能制約を使用すると、トランザクションでSET CONSTRAINT句を使用して、COMMIT文が発行されるまでこの制約のチェックを遅延させることができます。制約に違反している可能性があるデータベースを変更する場合、この設定により、すべての変更が完了するまで制約を事実上無効にすることができます。

データベースが遅延可能制約をチェックする時点に関して、デフォルト動作を設定できます。次のいずれかの属性を指定できます。

- INITIALLY IMMEDIATE
データベースは、各文の実行直後に制約をチェックします。制約に違反している場合、データベースは文をロールバックします。

- INITIALLY DEFERRED
データベースは、COMMITが発行された時点で制約をチェックします。制約に違反している場合、データベースはトランザクションをロールバックします。

employees.last_nameに対する遅延可能なNOT NULL制約がINITIALLY DEFERREDに設定されているとします。ユーザーは100個のINSERT文を含むトランザクションを作成し、その一部にはlast_nameとしてNULL値があります。ユーザーがコミットしようとすると、データベースは100個すべての文をロールバックします。ただし、この制約がINITIALLY IMMEDIATEに設定されている場合、データベースはトランザクションをロールバックしません。

制約によってアクションが発生する場合は、遅延制約か即時制約かに関係なく、このアクションはアクションを発生させた文の一部とみなされます。たとえば、departmentsの行を削除すると、削除された部門の行を参照するemployeesのすべての行が削除されます。この場合、employeesからの削除は、departmentsに対して実行されたDELETE文の一部とみなされます。

関連項目:
制約属性とそのデフォルト値の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

制約チェックの例

Oracle Databaseが制約のチェックをどの時点で実行するかを説明するため、いくつかの例を示します。この例では、次のような状況を想定します。

- 図5-2に、employees表の構造を示します。

- 自己参照型制約によって、manager_id列のエントリがemployee_id列の値に依存しています。

親キー値が存在しない時点での外部キー列での値の挿入

employees表に最初の行を挿入する場合を考えます。現在は行が存在しないため、manager_id列の値がemployee_id列の既存の値を参照できない場合に行を入力する方法を考えなくてはなりません。次の方法が考えられます。

- manager_id列にNOT NULL制約が定義されていない場合には、第1行のmanager_id列にNULLを入力できます。
外部キーにはNULLが許されるため、この行は表に挿入されます。

- 同じ値をemployee_id列およびmanager_id列に入力できます。これにより、その従業員が管理職であることを示します。
このことから、Oracle Databaseが文の実行完了後に制約チェックを実行することがわかります。親キーと外部キーに同じ値を指定した行の入力を許可するために、データベースは、文を実行(つまり、新しい行を挿入)してから、その新しい行のmanager_idに対応するemployee_idのある行がその表に含まれているかどうかをチェックします。

- SELECT文のネストを伴うINSERT文など、複数行を挿入するINSERT文により、相互に参照しあう行を挿入できます。
たとえば、第1行には従業員IDとして200、管理職IDとして300が含まれており、第2行には従業員IDとして300、管理職IDとして200が含まれているとします。制約チェックは文の実行が完了するまで遅延されています。すべての行が挿入されてから、制約違反がないかどうかすべての行が調べられます。

デフォルト値は、文の解析前にINSERT文の一部として組み込まれます。このため、デフォルトの列値はすべての整合性制約チェックの対象になります。

すべての外部キー値および親キー値の更新

同じ自己参照型の整合性制約に関して、別の使用例を考えます。会社が買収された場合です。この買収に伴い、すべての従業員番号の現在の設定値に5000を加算して、新しい会社の従業員番号と調和させる必要があります。管理職番号は実際には従業員番号であるため、管理職番号にも5000を加算する必要があります(図5-3を参照)。

図5-3 更新前のemployees表

次のSQL文を実行すると値を更新できます。

UPDATE employees SET employee_id = employee_id + 5000,
manager_id = manager_id + 5000;

制約は、各manager_id値がemployee_id値と一致するかどうかを検証するように定義されていますが、データベースでは文の完了後に制約チェックが効率的に実行されるため、前述の文は有効です。図5-4に、データベースでは、制約をチェックする前に、SQL文全体のアクションが実行されることを示します。

図5-4 制約チェック

この項の例は、INSERT文とUPDATE文を実行した場合の制約チェックのメカニズムを示していますが、データベースでは同じメカニズムがすべてのタイプのDML文に使用されます。同じメカニズムが、自己参照型制約のみでなく、すべてのタイプの制約に使用されます。

注意:
ビューまたはシノニムに対する操作は、実表に定義されている整合性制約に従います。

6 データ・ディクショナリと動的パフォーマンス・ビュー

この章では、データ・ディクショナリと呼ばれる、各Oracle Databaseの読取り専用の参照表とビューの中核的なセットについて説明します。また、この章では、データベースがオープンされ、使用されている間に継続的に更新される特別な動的パフォーマンス・ビューについても説明します。

この章の内容は、次のとおりです。

- データ・ディクショナリの概要

- 動的パフォーマンス・ビューの概要

- データベース・オブジェクト・メタデータ

データ・ディクショナリの概要

データ・ディクショナリはOracle Databaseの重要な部分であり、データベースに関する管理メタデータを提供する読取り専用の表の集合です。データ・ディクショナリには次のような情報が含まれています。

- 列のデフォルト値、整合性制約情報など、データベース内の各スキーマ・オブジェクトの定義

- スキーマ・オブジェクトに割り当てられている領域、およびスキーマ・オブジェクトによって現在使用されている領域の容量

- Oracle Databaseユーザーの名前、ユーザーに付与された権限とロール、およびユーザーに関連する監査情報(「ユーザー・アカウント」を参照)

データ・ディクショナリは、すべてのOracle Databaseでデータ管理の中心的な部分となります。たとえば、データベースでは次のアクションを実行します。

- ユーザー、スキーマ・オブジェクトおよび記憶域構造に関する情報を検索するために、データ・ディクショナリにアクセスします。

- DDL文が発行されるたびに、データ・ディクショナリを変更します(「データ定義言語(DDL)文」を参照)。

Oracle Databaseでは、データ・ディクショナリのデータは、他のデータと同様に表に格納されるため、ユーザーはSQLを使用してデータの問合せを実行できます。たとえば、ユーザーは自分の権限、自分のスキーマに存在する表、自分の表に存在する列、これらの列に対して索引が構築されているかどうかなどを判断するために、SELECT文を実行できます。

関連項目:
「スキーマ・オブジェクトの概要」

データ・ディクショナリの内容

データ・ディクショナリは、次のタイプのオブジェクトで構成されています。

- 実表
データベースに関する情報を格納する、基礎となる表です。これらの表に読取り/書込みできるのはOracle Databaseのみです。これらの表は正規化され、データのほとんどは、暗号形式で格納されているため、ユーザーが直接アクセスすることはほとんどありません。

- ビュー
これらのビューは、実表にあるデータを、ユーザー名や表の名前などの実用的な情報にデコードし、結合とWHERE句を使用して情報を簡略化します。これらのビューには、データ・ディクショナリ内のすべてのオブジェクトの名前と説明が含まれています。すべてのユーザーがアクセスできるビューもいくつかありますが、その他のビューは管理者のみが使用するように設計されています。

一般的に、データ・ディクショナリはセットとしてグループ化されています。多くの場合、表6-1で示すように、そのセットは、類似した情報が格納されている3つのビューで構成され、それぞれが接頭辞によって区別されます。適切なビューに問合せを発行すると、自分に関係のある情報にのみアクセスできます。

表6-1 データ・ディクショナリ・ビューのセット

接頭辞

ユーザー・アクセス

内容

注意

DBA_

データベース管理者

すべてのオブジェクト

一部のDBA_ビューには、管理者にとって有用な情報を含む列が追加されています。

ALL_

すべてのユーザー

ユーザーが権限を持つオブジェクト

ユーザーが所有するオブジェクトが含まれています。これらのビューは有効化されている現在の一連のロールに従います。

USER_

すべてのユーザー

ユーザーによって所有されているオブジェクト

接頭辞がUSER_のビューには、通常、列OWNERは含まれません。この列は、問合せを発行するユーザーとして、USER_ビューに暗黙的に含まれています。

ビュー・セットには必ずしも3つのメンバーが含まれるわけではありません。たとえば、データ・ディクショナリにはDBA_LOCKビューはありますが、ALL_LOCKビューはありません。

システムによって提供されているDICTIONARYビューには、すべてのデータ・ディクショナリ・ビューの名前と短い説明が含まれています。次に、このビューに対する問合せと出力サンプルの一部を示します。

SQL> SELECT * FROM DICTIONARY
2  ORDER BY TABLE_NAME;

TABLE_NAME                     COMMENTS
------------------------------ ----------------------------------------
ALL_ALL_TABLES                 Description of all object and relational
tables accessible to the user

ALL_APPLY                      Details about each apply process that
dequeues from the queue visible to the
current user
.
.
.

関連項目:

- データ・ディクショナリ・ビューとその列の完全なリストは、『Oracle Databaseリファレンス』を参照してください。

- 「ビューの概要」

接頭辞がDBA_のビュー

接頭辞がDBA_のビューには、データベース全体の関連情報がすべて表示されます。DBA_ビューは、管理者のみが使用するように設計されています。

たとえば、次の問合せは、データベース内のすべてのオブジェクトに関する情報を表示します。

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE
FROM   DBA_OBJECTS
ORDER BY OWNER, OBJECT_NAME;

関連項目:
管理権限の詳細は、『Oracle Database管理者ガイド』を参照してください。

接頭辞がALL_のビュー

接頭辞がALL_のビューは、ユーザーのデータベース全体の概要を参照します。これらのビューは、ユーザーが所有しているスキーマ・オブジェクトに加えて、権限とロールのPUBLICへの付与や明示的な付与によってそのユーザーがアクセスできるようになったスキーマ・オブジェクトに関する情報を戻します。

たとえば次の問合せは、アクセス権を持っているすべてのオブジェクトに関する情報を戻します。

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE
FROM   ALL_OBJECTS
ORDER BY OWNER, OBJECT_NAME;

ALL_ビューは有効化されているロールの現在のセットに従うため、問合せの結果は、次に示す例のように、どのロールが有効化されているかによって異なります。

SQL> SET ROLE ALL;

Role set.

SQL> SELECT COUNT(*) FROM ALL_OBJECTS;

COUNT(*)
----------
68295

SQL> SET ROLE NONE;

Role set.

SQL> SELECT COUNT(*) FROM ALL_OBJECTS;

COUNT(*)
----------
53771

ストアド・プロシージャはロールがデフォルトで有効化されていないため、ここでALL_ビューを使用する場合、アプリケーション開発者はロールが及ぼす影響について認識しておく必要があります。

関連項目:
「PL/SQLサブプログラム」

接頭辞がUSER_のビュー

通常のデータベース・ユーザーが最も頻繁に使用するのは、接頭辞がUSER_のビューです。これらのビューには、次のような特長があります。

- ユーザーが作成したスキーマ・オブジェクトやユーザーによる権限付与に関するメタデータなど、ユーザーのプライベートなデータベース環境を参照します。

- ユーザーに関係する行のみを表示し、ALL_ビューにある情報のサブセットを戻します。

- 列OWNERが暗黙的に想定されることを除いて、他のビューと同一の列を持っています。

- 使用しやすいように短縮したPUBLICシノニムを持つことができます。

たとえば、次の問合せは、自分のスキーマに入っているすべてのオブジェクトを戻します。

SELECT OBJECT_NAME, OBJECT_TYPE
FROM   USER_OBJECTS
ORDER BY OBJECT_NAME;

DUAL表

DUAL表は、既知の結果を保証するために、Oracle Databaseとユーザー作成のプログラムによって参照されるデータ・ディクショナリ内の小さな表です。DUAL表は、現在の日時など、値を1回のみ戻す必要がある場合に役立ちます。DUALにはすべてのデータベース・ユーザーがアクセスできます。

DUAL表にはDUMMYという1つの列と、値Xを格納する1つの行があります。次の例では、算術演算を行うためにDUAL表に対する問合せを発行しています。

SQL> SELECT ((3*4)+5)/3 FROM DUAL;

((3*4)+5)/3
-----------
5.66666667

関連項目:
DUAL表の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

データ・ディクショナリの記憶域

データ・ディクショナリの実表は、あらゆるOracle Databaseで最初に作成されるオブジェクトです。データベースのデータ・ディクショナリ表およびビューは、すべてSYSTEM表領域に格納されます。SYSTEM表領域は、データベースのオープン中、常にオンラインであるため、データベースのオープン中、データ・ディクショナリは常に使用可能です。

関連項目:
SYSTEM表領域の詳細は、「SYSTEM表領域」を参照してください。

Oracle Databaseでのデータ・ディクショナリの使用方法

データ・ディクショナリのすべての実表とユーザー・アクセス可能ビューは、Oracle DatabaseユーザーSYSが所有しています。データ・ディクショナリの実表内のデータは、Oracle Databaseを機能させるために必要です。このため、データ・ディクショナリの情報はOracle Databaseによってのみ書込みまたは変更される必要があります。したがって、データ整合性が損われることがあるため、Oracle DatabaseのユーザーはSYSスキーマに含まれている行またはスキーマ・オブジェクトを変更できません。セキュリティ管理者は、この重要なアカウントを厳しく管理し続ける必要があります。

注意:

データ・ディクショナリ表のデータを変更したり操作すると、データベースの操作に永続的な悪影響を与えるおそれがあります。

データベースの操作時に、Oracle Databaseはデータ・ディクショナリを読み取って、スキーマ・オブジェクトが存在すること、およびユーザーのアクセス権が適切に付与されていることを確認します。また、Oracle Databaseは、データベース構造、監査、権限付与およびデータの変更を反映するために、継続的にデータ・ディクショナリを更新します。

たとえば、ユーザーhrがinternsという表を作成すると、新しい表、列、セグメント、エクステントおよびhrがその表に対して持っている権限を反映するために、新しい行がデータ・ディクショナリに追加されます。この新しい情報は、次回ディクショナリ・ビューを問い合せるときに表示されます。

関連項目:
「SYSスキーマとSYSTEMスキーマ」

データ・ディクショナリ・ビューのパブリック・シノニム

多くのデータ・ディクショナリ・ビューにユーザーが簡単にアクセスできるようにするため、Oracle Databaseはパブリック・シノニムを作成します。セキュリティ管理者は、システム全体で使用するスキーマ・オブジェクトのパブリック・シノニムを作成して追加することもできます。ユーザーは、パブリック・シノニムに使用されているのと同じ名前を、自分のスキーマ・オブジェクトに付けないようにする必要があります。

関連項目:
「シノニムの概要」

高速アクセスのためのデータ・ディクショナリのキャッシュ

データ・ディクショナリの情報の多くは、データ・ディクショナリ・キャッシュに含まれており、これは、ユーザーのアクセスの妥当性のチェックや、スキーマ・オブジェクトの状態検証のため、データベースで常にこれらの情報が必要とされるためです。通常、キャッシュに保持されるのは、解析情報です。表とそれらの列について記述しているCOMMENTS列は、ディクショナリ・キャッシュには保持されませんが、データベース・バッファ・キャッシュに保持されることがあります。

関連項目:
「データ・ディクショナリ・キャッシュ」

他のプログラムとデータ・ディクショナリ

他のOracle Database製品は、既存のビューを参照したり、独自のデータ・ディクショナリ表またはビューを追加できます。データ・ディクショナリを参照するプログラムを記述するアプリケーション開発者は、基礎となる表ではなくパブリック・シノニムを参照する必要があります。これは、シノニムの方がリリース間での変更が少ないためです。

動的パフォーマンス・ビューの概要

Oracle Databaseは、操作中ずっと、カレント・データベース・アクティビティを記録する一連の仮想表を保持しています。これらのビューは、データベースがオープンされ、使用中である間、継続的に更新されるため、動的パフォーマンス・ビューと呼ばれます。これらのビュー(場合によってはV$ビューとも呼ばれます)には、次のような情報が含まれています。

- システムおよびセッション・パラメータ

- メモリー使用量および割当て

- ファイルの状態(RMANバックアップ・ファイルなど)

- ジョブおよびタスクの進行状況

- SQLの実行

- 統計およびメトリック

動的パフォーマンス・ビューの主な用途は、次のとおりです。

- Oracle Enterprise Managerでは、データベースに関する情報を取得するためにこのビューを使用します(「Oracle Enterprise Manager」を参照)。

- 管理者はこのビューを使用して、パフォーマンスを監視し、デバッグを実行できます。

関連項目:
動的パフォーマンス・ビューの完全なリストは、『Oracle Databaseリファレンス』を参照してください。

動的パフォーマンス・ビューの内容

動的パフォーマンス・ビューは、データベース管理者が変更または削除できないため、固定ビューと呼ばれることもあります。しかし、データベース管理者は、これらの表のビューに問合せを発行したり、ビューを作成したり、それらのビューにアクセスする権限を他のユーザーに付与できます。

動的パフォーマンス表はSYSが所有し、その名前はV_$で始まります。これらの表に対してビューが作成され、V$という接頭辞を持つパブリック・シノニムが作成されます。たとえば、V$DATAFILEビューにはデータファイルに関する情報が格納されます。V$FIXED_TABLEビューにはすべての動的パフォーマンス表およびビューに関する情報が格納されます。

ほとんどのV$ビューに対して、対応するGV$ビューが存在します。Oracle Real Application Clusters(Oracle RAC)では、GV$ビューに対して問合せを発行すると、すべての修飾データベース・インスタンスからのV$ビュー情報が戻されます(「データベース・サーバー・グリッド」を参照)。

Database Configuration Assistant(DBCA)を使用してデータベースを作成する場合は、データ・ディクショナリがOracleによって自動的に作成されます。Oracle Databaseでは、自動的にcatalog.sqlスクリプトが実行され、このスクリプトには、その動的パフォーマンス・ビューの、ビューおよびパブリック・シノニムの定義が含まれます。これらのビューとシノニムを作成するには、catalog.sqlを実行する必要があります。

関連項目:

- DBCAの詳細は、「データベースのインストールおよび構成ツール」を参照してください。

- catalog.sqlを手動で実行する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle RACでパフォーマンス・ビューを使用する方法の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

動的パフォーマンス・ビューの記憶域

動的パフォーマンス・ビューは、データベースのメモリー構造から構築された仮想表に基づいています。このため、これらのビューはデータベース内に格納される従来型の表ではありません。これらのビューではデータが動的に更新されるため、読取り一貫性は保証されません。

動的パフォーマンス・ビューは実際の表ではないため、データはデータベースおよびインスタンスの状態によって異なります。たとえば、データベースが起動されており、マウントされていないとき、V$INSTANCEおよびV$BGPROCESSに対する問合せを発行できます。ただし、データベースがマウントされるまでは、V$DATAFILEに対する問合せは発行できません。

関連項目:
第9章「データの同時実行性と整合性」

データベース・オブジェクト・メタデータ

DBMS_METADATAパッケージには、データベース・オブジェクトの完全な定義を抽出するためのインタフェースが用意されています。これらの定義は、XMLまたはSQL DDLのいずれかで表現されます。柔軟で洗練された、プログラム制御用のインタフェースと、単純化された、非定型問合せ用のインタフェースの2つのスタイルのインタフェースがあります。

関連項目:
DBMS_METADATAの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

第II部

Oracleデータ・アクセス

この部の構成は、次のとおりです。

- 第7章「SQL」

- 第8章「サーバー側プログラミング: PL/SQLとJava」

7 SQL

この章では、Structured Query Language(SQL)の概要およびOracle DatabaseによるSQL文の処理方法について説明します。

この章の内容は、次のとおりです。

- SQLの概要

- SQL文の概要

- オプティマイザの概要

- SQL処理の概要

SQLの概要

SQL(「シーキューエル」と読みます)は、すべてのプログラムおよびユーザーがOracleデータベースのデータへアクセスする際に使用する、セットベースの高度な宣言型コンピュータ言語です。 いくつかのOracleツールおよびアプリケーションでは、SQLの使用はマスクされていますが、すべてのデータベース操作はSQLを使用して実行されます。その他のデータ・アクセス方法を使用すると、Oracle Databaseに組み込まれているセキュリティが活用されず、データのセキュリティと整合性が損われる可能性があります。

SQLはOracle Databaseなどのリレーショナル・データベースに対するインタフェースを提供します。SQLでは、次のようなタスクを1つの一貫した言語に統合します。

- オブジェクトの作成、置換、変更および削除

- 表の行の挿入、更新および削除

- データの問合せ

- データベースおよびそのオブジェクトへのアクセスの制御

- データベースの整合性と一貫性の保証

SQLは対話的に使用できます(つまり、文を手動でプログラムに入力できます)。SQL文はCまたはJavaなどの異なる言語で記述されたプログラム内に埋め込むこともできます。

関連項目:

- SQLの概要は、『Oracle Database SQL言語リファレンス』を参照してください。

- 「サーバー側プログラミングの概要」および「クライアント側のデータベース・プログラミング」

SQLデータ・アクセス

コンピュータ言語には大きく分けて2つの種類があり、1つは実行目的を表す非手続き型の宣言型言語、もう1つは処理の実行経緯を表すC++およびJavaなどの手続き型言語です。SQLは、ユーザーが結果の導出方法ではなく目的とする結果を指定するという意味において、宣言型です。SQL言語コンパイラが手続きを生成する作業を実行し、データベースに指示して目的のタスクを実行します。

SQLを使用すると、論理レベルでデータを操作できます。実装の詳細は、データを操作する場合にのみ、考慮する必要があります。たとえば、次の文を使用すると、姓がKで始まる従業員のレコードを問い合せることができます。

SELECT   last_name, first_name
FROM     hr.employees
WHERE    last_name LIKE 'K%'
ORDER BY last_name, first_name;

データベースはWHERE条件(述語とも呼ばれる)を満たすすべての行を1つの手順で取得します。これらの行は1つの単位としてユーザー、別のSQL文またはアプリケーションに渡すことができます。行を1つずつ処理する必要はなく、また、行の物理的な格納方法または取得方法を認識する必要もありません。

すべてのSQL文でオプティマイザ(指定されたデータへの最も効率的なアクセス手段を決定するOracle Databaseの機能)が使用されます。Oracle Databaseでは、オプティマイザにジョブを適切に実行させるための技術もサポートされています。

関連項目:
SQL文およびSQLのその他の部分(演算子、関数、書式モデルなど)の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

SQL規格

オラクル社は業界で承認されている標準への準拠に努め、SQLの規格協会に積極的に参加しています。業界が認可している協会として、米国規格協会(ANSI)および国際標準化機構(ISO)があります。ANSIおよびISO/IECはいずれも、リレーショナル・データベースの標準言語としてSQLを認可しています。

最新のSQL規格は2003年7月に採用され、一般的にSQL:2003と呼ばれています。SQL規格の一部であるPart 14: SQL/XML(ISO/IEC 9075-14)は2006年に改訂されており、一般的にはSQL/XML:2006と呼ばれています。

Oracle SQLには、ANSI/ISO標準SQL言語に対応する多くの拡張機能が組み込まれており、Oracle Databaseのツール製品とアプリケーションを使用することで、文を追加できます。SQL*Plus、SQL DeveloperおよびOracle Enterprise Managerなどのツールを使用すると、Oracle Databaseに対してANSI/ISO標準のSQL文を実行でき、さらにこれらのツール製品で使用可能な追加の文や機能を実行できます。

関連項目:

- Oracle SQLと標準SQLの相違点の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- SQL文との区別など、SQL*Plusコマンドの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

- 「データベース管理者向けのツール」および「データベース開発者向けのツール」

SQL文の概要

Oracle Database内の情報に対するすべての操作は、SQL文を使用して実行します。SQL文は識別子、パラメータ、変数、名前、データ型およびSQL予約語で構成されるコンピュータ・プログラムまたは命令です。

注意:
SQL予約語は、SQLで特別な意味を持ち、他の目的には使用できません。たとえば、SELECTとUPDATEは予約語のため、表名には使用できません。

SQL文は、完全なSQL文と等価であることが必要です。次に例を示します。

SELECT last_name, department_id FROM employees

Oracle Databaseでは、完全なSQL文のみが実行されます。次のような不完全文を実行しようとすると、テキストの不足を示すエラーが発生します。

SELECT last_name;

Oracle SQL文は、次のカテゴリに分類されます。

- データ定義言語(DDL)文

- データ操作言語(DML)文

- トランザクション制御文

- セッション制御文

- システム制御文

- 埋込みSQL文

データ定義言語(DDL)文

データ定義言語(DDL)文は、スキーマ・オブジェクトに対し、定義、構造の変更および削除を実行します。たとえば、DDL文で次の操作を実行できます。

- スキーマ・オブジェクトと他のデータベース構造(データベースとデータベース・ユーザーを含む)を作成、変更および削除します。ほとんどのDDL文はCREATE、ALTERまたはDROPのキーワードで始まります。

- スキーマ・オブジェクトの構造を削除することなく、それらのオブジェクトの中のすべてのデータを削除します(TRUNCATE)。

注意:
DELETEとは異なり、TRUNCATEはUNDOデータを生成しないため、DELETEよりも処理が速くなります。また、TRUNCATEは削除のトリガーを起動しません。

- 権限とロールを付与および取り消します(GRANT、REVOKE)。

- 監査オプションをオンまたはオフに切り換えます(AUDIT、NOAUDIT)。

- データ・ディクショナリにコメントを追加します(COMMENT)。

DDLを使用すると、オブジェクトにアクセスするアプリケーションを変更することなく、オブジェクトの属性を変更できます。たとえば、アプリケーションをリライトせずに、人事管理アプリケーションからアクセスする表に列を追加できます。また、DDLを使用して、データベース・ユーザーがデータベース内で作業を実行している間に、オブジェクトの構造を変更することもできます。

例7-1では、DDL文を使用してplants表を作成した後、DMLを使用して表に2つの行を挿入します。次に、DDLを使用して表構造を変更し、この表に対するユーザーの権限を付与および取り消してから、表を削除します。

例7-1 DDL文

CREATE TABLE plants
( plant_id    NUMBER PRIMARY KEY,
common_name VARCHAR2(15) );

INSERT INTO plants VALUES (1, 'African Violet'); # DML statement

INSERT INTO plants VALUES (2, 'Amaryllis'); # DML statement

ALTER TABLE plants ADD
( latin_name VARCHAR2(40) );

GRANT SELECT ON plants TO scott;

REVOKE SELECT ON plants FROM scott;

DROP TABLE plants;

データベースがDDL文を実行する直前に暗黙的なCOMMITが行われ、直後にCOMMITまたはROLLBACKが行われます。例7-1では、2つのINSERT文の後にALTER TABLE文が続くため、データベースによって2つのINSERT文がコミットされます。ALTER TABLE文が成功した場合は、この文はデータベースによってコミットされ、失敗した場合は、この文はデータベースによってロールバックされます。いずれの場合も、2つのINSERT文はすでにコミットされています。

関連項目:

- 権限およびロールの詳細は、「データベース・セキュリティの概要」を参照してください。

- スキーマ・オブジェクトの作成方法の詳細は、『Oracle Database 2日で開発者ガイド』および『Oracle Database管理者ガイド』を参照してください。

- DDL文のリストは、『Oracle Database SQL言語リファレンス』を参照してください。

データ操作言語(DML)文

データ操作言語(DML)文は、既存のスキーマ・オブジェクト内のデータの問合せや操作を実行します。DDL文ではデータベースの構造を変更できるのに対して、DML文では内容の問合せまたは変更が可能です。たとえば、ALTER TABLEは表の構造を変更するのに対して、INSERTは1つ以上の行を表に追加します。

DML文は、最も頻繁に使用するSQL文であり、次の操作を実行できます。

- 1つ以上の表またはビューからデータの取出しまたはフェッチを行います(SELECT)。

- 列値のリストを指定するか、既存のデータを選択および操作する副問合せを使用して、表またはビューに新しいデータ行を追加します(INSERT)。

- 表またはビューの既存の行の列値を変更します(UPDATE)。

- 行の更新または、条件付きで表またはビューに行の挿入を行います(MERGE)。

- 表またはビューから行を削除します(DELETE)。

- SQL文の実行計画を表示します(EXPLAIN PLAN)。「Oracle DatabaseによるDML処理方法」を参照してください。

- 表またはビューをロックして、一時的に他のユーザーのアクセスを制限します(LOCK TABLE)。

次の例では、DMLを使用してemployees表に問い合せます。例では、DMLを使用してemployeesに行を挿入し、この行を更新した後、行を削除します。

SELECT * FROM employees;

INSERT INTO employees (employee_id, last_name, email, job_id, hire_date, salary)
VALUES (1234, 'Mascis', 'JMASCIS', 'IT_PROG', '14-FEB-2011', 9000);

UPDATE employees SET salary=9100 WHERE employee_id=1234;

DELETE FROM employees WHERE employee_id=1234;

論理作業単位を形成するDML文のコレクションは、トランザクションと呼ばれます。たとえば、預金を振り替えるトランザクションは、普通預金口座の残高の減額、当座預金口座の残高の増額および預金口座履歴表への振替えの記録という3つの別々の操作を伴います。DDL文とは異なり、DML文は現行のトランザクションを暗黙的にコミットしません。

関連項目:

- 「トランザクションの概要」

- データの問合せおよび操作方法の詳細は、『Oracle Database 2日で開発者ガイド』を参照してください。

- DML文のリストは、『Oracle Database SQL言語リファレンス』を参照してください。

SELECT文

問合せは、表またはビューからデータを取得する操作です。SELECTはデータの問合せに使用できる唯一のSQL文です。SELECT文の実行から取得した一連のデータは結果セットと呼ばれます。

表7-1に、SELECT文で一般的に使用される2つの必須キーワードおよび2つのキーワードを示します。また、表では、キーワードとSELECT文の機能を関連付けています。

表7-1 SQL文のキーワード

キーワード

必須

説明

機能

SELECT

はい

結果に表示される列を指定します。投影により、表内の列のサブセットが作成されます。

式は1つ以上の値、演算子、および値を評価するSQL機能の組合せです。SELECTキーワードの後かつFROM句の前に置かれる式のリストはSELECT構文のリストと呼ばれます。

投影

FROM

はい

データの取得元の表またはビューを指定します。

結合

WHERE

いいえ

条件を指定して行をフィルタ処理し、表内の行のサブセットを作成します。条件は、1つ以上の式および論理(ブール)演算子の組合せを指定し、TRUE、FALSEまたはUNKNOWNの値を戻します。

選択

ORDER BY

いいえ

行の表示順序を指定します。

関連項目:
SELECTの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

結合

結合は2つ以上の表、ビューまたはマテリアライズド・ビューからの行を組み合せる問合せです。例7-2は、employees表およびdepartments表を結合して(FROM句)、指定した条件に一致する行のみを選択し(WHERE句)、投影を使用して2つの列からデータを取得します(SELECT)。SQL文の後にサンプルの出力を示しています。

例7-2 結合のサンプル

SELECT email, department_name
FROM   employees JOIN departments
ON     employees.department_id = departments.department_id
WHERE  employee_id IN (100,103)
ORDER BY email;

EMAIL                     DEPARTMENT_NAME
------------------------- ------------------------------
AHUNOLD                   IT
SKING                     Executive

図7-1に、例7-2の結合で示した投影および選択の操作を視覚的に表します。

図7-1 投影と選択

ほとんどの結合には、FROM句またはWHERE句のいずれかに1つ以上の結合条件があり、それぞれ異なる表の2つの列をこの条件によって比較します。データベースでは1対の行を組み合せ、それぞれの対には、結合条件がTRUEになる各表の行を1行ずつ含みます。オプティマイザは結合条件、索引、および表に使用できる任意の統計に基づいて、データベースが表を結合する順序を決定します。

結合タイプは次のとおりです。

- 内部結合
内部結合は、結合条件を満たす行のみを戻す2つ以上の表の結合です。たとえば、結合条件がemployees.department_id=departments.department_idの場合、この条件を満たさない行は戻されません。

- 外部結合
外部結合は結合条件を満たすすべての行を戻すとともに、一方の表からは、他方の表の条件を満たさない行に対応する行も戻します。たとえば、employeesおよびdepartmentsの左側外部結合では、departmentsに一致する行がない場合でも、employees表のすべての行を取得します。右側外部結合では、employeesに一致する行がない場合でも、departmentsのすべての行を取得します。

- デカルト積
結合問合せ内の2つの表に結合条件がない場合、データベースはデカルト積を戻します。一方の表の各行を他方の表の各行と組み合せます。たとえば、employeesに107行ありdepartmentsには27行ある場合、デカルト積には107*27行が含まれます。デカルト積が便利な場合はほとんどありません。

関連項目:
結合の詳細および例は、『Oracle Database SQL言語リファレンス』を参照してください。

副問合せおよび暗黙的問合せ

副問合せは別のSQL文内にネストされたSELECT文です。副問合せは、1つの問題を解決するために複数の問合せを実行する必要がある場合に便利です。

各文の問合せ部分は問合せブロックと呼ばれます。例7-3では、カッコ内の副問合せが内部問合せブロックです。内部SELECT文により、場所IDが1800の部門のIDが取得されます。これらの部門IDは、副問合せによってIDが戻された部門の従業員名を取得する外部問合せブロックに必要です。

例7-3 副問合せ

SELECT first_name, last_name
FROM   employees
WHERE  department_id
IN     (SELECT department_id FROM departments WHERE location_id = 1800);

このSQL文の構造では、内部問合せを最初に実行することをOracle Databaseに強制しているわけではありません。たとえば、Oracle Databaseにより問合せ全体がemployeesとdepartmentsの結合としてリライトされることもあり、その場合は副問合せ自体が実行されません。また、別の例として、Virtual Private Database(VPD)機能では、WHERE句を使用して従業員の問合せが絞り込まれることがあり、この場合は、Oracle Databaseでは、最初に従業員を問い合せてから部門IDが取得されます。オプティマイザにより、要求された行を取得するための手順の最適な順序が決定されます。

暗黙的問合せは、副問合せを使用せずにデータを取得するDML文のコンポーネントです。SELECT文を明示的に含まないUPDATE、DELETEまたはMERGE文では、暗黙的問合せを使用して変更対象の行を取得します。たとえば、次の文にはBaerレコードの暗黙的問合せが含まれます。

UPDATE employees
SET salary = salary*1.1
WHERE last_name = 'Baer';

問合せコンポーネントを必ずしも含まなくてよいDML文は、VALUES句を伴うINSERT文のみです。たとえば、INSERT INTO TABLE mytable VALUES (1)文では、行を挿入する前に行が取得されることはありません。

関連項目:
「Virtual Private Database (VPD)」

トランザクション制御文

トランザクション制御文は、DML文による変更の内容を管理し、一連のDML文をトランザクションとしてグループ化します。これらの文によって、次のことを実行できます。

- トランザクションの変更を確定します(COMMIT)。

- トランザクションの開始以降(ROLLBACK)またはセーブポイント以降(ROLLBACK TO SAVEPOINT)に実行されたトランザクション内での変更を取り消します。セーブポイントは、トランザクションのコンテキスト内のユーザー宣言による中間マーカーです。

注意:
ROLLBACKコマンドはトランザクションを終了しますが、ROLLBACK TO SAVEPOINTは終了しません。

- ロールバックできるポイントを設定します(SAVEPOINT)。

- トランザクションのプロパティを設定します(SET TRANSACTION)。

- 後に続く各DML文の遅延可能整合性制約をチェックするかどうか、またはトランザクションをコミットするタイミングを指定します(SET CONSTRAINT)。

次の例はUpdate salariesという名前のトランザクションを開始します。例ではセーブポイントを作成し、従業員の給与を更新した後、セーブポイントまでトランザクションをロールバックします。さらに、給与を別の値に更新してコミットします。

SET TRANSACTION NAME 'Update salaries';

SAVEPOINT before_salary_update;

UPDATE employees SET salary=9100 WHERE employee_id=1234 # DML

ROLLBACK TO SAVEPOINT before_salary_update;

UPDATE employees SET salary=9200 WHERE employee_id=1234 # DML

COMMIT COMMENT 'Updated salaries';

関連項目:

- 「トランザクションの概要」

- 「遅延可能制約」

- 『Oracle Database SQL言語リファレンス』

セッション制御文

セッション制御文は、ユーザー・セッションのプロパティを動的に管理します。「接続とセッション」で説明しているように、セッションは、データベースに対する現在のユーザー・ログインの状態を示す、データベース・インスタンス・メモリー内の論理エンティティです。セッションは、ユーザーがデータベースに認証された時点から、ユーザーが接続を切断するか、データベース・アプリケーションを終了する時点まで続きます。

セッション制御文によって、次のことを実行できます。

- SQLトレース機能の使用可能および使用禁止の切換えなど、特化された機能を実行して現行のセッションを変更します(ALTER SESSION)。

- 現行のセッションのロール(権限のグループ)を使用可能または使用禁止にします(SET ROLE)。

次の例では、セッションのSQLトレースをオンにして、dw_manager以外の現行のセッションで付与されているすべてのロールを有効にします。

ALTER SESSION SET SQL_TRACE = TRUE;

SET ROLE ALL EXCEPT dw_manager;

セッション制御文は現行のトランザクションを暗黙的にコミットしません。

関連項目:
ALTER SESSIONの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

システム制御文

システム制御文は、データベース・インスタンスのプロパティを変更します。システム制御文は、ALTER SYSTEMのみです。この文は、設定値(共有サーバーの最小数など)の変更、セッションの終了およびその他のシステム・レベルでのタスクの実行に使用します。

システム制御文の例を次に示します。

ALTER SYSTEM SWITCH LOGFILE;

ALTER SYSTEM KILL SESSION '39, 23';

ALTER SYSTEM文は現行のトランザクションを暗黙的にコミットしません。

関連項目:
ALTER SYSTEMの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

埋込みSQL文

埋込みSQL文は、手続き型言語プログラム内にDDL、DMLおよびトランザクション制御文を取り込みます。これらの文は、Oracleプリコンパイラで使用されます。埋込みSQLは、手続き型言語アプリケーションにSQLを取り込むための1つの方法です。他に、Open Database Connectivity(ODBC)またはJava Database Connectivity(JDBC)などの手続き型APIを使用する方法もあります。

埋込みSQL文によって、次のことを実行できます。

- カーソルの定義、割当ておよび解放を行います(DECLARE CURSOR、OPEN、CLOSE)。

- データベースを指定して、接続します(DECLARE DATABASE、CONNECT)。

- 変数名を割り当てます(DECLARE STATEMENT)。

- 記述子を初期化します(DESCRIBE)。

- エラー条件と警告の処理方法を指定します(WHENEVER)。

- SQL文を解析および実行します(PREPARE、EXECUTE、EXECUTE IMMEDIATE)。

- データベースからデータを取り出します(FETCH)。

関連項目:
「サーバー側プログラミングの概要」および「クライアント側のAPI」

オプティマイザの概要

Oracle DatabaseがSQL文を処理する仕組みを理解するには、データベースのオプティマイザと呼ばれる部分(問合せオプティマイザまたはコストベース・オプティマイザとも呼ばれる)を理解する必要があります。すべてのSQL文でオプティマイザを使用して、指定されたデータへの最も効率的なアクセス手段を決定します。

オプティマイザの使用

DML文を実行するために、Oracle Databaseで多くの処理を必要とする場合があります。各処理では、データベースからデータ行を物理的に検索するか、文を発行したユーザーのためにデータ行を準備します。

多くの場合、DML文の処理には多くの様々な方法を使用できます。たとえば、表または索引のアクセス順序を変更できます。データベースが文を実行するときに使用する手順は、文の実行速度に大きく影響します。オプティマイザは、使用可能な実行方法を表す実行計画を生成します。

オプティマイザは、問合せ条件、使用可能なアクセス・パス、収集された対象システムの統計およびヒントなどの複数の情報ソースを考慮して、最も効率的な実行計画を決定します。Oracleによって処理されるSQL文に対して、オプティマイザは次の操作を実行します。

- 式および条件の評価

- データの詳細を把握し、このメタデータに基づいて最適化するための整合性制約の検査

- 文の変換

- オプティマイザの目的の選択

- アクセス・パスの選択

- 結合順序の選択

オプティマイザは、問合せの処理に使用できる方法の大部分を生成し、生成した実行計画の各手順にコストを割り当てます。コストが最も低い計画が、実行する問合せ計画として選択されます。

注意:
SQL文の実行計画は、その計画を実行しなくても取得できます。データベースが問合せの実行に実際に使用する実行計画は、適切に規定された問合せ計画のみです。

オプティマイザが選択する内容は、オプティマイザの目的を設定して、オプティマイザ用の代表的な統計を収集することにより決まります。たとえば、オプティマイザの目的を次のいずれかに設定できます。

- 合計スループット
結果の最後の行を可能なかぎり迅速にクライアント・アプリケーションに取得するよう、ALL_ROWSヒントがオプティマイザに指示します。

- 初期レスポンス時間
最初の行を可能なかぎり迅速にクライアントに取得するよう、FIRST_ROWSヒントがオプティマイザに指示します。

典型的なエンド・ユーザーの対話型アプリケーションの場合、初期レスポンス時間による最適化が有用であるのに対して、バッチモードの非対話型アプリケーションの場合、合計スループットによる最適化が有用です。

関連項目:

- DBMS_STATSの使用の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

- オプティマイザの詳細およびヒントの使用方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

オプティマイザ・コンポーネント

オプティマイザには、図7-2に示す主要な3つのコンポーネントが含まれます。

図7-2 オプティマイザのコンポーネント

オプティマイザには、解析済の問合せが入力されます(「SQLの解析」を参照)。オプティマイザは、次の操作を実行します。

1. オプティマイザは解析済の問合せを受け取り、使用可能なアクセス・パスおよびヒントに基づいてSQL文に対する一連の計画候補を生成します。

2. オプティマイザはデータ・ディクショナリの統計に基づいて各計画のコストを見積ります。コストとは、特定の計画を使用して文を実行するために必要な、予想されるリソース使用に比例した見積り値です。

3. オプティマイザは各計画のコストを比較し、コストが最も低い計画(問合せ計画と呼ばれる)を選択して、行ソース・ジェネレータに渡します(「SQLの行ソース生成」を参照)。

問合せトランスフォーマ

問合せトランスフォーマは、オプティマイザがより優れた実行計画を生成できるように、問合せの形式を変更することが有用かどうかを判断します。問合せトランスフォーマには、一連の問合せブロックによって表現された解析済の問合せが入力されます。

関連項目:
「クエリー・リライト」

エスティメータ

エスティメータは指定された実行計画の全体コストを判断します。この目的を達成するために、エスティメータは3つの異なる計測タイプを生成します。

- 選択性
この計測タイプは、行セット内の行の一部分を表します。選択性は、問合せの述語(last_name='Smith'など)や述語の組合せに関連します。

- カーディナリティ
この計測タイプは、行セット内の行数を表します。

- コスト
この計測タイプは、使用される作業またはリソースの単位を表します。問合せオプティマイザでは、作業単位としてディスクI/O、CPU使用率およびメモリー使用量を使用します。

統計が使用できる場合、エスティメータは統計を使用して計測値を計算します。統計によって、計測値の精度が向上します。

プラン・ジェネレータ

プラン・ジェネレータは、発行済の問合せに対して複数の異なる計画を試行し、最もコストが低い計画を選択します。オプティマイザは、ネストされた副問合せおよびマージ解除したビューそれぞれ(個別の問合せブロックで表現されている)に対して、サブプランを生成します。プラン・ジェネレータは、異なるアクセス・パス、結合方法および結合順序を試行して、問合せブロックに対する様々な計画を検索します。

オプティマイザは自動的に計画を管理し、検証された計画のみが使用されることを保証します。SQL計画の管理(SPM)では、現在の計画よりも新しい計画の方がより適切に実行されることが検証された場合にかぎり、その新しい計画を使用することによって、計画の更新を制御できます。

EXPLAIN PLAN文などの診断ツールを使用すると、オプティマイザが選択した実行計画を表示できます。EXPLAIN PLANは、指定したSQLの問合せが現行のセッション内で実行された場合の、その問合せに対する問合せ計画を示します。他の診断ツールとして、Oracle Enterprise ManagerおよびSQL*Plus AUTOTRACEコマンドがあります。例7-6に、AUTOTRACEが有効な場合の問合せの実行計画を示します。

関連項目:

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

- EXPLAIN PLANの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- オプティマイザのコンポーネントの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

アクセス・パス

アクセス・パスは、データベースからデータを取得するための方法です。たとえば、索引を使用する問合せは、索引を使用しない問合せとは異なるアクセス・パスになります。通常、表内の行の小規模なサブセットを取得する文には、索引アクセス・パスが最適です。表内の大きな一部分にアクセスするには、全体スキャンがより効率的です。

データベースは、表からデータを取得するために、複数の異なるアクセス・パスを使用できます。代表的なものは次のとおりです。

- 全表スキャン
このタイプのスキャンは、表からすべての行を読み取り、選択基準に合致しない行をフィルタ処理して除外します。データベースは、使用済領域と未使用領域を分離する最高水位標より下のものも含め、セグメント内のすべてのデータ・ブロックを順次スキャンします(「セグメント領域と最高水位標」を参照)。

- ROWIDスキャン
行のROWIDは、そのブロック内の行および行の位置を含むデータファイルおよびデータ・ブロックを指定します。データベースは、最初に文中のWHERE句または索引スキャンのいずれかから選択した行のROWIDを取得し、次にそのROWIDに基づいて選択した各行の位置を特定します。

- 索引スキャン
このスキャンは、SQL文によってアクセスする索引付けされた列値に対応した索引を検索します(「索引スキャン」を参照)。文によって索引の列のみにアクセスする場合、Oracle Databaseは索引付けされた列値を索引から直接読み取ります。

- クラスタ・スキャン
クラスタ・スキャンは、索引付きの表クラスタに格納された表からデータを取得するために使用され、表クラスタでは、同じクラスタ・キー値を持つすべての行が同じデータ・ブロックに格納されています(「索引付きクラスタの概要」を参照)。データベースは最初にクラスタ索引をスキャンして、選択した1つの行のROWIDを取得します。Oracle DatabaseはこのROWIDに基づいて行の位置を特定します。

- ハッシュ・スキャン
ハッシュ・スキャンは、ハッシュ・クラスタ内の行の位置を特定するために使用され、ハッシュ・クラスタ内では、同じハッシュ値を持つすべての行が同じデータ・ブロックに格納されています(「ハッシュ・クラスタの概要」を参照)。データベースは最初に、文によって指定されたクラスタ・キー値にハッシュ関数を適用することにより、ハッシュ値を取得します。次に、Oracle Databaseはこのハッシュ値の行を含むデータ・ブロックをスキャンします。

オプティマイザは、文に対して使用可能なアクセス・パスと、各アクセス・パスまたはパスの組合せの使用時の見積りコストに基づいて、1つのアクセス・パスを選択します。

関連項目:
アクセス・パスの詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

オプティマイザ統計

オプティマイザ統計は、データベースの詳細を記述したデータとデータベース内のオブジェクトのコレクションです。統計は、アクセス・パスを評価する場合にオプティマイザが使用できるデータ記憶域とデータ配分に関する、統計的に正しいピクチャを提示します。

オプティマイザ統計のタイプは次のとおりです。

- 表統計
行数、ブロック数および行の平均長が含まれます。

- 列統計
列内の個々の値とNULLの数およびデータ配分が含まれます。

- 索引統計
リーフ・ブロックおよび索引レベルの数が含まれます。

- システム統計
CPUとI/Oのパフォーマンスおよび使用率が含まれます。

Oracle Databaseは、すべてのデータベース・オブジェクトのオプティマイザ統計を自動的に収集し、これらの統計を自動メンテナンス・タスクとして保持します。また、DBMS_STATSパッケージを使用して、手動で統計を収集することもできます。このPL/SQLパッケージでは、統計を変更、表示、エクスポート、インポートおよび削除できます。

オプティマイザ統計は問合せの最適化を目的として作成され、データ・ディクショナリに格納されます。これらの統計と動的パフォーマンス・ビューを介して表示できるパフォーマンス統計を混同しないでください。

関連項目:

- 統計の収集および管理方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- DBMS_STATSの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

オプティマイザ・ヒント

ヒントは、オプティマイザへの指示として機能するSQL文内のコメントです。特定のアプリケーションのデータについて、オプティマイザよりもさらに詳細な知識を持つアプリケーション設計者の方が、SQL文をより効率的に実行する方法を選択できることもあります。アプリケーション設計者は、SQL文内にヒントを使用して文の実行方法を指定できます。

たとえば、対話型アプリケーションによって、50行を戻す問合せが実行されるとします。このアプリケーションでは、問合せによって戻される最初の25行のみを初めにフェッチしてエンド・ユーザーに表示します。オプティマイザを使用して、最初の25レコードを可能なかぎり迅速に取得する計画を生成し、ユーザーが待たずに済むようにします。この指示をオプティマイザに渡すには、例7-4のSELECT文およびAUTOTRACE出力に示すように、ヒントを使用します。

例7-4 FIRST_ROWSヒントを指定したSELECTの実行計画

SELECT /*+ FIRST_ROWS(25) */ employee_id, department_id
FROM   hr.employees
WHERE  department_id > 50;

------------------------------------------------------------------------
| Id | Operation                    | Name              | Rows | Bytes
------------------------------------------------------------------------
|  0 | SELECT STATEMENT             |                   | 26   | 182
|  1 |  TABLE ACCESS BY INDEX ROWID | EMPLOYEES         | 26   | 182
|* 2 |   INDEX RANGE SCAN           | EMP_DEPARTMENT_IX |      |
------------------------------------------------------------------------

例7-4の実行計画では、オプティマイザがemployees.department_id列の索引を選択して部門IDが50を超えるemployeesの最初の25行を検索しています。オプティマイザは索引から取得したROWIDを使用してemployees表からレコードを取得し、クライアントに戻します。通常、最初のレコードの取得はほとんど即時です。

例7-5に、オプティマイザ・ヒントを指定しない同じ文を示します。

例7-5 ヒントを指定しないSELECTの実行計画

SELECT employee_id, department_id
FROM   hr.employees
WHERE  department_id > 50;

------------------------------------------------------------------------
| Id | Operation              | Name              | Rows | Bytes | Cos
------------------------------------------------------------------------
|  0 | SELECT STATEMENT       |                   | 50   | 350   |
|* 1 |  VIEW                  | index$_join$_001  | 50   | 350   |
|* 2 |   HASH JOIN            |                   |      |       |
|* 3 |    INDEX RANGE SCAN    | EMP_DEPARTMENT_IX | 50   | 350   |
|  4 |    INDEX FAST FULL SCAN| EMP_EMP_ID_PK     | 50   | 350   |

例7-5の実行計画では2つの索引を結合し、可能なかぎり迅速に要求されたレコードを戻します。オプティマイザは、例7-4のように索引から表へと繰り返し移動するのではなく、EMP_DEPARTMENT_IXのレンジ・スキャンを選択して、部門IDが50を超えるすべての行を検索し、ハッシュ表にこれらの行を配置します。オプティマイザは次に、EMP_EMP_ID_PK索引を読み取ることを選択します。この索引の各行について、ハッシュ表を調査して部門IDを検索します。

この場合、EMP_DEPARTMENT_IXの索引レンジ・スキャンが完了するまで、データベースはクライアントに最初の行を戻すことができません。このため、生成されたこの計画では最初のレコードを戻すために、より長い時間がかかります。索引のROWIDによって表にアクセスする例7-4の計画とは異なり、例7-5の計画はマルチブロックI/Oを使用し、読取りの範囲が大きくなります。読取りによって、全結果セットの最後の行をより迅速に戻すことができます。

関連項目:
オプティマイザ・ヒントの使用方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

SQL処理の概要

この項では、Oracle DatabaseによるSQL文の処理の仕組みについて説明します。特に、データベースがDDL文を処理してオブジェクトを作成する仕組み、DMLを使用してデータを変更する仕組み、問合せを使用してデータを取得する仕組みについて説明します。

SQL処理の段階

図7-3は、解析、最適化、行ソース生成および実行というSQL処理の一般的な段階を示しています。文によっては、データベースがこれらの手順の一部を省略する場合があります。

図7-3 SQL処理の段階

SQLの解析

図7-3に示すように、SQL処理の最初の段階は解析です。この段階では、SQL文の各部分を他のルーチンで処理できるデータ構造に分解する処理が行われます。Oracle Databaseは、アプリケーションから指示されたときに文を解析するため、解析回数を削減できるのはアプリケーションのみです(Oracle Database自体ではありません)。

アプリケーションがSQL文を発行すると、アプリケーションはOracle Databaseに解析コールを出して、文の実行を準備します。解析コールによって、解析済のSQL文と処理に使用するその他の情報が保持されるセッション固有のプライベートSQL領域のハンドルであるカーソルがオープンまたは作成されます。カーソルおよびプライベートSQL領域はPGA内にあります。

解析コール時には、データベースでは次のチェックを実行します。

- 構文チェック

- セマンティクス・チェック

- 共有プール・チェック

これらのチェックによって、文の実行前に検出できるエラーを特定します。解析では捕捉できないエラーもあります。たとえば、データベースでは文の実行時にしかデッドロックまたはデータ変換エラーが発生しません(「ロックとデッドロック」を参照)。

構文チェック

Oracle Databaseは各SQL文の構文上の妥当性を必ずチェックします。SQL構文の形式が整っていても、規則に違反している文はチェックが失敗します。たとえば、次の文ではキーワードFROMがFORMという誤ったスペルになっているため、失敗します。

SQL> SELECT * FORM employees;
SELECT * FORM employees
*
ERROR at line 1:
ORA-00923: FROM keyword not found where expected

セマンティクス・チェック

文のセマンティクスとは、文の意味のことです。このため、セマンティクス・チェックでは、文内のオブジェクトおよび列が存在するかどうかなど、文の意味が有効かどうかを判断します。次に示す存在しない表の問合せの例のように、構文的に正しい文でも、セマンティクス・チェックに失敗します。

SQL> SELECT * FROM nonexistent_table;
SELECT * FROM nonexistent_table
*
ERROR at line 1:
ORA-00942: table or view does not exist

共有プール・チェック

解析中、データベースは共有プール・チェックを実行して、文の処理のうちリソース集中型の手順を省略できるかどうかを判断します。これを行うために、データベースはハッシング・アルゴリズムを使用してSQL文ごとにハッシュ値を生成します。文のハッシュ値は、V$SQL.SQL_IDに示されるSQL IDです。

ユーザーがSQL文を発行すると、データベースは共有SQL領域を検索して、既存の解析済の文に同じハッシュ値があるかどうかを確認します。SQL文のハッシュ値は、次の値とは異なります。

- 文のメモリー・アドレス
Oracle Databaseでは、SQL IDをキーとして使用して検索対象の表を読み取ります。これにより、Oracle Databaseは文のメモリー・アドレスを取得します。

- 文の実行計画のハッシュ値
1つのSQL文で、複数の計画を共有プールに設定できます。各計画には、異なるハッシュ値を設定します。同じSQL IDに複数の計画ハッシュ値が設定されていると、Oracle Databaseでは、そのSQL IDに対して複数の計画が存在することが認識されます。

発行される文のタイプとハッシュ・チェックの結果に応じて、解析操作は次のカテゴリに分類されます。

- ハード解析
Oracle Databaseは、既存のコードを再利用できない場合、新しく実行可能なバージョンのアプリケーション・コードを作成する必要があります。この操作はハード解析またはライブラリ・キャッシュ・ミスと呼ばれます。データベースは常にDDLのハード解析を実行します。

ハード解析時には、データベースはライブラリ・キャッシュおよびデータ・ディクショナリ・キャッシュに何度もアクセスして、データ・ディクショナリをチェックします。データベースはこれらの領域にアクセスするとき、定義が変更されないように、必要なオブジェクト上にラッチと呼ばれるシリアライズ・デバイスを使用します(「ラッチ」を参照)。ラッチの競合が発生すると、文の実行時間が長くなり、同時実行性が低下します。

- ソフト解析
ソフト解析は、ハード解析以外のすべての解析です。発行される文が共有プール内の再利用可能なSQL文と同じ場合、Oracle Databaseは既存のコードを再利用します。コードの再利用は、ライブラリ・キャッシュ・ヒットとも呼ばれます。

ソフト解析によって実行される作業の量は、解析ごとに異なる場合があります。たとえば、セッションの共有SQL領域の構成によって、ソフト解析はラッチ量が減少し、よりソフト解析らしくなる場合があります。

データベースが最適化および行ソース生成の手順を省略してそのまま実行に進むため、通常ソフト解析はハード解析よりも優れています。

図7-4に、専用サーバー・アーキテクチャのUPDATE文の共有プール・チェックを簡単に示します。

図7-4 共有プール・チェック

チェックにより、共有プール内の文に同じハッシュ値があると判断された場合、データベースはセマンティクス・チェックおよび環境チェックを実行して、文の意味が同一かどうかを判断します。構文が同一であるだけでは不十分です。たとえば、データベースに異なる2人のユーザーがログインし、次のSQL文を発行したと想定します。

CREATE TABLE my_table ( some_col INTEGER );
SELECT * FROM my_table;

2人のユーザーのSELECT文は構文上同一ですが、2つの別々のスキーマ・オブジェクトがmy_tableという名前になっています。この意味の相違によって、2番目の文では最初の文のコードを再利用できません。

2つの文が意味的に同一であったとしても、環境の違いによりハード解析が強制的に行われることがあります。この場合の環境とは、作業領域サイズまたはオプティマイザの設定など、実行計画の生成に影響する可能性があるすべてのセッション設定です。単一のユーザーによって実行される次の一連のSQL文を考えてみます。

ALTER SYSTEM FLUSH SHARED_POOL;
SELECT * FROM my_table;

ALTER SESSION SET OPTIMIZER_MODE=FIRST_ROWS;
SELECT * FROM my_table;

ALTER SESSION SET SQL_TRACE=TRUE;
SELECT * FROM my_table;

この例では、同じSELECT文が3つの異なるオプティマイザ環境で実行されます。結果として、データベースはこれらの文に対して3つの個別の共有SQL領域を作成し、各文にハード解析を強制的に実行します。

関連項目:

- 「プライベートSQL領域」と「共有SQL領域」

- 共有プールの構成方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

SQLの最適化

「オプティマイザの概要」で説明しているように、問合せの最適化は、SQL文の実行の最も効率的な手段を選択するための処理です。データベースは、アクセスする実際のデータに関して収集した統計に基づいて、問合せを最適化します。オプティマイザは行数、データ・セットのサイズおよびその他の要因を使用して、使用可能な実行計画を生成し、各計画に数値コストを割り当てます。データベースは最もコストが低い計画を使用します。

データベースは一意のDML文ごとに必ず1回以上のハード解析を実行して、この解析中に最適化を実行します。最適化を要求する副問合せなどのDMLコンポーネントを含まないかぎり、DDLは最適化されません。

関連項目:
問合せオプティマイザの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

SQLの行ソース生成

行ソース・ジェネレータは、オプティマイザから最適な実行計画を受け取り、データベースのその他の部分で使用可能な問合せ計画と呼ばれる反復計画を作成するソフトウェアです。反復計画は、SQL仮想マシンで実行される場合に、結果セットを作成するバイナリ・プログラムです。

問合せ計画では、手順の組合せ形式を使用します。各手順では行セットが戻されます。このセット内の行は次の手順または最後の手順のいずれかで使用され、SQL文を発行するアプリケーションに戻されます。

行ソースは、行を反復的に処理できる制御構造に沿って、実行計画の手順から戻された行セットです。表、ビュー、または結合処理あるいはグループ化処理の結果が行ソースになる可能性があります。

行ソース・ジェネレータは、行ソースのコレクションである行ソース・ツリーを作成します。行ソース・ツリーには次の情報が表示されます。

- 文が参照する表の順序

- 文内に記述された各表へのアクセス方法

- 文の結合操作によって影響を受ける表の結合方法

- フィルタ、ソートまたは集計などのデータ操作

例7-6に、AUTOTRACEが有効な場合のSELECT文の実行計画を示します。この文では、姓が文字Aで始まるすべての従業員の姓、職種、部門名を選択します。この文の実行計画は行ソース・ジェネレータから出力されます。

例7-6 実行計画

SELECT e.last_name, j.job_title, d.department_name
FROM   hr.employees e, hr.departments d, hr.jobs j
WHERE  e.department_id = d.department_id
AND    e.job_id = j.job_id
AND    e.last_name LIKE 'A%' ;

Execution Plan
----------------------------------------------------------
Plan hash value: 975837011

---------------------------------------------------------------------------------------------
| Id  | Operation                     | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |             |     3 |   189 |     7  (15)| 00:00:01 |
|*  1 |  HASH JOIN                    |             |     3 |   189 |     7  (15)| 00:00:01 |
|*  2 |   HASH JOIN                   |             |     3 |   141 |     5  (20)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| EMPLOYEES   |     3 |    60 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | EMP_NAME_IX |     3 |       |     1   (0)| 00:00:01 |
|   5 |    TABLE ACCESS FULL          | JOBS        |    19 |   513 |     2   (0)| 00:00:01 |
|   6 |   TABLE ACCESS FULL           | DEPARTMENTS |    27 |   432 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
2 - access("E"."JOB_ID"="J"."JOB_ID")
4 - access("E"."LAST_NAME" LIKE 'A%')
filter("E"."LAST_NAME" LIKE 'A%')

SQLの実行

実行時には、SQLエンジンが行ソース・ジェネレータによって作成されたツリー内の各行ソースを実行します。この手順のみがDML処理の必須手順です。

図7-5は、各手順間の行ソースのフローを示す実行ツリー(解析ツリーとも呼ばれる)です。通常、実行時の手順の順序は計画時の順序とは逆になるため、計画の場合は下から上へと読み取ります。Operation列の最初のスペースは階層の関係を示します。たとえば、操作の名前の前に2つのスペースがある場合、この処理は1つのスペースの後続となる子処理です。前に1つのスペースがある操作は、SELECT文自体の子です。

図7-5 行ソース・ツリー

図7-5では、ツリーの各ノードが行ソースとして機能しており、実行計画の各手順がデータベースから行を取得するか、1つ以上の行ソースから入力として行を受け取ります。SQLエンジンは各行のソースを次のように実行します。

- 黒のボックスで示された手順は、データベース内のオブジェクトから物理的にデータを取り出します。これらの手順はアクセス・パス、つまりデータベースからデータを取得する技法です。

- 手順6は全表スキャンを使用してdepartments表のすべての行を取得します。

- 手順5は全表スキャンを使用してjobs表のすべての行を取得します。

- 手順4はemp_name_ix索引を順番にスキャンして、文字Aで始まる各キーを検索し、該当のROWIDを取得します(「索引レンジ・スキャン」を参照)。たとえば、Atkinsonに対応するROWIDはAAAPzRAAFAAAABSAAeです。

- 手順3はemployees表から手順4でROWIDが戻された行を取得します。たとえば、データベースはROWID AAAPzRAAFAAAABSAAeを使用して、Atkinsonの行を取得します。

- 透明のボックスで示された手順は行ソースを操作します。

- 手順2はハッシュ結合を実行して、手順3および5から行ソースを受け取り、手順5の行ソースからの各行を手順3の対応する行と結合して、手順1に結果の行を戻します。
たとえば、従業員Atkinsonの行は職種Stock Clerkに関連付けられています。

- 手順1は別のハッシュ結合を実行して、手順2および6から行ソースを受け取り、手順6のソースからの各行を手順2の対応する行と結合して、クライアントに結果を戻します。
たとえば、従業員Atkinsonの行は部門名Shippingに関連付けられています。

一部の実行計画では、手順が他の順序で反復されます。例7-6に示した計画は、SQLエンジンが索引から表、さらにクライアントへと移動して手順を繰り返すため反復されます。

実行中、データがメモリー内にない場合は、データベースがディスクからメモリーへとデータを読み取ります。また、データベースはデータ整合性を保証するために必要なすべてのロックおよびラッチを取り除き、SQL実行時に行われたすべての変更を記録します。SQL文の処理の最後の段階は、カーソルのクローズです。

関連項目:
実行計画およびEXPLAIN PLAN文の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

Oracle DatabaseによるDML処理方法

ほとんどのDML文には問合せコンポーネントがあります。問合せでは、カーソルを実行すると、問合せの結果が結果セットと呼ばれる行の集合に配置されます。

結果セットの行は、1行ごとにまたはグループ単位でフェッチできます。フェッチ段階では、データベースで行が選択され、問合せで要求された場合には行が順序付けされます。最後の行がフェッチされるまで、毎回のフェッチで結果の行が連続して取得されます。

通常、データベースは、最後の行がフェッチされるまで問合せによって取得する確実な行数を判定できません。Oracle Databaseはフェッチ・コールに応じてデータを取得するため、データベースが読み取る行が多いほど、データベースが実行する作業が増加します。一部の問合せではデータベースが最初の行を可能なかぎり迅速に戻すのに対して、別の問合せでは最初の行を戻す前にデータベースは全結果セットを作成します。

読取り一貫性

通常、問合せはOracle Databaseの読取り一貫性メカニズムを使用してデータを取得します。UNDOデータを使用して過去のバージョンのデータを表示するこのメカニズムでは、問合せによって読み取られるすべてのデータ・ブロックがある時点のものと一貫していることを保証します。

読取り一貫性の例として、1つの問合せで全表スキャンにより100個のデータ・ブロックを読み取る必要があるとします。問合せが最初の10個のブロックを処理している間に、別のセッションのDMLがブロック75を変更します。最初のセッションがブロック75に到達したとき、問合せは変更を認識し、変更前の古いバージョンのデータを取り出すためにUNDOデータを使用し、メモリー内に現時点のバージョンではないブロック75を構成します。

関連項目:
「マルチバージョン読取り一貫性」

データ変更

データを変更する必要があるDML文では、読取り一貫性のメカニズムを使用して、変更が開始された時点で検索基準に一致していたデータのみを取得します。その後、これらの文は最新の状態のデータ・ブロックを取得して、必要な変更を加えます。データベースは、REDOおよびUNDOデータの生成などのデータの変更に関連するその他のアクションを実行する必要があります。

関連項目:
「オンラインREDOログの概要」

Oracle DatabaseによるDDLの処理方法

Oracle DatabaseはDMLとは異なる方法でDDLを処理します。たとえば、表を作成するとき、データベースはCREATE TABLE文を最適化しません。かわりに、Oracle DatabaseはDDL文を解析してコマンドを実行します。

DDLはデータ・ディクショナリ内のオブジェクトを定義する手段であるため、データベースはDDLを異なる方法で処理します。通常、DDLコマンドを実行するために、Oracle Databaseは多くの 再帰的SQL文を解析して実行する必要があります。次のような表を作成するとします。

CREATE TABLE mytable (mycolumn INTEGER);

通常、この文を実行するために、データベースは多数の再帰的な文を実行します。再帰的SQLでは、次のようなアクションが実行されます。

- CREATE TABLE文を実行する前にCOMMITを発行します。

- ユーザー権限が表の作成に十分であることを検証します。

- 表が属する表領域を決定します。

- 表領域の割当てが超過していないことを確認します。

- スキーマ内に同じ名前のオブジェクトがないことを確認します。

- データ・ディクショナリに表を定義する行を挿入します。

- DDL文が成功した場合はCOMMITを発行し、失敗した場合はROLLBACKを発行します。

関連項目:
アプリケーション開発者のためのSQL処理の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

8 サーバー側プログラミング: PL/SQLとJava

第7章「SQL」では、Structured Query Language(SQL)言語およびデータベースによるSQL文の処理方法について説明しました。この章では、データベースに格納された手続き型言語/SQL(PL/SQL)またはJavaプログラムがSQLを使用できる仕組みについて説明します。

この章の内容は、次のとおりです。

- サーバー側プログラミングの概要

- PL/SQLの概要

- Oracle DatabaseにおけるJavaの概要

- トリガーの概要

関連項目:
第7章「SQL」

サーバー側プログラミングの概要

SQLなどの非手続き型言語では、処理対象のデータ・セットは指定しますが、実行される処理またはその処理の実行方法は指定しません。手続き型言語プログラムでは、ほとんどの文の実行が、前後の文、およびループまたは条件分岐などの制御構造に依存しますが、このような処理はSQLでは実行できません。

手続き型言語と非手続き型言語の相違を例示するために、次のSQL文でemployees表に問い合せるとします。

SELECT employee_id, department_id, last_name, salary FROM employees;

この文はデータを要求しますが、データにロジックを適用しません。ただし、データ・セットの各従業員が給与および部門の業績に基づく昇給の対象者になるかどうかを判定するアプリケーションが必要であるとします。昇給の必要条件は、従業員が過去5年間に4回以上の昇給を受けていないことです。昇給する場合は、アプリケーションで給与を調整してマネージャに電子メールを送信し、昇給しない場合は、アプリケーションでレポートを更新する必要があります。

この処理を実行するために、条件付きロジックおよびプログラム・フロー制御を必要とする手続き型データベース・アプリケーションでSQLを使用できるようにします。基本的な開発アプローチは次のとおりです。

- クライアント側プログラミングを使用して、C、C++またはJavaなどの手続き型言語で記述されたアプリケーションにSQL文を埋め込みます。
ソース・コードにSQL文を配置して、コンパイル前にそのSQL文をプリコンパイラまたはJavaトランスレータに送信できます。または、プリコンパイル手順を省略し、アプリケーションがデータベースと相互作用できるようにJava Database Connectivity(JDBC)またはOracle Call Interface(OCI)などのAPIを使用することもできます。

- サーバー側プログラミングを使用して、データベース内に配置するデータ・ロジックを開発します。
アプリケーションは、PL/SQL(「ピーエルシーキューエル」と読みます)またはJavaで記述されたストアド・サブプログラム(プロシージャおよびファンクション)を明示的に起動できます。また、データベースに格納されたプログラム・ユニットの名前を指定し、特定のイベントに応答して起動するトリガーを作成することもできます。

この章では、2番目のアプローチについて説明します。サーバー側プログラミングの主な利点は、データベースに組み込まれた機能を任意の場所にデプロイできることです。指定されたオペレーティング・システム上でタスクを実行するための最善の方法を決定するのは、アプリケーションではなくデータベースです。また、サブプログラムを使用すると、サーバー上にアプリケーション処理を集中化することでスケーラビリティを向上させることができ、また、クライアントでコードを再利用することもできます。サブプログラム・コールは迅速かつ効率的であるため、1回のコールで計算集中型のストアド・サブプログラムを開始し、ネットワーク・トラフィックを軽減できます。

Oracle Databaseにデータ・ロジックを格納するには、次の言語を使用できます。

- PL/SQL
PL/SQLは、SQLに対するOracle Databaseの手続きを拡張します。PL/SQLはデータベースに統合されており、すべてのOracle SQL文、関数およびデータ型をサポートします。データベースAPIに記述されたアプリケーションはPL/SQLストアド・サブプログラムを起動し、実行するPL/SQLコード・ブロックをデータベースに送信します。

- Java
Oracle Databaseは、Javaアプリケーションの開発、格納およびデプロイもサポートしています。Javaストアド・サブプログラムはデータベースで実行され、中間層で実行されるプログラムからは独立しています。Javaストアド・サブプログラムは、PL/SQLに類似の実行モデルを使用してSQLとインタフェースを確立します。

関連項目:

- プリコンパイラおよびAPIでのSQLの埋込みの詳細は、「クライアント側のデータベース・プログラミング」を参照してください。

- Oracle Databaseアプリケーション開発の概要は、『Oracle Database 2日で開発者ガイド』を参照してください。

- プログラミング環境を選択する方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

PL/SQLの概要

PL/SQLは、使用しやすく、SQLとシームレスで、堅牢かつ移植性を備えたセキュアなサーバー側に格納される手続き型言語を提供します。PL/SQLプログラム・ユニットというプロシージャ型スキーマ・オブジェクトを使用してデータベースにアクセスし、データを処理できます。

PL/SQLプログラム・ユニットは、一般に、次のように分類されます。

- サブプログラムとは、データベースに格納され、アプリケーションから名前でコールできるPL/SQLブロックのことです。サブプログラムを作成すると、データベースではそのサブプログラムを解析し、解析後の表現をデータベースに格納します。サブプログラムは、プロシージャまたはファンクションとして宣言できます。

- 無名ブロックとは、アプリケーション内に表示されるが名前が付いていない、またはデータベースに格納されていないPL/SQLブロックです。多くのアプリケーションでは、SQL文を記述できるところであればどこにでもPL/SQLブロックを記述できます。

PL/SQLのコンパイラとインタプリタはOracle SQL Developerに埋め込まれており、開発者にクライアントとサーバーの両方で一貫性のある高度な開発モデルを提供します。また、PL/SQLストアド・プロシージャは、Pro*C、JDBC、ODBCまたはOCIなどの複数のデータベース・クライアント、およびOracle ReportsとOracle Formsからコールできます。

関連項目:

- 「データベース開発者向けのツール」

- パッケージなどのPL/SQLの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

PL/SQLサブプログラム

PL/SQLサブプログラムは、コール元から、入力のみ、出力のみまたは入出力の値が入るパラメータを指定できる名前付きのPL/SQLブロックです。サブプログラムは特定の問題を解決するか、関連するタスクを実行してモジュール式のメンテナンス可能なデータベース・アプリケーションのビルディング・ブロックとして機能します。

サブプログラムは、プロシージャまたはファンクションのいずれかです。プロシージャとファンクションはほとんど同じものですが、プロシージャはコール元に値を戻さないのに対して、ファンクションは必ず1つの値を戻すという違いがあります。この章では、プロシージャという語でプロシージャとファンクションの両方を指すものとします。

関連項目:

- これらの言語のストアド・プロシージャの詳細は、『Pro*C/C++プログラマーズ・ガイド』および『Pro*COBOLプログラマーズ・ガイド』を参照してください。

- 『Oracle Database PL/SQL言語リファレンス』

PL/SQLサブプログラムの利点

「サーバー側プログラミングの概要」で説明しているように、サーバー側プログラミングにはクライアント側プログラミングよりも多くの利点があります。PL/SQLサブプログラムは次の利点を備えています。

- パフォーマンスの改善

- 情報が送信されるのは1回のみで、それ以降は使用するときに呼び出されるため、個々のSQL文を発行する場合や、PL/SQLブロック全体のテキストをOracle Databaseに送信する場合に比べて、アプリケーションがネットワークを介して送信する必要のある情報量が少なくなります。

- データベース内でプロシージャのコンパイル済形式をそのまま使用できるため、実行時にコンパイルする必要がありません。

- プロシージャがSGAの共有プール内にある場合、データベースはディスクからプロシージャを検索する必要がないため、ただちに実行を開始できます。

- メモリー割当て

ストアド・プロシージャは、Oracle Databaseの共有メモリー機能を活用しているため、複数のユーザーが実行する場合も、メモリーにロードする必要があるのはプロシージャのコピー1つのみです。コードを複数のユーザーが共有すれば、アプリケーションに必要なデータベース・メモリー要件を実質的に削減できます。

- 生産性の向上

ストアド・プロシージャにより、開発の生産性が向上します。共通のプロシージャを中心にしてアプリケーションを設計することにより、冗長なコーディングを回避できます。たとえば、プロシージャを記述してemployees表内の行を操作できます。どのアプリケーションでも、これらのプロシージャをコールするためにSQL文を書きなおす必要はありません。データ管理の方法に変更があった場合も、修正する必要があるのはプロシージャのみで、プロシージャを使用するアプリケーションを修正する必要はありません。

ストアド・プロシージャは、コードを再利用するための最善の方法です。任意の言語で記述されたデータベース接続を行うどのクライアント・アプリケーションもストアド・プロシージャを起動できるため、すべての環境において最大限にコードを再利用できます。

- 整合性

ストアド・プロシージャにより、アプリケーションの整合性と一貫性が向上します。共通のプロシージャ群を中心としてアプリケーションを開発すれば、コーディング・エラーの発生回数が少なくなります。

たとえば、サブプログラムが正確な結果を戻すかどうかをテストし、検証後は、そのサブプログラムを必要な数のアプリケーションで再利用でき、再びテストする必要はありません。プロシージャにより参照されるデータ構造が変更された場合には、プロシージャの再コンパイルのみが必要になります。プロシージャをコールするアプリケーションの修正は、必ずしも必要ありません。

- 定義者権限プロシージャでのセキュリティ
ストアド・プロシージャは、データ・セキュリティの規定に役立ちます(「データベース・セキュリティの概要」を参照)。定義者権限プロシージャは、現行のユーザーではなくプロシージャの所有者の権限で実行されます。このため、定義者の権限で実行するプロシージャとファンクションを介してのみユーザーがデータにアクセスできるようにすると、ユーザーが実行するデータベース操作を制限できます。

たとえば、表を更新するプロシージャへのアクセス権は付与しても、その表自体へのアクセス権は付与しないこともできます。ユーザーがプロシージャを呼び出すと、そのプロシージャがプロシージャの所有者の権限で実行されます。プロシージャの実行権限しかなく、表データの問合せ、更新または削除の権限を持たないユーザーは、プロシージャを呼び出すことはできても、表のデータをそれ以外の方法では操作できません。

- 実行者権限プロシージャで継承される権限およびスキーマのコンテキスト

実行者権限プロシージャは、現行のユーザーの権限で現行のユーザーのスキーマ内で実行されます。言い換えると、実行者権限プロシージャは特定のユーザーまたはスキーマに結び付けられていません。アプリケーション開発者は、実行者権限プロシージャにより、基礎となるデータが複数のユーザー・スキーマに分割されていても、アプリケーション・ロジックを容易に一元化できます。

たとえば、hr.employees表の更新プロシージャを実行するhr_managerユーザーは給与を更新できますが、同じプロシージャを実行するhr_clerkは住所データの更新のみに操作を制限されます。

関連項目:

- PL/SQLサブプログラムの概要は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- 定義者および実行者の権限の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

PL/SQLサブプログラムの作成

CREATE PROCEDURE文またはCREATE FUNCTION文を使用してスキーマ・レベルで作成されたサブプログラムは、スタンドアロンのストアド・サブプログラムです。パッケージに定義されているサブプログラムはパッケージ・サブプログラムと呼ばれ、パッケージの一部とみなされます。データベースは、データ・ディクショナリにスキーマ・オブジェクトとしてサブプログラムを格納します。

サブプログラムには、パラメータの記述などの仕様部と本体があります。例8-1に、スタンドアロンのPL/SQLプロシージャhire_employeesを作成する文の一部を示します。プロシージャは、employees表に1つの行を挿入します。

例8-1 PL/SQLプロシージャ

CREATE PROCEDURE hire_employees
(p_last_name VARCHAR2, p_job_id VARCHAR2, p_manager_id NUMBER, p_hire_date DATE,
p_salary NUMBER, p_commission_pct NUMBER, p_department_id NUMBER)
IS
BEGIN
.
.
.
INSERT INTO employees (employee_id, last_name, job_id, manager_id, hire_date,
salary, commission_pct, department_id)
VALUES (emp_sequence.NEXTVAL, p_last_name, p_job_id, p_manager_id, p_hire_date,
p_salary, p_commission_pct, p_department_id);
.
.
.
END;

関連項目:

- サブプログラムの作成方法の詳細は、『Oracle Database 2日で開発者ガイド』を参照してください。

- CREATE PROCEDUREコマンドの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

PL/SQLサブプログラムの実行

ユーザーは次の操作によって、対話的にサブプログラムを実行できます。

- SQL*PlusまたはSQL DeveloperなどのOracleツールを使用します(「データベース開発者向けのツール」を参照)。

- Oracle Formsやプリコンパイラのアプリケーションなど、データベース・アプリケーションのコード内で明示的にコールします(「クライアント側のデータベース・プログラミング」を参照)。

- 別のプロシージャやトリガーのコード内で明示的にコールします。

図8-1に、各種のデータベース・アプリケーションがhire_employeesをコールする状態を示します。

図8-1 PL/SQLストアド・プロシージャのコール

また、権限を付与されたユーザーは、Oracle Enterprise ManagerまたはSQL*Plusを使用して、次のような文でhire_employeesプロシージャを実行できます。

EXECUTE hire_employees ('TSMITH', 'CLERK', 1037, SYSDATE, 500, NULL, 20);

この文により、employees表にTSMITHのための新しいレコードが挿入されます。

ストアド・プロシージャは、プロシージャの本体で参照されるオブジェクトに依存しています。データベースは、この依存性を自動的に追跡して管理します。たとえば、プロシージャに影響を及ぼす方法でhire_employeesプロシージャが参照しているemployees表の定義を変更した場合は、プロシージャを再コンパイルして、引き続き設計どおりに機能することを確認する必要があります。通常、データベースはこのような依存性の管理を自動的に処理します。

関連項目:

- PL/SQLサブプログラムの使用方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- EXECUTEコマンドの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

PL/SQLパッケージ

PL/SQLパッケージとは、関連するサブプログラムおよびこれらのサブプログラムが使用するカーソルと変数をグループとしてまとめたもので、1単位として継続的に使用できるようにデータベースに格納されています。パッケージ化されたプログラムは、アプリケーションまたはユーザーから明示的にコールできます。

Oracle Databaseにはオラクル社が提供するパッケージが多数含まれており、これらのパッケージはデータベースの機能性を拡張してSQL機能へのPL/SQLアクセスを提供します。たとえば、UTL_HTTPパッケージを使用すると、PL/SQLおよびSQLからのHTTPコールアウトでインターネット上のデータにアクセスしたり、Oracle Web Server Cartridgesをコールできます。オラクル社が提供するパッケージは、アプリケーションの作成時や、独自のストアド・プロシージャを作成する場合に使用できます。

PL/SQLパッケージの利点

PL/SQLパッケージは次の利点を備えています。

- カプセル化
パッケージを使用すると、ストアド・プロシージャ、変数、データ型などに名前を付けて1つの単位としてこれらをカプセル化、つまりグループ化できます。カプセル化により開発時に優れた構成を実現でき、柔軟性も向上します。パッケージ本体を実際には作成せずに、仕様部を作成し、パブリック・プロシージャを参照するようにできます。カプセル化により、権限の管理が簡単になります。パッケージに対する権限を付与されたユーザーは、そのパッケージの構成メンバーにアクセスできるようになります。

- データ・セキュリティ
パッケージの定義方法により、変数、カーソルおよびプロシージャをパブリックとプライベートのどちらかに指定できます。パブリックはパッケージのユーザーが直接アクセスできることを意味します。プライベートはパッケージのユーザーには非表示になっていることを意味します。

たとえば、パッケージに10個のプロシージャが含まれているとします。この中の3つのプロシージャのみをパブリックに設定して、パッケージのユーザーが実行できるように定義できます。残りのプロシージャはプライベートなので、パッケージ内のプロシージャによってのみアクセスできます。パブリックおよびプライベートのパッケージ変数を、PUBLICへの権限付与と混同しないでください。

- 優れたパフォーマンス
パッケージ内のプロシージャが初めてコールされた時点で、そのパッケージ全体が小さいチャンクに分割されてメモリーにロードされます。スタンドアロン・プロシージャは個別にロードする必要があるのに対し、このロードは1回の操作で完了します。関連するパッケージ・プロシージャがコールされても、メモリーにあるコンパイル済のコードを実行すると、ディスクI/Oは発生しません。

パッケージ本体は、仕様部に影響を与えずに置換したり再コンパイルできます。その結果、パッケージ仕様部も置き換えない場合は、パッケージの構成メンバーを参照するスキーマ・オブジェクト(常に仕様部を介してアクセス)を再コンパイルする必要はありません。パッケージを使用すると、不必要な再コンパイルが最小限に抑えられるため、全体的なデータベース・パフォーマンスへの影響は少なくなります。

PL/SQLパッケージの作成

パッケージは、仕様部と本体の2つの部分に分けて作成します。パッケージの仕様部ではパッケージのすべてのパブリックな構成メンバーを宣言し、本体ではパッケージのすべての構成メンバー(パブリックとプライベート)を定義します。

例8-1は、employees_managementのパッケージ仕様を作成する文の一部で、このパッケージは、従業員データベースの管理に使用される複数のサブプログラムをカプセル化します。パッケージの各部分は、異なる文を使用して作成されます。

例8-2 PL/SQLパッケージ

CREATE PACKAGE employees_management AS
FUNCTION hire_employees (last_name VARCHAR2, job_id VARCHAR2, manager_id NUMBER,
salary NUMBER, commission_pct NUMBER, department_id NUMBER) RETURN NUMBER;
PROCEDURE fire_employees(employee_id NUMBER);
PROCEDURE salary_raise(employee_id NUMBER, salary_incr NUMBER);
.
.
.
no_sal EXCEPTION;
END employees_management;

仕様部に、ファンクションhire_employees、プロシージャfire_employeesおよびsalary_raiseと、例外であるno_salが宣言されています。パッケージへのアクセス権を持つユーザーは、これらすべてのパブリック・プログラム・オブジェクトを使用できます。

CREATE PACKAGE BODYコマンドでは、仕様部で宣言されたオブジェクトを定義します。パッケージ本体は、パッケージと同じスキーマに作成する必要があります。パッケージの作成後は、これらのうちいずれかのパブリック・プロシージャまたはファンクションをコールするか、パッケージのいずれかのパブリック例外を呼び出すアプリケーションを開発できます。

関連項目:
CREATE PACKAGEコマンドの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

PL/SQLパッケージ・サブプログラムの実行

パッケージの内容はデータベース・トリガー、ストアド・サブプログラム、3GLアプリケーション・プログラムおよびOracleツールから参照できます。図8-2に、employees_managementパッケージ内のプロシージャおよびファンクションを呼び出すデータベース・アプリケーションを示します。

図8-2 PL/SQLパッケージ内のサブプログラムのコール

データベース・アプリケーションは、必要に応じて明示的にパッケージ・プロシージャをコールします。employees_managementパッケージに対する権限を付与されたユーザーは、そこに含まれている任意のプロシージャを明示的に実行できます。たとえば、SQL*Plusでは、次の文を発行してhire_employeesパッケージ・プロシージャを実行できます。

EXECUTE employees_management.hire_employees ('TSMITH', 'CLERK', 1037, SYSDATE, 500, NULL, 20);

関連項目:

- PL/SQLパッケージの概要は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- PL/SQLパッケージのコーディング方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

PL/SQL無名ブロック

無名ブロックは名前が付与されていない非永続PL/SQLユニットです。典型的な無名ブロックの用途は次のとおりです。

- サブプログラムおよびパッケージ構成のコールの開始

- 例外処理の分離

- 他のPL/SQLブロック内でのコードのネストによる制御の管理

無名ブロックには、ストアド・サブプログラムのコードの再利用という利点はありません。表8-1に、2つのプログラム・ユニット・タイプの相違点の概要を示します。

表8-1 無名ブロックとサブプログラムの相違点

PL/SQLユニット

無名ブロック

サブプログラム

名前で指定するか

いいえ

はい

再利用ごとにコンパイルするか

いいえ

いいえ

データベースに格納されるか

いいえ

はい

他のアプリケーションから起動できるか

いいえ

はい

バインド変数値を戻すことができるか

はい

はい

関数値を戻すことができるか

いいえ

はい

パラメータを受け取ることができるか

いいえ

はい

無名ブロックは宣言部(オプション)、実行可能部分および1つ以上の例外ハンドラ(オプション)から構成されています。次のサンプルの無名ブロックでは、変数に格納する従業員の姓を選択して、その名前を出力しています。

DECLARE
v_lname VARCHAR2(25);
BEGIN
SELECT last_name INTO v_lname
FROM employees
WHERE employee_id = 101;
DBMS_OUTPUT.PUT_LINE('Employee last name is '||v_lname);
END;

Oracle Databaseでは、PL/SQLブロックをコンパイルしてSGAの共有プールに配置しますが、現行インスタンス以外で再利用するために、ソース・コードおよびコンパイル済バージョンのブロックをデータベースに格納することはありません。トリガーとは異なり、無名ブロックはメモリーにロードされるたびにコンパイルされます。共有SQLを使用すると、共有プールに入っている無名PL/SQLブロックがその共有プールからフラッシュされるまでの間は、そのブロックを再利用および共有できます。

関連項目:
無名PL/SQLブロックの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

PL/SQLの言語構造

PL/SQLブロックには、様々な異なるPL/SQL言語構造を組み込むことができます。これらの構造には、次のものが含まれます。

- 変数と定数
プロシージャ、ファンクションまたはパッケージ内にこれらの構造を宣言できます。SQL文やPL/SQL文では、必要になった時点で値を受け渡すために変数や定数を使用できます。

- カーソル
カーソルは、Oracle Databaseデータのレコード単位での処理を容易にするために、プロシージャ、ファンクションまたはパッケージの中で明示的に宣言できます。PL/SQLエンジンで、暗黙的にカーソルを宣言することもできます。

- 例外
PL/SQLでは、PL/SQLコードの処理中に発生する、例外と呼ばれる内部的なエラー条件とユーザー定義のエラー条件を明示的に処理できます。

PL/SQLでは、完全なテキストが実行時まで認識されない動的SQL文を実行できます。動的SQL文は、実行時に、プログラムに入力されたりまたはプログラムにより作成される文字列に格納されます。この技法により、汎用プロシージャを作成できます。たとえば、実行時までは名前がわからない表を操作するプロシージャを作成できます。

関連項目:

- 動的SQLの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- DBMS_SQLパッケージでの動的SQLの使用方法の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

PL/SQLのコレクションとレコード

多数のプログラミング技法は、配列、構造体、リスト、ネストした表、セットおよびツリーなどのコレクション型を使用します。これらの技法をデータベース・アプリケーション内でサポートするために、PL/SQLにはデータ型TABLEおよびVARRAYが用意されており、連想配列、ネストした表および可変サイズ配列を宣言できます。

コレクション

コレクションは、すべて同じ型の要素からなる順序付けられたグループです。各要素には、コレクション内での位置を決定する一意の添字が付いています。コレクションを作成するには、最初にコレクションの型を定義してから、その型の変数を宣言します。

コレクションの機能は、ほとんどの第3世代プログラミング言語に見られる配列と同じです。また、コレクションはパラメータとして渡すことができます。そのため、データベース表との間や、クライアント側アプリケーションとストアド・サブプログラムの間で、データの列を移動するときに使用できます。

レコード

レコードはC、C++またはJavaの構造型に類似した、異なる型のデータ値を格納できる複合変数です。レコードは、表内の行データまたは表内の行の特定列を保持する場合に役立ちます。

名前、給与および採用日など、従業員に関するデータがあるとします。これらの項目は、型は異なりますが論理的には関連しています。項目ごとに1フィールドを含むレコードを使用すると、データを論理単位として扱うことができます。

%ROWTYPE属性を使用すると、表の1行やカーソルからフェッチされる1行を表すレコードを宣言できます。ユーザー定義レコードの場合は、所有しているフィールドを宣言できます。

関連項目:
コレクションおよびレコードの使用方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

PL/SQLの実行方法

PL/SQLはシステム固有の実行および解析済の実行の両方をサポートします。解析済の実行では、PL/SQLソース・コードはその名のとおりバイトコード表現にコンパイルされ、Oracle Databaseの一部として実装される移植性のある仮想コンピュータによって実行されます。システム固有の実行では、計算集中型のプログラム・ユニットで最大限のパフォーマンスが発揮されるように、PL/SQLプログラム・ユニットのソース・コードを直接コンパイルし、特定のプラットフォームのオブジェクト・コードにします。このオブジェクト・コードは、Oracle Databaseにリンクされます。

PL/SQLエンジンは、PL/SQLプログラム・ユニットの定義、コンパイルおよび実行に使用するツールです。このエンジンは、Oracle Databaseをはじめとする多数のOracle製品に組み込まれている特別なコンポーネントです。多くのOracle製品にPL/SQLコンポーネントが含まれていますが、この項では、Oracle Databaseに格納でき、Oracle DatabaseのPL/SQLエンジンを使用して処理できるプログラム・ユニットについて説明します。それぞれのOracleツールのPL/SQL機能については、該当するOracleツールのマニュアルに説明があります。

図8-3に、Oracle Databaseに含まれているPL/SQLエンジンを示します。

図8-3 PL/SQLエンジンとOracle Database

プログラム・ユニットは、データベースに格納されています。アプリケションがストアド・プロシージャをコールすると、データベースは、コンパイル済のプログラム・ユニットをシステム・グローバル領域(SGA)内の共有プールにロードします(「共有プール」を参照)。PL/SQL文エグゼキュータとSQL文エグゼキュータは、連動してプロシージャ内の文を処理します。

別のPL/SQLブロック(無名ブロックまたは別のストアド・プロシージャ)からストアド・プロシージャをコールすることもできます。たとえば、Oracle Formsからストアド・プロシージャをコールできます。

Oracle Database上で実行されるPL/SQLプロシージャからは、Cプログラミング言語で作成して共有ライブラリに格納した外部プロシージャや外部ファンクションをコールできます。Cルーチンは、Oracle Databaseとは別のアドレス空間で実行されます。

関連項目:

- PL/SQLアーキテクチャの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- 外部プロシージャの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

Oracle DatabaseにおけるJavaの概要

オブジェクト指向プログラミング言語の選択肢として、Javaがあります。Javaの機能は、次のとおりです。

- Java仮想マシン(JVM)。プラットフォームの独立性を確保するための基礎を提供します。

- 自動ストレージ管理機能。ガーベージ・コレクションなどがあります。

- C言語に基づく言語構文。強い型指定が必要です。

注意:
この章は、Java言語に関するある程度の知識があることを前提としています。

データベースは、複雑な問合せおよび複数のデータ・ビューをサポートする動的データ処理エンジンを備えたJavaプログラムを提供しています。クライアント要求は、即時処理されるようにデータ問合せとして組み立てられます。問合せの結果は動的に生成されます。

JavaとOracle Databaseの組合せによって、ビジネス・ニーズの変更に応じて簡単に更新できるコンポーネントベースかつネットワーク中心のアプリケーションを作成できます。また、アプリケーションおよびデータ・ストアは、デスクトップからインテリジェント・ネットワーク上およびネットワーク中心のサーバー上に移動できます。さらに重要なのは、任意のクライアント・デバイスからこれらのアプリケーションおよびデータ・ストアにアクセスできることです。

図8-4は、従来の2層のクライアント/サーバー構成を示しています。この構成では、クライアントは、PL/SQLサブプログラムをコールする際と同じ方法でJavaストアド・プロシージャをコールします。

図8-4 2層のクライアント/サーバー構成

関連項目:
Oracle DatabaseでのJavaの使用方法の概要は、『Oracle Database 2日でJava開発者ガイド』を参照してください。

Java仮想マシン(JVM)の概要

JVMはコンパイル済のJavaコードを実行する仮想プロセッサです。Javaソース・コードは、バイトコードと呼ばれる、プラットフォームに依存しない低レベルのマシン命令にコンパイルされます。Javaバイトコードは、JVMを介して、プラットフォームに依存する処理に解釈されます。

Oracle JVMの概要

Oracle JVMは、Pure Javaアプリケーションを実行する完全なJava2準拠の環境です。JLSおよびJVMの仕様と互換性があります。標準のJavaバイナリ形式とAPIがサポートされています。また、Oracle Databaseは、実行時の動的クラス・ロードなど、標準のJava言語のセマンティクスに準拠しています。

図8-5に、OracleのJavaアプリケーションがJavaコア・クラス・ライブラリの最上位に配置され、さらに、Oracle JVMの最上位に配置される様子を示します。OracleのJavaサポート・システムはデータベース内に配置されるので、JVMはオペレーティング・システムと直接対話するかわりに、データベースのライブラリと対話します。

図8-5 Javaコンポーネントの構造

他のJava環境とは異なり、Oracle JVMはOracle Database内に埋め込まれています。Oracle JVMと典型的なクライアントJVMには、いくつかの重要な違いがあります。たとえば、標準のJava環境では、コマンドラインで次のコマンドを発行し、インタプリタを介してJavaアプリケーションを実行します(classnameは、JVMにより最初に解釈されるクラス名です)。

java classname

このコマンドによって、オペレーティング・システム上のプロセス内でアプリケーションが実行されます。ただし、コマンドライン・インタフェースを使用していない場合は、アプリケーションをデータベースにロードして、インタフェースをパブリッシュしてから、データベース・データ・ディクショナリ内のアプリケーションを実行します。

関連項目:
Oracle JVMと典型的なクライアントJVMのその他の相違の詳細は、『Oracle Database Java開発者ガイド』を参照してください。

Oracle JVMの主要コンポーネント

Oracle JVMはデータベースのメモリー・ヒープを共有してリレーショナル・データに直接アクセスするため、データベース・カーネルと同じ処理領域およびアドレス領域で実行されます。この設計によりメモリーの使用を最適化して、スループットを向上させます。

Oracle JVMは、Javaオブジェクトの実行時環境を提供します。Javaのデータ構造、メソッド・ディスパッチ、例外処理および言語レベル・スレッドを完全にサポートします。また、java.lang、java.io、java.net、java.mathおよびjava.utilなど、すべてのコアJavaクラス・ライブラリもサポートしています。

図8-6に、Oracle JVMの主要なコンポーネントを示します。

図8-6 Oracle JVMの主要コンポーネント

Oracle JVMは、データベース・スキーマに標準のJavaネームスペースを埋め込みます。この機能により、JavaプログラムはOracle Databaseに格納されたJavaオブジェクトおよび企業内のアプリケーション・サーバーにアクセスできます。

また、Oracle JVMは、データベースのスケーラブルな共有メモリー・アーキテクチャと緊密に統合されています。Javaプログラムは、ユーザーの介入なしで効率的にコール、セッションおよびオブジェクトの存続期間を使用します。結果として、セッションが継続状態であっても、Oracle JVMおよび中間層のJavaビジネス・オブジェクトのスケーラビリティを維持できます。

関連項目:
Oracle JVMの主要なコンポーネントの詳細は、『Oracle Database Java開発者ガイド』を参照してください。

Javaプログラミング環境

オラクル社は、エンタープライズ・アプリケーションの開発者に、Javaアプリケーションの作成、デプロイおよび管理のためのエンドツーエンドのJavaソリューションを提供します。このソリューションは、クライアント側とサーバー側のプログラム・インタフェース、Java開発をサポートするためのツール、Oracle Databaseと統合されたJava仮想マシンで構成されています。これらの製品はいずれも、Java標準との互換性を持っています。

Javaプログラミング環境は、次の追加機能で構成されています。

- PL/SQLに等価および相当するJavaストアド・プロシージャ。Javaストアド・プロシージャは、PL/SQLと緊密に統合されています。Javaストアド・プロシージャはPL/SQLパッケージから、プロシージャはJavaストアド・プロシージャからコールできます。

- SQLデータにアクセスするためのJDBCおよびSQLJプログラミング・インタフェース。

- クラスの開発、ロードおよび管理を支援するツールおよびスクリプト。

Javaストアド・プロシージャ

Javaストアド・プロシージャは、SQLにパブリッシュされデータベースに格納されるJavaメソッドです。PL/SQLサブプログラムと同様に、Javaプロシージャには、SQL*Plusなどの製品で直接起動する方法と、トリガーを使用して間接的に起動する方法があります。また、OCI、プリコンパイラまたはJDBCなど、すべてのOracle Netクライアントからアクセスできます。

Javaメソッドをパブリッシュするには、Javaメソッド名、パラメータの型およびSQLの対応部分への戻り型をマップするコール仕様を記述します。クライアント・アプリケーションからコールされると、Javaストアド・プロシージャは引数を受け取り、Javaクラスを参照してJavaの結果値を戻すことができます。

アプリケーションは、コール仕様の名前を参照することにより、Javaメソッドをコールします。実行時のシステムは、Oracleデータ・ディクショナリ内のコール仕様の定義を検索し、該当のJavaメソッドを実行します。

また、Javaを使用して、PL/SQLに依存しない強力なプログラムを開発することもできます。Oracle Databaseには、Javaプログラミング言語とJVMの完全準拠の実装が用意されています。

関連項目:
Javaでストアド・プロシージャを記述する方法、PL/SQLからアクセスする方法およびJavaからPL/SQL機能にアクセスする方法は、『Oracle Database Java開発者ガイド』を参照してください。

JavaおよびPL/SQLの統合

既存のPL/SQLプログラムをJavaから呼び出したり、JavaプログラムをPL/SQLから起動できます。このソリューションでは、PL/SQLおよびJavaコードを保護して活用します。

Oracle DatabaseはJava、JDBCおよびSQLJからSQLデータにアクセスするために、異なる2つのアプローチを提供しています。クライアントおよびサーバー上で両方のアプローチを使用できます。このため、コードを変更することなく、クライアントおよびサーバー上にアプリケーションをデプロイできます。

JDBCドライバ

JDBCは、ユーザーがデータベースに接続してSQL文を実行し、データベースに問合せできるようにするデータベース・アクセス・プロトコルです。コアJavaクラス・ライブラリには、JDBC APIのjava.sqlが1つのみ用意されています。ただし、JDBCは、ベンダーが特定のデータベースを必要に応じて特化するためのドライバを提供できるように設計されています。Oracleには、次の表に示す個々のJDBCドライバが用意されています。

ドライバ

説明

JDBC Thinドライバ

JDBC Thinドライバを使用すると、Oracle SQLのデータにアクセスするPure Javaアプリケーションおよびアプレットを作成できます。JDBC Thinドライバは、他のJavaアプレットと同様にWebページから動的にダウンロードできるため、Webベースのアプリケーションとアプレットに特に適しています。

JDBC OCIドライバ

JDBC OCIドライバは、クライアントまたは中間層にあるOracle固有のネイティブ・コード(つまり非Javaコード)およびライブラリにアクセスし、JDBC Thinドライバに比べてパフォーマンスが向上しますが、サイズが極端に大きくなることと、クライアント側でのインストールというコストの問題があります。

サーバー側JDBC内部ドライバ

Oracle Databaseは、Javaコードがサーバー上で実行される場合に、サーバー側内部ドライバを使用します。これにより、サーバーのOracle JVM内で実行中のJavaアプリケーションは、JDBCを使用してローカルに定義されたデータ(つまり、同じシステムの同じプロセスにあるデータ)にアクセスできます。また、基礎となるOracle RDBMSライブラリを直接使用できるため、パフォーマンスが向上し、JavaコードとSQLデータの間にネットワーク接続が介入することによるオーバーヘッドは発生しません。Oracle Databaseでは、サーバー上で同じJava-SQLインタフェースがサポートされるため、デプロイ時にコードの再処理を必要としません。

関連項目:

- 「ODBCおよびJDBC」

- 『Oracle Database 2日でJava開発者ガイド』および『Oracle Database JDBC開発者ガイド』

SQLJ

SQLJは、JavaプログラムにSQL文を埋め込むためのANSI標準です。Oracle Database環境内では、ストアド・プロシージャ、トリガーおよびメソッドでSQLJを使用できます。また、SQLJプログラムをJDBCと組み合せることもできます。

SQLJは、Javaからデータベースにアクセスするクライアント側の中間層アプリケーションを開発するための簡単かつ強力な方法を提供します(「SQLJ」を参照)。開発者はSQLJを使用してプログラムを記述し、その後SQLJトランスレータを使用して埋め込まれたSQLをJDBCベースのPure Javaコードに変換します。実行時に、プログラムは標準のJDBCドライバを使用して、複数のベンダーのデータベースと通信できます。

次の例は、簡単な実行可能SQLJ文を示しています。

String name;
#sql  { SELECT first_name INTO :name FROM employees WHERE employee_id=112 };
System.out.println("Name is " + name + ", employee number = " + employee_id);

Oracle Databaseは完全なJava環境を提供しているため、データベースで実行されるSQLJプログラムをクライアント上ではコンパイルできません。かわりに、サーバー上でSQLJプログラムを直接コンパイルできます。

関連項目:
『Oracle Database SQLJ開発者ガイド』

トリガーの概要

データベースのトリガーはコンパイル済のストアド・プログラム・ユニットであり、PL/SQLまたはJavaのいずれかで記述されます。Oracle Databaseは、次のいずれかの処理が発生した場合は常に自動的にトリガーの呼出し(起動)を行います。

1. 任意のユーザーによって発行された、特定の表またはビューに対するDML文
DML文は、スキーマ・オブジェクト内のデータを変更します。たとえば、行の挿入および削除はDMLの処理です。

2. 特定のユーザーまたは任意のユーザーのいずれかが発行したDDL文
DDL文は、スキーマ・オブジェクトを定義します。たとえば、表の作成および列の追加はDDLの処理です。

3. データベース・イベント
ユーザーのログインまたはログオフ、エラーおよびデータベースの起動または停止は、トリガーを起動できるイベントです。

トリガーはサブプログラムに類似したスキーマ・オブジェクトですが、起動方法が異なります。サブプログラムはユーザー、アプリケーションまたはトリガーによって明示的に実行されます。トリガーは、トリガー・イベントが発生したときにデータベースによって暗黙的に起動されます。

関連項目:

- DMLおよびDDLの詳細は、「SQL文の概要」を参照してください。

- 「インスタンスの起動と停止の概要」

トリガーの利点

トリガーを正しく使用すると、ユーザーはデータベースをより効率的に使用するさらに堅牢なアプリケーションを構築してデプロイできます。トリガーは、次のような目的で使用できます。

- 導出列の値の自動的な生成

- 不正なトランザクションの防止

- 監査およびイベント・ロギングの提供

- 表アクセスについての情報の記録

トリガーを使用して、すべてのクライアント・アプリケーションに共通の低レベルでのビジネス・ルールを強制実行できます。たとえば、複数のアプリケーションからemployees表にアクセスできます。この表でのトリガーで挿入されるデータの形式が保証される場合は、クライアントごとにこのビジネス・ロジックを再作成する必要はありません。アプリケーションはトリガーを回避できないため、トリガー内のビジネス・ロジックが自動的に使用されます。

トリガーと整合性制約を併用すると、任意の整合性規則を定義して規定できます。ただし、トリガーを使用するのは、整合性制約を使用して定義できない複雑なビジネス・ルールを強制実行する場合のみにしてください(「データ整合性の概要」を参照)。

トリガーを使用しすぎると相互依存性が複雑になるため、大規模アプリケーションのメンテナンスが困難になります。たとえば、トリガーが起動されると、そのトリガー・アクションに含まれるSQL文によって他のトリガーが起動されてトリガーの連鎖状態になり、意図しない影響が起きる可能性があります。

関連項目:
アプリケーションのトリガーを計画する場合のガイドラインおよび制限の詳細は、『Oracle Database 2日で開発者ガイド』および『Oracle Database PL/SQL言語リファレンス』を参照してください。

トリガーのタイプ

トリガーは、起動方法と実行するアクションのタイプに応じて分類できます。Oracle Databaseは次のタイプのトリガーをサポートしています。

- 行トリガー
行トリガーは、表がトリガーを実行する文の処理の影響を受けるたびに実行されます。たとえば、文が複数の行を更新する場合、UPDATEが処理する行ごとに1つずつ行トリガーが起動されます。トリガーを実行する文の影響を受ける行がなければ、行トリガーは実行されません。トリガー・アクションのコードが、トリガーを実行する文によって供給されるデータまたは影響を受ける行数に依存する場合には、行トリガーが便利です。

- 文トリガー
文トリガーは、トリガーを実行する文の影響を受ける行数とは関係なく、トリガーを実行する文の実行ごとに1回起動されます。たとえば、文が表から100行を削除すると、文レベルのDELETEトリガーが1回のみ起動されます。トリガー・アクションのコードが、トリガーを実行する文によって供給されるデータや、影響を受ける行に依存しない場合には、文トリガーが便利です。

- INSTEAD OFトリガー
INSTEAD OFトリガーは、トリガーを実行する文のかわりに、Oracle Databaseによって起動されます。これらのトリガーは、DML文を介して直接変更できないビューを透過的に変更する場合に便利です。

- イベント・トリガー
トリガーを使用すると、データベース・イベントに関する情報を、サブスクライバに対して発行できます。イベント・トリガーは、次のカテゴリに分類されます。

- システム・イベント・トリガー。データベース・インスタンスの起動および停止またはエラー・メッセージなどのイベントによって起動できます。

- ユーザー・イベント・トリガー。ユーザーのログオンおよびログオフに関連したイベント、DDL文およびDML文によって起動されます。

関連項目:

- 『Oracle Database 2日で開発者ガイド』

- 『Oracle Database PL/SQL言語リファレンス』

トリガーのタイミング

ユーザーは、トリガーのタイミングを定義でき、トリガー・アクションを、トリガーを起動する文の前に実行するか、後に実行するかを指定できます。単純なトリガーは表の単一のトリガーであり、次のいずれか1つのタイミング・ポイントに対してのみアクションを指定できます。

- 起動文の前

- 起動文によって影響を受ける各行の前

- 起動文によって影響を受ける各行の後

- 起動文の後

文および行のトリガーの場合、BEFOREトリガーによってセキュリティを高め、データベースに変更を加える前にビジネス・ルールを有効にできます。アクションのロギングには、AFTERトリガーが理想的です。

複合トリガーは、複数のタイミング・ポイントで起動できます。複合トリガーは、様々なタイミング・ポイントに対して実装するアクションで共通データを共有するためのアプローチをプログラム化する際に役立ちます。

関連項目:
複合トリガーの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

トリガーの作成

CREATE TRIGGER文はデータベース・トリガーを作成または置き換えます。PL/SQLトリガーの一般的な構文形式は次のとおりです。

CREATE TRIGGER trigger_name
triggering_statement
[trigger_restriction]
BEGIN
triggered_action;
END;

PL/SQLトリガーの基本的なコンポーネントは次のとおりです。

- トリガー名
名前は、同じスキーマ内の他のトリガーに対して一意であることが必要です。たとえば、part_reorder_triggerなどの名前にできます。

- トリガー・イベントまたはトリガーを実行する文
トリガー・イベントまたはトリガーを実行する文とは、トリガーを起動させるSQL文、データベース・イベントまたはユーザー・イベントのことです。たとえば、ユーザーによる表の更新などです。

- トリガー制限
トリガー制限にはブール式を指定し、トリガーが起動されるには、そのブール式がtrueになる必要があります。たとえば、引当可能部品の数量が現行の再発注数量より少なくなるまで、トリガーは起動されません。

- トリガー・アクション
トリガー・アクションは、トリガーを実行する文が発行され、トリガーの制限がtrueに評価された場合に実行されるSQL文およびコードを含むプロシージャです。たとえば、ユーザーが保留中のorders表に行を挿入します。

次のようにorders表およびlineitems表を作成するとします。

CREATE TABLE orders
( order_id NUMBER PRIMARY KEY,
/* other attributes */
line_items_count NUMBER DEFAULT 0 );

CREATE TABLE lineitems
( order_id REFERENCES orders,
seq_no   NUMBER,
/* other attributes */
CONSTRAINT lineitems PRIMARY KEY(order_id,seq_no) );

orders表は一意のオーダーごとに行を保持するのに対して、lineitems表は1つのオーダー内の項目ごとに行を保持します。例8-3に、orders表内のオーダーの項目数を自動的に更新するサンプル・トリガーを示します。

例8-3 lineitems_trigger

CREATE OR REPLACE TRIGGER lineitems_trigger
AFTER INSERT OR UPDATE OR DELETE ON lineitems
FOR EACH ROW
BEGIN
IF (INSERTING OR UPDATING)
THEN
UPDATE orders SET line_items_count = NVL(line_items_count,0)+1
WHERE order_id = :new.order_id;
END IF;
IF (DELETING OR UPDATING)
THEN
UPDATE orders SET line_items_count = NVL(line_items_count,0)-1
WHERE order_id = :old.order_id;
END IF;
END;
/

例8-3でトリガーを実行する文は、lineitems表に対するINSERT、UPDATEまたはDELETEです。トリガー制限はありません。変更される行ごとに、トリガーが起動されます。トリガーは、トリガーを実行する文によって影響を受ける現在の行の、新旧の列値にアクセスできます。表の変更対象の列ごとに、古い値(:old)および新しい値(:new)の2つの相関名があります。

あるオーダーについてlineitemsの行を挿入または更新すると、このアクションの後、トリガーによってこのオーダーの項目数が計算され、orders表の数値が更新されます。表8-2に、顧客が2つのオーダーを開始し、オーダーの明細項目を追加および削除する使用例を示します。

表8-2 行レベル・トリガーの使用例

SQL文

トリガーされるSQL文

説明

SQL> INSERT INTO orders
(order_id) VALUES (78);

1 row created.

顧客がID78のオーダーを作成します。この時点で、顧客のオーダーに項目はありません。

lineitems表ではアクションが実行されないため、このトリガーは起動されません。

SQL> INSERT INTO orders
(order_id) VALUES (92);

1 row created.

顧客がID92の別のオーダーを作成します。この時点で、顧客のオーダーに項目はありません。

lineitems表ではアクションが実行されないため、このトリガーは起動されません。

SQL> INSERT INTO lineitems
(order_id, seq_no) VALUES (78,1);

1 row created.

UPDATE orders SET
line_items_count = NVL(NULL,0)+1
WHERE order_id = 78;

顧客がオーダー78に項目を追加します。

INSERTによって、トリガーが起動されます。トリガーされた文が、オーダー78の明細項目数を0から1に増やします。

SQL> INSERT INTO lineitems
(order_id, seq_no) VALUES (78,2);

1 row created.

UPDATE orders SET
line_items_count = NVL(1,0)+1
WHERE order_id = 78;

顧客がオーダー78にさらに項目を追加します。

INSERTによって、トリガーが起動されます。トリガーされた文が、オーダー78の明細項目数を1から2に増やします。

SQL> SELECT * FROM orders;

ORDER_ID LINE_ITEMS_COUNT
--------- ----------------
78                2
92                0

顧客が2つのオーダーのステータスを問い合せます。オーダー78には2つの項目があります。オーダー92には項目がありません。

SQL> SELECT * FROM lineitems;

ORDER_ID     SEQ_NO
---------- ----------
78          1
78          2

顧客は明細項目のステータスを問い合せます。各項目は注文IDと順序番号によって一意に識別されます。

SQL> UPDATE lineitems SET order_id = 92;

2 rows updated.

UPDATE orders SET
line_items_count = NVL(NULL,0)+1
WHERE order_id = 92;

UPDATE orders SET
line_items_count = NVL(2,0)-1
WHERE order_id = 78;

UPDATE orders SET
line_items_count = NVL(1,0)+1
WHERE order_id = 92;

UPDATE orders SET
line_items_count = NVL(1,0)-1
WHERE order_id = 78;

顧客がオーダー78の明細項目をオーダー92に移動します。

UPDATE文はlineitems表の2つの行を変更します。このとき、各行に1回ずつトリガーが起動されます。

トリガーが起動されるたびに、トリガーの両方のIF条件が満たされます。最初の条件はオーダー92の数を増加させるのに対して、2番目の条件はオーダー78の数を減少させます。これにより、合計で4つのUPDATE文が実行されます。

SQL> SELECT * FROM orders;

ORDER_ID LINE_ITEMS_COUNT
--------- ----------------
78                0
92                2

顧客が2つのオーダーのステータスを問い合せます。実際の結果としては、オーダー92の明細項目数が0から2に増加し、オーダー78の数が2から0に減少しています。

SQL> SELECT * FROM lineitems;

ORDER_ID     SEQ_NO
---------- ----------
92          1
92          2

顧客は明細項目のステータスを問い合せます。各項目は注文IDと順序番号によって一意に識別されます。

SQL> DELETE FROM lineitems;

2 rows deleted.

UPDATE orders SET
line_items_count = NVL(2,0)-1
WHERE order_id = 92;

UPDATE orders SET
line_items_count = NVL(1,0)-1
WHERE order_id = 92;

顧客はすべてのオーダーからすべての明細項目を削除します。

DELETE文はlineitems表の2つの行を変更し、このとき、各行に1回ずつトリガーが起動されます。トリガーの起動ごとに、トリガーの片方のIF条件のみが満たされます。毎回、条件によってオーダー92の数を1つずつ減らします。これにより、合計で2つのUPDATE文が実行されます。

SQL> SELECT * FROM orders;

ORDER_ID LINE_ITEMS_COUNT
--------- ----------------
78                0
92                0

SQL> SELECT * FROM lineitems;

no rows selected

顧客が2つのオーダーのステータスを問い合せます。どちらのオーダーにも明細項目がありません。

また、顧客は明細項目のステータスも問い合せます。項目は存在しません。

関連項目:

- トリガーの作成方法の詳細は、『Oracle Database 2日で開発者ガイド』および『Oracle Database PL/SQL言語リファレンス』を参照してください。

- CREATE TRIGGERコマンドの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

トリガーの実行

Oracle Databaseは、サブプログラムの実行と同じ手順を使用してトリガーを内部的に実行します。両者の唯一の違いは、ユーザーがトリガー文を実行する権限を持っていれば、トリガーを起動する権限が付与されることです。この例外を除いて、データベースはストアド・サブプログラムと同じ方法でトリガーを検証して実行します。

関連項目:
トリガー実行の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

トリガーの記憶域

Oracle Databaseでは、PL/SQLストアド・プロシージャと同じように、コンパイル済の形式でデータベース・スキーマにPL/SQLトリガーを格納します。CREATE TRIGGER文がコミットされると、コンパイル済PL/SQLコードがデータベースに格納され、PL/SQLトリガーのソース・コードは共有プールから削除されます。

図8-7に示すデータベース・アプリケーションには、PL/SQLトリガーを暗黙のうちに起動するSQL文が含まれています。トリガーは、それに対応付けられている表とは別々に格納されています。

図8-7 トリガー

Javaトリガーは、PL/SQLトリガーと同じ方法で格納されます。ただし、Javaトリガーでは、CALL文を使用して、個別にコンパイルされたJavaコードを参照します。このため、Javaトリガーを作成する場合は、JavaコードおよびこのJavaコードを参照するトリガーを作成することが必要となります。

関連項目:
トリガーのコンパイルおよび格納の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

第III部

Oracleトランザクションの管理

この部の構成は、次のとおりです。

- 第10章「トランザクション」

- 第9章「データの同時実行性と整合性」

9 データの同時実行性と整合性

この章では、マルチユーザー・データベース環境でのOracle Databaseによるデータ整合性の維持について説明します。

この章の内容は、次のとおりです。

- データの同時実行性と整合性の概要

- Oracle Databaseのトランザクション分離レベルの概要

- Oracle Databaseのロック・メカニズムの概要

- 自動ロックの概要

- 手動データ・ロックの概要

- ユーザー定義ロックの概要

データの同時実行性と整合性の概要

シングル・ユーザーのデータベースでは、他のユーザーが同時に同じデータを変更することがないため、ユーザーは何も心配せずにデータを変更できます。ただし、マルチユーザー・データベースでは、複数のトランザクション内の文によって、同じデータが同時に更新される可能性があります。同時に実行される複数のトランザクションでは、意味のある一貫した結果を出すことが必要です。このため、マルチユーザー・データベースには次の機能が備わっている必要があります。

- データ同時実行性は、複数のユーザーが同時にデータにアクセスできることが保証されます。

- データ整合性は、各ユーザーにデータの一貫したビューが表示され、その中にユーザー自身のトランザクションや他のユーザーのトランザクションによる参照可能な変更も含まれることが保証されます。

複数のトランザクションが同時に実行される場合のトランザクションの首尾一貫した動作を記述するために、データベース研究者はシリアライズ可能性と呼ばれるトランザクションの分離モデルを定義してきました。シリアライズ可能トランザクションは、他のユーザーがデータベースのデータを変更していないように認識される環境内で動作します。

一般に、この程度までのトランザクションの分離が望ましいとされますが、シリアライズ可能モードで数多くのアプリケーションを実行すると、アプリケーションのスループットがかなり低下する可能性があります。同時に実行される各トランザクションの完全な分離とは、あるトランザクションが問合せを実行している表に対して、他のトランザクションが挿入を実行できない状態を指します。つまり、現実には、トランザクションの完全な分離とパフォーマンスとの間の妥協点を考慮する必要があります。

Oracle Databaseでは、マルチバージョン一貫性モデルや様々なタイプのロックおよびトランザクションを使用することによって、データ整合性を維持します。これにより、データベースが複数の同時ユーザーに対してデータのビューを提示する場合、それぞれ特定の時点において一貫性があるビューになります。異なるバージョンのデータ・ブロックが同時に存在する場合があるため、トランザクションでは問合せに要求された時点でコミットされているデータのバージョンが読み取られ、ある特定の時点において一貫性のある結果が戻されます。

関連項目:
第5章「データ整合性」および第10章「トランザクション」

マルチバージョン読取り一貫性

Oracle Databaseでは、マルチバージョン機能によって、複数のバージョンのデータが同時にマテリアライズされます。Oracle Databaseでは、マルチバージョン読取り一貫性が維持され、データベース問合せには次の特徴があります。

- 読取り一貫性問合せ
1つの問合せによって戻されるデータは、コミット済であり、ある特定の時点での一貫性を保っています。

重要:
Oracle Databaseでは、他のトランザクションにおいて未コミットのデータをトランザクションが読み取る場合に発生する、内容を保証しない読取りは許可されていません。

内容を保証しない読取りの問題を具体的に説明するため、あるトランザクションが列値を更新し、その値がまだコミットされていない場合を考えます。2つ目のトランザクションによって、内容が保証されない更新された値(未コミットの値)が読み取られます。その後、1つ目のセッションによってトランザクションがロールバックされ、列の値が元の値に戻された場合でも、2つ目のトランザクションでは更新された値が引き続き使用されるため、データベースが破損します。内容を保証しない読取りでは、データ整合性が損われ、外部キーに違反し、一意制約が無視されます。

- 非ブロック化問合せ
データの読取り側と書込み側が互いに処理をブロックしません(「ロック動作の概要」を参照)。

文レベルの読取り一貫性

Oracle Databaseでは、文レベルの読取り一貫性を常に適用することにより、1つの問合せによって戻されたデータがコミット済で、ある特定の時点で一貫していることを保証します。単一のSQL文の一貫性が保たれる基準となる時点は、トランザクション分離レベルおよび問合せの内容に応じて異なります。

- コミット読取り分離レベルでは、この時点は文が開始されたときになります。たとえば、SCN 1000でSELECT文が開始された場合、この文ではSCN 1000の時点での一貫性が保たれます。

- シリアライズ可能トランザクションまたは読取り専用トランザクションでは、この時点はトランザクションが開始されたときになります。たとえば、複数のSELECT文が実行されるトランザクションがSCN 1000で開始された場合、各文ではSCN 1000の時点での一貫性が保たれます。

- フラッシュバック問合せ操作(SELECT ... AS OF)では、SELECT文で特定の時点が明示的に指定されます。たとえば、先週の木曜日の2:00 p.m時点の表を問い合せることができます。

関連項目:
フラッシュバック問合せの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

トランザクション・レベルの読取り一貫性

Oracle Databaseは、トランザクションのすべての問合せに対して、トランザクション・レベルの読取り一貫性と呼ばれる読取り一貫性を実現することもできます。この場合、トランザクション内の各文には同じ時点(トランザクション開始時)のデータが表示されます。

シリアライズ可能トランザクションによる問合せでは、そのトランザクション自体が変更したデータも参照できます。たとえば、employeesを更新し、employeesを問い合せたトランザクションには、その更新内容が反映されます。トランザクション・レベルの読取り一貫性によってリピータブル・リードが実現され、問合せで仮読取りが検索されなくなります。

読取り一貫性とUNDOセグメント

マルチバージョン読取り一貫性モデルを管理するには、表が同時に問合せおよび更新された場合に、読取り一貫性のある一連のデータがデータベースで作成される必要があります。Oracle Databaseは、UNDOデータを使用してこの機能を実現しています。

ユーザーがデータを変更すると、常にOracle DatabaseによってUNDOエントリが作成されて、UNDOセグメントに書き込まれます(「UNDOセグメント」を参照)。UNDOセグメントには、未コミットのトランザクションや、最近コミットされたトランザクションによって変更されたデータの古い値が含まれています。このため、同じデータの異なる時点の複数のバージョンがデータベース内に存在することになります。データの読取り一貫性ビューを提供し、非ブロック化問合せを可能にするために、データベースでは異なる時点のデータのスナップショットを使用できます。

読取り一貫性は、単一のインスタンス内、およびOracle Real Application Clusters(Oracle RAC)環境内で保証されています。Oracle RACでは、データ・ブロックの読取り一貫性イメージをデータベース・インスタンス間で転送するために、キャッシュ・フュージョンと呼ばれるキャッシュ間ブロック転送メカニズムを使用します。

関連項目:

- LOBの読取り一貫性メカニズムの詳細は、「内部LOB」を参照してください。

- キャッシュ・フュージョンの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

読取り一貫性: 例

図9-1に、コミット読取り分離レベルで、UNDOデータを使用して文レベルの読取り一貫性を提供する問合せの例を示します。

図9-1 コミット読取り分離レベルでの読取り一貫性

問合せによってデータ・ブロックを取得する場合、データベースによって、各ブロックのデータが問合せ開始時のブロックの内容を反映したものになることが保証されます。必要に応じて、ブロックに対する変更がロールバックされ、ブロックが問合せ処理の開始時点の内容に再構成されます。

データベースでは、SCNと呼ばれるメカニズムを使用して、トランザクションの順序が保証されます。SELECT文が実行フェーズに移行すると、データベースによって、問合せの実行開始時点で記録されたSCNが特定されます。図9-1では、このSCNは10023です。問合せでは、SCN 10023に対応したコミット済データが戻されます。

図9-1では、10023よりも後のSCNを持つブロック(SCN 10024の2つのブロック)は変更済データであることが示されています。この場合、SELECT文では、コミット済の変更と一貫性があるバージョンのブロックが必要となります。データベースでは、現在のデータ・ブロックが新しいバッファにコピーされ、前のバージョンのブロックを再構築するためにUNDOデータが適用されます。このように再構築されたデータ・ブロックは、読取り一貫性(CR)クローンと呼ばれます。

図9-1では、データベースによって2つのCRクローンが作成されており、1つのブロックではSCN 10006との一貫性が保たれ、もう1つのブロックではSCN 10021との一貫性が保たれています。問合せに対しては、この再構築されたデータが戻されます。Oracle Databaseでは、このようにして内容を保証しない読取りが回避されています。

関連項目:
「データベース・バッファ・キャッシュ」および「システム変更番号(SCN)」

読取り一貫性とトランザクション表

データベースでは、ブロック・ヘッダー(Interested Transaction List (ITL)とも呼ばれる)の情報を使用して、ブロックの変更が開始された時点でトランザクションがコミットされているかどうかを指定します。各セグメント・ブロックのブロック・ヘッダーには、ITLが含まれています。

ITLのエントリは、ロックされた行のあるトランザクション、およびブロック内のコミット済の変更や未コミットの変更を含む行を表しています。ITLは、データベースに対する変更が行われたタイミングの情報を提供するUNDOセグメント内のトランザクション表を指しています。

ある意味で、ブロック・ヘッダーには、ブロック内の各行に影響を与えたトランザクションの最新の履歴が含まれていると考えられます。CREATE TABLE文およびALTER TABLE文のINITRANSパラメータは、保持するトランザクション履歴の量を制御します。

関連項目:
INITRANSパラメータの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ロックのメカニズム

一般に、マルチユーザー・データベースでは、なんらかのデータ・ロックを使用してデータの同時実行性、一貫性、および整合性の問題を解決しています。ロックは、同じリソースにアクセスしている複数のトランザクション間で破壊的な相互作用が起きないようにするメカニズムです。

関連項目:
「Oracle Databaseのロック・メカニズムの概要」

ANSI/ISOトランザクション分離レベル

ANSIとISO/IECの両方で採用されているSQL規格では、トランザクション分離レベルが4つ定義されています。これらのレベルは、トランザクション処理のスループットに与える影響の度合いが異なります。

これらの分離レベルは、複数のトランザクションを同時に実行する場合に防ぐ必要がある現象という観点から定義されています。回避可能な現象とは、次のものです。

- 内容を保証しない読取り
未コミットのトランザクションが書き込んだデータを、別のトランザクションが読み取る現象。

- 非リピータブル・リード(ファジー読取り)
あるトランザクションが以前に読み取ったデータをもう一度読み取ったときに、コミットされた別のトランザクションによってそのデータが変更または削除されたことが明らかになる現象。たとえば、ユーザーがデータに変更があるかどうかを知るためにのみ、ある行を問い合せ、後で再度同じ行を問い合せるという現象などのことです。

- 仮読取り
あるトランザクションが検索条件を満たす一連の行を戻す問合せを2回実行する間に、コミットされた別のトランザクションによってその条件を満たす新しい行が挿入されたことが明らかになる現象。

たとえば、トランザクションから従業員数を問い合せるとします。5分後に同じ問合せを実行したところ、他のユーザーが新規従業員のレコードを挿入したため、戻される従業員数が1人増えています。問合せ基準を満たすデータは増えていますが、ファジー読取りとは異なり、すでに読み取ったデータは変更されていません。

SQL規格では、それぞれの分離レベルで実行されるトランザクションで起こり得る現象という観点で4つの分離レベルを定義しています。表9-1に、これらのレベルを示します。

表9-1 分離レベル別による回避可能な読取り現象

分離レベル

内容を保証しない読取り

非リピータブル・リード

仮読取り

非コミット読取り

あり

あり

あり

コミット読取り

なし

あり

あり

リピータブル・リード

なし

なし

あり

シリアライズ可能

なし

なし

なし

Oracle Databaseには、コミット読取り(デフォルト)およびシリアライズ可能の分離レベルが用意されています。また、読取り専用モードも提供されています。

関連項目:

- コミット読取り、シリアライズ可能および読取り専用の各分離レベルの詳細は、「Oracle Databaseのトランザクション分離レベルの概要」を参照してください。

- Oracle DatabaseのSQL規格への準拠については、『Oracle Database SQL言語リファレンス』を参照してください。

Oracle Databaseのトランザクション分離レベルの概要

表9-1に、トランザクション分離レベルのANSI規格の概要を示します。この規格は、各分離レベルで許可または防止される現象という観点から定義されています。Oracle Databaseでは、次のトランザクション分離レベルが提供されています。

- コミット読取り分離レベル

- シリアライズ可能分離レベル

- 読取り専用分離レベル

関連項目:

- トランザクション分離レベルの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- SET TRANSACTION ISOLATION LEVELの詳細は、『Oracle Database SQL言語リファレンス』 および『Oracle Database PL/SQL言語リファレンス』 を参照してください。

コミット読取り分離レベル

デフォルトのコミット読取り分離レベルでは、トランザクションによって実行されるすべての問合せにおいて、トランザクション開始前ではなく、問合せ開始前にコミット済のデータのみが戻されます。この分離レベルは、トランザクションの競合がほとんど発生しないデータベース環境に適しています。

コミット読取りトランザクション内の問合せでは、問合せ処理中にコミットされるデータは読み取られません。たとえば、100万行を持つ表の問合せ中に、別のトランザクションによって行950,000への更新がコミットされたとすると、この問合せで行950,000を読み取っても、その変更は反映されていません。ただし、問合せによって読み取られたデータを他のトランザクションが変更することは可能であるため、複数の問合せ実行の間にデータが変更される可能性があります。このため、同じ問合せを2回実行するトランザクションでは、ファジー読取りと仮読取りが発生する可能性があります。

コミット読取り分離レベルでの読取り一貫性

ユーザーが何もしなくても、あらゆる問合せに対して一貫した結果セットが保証され、データ整合性が保証されます。UPDATE文のWHERE句などで使用される暗黙的問合せでは、一貫した結果セットが保証されます。ただし、暗黙的問合せ内の各文では、そのDML文自体によって行われた変更は参照されず、変更前に存在したデータが参照されます。

SELECT文のリストにPL/SQLファンクションが含まれる場合、親SQLレベルではなくPL/SQLファンクション・コード内で実行されるSQL文のレベルにおいて、文レベルの読取り一貫性が適用されます。たとえば、ファンクションは、別のユーザーがデータを変更およびコミットした表にアクセスする場合があります。ファンクション内のSELECTの実行ごとに、読取り一貫性を備えた新しいスナップショットが設定されます。

関連項目:
「副問合せおよび暗黙的問合せ」

コミット読取りトランザクション内での書込みの競合

コミット読取りトランザクションでは、未コミットの同時実行トランザクション(ブロックしているトランザクションとも呼ばれる)によって更新された行の変更を試行すると、書込みの競合が発生します。コミット読取りトランザクションは、ブロックしているトランザクションが終了して行ロックが解除されるまで待機します。次の2通りの場合があります。

- ブロックしているトランザクションがロールバックされた場合、待機しているトランザクションでは、ブロックしているトランザクションが存在していなかったかのように、ロックされていた行が変更されます。

- ブロックしているトランザクションがコミットされてロックが解除された場合、待機しているトランザクションでは、新たに変更された行に対して更新が実行されます。

表9-2に、トランザクション1(シリアライズ可能トランザクションまたはコミット読取りトランザクション)とコミット読取りトランザクション2との間の相互作用を示します。表9-2では、更新内容の消失として知られる典型的な状況について説明します(「ロックの使用」を参照)。トランザクション1の更新内容は、コミットされましたが表に反映されていません。このような更新内容の消失の問題をいかに回避するかは、アプリケーション開発の重要な点です。

表9-2 READ COMMITTEDトランザクションにおける書込みの競合と更新内容の消失

セッション1

セッション2

説明

SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               6200
Greene              9500

セッション1で、Banda、GreeneおよびHintzの給与を問い合せます。Hintzという名前の従業員が見つかりません。

SQL> UPDATE employees SET salary
= 7000 WHERE last_name = 'Banda';

セッション1で、Bandaの給与を更新することによってトランザクションを開始します。トランザクション1のデフォルトの分離レベルは、READ COMMITTEDです。

SQL> SET TRANSACTION ISOLATION
LEVEL READ COMMITTED;

セッション2でトランザクション2を開始して、分離レベルを明示的にREAD COMMITTEDに設定します。

SQL> SELECT last_name, salary
FROM employees WHERE last_name IN
('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               6200
Greene              9500

トランザクション2で、Banda、GreeneおよびHintzの給与を問い合せます。Oracle Databaseでは読取り一貫性が使用され、トランザクション1によって行われた未コミットの更新前のBandaの給与を表示します。

SQL> UPDATE employees SET salary =
9900 WHERE last_name = 'Greene';

トランザクション1ではBandaの行のみがロックされているため、トランザクション2でGreeneの給与が正常に更新されます(「行ロック(TX)」を参照)。

SQL> INSERT INTO employees
(employee_id, last_name, email,
hire_date, job_id) VALUES (210,
'Hintz', 'JHINTZ', SYSDATE,
'SH_CLERK');

トランザクション1で、従業員Hintzの行を挿入しますが、コミットはしません。

SQL> SELECT last_name, salary
FROM employees WHERE last_name IN
('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               6200
Greene              9900

トランザクション2で、従業員Banda、GreeneおよびHintzの給与を問い合せます。

トランザクション2では、このトランザクション自体で更新したGreeneの給与を参照できます。トランザクション2では、トランザクション1によって行われた未コミットのBandaの給与の更新やHintzの挿入は参照できません。

SQL> UPDATE employees SET salary =
6300 WHERE last_name = 'Banda';

-- prompt does not return

トランザクション2で、現在トランザクション1によってロックされているBandaの行の更新を試行したため、書込みの競合が発生します。トランザクション2は、トランザクション1の終了を待機します。

SQL> COMMIT;

トランザクション1では作業をコミットし、トランザクションを終了します。

1 row updated.

SQL>

Bandaの行に対するロックが解除されたため、トランザクション2ではBandaの給与が更新されます。

SQL> SELECT last_name, salary
FROM employees WHERE last_name IN
('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               6300
Greene              9900
Hintz

トランザクション2で、従業員Banda、GreeneおよびHintzの給与を問い合せます。トランザクション1によってコミットされたHintzの行の挿入がトランザクション2でも参照可能になりました。トランザクション2では、このトランザクション自体で行ったBandaの給与への更新が表示されます。

COMMIT;

トランザクション2では作業をコミットし、トランザクションを終了します。

SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               6300
Greene              9900
Hintz

セッション1で、Banda、GreeneおよびHintzの行を問い合せます。Bandaの給与は6300ですが、これはトランザクション2で更新された値です。トランザクション1でBandaの給与を7000に更新しましたが、この更新内容は消失しました。

シリアライズ可能分離レベル

シリアライズ可能分離レベルでは、問合せ開始時ではなく、トランザクション開始時にコミット済の変更およびこのトランザクション自体が行った変更のみを参照できます。シリアライズ可能トランザクションは、他のユーザーがデータベースのデータを変更していないように認識される環境内で動作します。

シリアライズ可能な分離は、次のような環境に適しています。

- 大規模データベースを使用し、短いトランザクションでごく少数の行しか更新しない環境。

- 2つの同時実行トランザクションが同一の行を更新するようなことが比較的少ない環境。

- 比較的長時間にわたって実行されるトランザクションが主に読取り専用である環境。

シリアライズ可能分離では、通常は文レベルで確保される読取り一貫性が、トランザクション全体に拡張されます。トランザクションによって読み取られるすべての行は、再度読み取っても同じであることが保証されます。トランザクション実行中は、問合せによって戻される結果が同じであることが保証されるため、トランザクションの実行時間に関係なく、他のトランザクションによる変更は問合せで参照できません。シリアライズ可能トランザクションでは、内容を保証しない読取り、ファジー読取りまたは仮読取りの現象は発生しません。

Oracle Databaseの場合、シリアライズ可能トランザクションでは、他のトランザクションで変更され、シリアライズ可能トランザクションが開始されたときにすでにコミットされている行のみ変更できます。シリアライズ可能トランザクションが、その開始後にコミットされた別のトランザクションによって変更されたデータの更新または削除を試行すると、データベースでは次のようなエラーが生成されます。

ORA-08177: Cannot serialize access for this transaction

シリアライズ可能トランザクションでORA-08177エラーが発生した場合、アプリケーションでは次のいずれかのアクションを実行できます。

- 実行した作業をそのポイントまでコミットします。

- 追加の(異なる)文を実行します(トランザクション内で以前に設定したセーブポイントまでロールバックした後など)。

- トランザクション全体をロールバックします。

表9-3に、シリアライズ可能トランザクションと他のトランザクションとの間の相互作用を示します。シリアライズ可能トランザクションにおいては、シリアライズ可能トランザクションの開始後に他のトランザクションでコミットされた行の変更を試行しなければ、シリアライズ・アクセスの問題を回避できます。

表9-3 シリアライズ可能トランザクション

セッション1

セッション2

説明

SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               6200
Greene              9500

セッション1で、Banda、GreeneおよびHintzの給与を問い合せます。Hintzという名前の従業員が見つかりません。

SQL> UPDATE employees SET salary
= 7000 WHERE last_name = 'Banda';

セッション1で、Bandaの給与を更新することによってトランザクション1を開始します。デフォルトの分離レベルは、READ COMMITTEDです。

SQL> SET TRANSACTION ISOLATION
LEVEL SERIALIZABLE;

セッション2でトランザクション2を開始して、SERIALIZABLE分離レベルに設定します。

SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               6200
Greene              9500

トランザクション2で、Banda、GreeneおよびHintzの給与を問い合せます。Oracle Databaseでは読取り一貫性が使用され、トランザクション1によって行われた未コミットの更新前のBandaの給与を表示します。

SQL> UPDATE employees SET salary =
9900 WHERE last_name = 'Greene';

Bandaの行のみがロックされているため、トランザクション2でGreeneの給与は正常に更新されます。

SQL> INSERT INTO employees
(employee_id, last_name, email,
hire_date, job_id) VALUES (210,
'Hintz', 'JHINTZ', SYSDATE,
'SH_CLERK');

トランザクション1で、従業員Hintzの行を挿入します。

SQL> COMMIT;

トランザクション1では作業をコミットし、トランザクションを終了します。

SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               7000
Greene              9500
Hintz

SQL> SELECT last_name, salary
FROM employees WHERE last_name IN
('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               6200
Greene              9900

セッション1で従業員Banda、GreeneおよびHintzの給与を問い合せると、トランザクション1によってコミットされた変更が表示されます。セッション1では、トランザクション2での未コミットのGreeneの更新は参照できません。

トランザクション2で、従業員Banda、GreeneおよびHintzの給与を問い合せます。Oracle Databaseの読取り一貫性により、トランザクション1でコミットされたHintzの行の挿入およびBandaの更新は、トランザクション2では表示されません。トランザクション2では、このトランザクション自体で行ったBandaの給与への更新が表示されます。

COMMIT;

トランザクション2では作業をコミットし、トランザクションを終了します。

SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               7000
Greene              9900
Hintz

SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               7000
Greene              9900
Hintz

両方のセッションで、Banda、GreeneおよびHintzの給与を問い合せます。両方のセッションで、トランザクション1およびトランザクション2で行われたコミット済のすべての変更を参照できます。

SQL> UPDATE employees SET salary
= 7100 WHERE last_name = 'Hintz';

セッション1で、Hintzの給与を更新することによってトランザクション3を開始します。トランザクション3のデフォルトの分離レベルは、READ COMMITTEDです。

SQL> SET TRANSACTION ISOLATION
LEVEL SERIALIZABLE;

セッション2でトランザクション4を開始して、SERIALIZABLE分離レベルに設定します。

SQL> UPDATE employees SET salary =
7200 WHERE last_name = 'Hintz';

-- prompt does not return

トランザクション4で、Hintzの給与の更新を試みますが、トランザクション3でHintzの行がロックされているためにブロックされます(「行ロック(TX)」を参照)。トランザクション4は、トランザクション3の後のキューに入ります。

SQL> COMMIT;

トランザクション3でHintzの給与の更新をコミットして、トランザクションを終了します。

UPDATE employees SET salary = 7200
WHERE last_name = 'Hintz'
*
ERROR at line 1:
ORA-08177: can't serialize access
for this transaction

コミットしてトランザクション3を終了することによって、トランザクション4におけるHintzの更新はORA-08177エラーが発生して失敗します。この問題は、トランザクション4が開始された後にトランザクション3でHintzの更新をコミットしたことによって発生します。

SQL> ROLLBACK;

セッション2で、トランザクション4をロールバックして終了します。

SQL> SET TRANSACTION ISOLATION
LEVEL SERIALIZABLE;

セッション2でトランザクション5を開始して、SERIALIZABLE分離レベルに設定します。

SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');

LAST_NAME         SALARY
------------- ----------
Banda               7100
Greene              9500
Hintz               7100

トランザクション5で、Banda、GreeneおよびHintzの給与を問い合せます。トランザクション3によってコミットされたHintzの給与の更新を参照できます。

SQL> UPDATE employees SET salary =
7200 WHERE last_name = 'Hintz';

1 row updated.

トランザクション5で、Hintzの給与を異なる値に更新します。トランザクション5が開始される前にトランザクション3でのHintzの更新をコミットしているため、シリアライズ・アクセスの問題は回避されます。

注意: トランザクション5が開始された後に、別のトランザクションでHintzの行を更新してコミットした場合は、再度シリアライズ・アクセスの問題が発生します。

SQL> COMMIT;

セッション2で、問題なく更新をコミットして、トランザクションを終了します。

関連項目:
「トランザクション制御の概要」

読取り専用分離レベル

読取り専用分離レベルはシリアライズ可能分離レベルと類似していますが、読取り専用トランザクションでは、SYSユーザー以外はトランザクションでデータを変更できません。このため、読取り専用トランザクションでは、ORA-08177エラーは発生しません。読取り専用トランザクションは、トランザクション開始時点での一貫性を保つ必要があるレポートの生成に役立ちます。

Oracle Databaseでは、必要に応じてUNDOセグメントからデータを再構築することによって、読取り一貫性を実現しています。UNDOセグメントは循環方式で使用されるため、データベースではUNDOデータを上書きできます。長時間実行されるレポートでは、読取り一貫性を保つために必要なUNDOデータが他のトランザクションによって再利用され、snapshot too oldというエラーが発生することがあります。UNDO保存期間とは、古いUNDOデータを上書きしないで保存する最低期間のことで、この期間を設定することにより、この問題を適切に回避できます。

関連項目:

- 「UNDOセグメント」

- UNDO保存期間の設定方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

Oracle Databaseのロック・メカニズムの概要

ロックとは、共有データにアクセスする複数のトランザクション間で不正確なデータの更新または基礎となるデータ構造の不正な変更を引き起こす、破壊的な相互作用を防止するためのメカニズムのことです。ロックは、データベースの同時実行性および一貫性を維持するために非常に重要です。

ロック動作の概要

データベースでは、ロックを取得する操作に応じて、複数のタイプのロックが使用されます。一般に、データベースでは、排他ロックと共有ロックの2種類のロックが使用されます。排他ロックは、1つのリソース(行や表など)に対して1つのみ取得でき、共有ロックは、1つのリソースに対して複数取得できます。

ロックは、読取り側と書込み側の相互作用に影響を与えます。読取り側とはリソースの問合せを指し、書込み側とはリソースを変更する文を指します。次に、Oracle Databaseにおける、読取り側と書込み側に対するロック動作の概要を示します。

- 行は、書込み側によって変更される場合にのみロックされます。
文がある行を更新する場合、そのトランザクションはその行に対してのみロックを取得します。行レベルで表データをロックすることによって、同一のデータに対する競合が最小限に抑えられます。通常は、行ロックがブロック・レベルや表レベルに拡大されることはありません(脚注 1)。

- 行の書込み側は、同じ行に対する同時書込みをブロックします。
あるトランザクションで行を変更している場合は、行ロックによって、他のトランザクションからの同じ行に対する同時変更が防止されます。

- 読取り側が書込み側をブロックすることはありません。
行の読取り側は行をロックしないため、書込み側はこの行を変更できます。唯一の例外はSELECT ... FOR UPDATE文で、この文はSELECT文の特殊なタイプであり、読取り中の行をロックします。

- 書込み側が読取り側をブロックすることはありません。
行が書込み側によって変更されている場合、データベースでは、UNDOデータを使用して読込み側に一貫性のある行のビューが表示されます。

注意:
保留中の分散トランザクションにおける非常に特殊な状況では、データを読み取るために、同じデータ・ブロックへの書込みの待機が必要になることもあります。

関連項目:

- SELECT ... FOR UPDATEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- インダウト分散トランザクションに関連する待機の詳細は、『Oracle Database管理者ガイド』を参照してください。

ロックの使用

シングル・ユーザーのデータベースでは、情報を変更するのは1人のユーザーのみであるため、ロックは必要ありません。ただし、複数のユーザーがデータにアクセスして変更する場合、データベースには、同じデータに対する同時変更を防止する手段が必要です。ロックによって、次のようなデータベースの重要な要件を満たすことが可能になります。

- 一貫性
あるセッションが表示または変更しているデータは、そのユーザーがデータの使用を終了するまで他のセッションでは変更できません。

- 整合性
データおよび構造には、すべての変更内容が適切な順序で反映される必要があります。

Oracle Databaseでは、ロック・メカニズムを使用して、トランザクション間のデータの同時実行性、一貫性および整合性を実現します。 ロックは自動的に実行されるため、ユーザーの操作は必要ありません。

ロックの必要性については、単一の行に対する同時更新で説明できます。次の例では、単純なWebベースのアプリケーションによって、エンド・ユーザーに対して従業員の電子メールおよび電話番号が表示されます。アプリケーションでは、次のようなUPDATE文を使用してデータが変更されます。

UPDATE employees
SET    email = ?, phone_number = ?
WHERE  employee_id = ?
AND    email = ?
AND    phone_number = ?

この例のUPDATE文では、WHERE句中の電子メールと電話番号は、特定の従業員についての変更前の元の値です。この更新では、アプリケーションで変更される行は、最後に読み取られてユーザーに表示された後、変更されていないことが保証されます。このようにして、アプリケーションでは、あるユーザーによって行われた変更を他のユーザーが上書きして更新内容が消失する、データベースの更新内容の消失の問題が回避されます(更新内容の消失の例は、表9-2を参照)。

表9-4に、2つのセッションがほぼ同時にemployees表の同じ行の変更を試行した場合の一連のイベントを示します。

表9-4 行ロックの例

時間

セッション1

セッション2

説明

t0

SELECT employee_id, email,
phone_number
FROM   hr.employees
WHERE  last_name = 'Himuro';

EMPLOYEE_ID EMAIL   PHONE_NUMBER
----------- ------- ------------
118 GHIMURO 515.127.4565

セッション1で、hr1ユーザーがhr.employeesのHimuroのレコードを問い合せて、employee_id(118)、email(GHIMURO)およびphone_number(515.127.4565)属性を表示します。

t1

SELECT employee_id, email,
phone_number
FROM   hr.employees
WHERE  last_name = 'Himuro';

EMPLOYEE_ID EMAIL   PHONE_NUMBER
----------- ------- ------------
118 GHIMURO 515.127.4565

セッション2で、hr2ユーザーがhr.employeesのHimuroのレコードを問い合せて、employee_id(118)、email(GHIMURO)およびphone_number(515.127.4565)属性を表示します。

t2

UPDATE hr.employees
SET phone_number='515.555.1234'
WHERE employee_id=118
AND email='GHIMURO'
AND phone_number='515.127.4565';

1 row updated.

セッション1で、hr1ユーザーがこの行の電話番号を515.555.1234に更新します。この場合、GHIMUROの行に対してロックを取得します。

t3

UPDATE hr.employees
SET phone_number='515.555.1235'
WHERE employee_id=118
AND email='GHIMURO'
AND phone_number='515.127.4565';

-- SQL*Plus does not show
-- a row updated message or
-- return the prompt.

セッション2で、hr2ユーザーが同じ行を更新しようとしますが、現在hr1がその行を処理中であるためブロックされます。

hr2による更新は、hr1による更新とほぼ同時に試行されました。

t4

COMMIT;

Commit complete.

セッション1で、hr1ユーザーがトランザクションをコミットします。

このコミットによってHimuroに対する変更が確定され、待機しているセッション2のブロックが解除されます。

t5

0 rows updated.

セッション2で、hr2ユーザーは、GHIMUROの行が変更されたため、条件に一致しなくなったことに気付きます。

条件が一致しないため、セッション2ではレコードが更新されません。

t6

UPDATE hr.employees
SET phone_number='515.555.1235'
WHERE employee_id=118
AND email='GHIMURO'
AND phone_number='515.555.1234';

1 row updated.

セッション1で、hr1ユーザーは、GHIMUROの行を誤った電話番号で更新したことに気付きます。そのためユーザーは新たにトランザクションを開始して、この行の電話番号を515.555.1235に更新し、これによりGHIMUROの行がロックされます。

t7

SELECT employee_id, email,
phone_number
FROM   hr.employees
WHERE  last_name = 'Himuro';

EMPLOYEE_ID EMAIL   PHONE_NUMBER
----------- ------- ------------
118 GHIMURO 515.555.1234

セッション2で、hr2ユーザーは、hr.employeesのHimuroのレコードを問い合せます。レコードには、t4でセッション1によってコミットされた電話番号の更新内容が表示されます。Oracle Databaseの読取り一貫性によって、セッション2ではt6の未コミットの変更は表示されません。

t8

UPDATE hr.employees
SET phone_number='515.555.1235'
WHERE employee_id=118
AND email='GHIMURO'
AND phone_number='515.555.1234';

-- SQL*Plus does not show
-- a row updated message or
-- return the prompt.

セッション2で、hr2ユーザーが同じ行を更新しようとしますが、現在hr1がその行を処理中であるためブロックされます。

t9

ROLLBACK;

Rollback complete.

セッション1で、hr1ユーザーがトランザクションをロールバックして終了します。

t10

1 row updated.

セッション1による更新がロールバックされたため、セッション2による電話番号の更新は成功します。GHIMUROの行が条件に一致するため、更新は成功します。

t11

COMMIT;

Commit complete.

セッション2で、更新をコミットして、トランザクションを終了します。

Oracle Databaseでは、SQL文を実行するときに、必要なロックを自動的に取得します。たとえば、セッションによるデータの変更が許可される前に、最初にデータをロックする必要があります。ロックによってセッションは更新対象データに対する排他制御を取得するため、ロックが解除されるまでは他のトランザクションはロックされたデータを変更できません。

Oracle Databaseのロック・メカニズムはトランザクション制御と密接に結び付けられているため、アプリケーション設計者がトランザクションを適切に定義するのみで、ロックはOracle Databaseによって自動的に管理されます。ユーザーはリソースを明示的にロックする必要はありませんが、Oracle Databaseには、ユーザーが手動でデータをロックするための方法も用意されています。

次の項では、Oracle Databaseでデータの同時実行性が実現される方法を理解するために重要な概念について説明します。

関連項目:
更新内容の消失の防止に役立つサブプログラムを含むOWA_OPT_LOCKパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

ロック・モード

Oracle Databaseでは、最高水準のデータ同時実行性を実現しながらフェイルセーフなデータの整合性を確保するため、可能なかぎり低い制限レベルが自動的に使用されます。制限レベルが低いほど、他のユーザーによるデータへのアクセスがより容易になります。逆に、制限レベルが高いほど、他のトランザクションで取得できるロックのタイプがより制限されます。

Oracle Databaseでは、マルチユーザー・データベースで2つのロック・モードを使用します。

- 排他ロック・モード
このモードは、関連リソースの共有を防止します。トランザクションでは、データを変更するときに排他ロックを取得します。リソースを排他的にロックした最初のトランザクションは、その排他ロックが解除されるまで、そのリソースを変更できる唯一のトランザクションになります。

- 共有ロック・モード
このモードでは、操作の種類に応じて、関連するリソースの共有が可能です。データの読取りを実行する複数のユーザーはそのデータを共有でき、また共有ロックを保持することによって、排他ロックを必要とする書込みユーザーの同時アクセスを防ぎます。複数のトランザクションが同じリソースについて共有ロックを取得できます。

あるトランザクションで、SELECT ... FOR UPDATE文を使用して単一の表の行を選択するとします。このトランザクションでは、排他行ロックおよび行共有表ロックを取得します。行ロックでは、他のセッションは、ロックされた行以外の任意の行を変更できますが、表ロックでは、他のセッションによる表の構造の変更が禁止されます。したがって、データベースでは、任意の数の文を実行できます。

ロック変換とロックの段階的拡大

Oracle Databaseでは、必要に応じてロック変換が実行されます。ロック変換は、低い制限の表ロックを、より高い制限の表ロックに自動的に変換します。

たとえば、あるトランザクションで特定の従業員に対するSELECT ... FOR UPDATEを発行し、その後ロックされた行を更新するとします。この場合、データベースでは、行共有表ロックが行排他表ロックに自動的に変換されます。トランザクションは、トランザクション内で挿入、更新または削除の対象になる行すべてに対して排他ロックを保持します。行ロックは、制限の最も高い程度で取得されるため、ロック変換はまったく必要なく、実行されません。

ロック変換は、あるレベル(行レベルなど)で多数のロックが保持されている場合に、各ロックをデータベースが上位レベルの粒度(表レベルなど)の別のロックに拡大するロックの段階的拡大とは異なります。あるユーザーが表の中の多数の行をロックした場合、データベースによっては、行ロックが単一の表ロックに自動的に拡大される場合があります。ロックの数は少なくなりますが、ロックされている対象の制限は大きくなります。

Oracle Databaseでは、ロックの段階的拡大が発生することはありません。ロックの段階的拡大はデッドロックの可能性を大幅に増します。たとえば、システムがトランザクション1のためにロックの拡大を試行しますが、トランザクション2によって保持されているロックのために拡大できないとします。トランザクション2の処理を続行するために同じデータのロックの段階的拡大が必要な場合、デッドロックが発生します。

ロックの期間

Oracle Databaseでは、なんらかのイベントが発生し、トランザクションがそのリソースを必要としなくなると、ロックは自動的に解除されます。ほとんどの場合、トランザクション内の文で取得したロックは、トランザクションの存続期間中保持されます。これらのロックによって、同時トランザクションによる内容を保証しない読取り、更新内容の消失、有害なDDLなどの破損を招く干渉を防止できます。

注意:
外部キーに索引が作成されていないために子表に対して設定される表ロックは、トランザクション存続期間中ではなく、文の存続期間中のみ保持されます。また、「ユーザー定義ロックの概要」で説明しているように、DBMS_LOCKパッケージを使用すると、ユーザー定義のロックを自由に割当ておよび解除でき、トランザクションの境界を越えて保持することもできます。

Oracle Databaseでは、トランザクションをコミットまたはロールバックすると、そのトランザクション内の文で取得したすべてのロックが解除されます。また、Oracle Databaseでは、セーブポイントまでロールバックすると、そのセーブポイントより後で取得されたロックが解除されます。ただし、ロックを解除されて使用可能となったリソースに対してロックを取得できるのは、ロック中だったリソースを待機していなかったトランザクションのみです。ロック中のリソースを待機していたトランザクションは、元のトランザクションが完全にコミットまたはロールバックされるまで待機し続けます(表10-2の例を参照)。

関連項目:
「セーブポイントへのロールバック」

ロックとデッドロック

デッドロックとは、2人以上のユーザーが、相手がロックしているデータをお互いに待機している状況を指します。デッドロックが発生すると、トランザクションの処理を継続できなくなる場合があります。

Oracle Databaseでは、デッドロックを自動的に検出し、そのデッドロックに関係する文の一方をロールバックして、競合する一連の行ロックを解放することにより、デッドロックを解決します。また、データベースでは、文レベルのロールバックが実行されたトランザクションに対して対応するメッセージが戻されます。ロールバックされる文は、デッドロックが検出されたトランザクションに属しています。通常、通知されたトランザクションは明示的にロールバックする必要がありますが、待機した後でロールバック文を再試行できます。

表9-5に、デッドロック状態の2つのトランザクションを示します。

表9-5 デッドロック・トランザクション

時間

セッション1

セッション2

説明

t0

SQL> UPDATE employees
SET salary = salary*1.1
WHERE employee_id = 100;

1 row updated.

SQL> UPDATE employees
SET  salary = salary*1.1
WHERE employee_id = 200;

1 row updated.

セッション1でトランザクション1を開始して、従業員100の給与を更新します。セッション2でトランザクション2を開始して、従業員200の給与を更新します。各トランザクションでは、そのトランザクションで更新する行のみがロックされるため、問題は発生しません。

t1

SQL> UPDATE employees
SET salary = salary*1.1
WHERE employee_id = 200;

-- prompt does not return

SQL> UPDATE employees
salary = salary*1.1
WHERE employee_id = 100;

-- prompt does not return

トランザクション1で、現在トランザクション2でロックされている従業員200の行の更新を試行します。トランザクション2で、現在トランザクション1でロックされている従業員100の行の更新を試行します。

どちらのトランザクションでも、処理を続行または終了するために必要なリソースを取得できないため、デッドロックが発生します。各トランザクションがいくら待機しても、競合するロックは保持されたままです。

t2

UPDATE employees
*
ERROR at line 1:
ORA-00060: deadlock detected
while waiting for resource

SQL>

トランザクション1でデッドロックが検出されて、t1で発行されたUPDATE文がロールバックされます。ただし、t0で行われた更新はロールバックされません。セッション1にプロンプトが戻されます。

注意: デッドロック状態になっているセッションのうちの一方のみが実際にデッドロック・エラーを受信しますが、どちらのセッションもエラーになる可能性があります。

t3

SQL> COMMIT;

Commit complete.

セッション1で、t0で行った更新をコミットして、トランザクション1を終了します。t1で正常に行われなかった更新はコミットされません。

t4

1 row updated.

SQL>

トランザクション1によってブロックされていた、t1でのトランザクション2による更新が実行されます。プロンプトが戻されます。

t5

SQL> COMMIT;

Commit complete.

セッション2で、t0およびt1において行った更新をコミットして、トランザクション2を終了します。

デッドロックが最も頻繁に発生するのは、トランザクションがOracle Databaseのデフォルト・ロックを明示的にオーバーライドする場合です。Oracle Databaseではロックの段階的拡大は実行されず、問合せで読取りロックは使用されませんが、行レベルのロック(ページ・レベルのロックではありません)のみは使用されるため、デッドロックはほとんど起こりません。

関連項目:

- 「手動データ・ロックの概要」

- 明示的に表をロックしたときのデッドロックの処理方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

自動ロックの概要

Oracle Databaseのトランザクションでは、同じリソースに対する排他的アクセスを必要とする処理が他のトランザクションで行われないように、自動的にリソースがロックされます。データベースは、リソースおよび実行される操作に応じて、様々な制限レベルの様々なタイプのロックを自動的に取得します。

注意:
単純な読取り時に行がロックされることはありません。

Oracle Databaseのロックは、次のカテゴリに分類されます。

ロック

説明

DMLロック

データを保護します。たとえば、表ロックは表全体をロックし、行ロックは選択された行をロックします。「DMLロック」を参照してください。

DDLロック

スキーマ・オブジェクトの構造、たとえば表とビューのディレクトリ定義を保護します。「DDLロック」を参照してください。

システム・ロック

データファイルなどの内部データベース構造を保護します。ラッチ、mutexおよび内部ロックは完全に自動的です。「システム・ロック」を参照してください。

DMLロック

DMLロックは、データ・ロックとも呼ばれ、複数のユーザーが同時にアクセスするデータの整合性を保証します。たとえば、DMLロックでは、オンライン書店で最後の1冊を2人の顧客が購入可能になることを防止できます。DMLロックは、同時に実行される矛盾する複数のDML操作またはDDL操作の破損を招く干渉を防ぎます。

DML文では、次のタイプのロックを自動的に取得します。

- 行ロック(TX)

- 表ロック(TM)

後続の項において、それぞれのタイプのロックまたはロック・モードの後のカッコ内にある頭字語は、Oracle Enterprise Manager(Enterprise Manager)のロック・モニターで使用される略称です。Enterprise Managerでは、表ロックのモード(RSやSRXなど)が示されるかわりに、すべての表ロックにTMと表示される可能性があります。

関連項目:
「Oracle Enterprise Manager」

行ロック(TX)

行ロックは、TXロックとも呼ばれ、表の単一の行に対するロックです。トランザクションでは、INSERT、UPDATE、DELETE、MERGEまたはSELECT ... FOR UPDATE文によって変更される各行で行ロックを取得します。行ロックは、トランザクションがコミットまたはロールバックされるまで存在します。

行ロックは、主に2つのトランザクションによる同じ行の変更を防止するためのキューイング・メカニズムとして機能します。変更される行は常に排他モードでロックされるため、ロックを保持しているトランザクションがコミットまたはロールバックされるまで、他のトランザクションはその行を変更できません。行ロックでは、最もきめの細かいロックが実現されるため、最高の同時実行性とスループットが得られます。

注意:
データベースのインスタンス障害が原因でトランザクションが終了した場合は、トランザクション全体がリカバリされる前に、ブロックレベルのリカバリによって行が使用可能になります。

ある行のロックを取得したトランザクションは、その行を含む表のロックも取得します。表ロックがあると、現行のトランザクションでのデータ変更をオーバーライドするDDL操作の競合が回避されます。図9-2に、表の行3を更新する例を示します。Oracle Databaseでは、更新される行には排他ロックが、表には副排他ロックが自動的に設定されます。

図9-2 行ロックと表ロック

行ロックと同時実行性

表9-6に、Oracle Databaseの行ロックによって同時実行性が確保される例を示します。3つのセッションから同時に同じ行を問い合せます。セッション1およびセッション2では異なる行に対してコミットせずに更新しますが、セッション3では更新は行われません。各セッションでは、そのセッション自体で行った未コミットの更新を参照できますが、他のセッションによる未コミットの更新は参照できません。

表9-6 データ同時実行性の例

時間

セッション1

セッション2

セッション3

説明

t0

SELECT employee_id,
salary FROM employees
WHERE  employee_id
IN ( 100, 101 );

EMPLOYEE_ID  SALARY
-----------  ------
100          512
101          600

SELECT employee_id,
salary FROM employees
WHERE  employee_id
IN ( 100, 101 );

EMPLOYEE_ID  SALARY
-----------  ------
100          512
101          600

SELECT employee_id,
salary FROM employees
WHERE  employee_id
IN ( 100, 101 );

EMPLOYEE_ID  SALARY
-----------  ------
100          512
101          600

3つの異なるセッションから、従業員100および101のIDと給与を同時に問い合せます。それぞれの問合せからは、同じ結果が戻されます。

t1

UPDATE hr.employees
SET salary=salary+100
WHERE employee_id=100;

セッション1で従業員100の給与を更新しますが、コミットはしません。更新時には、書込み側は更新する行に対してのみ行レベル・ロックを取得して、他の書込み側からこの行を変更されないようにします。

t2

SELECT employee_id,
salary FROM employees
WHERE  employee_id
IN ( 100, 101 );

EMPLOYEE_ID  SALARY
-----------  ------
100          612
101          600

SELECT employee_id,
salary FROM employees
WHERE  employee_id
IN ( 100, 101 );

EMPLOYEE_ID  SALARY
-----------  ------
100          512
101          600

SELECT employee_id,
salary FROM employees
WHERE  employee_id
IN ( 100, 101 );

EMPLOYEE_ID  SALARY
-----------  ------
100          512
101          600

各セッションが、同時に元の問合せを発行します。セッション1では、t1での更新結果が反映された給与612が表示されます。セッション2およびセッション3における読取りでは、セッション1のトランザクション終了を待機せず、即座に行が戻されます。データベースでは、セッション1での更新前の状態の給与を表示するためにマルチバージョン読取り一貫性が使用されます。

t3

UPDATE hr.employees
SET salary=salary+100
WHERE employee_id=101;

セッション2で従業員101の給与を更新しますが、トランザクションをコミットしません。更新時には、書込み側は更新する行に対してのみ行レベル・ロックを取得して、他のセッションからこの行が変更されないようにします。

t4

SELECT employee_id,
salary FROM employees
WHERE  employee_id
IN ( 100, 101 );

EMPLOYEE_ID  SALARY
-----------  ------
100          612
101          600

SELECT employee_id,
salaryFROM employees
WHERE  employee_id
IN ( 100, 101 );

EMPLOYEE_ID  SALARY
-----------  ------
100          512
101          700

SELECT employee_id,
salary FROM employees
WHERE  employee_id
IN ( 100, 101 );

EMPLOYEE_ID  SALARY
-----------  ------
100          512
101          600

各セッションが、同時に元の問合せを発行します。セッション1では、t1で更新された給与612が表示されますが、セッション2で更新された従業員101の給与は表示されません。セッション2の読取り側では、セッション2によって更新された給与が表示されますが、セッション1で更新された給与は表示されません。セッション3での読取りでは、読取り一貫性を使用して、セッション1およびセッション2で変更される前の給与が表示されます。

関連項目:

- 『Oracle Database SQL言語リファレンス』

- V$LOCKの詳細は、『Oracle Databaseリファレンス』を参照してください。

行ロックの記憶域

ロック・マネージャを使用してロックのリストをメモリー上に保持する一部のデータベースとは異なり、Oracle Databaseでは、ロックされた行を含むデータ・ブロックにロック情報を格納します。

Oracle Databaseでは、キューイング・メカニズムを使用して、行ロックを取得します。トランザクションで未ロックの行に対するロックが必要になった場合は、データ・ブロックにロックが配置されます。このトランザクションによって変更される各行は、ブロック・ヘッダーに格納されるトランザクションIDのコピーを指しています(「データ・ブロックの概要」を参照)。

トランザクションが終了しても、トランザクションIDはそのままブロック・ヘッダーに残ります。別のトランザクションで行が変更される場合は、そのトランザクションIDを使用してロックがアクティブであるかどうかが判断されます。ロックがアクティブである場合は、ロックが解除されたときにセッションに通知されるように設定されます。ロックがアクティブでない場合は、そのトランザクションがロックを取得します。

関連項目:
V$TRANSACTIONの詳細は、『Oracle Databaseリファレンス』を参照してください。

表ロック(TM)

表ロックはTMロックとも呼ばれ、INSERT、UPDATE、DELETE、MERGE、FOR UPDATE句付きのSELECTまたはLOCK TABLE文で表を変更する場合にトランザクションに取得されます。DML操作では、トランザクションのために表へのDMLアクセスを確保して、このトランザクションと競合する可能性のあるDDL操作を防止するために表ロックが必要になります。

表ロックは、次のいずれかのモードで保持できます。

- 行共有(RS)
このロックは、副共有表ロック(SS)とも呼ばれ、表に対するロックを保持しているトランザクションがその表の行をロック済であり、それらの行を更新する予定であることを示しています。行共有ロックは、最も制限の緩やかなモードの表ロックであり、最高水準の同時実行性を表にもたらします。

- 行排他表ロック(RX)
このロックは、副排他表ロック(SX)とも呼ばれ、一般的にこのロックを保持しているトランザクションが表の行を更新したか、SELECT ... FOR UPDATEを発行したことを示しています。SXロックでは、他のトランザクションが同じ表の行に対して問合せ、挿入、更新、削除またはロックを実行できます。そのため、SXロックでは、複数のトランザクションが同じ表に対して同時にSXロックおよび副共有表ロックを取得できます。

- 共有表ロック(S)
トランザクションで共有表ロックを取得すると、他のトランザクションは表に対するSELECT ... FOR UPDATEを使用しない問合せを実行できますが、更新は単一のトランザクションが共有表ロックを保持している場合にのみ許可されます。複数のトランザクションが共有表ロックを同時に保持することがあるため、トランザクションで表を変更できるかどうかは、このロックを保持しているのみでは保証されません。

- 共有行排他表ロック(SRX)
このロックは、共有副排他表ロック(SSX)とも呼ばれ、共有表ロックよりも多くの制限を課します。特定の表に対して、同時に1つのトランザクションのみがSSXロックを取得できます。トランザクションでSSXロックを取得すると、他のトランザクションは表に対してSELECT ... FOR UPDATE以外の問合せを実行できますが、表は更新できません。

- 排他表ロック(X)
このロックは、最も制限が強くなります。他のトランザクションは、一切のDML文を実行できなくなり、表に一切のロックをかけられなくなります。

関連項目:

- 『Oracle Database SQL言語リファレンス』

- 表ロックの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

ロックと外部キー

Oracle Databaseでは、親キーとそれに依存する外部キーとの関連において、同時実行性制御が最適化されます。ヒープ構成表では、ロック動作は外部キー列の索引付けにより異なります。外部キーが索引付けされていない場合、子表が頻繁にロックされ、デッドロックが発生し、同時実行性が低下する可能性があります。このため、対応する一意キーまたは主キーの更新や削除が発生しないことが確実な場合を除くほとんどの場合で、外部キーの索引付けをお薦めします。

注意:
索引構成表および表クラスタなどのヒープ以外のデータ構造には、追加の考慮事項が適用されます。

ロックと索引のない外部キー

次の両方の条件に当てはまる場合、データベースは子表に対する完全表ロックを取得します。

- 子表の外部キー列に索引が存在しない場合。

- セッションで、親表の主キーが変更されるか(行の削除や主キーの属性の変更など)、親表に行がマージされた場合。親表に対する挿入では、子表の表ロックは取得されません。
hr.departments表が、索引付けされていない外部キーdepartment_idを含むhr.employeesの親である場合など。図9-3に、departments表の部門60の主キー属性を変更するセッションを示します。

図9-3 外部キーの索引がない場合のロック・メカニズム

図9-3では、データベースは、部門60の主キーの変更時にemployeesに対する完全表ロックを取得しています。このロックによって、他のセッションはemployees表の問合せはできますが、更新できなくなります。たとえば、従業員の電話番号は更新できません。employeesに対する表ロックはdepartments表への主キーの変更が完了すると、即時に解除されます。departmentsの複数の行で主キーの変更が実行される場合、employeesに対する表ロックは、departmentsで変更される行ごとに取得および解除されます。

注意:
子表に対するDMLでは、親表の表ロックは取得されません。

ロックと索引付き外部キー

次の両方の条件に当てはまる場合、データベースは子表に対する完全表ロックを取得しません。

- 子表の外部キー列が索引付けされる場合。

- セッションで、親表の主キーが変更されるか(行の削除や主キーの属性の変更など)、親表に行がマージされた場合。

親表に対するロックにより、トランザクションは排他表ロックを取得できませんが、主キーの変更時に、親表または子表に対するDMLは阻止されません。この状況は、子表への更新が発生している間に、親表での主キーの変更が発生する場合に適しています。

図9-4に、department_id列が索引付けられた子表employeesを示します。トランザクションにより、部門280がdepartmentsから削除されます。この削除により、「ロックと索引のない外部キー」に示すようにデータベースがemployees表に対する完全表ロックを取得することはありません。

図9-4 外部キーが索引付けされている場合のロック・メカニズム

子表でON DELETE CASCADEを指定すると、親表からの削除によって、子表からも削除することができます。たとえば、部門280を削除した場合、削除された部門の従業員に関するレコードをemployeesから削除できます。この場合、待機とロックに関するルールは、親表から行を削除した後に子表から行を削除する場合と同じです。

関連項目:

- 「外部キー制約」

- 「索引の概要」

DDLロック

データ・ディクショナリ・ロック(DDLロック)によって、DDL操作によるスキーマ・オブジェクトの処理中または参照中に、そのオブジェクトの定義が保護されます。DDL操作中には、修正や参照の対象となる個々のスキーマ・オブジェクトのみがロックされます。データ・ディレクトリ全体がロックされることはありません。

Oracle Databaseは、DDLロックを必要とするDDLトランザクションのために、DDLロックを自動的に取得します。ユーザーはDDLロックを明示的に要求できません。たとえば、ユーザーがストアド・プロシージャを作成する場合、Oracle Databaseはプロシージャ定義内で参照されるすべてのスキーマ・オブジェクトについてのDDLロックを自動的に取得します。DDLロックにより、プロシージャのコンパイル完了前にそれらのオブジェクトの変更または削除が防止されます。

排他DDLロック

排他DDLロックは、他のセッションによるDDLロックまたはDMLロックの取得を防止します。「共有DDLロック」の項に示されているDDL操作を除き、ほとんどのDDL操作では、同じスキーマ・オブジェクトの変更や参照を実行する可能性のある他のDDL操作によって破壊的な干渉が起きないように、リソースの排他DDLロックが必要です。たとえば、ALTER TABLEで表に列を追加している間は、DROP TABLE操作でその表を削除できず、その逆も同様です。

排他ロックは、DDL文実行の継続中と自動コミット中ずっと存続します。排他DDLロックの取得では、別の操作によってそのスキーマ・オブジェクトに対して別のDDLロックが保持されている場合、その取得は古いDDLロックが解除されるまで待機し、その後に処理されます。

共有DDLロック

リソースに対する共有DDLロックでは、競合するDDL操作によって破壊的な干渉が防止されますが、同様のDDL操作でのデータ同時実行性は確保されます。

たとえば、CREATE PROCEDURE文の実行時には、その文を含むトランザクションは、参照されるすべての表について共有DDLロックを取得します。他のトランザクションは同じ表を参照するプロシージャを同時に作成できるため、同じ表について同時実行の共有DDLロックの取得はできますが、参照中の表について排他DDLロックを取得できるトランザクションはありません。

共有DDLロックは、DDL文実行の継続中と自動コミット中ずっと存続します。その結果、共有DDLロックを保持するトランザクションでは、参照中のスキーマ・オブジェクトの定義がそのトランザクションの継続時間にわたって変化しないことが保証されます。

ブレーク可能解析ロック

SQL文またはPL/SQLプログラム・ユニットは、参照される各スキーマ・オブジェクトについて解析ロックを保持します。参照オブジェクトが変更または削除された場合に、対応する共有SQL領域を無効にできるようにするため、解析ロックが取得されます。解析ロックは、どのようなDDL操作も拒否せず、一時的に解除して競合するDDL操作を実行することも許可するために、ブレーク可能解析ロックと呼ばれます。

解析ロックは、SQL文実行の解析フェーズ中に共有プールに取得されます。解析ロックは、その文の共有SQL領域が共有プールに残っているかぎり保持されます。

関連項目:
「共有プール」

システム・ロック

Oracle Databaseでは、様々なタイプのシステム・ロックを使用して、内部データベースおよびメモリー構造を保護します。ユーザーは、システム・ロックの出現や継続期間を制御できないため、このメカニズムにアクセスできません。

ラッチ

ラッチは、共有のデータ構造、オブジェクトおよびファイルへのマルチユーザー・アクセスを調整するための、単純な低レベルのシリアライズ・メカニズムです。ラッチによって、複数のプロセスからアクセスされる共有メモリー・リソースが破損しないように保護されます。特に、ラッチは次の状況からデータ構造を保護します。

- 複数のセッションによる同時変更

- あるセッションで変更中の場合の他のセッションによる読取り

- アクセス中のメモリーの割当て解除(エージ・アウト)

通常、1つのラッチによってSGA内の複数のオブジェクトが保護されます。たとえば、DBWnやLGWRなどのバックグラウンド・プロセスでは、共有プールのメモリーを割り当ててデータ構造を作成します。このメモリーを割り当てるために、これらのプロセスでは、アクセスをシリアライズする共有プール・ラッチを使用して、2つのプロセスが共有プールを同時に検査または変更できないようにします。メモリーが割り当てられた後、解析に必要なライブラリ・キャッシュなどの共有プール領域に他のプロセスがアクセスする必要がある場合があります。この場合、共有プール全体ではなくライブラリ・キャッシュのみがラッチされます。

行ロックなどのエンキュー・ラッチとは異なり、ラッチではセッションのキューイングは許可されません。ラッチが使用可能になると、ラッチを要求する最初のセッションがラッチへの排他的アクセスを取得します。プロセスがループ内のラッチを繰り返し要求するとラッチ・スピンが発生し、プロセスがラッチ要求を更新する前にCPUを解放するとラッチ・スリープが発生します。

通常、Oracleプロセスは、データ構造の1つを操作または参照する、非常に短い間のみラッチを取得します。たとえば、1人の従業員の給与更新の処理中に、データベースは数千のラッチを取得および解除する場合があります。ラッチの実装(特に、プロセスがラッチを待機するかどうか、およびどのくらいの時間待機するか)は、オペレーティング・システムに依存します。

ラッチの数を増やすと、同時実行可能な操作の数が減少します。たとえば、ハード解析操作を過度に行うと、ライブラリ・キャッシュ・ラッチの競合が発生します。V$LATCHビューには、各ラッチが要求された回数や待機された回数を含む、各ラッチの詳細な使用統計が含まれています。

関連項目:

- 「SQLの解析」

- V$LATCHの詳細は、『Oracle Databaseリファレンス』を参照してください。

- 待機イベント統計の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

mutex

相互排他オブジェクト(mutex)は、メモリー内のオブジェクトが同時プロセスでアクセスされた場合にエージ・アウトまたは破損しないようにするための低レベルのメカニズムです。mutexはラッチに似ていますが、通常、ラッチではオブジェクトのグループが保護されるのに対して、mutexでは単一のオブジェクトが保護されます。

mutexには、複数の利点があります。

- mutexによって、競合の可能性が減少します。
ラッチでは複数のオブジェクトを保護するため、複数のプロセスで保護対象のオブジェクトのいずれかへの同時アクセスが試行された場合に、ボトルネックが生じる可能性があります。mutexでは、グループではなく個別のオブジェクトへのアクセスをシリアライズするため、可用性が向上します。

- mutexでは、ラッチよりも少ないメモリーが使用されます。

- 共有モードでmutexを使用すると、複数のセッションからの同時参照が可能になります。

内部ロック

内部ロックは、ラッチやmutexよりも高レベルで複雑なメカニズムであり、様々な目的に使用されます。データベースでは、次のタイプの内部ロックを使用します。

- ディクショナリ・キャッシュ・ロック

これらのロックの継続時間は非常に短く、ディクショナリ・キャッシュ内のエントリが修正されたり使用されている間、そのエントリについて保持されます。これらのロックは、解析されている文が矛盾したオブジェクト定義を参照しないことを保証します。ディクショナリ・キャッシュ・ロックは、共有または排他で保持されます。共有ロックは解析が完了すると解除されますが、排他ロックはDDL操作が完了したときに解除されます。

- ファイルとログの管理ロック

これらのロックは様々なファイルを保護します。たとえば、ある内部ロックは制御ファイルを保護し、一度に1つのプロセスのみがそれを変更できるようにします。別のロックは、オンラインREDOログ・ファイルの使用とアーカイブを調整します。データベースを複数インスタンスが共有モードでマウントしたり、1つのインスタンスが排他モードでマウントすることを保証するために、データファイルがロックされます。ファイルとログのロックはファイルの状態を示すため、必然的に長い間保持されます。

- 表領域とUNDOセグメントのロック

これらのロックは、表領域とUNDOセグメントを保護します。たとえば、データベースにアクセスするすべてのインスタンスは、表領域のオンライン/オフラインの状態について一致している必要があります。UNDOセグメントは、1つのセグメントに1つのデータベース・インスタンスしか書き込めないようにロックされています。

関連項目:
「データ・ディクショナリ・キャッシュ」

手動データ・ロックの概要

データの同時実行性、整合性および文レベルの読取り一貫性を確保するために、Oracle Databaseは自動的にロックを実行します。ただし、Oracle Databaseでは、手動でデフォルトのロック・メカニズムを置き換えることもできます。デフォルト・ロックの置換えは、次のような状況で有効です。

- アプリケーションで、トランザクション・レベルの読取り一貫性またはリピータブル・リードが必要な場合。
この場合、問合せによって作成されるデータが、他のトランザクションによる変更を反映せず、トランザクションの継続時間にわたって一貫性を維持する必要があります。トランザクション・レベルの読取り一貫性は、明示的ロック、読取り専用トランザクションまたはシリアライズ可能トランザクションを使用するか、デフォルトのロックをオーバーライドすると実現できます。

- アプリケーションで、あるトランザクションが他のトランザクションの完了まで待機せずに済むように、そのトランザクションがリソースに排他的アクセスできるようにする必要がある場合。

Oracle Databaseの自動ロックは、セッション・レベルまたはトランザクション・レベルでオーバーライドできます。セッション・レベルでは、ALTER SESSION文を使用して必要なトランザクション分離レベルを設定できます。トランザクション・レベルでは、次のSQL文を含むトランザクションによってOracle Databaseのデフォルト・ロックがオーバーライドされます。

- SET TRANSACTION ISOLATION LEVEL文

- LOCK TABLE文(表をロックする文、またはビューを使用するときに実表をロックする文)

- SELECT ... FOR UPDATE文

前述の文で取得したロックは、トランザクション終了後に解除されるか、セーブポイントへのロールバックによって解除されます。

Oracle Databaseのデフォルト・ロックを任意のレベルで置き換える場合、データベース管理者やアプリケーション開発者は、ロック置換の手順が確実に正しく実行されるようにしてください。ロックの手順は、データ整合性が保証される、データ同時実行性が許容範囲内である、デッドロックは発生する可能性がないかまたは適切に処理される、などの基準を満たすものにする必要があります。

関連項目:

- LOCK TABLEおよびSELECT ... FOR UPDATEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 手動で表をロックする方法の詳細は『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

ユーザー定義ロックの概要

Oracle Databaseのロック・マネージメント・サービスを使用すると、特定のアプリケーションで独自のロックを定義できます。たとえば、ファイルシステム上のメッセージ・ログに対するアクセスをシリアライズするためのロックを作成できます。確保したユーザー・ロックは、Oracle Databaseロックと同一とみなされるため、デッドロックの検出などのOracle Databaseロックの機能をすべて備えています。ユーザー・ロックは接頭辞ULで識別されるため、Oracle Databaseロックと矛盾することはありません。

Oracle Databaseのロック・マネージメント・サービスは、DBMS_LOCKパッケージ内のプロシージャを介して利用できます。PL/SQLブロックには、次の処理を行う文を含めることができます。

- 特定のタイプのロックを要求します。

- そのロックに、同一のインスタンスまたは別のインスタンス内にある別のプロシージャからも識別できる、一意の名前を指定します。

- ロック・タイプを変更します。

- ロックを解除します。

関連項目:

- Oracle Databaseのロック・マネージメント・サービスの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- DBMS_LOCKの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

脚注の凡例

脚注 1: 分散トランザクションの2フェーズ・コミットを処理する場合、特殊な状況では、データベースで読取りアクセスが一時的に禁止されることがあります。具体的には、問合せが準備フェーズとコミット・フェーズの間に開始され、コミット前にデータの読取りを試みる場合、データベースでは、読取りの整合性を保証するため、行レベルからブロック・レベルにロックが拡大されます。

10 トランザクション

この章では、トランザクションを定義し、データベースでトランザクションが処理される方法について説明します。

この章の内容は、次のとおりです。

- トランザクションの概要

- トランザクション制御の概要

- 自律型トランザクションの概要

- 分散トランザクションの概要

トランザクションの概要

トランザクションは、1つ以上のSQL文を含むアトミックな論理作業単位です。トランザクションは、SQL文をグループ化して、すべての文がコミットされた(データベースに適用された)状態にするか、すべての文がロールバックされた(データベースから取り消された)状態にできる必要があります。Oracle Databaseでは、すべてのトランザクションにトランザクションIDと呼ばれる一意の識別子が割り当てられます。

すべてのOracleトランザクションは、ACIDプロパティと呼ばれる、データベース・トランザクションの基本プロパティに準拠します。ACIDは次の単語の頭字語です。

- Atomicity(原子性)
1つのトランザクションでは、すべてのタスクが実行されるか、1つも実行されないかのいずれかです。部分的に実行されるトランザクションは存在しません。たとえば、トランザクションで100行の更新が開始され、20行が更新された後にシステムで障害が発生した場合、データベースではこの20行に行われた変更がロールバックされます。

- 一貫性
トランザクションにより、データベースは一貫したある状態から一貫した別の状態に移行します。たとえば、普通預金口座の借方に記入し、当座預金口座の貸方に記入する銀行のトランザクションにおいて、障害によって、データベースで一方の口座でのみ貸方に記入されたためにデータの一貫性がなくなることは許されません。

- Isolation(独立性)
トランザクションの結果は、そのトランザクションがコミットされるまで、他のトランザクションに表示されません。たとえば、hr.employees表を更新しているユーザーには、別のユーザーがemployeesに対して同時に行った未コミットの変更は表示されません。このため、ユーザーには、トランザクションがシリアルに実行されているように見えます。

- Durability(永続性)
コミットされたトランザクションによって行われた変更は、永続的に確定されます。トランザクションの完了後、データベースではリカバリ・メカニズムを使用して、トランザクションによる変更が失われていないことが確認されます。

トランザクションの使用は、データベース管理システムとファイルシステムの最も重要な違いの1つです。

サンプル・トランザクション: 口座の借方と貸方

トランザクションの概念を具体的に説明するため、銀行業務データベースについて考えてみます。顧客が普通預金口座から当座預金口座へ預金を振り替える場合、トランザクションは次の3つの別々の操作で構成する必要があります。

- 普通預金口座の減額

- 当座預金口座の増額

- トランザクション・ジャーナルへのトランザクションの記録

Oracle Databaseでは、2つの状況が考慮されます。3つのSQL文のすべてにおいて口座の差引残高の帳尻が合えば、トランザクションの結果をデータベースに適用できます。ただし、預金額の不足、口座番号が無効、またはハードウェア障害などの問題が原因で、トランザクション内の1つまたは2つの文が完了しない場合は、データベースではすべての口座の差引残高が正しく維持されるようにトランザクション全体をロールバックする必要があります。

図10-1に、銀行のトランザクションを示します。最初の文では、普通預金口座3209から$500を減額します。2番目の文では、当座預金口座3208に$500を増額します。3番目の文では、ジャーナルの表にこの振替のレコードを挿入します。最後の文で、トランザクションをコミットします。

図10-1 銀行のトランザクション

トランザクションの構造

データベース・トランザクションは、1つ以上の文で構成されています。具体的には、トランザクションは次のいずれかで構成されています。

- 全体でデータベースに対するアトミックな変更を構成する1つ以上のデータ操作言語(DML)文

- 1つのデータ定義言語(DDL)文

トランザクションには、開始と終了があります。

関連項目:
「SQL文の概要」

トランザクションの開始

トランザクションは、最初の実行可能SQL文が検出された時点で開始されます。実行可能SQL文は、DML文やDDL文、およびSET TRANSACTION文など、データベース・インスタンスへのコールを生成するSQL文のことです。

トランザクションが開始されると、Oracle Databaseはそのトランザクションを使用可能なUNDOデータ・セグメントに割り当てて、新しいトランザクションのUNDOエントリを記録します。トランザクションIDは、UNDOセグメントおよびトランザクション表スロットが割り当てられるまでは割り当てられません(割当ては、最初のDML文の実行中に行われます)。トランザクションIDはトランザクションに対して一意であり、UNDOセグメント番号、スロットおよび順序番号を表します。

次の例では、UPDATE文を実行してトランザクションを開始し、このトランザクションの詳細をV$TRANSACTIONに問い合せます。

SQL> UPDATE hr.employees SET salary=salary;

107 rows updated.

SQL> SELECT XID AS "txn id", XIDUSN AS "undo seg", XIDSLOT AS "slot",
2  XIDSQN AS "seq", STATUS AS "txn status"
3  FROM V$TRANSACTION;

txn id             undo seg       slot        seq txn status
---------------- ---------- ---------- ---------- ----------------
0600060037000000          6          6         55 ACTIVE

関連項目:
「UNDOセグメント」

トランザクションの終了

トランザクションは、次のいずれかのアクションが発生すると終了します。

- COMMIT文またはROLLBACK文が、SAVEPOINT句なしで発行される場合。
コミットでは、ユーザーが明示的または暗黙的に、このトランザクションの変更内容を確定するように要求します。トランザクションによって行われた変更内容が確定され、トランザクションのコミット後にのみ他のユーザーが参照できるようになります。図10-1に示したトランザクションは、コミットで終了しています。

- CREATE、DROP、RENAMEまたはALTERなどのDDLコマンドが実行される場合。
データベースでは、すべてのDDL文の前後に暗黙的なCOMMIT文が発行されます。現行のトランザクションにDML文が含まれている場合、Oracle Databaseは最初にそのトランザクションをコミットし、新しい単一文トランザクションとしてそのDDL文を実行し、コミットします。

- ユーザーがほとんどのOracle Databaseユーティリティおよびツールを正常に終了する場合(このような場合は、現行のトランザクションが暗黙的にコミットされます)。ユーザーが切断したときのコミット動作は、アプリケーションに依存しており、構成可能です。

注意:
アプリケーションでは、プログラムを終了する前に、必ず明示的にトランザクションをコミットまたは取り消す必要があります。

- クライアント・プロセスが異常終了し、トランザクション表およびUNDOセグメントに格納されていたメタデータを使用して、トランザクションが暗黙的にロールバックされる場合。

1つのトランザクションが終了すると、次の実行可能SQL文によって次のトランザクションが自動的に開始されます。次の例では、UPDATEを実行してトランザクションを開始し、ROLLBACK文でトランザクションを終了してから、UPDATEを実行して新しいトランザクションを開始します(トランザクションIDが異なることに注意してください)。

SQL> UPDATE hr.employees SET salary=salary;
107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0800090033000000 ACTIVE

SQL> ROLLBACK;

Rollback complete.

SQL> SELECT XID FROM V$TRANSACTION;

no rows selected

SQL> UPDATE hr.employees SET last_name=last_name;

107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0900050033000000 ACTIVE

関連項目:

- 「データベース管理者向けのツール」および「データベース開発者向けのツール」

- COMMITの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

文レベルの原子性

Oracle Databaseでは、文レベルの原子性がサポートされます。文レベルの原子性とは、SQL文がアトミックな作業単位であり、完全に成功するか、完全に失敗するかのいずれかであることを意味します。

正常に実行される文とコミットされるトランザクションとは異なります。1つのSQL文は、アトミックな単位として解析され、エラーなしで実行された場合、たとえば複数行の更新ですべての行が変更されたときなどに、正常に実行されます。

実行中にSQL文が原因でエラーが発生すると成功しないため、この文のすべての結果がロールバックされます。この操作が文レベルのロールバックです。この操作には次のような特徴があります。

- SQL文が成功しなかった場合は、SQLでの実行予定の作業のみが影響を受けます。
成功しなかった文が、現行のトランザクションにおけるこれまでの作業に影響を及ぼすことはありません。たとえば、図10-1で、2番目のUPDATE文でエラーが発生してロールバックされた場合、最初のUPDATE文によって実行された作業はロールバックされません。最初のUPDATE文は、ユーザーが明示的にコミットまたはロールバックできます。

- ロールバックの効果は、その文がまったく実行されなかった場合と同じ状態にすることです。
アトミックな文の副次的な効果としては、たとえば、文の実行時に起動されたトリガーが、アトミックな文の一部とみなされることがあげられます。アトミックな文の一部として生成された作業は、すべてが成功するか、1つも成功しないかのいずれかです。

文レベル・ロールバックの原因となるエラーの例として、重複する主キーの挿入を試行する場合があります。1つのデッドロック(同じデータに関する競合)に単一SQL文が複数関係している場合も、文レベル・ロールバックが発生します。ただし、SQL文の解析中に構文エラーなどのエラーが検出された場合は、まだSQL文は実行されていないため、文レベルのロールバックは発生しません。

関連項目:

- 「SQLの解析」

- 「ロックとデッドロック」

- 「トリガーの概要」

システム変更番号(SCN)

システム変更番号(SCN)は、Oracle Databaseで使用される論理的な内部タイムスタンプです。SCNを使用して、トランザクションのACIDプロパティに準拠する必要があるデータベース内で発生するイベントに順序を付けます。Oracle DatabaseではSCNを使用して、すべての変更がディスク上に存在することが認識される前のSCNをマークし、リカバリで不要なREDOが適用されないようにします。さらに、データの集合に対するREDOが存在しない時点のマークにもSCNを使用し、リカバリを停止できるようにします。

SCNは直線的に増加する順序で発生します。監視されたSCNは時間における論理的なある時点を示し、監視を繰り返すと等しい値または前よりも大きな値が戻されるため、Oracle DatabaseではSCNを実時間のように使用できます。あるイベントのSCNが別のイベントのSCNよりも小さい場合、このイベントはそのデータベースに関して先行する時間に発生したことになります。複数のイベントが同じSCNを共有する場合もあり、これはイベントがデータベースに関して同じ時間に発生したことを意味します。

すべてのトランザクションには、SCNがあります。たとえば、トランザクションで行が更新されると、データベースではこの更新が発生したときのSCNが記録されます。このトランザクションで行われたその他の変更にも同じSCNが付けられます。トランザクションがコミットされると、データベースではこのコミットのSCNが記録されます。

Oracle Databaseでは、SCNがシステム・グローバル領域(SGA)で増分されます。トランザクションでデータが変更されると、データベースではこのトランザクションに割り当てられたUNDOデータ・セグメントに新しいSCNが書き込まれます。次に、ログ・ライター・プロセスによって、このトランザクションのコミット・レコードがオンラインREDOログに即時に書き込まれます。コミット・レコードには、トランザクションの一意のSCNが付けられています。Oracle Databaseでは、SCNをインスタンス・リカバリ・メカニズムおよびメディア・リカバリ・メカニズムの一部としても使用します。

関連項目:
「インスタンス・リカバリの概要」および「バックアップおよびリカバリ」

トランザクション制御の概要

トランザクション制御は、DML文による変更の内容を管理し、一覧のDML文をトランザクションとしてグループ化する処理です。通常、アプリケーション設計者は、作業が論理単位で完了してデータの一貫性が保たれるよう、トランザクション制御を考慮します。

トランザクション制御では、「トランザクション制御文」で説明したように、次の文が使用されます。

- COMMIT文は、現行のトランザクションを終了し、トランザクションで実行されたすべての変更を確定します。さらに、COMMIT文により、トランザクション内のすべてのセーブポイントが消去され、トランザクション・ロックが解放されます。

- ROLLBACK文は、現行のトランザクションで行われた作業を元に戻し、最後のCOMMITまたはROLLBACK以降に行われたすべてのデータ変更が破棄されます。ROLLBACK TO SAVEPOINT文は、最後のセーブポイント以降の変更を取り消しますが、トランザクション全体は終了しません。

- SAVEPOINT文は、後からロールバックできるトランザクションの時点を特定します。

表10-1のセッションは、トランザクション制御の基本概念を示しています。

表10-1 トランザクション制御

時間

セッション

説明

t0

COMMIT;

セッション内の既存のトランザクションを終了します。

t1

SET TRANSACTION NAME 'sal_update';

トランザクションを開始し、トランザクションにsal_updateという名前を付けます。

t2

UPDATE employees
SET salary = 7000
WHERE last_name = 'Banda';

Bandaの給与を7000に更新します。

t3

SAVEPOINT after_banda_sal;

after_banda_salという名前のセーブポイントを作成し、このトランザクションで行われた変更をこの時点までロールバックできるようにします。

t4

UPDATE employees
SET salary = 12000
WHERE last_name = 'Greene';

Greeneの給与を12000に更新します。

t5

SAVEPOINT after_greene_sal;

after_greene_salという名前のセーブポイントを作成し、このトランザクションで行われた変更をこの時点までロールバックできるようにします。

t6

ROLLBACK TO SAVEPOINT
after_banda_sal;

トランザクションをt3までロールバックし、t4で行われたGreeneの給与の更新を取り消します。sal_updateトランザクションは終了していません。

t7

UPDATE employees
SET salary = 11000
WHERE last_name = 'Greene';

トランザクションsal_updateで、Greeneの給与を11000に更新します。

t8

ROLLBACK;

トランザクションsal_updateで行われたすべての変更をロールバックし、トランザクションを終了します。

t9

SET TRANSACTION NAME 'sal_update2';

セッションで新しいトランザクションを開始し、トランザクションにsal_update2という名前を付けます。

t10

UPDATE employees
SET salary = 7050
WHERE last_name = 'Banda';

Bandaの給与を7050に更新します。

t11

UPDATE employees
SET salary = 10950
WHERE last_name = 'Greene';

Greeneの給与を10950に更新します。

t12

COMMIT;

トランザクションsal_update2で行われたすべての変更をコミットし、トランザクションを終了します。このコミットにより、変更がオンラインREDOログ・ファイルに保存されることが保証されます。

関連項目:
トランザクション制御文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

トランザクション名

トランザクション名は、ユーザー指定のオプションのタグであり、トランザクションが実行する作業のリマインダとして機能します。トランザクションの命名にはSET TRANSACTION ... NAME文を使用し、トランザクションの最初の文として使用する必要があります。表10-1では、最初のトランザクションがsal_update、2つ目のトランザクションがsal_update2と命名されています。

トランザクション名を使用すると、次のような利点があります。

- 名前を付けることで、長時間実行中のトランザクションの監視およびインダウト分散トランザクションの解決が容易になります。

- アプリケーションのトランザクションIDとともにトランザクション名を表示できます。たとえば、システムの活動状況を監視する場合、データベース管理者はOracle Enterprise Manager(Enterprise Manager)内のトランザクション名を表示できます。

- トランザクション名はトランザクション監査REDOレコードに書き込まれるため、LogMinerを使用してREDOログ内の特定のトランザクションを検索できます。

- トランザクション名を使用して、V$TRANSACTIONなどのデータ・ディクショナリ・ビュー内の特定のトランザクションを検索できます。

関連項目:

- 「Oracle Enterprise Manager」

- V$TRANSACTIONの詳細は、『Oracle Databaseリファレンス』を参照してください。

- SET TRANSACTIONの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

アクティブなトランザクション

アクティブなトランザクションとは、開始した後、まだコミットまたはロールバックされていないトランザクションのことです。表10-1では、sal_updateトランザクションでデータを変更する最初の文が、Bandaの給与の更新です。この更新の実行が成功してからROLLBACK文がトランザクションを終了するまで、sal_updateトランザクションはアクティブです。

トランザクションによるデータ変更は、トランザクションがコミットまたはロールバックされるまでは一時的です。トランザクションが終了する前のデータの状態は、次のとおりです。

- Oracle Databaseにより、システム・グローバル領域(SGA)内にUNDOデータ情報が生成されます。
このUNDOデータには、トランザクションのSQL文によって変更された古いデータ値が含まれています。「コミット読取り分離レベルでの読取り一貫性」を参照してください。

- Oracle Databaseにより、SGAのオンラインREDOログ・バッファにREDOが生成されています。
REDOログ・レコードには、データ・ブロックおよびUNDOブロックに対する変更内容が含まれています。「REDOログ・バッファ」を参照してください。

- SGAのデータベース・バッファに変更が加えられます。
コミットされたトランザクションのデータ変更は、SGAのデータベース・バッファに格納されており、データベース・ライター(DBW)によりデータファイルに必ずしもすぐに書き込まれるわけではありません。ディスクへの書込みは、コミットの前に行われることも、後に行われることもあります。「データベース・バッファ・キャッシュ」を参照してください。

- データ変更の影響を受ける行はロックされます。
他のユーザーは、影響を受ける行のデータを変更することも、未コミットの変更を表示することもできません。「ロック動作の概要」を参照してください。

セーブポイント

セーブポイントは、トランザクションのコンテキスト内のユーザー宣言による中間マーカーです。内部的には、このマーカーはSCNに解決されます。セーブポイントは、ロング・トランザクションをいくつかの小さい部分に分割します。

ロング・トランザクションでセーブポイントを使用すると、そのトランザクション内の宣言されたセーブポイントからトランザクション内の現時点までの間に実行された作業を、後でロールバックできるようになります。したがって、エラーが発生してもすべての文を再発行する必要はありません。表10-1では、セーブポイントafter_banda_salを作成しているため、Greeneの給与に対する更新をこのセーブポイントまでロールバックできます。

セーブポイントへのロールバック

未コミットのトランザクションにおけるセーブポイントへのロールバックは、指定したセーブポイント後に行われたすべての変更の取消しを意味しますが、トランザクション自体のロールバックは意味しません。表10-1でROLLBACK TO SAVEPOINT after_banda_salを実行したときのように、トランザクションがセーブポイントまでロールバックされると、次の処理が行われます。

1. Oracle Databaseにより、セーブポイントの後に実行された文のみがロールバックされます。
表10-1では、ROLLBACK TO SAVEPOINTにより、Greeneに対するUPDATEがロールバックされますが、Bandaに対するUPDATEはロールバックされません。

2. Oracle Databaseでは、ROLLBACK TO SAVEPOINT文に指定されたセーブポイントは保存されますが、それより後のセーブポイントはすべて失われます。
表10-1では、ROLLBACK TO SAVEPOINTによってafter_greene_salセーブポイントが失われます。

3. Oracle Databaseにより、指定したセーブポイントの後に取得された表と行のすべてのロックが解放されますが、そのセーブポイントより前に取得されたすべてのデータ・ロックは保持されます。

トランザクションはアクティブであり、継続できます。

関連項目:

- ROLLBACK文およびSAVEPOINT文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- トランザクション処理および制御の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

トランザクションのエンキュー

状況によっては、以前にロックされたリソースを待機中のトランザクションが、セーブポイントへのロールバック後も引き続きブロックされる場合があります。トランザクションが別のトランザクションによってブロックされた場合、このトランザクションはブロックしているトランザクション上でエンキューされるため、ブロックされたトランザクションを続行するには、ブロックしているトランザクション全体をコミットまたはロールバックする必要があります。

表10-2に示すシナリオでは、セッション1でDML文が実行される前に作成されたセーブポイントに、セッション1がロールバックされます。ただし、セッション2はセッション1のトランザクションの完了を待機するため、引き続きブロックされます。

表10-2 セーブポイントへのロールバックの例

時間

セッション1

セッション2

セッション3

説明

t0

UPDATE employees
SET salary = 7000
WHERE last_name =
'Banda';

セッション1でトランザクションが開始されます。このセッションでは、Bandaの行(TX)に排他ロック、表に副排他表ロック(SX)が適用されます。

t1

SAVEPOINT
after_banda_sal;

セッション1により、after_banda_salという名前のセーブポイントが作成されます。

t2

UPDATE employees
SET salary = 12000
WHERE last_name =
'Greene';

セッション1により、Greeneの行がロックされます。

t3

UPDATE employees
SET salary = 14000
WHERE last_name =
'Greene';

セッション2により、Greeneの行の更新が試行されますが、セッション1でこの行がロックされているため、ロックを取得できません。セッション2ではトランザクションが開始しません。

t4

ROLLBACK
TO SAVEPOINT
after_banda_sal;

セッション1により、Greeneの給与の更新がロールバックされ、Greeneの行ロックが解放されます。t0で取得された表ロックは解放されません。

この時点で、セッション2は引き続きセッション1にブロックされています。これは、まだ完了していないセッション1のトランザクション上でセッション2がエンキューされているためです。

t5

UPDATE employees
SET salary = 11000
WHERE last_name =
'Greene';

Greeneの行は現在ロックが解放されているため、セッション3により、Greeneの行を更新するためのロックが取得されます。この文により、セッション3のトランザクションが開始されます。

t6

COMMIT;

セッション1がコミットし、そのトランザクションが終了します。セッション2は現在、セッション3のトランザクションの後でGreeneの行を更新するようにエンキューされています。

関連項目:
Oracle Databaseによってロックが解放される時期の詳細は、「ロックの期間」を参照してください。

トランザクションのロールバック

未コミットのトランザクションをロールバックすると、そのトランザクション内のSQL文によって実行された、データに対するすべての変更が取り消されます。トランザクションのロールバック後には、そのトランザクション内で実行された作業の結果は存在しません。

セーブポイントを参照しないで、トランザクション全体をロールバックした場合、Oracle Databaseでは次の処理が実行されます。

- トランザクションのすべてのSQL文によるすべての変更が、対応するUNDOセグメントを使用して取り消されます。
すべてのアクティブなトランザクションのトランザクション表エントリには、そのトランザクションのすべてのUNDOデータを示すポインタが(適用時とは逆の順序で)格納されています。データベースでは、UNDOセグメントからデータを読み取り、操作を逆順にして、適用されたとおりにUNDOエントリをマークします。したがって、トランザクションで行が挿入されると、ロールバックによって削除されます。トランザクションで行が更新されると、ロールバックによって更新が元に戻されます。トランザクションで行が削除されると、ロールバックによって再挿入されます。表10-1では、GreeneとBandaの給与の更新が、ROLLBACKによって元に戻されています。

- トランザクションで保持されているすべてのデータ・ロックが解放されます。

- トランザクション内のすべてのセーブポイントが消去されます。
表10-1では、ROLLBACKによってセーブポイントafter_banda_salが削除されています。セーブポイントafter_greene_salは、ROLLBACK TO SAVEPOINT文によって削除されています。

- トランザクションを終了します。
表10-1では、ROLLBACKによって、データベースは最初のCOMMITが実行された後と同じ状態で残ります。

ロールバックの持続時間は、変更されたデータ量の関数になります。

関連項目:
「UNDOセグメント」

トランザクションのコミット

コミットは、現行のトランザクションを終了し、トランザクションで実行されたすべての変更を確定します。表10-1では、2つ目のトランザクションがsal_update2で開始され、明示的なCOMMIT文で終了しています。これにより、2つのUPDATE文の結果である変更が確定されます。

トランザクションをコミットすると、次のアクションが実行されます。

- COMMITに対してシステム変更番号(SCN)が生成されます。
関連するUNDO表領域の内部トランザクション表に、トランザクションのコミットが記録されます。トランザクションに対応する一意のSCNは、トランザクション表に割り当てられて記録されます。「シリアライズ可能分離レベル」を参照してください。

- ログ・ライター(LGWR)・プロセスにより、REDOログ・バッファ内に残されたREDOログ・エントリがオンラインREDOログに書き込まれ、さらにトランザクションのSCNがオンラインREDOログに書き込まれます。これが、トランザクションのコミットを構成するアトミック・イベントです。

- Oracle Databaseにより、行と表に対して保持されているロックが解放されます。
未コミットのトランザクションによって保持されているロックを待機してエンキューされていたユーザーが、作業を続行できるようになります。

- Oracle Databaseにより、セーブポイントが削除されます。
表10-1では、sal_updateトランザクション内にセーブポイントが存在しないため、消去されたセーブポイントはありません。

- Oracle Databaseにより、コミットのクリーンアウトが実行されます。
コミットされたトランザクションのデータが含まれている変更済ブロックが引き続きSGA内に存在し、このブロックを変更する他のセッションがない場合は、データベースにより、このブロックからロックに関するトランザクション情報が削除されます。COMMITでブロックをクリーンアウトし、後続のSELECTによるこのタスクの実行を不要にすると理想的です。

注意:
ブロックのクリーンアウトではREDOが生成されるため、問合せによってREDOが生成され、結果として次のチェックポイント時にブロックが書き込まれる場合があります。

- Oracle Databaseにより、トランザクションに完了のマークが付けられます。

トランザクションをコミットした後、ユーザーは変更を表示できます。

通常のコミットは、トランザクションのサイズにかかわらず高速な操作です。コミットの速度は、トランザクション内で変更されるデータのサイズによって遅くなりません。コミットで最も時間がかかる部分は、LGWRによって実行される物理ディスクI/Oです。ただし、LGWRではREDOログ・バッファの内容が段階的にバックグラウンドで書き込まれるため、LGWRにかかる時間は削減されます。

デフォルトの動作では、LGWRによりREDOがオンラインREDOログに同時に書き込まれ、トランザクションはバッファ内のREDOがディスクに移動するまで待機してから、コミットをユーザーに戻します。ただし、アプリケーション開発者は、トランザクションのコミット待機時間を短縮するために、REDOが非同期に書き込まれ、REDOがディスクに移動されるまでトランザクションが待機せずに、COMMITコールからすぐに戻れるよう指定できます。

関連項目:

- 非同期コミットの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- 「ロックのメカニズム」

- LGWRの詳細は、「バックグラウンド・プロセスの概要」を参照してください。

自律型トランザクションの概要

自律型トランザクションは、メイン・トランザクションと呼ばれる他のトランザクションからコールできる独立したトランザクションです。コール側のトランザクションを一時停止して、自律型トランザクション内でSQL操作を実行し、その操作をコミットまたは取り消してから、コール側トランザクションを再開できます。

自律型トランザクションは、コール側トランザクションでコミットまたはロールバックするかどうかに関係なく、独立して実行する必要があるアクションを実装する場合に便利です。たとえば、株購入のトランザクションでは、全体的な株購入が成立するかどうかにかかわらず、顧客データをコミットする必要があります。また、トランザクション全体がロールバックされた場合でも、デバッグ表にエラー・メッセージを記録することも必要となります。

自律型トランザクションの特性は、次のとおりです。

- 自律型トランザクションでは、メイン・トランザクションによって加えられたがコミットされていない変更は取り扱わず、ロックやリソースをメイン・トランザクションと共有することもありません。

- 自律型トランザクション内の変更は、自律型トランザクションのコミット時に他のトランザクションに表示されるようになります。そのため、ユーザーはメイン・トランザクションのコミットを待機しなくても更新情報にアクセスできます。

- 自律型トランザクションで他の自律型トランザクションを開始できます。自律型トランザクションをコールできるレベル数には、リソース制限以外の制限はありません。

PL/SQLでは、自律型トランザクションは自律型スコープ内で実行されます(自律型スコープとは、プラグマAUTONOMOUS_TRANSACTIONでマークされたルーチンです)。このコンテキストでは、トップレベルの無名PL/SQLブロックおよびPL/SQLサブプログラムとPL/SQLトリガーが、ルーチンに含まれています。プラグマは、コンパイラにコンパイル・オプションの実行を指示するディレクティブです。プラグマAUTONOMOUS_TRANSACTIONによって、このプロシージャは実行時に親トランザクションから独立した新しい自律型トランザクションとして実行する必要があることが、データベースに指示されます。

図10-2に、制御がメイン・ルーチン(MT)から自律型ルーチンに移り、再びメイン・ルーチンに戻ってくるまでのフローを示します。メイン・ルーチンはproc1、自律型ルーチンはproc2です。自律型ルーチンでは、制御がメイン・ルーチンに戻る前に、複数のトランザクション(AT1およびAT2)をコミットできます。

図10-2 トランザクション制御フロー

自律型ルーチンの実行可能セクションに入ると、メイン・ルーチンが一時停止します。この自律型ルーチンを終了すると、メイン・ルーチンが再開されます。

図10-2では、proc1内部のCOMMITにより、この文自体の作業のみでなく、そのセッション内で実行されたすべての保留中の作業が確定されます。ただし、proc2内のCOMMITでは、proc2トランザクション内で実行された作業のみが確定されます。したがって、トランザクションAT1およびAT2内のCOMMIT文は、MTトランザクションに影響を与えません。

関連項目:
自律型トランザクションの使用方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』および『Oracle Database PL/SQL言語リファレンス』を参照してください。

分散トランザクションの概要

分散データベースは、分散システム内のデータベースの集合であり、アプリケーションには1つのデータソースとして認識されます。分散トランザクションとは、データベース・リンクと呼ばれるスキーマ・オブジェクトを使用し、分散データベースの複数の異なるノード上でデータを更新する、1つ以上の文を含むトランザクションのことです。データベース・リンクは、1つのデータベース・インスタンスが別のデータベース・インスタンスにログインする様子を記述します。

ローカル・データベースでのトランザクションとは異なり、分散トランザクションでは、複数データベース上にあるデータが変更されます。その結果、データベースではトランザクションでの変更のコミットやロールバックをアトミックな単位として処理する必要があるため、分散トランザクション処理はより複雑になります。トランザクション全体をコミットまたはロールバックする必要があります。Oracle Databaseはネットワーク全体でトランザクション制御を調整し、ネットワーク障害やシステム障害が発生した場合にもデータ整合性が保たれるようにする必要があります。

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

2フェーズ・コミット

2フェーズ・コミット・メカニズムは、分散トランザクションに関係するすべてのデータベースが、そのトランザクション内の文のすべてをコミットするか、すべてを取り消すかのどちらか一方のみになるように保証するものです。このメカニズムでは、整合性制約、リモート・プロシージャ・コールおよびトリガーによって実行される暗黙的DMLも保護されます。

複数データベース間の2フェーズ・コミットでは、1つのデータベースで分散トランザクションが調整されます。開始ノードはグローバル・コーディネータと呼ばれます。このコーディネータによって、他のデータベースでコミットの準備ができているかどうかが確認されます。いずれかのデータベースで否定のレスポンスがあった場合は、トランザクション全体がロールバックされます。すべてのデータベースから肯定のレスポンスがあった場合は、コーディネータからメッセージがブロードキャストされ、各データベース上でコミットが確定されます。

2フェーズ・コミット・メカニズムは、分散トランザクションを発行するユーザーからは意識されません。事実、ユーザーは、トランザクションが分散していることも認識する必要はありません。トランザクションの終了を示すCOMMIT文は、自動的に2フェーズ・コミット・メカニズムをトリガーします。データベース・アプリケーション本体に分散トランザクションを含めるのに、コーディングや複雑な構文の記述は必要ありません。

関連項目:
2フェーズ・コミットの詳細は、『Oracle Database管理者ガイド』を参照してください。

インダウト・トランザクション

インダウト分散トランザクションは、システム障害やネットワーク障害によって2フェーズ・コミットが中断されたときに発生します。たとえば、2つのデータベースから調整データベースにコミットの準備ができたことが報告されたものの、このメッセージの受信直後に調整データベース・インスタンスが失敗した場合などです。この場合、コミットの準備ができている2つのデータベースはハング状態となり、結果の通知を待機し続けます。

リカバラ(RECO)・バックグラウンド・プロセスでは、インダウト分散トランザクションの結果が自動的に解決されます。障害が修復され、通信が再確立された後、各ローカルのOracleデータベースのRECOプロセスが、関係するすべてのノード上でインダウト分散トランザクションを自動的にコミットするか、ロールバックします。

長時間にわたる障害が発生した場合、Oracle Databaseでは、各ローカル管理者が障害によって発生したインダウト分散トランザクションを手動でコミットまたは取り消すことができます。このオプションにより、ローカル・データベース管理者は、長時間にわたる障害によって無期限にロックされる可能性のあるリソースを解放できます。

あるデータベースを過去のある時点までリカバリする必要がある場合、データベースのリカバリ機能を使用すると、他のサイトのデータベース管理者が、自分のデータベースを過去のその同じ時点に戻すことができます。この操作により、グローバル・データベースは一貫した状態に保たれます。

関連項目:

- 「リカバラ・プロセス(RECO)」

- インダウト・トランザクションの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

第IV部

Oracleデータベース記憶域構造

この部では、論理的および物理的な記憶域構造など、Oracleデータベースの基本的な構造上のアーキテクチャについて説明します。

この部の構成は、次のとおりです。

- 第11章「物理記憶域構造」

- 第12章「論理記憶域構造」

11 物理記憶域構造

この章では、Oracleデータベースの主要な物理データベース構造について説明します。物理構造は、オペレーティング・システム・レベルで表示可能です。

この章の内容は、次のとおりです。

- 物理記憶域構造の概要

- データファイルの概要

- 制御ファイルの概要

- オンラインREDOログの概要

物理記憶域構造の概要

RDBMSの特徴の1つは、表、ビュー、索引などの論理データ構造が物理記憶域構造から独立していることです。物理構造と論理構造は分離されているため、論理構造へのアクセスに影響を与えずに、データの物理記憶域を管理できます。たとえば、データベース・ファイルの名前を変更しても、ファイルに格納されている表の名前は変更されません。

Oracleデータベースは、Oracleデータを永続ディスク記憶域に格納する一連のファイルです。この項では、CREATE DATABASE文を発行したときに生成されるデータベース・ファイルについて説明します。

- データファイルと一時ファイル
データファイルはディスク上にOracle Databaseが作成した物理ファイルであり、表や索引などのデータ構造が含まれます。一時ファイルは一時表領域に属するデータファイルです。これらのファイルには、他のプログラムでは読み取ることのできないOracle固有のフォーマットでデータが書き込まれます。

- 制御ファイル
制御ファイルは、データベースの物理コンポーネントを追跡するためのルート・ファイルです。

- オンラインREDOログ・ファイル
オンラインREDOログは、データに対する変更が記録される一連のファイルです。

データベース・インスタンスは、データベース・ファイルを管理する一連のメモリー構造です。図11-1に、インスタンスとインスタンスによって管理されるファイルの間の関係を示します。

図11-1 データベース・インスタンスとデータベース・ファイル

関連項目:

- データベースの作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE DATABASEの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

データベース・ファイル格納のメカニズム

データベース・ファイルの記憶域の割当ておよび管理には、複数のメカニズムを使用できます。一般的なメカニズムは、次のとおりです。

- Oracle Automatic Storage Management (Oracle ASM)
Oracle ASMには、Oracle Databaseでのみ使用できるよう設計されたファイルシステムが含まれています。Oracle ASMについては、「Oracle Automatic Storage Management(Oracle ASM)」を参照してください。

- オペレーティング・システムのファイルシステム
ほとんどのOracleデータベースでは、ファイルをファイルシステムに格納します(ファイルシステムは、連続するディスク・アドレス空間内に構築されたデータ構造です)。すべてのオペレーティング・システムには、ファイルシステム内でディスク領域のファイルへの割当ておよび割当て解除を実行するファイル・マネージャがあります。

ファイルシステムを使用すると、多数のファイルにディスク領域を割り当てることができます。各ファイルには名前があり、Oracle Databaseなどのアプリケーションに対して連続するアドレス空間として表示されます。データベースでは、ファイルの作成、読取り、書込み、サイズ変更および削除が可能です。

通常、ファイルシステムは、論理ボリューム・マネージャ(LVM)と呼ばれるソフトウェア・パッケージによって作成される論理ボリュームの最上部に構築されます。LVMを使用すると、複数の物理ディスクの断片を単一の連続するアドレス空間に結合し、ソフトウェアの上位レイヤーに対して1つのディスクとして表示できます。

- RAWデバイス
RAWデバイスは、ファイルシステムでフォーマットされないディスク・パーティションまたは論理ボリュームです。RAWデバイスの主な利点は、ダイレクトI/Oを実行し、より規模の大きいバッファを記述できることです。ダイレクトI/Oでは、オペレーティング・システムのバッファ・キャッシュを介さず、アプリケーションからストレージ・デバイスへの書込みおよび読取りを直接実行できます。

注意:
現在では多くのファイルシステムで、独自のキャッシュを管理するデータベースおよびその他のアプリケーションに対し、ダイレクトI/Oがサポートされるようになりました。以前は、RAWデバイスはダイレクトI/Oを実装するための手段でした。

- クラスタ・ファイルシステム
クラスタ・ファイルシステムとは、領域割当ておよびファイル内容の一貫性を維持しながら、複数のコンピュータでファイルの記憶域を共有できるようにするソフトウェアです。Oracle RAC環境でクラスタ・ファイルシステムを使用すると、共有記憶域が、クラスタ化環境内の多数のコンピュータによって共有されるファイルシステムとして表示されます。クラスタ・ファイルシステムを使用すると、クラスタ内のいずれかのコンピュータで障害が発生しても、ファイルシステムが使用できなくなることはありません。ただし、オペレーティング・システムのファイルシステムで、NFSなどの方法を使用してファイルを共有するコンピュータに障害が発生した場合、ファイルシステムは使用できません。

データベースでは、これらのストレージ・メカニズムを組み合せて使用します。たとえば、データベースでは、従来のファイルシステムに制御ファイルとオンラインREDOログ・ファイルを、RAWパーティションに一部のユーザー・データファイルを、Oracle ASMに残りのデータファイルを、クラスタ・ファイルシステムにアーカイブREDOログ・ファイルを格納できます。

関連項目:

- Oracle Enterprise Manager(Enterprise Manager)を使用したデータベース記憶域構造の表示方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- データベース・ビューを問い合せてデータベース記憶域構造を表示する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

Oracle Automatic Storage Management (Oracle ASM)

Oracle ASMは、高パフォーマンスで管理しやすいOracle Databaseファイルのストレージ・ソリューションです。Oracle ASMはボリューム・マネージャであり、データベースでのみ使用できるよう設計されたファイルシステムが備えられています。

Oracle ASMには、従来のファイルシステムおよびストレージ・マネージャと比較して、次のような利点があります。

- データベースの作成およびレイアウトやディスク領域の管理など、ストレージ関連のタスクが簡略化されます。

- 複数の物理ディスクにわたってデータが配分されるため、ホットスポットがなくなり、ディスク間のパフォーマンスが均一になります。

- ストレージ構成が変わると、データのバランスが自動的に再調整されます。

Oracle ASMを使用するには、ストライプ化およびミラー化のプリファレンスを使用して、Oracle Databaseのパーティション化したディスクを割り当てます。Oracle ASMによってディスク領域が管理され、使用可能なすべてのリソースにI/O負荷が配分されるため、I/Oを手動でチューニングしなくてもパフォーマンスが最適化されます。たとえば、データベースを停止しなくても、データベースのディスクのサイズを増加し、データベースの一部を新しいデバイスに移動できます。

Oracle ASMのストレージ・コンポーネント

Oracle Databaseでは、データファイルをOracle ASMディスク・グループ内のOracle ASMファイルとして格納でき、Oracle ASMディスク・グループとは、1つの単位としてOracle ASMで管理される、ディスクのコレクションのことです。ディスク・グループ内では、各データベース・ファイルに使用するファイルシステム・インタフェースがOracle ASMによって公開されます。

図11-2に、Oracle ASMを使用するデータベース内のストレージ・コンポーネント間の関係を示します。このダイアグラムは、Oracle ASMファイルとデータファイルの間の関係を表していますが、Oracle ASMには他のタイプのファイルも格納できます。線の末端の分岐は、1対多の関係を表しています。

図11-2 Oracle ASMのコンポーネント

図11-2は、次のOracle ASMの概念を示しています。

- Oracle ASMディスク

Oracle ASMディスクは、Oracle ASMディスク・グループにプロビジョニングされるストレージ・デバイスです。Oracle ASMディスクは、物理ディスクまたはパーティション、ストレージ・アレイからの論理ユニット番号(LUN)、論理ボリュームまたはネットワーク接続ファイルのいずれでもかまいません。

Oracle ASMディスク・グループ内のOracle ASMディスクは、データベースの稼働中に追加または削除できます。ディスクをディスク・グループに追加するときは、ディスク名を割り当てます(割り当てない場合は、Oracle ASMディスク名が自動的に指定されます)。

- Oracle ASMディスク・グループ

Oracle ASMディスク・グループは、1つの論理単位として管理されるOracle ASMディスクのコレクションです。ディスク・グループのデータ構造は自己完結型で、ディスク・グループの一部のディスク領域を使用します。

ディスク・グループ内では、各Oracleデータベース・ファイルに使用するファイルシステム・インタフェースがOracle ASMによって公開されます。ディスク・グループに格納される各ファイルの内容は均等に配分(つまりストライプ化)されるため、ホットスポットがなくなり、ディスク間のパフォーマンスが均一化されます。このパフォーマンスは、RAWデバイスのパフォーマンスに匹敵します。

- Oracle ASMファイル

Oracle ASMファイルは、Oracle ASMディスク・グループに格納されるファイルです。Oracle Databaseは、ファイルに関してOracle ASMと通信します。データベースには、データファイル、制御ファイル、オンラインREDOログ・ファイルなどの様々なファイルをOracle ASMファイルとして格納できます。データベースから要求されると、Oracle ASMによってOracle ASMファイルが作成され、プラス記号(+)の後にディスク・グループ名が続く完全修飾名(+DISK1など)が、このファイルに割り当てられます。

注意:
Oracle ASMファイルは、RAWディスクやサード・パーティのファイルシステムなど他のストレージ管理オプションと共存できます。この機能により、Oracle ASMを既存の環境に統合する作業が簡素化されます。

- Oracle ASMエクステント
Oracle ASMエクステントは、Oracle ASMファイルの内容を保持するために使用されるRAWストレージです。1つのOracle ASMファイルは1つ以上のファイル・エクステントで構成されます。それぞれのOracle ASMエクステントは、特定のディスク上にある1つ以上の割当て単位で構成されます。

注意:
Oracle ASMエクステントは、データをセグメントに格納するために使用されるエクステントとは異なります。

- Oracle ASM割当て単位
割当て単位とは、ディスク・グループ内での割当ての基本単位です。割当て単位は、Oracle ASMによって割り当てられる最小の連続するディスク領域になります。1つ以上の割当て単位によって、1つのOracle ASMエクステントが構成されます。

関連項目:

- Oracle Enterprise Manager(Enterprise Manager)を使用したOracle ASMディスクの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- Oracle ASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

Oracle ASMインスタンス

Oracle ASMインスタンスは、Oracle ASMディスクを管理する特殊なOracleインスタンスです。ASMインスタンスとデータベース・インスタンスは両方ともASMディスク・グループ内のディスクへの共有アクセスを必要とします。ASMインスタンスはディスク・グループのメタデータを管理し、データベース・インスタンスにファイル・レイアウト情報を提供します。データベース・インスタンスは、ASMインスタンスにアクセスせずに、ASMディスクに対してダイレクトI/Oを実行します。

ASMインスタンスは、データベース・インスタンスと同じテクノロジに基づいて構築されます。たとえば、ASMインスタンスには、データベース・インスタンスと同様のシステム・グローバル領域(SGA)およびバックグラウンド・プロセスがあります。ただし、ASMインスタンスではデータベースをマウントできず、実行されるタスクもデータベース・インスタンスより少なくなります。

図11-3に、Oracle ASMインスタンスが1つとデータベース・インスタンスが2つあり、それぞれが異なる単一インスタンス・データベースに関連付けられている単一ノード構成を示します。このASMインスタンスによってメタデータが管理され、2つのデータベースのデータが格納されているASMファイルの領域が割り当てられます。一方のASMディスク・グループにはASMディスクが4つあり、もう一方には2つあります。いずれのデータベース・インスタンスも、これらのディスク・グループにアクセスできます。

図11-3 Oracle ASMインスタンスとデータベース・インスタンス

関連項目:

- Oracle Enterprise Manager(Enterprise Manager)を使用したOracle ASMディスクの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- Oracle ASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

Oracle Managed Filesおよびユーザー管理ファイル

Oracle Managed Filesとは、ファイル名ではなく、データベース・オブジェクトの観点で操作を指定できるようにするためのファイル命名方法です。たとえば、表領域のデータファイルの名前を指定しなくても、表領域を作成できます。このため、Oracle Managed Filesでは、データベース内のオペレーティング・システム・ファイルを管理者が直接管理する必要がなくなります。Oracle ASMではOracle Managed Filesが必要です。

注意:
この機能は、トレース・ファイル、監査ファイル、アラート・ログなどの管理ファイルの作成または命名には影響を与えません(「診断ファイルの概要」を参照)。

ユーザー管理ファイルを使用すると、データベース内のオペレーティング・システム・ファイルをユーザーが直接管理できます。ユーザーは、ファイルの構造および名前を決定できます。たとえば、表領域を作成する場合は、表領域データファイルの名前とパスを設定します。

初期化パラメータを使用して、特定タイプのファイルに使用するファイルシステム・ディレクトリを指定します。Oracle Managed Filesの主な役割は、データベースによって一意のファイルが作成され、そのファイルが不要になったら削除されるようにすることです。データベースでは、標準のファイルシステム・インタフェースを内部で使用して、データファイルと一時ファイル、制御ファイル、および高速リカバリ領域に格納されているリカバリ関連ファイルなどのファイルが作成および削除されます。

Oracle Managed Filesを使用しても、既存の機能は削除されません。以前のファイルを手動で管理しながら、新しいファイルを作成できます。このため、データベースにはOracle Managed Filesとユーザー管理ファイルが混在する場合があります。

関連項目:
Oracle Managed Filesの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

データファイルの概要

Oracle Databaseでは、オペレーティング・システム・レベルで、データベース・データがデータファイルに格納されます。すべてのデータベースには、少なくとも1つのデータファイルが必要です。

データファイルの使用

第IV部「Oracleリレーショナル・データ構造」では、ユーザーがデータを格納する論理構造について説明しましたが、この中で最も重要なデータは表です。パーティション化されていない各スキーマ・オブジェクトと各オブジェクトのパーティションは、それぞれ独自のセグメントに格納されます。

Oracle Databaseでは、管理を容易にするために、セグメントと同様の論理記憶域構造である表領域内のユーザー・データに領域が割り当てられます。各セグメントは、1つの表領域にのみ属します。たとえば、パーティション化されていない表のデータは1つのセグメントに格納され、このセグメントは1つの表領域に格納されます。

Oracle Databaseでは、表領域データがデータファイルに物理的に格納されます。表領域とデータファイルは密接に関連していますが、次のような重要な違いがあります。

- 各表領域は1つ以上のデータファイルから構成され、このデータファイルはOracle Databaseを実行しているオペレーティング・システムに準拠します。

- データベースのデータは、そのデータベースの各表領域内にあるデータファイルにまとめて格納されます。

- セグメントは1つ以上のデータファイルにまたがることがありますが、複数の表領域にまたがることはありません。

- データベースには、SYSTEM表領域とSYSAUX表領域が必要です。Oracle Databaseでは、データベースの作成時に、データベースの最初のデータファイルがSYSTEM表領域に自動的に割り当てられます。
SYSTEM表領域には、データベースのメタデータを含む一連の表であるデータ・ディクショナリが含まれています。通常、データベースにはUNDO表領域と一時表領域(通常の名前はTEMP)もあります。

図11-4に、表領域、データファイルおよびセグメントの関係を示します。

図11-4 データファイルと表領域

関連項目:

- 「表領域の概要」

- データファイルの管理方法の詳細は、『Oracle Database管理者ガイド』および『Oracle Database 2日でデータベース管理者』を参照してください。

永続データファイルと一時データファイル

永続表領域には、永続スキーマ・オブジェクトが含まれています。永続表領域内のオブジェクトはデータファイル内に格納されます。

一時表領域には、セッションの持続時間中のみスキーマ・オブジェクトが存在します。ローカルで管理される一時表領域には、ハッシュやソートなどの操作でデータを格納するための特殊なファイルである(一時ファイル)が含まれています。一時ファイルには、メモリー内の領域が不足したときの結果セットのデータも格納されます。

一時ファイルは永続データファイルと似ていますが、次のような例外があります。

- 表などの永続データベース・オブジェクトは、一時ファイルには格納されません。

- 一時ファイルは常にNOLOGGINGモードに設定され、これは、一時ファイルにはREDOが生成されないということを意味します。メディア・リカバリは一時ファイルを認識しません。

- 一時ファイルを読取り専用にすることはできません。

- ALTER DATABASE文では一時ファイルを作成できません。

- 一時ファイルを作成またはサイズ変更する場合、指定したファイル・サイズのディスク領域が常に保証されるとはかぎりません。LinuxやUNIXなどのファイルシステムでは、一時ファイルはスパース・ファイルとして作成されます。この場合、ディスク・ブロックはファイルの作成時やサイズ変更時ではなく、最初にブロックがアクセスされるときに割り当てられます。

注意:
スパース・ファイルを使用すると、一時ファイルの作成とサイズ変更が素早く行えますが、一時ファイルにアクセスしたときに、ディスク領域が不足する可能性があります。

- 一時ファイルの情報は、データ・ディクショナリ・ビューDBA_TEMP_FILESと動的パフォーマンス・ビューV$TEMPFILEには表示されますが、DBA_DATA_FILESビューやV$DATAFILEビューには表示されません。

関連項目:

- 「一時表領域」

- 一時ファイルの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

オンライン・データファイルとオフライン・データファイル

すべてのデータファイルは、オンライン(使用可能)またはオフライン(使用不可能)のいずれかです。個々のデータファイルまたは一時ファイルの可用性は、ファイルをオフラインにするか、オンラインにして変更できます。オフラインのデータファイルには、ファイルが再びオンラインになるまでアクセスできません。

管理者がデータファイルをオフラインにする理由は、オフライン・バックアップの実行、データファイルの名前変更、ブロックの破損など数多くあります。データベースでは、データファイルに書き込めない場合に、ファイルが自動的にオフラインになります。

データファイルと同様に、表領域自体もオフラインまたはオンラインになります。オンラインの表領域にあるデータファイルをオフラインにしても、表領域自体はオンラインのままです。表領域自体をオフラインにすると、表領域のすべてのデータファイルを一時的に使用不可能にできます。

関連項目:

- 「オンライン表領域とオフライン表領域」

- データファイルの可用性を変更する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

データファイルの構造

Oracle Databaseでは、表領域のデータファイルを作成する際に、指定されたディスク領域に加えて、データファイル・ヘッダーのオーバーヘッドの領域が割り当てられます。Oracle Databaseを実行するオペレーティング・システムによって、ファイルから古い情報や認可が消去された後、そのファイルがデータベースに割り当てられます。

データファイル・ヘッダーには、サイズやチェックポイントSCNなど、データファイルに関するメタデータが含まれています。各ヘッダーには、絶対ファイル番号と相対ファイル番号が含まれます。絶対ファイル番号は、データベース内でデータファイルを一意に識別します。相対ファイル番号は、表領域内でデータファイルを一意に識別します。

Oracle Databaseでデータファイルが初めて作成されると、割り当てられたディスク領域がフォーマットされますが、ユーザー・データは含まれません。ただし、データベースでは、関連付けられた表領域の将来のセグメントのデータを保持する領域が確保されます。Oracle Databaseでは、表領域内のデータが増加すると、データファイル内の空き領域を使用してセグメントにエクステントを割り当てます。

図11-5に、データファイル内の各種の領域を示します。エクステントは、使用中(セグメント・データが含まれている場合)または空き(再使用が可能な場合)のいずれかです。表領域内のオブジェクトの更新または削除が繰り返されると、単独では新しいデータに再使用できるほど大きくはないものの、孤立した空き領域ができる場合があります。このような空き領域を断片化空き領域と呼びます。

図11-5 データファイル内の領域

関連項目:
データファイル情報の表示方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

制御ファイルの概要

データベースの制御ファイルは、1つのデータベースのみに関連付けられた小さなバイナリ・ファイルです。各データベースには一意の制御ファイルが1つありますが、複数の同一コピーが保持される場合もあります。

制御ファイルの使用

制御ファイルは、データベース・ファイルの検索やデータベース全体の状態の管理にOracle Databaseで使用されるルート・ファイルです。制御ファイルには、次のような情報が含まれています。

- データベース名およびデータベースの一意の識別子(DBID)

- データベースを作成したときのタイムスタンプ

- データファイル、オンラインREDOログ・ファイルおよびアーカイブREDOログ・ファイルに関する情報

- 表領域情報

- RMANバックアップ

制御ファイルは、次のような目的で使用されます。

- データベースをオープンするために必要となるデータファイル、およびオンラインREDOログ・ファイルなどに関する情報を格納します。
制御ファイルは、データベースに対する構造上の変更を追跡します。たとえば、管理者がデータファイルやオンラインREDOログ・ファイルの追加、名前変更または削除を実行すると、データベースで制御ファイルが更新され、変更が反映されます。

- データベースがオープンしていないときにアクセスする必要があるメタデータを格納します。
制御ファイルには、チェックポイントなどデータベースのリカバリに必要な情報などが含まれています。チェックポイントは、インスタンス・リカバリの開始が必要な時点である、REDOストリームにおけるSCNを示します(「インスタンス・リカバリの概要」を参照)。チェックポイントSCNの前にコミットされたすべての変更は、データファイルのディスクに保存されることが保証されます。チェックポイント・プロセスは、オンラインREDOログ内のチェックポイント位置に関する情報を、少なくとも3秒ごとに制御ファイルに記録します。

Oracle Databaseでは、データベースの使用中に制御ファイルの読取りと書込みが絶えず実行されるため、データベースがオープンしているときは、常に書込み可能であることが必要です。たとえば、データベースのリカバリには、データベースに含まれているすべてのデータファイルの名前を制御ファイルから読み取る必要があります。データファイルの追加など他の操作を実行すると、制御ファイルに格納された情報が更新されます。

関連項目:

- 「チェックポイント・プロセス(CKPT)」

- 制御ファイルの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

多重制御ファイル

Oracle Databaseでは、同じデータベースに対する同一の制御ファイルを同時に複数オープンし、書き込むことができます。1つの制御ファイルを複数のディスク上で多重化することにより、データベースの冗長性が実現されるため、シングル・ポイント障害を回避できます。

注意:
多重制御ファイルのコピーをそれぞれ異なるディスクで維持することをお薦めします。

制御ファイルが使用不可能になると、データベース・インスタンスからこの破損した制御ファイルへのアクセスが試行されたときに、インスタンスが失敗します。現行の制御ファイルのコピーが他にある場合は、メディア・リカバリを実行しなくても、データベースを再マウントしてオープンできます。ただし、データベースのすべての制御ファイルが失われた場合は、インスタンスが失敗し、メディア・リカバリが必要になります。現行の制御ファイルを使用できず、制御ファイルの古いバックアップを使用する場合、メディア・リカバリは容易ではありません。

関連項目:

- 多重制御ファイルを維持する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 制御ファイルのバックアップおよびリストア方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

制御ファイルの構造

データベースに関する情報は、制御ファイルの異なるセクションに格納されます。各セクションは、データベースの特定の側面に関するレコードの集合です。たとえば、制御ファイルの1つのセクションではデータファイルが追跡され、レコードの集合がデータファイルごとに1つ含まれています。各セクションは、複数の論理的な制御ファイル・ブロックに格納されます。レコードは、1つのセクション内の複数のブロックにまたがる場合があります。

制御ファイルには、次のようなレコードが含まれています。

- 循環再利用レコード
このレコードには、必要に応じて上書きできる重要度の低い情報が含まれます。使用可能なレコード・スロットがすべて使用されると、データベースは、制御ファイルを拡張して新規レコード用の領域を作成するか、または最も古いレコードを上書きします。たとえば、アーカイブREDOログ・ファイルやRMANバックアップのレコードなどです。

- 非循環再利用レコード
このレコードには、頻繁な変更がなく、上書きできない重要な情報が含まれます。たとえば、表領域、データファイル、オンラインREDOログ・ファイル、REDOスレッドなどの情報です。Oracle Databaseでは、対応するオブジェクトが表領域から削除されないかぎり、これらのレコードを再使用しません。

「動的パフォーマンス・ビューの概要」で説明しているように、動的パフォーマンス・ビュー(V$ビューとも呼ばれる)を問い合せて、制御ファイルに格納されている情報を表示できます。たとえば、V$DATABASEを問い合せると、データベース名およびDBIDを取得できます。ただし、制御ファイルの情報を変更できるのは、そのデータベースのみです。

制御ファイル・ブロックの読取りおよび書込みは、データ・ブロックの場合とは異なります。制御ファイルの場合、Oracle Databaseでは読取りおよび書込みがディスクからプログラム・グローバル領域(PGA)に直接行われます。各プロセスでは、そのPGAメモリーの一定量が制御ファイル・ブロックに割り当てられます。

関連項目:

- V$CONTROLFILE_RECORD_SECTIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

オンラインREDOログの概要

リカバリにとって最も重要な構造がオンラインREDOログであり、このログは、データベースの変更が発生したときにその変更が格納される、事前に割り当てられた複数のファイルで構成されます。オンラインREDOログには、データファイルに対する変更が記録されます。

オンラインREDOログの使用

データベースでは、オンラインREDOログ・ファイルを維持してデータ損失を防ぎます。特に、インスタンス障害の後には、オンラインREDOログ・ファイルを使用すると、Oracle Databaseではまだデータファイルに書き込まれていないコミット済のデータをリカバリできます。

Oracle Databaseでは、すべてのトランザクションがREDOログ・バッファと同期して書き込まれ、その後、REDOログ・バッファがオンラインREDOログに書き込まれます。ログの内容には、コミットされていないトランザクション、UNDOデータ、スキーマおよびオブジェクトの管理文などがあります。

Oracle Databaseでは、オンラインREDOログはリカバリにのみ使用されます。ただし、管理者はOracle LogMinerユーティリティでSQLインタフェースを使用して、オンラインREDOログ・ファイルを問い合せることができます(「Oracle LogMiner」を参照)。REDOログ・ファイルは、データベース・アクティビティに関する履歴情報の入手に役立ちます。

関連項目:
「インスタンス・リカバリの概要」

Oracle DatabaseでのオンラインREDOログの書込み方法

データベース・インスタンスのオンラインREDOログは、REDOスレッドと呼ばれます。単一インスタンス構成では、1つのインスタンスしかデータベースにアクセスできないため、REDOスレッドは1つのみです。ただし、Oracle Real Application Clusters(Oracle RAC)構成では、複数のインスタンスが同時にデータベースにアクセスし、各インスタンスには独自のREDOスレッドがあります。インスタンスごとにREDOスレッドを分けると、オンラインREDOログ・ファイルの1つの集合に対する競合を回避できます。

オンラインREDOログは、複数のオンラインREDOログ・ファイルで構成されています。Oracle Databaseでは、ファイルの1つがアーカイブ中であっても(データベースがARCHIVELOGモードの場合)、もう1つのファイルが常に書込み可能であることを保証するため、少なくとも2つ以上のファイルが必要です。

関連項目:
Oracle RAC内のオンラインREDOログ・グループの詳細は、『Oracle Database 2日でReal Application Clustersガイド』および『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

オンラインREDOログ・スイッチ

Oracle Databaseでは、オンラインREDOログ・ファイルを一度に1つのみ使用して、REDOログ・バッファから書き込まれるレコードを格納します。ログ・ライター(LGWR)プロセスによる書込みがアクティブなオンラインREDOログ・ファイルは、現行のオンラインREDOログ・ファイルと呼ばれます。

ログ・スイッチは、データベースで1つのオンラインREDOログ・ファイルへの書込みが停止し、別のファイルへの書込みが開始するときに発生します。スイッチは通常、現行のオンラインREDOログ・ファイルがいっぱいになり、さらに書込みを継続する必要があるときに発生します。ただし、ログ・スイッチは、現行のオンラインREDOログ・ファイルがいっぱいになったかどうかに関係なく、定期的にログ・スイッチが発生するように構成し、手動で強制的に実行できます。

ログ・ライターでは、オンラインREDOログ・ファイルが循環的に書き込まれます。ログ・ライター・プロセスは、使用可能な最後のオンラインREDOログ・ファイルがいっぱいになると、最初のログ・ファイルへ書き込み、循環が再び始まります。図11-6に、REDOログの循環書込みを示します。

図11-6 オンラインREDOログ・ファイルの再使用

図11-6の数字は、それぞれのオンラインREDOログ・ファイルへのLGWRによる書込みの順序を示しています。データベースでは、ログ・スイッチが発生し、ログ・ライターが書込みを開始したときに、各ファイルに新しいログ順序番号を割り当てます。データベースでオンラインREDOログ・ファイルが再使用されると、このファイルには次に使用可能なログ順序番号が与えられます。

いっぱいになったオンラインREDOログ・ファイルは、アーカイブ・モードに応じて再利用できます。

- アーカイブが無効、つまりデータベースがNOARCHIVELOGモードの場合、ファイルに記録された変更のチェックポイント(書込み)処理がデータベース・ライター(DBW)によってディスクに実行されるまで、いっぱいになったオンラインREDOログ・ファイルを使用できません。

- アーカイブが有効、つまりデータベースがARCHIVELOGモードの場合は、変更がデータファイルに書き込まれ、そのファイルがアーカイブされた後、いっぱいになったオンラインREDOログ・ファイルをログ・ライターで使用できるようになります。

状況によっては、既存のオンラインREDOログ・ファイルをログ・ライターで再利用できない場合もあります。たとえば、オンラインREDOログ・ファイルが非アクティブ(インスタンス・リカバリに不要)ではなく、アクティブ(インスタンス・リカバリに必要)な場合などです。また、オンラインREDOログ・ファイルが消去プロセスの途中である場合もあります。

関連項目:

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

- オンラインREDOログの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

オンラインREDOログ・ファイルの複数コピー

Oracle Databaseでは、オンラインREDOログの複数の同一コピーを別個の場所で自動的に維持できます。オンラインREDOログ・グループは、1つのオンラインREDOログ・ファイルと複数の冗長コピーで構成されています。それぞれの同一コピーは、オンラインREDOログ・グループのメンバーです。各グループはグループ1、グループ2のように番号で定義されます。

オンラインREDOログ・グループの複数のメンバーを維持すると、REDOログの損失を防ぐことができます。メンバーの場所を別個のディスクに配置し、1つのディスクで障害が発生してもオンラインREDOログ全体が失われないようにすることが理想的です。

図11-7では、A_LOG1とB_LOG1はグループ1の同一のメンバーであり、A_LOG2とB_LOG2はグループ2の同一のメンバーです。同じグループの各メンバーは同じサイズである必要があります。LGWRでは、グループ1(メンバーA_LOG1とB_LOG1)への書込みが同時に実行された後、グループ2(メンバーA_LOG2とB_LOG2)への書込みが同時に実行され、次に、再びグループ1への書込みが実行されます。LGWRでは、異なるグループのメンバーに同時に書き込まれることはありません。

図11-7 オンラインREDOログ・ファイルの複数コピー

注意:
オンラインREDOログは、多重化することをお薦めします。ログ・ファイルの損失は、リカバリが必要な場合に壊滅的な被害を招く可能性があります。オンラインREDOログを多重化する場合は、データベースで実行されるI/Oの量が増加します。システムによっては、I/Oをこのように追加すると、データベース全体のパフォーマンスに影響を与える場合があります。

関連項目:
オンラインREDOログ・ファイルの複数コピーを維持する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

アーカイブREDOログ・ファイル

アーカイブREDOログ・ファイルとは、オンラインREDOログ・グループ内のいっぱいになったメンバーのコピーです。このファイルはデータベースの一部とはみなされませんが、データベースによって作成されたオンラインREDOログ・ファイルのオフライン・コピーであり、ユーザーが指定した場所に書き込まれます。

アーカイブREDOログ・ファイルは、バックアップおよびリカバリ計画にとって重要です。アーカイブREDOログ・ファイルは、次の目的に使用できます。

- データベース・バックアップのリカバリ

- スタンバイ・データベースの更新(「コンピュータ障害」を参照)

- LogMinerユーティリティの使用によるデータベースの履歴情報の取得(「Oracle LogMiner」を参照)

アーカイブとは、アーカイブREDOログ・ファイルを生成する操作です。アーカイブは自動の場合と手動の場合があり、データベースがARCHIVELOGモードの場合のみ実行可能です。

アーカイブREDOログ・ファイルには、オンラインREDOログ・グループの同一メンバーのREDOエントリ、およびログ順序番号が含まれています。図11-7では、ファイルA_LOG1とB_LOG1がグループ1の同一メンバーです。データベースがARCHIVELOGモードで、自動アーカイブが有効になっている場合は、アーカイバ・プロセス (ARCn)によってこれらのファイルの1つがアーカイブされます。A_LOG1が破損している場合は、B_LOG1をアーカイブできます。アーカイブREDOログには、アーカイブを有効にした後に作成されたすべてのグループのコピーが含まれます。

関連項目:

- 「データファイル・リカバリ」

- アーカイブREDOログの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

オンラインREDOログの構造

オンラインREDOログ・ファイルには、REDOレコードが含まれています。REDOレコードは、変更ベクトルのグループで構成され、それぞれの変更ベクトルは、データ・ブロックに対する変更を表します。たとえば、employees表の給与を更新すると、この表のデータ・セグメント・ブロック、UNDOセグメント・データ・ブロックおよびUNDOセグメントのトランザクション表に対する変更を記述するREDOレコードが生成されます。

REDOレコードには、変更に関係するすべてのメタデータが設定されます。たとえば、次のものがあります。

- 変更のSCNおよびタイムスタンプ

- 変更が生成されたトランザクションのトランザクションID

- トランザクションがコミットされたときのSCNおよびタイムスタンプ(トランザクションがコミットされた場合)

- 変更を実行した操作のタイプ

- 変更されたデータ・セグメントの名前およびタイプ

関連項目:
「データ・ブロックの概要」

12 論理記憶域構造

この章では、論理記憶域構造の性質と論理記憶域構造間の関係について説明します。これらの構造は、Oracle Databaseによって作成されて認識されるものであり、オペレーティング・システムでは認識されません。

この章の内容は、次のとおりです。

- 論理記憶域構造の概要

- データ・ブロックの概要

- エクステントの概要

- セグメントの概要

- 表領域の概要

論理記憶域構造の概要

Oracle Databaseでは、データベース内のすべてのデータに対して論理領域が割り当てられます。データベース領域の論理単位は、データ・ブロック、エクステント、セグメントおよび表領域です。物理レベルでは、データはディスク上のデータファイルに格納されます(第11章「物理記憶域構造」を参照)。データファイル内のデータは、オペレーティング・システムのブロックに格納されます。

図12-1に、物理記憶域と論理記憶域のエンティティ関係ダイアグラムを示します。線の末端の分岐は、1対多の関係を表しています。

図12-1 論理記憶域と物理記憶域

論理記憶域階層

図12-2に、表領域内のデータ・ブロック、エクステントおよびセグメント間の関係を示します。この例では、1つのセグメントに対して、異なるデータファイルに格納された2つのエクステントがあります。

図12-2 表領域内のセグメント、エクステントおよびデータ・ブロック

Oracle Databaseデータの最小レベルでの格納単位は、データ・ブロックです。1つの論理データ・ブロックは、一定のバイト数(たとえば2KB)の物理ディスク領域に対応します。データ・ブロックは、Oracle Databaseで使用または割当て可能な記憶域の最小単位です。

エクステントとは、論理的に連続する一連のデータ・ブロックで、特定のタイプの情報を格納するために割り当てられます。図12-2では、24KBのエクステントには12のデータ・ブロックが存在し、72KBのエクステントには36のデータ・ブロックが存在しています。

セグメントとは、表などの特定のデータベース・オブジェクトのために割り当てられるエクステントの集合です。たとえば、employees表のデータはそれぞれ専用のデータ・セグメントに格納されており、employeesの各索引はそれぞれ専用の索引セグメントに格納されています。記憶域を使用する各データベース・オブジェクトは、1つのセグメントを構成します。

各セグメントは、1つの表領域にのみ属しています。このため、1つのセグメントのすべてのエクステントは、同じ表領域に格納されます。図12-2に示すように、表領域内のセグメントには、複数のデータファイルのエクステントが含まれている場合があります。たとえば、セグメントのあるエクステントはusers01.dbfに格納され、他のセグメントはusers02.dbfに格納されます。1つのエクステントが複数のデータファイルにまたがることはありません。

関連項目:
「データファイルの概要」

論理領域管理

Oracle Databaseでは、表領域内でエクステントの追跡および割当てを行うために論理領域管理を使用する必要があります。データベース・オブジェクトでエクステントが必要な場合、データベースには、エクステントを検索および提供する手段が必要です。同様に、オブジェクトでエクステントが不要になった場合、データベースに空きエクステントを使用可能にする手段が必要です。

Oracle Databaseでは、作成する表領域のタイプに基づいて、表領域内の領域が管理されます。次のいずれかのタイプの表領域を作成できます。

- ローカル管理表領域(デフォルト)
エクステントの管理に、表領域自体にあるビットマップが使用されます。したがって、ローカル管理表領域の一部には、ビットマップ用の表領域があります。表領域内のセグメントは、自動セグメント領域管理(ASSM)または手動セグメント領域管理(MSSM)を使用して管理できます。

- ディクショナリ管理表領域
エクステントの管理に、データ・ディクショナリが使用されます(「データ・ディクショナリの概要」を参照)。

図12-3に、表領域の論理領域管理の方法を示します。

図12-3 論理領域管理

ローカル管理表領域

ローカル管理表領域では、データファイル・ヘッダー内に、データファイル本体の空き領域および使用済領域を追跡するためのビットマップが保持されています。各ビットは、1ブロック・グループに対応します。領域が割り当てられるか、解放されると、Oracle Databaseでは、ビットマップの値がブロックの新しい状態を反映する値に変更されます。

ビットマップ管理記憶域を概念的に表現すると、次の図のようになります。ヘッダー内の1は使用済領域を表し、0は空き領域を表します。

ローカル管理表領域には、次のような利点があります。

- エクステントの管理にデータ・ディクショナリを使用する必要がありません。
ディクショナリ管理表領域では、エクステント内の領域を使用または解放することにより、データ・ディクショナリ表やUNDOセグメントの領域を使用または解放する他の操作が行われた場合、再帰的な操作が発生することがあります。

- 隣接する空き領域が自動的に追跡されます。
これにより、データベースで空きエクステントを結合する必要がなくなります。

- ローカル管理エクステントのサイズが自動的に決定されます。
また、ローカル管理表領域内では、すべてのエクステントを同じサイズにすることもでき、さらにオブジェクト記憶域オプションがオーバーライドされます。

注意:
ローカル管理表領域と自動セグメント領域管理を使用することをお薦めします。

セグメント領域管理は、セグメントを含む表領域から継承される属性です。ローカル管理表領域内では、セグメントは自動または手動で管理できます。たとえば、表領域users内はセグメントを自動で、表領域tools内のセグメントは手動で管理できます。

自動セグメント領域管理

ASSM方式では、領域の管理にビットマップが使用されます。ビットマップには、次の利点があります。

- 管理の簡素化
ASSMでは、多数の記憶域パラメータの設定を手動で厳密に決定する必要がありません。唯一の重要なSQLパラメータPCTFREEによって、領域割当てが制御されます。このパラメータは、将来の更新用にブロック内に予約する領域の割合を指定します(「データ・ブロック内の空き領域の割合」を参照)。

- 同時実行性の向上
複数のトランザクションで別々の空きデータ・ブロックのリストを検索できるため、競合や待機時間が減少します。多数の標準的なワークロードでは、適切にチューニングされた、MSSMを使用するアプリケーションよりも、ASSMを使用するアプリケーションの方が高いパフォーマンスを示します。

- Oracle Real Application Clusters(Oracle RAC)環境における、インスタンスへの領域の動的アフィニティ

ASSMは永続的なローカル管理表領域に対するデフォルトであり、より効率的です。

注意:
この章では、論理記憶域のすべての説明において、ASSMを使用することを前提としています。

手動セグメント領域管理

従来のMSSM方式では、空きリストと呼ばれるリンク・リストを使用して、セグメントの空き領域が管理されます。空き領域が存在するデータベース・オブジェクトでは、空きリストによって、使用済のセグメント領域と未使用のセグメント領域を分割するラインである最高水位標(HWM)より下のブロックが追跡されます。ブロックが使用済になると、データベースは必要に応じて、空きリストにブロックを登録したり、空きリストからブロックを削除したりします。

MSSMでは、PCTFREE以外にもPCTUSED、FREELISTS、FREELIST GROUPSなどのSQLパラメータを使用して、領域割当てを制御する必要があります。PCTUSEDでは、現在使用されているブロックが空きリストに登録されるためには、どの程度の空き領域が必要なのかの割合を設定します。たとえば、CREATE TABLE文でPCTUSEDを40に設定すると、ブロックの使用済領域の割合が40%未満になるまでは、セグメント内のブロックに行を挿入できません。

例として、表に行を挿入するとします。データベースは表の空きリストを参照し、最初の空き領域がどこなのかをチェックします。行がブロックに格納し切れず、ブロック内の使用済領域がPCTUSED以上になっている場合、そのブロックはリストから除外され、別のブロックが検索されます。ブロックから行を削除した場合は、ブロック内の使用済領域がPCTUSED未満になったかどうかがチェックされます。PCTUSED未満になった場合は、そのブロックが空きリストの先頭に登録されます。

1つのオブジェクトに対して、空きリストを複数にすることもできます。こうしておくと、表に対してDMLを実行している複数のセッションが別々のリストを使用できるため、競合を回避できます。各データベース・セッションがセッション中に使用する空きリストは1つです。

図12-4に示すように、1つ以上の空きリスト・グループ(空きリストの集合)が存在するオブジェクトを1つ作成することもできます。各グループにはマスター空きリストがあり、グループ内の各プロセス空きリストを管理します。空きリストに必要な領域は、特に空きリスト・グループの場合、大きくなることがあります。

図12-4 空きリスト・グループ

セグメント領域を手動で管理する手順は複雑です。行の移行(「行の連鎖と移行」を参照)を少なくし、領域を無駄にしないようにするには、PCTFREEおよびPCTUSEDを調整する必要があります。たとえぱ、セグメント内のどの使用済ブロックも半分の領域がいっぱいになっており、PCTUSEDが40になっている場合は、これらのブロックのいずれにも挿入できません。領域割当てパラメータの詳細なチューニングは難しいため、ASSMの使用をお薦めします。ASSMでは、ブロックに新しい行を挿入可能かどうかを判断するためにPCTFREEが使用されますが、空きリストは使用されず、PCTUSEDは無視されます。

関連項目:

- ローカル管理表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 自動セグメント領域管理の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

- PCTFREEやPCTUSEDなどの記憶域パラメータの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ディクショナリ管理表領域

ディクショナリ管理表領域では、データ・ディクショナリを使用してそのエクステントが管理されます。Oracle Databaseでは、エクステントが割り当てられたり、再利用のために解放されるたびに、データ・ディクショナリ内の表が更新されます。たとえば、表でエクステントが必要な場合は、データ・ディクショナリ表が問い合せられ、空きエクステントが検索されます。領域が見つかると、あるデータ・ディクショナリ表が変更され、別のデータ・ディクショナリ表に行が挿入されます。このようにデータを変更および移動することによって、領域が管理されます。

データベース・オブジェクト用の領域を取得するため、データベースでバックグラウンドで実行されるSQLは、再帰的SQLです。データ・ディクショナリへの更新はシリアライズされる必要があるため、再帰的SQLを頻繁に使用するとパフォーマンスに悪影響を与える可能性があります。デフォルトのローカル管理表領域では、このようなパフォーマンス上の問題は回避されます。

関連項目:
ディクショナリ管理表領域からローカル管理表領域への移行方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

データ・ブロックの概要

Oracle Databaseでは、データベースのデータファイル内の論理記憶域は、データ・ブロックと呼ばれる単位で管理されます(データ・ブロックは、Oracleブロックまたはページとも呼ばれます)。データ・ブロックは、データベースI/Oの最小単位です。

データ・ブロックとオペレーティング・システム・ブロック

物理レベルでは、データベースのデータは、オペレーティング・システム・ブロックによって構成されているディスク・ファイル内に格納されます。オペレーティング・システム・ブロックは、オペレーティング・システムが読取りまたは書込みできるデータの最小単位です。一方、Oracleブロックは、論理記憶域構造であり、そのサイズや構造はオペレーティング・システムには認識されません。

図12-5に、オペレーティング・システム・ブロックのサイズがデータ・ブロックのサイズと異なる場合があることを示します。データベースでは、オペレーティング・システム・ブロックではなく、データ・ブロックの倍数を単位としてデータを要求します。

図12-5 データ・ブロックとオペレーティング・システム・ブロック

データベースがデータ・ブロックを要求すると、オペレーティング・システムは、この操作を永続ストレージ内のデータに対する要求に変換します。データ・ブロックをオペレーティング・システム・ブロックから論理的に分離することは、次のことを意味します。

- アプリケーションでは、データのディスク上の物理アドレスを特定する必要がありません。

- データベースのデータは、複数の物理ディスクにストライプ化またはミラー化できます。

データベース・ブロック・サイズ

すべてのデータベースには、データベース・ブロック・サイズがあります。DB_BLOCK_SIZE初期化パラメータでは、データベース作成時のデータ・ブロック・サイズが設定されます。このサイズは、SYSTEM表領域およびSYSAUX表領域に対して設定され、他のすべての表領域のデフォルトとなります。データベース・ブロック・サイズは、データベースを再作成する場合以外は変更できません。

DB_BLOCK_SIZEが設定されていない場合、デフォルトのデータ・ブロック・サイズは、オペレーティング・システム固有のサイズになります。データベースの標準的なデータ・ブロック・サイズは、4KBまたは8KBです。データ・ブロックのサイズとオペレーティング・システム・ブロックのサイズが異なる場合、データ・ブロックのサイズは、オペレーティング・システム・ブロックのサイズの倍数である必要があります。

関連項目:

- DB_BLOCK_SIZE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- ブロック・サイズの選択方法の詳細は、『Oracle Database管理者ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

表領域ブロック・サイズ

DB_BLOCK_SIZEの設定とは異なるブロック・サイズの表領域を個別に作成できます。非標準のブロック・サイズは、トランスポータブル表領域を別のプラットフォームに移動する場合に役立ちます。

関連項目:
表領域に非標準のブロック・サイズを指定する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

データ・ブロックの形式

すべてのデータ・ブロックには、形式、つまりデータベースでのブロック内のデータや空き領域の追跡を可能にする内部構造があります。この形式は、データ・ブロックに表、索引、表クラスタのいずれのデータが含まれている場合でも同じです。図12-6に、非圧縮データ・ブロックの形式を示します(圧縮ブロックについては、「データ・ブロックの圧縮」を参照)。

図12-6 データ・ブロックの形式

データ・ブロック・オーバーヘッド

Oracle Databaseでは、ブロック・オーバーヘッドを使用してブロック自体を管理します。ブロック・オーバーヘッドには、ユーザー・データは格納できません。図12-6に示すように、ブロック・オーバーヘッドには次の構成要素が含まれています。

- ブロック・ヘッダー
ブロック・ヘッダーには、ディスク・アドレスやセグメント・タイプなどブロックについての一般的な情報が含まれています。トランザクション管理ブロックの場合、ブロック・ヘッダーにはアクティブなトランザクション情報とトランザクション履歴情報が含まれています。

ブロックを更新する各トランザクションには、トランザクション・エントリが必要です。Oracle Databaseでは、トランザクション・エントリ用の領域が最初にブロック・ヘッダーに予約されます。トランザクションによる変更をサポートするセグメントに割り当てられたデータ・ブロックでは、ヘッダー領域の空きがなくなると、トランザクション・エントリが空き領域にも保持されます。トランザクション・エントリに必要な領域のサイズは、オペレーティング・システムによって異なります。ただし、ほとんどのオペレーティング・システムで、トランザクション・エントリのサイズは約23バイトです。

- 表ディレクトリ
ヒープ構成表では、このディレクトリには、該当するブロックに行を格納する表についてのメタデータが含まれています。複数の表の行が同じブロックに格納されることもあります。

- 行ディレクトリ
ヒープ構成表では、このディレクトリはブロックのデータ部分内の行の位置を示しています。

行ディレクトリに領域が割り当てられると、行が削除された後もこの領域は再利用されません。したがって、現在は空き状態でも、以前に最大50行が格納されていた場合は、行ディレクトリには100バイトが割り当てられたままになります。この領域は、ブロックに新しい行が挿入された場合にのみ再利用されます。

一部のブロック・オーバーヘッドはサイズが固定ですが、全体のサイズは可変です。ブロック・オーバーヘッド全体のサイズは、平均で84から107バイトです。

行形式

ブロックの行データ部分には、表の行や索引キー・エントリなどの実際のデータが格納されます。すべてのデータ・ブロックに内部形式があるように、すべての行に行形式があり、これにより、データベースにおける行のデータ追跡が可能になります。

Oracle Databaseでは、行は可変長レコードとして格納されます。行は、1つ以上の行断片に含まれています。各行断片は、行ヘッダーおよび列データで構成されます。

図12-7に、行の形式を示します。

図12-7 行断片の形式

行ヘッダー

Oracle Databaseでは、行ヘッダーを使用して、ブロック内に格納された行断片を管理します。行ヘッダーには、次のような情報が含まれています。

- 行断片内の列

- 他のデータ・ブロック内にある行の断片
Oracle Databaseでは、行全体を単一のデータ・ブロックに挿入できる場合、その行は1つの行断片として格納されます。ただし、行データのすべてを単一のブロックに挿入できない場合、または行の更新によって既存の行が単一のブロックに収まらなくなった場合には、その行は複数の行断片として格納されます(「行の連鎖と移行」を参照)。データ・ブロックには、通常1つの行につき1つの行断片のみが含まれています。

- 表クラスタのクラスタ・キー(「表クラスタの概要」を参照)

1つのブロックに完全に収まる行は、最低3バイトの行ヘッダーを持っています。

列データ

行ヘッダーの後ろにある列データ・セクションに、行の実際のデータが格納されます。行断片には通常、CREATE TABLE文で指定された順序で列が格納されますが、必ずこの順序であるとはかぎりません。たとえば、LONG型の列は最後に作成されます。

Oracle Databaseでは、図12-7に示すように、行断片内の各列の長さとデータが別々に格納されます。必要な領域のサイズは、データ型によって異なります。列のデータ型が可変長である場合、値を保持するために必要な領域は、データの更新によって変動します。

各行には、データ・ブロック・ヘッダーの行ディレクトリにスロットがあります。このスロットは行の先頭を指しています。

関連項目:
「表の記憶域」および「索引記憶域」

ROWID形式

Oracle Databaseでは、ROWIDを使用して行が一意に識別されます。内部的には、ROWIDは、データベースが行にアクセスするために必要な情報を保持する構造です。ROWIDは、物理的にはデータベースに格納されませんが、データが格納されているファイルやブロックから推論されます。

拡張ROWIDには、データ・オブジェクト番号が含まれています。このROWIDタイプは、各行の物理アドレスをBASE64エンコーディングで表現したものです。エンコーディング文字は、AからZ、aからz、0から9、+および/です。

例12-1では、ROWID擬似列を問い合せて、employees表にある従業員100の行の拡張ROWIDを表示します。

例12-1 ROWID擬似列

SQL> SELECT ROWID FROM employees WHERE employee_id = 100;

ROWID
------------------
AAAPecAAFAAAABSAAA

図12-8に、拡張ROWIDの形式を示します。

図12-8 ROWID形式

拡張ROWIDは、OOOOOOFFFBBBBBBRRRという4つの部分から構成される形式で表示されます。各部分の内容は、次のとおりです。

- OOOOOO
セグメントを識別するデータ・オブジェクト番号(例12-1では、データ・オブジェクトAAAPecです)。データ・オブジェクト番号は、各データベース・セグメントに割り当てられます。同じセグメント内のスキーマ・オブジェクト(表クラスタなど)は、同じデータ・オブジェクト番号を持っています。

- FFF
行を含むデータファイルを識別する表領域関連のデータファイル番号(例12-1では、ファイルAAFです)。

- BBBBBB
行を含むブロックを識別するデータ・ブロック番号(例12-1では、ブロックAAAABSです)。ブロック番号は、表領域ではなくデータファイルに対する相対値です。このため、同じブロック番号の行が、同じ表領域の異なるデータファイルに存在することもあります。

- RRR
ブロック内の行を識別する行番号(例12-1では、行AAAです)。

特殊な状況では、ROWIDが行断片に割り当てられた後、ROWIDが変更される場合があります。たとえば、行の移動が可能な場合、ROWIDは、パーティション・キーの更新、フラッシュバック表の操作、表の縮小操作などのために変更される可能性があります。行の移動が無効な場合は、Oracle Databaseユーティリティを使用して行をエクスポートおよびインポートした場合にROWIDが変更される可能性があります。

注意:
内部的には、行の移動は、行が物理的に削除されて再挿入されたものとして実行されます。ただし、行の移動は更新であるとみなされ、これはトリガーに影響します。

関連項目:

- 「ROWIDデータ型」

- ROWIDの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

データ・ブロックの圧縮

データベースでは、表の圧縮を使用して、データ・ブロック内の重複値を排除します(「表の圧縮」を参照)。この項では、圧縮を使用するデータ・ブロックの形式について説明します。

基本および高度な行圧縮を使用するデータ・ブロックの形式は、基本的には非圧縮ブロックの形式と同じです。相違点は、ブロックの先頭にあるシンボル表に、行および列の重複値が格納されることです。Oracle Databaseでは、発生した重複値はシンボル表の短い参照で置き換えられます。

例12-2の行が、7列で構成されたsales表のデータ・ブロックに格納されるとします。

例12-2 sales表の行

2190,13770,25-NOV-00,S,9999,23,161
2225,15720,28-NOV-00,S,9999,25,1450
34005,120760,29-NOV-00,P,9999,44,2376
9425,4750,29-NOV-00,I,9999,11,979
1675,46750,29-NOV-00,S,9999,19,1121

この表に基本または高度な行圧縮が適用されると、重複値がシンボル参照に置き換えられます。例12-3は、圧縮の概念を示しており、29-NOV-00がシンボル*、9999が%に置き換えられています。

例12-3 sales表のOLTP圧縮行

2190,13770,25-NOV-00,S,%,23,161
2225,15720,28-NOV-00,S,%,25,1450
34005,120760,*,P,%,44,2376
9425,4750,*,I,%,11,979
1675,46750,*,S,%,19,1121

表12-1は、シンボルを値にマップするシンボル表の概念を示します。

表12-1 シンボル表

シンボル

値

列

行

*

29-NOV-00

3

958-960

%

9999

5

956-960

データ・ブロック内の領域管理

Oracle Databaseでは、データ・ブロックは下から順に使用されるため、行データとブロック・ヘッダー間の空き領域は減少します。この空き領域は、行の末尾のNULLがNULL以外の値に変更されるときなどの更新の際にも減少します。Oracle Databaseでは、パフォーマンスを最適化し、領域を無駄にしないようにするために、データ・ブロック内の空き領域が管理されます。

注意:
この項では、自動セグメント領域管理の使用を前提としています。

データ・ブロック内の空き領域の割合

PCTFREE記憶域パラメータは、データベースにおける空き領域の管理にとって不可欠です。このSQLパラメータでは、既存の行の更新用に空き領域として予約される領域の最小の割合を設定します。したがって、行の移行を防止し、領域を無駄にしないようにするためにPCTFREEが必要です。

たとえば、ほとんど更新されず、更新される場合でも既存のデータのサイズがほとんど増加しない表を作成するとします。CREATE TABLE文内のPCTFREEパラメータを次のように指定します。

CREATE TABLE test_table (n NUMBER) PCTFREE 20;

図12-9に、PCTFREEを20に設定した場合の領域管理への影響について示します。時間の経過とともにブロックに行が追加され、行データがブロック・ヘッダーの方向へ上向きに増加し、ブロック・ヘッダー自体も、行データの方向へ下向きに増加します。PCTFREEの設定によって、データ・ブロックの20%以上が空き領域となることが保証されます。たとえば、行を挿入すると行データとヘッダーの合計がブロック領域全体の90%を占め、空き領域が10%になる場合には、INSERT文は実行できません。

図12-9 PCTFREE

注意:
この説明は、PCTFREE記憶域パラメータや空きリストを使用しないLOBデータ型については該当しません。「LOBの概要」を参照してください。

関連項目:
PCTFREEパラメータの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

データ・ブロック内の空き領域の最適化

空き領域の割合は、PCTFREEよりも小さくなることはありませんが、大きくなることがあります。たとえば、PCTFREEを20%に設定すると、空き領域の合計がブロックの5%になることはありませんが、50%になることはあります。次のSQL文を使用すると、空き領域のサイズが増えます。

- DELETE文

- 既存の値をより小さいサイズの値に更新するか、既存の値をより大きいサイズの値に更新して行の移行を強制するUPDATE文

- OLTP圧縮を使用する表に対するINSERT文
挿入によってブロックがデータでいっぱいになると、データベースによってブロック圧縮が開始され、ブロックにより多くの空き領域が生じる可能性があります。

解放された領域は、次の条件下でINSERT文に使用できます。

- INSERT文が同じトランザクション内に存在し、領域を解放した文の後にある場合、その文で使用可能になった領域を使用できます。

- INSERT文が、領域を解放する文とは別のトランザクションに含まれている(別々のユーザーが実行している)場合、その文では、もう一方のトランザクションがコミットされた後で、しかもその領域が必要とされる場合にかぎり、使用可能になった領域を使用できます。

関連項目:
OLTP圧縮の詳細は、『Oracle Database管理者ガイド』を参照してください。

断片化領域の結合

図12-10に示すように、解放された領域は、データ・ブロック内の主な空き領域と連続しているとはかぎりません。連続しない空き領域は、断片化領域と呼ばれます。

図12-10 断片化領域があるデータ・ブロック

Oracle Databaseでは、次の条件に当てはまる場合にのみ、データ・ブロックの空き領域が自動的かつ透過的に結合されます。

- INSERT文またはUPDATE文において、新しい行断片を格納するために十分な空き領域のあるブロックの使用が試行された場合。

- 空き領域が断片化されており、行断片をブロック内の連続したセクションに挿入できない場合。

結合後の空き領域のサイズは結合前と同じですが、領域は連続的に存在するようになります。図12-11に、領域結合後のデータ・ブロックを示します。

図12-11 空き領域結合後のデータ・ブロック

Oracle Databaseでは、前述の状況でのみ結合が実行されます。それ以外の状況で結合を実行すると、データ・ブロック内の空き領域が連続的に結合されることによって、パフォーマンスが低下する可能性があるためです。

索引領域の再利用

データベースでは、索引ブロック内の領域を再利用できます。たとえば、ある列に値を挿入してから削除し、この列に索引が設定されている場合は、この索引が行で必要になったときに、索引スロットを再利用できます。

データベースでは、索引ブロック自体を再利用できます。表ブロックとは異なり、索引ブロックは空になったときにのみ解放されます。空になったブロックは索引構造の空きリスト上に配置され、再利用が可能となります。ただし、Oracle Databaseでは、索引は自動的には圧縮されず、ALTER INDEX REBUILD文またはCOALESCE文を実行する必要があります。

図12-12に、索引結合前のemployees.department_id列の索引を示します。最初の3つのリーフ・ブロックは、グレーの格納ラインで示されているように、まだ満杯ではありません。

図12-12 結合前の索引

図12-13に、図12-12の索引を結合した後の図を示します。最初の2つのリーフ・ブロックは、グレーの格納ラインで示されているように満杯になり、3つ目のリーフ・ブロックは解放されています。

図12-13 結合後の索引

関連項目:

- 索引を結合および再構築する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- COALESCE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

行の連鎖と移行

Oracle Databaseでは、大きすぎる行を1つのブロック内に収まるように管理する必要があります。次の状況が考えられます。

- 最初に行を挿入するとき、大きすぎて1つのデータ・ブロック内に収まらない場合。
行連鎖では、Oracle Databaseにより、その行のデータは、セグメント用に確保された1つ以上のデータ・ブロックの連鎖に格納されます。多くの場合、行連鎖は、行が大きい場合に発生します。大きい行の例には、LONGまたはLONG RAWデータ型の列を含む行、2KBブロックにVARCHAR2(4000)の列が含まれる行、または行に含まれる列の数が多すぎる場合があります。そのような場合の行連鎖は、避けられません。

- 1つのデータ・ブロックに収まっていた行が更新されて、行全体の長さが増加したが、更新後の行を保持する十分な空き領域がない場合。
行の移行では、Oracle Databaseにより、行全体が新しいブロックに収まることを前提として、行全体が新しいデータ・ブロックに移動されます。移行された行の元の行断片には、行の移行先の新しいブロックへのポインタまたは「転送先アドレス」が含まれます。そのため、移動された行のROWIDは変わりません。

- 行に255を超える列が含まれる場合。
Oracle Databaseでは、1つの行断片に格納できる列数は、255列のみです。したがって、1000列の行を表に挿入すると、データベースでは通常、複数のブロックに連鎖された4つの行断片が作成されます。

図12-14に、データ・ブロックへの大きなサイズの行の挿入を示します。この行は左側のブロックには大きすぎて格納し切れないため、Oracle Databaseでは行を連鎖し、最初の行断片を左側のブロックに配置し、2つ目の行断片を右側のブロックに配置します。

図12-14 行の連鎖

図12-15では、左側のブロックには、更新によってサイズが増大してこのブロックに収まらなくなった行が格納されています。Oracle Databaseにより、この行全体が右側のブロックに移動され、この移行後の行へのポインタが左側のブロックに残されます。

図12-15 行の移行

行が連鎖または移行されると、データの取出しに必要なI/Oが増加します。これは、その行の情報を取り出す際に、Oracle Databaseが複数のブロックをスキャンする必要があるためです。たとえば、索引の読取りに対して1回のI/Oを行い、移行されていない表の行を読み取るために1回のI/Oを行う場合、移行された行のデータを取得するために追加のI/Oが必要になります。

セグメント・アドバイザは、再利用可能な領域のあるセグメントを特定するOracle Databaseコンポーネントであり、手動または自動で実行できます。セグメント・アドバイザを使用すると、多くの空き領域のあるオブジェクト、または多くの連鎖行があるオブジェクトについてのアドバイスを入手できます。

関連項目:

- 「行の格納」および「行断片のROWID」

- 無駄に使用された領域を再利用する方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

- 行の連鎖と移行を削減する方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

エクステントの概要

エクステントは、複数の連続したデータ・ブロックで構成される、データベース記憶域の割当ての論理単位です。エクステント内のデータ・ブロックは論理的に連続していますが、RAIDのストライプ化やファイルシステムの実装によって、物理的にはディスク上に断続的に存在する可能性があります。

エクステントの割当て

データベースでは、セグメントが作成されたときにデータ・セグメント用の初期エクステントがデフォルトで割り当てられます。エクステントは、常に1つのデータファイルに含まれています。

セグメントにデータが追加されていない場合でも、初期エクステント内にこのセグメント専用のデータ・ブロックが予約されます。各セグメントの最初のデータ・ブロックには、そのセグメント内のエクステントのディレクトリが含まれています。図12-16に、データが含まれていなかったデータファイル内の、セグメントの初期エクステントを示します。

12-16 セグメントの初期エクステント

初期エクステントがいっぱいになり、さらに追加の領域が必要になると、データベースによって自動的にこのセグメントの増分エクステントが割り当てられます。増分エクステントは、セグメントに対して後から作成されるエクステントです。

割当てアルゴリズムは、ローカル管理表領域であるか、ディクショナリ管理表領域であるかに応じて異なります。ローカル管理表領域の場合は、データファイルのビットマップで、隣接する空きブロックが検索されます。データファイルに十分な領域がない場合は、他のデータファイルが検索されます。セグメントのエクステントは常に同じ表領域内に存在しますが、異なるデータファイル内に存在する場合もあります。

図12-17に、セグメントのエクステントは表領域内の任意のデータファイル内に割当て可能であることを示します。たとえば、セグメントの初期エクステントをusers01.dbfに、最初の増分エクステントをusers02.dbfに、次のエクステントをusers01.dbfに割り当てることができます。

図12-17 セグメントの増分エクステント

新しく割り当てられたエクステントのブロックは、空き領域であったブロックですが、古いデータが残っていることがあります。ASSMでは、新たに割り当てられたエクステントの使用開始時に、Oracle Databaseによってそのエクステントのブロックがフォーマットされます(「セグメント領域と最高水位標」を参照)。

注意:
この項は、1つのサーバー・プロセスによって文を解析して実行する、シリアル操作に適用されます。複数のサーバー・プロセスを必要とするパラレルSQL文では、エクステントは異なる方法で割り当てられます。

関連項目:
手動でのエクステントの割当て方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

エクステントの割当て解除

一般的に、ユーザー・セグメントのエクステントは、DROPコマンドを使用してオブジェクトを削除するまでは表領域に戻されません。Oracle Database 11gリリース2(11.2.0.2)では、DBMS_SPACE_ADMINパッケージを使用してセグメントを削除することもできます。たとえば、表の行をすべて削除しても、データベースによりデータ・ブロックが再利用されて表領域内の他のオブジェクトがそれらのブロックを使用できるようになることはありません。

注意:
UNDOセグメントでは、サイズにOPTIMALが指定されている場合、またはデータベースが自動UNDO管理モードである場合には、Oracle Databaseにより定期的に1つ以上のエクステントの割当てが解除されます(「UNDO表領域」を参照)。

領域の割当てを手動で解除できる場合もあります。Oracle Segment Advisorは、オブジェクト内の断片化のレベルに応じて、オブジェクトに再利用可能な領域があるかどうかを判断する際に役立ちます。次の方法でエクステントを解放できます。

- オンラインでのセグメントの縮小を使用して、セグメント内の断片化された領域を再利用します。セグメントの縮小は、オンラインのインプレース操作です。一般的に、データ圧縮によって、より効率的にキャッシュを利用できるようになり、全表スキャン時に読み取る必要があるブロック数が少なくなります。

- パーティション化されていない表や表パーティションのデータを新しいセグメントに移動し、必要であれば割当て制限を持つ別の表領域に移動できます。

- 索引を再構築または結合します(「索引領域の再利用」を参照)。

- 表または表クラスタを切り捨てて、すべての行を削除します。デフォルトで、Oracle Databaseでは、MINEXTENTS記憶域パラメータで指定されたサイズを除き、削除された行で使用していたすべての領域の割当てが解除されます。Oracle Database 11gリリース2(11.2.0.2)では、DROP ALL STORAGEオプションを指定してTRUNCATEを使用すれば、セグメント全体を削除することもできます。

- 未使用領域の割当てを解除して、データベース・セグメントの最後の最高水位標付近の未使用領域を解放し、表領域内の他のセグメントがその領域を使用できるようにします(「セグメント領域と最高水位標」を参照)。

エクステントが解放されると、Oracle Databaseでは、ローカル管理表領域のデータファイル内のビットマップを変更し、再度取得されたエクステントを使用可能領域として反映します。解放されたエクステントのブロックにあるデータにはアクセスできなくなります。

関連項目:
セグメント領域の再利用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

エクステントの記憶域パラメータ

各セグメントは、エクステントについての設定である記憶域パラメータによって定義されます。記憶域パラメータにより、Oracle Databaseで特定のセグメントに空き領域がどのように割り当てられるかが制御されます。

記憶域設定は、次に示す優先順位で決定されます。つまり、リストの上位の設定は下位の設定よりも優先されます。

1. セグメントのSTORAGE句

2. 表領域のSTORAGE句

3. Oracle Databaseのデフォルト

ローカル管理表領域の場合は、均一のエクステント・サイズでも、システムによって自動的に決定される可変エクステント・サイズでもかまいません。

- 均一エクステントの場合は、エクステント・サイズを指定するか、デフォルト・サイズである1MBを使用できます。表領域内のすべてのエクステントが指定したサイズになります。ローカル管理一時表領域の場合は、均一サイズの割当てのみ使用できます。

- 自動割当てエクステントの場合は、追加エクステントの最適サイズがOracle Databaseにより自動的に決定されます。

ローカル管理表領域では、一部の記憶域パラメータは表領域レベルでは指定できません。ただし、これらのパラメータをセグメント・レベルで指定することはできます。この場合、データベースでは、すべてのパラメータをまとめて使用して、セグメントの初期サイズが計算されます。内部のアルゴリズムによって、その後に割り当てられる各エクステントのサイズが決定されます。

関連項目:

- ローカル管理表領域を作成する場合のエクステント管理についての考慮事項の詳細は、『Oracle Database管理者ガイド』を参照してください。

- STORAGE句のオプションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

セグメントの概要

セグメントは、表領域内の特定の論理記憶域構造のデータがすべて入っている、エクステントの集合です。たとえば、Oracle Databaseでは、1つ以上のエクステントを割り当てることによって、表のデータ・セグメントを形成します。データベースでは、表の索引セグメントも、1つ以上のエクステントを割り当てることによって形成します。

「論理領域管理」で説明しているように、Oracle Databaseでは、セグメント領域は自動または手動で管理されます。この項では、ASSMを使用することを前提としています。

ユーザー・セグメント

データベース内の1つのデータ・セグメントには、1つのユーザー・オブジェクトのデータが格納されます。セグメントには様々なタイプがあります。次に、ユーザー・セグメントの例を示します。

- 表、表パーティションまたは表クラスタ

- LOBまたはLOBパーティション

- 索引または索引パーティション

パーティション化されていない各オブジェクトおよび各オブジェクト・パーティションは、それぞれ独自のセグメントに格納されます。たとえば、索引に5つのパーティションがある場合は、5つのセグメントに索引データが格納されます。

ユーザー・セグメントの作成

デフォルトで、データベースでは遅延セグメント作成により、表や索引を作成する際、データベース・メタデータのみが更新されます。Oracle Database 11gリリース2(11.2.0.2)以降では、パーティションを作成する際に、セグメント作成の遅延も発生します。ユーザーが最初の行を表またはパーティションに挿入するときに、その表またはパーティション、LOB列およびその索引のセグメントが作成されます。

セグメントの作成は遅延するため、データベース・リソースを必要以上に使用しなくて済みます。たとえば、アプリケーションをインストールすると、数千ものオブジェクトが作成されて、ディスク領域を大量に消費する場合があります。このようなオブジェクトの多くは、実際には使用されない可能性があります。

DBMS_SPACE_ADMINパッケージを使用して、空のオブジェクト用のセグメントを管理できます。Oracle Database 11gリリース2(11.2.0.2)以降では、このPL/SQLパッケージを使用して次の操作を行うことができます。

- セグメントが作成されていない空の表またはパーティション用のセグメントの手動マテリアライズ

- 空のセグメントが割り当てられている空の表またはパーティションからのセグメントの削除

オブジェクトの作成とセグメントの作成との関係がわかりやすくなるように、遅延セグメント作成は発生しないものとします。次のような表を作成するとします。

CREATE TABLE test_table (my_column NUMBER);

図12-18に示すように、表のセグメントが1つ作成されます。

図12-18 ユーザー・セグメントの作成

主キーまたは一意キーを持つ表を作成する場合は、Oracle Databaseによって、このキーの索引が自動的に作成されます。ここでも、遅延セグメント作成は発生しないものとします。次のような表を作成するとします。

CREATE TABLE lob_table (my_column NUMBER PRIMARY KEY, clob_column CLOB);

図12-19は、lob_tableのデータがあるセグメントに格納され、暗黙的に作成された索引が別のセグメントに格納されることを示しています。また、CLOBデータは、関連付けられたCLOB索引と同様に、専用のセグメントに格納されます(「内部LOB」を参照)。したがって、CREATE TABLE文を実行すると4つの異なるセグメントが作成されます。

図12-19 複数のセグメント

注意:
表のセグメントとその表の索引のセグメントは、同一の表領域に存在する必要はありません。

セグメントが作成されると、1つ以上のエクステントが割り当てられます。オブジェクトの記憶域パラメータによって、各セグメントに対するエクステントの割当て方法が決定されます(「エクステントの記憶域パラメータ」を参照)。これらのパラメータは、オブジェクトに関連するデータ・セグメントのデータ検索と格納の効率に影響を与えます。

関連項目:

- 遅延セグメント作成の管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- マテリアライズド・ビューとマテリアライズド・ビュー・ログの詳細は、『Oracle Databaseアドバンスト・レプリケーション』を参照してください。

- CREATE TABLEの構文については、『Oracle Database SQL言語リファレンス』を参照してください。

一時セグメント

Oracle Databaseでは、問合せの処理中に、SQL文実行の中間段階で、一時作業領域が必要になることがあります。一時セグメントが必要になる一般的な操作には、ソート、ハッシング、ビットマップのマージなどがあります。また、索引の作成中には索引セグメントも一時セグメントに配置され、索引の作成が完了すると、永続セグメントに変換されます。

Oracle Databaseでは、メモリー内で操作が完了する場合、一時セグメントは作成されません。ただし、メモリーを使用できない場合には、ディスク上に一時セグメントが自動的に割り当てられます。

問合せ用の一時セグメントの割当て

Oracle Databaseでは、ユーザー・セッション中に必要に応じて問合せ用の一時セグメントが割り当てられ、問合せが完了すると削除されます。一時セグメントに対する領域管理操作以外の、一時セグメントに対する変更は、オンラインREDOログに記録されます(「オンラインREDOログの概要」を参照)。

データベースでは、ユーザーに割り当てられた一時表領域に一時セグメントが作成されます。表領域のデフォルトの記憶域特性によって、一時セグメント内のエクステントの特性が決定されます。一時セグメントの割当てと割当て解除は頻繁に発生するため、一時セグメント専用に1つ以上の表領域を作成してください。これにより、I/Oがディスク間で分散され、SYSTEM表領域やその他の一時セグメントがある表領域の断片化が回避されます。

注意:
SYSTEM表領域がローカル管理の場合は、データベースの作成時にデフォルトの一時表領域を定義する必要があります。ローカル管理のSYSTEM表領域は、デフォルトの一時記憶域として使用できません。

関連項目:

- 一時表領域の作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE TEMPORARY TABLESPACEの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

一時表および索引用の一時セグメントの割当て

Oracle Databaseでは、一時表およびその索引用に一時セグメントを割り当てることがあります。一時表には、トランザクションまたはセッションの期間中にのみ存在するデータが保持されます。各セッションは、そのセッションに割り当てられたエクステントにのみアクセスし、他のセッションに割り当てられたエクステントにはアクセスできません。

その表への最初のINSERTが発行されるときに、Oracle Databaseにより一時表のセグメントが割り当てられます。この挿入は、明示的に行われたものでも、CREATE TABLE AS SELECTによって行われたものでもかまいません。一時表に対する最初のINSERT文では、表とその索引にセグメントが割り当てられ、索引のルート・ページが作成され、LOBセグメントが割り当てられます。

一時表のセグメントは、現行ユーザーの一時表領域内で割り当てられます。user1に割り当てられた一時表領域がtemp1であり、user2に割り当てられた一時表領域がtemp2であるとします。この場合、user1の一時データはtemp1のセグメントに格納され、user2の一時データはtemp2のセグメントに格納されます。

関連項目:

- 「一時表」

- 一時表の作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

UNDOセグメント

Oracle Databaseには、UNDOデータと総称されている、トランザクションのアクションのレコードが保持されています。Oracle Databaseでは、次の場合にUNDOデータが使用されます。

- アクティブ・トランザクションのロールバック

- 終了したトランザクションのリカバリ

- 読取り一貫性の実現

- 一部の論理フラッシュバック操作の実行

Oracle Databaseでは、UNDOデータは、外部ログではなくデータベース内部に格納されます。UNDOデータが格納されるブロックは、データ・ブロックと同様に更新され、これらのブロックに対する変更によってREDOデータが生成されます。このように、Oracle Databaseでは、外部ログを読み取ることなくUNDOデータに効率的にアクセスできます。

UNDOデータは、UNDO表領域に格納されます。Oracle Databaseには、UNDO表領域内のUNDOセグメントおよび領域を管理するための自動UNDO管理モードと呼ばれる完全に自動化されたメカニズムが提供されています。

UNDOセグメントとトランザクション

トランザクションが開始するときに、そのトランザクションは、現在のUNDO表領域内のUNDOセグメント(トランザクション表)にバインド(割当て)されます。データベース・インスタンスに対し専用のUNDO表領域が割り当てられていない場合は、トランザクションがシステムUNDOセグメントにバインドされます。

複数のアクティブなトランザクションが、同じUNDOセグメントに同時に書き込むこともあれば、別々のセグメントに書き込むこともあります。たとえば、トランザクションT1とT2が両方ともU1というUNDOセグメントに書き込むこともあれば、T1がU1に書き込み、T2がU2というUNDOセグメントに書き込むこともあります。

概念的には、UNDOセグメント内のエクステントは輪のようなものです。トランザクションは、輪に沿って回るように、UNDOエクステントに順に書き込んでいきます。図12-20では、T1とT2という2つのトランザクションを示し、この2つのトランザクションはそれぞれ、UNDOセグメントの3番目のエクステント(E3)から書込みを開始し、4番目のエクステント(E4)まで書込みを進めます。

図12-20 UNDOセグメントに円環状に割り当てられたエクステント

トランザクションは必ずUNDOセグメント内のエクステントに1つずつ順番に書き込み、その時点で書込み可能なエクステントをトランザクションの現行エクステントと呼びます。複数のアクティブなトランザクションが同時に、同じ現行エクステントに書き込むことも、別々の現行エクステントに書き込むことも可能です。図12-20では、T1とT2のトランザクションがエクステントE3に同時に書き込んでいます。UNDOエクステント内では、各データ・ブロックに格納されるデータは、1つのトランザクションのデータのみです。

現在のUNDOエクステントがいっぱいになると、領域を必要とする最初のトランザクションによって、輪の中にある次の割当てエクステントの空き状況がチェックされます。次のエクステントにアクティブなトランザクションのデータが格納されていない場合は、このエクステントが現行エクステントになります。この時点で、領域を必要としているすべてのトランザクションが、新しい現行エクステントに書込み可能な状態になります。図12-21では、E4がいっぱいになり、T1とT2がE1に書込みを継続し、E1内のアクティブでないUNDOデータを上書きしています。

図12-21 UNDOセグメントに円環状に割り当てられたエクステントの再利用

次のエクステントにアクティブなトランザクションのデータが格納されている場合は、新しいエクステントが割り当てられます。図12-22では、T1とT2はE4に書き込んでいます。E4がいっぱいになっても、E1にはアクティブなUNDOデータが格納されているため、トランザクションはE1に書込みを継続することができません。そこで、このUNDOセグメントに新しいエクステント(E5)が割り当てられます。トランザクションはE5に書込みを継続します。

図12-22 UNDOセグメントに対する新しいエクステントの割当て

関連項目:
UNDOセグメントの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

トランザクションのロールバック

ROLLBACK文が発行されると、UNDOレコードは、コミットされていないトランザクションによってデータベースに加えられた変更を元に戻すために使用されます。リカバリ中には、オンラインREDOログからデータファイルに適用されたコミットされていないすべての変更が元に戻されます。UNDOレコードでは、あるユーザーによるデータの変更中にそのデータにアクセスしているユーザー用に、そのデータの修正前のイメージを維持することで、読取り一貫性が実現されます。

セグメント領域と最高水位標

Oracle Databaseでは、領域を管理するために、セグメント内のブロックの状態を追跡します。最高水位標(HWM)は、セグメント内の位置を指し示し、その位置を超えると、データ・ブロックは未フォーマットであり、使用されていません。

MSSMでは、空きリストを使用してセグメント領域が管理されます。表の作成時には、セグメント内のブロックはフォーマットされていません。セッションが最初に行を表に挿入すると、空きリストが検索され、使用可能なブロックが検出されます。使用可能なブロックが見つからなかった場合には、ブロックのグループが事前にフォーマットされ、それらが空きリストに追加され、ブロックへのデータの挿入が開始されます。MSSMでは、全表スキャンによってHWMより下のすべてのブロックが読み取られます。

ASSMでは空きリストは使用されないため、異なる方法で領域を管理する必要があります。セッションで最初にデータを表に挿入すると、MSSMの場合のようにブロックのグループが事前にフォーマットされるかわりに、1つのビットマップ・ブロックがフォーマットされます。このビットマップでは、セグメント内のブロックの状態が追跡されます(空きリストのかわりとなります)。データベースでは、ビットマップを使用して空きブロックが検索されて、データが格納される前に各ブロックがフォーマットされます。ASSMを使用すると、挿入処理が各ブロックに分散されるため、同時実行性の問題を回避できます。

ASSMセグメント内の各データ・ブロックは、次のいずれかの状態になっています。

- HWMより上
これらのブロックは未フォーマットであり、使用されていません。

- HWMより下
これらのデータ・ブロックは、次のいずれかの状態になっています。

- 割当て済ですが、現時点では未フォーマットで使用されていません。

- フォーマット済でデータが格納されています。

- フォーマット済ですが、データが削除されたため空です。

図12-23に、ブロックを水平方向に並べて表現したASSMのセグメントを示します。表の作成時には、HWMはセグメントの先頭(左端)にあります。まだデータは挿入されていないため、セグメント内のすべてのブロックは未フォーマットで、まだ使用されたことはありません。

図12-23 表作成時のHWM

トランザクションでセグメントに行が挿入されるとします。Oracle Databaseにより、これらの行を保持するためのブロックのグループが割り当てられます。割り当てられたブロックは、HWMに達していません。データベースでは、このグループ内のビットマップ・ブロックはフォーマットされてメタデータが保持されますが、グループ内の他のブロックは事前にフォーマットされません。

図12-24では、HWMより下のブロックは割り当てられていますが、HWMより上のブロックは割当てもフォーマットも行われません。挿入が行われるときに、データベースは空き領域がある任意のブロックに書き込みます。低い最高水位標(低いHWM)は、この位置より下のすべてのブロックは、データが格納されているか、以前にデータが格納されていたため、フォーマット済であることを示しています。

図12-24 HWMと低いHWM

図12-25に示すように、データベースはHWMと低いHWMの間のブロックを選択し、そのブロックに書き込みます。データベースが書込み対象として選択するブロックは、HWMと低いHWMの間のブロックになることもあれば、低いHWMよりも低い、空き領域のあるブロックになることもあります。図12-25に示すように、新しくいっぱいになったブロックの両側のブロックは、未フォーマットになっています。

図12-25 HWMと低いHWM

全表スキャン時には、低いHWMが重要になります。HWMより下のブロックは使用時にのみフォーマットされるため、図12-25に示すように、いくつかのブロックは未フォーマットのままになる可能性があります。このため、Oracle Databaseでは、低いHWMの位置を取得するためにビットマップ・ブロックが読み取られます。低いHWMまでのブロックはフォーマット済であることが既知であるためすべて読み取られ、次に、低いHWMとHWMの間にあるフォーマット済ブロックのみが選択されて読み取られます。

新しいトランザクションによって表に行が挿入されるときに、HWMより下に十分な空き領域が存在しないことがビットマップから判明したとします。この場合は、図12-26に示すように、HWMが右側に移動されて、未フォーマット・ブロックのグループが新しく割り当てられます。

図12-26 HWMと低いHWMの拡張

HWMと低いHWMとの間のブロックに空きがなくなると、HWMが右側に拡張されて、低いHWMも以前のHWMの場所まで拡張されます。データベースにデータが徐々に挿入されるにつれて、HWMは次第に右側へと拡張され、それに伴い、低いHWMもHWMに従って拡張されます。オブジェクトを手動で再構築、切捨てまたは縮小しないかぎり、HWMが縮小することはありません。

関連項目:

- オンラインでセグメントを縮小する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- TRUNCATE TABLEの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

表領域の概要

表領域は、セグメントを格納するための論理記憶域コンテナです。セグメントは表や索引などのデータベース・オブジェクトであり、記憶域領域を使用します。物理レベルでは、表領域のデータは、1つ以上のデータファイルまたは一時ファイルに格納されます。

データベースには、SYSTEM表領域とSYSAUX表領域が必要です。図12-27に、一般的なデータベースの表領域を示します。次の各項では、表領域タイプについて説明します。

図12-27 表領域

永続表領域

永続表領域には、永続スキーマ・オブジェクトがまとめられます。永続表領域内のオブジェクトのセグメントは、物理的にはデータファイルに格納されます。

各データベース・ユーザーには、デフォルトの永続表領域が割り当てられます。非常に小規模なデータベースでは、デフォルトのSYSTEM表領域およびSYSAUX表領域のみで十分な場合があります。ただし、ユーザー・データおよびアプリケーション・データを格納するための表領域を1つ以上作成することをお薦めします。表領域を使用して次の目的を達成できます。

- データベース・データに対するディスク領域の割当てを制御します。

- データベース・ユーザーに割当て制限(領域の許容量または制限)を割り当てます。

- データベース全体の可用性に影響を与えることなく、個別の表領域をオンライン化またはオフライン化します。

- 個別の表領域のバックアップとリカバリを実行します。

- Oracle Data Pumpユーティリティを使用することによって、アプリケーション・データをインポートまたはエクスポートします(「Oracle Data Pumpエクスポートおよびインポート」を参照)。

- データベース間、またはプラットフォーム間でコピーし、移動できるトランスポータブル表領域を作成します。
表領域を移動する場合は、データファイルをコピーして表領域のメタデータを統合するのみでよいため、この方法によるデータ移動は同じデータをエクスポート/インポートまたはアンロード/ロードするよりも何倍も高速です。表領域を移動する場合は、索引データも移動できます。

関連項目:

- 表領域の移動方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。

- ファイルをコピーまたは転送する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

SYSTEM表領域

SYSTEM表領域は、データベースの作成時に生成される、必須の管理表領域です。Oracle Databaseでは、データベースの管理にSYSTEMが使用されます。

SYSTEM表領域には、次の情報が含まれています。これらの情報は、すべてSYSユーザーが所有しています。

- データ・ディクショナリ

- データベースの管理情報を含む表およびビュー

- トリガー、プロシージャ、パッケージなどのコンパイル済ストアド・オブジェクト

SYSTEM表領域は、他のすべての表領域と同様に管理されますが、より高いレベルの権限が必要であり、また一部制限事項があります。たとえば、SYSTEM表領域の名前変更や削除はできません。

デフォルトで、Oracle Databaseでは、新しく作成されたすべてのユーザー表領域がローカル管理に設定されます。ローカル管理のSYSTEM表領域を持つデータベースには、ディクショナリ管理表領域を作成できません(非推奨)。ただし、手動でCREATE DATABASE文を実行してデフォルトを受け入れると、SYSTEM表領域はディクショナリ管理になります。既存のディクショナリ管理SYSTEM表領域をローカル管理形式に移行できます。

注意:
SYSTEM表領域を含むすべての表領域がデフォルトでローカル管理になるように、Database Configuration Assistant(DBCA)を使用して新しいデータベースを作成することをお薦めします。

関連項目:

- SYSTEM表領域の永続的なオンライン条件の詳細は、「オンライン表領域とオフライン表領域」を参照してください。

- DBCAの詳細は、「データベースのインストールおよび構成ツール」を参照してください。

- ローカル管理のSYSTEM表領域を作成する方法、またはローカル管理のSYSTEM表領域に移行する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE DATABASEの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

SYSAUX表領域

SYSAUX表領域は、SYSTEM表領域の補助表領域です。SYSAUX表領域は、SYSTEM表領域に常駐しないデータベース・メタデータの集中格納場所となります。これにより、シード・データベースとユーザー定義データベースの両方で、デフォルトで作成される表領域の数が減少します。

Oracle Enterprise ManagerやOracle Streamsなどいくつかのデータベース・コンポーネントでは、デフォルトの記憶域の場所としてSYSAUX表領域が使用されます。そのため、データベースの作成時またはアップグレード時にSYSAUX表領域が自動的に作成されます。

通常のデータベース操作中には、SYSAUX表領域の削除や名前変更は許可されません。SYSAUX表領域が使用できなくなった場合でも、中核となるデータベース機能は利用できます。SYSAUX表領域を使用するデータベース機能は、エラーが発生したり、機能が制限されることがあります。

関連項目:
SYSAUX表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

UNDO表領域

UNDO表領域は、システム管理UNDOデータ用に予約されたローカル管理表領域です(「UNDOセグメント」を参照)。他の永続表領域と同様、UNDO表領域にもデータファイルが含まれています。これらのファイル内のUNDOブロックは、エクステントにグループ化されています。

自動UNDO管理モード

UNDO表領域を使用する場合は、データベースがデフォルトの自動UNDO管理モードにあることが必要です。このモードでは、手動でUNDOセグメントを管理する複雑な作業が不要です。UNDOデータを可能なかぎり最適に保存して、UNDOデータを必要とする長時間実行される問合せに対応できるように、データベース自体が自動的にチューニングされます。

UNDO表領域は、Oracle Databaseを新たにインストールすると、自動的に作成されます。Oracle Databaseの以前のバージョンでは、UNDO表領域が含まれておらず、かわりに手動UNDO管理モードと呼ばれる従来のロールバック・セグメントが使用される場合があります。Oracle Database 11gにアップグレードすると、自動UNDO管理モードを有効にして、UNDO表領域を作成できます。Oracle Databaseには、UNDO環境についてのアドバイスを提供し、UNDO環境の自動化に役立つUNDOアドバイザが含まれています。

データベースに複数のUNDO表領域を含めることができますが、使用中となるのは常に1つのUNDO表領域のみです。インスタンスによってデータベースのオープンが試行されると、Oracle Databaseでは、使用可能な最初のUNDO表領域が自動的に選択されます。使用可能なUNDO表領域がない場合、インスタンスはUNDO表領域なしで起動され、UNDOデータはSYSTEM表領域に格納されます。ただし、SYSTEM表領域にUNDOデータを格納しないことをお薦めします。

関連項目:

- 自動UNDO管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 自動UNDO管理モードへの移行方法の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

- UNDOアドバイザおよびその使用方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

自動UNDO保存

UNDO保存期間とは、Oracle Databaseで古いUNDOセグメントを上書きしないで保存する最低期間のことです。長時間実行される問合せでは、読取り一貫性を実現するためにより古いブロック・イメージが必要になる場合があるため、UNDOデータの保存は重要です。また、一部のOracle Flashback機能は、UNDOデータの可用性に依存しています。

一般的に、古いUNDOデータは可能なかぎり長期間保存することをお薦めします。トランザクションのコミット後、ロールバックやトランザクション・リカバリの目的にはUNDOデータは不要になります。UNDO表領域に新しいトランザクション用の領域がある場合には、古いUNDOデータを保持できます。領域が少なくなると、コミットされたトランザクションのデータによる古いUNDOデータの上書きが開始されます。

Oracle Databaseでは、現行のUNDO表領域で、可能なかぎり最適にUNDOデータが自動的に保存されます。データベースにより、使用統計が収集され、これらの統計およびUNDO表領域サイズに基づいて保存期間がチューニングされます。UNDO表領域がAUTOEXTENDオプションを使用して構成されており、最大サイズが指定されていない場合は、UNDO保存期間は異なる方法でチューニングされます。この場合には、データベースにより、実行時間が最も長い問合せより少し長くなるように、UNDO保存期間がチューニングされます(領域が許す場合)。

関連項目:
UNDO保存の自動チューニングの詳細は、『Oracle Database管理者ガイド』を参照してください。

一時表領域

一時表領域には、セッションの存続期間中のみ保持される一時データが含まれています。永続スキーマ・オブジェクトを一時表領域に格納することはできません。データベースでは、一時表領域データは一時ファイルに格納されます。

一時表領域によって、メモリー内に収まらない複数のソート操作の同時実行性が向上します。また、一時表領域によって、ソート中の領域管理操作の効率も向上します。

SYSTEM表領域がローカル管理表領域の場合は、デフォルトでデータベース作成時にデフォルトの一時表領域が作成されます。ローカル管理のSYSTEM表領域は、デフォルトの一時記憶域として使用できません。

注意:
デフォルトの一時表領域を永続表領域にすることはできません。

CREATE DATABASE文でDEFAULT TEMPORARY TABLESPACE拡張機能を使用すると、データベースの作成時に、ユーザーを限定したデフォルトの一時表領域の作成を指定できます。SYSTEM表領域がディクショナリ管理されており、データベースの作成時にデフォルトの一時表領域を定義しないない場合は、SYSTEMがデフォルトの一時記憶域となります。ただし、アラート・ログに、一時表領域の使用を推奨する警告が書き込まれます。

関連項目:

- 「永続データファイルと一時データファイル」

- デフォルトの一時表領域の作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE DATABASEおよびALTER DATABASEのDEFAULT TEMPORARY TABLESPACE句の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表領域モード

表領域モードによって、表領域のアクセス可能性が決まります。

読取り/書込み表領域と読取り専用表領域

すべての表領域は、書込み可能であるかどうかを指定する書込みモードのうちいずれかのモードになっています。次の相互に排他的なモードがあります。

- 読取り/書込みモード
ユーザーは、表領域の読取りおよび書込みが可能です。すべての表領域は、最初は読取り/書込みモードで作成されます。SYSTEM表領域とSYSAUX表領域、および一時表領域は永続的に読取り/書込みモードであるため、読取り専用にはできません。

- 読取り専用モード
表領域内のデータファイルへの書込み操作を行うことができません。読取り専用表領域は、DVDドライブやWORMドライブなどの読取り専用メディア上にのみ存在します。

読取り専用表領域では、データベースの静的な部分を大量にバックアップしたり、リカバリする必要がなくなります。読取り専用表領域は変更されないため、繰り返しバックアップする必要はありません。メディア障害後にデータベースをリカバリする場合、読取り専用表領域はリカバリする必要がありません。

関連項目:

- 表領域を読取り専用または読取り/書込みモードに変更する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- ALTER TABLESPACEの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

- リカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

オンライン表領域とオフライン表領域

表領域は、データベースがオープンされているときはいつでも、オンライン(アクセス可能)またはオフライン(アクセス不能)にできます。表領域は通常はオンラインになっており、ユーザーはその表領域内のデータを使用できます。SYSTEM表領域と一時表領域は、オフラインにはできません。

表領域は、自動または手動でオフラインにできます。たとえば、メンテナンスまたはバックアップとリカバリのために表領域をオフラインにできます。データベース・ライター(DBW)プロセスによるデータファイルへの書込みが数回失敗した場合など、特定のエラーが発生した場合には、表領域は自動的にオフラインになります。オフライン表領域にある表にアクセスしようとしたユーザーは、エラーを受け取ります。

表領域がオフラインになると、データベースで次のような処理が実行されます。

- データベースでは、表領域がオフラインになると、その表領域内のオブジェクトをDML文で参照できなくなります。Oracle Database以外のユーティリティでは、オフライン表領域の読取りまたは編集はできません。

- その表領域内のデータを参照する文が完了しているアクティブなトランザクションは、トランザクション・レベルでは影響を受けません。

- これらの完了した文に対応するUNDOデータは、SYSTEM表領域内の遅延UNDOセグメントに保存されます。表領域が再びオンライン化されたとき、必要に応じてUNDOデータが表領域に適用されます。

関連項目:

- 「オンライン・データファイルとオフライン・データファイル」

- 「データベース・ライター・プロセス(DBWn)」

- 表領域の可用性を変更する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

表領域ファイル・サイズ

表領域には、bigfile表領域と小型ファイル表領域があります。これらの表領域は、データファイルまたは一時ファイルを明示的に参照しないSQL文の実行時には区別できません。これらの表領域の違いは、次のとおりです。

- smallfile表領域には、複数のデータファイルや一時ファイルを含むことができますが、bigfile表領域ほど大きなファイルは含むことができません。デフォルトの表領域タイプは、smallfile表領域です。

- bigfile表領域には、1つの非常に大きなデータファイルまたは一時ファイルを含むことができます。このタイプの表領域には、次のような利点があります。

- データベースの記憶域容量の増加
データベース内のデータファイルの最大数には制限があるため(通常は64KB個)、各データファイルのサイズを増加することによって、全体的な記憶域容量を増加できます。

- 数多くのデータファイルおよび一時ファイルを管理する負担の軽減
bigfile表領域により、新規ファイルを追加したり複数ファイルを取り扱う必要がなくなり、Oracle Managed Filesと自動ストレージ管理(Oracle ASM)によるファイル管理が簡素化されます。

- 個々のファイルではなく表領域に対する操作の実行
bigfile表領域では、表領域はディスク領域の管理、バックアップおよびリカバリなどの主要単位となります。

bigfile表領域がサポートされるのは、ASSMを使用するローカル管理表領域の場合のみです。ただし、ローカル管理のUNDO表領域と一時表領域は、セグメントが手動管理される場合にもbigfile表領域として使用できます。

関連項目:

- 「バックアップおよびリカバリ」

- bigfile表領域の管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

第V部

Oracleインスタンス・アーキテクチャ

この部では、Oracleデータベース・インスタンスの基本的な構造上のアーキテクチャについて説明します。この部の構成は、次のとおりです。

- 第13章「Oracleデータベース・インスタンス」

- 第14章「メモリー・アーキテクチャ」

- 第15章「プロセス・アーキテクチャ」

- 第16章「アプリケーションおよびネットワークのアーキテクチャ」

13 Oracleデータベース・インスタンス

この章では、Oracleデータベース・インスタンスの性質、インスタンスに関連付けられたパラメータ・ファイルと診断ファイル、およびインスタンスの作成時やデータベースのオープン時とクローズ時に発生する処理について説明します。

この章の内容は、次のとおりです。

- Oracleデータベース・インスタンスの概要

- インスタンスの起動と停止の概要

- チェックポイントの概要

- インスタンス・リカバリの概要

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

- 診断ファイルの概要

Oracleデータベース・インスタンスの概要

データベース・インスタンスは、データベース・ファイルを管理する一連のメモリー構造です。データベースは、CREATE DATABASE文によって作成されたディスク上の一連の物理ファイルです。インスタンスは、関連データを管理し、データベースのユーザーに対応します。

稼働中のすべてのOracleデータベースは、1つ以上のOracleデータベース・インスタンスに関連付けられます。インスタンスはメモリー内に存在し、データベースはディスク上に存在するため、インスタンスがデータベースなしで存在することも、データベースがインスタンスなしで存在することも可能です。

データベース・インスタンスの構造

インスタンスが起動されると、Oracle Databaseによってシステム・グローバル領域(SGA)と呼ばれるメモリー領域が割り当てられ、1つ以上のバックグラウンド・プロセスが起動されます。SGAは、次のような様々な目的で機能します。

- 多くのプロセスおよびスレッドから同時にアクセスされる内部データ構造の維持

- ディスクから読み取られるデータ・ブロックのキャッシュ

- オンラインREDOログ・ファイルに書き込まれる前のREDOデータのバッファリング

- SQL実行計画の格納

SGAは、サーバー・プロセスおよびバックグラウンド・プロセスを含むOracleプロセスで共有され、1台のコンピュータ上で実行されます。OracleプロセスがSGAと関連付けられる方法は、オペレーティング・システムによって異なります。

データベース・インスタンスにはバックグラウンド・プロセスが含まれています。サーバー・プロセスおよびサーバー・プロセスに割り当てられたプロセス・メモリーもインスタンスに存在します。サーバー・プロセスが終了しても、インスタンスは機能し続けます。

図13-1に、Oracleデータベース・インスタンスの主要なコンポーネントを示します。

図13-1 データベース・インスタンス

関連項目:

- 「システム・グローバル領域の概要」

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

データベース・インスタンス構成

次の矛盾しない構成のいずれかでOracle Databaseを実行できます。

- 単一インスタンス構成
データベースとインスタンスの間には1対1関係が存在します。

- Oracle Real Application Clusters(Oracle RAC)構成
データベースとインスタンスの間には1対多関係が存在します。

図13-2に、可能なデータベース・インスタンス構成を示します。

図13-2 データベース・インスタンス構成

単一インスタンス構成とOracle RAC構成のどちらでも、1つのデータベース・インスタンスは一度に1つのデータベースにのみ関連付けられます。データベース・インスタンスを起動して1つのデータベースをマウント(インスタンスに関連付け)できますが、2つのデータベースを同じインスタンスに同時にマウントすることはできません。

注意:
この章では、特に記載のないかぎり単一インスタンス・データベース構成について説明します。

複数のインスタンスを同時に同じコンピュータ上で実行し、それぞれ専用のデータベースにアクセスさせることができます。たとえば、1台のコンピュータで2つの異なるデータベースprod1とprod2をホストできます。1つのデータベース・インスタンスでprod1を管理し、別のインスタンスでprod2を管理します。

関連項目:
Oracle RACの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

インスタンスの存続期間

インスタンスは、STARTUPコマンドを使用して作成されたときに開始し、終了されたときに終了します。この期間中、インスタンスはそのインスタンス自体を1つのデータベースにのみ関連付けることができます。さらに、そのインスタンスでは、データベースのマウント、クローズおよびオープンをそれぞれ1回のみ実行できます。データベースがクローズまたは停止された後、このデータベースをマウントしてオープンするには、別のインスタンスを起動する必要があります。

表13-1に、以前にクローズされたデータベースの再オープンを試行するデータベース・インスタンスを示します。

表13-1 インスタンスの存続期間

文

説明

SQL> STARTUP
ORACLE instance started.

Total System Global Area  468729856 bytes
Fixed Size                  1333556 bytes
Variable Size             440403660 bytes
Database Buffers           16777216 bytes
Redo Buffers               10215424 bytes
Database mounted.
Database opened.

STARTUPコマンドによってインスタンスが作成されます。これにより、データベースがマウントおよびオープンされます。

SQL> SELECT
TO_CHAR(STARTUP_TIME,'MON-DD-RR HH24:MI:SS')
AS "Inst Start Time" FROM V$INSTANCE;

Inst Start Time
------------------
JUN-18-11 13:14:48

この問合せによって、現在のインスタンスが起動された時刻が表示されます。

SQL> SHUTDOWN IMMEDIATE

インスタンスはデータベースをクローズして停止し、そのインスタンスの存続期間は終了します。

SQL> STARTUP
Oracle instance started.
. . .

STARTUPコマンドによって新しいインスタンスが作成され、データベースがマウントおよびオープンされます。

SQL> SELECT
TO_CHAR(STARTUP_TIME,'MON-DD-RR HH24:MI:SS')
AS "Inst Start Time" FROM V$INSTANCE;

Inst Start Time
------------------
JUN-18-11 13:16:40

この問合せによって、現在のインスタンスが起動された時刻が表示されます。起動時刻が異なるため、このインスタンスがデータベースを停止したインスタンスと異なることがわかります。

Oracleシステム識別子(SID)

システム識別子(SID)とは、特定のホスト上でOracleデータベース・インスタンスを示す一意の名前です。UNIXおよびLinuxでは、Oracle DatabaseはSIDとOracleホームの値を使用して共有メモリーに対するキーを作成します。また、SIDは、デフォルトでパラメータ・ファイルを検索するためにも使用され、パラメータ・ファイルは、データベース制御ファイルなどの関連ファイルの検索に使用されます。

ほとんどのプラットフォームでは、ORACLE_SID環境変数によってSIDが設定され、ORACLE_HOME変数によってOracleホームが設定されます。インスタンスへの接続時に、クライアントはOracle Net接続のSIDを指定するか、ネット・サービス名を使用できます。サービス名は、Oracle DatabaseによってORACLE_HOMEとORACLE_SIDに変換されます。

関連項目:

- 「サービス名」

- Oracle SIDの指定方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

インスタンスの起動と停止の概要

データベース・インスタンスにより、ユーザーはデータベースにアクセスできます。この項では、インスタンスとデータベースがどのような状態になる可能性があるかについて説明します。

インスタンスとデータベースの起動の概要

通常のユースケースでは、手動でインスタンスを起動してから、データベースをマウントおよびオープンし、ユーザーが使用できるようにします。SQL*Plus STARTUPコマンド、Oracle Enterprise Manager(Enterprise Manager)またはSRVCTLユーティリティを使用して、これらの手順を実行できます。図13-3に、データベースの停止状態からオープン状態までの経過を示します。

図13-3 インスタンスとデータベースの起動順序

データベースが停止状態からオープン状態になるとき、次のフェーズを経由します。

1. データベースにマウントせずにインスタンスを起動
インスタンスは起動されますが、まだデータベースと関連付けられていません。

この段階については、「インスタンスの起動方法」を参照してください。

2. データベースのマウント
インスタンスが起動され、データベースの制御ファイルを読み取ってデータベースと関連付けられます(「制御ファイルの概要」を参照)。データベースは、ユーザーに対してクローズされています。

この段階については、「データベースのマウント方法」を参照してください。

3. データベースのオープン
インスタンスが起動され、オープン状態のデータベースと関連付けられます。データファイルに含まれるデータは、許可されたユーザーからアクセス可能になります。

この段階については、「データベースのオープン方法」で説明しています。

関連項目:

- 「Oracle Enterprise Manager」

- インスタンスの起動方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

- SRVCTLの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

管理者権限での接続

データベースの起動と停止は、管理者権限を使用してOracle Databaseに接続するユーザーのみが実行できる強力な管理オプションです。一般のユーザーは、Oracleデータベースの現在の状態を制御できません。

ユーザーの管理者権限を確立するには、オペレーティング・システムに応じて、次のいずれかの条件が必要です。

- ユーザーのオペレーティング・システム権限により、そのユーザーが管理者権限を使用して接続できること。

- ユーザーがSYSDBAまたはSYSOPERシステム権限を付与されており、データベースがパスワード・ファイルを使用し、ネットワークを介してデータベース管理者を認証していること。

SYSDBAとSYSOPERは、データベースがオープンしていない場合でもデータベース・インスタンスにアクセスできる、特別なシステム権限です。これらの権限は、データベースでは制御されません。SYSDBAシステム権限で接続すると、ユーザーはSYSが所有するスキーマ内に置かれます。SYSOPERとして接続すると、そのユーザーはパブリック・スキーマ内に置かれます。SYSOPER権限は、SYSDBA権限のサブセットです。

関連項目:

- 「SYSスキーマとSYSTEMスキーマ」

- データベース管理者を認証するときのパスワード・ファイルと認証方式の詳細は、「データベース・セキュリティの概要」を参照してください。

- SYSDBAおよびSYSOPERの詳細は、『Oracle Database管理者ガイド』を参照してください。

インスタンスの起動方法

Oracle Databaseは、インスタンスの起動時に、次の基本ステップを実行します。

1. プラットフォーム固有のデフォルトの格納場所でサーバー・パラメータ・ファイルを検索します。見つからなかった場合は、テキスト形式の初期化パラメータ・ファイルを検索します(STARTUPにSPFILEまたはPFILEパラメータを指定すると、デフォルトの動作が上書きされます)。

2. パラメータ・ファイルを読み取り、初期化パラメータの値を決定します。

3. 初期化パラメータの設定に基づいてSGAを割り当てます。

4. Oracleバックグラウンド・プロセスを起動します。

5. アラート・ログとトレース・ファイルをオープンし、明示的に設定されたすべてのパラメータ設定をパラメータの有効な構文でアラート・ログに書き込みます。

この時点では、このインスタンスにデータベースは関連付けられていません。NOMOUNT状態が必要とされるシナリオには、データベースの作成および特定のバックアップ操作とリカバリ操作があります。

関連項目:
サーバー・パラメータ・ファイルを使用した初期化パラメータの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

データベースのマウント方法

インスタンスは、データベースをマウントして、データベースをそのインスタンスに対応付けます。データベースをマウントすると、そのインスタンスはCONTROL_FILES初期化パラメータに指定されたデータベース制御ファイルの名前を取得し、これらのファイルをオープンします。Oracle Databaseでは、制御ファイルを読み取ることによって、データベースのオープン時にアクセスを試行するデータファイルとオンラインREDOログ・ファイルの名前を検出します。

マウントされたデータベースでは、データベースはクローズされているため、データベース管理者のみがそのデータベースにアクセスできます。管理者は、特定のメンテナンス操作を完了するまでの間、データベースをクローズしたままにしておくことができます。ただし、データベースに対して通常の操作を行うことはできません。

Oracle Databaseで、複数のインスタンスによる同じデータベースの同時マウントが許可されている場合、CLUSTER_DATABASE初期化パラメータの設定で、複数のインスタンスによるデータベースの使用を可能にできます。データベースの動作は、設定によって異なります。

- データベースをマウントする最初のインスタンスのCLUSTER_DATABASEパラメータがfalse(デフォルト)の場合は、最初のインスタンスのみがデータベースをマウントできます。

- このCLUSTER_DATABASEパラメータがtrueの場合は、他のインスタンスもCLUSTER_DATABASEパラメータの設定がtrueに設定されている状態でデータベースをマウントできます。データベースをマウントできるインスタンスの数は、データベースの作成時に指定された最大数によって決まります。

関連項目:

- データベースのマウント方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 1つのデータベースでの複数のインスタンスの使用方法の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

データベースのオープン方法

マウントされたデータベースをオープンすると、そのデータベースで通常のデータベース操作を実行できるようになります。有効なユーザーは、オープン状態のデータベースに接続して、データベースの情報にアクセスできます。通常、データベース管理者は、データベースをオープンして一般に使用できる状態にします。

データベースをオープンするときに、Oracle Databaseでは次のアクションを自動的に実行します。

- UNDO表領域以外の表領域でオンライン・データファイルをオープンします。
データベースを前回停止したときに表領域がオフラインであった場合は(「オンライン表領域とオフライン表領域」を参照)、データベースを再オープンしたとき、その表領域と対応するデータファイルはオフラインのままです。

- UNDO表領域を取得します。
複数のUNDO表領域が存在する場合には、使用するUNDO表領域をUNDO_TABLESPACE初期化パラメータで指定できます。このパラメータが設定されていない場合、使用可能な最初のUNDO表領域が選択されます。

- オンラインREDOログ・ファイルをオープンします。

関連項目:
「データ修復」

読取り専用モード

デフォルトでは、データベースは読取り/書込みモードでオープンします。このモードでは、ユーザーがデータを変更し、オンラインREDOログにREDOを生成できます。また、読取り専用モードでオープンすると、ユーザー・トランザクションによってデータが変更されるのを防ぐことができます。

注意:
デフォルトでは、フィジカル・スタンバイ・データベースは読取り専用モードでオープンします。『Oracle Data Guard概要および管理』を参照してください。

読取り専用モードでは、データベース・アクセスは読取り専用トランザクションに限定され、データファイルやオンラインREDOログ・ファイルに書き込むことはできません。ただし、データベースではリカバリや、REDOを生成しないでデータベースの状態を変更する操作を実行できます。たとえば、読取り専用モードでは、次の操作を実行できます。

- データファイルのオフラインとオンラインを切り替えることができます。ただし、永続表領域はオフライン化できません。

- オフラインのデータファイルと表領域をリカバリできます。

- 制御ファイルは、データベースの状態の更新に引き続き使用できます。

- CREATE TEMPORARY TABLESPACE文を使用して作成された一時表領域は、読取り/書込み可能です。

- オペレーティング・システムの監査証跡、トレース・ファイルおよびアラート・ログへの書込みは引き続き実行できます。

関連項目:
データベースを読取り専用モードでオープンする方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

データベース・ファイルのチェック

インスタンスがデータベースをオープンするとき、データファイルまたはREDOログ・ファイルが存在しない場合、またはこれらのファイルは存在するが、一貫性テストに失敗した場合は、データベースからエラーが戻されます。メディア・リカバリが必要な場合があります。

関連項目:
「バックアップおよびリカバリ」

データベースとインスタンスの停止の概要

通常のユースケースでは、手動でデータベースを停止し、メンテナンスや他の管理作業の実行中にユーザーがデータベースを使用できないようにします。SQL*Plus SHUTDOWNコマンドまたはEnterprise Managerを使用して、これらの手順を実行できます。図13-4に、オープン状態から一貫性のある停止状態までの経過を示します。

図13-4 インスタンスとデータベースの停止順序

オープン状態のデータベースが一貫性のある状態で停止されるときは、Oracle Databaseが次の手順を自動的に実行します。

1. データベースのクローズ
データベースはマウントされていますが、オンライン・データファイルとREDOログ・ファイルはクローズされます。

この段階については、「データベースのクローズ方法」を参照してください。

2. データベースのアンマウント
インスタンスは起動状態にありますが、データベースの制御ファイルとの関連付けは解消されます。

この段階については、「データベースのアンマウント方法」を参照してください。

3. データベース・インスタンスの停止
データベース・インスタンスは起動状態にありません。

この段階については、「インスタンスの停止方法」を参照してください。

インスタンス障害やSHUTDOWN ABORTの場合、Oracle Databaseは前述の手順のすべてを実行せず、インスタンスを即時に終了します。

関連項目:
データベースの停止方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

停止モード

SYSDBAまたはSYSOPER権限を持つデータベース管理者は、SQL*PlusのSHUTDOWNコマンドまたはEnterprise Managerを使用してデータベースを停止できます。SHUTDOWNコマンドには、停止動作を指定するオプションがあります。表13-2に、様々な停止モードの動作の概要を示します。

表13-2 停止モード

データベースの動作

ABORT

IMMEDIATE

TRANSACTIONAL

NORMAL

新しいユーザー接続を許可

いいえ

いいえ

いいえ

いいえ

現行セッションが終了するまで待機

いいえ

いいえ

いいえ

はい

現行トランザクションが終了するまで待機

いいえ

いいえ

はい

はい

チェックポイントを実行し、オープン状態のファイルをクローズ

いいえ

はい

はい

はい

使用可能なSHUTDOWN文は、次のとおりです。

- SHUTDOWN ABORT
このモードは、他の停止方法が機能しない場合などの非常時のために用意されています。これは最速の停止モードです。ただし、停止後にこのデータベースをオープンする際に、データファイルの整合性を保つためにインスタンス・リカバリを実行する必要があるため、非常に長い時間がかかる場合があります。

注意:
SHUTDOWN ABORTでは、オープン状態のデータファイルのチェックポイントが実行されないため、データベースを再オープンする前にインスタンス・リカバリが必要です。その他の停止モードでは、データベースを再オープンする前にインスタンス・リカバリを実行する必要はありません。

- SHUTDOWN IMMEDIATE
通常は、SHUTDOWN ABORTの次に速い停止モードです。Oracle Databaseは、実行中のSQL文をすべて終了し、ユーザーとの接続を切断します。アクティブなトランザクションは終了され、コミットされていない変更はロールバックされます。

- SHUTDOWN TRANSACTIONAL
このモードでは、ユーザーが新しいトランザクションを開始することはできませんが、すべての現行トランザクションが完了するまで待機してから停止します。現行トランザクションの性質によっては、停止までにかなりの時間がかかる場合があります。

- SHUTDOWN NORMAL
これはデフォルトの停止モードです。データベースは、接続されたすべてのユーザーの接続が解除されるまで待機してから停止します。

関連項目:

- 様々な停止モードの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

- SHUTDOWNコマンドの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

データベースのクローズ方法

データベースのクローズ操作は、データベース停止時に暗黙的に実行されます。この操作の性質は、データベースが正常停止されたか、異常停止されたかによって異なります。

正常停止時のデータベースのクローズ方法

ABORT以外のオプションが指定されたSHUTDOWNの一環としてデータベースがクローズされると、Oracle DatabaseはSGA内のデータをデータファイルとオンラインREDOログ・ファイルに書き込みます。次に、データベースはオンライン・データファイルとオンラインREDOログ・ファイルをクローズします。オフライン表領域のオフライン・データファイルは、すでにクローズされています。データベースを再オープンしたとき、オフラインになっていた表領域はオフラインのままです。

この時点でデータベースはクローズされているため、通常の操作は実行できません。データベースがクローズされても、制御ファイルはオープンされたままになります。

異常停止時のデータベースのクローズ方法

SHUTDOWN ABORTまたは異常終了が発生すると、オープン状態のデータベースのインスタンスはクローズされ、データベースはただちに停止されます。Oracle Databaseは、SGAのバッファ内のデータをデータファイルとREDOログ・ファイルに書き込みません。次にデータベースを再オープンするときに必要なインスタンス・リカバリは、Oracle Databaseで自動的に実行されます。

データベースのアンマウント方法

データベースがクローズされると、Oracle Databaseはデータベースをアンマウントしてインスタンスから切り離します。データベースをアンマウン卜すると、Oracle Databaseでは、データベースの制御ファイルがクローズされます。この時点ではインスタンスはメモリーに残っています。

インスタンスの停止方法

データベース停止の最後の操作は、インスタンスの停止です。データベース・インスタンスを停止すると、SGAがメモリーから削除され、バックグラウンド・プロセスが停止します。

異常な状況では、インスタンスが正常に停止しないことがあります。たとえば、メモリー構造がメモリーから削除されない場合や、バックグラウンド・プロセスの1つが終了されない場合があります。前のインスタンスの一部が残っていると、後続のインスタンスの起動が失敗します。このような状況では、残っている前のインスタンスを削除してから新しいインスタンスを起動するか、SQL*PlusまたはEnterprise ManagerでSHUTDOWN ABORT文を発行することで、新しいインスタンスの起動を強制実行できます。

関連項目:
データベースの停止の詳細は、『Oracle Database管理者ガイド』を参照してください。

チェックポイントの概要

一般的に、チェックポイントは、一貫性のあるデータベースの停止、インスタンス・リカバリおよびOracle Databaseの操作に不可欠なメカニズムです。チェックポイントという用語には、次のような意味が含まれています。

- チェックポイント位置を示すデータ構造。これは、インスタンス・リカバリを開始する必要があるREDOストリーム内のSCNです。
チェックポイント位置は、データベース・バッファ・キャッシュ内の最も古い使用済バッファによって決まります。チェックポイント位置は、REDOストリームへのポインタとして機能し、制御ファイル内と各データファイル・ヘッダー内に格納されます。

- データベース・バッファ・キャッシュ内の変更済データベース・バッファのディスクへの書込み

関連項目:
「システム変更番号(SCN)」

チェックポイントの目的

Oracle Databaseでは、次の目的を達成するためにチェックポイントを使用します。

- インスタンス障害またはメディア障害時のリカバリに要する時間を短縮します。

- バッファ・キャッシュ内の使用済バッファが定期的にディスクに書き込まれることを保証します。

- 一貫性のある停止が実行されるとき、すべてのコミット済データがディスクに書き込まれることを保証します。

Oracle Databaseでチェックポイントが開始される時期

チェックポイント・プロセス(CKPT)は、データファイル・ヘッダーと制御ファイルにチェックポイントを書き込みます。チェックポイントは、様々な状況で発生します。たとえば、Oracle Databaseでは、次のタイプのチェックポイントを使用します。

- スレッドのチェックポイント
データベースは、特定のターゲットより前の特定のスレッド内でREDOによって変更されたすべてのバッファをディスクに書き込みます。データベース内の全インスタンスに対するスレッドのチェックポイントのセットが、データベースのチェックポイントです。スレッドのチェックポイントは、次の状況で発生します。

- 一貫性のあるデータベースの停止

- ALTER SYSTEM CHECKPOINT文

- オンラインREDOログの切替え

- ALTER DATABASE BEGIN BACKUP文

- 表領域とデータファイルのチェックポイント
データベースは、特定のターゲットより前のREDOによって変更されたすべてのバッファをディスクに書き込みます。表領域のチェックポイントは、表領域のデータファイルごとに1つあるデータファイルのチェックポイントのセットです。これらのチェックポイントは、表領域の読取り専用化やNORMALモードでのオフライン化、データファイルの縮小、またはALTER TABLESPACE BEGIN BACKUPの実行時など、様々な状況で発生します。

- 増分チェックポイント
増分チェックポイントはスレッドのチェックポイントの一種であり、オンラインREDOログを切り替えるとき、大量のブロックの書込みを防止することが目的の1つとなっています。DBWnは、実行する処理の有無を少なくとも3秒ごとにチェックします。DBWnが使用済バッファを書き込むと、チェックポイント位置が前進し、これにより、CKPTでは、このチェックポイント位置をデータファイル・ヘッダーではなく制御ファイルに書き込みます。

その他のタイプには、インスタンスとメディア・リカバリのチェックポイント、およびスキーマ・オブジェクトが削除または切り捨てられたときのチェックポイントがあります。

関連項目:

- 「チェックポイント・プロセス(CKPT)」

- Oracle RACによるCKPTの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

インスタンス・リカバリの概要

インスタンス・リカバリは、オンラインREDOログ内のレコードをデータファイルに適用し、最新のチェックポイントの後に行われた変更を再構築するプロセスです。管理者が前回一貫性のない状態で停止されたデータベースの再オープンを試行すると、インスタンス・リカバリが自動的に実行されます。

インスタンス・リカバリの目的

インスタンス・リカバリは、インスタンス障害後にデータベースが一貫性のある状態になることを保証します。Oracle Databaseでのデータベースの変更管理方法により、データベースのファイルが一貫性のない状態のままになることがあります。

REDOスレッドは、インスタンスによって生成された変更のすべてのレコードです。単一インスタンス・データベースには1つのREDOスレッドがあり、Oracle RACデータベースには各データベース・インスタンスに対応する複数のREDOスレッドがあります。

トランザクションがコミットされると、ログ・ライター(LGWR)は、メモリー内の残りのREDOエントリとトランザクションのSCNの両方をオンラインREDOログに書き込みます。ただし、データベース・ライター(DBW)プロセスでは、変更されたデータ・ブロックを最も効率的な時点でデータファイルに書き込みます。このため、コミットされた変更がまだデータファイルに存在しないとき、コミットされていない変更が一時的にデータファイルに存在することがあります。

SHUTDOWN ABORT文または異常終了のいずれかにより、オープン状態のデータベースのインスタンスに障害が発生すると、次の状態になることがあります。

- トランザクションによってコミットされたデータ・ブロックはデータファイルに書き込まれず、オンラインREDOログにのみ表示されます。これらの変更は、データベースに再適用される必要があります。

- インスタンスに障害が発生した時点でコミットされていない変更がデータファイルに含まれています。これらの変更は、トランザクションの一貫性を保証するためにロールバックする必要があります。

インスタンス・リカバリは、オンラインREDOログ・ファイルと現行のオンライン・データファイルのみを使用してデータファイルを同期し、これらが一貫性のある状態になることを保証します。

関連項目:

- 「データベース・ライター・プロセス(DBWn)」および「データベース・バッファ・キャッシュ」

- 「データの同時実行性と整合性の概要」

Oracle Databaseでインスタンス・リカバリが実行される時期

インスタンス・リカバリが必要かどうかは、REDOスレッドの状態によります。制御ファイル内では、データベース・インスタンスが読取り/書込みモードでオープンすると、REDOスレッドにオープンのマークが付けられ、インスタンスが一貫性のある状態で停止されると、クローズ済のマークが付けられます。REDOスレッドに制御ファイルでオープンのマークが付けられると、稼働中のインスタンスはこれらのスレッドに対応するスレッドのエンキューを保持しないため、データベースでインスタンス・リカバリが必要となります。

Oracle Databaseでは、次の場合にインスタンス・リカバリが自動的に実行されます。

- 単一インスタンス・データベースまたはOracle RACデータベースの全インスタンスの障害後に、最初にデータベースをオープンするとき。このタイプのインスタンス・リカバリはクラッシュ・リカバリとも呼ばれます。Oracle Databaseでは、終了したインスタンスのオンラインREDOスレッドも同時にリカバリされます。

- Oracle RACデータベースに含まれる全インスタンスではなく一部のインスタンスに障害が発生したとき。インスタンス・リカバリは、構成内で正常に稼働しているインスタンスにより自動的に実行されます。

SMONバックグラウンド・プロセスではインスタンス・リカバリが実行され、オンラインREDOが自動的に適用されます。ユーザーが介入する必要はありません。

関連項目:

- 「システム・モニター・プロセス(SMON)」

- Oracle RACデータベースでのインスタンス・リカバリの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

インスタンス・リカバリでのチェックポイントの重要性

インスタンス・リカバリでは、データファイルに適用する必要がある変更を判断するためにチェックポイントが使用されます。チェックポイント位置は、チェックポイントSCNより小さいSCNを持つすべてのコミット済の変更がデータファイルに保存されることを保証するものです。

図13-5に、オンラインREDOログ内のREDOスレッドを示します。

図13-5 オンラインREDOログ内のチェックポイント位置

インスタンス・リカバリ時には、データベースによってチェックポイント位置からREDOスレッドの最後までに発生した変更が適用される必要があります。図13-5に示されているように、変更の一部はすでにデータファイルに書き込まれています。ただし、ディスクに書き込まれるのは、チェックポイント位置より小さいSCNを持つ変更のみであることが保証されます。

関連項目:
リカバリ時間の制限方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

インスタンス・リカバリのフェーズ

インスタンス・リカバリの最初のフェーズは、キャッシュ・リカバリまたはロールフォワードと呼ばれ、このフェーズでは、オンラインREDOログに記録されているすべての変更がデータファイルに再適用されます。オンラインREDOログにはロールバック・データが記録されているため、ロールフォワードでは対応するUNDOセグメントも再生成されます。

ロールフォワードでは、必要に応じて多数のオンラインREDOログ・ファイルをたどり、データベースを後の時点まで進行させます。ロールフォワード後のデータ・ブロックには、オンラインREDOログ・ファイルに記録されたコミット済の変更がすべて含まれています。これらのファイルには、障害発生前にデータファイルに保存されていたか、オンラインREDOログに記録されてキャッシュ・リカバリ時に取り込まれた、コミットされていない変更も含まれることがあります。

ロールフォワード後は、コミットされなかった変更を取り消す必要があります。Oracle Databaseでは、チェックポイント位置が使用され、これにより、チェックポイントSCNより小さいSCNを持つすべてのコミット済の変更がディスクに保存されることが保証されます。Oracle Databaseでは、UNDOブロックの適用により、障害発生前に書き込まれたか、キャッシュ・リカバリ中に取り込まれたデータ・ブロック内の、コミットされていない変更がロールバックされます。このフェーズは、ロールバックまたはトランザクション・リカバリと呼ばれます。

図13-6に、ロールフォワードとロールバックを示します。この2つは、データベース・インスタンスの障害からのリカバリに必要なステップです。

図13-6 インスタンス・リカバリの基本ステップ: ロールフォワードとロールバック

Oracle Databaseは、必要に応じて同時に複数のトランザクションをロールバックできます。 障害時点でアクティブになっていたトランザクションすべてに、終了マークが付けられます。終了したトランザクションがSMONプロセスによりロールバックされるのを待たずに、新しいトランザクションによりトランザクション自体で個別のブロックをロールバックし、必要なデータを取得できます。

関連項目:

- UNDOデータの詳細は、「UNDOセグメント」を参照してください。

- インスタンス・リカバリのメカニズムとチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

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

データベース・インスタンスを起動するには、Oracle Databaseはサーバー・パラメータ・ファイル(推奨)またはテキスト形式の初期化パラメータ・ファイル(従来型の実装)を読み取る必要があります。これらのファイルには、構成パラメータのリストが格納されます。

データベースを手動で作成するには、パラメータ・ファイルを使用してインスタンスを起動してから、CREATE DATABASEコマンドを発行する必要があります。このため、データベース自体が存在していない場合でも、インスタンスとパラメータ・ファイルが存在することがあります。

初期化パラメータ

初期化パラメータは、インスタンスの基本操作に影響する構成パラメータです。インスタンスは、起動時にファイルから初期化パラメータを読み取ります。

Oracle Databaseには、様々な環境に応じて操作を最適化する多数の初期化パラメータが用意されています。ほとんどの場合はデフォルト値のままで十分で、明示的な設定を必要とするパラメータはごく少数です。

初期化パラメータの機能グループ

ほとんどの初期化パラメータは、次の機能グループのいずれかに属しています。

- ファイルやディレクトリなどのエンティティに名前を指定するパラメータ

- プロセス、データベース・リソースまたはデータベース自体の制限を設定するパラメータ

- SGAのサイズなどの容量に影響するパラメータ(可変パラメータと呼ばれる)

可変パラメータを使用するとデータベースのパフォーマンスを改善できるため、これらのパラメータは、特にデータベース管理者によって頻繁に使用されます。

基本的な初期化パラメータと拡張初期化パラメータ

初期化パラメータは、基本と拡張という2つのグループに分かれています。ほとんどの場合、妥当なパフォーマンスを得るには、約30種類の基本パラメータのみを設定およびチューニングする必要があります。基本パラメータでは、データベース名、制御ファイルの場所、データベース・ブロック・サイズ、UNDO表領域などの特性を設定します。

ただし最適なパフォーマンスを得るために、拡張パラメータの変更が必要になる場合があります。拡張パラメータを使用することによって、熟練したDBAは固有の要件にあわせてOracle Databaseの動作を調整できます。

Oracle Databaseは、データベース・ソフトウェアで提供される最初の初期化パラメータ・ファイル、またはDatabase Configuration Assistantにより作成される最初の初期化パラメータ・ファイルに値を提供します(「データベースのインストールおよび構成ツール」を参照)。構成およびデータベースのチューニング計画に応じて、これらのOracle提供の初期化パラメータを編集し、他のパラメータを追加できます。該当する初期化パラメータがパラメータ・ファイルに組み込まれていない場合には、Oracle Databaseによりデフォルトが指定されます。

関連項目:

- 初期化パラメータの指定方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

- 初期化パラメータの種類の詳細は、『Oracle Databaseリファレンス』を参照してください。

- V$PARAMETERの詳細は『Oracle Databaseリファレンス』 を、SHOW PARAMETER構文については『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

サーバー・パラメータ・ファイル

サーバー・パラメータ・ファイルは、Oracle Databaseにより管理される初期化パラメータのリポジトリです。サーバー・パラメータ・ファイルには、主に次の特徴があります。

- サーバー・パラメータ・ファイルは、データベースに対して1つのみ存在します。このファイルは、データベース・ホストに常駐する必要があります。

- サーバー・パラメータ・ファイルは、クライアント・アプリケーションではなく、Oracle Databaseのみが書込みと読取りを実行します。

- サーバー・パラメータ・ファイルはバイナリであり、テキスト・エディタでは編集できません。

- サーバー・パラメータ・ファイルに格納されている初期化パラメータは永続的です。データベース・インスタンスの実行中に行われたパラメータの変更は、インスタンスを停止して起動しても残ります。

サーバー・パラメータ・ファイルを使用すると、クライアント・アプリケーション用に複数のテキスト形式の初期化パラメータ・ファイルを保持する必要がなくなります。サーバー・パラメータ・ファイルは、最初は、CREATE SPFILE文を使用してテキスト形式の初期化パラメータ・ファイルから作成されます。また、Database Configuration Assistantにより直接作成することもできます。

関連項目:

- サーバー・パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE SPFILEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

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

テキスト形式の初期化パラメータ・ファイルは、初期化パラメータのリストが格納されるテキスト・ファイルです。このタイプのパラメータ・ファイルは、従来型の実装のパラメータ・ファイルであり、主に次の特徴があります。

- データベースを起動または停止するときに、テキスト形式の初期化パラメータ・ファイルは、データベースに接続するクライアント・アプリケーションと同じホストに常駐する必要があります。

- テキスト形式の初期化パラメータ・ファイルはテキストベースであり、バイナリではありません。

- Oracle Databaseは、テキスト形式の初期化パラメータ・ファイルの読取りはできますが、書込みはできません。パラメータ値を変更するには、テキスト・エディタを使用してファイルを手動で編集する必要があります。

- ALTER SYSTEMを使用した初期化パラメータ値の変更は、現行インスタンスにのみ有効になります。変更内容を確認するには、テキスト形式の初期化パラメータ・ファイルを手動で更新し、インスタンスを再起動する必要があります。

テキスト形式の初期化パラメータ・ファイルには、一連のキー=値のペア(行ごとに1ペア)が格納されています。たとえば、初期化パラメータ・ファイルの一部は、次のように表示されます。

db_name=sample
control_files=/disk1/oradata/sample_cf.dbf
db_block_size=8192
open_cursors=52
undo_management=auto
shared_pool_size=280M
pga_aggregate_target=29M
.
.
.

テキスト形式のパラメータ・ファイルの管理性に関する問題を具体的に説明するため、clientaとclientbというコンピュータを使用し、いずれのコンピュータ上でもSQL*Plusでデータベースを起動できるようにする必要があるとします。この場合、図13-7に示すように、個別のテキスト形式の初期化パラメータ・ファイルが2つ(コンピュータごとに1つ)存在する必要があります。サーバー・パラメータ・ファイルは、パラメータ・ファイルが増加する問題を解決します。

図13-7 複数の初期化パラメータ・ファイル

関連項目:

- テキスト形式の初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE PFILEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

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

初期化パラメータを調整してデータベースの動作を変更できます。パラメータの分類が静的であるか、動的であるかによって、パラメータの変更方法が決まります。表13-3に、これらの違いの概要を示します。

表13-3 静的な初期化パラメータと動的な初期化パラメータ

特徴

静的

動的

パラメータ・ファイル(テキストまたはサーバー)を変更する必要性

あり

なし

設定を有効にする前にデータベース・インスタンスを再起動する必要性

あり

なし

『Oracle Databaseリファレンス』の初期化パラメータのエントリでの変更可能という説明

なし

あり

データベースまたはインスタンスによってのみ変更可能かどうか

はい

いいえ

静的なパラメータには、DB_BLOCK_SIZE、DB_NAMEおよびCOMPATIBLEがあります。動的なパラメータは、現行のユーザー・セッションにのみ影響するセッション・レベルのパラメータと、データベースおよびすべてのセッションに影響するシステム・レベルのパラメータに分類されます。たとえば、MEMORY_TARGETはシステム・レベルのパラメータであり、NLS_DATE_FORMATはセッション・レベルのパラメータです(「ロケール固有の設定」を参照)。

パラメータ変更の有効範囲は、変更が有効になる時期によって異なります。インスタンスがサーバー・パラメータ・ファイルで起動されている場合は、ALTER SYSTEM SET文を使用して、次のようにシステム・レベルのパラメータの値を変更できます。

- SCOPE=MEMORY
変更はデータベース・インスタンスにのみ適用されます。データベースが停止して再起動された場合、変更は存続しません。

- SCOPE=SPFILE
変更はサーバー・パラメータ・ファイルに書き込まれますが、現行インスタンスには影響しません。このため、インスタンスが再起動されるまで変更は有効になりません。

注意:
『Oracle Databaseリファレンス』で変更不可と説明されているパラメータの値を変更する場合は、SPFILEを指定する必要があります。

- SCOPE=BOTH
変更は、メモリーとサーバー・パラメータ・ファイルの両方に書き込まれます。これは、データベースがサーバー・パラメータ・ファイルを使用している場合のデフォルトの有効範囲です。

データベースにより、初期化パラメータの新しい値と古い値がアラート・ログに出力されます。不正な値がサーバー・パラメータ・ファイルに書き込まれるのを防ぐため、予防策として、データベースにより基本的なパラメータの変更が検証されます。

関連項目:

- 初期化パラメータ設定の変更方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- すべての初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- ALTER SYSTEMの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

診断ファイルの概要

Oracle Databaseには、データベースの問題を防止、検出、診断および解決するための障害診断性インフラストラクチャが含まれています。問題には、コードの不具合、メタデータの破損、顧客データの破損などの重大なエラーがあります。

この高度な障害診断性インフラストラクチャの目的は、次のとおりです。

- 問題の予防的な検出

- 問題検出後の損害および障害の制限

- 問題の診断時間と解決時間の短縮

- ユーザーとOracleサポートとのやりとりの簡略化

自動診断リポジトリ

自動診断リポジトリ(ADR)は、トレース・ファイル、アラート・ログ、状態モニター・レポートなどデータベース診断データを格納するファイルベース・リポジトリです。ADRの主な特徴は、次のとおりです。

- 統合ディレクトリ構造

- 一貫性のある診断データ形式

- 統合されたツール・セット

これらの特性により、ユーザーとOracleサポートは、複数のOracleインスタンス、コンポーネントおよび製品間で診断データを相関付けて、分析できます。

ADRはデータベースの外側に位置するため、物理データベースが使用不可の場合でも、Oracle DatabaseはADRにアクセスして管理できます。インスタンスにより、データベースの作成が完了する前にADRが作成されることがあります。

問題とインシデント

ADRは、データベース内で重大なエラーとなる問題を予防的に追跡します。重大なエラーとは、ORA-600などの内部エラーや他のサーバー・エラーのことです。各問題には、問題を説明する文字列である問題キーがあります。

1つの問題が複数回発生した場合は、発生するたびに、タイムスタンプの付いたインシデントがADRによって作成されます。インシデントは、数字のインシデントIDによって一意に識別されます。インシデントが発生すると、ADRではインシデント・アラートをEnterprise Managerに送信します。通常、重大なエラーを診断および解決する場合、最初にインシデント・アラートを確認します。

1つの問題で短時間に多数のインシデントが生成される場合があるため、ADRでは特定のしきい値に到達した後、インシデントの生成にフラッド制御を適用します。大量データを制御されたインシデントでは、アラート・ログ・エントリは生成されますが、インシデントのダンプは生成されません。この方法では、ADRから重大なエラーが継続中であることが通知され、診断データによるシステムのオーバーロードは回避されます。

関連項目:
障害診断性インフラストラクチャの詳細は、『Oracle Database管理者ガイド』を参照してください。

ADRの構造

ADRベースは、ADRのルート・ディレクトリです。ADRベースには、複数のADRホームを格納でき、それぞれのADRホームは、Oracle製品やコンポーネントのインスタンスごとにすべての診断データ(トレース、ダンプ、アラート・ログなど)を格納するルート・ディレクトリです。たとえば、共有記憶域とASMがあるOracle RAC環境では、各データベース・インスタンスと各ASMインスタンスにはそれぞれ独自のADRホームがあります。

図13-8に、データベース・インスタンスのADRディレクトリ階層を示します。この階層内の同じADRベースの下に、ASMまたはOracle Net Servicesなどの他のOracle製品やコンポーネントに対する別のADRホームを格納できます。

図13-8 Oracleデータベース・インスタンスのADRディレクトリ構造

次のLinuxの例に示すように、データベースを作成する前に一意のSIDとデータベース名でインスタンスを起動すると、Oracle Databaseは、ホスト・ファイルシステムのディレクトリ構造としてデフォルトでADRを作成します。SIDとデータベース名は、ADRホーム内のファイルのパス名の一部になります。

例13-1 ADRの作成

% setenv ORACLE_SID osi
% echo "DB_NAME=dbn" > init.ora
% sqlplus / as sysdba
.
.
.
Connected to an idle instance.

SQL> STARTUP NOMOUNT PFILE="./init.ora"
ORACLE instance started.

Total System Global Area  146472960 bytes
Fixed Size                  1317424 bytes
Variable Size              92276176 bytes
Database Buffers           50331648 bytes
Redo Buffers                2547712 bytes

SQL> SELECT NAME, VALUE FROM V$DIAG_INFO;

NAME                  VALUE
--------------------- --------------------------------------------------
Diag Enabled          TRUE
ADR Base              /u01/oracle/log
ADR Home              /u01/oracle/log/diag/rdbms/dbn/osi
Diag Trace            /u01/oracle/log/diag/rdbms/dbn/osi/trace
Diag Alert            /u01/oracle/log/diag/rdbms/dbn/osi/alert
Diag Incident         /u01/oracle/log/diag/rdbms/dbn/osi/incident
Diag Cdump            /u01/oracle/log/diag/rdbms/dbn/osi/cdump
Health Monitor        /u01/oracle/log/diag/rdbms/dbn/osi/hm
Default Trace File    /u01/oracle/log/diag/rdbms/dbn/osi/trace/osi_ora_10533.trc
Active Problem Count  0
Active Incident Count 0

次の各項では、ADRの内容について説明します。

アラート・ログ

各データベースには、アラート・ログがあり、これは、データベースのメッセージとエラーの履歴ログが格納されたXMLファイルです。アラート・ログの内容は次のとおりです。

- すべての内部エラー(ORA-600)、ブロック破損エラー(ORA-1578)およびデッドロック・エラー(ORA-60)

- 管理的な操作(たとえば、DDL文やSQL*PlusコマンドのSTARTUP、SHUTDOWN、ARCHIVE LOG、およびRECOVERなど)

- 共有サーバーとディスパッチャ・プロセスの機能に関係するいくつかのメッセージとエラー。

- マテリアライズド・ビューの自動リフレッシュにおけるエラー。

Oracle Databaseでは、Enterprise ManagerのGUIに情報を表示するかわりに、アラート・ログを使用します。管理操作が成功すると、Oracle Databaseはタイムスタンプとともに「completed」というメッセージをアラート・ログに書き込みます。

最初にデータベース・インスタンスを起動すると、データベースがまだ作成されていない場合でも、Oracle Databaseは図13-8に示すalertサブディレクトリにアラート・ログを作成します。次の例では、テキストのみのアラート・ログの一部を示します。

Fri Jun 19 17:05:34 2011
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 2
Autotune of undo retention is turned on.
IMODE=BR
ILAT =12
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 11.2.0.0.0.
Using parameter settings in client-side pfile
.
.
.
System parameters with nondefault values:
db_name                  = "my_test"
Fri Jun 19 17:05:37 2011
PMON started with pid=2, OS id=10329
Fri Jun 19 17:05:37 2011
VKTM started with pid=3, OS id=10331 at elevated priority
VKTM running at (20)ms precision
Fri Jun 19 17:05:37 2011
DIAG started with pid=4, OS id=10335

例13-1に示すように、アラート・ログを検索するにはV$DIAG_INFOを問い合せます。

トレース・ファイル

トレース・ファイルは、問題の調査に使用される診断データを含む管理用のファイルです。「パフォーマンス診断およびチューニング」で説明しているように、トレース・ファイルは、アプリケーションやインスタンスをチューニングするための手引きにもなります。

トレース・ファイルのタイプ

それぞれのサーバーとバックグラウンド・プロセスは、関連付けられたトレース・ファイルに定期的に書き込むことができます。トレース・ファイルには、プロセスの環境、ステータス、アクティビティおよびエラーに関する情報が含まれています。

SQLトレース機能でも、個別のSQL文に関するパフォーマンス情報を提供するトレース・ファイルが作成されます。クライアント識別子、サービス、モジュール、アクション、セッション、インスタンスまたはデータベースのトレースを有効にするには、DBMS_MONITORパッケージで適切なプロシージャを実行するか、Oracle Enterprise Managerを使用する必要があります。

ダンプは、特別なタイプのトレース・ファイルです。多くの場合、トレースでは診断データが連続して出力されますが、ダンプでは、通常、1つのイベント(インシデントなど)に対応して診断データが1回出力されます。インシデントが発生すると、データベースは、そのインシデント用に作成されたインシデント・ディレクトリに1つ以上のダンプを書き込みます。インシデントのダンプには、ファイル名にインシデント番号も付きます。

関連項目:

- 「セッション制御文」

- トレース・ファイル、ダンプおよびコア・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

- アプリケーションのトレースの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

トレース・ファイルの場所

図13-8に示すように、ADRはトレース・ファイルをtraceサブディレクトリに格納します。トレース・ファイル名はプラットフォーム依存であり、拡張子.trcが使用されます。

通常、データベース・バックグラウンド・プロセスのトレース・ファイル名には、Oracle SID、バックグラウンド・プロセス名およびオペレーティング・システムのプロセス番号が含まれています。たとえば、RECOプロセスのトレース・ファイル名は、mytest_reco_10355.trcのようになります。

サーバー・プロセスのトレース・ファイル名には、Oracle SID、文字列oraおよびオペレーティング・システムのプロセス番号が含まれています。たとえば、サーバー・プロセスのトレース・ファイル名は、mytest_ora_10304.trcのようになります。

トレース・ファイルには、対応するトレース・マップ(.trm)のファイルが付くことがあります。これらのファイルには、トレース・ファイルの構造に関する情報が含まれており、検索やナビゲーションに使用されます。

関連項目:
トレース・ファイルの検索方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

14 メモリー・アーキテクチャ

この章では、Oracle Databaseインスタンスのメモリー・アーキテクチャについて説明します。

この章の内容は、次のとおりです。

- Oracle Databaseのメモリー構造の概要

- ユーザー・グローバル領域の概要

- プログラム・グローバル領域の概要

- システム・グローバル領域の概要

- ソフトウェア・コード領域の概要

関連項目:
メモリーの構成方法および管理方法は、『Oracle Database管理者ガイド』を参照してください。

Oracle Databaseのメモリー構造の概要

インスタンスが開始されると、Oracle Databaseによってメモリー領域が割り当てられ、バックグラウンド・プロセスが起動されます。メモリー領域には、次のような情報が格納されています。

- プログラム・コード

- 接続されているセッションについての情報(現在はアクティブかどうかは不問)

- プログラムの実行時に必要な情報(行をフェッチしている問合せの現在の状態など)

- プロセス間で共有および通信されるロック・データなどの情報

- データ・ブロックやREDOレコードなどの、ディスク上にも存在するキャッシュ・データ

関連項目:
第15章「プロセス・アーキテクチャ」

基本的なメモリー構造

Oracle Databaseに関連する基本的なメモリー構造は、次のような領域で構成されています。

- システム・グローバル領域(SGA)
SGAは、SGAコンポーネントと呼ばれる共有メモリー構造のグループで、1つのOracle Databaseインスタンスに関するデータと制御情報が保存されています。SGAは、すべてのサーバーおよびバックグラウンド・プロセスで共有されます。SGAに保存されるデータの例としては、キャッシュ・データ・ブロックや共有SQL領域があります。

- プログラム・グローバル領域(PGA)
PGAは、Oracleプロセス専用のデータや制御情報を含む、非共有メモリー領域です。PGAは、Oracleプロセスの起動時に、Oracle Databaseによって作成されます。

PGAは、サーバー・プロセスごと、およびバックグラウンド・プロセスごとに存在します。個々のPGAの集合は、合計インスタンスPGAまたはインスタンスPGAと呼ばれています。個々のPGAではなく、データベース初期化パラメータを使用してインスタンスPGAのサイズを設定します。

- ユーザー・グローバル領域(UGA)
UGAは、ユーザー・セッションに関連付けられたメモリーです。

- ソフトウェア・コード領域
ソフトウェア・コード領域とは、実行中または実行される可能性のあるコードを格納するためのメモリー部分です。Oracle Databaseのコードはソフトウェア領域に格納され、通常、この場所はユーザー・プログラムの格納場所とは異なり、より排他的で保護されています。

図14-1に、これらのメモリー構造の関係を示します。

図14-1 Oracle Databaseのメモリー構造

Oracle Databaseのメモリー管理

メモリー管理では、データベースの変化に応じて、Oracleインスタンスのメモリー構造を最適なサイズに維持します。Oracle Databaseでは、メモリー関連の初期化パラメータの設定に基づいてメモリーが管理されます。メモリー管理の基本的なオプションは、次のとおりです。

- 自動メモリー管理
インスタンス・メモリーのターゲット・サイズを指定します。データベース・インスタンスは自動的にターゲット・メモリー・サイズにチューニングされ、必要に応じて、SGAとインスタンスPGAとの間でメモリーの再配分が行われます。

- 自動共有メモリー管理
この管理モードでは、一部の処理が自動化されます。SGAは、ターゲット・サイズを設定し、PGAは、ターゲット・サイズの合計を設定するか、作業領域を個別に管理できます。

- 手動メモリー管理
合計メモリー・サイズを設定するかわりに、SGAのコンポーネントおよびインスタンスPGAを個別に管理するための数多くの初期化パラメータを設定します。

Database Configuration Assistant(DBCA)を使用してデータベースを作成し、基本インストール・オプションを選択した場合のデフォルトは、自動メモリー管理です。

関連項目:

- DBAのメモリー管理オプションの詳細は、「メモリーの管理」を参照してください。

- DBCAの詳細は、「データベースのインストールおよび構成ツール」を参照してください。

- メモリー管理オプションの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

ユーザー・グローバル領域の概要

UGAはセッション・メモリーで、ログオン情報やデータベース・セッションに必要なその他の情報などのセッション変数に割り当てられるメモリーです。基本的に、UGAにはセッション状態が格納されています。図14-2に、UGAを示します。

図14-2 ユーザー・グローバル領域(UGA)

セッションによってPL/SQLパッケージがメモリーにロードされると、特定の時点においてすべてのパッケージ変数に格納されている値のセットであるパッケージ状態がUGAに格納されます(「PL/SQLパッケージ」を参照)。パッケージのサブプログラムによって変数が変更されると、パッケージ状態も変更されます。デフォルトで、パッケージ変数はセッションの存続期間に対して固有の変数であり、セッションの存続期間中保持されます。

UGAには、OLAPページ・プールも格納されています。このプールでは、OLAPデータ・ページが管理され、データ・ページはデータ・ブロックと同じものです。ページ・プールは、OLAPセッションの開始時に割り当てられて、セッションの終了時に解放されます。OLAPセッションは、ユーザーがキューブなどのディメンション・オブジェクトを問い合せると、常に自動的に開かれます。

データベース・セッションの存続期間中は、セッションでUGAが使用可能である必要があります。このことは、PGAは単一のプロセス固有の領域であるため、共有サーバー接続を使用する場合にはUGAをPGAに格納できないことを意味しています。したがって、共有サーバー接続を使用する場合は、すべての共有サーバー・プロセスからUGAにアクセスできるよう、UGAはSGAに格納されます。専用サーバー接続を使用する場合は、UGAはPGAに格納されます。

関連項目:

- 「接続とセッション」

- 共有サーバー接続の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- Oracle OLAPの概要は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

プログラム・グローバル領域の概要

PGAは、システムの他のプロセスやスレッドによって共有されていない、動作中のプロセスやスレッドに固有のメモリーです。PGAはプロセス固有であるため、SGA内で割り当てられることはありません。

PGAは、専用サーバー・プロセスまたは共有サーバー・プロセスが必要とするセッション依存の変数を含むメモリー・ヒープです。サーバー・プロセスでは、必要なメモリー構造がPGA内に割り当てられます。

PGAは、文書係が使用するカウンタ上の一時的な作業領域に似ています。このたとえの場合、文書係はサーバー・プロセスを表しており、顧客(クライアント・プロセス)のために作業を行います。文書係は、作業のための場所をカウンタ上に準備し、その場所に顧客のリクエストの詳細をまとめ、顧客が要求するフォルダをソートし、作業が終わるとその場所を解放します。

図14-3に、共有サーバー用に構成されていないインスタンスのインスタンスPGA(すべてのPGAの集合)を示します。初期化パラメータを使用して、インスタンスPGAの最大ターゲット・サイズを設定できます(「メモリー管理方法の概要」を参照)。個々のPGAでは、必要に応じて最大このターゲット・サイズまでサイズを増加できます。

図14-3 インスタンスPGA

注意:
バックグラウンド・プロセスにも独自のPGAが割り当てられます。ここでは、サーバー・プロセスPGAのみを説明します。

PGAの内容

PGAは、それぞれ異なる目的を持つ複数の領域によって構成されています。図14-4に、専用サーバー・セッションのPGAの内容を示します。どの場合にもすべてのPGA領域が揃っているとはかぎりません。

図14-4 PGAの内容

プライベートSQL領域

プライベートSQL領域には、解析済のSQL文に関する情報と、処理に使用するその他のセッション固有の情報が保持されます。サーバー・プロセスでSQLまたはPL/SQLのコードが実行される場合、プロセスではプライベートSQL領域を使用してバインド変数値、問合せ実行状態情報、問合せ実行作業領域が格納されます。

UGA内のプライベートSQL領域は、SGAにおいて実行計画が格納される共有SQL領域とは異なります。同じセッション内または異なるセッション内の複数のプライベートSQL領域から、SGA内の単一の実行計画を指すことができます。たとえば、あるセッションにおけるSELECT * FROM employeesの20回の実行および別のセッションにおける同じ問合せの10回の実行において、同じ計画を共有できます。各実行におけるプライベートSQL領域は共有されず、異なる値やデータが含まれている可能性があります。

カーソルは、特定のプライベートSQL領域の名前またはハンドルです。図14-5に示すように、カーソルはクライアントから見るとポインタ、サーバーから見ると状態のようなものです。カーソルはプライベートSQL領域と密接に関連しているため、これらの用語は同じ意味で使用されることがあります。

図14-5 カーソル

プライベートSQL領域は、次の領域によって構成されています。

- ランタイム領域
この領域には、問合せ実行状態情報が含まれています。たとえば、ランタイム領域では、全表スキャンで現在までに取得された行数が追跡されます。

Oracle Databaseでは、ランタイム領域は実行要求の最初の処理で作成されます。DML文では、SQL文が終了するとランタイム領域が解放されます。

- 持続領域
この領域には、バインド変数値が含まれています。バインド変数値は、SQL文が実行される実行時にSQL文に指定されます。持続領域は、カーソルのクローズ時にのみ解放されます。

クライアント・プロセスは、プライベートSQL領域の管理を担当します。クライアント・プロセスが割り当てることのできるプライベートSQL領域の数は、初期化パラメータOPEN_CURSORSによって制限されますが、プライベートSQL領域の割当ておよび割当て解除は、アプリケーションに大きく依存します。

ほとんどのユーザーはデータベース・ユーティリティの自動カーソル処理を使用しますが、Oracle Databaseのプログラム・インタフェースを利用すると、開発者はカーソルをより制御できるようになります。一般的に、持続領域を解放し、アプリケーション・ユーザーが必要とするメモリーを最小限に抑えるには、オープンされているカーソルのうち再利用しないすべてのカーソルをアプリケーション側でクローズする必要があります。

関連項目:

- 「共有SQL領域」

- カーソルの使用方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』および『Oracle Database PL/SQL言語リファレンス』を参照してください。

SQL作業領域

作業領域は、メモリー集中型の操作に使用されるPGAメモリーを個別に割り当てるための領域です。たとえば、ソート演算子では、ソート領域を使用して行のセットがソートされます。同様に、ハッシュ結合演算子ではハッシュ領域を使用して左側の入力からハッシュ表が構築され、ビットマップ・マージ演算子ではビットマップ・マージ領域を使用して複数のビットマップ索引のスキャンにより取得されたデータがマージされます。

例14-1に、employeesとdepartmentsとの結合およびその問合せ計画を示します。

例14-1 表結合の問合せ計画

SQL> SELECT *
2  FROM   employees e JOIN departments d
3  ON     e.department_id=d.department_id
4  ORDER BY last_name;
.
.
.
----------------------------------------------------------------------------------
| Id  | Operation           | Name        | Rows  | Bytes | Cost (%CPU)| Time    |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |             |   106 |  9328 |    7  (29)| 00:00:01 |
|   1 |  SORT ORDER BY      |             |   106 |  9328 |    7  (29)| 00:00:01 |
|*  2 |   HASH JOIN         |             |   106 |  9328 |    6  (17)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| DEPARTMENTS |    27 |   540 |    2   (0)| 00:00:01 |
|   4 |    TABLE ACCESS FULL| EMPLOYEES   |   107 |  7276 |    3   (0)| 00:00:01 |
----------------------------------------------------------------------------------

例14-1では、ランタイム領域で全表スキャンの進行状況が追跡されます。セッションでは、ハッシュ領域を使用してハッシュ結合が実行されて、2つの表の行が照合されます。ORDER BYによるソートは、ソート領域で行われます。

演算子で処理するデータが作業領域に収まらない場合は、Oracle Databaseによって入力データがより小さく分割されます。データベースでは、このようにして一部のデータがメモリー内で処理され、残りのデータは後で処理するために一時ディスク記憶域に格納されます。

自動PGAメモリー管理が有効になっている場合、作業領域サイズはデータベースにより自動的にチューニングされます。作業領域のサイズを手動で制御してチューニングすることもできます。詳細は、「メモリーの管理」を参照してください。

通常、作業領域を増やすとメモリー使用率は増えますが、演算子のパフォーマンスが大幅に改善されます。作業領域は、入力データや関連するSQL演算子によって割り当てられる補助メモリー構造を格納するために十分なサイズにすることをお薦めします。十分なサイズが確保されていない場合は、一部の入力データがディスクにキャッシュされるため、レスポンス時間が長くなります。作業領域のサイズが入力データ・サイズに比べて非常に小さい場合は、データを分割して何度も渡すことが必要となるため、レスポンス時間が大幅に長くなります。

関連項目:

- 自動PGA管理の使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- PGAメモリーのチューニング方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

専用サーバー・モードおよび共有サーバー・モードにおけるPGAの使用

PGAにメモリーが割り当てられるかどうかは、データベースで専用サーバー接続が使用されるか、共有サーバー接続が使用されるかに応じて異なります。表14-1に相違点を示します。

表14-1 専用サーバーと共有サーバーのメモリー割当て方法の相違点

メモリー領域

専用サーバー

共有サーバー

セッション・メモリーの性質

プライベート

共有

持続領域の位置

PGA

SGA

DML/DDL文のランタイム領域の位置

PGA

PGA

関連項目:
共有サーバーを使用するためのデータベースの構成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

システム・グローバル領域の概要

SGAは、Oracleバックグラウンド・プロセスとともにデータベース・インスタンスを構成する、読取り/書込み可能なメモリー領域です。ユーザー用に実行されるすべてのサーバー・プロセスで、インスタンスSGA内の情報の読取りが可能です。データベース操作中にSGAに書き込むプロセスもあります。

注意:
サーバー・プロセスおよびバックグラウンド・プロセスは、SGA内ではなく、別のメモリー領域内に存在しています。

各データベース・インスタンスには、独自のSGAがあります。Oracle Databaseでは、インスタンスの開始時にSGAのメモリーが自動的に割り当てられて、インスタンスが停止するとメモリーが再利用されます。SQL*PlusまたはOracle Enterprise Managerを使用してインスタンスを開始した場合、SGAは次の例に示すサイズになります。

SQL> STARTUP
ORACLE instance started.

Total System Global Area  368283648 bytes
Fixed Size                  1300440 bytes
Variable Size             343935016 bytes
Database Buffers           16777216 bytes
Redo Buffers                6270976 bytes
Database mounted.
Database opened.

図14-1に示すように、SGAはいくつかのメモリー・コンポーネントによって構成され、これらのコンポーネントは、特定の種類のメモリー割当て要求を満たすために使用されるメモリーのプールです。REDOログ・バッファを除くすべてのSGAコンポーネントは、グラニュルと呼ばれる連続したメモリーの単位で割当ておよび割当て解除されます。グラニュルのサイズはプラットフォーム固有であり、SGAサイズの合計から決定されます。

SGAコンポーネントの情報は、V$SGASTATビューに問い合せることができます。

次に、最も重要なSGAコンポーネントを示します。

- データベース・バッファ・キャッシュ

- REDOログ・バッファ

- 共有プール

- ラージ・プール

- Javaプール

- ストリーム・プール

- 固定SGA

関連項目:

- 「Oracleデータベース・インスタンスの概要」

- グラニュルのサイズ設定の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

データベース・バッファ・キャッシュ

バッファ・キャッシュとも呼ばれるデータベース・バッファ・キャッシュとは、データファイルから読み取られたデータ・ブロックのコピーを格納するメモリー領域のことです。バッファとは、現在使用されているデータ・ブロックまたは最近使用されたデータ・ブロックがバッファ・マネージャによって一時的にキャッシュされるメイン・メモリーのアドレスのことです。データベース・インスタンスに同時接続されたユーザーはすべて、バッファ・キャッシュへのアクセスを共有します。

Oracle Databaseでは、次の目的でバッファ・キャッシュが使用されます。

- 物理I/Oを最適化します。
データベースでは、キャッシュ内のデータ・ブロックが更新されて、REDOログ・バッファに変更についてのメタデータが格納されます。COMMITの後、データベースによってREDOバッファがディスクに書き込まれますが、データ・ブロックが即座にディスクに書き込まれるわけではありません。かわりに、データベース・ライター(DBW)によって、バックグラウンドで遅延書込みが実行されます。

- 頻繁にアクセスされるブロックをバッファ・キャッシュに保持して、頻繁にアクセスされないブロックはディスクに書き込みます。
データベース・スマート・フラッシュ・キャッシュ(フラッシュ・キャッシュ)を有効にすると、バッファ・キャッシュの一部をフラッシュ・キャッシュ内に保持できます。このバッファ・キャッシュの拡張部分は、フラッシュ・ディスク・キャッシュという、フラッシュ・メモリーを搭載した半導体ストレージ・デバイスに保存されます。フラッシュ・メモリー内にバッファがキャッシュされ、磁気ディスクからの読取りが必要なくなるため、データベースのパフォーマンスが向上します。

注意:
データベース・スマート・フラッシュ・キャッシュは、SolarisおよびOracle Enterprise Linux環境でのみ使用できます。

バッファ状態

データベースでは、内部アルゴリズムを使用してキャッシュ内のバッファが管理されます。バッファには、次のような相互に排他的な状態があります。

- 未使用
このバッファはまだ使用されていないか、現在使用されていないため、使用可能です。このタイプのバッファは、最も使用しやすいバッファです。

- クリーン
このバッファは過去に使用され、現在はある時点において読取り一貫性があるバージョンのブロックが含まれています。このブロックにはデータが含まれていますが、クリーンであるため、チェックポイントを作成する必要はありません。データベースでは、このブロックを確保して再利用できます。

- 使用済
このバッファには、まだディスクに書き込まれていない変更されたデータが含まれています。データベースでこのバッファを再利用する前に、このブロックのチェックポイントを作成する必要があります。

すべてのバッファには、使用中または使用可能(確保解除)というアクセス・モードがあります。バッファは、ユーザー・セッションによってアクセスされている間にメモリーからエージ・アウトされないように、キャッシュ内で確保されます。確保されたバッファを複数のセッションから同時に変更することはできません。

Oracle Databaseでは、高度なアルゴリズムを使用して効率的にバッファにアクセスできるようにしています。使用済のバッファと未使用のバッファへのポインタは、同じ最低使用頻度(LRU)リスト上に存在し、このリストの両端はそれぞれホットとコールドと呼ばれます。コールド・バッファは、最近使用されていないバッファです。ホット・バッファは、頻繁にアクセスされ、最近使用されたバッファです。

注意:
概念的にはLRUは1つのみですが、データベースでは実際には同時実行性のために複数のLRUが使用されています。

バッファ・モード

クライアントがデータを要求すると、Oracle Databaseでは、次のいずれかのモードでデータベース・バッファ・キャッシュからバッファが取得されます。

- 現在のモード
現在のモード取得は、DBブロック取得とも呼ばれ、バッファ・キャッシュ内の現行のブロックをそのまま取得します。たとえば、コミットされていないトランザクションによってブロック内の2つの行が更新された場合、現行モード取得により、これらのコミットされていない行を含むブロックが取得されます。Oracle Databaseでは、ブロックの現行バージョンのみを更新する必要がある変更文を実行する際に、最も頻繁にDBブロック取得が使用されます。

- 一貫したモード
読取り一貫性取得は、ブロックの読取り一貫性バージョンを取得します。この取得では、UNDOデータが使用される場合があります。たとえば、トランザクションによってブロック内の2つの行が更新されたがまだコミットされていない場合に、別のセッションの問合せがそのブロックを要求すると、Oracle DatabaseではUNDOデータを使用して、コミットされていない更新を含まない、このブロックの読取り一貫性バージョン(読取り一貫性クローンと呼ばれます)が作成されます。一般に、問合せは一貫性モードでブロックを取得します。

関連項目:

- 「読取り一貫性とUNDOセグメント」

- DBブロック取得や読取り一貫性取得などのデータベース統計の詳細は、『Oracle Databaseリファレンス』を参照してください。

バッファI/O

論理I/Oは、バッファI/Oとも呼ばれ、バッファ・キャッシュ内でのバッファの読取りおよび書込みを表しています。要求されたバッファがメモリーにない場合、Oracle Databaseでは物理I/Oを実行してフラッシュ・キャッシュまたはディスクからメモリーにバッファをコピーし、次に論理I/Oを実行して、キャッシュされたバッファを読み取ります。

バッファ書込み

データベース・ライター(DBW)プロセスでは、コールドかつ使用済のバッファが定期的にディスクに書き込まれます。DBWnでは、次の状況でバッファが書き込まれます。

- サーバー・プロセスで、新しいブロックをデータベース・バッファ・キャッシュに読み取るときにクリーンなバッファが見つからなかった場合。
バッファが使用されるにつれて、使用可能バッファの数が減少します。使用可能バッファの数が内部のしきい値未満になり、クリーンなバッファが必要な場合には、サーバー・プロセスからDBWnに対して、書込みを行うように通知されます。

Oracle Databaseでは、LRUを使用して、どの使用済バッファに書き込むかが決定されます。使用済バッファがLRUのコールド・エンドに達すると、そのバッファはLRUから書込みキューに移動されます。DBWnによって、可能な場合にはマルチブロック書込みを使用して、キュー内のバッファがディスクに書き込まれます。このメカニズムによって、LRUの終端に使用済バッファが滞留しなくなり、クリーンなバッファを検出して再利用できるようになります。

- データベースで、REDOスレッド内のインスタンス・リカバリを開始する位置であるチェックポイントを進める必要がある場合。

- 表領域が読取り専用ステータスに変更されたか、オフラインにされた場合。

関連項目:

- 「データベース・ライター・プロセス(DBWn)」

- バッファ書込みの問題を診断およびチューニングする方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

バッファ読取り

クリーン・バッファまたは未使用バッファの数が減少したら、データベースにより、バッファ・キャッシュからバッファが削除されます。アルゴリズムはフラッシュ・キャッシュが有効かどうかに応じて変わります。

- フラッシュ・キャッシュが無効な場合
各クリーン・バッファは、必要に応じて上書きされ、再使用されます。上書きされたバッファが後から必要になった場合は、そのバッファが磁気ディスクから読み取られます。

- フラッシュ・キャッシュが有効な場合
DBWnがフラッシュ・キャッシュにクリーン・バッファ本体を書き込めるため、メモリー内のバッファの再利用が可能になります。データベースは、フラッシュ・キャッシュ内のバッファ本体の状態と場所を追跡できるように、メイン・メモリー内のLRUリストにバッファのヘッダーを保持します。バッファが後で必要になったときに、データベースは磁気ディスクからではなく、フラッシュ・キャッシュからバッファを読み取ります。

クライアント・プロセスからバッファが要求されると、サーバー・プロセスは最初にバッファ・キャッシュ内でそのバッファを検索します。データベースによるメモリー内のバッファの検索時には、キャッシュ・ヒットの処理が実行されます。検索順序は、次のとおりです。

1. サーバー・プロセスによってバッファ・キャッシュ内にバッファ全体があるかどうかが検索されます。
バッファ全体が見つかった場合は、データベースによってそのバッファの論理読取りが実行されます。

2. サーバー・プロセスによってフラッシュ・キャッシュのLRUリスト内にバッファのヘッダーがあるかどうかが検索されます。
バッファのヘッダーが見つかった場合、データベースによってフラッシュ・キャッシュからメモリー内のキャッシュにバッファ本体の最適化物理読取りが実行されます。

3. キャッシュ・メモリー内にバッファが見つからない場合は(キャッシュ・ミス)、サーバー・プロセスによって次のステップが実行されます。

1. データファイルからメモリーへのブロックのコピー(物理読取り)

2. メモリーに読み取られたバッファの論理読取りの実行

図14-6に、バッファの検索順序を示します。拡張バッファ・キャッシュは、バッファ全体を格納するインメモリーのバッファ・キャッシュと、バッファ本体を格納するフラッシュ・キャッシュから構成されます。図では、データベースによってバッファ・キャッシュ内にバッファがあるかどうか検索され、バッファが見つからなければ、磁気ディスクからメモリーにバッファが読み込まれます。

図14-6 バッファの検索

通常、キャッシュにヒットした場合のデータへのアクセスは、キャッシュ・ミスの場合よりも高速です。バッファ・キャッシュ・ヒット率は、要求されたブロックがバッファ・キャッシュ内に見つかり、ディスクからの読取りが不要である確率を示しています。

データファイルまたは一時ファイルから物理読取りが実行されます。データファイルからの読取りの後には、論理I/Oが実行されます。一時ファイルからの読取りは、メモリー不足によってデータベースがデータを一時表に書き込み、後からそのデータを読み取る必要がある場合に行われます。このような物理読取りでは、バッファ・キャッシュにはアクセスされないため、論理I/Oは発生しません。

関連項目:
バッファ・キャッシュ・ヒット率の計算方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

バッファのタッチ・カウント

データベースでは、タッチ・カウントを使用して、LRUリスト上のバッファへのアクセス頻度が測定されます。このメカニズムによって、バッファが確保されたときに常にLRUリスト上でバッファをシャッフルするかわりに、カウンタを増加できます。

注意:
メモリー内のブロックは、物理的には移動されません。移動は、リスト上のポインタの位置を変更することによって行われます。

バッファが確保されると、最後にタッチ・カウントが増加された時間が特定されます。カウントが3秒前より以前に増加されている場合は、カウントが増加され、そうでない場合は、カウントはそのままです。この3秒ルールによって、バッファが非常に多くの回数確保されたときに、同じ数だけタッチ・カウントが増加されることを防止できます。たとえば、セッションでデータ・ブロックに複数の行を挿入する場合に、データベースではこれらの挿入が1回のタッチであるとみなされます。

バッファがLRUのコールド・エンドにあり、タッチ・カウントが大きい場合、バッファはホット・エンドに移動されます。タッチ・カウントが小さい場合、バッファはキャッシュからエージ・アウトされます。

バッファと全表スキャン

バッファをディスクから読み取る必要がある場合、そのバッファはLRUリストの中央に挿入されます。これにより、ホット・ブロックがキャッシュ内に維持されて、再度ディスクから読み取る必要がなくなります。

表の最高水位標より下のすべての行を順次読み取る全表スキャンでは、問題が発生します(「セグメント領域と最高水位標」を参照)。表セグメント内のブロックの合計サイズが、バッファ・キャッシュのサイズよりも大きいとします。この表を全体スキャンすると、バッファ・キャッシュが一掃されて、頻繁にアクセスされるブロックのキャッシュが維持されなくなる可能性があります。

そのため、大規模な表を全体スキャンした結果データベース・キャッシュに読み取られたブロックは、他のタイプの読取りとは異なる方法で処理されます。スキャンによって実質的にバッファ・キャッシュが一掃されることを防止するために、これらのブロックは即座に再利用可能となります。

まれに、デフォルトの動作が望ましくないことがありますが、その場合は、表のCACHE属性を変更できます。この場合、データベースでは、バッファ・キャッシュ内のブロックは強制的に確保されず、他のブロックの場合と同じようにキャッシュからエージ・アウトされます。このオプションを使用すると、大規模な表の全体スキャンを行ったときに、キャッシュ内の他のほとんどのブロックが一掃される可能性があるため、注意が必要です。

関連項目:

- CACHE句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- バッファ・キャッシュ・アドバイザ統計の解析方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

バッファ・プール

バッファ・プールとは、バッファの集合のことです。データベース・バッファ・キャッシュは、1つ以上のバッファ・プールによって構成されています。

バッファ・キャッシュ内のデータを保持するバッファ・プール、または新しいデータがデータ・ブロックを使用した直後に使用可能なバッファを提供するバッファ・プールを手動で個別に構成できます。その後、適切なバッファ・プールに特定のスキーマ・オブジェクトを割り当て、ブロックがキャッシュからエージ・アウトされる方法を制御できます。

次のバッファ・プールがあります。

- DEFAULTプール
このプールは、ブロックが通常キャッシュされる場所です。手動で個別にプールを構成しない場合は、DEFAULTプールが唯一のバッファ・プールとなります。

- KEEPプール
このプールは、頻繁にアクセスされたが、領域が不足したためにDEFAULTプールからエージ・アウトされたブロック用のプールです。KEEPバッファ・プールの目的は、メモリー内にオブジェクトを保持して、I/O操作を回避することです。

- RECYCLEプール
このプールは、頻繁に使用されないブロック用のプールです。RECYCLEプールによって、キャッシュ内の領域が不要なオブジェクトによって消費されることを防止できます。

データベースには、標準ブロック・サイズがあります(「データベース・ブロック・サイズ」を参照)。標準のサイズとは異なるブロック・サイズを持つ表領域を作成できます。非デフォルトのブロック・サイズには、それぞれ独自のプールがあります。Oracle Databaseでは、これらのプールのブロックもDEFAULTプールと同様に管理されます。

図14-7に、複数のプールが使用された場合のバッファ・キャッシュの構造を示します。このキャッシュには、DEFAULTプール、KEEPプールおよびRECYCLEプールが含まれています。デフォルトのブロック・サイズは8KBです。このキャッシュには、2KB、4KBおよび16KBという非標準のブロック・サイズを使用する表領域用の個別のプールが含まれています。

図14-7 データベース・バッファ・キャッシュ

関連項目:

- バッファ・プールの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

- 複数のバッファ・プールを使用する方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

REDOログ・バッファ

REDOログ・バッファとは、SGA内の循環バッファであり、データベースに加えられた変更についてのREDOエントリが格納されます。REDOエントリには、DML操作やDDL操作によって行われた変更を再構築または再実行するために必要な情報が含まれています。データベースのリカバリでは、データファイルにREDOエントリを適用して、失われた変更が再構築されます。

REDOエントリは、Oracle Databaseプロセスによってユーザーのメモリー領域からSGA内のREDOログ・バッファにコピーされます。REDOエントリは、バッファ内で連続した領域を占めます。REDOログ・バッファは、バックグラウンド・プロセスのログ・ライター(LGWR)によって、ディスク上のアクティブなオンラインREDOログ・グループに書き込まれます。図14-8に、このREDOバッファのアクティビティを示します。

図14-8 REDOログ・バッファ

DBWnではデータ・ブロックは分散してディスクに書き込まれますが、LGWRではREDOログ・バッファはディスクに対して順次書き込まれます。通常、分散書込みの速度は順次書込みよりも大幅に遅くなります。LGWRでは、ユーザーはDBWnによる遅い書込みが完了するまで待機する必要がないため、パフォーマンスが向上します。

LOG_BUFFER初期化パラメータでは、Oracle DatabaseでREDOエントリをバッファリングする場合に使用するメモリー量を指定します。他のSGAコンポーネントとは異なり、REDOログ・バッファおよび固定SGAバッファのメモリーは、グラニュルに分割されません。

関連項目:

- 「ログ・ライター・プロセス(LGWR)」および「インスタンス・リカバリでのチェックポイントの重要性」

- オンラインREDOログの詳細は、『Oracle Database管理者ガイド』を参照してください。

共有プール

共有プールには、様々なタイプのプログラム・データがキャッシュされます。たとえば、共有プールには、解析済のSQLやPL/SQLのコード、システム・パラメータ、データ・ディクショナリ情報などが格納されます。共有プールは、データベースで行われるほぼすべての操作に関連します。たとえば、ユーザーがSQL文を実行する場合にも、Oracle Databaseは共有プールにアクセスします。

共有プールは、複数のサブコンポーネントから構成されています。図14-9に、最も重要なサブコンポーネントを示します。

図14-9 共有プール

この項の内容は、次のとおりです。

- ライブラリ・キャッシュ

- データ・ディクショナリ・キャッシュ

- サーバー結果キャッシュ

- 予約プール

ライブラリ・キャッシュ

ライブラリ・キャッシュとは、実行可能なSQLコードやPL/SQLコードが格納されている共有プール・メモリー構造です。このキャッシュには、SQLとPL/SQLの共有領域や、ロックやライブラリ・キャッシュ・ハンドルなどの制御構造が含まれています。共有サーバー・アーキテクチャでは、ライブラリ・キャッシュにはプライベートSQL領域も含まれています。

SQL文が実行されると、データベースでは、以前に実行されたコードの再利用が試みられます。ライブラリ・キャッシュ内にSQL文の解析済表現が存在し、共有可能である場合には、そのコードが再利用され、これはソフト解析またはライブラリ・キャッシュ・ヒットと呼ばれます。それ以外の場合には、データベースでアプリケーション・コードの実行可能バージョンを新たに構築する必要があり、これは ハード解析またはライブラリ・キャッシュ・ミスと呼ばれます。

共有SQL領域

データベースでは、実行される各SQL文の表現が次のSQL領域内に保持されます。

- 共有SQL領域
SQL文が最初に実行されたときは、共有SQL領域を使用してSQL文が処理されます。この領域にはすべてのユーザーがアクセス可能であり、文の解析ツリーと実行計画が含まれています。一意の文に対して、共有SQL領域は1つのみ存在します。

- プライベートSQL領域
SQL文を発行するそれぞれのセッションには、PGA内にプライベートSQL領域があります(「プライベートSQL領域」を参照)。同じ文を発行する各ユーザーのプライベートSQL領域は、同じ共有SQL領域を指しています。これにより、異なるPGA内の数多くのプライベートSQL領域を同一の共有SQL領域に関連付けることができます。

データベースでは、アプリケーションによって同じSQL文が発行されたことが自動的に判断されます。ユーザーやアプリケーションが直接発行したSQL文も、他の文によって内部的に発行された再帰的SQL文も対象となります。

データベースでは、次のステップが実行されます。

1. 構文およびセマンティクスが同一の文について共有SQL領域が存在しているかどうかを確認するため、共有プールがチェックされます。

- 同一の文が存在する場合、これ以降この文の新たなインスタンスが実行されるときには共有SQL領域が使用されるため、メモリー消費が削減されます。

- 同一の文が存在しない場合は、共有プールに新しい共有SQL領域が割り当てられます。構文が同じであるもののセマンティクスが異なる文の場合は、子カーソルが使用されます。

どちらの場合も、ユーザーのプライベートSQL領域が、その文と実行計画を含む共有SQL領域に対応付けられます。

2. セッションのためにプライベートSQL領域が割り当てられます。
プライベートSQL領域の位置は、セッションのために確立される接続に応じて異なります。セッションが共有サーバーを介して接続されている場合、プライベートSQL領域の一部はSGA内に保持されます。

図14-10に、専用サーバー・アーキテクチャにおいて、2つのセッションが同じSQL文のコピーをそれぞれのPGA内に保持する様子を示します。共有サーバーでは、このコピーはラージ・プール内のUGAにあり、ラージ・プールが存在しない場合は、共有プール内のUGAにあります。

図14-10 プライベートSQL領域と共有SQL領域

関連項目:

- ライブラリ・キャッシュの管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- 共有SQLの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

プログラム・ユニットとライブラリ・キャッシュ

ライブラリ・キャッシュには、PL/SQLプログラムおよびJavaクラスの実行可能形式が保持されます。これらは、プログラム・ユニットと総称されます。

データベースでは、プログラム・ユニットはSQL文と同様に処理されます。たとえば、データベースでは、割り当てられた共有領域にPL/SQLプログラムの解析済かつコンパイル済の形式が保持されます。データベースでは、ローカル変数、グローバル変数、パッケージ変数、SQL実行用バッファなど、プログラムを実行するセッションに固有の値を保持するためのプライベート領域が割り当てられます。複数のユーザーが同じプログラムを実行する場合は、各ユーザーが独自のプライベートSQL領域を持ち、セッション固有の値はそこに保持され、単一の共有SQL領域にアクセスします。

データベースでは、PL/SQLプログラム・ユニット内の個別のSQL文はすでに説明したように処理されます。PL/SQLプログラム・ユニット内の起点には関係なく、これらのSQL文は解析された表現を保持するために共有領域を使用し、その文を実行するセッションごとにプライベートSQL領域を使用します。

共有プール内のメモリーの割当てと再利用

データベースでは、新しいSQL文が解析されたときに共有プール・メモリーが割り当てられます。このメモリーのサイズは、文の複雑度に応じて決められます。

通常、共有プール内の項目は、LRUアルゴリズムによって削除されるまで保持されます。多数のセッションが使用している共有プール項目は、その項目を作成したプロセスが終了しても、その項目が使用されているかぎりメモリーに残ります。このメカニズムによって、SQL文のオーバーヘッドと処理を最小限に抑えることができます。

新しい項目の領域が必要になった場合は、頻繁に使用されていない項目のメモリーが解放されます。共有SQL領域がオープンしているカーソルに対応していても、しばらく使用されていないカーソルであれば、その共有SQL領域を共有プールから削除できます。オープンしているカーソルが、その後その文を実行するために使用される場合、その文はOracle Databaseにより再解析されて新しい共有SQL領域が割り当てられます。

データベースでは、次のような場合にも共有プールから共有SQL領域が削除されます。

- 表、表クラスタまたは索引に対して統計が収集されている場合は、デフォルトで、特定の時間が経過した後、その分析対象オブジェクトを参照する文を含むすべての共有SQL領域が徐々に削除されます。削除された文を次に実行するときには、その文はスキーマ・オブジェクトの新しい統計を反映するように新しい共有SQL領域で解析されます。

- スキーマ・オブジェクトがSQL文内で参照されており、このオブジェクトが後でDDL文によって変更された場合、共有SQL領域は無効化されます。オプティマイザでは、次回この文を実行するときに文を再解析する必要があります。

- グローバル・データベース名を変更すると、すべての情報が共有プールから削除されます。

ALTER SYSTEM FLUSH SHARED_POOL文を使用して共有プール内のすべての情報を手動で削除すると、インスタンスを再起動した後のパフォーマンスを評価できます。

関連項目:

- ALTER SYSTEM FLUSH SHARED_POOLの使用方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- V$SQLおよびV$SQLAREA動的ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

データ・ディクショナリ・キャッシュ

データ・ディクショナリとは、データベース、データベースの構造およびそのユーザーについての参照情報を含むデータベース表およびビューの集合です。Oracle Databaseは、SQL文の解析時にデータ・ディクショナリに頻繁にアクセスします。

データ・ディクショナリはOracle Databaseによって頻繁にアクセスされるので、ディクショナリ・データを保持するために、次のような特別な場所がメモリー内に指定されています。

- データ・ディクショナリ・キャッシュ
このキャッシュには、データベース・オブジェクトについての情報が保持されています。データがバッファではなく行として保持されるため、このキャッシュは行キャッシュとも呼ばれます。

- ライブラリ・キャッシュ

これらのキャッシュは、データ・ディクショナリ情報にアクセスするすべてのサーバー・プロセスによって共有されます。

関連項目:

- 第6章「データ・ディクショナリと動的パフォーマンス・ビュー」

- データ・ディクショナリ・キャッシュに追加のメモリーを割り当てる方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

サーバー結果キャッシュ

バッファ・プールとは異なり、サーバー結果キャッシュにはデータ・ブロックではなく結果セットが保持されています。サーバー結果キャッシュには、同一のインフラストラクチャを共有するSQL問合せ結果キャッシュとPL/SQLファンクション結果キャッシュが含まれています。

クライアント結果キャッシュは、サーバー結果キャッシュとは異なります。クライアント・キャッシュはアプリケーション・レベルで構成されており、データベース・メモリーではなくクライアント・メモリー内に配置されます。

関連項目:

- 結果キャッシュのサイズ設定の詳細は、『Oracle Database管理者ガイド』を参照してください。

- DBMS_RESULT_CACHEパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

- クライアント結果キャッシュの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

SQL問合せ結果キャッシュ

データベースでは、将来の問合せおよび問合せ断片用にキャッシュされた結果を使用して、SQL問合せ結果キャッシュに問合せおよび問合せの断片の結果を格納できます。ほとんどのアプリケーションにとって、このキャッシュによるパフォーマンス向上は有益です。

たとえば、アプリケーションで繰り返し同じSELECT文が実行されるとします。結果がキャッシュされている場合には、データベースから即座に結果が戻されます。これにより、データベースでは、ブロックの再読取りおよび結果の再計算という多くのリソースを消費する操作を行う必要がなくなります。データまたはキャッシュされた結果の構成に使用されているデータベース・オブジェクトのメタデータがトランザクションで変更されると、キャッシュされた結果はデータベースにより自動的に無効化されます。

ユーザーは、RESULT_CACHEヒントを使用して問合せまたは問合せ断片に注釈を付け、結果をSQL問合せ結果キャッシュに保存することを指定できます。RESULT_CACHE_MODE初期化パラメータによって、SQL問合せ結果キャッシュが可能なかぎりすべての問合せで使用されるか、注釈が付けられた問合せにのみ使用されるかが決定されます。

関連項目:

- RESULT_CACHE_MODE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- RESULT_CACHEヒントの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

PL/SQLファンクション結果キャッシュ

PL/SQLファンクション結果キャッシュには、ファンクションの結果セットが格納されています。キャッシュがない場合には、1コール当たり1秒かかるファンクションを1000回コールすると、1000秒かかります。キャッシュがある場合は、このファンクションを同じ入力を使用して1000回コールしても全体で1秒しかかかりません。結果キャッシュは、比較的静的なデータに依存し、頻繁に起動されるファンクションに適しています。

PL/SQLファンクション・コードには、その結果をキャッシュするように要求するコードを含めることができます。このようなファンクションが起動されると、システムによってキャッシュがチェックされます。同じパラメータ値が指定された以前のファンクション・コールの結果がキャッシュに含まれている場合は、実行者にはキャッシュされた結果が戻され、ファンクション本体は再実行されません。キャッシュに結果が含まれていない場合は、ファンクション本体が実行され、実行元に制御が戻される前に、指定されたパラメータ値での結果がキャッシュに追加されます。

注意:
キャッシュされた結果を計算するために使用されるデータベース・オブジェクトを指定して、これらのオブジェクトのいずれかが更新された場合にキャッシュされた結果が無効になり、再計算されるように設定できます。

キャッシュには数多くの結果を含むことができ、ファンクションの起動に使用されたパラメータの一意の組合せごとに1つの結果がキャッシュされます。データベースでさらにメモリーが必要になった場合は、1つ以上のキャッシュ済の結果がエージ・アウトされます。

関連項目:

- PL/SQLファンクション結果キャッシュの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- PL/SQLファンクション結果キャッシュの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

予約プール

予約プールは共有プール内のメモリー領域であり、Oracle Databaseで大量の連続したメモリーのチャンクを割り当てる場合に使用できます。

共有プールからのメモリーの割当ては、チャンク単位で実行されます。チャンクを使用することによって、単一の連続した領域がない場合でもキャッシュに大きなオブジェクト(5KBよりも大きいオブジェクト)をロードできます。これにより、データベースでは、断片化によって連続したメモリーが使用できなくなる可能性が低減されます。

まれに、Java、PL/SQLまたはSQLカーソルによって、5KBを超える領域が共有プールから割り当てられることがあります。このような割当てが最も効率的に行われるように、データベースでは共有プールの一部分が予約プールとして分離されています。

関連項目:
予約プールの構成方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

ラージ・プール

ラージ・プールは、共有プールでの割当てには適さない大量のメモリー割当て用のオプションのメモリー領域です。ラージ・プールでは、次のような領域に対して大量のメモリー割当てを行うことができます。

- 共有サーバーおよびOracle XAインタフェース用のUGA(トランザクションが複数のデータベースと対話する環境で使用)

- 文のパラレル実行で使用されるメッセージ・バッファ

- Recovery Manager(RMAN)I/Oスレーブ用のバッファ

共有SQLのセッション・メモリーをラージ・プールから割り当てることによって、共有SQLキャッシュが小さくなることによるパフォーマンス上のオーバーヘッドを回避できます。ラージ・プールでは、RMAN操作、I/Oサーバー・プロセスおよびパラレル・バッファ用のメモリーを大きなバッファに割り当てることによって、大量のメモリーのリクエストを共有プールよりも効率的に処理できます。

図14-11に、ラージ・プールを視覚的に示します。

図14-11 ラージ・プール

ラージ・プールは、同じ共有プールから割り当てられる他のメモリーと同じLRUリストが使用される、共有プール内の確保されている領域とは異なります。ラージ・プールには、LRUリストはありません。割り当てられた各メモリーは、そのメモリーの使用が終了するまでは解放できません。メモリーのチャンクが解放されると、その領域は他のプロセスがすぐに使用できます。

関連項目:

- 共有サーバーのセッション・メモリーの割当ての詳細は、「ディスパッチャのリクエスト・キューとレスポンス・キュー」を参照してください。

- Oracle XAの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- ラージ・プールの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- パラレル実行用にメモリーを割り当てる方法は、「パラレル実行」を参照してください。

Javaプール

Javaプールは、Java仮想マシン(JVM)内のセッション固有のすべてのJavaコードとデータが格納されるメモリー領域です。このメモリーには、コール終了時にJavaセッション領域に移行されるJavaオブジェクトが含まれています。

専用サーバー接続では、Javaプールには各Javaクラスの共有部分(メソッドおよびコード配列などの読取り専用メモリー)が含まれていますが、各セッションのセッションごとのJava状態は含まれていません。共有サーバーでは、Javaプールには、各クラスの共有部分および各セッションの状態に使用される一部のUGAが含まれています。各UGAは必要に応じて拡大および縮小されますが、UGAの合計サイズはJavaプール領域に収まる必要があります。

Java Pool Advisor統計は、Javaに使用されるライブラリ・キャッシュ・メモリーに関する情報を提供し、Javaプールのサイズの変化が解析率に及ぼす影響を予測します。Java Pool Advisorは、statistics_levelをTYPICAL以上に設定すると内部的にオンに設定されます。これらの統計は、アドバイザをオフにするとリセットされます。

関連項目:

- 『Oracle Database Java開発者ガイド』

- Javaプール・アドバイザ統計を含むビューの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

ストリーム・プール

ストリーム・プールには、バッファ・キュー・メッセージが保存され、Oracle Streamsの取得プロセスおよび適用プロセス用のメモリーが用意されています。ストリーム・プールは、Oracle Streamsによって排他的に使用されます。

明示的に構成しないかぎり、ストリーム・プールのサイズはゼロから開始されます。プール・サイズは、Oracle Streamsの必要に応じて動的に増加します。

関連項目:
『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』および『Oracle Streamsレプリケーション管理者ガイド』

固定SGA

固定SGAは、内部のハウスキーピング用領域です。固定SGAには、たとえば次のような情報が含まれています。

- バックグラウンド・プロセスがアクセスする必要のある、データベースとインスタンスの状態に関する一般的な情報

- ロックに関する情報などの、プロセス間で通信される情報(「自動ロックの概要」を参照)

固定SGAのサイズはOracle Databaseによって設定され、手動では変更できません。固定SGAのサイズは、リリースによって異なります。

ソフトウェア・コード領域の概要

ソフトウェア・コード領域とは、実行中または実行される可能性のあるコードを格納するメモリー部分です。Oracle Databaseのコードはソフトウェア領域に格納され、通常、この場所はユーザー・プログラムの格納場所よりも排他的であり、保護されています。

ソフトウェア領域のサイズは通常固定されており、ソフトウェアの更新時か再インストール時にかぎり変化します。これらの領域に必要なサイズは、オペレーティング・システムによって異なります。

ソフトウェア領域は読取り専用で、共有または非共有でインストールされます。Oracle FormsやSQL*Plusなど一部のデータベース・ツールおよびユーティリティは共有でインストールできますが、共有でインストールできないものもあります。データベースのコードは、メモリー内に複数のコピーを格納することなくすべてのユーザーがアクセスできるよう、可能なかぎり共有され、これにより、メイン・メモリーの使用量が削減されて、全体的にパフォーマンスが向上します。データベースの複数のインスタンスが同じコンピュータ上で実行されている場合、それらのインスタンスは異なるデータベースにおいても同じデータベース・コード領域を使用できます。

注意:
ソフトウェアを共有でインストールするオプションは、すべてのオペレーティング・システムで使用できるわけではありません(たとえば、Windowsが稼働しているPCでは使用できません)。詳細は、オペレーティング・システム別のドキュメントを参照してください。

15 プロセス・アーキテクチャ

この章では、Oracle Databaseのプロセスについて説明します。

この章の内容は、次のとおりです。

- プロセスの概要

- クライアント・プロセスの概要

- サーバー・プロセスの概要

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

プロセスの概要

プロセスは一連の処理を実行できるオペレーティング・システムのメカニズムです。このメカニズムはオペレーティング・システムによって異なります。たとえば、Linuxでは、Oracleバックグラウンド・プロセスはLinuxプロセスです。Windowsでは、Oracleバックグラウンド・プロセスはプロセス内の実行スレッドです。

コード・モジュールは、プロセスによって実行されます。Oracle Databaseに接続されたすべてのユーザーは、データベース・インスタンスにアクセスするために、次のモジュールを実行する必要があります。

- アプリケーションまたはOracle Databaseユーティリティ
データベース・ユーザーは、プリコンパイラ・プログラムなどのデータベース・アプリケーションや、データベースに対してSQL文を発行するSQL*Plusなどのデータベース・ツールを実行します。

- Oracleデータベース・コード
各ユーザーには、各ユーザーのために実行されるOracleデータベース・コードがあり、これによってアプリケーションのSQL文を解釈および処理します。

プロセスは通常、そのプロセスのプライベート・メモリー領域で実行されます。ほとんどのプロセスは、関連付けられたトレース・ファイルに定期的に書き込むことができます(「トレース・ファイル」を参照)。

関連項目:
「データベース管理者向けのツール」および「データベース開発者向けのツール」

マルチ・プロセスOracle Databaseシステム

マルチ・プロセスOracle(マルチユーザーOracleとも呼ばれる)は、Oracle Databaseコードの各部分の実行およびユーザー用に複数のプロセスを使用します(ユーザー用のプロセスは、接続するユーザーごとに個別のプロセスの場合や、複数のユーザーが共有する1つ以上のプロセスの場合があります)。データベースの主な利点が、複数のユーザーが同時に必要とするデータを管理できることにあるため、多くのデータベースはマルチユーザー対応です。

データベース・インスタンスの各プロセスは、特定のジョブを実行します。データベースとアプリケーションの処理を複数のプロセスに分割することにより、複数のユーザーおよびアプリケーションが1つのインスタンスに同時に接続でき、優れたパフォーマンスを確保できます。

プロセスのタイプ

次のタイプのプロセスは、データベース・インスタンスに含まれているか、データベース・インスタンスと対話します。

- クライアント・プロセスは、アプリケーションまたはOracleツールのコードを実行します。

- Oracleプロセスは、Oracleデータベース・コードを実行します。Oracleプロセスには、次のサブタイプがあります。

- バックグラウンド・プロセスは、データベース・インスタンスとともに起動し、インスタンス・リカバリの実行、プロセスのクリーン・アップ、ディスクへのREDOバッファの書込みなどのメンテナンス・タスクを実行します。

- サーバー・プロセスは、クライアントの要求に基づいて処理を実行します。
たとえば、これらのプロセスではSQL問合せを解析して共有プールに入れ、問合せごとに問合せ計画を作成して実行し、データベース・バッファ・キャッシュまたはディスクからバッファを読み取ります。

注意:
サーバー・プロセスおよびサーバー・プロセス内で割り当てられたプロセス・メモリーは、インスタンス内で実行されます。サーバー・プロセスが終了しても、インスタンスは機能し続けます。

- スレーブ・プロセスは、バックグラウンドまたはサーバー・プロセスに対して追加タスクを実行します。

プロセスの構造は、オペレーティング・システムおよびOracle Databaseオプションの選択に応じて異なります。たとえば、接続されたユーザーのコードは、専用サーバーまたは共有サーバー接続に対して構成できます。共有サーバー・アーキテクチャでは、データベース・コードを実行する各サーバー・プロセスが複数のクライアント・プロセスに対応できます。

図15-1に、専用のサーバー接続を使用する、システム・グローバル領域(SGA)およびバックグラウンド・プロセスを示します。それぞれのユーザー接続で、データベース・コードを実行するためのサーバー・プロセスとは別のクライアント・プロセスでアプリケーションが実行されます。各クライアント・プロセスは、それ自体のサーバー・プロセスに関連付けられ、そのサーバー・プロセスには、それ自体のプログラム・グローバル領域(PGA)があります。

図15-1 OracleプロセスおよびSGA

関連項目:

- 「専用サーバー・アーキテクチャ」および「共有サーバー・アーキテクチャ」

- 構成の選択の詳細は、オペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

- V$PROCESSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

クライアント・プロセスの概要

ユーザーがPro*CプログラムやSQL*Plusなどのアプリケーションを実行する場合、オペレーティング・システムでは、そのユーザー・アプリケーションを実行するために、クライアント・プロセス(ユーザー・プロセスとも呼ばれる)を作成します。クライアント・アプリケーションにはOracle Databaseライブラリがリンクされており、このライブラリによってデータベースとの通信に必要なAPIが提供されます。

クライアントおよびサーバー・プロセス

クライアント・プロセスは、インスタンスと直接対話するOracleプロセスとは大きく異なります。クライアント・プロセスにサービスを提供するOracleプロセスでは、SGAからの読取りおよびSGAへの書込みが可能ですが、クライアント・プロセスではできません。クライアント・プロセスは、データベース・ホストとは別のホストで実行できますが、Oracleプロセスは実行できません。

たとえば、クライアント・ホストのユーザーがSQL*Plusを起動し、ネットワークを介して別のホストのデータベース、sampleに接続するとします(データベース・インスタンスは開始されません)。

SQL> CONNECT SYS@inst1 AS SYSDBA
Enter password: *********
Connected to an idle instance.

クライアント・ホスト上でsqlplusまたはsampleのプロセスを検索すると、sqlplusクライアント・プロセスのみが表示されます。

% ps -ef | grep -e sample -e sqlplus | grep -v grep
clientuser 29437 29436  0 15:40 pts/1    00:00:00 sqlplus           as sysdba

データベース・ホスト上でsqlplusまたはsampleのプロセスを検索すると、ローカル以外の接続を伴うサーバー・プロセスが表示されますが、クライアント・プロセスは表示されません。

% ps -ef | grep -e sample -e sqlplus | grep -v grep
serveruser 29441     1  0 15:40 ?        00:00:00 oraclesample (LOCAL=NO)

接続とセッション

接続とは、クライアント・プロセスとデータベース・インスタンスとの間の物理的な通信経路のことです。通信経路は、使用可能なプロセス間通信メカニズムまたはネットワーク・ソフトウェアを使用して確立されます。一般的に、接続はクライアント・プロセスとサーバー・プロセスまたはディスパッチャとの間で確立されますが、クライアント・プロセスとOracle Connection Manager(CMAN)との間でも確立されます。

セッションは、データベースに対する現在のユーザー・ログインの状況を示す、データベース・インスタンス・メモリー内の論理エンティティです。たとえば、ユーザーがパスワードによってデータベースから認証されると、このユーザーに対してセッションが確立されます。セッションは、ユーザーがデータベースから認証された時点から、ユーザーが接続を切断するか、データベース・アプリケーションを終了する時点まで続きます。

1つの接続では、セッションが確立されないか、1つ以上のセッションが確立されます。セッションはそれぞれ独立していて、あるセッションでのコミットは、他のセッションのトランザクションには影響しません。

注意:
Oracle Net接続プーリングが構成されると、接続が中断されることがありますが、セッションはそのまま残されます。

単独のデータベース・ユーザーに対して、複数のセッションが同時に存在できます。図15-2に示すように、ユーザーhrが1つのデータベースに複数の接続を確立できます。専用サーバー接続の場合、それぞれの接続のかわりに1つのサーバー・プロセスがデータベースによって作成されます。これは、専用サーバーを作成するクライアント・プロセスのみが使用します。共有サーバー接続では、多数のクライアント・プロセスが1つの共有サーバー・プロセスにアクセスします。

図15-2 各接続に1セッション

図15-3は、ユーザーhrが1つのデータベースに1つの接続を確立していることを示していますが、この接続には2つのセッションがあります。

図15-3 1つの接続に存在する2つのセッション

SQL文実行統計の自動トレース・レポートを作成すると、図15-3のシナリオが再作成されます。例15-2では、ユーザーSYSTEMとしてデータベースにSQL*Plusを接続してトレースを実行可能にし、新規セッションを作成しています(サンプル出力を含みます)。

例15-1 1接続に2セッション

SQL> SELECT SID, SERIAL#, PADDR FROM V$SESSION WHERE USERNAME = USER;

SID SERIAL# PADDR
--- ------- --------
90      91 3BE2E41C

SQL> SET AUTOTRACE ON STATISTICS;
SQL> SELECT SID, SERIAL#, PADDR FROM V$SESSION WHERE USERNAME = USER;

SID SERIAL# PADDR
--- ------- --------
88      93 3BE2E41C
90      91 3BE2E41C
...
SQL> DISCONNECT

例15-1のDISCONNECTコマンドは、実際には、接続ではなくセッションを終了しています。新規端末を開いて別のユーザーとしてインスタンスに接続し、例15-2の問合せを実行すると、例15-1からの接続がアクティブなままであることが示されます。

例15-2 セッションなしの接続

SQL> CONNECT dba1@inst1
Password: ********
Connected.
SQL> SELECT PROGRAM FROM V$PROCESS WHERE ADDR = HEXTORAW('3BE2E41C');

PROGRAM
------------------------------------------------
oracle@stbcs09-1 (TNS V1-V3)

関連項目:
「共有サーバー・アーキテクチャ」

サーバー・プロセスの概要

Oracle Databaseでは、インスタンスに接続されたクライアント・プロセスの要求を処理するために、サーバー・プロセスが作成されます。クライアント・プロセスは常に別のサーバー・プロセスを介してデータベースと通信します。

データベース・アプリケーション用に作成されるサーバー・プロセスは、次のタスクを1つ以上実行できます。

- アプリケーションを介して発行されたSQL文を解析し、実行します。これには問合せ計画の作成および実行も含まれます(「SQL処理の段階」を参照)。

- PL/SQLコードを実行します。

- データファイルからデータベース・バッファ・キャッシュにデータ・ブロックを読み取ります(DBWnバックグラウンド・プロセスには、修正されたブロックをディスクに戻して書き込むというタスクがあります)。

- アプリケーションが情報を処理できるような方法で結果を戻します。

専用サーバー・プロセス

専用サーバー接続の場合、クライアント接続は、1つのサーバー・プロセスにのみ関連付けられています(「専用サーバー・アーキテクチャ」を参照)。Linuxでは、1つのデータベース・インスタンスに接続された20のクライアント・プロセスに、20のサーバー・プロセスが対応します。

各クライアント・プロセスは、そのサーバー・プロセスと直接通信します。セッションの継続中、このサーバー・プロセスはそのクライアント・プロセス専用になります。サーバー・プロセスでは、PGAにプロセス固有の情報およびUGAを格納します(「専用サーバー・モードおよび共有サーバー・モードにおけるPGAの使用」を参照)。

共有サーバー・プロセス

共有サーバー接続の場合、クライアント・アプリケーションはネットワーク上でサーバー・プロセスではなく、ディスパッチャ・プロセスに接続します(「共有サーバー・アーキテクチャ」を参照)。たとえば、20のクライアント・プロセスが1つのディスパッチャ・プロセスに接続できます。

ディスパッチャ・プロセスでは、接続されたクライアントからのリクエストを受け取り、ラージ・プールのリクエスト・キューに入れます(「ラージ・プール」を参照)。最初に使用可能な共有サーバー・プロセスが、キューからリクエストを受け取って処理します。その後、共有サーバーは、その結果をディスパッチャ・レスポンス・キューに入れます。ディスパッチャ・プロセスはこのキューを監視し、結果をクライアントに送信します。

専用サーバー・プロセスと同様、共用サーバー・プロセスにはそれ自体のPGAがあります。ただし、共有サーバーがセッション・データにアクセスできるように、セッションのUGAはSGAにあります。

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

マルチ・プロセスOracle Databaseでは、バックグラウンド・プロセスと呼ばれる、いくつかの追加プロセスを使用します。バックグラウンド・プロセスでは、データベースの操作、および複数ユーザーのパフォーマンスの最大化に必要なメンテナンス・タスクを実行します。

各バックグラウンド・プロセスには個別のタスクがありますが、他のプロセスと連携して動作します。たとえば、LGWRプロセスでは、REDOログ・バッファのデータをオンラインREDOログに書き込みます。ログ・ファイルがいっぱいになり、アーカイブできるようになると、LGWRは別のプロセスに対してそのファイルをアーカイブするよう信号を送ります。

Oracle Databaseは、データベース・インスタンスが起動すると、自動的にバックグラウンド・プロセスを作成します。インスタンスは多数のバックグラウンド・プロセスを持つことができますが、そのすべてが常にそれぞれのデータベース構成に存在するとはかぎりません。次の問合せを実行すると、データベースで実行中のバックグラウンド・プロセスが表示されます。

SELECT PNAME
FROM   V$PROCESS
WHERE  PNAME IS NOT NULL
ORDER BY PNAME;

この項の内容は、次のとおりです。

- 必須のバックグラウンド・プロセス

- オプションのバックグラウンド・プロセス

- スレーブ・プロセス

関連項目:
すべてのバックグラウンド・プロセスの詳細は、『Oracle Databaseリファレンス』を参照してください。

必須のバックグラウンド・プロセス

必須のバックグラウンド・プロセスは、すべての一般的なデータベース構成に存在します。これらのプロセスは、デフォルトでは、最小限に構成された初期化パラメータ・ファイルを使用して起動されるデータベース・インスタンス内で実行されます(例13-1を参照)。

この項では、次の必須のバックグラウンド・プロセスについて説明します。

- プロセス・モニター・プロセス(PMON)

- システム・モニター・プロセス(SMON)

- データベース・ライター・プロセス(DBWn)

- ログ・ライター・プロセス(LGWR)

- チェックポイント・プロセス(CKPT)

- 管理性モニター・プロセス(MMONおよびMMNL)

- リカバラ・プロセス(RECO)

関連項目:

- MMAN、DIAG、VKTM、DBRM、PSP0などの他の必須プロセスの詳細は、『Oracle Databaseリファレンス』を参照してください。

- Oracle RACおよびOracle Clusterwareに固有のバックグラウンド・プロセスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』および『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

プロセス・モニター・プロセス(PMON)

プロセス・モニター(PMON)では、他のバックグラウンド・プロセスを監視し、サーバーまたはディスパッチャ・プロセスが異常終了した場合には、プロセス・リカバリを実行します。PMONは、データベース・バッファ・キャッシュをクリーン・アップしたり、クライアント・プロセスが使用していたリソースを解放します。たとえば、PMONでアクティブ・トランザクション表の状態をリセットして、不要になったロックを解除し、アクティブ・プロセスのリストからプロセスIDを削除します。

また、PMONは、インスタンスおよびディスパッチャ・プロセスに関する情報をOracle Net Listenerに登録します(「Oracle Net Listener」を参照)。インスタンスの起動時に、PMONはリスナーに対してポーリングを実行し、リスナーが実行されているかどうかを確認します。リスナーが実行されている場合、PMONはリスナーに該当パラメータを渡します。実行されていない場合には、PMONは定期的にリスナーとの接続を試行します。

システム・モニター・プロセス(SMON)

システム・モニター・プロセス(SMON)は、システム・レベルで様々なクリーン・アップ作業を実行します。SMONには次のような役割があります。

- 必要に応じて、インスタンスの起動時に、インスタンス・リカバリを実行します。Oracle RACデータベースでは、障害の発生したインスタンスのインスタンス・リカバリを、データベース・インスタンスのSMONプロセスが実行できます。

- ファイル読取りまたは表領域オフライン・エラーが原因で、インスタンス・リカバリ時にスキップされた終了済トランザクションがリカバリされます。表領域またはファイルがオンラインに戻ると、SMONによってトランザクションがリカバリされます。

- 未使用の一時セグメントをクリーン・アップします。たとえば、Oracle Databaseでは、索引を作成するときにエクステントを割り当てます。この操作が失敗すると、SMONによって一時領域がクリーン・アップされます。

- ディクショナリ管理表領域内の、連続した空きエクステントを結合します。

SMONは、処理が必要かどうかを定期的にチェックします。他のプロセスは、必要性が検出された場合にSMONをコールできます。

データベース・ライター・プロセス(DBWn)

データベース・ライター・プロセス(DBWn)は、データベース・バッファの内容をデータファイルに書き込みます。DBWnプロセスは、データベース・バッファ・キャッシュ内の変更されたバッファをディスクに書き込みます(「データベース・バッファ・キャッシュ」を参照)。

ほとんどのシステムでは1つのデータベース・ライター・プロセス(DBW0)があれば十分ですが、追加プロセス(DBW1からDBW9およびDBWaからDBWj)を構成して、システムでデータを頻繁に変更する場合の書込みのパフォーマンスを改善できます。これらの追加DBWnプロセスは、ユニプロセッサ・システムでは効果がありません。

DBWnプロセスは、次のような場合に使用済バッファをディスクに書き込みます。

- サーバー・プロセスがしきい値の数までバッファをスキャンしても、クリーンな再利用可能バッファが見つからない場合は、DBWnに書込み信号が送られます。DBWnは、可能であれば、他の処理中に使用済バッファをディスクに非同期に書き込みます。

- DBWnは、定期的にバッファを書き込んで、REDOスレッド内のインスタンス・リカバリを開始する位置(チェックポイント)を進めます(「チェックポイントの概要」を参照)。チェックポイントのログ位置は、バッファ・キャッシュ内の最も古い使用済バッファ・キャッシュによって決まります。

多くの場合、DBWnによって書き込まれるブロックは、ディスク内に分散されます。このため、この書込みは、LGWRが実行する順次書込みよりも遅くなる傾向があります。効率を向上させるために、可能であればDBWnは、マルチブロック書込みを実行します。マルチブロック書込みで書き込まれるブロックの数は、オペレーティング・システムによって異なります。

関連項目:
DBWnの構成、監視およびチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

ログ・ライター・プロセス(LGWR)

ログ・ライター・プロセス(LGWR)では、REDOログ・バッファを管理します。LGWRは、バッファの連続した一部分をオンラインREDOログに書き込みます。データベース・バッファを変更するタスクを切り離すことによって、分散した使用済バッファのディスクへの書込み、およびREDOのディスクへの高速順次書込みの処理で、データベースのパフォーマンスが向上します。

次の状況では、LGWRは、最後の書込み以降にバッファにコピーされたREDOエントリすべてを、REDOログ・ファイルに書き込みます。

- ユーザーがトランザクションをコミットしたとき(「トランザクションのコミット」を参照)

- オンラインREDOログ・スイッチが発生したとき

- LGWRによる最後の書込みから3秒経過したとき

- REDOログ・バッファが3分の1になったとき、またはバッファ・データが1MBになったとき

- DBWnが修正済のバッファをディスクに書き込む必要があるとき
DBWnが使用済バッファを書き込むには、バッファの変更に関連するすべてのREDOレコードがディスクに書き込まれている必要があります(事前書込みプロトコル)。DBWnは、書き込まれていないREDOレコードがあることを検出すると、そのレコードをディスクに書き込むようにLGWRに信号を送り、LGWRの処理が完了するまで待機して、データ・バッファをディスクに書き込みます。

LGWRおよびコミット

Oracle Databaseは、コミットされたトランザクションのパフォーマンスを向上させるために、高速コミット・メカニズムを使用します。ユーザーがCOMMIT文を発行すると、トランザクションにシステム変更番号(SCN)が割り当てられます。LGWRはREDOログ・バッファ内にコミット・レコードを入れ、コミットSCNおよびトランザクションのREDOエントリとともにそれを即時にディスクに書き込みます。

REDOログ・バッファは循環バッファです。LGWRがREDOログ・バッファからオンラインREDOログ・ファイルにREDOエントリを書き込んだ後、サーバー・プロセスはディスクに書き込まれたREDOログ・バッファのエントリ上に新しいエントリをコピーできます。オンラインREDOログへのアクセスが頻繁なときにも、新しいエントリを書き込めるよう常にバッファ内の領域を空けておくため、LGWRが行う書込みは通常は非常に高速になります。

トランザクションのコミット・レコードを含むREDOエントリのアトミックな書込みは、トランザクションがコミットされたかどうかを判別する1つのイベントです。Oracle Databaseでは、データ・バッファがまだディスクに書き込まれていない場合でも、コミットしたトランザクションに対する成功コードが戻されます。対応するデータ・ブロックの変更は、DBWnがそれらの変更を効率的にデータファイルに書き込めるようになるまで延期されます。

注意:
LGWRでは、トランザクションがコミットする前に、REDOログ・エントリをディスクに書き込むことができます。後でトランザクションがコミットされた場合にのみ、REDOエントリにより保護された変更が確定します。

アクティビティが高いとき、LGWRはグループ・コミットを使用できます。たとえば、ユーザーがコミットし、これによって、LGWRがトランザクションのREDOエントリをディスクに書き込むとします。この書込み中、他のユーザーがコミットします。LGWRでは、前の書込みが完了するまで、これらのトランザクションをディスクに書き込んでコミットすることはできません。完了すると、LGWRは、(まだコミットされていない)待機しているトランザクションに関するREDOエントリのリストを1回の操作で書き込むことができます。これにより、データベースでは、ディスクI/Oが最小化され、パフォーマンスが最大化されます。コミットの要求が高い頻度で続くと、LGWRによる毎回の書込みに複数のコミット・レコードが含まれることがあります。

LGWRおよびアクセス不能ファイル

LGWRは、ミラー化されたアクティブなオンラインREDOログ・ファイルのグループにも同時に書き込みます。ログ・ファイルにアクセスできない場合、LGWRはグループ内の他のファイルに書込みを続け、LGWRトレース・ファイルおよびアラート・ログにエラーを書き込みます。グループ内のすべてのファイルが破損している場合や、アーカイブされていないためにグループ全体が使用できない場合、LGWRは機能を続行できません。

関連項目:

- 「Oracle DatabaseでのオンラインREDOログの書込み方法」および「REDOログ・バッファ」

- LGWRのパフォーマンスの監視およびチューニング方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

チェックポイント・プロセス(CKPT)

チェックポイント・プロセス(CKPT)は、チェックポイント情報により制御ファイルおよびデータファイル・ヘッダーを更新し、DBWnに対してブロックをディスクに書き込むように信号を送ります。チェックポイント情報には、チェックポイント位置、SCN、オンラインREDOログの中でリカバリを開始する位置などが含まれます。図15-4に示すように、CKPTではデータファイルへのデータ・ブロックの書込み、およびオンラインREDOログ・ファイルへのREDOブロックの書込みは行いません。

図15-4 チェックポイント・プロセス

関連項目:
「チェックポイントの概要」

管理性モニター・プロセス(MMONおよびMMNL)

管理性モニター・プロセス(MMON)は、自動ワークロード・リポジトリ(AWR)に関連する多数のタスクを実行します。たとえば、MMONはスナップショットを取得し、前回変更されたSQLオブジェクトの統計値を取得して、メトリックがそのしきい値を超えたときに書込みを行います。

管理性モニター・ライト・プロセス(MMNL)は、SGAのアクティブ・セッション履歴(ASH)バッファ内の統計をディスクに書き込みます。MMNLは、ASHバッファがいっぱいになるとディスクに書き込みます。

関連項目:
「自動ワークロード・リポジトリ(AWR)」および「アクティブ・セッション履歴(ASH)」

リカバラ・プロセス(RECO)

分散データベースでは、リカバラ・プロセス(RECO)によって、分散トランザクションに関連する障害が自動的に解決されます。ノードのRECOプロセスは、インダウト分散トランザクションにかかわる他のデータベースに自動的に接続されます。RECOでは、データベース間の接続を再確立するとき、すべてのインダウト・トランザクションを自動的に解決し、解決されるトランザクションに対応する行を各データベースの保留中のトランザクション表からすべて削除します。

関連項目:
分散トランザクション・リカバリの詳細は、『Oracle Database管理者ガイド』を参照してください。

オプションのバックグラウンド・プロセス

オプションのバックグラウンド・プロセスは、必須として定義されていないバックグラウンド・プロセスです。ほとんどのオプションのバックグラウンド・プロセスは、タスクまたは機能に固有です。たとえば、Oracle Streams Advanced Queuing(AQ)またはOracle Automatic Storage Management(Oracle ASM)をサポートするバックグラウンド・プロセスは、これらの機能が使用可能である場合にのみ使用できます。

この項では、いくつかの一般的なオプションのプロセスについて説明します。

- アーカイバ・プロセス(ARCn)

- ジョブ・キュー・プロセス(CJQ0およびJnnn)

- フラッシュバック・データ・アーカイバ・プロセス(FBDA)

- 領域管理コーディネータ・プロセス(SMCO)

関連項目:

- 「Oracle Streams Advanced Queuing(AQ)」

- AQおよびASMに固有のバックグラウンド・プロセスの詳細は、『Oracle Databaseリファレンス』を参照してください。

アーカイバ・プロセス(ARCn)

アーカイバ・プロセス(ARCn)は、REDOログ・スイッチが行われると、オンラインREDOログ・ファイルをオフライン・ストレージにコピーします。また、トランザクションのREDOデータを収集し、そのデータをスタンバイ・データベースの宛先に転送できます。ARCnプロセスは、データベースがARCHIVELOGモードに設定され、自動アーカイブが使用可能になっている場合にのみ存在します。

関連項目:

- 「アーカイブREDOログ・ファイル」

- アーカイバ・プロセス数の調整方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- アーカイバ・パフォーマンスのチューニング方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

ジョブ・キュー・プロセス(CJQ0およびJnnn)

Oracle Databaseでは、ジョブ・キュー・プロセスを使用して、多くの場合、バッチ・モードでユーザー・ジョブを実行します。ジョブは、1回以上実行することがスケジュールされている、ユーザー定義タスクです。たとえば、ジョブ・キューを使用して、バックグラウンドで長時間実行される更新をスケジュールできます。開始日と時間間隔を指定すると、ジョブ・キュー・プロセスは、指定された間隔でジョブの実行を試行します。

Oracle Databaseではジョブ・キュー・プロセスが動的に管理されるため、ジョブ・キュー・クライアントは、必要に応じてより多くのジョブ・キュー・プロセスを使用できます。新規プロセスが使用するリソースは、そのプロセスがアイドル状態になると解放されます。

動的ジョブ・キュー・プロセスは、指定された間隔で多数のジョブを同時に実行できます。イベントの順序は、次のようになります。

1. ジョブ・コーディネータ・プロセス(CJQ0)は、Oracle Schedulerの必要に応じて、自動的に起動し、停止します(「Oracle Scheduler」を参照)。コーディネータ・プロセスは、システムのJOB$表から、実行する必要があるジョブを定期的に選択します。選択された新規ジョブは、時間順に並べ替えられます。

2. コーディネータ・プロセスは、ジョブを実行するためにジョブ・キュー・スレーブ・プロセス(Jnnn)を動的に生成します。

3. ジョブ・キュー・プロセスは、実行のためにCJQ0プロセスによって選択されたジョブの1つを実行します。ジョブ・キュー・プロセスは、一度に1つずつジョブを実行して完了します。

4. ジョブ・キュー・プロセスは、1つのジョブの実行が終了すると、次のジョブの問合せを行います。実行予定のジョブが存在しない場合、ジョブ・キュー・プロセスはスリープ状態に入り、定期的な周期で起動すると次のジョブの問合せを行います。新しいジョブがない場合、事前に設定した周期が経過した後に終了します。

初期化パラメータJOB_QUEUE_PROCESSESは、1つのインスタンスで同時に実行できるジョブ・キュー・プロセスの最大数を示します。ただし、クライアントは、すべてのジョブ・キュー・プロセスがジョブの実行に使用可能であると想定することはできません。

注意:
初期化パラメータJOB_QUEUE_PROCESSESが0(ゼロ)に設定されている場合、コーディネータ・プロセスは起動しません。

関連項目:

- Oracle Schedulerジョブの詳細は、『Oracle Database管理者ガイド』を参照してください。

- AQバックグラウンド・プロセスの詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。

フラッシュバック・データ・アーカイバ・プロセス(FBDA)

フラッシュバック・データ・アーカイバ・プロセス(FBDA)は、フラッシュバック・データ・アーカイブに追跡した表の履歴行をアーカイブします。追跡した表に対するDMLを含むトランザクションがコミットされると、このプロセスは、行の事前イメージをフラッシュバック・データ・アーカイブに保存します。また、現在の行にメタデータを保存します。

FBDAは、フラッシュバック・データ・アーカイブの領域、編成および保存に関する管理を自動的に行います。また、追跡対象トランザクションのアーカイブがどの程度発生するかを追跡します。

領域管理コーディネータ・プロセス(SMCO)

SMCOプロセスは、予防的な領域の割当ておよび領域の再生など、様々な領域管理関連タスクの実行を調整します。SMCOにより、自動的にスレーブ・プロセス(Wnnn)が起動され、タスクが実行されます。

関連項目:
フラッシュバック・データ・アーカイブの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

スレーブ・プロセス

スレーブ・プロセスは、他のプロセスにかわって作業を実行するバックグラウンド・プロセスです。この項では、Oracle Databaseが使用するスレーブ・プロセスの一部について説明します。

関連項目:
Oracle Databaseのスレーブ・プロセスの詳細は、『Oracle Databaseリファレンス』を参照してください。

I/Oスレーブ・プロセス

I/Oスレーブ・プロセス(Innn)は、非同期I/Oがサポートされていないシステムおよびデバイスにかわって、非同期I/Oをシミュレートします。非同期I/Oの場合、伝送のためのタイミング要件がないため、伝送が終了する前に他のプロセスを起動できます。

たとえば、非同期I/Oがサポートされていないオペレーティング・システムのディスクに、アプリケーションが1000ブロックを書き込むとします。それぞれの書込みは順次実行され、書込みの完了確認まで待機します。非同期ディスクの場合、アプリケーションは一括でブロックを書き込み、すべてのブロックが書き込まれたというオペレーティング・システムからのレスポンスを待機している間、他の作業を実行できます。

非同期I/Oをシミュレートするには、1プロセスがいくつかのスレーブ・プロセスを監視します。実行者プロセスでは、それぞれの書込みの完了報告を待機し、完了時にそれを実行者に転送する各スレーブ・プロセスに作業を割り当てます。真の非同期I/Oでは、オペレーティング・システムがI/Oの完了と、その報告のプロセスへの転送を待機しますが、シミュレートされた非同期I/Oの場合、スレーブが完了報告を待機し、実行者へそれを転送します。

Oracle Databaseでは、次のような様々なタイプのI/Oスレーブがサポートされています。

- Recovery Manager(RMAN)のI/Oスレーブ
データのバックアップまたはリストアにRMANを使用するとき、ディスクおよびテープ・デバイスにI/Oスレーブを使用できます。

- データベース・ライター・スレーブ
複数のデータベース・ライター・プロセスを使用することが現実的でない場合、たとえば、コンピュータのCPUが1つのみである場合、Oracle Databaseは、複数のスレーブ・プロセスにI/Oを分散できます。DBWRは、ディスクへのブロックの書込みを可能にするため、バッファ・キャッシュLRUリストをスキャンする唯一のプロセスです。ただし、I/Oスレーブは、これらのブロックに対するI/Oを実行します。

関連項目:

- I/Oスレーブのバックアップおよびリストア操作の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- データベース・ライター・スレーブの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

パラレル問合せスレーブ

パラレル実行またはパラレル処理では、同時に多数のプロセスが連携して1つのSQL文を実行します。複数プロセス内で作業を分割すると、Oracle Databaseでは、より迅速にSQL文を実行できます。たとえば、1つのプロセスで4つの四半期分をすべて処理するのではなく、4つのプロセスが1年のそれぞれの四半期を分担して処理するなどがこの例です。

パラレル実行では、データ・ウェアハウスなどの大規模データベースでの、データ処理集中型の操作におけるレスポンス時間が短縮されます。対称型マルチプロセッサ(SMP)およびクラスタ化されたシステムでは、文の処理を多数のCPUに分割できるため、パラレル実行によりパフォーマンスが大幅に改善されます。パラレル実行は、特定のタイプのOLTPおよびハイブリッド・システムにとっても利点があります。

Oracle RACシステムでは、特定のサービスに対するサービスの配置によって、パラレル実行が制御されています。つまり、パラレル・プロセスはサービスを構成したノードで実行されます。デフォルトで、Oracle Databaseはデータベースに接続するときに使用されるサービスを提供するインスタンスでのみ、パラレル処理を実行します。これは、パラレル・リカバリやGV$問合せの処理などの他のパラレル操作には影響しません。

関連項目:

- パラレル実行の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』および『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- Oracle RAC環境でのパラレル実行に関する考慮事項については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

シリアル実行

シリアル実行の場合、SQL文の順次実行に必要な処理のすべてを1つのサーバー・プロセスが実行します。たとえば、SELECT * FROM employeesなどの全表スキャンを実行するには、図15-5に示すように、1つのサーバー・プロセスですべての処理が実行されます。

図15-5 シリアルの全表スキャン

パラレル実行

パラレル実行の場合、サーバー・プロセスは、問合せの解析、スレーブ・プロセスの割当てと制御、およびユーザーへの出力送信を行うパラレル実行コーディネータの役割を果します。SQL問合せの問合せ計画では、まずコーディネータがSQL問合せ内の各演算子をパラレル・ピースに分割し、それらを問合せで指定した順序に従って実行し、その後、演算子を実行するスレーブ・プロセスによって作成された部分的な実行結果を統合します。

図15-6に、employees表のパラレル・スキャンを示します。この表は、グラニュルと呼ばれるロード単位に動的に分割されます(動的パーティション化)。各グラニュルは、パラレル実行サーバーと呼ばれる、単一のスレーブ・プロセスによって読み取られる表のデータ・ブロックの範囲で、その名前の形式はPnnnです。

図15-6 パラレルの全表スキャン

データベースでは、実行時にグラニュルを実行サーバーにマップします。実行サーバーがグラニュルに対応する行の読取りを終了したとき、グラニュルがまだ残っている場合、コーディネータから他のグラニュルを取得します。この操作は、表全体が読み取られるまで続行されます。実行サーバーは結果をコーディネータに送り返し、それぞれの結果が組み立てられて、最終的な全表スキャンになります。

1つの操作に割り当てられたパラレル実行サーバーの数が、その操作の並列度となります。同じSQL文中の複数の操作の並列度は、すべて同じです。

関連項目:

- パラレル実行の使用方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- 推奨の並列性初期化パラメータについては、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

16 アプリケーションおよびネットワークのアーキテクチャ

この章では、アプリケーション・アーキテクチャについて定義し、分散処理環境でOracleデータベースとデータベースのアプリケーションがどのように機能するかを説明します。このマニュアルの内容は、ほとんどすべてのタイプのOracle Database環境に適用されます。

この章の内容は、次のとおりです。

- Oracleアプリケーション・アーキテクチャの概要

- Oracleネットワーク・アーキテクチャの概要

- プログラム・インタフェースの概要

Oracleアプリケーション・アーキテクチャの概要

この章では、アプリケーション・アーキテクチャは、データベース・アプリケーションがOracleデータベースに接続するコンピューティング環境を示します。

クライアント/サーバー・アーキテクチャの概要

Oracle Database環境では、データベース・アプリケーションとデータベースはクライアント/サーバー・アーキテクチャに分割されます。

- クライアントでは、データベース情報にアクセスし、ユーザーと対話するデータベース・アプリケーション(SQL*Plus、Visual Basicデータ入力プログラムなど)が実行されます。

- サーバーでは、Oracle Databaseソフトウェアが実行され、Oracleデータベースへの同時実行の共有データ・アクセスに必要な機能が処理されます。

クライアント・アプリケーションとデータベースを同じコンピュータで実行することもできますが、クライアント部分とサーバー部分を別々のコンピュータで実行し、それらのコンピュータをネットワークで接続する方がさらに効率的です。次の各項では、Oracle Databaseクライアント/サーバー・アーキテクチャの様々な形態について説明します。

分散処理

複数ホストを使用した個別タスクの処理は、分散処理と呼ばれます。フロントエンド処理とバックエンド処理は異なるコンピュータ上で実行されます。図16-1では、クライアントとサーバーが異なるホストに配置され、Oracle Net Servicesを介して接続されています。

図16-1 クライアント/サーバー・アーキテクチャと分散処理

図16-2に、様々な分散データベースを示します。この例では、あるホスト上のデータベースが、異なるホスト上の別のデータベースにアクセスしています。

図16-2 クライアント/サーバー・アーキテクチャと分散データベース

注意:
この章の以降の内容は、1つのサーバー上に1つのデータベースがある環境に適用されます。

クライアント/サーバー・アーキテクチャの利点

分散処理環境でのOracle Databaseクライアント/サーバー・アーキテクチャには、次のような利点があります。

- クライアント・アプリケーションではデータ処理は実行されません。そのかわり、クライアント・アプリケーションは、ユーザーに入力をリクエストし、必要なデータをサーバーにリクエストし、そのデータを分析してクライアント・ワークステーションまたは端末の表示機能(グラフィックスやスプレッドシート)を使用して表示します。

- クライアント・アプリケーションはデータの物理的な位置に依存しません。データを他のデータベース・サーバーに移動したり分散しても、アプリケーションはほとんど、またはまったく変更することなく、機能を続行できます。

- Oracle Databaseでは、基礎となるオペレーティング・システムのマルチタスキング機能と共有メモリー機能を活用できます。その結果、クライアント・アプリケーションに最高度の同時実行性、データ整合性およびパフォーマンスが提供されます。

- クライアント・ワークステーションや端末はデータの表示用に最適化でき(グラフィックスやマウスのサポート提供など)、サーバーはデータの処理と格納用に最適化できます(大容量のメモリーとディスク領域の搭載など)。

- ネットワーク化された環境では、安価なクライアント・ワークステーションを使用して、サーバーのリモート・データに効率的にアクセスできます。

- データベースは、システムの拡張とともにスケーリングできます。複数のサーバーを追加して、データベース処理の負荷をネットワーク全体に分散することや(水平スケール)、データベースをミニコンピュータやメインフレームなどに移動して、より大規模なシステムのパフォーマンス上の利点を活用(垂直スケール)することができます。どちらの場合も、Oracle Databaseにはシステム間での移植性があるため、データとアプリケーションをほとんど、またはまったく変更することなく維持できます。

- ネットワーク化された環境の場合、共有データは、すべてのコンピュータに格納されるのではなく、サーバーに格納されます。これにより、同時アクセスの管理が簡略化され、効率的になります。

- ネットワーク化された環境では、クライアント・アプリケーションからサーバーにデータベース・リクエストを送るときにSQL文を使用できます。サーバーが受け取ったSQL文はそのサーバーで処理され、その結果がクライアントに戻されます。ネットワークを介してやりとりされるのはリクエストと結果のみであるため、ネットワーク通信量は最小限ですみます。

関連項目:
分散データベースの詳細は、『Oracle Database管理者ガイド』を参照してください。

複数層アーキテクチャの概要

従来の複数層アーキテクチャ環境では、アプリケーション・サーバーはクライアントにデータを提供し、クライアントとデータベース・サーバー間のインタフェースとして機能します。このアーキテクチャでは、アプリケーション・サーバーを使用して次のことを実行できます。

- Webブラウザなど、クライアントの資格証明の検証

- データベース・サーバーへの接続

- リクエストされた操作の実行

図16-3は、複数層アーキテクチャの例を示しています。

図16-3 複数層アーキテクチャ環境

クライアント

クライアントは、データベース・サーバー上で実行される操作についてリクエストを出します。このクライアントは、Webブラウザでも他のエンド・ユーザー・プログラムでもかまいません。複数層アーキテクチャでは、クライアントは1つ以上のアプリケーション・サーバーを介してデータベース・サーバーに接続します。

アプリケーション・サーバー

アプリケーション・サーバーは、クライアントにデータ・アクセスを提供します。また、クライアントと、1つ以上のデータベース・サーバーとの間のインタフェースとして機能し、アプリケーションをホスティングします。

アプリケーション・サーバーでは、最小限のソフトウェア構成を備えたクライアントである、Thinクライアントから、クライアントの継続的なメンテナンスを必要とせずにアプリケーションにアクセスできます。また、アプリケーション・サーバーでは、クライアント用にデータを再フォーマットし、クライアント・ワークステーションの負荷を軽減できます。

アプリケーション・サーバーは、クライアントのためにデータベース・サーバー上で操作を実行するとき、そのクライアントの識別を想定します。アプリケーション・サーバーの権限は、クライアント操作中に不要な操作や望ましくない操作を実行できないように制限する必要があります。

データベース・サーバー

データベース・サーバーは、クライアントにかわってアプリケーション・サーバーからリクエストされたデータを提供します。すべての問合せ処理は、データベースによって実行されます。

データベース・サーバーは、クライアントのかわりにアプリケーション・サーバーが実行した操作や、アプリケーション・サーバー自体のために実行する操作を監査できます(「監視」を参照)。たとえば、クライアント操作はクライアントに表示する情報をリクエストでき、アプリケーション・サーバー操作はデータベース・サーバーに接続をリクエストできます。

サービス指向アーキテクチャ(SOA)

データベースは、従来の複数層またはサービス指向アーキテクチャ(SOA)環境でWebサービス・プロバイダとして機能できるようになりました。SOAはネットワーク上にあるコンピュータ間での相互作用をサポートするサービスに依存する、複数層アーキテクチャです。サービスは動的に検出することが可能であり、使用可能な関数およびコール・シーケンスで問い合せることもできます。

通常、SOAサービスはHTTPプロトコルを介してアクセスできるWebサービスとして実装されます。これらのサービスは、WSDLやSOAPなどのXML標準に基づいています。

XML DBの一部として実装されるOracle DatabaseのWebサービス機能は、DBAが明示的に有効化する必要があります。アプリケーションは、データベースWebサービスを介して次のことを実行できます。

- SQLまたはXQuery問合せの発行およびXMLでの結果の受信

- スタンドアロンPL/SQLファンクションの起動および結果の受信(「PL/SQLサブプログラム」を参照)

- PL/SQLパッケージ・ファンクションの起動および結果の受信

データベースWebサービスを使用すると、アプリケーション・サーバーがなくても、アプリケーション環境に簡単にWebサービスを追加できます。ただし、Oracle Fusion Middlewareなどのアプリケーション・サーバーを介してWebサービスを起動すると、SOA環境で、セキュリティ、スケーラビリティ、UDDI登録および信頼できるメッセージ機能の面でさらに利点があります。ただし、データベースWebサービスはOracle Fusion Middlewareと簡単に統合できるため、SOAソリューションの最適化に適しています。

関連項目:

- データベースWebサービスを有効化する方法および使用方法の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

- SOAおよびWebサービスの詳細は、Oracle Fusion Middlewareのマニュアルを参照してください。

グリッド・アーキテクチャの概要

Oracle Database環境では、グリッド・コンピューティングは、柔軟なオンデマンド・コンピューティング・リソースに多くのサーバーおよび記憶域を効率的にプールするコンピューティング・アーキテクチャです。ビジネスのニーズの変化に対応して、必要であればモジュール化したハードウェアおよびソフトウェア・コンポーネントのグループを接続および再結合できます。

関連項目:
サーバーおよび記憶域グリッドの詳細は、「グリッド・コンピューティングの概要」を参照してください。

Oracleネットワーク・アーキテクチャの概要

Oracle Net Servicesは分散した、異機種間コンピューティング環境において、企業全体の接続性を確保する一連のネットワーク・コンポーネントです。Oracle Net Servicesを使用すると、アプリケーションからデータベース・インスタンスへ、およびデータベース・インスタンスから別のデータベース・インスタンスへのネットワーク・セッションを確立できます。

Oracle Net Servicesにより、位置の透過性、構成と管理の一元化および迅速なインストールと構成が実現されます。また、システム・リソースの最大化とパフォーマンスの改善が可能です。Oracle Databaseの共有サーバー・アーキテクチャでは、アプリケーションのスケーラビリティが向上し、データベースへのクライアントの同時接続数が増加します。Virtual Interface(VI)プロトコルは、メッセージ機能の負荷のほとんどを高速ネットワーク・ハードウェアに負わせることによって、CPUを解放します。

Oracle Net Servicesは、広範囲のネットワークでサポートされている通信プロトコルやApplication Program Interface(API)を使用して、分散データベースと分散処理の機能を提供します。ネットワーク・セッションの確立後、Oracle Net Servicesは、接続を確立してメッセージを交換することによって、クライアント・アプリケーションとデータベース・サーバーのためのデータ伝達手段として機能します。Oracle Net Servicesはネットワーク内の各コンピュータに配置されているため、これらのタスクを実行できます。

関連項目:
Oracle Netアーキテクチャの概要は、『Oracle Database Net Services管理者ガイド』を参照してください。

Oracle Net Servicesの動作

Oracle Databaseプロトコルでは、OracleアプリケーションのインタフェースからSQL文を取り出し、それらをパッケージ化してから、サポートされている業界標準の高レベルのプロトコルまたはAPIを介してOracle Databaseに送信します。Oracle Databaseからの応答は、同じ高レベルの通信メカニズムを介してパッケージ化されます。これらの処理はネットワーク・オペレーティング・システムからは独立して実行されます。

Oracle Databaseを実行するオペレーティング・システムによっては、データベース・サーバーのOracle Net Servicesソフトウェアにドライバ・ソフトウェアが含まれており、ドライバ・ソフトウェアによって追加のバックグラウンド・プロセスが起動される場合があります。

関連項目:
Oracle Net Servicesの動作の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

Oracle Net Listener

Oracle Net Listener(リスナーとも呼ばれる)は、受信するクライアント接続リクエストをリスニングし、データベースへのトラフィックを管理する、サーバー側のプロセスです。 データベース・インスタンスの起動時、および起動中の様々なタイミングで、インスタンスはリスナーに接続してそのインスタンスへの接続経路を確立します。

サービス登録により、リスナーは、データベース・サービスおよびそのサービス・ハンドラが使用可能かどうかを判断できます。サービス・ハンドラは、データベースへの接続ポイントとなる、ディスパッチャまたは専用サーバー・プロセスです。登録時に、PMONプロセスは、インスタンス名、データベース・サービス名、およびサービス・ハンドラのタイプとアドレスをリスナーに提供します。リスナーは、この情報を使用することにより、クライアント・リクエストの受信時にサービス・ハンドラを起動できます。

図16-4に、異なるホスト上にある2つのデータベースを示します。このデータ環境は、異なるホスト上にある2つのリスナーが対応しています。各データベース・インスタンスで実行されているPMONプロセスは、両方のリスナーと通信してデータベースを登録します。

図16-4は、ブラウザによるHTTP接続の実行と、クライアントによるリスナーを介したデータベース接続の実行を示します。このリスナーは、データベース・ホストに常駐する必要はありません。

図16-4 リスナー・アーキテクチャ

クライアントがリスナーを経由して接続を確立する基本ステップを次に示します。

1. クライアント・プロセスまたは別のデータベースが接続をリクエストします。

2. リスナーは、クライアント・リクエストの処理に適したサービス・ハンドラを選択し、そのリクエストをハンドラに送ります。

3. クライアント・プロセスは、サービス・ハンドラに直接接続します。リスナーは通信には関わりません。

関連項目:
「クライアント・プロセスの概要」および「サーバー・プロセスの概要」

サービス名

Net Servicesでは、サービスとは、1つ以上のデータベース・インスタンスの集合です。サービス名とは、クライアント接続に使用するサービスの論理表現です。

クライアントは、リスナーに接続するときにサービスへの接続をリクエストします。データベース・インスタンスは、起動時にインスタンス自体をリスナーに登録し、1つ以上のサービスとして名前で指定できるようになります。このようにして、リスナーはクライアントとインスタンスとの間の仲介役を果たし、接続リクエストを適切な場所に渡します。

各サービスは、リスナーを介して、1つ以上のデータベース・インスタンスを識別できます。また、各データベース・インスタンスは、1つ以上のサービスをリスナーに登録できます。サービスに接続するクライアントは、必要なインスタンスを指定する必要がありません。

図16-5は、book.example.comとsoft.example.comの2つのサービスに関連付けられた1つの単一インスタンス・データベースを示します。これらのサービスにより、同じデータベースを異なるクライアントが個別に識別できるようになります。データベース管理者はシステム・リソースを制限または確保できるため、これらのサービスの1つをリクエストするクライアントに対してリソースをより効率的に割り当てることができます。

図16-5 1つのデータベースに関連付けられた複数のサービス

関連項目:
ネーミング・メソッドの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

サービス登録

サービス登録とは、PMONプロセスがインスタンス情報を動的にリスナーに登録するために使用する機能であり、この機能によって、リスナーがクライアント接続リクエストを適切なサービス・ハンドラに送ることができます。PMONによって、次の情報がリスナーに提供されます。

- データベースによって提供された、データベース・サービスの名前

- サービスと関連付けられたデータベース・インスタンスの名前、およびそのインスタンスの現在の負荷と最大負荷

- インスタンスから使用可能なサービス・ハンドラ(ディスパッチャおよび専用サーバー)とそのタイプ、プロトコル・アドレスおよび現在の負荷と最大負荷

サービス登録は動的であり、listener.oraファイルでの構成は必要ありません。動的登録により、複数のデータベースやインスタンスの管理に伴うオーバーヘッドが低減します。

初期化パラメータSERVICE_NAMESでは、インスタンスが属するサービスを示します。起動時に、各インスタンスは、同じサービスに属している他のインスタンスのリスナーに登録します。データベース操作中に、各サービスのインスタンスはCPUの使用と現行の接続カウントに関する情報を、同じサービスのすべてのリスナーに渡します。この通信により、動的なロード・バランシング機能と接続フェイルオーバー機能が使用可能になります。

関連項目:

- 「プロセス・モニター・プロセス(PMON)」

- サービス登録の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- Oracle RACでのインスタンス登録およびクライアント/サービス接続の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

専用サーバー・アーキテクチャ

専用サーバー・アーキテクチャでは、各クライアント・プロセスのかわりとして作成されたサーバー・プロセスは専用サーバー・プロセス(またはシャドウ・プロセス)と呼ばれます。図16-6に示すように、このサーバー・プロセスはクライアント・プロセスとは別のものであり、クライアント・プロセスのかわりとしてのみ動作します。

図16-6 Oracle Databaseでの専用サーバー・プロセスの使用

クライアント・プロセスとサーバー・プロセスの比率は1対1です。ユーザーが活発にデータベース・リクエストをしていない場合でも、専用サーバー・プロセスはそのまま残ります(ただし、アクティブでない状態の場合、オペレーティング・システムによっては、ページアウトされることもあります)。

図16-6には、ユーザー・プロセスとサーバー・プロセスが、ネットワーク接続された複数のコンピュータで実行されている状態を示しています。専用サーバー・アーキテクチャは、同じコンピュータ上でクライアント・アプリケーションとデータベース・コードの両方が実行される場合にも使用されますが、この2つのプログラムが1つのプロセスで実行されている場合は、ホスト・オペレーティング・システムはその2つの分離を維持できません。Linuxはそのようなオペレーティング・システムの一例です。

専用サーバー・アーキテクチャでは、ユーザー・プロセスとサーバー・プロセスは異なるメカニズムを使用して通信します。

- クライアント・プロセスと専用サーバー・プロセスが同じコンピュータで実行される場合、プログラム・インタフェースは、ホスト・オペレーティング・システムのプロセス間通信メカニズムを使用してジョブを実行します。

- クライアント・プロセスと専用サーバー・プロセスを別々のコンピュータで実行する場合は、プログラム・インタフェースがプログラム間の通信メカニズム(ネットワーク・ソフトウェアやOracle Net Servicesなど)を提供します。

専用サーバーを十分に活用しない場合は、オペレーティング・システムを効率的に使用できなくなることがあります。専用サーバー・プロセスによる注文入力システムの例を考えてみます。顧客から注文が入り、事務担当がデータベースにその注文を入力します。トランザクションの大部分では、事務担当が顧客と話し合っており、事務担当のクライアント・プロセス専用のサーバー・プロセスはアイドル状態になっています。サーバー・プロセスは、トランザクションの大部分で不要であり、管理されているプロセスが多数ある場合、他の事務担当が注文を入力するとき、システムの処理速度は遅くなることがあります。このようなタイプのアプリケーションでは、共有サーバー・アーキテクチャを選択してください。

関連項目:
専用サーバー・プロセスの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

共有サーバー・アーキテクチャ

共有サーバー・アーキテクチャでは、複数の受信ネットワーク・セッション・リクエストがディスパッチャによって共有サーバー・プロセスのプールに送られることにより、各接続に対する専用サーバー・プロセスが不要になります。プールにあるアイドル状態の共有サーバー・プロセスは、共通キューからリクエストをピックアップします。

共有サーバーには、次のような潜在的な利点があります。

- オペレーティング・システム上のプロセス数の削減
少数の共有サーバーで、多数の専用サーバーと同じ量の処理を実行できます。

- インスタンスPGAメモリーの削減
すべての専用サーバーおよび共有サーバーにはPGAがあります。サーバー・プロセスの数が減少すると、PGAおよびプロセス管理も減少します。

- アプリケーションのスケーラビリティ向上、およびデータベースに同時に接続できるクライアントの数の増加

- クライアントの接続と切断の比率が高いときに専用サーバーより高速である可能性の高さ

共有サーバーには、特定のケースにおけるレスポンス時間の長さ、機能の不完全なサポート、および設定やチューニングの複雑化などのデメリットがあります。一般的な目安としては、データベースへの同時接続数がオペレーティング・システムで処理可能な数を超える場合にのみ、共有サーバーを使用してください。

共有サーバー・アーキテクチャでは、次のプロセスが必要となります。

- クライアント・プロセスをディスパッチャまたは専用サーバーに接続するネットワーク・リスナー(リスナー・プロセスは、Oracle DatabaseではなくOracle Net Servicesの一部)

注意:
共有サーバーを使用する際は、クライアント・プロセスは、Oracleデータベース・インスタンスと同一のコンピュータで実行されている場合でも、Oracle Net Servicesを介して接続する必要があります。

- 1つ以上のディスパッチャ・プロセス(Dnnn)

- 1つ以上の共有サーバー・プロセス

データベースは、共有サーバー接続と専用サーバー接続の両方を同時にサポートできます。たとえば、1つのクライアントが専用サーバーを使用してデータベースに接続すると同時に、別のクライアントが共有サーバーを使用して同じデータベースに接続できます。

関連項目:

- 共有サーバー・アーキテクチャの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- 共有サーバーを使用するためのデータベースの構成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

ディスパッチャのリクエスト・キューとレスポンス・キュー

ユーザーからのリクエストは、ユーザーのSQL文の一部である単一のAPIコールです。ユーザーがコールを実行すると、次のアクションが発生します。

1. ディスパッチャがリクエストをリクエスト・キューに入れ、次に使用可能な共有サーバー・プロセスがそこからリクエストを取り出します。
リクエスト・キューはSGA内に存在し、インスタンスのディスパッチャ・プロセスすべてに共通です(「ラージ・プール」を参照)。

2. 共有サーバー・プロセスは、共通のリクエスト・キューをチェックして新しいリクエストがないかどうかを調べ、先入れ先出し方式に基づいて新しいリクエストをピックアップします。

3. 1つの共有サーバー・プロセスがキュー内のリクエストを1つピックアップし、そのリクエストを完了するのに必要なデータベースに対するコールをすべて出します。
各データベース・コールは異なるサーバー・プロセスが処理できます。このため、問合せの解析、最初の行のフェッチ、次の行のフェッチ、および結果セットのクローズそれぞれのリクエストは、別の共有サーバーが処理できます。

4. サーバー・プロセスはリクエストを完了すると、コール・ディスパッチャのレスポンス・キューに応答を入れます。各ディスパッチャには、固有のレスポンス・キューがあります。

5. ディスパッチャは、完了したリクエストを適切なクライアント・プロセスに戻します。

たとえば、注文入力システムで、各事務担当のクライアント・プロセスがディスパッチャに接続します。事務担当によって作成されたそれぞれのリクエストはこのディスパッチャに送られ、ディスパッチャがリクエストをキューに入れます。次に使用可能な共有サーバーは、リクエストをピックアップして処理し、レスポンス・キューにレスポンスを入れます。リクエストが完了しても、事務担当はディスパッチャに接続されたままですが、そのリクエストを処理した共有サーバーは解放されるため、別のリクエストで使用できます。1人の事務担当が顧客と話し合っている間に、別の事務担当は同じ共有サーバー・プロセスを使用できます。

図16-7に、クライアント・プロセスがAPIを介してディスパッチャと通信する方法と、ディスパッチャがユーザー・リクエストを共有サーバー・プロセスに伝達する方法を示します。

図16-7 共有サーバー構成とプロセス

ディスパッチャ・プロセス(Dnnn)

ディスパッチャ・プロセスは、クライアント・プロセスが限定された数のサーバー・プロセスを共有できるようにします。1つのデータベース・インスタンスに対し、複数のディスパッチャ・プロセスを作成できます。ディスパッチャの最適な数は、オペレーティング・システムの制限事項と各プロセスの接続数に応じて異なります。

注意:
ディスパッチャに接続する各クライアント・プロセスは、両方のプロセスが同じホスト上で実行される場合でも、Oracle Net Servicesを使用する必要があります。

ディスパッチャ・プロセスは次のように通信を確立します。

1. インスタンスが起動されると、ネットワーク・リスナー・プロセスは、ユーザーがOracle Databaseへの接続に使用する通信経路をオープンして確立します。

2. 各ディスパッチャ・プロセスは、接続リクエストをリスニングするアドレスをリスナー・プロセスに割り当てます。
データベース・クライアントで使用するネットワーク・プロトコルごとに、最低1つ以上のディスパッチャ・プロセスを構成し起動する必要があります。

3. クライアント・プロセスが接続をリクエストすると、リスナーはそのクライアント・プロセスが共有サーバー・プロセスを使用する必要があるかどうかを判断します。

- 共有サーバーが必要であるとリスナーが判断した場合、リスナーは負荷が最も軽いディスパッチャ・プロセスのアドレスを戻し、クライアント・プロセスはディスパッチャに直接接続します。

- プロセスがディスパッチャと通信できない場合、またはクライアント・プロセスが専用サーバーをリクエストする場合には、リスナーは専用サーバーを作成して適切な接続を確立します。

関連項目:
ディスパッチャの構成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

共有サーバー・プロセス(Snnn)

共有サーバー構成では、各共有サーバー・プロセスは複数のクライアント・リクエストを処理します。共有サーバー・プロセスには専用サーバー・プロセスと同じ機能がありますが、特定のクライアント・プロセスと関連付けられていません。共有サーバー・プロセスは、共有サーバー構成におけるクライアント・リクエストに対してサービスを提供します。

共有サーバー・プロセスのPGAには、(すべての共有サーバー・プロセスからアクセス可能であることが必要な)UGAデータは含まれません(「プログラム・グローバル領域の概要」を参照)。共有サーバーのPGAには、プロセス固有のデータのみが含まれています。

セッション関連の情報はすべてSGA内に入れられます。各共有サーバー・プロセスは、サーバーがどのセッションからのリクエストでも処理できるように、すべてのセッションのデータ領域にアクセスできる必要があります。セッションのデータ領域ごとに、SGA内に領域が割り当てられます。

共有サーバーの限定的運用

インスタンスの停止、インスタンスの起動、およびメディア・リカバリを含む、特定の管理アクティビティは、ディスパッチャ・プロセスに接続されている間は実行できません。これらのアクティビティは、一般的には管理者権限を使用して接続しているときに実行されます。共有サーバーにより構成されたシステムで管理者権限を使用して接続する場合は、専用サーバー・プロセスを使用することを指定する必要があります。

関連項目:
正しい接続文字の構文は、『Oracle Database Net Services管理者ガイド』を参照してください。

データベース常駐接続プーリング

データベース常駐接続プーリング(DRCP)は、一般的なWebアプリケーション使用のシナリオにおいて、専用サーバーの接続プールを提供します。通常、Webアプリケーションは、データベースへの接続を取得し、その接続を短時間使用した後、接続を解放します。DRCPを使用すると、データベースは同時接続数を数万にまで増やすことができます。

DRCPには、次の利点があります。

- 中間層プロセス内のスレッド間で接続を共有する、中間層接続プールを補完します。

- 複数の中間層プロセスにわたってデータベース接続を共有できるようにします。これらの中間層プロセスは、中間層ホストが同一の場合と異なる場合があります。

- 多数のクライアント接続のサポートに必要な、主要データベース・リソースを大幅に削減できます。たとえば、DRCPは、データベースに必要なメモリーの量を削減し、データベースと中間層の両方のスケーラビリティを向上させます。利用可能なサーバーのプールにより、クライアント接続を再作成するコストも削減されます。

- 中間層接続プーリングを実行できないPHPやApacheサーバーなど、マルチ・プロセスのシングルスレッド・アプリケーション・サーバーを含むアーキテクチャでプーリングが実行できるようになります。

DRCPでは、プールされたサーバーを使用し、専用サーバー・プロセス(共有サーバー・プロセスではない)とデータベース・セッションを組み合せたものと同じ機能を実現します。プールされたサーバー・モデルは、短時間だけサーバーを必要とする接続のすべてに専用サーバーを割り当てることによるオーバーヘッドを排除します。

データベース常駐接続プールから接続を取得したクライアントは、接続ブローカと呼ばれるOracleバックグラウンド・プロセスに接続します。接続ブローカはプール機能を実装しており、プールされたサーバーをクライアント・プロセスからのインバウンド接続間で多重化します。

図16-8に示すように、クライアントがデータベース・アクセスをリクエストすると、接続ブローカがプールから、サーバー・プロセスを選択してクライアントに渡します。クライアントは、リクエストが処理されるまで、サーバー・プロセスに直接接続します。サーバーでの処理が終了すると、サーバー・プロセスはプールに戻されます。クライアントからの接続はブローカにリストアされます。

図16-8 DRCP

DRCPでは、リソースを解放しても、セッションはそのまま残されますが、接続(サーバー・プロセス)との関連付けは失われます。共有サーバーとは異なり、このセッションではそのUGAをSGAではなくPGAに格納します。クライアントは、検出アクティビティを実行するとき、接続を透過的に再確立できます。

関連項目:

- 「接続とセッション」

- DRCPの詳細は、『Oracle Database管理者ガイド』および『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

プログラム・インタフェースの概要

プログラム・インタフェースとは、データベース・アプリケーションとOracle Databaseの間のソフトウェア・レイヤーです。プログラム・インタフェースでは、次の機能を実行します。

- セキュリティ・バリアを実現し、クライアント・クライアント・プロセスによるSGAへの破壊的なアクセスを防ぎます。

- 通信メカニズムとして機能し、情報リクエストの書式設定、データの受渡し、エラーのトラップと通知を行います。

- 特に異機種コンピュータ間、または外部ユーザー・プログラム・データ型に対してデータを変換し解釈します。

Oracleコードはサーバーとして機能し、データ・ブロックから行をフェッチするなど、アプリケーション(クライアント)のためにデータベース・タスクを実行します。プログラム・インタフェースは、Oracle Databaseソフトウェアとオペレーティング・システム固有のソフトウェアの両方によって提供される、複数の部分から構成されています。

プログラム・インタフェースの構造

プログラム・インタフェースは、次の要素から構成されます。

- Oracleコール・インタフェース(OCI)またはOracleランタイム・ライブラリ(SQLLIB)

- クライアント側またはユーザー側のプログラム・インタフェース

- 様々なOracle Net Servicesドライバ(プロトコル固有の通信ソフトウェア)

- オペレーティング・システムの通信ソフトウェア

- サーバーまたはOracle Database側のプログラム・インタフェース(OPIとも呼ばれます)

ユーザー側とOracle Database側のプログラム・インタフェースは、どちらもドライバのような仕組みでOracleソフトウェアを実行します。

プログラム・インタフェース・ドライバ

ドライバとは、通常はネットワークを介してデータを転送するソフトウェアの一部です。ドライバは、接続、切断、エラーの通知、エラーのテストなどの操作を実行します。ドライバは通信プロトコルに固有のものです。

デフォルトのドライバが常に存在します。複数のドライバ(非同期またはDECnetドライバなど)をインストールし、その1つをデフォルト・ドライバとして選択しますが、各ユーザーは、接続の時点で必要なドライバを指定することで、他のドライバを使用できます。

プロセスが異なる場合は、異なるドライバを使用できます。1つのプロセスは、異なるOracle Net Servicesドライバを使用して、単一または複数のデータベースに同時接続できます。

関連項目:

- ドライバの選択、インストールおよび追加方法の詳細は、システムのインストレーションおよび構成ガイドを参照してください。

- JDBCドライバの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

オペレーティング・システムの通信ソフトウェア

ユーザー側をOracle Database側のプログラム・インタフェースに接続する最下位層のソフトウェアは、ホスト・オペレーティング・システムによって提供される通信ソフトウェアです。たとえば、DECnet、TCP/IP、LU6.2、ASYNCなどです。通信ソフトウェアはOracleから提供されることもありますが、通常、ハードウェア・ベンダーまたはサード・パーティのソフトウェア・サプライヤから別途、購入します。

第VI部

Oracle Databaseの管理と開発

この部では、データベースの管理者および開発者にとって重要なトピックの概要について説明します。

この部の構成は、次のとおりです。

- 第17章「データベース管理者および開発者向けのトピック」

- 第18章「データベース管理者の概念」

- 第19章「データベース開発者の概念」

17 データベース管理者および開発者向けのトピック

これまでに、Oracle Databaseの基本的なアーキテクチャについて説明しました。この章では、データベース管理者と開発者にとって重要で一般的なデータベース・トピックを要約し、ここで網羅的にデータベースの機能を説明するかわりに、参照可能な他のマニュアルを紹介します。

この章の内容は、次のとおりです。

- データベース・セキュリティの概要

- 高可用性の概要

- グリッド・コンピューティングの概要

- データ・ウェアハウスとビジネス・インテリジェンスの概要

- Oracleにおける情報統合の概要

関連項目:
第18章「データベース管理者の概念」では、DBAに固有のトピックについて説明します。第19章「データベース開発者の概念」では、開発者向けのトピックについて説明します。

データベース・セキュリティの概要

通常、データベース・セキュリティには、ユーザー認証、暗号化、アクセス制御および監視が含まれます。

ユーザー・アカウント

各Oracleデータベースには、有効なデータベース・ユーザーのリストがあります。データベースには、デフォルトの管理アカウントSYSTEM(「SYSスキーマとSYSTEMスキーマ」を参照)を含む、複数のデフォルトのアカウントが含まれます。ユーザー・アカウントは必要に応じて作成できます。

データベースにアクセスするには、有効なユーザー名と認証用の資格証明を提供する必要があります。資格証明には、パスワード、Kerberosチケットまたは公開鍵インフラストラクチャ(PKI)の証明書などがあります。データベース・セキュリティでは、ログオン試行の失敗に基づいてアカウントをロックするよう構成できます。

権限およびロールの認可

通常、データベース・アクセス制御には、データ・アクセスおよびデータベース・アクティビティの制限が含まれます。たとえば、指定された表への問合せや指定されたデータベース・コマンドの実行を制限できます。

ユーザー権限とは、特定のSQL文を実行できる権利のことです。権限は、次のカテゴリに分類できます。

- システム権限
これは、データベース内で特定のアクションを実行する権限、または特定のタイプのオブジェクトに対してアクションを実行する権限のことです。システム権限の例として、CREATE USER、CREATE SESSIONがあります。

- オブジェクト権限
これは、employees表への問合せなど、指定されたアクションをオブジェクトに対して実行できる権限のことです。権限のタイプは、データベースによって定義されます。

権限は、他のユーザーの裁量で任意に付与されます。管理者は、ユーザーが業務に必要な作業を実行できるよう、必要な権限をユーザーに付与する必要があります。セキュリティの観点から、権限は必要な作業を行うためにその権限を必要とするユーザーにのみ付与することをお薦めします。

ロールは、関連する権限のグループに名前を付けたもので、ユーザーまたは他のロールに付与します。ロールを使用すると、データベース・アプリケーションまたはユーザー・グループの権限の管理が容易になります。

図17-1は、ロールの一般的な使用方法を示しています。PAY_CLERK、MANAGER、およびREC_CLERKの各ロールが、異なるユーザーに割り当てられます。ACCTS_PAYアプリケーションを実行する権限を含むACCTS_PAYアプリケーション・ロールが、PAY_CLERKおよびMANAGERロールを持つユーザーに割り当てられます。ACCTS_RECアプリケーションを実行する権限を含むACCTS_RECアプリケーション・ロールが、REC_CLERKおよびMANAGERロールを持つユーザーに割り当てられます。

図17-1 ロールの一般的な使用方法

関連項目:

- 権限の管理方法の詳細は、『Oracle Database 2日でセキュリティ・ガイド』および『Oracle Databaseセキュリティ・ガイド』を参照してください。

- セキュリティのためのロールの使用方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- ロールの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

- SESSION_PRIVSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

プロファイル

システム・リソースのコンテキストにおけるユーザー・プロファイルとは、リソース制限とパスワード・パラメータをセットにして名前を付けたもので、ユーザーに対してデータベースの使用およびインスタンス・リソースを制限します。プロファイルでは、ユーザーが同時に確立できるセッションの数、各セッションに使用可能なCPU処理時間、および使用可能な論理I/O量を制限できます(「バッファI/O」を参照)。たとえば、clerkプロファイルでは、ユーザーのシステム・リソースが事務作業に必要な程度に制限されます。

注意:
リソースの制限にはデータベース・リソース・マネージャを使用し、パスワードの管理にはプロファイルを使用することをお薦めします。

プロファイルを使用すると、一連の属性を共有する複数のユーザーに対して1つの参照先を指定できます。一連のユーザーにプロファイルを割り当て、それ以外のすべてのユーザーにデフォルト・プロファイルを割り当てることができます。各ユーザーには、任意の時点で最大1つのプロファイルを割り当てることができます。

関連項目:

- プロファイルを使用したリソースの管理方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- CREATE PROFILEの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください。

認証

Oracle Databaseでは、データベース認証は、ユーザーがデータベースに資格証明を提示し、この資格証明をデータベースが検証してデータベースへのアクセスを許可するプロセスです。アイデンティティを検証することで、その後の対話に関する信頼関係が確立されます。また、認証により、アクセスとアクションを特定のアイデンティティにリンクでき、アカウンタビリティが有効化されます。

Oracle Databaseでは、次のものを含む様々な認証方式が提供されています。

- データベースによる認証
Oracleデータベースは、パスワード、KerberosチケットまたはPKIの証明書を使用してユーザーを認証できます。Oracleでは、生体認証を含む、他の認証方式用のRADIUS準拠のデバイスもサポートしています。認証のタイプは、Oracleデータベースでユーザーを作成する際に指定する必要があります。

- オペレーティング・システムによる認証
一部のオペレーティング・システムでは、オペレーティング・システムがユーザー認証のために管理している情報を、Oracle Databaseで使用できます。オペレーティング・システムから認証を受けたユーザーは、ユーザー名やパスワードを指定することなくデータベースに接続できます。

データベースの起動や停止などのデータベース操作は、データベース管理者以外のデータベース・ユーザーが実行しないようにする必要があります。これらの操作には、SYSDBAまたはSYSOPER権限が必要です(「管理者権限での接続」を参照)。

関連項目:

- 認証方式の詳細は、『Oracle Databaseセキュリティ・ガイド』および『Oracle Database Advanced Security管理者ガイド』を参照してください。

- 管理認証の詳細は、『Oracle Database管理者ガイド』を参照してください。

暗号化

通常、暗号化は、秘密鍵と暗号化アルゴリズムを使用して、データを読取り不可能な形式に変換するプロセスです。多くの場合、暗号化は、Payment Card Industry Data Security Standard(PCI-DSS)や侵害通知法に関連する要件などの法令遵守要件を満たすために使用されます。たとえば、クレジット・カード番号、社会保障番号、患者の病状に関わる情報などを暗号化する必要があります。

ネットワーク暗号化

クライアントとサーバー間のネットワーク上を移動するデータを暗号化することを、ネットワーク暗号化といいます。侵入者は、ネットワーク・パケット・スニファを使用することにより、ネットワーク上を移動する情報を取得してファイルにスプールし、悪用できます。このような行為は、ネットワーク上のデータを暗号化することによって防ぐことができます。

透過的データ暗号化

Oracle Advanced Securityの透過的データ暗号化を使用すると、表の個々の列または表領域を暗号化できます。ユーザーが暗号化された列にデータを挿入すると、データベースによって自動的にデータが暗号化されます。ユーザーが列を選択すると、データは復号化されます。このような形式の暗号化は透過的であり、パフォーマンスが高く、実装が容易です。

透過的データ暗号化には、Advanced Encryption Standard(AES)や組込み鍵管理などの複数の業界標準の暗号化アルゴリズムが含まれます。

関連項目:
『Oracle Database 2日でセキュリティ・ガイド』および『Oracle Database Advanced Security管理者ガイド』

Oracle Data Redaction

Oracle Database 11gリリース2 (11.2.0.4)以降では、Oracle Data Redactionを使用して、権限の少ないユーザーまたはアプリケーションによって問い合されるデータを隠す(リダクションする)ことができます。このリダクションは、ユーザーがデータを問い合せるときに、リアルタイムで発生します。Oracle Data Redactionは、Oracle Advanced Securityの一部です。

データ・リダクションでは次のリダクション機能タイプがサポートされています。

- 完全データ・リダクション
この場合、表またはビューの指定した列の内容全体がリダクションされます。たとえば、姓のVARCHAR2列には、1つの空白が表示されます。

- 部分データ・リダクション
この場合、表示された出力の一部がリダクションされます。たとえば、アプリケーションでは、1234で終わるクレジット・カード番号をxxxx-xxxx-xxxx-1234と表示できます。完全と部分のどちらのリダクションにも、正規表現を使用できます。正規表現は、検索パターンに基づいて、データをリダクションできます。たとえば、正規表現を使用して、特定の電話番号または電子メール・アドレスをリダクションできます。

- ランダム・データ・リダクション
この場合、列のデータ型に応じて、データがランダムに生成された値として表示されます。たとえば、数値1234567は、83933895として表示される可能性があります。

データ・リダクションは、包括的なセキュリティの解決策ではありません。たとえば、直接接続し権限を付与されたユーザーが、リダクションされたデータに対して推論攻撃を実行することを阻止できません。このような攻撃では、リダクションされた列を識別し、削除の処理で、格納された値を推測するSQL問合せを繰り返すことにより、実際のデータに戻そうとします。権限を持つユーザーから発生する推論およびその他の攻撃を検出し、阻止するには、Oracle Data Redactionと関連のデータベース・セキュリティ製品(Oracle Audit Vault and Database Firewall、Oracle Database Vaultなど)と組み合せることをお薦めします。

データ・リダクションは、次のように機能します。

- DBMS_REDACTパッケージを使用して、指定した表のリダクション・ポリシーを作成します。

- ポリシーで、事前定義のリダクション機能を指定します。

- データベースで表示される列の値が実際の値かそれともリダクションされた値かは、ポリシーによって決まります。データがリダクションされると、そのリダクションがただちに最上位の選択リストに反映されから、ユーザーに表示されます。

次の例では、hr.employees表のemployee_id列をリダクションする完全データ・リダクション・ポリシーが追加されています。

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema    => 'hr'
,  object_name      => 'employees'
,  column_name      => 'employee_id'
,  policy_name      => 'mask_emp_ids'
,  function_type    => DBMS_REDACT.FULL
,  expression       => '1=1'
);
END;
/

この例では、表現の設定(trueと評価)により、EXEMPT REDACTION POLICY権限を付与されていないユーザーに対して、リダクションが適用されます。

関連項目:

- データ・リダクションの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

- DBMS_REDACTの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

アクセス制御

Oracle Databaseでは、データへのアクセスを制御するための技術が数多く提供されています。この項では、これらの技術の概要を示します。

Oracle Database Vault

Oracle Database Vaultは、権限を持つユーザーによるアクセスをアプリケーション・データに制限するセキュリティ・オプションです。Oracle Database Vaultを使用すると、データベース、データおよびアプリケーションに対するアクセスのタイミング、場所および方法を制御できます。このため、法令遵守および責務の分離を実現しながら、関係者による脅威からの保護など、一般的なセキュリティ上の問題にも対応できます。

関連項目:
『Oracle Database 2日でセキュリティ・ガイド』および『Oracle Database Vault管理者ガイド』

Virtual Private Database(VPD)

Oracle Virtual Private Database (VPD)を使用すると、行および列レベルでセキュリティを確保できます。セキュリティ・ポリシーによって、予期しないまたは悪意のあるデータの破壊やデータベース・インフラストラクチャの破損からデータベースを保護する方法が確立されます。

VPDでは、権限やロールなどのセキュリティ保護では設定できない詳細な設定が可能です。たとえば、すべてのユーザーに対してemployees表へのアクセスを許可する場合は、セキュリティ・ポリシーを作成して、ユーザーが同じ部門の従業員にアクセスすることを禁止できます。

基本的にデータベースは、Oracle VPDセキュリティ・ポリシーが適用された表、ビューまたはシノニムに対して発行されるSQL文に、動的なWHERE句を追加します。このWHERE句によって、保護データへのアクセスが、セキュリティ・ポリシーに準拠する資格証明を持つユーザーにのみ許可されます。

関連項目:
『Oracle Database 2日でセキュリティ・ガイド』および『Oracle Databaseセキュリティ・ガイド』

Oracle Label Security(OLS)

Oracle Label Security(OLS)は、セキュリティ・ラベルを使用してデータ分類の割当てとアクセスの制御を行うことができるセキュリティ・オプションです。ラベルはデータとユーザーの両方に割り当てることができます。

データに割り当てる場合、ラベルを非表示の列として既存の表に添付できるため、既存のSQLが透過的になります。たとえば、機密性が非常に高いデータを含む行にはHIGHLY SENSITIVEというラベルを、またそれほど機密性が高くない行にはSENSITIVEというラベルを添付できます。ユーザーがデータにアクセスしようとすると、OLSにより、ユーザー・ラベルとデータ・ラベルが比較され、アクセスを付与するかどうかが決定されます。VPDとは異なり、OLSには、ラベルの定義および格納について独創的なセキュリティ・ポリシーとメタデータ・リポジトリが採用されています。

関連項目:
『Oracle Database 2日でセキュリティ・ガイド』および『Oracle Label Security管理者ガイド』

監視

Oracle Databaseには、ユーザー・アクティビティを監視するために複数のツールおよび技術が採用されています。

データベース監査

データベース監査とは、選択したユーザー・データベース・アクションを監視して記録する処理のことです。標準監査では、SQL文、権限、スキーマ、オブジェクト、ネットワーク・アクティビティおよび複数層アクティビティを監査できます。また、ファイングレイン監査では、データベース表に対する操作などの特定のデータベース・アクティビティと、そのアクティビティが発生した時間を監視できます。たとえば、9:00 p.m.以降にアクセスされた表を監査できます。

監査は、次のような理由で使用します。

- 現在のアクションのアカウンタビリティの有効化

- アカウンタビリティに基づいた、ユーザー(または侵入者などの非ユーザー)の不適切なアクションの阻止

- 不審なアクティビティの調査、監視および記録

- 監査要件の準拠に対応するため

関連項目:

- 監査の有効/無効の切替え方法の詳細は、『Oracle Database 2日でセキュリティ・ガイド』および『Oracle Databaseセキュリティ・ガイド』を参照してください。

- 標準監査を補完するOracle Label Security監査の詳細は、『Oracle Label Security管理者ガイド』を参照してください。

Oracle Audit Vault and Database Firewall

Oracle Audit Vault and Database Firewall (Oracle AVDF)は、データベースの最初の防衛線を提供し、データベース、オペレーティング・システムおよびディレクトリからの監査データを統合します。SQL文法に基づくエンジンは、認可されていなSQLトラフィックがデータベースに到達する前に監視およびブロックします。コンプライアンス・レポートとアラートのために、Oracle AVDFはネットワークからのデータベース・アクティビティ・データを詳細な監査データと統合します。監査および監視制御を調整してエンタープライズ・セキュリティ要件を満たすことができます。

関連項目:
『Oracle Audit Vault and Database Firewall管理者ガイド』

Enterprise Managerの監査サポート

Oracle Enterprise Manager (Enterprise Manager)を使用すると、監査関連の初期化パラメータを表示および構成できます。また、文およびスキーマ・オブジェクトの監査時にオブジェクトを管理することもできます。たとえば、Enterprise Managerを使用して、現行の監査対象の文、権限およびオブジェクトのプロパティを表示および検索できます。監査は必要に応じて有効/無効を切り替えることができます。

高可用性の概要

可用性とは、アプリケーション、サービスおよび機能が必要なときにどの程度使用可能であるかということです。たとえば、オンライン書店で使用されるOLTPデータベースには、本を購入する顧客がアクセスできる程度の可用性があります。高可用性の主な特徴として、信頼性、リカバリ可能性、タイミングのよいエラー検出、継続的稼働などをあげることができます。

データベース環境において高可用性が重要である理由は、停止時間のコストに関連するためです(停止時間とは、リソースを使用できない時間のことです)。停止時間は、計画停止時間と計画外停止時間のいずれかに分類されます。高可用性環境を設計する場合の主要な課題は、可能性のある停止時間の原因をすべて調査し、対策を講じることです。

関連項目:
高可用性の概要は、『Oracle Database高可用性概要』を参照してください。

高可用性と計画外停止時間

Oracle Databaseでは、あらゆるタイプの予期しない障害により発生する停止時間を防止、許容および短縮する高可用性ソリューションが提供されています。計画外停止時間は、その原因によって次のように分類されます。

- サイト障害

- コンピュータ障害

- ストレージ障害

- データ破損

- 人為的エラー

関連項目:
計画外停止時間からの保護方法の詳細は、『Oracle Database高可用性概要』を参照してください。

サイト障害

サイト障害は、なんらかの原因でアプリケーションのすべてまたは大部分の処理が停止したか、サービスが利用できないほど速度が低下した場合に発生します。サイト障害は、データ・センターのすべての処理、またはデータ・センターによってサポートされているアプリケーション・サブセットに影響を及ぼす場合があります。サイト障害の例には、サイト全体にわたる広範囲な停電またはネットワーク障害、データ・センターが運用できなくなるほどの自然災害、運営あるいはサイト自体に対する悪意のある攻撃などがあります。

サイト障害に対する最も簡単な保護方法は、RMANを使用してデータベース・バックアップを作成し、オフサイトに保存することです。データベースを別のホストにリストアできます。ただし、この方法は時間がかかる場合があり、バックアップが最新でない可能性もあります。1つ以上のスタンバイ・データベースを持つData Guard環境では、本番サイトに障害が発生した場合でもデータベース・サービスの継続性を維持できます。

関連項目:

- サイト障害の詳細は、『Oracle Database高可用性概要』を参照してください。

- RMANとバックアップおよびリカバリ・ソリューションの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- スタンバイ・データベースの概要は、『Oracle Data Guard概要および管理』を参照してください。

コンピュータ障害

コンピュータ障害による停止は、データベースを実行しているシステムが停止またはアクセス不能になることによって、システムが使用不可能になった場合に発生します。コンピュータ障害の例には、ハードウェア障害やオペレーティング・システム障害などがあります。

コンピュータ障害を防止、またはコンピュータ障害への対応をサポートするOracle機能は、次のとおりです。

- エンタープライズ・グリッド
Oracle Real Applications Cluster(Oracle RAC)環境では、Oracle Databaseは単一の共有データベースに同時にアクセスしながら、クラスタ内の2つ以上のシステム上で稼働します。複数のハードウェア・システムにまたがる単一のデータベース・システムが、アプリケーションでは単一のデータベースとして認識されます。「グリッド・コンピューティングの概要」を参照してください。

- Oracle Data Guard
Data Guardを使用すると、スタンバイ・データベースと呼ばれる本番データベースのコピーを保持でき、スタンバイ・データベースは、地理的に離れた場所に設置することも、同じデータベース・センターに設置することも可能です。停止によりプライマリ・データベースが使用できなくなった場合、Data Guardにより任意のスタンバイ・データベースがプライマリ用に切り替えられるため、停止時間が最小限に抑えられます。『Oracle Data Guard概要および管理』を参照してください。

- Oracle Restart
データベース・インスタンス、リスナー、Oracle ASMインスタンスなどのOracle Databaseソフトウェア・スタックのコンポーネントは、コンポーネントに障害が発生するか、データベース・ホスト・コンピュータが再起動されると、自動的に再起動されます。Oracle Restartは、Oracleコンポーネントをコンポーネントの依存性に従って適切な順番で起動します。Oracle Restartの構成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- ファスト・スタート・リカバリ
計画外停止時間の一般的な原因は、システム障害またはクラッシュです。Oracle Databaseのファスト・スタート・リカバリ・テクノロジは、データベース・インスタンス・リカバリ時間を自動的にバインドします。ファスト・スタート・リカバリの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

関連項目:
単一インスタンス・データベースで実行されるプロセスおよびアプリケーションに対する高可用性の使用方法の詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

ストレージ障害

ストレージ障害による停止は、一部またはすべてのデータベース・コンテンツを保持しているストレージが停止またはアクセス不能になり、使用できなくなった場合に発生します。ストレージ障害の例には、ディスク・ドライブ障害やストレージ・アレイ障害などがあります。

ストレージ障害に対して、Oracle Data Guard以外に次のソリューションが提供されています。

- Oracle Automatic Storage Management (Oracle ASM)
Oracle ASMは、ファイルシステムとボリューム・マネージャをデータベース・カーネル内で垂直に統合します(「Oracle Automatic Storage Management(Oracle ASM)」を参照)。Oracle ASMにより、データおよびディスクの管理に伴う複雑な仕組みが排除され、ミラー化やディスクの追加および削除プロセスが簡略化されます。

- バックアップおよびリカバリ
Recovery Manager(RMAN)ユーティリティでは、データのバックアップ、以前のバックアップからのリストア、障害発生時までのデータ変更のリカバリなどを実行できます(「バックアップおよびリカバリ」を参照)。

関連項目:

- Oracle Enterprise Manager(Enterprise Manager)を使用したOracle ASMディスクの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- Oracle ASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

データ破損

データ破損は、ハードウェア、ソフトウェアまたはネットワーク・コンポーネントによって、破損したデータが読み取られた場合、または書き込まれた場合に発生します。たとえば、ボリューム・マネージャのエラーにより、不正なディスク読取りまたは書込みが実行されます。データ破損はほとんどありませんが、発生した場合にはデータベース、つまりビジネスに壊滅的な影響があります。

データ破損については、Data GuardおよびRecovery Manager以外にも、次の保護方法がOracle Databaseでサポートされています。

- 書込み欠落の保護
データ・ブロックの書込み欠落は、実際には行われていないブロック書込みの完了がI/Oサブシステムにより認識された場合に発生します。バッファ・キャッシュ・ブロックの読取りをREDOログに記録するように、データベースを構成できます。書込み欠落の検出は、Data Guardとともに使用することによって、最大の効果を発揮します。

- データ・ブロック破損の検出
ブロック破損とは、認識されているOracle形式ではないデータ・ブロック、または内容の一貫性が内部で保たれていないデータ・ブロックです。RMANなどのいくつかのデータベース・コンポーネントおよびユーティリティでは、破損ブロックを検出し、V$DATABASE_BLOCK_CORRUPTIONに記録できます。リアルタイムのスタンバイ・データベースが使用されている環境では、RMANにより自動的に破損ブロックを修復できます。

- データ・リカバリ・アドバイザ
データ・リカバリ・アドバイザは、データ障害を自動的に診断し、適当な修復オプションを提示し、ユーザーのリクエストに基づいて修復を実行するOracleツールです。

関連項目:

- データ破損に対する保護方法の詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

- RMANとバックアップおよびリカバリ・ソリューションの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

人為的エラー

人為的エラーによる停止は、過失または悪意による操作によって、データベース内のデータが論理的に破損するか、使用不可能になった場合に発生します。人為的エラーによる停止のサービス・レベルへの影響は、影響を受けたデータの量および重要度によって大きく異なる場合があります。

多くの研究で、停止時間の最大の原因は人為的エラーだと指摘されています。Oracle Databaseでは、人為的なエラーを迅速に診断してリカバリするために役立つ、管理者用の強力なツールが提供されています。また、エンド・ユーザーが、管理者の介入なしで問題からのリカバリを実行できる機能も備えられています。

Oracle Databaseを使用する場合、次の方法により人為的エラーから保護することをお薦めします。

- ユーザー・アクセスの制限
エラーを回避する最善の方法は、データおよびサービスへのユーザー・アクセスを制限することです。Oracle Databaseでは、ユーザー認証によりアプリケーション・データへのアクセスを制御する様々なセキュリティ・ツールが提供されており、管理者は、各ユーザーに対し、それぞれの職務の実行に必要な権限のみを付与できます(「データベース・セキュリティの概要」を参照)。

- Oracle Flashback Technology
Oracle Flashbackテクノロジは、人為的エラーを修復する一連のOracle Database機能です。Oracle Flashbackでは、人為的エラーを迅速に分析して修復するSQLインタフェースを提供しています。たとえば、次の操作を実行できます。

- 部分的な損害を対象としたファイングレイン分析と修復

- 広範囲の損害の迅速な修正

- 行、トランザクション、表、表領域、およびデータベース・レベルでのリカバリ

- Oracle LogMiner
Oracle LogMinerは、SQLを使用したオンライン・ファイルの読取り、分析および解析が可能な完全なリレーショナル・ツールです(「Oracle LogMiner」を参照)。

関連項目:

- 人為的エラーからのリカバリ方法の詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

- Oracle Flashback機能の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』および『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- Oracle LogMinerの詳細は、『Oracle Databaseユーティリティ』を参照してください。

高可用性と計画停止時間

特に複数のタイムゾーンのユーザーをサポートしているグローバル・エンタープライズでは、計画停止時間は運用に大きな損害を与える可能性があります。このような場合、ルーチン操作、定期的なメンテナンスおよび新規デプロイメントなどの計画的な中断を最小化するようシステムを設計することが重要です。

計画停止時間は、その原因によって次のように分類されます。

- システムおよびデータベースの変更

- データ変更

- アプリケーション変更

関連項目:
計画停止時間の機能およびソリューションの詳細は、『Oracle Database高可用性概要』を参照してください。

システムおよびデータベースの変更

計画的なシステム変更は、日常的および定期的なメンテナンス操作や新規デプロイメントを実行する場合に発生し、データベースの組織データ構造の外部で行われる運用環境の計画的変更もその1つです。その例としては、CPUやクラスタ・ノード(ノードは、データベース・インスタンスのあるコンピュータ)の追加または削除、システム・ハードウェアまたはソフトウェアのアップグレード、およびシステム・プラットフォームの移行などがあります。

Oracle Databaseでは、計画的なシステムおよびデータベース変更に対するソリューションとして、リソースの動的プロビジョニングを提供しています。

- データベースの動的再構成
Oracle Databaseでは、ハードウェアおよびデータベース構成の動的な変更がサポートされており、SMPサーバーのプロセッサの追加および削除、Oracle ASMを使用したストレージ・アレイの追加および削除などを動的に実行できます。たとえば、Oracle Databaseはオペレーティング・システムを監視して、CPU数の変更を検出します。CPU_COUNT初期化パラメータがデフォルトに設定されている場合、データベースのワークロードは、新規に追加されたプロセッサでも負担されます。

- 自動調整によるメモリー管理
Oracle Databaseでは、非一元化ポリシーを使用して、SGAおよびPGAの各サブコンポーネントのメモリーを解放および取得します。Oracle Databaseは、オペレーティング・システムにプロンプトを発行し、メモリーを必要とするコンポーネントにメモリーのグラニュルを転送することによってメモリーを自動調整します。「メモリーの管理」を参照してください。

- データファイル、制御ファイル、およびオンラインREDOログ・ファイルの自動配布
Oracle ASMでは、すべての使用可能なディスクにデータファイル、制御ファイル、およびログ・ファイルが自動配布されるため、それらのファイルのレイアウトが自動化され、簡素化されます。Oracle ASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

データ変更

計画的なデータ変更は、Oracle Databaseオブジェクトの論理構造または物理的な編成が変更された場合に発生します。これらの変更は、主にパフォーマンスまたは管理性を向上させる目的で行われます。例として、表の再定義、表パーティションの追加、および索引の作成または再作成などがあります。

Oracle Databaseでは、オンラインで再編成および再定義することによって、データ変更に伴う停止時間を最小化します。このアーキテクチャを使用すると、データベースのオープン中に、次のタスクを実行できます。

- 表の可用性に大きな影響を与えることなく表構造を変更できる、オンライン表再定義

- 索引の作成、分析および再編成(第3章「索引と索引構成表」を参照)

- 表パーティションの移動(「パーティションの概要」を参照)

関連項目:
オンラインでデータ構造を変更する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

アプリケーション変更

計画的なアプリケーション変更には、データ、スキーマおよびプログラムの変更が含まれる場合があります。これらの変更は、主にパフォーマンス、管理性、および機能性を向上させる目的で行われます。例として、アプリケーションのアップグレードがあります。

Oracle Databaseでは、アプリケーション・データベース・オブジェクトの変更に必要なアプリケーションの停止時間を最小限に抑えるために、次のソリューションがサポートされています。

- ローリング・パッチ更新
Oracle Databaseは、ローリング方式によるOracle RACシステムのノードへのパッチの適用をサポートします。『Oracle Database高可用性ベスト・プラクティス』を参照してください。

- ローリング・リリース・アップグレード
Oracle Databaseでは、ローリング方式によるデータベース・ソフトウェア・アップグレードのインストールおよびパッチセットの適用がサポートされており、この方式では、Data Guard SQL Applyおよびロジカル・スタンバイ・データベースが使用され、データベースの停止時間はほとんどありません。『Oracle Databaseアップグレード・ガイド』を参照してください。

- エディションベースの再定義
エディションベースの再定義を使用すると、アプリケーションの使用中にアプリケーションのデータベース・オブジェクトをアップグレードできるため、停止時間を最小限に抑えることや解消することが可能です。Oracle Databaseでは、エディションと呼ばれるプライベート環境でデータベース・オブジェクトを変更(再定義)することにより、このタスクを実行します。『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- デフォルトがWAITオプションのDDL
DDLコマンドには、内部構造の排他ロックが必要です(「DDLロック」を参照)。以前のリリースでは、ロックを取得できない場合、DDLコマンドが失敗しました。この問題は、DDLにWAITオプションを指定することで解決できます。『Oracle Database高可用性概要』を参照してください。

- 無効な状態のトリガーの作成
無効な状態のトリガーを作成でき、コードが正常にコンパイルされることを確認してから、トリガーを有効にできます。『Oracle Database PL/SQL言語リファレンス』を参照してください。

グリッド・コンピューティングの概要

グリッド・コンピューティングは、すべての企業のコンピューティング・ニーズに応じて、柔軟なオンデマンド・リソースに多くのサーバーおよび記憶域を効果的にプールするコンピューティング・アーキテクチャです。データベース・サーバー・グリッドは、互いに接続されたコモディティ・サーバーのコレクションで、1つ以上のデータベースを実行します。データベース記憶域グリッドは、低コストのモジュール・ストレージ・アレイのコレクションで、互いに結合されており、データベース・サーバー・グリッド内のコンピュータによってアクセスされます。

データベース・サーバー・グリッドとデータベース記憶域グリッドにより、システム・リソースのプールを構築できます。これらのシステム・リソースは、業務の優先順位に従って動的に割当ておよび割当解除できます。

図17-2に、エンタープライズ・グリッド・コンピューティング環境でのデータベース・サーバー・グリッドおよびデータベース記憶域グリッドを示します。

図17-2 グリッド・コンピューティング環境

関連項目:

- グリッド・コンピューティングの概要は、『Oracle Database高可用性概要』を参照してください。

- 標準化機構のグローバル・グリッド・フォーラム(GGF)の詳細は、http://www.gridforum.org/を参照してください。

データベース・サーバー・グリッド

Oracle Real Application Clusters(Oracle RAC)では、相互接続された複数のインスタンス間で、Oracle Databaseへのアクセスを共有できます。Oracle RAC環境では、Oracle Databaseは単一の共有データベースに同時にアクセスしながら、クラスタ内の2つ以上のシステム上で稼働します。Oracle RACでは、複数の低コストのサーバーにまたがる単一のデータベース(アプリケーションでは単一の統合されたデータベース・システムとして認識される)を提供することによって、データベース・サーバー・グリッドを有効にします。

Oracle Clusterwareは、複数のサーバーを1つのサーバーのように操作できるソフトウェアです。各サーバーは、普通のスタンドアロン・サーバーのように見えます。ただし、各サーバーには相互に通信を行うための追加的なプロセスが組み込まれているため、別々のサーバーが1つのサーバーであるかのように連携して動作します。Oracle Clusterwareには、ノード・メンバーシップおよびメッセージ・サービスなど、クラスタの実行に必要なすべての機能が用意されています。

関連項目:

- Oracle ClusterwareおよびOracle RACの概要は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

- Oracle RACデータベースの管理方法の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- Oracle Clusterwareのデプロイ方法および管理方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

スケーラビリティ

データベース・サーバー・グリッドでOracle RACを使用すると、容量を増加するためにクラスタにノードを追加できます。Oracle RACに実装されているキャッシュ・フュージョン・テクノロジにより、アプリケーションを変更しなくても容量を拡張できます。これにより、システムを段階的に拡張してコストを節約でき、小規模な単一ノード・システムを大規模なシステムに置き換える必要がなくなります。

既存のシステムを大規模なノードに置き換えるかわりに、ノードを段階的にクラスタに追加できます。グリッド・プラグ・アンド・プレイを使用すると、クラスタのノードの追加と削除が簡素化されるため、動的にプロビジョニングされた環境でクラスタをデプロイしやすくなります。また、グリッド・プラグ・アンド・プレイでは、データベースとサービスを位置に依存しない方法で管理することもできます。SCANを使用すると、クライアントはグリッド内の位置とは関係なくデータベース・サービスに接続できるようになります。

関連項目:

- キャッシュ・フュージョンの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- グリッド・プラグ・アンド・プレイのインストール方法の詳細は、『Oracle Databaseインストレーション・ガイド』を参照してください。

フォルト・トレランス

フォルト・トレランスは、高可用性アーキテクチャによって提供される、アーキテクチャ内のコンポーネント障害に対する保護機能です。Oracle RACアーキテクチャの主な利点は、複数のノードによって実現される本質的なフォルト・トレランスです。物理ノードは独立して動作しているため、1つ以上のノードに障害が発生してもクラスタ内の他のノードには影響しません。

フェイルオーバーはグリッド上の任意のノードで発生します。極端な場合、1つのノードを除くすべてのノードが停止しても、Oracle RACシステムはデータベース・サービスを提供し続けます。このアーキテクチャでは、メンテナンスのためにノードのグループを透過的にオンラインまたはオフラインにすると同時に、クラスタの残りの部分によってデータベース・サービスを提供し続けることができます。

Oracle RACには、Oracleクライアントおよび接続プールとの統合が組み込まれています。この機能により、接続を終了する障害がプールを介してアプリケーションに即座に通知されます。アプリケーションは、TCPタイムアウトを待機することなく、適切なリカバリ・アクションを即座に実行できます。Oracle RACでは、リスナーとOracleクライアントおよび接続プールを統合することによって、最適なアプリケーション・スループットを実現します。Oracle RACは、トランザクション時の負荷に基づいて、クラスタ・ワークロードのバランスを調整します。

関連項目:

- 「データベース常駐接続プーリング」

- 自動ワークロード管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- Oracle RACでのフォルト・トレランスの概要は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

サービス

Oracle RACはサービスをサポートしており、これによりデータベースのワークロードをグループ化し、サービスを提供するために割り当てられている最適なインスタンスに処理をルーティングできます。サービスとは、共通の属性、パフォーマンスしきい値、および優先順位を持つアプリケーションのワークロードです。

ビジネス・ポリシーを定義してこれらのサービスに適用し、ピーク処理時用のノードの割当てや、サービス障害の自動処理などのタスクを実行します。サービスを使用してシステム・リソースを必要な場所と時間に応じて適用することにより、ビジネス上の目標を達成します。

サービスは、データベース・リソース・マネージャに統合されており、データベース・リソース・マネージャでは、インスタンス内のサービスが使用するリソースを制限できます。また、特定のインスタンスを使用するかわりに、サービスを使用してOracle Schedulerジョブを実行することもできます。

関連項目:

- Oracleサービスの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

- データベース・リソース・マネージャおよびOracle Schedulerの詳細は、『Oracle Database管理者ガイド』を参照してください。

データベース記憶域グリッド

DBAまたはストレージ管理者は、Oracle ASMインタフェースを使用してデータベース記憶域グリッド内のディスクを指定でき、指定されたディスクは、すべてのサーバーおよび記憶域プラットフォームでASMにより管理されます。ASMは、ディスク領域をパーティションに区切り、データをASMに提供されたディスク全体に均等に配分します。また、ASMは、データベース記憶域グリッドのストレージ・アレイのディスクが追加または削除されると、データを自動的に再配分します。

関連項目:

- 「Oracle Automatic Storage Management(Oracle ASM)」

- データベース記憶域グリッドの概要は、『Oracle Database高可用性概要』を参照してください。

- クラスタOracle ASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

データ・ウェアハウスとビジネス・インテリジェンスの概要

データ・ウェアハウスは、トランザクション処理ではなく問合せおよび分析用に設計されたリレーショナル・データベースです。たとえば、データ・ウェアハウスでは、株価の履歴や所得税の記録を追跡できます。通常、ウェアハウスには履歴トランザクション・データから導出されたデータが格納されますが、他のソースからのデータも格納できます。

データ・ウェアハウス環境には、リレーショナル・データベースの他に、様々なツールがあります。典型的な環境には、ETLソリューション、OLAPエンジン、Oracle Warehouse Builder、クライアント分析ツール、データを収集してユーザーに配信するその他のアプリケーションがあります。

データ・ウェアハウスとOLTP

一般的なデータ・ウェアハウスの紹介として、William Inmonが規定したデータ・ウェアハウスの特性について説明します。脚注1

- サブジェクト指向
データ・ウェアハウスでは、売上などの主題別にデータベースを定義できます。

- 統合
データ・ウェアハウスには、様々なソースからのデータを一貫性のある形式で格納する必要があります。また、名前の競合や単位間の不一致などの問題を解決する必要があります。この目標が達成されて初めて、データ・ウェアハウスは統合されたことになります。

- 恒常的
ウェアハウスの目的は、発生した事柄を分析できるようにすることです。このため、ウェアハウスに格納されたデータは変更されません。

- 時系列
データ・ウェアハウスは時間経過による変化に焦点を当てています。

データ・ウェアハウスとOLTPデータベースでは、要件が異なります。たとえば、データ・ウェアハウスでは、ビジネスの傾向を把握するために、大量のデータを保持する必要があります。それとは対照的に、OLTPシステムでは、パフォーマンスを維持するために、履歴データを定期的にアーカイブに移動する必要があります。表17-1にデータ・ウェアハウスとOLTPの相違点を示します。

表17-1 データ・ウェアハウスとOLTPシステム

特徴

データ・ウェアハウス

OLTP

ワークロード

非定型問合せに適応するように設計されています。データ・ウェアハウスのワークロードは事前にはわからない場合があり、データ・ウェアハウスは様々な問合せを適切に実行できるように最適化する必要があります。

事前定義済の操作のみをサポートします。これらの操作のみをサポートするように、アプリケーションの特別なチューニングや設計が必要になる場合があります。

データ修正

バルク・データ修正テクニックを使用してETLプロセスにより定期的に更新されます。データ・ウェアハウスのエンド・ユーザーがデータベースを直接更新することはありません。

エンド・ユーザーにより定期的に発行される個々のDML文によって行われます。OLTPデータベースは常に最新であり、各ビジネス・トランザクションの現在の状態が反映されます。

スキーマ設計

全体または一部が非正規化されたスキーマ(スター・スキーマなど)を使用して、問合せパフォーマンスが最適化されます。

完全に正規化されたスキーマを使用して、DMLパフォーマンスが最適化され、データの整合性が保証されます。

典型的な操作

典型的な問合せでは、数千または数百万の行がスキャンされます。たとえば、すべての顧客についての先月の総売上を要求できます。

典型的な操作は、少数のレコードにのみアクセスします。たとえば、1人の顧客の現行の注文を取得できます。

履歴データ

履歴分析をサポートするために、数か月または数年分のデータが格納されます。

数週間または数か月分のデータしか格納されません。現行のトランザクションの要件を適切に満たすために必要な履歴データが保持されます。

関連項目:

- データベース・ウェアハウスの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- OLTPシステムの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

データ・ウェアハウスのアーキテクチャ

データ・ウェアハウスとそのアーキテクチャは、ビジネス要件によって異なります。この項では、一般的なデータ・ウェアハウス・アーキテクチャについて説明します。

データ・ウェアハウスのアーキテクチャ(基本)

図17-3に、データ・ウェアハウスの単純なアーキテクチャを示します。エンド・ユーザーは、複数のソース・システムからデータ・ウェアハウスに転送されたデータに直接アクセスします。

図17-3 データ・ウェアハウスのアーキテクチャ

図17-3には、従来型OLTPシステムのメタデータと生データの他に、サマリー・データが示されています。サマリーは集計ビューで、高コストの結合および集計操作を事前に計算して結果を表に格納することで、問合せのパフォーマンスが向上します。たとえば、サマリー表に地域別、製品別の売上合計を含めることができます。サマリーは、マテリアライズド・ビューとも呼ばれます。

関連項目:
基本マテリアライズド・ビューの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

データ・ウェアハウスのアーキテクチャ(ステージング領域あり)

図17-3のアーキテクチャでは、業務系データをウェアハウスに入れる前に、クリーン・アップおよび処理する必要があります。図17-4では、ウェアハウスに入れる前にデータを事前に処理する場所であるステージング領域が含まれるデータ・ウェアハウスを示しています。ステージング領域により、サマリーの作成とウェアハウス管理のタスクが簡素化されます。

図17-4 データ・ウェアハウスのアーキテクチャ(ステージング領域あり)

関連項目:
異なる転送メカニズムの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

データ・ウェアハウスのアーキテクチャ(ステージング領域およびデータ・マートあり)

ウェアハウス・アーキテクチャを組織内の様々なグループ向けにカスタマイズできます。そのためには、ウェアハウス内のデータを、特定の業務またはプロジェクト用に設計された独立したデータベースであるデータ・マートに転送します。通常、データ・マートには多くのサマリー表が含まれています。

図17-5では、購買、売上および在庫情報が別々のデータ・マートに分離されています。財務アナリストはデータ・マートに対して購買と売上の履歴情報を問い合せることができます。

図17-5 データ・ウェアハウスのアーキテクチャ(ステージング領域およびデータ・マートあり)

関連項目:
変換メカニズムの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

抽出、変換、ロード(ETL)の概要

ソース・システムからデータを抽出してウェアハウスに取り込む処理は、一般にETLと呼ばれ、抽出、変換、ロードを表します。ETLは、詳細に定義された3つのステップではなく、広範囲なプロセスを指します。

典型的なシナリオでは、1つ以上の業務系システムからデータを抽出し、処理用にターゲット・システムまたは中間システムに物理的に転送します。転送方法によっては、このプロセスでなんらかの変換処理が行われる場合もあります。たとえば、ゲートウェイを介してリモート・ターゲットに直接アクセスするSQL文では、SELECT文の一部として2つの列を連結できます。

Oracle Database自体は、ETLツールではありません。ただし、Oracle Databaseには、Oracle Warehouse BuilderやカスタマイズされたETLソリューションなど、ETLツールに使用される多くの機能が提供されています。Oracle Databaseが提供するETL機能は、次のとおりです。

- トランスポータブル表領域
異なるコンピュータ・アーキテクチャやオペレーティング・システム間で表領域を転送することもできます。トランスポータブル表領域は、2つのOracleデータベース間で大量のデータを移動する場合に最も高速な方法です。トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

- テーブル・ファンクション
テーブル・ファンクションは、出力として行セットを生成でき、行セットを入力として受け入れることができます。テーブル・ファンクションでは、PL/SQL、CまたはJavaで実装されている変換のパイプライン実行とパラレル実行がサポートされており、中間のステージング表を使用する必要はありません。テーブル・ファンクションの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- 外部表
外部表により、最初に外部データをデータベースにロードしなくても、パラレルで直接結合できます(「外部表」を参照)。このため、外部表を使用すると、ロード・フェーズと変換フェーズをパイプライン処理できます。

- 表の圧縮
ディスク使用量とメモリー使用量を減少させるために、表とパーティション表を圧縮形式で格納できます(「表の圧縮」を参照)。通常は、表の圧縮を使用すると、読取り専用操作のパフォーマンスが向上し、問合せ実行も速くなります。

- チェンジ・データ・キャプチャ
この機能により、リレーショナル表に対して追加、更新または削除されたデータが効率的に識別および取得され、この変更データのアプリケーションまたはユーザーでの使用が可能になります。

関連項目:

- チェンジ・データ・キャプチャの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- ETLの概要は、『Oracle Warehouse Builderデータ・モデリング、ETLおよびデータ・クオリティ・ガイド』を参照してください。

ビジネス・インテリジェンス

ビジネス・インテリジェンスは、ビジネスにおける意志決定を支援するために組織内の情報を分析することです。ビジネス・インテリジェンスおよび分析アプリケーションでのアクションのほとんどは、階層のドリルアップやドリルダウン、および集計値の比較によって占められています。Oracle Databaseでは、ビジネス・インテリジェンスをサポートするテクノロジを提供しています。

分析SQL

Oracle Databaseには、分析操作を実行するための多数のSQL操作が導入されています。たとえば、ランキング、移動平均、累計、対比レポート、期間対比などです。Oracle Databaseでは、次の形式による分析SQLがサポートされています。

- 集計用SQL
COUNTなどの集計関数は、個々の行ではなく、行グループに1つの結果行を戻します。集計は、データ・ウェアハウスの基盤です。ウェアハウスでの集計効率を改善するために、データベースには問合せとレポートを容易かつ高速にするGROUP BY句の拡張機能が用意されています。集計の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- 分析用SQL
分析関数では、行グループに基づいて集計値を計算します。集計関数との違いは、グループごとに複数の行を戻す点です。Oracleは、分析SQL関数ファミリを使用した拡張SQL分析処理機能を備えています。たとえば、これらの分析関数を使用すると、ランキングやパーセンタイル、変動ウィンドウを計算できます。分析用およびレポート用SQLの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- モデル化用SQL
MODEL句を使用すると、問合せ結果から多次元配列を作成し、この配列にルールを適用して新規の値を計算できます。たとえば、売上ビューのデータを国別にパーティション化し、複数のルールによって定義されたモデル計算を国別に実行できます。ある製品の2009年と2010年の売上の合計として2011年の売上を計算するルールを定義できます。SQLのモデル化の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

関連項目:
SQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

OLAP

Oracleオンライン分析処理(OLAP)では、複数のディメンション間でのデータ分析において、システム固有の多次元記憶域を提供し、レスポンス時間の短縮を実現します。OLAPを使用すると、アナリストは複雑な反復問合せの結果を対話形式のセッションで迅速に取得できます。

Oracle OLAPには、主に次の特性があります。

- Oracle OLAPはデータベースに統合されているため、標準的なSQLの管理、問合せおよびレポート・ツールを使用できます。

- OLAPエンジンは、Oracle Databaseのカーネル内で動作します。

- ディメンション・オブジェクトは、システム固有の多次元形式でOracle Databaseに格納されます。

- キューブおよび他のディメンション・オブジェクトは、Oracleデータ・ディクショナリ内に存在する最上位のデータ・オブジェクトです。

- データ・セキュリティは、Oracle Databaseユーザーおよびロールの権限の付与と取消しにより、標準的な方法で管理されます。

Oracle OLAPの特長はシンプルさで、1つのデータベース、標準的な管理とセキュリティ、および標準的なインタフェースと開発ツールで構成されています。

関連項目:

- 「ディメンションの概要」

- Oracle OLAPの概要は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

データ・マイニング

データ・マイニングでは、単なる分析の域を超えたパターンや傾向を大量の保存データの中から自動的に検索します。データ・マイニングでは、高度な数学的アルゴリズムを使用してデータをセグメント化し、イベントが将来発生する確率を計算します。通常、データ・マイニングは、コール・センター、ATM、E-Businessリレーショナル管理(ERM)およびビジネス・プランニングなどで使用されます。

Oracle Data Miningでは、データ、データ準備、モデル構築およびモデルのスコアリングの結果は、すべてデータベースに残ります。Oracle Data Miningでは、PL/SQL API、Java API、モデルのスコアリングを行うSQL関数、およびOracle Data Minerと呼ばれるGUIをサポートします。これにより、Oracle Databaseはアプリケーション開発者に、データ・マイニングをデータベース・アプリケーションとシームレスに統合するためのインフラストラクチャを提供します。

関連項目:
『Oracle Data Mining概要』

Oracleにおける情報統合の概要

組織が成長するにつれて、複数のデータベースおよびアプリケーション間で情報を共有できることに対する重要性が高まってきます。情報を共有するには、次の基本的な方法があります。

- 連結
情報を1つのデータベースに連結でき、これによって、それ以上の統合は必要なくなります。Oracle RAC、グリッド・コンピューティング、およびOracle VPDを使用して、情報を1つのデータベースに連結できます。

- 統合
情報は分散した状態にしておき、この情報を統合するツールを提供できます。これによって、情報が1つの仮想データベース内にあるかのように見せることができます。

- 共有
情報を共有することで、複数のデータ・ストアおよびアプリケーションで情報を保持できます。

この項では、主に情報を統合および共有するためのOracleソリューションについて説明します。

関連項目:
データ・レプリケーションおよび統合の概要は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

統合されたアクセス

統合されたアクセスの基本となるのは分散環境で、これは、相互にシームレスに通信する様々なシステムで構成されるネットワークです。分散環境では、各システムをノードと呼びます。ユーザーが直接接続するシステムをローカル・システムと呼びます。このユーザーがアクセスする他のシステムをリモート・システムと呼びます。

分散環境では、アプリケーションからローカル・システムやリモート・システムのデータにアクセスして相互に交換できます。すべてのデータに同時にアクセスして変更できます。

分散SQL

分散SQLを使用すると、複数のデータベース間に分散されたデータに同時にアクセスして更新できます。Oracle分散データベース・システムはユーザーに対して透過的であるため、単一のOracle Databaseであるかのように見せることができます。

分散SQLには、分散問合せおよび分散トランザクションが含まれます。Oracleの分散データベース・アーキテクチャによって、問合せおよびトランザクションが透過的になります。たとえば、標準DML文の動作は、非分散データベース環境の場合と同じです。また、アプリケーションでは標準SQL文COMMIT、SAVEPOINTおよびROLLBACKを使用してトランザクションを制御します。

関連項目:

- 「分散トランザクションの概要」

- 分散SQLの詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- 分散トランザクションの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

データベース・リンク

データベース・リンクは、2つの物理データベースを結ぶ接続で、これにより、クライアントは1つの論理データベースとして物理データベースにアクセスできます。Oracle Databaseは、データベース・リンクを使用して、あるデータベース上のユーザーがリモート・データベース内のオブジェクトにアクセスできるようにします。ローカル・ユーザーは、リモート・データベースのユーザーでなくても、リモート・データベースへのリンクにアクセスできます。

図17-6の例では、ユーザーhrが、hq.example.comというグローバル名を持つリモート・データベース上にあるemployees表にアクセスしています。employeesシノニムにより、リモート・スキーマ・オブジェクトのアイデンティティおよび位置は意識されなくなります。

図17-6 データベース・リンク

関連項目:
データベース・リンクの詳細は、『Oracle Database管理者ガイド』を参照してください。

情報の共有

どのような統合であっても、その中心は社内のアプリケーション間でデータを共有することです。Oracle Streamsは、Oracle Databaseにおける非同期の情報共有インフラストラクチャです。このインフラストラクチャを使用すると、データベース内またはデータベース間で、データ・ストリーム内のデータ、トランザクションおよびイベントを伝播させ、管理できます。

Oracle Streamsには、レプリケーションおよびメッセージ機能が含まれています。レプリケーションとは、データベース・オブジェクトおよびデータを複数のデータベースで共有するプロセスのことです。メッセージとは、アプリケーションとユーザー間で情報を共有することです。

関連項目:

- 『Oracle Streams概要および管理』

- 『Oracle Streamsレプリケーション管理者ガイド』

Oracle Streamsレプリケーション

Oracle Streamsレプリケーションでは、あるデータベースのデータベース・オブジェクトに対する変更をレプリケーション環境内の他のデータベースと共有できます。たとえば、Oracle Streamsを使用すると、employees表に対する更新を別のデータベースにある同一のemployees表に伝播できます。このように、レプリケーション環境のすべてのデータベースで、データベース・オブジェクトおよびデータの同期が維持されます。

Oracle Streamsレプリケーションの典型的な使用目的は、次のとおりです。

- プライマリOLTPサイトから処理をオフロードするためのレポート・サイトの作成。

- コール・センターまたは同様の業務におけるロード・バランシングの実装、スケーラビリティおよび可用性の向上。

- 一般的なビジネス要件を満たすためのサイト間の自律性の実現。

- 複数の場所からのデータの転送および連結。

- 異なるプラットフォームおよびOracle Databaseリリース間、およびWide Area Network(WAN)全体でのデータのレプリケート。

Oracle Streamsの情報フロー

Oracle Streamsのアーキテクチャはきわめて柔軟です。図17-7に、レプリケーション環境での基本的な情報フローを示します。

図17-7 Oracle Streamsの情報フロー

図17-7に示すように、Oracle Streamsには次の基本要素があります。

- 取得
Oracle Streamsは、暗黙的にDMLおよびDDLの変更を取得します。ルールによって、取得する変更が決定されます。変更は、データベースの変更を記述する固有の形式を備えたメッセージである、論理変更レコード(LCR)形式にフォーマットされます。

- ステージング
LCRは、取得したメッセージを格納して管理するキューであるステージング領域に置かれます。メッセージのステージングにより、メッセージ・データの監査と追跡のみでなく保持のための、セキュリティ機能を備えた領域が提供されます。伝播によってメッセージを1つのキューから別のキューに送信できます。キューは、同じまたは異なるデータベースに格納できます。

- 使用
LCRは、サブスクライバにより暗黙的または明示的に使用されるまでステージング領域に保持されます。適用プロセスは、LCRにカプセル化されている変更を暗黙的に適用します。

注意:
Oracle Streamsは、マテリアライズド・ビューと完全に相互運用可能です。マテリアライズド・ビューを使用して、更新可能または読取り専用のデータのコピーを維持できます(「マテリアライズド・ビューの概要」を参照)。

関連項目:
Oracle Streamsを使用したデータのレプリケート方法の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

Oracle Streamsレプリケーション環境

Oracle Streamsでは、様々なタイプのカスタム・レプリケーション環境を構成できます。ただし、次のタイプのレプリケーション環境が最も一般的です。

- 2データベース
レプリケートしたデータベース・オブジェクトは、2つのデータベース間でのみ共有されます。一方のデータベースでレプリケートしたデータベース・オブジェクトに対して行われた変更は、取得されて、もう一方のデータベースに直接送信され、変更が適用されます。

一方向レプリケーション環境では、レプリケートしたデータベース・オブジェクトを一方のデータベースでのみ変更でき、もう一方のデータベースは、これらのオブジェクトの読取り専用レプリカを格納します。双方向レプリケーション環境では、レプリケートしたオブジェクトを両方のデータベースで変更できます。この場合、データベースは両方とも、これらのデータベース・オブジェクトに対する変更を取得し、もう一方のデータベースに送信して適用します。

- ハブ・アンド・スポーク
中央データベース(ハブ)と2次データベース(スポーク)との間で通信が行われます。各スポークが相互に直接通信することはありません。ハブ・アンド・スポーク・レプリケーション環境では、レプリケートしたデータベース・オブジェクトに変更が可能かどうかはスポークによって異なります。

- N方向
各データベースは、環境内のその他のデータベースと直接通信します。一方のデータベースでレプリケートしたデータベース・オブジェクトに対して行われた変更は、取得されて環境内のその他のデータベースにそれぞれ直接送信され、変更が適用されます。

関連項目:
一般的なレプリケーション環境の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

Oracle Streams Advanced Queuing(AQ)

Oracle Streams Advanced Queuing(AQ)は、堅牢で豊富な機能を持つメッセージ・キューイング・システムであり、Oracle Databaseに統合されています。組織内の異なるシステム間で通信を行う必要がある場合は、メッセージング環境によって、これらのシステム間で重要な情報を転送する、標準的で信頼性の高い方法が提供されます。

ユースケースの例として、本社のOracleデータベースに注文を入力するとします。注文が入力されると、AQにより、注文IDと注文日がウェアハウスのデータベースに送信されます。これらのメッセージにより、ウェアハウスの従業員は注文があったことを知り、商品を梱包および出荷できます。

メッセージのキューイングとデキューイング

アドバンスト・キューイングでは、ユーザー・メッセージがキューと呼ばれる抽象的な記憶単位に保存されます。エンキューは、プロデューサがメッセージをキューに入れるプロセスです。デキューは、コンシューマがキューからメッセージを取得するプロセスです。

明示的デキューがサポートされるため、開発者はOracle Streamsを使用してメッセージを確実に交換できます。また、Oracle Streamsの変更取得および伝播機能を活用することで、変更をアプリケーションに通知できます。

図17-8では、サンプル・アプリケーションがアドバンスト・キューイングを介して、明示的にメッセージをエンキューおよびデキューしており、これにより、異なるメッセージ・システムを使用しているパートナとも情報を共有できます。エンキューした後、パートナのアプリケーションにデキューされる前に、メッセージを変換および伝播することもできます。

図17-8 Oracle Streamsのメッセージ・キューイング

アドバンスト・キューイングの機能

Oracle Streams Advanced Queuingでは、メッセージ・キューイング・システムの標準的な機能がすべてサポートされています。これらの機能は、次のとおりです。

- 非同期によるアプリケーションの統合
Oracle Streams Advanced Queuingでは、複数の方法でメッセージをエンキューできます。メッセージは、取得プロセスまたは同期取得が暗黙的に取得するか、アプリケーションやユーザーが明示的に取得できます。

- 拡張可能な統合アーキテクチャ
多くのアプリケーションは、Oracle Databaseをハブとする分散ハブ・アンド・スポーク・モデルを使用して統合されます。Oracleデータベース上の分散アプリケーションは、同じハブのキューと通信します。複数のアプリケーションが同じキューを共有できるので、サポートするアプリケーション数を増やすためにキューを追加する必要がありません。

- 異機種間アプリケーションの統合
アドバンスト・キューイングは、アプリケーションにOracleタイプ・システムの全機能を提供します。これには、スカラー・データ型、継承を伴うOracle Databaseオブジェクト型、XMLデータ用の追加演算子を持つXMLType、およびANYDATAのサポートが含まれます。

- 従来型アプリケーションの統合
Oracle Messaging Gatewayは、Oracle DatabaseアプリケーションをWebSphere MQやTibcoなどの他のメッセージ・キューイング・システムと統合します。

- 標準ベースAPIのサポート
Oracle Streams Advanced Queuingは、業界標準のAPIであるSQL、JMSおよびSOAPをサポートしています。SQLを使用して行われた変更は、メッセージとして自動的に取得されます。

関連項目:

- アドバンスト・キューイングを使用したメッセージの送信方法の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- 『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』

Oracle Streamsのユースケース

ユースケースの例として、会社がOracle Streamsを使用して自社のWebサイトのコピーを複数管理するとします。この場合のビジネス要件は、次のとおりです。

- ニューヨークのオフィスのアナリストが非定型問合せを実行できるように、最新のデータがレポート用データベースに格納されている必要があります。

- 現場の営業担当が、更新可能なマテリアライズド・ビューによってサポートされる必要があります。

- Sybaseデータベースで管理されているアプリケーションでデータが共有される必要があります。

図17-9に、Oracle Streamsの構成を示します。

図17-9 Oracle Streamsの構成

Oracle Streamsは、ニューヨーク、ロンドンおよび東京にあるサイトで構成されるN方向の構成でデータをレプリケートするために使用されます。各サイトでは、Oracle Streamsの暗黙的な取得機能により、各地のサブスクライブ表に発生する変更が収集され、ローカルでキューにステージングされます。各地で取得された変更は、その他の地域のそれぞれのデータベースに転送されます。各データベースで行われた変更はその他すべてのデータベースに反映でき、これにより、サブスクライブされた世界中のオブジェクトの完全なデータが提供されます。

各地のデータベースでは、Oracle Streamsの適用プロセスにより自動的に変更が行われます。変更が適用されると、Oracle Streamsは競合の有無をチェックし、競合を解消します。また、Oracle Streamsを使用してOracle以外のデータベースとの間で特定の表データを交換することもできます。Oracle Database Gateway for Sybaseを利用すると、Oracle Streamsの適用プロセスはOracle Databaseの場合と同じメカニズムを使用して変更をSybaseデータベースに適用します。

レポート用データベースは、ニューヨークにホスティングされます。このデータベースは、該当するアプリケーション表の読取り専用コピーが格納されている、全機能を備えたOracle Databaseです。レポート・サイトは、これらのアプリケーション表に対する変更を取得するように構成されていません。このレポート用データベースの構成と使用には制限が課されません。

ロンドンのサイトは、複数の更新可能マテリアライズド・ビュー・サイトのマスター・サイトとしても機能します。各営業担当は、データのうち必要な部分の更新可能なコピーを受け取ります。通常、これらのサイトは、前回のリフレッシュ以降に発生した注文をアップロードして変更をダウンロードするために、1日に1度のみ接続します。

関連項目:
Oracle Streamsの構成の例は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

脚注の凡例

脚注1: 『Building the Data Warehouse』(1996年John Wiley and Sons社)

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

この章の内容は、次のとおりです。

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

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

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

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

データベース管理者(DBA)の主要な役割は、企業データをユーザーに対して利用可能にすることです。DBAは、アプリケーションがデータベースを効率よく使用できるよう、開発者と緊密に連携する必要があり、また、物理リソースを適切に保ち、効率よく使用できるよう、システム管理者と緊密に連携する必要があります。

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

- Oracle Databaseソフトウェアのインストール、アップグレードおよびパッチ適用

- 要件の確認、論理設計(概念モデル)の作成および物理データベース設計を含む、データベースの設計

- Oracle Databaseの作成

- バックアップやリカバリ計画の開発およびテスト、Oracle Databaseの定期バックアップ、障害発生時のリカバリ

- クライアントがデータベースに接続するためのネットワーク環境の構成

- データベースの起動および停止

- データベースの記憶域の管理

- ユーザーおよびセキュリティの管理

- 表、索引、ビューなどのデータベース・オブジェクトの管理

- データベースのパフォーマンスの監視およびチューニング

- 重大なデータベース・エラーが発生した場合の調査、診断データの収集、Oracleサポート・サービスへの報告

- 新しいデータベース機能の評価およびテスト

前述のタスク、および他の多くのタスクの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

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

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

Oracleでは、データベースを管理するためのいくつかのツールを提供しています。この項では、一般的に使用される次のツールについて説明します。

- Oracle Enterprise Manager

- SQL*Plus

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

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

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

Oracle Enterprise Manager

Oracle Enterprise Manager(Enterprise Manager)は、データベース環境を集中管理するためのシステム管理ツールです。Enterprise Managerは、グラフィカル・コンソール、Oracle Management Server、Oracle Intelligent Agent、共通サービスおよび管理ツールを組み合せることで、Oracle製品の包括的なシステム管理プラットフォームを提供します。

WebベースのEnterprise Manager Database Control(Database Control)は、Oracle Database管理における主要ツールです。このツールは、Oracle Databaseとともにインストールされます。Database Controlを使用すると、次のような管理タスクを実行できます。

- データベースの診断、変更およびチューニング

- 管理タスクを容易にするための関連ターゲットのグループ化、他の管理者とのタスクの共有、様々な時間間隔でのタスクのスケジューリング

- OracleホームへのOracle Net Servicesの構成および管理(「Oracleネットワーク・アーキテクチャの概要」を参照)

- 統合されたOracleおよびサード・パーティ製のツールの起動

下図に、Database Controlのデータベース・ホームページを示します。ページ上部に配列されたサブページ・リンクを使用すると、パフォーマンス、可用性およびその他のデータベース管理ページにアクセスできます。データベース・ホームページのサブセクションには、データベースの環境および状態に関する情報が表示されます。

次の図に、Enterprise Managerの基本アーキテクチャを示します。管理リポジトリはデータベースに格納されます。エージェントと管理サービスは両方ともデータベースのホスト上で実行されます。Database Control Consoleは、管理サービスにセキュアに接続できる任意のWebブラウザから実行できます。

関連項目:
Enterprise Managerを使用したデータベースの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

SQL*Plus

SQL*Plusは、すべてのOracle Databaseのインストール時に含まれる、対話型のバッチ問合せツールです。このツールには、データベースへの接続時にクライアントとして機能する、コマンドライン・ユーザー・インタフェースがあります。

SQL*Plusは独自のコマンドと環境を持っています。ここでは、SQL、PL/SQL、SQL*Plus、オペレーティング・システム・コマンドを入力および実行し、次のタスクを実行できます。

- 問合せ結果の書式設定、計算の実行、保存および印刷

- 表定義およびオブジェクト定義の検証

- バッチ・スクリプトの開発および実行

- データベースの管理

SQL*Plusを使用して、対話的なレポート生成、バッチ処理としてのレポート生成、およびテキスト・ファイル、スクリーンまたはインターネットでの閲覧用のHTMLファイルへの結果の出力が可能です。HTML出力機能を使用するとレポートを動的に生成できます。

関連項目:
SQL*Plusの詳細は、『Oracle Database 2日でデータベース管理者』および『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

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

Oracleでは、Oracle Databaseソフトウェアのインストール・タスクおよび構成タスクを簡略化するためのいくつかのツールを提供しています。これらのツールは次のとおりです。

- Oracle Universal Installer(OUI)
OUIは、Oracle Databaseソフトウェアを表示、インストールおよびアンインストールするためのGUIユーティリティです。オンライン・ヘルプがあり、ガイドに従ってインストールできます。Oracle Databaseソフトウェアのインストール方法の詳細は、『Oracle Databaseインストレーション・ガイド』を参照してください。

- Database Upgrade Assistant(DBUA)
DBUAを使用すると、対話形式のガイドに従ってデータベースをアップグレードし、新規リリースに応じてデータベースを構成できます。DBUAでは、通常は手動で実行されるタスクをすべて実行することによって、アップグレードを自動化します。DBUAでは、表領域やオンラインREDOログなどの構成オプションに対して推奨設定を作成します。DBUAを使用したデータベースのアップグレード方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- Database Configuration Assistant(DBCA)
DBCAには、データベースを作成し、構成するためのグラフィカル・インタフェースおよびガイド付きワークフローが用意されています。このツールを使用すると、Oracle提供のテンプレートからデータベースを作成したり、独自のデータベースやテンプレートを作成できます。DBCAを使用したデータベースの作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

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

Oracle Net Servicesにより、分散、異機種間コンピューティング環境において、企業全体の接続性が確保されます。Oracle NetはOracle Net Servicesのコンポーネントであり、クライアント・アプリケーションからデータベースへのネットワーク・セッションも確立できます。次のツールを使用して、Oracle Net Servicesを構成および管理できます。

- Oracle Net Manager
このツールを使用すると、ローカル・クライアントまたはサーバー・ホスト上のOracleホームにOracle Net Servicesを構成できます。Oracle Net Managerを使用して、ネーミング、ネーミング・メソッド、プロファイルおよびリスナーを設定できます。Oracle Net Managerは、Oracle Enterprise Manager Consoleを使用して起動するか、独立したアプリケーションとして起動できます。

- Oracle Net Configuration Assistant
このツールは、ソフトウェアのインストール時に自動的に実行されます。Oracle Net Configuration Assistantでは、リスナー名、プロトコル・アドレス、ネーミング・メソッド、tnsnames.oraファイル内のネット・サービス名、ディレクトリ・サーバーの使用などの基本ネットワーク・コンポーネントをインストール時に構成できます。

- リスナー制御ユーティリティ
リスナー制御ユーティリティを使用すると、クライアント接続を受信するリスナーを構成できます(「Oracle Net Listener」を参照)。ユーティリティには、Enterprise Managerから、またはスタンドアロンのコマンドライン・アプリケーションとしてアクセスできます。

- Oracle Connection Manager制御ユーティリティ
このコマンドライン・ユーティリティを使用すると、Oracle Connection Manager(ルーターの一種で、クライアント接続リクエストは、このルーターを経由して次のホップに送信されたり、データベースに直接送信されます)を管理できます。ユーティリティ・コマンドを使用して、基本的な管理機能を1つ以上のOracle Connection Managerに対して実行できます。さらに、パラメータの設定を表示および変更できます。

関連項目:

- 「Oracleネットワーク・アーキテクチャの概要」

- Oracle Net Servicesツールの詳細は、『Oracle Database Net Services管理者ガイド』および『Oracle Database Net Servicesリファレンス』を参照してください。

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

Oracle Databaseでは、データベースでの移動および分析を支援するいくつかのユーティリティを提供しています。たとえば、データベース・ユーティリティを使用して、次のことを実行できます。

- オペレーティング・システム・ファイルからOracle Database表へのデータのロード(「SQL*Loader」を参照)

- 一方のデータベースから他方のデータベースへのデータおよびメタデータの移動(「Oracle Data Pumpエクスポートおよびインポート」を参照)

- SQLインタフェースを介したREDOログ・ファイルの問合せ(「Oracle LogMiner」を参照)

- Oracle Database診断データの管理(「ADRコマンド・インタプリタ(ADRCI)」を参照)

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

注意:
バックアップおよびリカバリに関連したツールは、「バックアップおよびリカバリ」を参照してください。

関連項目:
DBVERIFYおよびDBNEWIDの詳細は、『Oracle Databaseユーティリティ』を参照してください。

SQL*Loader

SQL*Loaderは、データファイルと呼ばれる外部ファイルからデータベース表にデータをロードします。強力なデータ解析エンジンによって、あらゆるデータ形式のデータファイルに対応できます。SQL*Loaderでは、次のタスクを実行できます。

- 複数のデータファイルから複数の表へのデータのロード
ロードするデータは、SQL*Loaderデータファイルに格納します。SQL*Loader制御ファイルはテキスト・ファイルであり、このファイルには、SQL*Loaderがデータの格納場所、解析方法、解釈方法、挿入場所などを決定するときに使用するDDL命令が含まれています。

注意:
SQL*Loaderデータファイルおよび制御ファイルは、Oracle Databaseデータファイルおよび制御ファイルとは関連付けられていません。

- ロード操作の様々な制御
たとえば、データの選択的なロード、データのキャラクタ・セットの指定(「キャラクタ・セット」を参照)、SQL関数によるデータの操作、指定の列への一意のシーケンシャル・キー値の生成が可能です。また、複雑なエラー・レポートも生成できます。

- 従来型パスによるロードまたはダイレクト・パス・ロード
従来型パスによるロードでは、表にデータを移入するときにSQL INSERT文を実行します。一方、ダイレクト・パス・ロードでは、データ・ブロックをフォーマットし、それをデータベース・ファイルに直接書き込むことによって、データベースのオーバーヘッドを大幅に軽減します。直接書き込む場合は、最高水位標よりも高いブロックで処理され、データベース・バッファ・キャッシュを経由せずに、ディスクに直接書き込まれます。直接読み取る場合も、バッファ・キャッシュを経由せずに、ディスクからPGAに直接読み取ります。

典型的なSQL*Loaderセッションは、SQL*Loader制御ファイルと1つ以上のデータファイルを入力として使用します。出力は、Oracle Database、ログ・ファイル、不良ファイル、および存在する場合は廃棄ファイルです。図18-1に、典型的なSQL*Loaderセッションのフローを示します。

図18-1 SQL*Loaderセッション

関連項目:
SQL*Loaderの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseユーティリティ』を参照してください。

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

Oracle Data Pumpにより、データベース間でデータとメタデータを高速で移動できます。このテクノロジは、次のOracle Databaseデータ移動ユーティリティのベースとなります。

- データ・ポンプ・エクスポート(エクスポート)
エクスポートは、データとメタデータをダンプ・ファイル・セットと呼ばれる一連のオペレーティング・システム・ファイルにアンロードするユーティリティです。ダンプ・ファイル・セットは、表データ、データベース・オブジェクトのメタデータおよび制御情報を含む1つ以上のバイナリ・ファイルから構成されています。

- データ・ポンプ・インポート(インポート)
インポートは、エクスポートされたダンプ・ファイル・セットをデータベースにロードするユーティリティです。また、インポートを使用すると、ソース・データベースから中間ファイルなしで宛先データベースに直接ロードすることができ、エクスポート操作とインポート操作を同時に実行することで全体の所要時間が短縮されます。

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

- expdpおよびimpdpコマンドライン・クライアント
これらのクライアントは、DBMS_DATAPUMPパッケージに対してコールし、Oracle Data Pump操作を実行します(「PL/SQLパッケージ」を参照)。

- DBMS_DATAPUMP PL/SQLパッケージ(データ・ポンプAPIとも呼ばれる)
このAPIによって、高速でインポートおよびエクスポートされます。

- DBMS_METADATA PL/SQLパッケージ(メタデータAPIとも呼ばれる)
このAPIには、オブジェクト定義がXML形式で格納されており、メタデータのすべてのロードおよびアンロード・プロセスで使用されます。

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

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

関連項目:

- Oracle Data Pumpの概要は、『Oracle Databaseユーティリティ』を参照してください。

- DBMS_DATAPUMPおよびDBMS_METADATAの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

Oracle LogMiner

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

- アプリケーション・レベルで発生したエラーなど、データベースの論理的な破損の開始時点を特定します。

- ユーザー・エラーを検出します。

- トランザクション・レベルでファイングレイン・リカバリを実行するために必要な操作を判断します。

- 傾向分析を使用して、更新および挿入頻度の最も高い表を判断できます。

- REDOログ・ファイルに対するLogMinerの包括的なリレーショナル・インタフェースを使用して、システムの動作を分析し、データベースの使用状況を監査します。

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

関連項目:
LogMinerの詳細は、『Oracle Databaseユーティリティ』を参照してください。

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

ADRCIは、問題の調査、ヘルス・チェック・レポートの表示、新たな障害の診断データのパッケージおよびそのOracleサポートへのアップロードに使用するコマンドライン・ユーティリティです。また、このユーティリティでは、自動診断リポジトリ(ADR)内のトレース・ファイル名やアラート・ログを表示できます。ADRCIには、対話形式またはスクリプトで使用できる豊富なコマンド・セットが用意されています。

関連項目:

- 「自動診断リポジトリ」

- ADRおよびADRCIの詳細は、『Oracle Databaseユーティリティ』および『Oracle Database管理者ガイド』を参照してください。

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

第17章では、開発者とDBAの両方にとって重要なトピックについて説明します。この項では、他の箇所で説明されていないDBAに不可欠なトピックについて説明します。

この項には次のトピックが含まれます:

- バックアップおよびリカバリ

- メモリーの管理

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

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

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

バックアップおよびリカバリとは、メディア障害またはユーザー・エラーによるデータ損失からのデータベース保護に関連する、一連の概念、プロシージャ、計画です。一般的に、バックアップおよびリカバリ計画の目的は、データベースをデータ損失から保護し、失われたデータを再構築することです。

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

関連項目:
バックアップとリカバリの概念およびタスクの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

次の方法を使用すると、Oracle Databaseをバックアップおよびリカバリできます。

- Recovery Manager(RMAN)
RMANは、Oracle Databaseと統合し、バックアップおよびリカバリ・アクティビティを実行するためのOracle Databaseユーティリティで、たとえば、履歴バックアップ・メタデータのリポジトリをバックアップ対象のすべてのデータベースの制御ファイルに保持できます。RMANでは、リカバリ・カタログと呼ばれる集中管理されるバックアップ・リポジトリを別のデータベースに保持することもできます。RMANはOracle Databaseの機能であるため、別途インストールする必要はありません。

RMANは、Oracle Secure Backupと統合されており、Oracle Secure Backupを使用すると、ファイルシステム・データおよびOracle Databaseファイルを保護する、信頼性の高いテープ・バックアップの集中管理が可能となります。Oracle Secure Backup SBTインタフェースでは、RMANを使用したデータベース・ファイルのテープおよびAmazon S3などのインターネット・ベースのWebサービスへのバックアップ、およびこれらの媒体からのデータベース・ファイルのリストアが可能になります。Oracle Secure Backupでは、SANおよびSCSI環境のほとんどすべてのテープ・ドライブおよびテープ・ライブラリがサポートされています。

RMANおよびOracle Secure Backupには、コマンドラインとEnterprise Managerの両方からアクセスできます。

- ユーザーによる管理方法
RMANを使用するかわりに、バックアップおよびファイルのリストアの場合はLinuxのddコマンド、メディア・リカバリの場合はSQL*PlusのRECOVERコマンドなど、オペレーティング・システムのコマンドを使用できます。Oracleでは、ユーザー管理のバックアップおよびリカバリが全面的にサポートされていますが、RMANの方がOracle Databaseと統合されており、管理が簡素化されているため、RMANを使用することをお薦めします。

図18-3に、基本的なRMANアーキテクチャを示します。Enterprise Managerからアクセス可能なRMANクライアントは、ターゲット・データベースのサーバー・セッションを使用して、データをディスクまたはテープにバックアップします。RMANは、外部にあるリカバリ・カタログをバックアップ・メタデータで更新できます。

図18-3 RMANアーキテクチャ

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

関連項目:

- Enterprise Managerを使用したバックアップおよびリカバリの実行方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- バックアップおよびリカバリ・ソリューションの概要は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 高速リカバリ領域の設定および管理方法は、『Oracle Database管理者ガイド』を参照してください。

- Oracle Secure Backupの概要は、『Oracle Secure Backup管理者ガイド』を参照してください。

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

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

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

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

関連項目:
物理バックアップおよび論理バックアップの概要は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

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

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

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

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

データベースの一貫性バックアップは、一貫性が保たれた状態で停止した後にのみ実行でき(「停止モード」を参照)、NOARCHIVELOGモードで稼働しているデータベースで有効な唯一のバックアップ・オプションです。他のバックアップ・オプションでは、一貫性のためメディア・リカバリを必要としますが、これはアーカイブREDOログ・ファイルを適用しなければ不可能です。

注意:
REDOを適用せずにデータベース全体の一貫性バックアップをリストアすると、バックアップ後に実行されたトランザクションはすべて失われます。

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

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

関連項目:
非一貫性バックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

バックアップ・セットおよびイメージ・コピー

RMANのBACKUPコマンドでは、イメージ・コピーまたはバックアップ・セットが生成されます。イメージ・コピーとは、データファイル、制御ファイルまたはアーカイブREDOログ・ファイルをビット単位でディスク上に複製したものです。オペレーティング・システムのユーティリティまたはRMANを使用して物理ファイルのイメージ・コピーを作成し、いずれかのツールを使用してファイルをリストアできます。

注意:
オペレーティング・システムによるコピーとは異なり、RMANではファイル内のブロックが検証され、イメージ・コピーがRMANリポジトリに記録されます。

RMANは、バックアップ・セットと呼ばれる独自の形式のバックアップを作成することもできます。バックアップ・セットには、1つ以上のデータファイル、アーカイブREDOログ・ファイル、制御ファイル、または1つのサーバー・パラメータ・ファイルからのデータが格納されます。バックアップ・セットの最小単位は、バックアップ・ピースと呼ばれるバイナリ・ファイルです。バックアップ・セットは、RMANがテープ・ドライブなどのシーケンシャル・デバイスへバックアップを書き込むための唯一の方法です。

バックアップ・セットを使用すると、テープ・デバイスが連続して動作できるようになります。たとえば、RMANでは、低速、中速および高速の各ディスクのブロックを1つのバックアップ・セットに結合することにより、テープ・デバイス内の入力ブロックを一定に保つことができます。ディスクのイメージ・コピーは、段階的な更新や所定の位置でのリカバリが可能であるため、役に立ちます。

関連項目:
バックアップ・セットおよびイメージ・コピーの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

データ修復

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

- メディア障害
メディア障害は、データベース外部の問題により、データベースでファイルの読取りまたは書込みができない場合に発生します。一般的なメディア障害には、ヘッド・クラッシュなどの物理的な障害、およびデータベース・ファイルの上書き、削除または破損が含まれます。メディア障害は、ユーザーまたはアプリケーションのエラーより頻度は低いですが、リカバリ計画を堅実にするには、これに備えておく必要があります。

- ユーザー・エラー
不適切な更新、表の内容の削除またはデータベース・オブジェクトの削除など、ユーザーまたはアプリケーションによって、データベースに不要な変更が加えられる場合があります(「人為的エラー」を参照)。適切なバックアップおよびリカバリ計画では、データベースの可用性に対する影響を最小化し、DBAの労力を最低限に抑えて、必要な状態にデータベースを戻すことができます。

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

関連項目:
データ修復の概念の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

データ・リカバリ・アドバイザ

データ・リカバリ・アドバイザ・ツールは、データ障害を自動的に診断して、適切な修復オプションを提示し、ユーザーのリクエストに基づいて修復を実行します。データ・リカバリ・アドバイザは、自動データ修復用の集中管理ツールを提供することによって、Oracle Databaseの管理性および信頼性を向上し、リカバリ時間を短縮します。

データベースには、状態モニターと呼ばれる、診断チェックを実行するためのフレームワークがあります。チェッカは、データベースまたはそのコンポーネントの状態を評価するために状態モニターに登録されている診断操作またはプロシージャです。状態評価はデータ整合性チェックとも呼ばれ、対処的または予防的に起動できます。

障害とは、データ整合性チェックにより検出される永続的なデータ破損のことです。障害は通常、対処的に検出されます。破損データが関与するデータベースの操作はエラーとなりますが、これにより自動的にデータ整合性チェックが起動され、エラーに関連する障害がないかデータベースが検索されます。障害が診断された場合、その障害はデータベースにより自動診断リポジトリ(ADR)に記録されます。

障害がデータベースにより検出され、ADRに保存されると、データ・リカバリ・アドバイザは最善の修復オプションおよびデータベースへの影響を自動的に判断します。通常、データ・リカバリ・アドバイザは、それぞれの障害または障害グループに対して手動および自動の両方の修復オプションを生成します。

データ・リカバリ・アドバイザは、自動修復オプションを提示する前に、修復を完了するために必要なメディア・コンポーネントが使用可能かどうか、およびそのオプションが特定の環境に適しているかどうかを検証します。自動修復を選択すると、Oracle Databaseによって自動的に修復されます。データ・リカバリ・アドバイザ・ツールは、修復の成功を確認し、該当する障害をクローズします。

関連項目:
データ・リカバリ・アドバイザの使用方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

Oracle Flashback Technology

Oracle Databaseでは、Oracle Flashbackテクノロジと呼ばれる機能グループが提供されており、バックアップをリストアせずに、過去のデータの状態を表示したり、特定の時間に応じてデータを前後に巻き戻すことができます。データベースの変更内容にもよりますが、フラッシュバック機能では、メディア・リカバリよりも迅速に、可用性に及ぼす影響も少なく、不要な変更を元に戻すことができます。

バックアップおよびリカバリに最適なフラッシュバック機能には、次のものがあります。

- フラッシュバック・データベース
Oracle Databaseを以前の時点まで巻き戻し、論理データの破損やユーザー・エラーによる問題を解決できます。フラッシュバック・データベースは、Data Guard、データ・リカバリ・アドバイザの補完、およびクローン・データベースの同期化にも使用できます。フラッシュバック・データベースではファイル上でメディア・リカバリはリストアまたは実行されないため、これを使用してディスク・クラッシュなどのメディア障害を修正することはできません。

- フラッシュバック表
1つのSQL文で、指定した時点まで表を巻き戻しできます。表データとともに、関連する索引、トリガーおよび制約をリストアでき、データベースはオンライン状態で、指定された表に対する変更のみが取り消されます。フラッシュバック表は、不良ディスクやデータ・セグメントと索引の非一貫性など、物理的な破損には対応していません。

- フラッシュバック・ドロップ
DROP TABLE操作の効果を無効にできます。フラッシュバック・ドロップは、ポイント・イン・タイム・リカバリなどのリカバリ・メカニズムより大幅に高速であり、最近のトランザクションの損失や停止時間も発生しません。

関連項目:

- フラッシュバック機能の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- FLASHBACK DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』および『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

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

ブロック破損とは、認識されているOracle形式ではないデータ・ブロック、または内容の一貫性が内部で保たれていないデータ・ブロックです(「データ破損」を参照)。ブロック・メディア・リカバリは、データファイルをオンラインの状態に保ったまま、破損データ・ブロックをリストアしてリカバリするテクニックです。破損が少数のブロックのみに限定されている場合は、データファイル・リカバリよりもブロック・リカバリが適しています。

関連項目:
ブロック・メディア・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

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

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

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

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

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

- 完全リカバリ
完全リカバリでは、アーカイブ・ログとオンライン・ログに含まれるREDO変更すべてがバックアップに適用されます。通常、完全メディア・リカバリは、メディア障害によりデータファイルまたは制御ファイルが破損した後に実行します。完全リカバリは、データベース、表領域またはデータファイルに対して実行できます。

- 不完全リカバリ
不完全リカバリはデータベース・ポイント・イン・タイム・リカバリとも呼ばれ、データベースの以前のバージョンを生成します。この場合、リストアされたバックアップ以後に生成されたREDOすべてを適用するわけではありません。通常、データベースのポイント・イン・タイム・リカバリは、フラッシュバック・データベースを使用できないときにユーザー・エラーを取り消す場合に実行します。

不完全リカバリを実行するには、リカバリが必要な時点より前に作成されたバックアップからデータファイルをすべてリストアし、リカバリの完了時にRESETLOGSオプションを指定してデータベースをオープンする必要があります。ログをリセットすると、新しくログ順序1からログ順序番号のストリームが開始します。

注意:
現行のデータファイルが利用可能な場合は、DBPITRのかわりにフラッシュバック・データベースを使用できます。

表領域のポイント・イン・タイム・リカバリ(TSPITR)機能を使用すると、1つ以上の表領域をデータベースの残りの部分より古い時点までリカバリできます。

関連項目:

- 「インスタンス・リカバリの概要」

- メディア・リカバリの概念の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

メモリーの管理

メモリー管理では、データベースの変化に応じて、Oracleインスタンスのメモリー構造を最適なサイズに維持します。初期化パラメータ設定により、SGAおよびインスタンスPGAメモリーの管理方法が決まります。

図18-4に、メモリー管理オプションのディシジョン・ツリーを示します。次の各項では、各オプションの詳細を説明します。

図18-4 メモリー管理方法

関連項目:
SGAおよびPGAの詳細は、第14章「メモリー・アーキテクチャ」を参照してください。

自動メモリー管理

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

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

図18-5に、オンライン・ユーザーにより発行されたジョブを必要に応じて処理したり、バッチ・ジョブを処理するデータベースを示します。自動メモリー管理を使用すると、データベースは実行するジョブのタイプに応じて、自動的にラージ・プールとデータベース・バッファ・キャッシュのサイズを調整します。

図18-5 自動メモリー管理

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

関連項目:
自動メモリー管理の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

SGAの共有メモリー管理

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

- 自動共有メモリー管理
このモードは、自動メモリー管理が無効になっている場合のデフォルトで、SGAのサイズをより直接的に制御できます。データベースは、SGAの合計サイズをターゲット・サイズにチューニングし、動的にSGAコンポーネントのサイズをチューニングします。サーバー・パラメータ・ファイルを使用すると、自動的にチューニングされたコンポーネントのサイズが、インスタンスを停止した後もOracle Databaseに記憶されます。

- 手動共有メモリー管理
このモードでは、個々のSGAコンポーネントのサイズをいくつか設定し、処理ごとに個々のSGAコンポーネントを手動でチューニングします。個々のSGAコンポーネントのサイズを完全に制御できます。自動メモリー管理および自動共有メモリー管理が両方とも無効になっている場合は、このモードがデフォルトになります。

注意:
自動メモリー管理が無効になっている場合、データベースはユーザー・ワークロードに応じて共有プールとバッファ・キャッシュの相対サイズを自動的に調整することがあります。

関連項目:
共有メモリー管理の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

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

自動メモリー管理が有効でない場合、PGAメモリー管理に次のモードを選択できます。

- 自動PGAメモリー管理
自動メモリー管理が無効で、PGA_AGGREGATE_TARGETが0(ゼロ)以外の値に設定されている場合、データベースは自動PGAメモリー管理を使用します。このモードでは、PGA_AGGREGATE_TARGETによってインスタンスPGAのターゲット・サイズが指定されます。データベースは、ターゲットに対してインスタンスPGAのサイズをチューニングし、個々のPGAのサイズを動的にチューニングします。ターゲット・サイズを明示的に設定しない場合は、適切なデフォルト値がデータベースによって自動的に構成されます。

- 手動PGAメモリー管理
自動メモリー管理が無効で、PGA_AGGREGATE_TARGETが0(ゼロ)に設定されている場合、手動PGA管理がデフォルトになります。Oracle Databaseの以前のリリースでは、DBAが作業領域の最大サイズをSQL演算子(ソートやハッシュ結合など)のタイプごとに手動で指定する必要がありました。しかし、ワークロードは常に変化するため、この技法は非常に困難であることがわかりました。Oracle Databaseでは手動によるPGAメモリー管理もサポートされていますが、自動メモリー管理を使用することをお薦めします。

関連項目:
PGAメモリー管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

メモリー管理方法の概要

表18-1で、各メモリー管理方法を説明します。自動メモリー管理を有効化しない場合は、SGAおよびPGAのそれぞれに対して個別にメモリー管理方法を構成する必要があります。

注意:
自動メモリー管理を有効化しない場合、インスタンスPGAに対しては自動PGAメモリー管理がデフォルトの方法となります。

図18-1 メモリー管理方法

インスタンス

SGA

PGA

説明

初期化パラメータ

自動

N/A

N/A

1つのインスタンス・ターゲット・サイズに基づいてインスタンスのサイズがチューニングされます。

設定項目:

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

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

N/A

自動

自動

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

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

設定項目:

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

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

- インスタンスPGAのターゲット・サイズ(PGA_AGGREGATE_TARGET)

N/A

自動

手動

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

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

設定項目:

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

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

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

N/A

手動

自動

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

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

設定項目:

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

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

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

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

- ストリーム・プール・サイズ(STREAMS_POOL_SIZE)

- インスタンスPGAのターゲット・サイズ(PGA_AGGREGATE_TARGET)

N/A

手動

手動

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

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

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

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

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

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

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

- ストリーム・プール・サイズ(STREAMS_POOL_SIZE)

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

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

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

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

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

Oracle Database Resource Manager(リソース・マネージャ)は、ユーザー、アプリケーション、およびサービスに割り当てるデータベース・リソースを細かく制御するためのインフラストラクチャです。リソース・マネージャを使用することで、オペレーティング・システムでは十分に管理できない次の多くのリソース割当ての問題が解決されます。

- 過度のオーバーヘッド

- 非効率的なスケジューリング

- 不適当なリソースの割当て

- データベース固有のリソース管理ができない状態

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

リソースは、データベース管理者が指定するリソース・プランに従ってユーザーに割り当てられます。リソース・プランは、リソース要件に従ってグループ化されたユーザー・セッションである、リソース・コンシューマ・グループ間でのリソースの分配方法を指定します。リソース・プラン・ディレクティブは、リソース・コンシューマ・グループにプランを関連付け、グループへのリソースの割当て方法を指定します。

図18-6に、昼間にOLTPアプリケーションとレポート・アプリケーションを同時に実行する組織で使用する簡単なリソース・プランを示します。現在、DAYTIMEのプランがアクティブになっており、3つのリソース・コンシューマ・グループ間でCPUリソースを割り当てます。具体的には、CPUタイムの75%がOLTPに、15%がREPORTSに、残りの10%がOTHER_GROUPSに割り当てられています。

図18-6 簡単なリソース・プラン

関連項目:
リソース・マネージャの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

Oracle Scheduler

Oracle Scheduler(スケジューラ)を使用すると、データベース管理者とアプリケーション開発者はデータベース環境で各種タスクが発生する時期と場所を制御できます。スケジューラには、企業向けの複雑なスケジューリング機能が用意されており、次の操作を実行できます。

- 時間またはイベントに基づくジョブ実行スケジュール

- ビジネス要件をモデル化する方法によるジョブ・プロセスのスケジュール

- ジョブの管理と監視

- クラスタ環境におけるジョブの実行と管理

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

スケジューラは、DBMS_SCHEDULER PL/SQLパッケージ内の一連のファンクションおよびプロシージャとして実装されています。このパッケージまたはEnterprise Managerを使用して、スケジューラ・オブジェクトを作成および操作します。スケジューラ・オブジェクトは標準データベース・オブジェクトであるため、システム権限およびオブジェクト権限により、これらのオブジェクトへのアクセスを制御できます。

図18-7に、スケジューラの基本アーキテクチャを示します。ジョブ表はすべてのジョブのコンテナであり、データベースごとにあります。ジョブ・コーディネータ・バックグラウンド・プロセスは、必要に応じて自動的に起動および停止します。ジョブ・スレーブは、ジョブの実行時間になるとジョブ・コーディネータによって起動されます(「ジョブ・キュー・プロセス(CJQ0およびJnnn)」を参照)。スレーブはジョブ表からメタデータを収集し、ジョブを実行します。

図18-7 スケジューラ・コンポーネント

関連項目:
スケジューラの詳細は、『Oracle Database管理者ガイド』を参照してください。

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

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

- CPUのボトルネック

- サイズ設定が小さすぎるメモリー構造

- I/O能力に関連する問題

- 効率の悪いまたは負荷が大きいSQL文

- SQL文のチューニング後の予期しないパフォーマンスの低下

- 同時実行性および競合に関連する問題

- データベース構成に関連する問題

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

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

- チューニング前の準備

- 定期的なデータベースの予防的チューニング

- ユーザーからのパフォーマンス上の問題報告に対応するデータベースのチューニング

- 負荷の高いSQL文の識別、チューニング、および最適化

この項では、アドバイザの使用など、Oracle Databaseパフォーマンス・チューニングの基本的な事柄について説明します。Oracle Databaseアドバイザは、領域、パフォーマンス、UNDO管理など、幅広い分野を網羅し、データベース管理に関係した主要な問題の対処方法について具体的なアドバイスを提供します。

関連項目:
Oracleパフォーマンス・メソッドの実施方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

データベースの自己監視

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

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

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

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

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

自動ワークロード・リポジトリ(AWR)は、システム、セッション、個々のSQL文、セグメント、およびサービスの累積統計などの履歴パフォーマンス・データを格納するリポジトリです。これらの統計は、パフォーマンスのチューニングなどの基礎となります。AWRは問題の検出とチューニングに利用されるデータベース統計を自動的に集計し、データベースの自己管理において重要な役割を果します。

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

図18-8 自動ワークロード・リポジトリ(AWR)

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

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

関連項目:

- 「SYSAUX表領域」

- AWRの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- 自動メンテナンス・タスクの管理方法の詳細は、『Oracle Database管理者ガイド』および『Oracle Database 2日でデータベース管理者』を参照してください。

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

自動データベース診断モニター(ADDM)は、Oracle Databaseに組み込まれている自己診断アドバイザです。AWRで取得された統計を使用して、ADDMは自動的かつ予防的にデータベース・パフォーマンスを診断し、識別された問題の解決方法を判断します。ADDMは手動でも実行できます。

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

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

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

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

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

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

インスタンス・レベルで統計を集計するAWRとは異なり、ASHはセッション・レベルで統計を集計します。アクティブ・セッションは、CPUを使用しており、アイドル待機クラスのイベントを待機していないセッションです。

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

- ADDMによって識別されない短期間のパフォーマンス上の問題の分析

- 時間、セッション、モジュール、処理、SQL IDなどの各種ディメンションまたはその組合せで範囲を絞った、または目標に応じたパフォーマンスの分析

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

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

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

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

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

自動SQLチューニングは、SQLチューニング・アドバイザを介して提供されます。SQLチューニング・アドバイザは、システム・メンテナンス・ウィンドウでメンテナンス・タスクとして自動的に実行されます。それぞれの自動実行中、アドバイザはデータベース内の負荷の大きいSQL問合せを選択し、これらの問合せに対するチューニングの推奨設定を生成します。

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

- 統計分析

- SQLプロファイリング

- アクセス・パス分析

- SQL構造分析

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

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

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

SQLアクセス・アドバイザ

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

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

SQLアクセス・アドバイザは、SQLアクセス・アドバイザ・ウィザードを使用してEnterprise Managerから実行するか、DBMS_ADVISORパッケージの起動によって実行できます。DBMS_ADVISORパッケージは、どのPL/SQLプログラムからでもコール可能な、分析およびアドバイス用の一連のファンクションおよびプロシージャで構成されます。

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

19 データベース開発者の概念

Oracle Database開発者は、データベース・アプリケーションを作成およびメンテナンスします。この項では、データベース開発者の作業内容と使用可能な開発ツールの概要について説明します。

この項には次のトピックが含まれます:

- データベース開発者の業務

- データベース開発者向けのツール

- データベース開発者のためのトピック

データベース開発者の業務

Oracle開発者は、Oracleテクノロジ・スタックを使用するアプリケーションのデータベース・コンポーネントの作成およびメンテナンスを担当します。Oracle開発者は、新しいアプリケーションを開発するか、既存アプリケーションをOracle Database環境で動作するように変換します。このため、開発者はデータベース管理者と緊密に連携し、知識や情報を共有する必要があります。

Oracleデータベース開発者は、次のタスクを担当します。

- アプリケーションに必要なデータ・モデルの実装

- スキーマ・オブジェクトの作成とデータ整合性規則の実装

- 新しい開発プロジェクトのプログラミング環境の選択

- サーバー側のPL/SQLまたはJavaサブプログラム、およびSQL文を使用するクライアント側の手続き型コードの記述

- 選択した開発ツールを使用したアプリケーション・インタフェースの作成

- グローバル・アプリケーション開発用のグローバリゼーション・サポート環境の構築

- 本番環境での開発、テスト、教育およびデプロイメント用の異なるデータベースへのアプリケーションのインスタンス化

前述のタスク、および他の多くのタスクの詳細は、『Oracle Database 2日で開発者ガイド』および『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

関連項目:
「サーバー側プログラミングの概要」

データベース開発者向けのツール

Oracleでは、データベース・アプリケーションを開発するためのいくつかのツールを提供しています。この項では、一般的に使用されるいくつかの開発ツールについて説明します。

SQL Developer

SQL Developerは、Javaで記述された、SQL*Plusのグラフィカル版ツールで、SQLおよびPL/SQLの開発を支援します。標準的なデータベース認証を使用してOracleデータベース・スキーマに接続できます。SQL Developerでは、次のことを実行できます。

- スキーマ・オブジェクトの参照、作成、編集、削除

- SQL文の実行

- PL/SQLプログラム・ユニットの編集およびデバッグ

- データの操作およびエクスポート

- レポートの作成および表示

SQL Developerは、デフォルトのOracle Databaseインストールに含まれており、無償でダウンロードできます。

関連項目:
SQL Developerの使用方法の詳細は、『Oracle Database 2日で開発者ガイド』およびOracle SQL Developerユーザーズ・ガイドを参照してください。

Oracle Application Express

Oracle Application Express(APEX)は、Oracle Database向けのWebアプリケーション開発ツールです。このツールのユーザー・インタフェースのテーマ、ナビゲーション・コントロール、フォーム・ハンドラ、柔軟なレポートなどの組込み機能を使用することで、効率よくアプリケーションを開発できます。

Oracle Application Expressはデータベースとともにインストールし、表形式のデータおよびPL/SQLコードで構成されています。アプリケーションを実行すると、Oracle Application Express PL/SQLコールに変換されたURLリクエストがブラウザから送信されます。データベースでPL/SQLが処理された後、その結果がHTMLとしてブラウザに送り返されます。このサイクルをページのリクエストまたは送信ごとに繰り返します。

Oracle Application Expressは、埋込み型PL/SQLゲートウェイと統合できます。このゲートウェイは、データベース内のXML DB HTTPサーバーで実行され、動的アプリケーションの作成に必要なインフラストラクチャを提供します。図19-1に示すように、埋込み型PL/SQLゲートウェイは、中間層をなくすことで、シンプルなアプリケーション・アーキテクチャを実現します。

図19-1 埋込み型PL/SQLゲートウェイを使用したApplication Express

関連項目:
APEXの使用方法の詳細は、『Oracle Database Application Express 2日で開発者ガイド』を参照してください。

Oracle JDeveloper

Oracle JDeveloperは、最新の業界標準Java、XML、Webサービス、およびSQLを使用するサービス指向アプリケーションを構築するための統合開発環境(IDE)を提供します。Oracle JDeveloperは、アプリケーションをモデル化、コーディング、デバッグ、テスト、プロファイリング、チューニングおよびデプロイするための機能を統合することによって、ソフトウェア開発全般を支援します。

JDeveloperでは、各種アプリケーション開発ツールのウィンドウを使用します。たとえば、Javaアプリケーションを作成する場合、Javaビジュアル・エディタやコンポーネント・パレットなどのツールを使用できます。これらのツールに加えて、JDeveloperでは、プロジェクト・コンテンツを整理および表示するための様々なナビゲーション機能を提供しています。

関連項目:

- JDeveloperの使用方法の詳細は、『Oracle Database 2日でJava開発者ガイド』を参照してください。

- JDeveloperはURL http://www.oracle.com/technetwork/developer-tools/jdev/downloads/からダウンロードできます。

Oracle JPublisher

Java Publisher(JPublisher)は、データベース表にアクセスするJavaプログラムを作成するためのシンプルで便利なツールです。JDeveloperで生成されるJavaコード・スタブによって、データベースのオブジェクト・リレーショナル構造がJavaクラスとして表現されます。これらのクラスにより、次のユーザー定義データベース・エンティティをJavaプログラムで表すことができます。

- SQLオブジェクト型

- オブジェクト参照型

- SQLコレクション型

- PL/SQLパッケージ

これらのエンティティからJavaクラスへのマッピングは、強い型指定のパラダイムで指定およびカスタマイズできるため、特定のJava型は特定のユーザー定義のSQL型に関連付けられます。また、JPublisherではPL/SQLパッケージ用のクラスも生成できます。これらのクラスには、パッケージのストアド・プロシージャをコールするラッパー・メソッドが含まれています。

関連項目:
『Oracle Database JPublisherユーザーズ・ガイド』

Oracle Developer Tools for Visual Studio .NET

Oracle Developer Tools for Visual Studio .NETは、Visual Studio .NET環境に統合された一連のアプリケーション・ツールです。これらのツールを使用すると、ユーザーはGUIを介してOracle機能にアクセスして、様々なアプリケーション開発タスクを実行でき、生産性および操作性が向上します。

Oracle Developer Toolsでは、Visual Basic、C#、およびその他の.NET言語を使用して.NETストアド・プロシージャをプログラミングおよび実装できます。これらのプロシージャは、.NET言語で記述され、SQLまたはPL/SQL文を含みます。

関連項目:
『Oracle Database 2日で.NET開発者ガイド』

データベース開発者のためのトピック

第17章では、開発者と管理者の両方にとって大切なトピックについて説明します。この項では、他の箇所で説明されていないデータベース開発者に不可欠なトピックについて説明します。

この項には次のトピックが含まれます:

- アプリケーション設計およびチューニングの原則

- クライアント側のデータベース・プログラミング

- グローバリゼーション・サポート

- 非構造化データ

アプリケーション設計およびチューニングの原則

Oracle開発者は、セキュリティおよびパフォーマンス目標を達成できるよう、データベース・アプリケーションを設計、作成、およびチューニングする必要があります。アプリケーション設計およびチューニングに関する次の原則が、ガイドラインとして役立ちます。

- Oracle Databaseの動作の理解
開発者としてOracle Databaseを使用するアプリケーションの開発にかかる時間を最小限に抑えるには、データベースのアーキテクチャおよび機能を利用する必要があります。たとえば、Oracle Databaseの同時実行性制御やマルチバージョンの読取り一貫性に関する知識が不足していると、アプリケーションによってデータ整合性が破損したり、処理速度およびスケーラビリティが低下する場合があります(「データの同時実行性と整合性の概要」を参照)。

- バインド変数の使用
問合せにバインド変数を使用すると、データベースは問合せを一度コンパイルした後で、問合せ計画を共有プールに格納します。同じ文を再度実行する場合、データベースはソフト解析を実行し、計画を再利用できます。これに対し、ハード解析は、時間がかかる上、多くのリソースを消費します(「SQLの解析」を参照)。バインド変数を使用してソフト解析を可能にすることで、効率は大幅に向上し、また、データベースはそのように設計されています。

- クライアントではなく、サーバーでの整合性制約の実装
主キーと外部キーを使用すると、複数のアプリケーションでデータを再利用できます。クライアント側で規則をコーディングすると、データベースに対する実行中、他のクライアントはこれらの規則にアクセスできません(「整合性制約の利点」を参照)。

- 代表的なデータおよびセッション・アクティビティが利用可能なテスト環境の構築
稼働中の本番環境をシミュレートするテスト環境の構築には、複数の利点があります。たとえば、アプリケーションのベンチマークを実施でき、拡張性およびパフォーマンスが十分かどうかを確認できます。また、テスト環境を使用して、データベースの変更によるパフォーマンスへの影響を測定したり、アップグレードおよびパッチが正常に動作するかどうかを確認できます。

- 高いパフォーマンス目標に沿ったデータ・モデルの設計
通常、汎用データ・モデルを使用すると、パフォーマンスは低下します。データ・モデルは、最も一般的な問合せに最大限効率よく応答できるように綿密に設計します。たとえば、データ・モデルでは、最高のパフォーマンスを示す索引のタイプを使用する必要があります。論理および物理構造の変更は困難または不可能な場合があるため、デプロイ後のチューニングはお薦めしません。

- 明確なパフォーマンス目標の定義およびメトリックの履歴レコードの保管
開発での重要な要素として、アプリケーションのパフォーマンスおよび拡張性の正確な判断があります。たとえば、予想されるユーザー負荷、1秒当たりのトランザクション、許容レスポンス時間などのメトリックを使用する必要があります。このため、パフォーマンス・メトリックの履歴レコードを保管しておくことをお薦めします。これにより、パフォーマンスを予防的また対処的に監視できます(「パフォーマンス診断およびチューニング」を参照)。

- アプリケーション・コードのインスツルメント処理
開発の際、アプリケーションにデバッグ・コードを追加することをお薦めします。トレース・ファイルが生成可能である場合、パフォーマンス上の問題をデバッグおよび診断するときに便利です。

関連項目:
データベース・アプリケーションの設計およびデプロイの考慮事項は、『Oracle Database 2日で開発者ガイド』を参照してください。

クライアント側のデータベース・プログラミング

第8章「サーバー側プログラミング: PL/SQLとJava」で説明しているように、手続き型データベース・アプリケーションでSQLを使用するには、2つの基本テクニックがあり、1つはPL/SQLおよびJavaを使用したサーバー側のプログラミングで、もう1つはプリコンパイラおよびAPIを使用したクライアント側のプログラミングです。この項では、クライアント側のデータベース・プログラミングの概要について説明します。

関連項目:
プログラミング環境を選択する方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

埋込みSQL

以前は、クライアント/サーバー・プログラムとデータベースの対話には埋込みSQLが使用されていました。この項では、埋込みSQLの使用に関するオプションについて説明します。

Oracleプリコンパイラ

一般的に、クライアント/サーバー・プログラムは、プリコンパイラを使用して記述されます(プリコンパイラは、高度なプログラムにSQL文を埋め込むためのプログラミング・ツールです)。たとえば、Oracle Pro*C/C++プリコンパイラを使用すると、CまたはC++のソース・ファイルにSQL文を埋め込むことができます。Oracleプリコンパイラは、COBOLおよびFORTRANにも使用できます。

プリコンパイラには、次のような複数の利点があります。

- 同等のOCIアプリケーションに比べて一般的にコードの記述量が少ないことによる生産性の向上

- 高度にカスタマイズされたアプリケーションを作成可能

- リソース使用、SQL文実行および各種のランタイム・インジケータの緊密な監視

- プリコンパイラにより各埋込みSQL文がOracle Databaseランタイム・ライブラリのコールへと自動変換されることによる時間の節約

- Object Type Translatorによる、Pro*C/C++アプリケーションで使用可能なCデータ型へのOracle Databaseのオブジェクト型およびコレクションのマップ

- オブジェクト型とコレクションのコンパイル時におけるタイプ・チェック機能、データベース型からCデータ型への自動型変換

SQL文を含むクライアント・アプリケーションがホスト・プログラムになります。このプログラムは、ホスト言語で記述されます。ホスト・プログラムでは、完全なSQL文と完全なC文を混合して使用でき、Cの変数または構造をSQL文に使用することもできます。SQL文を埋め込む場合は、文をEXEC SQLキーワードで開始して、セミコロンで終了する必要があります。EXEC SQL文は、Pro*C/C++によりランタイム・ライブラリSQLLIBへのコールに変換されます。

多くの埋込みSQL文は、新しい句が追加される点、またはプログラム変数が使用される点のみが同等の対話型SQLと異なります。次の例では、対話型と埋込み型のROLLBACK文を比較しています。

ROLLBACK;           -- interactive
EXEC SQL ROLLBACK;  -- embedded

これらの文は同じ働きをしますが、前者は対話型SQL環境(SQL Developerなど)で、また後者はPro*C/C++プログラムで使用します。

このプリコンパイラは入力としてホスト・プログラムを受け入れ、埋込みSQL文を標準のデータベース・ランタイム・ライブラリ・コールに変換し、通常の方法でコンパイル、リンクおよび実行できるソース・プログラムを生成します。図19-2に、プリコンパイラを使用したプログラム開発の典型的な手順を示します。

図19-2 プリコンパイラを使用したプログラム開発

関連項目:

- Pro*C/C++プリコンパイラの詳細は、『Pro*C/C++プログラマーズ・ガイド』を参照してください。

- 『Pro*FORTRAN Supplement to the Oracle Precompilers Guide』

SQLJ

SQLJは、SQL文をJavaソース・コードに埋め込むためのANSI SQL-1999規格です。SQLJは、クライアント側でJavaからSQLへのデータ・アクセスに使用されるJava Database Connectivity(JDBC)APIにかわるシンプルなAPIを提供します。

SQLJインタフェースは、Java版のPro*インタフェースです。SQL文をJavaソース・コードに挿入します。その後、Javaソース・ファイルをSQLJトランスレータに送信すると、SQLJトランスレータによって埋込みSQLが純粋なJDBCベースのJavaコードに変換されます。

関連項目:
「SQLJ」

クライアント側のAPI

現在は、多くの開発者がAPIを使用してデータベース・アプリケーションにSQLを埋め込みます。たとえば、Oracle Databaseと通信するプログラムの有効化によく使用されるOpen Database Connectivity(ODBC)およびJDBCという2つのAPIがあります。その他、クライアント側のプログラミングによく使用されるOracle Call Interface(OCI)およびOracle C++ Call Interface(OCCI)という2つのAPIもあります。

OCIおよびOCCI

プリコンパイラのかわりとして、OracleではOCI APIおよびOCCI APIを提供しています。OCIでは、Cなどのホスト・プログラミング言語を使用して、データベース内のデータおよびスキーマを操作できます。OCCIは、オブジェクト指向のインタフェースで、C++を使用する場合に適しています。どちらのAPIを使用する場合も、開発者はシステム固有のサブプログラムを起動して、Oracle Databaseにアクセスし、SQLの実行を制御できます。

場合によっては、レベルの高いインタフェースよりも、OCIの方が高いパフォーマンスを示すことや、機能が豊富なことがあります。OCIおよびOCCIでは、次のような多くの機能を提供しています。

- Oracle Database全体で使用可能なすべてのSQL DDL、DML、問合せおよびトランザクション制御機能のサポート

- ディスク領域が問題になる場合のアプリケーションをデプロイする方法であるインスタント・クライアント

- Cアプリケーションからのスレッド管理、接続プール、グローバリゼーション・ファンクションおよびデータのダイレクト・パス・ロード

OCIおよびOCCIには、動的ランタイム・ライブラリ(OCILIB)という形式で、標準データベース・アクセスおよび検索関数のライブラリが提供されています。このライブラリは、実行時にアプリケーション内でリンクを設定できます。このように、非データベース・アプリケーションと同様の方法でOCIまたはOCCIプログラムをコンパイルおよびリンクすると、別の処理やプリコンパイル作業が不要になります。図19-3に、開発プロセスを示します。

図19-3 OCIまたはOCCIを使用した開発プロセス

関連項目:

- 『Oracle Call Interfaceプログラマーズ・ガイド』

- 『Oracle C++ Call Interfaceプログラマーズ・ガイド』

ODBCおよびJDBC

ODBCは、アプリケーションをデータベースに接続し、SQL文を準備して実行するための標準APIです。ODBCは、プログラミング言語、データベース、およびオペレーティング・システムに依存しません。ODBCの目的は、任意のアプリケーションが任意のデータベースのデータにアクセスできるようにすることです。

データベース・ドライバは、アプリケーションとデータベースの間にあるソフトウェアです。このドライバは、アプリケーションによるAPIコールをデータベースが処理可能なコマンドへと変換します。ODBCドライバを使用することで、スプレッドシートに格納されているデータなど、あらゆるデータ・ソースにアプリケーションからアクセスできます。ODBCドライバは、ODBC標準とデータベースの間のマッピングをすべて実行します。

Oracleが提供するOracle ODBCドライバを使用すると、ODBCに準拠したアプリケーションはOracle Databaseにアクセスできます。たとえば、Visual Basicで記述されたアプリケーションでは、ODBCを使用してOracle Database表の問合せや更新を実行できます。

JDBCは、JavaアプリケーションがOracle Databaseと対話するための下位レベルのJavaインタフェースです。ODBCと同様、JDBCもベンダーに依存しないAPIです。Sun社により定義されるJDBC標準は、java.sqlインタフェースを介して実装されます。

JDBC標準では、個々のプロバイダが独自のJDBCドライバを使用して標準を実装および拡張できます。Oracleでは、クライアント側のプログラミング用に次のJDBCドライバを提供しています。

- JDBC Thinドライバ
このPure Javaドライバは、Oracleクライアントがインストールされていないクライアント側にインストールします。これはプラットフォームに依存せず、アプレットおよびアプリケーションの両方で使用できます。

- JDBC OCIドライバ
このドライバは、Oracleクライアントがインストールされているクライアント側にインストールします。これはアプリケーションでのみ使用できます。JDBC OCIドライバは、CおよびJavaの両方で記述されており、JDBCコールをOCIコールに変換します。

次のスニペットは、JDBC OCIドライバを使用してStatementオブジェクトを作成し、dual表に問合せを実行するJavaプログラムのスニペットです。

// Create a statement
Statement stmt = conn.createStatement();

// Query dual table
ResultSet rset = stmt.executeQuery("SELECT 'Hello World' FROM DUAL");

関連項目:

- JDBCの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』および『Oracle Database 2日でJava開発者ガイド』を参照してください。

- 『Oracle Database Gateway for ODBCユーザーズ・ガイド』

グローバリゼーション・サポート

Oracle Databaseグローバリゼーション・サポートを使用すると、ネイティブ言語でデータを格納、処理および取得できます。このように、世界中から同時にアクセスおよび実行できる多言語アプリケーションおよびソフトウェアを開発できます。

グローバル・データベース・アプリケーションを記述する開発者は、次のことを実行する必要があります。

- Oracle Databaseグローバリゼーション・サポートのアーキテクチャ(各キャラクタ・セット、地域、言語、言語ソート定義の特性など)の理解

- 中間層プログラミング環境のグローバリゼーション機能(データベースのロケール・モデルとの対話および同期方法など)の理解

- 異なるオペレーティング・システム、キャラクタ・セット、およびロケール要件で実行されている複数のクライアントを同時にサポートするコードの設計と記述

たとえば、アプリケーションはネイティブ・ユーザーが使用する言語およびロケールのプリファレンスに基づいてユーザー・インタフェースの内容をレンダリングしたり、データを処理する必要がある場合があります。たとえば、アプリケーションは、ユーザーに設定の変更を求めることなく、マルチバイトの漢字データを処理し、該当する地域の形式でメッセージや日付を表示して、7ビットASCIIデータを処理する必要があります。

関連項目:
グローバリゼーションの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

グローバリゼーション・サポート環境

グローバリゼーション・サポート環境には、クライアント・アプリケーションとデータベースが含まれます。言語に依存する処理は、クライアントとサーバー上でパラメータおよび環境変数を設定することによって制御します(クライアントとサーバーは別々の場所に存在する場合もあります)。

注意:
以前のリリースでは、Oracleではグローバリゼーション・サポート機能は各国語サポート(NLS)機能と呼ばれていました。実際、NLSはグローバリゼーション・サポートの一種で、NLSを使用して、各国語を選択し、特定のキャラクタ・セットでデータを格納できます。

Oracle Databaseでは、次の機能に対するグローバリゼーション・サポートを提供しています。

- ネイティブ言語および地域

- 日付、時間、数字、および通貨のローカル形式

- 暦法(グレゴリオ暦、和暦、元号暦、タイ仏教暦など)

- Unicodeなどの複数のキャラクタ・セット

- キャラクタ・セマンティクス

キャラクタ・セット

キャラクタ・セットはグローバリゼーション・サポートの主要なコンポーネントであり、コンピュータ画面に文字を表示するときに使用されるコード体系です。アプリケーション開発においては、次の違いが重要です。

- データベース・キャラクタ・セットによって、データベースで表現される言語が決定します。このキャラクタ・セットは、データベースの作成時に指定します。

注意:
データベースを作成した後でキャラクタ・セットを変更すると、一般的に、時間およびリソースの面で大きなコストがかかります。この操作では、データベース全体のエクスポートおよび再インポートによる、すべての文字データの変換が必要になる場合があります。

- クライアント・キャラクタ・セットは、クライアント・アプリケーションによって入力および表示されるデータに使用されるキャラクタ・セットです。クライアントとデータベースのキャラクタ・セットは異なる場合もあります。

特定の文字グループ(アルファベット文字、表意文字、記号、句読点、制御文字など)をキャラクタ・セットとしてエンコードできます。エンコードされたキャラクタ・セットでは、セット内の各文字について、コード・ポイントまたはエンコード値と呼ばれる一意の数値コードが割り当てられます。グローバル環境では、異なるキャラクタ・セット間でデータの変換が必要になる可能性があるため、このコード・ポイントが重要になります。

コンピュータ業界では、多数のエンコードされたキャラクタ・セットが使用されています。これらのセットでは、使用可能な文字数、使用可能な文字および各文字に割り当てられているコード・ポイントなどが異なります。Oracle Databaseでは、各国の規格、国際規格およびベンダー固有のエンコードされたキャラクタ・セット規格のほとんどすべてをサポートしています。

Oracle Databaseでは、次のクラスのエンコードされたキャラクタ・セットをサポートしています。

- シングルバイト・キャラクタ・セット
各文字が占めるバイト数は、1バイトです。7ビット・キャラクタ・セットの例には、US7ASCIIなどがあります。8ビット・キャラクタ・セットの例には、WE8DECなどがあります。

- マルチバイト・キャラクタ・セット
1文字が2バイト以上を占めます。一般的に、マルチバイト・キャラクタ・セットは、アジア言語に使用されます。

- Unicode
ユニバーサル・エンコードされたキャラクタ・セットでは、1つのキャラクタ・セットで任意の言語の情報を格納できます。Unicodeでは、プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が割り当てられています。

関連項目:
キャラクタ・セットの移行の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

ロケール固有の設定

ロケールとは、システムまたはプログラムが実行されている、言語的および文化的な環境を表します。NLSパラメータは、クライアントとデータベースの両方におけるロケール固有の動作を指定します。データベース・セッションでは、クライアントにかわって文を実行するとき、NLSの設定が使用されます。たとえば、データベースでは、クライアントの地域の書式で3桁区切りを使用します。

一般的に、クライアント・ホストのNLS_LANG環境変数によって、サーバー・セッションとクライアント・アプリケーションの両方のロケールが指定されます。このプロセスは、次のとおりです。

1. クライアント・アプリケーションは起動すると、環境設定に従ってクライアントのNLS環境を初期化します。
Oracle Developerアプリケーションの表示形式の設定など、ローカルで実行されるすべてのNLS操作にこれらの設定が使用されます。

2. クライアントは、データベースに接続すると、NLS_LANGで定義された情報をデータベースに伝達します。

3. データベース・セッションは、クライアントから伝達された設定に基づいてNLS環境を初期化します。
クライアントにより設定が指定されていなかった場合、セッションは初期化パラメータ・ファイルの設定を使用します。データベースが初期化パラメータの設定を使用するのは、クライアントがNLS設定をまったく指定しなかった場合のみです。クライアントが一部のNLS設定を指定した場合、残りのNLS設定はデフォルトの設定になります。

クライアント・アプリケーションにかわって開始された各セッションは、他のセッションと同じまたは異なるロケールで実行されます。たとえば、一方のセッションではドイツ語ロケールが使用され、別のセッションではフランス語ロケールが使用される場合があります。また、各セッションで同じまたは異なる言語要件が指定されます。

表19-1に、異なるNLS_LANG設定を使用する2つのクライアントを示します。ユーザーは、各ホスト上でSQL*Plusを起動して同じデータベースにhrとしてログオンし、同時に同じ問合せを実行します。各セッションの結果は、浮動小数点数に関するロケール固有のNLS設定のために異なります。

表19-1 ロケール固有のNLS設定

t

クライアント・ホスト1

クライアント・ホスト2

t0

$ export NLS_LANG=American_America.US7ASCII

$ export NLS_LANG=German_Germany.US7ASCII

t1

$ sqlplus /nolog
SQL> CONNECT hr@proddb
Enter password: *******
SQL> SELECT 999/10 FROM DUAL;

999/10
----------
99.9

$ sqlplus /nolog
SQL> CONNECT hr@proddb
Enter password: *******
SQL> SELECT 999/10 FROM DUAL;

999/10
----------
99,9

関連項目:
NLS設定の詳細は、『Oracle Database 2日でJava開発者ガイド』および『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

Oracle Globalization Development Kit

Oracle Globalization Development Kit(GDK)は、開発プロセスを簡略化し、グローバル環境サポートが必要なインターネット・アプリケーションの開発コストを削減します。GDKには、Java用とPL/SQL用の包括的なプログラミングAPIとコード・サンプルが用意されています。また、グローバル・アプリケーションの構築時に直面する設計、開発および配置に関する数多くの問題の対処方法を解説したドキュメントも用意されています。

GDKは主に、GDK for JavaとGDK for PL/SQLの2つからなります。GDK for Javaは、Javaアプリケーションに対してグローバリゼーション・サポートを提供します。GDK for PL/SQLは、PL/SQLプログラミング環境に対してグローバリゼーション・サポートを提供します。これらの2つの要素で提供される機能は同じではありません。

関連項目:
『Oracle Databaseグローバリゼーション・サポート・ガイド』

非構造化データ

従来のリレーショナル・モデルは、単純な表に格納できる単純な構造化データを処理します。Oracle Databaseでは、標準構成要素に分解できない非構造化データもサポートしています。非構造化データには、テキスト、グラフィック・イメージ、ビデオ・クリップ、サウンド・ウェーブなどが含まれます。

Oracle Databaseには、非構造化コンテンツを処理するためのデータ型が組み込まれています。これらのデータ型は、データベースではシステム固有の型として表示され、SQLを使用して問い合せることができます。

Oracle DatabaseにおけるXMLの概要

Oracle XML DBは、高パフォーマンスのXMLの格納と取得に関連する一連のOracle Databaseテクノロジです。XML DBは、SQLデータ・モデルとXMLデータ・モデルの相互運用が可能な方法でサポートするシステム固有のXMLを提供します。

Oracle XML DBは、アプリケーションで処理されるデータの一部または全部がXMLで表現されているJavaまたはPL/SQLアプリケーションに適しています。たとえば、多数のXML文書を収集、生成、検証および検索する必要があるアプリケーションなどに適しています。

Oracle XML DBでは、次のような多くの機能を提供しています。

- XML文書をデータベース内で表すことができ、SQLによるアクセスを可能にするシステム固有のXMLTypeデータ型

- XMLスキーマ、XPath、XQuery、XSLT、DOMなどのXML標準のサポート

- 高度に構造化されたデータから完全な非構造化データまで、すべての形式のXMLデータをサポートするXMLIndex

例19-1では、XMLType型のorders表を作成します。また、この例では、ホスト・コンピュータ上の物理ディレクトリに対するデータベース内の論理名となるSQLディレクトリ・オブジェクトも作成します。このディレクトリにXMLファイルが格納されます。次に、purchaseOrder.xmlファイルからorders表にXMLコンテンツを挿入します。

例19-1 XMLType

CREATE TABLE orders OF XMLType;
CREATE DIRECTORY xmldir AS path_to_folder_containing_XML_file;
INSERT INTO orders VALUES (XMLType(bfilename('XMLDIR', 'purchaseOrder.xml'),
nls_charset_id('AL32UTF8')));

Oracle XML Developer's Kit(XDK)には、XML文書(ファイルシステム上にあるかデータベース内にあるかは不問)の読取り、操作、変換および表示のための基本ビルディング・ブロックが用意されています。APIおよびツールは、Java、CおよびC++で使用できます。Oracle XDKは本番環境で全面的にサポートされ、業務目的で再配布するためのライセンスが付属しています。

関連項目:

- 『Oracle XML DB開発者ガイド』

- 『Oracle XML Developer's Kitプログラマーズ・ガイド』

- 『Oracle Database XML Java API Reference』

LOBの概要

ラージ・オブジェクト(LOB)データ型を使用すると、非構造化データの大きなブロックを、バイナリ形式または文字形式で格納し、操作できます。LOBを使用すると、個々のデータに対する効率的なランダム・アクセスが可能です。

内部LOB

内部LOBは、データを外部ファイルではなく、データベース自体に格納します。内部LOBは、次のとおりです。

- テキスト・ファイルまたはXMLファイルなどの大量のテキストをデータベース・キャラクタ・セットで格納するCLOB(文字LOB)

- Unicodeデータを格納するNCLOB(各国語キャラクタ・セットLOB)

- 大量のバイナリ情報をビット・ストリームとして格納し、キャラクタ・セットの変換を行わないBLOB(バイナリLOB)

データベースは、他のデータ型とは異なる方法でLOBを格納します。LOB列を作成すると、暗黙的にLOBセグメントとLOB索引が作成されます(「ユーザー・セグメントの作成」を参照)。LOBセグメントとLOB索引は常に一緒に格納され、これらを含む表領域は、表を含む表領域と異なる場合があります。

注意:
データベースは、少量のLOBデータを個別のLOBセグメントにではなく、表自体に格納できる場合があります。

LOBセグメントは、データをチャンクと呼ばれる単位に分割して格納します。チャンクは、論理的に連続するデータ・ブロックのセットであり、LOBに割り当てられる最小単位のデータです。表の行には、LOB索引を指すLOBロケータと呼ばれるポインタが格納されます。表に問合せが実行されると、データベースはLOB索引を使用して、LOBチャンクの場所をすばやく特定します。

データベースは、他のデータとは異なる方法で、LOBセグメントの読取り一貫性を管理します(「読取り一貫性とUNDOセグメント」を参照)。UNDOデータを使用して変更を記録するかわりに、データベースはビフォア・イメージをセグメント自体に格納します。トランザクションによってLOBに変更が加えられると、データベースは新しいチャンクを割り当て、古いデータを元の場所に残します。トランザクションがロールバックされると、データベースも古いチャンクを指す索引まで変更をロールバックします。

外部LOB

BFILE(バイナリ・ファイルLOB)は、データベースがオペレーティング・システム内のファイルを指定するポインタを格納するため、外部LOBです。外部データは、読取り専用です。

BFILEは、ディレクトリ・オブジェクトを使用してデータを検索します。使用領域量は、ディレクトリ・オブジェクト名の長さ、およびファイル名の長さによって決まります。

バイナリ・ファイルはデータベース外のファイルのため、BFILEでは内部LOBと同じ読取り一貫性メカニズムを使用できません。ファイルのデータに変更が加えられると、再度同じバイナリ・ファイルから読み込んだ場合に結果が異なることがあります。

SecureFiles

SecureFilesはLOBデータ型の1つであり、Oracle Databaseの利点を保持しながら、従来のファイルシステムと比べ、ファイル・データの配布を高速化するように設計されています。SECUREFILE LOBパラメータを使用すると、通常はハイエンドなファイルシステムに見られる、重複除外、圧縮、暗号化、ジャーナルなどの拡張機能を使用できます。

関連項目:

- 「Oracleデータ型」

- LOBデータ型の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

Oracle Textの概要

Oracle Text(Text)は、Oracle Databaseに統合されている、高速で正確な全テキスト検索テクノロジです。Oracle Textは、ファイルシステム、データベースまたはWeb上に格納されているすべてのドキュメントまたはテキスト形式のコンテンツに索引を付けます。これらのドキュメントは、テキスト形式のコンテンツ、メタデータまたは属性に基づいて検索できます。

Oracle Textには、次の利点があります。

- Oracle Textを使用すると、テキスト検索と通常のデータベース検索を1つのSQL文にまとめることができます。Oracle Textの索引はデータベースにあり、Oracle Textの問合せはOracle Databaseプロセス内で実行されます。オプティマイザは、どのような問合せについても最善の実行計画を選択でき、テキストと構造化された基準を使用する非定型問合せに最高のパフォーマンスを提供します。

- Oracle Textは、XMLデータにも使用できます。特に、XMLIndexとOracle Textの索引機能を組み合せることで、XML索引と全テキスト索引の両方の利点を活用できます。

- Oracle TextのSQL APIにより、単純で直感的な方法でOracle Text索引を作成、メンテナンスしてテキスト検索を実行できます。

ユースケースとして、電子機器を販売するオークション・サイトのカタログ索引を作成する必要があるとします。新しい在庫が毎日追加されます。品物の説明、入札日、価格をともに格納する必要があります。アプリケーションは、複合問合せに対して適切な時間で応答する必要があります。最初に、catalog表を作成し、データを入力します。次に、Oracle Textを使用してCTXCAT索引を作成し、この索引は、SELECT ... WHERE CATSEARCH文のCATSEARCH演算子を使用した問合せが可能です。

図19-4に、catalog表とそのCTXCAT索引、およびCATSEARCH演算子を使用して索引を問い合せているカタログ・アプリケーションとの関係を示します。

図19-4 カタログ問合せアプリケーション

関連項目:

- 『Oracle Textアプリケーション開発者ガイド』および『Oracle Textリファレンス』

- XMLデータを対象とした全文検索の実行方法の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

Oracle Multimediaの概要

Oracle Multimediaを使用すると、Oracle Databaseにおいて、イメージ、Digital Imaging and Communications in Medicine(DICOM)規格に準拠した医療画像、オーディオおよびビデオ・データを他の企業情報と統合された方法で格納、管理および取得できます。Oracle Multimediaでは、次の操作を実行するためのオブジェクト型およびメソッドを提供しています。

- マルチメディア・データからのメタデータおよび属性の抽出

- アプリケーションによって作成されたメタデータの、イメージおよびDICOMデータへの埋込み

- Oracle Database、Webサーバー、ファイルシステム、およびその他のサーバーからのマルチメディア・データの取得と管理

- イメージおよびDICOMデータ上のサムネイル生成などの操作

- DICOMデータの匿名化

- DICOMデータがユーザー指定の検証ルールに準拠しているかどうかのチェック

関連項目:

- 『Oracle Multimediaユーザーズ・ガイド』および『Oracle Multimediaリファレンス』

- 『Oracle Multimedia DICOM開発者ガイド』および『Oracle Multimedia DICOM Java API Reference』

- 『Oracle Multimedia Java API Reference』および『Oracle Multimedia Servlets and JSP Java API Reference』

Oracle Spatialの概要

Oracle Spatial(Spatial)にはSQLスキーマおよび関数が用意されており、Oracle Database内にある空間機能の集まりを容易に格納、取得、更新および問合せできます。Oracle Spatialを使用すると、ロケーション対応アプリケーションや地理情報システム(GIS)・アプリケーションのユーザーは、より容易に空間データを管理できます。

空間データの一例は、ロード・マップです。空間データは、オブジェクトの地球上の位置(緯度や経度など)をマップ上に示します。マップがレンダリングされるときには、この空間データを使用してオブジェクトの位置が2次元の紙上に投影されます。通常、この相対的空間データの格納、取得およびレンダリングにはGISが使用されます。空間データがOracle Databaseに格納されている場合は、簡単に操作し、取り出して、他のデータに関連付けることができます。

関連項目:
『Oracle Spatial開発者ガイド』

用語集

アクセス・ドライバ

外部表インフラストラクチャで、データベースに対する外部データを解析するAPI。アクセス・ドライバはデータベースの内部で動作し、データベースはアクセス・ドライバを使用して外部表のデータを読み取ります。

アクセス・パス

データベースからデータを取り出す方法。たとえば、索引を利用した問合せと全表スキャンを利用した問合せでは、使用されるアクセス・パスが異なります。

アクティブなトランザクション

開始した後、まだコミットまたはロールバックされていないトランザクション。

ADDM

自動データベース診断モニター。データベースがそれ自体のパフォーマンスを診断し、識別された問題の解決方法を決定できるようにするOracle Databaseインフラストラクチャ。

ADR

自動診断リポジトリ。ネットワークのトレースやロギングに関する情報などの診断情報を管理するための、ファイルベースの階層データストア。

アラート・ログ

データベースのメッセージとエラーの履歴ログが記録されたファイル。アラート・ログはADRに格納されます。

アンチ結合

述語の右側に対応する行を持たない述語の左側の行を戻す結合。

アプリケーション・アーキテクチャ

データベース・アプリケーションがOracleデータベースに接続されているコンピューティング環境。データベースの最も一般的なアーキテクチャは、クライアント/サーバーと複数層の2種類です。

アプリケーション・ドメイン索引

アプリケーション固有のカスタマイズされた索引。

アーカイブREDOログ・ファイル

Oracle DatabaseによってアーカイブされたオンラインREDOログのメンバー。メディア・リカバリ時にアーカイブREDOログ・ファイルをデータベース・バックアップに適用できます。

ARCHIVELOGモード

オンラインREDOログをアーカイブできるデータベースのモード。

昇順索引

データが昇順に格納される索引。デフォルトでは、文字データは値の各バイトに含まれるバイナリ値に従って順序付けられ、数値データは最小の数から最大の数へ、日付は古い値から新しい値への順になります。

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

「ADDM」を参照してください。

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

「ADR」を参照してください。

自動UNDO管理モード

専用UNDO表領域のUNDO領域が自動的に管理されるデータベースのモード。

「手動UNDO管理モード」を参照してください。

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

「AWR」を参照してください。

AWR

自動ワークロード・リポジトリ(AWR)。すべてのOracleデータベースに組み込まれているリポジトリ。Oracle Databaseでは、定期的に、稼働統計とワークロード情報のスナップショットが作成され、作成されたスナップショットがAWRに格納されます。

Bツリー索引

ツリーを上下反転させたような形状の索引。Bツリー索引には、検索用のブランチ・ブロックと、値を格納するリーフ・ブロックの2種類のブロックがあります。リーフ・ブロックには、すべての索引付きデータ値と、実際の行を検索するための対応するROWIDが含まれています。Bはbalanced(バランスが取れた)の略で、これは、すべてのリーフ・ブロックが自動的に同じ深さになるためです。

バックグラウンド・プロセス

クライアント・プロセスごとに実行される複数のOracleプログラムによって処理されるファンクションを統合するプロセス。バックグラウンド・プロセスは、I/Oを非同期的に実行し、他のOracleプロセスを監視します。

関連項目: 「インスタンス」、「Oracleプロセス」

バインド変数

SQL文の中のプレースホルダで、SQL文を正常に実行するために、有効な値または値のアドレスと置換される必要があります。バインド変数を使用すると、実行時に入力データまたはパラメータを受け取るSQL文を作成できます。次の例は、v_empidをバインド変数として使用した問合せです。

SELECT * FROM employees WHERE employee_id = :v_empid;

ビットマップ索引

各索引キーのビットマップがROWIDのリストのかわりにデータベースに格納されるデータベース索引。

ビットマップ結合索引

2つ以上の表を結合するためのビットマップ索引。

ビットマップ・マージ

ビットマップ索引スキャンで取得したビットマップをマージする操作。たとえば、gender列とDOB列にビットマップ索引が設定されていて、問合せの述語がWHERE gender='F' AND DOB > 1966である場合、データベースでビットマップ・マージを使用できます。

ブロック破損

認識されているOracle形式ではないか、または内容に内部的な一貫性がないデータ・ブロック。

ブロック・ヘッダー

データ・ブロックの一部分で、ブロックのタイプやブロックのアドレスの情報が含まれます。また、トランザクション情報が含まれている場合もあります。

ブロック・オーバーヘッド

データ・ブロック内の領域で、ブロックの管理に必要なメタデータが格納されています。オーバーヘッドには、ブロック・ヘッダー、表ディレクトリおよび行ディレクトリが含まれています。

ブランチ・ブロック

Bツリー索引で、データベースが検索に使用するブロック。リーフ・ブロックが索引エントリを格納します。Bツリー索引の上位ブランチ・ブロックには、下位レベルの索引ブロックを指す索引データが含まれます。

バッファ

データベース・バッファ・キャッシュ内のメイン・メモリー・アドレス。バッファには、ディスクから読み取られた最新のブロックおよび最近使用されたブロックがキャッシュされます。データベースで新しいブロックが必要になったときは、古いデータ・ブロックを新しいデータ・ブロックと置換できます。

バイト・セマンティクス

文字列を一連のバイトとして取り扱うこと。文字列へのオフセットと文字列長はバイトで表されます。

キャッシュ・リカバリ

インスタンス・リカバリのフェーズ。Oracle Databaseにより、コミット済かどうかを問わず、オンラインREDOログ内のすべての変更が、対象となるデータ・ブロックに適用されます。

カーディナリティ

表の行数に対する個別値の数の比率。100万行を持つ表内で個別値が2つしかない列の場合、カーディナリティは低くなります。

文字エンコーディング

指定されたレパートリの各文字とコード単位を組み合せて、データ記憶域を可能にするコード。

キャラクタ・セマンティクス

文字列を一連の文字として取り扱うこと。文字列へのオフセットと文字列長は文字(文字コード)数で表されます。

キャラクタ・セット

コンピュータ画面に文字を表示するために使用するコード体系。

チェックポイント

1. チェックポイント位置を表すデータ構造で、チェックポイント位置は、インスタンス・リカバリの開始位置を示すREDOスレッド内のSCNです。チェックポイントは、制御ファイルと各データファイルのヘッダーに記録される重要なリカバリ要素です。

2. データベース・バッファ・キャッシュ内のディスクに書き込まれていないデータ・ブロックをディスクに書き込むこと。データベース・ライター(DBW)・プロセスは、ブロックをディスクに書き込み、バッファ・キャッシュとデータファイルを同期します。

クライアント

クライアント/サーバー・アーキテクチャにおいて、ユーザーと対話するフロントエンドのデータベース・アプリケーション。クライアント部分ではデータをアクセスしません。

クライアント・プロセス

アプリケーションまたはOracleツールのコードを実行するプロセス。ユーザーがSQL*Plusなどのクライアント・アプリケーションを実行すると、オペレーティング・システムではクライアント・プロセスを作成し、アプリケーションを実行します。

関連項目: 「Oracleプロセス」

クライアント/サーバー・アーキテクチャ

2つのCPU間で処理を分割するソフトウェア・アーキテクチャ。1つのCPUは、トランザクションでクライアントとして機能し、サービスを要求して受け取ります。もう1つはトランザクションでサービスを提供するサーバーとして機能します。

クラスタ・ファイル・システム

高パフォーマンスのサービスをクライアントに提供するために連携するサーバーのクラスタによる分散ファイル・システム。

クラスタ索引

クラスタ・キーのBツリー索引。

クラスタ・キー

表クラスタで、クラスタ化表で共有される1つ以上の列。たとえば、employeesおよびdepartments表はdepartment_id列を共有しています。表クラスタの作成時と表クラスタに追加されるすべての表の作成時にクラスタ・キーを指定します。

列

表内の垂直方向の領域で、データ・ドメインを表します。表定義には、表名と一連の列が含まれています。各列には名前とデータ型があります。

コミット

データベース・トランザクションを終了し、トランザクションで実行されたすべての変更を永続的にするアクション。

コンポジット索引

表の複数の列の索引。

コンポジット・パーティション化

パーティション化計画では、1つのデータ配分方法で表をパーティション化し、別のデータ配分方法を使用して、各パーティションをさらに小さなサブパーティションに分割します。

圧縮ユニット

ハイブリッド列圧縮で、行の集合を格納する論理的な構造。表にデータをロードする場合、データベースでは、行のグループは列形式で、それぞれの列の値としてまとめて圧縮されて格納されます。データベースでは、一連の行の列データが圧縮された後、そのデータが圧縮ユニットに収められます。

同時実行性

多数のユーザーによる同一のデータへの同時アクセス。マルチユーザー・データベース管理システムには、データが正しく更新または変更され、データ整合性が維持されるように、適切な同時実行性制御が必要です。

関連項目: 「データ整合性」

条件

SQL文内の1つ以上の式および論理演算子で、TRUE、FALSEまたはUNKNOWNの値を戻します。たとえば、1=1という条件は、常にTRUEとなります。

接続

クライアント・プロセスとOracleデータベース・インスタンスとの間の通信経路。

関連項目: 「セッション」

接続プーリング

共有サーバーとの制限された数のプロトコル接続を介してセッションの数を最大化する、リソース使用率とスケーラビリティのための機能。

一貫性バックアップ

メディア・リカバリを実行せずにRESETLOGSオプションを指定してオープンできるデータベース全体のバックアップ。つまり、このバックアップでは一貫性を保つためにREDOを適用する必要はありません。

関連項目: 「非一貫性バックアップ」

コンテキスト

アプリケーションによって定義された、アプリケーションを検証および保護する一連の属性。CREATE CONTEXTというSQL文により、コンテキストの名前空間が作成されます。

制御ファイル

データベースの物理構造を記録し、REDOログ・ファイルの名前と位置、データベース作成のタイムスタンプ、現行のログ順序番号、チェックポイント情報などを含むバイナリ・ファイル。

キューブ

同一のディメンションおよびその他の共通する特性を持つ、メジャーの編成。キューブのエッジにはディメンション・メンバーが含まれ、キューブの本体にはデータ値が含まれています。

カーソル

PGAのプライベートSQL領域のハンドルまたは名前。カーソルはプライベートSQL領域と密接に関連しているため、これらの用語は同じ意味で使用されることがあります。

データベース

1つの単位として取り扱われる組織化されたデータの集まり。データベースの目的は、関連する情報の格納や取出しです。すべてのOracleデータベース・インスタンスは、その存続期間において1つのデータベースにのみアクセスします。

データベース・アクセス制御

データ・アクセスおよびデータベース・アクティビティの制限。たとえば、データベース管理者は、指定された表への問合せや指定されたデータベース・コマンドの実行を制限できます。

データベース・アプリケーション

データベースと対話してデータのアクセスと操作を行うソフトウェア・プログラム。

データベース認証

ユーザーがデータベースに資格証明を提示し、この資格証明をデータベースが検証してデータベースへのアクセスを許可するプロセス。

データベース・バッファ・キャッシュ

システム・グローバル領域(SGA)でデータ・ブロックのコピーを保持している部分。インスタンスに同時接続されたクライアント・プロセスはすべて、バッファ・キャッシュへのアクセスを共有します。

データベース・インスタンス

システム・グローバル領域(SGA)とバックグラウンド・プロセスの組合せ。インスタンスは1つのデータベースのみに関連付けられます。Oracle Real Application Clusters構成では、複数のインスタンスが1つのデータベースに同時にアクセスします。

データベース・リンク

スキーマ・オブジェクトでは、1つのデータベース内のスキーマ・オブジェクトにより、ユーザーは別のデータベースのオブジェクトにアクセスできます。

データベース管理システム(DBMS)

データの格納、編成および取得を制御するソフトウェア。

データベース・オブジェクト

SQLで操作できるデータベース内のオブジェクト。表や索引などのスキーマ・オブジェクトは、スキーマに常駐します。ディレクトリやロールなどの非スキーマ・オブジェクトは、スキーマに常駐しません。

データベース・セキュリティ

ユーザー認証、暗号化、アクセス制御および監視が含まれるデータベース管理機能。

データベース・サーバー

マルチユーザー環境において、複数のユーザーが同時に同じデータにアクセスできるように大量のデータを確実に管理するサーバー。権限のないアクセスに対して保護機能を備えながら、障害のリカバリについても効率のよい解決方法を提供します。

データベース・サービス

1つ以上のデータベース・インスタンスの名前付きの表現。Oracle Databaseのサービス名は、通常、そのグローバル・データベース名です。クライアントは、サービス名を使用して、1つ以上のデータベース・インスタンスに接続します。

データベース・ユーザー

Oracleデータベースへのログインに使用できるアカウント。

データベース・ライター(DBW)

データベース・バッファ・キャッシュ内のバッファ・データをデータファイルに書き込むバックグラウンド・プロセス。

データ・ブロック

Oracle Database内にあるデータ記憶域の最小論理単位。データ・ブロックは、Oracleブロックまたはページとも呼ばれます。1つのデータ・ブロックは、ディスク上の特定のバイト数の物理領域に対応します。

関連項目: 「エクステント」、「セグメント」

データ整合性

マルチユーザー・データベースの各ユーザーごとのデータの一貫したビュー。

関連項目: 「同時実行性」

データ破損

ハードウェア、ソフトウェアまたはネットワーク・コンポーネントによって、破損したデータが読み取られた場合、または書き込まれた場合に発生するエラー。

データ・ディクショナリ

データベース、データベースの構造およびそのユーザーについての参照情報を含むデータベース表およびビューの読取り専用の集合。

データ・ディクショナリ・キャッシュ

共有プール内でデータ・ディクショナリ情報を保持するメモリー領域。バッファはデータ・ブロック全体を保持しますが、データ・ディクショナリ・キャッシュはデータをバッファではなく行として保持するため、行キャッシュとも呼ばれます。

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

データ・ディクショナリの表または他のビューの事前定義済ビュー。データ・ディクショナリ・ビューは、接頭辞DBA_、ALL_またはUSER_で始まります。

データファイル

Oracle Databaseによってディスク上に作成される物理ファイルであり、データベースのデータが含まれます。データファイルは、オペレーティング・システムのファイルシステムまたはOracle ASMディスク・グループのいずれにも配置できます。

データ整合性

受入れ可能なデータに関する規格を指定するビジネス・ルール。ビジネス・ルールは整合性制約およびトリガーを使用してデータベースに適用され、無効なデータ入力を防止します。

データ・マイニング

大規模なデータ・ストアでパターンおよび傾向を検索する、単純な分析よりも優れた自動検索。

データ・リカバリ・アドバイザ

永続的なデータ障害を自動的に診断してユーザーに修復オプションを提示し、ユーザーのリクエストで修復を実行するOracle Databaseインフラストラクチャ。

データ・セグメント

クラスタ化されていない表、表パーティションまたは表クラスタのデータを含むセグメント。

関連項目: 「エクステント」

データ型

SQLにおいて、列の値または定数に関連付けられた、固定された一連のプロパティ。例として、VARCHAR2やNUMBERがあります。Oracle Databaseでは、様々なデータ型の値をそれぞれ異なる方法で処理します。

データ・ウェアハウス

OLTP用ではなく問合せおよび分析用に設計されたリレーショナル・データベース

DDL

データ定義言語。データ構造を定義または変更するCREATE TABLEやALTER INDEXなどの文があります。

デッドロック

2人以上のユーザーが互いに他方のユーザーによってロックされたデータを待機している状況。このようなデッドロックは、Oracle Databaseではまれです。

専用サーバー

サーバー・プロセスが単一のクライアント・プロセスのリクエストを処理するデータベース構成。

関連項目: 「共有サーバー」

遅延可能制約

SET CONSTRAINT文でトランザクションがコミットされるまで制約チェックの遅延を許可する制約。遅延可能制約を使用すると、制約に違反する可能性がある変更を行う際に制約を一時的に無効にできます。

並列度

単一の処理に関連付けられているパラレル実行サーバーの数。パラレル実行は複数のCPUを効率よく使用するためのものです。Oracle Databaseのパラレル実行フレームワークでは、特定の並列度をユーザーが明示的に選択することも、Oracle Databaseによって自動的に並列度を制御することもできます。

依存オブジェクト

スキーマ・オブジェクト依存性で、定義が別のオブジェクトを参照するオブジェクト。たとえば、オブジェクトAの定義がオブジェクトBを参照している場合、AはBの依存オブジェクトになります。

降順索引

指定された列(1つまたは複数)でデータが降順に格納される索引。

ディメンション

ユーザーのビジネス上の疑問に答えられるようにデータを分類する構造。よく使用されるディメンションとしてcustomers、products、timeがあります。

ディメンション表

スター・スキーマまたはスノーフレーク・スキーマにおいて、ディメンションの全部または一部の値が格納されるリレーショナル表。通常、ディメンション表にはディメンションのキー、レベルおよび属性の列が含まれています。

ダイレクト・パスINSERT

データベースにより、データベース・バッファ・キャッシュを迂回して、データがデータファイルに直接書き込まれるINSERT。データベースは、挿入データを表内の既存データに追加します。

ディレクトリ・オブジェクト

サーバーのファイルシステム上の、外部バイナリ・ファイルLOB(BFILE)および外部表データが保存されているディレクトリの別名を指定するデータベース・オブジェクト。ディレクトリ・オブジェクトはすべて1つの名前空間に作成され、個別のスキーマによって所有されません。

内容を保証しない読取り

未コミットのトランザクションが書き込んだデータを、別のトランザクションが読み取る現象。Oracle Databaseでは、内容を保証しない読取りは許可されません。

ディスパッチャ

「ディスパッチャ・プロセス(Dnnn)」を参照してください。

ディスパッチャ・プロセス(Dnnn)

オプションのバックグラウンド・プロセスで、共有サーバー構成を使用している場合のみ存在します。各ディスパッチャ・プロセスは、接続されたクライアント・プロセスからのリクエストを使用可能な共有サーバー・プロセスにルーティングし、応答を戻します。

分散データベース

分散システムにおいて、アプリケーションで1つのデータ・ソースとして処理できるデータベースの集合。

分散処理

アプリケーションがネットワークの異なる複数のコンピュータ間でタスクを分散させるときに発生する操作。

分散トランザクション

分散データベースのノード上のデータを個別に、またはグループとして更新する文を含むトランザクション。Oracle Databaseでは、分散トランザクションのデータ整合性が2フェーズ・コミット・メカニズムを使用して保証されます。

DML

データ操作言語。SELECT、INSERT、UPDATE、DELETEなどの文があります。

エディション

データベース・オブジェクトの再定義が可能なプライベートな環境。エディションベースの再定義を使用すると、アプリケーションの使用中にアプリケーションのデータベース・オブジェクトをアップグレードできるため、停止時間を最小限に抑えることや停止時間をなくすことが可能です。

暗号化

秘密鍵と暗号化アルゴリズムを使用して、データを読取り不可能な形式に変換するプロセス。

等価結合

等価演算子が含まれている結合条件を使用した結合。

ETL

抽出、変換、ロード(ETL)。ソース・システムからデータを抽出してデータ・ウェアハウスに取り込む処理。

実行計画

SQL文を実行するためにデータベースによって使用されるステップの組合せ。各処理では、データベースからデータ行を物理的に検索するか、文を発行したユーザーのためにデータ行を準備します。ヒントを使用すると実行計画を上書きできます。

式

結果が値となる、1つ以上の値、演算子およびSQL関数の組合せ。たとえば、2*2という式の結果は4になります。一般に、式ではその構成要素のデータ型が想定されます。

エクステント

特定の型の情報を格納するために割り当てられた複数の連続データ・ブロック。セグメントは1つ以上のエクステントで構成されます。

関連項目: 「データ・ブロック」

外部表

メタデータがデータベースに格納されている一方、データがデータベース外部のファイルに格納されている読取り専用の表。データベースは外部表を記述したメタデータを使用して、外部表をリレーショナル表とみなし、外部表のデータを公開します。

抽出、変換、ロード(ETL)

関連項目: 「ETL」

ファクト

売上やコスト・データなど、ビジネス・メジャーを表すデータ。

ファクト表

データ・ウェアハウスのスター・スキーマにおいて、ファクト・データを含む表。ファクト表には一般にファクトを含む列と、ディメンション表の外部キーである列の2種類の列があります。

高速全索引スキャン

データベースが索引ブロックを特定の順序によらずに読み取る全索引スキャン。データベースでは、表にアクセスすることなく、索引自体の中のデータにアクセスします。

高速リカバリ領域

制御ファイル、オンラインREDOログのコピー、アーカイブREDOログ・ファイル、フラッシュバック・ログ、RMANバックアップなどのリカバリ関連ファイルが格納されているオプションのディスク位置。

フィールド

表の行または列の交差部分。

ファイル・システム

連続するディスク・アドレス空間内に構築されるデータ構造。

外部キー

1つの列または列の集合の値が、それぞれ関連する表の一意キーまたは主キーの値と一致する必要がある整合性制約。外部キーに対する整合性制約で定義されるアクションは、参照先のデータが変更された場合のデータベースの動作を決定します。

書式モデル

日時の書式を文字列で記述する文字リテラル。

全索引スキャン

データベースによって索引全体が順に読み取られる索引のスキャン。

全表スキャン

データベースによって表のすべての行が順に読み取られ、選択基準を満たさない行が除外される表データのスキャン。最高水位標を下回るすべてのデータ・ブロックがスキャンされます。

ファンクション

PL/SQLプロシージャに類似した、常に単一の値を戻すスキーマ・オブジェクト。

ファンクション索引

1つ以上の列を含むファンクションや式の値を計算し、索引に格納する索引。

グラニュル

パラレルな作業の基本単位。Oracle Databaseによって、パラレル化対象の操作(表のスキャン、表の更新、索引の作成など)がグラニュル単位に分割されます。パラレル実行プロセスは操作を1回に1グラニュルずつ実行します。

グリッド・コンピューティング

多くのサーバーと記憶域を調整して単一の大容量コンピュータとして動作させるコンピューティング・アーキテクチャ。

グリッド・インフラストラクチャ

エンタープライズ・グリッド・アーキテクチャ用のインフラストラクチャを提供するソフトウェア。クラスタの場合、このソフトウェアにはOracle ClusterwareとOracle ASMが含まれます。スタンドアロン・サーバーの場合、このソフトウェアにはOracle RestartとOracle ASMが含まれます。Oracle Database 11g リリース2(11.2)では、これらのインフラストラクチャ製品を組み合せ、1つのソフトウェアとしてインストールされます(グリッド・インフラストラクチャ・ホーム)。

ハード解析

新しい実行可能なバージョンのアプリケーション・コードを構築するためにデータベースによって実行されるステップ。実行を依頼された文の解析済の表現が共有プール内に存在しない場合、データベースはソフト解析ではなくハード解析を行います。

ハッシュ・クラスタ

索引キーがハッシュ関数に置き換わることを除いて、索引付きクラスタと似ている表クラスタの一種。別個のクラスタ索引は存在しません。ハッシュ・クラスタでは、データが索引になります。

ハッシュ衝突

複数の入力値を同じ出力値にハッシュすること。

ハッシュ関数

任意の長さの入力値に対して作用し、固定長のハッシュ値を戻す関数。

ハッシュ結合

データベースで、2つの表またはデータ・ソースの小さい方を使用して、メモリー内にハッシュ表を作成する結合。大きい方の表をスキャンしてハッシュ表を調べ、小さい方の表の対応する行のアドレスを見つけます。

ハッシュ・キー値

ハッシュ・クラスタで、クラスタ・キー列に挿入される実際の値または推定値。たとえば、クラスタ・キーがdepartment_idの場合は、ハッシュ・キー値が10、20、30のような値になります。

ハッシュ表

ハッシュ結合で結合キーを行と関連付けるインメモリー・データ構造。たとえば、employees表とdepartments表の結合では、部門IDが結合キーになる場合があります。ハッシュ関数は結合キーを使用してハッシュ値を生成します。このハッシュ値は、ハッシュ表である配列内の索引です。

ハッシュ値

ハッシュ・クラスタで、バケットを識別する一意の数値ID。Oracle Databaseでは、無数にあるハッシュ・キー値を入力として受け付け、限定された数のバケットに選別するハッシュ関数が使用されます。各ハッシュ値は、ハッシュ・キー値(部門10、20、30など)に対応する行の格納ブロックのデータベース・ブロック・アドレスにマップされます。

ハッシング

入力値の無限集合をハッシュ値と呼ばれる出力値の有限集合に対応付ける数学的技法。ハッシングはハッシュ表内のデータの迅速な検索に役立ちます。

ヒープ構成表

データ行が特定の順序によらずディスク上に格納される表。デフォルトでは、CREATE TABLEでヒープ構成表が作成されます。

階層データベース

データがツリー構造で編成されたデータベース。ファイルシステムの構造と同様に、各親レコードが1つ以上の子レコードを持ちます。

最高水位標

セグメント内の使用済領域と未使用領域の境界。

ヒント

SQL文の中のコメントを介してオプティマイザに渡される命令。オプティマイザはヒントを使用して文の実行計画を選択します。

人為的なエラーによる停止

データベースのデータを論理的に破損させるか、使用不可能な状態にする意図的ではないアクションまたは悪意のあるアクションが実行されたときに発生する停止状態。

暗黙的問合せ

副問合せなしでデータを取得するDML文の構成要素。明示的にSELECT文が含まれていないUPDATE、DELETEまたはMERGE文では、変更対象の行が暗黙的問合せを使用して取得されます。

非一貫性バックアップ

バックアップの一部のファイルに、チェックポイントより後に行われた変更が含まれているバックアップ。一貫性バックアップとは異なり、非一貫性バックアップではメディア・リカバリに一貫性を持たせる必要があります。

索引

クラスタ化されていない表、表パーティションまたは表クラスタに関連付けられた、オプションのスキーマ・オブジェクト。索引によってデータ・アクセスが高速化される場合があります。

索引ブロック

領域を表ブロックとは異なる方法で管理する特殊なタイプのデータ・ブロック。

索引クラスタ

索引を使用してデータを検索する表クラスタ。クラスタ索引とは、クラスタ・キーのBツリー索引のことです。

索引クラスタ化係数

姓などの索引付きの値を対象に、行の順序性を測定した指標。行の記憶域の中でこの値に関する順序性がよいほど、クラスタ化係数は小さくなります。

索引構成表

記憶域組織がプライマリBツリー索引の改良型となる表。ヒープ構成表とは異なり、データは主キーの順に格納されます。

索引レンジ・スキャン

次の特性を持つ索引の順序付きスキャン。

- 索引の1つ以上の先頭列を条件に指定します。条件は、1つ以上の式および論理(ブール)演算子の組合せを指定し、TRUE、FALSEまたはUNKNOWNの値を戻します。

- 0個、1個、または複数の値を索引キーにできます。

索引スキャン

文で指定された索引付きの列の値を使用して索引を検索することで、行を取得すること。

索引セグメント

パーティション化されていない索引または索引パーティションのデータを格納するセグメント。

索引スキップ・スキャン

コンポジット索引の論理副索引を使用する索引スキャン。個別の索引を検索する場合と同様に、データベースでは単一の索引をスキップします。

索引の一意スキャン

索引キーに関連付けられたROWIDが0個または1個である必要のある索引スキャン。データベースでは、述語が等価演算子を使用して一意索引のキーのすべての列を参照する場合に、一意スキャンが実行されます。

処理中のトランザクション

故障によりクライアント・アプリケーションとデータベース間の接続が切れたときに実行中のトランザクション。

情報システム

情報を格納および処理するための形式が定められたシステム。

初期化パラメータ

データベース・インスタンスの操作に影響するDB_NAMEやSGA_TARGETなどの構成パラメータ。初期化パラメータ設定はテキストベースの初期化パラメータ・ファイルまたはバイナリ・サーバー・パラメータ・ファイルに格納されます。

初期化パラメータ・ファイル

データベース・インスタンスの初期化パラメータ設定が含まれているテキスト・ファイル。

内部結合

結合条件を満たす行のみを戻す2つ以上の表の結合。

インスタンス

システム・グローバル領域(SGA)とバックグラウンド・プロセスの組合せ。インスタンスは1つのデータベースのみに関連付けられます。Oracle Real Application Clusters構成では、複数のインスタンスが1つのデータベースに同時にアクセスします。

インスタンス障害

ハードウェア障害、Oracle内部エラーまたはSHUTDOWN ABORT文によるデータベース・インスタンスの終了。

インスタンス・リカバリ

障害後のインスタンス再起動時の、コミットされていないデータ・ブロックへのREDOログ・レコードの自動的な適用。

整合性

「データ整合性」を参照してください。

整合性制約

列に関する規則を定義するための宣言型の方法。整合性制約はビジネス・ルールを適用し、無効な情報が表に入力されるのを防止します。

Interested Transaction List (ITL)

ブロックの変更が開始された時点でトランザクションがコミットされているかどうかを指定する、各セグメントのブロック・ヘッダー内の情報。ITLのエントリは、ロックされた行のあるトランザクション、およびブロック内のコミット済の変更や未コミットの変更を含む行を表しています。

非参照用索引

DML操作によって管理されるが、デフォルトではオプティマイザにより使用されない索引。索引を非表示にするのは、使用禁止または削除の代替手段です。

結合

FROM句に指定された複数の表からデータを取得する文。結合のタイプには、内部結合、外部結合およびデカルト結合があります。

結合条件

別々の表にある2つの列を結合時に比較する条件。データベースでは1対の行を組み合せ、それぞれの対には、結合条件がTRUEになる各表の行を1行ずつ含みます。

キー

特定タイプの整合性制約の定義に含まれる列または列の集合。

キー圧縮

索引構成表内の主キー列値で繰り返されている値の除去。

キー値

キー内の個別の値。

ラージ・オブジェクト(LOB)

「LOB」を参照してください。

ラージ・プール

バックアップおよびリストア操作、I/Oサーバー・プロセスおよび共有サーバーとOracle XAのセッション・メモリー用に、大量のメモリー割当てを提供するSGA内のオプション領域。

ラッチ

SGA内の共有データ構造を同時アクセスから保護するために使用される、低レベルのシリアライズ制御メカニズム。

リーフ・ブロック

Bツリー索引で、索引エントリを格納する低レベルのブロック。Bツリー索引の上位ブランチ・ブロックには、下位レベルの索引ブロックを指す索引データが含まれます。

ライブラリ・キャッシュ

共有プール内のメモリー領域。このキャッシュには、共有SQL領域、プライベートSQL領域(共有サーバー構成の場合)、PL/SQLプロシージャおよびパッケージ、ロックやライブラリ・キャッシュ・ハンドルなどの制御構造が含まれています。

リスナー

受信クライアント接続リクエストをリスニングし、データベースへのネットワーク・トラフィックを管理するプロセス。

リテラル

固定データ値。

LOB

ラージ・オブジェクト。大量のデータを保持するために設計されたOracleデータ型です。

ローカル管理表領域

各データファイルに格納されたビットマップを使用してエクステントを管理する表領域。一方、ディクショナリ管理表領域は、データ・ディクショナリを使用して領域を管理します。

ロック

表、行、ユーザーには見えないシステム・オブジェクトなどの共有リソースにアクセスする複数のトランザクション間で、破損を招く相互作用を回避するためのデータベース・メカニズム。ロックの主なカテゴリとして、DMLロック、DDLロックおよびラッチと内部ロックがあります。

論理トランザクションID

アプリケーションの観点から、トランザクションを定義するグローバルに一意の識別子。論理トランザクションIDは、データベース・トランザクションIDにバインドされます。

論理ボリューム

仮想ディスク・パーティション。

論理ボリューム・マネージャ(LVM)

複数の物理ディスクの断片を、ソフトウェアの上位レイヤーに対して1つのディスクとして表示される単一の連続するアドレス空間に結合する、ほとんどのオペレーティング・システムで使用可能なソフトウェア・パッケージ。

ログ順序番号

REDOログ・ファイル内のREDOレコードの集合を一意に識別する番号。データベースで1つのオンラインREDOログ・ファイルがいっぱいになり、別のファイルに切り替えるとき、データベースは新しいファイルにログ順序番号を自動的に割り当てます。

ログ・スイッチ

ログ・ライター(LGWR)がアクティブなREDOログ・ファイルへの書込みを停止し、使用可能な次のREDOログ・ファイルに切り替えるポイント。LGWRは、アクティブなREDOログ・ファイルがREDOレコードでいっぱいになったとき、または手動で切替えが開始されたときに、切替えを行います。

ログ・ライター(LGWR)

REDOログ・バッファ管理、つまりオンラインREDOログへのREDOログ・バッファの書込みを行うバックグラウンド・プロセス。LGWRは、最後の書込み以後にバッファにコピーされたREDOエントリすべてを、REDOログ・ファイルに書き込みます。

参照表

コード列および関連付けられた値列が含まれる表。たとえば、ジョブ・コードはジョブ名に対応します。マスター/ディテール表ペアのマスター表とは対照的に、参照表は、従業員のリストなどの詳細な結果セットを取得する手段ではありません。逆に、ユーザーは従業員リストを求めてemployeesなどの表に問い合せ、結果セットを参照表に結合します。

更新内容の消失

あるデータ書込みによって、同じデータを変更する別の書込みの変更内容が上書きされるというデータ整合性の問題。

仮数

有効桁数を含む浮動小数点数の一部。

手動UNDO管理モード

UNDOブロックがユーザー管理UNDOセグメントに格納されるデータベース・モード。自動UNDO管理モードでは、UNDOブロックはシステム管理の専用UNDO表領域に格納されます。

マスター/ディテール表

ディテール表には、マスター表との外部キー関係があります。たとえば、employeesディテール表には、departmentsマスター表に対する外部キーがあります。参照表とは異なり、通常、マスター表は問い合せられてからディテール表に結合されます。たとえば、ユーザーはdepartments表で部門について問い合せてから、その結果を使用して部門内の従業員を検索します。

マスター・サイト

レプリケーション環境において、マテリアライズド・ビューがデータを共有する別のデータベース。

マスター表

マスター・サイトのマテリアライズド・ビューに関連付けられた表。

マテリアライズド・ビュー

問合せの結果を格納するスキーマ・オブジェクト。Oracleマテリアライズド・ビューは、読取り専用または更新可能です。

関連項目: 「ビュー」

メディア・リカバリ

REDOまたは増分バックアップをデータ・ブロックまたはバックアップ・データファイルに適用すること。

マウントされたデータベース

起動されており、オープンしているデータベース制御ファイルを持つインスタンス。

複数層アーキテクチャ

1つ以上のアプリケーション・サーバーがクライアントにデータを提供し、クライアントとデータベース・サーバーの間のインタフェースとして機能するようなアーキテクチャ。

ネットワーク・データベース

レコードが1対多の関係ではなく多対多の関係を持つ、階層データベースと似たデータベースのタイプ。

ネットワーク暗号化

クライアントとサーバー間のネットワークを移動するデータを暗号化すること。

NULL

1つの行の1つの列に値がないこと。NULLは、データがない、不明である、または適切でないことを示します。

オブジェクト・リレーショナル・データベース管理システム(ORDBMS)

ユーザー定義型、継承、ポリモフィズムなどのオブジェクト指向機能を実装したRDBMS。

オブジェクト表

各行がオブジェクトを表す特殊な表。

オブジェクト型

発注書のような実社会のエンティティを抽象化したスキーマ・オブジェクト。属性はエンティティの構造をモデル化し、メソッドはアプリケーションがエンティティに対して実行できる操作を実装します。

OLAP

オンライン分析処理。OLAPは履歴データの動的なディメンション分析を特徴とします。

OLTP

オンライン・トランザクション処理。OLTPシステムは、高速で信頼性の高いトランザクション処理用に最適化されています。データ・ウェアハウス・システムに比べ、OLTPの相互作用では、扱われる行が少なく、表のグループが大きいのが通例です。

オンラインREDOログ

Oracle Databaseのデータファイルおよび制御ファイルに対して行われたすべての変更を記録する、複数のオンラインREDOログ・ファイルの集合。データベースに対して変更が行われると、Oracle DatabaseによりREDOバッファにREDOレコードが生成され、REDOバッファの内容は、ログ・ライター(LGWR)によりオンラインREDOログに書き込まれます。

演算子

1. メモリー管理では、演算子はデータのフローを制御します。たとえば、ソート、ハッシュ結合、ビットマップ・マージの演算子があります。

2. SQLでは、演算子はオペランドまたは引数と呼ばれるデータ項目を操作し、結果を戻します。SQLの演算子は特殊文字またはキーワードで表現されます。たとえば、乗算演算子はアスタリスク(*)で表現されます。

オプティマイザ

SQL文で参照されているオブジェクトと指定された条件に関連する要因を考慮して、SQL文を実行する最も効率的な方法を決定する組込みのデータベース・ソフトウェア。

Oracleアーキテクチャ

データベースの管理でOracle Databaseが使用するメモリーとプロセスの構造。

Oracle Automatic Storage Management (Oracle ASM)

「Oracle ASM」を参照してください。

Oracle ASM

Oracle Automatic Storage Management(Oracle ASM)。データベース・ファイル用のボリューム・マネージャとファイルシステム。Oracle ASMはオラクル社が推奨するストレージ管理ソリューションであり、従来のボリューム・マネージャ、ファイルシステムおよびRAWデバイスの代替手段となります。

Oracle ASMディスク・グループ

1つの論理単位として管理される1つ以上のOracle ASMディスク。ディスク・グループに対するI/Oは、そのグループの全ディスクに自動的に分散されます。

Oracleクラスタウェア

複数のサーバーを1つのサーバーとみなし、まとめて実行できるようにするコンポーネントの集合。Oracle Clusterwareは、Oracle RACの使用に不可欠であり、Oracle RACを実行するプラットフォーム用に必要な唯一のクラスタウェアです。

Oracle Database Vault

データベース、データおよびアプリケーションに対するアクセスのタイミング、場所および方法を制御するデータベース・セキュリティ機能。

Oracle Data Redaction

権限の低いユーザーまたはアプリケーションが発行する問合せから返されるデータをマスク(リダクション)できるセキュリティ機能。

Oracle Enterprise Manager

Oracleデータベース環境を集中管理するためのシステム管理ツール。

Oracleホーム

オペレーティング・システムのOracle Databaseインストールの位置。

Oracle Net

クライアント・アプリケーションとOracleデータベース間のネットワーク・セッションを可能にする通信ソフトウェア。ネットワーク・セッションの確立後、Oracle Netはクライアント・アプリケーションとデータベースのためのデータ伝達手段として機能します。

Oracle Net Listener

サーバー上のプロセスであり、着信クライアント接続要求をリスニングし、サーバーへのトラフィックを管理する責任を持ちます。クライアントがデータベースとのネットワーク・セッションをリクエストするときに、Oracle Net Listener (通常はリスナーと呼ばれる)はリクエストを受け取ります。クライアント情報がリスナー情報と一致した場合、リスナーはデータベース・サーバーへの接続を許可します。

Oracle Net Services

分散された異機種間コンピューティング環境における、企業全体の接続性ソリューションを提供するネットワーキング・コンポーネントのスイート。Oracle Net Servicesは、Oracle Net、リスナー、Oracle Connection Manager、Oracle Net Configuration AssistantおよびOracle Net Managerを含みます。

Oracleプロセス

Oracle Databaseコードを実行するプロセス。Oracleプロセスには、サーバー・プロセスとバックグラウンド・プロセスがあります。

Oracle RAC

Oracle Real Application Clusters.複数の同時データベース・インスタンスが1つの物理データベースを共有できるオプション。

Real Application Clusters

「Oracle RAC」を参照してください。

Oracle SQL

SQLのANSI標準の実装の1つ。Oracle SQLでは、標準SQLを拡張した数多くの機能がサポートされています。

Oracle Virtual Private Database(VPD)

セキュリティ・ポリシーを作成し、行および列レベルでデータベース・アクセスを制御できるセキュリティ機能。基本的には、VPDのセキュリティ・ポリシーが適用されている表、ビューまたはシノニムに対して発行されたSQL文に対して動的なWHERE句がVPDによって追加されます。

Oracle XA

Oracle Database以外のトランザクション・マネージャでグローバル・トランザクションを調整できるようにする外部インタフェース。

外部結合

結合条件を満たすすべての行を返し、一方の表の行が結合条件を満たさなくても、他方の表の一部または全部の行を返す結合。

パラレル実行

複数のCPUおよびI/Oリソースを1つのデータベース操作の実行に適用すること。

部分索引

関連付けられたパーティション表の索引付けプロパティと相互に関連付けられている索引。

パーティション

同じ論理属性を共有する表または索引のピース。たとえば、1つの表内のすべてのパーティションは同じ列定義と制約定義を共有します。

パーティション・キー

パーティション表の各行が属するパーティションを決定する1つ以上の列のセット。各行は、単一パーティションに明示的に割り当てられます。

パーティション化

パーティションと呼ばれる、より小さく管理しやすい部分に大規模な表や索引を分割する機能。

PGA

プログラム・グローバル領域。サーバー・プロセス用のデータや制御情報を含むメモリー・バッファです。

関連項目: 「SGA」

物理推測

索引エントリの最初の作成時の物理ROWID。Oracle Databaseは、物理推測を使用して、主キー検索をバイパスし、索引構成表のリーフ・ブロックを直接検証できます。

プラン・ジェネレータ

特定の問合せブロックに対して、最小コストの計画を検出するために、様々なアクセス・パス、結合方法および結合順序を試行するオプティマイザの要素。

PL/SQL

手続き型言語/SQL。SQLに対するOracle Databaseの手続き型言語拡張機能です。PL/SQLを使用すると、SQL文をプロシージャ、ファンクション、パッケージなどのプログラム構造と混合して使用できます。

PL/SQLパッケージ

関連するPL/SQLタイプ、変数およびサブプログラムを論理的にグループ化すること。

PL/SQLプロシージャ

SQL文やその他のPL/SQL構成メンバーのセットで構成され、グループとしてまとめてデータベースに格納されるスキーマ・オブジェクト。特定の問題を解決したり、関連する一連のタスクを実行するために、1単位として実行されます。

PL/SQLサブプログラム

一連のパラメータを使用して起動できる、名前付きPL/SQLブロック。

精度

浮動小数点数の桁数の合計。固定小数点数は、NUMBER(p,s)の形式で指定します(pは精度を表します)。

プリコンパイラ

C、C++、COBOLなどの言語で記述された高水準のソース・プログラムにSQL文を埋め込むことができるプログラミング・ツール。

述語

SQL文のWHERE条件。

主キー

表の行を一意に識別する列または列の集合。各表には1つの主キーのみを定義できます。

主キー制約

列または列の集合に重複値とNULLを許可しない整合性制約。

プライベートSQL領域

解析済の文と処理に使用するその他の情報が保持されるメモリー内の領域。プライベートSQL領域には、バインド変数値、問合せ実行状況の情報、問合せ実行作業領域などのデータが格納されます。

権限

特定のタイプのSQL文を実行する権利や、別のユーザーに属するオブジェクトにアクセスする権利、PL/SQLパッケージを実行するなどの権利。権限のタイプはOracle Databaseによって定義されます。

権限分析

指定した条件に従ってデータベースの権限使用状況を取得するセキュリティ・メカニズム。たとえば、ユーザーが特定のデータベース・セッション中に行使した権限を見つけることができます。

プロセス

一連の処理を実行できるオペレーティング・システムのメカニズム。Oracle Databaseとデータベース・アプリケーションの作業を複数のプロセスに分割することにより、複数のユーザーやアプリケーションが同時に1つのデータベース・インスタンスに接続できます。

関連項目: 「バックグラウンド・プロセス」、「Oracleプロセス」、「クライアント・プロセス」

プログラム・グローバル領域(PGA)

「PGA」を参照してください。

疑似列

表に格納されないが表の列のように動作する列。

問合せ

表またはビューからデータを取り出す操作。たとえば、SELECT * FROM employeesは問合せです。

関連項目: 「暗黙的問合せ」、「副問合せ」

問合せブロック

最上位のSELECT文、副問合せ、またはマージされていないビュー。

問合せコーディネータ

パラレル実行において、パラレル実行サーバーを調整するユーザー・セッションまたはシャドウ・プロセス。パラレル実行サーバーは可能な場合には各操作をパラレルで実行します。パラレル・サーバーで文の実行が終了すると、問合せコーディネータは、パラレルで実行できない作業の部分を実行します。最後に問合せコーディネータが結果をユーザーに返します。

問合せ計画

問合せの実行に使用される実行計画。

R

統計計算およびグラフィック用の言語および環境。

読取り一貫性

ユーザーから見たデータの一貫したビュー。たとえば、文レベルの読取り一貫性では、SQL文から見たデータの集合は、文の実行中に不変です。

関連項目: 「同時実行性」、「データ整合性」

読取り専用データベース

問合せのみに使用でき、変更できないデータベース。

リカバリ可能なエラー

実行中のアプリケーション・セッション・ロジックとは関係なく、外部システムの障害のために生じるエラーの種類。リカバリ可能なエラーは、ネットワーク、ノード、記憶域およびデータベースの計画および計画外停止の後に発生します。リカバリ不可能なエラーの例は、無効なデータ値の送信です。

Recovery Manager(RMAN)

「RMAN」を参照してください。

再帰的SQL

データベース・オブジェクト用の領域を取得するため、データベースでバックグラウンドで実行されるSQL。再帰的SQLは副作用SQLと考えることができます。

REDOログ

データファイルに書き込まれていないメモリー内の変更済データベース・データを保護する一連のファイル。REDOログは、オンラインREDOログとアーカイブREDOログという2つの部分からなる場合があります。

REDOログ・バッファ

REDOエントリ(データベースに対して行われた変更のログ)を格納するSGAのメモリー構造。データベースは、REDOログ・バッファ内に格納されたREDOエントリをオンラインREDOログ・ファイルに書き込み、REDOログ・ファイルはインスタンス・リカバリが必要になったときに使用されます。

REDOレコード

変更ベクトル(データベース内の単一ブロックに加えられた変更を記述したもの)のグループを保持するオンラインREDOログ内のレコード。各REDOログ・ファイルは、REDOレコードで構成されます。

REDOスレッド

データベース・インスタンスによって生成されるREDO。

参照しているオブジェクト

スキーマ・オブジェクト依存性で、別のオブジェクト定義で参照されるオブジェクト。たとえば、オブジェクトAの定義がオブジェクトBを参照している場合、BはオブジェクトAの参照オブジェクトになります。

参照整合性

1つの表のキーに対して定義される規則であり、そのキーの値が関連する表のキーの値(参照値)と一致することを保証します。

リレーション

一連のタプル。

リレーショナル・データベース

データを一連の単純なリレーションに格納する、リレーショナル・モデルに準拠するデータベース。

リレーショナル・データベース管理システム(RDBMS)

データをリレーショナル・データベースに移動して、アプリケーションが操作できるようにそのデータを取得する管理システム。

レプリケーション

複数のデータベースでデータベース・オブジェクトおよびデータを共有する処理。

予約プール

Oracle Databaseで大量の連続したメモリーのチャンクを割り当てるために使用できる共有プール内のメモリー領域。

逆キー索引

列の順序は保ちながら、各索引キーのバイトを物理的に逆にするBツリー索引の一種。たとえば、索引キーが20であり、このキーに対して標準Bツリー索引で格納される16進数の2バイトがC1,15である場合、逆キー索引では、バイトが15,C1として格納されます。

RMAN

Recovery Manager。Oracleデータベースをバックアップ、リストアおよびリカバリするOracle Databaseユーティリティ。

ロール

データベース・ユーザーまたは他のロールに付与できる一連の権限。

行

表の1つのレコードに対応する一連の列情報。データベースでは、行がデータ・ブロックに格納されます。

行連鎖

行が大きすぎて1つのブロックに収まらず、Oracle Databaseが行を一連のブロックまたは連鎖するブロックに格納することが必要になる状況。

ROWID

データベース内の行に対するグローバルな一意のアドレス。

行優先形式

ある行のすべての列がまとめて格納され、それ以降の行のすべての列がそれに続く表記憶域のタイプ。

行の移行

行が大きくなりすぎて元のブロックに収まらなくなったためにOracle Databaseが1つのデータ・ブロックから別のデータ・ブロックへ行を移動する状況。

行断片

可変長レコードに格納される行。このレコードは、1つ以上の行断片に分割されます。各行断片は、行ヘッダーおよび列データで構成されます。

サンプル・スキーマ

共通のデータベース・タスクに関するOracleドキュメントおよび資料を表示できる、連結されたスキーマのセット。

セーブポイント

トランザクション内の名前付きSCN。トランザクションをそのSCNまでロールバックできます。

スケール

浮動小数点数で、小数点から最下位桁までの桁数。固定小数点数は、NUMBER(p,s)の形式で指定します(sはスケールを表します)。

スキーマ

表や索引などの論理構造を含む、データベース・オブジェクトの名前付きコレクション。スキーマには、そのスキーマを所有するデータベースの名前が付きます。

スキーマ・オブジェクト

スキーマに格納されたデータの論理構造。たとえば、スキーマ・オブジェクトには、表、索引、順序、データベース・リンクがあります。

スキーマ・オブジェクト依存性

別のオブジェクトによるオブジェクトの参照。たとえば、ビューに表またはビューを参照する問合せが含まれている場合や、PL/SQLサブプログラムが他のサブプログラムを起動する場合があります。

SCN

システム変更番号。データベース順序付けプリミティブです。SCNの値は、データベースに対して変更が行われた論理的な時点です。

2次索引

索引構成表の索引。ある意味では、これは索引の索引です。

セキュリティ・ポリシー

過失または悪意によるデータの破壊、またはデータベース・インフラストラクチャの被害からデータベースを保護する一連の手段。

セグメント

表、索引、表クラスタなどの特定のデータベース・オブジェクトに割り当てられた一連のエクステント。セグメントのタイプは、ユーザー・セグメント、UNDOセグメントおよび一時セグメントで、すべてです。

選択性

問合せにおいて、行の集合のうち何行が述語のテストを通過するかを示す測定基準。たとえば、WHERE last_name = 'Smith'など。選択性が0.0の場合は、行がないことを意味し、1.0の場合はすべての行を意味します。述語は、値が0.0に近付くほど選択性が高くなり、値が1.0に近付くほど選択性が低く(非選択性が高く)なります。

自己結合

自身への表の結合。

順序

表の列に対して連続する一意の数値のリストを生成するスキーマ・オブジェクト。

サーバー

クライアント/サーバー・アーキテクチャで、Oracleソフトウェアを実行し、同時実行の共有データ・アクセスに必要な機能を処理するコンピュータ。サーバーは、クライアント・アプリケーションから発行されたSQL文やPL/SQL文を受け取って処理します。

サーバー・パラメータ・ファイル

データベースによって読み書きされる初期化パラメータ設定を含むサーバー側のバイナリ形式のファイル。

サーバー・プロセス

ユーザー・リクエストを満たすために、クライアント・プロセスおよびOracle Databaseと通信するOracleプロセス。サーバー・プロセスは、データベース・インスタンスと関連付けられていますが、インスタンスの一部ではありません。

サービス指向アーキテクチャ(SOA)

ネットワーク上のコンピュータ間の対話をサポートするサービスに依存する複数層アーキテクチャ。

セッション

データベースへの現行ユーザー・ログインの状態を表すデータベース・インスタンス・メモリー内の論理エンティティ。1つの接続では、セッションが確立されないか、1つ以上のセッションが確立されます。

SGA

システム・グローバル領域。共有メモリー構造のグループで、1つのOracleデータベース・インスタンスに関するデータと制御情報が含まれます。

共有プール

共有SQL領域などの共有メモリー構成メンバーを含むSGAの一部。

共有サーバー

複数のクライアント・プロセスが少数のサーバー・プロセスを共有できるデータベース構成。

関連項目: 「専用サーバー」

共有SQL領域

SQL文の解析ツリーと実行計画を含む共有プール内の領域。一意の文に対して、共有SQL領域は1つのみ存在します。

単一レベル・パーティション化

リスト・パーティションのみまたはレンジ・パーティションのみなど、データ配分方法を1つのみ使用するパーティション化計画。

ソフト解析

実行依頼されたSQL文の解析済の表現が共有プールに存在し、共有できる場合に行われる、既存コードの再利用。

関連項目: 「ハード解析」

ソート済のハッシュ・クラスタ

データベースがソートされた順序で効率的に行を戻すことが可能になるように、ハッシュ関数の各値に対応する行を格納するハッシュ・クラスタ。データベースは最適化されたソートを内部的に実行します。

SQL

構造化問合せ言語。リレーショナル・データベースにアクセスするための非手続き型言語です。ユーザーが処理内容をSQLで記述すると、SQL言語コンパイラはデータベースをナビゲートし、そのタスクを実行するプロシージャを自動的に生成します。Oracle SQLには、ANSI/ISO標準SQL言語に対する拡張機能が多数含まれています。

関連項目: 「SQL*Plus」、「PL/SQL」

SQL*Plus

Oracle Databaseに対してSQL文を実行するために使用するOracleツール。

スタンバイ・データベース

高可用性環境で障害時の保護に使用できる、本番データベースの独立したコピー。

スター・スキーマ

ディメンション・データ・モデルを表すように設計されたリレーショナル・スキーマです。1つ以上のファクト表と、外部キーを介して関連付けられている1つ以上のディメンション表で構成されます。

「ディメンション表」および「ファクト表」も参照してください。

文レベルのロールバック

実行中にエラーが発生したために失敗したSQL文の効果がロールバックされるデータベース操作。

ストアド・プロシージャ

Oracle Databaseによってデータベースに格納される名前付きPL/SQLブロックまたはJavaプログラム。アプリケーションはストアド・プロシージャを名前で呼び出すことができます。

Structured Query Language(SQL)

「SQL」を参照してください。

副問合せ

別のSQL文内にネストされた問合せ。暗黙的な問合せとは異なり、副問合せはSELECT文を使用してデータを取得します。

サマリー

データ・ウェアハウス内の集計ビューで、結合および集計操作を事前に計算して結果を表に格納することで、問合せ時間が短縮されます。

シノニム

スキーマ・オブジェクトの別名。シノニムを使用してデータの独立性と位置の透過性を提供できます。

システム変更番号(SCN)

「SCN」を参照してください。

システム・グローバル領域(SGA)

「SGA」を参照してください。

表

Oracle Databaseにおけるデータ記憶域の基本単位。表のデータは、行と列に格納されています。

表クラスタ

1つ以上の共通する列を持つ、1つ以上の表のデータを含むスキーマ・オブジェクト。表クラスタでは、データベースは同じクラスタ・キーを共有するすべての表について、すべての行をまとめて格納します。

表の圧縮

ヒープ構成表または表パーティションのディスク領域を削減するために行うデータ・セグメントの圧縮。

テーブル・ファンクション

行の集合(ネストした表またはVARRAY)を戻すユーザー定義のPL/SQLファンクション。SELECT文のTABLE句の内部でテーブル・ファンクションを起動することで、データベース表のようにこのコレクションから要素を選択できます。

表領域

関連する論理構造をグループ化するデータベース記憶域。データベースのデータファイルは表領域に格納されます。

一時ファイル

一時表領域に属するファイル。一時表領域の一時ファイルには、永続的なデータベース・オブジェクトが含まれることはありません。

一時セグメント

SQL文の実行を完了するために一時的なデータベース領域が必要なときに、Oracle Databaseによって作成されるセグメント。

一時表

トランザクションまたはセッションの継続時間中に中間結果セットを保持する表。現行セッションのみが一時表のデータを参照できます。

トレース・ファイル

問題の調査に使用される診断データを含む管理用のファイル。Oracle Databaseでは、トレース・ファイルをADRに書き込みます。

トランザクション

1つ以上のSQL文を含む論理的な作業単位。トランザクション内のすべての文は、まとめてコミットまたはロールバックされます。トランザクションの使用は、データベース管理システムとファイルシステムの最も重要な違いの1つです。

トランザクションID

識別子はトランザクションに対して一意であり、UNDOセグメント番号、スロットおよび順序番号を表します。

トランザクション・リカバリ

コミットされていないトランザクションがロールバックされるインスタンス・リカバリのフェーズ。

トランザクション表

UNDOセグメント内のデータ構造で、UNDOセグメントを使用するトランザクションのトランザクション識別子を保持します。

透過的データ暗号化

個々の表列または表領域を暗号化するデータベース機能。ユーザーが暗号化された列にデータを挿入すると、データベースによって自動的にデータが暗号化されます。ユーザーが列を選択すると、データは復号化されます。このような形式の暗号化は透過的であり、パフォーマンスが高く、実装が容易です。

トランスポータブル表領域

データベース間でコピーまたは移動できる表領域。Oracle Data Pumpは、トランスポータブル表領域のインフラストラクチャを提供します。

トリガー

表またはビューが変更されたとき、または特定のユーザー・アクションまたはデータベース・アクションが発生したときに起動されるPL/SQLまたはJavaのプロシージャ。プロシージャが明示的に実行されるのに対し、トリガーは暗黙的に実行されます。

タプル

順不同の一連の属性値。

UGA

ユーザー・グローバル領域。ログオン情報などのセッション変数が格納されるセッション・メモリーであり、OLAPプールを含むこともできます。

UNDOデータ

トランザクション・アクションのレコードで、基本的にはコミットされる前のもの。データベースでは、UNDOデータを使用してSQL文の効果を論理的に元に戻すことができます。UNDOデータはUNDOセグメントに格納されます。

UNDOセグメント

UNDO表領域内のセグメント。

UNDO表領域

自動UNDO管理モードが有効になっている場合にUNDOセグメントを含む表領域。

Unicode

1つのキャラクタ・セットで任意の言語の情報を格納できるユニバーサル・エンコードされたキャラクタ・セット。

ユニバーサルROWID

すべてのタイプのROWIDを格納できるデータ型。Oracleでは、索引編成表とOracle以外の表のアドレスはユニバーサルROWIDを使用して格納されます。

使用禁止索引

DML操作によって管理され、オプティマイザにより無視される索引。すべての索引は、使用可能(デフォルト)または使用禁止です。

ユーザー・グローバル領域(UGA)

「UGA」を参照してください。

ユーザー名

Oracle Databaseおよび他のユーザーがユーザーを識別するための名前。すべてのユーザー名にはパスワードが関連付けられており、Oracle Databaseに接続するときはユーザー名とパスワードの両方を入力する必要があります。

ユーザー・プロセス

「クライアント・プロセス」を参照してください。

ユーザー・プロファイル

ユーザーのデータベース使用とデータベース・インスタンス・リソースを制限する、リソース制限とパスワード・パラメータをセットにして名前を付けたもの。

ビュー

1つ以上の表のデータをカスタム調整したデータ表現。ビューは、実際にデータが含まれたり、格納されたりすることはなく、基になる表から導出されます。

仮想列

ディスク上に格納されない列。データベースは、必要に応じて、一連の式またはファンクションを計算することによって仮想列の値を導出します。

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

データベースに属するすべての制御ファイルおよびデータファイルのバックアップ。

作業領域

メモリー集中型の操作に使用されるPGAメモリーを個別に割り当てるための領域。

索引
A B C D E F G H I J K L M N O P Q R S T U V W X

A

アクセス・ドライバ, 外部表, 2.2.7.2

アクセス・パス, データ, 3.1.1, 3.1.4.2, 7.3.1, 7.3.3, 7.4.1.4

アカウント, ユーザー, 6.1

ACIDプロパティ, 10.1

アクティブなトランザクション, 10.2.2

ADDM(自動データベース診断モニター), 18.3.4.3, 18.3.4.4

管理アカウント, 2.1.4, 6.1.1

管理者権限, 2.1.4, 13.2.1.1, 13.2.1.1, 16.2.4.2

アドバンスト・キューイング, 15.4.2, 15.4.2, 17.5.2.2

アラート・ログ, 13.6.2, 15.4.1.4.2

ALL_データ・ディクショナリ・ビュー, 6.1.1.2

ALTER SESSION文, 7.2.4

無名PL/SQLブロック 8.2

ANSI/ISO規格, 7.1.2

API(Application Program Interface), 16.3

埋込みSQL文, 7.2.6

外部表, 2.2.7.2, 用語集

Java, 8.3.1.1, 17.4.4.3, 19.3.2.1.2, 19.3.2.2.2

JDBC, 7.2.6, 8.3.2.2

ネットワーク・サービス, 16.2.1

OCI/OCCI, 19.3.2.2.1

ODBC, 7.2.6, 19.3.2.2.2

Oracle Data Pump, 18.2.5.2

Oracle Streams Advanced Queuing, 17.5.2.2.2

SQLJ, 8.3.2.2

アプリケーション・アーキテクチャ, 1.5.4.1 アプリケーション開発者

業務, 19.1

ツール, 19.2

トピック, 19.3

アプリケーション・ドメイン索引, 3.1.5, 3.1.5 アプリケーション・プロセス, 15.2 アプリケーション・プログラム・インタフェース, 「API」を参照 アプリケーション・サーバー, 1.5.4.1, 8.3.1.2 アーカイブREDOログ・ファイル, 11.3.3, 11.4.2.3, 18.3.1.3.4 ARCHIVELOGモード, 15.4.2.1 アーカイバ・プロセス(ARCn), 15.4.2.1 昇順索引, 3.1.2.4 ASM(自動ストレージ管理), 11.1.2, 11.1.2.1, 17.3.2 原子性, 文レベル, 10.1.3 AUDIT文, 7.2.1 監査, 6.1, 6.1.3, 7.2.1, 8.4.1, 11.1.3, 13.2.1.4.1, 16.1.2.3, 17.1.6.1

Oracle Audit Vault, 17.1.6.2

認証, データベース, 7.2.4, 15.2.2, 17.1.2 自動データベース診断モニター。「ADDM」を参照 自動メンテナンス・タスク, 18.3.4.2 自動メモリー管理, 18.3.2.1, 18.3.2.2 自動ストレージ管理, 「ASM」を参照 自動UNDO管理, 12.4.3 AutoTask, 18.3.4.2, 18.3.4.2

B

バックグラウンド・プロセス, 15.4

バックアップ, データベース, 18.3.1.2.1

ビットマップ索引, 3.1.3, 3.1.3, 4.1.3.1

ビットマップ結合, 3.1.3.2

ロック, 3.1.3

マッピング表 3.2.3.2

単一表, 3.1.3.1

記憶域, 3.1.3.3

ビットマップによる表領域管理, 12.1.2.1 ブロックしているトランザクション, 9.2.1.2 BOOLEANデータ型, 2.2.3, 3.1.2.2.3, 7.2.2.1, 8.4.4, 用語集 ブランチ・ブロック, 索引, 3.1.2.1 Bツリー索引, 2.2.8.3, 2.3.1, 3.1.2, 用語集

ブランチ・レベル, 3.1.2.1

高さ, 3.1.2.1

キー圧縮, 3.1.2.5

逆キー, 3.1.2.3

ビジネス・ルール, 規定, 5.1.1

C

キャッシュ・フュージョン, 9.1.1.3

カーディナリティ, 列, 3.1.3, 7.3.2.2

デカルト結合, 7.2.2.2

カートリッジ, 3.1.5

連鎖的な削除, 5.2.4.3

catalog.sqlスクリプト, 6.2.1

連鎖, 行, 「行連鎖」を参照, 12.2.4.3

文字データ型, 2.2.3.1

バイト・セマンティクス, 2.2.3.1

CHAR, 2.2.3.1.1

キャラクタ・セマンティクス, 2.2.3.1

VARCHAR2, 2.2.3.1

キャラクタ・セット, 2.2.3.1

ASCII, 2.2.3.1

EBCDIC, 2.2.3.1

Unicode, 2.2.3.1

チェック制約, 5.2, 5.2.5 チェックポイント(CKPT)プロセス, 15.4.1.5 チェックポイント

制御ファイル, 11.3.1

データベース停止, 13.2.2.1

定義, 13.3

非一貫性バックアップ, 18.3.1.2.2

増分, 13.3.2

位置, 13.4.4

スレッド, 13.3.2

クライアント・プロセス, 15.2

接続, 15.2.2

セッション, 15.2.2

共有サーバー・プロセス, 16.2.4.1.2

クライアント結果キャッシュ, 14.4.3.3 クライアント/サーバー・アーキテクチャ, 16.1.1 クライアント側プログラミング, 8.1 クラスタ索引, 2.3.1, 用語集 クラスタ, 表, 2.3.2

クラスタ・キー, 2.3

ハッシュ, 2.3.2

索引, 2.3.2

Codd, E.F., 1.1.2 コード・ポイント, 2.2.3.1 コレクション, PL/SQL, 8.2.5.1 列

カーディナリティ, 3.1.3, 3.1.3, 7.3.2.2

定義, 2.2.1

順序, 2.2.8.1

NULLの使用禁止, 5.2.1

仮想, 2.2.1, 2.2.8.1, 3.1.4.2

COMMENT文, 7.2.1 トランザクションのコミット

COMMIT文, 7.2.3

定義, 10.1

トランザクションの終了, 10.1.2.2

高速コミット, 15.4.1.4.1, 15.4.1.4.1

グループ・コミット, 15.4.1.4.1

実現, 15.4.1.4.1

暗黙的コミット, 7.2.1

2フェーズ・コミット, 10.4.1

コンパイル済PL/SQL

疑似コード, 8.4.6

共有プール, 8.2.6

トリガー, 8.4.6

完全リカバリ, 18.3.1.3.4, 18.3.1.3.4 コンポジット索引, 3.1.1.2, 3.1.1.2, 3.1.1.2 コンポジット・パーティション化, 4.1.1.2 複合トリガー, 8.4.3 圧縮

基本表, 2.2.9.1

データ・ブロック, 12.2.3

ハイブリッド列圧縮, 2.2.9.2

索引キー, 3.1.2.5

オンライン・アーカイブ, 2.2.9.2.1

表, 2.2.9, 4.1.2

ウェアハウス, 2.2.9.2.1

連結索引, 3.1.1.2, 3.1.1.2 同時実行性

定義, 9.1

内容を保証しない読取り, 9.1.3

ファジー読取り, 9.1.3

仮読取り, 9.1.3

行ロック, 9.4.1.1.1

トランザクション分離, 9.1.3, 9.2.2, 9.2.3

条件, SQL, 7.1.1, 7.2.2.1 書込みの競合, 9.2.1.2 接続, クライアント/サーバー

管理者権限, 13.2.1.1

定義, 15.2.2

埋込みSQL, 7.2.6

リスナー・プロセス, 16.2.2

セッションと対比, 15.2.2

一貫性

書込みの競合, 9.2.1.2

定義, 9.1

マルチバージョン, 9.1, 9.1.1

読取り一貫性クローン, 9.1.1.3.1 制約, 整合性

チェック, 5.2, 5.2.5

デフォルト値, 5.3.3.1

遅延可能, 5.2.3, 5.3.2.2, 5.3.2.2, 7.2.3

使用可能と使用禁止, 5.3.1

索引による規定, 5.2.3

外部キー, 5.2, 5.2.4

規定のメカニズム, 5.3.3

NOT NULL, 2.2.2, 5.2, 5.2.1

主キー, 2.2.2, 5.2, 5.2.3

REF, 5.2

参照, 5.2.4.3

自己参照型, 5.2.4.1

状態, 5.3

一意キー, 5.2, 5.2.2, 5.2.2

検証, 5.3.1

競合

データ

デッドロック, 9.3.6

ロックの段階的拡大, 9.3.4

コンテキスト, 2.1.1 制御ファイル, 11.3

記録される変更内容, 11.3.1

チェックポイント, 11.3.1

内容, 11.3.1

多重化, 11.3.2

概要, 11.3

データベースのマウントでの使用, 13.2.1.3

CREATE CLUSTER文, 2.3.1 CREATE DIMENSION文, 4.5.2, 4.5.2 CREATE GLOBAL TEMPORARY TABLE文, 2.2.6.1 CREATE INDEX文, 2.2.6.1, 3.1.1.1, 3.1.1.2, 3.1.2.4, 3.1.2.4, 3.1.4.1, 3.1.6, 4.1.3.2

記憶域パラメータ, 12.4.1.1

CREATE MATERIALIZED VIEW文, 4.3 CREATE SEQUENCE文, 4.4.1 CREATE SYNONYM文, 4.6 CREATE TABLEコマンド, 2.2.2 CREATE TABLE文, 2.2 CREATE TRIGGER文

コンパイルと格納, 8.4.6

CREATE UNIQUE INDEX文, 5.2.3 CREATE USER文

一時セグメント, 12.4.2.1

カーソル

埋込みSQL, 7.2.6

明示的, 8.2.4

行のフェッチ, 7.2.6

D

データ

一貫性

ロック, 9.1.2

手動ロック, 9.5

データ・ブロック, 7.4.2.1, 12.1

メモリーにキャッシュ, 14.4.1.3.4

クラスタ化行, 2.3

ブロック内の空き領域の結合, 12.2.4.2.1

圧縮, 12.2.3

形式, 12.2.2, 12.2.2.2

格納されているロック, 9.4.1.1.2

概要, 12.1.1

ROWIDでの表示, 12.2.2.2.3

バッファ・キャッシュに格納, 14.4.1

ディスクへの書込み, 14.4.1.3.4

データ変換

プログラム・インタフェース, 16.3

データ・ディクショナリ, 2.1.4, 2.2.4

接頭辞がALL_のビュー, 6.1.1.2

キャッシュ, 14.4.3

コメント, 7.2.1

内容, 6.1.1, 14.4.3.2

接頭辞がDBA_のビュー, 6.1.1.1

ディクショナリ管理表領域, 12.1.2.2

DUAL表, 6.1.1.4

動的パフォーマンス・ビュー, 6.2

ロック, 9.4.2

概要, 6.1

所有者, 6.1.3

パブリック・シノニム, 6.1.3.1

行キャッシュ, 14.4.3.2

ストアド・サブプログラム, 8.2.1.2

接頭辞がUSER_のビュー, 6.1.1.3

用途, 6.2

データ・ディクショナリ・キャッシュ, 6.1.3.2, 7.4.1.1.3, 14.4.3, 14.4.3.2 データ障害, 人為的エラーに対する保護, 17.2.1.5 データファイル

内容, 11.2.4

データファイル1, 12.5.1.1

制御ファイルに名前がある, 11.3.1

ROWIDでの表示, 12.2.2.2.3

SYSTEM表領域, 12.5.1.1

一時, 11.2.2

データ整合性, 5.1

規定, 5.1, 6.1.3

SQL, 7.1

データ操作言語, 「DML」を参照 データ・オブジェクト番号

拡張ROWID, 12.2.2.2.3

データ・ポンプ・エクスポート

ダンプ・ファイル・セット, 18.2.5.2

データ・リカバリ・アドバイザ, 18.3.1.3.1 データ・リダクション, 17.1.2, 17.1.4

ランダム, 17.1.4

データ・セグメント, 12.4.1 データ型

BOOLEAN, 2.2.3, 3.1.2.2.3, 7.2.2.1, 8.4.4, 用語集

組込み, 2.2.3

CHAR, 2.2.3.1.1

文字, 2.2.3.1

コンポジット型, 2.2.3

変換

プログラム・インタフェース, 16.3

DATE, 2.2.3.3.1 日時, 2.2.3.3 定義, 2.2.3 書式モデル, 2.2.3.3.1 表との関連, 2.2.1 PL/SQL, 2.2.3 LONG

記憶域, 2.2.8.1

NCHAR, 2.2.3.1.2 NUMBER, 2.2.3.2.1 数値, 2.2.3.2 NVARCHAR2, 2.2.3.1.2 オブジェクト, 2.2.5 参照型, 2.2.3 ROWID, 2.2.3.4 TIMESTAMP, 2.2.3.3.2 UROWID, 2.2.3.4 ユーザー定義, 2.2.3, 4.2.3 データ・ウェアハウス

アーキテクチャ, 17.4.2

ビットマップ索引, 3.1.3

ディメンション, 4.5

マテリアライズド・ビュー, 4.3

パーティション, 4.1

サマリー, 4.3

データベース・アプリケーション

定義, 1.1.1

データベース認証, 7.2.4, 15.2.2 データベース・バックアップ, 18.3.1.2.1 データベース・バッファ・キャッシュ, 2.2.9, 14.4.1, 15.4.1.3

キャッシュ・ヒットとキャッシュ・ミス, 14.4.1.3.2

コメントのキャッシュ, 6.1.3.2

フラッシュ・キャッシュ, 14.4.1

データベース・バッファ

トランザクションをコミットした後, 10.2.5

フラッシュ・キャッシュ内のバッファ本体, 14.4.1.3.2

バッファ・キャッシュ, 14.4.1

チェックポイントの位置, 15.4.1.3

トランザクションのコミット, 15.4.1.4.1

定義, 14.4.1

書込み, 15.4.1.3

Database Configuration Assistant, 6.2.1 データベース常駐接続プーリング, 16.2.5 データベース・サーバー・グリッド, 17.3

説明, 17.3.1

データベース記憶域グリッド, 17.3

説明, 17.3.2

データベース構造

制御ファイル, 11.3

データ・ブロック, 12, 12.2

データファイル, 11

エクステント, 12.1

プロセス, 15

セグメント, 12.1, 12.4

表領域, 11, 12.5

データベース・ライター・プロセス(DBWn), 15.4.1.3

チェックポイント, 15.4.1.3

定義, 15.4.1.3

LRUアルゴリズム, 14.4.1.3.4

複数のDBWnプロセス, 15.4.1.3

事前書込み, 15.4.1.4

データベース

管理アカウント, 2.1.4

キャラクタ・セット, 2.2.3.1

クローズ, 13.2.2.2

インスタンスの終了, 13.2.2.2.2

定義, 1.1 分散

グローバル・データベース名の変更, 14.4.3.1.3

階層, 1.1.1 歴史, 1.1.4 インカネーション, 18.3.1.3.4 概要, 1 マウント, 13.2.1.3 制御ファイルに格納される名前, 11.3.1 ネットワーク, 1.1.1 オブジェクト・リレーショナル, 1.1.3 オープン, 13.2.1.4, 13.2.1.4.1 リレーショナル, 1.1.2, 1.1.3, 7.1 停止, 13.2.2 起動, 2.1.4, 13.1

強制実行, 13.2.2.4

構造

制御ファイル, 11.3

データ・ブロック, 12, 12.2

データファイル, 11

エクステント, 12.1, 12.3

論理, 12

プロセス, 15

セグメント, 12.1, 12.4

表領域, 11, 12.5

DATEデータ型, 2.2.3.3, 2.2.3.3.1 日時データ型, 2.2.3.3 DBA_ビュー, 6.1.1.1 DBMS(データベース管理システム), 1.1.1 DBMS_METADATAパッケージ, 6.3 DBMS_RADMパッケージ, 17.1.4 DBMS_STATSパッケージ, 7.3.4 DBWnバックグラウンド・プロセス, 15.4.1.3 DDL(データ定義言語), 6.1

説明, 7.2.1

ロック, 9.4.2

処理, 7.4.3

デッドロック, 7.4.1.1

定義, 9.3.6

意思決定支援システム(DSS)

マテリアライズド・ビュー, 4.3

専用サーバー, 7.4.1.1.3 デフォルト値

制約が与える影響, 5.3.3.1

定義者権限, 8.2.1.1 並列度

パラレルSQL, 15.4.3.2.2

DELETE文, 7.2.2

データ・ブロック内の領域の解放, 12.2.4.2

削除, 連鎖的, 5.2.4.3 正規化されていない表, 4.5.2 依存性, スキーマ・オブジェクト, 2.1.3 降順索引, 3.1.2.4 ディテール表, 4.3 ディクショナリ・キャッシュ・ロック, 9.4.3.3 ディクショナリ管理表領域, 12.1.2.2 ディメンション, 4.5

属性, 4.5.2

階層, 4.5.2

結合キー, 4.5.2

正規化された表と正規化されていない表, 4.5.2 表, 4.5.1 ディレクトリ・オブジェクト, 2.1.1 内容を保証しない読取り, 9.1.1, 9.1.3, Glossary ディスク領域

割当てに使用されるデータファイル, 11.2.4, 11.2.4

ディスパッチャ・プロセス

説明, 16.2.4.1.1

ディスパッチャ・プロセス(Dnnn)

Oracle Net Servicesを介したクライアント・プロセスの接続, 16.2.4, 16.2.4.1.1

ネットワーク・プロトコル, 16.2.4.1.1

起動と停止の禁止, 16.2.4.2

レスポンス・キュー, 16.2.4.1

分散データベース

クライアント/サーバー・アーキテクチャ, 16.1.1.1

ジョブ・キュー・プロセス, 15.4.2.2

リカバラ・プロセス(RECO), 15.4.1.7

サーバーをクライアントとしても使用可能, 16.1.1.1

トランザクション, 10.4

分散トランザクション, 10.2.1, 10.4

インダウト, 10.4.2

命名, 10.2.1

2フェーズ・コミット, 10.4

DML(データ操作言語)

索引付けされた列, 3.1.3

非参照用索引, 3.1.1, 3.1.1

ロック, 9.4.1

概要, 7.2.2

参照アクション, 5.2.4.3

トリガー, 8.4.1

停止時間

計画メンテナンス中の回避, 17.2.2

計画外メンテナンス中の回避, 17.2.1.2

ドライバ, 16.3.2 DUAL表, 6.1.1.4 動的パーティション化, 15.4.3.2.2 動的パフォーマンスビュー(V$表), 6.2 動的SQL

DBMS_SQLパッケージ, 8.2.4

埋込み, 8.2.4

E

埋込みSQL, 7.1, 7.2.6, 8.3.2.2.2

トランザクションのエンキュー, 10.2.3.2

エンタープライズ・グリッド

Oracle Real Application Clusters, 17.3

Enterprise Manager

アラート・ログ, 13.6.2

動的パフォーマンス・ビューの使用, 6.2

パッケージの実行, 8.2.2.3

ロックとラッチのモニター, 9.4.3

停止, 13.2.2.1, 13.2.2.4

SQL文, 7.1.2

等価結合, 3.1.3.2 例外, PL/SQL, 8.2.4 排他ロック, 9.3.3

行ロック(TX), 9.4.1.1

表ロック(TM), 9.4.1.2

EXECUTE文, 8.2.1.3 実行計画, 4.3.3, 7.3.1, 7.3.2.3

EXPLAIN PLAN, 7.2.2

EXPLAIN PLAN文, 7.2.2, 7.3.2.3 明示的ロック, 9.5, 9.5 式, SQL, 3.1.1.1, 7.2.2.1 エクステント

データ・ブロックの集合, 12.3

定義, 12.1.1

ディクショナリ管理, 12.1.2.2

増分, 12.3.1

ローカルに管理される, 12.1.2.1

概要, 12.3

外部プロシージャ, 8.2.6 外部表, 2.2 抽出、変換、ロード(ETL)

概要, 17.4.3

F

ファクト表, 4.5.1

障害

データベース・バッファ, 13.4.1

文とプロセス, 15.4.1.1

高速コミット, 15.4.1.4.1 高速全索引スキャン, 3.1.2.2.2 高速リフレッシュ, 4.3.2 ファスト・スタート

オンデマンド・ロールバック, 13.4.4

フィールド, 2.2.2 ファイル管理ロック, 9.4.3.3 ファイル

アラート・ログ, 15.4.1.4.2

初期化パラメータ, 13.2.1.2, 13.5

パスワード

管理者権限, 13.2.1.1

サーバー・パラメータ, 13.2.1.2, 13.5 トレース・ファイル, 15.4.1.4.2 固定ビュー, 6.2.1 フラッシュ・キャッシュ

バッファ読取り, 14.4.1.3.2

定義, 14.4.1

最適化物理読取り, 14.4.1.3.2

浮動小数点数, 2.2.3.2.2 外部キー制約, 5.2 外部キー, 2.2.2, 5.2.4

親キー値の変更, 5.2.4.3

コンポジット, 5.2.4

索引, 3.1.1.1

親キー表の更新, 5.2.4.3

表の更新, 9.4.1.3

書式モデル, データ型, 2.2.3.3.1, 2.2.3.5 空き領域

自動セグメント領域管理, 12.2.4

管理, 12.2.4

全索引スキャン, 3.1.2.2.1 全表スキャン, 3.1, 3.1.2.2.2, 5.2.4.4, 7.3.3

LRUアルゴリズム, 14.4.1.3.4

パラレル実行, 15.4.3.2.2

ファンクション索引, 3.1.4 ファンクション, 7.2.2.1

ファンクション索引, 3.1.4

ハッシュ, 4.1.1.2.3

PL/SQL, 8.2.1

SQL, 2.2.3.4.2

ファジー読取り, 9.1.3

G

グローバル・データベース名

共有プール, 14.4.3.1.3

グローバル索引, 4.1.3, 4.1.3.2 GRANT文, 4.6, 7.2.1 グリッド・コンピューティング

データベース・サーバー・グリッド, 17.3

データベース記憶域グリッド, 17.3

グループ・コミット, 15.4.1.4.1 GV$ビュー, 6.2.1

H

SQL文のハンドル, 14.3.1.1

ハード解析, 7.4.1.1.3

ハッシュ・クラスタ, 2.3.2, 2.3.2

クラスタ・キー, 2.3.2.1

ハッシュ衝突, 2.3.2.4

ハッシュ・キー値, 2.3.2.1

クエリー, 2.3.2.2

単一表, 2.3.2.3

記憶域, 2.3.2.4

ハッシュ関数, 2.3.2, 4.1.1.2.3 ハッシュ・パーティション, 4.1.1.2.3, 4.1.1.2.3 ヘッダー, データ・ブロック, 9.4.1.1.2 ヘッダー, データ・ブロック, 12.2.2.1 状態モニター, 18.3.1.3.1 ヒープ構成表, 2.1.2, 3.2 高さ, 索引, 3.1.2.1 階層

結合キー, 4.5.2

レベル, 4.5.2

ヒント, オプティマイザ, 7.3.1, 7.3.5 ハイブリッド列圧縮, 2.2.9.2

I

暗黙的問合せ, 7.2.2.3

インカネーション, データベース, 18.3.1.3.4

増分リフレッシュ, 4.3.2

索引の一意スキャン, 3.1.2.2.4

索引

アプリケーション・ドメイン, 3.1.5

昇順, 3.1.2.4

ビットマップ, 3.1.3, 4.1.3.1

ビットマップ結合, 3.1.3.2

ブランチ・ブロック, 3.1.2.1

Bツリー, 2.2.8.3, 3.1.2

カーディナリティ, 3.1.3

コンポジット, 3.1.1.2, 3.1.1.2

圧縮, 3.1.2.5

連結, 3.1.1.2

降順, 3.1.2.4

ドメイン, 3.1.5

整合性制約の規定, 5.2.3

拡張可能, 3.1.5

ファンクション, 3.1.4

グローバル, 4.1.3, 4.1.3.2

非参照用, 3.1.1

キー, 3.1.1.1, 3.1.2.5, 5.2.3

リーフ・ブロック, 3.1.2.1

非同一キー, ローカル, 4.1.3.1.1

非一意, 3.1.1.3

概要, 3.1

パーティション, 4.1.3

同一キー, ローカル, 4.1.3.1.1

逆キー, 3.1.2.3

スキャン, 3.1.2.2, 3.1.2.2.3, 3.1.2.2.5, 7.3.3

2次, 3.2.3

セグメント, 3.1.3.3

選択性, 3.1.2.2.3

記憶域, 3.1.6

タイプ, 3.1.1.4

一意, 3.1.1.3

索引, ローカル, 4.1.3 索引構成表, 3.2, 3.2.3

利点, 3.2

パーティション化, 4.1.4

行オーバーフロー, 3.2.2

2次索引, 3.2.3

情報システム, 1.1 初期化パラメータ・ファイル, 13.2.1.2, 13.5

起動, 13.2.1.2

初期化パラメータ

基本, 13.5.1

OPEN_CURSORS, 14.3.1.1

SERVICE_NAMES, 16.2.2.2

内部結合, 7.2.2.2 INSERT文, 7.2.2 インスタンスPGA

定義, 14.1.1

インスタンス・リカバリ

SMONプロセス, 15.4.1.2

インスタンス, 7.2.5

データベースに対応付け, 13.2.1.3

説明, 13.1

障害, 9.4.1.1

メモリー構造, 14.1

マルチ・プロセス, 15.1.1

プロセスの構造, 15.1

リカバリ

SMONプロセス, 15.4.1.2

サービス名, 16.2.2 停止, 13.2.2, 13.2.2.4 終了, 13.2.2.2.2 INSTEAD OFトリガー, 8.4.2 整合性制約, 5.1

利点, 5.1

チェック, 5.2.5

定義, 2.2.4

表内, 5.2

表外, 5.2

ビュー, 4.2.1.1

Interested Transaction List(ITL), 9.1.1.3.2 内部ロック, 9.4.3.3 非参照用索引, 3.1.1 実行者権限, 8.2.1.1 分離レベル

読取り専用, 9.2.3

シリアライズ, 9.2.2

設定, 9.5

分離レベル, トランザクション, 9.1.3

コミット読取り, 9.2.1

J

Java

コール仕様, 8.3.2.1

概要, 8.3

SQLJトランスレータ, 8.3.2.2.2

ストアド・プロシージャ, 1.3.2, 8.3.2.1

仮想マシン, 8.3.1

JDBC

SQLへのアクセス, 8.3.2.2

ドライバ・タイプ, 8.3.2.2.1

ドライバ, 8.3.2.2.1

埋込みSQL, 7.2.6

ジョブ・キュー・プロセス, 15.4.2.2 ジョブ, 15.1 結合ビュー, 4.2.2 結合, 6.1.1

ネストしたループ, 7.4.1.4

ビュー, 4.2.2

結合, 表, 3.1.3.2, 7.2.2.2

デカルト, 7.2.2.2

クラスタ化表, 2.3

条件, 3.1.3.2

内部結合, 7.2.2.2

結合条件, 7.2.2.2

外部結合, 7.2.2.2

ビュー, 4.2

K

キー保存表, 4.2.2

キー

圧縮, 3.1.2.5

索引の連結, 3.1.2.5

外部, 5.2.4, 5.2.4

索引, 3.1.1.1, 3.1.2.5, 5.2.3

自然, 5.2.3

親, 5.2.4

パーティション, 4.1.1.1

同一キー索引, 3.1.2.1, 3.1.2.5

参照, 5.2.4

逆, 3.1.2.3

サロゲート, 5.2.3

一意, 5.2.2

値, 5.2

L

ラージ・プール, 14.4.4

ラッチ

定義, 9.4.3.1

エンキュー, 9.4.3.1

解析, 7.4.1.1.3

スリープ, 9.4.3.1

スピン, 9.4.3.1

リーフ・ブロック, 索引, 3.1.2.1 最低使用頻度(LRU)アルゴリズム

データベース・バッファ, 14.4.1.1, 14.4.1.1

全表スキャン, 14.4.1.3.4

ラッチ, 14.4.1.3.4

共有SQLプール, 14.4.3.1.3, 14.4.3.1.3

LGWRバックグラウンド・プロセス, 15.4.1.4 ライブラリ・キャッシュ, 7.4.1.1.3, 14.4.3, 14.4.3.1 リスト・パーティション, 4.1.1.2.2 リスナー・プロセス, 16.2.2

サービス名, 16.2.2

リスナー, 16.2.2

サービス名, 16.2.2

ローカル索引, 4.1.3 ローカル管理表領域, 12.1.2.1 LOCK TABLE文, 7.2.2 ロック, 9.1.2

トランザクションをコミットした後, 10.2.5

自動, 9.3.2, 9.4

ビットマップ索引, 3.1.3

変換, 9.3.3, 9.3.3, 9.3.4

デッドロック, 7.4.1.1, 9.3.6

ディクショナリ, 9.4.2

ディクショナリ・キャッシュ, 9.4.3.3

DML, 9.4.1

処理時間, 9.3.2, 9.3.5

段階的な拡大, 9.3.3, 9.3.4

排他, 9.3.3

排他DDL, 9.4.2.1

排他表, 9.4.1.2

ファイル管理ロック, 9.4.3.3

ラッチ, 9.4.3.1

ログ管理ロック, 9.4.3.3

手動, 9.5

概要, 9.1.2

解析, 9.4.2.3

制限, 9.3.3

ロールバック・セグメント, 9.4.3.3

行排他表, 9.4.1.2

行共有, 9.4.1.2

行(TX), 9.4.1.1

共有DDL, 9.4.2.2

共有ロック, 9.3.3

共有行排他, 9.4.1.2

共有表, 9.4.1.2

システム, 9.4.3

表, 3.1, 7.2.2

表(TM), 9.4.1.2

表領域, 9.4.3.3

タイプ, 9.4

索引なしの外部キー, 9.4.1.3

ユーザー定義, 9.6

ログ管理ロック, 9.4.3.3 ログ・スイッチ

アーカイバ・プロセス, 15.4.2.1

ログ・スイッチ

ログ順序番号, 11.4.2.1

ログ・ライター・プロセス(LGWR), 15.4.1.4

グループ・コミット, 15.4.1.4.1

使用可能なオンラインREDOログ, 11.4.2.1

REDOログ・バッファ, 14.4.2

事前書込み, 15.4.1.4

オンラインREDOログ・ファイルへの書込み, 11.4.2.1

論理データベース構造

定義, 1.5.2.2

表領域, 12.5

論理ROWID, 3.2.3 LONGデータ型

記憶域, 2.2.8.1

更新内容の消失, 9.2.1.2 LRU, 14.4.1.1, 14.4.1.1, 14.4.1.3.4, 14.4.1.3.4

共有SQLプール, 14.4.3.1.3, 14.4.3.1.3

M

メンテナンス・タスク, 自動, 18.3.4.2

メンテナンス時間枠, 18.3.4.2

手動ロック, 9.5

マッピング表, 3.2.3.2

マスター表, 4.3, 4.3

マテリアライズド・ビュー, 4.3

ログ, 4.3.2

パーティション化, 4.3.1

リフレッシュ

ジョブ・キュー・プロセス, 15.4.2.2

リフレッシュ, 4.3.2 メディア・リカバリ

完全, 18.3.1.3.4, 18.3.1.3.4

概要, 18.3.1.3.4, 18.3.1.3.4, 18.3.1.3.4, 18.3.1.3.4, 18.3.1.3.4

メモリー

SQL文のための割当て, 14.4.3.1.1

内容, 14.1

プロセスでの使用, 15.1

ソフトウェア・コード領域, 14.5

ストアド・プロシージャ, 8.2.1.1

メモリー管理

説明, 18.3.2

自動, 18.3.2.1

自動共有, 18.3.2.2

MERGE文, 7.2.2 メトリック, 6.2, 18.3.4.1 ユーザー・アクションの監視, 17.1.6.1 マルチブロック書込み, 15.4.1.3 マルチ・プロセス・システム(マルチユーザー・システム), 15.1.1 多重化

制御ファイル, 11.3.2

REDOログ・ファイル・グループ, 11.4.2.2

REDOログ・ファイル, 11.4.2.2, 11.4.2.2

マルチユーザー環境, 15.1.1 マルチバージョン読取り一貫性, 6.2.2, 7.4.2.1, 9.1, 9.1.1, 9.1.1, 9.1.3

読取り一貫性クローン, 9.1.1.3.1

内容を保証しない読取り, 9.1.1, 用語集

コミット読取り分離レベル, 9.2.1.1

文レベル, 1.4.3, 9.1.1.1

トランザクション・レベル, 9.1.1.2

UNDOセグメント, 9.1.1.3

mutex, 9.4.3.2

N

自然キー, 5.2.3

NCHARデータ型, 2.2.3.1.2

ネットワーク・リスナー・プロセス

接続リクエスト, 16.2.4.1.1

ネットワーク

クライアント/サーバー・アーキテクチャでの使用, 16.1.1

通信プロトコル, 16.3.2, 16.3.3

ディスパッチャ・プロセス, 16.2.4.1.1, 16.2.4.1.1

ドライバ, 16.3.2

リスナー・プロセス, 16.2.2

Oracle Net Services, 16.2

NLS_DATE_FORMATパラメータ, 2.2.3.3.1 NOAUDIT文, 7.2.1 非一意索引, 3.1.1.3 正規化された表, 4.5.2 NOT NULL制約, 5.2, 5.2.1 NULL, 2.2.2

外部キー, 5.2.4.2

格納方法, 2.2.2, 2.2.8.4

索引付き, 3.1.1.3

禁止, 5.2.1

NUMBERデータ型, 2.2.3.2.1 数値データ型, 2.2.3.2

浮動小数点数, 2.2.3.2.2

NVARCHAR2データ型, 2.2.3.1.2

O

オブジェクト表, 2.2.5

オブジェクト型, 2.2.5, 4.2.3

オブジェクト・ビュー, 4.2.3

OLAP

索引構成表, 3.2

概要, 17.4.4.2

オンライン分析処理

「OLAP」を参照

オンラインREDOログ

チェックポイント, 11.3.1

OPEN_CURSORSパラメータ

プライベートSQL領域の管理, 14.3.1.1

オペレーティング・システム

通信ソフトウェア, 16.3.3

管理者の権限, 13.2.1.1

演算子, SQL, 7.2.2.1 最適化, SQL, 7.4.1.2 最適化物理読取り, 14.4.1.3.2 オプティマイザ, 7.1.1, 7.3, 7.3

コンポーネント, 7.3.2

エスティメータ, 7.3.2.2

実行, 7.4.1.4

実行計画, 4.3.3, 7.3.1, 7.4.1.3

ファンクション索引, 3.1.4.2

ヒント, 7.3.1, 7.3.5

非参照用索引, 3.1.1, 3.1.1

問合せ計画のパーティション, 4.1

プラン・ジェネレータ, 7.3.2.3

問合せ計画, 7.4.1.3

クエリー・リライト, 4.3.3

問合せトランスフォーマ, 4.3.3, 7.3.2.1

行ソース, 7.4.1.3, 7.4.1.3

統計, 2.2.8.1, 7.3.4

統計の収集, 18.3.4.2

Oracle

構成

マルチ・プロセスOracle, 15.1.1

インスタンス, 13.1 プロセス, 15.3 Oracle Audit Vault, 17.1.6.2 Oracleブロック, 12.1.1 Oracle Call Interface, 「OCI」を参照 Oracleコード, 16.3 Oracle Flashbackテクノロジ, 18.3.1.3.2 Oracle interMedia,

「Oracle Multimedia」を参照

Oracle Internet Directory, 16.2.2.2 Oracle JVM

主要なコンポーネント, 8.3.1.2

概要, 8.3.1.1

Oracle Multimedia, 19.3.4.4 Oracle Net Services, 16.2

クライアント/サーバー・システムでの使用, 16.2

概要, 16.2

共有サーバーの要件, 16.2.4.1.1

Oracle Net Services Connection Manager, 8.3 Oracle Program Interface(OPI), 16.3.1, 16.3.1 Oracle Real Application Clusters, 6.2.1

エンタープライズ・グリッド, 17.3

逆キー索引, 3.1.2.3

Oracle Streams, 17.5.2 Oracle Text, 19.3.4.3 Oracle XA

ラージ・プール内のセッション・メモリー, 14.4.4

ORDBMS(オブジェクト・リレーショナル・データベース管理システム), 1.1.3 外部結合, 7.2.2.2

P

パッケージ, 8.2.2

利点, 8.2.2.1

実行, 8.2.6

ロック用, 9.6

プライベート, 8.2.2.1

パブリック, 8.2.2.1

共有SQL領域, 14.4.3.1.2

ページ, 12.1.1 パラレル実行, 15.4.3.2

コーディネータ, 15.4.3.2.2

サーバー, 15.4.3.2.2

サーバー, 15.4.3.2.2

チューニング, 15.4.3.2

パラレルSQL, 15.4.3.2

コーディネータ・プロセス, 15.4.3.2.2

サーバー・プロセス, 15.4.3.2.2

パラメータ

サーバー, 13.5

パラメータ

初期化, 13.5

ロック動作, 9.4

記憶域, 12.3.3 解析ロック, 9.4.2.3 解析

埋込みSQL, 7.2.6

情報の記憶域, 6.1.3.2

解析, SQL, 7.4.1.1

ハード解析, 7.4.1.1.3, 9.4.3.1

ソフト解析, 7.4.1.1.3

パーティション, 4.1

コンポジット, 4.1.1.2

動的パーティション化, 15.4.3.2.2

問合せからの除外, 4.1.3.1.1

ハッシュ, 4.1.1.2.3

索引, 4.1.3

索引構成表, 4.1.4

キー, 4.1.1.1

マテリアライズド・ビュー, 4.3.1

レンジ, 4.1.1.2

リカバリ, 4.1.3.1

セグメント, 12.4.1

単一レベル, 4.1.1.2

計画, 4.1.1.2

表, 4.1.2

表, 4.1.4

パスワード

管理者権限, 13.2.1.1

接続, 15.2.2

PCTFREE記憶域パラメータ

仕組み, 12.2.4.1

パフォーマンス

動的パフォーマンス・ビュー(V$), 6.2

グループ・コミット, 15.4.1.4.1

パッケージ, 8.2.2.1

PGA, インスタンス

定義, 14.1.1

仮読取り, 9.1.3 物理データベース構造

制御ファイル, 11.3

物理推測, 3.2.3.1 計画

SQLの実行, 7.2.2

計画停止時間

停止時間の回避, 17.2.2

PL/SQL

無名ブロック, 8.2, 8.2.3

コレクション, 8.2.5.1

データ型, 2.2.3

動的SQL, 8.2.4

例外, 8.2.4

実行, 8.2.6

言語構造, 8.2.4

概要, 8.2

パッケージ, 6.3, 8.2.2

PL/SQLエンジン, 8.2.6

プログラム・ユニット, 8.2, 14.4.3.1.2

コンパイル済, 8.2.6

共有SQL領域, 14.4.3.1.2

レコード, 8.2.5.1 ストアド・プロシージャ, 1.3.2, 6.1.1.2, 8.2, 8.2.1 PMONバックグラウンド・プロセス, 15.4.1.1 プラグマ, PL/SQL, 10.3 プリコンパイラ, 8.1

埋込みSQL, 7.2.6, 7.2.6

述語, SQL, 3.1.2.2.1

SQL

述語, 7.1.1

主キー制約, 5.2 主キー, 2.2.2, 3.1

制約, 5.2.3, 5.2.3, 5.2.3

ハッシュ・クラスタ, 2.3.2.3

索引構成表, 2.2

プライベートSQL領域, 14.4.3.1.1

説明, 14.4.3.1.1

どのように管理されるか, 14.3.1.1

解析, 7.4.1.1

プライベート・シノニム, 4.6 権限, 6.1, 7.2.4

管理者, 13.2.1.1, 13.2.1.1

付与, 7.2.1

PL/SQLプロシージャ, 8.2.1.1

取消し, 7.2.1

プロシージャ

利点, 8.2.1.1

実行, 8.2.1.3, 8.2.1.3, 8.2.6

外部, 8.2.6

メモリー割当て, 8.2.1.1

セキュリティ, 8.2.1.1

共有SQL領域, 14.4.3.1.2

ストアド・プロシージャ, 1.3.2, 6.1.1.2, 8.2, 8.2.6

プロセス・モニター(PMON)・プロセス

説明, 15.4.1.1

プロセス, 15.1

アーカイバ(ARCn), 15.4.2.1

バックグラウンド, 15.4

チェックポイント, 15.4.1.3

クライアント, 15.2

専用サーバー, 7.4.1.1.3, 16.2.4.1.2

分散トランザクションの解決, 15.4.1.7

ジョブ・キュー, 15.4.2.2

リスナー, 16.2.2

共有サーバー, 16.2.4.1.1

ログ・ライター(LGWR), 15.4.1.4 マルチ・プロセスOracle, 15.1.1 Oracle, 15.3 パラレル実行コーディネータ, 15.4.3.2.2 パラレル実行サーバー, 15.4.3.2.2 プロセス・モニター(PMON), 15.4.1.1 リカバラ(RECO), 15.4.1.7 サーバー, 15.3

共有, 16.2.4.1.1, 16.2.4.1.2

共有サーバー, 16.2.4

クライアントのリクエスト, 16.2.4.1

構造, 15.1 システム・モニター(SMON), 15.4.1.2 ユーザー

障害からのリカバリ, 15.4.1.1

サーバー・プロセスの共有, 16.2.4.1.1

処理

パラレルSQL, 15.4.3.2

プログラム・グローバル領域(PGA), 14.1.1

共有サーバー, 16.2.4.1.2

共有サーバー, 16.2.4.1.2

プログラム・インタフェース, 16.3

Oracle側(OPI), 16.3.1

構造, 16.3.1

ユーザー側(UPI), 16.3.1

プログラム・ユニット, 8.2

共有プール, 14.4.3.1.2

プログラミング, サーバー側, 8.1 疑似コード

トリガー, 8.4.6

疑似列, 2.2.3.4.2, 3.2.1 パブリック・シノニム, 4.6

Q

クエリー

ブロック, 7.2.2.3

定義, 7.2.2.1

暗黙的, 7.2.2.3, 9.2.1.1

DML, 7.2.2

パラレル処理, 15.4.3.2

問合せブロック, 7.3.2.3

問合せトランスフォーマ, 7.3.2.1

SQL言語, 7.1

ストアド, 4.2

副問合せ, 4.2, 7.2.2, 7.2.2.3

問合せブロック, 7.3.2.3 問合せ計画, 7.4.1.3

パーティション, 4.1

クエリー・リライト, 4.3.3, 4.5 問合せトランスフォーマ, 4.3.3

R

レンジ・パーティション, 4.1.1.2

RDBMS(リレーショナル・データベース管理システム), 1.1.3

コミット読取り分離, 9.2.1

非コミット読取り, 9.1.3

読取り専用分離レベル, 9.2.3

Real Application Clusters

キャッシュ・フュージョン, 9.1.1.3

システム・モニター・プロセス, 15.4.1.2

オンラインREDOログのスレッド, 11.4.2

レコード, PL/SQL, 8.2.5.1 リカバラ・プロセス(RECO), 15.4.1.7

インダウト・トランザクション, 10.4.2

リカバリ

完全, 18.3.1.3.4

データベース・バッファ, 13.4.1

分散処理, 15.4.1.7

インスタンス・リカバリ

SMONプロセス, 15.4.1.2

メディア, 18.3.1.3.4, 18.3.1.3.4, 18.3.1.3.4, 18.3.1.3.4 メディア・リカバリ

ディスパッチャ・プロセス, 16.2.4.2

プロセスのリカバリ, 15.4.1.1 インスタンスの終了後に必要, 13.2.2.2.2, 13.2.2.2.2 トランザクションのロールバック, 13.4.4 表領域

ポイント・イン・タイム, 18.3.1.3.4

Recovery Manager(RMAN), 6.2 再帰的SQL, 7.4.3 リダクション, データ, 17.1.2, 17.1.4

ポリシー, 17.1.4

REDOログ・ファイル

使用可能, 11.4.2.1

循環使用, 11.4.2.1

内容, 11.4.3

分散トランザクション情報, 11.4.2

グループ・メンバー, 11.4.2.2

グループ, 定義, 11.4.2.2

インスタンス・リカバリでの使用, 11.4

LGWR, 11.4.2.1

メンバー, 11.4.2.2

多重化, 11.4.2.2, 11.4.2.2

オンライン, 定義, 11.4

REDOエントリ, 11.4.3

スレッド, 11.4.2

「REDOログ・ファイル」も参照

REDOログ

アーカイバ・プロセス(ARCn), 15.4.2.1

バッファ管理, 15.4.1.4

コミット済データ, 13.4.1

トランザクションのコミット, 15.4.1.4.1

ログ・スイッチ

アーカイバ・プロセス, 15.4.2.1

ログ・ライター・プロセス, 14.4.2, 15.4.1.4 ロールフォワード, 13.4.1 バッファの書込み, 15.4.1.4 REDOログ・バッファ, 14.4.2 REDOレコード, 11.4.3 REF制約, 5.2 参照整合性

例, 5.3.3

自己参照型制約, 5.3.3

リフレッシュ

増分, 4.3.2

ジョブ・キュー・プロセス, 15.4.2.2

マテリアライズド・ビュー, 4.3.2

リレーショナル・データベース管理システム, 「RDBMS」を参照 レプリケーション, Oracle Streams, 4.3, 17.5.2.1

双方向, 17.5.2.1.2

ハブ・アンド・スポーク, 17.5.2.1.2

マスター・データベース, 4.3

N方向, 17.5.2.1.2

一方向, 17.5.2.1.2

予約語, 7.2 レスポンス・キュー, 16.2.4.1 結果キャッシュ, 14.4.3.3, 14.4.3.3.1 結果セット, SQL, 2.2, 2.2.3.4.2, 2.2.6, 4.2.2, 7.4.1.3, 7.4.2 RESULT_CACHE句, 14.4.3.3.1 結果セット, SQL, 7.2.2.1 逆キー索引, 3.1.2.3 REVOKE文, 7.2.1 権限, 定義者および実行者, 8.2.1.1 ロール, 2.1.1, 6.1.1.2, 7.2.4 ロールバック, 10.2.3.1, 10.2.4

説明, 10.2.3.1, 10.2.4

トランザクションの終了, 10.2.3.1, 10.2.4

DDLでの暗黙的, 7.2.1

文レベル, 10.1.3

セーブポイントまで, 10.2.3.1

ロールバック・セグメント

ロック, 9.4.3.3

パラレル・リカバリ, 13.4.4

リカバリ中の使用, 13.4.4

ROLLBACK文, 10.2 ロールバック, 文レベル, 9.3.6 ロールバック, トランザクション, 7.2.3 ロールバック, 10.1, 10.2.3.1, 10.2.4 行キャッシュ, 14.4.3.2 行データ(データ・ブロックのセクション), 12.2.2.2 行ディレクトリ, 12.2.2.1 行ロック, 9.4.1.1

同時実行性, 9.4.1.1.1

記憶域, 9.4.1.1.2

行断片, 2.2.8.2 行ソース生成, 7.4.1.3 ROWIDデータ型, 2.2.3.4 ROWID, 2.2.8.3

外部, 2.2.3.4

索引, 3.1.1.3

論理, 2.2.3.4, 3.2.3

物理, 2.2.3.4

行の移行, 12.2.4.3

スキャン, 7.3.3

ユニバーサル, 2.2.3.4

行

アドレス, 2.2.8.3

ブロックにまたがる連鎖, 2.2.8.2, 12.2.4.3

クラスタ化, 2.2.8.2

定義, 2.2.1

データ・ブロック内での形式, 12.2.2.1

ロック, 9.4.1.1

ロック, 9.4.1.1

新規ブロックへの移行, 12.2.4.3

行セット, 7.4.1.3

行ソース, 7.4.1.3

ROWIDでの表示, 12.2.2.2.3

記憶域, 2.2.8.2

トリガー, 8.4.2

S

サンプル・スキーマ, 2.1.5

SAVEPOINT文, 7.2.3

セーブポイント, 7.2.3, 10.2.3

定義, 10.2.3

暗黙的, 10.1.3

ロールバック, 10.2.3.1

SAVEPOINT文, 10.2

スキャン

クラスタ, 7.3.3

高速全索引, 3.1.2.2.2

全索引, 3.1.2.2.1

全表, 3.1, 5.2.4.4, 7.3.3, 14.4.1.3.4

索引, 3.1.2.2, 7.3.3

索引スキップ, 3.1.2.2.5

レンジ, 2.3.2.2

ROWID, 7.3.3

一意索引, 3.1.2.2.4

スキーマ・オブジェクト

定義, 6.1, 7.2.1

依存性, 2.1.3, 4.2.1

ディメンション, 4.5

索引, 3.1.1

概要, 2.1

マテリアライズド・ビュー, 4.3

データファイルとの関連, 11.2.1

順序, 4.4

記憶域, 2.1.2

スキーマ, 2.1 スキーマ, サンプル, 2.1.5 SCN

「システム変更番号」を参照

2次索引, 3.2.3

利点, 3.2.3

物理推測, 3.2.3.1

SecureFiles, 19.3.4.2.3 セキュリティ

管理者権限, 13.2.1.1

監査, 17.1.6.1

定義者権限, 8.2.1.1

プログラム・インタフェースでの規定, 16.3

ビュー, 4.2

セグメント・アドバイザ, 18.3.4.2 セグメント, 12.4

データ, 12.4.1

定義, 12.1.1

索引, 3.1.3.3, 3.1.6

概要, 12.4

表の記憶域, 2.2.8

一時, 2.2.6.2, 12.4.2

割当て, 12.4.2

SELECT構文のリスト, SQL, 7.2.2.1 SELECT文, 7.2.2 選択性, 3.1.2.2.3, 3.1.4.2 自己参照型整合性制約, 5.2.4.1 順序

同時アクセス, 4.4.2

定義, 4.4

サロゲート・キー, 5.2.3

シリアライズ可能性, トランザクション, 9.1 シリアライズ可能分離レベル, 9.2.2 サーバー・パラメータ・ファイル

起動, 13.2.1.2

サーバー・プロセス, 15.3, 15.3

リスナー・プロセス, 16.2.2

サーバー

クライアント/サーバー・アーキテクチャ, 16.1.1

共有

アーキテクチャ, 15.1.2, 16.2.4

プロセス, 16.2.4, 16.2.4.1.2

サーバー側プログラミング, 8.1

概要, 8.1

サービス名, 16.2.2 サービス指向アーキテクチャ, 1.5.4.1, 16.1.2.4 SERVICE_NAMESパラメータ, 16.2.2.2 セッション制御文, 7.2.4 セッション, 7.2.4

接続と対比, 15.2.2

定義, 15.2.2

ラージ・プール内のメモリー割当て, 14.4.4

順序生成, 4.4.2

SET CONSTRAINT文, 7.2.3 SET TRANSACTION文, 7.2.3, 10.1.2.1 SGA(システム・グローバル領域)

割当て, 13.2.1.2

内容, 14.4

データ・ディクショナリ・キャッシュ, 6.1.3.2, 14.4.3.2

データベース・バッファ・キャッシュ, 14.4.1

ラージ・プール, 14.4.4

REDOログ・バッファ, 10.2.2, 14.4.2

ロールバック・セグメント, 10.2.2

共有および書込み可能, 14.4

共有プール, 8.2.1.1, 14.4.3

可変パラメータ, 13.5.1.1

共有DDLロック, 9.4.2.2 共有ロック, 9.3.3 共有プール, 8.2.6, 14.4.3, 14.4.3.1.3

割当て, 14.4.3.1.3

チェック, 7.4.1.1.3

依存性管理, 14.4.3.1.3

説明, 14.4.3

フラッシュ, 14.4.3.1.3

ラッチ, 9.4.3.1

解析ロック, 9.4.2.3

行キャッシュ, 14.4.3.2

共有サーバー

説明, 15.1.2

ディスパッチャ・プロセス, 16.2.4.1.1

Oracle Net ServicesまたはSQL*Net V2の要件, 16.2.4.1.1

プロセス, 16.2.4.1.2, 16.2.4.1.2

必要なプロセス, 16.2.4

限定的運用, 16.2.4.2

ラージ・プール内のセッション・メモリー, 14.4.4

共有サーバー・プロセス(Snnn), 16.2.4.1.2

説明, 16.2.4.1.2

共有SQL領域, 4.2.1.2, 7.4.1.1.3, 14.4.3, 14.4.3.1.1, 14.4.3.1.3

依存性管理, 14.4.3.1.3

説明, 14.4.3.1.1

解析ロック, 9.4.2.3

プロシージャ、パッケージ、トリガー, 14.4.3.1.2

停止, 13.2.2, 13.2.2.4

異常, 13.2.2.4

ディスパッチャ・プロセスでは禁止, 16.2.4.2

手順, 13.2.2

SHUTDOWN ABORT文, 13.2.2.4 Simple Object Access Protocol (SOAP), 「SOAP」を参照 単一のトリガー, 8.4.3 単一レベル・パーティション化, 4.1.1.2 SMONバックグラウンド・プロセス, 15.4.1.2 SOA, 1.5.4.1, 16.1.2.4 SOAP(Simple Object Access Protocol), 1.5.4.1 ソフト解析, 7.4.1.1.3 ソフトウェア・コード領域, 14.5 領域管理

エクステント, 12.3

PCTFREE, 12.2.4.1

行連鎖, 12.2.4.3

セグメント, 12.4

SQL, 7.1, 7.2

条件, 7.1.1, 7.2.2.1

データ定義言語(DDL), 7.2.1

データ操作言語(DML), 7.2.2

ディクショナリ・キャッシュ・ロック, 9.4.3.3

動的SQL, 8.2.4

埋込み, 7.1, 7.2.6, 7.2.6

実行可能, 10.1.2.1

実行, 7.4.1.4, 10.1.3

式, 3.1.1.1, 7.2.2.1

ファンクション, 2.2.3.4.2, 7.1.2

ID, 7.4.1.1.3

暗黙的問合せ, 7.2.2.3

対話型, 7.1

メモリー割当て, 14.4.3.1.1

演算子, 7.1.1, 7.2.2.1

最適化, 7.4.1.2

Oracle, 7.1.2

概要, 7.1

パラレル実行, 15.4.3.2

解析, 7.4.1.1

PL/SQL, 8.2

述語, 3.1.2.2.1

再帰, 7.4.3

予約語, 7.2

結果セット, 2.2, 2.2.3.4.2, 2.2.6, 4.2.2, 7.2.2.1, 7.4.1.3, 7.4.2

SELECT構文のリスト, 7.2.2.1

セッション制御文, 7.2.4

処理の段階, 7.4.1

規格, 7.1.2

文, 7.2

副問合せ, 4.2, 7.2.2.3

システム制御文, 7.2.5

トランザクション制御文, 7.2.3

トランザクション, 10.1

トランザクション, 10.2.5

文のタイプ, 7.2

SQL領域

プライベート, 14.4.3.1.1

共有, 14.4.3.1.1

SQL計画の管理(SPM), 7.3.2.3 SQLチューニング・アドバイザ, 18.3.4.2 SQL*Plus

アラート・ログ, 13.6.2

パッケージの実行, 8.2.2.3

ロックとラッチのモニター, 9.4.3

SQL文, 7.1.2

SQLJ規格, 8.3.2.2.2 規格

ANSI/ISO, 7.1.2

分離レベル, 9.1.3

起動, 13.1

ディスパッチャ・プロセスでは禁止, 16.2.4.2

文レベルの原子性, 10.1.3 文レベルの読取り一貫性, 9.1.1.1 文レベルのロールバック, 9.3.6, 10.1.3 文, SQL, 7.2 統計, 2.2.8.1, 6.2, 7.3.1, 7.4.1.2, 14.4.3.1.3

ASH, 18.3.4.4

AWR, 18.3.4.2

定義, 7.3.4

オプティマイザ用に収集, 18.3.4.2

Java関連, 14.4.5

結合順序, 7.2.2.2

UNDO保存, 12.5.1.3.2

記憶域

論理構造, 12.5

NULL, 2.2.2

トリガー, 8.4.6, 8.4.6

STORAGE句

使用, 12.3.3

記憶域パラメータ

設定, 12.3.3

Structured Query Language(SQL), 7.1 構造

ロック, 9.4.2

論理, 12

データ・ブロック, 12, 12.2

エクステント, 12.1, 12.3

セグメント, 12.1, 12.4

表領域, 11, 12.5

物理

制御ファイル, 11.3

データファイル, 11

プロセス, 15 副問合せ, 4.2, 7.2.2, 7.2.2.3 サマリー, 4.3 サロゲート・キー, 5.2.3 シノニム

制約が間接的に影響する, 5.3.3.2

データ・ディクショナリ・ビュー, 6.1.3.1

定義, 4.6

プライベート, 4.6

パブリック, 4.6, 6.1.1.3

安全性, 4.6

SYSユーザー名, 2.1.4

データ・ディクショナリ表, 6.1.3

V$ビュー, 6.2.1

SYSDBA権限, 13.2.1.1 SYSOPER権限, 13.2.1.1 システム変更番号

定義, 9.1.1.3.1

割当て時, 11.4.3

システム変更番号(SCN), 10.1.4

トランザクションのコミット, 10.2.5

定義, 10.2.5

システム制御文, 7.2.5 システム・グローバル領域, 「SGA」を参照 システム・ロック, 9.4.3

内部, 9.4.3.3

ラッチ, 9.4.3.1

mutex, 9.4.3.2

システム・モニター・プロセス(SMON), 15.4.1.2

定義, 15.4.1.2

Real Application Clusters, 15.4.1.2

トランザクションのロールバック, 13.4.4

SYSTEM表領域, 6.1.2

格納されているデータ・ディクショナリ, 12.5.1.1

オンライン要件, 12.5.3.2

SYSTEMユーザー名, 2.1.4

T

表クラスタ

クラスタ・キー, 2.3

定義, 2.3

ハッシュ・クラスタ, 2.3.2

索引付き, 2.3.1, 用語集

スキャン, 7.3.3

表

実表, 4.2.1, 6.1.2

特徴, 2.2.2

クラスタ化, 2.3

圧縮, 2.2.9, 4.1.2

定義, 2.1.1

ディテール, 4.3

ディメンション, 4.5.1

ディレクトリ, 12.2.2.1, 12.2.2.1

DUAL, 6.1.1.4

動的パーティション化, 15.4.3.2.2

外部, 2.2.7

ファクト, 4.5.1

全表スキャン, 3.1

ヒープ構成, 2.1.2, 3.2

索引構成, 3.2, 3.2.3, 4.1.4

整合性制約, 5.1

結合, 3.1.3.2

キー保存, 4.2.2

マスター, 4.3, 4.3

正規化された表と正規化されていない表, 4.5.2

オブジェクト, 2.2.5

概要, 2

パーティション, 4.1.2

永続, 2.2

記憶域, 2.2.8

一時, 2.2.6, 12.4.2.2

トランザクション, 10.1.2.1

切捨て, 7.2.1

ビュー, 4.2

仮想, 6.2.2

表, 実, 4.2 表, 外部, 2.2 表, 一時, 2.2 表領域のポイント・イン・タイム・リカバリ, 18.3.1.3.4 表領域, 12.5

説明, 12.5

ディクショナリ管理, 12.1.2.2

ローカルに管理される, 12.1.2.1

ロック, 9.4.3.3

オフライン, 12.5.3.2

オンライン, 12.5.3.2

概要, 12.5

リカバリ, 18.3.1.3.4

スキーマ・オブジェクト, 2.1.2

領域割当て, 12.1.2

SYSTEM, 6.1.2

一時セグメントに使用, 12.4.2.1

タスク, 15.1 一時ファイル, 11.2.2 一時セグメント, 2.2.6.2, 12.4.2.2

割当て, 12.4.2.1

問合せ用の割当て, 12.4.2.1

一時表, 2.2, 2.2.6 スレッド

オンラインREDOログ, 11.4.2

タイム・ゾーン, 2.2.3.3.2

日付/時間列,, 2.2.3.3.2

TIMESTAMPデータ型, 2.2.3.3, 2.2.3.3.2 TO_CHAR関数, 2.2.3.5 TO_DATE関数, 2.2.3.3.1, 2.2.3.5 トレース・ファイル

LGWRトレース・ファイル, 15.4.1.4.2

トランザクション制御文, 7.2.3 トランザクション表, 10.1.2.1

リカバリ時にリセット, 15.4.1.1

トランザクション・レベルの読取り一貫性, 9.1.1.2 トランザクション, 10

ACIDプロパティ, 10.1

アクティブ, 10.2.2

システム変更番号の割当て, 10.2.5

自律型, 10.3

PL/SQLブロック内, 10.3

開始, 10.1.2.1 ブロック, 9.2.1.2 コミット, 10.2.5, 15.4.1.4.1

グループ・コミット, 15.4.1.4.1

書込みの競合, 9.2.1.2 デッドロック, 9.3.6 デッドロック, 10.1.3 定義, 10.1 分散, 10.2.1, 10.4

自動解決, 15.4.1.7

DML文, 7.2.2 終了, 10.1.2.2 エンキュー, 10.2.3.2 インダウト

自動解決, 10.4.2

Interested Transaction List(ITL), 9.1.1.3.2 分離レベル, 9.1.3, 9.2.2, 9.2.3 分離, 9.1.3 命名, 10.2.1 読取り一貫性, 9.1.1.2 ロールバック, 10.2.3.1, 10.2.4

部分的な, 10.2.3.1

セーブポイント, 10.2.3 シリアライズ可能性, 9.1 設定のプロパティ, 7.2.3 アプリケーションの終了, 10.1.2.2 トランザクション制御文, 7.2.3 トランザクション履歴, 9.1.1.3.2 トランザクションID, 10.1, 10.1.2.1 トリガー, 8.1

連鎖的, 8.4.1

コンポーネント, 8.4.4

複合, 8.4.3

ロールバックの効果, 10.1.3

起動(実行), 8.4.5

必要な権限, 8.4.5

INSTEAD OF, 8.4.2 概要, 8.4 制限, 8.4.4 行, 8.4.2 共有SQL領域, 14.4.3.1.2 単一, 8.4.3 文, 8.4.2 記憶域, 8.4.6 タイミング, 8.4.3 UNKNOWNでは起動されない, 8.4.4 使用方法, 8.4.1 TRUNCATE文, 7.2.1 2フェーズ・コミット

トランザクションの管理, 10.4

U

UNDO管理, 自動, 12.4.3

UNDOセグメント, 10.1.2.1

読取り一貫性, 9.1.1.3

UNDO表領域, 12.5.1.3

UNDO保存期間, 9.2.3

Unicode, 2.2.3.1 一意索引, 3.1.1.3 一意キー制約, 5.2, 5.2.2

コンポジット・キー, 5.2.2

NOT NULL制約, 5.2.2

計画外停止時間

停止時間の回避, 17.2.1.2

UPDATE NO ACTION制約, 5.2.4.3 UPDATE文, 7.2.2 更新

消失, 9.2.1.2

ビューの更新可能性, 4.2.2, 8.4.2

更新可能な結合ビュー, 4.2.2

表の更新

親キー, 9.4.1.3

UROWIDデータ型, 2.2.3.4 ユーザー・プログラム・インタフェース(UPI), 16.3.1 USER_ビュー, 6.1.1.3 ユーザー, データベース, 2.1.1

認証, 17.1.2

名前, 6.1

セッションと接続, 15.2.2

権限, 2.1 一時表領域, 12.4.2.1 UTL_HTTPパッケージ, 8.2.2

V

V$ビュー, 6.2.1

VARCHAR2データ型, 2.2.3.1

変数

埋込みSQL, 7.2.6

ビュー, 4.2

実表, 4.2

制約が間接的に影響する, 5.3.3.2

データ・アクセス, 4.2.1.2

データ・ディクショナリ

更新可能な列, 4.2.2

固定ビュー, 6.2.1 索引, 4.2.1.2 INSTEAD OFトリガー, 8.4.2 整合性制約, 4.2.1.1 マテリアライズド, 4.3 オブジェクト, 4.2.3 スキーマ・オブジェクトの依存性, 4.2.1 記憶域, 4.2.1 更新可能性, 4.2.2 用途, 4.2 V$, 6.2 仮想列, 2.2.1, 2.2.8.1, 3.1.4.2

W

ウェアハウス

マテリアライズド・ビュー, 4.3

Webサービス, 1.5.4.1, 16.1.2.4 事前書込み, 15.4.1.4

X

XA

ラージ・プール内のセッション・メモリー, 14.4.4

XMLTypeデータ型, 19.3.4.1

オラクル社の法律上の注意点について

コピーライトについて

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。