Slow Performance Running Oracleware/Novell

From: Michael Stowe <Michael.Stowe_at_f573.fido.chi.il.us>
Date: Sun, 16 Oct 94 10:51:04 -0500
Message-ID: <782308264_at_f573.n115.z1.ftn>


This depends largely on the hardware, but note that the default INIT.ORA shipped is the SMALL model. You may also want to check your Novell and Oracle block sizes, and the more RAM the better, of course.

Standard tuning procedures also apply -- separate rollback segments, indexes, and main data, put logfiles on a separate volume... And don't use RAID disks. (Mirroring, on the other hand, is just fine.) Remember that since Novell is a non-pre-emptive platform, it is possible for any NLM loaded on the server to steal processor cycles, so be careful what you are loading...
> 2. What Novell parameters can be turned on/turned off to speed
> performance?

In general, Novell is already tuned for performance; for specific needs, it once again depends on your hardware. There isn't a magic parameter that works in all cases, but it's a good idea to have a look at monitor and see what's really taking up all the time. (LOAD MONITOR -P)

> 3. I am accustomed to being able to specify where to place data files
> (e.g. UNIX); my understanding of Novell is that Novell sees all the
> devices as one big volume. Should I continue to allow Novell to do
> this, or is there a way to bypass the Novell operating system?

Your understanding is incorrect. You may, of course, specify where anything and everything goes. Novell is also capable of joining physical volumes into logical volumes, but nobody really ever does this. Of course, you can't expect to use the UNIX naming conventions, either. Novell paths are specified by SERVER/VOLUME:PATH... Also, there is a bug in some versions, where you must first assign a logical to the path and then assign the parameter to the logical.  You may be running into this problem if you are having trouble specifying locations of files.

> 4. I suspect double-buffering may be occuring: anyway to get get
> around this?

Oracle gets around this by using the DIRECTFS module, which allows the database to bypass Novell's buffering. I imagine, though, that you have it loaded already.
> 5. This is going to sound strange but....how do I know if we are
> running SQL*Net? I got into a very heated arguement about this (and may be
> wrong), but I thought that SQL*Net required some protocol, e.g. Novell
> or TCP/IP to run. The other ORACLE guru says no, we are not running
> SQL*Net, because we have Novell. Some clarification please.

You are both wrong, in a sense. The SQL*Net listener attaches to the IPX/SPX protocol stack, of course. Since only SQL*Net 1.1 is available, there are not separate protocol modules available. (In other words, if you load the TCP/IP protocol stack, it will be ignored unless you get the SQL*Net listener for TCP/IP and load that as well.)
Of course, you don't have to run SQL*Net, but if you don't, you can't attach to the server remotely, either. The SQL*Net listener is loaded by ORALOAD by default. (To see the listener in action, you need only ALT-ESC over to its screen, or type MODULES.)

Michael Stowe Received on Sun Oct 16 1994 - 16:51:04 CET

Original text of this message