Register and sign up here:
Agenda :
š 10:00am – Introduction
š Release Strategy
š Database Upgrade with AutoUpgrade
š 5-minute break
š Ensure Performance Stability
š Move to Oracle Multitenant
š 12:00pm – Conclusion
This event was planned originally in-person, but of course due to the current situation, it had to be transformed into a virtual 2 hour workshop hosted by Digora!
Hope to talk to you soon!
Mike…
Continue reading...Thanks a lot to all of you who participated also in our second seminar. Below you find now 3 Live Seminars: Upgrade and Performance Seminar 2 Questions answered.
I this blog post I answer all questions from the second seminar about AutoUpgrade to Oracle 19c and Performance Stability. Please find the links to the other QAs for Seminar 1 (Release Strategy, Patching and Cool Features) and Seminar 3 (Migration to Multitenant) below in the Links section of this blog post.
| 39 | We need |
Please apologize that it took me a bit longer to upload a new version of our comprehensive slide deck. You can download now a new version of “Upgrade / Migrate / Consolidate to Oracle 19c” via the blog’s download page.
Since Oracle Open World 2019 we have a new corporate template. And while I like the graphics quite a bit, I’d say, the people who built it have a good sense for graphics. But they aren’t powerpoint experts. In fact, almost every slide had to be adjusted. This may not be a huge …
Continue reading...You may have realized that there are a few techniques missing describing how to do a Database Migration from non-CDB to PDB ā Migration with Data Pump is one of them. I will explain the most simple approach of going to Single- or Multitenant. It isn’t the coolest – and it isn’t very fast as soon as your database has a significant size. But it is not complex. And it allows you to move even from very old versions directly into an Oracle 19c PDB – regardless of patch levels or source and destination platform.
| Endianness change |
There are several pitfalls when you plugin a non-CDB into a CDB environment. Iād like to highlight some of them ā and show you potential workarounds as well. This is part of a series of blog posts to make your migration from non-CDB to PDB a bit smoother.
When we start to look at a migration from non-CDB to PDB for an important system, regardless of migrating on-prem or to the cloud, reducing the downtime is very important. In this blog post I’d like to highlight the different aspects …
Continue reading...There are several pitfalls when you plugin a non-CDB into a CDB environment. I’d like to highlight some of them – and show you potential workarounds as well. This is part of a series of blog posts to make your migration from non-CDB to PDB a bit smoother.
Photo by Sebastian Grochowicz on Unsplash
As I work with customers on upgrades and migrations for a very long time, I know how important a proper fallback is.
When you attempt a migration from a non-CDB to PDB, you need to plan …
Continue reading...There are several pitfalls when you plugin a non-CDB into a CDB environment. I’d like to highlight some of them – and show you potential workarounds as well. This is part of a series of blog posts to make your migration from non-CDB to PDB a bit smoother.
Photo by timJ on Unsplash
In all the previous blog posts of this series I tried to explain specific pitfalls, and how you can workaround them. This article is meant to collect the “leftovers”, the minor issues and pitfalls which you may not …
Continue reading...There are several pitfalls when you plugin a non-CDB into a CDB environment. I’d like to highlight some of them – and show you potential workarounds as well. This is part of a series of blog posts to make your migration from non-CDB to PDB a bit smoother.
Photo by Piron Guillaume on Unsplash
When you consolidate on a larger scale, it is very likely that you have different patch levels in your database environments. But when you attempt to plugin a non-CDB into a CDB, you may see …
Continue reading...There are several pitfalls when you plugin a non-CDB into a CDB environment. I’d like to highlight some of them – and show you potential workarounds as well. This is part of a series of blog posts to make your migration from non-CDB to PDB a bit smoother.
Photo by Brett Jordan on Unsplash
With component we mean the database component which you can find in DBA_REGISTRY – or CDB_REGISTRY. When Multitenant became available over 5 years ago, a decision had been made to make all options/components mandatory in a container database. This decision had to …
There are several pitfalls when you plugin a non-CDB into a CDB environment. I’d like to highlight some of them – and show you potential workarounds as well. This is part of a series of blog posts to make your migration from non-CDB to PDB a bit smoother.
Photo by Allef Vinicius on Unsplash
Interestingly, there is no issue with different time zone settings within a single CDB. Your CDB$ROOT can be on DST V.32 whereas a PDB you plugin can be already on DST V.33. But only …
There are several pitfalls when you plugin a non-CDB into a CDB environment. I’d like to highlight some of them – and show you potential workarounds as well. This is part of a series of blog posts to make your migration from non-CDB to PDB a bit smoother.
When you migrate your non-CDB to PDB, in most cases the COMPATIBLE setting of the non-CDB will be lower than the setting of the receiving CDB. But still in this case you may see warnings. I will explain how to deal with …
Continue reading...In the previous blog posts I showed different approaches on how to migrate your database on a same Endianness platform into Multitenant. Whether you prefer to upgrade first or plugin first is up to you. I recommend upgrading first as this allows you a seamless fallback. But regardless of which approach you prefer, you may take care on potential pitfalls. Hence, this blog post is about Database Migration from non-CDB to PDB – Typical Plugin Issues and Workarounds. It may not be complete when I publish it and I may extend it later on. Let me know if you have …
Continue reading...The third option for plugging in a non-CDB is called Database Migration from non-CDB to PDB ā Clone via NON$CDB, upgrade, convert. As I showed already in this blog post a while ago, your source must be at least an Oracle 12.1 database. And this technique can be used also only for same-Endianness migrations but does not apply if you’d like to migrate from Big to Little Endian. If your source database matches already the receiving CDB, no upgrade is necessary.
Photo by Samuel Chan on Unsplash
| Endianness change possible: |
No |
| Source database versions: | Oracle 12.1.0.2 |
