ZDLRA

I wanted to write a post on one of Oracle's newest products (Well not that new).. The ZDLRA.
The ZDLRA is often referred to as "Zelda".  I know the name ZDLRA does not roll off the tongue well.  Zelda is a much better (and easier to say name).
The other name you will hear the ZDLRA referred to as is RA or Recover Appliance.

Recover Appliance is probably the best description of the product.  One of the things that makes this product unique is the emphasis on RECOVERY.. Notice there is not a mention of backup in the name.


Here is a great starting point for information


It does a lot of it's magic by using incremental forevers   --

    I know what you are thinking... The incremental forever strategy has been around for a long time (since 10.2 I think).  The idea is simple.  You take a full backup (database copy NOT backup set), and then take incrementals from then on.  You use RMAN to apply the incremental to the full, and create a new full (destroying the old full in the process).  I've seen many customers (and me also) use the rolling incrementals in the online recovery area to keep a full backup online from the previous day.
This is used with a second backup strategy for longer term storage to a backup device.

  The way the RA handles this differently, is that it creates "virtual fulls" for each incremental backup you take.  You also tell it how far back to store virtual fulls.  Using this methodology, if you do an incremental backup nightly, you can keep "virtual fulls" from each night as far back as you want.
There is no need to keep an online backup, and one in backup appliance.

Why is the RA different from most backup strategies ?

1) The use of only needing to do incremental forevers uses less I/O to read database blocks, and less backup network I/O -  Using this method, the RA ONLY needs the incremental backups to keep a restore point.  This saves the I/O of doing a full, and it saves the bytes going across the network.

2) RMAN keeps track of all the backups.  RMAN is the backbone of the RA, and the RA contains a recovery catalog.  RMAN verifies that backups are good, and you will always know if you have a good backup to restore.

3) Real time apply.  You can think of the RA receiving redo log information in the same vein as a Dataguard database.  Without the RA, you would backup archive logs as they are written from the redo logs.  This leaves you open to data loss from your backup.. The RA reads from the current Redo log stream in the database (like dataguard) to ensure there there is almost no data loss. Nothing else does this.

4) Performance.  The performance the RA is phenomenal.  You can find a whitepaper here on the performance with multiple databases backing up to a single RA appliance.

This is a fantastic product to backup multiple databases and most importantly be able to recover your databases with next-to-no data loss.

M7 is Here

Yes, I know I am more of a sofware geek, than a hardware geek, but I spent the day listening to all the goodness of the new Sparc M7 chip.. and Wow..

This was announced at OOW '15, and you can find a lot of the information here.

I think what excited me wasn't just the benchmarks that you can find here, ir was the idea of Software-on-Silicon.

That's the big story for software geeks.. The idea of the DAX...

I know DAX sounds like something out of Dr. Seuss.

The DAX (Database Analytics Accelerator) is a special section of the new processor dedicated to In-Memory processes.

If you have read through Maria Colgans blog (which you should) you learn about how In-memory takes advantage of the SIMD instruction set available on the intel Chip.. The SIMD instructions are able to scan multiple rows of data in one CPU cycle.  That's part of what makes the In-Memory option process data so fast.

What does this have to do the M7 ?  The DAX replaces the SIMD instructions when you are running in-memory queries on the M7.  The DAX is specifically built to run this instruction set and the results are then fed to the CPU.  




What does this mean for you ? It means that the DAX is able to not only process the data faster than the SIMD processing on Intel, but it also does not use any of the CPU power to execute the In-Memory scanning.  You get faster performance, and you use less CPU.
That's the point of the DAX, and the Software-on-Silicon.  Faster performance with silicon that is built specially for an oracle workload (In-Memory in this case).

12.1.0.2 New Features PDB CONTAINERS Clause

When 12.1.0.2 came out, one of the features I wanted to play was the Cross-container functionality, and I finally had time to play with it.

First here is the description of the feature.

The CONTAINERS clause is a new way of looking at multitenant container databases (CDBs). With this clause, data can be aggregated from a single identical table or view across many pluggable databases (PDBs) from the root container. The CONTAINERS clause accepts a table or view name as an input parameter that is expected to exist in all PDBs in that container. Data from a single PDB or a set of PDBs can be included with the use of CON_ID in the WHERE clause. 

I decided to play with this and see what it really means.... And mostly to see the explain plan to see what happens under the covers.

Step 1 --   The first thing you need to do is create a "common user".  A common user is a new term that comes with Pluggable databases.  A common user is a user which is created in the CDB (the Root container), and is then available as a user in all the PDB's that are part of the CDB.  There are some rules around this.

• In Oracle Database 12c Release 1 (12.1.0.1), the name of a common user must begin with C## or c## and the name of a local user must not begin with C## or c##.
• Starting with Oracle Database 12c Release 1 (12.1.0.2):
• The name of a common user must begin with characters that are a case-insensitive match to the prefix specified by the COMMON_USER_PREFIX initialization parameter. By default, the prefix is C##.
• The name of a local user must not begin with characters that are a case-insensitive match to the prefix specified by the COMMON_USER_PREFIX initialization parameter. Regardless of the value of COMMON_USER_PREFIX, the name of a local user can never begin with C## or c##.

 So here goes for step 1 ..

$ sqlplus "/ as sysdba"

SQL*Plus: Release 12.1.0.2.0 Production on Thu Aug 7 22:23:26 2014

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


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

SQL create user c##bgrenn identified by bgrenn;
grant dba to c##bgrenn;

User created.

SQL 
Grant succeeded.

One thing to mention at this point is that I granted DBA role to my new common user c##bgrenn.  You also need to set individual privileges at each PDB level

