1 Oracle AI Databaseの概要
この章では、Oracle AI Databaseの概要について説明します。
この章のトピックは、次のとおりです:
リレーショナル・データベースについて
すべての組織には、その要件を満たすために格納および管理する必要のある情報があります。たとえば、会社では従業員の人事管理レコードを収集し、管理する必要があります。この情報は、必要とする人が使用できるようにする必要があります。
情報システムとは、情報を格納および処理するための形式が定められたシステムです。情報システムは、フォルダを収納した一連の段ボール箱とフォルダの格納および取出し方法に関するルールとすることもできます。ただし、今日のほとんどの企業はデータベースを使用して情報システムを自動化しています。データベースとは、1つの単位として取り扱われる編成されたデータの集合です。データベースは、データベース・アプリケーションで使用するための関連情報の収集、格納、および取出しを目的としています。
データベース管理システム(DBMS)
データベース管理システム(DBMS)とは、データの格納、編成および取得を制御するソフトウェアです。
通常、DBMSの要素は次のとおりです。
-
カーネル・コード
このコードでは、DBMS用のメモリーと記憶域を管理します。
-
メタデータのリポジトリ
このリポジトリは、通常、データ・ディクショナリと呼ばれます。
-
問合せ言語
この言語を使用してデータにアクセスできます。
データベース・アプリケーションとは、データにアクセスして操作するためにデータベースと対話するソフトウェア・プログラムです。
第一世代のデータベース管理システムには次のタイプがありました。
-
階層
階層データベースは、データをツリー構造に編成したものです。ファイル・システムの構造と同様に、各親レコードが1つ以上の子レコードを持ちます。
-
ネットワーク
ネットワーク・データベースは、レコードが1対多の関係ではなく多対多の関係を持つ点を除いて、階層データベースと同じです。
第一世代のデータベース管理システムでは、事前に定義された厳密な関係に基づいてデータが格納されていました。データ定義言語がなかったため、データ構造の変更は困難でした。また、これらのシステムには簡単な問合せ言語がなく、このことがアプリケーション開発の妨げになっていました。
リレーショナル・モデル
独創性に富んだ1970年の論文「A Relational Model of Data for Large Shared Data Banks」において、E. F. Codd氏は、数学的な集合理論に基づいてリレーショナル・モデルを定義しました。今日、最も普及しているデータベース・モデルはリレーショナル・モデルです。
リレーショナル・データベースとは、リレーショナル・モデルに準拠したデータベースです。リレーショナル・モデルには次の特徴があります。
-
構造
詳細に定義されたオブジェクトによって、データベースのデータの格納またはアクセスが行われます。
-
操作
明確に定義されたアクションによって、アプリケーションはデータベースのデータおよび構造を操作できます。
-
整合性規則
整合性規則は、データベースのデータおよび構造に対する操作を制御します。
リレーショナル・データベースでは、データは一連の単純なリレーションに格納されます。リレーションは一連のタプルです。タプルは、順不同の一連の属性値です。
表は、行(タプル)と列(属性)の形式でのリレーションの2次元表現です。表の各行は同じ一連の列を持ちます。リレーショナル・データベースは、データをリレーション(表)に格納するデータベースです。たとえば、リレーショナル・データベースで会社の従業員に関する情報を従業員表、部門表、および給与表に格納できます。
リレーショナル・データベース管理システム(RDBMS)
リレーショナル・モデルは、リレーショナル・データベース管理システム(RDBMS)の基礎です。RDBMSではデータをデータベース内に移動して格納し、それを取り出してアプリケーションで操作できるようにします。
RDBMSでは、次のように操作のタイプが区別されます。
-
論理演算
この場合、アプリケーションは、必要な内容を指定します。たとえば、従業員の名前を要求したり、従業員レコードを表に追加します。
-
物理演算
この場合、RDBMSは、どのように実行すべきかを判断して演算を実行します。たとえば、アプリケーションが表に問合せを実行すると、データベースの索引を使用して要求した行が検索され、データがメモリーに読み込まれ、その他多くのステップが実行されてからユーザーに結果が戻されます。RDBMSがデータの格納と取得を行うため、物理演算はデータベース・アプリケーションに対して透過的です。
Oracle AI DatabaseはRDBMSです。ユーザー定義型、継承、ポリモフィズムなどのオブジェクト指向機能を実装したRDBMSは、オブジェクト・リレーショナル・データベース管理システム(ORDBMS)と呼ばれます。Oracle AI Databaseはリレーショナル・モデルを拡張したオブジェクト・リレーショナル・モデルであり、複雑なビジネス・モデルをリレーショナル・データベースに格納できます。
スキーマ・オブジェクト
RDBMSの特性の1つは、物理データ記憶域が論理データ構造から独立していることです。
Oracle AI Databaseにおいて、データベース・スキーマとは、論理データ構造またはスキーマ・オブジェクトの集合です。データベース・スキーマはデータベース・ユーザーによって所有され、そのユーザー名と同じ名前になります。
スキーマ・オブジェクトは、ユーザーが作成する構造であり、データベース内のデータを直接参照します。データベースは多くのタイプのスキーマ・オブジェクトをサポートしますが、最も重要なのは表と索引です。
スキーマ・オブジェクトは、データベース・オブジェクトの1種です。プロファイルやロールなど、一部のデータベース・オブジェクトは、スキーマに常駐しません。
関連トピック
表
データ・アクセス
DBMSの一般的な要件は、業界で受け入れられているデータ・アクセス言語の標準に準拠することです。
ノート:
JavaScriptを使用するには、Linux x86-64またはLinux aarch64でOracle 26aiを実行している必要があります。Structured Query Language(SQL)
SQLは、Oracle AI 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を拡張した数多くの機能がサポートされています。
関連トピック
PL/SQL、JavaおよびJavaScript
PL/SQLは、Oracle SQLに対する手続きを拡張します。JavaおよびJavaScriptは、ビジネス・ロジックをデータベースに格納するために使用できる追加オプションです。
PL/SQLはOracle AI Databaseに統合されており、Oracle AI DatabaseのすべてのSQL文、関数、およびデータ型を使用できます。PL/SQLを使用すると、SQLプログラムのフローの制御、変数の使用、およびエラー処理プロシージャの作成を行うことができます。
PL/SQLの主な利点は、アプリケーション・ロジックをデータベースそのものに格納できることです。PL/SQLプロシージャまたはファンクションは、一連のSQL文と他のPL/SQL構文で構成され、グループとしてまとめてデータベースに格納されるスキーマ・オブジェクトであり、特定の問題を解決したり、一連の関連タスクを実行するために1つの単位として実行されます。サーバー側プログラミングの主な利点は、組込み機能を任意の場所にデプロイできることです。
Oracle AI Databaseは、JavaおよびJavaScriptで作成されたプログラム・ユニットも格納できます。Javaストアド・プロシージャは、SQLにパブリッシュされ、一般的な用途向けにデータベースに格納されるJavaメソッドです。既存のPL/SQLプログラムをJavaおよびJavaScriptからコールしたり、JavaおよびJavaScriptプログラムをPL/SQLからコールできます。
マルチリンガル・エンジン(MLE)では、ビジネス・ロジックをJavaScriptに記述し、そのコードをMLEモジュールとしてデータベースに格納できます。MLEモジュールによってエクスポートされるファンクションは、コール仕様を使用してSQLおよびPL/SQLに公開できます。これらのコール仕様はPL/SQLユニット(ファンクション、プロシージャおよびパッケージ)であり、PL/SQLがコールされる任意の場所でコールできます。
トランザクションの管理
Oracle AI Databaseはマルチユーザー・データベースとして設計されています。データベースは、複数のユーザーが互いのデータを破損することなく同時に作業できることを保証する必要があります。
トランザクション
トランザクションは、1つ以上のSQL文を含むアトミックな論理作業単位です。
RDBMSは、SQL文をグループ化して、すべての文がコミットされた(つまりデータベースに適用された)状態にするか、すべての文がロールバックされた(つまり取り消された)状態にできる必要があります。
トランザクションが必要な例として、普通預金口座から当座預金口座への振替があります。振替は独立した次の操作で構成されます。
-
普通預金口座の減額
-
当座預金口座の増額
-
トランザクション・ジャーナルへのトランザクションの記録
Oracle AI Databaseは、3つの操作すべてが1つの単位として成功したこと、または失敗したことを保証します。たとえば、ハードウェア障害によってトランザクション内の文の1つを実行できなかった場合は、その他の文をロールバックする必要があります。
トランザクションは、Oracle AI Databaseとファイル・システムとの明らかな違いを示す1つの機能です。複数のファイルを更新する不可分な操作を実行する場合、その途中でシステム障害が発生すると、ファイル間の整合性が失われます。対照的に、トランザクションは、Oracle Databaseを矛盾のない1つの状態から矛盾のない別の状態に移行します。トランザクションの基本的な原則は、100かゼロかであり、不可分の操作はその全体が成功するかその全体が失敗します。
関連トピック
データ同時実行性
マルチユーザーRDBMSの要件の1つに、データ同時実行性(同じデータに複数のユーザーが同時にアクセスすること)の制御があります。
同時実行性が制御されていない場合、ユーザーがデータを不適切に変更し、データ整合性が損われることがあります。たとえば、あるユーザーが行を更新する一方で、別のユーザーがその行を同時に更新することがあります。
複数のユーザーが同じデータにアクセスした場合、同時実行性を管理する1つの方法は、ユーザーを待機させることです。ただし、DBMSの目標は待機時間をゼロまたはごくわずかまで減らすことです。データを変更するすべてのSQL文は、できるだけ干渉されない状態で処理する必要があります。破壊的な相互作用とは、不正確なデータの更新または基礎となるデータ構造の不正な変更を引き起こす相互作用であり、これを回避する必要があります。
Oracle AI Databaseは、ロックを使用してデータへの同時アクセスを制御します。ロックは、共有リソースにアクセスする複数のトランザクション間で、破壊的な相互作用が起きないようにするメカニズムです。ロックは、データ整合性を保証する場合に役立つ一方、データへの最大の同時アクセスを可能にします。
関連トピック
データ整合性
Oracle AI Databaseでは、各ユーザーに対して、ユーザー自身のトランザクションによる変更および他のユーザーのトランザクションのコミットによる変更を反映した、整合性のあるデータのビューが表示される必要があります。
たとえば、データベースは、あるトランザクションが別の同時トランザクションによるコミットされていない変更に遭遇した場合に発生する内容を保証しない読取りの問題を防止する必要があります。
Oracle AI Databaseでは、文レベルの読取り一貫性を常に適用することにより、1つの問合せによって戻されたデータがコミット済であり、ある時点で一貫していることが保証されます。トランザクション分離レベルに応じて、この時点は文またはトランザクションが開始されたときになります。この時点は、Oracle Flashback Query機能で明示的に指定できます。
データベースは、トランザクションのすべての問合せに対して、トランザクション・レベルの読取り一貫性と呼ばれる読取り一貫性を実現することもできます。この場合、トランザクション内の各文には同じ時点(トランザクション開始時)のデータが表示されます。
Oracle AI Databaseアーキテクチャ
データベース・サーバーは、情報管理のキーとなります。
一般的にサーバーでは、多数のユーザーが同時に同じデータへアクセスできるように、マルチユーザー環境において大量のデータが確実に管理されます。権限のないアクセスに対して保護機能を備えながら、障害のリカバリについても効率のよい解決方法を提供します。
データベースおよびインスタンス
Oracleデータベース・サーバーは、1つのデータベースと1つ以上のデータベース・インスタンス(通常は単にインスタンスと呼ばれる)で構成されます。
インスタンスとデータベースは非常に密接に関連しているため、Oracle databaseという用語が、インスタンスとデータベースの両方を示す場合があります。これらの用語の厳密な意味は次のとおりです。
-
データベース
データベースは、ディスク上に配置された、ユーザー・データを格納する一連のファイルです。これらのデータ・ファイルはデータベース・インスタンスとは別に存在できます。Oracle Database 21cから、データベースとは、具体的にはマルチテナント・コンテナ・データベース(CDB)、プラガブル・データベース(PDB)またはアプリケーション・コンテナのデータ・ファイルを指すようになりました。
-
データベース・インスタンス
インスタンスは、データベース・ファイルを管理する一連の名前付きメモリー構造です。データベース・インスタンスは、システム・グローバル領域(SGA)と呼ばれる共有メモリー領域と、一連のバックグラウンド・プロセスで構成されます。インスタンスはデータベース・ファイルとは別に存在できます。
マルチテナント・アーキテクチャ
マルチテナント・アーキテクチャを使用すると、Oracle DatabaseをCDBにすることができます。
すべてのOracleデータベースは、別のデータベースを格納しているか、別のデータベースに格納可能です。たとえば、CDBにはPDBが含まれており、アプリケーション・コンテナにはアプリケーションPDBが含まれています。PDBはCDBまたはアプリケーション・コンテナに含まれており、アプリケーション・コンテナはCDBに含まれています。
Oracle Database 21cから、マルチテナント・コンテナ・データベースがサポート対象の唯一のアーキテクチャになりました。前のリリースでは、Oracleは非コンテナ・データベース(非CDB)をサポートしていました。
CDB
CDBには、ユーザーが作成した1つ以上のPDBおよびアプリケーション・コンテナが含まれています。
物理レベルでは、CDBは制御ファイル、オンラインREDOログ・ファイルおよびデータ・ファイルの一連のファイルです。データベース・インスタンスは、CDBを構成するファイルを管理します。
次の図に、CDBおよび関連するデータベース・インスタンスを示します。
PDB
PDBは、アプリケーションに別のデータベースとして表示されるスキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトのポータブル・コレクションです。
物理レベルでは、各PDBに、そのPDBのデータを格納する独自のデータ・ファイルのセットがあります。CDBには、そこに含まれるPDBのすべてのデータ・ファイルと、CDB自体のメタデータを格納する一連のシステム・データ・ファイルが含まれます。
PDBを移動またはアーカイブするには、切断できます。切断されたPDBは、PDBデータ・ファイルおよびメタデータ・ファイルで構成されます。切断されたPDBは、CDBに接続されるまで使用できません。
次の図に、MYCDBという名前のCDBを示します。
物理的に、MYCDBは、インスタンスに関連付けられている一連のデータ・ファイルを意味するOracleデータベースです。MYCDBには、1つのデータベース・インスタンス(ただし、Oracle Real Application Clustersでは複数のインスタンスが可能)と、1つのデータベース・ファイル・セットがあります。
MYCDBには2つのPDB、hrpdbとsalespdbが含まれます。図1-2に示すように、これらのPDBは、それぞれのアプリケーションで別個の独立したデータベースとして表示されます。アプリケーションは、CDBとPDBのどちらに接続しているのかを認識しません。
CDB自体またはその中のPDBを管理するために、CDBルートに接続できます。ルートは、スキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトの集合で、すべてのPDBとアプリケーション・コンテナはこれに属します。
アプリケーション・コンテナ
アプリケーション・コンテナはオプションでCDB内にユーザーが作成したコンテナであり、1つ以上のアプリケーションのデータおよびメタデータが格納されます。
このような状況では、アプリケーション(マスター・アプリケーション定義とも呼ばれる)は、アプリケーション・ルートに格納される共通データおよびメタデータの名前付けおよびバージョニングされたセットです。たとえば、アプリケーションには一連のPDBに共通の表、ビュー、ユーザー・アカウント、PL/SQLパッケージの定義を含めることができます。
アプリケーション・コンテナはある意味で、CDB内のアプリケーション固有CDBとして機能します。アプリケーション・コンテナにはCDB自身のように複数のアプリケーションPDBが含まれ、これらのPDBはメタデータおよびデータを共有できます。物理レベルでは、アプリケーション・コンテナには、PDBと同様に独自のデータ・ファイルのセットがあります。
たとえば、SaaSデプロイメントでは、個々が別の顧客用で、アプリケーションのメタデータおよびデータを共有する複数のアプリケーションPDBを使用できます。たとえば次の図では、sales_appはアプリケーション・ルート内のアプリケーション・モデルです。cust1_pdbというアプリケーションPDBには顧客1用の販売データのみが含まれる一方、cust2_pdbというアプリケーションPDBには顧客2用の販売データのみが含まれます。接続、切断、クローニングおよびその他のPDBレベルの操作を、個々の顧客PDBで使用できます。
Globally Distributed Databaseアーキテクチャ
Oracle Globally Distributed Database (以前はOracle Shardingと呼ばれていました)は、複数のPDB間におけるデータの水平パーティション化に基づくデータベース・スケーリング技術です。アプリケーションは、PDBのプールを単一の論理データベースとして認識します。各パーティションはシャードと呼ばれます。
アプリケーションのシャーディングの主な利点には、線形スケーラビリティ、障害の封じ込め、および地理的データ分散などが挙げられます。Globally Distributed Databaseは、Oracle Cloudでのデプロイメントに適しています。シャーディングを実装するNoSQLデータ・ストアとは異なり、Globally Distributed DatabaseはエンタープライズRDBMSの機能を犠牲にすることなく、シャーディングの利点を提供します。
シャーディング・アーキテクチャでは、各CDBは、独自のローカル・リソース(CPU、メモリー、フラッシュまたはディスク)を持つ専用サーバーでホストされます。PDBはシャードとして指定できます。異なるCDBからのPDBシャードが一体的に単一の論理データベースを形成し、これはシャード・データベースと呼ばれます。同じCDB内の2つのシャードは、同じシャード・データベースのメンバーにはできません。ただし、同じCDB内で、1つのPDBが1つのシャード・データベース内に存在し、別のPDBが別のシャード・データベースに存在することはできます。
水平パーティション化にはシャード間のデータベース表の分割が伴い、これによって各シャードには、列は同じですが行は異なるサブセットを持つ表が含まれます。この方法で分割された表はシャード表とも呼ばれています。次の図は、3つのシャード間で水平パーティション化されたシャード表を示しており、各シャードはそれぞれ別のCDB内にあるPDBです。
ユースケースの1つは、複数のCDBへの顧客アカウント・データの分散です。たとえば、IDが28459361の顧客が自身のレコードを検索するとします。次の図に、考えられるアーキテクチャを示します。顧客のリクエストは、接続プールを介してルーティングされます。接続プールでは、シャード・ディレクタ(ネットワーク・リスナー)がリクエストをすべての顧客の行が含まれている適切なPDBシャードに送信します。
図1-5 Oracle Globally Distributed Databaseアーキテクチャ

