Monday, September 30, 2013

Compression Advisor script - from 9i to 12c

A compression advisor (through DBMS_COMPRESSION) comes packaged with Oracle Database 11g Release 2 and Oracle Database 12c.
Oracle has made available a package you can use with Oracle Database 9i Release 2 through Oracle Database 11g release 1 - this is DBMS_COMP_ADVISOR available for download here.

This script is made to run for all versions, 9i to 12c, and requires only the database version as an input.

DECLARE
  v_owner            VARCHAR2(60);
  v_segment_name      VARCHAR2(60);
  v_execute112 varchar2(4000);
  v_execute10 varchar2(4000);
  v_execute varchar2(4000);
BEGIN       
  v_execute112 :=  q'[DECLARE
                      l_blkcnt_cmp       pls_integer;
                      l_blkcnt_uncmp     pls_integer;
                      l_row_cmp          pls_integer;
                      l_row_uncmp        pls_integer;
                      l_cmp_ratio        NUMBER;
                      l_comptype_str     VARCHAR2(60);
        begin dbms_compression.get_compression_ratio(
        -- input parameters
        scratchtbsname   => 'SYSAUX',       -- scratch tablespace
        ownname          => :v_owner,            -- owner of the table
        tabname          => :v_segment_name,    -- table name
        partname         => NULL,            -- partition name
        comptype         => dbms_compression.COMP_FOR_OLTP,      -- compression algorithm
        -- output parameters
        blkcnt_cmp       => l_blkcnt_cmp,    -- number of compressed blocks
        blkcnt_uncmp     => l_blkcnt_uncmp,  -- number of uncompressed blocks
        row_cmp          => l_row_cmp,       -- number of rows in a compressed block
        row_uncmp        => l_row_uncmp,     -- number of rows in an uncompressed block
        cmp_ratio        => l_cmp_ratio,     -- compression ratio
        comptype_str     => l_comptype_str   -- compression type
      ); 
      dbms_output.put_line('SegmentOwner: '||:v_owner||' SegmentName: '||:v_segment_name||' - '||' Ratio: '||to_char(l_cmp_ratio,'99.99'));
      end;]';
    v_execute10 := q'[declare
                      l_compression     NUMBER:= 10;
                      begin dbms_comp_advisor.getratio(:v_owner,:v_segment_name,l_compression);
                      end;]';
  if substr('&db_version',1,4)='11.2' or substr('&&db_version',1,2)='12' then
   v_execute := v_execute112;
  else 
    v_execute := v_execute10;
  end if;
  FOR rec IN (select segment_name, owner
            from (
              select * from
                    (select dba_tables.owner, segment_name, segment_type, dba_extents.tablespace_name, round(sum(dba_extents.bytes/1024/1024),2) SizeMB,
                            dba_tables.num_rows 
                    from dba_extents, dba_tables
                     where segment_type = 'TABLE' 
                     and  dba_tables.table_name = dba_extents.segment_name
                     and dba_tables.compression = 'DISABLED'
                group by dba_tables.owner, segment_name, segment_type, dba_extents.tablespace_name, 
                        dba_tables.num_rows,  
                        to_char(last_analyzed, 'DD-MON-RRRR')
                having  sum(dba_extents.bytes/1024/1024) > 10
              )
              order by SizeMB desc)
              where rownum <= 50)
  
   LOOP
    v_owner := rec.owner;
    v_segment_name := rec.segment_name;
    execute immediate v_execute using in v_owner,v_segment_name;
    END LOOP; 
END;
/

Upgrade to DB12c

This shows the minimum steps I took to upgrade an 11gR2 instance to 12c.

The full reference can be found under this blog entry - Mike Dietrich - he maintains 500 pages of guidelines and best practices to follow for your upgrade.

My database to migrate has 10GB.

1) Install new software in new oracle home
2) Purge recycle bin
3) Check for Invalid objects - recompile if you have invalid objects in SYS or SYSTEM using $ORACLE_HOME/rdbms/admin/utlrp.sql before running the upgrade.
4) Remove outdated parameters, underscores and events from init.ora
5) Necessary components
      a) XDB component is mandatory in DB12c
      b) Remove components which don't exists any more in DB12c
                i. EM DB Control Repository
                ii. OLAP AMD
6) Collect fresh stats
7) Parameter recommendations
      a) Deprecated in 12c
                i. SEC_CASE_SENSITIVE_LOGON=TRUE (this defaults to TRUE in 11g)
                ii. This must be aged out
      b) Obsolete in 12c
                i. _app_ctx_vers
                ii. _log_io_size

8) Put the db you want to upgrade in mount mode
9) Go to the new software location (12c) and invoke DBUA (Database Upgrade Assistant) from $ORACLE_HOME/bin/dbua

In step 1 we select the operation to perform.


In step 2 we select the source Oracle Home, and the SID that we plan the upgrade on



In step 2 we are prompted the validation and what action we need in order to comply.


As we have invalid object we fix this in a terminal and click on Check Again


