Top 5 DB2 Support
Nightmares & How to
Avoid Them - 2018
Part 1 - Single User Access
When you install DB2 you
obviously have an all-powerful
instance owner ID and password.
The best option, once you’ve got
DB2 up and running, is to ensure
that no-one, except essential
support staff, has access to it.
From past experience we have come across DB2 sites that have
only the one userid for all users to use and, frighteningly, use the
same password in all environments.
What this means is:
• If you’re a user who has ever connected to
the DEV environment, you can now get
straight in to Production
• You can (if malicious) harvest sensitive data
or drop critical objects
• You can (even if entirely benign) put in place
features or structures that you think might
help Production run, but which will actually
knacker it completely
You have the ability to submit ad-hoc queries that you think might be
handy but that will actually stop your Production services dead:
“I wonder how many rows are in that table?
Maybe if I submit SELECT * FROM
Largest_Table_in_the_Database it will tell me.
Well, it doesn’t look like that’s going to respond
any time soon; guess I’ll go home and see if its
worked in the morning”
About 3 a.m. the entire batch suite comes
down with a series of locking and timeout
And finally, of course, no-one can tell who did
any of this because everyone is using the same
The Moral of the Story
Build a security strategy into your
database from the word go.
Design a set of users, groups and roles
and implement them in Dev.
Use that design as a template for your
other environments and don’t let
anyone have any more database
authority than they actually need to do