What do you mean?
This prod db that I have is like a "hub" with data coming from multiple sources for user to query. It also have a fair share of procedures and packages that are scheduled to run throughout the day.
3) I, supposed to be the saviour, shutdown immediateAfter SHUTDOWN DATABASE, no new orders can be entered, no inventory records updated & no customers billed; which is an excellent way to get yourself fired for stopping every business activity required by the business to stay in business.
moslee wrote:& flawed Quality Assurance group that allows bugs into Production.
No, this prod db that I'm talking about is not the main db that deals directly with business activity. Business activity are handled by multiple sources of db. This one with Flashback Database on is more for reporting purpose, but it has a fair share of procedures/packages, scheduled jobs.
moslee wrote:above approch is fair enough....to recover database as per your requirement...but fix your code error ( *new release of procedure).....and test it 1st in test environment ..then run in prod..
Hi to all
Just want to hear from you guys if Flashback Database can be used in the following scenario. 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. Secondary objective is to show that Flashback Database can be used to determine the time of error occurred. Let me know if I can use Flashback Database to fulfill these 2 objectives. Thanks for your feedbacks!
db_recovery_file_dest_size big integer 20G
1) Logical data corruptions reported to occur in DB at about *1455*.
2) DBA ABC feedbacks suspecting that scheduled job at 1450 has logical errors. But DBA XYZ feedbacks suspecting that new release of procedure that runs at 1455 has logical errors.
3) I, supposed to be the saviour, shutdown immediate and startup mount the DB.
4) Then I flashback the database to 1450. Followed by ALTER DATABASE OPEN READ ONLY; to do logical checking with developer and dba.
5) Result found that scheduled job at 1450 has no problem.
6) Next I shutdown immediate and startup mount the DB again.
7) Roll forward the DB with RECOVER command to 1455. Followed by ALTER DATABASE OPEN READ ONLY; to do logical checking with developer and dba.
8) Result found that new release of procedure at 1455 has logical errors.
9) For the third time, I shutdown immediate and startup mount the DB.
10) Then I flashback the database to 1454. Followed by ALTER DATABASE OPEN READ ONLY; to do logical checking with developer and dba the last time.
11) For the fourth time, I shutdown immediate and startup mount the DB.
12) ALTER DATABASE OPEN RESETLOGS; to confirm recovery of DB at 1454.
13) Correct and retest the procedure in Development DB before releasing to Production.
14) Case resolved.