Keep It Simple

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » Keep It Simple

17 posts, Page 1 of 2

1 2 »»

Keep It Simple

Rate Topic

Display Mode

Topic Options

Author

Message

Steve Jones - SSC Editor

Posted Thursday, March 12, 2009 12:32 AM

SSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 1:47 PM
Points: 31,406, Visits: 13,722

Comments posted to this topic are about the item Keep It Simple

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #673960

Frank Bazan

Posted Thursday, March 12, 2009 5:28 AM

SSC Veteran

Group: General Forum Members
Last Login: Wednesday, March 06, 2013 3:02 PM
Points: 268, Visits: 1,055

It's interesting how people's interpretation of keeping it simple varies from organisation to organisation. I've worked in places where a developers concept of keeping it simple meant the simplest code to write (hard coding, code that is written for a specific server, or to do a particular thing in a particular circumstance). This for me is a scenario that I do everything I can to change.

For me the notion of keeping it simple means simple to manage. To achieve this often requires the most difficult code and considerably more effort.

I'd be inclined to agree with you in your point about it not being necessary to do the same work on every server just for the sake of it, however what I would want is exactly the same logic applied on all my servers. In a corporation where developers and operational staff / servers are kept in isolation, it is essential that even if the data is different, the logic stays the same. That way your developers know what to expect when its release time.

Kindest Regards,

Frank Bazan
@Bikeride2Africa

Post #674086

Greg Edwards-268690

Posted Thursday, March 12, 2009 7:49 AM

Right there with Babe

Group: General Forum Members
Last Login: Yesterday @ 12:34 PM
Points: 781, Visits: 5,176

Overthinking can kill you - too complex, and you could miss a key ingredient. And thinking tends to get me in trouble, so I avoid it as much as possible. Exclamation Mark

Some databases - like the backend for RS or WSS - generally can be simple backups once a day. Risk to the Business and the question of how difficult to recreate what I might have lost are weighed.
Transactional DB's need the constant just in case of disaster - how do I recover approach.
So we have never used a one size fits all method of management. It varies by db.

Working in a data warehouse gives me a different perspective than some. Our cube build pegs our server for several hours each night. A network admin looks at averages, and would say our server is under utilized. I look at the peaks during the night, and during the day, and manage to the peaks.
I think our 'green' management is more influenced by working towards Hyper V and virtualized. But there again, green is only a part of it. A bigger driver is managing upgrades - they will be more driven by the application release cycles than hardware lease cycles.
Greg E

Post #674229

ChrisMoix-87856

Posted Thursday, March 12, 2009 7:52 AM

SSC Eights!

Group: General Forum Members
Last Login: Wednesday, April 03, 2013 8:23 AM
Points: 966, Visits: 927

That's an interesting angle - possibly sacrifice some performance for electricity savings.

I'd still probably err on the performance side, but I hadn't really thought about it that way.

I'd be curious to see what the power consumption of database servers is versus the entire data center - if it is a small percentage (depends on how many database servers you have, obviously) it wouldn't make too much sense to conserve.

With all of the backups to tape (via tape libraries), etc. going on during the night for all of the servers we have, I doubt that (in my company) the hit for indexing and full backups is too high.

Thought provoking...

Post #674234

John Hoegy

Posted Thursday, March 12, 2009 7:58 AM

Forum Newbie

Group: General Forum Members
Last Login: Thursday, June 17, 2010 3:30 PM
Points: 5, Visits: 15

Good comments, and good way of thinking about things. It certainly got me thinking...

My takeaway is that it's important to not become complacent regarding our priorities and the methods we use to evaluate those priorities. Often times there are multiple factors, both internal and external, that affect our priorities, and the way we work.

That being said, in order to truly evaluate what's important, we need to truly understand the cost of our actions. For example, in deciding not to back up or reindex every night in order to save energy must be balanced against the cost of not doing so (e.g. in terms of performance). Considering this specific example, it would be interesting to calculate what the actual savings, in terms of energy consumption, would be for altering the backup/reindexing strategy. It would also be interesting to see the benefit in terms of a better end-user experience in doing these things, and at what point (if any) that experience begins to degrade due to the altered strategy.

Best regards,
-- John.

John Hoegy
Technical Specialist

Post #674240

Alvin Ramard

Posted Thursday, March 12, 2009 8:07 AM

Hall of Fame

Group: General Forum Members
Last Login: Saturday, November 10, 2012 8:24 AM
Points: 3,031, Visits: 7,383

KISS also stands for Keep It Sql Server

:)

Alvin Ramard
Memphis PASS Chapter

All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.

Post #674252

GSquared

Posted Thursday, March 12, 2009 8:10 AM

SSCoach

Group: General Forum Members
Last Login: Monday, May 06, 2013 1:09 PM
Points: 15,439, Visits: 9,569

I try to make my maintenance plans as lazy as possible. I set them up to do the minimum necessary to make sure everything works well. That means index rebuilds when they are needed, not every night, for example.

I generally do full backups every night for all production databases. I've yet to manage a database where a greater amount of data loss would be acceptible, and I've found that long periods of diff backups make for a higher probability of data loss. I could see, in some cases, an argument for weekly full and nightly diff and every-four-hour tran (for OLTP). Disregard the tran for databases that aren't transactional, of course (ones loaded nightly with ETL processes, for example). But the nightly full backups is more of a habit than otherwise, and works pretty well.

On the laxy maintenance, part of the goal is to free up as much processing time as possible, because I'm used to servers that have to do a lot of work overnight to load up reporting tables and such, but also have to do maintenance overnight.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Post #674260

Steve Jones - SSC Editor

Posted Thursday, March 12, 2009 9:16 AM

SSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 1:47 PM
Points: 31,406, Visits: 13,722

Glad the ed got you to think.

I wish we had more insight into power usage. I suspect that it's coming over time, but hard to get at times now.

I found that moving to weekly Fulls, and daily diffs saved a lot of space. I'm sure it saved power as well since less to back up, less full load at night on the server, etc. We saved close to $10k in tapes at JDE back in 2001/2002 with this. Adding in the savings from compression at that time in backups, and we paid for our licenses in a year.

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #674346

TcW_1978

Posted Thursday, March 12, 2009 9:17 AM

Old Hand

Group: General Forum Members
Last Login: Wednesday, May 01, 2013 1:33 PM
Points: 368, Visits: 156

Everything works better when you're KIS'ing, as a developper I can tell you that keeping it simple doesn't mean to write simple code. You can build something and work hard, that's good, the simple part should be understanding it and modifying it when the next developper steps in your things.

Same thing for database and table structures... you should knock your head on the wall making them as pure as possible, so it can be understood more quickly by the next kid who has to work in them.

Post #674347

Steve Jones - SSC Editor

Posted Thursday, March 12, 2009 9:17 AM

SSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 1:47 PM
Points: 31,406, Visits: 13,722

Alvin Ramard (3/12/2009)

KISS also stands for Keep It Sql Server

:)

ROFL!

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #674349

« Prev Topic | Next Topic »

17 posts, Page 1 of 2

1 2 »»

Permissions