Corruption

Hi. Quick question:
Are SQL server databases prone to corruption?
MikeNot in 7.0 or 2000. Corruption these days is usually due to faulty hardware
or power outages, both of which can be mostly avoided with the right
configuration.
--
Andrew J. Kelly
SQL Server MVP
"Mike Tremendous" <noone@.hotmail.com> wrote in message
news:%23I3aZBxrDHA.2304@.TK2MSFTNGP12.phx.gbl...
> Hi. Quick question:
> Are SQL server databases prone to corruption?
> Mike
>|||> > Hi. Quick question:
> > Are SQL server databases prone to corruption?
> Not in 7.0 or 2000. Corruption these days is usually due to faulty
hardware
> or power outages, both of which can be mostly avoided with the right
> configuration.
What about with so-called 'abnormal' use? Eg:
- What if there are clients not disconneting cleanly and leaving
transactions open?
- How about creating foreign keys and the like whilst other users are
connected?
- What about executing a huge transactions that effects, say, 10,000,000
rows, and then rolling it back?
- What about restarting the SQL Server service with clients connected and
transactions open?
Can it cope with these scenarios?
Mike|||Yes these are essentially non-issues when it comes to corrupting the
database. Any time a user is disconnected the server will automatically
roll back any open trans. Creating keys and huge trans are all Atomic
operations and the only issue is user performance not stability. Even
restarting a server should not be an issue from a sql server standpoint as
when it restarts it will automatically roll back any uncommitted trans
before it allows new ones in. I wouldn't recommend restarting a server with
users in it for general purposes but SQL Server wouldn't be much of an
enterprise db if it didn't handle the issues you pose correctly.
--
Andrew J. Kelly
SQL Server MVP
"Mike Tremendous" <noone@.hotmail.com> wrote in message
news:OLKPgZzrDHA.1740@.TK2MSFTNGP12.phx.gbl...
> > > Hi. Quick question:
> > > Are SQL server databases prone to corruption?
> >
> > Not in 7.0 or 2000. Corruption these days is usually due to faulty
> hardware
> > or power outages, both of which can be mostly avoided with the right
> > configuration.
> What about with so-called 'abnormal' use? Eg:
> - What if there are clients not disconneting cleanly and leaving
> transactions open?
> - How about creating foreign keys and the like whilst other users are
> connected?
> - What about executing a huge transactions that effects, say, 10,000,000
> rows, and then rolling it back?
> - What about restarting the SQL Server service with clients connected and
> transactions open?
> Can it cope with these scenarios?
> Mike
>|||> Yes these are essentially non-issues when it comes to corrupting the
> database. Any time a user is disconnected the server will automatically
> roll back any open trans. Creating keys and huge trans are all Atomic
> operations and the only issue is user performance not stability. Even
> restarting a server should not be an issue from a sql server standpoint as
> when it restarts it will automatically roll back any uncommitted trans
> before it allows new ones in. I wouldn't recommend restarting a server
with
> users in it for general purposes but SQL Server wouldn't be much of an
> enterprise db if it didn't handle the issues you pose correctly.
Thanks for the advice.
Mike