Reprinted from my editorial in Database Weekly.
When I was a junior DBA many years ago (even before the company I work for now, Red Gate Software existed), I ran across some third-party software for SQL Server that I thought could really benefit my productivity and save my organization money. I presented my case, proving how the new software would be beneficial to the company. My boss agreed with that the new software would indeed boost my productivity, he refused my request. When I asked why, he answer was “We are a 100% Microsoft shop, and I don’t want to introduce any third-party software into the mix.” He continued to say, “If we should every have any problem with the third-party software, then Microsoft and the third-party software company would point fingers at each other, and the problem would never get solved.”
Last week I attended the inaugural training event of the new four-week SQL Server Immersion Training offered by Kimberly Tripp and Paul Randall of SQLskills.com. The four available training weeks include:
- Internals and Performance
- Performance Tuning
- High Availability and Disaster Recovery
- Security, PowerShell, and Development Support
I attended the Internals and Performance class in Dallas, and I will also attend the Performance Tuning class in March, also held in Dallas. While these classes can be used to help you prepare for the MCM, they are designed to be taken by any DBA who wants to deepen their understanding of SQL Server. In fact, only a handful of the 29 attendees at the Internals and Performance tuning class were interested in pursuing the MCM. Most of them, like me, just wanted to gain a deeper level of understanding of SQL Server.
From my Database Weekly editorial.
Most of us DBAs don’t work in a standard 40-hour a week job. We often have to work late, work weekends, and be on call just in case a problem arises. If you’ve been a DBA for a really long time, you still remember the days before the Internet, VPN connections, and cell phones. Back then, many DBAs carried a pager when on call, or took phone calls over a land line. In many cases, the only way to resolve the problem was to physically go into the office and check out the problem in person, no matter what time of the day it was.
This is a reprint of my editorial in Database Weekly.
Scenario One: The new third-party application, purchased by your company without your involvement, is performing poorly on SQL Server. As the DBA, you are getting a lot of flak from users and management, but your hands are severely tied as to what you can do to fix the problem.
Scenario Two: The IT budget has been cut, one DBA position has been lost, and the money promised to replace your aging hardware is nowhere to be seen. And, by the way, you now have to take over all the duties that the laid off DBA used to do.
When faced with difficult times such as these, what do you do? Do you:
This editorial was originally published in the Simple-Talk newsletter.
Imagine for a moment if you will. As a DBA, and as the protector of your organization’s data, you have implemented many safeguards to protect your data. You have set up periodic jobs to back up your databases; you check daily to ensure that the backups were actually taken; and you periodically perform test restores to ensure your backups work. In addition, you have established an appropriate backup retention policy and you store backups offsite. With all of this planning and hard work, you are confident that your organization’s data is safe. But is it?
This is reprinted from my editorial in Database Weekly.
During some recent conversations, I’ve noticed an increasing tendency for people to precede a disclosure or opinion with a proviso such as “Please don’t tweet/blog about this, but…” It’s an interesting indication that, with the advent and growth of social media, has come an increasing concern that today’s private conversation may turn into tomorrow’s world-wide Tweet.