Doc1586374 A

An Oracle White Paper
September 2013

Best Practices for Gathering Statistics
with Oracle E-Business Suite

Best Practices for Gathering Statistics with Oracle E-Business Suite
Disclaimer
The following is intended to outline our general product direction. It is intended for information purposes
only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code,
or functionality, and should not be relied upon in making purchasing decisions. The development, release,
and timing of any features or functionality described for Oracles products remains at the sole discretion
of Oracle.
Executive Overview ......................................................................................... 1
Introduction ..................................................................................................... 1
FND_STATS Features .................................................................................... 2
History Mode ................................................................................................... 2
Gather Options ................................................................................................ 2
Histograms ...................................................................................................... 3
The AUTO Sampling Option ........................................................................... 4
Custom Scripts ................................................................................................ 4
When to Gather Statistics ............................................................................... 5
Cursor Invalidation .......................................................................................... 6
Locking Statistics ............................................................................................ 6
Database 11g Extended Statistics .................................................................. 7
Gathering Dictionary and Fixed Object Statistics ........................................... 8
Dictionary Statistics .................................................................................... 8
Fixed Statistics ............................................................................................ 8
Global Temporary Tables................................................................................ 9
Temporary Tables ......................................................................................... 10
Incremental Statistics for Partitioned Tables................................................. 10
Improving the Collection Time ...................................................................... 11
Verifying Statistics ......................................................................................... 11
Standalone Patches ...................................................................................... 12
Performance Test Cases & Examples .......................................................... 13
1. Oracle 11g Extended Optimizer Statistics ........................................ 13
2. Incremental Statistics Gathering ....................................................... 17
3. Concurrent Statistics Gathering ........................................................ 20
Appendix A: Related Documentation ............................................................ 21
Whitepapers .............................................................................................. 21
My Oracle Support Knowledge Documents ............................................. 21
Blogs ......................................................................................................... 21
Appendix B: Package Specifications ............................................................ 23
Gather Table Statistics ............................................................................. 23
Gather Schema Statistics ......................................................................... 25
Executive Overview
This paper documents the best practices for gathering statistics. It focuses on new features
implemented in the FND_STATS package that can be applied to Oracle E-Business Suite 11i (11.5.10
and later) and Release 12.
Introduction
The Best Practices for Gathering Optimizer Statistics white paper provides an extensive overview of
the Oracle database statistics gathering process and is a useful precursor to this paper. It describes
several methods for collecting or setting statistics, however, the only supported methods with Oracle
E-Business Suite are either the Gather Statistics concurrent program or the FND_STATS package
(which is called by the Gather Statistics concurrent program). FND_STATS is a wrapper around the
DBMS_STATS package and provides several PL/SQL procedures for gathering statistics at the table,
schema, or database level. The FND_STATS package also supports histograms, table exclusions and
the new database 11G features such as extended stats, incremental stats gathering for partitioned tables
and concurrent stats gathering. Neither the DBMS_STATS package nor the now obsolete ANALYZE
command recognize those features and may result in suboptimal execution plans.

1
FND_STATS Features
This section provides a high-level view of how the FND_STATS package interacts with DBMS_STATS. While either the
Oracle E-Business Suite or DBMS_STATS will gather statistics for objects with stale or empty (missing) statistics, the
FND_STATS package implements the following features in Oracle E-Business Suite:
Supports collection of statistics for individual schemas, or for the entire Oracle E-Business Suite. To process all E-
Business schemas, pass the schema name as 'ALL'. DBMS_STATS does not have this functionality.
Histograms on columns designated in FND_HISTOGRAM_COLS. This contains a list of histogram columns that
Oracle Development have identified as essential.
The new GATHER_AUTO option combines the collection of statistics for tables with either stale or missing (empty)
statistics.
FND_STATS supports rerun-ability feature. If the Gather Schema Statistics concurrent program is used, FND_STATS
maintains the history of each submission. If a run stopped or interrupted, the next submission will resume from the point
of failure or termination. Starting with the 10g version of the database, DBMS_STATS 'GATHER AUTO' option with
Table Monitoring feature can be used to serve the purpose of rerun-ability.
FND_STATS_HIST stores historical information about the amount of time it takes the statistics gathering package
FND_STATS to gather statistics.
History Mode
The Gather Table Statistics program can optionally backup the existing statistics prior to gathering new statistics. If the value
of backup flag parameter is BACKUP, FND_STATS exports the old statistics using
DBMS_STATS.EXPORT_TABLE_STATS prior to gathering new statistics and stores them in FND_STATTAB.
The history mode parameter controls the amount of history records that are created:
Last Run - History records are maintained only for the last gather statistics run. Each subsequent run will overwrite
the previous history record for the object. This is the default behavior.
Full - This mode does not overwrite previous historical information. History records are created for each new run and
are identified by the Request ID, which is generated automatically if one is not provided. If this mode is used, the
Purge FND_STATS History Records concurrent program should be run periodically to purge the FND_STATS_HIST
table.
None - This mode does not generate any history information and the run cannot be restarted.
If problems ensue post gathering statistics, you can use the RESTORE_SCHEMA_STATS or
RESTORE_TABLE_STATS procedure to restore statistics that were previously backed up in the FND_STATTAB table,
into the dictionary; statid can be provided to distinguish between different sets of statistics.
Gather Options
Use GATHER_AUTO option to gather stats incrementally. GATHER_AUTO relies on the Oracle Table Monitoring
feature to gather information about new or changed objects statistics.

2
In Oracle 9i, it was possible to specify individual tables, but this approach was deprecated in later releases and is now
automatically enabled for the entire schemas by default in Oracle 10g and Oracle 11g. To mimic this behavior in Oracle 9i,
use the following procedure:

exec FND_STATS.ENABLE_SCHEMA_MONITORING (ALL);
or to enable monitoring for a single schema:
exec FND_STATS.ENABLE_SCHEMA_MONITORING (SCHEMA_NAME);

When Gather Options parameter is set to "GATHER AUTO", fnd_stats will only gather statistics for tables that have
changed by more than the modification threshold % since the table was last analyzed (statistics gathered). The
modifications threshold can be adjusted by the user by passing a value for modpercent, which by default is equal to 10. So
the GATHER_AUTO will only gather stats on tables that show up in DBA_TAB_MODIFICATIONS with > 10%
changes.

