Hi newsgroup,
in the last days we had a lot of trouble with our SQL-Server2000 database.
We moved to complete new Hardware. Now it's solved (i hope so),
but we want to be prepared for the future. Therefore i've a few questions:
During the normal maintenance of the database some consistency errors were d
etected.
The REPAIR_ALLOW_DATA_LOSS option was suggested by dbcc checkdb.
We had the luck, that not data loss was mentioned in the log file.
So, can we be really sure that there was no data loss?
If there's a data loss, how detailed is the information about the lost data?
After the first run with the REPAIR_ALLOW_DATA_LOSS option the next checkdb
detected still errors. (The first job wrote to the log file that all errors
were corrected)
The check suggested the REPAIR_REBUILD option.
For me the question is, why are there still errors after the first run with
the
REPAIR_ALLOW_DATA_LOSS option? How can we avoid to run the job with a REPAIR
_XXXXX option more
than one time.
Thank you & Regards,
Sven KrampeHi Sven,
The reason it sometimes needs to be run twice or more is that some errors
can mask other errors. There are many different integrity checks performed
on the various structures in the database. If a problem is detected with a
higher level structure, this may prevent lower-level integrity checks from
running. Once the higher-level roblem is fixed, a subsequent check may
discover these masked errors.
We have made great strides in reducing this phenomenon in the upcoming Yukon
release.
As a side note, you should always endeavor to use your backups to recover
from corruption issues rather than running repair. The
repair_allow_data_loss option is aptly and deliberately named as it may need
to delete some of your data to remove corruption and does nothing to prevent
further hardware caused corruption (how could it?). You should assume that
data was lost if you had to use this option and so your business or
application logic may no longer be correct (constraints etc).
Let me know if you have any further questions.
Regards
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:49F9BF8C-7B8B-4B10-BCB1-C60295BA60C8@.microsoft.com...
> Hi newsgroup,
> in the last days we had a lot of trouble with our SQL-Server2000 database.
> We moved to complete new Hardware. Now it's solved (i hope so),
> but we want to be prepared for the future. Therefore i've a few questions:
> During the normal maintenance of the database some consistency errors were
detected.
> The REPAIR_ALLOW_DATA_LOSS option was suggested by dbcc checkdb.
> We had the luck, that not data loss was mentioned in the log file.
> So, can we be really sure that there was no data loss?
> If there's a data loss, how detailed is the information about the lost
data?
> After the first run with the REPAIR_ALLOW_DATA_LOSS option the next
checkdb
> detected still errors. (The first job wrote to the log file that all
errors were corrected)
> The check suggested the REPAIR_REBUILD option.
> For me the question is, why are there still errors after the first run
with the
> REPAIR_ALLOW_DATA_LOSS option? How can we avoid to run the job with a
REPAIR_XXXXX option more
> than one time.
>
> Thank you & Regards,
> Sven Krampe|||...
You should assume that
data was lost if you had to use this option and so your business or
application logic may no longer be correct (constraints etc).
...
Just to be sure: You mean, that it's possible that data is lost and we do no
t have any information about this in the Log-File of the repair job?
We check our database every night.
So, what would you suggest if we'll find consistency errors again (with the
suggestion repair_allow_data_loss)?
Go back to the last complete backup? (lose 24 h work of the users)!
Have a system downtime and try to repair the database?
Thank you very much for your help!
Regards,
Sven Krampe|||If you do regular transaction log backups, you can do a log backup after you
discover the corruption, and then
restore latest clean db backup and all subsequent log backups. Most probably
, the corruption will not re-occur
when you restore the log backups and you'll have no data loss. Below are my
general recommendations, btw:
http://www.karaszi.com/sqlserver/in..._suspect_db.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:73BA7F69-450B-4CE9-8C7C-1D8DDB0F10AF@.microsoft.com...
> ...
> You should assume that
> data was lost if you had to use this option and so your business or
> application logic may no longer be correct (constraints etc).
> ...
> Just to be sure: You mean, that it's possible that data is lost and we do not have
any information about
this in the Log-File of the repair job?
> We check our database every night.
> So, what would you suggest if we'll find consistency errors again (with the sugges
tion
repair_allow_data_loss)?
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
> Thank you very much for your help!
> Regards,
> Sven Krampe
>|||> Just to be sure: You mean, that it's possible that data is lost and we do
not have any information about this in the Log-File of the repair job?
I'm not sure what's captured in the log file but DBCC always provides
output.
> So, what would you suggest if we'll find consistency errors again (with
the suggestion repair_allow_data_loss)?
I would suggest you have a hardware issue if you see it again - in fact, I'd
suggest you do root-cause analysis to make sure you hardware is sound anyway
just because you saw this corruption.
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
>
You should always be able to restore from your backups - repair should
always be a last resort. How often you take them is up to you - you must ask
yourself 'how much data can my business afford to lose?'. If the answer is
zero, then you need to beef up your backup strategy and put in place a
disaster recovery strategy (maybe use clustering, log shipping etc). I've
seen catastophic failures where the loss has only been 15 minutes or less
with a daily full backup and log backups every 15 mins.
Regards.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:73BA7F69-450B-4CE9-8C7C-1D8DDB0F10AF@.microsoft.com...
> ...
> You should assume that
> data was lost if you had to use this option and so your business or
> application logic may no longer be correct (constraints etc).
> ...
> Just to be sure: You mean, that it's possible that data is lost and we do
not have any information about this in the Log-File of the repair job?
> We check our database every night.
> So, what would you suggest if we'll find consistency errors again (with
the suggestion repair_allow_data_loss)?
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
> Thank you very much for your help!
> Regards,
> Sven Krampe
>sql
Showing posts with label trouble. Show all posts
Showing posts with label trouble. Show all posts
Thursday, March 22, 2012
dbcc repair_allow_data_loss
Hi newsgroup,
in the last days we had a lot of trouble with our SQL-Server2000 database.
We moved to complete new Hardware. Now it's solved (i hope so),
but we want to be prepared for the future. Therefore i've a few questions:
During the normal maintenance of the database some consistency errors were detected.
The REPAIR_ALLOW_DATA_LOSS option was suggested by dbcc checkdb.
We had the luck, that not data loss was mentioned in the log file.
So, can we be really sure that there was no data loss?
If there's a data loss, how detailed is the information about the lost data?
After the first run with the REPAIR_ALLOW_DATA_LOSS option the next checkdb
detected still errors. (The first job wrote to the log file that all errors were corrected)
The check suggested the REPAIR_REBUILD option.
For me the question is, why are there still errors after the first run with the
REPAIR_ALLOW_DATA_LOSS option? How can we avoid to run the job with a REPAIR_XXXXX option more
than one time.
Thank you & Regards,
Sven Krampe
Hi Sven,
The reason it sometimes needs to be run twice or more is that some errors
can mask other errors. There are many different integrity checks performed
on the various structures in the database. If a problem is detected with a
higher level structure, this may prevent lower-level integrity checks from
running. Once the higher-level roblem is fixed, a subsequent check may
discover these masked errors.
We have made great strides in reducing this phenomenon in the upcoming Yukon
release.
As a side note, you should always endeavor to use your backups to recover
from corruption issues rather than running repair. The
repair_allow_data_loss option is aptly and deliberately named as it may need
to delete some of your data to remove corruption and does nothing to prevent
further hardware caused corruption (how could it?). You should assume that
data was lost if you had to use this option and so your business or
application logic may no longer be correct (constraints etc).
Let me know if you have any further questions.
Regards
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:49F9BF8C-7B8B-4B10-BCB1-C60295BA60C8@.microsoft.com...
> Hi newsgroup,
> in the last days we had a lot of trouble with our SQL-Server2000 database.
> We moved to complete new Hardware. Now it's solved (i hope so),
> but we want to be prepared for the future. Therefore i've a few questions:
> During the normal maintenance of the database some consistency errors were
detected.
> The REPAIR_ALLOW_DATA_LOSS option was suggested by dbcc checkdb.
> We had the luck, that not data loss was mentioned in the log file.
> So, can we be really sure that there was no data loss?
> If there's a data loss, how detailed is the information about the lost
data?
> After the first run with the REPAIR_ALLOW_DATA_LOSS option the next
checkdb
> detected still errors. (The first job wrote to the log file that all
errors were corrected)
> The check suggested the REPAIR_REBUILD option.
> For me the question is, why are there still errors after the first run
with the
> REPAIR_ALLOW_DATA_LOSS option? How can we avoid to run the job with a
REPAIR_XXXXX option more
> than one time.
>
> Thank you & Regards,
> Sven Krampe
|||...
You should assume that
data was lost if you had to use this option and so your business or
application logic may no longer be correct (constraints etc).
....
Just to be sure: You mean, that it's possible that data is lost and we do not have any information about this in the Log-File of the repair job?
We check our database every night.
So, what would you suggest if we'll find consistency errors again (with the suggestion repair_allow_data_loss)?
Go back to the last complete backup? (lose 24 h work of the users)!
Have a system downtime and try to repair the database?
Thank you very much for your help!
Regards,
Sven Krampe
|||If you do regular transaction log backups, you can do a log backup after you discover the corruption, and then
restore latest clean db backup and all subsequent log backups. Most probably, the corruption will not re-occur
when you restore the log backups and you'll have no data loss. Below are my general recommendations, btw:
http://www.karaszi.com/sqlserver/inf...suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:73BA7F69-450B-4CE9-8C7C-1D8DDB0F10AF@.microsoft.com...
> ...
> You should assume that
> data was lost if you had to use this option and so your business or
> application logic may no longer be correct (constraints etc).
> ...
> Just to be sure: You mean, that it's possible that data is lost and we do not have any information about
this in the Log-File of the repair job?
> We check our database every night.
> So, what would you suggest if we'll find consistency errors again (with the suggestion
repair_allow_data_loss)?
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
> Thank you very much for your help!
> Regards,
> Sven Krampe
>
|||> Just to be sure: You mean, that it's possible that data is lost and we do
not have any information about this in the Log-File of the repair job?
I'm not sure what's captured in the log file but DBCC always provides
output.
> So, what would you suggest if we'll find consistency errors again (with
the suggestion repair_allow_data_loss)?
I would suggest you have a hardware issue if you see it again - in fact, I'd
suggest you do root-cause analysis to make sure you hardware is sound anyway
just because you saw this corruption.
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
>
You should always be able to restore from your backups - repair should
always be a last resort. How often you take them is up to you - you must ask
yourself 'how much data can my business afford to lose?'. If the answer is
zero, then you need to beef up your backup strategy and put in place a
disaster recovery strategy (maybe use clustering, log shipping etc). I've
seen catastophic failures where the loss has only been 15 minutes or less
with a daily full backup and log backups every 15 mins.
Regards.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:73BA7F69-450B-4CE9-8C7C-1D8DDB0F10AF@.microsoft.com...
> ...
> You should assume that
> data was lost if you had to use this option and so your business or
> application logic may no longer be correct (constraints etc).
> ...
> Just to be sure: You mean, that it's possible that data is lost and we do
not have any information about this in the Log-File of the repair job?
> We check our database every night.
> So, what would you suggest if we'll find consistency errors again (with
the suggestion repair_allow_data_loss)?
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
> Thank you very much for your help!
> Regards,
> Sven Krampe
>
in the last days we had a lot of trouble with our SQL-Server2000 database.
We moved to complete new Hardware. Now it's solved (i hope so),
but we want to be prepared for the future. Therefore i've a few questions:
During the normal maintenance of the database some consistency errors were detected.
The REPAIR_ALLOW_DATA_LOSS option was suggested by dbcc checkdb.
We had the luck, that not data loss was mentioned in the log file.
So, can we be really sure that there was no data loss?
If there's a data loss, how detailed is the information about the lost data?
After the first run with the REPAIR_ALLOW_DATA_LOSS option the next checkdb
detected still errors. (The first job wrote to the log file that all errors were corrected)
The check suggested the REPAIR_REBUILD option.
For me the question is, why are there still errors after the first run with the
REPAIR_ALLOW_DATA_LOSS option? How can we avoid to run the job with a REPAIR_XXXXX option more
than one time.
Thank you & Regards,
Sven Krampe
Hi Sven,
The reason it sometimes needs to be run twice or more is that some errors
can mask other errors. There are many different integrity checks performed
on the various structures in the database. If a problem is detected with a
higher level structure, this may prevent lower-level integrity checks from
running. Once the higher-level roblem is fixed, a subsequent check may
discover these masked errors.
We have made great strides in reducing this phenomenon in the upcoming Yukon
release.
As a side note, you should always endeavor to use your backups to recover
from corruption issues rather than running repair. The
repair_allow_data_loss option is aptly and deliberately named as it may need
to delete some of your data to remove corruption and does nothing to prevent
further hardware caused corruption (how could it?). You should assume that
data was lost if you had to use this option and so your business or
application logic may no longer be correct (constraints etc).
Let me know if you have any further questions.
Regards
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:49F9BF8C-7B8B-4B10-BCB1-C60295BA60C8@.microsoft.com...
> Hi newsgroup,
> in the last days we had a lot of trouble with our SQL-Server2000 database.
> We moved to complete new Hardware. Now it's solved (i hope so),
> but we want to be prepared for the future. Therefore i've a few questions:
> During the normal maintenance of the database some consistency errors were
detected.
> The REPAIR_ALLOW_DATA_LOSS option was suggested by dbcc checkdb.
> We had the luck, that not data loss was mentioned in the log file.
> So, can we be really sure that there was no data loss?
> If there's a data loss, how detailed is the information about the lost
data?
> After the first run with the REPAIR_ALLOW_DATA_LOSS option the next
checkdb
> detected still errors. (The first job wrote to the log file that all
errors were corrected)
> The check suggested the REPAIR_REBUILD option.
> For me the question is, why are there still errors after the first run
with the
> REPAIR_ALLOW_DATA_LOSS option? How can we avoid to run the job with a
REPAIR_XXXXX option more
> than one time.
>
> Thank you & Regards,
> Sven Krampe
|||...
You should assume that
data was lost if you had to use this option and so your business or
application logic may no longer be correct (constraints etc).
....
Just to be sure: You mean, that it's possible that data is lost and we do not have any information about this in the Log-File of the repair job?
We check our database every night.
So, what would you suggest if we'll find consistency errors again (with the suggestion repair_allow_data_loss)?
Go back to the last complete backup? (lose 24 h work of the users)!
Have a system downtime and try to repair the database?
Thank you very much for your help!
Regards,
Sven Krampe
|||If you do regular transaction log backups, you can do a log backup after you discover the corruption, and then
restore latest clean db backup and all subsequent log backups. Most probably, the corruption will not re-occur
when you restore the log backups and you'll have no data loss. Below are my general recommendations, btw:
http://www.karaszi.com/sqlserver/inf...suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:73BA7F69-450B-4CE9-8C7C-1D8DDB0F10AF@.microsoft.com...
> ...
> You should assume that
> data was lost if you had to use this option and so your business or
> application logic may no longer be correct (constraints etc).
> ...
> Just to be sure: You mean, that it's possible that data is lost and we do not have any information about
this in the Log-File of the repair job?
> We check our database every night.
> So, what would you suggest if we'll find consistency errors again (with the suggestion
repair_allow_data_loss)?
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
> Thank you very much for your help!
> Regards,
> Sven Krampe
>
|||> Just to be sure: You mean, that it's possible that data is lost and we do
not have any information about this in the Log-File of the repair job?
I'm not sure what's captured in the log file but DBCC always provides
output.
> So, what would you suggest if we'll find consistency errors again (with
the suggestion repair_allow_data_loss)?
I would suggest you have a hardware issue if you see it again - in fact, I'd
suggest you do root-cause analysis to make sure you hardware is sound anyway
just because you saw this corruption.
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
>
You should always be able to restore from your backups - repair should
always be a last resort. How often you take them is up to you - you must ask
yourself 'how much data can my business afford to lose?'. If the answer is
zero, then you need to beef up your backup strategy and put in place a
disaster recovery strategy (maybe use clustering, log shipping etc). I've
seen catastophic failures where the loss has only been 15 minutes or less
with a daily full backup and log backups every 15 mins.
Regards.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:73BA7F69-450B-4CE9-8C7C-1D8DDB0F10AF@.microsoft.com...
> ...
> You should assume that
> data was lost if you had to use this option and so your business or
> application logic may no longer be correct (constraints etc).
> ...
> Just to be sure: You mean, that it's possible that data is lost and we do
not have any information about this in the Log-File of the repair job?
> We check our database every night.
> So, what would you suggest if we'll find consistency errors again (with
the suggestion repair_allow_data_loss)?
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
> Thank you very much for your help!
> Regards,
> Sven Krampe
>
dbcc repair_allow_data_loss
Hi newsgroup
in the last days we had a lot of trouble with our SQL-Server2000 database
We moved to complete new Hardware. Now it's solved (i hope so)
but we want to be prepared for the future. Therefore i've a few questions
During the normal maintenance of the database some consistency errors were detected
The REPAIR_ALLOW_DATA_LOSS option was suggested by dbcc checkdb
We had the luck, that not data loss was mentioned in the log file
So, can we be really sure that there was no data loss
If there's a data loss, how detailed is the information about the lost data
After the first run with the REPAIR_ALLOW_DATA_LOSS option the next checkdb
detected still errors. (The first job wrote to the log file that all errors were corrected
The check suggested the REPAIR_REBUILD option
For me the question is, why are there still errors after the first run with th
REPAIR_ALLOW_DATA_LOSS option? How can we avoid to run the job with a REPAIR_XXXXX option mor
than one time
Thank you & Regards
Sven KrampeHi Sven,
The reason it sometimes needs to be run twice or more is that some errors
can mask other errors. There are many different integrity checks performed
on the various structures in the database. If a problem is detected with a
higher level structure, this may prevent lower-level integrity checks from
running. Once the higher-level roblem is fixed, a subsequent check may
discover these masked errors.
We have made great strides in reducing this phenomenon in the upcoming Yukon
release.
As a side note, you should always endeavor to use your backups to recover
from corruption issues rather than running repair. The
repair_allow_data_loss option is aptly and deliberately named as it may need
to delete some of your data to remove corruption and does nothing to prevent
further hardware caused corruption (how could it?). You should assume that
data was lost if you had to use this option and so your business or
application logic may no longer be correct (constraints etc).
Let me know if you have any further questions.
Regards
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:49F9BF8C-7B8B-4B10-BCB1-C60295BA60C8@.microsoft.com...
> Hi newsgroup,
> in the last days we had a lot of trouble with our SQL-Server2000 database.
> We moved to complete new Hardware. Now it's solved (i hope so),
> but we want to be prepared for the future. Therefore i've a few questions:
> During the normal maintenance of the database some consistency errors were
detected.
> The REPAIR_ALLOW_DATA_LOSS option was suggested by dbcc checkdb.
> We had the luck, that not data loss was mentioned in the log file.
> So, can we be really sure that there was no data loss?
> If there's a data loss, how detailed is the information about the lost
data?
> After the first run with the REPAIR_ALLOW_DATA_LOSS option the next
checkdb
> detected still errors. (The first job wrote to the log file that all
errors were corrected)
> The check suggested the REPAIR_REBUILD option.
> For me the question is, why are there still errors after the first run
with the
> REPAIR_ALLOW_DATA_LOSS option? How can we avoid to run the job with a
REPAIR_XXXXX option more
> than one time.
>
> Thank you & Regards,
> Sven Krampe|||...
You should assume tha
data was lost if you had to use this option and so your business o
application logic may no longer be correct (constraints etc)
...
Just to be sure: You mean, that it's possible that data is lost and we do not have any information about this in the Log-File of the repair job
We check our database every night
So, what would you suggest if we'll find consistency errors again (with the suggestion repair_allow_data_loss)
Go back to the last complete backup? (lose 24 h work of the users)
Have a system downtime and try to repair the database
Thank you very much for your help
Regards
Sven Kramp|||If you do regular transaction log backups, you can do a log backup after you discover the corruption, and then
restore latest clean db backup and all subsequent log backups. Most probably, the corruption will not re-occur
when you restore the log backups and you'll have no data loss. Below are my general recommendations, btw:
http://www.karaszi.com/sqlserver/info_corrupt_suspect_db.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:73BA7F69-450B-4CE9-8C7C-1D8DDB0F10AF@.microsoft.com...
> ...
> You should assume that
> data was lost if you had to use this option and so your business or
> application logic may no longer be correct (constraints etc).
> ...
> Just to be sure: You mean, that it's possible that data is lost and we do not have any information about
this in the Log-File of the repair job?
> We check our database every night.
> So, what would you suggest if we'll find consistency errors again (with the suggestion
repair_allow_data_loss)?
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
> Thank you very much for your help!
> Regards,
> Sven Krampe
>|||> Just to be sure: You mean, that it's possible that data is lost and we do
not have any information about this in the Log-File of the repair job?
I'm not sure what's captured in the log file but DBCC always provides
output.
> So, what would you suggest if we'll find consistency errors again (with
the suggestion repair_allow_data_loss)?
I would suggest you have a hardware issue if you see it again - in fact, I'd
suggest you do root-cause analysis to make sure you hardware is sound anyway
just because you saw this corruption.
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
>
You should always be able to restore from your backups - repair should
always be a last resort. How often you take them is up to you - you must ask
yourself 'how much data can my business afford to lose?'. If the answer is
zero, then you need to beef up your backup strategy and put in place a
disaster recovery strategy (maybe use clustering, log shipping etc). I've
seen catastophic failures where the loss has only been 15 minutes or less
with a daily full backup and log backups every 15 mins.
Regards.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:73BA7F69-450B-4CE9-8C7C-1D8DDB0F10AF@.microsoft.com...
> ...
> You should assume that
> data was lost if you had to use this option and so your business or
> application logic may no longer be correct (constraints etc).
> ...
> Just to be sure: You mean, that it's possible that data is lost and we do
not have any information about this in the Log-File of the repair job?
> We check our database every night.
> So, what would you suggest if we'll find consistency errors again (with
the suggestion repair_allow_data_loss)?
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
> Thank you very much for your help!
> Regards,
> Sven Krampe
>
in the last days we had a lot of trouble with our SQL-Server2000 database
We moved to complete new Hardware. Now it's solved (i hope so)
but we want to be prepared for the future. Therefore i've a few questions
During the normal maintenance of the database some consistency errors were detected
The REPAIR_ALLOW_DATA_LOSS option was suggested by dbcc checkdb
We had the luck, that not data loss was mentioned in the log file
So, can we be really sure that there was no data loss
If there's a data loss, how detailed is the information about the lost data
After the first run with the REPAIR_ALLOW_DATA_LOSS option the next checkdb
detected still errors. (The first job wrote to the log file that all errors were corrected
The check suggested the REPAIR_REBUILD option
For me the question is, why are there still errors after the first run with th
REPAIR_ALLOW_DATA_LOSS option? How can we avoid to run the job with a REPAIR_XXXXX option mor
than one time
Thank you & Regards
Sven KrampeHi Sven,
The reason it sometimes needs to be run twice or more is that some errors
can mask other errors. There are many different integrity checks performed
on the various structures in the database. If a problem is detected with a
higher level structure, this may prevent lower-level integrity checks from
running. Once the higher-level roblem is fixed, a subsequent check may
discover these masked errors.
We have made great strides in reducing this phenomenon in the upcoming Yukon
release.
As a side note, you should always endeavor to use your backups to recover
from corruption issues rather than running repair. The
repair_allow_data_loss option is aptly and deliberately named as it may need
to delete some of your data to remove corruption and does nothing to prevent
further hardware caused corruption (how could it?). You should assume that
data was lost if you had to use this option and so your business or
application logic may no longer be correct (constraints etc).
Let me know if you have any further questions.
Regards
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:49F9BF8C-7B8B-4B10-BCB1-C60295BA60C8@.microsoft.com...
> Hi newsgroup,
> in the last days we had a lot of trouble with our SQL-Server2000 database.
> We moved to complete new Hardware. Now it's solved (i hope so),
> but we want to be prepared for the future. Therefore i've a few questions:
> During the normal maintenance of the database some consistency errors were
detected.
> The REPAIR_ALLOW_DATA_LOSS option was suggested by dbcc checkdb.
> We had the luck, that not data loss was mentioned in the log file.
> So, can we be really sure that there was no data loss?
> If there's a data loss, how detailed is the information about the lost
data?
> After the first run with the REPAIR_ALLOW_DATA_LOSS option the next
checkdb
> detected still errors. (The first job wrote to the log file that all
errors were corrected)
> The check suggested the REPAIR_REBUILD option.
> For me the question is, why are there still errors after the first run
with the
> REPAIR_ALLOW_DATA_LOSS option? How can we avoid to run the job with a
REPAIR_XXXXX option more
> than one time.
>
> Thank you & Regards,
> Sven Krampe|||...
You should assume tha
data was lost if you had to use this option and so your business o
application logic may no longer be correct (constraints etc)
...
Just to be sure: You mean, that it's possible that data is lost and we do not have any information about this in the Log-File of the repair job
We check our database every night
So, what would you suggest if we'll find consistency errors again (with the suggestion repair_allow_data_loss)
Go back to the last complete backup? (lose 24 h work of the users)
Have a system downtime and try to repair the database
Thank you very much for your help
Regards
Sven Kramp|||If you do regular transaction log backups, you can do a log backup after you discover the corruption, and then
restore latest clean db backup and all subsequent log backups. Most probably, the corruption will not re-occur
when you restore the log backups and you'll have no data loss. Below are my general recommendations, btw:
http://www.karaszi.com/sqlserver/info_corrupt_suspect_db.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:73BA7F69-450B-4CE9-8C7C-1D8DDB0F10AF@.microsoft.com...
> ...
> You should assume that
> data was lost if you had to use this option and so your business or
> application logic may no longer be correct (constraints etc).
> ...
> Just to be sure: You mean, that it's possible that data is lost and we do not have any information about
this in the Log-File of the repair job?
> We check our database every night.
> So, what would you suggest if we'll find consistency errors again (with the suggestion
repair_allow_data_loss)?
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
> Thank you very much for your help!
> Regards,
> Sven Krampe
>|||> Just to be sure: You mean, that it's possible that data is lost and we do
not have any information about this in the Log-File of the repair job?
I'm not sure what's captured in the log file but DBCC always provides
output.
> So, what would you suggest if we'll find consistency errors again (with
the suggestion repair_allow_data_loss)?
I would suggest you have a hardware issue if you see it again - in fact, I'd
suggest you do root-cause analysis to make sure you hardware is sound anyway
just because you saw this corruption.
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
>
You should always be able to restore from your backups - repair should
always be a last resort. How often you take them is up to you - you must ask
yourself 'how much data can my business afford to lose?'. If the answer is
zero, then you need to beef up your backup strategy and put in place a
disaster recovery strategy (maybe use clustering, log shipping etc). I've
seen catastophic failures where the loss has only been 15 minutes or less
with a daily full backup and log backups every 15 mins.
Regards.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"skrampe" <anonymous@.discussions.microsoft.com> wrote in message
news:73BA7F69-450B-4CE9-8C7C-1D8DDB0F10AF@.microsoft.com...
> ...
> You should assume that
> data was lost if you had to use this option and so your business or
> application logic may no longer be correct (constraints etc).
> ...
> Just to be sure: You mean, that it's possible that data is lost and we do
not have any information about this in the Log-File of the repair job?
> We check our database every night.
> So, what would you suggest if we'll find consistency errors again (with
the suggestion repair_allow_data_loss)?
> Go back to the last complete backup? (lose 24 h work of the users)!
> Have a system downtime and try to repair the database?
> Thank you very much for your help!
> Regards,
> Sven Krampe
>
Friday, February 17, 2012
dbcc checkdb found 2 errors
I'm in trouble...
dbcc checkdb found 2 errors on my database and this is the first time it was
checked. It says the lowest repair is the "allow data loss". If I run repair
and data is lost, how can I find out which data it is?
Select * from table
does not finish due to
error on page xxxxx.
oh i forgot, the trouble is I don't have a backup without that error, but I
have the way to recreate database but it's huge and I wonder if I could
identify the defect rows and insert only them?
tia
Zarko
Make sure you have an updated books online (Jan 2004) and search for the error numbers in there. Almost all
corruption errors has specific recommendations in the updated Books Online.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it was
> checked. It says the lowest repair is the "allow data loss". If I run repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>
|||Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and see
what data is on it..
Google dbcc page
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it
was
> checked. It says the lowest repair is the "allow data loss". If I run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>
|||If you could post the errors, we might be able to give you a bit more insight.
Thanks,
Ryan Stonecipher
MS SQL Server Storage Engine
"Wayne Snyder" <wayne.nospam.snyder@.mariner-usa.com> wrote in message news:e4uZK0WSEHA.1544@.TK2MSFTNGP09.phx.gbl...
Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and see
what data is on it..
Google dbcc page
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it
was
> checked. It says the lowest repair is the "allow data loss". If I run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>
dbcc checkdb found 2 errors on my database and this is the first time it was
checked. It says the lowest repair is the "allow data loss". If I run repair
and data is lost, how can I find out which data it is?
Select * from table
does not finish due to
error on page xxxxx.
oh i forgot, the trouble is I don't have a backup without that error, but I
have the way to recreate database but it's huge and I wonder if I could
identify the defect rows and insert only them?
tia
Zarko
Make sure you have an updated books online (Jan 2004) and search for the error numbers in there. Almost all
corruption errors has specific recommendations in the updated Books Online.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it was
> checked. It says the lowest repair is the "allow data loss". If I run repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>
|||Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and see
what data is on it..
Google dbcc page
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it
was
> checked. It says the lowest repair is the "allow data loss". If I run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>
|||If you could post the errors, we might be able to give you a bit more insight.
Thanks,
Ryan Stonecipher
MS SQL Server Storage Engine
"Wayne Snyder" <wayne.nospam.snyder@.mariner-usa.com> wrote in message news:e4uZK0WSEHA.1544@.TK2MSFTNGP09.phx.gbl...
Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and see
what data is on it..
Google dbcc page
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it
was
> checked. It says the lowest repair is the "allow data loss". If I run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>
dbcc checkdb found 2 errors
I'm in trouble...
dbcc checkdb found 2 errors on my database and this is the first time it was
checked. It says the lowest repair is the "allow data loss". If I run repair
and data is lost, how can I find out which data it is?
Select * from table
does not finish due to
error on page xxxxx.
oh i forgot, the trouble is I don't have a backup without that error, but I
have the way to recreate database but it's huge and I wonder if I could
identify the defect rows and insert only them?
tia
ZarkoMake sure you have an updated books online (Jan 2004) and search for the err
or numbers in there. Almost all
corruption errors has specific recommendations in the updated Books Online.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it w
as
> checked. It says the lowest repair is the "allow data loss". If I run repa
ir
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>|||Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and see
what data is on it..
Google dbcc page
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it
was
> checked. It says the lowest repair is the "allow data loss". If I run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>|||If you could post the errors, we might be able to give you a bit more insigh
t.
Thanks,
Ryan Stonecipher
MS SQL Server Storage Engine
"Wayne Snyder" <wayne.nospam.snyder@.mariner-usa.com> wrote in message news:e
4uZK0WSEHA.1544@.TK2MSFTNGP09.phx.gbl...
Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and see
what data is on it..
Google dbcc page
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it
was
> checked. It says the lowest repair is the "allow data loss". If I run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>
dbcc checkdb found 2 errors on my database and this is the first time it was
checked. It says the lowest repair is the "allow data loss". If I run repair
and data is lost, how can I find out which data it is?
Select * from table
does not finish due to
error on page xxxxx.
oh i forgot, the trouble is I don't have a backup without that error, but I
have the way to recreate database but it's huge and I wonder if I could
identify the defect rows and insert only them?
tia
ZarkoMake sure you have an updated books online (Jan 2004) and search for the err
or numbers in there. Almost all
corruption errors has specific recommendations in the updated Books Online.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it w
as
> checked. It says the lowest repair is the "allow data loss". If I run repa
ir
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>|||Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and see
what data is on it..
Google dbcc page
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it
was
> checked. It says the lowest repair is the "allow data loss". If I run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>|||If you could post the errors, we might be able to give you a bit more insigh
t.
Thanks,
Ryan Stonecipher
MS SQL Server Storage Engine
"Wayne Snyder" <wayne.nospam.snyder@.mariner-usa.com> wrote in message news:e
4uZK0WSEHA.1544@.TK2MSFTNGP09.phx.gbl...
Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and see
what data is on it..
Google dbcc page
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it
was
> checked. It says the lowest repair is the "allow data loss". If I run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>
dbcc checkdb found 2 errors
I'm in trouble...
dbcc checkdb found 2 errors on my database and this is the first time it was
checked. It says the lowest repair is the "allow data loss". If I run repair
and data is lost, how can I find out which data it is?
Select * from table
does not finish due to
error on page xxxxx.
oh i forgot, the trouble is I don't have a backup without that error, but I
have the way to recreate database but it's huge and I wonder if I could
identify the defect rows and insert only them?
tia
ZarkoMake sure you have an updated books online (Jan 2004) and search for the error numbers in there. Almost all
corruption errors has specific recommendations in the updated Books Online.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it was
> checked. It says the lowest repair is the "allow data loss". If I run repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>|||Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and see
what data is on it..
Google dbcc page
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it
was
> checked. It says the lowest repair is the "allow data loss". If I run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>|||This is a multi-part message in MIME format.
--=_NextPart_000_0017_01C4495A.57644590
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
If you could post the errors, we might be able to give you a bit more =insight.
Thanks,
Ryan Stonecipher
MS SQL Server Storage Engine
"Wayne Snyder" <wayne.nospam.snyder@.mariner-usa.com> wrote in message =news:e4uZK0WSEHA.1544@.TK2MSFTNGP09.phx.gbl...
Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and =see
what data is on it..
Google dbcc page
-- Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in =message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
>
> dbcc checkdb found 2 errors on my database and this is the first =time it
was
> checked. It says the lowest repair is the "allow data loss". If I =run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
>
> oh i forgot, the trouble is I don't have a backup without that =error, but
I
> have the way to recreate database but it's huge and I wonder if I =could
> identify the defect rows and insert only them?
>
> tia
>
> Zarko
>
>
--=_NextPart_000_0017_01C4495A.57644590
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&
If you could post the errors, we might be able to =give you a bit more insight.
Thanks,
Ryan Stonecipher
MS SQL Server Storage Engine
"Wayne Snyder" wrote in message news:e4uZK0WSEHA.1544=@.TK2MSFTNGP09.phx.gbl...
Also the errors should give you the page numbers,you might try to use =dbcc page to see if you can look at the page and seewhat data is on it..Google dbcc page-- Wayne Snyder, MCDBA, SQL =Server MVPMariner, Charlotte, NChttp://www.mariner-usa.com">www.mariner-usa.com(Please =respond only to the newsgroups.)I support the Professional Association =of SQL Server (PASS) and it'scommunity of SQL Server professionals.http://www.sqlpass.org">www.sqlpass.org"Zarko =Jovanovic" wrote in messagenews:1086238949.478311@.i=nternet.fina.hr...> I'm in trouble...>> dbcc checkdb found 2 errors on my =database and this is the first time itwas> checked. It says the =lowest repair is the "allow data loss". If I runrepair> and data =is lost, how can I find out which data it is?> Select * from =table> does not finish due to> error on page xxxxx.>> oh i =forgot, the trouble is I don't have a backup without that error, =butI> have the way to recreate database but it's huge and I wonder if I =could> identify the defect rows and insert only them?>> tia>> =Zarko>>
--=_NextPart_000_0017_01C4495A.57644590--
dbcc checkdb found 2 errors on my database and this is the first time it was
checked. It says the lowest repair is the "allow data loss". If I run repair
and data is lost, how can I find out which data it is?
Select * from table
does not finish due to
error on page xxxxx.
oh i forgot, the trouble is I don't have a backup without that error, but I
have the way to recreate database but it's huge and I wonder if I could
identify the defect rows and insert only them?
tia
ZarkoMake sure you have an updated books online (Jan 2004) and search for the error numbers in there. Almost all
corruption errors has specific recommendations in the updated Books Online.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it was
> checked. It says the lowest repair is the "allow data loss". If I run repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>|||Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and see
what data is on it..
Google dbcc page
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
> dbcc checkdb found 2 errors on my database and this is the first time it
was
> checked. It says the lowest repair is the "allow data loss". If I run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
> oh i forgot, the trouble is I don't have a backup without that error, but
I
> have the way to recreate database but it's huge and I wonder if I could
> identify the defect rows and insert only them?
> tia
> Zarko
>|||This is a multi-part message in MIME format.
--=_NextPart_000_0017_01C4495A.57644590
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
If you could post the errors, we might be able to give you a bit more =insight.
Thanks,
Ryan Stonecipher
MS SQL Server Storage Engine
"Wayne Snyder" <wayne.nospam.snyder@.mariner-usa.com> wrote in message =news:e4uZK0WSEHA.1544@.TK2MSFTNGP09.phx.gbl...
Also the errors should give you the page numbers,
you might try to use dbcc page to see if you can look at the page and =see
what data is on it..
Google dbcc page
-- Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Zarko Jovanovic" <RmEaMkOnViEoTHvIoSmind_less@.bigfoot.com> wrote in =message
news:1086238949.478311@.internet.fina.hr...
> I'm in trouble...
>
> dbcc checkdb found 2 errors on my database and this is the first =time it
was
> checked. It says the lowest repair is the "allow data loss". If I =run
repair
> and data is lost, how can I find out which data it is?
> Select * from table
> does not finish due to
> error on page xxxxx.
>
> oh i forgot, the trouble is I don't have a backup without that =error, but
I
> have the way to recreate database but it's huge and I wonder if I =could
> identify the defect rows and insert only them?
>
> tia
>
> Zarko
>
>
--=_NextPart_000_0017_01C4495A.57644590
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&
If you could post the errors, we might be able to =give you a bit more insight.
Thanks,
Ryan Stonecipher
MS SQL Server Storage Engine
"Wayne Snyder"
Also the errors should give you the page numbers,you might try to use =dbcc page to see if you can look at the page and seewhat data is on it..Google dbcc page-- Wayne Snyder, MCDBA, SQL =Server MVPMariner, Charlotte, NChttp://www.mariner-usa.com">www.mariner-usa.com(Please =respond only to the newsgroups.)I support the Professional Association =of SQL Server (PASS) and it'scommunity of SQL Server professionals.http://www.sqlpass.org">www.sqlpass.org"Zarko =Jovanovic"
--=_NextPart_000_0017_01C4495A.57644590--
Subscribe to:
Posts (Atom)