Welcome to the Oracle Database Upgrade blog!!!

Glad that you'd find your way to my Oracle Database Upgrade Blog :-)

"Uhhh ... yet another blog ..." you might think. But the intention is to give you the most recent database upgrade tech news and findings. Discuss with you about best practices. And offer you access to upgrade workshops we are running right around the world - at no extra cost.

So I hope to see you more often - and maybe we'll meet one day in one of our workshops in person.

Enjoy - thanks and kind regards
Mike

Comments:

Hi Mike, Attended one of your 11g Upgrade workshops and found it to be highly informative, and would encourage anyone to get along to one of these. Testing 11gR1 now. having to use 2 underscore parameters due to regressions introduced - both marked as 11gR2. Could be better. jason.

Posted by jason arneil on July 29, 2009 at 07:15 AM CEST #

Hallo Herr Dietrich,
Anfrage: beim Upgrade von 11.2.0.1 auf 11.2.0.3
wurden alle Werte von Oracle Connection Pooling
auf Default-Werte zurückgesetzt.
Die Konfiguration musste neu aufgebaut werden.
Ein automatiches Start der Prozesse
wurde auch nicht durchgeführt.
Ist das irgendwo beschrieben ?
Gruß
Peter

Posted by Peter on May 16, 2013 at 01:27 PM CEST #

Hallo Herr Peter,

ich habe diverse Dokumente in MOS gefunden, die ueber das Thema "Connection Pool" beim Upgrade schreiben. Ohne genauere Kenntnis der Thematik kann ich Ihnen aber keine Auskunft geben. Haben Sie eine SR Nummer, die Sie mir zumailen koennen?

Danke und VG
Mike Dietrich

Posted by Mike Dietrich on May 21, 2013 at 11:37 AM CEST #

Thank you

Posted by LAMOTTE on June 27, 2013 at 10:16 AM CEST #

Hi Mike,

Thanks a lot for the interesting workshop today in Brussels; it gave us a brief and clear view in some topics regarding upgrade, migrating strategies....

FCN or Bayern? I hope you wear the correct shirt tonight.

Posted by guest on April 29, 2014 at 07:59 PM CEST #

I wore my regular shirt - but as you may have seen from the current league standings it may have been the wrong decisions ... :-(

But good luck for Belgium for the World Cup - the team is good enough to surprise everybody and make it under the top-4 teams :-)

Thanks for your feedback!!!

Mike

Posted by Mike on May 06, 2014 at 01:12 PM CEST #

Hell'o Mike,
Thanks again for the upgrade day in Brussel the 29th of April. From that time I heard that Bayern lost 4-0... Ouch!
I have a question about a work project. We have bought 2 exadata (1/4 and 1/8) X4 generation. All our servers are windows based with microsoft cluster and we'll have to migrate and upgrade (we have a panel of 9, 10, 11 DB version) most database into exadata. The contact we have here in Belgium for Oracle said that he'll ask Johan Vandenbosch to come see us. He mention that project might interest you and that he'll ask you aswell. Did you heard about anything? (More informations by email if you need some.)
Greetings and keep the very good work.

Posted by guest on May 09, 2014 at 08:27 AM CEST #

Hi,
Thanks a lot for the interesting workshop yesterday in Warsaw in Poland; it gave us a brief and clear view in some topics regarding upgrade and migration. This was the first workshop organized by Oracle have been to.

Posted by Lukasz on July 16, 2014 at 12:32 PM CEST #

Lukasz,

thanks a lot - I did enjoy the day as well :-)

Cheers, Mike

Posted by Mike on July 16, 2014 at 04:02 PM CEST #

We have a two node rac version 10.2.0.4 running on red hat linux x86_64. We want to upgrade the OS to RHEL 5 and the database to 11.2.

We want to do a rac rolling upgrade. We are told by Oracle support that we should complete the upgrade on both nodes within 24 hours or it is likely we will encounter criticat problem. Our system engineers are telling us that it takes 2 to 3 days to upgrade each node from rhel 4 to rhel 5 eventhoug we know this could be done in 2 to 3 hours.

