Wednesday, February 01, 2006

Default Kernel Parameters for Sun OS 9.X Database

Metalink Note:187273.1 Type: PROBLEM
Last Revision Date: 21-OCT-2005 Status: PUBLISHED


Solution Description:
---------------------
This article is to define the default kernel parameter settings for the
Sun OS/Solaris Operating system running Oracle 8.X Enterprise Edition.

Solution Explanation:
---------------------
In Sun OS the /etc/system file is the kernel parameter file.

The current kernel parameters values can be displayed by using the
'sysdef -i' command.
- Refer to Note 70688.1"Location and Dispay of kernel parameters" for more
information on uderstanding the 'sysdef -i'output.
======================================================================
UNIX Kernel Parameters:
-----------------------
SEMMNI 100
- Defines the maximum number of semaphore sets in the entire system.
SEMMNS 256
- Defines the maximum semaphores on the system. This setting is a
minimum recommended value, for initialinstallation only. The SEMMNS
parameter should be set to the sum of the PROCESSES parameter for each Oracle
database, adding the largest one twice, and then adding an additional 10 for
each database.
SEMMSL 256
- Defines the minimum recommended value, for initial installation only.
SHMMAX 4294967295
- Defines the maximum allowable size of one shared memory segment.
(4 GB = 4294967295)
SHMMIN 1
- Defines the minimum allowable size of a single shared memory segment.
SHMMNI 100
- Defines the maximum number of shared memory segments in the entire system.
SHMSEG 10
- Defines the maximum number of shared memory segments one process can attach.

Note: These are minimum kernel requirements for Oracle9i. If you have previously
tuned your kernel parameters to levels equal to or higher than these values,
continue to use the higher values. A system restart is necessary for kernel
changes to take effect.

------------------------------------------------------------------------------
* Example of Oracle required parameters:

set shmsys: shminfo_shmseg = 10
set shmsys: shminfo_shmmin = 1
set shmsys: shminfo_shmmni = 100
set semsys: seminfo_semmns = 256
set semsys: seminfo_semmni = 4096
set semsys: seminfo_semmsl = 256
set shmsys: shminfo_shmmax = 4294967295

9.2.0.4 databases to 9.2.0.6, 9.2.0.7 or wait for testing?

http://searchoracle.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid41_gci1157663,00.html?track=sy40

My name is Steve and I'm a Lead Oracle DBA. My question revolves around the quarterly security patches and the best 9i release of Oracle to be on. I have over 300 9.2.0.4 databases. We just started creating 9.2.0.6 databases with an eye toward going to 10.2 in the first quarter next year. My question/issue is this: Oracle released 9.2.0.7 recently, and my concern is that they will stop patching 9.2.0.6 in the near future (not sure of that date). I'd like to be on the terminal release of 9i but that's been a moving target. Anyway, should I upgrade my existing 9.2.0.4 databases to 9.2.0.6, 9.2.0.7 or wait for testing, etc. of 10.2 and just move them all to that release? Any advice would be helpful. Thanks.
This question posed on 10 January 2006


>This is a subject I have quite an interest in so I could probably spend hours discussing it. This patching issue is still relatively new to most DBAs and it can be especially painful if there are a large number of databases to support, as is the case here. I work for an IT consulting company, but I just spent the last two years at a large client and we had to tackle this exact problem. This client had more than 200 Oracle databases that had to be patched on a regular basis. With Sarbanes-Oxley (and other) regulatory compliance legislation, patching databases is no longer an option, but a necessity.

Your concern that patches will no longer be available for Oracle 9.2.0.6 is quite valid -- this, in fact, will happen one day soon. So, in my opinion, you need to develop a strategy that balances the practicality of patching but can tolerate some risk. For example, you can apply the appropriate CPU patches once per year (say, in late spring) and then plan to upgrade databases to the next release in the fall. In theory, the latest release will contain the latest CPUs. It's nearly impossible to upgrade 300 databases more than once per year; as well, it would be impossible to apply all four CPUs to these databases considering you would require outages which can be very difficult to obtain on production systems.

Whatever strategy you choose, make sure that it works for your organization and that you can justify it. Also, document the strategy and your rationale for choosing it.

Monday, January 16, 2006

How to find obsolete parameters in Oracle

By querying V$OBSOLETE_PARAMETER.

If the value in column ISSPECIFIED is 'TRUE' then it is specified in the init.ora file.

select * from V$OBSOLETE_PARAMETER
where ISSPECIFIED = 'TRUE'
/