Cherie,
If network bandwidth is the bottleneck, the use of Fast Refreshable
snapshots will be a great help. Whereby you only pull the rows that have
changed since the last refresh across to the primary.
Raj
I think that you can try 2 things:
1) Run the function in the source db. Selects across links does funny stuff.
2) Write CSV file on the source system and sql loader on the target using
direct.
Yechiel Adar
Mehish
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL
I believe, with 8.1.7, Oracle changed the behavior of selects over a
database link so that it is optimized for snapshot (materialized view)
replication. We faced a similar situation and the answer was to copy the
source tables over the db_link and then run the PL/SQL against the copied
tables
Title: RE: Long-running PL/SQL function (long)
Cherie,
I'd run this function with 2 events separately ...
first 10938 this will give you pl/sql profiling or simply use dbms_profiler package. This will tell you where (and at which line) you are spending most of your time. Metalink has some
PROTECTED]
Sent by: cc:
[EMAIL PROTECTED] Subject: Re: Long-running PL/SQL function
(long)
om
Subject: RE: Long-running PL/SQL
function (long)
Sent by:
[EMAIL PROTECTED
Title: RE: Long-running PL/SQL function (long)
Cherie,
Bulk inserts/selects are available since 8i ...
Not being sarcastic but sorry to disappoint you, but your developers haven't used anything new that wasn't in 8i ... you can give them the bad news .. (if you want.)
I think bulk
Title: RE: Long-running PL/SQL function (long)
Hi Cherie,
Using pl/sql tables and bulk binding will increase the speed dramatically with both insert and cursor fetching. I've done it myself many times with runaway success.
Also, lookup tables can be cached in the procedure to avoid going
of list ORACLE-L
[EMAIL PROTECTED]
cc:
Sent by: Subject: Re: Long-running PL/SQL function
(long)
[EMAIL PROTECTED
