Thursday, April 23, 2009

Heterogenous standby Windows 32-bit -> Linux 32-bit in Oracle 11g

Based on Metalink Note 413484.1 physical Standby configuration
is supported for mixed platforms.

The configuration that attracted my attention is cascaded physical standby that
can be configured between Windows 32-bit -> Linux 32-bit and Linux 64-bit.

It can be considered as minimal downtime migration from Windows to Linux
using switchover operations.

To setup configuration I started with standby for Windows 32 and Linux 32
and created primary database 11.1.0.7 on Windows and
installed APEX 3.2 there as well as put the same version of RDBMS at Linux side.

To duplicate the database RMAN have to be used but because of differences
between windows and linux like paths "duplicate" command can't be used.
So I took full backup of the database including backup of current
controlfile for standby and copied it over to standby server.
backup as compressed backupset tag 'FOR_STBY' (database)
(current controlfile for standby);


I took the following steps to restore database at standby:
startup nomount;

restore standby controlfile from '/u02/fra/O1_MF_NCNNF_FOR_STBY_4Z0O8NPK_.BKP';

mount database;

catalog start with '/u02/fra';

run {
set newname for datafile 1 to new;
set newname for datafile 2 to new;
set newname for datafile 3 to new;
set newname for datafile 4 to new;
set newname for datafile 5 to new;
set newname for datafile 6 to new;
set newname for tempfile 1 to new;
restore database;
switch datafile all;
switch tempfile all;
}


I started DG broker at primary and standby databases,
added standby log files on standby and created DG configuration:

create configuration dev_dg as primary database is dev
connect identifier is '//192.168.1.3/dev';

add database dev_srv2 as connect identifier
is '//192.168.1.7/dev_srv2' maintained as physical;

enable configuration;


The configuration showed SUCCESS but I checked log files and see
that there are windows style files left in controlfile.
SQL> select member from v$logfile;

MEMBER
-----------------------------------------------
D:\APP\GORYUNOV\ORADATA\DEV\REDO03.LOG
D:\APP\GORYUNOV\ORADATA\DEV\REDO02.LOG
D:\APP\GORYUNOV\ORADATA\DEV\REDO01.LOG
/u02/oradata/DEV_SRV2/onlinelog/o1_mf_5_4z0sofxh_.log
/u02/fra/DEV_SRV2/onlinelog/o1_mf_5_4z0sogml_.log
/u02/oradata/DEV_SRV2/onlinelog/o1_mf_6_4z0soyrl_.log
/u02/fra/DEV_SRV2/onlinelog/o1_mf_6_4z0sozjh_.log


I was able to drop only one group (after cancelling recovery
and changing standby_file_management to manual), others
were not dropped since they needed for crash recovery

When all preparations were done (IP addresses and name to hosts files,
addition of dev_DGMGRL, dev_srv2_DGMGRL service names to listener.ora)
I executed switchover to standby database on Linux
and it was completed successfully:

DGMGRL> switchover to dev_srv2;
Performing switchover NOW, please wait...
New primary database "dev_srv2" is opening...
Operation requires shutdown of instance "dev" on database "dev"
Shutting down instance "dev"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "dev" on database "dev"
Starting instance "dev"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "dev_srv2"


Check of log files in new primary dev_srv2 showed new names:

SQL> select member from v$logfile;
MEMBER
---------------------------------------------------
/u01/app/oracle/product/11.1.0/db_1/dbs/D:APPGORYUNOVORADATADEVREDO03.LOG
/u01/app/oracle/product/11.1.0/db_1/dbs/D:APPGORYUNOVORADATADEVREDO02.LOG
/u02/oradata/DEV_SRV2/onlinelog/o1_mf_5_4z0sofxh_.log
/u02/fra/DEV_SRV2/onlinelog/o1_mf_5_4z0sogml_.log
/u02/oradata/DEV_SRV2/onlinelog/o1_mf_6_4z0soyrl_.log
/u02/fra/DEV_SRV2/onlinelog/o1_mf_6_4z0sozjh_.log

but I easily added new OMF logfiles and dropped files from dbs directory.


After switchover I was able to connect to APEX through standby IP address

And now I need switchover it back and create standby database on
Linux 64-bit
(to be continued...)


Have a good day!

Friday, April 10, 2009

LargeRepository option in EM Grid Control 10.2.0.5

If you have lots of targets, many jobs, getting plenty of alerts in
Enterprise Manager Grid Control you possibly already set
LargeRepository to true in emoms.properties
to speed up navigation of Console.

And of course you already downloaded and upgraded it to 10.2.0.5
which is available for Linux 64-bit as well.

The upgrade and configuration of repository would go well
but you get error 404 after login to Grid Control Console
404 Not Found
Resource /em/home.jsp/page/internalError not found on this server


There is note on Metalink that mentions that problem and
workaround is very simple and straightforward - set LargeRepository to false.

Known Issues during 10.2.0.5 Upgrade

But does everybody want to change the parameter back to false?...
I hope it will be fixed soon.

Have a good day!

Wednesday, April 8, 2009

silent installation of Enterprise Manager 10g Grid Control Release 5

The Enterprise Manager 10g Grid Control Release 5 for Linux x86-64 is out
on OTN and also there is patch available on Metalink

I already installed 10.2.0.3 (full release) silently and wanted to upgrade
using the same way.

There are steps clearly described in documentation how to upgrade
existing version together with post-installation actions:
Installing Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) Using Existing Database

So I started:
./runInstaller -noconfig -silent \
-responseFile /opt/oracle/install/gc/10205/3731593/Disk1/response/patchset.rsp \
b_softwareonly=true s_sysPassword="sys24" \
ORACLE_HOME="/home/oracle/grid/oms10g" \
oracle.iappserver.st_midtier:szl_InstanceInformation={"rep24"}


It went ok without errors and asked to execute root.sh at the end

After that following further configuration procedures
I set PERL5LIB and started upgrade of OMS repository:
export PERL5LIB=$ORACLE_HOME/perl/lib/5.6.1

$ORACLE_HOME/perl/bin/perl /home/oracle/grid/oms10g/sysman/install/ConfigureGC.pl /home/oracle/grid


It bounced database to remove running jobs (even I did pre-installation steps
for it mentioned in Oracle Enterprise Manager
Grid Control ReadMe for Linux x86-64
10g Release 5


and finally executed RepManager with -action upgrade ... options
spooling output to $OMS_HOME/sysman/log/emrepmgr.log.10.2.0.5.0

When the script had been finished I was able to start oms and it was
showing the newest verison.

Another step was an upgrade of the agent running 10.2.0.4 version

The same installation can be used for agent upgrade but
with ORACLE_HOME related to agent home:
./runInstaller -noconfig -silent \
-responseFile /opt/oracle/install/gc/10205/3731593/Disk1/response/patchset.rsp \
b_softwareonly=true ORACLE_HOME="/home/oracle/grid/agent10g"


And that upgrade went smoothly asking to run root.sh at the end.


I started agent but it could not upload files due to errors in XML files.
So I completely cleaned files there, secured the agent and tried to start
it again but it failed with errors in emagent.trc

ERROR pingManager: Did not receive valid response to ping "ERROR-Agent is blocked. Blocked reason is: Agent is out-of-sync with repository. This most likely means that the agent was reinstalled or recovered. Please contact an EM administrator to unblock the agent by performing an agent resync from the console. Please contact EM adminstrator to unblock the agent"


There is one note on Metalink exactly related to the issue
and method to fix it is to run Synchronization from Grid Control Console

Upload Agent Failing With Error
"OMS Version Not Checked Yet" ,
After Upgrading Agent to 10.2.0.5.0


Submit of synchronization button failed with another error:

Agent Operation completed with errors.
For those targets that could not be saved, please go to the target's monitoring configuration page to save them. All other targets have been saved successfully. Agent has not been unblocked. Error saving target EnterpriseManager0.rac2.home_Web Cache:oracle_webcache - Skipping target {EnterpriseManager0.
rac2.home_Web Cache, oracle_webcache}: Missing properties - authpwd, authuser

I manually unblocked the agent in there and it started to upload files to OMS
without errors.


Have a good day!

Wednesday, April 1, 2009

silent installation of 11.1.0.7 on Linux

There are Oracle installations that simplier to do in command line
and one of them is patchset installation.

To start it I used ORACLE_HOME and ORACLE_HOME_NAME
in addition to usual -silent -responseFile options

./runInstaller -silent \
-responseFile /u02/install/patch/Disk1/response/patchset.rsp \
ORACLE_HOME="/u03/app/oracle/product/11.1.0/db_1" \
ORACLE_HOME_NAME="OraDb11g_home1"


But the execution failed with error:
SEVERE:Values for the following variables could not be obtained
from the command line or response file(s):
METALINK_USERNAME(MetaLinkUsername)
Silent install cannot continue


Well, if it is not provided why not to use just null value. For some reason
installer did not want to do it and I added METALINK_USERNAME
(together with METALINK_PASSWORD) defined to empty string:

/u02/install/patch/Disk1> ./runInstaller -silent \
-responseFile /u02/install/patch/Disk1/response/patchset.rsp \
ORACLE_HOME="/u03/app/oracle/product/11.1.0/db_1" \
ORACLE_HOME_NAME="OraDb11g_home1" \
METALINK_USERNAME="" METALINK_PASSWORD=""


And the installation went further but stopped asking me:
You may not have enough space on your drive for a successful install.
Do you still want to continue?


Funny but I tried to answer "y", "Y", "YES" but it was failing with
"-bash: n: command not found". And then I checked the log
of installation: "INFO: Installation cannot continue. To Ignore Disk Warning, please use "-ignoreDiskWarning" command line option" was there.

I added -ignoreDiskWarning and was able to install patchset without problems
and questions

./runInstaller -silent\
-responseFile /u02/install/patch/Disk1/response/patchset.rsp \
ORACLE_HOME="/u03/app/oracle/product/11.1.0/db_1" \
ORACLE_HOME_NAME="OraDb11g_home1" \
METALINK_USERNAME="" METALINK_PASSWORD="" \
-ignoreDiskWarning


Another thing that is worth to mention that root.sh script generated
during silent installation also has parameter not to show output:

grep -i silent /u03/app/oracle/product/11.1.0/db_1/root.sh
OUI_SILENT=true
...


With TRUE value it won't show anything on a screen during execution
but change to FALSE will provide the output as usual.


Have a good day!