BI Apps796 Perf Tech Note V5

Oracle Business
Intelligence Applications
Version 7.9.6 Performance
Recommendations
An Oracle Technical Note
January 2010
1
Oracle Business Intelligence Applications Version 7.9.6 Performance
Recommendations
Introduction ....................................................................................................................................................... 4
Hardware recommendations for implementing Oracle BI Applications ............................................................ 4
Storage Considerations for Oracle Business Analytics Warehouse............................................................. 5
Introduction............................................................................................................................................... 5
Shared Storage Impact Benchmarks ....................................................................................................... 5
Conclusion................................................................................................................................................ 7
Source Tier ................................................................................................................................................... 7
Oracle BI Enterprise Edition (OBIEE) / ETL Tier .......................................................................................... 7
Review of OBIEE/ETL Tier components .................................................................................................. 7
Deployment considerations for the ETL components .............................................................................. 7
Target Tier .................................................................................................................................................... 7
Oracle RDBMS ......................................................................................................................................... 7
Oracle Business Analytics Warehouse configuration ....................................................................................... 8
Database configuration parameters ............................................................................................................. 8
ETL impact on amount of generated REDO Logs ........................................................................................ 8
Oracle RDBMS System Statistics ................................................................................................................. 9
Parallel Query configuration ......................................................................................................................... 9
Oracle Business Analytics Warehouse Tablespaces ................................................................................. 10
Informatica configuration for better performance............................................................................................ 10
Informatica PowerCenter 8.6 32-bit vs. 64-bit ............................................................................................ 10
Informatica Session Logs ........................................................................................................................... 10
Informatica Lookups ................................................................................................................................... 11
Disabling Lookup Cache for very large Lookups ........................................................................................ 12
Joining Staging Tables to Lookup Tables in Informatica Lookups ............................................................. 12
Informatica Custom Relational Connections for long running mappings.................................................... 13
Informatica Session Parameters ................................................................................................................ 14
Commit Interval ...................................................................................................................................... 14
DTM Buffer Size ..................................................................................................................................... 14
Additional Concurrent Pipelines for Lookup Cache Creation ................................................................. 14
Default Buffer Block Size ....................................................................................................................... 14
Informatica Load: Bulk vs. Normal ............................................................................................................. 15
Use of NULL Ports in Informatica Mappings .............................................................................................. 15
Informatica Parallel Sessions Load on ETL tier.......................................................................................... 15
Informatica Load Balancing Implementation .............................................................................................. 16
Bitmap Indexes usage for better queries performance ................................................................................... 16
Introduction ................................................................................................................................................. 16
DAC properties for handling bitmap indexes during ETL ........................................................................... 16
Bitmap Indexes handling strategies ............................................................................................................ 18
Disabling Indexes with DISTINCT_KEYS = 1............................................................................................. 21
Monitoring and Disabling Unused Indexes ................................................................................................. 22
Handling Query Indexes during Initial ETL ................................................................................................. 24
Partitioning guidelines for Large Fact tables ................................................................................................... 25
Introduction ................................................................................................................................................. 25
Convert to partitioned tables ....................................................................................................................... 25
Identify a partitioning key and decide on a partitioning interval .............................................................. 25
Create a partitioned table in Data Warehouse ....................................................................................... 27
Configure Informatica to support partitioned tables ............................................................................... 29
Configure DAC to support partitioned tables .......................................................................................... 29
2
Unit test the changes for converted partitioned tables in DAC ............................................................... 36
Interval Partitioning ..................................................................................................................................... 37
Table Compression implementation guidelines .............................................................................................. 37
Guidelines for Oracle optimizer hints usage in ETL mappings ....................................................................... 38
Hash Joins versus Nested Loops in Oracle RDBMS.................................................................................. 38
Suggested hints for Oracle Business Intelligence Applications 7.9.6 ......................................................... 41
Using Oracle Optimizer Dynamic Sampling for big staging tables ............................................................. 44
Custom Indexes in Oracle EBS for incremental loads performance .............................................................. 45
Introduction ................................................................................................................................................. 45
Custom OBIEE indexes in EBS 11i and R12 systems ............................................................................... 45
Custom EBS indexes in EBS 11i source systems ...................................................................................... 47
Oracle EBS tables with high transactional load .......................................................................................... 48
Custom EBS indexes on CREATION_DATE in EBS 11i source systems ................................................. 49
Wide tables with over 255 columns performance ........................................................................................... 50
Introduction ................................................................................................................................................. 50
Wide tables structure optimization ............................................................................................................. 50
Oracle BI Applications HIgh Availability .......................................................................................................... 51
Introduction ................................................................................................................................................. 51
High Availability with Oracle Data Guard and Physical Standby Database ................................................ 51
Oracle BI Applications ETL Performance Benchmarks .................................................................................. 53
Oracle BI Applications 7.9.6.1, Siebel CRM 8.0 Adapter............................................................................ 53
Oracle BI Applications 7.9.6.1, Oracle EBS R12 Projects Adapter ............................................................ 54
Oracle BI Applications 7.9.6.1, Oracle EBS 11i10 Enterprise Sales Adapter ............................................. 54
Oracle BI Applications 7.9.6.1, Oracle EBS 11i10 Supply Chain Adapter .................................................. 55
Conclusion ...................................................................................................................................................... 56
3
Oracle Business Intelligence Applications Version 7.9.6 Performance
Recommendations
INTRODUCTION
Oracle Business Intelligence (BI) Applications Version 7.9.6 delivers a number of adapters to various business
applications on Oracle database. 7.9.6.1 version is certified with other major data warehousing platforms. Each Oracle
BI Applications implementation requires very careful planning to ensure the best performance both during ETL and web
queries or dashboard execution.
This article discusses performance topics for Oracle BI Applications 7.9.6 and higher using Informatica PowerCenter
8.6 ETL platform.
Note: The document is intended for experienced Oracle BI Administrators, DBAs and Applications implementers. It
covers advanced performance tuning techniques in Informatica and Oracle RDBMS, so all recommendations must be
carefully verified in a test environment before applied to a production instance. Customers are encouraged to engage
Oracle Expert Services to review their configurations prior to implementing the recommendations to their BI
Applications environments.
HARDWARE RECOMMENDATIONS FOR IMPLEMENTING ORACLE BI APPLICATIONS

Depending on source data volumes, Oracle BI Applications Version 7.9.6 implementations can be categorized as
small, medium and large. The table below summarizes hardware recommendations for Oracle BI Applications tiers by
the volume ranges.
Source Data SMALL: MEDIUM: LARGE:

Volume Up to 200Gb 200Gb to 1Tb 1Tb and higher
Target Tier
# CPU cores 8 16 32*
Physical RAM 16Gb 32Gb 64Gb*
Storage Space Up to 400Gb 400Gb - 2Tb 2Tb and higher
High performance SCSI or

Local (PATA, SATA, iSCSI).
Local (PATA, SATA, iSCSI), network attached storage.
Storage System Recommended two or more
preferred RAID configuration Hardware RAID controller with
I/O controllers
multiple I/O channels.
Oracle BI Enterprise Edition / ETL Tier
# CPU cores 4-8 8 - 16 16**
Physical RAM 8Gb 8 - 16Gb 16Gb**
4
Storage Space 100Gb local 200Gb local 400Gb local
* Consider implementing Oracle RAC with multiple nodes to accommodate large numbers of concurrent users
accessing web reports and dashboards.
** Consider installing two or more servers on ETL tier and implementing Informatica Load Balancing across all ETL tier
servers.
Important: All Oracle BI Applications tiers must be set up in the same local area network. Installation of any of
these three tiers over Wide Area Network (WAN) may cause timeouts during ETL mappings execution on the
ETL tier.
Storage Considerations for Oracle Business Analytics Warehouse
Introduction
Oracle BI Applications ETL execution plans are optimized to maximize hardware utilization on ETL and target tiers and
reduce ETL runtime. Usually a well-optimized infrastructure consumes higher CPU and memory on an ETL tier and
causes rather heavy storage I/O load on a target tier during an ETL execution. The storage could easily become a
major bottleneck as the result of such actions as:
• Setting excessive parallel query processes (refer to ‘Parallel Query Configuration’ section for more details)
• Running multiple I/O intensive applications, such as databases, on a shared storage
• Choosing sub-optimal storage for running BI Applications tiers.
Oracle positions Exadata solution as fast and efficient hardware for addressing I/O bottlenecks in large volume
environments. The internal benchmarks for running Oracle BI Applications on Exadata will be published soon.
Shared Storage Impact Benchmarks

Sharing storage among heavy I/O processes could easily degrade ETL performance and result in extended ETL
runtime. The following benchmarks helped to measure the impact from sharing the same NetApp filer storage between
two target databases, concurrently loading data in two parallel ETL executions.
Configuration description:
• Linux servers #1 and #2 have the following configurations:
• 2 quad-core 1.8 GHz Intel Xeon CPU
• 32 GB RAM
• Shared NetApp filer volumes, volume1 and volume2, are mounted as EXT3 file systems:
o Server #1 uses volume1
o Server #2 uses volume2
Execution test description:
• Set record block size for I/O operations to 32k, the recommended db block size in a target database.
• Execute parallel load using eight child processes to imitate average workload during ETL run.
• Run the following test scenarios:
o Test#1: execute parallel load above on NFS volume1 using Linux server #1; keep Linux server #2 idle.
o Test#2: execute parallel load above on both NFS volume1 and volume2 using Linux servers #1 and #2.
5
The following benchmarks describe performance measurements in KB / sec:
- Initial Write: write a new file.
- Rewrite: re-write in an existing file.
- Read: read an existing file.
- Re-Read: re-read an existing file.
- Random Read: read a file with accesses made to random locations in the file.
- Random Write: write a file with accesses made to random locations in the file.
- Mixed workload: read and write a file with accesses made to random locations in the file.
- Reverse Read: read a file backwards.
- Record Rewrite: write and re-write the same record in a file.
- Strided Read: read a file with a strided access behavior, for example: read at offset zero for a length of 4
Kbytes, seek 200 Kbytes, read for a length of 4 Kbytes, seek 200 Kbytes and so on.
The test summary:
Test Type Test #1 Test #2
"Initial write " 46087.10 KB/sec 30039.90 KB/sec
"Rewrite " 70104.05 KB/sec 30106.25 KB/sec
"Read " 3134220.53 KB/sec 2078320.83 KB/sec
"Re-read " 3223637.78 KB/sec 3038416.45 KB/sec
"Reverse Read " 1754192.17 KB/sec 1765427.92 KB/sec
"Stride read " 1783300.46 KB/sec 1795288.49 KB/sec
"Random read " 1724525.63 KB/sec 1755344.27 KB/sec
"Mixed workload " 2704878.70 KB/sec 2456869.82 KB/sec
"Random write " 68053.60 KB/sec 25367.06 KB/sec
"Pwrite " 45778.21 KB/sec 23794.34 KB/sec
"Pread " 2837808.30 KB/sec 2578445.19 KB/sec
Total Time 110 min 216 min
Initial Write, Rewrite, Initial Read, Random Write, and Pwrite (buffered write operation) were impacted the most, while
Reverse Read, Stride Read, Random Read, Mixed Workload and Pread (buffered read operation) were impacted the
least by the concurrent load.
Read operations do not require specific RAID sync-up operations therefore read requests are less dependent on the
number of concurrent threads.
6
Conclusion
Make sure you carefully plan for storage deployment, configuration and usage in Oracle BI Applications environment.
Avoid sharing the same RAID controller(s) across multiple databases. Set up periodic monitoring of your I/O system
during both ETL and end user queries load for any potential bottlenecks.
Source Tier
Oracle BI Applications data loads may cause additional overhead of up to fifteen percent of CPU and memory on a
source tier. There might be a bigger impact on the I/O subsystem, especially during full ETL loads. Using several I/O
controllers or a hardware RAID controller with multiple I/O channels on the source side would help to minimize the
impact on Business Applications during ETL runs and speed up data extraction into a target data warehouse.
Oracle BI Enterprise Edition (OBIEE) / ETL Tier

Review of OBIEE/ETL Tier components
The Oracle BIEE/ETL Tier is composed of the following parts:
- Oracle Business Intelligence Server 10.1.3.4
- Informatica PowerCenter 8.6 Client
- Informatica PowerCenter 8.6 Server
- Data Warehouse Administration Console (DAC) client 10.1.3.4.1
- Data Warehouse Administration Console server 10.1.3.4.1
- Informatica BI Applications Repository (usually stored in a target database)
- DAC BI Applications Repository (usually stored in a target database)
Deployment considerations for the ETL components

• The Informatica server and DAC server should be installed on a dedicated machine for best performance.
• The Informatica server and DAC server cannot be installed separately on different servers.
• The Informatica client and DAC client can be located on an ETL Administration client machine, or a Windows
server, running Informatica and DAC servers.
• Informatica and DAC repositories can be deployed as separate schemas in the same database, as Oracle
Business Analytics Warehouse, if the target database platform is Oracle, IBM DB2 or Microsoft SQL Server.
• The Informatica server and DAC server host machine should be physically located near the source data machine
to improve network performance.
Target Tier
Oracle RDBMS
Oracle recommends deploying Oracle Business Analytics Warehouse on Oracle RDBMS 64-bit, running under 64-bit
Operating System (OS). If 64-bit OS is not available, then consider implementing Very Large Memory (VLM) on Unix /
Linux and Address Windowing Extensions (AWE) for Windows 32 bit Platforms. VLM/AWE implementations would
increase database address space to allow for more database buffers or a larger indirect data buffer window. Refer to
Oracle Metalink for VLM / AWE implementation for your platform.
7
Note: You cannot use sga_target or db_cache_size parameters if you enable VLM / AWE by setting
'use_indirect_data_buffers = true'. You would have to manually resize all SGA memory components and use
db_block_buffers instead of db_cache_size to specify your data cache.
ORACLE BUSINESS ANALYTICS WAREHOUSE CONFIGURATION
Database configuration parameters

Oracle Business Intelligence Applications version 7.9.6 are certified with Oracle RDBMS 9iR2, 10g and 11g. Since
Oracle BI Applications extensively use bitmap indexes, partitioned tables, and other database features in both ETL and
front-end queries logic, it is important that Oracle BI Applications customers install the latest database releases for their
Data Warehouse tiers:
- Oracle 9i customers should use Oracle 9.2.0.8.
- Oracle 10g customers should use Oracle 10.2.0.4 or higher.
- Oracle 11g customers should use Oracle 11.1.0.7 or higher.
Important: Oracle 10.2.0.1 customers must upgrade their Oracle Business Analytics Warehouses to the latest
Patchset.
Oracle BI Applications include template init.ora files with recommended and required parameters located in the
<ORACLEBI_HOME>\dwrep\Documentation\ directory:
- init9iR2.ora - init.ora template for Oracle RDBMS 9i
- init10gR2.ora - init.ora template for Oracle RDBMS 10g
- init11g.ora – init.ora template for Oracle RDBMS 11g
Review an appropriate init.ora template file and follow its guidelines to configure target database parameters specific to
your data warehouse tier hardware.
ETL impact on amount of generated REDO Logs

Initial ETL may cause higher than usual generation of REDO logs, when loading large data volumes in a data
warehouse database. If your target database is configured to run in ARCHIVELOG mode, you can consider two
options:
1. Switch the database to NOARCHIVELOG mode, execute Initial ETL, take a cold backup and switch the
database back to ARCHIVELOG mode.
2. Allocate up to 10-15% of additional space to accommodate for archived REDO logs during Initial ETL.
Below is a calculation of generated REDO amount in an internal initial ETL run:
redo log file sequence:

start : 641 (11 Jan 21:10)
end : 1624 (12 Jan 10:03)
total # of redo logs : 983
log file size : 52428800
redo generated: 983*52428800 = 51537510400 (48 GB)
Data Loaded in warehouse:

SQL> select sum(bytes)/1024/1024/1024 Gb from dba_segments where owner='DWH' and
segment_type='TABLE';
8
Gb
----------
280.49
Oracle RDBMS System Statistics

Oracle has introduced workload statistics in Oracle 9i to gather important information about system such as single and
multiple block read time, CPU speed, and various system throughputs. Optimizer takes system statistics into account,
when it computes the cost of query execution plans. Failure to gather workload statistics may result in sub-optimal
execution plans for queries, excessive temporary space consumption, and ultimately impact BI Applications
performance.
Oracle BI Applications customers are required to gather workload statistics on both source and target Oracle
databases prior to running initial ETL.
Oracle recommends two options to gather system statistics:
- Run the dbms_stats.gather_system_stats('start') procedure at the beginning of the workload window, then the
dbms_stats.gather_system_stats('stop') procedure at the end of the workload window.
- Run dbms_stats.gather_system_stats('interval', interval=>N) where N is the number of minutes when statistics

gathering will be stopped automatically.
Important: Execute dbms_stats.gather_system_stats, when the database is not idle. Oracle computes desired system
statistics when database is under significant workload. Usually half an hour is sufficient to generate the valid statistic
values.
Parallel Query configuration

The Data Warehouse Administration Console (DAC) leverages the Oracle Parallel Query option for computing statistics
and building indexes on target tables. By default DAC creates indexes with the 'PARALLEL' clause and computes
statistics with pre-calculated degree of parallelism. Refer to the init.ora template files, located in
<ORACLEBI_HOME>\dwrep\Documentation for details on setting the following parameters:
parallel_max_servers
parallel_min_servers
parallel_threads_per_cpu
Important: Parallel execution is non-scalable. It could easily lead to increased resource contention, creating
I/O bottlenecks, and increasing response time when the resources are shared by many concurrent
transactions.
Since DAC creates indexes and computes statistics on target tables in parallel on a single table and across multiple
tables, the parallel execution may cause performance problems if the values parallel_max_servers and
parallel_threads_per_cpu are too high. The system load from parallel operations can be observed by executing the
following query:
SQL> select name, value from v$sysstat where name like 'Parallel%';
Reduce the "parallel_threads_per_cpu" and "parallel_max_servers" value if the system is overloaded.
9
Oracle Business Analytics Warehouse Tablespaces
By default, DAC deploys all data warehouse entities into two tablespaces: all tables into a DATA tablespace, and all
indexes into an INDEX tablespace. Depending on your hardware configuration on the target tier you can improve its
performance by rearranging your data warehouse tablespaces.
The following table summarizes space allocation estimates in a data warehouse by its data volume range:
SMALL: MEDIUM: LARGE:

