Troubleshooting
Problem
Symptom
V10.5では問題が無く実行できたSQL文がSQL0802Nで失敗しました。テーブル定義およびテーブルデータの変更はありません。db2exfmtを使ってOPTIMIZED STATEMENTを比較したところ以下の特徴がが見られました。
Original Statement:
------------------
SELECT ...
(SELECT SUM(T1.C1) FROM T1 WHERE T1.C2 = T2.C1)
...
(SELECT SUM(T1.C1) FROM T1 WHERE T1.C2 = T2.C1)
...
(SELECT SUM(T1.C1) FROM T1 WHERE T1.C2 = T2.C1)
...
) FROM T2
Original Stetementは、同じ副照会を複数指定していますが、Optimized Statement では、共通の副照会を一度に実行しGROUP BY で C1 の値でまとめた後、WHERE で抽出しているようです。V10.5では、このような変換は行われていませんでした。
Optimized Statement:
-------------------
SELECT ...
(SELECT
Q11.$C0
FROM
(SELECT
SUM(Q10.C1),
Q10."C2
FROM
(SELECT
Q9.C1,
Q9.C2
FROM
T1I AS Q9
) AS Q10
GROUP BY
Q10.C1
) AS Q11
WHERE
(Q11.C1 = Q8.C2)
) AS Q12
Cause
しかし、この変換を行うともとの SQL では実行されないデータに対しても SUM が実行され、それが算術桁溢れを引き起こす可能性があります。
以下の例では、表 T1 は、T1 (C1 INT, C2 INT, ... のように定義されて、以下のデータを持ちます。
例：
T1 = (1, 100, ...),(1, 200, ...),(2, 1000, ...),(2, 2000, ...), (999, 2147483647, ...),(999, 2147436847, ...).
T2 = (1, ...),(2, ...)
もとの SQL がそのまま実行された場合、SUM は C1=1 および C1=2 のを持つ行の C2 列に対してしか実行されませんが、上記の Optimized Statement で実行された場合には、C1=999を持つ２行に対しても SUM が実行されます。その場合、2147483647+2147483647は INTEGER の上限を超えるため、SQL0802N エラーが発生します。
Resolving The Problem
- レジストリ変数を設定して照会書き換えの動作をを Db2 10.5 以前と同様に戻します。
db2set -im DB2COMPOPT=NO_GBPRDPU - 桁溢れが起きたカラムの定義を変更します。例えば、上の例では C1 の型を INT から BIGINT に変えることで回避できます。
SQL0802N 算術オーバーフローまたはその他の算術例外が発生しました。
パスポート・アドバンテージによく寄せられる質問
お問い合わせ先
技術的な内容に関して、パスポート・アドバンテージの契約のもと Db2 テクニカル・サポートへお問い合わせください。
Db2 テクニカル・サポート
Was this topic helpful?
Document Information
Modified date:
14 August 2023
UID
swg22011444