ホームページ > 記事 > データベース > Oracle アーキテクチャの簡単な分析

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

WBOY転載: 2022-07-22 16:51:371695ブラウズ

この記事では、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 つの部分が含まれています。

データディクショナリキャッシュ: データベースで使用する重要なデータディクショナリ情報を保存します。

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

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

サーバー結果キャッシュ: サーバー側の SQL 結果セットと PL/SQL 関数の戻り値を保存します。

上記の説明を読むと、少し抽象的だと思われるかもしれませんので、以下に例を挙げて説明します。

コマンドがクライアントで次のように送信されるとします:

SELECT ename，sal FROM emp WHERE empno=7788;

このステートメントが初めてデータベースに送信される場合は、解析する必要があります。解析プロセスは次のように分割されます。ハード解析とソフト解析。

ソフト解析: 実行計画に従って具体的に実行します。。 select 文の場合は実行後に結果セットが返されますが、update 文や delete 文の場合は結果セットを返す必要はありません。

ライブラリキャッシュは、この SQL ステートメントと実行プランをそこにロードします。

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

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

select ename，sal from emp where empno=7788；

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

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

前述したように、select ステートメントの場合、実行後に結果セットが返されます。結果セットはどこに保存されますか?

select ename，sal from emp where empno=7788；

このステートメントの実行によって返された結果セットは、サーバー結果キャッシュに保存されます。

2) データベースバッファキャッシュ

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 接続

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

1. 最初に TCP 接続を確立し、オラクルはユーザーの ID を認証し、セキュリティ監査などを実施します;

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

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

図 5 接続とセッション

Background Process (バックグラウンドプロセス) には、主に SMON (システム監視プロセス)、PMON (プロセス監視プロセス) が含まれます。 ) サーバープロセス)、DBWR (データベースライタープロセス)、LGWR (ログライタープロセス)、CKPT (チェックポイントプロセス)。

1) PMON (プロセス監視)

PMON の主な機能は以下のとおりです。

アイドルセッションがしきい値に達するかどうかを監視します。
モニタリングのための動的登録。

2) SMON (システムモニター)

SMON の主な機能は次のとおりです。

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

3) DBWR (データベースライター)

DBWn は、Oracle で最も重い作業プロセスです。主な機能は次のとおりです。

データバッファキャッシュスペースを解放します。

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

注: 次の状況が発生すると、DBWR プロセスがトリガーされ、データベースバッファキャッシュの内容がデータファイルに書き込まれます:

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

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

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

4) LGWR ((LOG Writer))

Oracle インスタンスには LGWR プロセスが 1 つだけあり、このプロセスの動作は DBWR プロセスと似ています。主な機能は次のとおりです。

REDO ログバッファの内容を REDO ログファイルに書き込みます (ログは、DBWR がダーティブロックを書き込む前に書き込む必要があります)。

(Redo Log Buffer は循環バッファであり、対応する Redo Log Files も循環ファイルグループです。ファイルの先頭から書き込みを開始します。ファイルがいっぱいになると、ファイルの先頭から書き込みを開始します。もう一度実行すると、前の内容が上書きされます。REDO ログファイルの上書きを避けるために、アーカイブ REDO ログファイルに書き込むことを選択できます。)

注: 次の状況が発生した場合、 LGWR プロセスがトリガーされて、REDO ログファイルが保存されます。バッファ内の内容が REDO ログファイルに書き込まれます:

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

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

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

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

チェックポイントを生成し、DBWR にダーティブロックを書き込むように通知または促します。 ;
*完全なチェックポイント: データの一貫性を確保します。

6) ARCn (アーカイバ)

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

ARCn の主な機能は次のとおりです。

Oracle がアーカイブモードで実行されている場合、

ARCn プロセスは、ログが再利用される前に REDO ログファイルを自動的にアーカイブするため、データベースに加えられたすべての変更が保持されます。

これにより、ディスクドライブが損傷した場合でも、データベースを障害点まで復元できます。

上記の学習を通じて、まず図 1 を次のように更新します。

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

Database

Database は実際には、主にデータの保存に使用される物理ファイルの束で構成されており、主にデータファイル、制御ファイル、REDO ログファイルの 3 種類のファイルが含まれています。

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

1) データファイル

データファイルはデータの保存に使用され、テーブル内のデータはデータファイルに保存されます。

2) 制御ファイル

データファイルを操作するために、Oracle は主にデータベースの制御情報を記録するいくつかの制御ファイルを提供しています。

3) REDO ログファイル (REDO ログファイル)

REDO ログファイルは、データベース内の変更を記録します。データベースにデータを入力したり、データベース内のデータを変更したりする場合は、操作を実行するだけで済みます。変更を行った場合は、データファイルを復元する機能を持つREDOログファイルに変更前のステータスと変更後のステータスを記録する必要があります。

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

4) パラメータファイル

どのデータベースにもパラメータファイルが必要です。このパラメータファイルは、Oracle のいくつかの基本パラメータと初期化パラメータの値を指定します。

5) アーカイブログファイル

アーカイブログファイルと REDO ログファイルは相互に補完します。REDO ログファイルは、実際には繰り返し使用されるプロセスです。いくつかの (通常 (3) 個の) 固定ファイルが存在します。これらの固定ファイルは順番に使用され、ファイルがいっぱいになると、Oracle はファイルヘッダーを再度書き込み、前のファイルをフラッシュします。データベースのバックアップおよびリカバリ機能をさらに強化するために、これらの変更された情報は上書きされる前にアーカイブログファイルにアーカイブされます。

6) パスワードファイル

ユーザークライアントがバックエンドデータベースシステムに接続するときにパスワードを保存します。

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

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

小さな補足:

Oracle のメモリ構造

Oracle のメモリ構造には、実際には SGA と PGA の 2 つの部分が含まれています

SGA（システムグローバルエリア）

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 サイトの他の関連記事を参照してください。

Java sql select Session 循环堆 delete 对象 background table oracle database 数据库 dba

声明：

この記事はjb51.netで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。

前の記事：Oracle 12c での SQLPlus 操作の使用法の概要次の記事：Oracle 12c での SQLPlus 操作の使用法の概要

続きを見る