ORA-06553: PLS-801: internal error [56319]

Few things to do

1) Running utlirp.sql (this is going to invalidate most (for me around 80,000 objects) and then recompiles them again) Took a helluva time.. but got it sorted out. in the end.

2) Had to run utlirp.sql when database is in migration mode. (remember I ported the db from 32 bit to 64 bit).

I am sure that this "IS A" solutions as now, I am getting the same error with 32bit version of oracle software. However with 64 bit I am fine. now. before this the error was with 64 bit and 32 bit was clean.

-------------- Other Scenario---------------------------------------------------------

Worked great, I had to restore a 32 bit database on a 64 bit system. After restore/recover operations with RMAN I did the following.

1) startup upgrade;
2) @?/rdbms/admin/utlirp.sql
3) shutdown immediate;
4) startup;

------------Other Scenario-----------------------------------------------------

Received the "ORA-06553: PLS-801: internal error [56319]" error after cloning a db, while trying to drop a user.

SQL> drop user QCSITEADMIN_DB0 cascade;
drop user QCSITEADMIN_DB0 cascade
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-06553: PLS-801: internal error [56319]

and it got resolved after executing "utlirp.sql".

---------------------------------------------------My scenario -----------------

SYS @ bsqrac >>conn volume/trace

ERROR:

ORA-06553: PLS-801: internal error [56327]

Error accessing package DBMS_APPLICATION_INFO

Connected.

VOLUME @ bsqrac >>

VOLUME @ bsqrac >>@utlirp.sql

VOLUME @ bsqrac >>WHENEVER SQLERROR EXIT;

VOLUME @ bsqrac >>DOC

DOC>#######################################################################

DOC>#######################################################################

DOC> The following statement will cause an "ORA-01722: invalid number"

DOC> error if there the database was not opened in UPGRADE mode

DOC>

DOC> If you encounter this error, execute "SHUTDOWN", "STARTUP UPGRADE" and

DOC> re-execute utlirp.sql

DOC>#######################################################################

DOC>#######################################################################

DOC>#

VOLUME @ bsqrac >>SELECT TO_NUMBER('MUST_BE_OPEN_UPGRADE') FROM v$instance

2 WHERE status != 'OPEN MIGRATE';

SELECT TO_NUMBER('MUST_BE_OPEN_UPGRADE') FROM v$instance

*

ERROR at line 1:

ORA-00942: table or view does not exist

Disconnected from Oracle Database 11g Release 11.2.0.1.0 - Production

With the Automatic Storage Management option

[oracle@VOL-ORATEST admin]$ s

SQL*Plus: Release 11.2.0.1.0 Production on Mon Jan 24 12:35:48 2011

Copyright (c) 1982, 2009, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Release 11.2.0.1.0 - Production

With the Automatic Storage Management option

SYS @ bsqrac >>shutdown

Database closed.

Database dismounted.

ORACLE instance shut down.

SYS @ bsqrac >>startup upgrade

ORACLE instance started.

Total System Global Area 246910976 bytes

Fixed Size 1335752 bytes

Variable Size 192941624 bytes

Database Buffers 50331648 bytes

Redo Buffers 2301952 bytes

Database mounted.

Database opened.

SYS @ bsqrac >>@utlirp.sql

......................

.........................

............................

PL/SQL procedure successfully completed.

SYS @ bsqrac >>

SYS @ bsqrac >>DOC

DOC>#######################################################################

DOC>#######################################################################

DOC> utlirp.sql completed successfully. All PL/SQL objects in the

DOC> database have been invalidated.

DOC>

DOC> Shut down and restart the database in normal mode and run utlrp.sql to

DOC> recompile invalid objects.

DOC>#######################################################################

DOC>#######################################################################

DOC>#

SYS @ bsqrac >>

SYS @ bsqrac >>shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SYS @ bsqrac >>startup

ORACLE instance started.

Total System Global Area 246910976 bytes

Fixed Size 1335752 bytes

Variable Size 192941624 bytes

Database Buffers 50331648 bytes

Redo Buffers 2301952 bytes

