Backup & Recovery :: How Many Times To Recover (TSPITR) A Tablespace
Feb 7, 2011
How many times i can do recover (TSPITR) a tablespace ? While trying to recover tspitr tablespace on 2nd time i got error message ORA-01178 file 13 created before last create controlfile,but first time it was success.
I have to perform the TSPITR of a tablespace to recover it to a time 03-apr-2011 5 pm.Now I have done that.
Now I find that I need to actually recover it ti 04-apr-2011.Can I again recover the tablespace to 04-Apr after recovering it to 03-Apr by mistake I am not usng recovery catalog;
I am doing some test, seeking your expert opinion.I have a database and have the following backup strategy.
1) Database running in archive log mode. 2) First I backup all the table space excluding one tablespace 'DP_TS_LOB'.
RMAN> CONFIGURE EXCLUDE FOR TABLESPACE 'DP_TS_LOBS'; RMAN> BACKUP DATABASE;
3) I take a separate Backup of DP_TS_LOB tablespace.
RMAN> BACKUP TABLESPACE DP_TS_LOB;
4) I backup all the archived redo logs.
RMAN> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; RMAN> backup archivelog all delete input;
Now I wanted to restore the database from the backup excluding the DP_TS_LOB and bring it up and running. DP_TS_LOB is huge and used only on certain work flows. I don't want the database to be down until we restore DP_TS_LOB. I wanted to restore all the other tablespace and bring the database up operational and restore and recover the DP_TS_LOB tablespace datafile's in background taking the datafiles of DP_TS_LOB tablespace offline.I tried the following but unsuccessful.
RMAN> restore controlfile to 'g:ctl_bckctl_01' from autobackup; RMAN> restore spfile to 'g:ctl_bckspfile' from autobackup; RMAN> sql "create PFILE = ''G:ctl_bckPFILE'' from SPFILE = ''G:ctl_bckSPFILE''";
Update the new parameter with new control file name. Copied the control file and parameter file to corresponding location.
First I assumed "Recover Database" will only recover online database files. But got the following error.
RMAN> recover database;
Starting recover at 27-JUL-11 using channel ORA_DISK_1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 07/27/2011 18:23:03 RMAN-06094: datafile 8 must be restored
Then I tried recovering data file separately, but same error.
RMAN> recover datafile 1;
Starting recover at 27-JUL-11 using channel ORA_DISK_1
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 07/27/2011 18:24:30 RMAN-06067: RECOVER DATABASE required with a backup or created control file
I am trying to create my database on a new server using rman incremental hot backups.
I have already restored and recovered my level 0 database on new server, but i am not able to restore/recover the level 1 backup on the new server. I have transported level 1 backup irom the old server to the new one. Do i need to recover lvl 1 bkp only or restore it also.
I'm in the process of testing a restore/recover from a simulated full system and media loss. A level 0 backup was taken from the server, and I'm trying to restore/recover to a point in time on a second server. I have created the database (with the same name) and have been able to successfully restore both the controlfile and spfile from the autobackup.
how does RMAN treat the "set until time"? The level 0 was taken on a database/server that is in CST while the database I'm trying to do a restore/ recover to is in EST. So when trying to do a point in time recovery, should I specify the time in EST or CST?
I have the following situation: a customer sent me a group of files, that he said to be a "backup" of an old database, that is no longer online (he doesn´t use our software anymore). However, he needs to recover the data in this database. The person at the company who generate these files doesn´t work there anymore, so we don´t have any of the following information:
- Database version, connection details, service names, user names neither tablespace names.
We were just told that these files were recorded in a DVD, and is que only source remaining. The files he sent are the following:
Currently my DB is running on 10g Archivelog mode. All the archive logs being generated at /u04/dbarch/.The server crashed yesterday. Now when I want to start my instance it throwing the error ORA-01110 and ORA-01113-- system01.dbf need more recovery.The below are the command I fired from sql prompt:-
SQL>STARTUP MOUNT; SQL>RECOVER DATABASE UNTIL CANCEL; But still oracle suggesting that system01.dbf need more recovery.
How i can recover my drop table..i use user managed backup concept after dropping table i cant recover my table..how i use step that my dropped table recover.
Our client has this scenario:May 23th 4:00 PM a user truncate a critical table. The customer need to recover the data before truncate.
The recover materials list like this: 1. A cold backup of this database at May 1th. 2. The archive log except May 1th ~ May 15th. 3. Every day exp at 00:30 and 12:00.
Is there any way to recover the data before truncate table with these material?
My scenario is use RMAN to restore and recover database to a new host.The structure of two hosts are same.
In Host A: 1. Take a full backup. 2. Import a schema which has 191 tables in order to generate archivelogs.
In Host B: I put all the folders(backupset, autobackup, archivelog) to the same directory. But after recovered the database, i checked that schema just has 175 tables, the latest few tables are missing.
multiple disk failure, the database was open at the time.We have managed to recover the data from the disk and have put it on another disk.We have got a new server with oracle 9 running.
A blank database has been created.I have copied the control files and redo files onto the new server and left the datafiles , (.dbf,.ora) on a seperate external disk F drive (this is because the original database resided on F drive)I can mount the database , however when I try to open it I get the following
ORACLE instance started.
Total System Global Area 135338868 bytes Fixed Size 453492 bytes Variable Size 109051904 bytes Database Buffers 25165824 bytes Redo Buffers 667648 bytes Database mounted. ORA-01122: database file 1 failed verification check ORA-01110: data file 1: 'F:ORACLEORADATALCMPROSYSTEM01.DBF' ORA-01207: file is more recent than controlfile - old controlfile
We have faced database(10.2.0) issue cause incomplete recovery and have performed open resetlogs. This DB is of 12Tb. In 10g opening database with reset logs do not invalidate previous backups. we have another replica(no reset state)of this database which we sync using archives.how we can apply those archives(reset database)to previous database?
I am attempting to perform a TSPITR on a newly created tablespace. The error indicates that the tablespace is not in the recovery catalog in which case it is. The database is Oracle 11g on Win2k8 64bit enterprise edition.
List of Datafiles in backup set 52 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 3959509 06-MAR-11 +DATA/orcl/datafile/system.257.742678049 2 Full 3959509 06-MAR-11 +DATA/orcl/datafile/sysaux.258.742678049
I have a database for which I use RMAN for backup & recovery. The database is in archivelog mode. Online redo log files are multiplexed and I have more than one destinations for archive logs. If, due to a disk crash, all data files and redo log files are gone - and I have archive logs, one member of each redo log group and a full database backup available, I can recover till the last archived log. But I want to ask that what about the transactions which were not archived at the time of media failure? How can I recover committed transactions which were not archived at the time of crash, and I have a mirrored copy of log group which was current at the time of failure?
Is possible use the TSPITR recovery with a database not cataloged in a RC (Recovery Catalog)? ... Using only the control file? I am trying but seems not possible...
i want to clone the test db to dev db but i dont want default users and tablespaces(SYS,SYSAUX,...) in the test db datapump and exp are not working, then contacted ORACLE support and they concluded that test db sysaux was corrupted.i took RMAN all tablespace bkup except default tablespaces. then created new database using DBCA and now i want to restore and recover all those test db tablesapces but while i'm doing restore its saying
RMAN> restore tablespace MAIN_DATA;
Starting restore at 07-SEP-12 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=129 device type=DISK creating datafile file number=20 name=/opt/oracle/oradata/DEV71/main_data01.dbf restore not done; all files read only, offline, or already restored Finished restore at 07-SEP-12
we are using dataware house of huge amount of data I want to take backup using rman so that I restore oracle instance and specific tablespace only not full database
I recently started reading about oracle backup and recovery concepts, and I needed to understand what is happening where we put a tablespace to a backup mode (alter tablespace tablespace_name begin backup) ?
I have a "prj_tbl" named tablespace in a user's schema in my database. i have given 100mb size to the "prj_tbl" at the time of its creation and auto extend is open for 10mb,and now this tablespace is using nearly 3.6mb space for its data and remaining space is free,now i want to reduce the size of "prj_tbl" tablespace to 20mb and when i tried to resize it then ,
It throws an error- "'ora-03297 file contains used data beyond requested resize value oracle"
I think this message showing that my new size is small than the size of data on my tablespace but it shows free space nearly 96mb then it means my new size is larger than the size of data on tablespace. How should I reduce the size..