FND_STATS.gather_schema_statistics (. . ..,options=>GATHER AUTO);
Histograms
A histogram is a special type of column statistic that provides additional information about the frequency and distribution
of values within a column. This information is used by the Optimizer when, for example, deciding to use an index or
perform a full-table scan, or deciding the join order. Without histograms the Optimizer assumes a uniform distribution of
rows across the distinct values in the column. These are created in Oracle E-Business Suite when a value in a column that is
referenced in a where clause has a disproportionate number of values that would usually make a full-table scan cheaper than
using the index - in other words when a column has non-unique repeating keys and only a few distinct values. This is
referred to as data skew. Histograms may also be used for some join predicates, which is beneficial with cardinality
estimates. Oracle 11g uses adaptive cursor sharing to ensure that the correct plan is used with bind peeking.
Collecting statistics for histograms adds time to the overall process. Histograms can be problematic and in Oracle 10g there
were concerns with bind peeking and how it affects cardinality estimates. The Optimizer would peek at the value of the
bind variables on the first hard parse of the SQL statement and then always use that plan for all future executions. The only
real solution for Oracle E-Business Suite was to disable bind peeking; dropping the histograms was not an option.
This has been improved in Oracle 11g with the introduction of Adaptive Cursor Sharing. Avoiding histograms will ensure
that SQL execution plans will not change depending on the bind value.
Those with custom development can use FND_STATS.CHECK_HISTOGRAM_COLS to determine the viability of
proposed histograms. This procedure checks if the leading columns in non-unique indexes have a single value occupancy
>=1/75th or more of the sample. The recommendation is that there is a minimum of 3000 rows. The following example
shows how to run the procedure:
Set Serveroutput on
EXEC FND_STATS.CHECK_HISTOGRAM_COLS( tablelist =>'owner.table_name1 , owner.table_name2, .... )
Once you have checked the design and performance use the LOAD_HISTOGRAM_COLS procedure to seed information
in the FND_HISTOGRAM_COLS table, which will ensure that they are updated when Gathering Statistics using the
following syntax:
begin
FND_STATS.LOAD_HISTOGRAM_COLS
(action=>'INSERT', appl_id=>&custom_application_id, tabname=>&table_name, colname=>&column_name);
FND_STATS.GATHER_TABLE_STATS( ownname=>&owner_name, tabname=>&table_name);
end;
3
/
The AUTO Sampling Option
Traditionally in Oracle E-Business Suite most statistics were gathered at the default sample size of 10%, which was
provided to the ESTIMATE_PERCENT parameter. Experience shows that some of the products subject to data skew
benefited from gathering at a higher percentage. This led to a trade-off. A larger sample size would deliver more accurate
results, but would take longer to collect; whereas a smaller sample size would collect more quickly, but may not collect
statistics that reflect the true distribution of data and might result in sub-optimal runtime performance (especially in the case
of data skew).
In Oracle 10g DBMS_STATS, the default value for the ESTIMATE_PERCENT parameter changed to
DBMS_STATS.AUTO_SAMPLE_SIZE. Although this allowed Oracle to determine the appropriate sample size, there
were some issues with inadequate samples when tables had exceptional data skew. Oracle 11g now uses hash-based
sampling that has accuracy close to 100% but executes more quickly than when collecting at 10% using the old method.
The new version of FND_STATS now supports the 'AUTO' option for the ESTIMATE_PERCENT parameter, which in
turn uses the DBMS_STATS.AUTO_SAMPLE_SIZE.
Note: Using AUTO is highly recommended as specifying a numeric percentage will use the old statistics
gathering algorithm, even if you specify 100%.
Further advantages of using the AUTO sample size instead of a specific percentage include the following:
It adapts to changes in data volumes, such as system growth or purging, whereas a fixed sampling percentage that was
suitable at some point in time will inevitably require regular tests and reviews.
Historically, a 10% sample was sufficient for most objects, but some products/tables benefited from higher sampling
percentage of 30% - 40%, usually due to data skew. Having to determine which products benefitted, or which sample size
provided the best benefit in least time, should no longer be necessary.
Note: The AUTO sampling feature with Oracle E-Business Suite only operates as described with Oracle 11g.
When used with previous database versions it will use 10% for the estimate_percent parameter.

Note: When invoking the Gather Statistics concurrent program, leave the estimate percentage parameter blank.
The program will automatically choose the default value for estimate_percent parameter (depends on the
database version). If a value is provided then statistics will be gathered at the specified percentage. If the
database version is 11g or higher, the default value for this parameter will be dbms_stats.auto_sample_size,
whereas it will be set to 10% for previous releases.

Note: AUTO Sampling Statistics Gathering Feature of Oracle Database 11g is implemented with the latest code
of FND_STATS. Refer to Standalone Patches section, the standalone patches for Oracle 11g are shown in
Table 1.
Custom Scripts
As an alternative to using the Gather Statistics concurrent program, custom scripts may be developed that call the
FND_STATS package directly. The syntax is as follows:
For schema stats: Exec FND_STATS.gather_schema_statistics('schema_name');
For example:
4
EXEC FND_STATS.gather_schema_statistics('ALL');
EXEC FND_STATS.gather_schema_statistics('XLA');
For table stats: Exec FND_STATS.gather_table_stats(owner,table_name);
For example:
EXEC FND_STATS.gather_table_stats('AR','RA_CUSTOMER_TRX_ALL');
When to Gather Statistics
Some Oracle E-Business Suite customers gather statistics too frequently unnecessarily wasting system resources. Having
representative statistics, doesnt mean frequently running Gather Statistics, such as daily. Instead, devise a strategy to ensure
that the collection frequency does not cause excessive SQL execution plan instability and that the statistics do not reach a
level of staleness that impacts performance. Exceptions include, for example, gathering statistics for a specific set of objects
immediately after significant data imports. This is typically automated within Oracle E-Business Suite interface programs.
Oracle E-Business Suite customers are advised to determine the frequency of statistics gathering based on substantive
changes to data or data skew, in other words, on volume rather than time. It is highly recommended that statistics are
gathered bi-weekly, monthly, or an even longer interval depending on your data.
Consider an example where 1 million records are added per month to a table containing 10M rows. This corresponds to
the 10% threshold used when gathering stale statistics and therefore statistics would be collected approximately once each
month. Variations in volume that trigger the 10% stale threshold may result in more or less frequent updates to the
statistics collection process.
The collection interval may also be determined by monitoring transaction throughput. Create a repeatable baseline of
critical business processes and transactions. Review the baseline regularly, such as weekly or monthly, until key transaction
performance starts to change. Map the business cycle and substantial data changes including, for example, posting, month
end processing, data import, or purging. Use this information to help determine the collection frequency.
Note: A baseline of critical business processes and transactions provide a datum and is exceptionally useful for
performance monitoring when patching or updating the system.
When time constrained and the time to gather statistics exceeds the collection window, break the collection process across
each time slot by schema, or even individual tables. With the later approach, static and reference tables, which tend to be
relatively small, are unlikely to become stale and so it is more important to focus on the more volatile high-transaction
tables.
Note: During collection Oracle internally prioritizes the database objects that require statistics.
Administrators who are trying to determine an appropriate strategy may find it useful to monitor the STALE_STATS
column in USER_TAB_STATISTICS. However, this information is only updated daily, so you also need business
knowledge of the major activities, such as purging or data import or you should additionally refer to information from
USER_TAB_MODIFICATIONS, which lists the number of inserts, updates and deletes.
Overall, gathering statistics on a particular day, date, or specific time during the business cycle enables administrators to
correlate the gathering statistics event with any unexpected behavior. You should not excessively gather statistics on all
schemas such as nightly or weekly.
5
Cursor Invalidation
When an objects statistics are refreshed, all references to that object in the shared pool or library cache are invalidated and
all dependent cursors referencing that object are also invalidated, each will require a new hard parse. Oracle distributes
invalidation timestamps for dependent objects needing invalidation, thereby reducing the potentially large number of
simultaneous hard parses, but this can still result in an increase in library cache waits especially when collecting statistics
across a large number of objects.
Note: When using the Gather Statistics concurrent program, the Invalidate Dependent Cursors parameter is set
to Yes by default, which is the standard best practice. New execution plans will be generated whenever cursor
has been flushed out and reloaded.
While this approach suits most Oracle E-Business Suite installations, this parameter allows you to specify that cursors
should not be invalidated. Although this may reduce the CPU utilization, this means that existing plans, which may be sub-
optimal, will continue to be used until the dependent cursors are aged out.
Deciding between these two invalidation options is determined by the collection frequency. If you keep your statistics fairly
current, you will probably not need to invalidate cursors as the plans from the newly collected statistic are unlikely to be
significantly different. In other words, performance should remain consistent and stable and over time. However, if you
dont collect statistics frequently enough, or if you start to experience performance degradation due to stale statistics, then
setting this to the default to invalidate the cursors that are dependent on the targeted objects as soon as possible will ensure
that the plans are refreshed sooner.
Note: Gather statistics only when there is little system activity or during a defined batch period.
Locking Statistics
Locking prevents object statistics from being overwritten when the collection processes is run. This may be useful when
tables are empty when the collection process is run, or when you want to exclude exceptionally large tables while gathering
statistics for the remainder of the schema.

Consider locking statistics for the following:

Very large static tables that have representative statistics already in place and are rarely updated.

Volatile tables where data changes dramatically over time. Good examples include intermediate tables used during
batch processing and some interface tables, which are deployed extensively across Oracle E-business Suite. Example
application tables include AP_SELECTED_INVOICES and WSH_PR_WORKERS.

Temporary or interim tables that only contain data at runtime but are typically empty when the collection process
runs. In this specific case, not locking statistics results in having zero or un-representative statistics. Note that these do
not include Global Temporary tables, which are excluded from FND_STATS Gather Schema Statistics anyway.

Note : If a table has zero statistics (num_rows = 0) then the CBO uses these statistics to determine the
execution plan and if the table has a lot of rows at time of execution then this execution plan could be very
inefficient. If tables have empty statistics (null) then dynamic sampling will be used, which is preferable to
using the CBO with incorrect or zero statistics.

There are two distinct methods for protecting table statistics from modification.

1. You can physically lock the statistics using DBMS_STATS.LOCK_TABLE_STATS, which prevents any calls to
FND_STATS or DBMS_STATS from modifying the statistics.
6

2. You can also add the table to a list of excluded tables by using FND_STATS.LOAD_XCLUD_TAB. This prevents the table
from having its statistics modified when using Gather Schema Statistics, but the Gather Table Statistics does not honor
the FND exclusion, only the DBMS lock. This is by design; there may be instances when you want to manually collect
statitistics.

Oracle E-Business Suite development teams use LOAD_XCLUD_TAB to seed exceptions into the
FND_EXCLUDE_TABLE_STATS table (which is a metadata container). Many of the EBS volatile and temporary tables
are seeded in this table for reference only. They will not be excluded from FND_STATS Gather Schema Statistics, as they
have been seeded with negative application_ids. You should consider these tables as candidates for locking.

Note: It is recommended that you use seed tables into FND_EXCLUDE_TABLE_STATS, or use
DBMS_STATS.LOCK_TABLE_STATS if certain that you never want the statistics modified.
For each volatile or temporary table that you have locked you should initially have empty (null) statistics and rely
on dynamic sampling. Delete the statistics if they already contain values. Only if you have performance issues
should you consider gathering statistics when the table has a representative load or populating using
FND_STATS. SET_TABLE_STATS.

Once the statistics are locked using DBMS_STATS.LOCK_TABLE_STATS, the Gather Schema Statistics Concurrent
Program will display a message in the request log file explicitly stating that statistics are locked on that table.

Use the following to seed a table in FND_EXCLUDE_TABLE_STATS:

FND_STATS.LOAD_XCLUD_TAB(action=>'INSERT', appl_id=>&application_id, tabname=>&table_name)
Example
FND_STATS.LOAD_XCLUD_TAB(action=>'INSERT',
appl_id=>222,tabname=>'RA_CUSTOMER_TRX_ALL)

Use the following to delete the table entry from the fnd_exclude_table_stats:

FND_STATS.LOAD_XCLUD_TAB(action=>'DELETE', appl_id=>&application_id, tabname=>&table_name)
Example
FND_STATS.LOAD_XCLUD_TAB(action=>'DELETE',
appl_id=>222, tabname=>'RA_CUSTOMER_TRX_ALL')
Database 11g Extended Statistics
The Oracle Optimizer collects statistics on separate columns but does not have any knowledge about the relationship or
correlation between the data stored across separate columns in the same table.
Creating extended statistics on a group of columns increases the accuracy of the combined selectivity of the predicates and
hence the cardinality estimate, when the columns are used together in the where clause of a SQL statement. These are
typically used when the cardinality estimates on a group of columns is inaccurate.
The column groups are defined using DBMS_STATS.CREATE_EXTENDED_STATS. Once created, Oracle will
automatically maintain the statistics on that column group when statistics are gathered on the table.
Note: The new FND_STATS, as provided by Oracle E-Business Suite standalone patches now supports Oracle
11g extended statistics. Refer to Standalone Patches section, the standalone patches for Oracle 11g are shown in
Table 1.
In Oracle E-Business Suite, FND_STATS.LOAD_EXTNSTATS_COLS is used to seed the multi-column groups.
Statistics are automatically maintained by Gather Schema/Table Statistics concurrent programs or when using
FND_STATS. The following examples provide the syntax for this procedure:
7
begin
FND_STATS.LOAD_EXTNSTATS_COLS
(action =>'INSERT', appl_id=>&custom_application_id, tabname =>&table_name, owner=>&owner, colname1
=>&column_name1, colname2 =>&column_name2, colname3.....);
FND_STATS.GATHER_TABLE_STATS( ownname=>&owner_name, tabname=>&table_name);
end;
/
Note: You need to gather statistics after defining the group of columns.
Gathering Dictionary and Fixed Object Statistics
For the Cost Based Optimizer to work effectively for internal (recursive) SQLs, or application SQLs that use data dictionary
views or fixed objects, the statistics need to be gathered for all the dictionary tables (owned by SYS, SYSTEM and
SYSAUX etc) and the x$ tables used by the dynamic v$ performance views.
FND_STATS does not gather statistics for dictionary or fixed objects and instead you need to use DBMS_STATS in 10g
and above. There are no Oracle E-Business Suite specific guidelines on the collection frequency for the dictionary and fixed
object statistics.
Dictionary Statistics
Dictionary statistics only need to be gathered when there have been significant structural changes to the database.
e.g.
After any associated platform or DB upgrade that is part of the overall EBS upgrade.
After the R12 upgrade.
After move to OATM
The question is when, and how often do they need to be collected. Typical examples include upgrades, new modules, or the
application of large patches where several objects might be created or rebuilt using Data Definition Language (DDL)
operations.
Statistics will need to be collected when SQL on the data dictionary objects appears as a high load (usually high elapsed
time) in AWR reports or other monitoring tools, or when times in trace/tkprof files are very high for recursive SQL on the
data dictionary objects. The following command can be used to gather statistics for all system schemas:
EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS( estimate_percent =>DBMS_STATS.AUTO_SAMPLE_SIZE options
=>'GATHER AUTO' ); -- In 10G and above.
Fixed Object Statistics
Fixed objects include the x$ tables and their indexes, which typically contain information about the instance or memory
structures. Unlike dictionary tables that reside on disk, such as SYS.DBA_DATA_FILES, most of the v$ views, such as
V$SQL and V$SQL_PLAN are based on the x$ tables, which are in-memory structures. As such, fixed tables have no IO
cost associated with them and therefore when generating an execution plan the CBO only considers the CPU cost.
The automatic statistics gathering job does not gather fixed object statistics and in this case, dynamic sampling is not
automatically used for SQL statements involving x$ tables when statistics are missing. Instead, the Optimizer uses
predefined default values; however, these defaults may not be representative and could potentially lead to suboptimal
execution plans.
8
How and When to Gather Fixed Object Statistics
Use DBMS_STATS.GATHER_FIXED_OBJECT_STATS (available in Oracle 10g and later) to gather fixed object
statistics. For optimal performance, and due to the transient nature of the x$ tables, it is important to gather statistics when
there is a representative workload on the system. The collection process tends to be resource intensive and if there is
insufficient capacity during peak load, choose a time after the database has been running for some time and the v$ views
have a significant amount of data. However, gathering fixed objects statistics under heavy load can result in contention
issues thereby leading to performance degradation or hangs. Refer to MyOracle Knowledge Document Fixed Objects
Statistics (GATHER_FIXED_OBJECTS_STATS) Considerations (Doc ID 798257.1) for further information.
The following command can be used to gather fixed object statistics:
EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
Planning Collection
Fixed object statistics should be gathered when there are significant changes to the database configuration or when
accessing the v$ views is of concern. Oracle E-Business Suite examples include the following:
Major database or application upgrades*
Platform upgrades (especially Exadata)
New application modules are deployed
Performance issues when querying V$ views
Significant changes in the workload or number of sessions
After significant database structure changes (e.g. SGA/PGA)
For example, all the x$ tables that contain information about the buffer cache and shared pool, such as x$ tables used in
v$buffer_pool or v$shared_pool_advice, may change significantly when the SGA is increased.
Note: In Oracle E-Business Suite it is imperative that you disable the Database 11g automatic DBMS job to
gather statistics, but ensure that dictionary statistics are still gathered.
* When upgrading Oracle E-Business Suite, the $APPL_TOP/admin/adstats.sql script disables the Oracle DBMS job that
automatically gathers statistics. It then gathers dictionary and fixed object statistics. However, the Database is run in
restricted mode during the upgrade. Therefore, it is highly recommended to rerun
DBMS_STATS.GATHER_FIXED_OBJECT_STATS post upgrade, when there is a representative load on the system.
Global Temporary Tables
Several Oracle E-Business Suite product teams create and use global temporary tables (GTTs) within a process; they are
subsequently dropped when the process completes. These tables are completely dynamic in nature. The standard
performance recommendation is not to gather statistics on global temporary tables.
The following approaches can be used to ensure good execution plan:
Rely on dynamic sampling, which will occur in the absence of statistics. You need to delete any stats using
DBMS_STATS.delete_table_stats on Global Temporary Tables as dynamic sampling only works if statistics are empty.
However, dynamic sampling statistics may not result in an optimal execution plan and often queries will also need to
include Optimizer hints to force a particular execution plan.
9
Note that FND_STATS Gather Schema Statistics excludes Global Temporary Tables anyway, so they do not need to
be excluded or locked.
Temporary Tables
Temporary tables in Oracle E-Business Suite are regular tables that should not be confused with GTTs. They tend to be
highly volatile and are typically empty for some of the processing cycle and then re-populated. Examples include interface
tables, intermediate transient tables, transactions that have been selected by a specific process such as payments or records
to be purged.
For these tables you should initially have empty (null) statistics and rely on dynamic sampling. Delete the statistics if they
already contain values.
Only if you have performance issues should you consider gathering statistics when the table has a representative load or
populating using FND_STATS. SET_TABLE_STATS.
In all cases the statistics should be locked (so that they are not gathered).
Incremental Statistics for Partitioned Tables
Incremental statistics gathering is a new Oracle 11gR2 DBMS_STATS feature and is fully supported by FND_STATS.
Oracle derives global statistics by scanning only new or modified partitions rather than the whole table, which is highly
beneficial with high volume Oracle E-Business Suite tables.
Incremental global statistics works by collecting statistics and storing a synopsis (statistical metadata) for each partition,
which consists of statistical metadata and the columns in each partition. This synopsis is typically only a few KB and is
stored in the SYSAUX tablespace. Global statistics are created not by reading the entire table, but by aggregating the
synopsis from each partition. Once a synopsis has been created for a new partition, all the synopses will be aggregated to
update the table level statistics.
The preconditions that need to be met for this approach include the following:
The INCREMENTAL preference for the partition table is set to TRUE
DBMS_STATS.GATHER_*_STATS parameter GRANULARITY includes ALL or AUTO.
ESTIMATE_PERCENT is set to AUTO_SAMPLE_SIZE (default in Oracle 11g)
Incremental statistics in conjunction with the new Oracle 11g DBMS_STATS.AUTO_SAMPLE_SIZE yield a significant
reduction in the time to collect highly accurate statistics.
Oracle E-Business Suite
Incremental statistics can be applied to any large partitioned tables. Once the table preference has been set, Oracle E-
Business Suite Gather Statistics (table or schema) can be used to automatically gather the statistics and create the synopsis.
Incremental Preference
Use the following command to check if the incremental preference is set for the XLA_AE_LINES table (which is part of
the Oracle E-Business Suite12 Subledger Accounting):
select dbms_stats.get_prefs('INCREMENTAL', 'XLA','XLA_AE_LINES')
from dual;
10
If it returns TRUE then the preference is set.
The preference can be set using the following command:
exec dbms_stats.set_table_prefs('XLA','XLA_AE_LINES','INCREMENTAL','TRUE');
During testing, it may be useful to know that the preference can be turned off using:
exec dbms_stats.set_table_prefs('XLA', 'XLA_AE_LINES, 'INCREMENTAL', 'FALSE');
Granularity Parameter
When running Gather Statistics at the schema or table level:
Set the granularity parameter to ALL or AUTO. Both of these are effectively the same and will invoke all the
granularity levels.
Set the Estimate Percent parameter to DBMS_STATS.AUTO_SAMPLE_SIZE, which is the default with Oracle 11g.
If you use custom scripts with FND_STATS, set the granularity to ALL or AUTO. For example:

exec fnd_stats.gather_table_stats
('OWNER', TABLE_NAME', granularity =>'ALL');
Improving the Collection Time
There are two ways to speed up the gather statistics collection process.
Degree Of Parallelism
FND_STATSs DEGREE (Degree of parallelism) helps speed up statistics gathering for large objects. If a degree is not
provided, FND_STATS automatically determines the Degree of Parallelism, it defaults to the minimum of
parallel_max_servers and cpu_count. This approach has been defined as intra object parallelism.
Concurrent Statistics Gathering
Concurrent statistics gathering is a new DBMS_STATS feature in Oracle 11gR2 that provides inter-object parallelism.
When CONCURRENT is set to TRUE (FALSE by default) and Estimate Percent is set to
DBMS_STATS.AUTO_SAMPLE_SIZE, Oracle uses the Oracle Job Scheduler ( job_queue_processes should be set to more
than 4) and Advanced Queuing to concurrently run multiple gather statistics jobs across multiple objects.
The preference can be set using the following command:
exec DBMS_STATS.SET_GLOBAL_PREFS('CONCURRENT','TRUE');
This needs to be set by logging in as sys user.
When using DEGREE, parallel servers will only work on one table partition at a time. This limitation is overcome when
combined with the Oracle 11gR2 concurrent feature.
This combined approach is most beneficial when there is plenty of available CPU. It is aimed at systems with several CPUs
that have spare capacity when the gather statistics process is run. It is unlikely to make much difference on small servers
(that are less likely to have huge partitions), or large servers that have reach maximum CPU during traditional (non-
concurrent) statistics gathering.
Although these features are supported, they may not provide a significant improvement as FND_STATS in 11gR2 already
uses the AUTO sample size and parallelism while gathering stats. In addition FND_STATS calls
11
DBMS_STATS.gather_table_stats and not gather_schema_statistics. So this feature can only be used to gather statistics for
different partitions of the same table at the same time. So it is only beneficial on partitioned tables, where data is reasonably
well distributed across the partitions.
Verifying Statistics
The FND_STATS.VERIFY_STATS procedure can be used to check that statistics are up-to-date. It produces a report and
can be run using the following syntax:
set serveroutput on
set long 10000
exec apps.fnd_stats.verify_stats (OWNER, TABLE_NAME);
For example:
exec apps.fnd_stats.verify_stats ('ONT', 'ONT.OE_ORDER_HOLDS_ALL');
Alternatively, you can verify statistics using the scripts from My Oracle Support Knowledge Document 163208.1.
bde_last_analyzed.sql - Verifies CBO Statistics.
Standalone Patches
The standalone patches for Oracle 11g are shown in Table 1: Oracle E-Business Suite Standalone Patches for the following
new features implemented in FND_STATS code.
1. Database 11g AUTO Sampling Statistics Gathering Option
Those unable to apply the Auto sampling standalone patch should review the automated script provided in My Oracle
Knowledge Document 156968.1: coe_stats.sql - Automates CBO Stats Gathering using FND_STATS and Table sizes.
This interim solution provides recommendations based on the range, sample size, and collection frequency.
2. Database 11g Extended Statistics Gathering Feature

TABLE 1. ORACLE E-BUSINESS SUITE STANDALONE PATCHES
(ORACLE 11G)
E-BUSINESS SUITE VERSION PATCH
12.1.x 16410424:R12.FND.B
12.0.x 16410424:R12.FND.A
11.5.10 14707975
12
Performance Test Cases & Examples
1. Oracle 11g Extended Optimizer Statistics
2. Incremental Statistics Gathering
3. Concurrent Stats Gathering
1. Oracle 11g Extended Optimizer Statistics
This simple example demonstrates how you might deploy the Oracle 11g extended (multi-column) optimizer statistics
feature in Oracle E-Business Suite. Recall that, individual column statistics provide the selectivity of a specific column, but
when the where clause includes multiple columns from the same table, the individual column statistics provide no
indication of the relationship between the columns. The extended statistics increase the accuracy of the combined selectivity
of the individual predicates, and hence the cardinality estimate, which results in a better execution plan.

The FND_LOOKUP_VALUES table provides the basis for this example as it is suitably small, easy to understand, and
may be familiar as is used across several modules.

It stores Oracle Application Object Library QuickCode values. Essentially each row contains the QuickCode lookup type,
the QuickCode itself, its meaning, and additional description (also other columns not directly pertinent to this example).
These values are used by List of Values across several of the Oracle E-Business Suite forms.

Several of the values are only used by specific modules and therefore they are typically both referenced when querying data,
which is one of the primary conditions for using extended statistics. As such, this implies that there is a correlation between
the columns, and in fact the LOOKUP_TYPE is dependent upon the VIEW_APPLICATION_ID.
1. Statistics without Extended Statistics
Gat her i ng st at i st i cs on t abl e wi t hout any mul t i col umn ext ensi on st at s f or t hi s t est case we ar e usi ng
FND_LOOKUP_VALUES t abl e.

- Descr i be t he FND_LOOKUP_VALUES t abl e.

desc FND_LOOKUP_VALUES

Dat at ype Lengt h Mandat or y Comment s
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LOOKUP_TYPE VARCHAR2 ( 30) Yes Qui ckCode l ookup t ype
LANGUAGE VARCHAR2 ( 30) Yes Language
LOOKUP_CODE VARCHAR2 ( 30) Yes Qui ckCode code
MEANI NG VARCHAR2 ( 80) Yes Qui ckCode meani ng
DESCRI PTI ON VARCHAR2 ( 240) Descr i pt i on
ENABLED_FLAG VARCHAR2 ( 1) Yes Enabl ed f l ag
SECURI TY_GROUP_I D NUMBER ( 15) Yes Secur i t y gr oup i dent i f i er
VI EW_APPLI CATI ON_I D NUMBER ( 15) Yes I dent i f i es whi ch appl i cat i on' s vi ew wi l l i ncl ude t he
l ookup val ues
TERRI TORY_CODE VARCHAR2 ( 2) Ter r i t or y code of t er r i t or y usi ng t he l anguage
. . . .
. . . .

- Tot al car di nal i t y of t he FND_LOOKUP_VALUES t abl e:

sel ect count ( 1) f r omFND_LOOKUP_VALUES;

COUNT( 1)
- - - - - - - - - -
532559

- Run gat her st at i st i cs on FND_LOOKUP_VALUES t abl e:

exec f nd_st at s. gat her _t abl e_st at s( ' APPLSYS' , ' FND_LOOKUP_VALUES' ) ;

- Check t he updat ed st at i st i cs i n dba_t abl es.

sel ect t abl e_name, num_r ows f r omdba_t abl es wher e t abl e_name=' FND_LOOKUP_VALUES' ;

TABLE_NAME NUM_ROWS
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FND_LOOKUP_VALUES 532559
13

- The f ol l owi ng hi st ogr ams ar e al r eady pr esent i n t he FND dat a di ct i onar y:

sel ect t abl e_name, col umn_name f r omf nd_hi st ogr am_col s wher e t abl e_name=' FND_LOOKUP_VALUES' ;

TABLE_NAME COLUMN_NAME
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FND_LOOKUP_VALUES LANGUAGE
FND_LOOKUP_VALUES VI EW_APPLI CATI ON_I D

- Revi ew t he t abl e dat a di st r i but i on.

sel ect VI EW_APPLI CATI ON_I D, l ookup_t ype, count ( *)
f r omFND_LOOKUP_VALUES
gr oup by VI EW_APPLI CATI ON_I D, l ookup_t ype
or der by 3 desc;

VI EW_APPLI CATI ON_I D LOOKUP_TYPE COUNT( *)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3 NO_POSTAL_CODE 13698
3 FI _POSTAL_CODE 11496
3 GHR_US_ACADEMI C_I NSTI TUTI ON 11043
3 AE_OCCUPATI ON 8760
3 PL_COMMUNI TY 7437
222 NAI CS_2002 7035
8901 FV_PSC_TYPE 6906
3 NAI C 6306
222 NAI CS_1997 5430
3 GHR_US_ACADEMI C_DI SCI PLI NE 5127
222 NACE 4599
222 1987 SI C 4512
222 1972 SI C 4338
8405 PE_US_COURSE_SUBJ ECT 4299
3 DK_POSTCODE_TOWN 4002
8901 FV_NAI CS_TYPE 3537
222 1977 SI C 3111
8901 FV_SI C_TYPE 3012
200 NUMBERS 3000
3 GHR_US_OCC_SERI ES 2889
3 NO_TAX_MUNI CI PALI TY 2619
3 GHR_US_LANG_I DENTI FI ER 2547
3 GHR_US_FOR_ALL_LOC 2238
3 GHR_US_AGENCY_CODE 2208
0 BUSI NESS_ENTI TY 2199
222 NAF 2145
3 GHR_US_LEGAL_AUTHORI TY 2031
3 GHR_US_HEALTH_PLAN 2001
8405 I MPORT_ERROR_CODE 1890
3 HU_J OB_FEOR_CODES 1884
222 HZ_RELATI ONSHI P_ROLE 1521
8901 FV_FSC_TYPE 1365
3 AE_AREA_CODES 1350

- Check t he dat a di st r i but i on i n f nd_l ookup_Val ues t abl e.

sel ect t abl e_name, col umn_name, num_di st i nct , densi t y, num_bucket s, hi st ogr amf r omuser _t ab_col _st at i st i cs wher e
t abl e_name = ' FND_LOOKUP_VALUES' ;

TABLE_NAME COLUMN_NAME NUM_DI STI NCT DENSI TY NUM_BUCKETS HI STOGRAM
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FND_LOOKUP_VALUES LOOKUP_TYPE 17203 . 000058129 1 NONE
FND_LOOKUP_VALUES LANGUAGE 3 9. 3886E- 07 3 FREQUENCY
FND_LOOKUP_VALUES LOOKUP_CODE 86164 . 000011606 1 NONE
FND_LOOKUP_VALUES MEANI NG 330917 3. 0219E- 06 1 NONE
FND_LOOKUP_VALUES DESCRI PTI ON 207029 4. 8302E- 06 1 NONE
FND_LOOKUP_VALUES ENABLED_FLAG 4 . 25 1 NONE
FND_LOOKUP_VALUES SECURI TY_GROUP_I D 17 . 058823529 1 NONE
FND_LOOKUP_VALUES VI EW_APPLI CATI ON_I D 87 9. 3886E- 07 87 FREQUENCY
FND_LOOKUP_VALUES TERRI TORY_CODE 10 . 1 1 NONE
. . . .
. . . .

- Check expl ai n pl an of t he sel ect f or t he di f f er ent val ues of vi ew_appl i cat i on_i d and l ookup_t ype

expl ai n pl an f or sel ect * f r omFND_LOOKUP_VALUES wher e VI EW_APPLI CATI ON_I D=201 and l ookup_t ype=: b2;

Expl ai ned.

sel ect pl an_t abl e_out put f r omt abl e( dbms_xpl an. di spl ay( ' pl an_t abl e' , nul l , ' ser i al ' ) ) ;

PLAN_TABLE_OUTPUT
14
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| I d | Oper at i on | Name | Rows | Byt es | Cost ( %CPU) | Ti me |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 0 | SELECT STATEMENT | | 1 | 152 | 4 ( 0) | 00: 00: 01 |
| 1 | TABLE ACCESS BY I NDEX ROWI D| FND_LOOKUP_VALUES | 1 | 152 | 4 ( 0) | 00: 00: 01 |
| * 2 | I NDEX RANGE SCAN | FND_LOOKUP_VALUES_U1 | 1 | | 3 ( 0) | 00: 00: 01 |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Pr edi cat e I nf or mat i on: 2 - access( " LOOKUP_TYPE" =: B2 AND " VI EW_APPLI CATI ON_I D" =201)

expl ai n pl an f or sel ect * f r omFND_LOOKUP_VALUES wher e VI EW_APPLI CATI ON_I D=3 and l ookup_t ype=' NO_POSTAL_CODE' ;

Expl ai ned.


PLAN_TABLE_OUTPUT
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Pr edi cat e I nf or mat i on: 2 - access( " LOOKUP_TYPE" =' NO_POSTAL_CODE' AND " VI EW_APPLI CATI ON_I D" =3)

expl ai n pl an f or sel ect * f r omFND_LOOKUP_VALUES wher e VI EW_APPLI CATI ON_I D=3 and l ookup_t ype=' AE_ARI A_CODE' ;
Expl ai ned.


PLAN_TABLE_OUTPUT
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Pr edi cat e I nf or mat i on: 2 - access( " LOOKUP_TYPE" =' AE_ARI A_CODE' AND " VI EW_APPLI CATI ON_I D" =3)
2. Statistics with Extended Stats

The ext ended st at i st i cs appr oach wi l l cr eat e a col umn st at i st i cs ent r y f or t he col umn gr oup i n t he Dat a Di ct i onar y. I n
t hi s exampl e t hey ar e gat her ed manual l y so t hat t he r esul t can be seen i mmedi at el y.

- St eps t o cr eat e mul t i col umn ext ended st at i st i cs

- Quer y f nd_ext nst at s_col s t abl e t o conf i r mt hat ext ended st at i st i cs do not exi st . f nd_exnst at s_col s i s FND t abl e
whi ch hol ds t he col umns on whi ch ext ensi on st at s wi l l be cr eat ed.

sel ect t abl e_name f r omf nd_ext nst at s_col s;

no r ows sel ect ed

- Del et e t he cur r ent st at i st i cs on FND_LOKUP_VALUES t abl e

anal yze t abl e appl sys. f nd_l ookup_val ues del et e st at i st i cs;

Tabl e anal yzed.

- Cr eat e ext ended st at i st i cs f or t he LOOKUP_TYPE and VI EW_APPLI CATI ON_I D:

set ser ver out put on

- Execut e f nd_st at s. l oad_ext nst at s_col s. Cr eat e mul t i col umn ext ensi on st at s usi ng f nd_st at s

exec f nd_st at s. l oad_ext nst at s_col s( act i on =>' I NSERT' , appl _i d=>0, t abname => ' FND_LOOKUP_VALUES' , col name1
=>' VI EW_APPLI CATI ON_I D' , col name2 =>' LOOKUP_TYPE' ) ;

PL/ SQL pr ocedur e successf ul l y compl et ed.

- check i f vi r t ual col umn i s cr eat ed f or t he mul t i - col umns i nvol ved f or t he ext ended st at i st i cs.

sel ect owner , t abl e_name, col umn_name, hi st ogr amf r omdba_t ab_col s wher e t abl e_name l i ke ' FND_LOOKUP_VALUES' and owner
=' APPLSYS' ;

OWNER TABLE_NAME COLUMN_NAME HI STOGRAM
15
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
APPLSYS FND_LOOKUP_VALUES ZD_EDI TI ON_NAME NONE
APPLSYS FND_LOOKUP_VALUES SYS_STU_L5AKW15J 1DXUKXDMYW3UJ F NONE
APPLSYS FND_LOOKUP_VALUES

- Above out put shows t hat t he vi r t ual col umn SYS_STU_L5AKW15J 1DXUKXDMYW3UJ F i s cr eat ed.

- Gat her st at i st i cs on ' FND_LOOKUP_VALUES' t o check i f hi st ogr ami s get t i ng cr eat ed on t he vi r t ual col umn

exec f nd_st at s. gat her _t abl e_st at s( ' APPLSYS' , ' FND_LOOKUP_VALUES' ) ;


- check i f hi st ogr ami s cr eat ed on vi r t ual col umn

sel ect owner , t abl e_name, col umn_name, hi st ogr amf r omdba_t ab_col s wher e t abl e_name l i ke ' FND_LOOKUP_VALUES' and owner
=' APPLSYS' ;

OWNER TABLE_NAME COLUMN_NAME HI STOGRAM
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
APPLSYS FND_LOOKUP_VALUES ZD_EDI TI ON_NAME NONE

APPLSYS FND_LOOKUP_VALUES SYS_STU_L5AKW15J 1DXUKXDMYW3UJ F HEI GHT BALANCED

- Above out put shows t hat t he hei ght bal anced hi st ogr ami s cr eat ed on t he vi r t ual col umn
- Now check t he changes i n t he expl ai n pl an of t he sel ect f or t he di f f er ent val ues of vi ew_appl i cat i on_i d and
l ookup_t ype

expl ai n pl an f or sel ect * f r omFND_LOOKUP_VALUES wher e VI EW_APPLI CATI ON_I D=201 and l ookup_t ype=: b2;

Expl ai ned.


PLAN_TABLE_OUTPUT
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Pr edi cat e I nf or mat i on ( i dent i f i ed by oper at i on i d) :
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 - access( " LOOKUP_TYPE" =: B2 AND " VI EW_APPLI CATI ON_I D" =201)

expl ai n pl an f or sel ect * f r omFND_LOOKUP_VALUES wher e VI EW_APPLI CATI ON_I D=3 and l ookup_t ype=' NO_POSTAL_CODE'

Expl ai ned.


PLAN_TABLE_OUTPUT
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 0 | SELECT STATEMENT | | 12580 | 1867K| 2729 ( 2) | 00: 00: 33 |
| * 1 | TABLE ACCESS FULL| FND_LOOKUP_VALUES | 12580 | 1867K| 2729 ( 2) | 00: 00: 33 |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 - f i l t er ( " LOOKUP_TYPE" =' NO_POSTAL_CODE' AND " VI EW_APPLI CATI ON_I D" =3)

expl ai n pl an f or sel ect * f r omFND_LOOKUP_VALUES wher e VI EW_APPLI CATI ON_I D=3 and l ookup_t ype=' AE_ARI A_CODE' ;

Expl ai ned.


PLAN_TABLE_OUTPUT
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

16
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 - access( " LOOKUP_TYPE" =' AE_ARI A_CODE' AND " VI EW_APPLI CATI ON_I D" =3)

Resul t : Above r esul t s shows t he car di nal i t y est i mat i on changes af t er cr eat i ng mul t i col umn ext ended st at s.
2. Incremental Statistics Gathering

Incremental statistics gathering is a new feature of 11G Database. Incremental stats will work only for partitioned tables
where global statistics are updated incrementally by scanning only the partitions that have changed from the last run. This
simple example demonstrates how you might deploy the Oracle 11g incremental Statistics Gathering feature in Oracle E-
Business Suite.

- Cr eat e a t abl e xl a_ae_l i nes_bkp as a par t i t i on t abl e t o per f or mt hi s t est case
- I nser t dat a f r omxl a_ae_l i nes t abl e

i nser t i nt o xl a. xl a_Ae_l i nes_bkp sel ect * f r omxl a. xl a_ae_l i nes;

1909409 r ows cr eat ed.

- Test case wi t hout set t i ng i ncr ement al pr ef er ence

set t i me on t i mi ng on

exec f nd_st at s. gat her _t abl e_st at s( ' XLA' , ' XLA_AE_LI NES_BKP' ) ;


El apsed: 00: 00: 29. 06

- I t t ook 29. 06 sec t o gat her st at s f or t he f i r st t i me af t er dat a i nser t i on.
- Check t he st at i st i cs and gl obal and par t i t i on l evel

sel ect t abl e_name, t o_Char ( l ast _anal yzed, ' DD- MON- YY HH24: MI : SS' ) " l ast _anal yzed" f r omdba_Tabl es wher e t abl e_name l i ke
' XLA_AE_LI NES_BKP' ;

TABLE_NAME l ast _anal yzed
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
XLA_AE_LI NES_BKP 23- SEP- 12 07: 04: 34

sel ect par t i t i on_name, t o_Char ( l ast _anal yzed, ' DD- MON- YY HH24: MI : SS' ) " l ast _anal yzed" f r omdba_Tab_par t i t i ons wher e
t abl e_name l i ke ' XLA_AE_LI NES_BKP' ;

PARTI TI ON_NAME l ast _anal yzed
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AP 23- SEP- 12 07: 04: 15
AR 23- SEP- 12 07: 04: 16
CE 23- SEP- 12 07: 04: 16
CST 23- SEP- 12 07: 04: 23
DPP 23- SEP- 12 07: 04: 23
FUN 23- SEP- 12 07: 04: 23
FV 23- SEP- 12 07: 04: 23
GMF 23- SEP- 12 07: 04: 23
I GC 23- SEP- 12 07: 04: 23
I GI 23- SEP- 12 07: 04: 23
LNS 23- SEP- 12 07: 04: 23
OFA 23- SEP- 12 07: 04: 23
OKL 23- SEP- 12 07: 04: 23
OZF 23- SEP- 12 07: 04: 23
PA 23- SEP- 12 07: 04: 24
PAY 23- SEP- 12 07: 04: 24
PN 23- SEP- 12 07: 04: 24
PO 23- SEP- 12 07: 04: 24
PSB 23- SEP- 12 07: 04: 24

- Del et e t he dat a f r omone of t he par t i t i on t o check how st at i st i cs ar e get t i ng cal cul at ed

del et e f r omxl a. xl a_ae_l i nes_bkp wher e appl i cat i on_i d=222;

- Gat her i ng st at s usi gn f nd_St at s



El apsed: 00: 00: 14. 06

- Af t er del et i ng t he dat a r an gat her st at s wi t hout set t i ng t he pr ef er ence. I t t ook 14. 06 sec
17

- Checki ng gl obal st at s and par t i t i on st at s


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AP 23- SEP- 12 07: 10: 14
AR 23- SEP- 12 07: 10: 14
CE 23- SEP- 12 07: 10: 14
CST 23- SEP- 12 07: 10: 15
DPP 23- SEP- 12 07: 10: 15
FUN 23- SEP- 12 07: 10: 15
FV 23- SEP- 12 07: 10: 15
GMF 23- SEP- 12 07: 10: 15
I GC 23- SEP- 12 07: 10: 15
I GI 23- SEP- 12 07: 10: 15
LNS 23- SEP- 12 07: 10: 16
OFA 23- SEP- 12 07: 10: 16
OKL 23- SEP- 12 07: 10: 16
OZF 23- SEP- 12 07: 10: 16
PA 23- SEP- 12 07: 10: 17
PAY 23- SEP- 12 07: 10: 17
PN 23- SEP- 12 07: 10: 17
PO 23- SEP- 12 07: 10: 17
PSB 23- SEP- 12 07: 10: 17

19 r ows sel ect ed.

NOTE : st at i st i cs ar e gat her ed on al l t he par t i t i ons even t hough onl y AR par i t i on dat a i s del et ed, l ast _anal yzed i s
updat ed f or al l t he par t i t i ons.

- Per f or mt he same t est case af t er set t i ng t he pr ef er ence t o t r ue. Fol l owi ng command wi l l set t he i ncr ement al
pr ef er ence at t he t abl e l evel so next t i me when gat her st at i st i cs i s r un, i t wi l l gat her st at s i ncr ement al on t hi s
t abl e
- Dr op and Recr eat e t he t abl e xl a_ae_l i nes_bkp as a par t i t i on t abl e t o per f or mt hi s t est case
- I nser t dat a f r omxl a_ae_l i nes t abl e

i nser t i nt o xl a. xl a_Ae_l i nes_bkp sel ect * f r omxl a. xl a_ae_l i nes;

1909409 r ows cr eat ed.

exec dbms_st at s. set _t abl e_pr ef s( ' XLA' , ' XLA_AE_LI NES_BKP' , ' I NCREMENTAL' , ' TRUE' ) ;

- Check i f t he pr ef er ence i s set

sel ect dbms_st at s. get _pr ef s( ' I NCREMENTAL' , ' XLA' , ' XLA_AE_LI NES_BKP' ) f r omdual ;

DBMS_STATS. GET_PREFS( ' I NCREMENTAL' , ' XLA' , ' XLA_AE_LI NES_BKP' )
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TRUE

- Gat her st at i st i cs af t er set t i ng t he pr ef er ence.



El apsed: 00: 00: 22. 91

- Af t er set t i ng t he pr ef er ence i t t ook 22. 91 sec t o gat her st at i st i cs f or t he f i r st t i me af t er dat a i nser t i on
- checki ng st at s t i mi ng i nf or mat i on


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

18

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AP 23- SEP- 12 07: 17: 30
AR 23- SEP- 12 07: 17: 12
CE 23- SEP- 12 07: 17: 10
CST 23- SEP- 12 07: 17: 21
DPP 23- SEP- 12 07: 17: 21
FUN 23- SEP- 12 07: 17: 12
FV 23- SEP- 12 07: 17: 10
GMF 23- SEP- 12 07: 17: 10
I GC 23- SEP- 12 07: 17: 10
I GI 23- SEP- 12 07: 17: 12
LNS 23- SEP- 12 07: 17: 10
OFA 23- SEP- 12 07: 17: 10
OKL 23- SEP- 12 07: 17: 12
OZF 23- SEP- 12 07: 17: 30
PA 23- SEP- 12 07: 17: 12
PAY 23- SEP- 12 07: 17: 12
PN 23- SEP- 12 07: 17: 12
PO 23- SEP- 12 07: 17: 10
PSB 23- SEP- 12 07: 17: 30


- Del et i ng t he dat a f r omone par t i t i on t o see how i ncr ement al st at i st i cs gat her i ng wi l l hel p next t i me when st at s ar e
gat her ed.

del et e f r omxl a_ae_l i nes_bkp wher e appl i cat i on_i d=222;

100233 r ows del et ed

- Gat her st at i st i cs af t er del et i ng dat a f r omappl i cat i on_i d 222 par t i t i on AR



El apsed: 00: 00: 04. 11

- Af t er del et i ng t he dat a f or one par t i t i on i ncr ement al gat her i ng st at i st i cs t ook 4. 11 sec
- Check gl obal and par t i t i on st at i st i cs


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

sel ect par t i t i on_name, t o_Char ( l ast _anal yzed, ' DD- MON- YY HH24: MI : SS' ) " l ast _anal yzed" f r omdba_Tab_par t i t i ons wher e t a
bl e_name l i ke ' XLA_AE_LI NES_BKP' ;

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AP 23- SEP- 12 07: 17: 30
AR 23- SEP- 12 07: 26: 18
CE 23- SEP- 12 07: 17: 10
CST 23- SEP- 12 07: 17: 21
DPP 23- SEP- 12 07: 17: 21
FUN 23- SEP- 12 07: 17: 12
FV 23- SEP- 12 07: 17: 10
GMF 23- SEP- 12 07: 17: 10
I GC 23- SEP- 12 07: 17: 10
I GI 23- SEP- 12 07: 17: 12
LNS 23- SEP- 12 07: 17: 10
OFA 23- SEP- 12 07: 17: 10
OKL 23- SEP- 12 07: 17: 12
OZF 23- SEP- 12 07: 17: 30
PA 23- SEP- 12 07: 17: 12
PAY 23- SEP- 12 07: 17: 12
PN 23- SEP- 12 07: 17: 12
PO 23- SEP- 12 07: 17: 10
PSB 23- SEP- 12 07: 17: 30


El apsed: 00: 00: 00. 01

Not e : st at i st i cs ar e gat her ed, l ast _anal yzed dat e i s changed f or onl y AR par t i t i on and t i mi ng has al so r educed.

19
- Wi t h t he above t est case we can see i mpr ovement i n t i mi ngs when i ncr ement al pr ef er ence i s set .

- Ti mi ng i nf or mat i on:

Pr ef er ence set Tabl e_name Oper at i on Ti mi ng
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NO xl a_ae_l i nes st at s gat her ed af t er i nser t i ng dat a f or f i r st t i me 29. 06 sec
Yes xl a_ae_l i nes st at s gat her ed af t er i nser t i ng dat a f or f i r st t i me 22. 91 sec
NO xl a_ae_l i nes st at s gat her ed af t er modi f yi ng one par t i t i on 14. 06 sec
Yes xl a_ae_l i nes st at s gat her ed af t er modi f yi ng one par t i t i on 04. 11 sec
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3. Concurrent Statistics Gathering
Concurrent statistics gathering is a new feature introduced in 11gR2. Concurrent statistics gathering is use to run stats on
multiple table and partitions concurrently. This simple example demonstrates how you might deploy the Oracle 11g
Concurrent Statistics Gathering feature in Oracle E-Business Suite.

- Concur r ent st at i st i cs gat her i ng i s cont r ol l ed by set t i ng gl obal pr ef er ence

exec DBMS_STATS. SET_GLOBAL_PREFS( ' CONCURRENT' , ' TRUE' ) ;

- To r un st at i st i cs concur r ent l y j ob_queue_pr ocesses shoul d be set t o mor e t han 4
- Test case t o gat her st at s concur r ent l y.
- Set t i ng j ob_queue_pr ocesses t o 10.

al t er syst emset j ob_queue_pr ocesses=10;

syst emal t er ed.

- Set t i ng concur r ent pr ef er ence t o FALSE

exec DBMS_STATS. SET_GLOBAL_PREFS( ' CONCURRENT' , ' FALSE' ) ;

- Del et e st at i st i cs on t he t abl e

exec dbms_st at s. del et e_t abl e_st at s( ' XLA' , ' XLA_AE_HEADERS' ) ;

- Gat her st at i st i cs usi ng f nd_st at s

exec f nd_st at s. gat her _t abl e_st at s( ' XLA' , ' XLA_AE_HEADERS' ) ;

El apsed: 00: 29: 30. 97

- Set t he gl obal pr ef er ence t o TRUE

exec DBMS_STATS. SET_GLOBAL_PREFS( ' CONCURRENT' , ' TRUE' ) ;

- Del et e t he st at i st i cs

exec dbms_st at s. del et e_t abl e_st at s( ' XLA' , ' XLA_AE_HEADERS' ) ;


- Gat her i ng St at i st i cs

exec f nd_st at s. gat her _t abl e_st at s( ' XLA' , ' XLA_AE_HEADERS' ) ;


El apsed: 00: 26: 59. 54

Resul t s of t he t est case:

Met hod Level ( schema/ t abl e) Concur r ent pr ocessi ng opt i on Ti mi ng
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FND_STATS t abl e( XLA_AE_HEADERS) FALSE 00: 29: 30. 97
FND_STATs t abl e( XLA_AE_HEADERS) TRUE 00: 26: 59. 54
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Fr omt he above t est cases, we see f nd_st at s ( wi t h par al l el opt i on, as f nd_st at s r uns by def aul t wi t h par al l el opt i on)
wi t h set t i ng gl obal pr ef er ence t o FALSE t ook 29 mi ns and 30 secs. f nd_st at s r an wi t h set t i ng gl obal pr ef er ence t o TRUE,
t ook 26 mi ns and 59 secs. We see a net gai n of 2 mi ns 5 secs i n t he gat her st at i st i cs t i mi ng. And even t hi s smal l gai n
coul d be expl ai ned by bl ocks al r eady bei ng i n cache.

20
Appendix A: Related Documentation
This appendix contains important Oracle documents, My Oracle Support Knowledge Documents and Blog references that
provide useful information.
Whitepapers
These papers are generic and do not specifically focus on Oracle E-Business Suite.
Best Practices for Gathering Optimizer Statistics
This paper provides an extensive overview of the Oracle Database statistics gathering process and is a useful precursor
to this paper. It should be considered as the source for many of the generic statements in this document. This is
available on the Oracle Optimizer blog: https://blogs.oracle.com/optimizer/ and Oracle Technet:
http://www.oracle.com/technetwork/database/bi-datawarehousing/dbbi-tech-info-optmztn-092214.html
Understanding Optimizer Statistics
This document provides more foundation information about Optimizer statistics and related topics. For example, it
includes a clear explanation of the different types of histograms and where they are applicable. This could be
considered a precursor to the Best Practices for Gathering Optimizer Statistics paper. This is available on Oracle Technet:
http://www.oracle.com/technetwork/database/focus-areas/bi-datawarehousing/twp-optimizer-stats-concepts-110711-1354477.pdf
Upgrading from Oracle Database 10g to 11g: What to expect from the Optimizer
This paper introduces the new Oracle 11g Optimizer features and outlines essential steps before and after the upgrade
in order to avoid performance regressions related to plan changes that are likely to occur. This is available on Oracle
Technet: http://www.oracle.com/technetwork/database/focus-areas/bi-datawarehousing/twp-upgrading-10g-to-11g-what-to-ex-
133707.pdf
My Oracle Support Knowledge Documents
Fixed Objects Statistics Considerations (Doc ID 798257.1)
This generic document summarizes problems including, for example, missing or bad statistics on the x$/fixed tables
that can lead to performance degradation or hangs.
Managing CBO Stats during an upgrade to Oracle 10g or Oracle 11g (Doc ID 465787.1)
The core idea presented is to continue gathering Optimizer statistics for application schemas as usual, but create a clean
baseline for non-application objects (data dictionary, fixed objects and system performance).
bde_last_analyzed.sql - Verifies CBO Statistics (Doc ID 163208.1)
This script verifies the Optimizer statistics in the data dictionary for all tables, indexes, and partitions. It also validates
the statistics on tables and indexes owned by 'SYS'.
EBPERF FAQ - Collecting Statistics with Oracle EBS 11i and R12 (Doc ID 368252.1)
This FAQ note assists with generic questions about gathering stats for Apps 11i and R12
The following My Oracle Support Knowledge Documents are useful if you are unable to apply the FND_STATS
standalone patch:
coe_stats.sql - Automates CBO Stats Gathering using FND_STATS (Doc ID 156968.1)
This interim solution provides recommendations based on the range, sample size, and collection frequency.
Blogs
21
The Oracle Optimizer blog ( https://blogs.oracle.com/optimizer ) contains excellent generic information on a number of topics
from the author of the Best Practices for Gathering Optimizer Statistics paper.
Topics include the following
Extended Statistics
Concurrent Statistics Gathering
Maintaining statistics on large partitioned tables
Fixed Objects Statistics and why they are important
In addition there are articles on other tuning related issues such as cardinality feedback.

22
Appendix B: Package Specifications
This appendix describes the Gather Table Statistics and Gather Schema Statistics programs. In both cases they attempt to
parallelize as much of the work as possible and can optionally backup the existing statistics in the FND_STATTAB table
(only if the value of the backup flag parameter is BACKUP) before gathering new statistics, ensuring that they can be
restored if necessary.
Gather Table Statistics
The Gather Table Statistics program gathers table, column and index statistics. This program calls the
FND_STATS.GATHER_TABLE_STATS package; the parameters are shown in Table B1. It is useful when collecting
statistics for very large tables that have been excluded from the main gather statistics collection due to time constraints. It is
also useful to update the statistics for a small set of tables when investigating performance of a single SQL statement.

Figure 1 :
Oracle E-Business Suite - Gather Table Statistics Concurrent Request Submission window
Figure 1 shows an example of submitting Gather Table Statistics. Note that Estimate Percent is blank; a description of the
parameters follows.
TABLE B1. FND_STATS.GATHER_TABLE_STATS PARAMETERS
PARAMETER DESCRIPTION
Owner Name The table owner.
Table Name The table name.
Estimate Percent The sampling percentage. If left blank, for 11g defaults to dbms_stats.auto_sample_size and for
23
10g and prior it the default value of 10 is used. The valid range is from 0 to 100.
Degree The degree of parallelism to be used when gathering statistics. If a Degree is not provided, it
defaults to the minimum of parallel_max_servers and cpu_count.
Partition Name The partition name.
Backup Flag Specify BACKUP to back up your statistics. (BACKUP/NOBACKUP)
Granularity
The granularity of statistics to collect (only relevant for partitioned tables). Valid values are:
DEFAULT - Gather global and partitionlevel statistics.
SUBPARTITION - Gather subpartitionlevel statistics.
PARTITION - Gather partitionlevel statistics.
GLOBAL - Gather global statistics.
ALL - Gather all (subpartition, partition, and global) statistics.
History Mode This parameter controls the number of history records. The options, which are discussed in the
History Mode section, include LASTRUN, FULL and NONE. The default is LASTRUN.
Invalidate Dependent Cursors This indicates whether dependent cursors should be invalidated. This parameter is ignored prior
to Oracle 9iR2

24
Gather Schema Statistics

The Gather Schema Statistics program gathers table, column and index statistics for every object in the schema. This
program calls the FND_STATS.GATHER_SCHEMA_STATS package; the parameters are shown in Table B2. This is the
recommended process to run in order to update Oracle E-Business Suite statistics. Various considerations are explained
throughout the main part of this paper. When the collection time exceeds the available time slot, it may be useful to exclude
very large tables and schedule these at different times.
If this procedure fails at any time during operation, supplying the request ID, for the request that failed, can restart it. The
request ID, which can be queried from the FND_STATS_HIST table, is captured when the program is started from
concurrent manager or will be automatically created if the FND_STATS.GATHER_SCHEMA_STATS is used directly or
in a custom script.

Figure 2 :
Oracle E-Business Suite - Gather Schema Statistics Concurrent Request Submission window
Figure 2 shows an example of submitting Gather Schema Statistics. Note that Estimate Percent is blank; a description of
the parameters follows.
TABLE B2: FND_STATS.GATHER_SCHEMA_STATS PARAMETERS
PARAMETER DESCRIPTION
Schema Name ALL will collect statistics for every registered Oracle E-Business Suite schema listed in
FND_PRODUCT_INSTALLATIONS table.
Estimate percent The sampling percentage. If left blank, for 11g defaults to dbms_stats.auto_sample_size and for
10g and prior it the default value of 10 is used. The valid range is from 0 to 100.
25
Degree The degree of parallelism for gathering statistics. Default value is MIN (DB init parameters:
parallel_max_servers, cpu_count).
Backup Flag Specify BACKUP to back up your statistics. (BACKUP/NOBACKUP)
Restart Request ID If the Gather Schema Statistics run failed or was stopped, it can be re-submitted with this
parameter and it will pick up where the failed run left off.
History Mode This parameter controls the number of history records. The options, which are discussed in the
History Mode section, include LASTRUN, FULL and NONE. The default is LASTRUN.
Gather Options This parameter specifies how objects are selected for statistics gathering.
GATHER (Default) - All schema tables and indexes are selected for statistics gathering.
GATHER_AUTO - Tables of the schema schemaname for which the percentage of modifications
has exceeded modpercent are selected for statistics gathering. Table monitoring needs to be
enabled before using this option.
GATHER_EMPTY - Statistics are gathered only for tables and indexes that are missing
statistics.
LIST_AUTO - It only provides a list of objects for gather statistics if GATHER_AUTO is used.
LIST_EMPTY - It only provides a list of objects for gather statistics if GATHER_EMPTY is used.
Modification Threshold This option is applicable only to GATHER AUTO and LIST AUTO options. This parameter
specifies the percentage of modifications that have to take place on a table before it can be
picked up for AUTO statistics gathering.
Invalidate Dependent Cursors This indicates whether dependent cursors should be invalidated. The default is 'Y'.

26

Best Practices for Gathering Statistics with
Oracle E-Business Suite
Aug 2013
Authors: Deepak Bhatnagar, Mohammed
Saleem, Andy Tremayne
Editor: Robert Farrington

Oracle E-Business Suite Performance Group
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 2013, Oracle and/or its affiliates. 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 and J ava are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0113

Doc1586374 A

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

Doc1586374 A

Uploaded by

Copyright:

Available Formats

An Oracle White Paper

You might also like