Is corruption always true corruption ?

Well the short answer is that there are different types of corruption.  I am writing this blog because I recently ran across “nologging” corruption which is considered softl corruption, and the handling of this type of corruption has changed across versions (which I will cover at the end of this article).

First, how does this happen ?  It can be seen in a physical standby, but you can also get this type of corruption in a Primary database.  I will go through how to reproduce this type of corruption shortly. 

Next, what is nologging ?  Nologging processes are direct path updates to the database that do not contain detailed log information.  Notice I used the word “detailed” .  This is because some logging is captured as to what blocks are updated, but the individual updates are not captured.

Nologging is most common in datawarehouse load processes (ELT)  that are part of workflow that can be restarted.  Often tables are created during this processing that are only kept as part of the processing.  Nologging can also be used for performing large inserts into existing tables.  Because this type of processing tends to be “logging intensive”, and steps can be re-run, nologging is utilized for these objects.  Nologging can speed up processing by performing limited logging.  The downside of nologging is that for objects updated with nologging, there is no point in time recovery capability.  The object can only be restore/recovered to the point where a backup is taken (full or incremental).  More on that later.

I will start by showing a nologging workflow.

Below are the steps on how to reproduce a nologging test.

  1)      Ensure that force_logging=false   ---  If FORCE_LOGGING is turned on, any nologging processing is handled as logging

SQL> select force_logging from v$database;

FOR

---

NO

2)   Create a nologging table

SQL>  create table bgrenn.test nologging as select * from dba_objects where 0=1;

Table created.

 

3)      Ensure the new table is nologging

SQL> select owner,table_name,logging from dba_tables where owner='BGRENN';

OWNER                          TABLE_NAME                     LOG

------------------------------ ------------------------------ ---

BGRENN                         TEST                           NO

4)      Perform a full backup of the database

RMAN> backup incremental level 0 database;

Starting backup at 23-february -2018 12:45:45

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=1069 device type=DISK

allocated channel: ORA_DISK_2

…

…

channel ORA_DISK_1: starting incremental level 0 datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00005 name=/oradata/db1/soe.dbf

…

…

channel ORA_DISK_7: starting incremental level 0 datafile backup set

channel ORA_DISK_7: specifying datafile(s) in backup set

input datafile file number=00004 name=/oradata/db1/users01.dbf

channel ORA_DISK_7: starting piece 1 at 23-february -2018 12:46:22

channel ORA_DISK_8: starting incremental level 0 datafile backup set

channel ORA_DISK_8: specifying datafile(s) in backup set

including current SPFILE in backup set

channel ORA_DISK_8: starting piece 1 at 23-february -2018 12:46:28

channel ORA_DISK_2: finished piece 1 at 23-february -2018 12:46:30

…

….

Finished backup at 23-february -2018 12:50:01

5)      Update the table no logging using append hint

SQL> insert into /*+ append */ bgrenn.test select * from dba_objects nologging;

68947 rows created.

SQL> Commit;

6)      Switch the logfile to ensure the changes are written to archive logs.

SQL> alter system switch logfile;

OK. Now we have done a Full backup of the database, and performed a nologging change to my table “bgrenn.test”.  I did a log switch to ensure the change is written to the archive log.

The next step is to reproduce the nologging “soft corruption” through a restore.

At this point, blocks containing my table were inserted into, but the actual changes were not logged.  The block numbers were written to the log file, and on recovery these blocks will be marked as being changed.

1)      Check for block corruption before restoring

SQL> select * from v$database_block_corruption;

no rows selected

2)       Retart the database mount and restore the database

RMAN> connect target /

connected to target database: DB16 (DBID=3618808394)

RMAN> shutdown immediate;

using target database control file instead of recovery catalog

startup mount;

database closed

database dismounted

Oracle instance shut down

using target database control file instead of recovery catalog

startup mount;

database closed

database dismounted

Oracle instance shut down

RMAN> startup mount;

connected to target database (not started)

Oracle instance started

database mounted

Total System Global Area   14564409344 bytes

Fixed Size                     2149720 bytes

Variable Size               6308233896 bytes

Database Buffers            8187281408 bytes

Redo Buffers                  66744320 bytes

RMAN> restore database;

Starting restore at 23-february -2018 12:55:54

allocated channel: ORA_SBT_TAPE_1

channel ORA_SBT_TAPE_1: SID=1110 device type=SBT_TAPE

channel ORA_SBT_TAPE_1: Oracle Secure Backup

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=1109 device type=DISK

