Exadata Support Oracle 10g with ACFS

ACFS is now supported on Exadata. But ACFS does not support Exadata smart scan and offloading , this mean you cannot place your critical databases on ACFS. Please see following Oracle note 1929629.1 for details.

ACFS Support database version :

  • Oracle Database 10g Rel. 2 ( and
  • Oracle Database 11g ( and higher)
  • Oracle Database 12c ( and higher)


  • Oracle ACFS replication or security/encryption/audit is only supported with general purpose files.
  • Oracle ACFS does not currently support the Exadata offload features.
  • Hybrid Columnar Compression (HCC) support requires fix for bug 19136936.
  • Exadata Smart Flash Cache will cache read operations.
  • Exadata Smart Flash Logging is not supported.



Do we need to Multiplex Redo Logs with Exadata ?

According to Oracle, “Oracle recommends that you multiplex your redo log files. The loss of the log file data can be catastrophic if recovery is required”

Oracle also has a cautionary note on performance that is “When you multiplex the redo log, the database must increase the amount of I/O that it performs. Depending on your configuration, this may impact overall database performance.”

So the question is should we multiplex redo logs with Exadata, which is highly protected from disk failures? The answer YES / NO, It will all depend on your ASM disk group redundancy levels. Oracle recommends making DATA disk group redundancy level high and placing all the online Redo Logs / Standby Logs on DATA disk group and not to be multiplexed.

Please use following Exadata Best practice matrix to decide whether to multiplex online redo logs or not.

  • If a high redundancy disk group exists, place all redo logs in that high redundancy disk group.
  • If both DATA and RECO are high redundancy, place all redo logs in DATA.
  • If only normal redundancy disk groups exist, multiplex redo logs, placing them in separate disk groups.

Sharing Exadata Machine Between SAP and Non-SAP Databases

Recently I was tasked to look into the possibility of sharing Exadata machine between SAP and NON-SAP databases. As many of you already know, SAP has its own bundle patches called SBP (SAP Bundle Patches). Most of these patches are applied to Oracle RDBMS home and some are, may be, applied to Oracle GI Home. You are required to maintain patches for both RDBMS and GRID Home. Sharing RDBMS homes between SAP and NON-SAP databases are not supported.

Now if you want to share Exadata Machine between SAP and NON-SAP databases you have the following options:

  1. Install two separate RDBMS homes, one for SAP databases and one for non-SAP databases. Maintain SAP RDBMS home as per SAP specific instruction and maintain non-SAP database as per Oracle provide instructions. You also have a GRID Home (GI Home) that you need to maintain as per SAP specific instructions.
  2. If you have more than 2 compute nodes ( e.g Exadata half rack ) , you can install 2 clusters using 2 nodes for each cluster. Once you have installed two clusters, you can dedicate 1 cluster each for SAP and NON-SAP databases.

NOTE : SAP has not yet certified OVM with Exadata. Once that is done, you can Install and maintain two separate VM Clusters using OVM, 1 each for SAP and NON-SAP databases.






Choosing High vs Normal ASM Redundancy with Exadata

Every time I go through an Exadata deployment process with my client, there is a discussion about ASM Redundancy level. As many of you already know that Exadata only supports two ASM redundancy levels (Normal or High) and Oracle Recommends using a High Redundancy level for both DATA and RECO disk groups. Keep in mind that changing the redundancy level will require recreating disk groups.

A brief description about respective redundancy levels is as follows:

*NORMAL redundancy provides protection against a single disk failure or an entire storage server failure.

*HIGH redundancy provides protection against 2 simultaneous disk failures from 2 distinct storage servers or 2 entire storage servers. HIGH redundancy provides redundancy during Exadata storage server rolling upgrades.

Choosing redundancy level for your Exadata machine will depend on your database environment, available capacity, and desired protection level. Some databases are critical and need a HIGH redundancy disk group while most other databases can use NORMAL redundancy disk groups. So if you choose Normal redundancy, it will not be against the norm but you will not be following Oracle recommendations. I have seen clients using Normal Redundancy more often than I want to. Following are some reasons where you should always use High Redundancy level:

  • If it is a production system with no DR in place.
  • If your storage requirement is low and using HP capacity disks
  • If you want to perform storage server rolling upgrades.

Now following are some situations where you can use Normal redundancy:

  • If it is a Dev or UAT system.
  • If you are space constrained.
  • If you have Data Guard in place for production databases.

NOTE: Standard Exadata deployment will create 3 disk groups (DATA, RECO and DBFS_DG), but you can create additional disk groups with different redundancy levels based on your requirement.