Oracle Database 11g: “DRIVING_SITE” hint will be ignored


For transactions with and without joins for database links 10.2.0.5+

  1. With 11g the hint “DRIVING SITE” will be ignored, generally
    • Bug 13851819 : 11G DATABASE IGNORES DRIVING_SITE HINT
    • –> Bug 13413837 : PREDICATE PUSHING AND VIEW MERGING NOT HAPPENING IN 11.2.0.2.0 TOGETHER.
  2. With 10.2.0.5++ there is a problem by generating plans of the remote query
    • Behavior in 10g: remote sql sends, as expected, a filter with remote index usage
    • Behavior in 11g: no filter –> remote full table scan

For both problems there is a patch:

  1. Bug 13057645 : PLAN OF A DISTRIBUTED QUERY IN 11G IS DIFFERENT FROM 10G
  2. Bug 11689699 : EXPLAIN PLAN CHANGED AFTER 10205 UPGRADE WITH CORRELATED SUB-QUERY OVER DB LINK

Both patches must be applied to get old behavior back.

ODA Patch 2.7.0.0.0 may be released soon


As announced in CPU Juli 2013 release document (Patch Set Update and Critical Patch Update July 2013 Availability Document (Doc ID 1548709.1)), Oracle Database Applicance Patch 2.7.0.0.0 or 2.7v will be released on 30th July 2013:

2.5 Post Release CPU and PSU Patches The following are post-release patches with their estimated release dates.

  • Oracle Database 11.2.0.3 SPU for IBM Linux on System Z: Available 18-July-2013
  • Oracle Database 11.1.0.7.16 PSU for HP-UX Itanium: Available 22-July-2013
  • Oracle Database 11.1.0.7.16 PSU for HP-UX PA-RISC: Available 23-July-2013
  • Oracle Database 11.1.0.7 SPU for HP-UX PA-RISC: 23-July-2013
  • Oracle Database 11.1.0.7 SPU for HP-UX Itanium: 23-July-2013
  • Oracle Database 10.2.0.5.12 PSU for HP-UX PA-RISC: 23-July-2013
  • Oracle Database 10.2.0.5.12 PSU for HP Tru64: 30-July-2013
  • Oracle Database 10.2.0.5.12 PSU for Linux Itanium: Available 19-July-2013
  • Oracle Database 10.2.0.5.12 PSU for Solaris x86-64: 30-July-2013
  • Oracle Database 10.2.0.5 BP4 for IBM z/OS on System z: Available 23-July-2013
  • Oracle Database 10.2.0.5 SPU for Solaris x86-64: 30-July-2013
  • Oracle Database Appliance 2.7.0.0.0: 30-July-2013

Fixed BUGs and security fixes:

Oracle Database Appliance 2.7.0.0.0:
CVE-2013-3751, CVE-2013-3758, CVE-2013-3760, CVE-2013-3771, CVE-2013-3774, CVE-2013-3789, CVE-2013-3790

Refer to

UPDATE: Oracle has released 2.7.0.0.0 see here

 

Oracle RAC with OCR mirrored by ASM pitfalls


Since 11gR2 OCR and Voting files can placed into ASM. Here an overview:

ASM Reduncancy Level  OCR Mirrors  Votingdisks  Failgroups  Min. count of disks
EXTERNAL 1 1 1 1
NORMAL 2 3 3 3
HIGH 3 5 5 5

The most common configuration of RAC is a 2 node RAC. For example Oracle database applicance.
If a RAC has one storage the will be no problem and ASM mirror is not nessecary, EXTERNAL redundancy can be used. If the RAC has two storages there is a problem with the Votingdisks. Therefore a third location will be needed. In most configurations two locations are expensive enough and a third location is not available.

Here a real situation:
Customer has two nodes and two storages. All files are mirrored on ASM with normal redundancy, also OCR diskgroup:
Site A: 2x voting, secondary RAC node
Site B: 1x voting, master RAC node

Suddenly site A will break down due to a site desaster. Some seconds later the RAC node on Site B will shutdown due to OCR errors.
Why does this happens:
ASM mirroring is done at block/extent level.

  • EXTERNAL mirroring does mean no mirror
  • NORMAL = extent will be located in one other failgroup
  • HIGH = extent will be located in two other failgroups

