AutoUpgrade and Plug In to a CDB – with a single command (and video)

Posted on May 20, 2020 by AutoUpgrade Single-/Multitenant 71

I have to confess, this feature is out and available for quite a while. But only unofficially. AutoUpgrade can upgrade and plug in a non-CDB into a CDB. But it lacked flexibility. And we didn’t test it a lot. Hence, you could find it documented in our Hands-On Lab instructions. And we did this exercise with you already in our sold-out labs at OOW 2019 as well. But since a week and a bit, it is officially supported: AutoUpgrade and Plug In to a CDB – with a single command (and video).

AutoUpgrade and Plug In to a CDB - with a single command (and video)

Photo by William Daigneault on Unsplash

Create your CDB at first

AutoUpgrade does not only upgrade your database. It can plug it into a CDB as well. With one single command. You will have to precreate this CDB. And please, pay close attention to the components you select to avoid plugin issues. The easiest approach is to create a CDB with all options. If you do this, make sure the PDB$SEED gets only the options you really want in future PDBs you provision. But personally I’d recommend to check your current non-CDB’s DBA_REGISTRY for the existing COMP_ID. And select these for your CDB as well.

These blog posts may help you to take the right choices when you create your CDB.

What does AutoUpgrade do?

Until Oracle Database 19c, AutoUpgrade at first will upgrade your database – and then plug it in. This is the more safer approach as we have a proven fallback for the upgrade part. So if anything goes wrong during the upgrade, AutoUpgrade allows you to seamless fallback within minutes. But with the future releases after Oracle 19c, this will chance. When the non-CDB architecture is gone, we can’t upgrade at first to a higher release than 19c as you’d have a non-CDB then. So for future releases, AutoUpgrade then will plug in at first, and then trigger the upgrade and conversion.

AutoUpgrade and Plug In to a CDB - with a single command (and video)

Please download always the newest AutoUpgrade tool from MOS Note: 2485457.1. And study the blog post series about the various considerations, pitfalls and fallback topics regarding the non-CDB to PDB conversion.

Which are the new parameters?

In order to allow you the plugin, we add now these three parameters to AutoUpgrade:

AutoUpgrade and Plug In to a CDB - with a single command (and video)

You find them in the Oracle Database 19c Upgrade Guide.

The command for AutoUpgrade stays exactly the same – you need to add only at least target_cdb to your config file specifying the SID of the CDB you precreated.

The other two parameters are optional. When you leave out target_pdb_copy_option, NOCOPY will be used. I’d recommend to you the parameter instead if you can have the duplicate disk space. Otherwise make sure you have a working backup. And remember Schroedinger’s Backup theorem: The condition of any backup is unknown until a restore is attempted. Let me add that you should try to recover as well to sleep well at night. And thanks to Luiza Nowak and the POUG for this cool t-shirt 🙂

And thanks to my team mates who added the target_pdb_name option to give your non-CDB a new name. This is your chance – but you could rename it afterwards as well if needed.

We received already some enhancement requests – so more flexibility may be added soon.

My config file

Please find here the config file I was using for the demo:

global.autoupg_log_dir=/home/oracle/upg_logs
global.target_home=/u01/app/oracle/product/19
global.target_version=19.7
global.restoration=no

upg1.upgrade_node=localhost
upg1.source_home=/u01/app/oracle/product/12.2.0.1
upg1.dbname=DB12
upg1.sid=DB12
upg1.target_cdb=CDB2
upg1.target_pdb_name=PDBDB12
upg1.target_pdb_copy_option=file_name_convert=('/u02/oradata/DB12','/u02/oradata/CDB2/pdbdb12')
upg1.start_time=NOW
upg1.log_dir=/home/oracle/upg_logs
upg1.timezone_upg=no

upg2.upgrade_node=localhost
upg2.source_home=/u01/app/oracle/product/11.2.0.4
upg2.dbname=FTEX
upg2.sid=FTEX
upg2.target_cdb=CDB2
upg2.target_pdb_name=PDBFTEX
upg2.target_pdb_copy_option=file_name_convert=('/u02/oradata/FTEX','/u02/oradata/CDB2/pdbftex')
upg2.start_time=NOW
upg2.log_dir=/home/oracle/upg_logs
upg2.timezone_upg=no

