Почему в 1С 8 в варианте SQL возможно грязное чтение? #685713

1. Почему сабж? 2. Почему не используется версирование? 3. Почему нельзя установить принудительную блокировку на чтение данных? 4. Как вообще и возможно ли установить принудительную блокировку на запись данных? 5. Можно ли снять установленную принудительно блокировку до окончания транзакции?

Только что выяснили, как в 1С исключить грязное чтение :)) 6. Можно ли исключить грязное чтение, но использовать версирование?

у тебя же Мёбиус - эксперт по тех.вопросам и блокировки знает, что сподвигло создать топик ?

1. Выяснили. 2. Не выяснили? 3. Выяснили. 4. Выяснили. 5. Не выяснили. 6. Не выяснили. :))

Обновляем знания

Спорим))

Шестой вопрос самый актуальный :))

ты бы вендора и релиз сиквела указал

Юзайте исключительно прямые запросы)

MS SQL 2012

имхо на 2012 можно

В MS SQL 2012 добавили вроде возможность использовать READ_COMMITTED_SNAPSHOT

Как? :))

на 8.3 переходи, она принудительно базу в версии переводит

1) Выгоняем всех из базы (можно даже застропорить сервер 1с) 2) Открываем SQL Server Management Studio, New Query 3) Пишем: USE [master] GO ALTER DATABASE [Моя База] SET SINGLE_USER WITH ROLLBACK IMMEDIATE GO ALTER DATABASE [Моя База] SET ALLOW_SNAPSHOT_ISOLATION ON ALTER DATABASE [Моя База] SET READ_COMMITTED_SNAPSHOT ON ALTER DATABASE [Моя База] SET MULTI_USER WITH ROLLBACK IMMEDIATE GO где “Моя База” естественно нужно заменить на название вашей базы данных Примечание. В “родном режиме” 1С 8.3 этот режим уже включен. Определить состояние базы можно скриптом select name,snapshot_isolation_state_desc,is_read_committed_snapshot_on  from sys.databases Как работает версионирование Берем примеру десять пользователей, которые читают остатки на складе. В обычном режиме MS SQL Server каждый делает попытку наложить блокировку на строку с нужной записью остатков. Когда вы включите версионирование, то каждый пользователь прочитает ВЕРСИЮ, которая предварительно будет помещена из основной базы в tempdb. Затем сделает транзакцию и удалит версию. Если положить tempdb на медленные диски (умышлено), то по отношению к текущему состоянию скорость в рамках одного потока замедлится, но общая параллельность все равно улучшиться. Надо понимать что любые технические решения имеют ВСЕГДА И ПЛЮСЫ И МИНУСЫ и надо уметь выбирать какие плюсы имеют большее значение чем минусы!

То есть если в 8.3 я в транзакции построю отчет по регистру, на который есть блокировки, то он без проблем построится?

а что автор называет "грязным чтением"?

+ Вчера в 8.3 пробовали, не взлетело, кстати.

Автор называет грязным чтением то, что и все остальные.

1 Не понял для тупого 1сникиа можно подробнее 2 замедляет работу 3 Зачем ? Это же не чему не вредит 4 Да возможно 5 Можно но нужно поподробнее снять из 1с или скл, и снять какую тарнзакцию, есть транзакции на запись а есть на всю таблицу

ну и до кучи

1. Документация помогает 2. Вопрос к разработчикам платформы. В Объектных блокировках, которые оптимистические, есть свои версии. Правда не те, но слово встречается :) 3. можно 4. можно 5. нельзя, т.к. разрулом блокировок в управляемом режиме занимается сервер 1С. В части этого функционала доступа нет. 6. не знаю, но попахивает недокументированными использование возможностей, что чревато. А так, да, Ром. На лицо - совсем ты батька поплыл в блокировках.

Мда...

В 8.3 сработает если режим совместимости с 8.2 не стоит. Ну и вручную переводом mssql в read_committed_snapshot это возможно, я бы сказал что значительно увеличивает параллельность. Или использовать версионники. За счет этой фишки, кстати, в многопоточном параллельном проведении у меня postgresql пол линуксом на raid1 из 2 дисков показывал лучшие результаты, чем ms sql 2008 на raid0 из 3 дисков.

1. Что тут непонятного? Впрочем, маленький нюанс, который расставил все по своим местам. Грязное чтение возможно НЕ в транзакции. 2. Использование RLS тоже замедляет работу. Убираем? 3. Да можно, выяснили уже. Просто это в транзакции проверять нужно :)) 4. Та же тема, что и 3. 5. А вот есть мнение, что нельзя :))

6. Попахивает использованием штатной возможности MS SQL :))

угу. С учетом того, что управляемыми блокировками рулит Сервер 1С, идея классная чо-то помутить там на уровне СУБД, потом почесав репку, вопрошать, подымая палец вверх..."Доколееееее????" В 8.3 - хз, пинтаболить не буду. В 8.2 про это комол писал на инфостарте. Я не знаю чем там кончилось дело, т.к. про эту фичу ничего сами разрабы не говорили. А раз так - все это, на свой страх/риск/чистые памперсы.

Причем здесь управляемые блокировки? При запросе на чтение на устанавливается автоматически никакой управляемой блокировки, но устанавливается блокировка на чтение на уровне СУБД. Так вот она может не устанавливаться в этом режиме, а прочитается актуальная версия. Это реально работало еще в 8.2.

при том, что если блокировки автоматические - то вообще про что ведется речь???

Грязного чтения в транзакции не бывает на то они и грязное что оно читает когда все все могут делать в другом случае оно чистое 5 Если ты проводишь один документ и он запустит транзакцию то можно выловить(получить) этот объект и отменить его транзакцию из другого объекта это по описаню 1с. На практике не срабатывало. Но можно в открытый объект передать сообщение что бы он закрылся и тогда транзакция его снимится

и опять начинается марлезонский балет фразами "блокировка на чтение на уровне СУБД". Зачем вы сейчас хоть про СУБД то в суе вспоминаете? ЗАЧЕМ???

Я говорю про управляемый режим. В нём, как тебе известно, есть 2 менеджера блокировок - 1с и СУБД. Менеджер блокировок 1с здесь не задействуется никак, так как автоматически не устанавливается управляемая блокировка при чтении данных.

Затем, что обсуждается версионирование, а это вообще-то, сюрприз!, относится к СУБД, а не к 1с

спасибо капитан, и в чем посыл сего? ну и? Что дальше? Я повторяю свой вопрос второй раз: зачем в рамках блокировок в прикладной логики конфигурации, вспоминается СУБД?

Ты комментировал следующий вопрос: 6. Можно ли исключить грязное чтение, но использовать версирование? Расскажи, как нужно мысль так вывернуть, чтобы локализовать его в рамки прикладной логики конфигурации и не вспоминать СУБД? Я вот тебе реальный опыт внедрения говорю - многократное увеличение параллельности за счет использования соответствующих возможностей СУБД. Измерялось в числовом показателе - количество проводимых документов разными потоками в минуту. Ты такой приходишь с саблей и говоришь, что это все не относится к СУБД и вообще непонятно как работает. Зачем ты так делаешь, если не знаешь точно?

в v8@1c.ru писали?

Зачем? :))

если выкинуть все твои пространные рассуждения, то коротко все можно свести к тезису "версионник лучше блокировочника, т.к. Дартаньян уже наблюдает "многократное увеличение параллельности за счет использования соответствующих возможностей СУБД" на "реальный опыт внедрения".  Т.е. на очень давний, поросшему мхом холивар "Что лучше - блокировочник или версионник?", ты однозначно нашел серебряную пулю. Мои искренние поздравления. Я заглянул в твою карточку, и увидел, среди прочих регалий, сданный "Эксперт по технологическим вопросам". У меня вполне конкретный вопрос, там так учат уже? Ну что блокировочник - ад, версионник - торт?

если режим блокировки = "исключительный", это разве не исключает "грязное" чтение?

Исключает. Исключает вообще возможность чтения. А вот версии дают возможность прочитать старые версии.

Какие-то утверждения о превосходстве версионников над блокировочниками - они у тебя в голове только. Я аргументирую тезис о повышении параллельности работы на уровне изоляции read_committed_snapshot. Никакие твои замуты с холиварами мне неинтересны, речь про конкретную задачу и оптимальное решение, когда блокировки можно ставить вручную в менеджере управляемых блокировок, а когда логика не требует обязательной блокировки - получить версию без ожидания. Ты никакой аргументации не даешь, кроме того, что я якобы врываюсь и раздаю ответы на вопросы о зарождении жизни на земле. На тренинге по эксперту рассказывают вполне очевидную вещь: данный режим повышает параллельность работы пользователей за счет снижения количества блокировок, но требует больше внимания от программиста, т.к. если прикладная логика требует получения данных с обязательным учетом завершилась успешно транзакция, которая их меняет, или нет, то нужно ставить явные управляемые блокировки. Есть что сказать по делу, опираясь на логику, опыт и документацию, а не на эмоции? Я, Дартаньян, заявляю, что вот так вот можно повысить производительность. И фирма 1с это утверждает в своих описаниях улучшений производительности 8.3. И другие учетные системы используют именно этот уровень изоляции. Но всем им и мне, конечно, очень интересно твоё мнение на этот счет.

Дартаньян, в 8.2. при при использовании управляемого режима блокировок для объекта используется уровень READ COMMITED, который устанавливается соединению с СУБД. В 8.3 произошел переход на уровень изоляции READ_COMMITED_SNAPSHOT в управляемых блокировок. Это мне было известно до начало всего этого эпик-треда. Теперь про аргументацию: в 8.2 такого же можно было добиться, если самостоятельно перевести скуль в в режим версионника и использовать режим управляемых блокировок. Что и делалось многими людями на проектах, и вашим покорнейшим слугою в т.ч. Кому помогало - писали хвалебные песни. Кому не помогало - начинали разбираться с холиварами. и оказалось, что  у луны всегда две стороны. Но они тебе не интересны.  На тренинге же, про который ты упомянул, говориЛОСЬ (когда еще 8.3 не было, как сейчас - хз) про штатный версионник: а на вопросы про блокировщик упомянались только холиварные тезисы про две стороны. Исходя из этого, в 8.2 ни на ИТС, ни в официальной документации, советы по переводу скуля из блокировщика в версионник 1С'овцы не давали. Сейчас дают? Т.к. мое мнение, конечно важно Дартаньяну, то я, точно также, как и все, хлопаю в ладоши веселюсь от счастья! я рад :) И выше я резюмировал - версионник - торт, блокировщик - ад. Никаких холиваров? Ну все так или нет?

примечание к : на тренинге говорилось про штатный блокировщик конечно, а про версионник. Очепатко. Извиняюсь

>> И другие учетные системы используют именно этот уровень изоляции. Ну скуль-срачи на скуль ру, действительно, появились на эту тему гораздо раньше чем у 1сников, что подтверждает, да. Видимо используют :)

Советов по переводу 8.2 в snapshot от 1с быть не может, т.к. это 1. нарушение лицензионного соглашения 2. вещь ненадёжная, т.к. при реструктуризации оно может обратно выставляться. На прямые вопросы на эту тему Александр Морозов, ведущий тренинга, отвечал, что да, 8.2 также вполне себе поддерживает работу на этом уровне, если его устанавливать для скуля, но есть проблемы связанные с п.1 и 2, а 8.3 его сама ставит если нет режима совместимости. Не нужно посещать тренинг чтобы понять - в будущем все типовые будут работать именно на этом уровне изоляции, достаточно посмотреть график перевода их на 8.3. Это не какая-то заявка на бессмысленные холивары - это рациональный способ обеспечить параллельность работы в информационной системе, одной из особенностей которой является значительное превосходство количества читающих запросов над пишущими запросами. Это не какая-то рекомендация, это способ реализации работы с СУБД вендора платформы, который в погоне за производительностью выбрал этот путь, мы по идее на это вообще влиять не имеем права. И у вендора есть причины такой путь выбрать - т.к. у нас есть управляемые блокировки и мы можем воспроизводить когда нам надо поведение блокировочника, а когда не надо - поведение версионника, жертвуя производительностью дисковой подсистемы. Ты ни одного холиварного тезиса не привёл, опять вижу поток эмоций. По факту - это один из возможных путей ухода от избыточных блокировок на MS SQL.