Build up on the count of disks needed and the mirror copies witch should be used?

  1. EXTERNAL = not usable for two storages
  2. NORMAL = 3 Disks with 3 voting disks and an OCR mirror
    therefore segmentation of disks is 2:1, but only 2 mirrored blocks of OCR maybe all OCR blocks are on Site A
  3. HIGH = 5 Disks with 5 voting disks and an HIGH OCR mirror
    therefore segmentation of disks is 3:2, but only 3 mirrored blocks of OCR maybe all OCR blocks are on Site A

So what can be done. The solution: NORMAL redundancy with HIGH redundancy OCR mirror. The following construct will be created:
Disk segmentation is 2:1 and 3 mirrored block of OCR. All blocks of the OCR will be mirrored on every Disk. Whatever witch Site on the disaster will happen, at least one OCR mirror copy will be available.

Here the demonstration on 12.1.0.1 GI:
1. Create Cluster with normal redundancy cluster diskgroup DG_CLUSTER
2. Check asm template of OCR asm diskgroup:

SQL> select * from v$asm_template where group_number=1;

GROUP_NUMBER ENTRY_NUMBER REDUND STRIPE S NAME                           PRIM MIRR     CON_ID
------------ ------------ ------ ------ - ------------------------------ ---- ---- ----------
           1          123 MIRROR COARSE Y VOTINGFILE                     COLD COLD          0
           1          343 MIRROR COARSE Y OCRFILE                        COLD COLD          0

3. Check mirror on OCR:

ASMCMD> ls -l +DG_CLUSTER/vmsvr-clu2/OCRFILE
Type     Redund  Striped  Time             Sys  Name
OCRFILE  MIRROR  COARSE   JUL 23 23:00:00  Y    REGISTRY.255.821572803

4. Check ASM extent distribution

SQL>select g.name
2          ,d.path
3          ,e.XNUM_KFFXP extent
4          ,decode(e.lxn_kffxp,0,'primary',1,'mirror-normal','mirror-high') mirrormeta
5  from x$kffxp        e
6        ,v$asm_alias  a
7        ,v$asm_disk   d
8        ,v$asm_diskgroup  g
9  where e.number_kffxp=a.file_number
10       and e.disk_kffxp=d.disk_number
11       and d.group_number = g.group_number
12       and a.name='REGISTRY.255.821572803'
13*      order by 3,4 desc

NAME                         PATH                               EXTENT MIRRORMETA
---------------------------------------------------------------------- -------------
DG_CLUSTER                   ORCL:ORA_DISK_2                         0 primary
DG_CLUSTER                   ORCL:ORA_DISK_1                         0 mirror-normal
DG_CLUSTER                   ORCL:ORA_DISK_3                         1 primary
DG_CLUSTER                   ORCL:ORA_DISK_1                         1 mirror-normal
DG_CLUSTER                   ORCL:ORA_DISK_1                         2 primary
DG_CLUSTER                   ORCL:ORA_DISK_3                         2 mirror-normal
DG_CLUSTER                   ORCL:ORA_DISK_2                         3 primary
DG_CLUSTER                   ORCL:ORA_DISK_3                         3 mirror-normal
DG_CLUSTER                   ORCL:ORA_DISK_3                         4 primary
DG_CLUSTER                   ORCL:ORA_DISK_2                         4 mirror-normal
DG_CLUSTER                   ORCL:ORA_DISK_1                         5 primary
DG_CLUSTER                   ORCL:ORA_DISK_2                         5 mirror-normal
DG_CLUSTER                   ORCL:ORA_DISK_2                         6 primary
DG_CLUSTER                   ORCL:ORA_DISK_1                         6 mirror-normal
DG_CLUSTER                   ORCL:ORA_DISK_3                         7 primary
DG_CLUSTER                   ORCL:ORA_DISK_1                         7 mirror-normal
DG_CLUSTER                   ORCL:ORA_DISK_1                         8 primary
DG_CLUSTER                   ORCL:ORA_DISK_3                         8 mirror-normal
DG_CLUSTER                   ORCL:ORA_DISK_2                         9 primary
DG_CLUSTER                   ORCL:ORA_DISK_3                         9 mirror-normal
DG_CLUSTER                   ORCL:ORA_DISK_3                        10 primary
DG_CLUSTER                   ORCL:ORA_DISK_2                        10 mirror-normal
...

As you can see the diskgroup is made up of 3 disks (ORA_DISK_1 – 3). Further there are only two mirrors of each extent.

5. Backup OCR

[root ~]# ocrconfig -manualbackup
vmsvredu3     2013/07/24 23:51:17     /opt/oracle/12.1/grid/cdata/vmsvr-clu2/backup_20130724_235117.ocr
vmsvredu3     2013/07/23 22:52:10     /opt/oracle/12.1/grid/cdata/vmsvr-clu2/backup_20130723_225210.ocr
vmsvredu3     2013/07/23 22:45:11     /opt/oracle/12.1/grid/cdata/vmsvr-clu2/backup_20130723_224511.ocr

6. To correct this problem if don’t have an OCR mirror, stop cluster and start one node exclusiv and without crsd

crsctl start crs -excl -nocrs

7. Change asm template

SQL> alter diskgroup dg_cluster modify template OCRFILE attributes (HIGH);

Diskgroup altered.

SQL> select * from v$asm_template where group_number=1;

GROUP_NUMBER ENTRY_NUMBER REDUND STRIPE S NAME                           PRIM MIRR     CON_ID
------------ ------------ ------ ------ - ------------------------------ ---- ---- ----------
           1          120 MIRROR COARSE Y PARAMETERFILE                  COLD COLD          0
           1          121 MIRROR COARSE Y ASMPARAMETERFILE               COLD COLD          0
           1          123 MIRROR COARSE Y VOTINGFILE                     COLD COLD          0
           1          124 MIRROR COARSE Y DUMPSET                        COLD COLD          0
           1          125 HIGH   FINE   Y CONTROLFILE                    COLD COLD          0
           1          126 MIRROR COARSE Y FLASHFILE                      COLD COLD          0
           1          127 MIRROR COARSE Y ARCHIVELOG                     COLD COLD          0
           1          128 MIRROR COARSE Y ONLINELOG                      COLD COLD          0
           1          129 MIRROR COARSE Y DATAFILE                       COLD COLD          0
           1          230 MIRROR COARSE Y TEMPFILE                       COLD COLD          0
           1          231 MIRROR COARSE Y BACKUPSET                      COLD COLD          0
           1          232 MIRROR COARSE Y XTRANSPORT BACKUPSET           COLD COLD          0
           1          233 MIRROR COARSE Y INCR XTRANSPORT BACKUPSET      COLD COLD          0
           1          234 MIRROR COARSE Y AUTOBACKUP                     COLD COLD          0
           1          235 MIRROR COARSE Y XTRANSPORT                     COLD COLD          0
           1          237 MIRROR COARSE Y CHANGETRACKING                 COLD COLD          0
           1          238 MIRROR COARSE Y FLASHBACK                      COLD COLD          0
           1          239 MIRROR COARSE Y KEY_STORE                      COLD COLD          0
           1          340 MIRROR COARSE Y AUTOLOGIN_KEY_STORE            COLD COLD          0
           1          341 MIRROR COARSE Y AUDIT_SPILLFILES               COLD COLD          0
           1          342 MIRROR COARSE Y DATAGUARDCONFIG                COLD COLD          0
           1          343 HIGH   COARSE Y OCRFILE                        COLD COLD          0

22 rows selected.

SQL>

8. Remove old OCR

ASMCMD> ls -l
Type     Redund  Striped  Time             Sys  Name
OCRFILE  MIRROR  COARSE   JUL 24 10:00:00  Y    REGISTRY.255.821572803
ASMCMD> rm -f REGISTRY.255.821572803

9. Restore OCR

[root ~]# ocrconfig -restore /opt/oracle/12.1/grid/cdata/vmsvr-clu2/backup_20130724_235117.ocr

10. Check new OCR

ASMCMD> ls -l
Type     Redund  Striped  Time             Sys  Name
OCRFILE  HIGH    COARSE   JUL 24 10:00:00  Y    REGISTRY.255.821615711
ASMCMD>

11. Check crsd starts

[oracle ~]$ crsctl start res ora.crsd -init
CRS-2672: Attempting to start 'ora.crf' on 'vmsvredu3'
CRS-2672: Attempting to start 'ora.storage' on 'vmsvredu3'
CRS-2676: Start of 'ora.storage' on 'vmsvredu3' succeeded
CRS-2676: Start of 'ora.crf' on 'vmsvredu3' succeeded
CRS-2672: Attempting to start 'ora.crsd' on 'vmsvredu3'
CRS-2676: Start of 'ora.crsd' on 'vmsvredu3' succeeded

12. Restart cluster normal

