コンテンツにスキップ
5.8 制約、エラー、トラブルシューティング

5.8 制約、エラー、トラブルシューティング

このページのUPDATE実習はStandard Editionを前提とします。まず次のテーブルを作成し、 正常なSQLと意図的に失敗するSQLを区別して実行します。失敗例を正常なスクリプトにまとめて 入れないでください。同名の既存オブジェクトは削除しません。

CREATE TAG TABLE ch5_error_time (
    name VARCHAR(64) PRIMARY KEY,
    time DATETIME BASETIME,
    value DOUBLE,
    status INTEGER
) METADATA (location VARCHAR(64));
INSERT INTO ch5_error_time METADATA VALUES ('sensor-01', 'zone-1');
INSERT INTO ch5_error_time METADATA VALUES ('sensor-02', 'zone-2');
INSERT INTO ch5_error_time VALUES
    ('sensor-01', TO_DATE('2026-07-01 12:00:00', 'YYYY-MM-DD HH24:MI:SS'), 10.0, 0);
INSERT INTO ch5_error_time VALUES
    ('sensor-02', TO_DATE('2026-07-01 12:00:00', 'YYYY-MM-DD HH24:MI:SS'), 20.0, 0);
CREATE TAG TABLE ch5_error_distance (
    name VARCHAR(64) PRIMARY KEY,
    distance DOUBLE BASEDISTANCE,
    value DOUBLE SUMMARIZED
);

TAG data UPDATEのWHERE条件エラー

WHERE句にはタグの選択条件とBASETIME条件の両方が必要です。 条件が曖昧な場合や許可されていない形式の場合、UPDATEは拒否されます。

必須条件

WHERE name ...形式のタグ選択条件とtime ...形式のBASETIME条件をともに指定します。 条件なしの全件UPDATE、タグ条件だけのUPDATE、時間条件だけのUPDATEは許可されません。

症状

次のようなUPDATEがエラーとして拒否されます。

-- 時間条件なし
UPDATE ch5_error_time SET value = 99.9
WHERE name = 'sensor-01';

-- タグ選択条件なし
UPDATE ch5_error_time SET value = 99.9
WHERE time >= TO_DATE('2026-07-01', 'YYYY-MM-DD');

-- OR条件を使用
UPDATE ch5_error_time SET value = 99.9
WHERE name = 'sensor-01'
   OR name = 'sensor-02';

原因

対象タグと時間範囲を明確に制限できない条件は拒否されます。

条件の形式サポート
name = 'sensor-01' AND time >= ...O
name IN ('sensor-01', 'sensor-02') AND time BETWEEN ...O
name LIKE 'sensor-%' AND time < ...O
value > 10のみX
name = 'sensor-01'のみX
time >= ...のみX
OR、サブクエリ、集計条件X

解決方法

タグ選択条件と時間条件をともに明示します。

UPDATE ch5_error_time
   SET value = 99.9
 WHERE name = 'sensor-01'
   AND time = TO_DATE('2026-07-01 12:00:00', 'YYYY-MM-DD HH24:MI:SS');

