Getting this "Error: 5180, Severity: 22, " in SQL Error log

Discussion:

(too old to reply)

Neeraj

2008-05-21 01:33:27 UTC

Hi All,
We are running SQL Server 2000 SP4 with 2040 patch. We have got the
following error twice in two days. It gives a different "file ID" every time.
I have run the checkdb on tempdb and didn't get any issues there. Tempdb
doesn't even have the file with ID 11. The server has only one other User
database which is pretty huge and does have a file with ID 11. I am afraid
that this error is not a sign of any corruption on Prod user DB. Running a
dbcc checkdb on Prod user db would be a big deal for us since it will affect
the production application. Any suggestions -

2008-05-20 16:23:04.05 spid839 Error: 5180, Severity: 22, State: 1

0
2008-05-20 16:23:04.05 spid839 Could not open FCB for invalid file ID 11
in database 'tempdb'..

0
2008-05-20 16:44:11.03 spid3096 DBCC CHECKDB (tempdb) executed by
PARAMOUNT\nagpalne found 0 errors and repaired 0 errors. Elapsed time: 0
hours 0 minutes 6 seconds.
0

Mike Walsh

2008-05-21 15:33:20 UTC

Permalink

I am concerned that you may have corruption in a file or you may have disk
issues. I would highly suggest running a DBCC CHECKDB on all databases. This
is something that even in a busy production environment you need to find the
time to do. At the absolute worst, I suggest you backup your user databases,
restore them someplace else and run the check. See if you see any issues.

I would also check your I/O subsystem, look at your event log/application
log on the Windows box and see if you are experiencing any hardware or
system issues.

If you don't run the checkdb and investigate this further you will have a
lot bigger hit than some performance implications during the execution of
your checkdb as you could risk data loss and a serious downtime as you
scramble to recover.

I would also say that once you get past this, you work out a schedule where
you can run a checkdb (which in SQL Server 2000 is an operation that can be
run with users in the system, it can affect performance but generally
finding corruption early is well worth that overhead).

Thanks,

Mike Walsh

Post by Neeraj
Hi All,
We are running SQL Server 2000 SP4 with 2040 patch. We have got the
following error twice in two days. It gives a different "file ID" every time.
I have run the checkdb on tempdb and didn't get any issues there. Tempdb
doesn't even have the file with ID 11. The server has only one other User
database which is pretty huge and does have a file with ID 11. I am afraid
that this error is not a sign of any corruption on Prod user DB. Running a
dbcc checkdb on Prod user db would be a big deal for us since it will affect
the production application. Any suggestions -
2008-05-20 16:23:04.05 spid839 Error: 5180, Severity: 22, State: 1
0
2008-05-20 16:23:04.05 spid839 Could not open FCB for invalid file ID 11
in database 'tempdb'..
0
2008-05-20 16:44:11.03 spid3096 DBCC CHECKDB (tempdb) executed by
PARAMOUNT\nagpalne found 0 errors and repaired 0 errors. Elapsed time: 0
hours 0 minutes 6 seconds.
0

Neeraj

2008-05-21 15:56:01 UTC

Permalink

Mike, thanks a lot for your response. On a daily basis we copy the database
to a different server and Run a check table on a set of different tables in
the copy database. I have not seen any errors in that. I am concerned about
the situation as well and plan to run check table on all tables by splitting
them into different groups.

Post by Mike Walsh
I am concerned that you may have corruption in a file or you may have disk
issues. I would highly suggest running a DBCC CHECKDB on all databases. This
is something that even in a busy production environment you need to find the
time to do. At the absolute worst, I suggest you backup your user databases,
restore them someplace else and run the check. See if you see any issues.
I would also check your I/O subsystem, look at your event log/application
log on the Windows box and see if you are experiencing any hardware or
system issues.
If you don't run the checkdb and investigate this further you will have a
lot bigger hit than some performance implications during the execution of
your checkdb as you could risk data loss and a serious downtime as you
scramble to recover.
I would also say that once you get past this, you work out a schedule where
you can run a checkdb (which in SQL Server 2000 is an operation that can be
run with users in the system, it can affect performance but generally
finding corruption early is well worth that overhead).
Thanks,
Mike Walsh

Mike Walsh

2008-05-21 16:14:07 UTC

Permalink

Are you running the entire DBCC CHECKDB? Have you checked your event viewer
for application events/system events that indicate any issues with your
disks?

Can you describe your setup also? (Clustered, Not Clustered, Hardware, Disk
system, virus scan running on the server, other uses of SQL Server, etc)

Post by Neeraj
Mike, thanks a lot for your response. On a daily basis we copy the database
to a different server and Run a check table on a set of different tables in
the copy database. I have not seen any errors in that. I am concerned about
the situation as well and plan to run check table on all tables by splitting
them into different groups.

Neeraj

2008-05-22 19:06:01 UTC

Permalink

We are not running the full check db.We overwrite the copy database every 24
hours and the checkdb takes more than 24 hours to finish and that is why we
are running check table on a different set of tables every day to finish
check table on all tables in one week. The server has 32 CPUs and 32 GB RAM.
The database is around 6TB in size. The server is on Unisys ES7000 and SAN is
IBM Shark. I don't see any errors in event viewer. Asked my SAN administrator
and he says everything on the SAN is good and they are not seeing any alerts.

Post by Mike Walsh
Are you running the entire DBCC CHECKDB? Have you checked your event viewer
for application events/system events that indicate any issues with your
disks?
Can you describe your setup also? (Clustered, Not Clustered, Hardware, Disk
system, virus scan running on the server, other uses of SQL Server, etc)

Andrew J. Kelly

2008-05-23 00:30:10 UTC

Permalink

There are other checks than just CheckTable done by CheckDB that you may
want to consider running as well such as:
checkalloc
checkconstriants
CheckCatalog

I would highly recommend you look at upgrading to 2005 or 2008 sooner rather
than later. CheckDB in 2005 has a fast option that will allow you to get
more checks done faster along with a whole host of features to better
support a larger db such as yours. And of course there is always the fact
that support is running out for 2000 as well. But in any case most of those
errors I have seen in 2000 was related to bugs. The funny thing is that I
think most were supposed to be fixed by SP4. Here is a KB that outlines the
most common issues with that error.
http://support.microsoft.com/default.aspx/kb/815183

Are you using Read Uncommitted Isolation level or NOLOCK hints? If so they
are known to cause these errors at times as well.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors

Post by Neeraj
We are not running the full check db.We overwrite the copy database every 24
hours and the checkdb takes more than 24 hours to finish and that is why we
are running check table on a different set of tables every day to finish
check table on all tables in one week. The server has 32 CPUs and 32 GB RAM.
The database is around 6TB in size. The server is on Unisys ES7000 and SAN is
IBM Shark. I don't see any errors in event viewer. Asked my SAN administrator
and he says everything on the SAN is good and they are not seeing any alerts.

Post by Neeraj
Mike, thanks a lot for your response. On a daily basis we copy the database
to a different server and Run a check table on a set of different
tables
in
the copy database. I have not seen any errors in that. I am concerned about
the situation as well and plan to run check table on all tables by splitting
them into different groups.

Post by Mike Walsh
I am concerned that you may have corruption in a file or you may have disk
issues. I would highly suggest running a DBCC CHECKDB on all
databases.
This
is something that even in a busy production environment you need to
find
the
time to do. At the absolute worst, I suggest you backup your user databases,
restore them someplace else and run the check. See if you see any issues.
I would also check your I/O subsystem, look at your event
log/application
log on the Windows box and see if you are experiencing any hardware or
system issues.
If you don't run the checkdb and investigate this further you will have a
lot bigger hit than some performance implications during the execution of
your checkdb as you could risk data loss and a serious downtime as you
scramble to recover.
I would also say that once you get past this, you work out a schedule where
you can run a checkdb (which in SQL Server 2000 is an operation that
can
be
run with users in the system, it can affect performance but generally
finding corruption early is well worth that overhead).
Thanks,
Mike Walsh

Post by Neeraj
Hi All,
We are running SQL Server 2000 SP4 with 2040 patch. We have
got
the
following error twice in two days. It gives a different "file ID"
every
time.
I have run the checkdb on tempdb and didn't get any issues there. Tempdb
doesn't even have the file with ID 11. The server has only one other User
database which is pretty huge and does have a file with ID 11. I am afraid
that this error is not a sign of any corruption on Prod user DB. Running a
dbcc checkdb on Prod user db would be a big deal for us since it
will
affect
the production application. Any suggestions -
2008-05-20 16:23:04.05 spid839 Error: 5180, Severity: 22, State: 1
0
2008-05-20 16:23:04.05 spid839 Could not open FCB for invalid file
ID
11
in database 'tempdb'..
0
2008-05-20 16:44:11.03 spid3096 DBCC CHECKDB (tempdb) executed by
PARAMOUNT\nagpalne found 0 errors and repaired 0 errors. Elapsed
0
hours 0 minutes 6 seconds.
0

Neeraj

2008-05-23 21:29:00 UTC

Permalink

Thanks Andrew, yes that was my plan. I was planning on running checkalloc and
catalog, will run the checkcontraints also. Thanks again for your suggestion.

Post by Andrew J. Kelly
There are other checks than just CheckTable done by CheckDB that you may
checkalloc
checkconstriants
CheckCatalog
I would highly recommend you look at upgrading to 2005 or 2008 sooner rather
than later. CheckDB in 2005 has a fast option that will allow you to get
more checks done faster along with a whole host of features to better
support a larger db such as yours. And of course there is always the fact
that support is running out for 2000 as well. But in any case most of those
errors I have seen in 2000 was related to bugs. The funny thing is that I
think most were supposed to be fixed by SP4. Here is a KB that outlines the
most common issues with that error.
http://support.microsoft.com/default.aspx/kb/815183
Are you using Read Uncommitted Isolation level or NOLOCK hints? If so they
are known to cause these errors at times as well.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors

Post by Neeraj
Mike, thanks a lot for your response. On a daily basis we copy the database
to a different server and Run a check table on a set of different
tables
in
the copy database. I have not seen any errors in that. I am concerned about
the situation as well and plan to run check table on all tables by splitting
them into different groups.

Post by Mike Walsh
I am concerned that you may have corruption in a file or you may have disk
issues. I would highly suggest running a DBCC CHECKDB on all
databases.
This
is something that even in a busy production environment you need to
find
the
time to do. At the absolute worst, I suggest you backup your user databases,
restore them someplace else and run the check. See if you see any issues.
I would also check your I/O subsystem, look at your event log/application
log on the Windows box and see if you are experiencing any hardware or
system issues.
If you don't run the checkdb and investigate this further you will have a
lot bigger hit than some performance implications during the execution of
your checkdb as you could risk data loss and a serious downtime as you
scramble to recover.
I would also say that once you get past this, you work out a schedule where
you can run a checkdb (which in SQL Server 2000 is an operation that
can
be
run with users in the system, it can affect performance but generally
finding corruption early is well worth that overhead).
Thanks,
Mike Walsh

Post by Neeraj
Hi All,
We are running SQL Server 2000 SP4 with 2040 patch. We have
got
the
following error twice in two days. It gives a different "file ID"
every
time.
I have run the checkdb on tempdb and didn't get any issues there. Tempdb
doesn't even have the file with ID 11. The server has only one other User
database which is pretty huge and does have a file with ID 11. I am afraid
that this error is not a sign of any corruption on Prod user DB. Running a
dbcc checkdb on Prod user db would be a big deal for us since it
will
affect
the production application. Any suggestions -
2008-05-20 16:23:04.05 spid839 Error: 5180, Severity: 22, State: 1
0
2008-05-20 16:23:04.05 spid839 Could not open FCB for invalid file
ID
11
in database 'tempdb'..
0
2008-05-20 16:44:11.03 spid3096 DBCC CHECKDB (tempdb) executed by
PARAMOUNT\nagpalne found 0 errors and repaired 0 errors. Elapsed
0
hours 0 minutes 6 seconds.
0