Blog

Dallas DBAs is a small database administration consulting firm. We don’t have a sales staff. Its just me, a Junior DBA, and my wife to inject reality into my delusions of grandeur from time to time.

We live and die from referral business. Nothing beats a happy client sending you something to put on the site, or post on LinkedIn. Even better when they tell someone else.

So how did I make money off Brent Ozar…one of the best known SQL Server DBA/performance dudes in the world?  Well…without him knowing it of course!

Some months ago I got an email from my friend Russ.  A recruiter had approached him about a 4-6 week full time contract cleaning up some SQL Servers.  Russ is more on the Business Intelligence side of the SQL Server world.  I’m a pure DBA so he forwarded the email to me.  I didn’t have the bandwidth for a 40-hour week, but most DBA gigs I see are not actually working a full 8 hours a day, so I fired off an email to the recruiter offering remote, part-time as a choice.  I figured that would be the end of it.  I told him “Cleaning up SQL Server messes is my specialty, and I can probably do it 3x faster than most DBAs.  Plus I won’t milk the client for extra hours.”

Within an hour, the recruiter was setting up a phone call with the client. That day. They lead with “We’ve read your blog, so we aren’t going to ask you technical questions.” (that was very cool…)

Essentially they told me they had signed up for SQL ConstantCare from Brent Ozar Unlimited, which in a nutshell reviews your servers, looks for bad things and tells you what to fix.  I only knew of this product’s existence prior to the call, but no details. I told them I was well aware of the type of tools that Brent and team had created and had been to a number of talks and classes from Brent so I had a pretty good idea what they were looking at. I also told them that if they were basically asking for someone to come in and apply best practices that made sense for them, then I was the guy.

Done deal, send me a contract Mr. Recruiter Guy.

All of this happened in one business day.  From Brent to Client to Recruiter to Russ to me to Recruiter to Client to Me.

Total billing so far for what the client thought was a 4-6 week effort?  Right at 40 hours, done in my spare morning hours I keep open for simple tasks on smaller clients.

If you have a bunch of servers, no SQL DBA and you need to know where you stand…ConstantCare is a great idea.  Then ping me and I’ll fix them for you.

Thanks for reading!

Kevin3NF

Follow @Dallas_DBAs

Full scans of a HEAP or Clustered index in SQL Server aren’t necessarily a bad thing.  But sometimes they are scanned because the Query Optimizer (“Optimus” here at Dallas DBAs HQ) cannot find a suitable index to use.  Sometimes its just because the table is tiny.  Either way, its worth investigating WHY all the pages are being read…especially if you are having performance issues or memory pressure.

Just for fun, I took the query found in this DBA StackExchange Answer and modified it to fit a client’s need.   Decided to share:

-- base query provided by Jonathan Fite:
-- https://dba.stackexchange.com/questions/210341/number-of-full-table-scans
-- Added sys.Partitions for rowcount, Imapct computed column, Where conditions and Sorting
-- Kevin3NF, https://dallasdbas.com

SELECT S.name AS SchemaName
  , O.name AS ObjectName
  , I.name AS IndexName
  , I.type_desc AS IndexType_Desc
  , IUS.last_user_scan
  , IUS.user_scans
  , P.rows
  , IUS.user_scans * P.rows as [Impact]
FROM sys.objects AS O 
  INNER JOIN sys.schemas AS S ON S.schema_id = O.schema_id
  INNER JOIN sys.indexes AS I ON I.object_id = O.object_id
  INNER JOIN sys.dm_db_index_usage_stats AS IUS ON IUS.index_id = I.index_id AND IUS.object_id = I.object_id
  INNER JOIN sys.Partitions P on p.object_id = I.object_id and p.index_id = i.index_id
WHERE 1=1 
  and I.type IN (0,1) --0=HEAP, 1=CLUSTERED (table)
  and IUS.user_scans > 5
  and p.rows > 1000

Order by 
--IUS.user_scans desc
--p.Rows Desc
IUS.user_scans * P.rows DESC

The top rows are very likely good candidates for an index review.

Edit as you see fit for your environment, especially the WHERE clause. Please leave the headers.

Thanks for reading.

Kevin3NF