Monday Apr 20, 2015

Oracle PSU and BP April 2015 is available

As of April 14, 2015:

The April 2015 PSU/BP is available!

Here's the most important information:

Please find below the links to the Recommended Patches and Patch Numbers for each of your database releases:

12.1.0.2
 Availability and Known issues for 12.1.0.2      Note:1683799.1
12.1.0.1
 Availability and Known issues for 12.1.0.1      Note:1565082.1 
11.2.0.4
 Availability and Known issues for 11.2.0.4      Note:1562139.1
 
11.2.0.3
 Availability and Known issues for 11.2.0.3      Note:1348336.1

11.1.0.7
 List of fixes included in 11.1.0.7              Note:601739.1

-Mike

Thursday Jul 24, 2014

Why "We'll wait for the 2nd release!" is a misconception ...

Oh, how often have I heard this phrase:

"We'll wait for the second release!"

And sometimes it makes me really anxious and angry at the same time when I hear that.

Anxious because it means that somebody has no strategy for the database upgrades/migrations and is just postponing necessary tasks to sometime in the future. Easy deal but not very clever

Angry because this is a way of thinking from the 90s/00s when Oracle had this "10.1", then later "10.2" strategy in database releases. But we are in 2014 now. And things have changed. Changed a lot in fact.

I'm probably not the only person who would love to see if we'd remove this "first" and "second" release tags. This has become obsolete with Oracle 11.1. We were telling customers officially that this is the brand new fantastic Oracle Database 11g release. But in fact it was - from the coding perspective - more or less a very stable 10g. In my workshops I did call it Oracle 10.3 with a marketing sticker on it. And as far as I can see the customer's I've had helped with going live on Oracle Database 11.1.0.7 were quite happy. Some really large shops still work with this release today with hundreds of databases in production.

But honestly most of the changes got introduced with Oracle Database 11.2. And not for a small number of customers this meant waiting for the first patch set (which since then has become a full release). Plenty of people went live with Oracle Database 11.2.0.2. But a lot of the remarkable changes got introduced not in Oracle 11.1 but in Oracle 11.2. Just remember things such as the move from Clusterware to Grid Infrastructure. But also minor things such as DEFERRED_SEGMENT_CREATION and plenty of optimizer news.

Now with Oracle Database 12c and the first patch set (full release) 12.1.0.2 I have heard this again - and I see it on the mailing list as well once a week:

"When will Oracle 12.2 be available?"

Well, that's the misconception. It's true, Oracle Database 12.1.0.2 has new features and extensions. But it has also many fixes over the already very stable Oracle 12.1.0.1. Why should anybody wait for Oracle 12.2 now? Because it's supposed to be THE SECOND release? Forget this - this is thinking from the old days.
We are in year 2014 now.

And then spend a minute to look closer to the Support Policy.

  • Oracle Database 11.2 will go out of Premier Support in 6 months. Yes!!! 6 months
  • And correct, we'll give everybody on Oracle 11.2.0.4 one full year of Extended Support for free
  • For Oracle 11.2.0.3 Extended Support will end 28-AUG-2015

That means if you plan to stay on Oracle 11.2.0.3/4 for a longer period you'll either have to calculate 20% extra of your support fee for the 2nd year of Extended Support. Or you prefer to "hope".

I can't tell you when Oracle 12.2 will be available - and I don't care. Usually people wait for the first patch set anyways which gets releases based on experience from the past 3 databases releases roughly a year and a bit after the initial release. Just do the math and you'll see where you end up with this strategy.

My recommendations are:

  • Stop thinking about THE SECOND release
  • Evaluate Oracle Database 12.1.0.2 now - not tomorrow
  • Look at the Support Policy - you need to start your upgrades as soon as possible
-Mike 

 

 

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 catctl.pl, the parallel upgrade Perl driving script in Oracle Database 12c, you may also want to get timings written in your logfile during execution. As catctl.pl 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 =============================================
@@catpses.sql

Rem =============================================
Rem  Set Timing On during the Upgrade
Rem =============================================
SET TIMING ON;

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


-Mike

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


Monday Jul 16, 2012

How to select statements from AWR?

Simple question - and more a reminder to myself as I'd assume that many people have their examples somewhere already. But in upgrade and migration projects it's sometime useful to simply select SQL statements directly from between two AWR snapshots into a SQL Tuning Set (STS). This will give you the possibility to later put a failing plan directly into a SQL Plan Baseline, part of the free Enterprise Edition's SQL Plan Management feature.

You'll need to create a SQL Tuning Set and simply fill it with staments from an AWR snapshot interval:


exec DBMS_SQLTUNE.CREATE_SQLSET('MD_STS','SYS')
/

DECLARE
  cur sys_refcursor;

BEGIN

open cur for

   select value(p)
from table(dbms_sqltune.select_workload_repository(
      begin_snap => 4711,
      end_snap => 4788,

      basic_filter => 'parsing_schema_name not in
                 (''DBSNMP'',''SYS'',''ORACLE_OCM'')',

      ranking_measure1 => 'elapsed_time',

      result_limit => 250)) p;

    dbms_sqltune.load_sqlset('MD_STS', cur);

  close cur;

END;

/

And fixing a failing plan and overwriting it with the plan from before the upgrade would work that way:

DECLARE
 my_plans PLS_INTEGER;
BEGIN
 my_plans := DBMS_SPM.LOAD_PLANS_FROM_SQLSET(
   sqlset_name => 'MD_STS',
   basic_filter => 'sql_id="b25h7qc53gowp"',
   fixed => 'YES');
END;
/

- Mike

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
« July 2015
SunMonTueWedThuFriSat
   1
2
3
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
30
31
 
       
Today
Oracle related Tech Blogs
Slides Download Center
Visitors since 17-OCT-2011
White Paper and Docs
Workshops
Viewlets and Videos
This week on my Rega/iPod/CD
Workshop Map
Upgrade Reference Papers