UPDATE ch5_error_time
   SET status = 1
 WHERE name IN ('sensor-01', 'sensor-02')
   AND time >= TO_DATE('2026-07-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
   AND time <  TO_DATE('2026-07-02 00:00:00', 'YYYY-MM-DD HH24:MI:SS');

NAMEまたはTIMEのバインドがERR-02190で拒否される場合

Machbase 8.7.0以降のStandard Editionでは、次のようにNAMEとBASETIMEの条件値に バインドパラメーターを使用できます。

UPDATE ch5_error_time
   SET value = ?
 WHERE name = ?
   AND time = ?;

タグ選択条件とBASETIME条件の両方があるにもかかわらず、この文が ERR-02190: Invalid UPDATE/DELETE condition. Specify it as (primary key column) = (value)で 拒否される場合は、サーバーバージョンを確認します。旧バージョンのサーバーはTAG data UPDATEの NAME/TIMEバインドをサポートしていません。サーバーを8.7.0以降にアップグレードし、名前付きマーカーを 使用する場合は該当する名前付きAPIをサポートする8.7.0 SDKも使用します。

?の例はSDKで準備・バインドするSQLであり、machsqlで値を指定せずそのまま実行する文ではありません。 同じプリペアドステートメントを再利用する際は、SET、NAME、TIMEの値をすべて再バインドします。 マーカーの詳細な規則は TAG data UPDATEのバインドを 参照してください。

大量のUPDATEの前には、同じWHERE条件でSELECT COUNT(*)を実行し、変更対象の行数を確認します。

TAG data UPDATEのSET対象列エラー

SET句は実際のデータ列だけを対象とします。PRIMARY KEY、BASETIME、メタデータ列を SETの対象に指定するとエラーになります。

SETの対象

valueとユーザーデータ列はUPDATEできます。nametime、METADATAブロックの列は TAG data UPDATEのSET対象ではありません。

症状

-- エラー: PRIMARY KEY列(name)の更新を試行
UPDATE ch5_error_time
   SET name = 'new-sensor'
 WHERE name = 'old-sensor'
   AND time >= TO_DATE('2026-07-01', 'YYYY-MM-DD');

-- エラー: BASETIME列(time)の更新を試行
UPDATE ch5_error_time
   SET time = NOW
 WHERE name = 'sensor-01'
   AND time >= TO_DATE('2026-07-01', 'YYYY-MM-DD');

-- エラー: メタデータ列をdata UPDATEで変更
UPDATE ch5_error_time
   SET location = 'zone-2'
 WHERE name = 'sensor-01'
   AND time >= TO_DATE('2026-07-01', 'YYYY-MM-DD');

列の種類別のUPDATE可否

列の種類説明data UPDATE
PRIMARY KEY (name)TAGを識別する一意キーX
BASETIME (time)時系列データのタイムスタンプX
データ列(value、補助列)実際の行の値O
SUMMARIZEDデータ列統計対象のデータ列O
メタデータ列METADATAブロックのタグ属性X

解決方法

データ値は通常のUPDATEで変更します。

UPDATE ch5_error_time
   SET value = 99.9,
       status = 1
 WHERE name = 'sensor-01'
   AND time = TO_DATE('2026-07-01 12:00:00', 'YYYY-MM-DD HH24:MI:SS');

メタデータには別の構文を使用します。

UPDATE ch5_error_time METADATA
   SET location = 'zone-2'
 WHERE name = 'sensor-01';

タグ名や時間軸を変更する必要がある場合は、新しいname/time値でデータを挿入してから、 運用ポリシーに従って既存データを削除します。

BASE DISTANCE TAG STATの列エラー

Machbase 8.7.0はBASE DISTANCE TAGのV$<TABLE>_STATの軸列を距離の名前と数値型で 提供します。アップグレード前のSQLがMIN_TIMEMAX_TIMERECENT_ROW_TIMEなどを検索すると、 列が見つからないエラーになる場合があります。

症状

  • アップグレード後、BASE DISTANCE統計ビューの従来の*_TIME列を検索できません。
  • 旧バージョンのサーバーでは、距離値がDATETIMEとして解釈され、意味のない日付に見える場合があります。
  • Cluster EditionでStandardと同じ位置ベースの結果マッピングを使用すると、先頭のHOSTNAMEに より後続列の対応がずれる場合があります。

診断

対象テーブルの軸と実際の統計ビュースキーマをともに確認します。

DESC ch5_error_distance;
DESC V$CH5_ERROR_DISTANCE_STAT;

BASE DISTANCEテーブルの場合、MIN_DISTANCEMAX_DISTANCEMIN_VALUE_DISTANCEMAX_VALUE_DISTANCERECENT_ROW_DISTANCEが元の距離軸の型で表示される必要があります。 Cluster EditionではHOSTNAME VARCHAR(64)が先頭列に追加されます。

解決方法

  1. SQLの従来の*_TIME名を、対応する*_DISTANCE名に変更します。
  2. SDKの結果マッピングをDATETIMEから元のDOUBLELONGULONG型に変更します。
  3. Clusterの結果は列名で読み取るか、HOSTNAMEを含めた位置番号を再確認します。
  4. BASE TIME TAGのクエリは従来の*_TIME DATETIMEマッピングを維持します。

全変換表とCluster集計の注意事項は タグ別統計ビューを参照してください。

制約と注意事項

機能のサポート範囲

機能状態
実際の時系列データのUPDATEStandard Editionでサポート(タグ/BASETIME条件が必要)
メタデータのUPDATEサポート(UPDATE ... METADATA
DELETEサポート(BEFORE、タグ/軸条件、または全削除)
複数のPRIMARY KEY非サポート(単一列のみ)
BASETIMEとBASEDISTANCEの同時使用非サポート
TAG DATAの通常列のALTER ADD/DROP非サポート
TAG METADATA列のALTER ADD/DROPサポート(Standard Edition)

タグ数の制限

  • 単一のTAGテーブルに作成できるタグ数はシステム設定によって制限されます。
  • タグ数が増えるとタグインデックスとメタデータのメモリ使用量も増えるため、本番規模のデータで 検索・入力性能を測定します。
  • タグ名がレコードごとに一意になる設計は避けてください(アンチパターン:センサーごとのテーブル作成を参照)。

遅延到着データ

  • BASETIME列には任意の過去時刻を挿入できます。
  • 遅延到着データが多いワークロードでは、実際の入力レートと検索性能を別途測定します。

Cluster Editionのサポート

TAGテーブルはCluster Editionでサポートされています。

ただしTAG data UPDATEはStandard Edition専用で、Cluster Editionではサポートされません。

まとめ

TAGテーブル = センサー名 (PK) + 時間/距離軸 + 計測値
- INSERT/APPEND: O
- UPDATE: 実際のDATAはStandard Editionのタグ/BASETIME条件、METADATAは別のSQL
- DELETE: O (BEFOREまたはタグ/軸条件)
- METADATA: O (別途属性を保存、UPDATE可能)

次に読む内容

実習の後片付け

正常な変更結果をSELECTで確認し、今回の実習テーブルのみ削除します。

SELECT name, time, value, status FROM ch5_error_time ORDER BY name, time;
DROP TABLE ch5_error_time;
DROP TABLE ch5_error_distance;
最終更新日