Posted by Yury Velikanov on Sep 8, 2010
Hello Apps DBA,
I’ve just come across an old known issue again today. Was working in the greatest and latest 12.1.2 Oracle e-Business Suite environment. Surprisingly, I face the old issue when WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES objects (among other objects) are set to NOLOGGING mode. Strictly speaking, the LOGGING attribute was set to YES at the table level, but several partitions of that table were set to LOGGING = NO! The SQL’s below will help you check if your environments are effected. Keep in mind that you should sound the alarm at your business if any other modules’ objects are in the list.
Read the rest of this entry . . .
Posted by Catherine Chow on Feb 4, 2010
A data file is considered unrecoverable if an unrecoverable operation has been performed on an object residing in the data file since the last backup of the data file. Operations will become unrecoverable if they are not logged in the redo log. These “nologging” operations that suppress the generation of redo log, include the following:
- direct load/SQL load
- direct-path inserts result from insert or merge statement
ALTER TABLE commandsCREATE and ALTER INDEX commandsINSERT /*+APPEND*/- partition manipulation
- database object that has explicitly set with nologging option
- Oracle eBusiness Suite concurrent job execution identified in Oracle metalink note: 216211.1
- Oracle eBusiness Suite patches activities that involve database object manipulation
The database recovery operations will look completed, but those data blocks used by the nologging objects in the data file will be marked corrupted when they are recovered. Accessing those nologging data objects in the recovered database instance will return a data block reading error such as ORA-1578 and ORA-26040, and the logical corruption in the data file will prevent the database object from being useful in the recovered database instance.
How do we detect unrecoverable operations?
Unrecoverable data files are those that involve nologging operations since the last successful backup took place. There are several ways to identify them. Read the rest of this entry . . .