If you’d like to repeat this exercise with our Hands-On Lab, you need to copy a newer version of the autoupgrade.jar into it at first.

Watch the video

If you’d like to see it live and in action, you may watch this video. In case you would like to watch the technical demo only, without explanation about how AutoUpgrade works, then please use this link instead as the demo starts at 4:45 min into the video.

Music provided by: https://www.frametraxx.de/info/gemafreie-musik-imagefilme.html

Enjoy!

More Information and Links

–Mike

Share this:

Tags:

You may also like...

71 Responses

  1. Vaithianathan says:
    May 20, 2020 at 16:42

    Hi Mike,

    Your blog and Hand-on Trainings are very useful. This one is classic, the “copy” option helps during Plan B situation! Thank You for the precise and clear explanation along with the video.

    Reply
  2. Tom de Jong says:
    May 24, 2020 at 07:41

    Hello Mike,
    Very useful command! Thank you for this wonderful website.
    Can the autoupgrade also be used to upgrade a database from 11.2 to 19c without the CDB conversion.
    I mean, is the autoupgrade a “good” replacement for dbupgrade?
    Kind regards,
    Tom

    Reply
  3. John says:
    May 26, 2020 at 12:11

    Some Comment

    Reply
  4. John Williams says:
    May 27, 2020 at 10:24

    Hi Mike. Thanks for the Video. Can the AutoUpgrade tool upgrade an Oracle Database 12cR2 Standard Edition to Oracle Database 19c Enterprise Edition and Plug Into Container? Thanks

    Reply
  5. John says:
    June 5, 2020 at 09:47

    OK, thanks Mike. One additional question. I noticed that exiting Oracle 19c sqlplus takes MUCH longer than under Oracle 11 / 12. I run this script:

    time sqlplus / as sysdba <
    NAME
    ———
    FULL11

    SYS @ full11 > Verbinding met Oracle Database 11g Enterprise Edition Release 11.
    2.0.4.0 – 64bit Production is verbroken.

    real 0m0.025s
    user 0m0.007s
    sys 0m0.005s
    /home/oracle [full11]
    $ oe
    ORACLE_SID = [full11] ? ctclone
    The Oracle base remains unchanged with value /u01/app/oracle
    /home/oracle [ctclone]
    $ ./timeit.sh

    SQL*Plus: Release 12.2.0.1.0 Production on Vr Jun 5 10:44:46 2020

    Copyright (c) 1982, 2016, Oracle. All rights reserved.

    Verbonden met:
    Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 – 64bit Production

    SYS @ ctclone >
    NAME
    ———
    CTCLONE

    SYS @ ctclone > Verbinding met Oracle Database 12c Enterprise Edition Release 12
    .2.0.1.0 – 64bit Production is verbroken.

    real 0m0.031s
    user 0m0.009s
    sys 0m0.005s
    /home/oracle [ctclone]
    $ oe
    ORACLE_SID = [ctclone] ? cupgdb
    The Oracle base remains unchanged with value /u01/app/oracle
    /home/oracle [cupgdb]
    $ ./timeit.sh

    SQL*Plus: Release 19.0.0.0.0 – Production on Vr Jun 5 10:44:57 2020
    Version 19.7.0.0.0

    Copyright (c) 1982, 2020, Oracle. All rights reserved.

    Verbonden met:
    Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production
    Version 19.7.0.0.0

    SYS @ cupgdb >
    NAME
    ———
    CUPGDB

    SYS @ cupgdb > Verbinding met Oracle Database 19c Enterprise Edition Release 19.
    0.0.0.0 – Production
    Version 19.7.0.0.0 is verbroken.

    real 0m1.020s
    user 0m0.007s
    sys 0m0.007s

    Any idea why it takes a much longer time to exit sqlplus in 19c?

    Thanks

    Reply
    • Mike.Dietrich says:
      June 11, 2020 at 21:32

      Hi John,

      my “feeling” is similar to yours – but I haven’t done any investigation on this yet.
      I fear you need to open an SR please, and let Oracle Support debug this.

      But my observation is similar to yours.

      Thanks,
      Mike

      Reply
  6. Melissa says:
    June 9, 2020 at 13:42

    Hi Mike,

    First your blog is AWESOME, thanks for the great info!

    Ok so I have been unsuccessful trying to upgrade a 11.2.0.4 database (all uppercase SID) to a pluggable 19c. I keep hitting a couple of issues I think may be bugs….

    Issue 1: Pfile references have inconsistent casing. During the process autoupgrade creates pfiles with the uppercase sid example of successful reference in log:

    2020-06-04 07:47:50.986 INFO Updating parameter *.cluster_database=’true’ to *.cluster_database=’FALSE’ in /home/oracle/upg_logs/EDMLABD/SASUKE1/temp/during_upgrade_pfile_SASUKE1.ora

    Later autoupgrade looks for the file with lowercase SID:
    2020-06-04 09:31:56.327 ERROR Pfile does not exist [/home/oracle/upg_logs/EDMLABD/SASUKE1/temp/during_upgrade_pfile_sasuke1.ora] Cannot start the database

    So I copied the existing uppercase pfile to the one autoupgrade is looking for with lowercase and resume autoupgrade and it moves on.

    Issue 2: I haven’t made it passed this one yet… Same test as above just later in the process. In this scenario I am not using the copy option in the config file so I am just letting defaults take hold.

    2020-06-04 09:37:52.594 WARNING Unable to validate the content of /home/oracle/upg_logs/EDMLABD/SASUKE1/temp/createpdb_sasuke.sql due to an invalid definition for fileNameConvertOption. The definition found was: “NOCOPY” The original value, N/A, will be used instead.
    2020-06-04 09:38:12.671 ERROR
    DATABASE NAME: SASUKE1
    CAUSE: ERROR at Line 8 in [Buffer]
    REASON: ORA-01122: database file 1 failed verification check
    ACTION: [MANUAL]
    DETAILS: 01122, 00000, “database file %s failed verification check”
    // *Cause: The information in this file is inconsistent with information
    // from the control file. See accompanying message for reason.
    // *Action: Make certain that the db files and control files are the correct
    // files for this database.

    Any thoughts?

    Thanks!

    Reply
  7. Norm says:
    June 11, 2020 at 20:20

    this is excellent Mike
    one question, I’m not sure it’s clear but we have a 12c db running on one node, say ‘sauce12’. I want to upgrade the db and plug in to a cdb running on a separate node, cdb19. Is this possible?

    thanks

    Norm

    Reply
    • Mike.Dietrich says:
      June 11, 2020 at 22:16

      Hi Norm,

      no, this is not possible – it has to be done all on one node. But if this is a RAC, you could run it on node “sauce12”, and once it is plugged it, copy all necessary files to node “sauce22” and start the PDB then there.

      Cheers,
      Mike

      Reply
      • Norm says:
        June 11, 2020 at 22:25

        Thanks Mike – this looked too good to be true…
        Which method would you recommend going from one 12c database on one host to a 19c cloud host? (Sorry for this lazy question)

        Thanks

        Reply
  8. Norm says:
    June 14, 2020 at 18:52

    thanks for responding Mike

    cloud host – OCI; Exadata CS

    the source is a 12.1.0.2 RAC (non-CDB) x3-2 on prem and the target will be a 19c RAC DB System (pdb) OCI

    I don’t want to take too much of your time but I’m looking at your second method: https://mikedietrichde.com/2019/07/24/database-migration-from-non-cdb-to-pdb-plug-in-upgrade-convert/

    I need to understand what the disadvantages of a shared UNDO will entail but I’ll be testing some of the migration options in the forthcoming weeks

    Reply
    • Mike.Dietrich says:
      June 14, 2020 at 21:01

      Hi Norm,

      ok – got you.

      Actually I’d recommend you at first to setup a standby in ExaCS with 12.1.0.2 RAC (non-CDB) to have your database there.

      Make sure BEFORE moving anything to upgrade:
      1. ExaCS software stack to the max
      2. Grid Infrastructure to 19c (19.6 or 19.7)

      Then deploy a 12.1.0.2 home, and a 19.6/7 home as well.

      Setup a standby between your source and ExaCS. This will decrease the amount of time to copy things over significantly.

      AutoUpgrade would help you only if you stay without wallets right now.
      Otherwise we have an “upgrade MOS note” which is non-public at the moment.

      Hope this helps – cheers,
      Mike

      Reply
  9. Norm says:
    June 14, 2020 at 21:11

    thanks Mike – your advice will be invaluable.

    I was going to mention a standby but didn’t want to confuse things..! There will be a 12c standby involved and fortunately TDE is not enabled at source but I will enable TDE on the 19c side.

    Reply
    • Mike.Dietrich says:
      June 15, 2020 at 07:40

      Hi Norm,

      but enable TDE only at the stage when EVERYTHING is completed. Otherwise (having no TDE on source, regardless if your source is on-prem or already in the cloud) things will get complicated. And online encryption (alter tablespace … encryption encrypt;) exists since 12.2.0.1 only but not in 12.1.0.2 yet. I just assume you planned this anyways, but I’d wanted to clarify at this stage.

      Cheers,
      Mike

      Reply
  10. Chris says:
    June 17, 2020 at 13:42

    Hi Mike,
    Like your Blogs!
    I can’t successfully upgrade and convert a 11.2.0.4 RAC database into a 19.6 PDB. The UPG shows a failure state at the end of the operation. The logs indicate it failed on spfile creation for source DB to ASM.
    The ori15t is the source database name. First SID is ori15t01.

    /upg_logs/ori15t/ori15t01/temp/after_upgrade_pfile_ori15t01.ora
    2020-06-05 21:19:32.963 ERROR Dispatcher failed: AutoUpgException [ERROR3007#Errors executing [CREATE SPFILE=’+D3CL001DG01′ FROM PFILE=’/oraadmin/workarea/19cUpgrade/AutoUpgrade/upg_logs/ori15t/ori15t01/temp/after_upgrade_pfile_ori15t01.ora’;

    Reply
  11. Vaithianathan says:
    June 18, 2020 at 15:36

    Hi Mike,

    Trying to upgrade a 12.1 Database to 19c and plug in as pdb . I have a CDB running on the same host.

    I have this parameter in the autoupgrade config file :

    upgrd1.target_cdb=cdb815s
    upgrd1.target_pdb_name=upgd05t
    upgrd1.target_pdb_copy_option=file_name_convert=(‘+DATA/UPGD05T’,’+DATA/CDB815S/A7E9537F18DF3997E053223B180A561D’)

    I ran the autoupgrade in “analyze” mode and it completed successfully.

    Ran the autoupgrade in “deploy” mode :

    Database was upgraded successfully, when it try to create the PDB using the xml file it through an error message :

    SQL> old 1: create pluggable database “&pdbName” using ‘&xmlFilePath’ &fileNameConvertOption tempfile reuse
    new 1: create pluggable database “upgd05t” using ‘/vol/dbabin/upgrades/logs/upgd05t/upgd05t/102/noncdbtopdb/upgd05t.xml’ COPY file_name_convert=(‘+DATA/UPGD05T’,’+DATA/CDB815S/A7E9537F18DF3997E053223B180A561D’) tempfile reuse
    create pluggable database “upgd05t” using ‘/vol/dbabin/upgrades/logs/upgd05t/upgd05t/102/noncdbtopdb/upgd05t.xml’ COPY file_name_convert=(‘+DATA/UPGD05T’,’+DATA/CDB815S/A7E9537F18DF3997E053223B180A561D’) tempfile reuse
    *
    ERROR at line 1:
    ORA-65180: duplicate file name encountered –
    +DATA/UPGD05T/DATAFILE/sysaux.266.1042904759

    SR#3-23339578151 was submitted.

    Thanks
    Vaithianathan

    Reply
  12. Vaithianathan says:
    June 25, 2020 at 21:29

    Hi Mike,

    I sent you a question about copying datafiles in ASM as part of upgrade, convert and migrate the Database to PDB. You suggested me to use the autoupgrade config parameter “target_pdb_copy_option”.

    I tested the parameter with multiple options :

    upgrd1.target_pdb_copy_option=file_name_convert=(‘+DATA/’,’+DATA/’)

    upgrd1.target_pdb_copy_option=file_name_convert=(‘+DATA/’,’+DATA//’)

    but it through me this error : ORA-65180: duplicate file name encountered !

    The one which worked :

    upgrd1.target_pdb_copy_option=file_name_convert=(‘+DATA/’,’+DATA’).

    It copied the files from +DATA/ to +DATA// —- Exactly what I wanted.

    Thanks
    Vaithianathan

    Reply
  13. Srini says:
    July 6, 2020 at 10:56

    Hi Mike,
    Worth reading your blog, thanks a lot !!

    What if I do not want to rename my non CDB database after autoupgrade & auto-plug?
    Can I just remove below parameter from my config file or I need to use the current DB name –

    Suppose my DB name is DB12HR

    parameter will be

    upg1.target_pdb_name=DB12HR
    OR
    upg1.target_pdb_name=
    OR
    remove this parameter

    Thanks,
    Srini

    Reply
  14. Frank Gerasch says:
    July 19, 2020 at 17:00

    Hi Mike,

    I’d like to upgrade and plugin a 12.2 Non-cdb to 19c CDB. Both databases are using OMF. The value “file_name_convert=(‘/u02/oradata/old’,’/u02/oradata/new’)” for parameter target_pdb_copy_option does obviously not work (ORA-01276). Is there another value for parameter target_pdb_copy_option to get it work using OMF?

    In other words, does AutoUpgrade support Non-CDB to PDB conversion using OMF?

    Best Regards
    Frank

    Reply
  15. prakash says:
    July 29, 2020 at 12:55

    if the target is different server the doc is not very clear ,it just says
    Complete the tasks to move the source Oracle Database from the source server to the target server.

    Reply
  16. Marcelo says:
    August 17, 2020 at 18:14

    what are the other parameters of target_pdb_copy_option? you can give an example of COPY (since the default is nocopy).

    It is impossible to find examples of the COPY parameter and the other parameters. Everyboby says the same.

    Reply
  17. Nelson says:
    September 9, 2020 at 06:33

    Is it possible to use autoupgrade to take a non-CDB 19c database and plug it into a 19c CDB?

    Reply
    • Mike.Dietrich says:
      September 9, 2020 at 09:06

      Yes – I will blog about this later this week as well.

      Have source and target home parameters the same.
      Define your precreated CDB with target_cdb=…
      And that’s it – but make sure the same components are installed, and the same version etc.

      Cheers,
      Mike

      Reply
  18. goran says:
    September 14, 2020 at 17:05

    Hello Mike,

    Thank you very much for very informative blog.

    In case I want to un-plug PDB from “source” 12.2 CDB and plugin (with upgrade) to target CDB version 19c, how ‘AutoUpgrade’ tool handle such scenario?
    What are rollback options?
    Is the whole upgrade & rollback process ‘automated’ or there are manual steps?

    Thanks.
    Goran

    Reply
  19. Davide says:
    November 11, 2020 at 12:15

    Hello Mike,
    I’ve tried to upgrade and convert to PDB a RAC database 12.1 to 19.5 using autoupgrade tool and everything went smoothly.
    I saw there are other comments about this but I don’t understand why it is trying to do what it is doing.
    Why after having successfully converted to PDB

    2020-11-10 14:06:23.810 INFO Completed job NONCDBTOPDB – DeployExecuteHelper.apply2

    It tries to start the source database from the new OH (19c)

    2020-11-10 14:06:23.810 INFO Starting the after upgrade RAC stuff – DeployExecuteHelper.manageRACInTarget

    This is my configuration file

    Thanks
    Davide

    Reply
    • Mike.Dietrich says:
      November 16, 2020 at 22:34

      Hi Davide,

      which version of AU are you using? If you use the 19.9.2 or 19.10 version already, I will need an SR with your logs (java -jar autoupgrade.jar -config yourconfig.cfg -zip) uploaded. Please share the SR number with me, and I can have a look into it.

      Cheers,
      Mike

      Reply
  20. Chris says:
    November 16, 2020 at 15:25

    Hi Mike,
    Can 19.10 jar handle Non-CDB RAC to 19c PDB RAC databases?

    Reply
    • Mike.Dietrich says:
      November 16, 2020 at 22:30

      Yes, it can, as long as you don’t use TDE.
      But it is not officially supported as a feature. Hence, if it fails, Support won’t give you support right now.

      Cheers,
      Mike

      Reply
  21. Chris says:
    November 16, 2020 at 23:41

    Mike,
    Thanks for the quick response. I encountered UPG-1699 and it failed at the plugging phase when it tried to create spfile in ASM for the PDB. I do not know why a spfile for PDB is needed. SR 3-24523491964 was created but the Support says ‘NonCDB to PDB on RAC system is not supported’.

    Reply
  22. Chris says:
    November 17, 2020 at 15:13

    Mike,
    Thanks for the clarification. It helps.
    I have two follow up questions: 1) Any plan to support this feature on RAC officially? I believe it is officially supported for NON-RAC, correct? 2) Why does autoupgrade try to create spfile for PDB in ASM? Does it happen for RAC only?

    Reply
  23. David Janes says:
    November 23, 2020 at 11:16

    Hi Mike
    I am trying to upgrade a 11.2.0.4 database to 19.8 PDB.
    I have installed 19.3, patched to 19.8, Used DBCA to create CDB called CDB. No PDBs were created.

    I can sqlplus to both databases fine and the 11g database is open:

    select INSTANCE_NAME, STATUS from v$instance;
    orcl OPEN

    select name from v$database;
    ORCL

    show parameter db_unique_name;
    db_unique_name string orcl

    However when i run analyze i get the following error:

    ———— ERROR ————
    Error Cause: Database orcl shutdown or open with incorrect binaries for ANALYZE. Ensure it is open with /u01/app/oracle/product/11.2.0
    ———— ERROR ————
    Error Cause: Database orcl open with status CLOSED. For ANALYZE mode, open it with one of the following: [OPEN, MOUNTED].
    Unable to connect to database orcl for entry upg1

    Any ideas please?

    Thanks

    Reply
  24. David Janes says:
    November 24, 2020 at 15:44

    Hi Mike

    I am using this version of Java
    $ java -version
    openjdk version “1.8.0_272”

    $ /u01/app/oracle/product/11.2.0/dbhome_1/jdk/bin/java -version
    java version “1.5.0_51”
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_51-b10)
    Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_51-b10, mixed mode)

    $ /u01/app/oracle/product/19.0.0/dbhome_1/jdk/bin/java -version
    java version “1.8.0_251”
    Java(TM) SE Runtime Environment (build 1.8.0_251-b08)
    Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode)

    I’ve tried setting ORACLE_HOME and SID to the 11.2 and the 19 values. Currently it’s set to start both databases from the 19c home with both entries in oratab set to Y.

    I added a more detailed post on Oracle Communities:
    https://community.oracle.com/mosc/discussion/4481606/autoupgrade-failing-database-orcl-shutdown-or-open-with-incorrect-binaries-for-analyze/p1?new=1

    Thanks

    David

    Reply
  25. Nelson says:
    November 26, 2020 at 00:48

    Please make sure the sid in the autoupgrade confile file has the same case as the value against the ORACLE_SID environment variable.

    Reply
  26. Paul McManus says:
    June 29, 2021 at 12:27

    Hi Mike

    Do I need to pre create my 19c CDB using the later versions of Auto upgrade?

    If the CDB does not exist – does Autoupgrade create it for me?

    Reply
    • Mike.Dietrich says:
      June 29, 2021 at 12:31

      Hi Paul,

      you need to precreate your target CDB with DBCA (Database Configuration Assistant). AutoUpgrade does not create this PDB for you.

      Cheers,
      Mike

      Reply
      • Paul McManus says:
        June 30, 2021 at 11:33

        Thanks for the quick response Mike – appreciated

        Is that a future enhancement by any chance?

        Reply
        • Mike.Dietrich says:
          July 1, 2021 at 17:08

          Hi Paul,

          not within AutoUpgrade.

          BUT … you can easily pass on a script with the upg1.before_action option. This script can call DBCA with a response file or in silent mode. Be aware that this will slow down the “upgrade” certainly as the upgrade will just start once the “before_action” has been completed and returned a “Y”.

          Cheers,
          Mike

          Reply
  27. sachin waghmode says:
    September 1, 2021 at 11:01

    HI Mike,

    is AutoUpgrade will work if TDE is enabled for non-CDB database?

    Thanks,
    Sachin

    Reply
  28. Sachin Waghmode says:
    September 28, 2021 at 09:26

    Thanks Mike for update .

    Autologin should be enable in Source and target database correct?

    Thanks,
    Sachin

    Reply
  29. Christian Floreck says:
    December 11, 2021 at 11:04

    Hi Mike
    Thanks for the blog.
    However, on Windows I’ve run into an nasty problem.
    First analyze runs fine. If you run “fixups” or even another analyze autoupgrade complains I could not create the xml file for the pdb.
    I’ve found the solution here:
    https://a-different-view-by-js.blogspot.com/2020/01/virtual-service-accounts-and-PDB-plugin-errors.html

    Regards
    Christian

    Reply
  30. CFL says:
    December 13, 2021 at 11:19

    Not working under Windows…
    Hi Mike,
    I tried several hours to get this running under Windows – no success.
    I figured out the cause:
    The autoupgrade runs as OS User (mostly Administrator) and creates an directory structure.
    Now, the Database (running as oracle) tries to access the xml File – but has no rights to read it.
    (As structure belongs to Administrator).
    It would be greate, if someone give me a helping hand.
    If this way is not supported on Windows – well, then autoupgrade should note this.
    Thanks
    Christian

    Reply
  31. Mustafa KALAYCI says:
    March 20, 2022 at 20:31

    Hi Mike,

    thanks for your amazing posts. I learned a lot. last 10 days, I am trying to migrate non-cdb to pdb via autoupgrade but job is STOPPED at compatiblity check step every time. I realized that “set timing on” clause in my glogin.sql file is causing this. probably, autoupgrade should execute a “set timing off” before it’s scripts. I explained it at my blog: http://mustafakalayci.me/2022/03/20/666

    I would be glad if you check it.

    Reply
  32. Zahid Malik says:
    April 10, 2022 at 21:01

    Hi Mike, Congratulations on a great site and superb videos. Your enthusiasm and knowledge persuaded me to use autoupgrade as the preferred method of upgrading 11/12c databases to 19c. Started with a direct 11.2.0.4.0 to 19c (patched to 19.12) and it worked a treat. Very impressed with the tool. However tried a couple of 12.2 databases and have had problems. One that is confusing me is “The target_cdb database CDBCOMP2 does not use the CDB architecture that will be required for database NCDB1”. CDBCOMP2 was created as a custom container database on 19c patched to 19.12 with no pdbs just the seed. Spent a whole day trying to find a workaround with no luck. Any ideas would be much appreciated, Cheers, Zahid (UK)

    Reply
    • Mike.Dietrich says:
      May 15, 2022 at 19:36

      Hi Zahid,

      thanks for your feedback. And sorry to get back to you quite late.
      Is this still an issue? If yes, then I need to see the config file and the error you receive.

      Thanks
      Mike

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mike Dietrich
Oracle Senior Director of Product Manager for Database Upgrade, Migrations and Patching writing just another blog.

Opinions certainly are my own as is this page.

Archives

Categories

Upgrade @YouTube

Subscribe via Email

Join 7,849 other subscribers

Follow me on Twitter