De-Duplication in ZDLRA

Customers often ask whether ZDLRA has de-duplication capabilities, and (if so) how ZDLRA performs de-duplication.  This blog post will explore this question and explain how de-duplication works inside of ZDLRA.

Change-Based – The Opposite of De-Duplication

ZDLRA is change-based, which is the opposite of de-duplication.  The primary purpose of the Oracle database engine (any database engine, in fact) is to track and manage changes to data.  ZDLRA essentially taps into those change management mechanisms of the Oracle database to capture and store changes.

An Oracle database is comprised of interrelated data structures that are constantly changing.  Data in a Relational DBMS is organized into tables and tables have relationships between them.  Each table might have one or more indexes, and the pointers in each index are pointing to rows in the corresponding table.  These structures are represented in the Data Dictionary, which is tightly related to all of the tables, indexes, and other structures in the database.

The following diagram shows an extremely simple database comprised of 2 tables (EMP and DEPT) and 2 indexes.  Small production databases might have several hundred tables, and large databases might have TENS of THOUSANDS of tables, indexes and other data structures.

Screen Shot 2018-02-21 at 9.08.33 AM

Oracle databases are constantly changing.  The only way to “quiesce” an Oracle database is to force all users to disconnect and shutdown the database.  As long as the database engine is running, the data it contains will be changing.  Changes in the database (made by transactions) are written into the REDO log.  The opposite of those changes are written into an UNDO “log” in case those changes need to be reversed.  Changes to the database are sent to ZDLRA using the Delta Push process.

Delta Push = Virtual Full Backup

ZDLRA uses the RMAN “incremental backup” API to capture changes on the source database.  While this incremental backup might appear to be the same as a conventional incremental backup, it is fundamentally different in ZDLRA.  When a DELTA PUSH is executed, the results are automatically transformed into a VIRTUAL FULL backup in what is known as the Delta Store inside of ZDLRA.

Creation of the Virtual Full backup also means that changes in the database are tracked from the previous Virtual Full instead of the last Physical Full backup.  Although ZDLRA makes use of the RMAN INCREMENTAL backup API, the results are quite different.  ZDLRA is often referred to as an “incremental forever” solution, but that terminology has a certain connotation.  Other products on the market might appear to be similar (such as solutions based on the RMAN Incremental Merge feature), but they are based on a fundamentally different operating principal.

I prefer to use the term Delta Push instead of “incremental forever” because ZDLRA is vastly different than anything else on the market.

Delta Store – A Database of Block Versions

The Delta Store within ZDLRA is a database containing versions of database blocks.  Every Oracle database  is comprised of tablespaces such as SYSTEM, DATA, INDEX, UNDO, etc.  Customers can add their own tablespaces and name them as desired to organize data within the database.  Each tablespace is comprised of many blocks.  ZDLRA captures a copy of each block and arranges that block into the hierarchy.

Screen Shot 2018-02-21 at 8.52.06 AM

Each Delta Push sends the latest version of each changed block.  Those changed blocks are indexed into the Delta Store and combined with previous un-changed blocks to form a Virtual Full Backup.

Frequency of Delta Push (Daily)

The vast majority of databases will push changes to ZDLRA once per day, resulting in a Daily Virtual Full Backup.  Some databases might have extremely HIGH or LOW change rates and customers might want to use more frequent or less frequent Delta Pushes on those databases.  However, these will be extremely rare circumstances and the vast majority of databases will simply use a Daily Delta Push.

Initial Physical Full

ZDLRA begins with a PHYSICAL FULL (LEVEL0) backup of each database.  That full backup is arranged into the Delta Store and serves as the basis for all Virtual Full Backups moving forward.  Some Oracle database blocks will never change for the life of the database, while other blocks change continuously.  Over the course of time, many block versions from the initial LEVEL0 will be purged when the Recovery Window is reached.  The initial physical full essentially doesn’t exist any longer, although the oldest Virtual Full will be available in the Delta Store.

Fast Incremental (Block Change Tracking)

We recommend using the “Fast Incremental” feature of the Oracle database, which is also known a Block Change Tracking (BCT).  With Block Change Tracking, the Oracle database records all blocks that have changed since the last backup.  BCT tracks changes since the last VIRTUAL FULL backup when ZDLRA is being used.  The BCT pointers are reset each time RMAN connects to ZDLRA and performs an implicit SYNC operation.

De-Duplication (Subsequent Physical Full)

De-Duplication occurs in ZDLRA whenever a subsequent physical full backup is executed. It is possible (but certainly not recommended) to execute subsequent full backups to ZDLRA after the first physical full.  ZDLRA will identify the changed blocks and insert them into the hierarchy in the Delta Store, discarding all of the un-changed or “duplicate” blocks.

The “Global” De-Duplication Question

As shown in the above diagram, ZDLRA organizes backups database under the DBID (Database Identifier) for each database.  This obviously means that data from one database will not be associated with and de-duplicated against data contained in a different database.

