Voice of the DBA

Tag: T-SQL Tuesday

  • T-SQL Tuesday #13 – What the Business Says Is Not What the Business Wants

    TSQL2sDay150x150It’s time to wrap up T-SQL Tuesday for the year 2010 and I was invited to host his month’s blog party by Adam Machanic (Blog | Twitter).

    What’s T-SQL Tuesday?

    This monthly event is the brainchild of Adam, and you can read about the inspiration in his very first T-SQL Tuesday post. Adam Machanic , a long time SQL Server MVP came up with an excellent idea of improving community involvement around blogging where bloggers around the world post their views on a same topic chosen by the host on the 2nd Tuesday of every month. If you are interested in hosting an event like this and then send a note to Adam.

    What are the rules?

    1. Since this is a global event, your post should go live between 2010/12/14 00:00:00.000 GMT (2nd Tuesday) and 2010/12/15 00:00:00.000 GMT. Since those of us in the US as sometimes date challenged, that’s sometime during Dec 14, 2010 using GMT time.
    2. Your blog post has to link back to the hosting blog, and the link must be anchored from the logo (found above) which must also appear at the top of the post.
    3. If trackbacks won’t work properly then please leave a comment below so that your post is accounted for in the roundup.

    Nice Things To Do

    1. Include a reference to T-SQL Tuesday in the title of your post. (The more we bloggers advertise T-SQL Tuesday, the more we bloggers get T-SQL Tuesday readers)
    2. Tweet using the hash tag #TSQL2sDay to follow links and other relevant conversations.
    3. consider hosting T-SQL Tuesday yourself. If you’re interested let Adam Machanic Know. If you’ve participated in two T-SQL Tuesdays previously and you don’t let your blog go stale (blog once a month for the last six months) then he’ll put you in the rotation.

    The Topic

    I was giving a presentation recently and someone in the audience started to ask about why I recommended against a certain technique. Without getting into it, this person kept saying that she had to implement things her way since the “business” said they needed it done that way. However a little digging showed that the business didn’t really understand the technology. They were asking for a result, and she took them literally in how she implemented a process. A classic impedance mismatch.

    I think we’ve all had situations that are similar. The business, the client, the customer, is asking for something, but they don’t know how to ask those of us building the technology. Or they don’t understand the implications of asking for something like “absolutely zero data loss” to be implemented.

    The official topic this month is:

    What issues have you had in interacting with the business to get your job done.

    Post your answer on Dec 14, 2010, based on GMT time, make sure a trackback or link appears in the comments for this blog, and I’ll look forward to reading what issues you have had to work through.

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