Database mounted.

Database opened.

SYS @ bsqrac >>

SYS @ bsqrac >>connect volumexx/xxxxx

Connected.

VOLUME @ bsqrac >>

ORA-17502: ksfdcre:5 Failed to create file +data

[oracle@VOL-ORATEST bin]$ rman target sys/xxxxx@bsquat catalog rman/xxxxx@gridem auxiliary /

Recovery Manager: Release 11.2.0.1.0 - Production on Wed Jan 19 13:12:26 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

connected to target database: BSQUAT (DBID=12345678)

connected to recovery catalog database

connected to auxiliary database: AUX (not mounted)

RMAN> duplicate target database to aux nofilenamecheck;

Starting Duplicate Db at 19-JAN-2011 13:12:37

allocated channel: ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: SID=23 device type=DISK

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of Duplicate Db command at 01/19/2011 13:12:38

RMAN-06136: ORACLE error from auxiliary database: ORA-00200: control file could not be created

ORA-00202: control file: '+data'

ORA-15045: ASM file name '+data' is not in reference form

ORA-17502: ksfdcre:5 Failed to create file +data

ORA-15081: failed to submit an I/O operation to a disk

Solution===================

Ok so for anyone else running into this issue...

the permissions of the file $ORACLE_HOME/bin/oracle must look as follow:

-r-sr-s--x 1 oracle asmadmin

in my case the file belonged to oracle:oinstall, but as stated in my previous post I changed it to oracle:asmadmin.

By changing the user and group the file permissions looked as follows:

-r-xr-x--x 1 oracle asmadmin

[root@VOL-ORATEST bin]# ls -lrt oracle

-rwsr-s--x 1 oracle oinstall 163939510 Jan 14 17:20 oracle

[root@VOL-ORATEST bin]# chown oracle:asmadmin oracle

[root@VOL-ORATEST bin]# ls -lrt oracle

-rwxr-x--x 1 oracle asmadmin 163939510 Jan 14 17:20 oracle

[root@VOL-ORATEST bin]#

BACKUPSET and BACKUP Pieces

1. Concept: A backup set is a backup that is taken using the RMAN’s BACKUP command. A backup set is a logical grouping of one or more physical (binary) files called backup pieces. By default, one backup set contains only one backup piece. A backup piece contains backed up data files, control files, or archived log files. A backup set is stored in an RMAN-specific format. Therefore, a backup set cannot be manually restored. It must be restored using the Recovery Manager (RMAN) RESTOREcommand before it can be used by Oracle. Backup sets are of two types: data file backup sets and archived log backup sets. A data file backup set is a backup of data files or control files. A data file backup set is compressed, i.e., it contains only used data blocks. An archived log backup set is a backup of archived redo logs. An archived log backup set is not compressed. A backup piece can belong to only one backup set. Backups of data files and archived redo logs cannot be stored in the same backup set. 2. Datafile in bkset and bk pieces - One bk set = one or more datafiles bkset must have at least one datafile, which means you cannot have part of a datafile(of course lar) in one dataset. The parameter MAXSETSIZE is used to limit the size of each bk set. This parameter must be larger than the size of the largest datafiles will be backed up. e.g if I have 3 datafiles with 500m, 600m, 700m, then the MAXSETSIZE must be set larger than or equal to 700m. if not, error will occurred and backup will fail. - When we can have multi. Pieces in one bkset? Set the MAXPIECESIZE RMAN> CONFIGURE MAXPIECESIZE TO500M; By default, MAXPIECESIZE is UNLIMITED; if we set the MAXPIECESIZE to 500M as this case, datafile that larger than 500M will be divided into two or more pieces. For example, backing up a datafile with 1200m will contain three pieces. - When we can have more than one bk set in each backup? Set the FILEPERSET parameter: RMAN> run{ allocate channel d1 type disk maxpiecesize =300M; backup filesperset 2 format='/u01/app/bak/db_%t_%p.bus' database; } “filesperset 2” means that each backupset contains two datafiles; if the backup contains more than 2 datafiles, say 5 datafiles, it will have 3 backup sets.

