Getting the Most out of DB2 Support

Posted by

This post is inspired by an email from a reader.

Let me first say that every software support team everywhere is complained about by someone. I’ve dealt with Oracle support, so I appreciate DB2 support all the more.

For those of us who work with DB2 every day and have for 5 or 10 years or more, we really do know more about some things than the first line support personnel. This can make it frustrating to talk with support – after we’ve nailed the problem down pretty well, it seems like they ask for all kinds of information that we may not think they need.

Remember that support gets a lot of calls from first-year DBAs or people who are not even DBAs asking some pretty basic questions. They also have to make sure they’re covering the most basic things before moving on to more complicated potential causes.

The Very Basics

If you’ve never called support before, there are a few things you must have before calling.

  • The number to call – which varies by geography of where the licenses/support contracts were bought
  • Your IBM customer number
  • Operating system being used and version
  • DB2 version and Fix Pack
  • A very short description of your problem
  • Severity level of the problem (from 1-4, with 1 being the most severe, and be sure to tell them if you’ve got a production system down)
  • Your e-mail address
  • Your phone – where you can be reached 24/7 if it’s a Sev 1

When you call the number, you’ll have to press a few numbers to get to software support for Information Management or DB2. The person who first picks up will ask you “Is this a new or existing PMR/Issue?”. This front line person knows how to spell DB2 and a bit about determining which branch the PMR needs to go to. But they are basically just an operator. Once they have the basic information, they will probably put you on hold for a minute or two and then come back to you with a PMR number and a branch number. Be sure to write both of these down. After that, one of two things will happen depending on the time of day, severity, and how busy they are. They will either transfer you directly to someone who actually knows db2 or they will tell you that someone will call you back.

Even if it’s a direct transfer, you are not going to get an exact answer in just one call. They will ask for information – most frequently details on your problem and output from this command:

db2support

Be nice to this person, because they are going to be coordinating your PMR – talking to others, and getting you the attention you need. These people have varying levels of skill, but they know the processes and have the procedures to bump your PMR up the chain. Gathering the inital information for a PMR is an excellent task for a junior DBA or for someone who wants to learn to become a DBA.

My Experiences with Support

In 11 years as a DBA, I’ve had support open fewer than 5 actual APARs based on problems that I’ve found. On a number of occasions, they’ve pointed me to a specific APAR that already exists that exactly describes my problem. A few times I’ve had to get a special build for that APAR because either it wasn’t in a FixPack yet or it was in a FixPack that IBM itself or another vendor would not let me use. A number of times, they’ve suggested a FixPack without being able to point me to a specific APAR. More often than not, they point out some small thing I’ve missed. I’ve found that the longer I’ve been a DBA, the longer I go between times I have to open a PMR.

What to do Before Calling Support

Support should not be your first source on an issue. I’ve usually got at least 4 hours research into a problem before I call support. First, look in the Info Center. Quadruple check everything. Look in db2diag.log. Search the Information Management support portal. Google the issue. Have another DBA look at it. Do your due diligence first. I always feel embarrassed when they point out some dumb mistake I’m making, because that means I’m wasting their time and mine.

When to Call Support

The best situation for calling support is when you truly feel that you’ve found a brand-new problem in the db2 code. Next best is when you’ve found a APAR that you think describes your problem, but you need help confirming that it’s that APAR or a special build to resolve that APAR. You should also be calling them when you have applied all of your resources and your fellow DBA’s resources and are just lost on what the issue is. Repeatable problems are much easier to get support’s help on, so try replicating the problem before calling.

When to not Call Support

Don’t call support as your first action on encountering a problem. Also don’t call them on a problem that is clearly an application problem – they won’t be able to help you. I frequently have to tell Service Managers that I don’t recommend opening a PMR with DB2 support because the problem is so clearly at the application level. A performance problem is also a bit of a stretch unless it is one that you can clearly track back to the DB2 code or that you suspect is wholly within DB2 and not a matter of how your application is written – deadlocks are not the sort of thing they’ll be able to help you with.

Escalating

If you’ve tried your best, and are providing everything that they’re asking for, and they are not responding in a timely manner, or they just don’t seem to get it after much patient trying, then you can request that your PMR be escalated to a duty manager. You can do that by calling the same number you called to open the PMR in the first place. You may also leverage other IBM contacts in that scenario – the sales person who you worked with on licensing or anyone else you may know.

Opening PMRs Online

I have been talking about calling support up on the phone. There’s a reason for that – my clients own their own software, and it’s much easier to open a PMR via phone if you’re not the main point of contact at your company for licensing. Opening PMRs online may require someone at the company that bought the licenses to approve every PMR. Calling on the phone is less likely to require approval of the person owning the licenses. I therefore just about always do it via phone. If anyone has experiences here, I’d love to hear about them in the comments.

Ember is always curious and thrives on change. She has built internationally recognized expertise in IBM Db2, and is now pivoting to focus on learning MySQL. Ember shares both posts about her core skill set and her journey learning MySQL. Ember lives in Denver and work from home

2 comments

  1. Hi,

    Is Package bind always required two steps (first step is package bind and second step is plan bind)? and also could you please explain more on collections and pklist. I’m tired of browsing to get this answer. Kindly help me, i’m so much hunger to know on this? Thanks

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.