Standby Database Datafile Move

Hi All
Oracle v10g (10.2.0.4)
Windows 2003
I need to move some datafiles onto a larger volume on our primary database. I have no issue with this task, except for some uncertainty on what to do with the Standby database?
Our Standby database (on the other side of the atlantic) has the exact same drive/file layout as the primary. I have a larger volume ready for the move on the Standby.
We have standby_file_management set to auto.
I assume that the data dictionary/control file information (datafile locations) will be updated via the logs being shipped? I assume I would need to manually move the files on the standby database?
Has anyone practiced this recently? could you give me a little guidance.
Much appreciated.

user3655049 wrote:
Hi All
Oracle v10g (10.2.0.4)
Windows 2003
I need to move some datafiles onto a larger volume on our primary database. I have no issue with this task, except for some uncertainty on what to do with the Standby database?
Our Standby database (on the other side of the atlantic) has the exact same drive/file layout as the primary. I have a larger volume ready for the move on the Standby.
We have standby_file_management set to auto.
I assume that the data dictionary/control file information (datafile locations) will be updated via the logs being shipped? I assume I would need to manually move the files on the standby database?
Has anyone practiced this recently? could you give me a little guidance.
Much appreciated.You no need to modify datafile locations on standby. structure can be different from primary and standby. Even primary can be ASM and standby can be non-ASM.
So no need to worry. But after changing the files location, you have to update DB_FILE_NAME_CONVERT parameter on databases.
Some more information to you, check this http://docs.oracle.com/cd/E11882_01/server.112/e17022/manage_ps.htm#i1034172
>
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.
>
Edited by: CKPT on Jan 17, 2013 9:02 PM

Similar Messages

Standby Database Datafiles

Question: I have a primary and standby database. Right now all the datafiles on both primary and standby are in the same location, unfortunately space can only be added to my primary database. My question is, can you still maintain a standby database if the physical location of the datafiles are not on the same mount point? i.e.:
Primary datafile: /u01/app/oracle/user_data01.dbf --> Standby datafile: /u03/app/oracle/user_data01.dbf
I know I have to turn standby file management to MANUAL to make such a change but can I turn it back to AUTO once I have completed moving this file? Thanks guys

"Can I?" ... and "should I?" are very different questions.
Let's approach this from the standpoint of why have a standby? If the point is high availability the value in your standby, based on sharing the same location as the primary, is a small number rapidly approaching zero.
The point of a standby is that you eliminate single points of failure ... you haven't.
The point of a standby is that it is a 100% duplicate, in every sense, of your primary database environment ... it isn't.
My recommendation would be to go to management with a proposal based on a cold dispassionate technical evaluation, and the cost per minute of an outage to the business, and tell them they MUST purchase the hardware required.

Standby database datafile corruption.

Hi:
I am getting the following errors on my standby db. Could u please tell me how to handle the situation. I am skeptical to try out any thing as this might end up in datafile corruption. Please advice..
MRP0: Background Media Recovery terminated with error 1237
Fri Nov 30 09:15:25 2007
Errors in file /u01/prod/oraprod/proddb/9.2.0/admin/PROD_hunter/bdump/prod2_mrp0_19630.trc:
ORA-01237: cannot extend datafile 392
ORA-01110: data file 392: '/u03/prod/oraprod/proddata/a_txn_data01.dbf'
ORA-19502: write error on file "/u03/prod/oraprod/proddata/a_txn_data01.dbf", blockno 424577 (blocksize=8192)
ORA-27072: skgfdisp: I/O error
Linux Error: 4: Interrupted system call
Additional information: 424576
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
MRP0: Background Media Recovery process shutdown
---------------------------------------------------------------------------------------------------------------------

Check this error,
ORA-01237: cannot extend datafile string
Cause: An operating system error occurred during the resize.
Action: Fix the cause of the operating system error and retry the command.
Is there any DDL statement in your primary to resize datafile ? Do you have enough space on standby server?

Creating Standby Database / Steps might be missing..

