1 2 Previous Next 17 Replies Latest reply on Mar 26, 2013 4:05 PM by marksmithusa Go to original post
      • 15. Re: Flashback Database Scenario
        So in your opinion, in what kind of use case will we be better of by using flashback database?
        Justin already answered that for you.
        Use Flashback Database in your production environment as a replacement for traditional point-in-time media recovery, when physical corruption is not the issue
        It will be quicker than doing point-in-time recovery using the logs and backups since the needed files are readily available.
        • 16. Re: Flashback Database Scenario
          Justin Mungal wrote:
          As SB mentioned, Flashback Database requires downtime. When troubleshooting individual transactions in production, such as a job gone awry, you would be better off making use of Flashback Technology that operates at the logical level, which use UNDO as opposed to flashback logs. Please study the following carefully.

          Use Flashback Database in your production environment as a replacement for traditional point-in-time media recovery, when physical corruption is not the issue (see http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmflash.htm#BGBDCAFA for more information on this). Flashback Database can be preferable to traditional media recovery because it does not restore the entire database, rather, it rewinds changes that have been made to it.

          You can also use LogMiner to analyze changes made to the database. It's easier to use than you might expect.

          Think of it this way: Flashback Database is drastic, and is designed as a potential alternative to media recovery. It rewinds the entire database and requires downtime. Flashback Technology such Flashback Transaction or Flashback Query let you analyze and make changes at the object/transaction level, and are designed to assist you in troubleshooting and reversing erroneous changes made to the database. There may be times when Flashback Database is necessary, but consider alternative options first. I hope this clears things up for you slightly.
          good explanation Justin.... :)
          • 17. Re: Flashback Database Scenario
            rp0428 wrote:
            Main objective is to show that in using Flashback Database, the DBA has great flexibility and control over in determine the best Point-in-Time recovery.
            No - Flashback is AN ALTERNATIVE to using point-in-time recovery.
            Secondary objective is to show that Flashback Database can be used to determine the time of error occurred.
            No - Flashback won't determine anything at all. YOU have to determine if there was an error and, if so, what time the error occured. Flashback can assist you by giving you more efficient access to the entire database from a previous savepoint or point-in-time.

            We have only ever used FLASHBACK DATABASE during testing where we can make a change and run the EXACT same workload through, capture various metrics and decide whether or not to keep the change.

            We have FLASHBACK DATABASE enabled but have never used it as a recovery tool for a Production database. It is the equivalent of performing a restore, it just might be faster (depending on your backup methods) than restoring from a backup.

            There are no guarantees with the flashback_retention_target either. It is simply a target and not enforced. The determining factor is disk space. The only way you can guarantee the ability to move back to a PiT is to use guaranteed restore points. We use these whenever we're upgrading the Production database, testing Data Guard, etc.

            FLASHBACK DATABASE is a decision with the same magnitude and consequence of a database restore. It just might help out if you do find yourself in that unfortunate situation.
            1 2 Previous Next