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.
High Level Overview
|Endianness change possible:
|Source database versions:||Oracle 18.104.22.168|
This is my next blog post about Database Migration from non-CDB to PDB – Plug in, upgrade, convert. But what is different from the previous one? And why is it necessary? Since Oracle Database 22.214.171.124 you can plugin a non-CDB at first, the upgrade and convert it. And I’ll show you this technique here.
High Level Overview
|Endianness change possible:||No|
|Source database versions:||Oracle 126.96.36.199 or newer (or 188.8.131.52 when CDB has shared UNDO)|
|Characteristic:||Plugin into CDB first|
|Upgrade necessary:||Yes, after plugin|
|Downtime:||Plugin, copy (optional), upgrade and
As first blog post of this series about Database Migration from non-CDB to PDB – Upgrade, plug in, convert I will explain the most straight forward approach of going to Single- or Multitenant. But you have other options as well. which I’ll showcase in the other blog posts. I demonstrated this technique on the blog already a while ago. But since Oracle 184.108.40.206, there are a few other options available.
High Level Overview
|Endianness change possible:||No|
|Source database versions:||Oracle 220.127.116.11 or newer|
|Characteristic:||Upgrade non-CDB first|
|Upgrade necessary:||Yes, before plugin|
||Upgrade, plugin, copy (optional) and|
Today I’ll start a blog post series of several “how to” articles about database migration from non-CDB to PDB – Overiew. You’ll find a quick introduction below. And of course, the links to all the other related blog posts.
Database Migration from non-CDB to PDB – Overview
When you plan to move from non-CDB, the Oracle term for regular database deployments, to a Pluggable Database (PDB), you will migrate your database. It will become a PDB and run as part of a Container Database (CDB). This is a well known concept for several years now called Oracle Multitenant. If you …Continue reading...
Sometimes it is necessary to warn you about known pitfalls to avoid frustration. In this particular case I decided not to blog about it simply because I thought this won’t happen to too many other people. Well, yesterday my good friend Philippe Fierens dropped me a message about an issue he ran into with a Transportable Tablespace PDB Migration and Local Undo. And I immediately knew what caused him trouble – and I regret that I didn’t blog about it (sorry Philippe!). We’ve seen the same problem with a large ExaCC migration project …Continue reading...
What a strange topic. And I thought I never will blog about this. But as I have received the same question for the third time today, I think there’s a bit clarification needed. Lost AWR snapshots reappear in Oracle 12.2 in Multitenant pluggable databases.
Lost AWR snapshots reappear again in Oracle 12.2 in Multitenant
In a non-CDB database you have your local AWR data stored in the SYSAUX tablespace. Whenever you create an AWR snapshot:
You can query and of course evaluate it afterwards:
select con_id, snap_id, snap_level, to_char(begin_interval_time, 'dd/mm/yy hh24:mi:ss') BEGIN from CDB_HIST_SNAPSHOT order by… Continue reading...
At the moment I work with one of our reference customers, Swiss Mobiliar Insurance, on their Multitenant upgrade to Oracle Database 18.104.22.168. And we encountered an “interesting” issue. After upgrade we received an ORA-44787 making it impossible to switch between containers with “
alter session set container=pdb1;” commands. Lesson learned now: If you don’t want ORA-44787 – Don’t mess with the Default Oracle Service.
What has happened?
Very simple case. We approach a database upgrade with a Multitenant deployment of over 90 PDBs. Source database version is Oracle Database 22.214.171.124.BP170117, destination version is Oracle Database 126.96.36.199.RU170718. …Continue reading...
Oracle Label Security (OLS) clean up in Oracle Database 11.2-19c is almost as simple and straight forward as removing OWM or APEX. You can do it online without downtime. But in older releases a relink operation did cause downtime. Oracle Label Security is an extra cost option. More information is available on oracle.com.
Oracle Label Security (OLS) Clean Up in Oracle Database 11.2-19c
Oracle Label Security is dependent on Oracle Database Vault (DV). In case DV is present you must remove it first if you plan to remove Oracle Label Security.
Before you start removing anything from …Continue reading...
What is noncdb_to_pdb.sql?
noncdb_to_pdb.sql gets run only once in the life span of your database. It gets executed when a regular Oracle database (non-CDB) gets move to become part of a Single-/Multitenant deployment as a pluggable database (PDB). But why does it take so long?
You will never run this script again for this database. The script is a sanity script to clean up and change things in a non-CDB, and unite it finally and irreversible with the CDB.
How long does it take to complete?
Runtime varies a lot. It depends mainly on the number of objects …Continue reading...
I did blog about this topic a while back.
Theory is nice but it’s a big difference when you do it the first time with a non-lab deployment at a customer with a real Multitenant database with almost 100 PDBs.Then you learn that neither the documentation nor my previous blog post contain all the necessary steps.
My test setup
I have a simple deployment of just 5 PDBs. But it will showcase with my limited compute capabilities how the process should work.
SQL> show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ----------… Continue reading...
Thanks to Roy – our Hands-On Lab “Upgrade, Migrate and Consolidate to Oracle Database 12.2” is now available for download from OTN.
- Download Hands-On Lab “Upgrade, Migrate and Consolidate to Oracle Database 12.2”
- Download the Hands-On Lab Instructions as PDF
Instructions and technical requirements are clearly documented on the OTN page as well. The lab is based on Virtual Box and can be easily imported upon download and unzip.
You can always access the lab via the blog’s top menu as well:
Inside the lab you’ll find :
- UPGR – an Oracle 188.8.131.52
I received a question whether the Non-CDB architecture still exists in Oracle Database 12.2.from 3 different colleagues in the past week:
“Does Oracle Database 12.2 still allow us to create non-CDB databases?”
And as I get this question at every customer-facing workshop these days as well before being able to talk about Single/Multitenant – I think it is important to clarify it. The statement is misleading. And I can’t blame anybody about misreading it.
Is the non-CDB architecture still available/supported in Oracle Database 12.2?
I did blog about it a while ago – but Google is not always your …Continue reading...
Some very helpful MOS Notes got published regarding the upgrade to Oracle Database 184.108.40.206:
- MOS Note: 2173141.1
Complete Checklist for Manual Upgrades to non-CDB Oracle Database 12.2
- MOS Note: 2173144.1
Complete Checklist for Manual Upgrade for Multitenant Architecture Oracle Databases from 12.1. to 12.2.
- MOS Note: 2189854.1
Complete Checklist for Upgrading to Oracle Database 12.2 using DBUA
Furthermore check regularly for Known Issues and Alerts – currently the note has no content but exists already:
Thanks to Murthy who commented on this blog post and Jeannette Holland (SimCorp) who opened an SR resulting in an ER.
DBMS_QOPATCH in Multitenant
DBMS_QOPATCH will deliver useful information about installed patches only when executed within the CDB$ROOT. It has been designed this way for security reasons in Oracle Database 12.1 but I can easily see a need to check for installed patches within a PDB as well.
I “borrowed” this test case from Jeannette’s SR:
… Continue reading...SQL> COLUMN NAME FORMAT A8 SQL> SELECT NAME, CON_ID, DBID, CON_UID, GUID FROM V$CONTAINERS ORDER BY CON_ID; NAME CON_ID DBID CON_UID GUID --------
When Oracle Multitenant was launched Roy and I amongst many other people always mentioned that the requirement of having all options in a Container Database (CDB$ROOT), and therefore also for the PDB$SEED with the immediate result that all PDBs provisioned from the PDB$SEED will have all options as well, will hinder customer adoption significantly. But this has been changed now. You can create Container Databases (CDB) with less options – it’s now supported in Oracle 220.127.116.11.
Create Container Databases (CDB) with less options – it’s now supported in Oracle 18.104.22.168
Almost all customers I have talked to in the …Continue reading...