Good Contents Are Everywhere, But Here, We Deliver The Best of The Best.Please Hold on!
Before we talk about Dbvisit Standby and it’s components, let’s talk little bit about about Disaster Recovery and Business Continuity.


What is Business Continuity?

In the event of a disaster, the process of failing over your server from the primary to the secondary site is known as Disaster Recovery. A disaster recovery solution provides your Company with Business Continuity.

The main purpose of Dbvisit Standby is to provide the Organizations with greater Business continuity.



What is Physical Replication?

The process of creating a Standby database from the source or primary database is known as Physical Replication. The Standby database is kept in sync using the archive logs generated on the source database to ensure that the Standby database is an exact copy of the source database.



How to Configure Disaster Recovery environment with Dbvisit Standby?

The following are the Disaster Recovery Configurations options available:
  1. On-Premise to On-Premise
  2. On-Premise to Cloud
  3. Cloud to On-Premise
  4. Cloud to Cloud

Dbvisit Standby Architecture

These are four main components that make up Dbvisit Standby’s Architecture.
  • Dbvserver
  • Dbvagent
  • Dbvnet
  • Standby core


Dbvserver:

It hosts secure web based user interface for Dbvisit standby. Multiple users can manage various different DR configurations. It provide graphical overview of setup, running and reporting of DR sites. It is recommended to that Dbvserver which has a small footprint be installed on different server.

Dbvserver details:
Using a small VM machine should be sufficient
HTTPS protocol port 4433
Host Managed by Dbvserver can be Windows or Linux
It has a small repository where information about executed tasks are store
It support Chrome, FireFox and Safari browsers

Dbvagent:

It is used to manages the communication between Dbvserver (web based user interface) and Dbvisit Standby core. Communication between Dbvagent and Dbvserver is encrypted. Dbvisit agent has a small footprint and listens for secure connection on port 7891 from the central console. The Dbvisit agent must run on the host managed by the Dbvisit Standby Central console. A user can bypass Dbvserver web based user interface and directly access CLI if preferred. In this case Dbvisit agent does not have to be installed or can be left shutdown.

Dbvnet:

It is responsible for secure communication between primary and standby systems. It essentially provides an encrypted transport layer to copy files and execute remote commands between primary and standby database server. It runs on both primary and standby servers and configured during installation process. Dbvnet removes any dependency SSH had for providing network communication  between primary and standby nodes. It is started as background process and it runs independently from the Dbvserver and Dbvagent.

Dbvisit Standby Core:

It is also known as command line interface. It is the heart of Dbvisit standby. This is where all commands are run to enable Dbvisit Standby to function. A user can bypass Dbvserver web based user interface and directly access CLI if preferred.

Dbvisit Standby Core allow you:

  •     Create standby database (CSD)
  •     Extract and Send archive logs to standby (SEND)
  •     Recover standby database using shipped archived logs (RECOVER)
  •     Perform Graceful Switchover also known as role reversal (GS)
  •     Synchronize a standby database (SYNC)
  •     In case of disaster activate the standby database (FAILVOER)
  •     It also provide API options, more than 80 command line API options (API)

dbvctl : The Dbvisit Standby Control CLI Utility



Other Dbvisit Standby Components

  • Database Configuration File (DDC)
Contains the Dbvisit Standby setting for a specific primary and standby pair.
Generated during the setup for each database.
can be edited with any text editor or by running ‘dbvisit -o setup’ or through web based GUI

  • Database Repository (DDR)
This is repository used by Dbvisit Standby to store internal information about Dbvisit Standby Configuration and functionality being performed.
It is a small *.db file located in the standby/conf sub directory.

  • Trace Files
Contains information about Dbvisit standby processing.
These files are required by Dbvisit Support in the event when an error is raised.
They are located in the standby/trace sub directory.



Dbvisit Standby functionality

Dbvisit Standby follows a simple 3 Steps functionality. The same is illustrated in the picture below:

Step 1: Log Extraction : Dbvisit Standby will extract the primary database archive logs from the database archive destination.
Step 2: Transport : The second step in the process will be to copy these extracted archive logs to the standby site.
Step 3: Log Apply : The third step in the process is Dbvisit Standby applying the transferred archive logs to the standby database.




Dbvisit Standby on Oracle RAC

  • Dbvisit Standby can be used together with Oracle RAC (Real Application Cluster)
  • Oracle RAC together with Dbvisit Standby standby database(s) allows scalability and provides high availability and disaster recovery
  • Dbvisit Standby supports archive logs in Oracle ASM (Automatic Storage Management) file system
  • The standby database can be a RAC or Non-RAC standby database


Conclusion

In this article we have learned Dbvisit Standby Architecture, different Dbvisit Standby components and Dbvisit Standby functionality.


0

In a Data Guard configuration it is very common to these the ‘UNNAMED File Issue/Error’ on Standby Database when you add new datafile on Primary Database and there is no space available on the standby database server or improper parameter settings related to standby file management. This will result in the following Oracle error messages ORA-01111, ORA-01110, ORA-01157 and cause MRP process to crash resulting in Standby database ‘out of sync’ with primary. 

Also note that, If STANDBY_FILE_MANAGEMENT parameter is not configured as ‘AUTO’ in your Data Guard environment and a datafile is created on Primary database,  then the file created on standby server will have unnamed file name and it is created under $ORACLE_HOME/dbs directory. 

Environment Details:

Primary DB HostName / DB Instance : PRD101/ ORCLPRD
Standby DB HostName / DB Instance : STD101/ ORCLSTDY
Database version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0

Alert log on Standby DB:

Sun May 21 15:05:13 2017
Errors in file /u01/app/oracle/diag/rdbms/orclstdy/orclstdy/trace/orclstdy_dbw0_61177.trc:
ORA-01186: file 11 failed verification tests
ORA-01157: cannot identify/lock data file 11 – see DBWR trace file
ORA-01111: name for data file 11 is unknown – rename to correct file
ORA-01110: data file 11: ‘/u01/app/oracle/product/11.2.0.4/db/dbs/UNNAMED00011’
File 11 not verified due to error ORA-01157
MRP0: Background Media Recovery terminated with error 1111
Errors in file /u01/app/oracle/diag/rdbms/orclstdy/orclstdy/trace/orclstdy_pr00_11317.trc:
ORA-01111: name for data file 11 is unknown – rename to correct file
ORA-01110: data file 11: ‘/u01/app/oracle/product/11.2.0.4/db/dbs/UNNAMED00011’
ORA-01157: cannot identify/lock data file 11 – see DBWR trace file
ORA-01111: name for data file 11 is unknown – rename to correct file
ORA-01110: data file 11: ‘/u01/app/oracle/product/11.2.0.4/db/dbs/UNNAMED00011’
Managed Standby Recovery not using Real Time Apply
Recovery Slave PR00 previously exited with exception 1111
MRP0: Background Media Recovery process shutdown (orclstdy)

Troubleshooting Steps:

Let us see how we can fix this error and get Standby In-synch again with Primary.

  • Run following at Standby side. 

SQL> set lines 300
SQL> select name,open_mode,database_role from v$database;

NAME      OPEN_MODE            DATABASE_ROLE
——— ——————– —————-
ORCLSTDY  READ ONLY            PHYSICAL STANDBY

SQL> select PROCESS,THREAD#,SEQUENCE#,STATUS from v$managed_standby where process=’MRP0′;

no rows selected  –> MRP is not Running

SQL> set sqlblanklines on

SQL> SELECT ARCH.THREAD# “Thread”, ARCH.SEQUENCE# “Last Sequence Received”, APPL.SEQUENCE# “Last Sequence Applied”, (ARCH.SEQUENCE# – APPL.SEQUENCE#) “Difference” FROM (SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH, (SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL WHERE ARCH.THREAD# = APPL.THREAD# ORDER BY 1;

    Thread Last Sequence Received Last Sequence Applied Difference

———- ———————- ——————— ———-

         1                  13817                 13708        109


  • Stop MRP if it’s not already stopped.


SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Database altered.

SQL> show parameter standby_file_management

NAME                                 TYPE                             VALUE
———————————— ——————————– ——————————
standby_file_management              string                           AUTO


SQL> col NAME for a70
SQL>  select * from v$recover_file where error like ‘%UNNAMED%’;

     FILE# NAME
———- ———————————————————————-
        11 /u01/app/oracle/product/11.2.0.4/db/dbs/UNNAMED00011

Here the datafile #11 is renamed to UNNAMED00011 on standby database 


  • Identify the datafile name on primary database

SQL>  select file#,name from v$datafile where file#=11;

FILE#   NAME
—— ———————————————————————-
11  /u02/oradata/datafile/orclprd/users01.dbf


  • Temporary change setting for STANDBY_FILE_MANAGEMENT to MANUAL, we can revert this setting once we finish the activity. 

SQL> alter system set standby_file_management=MANUAL scope=both;

System altered.

SQL> show parameter standby_file_management

NAME                                 TYPE                             VALUE
———————————— ——————————– ——————————
standby_file_management              string 


  • Create a new datafile with same name as of Primary ( Name obtained above)

SQL> alter database create datafile ‘/u01/app/oracle/product/11.2.0.4/db/dbs/UNNAMED00011’ as ‘/u02/oradata/datafile/orclstdy/users01.dbf’;

Database altered.

SQL> select file#,name from v$datafile where file#=11;

     FILE# NAME
———- ———————————————————————-
        11 /u02/oradata/datafile/orclstdy/users01.dbf


  • Revert STANDBY_FILE_MANAGEMENT to AUTO 

  SQL> alter system set standby_file_management=AUTO scope=both;

System altered.


  • Check if MRP is up 

SQL> select PROCESS,THREAD#,SEQUENCE#,STATUS from v$managed_standby where process=’MRP0′;

no rows selected


  • Start MRP process and monitor lag gap. MRP will start applying logs if archives are available at Standby side.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Database altered.


  • On Primary database switch log or archive log and check the archive logs are being shipped to Standby database and MRP is applying them

SQL> alter system switch logfile;


  • Verify standby database 

SQL> SELECT ARCH.THREAD# “Thread”, ARCH.SEQUENCE# “Last Sequence Received”, APPL.SEQUENCE# “Last Sequence Applied”, (ARCH.SEQUENCE# – APPL.SEQUENCE#) “Difference” FROM (SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH, (SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL WHERE ARCH.THREAD# = APPL.THREAD# ORDER BY 1;

    Thread Last Sequence Received Last Sequence Applied Difference

———- ———————- ——————— ———-

         1                  13818                 13713        105


SQL> /

    Thread Last Sequence Received Last Sequence Applied Difference
———- ———————- ——————— ———-
         1                  13820                 13820          0

You can observe, Standby Database is in synch with Primary and MRP is working perfect. 

Conclusion

In this article we have learned how to fix ‘UNNAMED File Issue/Error’ on Standby Database when you add new datafile on Primary Database and there is no space available on the standby database server or improper parameter settings related to standby file management. To avoid these kind of errors, also ensure that you have correct Data Guard setup as per best practices and there is sufficient file system space on both Primary and Standby servers

1