We are having response problems. This is on a test machine.
But we would still like to examine the problem and prevent the
same problem on a production machine.
The situation is a simple table (only three columns, which hardly
contains data, if the data goes to a few hundred rows the problems
starts. If the table is cleared of the rows there is no problem with the
coding.).
I am looking in the locks, there are four processes holding
locks on that database. Three processes only have
a DB (S) lock. (And are 'sleeping').
The fourth process holds 7 locks
This proces is doing a single insert on a table.
The locks :
1 DB (S) lock
2 DB called [BULK-OP-DB] (NULL)
3 DB called [BULK-OP-LOG] (NULL)
4 KEY lock (X) (The table a insert is done upon)
5 TAB lock (IX) (The table a insert is done upon)
6 PAG lock (IX) (The table a insert is done upon)
7 FIL (U) lock
All locks have been granted
What is the [BULK-OP-DB] and [BULK-OP-LOG] exactly, why does the
process become awfully slow ? Is this the cause ?
Any pointers ?
(SQL-server 2000 / simple recovery mode).
ben brugman.While this is an old post, this happened to me as well, so here's what
happened and how it was fixed.
To summarize, the database was set to auto growth. The [BULK-OP-DB]
(NULL) is the type of lock that is used during file growth (auto or
otherwise). The growth process expanded the size of the database, but
did not finish for some reason. The fix was to force the growth to
happend again by expanding the size of the database in EM (in the
database properties).
You will know if you have this issue if you go to EM, go to the shrink
database option, and look at the file size. This number should match
the size reported by looking at the size of the file in Windows
Explorer. In our case, the number was off by 10%, which was the auto
growth rate.
Also, in case this doesn't fit your situation, here are the uses for
that type of lock (from an MS support rep). Step through the lock you
have and, if possible, retry them to force the lock to clear:
If the BULK-OP-DB lock is
1. LCK_M_X (exclusive):- cause may be database or file backup,
incremental
db backup, or dbcc checkalloc/dbcc checkdb
2. LCK_M_S (shared):- cause may be index creation, text modification
operations, or nonlogged bulk insert/bcp/select into
3. LCK_M_U (update):- cause may be filegroup creation, shrink
file/shrink
database, drop file, or add file
4. LCK_M_NL (NULL):- cause may be modify file, auto grow file, or tran
log
backup/truncation
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment