July 29, 2003 at 12:25 am
Hi!
Just not sure how to read such information:
2:1:64247
TAB: 11:743738498 [[COMPILE]]
PAG: 7:1:26323
11:1:889440
Thanks.
July 29, 2003 at 4:58 am
Ok here we go.
quote:
2:1:64247
2 is the database id (compare it with dbid)
1 is the filegroup (so in this case I know it is primary since that is the first filegroup)
64247 is the page number that is locked in some way.
quote:
PAG: 7:1:26323
Same as previos except it specifically is lock the page (Represented by PAG).
and lastly
quote:
TAB: 11:743738498 [[COMPILE]]
TAB of course is a table lock.
11 is the database id
743738498 is the object id.
But here is the kicker. I bet the object is actually a Stored Procedure instead of a table. The reason is this
[[COMPILE]]
means the object is being compiled currently for run. And a couple of possiblities are you have the WITH RECOMPILE statement in it, the name starts with sp_, first run since last reboot, or there was a cache miss.
A bit on this from MS
July 29, 2003 at 5:23 am
quote:
64247 is the page number that is locked in some way.
Is it possible somehow, to figure out the table name (or ID), this page belongs to?
This one is index lock?
KEY: 11:78636069:1 (d200b6f90cfb)
KEY is index lock
11 is the database id
78636069 is the object id.
(d200b6f90cfb) is index id
Right?
July 29, 2003 at 6:27 am
You could try but you really have to know your data to have a clue.
Do
SELECT db_name(dbidvalue)
to get the database name. Then do
DBCC TRACEON(3604)
GO
DBCC PAGE('dbnamehere',filegroup,pagenumber,3)
The output is the page data itself (3 is one option and the easiest to read) but again you have to know you data and table structures to have an idea.
Beyond that the answer is no.
July 31, 2003 at 5:23 am
Found another one:
DB: 17 [BULK-OP-LOG]
Happens quite often. Is it critical?
July 31, 2003 at 5:37 am
quote:
DB: 17 [BULK-OP-LOG]
DB = Database
17 = is the database id which you can find out which by - SELECT db_name(17)
[BULK-OP-LOG] = Sounds like you have a bulk operation occurring such as a bcp or bulk insert and you database is set to BULK_LOGGED recovery model so that it records them to the transaction log.
As for importance it depedns on if you want bulk transactions logged or not. Of course they add performance hits on the servers IO the more that is logged but conversely if something failed can you live without the logging provided by the TL for recovery since last backup (as long as TL is not damaged by issue that is).
July 31, 2003 at 6:25 am
All my databases have full recovery model.
Just figured this out: this happens when full or diff backup are run at the same time as log backup.
July 31, 2003 at 6:48 am
Sorry the short name looks odd but found
quote:
DB:db_id[BULK-OP-LOG], which identifies the lock taken by the backup log for that particular database.
Taken from "Troubleshooting Deadlocks" in SQL BOL which covers some others as well.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply