Find Communities by: Category | Product


Bitly URL:


Tweet this document:

#VMworld 2014 public voting is now open. Please vote for your favorite sessions. #EMC #EMCElect


Follow us on Twitter:


VMworld 2014 looms, and the public voting for technical sessions is now open.


The following list includes EMC-sponsored sessions which are of interest to an Oracle audience:



There are a number of other EMC-sponsored sessions relating to Microsoft SQL Server and SAP HANA which are interesting, at least to me:


  • Session 1701 A Flash-Optimized Reference Architecture for Consolidating and Building a High Performance Virtualized Microsoft SQL Server Infrastructure on VMware
  • Session 2309 Reduce Your Business Risks and Lower Deployment Costs by Virtualizing SAP HANA
  • Session 1328 Choosing the Appropriate Storage Solutions for Microsoft Tier-1 Applications


Those interested in the Hadoop / OpenStack stuff might also enjoy these:


  • Session 1397 Benefits of Virtualizing Hadoop
  • Session 1314 Scaling Your Storage Architecture for Big Data - How the Isilon Server Fits Well with Virtual Hadoop Workloads


Public voting closes this Monday, i.e. May 12, at 5 P.M. PDT. Please vote early and vote often. Thanks!

Data Domain system : EMC Data Domain storage systems are traditionally used for disk backup, archiving, and disaster recovery. An EMC Data Domain system can also be used for online storage with additional features and benefits. A Data Domain system can connect to your network via Ethernet or Fibre Channel connections.

Data Domain systems use low-cost Serial Advanced Technology Attachment (SATA) disk drives and implement a redundant array of independent disks (RAID) 6 in the software. RAID 6 is block-level striping with double distributed parity. Most Data Domain systems have a controller and multiple storage units.

A Data Domain system is:


  • A storage system used for backup and archiving workloads that:

o   Performs high-speed deduplication to maximize storage efficiency

o   Ensures recoverability of data through integrated data integrity intelligence

o   Can replicate data automatically for disaster recovery

o   Easily integrates via Ethernet and Fiber Channel into existing backup infrastructures

  • Safe and reliable

o   Provides Continuous recovery verification, fault detection, and healing for end-to-end data integrity


DD Boost : EMC Data Domain Boost extends the optimization capabilities of Data Domain systems for other EMC environments, such as Avamar and NetWorker,  Greenplum, Quest vRanger, Oracle RMAN etc. DD Boost is a private protocol that is more efficient for backup than CIFS/NFS. DD Boost shares the work of deduplication by distributing some of the processing with the application host. This feature is called distributed segment processing (DSP). The DD Boost protocol enables backup servers to communicate with storage systems without the need for Data Domain systems to emulate tape. The application host is aware of, and manages replication of backups created with DD Boost. This is called Managed File Replication.


There are three basic features to DD Boost:


  1. A private protocol that is more efficient than CIFS or NFS. DD Boost has a private, efficient data transfer protocol with options to increase efficiencies.
  2. Distributed segment processing (DSP). An optional feature to DD Boost shares portions of the deduplication process with the application host, improving data throughput. DSP distributes parts of the deduplication process to the NetWorker storage node using the embedded DD Boost Library (or, for other backup applications, using the DD BOOST plug-in), moving some of the processing normally handled by the Data Domain system to the application host. The application host performs a comparison of the data to be backed up with the library and looks for any unique segments. Thus it sends only unique segments to the Data Domain system.
  3. DD Boost provides systems with centralized replication awareness and management. Using this feature, known as Managed File Replication, backups written to one Data Domain system can be replicated to a second Data Domain system under the management of the application host. The application host catalogs and tracks the replica, making it immediately accessible for recovery operations. Administrators can use their backup application to recover duplicate copies directly from a replica Data Domain system.


Data Domain and Oracle Oracle RMAN is a built-in tool that allows the database administrator (DBA) to easily back up and recover data in an Oracle database. RMAN handles the coordination required to ensure that transaction integrity is preserved, and sufficient information is maintained to recover the database to any appropriate point. RMAN can create backup sets that comprise as much or as little recovery information as the DBA requires but usually include information from the database datafiles, control files, and redo and archived log files. RMAN supports performing backups to a local tape drive 1 a local disk, or a NAS device, as well as integration with traditional enterprise backup applications, as shown in the below figure



Benefits of using a Data Domain system as a target for Oracle RMAN By eliminating redundant data segments inline, Data Domain systems allow many more backups to be retained than would be possible using traditional storage. In particular, Data Domain systems use a variable-length segmentation process that is extremely efficient at finding identical segments within backups of monolithic files, such as Oracle datafiles.


The ability of the Data Domain system to store several weeks or months of full Oracle backups enables the DBA to implement a backup and recovery scheme with great flexibility and protection while consuming a minimal amount of physical storage. The integration of the Data Domain system into an Oracle/RMAN environment is seamless

