【別紙】アーキテクチャ比較表【別紙】アーキテクチャ比較表
No.

アーキテクチャ
プロセス構成説明
DBサーバのプロセスの構成

PostgreSQL
OracleSQL Server
DB2
マルチプロセス構成。マスタープロセスがリスナプロセス マルチプロセス/スレッド構成。ネットワーク・リスナー・プ マルチプロセス/スレッド構成。各プロセスはWindowsのサ マルチプロセス/スレッド構成。接続毎にコーディネーターであり、クライアントからの接続を受け付ける毎にバックエ ロセスが接続を受け付け、サーバープロセスが起動され ービスとして実装されている・エージェントが生成されクライアントからの要求を処理すンドプロセスが生成されるる
る
SQL Server データベース エンジン [*1]
postgres常駐プロセス(postmaster) [*1]
ネットワーク・リスナー・プロセス [*1]
SQL Server エージェント [*2]
通信リスナー
postgres子プロセス [*2]
サーバープロセス [*2]SQL Server Integration Services [*3]コーディネーター・エージェント [*1]
補助プロセス [*3]ディスパッチャ・プロセス [*3]
SQL Server Browser [*4]データベースEDU [*2]ライタ
共有サーバー・プロセス [*3]
レプリケーション エージェント [*5]メイン・システム・コントローラ
WALライタ専用サーバー・プロセス [*4]SQLライター サービス [*6]バッファー・プール・プリフェッチャー用
WALアーカイバ
バックグラウンドプロセス [*2]その他サービスバッファー・プール・ページクリーナー用
統計情報コレクタ
データベース・ライター（DBWR）
SQL Server Analysis Services
ログマネージャ用ロガー
ログ・ライター（LGWR）
SQL Server Master Data Services
ログトラッキング用
自動バキュームランチャ
チェックポイント（CKPT）
SQL Server Reporting Services
デッドロック検出用
自動バキュームワーカ
システム・モニター（SMON）など
イベント・モニター高速ライター
WALセンダプロセス・モニター（PMON）など
WALレシーバ
リカバラ・プロセス（RECO）[*1]データベースエンジンのインスタンス。Windowsのサなど
アーカイバ・プロセス（ARCn）ービスとして実行される。(sqlservr.exe 実行可能ファイル [*1]接続毎。データベース要求を実行する
ジョブ・キュー・プロセスのコピー)[*2]EDU：エンジン・ディスパッチ可能単位[*1]マスタープロセス。バックエンドを管理する常駐プロセ キュー・モニタ・プロセス[*2]管理ジョブを自動実行しジョブの実行、SQL Serverの 様々なタスクの実行を行う実行単位（プロセス、スレッド）ス(PostgreSQL管理デーモン)など監視および警告の発生を行う[*2]バックエンドプロセス。フロントエンドからの接続毎に[*3]データ転送サービス
常駐プロセスから生成(fork)されるデータベースエンジン [*1]Oracle Net Servicesの一部[*4]SQL Server の各種リソースに関する着信要求を受信[*3]postgres常駐プロセスから起動されるその他のプロセ [*2]Windows環境ではデータベースインスタンスが１プロ し、SQL Server インスタンスに関する情報を提供する
ス群
セス（バックグラウンドプロセスはスレッドとして実装され [*5]SQL Server エージェントから実行されるレプリケーシている）
ョン関連のスタンドアロンプログラム。スナップショットエー
[*3]共有サーバ接続の場合
ジェント、ログリーダーエージェントなど[*4]専用サーバ接続の場合[*6]SQL Server のバックアップと復元に関する追加機能を提供

メモリ構成

DBサーバのメモリの構成大きくはプロセス間で共有されるメモリ領域とプロセスに固有のメモリ領域に分けられる

12

