/
Miscellaneous Operation Tasks

Miscellaneous Operation Tasks

Owned by Jan Klinke
Last updated: Mar 20, 2025
6 min read

This page contains information abou small and helpful operational tasks.

1. GUI Advanced Options

Advanced options can be selected and run by selecting advanced options from the ACTIONS pane:

image-20250224-111214.png

Before executing any Advanced option, you must stop automated standby update (ASU)

Recreate Standby Controlfile and Refresh one Datafile will cause your standby database to become inconsistent. Your standby database will become consistent again only after you enable again ASU and the transfer & apply jobs complete successfully.

1.1 Recreate Standby Control File

You can at any point in time decide to recreate standby controlfile. This is useful for example when you modify your redolog setting in your primary database. The controlfile can be recreated at any time. There is no option to specify, one you select “Recreate Standby Control File” click on start and wait for the task to complete:

image-20250224-111431.png

It is also possible to run following command on the primary server:

$ /usr/dbvisit/standbymp/oracle/dbvctl -d SLASH -f create_standby_ctl =>Replace current standby controfiles on czlin0232 with new standby control file? <Yes/No> [No]: yes >>> Create standby control file... done >>> Copy standby control file to czlin0232... done >>> Recreate standby control file... done >>> Standby controfile(s) on czlin0232 recreated. To complete please run dbvctl on the primary, then on the standby.

1.2 Refresh One Datafile

You can at any time force a refresh for a datafile on standby (for example if the datafile became corrupted on standby). You will need to specify file number and backup location on primary and standby which will be used for refresh:

image-20250224-112313.png

Once you click on start, new task will appear:

image-20250224-112533.png

Similar to controlfile refresh, dbvctl command on primary is available as well:

$ /usr/dbvisit/standbymp/oracle/dbvctl -d SLASH -f create_standby_ctl =>Replace current standby controfiles on czlin0232 with new standby control file? <Yes/No> [No]: yes >>> Create standby control file... done >>> Copy standby control file to czlin0232... done >>> Recreate standby control file... done >>> Standby controfile(s) on czlin0232 recreated. To complete please run dbvctl on the primary, then on the standby. [oracle@czlin0231 mp]$ /usr/dbvisit/standbymp/oracle/dbvctl -d SLASH -f refresh_datafile -a file_id=4 -a tmp_dir=/tmp -a tmp_dir_dr=/tmp >>> Back up datafile 4... done >>> Transfer backup of datafile 4 to standby server... done >>> Catalog backup... done >>> Restore datafile 4... done >>> Datafile 4 refresh complete /u02/app/oracle/oradata/SLASH/EDBEF650B7D3344BE053E708A8C06904/datafile/o1_mf_sysaux_mqzsrf13_.dbf on czlin0231 /u02/app/oracle/oradata/SLASH/EDBEF650B7D3344BE053E708A8C06904/datafile/o1_mf_sysaux_mv8tznj3_.dbf on czlin0232

1.3 Send one logfile

This function is for situations where you need to transfer single archivelog again to the standby server. The important condition is that such archivelog file must have been already transfered some time in the past to the standby database. This is helpful for example in situations when the archivelog got corrupted during transfer.

We do recommend that you check the existence of the archivelog you want to transfer on standby server in directory ARCHDEST/Thread#_Sequence#.arc (refer to DDC file for your ARCHDEST value). If the file exists, delete it.

You will need to enter thread# and sequence#:

image-20250224-112841.png

Once you start the job, task will appear:

image-20250224-113808.png

Running Dbvctl command is also possible on primary:

$ /usr/dbvisit/standbymp/oracle/dbvctl -d SLASH -r 4096 -t 1 ============================================================= Dbvisit Standby Database Technology (12.1.0RC) (pid 2819983) dbvctl started on czlin0231: Mon Feb 24 12:39:41 2025 ============================================================= >>> Obtaining information from standby database (RUN_INSPECT=Y)... done Thread: 1 Archive log gap: 0. Transfer log gap: 0 Note FORCE_LOGGING is disabled in the primary database. >>> Transferring Log file(s) from SLASH on czlin0231 to czlin0232: thread 1 sequence 4096 (o1_mf_1_4096_mvrp9ojo_.arc)... done ============================================================= dbvctl ended on czlin0231: Mon Feb 24 12:39:45 2025 =============================================================

2. Transfer all unapplied archivelogs to the standby Database

Dbvisit has built in functionality to transfer (or re-transfer) all unapplied archivelogs to the standby database. This is helpful when ASU transfer job would request for any reason to transfer inappropriate archivelog. For example standby database would be on recovery sequence 4094 and ASU job would request sequence number 1024 to be transferred.

In such case, it’s possible to use following procedure:

  • stop ASU

  • run command on primary (this action is command line only):

$ /usr/dbvisit/standbymp/oracle/dbvctl -d SLASH -R ============================================================= Dbvisit Standby Database Technology (12.1.0RC) (pid 2820137) dbvctl started on czlin0231: Mon Feb 24 12:48:23 2025 ============================================================= Note FORCE_LOGGING is disabled in the primary database. >>> Resynch option given. Dbvisit Standby configuration will be copied to czlin0232... >>> Transferring Log file(s) from SLASH on czlin0231 to czlin0232: thread 1 sequence 4098 (o1_mf_1_4098_mvrq3s7g_.arc)... done thread 1 sequence 4099 (o1_mf_1_4099_mvrq3t3k_.arc)... done thread 1 sequence 4100 (o1_mf_1_4100_mvrq3tvk_.arc)... done thread 1 sequence 4101 (o1_mf_1_4101_mvrq3vnr_.arc)... done ============================================================= dbvctl ended on czlin0231: Mon Feb 24 12:48:27 2025 =============================================================

  • run manually backup & send archivelog

  • enable ASU again

For referrence how to modify ASU and send / apply archivelog, check: Post Tasks - Automatic Standby Update (ASU)

3. Setting Standby Update Delay

You can enable the delay for applying archivelogs on your standby database. This helps in situations when you would like to prevent changes from your primary database to be immediately applied to standby database. For example if you won’t setup apply delay, any drop table / delete command will be applied almost immediately to the standby database.

Setting the apply delay will provide you with time window in which you can stop synchronization to prevent accidental table or row deletion to be applied on standby database (and save the data).

Archivelog transfer continues as normal (archivelogs are transferred immediately) even with apply delay set. So there is no effect on RPO. RTO is affected, because in case of disaster some time will be needed to apply all transferred archivelogs to the standby database before activation.

To enable Apply Update delay, select the “Standby Update Delay” from the ACTIONS pane:

image-20250224-120424.png

Set the desired apply delay in minutes:

image-20250224-120523.png

There is no hardcoded lower limit. But you should always aim for reasonable delay length. Set the Delay log application window to give you comfortable amout of time for:

  • detecting that there was harmful change applied to primary

  • making decision to stop the sycnhronization

  • stopping automated standby update (ASU)

Any value less than 30-60 minutes makes will very likely make no sense and will be useless.

4. Standby Read-Only Test

Standby read only test will test if the standby database can be opened in read only mode ensuring the standby database is consistent and ready for activation. After the tes, standby daabase is put into MOUNT mode again. To run the Read-Only test, select “Test Opening Standby Read Only”

image-20250224-121914.png

There is no option to be specified. After you click on start, the task with information about test result will appear:

image-20250224-122014.png

5. Start/Stop Database

You can use dbvcontrol GUI to start, stop or restart your primary and standby database. From the ACTIONS pane, select Start/Stop Database:

image-20250224-122205.png

You can the choose which database and action you want to execute:

image-20250224-122307.png

Start and restart actions always consider database role. For primary database, the start and restart will put the database into READ WRITE mode, for standby database start and restart will put the standby database into MOUNT mode.

You don’t have to use exclusively Dbvisit StandbyMP GUI for start/stop of your databases. You can of course use sqlplus or srvctl to perform these actions as well

Related content