Hey all!

I didn't know where else to post this so here it is.

Does anyone know why opeing a baan session (the first time) takes so long, and how I can fix this?

It seems to be getting slower and slower. Even the session display company data (tccom0500m000) takes 18 seconds - with only 1 item listed. I know 18 seconds doesn't sound like a long time - but count it out once. Users are going to start yelping soon. Opening BaaN itself is not slow. just opening a session for the first time.

Thanks.
-----------------
P-Matt.

ps. The server is not busy or over utilized, and it appears to be this way on all clients - even the server client.

Well, the sessions open slow because they are all calling the standard functions/dlls to read company parameters and user data for the first time in that bshell. I believe this then gets stored somehow by user/bshell, because when those libraries are called after the first time, they only take a second to run. Also, sessions that don't read those parameters are quick to open first time in, so I am pretty sure that's the problem.

Not a solution for you though, sorry.

Can't imagine why those libraries would run slower over time, the parameter tables and user data tables only have one record in them at all times. Do you have anything in shared memory? Maybe that would help - does anyone else put the parameter tables in shared memory?

You posted that you upgraded to Oracle 8i in another post. I can tell you from personal experience that it is your Oracle upgrade that is causing you these performance problems, because we had the same things happening. Oracle 7 consumed 3 - 5 Meg per session, and now Oracle 8i consumes about 10 Meg per session, so if you haven't considered increasing the memory on your database server, then do so. Whenever a user logs into Baan it generally spawns 4 to 5 Oracle sessions, and each of them occupy a specific amount of memory whether or not they are active. We have a 200 user license, so we might have as many as 1000 sessions that are wanting to consuming 10 Gig plus, and then add in the 1.2 Gig of SGA into that and we're pushing 12 Gig of memory just for Oracle 8i. We originally had 4 Gig and since added 4 more to get 8 Gig, but we found out even that still isn't enough. You'll probably notice during that your paging is way up if you're memory deficient. There are some different settings in Oracle 8i that differ from 7, but more memory will likely be the magic bullet for this issue. Good Luck.

Thanks for the quick replies.

I'm sure that adding memory will help, but if this is a cumulative issue, it will just catch up with me again in the future, because it appears to be getting worse and worse.

It is only the first time a session is opened - so I'm leaning toward shared memory and tuning. I see on support.baan.com that Oracle had a bug - 564060 or 248756, but metalink does not give any results when searched for this, and I'm not sure if it was supposedly fixed in 8i.

Is anyone familiar with this?

I'm trying to figure out the shared memory thing, but can't seem to see any difference.

gguymer - i went to the oraperf site with my statspack - thanks a bunch for the tip - it was very insightful!

The optimizer permutations issue has been around since Oracle 7, and we set permutations to 1500 for both O7 and O8i and it definitely helps. There is another bug in Oracle OCI for both 8.0 and 8i that causes performance issues, which is why Baan is recommending that Oracle 8 and 8i customers switch back to the Baan / Oracle 7 driver. I played with pinning Oracle structures into memory, but it still did not make a difference. We had an Oracle DBA consultant do an analysis of our system and his conclusion was MEMORY DEFICIENCY. You can play with Oracle settings all day long, but the other part of the equation in evaluating the problem has to include the hardware and operating system. I really hope you will look at your system's memory needs. I'm just trying to save you the grief I spent doing what you are trying to do right now.
I am attaching a powerpoint presentation by Gaja Vaidyanatha, author of Oracle Tuning 101. He has a very enlightened approach to tuning problem performance issues.

huh.

Thanks for the ppt. (I have the book - quite good)

And (at least in German) it's got a name too:

We call that time needed to open the first session the "Jan und Paul Gedenkminute"

Guess you checked the max permutation parameter and what components are loaded from shared memory and what from disk?

Han

I know that the max permutation parameter is set to 1500.
I'm going to play with the shared memory feature today. I don't think that is set or setup properly.

I'm going to load the sessions that were listed in another post, but if anyone knows of others to load, holler.

ulrich, I like your feature name. My boss has one also - but I should not repeat it. :D

What is this doing? How can I tell what it's doing? (if anything)
I can see stuff in Bentman - show loaded, but everything is still slower than mud.

Everytime I tell it to load from the DD, then I can't log in. Get Error 515 - probably unpatched binaries. What does that have to do with anything???????

If I remove the srdd_tab6.1 file, stop and start the shared memory service again, then maybe I'm ok. Sometimes I need to reboot the server.....

Why didn't our installation consultants set this up and show me what it is and how it works? (I know - too late - but it feels good to vent!)

Can anyone point me toward Shared Memory for Idiots information? I need to start from scratch here - Who, What, Where, When, Why....

Boy, I feel better already!!:p

Hi Matt,

Seems like you could do with some de-stressing :)

