Вы не только читаете но и пишите(into #rep1_tmp_pay from rep_pay t1). А грязная запись запрещена! Но можно сделать курсор с transaction isolation level 0 и в нем инсертить данные в вашу таблицу!

Гость123456За совет спасибо, только это делается для повыщения производительности, а использование курсора явно не ускорит работу ХП.
А по поводу записи не понимаю почему не делать выборку на 0 уровне изоляции, а потом уже вставку на 1 ?

http://www.sql.ru/forum/actualthread.aspx?tid=504419
дочитайте до конца там все рассказано!

А почему вы считаете что курсоры сильно тормозят? Я например токого не замечал.

MasterZivВот это странно. По идее, не должна.

Странно что блокируется? Почему странно?

По моему при SELECT...INTO или при INSERT...SELECT выставляется шаре блокировка на все таблицы во from(даже при isol.level 0).

MasterZivА источник такой уверенности в чём ?

только экспериментально! правдо таблицы все были APL. На DOL может ситуация другая будет, не проверял.

А вы считаете что должна блокироваться только "rep_pay", а та что в джойне(contract_agents) не должна?

Я выше писал ссылку, там вы и moris подробно расказываете почему это сделать нельзя!

http://www.sql.ru/forum/actualthread.aspx?tid=504419

MasterZivmoris wrote:

Согласен, что штука не очень нужная, но
однако

> Т.к. согласно SQL92 требуется такая блокировка
>
> SQL-92 recognizes that the execution of
> queries is dependant on the metadata of the tables involved, and requires
> that access to such metadata must be serializable, even if the level of
> isolation for the data is set to a lower level of isolation

из этого не следует, что надо накладывать блокировку на саму
таблицу. Можно наложить строчную блокировку на строку в
sysobjects. Но sysobjects у нас - LOCK ALL PAGES, только в
последнее время перевелись системные таблицы на DATAROWS.
Так что вот и понятно, откуда ноги фичи растут. Вместо того,
чтобы делать SHARED LOCK на страницу в sysobjects они (SI)
предпочли делать SHARED TABLE на саму таблицу, поскольку
такая блокировка меньше кому мешает. (SHARED LOCK на странице
sysobjects мог бы мешать изменениям других таблиц, чьи строки
лежали бы на этой же странице).

Кстити можно предположить, что и в MSSQLServer не так все
хорошо с этим, потому что как у них там что блокируется,
никто не знает, все на откуп решениям сервера. Так что вполне
может быть что это будет когда работать, а когда и нет.

Интересно еще, будет ли выставляться шаре-блокировка на DOL таблице если по ней бежит курсор с уровнем изоляции 1?

MasterZiv
cherrex_Den пишет:
> Интересно еще, будет ли выставляться шаре-блокировка на DOL таблице если
> по ней бежит курсор с уровнем изоляции 1?

На всей таблице ? На строках - точно будут.


выставляется sh_intent, это построчная блокировка?

а для чего он вообще выставляет? таблица же DOL, select же не выставляет!

Блокировка выставляется(sh_intent), но инсерты и апдэйты проходят!
Так sh_intent(блокировка занятости) не блокирует данные?

MasterZiv
cherrex_Den пишет:

> выставляется sh_intent, это построчная блокировка?
>

Так и такая, и такая есть.

> а для чего он вообще выставляет? таблица же DOL, select же не выставляет!

вы это с чего взяли ? я если ещё не совсем всё позабыл, выставляет.
Как он может не выставлять sh_row, если это read committed ?


На DOL таблицах выставлять не должен, если не взведен read committed with lock!

perf1ru.pdfЗапросы с оператором select к таблицам с блокировкой только данных
сначала устанавливают на таблицу разделяемую блокировку занятости.
Блокировку страниц и строк данных можно настроить с помощью пара-
метра read committed with lock следующим образом:
• Если параметр read committed with lock равен 0 (значение по умолча-
нию), то запросы с оператором select считывают значения столбцов,
устанавливая мгновенные блокировки страниц и строк. Нужные зна-
чения столбца или указатели на строку считываются в память, и бло-
кировка снимается. Во время просмотра строк из внутренних таблиц
соединений блокировки на внешние таблицы не устанавливаются.
Это уменьшает число взаимоблокировок и повышает эффективность
одновременных операций с базой данных.
Даже если запросу с оператором select нужно только прочитать стро-
ку, заблокированную блокировкой несовместимого типа, он все рав-
но приостанавливается на этой строке до снятия этой блокировки.
Если задать параметру read committed with lock значение 0, это не по-
влияет на уровень изоляции; возвращаются только зафиксированные
строки.
• Если параметр read committed with lock равен 1, то запросы с операто-
ром select устанавливают разделяемые блокировки страниц в табли-
цах с блокировкой страниц данных и разделяемые блокировки строк
в таблицах с блокировкой строк данных. Сначала устанавливается
блокировка первой страницы или строки, затем – блокировка второй
страницы или строки, а блокировка первой страницы или строки
снимается.

под мгновенной блокировкой - я думаю понимается защелки(latches)

MasterZivcherrex_Den пишет:
> Блокировка выставляется(sh_intent), но инсерты и апдэйты проходят!
> Так sh_intent(блокировка занятости) не блокирует данные?

На каком уровне ?

sh_intent -- это НЕ блокировка занятости. Это вспомогательная
блокировка, которая говорит о том, что данная транзакция СОБИРАЕТСЯ,
то есть будет накладывать shared блокировку на что -то.
Она сама по себе нужна только чтобы снизить deadlock-ки.

Уровень 1! А в русском переводе intent называют блокировкой занятости.

P.S. perf1ru.pdf - это переведенная ptg

Да на счет intent погорячился!!! она выставляется в любом случае. а шаре-строк или шаре-страниц не выставляется при select(на уровне 1 и на DOL)

Чтоб вас не запутать:
монопольная-эксклюзивная
разделяемая-шаре

MasterZivДа нет, на уровне чего : таблицы, строки/страницы ?

строки/страницы конечно!