大きくはOracleインスタンス内で共有されるメモリ領域
メモリの確保と解放が必要に応じて動的に行われるメモリーセットという管理単位を複数持つ構成(SGA)とプロセスに固有のメモリ領域(PGA)に分けられる。それら内部にセッション単位の領域(UGA)、スタック領域 ■動的メモリ管理
インスタンス・メモリ
共有メモリ [*1](CGA)が確保される
使用可能なシステム リソースに基づいて必要なメモリ量
DB(Database) memory set [*1]
共有バッファ [*2]が動的に変更。最小の既定メモリ量は、0MBとなっている Application memory set [*2]
WALバッファ [*3]
SGA [*1]。最大メモリ量に設定されている既定値は、2GBで、最大 DBMS memory set [*3]フリースペースマップ [*4]共有プール
メモリ量に設定できる最小値は、16MBとなっている
FCM memory set [*4]
ビジビリティマップ [*5]データベース・バッファ・キャッシュ
FMP memory set [*5]など
REDOログ・バッファ■AWE(Address Windowing Extensions)
Private memory set [*6]
プロセスメモリ [*6]
ラージ・プール
32ビット版のオペレーションシステムのみに適用さLocal Communication memory set [*7]
作業領域 [*7]Javaプール
れ、4GBを超える物理メモリを使用でき、最大64GBの物
メンテナンス領域 [*8]Streamプール
理メモリをサポートする[*1]データベース毎。各データベース固有の処理用
一時バッファ
結果キャッシュ・バッファー・プール・ヒープなど
PGA [*2]■バッファ管理・パッケージ・キャッシュ・ヒープ
UGA [*3]
I/Oの効率向上を実現するために重要なコンポーネントで ・カタログ・キャッシュ・ヒープ
[*1]複数のバックエンドで共有されるデータの保持領域。 CGA [*4]、データベースページに対するアクセスと更新を行うバッ ・データベース・ヒープ
サービス起動時に固定サイズが確保される
ファ マネージャと、データベース ファイルのI/Oを削減す ・ロック・マネージャ・ヒープ など[*2]テーブルやインデックスのデータをキャッシュする領 [*1]共有メモリ領域。自動メモリ管理機能使用の場合はメ るバッファ キャッシュから構成される[*2]データベース毎。アプリケーション固有の処理用 (作域
モリファイルシステム
業領域等)[*3]ディスクに書き込まれていないトランザクションログ[*2]動作中のプロセスやスレッドに固有のメモリ■オブジェクトの使用で使用されるメモリ
・アプリケーション・ヒープ（WAL：Write Ahead Logging）をキャッシュする領域[*3]主にSQLのソートや表結合などの処理で利用される ・テーブル ロック等 ロックしたことによるメモリ消費・ステートメント・ヒープ[*4]テーブル上で利用可能な空き領域を指し示す情報を 領域。セッション単位で確保される。専用サーバ接続であ ・クライアントが接続したことによるメモリ消費・統計ヒープ など
扱う領域
ればPGA、共有サーバ接続であればSGAのLARGEプー[*3]インスタンス毎。通信サービスなどの基本インフラスト[*5]テーブルのデータが可視であるかを管理する領域
ルの中から確保されるラクチャーの目的で使用[*6]実行プロセス毎に確保される[*4]PGA内に確保されるスタック領域[*4]ホスト毎。各パーティション間でのFCMによる通信に[*7]クエリ実行時の並び替え、ハッシュテーブル操作のた使用めに使われる領域[*5]インスタンス毎。エージェントとfenced モード・プロセ[*8]インデックス作成、外部キー追加、バキュームなど、メス(db2fmp)の間の通信に使用
ンテナンス操作で使用する領域[*6]インスタンス毎。内部管理領域[*7]接続毎。ローカル・アプリケーションとその関連エージ
ェントの間の通信に使用

ページ 1

【別紙】アーキテクチャ比較表
No.

アーキテクチャディスク構成3

インスタンスとデータベースの関係
4

認証方式

5

メモリ管理

6

