baaniac
30th January 2002, 15:48
Hi,

We are using Baan IV c2 with Oracle 7.3 as back-end and HP-UX 10.0 as Operating System.

When we run session, "Archive / Purge Finance Transactions" (tfgld6205m000), it is found to be taking a huge amount of time. Currently, it is running for the past 3 days for year 2000.

This is despite the latest solution received from local Baan Support center.

In the script, we found that select statment is written on table tfgld106 with clause "as prepared set".
We suspect that it is this clause which is causing the problem.

On the operating system side, we have found sufficent ticks being consumed by the session and also, Oracle database, Baan-Oracle driver and Operating System have been sufficiently tuned up.

Can anyone tell possible reason for such low performance in this session ?

Thanks

Youp2001
30th January 2002, 16:23
If the session processes a lot of date the 'as prepared set' is probably needed to prevent a fatal error (snapshot too old or something like that).

Did you do some tracing already on the session. Running the session in profile-mode could give an indication of the problem (it lists the functions that take most of the time at the top of the report). You can also activate tracing on the Oracle database, so you can check if session executes inefficient queries.

However this analyzing is only possible of you can test with a subset of your data because you only get the results after the session has ended.

Success.

richard
31st January 2002, 14:06
We are using baan c4, oracle level 2 and have been archiving
4,000,000 records in about 8 hours (purge + archive).

As prepared set is in the select.
We removed also the solution 106176 to use index2 again.

Regards

baaniac
31st January 2002, 14:29
Thanks Youpe and Richard.

We have Level 1 for Oracle driver and that might be the main reason of the problem.
But nowhere else in Baan system, we are facing this problem. Even in process-intensive sessions like "Post Integration Transactions to Finance" or MPS/MRP/DRP Runs, the performance is not that bad.

In script, we did find 106176 which needs to be commented out and make use of Index 2.
Also slight modification in the form will be required to ask for Month - From and To; so as to test for a smaller subset of records.

Thanks for your kind leads.