Sometimes I think that Db2 is one of the most widely used but least known databases. Db2 has been adopted all over the world and that scope is evident when the International Db2 User Group (IDUG) holds a technical conference on at least three different continents each year. I’ve traveled and spoken in North America and Europe but now I get to cross IDUG Australia off my bucket list.
When I was in my early thirties, I was diagnosed with a learning disability. This really put my learning style into perspective. Teaching myself via a book was incredibly hard, and still is in some ways. Where I thrived was with hands on labs and engaging speakers.
Recently I was forced outside my comfort zone and asked to vet various open source BI tools. I was a report developer in a past life, a database administrator supporting datamarts at various employers, and even supported Cognos backend databases. I thought my past experience gave me an edge when it came to evaluating BI tools.
It’s that magical time of year again.
With the development and adoption of automatic storage the art of the redirected restore is going the way of the dinosaur. For those with systems that are running the tried and true (and deprecated) DMS (Database Managed Storage) table spaces a redirected restore can be a lifesaver.
When the client considers high availability and disaster recovery, they often do not know what they are talking about. Many times the client may be dropping buzzwords like “five nines”. To them this is the definition of disaster recovery. In other cases, they are thinking of a worst-case scenario where a whole data center falls off the face of the earth and they need high availability.
I thought it would be relatively easy to investigate encryption for our environment. I was wrong, was just plain confusing. This was not because encryption is complicated per se, but that a DBA really needs to have a good understanding of business needs. If you don’t have this understanding, you can get lost in an array of options.
Today we are going to talk about some random DB2 features that can’t stand in a blog of their own, but are worth discussing nonetheless. These are tidbits I had discovered during “DB2’s Got Talent” presentations, IDUG conferences, or “Hey, look what I discovered” moments.
I’ve worked for larger companies since I was hired out of college. I’m comfortable there, I know how things roll, and I can work somewhat effectively. However, they all had one thing in common – my workload was dependent on whoever screamed the loudest or the fire of the day. Everything was reactionary, even our planned work. That automation script I wanted to write will have to wait. Performance tuning or capacity analysis …. I don’t have time. I know this SQL doesn’t do everything you want Mr. Client, but it will have to be close enough because a competing team needs me.
One of the most frustrating things a DBA can experience is troubleshooting due to bad data. The client is upset because rows are missing or incorrect data is returned. The client facing web front end could be displaying gobilty-gook because the data retrieved makes no sense. Resources and energy are burned because of an issue is easily solved with the proper use of constraints.