Veritas Backup Exec has recently started reporting occasional CHECKDB errors
in our primary SQL Server database. When I run CHECKDB manually, it sometimes
finds table inconsistencies and doesn't at other times; the inconsistencies
found are in different tables at different times, so there is no consistent
result. I have run DBCC CHECKDB(DatabaseName, REPAIR_ALLOW_DATA_LOSS) twice,
once immediately after CHECKDB without repair reported inconsistencies, but
no errors were found to repair either time. Has anyone else out there
encountered this sort of thing? Is there anything else I should be doing?
Thanks in advance...
This inconsistency is sometimes seen when there is a drive problem.
One possible scenario is:
* At some point in time your drive failed to read/write and this caused the
data to be corrupt
* DBCC CHECKDB found inconsistencies
* You repaired these by running the REPAIR_ALLOW_DATA_LOSS
* however, if any drive (or drive controller) issues are still outstanding,
it is certainly possible for SQL database to become corrupt again.
1. You want to start by checking the SQL Error logs, are there any 823
errors in there? PRB: Error message 823 may indicate hardware problems or
system problems - ID: 828339. This might indicate that Microsoft SQL
Server 2000 has detected hardware or system problems when it was reading
from or writing to database files
2. Check the application and system event logs. Are there any drive or
drive controller errors? Are there any Delayed Write Failed...errors?
3. You can use the SQLIOSTRESS utility to perform stress tests on disk
subsystems to simulate Microsoft SQL Server 2000 and Microsoft SQL Server
7.0 read, write, checkpoint, backup, sort, and read ahead activities.
http://support.microsoft.com/?id=231619
4. If possible, engage your hardware vendor to fully test and certify the
system.
5. When was the last time you updated disk or controller drivers? Are
they up to date?
KB article references (available at http://suport.microsoft.com):
86903 INF: SQL Server and Caching Disk Controllers
234656 Using Disk Drive Caching with SQL Server
46091 INF: Using Hard Disk Controller Caching with SQL Server
826433 Additional SQL Server Diagnostics Added to Detect Unreported I/O
231619 Use the SQLIOStress Utility to Stress a Disk Subsystem Such as
SQLServer
332023 Slow Disk Performance When Write Caching Is Enabled
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx
|||Thanks for your prompt and thoughtful reply. We have already run CHKDSK on
the hard drive involved and found no errors, and one of my associates has
checked error logs to no avail. We will proceed with the more thorough checks
you recommend.
In your proposed scenario, you hypothesize that REPAIR_ALLOW_DATA_LOSS fixed
the errors present, but would it do this without displaying any sort of
relevant message? Both times I ran REPAIR_ALLOW_DATA_LOSS, I specified WITH
ALL_ERRORMSGS, but each time the utility returned the message "CHECKDB found
0 allocation errors and 0 consistency errors in database xxxxx".
Thanks again... Steve B.
"Fany Vargas [MSFT]" wrote:
> This inconsistency is sometimes seen when there is a drive problem.
> One possible scenario is:
> * At some point in time your drive failed to read/write and this caused the
> data to be corrupt
> * DBCC CHECKDB found inconsistencies
> * You repaired these by running the REPAIR_ALLOW_DATA_LOSS
> * however, if any drive (or drive controller) issues are still outstanding,
> it is certainly possible for SQL database to become corrupt again.
> 1. You want to start by checking the SQL Error logs, are there any 823
> errors in there? PRB: Error message 823 may indicate hardware problems or
> system problems - ID: 828339. This might indicate that Microsoft SQL
> Server 2000 has detected hardware or system problems when it was reading
> from or writing to database files
> 2. Check the application and system event logs. Are there any drive or
> drive controller errors? Are there any Delayed Write Failed...errors?
> 3. You can use the SQLIOSTRESS utility to perform stress tests on disk
> subsystems to simulate Microsoft SQL Server 2000 and Microsoft SQL Server
> 7.0 read, write, checkpoint, backup, sort, and read ahead activities.
> http://support.microsoft.com/?id=231619
> 4. If possible, engage your hardware vendor to fully test and certify the
> system.
> 5. When was the last time you updated disk or controller drivers? Are
> they up to date?
> KB article references (available at http://suport.microsoft.com):
> ----
> --
> 86903 INF: SQL Server and Caching Disk Controllers
> 234656 Using Disk Drive Caching with SQL Server
> 46091 INF: Using Hard Disk Controller Caching with SQL Server
> 826433 Additional SQL Server Diagnostics Added to Detect Unreported I/O
> 231619 Use the SQLIOStress Utility to Stress a Disk Subsystem Such as
> SQLServer
> 332023 Slow Disk Performance When Write Caching Is Enabled
>
> Fany Vargas
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Are you secure? For information about the Strategic Technology Protection
> Program and to order your FREE Security Tool Kit, please visit
> http://www.microsoft.com/security.
> Microsoft highly recommends that users with Internet access update their
> Microsoft software to better protect against viruses and security
> vulnerabilities. The easiest way to do this is to visit the following
> websites:
> http://www.microsoft.com/protect
> http://www.microsoft.com/security/guidance/default.mspx
>
|||If dbcc checkdb ( 'gfrc_004',REPAIR_ALLOW_DATA_LOSS)
WITH
ALL_ERRORMSGS
does not report any errors - it means no errors were found. If any errors
were fixed you should see a summary of what errors were fixed. Some
errors are not repairable, if you run DBCC CHECKDB (without any options)
you will see what the minimun repair level is.
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx
Showing posts with label manually. Show all posts
Showing posts with label manually. Show all posts
Friday, February 17, 2012
DBCC CHECKDB in SQL Server 2000 - inconsistent results
Veritas Backup Exec has recently started reporting occasional CHECKDB errors
in our primary SQL Server database. When I run CHECKDB manually, it sometimes
finds table inconsistencies and doesn't at other times; the inconsistencies
found are in different tables at different times, so there is no consistent
result. I have run DBCC CHECKDB(DatabaseName, REPAIR_ALLOW_DATA_LOSS) twice,
once immediately after CHECKDB without repair reported inconsistencies, but
no errors were found to repair either time. Has anyone else out there
encountered this sort of thing? Is there anything else I should be doing?
Thanks in advance...This inconsistency is sometimes seen when there is a drive problem.
One possible scenario is:
* At some point in time your drive failed to read/write and this caused the
data to be corrupt
* DBCC CHECKDB found inconsistencies
* You repaired these by running the REPAIR_ALLOW_DATA_LOSS
* however, if any drive (or drive controller) issues are still outstanding,
it is certainly possible for SQL database to become corrupt again.
1. You want to start by checking the SQL Error logs, are there any 823
errors in there? PRB: Error message 823 may indicate hardware problems or
system problems - ID: 828339. This might indicate that Microsoft SQL
Server 2000 has detected hardware or system problems when it was reading
from or writing to database files
2. Check the application and system event logs. Are there any drive or
drive controller errors? Are there any Delayed Write Failed...errors?
3. You can use the SQLIOSTRESS utility to perform stress tests on disk
subsystems to simulate Microsoft SQL Server 2000 and Microsoft SQL Server
7.0 read, write, checkpoint, backup, sort, and read ahead activities.
http://support.microsoft.com/?id=231619
4. If possible, engage your hardware vendor to fully test and certify the
system.
5. When was the last time you updated disk or controller drivers? Are
they up to date?
KB article references (available at http://suport.microsoft.com):
----
--
86903 INF: SQL Server and Caching Disk Controllers
234656 Using Disk Drive Caching with SQL Server
46091 INF: Using Hard Disk Controller Caching with SQL Server
826433 Additional SQL Server Diagnostics Added to Detect Unreported I/O
231619 Use the SQLIOStress Utility to Stress a Disk Subsystem Such as
SQLServer
332023 Slow Disk Performance When Write Caching Is Enabled
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx|||Thanks for your prompt and thoughtful reply. We have already run CHKDSK on
the hard drive involved and found no errors, and one of my associates has
checked error logs to no avail. We will proceed with the more thorough checks
you recommend.
In your proposed scenario, you hypothesize that REPAIR_ALLOW_DATA_LOSS fixed
the errors present, but would it do this without displaying any sort of
relevant message? Both times I ran REPAIR_ALLOW_DATA_LOSS, I specified WITH
ALL_ERRORMSGS, but each time the utility returned the message "CHECKDB found
0 allocation errors and 0 consistency errors in database xxxxx".
Thanks again... Steve B.
"Fany Vargas [MSFT]" wrote:
> This inconsistency is sometimes seen when there is a drive problem.
> One possible scenario is:
> * At some point in time your drive failed to read/write and this caused the
> data to be corrupt
> * DBCC CHECKDB found inconsistencies
> * You repaired these by running the REPAIR_ALLOW_DATA_LOSS
> * however, if any drive (or drive controller) issues are still outstanding,
> it is certainly possible for SQL database to become corrupt again.
> 1. You want to start by checking the SQL Error logs, are there any 823
> errors in there? PRB: Error message 823 may indicate hardware problems or
> system problems - ID: 828339. This might indicate that Microsoft SQL
> Server 2000 has detected hardware or system problems when it was reading
> from or writing to database files
> 2. Check the application and system event logs. Are there any drive or
> drive controller errors? Are there any Delayed Write Failed...errors?
> 3. You can use the SQLIOSTRESS utility to perform stress tests on disk
> subsystems to simulate Microsoft SQL Server 2000 and Microsoft SQL Server
> 7.0 read, write, checkpoint, backup, sort, and read ahead activities.
> http://support.microsoft.com/?id=231619
> 4. If possible, engage your hardware vendor to fully test and certify the
> system.
> 5. When was the last time you updated disk or controller drivers? Are
> they up to date?
> KB article references (available at http://suport.microsoft.com):
> ----
> --
> 86903 INF: SQL Server and Caching Disk Controllers
> 234656 Using Disk Drive Caching with SQL Server
> 46091 INF: Using Hard Disk Controller Caching with SQL Server
> 826433 Additional SQL Server Diagnostics Added to Detect Unreported I/O
> 231619 Use the SQLIOStress Utility to Stress a Disk Subsystem Such as
> SQLServer
> 332023 Slow Disk Performance When Write Caching Is Enabled
>
> Fany Vargas
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Are you secure? For information about the Strategic Technology Protection
> Program and to order your FREE Security Tool Kit, please visit
> http://www.microsoft.com/security.
> Microsoft highly recommends that users with Internet access update their
> Microsoft software to better protect against viruses and security
> vulnerabilities. The easiest way to do this is to visit the following
> websites:
> http://www.microsoft.com/protect
> http://www.microsoft.com/security/guidance/default.mspx
>|||If dbcc checkdb ( 'gfrc_004',REPAIR_ALLOW_DATA_LOSS)
WITH
ALL_ERRORMSGS
does not report any errors - it means no errors were found. If any errors
were fixed you should see a summary of what errors were fixed. Some
errors are not repairable, if you run DBCC CHECKDB (without any options)
you will see what the minimun repair level is.
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx
in our primary SQL Server database. When I run CHECKDB manually, it sometimes
finds table inconsistencies and doesn't at other times; the inconsistencies
found are in different tables at different times, so there is no consistent
result. I have run DBCC CHECKDB(DatabaseName, REPAIR_ALLOW_DATA_LOSS) twice,
once immediately after CHECKDB without repair reported inconsistencies, but
no errors were found to repair either time. Has anyone else out there
encountered this sort of thing? Is there anything else I should be doing?
Thanks in advance...This inconsistency is sometimes seen when there is a drive problem.
One possible scenario is:
* At some point in time your drive failed to read/write and this caused the
data to be corrupt
* DBCC CHECKDB found inconsistencies
* You repaired these by running the REPAIR_ALLOW_DATA_LOSS
* however, if any drive (or drive controller) issues are still outstanding,
it is certainly possible for SQL database to become corrupt again.
1. You want to start by checking the SQL Error logs, are there any 823
errors in there? PRB: Error message 823 may indicate hardware problems or
system problems - ID: 828339. This might indicate that Microsoft SQL
Server 2000 has detected hardware or system problems when it was reading
from or writing to database files
2. Check the application and system event logs. Are there any drive or
drive controller errors? Are there any Delayed Write Failed...errors?
3. You can use the SQLIOSTRESS utility to perform stress tests on disk
subsystems to simulate Microsoft SQL Server 2000 and Microsoft SQL Server
7.0 read, write, checkpoint, backup, sort, and read ahead activities.
http://support.microsoft.com/?id=231619
4. If possible, engage your hardware vendor to fully test and certify the
system.
5. When was the last time you updated disk or controller drivers? Are
they up to date?
KB article references (available at http://suport.microsoft.com):
----
--
86903 INF: SQL Server and Caching Disk Controllers
234656 Using Disk Drive Caching with SQL Server
46091 INF: Using Hard Disk Controller Caching with SQL Server
826433 Additional SQL Server Diagnostics Added to Detect Unreported I/O
231619 Use the SQLIOStress Utility to Stress a Disk Subsystem Such as
SQLServer
332023 Slow Disk Performance When Write Caching Is Enabled
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx|||Thanks for your prompt and thoughtful reply. We have already run CHKDSK on
the hard drive involved and found no errors, and one of my associates has
checked error logs to no avail. We will proceed with the more thorough checks
you recommend.
In your proposed scenario, you hypothesize that REPAIR_ALLOW_DATA_LOSS fixed
the errors present, but would it do this without displaying any sort of
relevant message? Both times I ran REPAIR_ALLOW_DATA_LOSS, I specified WITH
ALL_ERRORMSGS, but each time the utility returned the message "CHECKDB found
0 allocation errors and 0 consistency errors in database xxxxx".
Thanks again... Steve B.
"Fany Vargas [MSFT]" wrote:
> This inconsistency is sometimes seen when there is a drive problem.
> One possible scenario is:
> * At some point in time your drive failed to read/write and this caused the
> data to be corrupt
> * DBCC CHECKDB found inconsistencies
> * You repaired these by running the REPAIR_ALLOW_DATA_LOSS
> * however, if any drive (or drive controller) issues are still outstanding,
> it is certainly possible for SQL database to become corrupt again.
> 1. You want to start by checking the SQL Error logs, are there any 823
> errors in there? PRB: Error message 823 may indicate hardware problems or
> system problems - ID: 828339. This might indicate that Microsoft SQL
> Server 2000 has detected hardware or system problems when it was reading
> from or writing to database files
> 2. Check the application and system event logs. Are there any drive or
> drive controller errors? Are there any Delayed Write Failed...errors?
> 3. You can use the SQLIOSTRESS utility to perform stress tests on disk
> subsystems to simulate Microsoft SQL Server 2000 and Microsoft SQL Server
> 7.0 read, write, checkpoint, backup, sort, and read ahead activities.
> http://support.microsoft.com/?id=231619
> 4. If possible, engage your hardware vendor to fully test and certify the
> system.
> 5. When was the last time you updated disk or controller drivers? Are
> they up to date?
> KB article references (available at http://suport.microsoft.com):
> ----
> --
> 86903 INF: SQL Server and Caching Disk Controllers
> 234656 Using Disk Drive Caching with SQL Server
> 46091 INF: Using Hard Disk Controller Caching with SQL Server
> 826433 Additional SQL Server Diagnostics Added to Detect Unreported I/O
> 231619 Use the SQLIOStress Utility to Stress a Disk Subsystem Such as
> SQLServer
> 332023 Slow Disk Performance When Write Caching Is Enabled
>
> Fany Vargas
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Are you secure? For information about the Strategic Technology Protection
> Program and to order your FREE Security Tool Kit, please visit
> http://www.microsoft.com/security.
> Microsoft highly recommends that users with Internet access update their
> Microsoft software to better protect against viruses and security
> vulnerabilities. The easiest way to do this is to visit the following
> websites:
> http://www.microsoft.com/protect
> http://www.microsoft.com/security/guidance/default.mspx
>|||If dbcc checkdb ( 'gfrc_004',REPAIR_ALLOW_DATA_LOSS)
WITH
ALL_ERRORMSGS
does not report any errors - it means no errors were found. If any errors
were fixed you should see a summary of what errors were fixed. Some
errors are not repairable, if you run DBCC CHECKDB (without any options)
you will see what the minimun repair level is.
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx
DBCC CHECKDB in SQL Server 2000 - inconsistent results
Veritas Backup Exec has recently started reporting occasional CHECKDB errors
in our primary SQL Server database. When I run CHECKDB manually, it sometime
s
finds table inconsistencies and doesn't at other times; the inconsistencies
found are in different tables at different times, so there is no consistent
result. I have run DBCC CHECKDB(DatabaseName, REPAIR_ALLOW_DATA_LOSS) twice,
once immediately after CHECKDB without repair reported inconsistencies, but
no errors were found to repair either time. Has anyone else out there
encountered this sort of thing? Is there anything else I should be doing?
Thanks in advance...This inconsistency is sometimes seen when there is a drive problem.
One possible scenario is:
* At some point in time your drive failed to read/write and this caused the
data to be corrupt
* DBCC CHECKDB found inconsistencies
* You repaired these by running the REPAIR_ALLOW_DATA_LOSS
* however, if any drive (or drive controller) issues are still outstanding,
it is certainly possible for SQL database to become corrupt again.
1. You want to start by checking the SQL Error logs, are there any 823
errors in there? PRB: Error message 823 may indicate hardware problems or
system problems - ID: 828339. This might indicate that Microsoft SQL
Server 2000 has detected hardware or system problems when it was reading
from or writing to database files
2. Check the application and system event logs. Are there any drive or
drive controller errors? Are there any Delayed Write Failed...errors?
3. You can use the SQLIOSTRESS utility to perform stress tests on disk
subsystems to simulate Microsoft SQL Server 2000 and Microsoft SQL Server
7.0 read, write, checkpoint, backup, sort, and read ahead activities.
http://support.microsoft.com/?id=231619
4. If possible, engage your hardware vendor to fully test and certify the
system.
5. When was the last time you updated disk or controller drivers? Are
they up to date?
KB article references (available at http://suport.microsoft.com):
----
--
86903 INF: SQL Server and Caching Disk Controllers
234656 Using Disk Drive Caching with SQL Server
46091 INF: Using Hard Disk Controller Caching with SQL Server
826433 Additional SQL Server Diagnostics Added to Detect Unreported I/O
231619 Use the SQLIOStress Utility to Stress a Disk Subsystem Such as
SQLServer
332023 Slow Disk Performance When Write Caching Is Enabled
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx|||Thanks for your prompt and thoughtful reply. We have already run CHKDSK on
the hard drive involved and found no errors, and one of my associates has
checked error logs to no avail. We will proceed with the more thorough check
s
you recommend.
In your proposed scenario, you hypothesize that REPAIR_ALLOW_DATA_LOSS fixed
the errors present, but would it do this without displaying any sort of
relevant message? Both times I ran REPAIR_ALLOW_DATA_LOSS, I specified WITH
ALL_ERRORMSGS, but each time the utility returned the message "CHECKDB found
0 allocation errors and 0 consistency errors in database xxxxx".
Thanks again... Steve B.
"Fany Vargas [MSFT]" wrote:
> This inconsistency is sometimes seen when there is a drive problem.
> One possible scenario is:
> * At some point in time your drive failed to read/write and this caused th
e
> data to be corrupt
> * DBCC CHECKDB found inconsistencies
> * You repaired these by running the REPAIR_ALLOW_DATA_LOSS
> * however, if any drive (or drive controller) issues are still outstanding
,
> it is certainly possible for SQL database to become corrupt again.
> 1. You want to start by checking the SQL Error logs, are there any 823
> errors in there? PRB: Error message 823 may indicate hardware problems or
> system problems - ID: 828339. This might indicate that Microsoft SQL
> Server 2000 has detected hardware or system problems when it was reading
> from or writing to database files
> 2. Check the application and system event logs. Are there any drive or
> drive controller errors? Are there any Delayed Write Failed...errors?
> 3. You can use the SQLIOSTRESS utility to perform stress tests on disk
> subsystems to simulate Microsoft SQL Server 2000 and Microsoft SQL Server
> 7.0 read, write, checkpoint, backup, sort, and read ahead activities.
> http://support.microsoft.com/?id=231619
> 4. If possible, engage your hardware vendor to fully test and certify the
> system.
> 5. When was the last time you updated disk or controller drivers? Are
> they up to date?
> KB article references (available at http://suport.microsoft.com):
> ----
--
> --
> 86903 INF: SQL Server and Caching Disk Controllers
> 234656 Using Disk Drive Caching with SQL Server
> 46091 INF: Using Hard Disk Controller Caching with SQL Server
> 826433 Additional SQL Server Diagnostics Added to Detect Unreported I/O
> 231619 Use the SQLIOStress Utility to Stress a Disk Subsystem Such as
> SQLServer
> 332023 Slow Disk Performance When Write Caching Is Enabled
>
> Fany Vargas
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> Are you secure? For information about the Strategic Technology Protection
> Program and to order your FREE Security Tool Kit, please visit
> http://www.microsoft.com/security.
> Microsoft highly recommends that users with Internet access update their
> Microsoft software to better protect against viruses and security
> vulnerabilities. The easiest way to do this is to visit the following
> websites:
> http://www.microsoft.com/protect
> http://www.microsoft.com/security/guidance/default.mspx
>|||If dbcc checkdb ( 'gfrc_004',REPAIR_ALLOW_DATA_LOSS)
WITH
ALL_ERRORMSGS
does not report any errors - it means no errors were found. If any errors
were fixed you should see a summary of what errors were fixed. Some
errors are not repairable, if you run DBCC CHECKDB (without any options)
you will see what the minimun repair level is.
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx
in our primary SQL Server database. When I run CHECKDB manually, it sometime
s
finds table inconsistencies and doesn't at other times; the inconsistencies
found are in different tables at different times, so there is no consistent
result. I have run DBCC CHECKDB(DatabaseName, REPAIR_ALLOW_DATA_LOSS) twice,
once immediately after CHECKDB without repair reported inconsistencies, but
no errors were found to repair either time. Has anyone else out there
encountered this sort of thing? Is there anything else I should be doing?
Thanks in advance...This inconsistency is sometimes seen when there is a drive problem.
One possible scenario is:
* At some point in time your drive failed to read/write and this caused the
data to be corrupt
* DBCC CHECKDB found inconsistencies
* You repaired these by running the REPAIR_ALLOW_DATA_LOSS
* however, if any drive (or drive controller) issues are still outstanding,
it is certainly possible for SQL database to become corrupt again.
1. You want to start by checking the SQL Error logs, are there any 823
errors in there? PRB: Error message 823 may indicate hardware problems or
system problems - ID: 828339. This might indicate that Microsoft SQL
Server 2000 has detected hardware or system problems when it was reading
from or writing to database files
2. Check the application and system event logs. Are there any drive or
drive controller errors? Are there any Delayed Write Failed...errors?
3. You can use the SQLIOSTRESS utility to perform stress tests on disk
subsystems to simulate Microsoft SQL Server 2000 and Microsoft SQL Server
7.0 read, write, checkpoint, backup, sort, and read ahead activities.
http://support.microsoft.com/?id=231619
4. If possible, engage your hardware vendor to fully test and certify the
system.
5. When was the last time you updated disk or controller drivers? Are
they up to date?
KB article references (available at http://suport.microsoft.com):
----
--
86903 INF: SQL Server and Caching Disk Controllers
234656 Using Disk Drive Caching with SQL Server
46091 INF: Using Hard Disk Controller Caching with SQL Server
826433 Additional SQL Server Diagnostics Added to Detect Unreported I/O
231619 Use the SQLIOStress Utility to Stress a Disk Subsystem Such as
SQLServer
332023 Slow Disk Performance When Write Caching Is Enabled
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx|||Thanks for your prompt and thoughtful reply. We have already run CHKDSK on
the hard drive involved and found no errors, and one of my associates has
checked error logs to no avail. We will proceed with the more thorough check
s
you recommend.
In your proposed scenario, you hypothesize that REPAIR_ALLOW_DATA_LOSS fixed
the errors present, but would it do this without displaying any sort of
relevant message? Both times I ran REPAIR_ALLOW_DATA_LOSS, I specified WITH
ALL_ERRORMSGS, but each time the utility returned the message "CHECKDB found
0 allocation errors and 0 consistency errors in database xxxxx".
Thanks again... Steve B.
"Fany Vargas [MSFT]" wrote:
> This inconsistency is sometimes seen when there is a drive problem.
> One possible scenario is:
> * At some point in time your drive failed to read/write and this caused th
e
> data to be corrupt
> * DBCC CHECKDB found inconsistencies
> * You repaired these by running the REPAIR_ALLOW_DATA_LOSS
> * however, if any drive (or drive controller) issues are still outstanding
,
> it is certainly possible for SQL database to become corrupt again.
> 1. You want to start by checking the SQL Error logs, are there any 823
> errors in there? PRB: Error message 823 may indicate hardware problems or
> system problems - ID: 828339. This might indicate that Microsoft SQL
> Server 2000 has detected hardware or system problems when it was reading
> from or writing to database files
> 2. Check the application and system event logs. Are there any drive or
> drive controller errors? Are there any Delayed Write Failed...errors?
> 3. You can use the SQLIOSTRESS utility to perform stress tests on disk
> subsystems to simulate Microsoft SQL Server 2000 and Microsoft SQL Server
> 7.0 read, write, checkpoint, backup, sort, and read ahead activities.
> http://support.microsoft.com/?id=231619
> 4. If possible, engage your hardware vendor to fully test and certify the
> system.
> 5. When was the last time you updated disk or controller drivers? Are
> they up to date?
> KB article references (available at http://suport.microsoft.com):
> ----
--
> --
> 86903 INF: SQL Server and Caching Disk Controllers
> 234656 Using Disk Drive Caching with SQL Server
> 46091 INF: Using Hard Disk Controller Caching with SQL Server
> 826433 Additional SQL Server Diagnostics Added to Detect Unreported I/O
> 231619 Use the SQLIOStress Utility to Stress a Disk Subsystem Such as
> SQLServer
> 332023 Slow Disk Performance When Write Caching Is Enabled
>
> Fany Vargas
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> Are you secure? For information about the Strategic Technology Protection
> Program and to order your FREE Security Tool Kit, please visit
> http://www.microsoft.com/security.
> Microsoft highly recommends that users with Internet access update their
> Microsoft software to better protect against viruses and security
> vulnerabilities. The easiest way to do this is to visit the following
> websites:
> http://www.microsoft.com/protect
> http://www.microsoft.com/security/guidance/default.mspx
>|||If dbcc checkdb ( 'gfrc_004',REPAIR_ALLOW_DATA_LOSS)
WITH
ALL_ERRORMSGS
does not report any errors - it means no errors were found. If any errors
were fixed you should see a summary of what errors were fixed. Some
errors are not repairable, if you run DBCC CHECKDB (without any options)
you will see what the minimun repair level is.
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx
Tuesday, February 14, 2012
DBCC CHECKDB
It looks like I have to setup maintenance for my 24x7 SQL Server 2000
manually. Most of the relevant pages in BOL are clear enough, but DBCC
CHECKDB isn't so clear.
I would like to schedule DBCC CHECKDB for nightly execution and (so far) I
haven't seen anything that would alter DDL at night, which is the only
restriction I see. I also have no intent of actually doing a repair
initially.
Is this the right routine? Is this the right usage?
Thanks,
JayHi Jay
"Jay" wrote:
> It looks like I have to setup maintenance for my 24x7 SQL Server 2000
> manually. Most of the relevant pages in BOL are clear enough, but DBCC
> CHECKDB isn't so clear.
> I would like to schedule DBCC CHECKDB for nightly execution and (so far) I
> haven't seen anything that would alter DDL at night, which is the only
> restriction I see. I also have no intent of actually doing a repair
> initially.
> Is this the right routine? Is this the right usage?
> Thanks,
> Jay
>
You may want to check out Paul Randals blog posts on this at
https://blogs.msdn.com/sqlserverstorageengine/archive/tags/DBCC+CHECKDB+Series/default.aspx
How often you run it will depend on many factors, but I don't know of anyone
that does it nightly! If you have scheduled other DBCC commands you may be
running some checks more than once, but you may want to run the these
commands rather than DBCC CHECKDB to reduce the time/workload on your servers.
John|||After digging in BOL, I see that DBCHECK includes CHECKALLOC and CHECKTABLE
(anything else?).
Since the runtime for CHECKDB is under 3 minutes for the primary database on
the dev system, even when expanded out I don't think it's that big a deal to
just use it.
Still, if I can do everything CHECKDB does (maybe even a little more) in an
application that spreads the load out, I should at least consider it.
So, what else is DBCHECK doing?
What else SHOULD it be doing?
Thanks,
Jay
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:74F66FBF-DFBC-456C-940A-9F1808FF0F7B@.microsoft.com...
> Hi Jay
> "Jay" wrote:
>> It looks like I have to setup maintenance for my 24x7 SQL Server 2000
>> manually. Most of the relevant pages in BOL are clear enough, but DBCC
>> CHECKDB isn't so clear.
>> I would like to schedule DBCC CHECKDB for nightly execution and (so far)
>> I
>> haven't seen anything that would alter DDL at night, which is the only
>> restriction I see. I also have no intent of actually doing a repair
>> initially.
>> Is this the right routine? Is this the right usage?
>> Thanks,
>> Jay
> You may want to check out Paul Randals blog posts on this at
> https://blogs.msdn.com/sqlserverstorageengine/archive/tags/DBCC+CHECKDB+Series/default.aspx
> How often you run it will depend on many factors, but I don't know of
> anyone
> that does it nightly! If you have scheduled other DBCC commands you may be
> running some checks more than once, but you may want to run the these
> commands rather than DBCC CHECKDB to reduce the time/workload on your
> servers.
> John|||Include DBCC CHECKCATALOG as well. SQL2005 includes this in CheckDB but 2000
omitted it.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Jay" <nospam@.nospam.org> wrote in message
news:uowYuIc5HHA.2380@.TK2MSFTNGP02.phx.gbl...
> After digging in BOL, I see that DBCHECK includes CHECKALLOC and
> CHECKTABLE (anything else?).
> Since the runtime for CHECKDB is under 3 minutes for the primary database
> on the dev system, even when expanded out I don't think it's that big a
> deal to just use it.
> Still, if I can do everything CHECKDB does (maybe even a little more) in
> an application that spreads the load out, I should at least consider it.
> So, what else is DBCHECK doing?
> What else SHOULD it be doing?
> Thanks,
> Jay
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:74F66FBF-DFBC-456C-940A-9F1808FF0F7B@.microsoft.com...
>> Hi Jay
>> "Jay" wrote:
>> It looks like I have to setup maintenance for my 24x7 SQL Server 2000
>> manually. Most of the relevant pages in BOL are clear enough, but DBCC
>> CHECKDB isn't so clear.
>> I would like to schedule DBCC CHECKDB for nightly execution and (so far)
>> I
>> haven't seen anything that would alter DDL at night, which is the only
>> restriction I see. I also have no intent of actually doing a repair
>> initially.
>> Is this the right routine? Is this the right usage?
>> Thanks,
>> Jay
>> You may want to check out Paul Randals blog posts on this at
>> https://blogs.msdn.com/sqlserverstorageengine/archive/tags/DBCC+CHECKDB+Series/default.aspx
>> How often you run it will depend on many factors, but I don't know of
>> anyone
>> that does it nightly! If you have scheduled other DBCC commands you may
>> be
>> running some checks more than once, but you may want to run the these
>> commands rather than DBCC CHECKDB to reduce the time/workload on your
>> servers.
>> John
>|||Hi Jay
DBCC CHECKDB can take a long time, so as you move forward you would have to
keep an eye on the duration and workload it places on the server.
John
"Jay" wrote:
> After digging in BOL, I see that DBCHECK includes CHECKALLOC and CHECKTABLE
> (anything else?).
> Since the runtime for CHECKDB is under 3 minutes for the primary database on
> the dev system, even when expanded out I don't think it's that big a deal to
> just use it.
> Still, if I can do everything CHECKDB does (maybe even a little more) in an
> application that spreads the load out, I should at least consider it.
> So, what else is DBCHECK doing?
> What else SHOULD it be doing?
> Thanks,
> Jay
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:74F66FBF-DFBC-456C-940A-9F1808FF0F7B@.microsoft.com...
> > Hi Jay
> >
> > "Jay" wrote:
> >
> >> It looks like I have to setup maintenance for my 24x7 SQL Server 2000
> >> manually. Most of the relevant pages in BOL are clear enough, but DBCC
> >> CHECKDB isn't so clear.
> >>
> >> I would like to schedule DBCC CHECKDB for nightly execution and (so far)
> >> I
> >> haven't seen anything that would alter DDL at night, which is the only
> >> restriction I see. I also have no intent of actually doing a repair
> >> initially.
> >>
> >> Is this the right routine? Is this the right usage?
> >>
> >> Thanks,
> >> Jay
> >>
> > You may want to check out Paul Randals blog posts on this at
> > https://blogs.msdn.com/sqlserverstorageengine/archive/tags/DBCC+CHECKDB+Series/default.aspx
> >
> > How often you run it will depend on many factors, but I don't know of
> > anyone
> > that does it nightly! If you have scheduled other DBCC commands you may be
> > running some checks more than once, but you may want to run the these
> > commands rather than DBCC CHECKDB to reduce the time/workload on your
> > servers.
> >
> > John
>
>
manually. Most of the relevant pages in BOL are clear enough, but DBCC
CHECKDB isn't so clear.
I would like to schedule DBCC CHECKDB for nightly execution and (so far) I
haven't seen anything that would alter DDL at night, which is the only
restriction I see. I also have no intent of actually doing a repair
initially.
Is this the right routine? Is this the right usage?
Thanks,
JayHi Jay
"Jay" wrote:
> It looks like I have to setup maintenance for my 24x7 SQL Server 2000
> manually. Most of the relevant pages in BOL are clear enough, but DBCC
> CHECKDB isn't so clear.
> I would like to schedule DBCC CHECKDB for nightly execution and (so far) I
> haven't seen anything that would alter DDL at night, which is the only
> restriction I see. I also have no intent of actually doing a repair
> initially.
> Is this the right routine? Is this the right usage?
> Thanks,
> Jay
>
You may want to check out Paul Randals blog posts on this at
https://blogs.msdn.com/sqlserverstorageengine/archive/tags/DBCC+CHECKDB+Series/default.aspx
How often you run it will depend on many factors, but I don't know of anyone
that does it nightly! If you have scheduled other DBCC commands you may be
running some checks more than once, but you may want to run the these
commands rather than DBCC CHECKDB to reduce the time/workload on your servers.
John|||After digging in BOL, I see that DBCHECK includes CHECKALLOC and CHECKTABLE
(anything else?).
Since the runtime for CHECKDB is under 3 minutes for the primary database on
the dev system, even when expanded out I don't think it's that big a deal to
just use it.
Still, if I can do everything CHECKDB does (maybe even a little more) in an
application that spreads the load out, I should at least consider it.
So, what else is DBCHECK doing?
What else SHOULD it be doing?
Thanks,
Jay
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:74F66FBF-DFBC-456C-940A-9F1808FF0F7B@.microsoft.com...
> Hi Jay
> "Jay" wrote:
>> It looks like I have to setup maintenance for my 24x7 SQL Server 2000
>> manually. Most of the relevant pages in BOL are clear enough, but DBCC
>> CHECKDB isn't so clear.
>> I would like to schedule DBCC CHECKDB for nightly execution and (so far)
>> I
>> haven't seen anything that would alter DDL at night, which is the only
>> restriction I see. I also have no intent of actually doing a repair
>> initially.
>> Is this the right routine? Is this the right usage?
>> Thanks,
>> Jay
> You may want to check out Paul Randals blog posts on this at
> https://blogs.msdn.com/sqlserverstorageengine/archive/tags/DBCC+CHECKDB+Series/default.aspx
> How often you run it will depend on many factors, but I don't know of
> anyone
> that does it nightly! If you have scheduled other DBCC commands you may be
> running some checks more than once, but you may want to run the these
> commands rather than DBCC CHECKDB to reduce the time/workload on your
> servers.
> John|||Include DBCC CHECKCATALOG as well. SQL2005 includes this in CheckDB but 2000
omitted it.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Jay" <nospam@.nospam.org> wrote in message
news:uowYuIc5HHA.2380@.TK2MSFTNGP02.phx.gbl...
> After digging in BOL, I see that DBCHECK includes CHECKALLOC and
> CHECKTABLE (anything else?).
> Since the runtime for CHECKDB is under 3 minutes for the primary database
> on the dev system, even when expanded out I don't think it's that big a
> deal to just use it.
> Still, if I can do everything CHECKDB does (maybe even a little more) in
> an application that spreads the load out, I should at least consider it.
> So, what else is DBCHECK doing?
> What else SHOULD it be doing?
> Thanks,
> Jay
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:74F66FBF-DFBC-456C-940A-9F1808FF0F7B@.microsoft.com...
>> Hi Jay
>> "Jay" wrote:
>> It looks like I have to setup maintenance for my 24x7 SQL Server 2000
>> manually. Most of the relevant pages in BOL are clear enough, but DBCC
>> CHECKDB isn't so clear.
>> I would like to schedule DBCC CHECKDB for nightly execution and (so far)
>> I
>> haven't seen anything that would alter DDL at night, which is the only
>> restriction I see. I also have no intent of actually doing a repair
>> initially.
>> Is this the right routine? Is this the right usage?
>> Thanks,
>> Jay
>> You may want to check out Paul Randals blog posts on this at
>> https://blogs.msdn.com/sqlserverstorageengine/archive/tags/DBCC+CHECKDB+Series/default.aspx
>> How often you run it will depend on many factors, but I don't know of
>> anyone
>> that does it nightly! If you have scheduled other DBCC commands you may
>> be
>> running some checks more than once, but you may want to run the these
>> commands rather than DBCC CHECKDB to reduce the time/workload on your
>> servers.
>> John
>|||Hi Jay
DBCC CHECKDB can take a long time, so as you move forward you would have to
keep an eye on the duration and workload it places on the server.
John
"Jay" wrote:
> After digging in BOL, I see that DBCHECK includes CHECKALLOC and CHECKTABLE
> (anything else?).
> Since the runtime for CHECKDB is under 3 minutes for the primary database on
> the dev system, even when expanded out I don't think it's that big a deal to
> just use it.
> Still, if I can do everything CHECKDB does (maybe even a little more) in an
> application that spreads the load out, I should at least consider it.
> So, what else is DBCHECK doing?
> What else SHOULD it be doing?
> Thanks,
> Jay
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:74F66FBF-DFBC-456C-940A-9F1808FF0F7B@.microsoft.com...
> > Hi Jay
> >
> > "Jay" wrote:
> >
> >> It looks like I have to setup maintenance for my 24x7 SQL Server 2000
> >> manually. Most of the relevant pages in BOL are clear enough, but DBCC
> >> CHECKDB isn't so clear.
> >>
> >> I would like to schedule DBCC CHECKDB for nightly execution and (so far)
> >> I
> >> haven't seen anything that would alter DDL at night, which is the only
> >> restriction I see. I also have no intent of actually doing a repair
> >> initially.
> >>
> >> Is this the right routine? Is this the right usage?
> >>
> >> Thanks,
> >> Jay
> >>
> > You may want to check out Paul Randals blog posts on this at
> > https://blogs.msdn.com/sqlserverstorageengine/archive/tags/DBCC+CHECKDB+Series/default.aspx
> >
> > How often you run it will depend on many factors, but I don't know of
> > anyone
> > that does it nightly! If you have scheduled other DBCC commands you may be
> > running some checks more than once, but you may want to run the these
> > commands rather than DBCC CHECKDB to reduce the time/workload on your
> > servers.
> >
> > John
>
>
Subscribe to:
Posts (Atom)