Design considerations

DD Boost technology

During the database backup operation with Oracle RMAN, the Oracle database sends backups to the Data Domain system through the Fibre Channel or Ethernet network. We selected DD Boost over Ethernet protocol to take advantage of the proven performance and deduplication features of DD Boost technology. In this configuration, both the DD Boost feature and distributed segment processing (DSP) are enabled. DD Boost software runs on both the Oracle database server and the Data Domain system. As shown in the following figure, for each backed-up segment, the DD Boost software determines if the segment is unique (that is, it has not been previously stored in the Data Domain system). When DD Boost confirms that the segment is unique, the segment is compressed and transferred over the network and stored on the Data Domain system. The deduplication and compression processes ensure that only unique data is compressed and sent over the network and stored in the Data Domain system.

During the first full database backup, because no data from this database has been stored in the Data Domain system, all the data segments from the backup are unique. As a result, each data segment from the first full backup is compressed, sent over the network, and stored in the Data Domain system. Starting with the second full backup, DD Boost software backs up only those unique data segments that have not been previously stored in the Data Domain system.

Figure 13.     DD Boost software determining if segment is unique

Storage and file system

The Data Domain system includes a set of disks for storing database backups. During the initial Data Domain configuration, we assigned these disks to disk groups so that they can be used to create file systems for storing database backups.

The Data Domain DD9300 system used in our testing has one head unit with 12 disks, and four disk enclosures (DS60) with 60 disks each. In the head unit, four disks are used as the system disks and eight disks are used as cache tier. From the four disk enclosures, we created 15 disk groups, each with 14 disks plus one spare disk. Each disk group has a 38.21 TiB usable storage capacity. All 15 disk groups provide a total of 573.15 TiB usable physical storage capacity that can be used to store the database backup images.

During the Data Domain system initialization process, we enabled the file system by running a file-system-enabling command on the Data Domain system command line. The following command shows an example of the space usage of the file system in a DD9300.

Figure 14.     Example of space usage of file system in DD9300

Mtree and storage unit

We created one storage unit on the Data Domain system to use with the database application agent on the database server to back up the database files, as shown in the following example:

Figure 15.     Storage unit rman created on DD9300 for backup and recovery testing

The storage units are shown as a logical partition of the Mtree file system:

Figure 16.     Storage units seen as logical partitions of Mtree file system

To implement the Oracle optimized deduplication feature in a Data Domain system, we set the value of the app_optimized-compression option to <user_name> on the Mtree with this command:

mtree option set app-optimized-compression <user_name> mtree <storage_unit_name>

For example, we ran these commands in the command line on the Data Domain system for storage unit rman:

$mtree option set app-optimized-compression oracle1 mtree rman

IP network design

The Data Domain appliance connects to the Oracle database server within the MX7000 infrastructure chassis of this reference architecture via four front-end 10 GbE interfaces spread across two NICs installed in the DD9300 system. These four front-end 10 GbE interfaces within the DD9300 connect to the same spine switches to which the MX9116n network IOMs within the MX7000 chassis connect.

Within the DD9300, we created a new network interface group and added these four front-end interfaces to this group as shown in the following figure. So that the Oracle database server could communicate with the backup appliance, we configured these DD9300 front-end interfaces within the same IP network address range as the Oracle database public network IP addresses.

Figure 17.     DD9300: IP network setup using interface groups

Note: Under Protocols -> DD Boost -> IP Network as shown above, we added the Oracle database hostname under Configured Clients and ensured that it used the 10 GbE Interface Group we had created.

To register and connect the database server as a client with the Data Domain system, we selected the static IP address assigned to one of the interfaces on the Data Domain. By internally enabling load balance and failover capability among the network interfaces configured within a group, the interface group configuration provided a robust network bandwidth and a highly available backup network between the database servers and the Data Domain system.

RMAN backup and restore parameters

To test backup and recovery, we used the Use Case 1 - Oracle OLTP database setup described in Chapter 3 Validation Test Goals, Configuration, and Use Cases. We used the following Oracle RMAN settings in our backup and restore tests of the Oracle OLTP database.

Table 21.        Oracle RMAN settings

Test methodology and results

We performed various backup and recovery tests on the DD9300 system using the Use Case 1 - Oracle OLTP database setup described in Chapter 3 Validation Test Goals, Configuration, and Use Cases. The following descriptions provide the details of three such backup and recovery test cases or use cases that were conducted in this reference architecture.

