Tag Archive: performancetuning

How to Tell if TempDB Is a Performance Problem

Written on October 27, 2011 by in SQL Server

Years ago, I came across an article about a gentleman who made a cat camera. Without boring you too much, this camera gave him a detailed view (including GPS info) about what his cats got up to all day. I got excited about the idea of finding out what my pets did all day. Not having the means to build a cat camera of my own and being far too cheap to buy one, I rigged up a web cam at home to watch the cats all day. It turns out that my pets do nothing all day. They slept and ate and slept and ate until I got home. At which point, they kept doing the exact same thing.

In a wonderful bit of quantum boringness, it turns out that I had no idea what kind of chaos my pets were causing until I directly observed them. I had no idea if they were actually moving things around in the house or if I was simply forgetting where I was putting things (turns out I’m very forgetful). TempDB is a lot like a basket of cats – you don’t know for sure that it’s causing your problems, you have some sneaking suspicions, but you’re not sure how to prove anything.

Watching Over TempDB

If TempDB is like a basket of cats, we need to watch what it’s doing; there’s no telling when it’s going to go from adorable to shredding the drapes. Knowing what to watch in TempDB is just as important as knowing that you should even be watching TempDB at all.

How Many Cats Do I Have? (Watching TempDB Free Space)

Excessive TempDB usage isn’t necessarily a sign that TempDB is a problem, but it is an indicator that you have problems worth looking into. When TempDB starts getting full, it’s an indicator that there’s a lot of temporary object creation as well as out of memory sorting and joining going on in the database. None of these things are bad, but they’re indicators that we should be taking a closer look at TempDB.

There’s no hard and fast metric for what you should do when your TempDB data file is large, but it’s a good indicator that you can stand to do one of a few things:

  1. Enable Instant File Initialization
  2. Add Multiple TempDB Files

These changes won’t always cure the problem, but they are starting points. Waiting for TempDB to grow can be a cause of performance problems and enabling Instant File Initialization makes it possible to quickly grow TempDB data files. Using multiple TempDB files uses more storage bandwidth, reduces file contention, and adds magical pixie dust to your queries.

What Are My Cats Doing? (Monitoring TempDB Usage)

The next step, after you know how much TempDB you’re using, is to find out how TempDB is being used. TempDB is used for a few distinct things: joins, aggregations, sorting, the version store, temporary tables (and table variables), and table/index spooling. While these are different operations, they all consume TempDB space. Understanding how your applications use TempDB is critical to understanding if TempDB is causing performance problems.

This is where things get more complicated; there’s never a right or wrong answer, but TempDB usage varies heavily by application and workload. Sometimes even the same application, with different customer workloads, can have wildly different TempDB usage characteristics. By monitoring TempDB through a variety of DMO calls, server side traces, and performance counters it’s possible to get an accurate picture of the health and utilization of TempDB over time. Through some careful DMO/DMV scripting it’s even possible trace who the biggest consumers of TempDB are back to the stored procedure or query that’s using TempDB.

Just like trying to watch a basket of cats through a webcam, you can only catch quick glimpses of what’s going on. This process makes it possible to capture a sample of what’s going on inside TempDB at any moment, but it’s only for a quick moment. The DMOs to monitor TempDB only look at the currently running queries, there is no historical record. The best way to get an accurate picture of what’s happening is to sample these DMOs on a regular basis and sample aggressively during peak performance periods. You won’t catch every query this way but you should be able to catch most.

Benchmark, Rinse, Repeat

Whenever I talk about performance tuning or general SQL Server problems, I always advise people to benchmark everything that they can. Having a steady baseline is the only way to verify that changes are having a positive effect on performance. Without a performance baseline in place, all you have to go on is a feeling that things are faster. Unfortunately, feelings don’t translate into quantifiable numbers (unless you’re trying to quantify how you feel about a basket of cats).

Establishing a performance baseline is one of my favorite parts of working with clients. As we go through the health check, I work with our clients to figure out where it hurts and help them build a solution. I cover how they can use the baseline to keep monitoring their system. With these tools in place, it’s easy to monitor a system’s health over time.

Focusing on performance metrics makes it easy to see which parts of an application are causing performance problems. It TempDB usage spikes after a change to a few stored procedures, it’s easy to identify the problem when you have a baseline established.

Determining whether or not TempDB is a performance problem boils down to establishing a baseline, monitoring performance before and after changes, and carefully making changes until acceptable performance levels are reached. This may involve adding more TempDB data files, forcing memory grant allocations, or using solid state drives for TempDB.

Resources

Jeremiah Peschka

Jeremiah Peschka has worked as a database and emerging technology expert at Quest Software where he researched new trends and technologies in the world of data storage. Over the course of his career he’s worked with companies across many industries as a system administrator, developer, and DBA. He’s been involved with all aspects of application development and deployment. He likes cheesecake, coffee, and ice cream.

Website - Twitter - Facebook - More Posts

2 Comments - Leave a comment!

Sargability: Why %string% Is Slow

Written on June 9, 2010 by in SQL Server

People love to search.

Google has us addicted to fast, easy search functions.  Users expect every application to have a built-in blazing-fast search functionality.  To pull that off, developers build search queries that let users enter a string, and we ask SQL Server to find matches.  For example, say our users need to find some nuts.  We take their string, put percent signs on either side, and then search for that field in the product names:

SELECT *
FROM AdventureWorks.Production.Product
WHERE [Name] LIKE '%nut%'

This works great on our machine – but when we scale it up to hundreds or thousands of simultaneous users, or if we ramp up the number of products, our response time sucks.  Let’s find out why by checking the execution plan.  In SQL Server Management Studio, click Query, Display Estimated Execution Plan, and we get:

Query Execution Plan

Query Execution Plan

There’s only one operation, which would sound like a good thing, but that one operation is a clustered index scan.  That means SQL Server has to read every row out of the Product table, check to see whether it’s got “nut” anywhere in the name, and then return our results.

But wait – there’s an index on Production.Product for the Name field, and SQL Server will use that index if we have a slightly different query:

Less Wildcards, Same Nuts

Less Wildcards, Same Nuts

If we take the leading % wildcard out, notice that this time it does two operations.  First, it does an index seek against our Name index, then it looks up the corresponding rows in the base table (Product).  Two operations might sound more expensive, but if we looked at the total cost for each query, the second one would be faster in situations where we’re only pulling a small number of search results back.  If this table was for a company called Nothin’ But Nuts, on the other hand, we would probably still need to scan the entire table, but that’s a discussion for another day.

So why doesn’t SQL Server use the index for the %nut% query?  Pretend for a moment that you held a phone book in your hand, and I asked you to find everyone whose last name contains the letters HAM.  You would have to scan every single page in the phone book, because the results would include things like:

  • Beckham
  • Chambers
  • Hamilton
  • Thames

If, on the other hand, I asked you to find everyone whose last name began with the letters HAM, you could turn straight to the H page in the phone book, scan through a few lines, and quickly get the information you need.

When I asked you for everyone beginning with the letters HAM, my query was sargable.  When I asked you for all last names containing HAM anywhere in the name, my query was not sargable – meaning, you couldn’t leverage the indexes to do an index seek.  (Yes, sargable is sort of a real word – it stems from the phrase Search Arguments.)

Since we can’t talk users out of using search queries, and since non-sargable queries don’t scale, we need to find a better way to search for text.  That’s where SQL Server’s Full Text Search comes in.  Unfortunately, your queries must change – normally when you add an index, your queries just magically become faster.  Full text indexes don’t work that way.  You have to tweak your queries to use operators like CONTAINS instead of LIKE.  If you’re dealing with an old boat anchor of a database and the developers are long gone, you might be out of luck.

%String% is just one thing that will cause SQL Server to do slower scans instead of high-performing index seeks.  To learn more about sargability, check out:

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

Website - Twitter - Facebook - More Posts

21 Comments - Leave a comment!

My Weekly Bookmarks for October 30th

Written on October 30, 2009 by in SQL Server

Here’s my bookmarked links for October 26th through October 30th:

SQL Server Links

#SQLPASS Links

Tech Links

The Junk Drawer

These bookmarks are automatically imported from my bookmarks at Delicious.com. If you’d like to get up-to-the-minute updates on what I’m bookmarking, you can subscribe to my bookmark RSS feed.

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

Website - Twitter - Facebook - More Posts

1 Comment - Leave a comment!

Bottlenecks and Bank Balances

