Friday Apr 11, 2014

Why cows can fly! Believe it or not ...

A colleague of mine, Murilo from Oracle Brasil talked about our roles at Oracle (but this applies to any other software company in the market I'd guess).

Do you believe in flying cows?

  • Sales
    In Sales you'll sell a customer that cows can fly
  • Presales
    The presales consultant will have to do a presentation showing the ROI, TCO and KPIs of flying cows. She or he may have also a screenshot demo in Powerpoint showing flying cows. 
  • Consulting
    The consultant is the person to install the flying-cow piece of software at the customer site and embedd it into the customer's environment. Unfortunately the poor consultant finds out that in this environment cows actually don't fly well. In fact, cows don't fly at all. So the consultant may raise an SR before going home.
  • Support
    The SR gets into the queue of a Support engineer somewhere in the world. The Support engineer wonders about this SR as she or he has never heard of flying cows before. So she/he takes a look into the doc. And there's nothing mentioned about flying cows. But the doc doesn't say anything about "cows can't fly" so a testcase will be required from the customer or the consultant to show the non-flying cows. Poor Support engineer: she/he can't even file a bug for it as the doc doesn't say anything about the flying-cow-feature. 

Guess how that story will end?
Does it sound familiar to you? To me it does ... a bit ;-)
And I'm glad that I'm working in Development :-)

So you may watch this tiny little video in your spare time ...


PS: Thanks to Murilo - and I phrased it in my own words as I still burst out laughing and crying at the same time when thinking about our conversation :-) But credits go to him - obgrigado!!!

PPS: No offense to anybody in any role in a software company ... 

Thursday Mar 13, 2014

Do you know?
Premier Support for Oracle 11.2 will end soon!!!

Do you know that Oracle Database 11.2 will run out of PREMIER SUPPORT in less than 11 months?

Well. you may mention now the waived first year of free EXTENDED SUPPORT but this will apply to Oracle Database (and to Oracle Database until Aug 27, 2015) only!!! Now if you think of upgrading to Oracle within the next months start thinking more into the direction of Oracle Database 12c instead. There won't be much difference in efforts and the amount of time you'll spend, regardless if you'd like to Oracle Database or Oracle Database 12c.

Don't waste your time, resources and money - start evaluation Oracle Database 12c today!!! 

