It’s out now and available since yesterday: AutoUpgrade 21c. Download the newest AutoUpgrade for 19c and 21c upgrades with many new features and improvements.
Photo by Jordan McGee on Unsplash
Download it!
This is the current version of AutoUpgrade:
build.hash 8ee6880 build.version 21.1.1 build.date 2020/12/14 14:41:34 build.max_target_version 21 build.supported_target_versions 12.2,18,19,21 build.type production 48 bug fixes since v21.0.0 release Tag: v21.1.1 Description: This is the release for 21.1.1 MOS only
As usual, download it please from:
What’s new?
- Non-CDB to PDB Upgrades
- AutoUpgrade can upgrade and convert a non-CDB to a PDB in a new CDB in a single operation, or upgrade and then convert a Non-CDB database to a PDB in a pre-existing CDB
- Support for RAC and SI databases
- Unplug-plug upgrade
- AutoUpgrade can perform an unplug of a pluggable database (PDB) from an earlier release source container database (CDB), plug it into a later release target CDB, and then complete all the steps required to upgrade the PDB to the target CDB release
- Supports RAC upgrades (Only for Linux or Unix-based systems)
- Configuration of the RAC management system in the source and target home is automated
- Supports native file systems, ASM and ACFS
- Oracle Restart
- Pluggable databases are supported in a RAC environment
- Ability to pass catctl_options (via config file)
- This enables the DBA to control the level of parallelism for a specific upgrade.
- Restore capability
- AutoUpgrade restore job option allows the DBA to restore database back to source home if upgrade failed or succeeded
- Clear the recovery for a specific job by adding clear_recovery_data on the command line and use jobs parameter to specific exactly which jobs recovery data must be cleared
- Upgrades on Data Guard environments
- AutoUpgrade can detect Oracle Data Guard configurations, and defer shipping logs to standby databases configured for the primary database. It will also detect and defer shipping logs to standby database if the deployment is configured manually. Upon a successfully upgrade of the primary database, upgrades to the standby database must be performed and monitored by the DBA
- AutoUpgrade performance improvements
- utlrp compilations moved out of upgrade into a post fixup
- Improved resume operations: AutoUpgrade keeps track and skips over PDBs databases that have been upgraded successfully
- Replay support was added for upgrades 21 or higher
- AutoUpgrade supports upgrade on CDBs with proxy pdbs
- AutoUpgrade supports upgrade on CDB’s with application containers
- Added additional JSON status information
- Integrated classic pre-upgrade functionality
- The -preupgrade clause of AutoUpgrade replaces the functions previously performed by the manual Pre-Upgrade Information Tool (preupgrade.jar) in previous releases The -mode clause takes one of three values:
- analyze: Check your system for readiness to upgrade
- fixups: Perform fixups as needed on your source Oracle Database release in preparation for upgrade
- postfixups: Perform fixups on your target Oracle Database release after upgrade is completed
- Reports are identical to what the preupgrade.jar originally produced.
- The -preupgrade clause of AutoUpgrade replaces the functions previously performed by the manual Pre-Upgrade Information Tool (preupgrade.jar) in previous releases The -mode clause takes one of three values:
- Starting Oracle Release 21c, Enterprise Manager, DBUA and ORAchk use AutoUpgrade to perform database upgrade readiness
- Starting Oracle Release 21c, FPP performs database upgrades using AutoUpgrade
- Enhanced management of databases using Transparent Data Encryption (TDE)
New fixes and enhancements
Wow – this list is very long. There are 5 enhancements and 43 fixes included in this version. Great work by the team!
As usual, you find the change.log listing all enhancements and fixes at the bottom of MOS Note: 2485457.1 as well as the previous versions of AutoUpgrade.
Enahancements
- AUPG-1860 Improve upgrade resume speed
- AUPG-1698 Use -zip option without a configuration file
- BUG-31859859 Run approot_to_pdb.sql when plugging in an application root
- BUG-31879931 Add utlrp compilations as a post fixup check
- BUG-31902600 Support Proxy pdbs
Fixes
- AUPG-534 Remove invalid_objects_exist reference to dbms_preup fixup
- AUPG-1234 Null pointer exception during Abort processing
- AUPG-1522 Change error message so that DBA knows to specify target_version
- AUPG-1593 Add Manage status support in RAC
- AUPG-1739 Clearer message when DBA interaction is needed
- AUPG-1823 Unclear where logs are located after running preupgrade
- AUPG-1863 Remove the Fixup for post fixed objects statistics
- AUPG-1874 On certain locales, the ORA errors are prefixed by a dot
- AUPG-1895 Query fails for GRP after service has been dropped on Windows
- AUPG-1905 Fix synonyms for timestamp mismatches and log any other issues
- AUPG-1922 Fix locale problem when checking for FRA size
- AUPG-1923 Incorrectly calculating number of pdbs to run together for Replay
- AUPG-1924 Local undo conversion must be done in UPGRADE mode
- AUPG-1938 Restore unplug is failing due to missing argument
- AUPG-1939 Fix NullPointerException during startup
- AUPG-1949 Default sample config file logging directory to cfgtoollogs
- AUPG-1951 Add logging of the command line option
- AUPG-1953 Better formatting of the preupgrade log file
- AUPG-1957 Fix NullPointerException in NonClusterIntoCluster routine
- AUPG-1958 Clearer message for achive_log_on check
- AUPG-1959 Report generation identical to classic preupgrade
- AUPG-1963 Checks deferred until upgrade are now run during fixup stage
- AUPG-1967 Fix database trgowner_no_admndbtrg check for correct privilege
- AUPG-1968 Always load dbmsjdev.sql in post_jvm_mitigat_patch fixup
- AUPG-1970 XML content for tablespaces check is incorrect
- AUPG-1972 Detect if an applied progress table needs recovery
- AUPG-1973 Updated post_jvm_mitigat_patch action message
- AUPG-1975 Preserve empty SPFILE parameters specified by customer
- BUG_31694835 Restore is not setting back DataGuard original configuration
- BUG-31729152 Add ASM management to the auto-login-wallet check
- BUG-31795652 UTLRP is rerunning during resume after a successful upgrade
- BUG-31817695 java.lang.OutOfMemoryError: GC overhead limit exceeded
- BUG-31869539 Validate file_name_convert option
- BUG-31882635 Open PDBs on the other RAC instances
- BUG-31936292 Support ACFS file systems
- BUG-32067940 Use dbname when plugging into a container
- BUG-32080126 Recompiles during post fixups consuming too much CPU
- BUG-32087481 Wrong entry in ORABASETAB creates a misleading message
- BUG-32144845 JAVAVM_STATUS check runs slow with many pdbs
- BUG-32164706 Clearer message for GRP creation failure
- BUG_32251471 Unplug Plug and Upgrade exception during Timezone fixup
- BUG_32261243 Merge source sqlnet.ora with the wrong target
- BUG_32266220 Auto_login_wallet_required Check Fails for 12.1
What’s supported?
With this version of AutoUpgrade, you can not only upgrade to Oracle Database 19c (regardless of which RU you have) but also to 12.2.0.1 and 18c with at least the January 2019 RU and – of course – to Oracle Database 21c as well.
Further Links and Information
- MOS Note: 2485457.1 – AutoUpgrade Tool
- The AutoUpgrade Utility – Start here
- Oracle 19c Upgrade Guide – Using AutoUpgrade for Oracle Database Upgrades
–Mike
Hi Mike ,
from the changelog i noticed it supports DG setup , does it mean it will upgrade the DG as part of the primary upgrade ?
Hi Sam,
yes, it does a partial automation now – but there are still some extra steps needed.
We did ask the team to add also new features the change log – I will update the blog post and write a bit more about it in the next days.
See here what it automates now:
https://docs.oracle.com/en/database/oracle/oracle-database/19/upgrd/non-cdb-to-pdb-upgrade-guidelines-examples.html#GUID-7985739B-B33B-4BA6-A9FE-FEFC7721FFE8
and what it doesn’t.
Cheers,
Mike
Hi Mike, thanks for the helpful blog! I am learning a lot about the autoupgrade tool from your posts. I had a question regarding conversion from non-CDB to PDB with a new CDB that was added to the tool in this release. The 19c documentation seems to have been updated to say that it is possible now, but doesn’t give details on how to achieve this. The 21c documentation has not yet been updated with this information (still says you need to pre-create the CDB). Will it just create the target_cdb if it doesn’t exist or are there additional parameters needed to get this working?
Hi Matt,
you need to always create the CDB you plan to migrate into beforehand by yourself.
Once you did this, this is the way how to convince AutoUpgrade to plugin a 19c database into a 19c CDB as a new PDB (without doing an upgrade):
https://mikedietrichde.com/2020/08/04/oracle-autoupgrade-between-two-servers-and-plugin/
Cheers,
Mike
Ah ok, I was confused by this line in the changelog, “AutoUpgrade can upgrade and convert a non-CDB to a PDB in a new CDB in a single operation, or upgrade and then convert a Non-CDB database to a PDB in a pre-existing CDB” I would have assumed that if you create it beforehand it is pre-existing.
Hi Mike,
We have 11.2.0.4 DBs using TDE. Autoupgrade 21.1.1 crashes when running the TDE check.
EXECUTE IMMEDIATE ‘select SYS_CONTEXT(”USERENV”, ”CON_ID”) from sys.dual’ INTO cur_con_id;
ORA-02003: invalid USERENV parameter
Regards,
Doug
Hi Doug,
somebody else reported a similar issue with 11.2.0.4 databases.
Can you please use the previous AU tool (scroll down in the download MOS note, the previous versions are still there) as a temp workaround?
Cheers,
Mike
Hi Doug,
this has been reported as
AUPG-1978 Analyze (TDE_IN_USE) fails in encrypted 11.2.0.4 database: UPG-1316
One of my team mates is actively working on the fix already.
Cheers,
Mike
Hi Mike,
on 2 Node RAC on Linux Exadata upgrading of database from 18.7 to 19.9 failed with step
– INFO Executing SQL [select value from v$parameter2 where name=’dg_broker_start’;] in [test1, container:null] – ExecuteSql$SQLClient.run
– ERROR Failed to get DG_BROKER_START parameter with error AutoUpgException [UPG-1711] – DeferStandby.isBrokerEnabled
No standby and DG_BROKER, just a simple 2 instance RAC.
Regards,
Hans
Hi Hans,
sorry to see this.
Did you open an SR for this issue? Then please share the SR number with me and I can ask the developer to have a look at it.
Cheers,
Mike
Hi Mike,
We hit the same UPG-1711 error when using Autoupgrade. for two node RAC on Linux ( 12.1.0.2 to 19.9) .. applied 19.10 patchset same behaviour.( No standby in use)
Tried below parameter from Upgrade guide and that allowed us to move forward.
upg1.defer_standby_log_shipping=no
Thanks,
Kanda
Hi Mike,
I downloaded the latest version of autoupgrade and want to upgrade 12.2.0.1.200714 CDB database on a 2-node-RAC to 19c.
The analyze fails with
2021-01-19 08:00:22.364 ERROR Database initilization of [TGCDB04X] failed due to [java.sql.SQLException]
2021-01-19 08:00:22.365 ERROR Errors executing [with segments as (select /*+ MATERIALIZE */ tablespace_name, inuse from( select ds.tablespace_na
me, row_number() over (partition by tablespace_name order by 1) rn, round(nvl(sum(ds.bytes) over (partition by ds.tablespace_name),0)/1024,2) as
…
*
ERROR at line 1:
ORA-12850: Could not allocate slaves on all specified instances: 2 needed, 0 allocated
] [TGARG01X]
I already created SR 3-24939760071 but no solution yet.
Rgards,
Gert
Hi Gert,
we have seen this several times (and it is not an AutoUpgrade issue but hits AU at this point).
In some cases, it happened when the PDB$SEED was open Read/only on another node.
Can you check the following workarounds:
1. OPEN PDB$SEED in RW mode in all the nodes before running preupgrade
2. Change parallel_force_local=TRUE
3. Change parallel_max_servers to 1
And can you share with the Support engineer this SR as the customer struggled with the same issue: 3-24725937771
Cheers,
Mike
Hi Mike,
thanks for the reply.
I tested all three workarounds. Unfortunately no success, no change, same error as before.
Support engineer did not answer yet regarding the SR# you mentioned.
Error is
ORA-12850: Could not allocate slaves on all specified instances: 2 needed, 0 allocated
] [TGARG02X]
TGARG02X is a PDB that used to be a single-instance non-CDB which was plugged in. Don’t know if this has something to do with the root cause?
Kind regards,
Gert
Hi Gert,
sorry to hear that – then please raise the severity to Sev.1, make several updates to the SR, request an escalation, request a management callback within x hours – and call the HUB (Support telephone number in your country) and tell them to escalate the SR please as well.
Thanks,
Mike
Hi Mike,
I tried v21 jar for a RAC upgrade+PDB plug. It worked well on primary but crashed DG. The DG does not know handle the files copied to the primary CDB. As a result it just stopped MRP. We can’t use the standby now. Can you please take a look? (SR 3-25018516404)
Recovery created pluggable database QCI012D +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
QCI012D(5):Recovery scanning directory +D3CL007DG01/CMQ04TG/B954AA17E0B712BEE053F106010AA192/DATAFILE for any matching files
QCI012D(5):*****************************************
QCI012D(5):WARNING: The converted filename ‘+D3CL007DG01/cmq04t/b954aa17e0b712bee053f106010aa192/datafile/system.416.1062313071’
QCI012D(5): is an ASM fully qualified filename.
QCI012D(5): Changing the filename to ‘+D3CL007DG01/MUST_RENAME_THIS_DATAFILE_61599.4294967295.4294967295’.
QCI012D(5): Please rename it accordingly.
QCI012D(5):*****************************************
MRP0: The following warnings/errors are found:
ORA-01274: cannot add data file that was originally created as ‘+D3CL001DG01/CMQ04T/B954AA17E0B712BEE053F106010AA192/DATAFILE/system.416.1062313071’
ORA-01565: error in identifying file ‘+D3CL001DG01’
ORA-17503: ksfdopn:2 Failed to open file +D3CL001DG01
ORA-15045: ASM file name ‘+D3CL001DG01’ is not in reference form
Multi Instance Redo Apply terminaed with error 1274
Hi Chris,
somebody from the team is looking into it already.
The problem is that ASM requires extra treatments as otherwise the standby site won’t find the files.
MOS Note: 2273304.1 Reusing the Source Standby Database Files When Plugging a non-CDB as a PDB into the Primary Database of a Data Guard Configuration
describes it exactly. I think, if you’d prepare the ASM Alias file beforehand, and execute it on the standby ASM side, it will work smoothly. But we are discussing internally how we can handle this best with AutoUpgrade.
Cheers,
Mike
hi Mike
We used the traditional method to upgrade the non-cdb database from 12c and 19c, after upgrade, we found we hit below 2 issues after raised SR.
1) Bug 25954054 – WRH$_SGASTAT_U BECOMING UNUSABLE STATE IN UPGRADED DB . This is to avoid issues with WRH$_SGASTAT_U.
2) Index WRH$_SYSMETRIC_HISTORY_INDEX Status Unusable ( Doc ID 2426391.1 )
If I changed to auto-upgrade tools , could we avoid from above 2 issues ?
Hi Andy,
no, as the underlying issues aren’t solved with AutoUpgrade.
For the 2nd issue, the post install script for a patch hasn’t been executed:
“Post install script calls the catawrtb.sql that comes with patch 19651064. If the post install script is not run or not completed to the end ,the index will be turned unusable.”
The first issue is covered in:
Oracle Support Document 25954054.8 (Bug 25954054 – wrh$_sgastat_u becoming unusable state in upgraded db) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=25954054.8
AU can’t foresee or cure all potential cases. Especially since this issue is fixed since 18c. I see that the problem is because of the source release. But there is not much, AU could do.
If you know about these issues, it is easy to pass on the necessary steps via a shell script as AU does allow you that, pre and post upgrade.
Cheers,
Mike
Hi Mike,
This is a fantastic and useful blog for us,, Kudos to you and the team !! we hit the below error while using Autoupgrade.jar for a two node RAC Database upgrade from 12.1.0.2 to 19.10.0
2021-02-10 13:08:14.513 ERROR Failed to get DG_BROKER_START parameter with error AutoUpgException [UPG-1711]
2021-02-10 13:08:14.514 ERROR drain failed: oracle.upgrade.autoupgrade.utils.errors.AutoUpgException: AutoUpgException [UPG-1711]
2021-02-10 13:08:14.515 ERROR Dispatcher failed: AutoUpgException [UPG-1711]
2021-02-10 13:08:14.516 INFO Starting error management routine
2021-02-10 13:08:14.517 INFO Ended error management routine
=========================================================
After reviewing the 19c upgrade guide, we set the below parameter to ‘no’ in the config file, as we did not standby and were able to move forward with the upgrade.. sharing it in hope that it will be useful for others!
upg1.defer_standby_log_shipping=no
Cheers,
Kanda
Thanks Kanda!!
Hi Mike.
We have a simple problema in running last version of autoupgrade.
§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§
/u01/app/oracle/product/19.8.0.0/dbhome_1/jdk/bin/java -jar /u01/app/oracle/product/19.8.0.0/dbhome_1/rdbms/admin/autoupgrade.jar -version
build.hash 8ee6880
build.version 21.1.1
build.date 2020/12/14 14:41:34
build.max_target_version 21
build.supported_target_versions 12.2,18,19,21
build.type production
§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§
We have to upgrade one of our database (RAC two nodes on Solais Sparc 11.4) from 11.2.0.4 to 19.8.
We have 3 environments:
TEST (Refreshed from Prod once every two months, with “emc srdf clone”)
PRE-PROD (Refreshed from Prod env once a week on Sunday, with “emc srdf clone”)
PROD
We have successfully upgraded the TEST env. two months ago and now we’re working on PRE-PROD env.
The test env. have been upgraded with autoupgrade version 19.10.0
Working with 21.1.1 we have a problem.
As we’re executing the upgrade each Sunday after SRDF Clone, after the first upgrade, each time that we’re going to execute a new upgrade, we reveive that error below and no action will be done on the database.
THE W.A. is rename the lOG directory location for each new RUN.
§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§
/u01/app/oracle/product/19.8.0.0/dbhome_1/jdk/bin/java -jar /u01/app/oracle/product/19.8.0.0/dbhome_1/rdbms/admin/autoupgrade.jar -config /NAS/jira/SOFTWARE/ORACLE_T5_19/RDBMS/AUTOUPGRADE/PPORAFIN/config.cfg -mode deploy
Previous execution found loading latest data <<<<<<<<<<<<<<<<<<<<<<<<<<<<< ——————- Final Summary ——————–
Number of databases [ 1 ]
Jobs finished [1]
Jobs failed [0]
Jobs pending [0]
—- Drop GRP at your convenience once you consider it is no longer needed —-
Drop GRP from OraFIN1: drop restore point AUTOUPGRADE_9212_ORAFIN1112040
–
Please check the summary report at:
/NAS/jira/SOFTWARE/ORACLE_T5_19/RDBMS/AUTOUPGRADE/PPORAFIN/upg_logs/cfgtoollogs/upgrade/auto/status/status.html
/NAS/jira/SOFTWARE/ORACLE_T5_19/RDBMS/AUTOUPGRADE/PPORAFIN/upg_logs/cfgtoollogs/upgrade/auto/status/status.log
§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§
That same process with autoupgrade 19.10.0 worked fine and new job number was generated.
Is that an expected behaviuour?
Regards.
Guido
Guido,
which error are you seeing? I read several times now through your comment but I’m not sure which error you are referring to when you write: “As we’re executing the upgrade each Sunday after SRDF Clone, after the first upgrade, each time that we’re going to execute a new upgrade, we reveive that error below and no action will be done on the database.”?
Is it that your “deploy” call does actually no additional upgrade but just tells you that the previous upgrade has been finished?
Do you use the same log directory again?
Cheers,
Mike
Hallo Mike,
You know that any argument passed to -create_sample_file option will fail but “config” or “settings” ?
Contrarily to what usage output of autoupgrade might let suggest (“usage: java -jar autoupgrade.jar [-version | -help | -create_sample_file ] [-settings ] [-config ] …”), running:
~ java -jar autoupgrade.jar -create_sample_file test.txt
or
~ java -jar autoupgrade.jar -create_sample_file test.cfg
or whatever will always return “Invalid value for create_sample_file “. If you leave it blank it’s more explicit, and you understand you must either type “config” or “settings” (with these arguments it’ll create respectively a sample_config.cfg and a sample_autoupg.cfg file).
Thanks.
Hi Seb,
which AU are you using? I test with the 21.1.1 version and it works smoothly:
$ java -jar $OH19/rdbms/admin/autoupgrade.jar -create_sample_file config text.cfg unplug
Created sample configuration file /u01/app/oracle/product/19/rdbms/admin/text.cfg
[CDB2] oracle@hol:/u01/app/oracle/product/19/rdbms/admin
$ java -jar $OH19/rdbms/admin/autoupgrade.jar -create_sample_file config text.txt unplug
Created sample configuration file /u01/app/oracle/product/19/rdbms/admin/text.txt
[CDB2] oracle@hol:/u01/app/oracle/product/19/rdbms/admin
$ java -jar $OH19/rdbms/admin/autoupgrade.jar -create_sample_file config text.txt full
Created sample configuration file /u01/app/oracle/product/19/rdbms/admin/text.txt
[CDB2] oracle@hol:/u01/app/oracle/product/19/rdbms/admin
Cheers,
Mike
Hi Mike,
Does autoupgrade currently support upgrade of single PDB plugged manually to target version CDB from different / earlier version CDB from different host?
It’s a scenario of unplug/plug upgrade but on different servers which AU currently doesn’t do, so we have to unplug and plug it manually, but afterwards when opening target CDB/PDB in upgrade mode and running au -upgrade it still moans about cdb/pdb version mismatch:
ERROR *Existing Plugin Violations
Fix the below pending violations in the database TARGET_CDB before the upgrade
PDB_NAME|PDB’s version does not match CDB’s version: PDB’s version 12.1.0.2.0. CDB’s version 19.0.0.0.0.
See here – Daniel, my team mate, described it:
https://dohdatabase.com/2021/01/07/how-to-upgrade-a-single-pdb/
Cheers,
Mike
I already did some unplug/plug upgrades of single pdb using autoupgrade but on the same host, whole operation performed by AU.
But this is different scenario as described above and couldn’t make it work.
Thanks – with Daniel’s instructions, it will work.
Otherwise please let us know.
Cheers,
Mike
Hi Mike,
What does it mean with “Enhanced management of databases using Transparent Data Encryption (TDE)” by the new release 21c? Is unplug-plug upgrades of PDBs that use Transparent Data Encryption (TDE), or that have an encrypted tablespace possible now with the new version of AutoUpgrade Tool?
Regards
Erhan
Hi Erhan,
it means that we handle now wallets much better than before, and can deal well with WALLET_ROOT etc.
But it has nothing to do with the actual encryption of the tablespaces but only with the procedure by AutoUpgrade when you have an encrypted database.
Cheers,
Mike
Hi Mike,
Thanks for the feedback, and where can I find the technical details about this enhancement? Another question, is it still not supported to use AutoUpgrade to upgrade a RAC/DG Oracle Database 12.2 (multitenant with TDE) to 19c? If still not, is it in pipeline to support it?
Regards
Erhan
Coming soon, Erhan – still a few bits missing.
Cheers,
Mike