Oracle LogMiner 错误地重建扩展字符串值

Question

我有一个 Oracle EE 19.3 环境设置，其中

MAX_STRING_SIZE

设置为

EXTENDED

，支持最多 32k 长度的字符串。在这个环境下，我有两个非常简单的桌子

CREATE TABLE test_a (id NUMERIC(9,0) primary key, DATA varchar2(4000));
CREATE TABLE test_b (id NUMERIC(9,0) primary key, DATA varchar2(32000));

这里唯一的区别是

test_a

不利用扩展字符串，而

test_b

则利用扩展字符串。

现在在

test_a

如果我发出以下SQL语句：

UPDATE test_a
   SET DATA = 'I haven''t, no.'
 WHERE id = 1;

LogMiner 生成的重构 SQL 如下：

update "SCHEMA"."TEST_A" set "DATA" = 'I haven''t, no.' where "ID" = '1' and "DATA" = 'test';

如果我使用任意数量的 SQL 解析器来重构此 SQL，它们就会成功地解析此 SQL，不会失败，因为它通常被视为一致且格式正确。

现在在

test_b

如果我发出完全相同的SQL语句，LogMiner生成的重建的SQL是：

update "SCHEMA"."TESTB_B" set "DATA" = 'I haven't, no.' where "ID" = '1';

我知道在这种情况下，扩展字符串在 LogMiner 中被视为更像 CLOB 字段，这就是为什么这里缺少

"DATA"

的额外谓词，但这不是我关心的。我担心的是

"DATA"

的突变值，

'I haven't, no.'

的值是无法解析的，因为 LogMiner 无法像处理非扩展字符串字段时那样转义嵌套撇号 (

'

)。

有谁知道这是否已被报告为已知错误，或者是否有办法强制 LogMiner 正确重建 SQL，以便后一个 SQL 镜像非扩展字符串字段的正确 SQL？

更新： 我应该指出，所有有关扩展字符串的文档似乎都表明 Oracle 将大小超过

VARCHAR2

的字段视为 CLOB。 然而，虽然技术上确实如此，但当字段显式设置为

4000

数据类型时，重建 CLOB 字段的字符数据并正确转义撇号 (

'

) 没有问题。所以对我来说，这似乎是 LogMiner 的 SQL 重建中的一个错误。

Answer 1