IDUG Europe - Day Two
The highlight of today’s sessions that I attended was “DB2 for z/OS vs. Oracle RAC: A Reality Check” presented by Namik Hrle of IBM. Hrle started off the presentation by admitting that there is a lot of confusion today and that even techies don’t know the benefits of DB2 for z/OS over Oracle RAC. He began by outlining the various ways that DB2 benefits by being designed for a single platform only. By taking advantage of synergies with the z9 hardware as well as the z/OS operating system, DB2 benefits from significant gains. DB2 inherits the benefits of the highly available, powerful mainframe hardware. The mainframe is built for handling multiple, mixed workloads – and DB2 gains that advantage by being engineered for the platform. Oracle RAC, in contrast, runs on more than 60 platforms. Therefore it cannot be engineered to take advantage of the specific features of any one platform.
DB2 also benefits for operating system synergies. DB2 is highly secure taking advantage of RACF, it benefits from the policy-based disk and tape management with virtualization (DFSMS), and it also benefits from WLM in being able to easily prioritize differing workloads across the system.
Hrle also emphasized that DB2 was architected from “day one” as an enterprise DBMS – it did not grow from a desktop DBMS to cobble on enterprise capabilities like Oracle.
The most interesting portion of the presentation was the comparison of DB2 for z/OS data sharing against Oracle RAC. Data sharing is more hardware than software; Oracle RAC is a shared-disk software implementation. DB2 data sharing uses a coupling facility to greatly reduce the number of links required for sharing – Oracle RAC has nothing like this. Hrle stated that Oracle RAC is not a bad solution for high availability, but it does not scale very well, whereas the DB2 for z/OS solution with data sharing scales very well. His slides go on to demonstrate what he means – I will not go into it here.
An additional point of Hrle's that I want to be sure to mention is that DB2 can run two different versions of DB2 against the same data. This can not be done with Oracle. With data sharing, one DB2 can be changed while the others continue to run all workload with no outages. Oracle RAC, on the other hand, must come down to make kernel changes or to apply security updated.
All in all, this was a very enlightening session.
Before lunch I had the opportunity to attend a vendor solution presentation from Software Engineering on their new Recovery Health Check for DB2 z/OS offering. Ulf Heinreich delivered the presentation in which he discussed how automated daily checks can assure that each DB2 database object can always be recovered reliably and as fast as possible. The Recovery Health Check product can tell you how long it will take to recover - and isn't that what your boss is always leaning over your shoulder to ask when things go awry? It also can produce management reports that indicate whether or not your system, applications, and database objects fall within the service levels required for recoverability.
Next up was a nice session outlining the many changes and implications of DB2 V8 online schema changes presented by Calene Janacek of BMC. She walked through the many new types of changes that are supported in V8, as well as the problems that can ensue as you change your schemas.
I also moderated another session today, entitled “DB2 V8 Optimizer: Early Prechecking SQL Performance” by Stephan Terhorst of LVM Insurance. Stephan is responsible for DB2 at LVM and he has designed and implemented the technical infrastructure for Authentication, Deployment, Performance and Monitoring. In this presentation, Stephan described the process LVM used to migrate their DB2 system and applications from V7 to V8 – and how they used Bind ImpactExpert to ensure the performance of their SQL as they migrated.
So it was another good day at IDUG – and I look forward to tomorrow being just as good... check in with me again tomorrow for an overview of day three at IDUG in Vienna.
this guy also claims that rac is not scalable. there are people with 50+ node clusters. the next oracle release will allow up to 128 node clusters.
oracle's shared everything environment. by far, this is the best method of implementing a cluster environment. you can add a node or take a node away dynamically without the need to redistribute the data. try that in the microsoft, and udb environments.
Replies to this comment