Restore Database Question

I'm using 9i.
Currnetly, I am perfroming hot backups each day at 6:00 AM. Naturally this process backups the Archive redo logs.
My question is, if I had a failure at say 1:00 PM, then would i be correct in saying that the backup of the Archive Redo Logs are useless?
I mean, with my current backup strategy, this means that I can restore from the 6:00 AM backup but the redo logs would be useless as the failure occured at 1:00 PM.

Yes, if the case with Redo Log files.
But why i told you about Archive Redo log files!!!
My question is, if I had a failure at say 1:00 PMMy Previous Post helps you
I'm syaing that if I had a disk failure at 1:00PM No use - restore point is your last backup at 06:00 AM
In this case I would restore from the 6:00AM backup and leave the archive >>>redo logs as they are? Reason I say that is the backup of the redo logs at >>>6:00AM are usless right? Is your Last backup 06:00 AM is consistent???

Similar Messages

Restore Database to non-ASM Storage - Issue with Bigfile Tablespace

I have been testing a restore of my prod database that uses ASM (and oracle managed files) for storage to a different server and non-ASM storage. Oracle version is 10g EE. My database has one bigfile tablespace and it's datafile is about 250GB. The restore fails and it has something to do with the bigfile tablespace.
Here is the rman restore script:
run
set newname for datafile 1 to '/ora01/db/ehr/system01.dbf';
set newname for datafile 2 to '/ora01/db/ehr/undotbs01.dbf';
set newname for datafile 3 to '/ora01/db/ehr/sysaux01.dbf';
set newname for datafile 4 to '/ora01/db/ehr/undotbs02.dbf';
set newname for datafile 5 to '/ora01/db/ehr/users01.dbf';
set newname for datafile 6 to '/ora01/db/ehr/apolloaud01.dbf';
set newname for datafile 7 to '/ora01/db/ehr/apollohist01.dbf';
set newname for datafile 8 to '/ora01/db/ehr/apolloidx01.dbf';
set newname for datafile 9 to '/ora01/db/ehr/apollotab01.dbf';
set newname for datafile 10 to '/ora01/db/ehr/apollotab02.dbf';
set newname for datafile 11 to '/ora02/db/ehr/apollolob01.dbf';
set newname for datafile 12 to '/ora01/db/ehr/apollofdb01.dbf';
set newname for datafile 13 to '/ora01/db/ehr/apolloidx02.dbf';
set newname for datafile 14 to '/ora01/db/ehr/apolloidx03.dbf';
set newname for datafile 15 to '/ora01/db/ehr/apolloaud02.dbf';
set newname for datafile 16 to '/ora01/db/ehr/apollotab03.dbf';
set until sequence 60298 thread 2;
restore database;
switch datafile all;
recover database;
Datafile 11 is the datafile in the bigfile tablespace. Here are the weird things about the restore:
1. The restore output shows this:
creating datafile fno=11 name=/ora02/db/ehr/apollolob01.dbf
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /ora01/db/ehr/system01.dbf
restoring datafile 00002 to /ora01/db/ehr/undotbs01.dbf
restoring datafile 00003 to /ora01/db/ehr/sysaux01.dbf
restoring datafile 00004 to /ora01/db/ehr/undotbs02.dbf
restoring datafile 00005 to /ora01/db/ehr/users01.dbf
restoring datafile 00006 to /ora01/db/ehr/apolloaud01.dbf
restoring datafile 00007 to /ora01/db/ehr/apollohist01.dbf
restoring datafile 00008 to /ora01/db/ehr/apolloidx01.dbf
restoring datafile 00009 to /ora01/db/ehr/apollotab01.dbf
restoring datafile 00010 to /ora01/db/ehr/apollotab02.dbf
restoring datafile 00012 to /ora01/db/ehr/apollofdb01.dbf
restoring datafile 00013 to /ora01/db/ehr/apolloidx02.dbf
restoring datafile 00014 to /ora01/db/ehr/apolloidx03.dbf
restoring datafile 00015 to /ora01/db/ehr/apolloaud02.dbf
restoring datafile 00016 to /ora01/db/ehr/apollotab03.dbf
Why at the beginning is it "creating" datafile 11? Then it doesnt even say it is "restoring" that datafile. Only restoring datafiles 1,2,3,4,5,6,7,8,9,10,12,13,14,15, and 16.
When it creates datafile 11 it is only 26GB, that is much smaller than it should be according to v$datafile view on source prod database. Also even though it says it is creating datafile 11 as /ora02/db/ehr/apollolob01.dbf it actually creates it as an oracle managed file at /ora02/db/ehr/EHR/datafile/o1_mf_apollolo_6crxyqs2_.dbf
After the datafiles are restored the "switch datafile all" command fails:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of switch command at 10/18/2010 13:58:37
ORA-19625: error identifying file /ora02/db/ehr/apollolob01.dbf
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
So my question is how do I get this database restored to non-ASM (and non omf)?

