From time to time you may want to write scripts that will allow you to copy files to a server, or login, without being prompted for passwords. This can make them simpler to write and also prevents you from having to embed the password in your code.
SCP has a feature that allows you to do this. You no longer have to worry about prying eyes seeing your passwords nor worrying about your script breaking when someone changes the password. You can configure SSH to do this by generating and installing data transfer encryption keys that are tied to the IP addresses of the two servers. The servers then use these pre-installed keys to authenticate one another for each file transfer. As you may expect, this feature doesn't work well with computers with IP addresses that periodically change, such as those obtained via DHCP.
There are some security risks though. The feature is automatically applied to SSH as well. Someone could use your account to log in to the target server by entering the username alone. It is therefore best to implement this using unprivileged accounts on both the source and target servers.
The example that follows enables this feature in one direction (from server bigboy to server smallfry) and only uses the unprivileged account called filecopy.
Configuration: Client Side
Here are the steps you need to do on the computer that acts as the SSH client:
1) Generate your SSH encryption key pair for the filecopy account. Press the Enter key each time you are prompted for a password to be associated with the keys. (Do not enter a password.)
[filecopy@bigboy filecopy]# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key
(/filecopy/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
/filecopy/.ssh/id_dsa.
Your public key has been saved in
/filecopy/.ssh/id_dsa.pub.
The key fingerprint is:
1e:73:59:96:25:93:3f:8b:50:39:81:9e:e3:4a:a8:aa
filecopy@bigboy
[filecopy@bigboy filecopy]#
2) These keyfiles are stored in the.ssh subdirectory of your home directory. View the contents of that directory. The file named id_dsa is your private key, and id_dsa.pub is the public key that you will be sharing with your target server. Versions other than RedHat/Fedora may use different filenames, use the SSH man pages to verify this.
[filecopy@bigboy filecopy]# cd ~/.ssh
[filecopy@bigboy filecopy]# ls
id_dsa id_dsa.pub known_hosts
[filecopy@bigboy .ssh]#
3) Copy only the public key to the home directory of the account to which you will be sending the file.
[filecopy@bigboy .ssh]# scp id_dsa.pub filecopy@smallfry:public-key.tmp
Now, on to the server side of the operation.
Configuration - Server Side
Here are the steps you need to do on the computer that will act as the SSH server.
1) Log into smallfry as user filecopy. Create an .ssh subdirectory in your home directory and then go to it with cd.
[filecopy@smallfry filecopy]# ls
public-key.tmp
[filecopy@smallfry filecopy]# mkdir .ssh
[filecopy@smallfry filecopy]# chmod 700 .ssh
[filecopy@smallfry filecopy]# cd .ssh
2) Append the public-key.tmp file to the end of the authorized_keys file using the >> append redirector with the cat command. The authorized_keys file contains a listing of all the public keys from machines that are allowed to connect to your Smallfry account without a password. Versions other than RedHat/Fedora may use different filenames, use the SSH man pages to verify this.
[filecopy@smallfry .ssh]# cat ~/public-key.tmp >> authorized_keys
[filecopy@smallfry .ssh]# rm ~/public-key.tmp
Tuesday, September 15, 2009
Saturday, September 12, 2009
Oracle SDU and TDU parameters in listener.ora and tnsnames.ora
The session data unit (SDU) specifies the size of the packets to send over the network. The maximum transmission unit (MTU) is a fixed value that depends on the actual network implementation used. Ideally, SDU should not surpass the size of the MTU. Oracle recommends that SDU be set equal to the MTU. The tnsnames.ora and listener.ora files house the SDU and TDU parameters.
To group data together, the TDU value is the default packet size used within Oracle*Net. The default value for both SDU and TDU is 2,048 bytes and the maximum value is 32,767 bytes. The TDU parameter should ideally be a multiple of the SDU parameter. For SDU and TDU, the following guidelines apply:
On fast network connections such as T1 or T3 lines, SDU and TDU should be set equal to the MTU for the network. On standard Ethernet networks, the default MTU size should be set to 1,514 bytes. On standard token ring networks, the default MTU size is 4,202 bytes.
If the users are connecting via dial-up modem lines, it may be desirable to set SDU and TDU to smaller values in consideration of the frequent resends that occur over modem connections.
The mts_dispatchers must also be set with the proper MTU - TDU configuration, if a Multi-Threaded Server (MTS) is used.
As a rule, SDU should not be set greater than the TDU because network resources will be wasted by shipping wasted space in each packet.
This brief review of network-related parameters was intended provide an introduction to the scope and complexity of network tuning. It is important to understand that Oracle*Net is simply a layer in the OSI model that is above the network-specific protocol stack, and therefore, virtually all network tuning is external to Oracle.
Ex: -
Doc ID: Note:71921.1
Subject: ORA-12151, ORA-12571 errors on Windows NT
Type: BULLETIN
Status: PUBLISHED
Content Type: TEXT/PLAIN
Creation Date: 09-JUN-1999
Last Revision Date: 07-FEB-2002
PURPOSE
Give an overview of what to adjust and verify in case of ORA-12151
and ORA-12571 errors
SCOPE AND APPLICATION
This notes applies to all who are facing intermittent SQL*Net read and
write errors while working on NT.
==============================================================================
ORA-12151 and ORA-12571 errors on Windows NT
Intermittent SQL*Net TCP/IP read and write errors are sometimes encountered
on NT. The underlying reasons of these errors are a synchronization error
in the TCP/IP layer on NT. To help prevent this kind of errors, a
few things can be adjusted to help the synchronization:
1. TCP.NODELAY parameter
This parameter is to be added in the "PROTOCOL.ORA" file in the
"NETWORK\\ADMIN" directory.
In most cases, TCP/IP info send across the network is buffered
till at least a complete network packet can be send. This means
that in certain cases commands are not issued directly, and kept
buffered until some other info can be send as well.
This has the potential to generate timeouts and errors.
To avoid this, this delay can be switched off.
tcp.nodelay = yes
2. Disabling AUTOMATIC_IPC on Clients
On client PC's, checking for IPC connections is pointless as there
is never a database installed on them. So, in order to save some
time during the connections phase, set AUTOMATIC_IPC=OFF in the
"SQLNET.ORA" file.
3. "NAMES.DIRECTORY_PATH" to force using "TNSNAMES.ORA" or "ONAMES"
If you have a fixed environment, it's best to specify this in the
"SQLNET.ORA" file. The parameter "NAMES.DIRECTORY_PATH" specifies how
the TNS resolving takes place.
By default, if this parameter is not present - the SQL*Net layer
will first check if there is a Names server anywhere on the network,
and will afterwards start checking for a "TNSNAMES.ORA" file.
If you have only a "TNSNAMES.ORA" file, and no Oracle Names installed,
it is best to specify this parameter to skip the Names searching in
order to speed up the TNS resolving time.
The value of this parameter is a comma separated list, with as
possible values TNSNAMES (for "TNSNAMES.ORA" searching) and "ONAMES"
(for Oracle Names searching).
4. TCP/IP timeouts on NT
The default retransmission count on NT is 5, before it detects that
the network is down. With the value of 5, the actual timeout is
aproximately 15 seconds.
This default value can be easily increased to a higher value.
In the registry, change the following value:
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
TCP/IP
Parameters
TcpMaxDataRetransmissions REG_DWORD "number"
This parameter is not present in the registry by default. This
means that the first time, this parameter will need to added to
this registry key.
This parameter can be useful on both client and server. Suggested
course of action is to first add this parameter on the machine
generating the SQL*Net errors, and if the problem persists, also
include the parameter in the registry of the other machine.
5. TCP/IP keepalive on NT
KEEPALIVE is an extension to TCP/IP which enables the closing of
dead connections which are no longer being used.
Problems can occur when the server does not close a connection
after a PC client process has disappeared. This typically happens
when a PC user switches off or reboots their machine while still
connected to Oracle. Note that this is not an Oracle problem, but
a limitation of TCP/IP, which has no way of knowing for sure
whether a remote connection has disappeared.
This feature is enabled by default on NT. Problem can occur however
if the timeout period is too fast for some heavily used or slow
network. In those conditions, the KEEPALIVE registry value can be
used to specify a KEEPALIVE value before a connection gets cut.
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
TCP/IP
Parameters
KeepAlive REG_DWORD "number"
A value of '10' is a common value specified for this variable.
Again, this parameter can be useful on both client and server.
Start with the machine generating the error, and if needed, also add
it on the machine on the other side.
6. TCP/IP timeouts on Windows 95
The same parameter can also be specified on Windows 95. It has the
same functionality, only the location of the parameter in the
registry is different.
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
Winsock
Parameters
TcpMaxDataRetransmissions REG_DWORD "number"
This parameter is not present in the registry by default. This
means that the first time, this parameter will need to added to
this registry key.
The purpose and behavior of the parameter is the same on the Windows 95
and Windows 98, as on the Windows NT platform.
7. SDU & TDU parameters
Part of this problem is the sequence of information that gets transmitted.
If there are disruptions in the sequence, the errors ORA-12151 and
ORA-12571 can also appear, alerting the application that not all information
has been send across the network succesfully.
The sequence of information is determined by the amount of data the program
is sending, and the actual size the protocol can send across the network
at a time.
The more data the program wants to send in one 'go', the more sequences and
transport packet split-ups will have to be made.
By default, SQL*Net is using an SDU (Session Data Unit) of 2048 bytes (2Kb)
and a TDU (Transport Data Unit) of 32768 (32Kb) bytes.
On standard Ethernet connections, with no special modifications made, the
SDU is 1500 bytes, while the TDU is 8760 bytes.
With these values, each data request made by SQL*Net will have to be split
up in several smaller packets to actually be able to transmit.
Therefore, to minize the creation the additional packets, it is advised, in
case of these errors, to synchronize the SDU and TDU parameters at the
SQL*Net level with those of the actual network topology used.
These SDU and TDU parameters have to be specified at both the client and
the server configuration files:
TNSNAMES.ORA:
-------------
ORCL.WORLD =
(DESCRIPTION =
(SDU=1500)
(TDU=8760)
(ADDRESS_LIST =
(ADDRESS =(PROTOCOL=TCP)(Host=foobar)(Port=1521))
)
(CONNECT_DATA =
(SID = ORCL)
)
)
LISTENER.ORA:
-------------
SID_DESC_LISTENER =
(SID_LIST =
(SID_DESC =
(SDU = 1500)
(TDU = 8760)
(SID_NAME = ORCL)
)
)
For more information about the SDU and TDU parameter, see Note 44694.1,
Note 44694.1: SQL*Net Packet Sizes (SDU & TDU Parameters)
8. Setting a new TDU size on Windows NT
You can modify the TDU size on NT, via the TcpWindowSize parameter:
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
Tcpip
Parameters
TcpWindowSize REG_DWORD "number"
Additional information about the NT network parameters on NT:
-------------------------------------------------------------
Q120642: TCP/IP & NBT Configuration Parameters for Windows NT
http://support.microsoft.com/support/kb/articles/Q120/6/42.asp
Q140375: Default MTU Size for Different Network Topology
http://support.microsoft.com/support/kb/articles/Q140/3/75.asp
To group data together, the TDU value is the default packet size used within Oracle*Net. The default value for both SDU and TDU is 2,048 bytes and the maximum value is 32,767 bytes. The TDU parameter should ideally be a multiple of the SDU parameter. For SDU and TDU, the following guidelines apply:
On fast network connections such as T1 or T3 lines, SDU and TDU should be set equal to the MTU for the network. On standard Ethernet networks, the default MTU size should be set to 1,514 bytes. On standard token ring networks, the default MTU size is 4,202 bytes.
If the users are connecting via dial-up modem lines, it may be desirable to set SDU and TDU to smaller values in consideration of the frequent resends that occur over modem connections.
The mts_dispatchers must also be set with the proper MTU - TDU configuration, if a Multi-Threaded Server (MTS) is used.
As a rule, SDU should not be set greater than the TDU because network resources will be wasted by shipping wasted space in each packet.
This brief review of network-related parameters was intended provide an introduction to the scope and complexity of network tuning. It is important to understand that Oracle*Net is simply a layer in the OSI model that is above the network-specific protocol stack, and therefore, virtually all network tuning is external to Oracle.
Ex: -
Doc ID: Note:71921.1
Subject: ORA-12151, ORA-12571 errors on Windows NT
Type: BULLETIN
Status: PUBLISHED
Content Type: TEXT/PLAIN
Creation Date: 09-JUN-1999
Last Revision Date: 07-FEB-2002
PURPOSE
Give an overview of what to adjust and verify in case of ORA-12151
and ORA-12571 errors
SCOPE AND APPLICATION
This notes applies to all who are facing intermittent SQL*Net read and
write errors while working on NT.
==============================================================================
ORA-12151 and ORA-12571 errors on Windows NT
Intermittent SQL*Net TCP/IP read and write errors are sometimes encountered
on NT. The underlying reasons of these errors are a synchronization error
in the TCP/IP layer on NT. To help prevent this kind of errors, a
few things can be adjusted to help the synchronization:
1. TCP.NODELAY parameter
This parameter is to be added in the "PROTOCOL.ORA" file in the
"NETWORK\\ADMIN" directory.
In most cases, TCP/IP info send across the network is buffered
till at least a complete network packet can be send. This means
that in certain cases commands are not issued directly, and kept
buffered until some other info can be send as well.
This has the potential to generate timeouts and errors.
To avoid this, this delay can be switched off.
tcp.nodelay = yes
2. Disabling AUTOMATIC_IPC on Clients
On client PC's, checking for IPC connections is pointless as there
is never a database installed on them. So, in order to save some
time during the connections phase, set AUTOMATIC_IPC=OFF in the
"SQLNET.ORA" file.
3. "NAMES.DIRECTORY_PATH" to force using "TNSNAMES.ORA" or "ONAMES"
If you have a fixed environment, it's best to specify this in the
"SQLNET.ORA" file. The parameter "NAMES.DIRECTORY_PATH" specifies how
the TNS resolving takes place.
By default, if this parameter is not present - the SQL*Net layer
will first check if there is a Names server anywhere on the network,
and will afterwards start checking for a "TNSNAMES.ORA" file.
If you have only a "TNSNAMES.ORA" file, and no Oracle Names installed,
it is best to specify this parameter to skip the Names searching in
order to speed up the TNS resolving time.
The value of this parameter is a comma separated list, with as
possible values TNSNAMES (for "TNSNAMES.ORA" searching) and "ONAMES"
(for Oracle Names searching).
4. TCP/IP timeouts on NT
The default retransmission count on NT is 5, before it detects that
the network is down. With the value of 5, the actual timeout is
aproximately 15 seconds.
This default value can be easily increased to a higher value.
In the registry, change the following value:
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
TCP/IP
Parameters
TcpMaxDataRetransmissions REG_DWORD "number"
This parameter is not present in the registry by default. This
means that the first time, this parameter will need to added to
this registry key.
This parameter can be useful on both client and server. Suggested
course of action is to first add this parameter on the machine
generating the SQL*Net errors, and if the problem persists, also
include the parameter in the registry of the other machine.
5. TCP/IP keepalive on NT
KEEPALIVE is an extension to TCP/IP which enables the closing of
dead connections which are no longer being used.
Problems can occur when the server does not close a connection
after a PC client process has disappeared. This typically happens
when a PC user switches off or reboots their machine while still
connected to Oracle. Note that this is not an Oracle problem, but
a limitation of TCP/IP, which has no way of knowing for sure
whether a remote connection has disappeared.
This feature is enabled by default on NT. Problem can occur however
if the timeout period is too fast for some heavily used or slow
network. In those conditions, the KEEPALIVE registry value can be
used to specify a KEEPALIVE value before a connection gets cut.
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
TCP/IP
Parameters
KeepAlive REG_DWORD "number"
A value of '10' is a common value specified for this variable.
Again, this parameter can be useful on both client and server.
Start with the machine generating the error, and if needed, also add
it on the machine on the other side.
6. TCP/IP timeouts on Windows 95
The same parameter can also be specified on Windows 95. It has the
same functionality, only the location of the parameter in the
registry is different.
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
Winsock
Parameters
TcpMaxDataRetransmissions REG_DWORD "number"
This parameter is not present in the registry by default. This
means that the first time, this parameter will need to added to
this registry key.
The purpose and behavior of the parameter is the same on the Windows 95
and Windows 98, as on the Windows NT platform.
7. SDU & TDU parameters
Part of this problem is the sequence of information that gets transmitted.
If there are disruptions in the sequence, the errors ORA-12151 and
ORA-12571 can also appear, alerting the application that not all information
has been send across the network succesfully.
The sequence of information is determined by the amount of data the program
is sending, and the actual size the protocol can send across the network
at a time.
The more data the program wants to send in one 'go', the more sequences and
transport packet split-ups will have to be made.
By default, SQL*Net is using an SDU (Session Data Unit) of 2048 bytes (2Kb)
and a TDU (Transport Data Unit) of 32768 (32Kb) bytes.
On standard Ethernet connections, with no special modifications made, the
SDU is 1500 bytes, while the TDU is 8760 bytes.
With these values, each data request made by SQL*Net will have to be split
up in several smaller packets to actually be able to transmit.
Therefore, to minize the creation the additional packets, it is advised, in
case of these errors, to synchronize the SDU and TDU parameters at the
SQL*Net level with those of the actual network topology used.
These SDU and TDU parameters have to be specified at both the client and
the server configuration files:
TNSNAMES.ORA:
-------------
ORCL.WORLD =
(DESCRIPTION =
(SDU=1500)
(TDU=8760)
(ADDRESS_LIST =
(ADDRESS =(PROTOCOL=TCP)(Host=foobar)(Port=1521))
)
(CONNECT_DATA =
(SID = ORCL)
)
)
LISTENER.ORA:
-------------
SID_DESC_LISTENER =
(SID_LIST =
(SID_DESC =
(SDU = 1500)
(TDU = 8760)
(SID_NAME = ORCL)
)
)
For more information about the SDU and TDU parameter, see Note 44694.1,
Note 44694.1: SQL*Net Packet Sizes (SDU & TDU Parameters)
8. Setting a new TDU size on Windows NT
You can modify the TDU size on NT, via the TcpWindowSize parameter:
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
Tcpip
Parameters
TcpWindowSize REG_DWORD "number"
Additional information about the NT network parameters on NT:
-------------------------------------------------------------
Q120642: TCP/IP & NBT Configuration Parameters for Windows NT
http://support.microsoft.com/support/kb/articles/Q120/6/42.asp
Q140375: Default MTU Size for Different Network Topology
http://support.microsoft.com/support/kb/articles/Q140/3/75.asp
ORA-27102: out of memory Error on Solaris 10
Symptom: -
As part of a database tuning effort you increase the SGA/PGA sizes; and Oracle greets with an ORA-27102: out of memory error message. The system had enough free memory to serve the needs of Oracle.
SQL> startup
ORA-27102: out of memory
SVR4 Error: 22: Invalid argument
Diagnosis: -
$ oerr ORA 27102
27102, 00000, "out of memory"
// *Cause: Out of memory
// *Action: Consult the trace file for details
Not so helpful. Let's look the alert log for some clues.
% tail -2 alert.log
WARNING: EINVAL creating segment of size 0x000000028a006000
fix shm parameters in /etc/system or equivalent
Oracle is trying to create a 10G shared memory segment (depends on SGA/PGA sizes), but operating system (Solaris in this example) responded with an invalid argument (EINVAL) error message. There is a little hint about setting shm parameters in /etc/system.
Prior to Solaris 10, shmsys:shminfo_shmmax parameter has to be set in /etc/system with maximum memory segment value that can be created. 8M is the default value on Solaris 9 and prior versions; where as 1/4th of the physical memory is the default on Solaris 10 and later. On a Solaris 10 (or later) system, it can be verified as shown below:
% prtconf | grep Mem
Memory size: 32760 Megabytes
% id -p
uid=59008(oracle) gid=10001(dba) projid=3(default)
% prctl -n project.max-shm-memory -i project 3
project: 3: default
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 7.84GB - deny -
system 16.0EB max deny -
Now it is clear that the system is using the default value of 8G in this scenario, where as the application (Oracle) is trying to create a memory segment (10G) larger than 8G. Hence the failure.
So, the solution is to configure the system with a value large enough for the shared segment being created, so Oracle succeeds in starting up the database instance.
On Solaris 9 and prior releases, it can be done by adding the following line to /etc/system, followed by a reboot for the system to pick up the new value.
set shminfo_shmmax = 0x000000028a006000
However shminfo_shmmax parameter was obsoleted with the release of Solaris 10; and Sun doesn't recommend setting this parameter in /etc/system even though it works as expected.
On Solaris 10 and later, this value can be changed dynamically on a per project basis with the help of resource control facilities . This is how we do it on Solaris 10 and later:
% prctl -n project.max-shm-memory -r -v 10G -i project 3
% prctl -n project.max-shm-memory -i project 3
project: 3: default
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 10.0GB - deny -
system 16.0EB max deny -
Note that changes done with prctl command on a running system are temporary, and will be lost when the system is rebooted. To make the changes permanent, create a project with projadd command as shown below:
$ projadd -p 102 -c 'eBS benchmark' -U oracle -G dba -K 'project.max-shm-memory=(privileged,10G,deny)' OASB
Finally make sure the project is created with projects -l or cat /etc/project commands.
$ projects -l
...
...
OASB
projid : 102
comment: "eBS benchmark"
users : oracle
groups : dba
attribs: project.max-shm-memory=(privileged,10737418240,deny)
$ cat /etc/project
...
...
OASB:102:eBS benchmark:oracle:dba:project.max-shm-memory=(privileged,10737418240,deny)
With these changes, Oracle would start the database up normally.
SQL> startup
ORACLE instance started.
Total System Global Area 1.0905E+10 bytes
Fixed Size 1316080 bytes
Variable Size 4429966096 bytes
Database Buffers 6442450944 bytes
Redo Buffers 31457280 bytes
Database mounted.
Database opened.
As part of a database tuning effort you increase the SGA/PGA sizes; and Oracle greets with an ORA-27102: out of memory error message. The system had enough free memory to serve the needs of Oracle.
SQL> startup
ORA-27102: out of memory
SVR4 Error: 22: Invalid argument
Diagnosis: -
$ oerr ORA 27102
27102, 00000, "out of memory"
// *Cause: Out of memory
// *Action: Consult the trace file for details
Not so helpful. Let's look the alert log for some clues.
% tail -2 alert.log
WARNING: EINVAL creating segment of size 0x000000028a006000
fix shm parameters in /etc/system or equivalent
Oracle is trying to create a 10G shared memory segment (depends on SGA/PGA sizes), but operating system (Solaris in this example) responded with an invalid argument (EINVAL) error message. There is a little hint about setting shm parameters in /etc/system.
Prior to Solaris 10, shmsys:shminfo_shmmax parameter has to be set in /etc/system with maximum memory segment value that can be created. 8M is the default value on Solaris 9 and prior versions; where as 1/4th of the physical memory is the default on Solaris 10 and later. On a Solaris 10 (or later) system, it can be verified as shown below:
% prtconf | grep Mem
Memory size: 32760 Megabytes
% id -p
uid=59008(oracle) gid=10001(dba) projid=3(default)
% prctl -n project.max-shm-memory -i project 3
project: 3: default
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 7.84GB - deny -
system 16.0EB max deny -
Now it is clear that the system is using the default value of 8G in this scenario, where as the application (Oracle) is trying to create a memory segment (10G) larger than 8G. Hence the failure.
So, the solution is to configure the system with a value large enough for the shared segment being created, so Oracle succeeds in starting up the database instance.
On Solaris 9 and prior releases, it can be done by adding the following line to /etc/system, followed by a reboot for the system to pick up the new value.
set shminfo_shmmax = 0x000000028a006000
However shminfo_shmmax parameter was obsoleted with the release of Solaris 10; and Sun doesn't recommend setting this parameter in /etc/system even though it works as expected.
On Solaris 10 and later, this value can be changed dynamically on a per project basis with the help of resource control facilities . This is how we do it on Solaris 10 and later:
% prctl -n project.max-shm-memory -r -v 10G -i project 3
% prctl -n project.max-shm-memory -i project 3
project: 3: default
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 10.0GB - deny -
system 16.0EB max deny -
Note that changes done with prctl command on a running system are temporary, and will be lost when the system is rebooted. To make the changes permanent, create a project with projadd command as shown below:
$ projadd -p 102 -c 'eBS benchmark' -U oracle -G dba -K 'project.max-shm-memory=(privileged,10G,deny)' OASB
Finally make sure the project is created with projects -l or cat /etc/project commands.
$ projects -l
...
...
OASB
projid : 102
comment: "eBS benchmark"
users : oracle
groups : dba
attribs: project.max-shm-memory=(privileged,10737418240,deny)
$ cat /etc/project
...
...
OASB:102:eBS benchmark:oracle:dba:project.max-shm-memory=(privileged,10737418240,deny)
With these changes, Oracle would start the database up normally.
SQL> startup
ORACLE instance started.
Total System Global Area 1.0905E+10 bytes
Fixed Size 1316080 bytes
Variable Size 4429966096 bytes
Database Buffers 6442450944 bytes
Redo Buffers 31457280 bytes
Database mounted.
Database opened.
Oracle 10g Installation on Solaris10
1. /etc/hosts file must contain a fully qualified name for the server:
(ip-address) (fully-qualified-machine-name) (machine-name)
2. Set Kernel Parameters
In previous versions of Solaris, kernel parameters were amended by adding entries to the "/etc/system" file, followed by a system reboot.
#set semsys:seminfo_semmni=100
#set semsys:seminfo_semmsl=256
#set shmsys:shminfo_shmmax=4294967295
#set shmsys:shminfo_shmmni=100
3. As the root user, issue the following command.
#projadd oracle
4. Append the following line to the "/etc/user_attr" file.
oracle::::project=oracle
If you've performed a default installation, it is likely that the only kernel parameter you need to alter is "max-shm-memory". To check the current value issue the following command.
# prctl -n project.max-shm-memory -i project oracle
project: 100: oracle
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 254MB - deny -
system 16.0EB max deny -
To reset this value, make sure at least one session is logged in as the oracle user, then from the root user issue the following commands.
# prctl -n project.max-shm-memory -v 4gb -r -i project oracle
# projmod -s -K "project.max-shm-memory=(priv,4gb,deny)" oracle
The first dynamically resets the value, while the second makes changes to the "/etc/project" file so the value is persistent between reboots.
# cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
oracle:100::::project.max-shm-memory=(priv,4294967296,deny)
5. The Oracle installer seems incapable of recognising kernel parameter set using resource control projects, but if you ignore the warnings the installation completes successfully.
Setup
Add the "SUNWi1cs" and "SUNWi15cs" packages using the "pkgadd" command.
# pkgadd -d /cdrom/sol_10_106_x86/Solaris_10/Product SUNWi1cs SUNWi15cs
(or) copy those directories from CD to local disk.
# pkgadd -d . SUNWi1cs
# pkgadd -d . SUNWi15cs
Processing package instance from
X11 ISO8859-1 Codeset Support(i386) 2.0,REV=2004.10.17.15.04
Copyright 2004 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
This appears to be an attempt to install the same architecture and
version of a package which is already installed. This installation
will attempt to overwrite this package.
Using as the package base directory.
## Processing package information.
## Processing system information.
16 package pathnames are already properly installed.
## Verifying package dependencies.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.
This package contains scripts which will be executed with super-user
permission during the process of installing this package.
Do you want to continue with the installation of [y,n,?] y
Installing X11 ISO8859-1 Codeset Support as
## Installing part 1 of 1.
Installation of was successful.
Processing package instance from
X11 ISO8859-15 Codeset Support(i386) 2.0,REV=2004.10.17.15.04
Copyright 2004 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
This appears to be an attempt to install the same architecture and
version of a package which is already installed. This installation
will attempt to overwrite this package.
Using as the package base directory.
## Processing package information.
## Processing system information.
21 package pathnames are already properly installed.
## Verifying package dependencies.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.
This package contains scripts which will be executed with super-user
permission during the process of installing this package.
Do you want to continue with the installation of [y,n,?] y
Installing X11 ISO8859-15 Codeset Support as
## Installing part 1 of 1.
Installation of was successful.
6. Create the new groups and users:
#groupadd oinstall
#groupadd dba
#groupadd oper
#useradd -g oinstall -G dba -d /export/home/oracle oracle
#mkdir /export/home/oracle
#chown oracle:oinstall /export/home/oracle
#passwd -r files oracle
7. Create the directories in which the Oracle software will be installed:
#mkdir -p /u01/app/oracle/product/10.2.0/db_1
#chown -R oracle:oinstall /u01
8. Login as the oracle user and add the following lines at the end of the .profile file, making sure you have set the correct ORACLE_BASE value:
# Oracle Settings
TMP=/tmp; export TMP
TMPDIR=$TMP; export TMPDIR
# Select the appropriate ORACLE_BASE
#ORACLE_BASE=/export/home/oracle; export ORACLE_BASE
ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/10.2.0/db_1; export ORACLE_HOME
ORACLE_SID=TSH1; export ORACLE_SID
PATH=$ORACLE_HOME/bin:$PATH; export PATH
9. Installation
Log into the oracle user. If you are using X emulation then set the DISPLAY environmental variable:
$DISPLAY=:0.0; export DISPLAY
10. Start the Oracle Universal Installer (OUI) by issuing the following command in the database directory:
$./runInstaller
to check Kernel value: -
#isoinfo -kv
to check RAM size: -
#prtconf | head -3 |grep Mem
(ip-address) (fully-qualified-machine-name) (machine-name)
2. Set Kernel Parameters
In previous versions of Solaris, kernel parameters were amended by adding entries to the "/etc/system" file, followed by a system reboot.
#set semsys:seminfo_semmni=100
#set semsys:seminfo_semmsl=256
#set shmsys:shminfo_shmmax=4294967295
#set shmsys:shminfo_shmmni=100
3. As the root user, issue the following command.
#projadd oracle
4. Append the following line to the "/etc/user_attr" file.
oracle::::project=oracle
If you've performed a default installation, it is likely that the only kernel parameter you need to alter is "max-shm-memory". To check the current value issue the following command.
# prctl -n project.max-shm-memory -i project oracle
project: 100: oracle
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 254MB - deny -
system 16.0EB max deny -
To reset this value, make sure at least one session is logged in as the oracle user, then from the root user issue the following commands.
# prctl -n project.max-shm-memory -v 4gb -r -i project oracle
# projmod -s -K "project.max-shm-memory=(priv,4gb,deny)" oracle
The first dynamically resets the value, while the second makes changes to the "/etc/project" file so the value is persistent between reboots.
# cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
oracle:100::::project.max-shm-memory=(priv,4294967296,deny)
5. The Oracle installer seems incapable of recognising kernel parameter set using resource control projects, but if you ignore the warnings the installation completes successfully.
Setup
Add the "SUNWi1cs" and "SUNWi15cs" packages using the "pkgadd" command.
# pkgadd -d /cdrom/sol_10_106_x86/Solaris_10/Product SUNWi1cs SUNWi15cs
(or) copy those directories from CD to local disk.
# pkgadd -d . SUNWi1cs
# pkgadd -d . SUNWi15cs
Processing package instance from
X11 ISO8859-1 Codeset Support(i386) 2.0,REV=2004.10.17.15.04
Copyright 2004 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
This appears to be an attempt to install the same architecture and
version of a package which is already installed. This installation
will attempt to overwrite this package.
Using as the package base directory.
## Processing package information.
## Processing system information.
16 package pathnames are already properly installed.
## Verifying package dependencies.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.
This package contains scripts which will be executed with super-user
permission during the process of installing this package.
Do you want to continue with the installation of [y,n,?] y
Installing X11 ISO8859-1 Codeset Support as
## Installing part 1 of 1.
Installation of was successful.
Processing package instance from
X11 ISO8859-15 Codeset Support(i386) 2.0,REV=2004.10.17.15.04
Copyright 2004 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
This appears to be an attempt to install the same architecture and
version of a package which is already installed. This installation
will attempt to overwrite this package.
Using as the package base directory.
## Processing package information.
## Processing system information.
21 package pathnames are already properly installed.
## Verifying package dependencies.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.
This package contains scripts which will be executed with super-user
permission during the process of installing this package.
Do you want to continue with the installation of [y,n,?] y
Installing X11 ISO8859-15 Codeset Support as
## Installing part 1 of 1.
Installation of was successful.
6. Create the new groups and users:
#groupadd oinstall
#groupadd dba
#groupadd oper
#useradd -g oinstall -G dba -d /export/home/oracle oracle
#mkdir /export/home/oracle
#chown oracle:oinstall /export/home/oracle
#passwd -r files oracle
7. Create the directories in which the Oracle software will be installed:
#mkdir -p /u01/app/oracle/product/10.2.0/db_1
#chown -R oracle:oinstall /u01
8. Login as the oracle user and add the following lines at the end of the .profile file, making sure you have set the correct ORACLE_BASE value:
# Oracle Settings
TMP=/tmp; export TMP
TMPDIR=$TMP; export TMPDIR
# Select the appropriate ORACLE_BASE
#ORACLE_BASE=/export/home/oracle; export ORACLE_BASE
ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/10.2.0/db_1; export ORACLE_HOME
ORACLE_SID=TSH1; export ORACLE_SID
PATH=$ORACLE_HOME/bin:$PATH; export PATH
9. Installation
Log into the oracle user. If you are using X emulation then set the DISPLAY environmental variable:
$DISPLAY=
10. Start the Oracle Universal Installer (OUI) by issuing the following command in the database directory:
$./runInstaller
to check Kernel value: -
#isoinfo -kv
to check RAM size: -
#prtconf | head -3 |grep Mem
Wednesday, September 9, 2009
MEMORY_TARGET in Oracle 11g
It is amazing memory management in Oracle 11g. Upto Oracle 9i one of the hectic process was to define the memory parameters (SGA and PGA) and there are some thumb role needs to followed for the each parameters. Now DBA sit back and relax since Oracle automated the Memory parameter completely on 11g.
Some lights on old versions:
Oracle 8i: –
db_block_buffer
shared_pool_size
large_pool_size
java_pool_size
sort_area_size
pga size,etc........
Oracle 9i: - introduced PGA_AGGREGATE_TARGET.
Oracle 10g: - Continued this era by automating SGA management using the SGA_TARGET and PGA_AGGREGATE_TARGET parameter.
Oracle 11g: - Fully automated using MEMORY_TARGET
Oracle 10g onwards this parameter automated, but again there was some sort of calculation for 2 parameters called sga_target and pga_aggregate_target. Now, you can take long breath, leave it without any difficult, because 11g all these two parameters auto tuned.
In Oracle 10g setting the sga_target, I have seen many bugs. Some people use the workaround as normal sga setting.
Automatic Memory Management (AMM) is only supported on the major platforms like AIX,Linux, Solaris, Windows, and HP-UX.
There are 2 initialization parameters for AMM confugration:
MEMORY_MAX_TARGET: - The maximum size the memor_target can be increased to without an instance restart (like earlier version sga_max_size). If the memory_max_target is not specified, it defaults to MEMORY_TARGET setting.
Using AMM, the SGA_TARGET and PGA_AGGREGATE_TARGET act as minimum size settings for their respective memory areas.
MEMORY_TARGET: - Elaborating this parameter that Shared memory available for Oracle to use when dynamically controlling the SGA and PGA. This parameter is dynamic, so the total amount of memory available to Oracle can be increased or decreased, provided it does not exceed the MEMORY_MAX_TARGET limit.
Automatic Memory Management Setup: -
The DBCA is also allows you to configure automatic memory management during database creation.
We can manually set, the appropriate MEMORY_TARGET and MEMORY_MAX_TARGET initialization parameters before creating the database or after.
Enabling automatic memory management on a system that didn't previously use it is a simple task.
Kindly use the following calculations:
MEMORY_TARGET = SGA_TARGET + GREATEST(PGA_AGGREGATE_TARGET, "maximum PGA allocated")
Assuming our required setting was 4G, we might issue the following statements.
$sqlplus “/as sysdba”
Set the static parameter. Leave some room for possible future growth without restart.
ALTER SYSTEM SET MEMORY_MAX_TARGET=5G SCOPE=SPFILE;
Set the dynamic parameters. Assuming Oracle has full control.
ALTER SYSTEM SET PGA_AGGREGATE_TARGET=0 SCOPE=SPFILE;
ALTER SYSTEM SET SGA_TARGET=0 SCOPE=SPFILE;
ALTER SYSTEM SET MEMORY_TARGET=4G SCOPE=SPFILE;
Shutdown and restart the instance: -
SHUTDOWN IMMEDIATE;
STARTUP;
The database is restarted the MEMORY_TARGET parameter can be amended as required without an instance restart.
ALTER SYSTEM SET MEMORY_TARGET=4G SCOPE=SPFILE;
Dictionary View Informations: -
V$MEMORY_TARGET_ADVICE
V$MEMORY_CURRENT_RESIZE_OPS
V$MEMORY_RESIZE_OPS
V$MEMORY_DYNAMIC_COMPONENTS
You can also, configure and get lot of information through ENERPRISE
Some lights on old versions:
Oracle 8i: –
db_block_buffer
shared_pool_size
large_pool_size
java_pool_size
sort_area_size
pga size,etc........
Oracle 9i: - introduced PGA_AGGREGATE_TARGET.
Oracle 10g: - Continued this era by automating SGA management using the SGA_TARGET and PGA_AGGREGATE_TARGET parameter.
Oracle 11g: - Fully automated using MEMORY_TARGET
Oracle 10g onwards this parameter automated, but again there was some sort of calculation for 2 parameters called sga_target and pga_aggregate_target. Now, you can take long breath, leave it without any difficult, because 11g all these two parameters auto tuned.
In Oracle 10g setting the sga_target, I have seen many bugs. Some people use the workaround as normal sga setting.
Automatic Memory Management (AMM) is only supported on the major platforms like AIX,Linux, Solaris, Windows, and HP-UX.
There are 2 initialization parameters for AMM confugration:
MEMORY_MAX_TARGET: - The maximum size the memor_target can be increased to without an instance restart (like earlier version sga_max_size). If the memory_max_target is not specified, it defaults to MEMORY_TARGET setting.
Using AMM, the SGA_TARGET and PGA_AGGREGATE_TARGET act as minimum size settings for their respective memory areas.
MEMORY_TARGET: - Elaborating this parameter that Shared memory available for Oracle to use when dynamically controlling the SGA and PGA. This parameter is dynamic, so the total amount of memory available to Oracle can be increased or decreased, provided it does not exceed the MEMORY_MAX_TARGET limit.
Automatic Memory Management Setup: -
The DBCA is also allows you to configure automatic memory management during database creation.
We can manually set, the appropriate MEMORY_TARGET and MEMORY_MAX_TARGET initialization parameters before creating the database or after.
Enabling automatic memory management on a system that didn't previously use it is a simple task.
Kindly use the following calculations:
MEMORY_TARGET = SGA_TARGET + GREATEST(PGA_AGGREGATE_TARGET, "maximum PGA allocated")
Assuming our required setting was 4G, we might issue the following statements.
$sqlplus “/as sysdba”
Set the static parameter. Leave some room for possible future growth without restart.
ALTER SYSTEM SET MEMORY_MAX_TARGET=5G SCOPE=SPFILE;
Set the dynamic parameters. Assuming Oracle has full control.
ALTER SYSTEM SET PGA_AGGREGATE_TARGET=0 SCOPE=SPFILE;
ALTER SYSTEM SET SGA_TARGET=0 SCOPE=SPFILE;
ALTER SYSTEM SET MEMORY_TARGET=4G SCOPE=SPFILE;
Shutdown and restart the instance: -
SHUTDOWN IMMEDIATE;
STARTUP;
The database is restarted the MEMORY_TARGET parameter can be amended as required without an instance restart.
ALTER SYSTEM SET MEMORY_TARGET=4G SCOPE=SPFILE;
Dictionary View Informations: -
V$MEMORY_TARGET_ADVICE
V$MEMORY_CURRENT_RESIZE_OPS
V$MEMORY_RESIZE_OPS
V$MEMORY_DYNAMIC_COMPONENTS
You can also, configure and get lot of information through ENERPRISE
MANAGER, using graphics,etc.
Tuesday, September 8, 2009
Oracle 11g Installation on Linux 5
This articles covers the Installation of Oracle Database 11g on Enterprise Linux 5 and CentOS 5. Server needs minimum 2gb RAM for the installation. Swap should have double of physical ram.
Set the Linux Kernal Parameters:
Linux Kernel Parameters
What is the Shared Memory:
Shared memory allows processes to access common structures and data by placing them in shared memory segments. It's the fastest form of IPC (Interprocess Communication) available since no kernel involvement occurs when data is passed between the processes. In fact, data does not need to be copied between the processes.
Oracle uses shared memory segments for the SGA (Shared Global Area) which is an area of memory that is shared by all Oracle background and foreground processes. The size of the SGA has a major impact to Oracle's performance since it holds database buffer cache and much more.
Setting SHMMAX Parameter
This parameter defines the maximum size in bytes for a shared memory segment. Since the SGA is comprised of shared memory, SHMMAX can potentially limit the size of the SGA.
Setting SHMMNI Parameter
This parameter sets the maximum number of shared memory segments system wide.
Setting SHMALL Parameter
This parameter sets the total amount of shared memory in bytes that can be used at one time on the system.
The SEMMSL Parameter
This parameter defines the maximum number of semaphores per semaphore set.
Oracle recommends to set SEMMSL to the largest PROCESSES init.ora parameter of any database on the Linux system.
The SEMMNI Parameter
This parameter defines the maximum number of semaphore sets in the entire Linux system.
The SEMMNS Parameter
This parameter defines the total number of semaphores (not semaphore set) in the entire Linux system.
The SEMOPM Parameter
This parameter defines the maximum number of semaphore operations that can be performed per semop(2) system call.
Setting File Handles
The maximum number of file handles denotes the maximum number of open files that you can have on the Linux system.
Setting System Wide Limit for File Handles
The value in /proc/sys/fs/file-max sets the maximum number of file handles or open files that the Linux kernel will allocate. When you get error messages about running out of file handles, then you might want to raise this limit.
Change the parameters:
#vi /etc/sysctl.conf
Add the following:
kernel.shmmax = 2147483648
kernel.shmall = 2097152
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536 # 512 * PROCESSES
net.core.rmem_default=4194304
net.core.rmem_max=4194304
net.core.wmem_default=262144
net.core.wmem_max=262144
net.ipv4.ip_local_port_range = 1024 65000
#vi /etc/hosts
IP-address Machinename.domainname Hostname
#vi /etc/security/limits.conf
Add or change /etc/security/limits.conf file:
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft nproc 2047
oracle hard nproc 16384
#vi /etc/pam.d/login
session required pam_limits.so
session required /lib/security/pam_limits.so
Very important Steps:
On secure linux has to be disabled:
#vi /etc/selinux/config
Change or add
SELINUX=disabled
The following packages(rpm) required for Enterprise Linux Disk1 :
Insert the 1st cd and mount the same: -
Go to cd /media/cdrom/Server (cd /media/cdrom/Server)
rpm -Uvh binutils-2.*
rpm -Uvh elfutils-libelf-0.*
rpm -Uvh glibc-2.*
rpm -Uvh glibc-common-2.*
rpm -Uvh libaio-0.*
rpm -Uvh libgcc-4.*
rpm -Uvh libstdc++-4.*
rpm -Uvh make-3.*
cd /
eject
Insert Disk2 Cd. Mount the CD: -
Go to cd /media/cdrom/Server (cd /media/cdrom/Server)
rpm -Uvh compat-libstdc++-33*
rpm -Uvh elfutils-libelf-devel-0.*
rpm -Uvh glibc-devel-2.*
rpm -Uvh gcc-4.*
rpm -Uvh gcc-c++-4.*
rpm -Uvh libaio-devel-0.*
rpm -Uvh libstdc++-devel-4.*
rpm -Uvh unixODBC-2.*
rpm -Uvh unixODBC-devel-2.*
cd /
eject
Insert Disk3 Cd. Mount the CD: -
Go to cd /media/cdrom/Server (cd /media/cdrom/Server)
rpm -Uvh sysstat-7.*
cd /
eject
Create user and groups: -
Adding Groups: -
groupadd oinstall
groupadd dba
groupadd asmadmin
Adding user and assign the group: -
useradd -g oinstall -G dba,oper,asmadmin oracle
Add password for Oracle user
#passwd oracle
I would like to light on the "asmadmin" group is used for ASM.
Make directories in which the Oracle Binary to be installed:
#mkdir -p /data1/app/oracle/product/11/db_1
#chown -R oracle:oinstall /data1
#chmod -R 777 /data1
#vi /home/oracle.bash_profile
Add the following: -
ORACLE_HOSTNAME=machinename.domainname
ORACLE_BASE=/data1/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/11/db_1; export ORACLE_HOME
ORACLE_SID=orcl; export ORACLE_SID
ORACLE_TERM=xterm; export ORACLE_TERM
PATH=/usr/sbin:$PATH; export PATH
PATH=$ORACLE_HOME/bin:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH
CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib; export CLASSPATH
if [ $USER = "oracle" ]; then
if [ $SHELL = "/bin/ksh" ]; then
ulimit -p 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
fi
Login as Oracle user: -
Run Install Steps:
Set the Display first
$export DISPLAY=hostname:0.0
Go setup Disk directory
$cd Disk1
$./runInstaller
Rest follow the GUI provided by Oracle
Set the Linux Kernal Parameters:
Linux Kernel Parameters
What is the Shared Memory:
Shared memory allows processes to access common structures and data by placing them in shared memory segments. It's the fastest form of IPC (Interprocess Communication) available since no kernel involvement occurs when data is passed between the processes. In fact, data does not need to be copied between the processes.
Oracle uses shared memory segments for the SGA (Shared Global Area) which is an area of memory that is shared by all Oracle background and foreground processes. The size of the SGA has a major impact to Oracle's performance since it holds database buffer cache and much more.
Setting SHMMAX Parameter
This parameter defines the maximum size in bytes for a shared memory segment. Since the SGA is comprised of shared memory, SHMMAX can potentially limit the size of the SGA.
Setting SHMMNI Parameter
This parameter sets the maximum number of shared memory segments system wide.
Setting SHMALL Parameter
This parameter sets the total amount of shared memory in bytes that can be used at one time on the system.
The SEMMSL Parameter
This parameter defines the maximum number of semaphores per semaphore set.
Oracle recommends to set SEMMSL to the largest PROCESSES init.ora parameter of any database on the Linux system.
The SEMMNI Parameter
This parameter defines the maximum number of semaphore sets in the entire Linux system.
The SEMMNS Parameter
This parameter defines the total number of semaphores (not semaphore set) in the entire Linux system.
The SEMOPM Parameter
This parameter defines the maximum number of semaphore operations that can be performed per semop(2) system call.
Setting File Handles
The maximum number of file handles denotes the maximum number of open files that you can have on the Linux system.
Setting System Wide Limit for File Handles
The value in /proc/sys/fs/file-max sets the maximum number of file handles or open files that the Linux kernel will allocate. When you get error messages about running out of file handles, then you might want to raise this limit.
Change the parameters:
#vi /etc/sysctl.conf
Add the following:
kernel.shmmax = 2147483648
kernel.shmall = 2097152
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536 # 512 * PROCESSES
net.core.rmem_default=4194304
net.core.rmem_max=4194304
net.core.wmem_default=262144
net.core.wmem_max=262144
net.ipv4.ip_local_port_range = 1024 65000
#vi /etc/hosts
IP-address Machinename.domainname Hostname
#vi /etc/security/limits.conf
Add or change /etc/security/limits.conf file:
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft nproc 2047
oracle hard nproc 16384
#vi /etc/pam.d/login
session required pam_limits.so
session required /lib/security/pam_limits.so
Very important Steps:
On secure linux has to be disabled:
#vi /etc/selinux/config
Change or add
SELINUX=disabled
The following packages(rpm) required for Enterprise Linux Disk1 :
Insert the 1st cd and mount the same: -
Go to cd /media/cdrom/Server (cd /media/cdrom/Server)
rpm -Uvh binutils-2.*
rpm -Uvh elfutils-libelf-0.*
rpm -Uvh glibc-2.*
rpm -Uvh glibc-common-2.*
rpm -Uvh libaio-0.*
rpm -Uvh libgcc-4.*
rpm -Uvh libstdc++-4.*
rpm -Uvh make-3.*
cd /
eject
Insert Disk2 Cd. Mount the CD: -
Go to cd /media/cdrom/Server (cd /media/cdrom/Server)
rpm -Uvh compat-libstdc++-33*
rpm -Uvh elfutils-libelf-devel-0.*
rpm -Uvh glibc-devel-2.*
rpm -Uvh gcc-4.*
rpm -Uvh gcc-c++-4.*
rpm -Uvh libaio-devel-0.*
rpm -Uvh libstdc++-devel-4.*
rpm -Uvh unixODBC-2.*
rpm -Uvh unixODBC-devel-2.*
cd /
eject
Insert Disk3 Cd. Mount the CD: -
Go to cd /media/cdrom/Server (cd /media/cdrom/Server)
rpm -Uvh sysstat-7.*
cd /
eject
Create user and groups: -
Adding Groups: -
groupadd oinstall
groupadd dba
groupadd asmadmin
Adding user and assign the group: -
useradd -g oinstall -G dba,oper,asmadmin oracle
Add password for Oracle user
#passwd oracle
I would like to light on the "asmadmin" group is used for ASM.
Make directories in which the Oracle Binary to be installed:
#mkdir -p /data1/app/oracle/product/11/db_1
#chown -R oracle:oinstall /data1
#chmod -R 777 /data1
#vi /home/oracle.bash_profile
Add the following: -
ORACLE_HOSTNAME=machinename.domainname
ORACLE_BASE=/data1/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/11/db_1; export ORACLE_HOME
ORACLE_SID=orcl; export ORACLE_SID
ORACLE_TERM=xterm; export ORACLE_TERM
PATH=/usr/sbin:$PATH; export PATH
PATH=$ORACLE_HOME/bin:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH
CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib; export CLASSPATH
if [ $USER = "oracle" ]; then
if [ $SHELL = "/bin/ksh" ]; then
ulimit -p 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
fi
Login as Oracle user: -
Run Install Steps:
Set the Display first
$export DISPLAY=hostname:0.0
Go setup Disk directory
$cd Disk1
$./runInstaller
Rest follow the GUI provided by Oracle
Subscribe to:
Posts (Atom)