Downloads
Ron describes how he decided to study Powershell as a single scripting system to automate all the common repetitive server tasks. He concludes that time spent learning PowerShell is time well spent, and that it can help a great deal in understanding the .NET Framework
I started studying PowerShell because I was looking for a quicker, more efficient way to gather information regarding my SQL Servers, and to manage my server workload better. I thought I was just going to learn yet another new scripting language that would help me do this. In fact, alongside providing a powerful means to automate many of my common, repetitive server tasks and heath checks, I've found that learning PowerShell has also proved a useful springboard to improving my skills with other, related technologies. For example, while learning PowerShell, I've found that I've:
In this article, I will describe several examples of using PowerShell that I would hope a DBA would find useful. My scripts will demonstrate how to run SQL queries, WMI queries or SMO code on one or more machines, and help you to better manage multiple database servers. All of the scripts have been tested on SQL Server 2005.
This article is not intended to be a PowerShell tutorial. I assume that you are familiar with the basic PowerShell terminology, how to get help with the cmdlets, how the command line works, how to run a script, what a pipeline is, what aliases are, and so on. If not, plenty of help can be found in various online articles, newsgroups and blogs (a reference section, at the end of the article, lists some of these sources). Some of the scripts I include with this article were derived from examples I encountered during my readings.
At the heart of multiple server management with PowerShell is a simple list of the servers on which you wish to run your routine tasks and health checks.
In my examples, I use a AllServers.txt file that simply contains a list of my servers, in the following format:
Server1
Server2
Server3
…
As I will demonstrate in the examples, I use this list to run a task against each listed server, using a foreach loop. This simple server list forms the cornerstone for completing repetitive tasks.
I work primarily in a Microsoft environment and I'm finding it quicker to perform repetitive tasks with Powershell than I previously did with Python. For instance, whereas Python needs multiple lines to open, read, and close a file, the get-content cmdlet in PowerShell reads a file with one line of code:
# Read a file
get-content "C:\AllServers.txt"
If even that feels like too much typing, you can invoke the get-content cmdlet via its alias:
gc "C:\AllServers.txt"
Figure1: Invoking the get-content cmdlet
The defined best practice is to use the alias at the command line and the complete cmdlet in scripts, for readability. You can list all the PowerShell aliases with the get-alias cmdlet:
# List aliases, sort by name or definition
get-alias | sort name
get-alias | sort definition
PowerShell is both an interactive command line and scripting environment.
I start solving a problem by executing commands at the command line. When I have established the correct sequence of commands, I save them to a script file with the .ps1 extension and execute it as needed.
PowerShell makes it easier for me to automate common, repetitive tasks across all my servers, and to deal quickly and efficiently with the seemingly-endless stream of ad-hoc requests for some bit of information about each of them.
The following sections describe just some of the PowerShell scripts I've created to automate these repetitive tasks. The examples progress from those I found the easiest to convert to PowerShell to those that took more effort to solve.
The easiest tasks to convert from Python to PowerShell were those that executed a SQL query against multiple machines. In these examples, the basic procedure followed in each script is as follows:
I run the following script to determine if my servers are at the approved patch level for our company:
# SQLVer.ps1
# usage: ./SQLVer.ps1
# Check SQL version
foreach ($svr in get-content "C:\data\AllServers.txt")
{
$con = "server=$svr;database=master;Integrated Security=sspi"
$cmd = "SELECT SERVERPROPERTY('ProductVersion') AS Version, SERVERPROPERTY('ProductLevel') as SP"
$da = new-object System.Data.SqlClient.SqlDataAdapter ($cmd, $con)
$dt = new-object System.Data.DataTable
$da.fill($dt) | out-null
$svr
$dt | Format-Table -autosize
}
The script follows the standard template I use for executing all of my SQL scripts against multiple servers. It uses a foreach loop to read through a list of servers, connect to the server and execute a query that returns the names of the user databases on each server. For this article, I have formatted the examples with comments in Green, PowerShell code in Blue and SQL in Red.
On a monthly basis, I must reconcile my real database inventory with an internally-developed database inventory system that is used as a resource by other applications.
# inv.ps1
# usage: ./inv.ps1
# Database inventory
foreach ($svr in get-content "C:\data\AllServers.txt")
{
$con = "server=$svr;database=master;Integrated Security=sspi"
$cmd = "SELECT name FROM master..sysdatabases WHERE dbid > 4 AND name NOT IN ('tracedb','UMRdb','Northwind','pubs','PerfAnalysis') ORDER BY name"
$da = new-object System.Data.SqlClient.SqlDataAdapter ($cmd, $con)
$dt = new-object System.Data.DataTable
$da.fill($dt) | out-null
$svr
$dt | Format-Table -autosize
}
The query returns the database names for all non-Microsoft supplied databases, sorted by server, and I then compare this to a report generated by the database inventory system.
This script, instead of a foreach loop, defines a function that allows me to remove the BUILTIN\Admin group from the sysadmin role on any server, simply by typing:
rmba ServerName
The function accepts one parameter, establishes the connection to the server and executes the sp_dropsrvrolemember system stored procedure.
# Remove BUILTIN\Administrators from sysadmin role
function rmba ($s)
{
$svr="$s"
$cn = new-object System.Data.SqlClient.SqlConnection "server=$svr;database=master;Integrated Security=sspi"
$cn.Open()
$sql = $cn.CreateCommand()
$svr
$sql.CommandText = "EXEC master..sp_dropsrvrolemember @loginame = N'BUILTIN\Administrators', @rolename = N'sysadmin';"
$rdr = $sql.ExecuteNonQuery();
}
This script saves me time since I don’t have to jump into Management Studio to complete the task. In the SMO section you'll find two other functions that I created to list the members of the sysadmin group and a server’s local administrators.
My next task was to get a quick view of free space on all my servers. In order to do this, I had to dip my toes into the world of WMI, which provides an object model that exposes data about the services or applications running on your machines.
The first obstacle here is figuring out what WMI has to offer. As soon as you start looking you'll realize that the object model for WMI (and SMO) is vast and you'll need to invest a little time in browsing through it and working out what does what.
MSDN is the best place to go for documentation on the WMI classes.
The WMI classes that will be the most useful to a DBA are the Win32 classes and you can use the following one-liner to get the list of all the available Win32 classes:
# Browse Win32 WMI classes
get-wmiobject -list | where {$_.name -like "win32*"} | Sort-Object
The classes I found interesting initially were:
The following examples will highlight the use of these and other classes of interest.
The simplest way to check disk space is with the Win32_LogicalDisk class. DriveType=3 is all local disks. Win32_LogicalDisk will not display mountpoint information.
# Check disk space on local disks on local server
Get-WmiObject -Class Win32_LogicalDisk -Filter "DriveType=3"
# Check disk space on a remote server.
Get-WmiObject -Class Win32_LogicalDisk -Filter "DriveType=3" -ComputerName ServerName
After a little digging around I found that, rather than try to calculate free space percentages from the output of the Win32_LogicalDisk class, it was easier to use the Win32_PerfFormattedData_PerfDisk_LogicalDisk class and its property PercentFreeSpace. In this example, I'm checking for drives with less than 20% free space. The other reason to use this class for checking disk space is that it will display mountpoint information.
# Checking disk space
foreach ($svr in get-content "C:\AllServers.txt")
{
$svr; Get-WmiObject Win32_PerfFormattedData_PerfDisk_LogicalDisk -ComputerName $svr | where{$_.Name -ne "_Total" -and $_.PercentFreeSpace -lt 20} | select-object Name, PercentFreeSpace | format-list
}
# Local computer example
Get-WmiObject -class Win32_PerfFormattedData_PerfOS_Processor -Property Name,PercentProcessorTime | where{$_.Name -eq "_Total"}
A quick way to find out which services are running on a remote server is to use the get-wmiobject, specifying the class, Win32_Service, and then the properties you want to list, and finally the computer that you wish to query. In this example, I'm just retrieving the name of the service:
# Checking what services are running on a computer.
get-wmiobject win32_service –computername COMPUTER | select name
If you want to see if a specific service is running on a remote machine use the filter parameter, –f, and specify the name of the service.
# Is IIS running on your server?
get-wmiobject win32_Service -computername COMPUTER -f "name='IISADMIN'"
gwmi win32_Service –co COMPUTER -f "name='IISADMIN'"
The output will look as shown in Figure 2:
Figure 2: IIS is running on my SQL Server. Panic!
SQL Server Management objects is a collection of objects that allows you to automate any task associated with managing Microsoft SQL Server.
Again, the biggest obstacle for the DBA who is unfamiliar with object-oriented programming is working through the rather intimidating object model. Again, as with WMI, you need to know how to examine an object to determine its available properties and methods.
In the SMO examples, you will again see the use of a foreach loop being used to execute SMO code against multiple servers. All of the examples begin by setting a reference to the SMO assembly. Once, you have established this reference, the script can then instantiate new objects derived from the classes in the assembly.
The SMO classes are documented in Books Online but it’s also helpful if you learn to list an object’s properties and methods. To browse the SMO classes, you need to set a reference to, and then use, the get-member (gm) cmdlet to display that object’s properties and methods.
# To examine the SMO Server object in PowerShell:
[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | out-null
$svr = new-object ("Microsoft.SqlServer.Management.Smo.Server") "ServerName"
$svr | get-member
To examine different objects change the second and third lines of the above script accordingly.
Depending on your previous experience, figuring out how the SMO object model works might prove tricky. I understood the basics of object-oriented programming but it didn’t really sink in until I was working on a script to list the sysadmin role members on my servers. Initially, I tried to use the code shown in Figure 3 and received the displayed error message:
# Before I understood the concept of objects completely, I tried…
[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | out-null
$svr="ServerName"
$srv=New-Object "Microsoft.SqlServer.Management.Smo.Server" "$svr"
$svrole = 'sysadmin'
$svrole
Figure 3: Incorrect object reference
I had a minor epiphany at this point. The concept of object-oriented programming and “Everything is an object” in PowerShell finally made sense to me. In the example in Figure 3, I had successfully created an instance of the Server object and, from there, wanted to work my way down to the ServerRole object for the sysadmin role. So, I set the variable, $svrole, to the string value ‘sysadmin’.
I then tried to invoke a method on that string object, thinking that I was, in effect, invoking a method on the ServerRole object. In this case, the $svrole variable only contained a string object not a reference to a ServerRole object. Thus, the error was thrown.
Method invocation failed because [System.String] doesn't contain a method named 'EnumServerRoleMembers'.
At line:1 char:30
+ $svrole.EnumServerRoleMembers( <<<< )
The following code sets the object reference correctly:
$svrole = $srv.Roles | where {$_.Name -eq 'sysadmin'}
Then, the command, $svrole.EnumServerRoleMembers(), will enumerate the members of the sysadmin server role on the selected server, as shown in Figure 4:
Figure 4: Enumerating the members of the sysadmin server role
The following script wraps the PowerShell code needed to list the sysadmins on a server into a function.
# create sa function to list sysadmin members
# usage: sa ServerName
[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | out-null
function sa ($s)
{
$svr="$s"
$srv=New-Object "Microsoft.SqlServer.Management.Smo.Server" "$svr"
$svrole = $srv.Roles | where {$_.Name -eq 'sysadmin'}
$svr
$svrole.EnumServerRoleMembers()
}
I use the following script (and the previous one) to keep to a minimum the number of people who have admin rights on a server and in SQL Server.
This example was inspired by Microsoft MVP Ying Li’s post on his blog demonstrating how to list local admins on a server (see the Reference section at the end of this article for the link). The function is supplied a server name. It then connects to the specified server and lists the members of the local Administrators group.
# create ListAdmins function to list local Administrators on a server.
# usage: ListAdmins ServerName
function ListAdmins ($svr)
{
$domain = [ADSI]""
$strComputer = $svr
$computer = [ADSI]("WinNT://" + $strComputer + ",computer")
$computer.name;
$Group = $computer.psbase.children.find("administrators")
$Group.name
$members= $Group.psbase.invoke("Members") | %{$_.GetType().InvokeMember("Name", 'GetProperty', $null, $_, $null)}
$members
}
One of my first SMO examples was inspired by my supervisor, who asked me to find out which database servers the data modeling group had access to. She was hoping it was only the development servers.
The following example ends up being five to seven lines of code, depending how you format it, but it will find a login/group on however many servers you have on your list.
# Find a login or AD group on multiple servers
[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | out-null
foreach ($svr in get-content "C:\AllServers.txt")
{
$srv=New-Object "Microsoft.SqlServer.Management.Smo.Server" "$svr"
trap {"Oops! $_"; continue } $srv.Logins | where {$_.Name -eq 'DOMAIN\ITS_DATA_ADMIN'} | select Parent, Name
}
The trap statement handles an error if one is encountered when the connection is made to a server. In this example, if there is an error connecting to the server, it will return the name of the server and the error message. Occasionally, I will see “Oops! Failed to connect to server SERVERNAME.” in the output.
Every morning I run the following script to check for any failed SQL Agent jobs on my servers:
# Check for failed SQL jobs on multiple servers
[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | out-null
foreach ($svr in get-content "C:\AllServers.txt")
{
write-host $svr
$srv=New-Object "Microsoft.SqlServer.Management.Smo.Server" "$svr"
$srv.jobserver.jobs | where-object {$_.lastrunoutcome -eq "Failed" -and $_.isenabled -eq $TRUE} | format-table name,lastrunoutcome,lastrundate -autosize
}
Pure PowerShell examples follow from here on out to answer a few more questions a DBA might have.
# List all installed hotfixes on a server
get-wmiobject Win32_QuickFixEngineering
# Check if a specific hotfix is installed on a server
get-wmiobject Win32_QuickFixEngineering | findstr KB928388
I’m often asked by a developer for the port number of a named instance. By combining in a short pipeline two cmdlets, get-content and select-string, you have a one-liner that find a port number in the errorlog text. This is much quicker than searching the errorlog manually, or running a bit of SQL code to return this result.
I did try to use select-string by itself to search the errorlog but, for some reason, select-string can’t read the active errorlog unless combined with get-content. In the following example, I search for the word "listening" in a SQL Server 2005 errorlog:
# Find a port number
gc \\ServerName\ShareName\MSSQL2005\MSSQL.2\MSSQL\LOG\ERRORLOG | select-string "listening"
The result is shown in Figure 5:
Figure 5: Searching a SQL 2005 errorlog
Keep in mind that if you have cycled the error log on your server the line you need to find might not be in the current error log and you will need to adjust the command below to search through your archived errorlogs by appending .1, .2, .3, etc. to ERRORLOG.
If you are searching an errorlog on a named instance of SQL Server 2000, you will need to escape the $ in the path with a backtick, as follows:
get-content \\ServerName\ShareName\MSSQL2000\MSSQL`$SQL100\LOG\ERRORLOG | select-string "listening"
If you need to generate a random password for a SQL login, use the following .NET class:
# generate a random password
[Reflection.Assembly]::LoadWithPartialName(”System.Web” ) | out-null
[System.Web.Security.Membership]::GeneratePassword(10,2) # 10 bytes long
[System.Web.Security.Membership]::GeneratePassword(8,2) # 8 bytes long
In my environment, I have two database configurations and the backups don't always land in a standard location. As such, I use a 'brute force' solution for checking my backups.
I have developed a script that checks that the backups are current for each of the servers that I support. The basic template is as follows:
# Checking backups are current
write-host ''
write-host 'ServerName'
get-childitem \\ServerName\ShareName\dump_data\*.bak | where-object { $_.LastWriteTime -ge (Get-Date).AddDays(-1) } | Select name, LastWriteTime
In the script, I repeat the above statement block for each server I need to check. Example output is shown in Figure 6:
Figure 6: Checking that Backups are up-to-date
If the server has multiple drives to be checked, I repeat the get-childitem cmdlet for the additional drives.
Here’s a slice of my full ChkBkups.ps1 script.
# checking three dump locations on a default instance.
write-host ''
write-host 'Server1'
get-childitem \\Server1\e$\dump_data\ServerName\*.bak | where-object { $_.LastWriteTime -ge (Get-Date).AddDays(-1) } | Select name, LastWriteTime
get-childitem \\Server1\g$\dump_data\ServerName\*.bak | where-object { $_.LastWriteTime -ge (Get-Date).AddDays(-1) } | Select name, LastWriteTime
get-childitem \\Server1\i$\dump_data\ ServerName \*.bak | where-object { $_.LastWriteTime -ge (Get-Date).AddDays(-1) } | Select name, LastWriteTime
# checking one dump location on a named instance.
write-host ''
write-host ' Server2'
get-childitem \\Server2\ShareName\dump_data\ServerName\Instance\db_dump\*.bak | where-object { $_.LastWriteTime -ge (Get-Date).AddDays(-1) } | Select name, LastWriteTime
I run this script each morning. We do have a set of automated routines that run nightly that handle the standard DBA tasks like backups, consistency checks, index maintenance, etc. Each server's maintenance process sends e-mails reporting on their status. This script saves me from having to read multiple e-mails.
I think using PowerShell will make me a better DBA because I have the means to automate mundane tasks, gather information quicker regarding my servers and manage my workload better. I've also found that using it has stretched my knowledge into areas I might not normally go, which can only be a good thing.
It is really striking to me how a few lines of PowerShell can do so much.
In my opinion, time spent learning PowerShell is time well spent.
I started with Bruce Payette’s book and the “Getting Started Guide”. I found a lot of good examples via Google by using simple search terms like: powershell sql; powershell smo; powershell wmi; powershell adsi; powershell blogs.
Bruce Payette’s book laid the foundation but all the people who have contributed to the newsgroup, blogs, and articles filled in the gaps. The section below is a just a subset of the materials I’ve used to learn PowerShell.
ADO.Net
SMO
WMI
PowerShell
Author profile: Ron Dameron
Ronald Dameron is a Senior Database Administrator for the largest life insurer in the United States. With almost 20 years of IT experience he has worked on a wide range of environments to include: mainframes, Oracle on Amdahl's Unix variant UTS, Sybase on AIX and Microsoft SQL Server since version 7. He is most comfortable with Microsoft SQL Server as a database developer and DBA. He is currently exploring how PowerShell can simplify his life as a DBA and the new features of SQL Server 2005. In his spare time, he enjoys rescucitating old PC hardware with Ubuntu Linux. To stay sane during his busy days at work, he practices the Yang style of Tai Chi or Power Yoga every morning. He feeds the hungry masses at his house with his Weber Kettle grill or the recipes of Rachel Ray.
When you are about to deploy a new version of a database by updating the current version, one of the essential... Read more...
Mr Flibble: As Seen Through a Lens, Darkly When things go awry The SQL Looks good but does it parse?
View the blog The Query Optimiser needs a good estimate of the number of rows likely to be returned by each physical... Read more... Continuous integration is becoming increasingly popular for database development, and when we heard of ... Read more... Often, there is a huge difference between software being easy to use, and easy to develop. When your... Read more... PowerShell is worth using when it is the quickest way to providing a solution. For the DBA, it is much... Read more... Quite often, the database developer or tester is faced with having to load data into a newly created... Read more... Steve Joubert begins an in-depth tour of SQL Server 2005 Reporting Services with a step-by-step guide... Read more... If database design is done right, then the development, deployment and subsequent performance in... Read more... SQL Server provides several "standard" techniques by which to read and write to files but, just... Read more... Given the fundamental importance of indexes in databases, it always comes as a surprise how often the... Read more... It is an interesting problem in Transact SQL, for which there are a number of solutions and... Read more...Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.
