Tsurugi 1.11.0 - Known Issues (ja)

[akirakw]

1.11.0 既知の問題

解決された問題

以下は本バージョンで解決された問題です。

TSURUGI-IS-177 DML処理中にDDLを実行するとデータベースが不安定な状態になる

問題:
SELECT 文や INSERT 文等の DML の実行中に CREATE TABLE 文や DROP TABLE 文等の DDL が実行されると、データベースが不安定な状態になることがあります。
このような状態を避けるため、DML 実行前に DDL をあらかじめ実行しておくなどして、DDL と DML でその実行時間が互いにオーバーラップしないように注意してください。

ステータス:

バージョン 1.6.0 でDDL実行時の対象テーブル閉塞に対応しました。
対象テーブルに対してDML処理とDDL処理のトランザクションが競合する場合にエラーとすることで、データベースの不安定な状態に陥ることを防止します。

バージョン 1.11.0 でDMLとDDLを同一のトランザクション内で実行した場合の挙動について改善しました。
DMLとDDLの両方を同一のトランザクション内で処理可能なケースにおいて、実行時に不安定となる問題を解決しました。

既知の問題

以下は本バージョンで未解決な問題です。
特別な記載が無い限り、これらの問題は将来のバージョンで修正、もしくは制限を緩和する対応を計画しています。

TSURUGI-IS-252 空でないテーブルに対してインデックスを作成できない

問題:
CREATE INDEX 文によってインデックスを作成する際、対象のテーブルにデータが存在する場合、エラーとなります。

Note

ワークアラウンド:
テーブルを一度空にしてからインデックスを作成してください。
テーブルデータを退避するにはダンプを利用し、インデックス作成後にロードを行うことでデータを復元できます。

TSURUGI-IS-289 トランザクションログの増加に伴いデータベースの起動が遅くなる

問題:
トランザクションログに多くのデータが含まれる状態でデータベースを起動すると、起動時間が長くなります。
またトランザクションログはデータベースへの書き込みのたびに増大していき、データベース上で行を削除してもログサイズが即座に減少することはありません。

Note

ワークアラウンド:
ログコンパクションツールを利用してトランザクションログを圧縮することで、データベースの起動時間を短縮できる場合があります。
同ツールは同一の行に対する複数回の操作をまとめたり、削除された行に関する情報をログから除去することでログサイズを削減します。

バージョン 1.0.0 では2種類のログコンパクションツールを提供しています。
以下のコマンドはTsurugiインストールディレクトリ配下の bin ディレクトリに配置されています。

tglogutil compaction : オフラインログコンパクションツール

tglogutil compaction はデータベース停止状態のトランザクションログファイルを圧縮することができます。

コマンドの詳細は以下のドキュメントを参照してください。

• tglogutil-compaction - reorganize a Tsurugi transaction log directory

tgcmpct_logs.sh : (試験的機能) オンラインログコンパクションツール

tgcmpct_logs.sh はデータベース起動状態のトランザクションログファイルを圧縮することができます。

このコマンドは実行時に圧縮した結果生成される削除可能となったログファイルを削除しません。
削除可能なログファイルを削除するには、別途 tgdel_logs.sh を実行してください。

tgdel_logs.sh は tgcmpct_logs.sh の実行によって削除可能となったログファイルを削除します。
基本的には tgcmpct_logs.sh と tgdel_logs.sh を組み合わせて使用してください。

本機能は現時点では試験的なサポートとなります。正式対応時は提供コマンドや機能が変更される予定です。
また本機能を利用する際には、データベースのバックアップを取得した上で利用することを推奨します。

Important

現時点のオンラインログコンパクションツールは自動的には実行されません。
またこのツールはコマンド実行毎に圧縮処理を1回実行して終了するため、定期的にログ圧縮処理を実行したい場合は外部ツールなどを使って上記コマンドをスケジュール実行するよう環境を構成してください。

データベース起動時間の測定例

ステータス:
バージョン 1.1.0 でトランザクションログ圧縮後の起動時間が高速化されました。以下は バージョン 1.1.0 利用時のデータベース起動時間の測定例です。

以下に、1レコードのサイズが約200バイトのテーブルデータに対するレコード数、トランザクションログサイズ、データベース起動時間の測定例は以下の通りです。

レコード件数(1M=1,000,000)	ログサイズ(GB)	ログ未圧縮時の起動時間(秒)	ログ圧縮後の起動時間(秒)	ログ圧縮ツールの実行時間(秒)
100M	22G	935	213	683
800M	171G	12,241	1,756	9,181

