Oracle アーキテクチャの簡単な分析

この記事では、Oracle に関する関連知識を提供します。主にアーキテクチャに関連する問題を整理します。Oracle のアーキテクチャは、一般にインスタンス (インスタンス) とデータベース (データベース) の 2 つの部分に分かれています。見てみましょう皆さんのお役に立てれば幸いです。

推奨チュートリアル: 「Oracle ビデオ チュートリアル 」

Oracle のアーキテクチャは、通常 2 つの部分に分かれています: インスタンス (インスタンス) および データベース (データベース) 。

図 1 に示すように:

図 1 Oracle データベースのアーキテクチャ

通常、Oracle サーバーと呼ばれるもの (Oracle サーバー) は、図 2 に示すように、Oracle インスタンスと Oracle データベースで構成されます。

図 2 Oracle サーバー

Oracle インスタンスインスタンスには、主に SGA と一部のバックグラウンド プロセス (例: PMON、SMON、DBWR、LGWR、CKPT など)。

SGA

SGA には 6 つの基本コンポーネントが含まれています: 共有プール (ライブラリ キャッシュ、データ ディクショナリ キャッシュ)、データベース バッファ キャッシュ、REDO ログ バッファ、Java プール、ラージ プール、ストリーム プール。

これら 6 つの基本コンポーネントの機能を以下に紹介します。

1) 共有プール

• 共有プールは、SQL および PL/SQL プログラムの構文分析、コンパイル、実行のためのメモリー領域です。
• 共有プールは、ライブラリ キャッシュ (ライブラリ キャッシュ)、データ ディクショナリ キャッシュ (データ ディクショナリ キャッシュ)、およびサーバー結果キャッシュ (結果キャッシュ) で構成されます。

それぞれの機能は何ですか?

ライブラリ キャッシュ: SQL および PL/SQL の解析場所。コンパイルおよび解析された SQL および PL/SQL 文の内容が保存され、すべてのユーザーが共有できます。
## 次回同じ SQL ステートメントが実行される場合、解析する必要はなく、ライブラリ キャッシュから即座に実行されます。

* ライブラリ キャッシュのサイズによって SQL ステートメントのコンパイルと解析の頻度が決まり、それによってパフォーマンスが決まります。

* ライブラリ キャッシュには、共有 SQL 領域と共有 PL/SQL 領域の 2 つの部分が含まれています。

* データ ディクショナリは最も頻繁に使用され、ほとんどすべての操作でデータ ディクショナリへのクエリが必要です。データディクショナリへのアクセス速度を向上させるために、この時点でキャッシュが必要となり、必要なときにメモリにアクセスできるようになります。

* データ ディクショナリ キャッシュ内の情報には、データベース ファイル、テーブル、インデックス、列、ユーザー、権限、その他のデータベース オブジェクトが含まれます。

SELECT ename，sal FROM emp WHERE empno=7788;

ハード解析: 構文、セマンティクス、権限を確認し、バインド変数などを分析し、最終的に実行計画を生成します;
ソフト解析: 実行計画に従って具体的に実行します。 。 select 文の場合は実行後に結果セットが返されますが、update 文や delete 文の場合は結果セットを返す必要はありません。

これらのものをロードする目的は何ですか?
次回まったく同じステートメント (句読点、大文字、スペースがまったく同じ) を入力するときは、ハードな解析は必要ありません。

簡単な Q&A: クライアントがこの時点で別のコマンドを送信した場合:

select ename，sal from emp where empno=7788；

このステートメントを解析する必要があると思いますか? 答え: はい。

小さな注意: 解析を避けるには、ステートメントがまったく同じである必要があることに注意してください。句読点、大文字、スペースなどはまったく同じである必要があります。定期的に文章を書くことの利点がここに反映されています。

select ename，sal from emp where empno=7788；

