Database Recovery Time

Hi
How to calculate Database recovery time in 10g? On what factors does it depend on?
Regards
JIL

JIL wrote:
Hi
How to calculate Database recovery time in 10g? On what factors does it depend on?
Regards
JILIts depend on:-
(1)Your backup stratergy.
(2)How much work you need to do during recovery like, number of archive log file/incremental backup needed for recovery.
(3)Whether require archive log file on disk or on tape.
(4)Whther you store baclup as file copy or backupset.
(5)And most important is, Your expertise on backup and recovery.

Similar Messages

Problem in performing multiple Point-In-Time Database Recovery using RMAN

Hello Experts,
I am getting an error while performing database point in time recovery multiple times using RMAN. Details are as follows :-
Environment:
Oracle 11g, ASM,
Database DiskGroups : DG_DATA (Data files), DG_ARCH(Archive logs), DG_REDO(Redo logs Control file).
Snapshot DiskGroups :
Snapshot1 (taken at 9 am): SNAP1_DATA, SNAP1_ARCH, +SNAP1_REDO
Snapshot2 (taken at 10 am): SNAP2_DATA, SNAP2_ARCH, +SNAP2_REDO
Steps performed for point in time recovery:
1. Restore control file from snapshot 2.
     RMAN> RESTORE CONTROLFILE from '+SNAP2_REDO/orcl/CONTROLFILE/Current.256.777398261';