TSURUGI-IS-448 DDLを実行したトランザクションを中断するとテーブルが不正な状態になる

問題:
CREATE TABLE や DROP TABLE 等のDDL文をトランザクション内で実行した後、そのトランザクションがアボートされるか、またはロールバックを実行するとTsurugi内部のテーブル管理情報が不整合な状態になります。
不整合な状態になったテーブルに対する操作は不正な結果を返す可能性があります。

例えば、以下の手順でSQLを実行するとテーブルが不整合な状態になります。

BEGIN;
CREATE TABLE T(C int);
ROLLBACK;
INSERT INTO T VALUES (1);

上記のような状態になった場合、速やかに DROP TABLE を実行してテーブルを削除してください。

TSURUGI-IS-702 テーブルを削除した際にテーブルに対するアクティブな PreparedStatement が不正な状態になる

問題:
PreparedStatement を保持したまま対象テーブルを DROP TABLE を実行、続けて同名テーブルを CREATE TABLE した後その PreparedStatement を使うと、サーバからのレスポンスが返らない、またはサーバが異常終了することがあります。

Note

ワークアラウンド:
対象の PreparedStatement を使う前に再度作成し直すことで問題を回避できます。

TSURUGI-IS-731 列定義と異なる型のキーを使って検索を行うと一部の結果が正しくないことがある

問題:
列定義と異なる型のキーを使って検索を行うと型の最大値・最小値付近の値において誤った結果が得られる場合があります。

以下はその例です:

tgsql> create table t (c0 int primary key);
tgsql> insert into t values (-2147483648);
tgsql> select * from t where c0=2147483648;
[c0: INT4]
[-2147483648]

上記の例では、条件 c0=2147483648 にマッチしないはずの -2147483648 が結果に含まれています。
期待するクエリ結果は0行です。

Note

ワークアラウンド:
異なる型での比較にならないように、あらかじめCAST式で型を列定義と合わせることで問題を回避できます。
例えば前述の例では WHERE 句の条件の右項を、左項と同じ型にキャストしています。

tgsql> select * from t where c0=CAST(2147483648 AS INT);
[c0: INT4]
(0 rows)

ただしCAST式の仕様として CAST(2147483648 AS INT) = 2147483647 (INTの最大値) となることに注意してください。

TSURUGI-IS-732 DECIMALとDECIMAL以外の型の間で二項演算を行うとエラーが発生することがある

問題:
DECIMAL 型と DECIMAL 以外の型の間で二項演算を行った際、結果が仕様と異なることがあります。

tgsql> create table t (c0 decimal(5) primary key);
tgsql> insert into t values (1);
tgsql> select * from t;
[c0: DECIMAL]
[1]
tgsql> select * from t where c0 = 1e0;
[c0: DECIMAL]
UNSUPPORTED_RUNTIME_FEATURE_EXCEPTION (SQL-02050: unsupported type conversion to:decimal(5, 0) from:float8)

仕様では DECIMAL と DOUBLE PRECISION (float8) の比較演算は、暗黙の型変換により DECIMAL の値が DOUBLE PRECISION へと変換したうえで比較しますが、現在の実装ではエラーになります。

TSURUGI-IS-891 同一トランザクション内で同じ行にINSERTとDELETEを行うと不正な状態になる

問題:
同一トランザクション内で INSERT または INSERT OR REPLACE 文で登録したレコードを DELETE 文で削除した場合、そのレコードはトランザクション完了時に削除されていなければなりませんが、実行タイミングによってはそのレコードが削除されずに残ることがあります。

Note

ワークアラウンド:
DELETE を2回実行することで確実に該当レコードを削除できます。

TSURUGI-IS-897 数値演算結果がラップアラウンドする

問題:
数値型同士の演算結果がオーバーフローする場合はエラーとなるべきですが、現時点の実装では数値型に応じたラップアラウンドした値が返ってしまいます。

tgsql> select value from tb1;
[value: INT4]
[2147483647]

