Drop a datafile from physical standby's control file

Hi,
I am trying to create a physical standby database for my production...
1) I have taken cold backup of my primary database on 18-Nov-2013...
2) I added a datafile on 19-nov-2013 ( 'O:\ORADATA\SFMS\SFMS_DATA4.DBF' )
3) Standby control file was generated on 20-ov-2013 (today) after shutting down and then mounting the primary database...
When i try to recover the newly setup standby using archive files, i am getting the following error (datafile added on 19th Nov is missing)
SQL> recover standby database;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 39: 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
How to overcome this situation...
Can i delete the entry for the newly added datafile from the backup control file ?
When i tried to delete datafile using "alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF';", it is showing that database should be open..
SQL> alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ERROR at line 1:
ORA-01109: database not open
SQL> show parameter STANDBY_FILE_MANAGEMENT
NAME                                 TYPE        VALUE
standby_file_management              string      AUTO
SQL> alter system set STANDBY_FILE_MANAGEMENT=manual;
System altered.
SQL> show parameter STANDBY_FILE_MANAGEMENT
NAME                                 TYPE        VALUE
standby_file_management              string      MANUAL
SQL> alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ERROR at line 1:
ORA-01109: database not open
Regards,
Jibu

Jibu wrote:
Hi,
I am trying to create a physical standby database for my production...
1) I have taken cold backup of my primary database on 18-Nov-2013...
2) I added a datafile on 19-nov-2013 ( 'O:\ORADATA\SFMS\SFMS_DATA4.DBF' )
3) Standby control file was generated on 20-ov-2013 (today) after shutting down and then mounting the primary database..
Hi,
What is your version?
If you added new datafile or created new tablespace, take backup again for restore new created standby database.
If your standby database running well, DG configuration success, then this datafile will create on standby side, too.
Set STANDBY_FILE_MANAGEMENT=AUTO best practice.
When i try to recover the newly setup standby using archive files, i am getting the following error (datafile added on 19th Nov is missing)
SQL> recover standby database;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 39: 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
How to overcome this situation...
Can i delete the entry for the newly added datafile from the backup control file ?
Not need any delete datafile from standby side, you must recreate standby database, or you can take RMAN backup and restore to standby side again.
When i tried to delete datafile using "alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF';", it is showing that database should be open..
SQL> alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ERROR at line 1:
ORA-01109: database not open
SQL> show parameter STANDBY_FILE_MANAGEMENT
NAME                                 TYPE        VALUE
standby_file_management              string      AUTO
SQL> alter system set STANDBY_FILE_MANAGEMENT=manual;
System altered.
SQL> show parameter STANDBY_FILE_MANAGEMENT
NAME                                 TYPE        VALUE
standby_file_management              string      MANUAL
SQL> alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ERROR at line 1:
ORA-01109: database not open
It is not logical, Physical standby must be bit-for-bit same with Primary database.
Regards
Mahir M. Quluzade

Similar Messages

Creation of logical standby in 9i from physical standby

Hi all,
I want to create logical standby from physical standby in 9i. can anyone send a doc for this

As per the Oracle documents "You create a logical standby database by first creating a physical standby database and then transitioning it to a logical standby database"
Please take a look at the below URL.
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14239/create_ls.htm
Regards,
Sabdar Syed.

Using streams to capture data from physical standby database.

Does anybody know if it is possible to use streams to capture data from physical standby database instead of PROD database? The standby database is in read only mode. We use Oracle 11gR2.
Thanks in advance.

physical are closed : how will it managed the queues and overspill queues when target is not present? Also the data dictionary must reflect the primary but If you run capture, then you introduce rules that are not on primary: How ?

Transport Tablespace from Physical Standby in Oracle 10gr2 - 64 Bit

Hi,
How to Export Transport Tablespaces from Physical Standby Server - Oracle 10gr2 EE in Windows 2003 EE, Since Production Servers are in 24*7 Support to avoid make Read Only Tablespaces.
Regards
Harish

Open your Physical Standby in read only mode and do your export. Then mount it back in managed recovery mode.

Can I Drop a datafile from UNDOTBS

Hi!!!!
I want to drop a datafile from UNDOTBS . can I Drop it.
If yes then how to drop ? what is the effect of it on database?
If anybody knows the the answer then Pls reply..

You can do this provided test it before doing it in production
Steps.
1. Create a new Undo tablespace
2. Shutdown the database
3. Change the parameter UNDO_TABLESPACE to the newly created undo tablespace
4. Start the database
5. Do whatever you want with the old undo tablespace.

Drop one datafile from Tablespace

Hi,
I have 9i Database on Linux. I want to drop one datafile from tablespace. I have tried to drop datafile through following command but it gave no effect.
alter database datafile <datafile name> offline drop;
What should i have to do for dropping datafile?
Do the needful
Thankx in advance.

Hi
since you dont specify the database version or if you have it setup as archivelog or noarchivelog mode, i paste the drop specs for dropping a datafile, from SQL Reference manual of 9i
DROP If the database is in NOARCHIVELOG mode, you must specify the DROP
clause to take a datafile offline. However, the DROP clause does not remove the
datafile from the database. To do that, you must drop the tablespace in which the
datafile resides. Until you do so, the datafile remains in the data dictionary with the
status RECOVER or OFFLINE.
If the database is in ARCHIVELOG mode, Oracle ignores the DROP keyword.
Regards
Message was edited by:
pcambra

Standby destination control file enqueue unavailable

Hi,
more than two days ..totally i tried 3 times for creating standby database in oralce 10g ..everthing working fine but i didnt get archive log from primary database..please help me
NOTE: both primary and standby database on same system
*#standby database 'stby' (omitted common parameters)*
*.compatible='10.2.0.3.0'
*.control_files='d:\oracle\product\10.2.0\oradata\stby\controlsb01.ctl','d:\oracle\product\10.2.0\oradata\stby\controlsb02.ctl','d:\oracle\product\10.2.0\oradata\stby\controlsb03.ctl'
*.db_file_name_convert='D:\oracle\product\10.2.0\oradata\live','D:\oracle\product\10.2.0\oradata\stby'
*.db_name='live'
*.fal_client='stby'
*.fal_server='live'
*.log_archive_config='DG_CONFIG=(live,stby)'
*.log_archive_dest_1='LOCATION=D:\oracle\product\10.2.0\flash_recovery_area\stby VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=stby'
*.log_archive_dest_2='SERVICE=live ARCH ASYNC VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=live'
*.log_file_name_convert='D:\oracle\product\10.2.0\oradata\live','D:\oracle\product\10.2.0\oradata\stby'
*.remote_login_passwordfile=EXCLUSIVE
*.standby_file_management='AUTO'
*.instance_name=stby
*.db_unique_name=stby
*#primary database 'live'*
*.compatible='10.2.0.3.0'
*.control_files='d:\oracle\product\10.2.0\oradata\live\control01.ctl','d:\oracle\product\10.2.0\oradata\live\control02.ctl','d:\oracle\product\10.2.0\oradata\live\control03.ctl'
*.db_file_name_convert='D:\oracle\product\10.2.0\oradata\stby','D:\oracle\product\10.2.0\oradata\live'
*.db_name='live'
*.fal_client='live'
*.fal_server='stby'
*.log_archive_config='DG_CONFIG=(live,stby)'
*.log_archive_dest_1='LOCATION=D:\oracle\product\10.2.0\flash_recovery_area\live VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=live'
*.log_archive_dest_2='SERVICE=stby ARCH ASYNC VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=stby'
*.log_file_name_convert='D:\oracle\product\10.2.0\oradata\stby','D:\oracle\product\10.2.0\oradata\live'
*.remote_login_passwordfile=EXCLUSIVE
*.standby_file_management='AUTO'
*.instance_name=live
*.DB_UNIQUE_NAME=live
*#standby database*
SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area 251658240 bytes
Fixed Size 1290012 bytes
Variable Size 159383780 bytes
Database Buffers 83886080 bytes
Redo Buffers 7098368 bytes
Database mounted.
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> select group#,member from v$logfile;
GROUP#
MEMBER
3
D:\ORACLE\PRODUCT\10.2.0\ORADATA\STBY\REDO03.LOG
2
D:\ORACLE\PRODUCT\10.2.0\ORADATA\STBY\REDO02.LOG
1
D:\ORACLE\PRODUCT\10.2.0\ORADATA\STBY\REDO01.LOG
GROUP#
MEMBER
4
D:\ORACLE\PRODUCT\10.2.0\ORADATA\STBY\SREDO04.LOG
5
D:\ORACLE\PRODUCT\10.2.0\ORADATA\STBY\SREDO05.LOG
6
D:\ORACLE\PRODUCT\10.2.0\ORADATA\STBY\SREDO06.LOG
6 rows selected.
*#primary database*
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> select SEQUENCE#, applied from v$archived_log;
SEQUENCE# APP
15 NO
16 NO
17 NO
18 NO
19 NO
20 NO
SQL> SELECT SEQUENCE#,STATUS FROM V$MANAGED_STANDBY;
SEQUENCE# STATUS
0 CONNECTED
19 CLOSING
20 CLOSING
0 CONNECTED
0 CONNECTED
0 CONNECTED
0 CONNECTED
0 CONNECTED
*#standby database*
SQL> select * from v$archived_log;
no rows selected
*#see even my standby database open .*
SQL> alter database open;
Database altered.
*# listener.ora*
STBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = selvaPC)(PORT = 2031))
LIVE =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = selvaPC)(PORT = 2030))
SID_LIST_STBY =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = live)
(SID_NAME = stby)
SID_LIST_LIVE =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = live)
(SID_NAME = live)
*# tnsnames.ora*
STBY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = selvaPC)(PORT = 2030))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = live)
LIVE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = selvaPC)(PORT = 2031))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = stby)
*#Error in alert file..during startup primary database*
Controlfile lock conflict at host 'stby'
Possible invalid cross-instance archival configuration
ORA-16146: standby destination control file enqueue unavailable
thanks
selva..

If you user this then a lot of information ( threads) can be found with the same problem.
Anyway the original ORA-message/solution is:
Error:     ORA-16146 (ORA-16146)
Text:     standby destination control file enqueue unavailable
Cause:     The target standby destination control file is currently
     unavailable to the Remote File Server (RFS) process. This
     indicates that the target destination is the primary database
     itself.
Action:     Check for and eliminate the standby destination archive log
     parameter in question.
This means you have an error in the log_archive_dest entries on the standby server.
Can you use Dataguard Manager (dgmgrl) to verify the configuration?
Edit:
Our Dataguard config e.g. has on primary:
log_archive_config='dg_config=(STDBY)'
On the standby it is:
log_archive_config='dg_config=(PRIMARY)'

Creation of logical standby by shipping the redologs from physical standby

Hi all,
I have to create a logical standby database using redo shipping from my PHYSICAL STANDBY while it is in mounted state .Is it really possible to do it??
Please send me any docs regarding this to my mail id ([email protected])
Thanx in advance

It is possible to do what you ask by using cascaded destinations. See the Data Guard Manual (online at OTN) http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14239/cascade_appx.htm#i636046
for the information. This relies on the standby creating and re-transmitting redo log data.
Hope this helps

Goldengate from physical standby with Active data guard or from logical standby - which is better?

Hi,
We have Oracle 11.2.0.4 and are currently using Active Data Guard on a physical standby. My boss wants me to use Goldengate
to replicate several schema from Oracle to SqlSserver. She doesn't want to touch the Primary, which is in production. Would it be better
to setup a Logical standby for Goldendate to use, in addition to the Physical standby? Or will it be sufficient to use the Physical standby?
The application tables don't all have primary keys. I'm trying to decide if the Logical standby adds another layer of complexity or would
introduce delays in getting the data from Oracle to Sqlserver.
Thanks in advance,

Hi,
In this case I recommend you to use physical standby + Golden gate with ALO mode. You might have sligthly more trouble in logical standby. it means you might have more trouble at Goldengate's extract side.
You said
The application tables don't all have primary keys.
so you have to add keycols on replicat side.
I recommend you to add an index which should consist of keycols columns. it will be necessary for replicat performance.
Best Regards

Restore - filename for datafile is missing in the control file

I am practicing RMAN recovery procedures and I encountered a problem that I do not know how to solve.
1) I took a hot backup of my test database.
2) Create tablespace TS_DATA_TEMP
3) Deleted tablespace TS_DATA which had 2 datafiles
4) Created tablespace TS_DATA with 1 datafile
5) shutdown database
6) logged into RMAN in nomount
7) restore controlfile from autobackup;
8) alter database mount;
9) restore database;
RMAN> restore database;
Starting restore at 22-AUG-08
using channel ORA_DISK_1
the filename for datafile 5 is missing in the control file
skipping datafile 1; already restored to file /u02/oradata/EDM91/system01.dbf
skipping datafile 2; already restored to file /u02/oradata/EDM91/undotbs01.dbf
skipping datafile 6; already restored to file /u02/oradata/EDM91/index
skipping datafile 3; already restored to file /u02/oradata/EDM91/sysaux01.dbf
skipping datafile 7; already restored to file /u03/oradata/EDM91/TS_INDEX01.dbf
skipping datafile 9; already restored to file /u03/oradata/EDM91/TS_LOB01.dbf
skipping datafile 4; already restored to file /u02/oradata/EDM91/users01.dbf
restore not done; all files readonly, offline, or already restored
Finished restore at 22-AUG-08
10) tried to recover
Starting recover at 22-AUG-08
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/22/2008 15:04:22
RMAN-06094: datafile 5 must be restored
SQL> select name from v$datafile where file#=5;
NAME
/u04/oradata/EDM91/TS_DATA.dbf
12) alter database backup controlfile to trace
DATAFILE
'/u02/oradata/EDM91/system01.dbf',
'/u02/oradata/EDM91/undotbs01.dbf',
'/u02/oradata/EDM91/sysaux01.dbf',
'/u02/oradata/EDM91/users01.dbf',
'/u04/oradata/EDM91/TS_DATA.dbf',
'/u02/oradata/EDM91/index',
'/u03/oradata/EDM91/TS_INDEX01.dbf',
'/u04/oradata/EDM91/TS_DATA02.dbf',
'/u03/oradata/EDM91/TS_LOB01.dbf'
CHARACTER SET UTF8
So i'm not sure what the problem is. Datafile TS_DATA.dbf is located in the control file but i'm getting the error: the filename for datafile 5 is missing in the control file.
Suggestions on what's wrong with the control file?

I found my mistake; a newbie error.
I did not know I needed to include in my restore command the 'until' option when doing incomplete recovery. I only included the 'until' option in the recover command:
original command
restore database;
recover database until sequence =123;
should be
restore database until sequence = 123;
recover database until sequence =123;
I usually run the command using a RUN block with a SET UNTIL SEQUENCE but this case I used the single commands separately.
RUN
+{+
SET UNTIL sequence 123;
RESTORE DATABASE;
RECOVER DATABASE;
+}+

How to automate the purging of archivelogs on primary when backing up from physical standby?

Hi,
When configuring archivelog backups to run from my Active Standby database (11.2.0.3) I am running into an issue where the archivelogs on the primary database are not getting purged. This is resulting in the archiver hanging on the primary.
run {
allocate channel ch1 type 'sbt_tape'
TRACE 0;
setlimit channel ch1 maxopenfiles 8;
backup
filesperset = 32
(archivelog all   delete input );
backup current controlfile spfile ;
My archivelog deletion policy is set as follows on both the primary and standby
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
When I run REPORT OBSOLETE from RMAN however, the primary database seems to have outdated information in it.
I have also observed the following in the RMAN backup log:
RMAN-08120: WARNING: archived log not deleted, not yet applied by standby.
Do I need to perform additional configuration to automate the purging of archivelogs on the primary database or is there an issue with the backup options and / or deletion policy specified?
Many thanks,
Gary Allen
DBA

The primary and standby databases are in sync and have been for over a week now.
Primary:
SQL> select max(sequence#), applied from v$archived_log group by applied;
MAX(SEQUENCE#) APPLIED
           268 NO
           267 YES
Standby:
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
           268
For some reason though, the primary controlfile is not being updated properly and when I run the RMAN REPORT OBSOLETE command the data is nearly a week old yet on the standby the same command retrieves up to date information:
Primary:
RMAN> report obsolete
Backup Set           136    06-AUG-13
Backup Piece       136    06-AUG-13          48ogk9ik_1_1
Backup Set           138    06-AUG-13
Backup Piece       138    06-AUG-13          4aogkqbm_1_1
Backup Set           142    06-AUG-13
Backup Piece       142    06-AUG-13          4eogl5i6_1_1
Backup Set           144    07-AUG-13
Backup Piece       144    07-AUG-13          4gogmc0a_1_1
RMAN> report obsolete
Standby:
Backup Set           156    13-AUG-13
Backup Piece       156    13-AUG-13          4uoh65o7_1_1
Backup Set           159    13-AUG-13
Backup Piece       159    13-AUG-13          51oh6d0r_1_1
Backup Set           162    13-AUG-13
Backup Piece       162    13-AUG-13          54oh6n8a_1_1
Backup Set           165    13-AUG-13
Backup Piece       165    13-AUG-13          57oh78qr_1_1

Db_file parameter change in oracle 8i with physical standby configured

i have oracle 8i (8.1.7) with physical standby configured.
i need to change the db_file parameter value. kindly check the below steps are correct? Thanks.
1. alter database backup controlfile to trace;
2. edit the init.ora file as db_file=<new value> (after backing up the existing pfile)
3. edit the create control file statement in udump -- max datafile (and also remove the first line startup nomount)
4. shutdown immediate;
5. startup pfile ='file name';
6. in sqlplus run the create control file statement;
7. alter database backup controfl file for standby;
8. move the standby control file to standby db server
9. shutdown immediate in standby
10. copy the pfile and edit the new values
11. startup mount pfile='new pfile' (in standby)
12. recover control file <location> from rman
13. start the recovering of standby.
Thanks,
Raman.

Just change the db_files value to some higher value in the init.ora file and restart the database. With this you can create more datafiles no need to create control file.

Implementation of ORACLE9i RMAN physical standby database`

Sir's,
How to implement RMAN in the physical standby database

Hi Ashu Goel,
Can u let me know any thing abot the prerequistw of implementation with the configuration settings of the above said.If I understand you correctly you want to use rman to backup an already existing dataguard setup.
Doing this would be very similar as a normal rman backup with the limitation you have to stop the recovery during the backup window and run the backup in mount mode.
To make a consistent backup of the standby database, make sure that the last shutdown of the standby database was clean and that it was not placed in recovery mode after that time, and then mount the control file. For example:
sqlplus SYS/oracle@sbdb1 <<EOF
SHUTDOWN IMMEDIATE
STARTUP NOMMOUNT PFILE=initSTANDBY.ora
ALTER DATABASE MOUNT STANDBY DATABASE;
EOF
You can back up the standby database when it is in any other mode, but the backups will be inconsistent.
Start RMAN and connect to the standby database with the TARGET keyword (not the AUXILIARY keyword) and the recovery catalog database. You must be connected to the recovery catalog. For example, enter:
% rman TARGET SYS/oracle@sbdb1 CATALOG rman/cat@catdb
If do not have automatic channels configured, then manually allocate one or more channels of type DISK or sbt. Note that you are connected to the standby host, so the backups are made by server sessions on the standby (not the primary) host.
This example backs up all the standby datafiles as well as the control file and archived logs by using automatic channels:
BACKUP DATABASE PLUS ARCHIVELOG;
Regards,
Tycho

ORA-03264: cannot drop offline datafile of locally managed tablespace

Hi list
A datafile was acidentally created on filesystem in one node of two nodes RAC.
After that the filesystem on which the datafile was created was out of space because of automatic control file backup and sysadmin move this datafile to another device. And before this action RMAN backup stopped work.
Now we replace the datafile to the original location, but it stay offline and recover status, and we cant bring them online because the customer dont have necessary archive logs to recover this datafile. RMAN backup is now working. But now we need to create a DataGuard on a third server and want to drop this datafile.
This datafile dont have any data segment and stay in most critical tablespace of the customer application which have more datafiles. This datafile in question isnt the first datafile of the tablespace.
SQL> select file#, status from v$datafile where name='/oracle/product/db/ars/dbs/arsystem.old';
FILE# STATUS
21 RECOVER
SQL> select file#, status from v$datafile_header where name='/oracle/product/db/ars/dbs/arsystem.old';
FILE# STATUS
21 OFFLINE
How can I drop this datafile?
Thanks
Cristiano

Review this metalink note, what to do:
How to 'DROP' a Datafile from a Tablespace
Doc ID:111316.1
If you cannot recover the datafile, you have to export the 'rest' of the tablespace (after statement 'alter database datafile '/oracle/product/db/ars/dbs/arsystem.old' offline drop;' was successfully issued). Afterwards drop the tablespace,recreate it and import the data).
Werner

How to move a specific tablespace datafile from one directory to another

Database: 10.2.0.1
OS : Generic
Problem Description : How to move a specific tablespace datafile from one directory to another considering that the database is on Oracle Dataguard setup
** Oracle is working on this issue, but in parallel is opening the topic to the Community so that Community members can add their perspective, experience or knowledge. This will further enhance all knowledge bases including My Oracle Support and My Oracle Support Communities **
Edited by: ram_orcl on 16-Aug-2010 21:21

Dear ram_orcl,
Please follow the procedures here;
http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ps.htm#i1034172
8.3.4 Renaming a Datafile in the Primary Database
When you rename one or more datafiles in the primary database, the change is not propagated to the standby database. Therefore, if you want to rename the same datafiles on the standby database, you must manually make the equivalent modifications on the standby database because the modifications are not performed automatically, even if the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO.
The following steps describe how to rename a datafile in the primary database and manually propagate the changes to the standby database.
   1.
      To rename the datafile in the primary database, take the tablespace offline:
      SQL> ALTER TABLESPACE tbs_4 OFFLINE;
   2.
      Exit from the SQL prompt and issue an operating system command, such as the following UNIX mv command, to rename the datafile on the primary system:
      % mv /disk1/oracle/oradata/payroll/tbs_4.dbf
      /disk1/oracle/oradata/payroll/tbs_x.dbf
   3.
      Rename the datafile in the primary database and bring the tablespace back online:
      SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE      2> '/disk1/oracle/oradata/payroll/tbs_4.dbf'
        3> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
      SQL> ALTER TABLESPACE tbs_4 ONLINE;
   4.
      Connect to the standby database, query the V$ARCHIVED_LOG view to verify all of the archived redo log files are applied, and then stop Redo Apply:
      SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
      SEQUENCE# APP
      8 YES
      9 YES
      10 YES
      11 YES
      4 rows selected.
      SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
   5.
      Shut down the standby database:
      SQL> SHUTDOWN;
   6.
      Rename the datafile at the standby site using an operating system command, such as the UNIX mv command:
      % mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
   7.
      Start and mount the standby database:
      SQL> STARTUP MOUNT;
   8.
      Rename the datafile in the standby control file. Note that the STANDBY_FILE_MANAGEMENT initialization parameter must be set to MANUAL.
      SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf'
        2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
   9.
      On the standby database, restart Redo Apply:
      SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
        2> DISCONNECT FROM SESSION;
If you do not rename the corresponding datafile at the standby system, and then try to refresh the standby database control file, the standby database will attempt to use the renamed datafile, but it will not find it. Consequently, you will see error messages similar to the following in the alert log:
ORA-00283: recovery session canceled due to errors
ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file
ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'Hope That Helps.
Ogan

Drop a datafile from physical standby's control file

Similar Messages

Maybe you are looking for