haesaerts
24th January 2005, 18:08
Hi,

has anyone experienced similar problems ? This is an HP-UX system running Baan B40 c4
and oracle 9.2.0.4.0

a reference transaction takes 1 second to complete on single cpu system.
when running the same transaction on a multi-cpu system, it sometimes takes up to 50 seconds.

I haven't seen the system yet, but I guess this might have something to do with either Baan or Oracle parameters.

Anyone ?

thanks in advance

dave_23
24th January 2005, 21:22
Did it just start happening after an Oracle X to 9i upgrade? If so check out solution 166049 on the support web site. It's a good starting point.

Dave

haesaerts
24th January 2005, 22:00
it started happening after a migration from another platform, which included an oracle 8 to 9 upgrade.

I'll check it out, thanks

Dikkie Dik
26th January 2005, 16:47
I also recommend to install the latest Oracle patchset.
You never know ;)

Kind regards,
Dick

ranias
13th February 2005, 18:51
1. I suggest that you check the recommended HPUX kernel parameters for Oracle 9i there a document which you can get form Oracle or HP for this configuration and recommendation.

2. you need to patch your version of Oracle up to patch release v9.2.0.6.

- Ranias

Francesco
14th February 2005, 18:52
Also check the recommended kernel settings by Baan. They can make a world of difference, particularly with Oracle as your backend.

Markus Schmitz
15th February 2005, 09:58
Hi haeserts,

we work with the combination of BaanIV/Oracle/HP for many years and always on multi-processor systems. The HW and SW combination you are talking of has most likely the biggest market share in the Baan community. So let's assume, what you describe is not normal.

To begin with, you or your customer changed a lot of things in parallel. This way it is difficult to figure out, where the source of problems is:

a) HW
b) OS
C) DB Version
D) single processor to multi processor

The least likely cause of your problem is actually the last one :-)

Anyway, as other members on this board descibed a "freeze" might be caused by kernel config, patch level of the OS or DB, DB config and many other things.

First you should try to narrow down the problem a bit better:

a) Does the whole system freeze, ie. for a considerable time everybody hangs?

b) Does only a specific baan session hang?

c) Is the "freeze" sporadic or can you reproduce it deterministically?

Performance is a very wide field, so lets first figure out better, what the actual problem is.

regards

Markus

haesaerts
15th February 2005, 10:26
I found out that the entire installation has 2 Baan companies. But there are only 4 disks (2 x 2 mirror) for the entire setup. I looked at performance with Glance & saw huge disk activity - my guess is that there are no Oracle statistics available & that there is too much real data access going on instead of index access. I have asked the dba to analyse/compute statistics on the most used tables. I have also suggested to put the redo logs on separate (fast) disks. They were all on the system disk (4 redo logs of 250MB)...

any other suggestions are more than welcome.

the system sometimes freezes up for seconds. I have witnessed it myself...

Markus Schmitz
15th February 2005, 10:49
if the whole system freezes, then check in alert.log for "checkpoint not complete". Most likely he can not write the redologs fast enough. This would be consistent with your high IO. Relocating the redologs would be an option here. Also adding additional once.

Another reason for high IO could be swapping. In a default HP installation normally dynamic buffering with 50% of RAM as max buffer limit is enabled. This often results in memory bottlenecks and therefore swapping.

Glance can show you disk io by physical disk and filesystem. Press "h" for help in the ascii version.

As I said, lots of things could be wrong ...

Martin
16th February 2005, 10:17
Do you had set the following init.ora parameter ?

HPUX_SCHED_NOAGE=178

that's importent for Oracle 9 Installations on HPUX.


greetz
martin

Markus Schmitz
16th February 2005, 10:47
Hi Martin,

that's an interesting parameter, which somehow passed me up to now. But as far as I understand, this is just influencing the scheduling priority and might improve performance according to Metalink by 5-10%.

Even though 5-10% is not bad at all, how does this relate to a "freezing" system?

Regards

Markus