powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / Помогите с бокировками
30 сообщений из 30, показаны все 2 страниц
Помогите с бокировками
    #33628827
yourij_mw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Немногим раньше я открыл топик "Ищу инструмент мониторинга производительности ASE-12.5", в частности меня интересовал мониторинг блокировок. Но теперь пришёл к тому что такие средства для меня мало полезны, пока не умею минимизировать такие блокировки в конкретном случае. Привожу пример.
Мы используем табличку KeyPool - пока не взять из нее ID, создать новую запись в 99% других табличек незя. Вот ее определенние
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
create table KeyPoolNew (
	ID_KeyPool                      ID                               not null  ,
	ID_Location                     ID                               not null  ,
	NameTable                       varchar( 30 )                      not null  ,
	Value                           ID                                   null  ,
	ValueMax                        ID                                   null  ,
		CONSTRAINT PK_KeyPool PRIMARY KEY CLUSTERED ( ID_KeyPool )  on 'default' 
)
lock datarows
 on 'default'

используем ее посредством процедуры аналогичной ниже нарисованной (приведённый пример упрощён и тоже не работает потому и подходит для примера )
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
CREATE PROCEDURE nkp_NewID
	 @idkp int,
     @TableName varchar( 30 ) = null,  
     @LocationID int = null,  
     @NID int output as  
BEGIN   
    DECLARE @CNT INTEGER 
    DECLARE @MinID INTEGER, @vm integer 
    DECLARE @ID_KeyPool INTEGER 
 
    SELECT @NID=Value, @vm = ValueMax 
    FROM KeyPoolNew (index PK_KeyPool)
    WHERE ID_KeyPool = @idkp
    
    
 
    UPDATE KeyPoolNew SET Value=Value+ 1  from Keypoolnew (index PK_KeyPool)
    WHERE ID_KeyPool=@idkp
    
  /*  if @NID = @vm 
    delete from KeyPoolNew (index PK_KeyPool) 
    where ID_KeyPool = @idkp */
    
END


как видно у таблички установлена схема блокировки на уровне строк, select и Update в условии отбора используется только поле ID_KeyPool которое является ключом и есть индексированным., что по моему должно было позволить устанавливать блокировку только на уровне строк. "(index PK_KeyPool)" писал специально потому что оптимизатор выбирал почему-то сканирование таблицы, а не индекса.
Пока не главный вопрос - почему в конструкции Delete (которая закоментаренная) выражение "(index PK_KeyPool)" считалось не позволительным и сервер ее не хотел сохранять (потому я и закоментарил )?
Теперь когда я в одном сеансе зпускаю транзакцию и не завершаю ее
Код: plaintext
1.
begin tran sss
exec nkp_newID  1 ,NULL,NULL,@m output

другая, аналогичная транзакция, только другой ID_keyPool (к примеру 25 )
Код: plaintext
1.
begin tran sss
exec nkp_newID  25 ,NULL,NULL,@m output
виснет и ждёт завершения первой.
Вот результат sp_lock:
Код: plaintext
1.
2.
3.
4.
fid	spid	loid	locktype	table_id	page	row	dbname	class	context
 0 	 13 	 26 	Ex_intent	 1113104025 	 0 	 0 	keeper	Non Cursor Lock               	 
 0 	 13 	 26 	Ex_row-blk	 1113104025 	 6752 	 0 	keeper	Non Cursor Lock               	 
 0 	 14 	 28 	Sh_intent	 1113104025 	 0 	 0 	keeper	Non Cursor Lock               	 
 0 	 15 	 30 	Sh_intent	 32000114 	 0 	 0 	master	Non Cursor Lock


Почемe же так? Разве при блокироке на уровне строк нельзя изменять одновременно разные записи в разных транзакциях?
Можно ли сделать так чтоб таких блокировок не возникало. Надеюсь на вашу помощь.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33628847
yourij_mw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да... вот вам на всякий случай showplan
declare @s ID
begin tran fff
exec nID 25,NULL, NULL,@s output

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
------------------------ Execute ------------------------

QUERY PLAN FOR STATEMENT  1  (at line  1 ).


    STEP  1 
        The type of query is DECLARE.


QUERY PLAN FOR STATEMENT  2  (at line  2 ).


    STEP  1 
        The type of query is BEGIN TRANSACTION.


QUERY PLAN FOR STATEMENT  3  (at line  3 ).


    STEP  1 
        The type of query is EXECUTE.


QUERY PLAN FOR STATEMENT  1  (at line  0 ).


    STEP  1 
        The type of query is DECLARE.


QUERY PLAN FOR STATEMENT  2  (at line  11 ).


    STEP  1 
        The type of query is SELECT.

        FROM TABLE
            KeyPoolNew
        Nested iteration.
        Using Clustered Index.
        Index : PK_KeyPool
        Forward scan.
        Positioning at index start.
        Using I/O Size  2  Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size  2  Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.


QUERY PLAN FOR STATEMENT  3  (at line  17 ).


    STEP  1 
        The type of query is UPDATE.
        The update mode is direct.

        FROM TABLE
            KeyPoolNew
        Nested iteration.
        Using Clustered Index.
        Index : PK_KeyPool
        Forward scan.
        Positioning at index start.
        Using I/O Size  2  Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size  2  Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            KeyPoolNew
        Using I/O Size  2  Kbytes for data pages.

return status =  0 
( 1  rows affected)
------------------------- Done --------------------------
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33629098
Фотография Dmitry.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Опишу ситуацию которая была у нас и как ее решили.
таблица по генерации ключей.
Код: plaintext
1.
2.
3.
4.
create table PKgen(
    tablename char( 30 ) not null,
    id numeric( 15 ) not null,
    constraint pk_PKgen primary key clustered ( tablename )
)lock datarows

обработка:
Код: plaintext
update PKgen set id=id+ 1  where tablename=@tname

при большой нагрузке на одну таблицу все друг друга блокировали.

переделали:
Код: plaintext
1.
2.
3.
4.
create table PKgen(
    tablename char( 30 ) not null,
    id numeric( 15 ) not null,
    constraint pk_PKgen primary key clustered ( tablename, id )
)lock datarows
обработка :
Код: plaintext
1.
2.
3.
set transaction isolation level  0 
insert into PKgen 
select @tname, max(id)+ 1  from PKgen 
where tablename=@tname

казалось-бы только вставка - проблем быть не должно.
все равно блокировка!

и только когда убрали primary key , все заработало.
(блокировок нет)

Код: plaintext
1.
2.
3.
4.
create table PKgen(
    tablename char( 30 ) not null,
    id numeric( 15 ) not null,
    constraint uk_PKgen unique nonclustered ( tablename, id )
)lock datarows
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33629509
yourij_mw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за предложение.
Для меня проблема несколько глобальнее чем табличка KeyPool. Если я переделаю KeyPool
и допусим заработает, то как быть во многих других случаях - искать какие-то новые разнообразные решения ?
Проблема в том что я немогу понять как работают блокировки. И я буду даже больше рад если сможет кто подсказать почему не правильно, а не как праильно.
Вроде по документации блокировка на уровне строк в приведённом мною примере должна обеспечиватся т.к. идёт сканирование только индекса, так почему-же чёрт подери....
Ткните носом меня куда следует, или хотя-бы успокйте, а то чуствую что меня начнётся стрес.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33629851
Alexandr Kapustin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, по плану запроса сразу же видно, что у вас не index seek, который позиционируется сразу на запись, а Index scan, который сканирует всю таблицу, и как только встречает заблокированную запись, останавливается и ждет...

Почему это происходит - а что у вас за пользовательский тип ID?
Есть у меня подозрения, что если вы в процедуре
@idkp int,
замените на
@idkp ID,

то ситуация изменится к лучшему...

Еще хочу заметить, что такая технология чревата bottleneck'ом, я просто уже столько накушался от такой схемы...
Если будет желание, то по аське могу рассказать, что да как...

--
WBR, Alexandr
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33630047
yourij_mw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну мужик...не буду многословным ... сам знаеш от чего ты меня спас жил бы в Москве, сам бы нашёл и пиво поставил.
Зраработало. А на счёт схемы нашей то скажу што пока мы и не сильно старались ее совершенствовать пока программа в стадии доработки С нашей программой не работало много пользователей и всё внимания мы приделяли на доработку функциональности, а не производительности. Например я думаю што можна сократить узкое место если для одной таблицы будут соответсвовать несколько записей в кейпуле например 5, а нужный ID_keyPool выбирался бы из другой таблички в зависимосты от остачи деления @@spid на 5, и названия таблички и номера подразделения. Таки образом грубо говоря в 5 раз можно уменьшить долю изменяемых записей процедурой в табличке КейПул Так как 5 раз увеличится общее число ее записей, В всяком сулчае про Ваше предложение не збуду..., постучусь как небудь
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33630089
Alexandr Kapustin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А необходимости массовых вставок в такие таблицы еще не было?
Это раз...
Второе - система двузвенка или трех? Если трех, то лучше всего вынести работу с этой таблицей в отдельный поток и тем более отдельную транзакцию...
Если двух, то тут дело гораздо сложнее и тяжелее... При больших количествах вставок в одну и ту же таблицу по-любому будут блокировки, особенно если бизнес-транзакции длинные... Придется крутиться по-любому...

--
WBR, Alexandr
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33630161
Alexandr Kapustin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И еще, не знаю как в оригинальной версии процедуры, но приведенная версия в случае если два коннекта почти одновременно запустят эту процедуру, то они получат одинаковый @NID для одного @idkp... Что есть нехорошо...

--
WBR, Alexandr
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33630218
Dim2000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yourij_mw wrote:

> старались ее совершенствовать пока программа в стадии доработки С нашей
> программой не работало много пользователей и всё внимания мы приделяли
> на доработку функциональности, а не производительности.

А чем не устроил автоинкремент? Это самый быстрый вариант.
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33631416
yourij_mw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Автоинкремент использовать было бы проблемно т.к. используэм АСЕ и система должна использоватся в репликации
Alexandr KapustinА необходимости массовых вставок в такие таблицы еще не было?
Это раз...
Второе - система двузвенка или трех? Если трех, то лучше всего вынести работу с этой таблицей в отдельный поток и тем более отдельную транзакцию...
Если двух, то тут дело гораздо сложнее и тяжелее... При больших количествах вставок в одну и ту же таблицу по-любому будут блокировки, особенно если бизнес-транзакции длинные... Придется крутиться по-любому...

--
WBR, Alexandr
..если имелось ввиду используем ли мы сервер приложений - то нет.
Ну, а на счёт Ваших замечаний, то если обладаете каким либо надёжным и ефективным решением, то буду рад, если сможете как нибудь поделится. Можно создать новый топик или к Вам по аське?

Alexandr Kapustin
И еще, не знаю как в оригинальной версии процедуры, но приведенная версия в случае если два коннекта почти одновременно запустят эту процедуру, то они получат одинаковый @NID для одного @idkp... Что есть нехорошо...

..неужели реально может произойти? Пока не замечали чтобы такое случалось, но лучше испраить.
Наконец я задам вопрос не по теме: как можно выделять цититы такого стиля
"yourij_mw wrote:
> старались ее совершенствовать пока программа в стадии доработки..."
-есть комбинация клавиш?
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33631436
Dim2000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yourij_mw wrote:

> Автоинкремент использовать было бы проблемно т.к. используэм АСЕ и
> система должна использоватся в репликации

Это грустно, потому что Вы обречены на неубиваемое узкое место в системе.

> Наконец я задам вопрос не по теме: как можно выделять цититы такого стиля
> "yourij_mw wrote:
> > старались ее совершенствовать пока программа в стадии доработки..."
> -есть комбинация клавиш?

Если Вы вдруг не в курсе, то я читаю эху через ньюсридер ;). В
Thunderbird-е то, что Вы видите, получается автоматом.
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33631467
Crip
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для таблицы KeyPoolNew можно установить 1 запись на страницу и все будет пучком.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33632887
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Отказывайтесь от такой схемы генерации ключей в таблицах как можно скорее. Используйте вместо этого IDENTITY. По крайней мере в жестком OLTP такое неприменимо. Просто потому что в реальной жизни не будет работать. Один вставивший запись будет до конца транзакции держать всех.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33632911
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yourij_mw

Почемe же так? Разве при блокироке на уровне строк нельзя изменять одновременно разные записи в разных транзакциях?
Можно ли сделать так чтоб таких блокировок не возникало. Надеюсь на вашу помощь.



Такое может происходить только в случае эскалации блокировок до табличного уровня. Если у тебя таблица маленькая, и есть только общесерверные настройки эскалации , то это очень вероятно.

Посмотри настройку эскалации блокировок на этой таблице и настрой ее.
(sp_setrowlockpromote "database", pubs3, 1000, 1100, 45)

Не забудь, что настройки для APL/DPL и DRL разные.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33632918
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
То, что ты жалуешься на table scan этой таблицы, скорее всего, тоже следствие того, что таблица маленькая. Ее просто быстрее всосать целиком, чем читать через индекс.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33632933
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yourij_mwвиснет и ждёт завершения первой.
Вот результат sp_lock:
Код: plaintext
1.
2.
3.
4.
fid	spid	loid	locktype	table_id	page	row	dbname	class	context
 0 	 13 	 26 	Ex_intent	 1113104025 	 0 	 0 	keeper	Non Cursor Lock               	 
 0 	 13 	 26 	Ex_row-blk	 1113104025 	 6752 	 0 	keeper	Non Cursor Lock               	 
 0 	 14 	 28 	Sh_intent	 1113104025 	 0 	 0 	keeper	Non Cursor Lock               	 
 0 	 15 	 30 	Sh_intent	 32000114 	 0 	 0 	master	Non Cursor Lock




