Search results matching tags 'SQL Server 2008' and 'DBA'

Start a SQL Server Agent Job using the SQL Server PowerShell Provider

BuckWoody — Wed, 10 Feb 2010 13:13:45 GMT

Whew! That’s a mouthfull. Anyway, I thought I would share part of a script I wrote today to help automate (more) from PowerShell. This assumes a few things: that you’re doing this from the SQL Server 2008 PowerShell provider (not just good old regular PowerShell) and that you change the HAL9000 and SQL2K8 parts with your server name and your Instance name. Oh, and the Jobs I start are called “Test” and then something else. That’s the Test* part. You can use a specific name and drop the * or use your own naming convention.

Script Disclaimer, for people who need to be told this sort of thing:

Never trust any script, including those that you find here, until you understand exactly what it does and how it will act on your systems. Always check the script on a test system or Virtual Machine, not a production system. All scripts on this site are performed by a professional stunt driver on a closed course. Your mileage may vary. Void where prohibited. Offer good for a limited time only. Keep out of reach of small children. Do not operate heavy machinery while using this script. If you experience blurry vision, indigestion or diarrhea during the operation of this script, see a physician immediately.

# Start a Job named Test in the SQL Server 2008 PowrShell Provider

DIR SQLSERVER:\SQL\HAL9000\SQL2K8\JobServer\Jobs\Test* | % {$_.Start()}

FILESTREAM: Storing Binary Objects in a database – or not

BuckWoody — Thu, 28 Jan 2010 14:47:16 GMT

Many shops need to store binary large objects (sometimes called BLOBS) in a database. There are really only two ways to do this: store in them in a table structure in the database itself using a binary data type, or store them in the operating system in a file folder somewhere and point to the file using a text field in a table.

Both of these approaches have issues. Relational Databases aren’t really designed to hold that much data in a single field – not ours, not anybody’s. And pointing to a file is risky, since the file might change, it isn’t under database control for security and backups and so on.

Enter FILESTREAM. In SQL Server 2008 we introduced a feature that actually combines the two approaches into one. Using FILESTREAM, you enter the data into a “column”, but in fact SQL Server stores the data on the hard drive. It’s lightning fast, doesn’t lose the “pointers” to the files, and keeps the whole thing under database control. You can secure it with the same permissions as the database, and it gets picked up in backups and so on.

It does have some limitations and caveats, so be sure and check out the reference data in the following link. And then try it yourself – pretty easy to set up and manage.

http://technet.microsoft.com/en-us/library/bb933993.aspx

Know Your Product Specifications

BuckWoody — Wed, 13 Jan 2010 14:57:01 GMT

As the Data Professional in your organization, the rest of the org looks to you to ensure that the system can handle what the business requires. To do that, you need to know two things: what the business requires, and what SQL Server can do.

But of course there’s a bit more to it than that. Knowing the business side of the requirements – well, I teach an entire course on that. But knowing what SQL Server can do is something you can find out on your own.

SQL Server comes in versions, which are released based on date, and editions, which are based on features and capabilities. It’s that last part that I want to focus on today.

As Microsoft SQL Server matures, you’re going to see even more separation between what each edition of SQL Server can do and where it should be used. In the past, most folks have only focused on three editions – Express (the “free” one), Standard, and Enterprise. The rule of thumb was that if Standard was good enough at the moment, put it in. And it is true (and a good thing) that you can upgrade from one edition to another fairly easily.

But as time goes on, we should spend a little more time understanding what each edition does, what it’s features and capabilities are, and where and when we should put them in. As I study this information, I’ll throw in my 2 cents and you can as well based on what you see. One thing I’ve found so far is that once I have the business requirements, there’s a mix of what I can write in code and what might already be included in a different edition. It’s important to look long and hard at that choice – writing a feature on my own is certainly cheaper in the short term than moving to a “higher” edition, but in some cases it makes sense to let Microsoft handle that lifting.

These links are ones that you should bookmark and take a peek at periodically. They are the “header” links for more information on those features and capabilities:

SQL Server 2008: http://msdn.microsoft.com/en-us/library/ms143287.aspx

SQL Server 2008 R2: http://msdn.microsoft.com/en-us/library/ms143287(SQL.105).aspx

In addition, you might start learning a little more about SQL Azure. I’ll talk more about that later.

Spit it out already!

BuckWoody — Wed, 06 Jan 2010 14:11:11 GMT

You’ve probably seen that commercial where the chewing-gum company van stalks the guy who has been chewing the same piece of gum too long, and they attack him and make him chew another piece.

I feel like that with SQL Server 2000. Almost every shop I go into has at least one primary application running on SQL Server 2000. Now, don’t get me wrong – SQL Server 2000 is a fine piece of software engineering. From over TEN YEARS AGO. In “software time”, that’s like a thousand years or something.

While it was great for its day, the newer versions are faster, more secure, and more robust. And every time it doesn’t get upgraded, SQL Server is perceived as “not as fast/strong/etc” as other platforms (which are upgraded, of course).

Now, I’m not suggesting that anyone upgrade for upgrade’s sake. We all have work to do, and the last thing we need to do is change out a platform when there’s no need.

But there is a need. SQL Server 2000 isn’t in mainline support any more. That means it can be attacked easier and so on. And it doesn’t scale like the new offerings, nor does it have any of the new features the latest versions have.

“Oh”, you might say, “I don’t use those features anyway.” Well of course you don’t – you can’t if you still have SQL Server 2000! How do you know the ways you could help your organization if you don’t experiment with the new stuff?

But it isn’t the DBA I would chase down and steal gum from. It’s the vendors.

