バッファ・キャッシュ
役割：データキャッシュでDBF
例：繰り返しの訪問と同じテーブルのBの可能性が大きい、物理IOが、これはデータベースのパフォーマンスにつながる、あなたがDBFを訪問するたびに起きようが非常に低く、
この例では、プロセスはDBFにアクセスする際に、サーバー・プロセスは、第1のデータは、DBFから、存在しない場合は、逆に、見返りにバッファ・キャッシュから直接クライアントを読んで、データがある場合は、テーブル内のデータを検索するために、バッファキャッシュ行きます検索では、バッファキャッシュにDBFから取り出したデータには、その後、バッファキャッシュから読み取ります。
重要：サーバーのプロセスデータが読み込まれると、バッファ・キャッシュを探しに行きます
論理的および物理的なIO IO
論理IOは---論理読み取り：サーバプロセスが直接データを読み出す（メモリ読み出し）バッファキャッシュから
物理的な物理IOは---読み：サーバプロセスがディスクから（ディスク読み込み）データを読みます
論理的には、物理的リードより大きく読み取り、さらにデータベースの読み取り速度を向上させます
射撃
L / L + Pを読み出し論理/物理的、論理リード+を読み出し
ヒット率：より多くの論理読み取りよりも、物理的には少し良く読み込み---
ヒット率：少ない論理読み取り、物理的には、複数の読み込み
ヒット率は、データベースが問題を持っている必要があり、低いが、ヒット率は問題なく、必ずしもではありません
例：Pを想定= L = 90 000 = 90 000 10 000次にヒット/ LとPが高い90000 + 10000、が、高いPサーバのパフォーマンスの結果は、ヒット率が必ずしも良好ではないように減少されます
裁判官の良いか悪いかに読んで短い包括的な物理的ヒットを必要と2で
サーバープロセス
サーバプロセスデータを変更し、第一データテーブルが必要なバッファ・キャッシュに読み込まれ、メモリ内のテーブルにサーバプロセスの変更は、変更時間は、ログを持つことになり、ログは、この中でredoログバッファに書き込まれますデータメモリとデータDBFは同じではありません。
サーバー・プロセスは、redoログバッファ生成されたログに書き込まれているメモリ内のデータを変更し、メモリにデータを読み込むための責任がある、それが戻ってディスクに変更されたデータを記述するための責任を負いません、それがディスクに書き込まれたログについては責任を負いません
SQL文の実行プロセス
SQL --->サーバープロセス---> ---解決>実施計画--->データをフェッチ
バックグラウンドプロセス
これは、バックグラウンドプロセスの機能：ユーザーが感じません
注：データベースの最適化フォーカス嘘のサーバー・プロセスは、サーバープロセスの反応速度は、データベースの速度を表しますので、
忙しいバックグラウンドプロセス、限り迅速かつ容易に、ユーザーが迅速かつ容易に感じることがserverprocessとして、ユーザーが迅速にデータベースを感じることがどのように関係なく、バックグラウンド・プロセスは、私たちの理想の結果である、非常に忙しいかもしれません。
（1）のDBWn ---メモリライトバックDBFのデータ（ディスク）
（2）LGWR --- redoログバッファがログにログ・ファイルに書き込まれ
（3）---周期チェックポイント処理は、状態情報は、データファイルは、各データファイル情報のヘッドの状態を記録しているデータベースヘッダー制御ファイルとデータファイルに書き込まれ実行されます
破片の統合の共有プールの維持のためのデータベースインスタンスの（4）SMON ---主の中では、データベース・インスタンスは内部の清掃やメンテナンスを担当し、（システムモニタ）、内部SGAの維持されるように
一例として
、共有SQL文を入れてプールし、実施計画の
使用に長い時間、破片の多くがあるかもしれません。
その後SMonitorは、これらの断片を統合します。
SMonitor内部データベースインスタンスは、清掃や保守を担当していること
（5）PMONは---家の外、メンテナンスとクリーンアップのためのサーバプロセス上で、不要なサーバー・プロセス（プロセスモニター）をクリーンアップ
例
お客様のネットワークが突然遮断し、serverprocessは、ユーザーに開始することがあります。
PMonitorは定期的に、開始します
、それに対応する顧客はすでに死んで見つけるserverprocessを開始した後、
彼はserverprocessをクリーンアップするでしょう。
このプロセスオフserverprocessを含む
PGAメモリ空間に対応するこのserverprocess、それを放棄します。
（6）のARCnアーカイブ・ログ・プロセス
Oracleは、ログファイルをたくさん持っているが、唯一の神託を維持することができる3つのグループ、ログ神託の最初のセットを使用する最初までログ、日記内、最初のログレコードが完了するまで、2番目のログ・ファイル・レコードに下る、最初に2つのグループは、完全に第三のセットを用いて、記録され、第三のグループがいっぱいになったとき、最初のセットを回します。カバーされた時間の最初のセットを置きます。
Oracleはログのみの3セットの最大は、より多くのログを保持するために保持することができますので、Oracleはアーカイブの動作モードを持っています。
ログの書き込みの最初のセットで満たさ今回
オラクルはのARCnと呼ばれるプロセスを開始します。
このプロセスは、他のA名、下に行くには別のディレクトリにアーカイブファイルを記録します
大きさ、そしてそれは同じです。
そして、2番目のログログファイルの書き込みを開始し、時間の3分の2番目いっぱいのカットは、
このプロセスは、第二のログのアーカイブログがそのディレクトリまで書かれています。
次いで、3番目、4番目を書きます。
この位置を提出するには、
ログオラクルのすべての保持
我々は古いデータを探していると、アーカイブから古いログを検索します。
バッファ・キャッシュブロック
これは、4つのカテゴリに分けることができます。
（1）クリーン：メモリとディスクのデータの一貫性
（2）ダーティ：メモリとディスクのデータの不整合
（3）無料または未使用
（4）が接続されている：データは、生のpingであります
詳細：
DBFは、メモリSGA内のデータ読み込み
buffercacheにデータやディスクのdbfファイルを、一貫性のある
データがクリーンであると呼ばれます。
いくつかのメモリ空間は使用せずにもあり、
アイドル状態または未使用です。
そこでは、このブロックの上にあり
、それはデータを変更する内serverprocessは、メモリ内の
データを内部のメモリには、ディスク上のデータが一致しません。
この場合、メモリ内のデータは、ダーティデータと呼ばれます。
あなたはDBFファイルに書き戻す必要があるダーティデータ。
タリアとは、一貫性のあるきれい、とにデータを書き込むために後で戻ってきます。
内部メモリ内のデータがあり
、現在serverprocessそれが読まれるか、それを書くされ
た瞬間は、ピンブロックがライブに呼ばれていることを。
翻訳は接続と呼ばれます。
書き込み後すぐにダーティデータとなりました。
PINは、読み書き、する瞬間です
読み取りと書き込みのメモリ瞬間速度は非常に高速です。
ピンは、ライブに接続されています。
データベースの操作では、
ゆっくりと、使用されてbuffercache
無料、きれい、データブロック汚い内
再び時間のメモリに転送DBFデータは、それがアイドル状態と未使用の使用よりも優先されます。
すべてのデータがbuffercache場合に使用されている、アイドルが存在しない、
それはそれからきれいに使用しています。
そのため、ディスクが1を持っており、それが同じデータであることをクリーンなデータ手段。
だから、新しいデータが上書きされたクリーンなブロックすることができます。
再びクリーン元のデータ・ブロックをメモリに、元のデータ、きれいにする必要があります。
面でそのbuffercache
クリーンまたはフリーのデータは、メモリのデータを再利用することができます。
あなたは汚れたカバーに直接に失敗することはできませんか？
することはできません！
このために我々はメモリ空間を使用し、ダーティデータブロックによって占められ
、例えば、すべての汚れである、
私はまだメモリの時間を使用する必要があり、
それがDBWnでは、ディスクへの書き戻し汚いブロックをトリガします。
クリーンアップに元のディスク上のライトバックブロックした後、
それを再利用することができますきれい。
これは、いくつかのデータ・ブロックの状態であるbuffercache
実際には、システム機器の性能監視Linuxコマンドが存在する
1は、vmstatの
vmstatのは非常に包括的パフォーマンス分析ツールであり、
それは、観測システムの処理状態、メモリ使用量、仮想メモリの使用状況、ディスクIO、とすることができる
システム（割り込み、コンテキストスイッチ）、CPU使用など
[オラクルをredhat4 @〜] vmstatの$
procsの---------- --- -----------メモリIO swap-- ----- ---- - CPU ---- ---- -system--
R＆LT swpd US SY ID CSワシントン州BフリーキャッシュのSi BUFF SO BI BO
3 61596 39456 669 880 204 0 0 303 174 48 35 13 22であり、30 0であります
iostat 2は、
iostatのは、主にシステム機器を監視IO負荷のために使用され、統計情報システムが稼働して表示し
、[オラクル@ redhat4〜] $のiostat
平均-CPU：％ユーザー％の素敵％SYS％iowaitの％アイドル
47.79 0.05 22.11 0.43 29.61
デバイス：TPS Blk_read / S Blk_wrtn / S Blk_read Blk_wrtn
SDA 6.37 51.81 142.53 3267484 8989120
SDA1 6.17 51.01 137.64 3216970 8680600
SDA2 0.18 0.44 3.86 27814 243424
sda3と0.02 0.34 1.03 21716 65096
これらのデータから、我々は全体のサーバーがビジー状態を知ることができます。
ヒット率のフィードバックの問題を参照してください、だけでなく、物理的な読み取り問題の量のみならず。
SQL文の実装でserverprocess、
必要なDBFは、ディスクからデータを読み取る際に、
データがDBFのserverprocessの内側から読んで、
その後、buffercacheを読み、[buffercacheからユーザーに返さ。
SQL文の実行を確認します
SQL> OBJECT_ID = 1、T1から* / COUNT（*）ハロー/ *を選択し;
COUNT（*）
----------
0
SQL> OBJECT_ID = 2 T1から* / COUNT（*）ハロー/ *を選択し;
COUNT（*）
----------
1
SQL> OBJECT_ID = 2 T1から* / COUNT（*）ハロー/ *を選択し;
COUNT（*）
----------
1
SQL>を選択しSQL_ID、SQL_TEXT、SQL_TEXT '％のハロー％'のようにV $ SQLから実行。
SQL_ID
-------------
SQL_TEXT
----------------------------------- ---------------------------------------------
EXECUTIONS
---- ------
fvbb8qrfd0w5y
選択/ *ハロー* /カウント（*）OBJECT_ID = 2 t1から
1
1vx8fabpy9dwv
SQL_ID、SQL_TEXT、SQL_TEXT '％のハロー％'のようにV $ SQLから実行]を選択
1
SQL_ID
-------------
SQL_TEXT
----------------------------------- ---------------------------------------------
EXECUTIONS
---- ------
8w6u2w729urmp
/ *ハロー* /カウント（*）OBJECT_ID = 2 t1から選択
1
d3wjnjd4tm0p8
選択/ *ハロー* / COUNT（*）OBJECT_ID = 1 t1から
SQL_ID
-------------
SQL_TEXT
----------------------------------- ---------------------------------------------
EXECUTIONS
---- ------
1
参考ボーエン：https://blog.csdn.net/xinzhan0/article/details/51933420