Now a bit of clarification as somebody has raised this question:
MOS Note:209768.1 Error Correction Policy describes clearly what you can expect after the Premier Support for Oracle Database 11.2 has ended.

  • Error correction is only available for the: 
  • Current patch set, and 
  • Previous patch set, for the duration of the Grace Period
  •  What does the Grace Period mean?

    Grace Period: up to 1 year for first patch set (minimum 3 months), and up to 2 years for second and subsequent patch sets. 

    • First Patch Set: Customers on all platforms have up to one year from the release of the first patch set on the first platform of a major release to install it.

    • Second and Subsequent Patch Sets: For the second and any subsequent patch set release, customers on all platforms have up to two years from the release of a new patch set to install it. 

    As an example, for release X.Y (base release version X.Y.0.1): 

    • First patch set for (X.Y.0.2) comes out on Linux x86-64 in September 2010. Customers on all platforms have until September 2011 to install it. 

    • Second patch set (X.Y.0.3) comes out in September 2011. Customers would have two years – until September 2013 – to install X.Y.0.3. 

    • Third patch set (X.Y.0.4) comes out in July 2013, customers have until July 2015 to install it.

    During the grace period we will create new bug fixes for the previous patch set and the current patch set.

    Patching end dates for current and most recent patch sets can be found on My Oracle Support in Release Schedule of Current Database Releases (Doc ID 742060.1)


    I appologize but I got used to Support policies for 18 years now and therefore got to learn about something which got removed with Oracle Database The direct combination of "Terminal Patch Set" and "Extended Support" has been removed a while back (and I didn't know it). That means (and the above posting has been corrected already):

    In order to get Extended Support for Oracle Database 11.2 you will have to be on Oracle Database (the terminal patch set) or on Oracle Database In the latter case patching will end by August 27, 2015 - which is described clearly in MOS Note: 742060.1

    Release Patching Ends

    Exceptions* 31-Jan-2018
    HP-UX Itanium: Patching ends Dec 2020. Beginning Feb 1, 2018, Sev 1 fixes only (no PSU or CPU will be produced). 27-Aug-2015 31-Oct-2013
    End date extended beyond normal.

    Tuesday Mar 04, 2014

    Upgrade to Grid Infrastructure - but OCR and VOTING on RAW?

    Just received this question from a colleague these days:

    "The current customer environment is on Linux with a 2 node RAC cluster having OCR and Voting Disks on RAW devices. Customer is concerned about the possibility of upgrading to 11gR2 Grid infrastructure first before they could upgrade to 12c Grid infrastructure."

    Now the answer is written down in MOS Note 1572925.1:
    How to Upgrade to 12c Grid Infrastructure if OCR or Voting File is on Raw/Block Devices

    Basically the MOS Note says:
    You will have to relocate your OCR/Voting to a supported device BEFORE you can upgrade to Oracle Grid Infrastructure 12c. No way out. A bit more clarification (thanks to Markus Michalewicz):

    The assumption of the note (which you might want to state) is that the customer has pre-12c GI with OCR / Voting Disk on RAW.

    In this case, Option A is always an option.

    For Option B, however, you need to distinguish. So the note should say: 

    • Option B: Customer is on 11g Rel. 2 still using RAW Devices 
      • Then move the OCR and Voting Disks to ASM
    • Option C: Customer is on pre-11g Rel. 2 and does not want to introduce a CFS (bad idea anyways) or use NFS
      • Then upgrade to 11g Rel. 2 and move the Clusterware files into ASM as mentioned under Option B.

    Unfortunately another example to add to my collection of "What happens if you stay too long on older releases?". In this case it simply increases complexity and drives costs as well. And please no complaints: Oracle Database 10.2 went out of PREMIER SUPPORT in July 2010 - 3.5 years ago!!!


    Thursday Feb 27, 2014

    CSX Corporation Upgrades Databases 2x Faster With Oracle Real Application Testing

    Wow - one of our reference projects went into the Yahoo Finance webpages. Carol Tagliaferri (my direct manager) worked with CSX, one of the largest US based railway companies, over a longer period together with the RAT team, and helped CSX to successfully upgrade and migrate their database landscape to Oracle Database 11.2.
    Plus: We did present about CSX at Oracle Open World 2012 as this project is a perfect showcase for:

    (a) an Upgrade project with many databases
    (b) over a longer period of time
    (c) using Real Application Testing decreasing the testing effort by factors!

    Read the published article on Yahoo Finance!

    And that is what Maritza Gonzalez, Technical Director at CSX said:

    “The Real Application Testing tool provided a comprehensive and flexible solution for assessing the impact of the Oracle 11g database upgrade  into CSX systems.  At CSX we were able to capture real production workloads,  replay it in the 11g environment,  identify poor performing  queries and, fine tune these queries in a test environment  before the production implementation.“

     More details on the actual project are included in our OOW 2012 talk (slides 35-42).

    Graphics are courtesy linked directly from the CSX public webpage

    Tuesday Feb 25, 2014

    Simplify your Migration from AIX to Solaris

    Oracle Solaris 11There is a brand new white paper available that will be of interest to anybody contemplating a database and/or application migration from AIX to Solaris. Simplify the Migration of Oracle Database and Oracle Applications from AIX to Oracle Solaris gives a good description of the steps involved in planning and executing a migration project, along with the benefits you can expect to achieve and a solid example of migration using Oracle Data Pump, complete with scripted steps.

    Of course, if your migration will include moving up to Oracle Database 12c, don't forget to sign up for Mike's webcast on February 26!

    Thursday Feb 13, 2014

    Collaborate '14 Early Bird Registration ends Today!

    Mike and I are in Sydney, Australia delivering an upgrade workshop today, but I am also looking forward to the Collaborate '14 conference in April. I will have a talk about upgrading to Oracle Database 12c, and of course there will be plenty of information about Oracle Multitenant, applications, and other aspects of your Oracle environment. 

    Collaborate 14 banner

    Early bird registration ends today, so if you want to save some money and attend a conference that is always chock full of good technical presentations, register today!

    Tuesday Feb 11, 2014


    Just learned something new I couldn't find actually in the doc at the first glance:

    There's a new init.ora parameter introduced in Oracle Database named:

    By default it is set to FALSE and the parameter got introduced because not only the external use of Oracle GoldenGate requires a valid license but also the use of the internal APIs. For example, XStream provides high performance APIs that enable client applications to receive and send real-time data changes from an Oracle database. Other APIs were added for encryption support, trigger suppression, etc. None of these APIs are licensed with the Oracle database itself - the license is included with an Oracle GoldenGate license, and most of the APIs are not public.

    So please make sure if you turn ENABLE_GOLDENGATE_REPLICATION=TRUE that you'll need to have a valid Oracle GoldenGate license in place.

    That will apply to 3rd party products such as Dell Shareplex as well in case they'll switch it to true.


    Addition: As a customer talked to me about that during the Sydney workshop last week I'd like to point out that this paramater does not effect the use of Oracle GoldenGate as a stand-alone tool but only the internal interfaces inside the database.

    Monday Dec 16, 2013

    Why you shouldn't set OPTIMIZER_FEATURES_ENABLE

    Roy today answered an interesting question on one of our internal mailing lists. And this reminds me to pick up that piece of information as we see this quite often on customer sites, especially after upgrades or migrations. People set OPTIMIZER_FEATURES_ENABLE (OFE) to revert the optimizer's behaviour to another pre-current release. That's what a lot of people think this parameter does.

    But in fact this is not true. Even though our documentation states it:

    OPTIMIZER_FEATURES_ENABLE acts as an umbrella parameter for enabling a series of optimizer features based on an Oracle release number.

    For example, if you upgrade your database from release 10.1 to release 11.1, but you want to keep the release 10.1 optimizer behavior, you can do so by setting this parameter to 10.1.0. At a later time, you can try the enhancements introduced in releases up to and including release 11.1 by setting the parameter to

    In my experience the following is true:
    Setting this parameter reverts the optimizer settings in terms of parameters - but we still use the new optimizer code from that release you are on now. And as far as I know nobody ever tests if switching back OFE will turn back to exactly the behaviour as it was known in the release OFE is now switched to. So it's simply guessing and assuming. But as code got changed there's very little chance to get back to the old behaviour. 

    What people sometimes  experience:
    Turning back OFE brings back good performance. This can happen. But if we act really really really precise than the performance should always be better with the optimizer running with the new settings - and not when the wheel is turned back. So in some cases this should be treated as a bug unless new behaviour leads to predictable worse results (such as more buffer gets etc). And I get so angry when Oracle Support people recommend to switch OFE to this or that setting to cure one or the otther misbehaviour. That's like throwing a big rock to kill a fly. 

    But the real danger is described in the following note - and I'm pretty sure a lot of people are not aware of this:
    Reverting the optimizer parametrization with OFE can turn back to misbehaviour which got fixed already in the current release. MOS Note:1581465.1 describes this pretty well.

    And in addition regarding upgrades you may want to read this note here as well:
    MOS Note: 1362332.1
    Use Caution if Changing the OPTIMIZER_FEATURES_ENABLE Parameter After an Upgrade
    (Thanks Roy!)

    Stay away from tweaking anything with OFE. Use Real Application Testing's SQL Performance Analyzer (SPA) to find out which plans get changed and use SQL Plan Management (SPM) to nail down misbehaving plans in 11g or 12c.


    Friday Dec 06, 2013


    The Oracle Database 12c Interactive Quick Reference is a nice little tool which may help you quickly to find a view you are searching for or to get more information about background processes in Oracle Database 12c.

    Click through it:


    Tuesday Dec 03, 2013

    Starting up 252 PDBs automatically?

    In my recent posting I have explained the startup of many PDBs at the same time.

    But once you startup the container database CDB$ROOT the PDBs will stay in MOUNT status. So how do you start them during CDB$ROOT startup (or immediately afterwards) in an automatic fashion?

    A startup trigger will do this job.

    CREATE OR REPLACE TRIGGER startup_all_pdbs





    And of course you can use the EXCEPT command option to exclude one or more PDBs from the automatic startup.

    CREATE OR REPLACE TRIGGER startup_all_pdbs_except_a_few


    How does this work in an Oracle Real Application Clusters environment?
    In an RAC environment you won't need the startup trigger as clusterware takes over this role of ensuring the automatic startup of a PDB on designated nodes within the CDB$ROOT's instances.

    srvctl add service -db rac -service pdbrac_srv -pdb pdbrac -preferred "rac1,rac2"

    A snipet from the crsctl status output will look like this:

       crsctl status resource -t
             1    ONLINE  ONLINE   rac-server01       Open,STABLE
             2    ONLINE  ONLINE   rac-server02       Open,STABLE
             1    ONLINE  ONLINE   rac-server01       STABLE
             2    ONLINE  ONLINE   rac-server02       STABLE


    Friday Nov 29, 2013

    Starting up 252 PDBs in Oracle Multitenant

    What happens when you start up 252 PDBs (Pluggable Databases) with the Oracle Multitenant Option for the first time?

    Interesting question, isn't it? The expectation would be that this will happen within seconds as the SGA and therefore the shared memory segments are already allocated from within the CDB$ROOT (Container Database). But ...

    The following happens:
    It takes minutes ... hours .... In my tiny lab environment with just as little as 20 PDBs due to space constraints it takes over 30 minutes to startup 21 PDBs. Takashi Ikeda from Fujitsu Hokoriku Systems who did a great demo with the new Fujitsu M10 servers at OOW this year told me that it took over two hours to start up 252 PDBs for the first time.
    Why is that?

    Let's have a closer look into the alert.log during startup. After issueing the command:


    I'd expect all PDBs to get started. With an EXCEPT PDB1, PDB2, PDB3 clause I could exclude some PDBs from this action. Now a look into the alert.log shows a very promising message:

    I'm just wondering about the opening sequence of PDBs. I'd expect 1 ... 2 ... 3 ... 4 ... ... ... 21. But the "order" is 3 ... 10 ... 16 ... 15 ... 20 ... 21 etc. telling me that the Resource Manager is not active (which is a must if you take Multitenant serious).
    OK, for that strange order there's an explanation:
    The open action gets distrubuted to slaves so PDBs may opened in a random order.
    Fuuny thing apart from that: I can access the PDB but the system seems to be really under heavy pressure. CPUs are all at 100%. What the heck is going on here in the background?

    Well, XDB needs to be installed (at least that is what the message says). Strange, isn't it, as the PDB$SEED has XDB in it and all my PDBs got provisioned from it. The awkward thing here is that the XDB messages appear over 20 minutes AFTER the PDBs signaled the Opening message into the alert.log (see the time stamps above).

    Now after exchanging a few emails with some very helpful people in development there's an explanation for the XDB messages as well. Actually it doesn't get really installed but the SGA needs to be initialized for XDB. And I'm guessing that this action takes a lot of resources plus may cause contention when many PDBs get opened at the same time. And there's optimization work going on right now meaning that a problem with port initialization within the PDB will get fixed in a future patch set. So this issue with the very long startups of PDBs because of XDB should disappear in most likely :-)

    Finally it took another while to get the PDBs really into OPEN mode. Even though they were showing OPEN before already in V$PDBS. But as the CPUs all went to 100% as XDB got installed/initiallized at more or less the same time in all PDBs you really can't do anything.

    Finally ...

    ... all PDBs got opened and the command ALTER PLUGGABLE DATABASE ALL OPEN returned completed.

    The good news:
    It takes just this long during the initial startup of a newly provisioned PDB. And you may see this issue only when you try to open many PDBs at the same time. But have a close look into your alert.log if you'll spot the message after creating a fresh PDB.

    And btw, just for the records: I was using Oracle Database with Oct 2013 PSU in it.


    Wednesday Nov 13, 2013

    Why people don't patch and upgrade?!?

    Please see the JAPANESE version of this blog post here!!

    Discussing the topic "Why Upgrade" or "Why not Upgrade" is not always fun. Actually the arguments repeat from customer to customer. Typically we hear things such as:

    • A PSU or Patch Set introduces new bugs
    • A new PSU or Patch Set introduces new features which lead to risk and require application verification 
    • Patching means risk
    • Patching changes the execution plans
    • Patching requires too much testing
    • Patching is too much work for our DBAs
    • Patching costs a lot of money and doesn't pay out

    And to be very honest sometimes it's hard for me to stay calm in such discussions. Let's discuss some of these points a bit more in detail.

    • A PSU or Patch Set introduces new bugs
      Well, yes, that is really true as there's no software containing more than some lines of code being bug free. This applies to Oracle's code as well as too any application or operating system code. But first of all, does that mean you never patch your OS because the patch may introduce new flaws? And second, what is the point of saying "it introduces new bugs"? Does that mean you will never get rid of the mean issues we know about and we fixed already? Scroll down from MOS Note:161818.1 to the patch release you are on, no matter if it's or and check for the Known Issues And Alerts.
      Will you take responsibility to know about all these issues and refuse to upgrade to I won't.

    • A new PSU or Patch Set introduces new features
      Ok, we can discuss that. Offering new functionality within a database patch set is a dubious thing. It has advantages such as in where we backported Database Redaction to. But this is something you will only use once you have an Advanced Security license. I interpret that statement I've heard quite often from customers in a different way: People don't want to get surprises such as new behaviour. This certainly gives everybody a hard time. And we've had many examples in the past (SESSION_CACHED_CURSROS in,  _DATAFILE_WRITE_ERRORS_CRASH_INSTANCE in and others) where those things weren't documented, not even in the README. Thanks to many friends out there I learned about those as well. So new behaviour is the topic people consider as risky - not really new features. And just to point this out: A PSU never brings in new features or new behaviour by definition!

    • Patching means risk
      Does it really mean risk? Yes, there were issues in the past (and sometimes in the present as well) where a patch didn't get installed correctly. But personally I consider it way more risky to not patch. Keep that in mind: The day Oracle publishes an PSU (or CPU) containing security fixes all the great security experts out there go public with their findings as well. So from that day on even my grandma can find out about those issues and try to attack somebody. Now a lot of people say: "My database does not face the internet." And I will answer: "The enemy is sitting already behind your firewalls. And knows potentially about these things."
      My statement: Not patching introduces way more risk to your environment than patching. Seriously!

    • Patching changes the execution plans
      Do they really? I agree - there's a very small risk for this happening with Patch Sets. But not with PSUs or CPUs as they contain no optimizer fixes changing behaviour (but they may contain fixes curing wrong-query-result-bugs). But what's the point of a changing execution plan? In Oracle Database 11g it is so simple to be prepared. SQL Plan Management is a free EE feature - so once that occurs you'll put the plan into the Plan Baseline. Basta! Yes, you wouldn't like to get such surprises? Then please use the SQL Performance Analyzer (SPA) from Real Application Testing and you'll detect that easily upfront in minutes. And not to forget this, a plan change can also be very positive!
      Yes, there's a little risk with a database patchset - and we have many possibilites to detect this before patching.

    • Patching requires too much testing
      Well, does it really? I have seen in the past 12 years how people test. There are very different efforts and approaches on this. I have seen people spending a heck of money on external licenses or on project team staffing. And I have seen people sailing blindly without any tests just going the John-Wayne-approach.
      Proper tools will allow you to test easily without too much efforts. See the paragraph above. We have used Real Application Testing in so many customer projects reducing the amount of work spend on testing by over 50%.
      But apart from that at some point you will have to stop testing. If you don't stop you'll get lost and you'll burn money. There's no 100% guaranty. You will have to deal with a little risk as reaching the final 5% of certainty will cost you the same as it did cost to reach 95%. And doing this will lead to abnormal long product cycles that you'll run behind forever. And this will cost even more money.

    • Patching is too much work for our DBAs
      Patching is a lot of work. I agree. And it's no fun work. It's boring, annoying. You don't learn much from that. That's why you should try to automate this task. Use the Database's Lifecycle Management Pack. And don't cry about the fact that it costs money. Yes it does. But it will ease the process and you'll save a lot of costs as you don't waste your valuable time with patching. Or use Oracle Database 12c Oracle Multitenant and patch either by unplug/plug or patch an entire container database with all PDBs with one patch at one time in one task.
      We have customer reference cases proofing it saved them 75% of time, effort and cost since they've used Lifecycle Management Pack. So why don't you use it?

    • Patching costs a lot of money and doesn't pay out
      Well, see my statements in the paragraph above. And it pays out as flying with a database with 100 known critical flaws in it which are already fixed by Oracle (such as in the Oct 2013 PSU for Oracle Database 12c) will cost ways more in case of failure or even data loss. Bet with me?

    Let me finally ask you some questions.

    What cell phone are you using and which OS does it run? Do you have an iPhone 5 and did you upgrade already to iOS 7.0.3? I've just encountered on my iPhone 5 that the alarm (which I rely on when traveling) has gotten now a dependency on the physical switch "sound on/off". If it is switched to "off" physically the alarm rings "silently". What a wonderful example of a behaviour change coming in with a patch set. Will this push you to stay with iOS5 or iOS6? No, because those have security flaws which won't be fixed anymore.And I tell you how I have found out that: I have tested the alarm after updating to iOS 7.0.3 as I heavily rely on that feature. I don't test everything as my time and my resource won't allow that - but I usually check the most important things.

    What browser are you surfing with? Do you use Mozilla 3.6? Well, congratulations to all the hackers. It will be easy for them to attack you and harm your system. I'd guess you have the auto updater on.  Same for Google Chrome, Safari, IE. Right?


    Wednesday Nov 06, 2013

    How to SET TIMING ON for parallel upgrades to 12c?

    Have you asked yourself how to get timings in an Oracle Database 12c upgrade for all statements?

    When you run the parallel upgrade via, the parallel upgrade Perl driving script in Oracle Database 12c, you may also want to get timings written in your logfile during execution. As does not offer an option yet the best way to achieve this is to edit the catupses.sql script in $ORACLE/rdbms/admin as this script will get called all time over and over again throughout all steps of theupgrade run.

    Just add these lines marked in RED to catupses.sql and start your upgrade:

    Rem =============================================
    Rem Call Common session settings
    Rem =============================================

    Rem =============================================
    Rem  Set Timing On during the Upgrade
    Rem =============================================

    Rem =============================================
    Rem Turn off PL/SQL event used by APPS
    Rem =============================================
    ALTER SESSION SET EVENTS='10933 trace name context off'


    PS: This may become the default in a future patch set ;-)

    Monday Sep 16, 2013

    Oracle Database 12c pre-upgrade scripts and JAVAVM

    This is a great example of why you should always review the README file when upgrading to a new release. Here is an issue that we found during customer beta testing, and that you will want to be aware of if you are upgrading to Oracle Database 12c and do not have the JAVAVM component in your database. The following text has been added to the 12.1 Readme under Section 1.1:

    TITLE: Pre-Upgrade Tool Does Not Generate Output Logs

    The pre-upgrade tool, preupgrd.sql, is not able to create a directory to
    store the output files if the JAVAVM component either does not exist in the
    database registry or is set to INVALID or OPTION OFF (reference Bug
    14614756). For example:

    SQL> @/tmp/preupgrd
    Loading Pre-Upgrade Package ...
    WARNING: Failed to open preupgrade.log for write access
       script will generate terminal output only
    WARNING: Failed to open preupgrade_fixups.sql for write access
       script will not generate fixup scripts.

    Results of the checks are located at:
    *** Scripts/Logs are not being Generated *** preupgrade.log

    The workaround is to manually create the output directory before running
    preupgrd.sql by executing the following steps:

    1. If ORACLE_BASE is defined in the environment settings, either create a
    directory $ORACLE_BASE/cfgtoollogs/<db-unique-name>/preupgrade or create a
    directory $ORACLE_HOME/cfgtoollogs/<db-unique-name>/preupgrade.

    2. To get <db-unique-name>, use the following query:

       SELECT value FROM V$PARAMETER WHERE NAME = 'db_unique_name';

       Note that <db-unique-name> used in the directory path is case sensitive.

    3. Rerun the preupgrd.sql tool.

    As you can imagine, your upgrade will be smoother if you are aware of issues like this before you upgrade instead of running into them on your go-live weekend!

    Thursday Aug 29, 2013

    Focus on Database Upgrade at OpenWorld 2013

    If you are going to Oracle OpenWorld in September, you might be overwhelmed by the sheer number of sessions throughout the week. ForOracle OpenWorld Logo those with an interest in database upgrade, I have prepared a Focus on Database Upgrade listing that lays out the sessions, demos, and hands-on lab for this area. Here is the listing thus far (NOTE: the list of sessions could change, so please check the document link at the start of OOW for the most current information!).


    Monday, Sep 23, 2013

    General Session: Oracle Database 12c—Engineered for Clouds and Big Data
    Andrew Mendelsohn, Oracle
    10:45 AM - 11:45 AM Moscone North - Hall D GEN8229

    Monday, Sep 23, 2013

    Consolidating Databases with Oracle Database 12c
    Bryn Llewellyn, Oracle
    Patrick Wheeler, Oracle
    12:15 PM - 1:15 PM Moscone South - 102 CON8707
    Different Ways to Upgrade, Migrate, and Consolidate with Oracle Database 12c
    Mike Dietrich, Oracle
    Roy Swonger, Oracle
    Carol Tagliaferri, Oracle
    3:15 PM - 4:15 PM Moscone South - 102 CON8176
    Mission-Critical Banking Systems Migration to Oracle Exadata: Lessons Learned
    Jason Reinhardt, CBA
    Sohan Demel, Oracle
    3:15 PM - 4:15 PM Moscone South - 308 CON9239
    Database Migration Best Practices and Oracle Migration Factory
    Ronald Carter, UBS
    Bharat Patel, Oracle
    4:45 PM - 5:45 PM Moscone South - 252 CON6054

    Wednesday, Sep 25, 2013

    Upgrade-Ready for Oracle Database 12c
    Michelle Malcher, DRW Holdings
    11:45 AM - 12:45 PM Moscone South - 236 CON7695
    Upgrade with Oracle Database 11g’s SQL Plan Management: Best Practices from Bank of America
    William Rice, Bank of America Merril Lynch
    Zimin Chai, Oracle
    11:45 AM - 12:45 PM Moscone South - 305 CON6938
    The Important Things DBAs Should Do Before and After an Oracle Database Upgrade
    Julian Dontcheff, Accenture Oy
    5:00 PM - 6:00 PM Moscone South - 236 CON1715

    Thursday, Sep 26, 2013

    Under the Hood of Pluggable Databases
    Alex Gorbachev, The Pythian Group Inc.
    11:00 AM - 12:00 PM Moscone South - 305 CON7593
    Cross-Platform Database Upgrades with Oracle GoldenGate
    Sharmila Kamath, Oracle
    Nalin Sahoo, Oracle
    2:00 PM - 3:00 PM Moscone South - 305 CON4286
    Oracle Database 12c Unicode Migration Moscone South, Left - SL-019
    Upgrade to Oracle Database 12c Moscone South, Left - SL-007

    Thursday Jul 18, 2013

    Full Transportable Export/Import White Paper

    One of the really cool and helpful features in Oracle Database 12c is called Full Transportable Export/Import. It combines the basics of transportable tablespaces - of course cross-platform, cross-endianess, cross-version - with Data Pump taking care on all the stuff not stored in tables and indexes, such as views, synonyms, trigger, packages etc. And you can even reduce downtime by combining the feature with incrementally converted RMAN backups.

    And the best thing: this will work with an Oracle Database to Oracle Database 12c - so you don't have to be on Oracle Database 12c in order to leverage from that cool new feature.

    See the brand new White Paper about Full Transportable Export/Import here:


    Wednesday Jul 17, 2013

    Oracle Multitenant (Pluggable Database) White Paper

    The feature we did introduce for a while now as Pluggable Database got named officially Oracle Multitenant - and if you'd like to read more about this feature the newly release White Paper may give you a good overview:


    Wednesday Jun 26, 2013

    New White Paper about Upgrade to Oracle Database 12c

    With the release of Oracle Database 12c many new collateral will be available right now including our new White Paper:

    White Paper:
    Upgrading to Oracle Database 12c

    This white paper outlines the methods available for you to upgrade and migrate your database to Oracle Database 12c.  Learn about different use cases and key factors to consider when choosing the method that best fits your requirements.

    And if you'd like to have a look into the new Oracle 12c documentation please find it here:

    Oracle Database 12c Documentation


    Monday May 27, 2013

    The MAGIC Questions

    Almost every week Roy, Carol and I receive one or more emails in the following style:

    "Hey, we (or my customer) plan(s) an upgrade to Oracle 11g. We (or the customer) wants zero downtime. Currently we (or they) are on AIX with Oracle 10g (and someold  9i) databases. Can we get an advice please?"

    or another one here ...

    "Upgrade from 8i to 11g. The customer's database is 28 TB (quite big!). Downtime is 5-6 hours. It's on AIX. And it's an it's an Oracle EBS database"

    Well, in both cases we lack a lot of useful information - or sometimes things are almost impossible or simply wishful thinking. So we have a collection of (we call them) The Magic Questions. Once those are answered upfront it is way easier to give a helpful advice.

    • Will you exchange the hardware?
    • Will you change to a new OS version?
    • Will you change to an entire new OS architecture?
    • Will you change the database characterset?
    • Do you plan to consolidate (schema/database/...)?
    • Number of databases you plan to upgrade or migrate?
    • Size of database(s)?
    • Exact source and target Oracle versions?
    • Maximum allowed downtime per database?
    • Fallback requirements?
    • Test environment available? Testing tools?
    • Does a performance baseline exist?
    • Changes required to enable new features?
    • RAC/Grid Infrastructure already in use or planned?

    Once we get the answer and (even more helpful) a sheet describing the entire landscape in more detail we will be able to give some advice.


    Thursday Jan 17, 2013

    Potential check for corruptions

    Having a corruption somewhere in the database is one of the worst case scenarios I could ever imagine - especially if it "sleeps" somewhere in the data dictionary. Recently I did talk to a customer who encountered a failing upgrade due to a data dictionary corruption gotten introduced in an earlier release.

    What can you do to check your database(s) prior to an upgrade or generally from time to time? Actually I know now two powerful possibilities: 

    • hcheck.sql
      See MOS Note:136697.1
      This script will check for known problems in Oracle8i, Oracle9i, Oracle10g and Oracle 11g.
      You will need to create
      hOut Helper Package first - please see MOS Note:101468.1 to download the script hout.sql
    • RMAN validation:
      RMAN> backup check logical validate database;
      See MOS Note:836658.1 for further details - and you can run this with multiple parallel channels to speed up the run

    Friday Oct 19, 2012

    Migration of a database from 32bit to 64bit

    Database migrations from an 32bit environment to an 64bit environment keeping the same platform architecture (e.g. moving an Oracle database from MS Windows XP 32bit to MS Windows Server 2003 64bit) does not happen that often anymore. But still we see them getting done. And there are a few things to note when doing such a move.

    First of all the important question is:
    Will you upgrade your database as part of this move - Yes or No?

    If you say "Yes" then you are almost done with that topic as we will take care of that bitnes move during the upgrade. The only thing you have to take care is OLAP in case you are using OLAP Option with Analytic Workspaces (AW) by yourself. Those store data in Binary LOBs - and in order to move AWs from 32bit to 64bit you have to export your AWs prior to the move - and import them later on. People who don't use OLAP don't have to take care on this. In that case you'll have to drop AWs after the export - please see MOS Note:386990.1 for further details.

    But if you say "No" (meaning: no upgrade actions involved - you keep your database version) then you have to make sure to invalidate all packages and stored code in the database before you shutdown your database in the 32bit environment and prior to moving it over. And the same rule as above for OLAP applies once you use the OLAP Option.

    In the source environment:

    startup upgrade;    -- [or startup migrate; -- for Oracle 9i]
    shutdown immediate

    In the destination environment:

    startup upgrade
    @?/olap/admin/xumuts.plb --Only if OLAP Option is installed

    The script utlirp.sql will invalidate all packages and stored code, utlrp.sql will recompile - and xumuts.plb will rebuild the OLAP Analytic Workspaces in case you have the OLAP Option installed.

    Thursday Oct 04, 2012

    OOW 2012:
    Under the Bridge ;-)

    Just some impressions ...

    Remember SF's landmark, Golden Gate bridge? Well ...

    Moon over Bay Bridge

    OOW 2012:
    Deutsche Messe on their SAP Database Upgades

    This Sunday Andreas Ellerhoff from Deutsche Messe (German Trade Fair) did report about Deutsche Messe's SAP/Oracle database upgrades to Oracle Database 11.2 and their improvements in comparison to Oracle Database 10g. Presentation was well attended and attendees I've talked to later on gave very positive feedback.

    Download the slides here as PDF (2.6MB)

    Wednesday Sep 26, 2012

    Oracle Open World starts on Sunday, Sept 30

    Oracle Open World 2012 starts on Sunday this week - and we are really looking forward to see you in one of our presentations, especially the

    Database Upgrade on Steriods
    Real Speed, Real Customers, Real Secrets
    on Monday, Oct 1, 12:15pm in Moscone South 307
    (just skip the lunch - the boxed food is not healthy at all):

    Monday, Oct 1, 12:15 PM - 1:15 PM - Moscone South - 307

    Database Upgrade on Steroids:
    Real Speed, Real Customers, Real Secrets

    Looking to improve the performance of your database upgrade and learn about other ways to reduce upgrade time? Isn’t everyone? In this session, you will learn directly from Oracle’s Upgrade Development team about what you can do to speed things up. Find out about ways to reduce upgrade downtime such as using a transient logical standby database and/or Oracle GoldenGate, and get other hints and tips. Learn about new features that improve upgrade performance and reduce downtime. Hear Georg Winkens, DB Services technical manager from Amadeus, speak about his upgrade experience, and get real-life performance measurements and advice for a successful upgrade.


    And don't forget: we already start on Sunday so if you'd like to learn about the SAP database upgrades at Deutsche Messe:

    Sunday, Sep 30, 11:15 AM - 12:00 PM - Moscone West - 2001

    Oracle Database Upgrade to 11g Release 2 with SAP Applications

    Deutsche Messe began to use Oracle6 Database at the end of the 1980s and has been using Oracle Database technology together with SAP applications successfully since 2002. At the end of 2010, it took the first steps of an upgrade to Oracle Database 11g Release 2 (11.2), and since mid-2011, all SAP production systems there run successfully with Oracle Database 11g. This presentation explains why Deutsche Messe uses Oracle Database together with SAP applications, discusses the many reasons for the upgrade to Release 11g, and focuses on the operational top aspects from a DBA perspective.


    And unfortunately the Hands-On-Lab is sold out already ... :-(
    We would like to apologize but we have absolutely ZERO influence on either the number of runs or the number of available seats. 

    Tuesday, Oct 2, 10:15 AM - 12:45 PM - Marriott Marquis - Salon 12/13

    Hands On Lab:
    Upgrading an Oracle Database Instance, Using Best Practices

    This hands-on lab gives participants the opportunity to work through a database upgrade from an older release of Oracle Database to the very latest Oracle Database release available. Participants will learn how the improved automation of the upgrade process and the generation of fix-up scripts can quickly help fix database issues prior to upgrading. The lab also uses the new parallel upgrade feature to improve performance of the upgrade, resulting in less downtime. Come get inside information about database upgrades from the Database Upgrade development team.


    See you soon :-)

    Wednesday Sep 19, 2012

    Parameter _rollback_segment_count can cause trouble

    Just some weeks ago we've learned that setting the hidden underscore parameter:


    may cause trouble during upgrade. This parameter is used in very rare cases to have under all circumstances and situations this specified number of UNDO's online. Now during upgrade this may result in massive latch contention due to bug14226559 - and there's a patch available as well. Recommendation is to unset it during upgrade.

    I don't think that many people will hit this as I personally haven't seen databases with this underscore in their init.ora or spfiles. So take this post more or less as a reminder for myself :-)


    Mike Dietrich - Oracle Mike Dietrich
    Senior Principal Technologist - Database Upgrade Development Group - Oracle Corporation

    Based near Munich/Germany and spending plenty of time in airplanes to run either upgrade workshops or work onsite with reference customers. Acting as interlink between customers and the Upgrade Development.

    Contact me either via XING or LinkedIn


    « April 2014
    Slides Download Center
    OOW Slides Download
    Visitors since 17-OCT-2011
    White Paper and Docs
    Oracle Blogs
    Viewlets and Videos
    This week on my Rega/iPod/CD
    Workshop Map
    Upgrade Reference Papers