Step 2 --   Now that I have a common user (c##bgrenn), I now need to go into my pdb's and create the objects that I want to have shared across PDB's. 

For simplicity, I chose DBA_TABLES, and DBA_OBJECTS.

The 3  PDBS I want to create this in are "orclpdb", "orclpdba" and "orcldbb"

SQL> COLUMN NAME FORMAT A15
COLUMN RESTRICTED FORMAT A10
COLUMN OPEN_TIME FORMAT A30
 
SELECT NAME, OPEN_MODE, con_id  FROM V$PDBS
SQL /

NAME   OPEN_MODE      CON_ID
--------------- ---------- ----------
PDB$SEED  READ ONLY     2
ORCLPDB  READ WRITE     3
ORCLPDBA  READ WRITE     4
ORCLPDBB READ WRITE     5

I then went into all 3 PDB's and created a local copy of DBA_OBJECTS and DBA_TABLES.

connect sys/oracle@localhost:1521/orclpdb as sysdba

grant dba to c##bgrenn;

create table c##bgrenn.local_objects as select * from dba_objects;

create table c##bgrenn.local_tables as select * from dba_tables; 

Connected.
SQL

Grant succeeded.

SQL 

Table created.

SQL 

 Table created.

SQL

Step 3 - Now that the same objects are created with data in all 3 PDB's, I can now do a combined query from the root PDB.  The next step is create a table in the CDB (root PDB) that is empty.

create table c##bgrenn.local_objects as select * from dba_objects where 1=0;

create table c##bgrenn.local_tables as select * from dba_tables where 1=0;

Table created.

Table created.

Then finally query and see the rows in the local_objects tables across all the PDB's

select count(*) from containers(c##bgrenn.local_objects) where con_id in (3) ;
  COUNT(*)
----------
     90925
select count(*) from containers(c##bgrenn.local_objects) where con_id in (4) ;
  COUNT(*)
----------
     90923
select count(*) from containers(c##bgrenn.local_objects) where con_id in (5) ;
  COUNT(*)
----------
     90925
select count(*) from containers(c##bgrenn.local_objects)  ;
 
  COUNT(*)
----------
    272773

Step 4 - Now to  look at the explain plan for one of the tables across containers

SET LINESIZE 130
SET PAGESIZE 0
SELECT * FROM table(DBMS_XPLAN.DISPLAY);
SQL> SQL> Plan hash value: 1439328272

----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |            |     1 |   381 |     0   (0)|       |       |        |      |         |
|   1 |  PX COORDINATOR     |       |            |       |       |            |       |       |        |      |
|   2 |   PX SEND QC (RANDOM)       | :TQ10000   |     1 |   381 |            |       |       |  Q1,00 | P->S | QC (RAND)  |
|   3 |    PX PARTITION LIST ALL    |            |     1 |   381 |            |     1 |   254 |  Q1,00 | PCWC |         |
|   4 |     FIXED TABLE FULL        | X$CDBVW$   |     1 |   381 |            |       |       |  Q1,00 | PCWP |         |
----------------------------------------------------------------------------------------------------------------------

Finally, this is the explain plan for a join query to get all the tables

explain plan for
select *
  from containers(c##bgrenn.local_objects) a,
       containers(c##bgrenn.local_tables) b
where
  a.object_name = b.table_name and
  a.object_type = 'TABLE';

SET LINESIZE 150
SET PAGESIZE 0
SELECT * FROM table(DBMS_XPLAN.DISPLAY);

  2    3    4    5    6    7  
Explained.

SQL> SQL> SQL> SQL> Plan hash value: 198107036

-------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ    |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           |     1 |  1226 |     0     (0)| 00:00:01|       |       |        |      |        |
|   1 |  PX COORDINATOR              |           |       |       |            |           |       |       |        |      |        |
|   2 |   PX SEND QC (RANDOM)        | :TQ10002  |     1 |  1226 |     0     (0)| 00:00:01|       |       |  Q1,02 | P-S  | QC (RAND)  |
|*  3 |    HASH JOIN BUFFERED        |           |     1 |  1226 |     0     (0)| 00:00:01|       |       |  Q1,02 | PCWP |        |
|   4 |     PX RECEIVE               |           |     1 |   381 |            |           |       |       |  Q1,02 | PCWP |        |
|   5 |      PX SEND HYBRID HASH     | :TQ10000  |     1 |   381 |            |           |       |       |  Q1,00 | P-P  | HYBRID HASH|
|   6 |       STATISTICS COLLECTOR   |           |       |       |            |           |       |       |  Q1,00 | PCWC |        |
|   7 |        PX PARTITION LIST ALL |           |     1 |   381 |            |           |     1 |   254 |  Q1,00 | PCWC |        |
|*  8 |     FIXED TABLE FULL         | X$CDBVW$  |     1 |   381 |            |           |       |       |  Q1,00 | PCWP |        |
|   9 |     PX RECEIVE               |           |     1 |   845 |            |           |       |       |  Q1,02 | PCWP |        |
|  10 |      PX SEND HYBRID HASH     | :TQ10001  |     1 |   845 |            |           |       |       |  Q1,01 | P-P  | HYBRID HASH|
|  11 |       PX PARTITION LIST ALL  |           |     1 |   845 |            |           |     1 |   254 |  Q1,01 | PCWC |        |
|  12 |        FIXED TABLE FULL      | X$CDBVW$  |     1 |   845 |            |           |       |       |  Q1,01 | PCWP |        |
-------------------------------------------------------------------------------------------------------------------------------------

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

   3 - access("A"."OBJECT_NAME"="B"."TABLE_NAME")
   8 - filter("A"."OBJECT_TYPE"='TABLE')

25 rows selected.

This looks like a very useful feature to get a high level view of all PDB's.  The things to note are.

1) You need to use a common user and this user needs to be the schema owner in all PDB's
2) By looking at the plan, I'm sure there is some high level view that does this using partitions.

Performance tuning using Oracle Internal Packages

I had an interesting problem last week with a customer who was performance testing on a new system compared to their current system.

The script was pretty simple. It was a PL/SQL package that inserted into a table 10M rows, and committed every 1,000 rows.  To make the data more "normal" the customer used DBMS_RANDOM .

The basic insert looked like this.

INSERT INTO TEST_TABLE1
     (ID,DTVAL,
      DTSTAMP,
      COL1,
      NUM)
VALUES
    (:B1 ,
      SYSDATE,
      SYSTIMESTAMP,
      DBMS_RANDOM.STRING('A', 100),
      DBMS_RANDOM.RANDOM);

To me it seemed like a simple test.  Unfortunately the performance results were not as expected.    To step back for a minute the current system was running on 11.1.0.7 and the new system they were benchmarking against was 11.2.0.4.

I even had them check the output of the  Table to ensure no changes in the output.. Everything looked the same.

You wouldn't think that would matter, but the differences in DBMS_RANDOM between versions seemed to be issue.  You see DBMS_RANDOM periodically has logic changes, and the performance of DBMS_RANDOM cannot be compared between versions in a performance benchmark.

I had the customer re-run the tests with constants instead of calling DBMS_RANDOM and the results were much better.

To reproduce what they saw  I finally tested against 11.2.0.2 and  12.1.0.1 (on the same machine).  I could not get a copy of 11.1.0.7 and 11.2.0.4 to test.  These 2 versions were enough to see the difference that affected the Customers Benchmark.

Below I've included the TKPROF formatted output from the trace file on 11.2.0.2

SQL ID: fg7gf0m6a2ca4 Plan Hash: 0

INSERT INTO TEST_TABLE1 (ID,DTVAL,DTSTAMP,COL1,NUM)
VALUES
(:B1 , SYSDATE, SYSTIMESTAMP, DBMS_RANDOM.STRING('A', 100),
  DBMS_RANDOM.RANDOM)


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute 100000     25.81      39.51          0       2464     119161      100000
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total   100001     25.81      39.51          0       2464     119161      100000

Notice the CPU time.. 25.81 seconds of CPU time on 11.2.0.2

Below is the TKPROF formatted output from the trace file on 12..1.0.1

INSERT INTO TEST_TABLE1 (ID,DTVAL,DTSTAMP,COL1,NUM)
VALUES
(:B1 , SYSDATE, SYSTIMESTAMP, DBMS_RANDOM.STRING('A', 100),
  DBMS_RANDOM.RANDOM)


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute 100000     74.01      90.31          1       3722     111116      100000
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total   100001     74.01      90.31          1       3722     111116      100000

This time notice that it 74.01 seconds of CPU.. Same statement executed the same number of times..

The difference between the 2 versions is almost 3X longer in 12.1.0.1

No I re-ran it with constants

11.2.0.2 Test

INSERT INTO TEST_TABLE1 (ID,DTVAL,DTSTAMP,COL1,NUM)
VALUES
(:B1 , SYSDATE, SYSTIMESTAMP, 'a', 1)


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute 100000      4.62       6.02          0        536     108087      100000
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total   100001      4.62       6.02          0        536     108087      100000

12.1.0.1 test

INSERT INTO TEST_TABLE1 (ID,DTVAL,DTSTAMP,COL1,NUM)
VALUES
(:B1 , SYSDATE, SYSTIMESTAMP, 'a', 1)


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute 100000      4.78       7.09          1        586     105731      100000
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total   100001      4.78       7.09          1        586     105731      100000

Wow.. Now that I use constants, the CPU time was almost identical.

There are absolutely some major performance differences with DBMS_RANDOM between versions.

Moral of the story is don't use internal packages for benchmarking (unless they are critical to your application).



Finally, this is the package code I used for testing..

OWNER        SET TIME ON
SET TIMING ON
SET ECHO ON
SET SERVEROUTPUT ON
SET TERMOUT ON
SET VERIFY ON
SET FEEDBACK ON

WHENEVER SQLERROR CONTINUE

select to_char(sysdate,'mm/dd/yyyy hh:mi:ss AM') from dual;


prompt create the test_table1

drop table test_table1;

create table test_table1
(
id NUMBER,
dtval DATE,
dtstamp TIMESTAMP,
col1 varchar2(100),
num NUMBER
);   

prompt Insert 1M with commit every 1000 records

alter session set tracefile_identifier = 'test_sess_1';
exec dbms_monitor.session_trace_enable( waits => true );


DECLARE
 x  PLS_INTEGER;
 rn NUMBER(20); 
BEGIN

  SELECT hsecs
  INTO rn
  FROM v$timer;
  
  dbms_random.initialize(rn);
  FOR i IN 1..100000
  LOOP
    x := dbms_random.random;
    rn := x; 
    
    insert into test_table1 (id,dtval,dtstamp,col1,num)
    values(x, sysdate, systimestamp, DBMS_RANDOM.string('A', 100), dbms_random.random);
    
    If ( MOD(i,100) = 0) then
        commit;
    end if;
    
  END LOOP;
  dbms_random.terminate;
END;
/

EXEC DBMS_MONITOR.session_trace_disable;

prompt Count of all records

select count(*) from test_table1;
select count(distinct col1) from test_table1 ;
select count(distinct num) from test_table1 ;

Monitoring your Exadata health

One of the biggest topics I talk to customers about is the monitoring of your exadata health. 

The best tool for this is the Exachk (see MOS Doc ID 1070954.1)

This document contains the current Exachk release, and any new beta release that is available.

The recommendation for Exachk is to

1) Run the exachk (at a minimum) quarterly, and after any changes are made to the configuration
2) ALWAYS run the current exachk.  This script is periodically updated/improved upon so it is very important to be current
3) Keep track of any failures to ensure that you can identify any new items that appear in the report
4) A score of 80 or above is a good score for production. It is very rare to have a score that is 99+.

There are also a great whitepaper  released in Sept. 2013 (just a few months ago).

This white paper can be  here.

http://www.oracle.com/technetwork/database/availability/exadata-health-resource-usage-2021227.pdf

X4-2 Exadata Announcement

These the differences with the new X4-2 just announced, along with a table comparing the differences.
1) Double the size of flashcache
2) Switch from 3tb drives to 4tb drives (HC)
3) More cpu cores
4) Increase in Infiniband throughput by using an Active-Active configuration
5) Automatic Flash compression on X3 and X4 systems (using the ACO option)

	x2	X3	X4
Database
Processesor	2 x Six-Core Intel Xeon® X5675 Processors (3.06 GHz)	2 x Eight-Core Intel Xeon®E5-2690 Processors (2.9 GHz)	2 X Twelve-Core Intel® Xeon® E5-2697 V2 Processors (2.7 GHz)
Memory	96G	128g/256g	256g
Disk controller	Disk Controller HBA with 512MB Batter Backed Write Cache	Disk Controller HBA with 512MB Batter Backed Write Cache	Disk Controller HBA with 512MB Batter Backed Write Cache
Internal disks	4 x 300 GB 10,000 RPM SAS Disks	4 x 300 GB 10,000 RPM Disks	4 x 600 GB 10,000 RPM Disks
Infiniband	2 x QDR (40Gb/s) Ports	2 x QDR (40Gb/s) Ports	2 x QDR (40Gb/s) Ports
Ethernet	2 x 10 Gb Ethernet Ports based on the Intel 82599 10GbE Controller	4 x 1/10 Gb Ethernet Ports (copper)	4 x 1/10 Gb Ethernet Ports (copper)
Ethernet	4 x 1 Gb Ethernet Ports	2 x 10 Gb Ethernet Ports (optical)	2 x 10 Gb Ethernet Ports (optical)
Full Rack	96 CPU cores and 768 gb memory for database processing (12 CPU cores and 96 GB memory per Database Server)	128 CPU cores and 1TB or  2 TB memory for database processing (16 CPU cores and 256 GB memory per Database Server)	192 CPU cores and 2TB memory for database processing (24 CPU cores and up to 512 GB memory per Database Server)
Storage Cells
CPU	2 x Six-Core Intel® Xeon® L5640 (2.26 GHz) Processors	2 x Six-Core Intel® Xeon® E5-2630L (2.0 GHz processors)	2 x Six-Core Intel® Xeon® E5-2630 v2 (2.6 GHz processors)
Memory	24 GB	64 GB	96 GB
HC (High Capacity)
Disk Bandwidth¹	Up to 18 GB/second of uncompressed disk bandwidth	Up to 18 GB/second of uncompressed disk bandwidth	Up to 20 GB/second of uncompressed disk bandwidth
Flash Bandwidth¹	Up to 68 GB/second of uncompressed Flash data bandwidth	Up to 93 GB/second of uncompressed Flash data bandwidth	Up to 100 GB/second of uncompressed Flash data bandwidth
Disk IOPS ²	Up to 28,000 Database Disk IOPS	Up to 28,000 Database Disk IOPS	Up to 32,000 Database Disk IOPS
Flash read IOPS ²	Up to 1,500,000 Database Flash IOPS	Up to 1,500,000 Database Flash IOPS	Up to 2,660,000 Database Flash IOPS
Flash write IOPS³	N/A	Up to 1,000,000 Database Flash IOPS	Up to 1,680,000 Database Flash IOPS
Flash Data Capacity (raw)⁴	5.3 TB Exadata Smart Flash Cache	22.4 TB	44.8 TB
Disk Data capacity (raw)⁵	504 TB of raw disk data capacity	504 TB	672 TB
Disk Data capacity (Usable)⁶	Up to 224 TB of uncompressed usable capacity	224 TB	300 TB
HP (High Performance)
Disk Bandwidth¹	Up to 25 GB/second of uncompressed disk bandwidth	Up to 25 GB/second of uncompressed disk bandwidth	Up to 24 GB/second of uncompressed disk bandwidth
Flash Bandwidth¹	Up to 75 GB/second of uncompressed Flash data bandwidth	Up to 100 GB/second of uncompressed Flash data bandwidth	Up to 100 GB/second of uncompressed Flash data bandwidth
Disk IOPS ²	Up to 50,000 Database Disk IOPS	Up to 50,000 Database Disk IOPS	Up to 50,000 Database Disk IOPS
Flash read IOPS ²	Up to 1,500,000 Database Flash IOPS	Up to 1,500,000 Database Flash IOPS	Up to 2,660,000 Database Flash IOPS
Flash write IOPS³	N/A	Up to 1,000,000 Database Flash IOPS	Up to 1,680,000 Database Flash IOPS
Flash Data Capacity (raw)⁴	5.3 TB Exadata Smart Flash Cache	22.4 TB	44.8 TB
Disk Data capacity (raw)⁵	100 TB of raw disk data capacity	100 TB	200 TB
Disk Data capacity (Usable)⁶	Up to 45 TB of uncompressed usable capacity	45 TB	90 TB
	¹Bandwidth is peak physical scan bandwidth achieved running SQL, assuming no database compression. Effective user data bandwidth is higher when database compression is used.
	²Based on 8K IO requests running SQL. Note that the IO size greatly affects Flash IOPS. Others quote IOPS based on 2K or smaller IOs and are not relevant for databases.
	³Based on 8K IO requests running SQL. Flash write I/Os measured at the storage servers after ASM mirroring. Database writes will usually issue multiple storage IOs to maintain redundancy.
	⁴Raw capacity is measured in standard disk drive terminology with 1 GB = 1 billion bytes. Capacity is measured using normal powers of 2 space terminology with 1 TB = 1024 * 1024 * 1024 * 1024 bytes. Actual formatted capacity is less.
	⁵Raw capacity is measured in standard disk drive terminology with 1 GB = 1 billion bytes. Capacity is measured using normal powers of 2 space terminology with 1 TB = 1024 * 1024 * 1024 * 1024 bytes. Actual formatted capacity is less.
	⁶Actual space available for a database after mirroring (ASM normal redundancy) while also providing adequate space (one disk on Quarter and Half Racks and two disks on a Full Rack) to reestablish the mirroring protection after a disk failure in the normal redundancy case.

