LOB 型は、TEXT、BLOB、JSON、Geometryなどのデータ型を格納するために使用されます。 LOB の格納方式には、インラインストレージ（INROW）とアウトラインストレージ（OUTROW）の2種類があります。
インラインストレージ
インラインストレージは、LOBデータをメインテーブルの行と一緒に格納する方式です。LOBデータを読み取る際には、ストレージへのアクセス操作を1回だけ行えば済みます。
アウトラインストレージ
アウトラインストレージは、LOBデータをLOB補助テーブルに格納する方式です。LOBデータを読み取る際には、まずメインテーブルの行を読み取ってアウトラインLOBのロケーター（locator）を取得し、その後そのロケーター情報に基づいてLOB補助テーブルから実際のLOBデータを読み取ります。このプロセスでは、ストレージへのアクセス操作を2回行う必要があります。
LOBストレージの変換
LOBデータのストレージがインラインストレージかアウトラインストレージかは、LOB列のデータサイズによって決まります。しきい値を8192バイトに設定した場合、8192バイトを超えるとアウトラインストレージとして扱われ、それ以下の場合はインラインストレージとして扱われます。
obclient> CREATE TABLE t(pk int, data text) LOB_INROW_THRESHOLD = 8192;
上記のDDLは、テーブル内のLOB列のINROWからOUTROWへの変換しきい値を8192バイトに指定しています。ここで LOB_INROW_THRESHOLD はLOB列のしきい値を表します。
- LOB列のデータが8192バイト以下の場合、LOBデータとメインテーブルの行が一緒に格納されます。
- LOB列のデータが8192バイトを超える場合、すべてのデータがLOB補助テーブルに格納されます。
説明
lob_inrow_thresholdの値を大きくから小さく変更するには、Offline DDLをトリガーする必要があります。
インラインストレージはアウトラインストレージに比べてパフォーマンスが優れており、ストレージへのアクセス回数を減らしてLOBデータの読み取り効率を向上させます。特にLOBデータへの頻繁なアクセスが必要なシナリオでは、インラインストレージを選択することでクエリ速度を高速化し、システムオーバヘッドを低減できます。
LOBタイプ
MySQLモードでは、一般的なLOBタイプをアルファベット順に以下のように並べます：
- ARRAY：配列データ型を格納するために使用され、複数の値の集合を格納できます。
- Roaringbitmap：ビットマップデータを格納するために使用され、主に画像処理と表現に用いられます。
- BLOB（Binary Large Object）：画像やファイルなどのバイナリデータを格納するために使用され、最大長は65,535バイトです。
- GEOMETRY：地理空間データを格納するために使用され、空間分析と操作をサポートします。
- JSON：JSON形式のデータを格納するために使用され、構造化データの処理を容易にします。
- LONGTEXT：大量のテキストデータを格納するために使用され、最大長は536,870,910バイトです。
- LONGBLOB：大量のバイナリデータを格納するために使用され、最大長は536,870,910バイトです。
- MEDIUMBLOB：中量のバイナリデータを格納するために使用され、最大長は16,777,215バイトです。
- MEDIUMTEXT：中量のテキストデータを格納するために使用され、最大長は16,777,215バイトです。
- TEXT：少量のテキストデータを格納するために使用され、最大長は65,535バイトです。
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検証専用のリソース計画を作成し、リソース管理計画とリソースグループを設定する必要があります。
ステップ1：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;
テナントにUnitレベルのIOPSを設定する際は、GV$OB_IO_BENCHMARKで照会したIOPSのベンチマーク値を基準に、その約10%の余裕を持たせることを推奨します（例えば、16KBに対応するIOPSの90%を設定値とする）。これにより、ディスクリソースをフル活用した際にボトルネックが発生するのを防ぎ、フロントエンドSQLの応答時間が影響を受けないように保証できます。
ステップ2：LOB検証専用リソース計画を作成する
検証を実行するビジネステナント内で、別途リソース計画を作成し、LOB検証関連のバックグラウンドタスクを専用リソースグループにマッピングしてCPUとIOPSを制限します。以下の例では、計画名をLOB_CHECK、リソースグループ名をLOB_CHECKとし、FUNCTIONマッピングを使用して値LOB_CHECKを持つバックグラウンドタスクをそのグループに分類します。MGMT_P1、UTILIZATION_LIMIT、MAX_IOPS、MIN_IOPS、WEIGHT_IOPSなどは、実際の仕様に応じて調整してください。
DBMS_RESOURCE_MANAGERの各サブプログラムの構文とパラメータの説明については、DBMS_RESOURCE_MANAGERの概要を参照してください。
CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN('LOB_CHECK', 'plan for lob_check');
CALL DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP( CONSUMER_GROUP => 'LOB_CHECK', COMMENT => 'LOB_CHECK');
CALL 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);
CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING('FUNCTION', 'LOB_CHECK', 'LOB_CHECK');
リソース管理計画を有効にすると、上記のマッピングと制限がセッションおよびバックグラウンドタスクに反映されます。
SET GLOBAL resource_manager_plan = 'LOB_CHECK';
resource_manager_planの意味と注意点については、resource_manager_planを参照してください。
ステップ3：スケジュールタスクを設定する（オプション）
注意
この部分のコマンドはビジネステナントで実行する必要があります。
LOB一貫性検証を定期的に実行する必要がある場合は、スケジュールタスクを作成できます。
タスクの開始：デフォルトでは無効なので、手動で有効にする必要があります。デフォルトの実行時間は毎週日曜日の午前4時です。
CALL DBMS_SCHEDULER.ENABLE('lob_check_job');スケジュールタスクの停止
CALL DBMS_SCHEDULER.DISABLE('lob_check_job');スケジュールタスクの実行間隔と開始時間の変更
CALL DBMS_SCHEDULER.ENABLE('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';実行結果の例は以下のとおりです：
*************************** 1. row *************************** OWNER: SYS JOB_NAME: lob_check_job JOB_SUBNAME: NULL JOB_STYLE: REGULAR JOB_CREATOR: NULL CLIENT_ID: NULL GLOBALUid: NULL PROGRAM_OWNER: SYS PROGRAM_NAME: NULL JOB_TYPE: PLSQL_BLOCK JOB_ACTION: DBMS_LOB_MANAGER.CHECK_LOB_INNER() NUMBER_OF_ARGUMENTS: NULL SCHEDULE_OWNER: NULL SCHEDULE_NAME: NULL SCHEDULE_TYPE: NULL START_DATE: 2025-12-01 17:48:00.000000 +08:00 REPEAT_INTERVAL: FREQ=DAILY; INTERVAL=1 EVENT_QUEUE_OWNER: NULL EVENT_QUEUE_NAME: NULL EVENT_QUEUE_AGENT: NULL EVENT_CONDITION: NULL EVENT_RULE: NULL FILE_WATCHER_OWNER: NULL FILE_WATCHER_NAME: NULL END_DATE: 4000-01-01 00:00:00.000000 +08:00 JOB_CLASS: DEFAULT_JOB_CLASS ENABLED: 1 AUTO_DROP: 0 RESTART_ON_RECOVERY: NULL RESTART_ON_FAILURE: NULL STATE: NULL JOB_PRIORITY: NULL RUN_COUNT: NULL MAX_RUNS: NULL FAILURE_COUNT: 0 MAX_FAILURES: NULL RETRY_COUNT: NULL LAST_START_DATE: NULL LAST_RUN_DURATION: +000000000 02:00:00.000000 NEXT_RUN_DATE: 2025-12-23 17:48:00.000000 +08:00 SCHEDULE_LIMIT: NULL MAX_RUN_DURATION: +000 02:00:00 LOGGING_LEVEL: NULL STORE_OUTPUT: NULL STOP_ON_WINDOW_CLOSE: NULL INSTANCE_STICKINESS: NULL RAISE_EVENTS: NULL SYSTEM: NULL JOB_WEIGHT: NULL NLS_ENV: NULL SOURCE: NULL NUMBER_OF_DESTINATIONS: NULL DESTINATION_OWNER: NULL DESTINATION: NULL CREDENTIAL_OWNER: NULL CREDENTIAL_NAME: NULL INSTANCE_ID: NULL DEFERRED_DROP: NULL ALLOW_RUNS_IN_RESTRICTED_MODE: NULL COMMENTS: LOB consistency check job, runs weekly to check LOB data consistency FLAGS: 0 RESTARTABLE: NULL CONNECT_CREDENTIAL_OWNER: NULL CONNECT_CREDENTIAL_NAME: NULL 1 row in setタスクがトリガーされた後、LOB検証タスクの進捗状況を確認するには、
oceanbase.DBA_OB_LOB_CHECK_TASKSビューを照会します。例は以下のとおりです。SELECT * FROM DBA_OB_LOB_CHECK_TASKS;実行結果の例は以下のとおりです：
+-------+-------------+----------+-----------+---------+---------------------+---------------------+--------------+------------+----------+------------------+------------+-------------+------------+-----------+-------------+ | LS_ID | TABLE_NAME | TABLE_ID | TABLET_ID | TASK_ID | START_TIME | END_TIME | TRIGGER_TYPE | STATUS | MISS_CNT | MISMATCH_LEN_CNT | ORPHAN_CNT | CORRECT_CNT | RET_CODE | TASK_TYPE | SCAN_INDEX | +-------+-------------+----------+-----------+---------+---------------------+---------------------+--------------+------------+----------+------------------+------------+-------------+------------+-----------+-------------+ | -1 | NULL | -3 | -3 | 1 | 2025-12-23 17:48:00 | 2025-12-23 17:48:00 | PERIODIC | TRIGGERING | 0 | 0 | 0 | 0 | OB_SUCCESS | LOB_CHECK | PRIMARY KEY | | 1 | __all_table | 3 | 3 | 1 | 2025-12-23 17:48:02 | 2025-12-23 17:48:02 | PERIODIC | PREPARED | 0 | 0 | 0 | 0 | OB_SUCCESS | LOB_CHECK | PRIMARY KEY | +-------+-------------+----------+-----------+---------+---------------------+---------------------+--------------+------------+----------+------------------+------------+-------------+------------+-----------+-------------+ 2 rows in setDBMS_LOB_MANAGER.RESCHEDULE_JOBを使用してスケジュールを変更した後、DBA_SCHEDULER_JOBSでNEXT_RUN_DATEなどのフィールドを確認できます。
ステップ4：LOB一貫性検証を実行する
LOB一貫性検証を手動でトリガーする
-- このテナントのすべてのLOB補助テーブルの一貫性検証をトリガーする CALL DBMS_LOB_MANAGER.CHECK_LOB(); -- このテナントのtable_idがこの配列内にあるテーブルのLOB一貫性検証をトリガーする 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");スケジュールタスクの実行間隔と開始時間を変更する
CALL DBMS_LOB_MANAGER.RESCHEDULE_JOB('2025-12-01 17:48:00', 'FREQ=DAILY; INTERVAL=1');
ステップ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;