Wednesday May 04, 2016

Are BPs. PSUs and Proactive BPs cumulative?

Are Bundle Patches (BPs) and Patch Set Updates (PSUs) cumulative?

That is a question sounding trivial to many people but actually it does get asked quite often. And sometimes I forget to mention this during the workshops - and luckily usually somebody asks the question reminding me to explain it.

Yes, Bundle Patches and Patch Set Updates (and of course Proactive Bundle Patches and Critical/Security Patch Updates (CPUs/SPUs) are all cumulative.

You'll find this mentioned in the first paragraph of MOS Note: 854428.1 - Patch Set Updates for Oracle Products:


...

Interesting note on the side:
I would have expected this important piece of information in MOS Note:1962125.1 - Oracle Database - Overview of Database Patch Delivery Methods but I couldn't find it. So it's no wonder why people ask such a trivial question ... [irony!]  
.

Two simple examples:

  • You have the October 2015 PSU applied
  • You'd like to apply the April 2016 PSU on top
    • Then you don't need the January 2016 PSU as it is included in the April 2016 PSU already
      .
  • You never applied a Procative Bundle Patch
  • You'd like to apply the April 2016 Proactive Bundle because a guy recommended it on an Oracle blog - and actually MOS notes mention it as well as highly recommended
    • You don't need to apply anything beforehand.
      The April 2016 Proactive BP has all the fixes from all previous BPs included on top of Oracle Database 12.1.0.2.0
      .

Further Information?

You'll find recent related postings on this blog here: 

 --Mike
.

Tuesday May 03, 2016

Can I apply a BP on top of a PSU? Or vice versa?

This question was in my inbox this morning raised by a customer via a colleague. 

Our feeling said:
Yes, but you'll have to deinstall the PSU first before applying the BP.

Having a feeling is one thing, knowing the truth is better. And as I have so much fun by applying PSUs and BPs back and forth since two weeks I thought "let's give it a try". So here we go ...
.

Apply a BP on top of a PSU

This is my starting point - Oracle Database 12.1.0.2 with PSU October 2015, the last state in my VBox environment since I experiment with parameters and packages at the moment.

And this is the result when trying to apply the BP from April 2016 on top: 

[CDB2] oracle@localhost:/media/sf_CTEMP/22899531/22899531/22806133
$ opatch apply
Oracle Interim Patch Installer version 12.1.0.1.10
Copyright (c) 2016, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/12.1.0.2
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0.2/oraInst.loc
OPatch version    : 12.1.0.1.10
OUI version       : 12.1.0.2.0
Log file location : /u01/app/oracle/product/12.1.0.2/cfgtoollogs/opatch/opatch2016-05-03_10-26-37AM_1.log

Verifying environment and performing prerequisite checks...

Conflicts/Supersets for each patch are:

Sub-Patch : 20243804

        Bug Conflict with Sub-Patch 21359755
        Conflicting bugs are:
        18966843, 19468991, 19032777, 19587324

[..]


Following patches have conflicts: [   21359755   22806133 ]
Refer to My Oracle Support Note 1299688.1 for instructions on resolving patch conflicts.

UtilSession failed: Patch 21359755 is a composite patch which could not be rollback.

Log file location: /u01/app/oracle/product/12.1.0.2/cfgtoollogs/opatch/opatch2016-05-03_10-26-37AM_1.log

OPatch failed with error code 73


Ok, our suspicion was correct.

There are a lot of conflicts - I have to remove the PSU first. And of course the recommended conflict check would have given me the same result. Furthermore I think I have read this a while back in one of the central notes about PSUs and BPs in MOS as well.
.

Removing the PSU from October 2015 first

Removing a PSU or BP is very simple and straight forward (and well described in the ReadMe.html coming coming with the patch).

[CDB2] oracle@localhost:/media/sf_CTEMP/21359755/21359755
$ opatch rollback -id 21359755
Oracle Interim Patch Installer version 12.1.0.1.10
Copyright (c) 2016, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/12.1.0.2
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0.2/oraInst.loc
OPatch version    : 12.1.0.1.10
OUI version       : 12.1.0.2.0

Log file location : /u01/app/oracle/product/12.1.0.2/cfgtoollogs/opatch/21359755_May_03_2016_10_41_54/rollback2016-05-03_10-41-54AM_1.log

Patches will be rolled back in the following order:
   21359755   20831110   20299023   19769480
The following patch(es) will be rolled back: 21359755  20831110  20299023  19769480
Sub-patches of a composite series are being rolled back. The system will be returned to a state where all subpatches are rolled back.

[..]

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/oracle/product/12.1.0.2')

Is the local system ready for patching? [y|n]
y

User Responded with: Y
Rolling back patch 21359755...

[..]

RollbackSession removing interim patch '19769480' from inventory Log file location: /u01/app/oracle/product/12.1.0.2/cfgtoollogs/opatch/21359755_May_03_2016_10_41_54/rollback2016-05-03_10-41-54AM_1.log OPatch succeeded.

Apply the BP from April 2016

I don't want to repeat myself as I wrote already about this positive experience a few days ago:

Oracle Database BP April 2016 applied successfully (Apr 21, 2016)
https://blogs.oracle.com/UPGRADE/entry/oracle_database_bp_april16_applied

Further Information?

You'll find recent related postings on this blog here:

--Mike

Friday Apr 29, 2016

Upgrade to Oracle Database 12c: We don't insist :-)

It's so funny - for years I discuss with customers minimal downtime upgrade strategies back and forth, up and down. I saw DBAs really hunting to save a few seconds potential downtime - and I always take this serious as there is usually a real reason behind that. Just to learn a few days later by repeating experience that my work Windows7 laptop goes down to apply upgrades ... and this takes looooooooong .... sometimes it takes a lengthy +30 minutes of quiet time. Whereas my OL6 VBox image applies upgrades in the background and needs a simple restart to be back in less than a minute or so.
Different strategies of course. 

For those who think I'm writing nonsense about the upgrade of my Win7 on my Lenovo x230 with 16GB of RAM, an i5-320M cpu and a 5400rpm WD spinning disk here's a screenshot taken from one of those upgrades where I sat already 15 minutes waiting ... waiting ... waiting ...

As Win7 had to configure the upgrades afterwards, once it was done with restarting I had to wait another 10 minutes for completion. And no, my laptop is not broken (not that I know) - it's 3 years old and heavily used of course. But all running fine usually ... :-) 

Anyhow ... 

Of course I discussed with a ton of people why you should upgrade now to Oracle Database 12.1.0.2 now! - and stay away from that "we go live on the 2nd release only" thinking as there's no such thing as THE 2nd release anymore.

But whatever my position on upgrades is, I can ensure that we don't discuss methods like this internally to force you to upgrade ...

MS Win10 Forced Upgrade Message

... not yet *haha* !!!
.

--Mike

PS: The picture is not a fake - you can watch the 41 seconds youtube video here :-) 
.

Thursday Apr 28, 2016

Incremental Statistics Collection in Oracle 12.1.0.2 - A True Story

Recently I came across a really interesting customer case in the UK dealing with Incremental Statistics Collection issues in regards to an upgrade to Oracle Database 12.1.0.2.

This is the follow-up blog post to: 

A while back I blogged already about Incremental Statistics collection in Oracle Database 12.1.0.2: 

And you'll find more information in our documentation and in posts by our optimizer folks:  

The Basics

