Microsoft

PowerShell, Sport of the Future

Geoff N. Hiten — Mon, 29 Sep 2008 16:20:23 GMT

No wait, that’s kickboxing. PowerShell is the something of the future. The management interface, the uber-scripting language, the what???

PowerShell, and its SQL-targeted implementation shipped with SQL Server 2008, brings to mind Michael Faraday’s response when asked “What use is electricity?” He replied “What use is a newborn baby?” PowerShell is somewhat of a newborn baby, much like the very early versions of SQL-based databases were. We see how those databases have grown and transformed IT and business in ways we never thought of. Maybe the future of PowerShell is just as bright?

Enough philosophy, let’s see if we can put this baby to use. Rather than the obligatory “Story of PowerShell”, I am just going to dump you to the Windows PowerShell home page. http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx You don’t need me to rehash the story or to write yet another “What is a cmdlet” post.

Now, let’s play with this toy and SQL Server. SQL 2008 installs a SQL-Specific provider into PowerShell when launched from SQL Server Management Studio. BOL includes instructions on how to configure PowerShell to add the SQL provider by default or to launch SQLPS.exe outside of SSMS.

The SQL Provider allows you to browse any SQL Server system list like the file system. While this is all based on SMO (Server Management Objects), this is not exactly the same as browsing the SMO object model. As a matter of fact, the toughest thing in PowerShell is bridging the gap between the provider and the object model. Part of this is that the SMO object model is somewhat flat, while the provider shows as a hierarchy.

Start with the provider and drill down to a particular column. You get something like this:

SQLServer:\SQL\MachineName\InstanceName\Databases\Adventureworks2008\Tables\Sales.CreditCard\Columns\CardNumber

If we want an SMO object for the current item we do this:

PS SQLServer:\...\Sales.CreditCard\Columns\CardNumber> $MyColumn = Get-Item .

Note the “.” at the end. Very important. You get an error otherwise

If we just wanted a “blank” Column object we would do this:

PS SQLServer\...\Sales.CreditCard.Columns.CardNumber> $MyColumn = New-Object –TypeName Microsoft.SQLServer.Management.SMO.Column

Pretty much every object for SQL is directly under SMO in the object model, regardless of where it is in the provider hierarchy. This makes it easy to find the documentation on each object since the links are all on one page. The provider hierarchy should look very familiar since it is very close to what we see in SSMS.

Now we can create objects mapped to actual provider locations which represent real server elements. From here it is not so hard to get or set properties, invoke methods, and make a lot of adjustments within the SQL Server system. Since SSMS is based on SMO, we can reasonably assume that any task in SSMS can be accomplished from PowerShell. Remember, PowerShell is a scripting environment, not an application development environment. Some of the things in SSMS require a lot of “glue” to tie the object changes together to accomplish a particular task.

This brings us back to why is PowerShell for SQL still a baby? Well, a baby can only do three things (eat, cry, poo). PowerShell is not quite as limited, but it is really only good for automating some very specific tasks and not for general SQL Server operation and maintenance. I see two critical cmdlets missing in the SQL PowerShell story before we can say it has grown to the next stage. Copy-item and New-Item would make SQL much more complete. Right now, if I want to create a copy of a table, alter its properties by adding a column and change its database (called a parent in the object model), then write the changes to the server, effectively createing the altered table in the new target database, I would have to drill down and copy each column and each property of each column individually. Copy-Item does with other providers such as the file system. Right now, if you try to invoke the Copy-Item cmdlet you get:

Copy-Item : SQL Server PowerShell provider error: Copy-Item is not supported.

And yes, it is bright red by default.

New-Item is a close cousin. If I back up to the columns level (cd ..) and want to add a new column, I cannot use New-Item. I get:

New-Item : The method or operation is not supported

This error message gives me hope that maybe I am not doing something correctly, but I suspect it is also not completely implemented. I get the same message when I execute it at the database level of the provider.

So, while PowerShell is unfinished, it is still a cool tool do script a lot of tedious, repetitive junk where you just set the same thing over and over or to retrieve the same thing from all databases/tables/etc. For version 1, I give it an “A”.