Some things to remember:

1) Did you convert to runtime <CTRL-D> after loading the objects in the session 'Maintain Shared Memory Objects'?

2) You can load the objects into shared memory manually or automatically. The easiest would be to stop and restart the application. Check your $BSE/log/log.srdd_tab6.1 file for errors etc

3) If you have problems with the shared memory segments, you can remove them with ipcrm command. On rarer occasions you would have to reboot your server.

4) What to load?: first of all you can load all your Tools objects (tt) into shared memory. Additionally you could load heavily used application objects into shared memory too.

Hey Patrick!

Stress? What Stress? :D

I don't have a log.srdd_tab6.1 file. Perhaps because I'm on NT? I do have a shmman.log file, but it's empty.

Is there something or somewhere I can monitor to see if the items listed in my file, and in the show loaded, are REALLY loaded and doing something?



By the way - what are table boosters? Should I be using these?

:confused:
Thanks
P

Hi Matt,

Hmm, my Baan on NT knowledge has drifted away into the far corners of my brain so can't help you too much.

However you should have shmmanager command or similar that can show you the listed objects.

Table boosters are a whole different matter and can be dangerous as well. I suggest you open a different thread on this if you would like more info - or - have a look around for existing posts covering this topic.

Good luck :)

You can check with bentman the components loaded in shm. Right click on the shm service, chose shm manager, show loaded.

Table boosters is a setup for specific programs (it means the sessions have to support it) that tells the session to load specific tables in memory instead of doing an i/o.
If it will help depends on your installation meaning you have to test it.

Han

Excuse me for interrupting this fine thread but you've arisen my
curiosity with those tuning messages. Could someone please
tell me what this permutation parameter is all about and where
can it be fixed? What about loading from shared memory or disk?
Where can I see those options too?

Tomas Sanchez Tejero
deckard@encomix.es

Here is the note from Metalink...

OPTIMIZER_MAX_PERMUTATIONS restricts the number of permutations of the tables the optimizer will consider in queries with joins. Such a restriction ensures that the parse time for the query stays within acceptable limits. However, a slight risk exists that the optimizer will overlook a good plan it would otherwise have found.

The default value for this parameter is 80000, which corresponds to no limitation at all. Setting this parameter to a value less than 1000 normally ensures parse times of a few seconds or less.

This should always be set to a lower value (1500 is recommended) for Baan sites. The key indicator that you have a problem that can be fixed with this solution is long parse times reflected in the trace or profile options (ORAPROF, etc.).

-- Jim

Not sure if you have resolved this yet or not, but I had the same problem at one installation. They had turned on History for all users, this writes the users id, date and session code along with the time they open and close a session to the TIME.HIS file. the problem with this is that the file reads seq, in other words I had a 245 meg file that users had to wait to read to the end before it would open the session. I set up a script to copy this file out to an archive on a daily basis, which I kept for 7 days.

Check your user maintenance and see if history is turned on.

Hope this helps.:)

Well, well, well. It's been awhile.
Finaly fixed the problem people.

I had antivirus software installed on both my production and test boxes (test first of course and everything was good). (At the time, my production BaaN box was also a file server.) But, the antivirus software kept Dr. Watson'ing so I disabled it. (key word here is disabled.) This was the case on both the test server and the production server.

huh - what are the odds?

Turns out that disabling the software was not enough. I needed to UNINSTALL it. Once I uninstalled it, then configured and implemented the Shared memory manager, my sessions that used to take up to 33 seconds to open, now open in 5 seconds or less. I figure the software had to have something running in the background that I couldn't see - even tho I had it disabled.

So, my new rule is:

NO ANTIVIRUS SOFTWARE ON A BAAN SERVER!!!

Live and learn eh?

I hate to crosspost but I have a little different but similar subject.
I wasn't sure if i should bring it into this one, or if I should start new. So I started new..

http://www.baanboard.com/baanboard/showthread.php?s=&threadid=9210

Maybe its all the same problem...

Dave

There is a fix about this problem in portingset 6.1c.07.01, specifically for NT/2000
(same fix in 7.1d.02 for B50c)

MaintBaanIVc: # 17883 (BDNT11130): Slow startup time of first session on Windows

Date: Tue, 8 Apr 2003 11:15:47 +0200

Created on: MaintBaanIVc
Type: bugfix

Problem Description (Customer terms)
Startup of session is slow, in spite of the fact that the tabledefinition files for that package combination are pre-loaded into the Baan Shared Memory.
Problem only applicable for Windows platform. Specially sessions, which needs a lot of tabledefinitions, are very slow. Because the tabledefinitions are pre-loaded into the Baan Shared Memory you should expect that also first time startup is fast.

Just a thought, but is your Porting Set up to date? Certainly the more recent porting sets (on NT at least) have improved session startup times generally.