The idea of Incremental Statistics Collection is simply to save time and resources when gathering statistics for partitioned tables in order to update the global stats. In Oracle Database 12c we added the very important features of: 

  • Incremental stats working now with partition exchange as well
  • "Changed" partitions won't be eligible for new stats generation until a certain stale percentage (default: 10%) has been reached - this has to be enabled and can be tweaked
    • SQL> exec DBMS_STATS.SET_DATABASE_PREFS('INCREMENTAL_STALENESS','USE_STALE_PERCENT');
    • SQL> exec DBMS_STATS.SET_DATABASE_PREFS('STALE_PERCENT','12');

Furthermore we always recommend to:  

  • Not enable incremental stats collection globally but only for specific tables. Otherwise the footprint for the synopsis on disk can grow fairly large. Biggest footprint I've seen so far was almost 1TB in size in the SYSAUX tablespace
  • Enable it mostly for range-partitioned tables where only a few partitions undergo DML changes 
    .

The Case

Actually the synopsis table in this particular case did contain "only" 300GB of data. But as the starting point was already Oracle Database 11.2.0.3 just a change from Range-Hash to List-Hash Partitioning would happen. As this happens via metadata swapping the impact should be small.

But the issue coming up after the upgrade didn't have to do with this change in partitioning layout.

Issue No.1

During the maintenance window the incremental stats job did not finish and actually this statement caused plenty of trouble:

delete from sys.wri$_optstat_synopsis$ where bo# = :tobjn and group# in (select * from table(:groups)

Not completing this statement within the 4 hours of the default maintenance window led to a rollback of the delete - and its rollback alone took 14 hours. It turned out that the delete has to happen (and complete) before the regathering of stats could start. 

I did recommend:
patch 21498770: AUTOMATIC INCREMENTAL STATISTICS JOB TAKING MORE TIME ON 12.1.0.2  (see also MOS Note:2041541.1 - Gather_Database_Stats_Job_Proc Taking More Time in 12.1.0.2 Than 11.2.0.4)

and the customer requested:
Patch 22893653: MERGE REQUEST ON TOP OF DATABASE PSU 12.1.0.2.160119 FOR BUGS 19450139 20807398
on top of their January 2016 PSU - the merge included the patch I mentioned.

Besides that another issue got discovered.

Issue No.2

The daily purge of statistics didn't really work on large synopsis as the default degree of parallelism introduced with Oracle 12c gets derived from the number of blocks on the synopsis table - bigger table means a higher parallel degree for the purge. It ended up with a PARALLEL hint of 60 - and that was counterproductive. Once a purge got started manually in serial mode or with a low DOP it completed in less than 1 minute.

With a similar trace as:

set serveroutput on;
EXEC dbms_output.enable(999999999);
EXEC dbms_stats.set_global_prefs('trace',1+4);
EXEC dbms_stats.gather_table_stats(ownname=>'&TABLE_OWNER',tabname=>'&TABLE_NAME');
EXEC dbms_stats.set_global_prefs('trace',0);

the issues could be identified as: 

Bug 21258096 - UNNECESSARY INCREMENTAL PARTITION GATHERS/HISTOGRAM REGATHERS

The customer requested another merge patch 22926433 which contains the following fixes:

19450139: KN:LNX:PERFORMANCE ISSUE WHEN RUNNING GATHER TABLE STATS WITH INCREMENTAL STATS
20807398: ORA-00600 [KGL-HASH-COLLISION] WITH FIX TO BUG 20465582
21258096: UNNECESSARY INCREMENTAL PARTITION GATHERS/HISTOGRAM REGATHERS
21498770: AUTOMATIC INCREMENTAL STATISTICS JOB TAKING MORE TIME ON 12.1.0.2

Finally the customer agreed with Support's recommendation to truncate the two synopsis tables, WRI$_OPTSTAT_SYNOPSIS_HEAD$ andWRI$_OPTSTAT_SYNOPSIS$, and regathered incremental statistics the following weekend. Of course they validated this action plan on their performance testing environment first - with the merge patch applied - and it had the desired effect and solved the issue.

Incremental statistic gathering works now as expected, the job fits into the maintenance window.

Lessons Learned

Actually Oracle Support released a very helpful and important note just a few weeks ago (too late for this customer): 

It contains not only links to the patches for the issues the customer hit here - but also a long list for Oracle 11.2.0.4 as well. 

Another MOS Note is worth to mention here: 

But these were not all issues the customer faced - so I may write up another blog post in addition within the next days.

--Mike

PS. All credits go to David Butler and Rob Dawley - thanks for your hard work, sorry for all the inconvenience - and especially thanks for writing it all together and forwarding it to me!!!

Wednesday Apr 27, 2016

Incremental Statistics Collection in Oracle 12.1.0.2 - Upgrade Pitfalls

A while back I blogged already about Incremental Statistics collection in Oracle Database 12.1.0.2: 

And you'll find more information in our documentation and in posts by our optimizer folks:  

And  you may read on this follow-up blog post about a related real world customer example ...   .

Database Upgrade

Important to know is the fact that during a database upgrade the underlying tables containing the synopsis for incremental stats collection may be reorganized. And depending on the amount of data this can take a bit.

The largest synopsis tables I have seen so far were almost 1TB of size at a financial customer in Europe. But I have seen ranges around 300GB quite often in the past months.
.

What happens during the database upgrade? 

Incremental Statistics Collection got introduced with Oracle Database 11.1.0.6 and improved from release to release. But during a database upgrade a reorganization of the synopsis table can happen.

  • Upgrade from Oracle 11.1.0.6/7 or 11.2.0.1 to Oracle 11.2.0.2/3/4:
    • Restructuring of WRI$_OPSTAT_SYNOPSIS$ to use range-hash partitioning 
    • Most data movement will happen here
    • As for the interim period two synopsis tables exist this will consume 2x the space of the synopsis table during the movement
      .

  • Upgrade from Oracle 11.2.0.2/3/4 to Oracle 12.1.0.x:
    • Restructuring of WRI$_OPSTAT_SYNOPSIS$ from range-hash partitioning to list-hash partitioning
    • There is little data movement in this case as the move happens with the help of metadata swapping
      .

Which symptoms may you see?

Actually very simple and obvious symptoms:
Phase 1 of the parallel upgrade to Oracle Database 12c takes unusually long. It should usually complete within the range of less than a few minutes. But in those cases it can take literally hours.

If that happens check your catupgrd0.log and watch out for the long running statements. It does not mean necessarily that it happens because of a huge synopsis table. For instance one of my German reference customers, DVAG had leftovers in the SYSAUX because of bugs in earlier releases they had worked with. 

But if you spot such results (quoting a colleague here):

"The table WRI$_OPTSTAT_SYNOPSIS$ has 20420 partitions, 344618 subpartitions and 921207 MB size. [..] This transformation step lasts for 6,5 hours, so the whole upgrade process duration has an important impact from this step." 

then you should be alerted. 
.

How can you check this upfront? 