--> -->

Oracle 12c PL/SQL improvements.

Last week I was giving a presentation for the UNYOUG (Upstate NY Oracle users Group) and I talked about the new features in 12c (along with In-Memory database).

I thought I would share some thoughts after the meeting.

I went through Tom Kyte's top 12 new features, and surprisingly the top feature that excited people was the PL/SQL improvements. 

The PL/SQL improvements had to do with the ability to write a PL/SQL as part of the query.

Lets say currently with 11g you have a function that includes the days between 2 dates.

  CREATE OR REPLACE FUNCTION Days_Between 
             (first_dt DATE, second_dt DATE)
                RETURN NUMBER IS 
       dt_one NUMBER; 
       dt_two NUMBER; 
BEGIN 
      dt_one := TO_NUMBER(TO_CHAR(first_dt, 'DDD')); 
      dt_two := TO_NUMBER(TO_CHAR(second_dt, 'DDD'));  
           RETURN (dt_two - dt_one); 
 END Days_Between;   

select Days_between(start_date,end_date) from mytable;



The problem is that in order to test this function you need to create the function.  There are multiple issues that developers face with having to do this.

1. Developers often don't have the authority to create/change functions, especially if they need to be owned by a different schema
2. Replacing the current function affects other users and this may not be desirable while debugging changes.
3. Testing against production data is often not possible because of authorization, and collision issues.

The answer in 12c is the ability to include a function in the "WITH" clause.. The above would become


WITH  FUNCTION Days_Between
             (first_dt DATE, second_dt DATE)
                RETURN NUMBER IS
       dt_one NUMBER;
       dt_two NUMBER;
BEGIN
      dt_one := TO_NUMBER(TO_CHAR(first_dt, 'DDD'));
      dt_two := TO_NUMBER(TO_CHAR(second_dt, 'DDD'));
           RETURN (dt_two - dt_one);
 END Days_Between;  
select Days_between(start_date,end_date) from mytable;

So. what about Procedures you ask ? You can also include procedures in the mix.  The main purpose of doing this is to include any procedures that are invoked from the function.  This way you can include all the "dependencies" in the with clause. 

Finally, I read an article talking about how much this improves performance too.

http://www.oracle-base.com/articles/12c/with-clause-enhancements-12cr1.php#plsql-support

but to the developers I talked to the big advantage was with the ability to test..

As far as performance gains, I don't know how much I would put reusable code (like functions) directly into a sql statement. It would be a bear to support any changes to a "common function" defined multiple places.