Hi Erman,
Our environment: 2 node apps tier R12.2.5(shared appltop) 2 node db 12.1.0.2(RAC) We are about to implement GST(GO-LIVE) next week in PROD. We have few concerns and requesting your suggestions 1)Take rman L0 backup just before starting the patching activity(patches may take 7 hours to get applied) 2)During the patches application,users will be connected and performing online transactions. Once all the patches are applied: Before cutover,can we bring down the application and database to take rman level0 backup(cold) again? will this create any issues in completing the whole online patching cycle like cutover and cleanup? If something went wrong,we are planning to restore L0 backup which is taken just before cutover.Because this will have user transactions as well Thanks, Raj |
Administrator
|
Good.. The changes cannot be rolled back once they are committed in the cutover phase. So you need to take a backup before patching.
A cold backup could work, but there is a big downtime there.. An online backup could work, but it is also timeconsuming process . You can use flashback Database feature of Oracle Database in the database tier. This is fast But in any case, you should think of estarting the application services from the relevant file system edition. So once you restore the database before the cutover phase, you may need to restart the application services from "the relevant file system edition" -- in case you fail after some time cutover switches the filesystems. And yes, you can stop the apps services and shutdown your database before cutover. I already recommend the same for using flashback restore point option. For ex: Stop the web services. Stop the concurrent managers or put the schedule concurrent requests on hold. Stop database-bound third-party applications or cut off their database connections. Force a log switch. Create a guaranteed restore point. Force another log switch This subject is address in our book Practical Oracle E-Business Suite "https://www.amazon.com/Practical-Oracle-Business-Suite-Implementation/dp/1484214234" Section : "Backup Best Practices for EBS 12.2 Patching" |
Hi erman,
Thank you. Our database size is 200Gb and takes 1 hour to complete. Which option do you think is best,if users asked us to restore after 2 days from gst patches application. 1)Flashback point in time to before cutover(we will then run abort)) 2)Using guaranteed restore point which is created before cut over 3)Rman L0 backup taken in Mount state just before cutover Thank you |
Administrator
|
Guaranteed restore point or rman level 0.
|
Thank you.
High level steps: 1) Take level0 backup online 2)Start applying gst patches( prepare,apply,finalise) 3)create restore point 4)Take L0 backup offline(db in Mount state) 5) performed cut over, cleanup and instance released to customer. After 2 days, we are asked to restore. In this case, we will use restore point created earlier and go back to a state just before cutover.As this is fast compared to L0 backup. After that, what things we need to perform in application end, so that we can abort patching cycle. Thank you |
Administrator
|
You will need to switch apps filesystems + you will lose some data. However, there is wrong approach here.. After 2 days , you shouldn't restore to the point of patching.. if you do so, the changes made during those 2 days will be lost. 29 May 2020 Cum 11:24 tarihinde satish [via Erman Arslan's Oracle Forum] <[hidden email]> şunu yazdı: Thank you. |
Dear Erman,
Thanks for pointing this.We have already communicated the same to clients.Moreover,we dont have any DR,golden gate etc.. After 2 days , you shouldn't restore to the point of patching.. if you do so, the changes made during those 2 days will be lost. In worst case,if we are asked to restore,then this approach will work right? Once the db is restored,we will switch the filesystems and then run abort. Thank You |
Administrator
|
This post was updated on .
I already sent you what needs to be done.
Stop the web services. Stop the concurrent managers or put the schedule concurrent requests on hold. Stop database-bound third-party applications or cut off their database connections. Force a log switch. Create a guaranteed restore point. Force another log switch In-case you fail on cutover -> shutdown apps, restore to the guaranteed restore point (while you are in mount mode) -> switch back the apps filesystems (if needed) -> startup the apps services (from the correct env) -> adop abort or adop cutover once again(if you want to try again from that point). |
This post was updated on .
Hi Erman ,
Lets assume,After 2 days...we have flashback the database to just before the cutover phase using restore point which we created. Instead of switching back file systems,can we restore the tar backup of file system which we take at the time of creating restore point? Thank You |
Administrator
|
No. You will lose data in that case. 29 May 2020 Cum 13:12 tarihinde raj [via Erman Arslan's Oracle Forum] <[hidden email]> şunu yazdı: Is the same process applicable after the patches are applied with successfull cutover and after instance is released to users? |
Free forum by Nabble | Edit this page |