We haven't included a check into the preupgrd.sql yet. But the following three queries will tell you if you may see issues when you get a larger number as result: 

  • How many tables have incremental stats on?
    SQL> select count(distinct bo#) from sys.wri$_optstat_synopsis_head$;
    .
  • How many partitions does your WRI$_OPSTATS_SYNOPSIS$ have?
    SQL> select partition_count from dba_part_tables where table_name='WRI$_OPTSTAT_SYNOPSIS$';
    .
  • How large is your synopsis table?
    SQL> select sum(bytes/(1024*1024)) "MB" from dba_segments where segment_name='WRI$_OPTSTAT_SYNOPSIS$';
    ,
  • Tables where inc stats are ON?
    SQL> select u.name "OWNER" ,o.name "TABLE_NAME" ,p.valchar
    from  sys.OPTSTAT_USER_PREFS$ p
    inner join sys.obj$ o on p.obj#=o.obj#
    inner join sys.user$ u on o.owner#=u.user#
    where p.PNAME = 'INCREMENTAL';

  • Synopsis for tables which don't exist anymore?
    SQL> select distinct h.bo# from sys.wri$_optstat_synopsis_head$ h where not exists (select 1 from sys.tab$ t where t.obj# = h.bo#);
    .

Especially a large number of tables being monitored and a size of tens and hundreds of GBs will indicate that you may have to calculate for a longer upgrade duration.

How do you cure this?

Support sometimes gives the recommendation to look for MOS Note: 1055547.1 - SYSAUX Grows Because Optimizer Stats History is Not Purged and asks for a manual purge of stats, for instance:

begin
for i in reverse 1..31
loop
dbms_stats.purge_stats(sysdate-i);
end loop;
end;
/

But this won't clean up the synopsis tables but only stats history for object statistics. And it may create some noise in your UNDO. So in any case you may better set your stats retention policy to something such as 10 days instead of the default of 31 days instead generally.

First of all you have to make sure that this patch got applied to your target already before upgrade - it will add parallel index capabilities which will speed up the rebuild a lot: 

Be aware:
Truncating WRI$_OPTSTATS_SYNOPSIS$ and WRI$_OPTSTAT_SYNOPSIS_HEAD$ is strictly not recommended. If you plan to do it the hard way please check back with Oracle Support for their approval first.
.

Further Information?

Please read on here about a real world customer example ... 

 


--Mike

Tuesday Apr 26, 2016

MOS Note 1454618.1: Quick Reference to Database PSUs, CPUs, BPs and Patchsets

Sometimes my mouse arm gets tired by clicking myself through MOS notes just to download a specific PSU or BP - and as I experiment a lot with PSUs and BPs right now I clicked a lot in the past days and nights. 

Usually I'd start with either MOS Note:161818.1 - then click on the release link (e.g. 12.1.0.x) in the left-most column, then into the Availability and Known Issues not (e.g. MOS Note:1683799.1 for Oracle Database 12.1.0.2.0) and then select the most recent patch from the list of Current Recommended Patches.

Even though we all agree that you should be ideally always on the most recent BP (or at least PSU) there may be situations where you need to access an older PSU or BP or just the CPU.
So what if you need for instance the October 2015 PSU?
This is obviously not linked from the above note.

My usual click routine guides me via the Critical Patch Updates and Security Alerts page, from there via the particular release date (e.g. October 2015) to the Database Server Version (e.g. linked from here is MOS Note:2037108.1) and then to the patch number I'm searching for.

Just learned a few days ago by accident that there's a MOS Note which I have on my favorites since then:

containing all this information - even for 8.1.7.4 patches if you still need them ;-)

After listing the base release first followed by the available patch sets it offers you the links to the PSUs, CPUs and BPs - and if you are looking for the patches containing the OJVM you'll find them by scrolling down towards the end of the note as well in a separate section. 

*** Don't get puzzled by the note's title - it lists the Bundle Patches for Windows only inside, not the general link to all BPs. Myself and a colleague left already feedback for the note owner to add the BP links (or Proactive Bundle Patch links) as well *** 

MOS Note Patches PSUs CPUs SPUs BPs

In fact a very useful MOS Note.
.

--Mike

Friday Apr 22, 2016

New PREUPGRD.SQL is available - Upgrade 12c - Apr16

It's time for a new and improved version of our team's preupgrd.sql (comes with the preupgrade package utluppkg.sql). 

The April 2016 preupgrd.sql 

Please always download and use the most recent version from:

as this version is 3 years newer than the one you'll get with a fresh install of Oracle Database 12.1.0.2

preupgrd.sql - April 2016 - MOS Note:884522.1
.

Included in the April 2016 PSU and BP as well

Great news - and very important. Once you apply the most recent April 2016 PSU or BP (recommended - please see here: April 2016 PSU/BP are here!) then you'll get the most recent version of the preupgrd.sql with utluppkg.sql as well automatically.

No need to download it separately anymore once you are on this PSU or BP.
.

--Mike

Thursday Apr 21, 2016

Oracle Database BP April16 applied successfully

Usually I don't post twice a day but as my post scriptum for the previous blog post got longer and longer I decided to write an entry about it - maybe simply because I feel soooo happy that my patch application succeeded flawless.

For many of you the following steps may look very boring as you have done this many times. But I use the blog also to brain-dump information for myself ;-) And for those who'd like to play with it, I summarized the steps fitting exactly into our Hands-On-Lab environment.

Download

I downloaded the following patches: 

Unzip

Then unzipped the patch into an empty directory and OPatch directly into the $ORACLE_HOME/OPatch directory in my 12.1.0.2 home.  As I run everything in our HOL environment (download it here) I stored the files on my local host and mapped the directories via a VBox shared folder. 

  • BP into: /media/sf_CTEMP/22899531/22899531/
  • OPatch into: unzip <OPATCH-ZIP> -d <ORACLE_HOME>
    .

Prechecks

Not sure if the 2nd conflict check was really necessary as it is a CRS patch. 

  • System Space Check 
    • Created a file /tmp/patch_list_dbhome.txt with the following content:
      /media/sf_CTEMP/22899531/22899531/22806133
      /media/sf_CTEMP/22899531/22899531/23006522
    • Run opatch to check if enough free space is available in the Database Home:
      $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_dbhome.txt

My first attempt failed - I had to clean up a bit.

After I removed a bit of stuff (I actually deleted the 12.1.0.1 home with $ORACLE_HOME/deinstall/deinstall after switching to the 12.1.0.1 environment with . cdb1 in the HOL environment) I could install the BP. 
.

Patch Installation

Here it struck me a bit that the logical layout of the patches readme is still very misleading. I was scrolling up and down to find the section for "Database Home only" install but realized that is is still buried under Patching Oracle RAC Database Homes and GI Together which does not make much sense. Anyhow, I stopped arguing with the owners. 

The section I'm interested in here is under Case 3: Non-Oracle RAC Database homes.

  • Shutdown my database(s) and my listener - in the lab env this means:
    • . cdb2
    • sqlplus / as sysdba
    • SQL> shutdown immediate
    • SQL> exit
    •  lsnrctl stop
  • Add OPatch to the PATH 
    • export PATH=$PATH:/u01/app/oracle/product/12.1.0.2/OPatch
  • Switch to the patches directory and apply the BP
    • cd /media/sf_CTEMP/22899531/22899531/22806133
    • opatch apply

 And after a while ... 


.

SQL Changes 

Almost done. But don't forget to run ./datapatch -verbose afterwards - see the readme's section:

2.6.2 Loading Modified SQL Files into the Database

As it is a Multitenant database in my case I'll have to start the database and the listener first, then start all pluggable databases: 

  • . cdb2
  • sqlplus / as sysdba
  • SQL> startup
  • SQL> alter pluggable database all open;
  • SQL> exit
  • lsnrctl start
  • cd $ORACLE_HOME/OPatch
  • ./datapatch -verbose

And finally ...

... after another little while ...

Done!
.

--Mike

Oracle April 2016 PSU and Proactive BPs are there

Hurray, it's Patching Day!

Sounds a bit like D-Day ;-) But April 19, 2016 the most recent April PSUs (Patch Set Updates) and BPs (Bundle Patches) got released.

Find all the necessary information with the below links: 

The important change in the April PSU/BP release:
The database patch for "Engineered Systems and Database In-Memory 12.1.0.2" luckily got renamed into "Proactive Bundle Patch 12.1.0.2". That is not only a rebranding but it should express that we would like to encourage you to apply the Bundle Patches
instead of the PSUs. Simple reason is that the BPs will contain optimizer fixes. 