[root ~]# crsctl stop crs -f
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'vmsvredu3'
CRS-2673: Attempting to stop 'ora.crsd' on 'vmsvredu3'
CRS-2677: Stop of 'ora.crsd' on 'vmsvredu3' succeeded
CRS-2673: Attempting to stop 'ora.ctssd' on 'vmsvredu3'
CRS-2673: Attempting to stop 'ora.evmd' on 'vmsvredu3'
CRS-2673: Attempting to stop 'ora.storage' on 'vmsvredu3'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'vmsvredu3'
CRS-2673: Attempting to stop 'ora.gpnpd' on 'vmsvredu3'
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'vmsvredu3'
CRS-2677: Stop of 'ora.storage' on 'vmsvredu3' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'vmsvredu3'
CRS-2677: Stop of 'ora.drivers.acfs' on 'vmsvredu3' succeeded
CRS-2677: Stop of 'ora.gpnpd' on 'vmsvredu3' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'vmsvredu3' succeeded
CRS-2677: Stop of 'ora.evmd' on 'vmsvredu3' succeeded
CRS-2677: Stop of 'ora.asm' on 'vmsvredu3' succeeded
CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'vmsvredu3'
CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'vmsvredu3' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'vmsvredu3' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'vmsvredu3'
CRS-2677: Stop of 'ora.cssd' on 'vmsvredu3' succeeded
CRS-2673: Attempting to stop 'ora.crf' on 'vmsvredu3'
CRS-2677: Stop of 'ora.crf' on 'vmsvredu3' succeeded
CRS-2673: Attempting to stop 'ora.gipcd' on 'vmsvredu3'
CRS-2677: Stop of 'ora.gipcd' on 'vmsvredu3' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'vmsvredu3' has completed
CRS-4133: Oracle High Availability Services has been stopped.

[root@vmsvredu3 ~]# crsctl start crs
CRS-4123: Oracle High Availability Services has been started.
[root ~]#

13. Check ASM mirroring again:

SQL> select g.name
  2          ,d.path
  3          ,e.XNUM_KFFXP extent
  4          ,decode(e.lxn_kffxp,0,'primary',1,'mirror-normal','mirror-high') mirrormeta
  5  from x$kffxp        e
  6        ,v$asm_alias  a
  7        ,v$asm_disk   d
  8        ,v$asm_diskgroup  g
  9  where e.number_kffxp=a.file_number
 10        and e.disk_kffxp=d.disk_number
 11        and d.group_number = g.group_number
 12        and a.name='REGISTRY.255.821615711'
 13        order by 3,4 desc
 14  ;

NAME                           PATH                               EXTENT MIRRORMETA
------------------------------ ------------------------------ ---------- -------------
DG_CLUSTER                     ORCL:ORA_DISK_1                         0 primary
DG_CLUSTER                     ORCL:ORA_DISK_3                         0 mirror-normal
DG_CLUSTER                     ORCL:ORA_DISK_2                         0 mirror-high
DG_CLUSTER                     ORCL:ORA_DISK_2                         1 primary
DG_CLUSTER                     ORCL:ORA_DISK_3                         1 mirror-normal
DG_CLUSTER                     ORCL:ORA_DISK_1                         1 mirror-high
DG_CLUSTER                     ORCL:ORA_DISK_3                         2 primary
DG_CLUSTER                     ORCL:ORA_DISK_1                         2 mirror-normal
DG_CLUSTER                     ORCL:ORA_DISK_2                         2 mirror-high
DG_CLUSTER                     ORCL:ORA_DISK_1                         3 primary
DG_CLUSTER                     ORCL:ORA_DISK_3                         3 mirror-normal
DG_CLUSTER                     ORCL:ORA_DISK_2                         3 mirror-high
DG_CLUSTER                     ORCL:ORA_DISK_2                         4 primary
DG_CLUSTER                     ORCL:ORA_DISK_3                         4 mirror-normal
DG_CLUSTER                     ORCL:ORA_DISK_1                         4 mirror-high
DG_CLUSTER                     ORCL:ORA_DISK_3                         5 primary
DG_CLUSTER                     ORCL:ORA_DISK_1                         5 mirror-normal
DG_CLUSTER                     ORCL:ORA_DISK_2                         5 mirror-high
DG_CLUSTER                     ORCL:ORA_DISK_1                         6 primary
DG_CLUSTER                     ORCL:ORA_DISK_3                         6 mirror-normal
DG_CLUSTER                     ORCL:ORA_DISK_2                         6 mirror-high
...

All done. Now a disaster can come.

References:

Database 12c: Common and local users and roles


Since 12c “nothing” is like before. Today we are talking about the user creation. The user beavior in a Non-CDB is like in 11g and before. In CDBs and PDBs the concept slightly changes. In a multitenant database users will be divided into two different types: Local and common users:

commonuser

Common users

A common user is user which is present in the CDB and all PDBs. Here from documentation:

“A common user is a database user that has the same identity in the root and in every existing and future PDB. Every common user can connect to and perform operations within the root, and within any PDB in which it has privileges.”

Special users are sys and system. Common users have the same characteristic in all instances (e.g. password, tablespace and so on)

Create a new common user:

SQL> alter session set container=CDB$ROOT;

Session altered.

SQL> create user C##TEST1 identified by test1 container = all;

User created.

Common users must start with c## or C##

SQL> create user TEST1 identified by bubu1 container=all;
create user TEST1 identified by bubu1 container=all
            *
ERROR at line 1:
ORA-65096: invalid common user or role name

Changes to common users apply to all container:

SQL> create user C##TEST1 identified by test1 container = all default tablespace users;
create user C##TEST1 identified by test1 container = all default tablespace users
*
ERROR at line 1:
ORA-65048: error encountered when processing the current DDL statement in pluggable database PDB1
ORA-00959: tablespace 'USERS' does not exist

The password is the same in CDB and all PDBs, when trying to change you get an error:

QL> alter user C##TEST1 identified by bubu1;
alter user C##TEST1 identified by bubu1
*
ERROR at line 1:
ORA-65066: The specified changes must apply to all containers

Changes to common users are only allowed in CDB

SQL> alter user C##TEST1 identified by bubu1 container=all;
alter user C##TEST1 identified by bubu1 container=all
*
ERROR at line 1:
ORA-65050: Common DDLs only allowed in CDB$ROOT

Local users

Local users are users which are only exsits in a PDB but not in all containers.

Create local users:

SQL> create user TEST1 identified by bubu1;

User created.

SQL> create user TEST2 identified by bubu1 container=current;

User created.

SQL> 

In CDBs no local users can be created:

SQL> create user TEST1 identified by bubu1 container=current;
create user TEST1 identified by bubu1 container=current
                                *
ERROR at line 1:
ORA-65049: creation of local user or role is not allowed in CDB$ROOT

The username for a local user must not start with c## or C##

SQL> create user C##TEST1 identified by bubu1;
create user C##TEST1 identified by bubu1
            *
ERROR at line 1:
ORA-65094: invalid local user or role name

SQL> create user C##TEST1 identified by bubu1 container=current;
create user C##TEST1 identified by bubu1 container=current
            *
ERROR at line 1:
ORA-65094: invalid local user or role name

Common roles

Common roles are like common users roles which are present in CDB and all PDBs. Important is that the privileges are granted at CDB or PDB level, but not over all containers, per default.

SQL> create role C##ROLE1 container=all;

Role created.

SQL> grant create session to C##ROLE1;

Grant succeeded.

SQL> select grantee,privilege,common from dba_sys_privs where grantee='C##ROLE1';
GRANTEE                        PRIVILEGE                      COMMON
------------------------------ ------------------------------ ------------------------------
C##ROLE1                       CREATE SESSION                 NO

SQL> alter session set container=PDB1;

Session altered.

SQL> select grantee,privilege,common from dba_sys_privs where grantee='C##ROLE1';

no rows selected

SQL> 

To grant privileges over all containers:

SQL> alter session set container=CDB$ROOT;

Session altered.

SQL> grant create table to C##ROLE1 container=all;

Grant succeeded.

SQL> select grantee,privilege,common from dba_sys_privs where grantee='C##ROLE1';

GRANTEE                        PRIVILEGE                      COMMON
------------------------------ ------------------------------ ------------------------------
C##ROLE1                       CREATE SESSION                 NO
C##ROLE1                       CREATE TABLE                   YES

SQL> alter session set container=PDB1;

Session altered.

SQL> select grantee,privilege,common from dba_sys_privs where grantee='C##ROLE1';

GRANTEE                        PRIVILEGE                      COMMON
------------------------------ ------------------------------ ------------------------------
C##ROLE1                       CREATE TABLE                   YES

