Supplemental Logging

Supplemental Logging分为两种:Database-Level Supplemental Logging和Table-Level Supplemental Logging,即数据库级别和表级别。下面我们来看看Oracle官方文档对其的介绍和说明,引自 http://docs.oracle.com/cd/E11882_01/server.112/e22490/logminer.htm#SUTIL1582

一、Database-Level Supplemental Logging

There are two types of database-level supplemental logging: minimal supplemental logging and identification key logging.Minimal supplemental logging does not impose significant overhead on the database generating the redo log files. However, enabling database-wide identification key logging can impose overhead on the database generating the redo log files.

--数据库级别的补充日志包括两种:minimal supplement logging和identification key logging。Minimal supplemental logging不会强加太多的信息到redo log;identification key logging会强加大量的信息到redo log。

1. Minimal Supplemental Logging

Minimal supplemental logging logs the minimal amount of information needed for LogMiner to identify, group, and merge the redo operations associated with DML changes. It ensures that LogMiner (and any product building on LogMiner technology) has sufficient information to support chained rows and various storage arrangements, such as cluster tables and index-organized tables. To enable minimal supplemental logging, execute the following SQL statement:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

2. Database-Level Identification Key Logging

Identification key logging is necessary when redo log files will not be mined at the source database instance, for example, when the redo log files will be mined at a logical standby database.

Using database identification key logging, you can enable database-wide before-image logging for all updates by specifying one or more of the following options to the SQL ALTER DATABASE ADD SUPPLEMENTAL LOG statement:

2.1 ALL system-generated unconditional supplemental log group

This option specifies that when a row is updated, all columns of that row (except for LOBs, LONGS, and ADTs) are placed in the redo log file.

To enable all column logging at the database level, execute the following statement:

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

--对于ALL COLUMNS补充日志来说,当行被修改时,该行的所有列都会被记录到日志文件中

2.2 PRIMARY KEY system-generated unconditional supplemental log group

This option causes the database to place all columns of a row‘s primary key in the redo log file whenever a row containing a primary key is updated (even if no value in the primary key has changed).

If a table does not have a primary key, but has one or more non-null unique index key constraints or index keys, then one of the unique index keys is chosen for logging as a means of uniquely identifying the row being updated.

If the table has neither a primary key nor a non-null unique index key, then all columns except LONG and LOB are supplementally logged; this is equivalent to specifying ALL supplemental logging for that row. Therefore, Oracle recommends that when you use database-level primary key supplemental logging, all or most tables be defined to have primary or unique index keys.

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

--对于PRIMARY KYE COLUMNS补充日志来说,当行被修改时,该行的主键将被记录到日志文件中,无论该行的主键是否被修改。如果该表没有主键,但有一个或多个非空唯一键,则任意一个非空主键将被记录到日志文件中,如果该表既没有主键,也没有非空唯一键,则该行的所有列将被记录到日志文件中。

2.3 UNIQUE system-generated conditional supplemental log group

This option causes the database to place all columns of a row‘s composite unique key or bitmap index in the redo log file if any column belonging to the composite unique key or bitmap index is modified. The unique key can be due to either a unique constraint or a unique index.

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;

--对于UNIQUE COLUMNS补充日志来说,当行被修改时,该行的唯一键或bitmap index将被记录到日志文件中。

2.4 FOREIGN KEY system-generated conditional supplemental log group

This option causes the database to place all columns of a row‘s foreign key in the redo log file if any column belonging to the foreign key is modified.

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY) COLUMNS;

注意:

1. When you enable identification key logging at the database level, minimal supplemental logging is enabled implicitly.

2. Supplemental logging statements are cumulative. If you issue the following SQL statements, then both primary key and unique key supplemental logging is enabled:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;

3. Dropping minimal supplemental log data is allowed only if no other variant of database-level supplemental logging is enabled.

--如果启动了identification key logging,则minimal supplemental logging将隐性启动;补充日志是叠加的;只有当所有identification key logging被禁止以后,minimal 补充日志才会被禁止。

禁止命令如下:

ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;

二、 Table-Level Supplemental Logging

Table-level supplemental logging specifies, at the table level, which columns are to be supplementally logged. You can use identification key logging or user-defined conditional and unconditional supplemental log groups to log supplemental information, as described in the following sections.

1. Table-Level Identification Key Logging  --针对所有列的

Identification key logging at the table level offers the same options as those provided at the database level: all, primary key, foreign key, and unique key. However, when you specify identification key logging at the table level, only the specified table is affected.

-- Database-Level Identification Key Logging与Table-Level Supplemental Logging的区别,前者是针对全库的,后者是针对表的。表级别的补充日志也是叠加的。

2. Table-Level User-Defined Supplemental Log Groups  --针对某些列的

In addition to table-level identification key logging, Oracle supports user-defined supplemental log groups. With user-defined supplemental log groups, you can specify which columns are supplementally logged. You can specify conditional or unconditional log groups, as follows:

2.1 User-defined unconditional log groups

To enable supplemental logging that uses user-defined unconditional log groups, use the ALWAYS clause as shown in the following example:

ALTER TABLE HR.EMPLOYEES
   ADD SUPPLEMENTAL LOG GROUP emp_parttime (EMPLOYEE_ID, LAST_NAME,
   DEPARTMENT_ID) ALWAYS;

This creates a log group named emp_parttime on the hr.employees table that consists of the columns employee_idlast_name, and department_id. These columns will be logged every time an UPDATE statement is executed on the hr.employees table, regardless of whether the update affected these columns.

--对于User-defined unconditional log groups,只要行被修改,无论列组中的列是否被修改,该组中的列都会被记录到日志文件中。

2.2 User-defined conditional supplemental log groups

To enable supplemental logging that uses user-defined conditional log groups, omit the ALWAYS clause from the SQL ALTER TABLE statement, as shown in the following example:

ALTER TABLE HR.EMPLOYEES
   ADD SUPPLEMENTAL LOG GROUP emp_fulltime (EMPLOYEE_ID, LAST_NAME,
   DEPARTMENT_ID);

This creates a log group named emp_fulltime on table hr.employees. Just like the previous example, it consists of the columns employee_idlast_name, and department_id. But because the ALWAYS clause was omitted, before-images of the columns will be logged only if at least one of the columns is updated.

--相比unconditional log groups,conditional supplemental log groups语句中只是少了关键字ALWAYS,只有该列组中的列被修改时,该组中列的信息才会记录到日志文件中。

2.3 User-defined supplemental log groups with NO LOG

For both unconditional and conditional user-defined supplemental log groups, you can explicitly specify that a column in the log group be excluded from supplemental logging by specifying the NO LOG option. When you specify a log group and use the NO LOG option, you must specify at least one column in the log group without the NO LOG option, as shown in the following example:

ALTER TABLE HR.EMPLOYEES
   ADD SUPPLEMENTAL LOG GROUP emp_parttime(
   DEPARTMENT_ID NO LOG, EMPLOYEE_ID);

This enables you to associate this column with other columns in the named supplemental log group such that any modification to the NO LOG column causes the other columns in the supplemental log group to be placed in the redo log file. This might be useful, for example, if you want to log certain columns in a group if a LONG column changes. You cannot supplementally log the LONG column itself; however, you can use changes to that column to trigger supplemental logging of other columns in the same row.

--譬如:新建一个表,其中,带有LONG字段,SQL> create table test(id number,ename long);

构建包括ename在内的supplemental log groups

SQL> alter table scott.test add supplemental log group test_g(loc,id) always;
           alter table scott.test add supplemental log group test_g(loc,id) always
           *
           ERROR at line 1:
           ORA-30569: data type of given column is not supported in a log group

可见,在log group中,long类型不支持。

在此,我们可以对long类型的列指定为NO LOG。如下所示:

SQL> alter table scott.test add supplemental log group test_g(ename no log,id) always;

Table altered.

时间: 2024-08-30 09:07:44

Supplemental Logging的相关文章

【翻译自mos文章】Main Note - ogg的 Supplemental Logging and TRANDATA

