Problem in setting up schedule push

Question

Hi every body,
I have a multimaster advance replication environment and we have less than 10 transaction per day. I am not sure what is the correct set up for my case.Could you please help me?
My first question is:I want to propagate data as soon as possible like sync if I setup the schedule push to propagate transaction every 5 seconds as below
BEGIN
DBMS_DEFER_SYS.SCHEDULE_PUSH(
destination => 'orc2',
interval => 'SYSDATE + (5/60*60*24)',
next_date => SYSDATE,
parallelism => 1,
delay_seconds => 10);
END;
is it correct approach?
in other hand ,book(I mean Advance Replication) has written that for simulating continuous push we should setup it as below so it will propagate transaction every 1 minute.
My second question is:I know interval >= 'SYSDATE + (1/144)' means every 10 minutes a job will start and delay_seconds => 1200 means each job remain aware for 20 minutes,
but I can't understand why it can simulate 1 minute propagation? anybody knows?
BEGIN
DBMS_DEFER_SYS.SCHEDULE_PUSH(
destination => 'orc2',
interval => 'SYSDATE + (1/144)',
next_date => SYSDATE,
parallelism => 1,
execution_second >= 1500,
delay_seconds => 1200);
END;
My thrid question is :Which of the above setups is a better solution for my environment?I mean 5 second interval (interval => 'SYSDATE + (5/60*60*24)') + delay_second = 10 and parallel or 10 minute interval (interval => 'SYSDATE + (1/144)') + delay_second = 1200 and parallel + execution_second =>1500)
Thank you in advance.
Mery

Answer 1

With a "delay" of 20minutes, the push job will "hang around" for 20minutes waiting for new transactions. If it receives no new transactions to push, it will go to sleep. However, with the job interval at 1minute, it will "wake up" one minute later and push
transactions that were created in that last 1 minute. Again, it will "hang around" for the next 20minutes.
This is what I see from the 9i documentation (for advanced replication not using streams, I find the 8i and 9i documentation better
than the 10g documentation)
Delay Seconds
Though not directly a performance mechanism, properly configuring the delay_seconds parameter can give you greater control over the timing of your propagation of deferred transactions.
When you are pushing deferred transactions, you set the delay_seconds parameter in the SCHEDULE_PUSH procedure or the PUSH function. When you are purging deferred transactions, you set the delay_seconds parameter in the SCHEDULE_PURGE procedure or the PURGE function. These procedures and functions are in the DBMS_DEFER_SYS package.
The delay_seconds parameter controls how long a job remains aware of the deferred transaction queue. The effects of the delay_seconds parameter can best be illustrated with the following two examples:
delay_seconds = 0 (default)
If a scheduled job with a 60 minute interval wakes up at 2:30 pm and checks the deferred transaction queue, then any existing deferred transactions are propagated. The propagation takes 2 minutes and therefore the job is complete at 2:32 pm.
If a deferred transaction enters the queue at 2:34 pm, then the deferred transaction is not propagated because the job is complete. In this scenario, the deferred transaction will be propagated at 3:30 pm.
delay_seconds = 300
If a scheduled job with a 60 minute interval wakes up at 2:30 pm and checks the deferred transaction queue, then any existing deferred transactions are propagated. The propagation takes 2 minutes and therefore the job is complete at 2:32 pm.
If a deferred transaction enters the queue at 2:34 pm, then the deferred transaction is propagated because the job remains aware of the deferred transaction queue for 300 seconds (5 minutes) after the job has completed propagating whatever was in the queue. In this scenario, the deferred transaction is propagated at 2:34 pm.
Why not just set the job to execute more often? Starting and stopping the job has a greater amount of overhead than starting the job and keeping it aware for a set period of time. In addition to decreasing the overhead associated with starting and stopping these jobs, using the delay_seconds parameter can reduce the amount of redo logging required to support scheduled jobs.
As with most performance features, there is a point of diminishing returns. Keep the length of the delay_seconds parameter in check for the following reasons:
Parallel Propagation: Each parallel process that is used when pushing the deferred transaction queue is not available for other parallel activities until the propagation job is complete. A long delay_seconds value may keep the parallel process unavailable for other operations. To use parallel propagation, you set the parallelism parameter to 1 or higher in the SCHEDULE_PUSH procedure or the PUSH function.
Serial Propagation: If you are using serial propagation (not parallel propagation), then the delay_seconds value causes the open session to "sleep" for the entire length of the delay, providing none of the benefits earlier described. To use serial propagation, you set the parallelism parameter to 0 (zero) in the SCHEDULE_PUSH procedure or the PUSH function.
Precise Purge: If you specify the purge_method_precise method when using the DBMS_DEFER_SYS.PURGE procedure and you have defined a large delay_seconds value, then you may experience performance degradation when performing the specified purge. Using purge_method_precise is more expensive than the alternative (purge_method_quick), but it ensures that the deferred transactions and procedure calls are purged after they have been successfully pushed.
As a general rule of thumb, there are few viewable benefits of setting the delay_seconds parameter to a value greater than 20 minutes (which is 1200 seconds for the parameter setting).
Additionally, if you are using serial propagation by setting the parallelism parameter to 0, then you probably do not want to set a large delay_seconds value. Unlike parallel propagation, serial propagation only checks the queue after the duration of the delay_seconds value has elapsed. If you use serial propagation and set delay_seconds to 20 minutes, then the scheduled job will sleep for the entire 20 minutes, and any deferred transactions that enter the deferred transaction queue during that time are not pushed until 20 minutes have elapsed. Therefore, if you are using serial propagation, then consider setting delay_seconds to a value of 60 seconds or lower.
If you set a value of 20 minutes for parallel propagation, then the parallel push checks once a minute. If you can afford this resource lock, then the relatively high delay_seconds value of 20 minutes is probably most efficient in your environment. If, however, you cannot afford this resource lock, then consider setting the delay_seconds value to 10 or 20 seconds. Although you will need to execute the jobs more often than if the value was set to 1200 seconds, you still gain many of the benefits of the delay_seconds feature (versus the default value of 0 seconds).