1Z0-184-25 Question 136
Single answerYou are building a PL/SQL-based RAG (Red, Amber, Green) application in an Autonomous Database on Oracle Cloud Infrastructure (OCI). The application needs to calculate a daily status color for each service based on performance metrics (e.g., availability). Thresholds for Red (<80%), Amber (80%�95%), and Green (>95%) must be easily adjustable without redeploying code. Which approach should you use to ensure maintainability and concurrency control as you update these thresholds over time?
- A
Hardcode the threshold values directly in a single PL/SQL procedure and redeploy whenever they change.
- B
Store the thresholds in a dedicated configuration table and reference them from a PL/SQL function that locks rows during updates.
- C
Use a package-level constant for each threshold so that they can be more easily maintained in your OCI environment.
- D
Define threshold values in environment variables at the session level to avoid any DDL changes in the database.
Show answer and explanation
Correct answer: B
Explanation
The recommended best practice is to separate RAG threshold logic from the main PL/SQL code by using a configuration table. This allows for updating thresholds without modifying or redeploying the PL/SQL packages or procedures. Employing row-level locking (e.g., SELECT FOR UPDATE) when making adjustments ensures that no concurrent sessions read outdated or partially updated thresholds. Refer to the Oracle Autonomous Database documentation on PL/SQL concurrency and schema design for guidance on implementing this pattern.
- A. Incorrect.
Incorrect: Hardcoding thresholds within the procedure forces code changes and redeployment for every threshold adjustment. This is impractical and error-prone.
- B. Correct.
Correct: Storing thresholds in a dedicated configuration table allows you to change them without altering the PL/SQL code, and row-level locking helps ensure proper concurrency control when these values are updated.
- C. Incorrect.
Incorrect: While package-level constants can be more visible than hardcoded literals, changing them still requires a package recompile and redeploy, making threshold adjustments cumbersome.
- D. Incorrect.
Incorrect: Session-level environment variables are not globally maintained or automatically enforced across all sessions. This makes concurrency control difficult and can lead to inconsistent threshold usage if sessions differ.