Author Archive | admin

Don’t fear the cloud

Everyone seems to be talking about the “THE CLOUD” these days. Many in management seem to be in love with the concept as it’ll (allegedly) solve all those problems around infrastructure, storage, archiving, backups, wages, quality of tea making and many others. Many DBA’s seem to view it as a pretty negative thing, with the overarching opinion being that their jobs are about to disappear or will be reclassified as account managers negotiating over contract changes to init.ora parameters

As always the truth is somewhere in between.


End of working 2011

Well, just about to wrap up working for 2011. For the first time in years I’ve actually got a completely clear christmas break with no planned work. And hopefully the last year’s work will help ensure no unplanned work callouts either.

Looking forward to 2012; I’ve just sorted my registration for all 3 days of SQLBits in London at the end of March, and it’s looking likely that I’ve scored some Dynamics CRM 2011 training off the back of a project.

Sort of dreading having to look at rebuying my ‘work’ library next year as tle SQL 2012 books start hitting the shelves. There is a temptation to look at an E-reader to save on space/cost, but the Kindle has never really impressed, and initial reports on the Kindle Fire for technical documents aren’t promising, this could finally push me over the edge in iPad ownership.

One of the last jobs for this year was setting up mirroring for an application between 2 geo-clustered SQL installs. Really looking forward to the AlwaysOn availability groups coming in SQL Server 2012 as it looks like it will remove a lot of the pain and overhead involved in these sort of scenarios, (In fact I’ve picked this session “AlwaysOn: Maximizing High Availability with SQL Server 2012” by Allan Hirt for my Thursday session at SQLBits.


SQL Server 2012 licensing, changes-a-coming?

Reading a post by Jeremiah Peschka over at and as I commented it raises some interesting questions above the standard “How much more is SQL2012 going to cost us” ones.

Current employer has been generally moving towards a strategy of larger ‘real’ SQL boxes and using smaller virtual app servers. This is partly due to this place’s Oracle heritage, where Oracle’s mid tier structure really pushed the idea of everything running from packages in the DB.

So all the heavy lifting and processing was pushed back onto the DB iron as there was plenty of power in the newer multi-core processors which weren’t under quite so much pressure as more of the DB could be moved into memory and the SAN got faster. This was great as the app servers got correspondingly smaller so you could get more VMs onto a given infrastructure, which was great as OS licenses were cheaper than DB licensese.

Now that SQL2012 is moving to per core this model might not make as much sense as it did before. Suddenly all those extra cores in the DB boxes are an expensive liability. Based on Microsoft’s released Licensing Datasheet we’re good for the upgrade (Software Assurance to the rescue) as we’ll get all our current SQL2008 CPU licenses turned into the appropriate number of cores of SQL2012 licensing. But our standard DB box is based on 8-core procs at the minute, and according to the datasheet the a SQL2012 core license is going to be 1/4 of the cost of a SQL2008 CPU license. Which makes each processor in our boxes twice as expensive to license under 2012. Suddenly having all that horsepower starts to look like a liability that business will want to reduce.

Reducing the grunt at the backend will mean either:

  • Developers having to become a bit cleverer with their code. spending more time on it.
  • Bigger App servers

Neither of which come cheap.

It’s going to be interesting (for me at least) to see how management pass the costs around. Especially as SQL2012 is on managements wish list (after some pushing) thanks to the HA (group failover) and related reporting features (read ability on mirrors). Something to look forward to chasing up after the Christmas break


Move that SQL Server TempDB

Always a good source of SQL Server problems is to have your tempdb on the same drives as your production databases, or even worse, your system drive.

You should always repoint it during the install, or first thing after finishing the install as it requires a restart. And restarts are bad because:

  • Downtime == bad as far as businesses go
  • With SQL Server 2008, R2 and 2012 a restart loses lots of lovely DMV data that comes in really handy for diagnosing interesting problems.

So assuming you still need to shift it, it’s pretty simple.

USE master; GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'E:\Data\tempdb.mdf'); GO ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'F:\Logs\templog.ldf'); GO And then restart your SQL instance.

The above assumes noone’s sneakily renamed your tempdb files. If the have you’ll need to look up the names via SQL Server Management studio or use: use master; go SELECT name, physical_name FROM sys.master_files WHERE database_id = DB_ID(N'tempdb'); go