• Database Buffer Cache用于存储从磁盘数据文件中读入的数据，为所有用户共享。
• Server Process（服务器进程)将读入的数据保存在数据缓冲区中，当后续的请求需要这些数据时可以在内存中找到，则不需要再从磁盘读取。

小说明：逻辑读（从内存读）的速度是物理读（从磁盘读）的1万倍呦，所以还是想办法尽量多从内存读哦。
所以，数据缓冲区的大小对数据库的读取速度有直接的影响。

例如用户访问一个表里面的记录时，数据库接收到这个请求后，首先会在Database Buffer Cache中查找是否存在该数据库表的记录，如果有所需的记录就直接从内存中读取该记录返回给用户（有效提升了访问的速度），否则只能去磁盘上去读取。

继续看上面的例子：

select ename，sal from emp where empno=7788；

该条语句以及它的执行计划被放在Library Cache里，但语句涉及到的数据，会放在 Database Buffer Cache 里。

小问答：
Database Buffer Cache是怎么工作的呢？

这就要说一说Database Buffer Cache的设计思想了。
磁盘上存储的是块（block），文件都有文件号，块也有块号。
若要访问磁盘上的块，并不是CPU拿到指令后直接访问磁盘，而是先把块读到内存中的Database Buffer cache里，生成副本，查询或增删改都是对内存中的副本进行操作。如图3所示。
另外，如果是增删操作，操作后会形成脏块，脏块会在恰当时机再写回磁盘原位置，注意哦，可不是立刻写回呦。

也许你会问，为什么不立刻写回呢？
因为:
（1）减少物理IO；
（2）可共享，若后面又有对该块的访问，可直接在内存中进行逻辑读。

图3 访问数据块

小问答：
为什么要通过内存访问数据块，而不是CPU直接访问磁盘呢？
答：因为相较于CPU，IO的速度实在是太慢了，CPU的速度是IO 的100万倍呢？如果CPU直接访问磁盘的话，会造成大量的IO等待，CPU的利用率会很低。所以，利用速度相当的内存（CPU速度为内存的100倍）做中间缓存，可以有效减少物理IO，提高CPU利用率。

但是，这里会有一个问题。前面说到查询或增删改都是对内存中的副本进行操作，当增删改操作产生脏块时不会立刻写回磁盘。

小问答：
我们设想一下，如果在 Database Buffer Cache 中存放大量未来得及写回磁盘的脏块时，突然出现系统故障（比如断电），导致内存中的数据丢失。而此时磁盘中的块存放的依然是修改前的旧数据，这样岂不是导致前面的修改无效？
要怎样保持事务的一致性呢？
答：如果我们能够保存住提交的记录，在 Database Buffer Cache 中一旦有数据更改，马上写入一个地方记录下来，不就可以保证事务一致性了嘛。

小说明：Instance在断电时会消失，Instance在内存中存放的数据将丢失。这就需要 Redo Log Buffer 发挥它的作用啦。

3）Redo Log Buffer

