ALERT: DB corruption after 12c upgrade for compressed tables during recovery

Did you compress tables on 11g before going to 12c?  If so, you need to check out My Oracle Support article "ALERT Bug 21682261 Corruption during Recovery after upgrading to 12c for Compressed Tables" from document ID 2058461.1 because you can run into corrupted tables if you need to recover them!  This is the worst possible news for a database because it violates all of the ACID principles and if you get to the recovery stage you already have your data in question!

Using an array update statement may cause row or block corruption

While advanced PL/SQL programming structures like an array can be advantageous at times over row by row (Cary Millsap's slow by slow), the article "ALERT: Bug 7662491 - Array Update can corrupt a row. ORA-600 [kghstack_free1] ORA-600 [kddummy_blkchk][6110/6129]" found on My Oracle Support by way of note ID 861965.1 shows that not every decision we make is without consequences!  Think you do not need to know about this if you are in Support?  Think again, unless you already know what table holds data about blocks which get corrupted and in that case you probably already have an alert built looking at that table to see when corruption occurs right?

Exadata: Fixes needed for ASM File System due to data corruption

Fresh off the presses, and on the heels of my post about ASM allowing disks of 2TB, is article "Important Fixes required to implement Oracle Automatic Storage Management File System (ACFS) on Oracle Exadata Database Machine" found on My Oracle Support via document ID 2022172.1 which explains there are multiple concerns of data corruption in ASM including one affecting disks which are larger than 2TB!

R12.1.3: Payables accounting date not in sync with General Ledger accounting date

I say a lot about bringing proactive data checks to Support teams, so tonight it would make a lot of sense to check out the My Oracle Support article "R12: Accounting Date And General Ledger Accounting Date Is Not In Sync" from note 1985068.1 because you will find out a setup issue that can cause a data mismatch between the EBS modules plus get a script which will allow you to identify if you are encountering this issue!

Weekend Learning: Block corruption in pre-12c DB versions

Out of a lot of error messages out there, I would think that the "ORA-01578: ORACLE data block corrupted" error is likely the most feared out there for DBAs (of course behind ORA-00600).  Do you want to find out more?  Read the long article "Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g" on My Oracle Support via note ID 28814.1 to get all the details which also includes a lot of datafile related tables and errors that go into the alert log which are all potential candidates for proactive alerts going forward!

R12.1: Incorrect GL and subledgers due to corruption

Are you already on R12.1?  Did you know there is a known bug where several reports are not returning subledger journals which requires a patch and datafix?  Visit the MOS article "Corruption in GL Journal Headers Causing Incorrect Reporting in GL and Subledgers" from note ID 1559470.1 to get up to speed on this issue, and make sure that you have applied the required patch!

11gR2: ORA-600 corruption in rolling back RAC transaction

If you are on several different versions of Oracle's 11gR2 database, you may be susceptible to a known ORA-600 bug detailed in the MOS note "ALERT: Bug 13605839 ORA-600 [ktbsdp1] ORA-600 [kghfrempty:ds] ORA-600 [kdBlkCheckError]. Corruption in Rollback with Clusterwide Global Transactions in RAC" which is found in document ID 1527740.1 but the linked document 13605839.8 has all of the bug details including which versions are affected and which versions have this fixed.

Database Week: Data Corruption

This week, I'll highlight a bunch of database related My Oracle Support articles which all have a different slant to them.  If there is one thing that all Support individuals live in fear of, it is corrupted data in the system!  Why?  Because it will show up without any warning and cause problems that probably are not straightforward at all to fix.  Here are some notes to visit and see if you are affected plus maybe get some idea how to be proactive to identify some possible ways to alert about the keywords thrown in the log when data is corrupted!

ALERT: Bug 13605839 ORA-600 [ktbsdp1] ORA-600 [kghfrempty:ds] ORA-600 [kdBlkCheckError]. Corruption in Rollback with Clusterwide Global Transactions in RAC - Note ID 1527740.1

ALERT: Bug 8198906 - Segment header corruption if extent allocation operation is interrupted - Note ID 1229669.1

For Oracle Solaris Cluster, Silent Data Corruption may Occur When Using Buffered Sequential I/O on the Cluster File System - Note ID 1672874.1

R12: Unable to change Supplier information

Since I'm on an A/P bug kick, and I've shared with you some knowledge about Supplier changes in R12, I should probably also clue you in on another item to add to your testing suite!  The other day A/P was in the web portal trying to change the inactivation date on a Supplier record when they received an error message indicating "Context Value Doesn't Exist In Value Set $FLEX$.DF_CONTEXTS" and the form wouldn't let them actually save their changes.  MOS note 1458183.1 indicates this happens because setup wasn't migrated over, or because there was a decision made to not migrate data, so you get two solutions: one if you want to fix your DFF and the other if you want to get a bugfix.

If you aren't testing the removal (or change) of information to your migrated data for A/P you should probably start trying to break the system by doing it, and even branch out to test other application data that was migrated because you might be able to introduce patches to your code base early in the process to prevent re-testing.

Patching R12 to fix SLA and GL data

If you weren't aware, SLA (Sub Ledger Accounting) is a new feature introduced with R12 and as expected with new features is the shaking out of bugs identified by the early adopters. Not only do we find out what the possible bugs are between the SLA intermediary and the GL, but included in the article is a new note with the root cause fix as well as data fix in case data corruption has happen AND in the comments the author has given us another note which will lead us to learn more about SLA in general.