Robin Schumacher

I still remember my first database disaster that occurred almost 20 years ago.  I was a brand new systems engineer working on a massive mainframe database.  My leader needed me to make a few data changes, but they would have to be done while he was on vacation (of course) but he assured me nothing would go wrong.  Right.  To make a long story short, the morning I ran the jobs to make the change, I ended up deleting the entire worldwide telecommunications database of General Motors and keeping just the two records I needed to change.  Let me tell you, no amount of antiperspirant stands up under those conditions.

Thank goodness for the backup job that I ran right before the change.  I was able to restore everything back to the way it was, but brother, were there ever some anxious moments in between… 

For sure, data protection is the database professional’s #1 job.  And this week, we’re going to be talking about how Oracle DBA’s (and really any DBA) can learn how to choose the best form of MySQL backup for their situation and also utilize the nice backup solution from Zmanda if they’d like.  Both Zmanda and I will be presenting a webinar that you should check out if you have time; in it, we’ll cover backup techniques and best practices that will keep you confident, knowing that you’re protecting your databases as best you can.  Hope to ’see’ you this Thursday at 1pm EST. 

When I was a DBA, there were only a handful of must-have tools that I constantly used.  One was a good performance monitor.  Two was a cross-platform admin tool (since I worked with Oracle, SQL Server, Sybase, MySQL, etc.) And three was my data modeling/design tool.  There was absolutely no way I could have done my job in the manner I needed to without those three tools.

Of those three, there were times when I basically lived inside my modeling tool.  Why?  Because:

• Metadata management – I had to ensure data consistency and enforce standards of data elements used throughout my shop; the modeling tool was the best way to do this. 
• DB design – simply put, there was no way to more quickly put out a new DB design and forward engineer it into a new physical DB without my modeling tool
• Change management – when I made changes to the DB, I always wanted to keep a copy of how the DB looked before for change management reasons (in case I needed to put things back).  Using the modeling tool was the best way to do this.
• Packaged application management – I hated the black-box feel of packaged apps, but the modeling tool allowed me to reverse engineer and see inside the DB, which was a huge help.
• Reporting and communication – developers and business analysts always wanted layouts of the database they were using.  A couple of clicks in the modeling tool gave them what they wanted.
• Performance tuning – looking at bad datatypes, bad relations, denormalizing designs, etc., are all more easily handled in a modeling tool.

This is why I’m hyped over us releasing the beta of MySQL Workbench.  Now you and I have a nice tool to tackle the stuff above for MySQL DB’s.  Once you use it for a project or two, you’ll see what I mean about how much help a modeling tool can be.

Make sure you download the free version and let us know what you think.  You can also try out the commerical version, which has a few more time-saving things in it. Whichever edition you end up using, I think you’ll get hooked on modeling tools like I did a long time ago.