…

…

channel ORA_DISK_5: starting datafile backup set restore

channel ORA_DISK_5: specifying datafile(s) to restore from backup set

channel ORA_DISK_5: restoring datafile 00004 to /oradata/db1116/users01.dbf

channel ORA_DISK_5: reading from backup piece /u01/app/oracle/flash_recovery_area/DB1116/backupset/2018_02_23/o1_mf_nnnd0_TAG20180223T12454

7_f90vwp3j_.bkp

Finished restore at 23-february -2018 12:57:41

3)      Recover database

RMAN> recover database;

Starting recover at 23-february -2018 12:58:22

using channel ORA_SBT_TAPE_1

using channel ORA_DISK_1

using channel ORA_DISK_2

using channel ORA_DISK_3

using channel ORA_DISK_4

using channel ORA_DISK_5

using channel ORA_DISK_6

using channel ORA_DISK_7

using channel ORA_DISK_8

starting media recovery

media recovery complete, elapsed time: 00:00:01

Finished recover at 23-february -2018 12:58:23

RMAN> alter database open;

database opened

RMAN>

4)      Check for corruption after restoring the database

SQL> select * from v$database_block_corruption;

no rows selected

5)      Select from the table in which we ran our nologging process

SQL> select * from bgrenn.test;

select * from bgrenn.test

                     *

ERROR at line 1:

ORA-01578: ORACLE data block corrupted (file # 4, block # 60)

ORA-01110: data file 4: '/oradata/db1/users01.dbf'

ORA-26040: Data block was loaded using the NOLOGGING option

6)      Check corruption again

SQL> select * from v$database_block_corruption;

no rows selected

7)       Validate datafile

RMAN> validate datafile 4;

Starting validate at 23-february -2018 14:15:36

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=1107 device type=DISK

channel ORA_DISK_8: SID=1073 device type=DISK

channel ORA_DISK_1: starting validation of datafile

channel ORA_DISK_1: specifying datafile(s) for validation

input datafile file number=00004 name=/oradata/db1/users01.dbf

channel ORA_DISK_1: validation complete, elapsed time: 00:00:01

List of Datafiles

=================

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN

---- ------ -------------- ------------ --------------- ----------

4    OK     1016           307          1440            1760824163

  File Name: /oradata/db1/users01.dbf

  Block Type Blocks Failing Blocks Processed

  ---------- -------------- ----------------

  Data       0              63             

  Index      0              2              

  Other      0              1068           

Finished validate at 23-february -2018 14:15:42

Now this is where it gets interesting between version of Oracle.  Oracle 10g/11.1 reports this soft corruption differently from Oracle 11.2, and  both of these report it differently from 12.1+

Oracle 11.1   -

1)      Check for corruption in v$DATABASE_BLOCK_CORRUPTION  -- NOTE the corrupt_type only reports "CORRUPTION"

SQL> select * from v$database_block_corruption;

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO

---------- ---------- ---------- ------------------ ---------

         4         60         13         1760822701 CORRUPT

         4         74         15         1760822716 CORRUPT

         4         90         15         1760822716 CORRUPT

         4        106         15         1760822730 CORRUPT

         4        122         15         1760822730 CORRUPT

         4        138         15         1760822745 CORRUPT

         4        154         15         1760822745 CORRUPT

         4        170         15         1760822759 CORRUPT

         4        267        126         1760822759 CORRUPT

         4        395        126         1760822763 CORRUPT

         4        523        126         1760822767 CORRUPT

         4        651        126         1760822771 CORRUPT

         4        779        126         1760822775 CORRUPT

         4        907        126         1760822779 CORRUPT

         4       1035        126         1760822784 CORRUPT

         4       1163         16         1760822788 CORRUPT

2)      Definition  of  CORRUPTION_TYPE

·         ALL ZERO - Block header on disk contained only zeros. The block may be valid if it was never filled and if it is in an Oracle7 file. The buffer will be reformatted to the Oracle8 standard for an empty block.

·         FRACTURED - Block header looks reasonable, but the front and back of the block are different versions.

·         CHECKSUM - optional check value shows that the block is not self-consistent. It is impossible to determine exactly why the check value fails, but it probably fails because sectors in the middle of the block are from different versions.

·         CORRUPT - Block is wrongly identified or is not a data block (for example, the data block address is missing)

·         LOGICAL - Specifies the range is for logically corrupt blocks. CORRUPTION_CHANGE# will have a nonzero values

3)      OEM Schedule Backup screen shows corruption

Oracle 11.2   -

1)      Check for corruption in v$DATABASE_BLOCK_CORRUPTION  -- NOTE 11.2 reports the soft corrupt in the view as "NOLOGGING" corruption.

SQL> select * from v$database_block_corruption;

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO

---------- ---------- ---------- ------------------ ---------

         4         60         13         1760822701 NOLOGGING

         4         74         15         1760822716 NOLOGGING

         4         90         15         1760822716 NOLOGGING

         4        106         15         1760822730 NOLOGGING

         4        122         15         1760822730 NOLOGGING

         4        138         15         1760822745 NOLOGGING

         4        154         15         1760822745 NOLOGGING

         4        170         15         1760822759 NOLOGGING

         4        267        126         1760822759 NOLOGGING

         4        395        126         1760822763 NOLOGGING

         4        523        126         1760822767 NOLOGGING

         4        651        126         1760822771 NOLOGGING

         4        779        126         1760822775 NOLOGGING

         4        907        126         1760822779 NOLOGGING

         4       1035        126         1760822784 NOLOGGING

         4       1163         16         1760822788 NOLOGGING

2)      Definition  of  CORRUPTION_TYPE

·         ALL ZERO - Block header on disk contained only zeros. The block may be valid if it was never filled and if it is in an Oracle7 file. The buffer will be reformatted to the Oracle8 standard for an empty block.

·         FRACTURED - Block header looks reasonable, but the front and back of the block are different versions.

·         CHECKSUM - optional check value shows that the block is not self-consistent. It is impossible to determine exactly why the check value fails, but it probably fails because sectors in the middle of the block are from different versions.

·         CORRUPT - Block is wrongly identified or is not a data block (for example, the data block address is missing)

·         LOGICAL - Block is logically corrupt

·         NOLOGGING - Block does not have redo log entries (for example, NOLOGGING operations on primary database can introduce this type of corruption on a physical standby)

3)      OEM Schedule Backup screen shows corruption

Oracle 12.1   -

1)      Check for corruption in v$DATABASE_BLOCK_CORRUPTION  -- NOTE - 12.1 does not report it as corruption, but is reported in a new view  V$NONLOGGED_BLOCK

SQL> select * from v$database_block_corruption;

no rows selected

SQL> select file#,block#,blocks from v$nonlogged_block

     FILE#     BLOCK#     BLOCKS

---------- ---------- ----------

         6       6786        126

         6       6914        126

         6       7042        126

         6       7170        126

         6       7298        126

         6       7426        126

         6       7554        126

         6       7682        126

         6       7810        126

         6       7938        126

         6       8066        126

     FILE#     BLOCK#     BLOCKS

---------- ---------- ----------

         6       8194        126

         6       8322        126

         6       8512         64

47 rows selected.

2)      Definition  of  CORRUPTION_TYPE

·         ALL ZERO - Block header on disk contained only zeros. The block may be valid if it was never filled and if it is in an Oracle7 file. The buffer will be reformatted to the Oracle8 standard for an empty block.

·         FRACTURED - Block header looks reasonable, but the front and back of the block are different versions.

·         CHECKSUM - optional check value shows that the block is not self-consistent. It is impossible to determine exactly why the check value fails, but it probably fails because sectors in the middle of the block are from different versions.

·         CORRUPT - Block is wrongly identified or is not a data block (for example, the data block address is missing)

·         LOGICAL - Block is logically corrupt

3)      OEM Schedule Backup screen

Nothing appears

Now we have seen how to recreate “soft corruption” caused by nologging.  I have also shown how this is displayed in different versions of Oracle.

There are a few items to note that I have learned from this testing.

·        This is considered “soft corruption” so it is not reported when restoring a database.  This makes it very hard detect.

·        The ZDLRA does validation during backups, but since this is “soft corruption”, the database is backed up without no alerting.

·        OEM reports this corruption differently between versions.  With version 12.1 it is no longer reported in V$DATABASE_BLOCK_CORRUPTION, so OEM does not alert on this.

How to avoid Nologging corruption.

Ensure that you schedule backups when there isn’t any nologging operations occurring.This is a situation where the ZDLRA shines.  You can take an incremental backup before and after your nologging process then you have the capability to perform a full restore from either of these checkpoints.

Creating Popup windows on your Apex Page

I have been playing with Apex for an internal application  Application Express is a great tool, and Oracle has an internal Apex environment that groups can use for their own internal applications.