Written on October 27, 2009 by in SQL Server, SQLServerPedia Syndication

Pop quiz: should you be worried if your SQL Server’s page life expectancy is averaging 214?

There’s only one correct answer: it depends.  Successful performance tuning boils down to a simple cycle:

  • Measure the application’s performance
  • Find the current bottleneck
  • Improve that bottleneck so that it’s not the bottleneck anymore
  • Measure to find out how much your application performance improved
  • Ask the application owner if it’s good enough now. If so, move on to the next application. If not, go back to step 2.

And every one of those steps is equally important.

If You Don’t Find the Right Bottleneck

The Bottleneck Is Plenty Big Enough for You

This Bottleneck Is Plenty Big Enough for You

Performance tuning isn’t about zooming in and focusing on a single number in incredible detail; rather, it’s about stepping away and getting the full picture. Time and again, I get emails asking about whether a single metric is OK, but upon questioning, the DBA has leapt to a conclusion without surveying the environment as a whole. If you spend your tuning time closely examining a single metric, trying to figure out how to improve that one metric, you might not improve the performance of your application.

Sure, your page life expectancy might be pretty bad – but is that the one thing keeping your application from performing faster?

Take a step back and gather a complete set of Perfmon metrics. Look at CPU, memory, disk, and network performance as a whole. Find the thing that’s in the absolute worst shape possible. In that link, I explain the order that I look at metrics to find which one looks like the most likely bottleneck.

If You Don’t Focus on Improving the Bottleneck

I was recently working with a client frustrated with their application performance. I found two issues:

  • CPU-intensive user-defined functions were being called thousands of times per query
  • The storage subsystem was nowhere near as fast in practice as the vendor had claimed

The application’s bottleneck was the CPU-intensive UDFs. The server was frequently pegged at 100% CPU, and queries just couldn’t run any faster until they were rewritten to rip out the UDFs. I put together a recommended plan of action to take those UDFs out, which would make the application an order of magnitude faster. I noted that they should probably start working on the storage performance in a second track, because the instant the UDFs were removed, storage was going to become a problem. With the CPU-burning UDFs out of the way, the server would be able to churn through more records faster, but the storage subsystem wouldn’t be able to deliver records fast enough to satisfy the users.

On our next status update call, they said they’d reworked the storage subsystem. SQLIO reported dramatically faster storage throughput, but they were only seeing a minor improvement in application performance. I had to break the bad news to them that they’d focused on the wrong problem first. After we revisited my report together, they pursued the UDFs with renewed vigor, and suddenly the application was blazing fast. Thankfully I’d documented my findings in writing, but if I’d have been an internal employee, I might have communicated that in verbal form instead. I might have lost the ensuing battle to fix the UDFs because the manager would have thought my advice was bogus.

If You Don’t Measure Your Improvements

You Get What You Measure

You Get What You Measure

All DBAs are consultants.

Some of us think we’re full time company employees, but in reality, we’re delivering a service. Whether they’re developers, project managers, end users, or other DBAs, they’re looking at you just as if you were an outsider. You’re expected to stride in, identify the problem, mitigate it, and show that your work delivered a return on investment. The investment, in case you’re not following, is your paycheck.

Don’t believe me? Poke around in an application and then throw up your hands, saying you can’t find a way to make it go faster. The next phone call the project manager makes will be to an external consultant, and the project manager probably won’t call you first next time. (Sometimes, that’s not a bad thing.)

If you put in a lot of hard work to make an application go faster, but you don’t measure the before-and-after effects of your work, someone else is going to take credit. The developers will say the improvements were due to a new version of their code, because they’re working on the code at the same time you’re working on the database. The sysadmins will say they defragged the muffler bearings. The SAN guy will say he tweaked the flux capacitor. The project manager will say he made everybody worked long hours and that did the trick. The only way, the ONLY way that the DBA can ever take credit is to take clear before-and-after measurements for proof. Run the same code base before & after your tweaks, and measure application performance. Follow up with a written report, even if it’s a one-paragraph email, summing up your changes and the performance improvements, and copy your manager on it.

If You Don’t Ask the App Owner If It’s Good Enough

