Search Results get_log_spec

Overview

SYS.DBMS_CUBE_LOG is the Oracle-supplied interface to the OLAP logging infrastructure within the database. In the context of Oracle E-Business Suite 12.1.1 and 12.2.2, this package provides the PL/SQL API through which OLAP engine activity — cube builds, dimension compiles, rejected-record handling, and general operations — is recorded, traced, and diagnosed. It is declared with AUTHID CURRENT_USER, meaning that name resolution and privilege checking for its SQL operations execute under the calling schema rather than under SYS. Because it belongs to the SYS schema and is documented as an OTHER-classification API, it is not an EBS application-tier object; it is a database kernel utility invoked by EBS components such as the OLAP-based planning, budgeting, and analytic features that depend on the database OLAP option.

The package is visible to all users per its own header documentation. It does not implement business logic itself. Instead, it centralizes the configuration of where and how OLAP log messages are emitted, at what verbosity, and under which query environment, so that cube maintenance operations performed by EBS background processes can be audited consistently.

Key Procedures and Functions

The package exposes 36 documented units. The most significant are grouped below.

• Lifecycle control: ENABLE and DISABLE turn the logging subsystem on and off; FLUSH forces buffered log content to its configured destination.
• Configuration: SET_LOG_SPEC and GET_LOG_SPEC define and retrieve the active logging specification (log type, target, and level); SET_PARAMETER and GET_PARAMETER manage individual log parameters; SET_QUERY_ENV establishes the query environment used to capture execution context; DEFAULT_NAME supplies a conventional log name.
• Content access: GET_LOG returns the accumulated log content; WRITE_TO_OPLOG writes an entry directly to the operations log.
• Operation bracketing: START_OPLOG and COMPLETE_OPLOG mark the beginning and successful end of a logged operation, providing duration and outcome context for cube activity.
• Physical setup and metadata: TABLE_CREATE creates the underlying log table; VERSION returns the package version.
• Type and target constants: TYPE_OPERATIONS, TYPE_REJECTED_RECORDS, TYPE_DIMENSION_COMPILE, and TYPE_BUILD identify the logging categories, corresponding to the BINARY_INTEGER constants TYPE_OPERATIONS_C (1), TYPE_REJECTED_RECORDS_C (2), TYPE_DIMENSION_COMPILE_C (3), and TYPE_BUILD_C (4). TARGET_TABLE mirrors the log-target constants (table, trace, file, LOB), and the level constants range from LEVEL_LOWEST_C through LEVEL_HIGHEST_C, with named verbosity aliases VERBOSE_ACTION_C through VERBOSE_DEBUG_C.

All enumerated constants — including the log table version identifiers OPERATIONS_V112, REJECTED_RECORDS_V112, DIMENSION_COMPILE_V112, and the BUILD versions — are declared as BINARY_INTEGER, which is why a search on that datatype surfaces this package.

Tables Accessed

No tables are documented as referenced through APPS synonyms, and the metadata records no dependencies from other packages. The package operates on log tables that it can create itself via TABLE_CREATE, and it writes operation, rejected-record, dimension-compile, and build entries into those structures or into the alternative targets (trace, file, or LOB) selected through the log specification. All such access executes under the invoker's schema because of AUTHID CURRENT_USER.

Usage Notes

DBMS_CUBE_LOG is typically invoked indirectly. During an EBS OLAP operation such as a cube build or dimension compile, the executing session calls START_OPLOG, performs the work, and calls COMPLETE_OPLOG, relying on ENABLE/FLUSH/GET_LOG to persist and retrieve diagnostics. During implementations and troubleshooting, DBAs and developers call SET_LOG_SPEC and SET_PARAMETER from SQL*Plus or custom scripts to raise verbosity temporarily and route output to a table, trace, file, or LOB. No EBS form or concurrent program is documented as a direct caller, so custom code touching this package should restrict itself to the documented interface and avoid the internal versioned constants, which are subject to change between releases.