In creating the application I learned how to do a Javascript window that pops up within a page to help enter data. This can be very useful to add a function to your application without adding more pages.


This is how its down..

First I created a table to contain breweries..  Since this is running on 12.1, I was able to use the new feature to automagically use a sequence as a default value (it's about time right) ?

Here is my table creation script..


CREATE SEQUENCE brewery_seq
 START WITH     1000
 INCREMENT BY   1
 NOCACHE
 NOCYCLE;

Create table breweries
(brewery_id number default brewery_seq.nextval primary key,
         brewery_name varchar2(255),
         Brewery_rating number);

So first I did was create a new region on the a new page.

ZDLRA and the FRA

ZDLRA and the FRA

I often get questions around the FRA (Flash Recovery Area), and how it should be used when moving backups to the ZDLRA.

First though, the recommendation is to ALWAYS set your db_recovery_file_dest_size to be 10% less than the amount of space available, and don't put other files in this same location (that are not managed as part of the FRA).  

Having a 10% buffer ensures that you can increase the available storage if necessary.  For those experienced on-call DBA's I'm sure there have been times where increasing the db_recovery_file_dest_size by that last 10% was used to keep the database running while space was cleaned up.. And of course this is often at 3:00 AM when the dreaded "archive log destination full" alert comes across.

First let's go through what's in the FRA and how it's being used.   

There is a lot of information in MOS and I will include pertinent MOS notes at the end of this post.

What's in the FRA  (V$FLASH_RECOVERY_AREA_USAGE shows us )?

Here is a sample output 

SQL> Select file_type, percent_space_used as used,
percent_space_reclaimable as reclaimable, 
    number_of_files as "number" from v$flash_recovery_area_usage; 
     
    FILE_TYPE          USED RECLAIMABLE     number 
    ------------ ---------- ----------- ---------- 
    CONTROLFILE           0           0          0 
    ONLINELOG             0           0          0 
    ARCHIVELOG         4.77           0          2 
    BACKUPPIECE       56.80           0         10 
    IMAGECOPY             0           0          0 
    FLASHBACKLOG      11.68       11.49         63 



From this you can see the following items are in the FRA.

CONTROLFILE  -- This comes from setting the location of the CONTROLFILE backup.

configure controlfile autobackup on;

If you configure controlfile backups using the 'FORMAT" option, it will not be managed by the FRA.

ONLINELOG

A copy of the online redo logs go to the FRA  when the DB_RECOVERY_FILE_DEST is set and the DB_CREATE_ONLINE_LOG_DEST_n is not set.




ARCHIVELOG -- 

Archive logs are managed by the FRA when the archive LOG_ARCHIVE_DEST_n parameter contains the clause 'LOCATION=USE_DB_RECOVERY_FILE_DEST'

alter system set LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'';

BACKUPPIECE or IMAGECOPY

RMAN backups are managed by the FRA when you configure RMAN to (or explicitly) send backups to disk AND the FORMAT option is not specified.

FLASHBACKLOG 

If flashback database is turned on for the database, flashback logs will be kept in the FRA automatically.  The database parameter db_flashback_retention_target is set to determine the amount of flashback logs that are kept for the database.

Now let's take a look at how space is managed for each piece 

ONLINELOG  -- Since online redo logs are necessary for the database, this is not affected with space pressure.

FLASHBACKLOG   -- Flashback logs are automatically removed to keep the window specified in the DB_FLASHBACK_RETENTION_TARGET setting.  If there is space pressure, the flashback management will automatically release space until it hits a window of 1 hour.  This is the default and comes from the _MINIMUM_DB_FLASHBACK_RETENTION parameter.

BACKUPPIECE or IMAGECOPY and/or CONTROLFILE and ARCHIVELOG --  these are managed by the setting in RMAN for the retention policy. 

The recommendation for the ZDLRA (when using real-time redo apply) is to set this parameter to

CONFIGURE ARCHIVELOG RETENTION POLICY SHIPPED to all STANDBY;

NOTE - This policy marks archive logs as "reclaimable" as soon as they are considered shipped to ALL standby databases.  If the ZDLRA is the only external destination, then as soon as it's received on the ZDLRA, it is "reclaimable".  If you have Dataguard along with ZDLRA, then archive logs are considered "reclaimable" as soon as they are received by both.

OR

CONFIGURE ARCHIVELOG RETENTION POLICY APPLIED on all STANDBY;

NOTE - This policy marks archive logs as "reclaimable" as soon as they are considered APPLIED on ALL standby databases.  If the ZDLRA is the only external destination, then as soon as it's received on the ZDLRA AND has been cataloged, it is "reclaimable".   This takes less than a minute, and occurs independent of the protected database.  If you have Dataguard along with ZDLRA, then archive logs are considered "reclaimable" as soon as they are applied by both.

***  Note that "APPLIED" is the most desirable because this ensures that the log is not removed until it "processed" by all destinations, HOWEVER, if you have a standby location that has a gap in apply then you need to consider "SHIPPED".

Both Policies will work, but it depends on your configuration.

The recommendation for the ZDLRA (when using log sweeps) is to set this parameter to

CONFIGURE ARCHIVELOG RETENTION POLICY xx backed up 1 times device type SBT;

Where XXX is

1) not used if there is no Dataguard or other destinations beyond local disk for archive logs.
2) "SHIPPED to all STANDBY" if Dataguard or Golden Gate is used.
3) "APPLIED" on all STANDBY if Dataguard or Golden Gate is used.