Solution of ORA-28002: the password will expire within 5 days

Error Description:
-----------------------------------
Whenever a user try to connect to database it raise ORA-28002: error.

-bash-3.00$ sqlplus Hemesh/a

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Jul 7 23:58:46 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

ERROR:
ORA-28002: the password will expire within 10 days


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

Cause of The Problem:
-----------------------------------
Lets know the user profile.
SQL> select profile from dba_users where username='HEMESH';

PROFILE
------------------------------
DEFAULT

Now lets know the resource settings 'PASSWORD_GRACE_TIME','PASSWORD_LIFE_TIME' of default profile.

SQL> select LIMIT, RESOURCE_NAME from dba_profiles where RESOURCE_NAME in ('PASSWORD_GRACE_TIME','PASSWORD_LIFE_TIME','PASSWORD_REUSE_MAX','PASSWORD_REUSE_TIME') and PROFILE=(select profile from dba_users where username='HEMESH');

LIMIT RESOURCE_NAME
---------------------------------------- --------------------------------
60 PASSWORD_LIFE_TIME
1800 PASSWORD_REUSE_TIME
UNLIMITED PASSWORD_REUSE_MAX
10 PASSWORD_GRACE_TIME

The resource PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX must be set in conjunction with each other. PASSWORD_REUSE_TIME specifies the number of days before which a password cannot be reused. PASSWORD_REUSE_MAX specifies the number of password changes required before the current password can be reused.

In this case our interested resource is PASSWORD_LIFE_TIME and PASSWORD_GRACE_TIME.

The resource of Default profile PASSWORD_LIFE_TIME specify the number of days the same password can be used for authentication.

The resource PASSWORD_GRACE_TIME specify the number of days after the grace period begins during which a warning is issued and login is allowed. If the password is not changed during the grace period, the password expires.

Here in the profile of HEMESH user the value of PASSWORD_GRACE_TIME is set to 10. So it just arises a warning ORA-28002 but still allow users to logon to database. The password will expire if it is not changed within the grace period, and further connections are rejected. If you do not set a value for PASSWORD_GRACE_TIME, its default of UNLIMITED will cause the database to issue a warning but let the user continue to connect indefinitely.

One may interpret wrongly of parameter PASSWORD_LIFE_TIME with account creation time. Actually the PASSWORD_LIFE_TIME limit of a profile is measured from the last time an account's password was changed or the account creation time if the password has never been changed.

The account creation time and password change time can be seen from USER$.CTIME and USER$.PTIME respectively. Like,
SQL> select ctime, ptime from sys.user$ where name='HEMESH';

CTIME PTIME
--------- ---------
08-MAY-08 08-MAY-08

You can also get the account creation time from dba_users view.
SQL> SELECT CREATED FROM DBA_USERS WHERE USERNAME = 'HEMESH';

CREATED
---------
08-MAY-08

Now let's look current time which is 08-JUL-08
SQL> select sysdate from dual;

SYSDATE
---------
08-JUL-08

So between the password change time and current time there it is passed 60 which is equal to PASSWORD_LIFE_TIME. Now the setting of PASSWORD_GRACE_TIME to 10 allow the user HEMESH to connect to database 10 days more but will issue a warning.

Solution of The Problem:
--------------------------------------
A)Change the user password.
------------------------------------
If you just want to avoid the error temporary then change the user password.
SQL> conn Hemesh/a
ERROR:
ORA-28002: the password will expire within 10 days
SQL> password
Changing password for HEMESH
Old password:
New password:
Retype new password:
Password changed
SQL> conn Hemesh/a!12
Connected.

Now you can see the change time by .
SQL> select ctime, ptime from sys.user$ where name='HEMESH';

CTIME PTIME
--------- ---------
08-MAY-08 08-JUL-08

This is a temporary solution. After 60 days the user will again see the warning message.

B)Change PASSWORD_LIFE_TIME resource of profile assigned to user.
----------------------------------------------------------------------------------------

