Any other way of dealing w/ logical corruption in MS SQL Server 2K

Hi,
Is there any other way of dealing with so called "logical corruptions" in MS
SQL Server 2000 SP3, other than transactional replication?
-- Many thanks, OskarWhat is a logical corruption? A modification that you want to undo? Or some corruption (broken page)
than you want to clean?
Anyhow, perhaps log shipping can be an option?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:79B18C1C-27B4-4A85-B0EC-D68A399723FC@.microsoft.com...
> Hi,
> Is there any other way of dealing with so called "logical corruptions" in MS
> SQL Server 2000 SP3, other than transactional replication?
> -- Many thanks, Oskar
>|||I guess you mean "If someone deletes something unintentionally \ not
deliberately...".
Tibor' s suggestion is good. You may want to use Log Shipping. Which backs
up your transaction log at your production SQL Server and then copies it to
your Secondary SQL Server and then restores them on this server. Set about 1
hour latency before restoring or copying your transaction logs to the
Secondary SQL Server, so that, you will be able to save your data that
damages if you realize this mistake in one hour. Or, you could change that
intervals according to your needs.
For more information about Log Shipping:
http://msdn2.microsoft.com/en-us/library/ms190016.aspx
--
Ekrem Ã?nsoy
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:79B18C1C-27B4-4A85-B0EC-D68A399723FC@.microsoft.com...
> Hi,
> Is there any other way of dealing with so called "logical corruptions" in
> MS
> SQL Server 2000 SP3, other than transactional replication?
> -- Many thanks, Oskar
>|||(MS SQL Server 2000 SP3)
No, I didn't mean user errors. Apparently, in rare cases, a "logical"
corruption could be a byproduct of "physical" corruption e.g. disk or IO
driver malfunction. The logical corruption, for example, supposedly could
happen if a DML statement is passed column values that were calculated based
on "physically" corrupt column values and the DML statement succeeds i.e. is
logged in the transaction log (and possibly shipped subsequently).
When I come to think of it again, this probably means that such corruptions
(i.e. corruptions that can be transfered by means of log shipping) actually
won't be detectable by DBCC CHECKDB on the secondary log shipping server, or
is this all nonsense? Maybe Michael Hotek has something to say in this regard?
-- Many thanks, (bewildered) Oskar
"Tibor Karaszi" wrote:
> What is a logical corruption? A modification that you want to undo? Or some corruption (broken page)
> than you want to clean?
> Anyhow, perhaps log shipping can be an option?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:79B18C1C-27B4-4A85-B0EC-D68A399723FC@.microsoft.com...
> > Hi,
> > Is there any other way of dealing with so called "logical corruptions" in MS
> > SQL Server 2000 SP3, other than transactional replication?
> >
> > -- Many thanks, Oskar
> >
>|||Oskar,
I (think) I understand what you are getting at. A physical corruption creeps up so it affects
something else in some undesired way. This "something else" is not a physical corruption, it is a
"valid value in SQL Server". I think that such is probably impossible to protect yourself from. If a
physical corruption makes a row having the value 1 instead of 2, and 1 is inside the domain for that
selected datatype, then whatever mean you use to "replicate" this database to somewhere else will
not detect this as a corruption. It is a valid value (according to SQL Server after all).
We enter a grey area if we add constraints to the discussion. Say that you have a CHECK constraint
saying col = 2, but the corruption result in col = 1, then I believe that replication will not allow
that row (assuming that you have that check constraint on the destination table), where log shipping
will allow that value.
Above gets pretty abstract, and I think that it is very unlikely that you will encounter this
situation. Especially if you do your DBCC CHECKDB *and* act ASAP if that finds the physical
corruption. Perhaps Paul Randall has more to say about this, so you might want to hunt down his blog
to see...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:1E24A00B-05E5-451A-8B1F-830155A9F4A5@.microsoft.com...
> (MS SQL Server 2000 SP3)
> No, I didn't mean user errors. Apparently, in rare cases, a "logical"
> corruption could be a byproduct of "physical" corruption e.g. disk or IO
> driver malfunction. The logical corruption, for example, supposedly could
> happen if a DML statement is passed column values that were calculated based
> on "physically" corrupt column values and the DML statement succeeds i.e. is
> logged in the transaction log (and possibly shipped subsequently).
> When I come to think of it again, this probably means that such corruptions
> (i.e. corruptions that can be transfered by means of log shipping) actually
> won't be detectable by DBCC CHECKDB on the secondary log shipping server, or
> is this all nonsense? Maybe Michael Hotek has something to say in this regard?
> -- Many thanks, (bewildered) Oskar
> "Tibor Karaszi" wrote:
>> What is a logical corruption? A modification that you want to undo? Or some corruption (broken
>> page)
>> than you want to clean?
>> Anyhow, perhaps log shipping can be an option?
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
>> news:79B18C1C-27B4-4A85-B0EC-D68A399723FC@.microsoft.com...
>> > Hi,
>> > Is there any other way of dealing with so called "logical corruptions" in MS
>> > SQL Server 2000 SP3, other than transactional replication?
>> >
>> > -- Many thanks, Oskar
>> >|||I do run CHECKDB on a daily basis. Though in this particular case I suppose
I'll have to rely on SQL Server's on-the-spot corruption detection logic.
"Tibor Karaszi" wrote:
> Oskar,
> I (think) I understand what you are getting at. A physical corruption creeps up so it affects
> something else in some undesired way. This "something else" is not a physical corruption, it is a
> "valid value in SQL Server". I think that such is probably impossible to protect yourself from. If a
> physical corruption makes a row having the value 1 instead of 2, and 1 is inside the domain for that
> selected datatype, then whatever mean you use to "replicate" this database to somewhere else will
> not detect this as a corruption. It is a valid value (according to SQL Server after all).
> We enter a grey area if we add constraints to the discussion. Say that you have a CHECK constraint
> saying col = 2, but the corruption result in col = 1, then I believe that replication will not allow
> that row (assuming that you have that check constraint on the destination table), where log shipping
> will allow that value.
> Above gets pretty abstract, and I think that it is very unlikely that you will encounter this
> situation. Especially if you do your DBCC CHECKDB *and* act ASAP if that finds the physical
> corruption. Perhaps Paul Randall has more to say about this, so you might want to hunt down his blog
> to see...
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:1E24A00B-05E5-451A-8B1F-830155A9F4A5@.microsoft.com...
> > (MS SQL Server 2000 SP3)
> >
> > No, I didn't mean user errors. Apparently, in rare cases, a "logical"
> > corruption could be a byproduct of "physical" corruption e.g. disk or IO
> > driver malfunction. The logical corruption, for example, supposedly could
> > happen if a DML statement is passed column values that were calculated based
> > on "physically" corrupt column values and the DML statement succeeds i.e. is
> > logged in the transaction log (and possibly shipped subsequently).
> >
> > When I come to think of it again, this probably means that such corruptions
> > (i.e. corruptions that can be transfered by means of log shipping) actually
> > won't be detectable by DBCC CHECKDB on the secondary log shipping server, or
> > is this all nonsense? Maybe Michael Hotek has something to say in this regard?
> >
> > -- Many thanks, (bewildered) Oskar
> >
> > "Tibor Karaszi" wrote:
> >
> >> What is a logical corruption? A modification that you want to undo? Or some corruption (broken
> >> page)
> >> than you want to clean?
> >>
> >> Anyhow, perhaps log shipping can be an option?
> >>
> >> --
> >> Tibor Karaszi, SQL Server MVP
> >> http://www.karaszi.com/sqlserver/default.asp
> >> http://sqlblog.com/blogs/tibor_karaszi
> >>
> >>
> >> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> >> news:79B18C1C-27B4-4A85-B0EC-D68A399723FC@.microsoft.com...
> >> > Hi,
> >> > Is there any other way of dealing with so called "logical corruptions" in MS
> >> > SQL Server 2000 SP3, other than transactional replication?
> >> >
> >> > -- Many thanks, Oskar
> >> >
> >>
>
>