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
>
Showing posts with label attempt. Show all posts
Showing posts with label attempt. Show all posts
Monday, March 19, 2012
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.
Thanks
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
>
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
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
>
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
>> >> > >
>> >> > >
>>
>
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
>> >> > >
>> >> > >
>>
>
Friday, March 9, 2012
MSFT: Urgent request for explanation, help please
Hello MSFT,
this is a repeated attempt to get an explanation for a hopefully simple
problem.
The question: What causes RS to mark an user account as "unknown" as
described below and what has to be done in order to get rid of this?
Here the problem description:
<snip>
I got a clue what might be wrong on my server machines which do not allow
eMail subscription due to a "configuration error"
I have an XP machine here with a local SQL server and a local RS client and
server. If I look at the property page of a given report there is always
something like that (I have to translate it from german, so maybe it is a
bit different in english versions):
changed at: (datetime)
changed by: SPONGEBOB\roland
created at: (datetime)
created by: SPONGEBOB\roland
size: 8kb
SPONGEBOB is the name of the machine; roland the user account.
Whereas my server machines show up the following:
changed at: (datetime)
changed by: TACCO\Administrator (unknown)
created at: (datetime)
created by: TACCO\Administrator (unknown)
size: 8kb
TACCO is the server name; administrator the user account. My concern is the
"unknown", what exactly causes the problem with eMail subscription. What
does cause RS to print "unknown" there and how to come over it?
</snip>
TIA
rolandReporting Services gets the name of the user from Windows / Active
Directory. Internally, we store a SID and translate this via the Windows API
at display time. In general, I don't think it has anything to do with your
subscription failures. What does the entry in the log file say?
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Roland" <roland.klabunde@.gmx.de> wrote in message
news:execmMdVEHA.1472@.TK2MSFTNGP09.phx.gbl...
> Hello MSFT,
> this is a repeated attempt to get an explanation for a hopefully simple
> problem.
> The question: What causes RS to mark an user account as "unknown" as
> described below and what has to be done in order to get rid of this?
>
> Here the problem description:
> <snip>
> I got a clue what might be wrong on my server machines which do not allow
> eMail subscription due to a "configuration error"
> I have an XP machine here with a local SQL server and a local RS client
and
> server. If I look at the property page of a given report there is always
> something like that (I have to translate it from german, so maybe it is a
> bit different in english versions):
> changed at: (datetime)
> changed by: SPONGEBOB\roland
> created at: (datetime)
> created by: SPONGEBOB\roland
> size: 8kb
> SPONGEBOB is the name of the machine; roland the user account.
> Whereas my server machines show up the following:
> changed at: (datetime)
> changed by: TACCO\Administrator (unknown)
> created at: (datetime)
> created by: TACCO\Administrator (unknown)
> size: 8kb
> TACCO is the server name; administrator the user account. My concern is
the
> "unknown", what exactly causes the problem with eMail subscription. What
> does cause RS to print "unknown" there and how to come over it?
> </snip>
>
> TIA
> roland
>
>|||In news:O5Q6GwtVEHA.3988@.tk2msftngp13.phx.gbl,
Brian Welcker [MSFT] <bwelcker@.online.microsoft.com> typed:
> Reporting Services gets the name of the user from Windows
> / Active Directory. Internally, we store a SID and
> translate this via the Windows API at display time. In
> general, I don't think it has anything to do with your
> subscription failures. What does the entry in the log
> file say?
Hello Brian,
thanks for your answer. All of our observations point into the direction of
a policy or user rights problem. Besides the fact, that the SPONGEBOB
machine has the SQL server locally and the TACCO had a previous Sharepoint
installation (currently deinstalled) this "unknown" trace seems to be the
only difference between both setups for RS.
We have three problems with TACCO:
1) The "unknown" remark
2) Sometimes we get an error which complains about an "unknown user", mostly
on attempts to setup role properties for a given and correct user
3) The eMail subscription does not work.
Here is the log for 2)
aspnet_wp!library!918!05/24/2004-14:30:07:: e ERROR: Throwing
Microsoft.ReportingServices.Diagnostics.Utilities.UnknownUserNameException:
Der Benutzer- oder Gruppenname 'roland.klabunde[Unbekannt]' wird nicht
erkannt., ;
Info:
Microsoft.ReportingServices.Diagnostics.Utilities.UnknownUserNameException:
Der Benutzer- oder Gruppenname 'roland.klabunde[Unbekannt]' wird nicht
erkannt.
Means: User or groupname roland.klabunde has not been recognized
Here is the log for 3)
ReportingServicesService!library!c20!05/24/2004-14:26:02:: e ERROR: Throwing
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
ception: The Report Server has encountered a configuration error; more
details in the log files, AuthzInitializeContextFromSid: Win32 error: 87;
Info:
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
ception: The Report Server has encountered a configuration error; more
details in the log files
ReportingServicesService!emailextension!c20!05/24/2004-14:26:02:: Error
sending email.
Microsoft.ReportingServices.Diagnostics.Utilities.RSException: The Report
Server has encountered a configuration error; more details in the log
files -->
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
ception: The Report Server has encountered a configuration error; more
details in the log files
Because I already made eMail subscription run on SPONGEBOB I'm currently
having no idea what might be wrong. As said the latest clue was that
"unknown" remark...
Hoping to finally overcome this problem
roland|||Looks like the user verification during subscriptions is failing. We use a
module called AuthZ to do this. Not sure what OS this is running on but if
it is Windows 2000, you will need to install the most recent service pack.
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Roland" <roland.klabunde@.gmx.de> wrote in message
news:ucIk$9uVEHA.1152@.TK2MSFTNGP09.phx.gbl...
> In news:O5Q6GwtVEHA.3988@.tk2msftngp13.phx.gbl,
> Brian Welcker [MSFT] <bwelcker@.online.microsoft.com> typed:
> > Reporting Services gets the name of the user from Windows
> > / Active Directory. Internally, we store a SID and
> > translate this via the Windows API at display time. In
> > general, I don't think it has anything to do with your
> > subscription failures. What does the entry in the log
> > file say?
> Hello Brian,
> thanks for your answer. All of our observations point into the direction
of
> a policy or user rights problem. Besides the fact, that the SPONGEBOB
> machine has the SQL server locally and the TACCO had a previous Sharepoint
> installation (currently deinstalled) this "unknown" trace seems to be the
> only difference between both setups for RS.
> We have three problems with TACCO:
> 1) The "unknown" remark
> 2) Sometimes we get an error which complains about an "unknown user",
mostly
> on attempts to setup role properties for a given and correct user
> 3) The eMail subscription does not work.
> Here is the log for 2)
> aspnet_wp!library!918!05/24/2004-14:30:07:: e ERROR: Throwing
>
Microsoft.ReportingServices.Diagnostics.Utilities.UnknownUserNameException:
> Der Benutzer- oder Gruppenname 'roland.klabunde[Unbekannt]' wird nicht
> erkannt., ;
> Info:
>
Microsoft.ReportingServices.Diagnostics.Utilities.UnknownUserNameException:
> Der Benutzer- oder Gruppenname 'roland.klabunde[Unbekannt]' wird nicht
> erkannt.
> Means: User or groupname roland.klabunde has not been recognized
> Here is the log for 3)
> ReportingServicesService!library!c20!05/24/2004-14:26:02:: e ERROR:
Throwing
>
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
> ception: The Report Server has encountered a configuration error; more
> details in the log files, AuthzInitializeContextFromSid: Win32 error: 87;
> Info:
>
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
> ception: The Report Server has encountered a configuration error; more
> details in the log files
>
> ReportingServicesService!emailextension!c20!05/24/2004-14:26:02:: Error
> sending email.
> Microsoft.ReportingServices.Diagnostics.Utilities.RSException: The Report
> Server has encountered a configuration error; more details in the log
> files -->
>
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
> ception: The Report Server has encountered a configuration error; more
> details in the log files
> Because I already made eMail subscription run on SPONGEBOB I'm currently
> having no idea what might be wrong. As said the latest clue was that
> "unknown" remark...
> Hoping to finally overcome this problem
> roland
>
>|||Brian, the Win2000 machine Tacco has SP4 and the latest patches installed. I
got the message that we have a third machine with this problem. It is a
Windows 2003 server. Again: We do neither have Active Directory installed
anywhere. Could that be the problem?
r.|||No, I think it has something to do with the privileges of the user used to
run the ReportServer Windows service. Are you running a domain? Is the
service running as a domain user?
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Roland" <roland.klabunde@.gmx.net> wrote in message
news:OhFFPD3VEHA.384@.TK2MSFTNGP10.phx.gbl...
> Brian, the Win2000 machine Tacco has SP4 and the latest patches installed.
I
> got the message that we have a third machine with this problem. It is a
> Windows 2003 server. Again: We do neither have Active Directory installed
> anywhere. Could that be the problem?
> r.
>|||> No, I think it has something to do with the privileges of the user used to
> run the ReportServer Windows service. Are you running a domain? Is the
> service running as a domain user?
The answers to both of your questions is NO. Does this cause any problem?
r|||Next attempt on new machine:
* Windows 2000 Advanced Server German out of the box, SP 4, latest security
patches.
* No domain, no active directory, standard web server
* IIS 5
* RS eval
* RS running under System
* Websites under ASPNET
Same result: Administrator marked as unknown, eMail subscription fails.
r.|||The error returned by the name resolution API is that the parameter is
incorrect. We have not seen this before.
A way to debug this would be to look at the subscription owner in the
ReportServer database:
select * from Users inner join Subscriptions on User.UserID =Subscriptions.OwnerID
The SQL is from memory so the exact syntax may be slightly different.
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Roland" <roland.klabunde@.gmx.net> wrote in message
news:uaPVZaGWEHA.1048@.tk2msftngp13.phx.gbl...
> Here is the log. The OS is an english Win2k Advanced Server.
> I'm near to surrender. Five machines and one with OK eMail only...
> r
>
>
>|||Brian, the problem has been solved by SP 1. Since then the [unknown] entry
has gone...
Thanks
roland
this is a repeated attempt to get an explanation for a hopefully simple
problem.
The question: What causes RS to mark an user account as "unknown" as
described below and what has to be done in order to get rid of this?
Here the problem description:
<snip>
I got a clue what might be wrong on my server machines which do not allow
eMail subscription due to a "configuration error"
I have an XP machine here with a local SQL server and a local RS client and
server. If I look at the property page of a given report there is always
something like that (I have to translate it from german, so maybe it is a
bit different in english versions):
changed at: (datetime)
changed by: SPONGEBOB\roland
created at: (datetime)
created by: SPONGEBOB\roland
size: 8kb
SPONGEBOB is the name of the machine; roland the user account.
Whereas my server machines show up the following:
changed at: (datetime)
changed by: TACCO\Administrator (unknown)
created at: (datetime)
created by: TACCO\Administrator (unknown)
size: 8kb
TACCO is the server name; administrator the user account. My concern is the
"unknown", what exactly causes the problem with eMail subscription. What
does cause RS to print "unknown" there and how to come over it?
</snip>
TIA
rolandReporting Services gets the name of the user from Windows / Active
Directory. Internally, we store a SID and translate this via the Windows API
at display time. In general, I don't think it has anything to do with your
subscription failures. What does the entry in the log file say?
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Roland" <roland.klabunde@.gmx.de> wrote in message
news:execmMdVEHA.1472@.TK2MSFTNGP09.phx.gbl...
> Hello MSFT,
> this is a repeated attempt to get an explanation for a hopefully simple
> problem.
> The question: What causes RS to mark an user account as "unknown" as
> described below and what has to be done in order to get rid of this?
>
> Here the problem description:
> <snip>
> I got a clue what might be wrong on my server machines which do not allow
> eMail subscription due to a "configuration error"
> I have an XP machine here with a local SQL server and a local RS client
and
> server. If I look at the property page of a given report there is always
> something like that (I have to translate it from german, so maybe it is a
> bit different in english versions):
> changed at: (datetime)
> changed by: SPONGEBOB\roland
> created at: (datetime)
> created by: SPONGEBOB\roland
> size: 8kb
> SPONGEBOB is the name of the machine; roland the user account.
> Whereas my server machines show up the following:
> changed at: (datetime)
> changed by: TACCO\Administrator (unknown)
> created at: (datetime)
> created by: TACCO\Administrator (unknown)
> size: 8kb
> TACCO is the server name; administrator the user account. My concern is
the
> "unknown", what exactly causes the problem with eMail subscription. What
> does cause RS to print "unknown" there and how to come over it?
> </snip>
>
> TIA
> roland
>
>|||In news:O5Q6GwtVEHA.3988@.tk2msftngp13.phx.gbl,
Brian Welcker [MSFT] <bwelcker@.online.microsoft.com> typed:
> Reporting Services gets the name of the user from Windows
> / Active Directory. Internally, we store a SID and
> translate this via the Windows API at display time. In
> general, I don't think it has anything to do with your
> subscription failures. What does the entry in the log
> file say?
Hello Brian,
thanks for your answer. All of our observations point into the direction of
a policy or user rights problem. Besides the fact, that the SPONGEBOB
machine has the SQL server locally and the TACCO had a previous Sharepoint
installation (currently deinstalled) this "unknown" trace seems to be the
only difference between both setups for RS.
We have three problems with TACCO:
1) The "unknown" remark
2) Sometimes we get an error which complains about an "unknown user", mostly
on attempts to setup role properties for a given and correct user
3) The eMail subscription does not work.
Here is the log for 2)
aspnet_wp!library!918!05/24/2004-14:30:07:: e ERROR: Throwing
Microsoft.ReportingServices.Diagnostics.Utilities.UnknownUserNameException:
Der Benutzer- oder Gruppenname 'roland.klabunde[Unbekannt]' wird nicht
erkannt., ;
Info:
Microsoft.ReportingServices.Diagnostics.Utilities.UnknownUserNameException:
Der Benutzer- oder Gruppenname 'roland.klabunde[Unbekannt]' wird nicht
erkannt.
Means: User or groupname roland.klabunde has not been recognized
Here is the log for 3)
ReportingServicesService!library!c20!05/24/2004-14:26:02:: e ERROR: Throwing
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
ception: The Report Server has encountered a configuration error; more
details in the log files, AuthzInitializeContextFromSid: Win32 error: 87;
Info:
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
ception: The Report Server has encountered a configuration error; more
details in the log files
ReportingServicesService!emailextension!c20!05/24/2004-14:26:02:: Error
sending email.
Microsoft.ReportingServices.Diagnostics.Utilities.RSException: The Report
Server has encountered a configuration error; more details in the log
files -->
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
ception: The Report Server has encountered a configuration error; more
details in the log files
Because I already made eMail subscription run on SPONGEBOB I'm currently
having no idea what might be wrong. As said the latest clue was that
"unknown" remark...
Hoping to finally overcome this problem
roland|||Looks like the user verification during subscriptions is failing. We use a
module called AuthZ to do this. Not sure what OS this is running on but if
it is Windows 2000, you will need to install the most recent service pack.
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Roland" <roland.klabunde@.gmx.de> wrote in message
news:ucIk$9uVEHA.1152@.TK2MSFTNGP09.phx.gbl...
> In news:O5Q6GwtVEHA.3988@.tk2msftngp13.phx.gbl,
> Brian Welcker [MSFT] <bwelcker@.online.microsoft.com> typed:
> > Reporting Services gets the name of the user from Windows
> > / Active Directory. Internally, we store a SID and
> > translate this via the Windows API at display time. In
> > general, I don't think it has anything to do with your
> > subscription failures. What does the entry in the log
> > file say?
> Hello Brian,
> thanks for your answer. All of our observations point into the direction
of
> a policy or user rights problem. Besides the fact, that the SPONGEBOB
> machine has the SQL server locally and the TACCO had a previous Sharepoint
> installation (currently deinstalled) this "unknown" trace seems to be the
> only difference between both setups for RS.
> We have three problems with TACCO:
> 1) The "unknown" remark
> 2) Sometimes we get an error which complains about an "unknown user",
mostly
> on attempts to setup role properties for a given and correct user
> 3) The eMail subscription does not work.
> Here is the log for 2)
> aspnet_wp!library!918!05/24/2004-14:30:07:: e ERROR: Throwing
>
Microsoft.ReportingServices.Diagnostics.Utilities.UnknownUserNameException:
> Der Benutzer- oder Gruppenname 'roland.klabunde[Unbekannt]' wird nicht
> erkannt., ;
> Info:
>
Microsoft.ReportingServices.Diagnostics.Utilities.UnknownUserNameException:
> Der Benutzer- oder Gruppenname 'roland.klabunde[Unbekannt]' wird nicht
> erkannt.
> Means: User or groupname roland.klabunde has not been recognized
> Here is the log for 3)
> ReportingServicesService!library!c20!05/24/2004-14:26:02:: e ERROR:
Throwing
>
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
> ception: The Report Server has encountered a configuration error; more
> details in the log files, AuthzInitializeContextFromSid: Win32 error: 87;
> Info:
>
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
> ception: The Report Server has encountered a configuration error; more
> details in the log files
>
> ReportingServicesService!emailextension!c20!05/24/2004-14:26:02:: Error
> sending email.
> Microsoft.ReportingServices.Diagnostics.Utilities.RSException: The Report
> Server has encountered a configuration error; more details in the log
> files -->
>
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorEx
> ception: The Report Server has encountered a configuration error; more
> details in the log files
> Because I already made eMail subscription run on SPONGEBOB I'm currently
> having no idea what might be wrong. As said the latest clue was that
> "unknown" remark...
> Hoping to finally overcome this problem
> roland
>
>|||Brian, the Win2000 machine Tacco has SP4 and the latest patches installed. I
got the message that we have a third machine with this problem. It is a
Windows 2003 server. Again: We do neither have Active Directory installed
anywhere. Could that be the problem?
r.|||No, I think it has something to do with the privileges of the user used to
run the ReportServer Windows service. Are you running a domain? Is the
service running as a domain user?
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Roland" <roland.klabunde@.gmx.net> wrote in message
news:OhFFPD3VEHA.384@.TK2MSFTNGP10.phx.gbl...
> Brian, the Win2000 machine Tacco has SP4 and the latest patches installed.
I
> got the message that we have a third machine with this problem. It is a
> Windows 2003 server. Again: We do neither have Active Directory installed
> anywhere. Could that be the problem?
> r.
>|||> No, I think it has something to do with the privileges of the user used to
> run the ReportServer Windows service. Are you running a domain? Is the
> service running as a domain user?
The answers to both of your questions is NO. Does this cause any problem?
r|||Next attempt on new machine:
* Windows 2000 Advanced Server German out of the box, SP 4, latest security
patches.
* No domain, no active directory, standard web server
* IIS 5
* RS eval
* RS running under System
* Websites under ASPNET
Same result: Administrator marked as unknown, eMail subscription fails.
r.|||The error returned by the name resolution API is that the parameter is
incorrect. We have not seen this before.
A way to debug this would be to look at the subscription owner in the
ReportServer database:
select * from Users inner join Subscriptions on User.UserID =Subscriptions.OwnerID
The SQL is from memory so the exact syntax may be slightly different.
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Roland" <roland.klabunde@.gmx.net> wrote in message
news:uaPVZaGWEHA.1048@.tk2msftngp13.phx.gbl...
> Here is the log. The OS is an english Win2k Advanced Server.
> I'm near to surrender. Five machines and one with OK eMail only...
> r
>
>
>|||Brian, the problem has been solved by SP 1. Since then the [unknown] entry
has gone...
Thanks
roland
Subscribe to:
Posts (Atom)