So I tried using a different scn with my "set until scn #####" then the restore created 2 datafiles. The datafile for apollolob and apollotab02.dbf. So I think I have narrowed the problem to be that I am not using the correct scn number so RMAN can successfully restore those datafiles and recreates them instead. How do I find the correct scn to use to do a successful restore of the entire database? I have seen different methods on the web, but cant figure it out. Ive used "select archivelog_change#-1 from v$database;" and I also did "list backup of archivelog all" and used the latest sequence number. How can I find the correct scn to use so the entire database will restore?
Here is the output of "list backup":
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
19724 41.12M DISK 00:00:10 14-OCT-10
BP Key: 65840 Status: AVAILABLE Compressed: YES Tag: TAG20101014T210022
Piece Name: /mnt/migrate/rman/EHR_dbid3632734257_set113195_piece1_copy1_20101014
List of Archived Logs in backup set 19724
Thrd Seq Low SCN Low Time Next SCN Next Time
1 50439 3230234843 14-OCT-10 3230268282 14-OCT-10
1 50440 3230268282 14-OCT-10 3230286806 14-OCT-10
2 60280 3230234852 14-OCT-10 3230251419 14-OCT-10
2 60281 3230251419 14-OCT-10 3230268263 14-OCT-10
2 60282 3230268263 14-OCT-10 3230286809 14-OCT-10
BS Key Type LV Size Device Type Elapsed Time Completion Time
19725 Full 126.40G DISK 09:11:51 15-OCT-10
List of Datafiles in backup set 19725
File LV Type Ckp SCN Ckp Time Name
1 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/system.625.609259453
2 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/undotbs1.620.609259461
3 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/sysaux.768.609259463
4 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/undotbs2.632.609259467
5 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/users.257.609259471
6 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloaud.316.619537285
7 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollohist.629.619538155
8 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloidx.312.619538169
9 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollotab.276.619538487
10 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollotab.576.619539331
11 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollolob.570.619539593
12 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollofdb.750.645974339
13 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloidx.429.651171265
14 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloidx.705.688680793
15 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloaud.747.699632315
16 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollotab.330.715622123
Backup Set Copy #1 of backup set 19725
Device Type Elapsed Time Completion Time Compressed Tag
DISK 09:11:51 20-OCT-10 YES TAG20101014T210039
List of Backup Pieces for backup set 19725 Copy #1
BP Key Pc# Status Piece Name
65851 1 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece1_copy1_20101014
65862 2 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece2_copy1_20101014
65873 3 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece3_copy1_20101014
65884 4 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece4_copy1_20101014
65895 5 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece5_copy1_20101014
65901 6 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece6_copy1_20101014
65902 7 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece7_copy1_20101014
65903 8 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece8_copy1_20101014
65904 9 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece9_copy1_20101014
65841 10 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece10_copy1_20101014
65842 11 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece11_copy1_20101014
65843 12 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece12_copy1_20101014
65844 13 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece13_copy1_20101014
65845 14 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece14_copy1_20101014
65846 15 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece15_copy1_20101014
65847 16 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece16_copy1_20101014
65848 17 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece17_copy1_20101014
65849 18 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece18_copy1_20101014
65850 19 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece19_copy1_20101014
65852 20 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece20_copy1_20101014
65853 21 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece21_copy1_20101014
65854 22 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece22_copy1_20101015
65855 23 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece23_copy1_20101015
65856 24 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece24_copy1_20101015
65857 25 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece25_copy1_20101015
65858 26 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece26_copy1_20101015
65859 27 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece27_copy1_20101015
65860 28 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece28_copy1_20101015
65861 29 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece29_copy1_20101015
65863 30 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece30_copy1_20101015
65864 31 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece31_copy1_20101015
65865 32 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece32_copy1_20101015
65866 33 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece33_copy1_20101015
65867 34 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece34_copy1_20101015
65868 35 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece35_copy1_20101015
65869 36 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece36_copy1_20101015
65870 37 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece37_copy1_20101015
65871 38 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece38_copy1_20101015
65872 39 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece39_copy1_20101015
65874 40 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece40_copy1_20101015
65875 41 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece41_copy1_20101015
65876 42 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece42_copy1_20101015
65877 43 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece43_copy1_20101015
65878 44 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece44_copy1_20101015
65879 45 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece45_copy1_20101015
65880 46 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece46_copy1_20101015
65881 47 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece47_copy1_20101015
65882 48 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece48_copy1_20101015
65883 49 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece49_copy1_20101015
65885 50 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece50_copy1_20101015
65886 51 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece51_copy1_20101015
65887 52 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece52_copy1_20101015
65888 53 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece53_copy1_20101015
65889 54 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece54_copy1_20101015
65890 55 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece55_copy1_20101015
65891 56 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece56_copy1_20101015
65892 57 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece57_copy1_20101015
65893 58 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece58_copy1_20101015
65894 59 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece59_copy1_20101015
65896 60 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece60_copy1_20101015
65897 61 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece61_copy1_20101015
65898 62 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece62_copy1_20101015
65899 63 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece63_copy1_20101015
65900 64 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece64_copy1_20101015
BS Key Size Device Type Elapsed Time Completion Time
19726 228.10M DISK 00:00:49 15-OCT-10
BP Key: 65905 Status: AVAILABLE Compressed: YES Tag: TAG20101015T061242
Piece Name: /mnt/migrate/rman/EHR_dbid3632734257_set113197_piece1_copy1_20101015
List of Archived Logs in backup set 19726
Thrd Seq Low SCN Low Time Next SCN Next Time
1 50441 3230286806 14-OCT-10 3230331993 14-OCT-10
1 50442 3230331993 14-OCT-10 3230401945 14-OCT-10
1 50443 3230401945 14-OCT-10 3230469794 15-OCT-10
1 50444 3230469794 15-OCT-10 3230555010 15-OCT-10
1 50445 3230555010 15-OCT-10 3230618396 15-OCT-10
1 50446 3230618396 15-OCT-10 3230695020 15-OCT-10
2 60283 3230286809 14-OCT-10 3230304858 14-OCT-10
2 60284 3230304858 14-OCT-10 3230330891 14-OCT-10
2 60285 3230330891 14-OCT-10 3230354275 14-OCT-10
2 60286 3230354275 14-OCT-10 3230366292 14-OCT-10
2 60287 3230366292 14-OCT-10 3230399805 14-OCT-10
2 60288 3230399805 14-OCT-10 3230423577 14-OCT-10
2 60289 3230423577 14-OCT-10 3230446176 15-OCT-10
2 60290 3230446176 15-OCT-10 3230469756 15-OCT-10
2 60291 3230469756 15-OCT-10 3230496786 15-OCT-10
2 60292 3230496786 15-OCT-10 3230524710 15-OCT-10
2 60293 3230524710 15-OCT-10 3230554981 15-OCT-10
2 60294 3230554981 15-OCT-10 3230583802 15-OCT-10
2 60295 3230583802 15-OCT-10 3230610465 15-OCT-10
2 60296 3230610465 15-OCT-10 3230617887 15-OCT-10
2 60297 3230617887 15-OCT-10 3230673207 15-OCT-10
2 60298 3230673207 15-OCT-10 3230695022 15-OCT-10

ORA-01180 and ORA-01110 error when restoring database by RMAN in 11.1.0.6.0

I have a new installed database running in ARCIHVELOG mode on SUSE 10SP3. Catalog is not used. When I try to restore the database from a level 0 backup based on SCN, ORA-01180 and ORA-01110 were raised out today. Please help me through this. Thx. The senario follows:
1. I got the current SCN by "select dbms_flashback.get_system_change_number from dual". Say it's 12345;
2. I did a level 0 hot backup with current control file, archived logs and parameter files. Everything went well;
3. Some other DMLs are applied to the database;
4. I want to do a SCN-based incomplete recovery for this database to SCN 12345. Then I
1) shutdown immediate;
2) startup nomount;
3) restore the control file from backupset;
5) startup mount;
6) catalog start with "[backupset path]";
7) restore database until scn 12345.
Just at step 4.7, ORA-01180 and ORA-01110 were raised out, saying cannot create data file 1. Note: Backup files are existing and file permissions are all OK.
Then I issues "list incarnation of database". There is just one record with incarnation id 1.
So I queried v$log_history, found serveral record there. The most recent one has NEXT_SCN later than 12345, say 12400. Then I tried to restore database until this SCN. It WORKED! The restore and recovery succeeded.
My questions are:
1. Why cannot I restore the database to a previous SCN, say 12345, but 12400 is OK?.
2. If the database was RESETLOG prior to my recovery, should I reset database to the incarnation where I took my backup? What can I do if there is no that incarnation information in my control file?
Waiting for your suggestion.

