Slow Performance Running Oracleware/Novell
Date: Sun, 16 Oct 94 10:51:04 -0500
Message-ID: <782308264_at_f573.n115.z1.ftn>
- Quoting Dagmara_at_Delphi.Com to All dated 10-15-94 ***
> 1. What INIT.ORA parameters should I tune for Novell?
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