Use Case 1: First full backup of standalone OLTP database

We performed a full backup of a 1.8 TB Oracle database using DD Boost software.  DD Boost integrates with RMAN and enables host-based deduplication of database backups to the Data Domain appliance. A full backup eliminates reliance on other backups, simplifying backup management and restoration after an unplanned failure.

In this use case, we used the DD Boost appliance to perform the first full backup of the production database. In the tested configuration, we used a 4 x 10 GbE LAN connection to the DD9300, as shown in the following figure.

Figure 18.     Use case 1: First full backup architecture diagram

The first full backup of an Oracle database is entirely unique; therefore, all the data is protected on the DD9300. The value of host-based deduplication begins with the second full backup. In the second backup, only the new or modified data is unique; therefore, the DD Boost software sends only a small subset of information to the Data Domain system for protection. Although the first full backup is unique, after the data has been protected on Data Domain, it then is compressed.

The figure below shows the local compression factor savings based on the default algorithm (maximized throughput) on the Data Domain system. A relationship exists between the amount of unique data and the local compression factor: The greater the amount of unique data, the more opportunity for compression, and the higher the compression factor. For example, the first backup consists of entirely unique data and has the largest compression factor.

Figure 19.     First full backup compression ratio

This compression saves significant space on the Data Domain system. Dell EMC engineering test results show the compression factor was 1.4x:  a 29.9 percent space savings for the first full backup. The reference architecture setup achieved this full 1.8 TB backup and compression in 38 minutes, exhibiting a backup throughput of 815 MB/s.

Use Case 2: Second full backup of the standalone OLTP database

The goal of this use case was to perform a second full backup of the same Oracle database to show the value of DD Boost host-based deduplication. Host-based deduplication means DD Boost software communicates with the Data Domain system to determine if a data block is unique. If the block is unique, it is sent to Data Domain system for protection. If the block is not unique, then it is not sent to Data Domain. The value of host-based deduplication is that it saves network utilization and space on the Data Domain appliance. DD Boost technology works transparently with RMAN, which means that RMAN sees a full database backup on the DD9300. 

Before running second full backup, we modified the existing data by running a few transactions. To simulate real-world conditions, we used HammerDB and ran OLTP transactions for 10 minutes to create roughly five percent modified data. This modified data consisted of one percent inserts and four percent updates to ensure that the DD Boost software backed up new and modified data.

The following figure shows the use case 2 architecture.

Figure 20.     Use case 2: Second full backup with 5% data modification

The following figure shows the local compression factor savings that are derived from the default algorithm (maximized throughput) on the Data Domain system for the second full backup. Tests show that only unique data was sent to Data Domain, and after local compression the final size was 109 GB. DD Boost host-based deduplication combined with local compression on Data Domain saves a significant amount of space. Performing daily full backups is easy because the space that is used on the Data Domain system is a small subset of the actual database size.

Figure 21.     Second full backup compression ratio

Compression and deduplication save significant space on the DD9300. Dell EMC engineering test results show the compression factor was 16.7x:  a 94 percent space savings for the second full backup.

The second full backup took significantly less time as compared to the first full backup. The second full backup of a 1.8 TB Oracle database took just 25 minutes—13 minutes less than the first full backup (38 minutes) and exhibited backup throughput of 1,191 MB/s. It is important that the time required for database backups remains predictable and minimized to reduce the impact to the business.

Use Case 3: Restore and recovery of the OLTP database from full backup

Unplanned failures can represent significant risk to the business by stopping back-office operations, thus impacting revenue. Backing up and protecting databases prepares the business to recover from an unplanned failure. In this test, we performed a restore from the Data Domain system backed up to the Oracle Database servers. The goal of this use case was to test how fast and how successfully this reference architecture can restore and recover a 1.8 TB Oracle database that was protected using the Data Domain system.

The following figure shows the use case 3 architecture:

Figure 22.     Use case 3: Restore fully backed up database architecture diagram

In this use case, the total time captured includes:

• The time taken to ‘restore’ which includes copying the fully backed up database files from the DD9300 back to the primary Oracle database, and
• The time taken to ‘recover’ which includes the application of online and archived redo logs on the restored data using RMAN and opening the database for processing.

In this test, our 1.8 TB Oracle database was fully restored and successfully recovered from backup in 25 minutes with just 15 percent average CPU utilization on the Oracle database server.