Hi guys. There is one update.
This issue is caused by the incorrect SCN vs. backup set. I got this SCN before the backup started. According to Oracle docs, it's not allowed for an SCN based recovery.
Now, I changed the sequence of my operations, so that SCN is got once backup is done, which is exact the "most recent sequence# and least SCN" mentioned by some thread in this forum. It works now.
Anyone could explain why the SCN got prior to the level 0 backup is not recognized by restore/recovery phase? Thanks.

After Piecemeal Primary FileGroup Restoration, Database Property Window Shows other FileGroups also

Hi,
I have a SQL Server 2008 database with 90 Gigs of Capacity.
The database consists of a huge table with 80 Gigs of Capacity and these entire 80 Gigs of data is Static in nature.
We need the to restore the backup of this database frequently in to the Development environment, so we moved this static data into a Secondary File Group.
Now, the database Consists of 2 Filegroups : Primary & Secondary_fg.
The entire Static table is moved to the Secondary FileGroup.
We have taken the backup of Primary FileGroup using the following Backup Command :
Backup Database MYDB FILEGROUP = 'PRIMARY' to disk = 'E:\SQLBackup\MYDB_Primary_FG_Only.bak'
WITH NOFORMAT, NOINIT, NAME = N'MYDB - Full Filegroup backup', SKIP, NOREWIND, NOUNLOAD
The backup went file with the expected capacity of 10 Gigs.
I have restored this backup in to a New Database : MYDB_PRIMARY_ONLY using the following command
RESTORE DATABASE [MYDB_PRIMARY_ONLY] FILE = 'MYDB_DATA', FILEGROUP = 'PRIMARY'
FROM DISK = 'E:\SQLBackup\MYDB_Primary_FG_Only.bak',
WITH FILE=1,
MOVE 'MYDB_DATA' TO 'E:\SQLDATA\MYDB_PRIMARY_ONLY_DATA.mdf',
MOVE 'MYDB_LOG' TO 'E:\SQLDATA\MYDB_PRIMARY_ONLY_LOG.ldf', NOUNLOAD, PARTIAL
GO
The Restoration also went fine and the size of the Newly Restored Database : "MYDB_PRIMARY_ONLY" is with 10 Gigs in Capacity.
But, the gotcha here is whilst checking the Database Properties of this Newly restored database, on the FILES & FILEGROUPS tab, the files & filegroups related to the SECONDARY FILEGROUP is also showing.
MY ACTUAL QUESTION :
On the PRIMARY FILEGROUP ONLY RESTORATION HOW THIS SECONDARY FILEGROUP IS COMING INTO PICTURE ?
MOREOVER, WHEN I TRIED TO REMOVE THE SECONDARY FILEGROUP AND IT'S RESPECTIVE DATA FILE IT THROUGH THE FOLLOWING ERROR :
COMMAND USED TO REMOVED THE FILE & FILEGROUP :
USE [MYDB_PRIMARY_ONLY]
GO
ALTER DATABASE [MYDB_PRIMARY_ONLY] REMOVE FILE [SECONDARY_DATA_FILE.ndf]
GO
ALTER DATABASE [MYDB_PRIMARY_ONLY] REMOVE FILEGROUP [SECONDARY_FG]
GO
Error :
Msg 5056, Level 16, State 2, Line 1
Cannot add, remove, or modify a file in filegroup 'SECONDARY_FG' because the filegroup is not online.
Can anyone explain why such this error message ? Thanks in advance for any guidance in this regard.

On the PRIMARY FILEGROUP ONLY RESTORATION HOW THIS SECONDARY FILEGROUP IS COMING INTO PICTURE ?
When you restore only the primary filegroup, all database meta data is restored, including references to the filegroups and files not yet restored. Filegroups/files not restored will be recovery pending state and data on those filegroups will be inaccessible.
Removing the filegroup will change the status to defunct but the meta data will remain. You'll need to copy the restored objects and data to a new clean database if you want to tidy up.
Dan Guzman, SQL Server MVP, http://www.dbdelta.com

RMAN restore database validate

All,
I cannot seem to find anything in the Oracle documentation what the RMAN restore database validate checks for? Does it check for physical and logical corruption or do I need to validate the backup using logical statement to check for this?
I would appreciate it if somebody could point me in the right direction.
This is for Oracle 9iR2
Many thanks