I have created standby database..
The archives are copied except one archived log and those copied archived are not applied at Standby database.
Besides this issue, I just checked the alert log file and pasting its contents here.
Do check it and let me know If I m missing any paramter[s].
Dump file c:\oracle\product\10.2.0\admin\rockstd\bdump\alert_rockstd.log
Mon May 12 15:23:42 2008
ORACLE V10.2.0.1.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows XP Version V5.1 Service Pack 2
CPU : 2 - type 586
Process Affinity : 0x00000000
Memory (Avail/Total): Ph:1194M/2038M, Ph+PgF:1368M/2641M, VA:1940M/2047M
Mon May 12 15:23:42 2008
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
System parameters with non-default values:
processes = 150
sga_target = 167772160
control_files = C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\ROCKSTD.CTL
db_block_size = 8192
compatible = 10.2.0.1.0
log_archive_dest_1 = location=C:\oracle\product\10.2.0\oradata\rockstd\Archive_rock
log_archive_dest_state_1 = ENABLE
log_archive_format = arc_%s_%t_%r.arc
fal_client = ROCKSTD
fal_server = ROCK
db_file_multiblock_read_count= 16
db_recovery_file_dest = C:\oracle\product\10.2.0\flash_recovery_area\rockstd
db_recovery_file_dest_size= 2147483648
undo_management = AUTO
undo_tablespace = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain =
dispatchers = (PROTOCOL=TCP) (SERVICE=rockXDB)
job_queue_processes = 10
audit_file_dest = C:\ORACLE\PRODUCT\10.2.0\ADMIN\ROCKSTD\ADUMP
background_dump_dest = C:\ORACLE\PRODUCT\10.2.0\ADMIN\ROCKSTD\BDUMP
user_dump_dest = C:\ORACLE\PRODUCT\10.2.0\ADMIN\ROCKSTD\UDUMP
core_dump_dest = C:\ORACLE\PRODUCT\10.2.0\ADMIN\ROCKSTD\CDUMP
db_name = rock
db_unique_name = rockstd
open_cursors = 300
pga_aggregate_target = 16777216
PMON started with pid=2, OS id=3656
PSP0 started with pid=3, OS id=504
MMAN started with pid=4, OS id=2544
DBW0 started with pid=5, OS id=3652
LGWR started with pid=6, OS id=552
CKPT started with pid=7, OS id=2688
SMON started with pid=8, OS id=3436
RECO started with pid=9, OS id=3696
CJQ0 started with pid=10, OS id=1636
MMON started with pid=11, OS id=2072
MMNL started with pid=12, OS id=3812
Mon May 12 15:23:43 2008
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
Mon May 12 15:24:06 2008
alter database mount standby database
Mon May 12 15:24:11 2008
Setting recovery target incarnation to 14
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=16, OS id=3536
Mon May 12 15:24:11 2008
ARC0: Archival started
ARC1 started with pid=17, OS id=4084
Mon May 12 15:24:12 2008
ARC1: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
Mon May 12 15:24:12 2008
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC1: Thread not mounted
Mon May 12 15:24:12 2008
Successful mount of redo thread 1, with mount id 3275426006
Mon May 12 15:24:12 2008
Physical Standby Database mounted.
Mon May 12 15:24:13 2008
ARC0: Becoming the heartbeat ARCH
Completed: alter database mount standby database
Mon May 12 15:25:02 2008
Using STANDBY_ARCHIVE_DEST parameter default value as C:\oracle\product\10.2.0\oradata\rockstd\Archive_rock
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 3444
RFS[1]: Identified database type as 'physical standby'
Mon May 12 15:25:02 2008
RFS LogMiner: Client disabled from further notification
Mon May 12 15:25:21 2008
db_recovery_file_dest_size of 2048 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Mon May 12 15:26:19 2008
alter database add standby logfile 'C:\oracle\product\10.2.0\oradata\rockstd\redo04.log' size 50m
Mon May 12 15:26:20 2008
Completed: alter database add standby logfile 'C:\oracle\product\10.2.0\oradata\rockstd\redo04.log' size 50m
Mon May 12 15:26:27 2008
alter database add standby logfile 'C:\oracle\product\10.2.0\oradata\rockstd\redo05.log' size 50m
Completed: alter database add standby logfile 'C:\oracle\product\10.2.0\oradata\rockstd\redo05.log' size 50m
Mon May 12 15:26:33 2008
alter database add standby logfile 'C:\oracle\product\10.2.0\oradata\rockstd\redo06.log' size 50m
Mon May 12 15:26:34 2008
Completed: alter database add standby logfile 'C:\oracle\product\10.2.0\oradata\rockstd\redo06.log' size 50m
Mon May 12 15:27:20 2008
alter database recover managed standby database disconnect from session
MRP0 started with pid=19, OS id=596
Managed Standby Recovery not using Real Time Apply
Mon May 12 15:27:26 2008
Errors in file c:\oracle\product\10.2.0\admin\rockstd\bdump\rockstd_dbw0_3652.trc:
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCK\SYSTEM01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.
Mon May 12 15:27:26 2008
Errors in file c:\oracle\product\10.2.0\admin\rockstd\bdump\rockstd_dbw0_3652.trc:
ORA-01157: cannot identify/lock data file 2 - see DBWR trace file
ORA-01110: data file 2: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCK\UNDOTBS01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.
Mon May 12 15:27:26 2008
Errors in file c:\oracle\product\10.2.0\admin\rockstd\bdump\rockstd_dbw0_3652.trc:
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCK\SYSAUX01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.
Mon May 12 15:27:26 2008
Errors in file c:\oracle\product\10.2.0\admin\rockstd\bdump\rockstd_dbw0_3652.trc:
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCK\TESTING1.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.
Mon May 12 15:27:26 2008
Errors in file c:\oracle\product\10.2.0\admin\rockstd\bdump\rockstd_dbw0_3652.trc:
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCK\SYSTEM03.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.
Mon May 12 15:27:26 2008
Errors in file c:\oracle\product\10.2.0\admin\rockstd\bdump\rockstd_dbw0_3652.trc:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCK\ABAMCO_TEST01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.
MRP0: Background Media Recovery terminated with error 1110
Mon May 12 15:27:26 2008
Errors in file c:\oracle\product\10.2.0\admin\rockstd\bdump\rockstd_mrp0_596.trc:
ORA-01110: data file 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCK\SYSTEM01.DBF'
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCK\SYSTEM01.DBF'
Mon May 12 15:27:26 2008
Errors in file c:\oracle\product\10.2.0\admin\rockstd\bdump\rockstd_mrp0_596.trc:
ORA-01110: data file 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCK\SYSTEM01.DBF'
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCK\SYSTEM01.DBF'
Mon May 12 15:27:27 2008
Completed: alter database recover managed standby database disconnect from session
Mon May 12 15:30:18 2008
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 2456
RFS[2]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO04.LOG'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO04.LOG'
Mon May 12 15:30:22 2008
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 3124
RFS[3]: Identified database type as 'physical standby'
RFS[3]: Successfully opened standby log 5: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO05.LOG'
Mon May 12 15:53:45 2008
RFS[3]: Successfully opened standby log 5: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO05.LOG'
Mon May 12 15:53:46 2008
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO04.LOG'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO04.LOG'
Mon May 12 15:53:58 2008
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO04.LOG'
Mon May 12 16:00:06 2008
RFS[3]: Successfully opened standby log 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO04.LOG'
Mon May 12 16:00:09 2008
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO04.LOG'
Mon May 12 16:00:14 2008
RFS[3]: Successfully opened standby log 5: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO05.LOG'
Mon May 12 16:00:18 2008
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO04.LOG'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROCKSTD\REDO04.LOG'
Regards,
Rakesh Soni.

