Oracle 补充测井水平

嗨，问汤姆团队，

我们正在使用GoldenGate或相关技术从Oracle OLTP系统构建CDC。开发人员 (包括我自己) 希望在所有列上启用补充日志记录，以便我们构建流分析解决方案，在更新事件期间，这需要完整的行，而不仅仅是PK和更改的列。我们的oltp已经在主键列上启用了补充日志记录，并且我们的dba完全反对对所有列启用相同的日志记录。
为了测试所有列补充日志记录的影响，我做了一个简单的测试加载和更新 (仅更新下面的命名空间列) 1 m行到一个表 (架构与ALL_OBJECTS相同)。在我的插入和更新期间，我在最后承诺一次:
表:

Name           Null     Type         
-------------- -------- ------------ 
OWNER                   VARCHAR2(30) 
OBJECT_NAME    NOT NULL VARCHAR2(30) 
SUBOBJECT_NAME          VARCHAR2(30) 
OBJECT_ID               NUMBER       
DATA_OBJECT_ID          NUMBER       
OBJECT_TYPE             VARCHAR2(19) 
CREATED                 DATE         
LAST_DDL_TIME           DATE         
TIMESTAMP               VARCHAR2(19) 
STATUS                  VARCHAR2(7)  
TEMPORARY               VARCHAR2(1)  
GENERATED               VARCHAR2(1)  
SECONDARY               VARCHAR2(1)  
NAMESPACE               NUMBER       
EDITION_NAME            VARCHAR2(30) 
复制

这是我运行来检查生成的重做大小 (在事务之前和之后):

select a.name, b.value
from v$statname a, v$mystat b
where a.statistic# = b.statistic#
and lower(a.name) like '%' || lower('redo size')||'%';
复制

下面检查我的事务使用的撤消块:

SELECT USED_UBLK FROM V$TRANSACTION;
复制

这就是我所看到的所有列补充日志与主键补充日志之间的重做日志大小和撤消块使用的差异:
i.使用 “所有列补充记录” 与 “主键补充记录” 的插入和更新事务的执行时间之间没有明显差异
二.在 “更新事务” 期间，与 “主键补充记录” 相比，“所有列补充记录” 生成了55-60% 个额外的重做。为 “插入” 事务生成的重做在两种日志记录模式之间几乎相同
三.在 “所有列补充记录” 与pk记录的情况下，“更新” 事务的使用量是撤消块的两倍

我正在尝试推理测试的结果，以及是否还有其他因素需要考虑。
能否请你帮我理解一下:
i.在 “更新” 事务期间，是否会使用额外的撤消块，因为撤消将记录所有列的前图像，而不仅仅是更改的列？
二.补充日志记录在内部是如何工作的？它在数据库上创造了什么开销？
三.如果我们需要在oltp中启用 “所有列补充记录”，应该只看一下调整重做日志缓冲区，重做日志组，文件大小，优化磁盘I/o (我们确实有ssd)？是否需要考虑其他因素，例如DR复制等？

我确实尝试在livesql上发布一个简单的测试，但是多次收到 “内部服务器错误”，因此无法与问题共享链接。

请帮忙。

i. During the 'update' transaction, was the additional undo block usage because of the fact that undo will record the before image of all the columns and not just the changed ones?

不完全是。我们 * 确实 * 需要存储更多信息，我们通过记录额外的 * undo * 来完成。见下文。

ii. How does the supplemental logging internally works? What overheads does it create on the database?

我们将其他信息存储在撤消流中，因为撤消会进入重做，因此我们会捕获两者。仅仅添加更多的重做是不够的，因为如果我这样做 (说): 更新T set col = 'A' 其中col = 'B'，那么重做 * 仍然 * 只包含 “A”，而不是原始的 “B”

朱利安·戴克 (Julian Dyke) 在这里写了一篇关于补充日志的出色文章

http://www.juliandyke.com/Research/GoldenGate/GoldenGateSupplementalLogging.php

iii. If we need to enable 'all column supplemental logging' in our OLTPs, should be just look at tuning the redo log buffers, redo log groups, file sizes, optimising disk I/Os (we do have SSDs)? Are their other factors to be looked at, like DR replication etc?

像任何东西一样 -- 为了获得好处，你要在某个地方付出代价。所以你会消耗更多的CPU，你会更积极地消耗更多的重做日志空间。但这仍然会比自己做更有效 (例如，使用触发器或其他表等)。

这也回答了你的相关问题。在您需要的补充日志记录级别与您需要获得的收益之间取得平衡。然后，您可以做出明智的决定。如果您的dba说 “不”，他们应该能够 * 证明 * 他们为什么这么说。正如你应该能够证明好处是合理的。