SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Keep It Simple


Keep It Simple

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)

Group: Administrators
Points: 145921 Visits: 19425
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
My Blog: www.voiceofthedba.com
Frank Bazan
Frank Bazan
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1450 Visits: 1087
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
Greg Edwards-268690
Greg Edwards-268690
SSCarpal Tunnel
SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)

Group: General Forum Members
Points: 4210 Visits: 8593
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
ChrisMoix-87856
ChrisMoix-87856
SSCrazy
SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)

Group: General Forum Members
Points: 2136 Visits: 941
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...



John Hoegy
John Hoegy
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
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
Alvin Ramard
Alvin Ramard
SSCrazy Eights
SSCrazy Eights (9.1K reputation)SSCrazy Eights (9.1K reputation)SSCrazy Eights (9.1K reputation)SSCrazy Eights (9.1K reputation)SSCrazy Eights (9.1K reputation)SSCrazy Eights (9.1K reputation)SSCrazy Eights (9.1K reputation)SSCrazy Eights (9.1K reputation)

Group: General Forum Members
Points: 9126 Visits: 11684
KISS also stands for Keep It Sql Server

Smile



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.

For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help
GSquared
GSquared
SSC Guru
SSC Guru (57K reputation)SSC Guru (57K reputation)SSC Guru (57K reputation)SSC Guru (57K reputation)SSC Guru (57K reputation)SSC Guru (57K reputation)SSC Guru (57K reputation)SSC Guru (57K reputation)

Group: General Forum Members
Points: 57509 Visits: 9730
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
Steve Jones
Steve Jones
SSC Guru
SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)

Group: Administrators
Points: 145921 Visits: 19425
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
My Blog: www.voiceofthedba.com
TcW_1978
TcW_1978
SSChasing Mays
SSChasing Mays (628 reputation)SSChasing Mays (628 reputation)SSChasing Mays (628 reputation)SSChasing Mays (628 reputation)SSChasing Mays (628 reputation)SSChasing Mays (628 reputation)SSChasing Mays (628 reputation)SSChasing Mays (628 reputation)

Group: General Forum Members
Points: 628 Visits: 160
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.
Steve Jones
Steve Jones
SSC Guru
SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)SSC Guru (145K reputation)

Group: Administrators
Points: 145921 Visits: 19425
Alvin Ramard (3/12/2009)

KISS also stands for Keep It Sql Server

Smile


ROFL!w00t

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search