Tsurugi 1.1.0 - Known Issues (ja)

[akirakw]

1.1.0 既知の問題

解決された問題

以下は本バージョンで解決された重要な問題のうち、既存ユーザーの注意が必要なものです。

TSURUGI-IS-706 広範囲のSELECT, UPDATE, DELETE を行うと他の処理が待たされる場合がある

問題:
同じテーブルに対して、あるトランザクションにて広範囲のデータに対する SELECT, UPDATE, DELETE を実行中に別のトランザクションから INSERT 文を実行すると、前者の処理が完了するまで INSERT 処理がブロックされることがあります。

ステータス:
バージョン 1.1.0 で修正済み。
一度のスキャン操作に対して以下の設定値を超えた場合、スキャン処理を一時中断して他のタスク処理がスケジューリングされます。

• sql.scan_block_size
  • スキャンが他のタスクに処理を譲渡する前に処理するレコードの最大数。デフォルトは100
• scan_yield_interval
  • スキャンが他のタスクに処理を譲渡する前に処理する最大時間（ms）。デフォルトは1

上記設定項目に対する詳細は Configuration file parameters - sql section を参照してください。

TSURUGI-IS-957 CHAR 型に対する MIN , MAX 関数の結果が不正となることがある

問題:
CHAR 型に対する集約関数 MIN , MAX を実行した場合、アルファベット順でソートした結果に対する最小、最大値が取得される仕様ですが、CHAR型のサイズによっては集約関数の結果が不正となることがあります。

tgsql> CREATE TABLE tc ( id int NOT NULL, value char(20) NOT NULL, PRIMARY KEY(id));
tgsql> insert into tc values (1, 'a');
tgsql> insert into tc values (2, 'b');
tgsql> insert into tc values (3, 'c');
tgsql> select MIN(value) from tc;
[@#0: CHARACTER]
[c                   ]
tgsql> select MAX(value) from tc;
[@#0: CHARACTER]
[c                   ]

ステータス:
バージョン 1.1.0 で修正済み。

TSURUGI-IS-944 sql.commit_response=STORED 指定時にデータベースを不正に終了すると極めて稀にデータが欠損する可能性がある

問題:
sql.commit_response=STORED においてトランザクションログの書き込みが完了する前にクライアントに応答が返る極めて短いタイミングが不正に存在していたため、データベースを不正に終了した際に極めて稀にクライアントがデータ書き込みが正常終了したと認識したデータがトランザクションログに保存されないことがあります。

ステータス:
バージョン 1.1.0 で修正済み。
ただし本修正によるトランザクションエンジンのバッファ管理方式の変更の影響により、 sql.commit_response=AVAILABLE を指定時かつ多数のスレッドでの同時トランザクション実行時、に従来のバージョンから若干の性能劣化が発生する可能性があります。

この対応として、環境変数 SHIRAKAMI_ENABLE_OCC_EPOCH_LOG_BUFFERING=1 を指定してtsurugidbを実行することでこの性能劣化を緩和することが可能です。ただしこのオプションを指定すると sql.commit_response=STORED の性能が劣化する可能性が高いこと、およびこのオプションは将来廃止される可能性があるため、基本的にはこのオプションの指定は非推奨です。

既知の問題

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

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

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

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-139 OR を含む条件式が非効率的な実行計画を生成する

問題:
条件式に OR を含む場合、非効率的な実行計画が生成されることがあります。
例えば、 key という主キーを持つテーブル t に対して以下のSQLを実行した場合、テーブル t のフルスキャンを行う実行計画を生成します。

SELECT * FROM t WHERE key = 1 OR key = 2

また、現状では IN 句は内部的に OR に展開されるため、同様の問題が発生します。

Note

ワークアラウンド:
条件の項ごとに UNION (DISTINCT) や UNION ALL で繋いでやると同様の結果が得られます。

SELECT * FROM t WHERE key = 1
UNION ALL
SELECT * FROM t WHERE key = 2

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

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

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

TSURUGI-IS-863 JOIN 句の結合優先順位を指定できない

問題:
3つ以上のテーブルでJOIN操作を行う場合、SQL標準では t1 JOIN (t2 JOIN t3 ON ...) ON ... のような記法で結合順序を規定できますが、現状ではこの記法をサポートしていません。

Note

ワークアラウンド:
代わりにサブクエリを用いて、結合順序を明示的に指定することができます。

SELECT * FROM t1 JOIN (SELECT * FROM t2 JOIN t3 ON t2.key = t3.key) AS q(key2, value2, key3, value3) ON t1.key = q.key2