Target Data Volume
Up to 400Gb 400Gb to 2Tb 2Tb and higher
Temporary Tablespace 40 – 60Gb 60 – 150Gb 150 – 250Gb
DATA Tablespace 350Gb 350Gb – 1.8Tb > 1.8Tb
INDEX Tablespace 50Gb 50 – 200Gb > 200Gb
Note that the INDEX Tablespace may increase if you enable more query indexes in your data warehouse.
During incremental loads, by default DAC drops and rebuilds indexes, so you should separate all indexes in a
dedicated tablespace and, if you have multiple RAID / IO Controllers, move the INDEX tablespace to a separate
controller.
You may also consider isolating staging tables (_FS) and target fact tables (_F) on different controllers. Such
configuration would help to speed up Target Load (SIL) mappings for fact tables by balancing I/O load on multiple RAID
controllers.
INFORMATICA CONFIGURATION FOR BETTER PERFORMANCE
Informatica PowerCenter 8.6 32-bit vs. 64-bit

32-bit OS memory can address only 2 ^ 32 bytes, or four gigabytes of RAM, and allow maximum two gigabytes for any
application. Oracle BI Applications ETL mappings use complex Informatica transformations such as lookups, cached in
memory, and their performance is heavily impacted by data from incremental extracts and high watermark
warehousing volumes. Additionally BI Applications ETL execution plans employ parallel mappings execution. So 32-bit
ETL tier can quickly exhaust the available memory and end up with very expensive I/O paging and swapping
operations, thus causing rather dramatic regression in ETL performance.
On the contrast, Informatica 64-bit takes the advantage of more physical RAM for performing complex transformations
in memory and eliminating costly disk I/O operations. Informatica PowerCenter 8.6 provides a true 64-bit performance
and the ability to scale because no intermediate staging or hashing files on disk are required for processing.
The internal benchmarks of BI Applications ETL mappings for Informatica 8.6 32-bit vs. 64-bit showed at least two
times better throughputs for 64-bit configuration. So, Oracle Business Intelligence Applications customers are strongly
encouraged to use Informatica 8.6 64-bit version for Medium and Large environments.
Informatica Session Logs

Oracle BI Applications 7.9.6 uses Informatica PowerCenter 8.6, which has improved log reports. Each session log
provides the detailed information about transformations as well as summary of a mapping execution, including the
detailed percentage run time, idle time, etc.
Below is an example of the execution summary from an Informatica session log:

***** RUN INFO FOR TGT LOAD ORDER GROUP [1], CONCURRENT SET [1] *****
10
Thread [READER_1_1_1] created for [the read stage] of partition point [Sq_W_CUSTOMER_LOC_USE_DS] has completed.
Total Run Time = [559.812502] secs
Total Idle Time = [348.453112] secs
Busy Percentage = [37.755389]
Thread [TRANSF_1_1_1] created for [the transformation stage] of partition point [Sq_W_CUSTOMER_LOC_USE_DS] has completed.
Thread work time breakdown:
Fil_W_CUSTOMER_LOC_USE_D: 2.105263 percent
Exp_W_CUSTOMER_LOC_USE_D_Update_Flg: 10.526316 percent
Lkp_W_CUSTOMER_LOC_USE_D: 13.684211 percent
mplt_Get_Etl_Proc_Wid.EXP_Constant_for_Lookup: 1.052632 percent
mplt_Get_Etl_Proc_Wid.Exp_Get_Integration_Id: 2.105263 percent
mplt_Get_Etl_Proc_Wid.Exp_Decide_Etl_Proc_Wid: 3.157895 percent
mplt_Get_Etl_Proc_Wid.LKP_ETL_PROC_WID: 20.000000 percent
mplt_SIL_CustomerLocationUseDimension.Exp_Scd2_Dates: 44.210526 percent
mplt_SIL_CustomerLocationUseDimension.Exp_W_CUSTOMER_LOC_USE_D_Transform: 3.157895 percent
Thread [WRITER_1_*_1] created for [the write stage] of partition point [W_CUSTOMER_LOC_USE_D] has completed.
Busy Percentage for a single thread cannot be considered as an absolute measure of performance for a whole
mapping. All threads statistics must be reviewed together. Informatica computes it for a single thread in a mapping as
follows:
Busy Percentage = (Total Run Time – Total Idle Time) / Total Run Time
If the report log shows high Busy Percentage (> 70 - 80%) for the READER Thread, then you may need to review the
mapping’s Reader Source Qualifier Query for any performance bottlenecks.
If the report shows high Busy Percentage (> 60 - 70%) for the TRANSF Thread, then you need to review the detailed
transformations execution summary and identify the most expensive transformation. In the example above the
transformation “mplt_SIL_CustomerLocationUseDimension.Exp_Scd2_Dates” consumes 44.2% of all TRANSF runtime,
so it may be considered a candidate for investigation.
If the report shows high Busy Percentage for the WRITER Thread, it may not necessarily be a performance bottleneck.
Depending on the processed data volumes, you may want to turn off Bulk Mode. Refer to the section “Informatica
Load: Bulk vs. Normal” for more details.
The log above shows that most probably the mapping is well balanced between Reader and Transformation threads
and it keeps Writer busy with inserts.
Informatica Lookups
Too many Informatica Lookups in an Informatica mapping may cause significant performance slowdown. Review the
guidelines below for handling Informatica Lookups in Oracle Business Intelligence Applications mappings:
• Inspect Informatica session logs for the number of lookups, including each lookup’s percentage runtime.
• Check “Lookup table row count” and “Lookup cache row count” numbers for each Lookup Transformation. If
Lookup table row count is too high, Informatica will cache a smaller subset in its Lookup Cache. Such lookup
could cause significant performance overhead on ETL tier.
• If functional logic permits, consider reducing a large lookup row count by adding more constraining predicates to
the lookup query WHERE clause.
• If a Reader Source Qualifier query is not a bottleneck in a slow mapping, and the mapping is overloaded with
lookups, consider pushing lookups with row counts less than two million into the Reader SQL as OUTER JOINS.
11
Important: Some lookups could be reusable within a mapping or across multiple mappings, so they cannot be
constrained or pushed down into Reader queries. Consult Oracle Development prior to re-writing Oracle
Business Intelligence Applications mappings.
• If you identify a very large lookup with row count more than 15-20 million, consider pushing it down as an OUTER
JOIN into the mapping’s Reader Query. Such update would slow down the Reader SQL execution, but it might
improve overall mapping’s performance.
• Make sure you test the changes to avoid functional regressions before implementing optimizations in your
production environment.
Disabling Lookup Cache for very large Lookups

Informatica uses Lookup cache to store the lookup data on the ETL tier in flat files (dat and idx). The Integration
Service builds cache in memory when it processes the first row of data in the cached Lookup Transformation. If Lookup
data is small, the lookup data can be stored in memory and transformation processes the rows very fast. But, if Lookup
data is very large (typically over 20M), the lookup cannot fit into the allocated memory and the data has to be paged in
and out many times during a single session. As a result, such lookup transformations adversely affect the overall
mapping performance. Additionally Informatica takes more time to build such large lookups.
If constraining a large lookup is not possible, then consider disabling the lookup cache. Connect to Informatica
Workflow Manager, open the session properties, and find the desired transformation in the Transformations folder on
the Mapping tab. Then uncheck Lookup Cache Enabled property and save the session.
Disabling the lookup cache for heavy lookups will help to avoid excessive paging on the ETL tier. When the lookup
cache is disabled, the Integration Service issues a select statement against the lookup source database to retrieve
lookup values for each row from the Reader Thread. It would not store any data in its flat files on ETL tier. The issued
lookup query uses bind variables, so it is parsed only once in the lookup source database.
Disabling lookup cache may work faster for very large lookups under following conditions:
• Lookup query must use index access path, otherwise data retrieval would be very expensive on the source lookup
database tier. Remember that Informatica would fire the lookup query for every record from its Reader thread.
• Consider creating an index for all columns, which are used in the lookup query. Then Oracle Optimizer would
choose INDEX FAST FULL SCAN to retrieve the lookup values from index blocks rather than scanning the whole
table.
• Check the explain plan for the lookup query to ensure index access path.
Make sure you test the modified mapping with the selected disabled lookups in a test environment and benchmark its
performance prior to implementing the change in the production system.
Joining Staging Tables to Lookup Tables in Informatica Lookups

If you identify bottlenecks with lookups having very large rowcounts, you can consider constraining them by updating
the Lookup queries and joining to a staging table used in the mapping. As a result, Informatica will execute the lookup
query and cache much fewer rows, and speed up the rows processing on its Transformation thread.
For example, the original query for Lkp_W_PARTY_D_With_Geo_Wid
SELECT DISTINCT W_PARTY_D.ROW_WID as ROW_WID,
W_PARTY_D.GEO_WID as GEO_WID,
W_PARTY_D.INTEGRATION_ID as INTEGRATION_ID,
W_PARTY_D.DATASOURCE_NUM_ID as DATASOURCE_NUM_ID,
W_PARTY_D.EFFECTIVE_FROM_DT as EFFECTIVE_FROM_DT,
W_PARTY_D.EFFECTIVE_TO_DT as EFFECTIVE_TO_DT
12
FROM
W_PARTY_D
Can be modified to:
SELECT DISTINCT W_PARTY_D.ROW_WID as ROW_WID,

W_PARTY_D.GEO_WID as GEO_WID,
W_PARTY_D.INTEGRATION_ID as INTEGRATION_ID,
W_PARTY_D.DATASOURCE_NUM_ID as DATASOURCE_NUM_ID,
W_PARTY_D.EFFECTIVE_FROM_DT as EFFECTIVE_FROM_DT,
W_PARTY_D.EFFECTIVE_TO_DT as EFFECTIVE_TO_DT
FROM
W_PARTY_D,
W_RESPONSE_FS
WHERE W_PARTY_D.INTEGRATION_ID=W_RESPONSE_FS.PARTY_ID AND
W_PARTY_D.DATASOURCE_NUM_ID=W_RESPONSE_FS.DATASOURCE_NUM_ID
Such change ensured the lookup row count drop from > 22M to 180K and helped to improve the mapping
performance.
This approach can be applied selectively to both initial and incremental mappings after thorough benchmarks.
Informatica Custom Relational Connections for long running mappings

If you plan to summarize very large volumes of data (usually over 100 million records), you could speed up the large
data ETL mappings by turning off automated PGA structures allocation and set SORT and HASH areas manually for
the selected sessions.
To speed up such ETL mappings execution, set sort_area_size and hash_area_size to higher values. If you have
limited system memory, you can increase only the sort_area_size as sorting operations for aggregate mappings are
more memory intensive. Hash joins involving bigger tables can still perform better with smaller hash_area_size.
Follow the steps below to create a new Relational Connection with custom session parameters in Informatica:
1. Open Informatica Workflow Manager and navigate to Connections -> Relational -> New
2. Define a new Target connection 'DataWarehouse_Manual_PGA'
3. Use the same values as in ‘DataWarehouse’ connection
4. Click on ‘Connection Environment SQL’ and insert the following commands:
Repeat the same steps to define another custom Relational connection to your Oracle Source database.
alter session set workarea_size_policy = manual;

alter session set sort_area_size = 1000000000;
alter session set hash_area_size = 2000000000;
Each mapping that is a candidate to use the custom Relational connections, should meet the requirements below:
- The mapping doesn’t use heavy transformations on ETL tier
- The Reader query joins very large tables
- Its Reader query execution plan uses HASH JOINS
Connect to Informatica Workflow Manager and complete the following steps for each identified mapping:
1. Open a session in Task Developer
2. Click on ‘Mapping’ tab
3. Select ‘Connections’ in the left pane
4. Select the defined Custom value for Source or Target connection
13
5. Save the changes.
Informatica Session Parameters

There are three major properties, defined in Informatica Workflow Manager for each session, which impact Informatica
mappings performance.
Commit Interval
The target-based commit interval determines the commit points at which the Integration Service commits data writes in
the target database. The larger the commit interval, the better the overall mapping’s performance. However too large
commit interval may cause database logs to fill and result in session failure.
Oracle BI Applications Informatica mappings have the default setting 10,000. The recommended range for commit
intervals is from 10,000 up to 200,000.
DTM Buffer Size

The DTM Buffer Size specifies the amount of memory the Integration Service uses for DTM buffer memory. Informatica
uses DTM buffer memory to create the internal data structures and buffer blocks used to bring data into and out of the
Integration Service.
Additional Concurrent Pipelines for Lookup Cache Creation

Additional Concurrent Pipelines for Lookup Cache Creation parameter defines the concurrency for lookup cache
creation.
Oracle BI Applications Informatica mappings have the default setting 0. You can reduce lookup cache build time by
enabling parallel lookup cache creation by setting the value larger than one.
Important: Make sure you carefully analyze long running mapping bottlenecks before turning on lookup cache build
concurrency in your production environment. Oracle BI Applications execution plans take advantage of parallel
workflows execution. Enabling concurrent lookup cache creation may result in additional overhead on a target
database and longer execution time.
You can consider turning on lookup cache creation concurrency when you have one or two long running mappings,
which are overloaded with lookups.
Default Buffer Block Size

The buffer block size specifies the amount of buffer memory used to move a block of data from the source to the
target. Oracle BI Applications Informatica mappings have the default setting 128,000. Avoid using ‘Auto’ value for
Default Buffer Block Size, as it may cause performance regressions for your sessions.
The internal tests showed better performance for both Initial and Incremental ETL with Default Buffer Block Size set to
512,000 (512K). You can run the following SQL to update the Buffer Block Size to 512K for all mappings in your
Informatica repository:
SQL> update opb_cfg_attr set attr_value='512000' where attr_value='128000' and attr_id = 5;
SQL> commit;
Important: Make sure you test the changes in your development repository and benchmark ETL performance before
making changes to your production environment.
14
Informatica Load: Bulk vs. Normal
The Informatica writer thread may become a bottleneck in some mappings that use bulk mode to load very large
volumes (>200M) into a data warehouse.
The analysis of a trace file from a Writer database session shows that Informatica uses an internal Oracle hint
SYS_DL_CURSOR to load data in Bulk mode. The database session performs two direct path writes to insert each
new portion of data. Every time Oracle scans for 12 contiguous blocks in a target table to perform a new write
transaction. As the table grows larger, it takes longer and longer to scan the segment for chunks of 12 contiguous
blocks. Even though it does bypass database block cache with SYS_DL_CURSOR hint, Oracle slows down the
mapping’s overall performance.
To determine whether your mapping, which loads very large data in bulk mode, slows down because of writer thread,
open its Informatica session log, and compute the time to write the same set of blocks (usually 10,000) at the beginning
and the end of the log. If you observe significant increase in the writer execution time at the end of the log, then you
should consider changing the session load mode from Bulk to Normal in Informatica Workflow Manager, and test the
mapping with the updated setting.
Use of NULL Ports in Informatica Mappings

The use of connected or disconnected ports with hard-coded NULL values in Informatica mappings can be yet another
reason for slower ETL mappings performance. The internal study showed that, depending on the number of NULL
ports, such mappings performance can drop two times or even more. The performance gap becomes larger when
more ports are used in a mapping. The session CPU time grows nearly proportionally to the number of connected
ports, so does the row width, processed by Informatica. As soon as certain threshold of ports reached, the internal
Informatica session processing for wide mappings becomes even more complex, and its execution runtime slows down
dramatically. The internal tests demonstrated that Informatica treats equally NULL and non-NULL values and allocates
critical resources for processing NULL ports. It also includes NULL values into INSERT statements, executed by
WRITER thread on data warehouse tier.
To ensure effective performance of Informatica mappings:
- Avoid using NULL ports in Informatica transformations.
- Try to keep the total number of ports no greater than 50 per mapping.
- Review slow mappings for NULL ports or any other potentially redundant ports, which could be eliminated.
Informatica Parallel Sessions Load on ETL tier

Informatica mappings with complex transformations and heavy lookups typically consume larger amounts of memory
during ETL execution. While processing large data volumes and executing in parallel, such mappings may easily
overload the ETL server and cause very heavy memory swapping and paging. As the result, the overall ETL execution
would take much longer time to complete. To avoid such potential bottlenecks:
• Consider implementing Informatica 64-bit version on your ETL tier.
• Ensure you have enough physical memory on your ETL tier server. Refer to Hardware Recommendations section
for more details.
• Keep in mind that too many Informatica sessions, running in parallel, may overload either source or target
database.
• Set smaller number of connections to Informatica Integration Service in DAC. Navigate to DAC’s Setup screen ->
Informatica Servers tab -> Maximum Sessions in the lower pane for both Informatica and Repository connections.
The recommended range is from 5 to 10 sessions.
15
• Benchmark your ETL performance in your test environment prior to implementing the change in the production
system.
Informatica Load Balancing Implementation

To improve the performance on the ETL tier, consider implementing Informatica Load Balancing to balance the
Informatica load across multiple ETL tiers and speed up mappings execution. You can register one or more
Informatica servers and the Informatica Repository Server in DAC and specify the number of workflows that can be
executed in parallel. The DAC server automatically load balances across the servers. It does not run more sessions
than the value specified for each of them.
To implement Informatica Load Balancing in DAC perform the following steps.
1. Register additional Informatica Server(s) in DAC. Refer to the section Registering Informatica Servers in the DAC
Client in the publication Oracle Business Intelligence Applications Installation Guide for Informatica PowerCenter
Users, Version 7.9.6
2. Configure the database connection information in Informatica Workflow Manager. Refer to the section Process of
Configuring the Informatica Repository in Workflow Manager in the publication Oracle Business Intelligence
Applications Installation Guide for Informatica PowerCenter Users, Version 7.9.6.
Important: Deploying multiple Informatica domains and repository services on different server nodes would cause
additional maintenance overhead. Any repository updates or configuration changes, performed on one node, must be
replicated across all the participating nodes in the multiple domains configuration.
To minimize the overhead from Informatica repositories maintenance, consider the load balancing implementation
below:
• Configure a single Informatica domain and deploy a single PowerCenter Repository service in it.
• Create Informatica services on each Informatica node and subscribe them to the single domain
BITMAP INDEXES USAGE FOR BETTER QUERIES PERFORMANCE

