March 30, 2009 at 8:46 am
Disaster preparation is something most people don't do well. And I don't just mean for computer-related issues.
How many people learn basic first aid? How about CPR? How many know how to handle it if someone has a back/neck/head injury?
How many people hold fire drills in their homes? When was the last time your employer held one? Have you practiced opening doors in a fire situation (test for heat on the door before grabbing a metalic doorknob that might be hot enough to burn your hand on contact, and so on)?
Simple things like having an "In Case of Emergency" number on your cell phone. How many have that? How many don't even know what I mean by that?
How about having a "stranded kit" in the trunk of your car?
No. Most people don't take care of that kind of thing. And if they can't do the stuff that might just save someone's life, quite possibly their own, how can you expect them to deal with something like a network outage, power surge, etc., affecting a data center or application?
- 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
March 30, 2009 at 9:12 am
IceDread (3/30/2009)
All those problems could still arise, like loss of connection, but to be 100% safe one has to do a lot of work that might not always be needed / wanted depending on the customer.
Yep, I agree. Not always needed. Selling cars, might be bad if part of a transaction gets out of whack, but not necessarily worth the time to check things. Moving money or calculating drug distribution in a machine, better be perfect.
The problem with the client (whether that's a desktop or a middle server) is that if it fails, crash/network/whatever, it might not know that a rollback needs to be issued. If it uses a DB transaction, then at least that part will eventually roll back when the connection breaks. Or someone catches it.
Not saying you shouldn't ever have business logic in middle tiers or clients, but transactional logic, which should be short and sweet, needs to be in server systems (not necessarily a RDBMS) that is designed for it. Queueing systems and other systems support transactional properties as well.
March 30, 2009 at 12:22 pm
Phil,
Thanks for keeping this topic alive and well. Oh, the many times I've heard:
"...who needs recovery, our servers never go down..."
Yea, right.
True Story: Once in a meeting with a CTO, the JDEdwards consultant professed: "...It is a 400..."
That is, an IBM A/S 400, and implying that it never goes down. A week later, there was a hardware failure and the accounting system was down for four days as they raced to get the spare parts. Humm, I guess they were not prepared?
For any of you who have dug deep into the SQL Server internals, you will have found that the internal page structure and recovery design of SQL Server is excellent. You still need to plan for recovery, but SQL Server has an excellent design. And has been excellent for a very long time.
A few weeks ago, I posted a query on Linkedin regarding the recovery approaches for MySQL. (not SQL Server -> but MySQL) I mostly got MySQL hate mail about how their MySQL systems never went down, so it was not important. Just an FYI, MySQL has a weak recovery design, IMHO.
The time to plan for and test for recovery is before disaster happens, not after the fact.
Thanks again Phil!
The more you are prepared, the less you need it.
March 30, 2009 at 3:10 pm
I don't think business objects belong in the database neither is the relational model of an application storage for CRUD. That is the reason some big companies keep both layers in separate teams so there is some balance.
But I have also seen many applications without relational model or almost useless middle layer all are looking to move to 64bits. I just say no the application is missing layers of design the problem is not related to 64bits.
Kind regards,
Gift Peddie
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply