Failed to obtain TransactionDispenserInterface and invalid LSN, databases suspec

All of a sudden I have 4 of my databases, including pubs that are all marked suspect and seem to be un-recoverable. I have followed the Resetting the suspect status directions as well as trying to attach only the .mdf files but still run into problems reading the .ldf file. I have not tried to do the procedure of creating another database with the same name and structure then swapping the files to trick SQl but will do so if I need to. Does anyone know why this happens all of a sudden to multile databases, of which Pubs I have never used for anything??

In my log files during startup I get this error

Failed to obtain TransactionDispenserInterface: Result Code = 0x8004d01b

Then this error for every database that is suspect, (the actual LSN numbers are different for each one).

The LSN (4:517:1) passed to log scan in database 'pubs' is invalid..
Is there anything else I can do to prevent this from happening or recover the DB's

ThanksThe log file is corrupted. The only good prevention is to have a good backup strategy. You need to look at whether your .mdf is also corrupted or not.|||Why would these become corrupted? Should I look for a SQL problem or a disk error??... Do you know the best way to track this?? I found it odd that 4 databases would end up like this at the same time

Thanks

Failed to access IIS metabase

I have installed SQL Server 2005, including Reporting Services 2005 on
Windows XP Professional in a standalone environment. I can see the Reports
and ReportServer folders in IIS in Administrative Tools and all settings
appear to be appropriate.
My first problem is that, when I try to access
"http://localhost/ReportServer", I get an error "Failed to access IIS
metabase". I have looked at KB article
"http://support.microsoft.com/?kbid=267904" which is referred to in the error
message but it appears to relate to Windows Server 2003.
Secondly, I expected to get the same error when trying to access
"http://localhost/Reports" but in this case I get a message "Directory
Listing Denied" which seems to indicate that the metabase is not an issue
here. I can see the directory listing if I activiate this option in IIS in
Admin Tools but I can't browse the contents of the Reports web page.
Can anyone provide me with a solution? I have also listed this problem in
Windows Server - IIS in case it is an IIS problem.
Thank you.The ASP.NET 2.0 is not registered properly in IIS. RS2005 uses ASP.NET 2.0
Try registering in the command line using the following ..
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i
and reset the iis. I think that will solve all the problem.
Let me know.
Thanks
Bava
"NeilW" wrote:
> I have installed SQL Server 2005, including Reporting Services 2005 on
> Windows XP Professional in a standalone environment. I can see the Reports
> and ReportServer folders in IIS in Administrative Tools and all settings
> appear to be appropriate.
> My first problem is that, when I try to access
> "http://localhost/ReportServer", I get an error "Failed to access IIS
> metabase". I have looked at KB article
> "http://support.microsoft.com/?kbid=267904" which is referred to in the error
> message but it appears to relate to Windows Server 2003.
> Secondly, I expected to get the same error when trying to access
> "http://localhost/Reports" but in this case I get a message "Directory
> Listing Denied" which seems to indicate that the metabase is not an issue
> here. I can see the directory listing if I activiate this option in IIS in
> Admin Tools but I can't browse the contents of the Reports web page.
> Can anyone provide me with a solution? I have also listed this problem in
> Windows Server - IIS in case it is an IIS problem.
> Thank you.
>|||Your solution worked perfectly. Thanks very much.
"Bava Mani" wrote:
> The ASP.NET 2.0 is not registered properly in IIS. RS2005 uses ASP.NET 2.0
> Try registering in the command line using the following ..
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i
> and reset the iis. I think that will solve all the problem.
> Let me know.
> Thanks
> Bava
> "NeilW" wrote:
> > I have installed SQL Server 2005, including Reporting Services 2005 on
> > Windows XP Professional in a standalone environment. I can see the Reports
> > and ReportServer folders in IIS in Administrative Tools and all settings
> > appear to be appropriate.
> >
> > My first problem is that, when I try to access
> > "http://localhost/ReportServer", I get an error "Failed to access IIS
> > metabase". I have looked at KB article
> > "http://support.microsoft.com/?kbid=267904" which is referred to in the error
> > message but it appears to relate to Windows Server 2003.
> >
> > Secondly, I expected to get the same error when trying to access
> > "http://localhost/Reports" but in this case I get a message "Directory
> > Listing Denied" which seems to indicate that the metabase is not an issue
> > here. I can see the directory listing if I activiate this option in IIS in
> > Admin Tools but I can't browse the contents of the Reports web page.
> >
> > Can anyone provide me with a solution? I have also listed this problem in
> > Windows Server - IIS in case it is an IIS problem.
> >
> > Thank you.
> >|||I have this same problem, however the solution given here did not work. Here
is what I have done:
1) Run a repair install of .Net 2.0
2) Totally reinstall .Net 2.0
3) Run aspnet_regiis.exe -i
4) Run aspnet_regiis.exe -ga ASPNET
Still have the problem. Any more ideas?
--
James
"Bava Mani" wrote:
> The ASP.NET 2.0 is not registered properly in IIS. RS2005 uses ASP.NET 2.0
> Try registering in the command line using the following ..
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i
> and reset the iis. I think that will solve all the problem.
> Let me know.
> Thanks
> Bava
> "NeilW" wrote:
> > I have installed SQL Server 2005, including Reporting Services 2005 on
> > Windows XP Professional in a standalone environment. I can see the Reports
> > and ReportServer folders in IIS in Administrative Tools and all settings
> > appear to be appropriate.
> >
> > My first problem is that, when I try to access
> > "http://localhost/ReportServer", I get an error "Failed to access IIS
> > metabase". I have looked at KB article
> > "http://support.microsoft.com/?kbid=267904" which is referred to in the error
> > message but it appears to relate to Windows Server 2003.
> >
> > Secondly, I expected to get the same error when trying to access
> > "http://localhost/Reports" but in this case I get a message "Directory
> > Listing Denied" which seems to indicate that the metabase is not an issue
> > here. I can see the directory listing if I activiate this option in IIS in
> > Admin Tools but I can't browse the contents of the Reports web page.
> >
> > Can anyone provide me with a solution? I have also listed this problem in
> > Windows Server - IIS in case it is an IIS problem.
> >
> > Thank you.
> >|||Can you give me the error msg that it says. send me more details of when and
where you get the error.
Thanks
Bava
"James" wrote:
> I have this same problem, however the solution given here did not work. Here
> is what I have done:
> 1) Run a repair install of .Net 2.0
> 2) Totally reinstall .Net 2.0
> 3) Run aspnet_regiis.exe -i
> 4) Run aspnet_regiis.exe -ga ASPNET
> Still have the problem. Any more ideas?
> --
> James
>
> "Bava Mani" wrote:
> > The ASP.NET 2.0 is not registered properly in IIS. RS2005 uses ASP.NET 2.0
> > Try registering in the command line using the following ..
> > C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i
> > and reset the iis. I think that will solve all the problem.
> > Let me know.
> >
> > Thanks
> > Bava
> >
> > "NeilW" wrote:
> >
> > > I have installed SQL Server 2005, including Reporting Services 2005 on
> > > Windows XP Professional in a standalone environment. I can see the Reports
> > > and ReportServer folders in IIS in Administrative Tools and all settings
> > > appear to be appropriate.
> > >
> > > My first problem is that, when I try to access
> > > "http://localhost/ReportServer", I get an error "Failed to access IIS
> > > metabase". I have looked at KB article
> > > "http://support.microsoft.com/?kbid=267904" which is referred to in the error
> > > message but it appears to relate to Windows Server 2003.
> > >
> > > Secondly, I expected to get the same error when trying to access
> > > "http://localhost/Reports" but in this case I get a message "Directory
> > > Listing Denied" which seems to indicate that the metabase is not an issue
> > > here. I can see the directory listing if I activiate this option in IIS in
> > > Admin Tools but I can't browse the contents of the Reports web page.
> > >
> > > Can anyone provide me with a solution? I have also listed this problem in
> > > Windows Server - IIS in case it is an IIS problem.
> > >
> > > Thank you.
> > >

Fact Tables and Clustered Indexes

A design question:
Say I have a medium-sized fact table w/ a handful of dimension key
columns (including a date) and a handful of measures.
I necessarily need a primary key on the composite dimension key
columns, and I don't know ahead of time which of my dimension key
column(s) will be the best candidate for a clustered index. I do plan
on putting non-clustered indexes on all my dimension key columns, and
the related dimension tables' key columns.
For the sake of argument, let's say we're not partitioning the fact
table.
Assume that new facts occur in time, the fact table grows with time,
and (nearly) all changes to the fact table occur as INSERTs.
Now, all things being equal, is there a benefit of adding a clustered
index to the fact table? Two options:
- Add an IDENTITY column, make it the primary key, and add the
clustered index to it.
- Add the clustered index on the date column, since it has a natural
order.
Basically, I'm after two answers in this scenario:
- Is there a benefit to having a clustered index on a table when the
application doesn't 'really' call for one?
- If so, is it better to add an IDENTITY column (adding size to the
table) or to pick an naturally ordered dimension key? A random key?
The fact's composite key?
Thanks much.
Steven D. Clark
stevec@.clarkdev.com
"Steven Clark" <stevec@.clarkdev.com> wrote in message
news:d7740507.0407100710.2b1644b5@.posting.google.c om...
> Basically, I'm after two answers in this scenario:
> - Is there a benefit to having a clustered index on a table when the
> application doesn't 'really' call for one?
In my opinion, there is never a reason NOT to have one; it's a freebie,
basically, unlike clustered indexes. It doesn't take up any extra disc
space, and you might as well order the data on the disc somehow, rather than
letting the server take care of it... So I always make sure that every table
has one.

> - If so, is it better to add an IDENTITY column (adding size to the
> table) or to pick an naturally ordered dimension key? A random key?
> The fact's composite key?
Some tips for clustered indexes:
- They assist with range queries and grouping. So try to use them for
columns that will be used for those kinds of operations (>, <, BETWEEN, etc,
or make it composite in the same order that you'll be grouping. If you do
composite, order the columns by selectivity, least selective first. This
will create a wider tree, which will result in somewhat quicker grouping.)
- Clustering on a random key is a very bad idea, because it will cause a
lot of page splits, leading to fragmentation. This will slow your data
loads. It will also give you no query benefits at all. So you'll actually
lose on this option.
- Clustering on an IDENTITY key or a DATETIME column that's
automatically set to the date the row is inserted will actually speed up
inserts as it will create a hotspot at the end of the table. So you'll
never have page splits when inserting new data. This can definitely help
speed your data load! Clustering on an IDENTITY will usually not help too
much with queries as, in my experience, most grouping and range operations
don't consider surrogates. Depending on your app, clustering on a DATETIME
as I described can help a lot, as a lot of queries will request data between
two dates, greater than a date, etc.
- Finally, clustering on the composite of your dimensions may be helpful
if you're grouping on them or requesting ranges. However, in the latter
case, remember that a composite index will only be used for searching if the
first column is part of the search criteria, so try to choose one of your
dimensions that will always be searched on (if that exists in your
warehouse).
I hope that answered your questions? Post back if you need some
clarification or further assistance.
|||> It doesn't take up any extra disc space,
That's not true. The clustered index uses the datapages as the leaves, so
that is disk space you use already anyway, but the nodes of the index still
take up extra space on disk. That doesn't mean btw that it is not a good
idea to have a clustered index on every table. In almost all cases the
performance improvement that a clustered index provides more than offsets
the extra disk space used.
Jacco Schalkwijk
SQL Server MVP
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23rDxElvZEHA.2388@.TK2MSFTNGP11.phx.gbl...
> "Steven Clark" <stevec@.clarkdev.com> wrote in message
> news:d7740507.0407100710.2b1644b5@.posting.google.c om...
> In my opinion, there is never a reason NOT to have one; it's a
freebie,
> basically, unlike clustered indexes. It doesn't take up any extra disc
> space, and you might as well order the data on the disc somehow, rather
than
> letting the server take care of it... So I always make sure that every
table
> has one.
>
> Some tips for clustered indexes:
> - They assist with range queries and grouping. So try to use them for
> columns that will be used for those kinds of operations (>, <, BETWEEN,
etc,
> or make it composite in the same order that you'll be grouping. If you do
> composite, order the columns by selectivity, least selective first. This
> will create a wider tree, which will result in somewhat quicker grouping.)
> - Clustering on a random key is a very bad idea, because it will cause
a
> lot of page splits, leading to fragmentation. This will slow your data
> loads. It will also give you no query benefits at all. So you'll
actually
> lose on this option.
> - Clustering on an IDENTITY key or a DATETIME column that's
> automatically set to the date the row is inserted will actually speed up
> inserts as it will create a hotspot at the end of the table. So you'll
> never have page splits when inserting new data. This can definitely help
> speed your data load! Clustering on an IDENTITY will usually not help too
> much with queries as, in my experience, most grouping and range operations
> don't consider surrogates. Depending on your app, clustering on a
DATETIME
> as I described can help a lot, as a lot of queries will request data
between
> two dates, greater than a date, etc.
> - Finally, clustering on the composite of your dimensions may be
helpful
> if you're grouping on them or requesting ranges. However, in the latter
> case, remember that a composite index will only be used for searching if
the
> first column is part of the search criteria, so try to choose one of your
> dimensions that will always be searched on (if that exists in your
> warehouse).
> I hope that answered your questions? Post back if you need some
> clarification or further assistance.
>
>
|||"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid > wrote
in message news:%23cIz3GDaEHA.2544@.TK2MSFTNGP10.phx.gbl...
> That's not true. The clustered index uses the datapages as the leaves, so
> that is disk space you use already anyway, but the nodes of the index
still
> take up extra space on disk. That doesn't mean btw that it is not a good
> idea to have a clustered index on every table. In almost all cases the
> performance improvement that a clustered index provides more than offsets
> the extra disk space used.
Thanks for the clarification on that... I also didn't think about fill
factor, which could also create the impression of more disc space being
used.

Fact Tables and Clustered Indexes

A design question:
Say I have a medium-sized fact table w/ a handful of dimension key
columns (including a date) and a handful of measures.
I necessarily need a primary key on the composite dimension key
columns, and I don't know ahead of time which of my dimension key
column(s) will be the best candidate for a clustered index. I do plan
on putting non-clustered indexes on all my dimension key columns, and
the related dimension tables' key columns.
For the sake of argument, let's say we're not partitioning the fact
table.
Assume that new facts occur in time, the fact table grows with time,
and (nearly) all changes to the fact table occur as INSERTs.
Now, all things being equal, is there a benefit of adding a clustered
index to the fact table? Two options:
- Add an IDENTITY column, make it the primary key, and add the
clustered index to it.
- Add the clustered index on the date column, since it has a natural
order.
Basically, I'm after two answers in this scenario:
- Is there a benefit to having a clustered index on a table when the
application doesn't 'really' call for one?
- If so, is it better to add an IDENTITY column (adding size to the
table) or to pick an naturally ordered dimension key? A random key?
The fact's composite key?
Thanks much.
Steven D. Clark
stevec@.clarkdev.com"Steven Clark" <stevec@.clarkdev.com> wrote in message
news:d7740507.0407100710.2b1644b5@.posting.google.com...
> Basically, I'm after two answers in this scenario:
> - Is there a benefit to having a clustered index on a table when the
> application doesn't 'really' call for one?
In my opinion, there is never a reason NOT to have one; it's a freebie,
basically, unlike clustered indexes. It doesn't take up any extra disc
space, and you might as well order the data on the disc somehow, rather than
letting the server take care of it... So I always make sure that every table
has one.

> - If so, is it better to add an IDENTITY column (adding size to the
> table) or to pick an naturally ordered dimension key? A random key?
> The fact's composite key?
Some tips for clustered indexes:
- They assist with range queries and grouping. So try to use them for
columns that will be used for those kinds of operations (>, <, BETWEEN, etc,
or make it composite in the same order that you'll be grouping. If you do
composite, order the columns by selectivity, least selective first. This
will create a wider tree, which will result in somewhat quicker grouping.)
- Clustering on a random key is a very bad idea, because it will cause a
lot of page splits, leading to fragmentation. This will slow your data
loads. It will also give you no query benefits at all. So you'll actually
lose on this option.
- Clustering on an IDENTITY key or a DATETIME column that's
automatically set to the date the row is inserted will actually speed up
inserts as it will create a hotspot at the end of the table. So you'll
never have page splits when inserting new data. This can definitely help
speed your data load! Clustering on an IDENTITY will usually not help too
much with queries as, in my experience, most grouping and range operations
don't consider surrogates. Depending on your app, clustering on a DATETIME
as I described can help a lot, as a lot of queries will request data between
two dates, greater than a date, etc.
- Finally, clustering on the composite of your dimensions may be helpful
if you're grouping on them or requesting ranges. However, in the latter
case, remember that a composite index will only be used for searching if the
first column is part of the search criteria, so try to choose one of your
dimensions that will always be searched on (if that exists in your
warehouse).
I hope that answered your questions? Post back if you need some
clarification or further assistance.|||> It doesn't take up any extra disc space,
That's not true. The clustered index uses the datapages as the leaves, so
that is disk space you use already anyway, but the nodes of the index still
take up extra space on disk. That doesn't mean btw that it is not a good
idea to have a clustered index on every table. In almost all cases the
performance improvement that a clustered index provides more than offsets
the extra disk space used.
Jacco Schalkwijk
SQL Server MVP
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23rDxElvZEHA.2388@.TK2MSFTNGP11.phx.gbl...
> "Steven Clark" <stevec@.clarkdev.com> wrote in message
> news:d7740507.0407100710.2b1644b5@.posting.google.com...
> In my opinion, there is never a reason NOT to have one; it's a
freebie,
> basically, unlike clustered indexes. It doesn't take up any extra disc
> space, and you might as well order the data on the disc somehow, rather
than
> letting the server take care of it... So I always make sure that every
table
> has one.
>
> Some tips for clustered indexes:
> - They assist with range queries and grouping. So try to use them for
> columns that will be used for those kinds of operations (>, <, BETWEEN,
etc,
> or make it composite in the same order that you'll be grouping. If you do
> composite, order the columns by selectivity, least selective first. This
> will create a wider tree, which will result in somewhat quicker grouping.)
> - Clustering on a random key is a very bad idea, because it will cause
a
> lot of page splits, leading to fragmentation. This will slow your data
> loads. It will also give you no query benefits at all. So you'll
actually
> lose on this option.
> - Clustering on an IDENTITY key or a DATETIME column that's
> automatically set to the date the row is inserted will actually speed up
> inserts as it will create a hotspot at the end of the table. So you'll
> never have page splits when inserting new data. This can definitely help
> speed your data load! Clustering on an IDENTITY will usually not help too
> much with queries as, in my experience, most grouping and range operations
> don't consider surrogates. Depending on your app, clustering on a
DATETIME
> as I described can help a lot, as a lot of queries will request data
between
> two dates, greater than a date, etc.
> - Finally, clustering on the composite of your dimensions may be
helpful
> if you're grouping on them or requesting ranges. However, in the latter
> case, remember that a composite index will only be used for searching if
the
> first column is part of the search criteria, so try to choose one of your
> dimensions that will always be searched on (if that exists in your
> warehouse).
> I hope that answered your questions? Post back if you need some
> clarification or further assistance.
>
>|||"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid> wrote
in message news:%23cIz3GDaEHA.2544@.TK2MSFTNGP10.phx.gbl...
> That's not true. The clustered index uses the datapages as the leaves, so
> that is disk space you use already anyway, but the nodes of the index
still
> take up extra space on disk. That doesn't mean btw that it is not a good
> idea to have a clustered index on every table. In almost all cases the
> performance improvement that a clustered index provides more than offsets
> the extra disk space used.
Thanks for the clarification on that... I also didn't think about fill
factor, which could also create the impression of more disc space being
used.