I have recently been working on a customer project where I had been challenged adding a dbvisit standby database on an ODA X7-2M, named ODA03. The existing customer environment was composed of Oracle Standard 12.2 version database. The primary database, myDB, is running on server named srv02 and using a non-OMF configuration. On the ODA side we are working with OMF configuration. The dbvisit version available at that time was version 8. You need to know that version 9 is currently the last one and brings some new cool features. Through this blog I would like to share with you my experience, the problem I have been facing and the solution I could put in place.
Preparing the instance on the ODA
First of all I have been creating an instance only database on the ODA.
root@ODA03 ~]# odacli list-dbhomes
ID Name DB Version Home Location Status
---------------------------------------- -------------------- ---------------------------------------- --------------------------------------------- ----------
ec33e32a-37d1-4d0d-8c40-b358dcf5660c OraDB12201_home1 12.2.0.1.180717 /u01/app/oracle/product/12.2.0.1/dbhome_1 Configured
[root@ODA03 ~]# odacli create-database -m -u myDB_03 -dn domain.name -n myDB -r ACFS -io -dh ec33e32a-37d1-4d0d-8c40-b358dcf5660c
Password for SYS,SYSTEM and PDB Admin:
Job details
----------------------------------------------------------------
ID: 96fd4d07-4604-4158-9c25-702c01f4493e
Description: Database service creation with db name: myDB
Status: Created
Created: May 15, 2019 4:29:15 PM CEST
Message:
Task Name Start Time End Time Status
---------------------------------------- ----------------------------------- ----------------------------------- ----------
[root@ODA03 ~]# odacli describe-job -i 96fd4d07-4604-4158-9c25-702c01f4493e
Job details
----------------------------------------------------------------
ID: 96fd4d07-4604-4158-9c25-702c01f4493e
Description: Database service creation with db name: myDB
Status: Success
Created: May 15, 2019 4:29:15 PM CEST
Message:
Task Name Start Time End Time Status
---------------------------------------- ----------------------------------- ----------------------------------- ----------
Setting up ssh equivalance May 15, 2019 4:29:16 PM CEST May 15, 2019 4:29:16 PM CEST Success
Creating volume datmyDB May 15, 2019 4:29:16 PM CEST May 15, 2019 4:29:38 PM CEST Success
Creating volume reco May 15, 2019 4:29:38 PM CEST May 15, 2019 4:30:00 PM CEST Success
Creating ACFS filesystem for DATA May 15, 2019 4:30:00 PM CEST May 15, 2019 4:30:17 PM CEST Success
Creating ACFS filesystem for RECO May 15, 2019 4:30:17 PM CEST May 15, 2019 4:30:35 PM CEST Success
Database Service creation May 15, 2019 4:30:35 PM CEST May 15, 2019 4:30:51 PM CEST Success
Auxiliary Instance Creation May 15, 2019 4:30:35 PM CEST May 15, 2019 4:30:47 PM CEST Success
password file creation May 15, 2019 4:30:47 PM CEST May 15, 2019 4:30:49 PM CEST Success
archive and redo log location creation May 15, 2019 4:30:49 PM CEST May 15, 2019 4:30:49 PM CEST Success
updating the Database version May 15, 2019 4:30:49 PM CEST May 15, 2019 4:30:51 PM CEST Success
Next steps are really common DBA operations :
- Create a pfile from the current primary database
- Transfer the pfile to the ODA
- Update the pfile as needed (path, db_unique_name, …)
- Create a spfile from the pfile on the new ODA database
- Apply ODA specific instance parameters
- Copy or create the password file with same password
The parameters that are mandatory to be set on the ODA instance are the following :
*.db_create_file_dest=’/u02/app/oracle/oradata/myDB_03′
*.db_create_online_log_dest_1=’/u03/app/oracle/redo’
*.db_recovery_file_dest=’/u03/app/oracle/fast_recovery_area’
Also all the convert parameters should be removed. Using convert parameter is incompatible with OMF.
Creating the standby database
Using dbvisit
I first tried to use dbvisit to create the standby database.
As usual and common dbvisit operation, I first created the DDC configuration file from the primary server :
oracle@srv02:/u01/app/dbvisit/standby/ [myDB] ./dbvctl -o setup ... ... ... Below are the list of configuration variables provided during the setup process: Configuration Variable Value Provided ====================== ============== ORACLE_SID myDB ORACLE_HOME /opt/oracle/product/12.2.0 SOURCE srv02 ARCHSOURCE /u03/app/oracle/dbvisit_arch/myDB RAC_DR N USE_SSH N DESTINATION ODA03 NETPORT 7890 DBVISIT_BASE_DR /u01/app/dbvisit ORACLE_HOME_DR /u01/app/oracle/product/12.2.0.1/dbhome_1 DB_UNIQUE_NAME_DR myDB_03 ARCHDEST /u03/app/oracle/dbvisit_arch/myDB ORACLE_SID_DR myDB ENV_FILE myDBSTD1 Are these variables correct? [Yes]: ... ... ...
I then used this DDC configuration file to create the standby database :
oracle@srv02:/u01/app/dbvisit/standby/ [myDB] ./dbvctl -d myDBSTD1 --csd ------------------------------------------------------------------------------- INIT ORA PARAMETERS ------------------------------------------------------------------------------- * audit_file_dest /u01/app/oracle/admin/myDB/adump * compatible 12.2.0 * control_management_pack_access NONE * db_block_size 8192 * db_create_file_dest /u02/app/oracle/oradata/myDB_03 * db_create_online_log_dest_1 /u03/app/oracle/redo * db_domain * db_name myDB * db_recovery_file_dest /u03/app/oracle/fast_recovery_area * db_recovery_file_dest_size 240G * db_unique_name myDB_03 * diagnostic_dest /u01/app/oracle * dispatchers (PROTOCOL=TCP) (SERVICE=myDBXDB) * instance_mode READ-WRITE * java_pool_size 268435456 * log_archive_dest_1 LOCATION=USE_DB_RECOVERY_FILE_DEST * open_cursors 3000 * optimizer_features_enable 12.2.0.1 * pga_aggregate_target 4194304000 * processes 8000 * remote_login_passwordfile EXCLUSIVE * resource_limit TRUE * sessions 7552 * sga_max_size 53687091200 * sga_target 26843545600 * shared_pool_reserved_size 117440512 * spfile OS default * statistics_level TYPICAL * undo_retention 300 * undo_tablespace UNDOTBS1 ------------------------------------------------------------------------------- Status: VALID What would you like to do: 1 - Create standby database using existing saved template 2 - View content of existing saved template 3 - Return to the previous menu Please enter your choice [1]:
This operation failed with following errors :
Cannot create standby data or temp file /usr/oracle/oradata/myDB/myDB_bi_temp01.dbf for primary file /usr/oracle/oradata/myDB/myDB_bi_temp01.dbf as location /usr/oracle/oradata/myDB does not exist on the standby.
A per dbvisit documentation, dbvisit standby is certified ODA and fully compatible with non-OMF and OMF databases. This is correct, the only distinction is that the full environment needs to be in same configuration. That’s to say that if the primary is OMF, the standby is expected to be OMF. If the primary is running a non-OMF configuration, the standby should be using non-OMF as well.
Using RMAN
I decided to duplicate the database using RMAN and a backup that I transferred locally on the ODA. The backup was the previous nightly inc0 backup. Before running the rman duplication I executed a last archive log backup to make sure to have the most recent archive used in the duplication.
I’m taking this opportunity to highlight that, thanks to ODA NVMe technology, the duplication of the 3 TB database without multiple channel (standard edition) took a bit more than 2 hours only. On the existing servers this took about 10 hours.
I added following tns entry in the tnsnames.ora.
myDBSRV3 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ODA03.domain.name)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = myDB)
(UR = A)
)
)
Of course I could have been using a local connection.
I made sure the database to be in nomount status and ran the rman duplication :
oracle@ODA03:/opt/oracle/backup/ [myDB] rmanh
Recovery Manager: Release 12.2.0.1.0 - Production on Mon May 20 13:24:29 2019
Copyright (c) 1982, 2017, Oracle and/or its affiliates. All rights reserved.
RMAN> connect auxiliary sys@myDBSRV3
auxiliary database Password:
connected to auxiliary database: myDB (not mounted)
RMAN> run {
2> duplicate target database for standby dorecover backup location '/opt/oracle/backup/myDB';
3> }
Starting Duplicate Db at 20-MAY-2019 13:25:51
contents of Memory Script:
{
sql clone "alter system set control_files =
''/u03/app/oracle/redo/myDB_03/controlfile/o1_mf_gg4qvpnn_.ctl'' comment=
''Set by RMAN'' scope=spfile";
restore clone standby controlfile from '/opt/oracle/backup/myDB/ctl_myDB_myDB_s108013_p1_newbak.ctl';
}
executing Memory Script
sql statement: alter system set control_files = ''/u03/app/oracle/redo/myDB_03/controlfile/o1_mf_gg4qvpnn_.ctl'' comment= ''Set by RMAN'' scope=spfile
Starting restore at 20-MAY-2019 13:25:51
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=9186 device type=DISK
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u03/app/oracle/redo/myDB_03/controlfile/o1_mf_gg4qvpnn_.ctl
Finished restore at 20-MAY-2019 13:25:52
contents of Memory Script:
{
sql clone 'alter database mount standby database';
}
executing Memory Script
sql statement: alter database mount standby database
released channel: ORA_AUX_DISK_1
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=9186 device type=DISK
contents of Memory Script:
{
set until scn 49713361973;
set newname for clone tempfile 1 to new;
set newname for clone tempfile 2 to new;
switch clone tempfile all;
set newname for clone datafile 1 to new;
set newname for clone datafile 2 to new;
set newname for clone datafile 3 to new;
set newname for clone datafile 4 to new;
set newname for clone datafile 5 to new;
set newname for clone datafile 6 to new;
set newname for clone datafile 7 to new;
set newname for clone datafile 8 to new;
set newname for clone datafile 10 to new;
set newname for clone datafile 11 to new;
set newname for clone datafile 12 to new;
set newname for clone datafile 13 to new;
set newname for clone datafile 14 to new;
set newname for clone datafile 15 to new;
set newname for clone datafile 16 to new;
set newname for clone datafile 17 to new;
set newname for clone datafile 18 to new;
restore
clone database
;
}
executing Memory Script
executing command: SET until clause
executing command: SET NEWNAME
executing command: SET NEWNAME
renamed tempfile 1 to /u02/app/oracle/oradata/myDB_03/myDB_03/datafile/o1_mf_temp_%u_.tmp in control file
renamed tempfile 2 to /u02/app/oracle/oradata/myDB_03/myDB_03/datafile/o1_mf_lx_bi_te_%u_.tmp in control file
executing command: SET NEWNAME
...
...
...
executing command: SET NEWNAME
Starting restore at 20-MAY-2019 13:25:57
using channel ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to /u02/app/oracle/oradata/myDB_03/myDB_03/datafile/o1_mf_system_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00003 to /u02/app/oracle/oradata/myDB_03/myDB_03/datafile/o1_mf_undotbs1_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00005 to /u02/app/oracle/oradata/myDB_03/myDB_03/datafile/o1_mf_lxdataid_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00006 to /u02/app/oracle/oradata/myDB_03/myDB_03/datafile/o1_mf_renderz2_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00007 to /u02/app/oracle/oradata/myDB_03/myDB_03/datafile/o1_mf_lx_ods_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00008 to /u02/app/oracle/oradata/myDB_03/myDB_03/datafile/o1_mf_users_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00013 to /u02/app/oracle/oradata/myDB_03/myDB_03/datafile/o1_mf_renderzs_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00015 to /u02/app/oracle/oradata/myDB_03/myDB_03/datafile/o1_mf_lx_stagi_%u_.dbf
channel ORA_AUX_DISK_1: reading from backup piece /opt/oracle/backup/myDB/inc0_myDB_s107963_p1
...
...
...
archived log file name=/opt/oracle/backup/myDB/1_58043_987102791.dbf thread=1 sequence=58043
archived log file name=/opt/oracle/backup/myDB/1_58044_987102791.dbf thread=1 sequence=58044
archived log file name=/opt/oracle/backup/myDB/1_58045_987102791.dbf thread=1 sequence=58045
archived log file name=/opt/oracle/backup/myDB/1_58046_987102791.dbf thread=1 sequence=58046
archived log file name=/opt/oracle/backup/myDB/1_58047_987102791.dbf thread=1 sequence=58047
archived log file name=/opt/oracle/backup/myDB/1_58048_987102791.dbf thread=1 sequence=58048
archived log file name=/opt/oracle/backup/myDB/1_58049_987102791.dbf thread=1 sequence=58049
archived log file name=/opt/oracle/backup/myDB/1_58050_987102791.dbf thread=1 sequence=58050
media recovery complete, elapsed time: 00:12:40
Finished recover at 20-MAY-2019 16:06:22
Finished Duplicate Db at 20-MAY-2019 16:06:39
I could check and see that my standby database has been successfully created on the ODA :
oracle@ODA03:/u01/app/oracle/local/dmk/etc/ [myDB] myDB ********* dbi services Ltd. ********* STATUS : MOUNTED DB_UNIQUE_NAME : myDB_03 OPEN_MODE : MOUNTED LOG_MODE : ARCHIVELOG DATABASE_ROLE : PHYSICAL STANDBY FLASHBACK_ON : NO FORCE_LOGGING : YES CDB Enabled : NO *************************************
As a personal note, I really found using oracle RMAN more convenient to duplicate a database. Albeit dbvisit script and tool is really stable, I think that this will give you more flexibility.
Registering the database in the grid cluster
As next step I registered the database in the grid.
oracle@ODA03:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/ [LX] srvctl add database -db MyDB_03 -oraclehome /u01/app/oracle/product/12.2.0.1/dbhome_1 -dbtype SINGLE -instance MyDB -domain team-w.local -spfile /u02/app/oracle/oradata/MyDB_03/dbs/spfileMyDB.ora -pwfile /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/orapwMyDB -role PHYSICAL_STANDBY -startoption MOUNT -stopoption IMMEDIATE -dbname MyDB -node ODA03 -acfspath "/u02/app/oracle/oradata/MyDB_03,/u03/app/oracle"
I stopped the database :
SQL> shutdown immediate; ORA-01109: database not open Database dismounted. ORACLE instance shut down.
And started it again with the grid infrastructure :
oracle@ODA03:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/ [MyDB] MyDB ********* dbi services Ltd. ********* STATUS : STOPPED ************************************* oracle@ODA03:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/ [MyDB] srvctl status database -d MyDB_03 Instance MyDB is not running on node ODA03 oracle@ODA03:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/ [MyDB] srvctl start database -d MyDB_03 oracle@ODA03:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/ [MyDB] srvctl status database -d MyDB_03 Instance MyDB is running on node ODA03
dbvisit synchronization
We now have our standby database created on the ODA. We just need to synchronize it with the primary.
Run a gap report
Executing a gap report, we can see that the newly created database is running almost 4 hours behind.
oracle@srv02:/u01/app/dbvisit/standby/ [rdbms12201] ./dbvctl -d myDBSTD1 -i ============================================================= Dbvisit Standby Database Technology (8.0.26_0_g3fdeaadd) (pid 321953) dbvctl started on srv02: Mon May 20 16:24:35 2019 ============================================================= Dbvisit Standby log gap report for myDB thread 1 at 201905201624: ------------------------------------------------------------- Destination database on ODA03 is at sequence: 58050. Source database on srv02 is at log sequence: 58080. Source database on srv02 is at archived log sequence: 58079. Dbvisit Standby last transfer log sequence: . Dbvisit Standby last transfer at: . Archive log gap for thread 1: 29. Transfer log gap for thread 1: 58079. Standby database time lag (DAYS-HH:MI:SS): +03:39:01. ============================================================= dbvctl ended on srv02: Mon May 20 16:24:40 2019 =============================================================
Send the archive logs from primary to the standby database
I have been shipping the last archive logs from the primary database to the newly created standby.
oracle@srv02:/u01/app/dbvisit/standby/ [rdbms12201] ./dbvctl -d myDBSTD1
=============================================================
Dbvisit Standby Database Technology (8.0.26_0_g3fdeaadd) (pid 326409)
dbvctl started on srv02: Mon May 20 16:29:14 2019
=============================================================
>>> Obtaining information from standby database (RUN_INSPECT=Y)... done
Thread: 1 Archive log gap: 30. Transfer log gap: 58080
>>> Sending heartbeat message... skipped
>>> First time Dbvisit Standby runs, Dbvisit Standby configuration will be copied to
ODA03...
>>> Transferring Log file(s) from myDB on srv02 to ODA03 for thread 1:
thread 1 sequence 58051 (1_58051_987102791.dbf)
thread 1 sequence 58052 (1_58052_987102791.dbf)
...
...
...
thread 1 sequence 58079 (1_58079_987102791.dbf)
thread 1 sequence 58080 (1_58080_987102791.dbf)
=============================================================
dbvctl ended on srv02: Mon May 20 16:30:50 2019
=============================================================
Apply archive logs on the standby database
Then I could finally apply the archive logs on the standby database.
oracle@ODA03:/u01/app/dbvisit/standby/ [myDB] ./dbvctl -d myDBSTD1
=============================================================
Dbvisit Standby Database Technology (8.0.26_0_g3fdeaadd) (pid 21504)
dbvctl started on ODA03: Mon May 20 16:33:42 2019
=============================================================
>>> Sending heartbeat message... skipped
>>> Applying Log file(s) from srv02 to myDB on ODA03:
thread 1 sequence 58051 (1_58051_987102791.arc)
thread 1 sequence 58052 (1_58052_987102791.arc)
...
...
...
thread 1 sequence 58079 (1_58079_987102791.arc)
thread 1 sequence 58080 (1_58080_987102791.arc)
Last applied log(s):
thread 1 sequence 58080
Next SCN required for recovery 49719323442 generated at 2019-05-20:16:27:09 +02:00.
Next required log thread 1 sequence 58081
=============================================================
dbvctl ended on ODA03: Mon May 20 16:36:52 2019
=============================================================
Run a gap report
Running a new gap report, we can see that there is no delta between the primary and the standby database.
oracle@srv02:/u01/app/dbvisit/standby/ [rdbms12201] ./dbvctl -d myDBSTD1 -i ============================================================= Dbvisit Standby Database Technology (8.0.26_0_g3fdeaadd) (pid 335068) dbvctl started on srv02: Mon May 20 16:37:53 2019 ============================================================= Dbvisit Standby log gap report for myDB thread 1 at 201905201637: ------------------------------------------------------------- Destination database on ODA03 is at sequence: 58081. Source database on srv02 is at log sequence: 58082. Source database on srv02 is at archived log sequence: 58081. Dbvisit Standby last transfer log sequence: 58081. Dbvisit Standby last transfer at: 2019-05-20 16:37:36. Archive log gap for thread 1: 0. Transfer log gap for thread 1: 0. Standby database time lag (DAYS-HH:MI:SS): +00:00:01. ============================================================= dbvctl ended on srv02: Mon May 20 16:37:57 2019 =============================================================
Preparing the database for switchover
Are we done? Absolutely not. In order to be able to successfully perform a switchover, 3 main modifications are mandatory on the non-ODA Server (running non-OMF database) :
- The future database files should be OMF
- The online redo log should be newly created
- The temporary file should be newly created
Otherwise you might end with unsuccessfull switchover having below errors :
>>> Starting Switchover between srv02 and ODA03
Running pre-checks ... failed
No rollback action required
>>> Database on server srv02 is still a Primary Database
>>> Database on server ODA03 is still a Standby Database
<<<>>>
PID:40386
TRACEFILE:40386_dbvctl_switchover_myDBSTD1_201905272153.trc
SERVER:srv02
ERROR_CODE:1
Remote execution error on ODA03.
====================Remote Output start: ODA03=====================
<<<>>>
PID:92292
TRACEFILE:92292_dbvctl_f_gs_get_info_standby_myDBSTD1_201905272153.trc
SERVER:ODA03
ERROR_CODE:2146
Dbvisit Standby cannot proceed:
Cannot create standby data or temp file /usr/oracle/oradata/myDB/temp01.dbf for primary
file /usr/oracle/oradata/myDB/temp01.dbf as location /usr/oracle/oradata/myDB does not
exist on the standby.
Cannot create standby data or temp file /usr/oracle/oradata/myDB/lx_bi_temp01.dbf for
primary file /usr/oracle/oradata/myDB/lx_bi_temp01.dbf as location /usr/oracle/oradata/myDB
does not exist on the standby.
Review the following standby database parameters:
db_create_file_dest = /u02/app/oracle/oradata/myDB_03
db_file_name_convert =
>>>> Dbvisit Standby terminated <<<>>> Dbvisit Standby terminated <<<<
Having new OMF configuration
There is no need to convert the full database into OMF. A database can run having both file naming configuration, non-OMF and OMF. We just need to have the database working now with OMF configuration. For this we will just apply the appropriate value to the init parameter. In my case the existing primary database was storing all data and redo files in the /opt/oracle/oradata directory.
SQL> alter system set DB_CREATE_FILE_DEST='/opt/oracle/oradata' scope=both; System wurde geändert. SQL> alter system set DB_CREATE_ONLINE_LOG_DEST_1='/opt/oracle/oradata' scope=both; System wurde geändert.
Refresh the online log
We will create new OMF redo log files as described below.
The current redo log configuration :
SQL> select v$log.group#, member, v$log.status from v$logfile, v$log where v$logfile.group#=v$log.group#;
GROUP# MEMBER STATUS
---------- -------------------------------------------------- ----------
12 /opt/oracle/oradata/myDB/redo12.log ACTIVE
13 /opt/oracle/oradata/myDB/redo13.log CURRENT
15 /opt/oracle/oradata/myDB/redo15.log INACTIVE
16 /opt/oracle/oradata/myDB/redo16.log INACTIVE
1 /opt/oracle/oradata/myDB/redo1.log INACTIVE
2 /opt/oracle/oradata/myDB/redo2.log INACTIVE
17 /opt/oracle/oradata/myDB/redo17.log INACTIVE
18 /opt/oracle/oradata/myDB/redo18.log INACTIVE
19 /opt/oracle/oradata/myDB/redo19.log INACTIVE
20 /opt/oracle/oradata/myDB/redo20.log INACTIVE
3 /opt/oracle/oradata/myDB/redo3.log INACTIVE
4 /opt/oracle/oradata/myDB/redo4.log INACTIVE
5 /opt/oracle/oradata/myDB/redo5.log INACTIVE
6 /opt/oracle/oradata/myDB/redo6.log INACTIVE
7 /opt/oracle/oradata/myDB/redo7.log INACTIVE
8 /opt/oracle/oradata/myDB/redo8.log ACTIVE
9 /opt/oracle/oradata/myDB/redo9.log ACTIVE
10 /opt/oracle/oradata/myDB/redo10.log ACTIVE
11 /opt/oracle/oradata/myDB/redo11.log ACTIVE
14 /opt/oracle/oradata/myDB/redo14.log INACTIVE
For all INACTIVE redo log groups, we will be able to drop the group and create it again with the OMF naming convention :
SQL> alter database drop logfile group 1; Datenbank wurde geändert. SQL> alter database add logfile group 1; Datenbank wurde geändert.
In order to move to the next redo group and release the current one, we will run a switch log file :
SQL> alter system switch logfile; System wurde geändert.
To move the ACTIVE redo log to INACTIVE we will run a checkpoint :
SQL> alter system checkpoint; System wurde geändert.
And then drop and recreate the last INACTIVE redo groups :
SQL> alter database drop logfile group 10; Datenbank wurde geändert. SQL> alter database add logfile group 10; Datenbank wurde geändert.
To finally have all our online log with OMF format :
SQL> select v$log.group#, member, v$log.status from v$logfile, v$log where v$logfile.group#=v$log.group# order by group#;
GROUP# MEMBER STATUS
---------- ------------------------------------------------------------ ----------
1 /opt/oracle/oradata/myDB/onlinelog/o1_mf_1_ggqx5zon_.log INACTIVE
2 /opt/oracle/oradata/myDB/onlinelog/o1_mf_2_ggqxjky2_.log INACTIVE
3 /opt/oracle/oradata/myDB/onlinelog/o1_mf_3_ggqxjodl_.log INACTIVE
4 /opt/oracle/oradata/myDB/onlinelog/o1_mf_4_ggqxkddc_.log INACTIVE
5 /opt/oracle/oradata/myDB/onlinelog/o1_mf_5_ggqxkj1t_.log INACTIVE
6 /opt/oracle/oradata/myDB/onlinelog/o1_mf_6_ggqxkmnm_.log CURRENT
7 /opt/oracle/oradata/myDB/onlinelog/o1_mf_7_ggqxn373_.log UNUSED
8 /opt/oracle/oradata/myDB/onlinelog/o1_mf_8_ggqxn7b3_.log UNUSED
9 /opt/oracle/oradata/myDB/onlinelog/o1_mf_9_ggqxnbxd_.log UNUSED
10 /opt/oracle/oradata/myDB/onlinelog/o1_mf_10_ggqxvlbf_.log UNUSED
11 /opt/oracle/oradata/myDB/onlinelog/o1_mf_11_ggqxvnyg_.log UNUSED
12 /opt/oracle/oradata/myDB/onlinelog/o1_mf_12_ggqxvqyp_.log UNUSED
13 /opt/oracle/oradata/myDB/onlinelog/o1_mf_13_ggqxvv2o_.log UNUSED
14 /opt/oracle/oradata/myDB/onlinelog/o1_mf_14_ggqxxcq7_.log UNUSED
15 /opt/oracle/oradata/myDB/onlinelog/o1_mf_15_ggqxxgfg_.log UNUSED
16 /opt/oracle/oradata/myDB/onlinelog/o1_mf_16_ggqxxk67_.log UNUSED
17 /opt/oracle/oradata/myDB/onlinelog/o1_mf_17_ggqxypwg_.log UNUSED
18 /opt/oracle/oradata/myDB/onlinelog/o1_mf_18_ggqy1z78_.log UNUSED
19 /opt/oracle/oradata/myDB/onlinelog/o1_mf_19_ggqy2270_.log UNUSED
20 /opt/oracle/oradata/myDB/onlinelog/o1_mf_20_ggqy26bj_.log UNUSED
20 Zeilen ausgewählt.
Refresh temporary file
The database was using 2 temp tablespaces : TEMP and MyDB_BI_TEMP.
We first need to add new temp files in OMF format for both tablespaces.
SQL> alter tablespace TEMP add tempfile size 20G; Tablespace wurde geändert. SQL> alter tablespace myDB_BI_TEMP add tempfile size 20G; Tablespace wurde geändert.
Both tablespace will now include 2 files : a previous non-OMF one and a new OMF one :
SQL> @qdbstbsinf.sql Enter a tablespace name filter (US%): TEMP TABLESPACE_NAME FILE_NAME STATUS SIZE_MB AUTOEXTENSIB MAXSIZE_MB -------------------- ------------------------------------------------------------ --------------- ---------- ------------ ---------- TEMP /opt/oracle/oradata/myDB/datafile/o1_mf_temp_ggrjzm9o_.tmp ONLINE 20480 NO 0 TEMP /usr/oracle/oradata/myDB/temp01.dbf ONLINE 20480 NO 0 SQL> @qdbstbsinf.sql Enter a tablespace name filter (US%): myDB_BI_TEMP TABLESPACE_NAME FILE_NAME STATUS SIZE_MB AUTOEXTENSIB MAXSIZE_MB -------------------- ------------------------------------------------------------ --------------- ---------- ------------ ---------- myDB_BI_TEMP /opt/oracle/oradata/myDB/datafile/o1_mf_lx_bi_te_ggrk0wxz_.tmp ONLINE 20480 NO 0 myDB_BI_TEMP /usr/oracle/oradata/myDB/lx_bi_temp01.dbf ONLINE 20480 YES 5120
Dropping temporary file will end into error :
SQL> alter database tempfile '/usr/oracle/oradata/myDB/temp01.dbf' drop including datafiles; alter database tempfile '/usr/oracle/oradata/myDB/temp01.dbf' drop including datafiles * FEHLER in Zeile 1: ORA-25152: TEMPFILE kann momentan nicht gelöscht werden
We need to restart the database. This will only be possible during the maintenance windows scheduled to run the switchover.
SQL> shutdown immediate; Datenbank geschlossen. Datenbank dismounted. ORACLE-Instanz heruntergefahren. SQL> startup ORACLE-Instanz hochgefahren. Total System Global Area 5,3687E+10 bytes Fixed Size 26330584 bytes Variable Size 3,3152E+10 bytes Database Buffers 2,0401E+10 bytes Redo Buffers 107884544 bytes Datenbank mounted. Datenbank geöffnet.
The previous non-OMF temporary file can now be deleted :
SQL> alter database tempfile '/usr/oracle/oradata/myDB/temp01.dbf' drop including datafiles; Datenbank wurde geändert. SQL> alter database tempfile '/usr/oracle/oradata/myDB/lx_bi_temp01.dbf' drop including datafiles; Datenbank wurde geändert.
And we only have OMF temporary files now :
SQL> @qdbstbsinf.sql Enter a tablespace name filter (US%): TEMP TABLESPACE_NAME FILE_NAME STATUS SIZE_MB AUTOEXTENSIB MAXSIZE_MB -------------------- ------------------------------------------------------------ --------------- ---------- ------------ ---------- TEMP /opt/oracle/oradata/myDB/datafile/o1_mf_temp_ggrjzm9o_.tmp ONLINE 20480 NO 0 SQL> @qdbstbsinf.sql Enter a tablespace name filter (US%): myDB_BI_TEMP TABLESPACE_NAME FILE_NAME STATUS SIZE_MB AUTOEXTENSIB MAXSIZE_MB -------------------- ------------------------------------------------------------ --------------- ---------- ------------ ---------- myDB_BI_TEMP /opt/oracle/oradata/myDB/datafile/o1_mf_lx_bi_te_ggrk0wxz_.tmp ONLINE 20480 NO 0
Testing switchover
We are now ready to test the switchover from current srv02 primary to ODA03 server after making sure both databases are synchronized.
oracle@srv02:/u01/app/dbvisit/standby/ [MyDB] ./dbvctl -d MyDBSTD1 -o switchover
=============================================================
Dbvisit Standby Database Technology (8.0.26_0_g3fdeaadd) (pid 12196)
dbvctl started on srv02: Tue May 28 00:07:34 2019
=============================================================
>>> Starting Switchover between srv02 and ODA03
Running pre-checks ... done
Pre processing ... done
Processing primary ... done
Processing standby ... done
Converting standby ... done
Converting primary ... done
Completing ... done
Synchronizing ... done
Post processing ... done
>>> Graceful switchover completed.
Primary Database Server: ODA03
Standby Database Server: srv02
>>> Dbvisit Standby can be run as per normal:
dbvctl -d MyDBSTD1
PID:12196
TRACE:12196_dbvctl_switchover_MyDBSTD1_201905280007.trc
=============================================================
dbvctl ended on srv02: Tue May 28 00:13:31 2019
=============================================================
Conclusion
With dbvisit standby it is possible to mix non-OMF and OMF databases after completing several manual steps. The final recommendation would be to run a unique configuration. This is why, after having run a switchover to the new ODA03 database, and making sure the new database is stable, we created from scratch the old primary srv02 database with OMF configuration. Converting a database to OMF using move option is not possible with standard edition.
Cet article Adding a dbvisit standby database on the ODA in a non-OMF environment est apparu en premier sur Blog dbi services.