Voice of the DBA

Tag: administration

  • T-SQL Tuesday #31 – Logging

    TSQL2sDay150x150It’s T-SQL Tuesday time again, and this month Aaron Nelson (blog | @sqlvariant) is hosting. The topic is logging, and if you’re like to participate, read Aaron’s post and learn the rules. We do this on the second Tuesday of every month.

    If you’d like to host, contact Adam Machanic. It’s easy to do. Get on the schedule, pick a topic, and then write a post.

    A list of previous posts is here,

    Logging

    I’ve found documentation of events to be one of the most important things I can do in my career. Finding out what happened, what changed, or what I did has been important many times, and often helped me come through difficult situations.

    Logging is the automated version of documentation. All kinds of applications, including SQL Server, produce logs of the various activity on the system. In SQL Server, we are moving to an eventing system, and if you haven’t looked at Extended Events, you should.

    One of the times when I found logging to be lacking was in a startup I worked at a decade ago. We had a number of developers that were working on various development servers. They had full rights, and they were allowed to build their own objects. That was a little concern to a controlling DBA like me, but I allowed it since they often wanted new objects quickly, and if I allowed them to write their own, they’d use stored procedures.

    A good compromise, if you ask me.

    However in the hectic pace of development, I found that the developers didn’t often keep good notes about what was being built for which features and functions. Since we had to produce a build script fairly quickly every Monday in order to update our QA systems, we would find that developers invariably would forget objects and we would not have a well tested QA script on Monday afternoon.

    I decided that we needed to better log the changes on our development server. I didn’t care about every change, especially intermediate changes to objects, but I did care about the gross changes made each day.

    This was in the SQL Server 2000 days, with limited tracking of changes outside of SQL Trace. Since I had no desire to move through lots of trace files, even in an automated fashion, I decided on a much simpler method.

    In sysobjects (now sys.objects), there was a crdate field, which tells you when the object was created. However that doesn’t change if an ALTER TABLE is run (or any other ALTER). That stumped me briefly, but I decided to search further.

    I found that there was a schema_ver field, which is incremented every time the object is changed. Since the majority of our developer changes were ALTERs, I could track the version number and then compare this each day. I tested this out, and it worked well.

    The outline of the solution is that I grabbed a copy of the sysobjects table every day and stored it in a temporary table. I then used a left join to compare this with the previous values stored in a table I’d created to store the data. When I found differences, I logged them in a table, along with the date, and sent myself an email. I would then overwrite the stored version of the objects with the version from the temp table, giving me a baseline for the next execution.

    At the end of the week, I’d have an aggregate list of all objects changed, which I could then compare against our build script.

    At the time we were in an agile environment, releasing new code every Wednesday, and operating on very short timelines. The logging I did cut down on mistakes and allowed us to have a smooth release process that functioned for over 18 months, with code releases nearly every Wednesday outside of holidays.

  • The Platform as Code

    data center
    Trying to manage all your servers individually is like tracing cables in this kind of setup.

    SQL Server has grown more and more complicated over the two decades that I have worked with the product. At the same time anyone can install it and set up a database with almost no training. There are more and more features and functions to learn, yet it’s become a much easier product to use. It seems as though one person may view the platform as very difficult to use while the next sees is as requiring almost no management. Both of these views can be true, but as we say often about SQL Server: it depends.

    When I started working with SQL Server, it was a cumbersome platform, the network configuration could be tricky and it wasn’t easy for developers to master the named pipe connections that were required. Since then it has become a very easy to set up and use platform, with many system administrators managing servers that almost manage themselves. “Almost” being the key word there.

    Just as with other Microsoft platforms, the days of having a set of procedures that handle your daily tasks and lead you through the solution are gone. The platform handles the simple stuff, the routine issues, but it is almost a requirement that a good system administrator be able to write T-SQL queries and string together segments of code.

    I was reading an interview with Jesse Robbins, the founder of OpsCode, a company focused on infrastructure automation. In the interview, he had a few quotes that struck me as very true. “What has happened over a period of time is that sysadmin skill set has been expanding more and more to include more and more basic infrastructure software development.” The second quote deals with managing more and more servers: ” That is not being built on your back every day, when you’re logging into the same 50 boxes and typing in the same 50 commands. ”

    Those quotes were similar to some of the presentations I saw on System Center 2012 at DevConnections. There is a focus on automation, on scripting, on working with groups of machines at scale, not as individual systems. The administrators, whether on Windows, Exchange, SQL Server, or some other platform need to learn how to better administer their systems with code, not with the GUI.Steve Jones

    SQL Server ConnectionsIf you want to learn more about Systems Center and SQL Server, come to DevConnections in the fall. It’s the best conference to learn about all parts of the Microsoft technology stack. Grant Fritchey and Steve Jones will be there speaking along with lots of other great Microsoft technology specialists.

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Finding the Default Trace File

    A post more for me than for anyone else, since I’ll look for something in the default trace and I often need this snippet of code:

    select path 
 from sys.traces 
 where is_default = 1

    That returns something like this:

    path

    ————————————————————————-

    C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\log_92.trc

    This is the current file being used by the trace, which allows me to then look into the file for some event.

    From here, I usually start running a query like this:

    select 
   e.name as eventclass
 , t.textdata
 , t.starttime
 , t.error 
 , t.hostname
 , t.ntusername
 , t.ntdomainname
 , t.clientprocessid
 , t.applicationname
 , t.loginname
 , t.spid
 from fn_trace_gettable('C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\log_92.trc', default) t
  inner join sys.trace_events e 
     on t.eventclass = e.trace_event_id 
  where eventclass = xx

    In this query, I take the output from the first query and use that as the FROM file and then include an event class number in the WHERE clause. I needed this today, running a check for the latest DBCC, and so I used the class 116.

    You can get a list of event classes here: Trace Event Classes

  • Small Management

    Steve on a horse
    I’m on a horse

    This editorial was originally published on June 21, 2007. It is being republished as Steve is traveling.

    I saw this article on server management from a handheld and it’s always seen like something that’s very cool and handy, but I’ve almost never been in a situation where I really needed to manage my server while stopped on the side of the road or eating dinner. There’s times I got called away from something to go into work, but usually it’s not something I think I could have solved, or even wanted to solve, on a 320×240 screen.

    But recently while I was at TechEd, I saw some really cool new handheld devices. The capabilities of handheld devices, usually PDAs converged into phones, is really amazing. So I wanted to know:

    How many of you can, or would, manage your servers from a handheld?

    I’ve never had a phone with a keyboard, like a Blackberry. I’ve been a candy-bay Nokia guy for a long time, though my updated Startac, errr Razr, adorns my belt these days. Not by choice, but for another 6 or 7 months I’m stuck with it.

    Years ago I also had a small form factor laptop to test for my boss. It was aCasio Cassiopeia A-10, and it ran CE and limited applications (this was circa 1997). I run pcAnywhere on it and actually logged into a workstation at work and tried to manage our SQL Server and other applications. It didn’t work, at least not without frustration. Granted that was over dial-up, but it was way worse than my laptop because of the small form factor.

    Recently I saw APC giving a self-guided tour of their new racks using PDAs. You could pick up a Dell Axim, click a button to start the video or move to the next section, and watch the tour while you walked around the rack. With headphones you could get the sales pitch and pause or move forward as you wanted. And it actually worked pretty well.

    That’s not quite typing in a T-SQL command and I’m not sure how difficult it would be to try and navigate SSMS thorough a Terminal Services screen, but it gave me some hope that it might be something I’d try down the road.

    So let me know if you think it’s something you might do.