Dan's Blog : PowerShell

Using PowerShell to Get Data & Log File Sizes

dtjones — Sun, 22 Mar 2009 00:42:06 GMT

I was playing around with PowerShell today (yes I’m was geeking out on Saturday afternoon) to learn how to access Performance Counters using PowerShell. My mission was to write a script that would return the Data File and Log File sizes for each database and a total for the instance. The good news is SQL Server already provides a bunch of fun performance counters and PowerShell has built-in support for accessing performance counters. I thought this was pretty cool so I decided to share it. In addition, I hadn’t blogged in a while and I was feeling bad about that.

There are two groups of scripts and sample output below: 1) Data File Space and 2) Log File Space.

Sorry about the formatting of the output I’m just being lazy today – after all it is Saturday.

Have fun with it!

Oh, btw: I was doing this on a Win7 machine (which I also need to give an update on) so I had to launch PS as administrator so it had access to the perf counters (same should be true on Vista and Windows Server 2K8). If you don’t launch as admin you’ll get an error that looks like this:

Get-Counter : The specified instance is not present.
At line:1 char:26
+ $DBDataFile = Get-Counter <<<< -Counter '\MSSQL$SQL2K8_01:Databases(*)\Data File(s) Size (KB)' -MaxSamples 1
+ CategoryInfo : InvalidResult: (:) [Get-Counter], Exception
+ FullyQualifiedErrorId : CounterApiError,Microsoft.PowerShell.Commands.GetCounterCommand

Data File Space

#Displays the total Data File size for each database (including system databases)

$DBDataFile = Get-Counter -Counter '\MSSQL$SQL2K8_01:Databases(*)\Data File(s) Size (KB)' -MaxSamples 1

$DBDataFile.CounterSamples | where-object -FilterScript {($_.InstanceName -ne "_total")} | sort-object -Property InstanceName | format-table @{Label = "Database"; Expression={$_.InstanceName}}, @{Label = "Total Data File(s) Size (MB)"; Express={$_.CookedValue/1000}} -AutoSize

Database Total Data File(s) Size (MB)

-------- ----------------------------

ansicheck 2.304

master 4.096

model 1.28

msdb 10.752

mssqlsystemresource 61.696

pbm-prototype 2.048

tempdb 8.192

We can also just grab the total Data File space used by the instance:

$DBDataFile = Get-Counter -Counter '\MSSQL$SQL2K8_01:Databases(*)\Data File(s) Size (KB)' -MaxSamples 1

$DBDataFile.CounterSamples | where-object -FilterScript {($_.InstanceName -eq "_total")} | sort-object -Property InstanceName | format-table @{Label = "Database"; Expression={$_.InstanceName}}, @{Label = "Total Data File(s) Size (MB)"; Express={$_.CookedValue/1000}} -AutoSize

Database Total Data File(s) Size (MB)

-------- ----------------------------

_total 90.368

Log File Space

#Displays the total Log File size for each database (including system databases)

$DBLogFile = Get-Counter -Counter '\MSSQL$SQL2K8_01:Databases(*)\Log File(s) Size (KB)' -MaxSamples 1

$DBLogFile.CounterSamples | where-object -FilterScript {($_.InstanceName -ne "_total")} | sort-object -Property InstanceName | format-table @{Label = "Database"; Expression={$_.InstanceName}}, @{Label = "Total Log File(s) Size (MB)"; Express={$_.CookedValue/1000}} -AutoSize

Database Total Log File(s) Size (MB)

-------- ---------------------------

ansicheck 0.496

master 1.016

model 0.504

msdb 0.504

mssqlsystemresource 0.504

pbm-prototype 1.016

tempdb 0.504

We can also just grab the total Log File space used by the instance:

$DBLogFile = Get-Counter -Counter '\MSSQL$SQL2K8_01:Databases(*)\Log File(s) Size (KB)' -MaxSamples 1

$DBLogFile.CounterSamples | where-object -FilterScript {($_.InstanceName -eq "_total")} | sort-object -Property InstanceName | format-table @{Label = "Database"; Expression={$_.InstanceName}}, @{Label = "Total Log File(s) Size (MB)"; Express={$_.CookedValue/1000}} –AutoSize

Database Total Log File(s) Size (MB)

-------- ---------------------------

_total 4.544

PowerShell vs. T-SQL or Why Did We Add PowerShell Support in SQL2K8

dtjones — Fri, 29 Aug 2008 19:29:33 GMT