説明
PostgreSQL
OracleDBサーバのディスクに配置される物理ファイ インスタンス（データベースクラスタ）は基本的には１つの OFA(Optimal Flexible Architecture)に準拠した構成で管ルの構成
ディレクトリで管理される
理される
データベース毎の情報はサブディレクトリ内にファイルとして格納される■OFA(Optimal Flexible Architecture)概要
所有するユーザおよび、バージョンの異なる複数のデー[データベースクラスタディレクトリ]
タベースが共存できるように、データベース・ソフトウェア+- [データベースディレクトリ] [*1]とデータベースを適切に配置および構成する|+- テーブルファイル|+- インデックスファイル
初期化パラメータファイル[*1]|+- フリースペースマップファイル
制御ファイル [*2]|+- ビジビリティマップファイル
データファイル [*3]+- WALファイル [*2]
REDOログファイル+- WALアーカイブ
アーカイブログファイル+- サーバログファイル[*1]インスタンス構成情報[*1]基本的には1テーブルが1ファイルとなる[*2]データベース構成情報
・1つのファイルに複数の表のデータは格納されない[*3]表領域のデータ（Oracleが使用する「システム表領域・表領域（テーブルスペース）は任意のディレクトリに表デ 」「UNDO表領域」「一時表領域」などの表領域、およびユータを格納したい場合に使用するーザが使用する表領域）[*2]先行書き込みログ（トランザクションログファイル）・通常１つの表領域は多数の小型ファイルで構成されるが、単一の大型ファイルで構成することも可能
・１つのデータファイルに複数の表を格納することも、1つの表のデータを複数のデータファイルに分割して格納することもできる

SQL Server
インスタンス構成によってACLディレクトリが構成される

DB2
ノード毎にデータベースファイル、表スペース コンテナー
や、トランザクションログが管理される■スタンドアロン インスタンス
既定のインスタンスまたは、名前付きインスタンスが指定 インスタンス構成情報
された既定構成
データベースマネージャ構成ファイル [*1]データベース構成情報■フェールオーバー クラスター インスタンス
データベース構成ファイル [*2]
ソフトウェアに障害が発生した際、インスタンスを冗長ノー トランザクションログ
ドで保護する
自動ストレージパス
表スペースコンテナー [*3]■ファイル構成など
プライマリ データ ファイル [*1][*3]
セカンダリファイルグループ[*1]データベースマネージャ構成ファイルにインスタンス
セカンダリ データ ファイル [*2][*3]
情報を格納（インスタンス内のデータベースに共通の情報
トランザクション ログ ファイルとして適用される）[*2]各データベース構成情報はデータベース構成ファイ[*1]システム情報（Oracleの制御ファイルに相当）
ルに記述される[*2]テーブルなどのユーザデータ[*3]システム情報を「カタログ表スペース」に、テーブルな[*3]Azure Virtual Machine(VM)上で稼動している場合どのユーザデータを「ユーザ表スペース」に格納。表スペ
データファイルを表領域に複数割り当てた場合、自動的 ースに対しコンテナ（ディレクトリ/ファイルで構成される物に64Kbyteごとに分散して格納される理オブジェクト）を複数配置することが可能。コンテナーはOracleのデータファイルに相当

