I have yet to see a third party tool that makes good recommendations for what to do about poor query performance. You can get some generic checks on the low-hanging...

Personally, unrestricted with lots and lots and lots of monitoring and alerts in place so that I can try to prevent the disks from filling up. Either approach has downsides....

You can query the Dynamic Management Objects for this information. sys.dm_exec_query_stats will show you which queries, currently in cache, are using the most ram, cpu & disk. You can combine...

Just remember, SQLIO is a stress test tool. If you're talking about validating your production system, you will be applying a load to your disks that is very likely to...

Thinking about it some more, take a look at sys.dm_os_wait_stats. That's going to tell you, in aggregate, what is causing your system to run slow. That will indicate where the...

If you're looking at disk problems, for once, you can leave the VM guy alone and concentrate on the physical box. You may need to wake up the SAN guy...

Millions of rows are not necessarily a problem. It really depends on your indexes and statistics. If you have something like an identity column as the primary key, then you...

When you add something like GROUP BY, the plan is not the same because the processing is not the same. You can't apply a simple SELECT (or even a very...

Nope. Those are different pieces of functionality inherent to the different versions of SQL Server. If there's 2008 functionality needed, it's also going to need the underlying 2008 engines.

There is not a single spot that says "SHOWPLAN Enhancement for 2012". All through the book there are additional pieces of knowledge as they are applicable.

There are few changes in...

There is no way. Sorry.

If it's a dev environment, you may not want to set up extensive backup routines (for many obvious reasons) which is yet another reason to have...

SQLSACT (11/28/2012)

---

Grant Fritchey (11/28/2012)

---

Just remember that the number is an estimate. This means it can be wildly inaccurate. But, it's the only number you get, so you're going to use...

No way I know of to do this.

There is a third party tool, Plan Explorer from SQL Sentry, that will let you open execution plans. But I'm pretty sure you...

You need to look at the execution plan of the query to understand which indexes it accessed. If query time increased, then adding that index did not help.

Just remember that the number is an estimate. This means it can be wildly inaccurate. But, it's the only number you get, so you're going to use it, just don't...