Я вот тут не вижу, что кто-то кого-то блокирует в результате sp_lock.
Странновато как-то. Эскалации не видно ...

Ты ничего там не нахимичил ? Перепутал может чего ?
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33632946
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry.Опишу ситуацию которая была у нас и как ее решили.
таблица по генерации ключей.


Тоже какая-то ерунда. Не может так быть. На DOL кластерный индекс на самом деле некластерный и таблица все равно HASH. Неблокируются на вставке записи вообще.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33632953
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexandr KapustinНу, по плану запроса сразу же видно, что у вас не index seek, который позиционируется сразу на запись, а Index scan, который сканирует всю таблицу, и как только встречает заблокированную запись, останавливается и ждет...


Это пофигу для блокировок. От способа доступа блокировки не зависят. На DOL по крайней мере...
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33632975
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yourij_mw
Вроде по документации блокировка на уровне строк в приведённом мною примере должна обеспечиватся т.к.


Должна, но я не могу понять, почему блокирует одна сессия другую.
Мало информации.
Поставь sp__wholock , попробуй с ним -- у него просто вывод понятнее.

yourij_mw
идёт сканирование только индекса, так почему-же чёрт подери....


Еще раз, как там у тебя что сканируется - все равно. От этого накладываемая блокировка не зависит.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33632998
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yourij_mwАвтоинкремент использовать было бы проблемно т.к. используэм АСЕ и система должна использоватся в репликации
[/quote]

А чем автоинкремент мешает репликации ?

[quot yourij_mw]
..неужели реально может произойти? Пока не замечали чтобы такое случалось, но лучше испраить.


Да, лучше бы сначала про -UPDATE -ить, а потом взять новое значение.
Можно кстати и в одном UPDATE-е это все сделать...
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33633298
Alexandr Kapustin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну почему блокируется - тут все понятно
1. Index scan + не все поля есть в индексе => нужно читать из самой таблицы

Ну там надо запись вообще-то UPDATE-ить между прочим.
Я не понимаю.

Index scan - latch-и на страницы индексов. На чтение.
нужно читать из самой таблицы - Shlock на строку записи. ДРУГОЙ записи.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33633395
Alexandr Kapustin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1-й запуск.
UPDATE KeyPoolNew SET Value=Value+1 from Keypoolnew (index PK_KeyPool)
WHERE ID_KeyPool=@idkp

Имеем X-блокировку на запись? Так?

2-й запуск (другой idkp)
SELECT @NID=Value, @vm = ValueMax
FROM KeyPoolNew (index PK_KeyPool)
WHERE ID_KeyPool = @idkp

При Index scan мы имеем перебор всех значений в таблице, и попытку наложить S-блокировку на запись, на которую держится X-блокировка первой процедурой (пока там транзакция не завершена)

Если бы поля Value, ValueMax были в индексе, то тогда для DOL-таблицы мы не имели бы таких проблем, т.к. он считал бы их из индекса, и не ждал бы никого...

Это я говорю про превоначальную ситуацию, дабы избежать недопонимания...

--
WBR, Alexandr
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33633531
yourij_mw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вмешаюсь чуть-чуть.. Проблема действительно была в процедуре изза несоответсвия типов.

Использовать такую схему генерации ИД в системе с репликацией по моему проще т.к. с одной базы можно легко управлять набором допустимых значений ключей для всех баз данных участвующих в репликации. Чтобы обеспечить уникальность ID во всей сети, достаточно обеспечить непересекание ключей в табличке KeyPool для одной и той же самой таблицы в центральной базе и распределять эту табличку (KeyPool ) между базами по их номеру (у нас ID_Location). я думаю узкие места можно немного расширить если для одного ID_Location и названия таблыцы будут соответствовать большее число записей.

вот пример процедуры

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
CREATE PROCEDURE nkp_NewID
	 @TableName varchar( 30 ),  
     @lid ID,   
     @NID ID output as  
