Voice of the DBA

Tag: administration

  • The DBA is Dead

    I love seeing articles like this one: The Database Administrator is Dead. They make me laugh and look back at previous incarnations of the same thought. I think I should save the text of this article, stick it in an appointment with a reminder for 2 years from now, and then read it again.

    The first time I heard this was back in 2000. I was working in a small company and SQL Server 7.0 came out with a marketing push that a DBA wouldn’t be needed. The developers I worked with crowded around and asked if I was worried about my job. I’ll admit I was a little worried, even as I denied any concerns to my co-workers, but as I read about the changes and thought about my job, I realized it was all for naught.

    While much of our jobs can be automated, the specific details and implementation of any automation at any particular job will vary widely at different companies. Even at different times. The work that DBAs do is not going away, and someone needs to continue to provide some administration and management of databases.

    I will admit that I think there is less of a need for DBAs at many companies, at least if the DBAs are strictly managing security and backups. The amount of time these tasks take now has been dramatically reduced with new tools for managing systems, both within SQL Server and from third party vendors. If you have a job that just deals with basic administration, good for you, but I wouldn’t stop learning. Those talents might not be enough to get you a new job if you need one.

    I also think that today’s DBAs need to be able to handle the limited administration that might be needed on other platforms, including the cloud. We need to understand how we can work with, and speed up development, with SQL Server databases while helping to improve the quality of any database code that’s written. We need to learn about how we can get the most from the platform while integrating with a variety of technologies.

    The DBA isn’t dead, and I’ve created that appointment for 2 years down the road. It will be interesting to see how things have changed in that time.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.9MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA podast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Servicing SQL Server in the Future

    Service Packs have become the way that many of us patch the various Microsoft products we use. Many administrators find patching to be time consuming and difficult to justify, even for security patches, and as a result, often wait for a Service Pack before they inform clients and schedule testing. Most people used to always wait for Service Pack 1 before installing a new version of a server product, but I don’t think that’s necessary anymore. The quality of Microsoft server products has gone up quite a bit in the last 5 years.

    However, I don’t like the way that the servicing, or patching, of products has evolved. For SQL Server, we get patches every other month, known as Cumulative Updates. Exchange Server has also moved to this format, though it seems many of the other server products (Windows Server, Sharepoint, System Center, etc) still release Service Packs. A few years ago it was rumored that Microsoft would not release Service Pack 3 for SQL Server 2005. A number of us voted on this patch and it was eventually released.

    The strategy announced at that time was that SQL Server would receive a service pack 6 months after the RTM release and thereafter annual service packs until support expired for the product. In between, Cumulative Updates would be released. That seemed to be the case for a few years, but once again Microsoft seems to have quietly decided not to move forward with Service Packs. We’ve been getting cumulative updates, but no service packs in over a year and a half. The last SPs we have are SP1 for 2012 (Nov 2012), SP2 for 2008 R2 (July 2012), and SP3 for 2008 (Oct 2011).

    If you’re like to express your opinion, take a moment and vote for these items:

    It just takes a moment to click on them, and I’d also ask that you pass along the URL (or this editorial) to friends that work with SQL Server.

    Personally I’d also like to see a solid strategy moving forward that includes annual service packs, especially with a 2 year release cycle. I know some of my fellow MVPs and writers like the CU strategy and wish more people would adopt it, but I don’t agree. It’s time consuming to test and prepare for updates, and as long as this paragraph appears on CU pages, I do not think we should recommend CUs to DBAs.

    “This cumulative package is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems. The updates in this package may receive additional testing. Therefore, if you are not severely affected by any of these problems, we recommend that you wait for the next SQL Server 2012 service pack that contains the hotfixes in this package.”

    To me that shows even Microsoft doesn’t completely want to stand behind their cumulative updates.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Management at Scale

    Would you like to manage 20,000 databases by yourself? What about 20,000 instances? It’s not quite the same thing, but Facebook recently announced that each of their data center operations staff manages 20,000 servers. That’s an impressive number, and it comes about because of lots of standardization, specialized design, and lots of automation.

    If you watch the video, you’ll see that a lot of effort in the Facebook data centers is being paid to gathering and analyzing information. They seem to truly understand that having data about not only their systems, but their processes, is valuable. Maybe more importantly, they understand how to modify the way they work based on data to improve their efficiencies.

    We should do the same thing as DBAs. Perhaps even as developers. We should be monitoring our workflow and looking for ways to improve our effectiveness. We should take advantage of the tools that let us manage systems at larger scales. PBM, third party tools for monitoring and alerting, BIML or SSIS patterns and practices, and more. There are a variety of ways in which we can work more efficiently.

    I thought the best quote in the article was this one: The emphasis on automation is not because Facebook is interested in unmanned data centers, or having robots operate facilities. It’s because Facebook values its workers”. The next quote is “We want to hang onto our talent,” she said. “The way you do that is to give them the opportunity to work on high-value tasks.”

    Those are powerful quotes, and I wish that was how more businesses viewed their workers. To be fair, most workers haven’t proven themselves to be willing to tackle and want the “high value tasks”. All too often I find there are too many workers that want to get their job done, without providing more value than they cost. If they did, perhaps we’d have many more companies that would value their employees, and they could manage systems at something closer to Facebook’s scale rather than the much lower numbers I’ve seen in my career.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Common Checks

    One of the things that I recommend to DBAs is that as they write code to solve problems, they write some sort of check to catch future potential occurrences of the issue. For example, I worked with a product years ago that had an identity column as an int, but this product scanned thousands of our systems every 5 minutes, logging each scan. We found that after 8-12 months, we’d run out of identity ranges.

    While we considered changing to a bigint, this was a third party product and they did not want to allow us to alter the schema. Since there were only a few million rows in the table at any one time, we decided to write a check that would alert us when the table came close to running out of integer values. A DBA could then easily reseed the identity property to prevent issues.

    Across my career I’ve found many other instances where we could write checks to find issues before users were impacted. At SQLServerCentral we have checks looking for discrepancies in points awarded, in incorrect status values, and more. These often don’t impact the users of the site, but they are alerts that let administrators know about potential problems before they become issues.

    This week I’m wondering:

    What types of common issues have you found that could be valuable as checks for other DBAs?

    Perhaps looking for delays in replication or Service Broker? Jobs that never stop or never execute for some reason? Memory or space alerts? Do you look for localsystem as a service account? Let us know what checks you’ve written, or which ones you wish were available for you to download and use on your systems.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.