Whats Your Carbon Footprint?

Last wednesday I had the privilege to attend the Sql Master Class with Kimberly L Tripp and Paul S Randal. A lot was discussed about the causes of poorly performing systems. The session as a whole thought  left me with one overwhelming thought, "the choices we make as DBA's and Developers can have a huge impact on our Carbon Footprint".

Kimberly talked about incorrect sizing and use of datatypes, like using big int instead of tiny int and datetime instead of small datetime when additional precision is not needed.  Or the hideous use of GUID's and their impact on storage and performance requirements. The attitude of "disk space is cheap" seems to dominate as an attitude when we design databases and few us even give a second thought to the impact our storage choices make.

However its not so cut and dry, the bigger the row size, the less pages fit in memory. The more times Sql has to read a page from disk, which is an expensive operation in terms of time and resources (power etc). When GUID's are used as primary keys they take 4 times as much storage as a conventional int. Every index stores the GUID's separatley if the GUID is actually the primary key. While this may not be a problem on small databases as the database grows these differences become noticeable . Kimberly discusses this issue in more detail here.

It doesnt just end there though, as DML is applied to the rows or even just index rebuilds, bigger rows means bigger log records being generated, bigger logs on disk, backed up to tape, replicated or mirrored. Oh yes and then theres the reporting, data warehouse and the DR server which also grow at the same rate. The power and network latency that it takes to move all this data around and back it up. 

And its not just table design that effects the resources we use: badly written queries hammer system resources like CPU and disk unneccesarily. Lazy DBA's doing full backups instead of a combination of full and differential also have their own impact in terms of time and resources. Things in the electronic world tend to grow exponentially not sequentially, so what may have started as a very minor decision can turn into something with a major consequences during the lifetime of a system.

I used to see TV advertisments in England telling you to turn off light switches to help prevent global warming, but as DBA's and Developers the impact of a light switch is miniscule compared to the impact we have in the course of our careers. If the Perfect Storm of 2030 where we will experience chronic global shortages of food, water and energy doen't scare you, it should. But whether you are driven by a desire to lower your carbon footprint, or a desire to reduce the financial cost of the resources you  consume, you can make a difference....

@Blakmk

Published 20 June 2010 12:46 by blakmk

Comments

21 June 2010 11:30 by RichardDouglas

# re: Whats Your Carbon Footprint?

An interesting take on a great day.

Rich

21 June 2010 15:59 by GrumpyOldDBA

# re: Whats Your Carbon Footprint?

Whilst at some levels I might have some agreement with you I take some offence at "Lazy DBA's doing full backups instead of a combination of full and differential "  there's a great difference between full backups and a string of diffs, if the security of data is utmost then unless you're immediately restoring every diff, which requires extra ( power? )as you need the full restore first so maybe restores take more energy ( ?? ) then relying on diffs where a broken (diff )backup will destroy your chain is foolish indeed. The absolute requirement for a Production DBA is to absolutely secure the data ( to the best of ability with the tools/facilities provided etc. etc.) Sorry but that's one of the worst greenwash statements I've seen.

21 June 2010 20:12 by blakmk

# re: Whats Your Carbon Footprint?

GrumpyOldDBA, I take the point security of data is most important. Perhaps the cpu overhead of restoring a full backup then a sequence of diffs is more resource intentensive, but In my experience I take a lot more backups than I do restores. When the databases are large in size then I often ask myself why not use a plan that uses diffs in the week and reduce the amount of space consumed in disk and tape. Does a full backup really need to be taken every night?

22 June 2010 07:57 by GrumpyOldDBA

# re: Whats Your Carbon Footprint?

I suspect you're missing my point, and would you expect your bank to take your view on backups? I'm only ever concerned with minimising data loss/ maintaining integrity against as many scenarios as I can. I'd also like to quote " The only good backups are those that have been successfully restored ".

sqlblogcasts.com/.../greenwash-and-roi.aspx

22 June 2010 13:07 by blakmk

# re: Whats Your Carbon Footprint?

I would expect my bank to do whats appropriate for the job in hand. Not all banking systems are business critical but for OLTP systems with low RTO's defined of course using diffs is not the answer. Nor are they are a good candidate for when the data in the database is very volatile.

What im talking about is not being wasteful when we dont have to be. Doing a full backup on a VLDB everynight when only a fraction of the data changes is very wasteful.

"When the only tool we have is a hammer, every problem becomes a nail".....