In this particular example, it is probably a transient error. Partition id (same as object id for tables with a single partition ) 8 is syslogs, which is typically a very active table. syslogs also uses a special bulk allocation method.
The object id on the page, -1, is used to indicate "unused".
If you do a dbcc page on that page now, the page has probably been used by syslogs and the page header will now show the ptnid and corresponding object name (presumably 8 and syslogs). In general, if you have a page number, you can get the object id and name from the dbcc page header output. If you have an object id / partition id, you can use the object_name() function to get the name.
set switch on 3604
go
dbcc page(<sid>, 14022685)
go
Example:
1> dbcc page(test,3934)
2> go
Page found in Cache: default data cache. Cachelet: 1
BUFFER:
Buffer header for buffer 0x10006057000
[...buffer output cut...]
PAGE HEADER:
Page header for page 0x10006056800
pageno=3934 nextpg=0 prevpg=0 ptnid=8 syslogs timestamp=0000 0000bbff
nextrno=27 level=0 indid=0 freeoff=1824 minlen=12
page status bits (pstat): 0x1 (0x0001 (PG_DATA))
DBCC execution completed. If DBCC printed error messages, contact a user with
System Administrator (SA) role.
Checkstorage works by quickly copying the page header (32 bytes) of each page into the workspaces in dbccdb and then doing analysis on the copied values. So dbccdb's size correlates to the size of the user database.
For large databases, dbcc checkdb and checkalloc are rarely practical.
I recommend finding the disk space for dbccdb.
Some sites do dump the database, load it on another server (non-production)
and run dbcc tests there.
-bret