Monthly Archives: June 2014

Axxana @ Northern California Oracle User Group

Axxana @ Northern California Oracle User Group

I recently attended the NoCOUG Spring Conference. NoCOUG stands for Northern California Oracle User Group. Axxana was one of the sponsors of the event and we had the opportunity to engage in the most important activity – meeting our end users. Unlike other, bigger, vendor focused, events, the Oracle User Group gatherings are a great opportunity to intimately spend time with people who are actually the ones using your product at the end of the day. We had the pleasure to spend quality time in lengthy conversations about the concept of Zero Transaction Loss, about our new Phoenix System for Oracle solution and about the Axxana Black Box. For some, it was the first time they have heard of the concept. With everyone, we were able to dig deeper into the different Data Guard topologies they are deploying and disaster scenarios they are concerned about. The day passed by so quickly. It was packed with DBAs, who came to educate themselves on the latest and greatest we can offer them and the organization of the event was impeccable.                                 Here are a couple of the topics of conversation that repeated themselves time and time again during the day. The Conversation Begins With a Few Simple Questions  Of course, everyone that approaches our table is immediately intrigued. They have never seen a Black Box like device in their data center, unless of course, they own the Axxana system, and they equally never dreamed of achieving zero loss of transactions when a disaster hits their data center. We never want to waste anybody’s time, so we ask a few questions, to help us qualify our guest’s business need for the Axxana system. The first question would be if they are replicating their applications’ data remotely, meaning, do they have another one or more data centers with a redundant setup, to which they can failover, in case a disaster hits their primary site. Most of our visitors do replicate, which is no surprise, given the increasing awareness of organizations today of the absolute criticality of having a strong DR/BC plan established. Then we ask whether they replicate using Storage based replication or Data Guard. Here, it is interesting to observe that most people we talk to indeed replicate with Data Guard, rather than with Storage based. This is somewhat of a shift in the direction of the wind, if you will. In the past, numbers were very strongly tilted towards Storage based replication. Not anymore. Be it Oracle, who are strongly recommending that their customers use Data Guard to replicate and maintain full consistency of the database, or be it the DBAs who are demanding to control the entire gamut of the database’s operation, including Disaster Recovery. Either way, Data Guard is proliferating. Truth is, we don’t care. Why? Because as you will see, with the new Phoenix System for Oracle, we protect both Databases which are replicated using Storage based replication and databases replicated using Data Guard. Next on our quick list of questions would be what the distance is between the two sites, primary and DR. Here, we establish the type of replication their organization would be using. Sure, we can ask whether they replicate Synchronously or Asynchronously, but by asking about the distance, we can establish the “level of pain”, if you will, that they will be experiencing and the level of risk they are taking when replicating Asynchronously. I will not go too deep into the differences between Synchronous and Asynchronous replication here, but in a few simple words – Asynchronous type replications always lose most recent data and transactions and therefore carry a very real risk of inconsistency among the different applications in the secondary site, resulting in inability to recover in a timely manner.  On the other hand, Synchronous replication is limited to short distances and therefore requires a nearby data center to be part of the topology, cost of which would be prohibitive. Synchronous replication also requires very costly communication lines, the likes of Dark Fiber to carry data between the two data centers. Most DBAs we talk to use either the Maximum Performance or Maximum Availability modes, with both, for all practical matters, baring the risks of Asynchronous replication – losing last transactions upon disaster and posing a significant risk of applications inconsistency and ability to failover in a timely manner. So we have qualified that our guest is indeed replicating her critical databases remotely, from one data center to another. It is not complicated – if you are using Oracle for your databases and are replicating asynchronously – you should listen to our story. Simply put: Zero Transaction Loss, Full Consistency across all applications, guaranteed swift and painless recovery.                                           What is The Phoenix System for Oracle?  The Phoenix System for Oracle is our brand new member of the Phoenix System family. It is dedicated to Oracle databases and any application running on the Oracle infrastructure. Axxana started its journey with a tight relationship with EMC. We worked on our first product for several years, both designing and developing the first ever “Black Box” hardware, built specifically for the Enterprise, as well as a truly seamless integration with EMC’s RecoverPoint replication platform – the Phoenix System RP. We quickly became an EMC Select partner and started our wonderful journey with the EMC teams. We grew from support of the VNX platform, to VBlock. We then expanded our supported array portfolio, under RecoverPoint, to EMC’s VMAX and last but not least, very recently announced support for VPLEX, EMC’s hugely successful Storage Virtualization and High Availability solution. We attracted customers from various verticals, including Government, Manufacturing, Retail, Financial and many others. The new Phoenix System for Oracle is our expansion, up the chain, from the infrastructure level, to the application layer. Whereas with the Phoenix System RP (for RecoverPoint), we provide bullet proof protection to any application running on EMC Storage or connected to EMC VPLEX, replicating with RecoverPoint, with the new Phoenix System for Oracle, we will be able to provide zero loss protection to Oracle environments utilizing any Storage and any Replication, including Data Guard. That is the rationale behind the Phoenix System for Oracle. I invite you to browse our recently updated web site and dig deeper into the Oracle story. Be sure to read our new white paper, dedicated to the Phoenix System for Oracle. The Exadata Angle When our table top visitors at the NoCOUG conference have deployed Oracle Exadata, things get even more interesting. Why, you ask? Because when your business is running on Exadata, you are replicating only with Data Guard and, as I mentioned above, most DBAs replicate with Data Guard using either Maximum Performance or Maximum Availability. For us, as some sort of a “Zero Data Loss Switzerland”, it is interesting to watch the growing fight between Oracle and EMC/VCE, over who wins the “Engineered System” battle in the data center. We don’t care who wins. We care about the end user and we want to make sure their business is protected with whatever infrastructure or application they are running. One of the “claims to fame” of the Storage vendors, in trying to fight off Oracle’s sweet Exadata deal, is that once you have deployed Exadata, you can’t completely protect your data in case of a disaster. I don’t know if this is true and why it would be true, but… with the new Phoenix System for Oracle, connected to Exadata and protecting its databases, we are eliminating this argument altogether. Exadata coupled with Axxana means zero transactions lost, no matter what Data Guard mode you are replicating with and how far your data centers are apart. The Next Conversation By now, we got our visitor’s attention. But this is not the end of the story. Here comes the punchline question. When you are using Data Guard and are replicating several applications, running on multiple databases, each database will run its own Data Guard thread. How do you guarantee, in an Asynchronous scenario (Maximum Availability or Maximum Performance), that your business will smoothly failover to the secondary data center when a disaster hits your primary site? Yes, each database will asynchronously failover to the secondary site. But your databases will each failover to a slightly different point in time, which means that your applications will each restart at the secondary site from a slightly different point in time. But, in most cases, your applications are interconnected, interdependent. If each application is recovered to a different point in time, how can you be sure that you will be able to failover your entire business operation right after a disaster?! There was almost consensus among our guests at the NoCOUG conference – you can’t be sure! Failing over most probably will become a manual process that may take a lot of time and severely impact the organization’s down time upon a disaster. Here is where Axxana comes in. If all databases failover with zero loss, it means that the secondary, DR, data center is going to be an exact mirror image of the primary data center, databases and applications, right when the disaster hit. This means that when you failover with zero loss, all of your applications will be completely synchronized and in a fully consistent state to the last committed transaction. There’s much more to say about this and again I would encourage you to take a look at our new web site and browse through the different documents and white papers we have prepared on the topic. NoCOUG Spring Conference was great. It was well organized and well attended. People were savvy and engaged and the conversations were very interesting and insightful. One particularly lucky participant went home with our raffled Amazon Fire TV…                                   We very much look forward to seeing you all at the next conference, on August 21st in sunny California! Eli    

read more »