１対N
データベースインスタンスとデータベースが１ 1対N
1対1
１対N
対１か、インスタンス内にデータベースを複数持てる構成か
唯一インスタンスがデータベースの集合である「データベ 1つのインスタンスにつき、インスタンス構成情報とデータ インスタンスの構成情報を1つのシステムデータベースに データベースマネージャ構成ファイルにインスタンス情報ースクラスタ」を管理
ベース構成情報を1つずつ持つ
格納し、各データベース構成情報はユーザデータベース （インスタンス内のデータベースに共通の情報）を格納す※「データベースクラスタ」が他のDBMSで「インスタンス」のシステムテーブルに格納ると呼ばれるものに相当※1つのインスタンスに複数のデータベースを持つことが 各データベースの構成情報はデータベース構成ファイル※インスタンス内に複数のデータベースを持つことができできるに記述される
る※1つのインスタンスに複数のデータベースを持つことができる
DB接続ユーザとOSユーザとのリンクや認証 OSのユーザを使用する、データベース接続ユーザとOS [ユーザ認証][ユーザ認証][ユーザ認証]方式のユーザを別にする、リンクさせる、が可能
・OS認証
・Windows／OS認証
外部機密保護サービス認証
・trust認証
・データベース認証
・SQL Server認証（データベース認証）（OS上のユーザーおよびグループの単位で認証）
・パスワード認証の２通りの２通り[ログインアカウント]・GSSAPI認証[ログインアカウント][ログインアカウント]
外部機密保護サービスに登録したユーザーに対し、管理・SSPI認証
インスタンスごとにログインアカウントを作成
インスタンスとデータベースへの認証が別者がデータベース接続権限を付与する
・Ident認証※インスタンスごとのログインアカウントを作成し、データ・Peer認証
ベースごとのデータベースユーザを作成、データベースユ・LDAP認証
ーザをログインアカウントと関連付けする・RADIUS認証
・証明書認証・PAM認証DBサーバの各メモリ領域のサイズ管理のさ データベースクラスタのパラメータに基づいてメモリ確保さ ■手動メモリ管理
サーバー構成オプションにて最小メモリ、最大メモリ、最 各メモリーセット[*1]について上限サイズ[*2]までメモリがれ方
れる[*1][*2]
メモリー関連の初期化パラメータの設定にて各メモリコン 大ワーカスレッド数などを指定する。メモリ使用量はメモリ 確保されメモリーセット内の各用途のメモリリソースの間大きく分けて「共有メモリ」と「ローカル ヒープ」から構成さ ポーネント毎に個別にサイズを指定する
マネージャー コンポーネントにより負荷状況に応じて自 で動的に分配[*3]される
れる■自動メモリ管理 [*1][*2]
動的にサイズ調整、最適化される■共有メモリ有効にすると負荷に応じて運用中も自動的にサイズ調整[*1]OS から取得したメモリは「メモリー・セット」として管理
・複数のバックエンドで共有されるデータを保持、最適化される■仮想アドレス空間(Virtual Address Space) [*1][*2]
されており、各コンポーネントは「メモリー・ブロック」という・セッションをまたいで共有すべきデータ・ユーザモード用（2GB）単位で必要なメモリを要求し「メモリー・マネージャー」が「・共有バッファ、トランザクション情報、ロック情報 等[*1]一部のメモリコンポーネントは自動チューニングの対 ・カーネルモード用（2GB）メモリー・セット」から割り振る・サービス起動時に固定サイズを確保
象外[*2]構成パラメータに上限値の指定項目があり、デフォル[*2]Oracle9i Database 以降で自動メモリ管理機能が強化 [*1]ユーザモード用および、カーネルモード用から構成さ トは「AUTOMATIC」となっている■ローカルヒープされており、11g以降ではPGAおよびSGAの合計割り当て れ、4GBの領域が確保される。物理メモリのサイズが8GB [*3]「データベース・メモリー・セット」を例にすると、データ・個別のセッションで使用するメモリサイズを指定する形となっているであっても32bit環境では、常に4GBとなるベース活動化時に固定サイズが確保される領域(バッファ・ソート、演算処理などを実行するときに使用するメモリス[*2]仮想アドレス空間は、あくまでも「仮想」である為、仮 プールなど)、クリーンアップされるまで使用量が単調増加
ペース
想アドレス空間でのメモリ割り当てがそのまま物理メモリ する領域(カタログ・キャッシュ・ヒープなど)、都度使用量・必要となるたびに確保、不要になったら開放上の領域を使用するわけではないが増減する領域(共有ソート・ヒープなど)がある[*1]postgresql.confにてキャッシュメモリサイズ、チェックポイント実施間隔、WALバッファサイズなどの項目を指定する[*2]メモリ確保/解放は「メモリコンテキスト」という単位で行われる

ページ 2

【別紙】アーキテクチャ比較表
No.

アーキテクチャ
クエリ実行フロー

説明
SQL文の実行フロー