「図1-5 Oracle Globally Distributed Databaseアーキテクチャ」の説明
データベース記憶域構造
データベースは、物理的な観点と論理的な観点の両方から検討できます。
物理データとは、オペレーティング・システム・レベルで表示可能なデータです。たとえば、Linuxのlsやpsなどのオペレーティング・システム・ユーティリティは、データベース・ファイルおよびプロセスをリスト表示できます。表などの論理データは、データベースに対してのみ意味を持ちます。Oracle Database内の表はSQL文でリスト表示できますが、オペレーティング・システム・ユーティリティでは表示できません。
データベースには物理構造と論理構造があります。物理構造と論理構造は分離されているため、論理記憶構造へのアクセスに影響を与えずに、データの物理記憶域を管理できます。たとえば、物理データベース・ファイルの名前を変更しても、このファイルにデータが格納されている表の名前は変更されません。
物理記憶域構造
物理データベース構造とは、データを格納するファイルです。
CREATE DATABASEコマンドを実行してCDBを作成します。次のファイルが作成されます。
-
データ・ファイル
すべてのCDBには、すべてのデータベース・データを含む1つ以上の物理データ・ファイルがあります。表や索引などの論理データベース構造のデータは、データファイルに物理的に格納されます。
-
制御ファイル
すべてのCDBには、制御ファイルがあります。制御ファイルには、データベース名やデータベース・ファイルの名前と位置など、データベースの物理構造を指定したメタデータが含まれています。
-
オンラインREDOログ・ファイル
すべてのCDBには、2つ以上のオンラインREDOログ・ファイルのセットからなるオンラインREDOログがあります。オンラインREDOログは、データに加えられた変更をすべて記録するREDOエントリ(REDOログ・レコードとも呼ばれる)で構成されています。
CDB内でCREATE PLUGGABLE DATABASEコマンドを実行してPDBを作成します。PDBには、CDB内の専用のデータ・ファイル・セットが含まれています。PDBには、それぞれ専用の制御ファイルとオンラインREDOログはありません。これらのファイルはPDBで共有されます。
CDBが機能するために重要なその他多くのファイルがあります。これらには、パラメータ・ファイルやネットワーキング・ファイルが含まれます。バックアップ・ファイルとアーカイブREDOログ・ファイルは、バックアップおよびリカバリに重要なオフライン・ファイルです。
論理記憶域構造
論理記憶域構造によって、Oracle AI Databaseのディスク領域の使用をきめ細かく制御できます。
このトピックでは、論理記憶域構造について説明します。
-
データ・ブロック
最少レベルとして、Oracle AI Databaseのデータはデータ・ブロックに格納されます。1つのデータ・ブロックは、ディスク上の特定のバイト数に対応します。
-
エクステント
エクステントは、1回の割当てで取得される特定数の論理的に連続したデータ・ブロックで、特定タイプの情報の格納に使用されます。
-
セグメント
セグメントは、ユーザー・オブジェクト(表や索引)、UNDOデータ、または一時データに割り当てられるエクステントの集合です。
-
表領域
データベースは、表領域と呼ばれる論理記憶域の単位に分割されます。表領域はセグメントの論理コンテナです。各表領域は1つ以上のデータ・ファイルで構成されます。
関連トピック
データベース・インスタンス構造
Oracleデータベースは、メモリー構造とプロセスを使用してCDBの管理やアクセスを行います。すべてのメモリー構造は、RDBMSを構成するコンピュータのメイン・メモリー内に存在します。
アプリケーションがCDBまたはPDBに接続すると、データベース・インスタンスに接続されます。インスタンスは、SGAのみでなくその他のメモリー領域も割り当て、バックグラウンド・プロセスの他のプロセスも起動して、アプリケーションに対応します。
Oracle AI Databaseのプロセス
プロセスは一連のステップを実行できるオペレーティング・システムのメカニズムです。オペレーティング・システムによっては、「ジョブ」、「タスク」または「スレッド」という用語を使用します。
このトピックの目的では、スレッドはプロセスと同等です。Oracleデータベース・インスタンスには次のタイプのプロセスがあります。
-
クライアント・プロセス
これらのプロセスは、アプリケーション・プログラムまたはOracleツールのソフトウェア・コードを実行するために作成およびメンテナンスされます。ほとんどの環境ではクライアント・プロセス用に独立したコンピュータが使用されます。
-
バックグラウンド・プロセス
これらのプロセスは、各クライアント・プロセスごとに実行されている複数のOracle AI Databaseプログラムが処理する機能を1つにまとめます。バックグラウンド・プロセスは、非同期的にI/Oを実行して他のOracle AI Databaseプロセスを監視することによって、並列性を高め、パフォーマンスと信頼性を向上させます。
-
サーバー・プロセス
これらのプロセスは、クライアント・プロセスと通信し、Oracle AI Databaseと対話してリクエストに対応します。
Oracleプロセスには、サーバー・プロセスとバックグラウンド・プロセスがあります。ほとんどの環境では、Oracleプロセスとクライアント・プロセスは別々のコンピュータ上で実行されます。
関連トピック
インスタンスのメモリー構造
Oracle AI Databaseでは、プログラム・コード、ユーザー間で共有されるデータ、および接続している各ユーザーのプライベート・データ領域のために、メモリー構造が作成および使用されます。
次のメモリー構造がデータベース・インスタンスに関連付けられています。
-
システム・グローバル領域(SGA)
SGAは、共有メモリー構造のグループであり、1つのデータベース・インスタンスに関するデータと制御情報が含まれています。SGAコンポーネントの例として、データベース・バッファ・キャッシュや共有SQL領域があります。SGAには、オプションのインメモリー列ストア(IM列ストア)を含めることができ、これにより、列形式でデータをメモリーに移入できます。
-
プログラム・グローバル領域(PGA)
PGAは、サーバー・プロセスまたはバックグラウンド・プロセス用のデータや制御情報を含むメモリー領域です。PGAにアクセスできるのはプロセスのみです。それぞれのサーバー・プロセスおよびバックグラウンド・プロセスには専用のPGAがあります。
関連トピック
アプリケーションおよびネットワークのアーキテクチャ
特定のコンピュータ・システムまたはネットワークを最大限に活用できるように、Oracle AI Databaseではデータベース・サーバーとクライアント・プログラムの間で処理を分割できます。RDBMSを実行しているコンピュータはデータベース・サーバーの処理を実行し、アプリケーションを実行しているコンピュータはデータの解釈と表示を行います。
アプリケーション・アーキテクチャ
アプリケーション・アーキテクチャは、データベース・アプリケーションがOracleデータベースに接続されているコンピューティング環境です。データベースの最も一般的なアーキテクチャは、クライアント/サーバーと複数層の2種類です。
クライアント・サーバー・アーキテクチャ
クライアント/サーバー・アーキテクチャでは、クライアント・アプリケーションは、データベース・サーバー上で実行される操作に関するリクエストを開始します。サーバーは、Oracle AI Databaseソフトウェアを実行し、同時実行の共有データ・アクセスに必要な機能を処理します。サーバーは、クライアントから発行されたリクエストを受け取って処理します。
複数層アーキテクチャ
複数層アーキテクチャでは、1つ以上のアプリケーション・サーバーが操作の各部分を実行します。アプリケーション・サーバーには、アプリケーション・ロジックの大部分が含まれ、クライアントのデータ・アクセスを可能にし、いくつかの問合せ処理を実行します。この方法で、データベースの負荷が軽減します。アプリケーション・サーバーは、クライアントと複数のデータベース間のインタフェースとして機能し、セキュリティ・レベルを高める役割を果します。
サービス指向アーキテクチャ(SOA)は、アプリケーション機能がサービスにカプセル化されている複数層アーキテクチャです。通常、SOAサービスはWebサービスとして実装されます。WebサービスはHTTP経由でアクセス可能なサービスであり、Webサービス記述言語(WSDL)やSOAPなどのXMLベースの規格に基づいています。Oracle AI Databaseは、従来の複数層またはSOA環境においてWebサービス・プロバイダとして機能できます。
Simple Oracle Document Access (SODA)は、データベースに格納されたデータへのアクセスを可能にするSOAのアダプタです。SODAは、リレーショナル・データベース機能やSQLおよびPL/SQLなどの言語に関する知識を使用しないスキーマレス・アプリケーション開発向けに設計されています。Oracle AI Databaseでは、ドキュメントがどのように格納されているかを把握しなくても、ドキュメント・コレクションの作成および格納や、それらのドキュメントの取得および問合せの実行を可能にします。RESTのためのSODAは、Representational State Transfer (REST)アーキテクチャ・スタイルを使用してSODAを実装します。
Oracle Net Servicesのアーキテクチャ
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を構成する最も一般的な方法は、次のとおりです。
-
専用サーバー・アーキテクチャ
各クライアント・プロセスは、専用サーバー・プロセスに接続します。サーバー・プロセスは、クライアントのセッションの継続中、その他のどのクライアントとも共有されません。それぞれの新規セッションに専用サーバー・プロセスが割り当てられます。
-
共有サーバー・アーキテクチャ
データベースは複数のセッションに対して共有サーバー・プロセスのプールを使用します。クライアント・プロセスはディスパッチャと通信し、ディスパッチャは、クライアントごとに専用のサーバー・プロセスがなくても多数のクライアントが同じデータベース・インスタンスに接続できるようにするプロセスです。



