My questions:

  1. Can anyone thing of a reason that supplemental logging results in an implicit constraint?
  2. Why is it created with a DISABLED state?
  3. Does anyone have experience with the effects of enabling these? We have a standard clean-up process that runs after deployments to fully enable constraints that may have been disabled or enabled novalidate for data migration reasons.

Views: 53

Reply to This

Replies to This Discussion

Constraint type is documented:http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/stat...

S stands for "Supplemental logging", which is further explained here:http://download.oracle.com/docs/cd/E11882_01/server.112/e10704/strm... and here: http://download.oracle.com/docs/cd/E11882_01/server.112/e10705/prep...

I don't have any experience with it. This is the result of searching on tahiti.oracle.com.

There are two ways of enabling supplemental logging. In more recent versions of the database we can set minimal logging at the database level

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

In additional we can add specify tables and columns in Supplemental Log Groups. The point of this is to include the values for unchanged columns in the change table, as it makes it easier to apply the changes in the target database. Find out more.

Obviously the S type constraint identifies columns in a Supplemental Log Group. I think the reason they are disabled is because they do not enforce a data integrity rule (unlike primary keys or check constraints). If so, I think it would be unwise to enable them, and so you should re-write your automatic clean-up to filter constraints of type S.

Reply to Discussion

RSS

Oracle Jobs in US

© 2024   Created by Maisam Agha.   Powered by

Badges  |  Report an Issue  |  Terms of Service