PostgreSQL
OracleSQL Server
DB21)SQLをパースツリーに変換
1)解析処理(PARSE)
1) コンパイル・DB2 オプティマイザーにより、SQLステートメントから最2)パースツリーを解析しクエリツリーに変換（アナライズ)
・ライブラリキャッシュチェック [*1]1-1. ステートメントを解析
適なアクセス・パスを解析[*1]
・構文チェック [*2]1-2. シーケンスツリーを作成
3)必要なクエリの書き換えを実施（リライト）[*2]・表、列の定義チェック [*2]
1-3 ツリーを正規化
1) アクセス・パスにより解析処理
4)問合せを実行するプランツリーを作成（クエリオプティマ ・オブジェクト権限チェック [*2]1-4. ステートメント判定
1-1. 索引アクセス[*1]
イズ）・実行計画作成 [*3]1-4-1. SQL DMLの場合
1-1-1. 索引参照
5)問合せを実行（エグゼキュート）
2)実行処理(EXECUTE) [*4]1-4-1-1. TSQLステートメント プロシージャーとして、コン 1-1-2.索引スキャン
3)データ取り出し処理(FETCH) [*5]パイル
1-1-2-1. マッチング索引スキャン[*1]テーブル名をOIDに変換する
1-4-2. SQLDML以外の場合
1-1-2-2. 非マッチング索引スキャン[*2]VIEWやRULEはリライトにより実装されている[*1]同一SQLの解析結果が共有プールのライブラリキャッ 1-4-2-1. シーケンスツリーをクエリグラフに変換
1-1-3. 完全スキャン
シュ領域にキャッシュされている場合は、残りの解析処理 1-4-2-2. クエリグラフを最適化
1-2. 結合方式[*2]はスキップ(SOFT PARSE)
1-4-2-3. クエリ実行プランを作成
1-2-1. ネスト・ループ結合[*2]データディクショナリに対して再帰SQLが発行される 2) 最適化
1-2-2. マージ・スキャン結合(HARD PARSE)
2-1. トリビアルなプラン最適化
1-2-3. ハッシュ結合[*3]統計情報より最適な抽出方法を決定。実行計画は共 2-2. 完全最適化
2)アクセス・パスからコンパイル
有プールのライブラリキャッシュ領域にキャッシュする
3) 問い合わせ実行
3)問い合わせを実行[*4]挿入、更新、削除処理はここまでで完了[*5]SELECT文の場合のデータ取り出し。データがデータ ストアドプロシージャのクエリプランだけでなく、アドホック [*1] SQLステートメントの最低限1つが索引付け可能であ
ベースバッファキャッシュに存在する場合はキャッシュか クエリや自動パラメータ化クエリのプランもキャッシュに入 ることら取得する
れて、再利用できるようにする[*2] 結合方式の場合、小さい表を選択し、結合対象の内部表への再アクセス回数を減らしている※Visual Explain ツールを用いることでアクセス・パスを目視することが可能

アクセス・パス

表データのスキャン・結合方式■表データの構成
データ・ブロックの連続で表データを構成

