I recently inherited a few servers that have autoupdate of statistics disabled. That’s a long story.  In other cases, we want to manually update statistics because it may take a quite some time for SQL Server to detect that it has stale statistics. We were running a script that updates all statistics across all indexes on all tables in all databases. And it was taking forever.

One day it hit me.

We’re running Michelle Ufford‘s script to reorganize and rebuild indexes. What if we could do the same for statistics? Why were we forcing the update of statistics on a static table? With a little bit of help from a script that Kendra Little wrote, I was able to put together a process that will dynamically update statistics only where needed. And we added a little more logic to set the sample rate as well. For small tables, doing a full scan makes more sense. But for large tables, this a smaller sample size is needed.

A lot of the values are hard coded here and should be moved to parameters. Maybe in the next version. This thing looks for five percent or 1000 rows, whichever comes first. It works in my environment. Your mileage will vary.

-- Dynamic Database Statistics Update
 --
 -- Created: Mike Hillwig
 -- 01/26/2012
 --

create table #statsmaint
 (databasename varchar(100),
 schemaname varchar(100),
 tablename varchar(100),
 indexname varchar(100),
 rowsupdated int,
 totalrows int)

--- Stats calculation adapted from Kendra Little's script found at
 --- http://www.littlekendra.com/2009/04/21/how-stale-are-my-statistics/

exec sp_msforeachdb 'use ?;
 INSERT #statsmaint
 SELECT DISTINCT
 ''?''
 , s.name
 , tablename=object_name(i.object_id)
 ,index_name=i.[name]
 , si.rowmodctr
 , si.rowcnt
 FROM sys.indexes i (nolock)
 JOIN sys.objects o (nolock) on
 i.object_id=o.object_id
 JOIN sys.schemas s (nolock) on
 o.schema_id = s.schema_id
 JOIN sys.sysindexes si (nolock) on
 i.object_id=si.id
 and i.index_id=si.indid
 where
 STATS_DATE(i.object_id, i.index_id) is not null
 and o.type <> ''S''
 and (si.rowmodctr > 1000 OR cast(si.rowmodctr as float) / cast (si.rowcnt+1 as float) > .05)
 and ''?'' <> ''tempdb''
 order by si.rowmodctr desc'

DECLARE @v_dbname varchar(100)
 DECLARE @v_schemaname varchar(100)
 DECLARE @v_tablename varchar(100)
 DECLARE @v_indexname varchar(100)
 DECLARE @v_SQL varchar(1000)
 DECLARE @v_rowsupdated int
 DECLARE @v_percentscan varchar (10)
 DECLARE @v_totalrows int
 DECLARE c_statistics CURSOR FOR
 SELECT databasename, schemaname, tablename, indexname, rowsupdated, totalrows
 FROM #statsmaint

OPEN c_statistics
 FETCH NEXT FROM c_statistics INTO @v_dbname, @v_schemaname, @v_tablename, @v_indexname, @v_rowsupdated, @v_totalrows
 WHILE (@@fetch_status <> -1)
 BEGIN
 IF (@@fetch_status <> -2)
 BEGIN

SELECT @v_percentscan = '100' where @v_totalrows <= 50000
 SELECT @v_percentscan = '75' WHERE @v_totalrows BETWEEN 50000 AND 1000000
 SELECT @v_percentscan = '50' WHERE @v_totalrows BETWEEN 1000000 AND 10000000
 SELECT @v_percentscan = '25' where @v_totalrows > 10000000

select @v_SQL = 'UPDATE STATISTICS ' + @v_dbname + '.' + @v_schemaname + '.' + @v_tablename + ' ' + @v_indexname + ' WITH SAMPLE ' + @v_percentscan + ' PERCENT --' + cast (@v_rowsupdated as varchar) + ' OF ' + cast(@v_totalrows as varchar) + ' ROWS UPDATED. STARTED ' + cast(current_timestamp as varchar)
 print @v_sql
 exec (@v_sql)

END
 FETCH NEXT FROM c_statistics INTO @v_dbname, @v_schemaname, @v_tablename, @v_indexname, @v_rowsupdated, @v_totalrows
 END

CLOSE c_statistics
 DEALLOCATE c_statistics

drop table #statsmaint

SABRE has evolved over the years, but the PNR code has persisted. Imagine making a flight reservation and having them give you a confirmation number that more closely resembled your bank account number. Yuck.

The more I think about this, the more fascinated I am with using a six character code as a data type.  In a modern relational database system, it may be completely impractical. But think back several decades. It was revolutionary.

Imagine using all 26 letters in the English alphabet plus 8 numbers. We don’t want to use 0 and 1 because they can be confused with O and I, respectively.  That’s 34^6 or 1,544,804,416 records that can be held before needing to recycle. Even by today’s standards, it’s quite a lot of records.

Using this datatype today could be a bit messy. Because we don’t store things on sequential punch cards, we’d need to have an algorithm to find the next available value. And putting a clustered index on this as a column would cause page splits for days.

I’ve been chewing on this idea for close to a year now, and I still can’t decide if I love it or hate it more.

I say this because there is just so much bad advice out there. Know your sources. Challenge the stuff you read. And more than anything, make sure you test the hell out of any script you download. Do you really want to run some script you found at Bernard’s Blog Land against your 12 TB production data warehouse and have it thrashing at your indexes? I certainly wouldn’t.

I work with a few people that I swear have read a few too many bad blog posts. Some of their suggested “best practices” are things that I’m constantly challenging. These are smart people. But I believe they’ve read some bad advice.

That said, I read a blog post from Kimberly Tripp today that made me giggle. It reaffirms something I’ve been saying for six months. And this one isn’t a random blog. So why do I take this one at face value? It comes from a reputable source, someone I’ve met, and this is someone whose advice has never failed me.

Read the slide above: If it comes from Paul or Kimberly, it’s true.

I gave this presentation at SQL Saturday in South Florida and it was a lot of fun. I’ve updated it slightly to include a warning on avoiding advice from random bloggers. My benchmark there is if someone says you should always or never do something, they’re not right.

Top 10 Operational Mistakes to Avoid 2012

I wrote this little nugget that generates enough confirmation for the client’s relationship manager to demonstrate that we did indeed move their code. And it seems to make the client happy.

set nocount on
go

DECLARE @dbname VARCHAR(30)
DECLARE @num_objects INT
DECLARE @object_type VARCHAR(3)

SELECT @dbname = 'userdatabasename' -- Use the database where the objects were moved
SELECT @num_objects = 1   -- Use the number of objects moved.
SELECT @object_type = 'P' -- Use P for procedures, F for functions, U for tables, V for views, etc. 

DECLARE @SQL VARCHAR (1000)

select @@servername

SELECT @sql = 'select top ' + cast(@num_objects as varchar) + 
' left(name,30) as object, object_id, modify_date from ' + @dbname +
'.sys.objects where type = ''' + @object_type + '''

order by modify_date desc'

EXEC (@sql)

Again, this is for my DEV environment. I’d never advise someone to run all databases in SIMPLE recovery mode in a production environment unless there was a very specific need to do that.

set nocount on
go
select 'ALTER DATABASE [' + name + '] SET RECOVERY SIMPLE'
from sys.databases
where database_id > 6
and recovery_model_desc = 'FULL'

We’re using Log Shipping for our DR environment, and before I opened up the databases, I needed to stop the LS Restore processes for all 22 of the databases, and I wasn’t about to right-click on 22 SQL Agent jobs. That’s when I wrote this little nugget:

set nocount on
go
select 'EXEC msdb.dbo.sp_update_job @job_id=N'''+ cast(job_id as varchar(60))

