|
Re: RMAN Backup and Restore (Full) [message #306322 is a reply to message #306319] |
Thu, 13 March 2008 11:55 |
|
ebrian
Messages: 2794 Registered: April 2006
|
Senior Member |
|
|
Your restore basically played back the drop table command. If you are on 10g, you can do a FLASHBACK TABLE and/or if on 10g and below, you can do a Point-in-time recovery.
Sorry, just noticed you are on 11g. The same holds true for 10g & 11g, however, 11g may have additional features. I haven't had a chance to do B&R with 11g yet.
[Updated on: Thu, 13 March 2008 11:56] Report message to a moderator
|
|
|
|
|
|
|
Re: RMAN Backup and Restore (Full) [message #306487 is a reply to message #306468] |
Fri, 14 March 2008 08:45 |
Catscratch
Messages: 10 Registered: March 2008
|
Junior Member |
|
|
At first: Thanks for your patience.
ebrian wrote on Fri, 14 March 2008 07:22 | YEP...and
RMAN performed exactly as it should.
|
Yeah, I think so.
ebrian wrote on Fri, 14 March 2008 07:22 |
As I mentioned above, the drop table action you performed BEFORE the restore was replayed with the RESTORE. For example, you dropped the table at 10:00am and do the restore at 11:00am, then without a point-in-time recovery, RMAN is going to replay all the database actions that occurred up till 11:00am and therefore, the drop table will get replayed.
|
Ok, I understand this. But why RMAn don't only use my backupfile? For example, I created the fullbackupfile at 9:00am and drop the table at 10:00am. Then at 11:00am I want to restore die backupfile from 9:00am. But RMAN restores all the data until 11:00am. But it only should use my backupfile. With point-in-time recovery I have to specify a timepoint. But I don't know when the backupfile was created. Ok, I could read the file information like creation date and so on, but is there a way to tell rman only to use this one backupfile?
If RMAN restores all the data until 11:00am, so it stores backupinformation otherwhere too (not in my backupfile). RMAN shouldn't use this additional information.
I want to realize something like the MySQLDump function where I can create a full dump. Later I can set the complete database to the state of a given dump. There I don't have to specify a timepoint. I only use the mysqldump function and the dumpfile as parameter and the result is the database which was frozen in the dumpfile.
[Updated on: Fri, 14 March 2008 08:46] Report message to a moderator
|
|
|
Re: RMAN Backup and Restore (Full) [message #306502 is a reply to message #306487] |
Fri, 14 March 2008 09:00 |
|
ebrian
Messages: 2794 Registered: April 2006
|
Senior Member |
|
|
Catscratch wrote on Fri, 14 March 2008 09:45 |
Ok, I understand this. But why RMAn don't only use my backupfile? For example, I created the fullbackupfile at 9:00am and drop the table at 10:00am. Then at 11:00am I want to restore die backupfile from 9:00am. But RMAN restores all the data until 11:00am. But it only should use my backupfile. With point-in-time recovery I have to specify a timepoint. But I don't know when the backupfile was created. Ok, I could read the file information like creation date and so on, but is there a way to tell rman only to use this one backupfile?
|
That would be a point-in-time recovery and if you do this, you'll essentially be rolling back the whole database to recover the one dropped table. An alternative would be to do a point-in-time recovery on another system (auxiliary database) and export the table and then import the table in the primary database.
Catscratch wrote on Fri, 14 March 2008 09:45 |
If RMAN restores all the data until 11:00am, so it stores backupinformation otherwhere too (not in my backupfile). RMAN shouldn't use this additional information.
I want to realize something like the MySQLDump function where I can create a full dump. Later I can set the complete database to the state of a given dump. There I don't have to specify a timepoint. I only use the mysqldump function and the dumpfile as parameter and the result is the database which was frozen in the dumpfile.
|
Without doing a point-in-time recovery, RMAN is going to utilize the archive & redo logs to bring the database current. For a logical "backup" of your database, you can consider doing an export. An export can be configured to provide you a consistent snapshot of your database at particular time. An export should really only be used as a supplement to a physical backup of your database.
|
|
|
|
|
|