Voice of the DBA

Author: way0utwest

  • The Tapestry

    270px-ST-TNG_Tapestry[1] When I run on the treadmill, I have a TV and DVD player down there and have been watching Star Trek: The Next Generation over the last few years on and off. I recently saw an episode called Tapestry and it really made me stop and think.

    In this episode, Picard is killed, or dying at the beginning, pulled into Sick Bay. As he fades, we cut to a scene with Q where Picard is told he’s dead. The story goes on to give Picard a chance to change his life, taking him back to the time when he’s newly graduated and just before he’s stabbed in the heart. Picard shows some regret that he started a fight then, and had to receive an artificial heart. You can guess that he relives the scene, but doesn’t get stabbed, resulting in a history he doesn’t like.

    As I watched this over a few days, I kept thinking about my life, and regrets. Would I want to go back, with different knowledge, and change anything? I know I have some regrets, some actions that I’m not proud of, but I wouldn’t change anything. The place that I am in today is because of all the choices I made in the past. The good ones, the bad ones, they’ve contributed to the person that I am today.

    I’m not a fatalist, but I have an acceptance of life as it is. I strive to do good, to be better, but I understand I’ll make mistakes and I’m frail. I do the best I can at each moment, knowing that sometimes that isn’t my best, and that I might change how I view the world as I grow and learn.

    The tapestry of my life is somewhat woven, with more being added each day, but I wouldn’t go back and change anything. If I died today, I would accept that I’ve lived a good life, without wishing for the chance to change my past.

  • Enterprise Management

    One of the things that I’ve had to do in my career is manage large numbers of servers. There was a time when two of us managed several hundred instances of SQL Server, and managed to do it very well with a lot of automation. Recently I saw someone post a note about having 400+ servers to manage, and they were wondering how to perform enterprise management. In Oracle environments, they mentioned using OEM, RMAN and other tools to manage backups centrally and wanted to know what SQL Server solutions were out there.

    I know things have changed quite a bit from the SQL Server 2000 days when we had to build all our own tools, so I wanted to ask the question as a poll this Friday:

    What do you do for central management of lots of instances?

    If you have more than 50 instances, what tools do you use to try and ensure you have a well managed environment. With the addition of the Central Management Server and Policy Based Management  to SQL Server, it definitely is easier to handle a larger load of instances

    This Friday I’m wondering what tips and techniques you think work well for managing lots of instances. Any tricks you’ve used? Any third party products that are very handy? Share you knowledge this Friday.

    Steve Jones

  • Powershell and Performance Monitoring

    When I was doing performance monitoring of servers, I typically struggled with a good way to get the data. In years past it was cumbersome to keep track of server information and rarely was it done well. So often I found that many problems were the result of simple mis-configuration settings, or a lack of patches. Once a DBA or sysadmin can’t remember everything about every instance, it invites chaos.

    Allen White is showing how to better track a “server inventory” to learn all about the setup, configuration, and performance of SQL Server using Powershell. It’s easy to find this information in an ad hoc manner, but keeping track of it and catching exceptions requires something more formal. Powershell is a great way to do that in a repeatable way.

    Based on an article at Simple Talk, Allen shows how you can put your servers in an XML file and then read that in from Powershell and use it to drive a series of queries against a particular instance and machine.

    Most of this session gives you a good look at a script that will gather various information, including performance data, from your instances.  One of the more practical sessions that can really help you understand a large Powershell script in detail.

    However Powershell takes some practice. It’s a set of fairly concepts that are designed to be put together, but you need to take a little time to understand how the scripts work.

    If you get the chance to see Allen speak, it’s worth it. He does a good job of walking through code and helping you understand how it works.

  • One Time Passwords

    Facebook seems to be constantly under fire for one privacy issue or another. I think it’s likely something that they will deal with forever, since their fundamental purpose is to find ways to share data with others and many people don’t understand the tools that Facebook has built for them. As I follow the growth of Facebook and see the new features that they add, I think they do have some commitment to making it easier for people to better secure their information and only share it in the way they want.

    Recently I saw on the Facebook blog two neat features that I really liked, and I think might be nice additions to SQL Server. One was the ability to remotely log your account off from other locations. This could be handy for people that might access Facebook from a public terminal and forget to log off. We can easily have an administrator do this in SQL Server by killing off a session.

    The other feature was the addition of a one-time password for someone that might want to access their account from an unsecured terminal. At first I thought I’d never need to use this, but then I thought about all the times that I had accessed a server from a friend’s computer. Or how often I had a request for some data that required a new account. What if I could setup a one-time password for an account in Reporting Services that would allow someone to view a report, or download some data without permanent access?

    It would be an interesting way to handle ad-hoc access to systems. In the past I’ve usually enabled a specific  account for a short period of time, but then I’d have to set a reminder or remember to do disable it. That wasn’t something I always remembered to do.

    However allowing someone a one-time password might be a good way to allow them access to data they need on a limited basis. I could see the need for a one-time execution of a report being a feature that would allow me to distribute data easily for a single use. It could be very useful in ensuring that accounts that were granted rights did not have them forever.

    Steve Jones

    This was also published at SQLServerCentral, which includes a discussion of this piece.