The permanent solution is to change PASSWORD_LIFE_TIME resource of profile DEFAULT which is assigned to user HEMESH.

SQL> select profile from dba_users where username='HEMESH';

PROFILE
------------------------------
DEFAULT
If you make it unlimited then user never will see above error. Like,
SQL> ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

Profile altered.

SQL > select * from dba_users where username='HEMESH';

ACCOUNT_STATUS = Expired(GRACED)

SQL> ALTER USER HEMESHidentified by newpassworld;

user altered.

SQL > select * from dba_users where username='HEMESH';

ACCOUNT_STATUS = OPEN

******************* Open an Expired Account***********************************

SQL> select account_status from dba_users where username='THOMAS';

ACCOUNT_STATUS

--------------------------------

EXPIRED

Up to 10g ) SQL> select password from dba_users where username='THOMAS';

from 11g) SQL>select password from SYS.user$ where name ='THOMAS';

PASSWORD

-----------------------------

063D8DE086C2860D

SQL> alter user thomas identified by values '063D8DE086C2860D';

User altered.

SQL> select account_status from dba_users where username='THOMAS';

ACCOUNT_STATUS

--------------------------------

OPEN

SQL> conn thomas/thomas

Connected.

FLASHBACK Database

============== How enable Flashback database =================================
shutdown immediate;
startup mount exclusive;
alter database archivelog;
alter database flashback on;
alter database open;

SELECT flashback_on, log_mode
FROM v$database;

SELECT name, value
FROM gv$parameter
WHERE name LIKE '%flashback%';

-- 2 days
alter system set DB_FLASHBACK_RETENTION_TARGET=2880;

SELECT name, value
FROM gv$parameter
WHERE name LIKE '%flashback%';

SELECT estimated_flashback_size FROM gv$flashback_database_log;

===================== How to use Flashback Database==================================
SELECT current_scn FROM v$database;

--oldest flashback log
SELECT oldest_flashback_scn,oldest_flashback_time FROM gv$flashback_database_log;

GRANT flashback any table TO uwclass;

CREATE RESTORE POINT bef_damage;



=======================Action==========================================
shutdown immediate;
startup mount exclusive;

-- check the flashback of incarnation is possible with restore point;
SELECT SCN,DATABASE_INCARNATION#,GUARANTEE_FLASHBACK_DATABASE,TIME,NAME FROM  V$RESTORE_POINT;

       SCN DATABASE_INCARNATION# GUA TIME                                     NAME
---------- --------------------- --- ---------------------------------------- ---------------
   9400175                     4 NO  24-JAN-12 11.53.19.000000000 AM          BEF_DAMAGE
   9400227                     4 NO  24-JAN-12 11.54.57.000000000 AM          AFTER_INSERT
   9400855                     6 NO  24-JAN-12 12.05.22.000000000 PM          LAST_POINT
   9330796                     8 NO  24-JAN-12 12.16.48.000000000 PM          BEF_IMAGE
   9330823                     8 NO  24-JAN-12 12.17.40.000000000 PM          AFTER_INSERT2
   9331462                     9 NO  24-JAN-12 12.30.02.000000000 PM          AFTER_INSERT3
   9331119                    10 NO  24-JAN-12 12.32.38.000000000 PM          AFTER_INSERT4



SELECT INCARNATION#,PRIOR_INCARNATION#,RESETLOGS_TIME,STATUS,FLASHBACK_DATABASE_ALLOWED from V$DATABASE_INCARNATION;

INCARNATION# PRIOR_INCARNATION# RESETLOGS STATUS  FLASHBACK_DATABASE_ALLOWED
------------ ------------------ --------- ------- --------------------------
           1                  0 30-JUN-05 PARENT  NO
           2                  1 30-MAR-11 PARENT  NO
           3                  2 20-JAN-12 PARENT  NO
           4                  3 20-JAN-12 PARENT  NO
           5                  4 24-JAN-12 ORPHAN  NO
           6                  4 24-JAN-12 ORPHAN  NO
           7                  4 24-JAN-12 PARENT  YES
           8                  7 24-JAN-12 PARENT  YES
           9                  8 24-JAN-12 ORPHAN  YES
          10                  8 24-JAN-12 ORPHAN  YES
          11                  9 24-JAN-12 ORPHAN  YES

