| Oracle® Streams Concepts and Administration 11g Release 2 (11.2) Part Number E10704-03 |
|
|
View PDF |
| Oracle® Streams Concepts and Administration 11g Release 2 (11.2) Part Number E10704-03 |
|
|
View PDF |
The following topics contain conceptual information about staging messages in queues and propagating messages from one queue to another:
See Also:
Oracle Streams Advanced Queuing User's Guide for detailed information about the propagation infrastructure in Oracle Streams AQ
An Oracle Streams propagation is configured internally using Oracle Scheduler. Therefore, a propagation job is a job that propagates messages from a source queue to a destination queue. Like other Oracle Scheduler jobs, propagation jobs have an owner, and they use slave processes (jnnn) as needed to execute jobs.
The following procedures can create a propagation job when they create a propagation:
The ADD_GLOBAL_PROPAGATION_RULES procedure in the DBMS_STREAMS_ADM package
The ADD_SCHEMA_PROPAGATION_RULES procedure in the DBMS_STREAMS_ADM package
The ADD_TABLE_PROPAGATION_RULES procedure in the DBMS_STREAMS_ADM package
The ADD_SUBSET_PROPAGATION_RULE procedure in the DBMS_STREAMS_ADM package
The CREATE_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package
When one of these procedures creates a propagation, a new propagation job is created in the following cases:
If the queue_to_queue parameter is set to TRUE, then a new propagation job always is created for the propagation. Each queue-to-queue propagation has its own propagation job. However, a slave process can be used by multiple propagation jobs.
If the queue_to_queue parameter is set to FALSE, then a propagation job is created when no propagation job exists for the source queue and database link specified. If a propagation job already exists for the specified source queue and database link, then the new propagation uses the existing propagation job and shares this propagation job with all of the other queue-to-dblink propagations that use the same database link.
This section contains the following topics:
Note:
The source queue owner performs the propagation, but the propagation job is owned by the user who creates it. These two users might or might not be the same.See Also:
Oracle Database Administrator's Guide for more information about Oracle Scheduler
A propagation schedule specifies how often a propagation job propagates messages from a source queue to a destination queue. Each queue-to-queue propagation has its own propagation job and propagation schedule, but queue-to-dblink propagations that use the same propagation job have the same propagation schedule.
A default propagation schedule is established when a new propagation job is created by a procedure in the DBMS_STREAMS_ADM or DBMS_PROPAGATION_ADM package.
The default schedule has the following properties:
The start time is SYSDATE().
The duration is NULL, which means infinite.
The next time is NULL, which means that propagation restarts as soon as it finishes the current duration.
The latency is three seconds, which is the wait time after a queue becomes empty to resubmit the propagation job. Therefore, the latency is the maximum wait, in seconds, in the propagation window for a message to be propagated after it is enqueued.
You can alter the schedule for a propagation job using the ALTER_PROPAGATION_SCHEDULE procedure in the DBMS_AQADM package. Changes made to a propagation job affect all propagations that use the propagation job.
When the restricted session is enabled during system startup by issuing a STARTUP RESTRICT statement, propagation jobs with enabled propagation schedules do not propagate messages. When the restricted session is disabled, each propagation schedule that is enabled and ready to run will run when there is an available slave process.
When the restricted session is enabled in a running database by the SQL statement ALTER SYSTEM ENABLE RESTRICTED SESSION, any running propagation job continues to run to completion. However, any new propagation job submitted for a propagation schedule is not started. Therefore, propagation for an enabled schedule can eventually come to a halt.
When a database object is prepared for instantiation at a source database, an Oracle Streams data dictionary is populated automatically at the database where changes to the object are captured by a capture process. The Oracle Streams data dictionary is a multiversioned copy of some of the information in the primary data dictionary at a source database. The Oracle Streams data dictionary maps object numbers, object version information, and internal column numbers from the source database into table names, column names, and column data types. This mapping keeps each captured LCR as small as possible, because the message can store numbers rather than names internally.
The mapping information in the Oracle Streams data dictionary at the source database is needed to evaluate rules at any database that propagates the captured LCRs from the source database. To make this mapping information available to a propagation, Oracle automatically populates a multiversioned Oracle Streams data dictionary at each database that has an Oracle Streams propagation. Oracle automatically sends internal messages that contain relevant information from the Oracle Streams data dictionary at the source database to all other databases that receive captured LCRs from the source database.
The Oracle Streams data dictionary information contained in these internal messages in a queue might or might not be propagated by a propagation. Which Oracle Streams data dictionary information to propagate depends on the rule sets for the propagation. When a propagation encounters Oracle Streams data dictionary information for a table, the propagation rule sets are evaluated with partial information that includes the source database name, table name, and table owner. If the partial rule evaluation of these rule sets determines that there might be relevant LCRs for the given table from the specified database, then the Oracle Streams data dictionary information for the table is propagated.
When Oracle Streams data dictionary information is propagated to a destination queue, it is incorporated into the Oracle Streams data dictionary at the database that contains the destination queue, in addition to being enqueued into the destination queue. Therefore, a propagation reading the destination queue in a directed networks configuration can forward LCRs immediately without waiting for the Oracle Streams data dictionary to be populated. In this way, the Oracle Streams data dictionary for a source database always reflects the correct state of the relevant database objects for the LCRs relating to these database objects.
You can propagate a binary file between databases by using Oracle Streams. To do so, you put one or more BFILE attributes in a message payload and then propagate the message to a remote queue. Each BFILE referenced in the payload is transferred to the remote database after the message is propagated, but before the message propagation is committed. The directory object and filename of each propagated BFILE are preserved, but you can map the directory object to different directories on the source and destination databases. The message payload can be a BFILE wrapped in an ANYDATA payload, or the message payload can be one or more BFILE attributes of an object wrapped in an ANYDATA payload.
The following are not supported in a message payload:
One or more BFILE attributes in a varray
A user-defined type object with an ANYDATA attribute that contains one or more BFILE attributes
Propagating a BFILE in Oracle Streams has the same restrictions as the procedure DBMS_FILE_TRANSFER.PUT_FILE.
See Also:
Oracle Database Administrator's Guide, and Oracle Database PL/SQL Packages and Types Reference for more information about transferring files with the
DBMS_FILE_TRANSFER package
|
 Copyright © 2002, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|