In Oracle DB12c we can do the upgrade using parallelism. This is NEW feature in the upgrades to 12c! This can save up to 40% time.


We are prompted the option to configure EM Express. We can do this at a later time as well by setting the port.


In step 6 we have several options on moving the database files. Read carefully and act accordingly to your needs


We choose to migrate the Listener.

We are prompted to options to recover in case of problems. We choose RMAN as an option to recover.



In step 9 we are prompted with all the details of the Upgrade. This is logical and concise.


We are prompted with a progress of the steps. We can monitor this activity and also monitor the alert log.




The upgrade completes in approximately 2 hours. This was a 10GB database but it had enabled lots of options and this is also a factor which dictates the duration.


In the end we are prompted full details of the upgrade.



 That is all.

Thursday, September 26, 2013

Report changes with ENABLE_DDL_LOGGING=TRUE

The init.ora parameter ENABLE_DDL_LOGGING is licensed as part of the Database Lifecycle Management Pack when set to TRUE. 
When set to TRUE, the database reports schema changes in real time into the DDL alert log.

SQL> show con_id

CON_ID
------------------------------
1
SQL> show parameter enable_ddl_logging

NAME         TYPE  VALUE
------------------------------------ ----------- ------------------------------
enable_ddl_logging       boolean  FALSE
SQL> alter system set enable_ddl_logging=TRUE scope=memory;

System altered.
SQL> show parameter enable_ddl_logging;

NAME         TYPE  VALUE
------------------------------------ ----------- ------------------------------
enable_ddl_logging       boolean  TRUE

The alert log show the change as expected:

Thu Sep 26 15:39:47 2013
ALTER SYSTEM SET enable_ddl_logging=TRUE SCOPE=MEMORY;


SQL> alter session set container=pdb1;    

Session altered.

SQL> create user newuser identified by newuser;

User created.

SQL> grant connect, resource, create table, unlimited tablespace to newuser;

Grant succeeded.

SQL> create table newuser.table1 (col1 number(9));

Table created.

SQL> alter table newuser.table1 add col2 varchar2(10);

Table altered.

SQL> drop user newuser cascade;

User dropped.

SQL> create user abc identified by abc;

User created.

SQL> drop user abc cascade;

User dropped.


[oracle@magenta log]$ pwd
/u01/app/oracle/diag/rdbms/orcl12c/orcl12c/log
[oracle@magenta log]$ ll
total 16
drwxr-x---. 2 oracle oinstall 4096 Sep 26 15:46 ddl
-rw-r-----. 1 oracle oinstall  203 Sep 26 15:51 ddl_orcl12c.log
drwxr-x---. 2 oracle oinstall 4096 Jul 29 14:07 debug
drwxr-x---. 2 oracle oinstall 4096 Jul 29 14:07 test

[oracle@magenta log]$ tail -f ddl_orcl12c.log 
Thu Sep 26 15:46:13 2013
diag_adl:create table newuser.table1 (col1 number(9))
diag_adl:alter table newuser.table1 add col2 varchar2(10)
diag_adl:drop user newuser cascade
diag_adl:drop user abc cascade

When ENABLE_DDL_LOGGING is set to true, the following DDL statements are written to the DDL alert log:
ALTER/CREATE/DROP/TRUNCATE CLUSTER
ALTER/CREATE/DROP FUNCTION
ALTER/CREATE/DROP INDEX
ALTER/CREATE/DROP OUTLINE
ALTER/CREATE/DROP PACKAGE
ALTER/CREATE/DROP PACKAGE BODY
ALTER/CREATE/DROP PROCEDURE
ALTER/CREATE/DROP PROFILE
ALTER/CREATE/DROP SEQUENCE
CREATE/DROP SYNONYM
ALTER/CREATE/DROP/RENAME/TRUNCATE TABLE
ALTER/CREATE/DROP TRIGGER
ALTER/CREATE/DROP TYPE
ALTER/CREATE/DROP TYPE BODY
DROP USER
ALTER/CREATE/DROP VIEW


Thursday, September 5, 2013

DB12c - when THREADED_EXECUTION=TRUE native authentication is not supported


When threaded execution is enabled (threaded_execution=TRUE) in the initialization parameter file on UNIX platforms, native authentication (that is, connect / as sysdba or connect /) is not supported.

Workaround: Use password-based authentication. Native authentication will not work for connections where the server execution is a thread.

SQL> select banner from v$version where rownum<=1;

BANNER
--------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production

SQL> select platform_name from v$database;

PLATFORM_NAME
--------------------------------------------------------------------------------
Linux x86 64-bit

SQL> show parameter threaded_execution;

NAME                                                        TYPE VALUE
------------------------------------ ----------- ------------------------------
threaded_execution                           boolean          FALSE
SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
[oracle@xxxxx]$ sqlplus /nolog

SQL*Plus: Release 12.1.0.1.0 Production on Thu Sep 5 19:14:48 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

