On Mon, Nov 16, 2009 at 2:04 PM, Robert Schnabel <schnabelr@missouri.edu> wrote:
> Granted, but the point of me testing this is to say whether or not the
> Diskeeper service could introduce a problem. If the system recovers without
> Diskeeper running but does not recover while Diskeeper is actively running
> then we have a problem. If they both recover then I've answered the
> question "Have you unplugged the power cord a few times in the middle of
> heavy write activity?" I understand that we can't prove that it works but I
> should be able to at least answer the question asked.
>
> I wouldn't consider my database a production one. I basically use it to
> store a large amount of genetic data for my lab. The only time the database
> gets use is when I use it. Short of frying a piece of hardware by pulling
> the plug I'm not worried about losing any data and rebuilding is actually
> quite a simple process that only takes about 2 hours... been there done that
> when I pulled the wrong SAS connector.
Be careful, it's not uncommon for a database / app to suddenly become
popular and people start expecting it to be up all the time. For
things like a corporate intranet, losing a few hours work from
something like a power loss is acceptable.
We have four types of dbs where I work. session servers can be
configured to have fsync off and don't have to be ultra reliable under
things like power loss. Search database which gets recreated every
few days as the indexer runs. Stats database where reliability is
sorta important but not life or death, and the user data database
which has to work and stay up. So each one is tested differently
because each one would have a much different impact if they crash and
can't come back up without help.