Main Note - ogg的 Supplemental Logging and TRANDATA 参加原文: Main Note - Supplemental Logging and TRANDATA for OGG (Doc ID 1537838.1) 适用于 Oracle GoldenGate - Version 9.5_EA and later Information in this document applies to any platform. 目的 从oracle redo l

【翻译自mos文章】OGG add Supplemental Logging 时失败,报错为 块损坏(Block Corruption)

OGG add Supplemental Logging 时失败,报错为 块损坏(Block Corruption) 来源于: Add Supplemental Logging Fails Due To Block Corruption (文档 ID 1468322.1) 适用于: Oracle Server - Enterprise Edition - Version 10.2.0.5 to 12cBETA1 [Release 10.2 to 12.1] Information in this

Oracle补全日志(Supplemental logging)

Oracle补全日志(Supplemental logging)特性因其作用的不同可分为以下几种:最小(Minimal),支持所有字段(all),支持主键(primary key),支持唯一键(unique),支持外键(foreign key).包括LONG,LOB,LONG RAW及集合等字段类型均无法利用补全日志. 最小(Minimal)补全日志开启后可以使得logmnr工具支持链式行,簇表和索引组织表.可以通过以下SQL检查最小补全日志是否已经开启:SELECT supplemental_

Oracle Database does not provide any supplemental logging, which means that by default LogMiner is not usable

写在前面,在研究Oracle logmnr 的时候看到 http://www.askmaclean.com/archives/dbms_logmnr-unsupported-sqlredo.html 的文章,其中有一句 不知道maclean测试的是哪个版本的数据库,我测试的情况是可以的. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Parti

【 翻译自mos文章】Alter Database Add Supplemental Log Data 命令挂起

Alter Database Add Supplemental Log Data 命令挂起 来源于: Alter Database Add Supplemental Log Data Hangs (文档 ID 406498.1) 适用于: Oracle Database - Enterprise Edition - Version 10.2.0.1 and later Information in this document applies to any platform. 症状: 作为流复制配

Oracle中的补充日志(supplemental log)

原网址:http://sugarlovecxq.blog.51cto.com/6707742/1693092 在配置DG的时候,有涉及到补充日志的知识,故做以整理. 补充日志不是独立的一种日志,是对重做记录中变更矢量的补充信息,增加了变更矢量记载的记录量,Oracle数据库某些功能要求启用补充日志才能正常地或更好的工作,如logminer.DG.闪回事务查询.闪回事务. Oracle中insert.delete命令在默认情况下产生的重做记录足以表明被修改的行的每个字段在被修改前后的值是什么,in

Oracle Supplemental 补全日志介绍

转. Oracle补全日志(Supplemental logging)特性因其作用的不同可分为以下几种:最小(Minimal),支持所有字段(all),支持主键(primary key),支持唯一键(unique),支持外键(foreign key).包括LONG,LOB,LONG RAW及集合等字段类型均无法利用补全日志. 最小(Minimal)补全日志开启后可以使得logmnr工具支持链式行,簇表和索引组织表.可以通过以下SQL检查最小补全日志是否已经开启: SELECT supplemen

Oracle异常汇总

持续更新中,可参见https://hnuhell.gitbooks.io/oracle_errmg/content/或https://hnuhell.github.io/Oracle_ERRMG/上的页面. ORA-00000 to ORA-00877 ORA-00000: 正常的成功的完成(操作) ORA-00000: normal, successful completion 原因1: 正常执行完成.[部分验证] Normal exit. 分析: 此异常多数为程序没有执行SQL语句或者说成功

OGG常见问题处理

1403: ORA-01403: No data found 在运行PL/SQL块.存储过程.函数.触发器等,假设须要进行操作的记录没有查询到.则会返回1403的错误 Goldengate中的1403 在目标段复制进程中,godengate从日志中解析出sql语句,依据sql语句的where条件.在目标段的库中匹配不出对应的记录 1403错误原因: 1. 附加日志相关 ? 数据相关 ? 表结构不一致/索引重建 常见问题: 1.生产端I/O过大.内存占用过大 配置了多个Extract进程导致 2.