🧠 Oracleインスタンスの概要
-
Oracleインスタンスは、メモリ領域（SGA） と バックグラウンドプロセス の2つで構成される。
-
インスタンスはサーバー起動時に生成され、データベースへのすべてのアクセスと処理はこのインスタンス内で行われる。
-
インスタンス内のデータは、最終的にデータベースファイルに書き込まれる。
💾 メモリ構造：SGA（System Global Area）
🔹 SGAの主な構成要素
| コンポーネント | 役割 |
|---|---|
| Library Cache | SQL文の解析木・実行計画を保存。複数ユーザが同一SQLを実行する際に再利用され、メモリを節約し高速化。 |
| Data Dictionary Cache | テーブル定義、ユーザ権限などの情報をキャッシュ。常に参照されるため、性能に直結。 |
| Server Result Cache | SQLやPL/SQL関数の実行結果をキャッシュし、再実行を高速化。 |
| Database Buffer Cache | データファイルから読み込まれたブロックをキャッシュ。キャッシュヒット時は高速、ミス時はディスクから読み込み。 |
| Redo Log Buffer | 更新操作の変更履歴を記録。障害復旧時に使用される。 |
| Large Pool（任意） | RMAN（バックアップ/リストア）やMTS用の大きなメモリ割り当てに利用される。 |
| Java Pool | Oracle JVM用。Javaコードやセッションデータ格納。 |
| Streams Pool | Oracle Streamsのメッセージや適用処理用。 |
🧾 Data Dictionary（データ辞書）
-
データベース構造・ユーザ・権限などのメタ情報を保持。
-
データベース操作時に頻繁に参照され、SYSスキーマが保持する。
-
一部は永続ストレージ（ALL_TABLESなど）に保存され、他は動的（
V$ビューなど）でメモリ上に存在。 -
V$PDBSやV$SESSIONは代表的な動的ビュー。
🔄 SQL文とキャッシュ
-
同じSQLが複数のユーザから発行される場合、Shared SQL Area が再利用され、解析・実行計画の再生成が不要。
-
SELECTにヒントを付ければ結果キャッシュが使用可能。
📦 データキャッシュの詳細
🔸 Database Buffer Cache
-
Oracleブロック単位でキャッシュ（1ブロック = Oracleの最小読み書き単位）。
-
キャッシュヒット：メモリから直接データ取得 → 高速
-
キャッシュミス：ディスクから読み込み → バッファに格納 → メモリから提供
-
変更されたブロック（Dirty Buffer） はバックグラウンドプロセス Database Writer (DBWn) によってディスクに書き戻される。
🔸 Redo Log Buffer
-
すべての変更（INSERT、UPDATE、DELETEなど）のログを保持。
-
循環バッファ構造。満たされたら最初から上書き。
-
Log Writer (LGWR) プロセスが定期的に REDOログファイル に書き込む。
-
障害復旧に不可欠。
🧮 その他のメモリ領域と構成
🔹 PGA（Program Global Area）
-
各サーバプロセス専用のメモリ領域（SGAとは非共有）
-
ログインセッション・SQL処理用のワーク領域を保持
-
専用サーバモード：セッションごとに1つのPGA（→ UGAはPGA内）
-
共有サーバモード：UGAはSGA内に配置される（Shared PoolやLarge Pool）
👤 ユーザーと処理フローの例
ユーザーA～Dの例で解説：
-
ユーザーA：
SELECT文発行 → ライブラリキャッシュ＆データ辞書参照 → 結果取得 -
ユーザーB：同じSQL実行 → キャッシュを活用し高速化
-
ユーザーC：
SELECT /*+ RESULT_CACHE */→ 実行結果をキャッシュし、次回は即応答 -
ユーザーD：PL/SQL関数に
RESULT_CACHE→ 同一引数での再呼び出しは実行不要
🔚 まとめ：Oracleインスタンス構造図イメージ
+----------------------------+| Oracle Instance || || +----------+ +----------+ || | SGA | | BG Proc | | ← メモリ領域＆バックグラウンドプロセス| +----------+ +----------+ |+----------------------------+SGA構成例：- Shared Pool（Library, Data Dictionary）- Buffer Cache（DBブロック）- Redo Log Buffer（変更履歴）- Large Pool, Java Pool, Streams PoolPGA構成例：- セッション情報、ソート、結合、ログオン情報など（個別プロセス単位）
🧠 Oracle Database のメモリ管理
🔹 概要：メモリ管理とは？
Oracleデータベースにおけるメモリ管理とは、インスタンス内のメモリ構造（SGAやPGA）のサイズを最適に保ち、パフォーマンスを向上させるための仕組みです。
🔧 メモリ管理の3つのモード
| モード | 概要 | 特徴 |
|---|---|---|
| ① 自動メモリ管理（AMM） | MEMORY_TARGET のみを指定するだけで、OracleがSGAとPGAの両方を自動調整する。 | 完全自動。最も推奨される（特に小規模～中規模環境）。 |
| ② 自動共有メモリ管理（ASMM） | SGA_TARGET と PGA_AGGREGATE_TARGET を個別に設定し、SGA内部は自動調整される。 | SGAは自動、PGAは手動。4GB以上の大規模システムで推奨。 |
| ③ 手動メモリ管理 | SGAやPGAの各コンポーネント（例：DB_CACHE_SIZE）をすべて個別に設定。 | 細かいチューニングが可能だが、専門知識が必要。 |
💡 現在の設定確認と切り替え手順
✅ 設定確認方法
SHOW PARAMETER コマンドや、SQLで確認可能。
-
MEMORY_TARGET、MEMORY_MAX_TARGETが 0でなければAMM（自動メモリ管理） -
SGA_TARGET、PGA_AGGREGATE_TARGETが有効なら ASMM（自動共有メモリ管理）
🔄 切り替え手順（例：AMM→ASMM）
-
バックアップのため、サーバパラメータファイル（SPFILE）をテキスト形式にエクスポート
-
MEMORY_TARGETを 0 に設定 -
SGA_TARGET、PGA_AGGREGATE_TARGETに適切な値を設定 -
インスタンスを再起動（
SGA_TARGET変更時は必須）※ASMM は SGA + PGA 合計が 4GB以上ある場合に推奨される。
🔁 AMM に戻すには？
-
MEMORY_TARGETに合計値を指定 -
Oracle が SGA と PGA の両方を自動で調整してくれる
📈 パフォーマンス監視：自動メモリ管理のチューニング
-
実運用後に負荷に応じて調整が必要な場合、以下のビューを使用：
-
memory_size_factor = 1が現在の設定 -
他の行は、異なるメモリサイズにした場合の予測完了時間（パフォーマンスへの影響）を示す
🔸 Oracle インスタンスとは？
-
Oracleインスタンスは、Oracleサーバーマシン上の メモリ（RAM） 内に構築される構造。
-
2つの構成要素からなる：
-
Memory structures（SGAなどの共有メモリ領域）
-
Background processes（自動で起動される補助プロセス）
-
🔹 プロセスの種類
| 種類 | 内容 |
|---|---|
| ユーザープロセス | アプリやツールがOracleに接続する際に動作。リモートから接続されることも。 |
| サーバープロセス | ユーザープロセスのリクエストを処理。Listenerによって専用に作成される（専用サーバーモードの場合）。 |
| バックグラウンドプロセス | Oracleが自動で起動。様々な補助処理（書き込み、同期、リカバリなど）を行う。v$bgprocess ビューで確認可能。 |
🔧 主なバックグラウンドプロセスの役割
✅ DB Writer（DBWn）
-
データベースバッファキャッシュ（SGA内）の「変更済み（ダーティ）」ブロックをディスクに書き出す。
-
書き出しタイミングはチェックポイントと呼ばれるイベントで発生。
✅ Checkpoint（CKPT）
-
DBWn の書き込みタイミングを監視。
-
制御ファイルやデータファイルのヘッダーにチェックポイント情報（SCNやREDOログ位置）を記録。
-
SCN: システム変更番号。これによりデータの同期が保証される。
✅ Log Writer（LGWR）
-
REDOログバッファの内容をディスク上のREDOログファイルに書き込む。
-
書き込みタイミング例：
-
トランザクションのコミット時
-
REDOログバッファが1/3満杯
-
ログスイッチ時
-
DB Writer がディスクに書き込む前
-
3秒経過後
-
Write Ahead Protocol：DBWnより前にLGWRが書き込む必要がある。
✅ アーカイバ（ARCn）
-
アーカイブログモード時に、ログスイッチのたびにREDOログを**アーカイブログ（別ファイル）**に退避。
-
メディア障害時のリカバリに必要。
✅ System Monitor（SMON）
-
インスタンス障害（例：停電）時に、再起動後にコミット済みトランザクションを反映し、未コミットはロールバック。
-
一貫性を回復。
✅ Process Monitor（PMON）
-
異常終了したユーザーセッションのリソース（ロック、セッション情報など）を自動クリーンアップ。
✅ Listener Registration Process（LREG）
-
インスタンスやディスパッチャープロセスの情報をOracle Net Listenerに登録。
🔁 トランザクション処理の流れ（ユーザーのCOMMIT時）
-
アプリケーションがユーザープロセスを作成、接続要求。
-
リスナーが専用サーバープロセスを作成。
-
ユーザーがSQL（SELECT, UPDATEなど）を発行。
-
Shared Poolに同一SQL文の共有領域があるか確認し、あれば再利用。
-
データ取得 or 修正
-
キャッシュにあればそのまま利用
-
なければディスクから取得
-
-
変更はSGA内で実施
-
COMMITが実行されると、LGWR がREDOログに書き込み
-
ユーザーへ成功メッセージが返される。
-
DBWn は、効率的なタイミングでデータを最終的にディスクへ書き出す
✅ その他ポイント
| 内容 | 説明 |
|---|---|
| REDOログの構成 | 最低2グループが必要。グループごとにファイルがあり、ログスイッチで順次書き込み先が変わる。 |
| グループコミット | 高負荷時に複数のトランザクションをまとめてREDOログに書き込むことでI/Oを効率化。 |
| Fast Commit Mechanism | COMMIT成功時、即REDOログに書き込み→データのディスク書き込みは後回し。 |
🧩 Oracle Multitenancyとは何か？
🔸 解決したい課題
-
複数データベースの非効率なリソース利用
-
サーバごとに個別のDBを動かすと、リソースが無駄になりがち。
-
-
DBAの管理負担が大きい
-
各DBを個別にパッチ適用・メンテナンスする必要がある。
-
🧱 Multitenantアーキテクチャの構造
Oracle Multitenancyでは、1つのOracleデータベースを CDB（Container Database） として動かし、
その中に複数の PDB（Pluggable Database） を格納します。
🔹 主な構成要素
| コンポーネント | 説明 |
|---|---|
| CDB$ROOT（ルートコンテナ） | Oracleのシステムメタデータ（辞書、共通ユーザー、PL/SQLパッケージなど）を保持。ユーザーデータはここに作らない。 |
| PDB$SEED（シードPDB） | 新しいPDBを作る際のテンプレート。変更・追加はできない。 |
| ユーザー作成PDB（例: SALES, HR） | 実際のアプリケーション用データベース。1つのPDBは1つのアプリケーションに対応させる想定。 |
🔧 Multitenantのメリットと特長
| 項目 | 内容 |
|---|---|
| アプリの互換性 | PDBに接続したアプリは、通常のスタンドアロンDBと区別がつかない。 |
| 管理の簡素化 | パッチ・アップグレードはCDB単位で行えば、すべてのPDBに反映される。 |
| リソースの統合 | 1つのインスタンス・SGA・バックグラウンドプロセスで複数DBを運用可能。 |
| アーキテクチャの一貫性 | ルートコンテナは共通辞書を管理、各PDBは独自のデータ辞書を持つ。 |
🗃️ 各種構成のポイント
| 機能 | 内容 |
|---|---|
| REDOログ | CDB全体で1つのREDOログファイル。どのPDBで変更が起きたかはログに記録される。 |
| アーカイブログモード | CDB単位で有効。全PDBに適用される。 |
| コントロールファイル | CDB単位で共通。PDB追加時の情報も含まれる。 |
| UNDO表領域 | 共有UNDOまたは各PDBのローカルUNDOが選択可能。 👉ローカルUNDO推奨：PDB単位でポイントインタイムリカバリ可能 |
| テンポラリ表領域 | 共通のテンポラリ表領域に加え、各PDBがローカルな一時表領域を持つことも可能。 |
| データディクショナリ | 各コンテナ（CDB$ROOT/PDB）に固有のSYSAUX/SYSTEM表領域に格納される。 |