In the MOS Note: 2102148.1 (Patch Set Update and Critical Patch Update April 2016 Availability Document) you'll find a section 3.1.4 linking to the database patches

This is the recommended one for Oracle Database 12.1.0.2:

  • Database Proactive Bundle Patch 12.1.0.2.160419 (Apr2016) Patch 22899531,

But right now it is available for Linux-x86-64, zLinux and Intel Solaris only. Not sure when the others will get released. Please find links to the regular PSUs and other ports and releases such as 11.2.0.4 and Windows etc in the above MOS Note: 2102148.1.

This is the list of fixes included in this Bundle Patch:

And don't worry about the name - I found out yesterday that not all MOS Notes have adopted the new naming convention to rename "Bundle Patches for Engineeered Systems and DB In-Memory" which was very misleading anyway into the new "Proactive Bundle Patches" naming. This may take a few additional days I'd guess ...

I will download it right now and patch my HOL environment.

And as usual don't forget the most recent version of opatch (Patch 6880880).

opatch download MOS

.

--Mike 
.


Wednesday Apr 20, 2016

Data Pump - Exclude Stats differently for TTS and FTEX

Nice little best practice for statistics and Data Pump when doing either Transportable Tablespaces or Full Transportable Export-Import (credits to Roy and Dean Gagne).
.

Transport Statistics via a Staging Table

First of all we always recommend to exclude statistics when doing a Data Pump export as the import of such stats takes way longer than transporting them via a stats table. If you are unfamiliar with transporting stats between databases please see the Oracle Performance Tuning Guide with a nice tutorial

The basic steps to transport statistics from one database to another fast and efficient consist of: 

  1. Create a staging table in your source database with DBMS_STATS.CREATE_STAT_TABLE
  2. Export your local stats into this staging table by using DBMS_STATS.EXPORT_SCHEMA_STATS
  3. Export the staging table and import it into your destination database with Data Pump
  4. Import the statistics held in the staging table by using DBMS_STATS.IMPORT_SCHEMA_STATS

For the regular Data Pump exports we always recommend to set:

EXCLUDE=STATISTICS

to avoid performance penalties during impdp.

But this does not affect Transportable Tablespaces and Full Transportable Export/Import.
.

How to exclude Statistics for TTS and FTEX?

For reasons I don't know the metadata heterogeneous object for "transportable" is different than all of the others Therefore in order to exclude statistics for Transportable Tablespaces and Full Transportable Export/Import you must set:

EXCLUDE=TABLE_STATISTICS,INDEX_STATISTICS

Tuesday Apr 19, 2016

RMAN Catalog Upgrade fails - ORA-02296 - error creating modify_ts_pdbinc_key_not_null

This issue got raised to my via a customer I know for quite a while - all credits go to Andy Kielhorn for digging down into that issue and solving it. 
,

Failed RMAN Catalog Upgrade from 11.2.0.4 to 12.1.0.2

The RMAN catalog upgrade:

SQL> @?/rdbms/admin/dbmsrmansys.sql

$ rman CATALOG rman/xxx@rman01

RMAN> UPGRADE CATALOG; 

RMAN> UPGRADE CATALOG;

failed with the following sequence of error messages: 

error creating modify_ts_pdbinc_key_not_null
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-02296: cannot enable (RMAN.) - null values found

error creating modify_tsatt_pdbinc_key_not_null
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-02296: cannot enable (RMAN.) - null values found

error creating modify_df_pdbinc_key_not_null
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-02296: cannot enable (RMAN.) - null values found

error creating modify_tf_pdb_key_not_null
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-02296: cannot enable (RMAN.) - null values found

error creating modify_bs_pdb_key_not_null
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-02296: cannot enable (RMAN.) - null values found

Andy found also these bugs in MOS - but no helpful information included:

  • Bug 20861957
    ORA-2296 DURING UPGRADE CATALOG TO 12.1,0.1 IN AN 11.2 DATABASE
  • Bug 19677999
    CATALOG SCHEMA UPGRADE TO 12.1.0.2 FAILED
.

The  Solution

There seems to be a potential inconsistency in the RMAN catalog when the PDB/CDB mechanisms get introduced. This does not necessarily happen - but it can happen.

The workaround is described in:

  • Bug 19677999 : CATALOG SCHEMA UPGRADE TO 12.1.0.2 FAILED

==> Connect to catalog schema and clear the table having null details 

delete bdf where not exists (select 1 from dbinc where dbinc.dbinc_key = bdf.dbinc_key);
delete bcf where not exists (select 1 from dbinc where dbinc.dbinc_key = bcf.dbinc_key);
commit;

==> After clearing the offending rows , upgrade catalog worked

But please use this workaround only under Oracle Support's supervision. I did document it here to ease your verification.

Andy fixed it with:

update <rmancat_owner>.dbinc set PARENT_DBINC_KEY=NULL where (DBINC_KEY) IN (SELECT DBINC_KEY  from  <rmancat_owner>..ts where pdbinc_key is null); 
commit;

but please open an SR and point Oracle Support to the bug and the potential workarounds in case you hit the issue.
.

--Mike

Monday Apr 18, 2016

Patching does not work - Journey to the Cloud VI

DBaaS Oracle Cloud

What happened so far on my Journey to the Cloud?


Patching in the Cloud

I would like to patch my Oracle DBaaS Cloud today. It was so simple a few weeks ago. But I didn't patch it yet up to the January 2016 PSU (12.1.0.2.160119PSU) - shame on me :-(

Please don't be scared by the weird mix of German and English - I filed a bug for this months ago ... and maybe one magic sunny day I can switch the language back to pure English ...

Anyhow, I choose my VM and it highlighted to me an available patch to apply, the January 2016 PSU:


.

Let's do the PreCheck 

I chose PRECHECK first from the drop-down hamburger menu to the right and received the following message: 

But where are the logs? There is no link, no hint, nothing.
.

Let's check the README 

At this point I decided to check the README to find out whether I missed something important. So I clicked on README and received this meaningful message:

Potentially not a fault of the Cloud folks as I realized by myself that the MOS facility to link patches directly is broken since weeks. A manual interaction in MOS to locate the README is necessary - but it gave me no indication regarding the above failed precheck.
.

Force to apply the PSU 

Next step: FORCE to apply the patch (2nd option in the hamburger menu). But again the result is not positive showing me again a weird mix of Denglish (Deutsch and English).

.

Result?

Well, that is somewhat unexpected. I checked with some people who are way more familiar than I with our DBaaS Cloud after consulting our documentation and googling around - and learned that this functionality is broken since several weeks,

No further comment necessary.
.

--Mike

Thursday Apr 07, 2016

Collaborate16 - See you on Monday!

Collaborate Conference 2016

Time flies.

 I already started packing stuff for COLLABORATE16 - and I hope to see you in Las Vegas from April 10-14, 2016 :-)

These are the sessions I'll present: 

And if you'd like to discuss your topics in more detail feel free to visit me at the:

Oracle Booth #1053
Exhibit Hall - Bayside C/D, Level 1 – Mandalay Bay South Convention Center

  • Wednesday, April 13
    • 10:15 a.m. - 11:15 p.m. 
    • 12:15 p.m. - 1:15 p.m.

     CU soon!

    --Mike
    .

    Thursday Mar 31, 2016

    DROP PLUGGABLE DATABASE - things you need to know

    Directly after my DOAG (German Oracle User Group) Conference presentation about "How Single-/Multitenant will change a DBA's life" Martin Bach (Enkitec) approached me and told me about his experiences with the DROP PLUGGABLE DATABASE command and future recoverability.

    Martin discovered that once you issued the DROP PLUGGABLE DATABASE command you can't reuse a previously taken backup of this particular PDB anymore and recover the PDB into this existing CDB. I wasn't aware of this and I'm glad that Martin told me about it.

    Actually only the meta information in the controlfile or the RMAN catalog will be deleted. But archive logs and backup still persist.

    See also my blog post from Jan 9, 2015:
    Recent News about Pluggable Databases - Oracle Multitenant

    This is the error message you'll see when you try to recover a dropped pluggable database:

    RMAN> restore pluggable database pdb2drop;

    Starting restore at 01-JUN-15
    using channel ORA_DISK_1
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of restore command at 06/01/2015 10:10:40
    RMAN-06813: could not translate pluggable database pdb2drop

    Just a few weeks ago a colleague from German presales asked me if I know a more convenient way to restore a PDB once the magic command (DROP PLUGGABLE DATABASE) has been issued than recovering it into an auxiliary container database abd unbplug/plug it. I haven't.

    But Nik (thanks!!!) told me that he pushed a MOS Note to being published explaining how to workaround this issue: 

    MOS Note: 2034953.1
    How to Restore Dropped PDB in Multitenant

    In brief this MOS Note describes how to:

    • Create an auxiliary container database
    • Recover the backup (yes, you will have to have a backup of your container database) including this particular PDB
    • Unplug the PDB after recovery has been finished and plug it back into the original CDB

    Now some will say: Hey, that's simple and obvious. For me it wasn't ;-) That's why I write about it to remind myself of this workaround ...

    --Mike
    .



    Wednesday Mar 30, 2016

    DBUA and Read-Only Tablespaces - Things to Know II

    Related Blog Posts:



    Thanks to Rodolfo Baselli commenting on a previous blog post about the DBUA and Read-Only Tablespaces I dug a bit deeper and found out that "assuming silently" does not mean "works as intended".

    But one piece after another.

    Rodolfo commented that if he triggers the DBUA to switch all data tablespaces into read-only mode for the duration of the upgrade it will be still him to create the correct backup, the DBUA won't do it.

    This is the option in the Oracle Database 12.1.0.2 DBUA (Database Upgrade Assiatant):

    DBUA - Tablespaces in Read Only Mode

    I did silently assume that the DBUA will choose the correct backup strategy automatically when it offers (enabled by default) to create an Offline Backup on the Recovery Options screen a while later in the same dialogue.

    Backup Strategy DBUA

    But in fact it doesn't.

    When you choose the default, "Create a New Offline RMAN Backup" it will create a full offline RMAN  backup to the desired location - but not an partial offline backup as intended by the optional trigger to have the tablespaces in read-only mode during upgrade to allow a fast and simple restore without the need for a recovery. Please note that I would recommend this option generally only in cases where the database is on purpose in norarchivelog mode or where the RTO (Recovery Time Objective) is met only by restoring a partial offline backup.

    What are your options now?

    If you switch on the Read-Only option on purpose you'll have to choose "I have my own backup and restore strategy" and do the partial offline backup by yourself - before you start the DBUA.

    Personally I'd consider this option as not useful when used within the DBUA right now. We have discussed this internally, it may work correctly in a future patch set for the upcoming next release of the database therefore no offense to anybody. It's just important to know that you'll have to do the partial offline backup by yourself at the moment.
    .

    --Mike

    Tuesday Mar 29, 2016

    Disable Transparent Hugepages on SLES11, RHEL6, RHEL7, OL6, OL7 and UEK2 Kernels

    This blog post is not related to database upgrades and migrations. But still I think it is very useful for many customers operating on modern Linux systems.

    Recommendation 

    Support just published an ALERT strongly recommending to disable Transparent Hugepages on Linux systems. And the below information does not apply to RAC systems only but also to single instance environments.
    .

    Which Linux Distrubutions/Kernels are affected? 

    • SLES11
    • RHEL6 and RHEL7
    • OL6 and OL7
    • UEK2 Kernels
      .

    What are the Issues? 

    I'm quoting MOS Note: 1557478.1 (ALERT: Disable Transparent HugePages on SLES11, RHEL6, RHEL7, OL6, OL7 and UEK2 Kernels):

    Because Transparent HugePages are known to cause unexpected node reboots and performance problems with RAC, Oracle strongly advises to disable the use of Transparent HugePages. In addition, Transparent Hugepages may cause problems even in a single-instance database environment with unexpected performance problems or delays. As such, Oracle recommends disabling Transparent HugePages on all Database servers running Oracle.

    This ONLY applies to the new feature Transparent HugePages, Oracle highly recommends the use of standard HugePages that were recommended for previous releases of Linux.  See MOS Note:361323.1 for additional information on HugePages. 

    As far as I see you'll have to reboot the server in order to disable Transparent Hugepages - the default is usually ALWAYS.
    .

    More Information?

     --Mike

    Wednesday Mar 23, 2016

    What does DEPRECATED mean? And DESUPPORTED?

    There's sometimes a misunderstanding about what we mean with the term DEPRECATED? And what is the difference to DESUPPORTED? Actually there's a full chapter in the Database Upgrade Guide listing deprecated and desupported features.

    Deprecated

    Especially this message puzzled a lot of customers stating that the non-CDB architecture is deprecated in Oracle Database 12c.


    In the Database Upgrade Guide we clearly explain what deprecated means:

    "By deprecate, we mean that the feature is no longer being enhanced but is still supported"

    So for you it means just be aware that we don't further develop or enhance something. But you are still fully supported by using this feature.

    Another well known example is Oracle Streams which is fully supported in Oracle Database 12c - but not in Oracle Multitenant - and is deprecated and therefore not enhanced or developed any further. 

    Or to name another example, Oracle Restart, which is deprecated for some time - but still not desupported. And I know a good bunch of customers using it in production even with Oracle Database 12.1.0.2 on several hundred databases.
    .

    Desupported

    Even if something is desupported - remember the Rule Based Optimizer? - you can still use a feature being desupported. But on your own risk as we don't fix any bugs or issues anymore. 

    Again the Database Upgrade Guide clarifies the term:

    "By desupported, we mean that Oracle will no longer fix bugs related to that feature and may remove the code altogether"

    Other common examples in Oracle Database 12c are the Enterprise Manager Database Control which simply does not exist anymore in Oracle Database 12c or the desupport of Raw Devices.
    .

    Summary

    Deprecated is a signal that something may disappear in the future and does not get enhanced anymore. No activity required except of taking note for your future plans. Desupported means that we don't fix anything anymore for a desupported feature or product - and it may even disappear. But often desupported features are still there and can be used on your own risk only. 
    .

    --Mike
    .


    Tuesday Mar 22, 2016

    GC Freelist Session Waits causing slowness and hangs

    Best Practice Hint

    One of the best things in my job:
    I learn from you folks out there. Everyday. 

    Credits here go to Maciej Tokar who did explain the below topic to me via LinkedIn - thanks a lot, Maciej! 
    .

    Locks are not being closed fast enough, resulting in gc freelist waits

    You can find a reference for Global Cache Freelist in the Oracle Documentation. This issue here can or will lead to database being slow, up to complete hangs. Based on my research it looks as the issue is not related to RAC only but a general thing. In your session waits you'll spot this:

    Event                               Event Class        % Event   Sessions
    ----------------------------------- --------------- ---------- ----------
    gc freelist                         Cluster              41.37       8.61

    This has been logged as a bugs 21352465 (public) and 18228629 (not public). It causes locks are not being closed fast enough, resulting in gc freelist waits. In conjunction the default for _gc_element_percent seemed to be too low at 120 (or 110 in 11.2.0.4).

    Actually the issue can affect not only Oracle Database 12.1.0.2 but also Oracle Database 11.2.0.3 and 11.2.0.4.

    See MOS Note:2055409.1 (Database Hangs with High "gc freelist" wait ) for further details.
    .

    Solution

    • Apply the patch for bug 18228629 on top of a PSU or BP where available
      • See the drop-down list to the right labeled "Release" to access the correct patch for your release
      • Unlike the above MOS Note states in Oracle Database 12.1.0.2 it is only available on top of the January 2016 PSU and BP and two other Exadata BPs - and on Linux only!
        .
    • Use the workaround and set _gc_element_percent = 200
      • This will require an instance restart as the parameter can't be changed dynamically:
        alter system set "_gc_element_percent"=200 scope=spfile;
        .

    Epilogue

    We've had a lot of discussions about underscore parameter in the past weeks. And I'm not a big fan of underscores especially when it comes to upgrades as experiences has shown that having underscores set one day may make it hard to remove them the other day - and underscores can significantly impact the upgrade duration in a negative way.

    But on the other hand, if an issue is seriously affecting many customers, and there's no patch available for your platform and environment right now, what else can one do?
    .

    --Mike

    .

    Wednesday Mar 09, 2016

    OUGN Conference - On the boat again

    OUGN Spring Conference 2016

    Last year influenza took me down and out just a couple of days before my planned departure for the famous OUGN Spring Conference. But this year (so far) I'm still happy and healthy and on my way towards beautiful Oslo. I'm really looking forward to this year's OUGN Spring Conference which will happen again on the boat departing from Oslo and sailing over to Kiel - and then returning back.

    In case you plan to visit my talks and demos:

    • Thursday, 10-March-2016 - 14:00-14:45h - Parliament 1+2
      How Oracle Single Tenant will change a DBA's life
      .
    • Friday, 11-March-2016 - 10:30-11:15h - Parliament 1+2
      Oracle Database Upgrade: Live and Uncensored
      .

    Looking forward to this wonderful event with so many good talks and presentations and such a great group of people. And thanks to the organizers of OUGN!

    --Mike

    .

    Tuesday Mar 08, 2016

    Parameter Recommendations for Oracle Database 12c - Part II


    Best Practice Hint

    Time for a new round on Parameter Recommendations for Oracle Database 12.1.0.2. The focus of this blog post settles on very well known parameters with interesting behavior. This can be a behavior change or simply something we'd like to point out. And even if you still work on Oracle Database 11g some of the below recommendations may apply to your environment as well.

    Preface

    Again, please be advised - the following parameter list is mostly based on personal experience only. Some of them are officially recommended by Oracle Support. Always use proper testing mechanisms.

    We strongly recommend Real Application Testing, especially the SQL Performance Analyzer but also Database Replay to verify the effect of any of those parameters. 
    .

    Known Parameters - Interesting Behavior

    • parallel_min_servers
      • What it does?
      • Default:
        • CPU_COUNT * PARALLEL_THREADS_PER_CPU * 2
      • Behavior Change:
        • Setting it to a value below the default will let the database ignore it.
        • In Oracle Database 11g the default was 0
        • Compare 11.2.0.4 vs 12.1.0.2 on the same box:
          • 11g:
            SQL> show parameter parallel_min_servers
            NAME                  TYPE     VALUE
            --------------------- -------- ------
            parallel_min_servers  integer  0

          • 12c:
            SQL> show parameter parallel_min_servers
            NAME                  TYPE     VALUE
            --------------------- -------- ------
            parallel_min_servers  integer  8
      • Explanation:

    • job_queue_processes
      • What it does?
        • See the Oracle Documentation - value specifies the maximum number of job slaves to be created to execute jobs started by either DBMS_JOBS or DBMS_SCHEDULER
      • Default:
        • 1000
      • Recommendation:
        • Set it to a rough equivalent of 2 * CPU cores
      • Explantion:
        • In Oracle Database 12c we introduced the automatic stats gathering during CTAS and IAS (into an empty table only) operations. This can potentially lead to too many jobs doing the stats gathering. Furthermore issues can happen due to the default of concurrent stats gathering.
          Therefore a limitation of this parameter seems to be a good idea. 
        • Be aware when switching it to 0 - this will block all recompilation attempts. Furthermore generally no jobs can be executed anymore with  DBMS_JOBS or DBMS_SCHEDULER.
        • Multitenant behavior change:
          In 12.1.0.1, job_queue_process was a Container Database (CDB) modifiable parameter (ie. at a global level). However, in 12.1.0.2, the job_queue_process parameter is not CDB modifiable; instead it's PDB modifiable which means each PDB can have its own job_queue_process value.  
      • More Information:
      • Annotation:
        I've had an email exchange with Stefan Köhler about the stats behavior for CTAS. As I couldn't myself reproduce the behavior we say at two customer with job_queue_processes=1000 and an heavy CTAS activity (which could be remedied by setting JQP to a lower value) I would put a question mark behind my above statement.

        .
        .
    • recyclebin
      • What it does?
        • See the Oracle Documentation - controls whether the Flashback Drop capability is turned on or off. If the parameter is set to OFF, then dropped tables do not go into the recycle bin. If this parameter is set to ON, then dropped tables go into the recycle bin and can be recovered.
      • Default:
        • ON
      • Recommendation:
        • If the recyclebin is ON (the default) in your environment then empty it at least once per week. Create a default job in all your environments emptying the recycle bin every Sunday morning at 3am for instance:
          SQL> purge DBA_RECYCLEBIN;
      • Explantion:
        • The recycle bin is on in every database by default since Oracle 10g. The danger is that it may not be emptied but especially on developer databases many objects may be created and dropped again. As a result the dropped objects and its dependents still stay in the database until the space needs to be reclaimed. That means, they exist in the data dictionary as well, for instance in TAB$. Their name is different now starting with "BIN$..." instead of "EMP" - but they will blow up your dictionary. And emptying it not often enough may introduce a performance dip to your system as the cleanup of many objects can be quite resource intense
        • Check your current recycle bins:
          SQL > SHOW RECYCLEBIN;
          ORIGINAL NAME RECYCLEBIN NAME              OBJECT TYPE DROP TIME
          ------------- ---------------------------- ----------- -------------------
          TEST_RBIN     BIN$2e51YTaSK8TL/mPy+FuA==$0 TABLE       2010-05-27:15:23:45
          TEST_RBIN     BIN$5dF60S3GSEOSSYREaqCg==$0 TABLE       2010-05-27:15:23:43
          TEST_RBIN     BIN$JHCDN9YwQRXjXGOJcCIg==$0 TABLE       2010-05-27:15:23:42
      • More Information:
    .
    .

    • deferred_segment_creation
      • What it does?
        • See the Oracle Documentation - set to the default (TRUE), then segments for tables and their dependent objects (LOBs, indexes) will not be created until the first row is inserted into the table
      • Default:
        • TRUE
      • Recommendation:
        • Set it to FALSE unless you plan to create a larger number of tables/indexes knowing that you won't populate many of them.
      • Explantion/Risk:
        • If my understanding is correct this parameter got introduced with Oracle Database 11.2 in order to save space when applications such as EBS, Siebel or SAP create tons of tables and indexes which never may get used as you don't work with the matching module of the software
        • The risk can be that certain query check DBA_SEGMENTS and/or DBA_EXTENTS - and if there's no segment allocated you won't find an indication about the existence of the object in there - but it actually exists. Furthermore we have seen issues with Data Pump workers getting contention, and some other things. 
      • More Information:
        • The documentation has become now pretty conservative as well since Oracle 11.2.0.4 and I'll second that:
          Before creating a set of tables, if it is known that a significant number of them will not be populated, then consider setting this parameter to true. This saves disk space and minimizes install time.
          ..
     --Mike

    Friday Mar 04, 2016

    Parameter Recommendations for Oracle Database 12c - Part I

    Best Practice Hint

     A few weeks ago we've published some parameter recommendations including several underscores but based on an internal discussion (still ongoing) we decided to remove this entry and split up the tasks. The optimizer team will take over parts of it and I'll post an update as soon as something is published.

    .

    Preface

    Please be advised - the following parameter list is mostly based on personal experience only. Some of them are officially recommended by Oracle Support. Always use proper testing mechanisms.

    We strongly recommend SQL Performance Analyzer to verify the effect of any of those parameters. 
    .

    How to read this blog post?

    Never ever blindly set any underscore or hidden parameters because "somebody said" or "somebody wrote on a blog" (including this blog!) or "because our country has the best tuning experts worldwide" ... Only trust Oracle Support if it's written into a MOS Note or an official Oracle White Paper or if you work with a particular support or consulting engineer for quite a long time who understands your environment.
    .

    Important Parameter Settings

      • _kks_obsolete_dump_threshold
        • What it does?
          • Introduced in Oracle 12.1.0.2 as an enhancement  to improve cursor sharing diagnostics by dumping information about an obsolete parent cursor and its child cursors after the parent cursor has been obsoleted N times. 
        • Problem:
          • Trace files can grow like giant mushrooms due to cursor invalidations
        • Solution:
        • Patches:
          • Fix included in DBBP 12.1.0.2.160216
          • Fix on-top of 12.1.0.2.13DBEngSysandDBIM
          • Since Feb 13, 2016 there's a one-off available but on Linux only - and only on top of a fresh 12.1.0.2 
        • Remarks:
          • The underlying cursor sharing problem needs to be investigated - always
            If you have cursor sharing issues you may set this parameter higher therefore not every invalidation causes a dump, then investigate and solve the issue, and finally switch the parameter to 0 once the issue is taken care of. 
            Please be aware that switching the parameter to 0 will lead to a lack of diagnostics information in case of cursor invalidations.


      • _use_single_log_writer
      • memory_target
        • What it does?
        • Problem:
          • Unexpected failing database upgrades with settings of  memory_target < 1GB where equal settings ofsga_target and pga_aggregate_target didn't cause issues 
          • It prevents the important use of HugePages
        • Solution:
          • Avoid memory_target by any chance
          • Better use sga_target and pga_aggregate_target instead


      • pga_aggregate_limit

      Essential MOS Notes for Oracle Database 12.1.0.2

      --Mike
      .

      Tuesday Mar 01, 2016

      Differences between Automatic Statistics Gathering job and GATHER_SCHEMA_STATS

      Recently a customer raised a question whether there are differences between the Automatic Statistics Gathering job and a manual creation of stats via the GATHER_SCHEMA_STATS procedure.

      The results in performance were quite interesting. Performance after an upgrade from Oracle Database 11.2.0.3 to Oracle Database 11.2.0.4 was not good when the automatic stats job got used. But performance changed significantly to the better when schema stats were created with the downside of taking more resources during the gathering.

      Is the Automatic Stats Gathering job enabled?

      That question can be answered quite easily. There's a very good MOS Note:1233203.1 - FAQ: Automatic Statistics Collection displaying this query:

      SELECT CLIENT_NAME, STATUS FROM DBA_AUTOTASK_CLIENT WHERE CLIENT_NAME='auto optimizer stats collection';

      The MOS Note has also the code to enable (or disable) the job.
      .

      Which parameters/settings are used?

      That question is a bit more tricky as the Note says: "The automatic statistics-gathering job uses the default parameter values for the DBMS_STATS procedures". But how do I display them?

      The following script will display the parameters being used during the Automatic Statistics Gathering:

      SET ECHO OFF
      SET TERMOUT ON
      SET SERVEROUTPUT ON
      SET TIMING OFF
      DECLARE
         v1  varchar2(100);
         v2  varchar2(100);
         v3  varchar2(100);
         v4  varchar2(100);
         v5  varchar2(100);
         v6  varchar2(100);
         v7  varchar2(100);
         v8  varchar2(100);
         v9  varchar2(100);
         v10 varchar2(100);        
      BEGIN
         dbms_output.put_line('Automatic Stats Gathering Job - Parameters');
         dbms_output.put_line('==========================================');
         v1 := dbms_stats.get_prefs('AUTOSTATS_TARGET');
         dbms_output.put_line(' AUTOSTATS_TARGET:  ' || v1);
         v2 := dbms_stats.get_prefs('CASCADE');
         dbms_output.put_line(' CASCADE:           ' || v2);
         v3 := dbms_stats.get_prefs('DEGREE');
         dbms_output.put_line(' DEGREE:            ' || v3);
         v4 := dbms_stats.get_prefs('ESTIMATE_PERCENT');
         dbms_output.put_line(' ESTIMATE_PERCENT:  ' || v4);
         v5 := dbms_stats.get_prefs('METHOD_OPT');
         dbms_output.put_line(' METHOD_OPT:        ' || v5);
         v6 := dbms_stats.get_prefs('NO_INVALIDATE');
         dbms_output.put_line(' NO_INVALIDATE:     ' || v6);
         v7 := dbms_stats.get_prefs('GRANULARITY');
         dbms_output.put_line(' GRANULARITY:       ' || v7);
         v8 := dbms_stats.get_prefs('PUBLISH');
         dbms_output.put_line(' PUBLISH:           ' || v8);
         v9 := dbms_stats.get_prefs('INCREMENTAL');
         dbms_output.put_line(' INCREMENTAL:       ' || v9);
         v10:= dbms_stats.get_prefs('STALE_PERCENT');
         dbms_output.put_line(' STALE_PERCENT:     ' || v10);
      END;
      /

      The settings of the DBMS_STATS.GATHER_SCHEMA_STATS procedure are documented:
      https://docs.oracle.com/database/121/ARPLS/d_stats.htm#ARPLS68577 

      When you compare the two you'll see that the settings/defaults are identical. 
      .

      But what is the difference between these two?

      Both activities use the same parameters. So the stats will look the same - IF they get created. The real difference between the Automatic Statistics Gathering job and a manual invocation of GATHER_SCHEMA_STATS is that the latter will refresh ALL statistics whereas the Automatic Statistics Gathering job will refresh only statistics on objects where statistics are missing or marked as STALE.

      The same behavior appears when you compare the recommendation to gather dictionary statistics before the upgrade by using DBMS_STATS.GATHER_DICTIONARY_STATS versus a DBMS_STATS.GATHER_SCHMEA_STATS('SYS')call. The latter will refresh all statistics whereas the first one will take less resources but refresh only STALE and missing statistics.
      .

      A simple example

      This script is kept as simple as possible.

      • It creates a test user
      • It creates two tables within this user - tablespace USERS
      • It inserts and updates information in the two tables
      • It flushes the monitoring information (how many DMLs got run?) out
      • It gathers stats on only one table to verify that STALE is working as intended
      • It kicks off the automatic stats gathering job
      • It kicks off the schema stats gathering call
      • It compares results before/after in the stats history table 

      set timing on
      set serverout on
      set echo on
      set termout on
      column table_name Format a5
      column owner      Format a6
      column stale_stats Format a4
      column last_analyzed Format a15
      column sample_size format 9999999
      drop user test1 cascade;
      create user test1 identified by test1;
      grant connect, resource, dba to test1;
      alter user test1 default tablespace USERS;
      create table TEST1.TAB1 as select * from dba_objects where rownum<50001;
      exec dbms_stats.gather_table_stats('TEST1','TAB1');
      create table TEST1.TAB2 as select * from dba_objects where rownum<50001;
      exec dbms_stats.gather_table_stats('TEST1','TAB2');
      insert into TEST1.TAB1 select * from dba_objects where rownum<50001;
      commit;
      insert into TEST1.TAB2 select * from dba_objects where rownum<50001;
      commit;
      insert into TEST1.TAB2 select * from dba_objects where rownum<50001;
      commit;
      update TEST1.TAB1 set object_id=object_id+0;
      commit;
      update TEST1.TAB2 set object_id=object_id+1;
      commit;
      exec DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO;
      select table_name,owner,stale_stats,to_char(last_analyzed,'DD-MON HH24:MI:SS') LAST_ANALYZED,SAMPLE_SIZE from dba_tab_statistics where table_name in ('TAB1','TAB2');
      exec DBMS_STATS.GATHER_TABLE_STATS('TEST1','TAB1');
      select table_name,owner,stale_stats,to_char(last_analyzed,'DD-MON HH24:MI:SS') LAST_ANALYZED,SAMPLE_SIZE from dba_tab_statistics where table_name in ('TAB1','TAB2');
      exec DBMS_AUTO_TASK_IMMEDIATE.GATHER_OPTIMIZER_STATS;
      pause Wait a bit - then press return ...
      select table_name,owner,stale_stats,to_char(last_analyzed,'DD-MON HH24:MI:SS') LAST_ANALYZED,SAMPLE_SIZE from dba_tab_statistics where table_name in ('TAB1','TAB2');
      exec dbms_stats.gather_schema_stats('TEST1');
      select table_name,owner,stale_stats,to_char(last_analyzed,'DD-MON HH24:MI:SS') LAST_ANALYZED,SAMPLE_SIZE from dba_tab_statistics where table_name in ('TAB1','TAB2');
      prompt End ...

      .

      The results

      exec
      DBMS_STATS.
      FLUSH_DATABASE_MONITORING_INFO;
      TABLE OWNER  STAL LAST_ANALYZED   SAMPLE_SIZE
      ----- ------ ---- --------------- -----------
      TAB1  TEST1  YES  29-FEB 22:37:07       50000
      TAB2  TEST1  YES  29-FEB 22:37:07       50000

      exec
      DBMS_STATS.
      GATHER_TABLE_STATS('TEST1','TAB1');
      TABLE OWNER  STAL LAST_ANALYZED   SAMPLE_SIZE
      ----- ------ ---- --------------- -----------
      TAB1  TEST1  NO   29-FEB 22:37:12      100000
      TAB2  TEST1  YES  29-FEB 22:37:07       50000

      exec
      DBMS_AUTO_TASK_IMMEDIATE.
      GATHER_OPTIMIZER_STATS;

      TABLE OWNER  STAL LAST_ANALYZED   SAMPLE_SIZE
      ----- ------ ---- --------------- -----------
      TAB1  TEST1  NO   29-FEB 22:37:12      100000
      TAB2  TEST1  NO   29-FEB 22:37:13      150000

      exec
      dbms_stats.
      gather_schema_stats('TEST1');

      TABLE OWNER  STAL LAST_ANALYZED   SAMPLE_SIZE
      ----- ------ ---- --------------- -----------
      TAB1  TEST1  NO   29-FEB 22:37:43      100000
      TAB2  TEST1  NO   29-FEB 22:37:43      150000

      The results can be interpreted this way:

      • The sample size of 50k is based on the first activity during the CTAS
      • Once table TAB1 gets analyzed the sample size is now correct - and the time stamp got updated - statistics on TAB2 are still marked STALE of course as the underlying table has changed by more than 10%
      • The Automatic Statistics Gathering job will refresh only stats for objects where stats are missing or marked STALE - in this example here TAB2. Table TAB1's statistics remain unchanged.
      • When the GATHER_SCHEMA_STATS job gets invoked it will refresh all statistics - regardless if they were STALE or not. 

      This is the behavior the customer who raised the question about differences in these two ways to create statistics may have seen. The GATHER_SCHEMA_STATS job took longer and consumed more resources as it will refresh all statistics regardless of the STALE attribute.

      And it's hard to figure out why the refresh of statistics created in a previous release may have led to suboptimal performance, especially as we talk about a patch set upgrade - and not a full release upgrade. Thanks to Wissem El Khlifi who twittered the following annotations I forgot to mention:

      • The Automatic Statistics Gathering job prioritizes objects with NO statistics over objects with STALE statistics
      • The Automatic Statistics Gathering job may get interrupted or skip objects leaving them with NO statistics gathered. You can force this by locking statistics - so the Auto job will skip those completely

      You'll find more information about the Automatic Statistics Gathering job here:

      And another strange finding ...

      When I played with this example in 12c I encountered the strange behavior of the GATHER_OPTIMIZER_STATS call taking exactly 10 minutes unti it returns to the command prompt.

      First I thought this is a Multitenant only issue. But I realized quickly: this happens in non-CDB databases in Oracle 12c as well. And when searching the bug database I came across the following unpublished bug:

      • Bug 14840737
        DBMS_AUTO_TASK_IMMEDIATE.GATHER_OPTIMIZER_STATS RETURNS INCORRECTLY

      which got logged in Oct 2012 and describes this exact behavior. I kick off the job - it will update the stats pretty soon after - but still take 10 minutes to return control to the command prompt. It is supposed to be fixed in a future release of Oracle Database ... 

       

      --Mike 

      Friday Feb 26, 2016

      Collaborate16 - See you soon!!!

      Collaborate Conference 2016

      If you haven't signed up for COLLABORATE16 yet, then please do so :-)

      And I hope to meet you and many other Oracle experts in Las Vegas from April 10-14, 2016.

      If you plan to attend one of our sessions mark them down in your conference scheduler:

      CU soon!

      --Mike
      .

      Thursday Feb 25, 2016

      What happened to the blog post about "12c parameters"?

      Best Practice Hint

      Two weeks ago I published a blog post about Parameter Recommendations for Oracle Database 12.1.0.2. And I took it down a day later. Why that?

      I've got a lot of input from external sources for the "Parameter" blog post. And I'd like to thank everybody who contributed to it, especially Oracle ACE Ludovico Caldara.

      Generally there was a bit of a misunderstanding internally about whether we should "advertise" underscore parameters to cure some misbehavior of the database. In 99% of all cases I'd agree that underscores are not a good solution - especially when it comes to database upgrades as our slide deck still contains a real world example about what happens when you keep old underscore parameters in your spfile. It can not only slow down the entire upgrade but also makes it very hard for Oracle Support to reproduce issues in case of something going the wrong direction. 

      But in some situations an underscore seems to be the only remedy in cases where a patch is not available for a particular release - the release you are using at the moment. And even if a patch is available or if the fix is available in a future PSU or BP that does not mean necessarily that one can apply it for several reasons.

      We still have a lot of very productive discussions going on internally between many groups. That is very good as it means that we have plenty of smart people around, especially in Oracle's Database Development :-)

      Furthermore we agreed that the Optimizer PM team will take over the part of my (taken down) blog post targeting wrong query results and other optimizer topics. We are in constant exchange and I'll link it as soon as something gets published.

      --Mike

      Monday Feb 15, 2016

      Upgrade Workshop on March 2, 2016 in Switzerland

      Grüezi alle miteinand!

      There are just a few seats open for the Upgrade / Migrate /Consolidate to Oracle Database 12c workshop on March 2, 2016 in Zürich in Switzerland open. If you would like to attend but haven't registered yet, please use this link to sign up:

      Workshop language will be German, slides will be in English.

      Looking forward to meet you there!

      --Mike 

      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
      « May 2016
      SunMonTueWedThuFriSat
      1
      2
      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
      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