SQL> 

Privileges granted in a pdb will only available in a pdb:

SQL> alter session set container=PDB1;

Session altered.

SQL> select grantee,privilege,common from dba_sys_privs where grantee='C##ROLE1';

GRANTEE                        PRIVILEGE                      COMMON
------------------------------ ------------------------------ ------------------------------
C##ROLE1                       CREATE TABLE                   YES

SQL> grant create view to C##ROLE1;

Grant succeeded.

SQL> select grantee,privilege,common from dba_sys_privs where grantee='C##ROLE1';

GRANTEE                        PRIVILEGE                      COMMON
------------------------------ ------------------------------ ------------------------------
C##ROLE1                       CREATE VIEW                    NO
C##ROLE1                       CREATE TABLE                   YES

SQL> alter session set container=CDB$ROOT;

Session altered.

SQL> select grantee,privilege,common from dba_sys_privs where grantee='C##ROLE1';

GRANTEE                        PRIVILEGE                      COMMON
------------------------------ ------------------------------ ------------------------------
C##ROLE1                       CREATE SESSION                 NO
C##ROLE1                       CREATE TABLE                   YES

SQL> 

Database 12c: RBO (Rule Based Optimizer) is not death


Starting with Oracle Database 10g Release 1 (10.1), the cost-based optimizer (CBO) is now enabled by default. The rule-based optimizer is no longer supported in Oracle Database 10g Release 1 (10.1). As a result, rule and choose are no longer supported as OPTIMIZER_MODE initialization parameter values and a warning is displayed in the alert log if OPTIMIZER_MODE is set to either of these values.

  • Oracle has announced to remove RBO in 11.1 and hasn’t done.
  • Oracle has announced to remove RBO in 11.2 and hasn’t done.
  • Oracle has announced to remove RBO in 12.1 and hasn’t done.

Here the test:

1. Create environment

SQL> conn dhafner/<pwd>
Connected.
SQL> create table tab1 (id number,text varchar2(32767));

Table created.

SQL> desc tab1
Name                                      Null?    Type
----------------------------------------- -------- ----------------------------
ID                                                 NUMBER
TEXT                                               VARCHAR2(32767)

SQL>

SQL> insert into dhafner.tab1 (select object_id,object_name from dba_objects);

90739 rows created.

SQL> commit;

Commit complete.

SQL> conn dhafner/dhafner
Connected.
SQL> create index tab1_idx on tab1(id);

Index created.

2. Test with CBO without statistics

SQL> explain plan for select text from tab1 where id=1000;

Explained.

SQL> select * from table(dbms_xplan.display());

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2211052296

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 | 16398 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TAB1 |     1 | 16398 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------

1 - filter("ID"=1000 AND INTERNAL_FUNCTION("TEXT"))

13 rows selected.

3. Change to RULE

SQL> alter session set optimizer_mode=rule;

Session altered.

SQL> explain plan for select text from tab1 where id=1000;

Explained.

SQL> select * from table(dbms_xplan.display());

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 926492477

------------------------------------------------
| Id  | Operation                   | Name     |
------------------------------------------------
|   0 | SELECT STATEMENT            |          |
|*  1 |  TABLE ACCESS BY INDEX ROWID| TAB1     |
|*  2 |   INDEX RANGE SCAN          | TAB1_IDX |
------------------------------------------------

Predicate Information (identified by operation id):

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------

1 - filter(INTERNAL_FUNCTION("TEXT"))
2 - access("ID"=1000)

Note
-----
- rule based optimizer used (consider using cbo)

19 rows selected.

4. To show the effect test it now with CBO and statistics

SQL> exec dbms_stats.gather_table_stats('DHAFNER','TAB1',cascade=>true);

PL/SQL procedure successfully completed.

SQL> alter session set optimizer_mode=all_rows;

Session altered.

SQL> select * from table(dbms_xplan.display())

PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------
Plan hash value: 358219344

------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |          |     1 |    30 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB1     |     1 |    30 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN                  | TAB1_IDX |     1 |       |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter(INTERNAL_FUNCTION("TEXT"))
2 - access("ID"=1000)

15 rows selected.

Database 12c: Extended Datatypes


Starting with 12c Extended Datatypes has been introduced. I’m going to show how to use the new feature. If you have installed default 12.1.0.1 database you will get the following error when trying to create a table with varchar2 greater 4000 bytes:

