Re: saving contents of 6 tables simultaneously..

Server doesn't like it, means load is too high (idle CPU time is close to 0).

No errors experienced, eveything is just running slower.

few 100K rows per table

timing element is critical within 1min, the job works fine, and does it's job.

On Wed, 1 Sep 2004 14:29:23 -0400, "Mark C. Stock" <mcstockX_at_Xenquery .com> wrote:

>
>"NetComrade" <netcomradeNSPAM_at_bookexchange.net> wrote in message
>news:41360fed.603498575_at_localhost...
>| We have an application doing the following around 10pm
>|
>| truncate table saved_table_1;
>| insert into saved_table_1 select * from table_1;
>|
>|
>| for 6 tables.. each 'save' is an oracle job.
>|
>| The problem is, this server now has 5 such application, which
>| translates into 30 jobs running simultaneously, which the server
>| doesn't like.
>|
>| My suggestion was, that we open cursors for each table in each
>| application (to insure that we catch all records prior to 10pm, which
>| is what's important for the app), and 'save' tables one by one,
>| instead of doing all 6 at once (have 1 job per application instead of
>| 6 jobs). However, the problem I think is going to be 'fetching' from a
>| cursor, instead of just doing a insert into .. select *.. and is going
>| to be slower, is there are a way to speed it up? Is there are a 'bulk
>| insert' from a cursor?
>|
>| Thanks!
>| .......
>| We use Oracle 8.1.7.4 on Solaris 2.7 boxes
>| remove NSPAM to email
>
>a little more info would be helpful....
>
>why doesn't the server like it? what errors are you experiencing? there may
>be a more direct solution based on your server configuration.
>
>how many rows in each table?
>
>how critical is the time element? if its significant then you probably need
>to rely on timestamps in the table rather than on scheduling the job to
>start at 10:00 pm.
>
>++ mcs
>
>

.......
We use Oracle 8.1.7.4 on Solaris 2.7 boxes remove NSPAM to email Received on Wed Sep 01 2004 - 13:40:38 CDT