user647138 wrote:
Many thanks for all your help. Much appreciated :)Handle:      user647138
Status Level:      Newbie
Registered:      Jul 15, 2008
Total Posts:      10
Total Questions:      5 (4 unresolved)
why dont you mark the thread as answered/helpful?
Many thanks for all your help. Much appreciated :) is it?
Posters, please mind these common-sense rules when participating here:
- When asking a question, provide all the details that someone would need to answer it. Consulting documentation first is highly recommended.
- When answering a question, please be courteous and respectful; there are different levels of experience represented here. A poorly worded question is better ignored than flamed - or better yet, help the poster ask a better question.
- It is considered good etiquette to reward answerers with points (as "helpful" - 5 pts - or "correct" - 10pts).
- See more tips in the FAQ
Thanks for doing your part to make this community as valuable as possible for everyone!
- OTN

Which archivelogs are required for restoring database

I'm moving to RMAN direct to tape backups (via Netbackup). I'm hoping someone can clarify for me which archivelogs are needed for restoring/recovering a RMAN "hot" backup.
I will have two tape pools with different retention periods:
- standard (kept for 2 months)
- long term (kept for 7 years)
I plan to backup as follows:
- archivelogs every 15 mins direct to the standard pool
- daily backups to the standard pool
- monthend backups to the long term pool
Month ends will either be a full or a full plus a cumulative (level 2) (depending on the weekday that month end falls on).
The bit I'm concerned about is archivelogs. After 2 months they will be expired on tape. But do I need archive logs in order to restore the month end backups?
At the moment I record the SCN before the backup begins and after it finishes (retrieved via select first_change# first_scn from v$log where status = 'CURRENT'). Before recording the post-backup SCN, I force a logfile switch.
For clones, I always restore to the post-backup SCN that I previously recorded (rather than using the tag I associated with the backup).
So a few questions related to restoring after the 2 month window:
- do I need the archivelogs created during the timespan of the backup ran in order to restore to the post-backup SCN?
- If so, is just backing up these archivelogs (to the long term pool) by specifying the range of pre-backup SCN to post-backup SCN sufficient or are additional archivelogs likely to be required?
- if I restore the database and don't specify an SCN but just specify the tag used at the time of the backup, will archive logs be required at all? In this case what would be the state of the restored database - would it be as it was at the beginning or at the end of the backup?

Hi user4835675,
do I need the archivelogs created during the timespan of the backup ran in order to restore to the post-backup SCN?Yes.
If so, is just backing up these archivelogs (to the long term pool) by specifying the range of pre-backup SCN to post-backup SCN sufficient or are additional
archivelogs likely to be required?Can you do a skip of the daily backup schedule duing the monthend backups run and run the "archivelogs every 15 mins" job to the long term pool?
Or temporarily stop the "archivelogs every 15 mins" job during the monthend job and run the monthend backup with the "backup database plus archivelog" clause?
if I restore the database and don't specify an SCN but just specify the tag used at the time of the backup, will archive logs be required at all?Yes, you need archivelogs to recover the datafiles to a consistent state.
In this case what would be the state of the restored database - would it be as it was at the beginning or at the end of the backup?You can only restore to a point in time which past the end of the backup.
Rgds,
Tycho

Database restore; database recover; Last step?

Ok, this is my first try with rman to restore and recover from tape.
My restore database finished successfully...no errors.
My recover database finished successfully...no errors.
Now...what is my last step?
Do I shut down and open back up normally, or, do I need to do something like shut down, then open with reset logs?
I'm guessing a full database backup after this re-opening would be a good idea too, no?
Thank you,
cayenne

sybrand_b wrote:
I wonder: why do you specialize in asking so called 'doc questions'?
Can't be bothered to read documentation?
Boss doesn't pay you for reading documentation?
Think this is a chat room?
Kindly stop posting doc questions. It violates the Forums Etiquette.
Sybrand Bakker
Senior Oracle DBABecause I didn't see anything that specifically addressed what I've had to go through in recovering this database in the document or examples I've seen or could find.
And was wanting to just make sure since I was so close, didn't want to mess anything up at the last moment.
No need to be snippy about it...everyone else is happy to give some advice and help to someone who is obviously a noob at much of this and learning as he goes.
Hoping as I learn things better...that I can helps someone else, not to mention, that searching the forums, someone might run into a weird set of circumstances like I have on this and a couple other things.
You know the old saying..."if you don't have something nice to say, then...."?
Thanks to all for all the help, I think I'm up and going again now.
C

Restore database validate command

Hey Guys..
Is there a way to attempt to run the "restore database validate" command specifying a different location for the backup?
Lets say i have a backup in the following location: C:\SimpleBackup
How can i run the restore validate command to that location instead of the default flash recovery?

We always use the :
set newname for datafile 1 to '/opt/dbsid/db01/system.dbf';
set newname for datafil 2 to '/opt/dbsid/db01/temp01.dbf';
to restore backup files to another location.
Is that useable here ?
Edit: I just re-read the question. Is the c:\simplebackup a destination to put restored files to, or is it the location of the rman archive ?
if the first is true, then the above can't be used.
Edited by: orafrf on Mar 16, 2009 4:37 PM

SQL Server 2012 restoring database from backup file

Hi All,
1. I was restoring the database from PROD box to DEV box with the deferent name.
For Ex: Both PROD and DEV boxes are having "A" database. Now I am refreshing database"A" from PROD bot to DEV box with name "B". Now while restoring in SQL server 2012 I used GUI and took database name as "A" by default.
by mistake I executed the request. before completing I notice that "A" database in DEV Box went to restoring mode.
Now, in middle I stopped the query but still I am seeing database "A" is in restoring state.
Please guide me is there any way to bring database online with current data?
2. Why sql server 2012 takes tail log backup of the existing database while restoring database with different name?

Hi,
check this link for the same issue and solutions:
http://stackoverflow.com/questions/520967/sql-server-database-stuck-in-restoring-state
Ronen Ariely
[Personal Site] [Blog] [Facebook]

Recreating ASM & Restoring database

I have an Oracle 10g R2 server with 2 disk volumes. 1st one is for the OS and the Oracle install and the 2nd one is for the database managed by Oracle ASM. I have a full backup of the database I took using OEM.
I'm having to rebuild the 2nd disk volume therefore loosing everything on it, but will still have the Oracle install unaffected.
My question is after rebuilding the disk would it be OK to just create a new ASM group and create a new database. Then just restore the backup on to it using OEM?
Thanks for your help.

We're restoring a database from tape using Oracle 10.2.0.5. We explcitely specify the location for every single file with SET NEWNAME FOR DATAFILE X. The files that get restored don't match the NEWNAME format we set it to even though the log says it restored the file to that name. I don't know what's occuring under the hood of ASM, but it appears OMF is coming into play and generating names for the files. it's becoming a problem because when we restart the restore (which occurs often due to size of the database, length of time it takes, and drives going down) we start all over because RMAN doesn't know of the existing files. This doesn't seem to be normal behavior, and I know it's not like this during file based restores.
Does anyone know what's going on within ASM itself? It appears to be normal behavior when restoring to ASM and the names are later set appropriately after the SWITCH DATAFILE ALL. That's what I think would happen. It's currently a problem restarting restores.Have you enabled OMF? as db_create_file_dest = '+data'
then if you restore database from tape/disk, it will place all the datafiles as '+data/db_unique_name/datafiles';

File name in msdb.dbo.backupset no longer matches the actual file name on the storage media. Error 3013 Restore Database is terminating abnormally.

Thanks in advance for taking the time to read this and comment. Platform: Windows Server 2008 R2 Enterprise Edition SP1 (X64) Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) Jun 17 2011 00:54:03 Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)Problem Description: The file name recorded in the msdb.dbo.backupset (sans the extension) no longer matches the actual file name written to the backup media which is
in this case a NETAPP NAS storage share. Example:
Mohave_backup_2014_03_14_233001_1158878.bak      (from NETAPP NAS filer)
Mohave_backup_2014_03_16_233001_4167237             (from MSDB.dbo.backupset), as you can see, the last 7 digits (chars) of the file name are different, although the date and time are identical. The
file names had previously been matching perfectly. The first occurance of this problem occured on 03/13/2014 at 5:00 AM MST. The error generated by the job was:
Date  3/14/2014 10:29:23 AM
Log  Job History (Refresh - Restore Mohave_93_DEV AD HOC)
Step ID  1
Server  OurDevServer
Job Name  Refresh - Restore Mohave_93_DEV AD HOC
Step Name  Restore Mohave_93_DEV
Duration  00:00:01
Sql Severity  0
Sql Message ID  50000
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted  0
Message
Executed as user: OurDomain\OurNetworkServiceLogin. Restore Mohave Prod to Mohave_93_DEV - ERROR: 3013 RESTORE DATABASE is terminating abnormally. [SQLSTATE 01000] (Message 50000). The step succeeded.