Database Blocks – Data within an Oracle database is contained in database blocks.  If the same data is insert into 2 separate databases, the physical blocks are virtually guaranteed to be different.  Each database block contains a row directory, interested transaction list (ITL), header metadata, footer metadata, etc.  Each database block records the SCN (System Change Number), which is unique to a particular database.  Two physically separate databases might contain the same logical data, but the physical database blocks will be different at the bit/byte level.

Cloned Databases – The only way to generate duplicate physical blocks across 2 or more databases is to “clone” the database.  A cloned database is a physical copy of a database, but a different DBID is assigned to that database.  Backups of cloned databases will contain physically duplicate blocks of data.

Sparse Clones – Oracle supports what are known as “sparse clones” of databases using SPARSE disk groups in ASM (Automatic Storage Management).  In a sparse clone configuration, there is a “master” copy of the data with multiple clones.  Each clone writes changed blocks (different from the master) into a SPARSE disk group.  The SPARSE disk group contains only the changes for a particular clone.  The database engine reads from the “master” or from the “cloned” blocks as necessary.

Sparse Backups – The next logical step in the evolution of sparse clones is to have Sparse Backups.  Sparse backups only contained the uniquely different (changed) blocks for the clone.  The sparse backup is merged with the master copy to generate a physically unique database upon restore.  ZDLRA currently supports backup of sparse clones, but these are done as physical backups.  Oracle can discuss future plans in this area under NDA (non-disclosure agreement).

As we can see from the discussion above, “global” de-duplication, or de-duplication across multiple databases will only occur in a TEST/DEV environment.  It’s virtually impossible to have physically duplicate blocks across multiple production databases, even if those databases contain the same data in tables and indexes.  Oracle’s direction is the use of sparse clones for TEST/DEV environments, extending the sparse clone capability into sparse backups.

Change Rate vs. De-Duplication Factor

The rate of change in an Oracle database is generally expressed in terms of a percentage, meaning the changed blocks as a percentage of total blocks within the database.  For any large population of Oracle databases, the AVERAGE change rate will be in the range of 2% to 4% each day.  The average change rate typically varies by industry.  Industries with longer data retention periods (retention of data within the database) will have databases with a low daily change rate compared to industries with shorter data retention.  Each company might have specific databases with higher or lower than average daily change rates, but such outliers are not common across a large population of databases.

De-Duplication is typically expressed as a factor, such as 3X or 4X de-duplication.  A database with a 3X de-duplication factor is the same as a 33% change rate.

Changed Blocks vs. De-Duplicated Segments

The Oracle database engine tracks and manages changes to blocks of data.  The typical Oracle database block is 8KB in size.  By contrast, de-duplication storage appliances process data in larger “segments” of data, typically at 128KB in length.  Each 128KB segment typically contains 16 Oracle database blocks (assuming 8KB block size).

The typical Oracle database with an OLTP workload will have changes that are fairly distributed across the database from a physical perspective.  Data Warehouse databases tend to have more changes that are concentrated into contiguous blocks.  Large sequential data loads will be more tightly sequenced into blocks on disk, whereas INDEX changes will be more distributed.  The following diagram shows 3 changed blocks (8KB each) within a string of 16 blocks (128KB total segment length).

Screen Shot 2018-02-21 at 11.47.35 AM

Using a de-duplication appliance, the entire string of 128KB will be stored as a non-duplicate segment, while ZDLRA will store only the 3 changed blocks (24KB).

Variable Length De-Duplication

Some de-duplication vendors support what is known as “variable length” de-duplication, which simply means the segment size is tunable.  For de-duplication to work, the segment size must be consistent.  For example, a string of data 64KB in length logically cannot equal a 128KB string of data.

We have tested de-duplication of Oracle backups using 8KB segment lengths.  While tuning a de-duplication appliance to use an 8KB segment size will equal the effective de-duplication rate of ZDLRA, we have found that performance suffers greatly.

ZDLRA is Cost Effective

The efficiency of ZDLRA makes it more cost effective than other solutions on the market. ZDLRA only captures the specific CHANGED data each day, resulting in the smallest possible volume of data stored.  ZDLRA is not the lowest cost on the market when measured by cost per terabyte, but ZDLRA needs fewer terabytes than other solutions. In most cases, ZDLRA needs 1/3 less storage space than competing products on the market, regardless of the competing product architecture.  Less space means lower cost as we see in the following example:

Screen Shot 2018-02-21 at 11.49.13 AM

Less space means a lower acquisition cost (purchase price), lower cost of services such as support, etc.  Less disk space means less physical space in the data center, lower costs for electrical power, etc.

Solutions such as Replicated Snapshots and De-Duplication appliances simply cannot match the space efficiency of ZDLRA, giving ZDLRA the edge from a cost standpoint.  ZDLRA then offers numerous advantages beyond simple storage savings and cost, driving more value than we covered in this blog post.