More, More, More

Geoff N. Hiten — Wed, 13 Aug 2008 17:45:27 GMT

Fast on the heels of SQL 2008 is the Feature Pack for SQL 2008. Cool goodies include stand-alone installers for SQLCMD and the SQL Native Client, SQL 2008 Server Management Objects, SQL 2008 pre-defined Policies, and lots more.

You can find it here.

http://www.microsoft.com/downloads/details.aspx?FamilyId=C6C3E9EF-BA29-4A43-8D69-A2BED18FE73C

Wait for it...

Geoff N. Hiten — Thu, 07 Aug 2008 17:09:19 GMT

It looks like SQL 2008 may have a slight dependency issue. If you have already installed Visual Studio 2008, you will be blocked from installing SQL 2008 until you install Visual Studio SP1. The problem is that Visual Studio SP1 is not released yet. Our guys came in ahead of schedule and they still get no respect.

Not to worry, Visual Studio 2008 SP1 should be out very soon (think days, not weeks) and this problem goes away.

Microsoft actually documented this issue here:

Visual Studio 2008 SP1 may be required for SQL 2008 Installations

http://support.microsoft.com/kb/956139

--GNH

UPDATE: It's Here

http://www.microsoft.com/downloads/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=en

DONE!!!

Geoff N. Hiten — Wed, 06 Aug 2008 18:06:54 GMT

SQL 2008 is finished. MSDN has all the bits downloadable now. Expect retail versions shortly.

Update: SQL 2005 Build 3186 Cluster problem

Geoff N. Hiten — Mon, 12 Nov 2007 21:09:24 GMT

Microsoft does not have a complete resolution for this problem yet, but they have found some more details. Evidently the problem with SQL Agent failure only occurs on systems using a domain admin account for the SQL Agent Service account. Microsoft is not 100% sure yet, so this is just a preliminary finding. However, it does match my own personal experiences. Worst Practices always has a cost. Several DBAs just found that out the hard way. Just as a reminder, this problem only occurs on x64 clusters using SQL Server 2005 build 3186 and higher.

SQL 2005 Build 3186 Cluster problem

Geoff N. Hiten — Thu, 11 Oct 2007 17:53:35 GMT

SQL 2005 Build 3186 has a major negative side effect on x64 clusters. Installing it pretty much kills the SQL Agent.. The workaround is to enable unconstrained delegation for the machine and the service accounts. Not exactly a best practices security setting, but necessary. For now, if you are on an x64 cluster and don't have a compelling reason to install this hotfix, you may want to wait until this issue gets resolved.

Here is the MSDN thread discussing the problem and the workaround:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2242421&SiteID=1

UPDATE: Build 3200 (Cumulative Update 4) has the same issue. Evidently this bug is due to a complex interaction between SQL and Windows Security. I would not expect a quick fix. I can confim that this definitely has major visibility and resource assignment within Microsoft. It just isn't an easy problem to solve.

BEGIN TRY

Geoff N. Hiten — Tue, 25 Sep 2007 18:40:06 GMT

Hopefully, I won't need a CATCH Block.

In case that opening sentence didn't give you a hint, I am a bit of a tech geek. Bill Graziano talked me into joining this merry band while at the PASS summit last week. While I enjoy answering questions on newsgroups, this will give me a way to initiate conversations. I looked around and decided SQLTeam would be a good place to stand and pontificate.

And now for some real SQL content. Sort of.

Based on a lot of presentations by Microsoft on proposed features and bug fixes, I have to conclude that Connect really matters. Connect is Microsoft's feedback center. While the list of complaints about Connect is quite long, it has one overwhelming benefit. The Microsoft SQL Development team actually pays attention to it. Not only that, but Microsoft is allocating resources based on feedback gathered from Connect. So get over the fact Connect seems modeled after a particularly clumsy session of "Messenger" at a Jr. High School party and use it. Post bugs. Post Suggestions. Vote early and often. You want to influence the product and you don't happen to have Ted Kummert's digits on the speed dial. Here is your chance.