Olaf:
Thanks for your reply. Sorry, my bad. I inadvertently copied wrong [name] form the msdb.dbo.backupset. On 3/13 and 3/14, the two file names did not match. In trying to select another example to show you this morning, I found that the names are now matching!
What I was doing was to create dynamic t-sql to retrieve the latest prod backup of the database, and then restore it with move to the development server. This is an ad-hoc job that the developers can run by themselves whenever they require a refresh. Unfortunately,
we only keep 3 days worth of backups for these databases, so the original disk file I was trying to use to restore no longer exists. Researching the original error, one of the error descriptions was that the restore could not find the file requested.
I thought this very strange since I get the file name directly from the backupset table. Further research did indeed show that the file names were different, but unfortunately, I failed to save the details of the file names. Anyway, in looking for a new example
to show you this morning, I have found that the file names are indeed matching exactly again. If this error pops up again, I will be sure to save all details and re-post.
Thanks, regards and best wishes to you and yours,

Problem with restore database in sql server 2008

hi,,,when i want to restore database from a .bak file i see this error
TITLE: Microsoft SQL Server Management Studio
Restore failed for Server 'ALI-PC'. (Microsoft.SqlServer.SmoExtended)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.1447.4+((KJ_RTM).100213-0103+)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Restore+Server&LinkId=20476
ADDITIONAL INFORMATION:
System.Data.SqlClient.SqlError: The database was backed up on a server running version 10.50.4000. That version is incompatible with this server, which is running version 10.00.1600. Either restore the database on a server that supports the backup, or use a
backup that is compatible with this server. (Microsoft.SqlServer.Smo)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.1447.4+((KJ_RTM).100213-0103+)&LinkId=20476
BUTTONS:
OK
i checked overwrite the existing database(WUTH REPLACE) in option,but i cant restore again,,,please help me

