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!
No comments:
Post a Comment