+''', @enabled=0
GO'
from msdb.dbo.sysjobs
where name like 'LSRestore_%'
and enabled = 1

What this does is generate a SQL script that I can copy, paste, and run. Sure, I could have encapsulated this into a cursor and EXECute it, but I like to have a little bit of control over these things.  Lately, I’ve become a big fan of writing scripts that generate other scripts.

After the DR test, I write something similar that re-enabled those jobs once I had my backups restored.

I’m working on a toolkit that DBAs will be able to use to have this data ready for their auditors. It’s just a handful of scripts that generate the data needed to demonstrate some basic audit controls. By dumping that data into the BI engine of your choice, it will look like you know what you’re doing and are well prepared. Here are a few things that you can expect.

• Basic Server Configuration Info
• Database logins
• Database logins with the sysadmin role
• List of users per database
• List of users per database including role
• List of database roles and users included
• List of explicit grants for database users
• Backup history
• Failed backups
• Failed backups and proof of notification
• List of SQL Agent Jobs
• SQL Agent Jobs and Schedule
• SQL Agent Job History

This really hit me on Wednesday night when I was talking to Kimberly Tripp about virtual log files. Here I was, talking to one of the most knowledgable people on the subject, and she was answering my questions, seeming to enjoy the conversation. This is a community of people passionate about SQL Server, and we love to talk about it. I got so much out of some of these conversations, and I’m already questioning some of the “best practices” my company suggests with our product. It’s time to challenge the product people and rock the boat a little bit.

Before heading to the conference, Denny Cherry and Tom LaRock gave a webinar about the Summit, and one of the things they said was to take advantage of the networking opportunities. This is not a conference to just attend and then go back to your hotel room at night. Every night has some opportunity to network and connect with other SQL Server professionals. A lot of people don’t take advantage of those opportunities, and that’s sad.

I joked to a friend last night that I got to see my new boss at the Summit. I’m just not sure who that was.

There are people who attend the Summit and those who experience the summit. I’m so glad I was able to experience it.

Being here is realizing a bit of a dream for me. I’ve been trying to get here for the past three years, and my former employer would never let me attend. Even when I agreed to pay for it out of pocket, they balked. Ultimately, it’s one of the reasons why they’re my former employer.

This is not a cheap event, and I have to say that it’s been worth every penny. Just by being here and listening to some of the experts, I’m already a better DBA for it. I’ve learned a ton, and a lot of it revolves around performance tuning. I like to think of myself as an operational DBA, dealing with security and the day-to-day getting of stuff done. Getting to listen to some of the speakers around this topic has really been remarkable.

Despite all of the great sessions, my top goal for attending the PASS Summit was networking, and that has been amazing. I’ve met some awesome people, but the highlight was last night when Paul Randal introduced himself to me. And he called me by name. It’s analogous to a teenager meeting his favorite sports icon. Paul is a cornerstone of this community, and the fact that he knew who I was was–well that was really flattering. And of course I got to meet his brilliant wife Kimberly. We had a great conversation about VLF management, which is something we’re struggling with in my current environment.

Speaking of cornerstones, I finally got to meet Kevin Kline from Quest Software. He’s been such a great resource for this community, and I’m glad to have finally met him.

Getting to meet Gail Shaw and listening to her speak about execution plans twice was another highlight. This is just the tip of the iceberg. I could blather on for days about the amazing people in this community that I’ve met this week.

And then there are the people I already know. Today, I went to Tom LaRock’s halfday session on performance tuning. Tom could have been presenting on tying your shoes, and I still would have gone. When he presents, he has such command of the room, and I envy his presentation skills. If I’m ever half that good, I’ll be thrilled. And then there is Buck Woody. We had a great conversation a few months ago about my career path, and we had a follow-up to that conversation today. The last two nights, I’ve gotten to hang out with Karen Lopez, and I can honestly say that she’s one of my favorite people on the planet. Denny Cherry was giving me some feedback on my ideas of writing my own log shipping process. And then there is Brent Ozar. He’s the guy that everyone asks advice from, and for very good reason.

Tomorrow is the last day of the summit, and there are still some amazing sessions to go. I think I shall be sad to be leaving Seattle. But next year, I will be back, hopefully as a presenter.