INCARNATION# PRIOR_INCARNATION# RESETLOGS STATUS  FLASHBACK_DATABASE_ALLOWED
------------ ------------------ --------- ------- --------------------------
          12                  8 24-JAN-12 CURRENT YES


-- be sure to substitute your SCN
FLASHBACK DATABASE TO SCN 19513917;
or
FLASHBACK DATABASE TO RESTORE POINT bef_damage;


/*
FLASHBACK DATABASE TO TIMESTAMP (SYSDATE-1/24);
FLASHBACK DATABASE TO TIMESTAMP timestamp'2002-11-05 14:00:00';
FLASHBACK DATABASE 
TO TIMESTAMP to_timestamp('2002-11-11 16:00:00', 'YYYY-MM-DD HH24:MI:SS');
*/

-- this will fail
alter database open;

-- this will succeed
alter database open resetlogs;

Oracle 11Gr2 Installation Pre-Task

2.1 Creating Groups and User for Oracle

Open a terminal window and login as the root user.

[root@~]# groupadd -g 1000 oinstall
      

[root@~]# groupadd -g 1200 asmadmin

[root@~]# groupadd -g 1300 dba

[root@~]# groupadd -g 1301 oper
      

[root@~]# groupadd -g 1201 asmdba
      

[root@~]# useradd -m -u 1101 -g oinstall -G dba,oper,asmdba -d /home/oracle -s /bin/bash -c "Oracle Software Owner" oracle

[root@~]# Id oracle

[root@~]# Passwd oracle
      

(Not Needed in 11GR2 DATABASE Installation)
      

[root@~]# groupadd -g 1202 asmoper
      

[root@racnode1 ~]# useradd -m -u 1100 -g oinstall -G asmadmin,asmdba,asmoper -d /home/grid -s /bin/bash -c "Grid Infrastructure Owner" grid 
      

2.2 Configure Oracle Installation Owner Shell Limits
For information, review "Configuring the oracle User's Environment"

To improve the performance of the software, you must increase the following shell limits for the oracle and grid user:

Shell Limit			Item in limits.conf	Hard Limit
Maximum number of open file descriptors			nofile	65536
Maximum number of processes available to a single user			nproc	16384
Maximum size of the stack segment of the process			stack	10240

To increase the shell limits:
Note:
Depending on your environment, make the following changes for all Oracle installation owners. The steps below only show the user oracle.

1. Add the following lines to the /etc/security/limits.conf file: (the following example shows only the software account owner oracle):
2. oracle soft nproc 2047
3. oracle hard nproc 16384
4. oracle soft nofile 1024
5. oracle hard nofile 65536
6. Add or edit the following line in the /etc/pam.d/login file, if it does not already exist:
   session required pam_limits.so

2.3 Configuring Kernel Parameters
During installation, you can generate and run the Fixup script to check and set the kernel parameter values required for successful installation of the database. This script updates required kernel packages if necessary to minimum values.
If you cannot use the Fixup scripts, then verify that the kernel parameters shown in the following table are set to values greater than or equal to the minimum value shown. The procedure following the table describes how to verify and set the values manually.
Note:
The kernel parameter and shell limit values shown in the following section are minimum values only. For production database systems, Oracle recommends that you tune these values to optimize the performance of the system. Refer to the operating system documentation for more information about tuning kernel parameters.2.8.1 Configuring Kernel Parameters for Linux

Parameter	Minimum Value	File
semmsl semmns semopm semmni	250 32000 100 128	/proc/sys/kernel/sem
shmall	2097152	/proc/sys/kernel/shmall
shmmax	Either 4 GB - 1 byte, or half the size of physical memory (in bytes), whichever is lower. Default: 536870912	/proc/sys/kernel/shmmax
shmmni	4096	/proc/sys/kernel/shmmni
file-max	6815744	/proc/sys/fs/file-max
aio-max-nr	Maximum: 1048576 Note: This value limits concurrent outstanding requests and should be set to avoid I/O subsystem failures.	/proc/sys/fs/aio-max-nr
ip_local_port_range	Minimum: 9000 Maximum: 65500	/proc/sys/net/ipv4/ip_local_port_range
rmem_default	262144	/proc/sys/net/core/rmem_default
rmem_max	4194304	/proc/sys/net/core/rmem_max
wmem_default	262144	/proc/sys/net/core/wmem_default
wmem_max	1048576	/proc/sys/net/core/wmem_max

Note:
If the current value for any parameter is greater than the value listed in this table, then the Fixup scripts do not change the value of that parameter.
2.8.2 Displaying and Changing Kernel Parameter Values
Enter the commands shown in the following table to display the current values of the kernel parameters, make a note of these values and identify any values that you must change:

Parameter	Command
semmsl, semmns, semopm, and semmni	# /sbin/sysctl -a | grep sem This command displays the value of the semaphore parameters in the order listed.
shmall, shmmax, and shmmni	# /sbin/sysctl -a | grep shm This command displays the details of the shared memory segment sizes.
file-max	# /sbin/sysctl -a | grep file-max This command displays the maximum number of file handles.
ip_local_port_range	# /sbin/sysctl -a | grep ip_local_port_range This command displays a range of port numbers.
rmem_default	# /sbin/sysctl -a | grep rmem_default
rmem_max	# /sbin/sysctl -a | grep rmem_max
wmem_default	# /sbin/sysctl -a | grep wmem_default
wmem_max	# /sbin/sysctl -a | grep wmem_max
aio-max-nr	# /sbin/sysctl -a | grep aio-max-nr

If the value of any kernel parameter is different from the minimum value, then perform the following: edit /etc/sysctl.conf
#ADDED BY HEMESH 28/04/2010
fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
#kernel.shmmax = 536870912
#kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048586
net.ipv4.tcp_wmem = 262144 262144 262144
net.ipv4.tcp_rmem = 4194304 4194304 4194304
After updating the values of kernel parameters in the /etc/sysctl.conf file, either restart the computer, or run the command sysctl -p to make the changes in the /etc/sysctl.conf file available in the active kernel memory.

]# sysctl –p

OR