Hi,
You need to install SQL Server 2008 R2 Service Pack 2
Download
http://www.microsoft.com/en-us/download/details.aspx?id=11093, you are currently running the RTM and the backup was from Version 10.50.4000 and your attempting to restore to version 10.00.1600.
To find your current SQL Version open a New Query and paste the following then execute
SELECT @@VERSION AS 'SQL Server Version
Reference:
http://sqlserverbuilds.blogspot.com/
http://support.microsoft.com/kb/321185
http://technet.microsoft.com/en-us/library/ms177512.aspx
Cheers,
-Ivan

Restore database failed on Oracle 10g 10.2.0.1 linux 32 bit

Hi,
I am working on test database for testing database disaster recovery.
1) i made full database backup by RMAN and ui also have archive log
2) i noted DBID and all folders of database
3)Turn on the Controlfile auto backup
4) then i drop database
5) then i follow all the steps , which include restoration of spfile and controlfile
6)After that when i have mounted database and in RMAN WRITING RESTORE DATABASE, it is giving following error.
Starting restore at 02-APR-08
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 04/02/2008 17:54:56
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore
Please help me
Regards,

1) i made full database backup by RMAN and ui also
have archive logWhat's the command used?
2) i noted DBID and all folders of databaseWhat's inside the folders.
ls -l <your folder>
3)Turn on the Controlfile auto backup
4) then i drop databaseHow did you drop it? delete files from OS? or DROP DATABASE statement?
5) then i follow all the steps , which include
restoration of spfile and controlfileWhat's the steps you followed? And from where you got the steps.
6)After that when i have mounted database and in RMAN
WRITING RESTORE DATABASE, it is giving following
error.
Starting restore at 02-APR-08
using channel ORA_DISK_1
RMAN-06026: some targets not found - aborting
restore
RMAN-06023: no backup or copy of datafile 4 found to
restore
RMAN-06023: no backup or copy of datafile 3 found to
restore
RMAN-06023: no backup or copy of datafile 1 found to
restoreOracle Error :: RMAN-06026
some targets not found - aborting restore
Cause
Some of the files specified for restore could not be found. Message 6023, 6024, or 6025 is also issued to indicate which files could not be found. Some common reasons why a file can not be restored are that there is no backup or copy of the file that is known to recovery manager, or there are no backups or copies that fall within the criteria specified on the RESTORE command, or some datafile copies have been made but not cataloged.
Action
The Recovery Manager LIST command can be used to display the backups and copies that Recovery Manager knows about. Select the files to be restored from that list.

Error while restoring database with different name on subscriber

Hi all,
I am using merge replication in sql server 2008R2. Yesterday I wanted to create a test environment, so
I did:
1. on publisher I restored from backup production db with another name ( lets call it TEST and new files
.mdf, .ldf and no switch KEEP_REPLICATION). After this step original replication between production
dbs worked fine.
2. on subscriber I did the same: restore as new db TEST with new
files .mdf, .ldf and no switch KEEP_REPLICATION.
Unfortunately I noticed, that after second step replication stopped. SQL agent replication job on Subscriber
is gone.
Why restoring db with new name did affect original replication?
Finally the most important: replication was set up by external company and I have to bring it to live now
but I don't know this subject so good. How can I do it?
Assuming, that there is no data change on subscriber in replicated tables is it enough when I select ‘reinitialize’
on Publisher and Subscriber?
Thanks in advance
Artur