• 日志条目（Redo Entries ）记录了数据库的所有修改信息(包括 DML 和 DDL）,一条Redo Entries记录一次对数据库的改变 ，为的是数据库恢复。
• 日志条目首先产生于日志缓冲区。日志缓冲区较小，它是以字节为单位的，它极其重要。
• 在Database Buffer Cache中一旦有数据更改，马上写入Redo Log Buffer，Redo Log Buffer在内存中保留一段时间后，会写入磁盘，然后归档（3级结构）。

4）Large Pool（可选）

为了进行大的后台进程操作而分配的内存空间，与 shared pool 管理不同，主要用于共享服
务器的 session memory，RMAN 备份恢复以及并行查询等。

5）Java Pool(可选）

为了 java 虚拟机及应用而分配的内存空间，包含所有 session 指定的 JAVA 代码和数据。

6）Stream Pool（可选）

为了 stream process 而分配的内存空间。stream 技术是为了在不同数据库之间共享数据，
因此，它只对使用了 stream 数据库特性的系统是重要的。

Background process

在正式介绍 Background Process 之前，先简单介绍 Oracle 的 Process 类型。

Oracle Process 有三种类型：

• User Proces
  

客户端要与服务器连接，在客户端启动起来的进程就是 User Process，一般分为三种形式（sql*plus, 应用程序，web 方式（OEM））。

• サーバー プロセス
  

ユーザー プロセスは Oracle に直接アクセスできません。対応するサーバー プロセスを通じてインスタンスにアクセスしてから、データベースにアクセスする必要があります。
ユーザーが Oracle サーバーにログインすると、ユーザー プロセスとサーバー プロセスが接続を確立します。

• バックグラウンド プロセス
  

Oracle インスタンスの重要な部分。これについては次に詳しく説明する。

ちょっとした追加:
接続とセッション
接続とは、Oracle クライアントとバックグラウンドおよびバックグラウンド プロセス (サーバー プロセス) によって確立された TCP 接続を指します。図 4 に示すように:

図 4 接続

接続確立プロセスは次のように簡単に説明できます。

2. これらが合格すると、オラクルのサーバー プロセスは、クライアントが提供するサービスを使用できるようにします。 Oracle;
3. Oracle 接続が確立されるとセッションが開始され、接続が切断されるとセッションは消滅します。

セッションと接続は相互に補完します。セッション情報は Oracle のデータ ディクショナリに保存されます。 図 5 を見ると、接続とセッションの違いが視覚的にわかります。

Oracle の各バックグラウンドプロセスが正常かどうかを監視し、異常なプロセスを削除します。見つかった場合は、プロセスを再生成します。
• 
  
(注: ユーザー プロセスが切断されたときに、サーバー プロセスが残っていると役に立ちませんが、それでもスペースを占有します。PMON はサーバー プロセスを定期的にチェックします。サーバー プロセスに接続できない場合は、ユーザー プロセス、PMON はサーバー プロセス、PGA スペース、および内部のロックを再利用します。)
• アイドル セッションがしきい値に達するかどうかを監視します。
• モニタリングのための動的登録。

Oracle が実行中に突然クラッシュすると、インスタンスがリカバリ (インスタンスリカバリ)、SMON はインスタンスリカバリの完全な監視を担当します;
• Oracle が実行中に突然クラッシュすると、次回 Oracle インスタンスが起動されるときに、その未解放のリソースの一部が失われます。 SMON によってクリーンアップされる;
• 一部のトランザクションが失敗した場合、SMON もそれをクリーンアップします; メモリ空間が非常に分散している (不連続な) 場合、SMON は分散している空間を統合する必要があります;
• リリース使用されなくなった一時的なセグメント (セグメント)。

データベース バッファ キャッシュ内のダーティ ブロック (ダーティ バッファ) をデータ ファイルに書き込みます。
• データ バッファ キャッシュ スペースを解放します。

ちょっとした注意: データベースの負荷が比較的大きく、クライアントからのリクエストが多く、IO 操作が多数ある場合は、バッファの内容をファイルに頻繁に書き込まれる場合、この時点で複数の DBWn を構成できます (Oracle は、合計 20 個の DBWn、DBW0 ～ DBW9、DBWa ～ DBWg をサポートします)。通常、中小規模の Oracle では、DBW0 プロセスが 1 つだけ必要になります。

チェックポイントが発生します
ダーティ バッファー到達しきい値
• 空きバッファーがありません
• タイムアウトが発生しました
• RAC ping リクエストが行われました
• テーブルスペースがオフラインです
• Tablespace READ ONLY
• Table DROP または TRUNCATE
• Tablespace BEGIN
• BACKUP

ちょっとした追加: サーバー プロセスDBWR はデータ ファイルの読み取り操作を実行し、DBWR はデータ ファイルに対する書き込み操作を実行します。

簡単な Q&A: DBWR はコミット時に何をしますか?
答え: 何もしないでください。

• コミット時
• 3分の1がいっぱいになったとき
• 1MBのREDOがあるとき
• 3秒ごと
• DBWnが書き込む前

送信されたトランザクションが永久に保持されるようにするにはどうすればよいですか?
回答: 更新操作は例として実行されました。
1. コミット ステートメントを作成すると、変更が Redo ログ バッファに書き込まれます;
2. 送信が成功したことが示されると、変更がディスク REDO ログファイルに書き込まれたことを意味します。
3 . したがって、送信が成功すると、変更はディスクに同期され、失われることはありません。

5) CKPT (チェックポイント)

CKPT の主な機能は次のとおりです:

• チェックポイントを生成し、DBWR にダーティ ブロックを書き込むように通知または促します。 ;
• *完全なチェックポイント: データの一貫性を確保します。
##増分チェックポイント: 制御ファイル内のチェックポイントの場所を継続的に更新し、インスタンスのクラッシュが発生した場合、インスタンスの回復時間を可能な限り短縮できます。データ ファイルのファイル ヘッダーのチェックポイント情報を更新し、制御ファイルのチェックポイント情報を更新します。

ARCn は、オプションのバックグラウンド プロセスです (ほぼ必須プロセスとみなされます)。
• Oracle は、ARCHIVELOG MODE (アーカイブ モード) と NOARCHIVELOG MODE (非アーカイブ モード) の 2 つのモードで実行できます。
• DBA が行う必要がある重要な決定は、データベースを ARCHIVELOG モードで実行するように構成するか、NOARCHIVELOG モードで実行するように構成するかです。
• オンライン REDO ログ ファイルがいっぱいになると、Oracle インスタンスは次のオンライン REDO ログ ファイルの書き込みを開始します。
• あるオンライン REDO ログ ファイルから別のオンライン REDO ログ ファイルに切り替えるプロセスは、ログ切り替えと呼ばれます。

ARCn プロセスは毎回ログインを開始します。ログを切り替えます。バックアップまたはアーカイブ用にログ グループを埋めます。
• ARCn プロセスは、ログが再利用される前に REDO ログ ファイルを自動的にアーカイブするため、データベースに加えられたすべての変更が保持されます。

その他、パラメータファイル、パスワードファイル、達成ログファイルなどがあります。

# たとえば、データベース内に送信する必要のあるトランザクションがありますが、送信が失敗するとトランザクションはロールバックされ、トランザクション ロールバックの基礎は REDO ログ ファイルから取得されます。 REDOログファイルにはデータベースの変更が記録されており、このトランザクション変更についてロールバックが必要な場合は、REDOログファイルのデータを取り出し、REDOログファイルのデータをもとにデータファイルを変更前の状態に戻す必要があります。

簡単な質問と回答: インスタンスとデータベースの対応関係は何ですか?

答え: インスタンス: データベース = n: 1
1 インスタンスは 1 つのデータベースにのみ所属でき、複数のインスタンスが同時に 1 つのデータベースにアクセスできます。

Oracle のメモリ構造

• Oracle インスタンスは SGA に対応します。SGA は、Oracle インスタンスの起動時に割り当てられます。SGA は、Oracle インスタンスの基本コンポーネントです。
• Oracle インスタンスには SGA が 1 つだけあります。SGA は非常に大きなメモリ領域であり、物理メモリの 80% を占有することもあります。

PGA (プログラム グローバル エリア)

• PGA は、サーバー プロセスの開始時に割り当てられます。 Oracle インスタンスには多数の PGA が存在する可能性があります。たとえば、10 個のサーバー プロセスを開始すると、10 個の PGA が存在します。
• PGA は、ユーザー カーソル、変数、コントロール、データの並べ替え、およびハッシュ値を保存します。
• SGA とは異なり、PGA は独立しており、共有されません。プロセスに割り当てられ、そのプロセス専用のメモリ領域です。

推奨チュートリアル: 「Oracle ビデオ チュートリアル 」

以上がOracle アーキテクチャの簡単な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。