78■表データの構成
・データ・ブロックの連続で表データを構成■表データの構成■表データの構成
・基本ユニットは、ページ(page)で管理されており、8KB毎 ページと呼ばれるブロックに格納され、ページのサイズはの連続データブロックで構成、4KB、8KB、16KB、32KB の4種類。データ・ページには、■全表スキャン
■全表スキャン列の定義情報は含まれない
シングル・ブロック読み込み（1回の読み込み命令で1つの ・マルチ・ブロック読み込み（複数のデータ・ブロックを一回 ■オプティマイザー
データ・ブロックにアクセス）の読み込みで処理し全表スキャン時の読み込み回数を クエリ オプティマイザーでは、論理クエリ プランが作成さ ■表スペース・スキャン・アクセス■主キーを利用した一意索引スキャン
軽減）
れると、100以上から構成される物理操作プラン[*1]から 作成済みの一時表を介してアクセスされ、索引スキャン
索引からTIDを参照し、TIDにより表データ・ブロックにアク ■主キーを利用した一意索引スキャン
最も効率的な物理操作を選択するが不可能である場合に決定される
セス
索引からROWIDを参照し、ROWIDにより表データ・ブロッ■ハッシュ・アクセス■非一意索引スキャン
クにアクセス[*1] 主な物理操作プラン
検索条件式を使用した単一行にアクセスする照会で決定
一意索引スキャン同様■非一意索引スキャン
1. Clustered Index Delete
される■表結合
一意索引スキャン同様
WHERE 述語がある場合、その述語に適合する行だけが ■集約関数アクセス
ネスティッド・ループ結合、ソート･マージ結合、ハッシュ結 ■表結合
削除される
SQLステートメントで集約関数を選択した際に決定される合を実装
ネスティッド・ループ結合、ソート･マージ結合、ハッシュ結 2. Index Scan
■索引アクセス [*1]■オプティマイザ合を実装
列に指定された非クラスター化インデックスからすべての 索引を使用した 列・テーブル・ビューで指定される表にアコストベースオプティマイザ [*1][*2]■オプティマイザ
行を取得する
クセスする
コストベースオプティマイザ [*1][*2]
3. Table Scan
■INリスト・アクセス[*1]カラム間の相関関係などは考慮しない（複雑なクエリ列で指定されているテーブルからすべての行を取得する IN述部を含む照会に対して、INリスト索引スキャンまたはでは常に最適なプランが選択されるとは限らない）[*1]Oracle10gよりルールベースオプティマイザ(RBO)は動 4. Collapse、INリスト直接表アクセスのいずれかが決定される[*2]ヒント句機能はPostgreSQL拡張モジュールの作保証外になり一本化された更新処理が最適化されます。クエリ プロセッサでは、同じ ■直接行アクセス「pg_hint_plan」により実装[*2]ヒント句により表の特定のアクセス・パスを使用する キー値を削除して挿入する操作が隣接する行で検出され 条件に該当する行を見つめるのに、索引や表スペース・ように指示可能
ると、これらの個別の操作を 1 つのより効率的な更新操 スキャンの使用を必要としない場合に決定される。きわめ作に置き換えるて高速なアクセス方式[*1] 索引タイプ
特性は、「一般特性」と、「固有特性」の２つのカテゴリーに分けられる

同時実行性

9

読み取り一貫性を保ちながら同時実行性を実現するために採用している仕組み

MVCC（多版型同時実行制御）
MVCC（多版型同時実行制御）
ロック法
ロック法
・追記型アーキテクチャ（更新、削除の場合でも以前の行 ・DML（レコード操作）にて変更する前の情報はUNDO表 規定の設定ではロッキングメカニズム
既定の設定ではロッキングメカニズム
データは削除されず、ロールバックに必要な情報として残 領域内のUNDOセグメント領域に保存される）・あるセッションの変更がコミットされていない時に、ほか ■ペシミスティック同時実行制御
・作業単位（コミット操作、フル・ロールバック操作、または・あるセッションの変更がコミットされていない時に、ほか のセッションが同じ情報を参照する場合、UNDOセグメント ユーザーが他のユーザーに影響するデータの変更を行う アプリケーション・プロセスの終了）毎に、ロックをかけるのセッションが同じ情報を参照する場合、以前の行データ に保存された情報（参照時に確定されている情報）だけを ことを防止。ユーザがロックを解放するまで他のユーザは ・排他ロックは、別のトランザクションの全てのロックをブを参照する
参照
ロックと競合する操作を実行できない
ロッキングする■オプティミスティック同時実行制御
・共有ロック同士であれば競合は発生しない。ロックに互
データを読み取る時点ではロックされない。データを更新 換性があるするときに、そのユーザーが読み取ってから他のユーザーによる変更がなかったかを確認。他のユーザがデータ ■ペシミスティック・ロッキングを更新していた場合、エラーが発生する
・更新するデータの参照時に(U)ロックを取得
・他アプリケーションは、参照できるが更新できない・多バージョン法のサポート■オプティミスティック・ロッキング
SQL Server2005 からは、多バージョン法を使用した同時 ・参照から更新に間にロックを保持しない実行制御をサポート
・他アプリケーションは、参照・更新とも可能・参照から更新の間に、その行が他アプリケーションによって更新されていなければ、更新は成功する。その行が他アプリケーションによって、更新されていれば、更新は失敗する

ページ 3

【別紙】アーキテクチャ比較表
No.

アーキテクチャロック機構

説明
PostgreSQL
ロックの種類、リードで共有ロックを取得する 明示的ロック
かの違い、ロックエスカレーションの有無など テーブルレベルロック
行レベルロック
ページレベルロック
勧告的ロック10

