Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: How to install oracle on UNIX
Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1096864658.119237_at_yasure>...
> Keg wrote:
>
> > Hans Forbrich <news.hans_at_telus.net> wrote in message news:<b5m7d.8750$223.380_at_edtnps89>...
> >
> >>y wrote:
> >>
> >>
> >>>Can someone please tell me how to install Oracle 9 on Solaris?I need as
> >>>much info as you possible can tell. Thanks in loads.
> >>
> >>There's a significant amount of information in this:
> >>
> >>http://www.oracle.com/pls/db92/db92.to_toc?pathname=..%2F..%2Fhtml%2FA96167_01%2Ftoc.htm&remark=docindex
> >
> >
> > Man, Solaris is the easy platform. (well excluding windoze)
>
> Do precisely what you wrote and I will guarantee a filed installation.
>
> Don't set the kernel parameters and reboot and you might as well not
> bother trying at all.
Actually there not needed for a database either if your SGA is small/medium sized. The changes to the parameters in /etc/system raise the default hard limits and thus allow larger shared memory segments and etc... I currently have a Solaris 8 64-bit and a Solaris 9 64-bit system running Oracle with the only change in /etc/system being increased open file descriptors. Same is true on Linux, rarely have I seen the need to make changes to the kernel parameters even though most install guides seem to make this a requirement _prior_ to doing anything.
Just remember, there is no SGA during the installation of the oracle binaries, thus why would there be a need to increase the default hard limits of the SGA. The OUI is a java based tool, and thus uses a JVM.
# Solaris tunables for better performance/larger oracle instances (a
lot of these won't make any since to you unless you have written C/C++
on Unix)
# Shared Mem
shmsys:shminfo_shmmax = maximum size of a shared memory segment shmsys:shminfo_shmmin = Minimum size of a shared memory segment shmsys:shminfo_shmmni = Maximum number of shared memory identifiers shmsys:shminfo_shmseg = Maximum number of segments per process
#Semaphores
semsys:seminfo_semmap = Number of entries in the semaphore map semsys:seminfo_semmni = Maximum number of identifiers semsys:seminfo_semmns = Number of entries in the semaphore map semsys:seminfo_semmnu = Number of entries in the semaphore map semsys:seminfo_semume = Maximum number of undo entries, per process semsys:seminfo_semmsl = Maximum number of semaphores, per id semsys:seminfo_semopm = Maximum number of operations, per semaphorecall
# Mesg Q's
msgsys:msginfo_msgmap = Number of entries in the message map msgsys:msginfo_msgmax = Maximum message size msgsys:msginfo_msgmnb = Maximum bytes on the queue msgsys:msginfo_msgmni = Number of message queue identifiers msgsys:msginfo_msgssz = Segment size of a message msgsys:msginfo_msgtql = Number of system message headers msgsys:msginfo_msgseg = Number of message segments
Regardless of what any install guide says, all are optional on Solaris and only need to be increased if your database/SGA needs the extra resources. I have been running databases on Solaris for 10+ years and rarely have I seen the need to increase these. (a lot of these changes data back to the old days of limited memory and etc..., this the kernels came default with these settings much lower than they are with today releases of Solaris. Same thing with the default init.ora, if you look the defaults in there are ridiculously low for a database in todays environments)
It is also advisable to start with a stable baseline with Solaris AND THEN increase kernel parameters as needed. This provides the most robust/stable approach to systems management. It is very easy to identify kernel resource shortfalls and since you never wanna rush a newly installed box into production, you have time to identify these.
This information is based on actual 'real-world' empirical testing and production operation. Received on Tue Oct 05 2004 - 07:38:13 CDT