3 Customer Responsibilities

The primary custom schema in RDS is a powerful, writable environment that enables you to extend Oracle Retail Cloud Services. With this flexibility comes responsibility. As the schema owner, you are accountable for the performance, reliability, and behavior of your extensions.

This chapter outlines the key responsibilities that ensure your extensions remain performant, maintainable, and compliant with the RDS operational model.

Performance and Scalability

You are responsible for ensuring that all custom services and queries operate within acceptable performance boundaries.

  • Query Duration Limits: All operations must complete in 300 seconds or less. Ideal baseline performance should be under 150 seconds.
  • Traffic Intensity: Estimate request arrival rates and average processing time to avoid overload.
  • Baseline Testing: Collect timing metrics under representative workloads for all services and reports.
  • Scalability Awareness: RDS has finite resources. Excessive CPU consumption or session usage can affect availability.

Resource Monitoring

You are expected to monitor and manage consumption of your schema’s allocated resources.

  • Session Management: Use the DB Ops Console to identify and terminate runaway, idle, or zombie sessions.
  • CPU and Storage: Track utilization and proactively request increased capacity when needed.
  • Efficiency: Optimize queries and background jobs to minimize resource usage.

Maintenance Preparedness

Custom objects may become invalid during RDS maintenance when underlying views or dependencies are dropped and recreated. Maintenance preparedness helps prevent downtime and ensures a smooth return to service.

Pre-Maintenance Responsibilities

  1. Notify Users: Let users know in advance to reduce disruption and prevent long-running or orphaned sessions.
  2. Disable Custom Jobs: Suspend scheduled jobs (for example, DBMS_SCHEDULER) to avoid interference during maintenance.
  3. Suspend External Orchestration: Pause external workflows that target RDS to avoid unexpected connections.
  4. Terminate Active Sessions: Ensure that no active sessions are holding locks on custom objects. Locked objects within dependency chains can cause recompilation failures.

Post-Maintenance Responsibilities

  1. Check for Lingering Sessions: Ensure no sessions are preventing recompilation or consuming resources unnecessarily.
  2. Handle Invalid Objects: Invalid custom objects may remain after maintenance due to:
    1. Long dependency chains, where objects must be compiled in order.
    2. Locked objects, which prevent successful recompilation.
    3. Timeouts, if recompilation takes too long or encounters blocked dependencies.
    4. You are responsible for resolving invalids in your schema. Refer to the RDS Compile Invalids Reference Paper (Doc ID 2899701.1) for instructions on resolving these issues.
  3. Notify Users: Let users know that RDS is available again and safe to resume work.
  4. Re-enable Jobs and Workflows: Restart any disabled jobs or paused orchestration processes.

Extension Management

Your primary custom schema is fully writable, and you are responsible for managing everything created within it.

  • Custom Object Ownership: All custom tables, views, packages, and procedures reside in your schema.
  • Cross-Schema Access: Other schemas do not have access to your objects unless explicitly granted.
  • Security and Governance: Apply least privilege principles and use views to control access when necessary.
  • Resilience: Design extensions to handle failure scenarios and resume cleanly after terminations.

  • Grants: You are responsible for managing grants on replicated objects in RDS_CUSTOM_1/2/3. See Grants to Auxiliary Workspace Schema.

Communication with Oracle

Proactive communication with Oracle Support helps ensure system stability and availability, especially during non-routine operations.

Examples of when to notify Oracle:

  • High-volume data events, such as store rollouts or data migrations.
  • Custom retention strategies, such as large-scale archiving.
  • Extended integration testing, especially if it may impact system load or replication.