2. For 2nd recovery, reset incarnation of database to snapshot 2 incarnation (Say 2).
3. Catalog data files from snapshot 1.
4. Catalog archive logs from snapshot 2.
5. Perform point in time recovery till given time.
     STARTUP MOUNT;
     RUN {
          SQL "ALTER SESSION SET NLS_DATE_FORMAT = ''dd-mon-yyyy hh24:mi:ss''";
          SET UNTIL TIME "06-mar-2013 09:30:00";
          RESTORE DATABASE;
          RECOVER DATABASE;
          ALTER DATABASE OPEN RESETLOGS;
Results:
Recovery 1: At 10.30 am, I performed first point in time recovery till 9:30 am, it was successful. Database incarnation was raised from *2* to *3*.
Recovery 2: At 11:10 am, I performed another point in time recovery till 9:45 am, while doing it I reset the incarnation of DB to *2*, it failed with following error :-
Starting recover at 28-FEB-13
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 03/06/2013 11:10:57
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
start until time 'MAR 06 2013 09:45:00'
ORA-00283: recovery session canceled due to errors
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '+DG_REDO/orcl/onlinelog/group_1.257.807150859'
ORA-17503: ksfdopn:2 Failed to open file +DG_REDO/orcl/onlinelog/group_1.257.807150859
ORA-15012: ASM file '+DG_REDO/orcl/onlinelog/group_1.257.807150859' does not exist
Doubts:
1. Why did recovery failed 2nd time, but not 1st time and why is RMAN looking for online redo log group_1.257.807150859 in 2nd recovery ?
3. I tried restoring control file from AutoBackup, in that case both 1st and 2nd recovery succeeded.
However for this to work, I always need to keep the AutoBackup feature enabled.
How reliable is control file AutoBackup ? Is there any alternative to using AutoBackup, can I restore control file from snapshot backup only ?
4. If I restore control file from AutoBackup, then from what point of time/SCN does RMAN restores the control file ?
Please help me out in this issue.
Thanks.

992748 wrote:
Hello experts,
I'm little newbie to RMAN recovery. Please help me in these doubts:
1. If I have datafiles, archive logs & control files backup, but current online REDO logs are lost, then can I perform incomplete database recovery ?yes, if you have backups of everything else
2. Till what maximum time/scn can incomplete database recovery be performed ??Assuming the only thing lost is the redo logs, you can recover to the last scn in the last archivelog.
3. What is role of online REDO logs in incomplete database recovery ? They provide the final redo changes - the ones that have not been written to archivelogs
Are they required for incomplete recovery ?It depends on how much incomplete recovery you need to do.
Think of all of your changes as a constant stream of redo information. As a redolog fills, it is copied to archive, then (eventually) reused. over time, your redo stream is in archivelog_1, continuing into archvivelog_2, then to 3, and eventually, when you get to the last archivelog, into the online redo. A recovery will start with the oldest necessary point in the redo stream and continue forward. Whether or not you need the online redo for a PIT recovery depends on how far forward you need to recover.
But you should take every precaution to prevent loss of online redo logs .. starting with having multiple members in each redo group ... and keeping those multiple members on physically separate disks.

Recovery Time of Database

Dear All
I have a database server with the following configuration:
Total Storage :(1.2 Tera Bytes)
Total Tablespace Size (250 GB)
Type of Processor :3.1 GHz
Number of Processor : 2
RAM : 8 GB
I want to setup a backup policy by configuring catalog server and want to take weekly full database backup and daily incremental level 1 backup.(control file auto backup). The database is in archive log mode
Please let me know the possible recovery time of control file, log file and data file in case of database failure from backup
Thanks and Regards,

10g has got very good new features with RMAN, flashback area helps to manage size of your backup location automatically, block change tracking, incremenal backups
some new features
http://www.oracle-base.com/articles/10g/RMANEnhancements10g.php
check this page, has lots of examples you might want to pick one
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10734/rcmbackp.htm#1006452

Questions About Database Recovery (-30975)

Hello,
In Berkeley 4.5.20, we are seeing the following error sporadically, but more frequently than we'd like (which is, to say, not at all): "BerkeleyDbErrno=-30975 - DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery"
This exception is being thrown mostly, if not exclusively, during the environment open call. Still investigating.
I will post my environment below, but first some questions.
1. How often should a database become become corrupt?
2. What are the causes of this corruption? Can they be caused by "chance?" (I.e. app is properly coded.) Can they be caused by improper coding? If so, is there a list of common things to check?
3. Does Oracle expect application developers to create their own recovery handlers, especially for apps that require 100% uptime? E.g. using DB_ENV->set_event_notify or filtering on DB_RUNRECOVERY.
Our environment:
Windows Server 2003 SP2
Berkeley DB 4.5.20
set_verbose(DB_VERB_WAITSFOR, 1);
set_cachesize(0, 65536 * 1024, 1);
set_lg_max(10000000);
set_lk_detect(DB_LOCK_YOUNGEST);
set_timeout(60000000, DB_SET_LOCK_TIMEOUT);
set_timeout(60000000, DB_SET_TXN_TIMEOUT);
set_tx_max(100000);
set_flags(DB_TXN_NOSYNC, 1);
set_flags(DB_LOG_AUTOREMOVE, 1);
set_lk_max_lockers(10000);
set_lk_max_locks(10000);
set_lk_max_objects(10000);
open(sPath, DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL | DB_THREAD | DB_INIT_TXN | DB_RECOVER, 0);
set_pagesize (4096);
u_int32_t dbOpenFlags = DB_CREATE | DB_AUTO_COMMIT;
pDbPrimary->open(NULL, strFile, NULL, DB_HASH, dbOpenFlags, 0);
We also have a number of secondary databases.
One additional piece of information that might be relevant is that the databases where this happens (we have 8 in total managed by our process,) seem to be the two specific databases that at times aren't opened until well after the process is up and running due to the nature of their data. This is to say that 6 of the other databases are normally opened during startup of our service. We are still investigating this to see if this is consistently true.

Here is the output from the error logs (we didn't have this properly set up until now) when this error opening the environment happens:
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley MapViewOfFile: Not enough storage is available to process this command.
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley PANIC: Not enough space
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley DeleteFile: C:\xxxxxxxx\Database\xxxJOB_OAT\__db.003: Access is denied.
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley MapViewOfFile: Not enough storage is available to process this command.
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley PANIC: Not enough space
12/17/2007 17:18:12 (e64/518) 1024: Berkeley Error: CDbBerkeley PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
12/17/2007 17:18:30 (e64/518) 1024: Berkeley Error: CDbBerkeley unable to join the environment
12/17/2007 17:18:30 (e64/518) 1024: Berkeley Error: CDbBerkeley DeleteFile: C:\xxxxxxxx\Database\xxxJOB_OAT\__db.003.del.0547204268: Access is denied.
12/17/2007 17:18:30 (e64/518) 1024: Berkeley Error: CDbBerkeley DeleteFile: C:\xxxxxxxx\Database\xxxJOB_OAT\__db.003: Access is denied.
12/17/2007 17:19:18 (e64/518) 1024: Database EInitialize failed. (C:\xxxxxxxx\Database\xxxJOB_OAT: BerkeleyDbErrno=-30975 - DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery)
The last line is generated by a DbException and was all we were seeing up until now.
I also set_verbose(DB_VERB_RECOVERY, 1) and set_msgcall to the same log file. We get verbose messages on the 1st 7 database files that open successfully, but none from the last one, I assume because they output to set_errcall instead.
There is 67GB of free space on this disk by the way, so not sure what "Not enough space" means.
Thanks again for your help.

Recover database until time - doesn't recover as expected

Hi,
We've got an Oracle 9i db (9208) running on AIX.
We've had a problem and that has meant restoring all the dbf's and control files from the over night backup onto the server replacing the currently corrupted system.
Once this was done we then opened the DB in order to check some things.
Once this was done we then closed and mounted it and issued the "recover database until time .... " command.
The archive logs we need are in the default archive location. They cover the time period just prior to the restored files up until the time we need the DB recovered to.
However, when running the recover the alert log just shows
"ALTER DATABASE RECOVER database until time '2010-08-11:16:30:00'
Mon Aug 16 14:33:57 2010
Media Recovery Start
Media Recovery Not Required"
Can anyone tell us why the recover command isn't recovering the archive log files up until the time we are specifying. It doesn't look like its even looking at them.
The command executes in less than a second.
Is this because we opened the DB between restoring and recovering so its already written a newer archive log file, so the DB thinks its already up to date???

Got it - thanks
Basically cause we were also restoring the control file so when adding the "using backup controlfile" it then started to work.
SQL> recover database until time '2010-08-11:16:30:00' using backup controlfile
ORA-00279: change 276395529 generated at 08/10/2010 21:59:38 needed for thread
1
ORA-00289: suggestion : /archive_logs/tprod/arch0000070260.arc
ORA-00280: change 276395529 for thread 1 is in sequence #70260
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
This was the first message we got once we put the "using backup controlfile" part into the command.
We selected AUTO and its now slowly working through all the archive log files going up the numbers therefore i assume applying the archive logs correctly.
Once this is done i believe we just "alter database open resetlogs"

How to estimate recovery time from rman backup

how to estimate recovery time from rman backup?
The database is of size 800GB.
the approximate time to backup is 8- 10 hours.

"Recovery time" is : RESTORE DATABASE time + RECOVER DATABASE time.
RESTORE can be done
a. in parallel with multiple channels if your backup was created as multiple backupsets
b. using incremental backups
c. whether the backups are on
i. disk
ii. tape
Alternatively, if you have a Recovery Area with an Incrementally Update backup of the database, you can SWITCH DATABASE almost immediately
RECOVER depends on
a. how many archivelogs (in terms of size, not necessarily number) need to be applied
-- this depends on
i. transaction volume
ii. the "freshness" of the backups (how recent the backups are)
b. whether required archivelogs are available on disk (which can be the case if the database backup itself is a very recent backup and archivelogs since then haven't been deleted {whether they have been backed up or not}) OR whether they need to be restored from
i. disk backup
ii. tape backup

Repeated Corruption of Spotlight Database on Time Machine disk?

I'm going to try this here since I don't seem to get much traction with this question in the Time Machine forum, and there is no forum here specific to Spotlight issues in Leopard:
I've been seeing repeated corruption of the Spotlight database on my external, Fireware 800, LaCie drive which is used exclusively for Time Machine. The symptom is that searches done in the Finder window after entering Time Machine produce no results or partial results.
There is no problem with Spotlight on the main hard drive for my laptop.
I received instructions from AppleCare for how to find and delete the hidden folder which makes up the Spotlight database on that drive -- an action which causes Spotlight to immediately rebuild the database on that drive from scratch -- but within days after doing that the database is corrupt again.
An additional symptom is that errors appear in the Console during a reboot -- but only if the Time Machine drive happens to be attached during the reboot. If the drive is attached AFTER booting and logging in, no such errors appear. The errors are from the "mds" process, and indicate either that a portion of the Spotlight database's "Stores" folder is having problems "storing dirty pages", and/or that a portion of the Spotlight database needs to be "recovered". Once those error messages start to appear, they will appear (identically) on every reboot where the drive is attached. No "recovery" happens. And searches after entering Time Machine fail to produce full results as described above.
There are no other Console complaints that appear relevant. No corrupt files during Time Machine backups, no errors when having entered Time Machine to view or restore files, no errors during searches themselves while in Time Machine.
Attempting to rebuild the Spotlight datbase on that drive by dragging it into the System Preferences > Spotlight > Privacy list and then removing it are fruitless. Spotlight indexing fires up for only a couple seconds after removing the disk from Privacy and there is no change in the search failures. And no new error message are entered in the Console. The same thing happens when attempting to use the "mdutil" command from Terminal to force a rebuild (as instructed by AppleCare). Only completely trashing the hidden Spotlight database folder on that drive suffices to get Spotlight to rebuild the database from scratch and start over in a fresh, uncorrupted state. But that doesn't last!
Meanwhile, Time Machine backups themselves are working just fine. No errors -- everything seems to be getting over to the drive -- and viewing within or restoring from Time Machine continues to work without problem. That is, the problem is entirely and ONLY within Spotlight for the Time Machine drive. (Again, that drive is used only for Time Machine.)
And as stated above, Spotlight continues to work without issue on the main hard drive.
Disk Utility > Verify Disk also has no complaints about that Time Machine drive (or the main hard drive)
And the usual panacea cures (booting once in Safe Mode, reset PRAM, reset PCU, Repair Permissions) also have no effect on this problem.
The computer in question was an "upgrade" install from 10.4.10 and has two accounts on it -- a non administrative account for normal work and an Administrator account that is almost never used. Only the one drive, the main hard drive, is being captured by the Time Machine backups. Nothing has been excluded from the Time Machine backups. I've even done a successful "full restore" of the system from that Time Machine. I.e., this is all very plain vanilla stuff. I can't fathom why I'm having this problem.
My Time Machine dates back to after installing 10.5.1. I've tried the process of deleting, and thus recreating, the Spotlight database several times without any luck.
Yesterday, after applying the "Time Machine and Airport Drivers" update to my 10.5.2 system, I decided it was time for a fresh start just in case there was something about the data put onto the drive by the older, 10.5.1, Time Machine that was causing Spotlight such grief.
So I erased the Time Machine drive and did an entirely new initial backup.
That completed without errors.
I then did a few incremental backups on top of that. After which I did a reboot to see if there were any Console error messages from mds. There were none, and my tests of searches while viewing in Time Machine all produced correct and complete results.
So far so good.
However, this morning, after I booted up with the Time Machine drive attached, I went immediately into Console and found the dreaded error messages from the mds process. And sure enough my searches inside of Time Machine now only produce partial results again. Here are the two messages I'm getting at the moment (with personal information "xxx"d out):
3/20/08 1:48:48 PM mds[26] (/Volumes/xxxxx Time Machine/.Spotlight-V100/Store-V1/Stores/4CE0F19E-8757-43F1-A5DD-06B1DCAD0E50)(E rror) IndexStore in SIStoreDirytySDBChunks:Error storing dirty sdb pages: 30
3/20/08 1:48:48 PM mds[26] (/Volumes/xxxxx Time Machine/.Spotlight-V100/Store-V1/Stores/ABE285E8-4E3D-45BD-A3EF-D9A5B4A149DA)(E rror) IndexStore in SIStoreDirytySDBChunks:Error storing dirty sdb pages: 30
So far I have NOT yet seen the messages saying that the Spotlight database "needs recovery".
I'm at a loss on this one. Again, the Time Machine backups themselves seem to be fully complete and fully functional. And Spotlight was perfectly happy after the new, initial backup, and a few incremental backups.
But I just can't get Spotlight to STAY happy with this Time Machine drive.
Any suggestions?
--Bob

OK I've completed the repartitioning test and the results are unexpected! Here's what I did and what I've spotted so far:
First, the only differences between what I'm going to list here and what I've done before is the repartitioning of the drive and the fact that I decided to do things this time entirely while logged in to my Administrator account. In the past, I did this stuff logged into my "standard" account and supplying Admin passwords when requested:
@ Rebooted with the drive attached and logged in to Admin
@ In System Preferences > Time Machine, did a Change Disk to No Disk to turn off Time Machine backups.
Note: In what follows, each of the several times Time Machine asked me if I wanted to use the external drive as the new Time Machine drive I selected "Cancel".
@ Used Disk Utility to re-partition the Time Machine drive into 2 untitled partitions (Apple Partition Map since this is a Powerbook Mac, Mac OS X Extended (Journalled) formatting, Mac OS 9 drivers turned off). I then partitioned it AGAIN back to 1 partition titled as my Time Machine drive (same settings). I did this two step process to make SURE the partitioning data was actually being re-written.
@ Used Disk Utility to Erase the single partition just created -- using the option to Write 0's to the drive to make sure all of the drive was exercised.
@ Checked and found the Time Machine volume was now identified as disk1s3.
@ Used Disk Utility to Verify Disk on my main hard drive.
@ Checked in Console after all of this and there were no I/O or other errors logged.
The next few steps were done to maximize the chances that my new "initial backup" would be as clean as possible.
@ Shut Down the computer and rebooted once into Safe Mode to let the Safe Mode boot delete caches and do its other background maintenance tasks. Shut Down immediately from the Safe Mode login window instead of logging in.
@ Rebooted while resetting PRAM. Just because.
@ Logged in as Admin, and used Disk Utility to Repair Permissions on the main hard drive. No messages were generated by this.
@ Rebooted once again and logged back in as Admin to get things into a fresh state.
At this point I was now ready to start the new, Time Machine "initial backup". However before I did that I decided to check the Console one more time.
Imagine my surprise when I found one each of the two Spotlight related error messages I reported above! There was one "needs recovery" error and one error trying to "store dirty pages"! (Note that normally I see TWO of each of these.)
Keep in mind that the drive had just been freshly partitioned and then erased again. Time Machine had never been given access to the drive. And no other user applications had been run. And yet the Spotlight database was ALREADY generating errors on that drive!
Upon checking further, I discovered that the first pair of these error messages was generated during the Safe Mode boot above. They were generated again during the boot where I reset PRAM.
BUT, there were NO ERROR MESSAGES in the most recent reboot I had just completed!
At this point I decided to do a 2 more reboots and there were NO ERROR MESSAGES in either of those.
Curious indeed! Well perhaps some sort of recovery had happened.
In any event, at this point I decide to do the "initial backup".
@ In System Preferences > Time Machine, I selected the drive for Time Machine use and let the initial backup complete. I also had Console running during this. The backup completed without any significant messages. In fact one additional incremental backup also completed without errors before I noticed it was done.
At this point, I entered Time Machine and tried my usual test searches which have demonstrated the Spotlight corruption in the past, and there were no problems. Spotlight was apparently good.
I then rebooted and checked the Console and son of a gun but the Spotlight error messages were back -- this time 2 of each.
However, when I checked searches in Time Machine -- THEY WORKED! This is the first time I've ever seen a case where the presence of those error messages during reboot wasn't accompanied by search failures inside of Time Machine.
I immediately did another reboot -- AND NO ERROR MESSAGES!
I've since done several additional incremental backups and several reboots, and I can't find a pattern anymore. The error messages OFTEN appear on reboot (if the Time Machine drive is attached), but not ALWAYS as was the case in the past. And up to now searches inside of Time Machine are working without problems.
I can see several possible explanations:
1) The error messages are spurious (or there is some sort of automatic recovery that is working now when it didn't work before) and the repartitioning above actually fixed the problem.
2) The database is indeed corrupted, but the corruption has moved to a portion of the database that my test searches aren't exercising.
3) I need to do more incremental backups before the database corruption will actually become visible in my test searches. I.e., the problem just hasn't had time to develop yet.
Meanwhile I heard back from LaCie support that they have not heard of a problem like this for Time Machine or Spotlight on this particular drive. I've also pointed them at this thread for details.
So I'll just continue to use this Mac normally over the next few days, while periodically checking to see if the Spotlight search failures reappear and to see if I can spot any pattern as to why those Console error messages sometimes appear on reboot and sometimes not.
I'll report back when I have more info.
Again, if anyone has any insight into what those 2 Console error messages actually mean, or if anyone else is seeing those error messages, or is having Spotlight search failures when inside Time Machine whether or not you see those error messages, please chime in.
--Bob

Object Level Recovery or Whole Database recovery

I'm hoping someone may know how to advise me on the following;
On a datawarehouse db (10.2.0.1.0) a team member removed records from three tables, and I have since attempted flashback recovery without success. The database is in Archivelog mode, with Flashback enabled, but no Flashback logging enabled. The rows were removed on Friday afternoon (it is now Monday). I attempted to get flashback logging enabled by tagging the "Enable Flashback Database" tag in the Flash Recovery region of Recovery settings, and restarting the database. The database when restarted went into mount state, and subsequently on restarting (from mount - I did not dismount the db), it still has Flashback logging disabled. I attempted flashback again but the team member states the record stil arn't there. EM however had given the message 'The select tables...X X....have been flashed back'. However I can see also that Em says flashback logging is still disabled.
I now consider I might be better off to perform a 'Whole Database Recovery', as I simply want to get the tables recovered. I'm not sure if this will mean re-keying though. Can anyone advise? Thanks in advance. DW
Message was edited by:
David_W

The first step you should try is flashback query. Because using flashback query your database will remain intact, you don't lose anything from your database. Of course most likely it's too late for you now. Just for future reference.
Flashback database is only available after you configured Flash Recovery Area and turn it on. Sound like it's does apply here as well. Remember even you could successful flashback your database to the point before deletion, you will lost all data changes after that point. Flashback database only buy you sometime, because you don't need to restore datafile from backup.
The third option would be restore from your last backup, ( the latest one before deletion happen) and do incomplete restore to the point in time right before the incident.

Database Recovery Scripts

Does anyone have a set of database recovery scripts for various scenarios for 8i and 9i databases running on Windows 2000 and 2003?
Cheers,
Derek.

>>
We do a cold backup each night and have archive on. The scenarios are any that may occur i.e., media failure, dropped tables, lost control files etc.
>>
Hey Derek, the problem with cold backup is incase of media recovery required, you can't simply resotre the datafile/s which have/has problems. You need to restore complete database.
Its difficult to have incomplete reocvery or point-in-time recovery having cold backups.
I strongly recommend you start thinking about online backups. You need to assess your business requirements, and much you can efforts to loose?
jaffar

Alternative solutions to reduce recovery times ?

Currently recovery times are excessively long when needing to restore an individual mailbox or messages. If for example wanted to restore a particular folder or review the contents of a backup would currently restore mailbox to a temp database and
replay logs. Some of the mailboxes are very large.
What is recommended backup/recovery solution when it comes to Exchange 2010 ? also are there any 3rd party tools which allow you to view the contents of the backup without needing to restore the database ?
Thanks in advance.

1. Yes if you had the capacity you could store the backups on disk for rapid granular recovery. Its a balance between convenience, time and resources.
2. I would say most people deal with it via the method provided via their backup provider or by restoring EDB's on an as needed basis and using the MS Recovery Database method.
3. So if you drill down into the foundation of this all granular recoveries require access to the native EDB that was backed up OR the granular data backup set. i.e. the entire data set explicitly or by way of automation process that data MUST get restored
to disk first and then the needed data gets extracted from that copy. Of course you could use the Brick Level backup method if you can find a vendor that still uses that but I wouldn't recommend because well in short it just sucks.
3.A: However as stated in my post above the Single Item Recovery method might be just the thing to eliminate this issue for a large # of cases, i.e. lets say most of your restores happen within a 90 day window of the data being created. If you turned
on SIR it would take more space but you would have all the data available for restoration and then for the outliers you just use the normal restore the DB to disk first and then recover
4. Logically you are probably thinking why can i not just open the Backup and extract what I want. Well the short answer is because when an EDB is backed up its in a dirty state ( Uncommitted logs) so in order to OPEN that EDB and get access to the
data you must first restore the EDB and logs and then commit them to the DB. If that happened in place the EDB would not be exactly what you backed up, i.e. you would be modifying the backed up files hence the reason they restore the EDB and Logs first
so that you are only working with a copy. That said IF a backup provider wanted to allow for this there are methods to make it happen for example A": Create a virtual rollup system that allows you access to the source files but when done throws
away all changes i.e. log commits etc so that the source file remains pristine. or B: allow for a tool like our DigiScope product to access the files without bringing them into a mountable state, i.e. no log commit when being accessed. We have
a function called forensic mount that allows this which works great if you don't have the logs or you want to not modify the original DB by applying logs. All that aside the vendor would have to open that up for us to do and alas their is no value
or reason for them to do so. Oh and also because none of the backup providers have a True EDB reader like DigiScope, Kroll or Quest (top 3 EDB tools). If they developed or licensed that technology they could make it happen
Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline Exchange Mailbox and Public Folder EDB's and Live Exchange Servers or Import/Migrate direct from Offline EDB to Any Production Exchange Server, even cross version i.e. 2003
--> 2007 --> 2010 --> 2013 with Lucid8's
DigiScope

Incomplete Database Recovery

Can anyone help me how to do a Incomplete recovery database recovery (Change/Time/Cancel) based.
I tried by looking documentation , but always I end up with error.
Many Thanks
-Prabhu

Hi,
Would you please post what you do and what error you have?
Michel

Sub minute recovery time?

Has anybody heard about a high availability solution for SAP on SQLServer which allows recovery times under 1 minute?
I know SAP does not certify high availability solutions from partners, so I think this has to be a hardware solution from a SAP partner (HP, IBM, etc.).
As I know, every HA solution would need some kind of failover for database engine and SCS. Database failover will took always about tens of minutes.
I will appreciate any guidance.

We have SQL 2008 (Release Candidate 0) Mirroring in place (same as SQL 2005, but SQL 2005 is more stable of course, since it is a released product). Our mirroring mode is synchronous with automatic failover.
At SAP level, we have setup database mirroring via supported methods. Just modify the database reference in your profiles, from a single database name to:
SAPDBHOST = primarydbserver;Failover_Partner=secondarydbserver
In event of db failure, at the DB level it takes less than 5 seconds to failover. SAP work processes will error but will be successful during reconnect. Average failover takes less than 1 minute from my experiences.
If you are looking for sub 1 min recovery, do not, I repeat - do not use MSCS. Fastest I have ever seen any MSCS recover is around 5 minutes. MSCS is affected by IPSEC, network name replication, etc. Because the name is moved from 1 physical server to another.
For SQL mirroring, there are no name changes, SAP simply point to another server.

Is it possible to copy the same database multiple times simultaneously?

This is the setup of my environment.
I have a 'master' database that contains the full schema plus some pre-populated data such as default settings. When database schema changes are made, they get made to the master database. When a new customer signs up for the service, I make a copy of this
master database (using SMO) that will now be the database containing all of the customer's information. The database is rather large, and the copy operation can take a couple minutes.
Everything works fine as expected, unless I try to provision two new customers at the same time. It appears that Azure only allows for one DB copy operation at a time. Is there a way to allow for copying the same database multiple times simultaneously?
Thanks for you input. I understand that this is likely not the optimal setup, and that there is many better ways of doing this, but I am somewhat heavily invested in the current process and I would like to find out how to make it work if I can.

BTW, you can do this programatically by using PowerShell (https://msdn.microsoft.com/en-us/library/ee210569.aspx), SqlPackage (http://www.benday.com/2012/12/18/deploy-a-sql-server-database-projects-dacpac-with-sqlpackage-exe/)
or the SQL Server binaries for .NET (http://www.vijayt.com/Post/Deploying-a-data-tier-application-in-SQL-Azure-programatically)
Hope this helps.
Alex

IPhoto needs to be upgraded everytime I open it. Then it finds consistences. I have rebuilt the database many times

iPhoto needs to be upgraded everytime I open it. Then it finds consistences. Then it repairs the database.
I have also rebuilt the database many times useing command + alt.
Now it shows every event three times. If I delete one version of that event, it deletes them all.
Then next time I open iPhoto it needs updateing and repairing again
I have used disk utility to repair permissions

Download iPhoto Library Manager and use its rebuild function. This will create a new library based on data in the albumdata.xml file. Not everything will be brought over - no slideshows, books or calendars, for instance - but it should get all your albums and keywords back.
Because this process creates an entirely new library and leaves your old one untouched, it is non-destructive, and if you're not happy with the results you can simply return to your old one.

Database recovery in Inconsistent mode

Hi,
We have mirroring at 24:00 on one of the mount point in Solaris which copy all oracle datafiles,redo files and control files and create a replica of all these files in a separate folder. But my database is running in NOARCHIVELOG mode.I am assuming it would be an inconsistent backup.
I am wondering if in case of any failure can we recover with these replica files created on 24:00.
My query is if the database is in NOARCHIVELOG mode, Can we use the command "recover database until time" and recover database till 23:55.
Thanks,
Vaibhav

user10624526 wrote:
Hi,
We have mirroring at 24:00 on one of the mount point in Solaris which copy all oracle datafiles,redo files and control files and create a replica of all these files in a separate folder. But my database is running in NOARCHIVELOG mode.I am assuming it would be an inconsistent backup.
I am wondering if in case of any failure can we recover with these replica files created on 24:00.
My query is if the database is in NOARCHIVELOG mode, Can we use the command "recover database until time" and recover database till 23:55.
Thanks,
Vaibhavno & no
For you to obtain a consistent backup, the DB must first be cleanly shutdown.
Consider changing into ARCHIVE MODE

Database Recovery Time

Similar Messages

Maybe you are looking for