hi all,

My users are complaining about this session tdrpl0122m000 that performs very slow and sometimes assumed to be hanging already by the users.

What are the things I need to check first.

We are using BaanIvc4 on IBM platform and Oracle as our database.

Your comments and suggestions will be greatly appreciated.

thank you very much.

julia

When a session runs slow I have the following suggestions:
- Check when the session runs slow (always/ with some users on the system/ between 9 and 10 AM/ on Thuesdays etc)
- If it is not always, try to identify what is causing the problem (Locking/ system usage/ application locks etc)
- If it is always, analyze the session by profiled objects/ BLAT or Database tools. In your situation I advise to start with database tracing when no sources are available. When sources are avaliable, start with profiled objects. You can more about how to do this in the document on top of this group (Link to performance and tuning doc (http://www.baanboard.com/baanboard/showthread.php?s=&threadid=7665))

If I am not clear (or my document) please let me know and we can try to help you further.

Hope this helps,
Dick

IMHO the problem with this session is in the default query on the main table. The query (shown when tracing) shows that there is some kind of extention whereby the mask is checked for certain step numbers. These text comparisons take a long time, and, if you have a lot of records in the tdrpl100 (Relenishment Order Lines) table, the session becomes extremely sluggish when trying to switch to the previous/next record. Also, startup of the session is affected by this. Why the query is not rewritten to check the status field, I do not know. Another method to better the performance would be to add an index where the mask field is the first keyfield, and then the program could construct the needed mask string before querying the database. Something to report to Baan Support?

Nico,

Thanks for the additions. As I expect you have done the traces ealier I hope ou can also send me the traces so we can give some hints to support. if you can't, hopefully Julia an make a database trace on it. and send/post these.

Together we can see if we can find a solution herefore.

BTW: wich version do we talk about?

Dick

We are using BaanIvc4 on IBM platform and Oracle as our database.


And that's the version I tested it on. Did it some time in the past, and do not have the traces anymore, but can recreate if necessary.

Regards,
Nico

Nico,

Sorry that I missed that part. Yes, if possible, recreate the traces.


Julia,

Are you using Level 1 or Level 2? If this sounds weird to you, please ask your Baan admin as he/ she should know ;) .

Kind regards,
Dick

Here are the two queries executed when starting up the session (done with TT_SQL_TRACE=0200):


SELECT tdrpl100.*, tiitm001.*
FROM tdrpl100, tiitm001
WHERE tdrpl100._index1 BETWEEN {:tdrpl100.orno, :tdrpl100.pono, :tdrpl100.srnb} AND {:tdrpl100.orno}
AND (
(:currkey <> 3 or tdrpl100.pino <> 0) and
(:currkey <> 4 or tdrpl100.dino <> 0) and
(:currkey <> 5 or tdrpl100.fono <> 0) and
tdrpl100.pmsk(:stno.rpl2126;1) <> "e" and
tdrpl100.pmsk(:stno.rpl0122;1) <> "n" and
tdrpl100.pmsk(:stno.rpl0114;1) <> "n")
AND tdrpl100.item REFERS TO tiitm001
ORDER BY tdrpl100._index1



SELECT tdrpl100.*, tiitm001.*
FROM tdrpl100, tiitm001
WHERE tdrpl100._index1 = {:tdrpl100.orno}
AND (
(:currkey <> 3 or tdrpl100.pino <> 0) and
(:currkey <> 4 or tdrpl100.dino <> 0) and
(:currkey <> 5 or tdrpl100.fono <> 0) and
tdrpl100.pmsk(:stno.rpl2126;1) <> "e" and
tdrpl100.pmsk(:stno.rpl0122;1) <> "n" and
tdrpl100.pmsk(:stno.rpl0114;1) <> "n")
AND tdrpl100.item REFERS TO tiitm001
ORDER BY tdrpl100._index1


Thus, the second performance killer is the tdrpl100.* and tiitm001.*

Hope this helps!

Nico

hello,

thank you very much to all your response. by the way, we are using the level 2 database driver.

additional info:I suggested to set the following variables in thier db_resource file.


dbsinit:021
ora_init:0111000
ora_max_array_fetch:2
ora_max_array_insert:1
baan_oracle_prefetch:2
oracle_client_home:/baan/usr/bse/lib/ora/oracle_home
nls_lang:american_america.us7ascii
nls_sort:binary
ora_column_format:8

lock_retry:0
ora_timeout:{0,60,60,60,0}

Would this help?

thanks,

julia

Hi,

Can you post init${ORACLE_SID}.ora file. This file has some more parameters which might be of some interest.

By the way what's the version of your Oracle.

regards,
Dev

Hi guys,



forgot to mention that this slow session performance was only observed in ASCII. There were no similar problem encountered
using the GUI or BW.

hi Avasarala,

Oracle version 8.1.7

thanks,

julia

Hi Julia,

Are you using Rule-Based-Optimizer or Cost-Based-Optimizer?
You can find these details from init${ORACLE_SID}.ora file.

Regards,
Dev

As the difference only occurs in ASCII I assume there are done some settings on OS level that are not used when using the GUI. So please login on UNIX and type env:

$env

Let us know these results. Also let us know the content of the following files:
- $BSE/lib/tabledef6.1
- $BSE/lib/defaults/db_resource

Maybe we need more files, but this is a good starting point.

As this is ASCII only, it has nothing to do with Oracle settings like RBO or CBO nor any init.ora parameter.

Kind regards,
Dick