Friday Nov 07, 2014

Sleeping Beauties - Upgrade to 11.2.0.4 can be slow

A customer from the US did contact me past week via LinkedIn and raised a question:

"Is it expected that my patch set upgrade from Oracle 11.2.0.3 to Oracle 11.2.0.4 takes over 3 hours?"

Of course, no - this is not expected

This is the upgrade stats gathered post upgrade with utlu112s.sql:

SQL> @?/rdbms/admin/utlu112s.sql ; .
Oracle Database 11.2 Post-Upgrade Status Tool 10-31-2014 10:05:29
Component Current Version Elapsed Time
Name Status Number HH:MM:SS
Oracle Server  
. VALID 11.2.0.4.0 02:46:19
JServer JAVA Virtual Machine
. VALID 11.2.0.4.0 00:08:34
[..]
Final Actions
. 00:00:00
Total Upgrade Time: 03:06:47

No, this is not really expected. So we tried to nail down the root cause finding out these statements in the upgrade script c1102000.sql are causing the trouble:

194 -- wri$_optstat_histhead_history2.
195 execute immediate
196 q'#create unique index i_wri$_optstat_hh_obj_icol_st on
197 wri$_optstat_histhead_history (obj#, intcol#, savtime, colname)
198 tablespace sysaux #';
199
200 execute immediate
201 q'#create index i_wri$_optstat_hh_st on
202 wri$_optstat_histhead_history (savtime)
203 tablespace sysaux #';
204 end;
205 /

It's index rebuilds on histogram tables. And the customer has a large amount of stats data in his database as the default stats retention is 31 days.

Obviously the index rebuild is not done very efficiently (not done in parallel, no nologging clause). Those things can happen and sometimes this may not cause any issues. But in this case it lead to over 2 hours for just those index rebuilds.  

Luckily my colleague Cindy is an excellent resource for such things - after asking our team I've got the reply that this is tagged with a bug number and code fix already got checked in (under review right now):

bug19855835:
Upgrade from 11.2.0.2 to 11.2.0.4 is slow 

-Mike

PS: Credits go to Tan for bringing this to my attention - and sorry for the inconvenience! 

Wednesday Feb 15, 2012

Why is every patchset now a full release?

This question got posted by Naveen in the previous entry today - and I found it worth it to create a new blog entry as this question gets raised in nearly every 2nd workshop as well - so others might be interested as well.

Mike,

A question has been bothering me for a while and I thought I'll throw it out there. I didn't raise a support ticket, I knew what the response is going to be.

So here is the question. I have an 11g ORACLE HOME that was built as 11.2.0.1. Now if I want to upgrade to 11.2.0.2 or 11.2.0.3, I guess there is no easy way to upgrade the existing ORACLE HOME. Why didn't Oracle give the option to just apply a patch (opatch) and upgrade to 11.2.0.2 (or .3). For a customer to create a new ORACLE HOME is just a lot of work and breaks a lot of things. We have to copy over so many configs from the old home to the new home.

I'm sure there is a good reason, I'm just trying to understand what they are.

Thanks
Naveen

Naveen, thanks for your question. And the answer has many aspects.

Install into your existing ORACLE Home

First of all you can still install the new patch set (which is now a full release since Oracle 11.2.0.2) into your existing $ORACLE_HOME. But you'll have to detach your current home from the OUI's inventory first. Please see slide 41 of the Upgrade and Migration workshop deck. Please backup the contents of $ORACLE_HOME/dbs and $ORACLE_HOME/network/admin first as you'll have to copy them back later.

$ ./runInstaller -detachHome ORACLE_HOME=/u01/orahomes/11.2.0

Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB. Actual 10047 MB Passed

The inventory pointer is located at /etc/oraInst.loc

The inventory is located at /u01/orabase

'DetachHome' was successful.

Once you've done that you'll install into your existing (old) directory.  And finally you'll copy back your dbs and network/admin files.

Why customers might use this procedure?

There are basically two reason why a customer chooses this strategy:
(a) Home naming conventions not allowing an Oracle 11.2.0.2 home and another Oracle 11.2.0.3 home
(b) Space issues
Both are valid reasons and therefore you can stay with the old strategy.

Why did we change from patchsets to full release patchsets?

Simple reason: Customers did ask us for a looooong time why we are delivering 3GB large patchsets instead of full releases. So we'd follow this wish. And second it will decrease the overall downtime when you'd install into your new Oracle Home. If you apply patchset software to your existing Oracle Home every Oracle process serviced by that home must be shut down as well - obviously including the database(s). And furthermore if something fails you'll have to restore your OUI's inventory plus all home contents - or reinstall your previous Oracle software.

Besides that we recommend to patch this home first with important one-offs (see links in MOS Note 161818.1) and the latest PSU or CPU. If you'd do that to your already emptied old home it will simply increase again your overall downtime.

And this is the reason why we recommend:
Always install into a new Oracle home beginning with Oracle Database 11.2 - don't erase your old home to reuse it unless there's no significant need for that procedure.

About

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

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

Follow me on TWITTER

Contact me via LinkedIn or XING

Search

Archives
« August 2015
SunMonTueWedThuFriSat
      
2
3
6
7
8
9
10
11
12
13
15
16
22
23
25
26
27
28
29
30
31
     
Today
Oracle related Tech Blogs
Slides Download Center
Visitors since 17-OCT-2011
White Paper and Docs
Workshops
Viewlets and Videos
Workshop Map
This week on my Rega & Pono
Upgrade Reference Papers