created db with dbca choosing asm, fast recovery area, archived mode.
Now I want to backup it preform some tests that would change the content of the db and If need comes then recover it from the backup.
I know of export/import utilities but need to use rman in case I need to move the db.
I followed the following tutorial with some caveats with most of the commands succeeding:
https://www.thegeekstuff.com/2013/08/oracle-rman-backup/
https://www.thegeekstuff.com/2014/11/oracle-rman-restore/
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
SQL> SHUTDOWN
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM "+DG1/<DB_NAME>/CONTROLFILE/CURRENT.<3_DIGIT_NUMBER>.<10_DIGIT_NUMBER>"
(before one of these commands) mounted the db with SQL> STARTUP MOUNT because needed exclusive type
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;
*last one didn't run successfully, outputted that only if badly recovered can be run
the change I've made to check the backup and recovery, was droping a table on one occurrence and inserting a record in another.
the problem is after checking the db didnt change to its previous state.
"only if badly recovered can be run" is not a known error message.
NOthing changed, because you didn't put a limitation on the 'recover' step. So it recovered right back through all the online redo - right back to where it was an instant before you shut it down to do the restore/recover. You need to look at the SET UNTIL command in the rman manuals. SET UNTIL a point in time or scn prior to when you did the activity that you expected to be gone after the restore/recover.
This is exactly as expected, and exactly what you would do in case of a disaster recovery where you do not want any data loss. In your case you do not want complete recovery, but a Point In Time (PIT) recovery.
Related
This question is almost exaclty like
oracle rman simple backup
but there isn't an acceptable answer there, and this question is about 11g. So I'll ask:
I'd like to do some table initialization DDL tests on an oracle shema, and I'd like to revert the database to the prior-test state between runs. I'm executing the following in RMAN:
shutdown immediate;
startup mount
backup database;
sql 'alter database open';
As I see it works fine, list backup shows backups.
Than I made some modifications (Added some users, added some tables, adding data) and I tried to restore backup:
shutdown immediate;
startup mount
restore database;
recover database;
sql 'alter database open resetlogs';
Expected result: the database should be restored to the exact state as to when the initial backup was taken.
Actual result: all the new tables and users I created in my test DDL continue to exist. I verified this by closing connections, restarting sessions, and then even selecting from the tables! The tables still exist even after the restore!
What is the deal with this? In MSSQL and Postgres, a backup means you save the state of the db, and restoring it means you go back to when the backup was. But in RMAN for oracle 11g, it 'claims' the restore was successful, but the evidence clearly shows otherwise.
How can I get oracle to save the state of the database exactly as it is, and then make changes, and when I restore, i want the database to be exactly as it was when I backed it up?
Is this possible in Oracle?
Yes it is possible - you have several options:
create a cold backup of the database (datafiles, controlfiles, online redo logs) and then to restore them when it is necessary
Perform so called "point in time recovery" (assuming your DB is in archivelog mode). Take DB backup with RMAN note the "time" or "SCN" or "archivelog sequence" after a while you can restore DB and recover until previous noted time/SCN/LOG SEQUENCE
Special designed by Oracle for this purposes and I recommend it in your case "Flashback Database" (brows Oracle docs to see what this is).
Oracle always "try" to restore/recover your database up to last committed transaction if it is possible, that is why you get the result you described above, but if you want to restore up to specific time/SCN/SEQUENCE just tell Oracle about this :)
I've just started a job and have identified an issue in which the database isn't currently being backed up properly so to speak. We are doing one back up every 6 hours that uses the Oracle native backup utility, but we were also sold a process by a company in which they stated that they could in essence perform "warm" backups of our database by simply taking file system copies of our database files and when we needed to restore we'd simply shut down Oracle and then copy over the files that had been copied, restart Oracle and the world would be whole again. The challenge is the fact that we have not gotten this to work just yet. I need to spend some more time reviewing the message that Oracle is giving, but my primary question is, "Is it possible" to take copies of Oracle files while Oracle is still running and to use those files at a later date to restore the database? I know that it works if the database is shut down, and then copies are made, but this is the first that I've heard that a copy (file system) can be made while the database is running. Any guidance would be greatly appreciated. Here is the error that we are getting.
ORA-00314: log 3 of thread 1, expected sequence# 1939 doesn't match 1944
ORA-00312: online log 3 thread 1: 'E:\ORACLE\ORADATA\ITMS\REDO03.LOG'
Yes, it is possible, but you have to put all the tablespaces into backup mode first and take them out afterwards (e.g. ALTER TABLESPACE x BEGIN BACKUP and ALTER TABLESPACE x END BACKUP; you'll need to check the syntax and make sure it's appropriate for your situation!). Oversimplifying hugely, this tells Oracle not to write to any of the data files, so they're all kept in a consistent state.
The two main problems you get otherwise are that individual files are updated while you're copying them so a single file can be corrupted; and more visibly that different files have different internal timestamps and sequences so Oracle won't allow them to be used.
If you're using a process you've bought in then it should already be taking care of all that though. It sounds the backup is OK and it's the restore that you haven't got working.
I haven't been involved in a restore from a hot backup for some time so someone else will need to give the detail on the actual error. My read of it is that you've tried to open with the restored data files but the later live redo logs. When restoring I think you either have to RECOVER the database using the redo logs generated since the backup was taken; or if you're trying to restore to that point in time then you can open the data with the RESETLOGS directive and lose all the changes from all the redo logs that came later. But really take more informed advice than this...
As far as I know, there are two ways that you can "copy" datafiles from a running Oracle instance.
The datafiles are copied for a
tablespace when the tablespace is in
"BEGIN BACKUP" mode.
You are using a high-end journalling
filesystem such as Veritas that can
snapshot and track block
changes on the filesystem while the
copy is taking place.
It is possible. You must must be in ARCHIVELOG mode.
An example script would be for manual:
Alter tablespace USERS begin backup;
host cp -p /u02/oradata/PROD/users01.dbf /u03/backup/PROD/
host cp -p /u02/oradata/PROD/users02.dbf /u03/backup/PROD/
Alter tablespace USERS end backup;
However, I would recommend just using RMAN. RMAN is QUITE ROBUST, included free, and will do the hot backup, as well as cold. It will clone to another instance, clone as a point in time, recover to a certain point in time, etc. Any manual backup procedure should be migrated to using the RMAN.
If you wanted to backup the entire database while it is open (I prefer as Oracle with DBA so you can avoid passwords in scripts, but ymmv):
$ ORAENV_ASK=NO
$ ORACLE_SID=PROD
$ . oraenv
$ rman target=/
Recovery Manager: Release 10.2.0.4.0 - Production on Thu Oct 28 14:23:29 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: PROD (DBID=x)
RMAN> backup as compressed backupset database plus archivelog;
...
Backup Complete.
I've effectively done this with a non-mission-critical database running on Amazon EC2. My backup strategy is to periodically take a snapshot of the EBS volume. To restore a backup, I create a new EBS volume from the snapshot, start up the instance using it, then run RECOVER DATABASE.
This loses any transactions that were in-flight at the time when the snapshot was taken, of course.
I would like to backup an Oracle 10G as simple as possible.
It is in NOARCHIVELOG mode and I can shut down for backup (it is only a development server).
After reading tons of documentation abour rman I tried this way in rman:
shutdown immediate;
startup mount
backup database;
sql 'alter database open';
As I see it works fine, list backup shows backups.
Than I made some modifications (droping some tables, adding data) and I tried to restore backup:
shutdown immediate;
startup mount
restore database;
recover database;
sql 'alter database open';
It also seems to work fine but I can't get back the previous state of the database. I don't understand why. I also don't understand why need to use recover.
Thanks
Hubidubi
The "restore database;" command will read the backup from the backup media media so that your database files are exactly like they were when the last backup was taken. It does not restore control files.
The "recover database;" command will apply incremental backups (not applicable - your example only has a full backup) and apply archive logs (also not applicable, you're in "NOARCHIVELOG" mode.) It may also write to the control files - if it does, you can see why it's required.
After the restore/recover/open commands you issued in your question your database is as it was at the time of the backup. Any transactions committed after the backup are lost and can't be recovered because you're in "NOARCHIVELOG" mode. You need to be in "ARCHIVELOG" mode to do a complete "point in time" recovery.
byw, what files, if any did you delete, rename or move to really simulate a true media failure? I'll bet you didn't delete one of your control files. You need to practice that scenario.
I'm currently using Oracle db11g on Red Hat Enterprise Linux 5.0.
I make an incremental level 0 one time a week and incremental level 1 everyday.
I can restore this backup on my new Linux server without any problems because I have all archive logs generated after level 1 backup.
However, if online redo log is not yet filled (I mean that I have some redo info in the online log), how can I use this online log to roll forward to my restored database on the new Linux server?
I don't want to lose the valuable information that is not yet archived.
Best regards,
Sarith
Restore your backed up files.
Copy your current online redo log files (from the "damaged" production instance) to the new server.
RECOVER DATABASE;
This scenario assumes you have total continuity with archived logs and online logs. In doing the recovery, Oracle will apply necessary archived redo, then move to the online redo logs to recover to the point of failure. Important! Don't restore online redo logs from the backup you have! Use the current online logs from your crashed instance.
Finally, don't believe anything you read without practicing it for yourself!
Yes you can use the unarchived logs - if you applying the archive logs via "recover database using backup controlfile", just supply the redo log name instead of the suggested archive log name that the recovery process provides when it comes to that point (i.e. "runs out" of archive logs).
So you mean you duplicate the database to another server using RMAN?
Online redo logs are only used for disaster recovery. For instance : you lose a datafile, restore the datafile from your latest backup, and apply archivelogs and finaly the online redo logs. This makes the restored datafile have the same SCN (System change number) as the controlfile (and other datafiles). Distaster recovery complete.
When you use your backups to duplicate the database on another server you can only roll forward using your archived logs. It does a incomplete recovery by defenition (creates a new controlfile and redologs).
Do a
SQL> Alter system switch logfile
before backup?
But no matter what restore is behind the source database if it stays open. I don't now your business case exactly but DataGuard might be an option for you.
Rob
I want to restore and recover my oracle database to the current state.
For example, I have a full backup on Sunday and I have all archive logs from Sunday to Wednesday.
If I restore and recover from backup to the new host, my database is in the state of Sunday only.
How can I apply all archive logs I have to recover my database to the state of Wednesday?
Do I need controlfile autobackup on Sunday or the current one on Wednesday?
Please give me steps to do this.
Regards, Sarith
Restore the full backup to the new server and all the new archive log files that you want to restore.
See note: 161742.1 (How To Roll Forward The Database Using a Old Control File, With Archivfiles) in metalink for a complete guide but I'm going to paraphrase it.
If you do not have access to metalink then here is the text from that note abreviated:
start db in mount mode
SQLPLUS> startup mount
Issue the command to start the recovery and apply all the archivelog files that are newer than the control/datafiles restored.
SQLPLUS> alter database recover until cancel using backup controlfile;
use this command to continue until you run out of archivelog to apply.
SQLPLUS> alter database recover continue default;
when you run out of archivelogs to apply
stop the recovery and open the database with reset logs.
SQLPLUS> alter database recover cancel;
SQLPLUS> alter database open resetlogs;
its important to take a new backup now as old archive logs will not be able to be used with this db since you've reset the logs.
As stated by the other poster, read the backup recovery manual for more info.
You haven't said what version of oracle you are using, the version you are using, and the backup strategy you have in place will effect how exactly you recover.
You need to read and understand the Backup and Recovery Manual
If this is actually a production issue, then you need to contact Oracle support right now, this isn't the time to make mistakes or learn on the job.