Re: How to install oracle on UNIX

From: Howard J. Rogers <howardjr_at_dizwell.com>
Date: Mon, 04 Oct 2004 22:56:51 +1000
Message-ID: <41629abe$0$20125$afc38c87@news.optusnet.com.au>

Keg wrote:

> 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.

Because Oracle Corporation and the writers of those installation guides tend to take the eminently sensible viewpoint that you're not installing all those Oracle binaries just to see how much disk space you can consume; that at some point you will want to create a database with them; and at that point, it would be helpful for the revised kernel parameters to be able to kick in.

Added to which, have you not noticed that the Oracle installer will (at least offer to) create a database *as part of the installation* by default. At least a substantial percentage of Oracle installations will indeed consist of also creating a database as a result.

Whether that's a good or bad thing is another matter (I happen to think confusing installation with creating a database is extremely bad, but so what). Point is, there is method in the madness of proposing kernel parameter changes prior to installation.

By the way... have you tried an Oracle 10g installation using your advice? Unless you explicitly remember to ask it not to check, it won't even start installing unless ALL the kernel parameters are within its own definition of acceptable.

Your practical and empirical experience on this matter is as nought compared with the direction Oracle itself is moving in, I would say.

Regards
HJR
> 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 semaphore
> call
>
> # 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 Mon Oct 04 2004 - 07:56:51 CDT