How can I ROLLBACK my database to specific date or point without create a ROLLBACK point?
If you are using Flashback technology you can do it OR using old backup,
Else you couldn't rollback.
Related
Background: hard-drive died in existing Oracle12cR2 server but I was able to recover all the previous tablespaces from backup, including SYSTEM01.DBF and USERS01.DBF. I created a new Oracle 12cR2 database server, and would like to know if I can recover any of the data in the tablespaces?
Thanks.
if you have oracle running in archive log mode and have a recent backup complete with all archives until the crash: yes you can. After that you can use various methods to move the data to the new database.
My question that remains is: why move it to an other database when you were able to recover the original one? The recovered database is as good as (or even better) than the new one.
Yesterday, I made some migrations to a website that I had to rollback. Luckily, I had a backup of the database, and was able to restore the lead database to a "good" state using Heroku's pg:backup:restore facility.
The lead database is followed by another database. Does the follower also get "restored" when I restore the lead? Will it contain the same data as the leader?
You can't rollback an existing database. When you use the rollback functionality you're actually forking the targeted database and thereby creating an entirely new database without any followers. If you need to do this operation for your primary database, you'll need to put the application maintenance mode before creating the rollback database, promote it to primary and then recreate the any followers.
We are using Oracle 12c in production. Lets say there was release that went to production on Sunday and then some hours or some days later(e.g. Tuesday) we realized that we need to rollback the changes we did, assume there were DDL schema changes, along with DML changes which could be inserts, updates, deletes.
What is the best practice to rollback the changes? we can not restore database from backup because backup was from Sunday and there is data from Sunday to lets say Tuesday.
Just want to know what is the best practice for rolling back database changes in Oracle 12c.
When you are making a rollout to Production, the best technique to go back is FLASHBACK DATABASE.
You can read more here
https://docs.oracle.com/database/121/SQLRF/statements_9012.htm#SQLRF01801
The idea is to create a restore point flashback guarantee that you can go back to just by running a restore command
create restore point my_save_point guarantee flashback database;
Then you do your changes, you verify whatever you want to verify and if you need to rollback you just run
flashback database to restore point my_save_point ;
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 need to do a database migration from Oracle 11g to 12c. But I cannot do a direct export and import kind
of a migration since there are a lot of schema changes which are going to happen. I already have the column mappings
in a sparedsheet with old columns and new columns with all details such as data type, constraints, etc.
There are new columns added to many tables are the default values that should be populated are also known.
So what should be the best approach to do this migration?
There are more ways to do this. Start with getting a dba involved.
To minimize production downtime, you could check if making a logical standby database is feasible in your situation. In that case, make the target database a 12c one, that saves for upgrade time.This target database is in sync with the source database at all times and makes it very valuable. Clone the target database and use that clone to test the migration steps. If the migration fails, you can easily re create a new clone to correct the migration process on.
Working in this way could even enable bi-directional replication, replication from the migrated database back to the source database that could make it possible to revert to the original database in the unlikely event that after production start on the new database things don't work as expected.
Start with adding a dba to the project, a good dba can help minimize downtime and reduce risk.