The following write-up was originally an email I sent to Allan White (SQL Server MVP) in the context of a discussion on PowerShell and some of the PowerShell community postings questioning why SQL Server needed PowerShell support @ all given the strength of T-SQL. Allan and others encouraged me to post the response. I realize there are times when the SQL Server product team appears opaque. In general this is not intentional. There are situations when we're working on very new stuff that cannot be discussed publicly (we function in a very competitive market), but generally we want to engage with the community and share the reasons we make certain decisions. I hope you find this posting informative and interesting. Note: I edited the original email just a little so that it made sense without the additional back and forth threads.

Within Microsoft we have a concept called Common Engineering Criteria (CEC). The goal of CEC is to establish consistency across IT products (Windows Server, Exchange, SQL Server, BizTalk, System Center, etc). Some of the requirements of CEC include items like virtualization support, security requirements, System Center support, localization requirements, and installation and patching requirements. I’m sure I don’t need to go into detail on why this is a good thing for our customers.

One of the latest CEC requirements is support for PowerShell. The old requirement used to be generic support for scripting. Imagine a world where every product used a different scripting syntax and had different constructs for error handling and procedural execution. Yuck! Just the cost to develop and maintain this would be enormous. There would be no consistency and each team would reinvent the wheel. This all might be fine if users never used more than one product. But we know that’s not the case. Lines of responsibility are blurring and IT professionals have to learn and use multiple products. Developers also must use multiple products.

While DBAs have traditionally been a specialized bunch and typically work solely with SQL Server we see this changing. For example, think of SharePoint. I had a number of people come up to me @ TechEd this year asking questions about SQL Server from a SharePoint perspective. These people have never written Transact-SQL and have no clue what a foreign key relationship is. They have no interest in learning T-SQL, rather they have a business need to keep the environment up and running – that’s what they’re measured on. If both products (SharePoint and SQL Server) implement a similar scripting language this person is instantly more comfortable – there’s automatic orientation. Yes there are new nouns and verbs to learn but there isn’t new syntax to learn. The fact that both products leverage the same scripting language places power in the user’s hands. They don’t have to “shell out” of one environment to make something happen in another.

Transact-SQL is a good scripting language but it’s not model driven. We will continue to invest in and evolve T-SQL. But we’ll also continue to invest in and evolve the models over DDL and DML. The model over DDL is SMO. The model over DML is EDM. We built PBM over SMO. This gave us instant backward compatibility with SQL2K5 and SQL2K. If we had to develop our own model over T-SQL we would have had to build the backward compatibility on our own. Frankly we wouldn’t have done this as the cost would’ve been too great. We also expose PBM in PowerShell which opens up use cases that wouldn’t be possible without extending the T-SQL language (an expensive proposition) or forcing DBAs to write C# or VB to accomplish seemingly simple tasks.

Take a database backup as an example. As part of the backup script I may want to find a volume which has greater than a minimum amount disk space and back-up to that drive. How do I do this in T-SQL? Or take a script that needs to be aware of the OS or processor the instance is running on. How do I get that from T-SQL? I’ve had a number of requests for help building policies which we just can’t do because either we don’t have a facet to support it or T-SQL can’t get access to the information. But if PBM had PowerShell support we’d be golden. As an aside, I really wish we added PowerShell support to PBM in the form of an ExecutePowerShellScript() function. We didn’t because of time constraints. Yes we can always add this stuff to T-SQL but we’ll be in a perpetual state of catch up. That’s a frustrating place for us and our customers.

Both PowerShell and our implementation on PowerShell are v1 products. They will evolve and get better. SMO is a v2 product and it’s evolving and getting better. In SQL11 we’ll make investments in T-SQL. Our goal in SQL Server manageability is to get out of the business of delivery one off tools and move to a state where everything is model driven. This creates an environment that is far more consistent and predictable. It allows us to build capability once and expose it in many places. For example, we want to get to the point where all we have to do is add a new object to SMO and it’s automatically available in PowerShell, SSMS, PBM, System Center, etc without making changes to those environments.

APIs aren’t always user friendly. The implementation may be pure from a coding and relationship perspective but from a usability perspective it may be hard to work with. Take a table object in SMO. It takes a lot of “work” to construct a new table in SMO. It’s far easier in T-SQL. But if I don’t know T-SQL and I know PowerShell wouldn’t a create-table cmdlet be valuable to me? The same goes for backing up a database. This is where the power of models and abstractions are realized. After all, when was the last time you wrote assembly code?

TechEd North America Session Videos

dtjones — Thu, 31 Jul 2008 18:00:51 GMT

In shameless self promotion the video of the talk I did on PowerShell and SQL Server has been posted to the web. I haven't watched this as I just can't bring myself to sit and watch myself for an hour but the session evaluations were pretty good. Therefore I think the odds are pretty good you'll get something out of this session, especially if you're new to PowerShell. A bunch of other talks have also been posted. Here's the landing page for the videos.

