Voice of the DBA

Tag: T-SQL Tuesday

  • T-SQL Tuesday #12 – Why Do You Need a DBA?

    TSQL2sDay150x150 It’s once again time for T-SQL Tuesday, the brainchild of Adam Machanic (Blog|Twitter). It’s a monthly blog party, designed to get bloggers to all write on a single topic on the same day. This month we have the party hosted by Paul Randal with his topic of why are DBA skills necessary?

    I enjoy participating, and if you want to host one of the monthly events, please contact Adam and get on the schedule. It’s not a lot of work, and it will be something that I’m sure you’ll enjoy.

    Is a DBA Needed?

    I’ve wondered about this at a few jobs. I know when I’ve automated checks and maintenance, gotten a solid DR plan running, and tuned most of the queries that I can, life is pretty easy as a DBA. I’ve often had time to try and learn more about SQL Server, be more pro-active with developers, and even spend a few minutes at the water cooler. After 6-12 months at a few jobs, I’ve often felt like I had things in control, and I could have worked 24 hours a week and had a very stable environment. 

    In fact, I tried to convince one boss of that, offering to take a pay cut and maintain his environment in 3 days a week. My boss didn’t go for it, mostly because the company didn’t want any part time people, but I think I could have saved them some money and been fine with the occasional consulting job.

    Not every environment is like that, but so many consultants walk into jobs where the SQL Server isn’t performing well, and the applications are slow. A crashed server can become a major event, and even cost the company significant revenue from systems not being able to handle the load or being down.

    DBAs are Insurance

    At the base level, a DBA provides some insurance for one of a company’s most valuable assets: it’s data. Many DBAs, even those that don’t know how to tune queries or design databases can implement the basics of the job in two areas:

    • backup/restore
    • security

    Without a doubt there are plenty of people that need to improve these skills, but most of them are better than the average system administrator. A DBA that understands these skills can really save money in a company that has any sort of disaster involving a database. I have seen many Windows administrators relying on their tape backup software and an Open file backup driver, or an agent based backup solution, most of which seem to fail when disaster strikes.

    In terms of security, so often a Windows administrator will grant all read/write rights to people accessing SQL Server. Developers can be even worse, granting db_owner privileges, or even using “sa” in their applications. A DBA can ensure that more granular rights are set up, which reduces the risk of any security issues.

    Even an expensive DBA provides some good insurance for a company that can pay off the first time a database needs a restore.

    DBAs are an Investment

    However someone that has strong skills working with SQL Server can be so much more than insurance. They can be an investment that vastly improves the amount of work that your databases systems can do.

    DBAs can tune your systems. They can ensure that SQL Server is set up properly, and that proper indexing is set up. The time savings can be a huge factor in allowing employees to be more productive and produce more revenue. If you develop pieces of your own software, a DBA is a must to ensure that you have well-written code.

    DBAs can find patterns in your data. I think the DBA is critical to ensuring the intelligence aspect of a BI system. The value of that should not be understated. As we capture more and more information about our businesses, it can be easy to start mis-interpreting or mis-understanding the meaning of that data. A good DBA will understand the business and the data, and help the company to understand what information is contained in the data.

    Not always, but often

    Not every company needs a full time DBA. I wouldn’t expect a small business that runs COTS systems with a system administrator to have one. But many companies, and likely every company that develops software based on a database (either in-house or shrinkwrap), should have DBA skills.  Having someone that understands the database, and can guide its use just prevents so many problems in the future.

    You might not need a full-time DBA, but you most likely do need those DBA skills if you have a SQL Server running in your data center.

  • T-SQL Tuesday Topics

    I was asked to host a T-SQL Tuesday, and I accepted.

    Once again, my fingers move a bit faster than my brain. “Sure, be happy to host one. Send me a date” flew out of my fingers before I thought through the implications. I’m happy to help the community, and I think Adam Machanic (Blog|Twitter) had a fantastic idea with the T-SQL Tuesday blog party, and I look forward to them every month.

    But I’m busy, and this is a very busy time of year for the next month, with the hope that most of December will be quiet for me. It’s been a crazy year for me and I’m looking to try and better manage life next year.
    Adam immediately responded to my email with a date, and I have December. I was thinking he’s a busy guy, and my mail might get lost in the shuffle. However it didn’t and I ended up with not only an acceptance, but a date that’s not too far in the future.

    So I need a topic.

    There are any number of topics out there, and after all, T-SQL Tuesday has only been around for a year. However I was somewhat stumped as to what a “good topic” will be. After all, I want this to be a good one.
    The ones I’ve seen so far are:

    I’ve got a few ideas, and some work ahead of me to develop something in the next month around SQL Connections, SQL Saturday #59 and a week of family vacation. If you have any ideas of your own, don’t post them. Save them for your own T-SQL Tuesday and contact Adam to host one.

    I’m not sure what will happen in November, and I’ll be jammed up with a post since I’ll be at Connections next week, so whether it’s the first Tuesday or second, I’ll be hustling a bit to participate.

  • T-SQL Tuesday #12 – Misconceptions

    TSQL2sDay150x150 It’s time for T-SQL Tuesday again, and I’m happy to participate again. This is a monthly blog party started by Adam Machanic (Blog|Twitter )that asks people to write on a particular topic all on the same day.

    This month’s theme is misconceptions in SQL Server, hosted by Sankar Reddy. You can read the rules for the party and get information from his blog.

    The Most Common Misconception

    I read a lot of forum posts, literally hundreds a week on all topics in SQL Server. One thing that I consistently see asked is the dreaded:

    “My transaction log has grown so large it filled the disk”

    That’s a common occurrence, too common in my opinion, and while there are people that forget to setup any backups, I also find in the majority of cases people just don’t understand one thing:

    A full backup does not clear the transaction log.

    Too many people assume that the log will get managed by a full backup. It doesn’t. While some log record get included in a full backup, they do not get marked as “backed up” and the space re-used.

    If there is one thing that I wish everyone managing a SQL Server knew, it would be that they need to make full and log backups to properly manage the disk space usage by their logs.

  • T-SQL Tuesday #10 – Indexes

    TSQL2sDay150x150[1] It’s time for T-SQL Tuesday again, the brainchild of Adam Machanic (Blog|Twitter), and this month’s topic is Indexes. A thanks to Michael Swart for hosting this month’s event, and sending me a personal invite through email. That was pretty cool, especially since I don’t necessarily remember when the event is kicking off.

    The invitation is here, and time is running out to participate, but if you want to blog, you can do it today before this script (from Michael) tells you that you can’t

    IF GETUTCDATE() BETWEEN '20100914' AND '20100915'
    SELECT 'You Can Post'
    ELSE
    SELECT     'Not Time To Post'

    Remembering to Index

    Indexing seems to be one of those things that so many people forget to do. As a result, adding a few indexes is often the easiest win, the lowest hanging fruit, the most effective way of improving performance in many situations.

    I know in the past that I almost always create a single index on a new table, the PK, when I build it. If there are FKs, those are setup as well, and this usually helps, but when building a database, I sometimes forget to add other indexes since I don’t know what other queries I might be running when I start. And as I start to build those queries (to support new functions for the user), it’s easy to forget to add an index.

    sqldatagenerator[1] Since it’s hard to guess what you will query often, and the think/build/test/refactor model leads you down dead ends at times, I don’t typically build an index for a new query. I don’t notice performance issues since I’m usually working with test data that has dozens of rows, not hundreds. In the past, I’ve wished for something like Data Generator. Now that I have it, I typically don’t need it anymore.

    I try to go back and add in indexes as we get close to deployment, but I’ll admit that I typically have found in the production system that I’m missing indexes. This usually occurs over time, as data grows and performance decreases. I’ve wished that I had a better method for handling indexes, and apparently Microsoft was listening to wishes since we now have sys.dm_db_missing_index_details and other missing index DMVs.

    However I found someone that did have a solution. The company I worked for bought a third party piece of software to handle some specialized function for a department. I wasn’t involved, but one day they came to me with a performance issue. As I dug into the application, which had been working for months, I noticed something interesting.

    Every column was indexed.

    Not only was every column indexed, they had added other indexes that reversed columns in the index, so if I had a table like this one:

    CREATE TABLE Customers
    (
    CustomerID INT
    , FirstName VARCHAR(50)
    ,     LastName VARCHAR(50)
    ,     ADDRESS1 VARCHAR(50)
    ,     City VARCHAR(50)
    ,     StateID INT
    , Country VARCHAR(50)
    , Notes varchar(max)
    )

    I might have these indexes:

    • CI : CustomerID
    • NCI: FirstName
    • NCI: LastName
    • NCI: FirstName, Lastname
    • NCI: LastName, Firstname
    • NCI: Address1
    • NCI: City
    • NCI: StateID
    • NCI: Country
    • NCI: Notes
    • NCI: Address1, city, stateid, country

    It seemed like a little overkill, and after discussing this with the support engineer for awhile, he admitted that a number of these indexes weren’t needed, but the developer didn’t know what to index, so they indexed everything.

    We decided to run a trace on the application for a week, sort through queries, and come up with some more rational choices for indexes. We also removed a few of the duplicate indexes, and we improved performance for a number of functions.

    Indexing is important, but you can overdo it. Make sure that you index, but also think about what you index, and don’t index everything.