1Z0-184-25 Question 138
Single answerYou are developing a RAG (Red-Amber-Green) performance dashboard in an Autonomous Database on Oracle Cloud Infrastructure. The application uses a PL/SQL package to compute RAG statuses for each new row inserted into a PERFORMANCE_METRICS table. You need to ensure that these RAG statuses are updated in real time without excessive overhead. Which approach meets this requirement effectively?
- A
Use an AFTER ROW trigger on PERFORMANCE_METRICS that calls the PL/SQL package to compute RAG upon new inserts.
- B
Rely on a daily scheduled job that runs the PL/SQL package to update RAG statuses once every 24 hours.
- C
Use an INSTEAD OF trigger on a view referencing PERFORMANCE_METRICS to compute RAG statuses upon DML operations.
- D
Load the data into a temporary staging table first, then manually run the PL/SQL package to update main table RAG statuses.
Show answer and explanation
Correct answer: A
Explanation
To maintain real-time accuracy of RAG statuses with minimal overhead, an AFTER ROW trigger is typically used in conjunction with PL/SQL logic. This approach calls the required package immediately upon each insert, ensuring timely updates. Refer to Oracle documentation on trigger best practices (in particular, Autonomous Database PL/SQL Trigger Creation guidelines) for implementation details and performance considerations.
- A. Correct.
Correct. An AFTER ROW trigger on the PERFORMANCE_METRICS table ensures that every new row is processed in real time, updating RAG statuses immediately. It automatically invokes the PL/SQL package whenever a new record is inserted, aligning with best practices for timely data validation in Autonomous Database environments.
- B. Incorrect.
Incorrect. A daily scheduled job delays the RAG computation until the next run, which could result in outdated statuses for most of the day. This fails the real-time requirement.
- C. Incorrect.
Incorrect. An INSTEAD OF trigger is used on views when a direct DML on that view is required. In this scenario, DML is happening directly on the PERFORMANCE_METRICS table, so AFTER ROW triggers on the actual table are more appropriate and simpler to manage.
- D. Incorrect.
Incorrect. Manually running the PL/SQL package introduces operational overhead and risks forgetting or delaying the update. It does not provide automated, real-time status computation compared to using a database trigger.