Recover Datafile with Noarchivelog

Dear all,
Received a call saying the database cannot up the error message as below
ORA:01113 file2 needs media recovery
ORA:01110 Data File 2.....
Thus,
svrmgr> startup mount
svrmgr> alter database datafile 'c:.....' offline drop;
svrmgr> alter database open;
I created another owner in order for me to import from backup file.
Next day, I discovered the datafile is being hide by 'someone' and the permission of the file is read only.
Question is can I still recover my datafile from my physical datafile ? This is no archivelog mode. I just set it archivelog mode.
Any ideas to recover back if without archive log mode ? Please help me on this ....
null

i tried to take this datafile offline but this failed Please check your alert log file. Since you are working with noarchivelog mode. You must be having a backup. Do you ?
what are the exactly procedures to recover this file ?You have not provided enough information but here are hints;
- What kind of backups you have? Rman or user managed backups?
Also read;
http://www.oracle.com/technology/documentation/index.html
Ex Senior DBA
Lazy: Those who do not read documentation

Similar Messages

Recover datafile in noarchivelog mode

hi all
i faced problem when opening the database that there are datafile needed recovery
i'm working in noarchivelog mode
i tried to take this datafile offline but this failed
what are the exactly procedures to recover this file ?

i tried to take this datafile offline but this failed Please check your alert log file. Since you are working with noarchivelog mode. You must be having a backup. Do you ?
what are the exactly procedures to recover this file ?You have not provided enough information but here are hints;
- What kind of backups you have? Rman or user managed backups?
Also read;
http://www.oracle.com/technology/documentation/index.html
Ex Senior DBA
Lazy: Those who do not read documentation

Recover datafile datafile_name until consistent with controlfile;

Hi.
When I tried to start a database I got message
Database mounted.
ORA-01113: file 22 needs media recovery
ORA-01110: data file 22: '/d01/ORACLE/DEV06/DEV06_sl_def_eo_01.dbf'
Can I use the above command in subject i.e.
recover datafile <datafile_name> until consistent with controlfile;
and then use alter database open to bring up the database.
It is a 10.1.0.4
Thanks
/SKH

Did you try what Eric recommended?
Restore the affected datafiles from backup and perform recovery
SQL> RECOVER DATAFILE <FILE NUMBER>
or
SQL> RECOVER DATABASE ;
V$DATAFILE
V$RECOVER_FILE
V$RECOVERY_FILE_STATUS
V$RECOVERY_PROGRESS Also check if you experience the below explained situation (Query V$BACKUP) :-
Ending a Backup After an Instance Failure or SHUTDOWN ABORT
http://download-east.oracle.com/docs/cd/B19306_01/backup.102/b14191/osbackup004.htm
Hope it helps,
Babu Rangasamy

Recovery of datafile which is in RECOVER state in NOARCHIVELOG mode

Hi,
i have following datafile in recover state
12 /oradata/ORADATA/undo_tbs.dbf OFFLINE
I tried to recover but getting following errors....
SQL> recover datafile 12;
ORA-00279: change 29659636 generated at 03/26/2011 00:47:23 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/product/10.2.0/flash_recovery_area/ORCL/archivelog/2011_04_07/o1_mf_1_4608_%u_.arc
ORA-00280: change 29659636 for thread 1 is in sequence #4608
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log '/u01/app/oracle/product/10.2.0/flash_recovery_area/ORCL/archivelog/2011_04_07/o1_mf_1_4608_%u_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
due to this datafile we r not able to create tables...is there any solution except restoring from backup...Pl helppp

SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 6150
Current log sequence 6153
SQL>
this is the output
Edited by: 850520 on Apr 7, 2011 2:46 AM

Got error while recover controlfile with rman

