Re: ORA-01274 & Some recovered datafiles maybe left media fuzzy
- From: "Vishal Gupta" <vishal@xxxxxxxxxxxxxxx>
- To: <wjwagman@xxxxxxxxxxx>
- Date: Tue, 3 Feb 2009 08:53:53 -0000
You can create the newly added file standby database using following
statement
Alter database create datafile as new
Please check the syntax in the manual.
After this resume the managed recovery and ofcourse set the standby
file management to auto.
I have done it couple of times. Standby will resume where it stopped
using archive logs. .
Cheers,
Vishal Gupta
On 3 Feb 2009, at 00:09, "William Wagman" <wjwagman@xxxxxxxxxxx> wrote:
> Greetings,
>
> It should not be necessary to recreate the standby. I had to do this
> once but my recollection is not clear. There should be something in
> the alret log on the standby referenceing a file number of the file
> that was missing (at least Windows does this)..
>
> Standby: SQL > select name from v$datafile where file#=NN;
> Primary: copy file that was added to Primary database ==> Standby
> server
> Standby: SQL > alter database rename file '<old_name>' to '<new_name>;
> Standby: SQL > recover standby database;
>
> At this point it will ask you for a log file to be applied ==> copy
> and paste the log name
> Then, after this log is successfully applied, type ==> CANCEL
> and resume managed recovery:
> Standby: SQL > recover managed standby database disconnect [using
> current logfile] ;
>
> And, of course, change standby_file_managemen='AUTO'
>
> I believe that will resolve the issue.
>
> Bill Wagman
> Univ. of California at Davis
> IET Campus Data Center
> wjwagman@xxxxxxxxxxx
> (530) 754-6208
> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx
> ] On Behalf Of Xu, Roger
> Sent: Monday, February 02, 2009 11:22 AM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: ORA-01274 & Some recovered datafiles maybe left media fuzzy
>
> Background: Oracle 10.2.0.4.0 in Sun Solaris 10 with Dataguard
>
> ALTER TABLESPACE "TS_INDEX_00"
> ADD DATAFILE '/SRV_ACEP/server/database/data/ts_index_00_02.dbf'
> SIZE 2000M AUTOEXTEND ON NEXT 2000M MAXSIZE 10000M;
>
> I added a dbfile in the primary without knowing the
> STANDBY_FILE_MANAGEMENT is set to MANUAL at the standby.
> Now I have the following in the standby alert log file.
>
> What should I do now? Do I have to recreate the standby?
>
> Thanks,
>
> Roger Xu
>
> p.s.
>
> Mon Feb 2 13:10:15 2009
> Media Recovery Log /SRV_ACEP/server/database/archlogs/
> redo6327_1_668699207.arc
> File #12 added to control file as 'UNNAMED00012' because
> the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
> The file should be manually created to continue.
> Mon Feb 2 13:10:35 2009
> Errors with log /SRV_ACEP/server/database/archlogs/
> redo6327_1_668699207.arc
> MRP0: Background Media Recovery terminated with error 1274
> Mon Feb 2 13:10:35 2009
> Errors in file /SRV_ACEP/server/database/bdump/ace46p0_mrp0_1065.trc:
> ORA-01274: cannot add datafile '/SRV_ACEP/server/database/data/
> ts_index_00_02.dbf' - file could not be created
> Some recovered datafiles maybe left media fuzzy
> Media recovery may continue but open resetlogs may fail
> Mon Feb 2 13:10:37 2009
> Errors in file /SRV_ACEP/server/database/bdump/ace46p0_mrp0_1065.trc:
> ORA-01274: cannot add datafile '/SRV_ACEP/server/database/data/
> ts_index_00_02.dbf' - file could not be created
> Mon Feb 2 13:10:37 2009
> MRP0: Background Media Recovery process shutdown (ACE46P0)
>
> Please be conscious of the environment and print this email only if
> absolutely necessary.
> This e-mail (including any attachments) is confidential and may
> contain privileged information of Dr Pepper Snapple Group, Inc. and/
> or its subsidiaries ("Dr Pepper Snapple Group"). If you are not the
> intended recipient or receive it in error, you may not use,
> distribute, disclose or copy any of the information contained within
> it and it may be unlawful to do so. If you are not the intended
> recipient, please notify us immediately by returning this e-mail to
> us at mailerror@xxxxxxxx and destroy all copies. Any views expressed
> by individuals within this e-mail do not necessarily reflect the
> views of Dr Pepper Snapple Group. This e-mail does not constitute a
> binding offer, acceptance, amendment, waiver or other agreement,
> unless the intent that an e-mail will constitute such is clearly
> stated in the body of the email. Recipients are advised to subject
> this e-mail and attachments to their own virus checking, in keeping
> with good computing practice. Please note that e-mail received by Dr
> Pepper Snapple Group may be monitored in accordance with applicable
> law.
> --
> //www.freelists.org/webpage/oracle-l
Other related posts:
