У нас УТ 10.3, пользователей около 30, пока база крутилась на SQL ни разу не было проблем с блокировками таблиц, потом перевели базу в файловый вариант - постоянно возникали блокировки. Вопрос: SQL полностью исключает блокировки? И может ли кто то дать информацию о том как происходит чтение и запись данных при работе с SQL? Может есть какие то полезные ресурсы, где доступно об этом рассказано?

30 пользователей на файловой базе? мда..

Нет. Да. Да. www.sql.ru

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

(0)[SQL полностью исключает блокировки]
нет
да
да

P.S.

в твоей ситуации сиквел работает на порядок быстрее файловой и на блокировки ты не нарываешься

"Нет, сынок, это фантастика" =)

(0) Нет. Да. Да.

Главное отличие - в файловом режиме блокируются таблицы целиком, а на MS SQL - отдельные записи, см. таблицу из
http://v8.1c.ru/overview/datalockcontrol.htm

(6) неправильно

(7) + 1

(7) Что неправильно?

(9) в упр. режиме блокировки "в контексте 1С" волокет на себе сервер приложения 1С...

(9) а на MS SQL - отдельные записи

(9) блокируется диапазон записей: сама запись и следующая+предыдущая. а из прочтения можно сделать вывод что только та, которая записывается

(11) (12) Это уточнения.
Педанты.

(12) не помню точно где (кажется на Гилеве ру), читал, что при определенных обстоятельствах ( когда % блокируемых записей превышает какое- то значение ), то SQL блокирует всю таблицу.

Поправьте меня.

(10) Ну и где противоречия? (Кроме уточнения про диапазон записей вместо конкретных записей).

(14) да, при большом количестве блокировок скуль эсколирует блокировки на более высокий уровень

(15) противоречие в том что sp_lock абсолютно пофигу разные там "Новый БлокировкаДанных" и т.д.

(12) называется - эскалация блокировок

(14) Ну то, что SQL накладывает излишние блокировки, не новость.
Но это всяко лучше, чем всегда блокировать тупо всю таблицу, как в файловом режиме.

>Ну то, что SQL накладывает излишние блокировки, не новость.

бред...

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

(10) Автор спрашивал, а я отвечал про разницу в режимах "файловая база" / "серверная база на MS SQL". Кто конкретно ставит там блокировки для ситуации ТС несущественно.

(11)(12) "сама запись и следующая+предыдущая" блокируется даже для объектов? Это что-то новое, напишите об этом книгу.

(21) молодец! Уроки хорошо выучил.
А потом тебя добрым словом вспомнят читатели, когда на SQL у них блокировки полезут.

(20) И как 1С может рулить планом выполнения запроса?
Насколько я знаю, напрямую - ни как. Есть только общие рекомендации как следует писать запросы в 1С. Да и их строгое соблюдение не даёт гарантии, что план выполнения запроса будет оптимальным.

(23) ну а причем тут скуль как таковой? Он же не виноват что 1С лупит в него одинаковыми текстами запросов, слепленными по одному шаблону

Господа! Давайте будем объективны.
Предлагаю резюмировать:
В SQL версии блокировки существуют. Это факт. Компания 1С для борьбы с этим нарисовала несколько феничек. Например стала использовать управляемые блокировки, которые повышают уровень изоляции транзакции и тем самым снижают вероятность ее возникновения. Но они происходят. Замутили еще быструю обработку движений регистров. Прикольно, но если не запускать пересчет итогов, то на чтение они становятся толстыми.
Ну еще для получения остатков прикрутили рег. свободные остатки. Но это что бы хоть как то расшевелить УПП.
Если исключить "грязное чтение" , то избавиться от блокировок никак.

Кто против?

(25) Ща налетят уточняльщики :))

>>Но это что бы хоть как то расшевелить УПП

оригинально

>Например стала использовать управляемые блокировки, которые повышают уровень изоляции транзакции и тем самым снижают вероятность ее возникновения.

какие ваши доказательства? уровень изоляции на скуле остается один и тот же...

уровень изоляции и вид блокировки - как бы два разных человека...

(24) Да, но, если я правильно понял, то речь шла о том, что даже с кривыми запросами от 1С, скуль не станет блокировать таблицу целиком (кроме отдельных тяжелых случаев) в отличии от файловой версии, которая блокирует таблицы целиком вне зависимости от качества запросов, установленных режимов блокировки в конфе и т.п.

(25) уровень изоляции наоборот понижается. потому как выше уже некуда.

(28) Ну типа 1С сказала:

Режим управляемых блокировок

При работе в этом режиме система использует гораздо более низкий уровень изоляции транзакций для MS SQL Server и IBM DB2, и блокировку на уровне записей для PostgreSQL. Это позволяет достичь более высокой параллельности работы пользователей.

Наврали?

(21) а Вы думаете что для объектов нет кластерных индексов? пишите книгу. только авторство свое не надо ставить хотябы

(32) ничего глаз не режет?

При работе в этом режиме система использует гораздо более низкий уровень изоляции транзакций для MS SQL Server и IBM DB2, и блокировку на уровне записей для PostgreSQL. Это позволяет достичь более высокой параллельности работы пользователей.

Например стала использовать управляемые блокировки, которые повышают уровень изоляции транзакции и тем самым снижают вероятность ее возникновения.

опустили или подняли?

(34) Ааааа. Ну описался SuperMario.
Что вы в самом деле...

(35) он путает теплое и соленое.

(36) +100

(0) О ресурсах где сказано....На диске ИТС.
Есть  куча галок на конфе и собсна на регистрах призваных победить  блокировки на уровне сервера БД .  Есть цельный пласт прикладного ваяния под названием "упр.блокировки" не имеющие к серверу СУБД никакого отношения.

(38) в режиме управляемых блокировоко быдлокодер должен сам озаботится чистотой получаемых данных. накладывая блокировки на прикладные объекты. При этом от скуля сервер 1С требует уровень READ COMMITTED. А в режиме автоблокировок используется SERIALIZABLE

Забавно, прочитал тему, не вдумываясь особо. Получилось что-то вроде:

ТС: Раньше возили картошку грузовиком с поля, потом попробовали на себе таскать - что-то подзамучились.
Правда ли, что когда автомобилем возишь, вообще проблем нет? Что почитать?

...блабла...

Отвечающий1: блабла... Автомобилем проще, чем пешком, ибо он много больше зараз перевезти может (пруфлинк)
Отвечающий2: Никуя не так.
Отвечающий1: woot?
Отвечающие 2,3,4,N: Потому что бывает Камаз, а бывает ГАЗ, бывают хорошие водители, бывают похуже, а в пруфлинке вообще не сказано, что еще и прицеп можно прицепить!
И вообще, бывает водители выпивают (далее отвечающие начинают обсуждать качество водки, кожу сиденья в разных авто, степень влияния оных на водителей и грузчиков и тд и тп)

(40) >> качество водки, кожу сиденья в разных авто

Ты ни чего не понимаешь! Это всё очень важно!

(39) Вот я и говорю ... куча галок на конфе. Поставил галку одно , другое. Сплиттер потом в дело пойдет. А потом из этого огорода сухой остаток. И галки уроде все ... и управляемые блокировки как баааа и  индексы рассставлены как надо но что делать с прущим index scan вместо index seek (который должон быть по идее в результате ) никто не в курсе.

(40) аналогия неправильная. у машины автомат, а чувак думал механика, и через 50 метров - опять "на себе таскать".

Ничего не понял.
в (38) утверждает, что при управл. блокировках от сервера SQL ничего не зависит.
А (39) пишет, что 1С требует READ COMMITTED вместо SERIALIZABLE.

В (25) = я начитался в свое время инета, что бы для себя прояснить картину этих упр. блокировок.

Ну так что?  READ COMMITTED и SERIALIZABLE.
Это как бы не одно и тоже.

Или SQL сидит ровно и ему эти крыжики от сервера вообще параллельны?

(44) представь что сейчас происходит транзакция. Документ срет в регистр X по измерению Y.

Кто-то еще, например, пытается получить во время открытой транзакции остатки по этому регистру и измерению.

в случае упр.блокировок сервер 1С сначала проверяет нет ли блокировок на регистре X по измерению Y, если нет, то потом  генерит запрос с уровнем read committed. read committed это грубо говоря дай то есть дай то что есть сейчас, до момента транзакции, а на то что транзакция в процессе - пофиг.

А в случае автоблокировок сразу генерит запрос с уровнем seriazable. SQL смотрит что есть открытая транзакция и отвечает отлупом.

(44) В режиме управляемых блокировок уровень изоляции в SQL сервере всегда READ COMMITED. Диапазон блокируемых записей, тип блокировки (на чтение или запись) определяется менеджером блокировок 1с.

(46) в режиме управляемых блокировок уровень изоляции тот, который установлен для коннекта оператором SET. потому как явно хинты не ставятся на таблицы.

(45) а в случае когда две пишущие транзакции  пытаются в одну таблицу попасть то тут как?

(48) это две блокировки ресурсов с видом "exclusive", не совместимые между собой... одна пишет вторая ждет...