Launching Vanilla PowerShell from SSMS

dtjones — Tue, 01 Jul 2008 20:22:28 GMT

One of the criticisms of our PowerShell implementation is the integration with Management Studio launches our custom minishell. With just a few simple key strokes you can add a custom tool menu item and toolbar button. To do this select "External Tools..." from the "Tools" menu in Management Studio.

The following dialog is displayed.

The above picture shows the dialog filled in to launch the vanilla PowerShell shell. You could add custom arguments, such as -nologo, if you desire and you can set the default directory. You could also use this to run a specific script. The title you enter will show up in the "Tools".

Once you've registered the custom tool you can add it to any toolbar. Here I'll add it to the default toolbar. Just select "Customize..." from the "Tools" menu.

The Customize dialog will be displayed. Unfortunately Visual Studio doesn't replace the generic "External Command 1". In this example I only have one external tool defined so I'll grab "External Command 1" and drag it to the toolbar.

This adds a button to the toolbar to launch the custom tool. Thankfully Visual Studio replaces the generic name with the name entered into the Title field.

The first-class integration on the Object Explorer context menu will launch you into SQLPS.exe directly to the selected object. This integration won't do the same but if you need to shell out into vanilla PowerShell this is a quick way to do so from within SSMS. If you combine this with the registration of the SQL Server provider extensions in a vanilla PS environment you might just get close to the best of both worlds.

The SQLPS Firestorm Part Duex

dtjones — Wed, 25 Jun 2008 03:45:25 GMT

On the PowerShell team's blog Architect Jeffrey Snover addresses the recent firestorm on SQLPS.

BTW: he was a lot nicer about the engagement model than I would have been. I do want all feedback, positive and critical. Just make it constructive. Getting nasty and throwing insults just makes you look like an idiot and ensures the person you want to receive your message will stop listening.

The SQLPS Firestorm

dtjones — Thu, 19 Jun 2008 09:15:15 GMT

Within the PowerShell community there's a firestorm raging over SQLPS.exe our mini-shell that we're introducing in SQL2K8. In his blog Michiel does a good job explaining the mini-shell and provides a script you can use to register the SQL Server provider extensions in a vanilla PS environment.

I love it when people who obviously have zero commercial software experience pontificate about what's right and wrong. Actually I don't love it. It something that pisses me off big time. These individuals think they're "helping" but they're not. They make claims that they want to understand but they don't really. To them the world is binary - they're TRUE and everyone who disagrees with them is FALSE. In elementary school we called these people bullies.

I'm purposefully not naming names here as it will do no good. I have no interest going head to head with them. It's a no win proposition - in fact everyone ends up loosing.

I don't like using this blog to air my opinions, I much rather focusing purely on technology and SQL Server. But they're defamation of the SQL Server team is simply uncalled for.

I'm very proud of the work the team did in SQL2K8. Is everything perfect? Absolutely not. Are we adding a ship load of value to the product? Absolutely.

If you don't like what we've down with PowerShell you're free to roll your own. PowerShell is an open environment for which you can register your own providers and build your own cmdlets. There's no restriction that states you must use sqlps.exe. Even within SQL Server Agent you can use the cmdshell subsystem to call powershell.exe directly. But we believe the vast majority of people will find value in sqlps.exe and the PowerShell subsystem in Agent. Hence why we built it.

Send us your feedback through http://connect.microsoft.com/sqlserver and I promise we'll listen. It doesn't mean we'll implement every suggestion but we'll listen. I've been developing software @ MS for over 4 years and the amount of debate and discussion that goes into key decisions is often mind numbing. Maybe it looks like we simply pull the answer out of our ass but that's not the case. We look at it from every angle and consider all of our constraints to arrive at the most optimum solution.

TechEd 2008 is Done!

dtjones — Fri, 13 Jun 2008 23:44:39 GMT

I'm writing this on the plane from Orlando back to Seattle. I have lots of thoughts on TechEd that I'll try to get through before I run out of battery or the guy in front of me snaps my laptop display. I also want to answer a few of the questions that came up that I couldn't immediately answer. I'll post the code from the sessions on another blog post. The PBM code will be posted to the PBM blog.

I am thoroughly impressed by our customers. They have incredible passion for our products and an endless desire to learn how to use our products more effectively, intelligently, efficiently, and completely. I thank each and every one of you for making my job so fun and pleasurable. Thank you for coming up and asking questions (whenever and wherever), thank you for submitting your evals - I take the feedback to heart, and thank you for betting your business on SQL Server. Without you I'd probably be a starving musician.

I did a ton of time at the booth, co-presented one interactive theater on using SQL2K8 for compliance, participated in two Tech-Ed Online Panels (TEOPs): Compliance and Automating DBA Tasks, presented a breakout (BRK) session on PowerShell and co-presented a session on Policy-Based Management.

Interactive Theater: I'm undecided if I like this format or not. Maybe it's just that compliance is a tough topic to discuss since there is so much interpretation that has to happen and there's no one-size-fits-all solution. I co-presented this with Il-Sung Lee a security PM in SQL Server. Il-Sung is so knowledgeable about his space and gave the audience a very good taste of Transparent Data Encryption (don't forget to backup the certificate!) and Auditing. I had directed on person that came to the security kiosk to the session. They came up to me afterward and thanked me.

TEOP: Compliance: This was fun although we didn't have much of an audience. I really like this format and encourage the TechEd planners to extend it. The people on the panel make all the difference.

TEOP: Automating DBA Tasks: Wow, I was up there with Allen White (SQL MVP), Steve Jones (SQL MVP), Kevin Kline (SQL MVP), and Buck Woody (former SQL MVP and now a PM on the SQL Server team). Talk about a humbling experience. It was absolutely fantastic. These guys are terrific and posses such incredible knowledge about SQL Server and the role of the DBA. Great job guys!

BRK: PowerShell: The feedback on this session was that I didn't spend enough time on SQL Server and too much time on vanilla PowerShell. Honestly this was by design and I think after people get back to the office and start using PowerShell they'll understand why I structure the session this way. One question that came up was the use of DAC (Dedicated Admin Connection). This is not support within PowerShell or our PowerShell provider. Another question was the use of SQL Logins. It's possible but not totally clean. It's documented in BOL here. There were more questions which I asked people to email. I'm still waiting for the email! Once I get them I'll post them.

BRK: PBM: I want to thank Peter DeBetta (SQL MVP) for co-presenting with me. I think Peter knows some facets (pun intended) of PBM better than I. BTW: My wife won't let me name the boy Wequel Sequel Jones - probably a good thing. This was, however, a tough session. It'd didn't flow the way I wanted it to. The feedback was that it was a little disjointed. Not to mention I messed up and thought the session started at 4:45 rather than 4:30. Sorry for blowing the first 7 or 8 minutes. But hey who doesn't like a good Bugs Bunny cartoon. The passion for PBM is immense. I remain convinced PBM is going to forever transform the management of the data platform. Y'all will get to say you were there when it all started. There were also some questions during this session that I didn't have the answer to. If you're out there please email your question. If you forgot my email address you can always send it through the blog.

Thank you for making my experience at TechEd valuable and memorable. I don't like taking time away from my family unless it's truly valuable and fruitful. Once again you, the customer, have satisfied both. I hope you got as much out of the experience as I did.

One final note: If you're the guy that came up to me at Universal asking about my round at Pebble Beach I apologize for costing you $10. I pared a few holes (namely 7 and 17!). But I had a few disasters (namely 2 and 8). We don't have much sand on our courses in Seattle so that part of my game is out of practice. Also it was my first full round in 6 months and the first round after breaking my collar bone in January. I won't try snowboarding again!

PowerShell Resources

dtjones — Sat, 07 Jun 2008 00:50:10 GMT

SQL Server Books Online

PowerShell Team

Books

Windows PowerShell in Action by Bruce Payette
Windows PowerShell Cookbook by Lee Holmes

Other

More PowerShell

dtjones — Sun, 30 Mar 2008 05:00:19 GMT

Check out this blog entry for BgShell a new PowerShell host. I'm just amazed at the endless possibility PowerShell provides. I haven't pulled this down yet, but I could imagine using it to automate common daily tasks. The problem I encounter is I don't have that many repetitive tasks; although if I could get it to reply to my email for me that would be very cool!

Getting Started with PowerShell

dtjones — Fri, 07 Mar 2008 18:59:38 GMT

The February CTP for SQL2K8 included first class support for PowerShell. Many people have ask how they can get started with PowerShell - not just using PowerShell to interact with SQL Server but just using PowerShell in general. PowerShell was a wealth of powerful features built-in. Here are a few PowerShell resources to get you started. In short, it's time to throw out those VBS scripts and move to the powerful world of PowerShell. After all, they it wouldn't have "power" in the name if it wasn't "powerful"!

Main PowerShell page: http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx

Getting Started Guide: http://msdn2.microsoft.com/en-us/library/aa973757.aspx

Channel 9 PowerShell Wiki: http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellWiki

On Demand Web Cast (Windows PowerShell and Manageability Improvements in Windows Server 2008): http://technet.microsoft.com/en-us/bb899729.aspx