Manually dropping EM repository

. Login to SQLPLUS as user SYS or SYSTEM, and drop the sysman account & mangement objects:

-> Clean up the Db Console repository
a. drop user sysman cascade;
b. drop role MGMT_USER;
c. drop user MGMT_VIEW cascade;
d. drop public synonym MGMT_TARGET_BLACKOUTS;
e. drop public synonym SETEMVIEWUSERCONTEXT;
f. issue a “commit;”

B. Export the correct values for the ORACLE_HOME and ORACLE_SID environment variables

C. Change directories to the $ORACLE_HOME/bin directory

D. Cleanup the External DB Console Configuration files by issuing:
emca -deconfig dbcontrol db -repos drop

E. Recreate the DB Console Repository & external Configuration files by issuing:
emca -config dbcontrol db -repos create

HugePages on Linux

•Page Table: A page table is the data structure of a virtual memory system in an operating system to store the mapping between virtual addresses and physical addresses. This means that on a virtual memory system, the memory is accessed by first accessing a page table and then accessing the actual memory location implicitly.

•TLB: A Translation Lookaside Buffer (TLB) is a buffer (or cache) in a CPU that contains parts of the page table. This is a fixed size buffer being used to do virtual address translation faster.
•hugetlb: This is an entry in the TLB that points to a HugePage (a large/big page larger than regular 4K and predefined in size). HugePages are implemented via hugetlb entries, i.e. we can say that a HugePage is handled by a “hugetlb page entry”. The ‘hugetlb” term is also (and mostly) used synonymously with a HugePage (See Note 261889.1). In this document the term “HugePage” is going to be used but keep in mind that mostly “hugetlb” refers to the same concept.
•hugetlbfs: This is a new in-memory filesystem like tmpfs and is presented by 2.6 kernel. Pages allocated on hugetlbfs type filesystem are allocated in HugePages.

Some HugePages Facts/Features
•HugePages can be allocated on-the-fly but they must be reserved during system startup. Otherwise the allocation might fail as the memory is already paged in 4K mostly.

•HugePage sizes vary from 2MB to 256MB based on kernel version and HW architecture (See related section below.)

•HugePages are not subject to reservation / release after the system startup unless there is system administrator intervention, basically changing the hugepages configuration (i.e. number of pages available or pool size)

Advantages of HugePages Over Normal Sharing Or AMM (see below)

•Not swappable: HugePages are not swappable. Therefore there is no page-in/page-out mechanism overhead.HugePages are universally regarded as pinned.
•Relief of TLB pressure:

◦HugePages will let less translations to be loaded into the TLB when purge the TLB
◦TLB entries will cover a larger part of the address space when use HugePages, there will be fewer TLB misses before the entire or most of the SGA is mapped in the SGA
◦Fewer TLB entries for the SGA also means more for other parts of the address space

•Decreased page table overhead: Each page table entry can be as large as 64 bytes and if we are trying to handle 50GB of RAM, the pagetable will be approximately 800MB in size which is practically will not fit in 880MB size lowmem (in 2.4 kernels – the page table is not necessarily in lowmem in 2.6 kernels) considering the other uses of lowmem. When 95% of memory is accessed via 256MB hugepages, this can work with a page table of approximately 40MB in total. See also Document 361468.1.

•Eliminated page table lookup overhead: Since the pages are not subject to replacement, page table lookups are not required.

•Faster overall memory performance: On virtual memory systems each memory operation is actually two abstract memory operations. Since there are less number of pages to work on, the possible bottleneck on page table access is clearly avoided.

The actual size of the HugePage on a specific system can be checked by:

$ grep Hugepagesize /proc/meminfo

Kernel Version 2.4

The kernel parameter used for HugePages is vm.hugetlb_pool which is based on MB of memory. RHEL3, Asianux 1.0, SLES8 (Service Pack 3 and over) are examples of distributions with the 2.4 kernels with HugePages support. For the configuration, follow steps below:

1. Start instance(s)
2. Calculate hugetlb_pool using script from Note 401749.1
3. Set kernel parameter:
# sysctl -w vm.hugetlb_pool=
and make sure that the parameter is persistent to reboots. e.g. On Asianux 1.0 by editing /etc/sysctl.conf adding/modifying as below:
vm.hugetlb_pool=

4. Check available hugepages:
$ grep Huge /proc/meminfo

5. Restart instances
6. Check available hugepages:
$ grep Huge /proc/meminfo

Notes:

•If the setting of hugetlb_pool is not effective, you will need to reboot the server to make HugePages allocation during system startup.
•The HugePages are allocated in a lazy fashion, so the “Hugepages_Free” count drops as the pages get touched and are backed by physical memory. The idea is that it’s more efficient in the sense that you don’t use memory you don’t touch.
•If you had set the instance initialization parameter PRE_PAGE_SGA=TRUE (for suitable settings see Document 30793.1), all of the pages would be allocated from HugePages up front.

Kernel Version 2.6

The kernel parameter used for HugePages is vm.nr_hugepages which is based on the number of the pages. SLES9, RHEL4 and Asianux 2.0 are examples of distributions with the 2.6 kernel. For the configuration, follow steps below:

1. Start instance(s)
2. Calculate nr_hugepages using script from Document 401749.1
3. Set kernel parameter:
# sysctl -w vm.nr_hugepages=
and make sure that the parameter is persistent to reboots. e.g. On SLES9:
# chkconfig boot.sysctl on

6. Check available hugepages:
$ grep Huge /proc/meminfo

7. Restart instances
8. Check available hugepages:
$ grep Huge /proc/meminfo

Notes:

•If the setting of nr_hugepages is not effective, you will need to reboot the server to make HugePages allocation during system startup.
•The HugePages are allocated in a lazy fashion, so the “Hugepages_Free” count drops as the pages get touched and are backed by physical memory. The idea is that it’s more efficient in the sense that you don’t use memory you don’t touch.
•If you had set the instance initialization parameter PRE_PAGE_SGA=TRUE (for suitable settings see Document 30793.1), all of the pages would be allocated from HugePages up front.

How to Configure
The configuration steps below will guide you to do a persistent system configuration where you would need to do a complete reboot of the system. Please plan your operations accordingly:

Step 1: Have the memlock user limit set in /etc/security/limits.conf file. Set the value (in KB) slightly smaller than installed RAM. e.g. If you have 64GB RAM installed, you may set:

* soft memlock 60397977
* hard memlock 60397977
There is no harm in setting this value large than your SGA requirements.

The parameters will be set by default on:

•Oracle Linux with oracle-validated package (See Document 437743.1) installed.
•Oracle Exadata DB compute nodes

@ See also Document 1284261.1 for Exadata

Step 2: Re-logon to the Oracle product owner account (e.g. ‘oracle’) and check the memlock limit

$ ulimit -l
60397977
Step 3: If you have Oracle Database 11g or later, the default database created uses the Automatic Memory Management (AMM) feature which is incompatible with HugePages. Disable AMM before proceeding. To disable, set the initialization parameters MEMORY_TARGET and MEMORY_MAX_TARGET to 0 (zero). Please see Document 749851.1 for further information.

Step 4: Make sure that all your database instances are up (including ASM instances) as they would run on production. Use the script hugepages_settings.sh in Document 401749.1 to calculate the recommended value for the vm.nr_hugepages kernel parameter. e.g.:
$ ./hugepages_settings.sh
…
Recommended setting: vm.nr_hugepages = 1496
$
Note: You can also calculate a proper value for the parameter yourself but that is not advised if you do not have extensive experience with HugePages and concepts.

Step 5: Edit the file /etc/sysctl.conf and set the vm.nr_hugepages parameter there:

…
vm.nr_hugepages = 1496
…
This will make the parameter to be set properly with each reboot.

Step 6: Stop all the database instances and reboot the server

Check and Validate the Configuration
# grep HugePages /proc/meminfo
HugePages_Total: 1496
HugePages_Free: 485
HugePages_Rsvd: 446
HugePages_Surp: 0

Troubleshooting
Some of the common problems and how to troubleshoot them are listed in the following table:
Symptom
Possible Cause
Troubleshooting Action

System is running out of memory or swapping
Not enough HugePages to cover the SGA(s) and therefore the area reserved for HugePages are wasted where SGAs are allocated through regular pages.
Review your HugePages configuration to make sure that all SGA(s) are covered.

Databases fail to start
memlock limits are not set properly
Make sure the settings in limits.conf apply to database owner account.

One of the database fail to start while another is up
The SGA of the specific database could not find available HugePages and remaining RAM is not enough.
Make sure that the RAM and HugePages are enough to cover all your database SGAs

Cluster Ready Services (CRS) fail to start
HugePages configured too large (maybe larger than installed RAM)
Make sure the total SGA is less than the installed RAM and re-calculate HugePages.

HugePages_Total = HugePages_Free
HugePages are not used at all. No database instances are up or using AMM.
Disable AMM and make sure that the database instances are up.

Database started successfully and the performance is slow
The SGA of the specific database could not find available HugePages and therefore the SGA is handled by regular pages, which leads to slow performance
Make sure that the HugePages are many enough to cover all your database SGAs

Applying Patchset with a 10g Physical Standby in Place

1. Log in to the oracle account on both the primary and standby hosts and make sure the environment is set to the correct ORACLE_HOME and ORACLE_SID.
2. On both the primary and standby host uncompress and untar the downloaded patchset or interim patch file into a new directory.
3. Shut down the existing Oracle Database instance on the primary host with normal or immediate priority. Stop all listeners, agents and other processes running against the ORACLE_HOME. If using Real Application Clusters perform this step on all nodes. If Automatic Storage Management (ASM) is running, shut down all databases that use ASM, then shut down the ASM instance.

   SQL> shutdown immediate

   % emctl stop

   % lsnrctl stop

   On RAC systems, if node applications are running in the RAC ORACLE_HOME:

   1. Shut down all RAC instances.

   2. Shut down all ASM instances.

   3. Stop all node applications.

   4. Shut down CRS processes on all nodes.

4. Cancel managed recovery on the standby database.

   SQL> recover managed standby database cancel;

5. Shutdown the standby instance on the standby host. Stop all listeners, agents and other processes running against the ORACLE_HOME. If using Real Application Clusters perform this step on all nodes. If Automatic Storage Management (ASM) is running, shut down all databases that use ASM, then shut down the ASM instance.

   SQL> shutdown immediate
   % emctl stop
   % lsnrctl stop

   On RAC systems, if node applications are running in the RAC ORACLE_HOME:

   1. Shut down all RAC instances.

   2. Shut down all ASM instances.

   3. Stop all node applications.

   4. Shut down CRS processes on all nodes.

6. Use ‘runInstaller’ to install the patchset or Opatch for an interim patch.  Do this on both the primary and standby ORACLE_HOME.  Refer to the patchset Release Notes or interim patch README for further install details.

   % ./runInstaller

   or

   % opatch apply <patch ID>

7. Once the patchset or interim patch has been installed on on all hosts / nodes, startup the standby listener on the standby host first.

   % lsnrctl start

8. Startup mount the standby database.

   % sqlplus “/ as sysdba”
   SQL> startup mount

9. Place the standby database in managed recovery mode.

   SQL> recover managed standby database nodelay disconnect;

10. Startup the primary instance on the primary host.

    % sqlplus “/ as sysdba”
    SQL> STARTUP UPGRADE 

    If applying an interim patch and no SQL scripts need to be run per the README, startup the primary normally and skip steps #12 thru #16.

11. Ensure that remote archiving to the standby database is functioning correctly by switching logfiles on the primary and verifying that v$archive_dest.status is valid. If not performing remote archiving make note of the current archive log sequence.

    SQL> alter system archive log current;

    SQL> select dest_id, status from v$archive_dest;

12. On the primary instance run the following script:

    SQL> SPOOL patch.log
    SQL> @?/rdbms/admin/catpatch.sql
    SQL> spool off

    Or whatever scripts are needed as outlined by the interim patch README.

13. Once the SQL script completes make note of the current log sequence and issue the following command:

    SQL> alter system archive log current;

14. Restart the primary database:

    SQL> SHUTDOWN
    SQL> STARTUP

15. Verify the standby database has been recovered to the log sequence from step 13.

    SQL> select max(sequence#) from v$log_history; 

16. Complete the remainder of the “Post Install Actions” from the Patch Set readme on the primary host. Please note that it is not necessary to shudown the standby in conjunction with the primary during the “Post Install Actions”.
17. Once all actions have been completed verify the standby database has been recovered to the last archive log produced by the primary.

    On the primary:

    SQL> select max(sequence#) from v$archived_log;

    On the standby:

    SQL> select max(sequence#) from v$log_history;

How to change ports for DB Control 10.2.x.x

Ports used by the DB Control for RDBMS 10.2.x.x

When the DB Control is initially configured, it uses a set of default system ports.
If this is the first DB Control configured on the node, the default ports are:
DB Control HTTP port: 1158
RMI port: 5521
JMS port: 5541
DB Control Agent port: 3938

Each new configuration of a DB Control on the node uses a set of default system ports, each port number being incremented by 1.

DB Control HTTP and Agent ports are stored in the file portlist.ini located in the RDBMS $ORACLE_HOME/install directory.
If you have several DB Control configured on a node, DB Control HTTP and Agent ports are stored in the same file portlist.ini.

The utility emca reads the file portlist.ini to check which ports are already used.

Difference between 10.1.x.x DB Control and 10.2.x.x DB Control

In release 10.1.x.x, it was possible to change the port numbers used by DB Control components by manually updating several configuration files.
See the note Note 289966.1 How to Change the Port Numbers for DB Control

In release 10.2.x.x, you must use the emca command-line to change the port numbers allocated to a DB Control
This is also documented in:
Enterprise Manager Advanced Configuration – Chapter 1.2.6.6 Specifying the Ports Used By the Database Control
available on OTN: http://download.oracle.com/docs/cd/B16240_01/doc/nav/portal_booklist.htm

It is possible to change one, some or all four port numbers in one emca command-line

Change DB Control port numbers on a single node

ORACLE_HOME must be set
ORACLE_HOME and ORACLE_HOME/bin must be set in the environment variable PATH

Launch emca in interactive mode

$ emca -reconfig ports [-DBCONTROL_HTTP_PORT <port_number>] [-RMI_PORT <port_number>] [-JMS_PORT <port_number>] [-AGENT_PORT <port_number>]

Example:
$ emca -reconfig ports -DBCONTROL_HTTP_PORT 1160 -AGENT_PORT 3940 -RMI_PORT 5523 -JMS_PORT 5543

Enter the following information:
Database SID: db102

This emca command does the following:

1. stops the DB Control
2. updates the port number in the following files in $ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_sid/config
   • rmi.xml
   • jms.xml
   • http-web-site.xml
3. updates the port number in the following files in $ORACLE_HOME/install
   • portlist.ini
   • readme.txt
4. updates the port number in the following files in $ORACLE_HOME/hostname_sid/sysman/config
   • emoms.properties
   • emd.properties
5. starts the DB Control

Log files to check:
emca log file for this operation is located in $ORACLE_HOME/cfgtoollogs/emca/sid.
emca log file name is in format emca_<timestamp_of_the_operation>.log

Launch emca in silent mode:
It is also possible to execute this command in silent mode with parameters provided in a response file:

$ emca -reconfig ports -silent -respFile /oracle/app/oracle/admin/db102/scripts/emca_port_change.rsp

Example of response file: /oracle/app/oracle/admin/EM102/scripts/emca_port_change.rsp
SID=db102
DBCONTROL_HTTP_PORT=1160
RMI_PORT=5523
JMS_PORT=5543
AGENT_PORT=3940

Change DB Control port numbers on a RAC node

ORACLE_HOME must be set.
ORACLE_HOME and ORACLE_HOME/bin must be present in the environment variable PATH.

The command can be executed from any node of the cluster.

DBCONTROL_HTTP_PORT,  RMI_PORT, JMS_PORT and AGENT_PORT  numbers are the same on each node of the cluster for a DB Control monitoring the same RAC database.
Hence it is not possible to change the port number of DBCONTROL_HTTP_PORT on one node of the cluster, without changing DBCONTROL_HTTP_PORT on all nodes of the cluster with same value. This is true for all DB Control ports (DBCONTROL_HTTP_PORT, RMI_PORT, JMS_PORT and AGENT_PORT).

Launch emca in interactive mode

$ emca -reconfig ports -cluster -DBCONTROL_HTTP_PORT <port_number> -RMI_PORT <port_number> -JMS_PORT <port_number> -AGENT_PORT <port_number>

Example:
$ emca -reconfig ports -cluster -DBCONTROL_HTTP_PORT 1159 -AGENT_PORT 3939 -RMI_PORT 5522 -JMS_PORT 5542

Enter the following information:
Database unique name: db102


This emca command does the following:

1. stops the DB Control on all nodes of the cluster where a DB Control is configured for this database

2. updates the port number in the following files in all sub-directories
    $ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname<i>_sid<i>/config on the local node
    and deploys the changes on all nodes of the cluster where a DB Control is configured in all sub-directories
* rmi.xml
* jms.xml
* http-web-site.xml

3. updates the port number in the following files in $ORACLE_HOME/install on the local node
    and deploys the changes on all nodes of the cluster where a DB Control is configured for this database
* portlist.ini
* readme.txt

4. updates the port number in the following files in all sub-directories
    $ORACLE_HOME/hostname<i>_sid<i>/sysman/config on the local node
    and deploys the changes on all nodes of the cluster where a DB Control is configured for this database
* emoms.properties
* emd.properties

5. starts the DB Control on all nodes

Log files to check:
emca log file for this operation is located in $ORACLE_HOME/cfgtoollogs/emca/sid.
emca log file name is in format emca_<timestamp_of_the_operation>.log

Launch emca in silent mode:
It is also possible to execute this command in silent mode with parameters provided in a response file:

$ emca -reconfig ports -cluster -silent -respFile /oracle/app/oracle/admin/EM102/scripts/emca_port_change.rsp

Example of response file: /oracle/app/oracle/admin/EM102/scripts/emca_port_change.rsp
DB_UNIQUE_NAME=EM102
DBCONTROL_HTTP_PORT=1159
RMI_PORT=5522
JMS_PORT=5542
AGENT_PORT=3939

Placement of voting and OCR disk files in 10gRAC

Oracle, 10g RAC, provided its own cluster-ware stack called CRS. The main file components of CRS are the Oracle Cluster Repository (OCR) and the Voting Disk. Due to the nature of these files, they must be placed on shared devices; either on cluster filesystems or shared raw devices. The aim of this document is to provide a clear and concise method to create the OCR and voting disk on raw devices using native OS utilities; i.e, without the need of extra licensable cluster software tools.

 

Prior to installing Oracle CRS, the raw devices that will house the OCR and voting disk files, must be defined and initialized using the following procedure. Note, RedHat and SuSe provided logical volume managers (LVM) are not supported by Oracle since these are not cluster-aware LVMs.

 

 
1. Determine which disk devices will be used store the OCR and voting disk file.

 

2. Execute cat /proc/partitions command on all nodes to verify that the selected devices are available on nodes of the cluster.

 

3. Run fdisk command to create and label a 120Mb partition for the OCR device and a 20 Mb partition for voting disk. 

 

4. Re-run cat /proc/partitions to verify that the partitions are available.

cat /proc/partitions
major minor  #blocks  name

   8     0   10485760 sda
   8     1    9430123 sda1
   8     2    1052257 sda2
   8    16   31457280 sdb
   8    32   31457280 sdc
   8    33   31455238 sdc1
   8    48   31457280 sdd

 

5. Initialize the devices using dd.

OCR disk device
dd if=/dev/zero of=/dev/sdc1 bs=125829120 count=1
Voting disk
dd if=/dev/zero of=/dev/sde1 bs=20971520 count=1

 

6. On Red Hat systems, complete the following steps to bind the disk devices to raw devices:

a. To determine what raw devices are already bound to other devices, enter the following command:
/usr/sbin/raw -qa

Raw devices have device names in the form /dev/raw/rawn, where n is a number that identifies the raw device.

 

b. Open the /etc/sysconfig/rawdevices file in any text editor and add a line similar to the following for each device that you want to use for the voting and OCR disks. Note, Specify an unused raw device for each disk device.
/dev/raw/rawn /dev/sdc1
/dev/raw/rawn /dev/sde1

 

c. For each raw device that you specified in the rawdevices file, enter commands similar to the following to set the owner, group, and permissions on the device file. Due to a port specific bug, the OCR device must set initially to 660 and root:dba. The root.sh script will to reset to the appropriate permissions.
OCR
chown root:dba /dev/raw/rawn
chmod 660 /dev/raw/rawn

Voting disk
chown oracle:dba /dev/raw/rawn
chmod 660 /dev/raw/raw

 

d. cat /etc/rc.d/rc.local

chown  root:dba /dev/raw/raw[1,2]

chown oracle:dba /dev/raw/raw[3-5] 

 

7. When installing Oracle CRS, OUI will request the location of the OCR and voting disk. List the appropriate disk names as requested.

Remove cluster configuration from the linux machine

Below are the list of commands which need to perform to clear up the exising cluster configuration if you failed to install clusterware software and need to try it again.

rm -rf /etc/*ora*
rm -f /etc/init.d/init.cssd
rm -f /etc/init.d/init.crs
rm -f /etc/init.d/init.crsd
rm -f /etc/init.d/init.evmd
rm -f /etc/rc2.d/K96init.crs
rm -f /etc/rc2.d/S96init.crs
rm -f /etc/rc3.d/K96init.crs
rm -f /etc/rc3.d/S96init.crs
rm -f /etc/rc5.d/K96init.crs
rm -f /etc/rc5.d/S96init.crs
rm -Rf /etc/oracle/scls_scr
rm -f /etc/inittab.crs
cp /etc/inittab.orig /etc/inittab

How to use privileged groups oinstall, dba, oper and nobody to protect accessing sysdba or sysoper

This article explains how to use privileged os groups to protect sysdba or sysoper access.

 

First of all, we should create oinstall, dba and oper os groups and need to check if a group called nobody is in the group list.

 

Second, installation of the oracle software will be done by oracle user whose default group is oinstall and supplementary groups are dba and oper.

 

Third, once software installation is done. it is necessary to adjust permission if we are using oracle version 10.2.03 or upward.

( Refer : Note:559753.1 Ext/R.R Non Oracle users can not connect to SQL/PLUS after install 10.2.0.3 )

 $cd $ORACLE_HOME/install

$ ./changePerm.sh
Fourth, assign dba, oper or nobody group to each person depends on the privilege level.

For example, dba to jyoon, oper to yakov and nobody to frank. Then jyoon user can connect to sysdba without password and yakov user can connect to sysoper and frank user can connecto to only the users who he knows the password.

 

uid=500(oracle) gid=300(oinstall) groups=300(oinstall),301(dba),302(oper)

uid=501(jyoon) gid=301(dba) groups=301(dba)

uid=502(yakov) gid=302(oper) groups=302(oper)

uid=503(frank) gid=99(nobody) groups=99(nobody)

 

 

Note:

 

The Oracle install now only allows bequeith conenctions and access to the binaires by
default for the
OS user / group that owns the binaries. (In your case oracle/oinstall)
Members of other groups and users can not access this on the server by default. This is for security.

If non oracle / non oinstall (in your case) users need to access the binaries like SQLPlus:

Cause
After install 10.2.0.3 the script changePerm.sh need to be executed to solve the unix permissions issue.

Solution
$ cd $ORACLE_HOME/install
$ ./changePerm.sh

See Note.559753.1 Ext/R.R Non Oracle users can not connect to SQL/PLUS after install 10.2.0.3
for more information.
It is also discussed in the 10.2.0.3 patchset readme:
See 7.3 Running changePerm.sh Script on an Oracle Database Server Home

Oracle Installation quick check list

1. Kernel parameters(/etc/sysctl.conf)

 kernel.shmmax = 4294967295
kernel.shmall = 268435456
kernel.shmmni = 4096
kernel.sem = 5000 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 1048576
net.core.rmem_max = 1048576
net.core.wmem_default = 262144
net.core.wmem_max = 262144

 

2. Shell limits for oracle user(/etc/security/limits.conf)

 oracle          soft    nproc           2047
oracle          hard    nproc           16384
oracle          soft    nofile          1024
oracle          hard    nofile          65536

 

3. Create groups and userid

# groupadd -g 300 oinstall

# groupadd -g 301 dba

# groupadd -g 302 oper

# useradd -g oinstall -G dba,oper oracle -d /home/app/oracle

 

 4. Add below into /etc/profile

 if [ $USER = "oracle" ]; then
        if [ $SHELL = "/bin/ksh" ]; then
                ulimit -p 16384
                ulimit -n 65536
        else
                ulimit -u 16384 -n 65536
        fi
fi

 

5. Create profile

# cat .profile 

 export ORACLE_BASE=/home/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/10g
export PATH=$ORACLE_HOME/bin:$PATH

export LD_LIBRARY_PATH=/usr/lib:$ORACLE_HOME/lib:$LD_LIBRARY_PATH

export ORACLE_SID=FXPROD

export PS1=`hostname`’($ORACLE_SID):$PWD > ‘

stty erase ^?

set -o vi

alias udump=”cd $ORACLE_BASE/admin/FXPROD/udump”
alias bdump=”cd $ORACLE_BASE/admin/FXPROD/bdump”
alias cdump=”cd $ORACLE_BASE/admin/FXPROD/cdump”
alias oh=”cd $ORACLE_HOME”
alias dbs=”cd $ORACLE_HOME/dbs”
alias net=”cd $ORACLE_HOME/network/admin”

 

6.  Required Linux package list

binutils

compat-db

compat-libstdc++

control-center

gcc

gcc-c++

glibc

glibc-common

gnome-libs

libstdc++

libstdc++-devel

make

pdksh

sysstat

xscreensaver

setarch

Oracle Universal Installer (OUI) initially fails with the following error

Problem 1

Checking installer requirements...
Checking operating system version: must be redhat-3, SuSE-9, redhat-4, UnitedLinux-1.0, asianux-1 or asianux-2 Failed << 

 

Solution

Solution
 
Download OUI 10.2.0.4 (Patch 6640752) and use that to install the 10.2 software. This version of OUI references redhat-5 in the oraparam.ini file
 
Workaround #1 
 
Ignore all the prerequisite checking by using
 
% ./runInstaller -ignoreSysPrereqs
 
Workaround #2
 
If you are installing 10.2 from DVD, copy the /database/install/oraparam.ini to a temporary directory (for example, /tmp).
 
If you are installing 10.2 from an OTN download or have copied the 10.2 media to disk, take a backup of /database/install/oraparam.ini
 
Now edit oraparam.ini and change the appropriate line:
 
    Original
 
    [Certified Versions]
    Linux=redhat-3,SuSE-9,redhat-4,UnitedLinux-1.0,asianux-1,asianux-2
 
    New
 
    [Certified Versions]
    Linux=redhat-3,SuSE-9,redhat-4,UnitedLinux-1.0,asianux-1,asianux-2,redhat-5
 
Now, if you copied oraparam.ini to /tmp, start OUI like this:
 
    % ./runInstaller -paramFile /tmp/oraparam.ini
 
If you edited /database/install/oraparam.ini on disk, just start OUI as normal

 

Problem 2

While installing Oracle database 10.2.0 on RHEL 5 (Redhat Enterprise Linux) or  OEL 5 (Oracle Enterprise Linux), you get the following error before Oracle Universal Installer (OUI) gets invoked.
 
    Exception java.lang.UnsatisfiedLinkError: /tmp/OraInstall/jre/1.4.2/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory occurred..
    java.lang.UnsatisfiedLinkError: /tmp/OraInstall/jre/1.4.2/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory 

 

Cause

The  i386 version of the libXp package is missing. The Oracle Universal Installer ( OUI  ) requires the file libXp.so.6 and this file is installed with the package libXp in RHEL 5 and OEL 5.
 
Issue the following to confirm the missing rpm:
 
    % rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE} (%{ARCH})\n" | grep libXp
 

Solution

The package libXp was not installed in RHEL 5/OEL 5 with default RPM packages, so it will need to be installed manually.   In RHEL 4 this file was provided by the package xorg-x11-deprecated-libs which is installed with default package installation but this is not the case for RHEL5/OEL5 and is now provided with a different rpm, the libXp rpm.
 
Install the package libXp by the command:
 
    # rpm -ivh libXp..i386.rpm 

How to change the password of the 10g database user sysman

All database administrators using the Enterprise Manager 10G DB Control

(also known as RDBMS 10G Standalone dbconsole)

 
 
How to change the password of the 10g database user sysman

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

 
The Oracle user sysman is the schema of the standalone repository

of the 10G Enterprise Manager DB Control.

 
To ensure that you change the sysman password in the right database,

you must check that the environment variable ORACLE_SID is set.

You must also check that the environment variable ORACLE_HOME is set

and that the path includes the correct $ORACLE_HOME/bin.

 
To change the password of the user sysman you must strictly

follow the steps below, otherwise you 10g Standalone dbconsole used to manage

your 10g database will not function properly.

 
1. Stop the standalone dbconsole

   on Unix

   $ emctl stop dbconsole

   on Windows

   Stop the Windows Service Oracle<oracle_home_name>DBConsole

   Or

   Open a DOS Command Window and type

   C> emctl stop dbconsole

 
2. Check that the standalone dbconsole is stopped

   on Unix

   $ emctl status dbconsole

   on Windows

   Check the status of the Windows Service Oracle<oracle_home_name>DBConsole

   Or

   Open a DOS Command Window and type

   C> emctl status dbconsole

 
3. Connect to the database as a user with DBA privilege with SQL*Plus

   and execute

   SQL> alter user sysman identified by <new_password> ;

 
4. Check the new password

   SQL> connect sysman/<new_password>[@database_alias]

 
5. Go to $ORACLE_HOME/db01_FXPROD1/sysman/config( $ORACLE_HOME/db02_FXPROD2/sysman/config )

   5.1 Save the file emoms.properties to emoms.properties.orig

   5.2 Edit the file emoms.properties

       a. Search for the line beginning with:

          oracle.sysman.eml.mntr.emdRepPwd=

          Replace the encrypted value by the new password value

       b. Search for the line:

          oracle.sysman.eml.mntr.emdRepPwdEncrypted=TRUE

          Replace TRUE by FALSE

 
6. Restart the standalone dbconsole

   on Unix

   $ emctl start dbconsole

   on Windows

   Start the Windows Service Oracle<oracle_home_name>DBConsole

   Or

   Open a DOS Command Window and type

   C> emctl start dbconsole

 
7. Check that the password has been encrypted

   Edit the file emoms.properties

   7.1 Search for the line beginning with:

       oracle.sysman.eml.mntr.emdRepPwd=

       Check that the password is encrypted

   7.2 Search for the line beginning with:

       oracle.sysman.eml.mntr.emdRepPwdEncrypted=

       Check that the value is TRUE