VinodNagpure wrote:If you want to export/import, then it has to be EBS specific.
We are not changing OS etc. The lost instance contains important data of oracle EBS. We want it back. So we are importing it into another fresh database which will act as our new EBS database. The new database has been created on the same server as the original db. The oracle support has left su confused. They say that we should follow the document 741818.1. They also say that this document assumes that the db is completely recovered, while our db is opened in inconsistent state. And in another SR they have suggested plain export/import without any EBS specific steps !
VinodNagpure wrote:Not necessarily if you have a deployment script to promote those reports directly to prod. If you do not have such a script, then you need to migrate them from dev to prod.
A question - The database has been opened with allowresetlogs_corruption. I ran autoconfig on db as well as apps tier without any errors. The application tier has started successfully. The concurrent managers, etc. everything is up. In the instance our dev team has some FSG reports and Cheque printing setup. Now as the db as well as apps is up and we need this instance just to transfer the FSG reports and test the cheque printing so that it can be applied on prod, do we really need to do this export and import stuff ? Anyway we would be scrapping this instance once this purpose is served.
And how can I do a health check to make sure this instance will work sanely for a couple of days ?Keep monitoring the database log file for any errors for the next couple of days and see if you get any errors. If you still have the log file, then you may log a SR and see why your database got corrupted (you will need to upload the alert.log file as we all trace files).