Never confuse what YOU think about a metric with what the BUSINESS thinks about a metric. Your CEO doesn’t care about page life expectancy. (Your CEO probably doesn’t even care about the DBA’s life expectancy.) Before you spend time or money improving an application, you have to find out whether it’s the most important thing to your business right now.

Say hello to the most important metric you will ever calculate: opportunity cost.

A Long Night at Zig Zag Has Its Own Opportunity Cost

A Long Night at Zig Zag Has Its Own Opportunity Cost

Opportunity cost is the cost of doing something as compared to the cost of doing something else. If you spend eight hours today improving the page life expectancy of a particular server, is that worth more to the business than anything else you could be doing in those eight hours? Could you spend eight hours doing something more valuable?

I use opportunity cost whenever anyone asks me to do something.

As an employee, if a project manager asks me to tune a particular application, I bring them into my manager’s office and say, “It will take me three days to make that application faster. I’ll probably make it an order of magnitude faster, because I’ve never tuned that server before. However, if I take those three days to do it, I won’t make the deadline for Project Snazzywidget. Which one is worth more to you?” At that point, it’s a political decision and a business decision, not a technical decision. If you’re doing the best job of any employee he has, your manager will put you on the most valuable project – which in turn increases your worth again.

As a consultant, I approach the problem differently: “Here’s the thing – I could spend another three days working on this application, but from this point forward, I’m only going to be able to achieve incremental improvements, not the order-of-magnitude improvements we saw in the first few rounds of tuning. I hate to make you guys go through that for a small gain – but is there another application in-house that isn’t delivering the performance you want?” This resets the client’s expectations, and they start seeing you as a weapon that they can point at slow applications. They’ll cherish your time and focus you where your effort will pay off the most. This keeps your perceived ROI high. If you deliver jawdropping results each time you tune an application, you can justify higher billable rates.

After all – isn’t your bank balance the one metric you really want to improve?

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

Website - Twitter - Facebook - More Posts

5 Comments - Leave a comment!

My Weekly Bookmarks for October 16th

Written on October 16, 2009 by in SQL Server

Here’s my bookmarked links for the week ending Friday, October 16th:

PASS Election Links

PASS Summit Links

SQL Server Links

IT Links

The Junk Drawer

These bookmarks are automatically imported from my bookmarks at Delicious.com. If you’d like to get up-to-the-minute updates on what I’m bookmarking, you can subscribe to my bookmark RSS feed.

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

Website - Twitter - Facebook - More Posts

2 Comments - Leave a comment!

My Weekly Bookmarks for October 9th

Written on October 9, 2009 by in SQL Server

Here’s my bookmarked links for October 2nd through October 9th:

SQL Server Links

Tech Links

The Junk Drawer

  • I Love That Game – Brilliant criminal minds at work.
  • Twitter Data Analysis: An Investor’s Perspective – A bunch of oddball stats about Twitter users and their histories.
  • Will Work for Whuffie? – Why you have to charge fees for speaking engagements when you hit a certain level of fame. (No, I’m not there yet, hahaha, but even if I was, my speaking engagements are free because I’m a service of Quest Software. No, not that kind of “service,” buddy.)

These bookmarks are automatically imported from my bookmarks at Delicious.com. If you’d like to get up-to-the-minute updates on what I’m bookmarking, you can subscribe to my bookmark RSS feed.

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

Website - Twitter - Facebook - More Posts

0 Comments - Leave a comment!

My Weekly Bookmarks for October 2nd

Written on October 2, 2009 by in SQL Server

Here’s my bookmarked links for September 25th through October 2nd:

SQL Server, Cloud, and Tech Links

Writing, Blogging and Networking Links

The Junk Drawer

These bookmarks are automatically imported from my bookmarks at Delicious.com. If you’d like to get up-to-the-minute updates on what I’m bookmarking, you can subscribe to my bookmark RSS feed.

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

Website - Twitter - Facebook - More Posts

1 Comment - Leave a comment!

Bookmarks for September 25th

Written on September 25, 2009 by in SQL Server

These are my recent favorite links:

Unfortunately, there’s more, but the WordPress plugin I’m using will only import 15 bookmarks per hour. Grumble. To see the full list of what I’ve been reading lately, either check out my Delicious bookmarks or subscribe to my Google Reader feed.

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

Website - Twitter - Facebook - More Posts

0 Comments - Leave a comment!