Introduction
Oracle Business Intelligence Applications Version 7.9.0 introduced the use of the Bitmap Index feature of the Oracle
RDBMS. In comparison with B-Tree indexes, Bitmap indexes provide significant performance improvements on data
warehouse star queries. The internal benchmarks showed performance gains when B-Tree indexes on the foreign
keys and attributes were replaced with bitmap indexes.
Although bitmap indexes improve star queries response time, their use may cause ETL performance degradations both
in Oracle 9i, 10g and 11g. Dropping all bitmap indexes on a large table prior to an ETL run, and then recreating them
after the ETL completion may be quite expensive and time consuming. This is especially the case when there are a
large number of such indexes, or when there is little change expected in the number of records updated or inserted into
a table during each ETL run. Conversely, the quality of the existing bitmap indexes may degrade as more updates,
deletes, and inserts are performed with indexes in place, making such indexes less effective unless they are rebuilt.
This section reviews the index processing behavior of the DAC and provides the recommendations for bitmap indexes
handling during ETL runs.
DAC properties for handling bitmap indexes during ETL

DAC handles the same indexes differently for initial and incremental ETL runs. Prior to an initial load in a data
warehouse, there are no indexes created on the tables except for the unique B-Tree indexes to preserve data integrity.
16
During the initial ETL run, DAC will create ETL indexes on a loaded table, which will be required for faster execution of
subsequent mappings. For an incremental ETL run, DAC’s index handling will vary based on the combination of the
several DAC properties and individual index usage settings.
The following table summarizes the list of parameters, available in DAC 10.1.3.4.1, to handle indexes during ETL runs:
Parameter Parameter Default

Values Effect
Name Type Value
DAC will drop all indexes on a target table, truncated before a load, and then re-
create them after loading the table. It is used mostly in small Execution plans.
Initial ETL:
- Y – all indexes irrespective of any other settings will be dropped and created
- N - no indexes will be dropped during an initial ETL
Incremental ETL:
Drop/Create Execution
Y|N - Y - indexes with Always Drop & Create (Bitmap) will be dropped during an Y
Indices Plan
incremental ETL
- N - no indexes will be dropped during an incremental ETL
DB2/390 customers may want to set it to N. The recommended default value for
other platforms is Y, unless you are executing a micro ETL in which case it would
be too expensive to drop and create all indexes, so the value should be changed to
N.
Important: When set to N, this parameter overrides all other index level properties.
The property Always Drop and Create is an index specific property, applicable to
bitmap indexes only.
- Y - a Bitmap index will be dropped prior to an ETL run.

Always Drop
- N - a Bitmap index will not be dropped in an incremental ETL run only.
& Create Index Y|N N/A
Bitmap The index property Always Drop & Create Bitmap does not override Drop/Create
Indices execution plan property if the latter is set to N'. If an index is inactivated in
DAC, the index would not be dropped and recreated during subsequent ETL runs.
The property applies to Oracle data warehouse platform only.
The property Always Drop and Create is an index specific property, applicable to all
indexes.
- Y – an index will be dropped prior to an ETL run.

Always Drop
Index Y|N - N – an index will not be dropped in an incremental ETL run only. N/A
& Create
The index property Always Drop & Create does not override Drop/Create Indices
execution plan property if the latter is set to N'. If an index is inactivated in DAC, the
index would not be dropped and recreated during subsequent ETL runs.
17
- ETL - an index is required to improve subsequent ETL mappings performance.
DAC drops ETL indexes on a table if it truncates the table before the load, or
ETL | you set Drop/Create Indices, Always Drop and Create Bitmap or Always Drop &
Index Usage Index Create to True. DAC will re-create the dropped ETL indexes after loading the N/A
QUERY
table, since the indexes will be used to speed up subsequent mappings.
- Query - an index is required to improve web queries performance.
- True – The DAC server will verify that all indexes defined in the DAC repository
are created in the target database.
Verify And
- False - DAC will not run any reconciliation checks between its repository and
Create Non- True |
System the target database. False
Existing False
Indices This parameter is useful when the current execution plan has Drop/Create Indexes
set to True, and new indexes have been created in the DAC repository since the
last ETL run.
Num Parallel Physical

This parameter specifies the maximum number of indexes that the DAC server will
Indexes per Data Number 1
create in parallel for a single table.
Table Source
Bitmap Indexes handling strategies

Review the following recommendations for effective bitmap indexes management in your environment.
1. Disable redundant bitmap indexes in DAC.
Pre-packaged Oracle BI Applications releases include bitmap indexes, enabled in the DAC metadata repository, and
therefore, created and maintained as part of ETL runs, even though the indexed columns might not be used in filtering
conditions in the Oracle BI Server repository.
Reducing the number of redundant bitmap indexes is an essential step for improving initial and incremental loads,
especially for dimension and lookup tables. To identify all enabled BITMAP indexes on a table in DAC metadata
repository:
- Log in into your repository through the DAC user interface, click on the Design button under top menu, select your
custom container in the pull down menu and select the Indices tab in the right pane.
- Click Query sub-tab
- Enter Table name and check ‘Is Bitmap’ box in the query row and click Go.
To identify the list of the exposed columns, included into filtering conditions in RPD repository, connect to BI Server
Administration Tool and generate the list of dependencies for each column using Query Repository and Related To
features.
To disable the identified redundant indexes in DAC and drop them in Data Warehouse:
- Check the Inactive checkbox against the indexes, which should be permanently dropped in the target schema.
- Rebuild the DAC execution plan.
- Connect to your target database schema and drop the disabled indexes.
2. Decide whether to drop or keep bitmap indexes during incremental loads.
Analyze the total time to build indexes and computing statistics during an incremental run. You can connect to your
DAC repository and execute the following queries:
18
SQL> alter session set nls_date_format='DD-MON-YYYY:HH24:MI:SS';
-- Identify your ETL Run and put its format into the subsequent queries:
select ROW_WID, NAME ETL_RUN

, EXTRACT(DAY FROM (END_TS - START_TS) DAY TO SECOND ) || ' days '
|| EXTRACT(HOUR FROM (END_TS - START_TS) DAY TO SECOND ) || ' hrs '
|| EXTRACT(MINUTE FROM (END_TS - START_TS) DAY TO SECOND ) || ' min '
|| EXTRACT(SECOND FROM (END_TS - START_TS) DAY TO SECOND ) || ' sec ' PLAN_RUN_TIME
from W_ETL_DEFN_RUN
order by START_TS DESC;
-- Identify your custom Execution Plan Name:
SELECT DISTINCT app.row_wid

FROM w_etl_defn_run run
, w_etl_app app
, w_etl_defn_prm prm
WHERE prm.etl_defn_wid = run.etl_defn_wid
AND prm.app_wid = app.row_wid
AND run.row_wid = '<Unique ETL ID from the first query>’;
-- Indexes build time:
SELECT ref_idx.tbl_name table_name

, ref_idx.idx_name
, sdtl.start_ts start_time
, sdtl.end_ts end_time
, EXTRACT(DAY FROM(sdtl.end_ts - sdtl.start_ts) DAY TO SECOND) || ' days '
|| EXTRACT(HOUR FROM(sdtl.end_ts - sdtl.start_ts) DAY TO SECOND) || ' hrs '
|| EXTRACT(MINUTE FROM(sdtl.end_ts - sdtl.start_ts) DAY TO SECOND) || ' min '
|| EXTRACT(SECOND FROM(sdtl.end_ts - sdtl.start_ts) DAY TO SECOND) || ' sec'
idx_bld_time
FROM w_etl_defn_run def
, w_etl_run_step stp
, w_etl_run_sdtl sdtl
, (SELECT ind_ref.obj_wid
, ind.name idx_name
, tbl.name tbl_name
FROM w_etl_index ind
, w_etl_obj_ref ind_ref
, w_etl_obj_ref tbl_ref
, w_etl_table tbl
, w_etl_app app
WHERE ind_ref.obj_type = 'W_ETL_INDEX' AND ind_ref.soft_del_flg = 'N' AND
ind_ref.app_wid = ‘<Your custom Execution Plan Name from the second query>’
AND ind_ref.obj_wid = ind.row_wid
AND tbl_ref.obj_type = 'W_ETL_TABLE' AND tbl_ref.soft_del_flg = 'N' AND
tbl_ref.app_wid = ‘<Your custom Execution Plan Name from the second query>’
AND tbl_ref.obj_wid = tbl.row_wid
AND tbl_ref.obj_ref_wid = ind.table_wid
AND ind.app_wid = app.row_wid
AND ind.inactive_flg = 'N'
) ref_idx
WHERE def.row_wid = stp.run_wid
AND def.row_wid ='<Unique ETL ID from the first query>’
AND sdtl.run_step_wid = stp.row_wid
AND sdtl.type_cd = 'Create Index'
AND sdtl.index_wid = ref_idx.obj_wid
-- AND ref_idx.tbl_name = 'W_OPTY_D'
ORDER BY sdtl.end_ts - sdtl.start_ts DESC
-- Table Stats computing time:
19
select TBL.NAME TABLE_NAME
, STP.STEP_NAME
, EXTRACT(DAY FROM (SDTL.END_TS - SDTL.START_TS) DAY TO SECOND ) ||' days '
|| EXTRACT(HOUR FROM (SDTL.END_TS - SDTL.START_TS) DAY TO SECOND ) ||' hrs '
|| EXTRACT(MINUTE FROM (SDTL.END_TS - SDTL.START_TS) DAY TO SECOND ) ||' min '
|| EXTRACT(SECOND FROM (SDTL.END_TS - SDTL.START_TS) DAY TO SECOND ) ||' sec'
TBL_STATS_TIME
from W_ETL_DEFN_RUN DEF
, W_ETL_RUN_STEP STP
, W_ETL_RUN_SDTL SDTL
, W_ETL_TABLE TBL
where DEF.ROW_WID=STP.RUN_WID
and DEF.ROW_WID ='<Unique ETL ID from the first query>’
and SDTL.RUN_STEP_WID = STP.ROW_WID
and SDTL.TYPE_CD = 'Analyze Table'
and SDTL.TABLE_WID = TBL.ROW_WID
order by SDTL.END_TS - SDTL.START_TS desc;
-- Informatica jobs for the selected ETL run:
select
SDTL.NAME SESSION_NAME
,
SDTL.SUCESS_ROWS
,
STP.FAILED_ROWS
,
SDTL.READ_THRUPUT
,
SDTL.WRITE_THRUPUT
, EXTRACT(DAY FROM (SDTL.END_TS - SDTL.START_TS) DAY TO SECOND ) ||' days '
|| EXTRACT(HOUR FROM (SDTL.END_TS - SDTL.START_TS) DAY TO SECOND ) ||' hrs '
|| EXTRACT(MINUTE FROM (SDTL.END_TS - SDTL.START_TS) DAY TO SECOND ) ||' min '
|| EXTRACT(SECOND FROM (SDTL.END_TS - SDTL.START_TS) DAY TO SECOND ) ||' sec'
INFA_RUN_TIME
from W_ETL_DEFN_RUN DEF
, W_ETL_RUN_STEP STP
, W_ETL_RUN_SDTL SDTL
where DEF.ROW_WID=STP.RUN_WID
and DEF.ROW_WID ='<Unique ETL ID from the first query>’
and SDTL.RUN_STEP_WID = STP.ROW_WID
and SDTL.TYPE_CD = 'Informatica'
order by SDTL.END_TS - SDTL.START_TS desc;
If the report shows significant amounts of time to rebuild indexes and compute statistics, and the cumulative
incremental load time does not fit into your load window, you can consider two options:
Option 1: range partition large fact tables if they show up in the report. Refer to the partitioning sections for more
details.
Option 2: If the incremental volumes are low, leave bitmap indexes on the reported tables for the next incremental run
and then compare the load times. Refer to the next chapter for the implementation.
Option 2 is not recommended for fact tables (%_F). It may be used for large dimension tables, which cannot be
partitioned effectively by range.
Important: Bitmap indexes present on target tables during inserts, updates or deletes could significantly
increase the SQL DML execution time. The same SQL would complete much faster if the indexes get dropped
prior to the query execution. Alternatively, it would take more time to rebuild the dropped bitmap indexes and
compute required statistics. You should measure the cumulative time to run a specific task plus the time to
rebuild indexes and compute required database statistics before deciding whether to drop or keep bitmap
indexes in place during incremental loads.
3. Configure DAC not to drop selected bitmap indexes during incremental loads.
20
If your benchmarks show that it is less time consuming to leave bitmap indexes in place on large dimension tables
during incremental loads and the incremental volumes are relatively small, then you can consider keeping the selected
indexes in place during incremental loads.
Since the DAC system property Drop and Create Bitmap Indexes Always overrides the index property Always Drop &
Create, the system property defines how DAC will handle all bitmap indexes for all containers in the data warehouse
schema. To workaround this limitation:
• Log in into your repository through DAC user interface, click on the Design button under the top menu, and select
the Indices tab in the right pane.
• Click on the Query sub-tab and get the list of all indexes defined on the target table.
• Check both the check boxes Always Drop & Create and Inactive against the indexes, which should not be dropped
during incremental runs.
Important: You must uncheck the Inactive checkbox for these indexes before the next initial load; otherwise
DAC will not create them after the initial load completion. Since the Inactive property is used both for true
inactive indexes and "hidden from incremental load" indexes, the property Always Drop & Create could be used
for convenience to distinguish between two different categories.
If you choose to keep some bitmap indexes in place during incremental runs, consider creating the indexes with the
storage parameter PCTFREE value to at least 50 or higher. Oracle RDBMS packs bitmap indexes in a data block
much more tightly compared to B*Tree indexes. When an update, insert, or delete occurs on table columns with
enabled indexes, the bitmap indexes quality will degrade. The higher value of PCTFREE will mitigate the impact to
some degree.
4. Additional considerations for handling bitmap indexes during incremental loads.
- All bitmap indexes should be dropped for transaction fact tables, with over 20 million records, that will have a large
volume of data updates and inserts, such as over 0.5 – 1 percent of total records, during an incremental run.
- For large tables with a small number of bitmap indexes, consider dropping and recreating the bitmap indexes since
the time to rebuild would be short.
- For large tables with few data updates, the indexes can be enabled during incremental runs without significant
performance degradations.
Disabling Indexes with DISTINCT_KEYS = 1

Oracle BI Applications delivers a number of indexes to optimize both ETL and end user queries performance.
Depending on end user data and its distribution there may be some indexes on columns with just one distinct value.
Such indexes will not be used in any queries, so they can be safely dropped in your Data Warehouse schema and
disabled in DAC repository.
The following script helps to identify all such indexes, disable them in DAC repository and drop in database. You have
to either connect as DBA user or implement additional grants, since the script requires access to two database
schemes:
ACCEPT DAC_OWNER PROMPT 'Enter DAC Repository schema name: '
ACCEPT DWH_OWNER PROMPT 'Enter Data Warehouse schema name: '
SELECT row_wid FROM "&&DAC_OWNER".w_etl_app;

ACCEPT APP_ID PROMPT 'Enter your DAC container from the list above: '
UPDATE "&&DAC_OWNER".w_etl_index SET inactive_flg = 'Y' WHERE row_wid IN (

SELECT ind_ref.obj_wid
FROM "&&DAC_OWNER".w_etl_index ind,
"&&DAC_OWNER".w_etl_obj_ref ind_ref,
21
"&&DAC_OWNER".w_etl_obj_ref tbl_ref,
"&&DAC_OWNER".w_etl_table tbl,
"&&DAC_OWNER".w_etl_app app,
all_indexes all_ind
WHERE ind_ref.obj_type = 'W_ETL_INDEX'
AND ind_ref.soft_del_flg = 'N'
AND ind_ref.app_wid = '&&APP_ID'
AND tbl_ref.obj_type = 'W_ETL_TABLE'
AND tbl_ref.soft_del_flg = 'N'
AND tbl_ref.app_wid = '&&APP_ID'
AND all_ind.index_name = ind.name
AND all_ind.table_name = tbl.name
AND all_ind.distinct_keys = 1
AND all_ind.num_rows >= 1
-- AND ind.type_cd = 'Query'
AND all_ind.owner = '&&DWH_OWNER');
COMMIT;
-- Drop the indexes in the schema:
spool drop_dist_indexes.sql
SELECT 'DROP INDEX ' || owner|| '.' || index_name || ' ;'
FROM all_indexes
WHERE distinct_keys =1 and owner='&&DWH_OWNER';
spool off;
-- Execute the spooled SQL file to drop the identified indexes:

-- @drop_dist_indexes.sql
Monitoring and Disabling Unused Indexes

In addition to indexes with distinct_keys=1 there could be more redundant query indexes in your data warehouse, not
used by any end user queries. These indexes could impact incremental ETL runtime Informatica mappings
performance. Such indexes can be identified by monitoring index usage in your warehouse over extended period of
time (usually 3-4 months).
To implement index usage monitoring:
1. Create a table in your data warehouse schema to load data from v$object_usage view:
CREATE TABLE myobj_usage AS SELECT * FROM v$object_usage;
2. Create the following scripts on DAC tier in the directory <dac_home>/bifoundation/dac/scripts
pre_sql.sql
INSERT INTO myobj_usage SELECT * FROM v$object_usage;

COMMIT:
EXIT;
pre_etl.bat
<ORACLE_HOME>/bin/sqlplus <dwh_user>/<dwh_pwd>@<dwh_db>
@<dac_home>/bifoundation/dac/scripts/pre_sql.sql
3. Set "Script before every ETL" System parameter in DAC to pre_etl.bat.
4. Create a backup copy of <dac_home>/bifoundation/dac/CustomSQLs/CustomSQL.xml
22
5. Open CustomSQL.xml and replace <SqlQuery name = "ORACLE_CREATE_INDEX">, <SqlQuery name =
"ETL_ORACLE_CREATE_INDEX"> and <SqlQuery name = "QUERY_ORACLE_CREATE_INDEX"> sections
with:
<SqlQuery name = "ORACLE_CREATE_INDEX">
BEGIN
execute immediate 'CREATE %1 INDEX
%2
ON
%3
(
%4
)
NOLOGGING';
execute immediate 'ALTER INDEx %2 MONITORING USAGE';
END;
</SqlQuery>
<SqlQuery name = "ETL_ORACLE_CREATE_INDEX">

BEGIN
%2
ON
%3
(
%4
)
NOLOGGING';
execute immediate 'ALTER INDEX %2 MONITORING USAGE';
END;
</SqlQuery>
<SqlQuery name = "QUERY_ORACLE_CREATE_INDEX">