Every time I raise my eyebrows when I hear about the SQL Server 2000 installs, the DBA shrugs and says “The vendor won’t certify SQL Server X, so we have to stay at SQL Server 2000 or 2005.” And I say, that’s just lazy. Unless the vendor codes specifically for deprecated features, a simple test run during their software development should allow them to move forward. I’m not saying that’s an easy task, but certainly they’ve tested their software releases once in the last ten years, no? If not, doesn’t that make you nervous?

Anyhoo, spit out the SQL Server 2000. Or I might have to fire up the company van.

After the Upgrade, it runs differently…

BuckWoody — Tue, 01 Dec 2009 16:06:55 GMT

I got a question yesterday in the mail that I thought I would just answer here in a broad context. While I can’t troubleshoot or do performance tuning from a distance, there are some interesting concepts and suggestions this e-mail brings up:

“I have recently seen a change from SQL Server from 2005 to 2008 in where it handles CASE statements differently. Previously we saw a tremendous improvement in performance by using CASE statements instead of OR statements. However when one of our client upgraded to 2008 they began to notice unusually long runtimes with a few of these queries (orders of magnitude larger runtimes). Swapping it to an OR statement allows it to run in 0.075 seconds... so my question to you is do you know of any changes to the exectution engine that would account for this and what is your recommendation?”

It’s a great question. Basically it boils down to “I changed versions, now something acts differently.” Before we talk about what might be the issue, let’s talk about some things you should do after you upgrade from one version of SQL Server to another.

First, open the database properties and change the compatibility level to 10.0, unless you know you shouldn’t. Next, update your statistics – all of them. Third, ensure you have all of the proper service packs applied to the operating system and SQL Server. And finally, check the code you have for deprecated statements, or for places where you could optimize the code to use new statements or formats. There are other steps to follow, but these basics will help.

Now, with all of that done, let’s move on to things that work differently. First, you need to find out what the code is doing – and the primary way to do that is to examine the Query Execution Plan. There are a lot of resources to teach you how to do that, but the general idea is that you turn that plan on (in the Query menu), run the query, look at the graphical plan and check three items: the overall plan, the icons that show the highest percentage of use, and the thickest arrows. Evaluating this on the “before” system and the “after” system, and that will show you what changed.

Maybe.

The point is, the query might take exactly the same path, but a different component may show stress because you might have a different box or configuration. Perhaps the drive layouts changed (or should), you have more memory (or better access to it) and so on. In that case, you simply follow standard performance tuning methodologies to locate what’s waiting, and what is showing pressure.

Now to the question at hand – does SQL Server (any version) handle a CASE statement differently than an OR statement? Well, once again, the execution plan will show you that answer, but the CASE statement is used for a different purpose than an OR statement – without having all of the code it’s difficult to say which to use in a given situation. The best thing to do is to evaluate the documentation on each and decide which fits the situation best.

CASE: http://msdn.microsoft.com/en-us/library/ms181765.aspx

OR: http://msdn.microsoft.com/en-us/library/ms188361.aspx

Did we make changes to CASE or OR? Not directly – but each change to the product may have orthogonal implications, which is where I point you back to the steps I mentioned for the “after upgrade” process.

New Features Announced In SQL Server 2008

andyleonard — Thu, 13 Mar 2008 10:23:00 GMT

Buck Woody, Microsoft SQL Server Program Manager, recently posted a list of enhancements in the works for SQL Server 2008 RTM in the SQL Server MVP newsgroup. The usual suspects were included in the list: Policy-Based Management (formerly DMF), Resource Governor, Multi-Server Query, PowerShell, and IntelliSense - but there are also some interesting additions that I'd not heard about until reading his post.

The big addition: Activity Monitor, described in the post thus:

The new Activity Monitor was written from the ground up with the perspective of the DBA needing to chase down a performance problem in real time. Modeled after the new Windows Resource Monitor, DBAs can quickly see the active sessions, wait states, file I/O, and long running queries in a command console like UI.

I'm excited! I currently lug around a collection of scripts (... that I keep promising to add to an application one day) to check hither and yon for performance gotchas.

Another addition: Database Diagram / Table Designer Safety Additions which add safety checks "for operations that that would drop an object or cause data loss."

You will also be able to launch Profiler "from a Query Editor Results window to the SPID of the query." This sounds very interesting. If I'm reading this right I'll be able to execute sp_who2, obtain the SPID of a long-running query, right-click (or something) and start a Profiler trace pre-configured to capture activity of this SPID. You can also launch the SPID-centric Profiler from Activity Monitor. I will be using that a lot!

New right-click options in the Query Results Window will allow users to "select a range of rows in the Results Grid and copy the headings as well. Also, you can select individual cells and copy them with headers if you wish." This sounds like the copy functionality we have in SSIS Grid Data Viewers. I can tell you from expereience this is handy feature. It's very useful to be able to copy a few multi-selected rows - including row headers (especially when you're working with a couple hundred columns!) - and paste them into Excel for analysis.

A new "Info Bar" provides pre-validated navigation cues in many screens.

The Open Table feature limits the number of rows returned. Has this ever happened to you? You right-click a table in SSMS and select Open Table only to hog server resources just so you could take a peek at the data? It's happened to me... (Thank you, thank you, thank you!)

There are also a few changes to ShowPlan - mostly related to XML / graphics interchange. I remember seeing some of this in early SQL Server 2005 pre-releases but I believe it was cut from the 2005 RTM. Nice to see these options - they're great for documenting issues.

Performance Studio will contain a host of performance tuning reports - another exciting feature! The whole Data Collection database has me stoked - have you seen this feature in CTP6? It's pretty cool.

Last but not least, the team has decided to include - drum roll please - the T-SQL debugger in SSMS!

I can hardly wait to see these in action, and it's very cool of the SQL Server Team to give us visibility into these planned features along with permission to blog about them (thanks Buck!).

:{> Andy