トランザクション機構

オートコミットの動作の違い、サポートしているトランザクション分離レベルなど

11

OracleDMLロック
DDLロックSQL Server
共有(S)ロック
更新(U)ロック
排他(X)ロック■DMLロック
インテント ロック
複数のユーザが同時にアクセスするデータの整合性を保 スキーマ ロック
障する。
一括更新(BU)ロック
ロックエスカレーション機構なし（行レベルのロック量が増キー範囲えることによって、自動的にテーブルロックに変更される ・行ロック(TX)ことはない）
・表ロック(TM)・ロック単位として「ページロック」が存在する
・行共有表ロック(RS)・ロックエスカレーション機構あり■テーブルレベルロック
・行排他表ロック(RX)・行ロック、インデックスキー範囲ロックの際にそれらを含テーブルに対するロック・共有表ロック(S)んでいるページのページロックを掛ける場合や、表ロック■行レベルロック・共有行排他行ロック(SRX)にエスカレートする場合がある
同じ行に対する書き込みとロックだけをブロックする。異 ・排他表ロック(X)なる副トランザクション内であっても、同じ行に対して競合
・READ_COMMITTED_SNAPSHOT オプションがOFFの場ロックを保持できる
リードロックを取得しない（更新を前提としたデータ読み取 合、参照処理を行うと共有ロックを取得し、参照を完了す■ページレベルロック
りの際はFOR UPDATE句にて明示的に行ロックを取得す ると、共有ロックが開放される
ページレベルの共有/排他ロックがあり、これらは共有バ る必要がある）
ッファプールにあるテーブルページへの読み書きのアクセ ロックエスカレーション機構なし
スを管理するために使用される■勧告的ロック■DDLロック
独自の意味を持つロックを生成する手法。勧告的ロック スキーマ・オブジェクトの変更や参照を実行する可能性のの使用に関してシステムによる制限はない
あるDDL操作によって干渉がおきないように「排他DDLロック」「共有DDLロック」を提供する

DB2
Sロック（共有）Uロック（更新）
Xロック（排他）DML（レコード操作）は自動コミットされる。
DML（レコード操作）について自動でコミットはされない。 トランザクションの開始にはBEGIN TRANSACTION文をDDL（テーブル操作）は自動コミットされない。
DDL（テーブル操作）は暗黙コミットされる。
使う。DML（レコード操作）、DDL（テーブル操作）はトラン
トランザクション途中でエラーを出すと、最後にCOMMITを トランザクション途中でエラーを出し最後にCOMMITを行う ザクションの一部として扱われる。（コミットする前であれしても、ROLLBACKしたのと同じ扱いとなると、正常に実行できたDMLについては処理が確定する
ばロールバックすることができる）

BEGIN文を使わずとも自動的にトランザクションが開始する。DML（レコード操作）、DDL（テーブル操作）はトランザクションの一部として扱われる。（コミットする前であればロールバックすることができる）

トランザクション分離レベルは３種類をサポート[*1]・コミット読み取り(READ COMMITTED)・繰り返し可能読み取り(REPEATABLE READ) [*2]・直列可能(SERIALIZABLE)
規定の分離レベルは「コミット読み取り」

トランザクション分離レベルは全てサポート
・未コミット読み取り(READ UNCOMMITTED)
・コミット読み取り(READ COMMITTED)・繰り返し可能読み取り(REPEATABLE READ)
・直列可能(SERIALIZABLE)
規定の分離レベルは「コミット読み取り」

４つの分離レベルをサポート
・反復可能読み取り (RR) [*1]・読み取り固定 (RS) [*2]・カーソル固定 (CS) [*3]・非コミット読み取り (UR) [*4]
規定の分離レベルは「カーソル固定」

トランザクションは、暗黙的ではない。SQL文が実行されるたびに自動的にコミットされることを想定している[*1]ISO分離レベルのSerializableに相当[*2]ISO分離レベルのRepeatable Readに相当[*3]ISO分離レベルのRead Committedに相当[*4]ISO分離レベルのUncommitted Readに相当