Dear all,
My controlfile and some datafiles were crash and i tried to recover their with rman as the following step:
1. startup nomount;
2. restore controlfile from autobackup;
3. alter database mount;
4. restore database;
5.SELECT archivelog_change#-1 FROM v$database;
ARCHIVELOG_CHANGE#-1
1301671
6.run {
set until scn 1301671;
recover database;
executing command: SET until clause
Starting recover at 01 พ.ย. 2006
using channel ORA_DISK_1
starting media recovery
media recovery failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 11/01/2006 15:38:01
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database reco
ver if needed
start until change 1301671 using backup controlfile
ORA-00283: recovery session canceled due to errors
ORA-01190: controlfile or data file 1 is from before the last RESETLOGS
ORA-01110: data file 1: 'C:\ORACLE\ORADATA\DB01\SYSTEM01.DBF'
What happend? Please give me some advise.
Thaks for advance !
Chara

After every resetlogs you have to take fresh backup.
It seems you have opened your database in resetlogs and your backup is prior to this resetlogs.So the controlfile is showing inconsistance with the other datafiles.

Empty datafile with special characters in name

Hello all
I'm having an issue with an empty datafile that is in recover mode.
Previously the following has been successful :
alter database create datafile 'fully_qualified_file_name' as 'fully_qualified_file_name' ;
recover datafile 'fully_qualified_file_name' ;
alter database datafile 'fully_qualified_file_name' online;
However this time it doesnt work as I get errors :
ORA-01516: nonexistent log file, data file, or temporary file
Using the file id doesnt work either.
When I created a control file trace I can see the datafile has special characters in the name :
'/oracle/PRD/112_64/dbs/PSPR3I ^?;^?'
As it is empty, would it be possible to create anothr empty datafile
using :
alter database create datafile '/oracle/PRD/112_64/dbs/PSPR3I ^?;^?'
as '/oracle/PRD/spdata2/r3i_8/r3i.data8';
then recover datafile 'fully_qualified_file_name' ;
alter database datafile 'fully_qualified_file_name' online;
How do oracle commands cope with special characters?
Thanks for your advice

user6737818 wrote:
Hello all
I'm having an issue with an empty datafile that is in recover mode.
Previously the following has been successful :
alter database create datafile 'fully_qualified_file_name' as 'fully_qualified_file_name' ;
recover datafile 'fully_qualified_file_name' ;
alter database datafile 'fully_qualified_file_name' online;
However this time it doesnt work as I get errors :
ORA-01516: nonexistent log file, data file, or temporary file
Using the file id doesnt work either.
When I created a control file trace I can see the datafile has special characters in the name :
'/oracle/PRD/112_64/dbs/PSPR3I ^?;^?'
It should work using a file number as the source file definition and a new name for the new file. Works for me:orcl> alter database create datafile 7 as 'c:\tmp\newname.dbf';
Database altered.
orcl>

Error during recover datafile - ORA-01422: exact fetch returns more than ..

Hi,
we have got actual a serious problem in our database. Some days ago we created a new datafile for a tablespace in the wrong directory:
ALTER TABLESPACE "ANZSIIDX" ADD DATAFILE '/oralunadata/anzora8/ANZSIIDX08.dbf' SIZE 500M
We recognized our mistake and generated the datafile with the same name in teh right directory:
ALTER TABLESPACE "ANZSIIDX" ADD DATAFILE '/oralunaindex/anzora8/ANZSIIDX08.dbf' SIZE 500M
We set the "wrong" datafile offline in order to rename and replace this in file in the right directory:
alter database datafile '/oralunadata/anzora8/ANZSIIDX08.dbf' offline;
ALTER TABLESPACE 'ANZSIIDX'
RENAME DATAFILE '/oralunadata/anzora8/ANZSIIDX08.dbf',
TO '/oralunaindex/anzora8/ANZSIIDX09.dbf';
After this we wanted to bring the datafile online again with a recovery but
this fails with teh strange error-message:
SQL> recover datafile 109;
ORA-00604: error occurred at recursive SQL level 1
ORA-01422: exact fetch returns more than requested number of rows
ORA-06512: at line 20
ORA-00279: change 10322956311023 generated at 04/10/2013 18:51:23 needed for
thread 1
ORA-00289: suggestion : /oralunaarchiv/anzora8/anzora8_1_315326_636567403.arc
ORA-00280: change 10322956311023 for thread 1 is in sequence #315326
A similar thing happens with our RMAN backup from last weekend, which failed:
channel c4: backup set complete, elapsed time: 00:32:33
input datafile fno=00109 name=/oralunadata/anzora8/ANZSIIDX08.dbf
input datafile fno=00103 name=/oralunaindex/anzora8/ITOPROTOKOLLEIDX01.dbf
input datafile fno=00097 name=/oralunadata/anzora8/ITOPROTOKOLLE03.dbf
input datafile fno=00096 name=/oralunadata/anzora8/ITOPROTOKOLLE02.dbf
channel c4: specifying datafile(s) in backupset
channel c4: starting compressed incremental level 0 datafile backupset
continuing other job steps, job failed will not be re-run
ORA-00600: internal error code, arguments: [krbbfmx_notfound], [109], [12801], [], [], [], [], []
ORA-01422: exact fetch returns more than requested number of rows
ORA-00604: error occurred at recursive SQL level 1
Has anybody an idea, how can we bring back the datafile online in order to run succesfull an RMAN backup?
Actually we see just the workaraound to move the objects from the affected tablespace to new tablespace
and the drop the empty tablespace what would be quite time consuming and not really practicable for us.
kind regards,
Marco

Hi,
actual we see this in v$datafile:
/oralunaindex/anzora8/ANZSIIDX01.dbf     15     ANZSIIDX     10737418240     1310720     AVAILABLE     15     NO     0     0     0     10737352704     1310712     ONLINE
/oralunaindex/anzora8/ANZSIIDX02.dbf     46     ANZSIIDX     10737418240     1310720     AVAILABLE     46     NO     0     0     0     10737352704     1310712     ONLINE
/oralunaindex/anzora8/ANZSIIDX03.dbf     58     ANZSIIDX     10737418240     1310720     AVAILABLE     58     NO     0     0     0     10737352704     1310712     ONLINE
/oralunaindex/anzora8/ANZSIIDX04.dbf     65     ANZSIIDX     10737418240     1310720     AVAILABLE     65     NO     0     0     0     10737352704     1310712     ONLINE
/oralunaindex/anzora8/ANZSIIDX05.dbf     78     ANZSIIDX     10737418240     1310720     AVAILABLE     78     NO     0     0     0     10737352704     1310712     ONLINE
/oralunaindex/anzora8/ANZSIIDX06.dbf     85     ANZSIIDX     10737418240     1310720     AVAILABLE     85     NO     0     0     0     10737352704     1310712     ONLINE
/oralunaindex/anzora8/ANZSIIDX07.dbf     88     ANZSIIDX     10737418240     1310720     AVAILABLE     88     NO     0     0     0     10737352704     1310712     ONLINE
/oralunaindex/anzora8/ANZSIIDX09.dbf     109     ANZSIIDX               AVAILABLE     109                                   RECOVER
/oralunaindex/anzora8/ANZSIIDX08.dbf     110     ANZSIIDX     10737418240     1310720     AVAILABLE     110     NO     0     0     0     10737352704     1310712     ONLINE
We dont use RMAN-Catalog for backup the information is only stored in the controlfile.
The recovery datafile command with full path including for the datafile failed with the same error message:
SQL> connect / as sysdba
Connected.
SQL> recover datafile '/oralunaindex/anzora8/ANZSIIDX09.dbf';
ORA-00604: error occurred at recursive SQL level 1
ORA-01422: exact fetch returns more than requested number of rows
ORA-06512: at line 20
ORA-00279: change 10322956311023 generated at 04/10/2013 18:51:23 needed for
thread 1
ORA-00289: suggestion : /oralunaarchiv/anzora8/anzora8_1_315326_636567403.arc
ORA-00280: change 10322956311023 for thread 1 is in sequence #315326
I guess it is a bug of oracle which will sometimes occur when you give two datafiles the same name in different directories that this poduces errors as above in the RMAN inerface(packages)!?
Maybe we could force to set he tablespace offline, rename the new added datafiles and ry to bring the tablespace online but nobody knows if it works really and we get the tablespace online again?
Therefore at the moment maybe it's the best way to move the objects away from this tablespace and than drop them, isn't it?
regards,
Marco

Recover datafile using cold backup in archivelog mode

Hi,
I have lost one of my datafiles i.e New.dbf from the disk. I have full database cold backup of last sunday. Also I have the archives. Is it possible to restore and recover only the lost datafile? Please help.

If you used RMAN to create the backup, then use RMAN again to restore that one datafile alone (RESTORE DATAFILE n) and then recover it (RECOVER DATAFILE n).
If you didn't use RMAN but you are sure that the backup was a COLD Backup, manually restore the datafile and then issue a RECOVER DATAFILE n from the SQLPlus command.
In either case you must ensure that the datafile is OFFLINE before you restore the file -- or take it OFFLINE with ALTER DATABASE DATAFILE n OFFLINE IMMEDIATE before doing the restore.
After the RECOVER is completed, you must bring it ONLINE with an ALTER DATABASE DATAFILE n ONLINE
Hemant K Chitale
http://hemantoracledba.blogspot.com

Recover datafile

Hi All,
DB: 10g No Archive mode
OS: windows
I am unable to recover my datafile after renaming the same. Following are the steps that I have taken:
I have a old controlfile trace and the latest controlfile is lost. The old controlfile doesnt have the new datafile entry.So i am mounting the database with the old trace with resetlog option and then i will be renaming the unamed datafiles.
STARTUP MOUNTThen i create controlfile
ALTER DATABASE OPEN RESETLOGS;Now the newly added datafile is as below:
SQL> select name from v$datafile;
NAME
D:\ORAHOME_XPRESS10G\ORADATA\XE\SYSTEM.DBF
D:\ORAHOME_XPRESS10G\ORADATA\XE\UNDO.DBF
D:\ORAHOME_XPRESS10G\ORADATA\XE\SYSAUX.DBF
D:\ORAHOME_XPRESS10G\ORADATA\XE\USERS.DBF
D:\ORAHOME_XPRESS10G\ORADATA\XE\TEST01.DBF
D:\ORAHOME_XPRESS10G\APP\ORACLE\PRODUCT\10.2.0\SERVER\DATABASE\MISSING00006Then i rename the datafile as
SQL> alter database rename file 'D:\ORAHOME_XPRESS10G\APP\ORACLE\PRODUCT\10.2.0\SERVER\DATABASE\MISSING00006' to 'D:\ORAHOME_XPRESS10G\ORADATA\XE\TEST02.DBF';
Database altered.
SQL> select FILE#,STATUS,NAME from v$datafile;FILE# STATUS NAME
1 SYSTEM D:\ORAHOME_XPRESS10G\ORADATA\XE\SYSTEM.DBF
2 ONLINE D:\ORAHOME_XPRESS10G\ORADATA\XE\UNDO.DBF
3 ONLINE D:\ORAHOME_XPRESS10G\ORADATA\XE\SYSAUX.DBF
4 ONLINE D:\ORAHOME_XPRESS10G\ORADATA\XE\USERS.DBF
5 ONLINE D:\ORAHOME_XPRESS10G\ORADATA\XE\TEST01.DBF
6 RECOVER D:\ORAHOME_XPRESS10G\ORADATA\XE\TEST02.DBF
After this when i am trying to recover the concern datafiel i am getting the following errors:
SQL> recover datafile 6;
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [krhpfh_03-1202], [fno =], [6], [fhcrt =], [794948267], [cptim =], [0], []
ORA-01110: data file 6: 'D:\ORAHOME_XPRESS10G\ORADATA\XE\TEST02.DBF'
and also,
SQL> RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
ORA-00283: recovery session canceled due to errors
ORA-01124: cannot recover data file 1 - file is in use or recovery
ORA-01110: data file 1: 'D:\ORAHOME_XPRESS10G\ORADATA\XE\SYSTEM.DBF'
BR
Sphinx
Edited by: $phinx19 on Sep 25, 2012 7:47 AM

Hi Vreddy,
I have tried the same by but it aint working. I am getting the following error:
SQL> recover datafile 6;
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [krhpfh_03-1202], [fno =], [6], [fhcrt =], [794948267], [cptim =], [0], []
ORA-01110: data file 6: 'D:\ORAHOME_XPRESS10G\ORADATA\XE\TEST02.DBF'
Br
Sphinx

Recover datafile doubt

After did a switchover(DataGuard), on my current primary database I did a level 0 backup RMAN and it did not end due to an error with an datafile that needs recover, specifically the datafile 2 (sysaux tablespace). The last level 0 backup I have is 9 days ago. The first thing I do was restore the datafile and try to recover it.
RMAN> run{sql 'alter database datafile 2 offline'; restore datafile 2; recover datafile 2;}
The second step (recover) show me the following error:
unable to find archived log
archived log thread=1 sequence=1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/17/2010 12:19:01
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1 and starting SCN of 1757
I appreciate any help, thank you.

Dear user12100209,
Please see the error message;
RMAN-06054: media recovery requesting unknown archived log for thread string with sequence string and starting SCN of string
Cause: Media recovery is requesting a log whose existence is not recorded in the recovery catalog or target database control file.
Action: If a copy of the log is available, then add it to the recovery catalog and/or control file via a CATALOG command and then retry the RECOVER command.
If not, then a point-in-time recovery up to the missing log is the only alternative and database can be opened using ALTER DATABASE OPEN RESETLOGS command.So what i am thinking is that is happening because of a missing archivelog metadata(information) in the standby controlfile.
Below link may give you a general information;
http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/rcmadvre.htm#BRADV89834
Hope That Helps.
Ogan

Recover datafile that has extended beyond OS limit?

We have a Linux server running Oracle 8.1.7 and we have a data file (users01.dbf) that had "autoextend" enabled and has now grown past the upper limit of the underlying filesystem. Oracle will not open the file, as the OS returns an error: "Linux Error: 75: Value too large for defined data type"
Here are some details:
OS: Redhat 7
Filesystem: Ext2
Oracle Ver: 8.1.7
DBF Size: >2gb
I have attempted to copy the .dbf files to a new server with little luck. Redhat 10 with Oracle 10 complained that the ctl files were corrupt, so I deleted them and recreated them based on the data files. After that, the DB indicated that the datafiles needed a media recovery, so I performed a "recover datafile..." on each of them successfully. Once I try to open the database, I get a "End of communication channel" error. I cannot mount it in Windows as the blocksizes are different (8192 vs. 4096)
I am at the end of my ideas on how to recover this file. Any suggestions?
I have thought of:
1. Bring a copy of 8.1.7 up on a new Redhat system running a newer FS (Reiser) and try to open the file
2. Add a new drive to the old sever and format that with the new FS, copy the dbf files there and point the DB to those files
Any tools that I try to run on the old server all hit the roadblock of the Linux:75 error.
Thanks for any ideas that come to mind.

Can you give more detail about how you tried to copy the database files?
First, I assume you are copying with the database down right?
I would not change versions of Oracle during the copy, only the OS.
SuSE Linux Enterprise Server 8 will work with your version of Oracle but I cannot from memory remember what its OS limit is.
I would research either Suse 9 or Red Hat 9 and see if they work with your version of Oracle and support larger file limits.
This site appears not to have info on Oracle 8 http://www.puschitz.com/
However, he can had it in the past and he might provide some help.
I like the copy idea, but I think you might lose some data.
I'm thinking you will try this if you iron out the OS issue
Start the database mount
SQLPLUS> alter database recover database until cancel using backup controlfile;
SQLPLUS> alter database recover cancel;
SQLPLUS> alter database open resetlogs;
I wish you luck and no loss of data!

Recover datafile problem

Hi, I am using Oracle 7.3.4 on NT 4.
I am having problem with one of my rollback segments call HISTORY which contain two datafiles in e:\rollback\history.ora and f:\rollback\history.ora
This rollback segment was used for transfer old data to HISTORY datafile in
f:\HISTORY\HISTORY.ora
(the sql look like this -
set transaction use rollback segment history;
insert into history.bk_tableA
where ..... )
Recently the HISTORY rollback was droped by mistake. Since then I lost access to history tables( in HISTORY datafile). When I open the storage manager
it shows these 3 files are in recover status.
What is the relationship between the History rollback seqment and History datafile?
The list below were the errors I got when trying to recover a datafile
First attemp:
SVRMGR>
recover datafile 'f:\history\history.ora';
ORA-00279: Change 525082216 generated at 12/08/99 16:24:02 needed for thread 1
ORA-00289: Suggestion : d:\ORANT\RDBMS73\%ORACLE_SID%25290.001
ORA-00280: Change 525082216 for thread 1 is in sequence #252904
Specify log: {=suggested | filename | AUTO | CANCEL}
ORA-00310: archived log contains sequence 252909; sequence 252904 required
ORA-00334: archived log: 'D:\ORANT\RDBMS73\ORCL25290.001'
I try auto, and even the suggested log file orcl25290.001 and still could not recover the datafile. It seems the recover program
cannot find the specific sequence # in the log file! Any suggestion?
Second attemp:
I try the incomplete, change base recovery -
SVRMGR>recover until chang 525082215
it shows Media recovery complete. Then, I open the database with
'alter database open noresetlogs'
But I still cannot access to that data file.
svrmgr>select count(*) from history.bk_sn_err;
count(*)
ora-00376: file 5 cannot be read at this time
ora-01110: data file 5: 'f:\history\history.ora'
From the storage manager the file is still in recover status.
Does the file been recovered at all?
Is it possible that I could drop the damaged
rollback segment and recreate a new one.
Should I be able to gain access to the f:\history\HISTORY.ora datafile?
[email protected]
null

Hi Micheal,
when you said you had dropped the history, did you drop the rollback segment or did you delete the history.ora file from the NT or did you drop the file from Oracle by doing an
alter database adatfile '...history...'offline drop?
also is your database running in archivelog mode?
depending on the above, you will have to use different methods to recover.
from the error messages you seem to be running with no archivelog mode so you have to offline drop the datafile.
If you do an offline drop on the datafile, then you will have to drop tha tablespace and recreate it.
Thanks,
Mandar
null

Recover database with arc-file

Hi,
my database was in the archive-log and then we had a dataimport and the database crashed, because there was not enough space.
So i brought the database now to the mount status and i want to recover my database.
I take this:
recover database using BACKUP CONTROLFILE
and then it proposed me an archive-file but i must take an other one.
How can i choose the file?
Thanks in advance.
Nicole

And why on Earth are you throwing "using backup controlfile" in there?
ARE you using a backed up copy of your controlfile? No. You haven't mentioned restoring an old copy of the controlfile at all. So if you haven't restored one from backup, why in Heaven's name are you telling Oracle that the control file is out of date? Because that's what that recovery command does.
Once you say, "The control file you are using is not to be trusted regarding which logs have been generated because it's an old one I brought back from a backup made some time in the past", then it's no wonder that Oracle has a brain fit and starts proposing that archives be applied which don't actually exist yet. "Using backup controlfile" means "I will tell you when to stop applying redo, because this ancient controlfile can't do that for me reliably".
It does actually get worse: the fact that your database crashes doesn't inevitably mean you have to recover a thing. Instance crashes are recovered from completely automatically just by restarting the database.
So you probably didn't need to recover your database at all. You've used the wrong command to recover it even if it did. And by claiming your control file is out of date once, it is quite possible that you really do now need to perform a recovery that was originally completely unnecessary.
Not bad for a day's work! :-)
The golden rule of recoveries is: when you're in a hole, stop digging until you've worked out with near-complete certainty why you're in the hole in the first place. Diagnosis is king. Only then do you start planning recoveries.
The second golden rule of any recovery process, once you've started is: only restore from backup those files which are actually damaged. If your control file isn't lost or damaged, it doesn't need restoring. Same goes for any datafile, too.
And the third golden rule is: only recover that which you've restored. If you've restored file 4, you don't issue a "recover database" command. And if you haven't restored file 6, don't say 'recover datafile 6'. And if you haven't restored a binary copy of the controlfile made at some time in the past, don't say "using backup controlfile".
The final, not so much rule as inevitable consequence, is that botched, mistaken, wrong or partial recoveries screw your database up much worse than it was before you did anything. I hope you have a good backup of this database, because you're going to need it.

Diff btw "recover datafile file#" & "alter database recover datafile file#"

What is the difference between
"recover datafile file#"
"alter database recover datafile file#"
Thanks
Naveen

I don't mean to be rude, but the statement that "There is no difference in both the commands" is facile in the extreme. Sounds like more off-the-cuff instant advice than the considered thoughts of someone who's actually bothered to try both commands out.
The "alter database recover..." command is a disaster waiting to happen and should never be used by anyone who actually wants to achieve a successful database recovery. It has the effect of suppressing most of the interactive dialogue you get when you submit the shorter "recover..." command, and indeed causes spurious errors to be displayed because the non-interactive recovery process gets it wrong.
For example, here's me recovering my database using the "alter database" syntax:
SQL> alter database open;
alter database open
ERROR at line 1:
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\WIN10\USERS01.DBF'
SQL> alter database recover datafile 4;
alter database recover datafile 4
ERROR at line 1:
ORA-00279: change 642359 generated at 07/04/2008 09:03:18 needed for thread 1
ORA-00289: suggestion :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_9_%U_.ARC
ORA-00280: change 642359 for thread 1 is in sequence #9Note the slightly alarming report of an 'error at line 1'. What's difficult to convey in mere text, however, is that at the end of that output, the thing just sits there, and you've no idea what on Earth is happening on the database. The text tells you it's making a suggestion, but there's no indication of how you accept the suggestion, of what's happening when you do accept it or where anything is up to.
I've interrupted one of those once (fortunately only in a training room) and lost the entire database as a result (because a half-complete, interrupted recovery is worse than no recovery at all).
Compare that with the plain "recover..." syntax example:
SQL> recover datafile 4;
ORA-00279: change 642359 generated at 07/04/2008 09:03:18 needed for thread 1
ORA-00289: suggestion :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_9_%U_.ARC
ORA-00280: change 642359 for thread 1 is in sequence #9
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 642571 generated at 07/04/2008 09:06:26 needed for thread 1
ORA-00289: suggestion :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_10_%U_.ARC
ORA-00280: change 642571 for thread 1 is in sequence #10
ORA-00278: log file
'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_9_46TPVL2G_.ARC' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 642576 generated at 07/04/2008 09:06:32 needed for thread 1
ORA-00289: suggestion :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_12_%U_.ARC
ORA-00280: change 642576 for thread 1 is in sequence #12
ORA-00278: log file
'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_11_46TPVRMK_.ARC' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
Media recovery complete.There are no weird error messages reported here. The suggestion is accompanied by a prompt that tells you how to accept it. Every time a new log is required, a new prompt is given. You can cleanly cancel at any time by typing 'cancel'. You are kept informed throughout and are in charge throughout.
Anyone that uses "alter database" syntax during a recovery is, therefore, either brave or foolhardy. In either case, there is a very profound difference between the two.
Your parting shot that 'alter database' is a SQL command and 'recover' can be an RMAN command misses the point by a wide mile, too. RMAN can issue pretty much any piece of SQL you like, so long as you wrap it in the SQL command:
RMAN> sql 'alter database recover datafile 4';
using target database control file instead of recovery catalog
sql statement: alter database recover datafile 4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 07/04/2008 09:23:16
ORA-00279: change generated at needed for thread
RMAN-11003: failure during parse/execution of SQL statement: alter database recover datafile 4
ORA-00279: change 642359 generated at 07/04/2008 09:03:18 needed for thread 1
ORA-00289: suggestion : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_9_%U_.ARC
ORA-00280: change 642359 for thread 1 is in sequence #9We don't get much further in RMAN with this dodgy form of the recovery command than we did in SQL*Plus, it's true -but that's just because it's a silly command to use in the first place, wherever you thought to use it. The distinction you seek to draw between 'SQL commands' and 'RMAN commands' is false in this case, in other words.

Recover Datafile until time

Hi ALL,
what is the correct syntax ....i get 'illegl recovery option until'
when i use
RECOVER DATAFILE 'COMPLETE FILENAME WITH PATH' UNTIL TIME '2006-01-28:16:00:00' ;
wHAT IS THE CORRECT ONE ?
Regards
Sunny

Recovery command in 9i

Recover Datafile with Noarchivelog

Similar Messages

Maybe you are looking for