Question: What is supplemental logging, and how does supplemental logging work?

Answer: When Supplemental Logging is enabled, either some selected columns or all columns are specified for extra logging. They are called a supplemental log group and consist of nothing but a set of additional columns that are being logged. When the supplemental logging is active on a database, the redo logs contain other columns from tables to uniquely identify a row. If the table has a primary key or unique index defined, the only columns involved in the primary key or unique index will be registered in the redo logs along with the actual column(s) that has changed.

If the table does not have any primary keys or unique index defined, Oracle will write all scalar columns from the table to identify the row. This may significantly increase the size of redo logs and will impact the log apply services on the logical standby site.

There are two types of supplemental log groups that determine when columns in the log group are logged:

• Unconditional Supplemental Log Groups - The before-images of specified columns are logged any time a row is updated, regardless of whether the update affected any of the specified columns. This can be referred to as an ALWAYS log group.
  

• Conditional Supplemental Log Groups - The before-images of all specified columns are logged only if at least one of the columns in the log group is updated.

Supplemental Logging can be enabled at database level or at the table level. When it is enabled at database level, there are two types, minimal logging and identification key logging.

Streams supplemental logging places additional column data into the redo log file whenever an UPDATE operation is performed. At the least, minimal database-level supplemental logging must be enabled for any Change Data Capture source database:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Why is supplemental logging needed? When a particular column is updated at the source database table for a set of rows, the values in the column or columns are logged by default. When these values are moved to the destination side, to which rows does Oracle apply them, or how does Oracle identify the rows to be updated? Supplemental logging provides the answers to these questions.

supplemental logging会在redo里多记录PK or unique index的信息

其目的在于使redo log 可用于logical stand DB的恢复

比如说，redo 里记录了一笔update的操作，如果是普通的log,就只记录rowid的信息，足够做recover / roll-forward之类的
但是由于logical stand DB不是根据rowid 来做recover,所以需要在redo里记录PK or unique index的信息来定位操作的data.

当然，用了supplemental logging之后，redolog 肯定会变多的。


supplemental logging的信息可以从v$database里获得

select SUPPLEMENTAL_LOG_DATA_MIN , SUPPLEMENTAL_LOG_DATA_PK ,
SUPPLEMENTAL_LOG_DATA_UI
from v$database

因为在oracle里在做update操作时候，有些信息是不技术redo log，例如主键或唯一键等，这样在根据redolog 来解析数据是时候你就不知道具体那行数据被修改，如果根据rowid 来做key值的，在不同数据库里脱离了块，rowid也就没有任何意义了，所以oracle提供了supplemenetal log，通过配置启动它，oracle会在redo log里技术主键或唯一键的信息。具体修改方法如下：

--停止supplemental log

alter database drop supplemental log data

--默认启动方法不是完全启动，建议使用下面的指定启动的方法

alter database add supplemental log data

--指定具体的启动的项对应v$database 中的supplemental_log_data_pk,supplemental_log_data_ui
alter database add supplemental log data (primary key ,unique index) columns

--检查修改结果

select supplemental_log_data_min,supplemental_log_data_pk,supplemental_log_data_ui
from v$database

对于有过逻辑standby,streams搭建体验的朋友，肯定对Supplemental logging不会感到陌生，在一步一步学Dataguard系列笔记中，我曾将其译为附加日志，后来想了想，我觉着附加日志这几个字还是不能完全体现其真实意图，一时半会儿又找不到合适的词儿，算了，不译了，还是坚持以英文相称吧。

Supplemental Logging具体是做什么用的呢？要回答这个问题，我们就必须先搞明白，为什么我们需要Supplemental Logging！

事实上，目前最有可能用到Supplemental Logging的也只有逻辑standby和streams这两项特性(10g以后如果希望logminer能够分析出所有操作，建议也要启用Supplemental Logging)，我们都知道，这两项特性的数据应用都属于逻辑应用，类似source database执行update语句之类，结果也要反映到target database，如何准确判断出source端修改的列，在target端中应该更新到哪条记录上呢？根据rowid？显然不靠谱啊，都说了是逻辑的，块的位置完全不一样，rowid已无用武之地~~~你想说，能否通过表中的唯一键？在更新表中记录时，将主键或唯一键做为附加的信息，与被修改的列一起存入redolog中，对于没有主键唯一键的表，则将表中所有列统统组合做为附加信息存入redolog，这样target端在分析redolog时，就知道该更新表中的哪些记录了！

哎呀，说到这里我不得不郑重表扬..............oracle，它跟你想到一块去啦，为了彰显其成果，Oracle将这项特性命名为：Supplemental Logging。当然啦，为了这项特性能够工作的更好，oracle深化了你的想法，并将其设计的更加灵活多样。

数据库启用了Supplemental Logging之后，对于修改操作，oracle就会同时附加一些能够唯一标识修改记录的列到redolog中，对于拥有主键或唯一键的表，这个操作最简单，只需要附加主键或唯一键即可，这样生成的redo也是最小的，当然这只是一个理想状态，现实情况下某些表可能无法创建主键/唯一键，或者历史原因确无主键/唯一键，这种情况下oracle会将所有列(提示，非log,long之类大字段类型的列)都做为附加信息记录到redo中，这种情况下redo有可能增长迅速，并且在target端应用时也会受到一些影响。因此oracle建议最好为每个涉及到复制的表都创建主键或者唯一键。

对于选择的列和那些用于精确定位的附加列的组合，oracle也对其做了定义叫做supplemental log group。随后oracle又对supplemental log group做了分类，目的是更精确的设置redolog中都记录些什么信息，分如下两类：
a.Unconditional Supplemental Log Groups：无条件记录指定列的前映像，而不管发生修改操作的是不是指定列。因此它还有个外号，叫"老记录日志组"。
b.Conditional Supplemental Log Groups：只有至少一个指定列发生修改操作时被触发，并记录下修改列的前映像。

Supplemental Logging可以在数据库级设置，也可以精确到表级设置，对于数据库级有两种类型：minimal logging和identification key logging，其主要区别就在于写入redolog中的数据详尽程度不同。

以数据库级为例，如何启用Supplemental Logging呢？试试这个命令：
alter database add supplemental log data;
注：这里启用minimal logging，一般做到这一步，logminer就拥有足够的信息分析所有所做过的操作。

如果想禁用Supplemental Logging，drop即可：
alter database drop supplemental log data;

如何查询当前数据库是否启用了Supplemental Logging呢？则可以试试这条语句：
select supplemental_log_data_min,
supplemental_log_data_pk,
supplemental_log_data_ui,
supplemental_log_data_fk,
supplemental_log_data_all
from v$database;
注：supp....data_min/pk/ui等等分别表示不同附加列级别。

正如前面多次提到的，更多应用Supplemental Logging的场合是逻辑standby和streams，因此，如果你希望了解更多的信息，不妨多去测试测试这两项特性吧。