SQL> connect / as sysdba
Connected.
SQL> show user
USER is "SYS"
SQL> alter system set threaded_execution=TRUE scope=spfile;

System altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORA-01017: invalid username/password; logon denied
SQL> connect / as sysdba
ERROR:
ORA-01017: invalid username/password; logon denied


Warning: You are no longer connected to ORACLE.
SQL> exit
[oracle@xxxxx]$ sqlplus /nolog

SQL*Plus: Release 12.1.0.1.0 Production on Thu Sep 5 19:17:18 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

SQL> connect sys as sysdba
Enter password:
Connected.
SQL> alter database mount;

Database altered.

SQL> alter database open;

Database altered.

SQL> show user
USER is "SYS"
SQL> show parameter threaded_execution

NAME                                                        TYPE VALUE
------------------------------------ ----------- ------------------------------
threaded_execution                           boolean          TRUE


This is logged as Bug 13877504

Monday, September 2, 2013

Gather statistics of SYS objects

There are couple interesting notes on Metalink:
GATHER_FIXED_OBJECTS_STATS Considerations [ID 798257.1]
Also, Metalink note How to Gather Statistics on SYS Objects and ‘Fixed’ Objects? [ID 457926.1]
mentions that “statistics gathering should be done when database has a representative load so that the statistics reflect the normal database activity”

There are some fixed tables that are simply very volatile by nature and it will be extremely hard to get accurate statistics on.
Still, better with than without.

The place I would look is how much time is spent for recursive sql, which basically touches the dictionary tables.

So how often to gather??
It depends. It depends on the load profile, if you regularly add more users (concurrency) in your application,
then gathering system statistics shall be in accordance to that.

RMAN 12c: System trigger to open PDBs causing table recovery to fail with ORA-65019, RMAN-11003

In Oracle Database 12c, while trying to perform a table recovery, I hit the below error:

RMAN-11003: failure during parse/execution of SQL statement: alter pluggable database  PDB_RMAN open
ORA-65019: pluggable database PDB_RMAN already open

The command used was:

RECOVER TABLE TEST.TEST OF PLUGGABLE DATABASE PDB_RMAN UNTIL SCN 3106312 AUXILIARY DESTINATION '/u01/app/oracle/test';

I had all the pre-requisites validated:
The target database was in read-write mode.
The target database was in ARCHIVELOG mode.
RMAN full backup taken previously the drop command

For the information, I had created an empty pluggable database, created a table in it, performed full backup at CDB level.
I then dropped the table and tried to recover it.

I have previously created a system trigger to start all my pluggable database when CDB is open.

Full section of the error is the below:

contents of Memory Script:
{
sql clone 'alter pluggable database  PDB_RMAN open';
}
executing Memory Script

sql statement: alter pluggable database  PDB_RMAN open

Removing automatic instance
shutting down automatic instance
Oracle instance shut down
Automatic instance removed
auxiliary instance file /u01/app/oracle/test/JVGF_PITR_PDB_RMAN_CDB1/datafile/o1_mf_test_916xmk0w_.dbf deleted
auxiliary instance file /u01/app/oracle/test/CDB1/datafile/o1_mf_sysaux_916xkgf6_.dbf deleted
auxiliary instance file /u01/app/oracle/test/CDB1/datafile/o1_mf_system_916xkgh9_.dbf deleted
auxiliary instance file /u01/app/oracle/test/CDB1/datafile/o1_mf_sysaux_916xhq2h_.dbf deleted
auxiliary instance file /u01/app/oracle/test/CDB1/datafile/o1_mf_undotbs1_916xhq31_.dbf deleted
auxiliary instance file /u01/app/oracle/test/CDB1/datafile/o1_mf_system_916xhq2x_.dbf deleted
auxiliary instance file /u01/app/oracle/test/CDB1/controlfile/o1_mf_916xhgl9_.ctl deleted
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/20/2013 15:00:54
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of sql command on clone_default channel at 08/20/2013 15:00:54
RMAN-11003: failure during parse/execution of SQL statement: alter pluggable database  PDB_RMAN open
ORA-65019: pluggable database PDB_RMAN already open


In short, what happens during table recovery is the following:
- Oracle creates an automatic (auxiliary) instance
- restores the backup into it and performes a media recovery
- exports from the auxiliary instance using EXPDP the table you want to recover
- imports into your pluggable database using IMPDP


The issue appears when you have a system trigger at CDB level which opens all PDB or at least the pluggable database where you have the issue with
the table you want to recover.

The workaround is to create an auxiliary parameter file /tmp/initaux.ora with the following line in it:
_system_trig_enabled=FALSE

Then, while invoking RMAN, set this auxiliary instance parameter file before recovering the table

RMAN> set auxiliary instance parameter file to '/tmp/initaux.ora';
RMAN> recover table test.test....

The error will no longer appear and you will be able to complete the recovery of the table.

This is documented as the following bug:
Bug 16822622 : PDB TABLESPACE PITR FAILS WITH EXISTING TRIGGER OPENING PDBS