Search Results alert_check_id




Overview
Explore in AI Chat

Overview

The ALR_ACTION_SET_CHECKS table is a core transactional table within the Oracle E-Business Suite (EBS) Alerts module. It functions as a detailed execution log and control mechanism for alert actions. When a periodic alert's check is performed, this table records the outcome and associates that specific check instance with the corresponding set of actions to be executed. It serves as the critical link between an alert check (ALR_ALERT_CHECKS) and the subsequent action sets (ALR_ACTION_SETS), enabling the system to track which actions were triggered by which specific data verification event. Its role is essential for the audit trail, performance monitoring, and ensuring actions are not erroneously repeated.

Key Information Stored

The table stores metadata and results for each execution cycle of an alert's action set. Key columns include the composite primary key (APPLICATION_ID, CHECK_ID), which uniquely identifies each logged check instance. The ALERT_CHECK_ID column, which the user specifically searched for, is a foreign key to ALR_ALERT_CHECKS, linking back to the definition of the check that was run. Other critical columns are ALERT_ID and ACTION_SET_ID, which identify the parent alert and the specific action set invoked. The SUCCESS_FLAG indicates the pass/fail status of the check, while ROW_COUNT and ACTION_COUNT can store metrics about the number of database rows returned by the check and the number of actions processed, respectively. ORACLE_ID links to the database user (FND_ORACLE_USERID) under which the check was executed.

Common Use Cases and Queries

Primary use cases involve troubleshooting alert execution, generating audit reports, and analyzing alert performance. Administrators often query this table to verify that alerts are running, diagnose failures, or understand historical execution patterns. A common query retrieves the execution history for a specific alert, joining to related tables for context:

  • Identifying recent failed checks: SELECT * FROM alr_action_set_checks WHERE success_flag = 'N' ORDER BY check_id DESC;
  • Correlating checks with their parent alert and action set: SELECT aasc.check_id, aasc.alert_id, aasc.alert_check_id, aasc.success_flag, aasc.row_count FROM alr_action_set_checks aasc WHERE aasc.alert_id = <alert_id>;
  • Analyzing execution volume: SELECT alert_id, COUNT(*) execution_count, MIN(check_id) first_check, MAX(check_id) last_check FROM alr_action_set_checks GROUP BY alert_id;

Related Objects

The table sits at the center of a key relationship network within the Alerts schema. It references several master definition tables via foreign keys: FND_PRODUCT_INSTALLATIONS (APPLICATION_ID), ALR_ALERTS (APPLICATION_ID, ALERT_ID), ALR_ACTION_SETS (APPLICATION_ID, ACTION_SET_ID), ALR_ALERT_CHECKS (APPLICATION_ID, ALERT_CHECK_ID), and FND_ORACLE_USERID (ORACLE_ID). Crucially, it is referenced by multiple transactional history tables, which store the detailed output and data from the executed actions. These include ALR_ACTION_DATA, ALR_ACTION_HISTORY, ALR_ACTUAL_RESPONSES, and ALR_OUTPUT_HISTORY, all linking via APPLICATION_ID and CHECK_ID. This structure ensures a complete chain of custody from alert definition to check execution to action output.