BEGIN   
    DECLARE @CNT INTEGER 
    DECLARE @vm integer 
    DECLARE @ID_KeyPool ID 
 
    SELECT @NID=Value, @vm = ValueMax,@ID_KeyPool = ID_KeyPool  
    FROM KeyPoolNew (index tb_lc) readpast
    WHERE NameTable = @TableName and ID_location = @lid
    
    if @ID_KeyPool is NULL	begin 
    	waitfor delay '00:00:02'
		SELECT @NID=Value, @vm = ValueMax,@ID_KeyPool = ID_KeyPool  
		FROM KeyPoolNew (index tb_lc) readpast
		WHERE NameTable = @TableName and ID_location = @lid
	end
	if @ID_KeyPool is NULL	begin
		raiserror  27001  
		rollback
		return
	end
	UPDATE KeyPoolNew 
	SET Value = Value +  1  FROM KeyPoolNew 
	WHERE ID_KeyPool = @ID_KeyPool
	
	if @NID = @vm 
	delete KeyPoolNew 
	from KeyPoolNew (index PK_KeyPoolNew)
	where ID_KeyPool = @ID_KeyPool
 END
здесь как раз предполагается што записей больше одного и которые заблокированы пропускаются, с waitfor и повторной попыткой я может и перегнул -- возможно и вреда больше будет чем пользы.
Поменять Update и select местами у меня пока не получилось - и ну его ... если и возьмут одинаковые ID то пусть потом попробуют вставить вcтавить оба:)
Правда я склонен с Вами соглашатся на счёт того, что перспектива быть этому узкому месту в будущем велика. Если есть предложения других схем генрации ID повторюсь и скажу что буду рад если со мною кто поделится.
Но и на этом спасибо действительно очень помогли.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33633886
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexandr KapustinНу почему блокируется - тут все понятно
1. Index scan + не все поля есть в индексе => нужно читать из самой таблицы

Ну там надо запись вообще-то UPDATE-ить между прочим.
Я не понимаю.

Index scan - latch-и на страницы индексов. На чтение.
нужно читать из самой таблицы - Shlock на строку записи. ДРУГОЙ записи.

Это я что, не ту кнопку что ли нажал ? Извиняюсь сильно ...
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33633891
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexandr Kapustin1-й запуск.
UPDATE KeyPoolNew SET Value=Value+1 from Keypoolnew (index PK_KeyPool)
WHERE ID_KeyPool=@idkp

Имеем X-блокировку на запись? Так?


Так.

Alexandr Kapustin

2-й запуск (другой idkp)
SELECT @NID=Value, @vm = ValueMax
FROM KeyPoolNew (index PK_KeyPool)
WHERE ID_KeyPool = @idkp

При Index scan мы имеем перебор всех значений в таблице, и попытку наложить S-блокировку на запись, на которую держится X-блокировка первой процедурой (пока там транзакция не завершена)


Да какую же ShLock на запись ?
Для ID_KeyPool = @idkp значение есть в индексе, будет сканироваться индекс
даже и не по ключу. Но только за одной записью надо идти в
таблицу для получения
@NID=Value, @vm = ValueMax .
Вот на нее и надо ShLock.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33634047
Alexandr Kapustin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хм...
Я почему-то думал, что в случае, если ASE берет какие-то поля из индекса, он пишет, какие поля из индекса он использует... А в этом случае он не смог это сделать, т.к. типы различны...
Хотя теперь тоже понимаю, что возможно все не так просто, как мне думалось вначале :)
--
WBR, Alexandr
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33635511
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexandr Kapustin
Я почему-то думал, что в случае, если ASE берет какие-то поля из индекса, он пишет, какие поля из индекса он использует...


Где пишет ? В плане что ли ? В плане пишется только, если индекс покрывающий и вообще не надо читать таблицу.

Alexandr Kapustin
А в этом случае он не смог это сделать, т.к. типы различны...


Что ты привязался к типам ? Ну различны они, ну и что, как на блокировки-то влияет ?
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33635984
iLLer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Что ты привязался к типам ? Ну различны они, ну и что, как на блокировки-то влияет ?
Не знаю как в ASE, а в ASA очень даже может повлиять. Это прямо влияет на то, что к чему сервер будет приводить, то ли выражение к типу поля, то ли значение поля для каждой записи к типу выражения. В первом случае индекс будет использован, а во втором - нет, приведение типа это же фактически функция над данными, а индекс по функции - не тоже самое что индекс, по аргументу функции.
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33636346
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iLLer MasterZiv
Что ты привязался к типам ? Ну различны они, ну и что, как на блокировки-то влияет ?
Не знаю как в ASE, а в ASA очень даже может повлиять. Это прямо влияет на

Да как это все на накладываемые блокировки влияет ?
...
Рейтинг: 0 / 0
Помогите с бокировками
    #33636409
iLLer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Думаю так, если используется индекс, то блокируются только записи, которые подходят по индексу, если сканирование таблицы, то блокировка всей таблицы. И все это конечно же еще зависит от используемого уровня изоляции.
...
Рейтинг: 0 / 0
30 сообщений из 30, показаны все 2 страниц
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / Помогите с бокировками
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]