Since the Data Domain system presents itself either as an NFS or CIFS shared storage server. Oracle/RMAN already supports and documents this type of installation for effective RMAN storage.


If an enterprise backup software solution such as Oracle Secure Backup or EMC NetWorker is already in use, the Data Domain system can be seamlessly integrated into this environment as well. In this case, the Data Domain system can appear as an SBT_Tape device or a disk device to the enterprise backup software solution.


For critical Oracle environments, it is a best practice to replicate the production Oracle data to a secondary recovery location. The DBA has many options to choose from, including technologies from Oracle such as Oracle Data Guard, solutions offered by primary storage providers, and third-party solutions. Data Domain Replicator software offers extremely bandwidth-efficient replication that is also easy to deploy, enabling DBAs to leverage RMAN to provide disaster recovery capabilities for Oracle databases.


The primary benefit of Data Domain Replicator is the fact that only deduplicated and compressed data is transferred across the network. Because deduplication is happening inline, replication takes place while the RMAN backup process is still active. As the RMAN backup process proceeds, the unique segments and metadata representing each file in the backup set are queued for replication to the remote site, -to- many cases, replication is completed within a short period of time after the initial backup completes.


References For additional information, see the following:


EMC Data Domain Family products and deduplication technology

EMC Data Domain solutions for Oracle

EMC Backup, Recovery, Archive solutions for Oracle EMC

Solutions for Oracle

EMC Data Domain Global Deduplication Array

EMC Data Domain Boost software

White Paper H11798 - Oracle RMAN Best Practices with Data Domain

This is a translated blog from the original blog of my colleague Mr. Makoto Miura (Makoto-san). This blog was also reviewed by Makoto-san and so I convey my utmost gratitude to him.


From my previous blog, we have understood the features and the benefits of storage based backup. Will not we now learn about some important points while using ASM? This time I would like to write an ASM related blog which is in continuation to my previous post Foundation of the storage based backup related to the Database.


Though ASM can be used both with block and NFS storage, I would like to talk about the block storage first. Of all the customers that I have worked with in Japan, I found that the majority of them are using block storage. I know of only 1 customer who uses NFS. In your environment, which storage option is most frequently used?


  • At the time of mounting the copied ASM DG to the production server, kindly rename the ASM DG.


In earlier versions of Oracle, we could start the multiple ASM instances on a single DB server box individually.  At the time of mounting the server for the purpose of copying ASM DG, it was possible to use the same name of the ASM DG. But in the new version of Oracle viz. Oracle 11gR2, in a single DB server we can start only ONE ASM instance. For this reason, before mounting the copied ASM DG, the name of the ASM DG needs to be changed. If we use EMC Replication Manager then the process of renaming the ASM DG name gets automated.


  • Maintaining the Consistency of the ASM DG


It is very important to maintain the consistency within DG when we build the DG from multiple LUNs. The metadata information (related to the ASM DG) is maintained within the DG itself. So, at the time of rebalancing, when hot backup mode is used, it is very important to maintain the write-order consistency in the LUN unit of the ASM DG. Within the LUNs of the EMC Storage, multiple logical groupings can be created, thereby the consistency is also maintained. This happens not only in high-end storage, but also in the mid-range storage. Yes, we can achieve this.


  • Important Points during the usage of ASM’s Failure Groups


If some users want to perform Data mirroring between different storage boxes while using ASM using the Failure Group, the data gets scattered between storages. In the below figure, the dispersion of data is getting depicted for ASM-DG#1 to two failure groups.




The above figure shows the self-setup function of ASM’s failure group creation.


Now, which process will be appropriate when we want to setup ASM-DG#1by storage copy?


To be frank, in the above setup oracle supports in maintaining the integrity of the whole setup and performs the copying operation. In short, one failure group’s copy looks insufficient here.


Let’s look into the various failure scenarios:-


  1. Within the failure group , one failure group got crashed.                                                                                    At this situation, the crashed Failure group is restored from the surviving failure group/s. Here storage based copy cannot be used.
  2. Within the failure group , two failure groups  got crashed.


That type of situation does not occur normally but even if we restore 1 failure group by the storage copy mechanism,  we are not sure whether Oracle DB can  be restarted or not as Oracle (formally) has not provided any guarantee for this operation. In the above picture, Oracle supports the storage copy only when  we create both Replica#1 and Replica#2 with the same timing and the consistency should also be maintained.  To recap, when we use storage based copy with ASM failure groups, we must take copy of all failure groups with consistency.


  • Why the customer wants to do ASM mirroring by using failure groups?


I feel the true purpose is to improve the reliability of the DB system by having redundant storage infrastructure.  In this situation, we can propose many alternatives, such as storage based mirroring between storage boxes; Appliance based mirroring (RecoverPoint) and Storage virtualization (VPLEX).

Filter Blog

By date:
By tag: