dbcc show_statistics wrong output

Has anyone ever come across the rows column in dbcc show_statistics not
reporting the right number of rows( I mean way off : Actual count maybe 500
whereas the rows column indicates 50000 ) even after stats are being updated
? Could that be a bug ? Using SQL 2K and SP2 with Slammer HF ofcourseThey may well not be accurate. You need to run DBCC UPDATEUSAGE or UPDATE
STATISTICS WITH FULLSCAN to get them right. See BOL for details
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:uaO6TeduDHA.560@.TK2MSFTNGP11.phx.gbl...
Has anyone ever come across the rows column in dbcc show_statistics not
reporting the right number of rows( I mean way off : Actual count maybe 500
whereas the rows column indicates 50000 ) even after stats are being updated
? Could that be a bug ? Using SQL 2K and SP2 with Slammer HF ofcourse

DBCC DBREINDEX Status

I have inherited a SQL SERVER 2000 project from a colleague and we have a monthly SQL SERVER job that reindexes all the indexes in a reporting table (it contains archived records up to 1 year old, averaging close to 15 million rows). This table receives fresh data from another table in a different database every night (close to 30000 rows).

Since there is a monthly job that rebuilds all the indexes, there will be a single day every month when the rebuilding of indexes will clash with insertion of those new rows. I haven't been able to find a specific TSQL construct that I can use in my INSERT stored procedure to see if the table is currently locked for rebuilding indexes before trying to insert the rows. Specifically, I wouldn't insert the rows that night because the table is being reindexed.

Please let me know if there is such a facility in Server 2000 to find out the current indexing status. Also, I wouldn't mind alternate solutions to the above problem.

Thanks in advance!
Your ETL Job could check to see if the re-indexing Job is running, and if so, have the ETL job take a pass for an hour [ WAITFOR DELAY '001:00:00' ], then check again, etc.|||

Sorry to ask the obvious, but how to check if the job is running? Specifically, from within SQL Server and outside SQL Server? I guess at this point in time I am just curious to find out both alternatives.

Thanks for the reply!

|||

With SQL 2005, you could use sp_helpjobactivity.

However, with SQL 2000, it is a bit more trouble. You can check the msdb.dbo.sysjobhistory, column run_status, looking for run_status = 4 (in progress).

|||

Great tip!

OK, here is a more reliability-related question... I have never dealt with the SQL Server Job Agent (believe me, I have complete faith in SQL Server 2005, but this is 2000's job agent), but I am hoping to find out how reliable the Agent is in 2000? I only bring up this question because you mentioned in your previous post that "with SQL Server 2000, it is a bit more trouble." Of course looking at the schema of that table (sysjobhistory), this doesn't seem to be too hard!

Thanks again for the quick replies, Arnie!

|||

My experience with SQL 2000 SQL Agent is that it is very reliable.

However, sometimes the JobHistory table seems to have some latency. If a Job 'should' be running, and the run_status <> 4, I will also cross check a the start_time against the end_time. Keep in mind that an entry is added to the JobHistory table when the Job starts, and if the end_time is NULL, then it has not finished.

|||

Alternatively you could use the stored procedure 'sp_help_job' to determine the job's status.

See here for more info:

http://www.databasejournal.com/features/mssql/article.php/10894_3491201_2

...or here (note that this link refers to SQL Server 7 but the syntax should still apply to SQL Server 2000):

http://doc.ddart.net/mssql/sql70/sp_help_27.htm

Chris

|||Thanks, Chris!

DBCC CHECKDB Reporting Errors in - SQL Server 2005

HI,
I am getting this ttype of errors in SQL Server 2005, This table have xml
column.
Msg 8964, Sev 16, State 1, Line 1 : Table error: Object ID 304720138, index
ID 1, partition ID 72057594055557120, alloc unit ID 72057594058702848 (type
LOB data). The off-row data node at page (4:26), slot 0, text ID 19136512 is
not referenced. [SQLSTATE 42000]
Please give some help on this , what will be the route cause of this problem?
how to resolve it.Hi
You may want to check out:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_0prl.asp
You may also want to check that this has not been re-introduced
http://support.microsoft.com/default.aspx?scid=kb;en-us;281287
Try dropping and re-creating the index. If the error persists then you
should log it with PSS.
John
"Srikanth" wrote:
> HI,
> I am getting this ttype of errors in SQL Server 2005, This table have xml
> column.
> Msg 8964, Sev 16, State 1, Line 1 : Table error: Object ID 304720138, index
> ID 1, partition ID 72057594055557120, alloc unit ID 72057594058702848 (type
> LOB data). The off-row data node at page (4:26), slot 0, text ID 19136512 is
> not referenced. [SQLSTATE 42000]
> Please give some help on this , what will be the route cause of this problem?
> how to resolve it.
>
>

DBCC CHECKDB Reporting Errors in - SQL Server 2005

HI,
I am getting this ttype of errors in SQL Server 2005, This table have xml
column.
Msg 8964, Sev 16, State 1, Line 1 : Table error: Object ID 304720138, index
ID 1, partition ID 72057594055557120, alloc unit ID 72057594058702848 (type
LOB data). The off-row data node at page (4:26), slot 0, text ID 19136512 is
not referenced. [SQLSTATE 42000]
Please give some help on this , what will be the route cause of this problem?
how to resolve it.
Hi
You may want to check out:
http://msdn.microsoft.com/library/de...err_2_0prl.asp
You may also want to check that this has not been re-introduced
http://support.microsoft.com/default...b;en-us;281287
Try dropping and re-creating the index. If the error persists then you
should log it with PSS.
John
"Srikanth" wrote:

> HI,
> I am getting this ttype of errors in SQL Server 2005, This table have xml
> column.
> Msg 8964, Sev 16, State 1, Line 1 : Table error: Object ID 304720138, index
> ID 1, partition ID 72057594055557120, alloc unit ID 72057594058702848 (type
> LOB data). The off-row data node at page (4:26), slot 0, text ID 19136512 is
> not referenced. [SQLSTATE 42000]
> Please give some help on this , what will be the route cause of this problem?
> how to resolve it.
>
>

DBCC CHECKDB Reporting Errors in - SQL Server 2005

HI,
I am getting this ttype of errors in SQL Server 2005, This table have xml
column.
Msg 8964, Sev 16, State 1, Line 1 : Table error: Object ID 304720138, index
ID 1, partition ID 72057594055557120, alloc unit ID 72057594058702848 (type
LOB data). The off-row data node at page (4:26), slot 0, text ID 19136512 is
not referenced. [SQLSTATE 42000]
Please give some help on this , what will be the route cause of this problem
?
how to resolve it.Hi
You may want to check out:
http://msdn.microsoft.com/library/d...serr_2_0prl.asp
You may also want to check that this has not been re-introduced
http://support.microsoft.com/defaul...kb;en-us;281287
Try dropping and re-creating the index. If the error persists then you
should log it with PSS.
John
"Srikanth" wrote:

> HI,
> I am getting this ttype of errors in SQL Server 2005, This table have xml
> column.
> Msg 8964, Sev 16, State 1, Line 1 : Table error: Object ID 304720138, inde
x
> ID 1, partition ID 72057594055557120, alloc unit ID 72057594058702848 (typ
e
> LOB data). The off-row data node at page (4:26), slot 0, text ID 19136512
is
> not referenced. [SQLSTATE 42000]
> Please give some help on this , what will be the route cause of this probl
em?
> how to resolve it.
>
>

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

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

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