SQL> create table tab1 (id number,text varchar2(32767 byte));
create table tab1 (id number,text varchar2(32767 byte))
                                           *
ERROR at line 1:
ORA-00910: specified length too long for its datatype

There is a new parameter called “MAX_STRING_SIZE”. Here the parameter and values:

  • 32767 bytes or characters if MAX_STRING_SIZE = EXTENDED
  • 4000 bytes or characters if MAX_STRING_SIZE = STANDARD

The parameter cannot be changed at session level…

SQL> alter session set max_string_size=EXTENDED;
alter session set max_string_size=EXTENDED
*
ERROR at line 1:
ORA-02096: specified initialization parameter is not modifiable with this option

If you try to change a system level:

SQL> alter system set max_string_size=EXTENDED scope=both;
alter system set max_string_size=EXTENDED scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-14694: database must in UPGRADE mode to begin MAX_STRING_SIZE migration

OK enough for testing. Here the steps to change this parameter:

0. Requirements

To activate the feature the parameter COMPATIBLE must at least 12.0.0.0.

1. change parameter

SQL>  alter system set max_string_size=EXTENDED scope=spfile;

System altered.

SQL>

2. shutdown immediate

[bash]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Jul 22 21:53:59 2013

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

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>

3. startup upgrade

SQL> startup upgrade
ORACLE instance started.

Total System Global Area 2488635392 bytes
Fixed Size                  2291424 bytes
Variable Size             671090976 bytes
Database Buffers         1795162112 bytes
Redo Buffers               20090880 bytes
Database mounted.
Database opened.

5. run script utl32k.sql

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

Session altered.

DOC>#######################################################################
DOC>#######################################################################
DOC>   The following statement will cause an "ORA-01722: invalid number"
DOC>   error if the database has not been opened for UPGRADE.
DOC>
DOC>   Perform a "SHUTDOWN ABORT"  and
DOC>   restart using UPGRADE.
DOC>#######################################################################
DOC>#######################################################################
DOC>#

no rows selected

DOC>#######################################################################
DOC>#######################################################################
DOC>   The following statement will cause an "ORA-01722: invalid number"
DOC>   error if the database does not have compatible >= 12.0.0
DOC>
DOC>   Set compatible >= 12.0.0 and retry.
DOC>#######################################################################
DOC>#######################################################################
DOC>#

PL/SQL procedure successfully completed.

Session altered.

0 rows updated.

Commit complete.

System altered.

PL/SQL procedure successfully completed.

Commit complete.

System altered.

Session altered.

PL/SQL procedure successfully completed.

No errors.

Session altered.

PL/SQL procedure successfully completed.

Commit complete.

Package altered.

TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN  2013-07-22 21:43:09

DOC>   The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC>   objects in the database. Recompilation time is proportional to the
DOC>   number of invalid objects in the database, so this command may take
DOC>   a long time to execute on a database with a large number of invalid
DOC>   objects.
DOC>
DOC>   Use the following queries to track recompilation progress:
DOC>
DOC>   1. Query returning the number of invalid objects remaining. This
DOC>      number should decrease with time.
DOC>         SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC>   2. Query returning the number of objects compiled so far. This number
DOC>      should increase with time.
DOC>         SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC>   This script automatically chooses serial or parallel recompilation
DOC>   based on the number of CPUs available (parameter cpu_count) multiplied
DOC>   by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC>   On RAC, this number is added across all RAC nodes.
DOC>
DOC>   UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC>   recompilation. Jobs are created without instance affinity so that they
DOC>   can migrate across RAC nodes. Use the following queries to verify
DOC>   whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC>   1. Query showing jobs created by UTL_RECOMP
DOC>         SELECT job_name FROM dba_scheduler_jobs
DOC>            WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>
DOC>   2. Query showing UTL_RECOMP jobs that are running
DOC>         SELECT job_name FROM dba_scheduler_running_jobs
DOC>            WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>#

PL/SQL procedure successfully completed.

TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_END  2013-07-22 21:43:11

DOC> The following query reports the number of objects that have compiled
DOC> with errors.
DOC>
DOC> If the number is higher than expected, please examine the error
DOC> messages reported with each object (using SHOW ERRORS) to see if they
DOC> point to system misconfiguration or resource constraints that must be
DOC> fixed before attempting to recompile these objects.
DOC>#

OBJECTS WITH ERRORS
-------------------
                  0