Overdriving Your Headlights

Written on September 25, 2009 by in SQL Server

The strength of your car’s headlights, the speed of your reactions, and the power of your brakes determine how fast you can drive safely at night.

Deer in the Headlights

Deer in the Headlights

Your headlights give you enough warning time to hit the brakes and stop your car before you hit an object. The better your headlights, the more distance you can see ahead, and the faster you can drive with confidence.

Let’s say your car’s headlights illuminate 350 feet in front of your car. Sure, you can see reflective signs from much farther away, but if a pile of lumber fell off a truck on the highway, it’s not going to be covered with reflective paint. To find out whether that 350 foot distance is far enough, we need to know three things:

  • How fast is your reaction time? – What’s the length of time you see the pile of lumber until the time your foot starts to move on the brake pedal? This length of time is affected by your alertness, your training, your muscle speed, and the iPhone you’re playing with while you’re driving.
  • How fast is your car going? – At 60 miles per hour, your car traveled 132 feet in the 1.5 seconds it took before your foot began to push the brake pedal. The faster you’re going, the more distance your car will travel.
  • How good are your brakes? – A Porsche 911 can stop from 60mph in 100 feet. If you’re going faster, or if your brakes aren’t as good as a 911′s, then you’re going to eat up more distance.

These factors combine to determine your safe stopping distance. Michael Schumacher might be able to drive at 100mph in a Ferrari using candles for headlights. You, however, are pushing the limits of your talents at 30mph even with those expensive fake xenons you installed on your Civic Si. Err on the wrong side of this formula, and you’re doing what’s called overdriving your headlights. People often learn this when the state trooper fills out the forms explaining why they hit the deer.

Monitoring and Forecasting: SQL Server’s Headlights

Most of us don’t bother with predictive analysis – we gather statistics with Perfmon, the DMVs, wait stats, and so on, but we’re looking in the rear view mirror – not ahead of us. Heck, some of us don’t even go that far; we wait until our phone rings and the users scream about dead bodies – uh, I mean, dead queries – lying around. We don’t have the time to project future growth and capacity needs because it’s a painful, time-intensive process with the native tools.

Serious performance tuning, though, requires looking ahead. Imagine being the head DBA for the New York Stock Exchange or NASDAQ systems: you simply can’t afford to wait until your end users call about lag times. You have to predict performance needs as far ahead as possible in order to design and implement an infrastructure to support those needs.

Unfortunately, there’s no quick and easy way to forecast how much our SQL Server CPU, memory and storage needs are going to grow in the next twelve months. DBAs can build their own data warehouses with performance data sourced from the DMVs, wait stats, SQL 2008′s Performance Data Warehouse, or Perfmon counters. To anticipate future needs and look down the road, the DBA would build time-based reports that use historical information to predict the future. This is left as an exercise for the reader.

Quest Capacity Manager

Quest Capacity Manager

Quest Capacity Manager makes this whole process point-and-click simple by combining storage, CPU, and memory requirements from various sources including Quest Spotlight‘s repository.

Another approach is to use your company’s financial metrics to predict system loads. DBAs in the financial industry often relate their system loads to stock trading volumes. They know that at a certain level of stock trading, their systems will have a certain level of loads. Instead of guessing SQL Server load directly, they can look at their financial analysts’ predictions of future stock volumes and use those to predict SQL Server activity. Your business may have similar transaction volumes – sales quantities, employee head counts, or widget production rates – that can help you guesstimate future database loads.

The farther down the road you can see, the more time you buy for reaction and braking.

Reaction Times in the DBA World

Reaction times measure the lag between your monitoring software’s alerts and your first action. Take one step backward if you’ve got an Outlook rule set up to automatically move all performance alerts out of your inbox and into another folder for later perusal. Uh-huh, I thought so. If you want to get a job driving the Ferraris of SQL Servers, you’re going to need to break the rules – specifically, your Outlook rules. Michael Schumacher didn’t win titles driving cars with automatic transmissions, and you can’t do serious SQL Server performance tuning by ignoring alerts.

The first challenge is to reduce false alarms coming from your monitoring system. Reconfiguring your monitoring system can be a constant challenge, especially if your monitoring systems are controlled by a different group in the company. This is one of the things I like about Quest Foglight Performance Analysis – the dashboard metrics show a historical high/low range, so you’re only alerted when a metric is outside of the established norm for a given server. Foglight PA even refines its baselines based on the day of week and time of day, because a CPU load metric that’s perfectly normal for noon on a workday might be completely out of the ordinary on Saturday at 9AM.

The second challenge is to be able to act faster when the alert comes in. In my experience, reaction times seem to be grouped in sizes of companies:

  • Small companies with one DBA – as soon as the DBA sees the alert, they either know right away exactly what action they’re going to take, or they have to hit the web to figure things out. They don’t have more senior DBAs on staff who may have seen a particular problem before, so some problems take longer than others to research before reacting.
  • Midsize companies with a couple/few DBAs – one DBA might be on call, but they may not know exactly what action they’re going to take right away. They may need to get approval from other DBAs before acting, or they may have security restrictions that stop them from taking serious actions like rebooting servers.
  • Large enterprises with multi-tier support groups, rigid policies, and run books – some problems are handled autonomously by help desk staff or first level support, and more serious problems are quickly escalated to the appropriate staff.

Each type of company has different solutions for reducing reaction times, and this sounds like a great idea for a future blog post series.  Note to self…

Braking Times: The Time Required to Fix Things

Just Like The Ones On Your Neon.

Just Like The Ones On Your Neon.

Just as race teams improve their stopping power by using new tools like ceramic brakes, you can use more advanced technology to help you solve problems faster. Some of the examples include:

  • Clustering improves your reaction time when dealing with broken server hardware.
  • Database mirroring helps you recover from a borked SAN or page corruption quicker.
  • SQL Server Enterprise Edition helps your database mirroring become even more powerful by compressing the data and by fetching corrupt pages from the mirror.
  • Virtualization can give you high availability for servers that might not ordinarily be able to afford HA.

Just like ceramic brakes, which can cost upwards of $10,000, none of these technologies are free. If you wanna go seriously fast, you gotta spend serious money, despite what you heard from that guy selling “Type R” stickers on eBay. Start by improving your reaction times first, because that’s free.

Want More Racing Performance Tips?

I’m doing a “Performance Tuning for Race Car Drivers” session at the SSWUG Virtual Conference. I illustrate SQL Server performance tuning using lessons from legendary Formula 1 icons Colin Chapman, Enzo Ferrari and Michael Schumacher.

I’ve been dying to do this presentation for months, and I’m excited to debut it at the SSWUG Virtual Conference. You can watch it in high definition along with dozens of other top-notch presentations from top-notch presenters on SQL Server, SharePoint and Business Intelligence.

Register today and use VIP code SPBOUVC09 to save $10 off the cost of registration!

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

Website - Twitter - Facebook - More Posts

1 Comment - Leave a comment!

My Weekly Bookmarks for September 17th

Written on September 17, 2009 by in SQL Server

Posting this one a little early since I’ll be doing presentations all day tomorrow for a Quest Day with the Experts in Boston, MA.  You can watch online too.

SQL Server & Tech Links

The Junk Drawer

  • Blur Tripod – iPhone tripod adapter and an app that has a built-in delay after you click to take a photo – that way the phone stops moving and the photo will be crisp.
  • Professional Development: Internet Image – When someone tells you that you should have a nice, clean, sanitized blog that’s free of any personal details, send them this blog by Jason Massie. I’m right there with him – I would rather see someone’s personality. People are likable – Books Online is not.
  • Trackin’ Away – Ping.fm now lets you track statistics on your broadcasted links. Yet another reason to use the PingPressFM plugin for WordPress.
  • Training Benefits – When you stop training, your career comes to a grinding halt.
  • Your Own Personal Development Plan – End-of-year reviews are coming up – time to start working on your Personal Development Plan.
  • Recording a webcast for Quest Connect 2009 – Colin Stasiuk talks about the upcoming free QuestConnect webcast.
  • Your company? There’s an app for that. – Many companies are going to be competing with dirt-cheap iPhone applications sooner or later.

These bookmarks are automatically imported from my bookmarks at Delicious.com. If you’d like to get up-to-the-minute updates on what I’m bookmarking, you can subscribe to my bookmark RSS feed.

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

Website - Twitter - Facebook - More Posts

0 Comments - Leave a comment!
« Older Posts