Voice of the DBA

Tag: career

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

  • Powershell in a Month Day 13 – Remote Control

    This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

    Remoting. It sounds complex, and intimidating. It isn’t, and it’s powerful. It’s also essential, allowing you to access commands on remove machines.

    The chapter starts with the idea of remoting, and running commands elsewhere. We learn this comes from telnet and other remote type access, and is implemented as a web services protocol, WS-MAN. Incidently, this is how SSMS works. Your T-SQL is executed remotely on the server, not on your workstation. Lots of people don’t get that and get confused.

    This chapter presents a challenge. You need a domain for security to work correctly, or easily, with remoting. There are potential workarounds, but it’s an issue. I haven’t had a domain at home because of overhead and not wanting a domain controller set up. That means some setup work to build a couple virtual machines and create a domain.

    Ugh. Annoying, but it’s something I should do. I have wanted to rebuild a domain for some time, but haven’t bothered, but this is the excuse to do so. As such, I read the chapter, and started setting up the domain. That will take a few days, so I’ll continue on with the next chapter as I get a domain ready. More notes to come once that’s done.

  • Powershell in a Month Day 12 – A Practical Interlude

    This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

    This chapter is a practical one. Build a scheduled task that removes all jobs from a certain printer. Not that hard, but we’re using Powershell, and I’ve never done this for sure.

    The chapter walks you through a process, though I’m not sure this is the best one. After all, building scheduled tasks from Powershell seems to be overkill, especially since I’ve rarely scheduled the same thing across multiple machines. Except SQL Agent, and there it’s certainly easy to use T-SQL to do so. However, I get the idea. They want you to work through looking for commands, and then figuring things out within Powershell.

    The other problem I have from this item is that there are typos. The command they first show with a parameter of “printer”, but that caused me errors. It needs to be “printername”. That threw me at first, and made me think if things didn’t work, I wouldn’t know where the errors were.

    As I worked along with the authors to create a task, trigger, action, etc. I felt somewhat empowered, but I also felt that they didn’t quite explain the details enough of how they delve into the commands. A lot of information is returned when you run help, and it can be confusing or difficult to choose which items to link and how. Overall, I felt they shortcut’ed the explanation a bit for people learning Powershell.

    However, the lab was similar. Create a folder and share it.

    I’ve done this lots of times, but not with PoSh. I knew that many of the DOS commands like “mkdir” work, but I wanted to find out what was the basis. A little help showed me this was the New-Item command. A few experiments and I had created a C:\Labs folder on my machine. I was thinking this would be a pipeline command, so I saved it.

    $cf = New-Item -path "c:\labs" -type "directory"

    When I saw the folder in Explorer, I felt a bit proud of myself.

    From there I dug into help with *share* and found the SMB share items. I’ve know that file sharing was with SMB, but I could certainly see some DBAs and others wondering. When I’ve used “SMB” in a few talks, I’ve gotten some blank stares at times. Anyway, I completed the task easily, and figured out I couldn’t pipeline these tasks. However, I had remembered somewhere in my mind that ($cf) would execute that variable, and that worked.

    Overall this was a good chapter and exercise. I could certainly see this lab being handy as I’ve often wanted to standardize things, like backup directories, on a lot of servers. I’ve even had standard shares at times.

    This was a good building block to learning how to assemble some commands and accomplish a task. I’d like to see 2-3 small tasks like this to help learn how to build to bigger projects. Perhaps that’s coming.

  • Powershell in a Month Day 11 – Filtering

    This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

    I’ve learned that the dash (-) is going to be my friend. Filtering and comparisons are the backbone of SQL. We use them all the time in our WHERE clauses. In Powershell, we have similar comparisons as I’ve seen, but almost always as I use the eq, ge, le, ne, etc. comparisons, there is the need to include a dash before them. Same thing for -and and -like (see I’m doing it).

    This chapter looks at filtering, and how you can reduce the information returned from cmdlets to just those items that you need. The idea of “filtering left”, meaning including the filter as soon as possible in the command. Since commands are interpreted and executed left to right, filtering left means less processing where possible. However since not all cmdlets include a -filter parameter, you must use the WHERE-OBJECT cmdlet.

    Overall, the idea of filtering and using comparisons is very much core to what we do in SQL and what happens in many programming algorithms as we look to make decisions in our applications. This chapter helps to understand this.

    I also learned about the “$_.” syntax, which is really  a way to specify a generic object and then specify a property for all instances of that object. So if I’m looking at the name for something, I want to use “$_.Name” syntax. I had wondered what that was for in the last chapter, but now this makes sense.

    The lab, however, was challenging. I want to use the WHERE syntax when I can do things easier. For example, getting a list of services whose names are “conhost” or “svchost”. I entered:

    PS C:\Windows\System32\WindowsPowerShell\v1.0> get-process | where {$_.Name -match "Conhost" -or $_.Name -match "Svchost"}

    Way too much overkill. This would do it.

    get-process -name conhost,svchost

    That’s an area where I need more practice and need to work on things. I suspect much of my initial Powershell work will be more complex, without filtering occurring in the most left point it could unless I manage to understand the details of various commands.