Search Results dg_broker_info




Overview
Explore in AI Chat

Overview

SYS.DBMS_DRS is the PL/SQL interface to the Disaster Recovery (DR) Server, historically referred to as the Hot Standby subsystem of the Oracle database. Within Oracle E-Business Suite 12.1.1 and 12.2.2, this package is owned by the SYS schema and is classified as a general-purpose ("OTHER") API rather than an EBS application-tier API. Its business function is to expose the control surface of the Data Guard / DR Server so that external callers — including EBS High Availability tooling, database administrators, and orchestration scripts — can query status, drive role transitions, and monitor standby health through a supported, documented programmatic entry point rather than by manipulating internal Data Guard tables directly.

The package implements a deliberate two-mode design. Every major operation is offered either as a blocking procedure, which does not return until the command has completed, or as a non-blocking function, which queues the request, returns a request identifier immediately, and allows the caller to retrieve the result later. This distinction is significant in an EBS environment, where a failover or state-change command can take many minutes and must not hold an online user session or a concurrent manager worker open indefinitely.

Key Procedures and Functions

The ETRM metadata documents twenty callable units in the package. The principal ones are:

  • DO_CONTROL and DO_CONTROL_RAW — the core control entry points. They accept an incoming document type, as defined in the DR Server API design specification, which describes the command to be executed. The non-blocking form of DO_CONTROL enqueues the request and returns a request identifier; the only failure it raises is inability to enqueue. The blocking form waits for completion before returning the first piece of the outgoing document.
  • GET_RESPONSE and GET_RESPONSE_RAW — retrieve the outgoing document produced by a previously submitted request. Outgoing documents are returned piecewise, with all initial requests expected to ask for piece=1 and subsequent calls walking the remaining pieces.
  • GET_PROPERTY and GET_PROPERTY_OBJ — return individual configuration or status properties from the DR Server. GET_PROPERTY returns a scalar value; GET_PROPERTY_OBJ returns the property as an object. Unlike the document-driven control procedures, these are simple blocking calls that do not queue a request.
  • DELETE_REQUEST and CANCEL_REQUEST — housekeeping procedures. Once all pieces of an outgoing document have been consumed, the caller must invoke DELETE_REQUEST to release the request. CANCEL_REQUEST aborts a request that has not yet completed.
  • DG_BROKER_INFO — reports Data Guard broker configuration and status information.
  • READYTOFAILOVER, STATECHANGERECORDED, INITIATE_FS_FAILOVER, and FS_FAILOVER_FOR_HC_COND — health-check and failover orchestration routines used to determine readiness and to drive fast-start failover transitions.
  • PING, SLEEP, and DUMP_META — diagnostic and liveness utilities; PING verifies the DR Server is responsive, SLEEP introduces a controlled delay, and DUMP_META emits internal metadata for troubleshooting.

Tables Accessed

The ETRM metadata records no application tables referenced through APPS synonyms for this package. This is consistent with its role: DBMS_DRS operates against the DR Server and Data Guard broker infrastructure in the SYS schema, communicating through the request queue and internal DR metadata rather than through EBS business tables. Because the package exposes no APPS-synonym dependencies, it carries no direct coupling to the EBS data model.

Usage Notes

DBMS_DRS is not an EBS application API and is not invoked by standard EBS forms or concurrent programs. It is called from the database tier — by DBA scripts, Data Guard broker automation, or custom monitoring code — when an installation requires programmatic visibility into or control over the standby configuration. The package is referenced by one other package, indicating internal reuse within the SYS namespace.

In practice, callers should prefer GET_PROPERTY and GET_PROPERTY_OBJ for read-only status queries, since these are simple blocking calls with minimal overhead. For any operation that may be long-running — failover initiation, state changes, or broker control — the non-blocking DO_CONTROL form should be used, followed by GET_RESPONSE to collect the output document and DELETE_REQUEST to release the request identifier. Omitting the delete step leaves orphaned entries in the request queue. Because the package is owned by SYS and is unsupported for direct EBS customization, any invocation from custom code should be wrapped with appropriate exception handling and restricted to privileged database accounts.