BEGIN
%2
ON
%3
(
%4
)
NOLOGGING PARALLEL';
execute immediate 'ALTER INDEX %2 MONITORING USAGE';
END;
</SqlQuery>
6. If you implement index monitoring for the first time after completing ETLs, execute the following PL/SQL block
to enable monitoring for all indexes:
DECLARE
CURSOR c1 IS
SELECT index_name
FROM user_indexes
WHERE index_name NOT IN (SELECT index_name
FROM v$object_usage
WHERE MONITORING = 'YES');
BEGIN
FOR rec IN c1 LOOP
EXECUTE IMMEDIATE 'alter index '||rec.index_name||' monitoring usage';
END LOOP;
END;
/
To query the unused indexes in your data warehouse execute the following SQL:
SELECT DISTINCT index_name FROM myobj_usage WHERE used = 'NO';
23
After identifying redundant indexes, disabling them in DAC and dropping in your data warehouse, follow the steps
below to turn off index monitoring:
1. Restore <dac_home>/bifoundation/dac/CustomSQLs/CustomSQL.xml from its backup copy.
2. Reset "Script before every ETL" System parameter in DAC
3. Execute the following PL/SQL block to disable index monitoring:
DECLARE
CURSOR c1 IS
SELECT index_name
FROM user_indexes
WHERE index_name IN (SELECT index_name FROM v$object_usage WHERE MONITORING = 'YES');
BEGIN
FOR rec IN c1 LOOP
EXECUTE IMMEDIATE 'alter index '||rec.index_name||' nomonitoring usage';
END LOOP;
END;
Important!!! Make sure you monitor the index usage for the extended period of at least 1-2 months before deciding
which additional indexes could be disabled in DAC and dropped in your target schema.
Handling Query Indexes during Initial ETL

Oracle BI Applications delivers a number of query indexes, which are not used during ETL but required for OBIEE
queries better performance. Most of query indexes are created as BITMAP indexes in Oracle database. Creation of
such large number of query indexes can extend both initial and incremental ETL windows. This article discusses
several options how to reduce index maintenance such as disabling unused query indexes, or partitioning large fact
tables and maintain local query indexes on the latest range partitions.
You can consider disabling ALL query indexes and reduce your ETL runtime in the following scenarios:
1. Disable query indexes -> run an initial ETL -> enable query indexes -> run an incremental ETL -> run OBIEE
reports
2. Disable query indexes -> run an incremental ETL -> enable query indexes -> run another incremental ETL ->
run OBIEE reports
st nd
To summarize, you can disable query indexes only for the following pattern: 1 ETL –> 2 ETL –> OBIEE. You
st nd
cannot use this option for 1 ETL –> OBIEE –> 2 ETL sequence.
Important: If you plan to implement partitioning for your warehouse tables and you want to take advantage of
conversion scripts in the next section, then you need to have query indexes, created on the target tables prior to
implementing partitioning.
• Identify and preserve all activated query indexes PRIOR to executing the first ETL run:
CREATE TABLE psr_initial_query_idx AS
SELECT ind_ref.obj_wid,
ind.NAME idx_name,
tbl.NAME tbl_name
FROM w_etl_index ind,
w_etl_obj_ref ind_ref,
w_etl_obj_ref tbl_ref,
w_etl_table tbl,
w_etl_app app
WHERE ind_ref.obj_type = 'W_ETL_INDEX'
AND ind_ref.soft_del_flg = 'N'
AND ind_ref.app_wid = :APP_ID
AND tbl_ref.obj_type = 'W_ETL_TABLE'
AND tbl_ref.soft_del_flg = 'N'
AND tbl_ref.app_wid = :APP_ID
24
AND ind.isunique = 'N'
AND ind.type_cd = 'Query'
AND (ind.DRP_CRT_ALWAYS_FLG = 'Y' OR ind.DRP_CRT_BITMAP_FLG = 'Y')
Where APP_ID can be identified from:

SELECT row_wid FROM w_etl_app;
• Disable the identified query indexes PRIOR to starting the first ETL run:
SQL> UPDATE w_etl_index SET inactive_flg = 'Y' WHERE row_wid IN (SELECT obj_wid FROM
psr_initial_query_idx);
SQL> commit;
• Execute your first ETL run.
• Enable all preserved indexes PRIOR to starting the second ETL run:
SQL> UPDATE w_etl_index SET inactive_flg = 'N' WHERE row_wid IN (SELECT obj_wid FROM
psr_initial_query_idx);
SQL> commit;
• Execute your second ETL run. DAC will recreate all disabled query indexes.
PARTITIONING GUIDELINES FOR LARGE FACT TABLES
Introduction
Taking advantage of range and composite range-range partitioning for fact tables will not only reduce index and
statistics maintenance time during ETL, but also improve web queries performance. Since the majority of inserts and
updates impact the last partition(s), you would need to disable only local indexes on a few impacted partitions, and then
rebuild disabled indexes after the load and compute statistics on updated partitions only. Online reports and
dashboards should also render results faster, since the optimizer would build more efficient execution plans using
partitions elimination logic.
Large fact tables, with more than 20 million rows, are good candidates for partitioning. To build an optimal partitioned
table with reasonable data distribution, you can consider partitioning by month, quarter, year, etc. You can either
identify and partition target fact tables before initial run, or convert the populated tables into partitioned objects after the
full load.
To implement the support for partitioned tables in Oracle Business Analytics Data Warehouse, you need to update
DAC metadata and manually convert the candidates into partitioned tables in the target database.
Follow the steps below to implement fact table partitioning in your data warehouse schema and DAC repository. Please
note that there are some steps, which apply for composite range-range partitioning only.
Convert to partitioned tables

Perform the following steps to convert a regular table into an range partitioned table.
Identify a partitioning key and decide on a partitioning interval

Choosing the correct partitioning key is the most important factor for effective partitioning, since it defines how many
partitions will be involved in web queries or ETL updates. Review the following guidelines for selecting a column for a
partitioning key:
25
• Identify eligible columns of type DATE for implementing range partitioning.
• Connect to the Oracle BI Server repository and check the usage or dependencies on each column in the
logical and presentation layers.
• Analyze the summarized data distribution in the target table by each potential partitioning key candidate and
data volumes per time range, month, quarter or year.
• Basing on the compiled data, decide on the appropriate partitioning key and partitioning range for your future
partitioned table.
• The recommended partitioning range for most implementations is a month, though you can consider a quarter
or a year for your partitioning ranges.
The proposed partitioning guidelines assume that the majority of incremental ETL volume data (~90%) is new records,
which end up in the one or two latest partitions. Depending on the chosen range granularity, you may consider
rebuilding local indexes for the most impacted latest partitions:
- Monthly range: you are advised to maintain two latest partitions, i.e. define index and table actions for PREVIOUS
and CURRENT partitions
- Quarterly range: you may consider maintaining just one, CURRENT partition.
- Yearly range: you are recommended to maintain only one, CURRENT partition.
The following table summarizes the recommended partitioning keys for some large Oracle BI Applications Fact tables:
Area Table Name Partitioning Key
Financials W_AP_XACT_F POSTED_ON_DT_WID
Financials W_AR_XACT_F POSTED_ON_DT_WID
Financials W_GL_REVN_F POSTED_ON_DT_WID
Financials W_GL_COGS_F POSTED_ON_DT_WID
Financials W_TAX_XACT_F POSTED_ON_DT_WID
Financials W_GL_OTHER_F ACCT_PERIOD_END_DT_WID
Sales W_SALES_ORDER_LINE_F ORDERED_ON_DT_WID
Sales W_SALES_PICK_LINE_F PICKED_ON_DT_WID
Sales W_SALES_INVOICE_LINE_F INVOICED_ON_DT_WID
Sales W_SALES_SCHEDULE_LINE_F ORDERED_ON_DT_WID
Siebel Sales W_REVN_F CLOSE_DT_WID
Consider implementing composite range-to-range partitioning for Projects large fact tables using the following
partitioning and sub-partitioning keys:
Area Table Name Partitioning Key Sub-partitioning Key
Projects W_PROJ_EXP_LINE_F CHANGED_ON_DT EXPENDITURE_DT_WID
26
Projects W_PROJ_COST_LINE_F CHANGED_ON_DT PROJ_ACCOUNTING_DT_WID
Projects W_PROJ_REVENUE_LINE_F CHANGED_ON_DT GL_ACCOUNTING_DT_WID
Create a partitioned table in Data Warehouse

You can pre-create a partitioned table prior to the initial load, or load data into the regular table and then create its
partitioned copy and migrate the summarized data. If you have already completed the initial load into a regular table
and then decided to partition it, you DO NOT need to re-run the initial load. You can consider two options to convert a
table into a partitioned one: (a) create table as select, or (b) create table exchange partition syntax and then split
partitions. The internal tests showed that the first option, create table as select, is simpler and faster. The second
option would be preferred in high availability data warehouses when you have to carry out partitioning with end users
accessing the data.
The example below uses the following tables for converting into partitioned objects:
• W_WRKFC_EVT_MONTH_F - range-partitioning
• W_PROJ_EXP_LINE_F - composite range-range partitioning.
1. Rename the original table
SQL> rename W_WRKFC_EVT_MONTH_F to W_WRKFC_EVT_MONTH_F_ORIG;

2. Create the partitioned table, using range partitioning by year:
SQL> create table W_WRKFC_EVT_MONTH_F partition by range (EVENT_YEAR)(

partition PART_MIN values less than (2006),
partition PART_2006 values less than (2007),
partition PART_MAX values less than (maxvalue)
)
tablespace BIAPPS_DATA
nologging parallel enable row movement
as select * from W_WRKFC_EVT_MONTH_F_ORIG;
EVENT_YEAR column in the example above uses number(4) precision, so the table partition values are defined
using format YYYY. If you choose WID column for a partitioning key, then you have to define your partition
ranges using format YYYYMMDD.
If you implement composite range-range partitioning, use the following sample syntax:
SQL> create table W_PROJ_EXP_LINE_F
partition by range (CHANGED_ON_DT)
subpartition by range (EXPENDITURE_DT_WID)
(partition PART_MIN values less then (TO_DATE('01-JAN-2008','DD-MON-YYYY'))
( subpartition PART_MIN_MIN values less than (19980000)
, subpartition PART_MIN_1998 values less than (19990000)
27
, subpartition PART_MIN_MAX values less than (maxvalue)
)
, partition PART_200801 values less than (TO_DATE('01-APR-2008','DD-MON-YYYY'))
( subpartition PART_200801_MIN values less than (19980000)
, subpartition PART_200801_1998 values less than (19990000)
, subpartition PART_200801_MAX values less than (MAXVALUE)
)
...
...
, partition PART_MAX values less than (maxvalue)
( subpartition PART_MAX_MIN values less than (19980000)
, subpartition PART_MAX_1998 values less than (19990000)
, subpartition PART_MAX_MAX values less than (maxvalue)
)
) nologging parallel
enable row movement
as (select * from W_PROJ_EXP_LINE_F_ORIG);
The composite range-range example uses Quarter for partitioning and Year for sub-partitioning ranges.
EXPENDITURE_DT_WID column has number(8) precision, so the table partition values are defined using
format YYYYMMDD.
Important: You must use the exact format YYYY, YYYYQQ or YYYYMMDD for partitioning by Year, Quarter or
Month correspondingly. Make sure you check partitioning column data type prior to partitioning a table.
3. Drop / Rename indexes on renamed table
To drop indexes on the renamed table:

SQL> spool drop_ind.sql
SQL> SELECT 'DROP INDEX '|| INDEX_NAME||';' FROM USER_INDEXES
WHERE TABLE_NAME = 'W_WRKFC_EVT_MONTH_F_ORIG';
SQL> spool off
SQL> @drop_ind.sql
If you want to keep indexes on the original renamed table until successful partitioning conversion completion, then
use the following commands:
SQL> spool rename_ind.sql

SQL> SELECT ‘ALTER INDEX ‘|| INDEX_NAME ||’ rename to ‘|| INDEX_NAME ||
‘_ORIG; ‘ FROM USER_INDEXES
WHERE TABLE_NAME = ‘W_WRKFC_EVT_MONTH_F_ORIG’;
SQL> spool off
SQL> @rename_ind.sql
28
4. Create Global and Local indexes.
4.1. Execute the following queries as DAC Repository owner:
SQL> spool indexes.sql

