Coconuts?

June 5, 2009 at 7:32 am (Misc, SQLServerPedia Syndication) (, , , )

I’m a bit of an old school geek, I prefer stone knives & bear skins…

“So You’re On A Deserted Island With WiFi and you’re still on the clock at work.  Okay, so not a very good situational exercise here, but let’s roll with it; we’ll call it a virtual deserted island.  Perhaps what I should simply ask is if you had a month without any walk-up work, no projects due, no performance issues that require you to devote time from anything other than a wishlist of items you’ve been wanting to get accomplished at work but keep getting pulled away from I ask this question: what would be the top items that would get your attention?”

 Brent Ozar has passed me this interesting little question, and called me a noob (even though it’s true, you get no hug in Seattle, Brent). He thought I’d disagree with his thoughts on BI. I don’t. Not at all. I suspect, strongly, that if a few more of us could take six months, really drill down on BI, understand it, breathe it and learn to properly and efficiently apply it, there’d be a bit of a revolution in business profits.

BUT… I am, first and foremost, a geek. While I can, and do, recognize, and acknowledge, Brent’s superior reasoning here… I don’t want to learn BI (I don’t want to go on the cart). I find it kind of dull and not “shiny toy” geeky enough to entice me to six months of extended diving. Plus, I’m a pretty awful salesman. So even if I had the goose that laid the golden egg, I suspect I wouldn’t be able to convince anyone of its value.

So, instead, I think I’ll spend my virtual six months expanding my skill set in a different direction. I’d like to delve back into the dark side of IT, you know, development. The area that seems to be particularly exciting these days is SharePoint. Learning all those funky ways of data storage, integration, work flow… Yeah, I think there’s room for growth and quite a lot of potential for long term gainful employment down that track. You’ll have to be good at old fashioned relational data storage, but you’ll also need to be capable with .NET programming and have a full understanding of business processes. It’s not going to deliver profits the way BI will, but it’s going to have a pretty high gee-wiz factor amongst the business types when you show how you can pass documents and processes from one part of the company to the next through a single app, with a common reporting point for the data & meta-data running the business. I know that the potential of it has quite a few managers & VP’s, my seniors, all very excited. Plus, the cross-discipline nature of the endeavor means that a real guru, which after six months of non-stop learning, I’m assuming I could imitate, would be able to write their ticket within a company.

Now that’s wishing. Let’s reset to something closer to reality and just take this from the point of view of my current job. Yeah, Brent, I’d spend time getting much cozier with PowerShell. I recognize a lot of untapped potential there from two points of view. There are a number of ways it could help with management of the servers across the enterprise. It’s also very much integrated into Operations Manager, which means you could set up some pretty sophisticated monitoring processes to really keep a proactive eye on the servers. I’m trying to pick up PowerShell in little 15 minute spurts here & there between all the other day-to-day tasks including learning how to work with spatial data & tune Dynamics CRM databases… it ain’t easy. Some time with nothing to do but focus on PowerShell would enable me to do more to work within my environment  for real improvements in the short- and long-term.

Who to pass this to?

I’m going to shotgun a bit. First, someone I pick on a lot with these things, Gail Shaw, the GilaMonster.
Next, let’s see what Tim Mitchell has in the Bucket.
Finally, I’ve actually thought about moving to Utah because I like this guy, TJay Belt.

Permalink 6 Comments

SQL Server Central Track at Connections

June 3, 2009 at 6:03 pm (Misc, SQLServerPedia Syndication) (, , )

This year at SQL Connections, there will be a new track, the SQL Server Central track (scroll down). I’ve been honored to be selected to present two different sessions on that track, MUQt or More Unecessary Query tuning (pronounced MUCK) and Scouting Out Execution Plans. I’m on a list with a bunch of speakers that… well, WOW is all I can say. I almost wish I wasn’t presenting (almost) so I can just attend their sessions & learn stuff. Anyway, for those that won’t or can’t make the PASS Summit in Seattle, I hope I catch up with you in Las Vegas (where I’m told that anything that happens will remain in place, or something, is it a transaction rollback do you think?).

Permalink 7 Comments

ORDER BY Speed

June 3, 2009 at 10:26 am (SQL Server 2008, SQLServerPedia Syndication, TSQL) (, , )

I answered a question on SSC with the comment that while an INT would perform better than a DATETIME in an ORDER BY query, assuming each has a viable index, that the difference wouldn’t be all that terribly substantial. Then I realized, maybe that’s not true. So I ran up a quick test, just to see.

First I created a little test table with the right indexes and loaded it with data:

CREATE TABLE dbo.IntDate
(IntCol INT NOT NULL,
DateCol DATETIME NOT NULL);

CREATE INDEX ixInt
ON dbo.IntDate(IntCol);
CREATE INDEX ixDate
ON dbo.IntDate(DateCol);

SELECT TOP 10000 IDENTITY( INT,1,1 ) AS n
INTO #Tally
FROM Master.dbo.SysColumns sc1,
Master.dbo.SysColumns sc2;

INSERT INTO dbo.IntDate (
IntCol
,DateCol)
SELECT t.n,
DATEADD(dd,- t.n,GETDATE() )
FROM #Tally AS t;

DROP TABLE #Tally;

Then I ran these two queries. Each one correctly accessed the index, doing a scan, to retrieve the data:

SELECT id.DateCol 
FROM dbo.IntDate AS id
ORDER BY BY DateCol DESC

SELECT  id.IntCol
FROM dbo.IntDate AS id
ORDER BY IntCol DESC

Here are the execution times:

Table 'IntDate'. Scan count 1, logical reads 26, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row(s) affected)
SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 70 ms.
(10000 row(s) affected)
Table 'IntDate'. Scan count 1, logical reads 21, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row(s) affected)
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 59 ms.

But what happens if I reverse the order?

SELECT id.DateCol 
FROM dbo.IntDate AS id
ORDER BY DateCol ASC 

SELECT id.IntCol
FROM dbo.IntDate AS id
ORDER BY IntCol ASC

Then results are:

Table 'IntDate'. Scan count 1, logical reads 26, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row(s) affected)
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 52 ms.
(10000 row(s) affected)
Table 'IntDate'. Scan count 1, logical reads 21, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row(s) affected)
SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 5 ms.

So, there can be a somewhat significant difference, although at least part of that is explained by the differences in the number of reads. Not exactly earth shattering, but good to know.

Permalink 2 Comments

« Previous page