oracle advanced queuing что такое
Oracle advanced queuing что такое
Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
Message Queuing in Oracle Database 19c
Oracle Advanced Queuing (AQ) provides enterprise message functionality across many industries and is widely used within the database itself. AQ supports both persistent and non-persistent messages, and AQ queues can be set up under different queuing models such as point-to-point and publish-subscribe to let business applications communicate with each other flexibly and reliably.
AQ asynchronously notifies interested clients about messages and database events. Messages can be asynchronously propagated between queues on the same or different databases
Interfaces to AQ include PL/SQL, JMS 1.1, JDBC, ODP.NET and OCI. Oracle WebLogic Server applications interoperate with AQ through the JMS API.
By being integrated with the database, AQ allows enqueues and dequeues to be automatically committed at the same time as other database operations without requiring the overhead of two-phase commit or XA interfaces. Standard SQL can query messages and their metadata. Indexes can be used to optimize access to messages. All operational benefits of the Oracle database such as high availability, scalability, security and reliability are applicable to the messages and queues in AQ. Oracle Dataguard, RAC, Enterprise Manager, and other Oracle technologies can be used with AQ.
For an overview on AQ and a short tutorial, please look at the following whitepaper:
What’s New in Oracle Database 19c: AQ Sharded Queues
AQ Sharded Queues are high-performance, scalable database queues that are designed to work well in single-instance databases, RAC databases, or Exadata database machines. Sharded Queues have optimizations for JMS, large numbers of subscribers, and scalability across RAC instances.
AQ Sharded Queues make it simpler to build and deploy Microservices with transactional messaging. Asynchronous Messaging is essential for Microservices, which are defined as loosely coupled service-oriented architectures with bounded contexts. Typically, synchronous communication with blocking REST APIs is an impediment to scaling Microservices architectures.
For details on AQ-JMS Sharded Queue performance, please look at the following whitepaper:
Oracle advanced queuing что такое
Transactional Event Queue (TEQ) and Advanced Queuing (AQ) stores user messages in abstract storage units called queues. When web, mobile, IoT, and other data-driven and event-driven applications stream events or communicate with each other as part of a workflow, producer applications enqueue messages and consumer applications dequeue messages.
At the most basic level of queuing, one producer enqueues one or more messages into one queue. Each message is dequeued and processed once by one of the consumers. A message stays in the queue until a consumer dequeues it or the message expires. A producer can stipulate a delay before the message is available to be consumed, and a time after which the message expires. Likewise, a consumer can wait when trying to dequeue a message if no message were available. An agent program or application could act as both a producer and a consumer.
Producers can enqueue messages in any sequence. Messages are not necessarily dequeued in the order in which they are enqueued. Messages can be enqueued without being dequeued.
At a slightly higher level of complexity, many producers enqueue messages into a queue, all of which are processed by one consumer. Or many producers enqueue messages, each message being processed by a different consumer depending on type and correlation identifier.
Enqueued messages are said to be propagated when they are reproduced on another queue, which can be in the same database or in a remote database.
Transactional Event Queues Leverage Oracle Database
Oracle Transactional Event Queues (TEQ) provide database-integrated message queuing functionality. This highly optimized and partitioned implementation leverages the functions of Oracle database so that producers and consumers can exchange messages with high throughput, by storing messages persistently, and propagate messages between queues on different databases. Oracle Transactional Event Queues (TEQ) are a high performance partitioned implementation with multiple event streams per queue, while Advanced Queuing (AQ) is a disk-based implementation for simpler workflow use cases.
Naming nomenclature for TEQ and AQ in Oracle Database Release 20c are as follows:
AQ buffered queues
You can decide about which queue to use as follows:
For buffered messages use AQ buffered queues.
For persistent messages, use the high performance Transactional Event Queues.
If you are currently using AQ classic queues, then consider moving to Transactional Event Queues with one event stream (to preserve total ordering in the queue) or consider taking advantage of multiple event streams where messages are ordered within each event stream. This is similar to Apache Kafka’s approach of Topics consisting of multiple partitions to which producers and consumers can publish to or subscribe from.
AQ sharded queues are being deprecated in this release.
Because TEQs are implemented in database tables, all operational benefits of high availability, scalability, and reliability are also applicable to queue data. Standard database features such as recovery, restart, and security are supported by TEQ. You can use standard database development and management tools to monitor queues. Like other database tables, queue tables can be imported and exported. Similarly, TEQ queues are supported by Oracle Data Guard for high availability, which can be critical to preserve messages when using a stateless middle tier. By being in the database, enqueues and dequeues can be incorporated in database transactions without requiring distributed transactions
Messages can be queried using standard SQL. This means that you can use SQL to access the message properties, the message history, and the payload. With SQL access you can also audit and track messages. All available SQL technology, such as in-memory latches, table indices, are used to optimize access to messages in TEQ and AQ.
TEQ and AQ do not support data manipulation language (DML) operations on a queue table, or associated index-organized table (IOT) for AQ, or associated system-partitioned tables used by TEQs, if any. The only supported means of modifying queue tables is through the supplied APIs. Queue tables and IOTs can become inconsistent and therefore effectively ruined, if DML operations are performed on them.
System-Level Access Control
TEQ and AQ support system-level access control for all queuing operations, allowing an application developer or DBA to designate users as queue administrators. A queue administrator can invoke TEQ or AQ administrative and operational interfaces on any queue in the database. This simplifies administrative work because all administrative scripts for the queues in a database can be managed under one schema.
Queue-Level Access Control
TEQ and AQ support queue-level access control for enqueue and dequeue operations. This feature allows the application developer to protect queues created in one schema from applications running in other schemas. The application developer can grant only minimal access privileges to applications that run outside the queue schema.
Requests for service must be separated from the supply of services to increase efficiency and enable complex scheduling. TEQ and AQ deliver high performance as measured by:
Number of messages and bytes enqueued and dequeued each second (messages/second and MB/second)
Time to evaluate a complex query on a message warehouse
Time to recover and restart the messaging process after a failure
Queuing systems must be scalable. TEQ and AQ deliver high performance when the number of programs using the application increases, when the number of messages increases, and when the size of the message warehouse increases.
Persistence for Security
Messages that constitute requests for service must be stored persistently and processed exactly once for deferred execution to work correctly in the presence of network, computer, and application failures. TEQ and AQ can meet requirements in the following situations:
Applications do not have the resources to handle multiple unprocessed messages arriving simultaneously from external clients or from programs internal to the application.
Communication links between databases are not available all the time or are reserved for other purposes. If the system falls short in its capacity to deal with these messages immediately, then the application must be able to store the messages until they can be processed.
External clients or internal programs are not ready to receive messages that have been processed.
Persistence for Scheduling
Queuing systems must deal with priorities, and those priorities can change:
Messages arriving later can be of higher priority than messages arriving earlier.
Messages may wait for later messages before actions are taken.
The same message may be accessed by different processes.
Messages in a specific queue can become more important, and so must be processed with less delay or interference from messages in other queues.
Messages sent to some destinations can have a higher priority than others.
Persistence for Accessing and Analyzing Metadata
Queuing systems must preserve message metadata, which can be as important as the payload data. For example, the time that a message is received or dispatched can be crucial for business and legal reasons. With the persistence features of TEQ and AQ, you can analyze periods of greatest demand or evaluate the lag between receiving and completing an order.
Object Type Support
TEQ and AQ also support ANYDATA queues, which enable applications to enqueue different message types in a single queue. TEQ and AQ support the LONG VARCHAR data type.
If you plan to enqueue, propagate, or dequeue user-defined type messages, then each type used in these messages must exist at every database where the message can be enqueued in a queue. Some environments use directed networks to route messages through intermediate databases before they reach their destination. In such environments, the type must exist at each intermediate database, even if the messages of this type are never enqueued or dequeued at a particular intermediate database.
In addition, the following requirements must be met for such types:
Type name must be the same at each database.
Type must be in the same schema at each database.
Shape of the type must match exactly at each database.
Type cannot use inheritance or type evolution at any database.
Type cannot contain varrays, nested tables, LOBs, rowids, or urowids.
The object identifier need not match at each database.
Structured and XMLType Payloads
You can use object types to structure and manage message payloads. Relational database systems in general have a richer typing system than messaging systems. Because Oracle Database is an object-relational database system, it supports traditional relational and user-defined types. Many powerful features are enabled because of having strongly typed content, such as content whose format is defined by an external type system. These include:
TEQ and AQ can examine the content and automatically route the message to another queue based on the content.
A publish and subscribe system is built on top of a messaging system so that you can create subscriptions based on content.
The ability to run queries on the content of the message enables message warehousing.
Store any type of message in a queue
Store m ore than one type of payload in a queue
Query XMLType columns using the operator ExistsNode()
Specify the operators in subscriber rules or dequeue conditions
Integration with Oracle Internet Directory
You can register system events, user events, and notifications on queues with Oracle Internet Directory. System events are database startup, database shutdown, and system error events. User events include user log on and user log off, DDL statements (create, drop, alter), and DML statement triggers. Notifications on queues include OCI notifications, PL/SQL notifications, and e-mail notifications.
You can also create aliases for TEQ and AQ agents in Oracle Internet Directory. These aliases can be specified while performing TEQ and AQ enqueue, dequeue, and notification operations. This is useful when you do not want to expose an internal agent name.
Transactional Event Queues (TEQ) does not support OCI and thick drivers.
Support for Oracle Real Application Clusters(Oracle RAC)
Oracle Real Application Clusters can be used to improve TEQ and AQ performance by allowing different queues (and event streams in the case of TEQ) to be managed by different instances. You do this by specifying different instance affinities (preferences) for the queue tables that store the queues. This allows queue operations (enqueue and dequeue) on different queues to occur in parallel. TEQs are recommended for applications with enqueuers or dequeuers on multiple Oracle RAC instances. Refer to Transactional Event Queues and Oracle Real Application Clusters (Oracle RAC) for more information.
If compatibility is set to Oracle8 i release 8.1.5 or higher, then an application can specify the instance affinity for a queue table. When TEQ and AQ is used with Oracle RAC and multiple instances, this information is used to partition the queue tables between instances for queue-monitor scheduling and, also for propagation. The queue table is monitored by the queue monitors of the instance specified by the user. If the owner of the queue table is terminated, then the secondary instance or some available instance takes over the ownership for the queue table.
If an instance affinity is not specified, then the queue tables are arbitrarily partitioned among the available instances. This can result in pinging between the application accessing the queue table and the queue monitor monitoring it. Specifying the instance affinity prevents this, but does not prevent the application from accessing the queue table and its queues from other instances.
Transactional Event Queues and Advanced Queuing in Integrated Application Environments
Figure 1-1 Integrated Application Environment Using TEQ and AQ
Description of «Figure 1-1 Integrated Application Environment Using TEQ and AQ»
Messages are exchanged between a client and the Oracle Database server or between two Oracle Database servers using Oracle Net Services. Oracle Net Services also propagates messages from one Oracle Database queue to another. Or, as shown in Figure 1-1, you can perform TEQ and AQ operations over the Internet using HTTP(S). In this case, the client, a user or Internet application, produces structured XML messages. During propagation over the Internet, Oracle Database servers communicate using structured XML also.
Application integration also involves the integration of heterogeneous messaging systems. Oracle Database Advanced Queuing seamlessly integrates with existing non-Oracle Database messaging systems like IBM WebSphere MQ through Messaging Gateway, thus allowing existing WebSphere MQ-based applications to be integrated into an Oracle Database Advanced Queuing environment. Oracle Transactional Event Queues can interoperate with Apache Kafka using a Kafka JMS connector. TEQ can also work with a Kafka Java client. Both capabilities are described in Kafka Java Client Interface for Oracle Transactional Event Queues.
Transactional Event Queues and Advanced Queuing Client/Server Communication
In this example Application B (a server) provides service to Application A (a client) using a request/response queue.
Figure 1-2 Client/Server Communication Using TEQ and AQ
Description of «Figure 1-2 Client/Server Communication Using TEQ and AQ»
Application A enqueues a request into the request queue. In a different transaction, Application B dequeues and processes the request. Application B enqueues the result in the response queue, and in yet another transaction, Application A dequeues it.
The client need not wait to establish a connection with the server, and the server dequeues the message at its own pace. When the server is finished processing the message, there is no need for the client to be waiting to receive the result. A process of double-deferral frees both client and server.
Multiconsumer Dequeuing of the Same Message
To allow for subscriber and recipient lists, the queue must reside in a queue table that is created with the multiple consumer option. Each message remains in the queue until it is consumed by all its intended consumers.
Multiple consumers, which can be either applications or other queues, can be associated with a queue as subscribers. This causes all messages enqueued in the queue to be made available to be consumed by each of the queue subscribers. The subscribers to the queue can be changed dynamically without any change to the messages or message producers.
You cannot add subscriptions to single-consumer queues or exception queues. A consumer that is added as a subscriber to a queue is only able to dequeue messages that are enqueued after the subscriber is added. No two subscribers can have the same values for name, address, and protocol. At least one of these attributes must be different for two subscribers.
It cannot be known which subscriber will dequeue which message first, second, and so on, because there is no priority among subscribers. More formally, the order of dequeuing by subscribers is indeterminate.
Subscribers can also be rule-based. Similar in syntax to the WHERE clause of a SQL query, rules are expressed in terms of attributes that represent message properties or message content. These subscriber rules are evaluated against incoming messages, and those rules that match are used to determine message recipients.
In Figure 1-3, Application B and Application C each need messages produced by Application A, so a multiconsumer queue is specially configured with Application B and Application C as queue subscribers. Each receives every message placed in the queue.
Figure 1-3 Communication Using a Multiconsumer Queue
Description of «Figure 1-3 Communication Using a Multiconsumer Queue»
A message producer can submit a list of recipients at the time a message is enqueued into a TEQ or AQ queue. This allows for a unique set of recipients for each message in the queue. The recipient list associated with the message overrides the subscriber list associated with the queue, if there is one. The recipients need not be in the subscriber list. However, recipients can be selected from among the subscribers.
A recipient can be specified only by its name, in which case the recipient must dequeue the message from the queue in which the message was enqueued. It can be specified by its name and an address with a protocol value of 0. The address should be the name of another queue in the same database or another installation of Oracle Database (identified by the database link), in which case the message is propagated to the specified queue and can be dequeued by a consumer with the specified name. If the recipient’s name is NULL, then the message is propagated to the specified queue in the address and can be dequeued by the subscribers of the queue specified in the address. If the protocol field is nonzero, then the name and address are not interpreted by the system and the message can be dequeued by a special consumer.
Subscribing to a queue is like subscribing to a magazine: each subscriber can dequeue all the messages placed into a specific queue, just as each magazine subscriber has access to all its articles. Being a recipient, however, is like getting a letter: each recipient is a designated target of a particular message.
Figure 1-4 shows how TEQ and AQ can accommodate both kinds of consumers. Application A enqueues messages. Application B and Application C are subscribers. But messages can also be explicitly directed toward recipients like Application D, which may or may not be subscribers to the queue. The list of such recipients for a given message is specified in the enqueue call for that message. It overrides the list of subscribers for that queue.
Figure 1-4 Explicit and Implicit Recipients of Messages
Description of «Figure 1-4 Explicit and Implicit Recipients of Messages»
Multiple producers can simultaneously enqueue messages aimed at different targeted recipients.
Transactional Event Queues and Advanced Queuing Implementation of Workflows
Application A begins a workflow by enqueuing Message 1.
Application B dequeues it, performs whatever activity is required, and enqueues Message 2.
Application C dequeues Message 2 and generates Message 3.
Application D, the final step in the workflow, dequeues it.
Figure 1-5 Implementing a Workflow using TEQ and AQ
Description of «Figure 1-5 Implementing a Workflow using TEQ and AQ»
The contents of the messages 1, 2 and 3 can be the same or different. Even when they are different, messages can contain parts of the contents of previous messages.
The queues are used to buffer the flow of information between different processing stages of the business process. By specifying delay interval and expiration time for a message, a window of execution can be provided for each of the applications.
From a workflow perspective, knowledge of the volume and timing of message flows is a business asset quite apart from the value of the payload data. TEQ and AQ helps you gain this knowledge by supporting the optional retention of messages for analysis of historical patterns and prediction of future trends.
Transactional Event Queues and Advanced Queuing Implementation of Publish/Subscribe
A point-to-point message is aimed at a specific target. Senders and receivers decide on a common queue in which to exchange messages. Each message is consumed by only one receiver.
Figure 1-6 shows that each application has its own message queue, known as a single-consumer queue.
Figure 1-6 Point-to-Point Messaging
Description of «Figure 1-6 Point-to-Point Messaging»
Broadcasting is like a radio station not knowing exactly who the audience is for a given program. The dequeuers are subscribers to multiconsumer queues. In contrast, multicast is like a magazine publisher who knows who the subscribers are. Multicast is also referred to as point-to-multipoint, because a single publisher sends messages to multiple receivers, called recipients, who may or may not be subscribers to the queues that serve as exchange mechanisms.
Figure 1-7 Publish/Subscribe Mode
Description of «Figure 1-7 Publish/Subscribe Mode»
Publish/subscribe describes a situation in which a publisher application enqueues messages to a queue anonymously (no recipients specified). The messages are then delivered to subscriber applications based on rules specified by each application. The rules can be defined on message properties, message data content, or both.
You can implement a publish/subscribe model of communication using TEQ and AQ as follows:
Set up one or more queues to hold messages. These queues should represent an area or subject of interest. For example, a queue can be used to represent billed orders.
Set up a set of rule-based subscribers. Each subscriber can specify a rule which represents a specification for the messages that the subscriber wishes to receive. A null rule indicates that the subscriber wishes to receive all messages.
Publisher applications publish messages to the queue by invoking an enqueue call.
Subscriber applications can receive messages with a dequeue call. This retrieves messages that match the subscription criteria.
Subscriber applications can also use a listen call to monitor multiple queues for subscriptions on different queues. This is a more scalable solution in cases where a subscriber application has subscribed to many queues and wishes to receive messages that arrive in any of the queues.
Subscriber applications can also use the Oracle Call Interface (OCI) notification mechanism. This allows a push mode of message delivery. The subscriber application registers the queues (and subscriptions specified as subscribing agent) from which to receive messages. This registers a callback to be invoked when messages matching the subscriptions arrive.
Figure 1-8 illustrates the use of TEQ and AQ for implementing a publish/subscribe relationship between publisher Application A and subscriber Applications B, C, and D:
Application B subscribes with rule «priority = 1».
Application C subscribes with rule «priority > 1».
Application D subscribes with rule «priority = 3».
Figure 1-8 Implementing Publish/Subscribe using TEQ and AQ
Description of «Figure 1-8 Implementing Publish/Subscribe using TEQ and AQ»
If Application A enqueues three messages with priorities 1, 2, and 3 respectively, then the messages will be delivered as follows:
Application B receives a single message (priority 1).
Application C receives two messages (priority 2, 3).
Application D receives a single message (priority 3).
Buffered Messaging
Buffered messaging combines the rich functionality that this product has always offered with a much faster queuing implementation. Buffered messaging is ideal for applications that do not require the reliability and transaction support of Oracle Database Advanced Queuing persistent messaging.
Buffered messaging is faster than persistent messaging, because its messages reside in shared memory. They are usually written to disk only when the total memory consumption of buffered messages approaches the available shared memory limit.
The portion of a queue that stores buffered messages in memory is sometimes referred to as a buffered queue.
Message retention is not supported for buffered messaging.
When using buffered messaging, Oracle recommends that you do one of the following:
Set parameter streams_pool_size
This parameter controls the size of shared memory available to Oracle Database Advanced Queuing. If unspecified, up to 10% of the shared pool size may be allocated for the Oracle Database Advanced Queuing pool from the database cache.
Refer to manually tuning sharded queues for more information about setting the message cache for buffered messaging with TEQs.
Turn on SGA autotuning
Oracle will automatically allocate the appropriate amount of memory from the SGA for Oracle Database Advanced Queuing, based on Oracle Database Advanced Queuing usage and, also usage of other components that use the SGA. Examples of such other components are buffer cache and library cache. If streams_pool_size is specified, it is used as the lower bound.
Enqueuing Buffered Messages
Buffered and persistent messages use the same single-consumer or multiconsumer queues and the same administrative and operational interfaces. They are distinguished from each other by a delivery mode parameter, set by the application when enqueuing the message to an Oracle Database Advanced Queuing queue.
Recipient lists are supported for buffered messaging enqueue.
Buffered messaging is supported in all queue tables created with compatibility 8.1 or higher. Transaction grouping queues and array enqueues are not supported for buffered messages in this release. You can still use the array enqueue procedure to enqueue buffered messages, but the array size must be set to one.
All ordering schemes available for persistent messages are also available for buffered messages, but only within each message class. Ordering among persistent and buffered messages enqueued in the same session is not currently supported.
Both enqueue and dequeue buffered messaging operations must be with IMMEDIATE visibility mode. Thus they cannot be part of another transaction. You cannot specify delay when enqueuing buffered messages.
Dequeuing Buffered Messages
Rule-based subscriptions are supported with buffered messaging. The procedure for adding subscribers is enhanced to allow an application to express interest in persistent messages only, buffered messages only, or both.
For AQ queues, array dequeue is not supported for buffered messaging, but you can still use the array dequeue procedure by setting array size to one message.
Dequeuing applications can choose to dequeue persistent messages only, buffered messages only, or both types. Visibility must be set to IMMEDIATE for dequeuing buffered messages. All of the following dequeue options are supported:
Navigation modes FIRST_MESSAGE and NEXT_MESSAGE
Propagating Buffered Messages
Propagation of buffered messages is supported. A single propagation schedule serves both persistent and buffered messages. The DBA_QUEUE_SCHEDULES view displays statistics and error information.
Oracle Database AQ deletes buffered messages once they are propagated to the remote sites. If the receiving site fails before these messages are consumed, then these messages will be lost. The source site will not be able to re-send them. Duplicate delivery of messages is also possible.
Oracle Database Advanced Queuing implements a flow control system that prevents applications from flooding the shared memory with messages. If the number of outstanding messages per sender exceeds a system-defined threshold, the enqueue call will block and timeout with an error message. A message sender is identified by sender_id.name in the enqueue options. A sender blocked due to flow control on a queue does not affect other message senders. The resolution is to dequeue messages, thereby resolving flow control, after which new messages can be enqueued.
Flow control threshold varies with memory pressure and could come down to the system-defined limit if streams pool usage becomes significant. Message senders will block on event Streams AQ: enqueue blocked due to flow control and time out with error ORA-25307 if flow control is not resolved. Applications are expected to handle this error, and re-enqueue the failed message.
Even with flow control, slow consumers of a multiconsumer queue can cause the number of messages stored in memory to grow without limit. Provided there is at least one subscriber who is keeping pace, older messages are spilled to disk and removed from the pool to free up memory. This ensures that the cost of disk access is paid by the slower consumers, and faster subscribers can proceed unhindered.
Buffered Messaging with Oracle Real Application Clusters (Oracle RAC)
TEQ and AQ queues handle buffered messaging with Oracle RAC differently.
TEQs perform cross-instance communication but avoid simultaneous writes to the same block across Oracle RAC instances. Typically, dequeues occur on an event stream that is local to a message’s enqueuing instance, but in certain situations, Oracle will efficiently forward messages across instances for dequeuing on another instance. For example, if a TEQ has a single enqueuing session on one Oracle RAC instance and a single dequeuing session on another instance, then TEQs will forward messages between the Oracle RAC instances. The forwarding of messages is done asynchronously to the enqueuing transaction to improve performance. Dequeuers may get an ORA-25228 if they are connected to an instance whose event streams have no messages.
For AQ queues, an application can enqueue and dequeue buffered messages from any Oracle RAC instance as long as it uses password-based authentication to connect to the database. The structures required for buffered messaging are implemented on one Oracle RAC instance. The instance where the buffered messaging structures are implemented is the OWNER_INSTANCE of the queue table containing the queue. Enqueue and dequeue requests received at other instances are forwarded to the OWNER_INSTANCE over the interconnect. The REMOTE_LISTENER parameter in listener.ora must also be set to enable forwarding of buffered messaging requests to correct instance. Internally, buffered queues on Oracle RAC may use dblinks between instances. Definer’s rights packages that enqueue or dequeue into buffered queues on Oracle RAC must grant INHERIT REMOTE PRIVILEGES to users of the package.
A service name is associated with each queue in Oracle RAC and displayed in the DBA_QUEUES and USER_QUEUES views. This service name always points to the instance with the most efficient access for buffered messaging, minimizing pinging between instances. OCI clients can use the service name for buffered messaging operations.
Oracle recommends that you specify instance affinity when using buffered messaging with queue-to-queue propagation. This results in transparent failover when propagating messages to a destination Oracle RAC system. You do not need to re-point your database links if the primary AQ Oracle RAC instance fails.
«REMOTE_LISTENER» in Oracle Database Reference for more information on setting the REMOTE_LISTENER parameter