Search Results edw_analyze_tables




Overview
Explore in AI Chat

Overview

The concurrent program EDW_ANALYZE_TABLES belongs to the BIS – Applications BIS product family within Oracle E-Business Suite. Its documented user-facing name is Analyze Dimensions and Facts, which accurately reflects its purpose: it invokes database statistics-gathering logic against the dimension and fact tables that make up the Enterprise Data Warehouse (EDW) and Business Intelligence (BIS) schemas. In Oracle EBS 12.1.1 and 12.2.2, accurate optimizer statistics are critical to warehouse query performance, and this program centralizes the ANALYZE operation so that administrators do not have to execute statistics collection manually against each dimension and fact object.

The program is recorded in the ETRM metadata with an Enabled status of No. This indicates that the concurrent program is shipped in a disabled state by default; it must be explicitly enabled by a system administrator before it can be submitted or scheduled in the environment. This is common for maintenance and DBA-oriented programs that are intended to be run deliberately rather than as part of routine transactional processing.

Execution Details

The documented execution attributes for EDW_ANALYZE_TABLES are as follows:

  • Execution Method: PL/SQL Stored Procedure
  • Argument Method: Standard
  • Executable: EDW_ANALYZE_TABLES
  • Execution File: EDW_ANALYZE_TABLES.Analyze_All
  • Subroutine Name: (not specified)

The execution file path EDW_ANALYZE_TABLES.Analyze_All shows that the program calls the Analyze_All procedure inside the EDW_ANALYZE_TABLES PL/SQL package. Because the execution method is PL/SQL Stored Procedure, the concurrent manager runs the packaged procedure directly through the database rather than launching an external executable or host script. The Standard argument method means the procedure draws its arguments from the concurrent program's defined parameter list, using the standard Oracle Reports/Concurrent argument convention.

How to Run

As a standard concurrent program, EDW_ANALYZE_TABLES is submitted through the Submit Requests (SRS) window in Oracle EBS. Because the program is shipped disabled, an administrator must first navigate to System Administrator > Concurrent > Program > Define, query the program, and set the Enabled flag to Yes. Once enabled, it appears in the list of available requests for the responsibility under which it was assigned.

Typical submission operates as follows:

  • Choose a run-once submission or schedule the program to recur, for example during nightly maintenance windows when warehouse activity is low.
  • Because statistics gathering can be resource-intensive, submissions should be confined to off-peak periods, and the request should be monitored through the Requests window for completion status.
  • Review any log or output generated by the Analyze_All procedure to confirm that dimension and fact objects were analyzed without error.

The ETRM metadata documents a Standard argument method, so parameters follow the conventional conflict-resolution and print options rather than a bespoke parameter set. Where parameters exist in an implementation, they are governed by the program definition rather than by the program's name or description.

Related Objects

The program operates across the EDW and BIS schemas, so its natural companions are the underlying warehouse tables. Related objects commonly associated with statistics maintenance of this kind include:

  • Dimension tables and fact tables in the EDW/BIS schema, which are the direct targets of the analysis.
  • Dictionary statistics views and DBMS_STATS-based collection routines that Oracle EBS uses for optimizer statistics.
  • Warehouse load and refresh programs in the BIS module, which should complete before statistics are refreshed.
  • Concurrent programs managing table statistics elsewhere in EBS, such as Gather Schema Statistics, with which this program's operation may need to be coordinated.

Administrators should coordinate execution with other statistics-gathering jobs to avoid overlap and to ensure the optimizer receives consistent data across the warehouse.