Tag Archives: MOS 1270094.1

New Exadata Critical Issues – EX23 and EX24

Over the weekend, Oracle announced two new Critical Issues for Exadata Storage Server (EX23 and EX24), both impacting version 12.1.2.1.

Both the new Critical Issues can be patched by either applying the one-off patch 21251493 or by upgrading the Exadata Storage Server software to 12.1.2.1.2.

 

Critical Issue EX23
Affects Exadata Storage Server 12.1.2.1.0 and 12.1.2.1.1

Bug 21174310 – wrong results, ORA-1438 errors or other internal errors (ORA-00600 and ORA-07445) are possible from smart scan offloaded queries against HCC or OLTP compressed tables stored on Exadata storage if:

  • Exadata Storage Server is version 12.1.2.1.0 or 12.1.2.1.1 AND
  • Oracle Database was upgraded from 11.2 to 12.1 AND
  • A smart scan offloaded query is issued against an OLTP compressed table or an HCC table containing OLTP compressed blocks

The workaround is to recreate the table.

The recommended action is to upgrade to Exadata Storage Server software version 12.1.2.1.2 (or higher).

Alternatively, apply patch 21251493 to Exadata Storage Servers running version 12.1.2.1.1.  Note that patch 21251493 contains additional fixes required to resolve other critical issues.

MOS 2032464.1 has additional details.

 

Critical Issue EX24
Affects Exadata Storage Server 12.1.2.1.1

After replacing a failed system disk (disk 0 or disk 1), the new disk is not correctly configured leaving the system vulnerable to the other system disk failing. The likelihood of occurrence is high when running Exadata version 12.1.2.1.1 and a failed system disk is replaced.

The workaround is to follow the instructions in MOS 2003674.1.

The recommended action is to upgrade to Exadata Storage Server software version 12.1.2.1.2 (or higher).

Alternatively, apply Patch 21251493 to Exadata Storage Servers running version 12.1.2.1.1. Note that patch 21251493 contains additional fixes required to resolve other critical issues.

MOS 2032402.1 has additional details.

 

References

  • Bug 21174310 – Wrong results or ORA-1438 errors possible from smart scan offloaded queries against HCC or OLTP compressed tables stored on Exadata storage (Doc ID 2032464.1)
  • Important Fixes Required for System Disk Replacement on Exadata Storage Servers Running Version 12.1.2.1.1 (Doc ID 2032402.1)
  • Exadata Storage Software 12.1.2.1.0 and 12.1.2.1.1 System Disk Replacement Issues (Doc ID 2003674.1)
  • Exadata Critical Issues (Doc ID 1270094.1)
  • Patch 21251493
Tagged , , , , , , , , , , ,

Exadata Critical Issue EX21

Oracle announced a new Exadata Critical Issue this morning (EX21) which applies to the ESS software versions 12.1.1.1.2 and 12.1.2.1.1.

“This issue is encountered only when a disk media error occurs while synchronous I/O is performed. Because the majority of I/O operations issued with Exadata storage are done asynchronously, and this problem is possible only when disk media errors are experienced while synchronous I/O is performed, the likelihood of experiencing this problem is low. However, the impact of hitting this problem can potentially be high.

This problem affects Exadata Storage Server software versions 12.1.2.1.1 and 12.1.1.1.2.

Disk corruption symptoms are varied. Some corruptions will be resolved automatically by Oracle Database, while other corruptions will lead to unexpected process shutdown due to internal errors.”

ESS 12.1.1.2.1 DOES have a patch available, but 12.1.2.1.1 does not at the moment (the patch is “pending”).  I’m sure it will become available soon.

I have MOS email me whenever the Exadata Critical Issues document (1270094.1) is updated so I’m quickly aware of the latest important bugs. It’s pretty neat and I’d advise other Exadata types to make use of it as well.

Tagged , , , ,

I don’t often learn of major bugs with incremental backups …

… but when I do, it’s always on a Friday afternoon.

During a Friday meeting, some friendly Oracle ExCite types directed my attention to this GEM of a bug:

Bug 16057129 – Exadata cell optimized incremental backup can skip some blocks to backup

If your incremental backups are “cell-optimized” – which they are by default in Exadata – they can skip blocks if a database file grows in size during the backup.

If you’re taking incremental backups with RMAN of your Exadata databases, have not applied the one-off patch for this bug or the “hidden” parameter workaround and you’re running:

  • 12.1.0.1 GIPSU1 or earlier
  • 11.2.0.3 BP21 or earlier
  • 11.2.0.2 (any)
  • 11.2.0.1 (any)

You should assume that all your incremental backups – both cumulative and differential – are invalid and unusable.

Unfortunately, there is no way to know whether your incremental backup has been affected until you use it for recovery and see an ORA-00600 [3020] error message.

Only incremental backups are possibly affected by this problem – you can still use archive logs to recover from a Level 0 backup and other recovery options are not impacted.

To squash this bug, you have three options:

  • Apply the workaround to disable cell optimized backups.
  • Apply the one-off bug fix for your version.
  • Upgrade to either 12.1.0.1.2, 11.2.0.4 or 11.2.0.3.22.

The Quarterly Full Stack Patch for January 2014 includes Bundle Patch 22 for 11.2.0.3, so you may want to review the QFSP January 2014 upgrade process. It looks like you will have to apply a one-off patch 17599908 on top of 11.2.0.3.22, so review it closely!

If you haven’t done so already, bookmark the MOS list of Exadata Critical Issues.

Mark

Tagged , , , , , , , , ,
%d bloggers like this: