The road behind and under us with a look ahead...

29 July 2010

 

Here it is, half of 2010 is about over, and an article on trends. These are the types of things that come out in December along with new years resolutions and yet another fruit cake from the family. But I am writing about it now.

 

Many of you may know me from either prior services engagements or in some of the videos and papers written over the years.  The articles and videos I do are not required for my position at IBM but are part of a bigger picture of a personal mission statement:  To provide my knowledge of "anything computing" to anyone that needs background information, needs a quick "how do you do this?", or just needs a second opinion.  It is actually fun for me to teach and for those of you who are already quite knowledgeable in I.T., I would encourage you to be a mentor.  You'll be glad you did!

 

 

What seems to be happening... 

 

Here are some of the common requests, assistances, and trends:

(1) Installing DB2 for z/OS used with SAP

(2) Migrating DB2 to the next release be it DB2 for z/OS V8 or V9

(3) Aggregate performance tuning on specific applications running on z/OS

 

Of course, the continual challenges we still face:

(4) Too much to do and not enough time to do it

(5) People doing the work have not done it before

(6) Lack of existing documentation about processes

(7) Lack of training

 

 

...and some ways to overcome

 

Let's take a real quick look at some ways to address these 7 items listed above. In spite of the issues we face, there is still an incredible amount of information, tools, and techniques available free to help overcome many of these challenges.

 

For those involved with installing DB2 for z/OS with Cognos, a Redbook has been completed called "Housing Transactional and Data Warehouse Workloads on System z"