Configure Kernel Parameters Oracle Database 11g release 2 on RHEL/OEL 5 requires the kernel parameter settings shown below. The values given are minimums, so if your system uses a larger value, do not change it. kernel.shmmax = 4294967295 kernel.shmall = 2097152 kernel.shmmni = 4096 kernel.sem = 250 32000 100 128 fs.file-max = 6815744 net.ipv4.ip_local_port_range = 9000 65500 net.core.rmem_default=262144 net.core.rmem_max=4194304 net.core.wmem_default=262144 net.core.wmem_max=1048576 fs.aio-max-nr=1048576 RHEL/OEL 5 already comes configured with default values defined for the following kernel parameters: kernel.shmall kernel.shmmax Use the default values if they are the same or larger than the required values. This article assumes a fresh new install of Oracle Enterprise Linux 5 and as such, many of the required kernel parameters are already set (see above). This being the case, you can simply copy / paste the following to both Oracle RAC nodes while logged in as root: [root@racnode1 ~]# cat >> /etc/sysctl.conf <<EOF # Controls the maximum number of shared memory segments system wide kernel.shmmni = 4096 # Sets the following semaphore values: # SEMMSL_value SEMMNS_value SEMOPM_value SEMMNI_value kernel.sem = 250 32000 100 128 # Sets the maximum number of file-handles that the Linux kernel will allocate fs.file-max = 6815744 # Defines the local port range that is used by TCP and UDP # traffic to choose the local port net.ipv4.ip_local_port_range = 9000 65500 # Default setting in bytes of the socket "receive" buffer which # may be set by using the SO_RCVBUF socket option net.core.rmem_default=262144 # Maximum setting in bytes of the socket "receive" buffer which # may be set by using the SO_RCVBUF socket option net.core.rmem_max=4194304 # Default setting in bytes of the socket "send" buffer which # may be set by using the SO_SNDBUF socket option net.core.wmem_default=262144 # Maximum setting in bytes of the socket "send" buffer which # may be set by using the SO_SNDBUF socket option net.core.wmem_max=1048576 # Maximum number of allowable concurrent asynchronous I/O requests requests fs.aio-max-nr=1048576 EOF Activate All Kernel Parameters for the System The above command persisted the required kernel parameters through reboots by inserting them in the /etc/sysctl.conf startup file. Linux allows modification of these kernel parameters to the current system while it is up and running, so there's no need to reboot the system after making kernel parameter changes. To activate the new kernel parameter values for the currently running system, run the following as root on both Oracle RAC nodes in the cluster: [root@racnode1 ~]# sysctl -p net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 kernel.sysrq = 0 kernel.core_uses_pid = 1 net.ipv4.tcp_syncookies = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 68719476736 kernel.shmall = 4294967296 kernel.shmmni = 4096 kernel.sem = 250 32000 100 128 fs.file-max = 6815744 net.ipv4.ip_local_port_range = 9000 65500 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576 fs.aio-max-nr = 1048576 Verify the new kernel parameter values by running the following on both Oracle RAC nodes in the cluster: [root@racnode1 ~]# /sbin/sysctl -a | grep shm vm.hugetlb_shm_group = 0 kernel.shmmni = 4096 kernel.shmall = 4294967296 kernel.shmmax = 68719476736 [root@racnode1 ~]# /sbin/sysctl -a | grep sem kernel.sem = 250 32000 100 128 [root@racnode1 ~]# /sbin/sysctl -a | grep file-max fs.file-max = 6815744 [root@racnode1 ~]# /sbin/sysctl -a | grep ip_local_port_range net.ipv4.ip_local_port_range = 9000 65500 [root@racnode1 ~]# /sbin/sysctl -a | grep 'core\.[rw]mem' net.core.rmem_default = 262144 net.core.wmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_max = 1048576

2.4 Creating an Oracle Base Directory

Create the directory for the software installation and assign ownership to oracle:oinstall.

$ mkdir -p /u01/app/oracle

$ chown -R oracle:oinstall /u01/app/

$ chmod -R 775 /u01/app/oracle

• /u01 owned by root.
• /u01/app/oracle owned by oracle:oinstall with 775 permissions.
• 
  

  2.4 Setting /home/oracle/.bash_profile for the Oracle user

  # .bash_profile

  # Get the aliases and functions

  if [ -f ~/.bashrc ]; then

  . ~/.bashrc

  fi

  umask 022

  # User specific environment and startup programs

  export ORACLE_BASE=/u01/app/oracle

  export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1

  export PATH=/usr/sbin:$PATH

  export PATH=$ORACLE_HOME/bin:$PATH

  export ORACLE_TERM=xterm

  export LD_LIBRARY_PATH=$ORACLE_HOME/lib

  export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/lib:/usr/lib:/usr/local/lib

  export CLASSPATH=$ORACLE_HOME/JRE

  export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/jlib

  export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/rdbms/jlib

  export TEMP=/tmp

  export TMPDIR=/tmp

  
  
  

  unset ORACLE_HOME

  unset TNS_ADMIN

  
  
  Note:
  If the ORACLE_HOME environment variable is set, then Oracle Universal Installer uses the value that it specifies as the default path for the Oracle home directory. However, if you set the ORACLE_BASE environment variable, then Oracle recommends that you unset the ORACLE_HOME environment variable and choose the default path suggested by Oracle Universal Installer. Update the default shell startup file for the "oracle" UNIX account.
  For the Bourne, Bash, or Korn shell, we add the following lines to the /etc/profile file by running the following command:
  

  cat >> /etc/profile <<EOF

  if [ \$USER = "oracle" ]; then

  if [ \$SHELL = "/bin/ksh" ]; then

  ulimit -p 16384

  ulimit -n 65536

  else

  ulimit -u 16384 -n 65536

  fi

  umask 022

  fi

  EOF