Hello,
Sorry for late response, but I was out of the office during last week.
Regarding problem 1: restoring replication. I contacted guy who made originally our replication and he recreated subscription agent. So this is solved.
problem 2: why did it happen?
Lydia, in link which you provided I found only info about restoring db in replication, but I didn't want to restore replication.
I checked SQL Server and Server Agent logs and there were no entries on that time. The only entries are regarding db restoring. Below:
09/11/2014 12:45:59,Backup,Unknown,Database was restored: Database: Logik_ATData_TEST<c/> creation date(time): 2012/04/27(13:55:41)<c/> first LSN: 21392:66:267<c/> last LSN: 21392:227:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=DISK: {'D:\MSSQLBackup\Dzienny\Logik_ATData_PROD\Logik_ATData_PROD_backup_2014_09_10_231001_6391536.bak'}). Informational message. No user action required.
09/11/2014 12:45:59,Backup,Unknown,Restore is complete on database 'Logik_ATData_TEST'. The database is now available.
09/11/2014 12:45:59,spid72,Unknown,CHECKDB for database 'Logik_ATData_TEST' finished without errors on 2012-04-26 22:50:05.490 (local time). This is an informational message only; no user action is required.
09/11/2014 12:44:53,spid72,Unknown,Recovery is writing a checkpoint in database 'Logik_ATData_TEST' (13). This is an informational message only. No user action is required.
09/11/2014 12:44:53,spid72,Unknown,Starting up database 'Logik_ATData_TEST'.
09/11/2014 12:44:51,spid72,Unknown,The database 'Logik_ATData_TEST' is marked RESTORING and is in a state that does not allow recovery to be run.
09/11/2014 12:44:51,spid72,Unknown,Starting up database 'Logik_ATData_TEST'.
In Windows application log there were also no other entries, besides these above.
I also could not check job history, because the job was gone in SSMS jobs list, while the subscription was present in SSMS Replication with info, that last successful synchronization was at 12:42 (there is a 5 min. sync period).
I also don't understand how the job was deleted, because according this manual (http://www.mssqltips.com/sqlservertip/1803/auto-alert-for-sql-agent-jobs-when-they-are-enabled-or-disabled/) I have 2 triggers in sysjobs table and every time, when
job is deleted/disabled I got @ notification. In this case I got no @.
My SQL Server version:
Product_Version Product_Level Edition
10.50.2550.0 SP1 Standard Edition (64-bit)
Any idea what happened?
Thanks,
Artur

Restore database to azure blob failed

Hi experts,
I create a test db in SQL on Azure VM and backup to my storage account successfully. However, when I delete the database and restore using the T-SQL below, it failed. Please help.
--- query ---
USE [master]
RESTORE DATABASE [test] FROM
URL = N'https://sa1qcisapdr.blob.core.windows.net/tcd-sql2014/test_backup_2014_08_18_013128.bak'
WITH CREDENTIAL = N'AzureCredential' , FILE = 1,
MOVE N'test' TO N'https://sa1qcisapdr.blob.core.windows.net/tcd-sql2014//test.mdf',
MOVE N'test_log' TO N'https://sa1qcisapdr.blob.core.windows.net/tcd-sql2014//test_log.ldf', NOUNLOAD, STATS = 5
GO
--- result ---
Msg 3634, Level 16, State 1, Line 2
The operating system returned the error '50(The request is not supported.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on 'https://sa1qcisapdr.blob.core.windows.net/tcd-sql2014//test.mdf'.
Msg 3156, Level 16, State 8, Line 2
File 'test' cannot be restored to 'https://sa1qcisapdr.blob.core.windows.net/tcd-sql2014//test.mdf'. Use WITH MOVE to identify a valid location for the file.
Msg 3634, Level 16, State 1, Line 2
The operating system returned the error '50(The request is not supported.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on 'https://sa1qcisapdr.blob.core.windows.net/tcd-sql2014//test_log.ldf'.
Msg 3156, Level 16, State 8, Line 2
File 'test_log' cannot be restored to 'https://sa1qcisapdr.blob.core.windows.net/tcd-sql2014//test_log.ldf'. Use WITH MOVE to identify a valid location for the file.
Msg 3119, Level 16, State 1, Line 2
Problems were identified while planning for the RESTORE statement. Previous messages provide details.
Msg 3013, Level 16, State 1, Line 2
RESTORE DATABASE is terminating abnormally.

One has to install Azure Storage Explorer and add Read/Write permissions in Shared Access Key

Restore Database Question

Similar Messages

Maybe you are looking for