(http://www.Redbooks.ibm.com/redpieces/abstracts/sg247726.html?Open)

 

An older Redbook relevant to DB2 for z/OS V9 and SAP, check out "Best Practices for SAP BI using DB2 9 for z/OS" (http://www.Redbooks.ibm.com/abstracts/sg246489.html?Open).  An update was made to "Enhancing SAP by Using DB2 9 for z/OS" on April 10, 2009 (http://www.Redbooks.ibm.com/abstracts/sg247239.html?Open)

 

With regards to DB2 for z/OS release information, look at "DB2 9 for z/OS Technical Overview" (http://www.Redbooks.ibm.com/abstracts/sg247330.html?Open) and "DB2 9 for z/OS Performance Topics" (http://www.Redbooks.ibm.com/abstracts/sg247473.html?Open).  For a nice presentation on DB2 for z/OS V10 look at Bob Rogers SHARE presentation (http://ew.share.org/client_files/callpapers/attach/SHARE_in__Seattle/S2209RR131512.pdf).

 

If you are new to DB2 for z/OS, make sure you search SHARE and IDUG sites for specifics.  Of course, the challenge is manipulating search engines to find items you're looking up.  If you live and work, or can find the time, join a local Relational User Group (RUG).  There are several RUGs that actually publish presentations on the web.

 

For performance topics on DB2 for z/OS, look at SHARE presentation "Data Gathering for DB2 Performance Tuning and Health Checks" (http://ew.share.org/proceedingmod/abstract.cfm?abstract_id=20482).  If you have any questions, please feel free to drop me an Email at jeffsull@us.ibm.com.

 

If you can get a class or some training, I strongly recommend taking a workload management course (WLM).  The course I would suggest is titled, "Basic z/OS Tuning Using the Workload Manager (WLM) (ES54)".  My main reason for suggesting this over taking a class in SQL (or some other DB2 course) is something I've seen over many years:

- If you talk strictly performance for DB2 with NO consideration of anything else, most performance issues are due to inappropriate buffer pool strategy, SQL-related issues, or "doing things the way we've always done it"..

- If you look at a system in a holistic fashion, most performance issues are also due to inappropriate buffer pool strategy, but additionally not knowing which objects are accessed the most, inappropriate service class policies in WLM, or SQL-related issues.

There is an "intersection" of these observations.  It is all about I/O for performance by either:

(1) Not getting the data fast enough.  Factors include inappropriate WLM settings for either DDF work or DBM1 address space or buffer pool contention such as pages thrown out before they can be used (ever see those negative BP hit ratios?)

(2) Getting the data fast enough but seeing the same objects over and over.  Factors include inappropriate buffer pool strategy for the work performed, buffer pool settings such as VDWQT and DWQT in clearing dirty pages, or legitimate SQL issues getting the same data over and over (ad nauseam..  such as a tablespace scan). 

 

We live in some tough times and many for you are doing double-duty or have been drafted from another technical group. Or many of you lack adequate documentation or processes.  And there is also the need for an occasional "surge" to get a project completed.  This is what my organization does - by providing this short-term relief.  An added benefit is that we create working documents for the work we are brought in to perform - a big plus for any customer.  We can build specific documentation describing, for example, the process of installing or migrating DB2.  In addition to hands-on experience, we provide checklist and the opportunity of getting immediate feedback when questions arise during the process.  Finally, there is the "knowledge-transfer" aspect.  In short - if it is on a z/Series machine, our organization can help you do the work (including zLinux and DB2 for LUW) to meet your project assignments.

 

A quick look ahead

I wish I had suggestions on the workload.  Putting a plan into action for some of the catch phrases like "Work smarter, not harder", "Think outside of the box", and "Work/Home Life Balance" are much more difficult than we are lead to believe.

 

I have a bit of a different view on this.  Think of yourself as the human manifestation of a mainframe with WLM.  We apply a service policy on the work we are responsible for doing but, like it or not, our MIPS have to take a break.  Of the work you do, find those items which can be automated.  When I was responsible for 18 subsystems many years ago (prior to automatic space management), there was no easy way to find objects close to running out of space and objects requiring maintenance REORGs - so this was automated.  It took about a week of time, but when it was completed my automated routine would find the objects tight on space and growing along with providing the tablespaces and indexes in need of a REORG.  Every Monday morning, my email account would receive this report so what used to take me 8 hours of analysis and about 4 hours to schedule (taking me into Tuesday afternoon to complete) could be completed by noon on each Monday.  My point - automate the simple, repetitive, high-time processes.

 

But to answer this question of the look ahead, there are some exciting tooling coming down the road.  Take a look at Optim solutions at http://www-01.ibm.com/software/data/optim/.  A real cool tool is Optim Query Tuner for z/OS and Optim Query Workload Tuner for z/OS. Information can be found at http://www-01.ibm.com/software/data/optim/query-tuner-z/ and http://www-01.ibm.com/software/data/optim/query-workload-tuner-z/.  There is a very nice developerWorks article called, “Tuning SQL with Optim Query Tuner”. This and can be found at http://www.ibm.com/developerworks/data/library/techarticle/dm-1006optimquerytuner1/index.html.

 

Solid-state devices (SSDs) are also coming.  An interesting Redbook called "Ready to Access DB2 for z/OS Data on Solid-State Drives" (http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/redp4537.html?OpenDocument).  I know - nothing new here and a "No duh, Jeff, this is a natural progression".  But I would like to caution that this, like some of the efficiencies of DASD microcode and caching, can only go so far.  Bottom line: it improves random access but not a huge gain for large swath of I/O reads.      

 

Jeffy’s caveat:  The following paragraph is my personal opinion and does not speak of any inside information.  Call it my “hope” for the future.

 

Putting on my wizard hat, look to a future where performance tooling will start to blend; where performance tools will continue to evolve for both DB2 for LUW and DB2 for z/OS to streamline end-to-end analysis of performance issues. Perhaps we will see a new future of integrated tooling across operating systems and platforms with a single dashboard providing built-in autonomic functions. This may not be around the corner but it will be a game-changing solution!

 

So in summary, I'd like to paraphrase a quote from "The Man with One Red Shoe": 

 

Hold your head up high.  You're in I.T. !

 

HOME | Search