SQL> SELECT 'CREATE '
||DECODE(ISUNIQUE,'Y','UNIQUE ')
||DECODE(ISBITMAP,'Y','BITMAP ')
||'INDEX '
||I.NAME ||CHR(10)
||' ON '
||T.NAME
||' ('
||MAX(DECODE(POSTN,1,C.NAME||' ASC')) ||CHR(10)
||MAX(DECODE(POSTN,2,' ,'||C.NAME||' ASC'))
||') tablespace USERS_IDX ' ||CHR(10)
||DECODE(ISUNIQUE,'Y','GLOBAL','LOCAL')
||' NOLOGGING;'
FROM W_ETL_TABLE T, W_ETL_INDEX I, W_ETL_INDEX_COL C
WHERE T.ROW_WID = I.TABLE_WID
AND T.NAME = 'W_WRKFC_EVT_MONTH_F'
AND I.ROW_WID = C.INDEX_WID
AND I.INACTIVE_FLG = 'N'
GROUP BY T.NAME,I.NAME,ISBITMAP,ISUNIQUE;
SQL> spool off;
The script creates indexes with maximum seven positions. If you have indexes with more than seven column
positions, then update modify "MAX(DECODE(POSTN...))" sentence.
Run the spooled file indexes.sql in warehouse schema.
SQL> @indexes.sql
4.2. Compute Statistics on Partitioned Table
SQL> BEGIN
dbms_stats.Gather_table_stats(
NULL,
tabname => 'W_WRKFC_EVT_MONTH_F',
CASCADE => true,
estimate_percent => dbms_stats.auto_sample_size,
method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO');
END;
Configure Informatica to support partitioned tables

Enable Row Movement
Set skip_unusable_indexes = TRUE in DataWarehouse Relational Connection in Informatica Workflow Manager.
Open Workflow Manager -> Connections -> Relational -> edit DataWarehouse -> Update Connection Environment
SQL:
ALTER SESSION SET SKIP_UNUSABLE_INDEXES=TRUE;
Configure DAC to support partitioned tables

Create new source system parameters
29
Important: This example below shows how to set up rebuilding indexes and maintaining statistics for last two
PREVIOUS and CURRENT partitions for range partitioning by year. You should consider implementing PREVIOUS
and CURRENT partitions only for monthly or more granular ranges. If you choose quarterly or yearly range, then you
can maintain CURRENT partition only. Maintaining PREVIOUS partition for partitioning by a quarter or a year may
introduce unnecessary overhead and extend your incremental ETL execution time.
Define the following source system parameters:
• Select Design Menu
• Click on Source System Parameters tab in the right pane
• Click New Button and define two new parameters with the following attributes:
Name: $$CURRENT_YEAR_WID
Data Type: SQL
Value (click on checkbox icon to define the following parameters):
Logical Data Source: DBConnection_OLAP
Enter the following SQL:
SELECT TO_CHAR(ROW_WID) FROM W_YEAR_D WHERE W_CURRENT_CAL_YEAR_CODE = 'Current'
Name: $$PREVIOUS_YEAR_WID
Data Type: SQL
Value (click on checkbox icon to define the following parameters):
Logical Data Source: DBConnection_OLAP
Enter the following SQL:
SELECT TO_CHAR(ROW_WID) FROM W_YEAR_D WHERE W_CURRENT_CAL_YEAR_CODE = 'Previous'
Important: Make sure you select the correct Logical Data Source, DBConnection_OLAP, which points to
your target data warehouse, when you define these new system parameters.
If you choose monthly partitions, then use the following names and values:
Name: $$PREVIOUS_MONTH_WID
Value: SELECT TO_CHAR(ROW_WID) FROM W_MONTH_D WHERE W_CURRENT_CAL_MONTH_CODE ='Previous'
Name: $$CURRENT_MONTH_WID
Value: SELECT TO_CHAR(ROW_WID) FROM W_MONTH_D WHERE W_CURRENT_CAL_MONTH_CODE = 'Current'
If you choose Quarterly partitions, then use the following names / values:
Name: $$PREVIOUS_QTR_WID
Value: SELECT TO_CHAR(ROW_WID) FROM W_QTR_D WHERE W_CURRENT_CAL_QTR_CODE = 'Previous'
Name: $$CURRENT_QTR_WID
Value: SELECT TO_CHAR(ROW_WID) FROM W_QTR_D WHERE W_CURRENT_CAL_QTR_CODE = 'Current'
Update Index Action Framework
Create the following Index Actions in DAC Action Framework:
1. Year Partitioning: Disable Local Index Parameter
• Navigate to Tools -> Seed Data -> Actions -> Index Actions -> New
• Enter Name: Year Partitioning: Disable Local Index
• Click on ‘Check’ Icon in Value field
30
• Click on Add button in the new open window
• Define ‘PREVIOUS_YEAR_WID Local Index’ SQL:
Name: Disable PREVIOUS_YEAR_WID Local Indexes

Type: SQL
Database Connection: target
Valid Database Platform: ORACLE
• Enter the following command in the lower right Text Area:

alter index getIndexName() modify partition PART_@DAC_$$PREVIOUS_YEAR_WID unusable
Important!!! Do not use semicolon (;) at the end of SQLs in Text Area.
• Click ‘Add’ button to define the second SQL command.
• Define ‘CURRENT_YEAR_WID Local Index’ SQL:
Name: Disable CURRENT_YEAR_WID Local Index

Type: SQL
• Enter the following command in the lower right Text Area:

alter index getIndexName() modify partition PART_@DAC_$$CURRENT_YEAR_WID unusable
• Save the changes.
Note: If you use Quarterly or Monthly partition range, then use PREVIOUS_MONTH_WID /
CURRENT_MONTH_WID or PREVIOUS_QTR_WID / CURRENT_QTR_WID in Action names and SQLs.
Important!!! If you implement partitioning by Year, Quarter, Month, then you need to define separate actions
for each range.
2. Year Partitioning: Enable Local Index Parameter
• Click ‘New’ in Index Actions window to create a new parameter
• Enter Name: Year Partitioning: Enable Local Index
• Define the following two values:
Name Enable PREVIOUS_YEAR_WID Local Index

Type: SQL
Enter the following command in the lower right Text Area:

alter index getIndexName() rebuild partition PART_@DAC_$$PREVIOUS_YEAR_WID nologging
Name Enable CURRENT_YEAR_WID Local Index

Type: SQL
31
alter index getIndexName() rebuild partition PART_@DAC_$$CURRENT_YEAR_WID nologging

Note: If you Quarterly or Monthly partition range, then use PREVIOUS_MONTH_WID /
3. Year Partitioning: Enable Local Sub-Partitioned Index Parameter (for composite partitioning only)
• Enter Name: Year Partitioning: Enable Local Index
• Define the following value:
Name Enable Local Sub-partitioned Index

Type: Stored Procedure

DECLARE
CURSOR C1 IS
SELECT DISTINCT SUBPARTITION_NAME
FROM USER_IND_SUBPARTITIONS
WHERE INDEX_NAME='getIndexName()' AND STATUS = 'UNUSABLE';
BEGIN
FOR REC IN C1 LOOP
EXECUTE IMMEDIATE 'alter index getIndexName() rebuild subpartition
'||REC.SUBPARTITION_NAME||'';
END LOOP;
END
4. Year Partitioning: Create Local Bitmap Index Parameter
• Enter Name: Year Partitioning: Create Local Bitmap Index
Name Create Local Bitmap Indexes

Type: SQL

Create bitmap index getIndexName() on getTableName()(getUniqueColumns()) tablespace
getTableSpace() local parallel nologging
32
Save the changes.
5. Year Partitioning: Create Local B-Tree Index Parameter
• Enter Name: Year Partitioning: Create Local B-Tree Index
Name Create Local B-Tree Index

Type: SQL

Create index getIndexName() on getTableName()(getUniqueColumns()) tablespace
getTableSpace() local parallel nologging
Save the changes.
6. Year Partitioning: Create Global Unique Index Parameter
• Enter Name: Year Partitioning: Create Global Unique Index
Name Create Local B-Tree Indexes

Type: SQL

Create unique index getIndexName() on getTableName()(getUniqueColumns()) tablespace
getTableSpace() global parallel nologging
Save the changes.
Update Table Action Framework
Create the following Table Action in DAC Action Framework:
1. Year Partitioning: Gather Partition Stats Parameter
• Navigate to Tools -> Seed Data -> Actions -> Table Actions -> New
• Enter Name: Year Partitioning: Gather Partition Stats
33
Name: Gather Partition Stats


DECLARE
CURSOR C1 IS
SELECT DISTINCT UTP.PARTITION_NAME
FROM USER_IND_PARTITIONS UIP,
USER_PART_INDEXES UPI,
USER_TAB_PARTITIONS UTP
WHERE UIP.INDEX_NAME=UPI.INDEX_NAME
AND UIP.STATUS = 'USABLE'
AND UTP.TABLE_NAME=UPI.TABLE_NAME
AND UTP.PARTITION_POSITION=UIP.PARTITION_POSITION
AND UPI.TABLE_NAME = 'getTableName()'
AND UTP.PARTITION_NAME IN
('PART_@DAC_$$CURRENT_YEAR_WID','PART_@DAC_$$PREVIOUS_YEAR_WID');
BEGIN
FOR REC IN C1 LOOP
DBMS_STATS.GATHER_TABLE_STATS(
NULL,
TABNAME => 'getTableName()',
CASCADE => FALSE,
PARTNAME => REC.PARTITION_NAME,
ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE,
GRANULARITY => 'PARTITION',
METHOD_OPT => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
DEGREE => DBMS_STATS.DEFAULT_DEGREE);
END LOOP;
END;
Note: If you Quarterly or Monthly partition range, then use PREVIOUS_MONTH_WID /

2. Quarter Composite Partitioning: Gather Partition Stats Parameter (for composite partitioning only)
• Navigate to Tools -> Seed Data -> Actions -> Table Actions -> New
• Enter Name: Quarter Composite Partitioning: Gather Partition Stats
Name: Gather Partition Stats


DECLARE
CURSOR C1 IS
34
SELECT DISTINCT UTP.PARTITION_NAME
FROM USER_IND_PARTITIONS UIP,
USER_PART_INDEXES UPI,
USER_TAB_PARTITIONS UTP
WHERE UIP.INDEX_NAME=UPI.INDEX_NAME
AND UIP.STATUS = 'USABLE'
AND UTP.TABLE_NAME=UPI.TABLE_NAME
AND UTP.PARTITION_POSITION=UIP.PARTITION_POSITION
AND UPI.TABLE_NAME = 'getTableName()'
AND UTP.PARTITION_NAME IN
('PART_@DAC_$$CURRENT_QTR_WID','PART_@DAC_$$PREVIOUS_QTR_WID');
BEGIN
FOR REC IN C1 LOOP
DBMS_STATS.GATHER_TABLE_STATS(
NULL,
TABNAME => 'getTableName()',
CASCADE => FALSE,
PARTNAME => REC.PARTITION_NAME,
ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE,
GRANULARITY => 'PARTITION',
METHOD_OPT => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
DEGREE => DBMS_STATS.DEFAULT_DEGREE);
END LOOP;
END;
Important!!! DO NOT change ‘Drop / Create Always’ or ‘Drop / Create Always Bitmap’ properties for the modified
indexes. Un-checking these properties would signal DAC to skip any actions, defined in Index Action Framework.
Attach Index Action to the desired indexes
• Retrieve all local indexes on partitioned tables. Navigate to Design -> Indices -> Query ->Table Name
'W_WRKFC_EVT_MONTH_F', check ‘Is Bitmap’ checkbox -> Go.
Important!!! Make sure you exclude the selected global index from the index query result set. The global
index must NOT have any assigned index action tasks.
• Right click your mouse on the generated list (Upper right pane) and select ‘Add Actions’
• Select ‘Drop Index’ from Action Type field
• Select ‘Incremental’ from Load Type field
• Click on Checkbox icon in Action field
• Select ‘Year Partitioning: Disable Local Indexes’ Action Name
• Click OK in Choose Action window
• Click OK in Add Actions window.
• Right click your mouse on the generated list (Upper right pane) and select ‘Add Actions’ one more time
• Select ‘Create Index’ from Action Type field
• Select ‘Year Partitioning: Enable Local Indexes’ Action Name
35
The steps above apply to all indexes, retrieved by your query. If you want to attach the defined Index Actions
for an individual index, then select the desired index in the right upper pane, and click on ‘Actions’ sub-tab in
the lower pane. Then click ‘New’ button in the lower pane and fill in the appropriate values in the new line.
• Repeat the same steps above to attach ‘Year Partitioning: Create Local Bitmap Index’, ‘Year Partitioning:
Create Local B-Tree Index’ and ‘Year Partitioning: Create Global Unique Index’ to the appropriate indexes,
used in an initial ETL run.
Important: Make sure you choose ‘Initial’ from Load Type field, when attaching ‘Year Partitioning: Create
Local Bitmap Index’, ‘Year Partitioning: Create Local B-Tree Index’ and ‘Year Partitioning: Create Global
Unique Index’ Index Action Tasks.
Even though you select Drop/Create Index Action Type, DAC will override these actions with the steps, defined
in Index Action Framework. Every time, DAC encounter ‘Drop Index’ step for an updated index, it will make it
unusable for the last two partitions, and for ‘Create Index’ – rebuild the index for the last two partitions.
Attach Table Action to the converted partitioned table
• Retrieve the partitioned tables. Navigate to Design -> Tables -> Query -> Name
'W_WRKFC_EVT_MONTH_F' -> Go.
• Right click your mouse on the generated list (Upper right pane) and select ‘Add Actions’
• Select ‘Analyze Table’ from Action Type field
• Select ‘Year Partitioning: Gather partition stats’ Action Name
Important!!! Make sure you use ‘Quarter Composite Partitioning: Gather Partition Stats’ parameter for
composite range-range tables.
If you want to attach the defined Table Action for an individual table, then select the desired table in the right
upper pane, and click on ‘Actions’ sub-tab in the lower pane. Then click ‘New’ button in the lower pane and fill
in the appropriate values in the new line.
Whenever DAC encounter ‘Analyze Table’ step for an updated table, it will override the default action by the set
of steps from Table Action Framework.
Unit test the changes for converted partitioned tables in DAC

You can generate the list of actions for a single task, which populates a partitioned table, to validate the correct
sequence of steps without executing them.
Follow the steps below to unit test the sequence of steps for a partitioned table:
• Select ‘Execute’ button from your top sub-menu
• Select your execution plan in the upper right pane
• Click ‘Ordered tasks’ sub-tab in the lower right pane
• Retrieve the task which populates your partitioned table
• Click ‘Unit test’ button in the lower right pane menu.
36
• Click ‘Yes’ to proceed with unit testing.
• Validate the generated sequence of steps in the new output window.
Important!!! DO NOT execute them in your data warehouse.
• Exit unit testing window.
Interval Partitioning
Oracle 11G introduced a new partitioning type, Interval Partitioning. Oracle automatically creates new partitions with
pre-defined range interval. With Interval Partitioning there is no need to pre-create partitions for data in the future.
The majority of recommended partitioning keys in Oracle BI Applications are using DATE format YYYYMMDD.. For
example, POSTED_ON_WID column is based on monthly range partitions with values less than 20041101, 20041201,
20050101, 20050201, etc. You can specify INTERVAL 100 for such range format. Oracle will skip creating partitions for
ranges with no data. In the example with POSTED_ON_WID there is a very large gap between ranges 20041201 and
20050101, so Oracle wouldn’t create any partitions in-between.
TABLE COMPRESSION IMPLEMENTATION GUIDELINES

Oracle Database table compression can be applied effectively to optimize the space consumption and reduce memory
use in buffer cache in Oracle Business Analytics Data Warehouse. Compressed tables require significantly less disk
storage and result in improved query performance due to reduced I/O and buffer cache requirements. It’s a valuable
feature, especially in a warehouse environment, where data loaded once, and read many times by end user queries.
Table compression requires careful analysis and planning to take the advantage of efficient space consumption, faster
end user query performance, while keeping incremental ETL within acceptable execution time frame.
Review the following recommendations and guidelines before table compression implementation:
1. The recommended Oracle Database version is 11.1.0.7 or higher. You must apply the following database
patches 8834636 and 8930565. Check with Oracle Support for any additional database patches.
2. Table compression should be implemented for target tables after careful analysis of DML operation types, data
volumes and ETL performance benchmarks.
3. The majority of Initial Informatica mappings use Bulk Load, so their target tables can be compressed to deliver
comparable or better ETL performance. There is a smaller set of initial mappings, which use Normal Load type
in Informatica. If you couldn’t change their Load type to Bulk, then leave their corresponding target tables
uncompressed.
4. Oracle Business Intelligence Applications delivers several Informatica mappings, which perform mass updates
during Initial ETL. The target tables for such mappings should NOT be compressed. W_POSITION_DH,
updated by SIL_PositionDimensionHierarchy_AsIsUpdate_Full. is an example of compression exception.
5. Incremental Informatica mappings always use Normal Load mode, so table compression may cause
performance overhead, especially for very large incremental volumes. Make sure you carefully benchmark the
mappings using compressed tables before implementing the compression in your production data warehouse.
6. Consider implementing table compression for Partitioned Fact tables at partition level:
a. Active partitions, loaded during incremental ETLs, should be uncompressed
b. Older, relatively static partitions can be good compression candidates
7. Staging tables are truncated during incremental ETLs, so they can be considered for compression.
8. After compressing a table you need to rebuild all its indexes (ALTER INDEX …. REBUILD syntax).
37
GUIDELINES FOR ORACLE OPTIMIZER HINTS USAGE IN ETL MAPPINGS
Hash Joins versus Nested Loops in Oracle RDBMS

Though Oracle optimizer chooses the most efficient plan with the least cost for a query, sometimes database hints can
help to improve efficiency and increase overall ETL performance, in spite of the higher estimated query cost, reported
in very large volume Oracle Business Analytics Data Warehouses.
If tables, used in a query, have indexes defined on the joining columns in a WHERE clause, the optimizer might choose
Nested loop join over Hash join accessing a table using an index defined on a column, used in a join. Although this
approach may start returning results sooner the overall time to fetch all the records could be considerably longer.
Specifying the hint USE_HASH would change the execution plan to use a full table scan (in some cases the optimizer
might still use indexes, such as index fast full scan) for a table involved in the query. Initial records fetch may take more
time as hash joins are built in memory, but the overall time for fetching all the records would be reduced quite
dramatically.
Important: Oracle might take up to 8-10 hours just to build hashes in memory for very large tables (over 100
million records), so it is important not to kill the query.
ETL is a batch process, measured by overall time to load all the records, so you should avoid using nested loops by
incorporating hint USE_HASH for tables with volumes over ten million records.
The real life example below provides the comparison between NESTED LOOPS and HASH JOIN execution. The
numbers are applicable to the specific test case configuration, which would vary depending on hardware specifications
and database settings.
Table No of Rows
--------------------- ----------
PAY_RUN_RESULT_VALUES 900 Million
PAY_RUN_RESULTS 14 Million
PAY_ASSIGNMENT_ACTIONS 50 Million
PAY_INPUT_VALUES_F 10000
PAY_ELEMENT_TYPES_F 10000
PAY_PAYROLL_ACTIONS 1445896
PAY_ELEMENT_CLASSIFICATIONS 1897
PER_TIME_PERIODS 52728
SELECT PAY_ASSIGNMENT_ACTIONS.ASSIGNMENT_ACTION_ID,
PAY_ASSIGNMENT_ACTIONS.ASSIGNMENT_ID,
PAY_ELEMENT_TYPES_F.INPUT_CURRENCY_CODE,
PAY_ELEMENT_TYPES_F.OUTPUT_CURRENCY_CODE,
PER_TIME_PERIODS.END_DATE,
PER_TIME_PERIODS.START_DATE,
PAY_PAYROLL_ACTIONS.PAY_ADVICE_DATE,
PAY_PAYROLL_ACTIONS.LAST_UPDATE_DATE,
PAY_PAYROLL_ACTIONS.LAST_UPDATED_BY,
PAY_PAYROLL_ACTIONS.CREATED_BY,
PAY_PAYROLL_ACTIONS.CREATION_DATE,
PAY_RUN_RESULT_VALUES.INPUT_VALUE_ID,
PAY_RUN_RESULT_VALUES.RUN_RESULT_ID,
PAY_RUN_RESULT_VALUES.RESULT_VALUE,
PAY_RUN_RESULTS.ELEMENT_TYPE_ID,
PAY_INPUT_VALUES_F.LAST_UPDATE_DATE LAST_UPDATE_DATE1,
PAY_ELEMENT_TYPES_F.LAST_UPDATE_DATE LAST_UPDATE_DATE2
FROM PAY_RUN_RESULT_VALUES,
PAY_RUN_RESULTS,
PAY_INPUT_VALUES_F,
PAY_ASSIGNMENT_ACTIONS,
PAY_ELEMENT_TYPES_F,
PAY_PAYROLL_ACTIONS,
PAY_ELEMENT_CLASSIFICATIONS,
PER_TIME_PERIODS
WHERE (PAY_PAYROLL_ACTIONS.LAST_UPDATE_DATE >= TO_DATE('01/01/2007 00:00:00','MM/DD/YYYY
HH24:MI:SS')
OR PAY_INPUT_VALUES_F.LAST_UPDATE_DATE >= TO_DATE('01/01/2007 00:00:00','MM/DD/YYYY
HH24:MI:SS')
38
OR PAY_ELEMENT_TYPES_F.LAST_UPDATE_DATE >= TO_DATE('01/01/2007 00:00:00','MM/DD/YYYY
HH24:MI:SS'))
AND PAY_PAYROLL_ACTIONS.ACTION_STATUS = 'C'
AND PAY_PAYROLL_ACTIONS.ACTION_POPULATION_STATUS = 'C'
AND PAY_ASSIGNMENT_ACTIONS.ACTION_STATUS = 'C'
AND PAY_INPUT_VALUES_F.UOM = 'M'
AND PAY_RUN_RESULT_VALUES.RUN_RESULT_ID = PAY_RUN_RESULTS.RUN_RESULT_ID
AND PAY_RUN_RESULT_VALUES.INPUT_VALUE_ID = PAY_INPUT_VALUES_F.INPUT_VALUE_ID
AND PAY_RUN_RESULTS.ASSIGNMENT_ACTION_ID = PAY_ASSIGNMENT_ACTIONS.ASSIGNMENT_ACTION_ID
AND PAY_RUN_RESULTS.ELEMENT_TYPE_ID = PAY_ELEMENT_TYPES_F.ELEMENT_TYPE_ID
AND PAY_ASSIGNMENT_ACTIONS.PAYROLL_ACTION_ID = PAY_PAYROLL_ACTIONS.PAYROLL_ACTION_ID
AND PAY_PAYROLL_ACTIONS.EFFECTIVE_DATE BETWEEN PAY_INPUT_VALUES_F.EFFECTIVE_START_DATE
AND PAY_INPUT_VALUES_F.EFFECTIVE_END_DATE
AND PAY_PAYROLL_ACTIONS.EFFECTIVE_DATE BETWEEN PAY_ELEMENT_TYPES_F.EFFECTIVE_START_DATE
AND PAY_ELEMENT_TYPES_F.EFFECTIVE_END_DATE
AND PAY_ELEMENT_CLASSIFICATIONS.CLASSIFICATION_ID = PAY_ELEMENT_TYPES_F.CLASSIFICATION_ID
AND PER_TIME_PERIODS.TIME_PERIOD_ID = PAY_PAYROLL_ACTIONS.TIME_PERIOD_ID
AND PAY_INPUT_VALUES_F.NAME = 'Pay Value'
AND CLASSIFICATION_NAME NOT LIKE '%Information%'
AND CLASSIFICATION_NAME NOT LIKE '%Employer%'
AND CLASSIFICATION_NAME NOT LIKE '%Balance%'
AND PAY_RUN_RESULTS.SOURCE_TYPE IN ('I', 'E')
The Explain Plan for the query is below:
Plan hash value: 1498624813

TempS
Id Operation Name Rows Bytes Cost (%CPU) Time
pc
0 SELECT STATEMENT 60 14040 111K (2) 00:22:23
1 CONCATENATION
2 NESTED LOOPS 55 12870 83423 (2) 00:16:42
3 HASH JOIN 59 12980 8064K 83304 (2) 00:16:40
4 TABLE ACCESS BY INDEX ROWID PAY_ASSIGNMENT_ACTIONS 7 147 7 (0) 00:00:01
5 NESTED LOOPS 38937 7604K 47490 (1) 00:09:30
6 HASH JOIN 5503 961K 9053 (4) 00:01:49
7 TABLE ACCESS FULL PAY_ELEMENT_CLASSIFICATIONS 1626 47154 13 (0) 00:00:01
8 MERGE JOIN 5505 806K 9039 (4) 00:01:49
9 SORT JOIN 3369 355K 8931 (4) 00:01:48
10 HASH JOIN 3369 355K 8930 (4) 00:01:48
11 MERGE JOIN 3527 292K 8579 (4) 00:01:43
12 SORT JOIN 15 675 156 (3) 00:00:02
13 TABLE ACCESS FULL PAY_INPUT_VALUES_F 15 675 155 (2) 00:00:02
14 FILTER
15 SORT JOIN 96393 3765K 11M 8424 (4) 00:01:42
16 TABLE ACCESS FULL PAY_PAYROLL_ACTIONS 96393 3765K 7424 (5) 00:01:30
17 TABLE ACCESS FULL PER_TIME_PERIODS 52728 1184K 349 (1) 00:00:05
18 FILTER
19 SORT JOIN 654 27468 106 (3) 00:00:02
20 TABLE ACCESS FULL PAY_ELEMENT_TYPES_F 654 27468 105 (2) 00:00:02
21 INDEX RANGE SCAN PAY_ASSIGNMENT_ACTIONS_N50 35 3 (0) 00:00:01
22 TABLE ACCESS FULL PAY_RUN_RESULTS 9986K 190M 20007 (4) 00:04:01
23 TABLE ACCESS BY INDEX ROWID PAY_RUN_RESULT_VALUES 1 14 3 (0) 00:00:01
24 INDEX UNIQUE SCAN PAY_RUN_RESULT_VALUES_PK 1 2 (0) 00:00:01
25 NESTED LOOPS 4 936 19634 (1) 00:03:56
26 HASH JOIN 4 820 19630 (1) 00:03:56
27 NESTED LOOPS 1460 232K 19524 (1) 00:03:55
28 NESTED LOOPS 1552 225K 14863 (1) 00:02:59
29 NESTED LOOPS 1579 198K 8538 (1) 00:01:43
30 NESTED LOOPS 223 24084 6974 (1) 00:01:24
31 NESTED LOOPS 234 19890 6740 (1) 00:01:21
TABLE ACCESS BY INDEX
33 PAY_PAYROLL_ACTIONS 241 9640 6585 (1) 00:01:20
ROWID
34 INDEX RANGE SCAN PAY_PAYROLL_ACTIONS_N5 72295 341 (1) 00:00:05
35 PER_TIME_PERIODS 1 23 1 (0) 00:00:01
ROWID
36 INDEX UNIQUE SCAN PER_TIME_PERIODS_PK 1 0 (0) 00:00:01
37 TABLE ACCESS BY INDEX ROWID PAY_ASSIGNMENT_ACTIONS 7 147 7 (0) 00:00:01
39 TABLE ACCESS BY INDEX ROWID PAY_RUN_RESULTS 1 20 4 (0) 00:00:01
40 INDEX RANGE SCAN PAY_RUN_RESULTS_N50 20 2 (0) 00:00:01
39
43 TABLE ACCESS FULL PAY_ELEMENT_TYPES_F 9873 404K 105 (2) 00:00:02
PAY_ELEMENT_CLASSIFICATION
44 TABLE ACCESS BY INDEX ROWID 1 29 1 (0) 00:00:01
_S
PAY_ELEMENT_CLASSIFICATION
45 INDEX UNIQUE SCAN 1 0 (0) 00:00:01
_PK
46 NESTED LOOPS 1 234 8809 (4) 00:01:46
47 NESTED LOOPS 1 205 8808 (4) 00:01:46
48 HASH JOIN 1 191 8805 (4) 00:01:46
49 TABLE ACCESS BY INDEX ROWID PAY_RUN_RESULTS 1 20 4 (0) 00:00:01
50 NESTED LOOPS 213 31737 8699 (4) 00:01:45
51 NESTED LOOPS 217 27993 7829 (4) 00:01:34
52 NESTED LOOPS 31 3348 7612 (5) 00:01:32
53 MERGE JOIN 32 2720 7580 (5) 00:01:31
54 SORT JOIN 14 630 156 (3) 00:00:02
56 FILTER
57 SORT JOIN 939 37560 7424 (5) 00:01:30
58 TABLE ACCESS FULL PAY_PAYROLL_ACTIONS 939 37560 7423 (5) 00:01:30
59 PER_TIME_PERIODS 1 23 1 (0) 00:00:01
ROWID
60 INDEX UNIQUE SCAN PER_TIME_PERIODS_PK 1 0 (0) 00:00:01
61 PAY_ASSIGNMENT_ACTIONS 7 147 7 (0) 00:00:01
ROWID
63 INDEX RANGE SCAN PAY_RUN_RESULTS_N50 20 2 (0) 00:00:01
67 TABLE ACCESS BY INDEX ROWID PAY_ELEMENT_CLASSIFICATIONS 1 29 1 (0) 00:00:01
PAY_ELEMENT_CLASSIFICATION_
68 INDEX UNIQUE SCAN 1 0 (0) 00:00:01
PK
The query took more than 48 hours to execute and produced 128 million records even though the first record was
fetched within 1.5 hours of the execution. The reported throughput achieved is 700 RPS.
Note: The optimizer chose to access the tables through index paths, and then joined the result sets using
Nested Loops.
After adding the hint USE_HASH(PAY_RUN_RESULT_VALUES PAY_RUN_RESULTS PAY_INPUT_VALUES_F

PAY_ASSIGNMENT_ACTIONS PAY_ELEMENT_TYPES_F PAY_PAYROLL_ACTIONS
PAY_ELEMENT_CLASSIFICATIONS PER_TIME_PERIODS) to the preceding query, the optimizer produced the
following execution plan:
Plan hash value: 3421230164

Id Operation Name Rows Bytes TempSpc Cost (%CPU) Time
0 SELECT STATEMENT 10 2340 932K (5) 03:06:29
1 HASH JOIN 10 2340 932K (5) 03:06:29
2 HASH JOIN 10 2050 932K (5) 03:06:28
4 HASH JOIN 103K 15M 932K (5) 03:06:27
5 HASH JOIN 1624 231K 167K (3) 00:33:28
6 HASH JOIN 1700 204K 166K (3) 00:33:23
8 HASH JOIN 670K 51M 47M 166K (3) 00:33:22
9 HASH JOIN 682K 39M 4896K 128K (3) 00:25:48
10 TABLE ACCESS FULL PAY_PAYROLL_ACTIONS 96393 3765K 7424 (5) 00:01:30
11 TABLE ACCESS FULL PAY_ASSIGNMENT_ACTIONS 10M 203M 105K (3) 00:21:03
12 TABLE ACCESS FULL PAY_RUN_RESULTS 9986K 190M 20007 (4) 00:04:01
13 TABLE ACCESS FULL PER_TIME_PERIODS 52728 1184K 349 (1) 00:00:05
14 TABLE ACCESS FULL PAY_RUN_RESULT_VALUES 912M 11G 751K (4) 02:30:21
15 TABLE ACCESS FULL PAY_ELEMENT_CLASSIFICATIONS 1626 47154 13 (0) 00:00:01
Even though the estimated cost went up, the query completed much faster. Below is the summary of two executions:
40
Query CPU Cost First records Fetch Reported Informatica Mapping Execution
Start Time Throughput Time
No Hints (nested loops) 111K After 1 hour 30 min 700 rows / sec 48 hours
Hash Join hint 923K After 5 hours 3000 rows / sec 10 hours
Suggested hints for Oracle Business Intelligence Applications 7.9.6

The following table summarizes the database hints, which helped to improve Oracle Business Intelligence Applications
7.9.6 mappings performance in internal performance tests.
Adapter Mapping name ETL Recommended hints

mode
Common Dimensions
Siebel, OM, SIL_PartyDimension_Person Initial /*+ USE_HASH(PTY PER DS) NO_INDEX(PTY) */

SCA
OM SIL_PartyDimension_Organization Initial /*+ NO_INDEX(ORG) */
Siebel SDE_PartyPersonDimension Initial / set DTM Buffer Size to 32000000
Incr. set Default Buffer Block Size to 128000
PRJ, SCA, SDE_ORA_PartyPersonDimension_Cu Initial $$HINT1: /*+ USE_HASH(PER PTY CNP SUP)*/
HCM, OM stomer $$HINT2: /*+ USE_HASH(PP) */
SCA, SCM, SDE_ORA_PartyOrganizationDimensio Initial $$HINT1: /*+ USE_HASH(HZ_ORGANIZATION_PROFILES HZ_PARTIES ) */
OM, PRJ n_Customer_Full $$HINT2: /*+USE_HASH(DOM_ULT_DUNS, DOM_REL) */
SCA, SCM, SDE_ORA_PartyOrganizationDimensio Incr. /*+ USE_HASH(HZ_ORGANIZATION_PROFILES HZ_PARTIES) */
OM, PRJ n_Customer
PRJ SIL_GLAccountDimension_SCDUpdate Incr. /*+ INDEX (TARGET_TABLE W_GL_ACCOUNT_D_U1) INDEX (SCD_OUTER
W_GL_ACCOUNT_D_U1)*/
FIN, PRJ, SDE_ORA_PartyContactStaging Incr. $$HINT1:/*+ INDEX(PP HZ_PARTIES_U1)*/
SCA, OM $$HINT2: /*+ USE_HL(OC TMP1)*/
FIN, OM, SDE_ORA_INVENTORYPRODUCTDI Initial /*+ FULL(PER_ALL_PEOPLE_F) */
PRJ, SCA MENSION_FULL
Siebel CRM
SIL_ResponseFact_Full Initial /*+ NO_INDEX(w_regn_d) NO_INDEX(w_segment_d) NO_INDEX(offer)

NO_INDEX(terr) NO_INDEX(W_WAVE_D) NO_INDEX(w_ld_wave_d)
NO_INDEX(w_source_d) */
SIL_PartyDimension_Person Initial $$HINT1: /*+ USE_HASH(PTY PER DS) FULL(PTY) */
SIL_Agg_OverlappingCampaign_Accou Incr. $$HINT1 /*+ NO_INDEX(SRC) NO_INDEX(OSRC) */
nts $$HINT2 /*+ FULL(W_CAMP_HIST_F) */
$$HINT3 /*+ FULL(W_CAMP_HIST_F) */
SIL_Agg_OverlappingCampaign_Conta Incr. $$HINT1 /*+ NO_INDEX(SRC) NO_INDEX(OSRC) */
cts $$HINT2 /*+ FULL(W_CAMP_HIST_F) */
$$HINT3 /*+ FULL(W_CAMP_HIST_F) */
SIL_Agg_ResponseCampaignOffer and Incr. /*+ FULL(W_PARTY_PER_D) */
SIL_Agg_ResponseCampaign
EBS Supply Chain
11.5.10 SDE_ORA_PurchaseReceiptFact Initial / /*+ FULL(RCV_TRANSACTIONS) */

Incr.
SDE_ORA_StandardCostGeneral_Full Initial / /+ USE_HASH(MTL_SYSTEM_ITEMS_B)/
Incr.
SIL_ExpenseFact_FULL Initial /*+ USE_HASH(W_PROJECT_D) */
SIL_APInvoiceDistributionFact_Full Initial /*+ USE_HASH(W_AP_INV_DIST_FS PO_PLANT_LOC PO_RCPT_LOC
41
OPERATING_UNIT_ORG PAYABLES_ORG PURCHASE_ORG W_LEDGER_D
INV_TYPE DIST_TYPE SPEND_TYPE APPROVAL_STATUS PAYMENT_STATUS
W_AP_TERMS_D W_PROJECT_D EXPENDITURE_ORG CREATED_BY
CHANGED_BY W_XACT_SOURCE_D W_Financial_Resource_D
W_GL_ACCOUNT_D W_PARTY_D W_SUPPLIER_ACCOUNT_D) */
SDE_ORA_BOMHeaderDimension_Full Initial /*+ FULL(M) */
SDE_ORA_PROJECT_HIERARCHYDI Initial / /*+ USE_HASH(PPV1 PPV2 POR1 POR2 PPEVS1 PPE1 PPE2 PPA2) */
MENSION_STAGE1 Incr.
SDE_ORA_TASKS Initial / $$HINT1 /*+ USE_HASH(PA_TASKS PA_TASK_TYPES
Incr. PA_PROJ_ELEMENT_VERSIONS PA_PROJ_ELEMENTS
PA_PROJECT_STATUSES PA_PROJ_ELEM_VER_STRUCTURE
PA_PROJECTS_ALL PA_PROJECT_TYPES_ALL
PA_PROJ_ELEM_VER_SCHEDULE) */
$$HINT2 /*+ USE_HASH(PA_PROJECTS_ALL PA_PROJECT_TYPES_ALL

PA_TASKS) */
$$HINT3 /*+ USE_HASH(PE PEV PPS) */
SIL_PRODUCTTRANSACTIONFACT Initial /*+ USE_HASH(SRC_PRO_D TO_PRO_D) */
SIL_PURCHASECOSTFACT Initial /*+ USE_HASH(W_PROJECT_D) */
SIL_APINVOICEDISTRIBUTIONFACT Incr. Apply hint to Lkp_W_AP_INV_DIST_F query:
/*+ INDEX(TARGET_TABLE) */
EBS Human Resources
R12 SDE_ORA_PayrollFact_Full Initial $$HINT1:

/*+ USE_HASH( PAY_RUN_RESULT_VALUES PAY_RUN_RESULTS
PAY_INPUT_VALUES_F
PAY_ASSIGNMENT_ACTIONS PAY_ELEMENT_TYPES_F
PAY_PAYROLL_ACTIONS
PAY_ELEMENT_CLASSIFICATIONS PER_TIME_PERIODS ) */
$$HINT2:
/*+ ORDERED USE_HASH( PAY_RUN_RESULT_VALUES PAY_RUN_RESULTS
PAY_INPUT_VALUES_F PAY_ASSIGNMENT_ACTIONS
PAY_ELEMENT_TYPES_F
PAY_PAYROLL_ACTIONS PAY_ELEMENT_CLASSIFICATIONS
PER_TIME_PERIODS ) */
$$HINT3:
/*+ FULL(PER_ALL_ASSIGNMENTS_F) FULL(PER_ALL_PEOPLE_F) */
SDE_ORA_PayrollFact_Agg_Items_Der Initial /*+ parallel(W_PAYROLL_FS,4)*/
ive_Full
PLP_RECRUITMENTHIREAGGREGAT Incr. $$HINT1:
E_LOAD /*+ USE_HASH (FACT MONTH PERF LOC SOURCE AGE EMP)*/
PLP_WorkforceEventFact_Month Initial /*+ FULL(suph) */
EBS Financials
R12 SDE_ORA_APTransactionFact_Liability Incr. /*+ parallel(AP_INVOICE_DISTRIBUTIONS_ALL,4) use_hash(AP_INVOICES_ALL

Distribution AP_INVOICE_DISTRIBUTIONS_ALL PO_HEADERS_ALL
PO_DISTRIBUTIONS_ALL PO_LINES_ALL)*/
SDE_ORA_Stage_GLJournals_Derive Incr. /*+ PARALLEL (W_ORA_GL_JOURNALS_F_TMP, 4) */
SDE_ORA_CustomerFinancialProfileDi Initial / /*+ USE_HASH (HZ_PARTIES)*/
mension Incr.
SDE_ORA_ARTransactionFact_Credit Incr. /*+ USE_HASH(AR_PAYMENT_SCHEDULES_ALL RA_CUSTOMER_TRX_ALL
MemoApplication RA_CUSTOMER_TRX_ALL1 AR_PAYMENT_SCHEDULES_ALL1
AR_DISTRIBUTIONS_ALL) */
PLP_APIncrActivityLoad Incr. /*+ index(W_AP_XACT_F, W_AP_XACT_F_M1) */
PLP_APXactsGroupAccount_A_Stage_ Initial /*+ full(W_GL_ACCOUNT_D) full(W_STATUS_D) full(W_AP_XACT_F)
Full full(W_XACT_TYPE_D) full(D1) full(D2) full( D3)*/
EBS Projects
R12 SDE_ORA_ProjectFundingHeader Initial / /*+ USE_HASH(PA_PROJECTS_ALL PA_TASKS PA_AGREEMENTS_ALL
42
Incr. PA_SUMMARY_PROJECT_FUNDINGS) */
SDE_ORA_ProjectInvoiceLine_Fact Initial /*+ USE_HASH(pa_draft_invoice_items pa_tasks pa_draft_invoices_all
pa_projects_all pa_agreements_all pa_lookups) */
SDE_ORA_ProjectCostLine_Fact Initial /*+ USE_HASH(pa_cost_distribution_lines_all pa_expenditure_items_all
pa_expenditures_all pa_implementations_all pa_implementations_all_1
gl_sets_of_books pa_project_assignments pa_resource_list_members pa_lookups
pa_projects_all pa_project_types_all pa_expenditure_types) */
SIL_ProjectFundingHeader_Fact Incr. /*+ INDEX(LOOKUP_TABLE W_PARTY_D_M3) */
EBS Order Management (Enterprise Sales)
11.5.10 SIL_SalesPickLinesFact_Full Initial /*+ FULL(A18) FULL(A19) FULL(A20) FULL(A21) FULL(A22) */

SIL_SalesOrderLinesFact_Full Initial /*+ FULL(A18) FULL(A19) FULL(A20) FULL(A21) FULL(A22) */
SIL_SalesInvoiceLinesFact_Full Initial /*+ FULL(A18) FULL(A19) FULL(A20) FULL(A21) FULL(A22) */
SIL_SalesScheduleLinesFact_Full Initial /*+ FULL(A18) FULL(A19) FULL(A20) FULL(A21) FULL(A22) */
EBS Service
11.5.10 SDE_ORA_EntitlementDimension Initial /*+ parallel(OKC_K_LINES_TL,4) parallel (OKC_K_LINES_B,4) */

SDE_ORA_AgreeDimension Initial /*+ NO_MERGE(fndv) */
SDE_ORA_AbsenceEvent Initial /*+ use_hash(per_absence_attendances per_all_assignments_f
per_absence_attendance_types per_abs_attendance_reasons ) */
SIL_ActivityFact_Full Initial /*+ use_hash(W_ACTIVITY_FS W_FS_ACT_CST_FS W_SOURCE_D
W_ENTLMNT_D W_AGREE_D W_REGION_D W_SRVREQ_D W_ASSET_D) */
You may consider using the recommended hints for the mappings above for other versions only after careful testing
and benchmarking ETL runtime and performance.
These hints are not included into the packaged mappings. Each mapping may have $$HINT placeholders, defined in
DAC. You can consider applying them to your environments after verifying mappings execution with the hints in your
test environment.
You can manually define $$HINT variables in your DAC and Informatica repositories by following the steps below:
- Connect to Informatica PowerCenter 8.6 Designer
- Check out the selected mapping and drag it to Mapplet Designer palette
- Navigate to Mapplets menu -> Parameters and Variables
- Click on the Add New Variable icon
- Fill in the following fields in a new line:
o Name: $$HINT1, 2, etc.
o Type: Parameter
o Datatype: String
o Precision: make sure you specify the sufficient precision to cover your hint value
o Click OK
o Save the changes and check in the mapping into the Informatica repository
- Connect to Informatica PowerCenter 8.6 Workflow Manager
- Check out the corresponding session and drag it to Task Developer palette
- Open the session
43
- Click on Mapping tab and select SQ (SQL Qualifier) under Sources folder in the left pane
- Click on Select Query attribute value
- Insert the defined $$HINT? Variable
- Save the changes
- Connect to DAC client
- Select the custom container
- Click on Design button and select Tasks menu in the right pane
- Retrieve the task which corresponds to the selected Informatica mapping
- Click on Parameters menu in the lower pane
- Fill in the fields in a new line:
o Name: use the exact variable name defined in Informatica above
o Data Type: Text
o Load Type: select the load type from the list of values
o Value: enter the hint value here
o Save the changes
- Verify the changes by inspecting the session log for the select mapping during the next ETL.
Important: DAC 10.1.3.4.1 invokes Informatica PowerCenter 8.6 command line API with <–lpf> option. Some
of the recommended hints can be very long and not fit into a single line. As a result, Informatica may not pick
the valid parameter values. If your DAC and Informatica servers share the same machine, you can resolve the
issue by implementing the following steps:
- Connect to your machine, running DAC and Informatica servers
- Open <DAC_HOME>\Conf\infa_command.xml
- Replace each occurrence of <-lpf> with <-paramfile> in the configuration file
- Save the changes
- Restart DAC server and test the solution.
Using Oracle Optimizer Dynamic Sampling for big staging tables

A typical Source Dependent Extract (SDE) task contains the following steps:
- Truncate staging table
- Extract data from one or more OLTP tables into staging table
- Analyze staging table
The last step computes statistics on the table to make sure that Oracle Cost Based Optimizer (CBO) builds the best
execution plan for the next task. However, during the initial loads that process very large data volumes, the staging
table may become so large (hundreds of millions of rows), that the Analyze Table job would take many hours to
complete. Oracle RDBMS offers a faster, yet accurate enough alternative to use dynamic sampling instead of gathering
table statistics. The purpose of dynamic sampling is to improve server performance by determining more accurate
estimates for predicate selectivity and statistics for tables and indexes. Oracle CBO determines whether a query would
benefit from dynamic sampling at the query compile time. Oracle Optimizer would issue a recursive SQL statement to
44
scan a small random sample of the table's blocks, and to apply the relevant single table predicates to estimate
selectivity for each predicate. In some cases sample cardinality can also be used to estimate table cardinality.
The internal tests, performed on large staging tables, show that optimizer can produce efficient execution plans by
utilizing dynamic sampling feature at much shorter time compared to gathering table stats using conventional methods.
Below are the details of one of the internal benchmark tests:
- Hardware configuration: 8 CPU cores x 16Gb RAM x 2Tb NAS server with Linux 64bit OS
- Target Database: Oracle 10.2.0.3 64bit
- Test configuration: query involves a large staging table with over 100 Million rows, joined with two smaller
dimension tables
Test Scenarios Statistics / Sampling Execution Time Query Execution Time
No statistics were collected on the staging table. Dynamic sampling: 10.6 sec 2 hours 27 min 45 sec
Computed statistics on the staging table using Statistics computing: 53 min 26 sec 2 hours 20 min 43 sec
DBMS_STATS package.
The overall run time for the second case was approximately 45 minutes longer compared to the dynamic sampling
scenario. The optimizer estimated the identical run time for both cases execution plans.
Enabling Dynamic Sampling at the system level may cause additional performance overhead, so it should be
selectively applied only to the mappings, which run the queries against the large staging table by inserting Dynamic
Sampling hints into the appropriate mapping SQLs. Refer to the publication Oracle Database Performance Tuning
Guide (10g Release 2) for more details.
Note that the DAC version released with Oracle Business Intelligence Applications Version 7.9.6 does not disable
computing statistics at a table level. To workaround this limitation, you can abort the execution plan in DAC, mark the
task Analyze Table for your staging table as Completed and restart the Execution Plan.
CUSTOM INDEXES IN ORACLE EBS FOR INCREMENTAL LOADS PERFORMANCE

Introduction
Oracle EBS source database tables contain mandatory LAST_UPDATE_DATE columns, which are used by Oracle BI
Applications for capturing incremental data changes. Some source tables used by Oracle BI Applications do not have
an index on LAST_UPDATE_DATE column, which hampers performance of incremental loads. There are three
categories of such source EBS tables:
- Tables that do not have indexes on LAST_UPDATE_DATE in the latest EBS releases, but there are no
performance implications reported with indexes on LAST_UPDATE_DATE column.
- Tables that have indexes on LAST_UPDATE_DATE columns, introduced in Oracle EBS Release 12.
- Tables that cannot have indexes on LAST_UPDATE_DATE because of serious performance degradations in
the source EBS environments.
Custom OBIEE indexes in EBS 11i and R12 systems

The first category covers tables, which do not have indexes on LAST_UPDATE_DATE in any EBS releases. The
creation of custom indexes on LAST_UPDATE_DATE columns for tables in this category has been reviewed and
45
approved by Oracle’s EBS Performance Group. All Oracle EBS 11i and R12 customers should create the custom
indexes using the DDL script provided below.
If your source system is on of the following:
- EBS R12
- EBS 11i release 11.5.10
- EBS 11i release 11.5.9 or lower and it has been migrated to OATM*
then replace <IDX_TABLESPACE> with APPS_TS_TX_IDX prior to running the DDL.
If your source system is EBS 11i release 11.5.9 or lower and it has not been migrated to OATM*, replace
<IDX_TABLESPACE> with <PROD>X, where <PROD> is an owner of the table which will be indexed on
LAST_UPDATE_DATE column.
DDL script for custom index creation:
CREATE index AP.OBIEE_AP_EXP_REP_HEADERS_ALL ON

AP.AP_EXPENSE_REPORT_HEADERS_ALL(LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE> ;
CREATE index AP.OBIEE_AP_INVOICE_PAYMENTS_ALL ON AP.AP_INVOICE_PAYMENTS_ALL(LAST_UPDATE_DATE)

tablespace <IDX_TABLESPACE> ;
CREATE index AP.OBIEE_AP_PAYMENT_SCHEDULES_ALL ON AP.AP_PAYMENT_SCHEDULES_ALL(LAST_UPDATE_DATE)

CREATE index AP.OBIEE_AP_INVOICES_ALL ON AP.AP_INVOICES_ALL(LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index AP.OBIEE_AP_HOLDS_ALL ON AP.HOLDS_ALL(LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>

;
CREATE index AP.OBIEE_AP_AE_HEADERS_ALL ON AP.AP_AE_HEADERS_ALL(LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index CST.OBIEE_CST_COST_TYPES ON CST.CST_COST_TYPES(LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index GL.OBIEE_GL_JE_HEADERS ON GL.GL_JE_HEADERS(LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index AR.OBIEE_HZ_ORGANIZATION_PROFILES ON AR.HZ_ORGANIZATION_PROFILES(LAST_UPDATE_DATE)

CREATE index AR.OBIEE_HZ_CONTACT_POINTS ON AR.HZ_CONTACT_POINTS(LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index AR.OBIEE_HZ_CUST_SITE_USES_ALL ON AR.HZ_CUST_SITE_USES_ALL(LAST_UPDATE_DATE)

CREATE index AR.OBIEE_HZ_LOCATIONS ON AR.HZ_LOCATIONS(LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index AR.OBIEE_HZ_RELATIONSHIPS ON AR.HZ_RELATIONSHIPS(LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index AR.OBIEE_HZ_CUST_ACCT_SITES_ALL ON AR. HZ_CUST_ACCT_SITES_ALL(LAST_UPDATE_DATE)

CREATE index AR.OBIEE_HZ_CUST_ACCOUNT_ROLES ON AR.HZ_CUST_ACCOUNT_ROLES(LAST_UPDATE_DATE)

CREATE index AR.OBIEE_HZ_PARTY_SITES ON AR.HZ_PARTY_SITES(LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index AR.OBIEE_HZ_PERSON_PROFILES ON AR.HZ_PERSON_PROFILES(LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
46
CREATE index ONT.OBIEE_OE_ORDER_HEADERS_ALL ON ONT.OE_ORDER_HEADERS_ALL(LAST_UPDATE_DATE)
CREATE index ONT.OBIEE_OE_ORDER_HOLDS_ALL ON ONT.OE_ORDER_HOLDS_ALL(LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index PER.OBIEE_PAY_INPUT_VALUES_F ON PER.PAY_INPUT_VALUES_F (LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index PER.OBIEE_PAY_ELEMENT_TYPES_F ON PER.PAY_ELEMENT_TYPES_F (LAST_UPDATE_DATE)

CREATE index PO.OBIEE_RCV_SHIPMENT_LINES ON PO.RCV_SHIPMENT_LINES (LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
CREATE index PO.OBIEE_RCV_SHIPMENT_HEADERS ON PO.RCV_SHIPMENT_HEADERS (LAST_UPDATE_DATE)

CREATE index AR.OBIEE_AR_CASH_RECEIPTS_ALL ON AR.AR_CASH_RECEIPTS_ALL (LAST_UPDATE_DATE)

CREATE index WSH.OBIEE_WSH_DELIVERY_DETAILS ON WSH.WSH_DELIVERY_DETAILS (LAST_UPDATE_DATE)

CREATE index WSH.OBIEE_WSH_NEW_DELIVERIES ON WSH.WSH_NEW_DELIVERIES (LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
Important: Make sure you use FND_STATS to compute statistics on the newly created indexes and update
statistics on newly indexed table columns in the EBS database.
Important: Since all indexes in this section have the prefix OBIEE_ and do not follow standard Oracle EBS
Index naming conventions, Autopatch might fail during future upgrades if Oracle EBS introduces indexes on
LAST_UPDATE_DATE columns for these tables. In such cases conflicting OBIEE_ indexes should be dropped
and Autopatch restarted.
Custom EBS indexes in EBS 11i source systems

The second category covers tables, which have indexes on LAST_UPDATE_DATE, officially introduced Oracle EBS
Release 12. All Oracle EBS 11i and R12 customers should create the custom indexes using the DDL script provided
below. Make sure you don't change the index name to avoid any future patch or upgrade failures on the source EBS
side.
If your source system is one of the following:
- EBS R12
- EBS 11i release 11.5.10
- EBS 11i release 11.5.9 or lower and it has been migrated to OATM*
then replace <IDX_TABLESPACE> with APPS_TS_TX_IDX prior to running the DDL.
If you source system is EBS 11i release 11.5.9 or lower and it has not been migrated to OATM*, replace
<IDX_TABLESPACE> with <PROD>X, where <PROD> is an owner of the table which will be indexed on
LAST_UPDATE_DATE column.
DDL script for custom index creation:

CREATE index PO.RCV_TRANSACTIONS_N23
ON PO.RCV_TRANSACTIONS (LAST_UPDATE_DATE)
INITIAL 4K NEXT 2M MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 2 MAXTRANS 255
PCTFREE 10 tablespace <IDX_TABLESPACE> ;
CREATE index PO.PO_DISTRIBUTIONS_N13
ON PO.PO_DISTRIBUTIONS_ALL (LAST_UPDATE_DATE)
47
CREATE index PO.PO_LINE_LOCATIONS_N11
ON PO.PO_LINE_LOCATIONS_ALL (LAST_UPDATE_DATE)
CREATE index PO.PO_LINES_N10
ON PO.PO_LINES_ALL (LAST_UPDATE_DATE)
INITIAL 4K NEXT 4K MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 2 MAXTRANS 255
CREATE index PO.PO_REQ_DISTRIBUTIONS_N6
ON PO.PO_REQ_DISTRIBUTIONS_ALL (LAST_UPDATE_DATE)
CREATE index PO.PO_REQUISITION_LINES_N17
ON PO.PO_REQUISITION_LINES_ALL (LAST_UPDATE_DATE)
CREATE index PO.PO_HEADERS_N9

ON PO.PO_HEADERS_ALL (LAST_UPDATE_DATE)
CREATE index PO.PO_REQUISITION_HEADERS_N6
ON PO.PO_REQUISITION_HEADERS_ALL (LAST_UPDATE_DATE)
CREATE index AR.RA_CUSTOMER_TRX_N14
ON AR.RA_CUSTOMER_TRX_ALL (LAST_UPDATE_DATE)
Important: Make sure you use FND_STATS to compute statistics on the newly created indexes and update
statistics on newly indexed table columns in the EBS database.
Since all custom indexes above follow Oracle EBS index standard naming conventions, any future upgrades would not
be affected.
*) Oracle Applications Tablespace Model (OATM):
Oracle EBS release 11.5.9 and lower uses two tablespaces for each Oracle Applications product, one for the
tables and one for the indexes. The old tablespace model standard naming convention for tablespaces is a
product's Oracle schema name with the suffixes D for Data tablespaces and X for Index tablespaces. For
example, the default tablespaces for Oracle Payables tables and indexes are APD and APX, respectively.
Oracle EBS 11.5.10 and R12 use the new Oracle Applications Tablespace Model. OATM uses 12 locally
managed tablespaces across all products. Indexes on transaction tables are held in a separate tablespace
APPS_TS_TX_IDX, designated for transaction table indexes.
Customers running pre-11.5.10 releases can migrate to OATM using OATM Migration utility. Refer to Oracle
Metalink Note 248857.1 for more details.
Oracle EBS tables with high transactional load

The following Oracle EBS tables are used for high volume transactional data processing, so introduction of indexes on
LAST_UPDATE_DATE may cause additional overhead for some OLTP operations. The majority of the customers will
not have any significant impact on OLTP Applications performance. Oracle BI Applications customers may consider
creating custom indexes on LAST_UPDATE_DATE for these tables only after benchmarking incremental ETL
performance and analyzing OLTP applications impact.
To analyze the impact on EBS source database, you can generate an Automatic Workload Repository (AWR) report
during the execution of OLTP batch programs, producing heavy inserts / updates into the tables below, and review
48
Segment Statistics section for resource contentions caused by custom LAST_UPDATE_DATE indexes. Refer to
Oracle RDBMS documentation for more details on AWR usage.
Make sure you use the following pattern for creating custom indexes on the listed tables below:
CREATE index <Ppod>.OBIEE_<Table_Name> ON <Prod>.<Table_Name> (LAST_UPDATE_DATE) tablespace

<IDX_TABLESPACE> ;
Prod Table Name
AP AP_EXPENSE_REPORT_LINES_ALL
AP AP_INVOICE_DISTRIBUTIONS_ALL
AP AP_AE_LINES_ALL
AP AP_PAYMENT_HIST_DISTS
AR AR_PAYMENT_SCHEDULES_ALL
AR AR_RECEIVABLE_APPLICATIONS_ALL
AR RA_CUST_TRX_LINE_GL_DIST_ALL
AR RA_CUSTOMER_TRX_LINES_ALL
BOM BOM_COMPONENTS_B
BOM BOM_STRUCTURES_B
CST CST_ITEM_COSTS
GL GL_BALANCES
GL GL_DAILY_RATES
GL GL_JE_LINES
INV MTL_MATERIAL_TRANSACTIONS
INV MTL_SYSTEM_ITEMS_B
ONT OE_ORDER_LINES_ALL
PER PAY_PAYROLL_ACTIONS
PO RCV_SHIPMENT_LINES
WSH WSH_DELIVERY_ASSIGNMENTS
WSH WSH_DELIVERY_DETAILS
Custom EBS indexes on CREATION_DATE in EBS 11i source systems

Oracle EBS source database tables contain another mandatory column CREATION_DATE, which can be used by
Oracle BI Applications for capturing initial data subsets. You may consider creating custom indexes on
CREATION_DATE if your initial ETL extracts a subset of historic data. You can use the same guidelines for creating
49
custom indexes on CREATION_DATE columns for improving initial ETL performance after careful benchmarking of
EBS source environment performance.
WIDE TABLES WITH OVER 255 COLUMNS PERFORMANCE
Introduction
Oracle Database supports relational tables with up to 1000 columns. Though there aren’t any differences in logical wide
table structure, the Oracle will split wide table rows into 255 row-pieces for tables, exceeding 255 columns limit. Even if
there is enough free space in a single block, Oracle will allocate another block for the next row-piece. As the result,
Oracle would have to generate recursive calls to dynamically allocate space for the chained rows during their read/write
time.
Oracle BI Applications physical data model contains several wide dimension tables, such as W_ORG_D,
W_SOURCE_D, W_PERSON_D, which could have over 255 columns after end user customizations. The table below
shows the comparison statistics for a sample W_ORG_D with 254 and 300 columns:
W_ORG_D with 300 columns W_ORG_D with 254 columns

Time: 186 sec Time: 54 sec
Statistics Statistics
---------------------------------------------------------- ----------------------------------------------------------
657 recursive calls 0 recursive calls
0 db block gets 0 db block gets
134975 consistent gets 134888 consistent gets
134867 physical reads 134864 physical reads
0 redo size 0 redo size
382 bytes sent via SQL*Net to client 382 bytes sent via SQL*Net to client
372 bytes received via SQL*Net from client 372 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client 2 SQL*Net roundtrips to/from client
6 sorts (memory) 0 sorts (memory)
0 sorts (disk) 0 sorts (disk)
1 rows processed 1 rows processed
Depending on the queries complexity the amount of physical reads also could be much higher for wide tables with
more than 255 columns. The described limitation would have critical impact on Oracle BI Applications Dashboards
performance.
Wide tables structure optimization

Since the wide dimension tables were designed to consolidate attributes from multiple source databases, there are
very few customers’ implementations, which would use all pre-defined attributes. Since the unused columns will store
NULLs, consider rebuilding wide tables with over 255 columns and moving the columns with NULLs to the end. Oracle
does not allocate space to NULL columns at the end of the table, so it would not create chained row-pieces.
Important: Optimized wide tables must be created from scratch, since the existing tables already have the
chained rows. So, any ‘ALTER TABLE’ command would not resolve the chaining problem.
After rebuilding a wide table make sure all ETL and Query indexes get created as well.
50
ORACLE BI APPLICATIONS HIGH AVAILABILITY
Introduction
Both initial and incremental data loads into Oracle BI Applications Data Warehouse must be executed during
scheduled maintenance or blackout windows for the following reasons:
- End user data could be inconsistent during ETL runs, causing invalid or incomplete results on dashboards
- ETL runs may result in significant hardware resource consumption, slowing down end user queries
The time to execute periodic incremental loads depends on a number of factors, such as number of source databases,
each source database incremental volume, hardware specifications, environment configuration, etc. As the result,
incremental loads may not always complete within a predefined blackout window and cause extended downtime.
Global businesses, operating 24 hours around o’clock not always could afford few hours downtime. Such customers
can consider implementing high availability solution using Oracle Data Guard with a physical Standby database.
High Availability with Oracle Data Guard and Physical Standby Database
Oracle Data Guard configuration contains a primary database and supports up to nine standby databases. A standby
database is a copy of a production database, created from its backup. There are two types of standby databases,
physical and logical.
A physical standby database must be physically identical to its primary database on a block-for-block basis. Data
Guard synchronizes a physical standby database with its primary one by applying the primary database redo logs. The
standby database must be kept in recovery mode for Redo Apply. The standby database can be opened in read-only
mode in-between redo synchronizations.
The advantage of a physical standby database is that Data Guard applies the changes very fast using low-level
mechanisms and bypassing SQL layers.
A logical standby database is created as a copy of a primary database, but it later can be altered to a different
structure. Data Guard synchronizes a logical standby database by transforming the data from the primary database
redo logs into SQLs and executing them in the standby database.
A logical standby database has to be open all the times to allow Data Guard to perform SQL updates.
Important: A primary database must run in ARCHIVELOG mode all the times.
Data Guard with Physical Standby Database option provides both efficient and comprehensive disaster recovery as
well as reliable high availability solution to Oracle BI Applications customers. Redo Apply for Physical Standby option
synchronizes a Standby Database much faster compared to SQL Apply for Logical Standby. OBIEE does not require
write access to BI Applications Data Warehouse for either executing end user logical SQL queries or developing
additional contents in RPD or Web Catalog.
The internal benchmarks on a low-range outdated hardware have showed four times faster Redo Apply on a physical
standby database compared to ETL execution on a primary database:
Step Name Row Count Redo Size ETL SQL time Redo Apply
on Primary DB time
SDE_ORA_SalesProductDimension_Full 2621803 621 Mb 01:59:31 00:10:20
SDE_ORA_CustomerLocationDimension_Full 4221350 911 Mb 04:11:07 00:16:35
SDE_ORA_SalesOrderLinesFact_Full 22611530 12791 Mb 09:17:19 03:16:04
W_SALES_ORDER_LINE_F_U1 Index 610 Mb 00:24:31 00:08:23
51
Creation
Total 29454683 14933 Mb 15:52:28 03:51:22
The target hardware was configured intentionally on a low-range Sun server, with both Primary and Standby databases
deployed on the same server, to imitate heavy incremental load. The modern production systems with primary and
standby database, deployed on separate servers, are expected to deliver up to 8-10 times better Redo Apply time on a
physical standby database, compared to the ETL execution time on the primary database.
The diagram below describes Data Guard configuration with Physical Standby database:
- The primary instance runs in “FORCE LOGGING” mode and serves as a target database for routine
incremental ETL or any maintenance activities such as patching or upgrade.
- The Physical Standby instance runs in read-only mode during ETL execution on the Primary database.
- When the incremental ETL load into the Primary database is over, DBA schedules the downtime or blackout
window on the Standby database for applying redo logs.
- DBA shuts down OBIEE tier and switches the Physical Standby database into ‘RECOVERY’ mode.
- DBA starts Redo Apply in Data Guard to apply the generated redo logs to the Physical Standby Database.
- DBA opens Physical Standby Database in read-only mode and starts OBIEE tier:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN;
52
Easy-to-manage switchover and failover capabilities in Oracle Data Guard allow quick role reversals between primary
and standby, so customers can consider switching OBIEE from the Standby to Primary, and then start applying redo
logs to the Standby instance. In such configuration the downtime can be minimized to two short switchovers:
- Switch OBIEE from Standby to Primary after ETL completion into Primary database, and before starting Redo
Apply into Standby database.
- Switch OBIEE from Primary to Standby before starting another ETL.
Additional considerations for deploying Oracle Data Guard with Physical Standby for Oracle BI Applications:
1. ‘FORCE LOGGING’ mode would increase the incremental load time into a Primary database, since Oracle
would logging index rebuild DDL queries.
2. Primary database has to be running in ARCHIVELOG mode to capture all REDO changes.
3. Such deployment results in more complex configuration; it also requires additional hardware to keep two large
volume databases and store daily archived logs.
However it offers these benefits:
1. High Availability Solution to Oracle BI Applications Data Warehouse
2. Disaster recovery and complete data protection
3. Reliable backup solution
ORACLE BI APPLICATIONS ETL PERFORMANCE BENCHMARKS

The execution time for each ETL run depends on such factors as hardware specifications, source data volumes,
various tiers configurations, DB tiers loads, and so on.
Important!!! The following numbers apply only to the specific hardware configurations and source data sets. They are
provided for reference purposes within the context of each specific configuration.
Oracle BI Applications 7.9.6.1, Siebel CRM 8.0 Adapter

Environment configuration:
Tier Model CPU RAM Storage OS Software
Source IBM 9117-570 8 x 1.9 GHz 64Gb 1.5Tb iSCSI IBM AIX 5.3 Siebel CRM 8.0 / Oracle 10.2.0.4 64-bit
Target IBM 9117-570 8 x 1.9 GHz 64Gb 1.5Tb iSCSI IBM AIX 5.3 Oracle 11.1.0.7 64-bit
ETL IBM 9115-505 4 x 1.6 GHz 8Gb 500Gb Local HDD IBM AIX 5.3 Informatica 8.6 SP4 / OBIEE 10.1.3.4
ETL Load type: Full Load of two years of historic data.
ETL run time: 11 hours 26 min
The following table contains the execution details for the longest mappings in the full ETL run:
Read Write
Success
Session Name Run Time Throughput, Throughput,
Rows
rows / sec rows / sec
SDE_PartyPersonDimension 2:01:37 21294734 3943 4480
SIL_ResponseFact_Full 1:57:28 32245373 4594 5746
53
SIL_PartyPersonDimension_Full 1:21:29 21294735 4657 4696
SDE_ResponseFact 0:54:44 32245373 10334 11959
SIL_PartyPersonDimension_UpdateCampaignOfferInfo 0:53:20 4109910 1416 1397
SIL_ActivityFact_Full 0:52:16 10505208 3395 4426
SDE_ResponseDimension 0:48:25 32271503 11753 12509
SIL_ResponseDimension_Full 0:46:11 32271504 11909 12318
SDE_ActivityFact 0:45:03 10505208 3948 4728
SIL_PartyDimension_Person 0:44:28 21294734 8100 9877
SIL_RevenueFact_Full 0:42:20 5626059 2251 2923
SIL_PersonFact_Full 0:42:12 9151737 3671 6740
SIL_CampaignHistoryFact_Full 0:37:45 10490109 4711 5867
Oracle BI Applications 7.9.6.1, Oracle EBS R12 Projects Adapter

Sun 16 x 900Mhz UltraSparc 16Tb NetApp Network Sun Solaris Oracle EBS R12 / Oracle
Source 32Gb
E6500 II CPUs Attached Storage (NAS) 9 10.2.0.3 64-bit
Dell 2 x quad-core 3.6 Ghz Windows

Target 16Gb 2Tb Netapp NAS Storage Oracle 11.1.0.7 64-bit
PE6850 Intel Xeon CPUs 2003
Dell 2 x dual-core 3.4 Ghz Windows Informatica 8.6 SP4 /

ETL 4Gb 200Gb Local HDD
PE2850 Intel Xeon CPUs 2003 OBIEE 10.1.3.4
ETL Load type: Full Load of seven years of historic data.
The following table contains the execution details for the longest Projects mappings in the full ETL run:
Read Write
Run Success
Session Name Throughput, Throughput,
Time Rows
SIL_ProjectCostLine_Fact 24:31:59 128723375 1459 1496
SIL_ProjectExpLine_Fact 14:21:31 117891397 2283 2363
SIL_ProjectRevenueLine_Fact 11:51:12 68597993 1609 1685
SDE_ORA_ProjectRevenueLine 8:16:54 68648978 2339 2884
SDE_ORA_ProjectCostLine 7:40:36 129439913 4690 7102
SDE_ORA_ProjectExpLine 4:38:22 117918424 7074 7161
SIL_ProjectTaskDimension 1:08:45 7187362 1757 1783
SIL_ProjectRevenueHdr_Fact_Full 0:56:05 1740225 523 1697
SDE_ORA_ProjectInvoiceLine_Fact 0:54:16 3076049 955 957
SDE_ORA_Project_Tasks 0:38:44 7187362 3142 7704
Oracle BI Applications 7.9.6.1, Oracle EBS 11i10 Enterprise Sales Adapter

54
Source 20Gb
Oracle 11.1.0.7 64-bit /

Target Dell 2 x quad-core 1.86 Ghz Linux
16Gb 1Tb Netapp NAS Storage Informatica 8.6 SP4 /
& ETL PE2950 Intel Xeon CPUs RedHat 3.4
OBIEE 10.1.3.4
The following table contains the execution details for the longest Sales mappings in the full ETL run:
Read Write
Run Success
Time Rows
SIL_SalesInvoiceLinesFact_Full 9:50:02 61076675 1729 3357
SIL_SalesOrderLinesFact_Full 8:45:51 44797448 1423 2194
SIL_SalesScheduleLinesFact_Full 8:45:08 44912891 1428 2204
SDE_ORA_SalesInvoiceLinesFact_Full 7:44:06 61076675 2194 2494
SDE_ORA_SalesOrderLinesFact_Full 5:52:47 44797448 2130 2482
PLP_SalesCycleLinesFact_Load_Full 4:17:19 44797448 2910 5363
SDE_ORA_SalesScheduleLinesFact_Full 4:04:34 44912891 3071 3397
SIL_SalesBookingLinesFact_Load_OrderLine_Debt 3:08:54 44797448 3967 3968
PLP_SalesOrderLinesFact_RollupAmt_Update_Full 2:48:34 4377020 521 471
SDE_ORA_SalesPickLinesFact_Full 2:43:05 6101903 627 783
SIL_SalesPickLinesFact_Full 1:42:34 6101903 997 1494
PLP_SalesOrderLinesAggregate_Load_Full 2:11:12 7128617 911 5690
PLP_SalesInvoiceLinesAggregate_Load_Full 1:40:52 2519900 419 8630
SDE_ORA_SalesProductDimension_Full 1:06:16 2620885 664 665
SDE_ORA_SalesCycleLinesFact_HoldDurationExtract 0:48:23 2246234 978 74875
SIL_SalesProductDimension_Full 0:22:17 2620886 2186 2170
Oracle BI Applications 7.9.6.1, Oracle EBS 11i10 Supply Chain Adapter

Source 20Gb
Oracle 11.1.0.7 64-bit /

Target Dell 2 x quad-core 1.86 Ghz Linux
16Gb 1Tb Netapp NAS Storage Informatica 8.6 SP4 /
& ETL PE2950 Intel Xeon CPUs RedHat 3.4
OBIEE 10.1.3.4
The following table contains the execution details for the longest Supply Chain mappings in the full ETL run:
Read Write
Run Success
Time Rows
SIL_APInvoiceDistributionFact_Full 9:40:13 82351451 2371 2464
55
SDE_ORA_APInvoiceDistributionFact_Full 7:55:10 82351451 2894 4063
SDE_ORA_EmployeeExpenseFact_Full 5:17:33 40789178 2145 2394
SIL_ExpenseFact_Full 5:12:05 40789180 2189 2500
SIL_ProductTransactionFact_Full 4:37:47 19955307 1202 1985
SDE_ORA_ProductTransactionFact_Full 4:20:57 19955307 1280 3531
SDE_ORA_PartyContactStaging_Full 3:06:30 27123133 2439 8032
SDE_ORA_PurchaseReceiptFact_Full 1:58:32 3147105 450 2565
SDE_ORA_CustomerLocationDimension_Full 1:32:53 4224659 761 915
SDE_ORA_InventoryProductDimension_Full 1:31:25 5241770 5553 6138
SIL_PurchaseCostFact_Full 1:17:32 2922581 632 806
SDE_ORA_CustomerFinancialProfileDimension_Full 1:09:07 4678902 1309 1775
SIL_PurchaseScheduleLinesFact_Full 0:59:24 2837469 803 941
SDE_ORA_PurchaseCostFact_Full 0:52:47 2922581 931 1400
SIL_PurchaseOrderFact_Full 0:52:18 2859692 923 1216
SDE_ORA_PurchaseRequisitionLinesFact_Full 0:37:10 2520984 1145 1970
SIL_RequisitionLinesCostFact_Full 0:31:15 2581337 1410 1980
SDE_ORA_PurchaseScheduleLinesFact_Full 0:30:13 2837469 1586 2395
SDE_ORA_RequisitionLinesCostFact_Full 0:26:31 2581337 1663 2934
SDE_ORA_PurchaseOrderFact_Full 0:26:14 2859692 1868 2449
SIL_InventoryProductDimension_Full 0:22:42 2620886 1976 2143
SIL_PurchaseRequisitionLinesFact_Full 0:19:19 2520984 2257 2697
SIL_CustomerFinancialProfileDimension_Full 0:18:52 2855450 2640 2684
SIL_PurchaseReceiptFact_Full 0:18:25 3147105 2953 3470
CONCLUSION
This document consolidates the best practices and recommendations for improving performance for Oracle Business
Intelligence Applications Version 7.9.6.This list of areas for performance improvements is not complete. If you observe
any performance issues with your Oracle BI Applications implementation, make sure you trace various components,
and carefully benchmark any recommendations or solutions discussed in this article or other sources, before
implementing the changes in the production environment.
56
Oracle Business Intelligence Applications Version 7.9.6 Performance Recommendations
January 2010
Contributors: Pavel Buynitsky, Eugene Perkov, Amar Batham, Nitin Aggarwal
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2010, Oracle. All rights reserved.

This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle
Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.
57

BI Apps796 Perf Tech Note V5

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BI Apps796 Perf Tech Note V5

Uploaded by

Copyright:

Available Formats

Oracle Business

HARDWARE RECOMMENDATIONS FOR IMPLEMENTING ORACLE BI APPLICATIONS

Source Data SMALL: MEDIUM: LARGE:

# CPU cores 8 16 32*

Physical RAM 16Gb 32Gb 64Gb*

Storage Space Up to 400Gb 400Gb - 2Tb 2Tb and higher

High performance SCSI or

Oracle BI Enterprise Edition / ETL Tier

# CPU cores 4-8 8 - 16 16**

Physical RAM 8Gb 8 - 16Gb 16Gb**

Storage Considerations for Oracle Business Analytics Warehouse

• Running multiple I/O intensive applications, such as databases, on a shared storage

• Choosing sub-optimal storage for running BI Applications tiers.

Shared Storage Impact Benchmarks

• Linux servers #1 and #2 have the following configurations:

• 2 quad-core 1.8 GHz Intel Xeon CPU

o Server #1 uses volume1

o Server #2 uses volume2

Execution test description:

• Run the following test scenarios:

- Initial Write: write a new file.

- Rewrite: re-write in an existing file.

- Read: read an existing file.

- Re-Read: re-read an existing file.

- Reverse Read: read a file backwards.

- Record Rewrite: write and re-write the same record in a file.

The test summary:

Test Type Test #1 Test #2

"Initial write " 46087.10 KB/sec 30039.90 KB/sec

"Rewrite " 70104.05 KB/sec 30106.25 KB/sec

"Read " 3134220.53 KB/sec 2078320.83 KB/sec

"Re-read " 3223637.78 KB/sec 3038416.45 KB/sec

"Reverse Read " 1754192.17 KB/sec 1765427.92 KB/sec

"Stride read " 1783300.46 KB/sec 1795288.49 KB/sec

"Random read " 1724525.63 KB/sec 1755344.27 KB/sec

"Mixed workload " 2704878.70 KB/sec 2456869.82 KB/sec

"Random write " 68053.60 KB/sec 25367.06 KB/sec

"Pwrite " 45778.21 KB/sec 23794.34 KB/sec

"Pread " 2837808.30 KB/sec 2578445.19 KB/sec

Total Time 110 min 216 min

Oracle BI Enterprise Edition (OBIEE) / ETL Tier

- Oracle Business Intelligence Server 10.1.3.4

- Informatica PowerCenter 8.6 Client

- Informatica PowerCenter 8.6 Server

- Data Warehouse Administration Console (DAC) client 10.1.3.4.1

- Data Warehouse Administration Console server 10.1.3.4.1

- Informatica BI Applications Repository (usually stored in a target database)

- DAC BI Applications Repository (usually stored in a target database)

Deployment considerations for the ETL components

ORACLE BUSINESS ANALYTICS WAREHOUSE CONFIGURATION

Database configuration parameters

- Oracle 9i customers should use Oracle 9.2.0.8.

- Oracle 10g customers should use Oracle 10.2.0.4 or higher.

- Oracle 11g customers should use Oracle 11.1.0.7 or higher.

- init9iR2.ora - init.ora template for Oracle RDBMS 9i

- init10gR2.ora - init.ora template for Oracle RDBMS 10g

- init11g.ora – init.ora template for Oracle RDBMS 11g

ETL impact on amount of generated REDO Logs

Below is a calculation of generated REDO amount in an internal initial ETL run:

redo log file sequence:

Data Loaded in warehouse:

Oracle RDBMS System Statistics

Oracle recommends two options to gather system statistics: