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?

ORA-00600 encountered while performing DBMS_STATS on table with too many columns

My Oracle Support document "ORA-00600 [kkqtutlAddSelItem] when Running DBMS_STATS on Table with Large Number of Columns" from article ID 1619803.1 reminds me a lot of a previous article where I found out about an ORA-00600 error when you try to select from too many tables at once!  It seems like you can run into these issues at "random" times when artificial limits are imposed within the Oracle database internals so be aware of these issues!

ALERT: ORA-600 on Standby after switchover

I have been told that SCNs and ITLs are some sacred parts of the ACID test for transactions, but article "ALERT Description and fix for Bug 8895202: ORA-1555 / ORA-600 [ktbdchk1: bad dscn] ORA-600 [2663] in Physical Standby after switchover" found via document ID 1608167.1 on My Oracle Support gives us reasons that both SCNs and ITLs can be violated!

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: ORA-600

It only feels appropriate to end Database Week with making sure that people know about the tools available when you encounter an ORA-00600/ORA-600 error message.  First let's start with "ORA-600/ORA-7445/ORA-700 Error Look-up Tool" on MOS via note ID 153788.1 which has a link to the troubleshooting tools for these as well.  Do you want to learn about an Oracle database?  Research well known errors like ORA-600s and see how far into the kernel it will take you!  Speaking of, here are some other documents which might help you a bit to learn about statistics and their relation to ORA-600 errors:

ORA-00600 [qernsRowP] on SELECT - Note ID 1910565.1
ORA-00600 [rwoirw: check ret val] After 11.2.0.4 Upgrade - Note ID 1910573.1

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

Selecting from too many tables hits Oracle DB bug on 11.2.0.3

Doing some research, I found a few hundred tables which were being gathered as if they contained no data but I wanted to verify it myself by looking at the data (or absence of data).  No problem I thought, I would just take the list of tables, put a comma at the end of each one, and then use the list in something like this:

SELECT * FROM table1, table2, etc

They are empty, so it sounds like a great idea right?  Not so much.  I believed that there was such a thing as too many tables (or maybe columns) that can be joined together (in a Cartesian join in this example) as the following ORA-00600 error was spit out at me:

ORA-00600: internal error code, arguments: [mal0-size-too-large], [kksoff : opitca], [], [], [], [], [], [], [], [], [], []

At first, I thought it was simply because of the Cartesian join but when I reduced the query to only have 20 or 30 tables I no longer received my ORA-00600 message and I received the single null row with all of the columns from each table returned.  It turns out, that since we are on 11.2.0.3 this is a bug I'm encountering detailed in MOS note/bug 553051.1/675576 which is resolved in 11.2.0.4 and 12.1.0.1 versions of the database.