Voice of the DBA

Tag: administration

  • T-SQL Tuesday #52 – Arguments

    tsqltuesdayIt’s time for T-SQL Tuesday, this month hosted by Michael J Swart, our artistic DBA in the community. I love Michael’s pictures, and enjoy the time I get to chat with him at events.

    His invitation this month for #52 is to argue against a popular opinion. He asking us to find a "never ever" issue and argue for it. Or perhaps an "always do this" advice and argue against that. It’s a great topic.

    T-SQL Tuesday is the monthly blog party, invented by Adam Machanic. The second Tuesday of the month is the time to publish a post on your own blog about the topic and join the other people that write about the same topic.

    Never Turn on Auto Shrink

    I think that if you turn on the auto-shrink setting, Paul Randal rips an LED off his interactive panels. Even if he doesn’t, why would you ever enable auto shrink? It causes fragmentation, it’s somewhat insane as your files will just regrow if the space is needed for a workload such as a maintenance operation.

    The recommendation is to never turn on Auto Shrink on your databases. There are numerous references, though I’ll point to Brent Ozar’s nice summary. I’m going to pick a fight with this advice, though only in a narrow, limited sense.

    Auto shrink is, in general, a very bad idea. However I think there are a few places where I’d use the setting, understanding the implications.

    The Road Warrior

    There was a salesperson that had a laptop, traveling around and working his a piece of SQL Server (Express) based software. Let’s call him Joe, since that’s a nice generic name for this story.

    When Joe arrived at a client site, he’d get data from the clients in an Excel spreadsheet. He’d use the import wizard, load a bunch of data into a new table, point his software at it, and do some analysis of the data. He’d then make recommendations to the client and sell something based on his recommendations. When he was done, he’d click a button in the software and drop the table. The amount of data from clients varied, and it sometimes caused his database (and log files) to grow. He’d also forget to the drop the table sometimes and would wind up with 4-5 clients’ worth of data before he removed the tables.

    Over time, this also caused his laptop to run low on space. This wasn’t a big deal, and the help desk could respond to his concerns by remotely running a shrink of the files for him. However the time spent dealing with questions, and the concern that Joe experienced weren’t worth the effort. Auto-shrink worked fine for Joe and some of his colleagues.

    Performance wasn’t a big concern, as a single user accessed the database. The data didn’t live long enough to worry about fragmentation or maintenance and the reduction in irritation from Joe and the help desk was worth it.

    The Dusty Archives

    I once worked in a company that had an archive database. We had a process that copied data from previous years to a new database that was taken offline and a copy burned to a few optical discs for long term archival. We actually build this process to use a separate instance for the copy as the source SQL Servers were located in various parts of the US, and the data was remotely transferred to a central location for archival, and because we didn’t want to ship optical drives to multiple locations and explain to warehouse personnel how to use them.

    I, and my cohorts in IT, also didn’t really want to travel to small, inconvenient warehouses located in small cities without direct flights.

    One of the requirements was that we make these databases as small as possible to save space. We typically built a few archive databases before we shrank them and took them offline. In hindsight, the process of copying the data should have minimized the size of data and log files with its own shrink, but that wasn’t the case. An administrator needed to perform the shrink and sometimes they’d forget. Actually, most of the time they’d forget.

    The simplest solution was to enable auto shrink on this instance. That way once database files were sitting on the instance for any length of time, the databases would shrink themselves. No need for anyone to worry.

    Performance wasn’t an issue in these cases as recovery of the data would have meant a transfer back to a source system, where fragmentation and indexing would have been a concern.

    Narrow Cases

    In both cases, the reason auto shrink worked was performance wasn’t an issue, and administration was. Performance didn’t matter, and it wasn’t a heavily used system. I think these, and perhaps a few other narrowly defined cases are acceptable uses of Auto Shrink.

    However I also think there are many more abuses of the setting and I’d prefer it removed from SQL Server. Scheduling this process with Powershell would be trivial if you really needed it.

    And if you don’t know how to use Powershell (or SQLCMD), perhaps you shouldn’t be shrinking database files.

  • Zombie Data

    Most of us that work with data are concerned about losing any of the bits or bytes we are responsible for. Many of us practice restores when we can, we complain about the low disaster recovery budgets we’re allowed, and we regularly check our systems for corruption. Even those of us that aren’t extremely diligent in our daily data protection are often worried about losing our jobs if a disaster causes data loss. Many of us don’t even trust our users, preferring to implement logical deletes in applications rather than physically running a DELETE statement.

    However there are times that we do want to remove data from our systems. We may find data quality is poor and want to erase the results of an ETL load. We may find ourselves bound by regulations that require the removal of data from our systems. We may upgrade old software and end up with copies of obsolete databases whose contents have been copied and reformatted by a new version of an application.

    This article talks about the data-pocolypse, and in somewhat of a jesting way, but it has a few good points that we may want to consider when we do need to remove data permanently. We should understand that deletes are not always deletes, and if a permanent solution is needed, we should use a utility to wipe the drive or physically destroy the hardware. However there are other places we should worry about old copies of data. Backups should be deleted from remote storage that might not have cleanup jobs running anymore if the servers are decommissioned. We should be wary about taking databases offline, or detaching them without physically removing the files. Development machines, laptops, etc. should have data removed if we are sure we don’t need it again.

    We should be especially careful about security access to servers that we are not using. Users might easily have links or pointers to old servers, and mistakenly connect. Make sure you remove access when you decommission the instance. Be careful about keeping old file exports, such as reports or feeds that were generated in the past. It might not be practical to wipe backup tapes, but be sure you’ve changed documentation and surfaced the information to all administrators that copes of databases restored from tapes after xxx date are not useable in DR situations.

    Of course the first thing you should do is make sure you have a good backup of the most current version of your data before you start deleting older copies. Delete this last, after you’re absolutely sure that users are no longer going to request a restore. I wouldn’t even ask users about this, however, because they may not be sure themselves. Instead I’d set a reminder a few months in the future to go back and delete this one, last, most current backup.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.3MB) 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.

  • 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.