Virtual Technology Summit with Hands-On Labs!

VTS Virtual Technology Summit

If you are at all interested in upgrade to Oracle Database 12c, you really should sign up for the Virtual Technology Summit for February. This is a “pseudo-live” event with recorded webcasts and live experts online to answer questions. Even better, it includes a hands-on lab that will take you through the process of:

  1. Upgrading from to
  2. Plugging that upgraded database in as a PDB
  3. Migrating a second database to a second PDB using the new Full Transportable Export/Import feature

The Virtual Technology Summit will run three times:

and it has content for developers and sysadmins as well as DBAs.

So, sign up now and get a head start by downloading the hands-on lab VM image here:

We think you will find the VM environment really useful to keep around for those times when you want to try something out, without having to install binaries or create databases.


Share this:

4 thoughts on “Virtual Technology Summit with Hands-On Labs!

  1. Oliver,

    nein – das macht Roy. Das Event ist aber aufgezeichnet, Fragen etc wird meine Chefin und ein Kollege aus UK beantworten. Ich bin leider unterwegs …

    VG Mike

  2. Hi Mike,

    I have recently upgraded my rman catalog db from to upgrading Database components steps(Step2) it took almost 2 hours..

    Is that normal time involved using dbua?

    Will manual upgrade reduce the upgrade time?

    What will PAR time for to upgrade?


    I have followed all the pre-upgrade script and I have 0 errors and 1 INFO(timezone).

    Any insight will be more helpful.

    Pls advice.

    Thank you.


  3. Krishnan,

    Your question might be the most common one about upgrades : what is a "normal" upgrade time?

    First, I will note that DBUA and manual upgrades perform exactly the same operations and should take exactly the same amount of time. So, it is not an issue of using DBUA or not.

    Upgrade duration is affected by many factors, including:
    -Number of components and options installed in the database
    -Number of parallel processes used (because you upgraded to
    -Number of objects in the dictionary (a "select count (*) from OBJ$" is a good start to check this
    -Use of incremental stats on partitioned tables (for>12.1, or>
    -CPU speed
    -Storage speed

    Offhand I would say that 2 hours for an upgrade is on the long side of things, but that would depend on the above factors. A typical upgrade is usually in the 20-90 minute range, so in your case I would need to see the upgrade log to determine whether there were particular steps that took longer than expected, whether the entire upgrade seems slow, etc. Sometimes the cause for a slow upgrade can be systemic (e.g. a slow storage subsystem), other times it could be due to your particular database or other reasons.

    The best way to diagnose this would be to file an SR and have support look at your upgrade logs. We have a good team in the install/upgrade space.

Leave a Reply

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

* Checkbox to comply with GDPR is required


I agree

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