DOC> The following query reports the number of errors caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC>#

ERRORS DURING RECOMPILATION
---------------------------
                          0

Function created.

PL/SQL procedure successfully completed.

Function dropped.

...Database user "SYS", database schema "APEX_040200", user# "98" 21:43:19
...Compiled 0 out of 2998 objects considered, 0 failed compilation 21:43:20
...263 packages
...255 package bodies
...453 tables
...11 functions
...16 procedures
...3 sequences
...458 triggers
...1322 indexes
...207 views
...0 libraries
...6 types
...0 type bodies
...0 operators
...0 index types
...Begin key object existence check 21:43:20
...Completed key object existence check 21:43:20
...Setting DBMS Registry 21:43:20
...Setting DBMS Registry Complete 21:43:20
...Exiting validate 21:43:20

PL/SQL procedure successfully completed.

SQL>

This script is mandatory, else you will get the following error:

SQL> startup
ORACLE instance started.

Total System Global Area 2488635392 bytes
Fixed Size                  2291424 bytes
Variable Size             671090976 bytes
Database Buffers         1795162112 bytes
Redo Buffers               20090880 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-14695: MAX_STRING_SIZE migration is incomplete
Process ID: 6324
Session ID: 355 Serial number: 5

NOTE:
The utl32k.sql script increases the maximum size of the VARCHAR2, NVARCHAR2, and RAW columns
for the views where this is required. The script does not increase the maximum size of the
VARCHAR2, NVARCHAR2, and RAW columns in some views because of the way the SQL for those views is written.

5. startup normal

SQL> startup
ORACLE instance started.

Total System Global Area 2488635392 bytes
Fixed Size                  2291424 bytes
Variable Size             671090976 bytes
Database Buffers         1795162112 bytes
Redo Buffers               20090880 bytes
Database mounted.
Database opened.
SQL> show parameter max_string_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
max_string_size                      string      EXTENDED
SQL>

NOW: test it

SQL> conn hr/hr
Connected.
SQL> create table tab1 (id number,text varchar2(32767));

Table created.

SQL> desc tab1
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 ID                                                 NUMBER
 TEXT                                               VARCHAR2(32767)

SQL>

Changing MAX_STRING_SIZE in PDBs

  1. Shut down the PDB.
  2. Restart the PDB in UPGRADE mode.
  3. Change the setting of MAX_STRING_SIZE in the PDB to EXTENDED.
  4. Run the @?/rdbms/admin/utl32k.sql script in the PDB. You must be connected AS SYSDBA to run the utl32k.sql script.
  5. Restart the PDB in NORMAL mode.

Changing MAX_STRING_SIZE in RAC

  1. Shut down all of the Oracle RAC database instances, except one.
  2. Restart the Oracle RAC database instance in UPGRADE mode.
  3. Change the setting of MAX_STRING_SIZE to EXTENDED.
  4. Run the @?/rdbms/admin/utl32k.sql script in the Oracle RAC database instance. You must be connected AS SYSDBA to run the script.
  5. Restart the Oracle RAC database instance in NORMAL mode.
  6. Restart the other Oracle RAC database instances in NORMAL mode.

Changing MAX_STRING_SIZE in DG Environment

  1. Shut down the Oracle Data Guard primary database and logical standby database.
  2. Restart the primary database and logical standby database in UPGRADE mode.
  3. Change the setting of MAX_STRING_SIZE to EXTENDED on the primary database and logical standby database.
  4. Run the @?rdbms/admin/utl32k.sql script on both the primary database and the logical standby database. You must be connected AS SYSDBA to run the script.
  5. Restart the primary database and logical standby database in NORMAL mode and start SQL Apply.

Bug 15845247

If you change the MAX_STRING_SIZE initialization parameter while creating a database using DBCA with a template that includes data files, the database creation fails with the following error:
ORA-14694: database must in UPGRADE mode to begin MAX_STRING_SIZE migration

Workaround: Leave the MAX_STRING_SIZE initialization parameter set to the default (STANDARD) or whatever it was set to in the template during DBCA. If you need to create a database with MAX_STRING_SIZE=EXTENDED, use the custom database template in DBCA.In a multitenant container database (CDB), the MAX_STRING_SIZE initialization parameter is a per-PDB parameter. The root CDB always uses STANDARD semantics, regardless of the parameter. You can change the MAX_STRING_SIZE initialization parameter for PDBs as needed after the CDB is created.