Now let's take a look at how space is managed (315098.1)
There is a MOS note on this, but it there are still some misconceptions on what you see happening.



Looking at the output of view V$RECOVERY_FILE_DEST you will see 3 pertinent columns.

SPACE_LIMIT                              ==> this is the amount of space that is allocated to the FRA.
SPACE_USED                               ==> This is the amount of space currently used
SPACE_RECLAIMABLE             ==> This is the amount space that the FRA considers reclaimable.
                                                                ** This NOT the total amount space reclaimable, just the amount
                                                                that the FRA knows about (I'll get to what this means soon).


The note says that 

If the free space becomes less then 15% in the Flash Recovery Area then all  the archivelogs in the Flash Recovery Area which are not needed for recovery by the current backups in the FRA will become obsolete and the space occupied will be shown in the SPACE RECLAIMABLE column of V$RECOVERY_FILE_DEST.

From this I made some assumptions that were incorrect.

I assumed 

1) Since I was immediately sending all backups and archive logs to the ZDLRA (Real Time Apply), the space for the ARCHIVELOG would all show up in the SPACE_RECLAIMABLE column.

2) When the FRA reaches 85%, it would automatically clean up ARCHIVELOGS to bring it down to 85%.

Both of these assumptions were wrong.  By testing I found that this is what actually happens, and this still falls within the verbiage in that note.

This is what happens as the space fills up.

For my example I have a 1 TB FRA.

849 GB used in the FRA.  The reclaimable space is NOT calculated yet because we have not hit the 85% full mark. 

Space_limit             1000GB

Space_used              849GB

Space_reclaimable       0GB

At 850GB  I reached 85% full. This is the point where the database  calculates SPACE_RECLAIMABLE.  Note that it does not fully calculate what's reclaimable, it only finds a portion of the reclaimable space.

Space_limit             1000GB

Space_used              850GB

Space_reclaimable       300GB

At 999GB it's not quite full.  The reclaimable space shows there is space available, 

but it still only finds a portion of the available space.

Space_limit             1000GB

Space_used              999GB

Space_reclaimable       300GB

At 1000GB it is completely full. The reclaimable space shows space available to be reclaimed.

At this point I can see in the alert log that archive logs are being removed. 

Only enough logs are removed to make space for new logs.  it remains at 99% used.

Space_limit             1000GB

Space_used              999GB

Space_reclaimable       160GB

As I added more logs, it remained at 99% used.

This makes it very difficult to know how much space you have available in your FRA. 

The warnings start occurring at the 85% full mark.

Since the FRA recalculates the SPACE_RECLAIMABLE at 85% full, but only adjusts it to keep  from warning,

it is impossible to tell how much TOTAL space is reclaimable.

Using the formula 

SPACE_LIMIT - SPACE_RECLAIMABLE 

Does not give you amount of space that is actually reclaimable.  

It is only useful to tell you when the amount of unreclaimable space > 85%.

Here are the useful MOS notes.

NOTE:305817.1 - FAQ - Flash Recovery Area feature

FRA: Flashback logs are not being deleted when space is needed for archive logs (Doc ID 1481739.1) Space issue in Fast / Flash Recovery Area - FRA Full (Doc ID 829755.1) How is the space pressure managed in the Flash Recovery Area - An Example. (Doc ID 315098.1) Correctly configuring the Flash Recovery Area to allow the release of reclaimable space (Doc ID 316074.1)

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 ;