Any suggestions ?

My name is Harvey Jefferson i work for acxiom corporation and i attended one your upgrade workshops a few years ago.

Thanks for any help

Posted by guest on September 10, 2014 at 09:45 PM CEST #

Harvey,

this is more a question for support than for myself ;-)

Actually I don't believe that you can do a rolling upgrade from 10.2 RAC to 11.2. As far as I know 11.1 would be the min requirement to do such a thing (and you'd still need additional patches). You may check our (not-updated-anymore) slide deck about 11.2 upgrades in the Slides Download Center for the MOS Notes about Rolling RAC Upgrades to 11.2.

One of the reasons this won't work is the desupport of OCR/Voting on RAW in 11.2.

My question nr. 1 would be: Are you staying on the same hardware or will you get a new cluster for the move? If the latter is true than my proposal would be:
- configure your new RAC with the latest patches/PSUs
- install 11.2.0.4 database software (again, get PSUs)
- build up a physcial standby (you won't need 10.2 sw)
- stop production when in synch
- activate the standby and upgrade it
Overall downtime will be (depending on installed options)
between 20 and 60 minutes usually. And you can test this
approach several times.
.
If you don't get new hardware ... hm ... then it will get tough. Minumal downtime usually requires a bit more effort ;-) Do you have a spare system which can take the load for a weekend or so? Then I'd build up a standby on the spare, switchover, reconstruct your current RAC with new Linux, new GI, PSUs, database 11.2.0.4 with PSUs, setup a phyiscal standby from SPARE prod back to the old/new cluster, activate and upgrade it. Downside here: you can't really test as you'll wipe out your current prod.

Hope this helps, cheers
Mike

Posted by Mike on September 11, 2014 at 10:33 AM CEST #

Thanks for replying.

We are going to stay on the same servers/hardware. No spare servers that we could use.

Here is our latest steps we are researching.

I am not including all detailed rac steps but this is a basic outline.

1. Shutdown oracle and rac on NODE1
2. Upgrade os on NODE1 --- since two different versions of os is not running then the 24 hour guideline does not apply.
3. Reinstall/relink oracle 10.2 on NODE1
4. Bring up rac on NODE1
At this time you need to meet Oracle’s 24 hour guideline since two different version of os is running until step 5 is done which should only take a few minutes
5. Shutdown oracle and rac on NODE2
Once step 5 is done then you are no longer running 2 different os versions so the 24 hour guideline does not apply.
6. Upgrade os on NODE2 --- 24 hour guideline does not apply
7. Reinstall/relink oracle 10.2 on NODE2
8. Bring up rac on NODE2
9. Upgrade oracle rac from 10.2 to 11.2

Posted by guest on September 11, 2014 at 05:06 PM CEST #

Ok, to upgrade the OS on both nodes only your solution sounds fine to me. But you may please double check with Oracle Support.

Posted by Mike on September 12, 2014 at 11:01 AM CEST #

Hi Mike,

We currently have 11R2 GI Stand Alone running and want to upgrade to 12R1 GI Stand Alone.
Is it possible to do a 'software only' installation of 12R1 GI Stand Alone, patch that software set to the latest PSU and, in a separate step (when having downtime), do the actual upgrade ot 11R2 GI to 12R1 GI.

Regards, Jaco

Posted by Jaco de Graaf on November 19, 2014 at 11:02 AM CET #

Hallo!

Kann ich mit GoldenGate auch den initialen Load der Daten von der Source- zur Target-DB machen oder ist GG nur für den Transport der Redo-Daten (oder wie auch immer das bei non-Oracle DB's heisst) zuständig?

Danke und Gruss

Posted by Christian on February 06, 2015 at 02:43 PM CET #

Hallo,

OGG kann theoretisch kleine Datenbanken selbst umziehen, das wuerde ich aber ab einer Groesse von 20GB vermeiden. Generell gesprochen ist OGG die Synchronisations-Lösung, um einen Umzug mit nahe-Null oder sogar zero downtime zu ermöglichen. Die Datenbank muss aber zuvor mit den verfübaren Technologien wie Transportable Tablespace oder Data Pump migriert oder upgegraded werden.

Mike

Posted by Mike on February 06, 2015 at 02:46 PM CET #

Danke für die Bestätigung!
Die Doku ist hier etwas interpretierbar.

Gruss
Christian

Posted by guest on February 06, 2015 at 04:22 PM CET #

after activate the standby and upgrade it
you will need to

• Attache databases to new CRS cluster

kal

Posted by guest on March 13, 2015 at 01:54 PM CET #

Hi Mike ,
We have to upgrade(in-place) from 11.2.0.3 to 12.1.0.2 (non-CDB mode).
do you recommend to leave parameter
COMPATIBLE=11.2.0.3 to prevent downgrade ?
What is the best practice ?
Best regards.
Kais

Posted by kais on June 18, 2015 at 09:09 PM CEST #

Kais,

yes, our recommendation would be:
(1) Leave COMPATIBLE=11.2.0.3 for 7-10 days after the upgrade. This will allow you to downgrade in case of significant issues you haven't see during testing.
(2) Then change COMPATIBLE 7-10 days after upgrade. But keep in mind that this will cause you downtime as you'll have to restart the database. If you won't get this additional downtime it's a tough decision: the ability to downgrade vs the new features.

Hope this helps - cheers
Mike

Posted by Mike on June 19, 2015 at 10:10 AM CEST #

Hi Mike ,
Thanks a lot for your valuable response !
What about issue during upgrade operation
It is possible to downgrade in this case ?
Best regards.
Kais

Posted by kais on June 19, 2015 at 11:18 PM CEST #

Kais,

yes, you can downgrade back down to 11.2.0.3 as long as you leave COMPATIBLE unchanged. For issues and such please see the posts on the blog and the big slide deck "Upgrade, Migrate and Consolidate to 12c" in the Slides Download Center to your right on this page.

Cheers
Mike

Posted by Mike on June 22, 2015 at 09:53 AM CEST #

Hi,

I would like to upgrade multiple 11.2.0.3 (around 50) databases to 11.2.0.4. The databases are hosted in Linux Environment 3 node RAC Setup. I would like to know fastest way of doing the upgrade with as much as minimum downtime as possible. Please note Grid Infrastructure had been upgraded already and Oracle 11.2.0.4 binaries had been installed in separate Oracle Home.
Is there a way to do an Online upgrade ? Our company Maintenance window is around 2 hours only. I went thru the standard Oracle documentation on this which requires downtime.
I have a script which I am testing which has standard oracle scripts as per Readme file. This takes roughly 1 hour per database.

Please note the above is just one example. We have other environments (like test, prod etc) which has little less databases. The underlying architecture is ASM. Is there a way to do something at ASM level which will inturn upgrade the databases ?

Please let us know the other faster options if available.

Thanks
Suresh

Posted by SURESH RAMASWAMY on August 19, 2015 at 09:17 PM CEST #

Suresh,

thanks for your comment - but actually this goes far beyond what I can deliver via the blog.

And let me point out one thing:
Oracle 11.2.0.4 will got out of FREE EXTENDED SUPPORT (meaning no CPUs/SPUs/PSUs/BPs after that without PAID EXTENDED SUPPORT) in 5 months. I don't see any good reason to upgrade to 11.2.0.4 these days as I'd silently assume that this will involve testing for 50 (!!!) databases. The resources (aka MONEY) spent on this effort is simply wasted as the amount of work would be exactly the same for a 12.1.0.2 upgrade.

I see your point of having GI already on 11.2.0.4 - but still my advice would be to move GI to 12.1.0.2 NOW - and afterwards the databases as soon as possible to 12.1.0.2 as well.

Not sure about your question with ASM - ASM runs out of the GI home and is independent of the database homes.

And unfortunately I can't tell you a precise answer as I know far to little about your environments.

Basically the upgrade can be fairly fast - 1 hour per database is fine.

But I'd emphasize on TESTING - the upgrade itself is just the most simple part - 90% of your efforts should be on testing your applications as 11.2.0.4 brings in a ton of optimizer changes over 11.2.0.3 (and this is another reason why I highly would encourage you to move to 12.1.0.2 instead - your testing amount will be the same).

Cheers :-)
Mike

Posted by Mike on August 20, 2015 at 10:06 AM CEST #

Suresh

I do not believe you have the luxury to automate database upgrade with an automated scripts, as every database upgrade is different and it requires some level of sanity checks before you proceed to next step. However, Some part can be automated to speed up. You could also run upgrade on multiple databases at the same time, however, it depends on the server capacity.

Alternatively you could use Multi-tenant option (req license), to help your cause. This can be very useful and viable feature based on the available downtime you have for 2 hours (50 database). With Multi-tenant you could be able to upgrade db in a short period of time, however, this is a 12c feature and depends on your database size too.
Hope this helps.

Thx
-Bhavesh

Posted by guest on August 30, 2015 at 01:49 PM CEST #

Hi Mike,
Usually I save (csv file) all parameters before upgrade because parameter value can be changed by DBA within or after upgrade.
What do you think about this practice ?
Do you think is enough to compare changes before and after upgrade procedure ?
Kais

Posted by Kais on September 29, 2015 at 12:21 AM CEST #

Kais,

sure, you can do that (saving and comparing).

Thanks
Mike

Posted by Mike on September 29, 2015 at 01:11 PM CEST #

Hi Mike,
we are currently in the process of testing an upgrade (11.2.0.4 to 12.1.0.2) in combination with a platform change (Linux to AIX) of a DWH (approx. 2TB). We are using transportable tablespaces and have excluded statistics. What is your recommendation for gathering statistics on the new system? We are thinking about schema- (of course), system-, fixed-objects- and data dictionary stats. At present we are facing huge performance problems on the new system even we have more memory, cpu etc.

Best regards
Axel D.

Posted by guest on November 20, 2015 at 10:01 AM CET #

Hi Axel,

thanks for your message.

I'll drop you an email.

Cheers
Mike

Posted by Mike on November 20, 2015 at 10:50 AM CET #

I am upgrading from 11.2.0.3 to 12.1.0.2. During the DBUA setup screens, I checked "Set User Tablespaces to Read Only During the Upgrade". It just seemed like the right thing to do. All of my tablespaces were ONLINE. All tablespace files were autoextendable. During the upgrade I got this error.
Context component upgrade error
ORA-01647 tablespace xxxxx is read-only. Cannot allocate space in it. There was plenty of space. I re-ran without the box checked and it ran ok. Just curious if anyone else has seen this.

Posted by guest on January 28, 2016 at 09:19 PM CET #

This is expected as soon as a repository is in another tablespace which is not treated as an Oracle supplied repository tablespace.

Which objects belonging to TEXT reside in this tablespace?

Cheers
Mike

Posted by Mike on January 28, 2016 at 11:54 PM CET #

Hi Mike,

Today i have a Question/Doubts regarding cross-platform db migration - specifically from AIX 11.2.0.3 to Oracle Linux 12.1

I aware of the new rman features introduced in 12c for cross-platform data transport.

For example, "Cross-platform Transportable Tablespaces using Read-Only Tablespaces"
as explained in MOS Note:
"How to restore a pre-12c backup to a cross-platform, cross-endian 12c database (Doc ID 1644693.1)"

In the example above they put the tablespaces in read-only mode.

Question-1:
------------
Is it possible to use the same technique, but using incremental backup sets to reduce downtime to migrate from 11.2 to 12.1 ?

The new rman syntax in 12c using "Backup for Transport allow inconsistent" and "restore from platform .."
seem to be valid only when source and destination's compatible parameter is set to 12.1

But i have successfully performed a normal rman backup from a 11.2.0.3 Database on AIX , without using the clause "for transport" or "allow inconsistent"
and i could successfully restore it on 12.1 DB on Linux using the rman "from platform" Clause.

I am not sure if this is officially supported - but it seems the platform-conversion was done even without using "backup for Transport".

Question-2:
-----------
Could please confirm if this is supported?

From the Document: http://docs.oracle.com/database/121/BRADV/rcmxplat.htm#BRADV726

It is indicated that before performing 'cross platform transportable tablespaces using inconsistent backup sets',
the COMPATIBLE parameter must be set to 12.0 or later on both source and target DB.

This does not seem to be true because i have seen examples where a cross-platform tts backup was made on 11.2.0.3 and restored to 12.1.
At least it should not be set to 12.0 on source DB - it can be set on target DB.

Question-3:
-----------
Can you please confirm if this is true or if it is a documentation bug?

I know it's not possible to use the rman clause "for transport" from a 11.2 Database, but it seems the clause "from platform .." on a 12c destination db would still be able to read those inconsistent rman backups and convert them automatically.

Best Regards,

Pascal

Posted by Pascal Phillip on February 08, 2016 at 05:52 PM CET #

Pascal,

thanks for your comment - and for all your questions.

As I don't work in the RMAN Development or Support I think you'll have to open an SR to get your questions answered in a way that you can rely on it.

I know that there are several open topics regarding COMPATIBLE and SOURCE versions which require clarification. The notes say "12.1 to 12.1" only - and I know from other customers that some things work even when your source is 11.2.0.4. But I'm not the instance to add or correct this. There may be a reason for this restriction - but I don't know it.

Now regarding your questions:

(1) Is it possible to use the same technique, but using incremental backup sets to
reduce downtime to migrate from 11.2 to 12.1 ?

Yes, this is possible. Please see: MOS Note:1389592.1
They offer you a PERL script which allows you to do this with RMAN Inc Backups.
Please see our presentation about "Full Transport with RMAN Inc" on the right side of this page:
http://apex.oracle.com/pls/apex/f?p=202202:2:::::P2_SUCHWORT:FullTransport

(2) Could please confirm if this is supported?

Sorry, but you'll have to open an SR to get a confirmation.
To me it looks as if this restriction (12.1 compatible on both sides) is a requirement regarding the specific command using 'cross platform transportable tablespaces using inconsistent backup sets'. As stated above you can do cross platform TTS, first of all regardless of version since Oracle 10.2 - and when using RMAN Inc backups since 11.2.0.4 as the target with (as far as I remember correctly) 10.2.0.3 as the minumum source. If you want to add some sort of automation you can rely on the PERL scripts. And if you want to avoid the crucial TTS part and your source is at least 11.2.0.3 you can add the Full Transportable Feature I described in the above mentioned presentation.

(3) Can you please confirm if this is true or if it is a documentation bug?

Please clarify with Oracle Support ;-)
I hate to say/write this but such questions need to be clarified by Support - and if it's a doc bug they'll file it for you and get you the bug id.

Thanks!
Mike

Posted by Mike on February 09, 2016 at 04:44 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Mike Dietrich - Oracle Mike Dietrich
Master Product Manager - Database Upgrade & Migrations - Oracle

Based in Germany. Interlink between customers/partners and the Upgrade Development. Running workshops between Arctic and Antartica. Assisting customers in their reference projects onsite and remotely. Connect via:

- -

Search

Archives
« February 2016
SunMonTueWedThuFriSat
 
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
     
       
Today
Slides Download Center
Visitors since 17-OCT-2011
White Paper and Docs
Workshops
Viewlets and Videos
Workshop Map
x Oracle related Tech Blogs
This week on my Rega & Pono
Upgrade Reference Papers