Search Results ghr_process_log_pk




Overview

HR.GHR_PROCESS_LOG is a transactional log table in the Oracle E-Business Suite HR schema that captures diagnostic and status information produced by batch and concurrent processes. According to the ETRM metadata, the table "contains log information about various batch process like Auto WGI, future action processing and mass actions." It therefore serves as a central audit and troubleshooting repository for the Oracle Human Resources (GHR) family of processes, storing one row per logged event generated during execution of those programs.

The object resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, reflecting its role as a high-volume transactional table subject to ongoing inserts rather than reference data. It is registered under FND Design Data as GHR.GHR_PROCESS_LOG and reports a status of VALID across EBS 12.1.1 and 12.2.2.

From a Data Vault modeling perspective, the metadata classifies this object as standalone. This heuristic suggests the table be modeled as an isolated satellite or raw log entity, since it declares no foreign key dependencies on other database objects and contains only its own surrogate key plus descriptive payload. No parent hub or linking relationship is documented.

Key Information Stored

The table comprises ten documented columns. The surrogate primary key is PROCESS_LOG_ID, a NUMBER generated from the sequence GHR_PROCESS_LOG_S. It is the sole unique index candidate (GHR_PROCESS_LOG_PK), and because no distinct business-key unique index is documented, PROCESS_LOG_ID also serves as the only determinative identifier for a row. The remaining columns fall into two functional groups:

The composite non-unique index GHR_PROCESS_LOG_N1 spans PROGRAM_NAME, LOG_DATE, and MESSAGE_NAME, confirming that the dominant access pattern filters log entries by program within a date range and by message type.

Common Use Cases and Queries

Typical use cases include troubleshooting failed or partial batch runs (Auto WGI, future action processing, mass actions), auditing process history for a given date, and reporting on recurring error conditions by message name. Because LOG_TEXT preserves program output, support analysts frequently query it to reconstruct what occurred during a run.

The primary access path uses the GHR_PROCESS_LOG_N1 index. A representative query is:

  • SELECT PROCESS_LOG_ID, PROGRAM_NAME, MESSAGE_NAME, LOG_DATE, LOG_TEXT FROM HR.GHR_PROCESS_LOG WHERE PROGRAM_NAME = :p_program AND LOG_DATE BETWEEN :p_start AND :p_end ORDER BY LOG_DATE;
  • To isolate error entries for a program, filter on MESSAGE_NAME IS NOT NULL.
  • To retrieve a specific entry, query by the surrogate key: WHERE PROCESS_LOG_ID = :p_id.

Reporting extracts commonly aggregate by PROGRAM_NAME and MESSAGE_NAME to trend error frequency over time.

Related Objects

The ETRM dependency data shows that HR.GHR_PROCESS_LOG does not reference any database object, consistent with its standalone classification. It is referenced only by GHR_PROCESS_LOG#, the Oracle-generated synonym or editioning companion for the base table. No foreign-key join columns to other tables are documented. Consequently, integration with the surrounding GHR application is achieved functionally — via the batch programs identified in PROGRAM_NAME rather than declarative referential constraints — so related logic is best confirmed through the GHR concurrent program definitions and the GHR_PROCESS_LOG_S sequence that feeds PROCESS_LOG_ID.