MSG 605 - Server having problems with fetching the logical pages

Hi,
I'm running SQL 2000 and server quite often (3 times within the last week)
fails on insert operation with the messages like:
"Attempt to fetch logical page (1:202685) in database 'tempdb' belongs to
object '-948063835' not to object #tmp
Connection Broken"
Similar messages were for the tables in the completely different databases.
Does not look like this is directly related to the table's size.
ThanksHi
Looks like corruption. Either your RAM or disk could ber causing this.
Run DBCC CHECKDB againt all your DB's on the server and see what the output
is.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"alex" wrote:
> Hi,
> I'm running SQL 2000 and server quite often (3 times within the last week)
> fails on insert operation with the messages like:
> "Attempt to fetch logical page (1:202685) in database 'tempdb' belongs to
> object '-948063835' not to object #tmp
> Connection Broken"
> Similar messages were for the tables in the completely different databases.
> Does not look like this is directly related to the table's size.
> Thanks
>|||Also check your backups (restore to a different sql server, run dbcc checkdb
on those). Find a backup that does not contain the corruption.
You may lose data.
If DBCC reports the minimal repair level is "repair_allow_data_loss" it's
not kidding.
If you run that, be prepared to lose some data. It might be a row, a page,
whole tables. There's really no telling.
Going back to a known good state is often a better alternative. At least
you know what data you lost.
:D
Donna Lambert
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> Looks like corruption. Either your RAM or disk could ber causing this.
> Run DBCC CHECKDB againt all your DB's on the server and see what the output
> is.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "alex" wrote:
> > Hi,
> > I'm running SQL 2000 and server quite often (3 times within the last week)
> > fails on insert operation with the messages like:
> >
> > "Attempt to fetch logical page (1:202685) in database 'tempdb' belongs to
> > object '-948063835' not to object #tmp
> >
> > Connection Broken"
> >
> > Similar messages were for the tables in the completely different databases.
> >
> > Does not look like this is directly related to the table's size.
> >
> > Thanks
> >
> >|||Thanks. Did that and got:
....
CHECKDB found 0 allocation errors and 0 consistency errors in database
'tempdb'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
Looks like database itself is OK. Can the problem be a result of some
application's
activities like the following scenario:
main stored procedure calls, withing a cycle, underlying stored procedure
and this
procedure contains the following:
create table #tmp(....)
....
drop table #tmp
It looks like after few repetitions of this scenario (number of the
iterations varies)
breakdown occurs. After replacement of the temp table with a regular one,
situation seems to be remedied.
Can it be that tempdb may have problems with a repeated re-creation of a
dropped temp. table within a single session?
Thanks
"Donna Lambert" wrote:
> Also check your backups (restore to a different sql server, run dbcc checkdb
> on those). Find a backup that does not contain the corruption.
> You may lose data.
> If DBCC reports the minimal repair level is "repair_allow_data_loss" it's
> not kidding.
> If you run that, be prepared to lose some data. It might be a row, a page,
> whole tables. There's really no telling.
> Going back to a known good state is often a better alternative. At least
> you know what data you lost.
> :D
> Donna Lambert
>
> "Mike Epprecht (SQL MVP)" wrote:
> > Hi
> >
> > Looks like corruption. Either your RAM or disk could ber causing this.
> >
> > Run DBCC CHECKDB againt all your DB's on the server and see what the output
> > is.
> >
> > Regards
> > --
> > Mike Epprecht, Microsoft SQL Server MVP
> > Zurich, Switzerland
> >
> > MVP Program: http://www.microsoft.com/mvp
> >
> > Blog: http://www.msmvps.com/epprecht/
> >
> >
> >
> > "alex" wrote:
> >
> > > Hi,
> > > I'm running SQL 2000 and server quite often (3 times within the last week)
> > > fails on insert operation with the messages like:
> > >
> > > "Attempt to fetch logical page (1:202685) in database 'tempdb' belongs to
> > > object '-948063835' not to object #tmp
> > >
> > > Connection Broken"
> > >
> > > Similar messages were for the tables in the completely different databases.
> > >
> > > Does not look like this is directly related to the table's size.
> > >
> > > Thanks
> > >
> > >|||> Can the problem be a result of some
> application's
> activities like the following scenario:
Basically, no. No TSQL code should be able to corrupt a database. If you can find such code that
reproduces, you have found a bug in SQL Server. You should investigate for hardware errors. See
general recommendations at http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp. Also,
remember that tempdb is re-created at each startup...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"alex" <alex@.discussions.microsoft.com> wrote in message
news:8D8B81BF-1C2A-4088-ACAE-1609A0FC5223@.microsoft.com...
> Thanks. Did that and got:
> ....
> CHECKDB found 0 allocation errors and 0 consistency errors in database
> 'tempdb'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> Looks like database itself is OK. Can the problem be a result of some
> application's
> activities like the following scenario:
> main stored procedure calls, withing a cycle, underlying stored procedure
> and this
> procedure contains the following:
> create table #tmp(....)
> ....
> drop table #tmp
> It looks like after few repetitions of this scenario (number of the
> iterations varies)
> breakdown occurs. After replacement of the temp table with a regular one,
> situation seems to be remedied.
> Can it be that tempdb may have problems with a repeated re-creation of a
> dropped temp. table within a single session?
> Thanks
> "Donna Lambert" wrote:
>> Also check your backups (restore to a different sql server, run dbcc checkdb
>> on those). Find a backup that does not contain the corruption.
>> You may lose data.
>> If DBCC reports the minimal repair level is "repair_allow_data_loss" it's
>> not kidding.
>> If you run that, be prepared to lose some data. It might be a row, a page,
>> whole tables. There's really no telling.
>> Going back to a known good state is often a better alternative. At least
>> you know what data you lost.
>> :D
>> Donna Lambert
>>
>> "Mike Epprecht (SQL MVP)" wrote:
>> > Hi
>> >
>> > Looks like corruption. Either your RAM or disk could ber causing this.
>> >
>> > Run DBCC CHECKDB againt all your DB's on the server and see what the output
>> > is.
>> >
>> > Regards
>> > --
>> > Mike Epprecht, Microsoft SQL Server MVP
>> > Zurich, Switzerland
>> >
>> > MVP Program: http://www.microsoft.com/mvp
>> >
>> > Blog: http://www.msmvps.com/epprecht/
>> >
>> >
>> >
>> > "alex" wrote:
>> >
>> > > Hi,
>> > > I'm running SQL 2000 and server quite often (3 times within the last week)
>> > > fails on insert operation with the messages like:
>> > >
>> > > "Attempt to fetch logical page (1:202685) in database 'tempdb' belongs to
>> > > object '-948063835' not to object #tmp
>> > >
>> > > Connection Broken"
>> > >
>> > > Similar messages were for the tables in the completely different databases.
>> > >
>> > > Does not look like this is directly related to the table's size.
>> > >
>> > > Thanks
>> > >
>> > >|||Thanks but I did not say that DB was corrupted: DBCC CHECKDATABASE indicated
that there are no problems.
Is corruption the only reason for getting Msg 605?
"Tibor Karaszi" wrote:
> > Can the problem be a result of some
> > application's
> > activities like the following scenario:
> Basically, no. No TSQL code should be able to corrupt a database. If you can find such code that
> reproduces, you have found a bug in SQL Server. You should investigate for hardware errors. See
> general recommendations at http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp. Also,
> remember that tempdb is re-created at each startup...
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "alex" <alex@.discussions.microsoft.com> wrote in message
> news:8D8B81BF-1C2A-4088-ACAE-1609A0FC5223@.microsoft.com...
> > Thanks. Did that and got:
> > ....
> > CHECKDB found 0 allocation errors and 0 consistency errors in database
> > 'tempdb'.
> > DBCC execution completed. If DBCC printed error messages, contact your
> > system administrator.
> >
> > Looks like database itself is OK. Can the problem be a result of some
> > application's
> > activities like the following scenario:
> >
> > main stored procedure calls, withing a cycle, underlying stored procedure
> > and this
> > procedure contains the following:
> >
> > create table #tmp(....)
> > ....
> > drop table #tmp
> >
> > It looks like after few repetitions of this scenario (number of the
> > iterations varies)
> > breakdown occurs. After replacement of the temp table with a regular one,
> > situation seems to be remedied.
> >
> > Can it be that tempdb may have problems with a repeated re-creation of a
> > dropped temp. table within a single session?
> >
> > Thanks
> >
> > "Donna Lambert" wrote:
> >
> >> Also check your backups (restore to a different sql server, run dbcc checkdb
> >> on those). Find a backup that does not contain the corruption.
> >> You may lose data.
> >> If DBCC reports the minimal repair level is "repair_allow_data_loss" it's
> >> not kidding.
> >> If you run that, be prepared to lose some data. It might be a row, a page,
> >> whole tables. There's really no telling.
> >> Going back to a known good state is often a better alternative. At least
> >> you know what data you lost.
> >> :D
> >> Donna Lambert
> >>
> >>
> >> "Mike Epprecht (SQL MVP)" wrote:
> >>
> >> > Hi
> >> >
> >> > Looks like corruption. Either your RAM or disk could ber causing this.
> >> >
> >> > Run DBCC CHECKDB againt all your DB's on the server and see what the output
> >> > is.
> >> >
> >> > Regards
> >> > --
> >> > Mike Epprecht, Microsoft SQL Server MVP
> >> > Zurich, Switzerland
> >> >
> >> > MVP Program: http://www.microsoft.com/mvp
> >> >
> >> > Blog: http://www.msmvps.com/epprecht/
> >> >
> >> >
> >> >
> >> > "alex" wrote:
> >> >
> >> > > Hi,
> >> > > I'm running SQL 2000 and server quite often (3 times within the last week)
> >> > > fails on insert operation with the messages like:
> >> > >
> >> > > "Attempt to fetch logical page (1:202685) in database 'tempdb' belongs to
> >> > > object '-948063835' not to object #tmp
> >> > >
> >> > > Connection Broken"
> >> > >
> >> > > Similar messages were for the tables in the completely different databases.
> >> > >
> >> > > Does not look like this is directly related to the table's size.
> >> > >
> >> > > Thanks
> >> > >
> >> > >
>|||Probably the corruption disappeared since objects are created and dropped all the time in tempdb.
Also, you possibly re-started SQL server in between so tempdb was rebuilt. However, you have had a
corruption, and that it something you should investigate further.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"alex" <alex@.discussions.microsoft.com> wrote in message
news:E28034E7-9F14-46EB-B491-CB690F52E0D0@.microsoft.com...
> Thanks but I did not say that DB was corrupted: DBCC CHECKDATABASE indicated
> that there are no problems.
> Is corruption the only reason for getting Msg 605?
> "Tibor Karaszi" wrote:
>> > Can the problem be a result of some
>> > application's
>> > activities like the following scenario:
>> Basically, no. No TSQL code should be able to corrupt a database. If you can find such code that
>> reproduces, you have found a bug in SQL Server. You should investigate for hardware errors. See
>> general recommendations at http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp. Also,
>> remember that tempdb is re-created at each startup...
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "alex" <alex@.discussions.microsoft.com> wrote in message
>> news:8D8B81BF-1C2A-4088-ACAE-1609A0FC5223@.microsoft.com...
>> > Thanks. Did that and got:
>> > ....
>> > CHECKDB found 0 allocation errors and 0 consistency errors in database
>> > 'tempdb'.
>> > DBCC execution completed. If DBCC printed error messages, contact your
>> > system administrator.
>> >
>> > Looks like database itself is OK. Can the problem be a result of some
>> > application's
>> > activities like the following scenario:
>> >
>> > main stored procedure calls, withing a cycle, underlying stored procedure
>> > and this
>> > procedure contains the following:
>> >
>> > create table #tmp(....)
>> > ....
>> > drop table #tmp
>> >
>> > It looks like after few repetitions of this scenario (number of the
>> > iterations varies)
>> > breakdown occurs. After replacement of the temp table with a regular one,
>> > situation seems to be remedied.
>> >
>> > Can it be that tempdb may have problems with a repeated re-creation of a
>> > dropped temp. table within a single session?
>> >
>> > Thanks
>> >
>> > "Donna Lambert" wrote:
>> >
>> >> Also check your backups (restore to a different sql server, run dbcc checkdb
>> >> on those). Find a backup that does not contain the corruption.
>> >> You may lose data.
>> >> If DBCC reports the minimal repair level is "repair_allow_data_loss" it's
>> >> not kidding.
>> >> If you run that, be prepared to lose some data. It might be a row, a page,
>> >> whole tables. There's really no telling.
>> >> Going back to a known good state is often a better alternative. At least
>> >> you know what data you lost.
>> >> :D
>> >> Donna Lambert
>> >>
>> >>
>> >> "Mike Epprecht (SQL MVP)" wrote:
>> >>
>> >> > Hi
>> >> >
>> >> > Looks like corruption. Either your RAM or disk could ber causing this.
>> >> >
>> >> > Run DBCC CHECKDB againt all your DB's on the server and see what the output
>> >> > is.
>> >> >
>> >> > Regards
>> >> > --
>> >> > Mike Epprecht, Microsoft SQL Server MVP
>> >> > Zurich, Switzerland
>> >> >
>> >> > MVP Program: http://www.microsoft.com/mvp
>> >> >
>> >> > Blog: http://www.msmvps.com/epprecht/
>> >> >
>> >> >
>> >> >
>> >> > "alex" wrote:
>> >> >
>> >> > > Hi,
>> >> > > I'm running SQL 2000 and server quite often (3 times within the last week)
>> >> > > fails on insert operation with the messages like:
>> >> > >
>> >> > > "Attempt to fetch logical page (1:202685) in database 'tempdb' belongs to
>> >> > > object '-948063835' not to object #tmp
>> >> > >
>> >> > > Connection Broken"
>> >> > >
>> >> > > Similar messages were for the tables in the completely different databases.
>> >> > >
>> >> > > Does not look like this is directly related to the table's size.
>> >> > >
>> >> > > Thanks
>> >> > >
>> >> > >
>>|||Also, CHECKDB doesn't check everything in TEMPDB so may not pick up on the
problem you have. You also can't run repair on TEMPDB as its impossible to
put TEMPDB into single_user mode (prerequisite for running repair).
If you can repro the problem, you should call product support
(http://support.microsoft.com)
Thanks
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eBmRC1EbFHA.2420@.TK2MSFTNGP12.phx.gbl...
> Probably the corruption disappeared since objects are created and dropped
> all the time in tempdb. Also, you possibly re-started SQL server in
> between so tempdb was rebuilt. However, you have had a corruption, and
> that it something you should investigate further.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "alex" <alex@.discussions.microsoft.com> wrote in message
> news:E28034E7-9F14-46EB-B491-CB690F52E0D0@.microsoft.com...
>> Thanks but I did not say that DB was corrupted: DBCC CHECKDATABASE
>> indicated
>> that there are no problems.
>> Is corruption the only reason for getting Msg 605?
>> "Tibor Karaszi" wrote:
>> > Can the problem be a result of some
>> > application's
>> > activities like the following scenario:
>> Basically, no. No TSQL code should be able to corrupt a database. If you
>> can find such code that
>> reproduces, you have found a bug in SQL Server. You should investigate
>> for hardware errors. See
>> general recommendations at
>> http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp. Also,
>> remember that tempdb is re-created at each startup...
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "alex" <alex@.discussions.microsoft.com> wrote in message
>> news:8D8B81BF-1C2A-4088-ACAE-1609A0FC5223@.microsoft.com...
>> > Thanks. Did that and got:
>> > ....
>> > CHECKDB found 0 allocation errors and 0 consistency errors in database
>> > 'tempdb'.
>> > DBCC execution completed. If DBCC printed error messages, contact your
>> > system administrator.
>> >
>> > Looks like database itself is OK. Can the problem be a result of some
>> > application's
>> > activities like the following scenario:
>> >
>> > main stored procedure calls, withing a cycle, underlying stored
>> > procedure
>> > and this
>> > procedure contains the following:
>> >
>> > create table #tmp(....)
>> > ....
>> > drop table #tmp
>> >
>> > It looks like after few repetitions of this scenario (number of the
>> > iterations varies)
>> > breakdown occurs. After replacement of the temp table with a regular
>> > one,
>> > situation seems to be remedied.
>> >
>> > Can it be that tempdb may have problems with a repeated re-creation of
>> > a
>> > dropped temp. table within a single session?
>> >
>> > Thanks
>> >
>> > "Donna Lambert" wrote:
>> >
>> >> Also check your backups (restore to a different sql server, run dbcc
>> >> checkdb
>> >> on those). Find a backup that does not contain the corruption.
>> >> You may lose data.
>> >> If DBCC reports the minimal repair level is "repair_allow_data_loss"
>> >> it's
>> >> not kidding.
>> >> If you run that, be prepared to lose some data. It might be a row, a
>> >> page,
>> >> whole tables. There's really no telling.
>> >> Going back to a known good state is often a better alternative. At
>> >> least
>> >> you know what data you lost.
>> >> :D
>> >> Donna Lambert
>> >>
>> >>
>> >> "Mike Epprecht (SQL MVP)" wrote:
>> >>
>> >> > Hi
>> >> >
>> >> > Looks like corruption. Either your RAM or disk could ber causing
>> >> > this.
>> >> >
>> >> > Run DBCC CHECKDB againt all your DB's on the server and see what
>> >> > the output
>> >> > is.
>> >> >
>> >> > Regards
>> >> > --
>> >> > Mike Epprecht, Microsoft SQL Server MVP
>> >> > Zurich, Switzerland
>> >> >
>> >> > MVP Program: http://www.microsoft.com/mvp
>> >> >
>> >> > Blog: http://www.msmvps.com/epprecht/
>> >> >
>> >> >
>> >> >
>> >> > "alex" wrote:
>> >> >
>> >> > > Hi,
>> >> > > I'm running SQL 2000 and server quite often (3 times within the
>> >> > > last week)
>> >> > > fails on insert operation with the messages like:
>> >> > >
>> >> > > "Attempt to fetch logical page (1:202685) in database 'tempdb'
>> >> > > belongs to
>> >> > > object '-948063835' not to object #tmp
>> >> > >
>> >> > > Connection Broken"
>> >> > >
>> >> > > Similar messages were for the tables in the completely different
>> >> > > databases.
>> >> > >
>> >> > > Does not look like this is directly related to the table's size.
>> >> > >
>> >> > > Thanks
>> >> > >
>> >> > >
>>
>