Arjen Visser
10-24-2008, 10:08 AM
Problem:
When using Dbvisit Standby prior to version 6.0.28 with a primary database in a different structure to the standby database, any new tablespaces or datafiles will not be added automatically to the standby database.
For example:
1) In ASM MODE ( Primary Database )
2) In Normal Mode ( Standby Database )
When a new tablespace is created in the primary database which is in ASM, the datafile will not be created on the standby because this database is using regular filesystem.
SPECIAL NOTE: As of Dbvisit Standby 6.0.28 datafiles will be added automatically to the standby database for all datafiles (ASM, OMF, regular). The location can also be different between the primary and standby database.
This solution can also be used when Dbvisit Standby fails to add the datafile to the standby database. This can be Return code = 412 or Return code = 410.
Solution:
Find out what the missing datafile is on the standby database. Do this by comparing the datafiles between primary and standby database.
This can be done by running the following command on both primary and standby server:
dbv_functions -F <database>
Run the following SQL on the standby database:
SQL> select name, file# from v$datafile where status = 'RECOVER';
This will give you the internal name of the datafile on the standby database.
Example, this may give you the name: /oracle/testdev/product/10.2.0.1/dbs/UNNAMED00012
Then you can rename the datafile to what you like with the following SQL:
SQL> alter database create datafile
'/oracle/testdev/product/10.2.0.1/dbs/UNNAMED00012'
as
'/oradata/testdev/dbs/ucsc_dev01.dbf';
Where /oradata/testdev/dbs/ucsc_dev01.dbf
is the file name for your standby database.
Note:
If the following statement does not return any rows:
SQL> select name, file# from v$datafile where status = 'RECOVER';
Then the rename SQL command is as follows:
SQL> alter database create datafile
'/oradata/testdev/dbs/ucsc_dev01.dbf'
as
'/oradata/testdev/dbs/ucsc_dev01.dbf';
Dbvisit Standby can now be run again on the standby server to continue to update the standby database.
When using Dbvisit Standby prior to version 6.0.28 with a primary database in a different structure to the standby database, any new tablespaces or datafiles will not be added automatically to the standby database.
For example:
1) In ASM MODE ( Primary Database )
2) In Normal Mode ( Standby Database )
When a new tablespace is created in the primary database which is in ASM, the datafile will not be created on the standby because this database is using regular filesystem.
SPECIAL NOTE: As of Dbvisit Standby 6.0.28 datafiles will be added automatically to the standby database for all datafiles (ASM, OMF, regular). The location can also be different between the primary and standby database.
This solution can also be used when Dbvisit Standby fails to add the datafile to the standby database. This can be Return code = 412 or Return code = 410.
Solution:
Find out what the missing datafile is on the standby database. Do this by comparing the datafiles between primary and standby database.
This can be done by running the following command on both primary and standby server:
dbv_functions -F <database>
Run the following SQL on the standby database:
SQL> select name, file# from v$datafile where status = 'RECOVER';
This will give you the internal name of the datafile on the standby database.
Example, this may give you the name: /oracle/testdev/product/10.2.0.1/dbs/UNNAMED00012
Then you can rename the datafile to what you like with the following SQL:
SQL> alter database create datafile
'/oracle/testdev/product/10.2.0.1/dbs/UNNAMED00012'
as
'/oradata/testdev/dbs/ucsc_dev01.dbf';
Where /oradata/testdev/dbs/ucsc_dev01.dbf
is the file name for your standby database.
Note:
If the following statement does not return any rows:
SQL> select name, file# from v$datafile where status = 'RECOVER';
Then the rename SQL command is as follows:
SQL> alter database create datafile
'/oradata/testdev/dbs/ucsc_dev01.dbf'
as
'/oradata/testdev/dbs/ucsc_dev01.dbf';
Dbvisit Standby can now be run again on the standby server to continue to update the standby database.