Done, I've given the same path in Standby Database [datafiles, controlfiles] as it has been given in the Primary Database.
MoreOver, I m manually switching logfiles at primary database [alter system switch logfile] they are copied and applied sucessfully at standby database. But the archived files that I have copied with cold backup are not applied yet. Infact they are not retrieved executing the below query.
select name, applied from v$archived_log;
How can I apply those archived logs? [archives that copied with cold backup]
Regards.

Move datafile on Primary not replicted on Standby Database

I'm using an automated script to move datafiles between partitions on my standby database, this ensures that only recent data is on the faster fibre channel disks, and older data is on SATA disks.
The commands it uses:
1. alter tablepspace offline;
2. unix command to mv data file from one partition to another.
3. alter tablepspace <tbname> rename datafile ' old datafile path' to 'new datafile path';
4. alter tablepspace online;
This works fine on the primary database, but the standby is not moving the datafiles.
Any help as to why this is happening would be much appreciated.
Thanks.

And why would it be replicated? If there already is the same file on the standby, redo entries can be applied to it. Renaming of data files is
not an operation that would be visible in redo logs, it is visible only in the control file(s). Standy databases apply redo logs from the primary
database, period. That is all they do. If the change is not visible in the redo logs, it isn't applied to standby. If a file is created, dropped or
changed in size, that is communicated to the standby which reacts appropriately if the STANDBY_FILE_MANAGEMENT parameter is set to AUTO on the standby side. Redo entry contains the following information:
<ol><li>     SCN for the change.</li>
<li>     The file number to which the change was made</li>
<li>The block number of the changed block.</li>
<li>     The offset and the size of the changed information.</li>
<li>     The changed information itself.</li>
</ol>
When the standby receives the archived log file and parses that information, it applies the information to the corresponding file on
the standby side, regardless of the file name. If the file 123 exists and contains the block 9876543210, redo entry will be applied
and all will be well. There is absolutely no way by which the standby database would be able to discern the new file name. There is
absolutely no need for that. To change the file name on the standby side, do the following on the standby side:
<ol><li>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;</li>
<li>ALTER DATABASE DATAFILE 123 OFFLINE;</li>
<li>ALTER DATABASE RENAME FILE 123 TO '/my/db/path/new_file.dbf';</li>
<li>ALTER DATABASE DATAFILE 123 ONLINE;</li>
<li>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;</li>
</ol>

Relocating datafiles on standby database after mount point on stanby is ful

Hi,
We have a physical standby database.
The location of datafiles on primary database are at /oracle/oradata/ and the location of datafiles on standby database are at /oracle/oradata/
Now we are facing a situation of mount mount getting full on standby database so we need to move some tablespaces to another location on standby.
Say old location is /oracle/oradata/ and new location is /oradata_new/ and the tablespaces to be relocated are say tab1 and tab2.
Can anybody tell me whether following steps are correct.
1. Stop managed recovery on standby database
alter database recover managed standby database cancel;
2. Shutdown standby database
shutdown immediate;
3. Open standby database in mount stage
startup mount;
4. Copy the datafiles to new location say /oradata_new/ using os level command
4. Rename the datafile
alter database rename file
'/oracle/oradata/tab1.123451.dbf', '/oracle/oradata/tab1.123452.dbf','/oracle/oradata/tab2.123451.dbf',''/oracle/oradata/tab2.123452.dbf'
to '/oradata_new/tab1.123451.dbf', '/oradata_new/tab1.123452.dbf','/oradata_new/tab2.123451.dbf',''/oradata_new/tab2.123452.dbf';
5. Edit the parameter db_file_name_convert
alter system set db_file_name_convert='/oracle/oradata/tab1','/oradata_new/tab1','/oracle/oradata/tab2','/oradata_new/tab2'
6. Start a managed recovery on standby database
alter database recover managed standby database disconnect from session;
I am littelbit confused in step 5 as we want to relocate only two tablespaces and not all tablespaces so we have used.
Can we use db_file_name_convert like this i.e. does this work for only two tablespaces tab1 and tab2.
Thanks & Regards
GirishA

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ps.htm#i1010428
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.
To rename the datafile in the primary database, take the tablespace offline:
SQL> ALTER TABLESPACE tbs_4 OFFLINE;
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
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;
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;
Shut down the standby database:
SQL> SHUTDOWN;
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
Start and mount the standby database:
SQL> STARTUP MOUNT;
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';
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'

Restoring and recovering datafiles in standby database

Hi,
oracle version : 8i(8.1.7.0.0)
os : sun solaris
I have scenerio where i lost some of the datafiles in standby database(physical standby) and i do have standby cold backup 3 months older since database size is 1TB is can i restore the the only lost files from cold backup and recover using archivelog files. since i only lost 4 data files of size 4gb each it will be faster compare to restoring the whole TB size database.
appreciated for valuable inputs.
Thanks
Prakash GR

Normal copy command can do your work:
sys@SANTU> startup
ORACLE instance started.
Total System Global Area 535662592 bytes
Fixed Size                  1334380 bytes
Variable Size             180355988 bytes
Database Buffers          348127232 bytes
Redo Buffers                5844992 bytes
Database mounted.
Database opened.
sys@SANTU> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     4
Next log sequence to archive   6
Current log sequence           6
sys@SANTU> host copy D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF d:\
        1 file(s) copied.
sys@SANTU> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
*Renamed the datafile 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF' to 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS011.DBF'*
sys@SANTU> startup
ORACLE instance started.
Total System Global Area 535662592 bytes
Fixed Size                  1334380 bytes
Variable Size             180355988 bytes
Database Buffers          348127232 bytes
Redo Buffers                5844992 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF'
sys@SANTU> host move d:\USERS01.DBF D:\APP\SANTOSKU\ORADATA\SANTU\
sys@SANTU> shu immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
sys@SANTU> startup
ORACLE instance started.
Total System Global Area 535662592 bytes
Fixed Size                  1334380 bytes
Variable Size             180355988 bytes
Database Buffers          348127232 bytes
Redo Buffers                5844992 bytes
Database mounted.
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF'
sys@SANTU> recover datafile 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF';
Media recovery complete.
sys@SANTU> alter database open;
Database altered.
sys@SANTU>N.B. I have not done the demo on standby database.
but just i want to know is this procedure is valid that is instead of taking the lost datafiles from production can i use lost datafiles from standby database to recover other standby database.That would be fine.
Regards,
S.K.
Edited by: Santosh Kumar on Oct 8, 2009 11:09 AM

Datafile issues in manual standby database

Hi all,
oracle - 10gR2
OS - RHEL 2.6
We have primary and standby database setup using manual methods('rsync') to send archive logs from primary to standby database and they are applied there. Today I have created a new datafile in primary and seen that the same is not replicated in standby( i was not aware of the functionality of this kind of setup) later I have seen that "standby_file_management parameter is set to MANUAL".
I have seen the following message in standby alert log(not disabled the archive log application script in satndby),
"Media Recovery Log /u01/app/oracle/oradata/bmprod/archivelog/1_1761_703415336.arc
File #6 added to control file as 'UNNAMED00006' because
the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
The file should be manually created to continue.
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail"
Later I have copied the required file from primary to standby database(now I have disabled the archive log application script in standby), and renamed the datafile 'UNNAMED00006' to 'desired one' and restarted the archive log application script. I have seen the following messages,
"ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 6 needs more recovery to be consistent
ORA-01110: data file 6: '/u02/app/oracle/oradata/bmprod/BMTEST.dbf'"
Now I am unable to figure out what I should do to come out of this situation. Atleast tell me this condition is not worse than I thought(I think that the standby database should be recreated).
Any help is appreciated.......
regards
Edited by: techfeud on Jan 18, 2010 11:26 PM

Hi,
when you set the standby_file_management parameter as mannual then , if you create any datafile or adding it to the tablespace then you should mannaully run the command on the standby side , if its auto then auto matically it will create the file over in the respective locationa and with the name what you have used to create the datafile on the primary side,
as the parameter value is mannual ypu need to create the datafile over the standby side and then performt the recovery,
Farhan.

Add Datafile in Logical Standby Database

Hi,
I have add one datafile in our primary RAC DB. We had logical standby database with file management is equal to manual. Both the primary RAC and logical standby db have the different storage structure. When the archive applied on the logical standby database its throws the error " error in creating datafile 'path'";
Would appreciate if come to know the steps to add the datafile in this kind of environment. and how can i overcome from this problem now except skip transaction for that ddl.
Thanks in advance.
Dewan

When the archive applied on the logical standby database its throws the error " error in creating datafile 'path'";Can you post the error message with the number.
From Manual..
8.3.1.2 Adding a Tablespace and a Datafile When STANDBY_FILE_MANAGEMENT Is Set to MANUAL
The following example shows the steps required to add a new datafile to the primary and standby database when the STANDBY_FILE_MANAGEMENT initialization parameter is set to MANUAL. You must set the STANDBY_FILE_MANAGEMENT initialization parameter to MANUAL when the standby datafiles reside on raw devices.
Add a new tablespace to the primary database:
SQL> CREATE TABLESPACE new_ts DATAFILE '/disk1/oracle/oradata/payroll/t_db2.dbf'
2> SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED;
Verify the new datafile was added to the primary database:
SQL> SELECT NAME FROM V$DATAFILE;
NAME
/disk1/oracle/oradata/payroll/t_db1.dbf
/disk1/oracle/oradata/payroll/t_db2.dbf
Perform the following steps to copy the tablespace to a remote standby location:
Place the new tablespace offline:
SQL> ALTER TABLESPACE new_ts OFFLINE;
Copy the new tablespace to a local temporary location using an operating system utility copy command. Copying the files to a temporary location will reduce the amount of time the tablespace must remain offline. The following example copies the tablespace using the UNIX cp command:
% cp /disk1/oracle/oradata/payroll/t_db2.dbf
/disk1/oracle/oradata/payroll/s2t_db2.dbf
Place the new tablespace back online:
SQL> ALTER TABLESPACE new_ts ONLINE;
Copy the local copy of the tablespace to a remote standby location using an operating system utility command. The following example uses the UNIX rcp command:
%rcp /disk1/oracle/oradata/payroll/s2t_db2.dbf standby_location
Archive the current online redo log file on the primary database so it will get transmitted to the standby database:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Use the following query to make sure that Redo Apply is running. If the MRP or MRP0 process is returned, Redo Apply is being performed.
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
Verify the datafile was added to the standby database after the archived redo log file was applied to the standby database:
SQL> SELECT NAME FROM V$DATAFILE;
NAME
/disk1/oracle/oradata/payroll/s2t_db1.dbf
/disk1/oracle/oradata/payroll/s2t_db2.dbf

Datafile corrupted On standby database

one of the datafile got corrupted in the standby database . when backing up with rman i got ora-15966 error .
i found the corrupted datafile but i did not have any backups to recover .
is there any way to recover the block corruption ?

Hello,
What's your Oracle version? OS? following link shows how to fix it , you can search oracle documentation according to your version.
http://www.mpi-inf.mpg.de/departments/d5/teaching/ss05/is05/oracle/server.920/a96521/repair.htm#11355
Regards

Add a new datafile to the standby database

Hi,
i have a standby database in recovery managed mode.
Now i must add a new datafile on the production database and i would like
to know how i realized adding the new datafile on the stanby database.
is it right when i do the follow steps?
Before i add a datafile to the primary database,
cancel the recovery on the standby database.
-> add the new datafile on the primary database
after all archived redo logs have been applied, cancel managed recovery:
alter database recover managed standby database cancel;
startup nomount
alter database mount standby database;than
ALTER DATABASE CREATE DATAFILE '/oracle/DB1/db1_9/data9' as '/oracle/DB1/db1_9/data9';
alter database recover managed standby database disconnect;Thanks

8.4.1.1 Adding a Tablespace and a Datafile When STANDBY_FILE_MANAGEMENT Is Set to AUTO
The following example shows the steps required to add a new datafile to the primary and standby databases when the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO.
Add a new tablespace to the primary database:
SQL> CREATE TABLESPACE new_ts DATAFILE 't_db2.dbf'
2> SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED;
Archive the current redo log so it will get copied to the standby database:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Verify that the new datafile was added to the primary database:
SQL> SELECT NAME FROM V$DATAFILE;
NAME
/disk1/oracle/dbs/t_db1.dbf
/disk1/oracle/dbs/t_db2.dbf
Verify that the new datafile was added to the standby database:
SQL> SELECT NAME FROM V$DATAFILE;
NAME
/disk1/oracle/dbs/s2t_db1.dbf
/disk1/oracle/dbs/s2t_db2.dbf
8.4.1.2 Adding a Tablespace and a Datafile When STANDBY_FILE_MANAGEMENT Is Set to MANUAL
The following example shows the steps required to add a new datafile to the primary and standby database when the STANDBY_FILE_MANAGEMENT initialization parameter is set to MANUAL. You must set the STANDBY_FILE_MANAGEMENT initialization parameter to MANUAL when the standby datafiles reside on raw devices.
Add a new tablespace to the primary database:
SQL> CREATE TABLESPACE new_ts DATAFILE 't_db2.dbf'
2> SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED;
Verify that the new datafile was added to the primary database:
SQL> SELECT NAME FROM V$DATAFILE;
NAME
/disk1/oracle/dbs/t_db1.dbf
/disk1/oracle/dbs/t_db2.dbf
Perform the following steps to copy the tablespace to a remote standby location:
Place the new tablespace offline:
SQL> ALTER TABLESPACE new_ts OFFLINE;
Copy the new tablespace to a local temporary location using an operating system utility copy command. Copying the files to a temporary location will reduce the amount of time that the tablespace must remain offline. The following example copies the tablespace using the UNIX cp command:
% cp t_db2.dbf s2t_db2.dbf
Place the new tablespace back online:
SQL> ALTER TABLESPACE new_ts ONLINE;
Copy the local copy of the tablespace to a remote standby location using an operating system utility command. The following example uses the UNIX rcp command:
%rcp s2t_db2.dbf standby_location
Archive the current redo log on the primary database so it will get copied to the standby database:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Use the following query to make sure that managed recovery is running. If the MRP or MRP0 process is returned, managed recovery is being performed.
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
Verify that the datafile was added to the standby database after the redo log was applied to the standby database.
SQL> SELECT NAME FROM V$DATAFILE;
NAME
/disk1/oracle/dbs/s2t_db1.dbf
/disk1/oracle/dbs/s2t_db2.dbf
From Oracle Docs...

Add new datafile to logical standby database but not in primary

Hi,
Is it ok to add a new datafile to the SYSAUX tablespace on the logical standby database but not on primary? We are running out of disk space on the partition where SYSAUX01.dbf resides so we want to add a new SYSAUX02.dbf in another partition which has space. but this will only be on the logical standby not on primary, there is still lots of space in primary. standby_file_management is MANUAL and this is LOGICAL STANDBY not PHYSICAL.
Is this possible or where there be any issues?
Thanks.

Logical Standby can differ from Primary, it can have extra tablespaces, datafiles, tables, indexes, users ...
HTH
Enrique

How to add datafile to standby database

Hi,
We have standby database on another site and we are using manual recovery. How to add datafile to standby database after datafile is added to primary database.
We are on Oracle 9i R2.
Please help.
Thanks in advance

Hi,
When you recover the standby database after you added a datafile to the production, you will get an error that the file that needs recovery does not exist.
At this point you can connect to the standby and issue:
alter database create datafile '<original_name>' as '<new_name>';the new name is optional if the location of the files are the same.
After that, you can continue recovering the standby database.
Liron Amitzi
Senior DBA consultant
[www.dbsnaps.com]
[www.orbiumsoftware.com]

Standby database applying newly created datafiles

Hi
I created standby database out of cold back up of my production database(taken 1 month back). I copied all the archive logs of production db since that time to standby database.
After I took COLD backup I added few datafiles to the production database.
Also after I set up standby database,I added few datafiles to the production database.
Now having all archive logs on standby,if I use my standby database in the event of my production database failure ,do the standby database creates all the data files created after the cold back up ,out of archive files.Do I need to issue any special statement for that.
If I open standby database in read only mode does the standby database creates those added datafiles out of archive files.
Please give your input.
Thanks in advance.
Gopal

You haven't given any usefuly information on your problem.
show parameter log_archive_dest
show parameter fal
show parameter dg
What errors are in your alert logs ?
What command are you using to recover ?
Check the contents of v$archived_log
# run on primary to detect failures :-
select destination, status, fail_date, valid_now
from v$archive_dest
where status != 'VALID' or VALID_NOW != 'YES';
# run on standby to get exact position of rollforward :-
select thread#, to_char(snapshot_time,'dd-mon-yyyy:hh24:mi'),
to_char(applied_time,'dd-mon-yyyy:hh24:mi'),
to_char(newest_time,'dd-mon-yyyy:hh24:mi') from V$STANDBY_APPLY_SNAPSHOT;
Are you using dataguard broker ?

Resize standby database's datafile, get ORA-00600:

Hello,
10GR2 database
In phsical standby database, when try
alter database datafile 'xxx' resize xxx;
got error:
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcvrsz_01], [45], [200], [], [], [], [], []
the database is in READ ONLY mode.
select log_mode, open_mode, protection_mode, database_role from v$database;
LOG_MODE OPEN_MODE PROTECTION_MODE DATABASE_ROLE
ARCHIVELOG READ ONLY MAXIMUM PERFORMANCE PHYSICAL STANDBY
is there any proper way I can resize datafile sucessfully?
thank you

Hello user9320579 :
yes, now database in mount status.
when I do
alter database datafile 'xxx' resize xxxM;
get error"ORA-01109, DATABASE NOT OPEN "
...So seems like I need to
alter database open; (read write mode)
(then do resize datafile.)
quesiton is...
(but) how can I put database back to read only mode WITHOUT BOUCING DATABASE?
thank you

Standby Database Datafile Move

Similar Messages

Maybe you are looking for