Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Top 5 DB2 Support Nightmares 2018 #2


Published on

In part 2 of our new series of DB2 Support Nightmares we look at the implications of a “Suck it and See” development approach

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Top 5 DB2 Support Nightmares 2018 #2

  1. 1. Top 5 DB2 Support Nightmares & How to Avoid Them - 2018 #2
  2. 2. Part 2 – Suck it and see development We have many clients who have rigorous change and version control procedures, where nothing goes into a downstream environment until it’s been tested and signed off and where database changes to give performance improvements are handled by the DBA staff who are carefully checking for adverse impact from any changes. And we have many clients who have none of the above….
  3. 3. However, everyone recognizes that there are situations where agile and immediate changes are imperative. The danger is that the Prod environment (or even Pre-Prod or QA if these are crucial environments where the test results are taken as being a realistic representation of what will occur in Production) is treated as a sand-box. It’s easy to be critical if you’re a database purist
  4. 4. This query is running really slowly I wonder if a new index might help (creates new index and re-submits query) No, that made no difference. Maybe I’ll Google it. OK, let’s try setting Database Manager Configuration parameter obscure_and_poorly_understood_parm to YES No, that hasn’t helped. I wonder if I create a small table with just the bits I need and query that (submits massive INSERT INTO TABLE statement using a SELECT on the base table with no usable index to service the WHERE clause)
  5. 5. So then…. At the end of this exercise not only do you not have a solution to your performance problem but you have a number of changes that may have made things worse rather than better. It’s very rare that anyone retraces their steps and removes all the changes they attempted in an effort to solve the problem.
  6. 6. The Moral of the Story The first moral of the story is don’t leave this sort of task to someone who isn’t an experienced DBA. Performance tuning is a specialist skill, some might say a Black Art, and it’s unfair to offload this sort of work on someone without the necessary skillset and the time to do it properly. I’ve been in IT for 30 years but I don’t expect someone to hand me a screwdriver and a soldering iron and ask me to rewire their mainframe.
  7. 7. The Moral of the Story The second moral is don’t leave this task so late in the cycle that it is occurring in Prod. Performance tuning should be part of the development cycle; occurring in the early stages of the project and forming part of the release checklist.
  8. 8. The Moral of the Story That’s not to say you can fully insulate yourself against Production outages caused by performance issues, so (and this is the third moral of the story); get some monitoring software running in your Production database and have someone take a cool, careful look at the figures on a regular basis to try and head off any performance issues before they become a panic situation.
  9. 9.