• SQL Azure Support – Connect to SQL Azure and utilize the same Toad features as if it were an on-premise SQL Server database
• Debug Tracing – generate a trace on a piece of code and replay it back later to determine what actually happenedduring execution
• Database Administration Object Explorer – enhanced to provide the ability to filter indexes in the Create/Alter Index window and allows you to postpone any Create/Create or Llike/Alter action
• Collaboration – provides a direct connection to RSS and Twitter feeds, including any Toad community postings
• Query Development – includes productivity-enhancing features for code completion, including object multi-select, the ability to resize the code completion box and parameter hints
• Group Execute – execute a SQL script against each specific database within each instance and merge the results of a group executon into a single result set
• Automation – Import/Export templates allow for the use of a default connection or the connection saved to the Import/Export template
• Project Manager – open a new project or save or save a project using buttons on the Project Manager toolbar

To evaluate this new release of Toad for SQL Server, please visit our dedicated product page.

Thank you,

Toad for SQL Server product management team

Historically, when we look at a physical machine, the simple metric of CPU % Used is a pretty good measure of how busy a SQL Server is.  A server that is at one time showing 20% CPU utilization and then at another time is showing 80% CPU utilization is generating 4X as much work during the later time period.  In an operating system that is being hosted by a VM, we lose the luxury of knowing exactly how much CPU horsepower we have at any given time.  The are a few factors that attribute to this “grey area”:

1. A VMWare admin has the ability to set an upper limit on the amount of CPU that is available to your VM.  They can also set a reservation to guarantee an amount of CPU to your VM.
   
   I will not see this limit in My Computer -> Properties nor will I see any representation of this limit in task manager or perfmon.  Let’s assume that throughout the morning I have 2GHz available to my VM and am showing 20% CPU utilization.  Later in the afternoon, my VMWare admin needs to free up resources so they put a 1 GHz cap on my available CPU.  Now the exact same workload will show 40% CPU utilization.  Nothing has changed on the OS or in my SQL Server workload, yet I am showing twice the CPU %.  See where this gets confusing?
2. Even if the VMWare admin hasn’t set any resource cap on your VM’s available CPU, the ESX host could simply become overloaded.  Let’s say an ESX host has 8GHz of total processing power, and that host has 5 VM’s running on it.  Normally each VM uses about 1GHz of processing power, but all of a sudden, each VM needs 2GHz.  Like fitting 10 pounds of feathers into a 5 pound bag, something has to give.  What gives, is that ESX has to dynamically scale down each VM’s available CPU to account for the increased workload.  As a result, you may see 80% CPU utilization when looking at perfmon or task manager, but you have no idea what that 100% is of.
3. A virtual machine may not be tied to a single ESX host.  For DR or performance reasons, a VMWare administrator can move your VM from ESX host to ESX host without you knowing.  These ESX hosts also need not offer the same performance as one another.  You could be chugging along just fine during the morning with 4 GHz of processing power, and then in the afternoon be switched to an ESX host with 3 GHz of processing power.  Not only did you not know that this occured, but your VM’s CPU % will go up, even though the workload is unchanged.

Because of this, it is absolutely critical that you not simply look at CPU % as a measure of how busy SQL Server is or how much CPU it is using.  Percentages are always relative to a ceiling, and when that ceiling can move up or down at will (or whenever a VMWare admin decides that your ceiling is too high), the percentage itself loses meaning.  CPU% analyzed in conjunction with GHz used will allow you to paint the full picture of a VM’s CPU requirements.  Unfortunately, this data is not available by looking purely at the OS.  You will need metrics from the virtual layer as well.  That data is readily available in the built in VMWare client tools (vSphere), but you’ll either need to have access to the ESX or vCenter instance to view them, or a tight relationship with the VMWare admin who can send them to you.

For a better way to have this information at your fingertips, stay tuned…

“The SQL Server was performing great yesterday and all of a sudden today the performance is terrible.”

Foglight Performance Analysis has a very powerful feature that allows you compare two different properties of your SQL Server workload.  This scenarios could be:

• Comparing the performance of a database over two different time ranges.
• Comparing the performance of a single stored procedure over two different time ranges.
• Comparing the performance of database A to database B over the same time range.
• etc…

Take a look at this short tutorial and see how the feature could help you in your environment!  Any questions, feel free to comment.

Brent Ozar says, “This is definitely my favorite way to check wait stats performance on my SQL Servers to find out what’s going wrong at a glance.”

Anyway, again, I just waned to repost the blog entry and invite discussion.  Here’s the link again:  http://troygallant.com/?p=155  -  thank you Grateful DBA.

Have a great weekend everybody and good luck getting your last minute Christmas  shopping out of the way.

We’re really excited about this release as it beefs up our already strong Fast Compression functionality. Fast Compression further reduces the size of backups by only backing up changed data. This improves backup times and lowers storage requirements by 70% or more over and above your current backup and compression strategy.

Again, we look forward to making it generally available during the PASS show and if you’re headed there, please stop by the booth to say hello and see a demo.  See you there!

Andy

1) As a database administrator, all of my critical data files are on my F and G drives.  I don’t want to monitor those drives with the same thresholds and alerts as I do my C drive.

2) I have different backup policies for different databases on my servers and I don’t want to alarm on every database the same way.

All of these use cases can be met with Spotlight on SQL Server Enterprise’s alarm configurations.  Please watch the video below to see how its done.  If anyone has any questions or comments, or you want to be walked through a use case of your own, leave a comment or post in the forums!

First off, a disclaimer.  Due to the “open” nature of custom counters, Quest Software makes no guarantees as to the overhead or accuracy of any custom counter.  Custom Counters should be fully tested and validated in a customer’s environment prior to loading onto a production system.

For documentation on the counter used in this screencast as well as other possible counters, head to the Articles -> Documentation -> Spotlight on SQL Server Enterprise section of this site, or click on the link below:

http://sqlserver.quest.com/kbcategory.jspa?categoryID=372

If you have any questions, please post them to the forum.