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:
- 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.
- 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.
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.
Because an Oracle Standby database (Active Data Guard) is essentially a read-only database, it can be used as a Business intelligence query server, relieving the workload of the primary database and improving query performance.
How it works
You would think since Oracle Standby database is read only database and Oracle OBIEE only generate sql queries, it should work with default configuration. But it’s not that simple , OBIEE generates some write operations and they need to route to Primary database. Following are the example of OBIEE write operations.
- Oracle BI Scheduler job and instance data
- Temporary tables for performance enhancements
- Writeback scripts for aggregate persistence
- Usage tracking data, if usage tracking has been enabled
- Event polling table data, if event polling tables are being used
- Create a single database object for the standby database configuration, with temporary table creation disabled.
- Configure two connection pools for the database object:
A read-only connection pool that points to the standby database
A second connection pool that points to the primary database for write Operations
- Update any connection scripts that write to the database so that they explicitly specify the primary database connection pool.
- If usage tracking has been enabled, update the usage tracking configuration to use the primary connection.
- If event polling tables are being used, update the event polling database configuration to use the primary connection.
- Ensure that Oracle BI Scheduler is not configured to use any standby sources.
Because the cost-based approach relies on statistics, you should generate statistics for all tables and clusters and all indexes accessed by your SQL statements before using the cost-based approach. If the size and data distribution of the tables change frequently, then regenerate these statistics regularly to ensure the statistics accurately represent the data in the tables.
Collecting optimizer statistics on Exadata is not any different than other systems. I usually recommend my clients for migrate existing gather stats methods from old system. In case you were not collecting stats on existing system , you should gather should at least following types of optimizer statistics.
- Table stats
- Index stats
- System stats
You can gather table / index stats using following procedure at schema level :
Gathering Exadata specific system statistics ensure the optimizer is aware of Exadata scan speed. Accurately accounting for the speed of scan operations will ensure the Optimizer chooses an optimal execution plan in a Exadata environment. Lack of Exadata specific stats can lead to less performant optimizer plans.
The following command gathers Exadata specific system statistics
Note this best practice is not a general recommendation to gather system statistics in Exadata mode for all Exadata environments. For existing customers who have acceptable performance with their current execution plans, do not gather system statistics in Exadata mode.
For existing customers whose cardinality estimates are accurate, but suffer from the optimizer over estimating the cost of a full table scan where the full scan performs better, then gather system statistics in Exadata mode.
For new applications where the impact can be assessed from the beginning, and dealt with easily if there is a problem, gather system statistics in Exadata mode.
Traditional parallel query(PQ) execution, it adopted Direct Path Read to load data which bypassed the database buffer cache(buffer cache) and load directly from the disks. In-Memory parallel execution takes advantage of this large aggregated database buffer cache. By having parallel execution servers access objects using the database buffer cache, they can scan data at least ten times faster than they can on disk. It allows you to cache your hottest tables across buffer caches of multiple RAC nodes
What about Exadata ? In-memory PQ is a great option, only if I/O is your bottleneck. With Exadata you get Terabytes falsh cache and Flash I/O , In-memory PQ is probably not a got idea.
As I have been a part of many detailed conversations with Oracle Experts regarding “Use of indexes on Exadata”, I decided to share my thoughts and experience on this topic.
I have been working with Exadata since 2011 and have been a part of many implementations and POC’s. As per my experience, Exadata works better without indexes but getting rid of all indexes is not a practical approach. I have implemented / migrated different types of applications (OLTP / OLAP) to Exadata and there were some cases where I was not allowed to make any application changes. Application changes like dropping an index, partitioning will require testing and will not be easy as it sounds. if you have worked with applications like EBS and SAP, you understand how difficult it will be to make any changes to the environment.
Personally I recommend following balance approach when it comes to use of indexes on Exadata.
- Don’t drop all the indexes
- Keep primary key / unique indexes
- You can drop bit map indexes
- Use invisible index options when possible
- Avoid indexes using SQL HINTS
- Drop and rebuild indexes during ETL load
Let start with listing Smart Scan requirements here:
- Full table scan / Full Index Scan
- Direct path read
As you can see that “direct path read” is required for Smart Scan. Parallel queries automatically use direct path read and serial queries may use direct path read. So if you don’t see Smart Scan happening with “Full Table / Index Scan”, its probably serial query not doing “Direct Path Read”.
Direct Path Read
For serial queries Oracle dynamically decides to use “Direct Path Read” base on following parameters
- _serial_direct_read = auto
- _direct_read_decision_statistics_driven = TRUE
- _small_table_threshold = XXX
As you can see that we can force “Direct Path Read” by setting “_serial_direct_read” to “ALWAYS”. It’s a hidden parameter and if you are not is comfortable using it in production, I will suggest making your queries run in parallel and keep db cache size small.
Please click the following link to download complete article:-
Key to a Sucessful Exadata POC
Please click following link for download complete Article :-
Exadata Implementation Strategy
Base on my consulting experience, I like to share some best practices running Operational Data Store on Exadata: –
- Use direct path load as much as possible.
- Maximize parallel data load using different techniques ( Partitioning, Parallel DML, etc.)
- User parallel degree based on you application needs, look into AUTO DOP feature.
- Make sure to use all Exadata Features (smart scan, offloading, and storage indexes) to get extreme performance.
- Use Histograms carefully, they can have an adverse impact on your application.
- Test optimizer mode for your application before you start developing you ODS application.
- Data compression is very important. Not only it can help you with query performance, it can also save some storage. Watch your CPU utilization.
- If you are planning to consolidate many data sources to a single ODS, make sure to implement Exadata consolidation best practices.
- Use proper data models 3NF or Star Schema based on your Needs. Most ODS are 3NF.
- Make sure to collect stats after every ETL loads, use incremental for huge tables.
- User partition smartly to achieve partition-wise join or Star Transformation.
- Carefully analyze your partition needs make sure it will help yours with ETL load. Just don’t create partitions randomly, number of partition matters
- If you carefully, Range, hash and interval partitioning will help you achieve extreme performance with Exadata.
- If you are planning to introduce partitioning to an existing application, please test thoroughly.
- Avoid Global Indexes, use local indexes instead.
- Test thoroughly before making any index invisible. It can have an adverse impact on other queries.
- Data load should be fast as possible with minimum impact on users, end user comes first.
- Make sure to achieve partition-wise join or Star Schema transformation.
- User summary tables for as needed.
- If you are planning have your ODS/Staging/DW within same Exadata machine, implement IORM (Exadata IO Resource Manager)