Or - In the Club: More Detail
(I wrote a Blog a while ago, and it was suggested I add my more detailed version..so, here you go!)
The big boys on System z platforms have decades of experience tuning and using techniques to optimize mixed workloads and databases. Workload Manager and Static Plans for DB2 are examples of component function which are widely used on System z but not always leveraged well during integration with the distributed world. DB2 static plans are used to improve database workload performance, management, and security. Workload Manager assures high utilization, high service levels, and high value of the System z platform. How can distributed applications leverage them for their benefit? Let’s take a look at both areas.
Workload Manager looks at transactions, jobs, and even database work then lets them run and use resources based upon priorities, profiles and things like intended service levels and velocity through the system. As e-business applications came along, and the new transaction manager on the block, Websphere on z, joined CICS, IMS, and JES2 as a transaction manager and was integrated as a full member of ‘the club’. So Websphere on z workload, and its associated DB2 work, could then be managed, secured, and line up to get the kinds of resources it needed. (See Say What? for a great overview of ‘the good old days’, packages, plans and such.)
Distributed Workload Needs a Ticket:
Unfortunately, as things evolved for the e-business applications (and here we mean both Java and .NET workload) off of System z, the kind of integration necessary to achieve the same kinds of benefits sometimes needs a little help. It turns out that when requests are sent to DB2 they tend to show up in the hopper as undifferentiated pieces of work --unless the Java programmer knows to specify an indicator (as SAP does by specifying differentiating parameters such as the correlation ID). Usually though, there is no ‘handle’ for DB2 to differentiate the incoming workload (or for subsystems to handle Workload Management, Monitoring, Reporting...). So, by default, everything settles in to a low priority and a low level of service. (For DB2 the default service class is 4 --which is low!).
If you don’t have that ‘handle’, System z can’t prioritize the workload so it gets its fair share competing with all the other workloads running on System z. Without the ‘handle’, you guarantee your incoming distributed work is at the bottom of the bucket!
Another large issue affecting overall performance for distributed Java workload using DB2 on the mainframe (and by the way, .Net applications implement that scenario more than to any other IBM database), is taking advantage of the first technique mentioned above: the use of Static Plans.
In the distributed environment where the paradigm is for interpretive rather than compiled programs, it is tough to even think of techniques using a pre-compiled approach as an alternative. However, there are ways to leverage the concept of a ‘static plan’ for DB2 by distributed workloads too.
Welcome to the Party: PureQuery:
PureQuery now enables distributed applications to bind static packages set up ahead of time.
A package, also called an access plan, can be thought of as a precompiled subroutines with the information to line up execution details ahead of time, (such as: access paths, indexes, etc ). Once created, the packages can then be stored in the DB2 catalog and are bound to a program. Note: Using packages can also add a layer of abstraction and security to DB2 access.
See some good references from developerworks and DB2 Magazine;
These static packages can be created and waiting on System z in the DB2 catalog for the Java applications to ‘call’ or connect to and use through a binding process done by the Websphere distributed admin or programmer. (By the way this is done through techniques that require far less heavy lifting than an earlier technology called SQL J employed. See some good tutorials on PureQuery again in DB2Mgazine and DeveloperWorks.).
Gift Bags for All:
If both approaches are used, distributed Java workloads can then benefit from the serious ($$) performance, security, and management effects of engaging DB2 and Workload Manager, and from using those static packages waiting at the ‘Enterprise Data Hub’ (System z).
But wait a minute.. there’s more…
Okay, that sounds great, but let’s stops and thinks about this. Put another way, what if you could now have the assurance that your database access on the mainframe from distributed applications could now have much better performance, much more predictable performance, like on the level of the service level agreements they use up there?
What if the mainframe land of sometimes ‘unknown-ness ‘ for distributed folks was something that now be counted on to give you fast data from lots of data sources, like federated, like services, like real time… and across not just your infrastructure of distributed and centralized, but across partner networks??
Since many application suites are on distributed platforms, how might your plans be affected for BPM, real time intelligence, MDM….? (See the article on MDM and PureQuery on Developerworks).
These are surely some things to go back and look at… don't you think?