| トップページ |
| Oracle9i DBA I |
| Oracleアーキテクチャ |
| Oracle Serverスタートガイド |
| Oracleインスタンスの管理 |
| データベースの作成 |
| データディクショナリの利用 |
| 制御ファイルの管理 |
REDOログ・ファイルの管理 |
| 表領域とデータファイルの管理 |
| 記憶領域構造 |
| UNDOデータの管理 |
| 表の管理 |
| 索引の管理 |
| 整合性制約の管理 |
| ユーザーの管理 |
| プロファイルの管理 |
| 権限の管理 |
| ロールの管理 |
| グローバリゼーションサポートの管理 |
１．Oracleアーキテクチャの概要 これは、Oracleの仕組みを図式化したもの。 Oracleというのは、物理的にはファイルとメモリとプロセスからなる。 ・・・なんて表現をされても「はぁ？」ってな感じなのだが、Excelなどと比較して考えてみるとわかりやすい。 Excelというアプリケーションは、その結果を「XXXXXX.xls」というファイルに書き出す。 で、ファイルに書き出される前の情報、 例えば「A-1のセルに“あ”という文字を入れた」という操作をした場合、 その情報はメモリ上にあり(保存をしない限りファイルには反映されない)、その保存などの操作はプロセスが行っている。 Oracleも、これと同じようなものである。 ちなみに、上の図は、Excelで書いたものだったりする(笑)。まあ、そんなのはどうでもいいんだけど(笑)。 |
||||||||||
２．接続の確立とセッションの作成Oracleを使用するときの状態を考えてみる。１つ目は、Oracleがインストールされているサーバ上で直接Oracleに接続してログインする場合。 ２つ目は、Oracleがインストールされているサーバに、クライアントから接続をしてログインする場合。 ３つ目は、まあクライアントから見たら２つ目と大差ないんだけど、 クライアントからのリクエストを受け付けてプログラムを動かしたりするサーバ(アプリケーションサーバ)と、 Oracleがインストールされているサーバ(データベースサーバ)が別サーバになっている場合。 まあ、どの場合でもユーザが入るところは、Oracleから見たら扱い的にはクライアント。 クライアントのプロセス、つまりユーザプロセスとなるわけだ。 SQL*Plus等を使って接続するとき、これはユーザプロセスなのだ。 このユーザプロセスが、Oracleが入っているのと同じマシン上にあるのか、 それとも他のマシン上にあるのかなんて、Oracleは意識していない(・・・はず(笑))。 ユーザプロセスから「つなぎたい〜」という要求を出すと、 まずはOracleがインストールされているサーバ上にできるサーバプロセスがこれを受信する。 サーバプロセスはPGA(Program Global Area)というメモリ構造から成っている。 ユーザプロセスとサーバプロセスがうまくつながると、接続成功となる。 で、接続がうまくいったら。 こんどはセッションを作成する必要がある。 サーバプロセスはOracleインスタンスとのセッションを作成。 ここで初めて、SQL文の送信等が行えるようになる。。  さて、上の図は、専用サーバのときと共有サーバのときとを簡単に表したものである。 そもそも、専用サーバと共有サーバはなんなのか、というところなんだけど。 通常は１ユーザプロセスに対し１サーバプロセスが割り当てられ、 そこからOracleインスタンスに接続されてセッションが確立する。 このとき、サーバプロセスにはPGAというメモリ領域があるんだけど。 このPGAには、以下の情報が含まれている。 ・ソート領域 ：SQL文の処理でソートの処理が必要な場合に使用される領域 ・セッション情報：セッションに関するユーザ権限とパフォーマンス統計が含まれる領域 ・カーソル情報 ：セッションで現在使用されているSQL文の処理状態が含まれる領域 ・スタック領域 ：その他のセッション変数が含まれる領域 １ユーザプロセスが１サーバプロセスを占有するのもいいんだけど、 １サーバプロセスを複数のユーザプロセスで共有できると効率がいいねーということでできたのが共有サーバ。 ただしこの場合、ユーザの情報を１PGAで保有してるとまずいことになる。 だって、例えばＡというユーザがどのサーバプロセスを利用するかわかんないから。 どのサーバプロセスを介してもいいように準備する必要がある。 というわけで、PGAで保有していた情報は、その一部をSGAで管理するようになる。 具体的にはソート領域、セッション情報、カーソル情報の３つを、SGAで管理するようになるのだ。 |
||||||||||
３．OracleインスタンスとOracleデータベース
一番最初に出てきた「ファイル」「メモリ」「プロセス」。
これらのうち、「メモリ」と「プロセス」の部分をあわせて、
Oracleでは論理的に「Oracleインスタンス」として扱っている。
Oracleは、このOracleインスタンスと、「ファイル」から成る「Oracleデータベース」とで構成される。
Oracleインスタンスは、特定の１つのOracleデータベースと関連付けられている。 １つのOracleインスタンスで、複数のOracleデータベースが操作されることは絶対にない。 インスタンスはORACLE_SIDというOSの環境変数が個々につけられていて、これによって個々が識別される。 ちなみに、１つのOracleインスタンスからは１つのOracleデータベースしか操作ができないが、 Oracleデータベースから見た場合、複数のOracleインスタンスから操作されることは可能である。 OracleインスタンスとOracleデータベースの関係は１：ｎなのだ。 このように複数のOracleインスタンスでOracleデータベースを操作する場合、 使用メモリが倍になるためパフォーマンスがよくなる。 しかしながら、もちろんメモリに余裕がない限りできない技なのだが。(^^; |
||||||||||
４．メモリ構造OracleインスタンスはSGA(Server Global Area)と呼ばれるメモリ構造と、いくつかのプロセス構造から成る。 SGAはOracleインスタンス起動時に割り当てられる、Oracleインスタンス内での共有メモリ領域である。 このSGAも、論理的に分割された領域となっている。SGA全体のサイズは初期化パラメータSGA_MAX_SIZEによって定義される。 この初期化パラメータの値は、9iからは動的に変更することが可能となった。 ちなみに、これは動的SGAと呼ばれていて、 SGA全体のサイズの他に共有プールやデータベース・バッファ・キャッシュ(非標準ブロックサイズのキャッシュやKEEPバッファ・プール、RECYCLEバッファ・プールを含む)がその対象となっている。 変更にはALTER SYSTEM文を使用する。 |
||||||||||
| ALTER SYSTEM SET 変更したい初期化パラメータ名 = integer[K|M]; | ||||||||||
|
また、9iではSGAコンポーネントを「グラニュル」という単位で管理する。 １グラニュルあたりのサイズは、SGA_MAX_SIZEによって以下のようになる。 SGA_MAX_SIZE ＜ 128MB → ４MB SGA_MAX_SIZE ≧ 128MB → 16MB (1) 共有プール 共有プールはライブラリ・キャッシュとデータ・ディクショナリ・キャッシュから成る。 それぞれのサイズは、共有プールのサイズから自動的に決定される。 共有プールのサイズは初期化パラメータSHARED_POOL_SIZEによって定義される。 また、ALTER文によって動的に変更することが可能である。 a. ライブラリ・キャッシュ 最近使用されたSQL文やPL/SQLに関する情報を格納する場所。 共有SQL領域と共有PL/SQL領域から成る。 って、そのままだなぁ。(笑) 一度実行したSQL文やPL/SQLはここに格納されるため、 次回同じものを実行するときに解析を行わなくて済むので処理時間を短縮することができる。 ライブラリ・キャッシュはLRUアルゴリズムによって管理されている。 (新しいものが残り、古いものから削除される。) b. データ・ディクショナリ・キャッシュ ライブラリ・キャッシュと似ているが、 こちらは最近使用されたデータ・ディクショナリ情報を格納する場所である。 (2) データベース・バッファ・キャッシュ データファイルから検索されたデータブロックのコピーを格納する場所。 ここもまた、LRUアルゴリズムによって管理されている。 データベース・バッファ・キャッシュは、 DEFAULTバッファ・プール、KEEPバッファ・プール、RECYCLEバッファ・プールの３つのプールから成る。 どのプールを使用するかは、CREATE TABLE文またはALTER TABLE文のSTORAGEパラメータ内のBUFFER POOL句にて指定する。 したがって、テーブル単位でプールを使い分けることになるのだ。 ちなみに、指定されていないテーブルについてはDEFAULTバッファ・プールが使用される。 また、それぞれALTER文を使って、サイズを動的に変更することが可能である。 ところで、9iからは標準ブロックサイズの他に、非標準ブロックサイズをしようできるようになった。 非標準ブロックサイズのデータベース・バッファ・キャッシュを定義するには、 初期化パラメータDB_nK_CACHE_SIZEを設定する。 ｎは非標準ブロックサイズを入れる。 この値は２〜32KBの２の累乗である必要がある。 初期化パラメータDB_nK_CACHE_SIZEを設定した場合、標準ブロックサイズで構成されたキャッシュ以外に、 指定された非標準ブロックサイズで構成されたキャッシュが作成される。 なぜ、このように複数のブロックサイズのキャッシュを作成する必要があるのかというと。 詳しくは「表領域とデータファイルの管理」の「１．データベース記憶領域の階層」で出てくるが、 9iからは、データファイルのブロックサイズを表領域ごとに設定することができるようになっているのだ。 データをデータベースバッファキャッシュに読み込むときに、そのブロックサイズは一致している必要があるため、 それらのブロックサイズに合わせたキャッシュが必要になるのである。 例えば、初期化パラメータにて DB_BLOCK_SIZE=4096 DB_CACHE_SIZE=1024M DB_2K_CACHE_SIZE=256M DB_8K_CACHE_SIZE=512M とした場合、標準ブロックサイズは4Kで、このブロックサイズでのデータベース・バッファ・キャッシュは1024M。 これ以外に非標準なキャッシュとして、ブロックサイズ2Kのキャッシュ256Mと、8Kのキャッシュ512Mとが作成される。 しかしながら、非標準なブロックサイズでは、 KEEPバッファ・プールとRECYCLEバッファ・プールを構成することができない点に注意。 まあ、ここらへんの詳細はパフォーマンスチューニングでやるらしい。 a. DEFAULTバッファ・プール 通常使用される場所。 そのサイズは初期化パラメータDB_CACHE_SIZEによって定義される。 必ず存在する場所で、DB_CACHE_SIZEを0にすることはできない。 b. KEEPバッファ・プール よく再利用されるデータ・ブロックを保持しておく場所。 マスタ系のテーブル等はここに保持するようにするとよい。 サイズは初期化パラメータDB_KEEP_CACHE_SIZEにて定義される。 この領域は作っても作らなくてもどっちでもよく、DB_KEEP_CACHE_SIZEの値を0にすることも可能である。 しかしながら、その場合は同じデータブロックに対して何度も読み込みが発生する可能性があり、 パフォーマンス的によくない場合もあるので、注意が必要。(^^; c. RECYCLEバッファ・プール あまり使用しない、削除しても大丈夫なデータを保持しておく場所。 そのサイズは初期化パラメータDB_RECYCLE_CACHE_SIZEにて定義される。 この領域も、作っても作らなくてもどっちでもよく、DB_RECYCLE_CACHE_SIZEの値を0にすることも可能である。 (3) REDOログ・バッファ データブロックに対して行われた変更をすべて記述しておく場所。 障害時のリカバリに威力を発揮。(笑) サイズは初期化パラメータLOG_BUFFERで定義される。 (4) ラージプール ユーザが共有サーバ経由で接続をする場合、セッション情報等をSGA内で保有する必要がある。 このとき、ラージプールが設定されていると、この領域を使用する。 サイズは初期化パラメータLARGE_POOL_SIZEで定義される。 この領域はオプションであるため、定義されなかった場合は共有プールが使用される。 この領域にはLRUアルゴリズムは適用されない。 (5) JAVAプール JAVAを使用するときに必要になる領域。 サイズは初期化パラメータJAVA_POOL_SIZEで定義される。 使用しない場合は、明示的に0を指定する必要がある。 |
||||||||||
５．プロセス構造(1) DBWn(Database Writer)データベース・バッファ・キャッシュにある使用済みバッファの内容をデータファイルに書き込む。 書き込むタイミングは以下のとおり。 ・チェックポイント発生時 ・使用済みバッファのサイズがしきい値に達したとき ・空きバッファの走査中に指定数のデータブロックが発見できないとき ・タイムアウト(３秒)発生時 ・表領域のオフライン設定時 ・表領域の読み取り専用設定時 ・表の削除または切り捨て時 ・表領域のバックアップ開始時 COMMIT処理とは非同期であることに注意！ (2) LGWR(Log Writer) REDOログ・バッファの内容をREDOログ・ファイルに順次書き込んでいく。 書き込みが発生するのは以下のタイミング。 ・トランザクションのCOMMIT時 ・REDOログ・バッファが容量の３分の１に達したとき ・タイムアウト(３秒)発生時 ・DBWnの動作前 REDOログ・ファイルへの出力が完了した時点でCOMMITが完了。 この時点で、インスタンスリカバリが保証される。 REDOログ・バッファからREDOログ・ファイルへの書き込みはシーケンシャルで行われる。 また、更新情報しかREDOログ・バッファには書き込まれていない。 これによって、COMMIT処理の高速化が実現されている。 (3) SMON(System Monitor) なんか「エスモン」とか言うと「ポケモン」みたいだけど。(笑) まあ、冗談は置いといて。 インスタンス障害時はSGAの情報がすべて失われるため、次回Oracle起動時にこれを復活させる必要がある。 SMONはこれを監視し、次回起動時に自動的にインスタンスリカバリを行う。 また、データファイル内の隣接した空き領域の結合や、一時セグメントの割り当ての解除も行う。 ここらへんの詳細については、「表領域とデータファイルの管理」を参照のこと。 (4) PMON(Process Monitor) ユーザプロセス障害時にクリーンアップを行う。 ・ユーザのトランザクションのロールバック ・現在保持されているすべての表ロックや行ロックの解放 ・ユーザが現在予約しているリソースの解放 ・使用不可能なディスパッチャの再起動 (5) CKPT(Checkpoint) チェックポイント発生時に、以下の処理を行う。 ・チェックポイントの詳細を記録するために、すべてのデータファイルのヘッダーと制御ファイルを更新 ・DBWnにシグナルを発信(これによりDBWnはデータファイルへの書き込みを行う) チェックポイントにより、頻繁に変更されるメモリ内のデータブロックがデータファイルに定期的に書き込まれるため、 インスタンス・リカバリの時間を短縮することができる。 チェックポイント時までの更新はすでにデータファイルに書き込まれているため、 REDOログ・ファイルのエントリをデータファイルに適用する必要がなくなるからである。 (6) ARCn(Archiver) オプションのプロセス。 ディスク障害時に備えて、データベースをリカバリできるようにREDOログ・ファイルを自動アーカイブするためのプロセスである。 詳細は「REDOログ・ファイルの管理」の「」を参照のこと。 (7) その他のプロセス RECO(リカバラ)、LMS(ロック・マネージャ・サーバ)、QMNn(キュー・モニター)、Dnnn(ディスパッチャ)、Snnn(共有サーバ)などがある。 |
||||||||||
６．ファイル構造Oracleデータベースの核となる「データファイル」「制御ファイル」「REDOログファイル」の３種類のファイルの他に、 「初期化パラメータファイル」「パスワードファイル」「アーカイブログファイル」がある。(1) データファイル 実際のデータが格納されている。 詳細は「表領域とデータファイルの管理」を参照のこと。 (2) 制御ファイル データベースの整合性を維持、検証するために必要な情報が格納されている。 詳細は「制御ファイルの管理」を参照のこと。 (3) REDOログ・ファイル データベースに対する変更情報が格納されている。 詳細は「REDOログ・ファイルの管理」を参照のこと。 (4) 初期化パラメータ・ファイル Oracleインスタンスの諸定義を行うパラメータ値が格納されている。 詳細は「Oracleインスタンスの管理」を参照のこと。 (5) パスワード・ファイル Oracle Serverを起動、停止する権限を持つユーザを認証するために使用する。 詳細は「Oracle Serverスタートガイド」を参照のこと。 (6) アーカイブ・ログ・ファイル REDOログファイルのオフラインコピー。 詳細は「REDOログ・ファイルの管理」を参照のこと。 |
||||||||||
７．SQL文の実行(1) SELECT文の実行解析フェーズ、実行フェーズ、フェッチフェーズの３段階の処理を行う。
１のステップで共有プール内に同じSQL文が存在した場合は１→４→６→７→８と進む。  (2) DML文の実行 解析フェーズ、実行フェーズの２段階の処理を行う。 解析フェーズはSELECT文の実行と同じである。
 |