Hi Daniel, Thank you for this clear video explanation. We are in the midst of switching from in-place patching to out-of-place patching and automating as much as possible with autoupgrade. I was wondering if the shown method also work in this case, especially when we also upgrade the timezone using the "timezone_upg=yes" option in the configuration file. With a timezone upgrade of a CDB, extra restarts of the database are needed. How are these restarts reflected to the standby? Thank you
Hi Frank-Jan, If you upgrade the time zone file on a primary database, there is no need to perform anything on the standby database. The time zone file upgrade happens entirely in the database and the changs are recoreded in redo. Once the redo applies on the standby, it is implicitly upgraded. The only restart of the primary database is to restart in upgrade mode. The time zone file upgrade happens with the database in upgrade mode. However, when the redo is applied on the standby database, there is no such requirement. The redo is just applied. Regards, Daniel
Hi Daniel, Firstly, thanks for the video above. Now, i have a doubt, maybe you could help me with some infos: i have multiple destinations, dest_2 is for dataguard, and dest_3 is for ZDL backup appliance. Is there any action i must do for dest_3 ? Thanks & Regards,
Hi Bruno, First, this video is slightly outdated. The default behaviour has changed, so now AutoUpgrade will not defer redo transport to the log archive destionations, unless you explicitly state that. So, if you use the latest version of AutoUpgrade, then AutoUpgrade won't make any changes to LAD. This means that you recovery appliance should receive the redo like normally. If you still prefer to defer redo log transport, you can set refer_log_shipping=yes. Then all LAD - including your recovery appliance LAD - will be deferred. Regards, Daniel P.S. We hope to have a new video ready soon! :)
Dear Is this approach safe for DB over 10 TB size ? Is auto upgrade going to preform the upgrade as well for standby database? What’s the rollback plan if test went wrong?
Hi Waleed, Yes, this approach is safe. Actually, if you look in the recommendations from the MAA team, then they recommend using AutoUpgrade for upgrades of Data Guard on Exadata. The rollback plan is using Flashback Database. You can always flash back a database, if the upgrade goes wrong. If you want to be even more safe, you can shut down the standby database, until you have completed the upgrade of the primary database. This way, you have the standby ready, if something goes wrong. Regards, Daniel
Dear Daniel, what if upgrading from 11.2.0.4 non-CDB to Oracle 19c in Multitenant? can we apply redo or not? in your demo, it seems the upgrade is non-CDB to non-CDB. Regards, Teguh
Hi Lorensius, If you want to upgrade to Database 19c and then convert to multitenant - it is two different things, although you can do it in the same maintenance window. The upgrade is easy - as explained in the video - the standby database will survive if you do as explained. With the multitenant conversion it is a little different and you must take special steps. We just discussed this in a webinar which you can watch here: videohub.oracle.com/media/Migrate+to+the+Multitenant+Architecture/1_izx15u3d?st=3727. You can get the slides here: apex.oracle.com/pls/apex/f?p=202202:2:::::P2_SUCHWORT:multitenant. This should help you get started. Happy migrating! Daniel
@@upgradenow nice explanation, Daniel. it makes sense. Multitenant is different architecture from 11g. I am happy with slide and video. Have a nice day. stay health. Regards,
Hi Zubair, The "srvctl" commands are used for various purposes. For starting and stopping the database just use STARTUP and SHUTDOWN from SQL*Plus. To move the database to a new Oracle Home, edit /etc/oratab and reset your environment to point to the new Oracle Home and then restart the database. To disable the database you could do something like renaming the spfile and/or password file. I hope that helps. Happy upgrading! Regards, Daniel
Hi Daniel,
Thank you for this clear video explanation.
We are in the midst of switching from in-place patching to out-of-place patching and automating as much as possible with autoupgrade.
I was wondering if the shown method also work in this case, especially when we also upgrade the timezone using the "timezone_upg=yes" option in the configuration file.
With a timezone upgrade of a CDB, extra restarts of the database are needed. How are these restarts reflected to the standby?
Thank you
Hi Frank-Jan,
If you upgrade the time zone file on a primary database, there is no need to perform anything on the standby database. The time zone file upgrade happens entirely in the database and the changs are recoreded in redo. Once the redo applies on the standby, it is implicitly upgraded.
The only restart of the primary database is to restart in upgrade mode. The time zone file upgrade happens with the database in upgrade mode. However, when the redo is applied on the standby database, there is no such requirement. The redo is just applied.
Regards,
Daniel
Hi Daniel,
Firstly, thanks for the video above.
Now, i have a doubt, maybe you could help me with some infos:
i have multiple destinations, dest_2 is for dataguard, and dest_3 is for ZDL backup appliance. Is there any action i must do for dest_3 ?
Thanks & Regards,
Hi Bruno,
First, this video is slightly outdated. The default behaviour has changed, so now AutoUpgrade will not defer redo transport to the log archive destionations, unless you explicitly state that. So, if you use the latest version of AutoUpgrade, then AutoUpgrade won't make any changes to LAD. This means that you recovery appliance should receive the redo like normally.
If you still prefer to defer redo log transport, you can set refer_log_shipping=yes. Then all LAD - including your recovery appliance LAD - will be deferred.
Regards,
Daniel
P.S. We hope to have a new video ready soon! :)
Dear
Is this approach safe for DB over 10 TB size ?
Is auto upgrade going to preform the upgrade as well for standby database?
What’s the rollback plan if test went wrong?
Hi Waleed,
Yes, this approach is safe. Actually, if you look in the recommendations from the MAA team, then they recommend using AutoUpgrade for upgrades of Data Guard on Exadata.
The rollback plan is using Flashback Database. You can always flash back a database, if the upgrade goes wrong. If you want to be even more safe, you can shut down the standby database, until you have completed the upgrade of the primary database. This way, you have the standby ready, if something goes wrong.
Regards,
Daniel
Dear Daniel,
what if upgrading from 11.2.0.4 non-CDB to Oracle 19c in Multitenant? can we apply redo or not?
in your demo, it seems the upgrade is non-CDB to non-CDB.
Regards,
Teguh
Hi Lorensius,
If you want to upgrade to Database 19c and then convert to multitenant - it is two different things, although you can do it in the same maintenance window.
The upgrade is easy - as explained in the video - the standby database will survive if you do as explained.
With the multitenant conversion it is a little different and you must take special steps. We just discussed this in a webinar which you can watch here: videohub.oracle.com/media/Migrate+to+the+Multitenant+Architecture/1_izx15u3d?st=3727. You can get the slides here: apex.oracle.com/pls/apex/f?p=202202:2:::::P2_SUCHWORT:multitenant.
This should help you get started. Happy migrating!
Daniel
@@upgradenow nice explanation, Daniel. it makes sense. Multitenant is different architecture from 11g. I am happy with slide and video. Have a nice day. stay health.
Regards,
How to do the same without using srvctl command
Hi Zubair,
The "srvctl" commands are used for various purposes. For starting and stopping the database just use STARTUP and SHUTDOWN from SQL*Plus. To move the database to a new Oracle Home, edit /etc/oratab and reset your environment to point to the new Oracle Home and then restart the database. To disable the database you could do something like renaming the spfile and/or password file.
I hope that helps. Happy upgrading!
Regards,
Daniel