|
|
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
Как проверить блокировки (MSSQL-6.5)? Количество блокировок в sp_configure =1000000 нормально ли это ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2002, 07:48 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
sp_lock. Думаю, что очень больших баз на 65 не осталось, поэтому рекомендовал бы 1 нолик убрать. Во всяком случае, у меня несколько месяцев 100000 стояло. Проблем не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2002, 09:08 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
я ВХОЖУ ПОД DBO ПЫТАЮСЬ УДАЛИТЬ ЗАПИСЬ ИЗ ТАБЛИЦЫ А В ИТОГЕ "LOCK TIME OUT" НЕ МОЖЕТ ЛИ ТАБЛИЦА САМА ЗАБЛОКИРОВАТЬСЯ ПОТОМУ ЧТО ДРУГИХ ЮЗЕРОВ В КАРЕНТ АКТИВИТИ НЕТ ПАРАДОКС ИЛИ СБОЙ В НАСТРОЙКАХ СЕРВЕРА КОРОЧЕ Я ПОНЯЛ ЧТО Я НЕ МОГУ ЗАБЛОКИРОВАТЬ ТАБЛИЦУ В НЕЙ 1700000 ЗАПИСЕЙ МОЖЕТ ЭТО МНОГО ЧТО ДЕЛАТЬ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2002, 09:29 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
Customizing the Lock Time-out When Microsoft® SQL Server™ 2000 cannot grant a lock to a transaction on a resource because another transaction already owns a conflicting lock on that resource, the first transaction becomes blocked waiting on that resource. If this causes a deadlock, SQL Server terminates one of the participating transactions (with no time-out involved). If there is no deadlock, the transaction requesting the lock is blocked until the other transaction releases the lock. By default, there is no mandatory time-out period, and no way to test if a resource is locked before locking it, except to attempt to access the data (and potentially get blocked indefinitely). Note The sp_who system stored procedure can be used to determine if a process is being blocked, and who is blocking it. The LOCK_TIMEOUT setting allows an application to set a maximum time that a statement waits on a blocked resource. When a statement has waited longer than the LOCK_TIMEOUT setting, the blocked statement is canceled automatically, and error message 1222 "Lock request time-out period exceeded" is returned to the application. However, any transaction containing the statement is not rolled back or canceled by SQL Server. Therefore, the application must have an error handler that can trap error message 1222. If an application does not trap the error, it can proceed unaware that an individual statement within a transaction has been canceled, and errors can occur because statements later in the transaction may depend on the statement that was never executed. Implementing an error handler that traps error message 1222 allows an application to handle the time-out situation and take remedial action for example, automatically resubmitting the statement that was blocked, or rolling back the entire transaction. To determine the current LOCK_TIMEOUT setting, execute the @@LOCK_TIMEOUT function, for example: DECLARE @Timeout int SELECT @Timeout = @@lock_timeout SELECT @Timeout GO See Also @@LOCK_TIMEOUT SET LOCK_TIMEOUT sp_who Handling Errors and Messages Ну а что трассировка дала? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2002, 03:50 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
При удалении появляется левый запрос типа SELECT Count(Coupon_Number) FROM Coupons where Series_ID=NULL and Coupon_Number between NULL and NULL и этот запрос блокирует DELETE откуда он взялся ума не дам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2002, 04:53 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
А функции @@Lock_Timeout в 6,5 нет более того (как многие советуют sp_who или sp_who2)ничего не кажет в полях blkby или blk ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2002, 05:03 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
Трасе ничего не дал вот данные фильтра после выполнения запроса -- 22.05.02 14:42:33,296 SQL (ID=657, SPID=98, User=Dima(SONAR\dima), App='Outlay Invoice', Host='DIMA_NT'(38dd) ) SELECT Count(Coupon_Number) FROM Coupons where Series_ID=NULL and Coupon_Number between NULL and NULL go -- 22.05.02 14:42:33,356 SQL (ID=657, SPID=98, User=Dima(SONAR\dima), App='Outlay Invoice', Host='DIMA_NT'(38dd) ) DELETE FROM OutLay_Specification WHERE OutLay_ID=174746 AND Invoice_ID=136879 AND Company_ID=0 AND BASIS_ID=44 AND ASCoupon=0 AND SELLUNIT=1 AND Product_ID=5 go -- 22.05.02 14:47:33,500 SQL (ID=657, SPID=98, User=Dima(SONAR\dima), App='Outlay Invoice', Host='DIMA_NT'(38dd) ) DELETE FROM OutLay_Specification WHERE OutLay_ID=174746 AND Invoice_ID=136879 AND Company_ID=0 AND BASIS_ID=44 AND ASCoupon=0 AND SELLUNIT=1 AND Product_ID=5 go ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2002, 08:08 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
> При удалении появляется левый запрос Вообще-то AFAIK "левые запросы" сами не появляются, тем более на основе юзерских таблиц. Триггеры проверь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2002, 08:52 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
Запрос этот оказывается нормально выполняется SELECT Count(Coupon_Number) FROM Coupons where Series_ID=NULL and Coupon_Number between NULL and NULL это я сужу по след строке -- 22.05.02 16:34:24,153 SQL (ID=876, SPID=122, User=Dima(SONAR\dima), App='Outlay Invoice', Host='DIMA_NT'(38e0) ) SELECT Count(Coupon_Number) FROM Coupons where Series_ID=NULL and Coupon_Number between NULL and NULL go -- 22.05.02 16:34:24,170 Duration 0,016, CPU 0,000, Reads 1, Writes 0 а вот этот совсем плохой судя по Duration -- 22.05.02 16:34:24,170 SQL (ID=876, SPID=122, User=Dima(SONAR\dima), App='Outlay Invoice', Host='DIMA_NT'(38e0) ) DELETE FROM OutLay_Specification WHERE OutLay_ID=174746 AND Invoice_ID=136879 AND Company_ID=0 AND BASIS_ID=44 AND ASCoupon=0 AND SELLUNIT=1 AND Product_ID=5 go -- 22.05.02 16:39:24,183 Duration 300,013, CPU 1,125, Reads 23463, Writes 0 вешаюсь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2002, 09:42 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
1.Попробуйте удалять не из вашего приложения "App='Outlay Invoice'" а из QA. В trace видно ведь, что именно ваше приложение генерит "злобный" селект, а не триггер. 2.Посмотрите внимательно на этот селект. Вам ничего не говорит такая штука как [singleton fetch of nonexistent data] и эскалация блокировок до уровня таблицы либо key range? Сервер мог запросто блоконуть всю таблицу либо хорощий ее кусок в результате выполнения SELECT Count(Coupon_Number) FROM Coupons where Series_ID=NULL and Coupon_Number between NULL and NULL аккурат перед делитом. Вот такие соображения. удачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2002, 15:29 |
|
||
|
|

start [/forum/topic.php?fid=46&gotonew=1&tid=1822633]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
178ms |
get topic data: |
11ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 489ms |

| 0 / 0 |
