10gリリース2（10.2）
B19215-02
 目次 |
 索引 |
| Oracle Database 概要 10gリリース2（10.2） B19215-02 |
|
この章では、Oracleデータベース・サーバーの概要について説明します。この章の内容は、次のとおりです。
Oracleデータベースとは、1単位として扱われるデータの集合です。 データベースの目的は、関連する情報の格納や取出しです。データベース・サーバーは、情報管理の問題を解決する鍵となります。一般にサーバーでは、多数のユーザーが同時に同じデータへアクセスできるように、マルチユーザー環境において大量のデータが確実に管理されます。このような管理を行いながら、一方では高いパフォーマンスを実現し、権限のないアクセスに対して保護機能を備えながら、障害のリカバリについても効率のよい解決方法を提供します。
Oracle Databaseは、エンタープライズ・グリッド・コンピューティング用に設計された最初のデータベースで、最も柔軟性があり、コスト効率の高い方法で情報とアプリケーションを管理できます。エンタープライズ・グリッド・コンピューティングでは、業界標準のモジュール化した記憶域とサーバーのラージ・プールが作成されます。このアーキテクチャによって、各新規システムをコンポーネントのプールから迅速にプロビジョニングできます。容量は、必要に応じてリソース・プールから容易に追加または再割当てできるため、ワークロードのピークに備える必要はありません。
データベースには、論理構造と物理構造があります。 物理構造と論理構造は分離されているため、論理記憶構造へのアクセスに影響を与えずに、データの物理記憶域を管理できます。
この項の内容は、次のとおりです。
グリッド・コンピューティングは、よりリジリエンスがあり低コストの企業情報システムを生成する新しいITアーキテクチャです。 グリッド・コンピューティングを使用すると、ビジネスのニーズの変化に合わせて、独立したモジュール・ハードウェアおよびソフトウェア・コンポーネントのグループを必要に応じて接続および再結合できます。
グリッド形式のコンピューティングは、企業のITに共通する問題を解決することを目的としています。たとえば、専用のハードウェア・リソースが十分に活用されていないアプリケーション・サイロの問題、保守にコストがかかり変更が難しい不便な大規模システムの問題、全体として企業で十分に活用されていない断片化した情報の問題などがあります。
その他のコンピューティング・モデルと比較して、グリッド形式で設計および実装されたITシステムは、サービス品質の向上、コストの削減および柔軟性の向上を実現します。 優れたサービス品質は、シングル・ポイント障害がないこと、堅牢なセキュリティ・インフラストラクチャおよびポリシードリブンの集中管理に起因します。 低コストは、リソース使用率の向上と、管理および保守コストの大幅な削減によるものです。 ソフトウェアおよびハードウェアのスタックを特定のタスク専用にするのではなく、すべてのリソースをプールしておき必要に応じて割り当てることで、容量を活用して冗長な機能が発生しないようにします。 グリッド・コンピューティングにより、小規模な個別のハードウェア・コンポーネントも活用できるため、各コンポーネントのコストが削減され、変化するニーズに合わせてより柔軟にリソースが割り当てられます。
グリッド形式のコンピューティングでは、類似したITリソースの集合を全体として1つのプールとみなし、明確な性質を持つ個別のリソースをそのプール内で活用します。 大規模なシステムと断片化したリソースの問題に同時に対処するために、グリッド・コンピューティングでは、全体的なリソース管理と独立した柔軟なリソース管理の利点が両立しています。 グリッドで管理されるITリソースは、次のとおりです。
グリッド・コンピューティングと、メインフレーム、クライアント/サーバー、多層などのその他の形式のコンピューティングを区別する2つの中心的な理念は、仮想化とプロビジョニングです。
情報、アプリケーションまたはインフラストラクチャ・リソースを仮想化およびプロビジョニングする特定の方法は、リソースの種類に固有のものですが、概念は普遍的に適用されます。 同様に、グリッド・コンピューティングの特定の利点は、リソースの種類により異なりますが、品質の向上、コストの削減、柔軟性の向上などの特性はすべてのリソースに共通しています。
インフラストラクチャ・グリッド・リソースには、ストレージ、プロセッサ、メモリー、ネットワークなどのハードウェア・リソースと、データベース、ストレージ管理、システム管理、アプリケーション・サーバー、オペレーティング・システムなど、このハードウェアを管理するように設計されたソフトウェアの両方が含まれます。
インフラストラクチャ・リソースの仮想化とプロビジョニングとは、リソースをまとめてプールし、ポリシーに基づいて適切なコンシューマに割り当てることを意味します。 たとえば、あるポリシーでは、Webサーバーに十分な処理能力を割り当てることで、常に1秒以内の応答時間を実現できます。 そのルールは、全コンシューマの要求のバランスを取るためにソフトウェアをプロビジョニングすることで、様々な方法で実行されます。
インフラストラクチャ・リソースを1つのプールとみなし、そのリソースを必要に応じて割り当てることで、容量を活用して冗長な機能が発生しなくなるため、コストが削減されます。 ハードウェアおよびソフトウェア・リソースを全体として管理することで、作業コストと人為的エラーが発生する可能性が抑えられます。
多数の異なるコンピュータ間にコンピューティング能力を分散し、複数のディスクおよびディスク・グループ間にストレージ容量を分散することで、シングル・ポイント障害を排除し、個別のコンポーネントに障害が発生しても、システム全体を使用可能な状態に保ちます。 さらに、グリッド・コンピューティングは、ブレード・サーバーや低コストのストレージなど、小規模な個別のハードウェア・コンポーネントを使用できるオプションを提供することで、増分スケーリングを可能にし、個別のコンポーネントのコストを削減して、企業における柔軟性の向上と低コストを実現します。
インフラストラクチャは、最もよく知られているわかりやすいグリッド・コンピューティングの側面ですが、アプリケーションおよび情報にも同じ概念が適用されます。
グリッド内のアプリケーション・リソースは、ビジネス・ロジックのエンコーディングとアプリケーション・ソフトウェア内のプロセス・フローです。 これらのアプリケーション・リソースは、複雑性のレベルを反映して、任意のプログラミング言語で記述されたパッケージ・アプリケーションまたはカスタム・アプリケーションになります。 たとえば、顧客から注文を受けて通知を送信するソフトウェア、給与支払小切手を印刷するプロセス、特定の顧客からの問合せを特定のエージェントに割り当てるロジックはすべて、アプリケーション・リソースです。
これまで、アプリケーション・ロジックは、ユーザー・インタフェース・コード、データ管理コードおよびプロセスまたはページ・フローと関連し、明確なインタフェースがなかったため、結果的に変更や統合が困難な大規模アプリケーションになっていました。
アプリケーションを構築するための優れたモデルとして、サービス指向のアーキテクチャが出現し、サービス指向アーキテクチャの概念は、グリッド・コンピューティングの中心的な理念と一致しています。 アプリケーション・リソースの仮想化およびプロビジョニングには、複数のコンシューマ（ユーザーまたはプロセス）が使用するサービスとしてのアプリケーション・コンポーネントの公開が含まれており、それらのサービスがより強力なビジネス・フローに統合されます。
グリッド・コンピューティングによりITインフラストラクチャ・リソースの有効な再利用と柔軟性の向上が実現されるのと同じ方法で、グリッド・コンピューティングでは、アプリケーション・ロジックの断片を1つのリソースとみなし、新しい複合アプリケーションを変更および構築する際に、アプリケーション機能をより有効に再利用して、柔軟性を高めます。
さらに、公開されたサービスから統合されたアプリケーションでは、企業内の各アクティビティを1つにまとめて表示できるため、各地域および営業単位間でプロセスが標準化され、プロセスがエンドツーエンドで自動化されます。 これによりビジネス・プロセスの信頼性が向上し、自動化の増加と変動性の削減によりコストが削減されます。
インフラストラクチャおよびアプリケーションに続く、グリッド・コンピューティングの3番目の側面は情報です。 現在、情報は社内で断片化される傾向があり、ビジネス全体を把握したり、顧客に関する基本的な質問に回答するのが困難になっています。 顧客の詳細や購入対象に関する情報がない場合、情報資産は活用されません。
対照的に、グリッド・コンピューティングでは、インフラストラクチャおよびアプリケーション・リソースと同様に、情報をまとめて1つのリソースとして扱うため、より多くの潜在的な価値が引き出されます。 情報グリッド・リソースには、企業内のすべてのデータと、そのデータを有意義なものにするために必要なすべてのメタデータが含まれます。 このデータは、構造化された状態、半構造化された状態または構造化されていない状態で、データベース、ローカル・ファイル・システム、電子メール・サーバーなどの任意の場所に格納され、任意のアプリケーションによって作成されます。
グリッド・コンピューティングの中核となる理念は、インフラストラクチャおよびアプリケーションの場合と同様に、情報にも適用されます。 インフラストラクチャ・グリッドは、ネットワークの機能を利用して、複数のサーバーまたはストレージ・デバイスを1つのタスクに結合し、ニーズの変化に合わせて簡単に再構成できるようにします。 サービス指向アーキテクチャ、つまりアプリケーション・グリッドを使用すると、独自に開発されたサービス、つまりアプリケーション・リソースを大規模なビジネス・プロセスに組み込むことで、複合アプリケーションのその他の部分を分割しなくても、ニーズの変化に合わせることができます。 同様に、情報グリッドは、情報リソースを関連する情報リソースと結合することで、情報間で本質的な関係の価値を活用し、状況の変化に合わせて新しい関係を確立できます。
たとえば、リレーショナル・データベースは、初期の情報仮想化テクノロジでした。 従来のデータベースと異なり、ネットワーク・データベースおよび階層データベース・モデルでは、データ間のすべての関係が事前に定義されている必要があったため、リレーショナル・データベースは、汎用的な情報リソースに柔軟にアクセスできました。 現在、情報とメタデータを表す標準的な方法を提供することで、XMLにより情報の仮想化が促進されており、その情報の作成および表示に使用される情報と特定のアプリケーション間の強力な関係が断絶されています。
情報プロビジョニング・テクノロジには、メッセージ・キューイング、データの伝播、レプリケーション、抽出-変換-ロード、データの品質を保証するためのマッピングおよびクレンジング・ツールが含まれます。 データ・ハブは、中央のオペレーショナル・データ・ストアを稼働中の複数のデータ・ソースと継続的に同期し、実際の1つのソースを確立するための推奨モデルとして出現する一方で、分散制御の柔軟性も維持しています。
グリッド・コンピューティングを使用して、他のリソースの処理方法に関係なく、1つのITリソース（インフラストラクチャ、アプリケーションまたは情報）を管理することで、企業は品質の向上、柔軟性の向上およびコストの削減を実現できます。 たとえば、インフラストラクチャ・グリッドを利用するためにアプリケーションを書き換える必要はありません。 情報を管理する方法、またはハードウェアを構成する方法を変更しなくても、アプリケーション・グリッド、つまりサービス指向アーキテクチャを配置することもできます。
また一方では、すべてのリソースにグリッド・コンピューティングを使用することで、より大きな成果を挙げることもできます。 たとえば、個別のサービス・レベルでリソース要件に関するポリシーを設定し、インフラストラクチャごとに処理が異なる同じ複合アプリケーションで異なるサービスを実行すると、アプリケーション・グリッドの機能が向上します。これは、アプリケーション・グリッドとインフラストラクチャ・グリッドを組み合せて使用する場合のみ可能です。 また、より多くの情報を実際の1つのソースに統合して情報グリッドを構築するのは、インフラストラクチャがグリッドとして構成されている場合のみ可能になるため、1つのコンピュータの境界を越えて拡張できます。
グリッド・コンピューティングに対するこの壮大なビジョンの実現を目指して、企業はより柔軟で生産的なITアーキテクチャに徐々に移行するための実際のソリューションを必要としています。 ソフトウェア製品のOracle Database 10gファミリは、企業を開始する中核となるグリッド・テクノロジの大部分を実装しています。 オラクル社では、全体的な企業アーキテクチャとの関連でこのグリッド・コンピューティング機能を提供し、堅牢なセキュリティ・インフラストラクチャ、集中管理、直感的で強力な開発ツールおよび汎用的なアクセスを実現します。 Oracle Database 10gには次のものが含まれます。
Oracle 10gのグリッド機能は、前述のすべての製品に含まれていますが、ここではOracle Database 10gのグリッド・コンピューティング機能を重点的に説明します。
Oracle Enterprise Manager 10gのグリッド・コントロール機能は、複数のシステムをまとめて1つの論理グループとして管理するための1つのコンソールを提供します。 グリッド・コントロールでは、ソフトウェアの適切なフルスタックを使用してグリッド内のノードのプロビジョニングが管理され、システムのグループごとに構成とセキュリティ設定を一元的に保守できます。
グリッド管理のもう1つの側面は、非常にセキュアで保守が容易な方法で、ユーザーの識別を管理することです。 Oracle Identity Management 10gには、委任管理によるLDAP準拠のディレクトリが含まれており、リリース2では、統合識別管理も追加されたため、1つのサインオン機能をセキュリティ・ドメイン間で安全に共有できます。 Oracle Identity Management 10gは、ユーザーを認証するためにアプリケーションの中心点（シングル・サインオン・サーバー）を利用してグリッドの原理に厳密に従う一方で、水面下では、委任と統合により識別の制御を分散することで、システムの保守性と全体の動作を最適化します。
標準的なWebサービスのサポート: Oracle Application Server 10gにおける堅牢なWebサービスのサポート以外に、Oracle Database 10gはWebサービスを公開して使用できます。 DMLおよびDDL操作をWebサービスとして公開し、データベース内の機能によりWebサービスをSQL行ソースとして表示することで、強力なSQLツールを使用して、リレーショナルおよび非リレーショナル・データとともにWebサービス・データを分析できます。
Oracle Enterprise Manager 10gでは、Webサービスや管理者が定義したその他のサービスを監視および管理し、エンドツーエンドのパフォーマンスを追跡して、発生した問題の根本的原因を分析することで、Oracleによるサービス指向アーキテクチャのサポートを強化します。
ファイングレイン・データ共有を実現するために、Oracle Database 10gのOracle Streams機能は、データベース・トランザクションの変更を取得して伝播することで、更新の適用時に複数のデータベース・コピーを同期化して保存できます。 また、メッセージ・キューイング、レプリケーション、イベント、データ・ウェアハウスのロード、通知および公開/サブスクライブなど、従来の個別のデータ共有メカニズムが単一のテクノロジに結合されます。
Oracleの企業データ・ハブ製品シリーズ（Oracle Customer Data Hubなど）では、運用情報ソースをリアルタイムで同期して、企業が1つのソースを所有できるようにする一方で、パッケージ化された従来のカスタム・アプリケーションの組合せを含む個別のシステムとアプリケーションを保持します。 データのクレンジングおよびスケジューリングのメカニズム以外に、Oracleでは、長年にわたるエンタープライズ・アプリケーションの構築経験から作成された適格なスキーマを、顧客情報、財務情報、製品情報などの一般的なタイプの情報に提供しています。
通常、データベースのアーキテクチャには、クライアント/サーバーと複数層の2種類があります。コンピューティング環境でインターネット・コンピューティングが普及するにつれて、多数のデータベース管理システムが複数層環境に移行しつつあります。
マルチプロセッシングでは、一連の関連ジョブに複数のプロセッサが使用されます。分散処理では、異なるプロセッサが関連するタスクのサブセットを集中処理することにより、1つのプロセッサの負荷が低減され、システム全体のパフォーマンスと能力が向上します。
Oracleデータベース・システムでは、クライアント/サーバー・アーキテクチャを使用することにより、分散処理を容易に活用できます。このアーキテクチャでは、データベース・システムは2つの部分に分割されます。フロントエンドのクライアントとバックエンドのサーバーです。
クライアントは、データベース・サーバー上で実行される操作について要求を出すデータベース・アプリケーションです。サーバーが管理するデータの要求、処理および提示を行います。クライアント・ワークステーションは、このようなジョブにあわせて最適化できます。たとえば、必要なディスク容量の縮小や、グラフィック機能を活用できます。
通常、クライアントは、PCなど、データベース・サーバーとは異なるコンピュータ上で実行されます。多数のクライアントを1つのサーバーに対して同時に実行できます。
サーバーは、Oracleソフトウェアを実行し、同時実行の共有データ・アクセスに必要な機能を処理します。 サーバーは、クライアント・アプリケーションから発行されたSQL文やPL/SQL文を受け取って処理します。サーバーを管理するコンピュータは、このような処理内容に応じて最適化できます。たとえば、大容量のディスクや高速プロセッサを搭載できます。
複数層アーキテクチャの構成要素は、次のとおりです。
このアーキテクチャでは、アプリケーション・サーバーを使用して次のことを実行できます。
プロキシ認証が使用されている場合、クライアントの識別は、接続のすべての層で保持されます。
次の項では、データファイル、REDOログ・ファイルおよび制御ファイルなど、Oracleデータベースの物理構造について説明します。
すべてのOracleデータベースには、1つ以上の物理データファイルがあります。データファイルには、すべてのデータベース・データが格納されます。表や索引などの論理データベース構造のデータは、データベースに割り当てられたデータファイルに物理的に格納されます。
データファイルの特性は次のとおりです。
通常のデータベース操作中、データファイル内のデータが必要に応じて読み込まれ、Oracleのメモリー・キャッシュに格納されます。たとえば、あるユーザーがデータベースの表に入っている一部のデータにアクセスする場合を考えます。要求された情報がデータベースのメモリー・キャッシュに存在しない場合には、その情報は適切なデータファイルから読み込まれて、メモリーに格納されます。
修正されたデータや新規のデータは、必ずしも即時にデータファイルに書き込まれるわけではありません。ディスクへのアクセス回数を減らし、パフォーマンスを向上させるために、データはメモリー内に蓄積されてから、適切なデータファイルに一度に書き込まれます。これらの操作は、バックグラウンド・プロセスであるデータベース・ライター・プロセス（DBWn）によって決定されます。
すべてのOracleデータベースには、制御ファイルがあります。この制御ファイルには、データベースの物理構造を指定するエントリが含まれています。たとえば、制御ファイルには次のような情報が含まれます。
Oracleでは、制御ファイルを多重化できます。つまり、制御ファイルに関連する障害から保護するために、同じ制御ファイルの多数のコピーが同時に維持されます。
Oracleデータベースのインスタンスが起動するたびに、データベース操作のためにオープンする必要のあるデータベース・ファイルとREDOログ・ファイルが、制御ファイルによって識別されます。データベースの物理的な構造が変更されると（データファイルやREDOログ・ファイルの新規作成など）、制御ファイルは、その変更を反映するようにOracleによって自動的に修正されます。制御ファイルは、データベースのリカバリにも使用されます。
すべてのOracleデータベースには、2つ以上のREDOログ・ファイルの集合があります。REDOログ・ファイルの集合は、データベースのREDOログと呼ばれます。REDOログは、REDOエントリ（REDOレコードとも呼ばれます）で構成されます。
REDOログの主要機能は、データに加えられた変更をすべて記録することです。万一障害が発生して、修正済のデータがデータファイルに書き込まれなかった場合でも、その変更はREDOログから取得できるため、実行した作業が失われることはありません。
REDOログ自体にかかわる障害から保護するため、Oracleでは2つ以上のREDOログのコピーを異なるディスク上に維持できるように、多重REDOログを使用できます。
REDOログ・ファイル内の情報は、データベース・データをデータファイルに書き込む妨げとなるシステム障害やメディア障害が起きた場合に、データベースをリカバリするためにのみ使用されます。たとえば、予期しない停電によってデータベース操作が停止した場合、メモリー内のデータはデータファイルに書き込まれずに失われます。ただし、電源が復旧した後、データベースがオープンされると、失われたデータがすべてリカバリされます。Oracleは、最新のREDOログ・ファイル内にある情報をデータベースのデータファイルに反映させることにより、停電が起きた時点までデータベースをリストアします。
リカバリ操作中にREDOログ・ファイルの情報を反映させる処理のことを、ロールフォワードと呼びます。
REDOログの自動アーカイブを使用可能にできます。データベースがARCHIVELOGモードの場合は、ログ・ファイルが自動的にアーカイブされます。
パラメータ・ファイルには、特定のインスタンスおよびデータベースの構成パラメータのリストが格納されます。
初期化パラメータを動的に維持する手段として、サーバー・パラメータ・ファイル（SPFILE）を作成することをお薦めします。サーバー・パラメータ・ファイルを使用すると、初期化パラメータをサーバー側ディスク・ファイルに永続的に格納して管理できます。
それぞれのサーバーとバックグラウンド・プロセスは、対応付けられたトレース・ファイルに書き込むことができます。プロセスによって内部エラーが検出されると、エラーについての情報がそのプロセスのトレース・ファイルに書き込まれます。トレース・ファイルに書き込まれる情報には、データベース管理者向けのものとオラクル社カスタマ・サポート・センター向けのものがあります。また、トレース・ファイル情報は、アプリケーションとインスタンスのチューニングにも使用されます。
アラート・ファイルは、アラート・ログとも呼ばれる特殊なトレース・ファイルです。データベースのアラート・ログは、メッセージとエラーの履歴ログです。
ファイルをリストアするには、バックアップ・ファイルで置き換えます。通常、ファイルをリストアするのは、メディア障害やユーザー・エラーによりオリジナルのファイルが破損したり削除された場合です。
ユーザー管理バックアップおよびリカバリでは、バックアップの試行リカバリを実行する前に、実際にバックアップ・ファイルをリストアする必要があります。
サーバー管理バックアップおよびリカバリでは、リカバリが必要な時点で適切なバックアップ・ファイルを適用するなどのリカバリ処理のみでなく、バックアップのスケジューリングなどのバックアップ処理も管理されます。
Oracleでは、データ・ブロック、エクステントおよびセグメントなどの論理記憶構造によって、ディスク領域の使用をきめ細かく制御できます。
データベースは、関連する論理構造がグループ化された表領域と呼ばれる論理記憶単位に分けられます。たとえば、通常、表領域はすべてのアプリケーション・オブジェクトをグループ化し、管理操作を容易にします。
各データベースは、論理的に1つ以上の表領域に分けられます。各表領域に対して1つ以上のデータファイルが明示的に作成され、すべての論理構造のデータが表領域に物理的に格納されます。表領域内のデータファイルのサイズを組み合せると、表領域全体の記憶容量になります。
すべてのOracleデータベースには、SYSTEM表領域とSYSAUX表領域が含まれています。この2つの表領域は、データベースの作成時に自動的に作成されます。システム・デフォルトでは、従来型のOracle表領域である小型ファイル表領域が作成されます。SYSTEMおよびSYSAUX表領域は、小型ファイル表領域として作成されます。
また、Oracleでは大型ファイル表領域を作成できます。これによって、Oracle Databaseでは、多数の小型ファイルではなく単一の大型ファイルで構成されている表領域を格納できます。これにより、Oracle Databaseでは、64ビット・システムの機能を利用して超大規模ファイルを作成および管理できます。この結果、Oracle Databaseは8TBまでサイズを拡張できるようになりました。Oracle Managed Filesでは、大型ファイル表領域によりデータファイルがユーザーに対して完全に透過的になります。つまり、基礎となるデータファイルではなく表領域に対する操作を実行できます。
表領域は、オンライン（アクセス可能）またはオフライン（アクセス不能）に設定できます。ユーザーが表領域内の情報にアクセスできるように、通常、表領域はオンラインになっています。ただし、場合によっては、1つの表領域をオフラインにしてデータベースの一部を使用できないようにすると同時に、データベースの残りの部分には通常どおりアクセスできるようにすることもできます。これによって、多くの管理業務を容易に実行できます。
最少レベルとして、Oracleデータベースのデータはデータ・ブロックに格納されます。 1つのデータ・ブロックは、ディスク上の特定のバイト数の物理データベース領域に対応します。標準のブロック・サイズは、DB_BLOCK_SIZE初期化パラメータで指定します。また、他のブロック・サイズを5つまで指定できます。データベースは、Oracleデータ・ブロック内の空きデータベース領域を使用して領域を割り当てます。
次の論理データベース領域のレベルは、エクステントと呼ばれます。1回の割当てで取得される特定数の連続したデータ・ブロックで、特定のタイプの情報を格納するために使用されます。
エクステントの上位に位置する論理データベース記憶域のレベルは、セグメントです。セグメントは、特定の論理構造に割り当てられるエクステントの集合です。次の表に、各種のセグメントを示します。
| セグメント | 説明 |
|---|---|
|
データ・セグメント |
クラスタ化されていない表には、それぞれ1つのデータ・セグメントがあります。表のデータはすべて、データ・セグメントのエクステントに格納されます。 パーティション表の場合は、各パーティションに1つずつデータ・セグメントがあります。 各クラスタには、1つのデータ・セグメントがあります。 クラスタ内のあらゆる表のデータが、そのクラスタのデータ・セグメントに格納されます。 |
|
索引セグメント |
各索引には、そのデータをすべて格納する索引セグメントが1つあります。 パーティション索引の場合は、各パーティションに1つずつ索引セグメントがあります。 |
|
一時セグメント |
一時セグメントは、SQL文の実行を完了するために一時的なデータベース領域が必要なときに、Oracleによって作成されます。SQL文の実行が終了すると、一時セグメントのエクステントは後で使用できるようにシステムに戻されます。 |
|
ロールバック・セグメント |
自動UNDO管理モードで操作している場合、データベース・サーバーは表領域を使用してUNDO領域を管理します。自動UNDO管理の使用をお薦めします。 以前のリリースのOracleでは、ロールバック・セグメントを使用してUNDO情報を格納していました。ロールバック・セグメント内の情報は、データベース・リカバリ中に読取り一貫性を備えたデータベース情報を生成する場合と、コミットされていないトランザクションをユーザーがロールバックする場合に使用されていました。 これらのロールバック・セグメントの領域管理は複雑であり、この方法は廃止になりました。このマニュアルでは、UNDOを管理するためのUNDO表領域方式について説明します。この方法により、ロールバック・セグメント領域の管理が簡素化され、UNDOが上書きされるまで保持される期間を正確に制御できます。
Oracleでは、システム・トランザクションの実行に |
Oracleは、1つのセグメントの既存のエクステントがいっぱいになった時点で、領域を動的に割り当てます。つまり、あるセグメントのエクステントがいっぱいになると、そのセグメントには別のエクステントが割り当てられます。エクステントは必要に応じて割り当てられるため、1つのセグメントの各エクステントはディスク上で連続している場合と連続していない場合があります。
スキーマとは、データベース・オブジェクトの集合です。スキーマはデータベース・ユーザーによって所有され、そのユーザーと同じ名前を持ちます。スキーマ・オブジェクトは、データベースのデータを直接参照する論理構造です。スキーマ・オブジェクトには、表、ビューおよび索引などの構造が含まれます。（表領域とスキーマとの間に関連付けはありません。同じスキーマのオブジェクトを異なる表領域に含めることができます。また、ある表領域に異なるスキーマのオブジェクトを含めることができます。）
ここでは、最も一般的なスキーマ・オブジェクトの定義について説明します。
表は、Oracleデータベースにおけるデータ記憶域の基本単位です。データベースの表には、ユーザーがアクセスできるすべてのデータが保持されています。それぞれの表には列と行があります。たとえば、従業員データベースの表には、従業員番号という列があり、その列の各行には従業員番号が格納されます。
索引とは、表に対応付けられているオプションの構造です。索引を作成すると、データ検索のパフォーマンスが向上します。このマニュアルでも、索引を使用すると特定の情報をすばやく見つけることができます。それと同じように、Oracleの索引を使用すると表データにアクセスできます。
1つの要求を処理するとき、Oracleは、要求された行を効率よく見つけるために使用可能な索引をいくつか（またはすべて）使用します。索引が有効なのは、アプリケーションが表内のある範囲の行（給与が1000ドルを超えるすべての従業員など）または特定の行を頻繁に問い合せる場合です。
索引は、表の1つ以上の列に対して作成されます。作成された索引は、Oracleにより自動的に維持され、使用されます。表データに対する変更（新しい行の追加、行の更新または削除など）は、関連するすべての索引にも自動的に取り込まれます。その操作は、ユーザーに対して透過的です。
ビューとは、1つ以上の表または他のビューに含まれているデータの表現がカスタマイズされたものです。ビューは、ストアド・クエリーとみなすこともできます。ビューに実際のデータは格納されていません。データはビューの基礎となる表からデータを導出します。これらの表を、ビューの実表と言います。
表の場合と同じように、ビューに対しても、いくつかの制限付きで、問合せ、更新、挿入および削除を実行できます。ビューに対して実行する操作は、すべてビューの実表にも影響します。
ビューは事前に定義された行と列の集合のみにアクセスを限定して、表のセキュリティ・レベルを強化します。また、データの複雑さを隠し、複雑な問合せを格納します。
クラスタとは、物理的にまとめて格納される1つ以上の表のグループです。それらの表は共通の列を共有しており、しばしば一緒に使用されるため、まとめて格納されます。 関連する行が物理的にまとめて格納されているため、ディスク・アクセス時間が短縮されます。
索引と同じように、クラスタがアプリケーションの設計に影響することはありません。表がクラスタの一部になっているかどうかは、ユーザーおよびアプリケーションに対して透過的です。クラスタ化表に格納されているデータは、クラスタ化されていない表のデータと同じようにSQLを使用してアクセスします。
シノニムとは、表、ビュー、マテリアライズド・ビュー、順序、プロシージャ、ファンクション、パッケージ、型、Javaクラスのスキーマ・オブジェクト、ユーザー定義オブジェクト型または他のシノニムの別名です。シノニムは単なる別名であるため、データ・ディクショナリ内の定義以外に記憶域は必要ありません。
各Oracleデータベースには、データ・ディクショナリが1つずつあります。Oracleデータ・ディクショナリは、データベースの読取り専用の参照として使用される、表およびビューの集合です。たとえば、データ・ディクショナリには、データベースの論理構造と物理構造の両方に関する情報が格納されます。また、データ・ディクショナリには次の情報も格納されます。
データ・ディクショナリは、データベースの作成時に作成されます。常にデータベースの正確な状態が反映されるように、データ・ディクショナリは、データベース構造の変更など、特定の処理が行われるたびに、Oracleにより自動的に更新されます。データベースでは、データ・ディクショナリを基盤として、進行する作業の記録、検証および指示が実行されます。たとえば、データベースの操作中、Oracleは、スキーマ・オブジェクトが存在しているかどうか、およびユーザーが適切なアクセス権を持っているかどうかを検証するためにデータ・ディクショナリを読み込みます。
Oracleデータベース・サーバーは、OracleデータベースとOracleインスタンスで構成されます。データベースを起動するたびに、システム・グローバル領域（SGA）が割り当てられ、Oracleバックグラウンド・プロセスが起動されます。バックグラウンド・プロセスとメモリー・バッファを組み合せて、Oracleインスタンスと呼びます。
ハードウェア・アーキテクチャ（共有ディスク・システムなど）によっては、複数のコンピュータで、データ、ソフトウェアまたは周辺装置へのアクセスを共有できます。Real Application Clusters（RAC）を使用すると、1つの物理データベースを共有する複数のインスタンスを実行できるため、このようなアーキテクチャの利点を活用できます。ほとんどのアプリケーションでは、RACによって、複数のコンピュータ上のユーザーが、優れたパフォーマンスで1つのデータベースにアクセスできます。
Oracleデータベース・サーバーは、メモリー構造とプロセスを使用してデータベースの管理やアクセスを行います。すべてのメモリー構造は、データベース・システムを構成するコンピュータのメイン・メモリー内に存在します。プロセスとは、これらのコンピュータのメモリー内で実行されるジョブです。
Oracleはメモリー構造を作成して使用し、いくつかのジョブを完了させます。たとえば、実行中のプログラム・コードやユーザー間で共有されるデータを格納するときに、メモリーが使用されます。2つの基本的なメモリー構造がOracleに関連付けられます。一方はシステム・グローバル領域で、他方はプログラム・グローバル領域です。この後、それぞれのメモリー領域について詳しく説明します。
システム・グローバル領域（SGA）は、1つのOracleインスタンスに関するデータと制御情報を含む共有メモリー領域です。SGAはインスタンスの起動時に割り当てられ、そのインスタンスの停止時に割当てが解除されます。各インスタンスには、それぞれ専用のSGAがあります。
SGA内のデータは、Oracleデータベースに現在接続しているユーザー間で共有されます。最適なパフォーマンスを得るには、SGA全体をできるだけ（ただし、実メモリーの範囲内で）大きくして、メモリーにできるだけ多くのデータを格納し、ディスクI/Oを最小限にとどめるようにします。
SGAに格納される情報は、データベース・バッファ、REDOログ・バッファおよび共有プールなど、いくつかのタイプのメモリー構造に分けられます。
データベース・バッファには、直前に使用されたデータのブロックが格納されます。1つのインスタンス内のデータベース・バッファの集合が、データベース・バッファ・キャッシュです。このバッファ・キャッシュには、修正済のブロックおよび未修正のブロックが含まれています。最後に使用されたデータ（多くの場合、最も使用頻度の高いデータ）をメモリー内に保持することにより、必要なディスクI/Oが少なくなり、パフォーマンスが向上します。
REDOログ・バッファは、REDOエントリを格納します。REDOエントリは、データベースに対して加えられた変更のログです。REDOログ・バッファ内に格納されたREDOエントリは、オンラインREDOログに書き込まれ、データベースのリカバリが必要になったときに使用されます。REDOログのサイズは固定です。
共有プールには、共有SQL領域などの共有メモリー構成メンバーが格納されています。 データベースに送られる個々の一意のSQL文を処理するために、共有SQL領域が必要になります。共有SQL領域には、解析ツリーや、対応する文の実行計画などの情報が格納されます。同じ文を発行する複数のアプリケーションが1つの共有SQL領域を共用するため、他に使用可能な共有メモリーがより多く残ります。
カーソルとは、解析済の文とその文の処理に使用するその他の情報が格納されるプライベートSQL領域のハンドルまたは名前のことです。（Oracle Call Interface（OCI）では、これらを文ハンドルと呼びます）。ほとんどのOracleユーザーはOracleユーティリティの自動カーソル処理を使用しますが、アプリケーションの設計者はプログラム・インタフェースによってカーソルを自由に制御できます。
たとえば、プリコンパイラのアプリケーション開発では、カーソルはプログラムで使用可能な名前付きのリソースであり、特にアプリケーション内に埋め込まれたSQL文の解析に使用できます。アプリケーション開発者は、アプリケーションをコーディングできるので、SQL文の実行フェーズを制御してそのパフォーマンスを改善できます。
プログラム・グローバル領域（PGA）とは、1つのサーバー・プロセスに関するデータと制御情報を含むメモリー・バッファです。 PGAはサーバー・プロセスの起動時に、Oracleによって作成されます。 PGA内の情報はOracleの構成によって異なります。
Oracleデータベースは、メモリー構造とプロセスを使用してデータベースの管理やアクセスを行います。すべてのメモリー構造は、データベース・システムを構成するコンピュータのメイン・メモリー内に存在します。プロセスとは、これらのコンピュータのメモリー内で実行されるジョブです。
この項で説明するアーキテクチャの機能によって、Oracleデータベースでは次の処理をサポートします。
Oracleは、インスタンスごとに1組のバックグラウンド・プロセスを作成します。バックグラウンド・プロセスは、各ユーザー・プロセスごとに実行されている複数のOracleプログラムが処理する機能を1つにまとめます。また、I/Oを非同期的に実行し、他のOracleプロセスを監視することにより、並列性を強化してパフォーマンスおよび信頼性を向上させます。
多数のバックグラウンド・プロセスがあり、Oracleインスタンスはそれぞれ複数のバックグラウンド・プロセスを使用します。
プロセスは制御のスレッド、つまり一連の処理を実行できるオペレーティング・システムのメカニズムです。オペレーティング・システムによっては、ジョブまたはタスクという用語を使用します。通常プロセスには、それぞれが実行する独自のプライベート・メモリー領域があります。
Oracleデータベース・サーバーには、通常2つのプロセスがあります。ユーザー・プロセスとOracleプロセスです。
ユーザー・プロセスを作成してメンテナンスを実行すると、OCIまたはOCCIプログラムなどのアプリケーション・プログラムや、Enterprise ManagerなどのOracleのツール製品のソフトウェア・コードを実行できます。後述のように、ユーザー・プロセスは、プログラム・インタフェースを介してサーバー・プロセスとの通信を管理します。
Oracleプロセスは、他のプロセスによって起動され、起動したプロセスにかわって処理を行います。
Oracleは、接続されたユーザー・プロセスの要求を処理するために、サーバー・プロセスを作成します。サーバー・プロセスは、関連付けられたユーザー・プロセスの要求を実行するために、ユーザー・プロセスと通信し、Oracleと対話します。たとえば、ユーザーがSGAのデータベース・バッファに存在しないデータを問い合せた場合、関連付けられたサーバー・プロセスが、データファイルからSGAに適切なデータ・ブロックを読み込みます。
Oracleでは、サーバー・プロセス当たりのユーザー・プロセス数が変動できるように構成できます。専用サーバー構成では、1つのサーバー・プロセスが1つのユーザー・プロセスの要求を処理します。共有サーバー構成では、多数のユーザー・プロセスが少数のサーバー・プロセスを共有できます。これにより、サーバー・プロセスの数を最低限に抑え、使用可能なシステム・リソースの使用効率を最大化できます。
ユーザー・プロセスとサーバー・プロセスが別個のプロセスになっているシステムと、1つのプロセスにまとめられているシステムがあります。システムが共有サーバーを使用している場合、またはユーザー・プロセスとサーバー・プロセスが別々のコンピュータ上で実行されている場合、ユーザー・プロセスとサーバー・プロセスは別のプロセスである必要があります。クライアント/サーバー・システムでは、ユーザー・プロセスとサーバー・プロセスが分離され、それぞれ別々のコンピュータで実行されます。
この項では、データベースの起動方法とOracle Net Servicesについて説明します。
Oracle Net Servicesは、ネットワークで使用される通信プロトコルとのインタフェースとなるOracleのメカニズムであり、分散処理と分散データベースの実現を支援します。
通信プロトコルにより、ネットワーク上でのデータの送受信方法が定義されます。Oracle Net Servicesは、TCP/IP、HTTP、FTPおよびWebDAVなど、主要なネットワーク・プロトコルによる通信をすべてサポートしています。
Oracle Net Servicesを使用すると、アプリケーション開発者がデータベース・アプリケーションでネットワーク通信のサポートにかかわる必要はありません。新しいプロトコルを使用する場合も、データベース管理者がわずかな変更を行うだけです。アプリケーションは修正しなくても機能し続けます。
Oracle NetはOracle Net Servicesのコンポーネントであり、クライアント・アプリケーションからOracleデータベース・サーバーへのネットワーク・セッションが使用可能です。ネットワーク・セッションの確立後は、Oracle Netはクライアント・アプリケーションとデータベース・サーバーのためのデータ伝達手段として機能します。また、クライアント・アプリケーションとデータベース・サーバー間の接続を確立して維持し、これらの間でメッセージを交換します。Oracle Netは、ネットワーク内の各コンピュータに配置されているのでこれらのジョブを実行できます。
Oracleデータベースを起動して、システム全体で使用可能にするには、次の3つの操作を行います。
データベース管理者は、SQL*PlusのSTARTUP文やEnterprise Managerを使用してこれらの手順を実行できます。Oracleは、インスタンスを起動するときに、サーバー・パラメータ・ファイル（SPFILE）または初期化パラメータ・ファイルを読み取って、初期化パラメータの値を判別します。次に、SGAを割り当ててバックグラウンド・プロセスを作成します。
次の例は、Oracleが実行する操作の最も基本的なレベルです。ここでは、ユーザー・プロセスとそれに対応するサーバー・プロセスが別々のコンピュータ（ネットワークを介して接続）上に存在するOracleの構成について、具体的に説明します。
Oracleには、Data Pump Export/Import、SQL*LoaderおよびLogMinerなど、データ転送、データ維持およびデータベース管理用の複数のユーティリティが用意されています。
この項の内容は、次のとおりです。
Oracleには、情報管理システムが持つ次の重要な要件を満たすために、複数のソフトウェア・メカニズムが組み込まれています。
この項の内容は、次のとおりです。
マルチユーザー・データベース管理システムの最大の関心は、同時実行性をどのように制御するか、つまり多数のユーザーによる同一データへの同時アクセスをどのように制御するかということです。十分な同時実行性制御機能がなければ、データが不当に更新または変更され、データ整合性が損なわれる可能性があります。
データの同時実行性を管理する1つの方法は、各ユーザーに順番待ちをさせることです。データベース管理システムの目標は、その待ち時間を、各ユーザーにとって存在しないか、または無視できる程度まで短縮することです。すべてのDML文をできるだけ干渉がなくなるように処理し、同時実行のトランザクション間の破壊的な相互作用を防止する必要があります。破壊的な相互作用とは、不正確なデータの更新または基礎となるデータ構造の不正な変更を引き起こす相互作用です。パフォーマンスとデータ整合性は、どちらも無視できません。
Oracleでは、様々なタイプのロックとマルチバージョン一貫性モデルを使用することで、このような問題を解決します。これらの機能は、トランザクションの概念に基づいています。同時実行性と一貫性に関するこれらの機能がトランザクションで十分に活用されるようにするのは、アプリケーション設計者の責任です。
Oracleがサポートする読取り一貫性は、次のようなことを保証します。
Oracleの読取り一貫性の実現について考える最も簡単な方法は、ユーザーがそれぞれ自分専用のデータベースのコピーを操作している状況を想定することです（つまりマルチバージョンの一貫性モデル）。
マルチバージョンの一貫性モデルを管理するために、表に対する問合せ（読取り）や同時更新（書込み）の実行時にOracleは読取り一貫性を備えたデータの集合を作成する必要があります。更新が発生すると、それによって変更されたデータの元の値が、データベースのUNDOレコードに記録されます。この更新がコミットされていないトランザクションの一部であるかぎり、変更されたデータに後から問い合せたユーザーは、データの元の値を参照することになります。つまり、Oracleはシステム・グローバル領域内の現在の情報とUNDOレコードにある情報を使用して、問合せのために表データの読取り一貫性を備えたビューを作成します。
トランザクションがコミットされた時点で初めて、トランザクションの変更が確定します。ユーザーのトランザクションがコミットされた後に開始された文のみが、そのコミットされたトランザクションによって加えられた変更を参照することになります。
トランザクションは、読取り一貫性を実現するためのOracleの重要な機能です。コミット済の（またはコミットされていない）SQL文から構成されているトランザクションは、次のように機能します。
デフォルトでは、文レベルの読取り一貫性が保証されます。1つの問合せによって戻された一連のデータは、ある特定の時点での一貫性を保っています。ただし、場合によっては、トランザクション・レベルの読取り一貫性が必要になることもあります。これは、1つのトランザクション内で複数の問合せを実行するときに、そのトランザクション内の問合せが、途中でコミットされた他のトランザクションの結果を参照しないように、1つのトランザクション内のすべての問合せに同一時点を基準とした読取り一貫性を持たせる機能です。複数の表に対して多数の問合せを実行し、更新を行わない場合は、読取り専用トランザクションを使用します。
Oracleは、ロックを使用してデータへの同時アクセスを制御します。情報の更新時には、更新が発行またはコミットされるまで、その情報にはデータ・サーバーによりロックされます。発行またはコミットされるまで、ロックされている情報は誰も変更できません。これにより、システムのデータ整合性が保証されます。
Oracleには、拡大されない一意の行レベル・ロック機能が用意されています。他のデータ・サーバーでは行グループ全体や表全体を扱うためにロックが拡大されますが、Oracleでは更新中の情報行のみが常にロックされます。Oracleには、実際の行自体を使用してロック情報が組み込まれるので、ロックできる行数に制限がなく、ユーザーは不必要な遅延なしで同時に作業できます。
Oracleのロックは自動的に実行されるため、ユーザーの操作は必要ありません。要求される処理によっては、必要に応じて暗黙的ロックがSQL文に対して発生します。Oracleのロック・マネージャ（ロック管理機能）は、行レベルで表データを自動的にロックします。行レベルで表データをロックすることで、同一データへの競合が最小限に抑えられます。
ロックを設定する操作のタイプに応じて、異なるタイプの行ロックを保持します。一般に、ロックには排他ロックと共有ロックの2種類があります。排他ロックは、1つのリソース（行や表など）に対して1つのみ設定できます。一方、共有ロックは、1つのリソースに対して数多く設定できます。排他ロックと共有ロックでは、ロックされたリソースに対する問合せはいつでも許可されますが、そのリソースに対する他のアクティビティ（更新や削除など）は禁止されます。
状況によっては、ユーザーは、デフォルト・ロックをオーバーライドできます。Oracleでは、自動ロック機能を行レベル（後続の文で更新する行を最初に問い合せておく）と表レベルの両方で手動変更できます。
データベース管理者は、同時に実行するデータベース管理者以外の処理を分離する必要が生じることがあります。つまり、同時に実行するデータベース管理者以外のトランザクション、問合せ、PL/SQL文を分離します。このような分離を実行する方法の1つとして、データベースを停止してから、制限モードで再オープンする方法があります。また、ユーザーに作業を中断させることなくシステムを静止状態にすることができます。静止状態では、データベース管理者は、データベース管理者以外の処理を分離して安全に実行できます。
Real Application Clusters（RAC）は、相互接続を使用して相互に通信する複数のクラスタ化コンピュータ上で実行される、複数のOracleインスタンスで構成されます。RACは、クラスタ・ソフトウェアを使用して、共有ディスクに常駐する共有データベースにアクセスします。このように相互接続された複数のコンピュータの処理能力を組み合せることで、RACはシステムの冗長性、ほぼ線形のスケーラビリティおよび高可用性を提供します。また、OLTPとデータ・ウェアハウス・システムの両方にとって大きな利点があり、すべてのシステムとアプリケーションはクラスタ環境を効率的に活用できます。
RAC環境では、アプリケーションをそのまま拡張して増大するデータ処理需要に対処でき、アプリケーション・コードを変更する必要がありません。ノードやストレージなどのリソースを追加すると、これらのリソースの処理能力はRACにより個々のコンポーネントの制限を超えて拡張されます。
Oracleは、すべての主要プラットフォームにまたがる一意の移植性を備えており、プラットフォームの変更後はそのままアプリケーションを実行できることが保証されます。これは、Oracleのコードベースがプラットフォーム間で同じなので、すべてのプラットフォーム間で同じ機能を使用でき、アプリケーションの完全な透過性が得られるためです。この移植性により、要件の変化に応じて、より強力なサーバーへと容易にアップグレードできます。
Oracleデータベース・システムの運用管理者はデータベース管理者（DBA）と呼ばれ、Oracleデータベースの作成、円滑な運用の保証および使用の監視を担当します。Oracleには、多数のアラートとアドバイザに加えて、次の機能が用意されています。
Oracle Databaseは高度な自己管理機能を備えており、日常的なDBAタスクが自動化され、領域、メモリーおよびリソース管理が簡素化されます。Oracleの自己管理データベース機能には、自動UNDO管理、動的メモリー管理、Oracle Managed Files、平均リカバリ時間、空き領域管理、マルチ・ブロック・サイズおよびRecovery Manager（RMAN）が含まれます。
Enterprise Managerは、異機種間環境を集中管理するための統合ソリューションを提供するシステム管理ツールです。Enterprise Managerは、グラフィカル・コンソール、Oracle Management Server、Oracle Intelligent Agent、共通サービスおよび管理ツールを組み合せることで、Oracle製品を管理するための包括的なシステム管理プラットフォームを提供します。
クライアント・インタフェースであるEnterprise Managerコンソールから、次のタスクを実行できます。
SQL*Plusは、非定型データベース文を入力して実行するためのツールです。SQL*Plusを使用すると、SQL文とPL/SQLブロックを実行したり、他の多数のタスクを実行できます。
自動ストレージ管理により、データファイル、制御ファイルおよびログ・ファイルのレイアウトが自動化され、簡素化されます。データベース・ファイルは使用可能なすべてのディスク間で自動的に分散され、記憶域構成に変更があるたびにデータベース記憶域のバランスが調整されます。データベース・ファイルのミラー化を介して冗長性が実現され、データベース・ファイルを使用可能なすべてのディスク間で自動的に分散することでパフォーマンスが改善されます。データベース記憶域のバランス再調整は、記憶域構成に変更があるたびに自動的に実行されます。
Oracleには、管理タスクを簡素化し、複雑なスケジューリング・ニーズに対処する豊富な機能セットを提供するために、DBMS_SCHEDULERパッケージにファンクションとプロシージャのコレクションが用意されています。これらのファンクションは総称してスケジューラと呼ばれ、どのPL/SQLプログラムからでもコールできます。
スケジューラを使用すると、データベース管理者とアプリケーション開発者はデータベース環境で各種タスクが発生する時期と場所を制御できます。たとえば、データベース管理者は、バックアップや夜間のデータ・ウェアハウスのロードおよび抽出など、データベース・メンテナンス・ジョブをスケジュールして監視できます。
従来、Oracleデータベースなど、システム上で実行される各種アプリケーション間のリソース管理は、オペレーティング・システムによって調整されていました。データベース・リソース・マネージャは、データベース内の実行スケジュールを制御することで、各種セッション間のリソースの分配を制御します。実行させるセッションとその実行時間を制御することで、データベース・リソース・マネージャでは、リソース分配とプラン・ディレクティブとを確実に一致させることができます（したがって、ビジネス目標とも一致します）。
どのようなデータベース・システムでも、常にシステムやハードウェアの障害が発生する可能性があります。障害が発生し、データベースが影響を受けた場合は、データベースをリカバリする必要があります。障害発生後の目標は、コミットされたすべてのトランザクションの影響を、リカバリするデータベースに確実に反映させ、その障害によって生じた問題からユーザーを隔離しながら、できるだけ迅速に通常の運用状態に復帰させることです。
Oracleには、次の各種メカニズムが用意されています。
状況によっては、Oracleデータベースの操作が中断されます。次の表に、最も一般的な障害のタイプを示します。
Oracleでは、ディスク障害など、発生する可能性のあるすべてのタイプのハードウェア障害から、完全なメディア・リカバリを実行できます。データベースを完全にリカバリするか、または部分的に特定の時点までリカバリできるように、オプションが用意されています。
ディスク障害のためにいくつかのデータファイルが破損しても、データベースの大部分は損なわれておらず、そのまま運用できるという場合にかぎり、必要な表領域を個別にリカバリする間、データベースをオープンしたままにしておくことができます。したがって、データベースのうち損害を受けていない部分は、破損した部分のリカバリ中も日常業務に使用できます。
Oracleは、REDOログ、UNDOレコード、制御ファイルおよびデータベース・バックアップなど、いくつかの構造を使用して、インスタンス障害やディスク障害から完全にリカバリします。
REDOログとは、データファイルに書き込まれていない、メモリー内の変更済データベース・データを保護するファイルの集合です。REDOログは、オンラインREDOログとアーカイブREDOログで構成できます。
オンラインREDOログは、2つ以上のオンラインREDOログ・ファイルの集合であり、データベースに対して行われたすべての変更が、コミット済かどうかを問わず記録されます。REDOエントリは、システム・グローバル領域のREDOログ・バッファに一時的に格納され、バックグラウンド・プロセスLGWRはこのREDOエントリをオンラインREDOログ・ファイルに順次書き込みます。LGWRはREDOエントリを絶えず書き込みます。つまり、ユーザー・プロセスがトランザクションをコミットするたびに、コミット・レコードを書き込みます。
いっぱいになったオンラインREDOログ・ファイルは、オプションでアーカイブREDOログを作成して再利用の前に手動で、または自動的にアーカイブできます。アーカイブを使用可能または使用禁止にするには、データベースを次のいずれかのモードに設定します。
ARCHIVELOG: いっぱいになったオンラインREDOログ・ファイルは、循環方式で再利用される前にアーカイブされます。
NOARCHIVELOG: いっぱいになったオンラインREDOログ・ファイルはアーカイブされません。
ARCHIVELOGモードにすると、インスタンスおよびディスク障害からデータベースを完全にリカバリできます。データベースがオープンされ使用可能な場合にも、バックアップを取ることが可能です。ただし、管理操作を追加して、アーカイブREDOログをメンテナンスする必要があります。
データベースのREDOログをNOARCHIVELOGモードで運用している場合、データベースをインスタンス障害から完全にリカバリできますが、ディスク障害からはリカバリできません。また、データベースが完全にクローズされている間のみ、データベースのバックアップを作成できます。アーカイブREDOログが作成されないため、データベース管理者による余分な作業は必要ありません。
UNDOレコードはUNDO表領域に格納されます。Oracleは、コミットされていないトランザクション内で変更があったブロックのビフォア・イメージにアクセスするなど、様々な目的でUNDOデータを使用します。データベース・リカバリ中には、OracleはREDOログに記録された変更をすべて適用した後、UNDO情報を使用して、コミットされていないトランザクションをロールバックします。
制御ファイルには、データベースのファイル構造と、LGWRによって書き込まれているカレント・ログ順序番号についての情報が保管されます。通常のリカバリ手順では、制御ファイル内の情報に基づいてリカバリ操作が自動的に進行します。
ディスク障害では、1つ以上のファイルが物理的に破損している可能性があるため、メディア・リカバリでは、データベースの最新のオペレーティング・システム・バックアップから、破損したファイルをリストアする必要があります。データベース・ファイルのバックアップを作成するには、Recovery Manager（RMAN）を使用する方法とオペレーティング・システムのユーティリティを使用する方法があります。Recovery Managerは、バックアップおよびリカバリの操作を管理するOracleユーティリティです。データベース・ファイル（データファイル、制御ファイルおよびアーカイブREDOログ・ファイル）のバックアップを作成したり、バックアップを使用してデータベースのリストアやリカバリを行います。
|
関連項目
|
ほとんど常時に近い可用性を提供するように構成されたコンピューティング環境は、高可用性システムと呼ばれます。通常、この種のシステムには、障害が発生してもシステムを使用できるように冗長ハードウェアおよびソフトウェアがあります。適切に設計された高可用性システムでは、単一の障害箇所が回避されます。
障害が発生すると、フェイルオーバー・プロセスは、障害を起こしたコンポーネントによって実行されていた処理を、バックアップ・コンポーネントに移動します。このプロセスは、可能な場合は数ミリ秒以内にシステム全体のリソースを再マスター化し、部分的なトランザクションまたは障害を起こしたトランザクションをリカバリして、システムを正常な状態にリストアします。フェイルオーバーがユーザーに対して透過的であるほど、システムの可用性が高いことになります。
Oracleには、予定されていたかどうかを問わず、停止時間が発生した場合に高可用性を提供する多数の製品と機能が用意されています。たとえば、ファスト・スタート・リカバリ、Real Application Clusters、Recovery Manager（RMAN）、バックアップおよびリカバリ・ソリューション、Oracle Flashback、パーティション化、Oracle Data Guard、LogMiner、多重化REDOログ・ファイル、オンライン再編成などがあります。これらの製品と機能を様々な組合せで使用して、特定の高可用性ニーズを満たすことができます。
この項では、複数のビジネス・インテリジェンス機能について説明します。
データ・ウェアハウスは、トランザクション処理ではなく問合せおよび分析用に設計されたリレーショナル・データベースです。通常は、トランザクション・データから導出された履歴データが格納されますが、他のソースからのデータも格納できます。データ・ウェアハウスにより、分析のワークロードがトランザクションのワークロードから分離され、組織は複数のソースからのデータを連結できます。
データ・ウェアハウス環境には、リレーショナル・データベースの他に、ETLソリューション、オンライン分析処理（OLAP）エンジン、クライアント分析ツール、データを収集してビジネス・ユーザーに配信するプロセスを管理する他のアプリケーションがあります。
ビジネス分析を容易にするという目的を果たせるように、データ・ウェアハウスを定期的にロードする必要があります。そのためには、1つ以上のオペレーティング・システムからデータを抽出し、ウェアハウスにコピーする作業が必要です。ソース・システムからデータを抽出してデータ・ウェアハウスに取り込む処理は、一般にETLと呼ばれ、抽出、変換、ロードを表します。
マテリアライズド・ビューは、問合せ結果を別々のスキーマ・オブジェクトに格納して、表データへのアクセスを提供します。通常のビューは記憶域を占めず、データも含まれていませんが、マテリアライズド・ビューには、1つ以上の実表やビューに対する問合せで得られた行が含まれます。マテリアライズド・ビューの格納場所は、実表と同じデータベースでも、異なるデータベースでもかまいません。
マテリアライズド・ビューをその実表と同じデータベースに格納すると、クエリー・リライトを通じて問合せのパフォーマンスを改善できます。クエリー・リライトは、Oracleやエンド・ユーザーまたはデータベースのアプリケーションにより、元の表にアクセスするかわりにマテリアライズド・ビューを使用するようSQL問合せが自動的にリライトされることで、問合せ応答時間が透過的に短縮されるメカニズムです。クエリー・リライトは、データ・ウェアハウス環境で特に役立ちます。
データ・ウェアハウス環境では、通常、大量のデータと非定型問合せを扱うものの、同時データ操作言語（DML）トランザクションのレベルは高くありません。この種のアプリケーションに対するビットマップ索引の利点は次のとおりです。
従来のBツリー索引を使用して大きな表に完全な索引を作成すると、領域という面で膨大なコストがかかります。索引は表中のデータの何倍にも膨れ上がることがあるからです。それに対して、ビットマップ索引は通常、表中で索引を付けるデータのサイズより小さくてすみます。
ディスク使用量とメモリー使用量（特にバッファ・キャッシュ）を減少させるために、表とパーティション表をデータベースに圧縮形式で格納できます。通常は、これにより読取り専用操作のパフォーマンスが向上します。また、問合せの実行も高速化されます。ただし、CPUオーバーヘッドの面で少しコストがかかります。
OracleでSQL文をパラレル実行する場合は、複数のプロセスが同時に作業を実行して、単一のSQL文を実行します。1つの文を実行するのに必要な作業を複数のプロセスに分けることにより、1つのプロセスで文を実行する場合に比べて、Oracleはさらに高速で実行できます。これらをパラレル実行またはパラレル処理と呼びます。
パラレル実行では、文の処理を1つのOracleシステムの多数のCPUに分割できるため、大規模データベースでのデータ処理集中型の操作における応答時間が劇的に短縮されます。
Oracleには、データベースで分析操作を実行するための多数のSQL操作があります。これには、ランキング、移動平均、累計、対比レポート、期間対比などがあります。
アプリケーション開発者は、標準レポートと非定型レポートにSQLのオンライン分析処理（OLAP）機能を使用できます。Oracle OLAPには、追加の分析機能として多次元計算、予測、モデル化およびWhat-Ifによる使用例が用意されています。これにより、開発者は売上およびマーケティング分析、企業の予算および財務分析、需要プランニング・システムなど、洗練された分析およびプランニング・アプリケーションを作成できます。データは、リレーショナル表またはマルチディメンション・オブジェクトに格納できます。
Oracle OLAPは、従来はマルチディメンション・データベース以外に見られなかった問合せパフォーマンスと計算機能を、Oracleのリレーショナル・プラットフォームに提供します。また、インターネット対応の分析アプリケーションの開発に適したJava OLAP APIも用意されています。OLAPおよびRDBMSテクノロジの他の組合せとは異なり、Oracle OLAPは、ブリッジを使用してリレーショナル・データ・ストアからマルチディメンション・データ・ストアにデータを移動するマルチディメンション・データベースではありません。真のOLAP対応リレーショナル・データベースです。そのため、Oracleは、Oracleデータベースのスケーラビリティ、アクセス可能性、セキュリティ、管理性および高可用性とともに、マルチディメンション・データベースの利点も備えています。Java OLAP APIは、インターネット・ベースの分析アプリケーション専用に設計されており、生産的なデータ・アクセスを提供します。
Oracle Data Miningでは、データがデータベースを出ることはありません。データ、データ準備、モデル構築およびモデルのスコアリングの結果は、すべてデータベースに残ります。これにより、Oracleはアプリケーション開発者に、データ・マイニングをデータベース・アプリケーションとシームレスに統合するためのインフラストラクチャを提供します。データ・マイニングが使用される典型的なアプリケーションには、コール・センター、ATM、ERMおよびビジネス・プランニング・アプリケーションなどがあります。モデルの構築、テストおよびスコアリングなどのデータ・マイニング機能は、Java APIを介して提供されます。
パーティション化とは、大規模な表や索引を、パーティションというより小さくて管理しやすい部分に分割して、この種の表や索引をサポートするときの主な問題に対処します。パーティション表にアクセスする際、SQL問合せとDML文を変更する必要はありません。ただしパーティションを定義すると、DDL文は表や索引全体ではなく、個々のパーティションへのアクセスやその操作ができるようになります。パーティション化を行うと、このようにしてラージ・データベース・オブジェクトの管理を簡素化できます。また、パーティション化は、アプリケーションに対して完全に透過的です。
パーティション化は様々なタイプのアプリケーションで有効ですが、特に大量のデータを管理するアプリケーションで便利です。OLTPシステムは管理性と可用性の改良によって改善されることが多く、データ・ウェアハウス・システムはパフォーマンスと管理性によって改善されます。
Oracleには、リレーショナル・データ、オブジェクト・リレーショナル・データ、XML、テキスト、オーディオ、ビデオ、イメージおよび空間など、豊富な各種インターネット・コンテンツをすべて処理するためのデータ型が組み込まれています。これらのデータ型は、データベースではシステム固有の型として表示されます。これらは、いずれもSQLを使用して問い合せることができます。これらのデータ型のいずれかまたはすべてに属するデータを、1つのSQL文に含めることができます。
XML（Extensible Markup Language）は、Web上でデータを識別し、記述するための標準的な手段です。Oracle XML DBでは、XMLはデータベース内のシステム固有のデータ型として扱われます。Oracle XML DBには、リレーショナル表からXML文書を簡単に作成する方法が多数用意されています。SQL問合せの結果は、すべて自動的にXML文書に変換できます。また、OracleにはJavaとC++で使用可能なユーティリティのセットも組み込まれており、XML文書の作成タスクが簡素化されます。
Oracleには、5つのXML Developer's Kit（XDK）が組み込まれています。各XDKは、コンポーネント、ツールおよびユーティリティからなる標準ベースのセットで構成されています。各XDKはJava、C、C++、PL/SQLおよびJavaBeansに使用できます。
LOBデータ型BLOB、CLOB、NCLOBおよびBFILEを使用すると、非構造化データ（テキスト、グラフィック・イメージ、ビデオ・クリップおよびサウンド・ウェーブなど）の大きなブロックを、バイナリ形式または文字形式で格納し、操作できます。このデータ型を使用すると、個々のデータに対する効率的なランダム・アクセスが可能です。
Oracle Textは、文書またはテキスト形式のコンテンツに索引を付けることで、情報の高速で正確な検索を実現します。Oracle Textを使用すると、テキスト検索と通常のデータベース検索を1つのSQL文にまとめることができます。テキスト形式のコンテンツ、メタデータまたは属性に基づいて文書を検索できるため、Oracle Databaseがすべてのデータ管理の単一の統合ポイントとなります。
Oracle TextのSQL APIは単純で直感的であり、アプリケーション開発者とDBAはテキスト索引を作成、メンテナンスしてテキスト検索を実行できます。
Oracle Ultra Searchを使用すると、Webサイト、データベース表、ファイル、宛先リスト、Oracle Application Server Portalsおよびユーザー定義データ・ソースに索引を付けて検索できます。たとえば、Oracle Ultra Search自体を使用して各種の検索アプリケーションをビルドできます。
Oracle interMediaは、イメージ、オーディオおよびビデオを含む従来型、Webおよび携帯型アプリケーションを統合された方法で開発し、配布するためのサービスの配列を提供します。マルチメディア・コンテンツをOracleに直接格納して管理できます。または、データベース外部に格納されているメディア・コンテンツに効率的にアクセスできるように、メタデータを外部参照とともに格納して索引を付けることも可能です。
Oracleには組込みの空間機能があり、位置コンテンツ（資産、ビル、道路、地区、営業地域など）を格納し、索引を付けて管理し、データベースの機能を使用して位置関係を問い合せることができます。Oracle Spatialオプションによって、線形参照のサポートや座標系などの拡張空間機能が追加されます。
Oracleには、データベースへのアクセス方法と使用方法を制御するためのセキュリティ機能が用意されています。たとえば、セキュリティ・メカニズムは次のように機能します。
スキーマは、各データベース・ユーザーに、そのユーザーと同じ名前によって対応付けられます。デフォルトでは、各データベース・ユーザーは、対応するスキーマ内のすべてのオブジェクトを作成およびアクセスする権利を持っています。
データベース・セキュリティはシステム・セキュリティとデータ・セキュリティの2つのカテゴリに分類できます。
システム・セキュリティには、システム・レベルにおけるデータベースのアクセスと使用を制御するメカニズムが含まれています。たとえば、次のものが含まれます。
システム・セキュリティ・メカニズムでは、ユーザーがデータベースへの接続を認可されているかどうか、データベース監査がアクティブになっているかどうかと、ユーザーが実行できるシステム操作がチェックされます。
データ・セキュリティには、スキーマ・オブジェクト・レベルにおけるデータベースのアクセスと使用を制御するメカニズムが含まれています。たとえば、データ・セキュリティには次のものが含まれます。
SCOTTはemployees表に対してSELECT文とINSERT文を発行できますが、DELETE文は発行できません）。
Oracleデータベースでは、任意アクセス制御が可能です。任意アクセス制御とは、権限に基づいて情報へのアクセスを制限する方法です。ユーザーがスキーマ・オブジェクトにアクセスするには、そのユーザーは適切な権限を割り当てられている必要があります。適切な権限が付与されているユーザーは、他のユーザーに自分で任意に権限を付与できます。
Oracleは、次のようにいくつかの異なる機能を使用してデータベース・セキュリティを管理します。
データは、データベース管理者やアプリケーション開発者によって決められたとおり、特定のビジネス・ルールを遵守する必要があります。たとえば、ビジネス・ルールによって、INVENTORY表のsale_discount列には9よりも大きな数値を入れないように指定されている場合を考えます。INSERT文やUPDATE文がこの整合性規則に違反しようとすると、Oracleはその無効な文を取り消し、アプリケーションにエラーを戻します。Oracleは、データ整合性規則を管理するために、整合性制約とデータベース・トリガーを提供します。
整合性制約は、表の列に対してビジネス・ルールを定義する宣言の方法です。整合性制約は表のデータに関する文であり、常に次の規則に従って機能します。
整合性制約は表に定義され、表の定義の一部としてデータ・ディクショナリに格納されるため、すべてのデータベース・アプリケーションは同じ一連の規則を遵守する必要があります。規則が変更されても、整合性制約はデータベース・レベルで一度変更すればよいため、アプリケーションごとに何度も変更する必要はありません。
Oracleがサポートする整合性制約は次のとおりです。
NOT NULL: 表の列にNULL（空のエントリ）を許可しません。
UNIQUE KEY: 列（または列の集合）に重複値を許可しません。
PRIMARY KEY: 列（または列の集合）に重複値とNULLを許可しません。
FOREIGN KEY: 列（または列の集合）の値が、それぞれ関連する表の一意キーまたは主キーの値と一致している必要があります。 また、外部キー制約は、参照データが変更された場合に依存データを処理する方法をOracleに指示する、参照整合性アクションも定義します。
CHECK: 制約の論理式を満たさない値を許可しません。
キーは、いくつかのタイプの整合性制約の定義で使用されます。キーは特定タイプの整合性制約の定義に含まれる列または列の集合で、 リレーショナル・データベースの異なる表と列の間の関連を記述するものです。キーの中にある個々の値を、キー値と呼びます。
次のようなタイプがあります。
一意制約の定義に含まれる列（または列の集合）。
トリガーとは、PL/SQL、JavaまたはC言語で記述され、表またはビューが変更された場合や、なんらかのユーザー・アクションまたはデータベース・システム・アクションが発生した場合に暗黙的に実行（起動）されるプロシージャです。
トリガーはOracleの標準機能を補い、高度にカスタマイズされたデータベース管理システムを提供します。たとえば、トリガーによって、表に対するDML操作を通常の業務時間内のみに制限できます。
分散環境とは、相互にシームレスに通信する様々なシステムで構成されるネットワークです。分散環境では、各システムをノードと呼びます。ユーザーが直接接続するシステムをローカル・システムと呼びます。このユーザーがアクセスする他のシステムをリモート・システムと呼びます。分散環境では、アプリケーションからローカル・システムやリモート・システムのデータにアクセスして相互に交換できます。すべてのデータに同時にアクセスして変更できます。
異機種間分散データベース・システムとは、1つ以上のコンピュータに常駐する複数のOracleデータベースで構成されるネットワークです。分散SQLを使用すると、アプリケーションとユーザーは、1つのデータベースにアクセスまたは変更する場合と同じくらい容易に、複数のデータベースにあるデータを同時にアクセスまたは変更できます。
Oracle分散データベース・システムはユーザーに対して透過的であるため、1つのOracleデータベースであるかのように見せることができます。企業は、この分散SQL機能を使用して、すべてのOracleデータベースを1つであるかのように見せることで、分散システムの複雑さを軽減できます。
Oracleは、データベース・リンクを使用して、あるデータベース上のユーザーがリモート・データベース内のオブジェクトにアクセスできるようにします。ローカル・ユーザーは、リモート・データベースのユーザーでなくても、リモート・データベースへのリンクにアクセスできます。
アプリケーションとユーザーがデータの物理的な位置を意識しないですむ（透過的である）とき、位置の透過性が実現されます。たとえば、複数のデータベースの表データを結合するビューによって、位置の透過性が実現されます。つまり、この場合、ビューのユーザーはデータの物理的な位置を知る必要がありません。
Oracleは、問合せ、更新およびトランザクションの透過性を提供します。たとえば、SELECT、INSERT、UPDATEおよびDELETEなどの標準SQL文の動作は、非分散データベース環境の場合と同じです。また、アプリケーションでは標準SQL文COMMIT、SAVEPOINTおよびROLLBACKを使用してトランザクションを制御します。Oracleでは、分散トランザクションのデータ整合性が2フェーズ・コミット・メカニズムを使用して保証されます。
分散問合せの最適化により、分散SQL文で参照されているリモート表からトランザクションでデータを取り出すときに、サイト間で必要なデータ転送量が減少します。
Oracle Streamsを使用すると、データベース内またはデータベース間で、データ・ストリーム内のデータ、トランザクションおよびイベントを伝播させ、管理できます。ストリームにより、パブリッシュされた情報がサブスクライブした宛先にルーティングされます。変更を必要とするユーザーは、Oracle Streamsの新機能を実装するのみで、既存の機能を犠牲にする必要はありません。
Oracle Streamsには一連の要素が用意されており、ストリームに入れる情報、ノード間でのストリーム・フローまたはルーティング、各ノードに入ったときにストリーム内でイベントに発生する処理およびストリームの終了方法を制御できます。ストリームで動作する要素の構成を指定することで、メッセージ・キューイングやデータ・レプリケーションなど、特定の要件に対処できます。
Oracle Streamsは、イベントを暗黙的および明示的に取得してステージング領域に置きます。DMLやDDLなどのデータベース・イベントは、REDOログ・ファイルのマイニングによって暗黙的に取得されます。洗練されたサブスクリプション規則により、どのイベントを取得するかを決定できます。
ステージング領域とは、取得されたイベントを格納して管理するサービスを提供するキューです。データベース表に対する変更は論理変更レコード（LCR）としてフォーマットされ、サブスクライバが使用するまでステージング領域に格納されます。LCRのステージングにより、LCRデータの監査と追跡のみでなく保持のための、セキュリティ機能を備えた領域が提供されます。
ステージング領域に置かれたメッセージは適用エンジンで使用され、そこで変更がデータベースに適用されるか、アプリケーションで使用されます。柔軟な適用エンジンにより、標準またはカスタムの適用ファンクションを使用できます。明示的デキューがサポートされるため、アプリケーション開発者はOracle Streamsを使用してメッセージを確実に交換できます。また、Oracle Streamsの変更取得および伝播機能を活用することで、データ変更をアプリケーションに通知できます。
Oracle Streams Advanced Queuingは、Oracle Streamsの柔軟なインフラストラクチャの最上位にビルドされています。このコンポーネントは、イベント処理用の統一フレームワークを提供します。アプリケーションやワークフローで生成されたイベント、またはREDOログやデータベース・トリガーから暗黙的に取得されたイベントを、1つのキューで取得できます。これらのイベントは、様々な方法で使用できます。ユーザー定義ファンクションまたはデータベース表の操作で自動的に適用するか、明示的にデキューするか、使用側アプリケーションに通知を送信できます。これらのイベントは、どの段階でも変換できます。使用側アプリケーションが異なるデータベースにある場合、イベントは適切なデータベースに自動的に伝播します。このようなイベントに対する操作を自動的に監査でき、ユーザー指定の期間のみ履歴を保持できます。
レプリケーションとは、データベース・オブジェクトを複数のデータベース内で維持することです。Oracle Streamsには強力なレプリケーション機能が用意されており、この機能を使用して分散オブジェクトの複数コピーの同期を維持できます。
どの情報が関連しているかは自動的に判別され、その情報を必要としているユーザーと共有されます。このアクティブな情報共有には、DMLによるデータ変更を含むデータベース内での、イベントの取得と管理および他のデータベースやアプリケーションへの伝播が含まれます。データ変更には、レプリカ・データベースに直接適用する方法と、ユーザー定義プロシージャをコールして宛先データベースで代替処理を実行する方法があります。たとえば、データ・ウェアハウスのロードに使用したステージング表を移入できます。
Oracle Streamsはオープンな情報共有ソリューションであり、OracleとOracle以外のシステム間での異機種間レプリケーションをサポートしています。Transparent Gatewayを使用すると、Oracleデータベースで実行されたDML変更をOracle以外のプラットフォームに適用できます。
Oracle Streamsはマテリアライズド・ビューと全面的に相互運用可能です。マテリアライズド・ビューは、更新可能または読取り専用の、データの特定時点のコピーであるスナップショットです。スナップショットには、値ベースの選択基準と一致するマスター表全体のコピー、またはその各行の定義済サブセットが含まれます。多重化マテリアライズド・ビューも使用でき、この場合は1つのマテリアライズド・ビューが別のマテリアライズド・ビューのサブセットとなります。マテリアライズド・ビューは、トランザクション一貫性を持つバッチ更新を介して、対応するマスター表から定期的に更新またはリフレッシュされます。
Oracle Transparent GatewaysとGeneric Connectivityにより、Oracle分散機能がOracle以外のシステムへと拡張されます。Oracleは、Oracle以外のデータ・ソース、Oracle以外のメッセージ・キューイング・システムおよび非SQLアプリケーションで動作でき、他のベンダーの製品およびテクノロジとの相互運用性が保証されます。
この2つのコンポーネントはサード・パーティのSQL言語、データ・ディクショナリおよびデータ型をOracleフォーマットに変換し、Oracle以外のデータ・ストアをリモートOracleデータベースとして使用可能にします。これらのテクノロジにより、企業は各種システムをシームレスに統合し、全社的に連結されたビューを提供できます。
Oracle Transparent GatewaysとGeneric Connectivityは、分散SQLを使用する場合は同期アクセスに、Oracle Streamsを使用する場合は非同期アクセスに使用できます。Oracle Streams環境にTransparent Gatewayを導入することで、OracleデータベースからOracle以外のデータベースへのデータ・レプリケーションが可能になります。
Generic Connectivityは汎用ソリューションですが、Oracle Transparent Gatewaysは調整されたソリューションであり、Oracle以外のシステム向けに特別にコーディングされています。
SQLとPL/SQLは、Oracleのアプリケーション開発スタックの核となっています。ほとんどの企業のバックエンドでSQLを実行しているのみでなく、データベースにアクセスするWebアプリケーションもSQL（JavaクラスによりJDBCとしてラップ）を使用しており、エンタープライズ・アプリケーション統合アプリケーションはSQL問合せからXMLを生成し、コンテンツ・リポジトリはSQL表の最上位に作成されます。これは、単純で広く知られた統一データ・モデルです。SQLは多数のアプリケーションでスタンドアロンとして使用されますが、Java（JDBC）、Oracle Call Interface（OCI）、Oracle C++ Call Interface（OCCI）またはXSU（XML SQL Utility）からも直接コールできます。ストアド・パッケージ、プロシージャおよびトリガーは、いずれもPL/SQLまたはJavaで記述できます。
この項の内容は、次のとおりです。
SQLは、データベースを定義して操作するためのプログラミング言語です。SQLデータベースはリレーショナル・データベースです。これは、データが一連の単純なリレーションに基づいて格納されるということです。
Oracleデータベース内の情報の操作はすべて、SQL文を使用して実行されます。SQL文は、SQLテキストの文字列です。次のように、文は、完全なSQL文と等価である必要があります。
SELECT last_name, department_id FROM employees;
正常に実行できるのは完全なSQL文のみです。次のような不完全文を実行しようとすると、テキストの不足を示すエラーが発生します。
SELECT last_name
SQL文は非常に簡単な文ですが、強力なコンピュータ・プログラム、または命令と考えることができます。SQL文は、次のカテゴリに分類されます。
この種の文は、スキーマ・オブジェクトを作成、変更、保持および削除します。DDL文には、データベースやデータベース内の特定のオブジェクトにアクセスする権限を、あるユーザーから他のユーザーに付与するための文も含まれます。
この種の文はデータを操作します。たとえば、表の行の問合せ、挿入、更新および削除はすべてDML操作です。最も使用頻度の高いSQL文は、SELECT文です。この文によって、データベースからデータを取り出します。表やビューのロックやSQL文の実行計画の検討もDML操作です。
この種の文は、DML文によって行われる変更を管理します。これによって、ユーザーはいくつかの変更をグループ化して論理トランザクションを作成できます。この文に含まれるのは、COMMIT、ROLLBACKおよびSAVEPOINTなどです。
この種の文を使用すると、ユーザーは自分のカレント・セッションのプロパティを制御できます。つまり、ロールを使用可能や使用禁止にしたり、言語設定を変更できます。セッション制御文には、ALTER SESSIONおよびSET ROLEの2つがあります。
この種の文は、Oracleデータベース・インスタンスのプロパティを変更します。システム制御文は、ALTER SYSTEMのみです。この文は、共有サーバーの最小数などの設定値の変更、セッションの停止およびその他の作業のために使用します。
この種の文は、DDL文、DML文およびトランザクション制御文を、Oracleプリコンパイラとともに使用されるプログラムなどの手続き型言語プログラムに取り込んだものです。たとえば、OPEN、CLOSE、FETCHおよびEXECUTEなどがあります。
PL/SQLは、SQLに対するOracleの手続き型言語拡張機能です。 PL/SQLでは、SQLが持つ使用しやすさと柔軟性に、IF ... THEN、WHILE、LOOPなどの構造化プログラミング言語の手続き型機能が結合されています。
データベース・アプリケーションを設計するときには、PL/SQLを使用することによる次のような利点を検討してください。
次の項では、データベース内に定義し、一括して格納できるPL/SQLプログラム・ユニットについて説明します。
プログラム・ユニットとは、ストアド・プロシージャ、ファンクション、パッケージ、トリガーおよび自律型トランザクションです。
プロシージャとファンクションは、一連のSQL文およびPL/SQL文です。これらの文は、特定の問題を解決したり一連の関連タスクを実行することを目的として、1つの単位としてグループ化されています。プロシージャとファンクションは、作成後にコンパイル済の形式でデータベース内に格納され、ユーザーまたはデータベース・アプリケーションによって実行されます。
プロシージャとファンクションは同じです。ただし、ファンクションはユーザーに必ず1つの値を戻します。これに対して、プロシージャは値を戻しません。
パッケージによって、関連したプロシージャ、ファンクション、変数およびその他の構成メンバーをカプセル化し、データベースの単位としてまとめて格納できます。パッケージによって、機能性が拡大されます（たとえば、グローバル・パッケージ変数を宣言して、パッケージ内のプロシージャで使用できます）。また、パフォーマンスも改善できます（たとえば、パッケージのすべてのオブジェクトを一度に解析およびコンパイルし、メモリーにロードできます）。
Javaは、アプリケーション・レベルのプログラムに効果を発揮するオブジェクト指向のプログラミング言語です。OracleにはあらゆるタイプのJDBCドライバが用意されており、Javaアプリケーションからのデータベース・アクセスを拡張します。Javaストアド・プロシージャはアクセス制御の面で移植可能でセキュアであり、Java以外の従来型アプリケーションでもJavaを透過的に起動できます。
Oracle Databaseの開発者は、アプリケーション開発に使用する言語をC、C++、Java、COBOL、PL/SQLおよびVisual Basicの中から選択できます。どの言語でも、データベースの機能全体が使用可能です。言語固有の標準がすべてサポートされます。開発者は、最も慣れている言語、または特定のタスクに最も適した言語を選択できます。たとえば、アプリケーションでは、サーバー側でJavaを使用して動的Webページを作成し、PL/SQLを使用してデータベースにストアド・プロシージャを実装し、C++を使用して中間層に計算集中型のロジックを実装できます。
Oracle Call Interface（OCI）は、Oracle Database用のCデータ・アクセスAPIです。OCIはOracle Database機能セット全体をサポートします。OCCI、ODBC、Oracle JDBC Type2ドライバなど、多くのデータ・アクセスAPIがOCIの上に作成されています。OCIは、高パフォーマンス、セキュア、スケーラブルおよびフォルト・トレラントを備えたアプリケーションを作成するための強力な機能を提供します。また、OCIは、サーバー内で、データベース・カーネル・コンポーネントのデータ・アクセス、および分散データベースへのアクセスを実行するためにも使用されます。OCIを使用すると、アプリケーション開発者はCファンクション・コールを使用してOracleデータ・サーバーにアクセスし、ビジネス・ロジック実行のすべてのフェーズを制御できます。OCIは、標準データベース・アクセスおよび検索関数のライブラリとして、アプリケーションによってリンク可能な動的ランタイム・ライブラリの形式で公開されます。
Oracle C++ Call Interface（OCCI）は、オブジェクト指向機能、システム固有クラスおよびC++プログラミング言語のメソッドを使用してOracleデータベースにアクセスできるC++ APIです。OCCIインタフェースは、JDBCインタフェースに基づいて設計されています。OCCIは、OCIの上に作成され、オブジェクト指向パラダイムを使用してOCIの機能とパフォーマンスを拡張します。
Open Database Connectivity（ODBC）は、データベースに接続し、データベースに対してSQL文を準備して実行するためのデータベース・アクセスAPIです。アプリケーションをODBCドライバと組み合せることで、Excelのようなスプレッドシートに格納されているデータなど、あらゆるデータ・ソースにアクセスできます。
Oracleには、Visual BasicやActive Server Pageなど、COMベースのプログラミング言語からの様々なデータ・アクセス方式が用意されています。たとえば、Oracle Objects for OLE（OO4O）やOracle Provider for OLE DBがあります。また、Oracleは、Oracle Data Provider for .NETを介して.NETデータ・アクセスのサポートを提供します。さらに、OLE DB .NETとODBC .NETもサポートしています。
OracleにはPro*シリーズのプリコンパイラも用意されており、SQLとPL/SQLをC、C++またはCOBOLアプリケーションに埋め込むことができます。
トランザクションは、単一のユーザーによって実行される1つ以上のSQL文を含む論理作業単位です。Oracleと互換性のあるANSI/ISO SQL規格によると、トランザクションはユーザーの最初の実行SQL文で開始されます。ユーザーが明示的にコミットまたはロールバックすると、トランザクションは終了します。
トランザクション内のSQL文が論理的にグループ化されるかぎり、ユーザーはトランザクションを使用してデータへの一貫した変更を保証できます。トランザクションには、1つの論理作業単位に必要な部分を過不足なくすべて含める必要があります。トランザクションの開始から終了まで、参照される表データはすべて一貫した状態に維持されます。各トランザクションには、データに対して首尾一貫した1つの変更を加えるSQL文のみを含めます。
銀行のデータベースを考えてみます。銀行の顧客が普通預金口座から当座預金口座へ預金を振り替える場合、トランザクションは次の3つの別々の操作で構成されます。つまり、普通預金口座の減額、当座預金口座の増額およびトランザクション・ジャーナルへのトランザクションの記録です。
送金（トランザクション）には、一方の口座の預金高を増やす処理（1つのSQL文）、他方の口座の預金高を減らす処理（1つのSQL文）、およびジャーナルにトランザクションを記録する処理（1つのSQL文）が含まれます。これらの処理は、すべて失敗するか、すべて成功するかのどちらかです。つまり、出金がコミットされずに、入金がコミットされることはありません。また、ある口座に新しく預金するなど、関連のないその他の処理を、振替トランザクションに含めることはできません。そのような文は、別のトランザクションに組み込みます。
Oracleは、3つのSQL文をすべて実行することにより、口座の差引勘定が正しく維持されることを保証する必要があります。なんらかの問題（ハードウェア障害など）でトランザクション内の文がどれか1つでも実行されなかった場合は、トランザクションの他の文の実行を取り消す必要があります。これをロールバックと呼びます。2つの更新のうちどちらかの実行中にエラーが発生した場合、どちらの更新も行われません。
トランザクションを構成するSQL文によって加えられた変更は、コミットまたはロールバックできます。トランザクションがコミットまたはロールバックされた場合、次のトランザクションは次のSQL文から開始されます。
トランザクションをコミットすると、トランザクション内のすべてのDML文による変更が確定されます。トランザクションのSQL文による変更は、そのトランザクションがコミットされた後に実行が開始された他のユーザーのSQL文から参照可能になります。
トランザクションを取り消すと、トランザクション内のSQL文による変更がすべて取り消されます。トランザクションがロールバックされると、トランザクション内のSQL文が実行されなかった場合と同様に、影響を受けたデータは変更されないまま残ります。
セーブポイントは、多数のSQL文によるロング・トランザクションをいくつかの小さい部分に分割します。セーブポイントを使用すると、ロング・トランザクション内の任意のポイントで作業に任意にマークを設定できます。これにより、トランザクションのカレント位置から、トランザクション内で宣言したセーブポイントまでの間に実行されたすべての作業を、選択的にロールバックできます。
SQL文中の列値と定数は、それぞれ特定の記憶域形式、制約および値の有効範囲に対応付けられたデータ型を持っています。表の作成時には、その各列のデータ型を指定する必要があります。
Oracleの組込みデータ型は、次のとおりです。
組込みデータベース型または以前に作成したオブジェクト型、オブジェクト参照およびコレクション型から、新規のオブジェクト型を作成できます。ユーザー定義型のメタデータは、SQL、PL/SQL、Javaおよび他の公開インタフェースで使用可能なスキーマに格納されます。
オブジェクト型は、ユーザー定義であり、基礎となる永続データ（属性）と関連する動作（メソッド）を指定するという点で、ネイティブのSQLデータ型と異なります。オブジェクト型は、発注情報など、実社会のエンティティを抽象化したものです。
オブジェクト型と、可変長配列やネストした表などの関連するオブジェクト指向機能により、データベース内のデータについて高水準の編成方法とアクセス方法が提供されます。データはオブジェクト・レイヤーでも列と表に格納されますが、顧客や発注情報など、データを意味のあるものにする実社会のエンティティに関連してデータを操作できます。データベースの問合せでは、列と表を考慮するかわりに単に顧客を選択できます。
Oracleデータベースは世界中どこにでも配置でき、Oracleデータベースの単一インスタンスに世界中のユーザーがアクセスできます。各ユーザーには、それぞれの所在地に固有の言語と形式で情報が表示されます。
Globalization Development Kit（GDK）により開発プロセスが簡素化され、多言語市場に向けたインターネット・アプリケーションの開発コストが削減されます。GDKを使用すると、1つのプログラムで世界各地のあらゆる言語によるテキストを処理できます。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|