>>Ты ни одного холиварного тезиса не привёл, опять вижу поток эмоций. Зачем мне их приводить, если ты сам, чуть ранее пишешь: >>Никакие твои замуты с холиварами мне неинтересны. Ну ок. Я просто все таки хочу ответ то получить - серебрянная пуля, найдена? Все типовые будут в версионнике. Все или еще что-то?

О, а вот и свеженькая спамятинка :))

Поиском боеприпасов из драг. металлов никто кроме тебя не занимается, поэтому не могу никак ответить на этот вопрос. Типовые с ms sql будут работать вот таким образом, да. Аргументы, почему это увеличивает параллельность, приведены. Способы решения версионных проблем тоже упомянуты. Не вижу смысла что-то еще добавлять. Ну кроме того, что все объединились против тебя и пытаются тебе доказать что блокировочники отстой, а версионники - рулез. Ведь, как ты сказал, если откинуть "пространные рассуждения", то 1с всему миру хочет заявить именно это!

заметил я среди звезд такую черту. Вот они всегда говорят от своего лица, при этом всегда подчеркивая, "мы", "все" и т.д. Кроме того, я вообще, в отличие От (с большой буквы, конечно), ни на одну сторон добра/зла не стал, и уж тем паче не пел хвалебные или отпевательный оды, ни по блокировщику, ни по версионнику. >>блокировочники отстой, а версионники - рулез Что там в школе то говорилось по этому поводу - Ч.Т.Д.? Рома, а ты хорошо вбросил сегодня? Я надеюсь ты контекст рассуждений не упустил? :)))

Заметил среди дилетантов такую черту, как желание аппроксимировать сложный набор условий, методов и нюансов в какое-нибудь общее явление, тем самым не утруждая себя вникнуть в суть происходящих процессов. В результате этого ты все выводишь к понятной тебе формуле "версионники рулят, блокировочники отстой" или наоборот, видишь тут какие-то стороны добра и зла, упуская из виду даже тот факт, что мы вроде как рассматриваем СУБД-блокировочник, которая позволяет использовать версии, когда прикладная логика приложения от этого не пострадает, а не mssql vs oracle. Я, как звезда, Дартаньян и все остальные вместе взятые, кем ты там меня назовешь еще, увидел, что ты не вникаешь абсолютно в технические аргументы и пропускаешь их мимо ушей, воспринимаешь все эмоциями. Логично в таком случае указывать на некие "авторитеты", да.

Батюшки мои, реальный звезда-Дартаньян :)))))

че 12-ка уже без костылей работает с 8.2???

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

все таки поправлю. В начале предложения хотелось бы увидеть такое: "Я, как звезда, Дартаньян и все остальные вместе взятые, нашли" и уже далее .

Троллишь вяло, примитивно и скучно, никому неинтересно...

ожидаемо кстати! Слушай, а у со сколькими людьми ты себя одновременно ассоциируешь? "Мы, все, никому". Я так полагаю, это такой легкий звездный пафос? :))) Ты не пробовал вещать за одного, самого себя? Не? И потом, бодро, остроумно и весело троллить могут только Звезды! Блокнотик уже готов. Давай! :)

*деликатно прикрывает зевок ладонью* Пока не зацепило, давай еще что-нибудь!

)))))))))))) Так я от тебя жду чего-нибудь задористого!

Мусье, продолжайте;)

Есть мнение, ты и без меня где-то находишь что-то "задористое". Тут тебе и серебряные пули, и ад, и Дартаньян, и звёзды - не огорчай меня тем, что мощный поток метафорических аллюзий иссяк!

что-то скучно.... Давайте, мусью, ещё выдайте что-нибудь....

Все не читал На ИТСе статья появилась Особенности нетранзакционного чтения данных