tgsql> select value + CAST(1 AS INT) from tb1;
[@#0: INT4]
[-2147483648]

TSURUGI-IS-933 SQL内で特定の構文要素を大量に繰り返すと、データベースが不安定になる

問題:
SQL内で特定の構文要素を大量に繰り返すと、データベースがクラッシュを含む不安定な挙動を示すことがあります。
現在判明している例は以下の2点です:

• IN 句の値リストに大量の要素を指定する (例: x IN (1, 2, 3, ...))
• 条件式に OR 繋ぎで大量の項を指定する (例: x = 1 OR x = 2 OR x = 3 OR ...)

上記はいずれも、単純なケースではコンパイラが自動的に検出し、不安定になる前にコンパイルエラーとなるようにしています。
しかし、複雑なケースではコンパイラが検出できないことがあります。

TSURUGI-IS-942 ORDER BY や LIMIT をクエリ式全体に適用できない

問題:
SQLにおいて ORDER BY や LIMIT 句によってクエリ結果の要素順や要素数の指定を行えますが、 UNION ALL 等を含むクエリ式全体に対して適用することができません。以下はその例です。

SELECT * FROM t1 UNION ALL SELECT * FROM t2 LIMIT 1

上記は、テーブル t1 と t2 のすべての行の和を取得し、そのうちの最大 1 行だけを返すことが期待されますが、現在の実装では t2 の内容を 1 行だけ取り出し、それと t1 の内容を和を取った結果を返します。つまり、合計行数は (t1 の行数) + 1 行となります。

Note

ワークアラウンド:
テーブルサブクエリでデータを取り出し、その外側のクエリに ORDER BY や LIMIT を適用することで目的の結果を得ることができます。以下はその例です。

SELECT * FROM (SELECT * FROM t1 UNION ALL SELECT * FROM t2) AS q LIMIT 1;

TSURUGI-IS-945 大量データに対して COUNT(DISTINCT ...) を実行すると、データベースが不安定になる

問題:
SELECT COUNT(DISTINCT ...) を実行した結果、大量のレコードが返されるような場合にデータベースが不安定になり、正しくレスポンスが返されないことがあります。

TSURUGI-IS-959 クエリーに COUNT(DISTINCT) と他の集約関数が含まれるとエラーとなることがある

問題:
COUNT(DISTINCT ...) のようにDISTINCTな値に対して実行する集約関数と、 MAX のように重複ありで計算する集約関数を同一の SELECT文 で記述すると、エラーとなることがあります。

tgsql> create table t (c0 int);
tgsql> select max(c0), count(distinct c0) from t;
[@#0: INT4, @#1: INT8]
UNSUPPORTED_RUNTIME_FEATURE_EXCEPTION (SQL-02050: failed to find function definition - it's likely aggregate functions with and without DISTINCT keyword are called in the same query, that is currently unsupported)

TSURUGI-IS-960 UNION ALL や一部の LIMIT が非効率的な処理を行う

問題:
UNION ALL によって複数のクエリ結果を連結する際、内部的に非効率的な処理を行うことがあります。

具体的には、SQL実行エンジンは UNION ALL のオペランドを一度メモリ上に展開し、それらを連結するという動作を行います。
このため、クエリの実行に必要なメモリ量が増大し、また全体の応答速度も遅くなることがあります。

同様に、一部の LIMIT (ORDER BY を伴わないもの) でも類似の問題が発生します。
こちらは、 LIMIT 1 によって任意の1件だけを取得したい場合でも、テーブル全体を読み出す場合があります。
ただし、 UNION ALL の場合とは異なり、それらをすべてメモリ上に展開することはなく、指定された件数を超えるものは破棄されます。

TSURUGI-IS-681 MIN, MAX が非効率的な実行計画を生成する

問題:
インデックスキー項目に対して集約関数 MAX, MIN を指定した場合でも、フルスキャンを伴う実行計画が生成されます。
本来であれば、これらのケースはインデックスの先頭や末尾から1件だけ取り出すことで高速に動作するべきですが、現状ではそのような最適化が行われていません。

これは、 ORDER BY ... LIMIT ... (いわゆる TOP-N クエリ) に対しても同様です。

TSURUGI-IS-1011 AS句で指定したカラムの別名をORDER BYの対象にすることができない

AS句で指定したカラムの別名をORDER BYの対象にすると以下のようにコンパイルエラーになります。

SELECT C AS COL from T ORDER BY COL;

SYMBOL_ANALYZE_EXCEPTION (SQL-03004: compile failed with error:variable_not_found message:"variable "COL" is not found, searching for {column_variable, field_variable, schema_variable}" location:<input>:1:33+3)

Note

ワークアラウンド:
テーブルサブクエリでデータを取り出し、その外側のクエリに ORDER BYを適用することで目的の結果を得ることができます。以下はその例です。

SELECT * FROM (SELECT C AS COL FROM T) AS T ORDER BY COL;