定期間隔で検知

定期間隔で検知

トランザクション分離レベルは以下をサポート
・コミット読み取り(Read Committed)
・シリアライズ（直列化）可能(Serializable)
規定の分離レベルは「コミット読み取り」[*1]未コミット読み取り(READ UNCOMMITTED)も指定可
能であるが、PostgreSQLではコミット読み取りとして扱われる[*2]PostgreSQLの実装ではファントムリードの可能性がない
デッドロック検知

状況検知

データ・ディクショナリ

メタデータ（データベース内のオブジェクト、表 ・「情報スキーマ」ビュー [*1]
領域、ユーザ、権限などの情報）へのアクセ ・システムカタログ（表およびビュー） [*2]
スがどのように提供されているか[*1]標準SQLで定義されたビュー[*2]PostgreSQL固有の機能についての情報はシステムカタログから取得する必要がある「データ・ディクショナリ・ビュー」を介してOracleが管理するディクショナリ表の情報を取得・利用する

動的パフォーマンス情報の取得

システムパラメータ、メモリ使用量/割当て、 ・統計情報ビュー
統計情報などへのアクセスがどのように提供 ・統計情報アクセス関数
されているか
データを複数の物理ファイルに分散配置する テーブルスペース機能を用いて表データファイルを別の仕組み
物理ディスク上に配置することは可能
パーティショニング機能についてはpgpool-II等の別の機構を併用する必要がある

動的パフォーマンス・ビュー

13I/O分散
15

ロック待ち検出→状態検査による検知■ロックの保持/開放
・作業単位が完了するまで、ロックが保持される・分離レベルCSでは、カーソルを移動すると開放。分離レ
ベルRSでは、選択行にロックが残る。分離レベルRRでは、走査行にロックが残る。カーソルをcloseしてもロックは外れない・カーソルが行にある間リードロックを取得する（更新を前提としたデータ読み取りの場合はトランザクション分離レベルを設定して他のトランザクションからの更新を防ぐ必要がある）
挿入、更新、削除は分離レベルとは関係なく対象となる行のすべての排他ロックが取得される。ロックエスカレーショ
ン機構あり。ロックを管理するメモリ領域の設定を行い、ロックエスカレーションを発生させないようチューニングするパラメータで指定した時間を超えてトランザクションがロッ デッドロック状況を自動的に検出し、デッドロックに含まれ ロックモニタースレッドにより定期間隔毎に検出を行う
データベース構成パラメータに指定した間隔で定期検出ク待ちしている場合、デッドロックの可能性があると判断 る文の1つをロールバックして競合する一連の行ロックを [*1]。対象のトランザクションをロールバックして、アプリケ を行う。デッドロックプロセスを任意に選択し、エラーを返してロック状態を検査する。デッドロックが検出されれば、 解放し、デッドロックを解決する。文レベルのロールバック ーションにエラーを返す。既定ではロールバックに最もコ 却して非コミット・トランザクションを自動的にロールバック
1つのトランザクションを強制的にロールバックするの対象となったトランザクションにメッセージを通知する
ストのかからないトランザクションを実行しているセッショ するンがデッドロックの対象として選択される

1214

デッドロック検出の仕組み

各ロックは行または、ページロックが適用される[*1]既定の間隔は5秒で、デッドロックが検出されると短い時間になり、検出されなくなると5秒に引き上げられる「システム ビュー」の「カタログ ビュー」を介してカタログ メ 「システム・カタログ・ビュー」が設けられている。
タデータの情報を取得・利用する（SYSCATビュー および SYSSTATビュー）
また、Oracle データ・ディクショナリー互換ビューをサポートしている・動的管理ビュー
・動的管理関数スナップショット・モニター SQL 管理ビュー(SYSIBMADMスキーマ)

パーティション機能を用いてデータファイルを複数の物理 表領域に複数のデータファイルを割り当てし、分散配置さ 表スペース（表領域）に対して複数の「コンテナ」を配置しディスクに分散配置するれたファイルを複数の物理ディスクに配置する、複数の物理ディスクに分散する

ページ 4