The following queries disclose any bad sysdatabases or sysusages rows leading to problems 2 and 3 above. Run these queries in the order given, since this makes it easier to interpret returns from the last query in the set.
This query discloses overlapping sysusages rows, which you should delete:
select u1.dbid, u1.lstart, u1.size, u1.vstart from sysusages u1, sysusages u2 where u1.dbid = u2.dbid and u1.lstart > u2.lstart and u1.lstart < (u2.lstart + u2.size) and not exists (select 1 from sysusages u3 where u3.dbid = u1.dbid and u1.lstart = u3.lstart + u3.size)
Any row returned by this query falls within the range of another entry for the same database. Such an entry is suspect; remove it.
This query may fail to disclose all problem
rows for a given database. This happens because removing the first
such row may uncover another row whose lstart matched
the earlier problem row’s lstart+size.
Remove the first sysusages row named in the
query’s result set, then run the query again; continue
until it returns no rows.
2. This query shows sysusages rows not belonging to any database:
select * from sysusages u where not exists (select 1 from sysdatabases d where d.dbid = u.dbid)
If such rows exist, either:
They belong to a previously dropped database and you should remove them, or
You need to reinitialize another disk and rerun disk refit.
This query discloses gaps in a database’s logical page numbering. It also discloses rows covered by queries 1 and 2, so you should ensure that those queries return no rows before attempting this query:
select * from sysusages u1 where lstart != 0 and not exists (select 1 from sysusages u2 where u2.dbid = u1.dbid and u1.lstart = u2.lstart + u2.size)
This query shows that sysusages entries are missing from the database whose dbid appears in the result set. This has the same two possible causes, and the same fixes, as rows in query 2.
