Preface: SuSe 10 is not supported platform for Grid Control. However, we've successfully implemented Grid Control in full production mode for several clients; Steps to install:
RPM needed:
openmotif-2.2.3-6.1.i586.rpm
db1-1.85-88.i586.rpm
unset ENV
echo $ENV
Modify /etc/SuSE-release file to change the version # to 9
cat /etc/SuSE-release
SUSE Linux Enterprise Server 9 (i586)
VERSION = 9
Ensure IPv6 is not setup in the /etc/hosts file (notice the IPv6 section is commented out)
cat /etc/hosts
# special IPv6 addresses
#::1 localhost ipv6-localhost ipv6-loopback
#fe00::0 ipv6-localnet
#ff00::0 ipv6-mcastprefix
#ff02::1 ipv6-allnodes
#ff02::2 ipv6-allrouters
#ff02::3 ipv6-allhosts
100.xx.xx.xx <instance_name> <name>
100.xx.xx.xx <instance_name> <name>
/opt/oracle/orahome/agent10g
/opt/oracle/orahome/db10g
/opt/oracle/orahome/oms10g
Setup users and groups
Start the installation in 10.2.0.1 after unzipping the 10.2.0.1 installation files
Unzip the source “unzip GridControl_10.2.0.3_Linux.zip”
Make sure Repository Database name is shorter than 16 characters, otherwise Grid control cannot be installed.
SQL> desc v$instance
Name Null? Type
----------------------------------------- -------- ----------------------------
INSTANCE_NUMBER NUMBER
INSTANCE_NAME VARCHAR2(16)
HOST_NAME VARCHAR2(64)
VERSION VARCHAR2(17)
STARTUP_TIME DATE
STATUS VARCHAR2(12)
PARALLEL VARCHAR2(3)
THREAD# NUMBER
ARCHIVER VARCHAR2(7)
LOG_SWITCH_WAIT VARCHAR2(15)
LOGINS VARCHAR2(10)
SHUTDOWN_PENDING VARCHAR2(3)
DATABASE_STATUS VARCHAR2(17)
INSTANCE_ROLE VARCHAR2(18)
ACTIVE_STATE VARCHAR2(9)
BLOCKED VARCHAR2(3)
Ignore warning due to opmn process manager already running; click ‘Continue’
# /opt/oracle/orahome/db10g/allroot.sh
Starting to execute allroot.sh .........
Starting to execute /opt/oracle/orahome/db10g/root.sh ......
Running Oracle10 root.sh script...
\nThe following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /opt/oracle/orahome/db10g
Enter the full pathname of the local bin directory: [/usr/local/bin]:
Copying dbhome to /usr/local/bin ...
Copying oraenv to /usr/local/bin ...
Copying coraenv to /usr/local/bin ...
\nCreating /etc/oratab file...
Adding entry to /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
/etc/oracle does not exist. Creating it now.
/bin/ln: creating hard link `/etc/rc3.d/S99gcstartup' to `/etc/init.d/gcstartup': No such file or directory
Finished execution of /opt/oracle/orahome/db10g/root.sh ......
Starting to execute /opt/oracle/orahome/oms10g/root.sh ......
Running Oracle10 root.sh script...
\nThe following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /opt/oracle/orahome/oms10g
Enter the full pathname of the local bin directory: [/usr/local/bin]:
The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n)
[n]: n
The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n)
[n]: n
The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n)
[n]: n
Adding entry to /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
Finished execution of /opt/oracle/orahome/oms10g/root.sh ......
Starting to execute /opt/oracle/orahome/agent10g/root.sh ......
Running Oracle10 root.sh script...
The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /opt/oracle/orahome/agent10g
Enter the full pathname of the local bin directory: [/usr/local/bin]: /tmp
Copying dbhome to /tmp ...
Copying oraenv to /tmp ...
Copying coraenv to /tmp ...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
Finished product-specific root actions.
Finished execution of /opt/oracle/orahome/agent10g/root.sh ......
DBCA error ORA-01081: cannot start already-running Oracle
Ps –ef|grep oracle > shows no oracle processes running
However, shared memory segments show there are two oracle db processes running, to check
# ipcs –a
0x13d4b85c 3506212 oracle 660 154
To kill it,
------ Message Queues --------
key msqid owner perms used-bytes messages
# ipcrm -s 3506212
All Configuration Assistant should compete with the exception of the ‘Agent Configuration Assistant’ > Installation and automatic configuration should give no problems…except these things:
- The last step in the configuration process, the configuration of the agent, returns an error. However, as far as I can see everything seems to work fine.
- During the execution of root.sh, the installer tries to create a hard link S99gcstartup in /etc/rc3.d to the file /etc/init.d/gcstartup. In SuSE the directory /etc/rc3.d does not exist, this has to be /etc/init.d/rc3.d.
If you get Configuration Assistant error messages, please refer to Metalink Notes:
353131.1, 368766.1, 380507.1
Notes:
Attempt to start the database results in:
SQL> conn /as sysdba
Connected to an idle instance.
SQL> startup;
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/orahome/db10g/dbs/initemrep.<servername>.ora'
Looking in $ORACLE_HOME/dbs the file does not exist.
>> Since Oracle proposed the use of the OFA standard (Optimal Flexible Architecture) for file placement, the init.ora file lives elsewhere now (in $ORACLE_BASE/admin/emrep/pfile or in $ORACLE_HOME/admin/emrep/pfile).
The solution is to create a symbolic link for the init.ora file in the dbs directory and the database startup will work.
ln -s $ORACLE_HOME/admin/emrep/pfile/init.ora.xxxxx
$ORACLE_HOME/dbs/initemrep.<servername>.ora
Apply patch # 4329444
- Download patch from Metalink and unzip
- As oracle user,
$ cd $ORACLE_HOME/OPatch
$ export PATH=$PATH:/bin
$ export OPATCH_NO_FUSER=TRUE
Last but not least, a workaround for a known bug: before starting the installer set the environment variable OPATCH_NO_FUSER to TRUE. Reason for this is a workaround for bug 4898745 as documented on Metalink in document 352507.1. It says: " fuser is used by OPatch to detect active processes. So presence of fuser executable is essential. It should be present in /sbin or /usr/sbin or should be present in the PATH.
$ ./opatch apply <patch_expanded_location>
Download and Install Oracle Database 10.2.0.1.0 (download from OTN > Downloads > Database > Oracle Database 10g Release 2 (10.2.0.1.0);
Unzip, cd to database folder, run $ ./runInstaller &
Select Installation Method – Basic Installation
Oracle Home Location, create a new Oracle Home in the same directory as db10g, oms10g, etc., named it ora10g; Installation type –enterprise edition,
UNIX dba group > dba
Check the box to create starter database;
Global Database Name: orcl
Patch 10.2.0.1 Database to 10.2.0.3
Export ORACLE_HOME pointing to ora10g, $ export ORACLE_HOME=/opt/oracle/oraoem/ora10g
$export ORACLE_SID=orcl
$ cd $ORACLE_HOME/bin
$ . /sqlplus /nolog
SQL> conn /as sysdba
SQL>shutdown immediate;
SQL> quit;
$ ./lsnrctl stop listener
Download patch # 5337014 from Metalink, unzip, cd to Disk1 and run $./runInstaller &
Specify Oracle Home Name – OraDb10g_home1
Create symbolic link for initORCL.ora, e.g.
oracle@<instance_name>:> ln -s /opt/oracle/orahome/db102/admin/orcl/pfile/init.ora.68200720555 /opt/oracle/orahome/db102/dbs/initORCL.ora
export ORACLE_HOME=/opt/oracle/orahome/db102
export ORACLE_SID=orcl
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
./sqlplus /nolog
SQL> conn /as sysdba
SQL> startup upgrade;
SQL>@$ORACLE_HOME/rdbms/admin/catalog.sql
SQL> @$ORACLE_HOME/rdbms/admin/catproc.sql
SQL>shutdown immediate;
SQL>startup;
SQL>@$ORACLE_HOME/rdbms/admin/utlrp.sql
SQL>quit;
$ ./lsnrctl start listener
Start DBUA
…. Next upgrade /opt/oracle/orahome/db10g repository via DBUA to version 10.2.0.3
Ensure the <Oracle_Inventory>/ContentsXML/inventory.xml file to make sure the Oracle home path is the same as the components that you are upgrading. <paths must always be hardlinks>
Repository Upgrade Assistant Fails with ‘Repository Upgrade Failed’
As per Metalink Note # 412848.1
Connect to the database via SQL*Plus as SYSMAN user and run:
BEGIN
FOR r IN (SELECT job_id
FROM mgmt_corrective_action a
WHERE NOT EXISTS
(SELECT 1
FROM mgmt_job j
WHERE j.job_id = a.job_id)
) LOOP
UPDATE mgmt_policy_assoc_cfg
c
SET crit_action_job_id = NULL
WHERE crit_action_job_id = r.job_id
;
UPDATE mgmt_policy_assoc_cfg
c
SET warn_action_job_id = NULL
WHERE warn_action_job_id = r.job_id
;
UPDATE mgmt_policy_assoc_cfg
c
SET info_action_job_id = NULL
WHERE info_action_job_id = r.job_id
;
DELETE
FROM
mgmt_corrective_action
WHERE job_id = r.job_id
;
COMMIT;
END LOOP;
COMMIT;
END;
/
After it displays: SQL > PL/SQL procedure successfully completed
Retry the Repository Upgrade Assistant
Stop all OMS and database services, change the location of Database 10.1.0.4 home, e.g
$ mv db10g db10g.old
Change the location of the new Database 10g home to db10g, e.g.
$ mv ora10g db10g
Copy db10g.old/admin folder contents to db10g/admin
Edit db10g/dbs/initEMREP.ora to point to the db10g location
Edit db10g/network/admin/listener.ora and tnsnames.ora to point to the db10g location
Start Oracle database in db10g;
Start OMS services;
Start OMS Agent;