LOB型は、TEXT、BLOB、JSON、Geometryなどのデータ型を格納するために使用されます。 LOBの格納方式には、インラインストレージ（INROW）とアウトラインストレージ（OUTROW）の2種類があります。
インラインストレージ
インラインストレージでは、LOBデータを主表の行と一緒に格納します。LOBデータを読み取る際には、ストレージへのアクセス操作を1回だけ行えば済みます。
アウトラインストレージ
アウトラインストレージでは、LOBデータをLOB補助表に格納します。LOBデータを読み取る際には、まず主表の行を読み取ってアウトラインLOBのロケーター（locator）を取得し、その後そのロケーター情報に基づいてLOB補助表から実際のLOBデータを読み取ります。このプロセスでは、ストレージへのアクセス操作を2回行う必要があります。
LOBタイプ
Oracleモードでは、一般的なLOBタイプには以下のものが含まれます：
- BLOB（Binary Large Object）：バイナリ大型オブジェクトの略で、通常は画像、ファイル、音楽などの大容量ファイル情報を格納するために使用されます。
- CLOB（Character Large Object）：文字大型オブジェクトの略で、単一字節および複数字節の文字データを格納するために使用されます。
- JSON：JSON形式のデータを格納するために使用され、構造化データの処理によく用いられます。
- SDO_GEOMETRY：幾何図形データを格納および処理するためのデータ型です。これは複合データ型であり、二次元または三次元の幾何図形を表現するために使用されます。
- XMLType：XML形式のデータを格納するために使用され、XMLドキュメントの処理とクエリを容易にします。
説明
XMLTypeは、従来のLOBタイプとはいくつか異なります。実際にはユーザー定義型（UDT）であり、内部にBLOBフィールドを含んでいます。
LOB一貫性検証
説明
この機能はV4.4.2 BP3バージョンからサポートされています。
外部ストレージを使用する場合、主表とLOB補助表はLOB IDによって関連付けられます。主表のロケータに含まれるLOB IDの集合は、LOB補助表に存在するLOB IDの集合と一致している必要があります。「主表にはあるが補助表にはない」または「補助表にはあるが主表にはない」といった不整合が発生した場合、読み取り異常やスペース回収不能などの問題が生じる可能性があります。
この機能は、LOB検証タスク（LOB Task）を通じて主表をスキャンしてLOB IDの集合を収集し、LOB補助表のスキャン結果と比較して、一致の有無と差異情報を出力します。これにより、オフピーク時の巡回検査や障害調査時にデータ関係が正常であるか確認することが容易になります。
注意
検証では主表とLOB補助表の関連データをスキャンするため、I/OとCPUに一定の負荷がかかります。業務のオフピーク時に実行し、以下の手順でタスクに適切なリソースグループを設定してください。
リソースグループとI/Oベンチマークの併用方法
LOB一貫性検証では主表とLOB補助表をスキャンするため、I/OとCPUの負荷が高くなります。検証タスクにI/O上限などの制限を設定する場合は、テナント側のディスクI/Oベンチマーク（I/Oキャリブレーションによって生成される）に依存します。デプロイメント形態に応じた推奨事項は以下の通りです：
- パブリッククラウドなど、既にI/Oキャリブレーションが完了している環境：通常はテナント内で直接リソース管理計画とリソースグループを設定できます。
- プライベートクラウドやI/Oキャリブレーションを行っていない環境：システムテナントでディスクI/Oキャリブレーションを完了した後、ベンチマークに基づいてビジネステナントのUnitの
MAX_IOPS/MIN_IOPSを計画し、リソースグループのI/O制限と組み合わせてください。キャリブレーションコマンド、進捗状況の確認、およびバックグラウンドタスクのリソース分離の関係については、バックグラウンドタスクのリソース分離を参照してください。ディスク性能キャリブレーションの手順については、ディスク性能キャリブレーションを参照してください。
全体の例
一貫性検証機能を使用する場合は、まずI/Oキャリブレーションを行い、次にLOB検証専用のリソース計画を作成し、リソース管理計画とリソースグループを設定する必要があります。
ステップ１：I/Oキャリブレーション（オプション）
I/Oキャリブレーションを行っていない場合は、システムテナントでI/Oキャリブレーションを実行する必要があります。キャリブレーション完了から反映までには1～2分かかる場合があります。
注意
この部分のコマンドはシステムテナントで実行する必要があります。
ALTER SYSTEM RUN JOB 'io_calibration';
キャリブレーション完了後、GV$OB_IO_CALIBRATION_STATUSでキャリブレーションタスクの状態を確認し、GV$OB_IO_BENCHMARKで各ノードのベンチマークIOPSを確認できます。テナントにUnit IOPSを設定する際は、ベンチマーク（例：16KB読み取りに対応するIOPS）を基準に約10%の余裕を持たせることを推奨します。これにより、ディスク満杯によるオンライン業務の遅延を防ぐことができます。
SELECT * FROM GV$OB_IO_CALIBRATION_STATUS;
SELECT * FROM GV$OB_IO_BENCHMARK;
ステップ2：LOB検証専用リソース計画の作成
検証を実行するビジネステナント内で、別途リソース計画を作成し、LOB検証関連のバックグラウンドタスクを専用リソースグループにマッピングしてCPUとIOPSを制限することができます。以下の例では、計画名をLOB_CHECK、リソースグループ名をLOB_CHECKとし、FUNCTIONマッピングを使用して値LOB_CHECKを持つバックグラウンドタスクをそのグループに割り当てます。MGMT_P1、UTILIZATION_LIMIT、MAX_IOPS、MIN_IOPS、WEIGHT_IOPSなどは、実際の仕様に応じて調整してください。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN('LOB_CHECK', 'plan for lob_check');
END;
/
BEGIN DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('LOB_CHECK', 'LOB_CHECK');
END;
/
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
PLAN => 'LOB_CHECK',
GROUP_OR_SUBPLAN => 'LOB_CHECK',
COMMENT => 'LOB_CHECK_GROUP',
MGMT_P1 => 30,
UTILIZATION_LIMIT => 30,
MAX_IOPS => 20,
MIN_IOPS => 0,
WEIGHT_IOPS => 20);
END;
/
BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING('FUNCTION', 'LOB_CHECK', 'LOB_CHECK');
END;
/
説明
MySQLモードで一般的なCALL DBMS_RESOURCE_MANAGER.*の書き方とは異なり、Oracleモードのテナントでは通常、BEGIN ... END;匿名ブロックを使用してリソース管理関連のプロシージャを呼び出します。
リソース管理計画を有効にした後、上記のマッピングと制限がセッションおよびバックグラウンドタスクに反映されます。
SET GLOBAL resource_manager_plan = 'LOB_CHECK';
resource_manager_planの意味と注意点については、resource_manager_planを参照してください。
DBMS_RESOURCE_MANAGERプロシージャ、パラメータ、権限の説明については、DBMS_RESOURCE_MANAGERの概要およびテナント内のリソース分離の設定（Oracleモード）を参照してください。
ステップ3：スケジュールタスクの設定（オプション）
LOB一貫性検証を定期的に実行する必要がある場合は、スケジュールタスクを手動で有効にできます。有効にすると、デフォルトで毎週日曜日の午前4時に実行されます。
-- タスクの開始
CALL DBMS_SCHEDULER.ENABLE('lob_check_job');
-- タスクの停止
CALL DBMS_SCHEDULER.DISABLE('lob_check_job');
-- スケジュールタスクの実行間隔と開始時間の変更
CALL DBMS_LOB_MANAGER.RESCHEDULE_JOB('2025-12-01 17:48:00', 'FREQ=DAILY; INTERVAL=1');
スケジュールタスクの情報を確認する：
SELECT * FROM DBA_SCHEDULER_JOBS WHERE job_name='lob_check_job';
ステップ4：LOB一貫性検証の実行
-- 現在のテナントに含まれるすべてのLOB補助表を持つデータテーブルの一貫性検証をトリガーする
CALL DBMS_LOB_MANAGER.CHECK_LOB();
-- 指定されたtable_idのテーブルのみの一貫性検証をトリガーする
CALL DBMS_LOB_MANAGER.CHECK_LOB('[500001, 500003]');
-- タスクの制御（検証タスクのみ）
CALL DBMS_LOB_MANAGER.CANCEL_JOB('check_lob');
CALL DBMS_LOB_MANAGER.SUSPEND_JOB('check_lob');
CALL DBMS_LOB_MANAGER.RESUME_JOB('check_lob');
ステップ5：LOB一貫性検証結果の確認
DBA_OB_LOB_CHECK_TASKSで現在のLOBタスクの進捗状況を確認し、DBA_OB_LOB_CHECK_EXCEPTION_RESULTで例外結果を確認します。
SELECT * FROM DBA_OB_LOB_CHECK_TASKS;
SELECT * FROM DBA_OB_LOB_CHECK_EXCEPTION_RESULT;