How I became a Db2 for z/OS DBA... OVERNIGHT!

I imagine my story is not entirely uncommon, but it is certainly unique to me. I was a SQL Server DBA for 7 years at Southern Farm Bureau Life Insurance, when a sudden personnel change led me to becoming our company’s new Db2 for z/OS DBA, (in addition to my role as the SQL Server DBA) literally overnight.   Because I had database experience, management thought this made sense and would not be out of my realm of knowledge or comfort.  Anyone working with Db2, z/OS, knows there is so much more involved.

Our company worked with an IBM Z partner, Sirius, who hired a consultant to spend a week learning about our Db2 applications and environment and then spend another week in skill transfer with me. After those two weeks, the number one message conveyed to me was something like, if it’s not broken, don’t fix it or worry about it.  

That’s not my basic nature, nor would it be my recommendation to anyone in a similar situation. I tried to get my hands on as much information as I could by reading and studying.  Our typical performance methodology before I took over as the Db2 DBA was, if something was slowing down our system, the developers waited until the next day, hoping it would go away or at least get better.

Because Southern Farm Bureau Life Insurance (SFBLI) cares about sensitive customer data and its protection, we decided to encrypt our Db2 databases. If we ever were breached, we wanted to know that the customer data would never be compromised. Shortly before the personnel change, my company purchased software to perform encryption.  I discovered very quickly that database tools can be very helpful if they fill a true need and you know how to use them.  I also discovered that in untrained and inexperienced hands, they could wreak all kinds of havoc. I encrypted the entire production database and our Db2 system ground to a halt.  We put in a late-night support call to IBM who asked us to send them the reports from our monitoring tools to see what happened.   The problem is that we had no monitoring tools… and my knowledge of Db2, z/OS, etc. was still in its infancy.  IBM not only helped us roll back to a safe and stable point, they also worked with us to help avoid issues like this in the future. 

I’m not an expert yet by any means, but today I can proudly say that SFBLI is no longer in a reactionary mindset when it comes to performance issues. Not that the end-user is able to notice or appreciate, but I have been able to move us to proactive performance monitoring and tuning.  Also, if there is a rogue performance issue, I am confident that I can find it and correct it before it affects application performance and availability and our customers. 

I hope you’ll join me on April 24th where I’ll share my performance tips and practices.  I’ll explain how we got past the database encryption that shut down our system and where we are today on our journey.  Here’s the URL for registration: http://bit.ly/Db2_Apr24

 

 

 

Views: 1031

Add a Comment

You need to be a member of The World of DB2 to add comments!

Join The World of DB2

Bringing Db2 enthusiasts together virtually. Expert or novice, distributed or mainframe, this is the place for everything DB2.

Top Discussions 

User Groups

Videos

  • Add Videos
  • View All

IDUG Conference News

© 2019   Created by Surekha Parekh.   Powered by

Badges  |  Report an Issue  |  Terms of Service