Естественно всё что перечисленно ниже нарушает лицензионное соглашение с 1С в пункте в котором вы обязуетесь использовать только средства платформы для работы с СУБД. Конечно я ничего такого никогда не делал :) и весь материал ниже носит чисто теоретический характер. И конечно его применение только на свой страх и риск :).
Собственно рецепт:
1) Выгоняем всех из базы
2) Открываем SQL Server Management Studio, New Query
3) Пишем:
ALTER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON
где "MyDatabase" естественно нужно заменить на название вашей базы данных
Для тех кому абсолютно не интересно что дальше произойдёт и как это работает - можно дальше не читать.
Для тех, кому наоборот - очень интересно могу привести ссылки: http://msdn.microsoft.com/ru-ru/library/ms173763.aspx
и http://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.80).aspx
Собственно окончательно меня убедило в правильности данного подхода, когда нашел в официальном руководстве для разработчиков Dynamics Ax (http://crusevinaq.narod2.ru/public/spravochnik-professionala-microsoft-dynamics-ax-4.0-skachat.html
) упомянание о том что данный уровень изоляции DAX по-умолчанию включает для баз, созданных на SQL Server 2005/2008. 1С, к сожалению на момент написания данной статьи ещё этого не умеет. И мне, если честно, продвигать эту идею туда пока лень. Собственно 2 команды написать намного проще.
Что при этом изменится. Всё очень просто - часть SQL Server станет версионником. Причём в данном случае рекоммендуется всё-таки использовать SQL Server 2008, т.к. в SQL 2005 эта возможность только появилась. А сами знаете как бывает когда возможности только появляются. У тех кто понял слово "Версионник" глаза уже загорелись, вдруг вспомнился "Oracle". Хотел найти статью, которая бы объяснила чем отличается версионник от блокировочника, но как-то не сложилось.
Обясню в 2 словах: мы хотим списать с остатков 1 Ручку, которая на складе всего одна, и сосед наш тоже этого жутко хочет:
Вместе жмём на кнопку "Провести". Мы на тысячную долю секунды быстрее.
Уровень изоляции везде READ COMMITED
Как сработает блокировочник:
- читаем остатки мы, и блокируем их
- читает остатки сосед - ждёт пока отпустим
- записываем остатки
- читает остатки сосед , ну и уже понятно, получает отказ
Как сработает версионник:
- Читаем остатки
- Читает остатки сосед (!!!!!!!)
- Записываем остатки
- Сосед записывает остатки, естественно дождавшись пока мы запишем
В чём разница? А в том что во втором случае сосед прочитает версию данных которая была зафиксирована до их измененеия. Концептуальному уровню READ COMMITED это всё удовлетворяет. Были прочитаны зафиксированные данные, просто прочитаны данные, которые были зафиксированы ранее. Таким образом, незафиксированных в транзакции данных мы не прочитаем, что немловажно. НО ведь в данном случае мы спишем 2-ю ручку в "-". Да - спишем, конечно если не наложим управляемую блокировку
речь о которых пойдёт в следующем посте. Потому что уровень изоляции READ COMMITED 1С использует только при наличии управляемых блокировок. При этом поддерживается на уровне СУБД только логическая целостность данных, а о своих "заморочках" программисты должны позаботиться сами, с чем я лично не могу не согласиться.
Теперь, я думаю, должно быть понятно какой простор для творчества открывает версионирование данных в случае с уровнем изоляции READ COMMITED. В этом случае можно вообще обойтись без блокировок на уровне СУБД. У версионирования, конечно, есть и проблемы - в частности ресурсов под него нужно несколько больше чем просто для поддержания инфраструктуры блокировок. Но потому как версионирование в MS SQL производится не для всех уровней изоляции, то существенной разницы в потреблении ресурсов быть не должно. Для более высоких уровней изоляции нельзя с уверенностью утверждать что версионность лучше чем блокировки. Да и в принципе это не цель данной статьи.
Как было отмечено выше, включение версионирования возможно только для уровня изоляции READ COMMITED. А этот уровень изоляции используется при включенных управляемых блокировках. При автоматических блокировках чаще всего уровень изоляции SERIALIZABLE - поэтому включение данной опции для автоматического режима несущественно повысит производительность, поэтому настоятельно рекоммендуется их включить, если этого ещё не сделано. Если не вдаваться в подробности включение управляемых блокировок в любой конфигурации не займёт более 3-4 часов работы квалифицированного программиста. Конечно в случае когда они включаются осмысленно и осознанно, а не простым слодованием методике, описанной на ИТС. В следующей статье я опишу как это проще всего сделать.
"Убираем блокировки" в 1С. Заставляем MS SQL работать как Oracle.
База данных - HighLoad оптимизация
См. также
HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)
Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.
24.06.2024 5132 ivanov660 12
HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)
Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.
06.06.2024 9253 Evg-Lylyk 61
HighLoad оптимизация Механизмы платформы 1С Системный администратор Программист Стажер Платформа 1С v8.3 Бесплатно (free)
Сравним «Регистры сведений» с «Сервисами интеграции» и узнаем, кто быстрее!
28.03.2024 5002 dsdred 23
HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)
Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.
13.03.2024 5094 spyke 28
HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)
Оказывается, в типовых конфигурациях 1С есть, что улучшить!
13.03.2024 7570 vasilev2015 20
HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)
Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.
2 стартмани
15.02.2024 12413 241 ZAOSTG 80
HighLoad оптимизация Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)
Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.
1 стартмани
24.01.2024 5668 glassman 18
HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)
Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.
09.01.2024 14001 doom2good 49
вообще непонятно, откуда вы взяли, что
- Читаем остатки
- Читает остатки сосед (!!!!!!!)
- Записываем остатки
- Сосед записывает остатки, естественно дождавшись пока мы запишем
а ситуация
- Читаем остатки
- Записываем остатки - Читает остатки сосед (!!!!!!!)
- что, невозможна?
Да даже и ваш пример - что тогда записывает сосед в базу, если вы уже записали свои данные, а сосед о них даже и не узнал?
1. Мы читаем остатки, потом делаем движение, хотим чтобы остатки не стали отрицательными, единственный вариант - установить управляемую блокировку (в данном случае исключительную, чтобы не получить дедлок). В итоге все плюсы от версионника теряем, так как остальные транзакции встанут на уровне менеджера блокировок 1С. Уточню, что даже если мы поставим разделяемую блокировку, то плюсы мы все равно потеряем, так как запись в управляемых блокировках все равно не сможем провести.
2. Мы делаем маленький запрос, потом запись, при этом не блокируем данные управляемой блокировкой. Что же произойдет? На время выполнения запроса, никакая другая транзакция записать данные не сможет (блокировка на уровне SQL без данной настройки), после выполнения запроса, но еще до записи блокировка READ COMMITED на прочитанные данные будет уже снята. Тем самым группа отдельных запросов внутри транзакции нам сильно мешать не будет. Итого вероятность того, что запись данных попала на чтение этих же данных в транзакции, да еще и без установки управляемой блокировки. И сравниваем с накладными расходами MS SQL для поддержания версионника. Спорный плюс.
3. Ну и наконец, ситуация когда мы получим плюс. Мы выполняем большой запрос в транзакции, при этом не устанавливаем управляемую блокировку. Например хотим отчет без чтения грязных данных. Тогда, да, мы получим плюс, т.к. в течении этого запроса мы сможем записывать данные.
4. Рассмотрим рекомендуемый ныне фирмой 1С метод контроля остатков (и не только 1С, но и Microsoft). Сначала пишем, потом проверяем, если что отменяем. В таком случае в самом начале будет установлена управляемая исключительная блокировка, и нам будет совершенно все равно какая блокировка установлена на уровне SQL.
Итог: почти все плюсы съест менеджер управляемых блокировок 1С. Теперь, прежде чем "нарушать лицензионное соглашение" :), стоит оценить насколько часто в вашей конфигурации встречается вариант 3. В итоге накладные расходы не перекроют ожидаемый эффект? В типовых конфигурациях, по-моему, вообще не имеет смысла данная настройка, если у вас собственная самописная конфигурация, то может быть. А вообще вам поможет только замер производительности в первом и втором случае. Потому тест центр в руки - генерируем нагрузку, смотрим ЦУПом время ожидания на блокировках SQL, ЦУПом же анализируем общее время выполнения запросов. Только этот эксперимент даст вам ответ на вопрос: "А стоит ли?".
Ради эксперимента проведу замер производительности в обоих случаях в разрабатываемой сейчас мною конфигурации, потом напишу результаты. Но сейчас, стадия промежуточная между тестами, так что недели через 2 только смогу.
Если не сразу устанавливать блокировку (или вообще не устанавливать явно) управляемую блокировку то выигрыш от управляемых блокировок только в случае идеальной конфигурации с контролем остатков по "новой методике" и отсутствием явной записи наборов в регистр. Иначе в случае блокировщика получаем deadlock из-за разного порядка записи в регистры, что гораздо хуже простого ожидания на блокироке.
Кроме того в обоих в обоих случаях получаем deadlock в случае блокировщика из-за того что MS SQL сам принимает решение что блокировать, в отличие от сервера приложений который использует "правильную" блокировку.
Так что при всем богатстве выбора, другой альтернативы нет - только версионник может повысить параллельность работы пользователей настолько, насколько это в принципе возможно.
- читаем остатки мы, и блокируем их
- читает остатки сосед - ждёт пока отпустим
- записываем остатки
- читает остатки сосед , ну и уже понятно, получает отказ
Как сработает версионник:
- Читаем остатки
- Читает остатки сосед (!!!!!!!)
- Записываем остатки
- Сосед записывает остатки, естественно дождавшись пока мы запишем
Это не так.
В первом случае никакого "ждёт пока отпустим" (на READ_COMMITTED) нет. И никакого "ну и уже понятно, получает отказ" тоже нет. Если и понадобится ждать (окончания обновления данных, непример), то просто дождётся. Ну или не дождётся.
Во втором случае "сосед" должен отвалиться с ошибкой. Версионник сделан так чтобы "пишущие" транзакции не мешали читающим транзакциям и читающие не мешали пишущим. В блокировочнике даже читающие могут мешать читающим, но на более высоких уровнях изоляции.
1. Версионный режим работы может не подойти, т.к. у версионника есть свои специфичные конфликты обновления, которых нет с read committed (.
2. Нет разницы - для всех или не для всех уровней изоляции используется READ_COMMITTED_SNAPSHOT, всё равно есть риск существенной нагрузки на tempdb (которая и так часто становится узким местом). Но что лучше - непредсказуемые эксалации для READ_COMMITTED или убитая tempdb для READ_COMMITTED_SNAPSHOT - это конечно же отдельный вопрос.
Самое главное. READ_COMMITTED_SNAPSHOT очень-очень-очень нужен чтобы отчет, который делается долгое время оперировал консистентным набором данных, причем не ставя колом всю остальную работу. А в 1С отчеты делаются с грязным чтением, поэтому все эти приседания просто не нужны. А для параллельного проведения обычного READ_COMMITTED и управляемых блокировок зачастую хватает.
Ну оооочень популярное заблуждение :). Если бы наши администраторы БД кроме чтения теории иногда ещё ставили простенькие эксперименты жизнь была бы намного легче :). Ничего не хочу сказать про теорию и работу может DB2.. но MS SQL делает так: В момент чтения Read Commited Кратковременно пытается наложить S блокировку Звучит конечно не очень, но происходит именно так - проверяйте :))) Как раз в это время и ждёт..
- читаем остатки мы, и блокируем их
- читает остатки сосед - ждёт пока отпустим
- записываем остатки
- читает остатки сосед , ну и уже понятно, получает отказ
Что значит "получает Отказ" ?
Понятнее другое :
- читаем остатки мы, и блокируем их (конструкция "Для Изменения" в запросе)
- читает остатки сосед - ждёт пока отпустим
- записываем остатки и "отпускаем"
- или сосед читает изменившиеся остатки , и в модуле проведения определяется возможно ли проведение при изменившихся остатках.
- или для соседа время ожидания завершения нашей транзакции истекло и сосед получает "отказ".
Сосед конечно не читает остатки а "предпринимает попытку чтения". Собственно за коммент спасиб, действительно придётся чуть подправить чтобы было понятнее...
А то ж! Конечно! Как же без неё родимой, а вдруг кто-то решил удалить данные, пока мы читаем? Но у вас же 2 читающие транзакции в READ_COMMITTED, обе накладывают S блокировочку. Кто кого ждёт? Смотрим в доку, - Shared совместима с Shared.
По версионнику. В вашем сценарии ошибки времени выполнения не будет. Я перепутал с уровнем изоляции Snapshot, в чём каюсь. В Snapshot транзакция второго участника отвалится из-за изменения данных, но это уже отдельная история. Кстати, а зачем вы разрешаете оба режима и SNAPSHOT, и READ_COMMITTED_SNAPSHOT?
Вообще, посмотрев внимательно, я считаю, что в случае, если у нас read committed или read committed snapshot (и нет управляемых блокировок), то сценарий "читает 1, читает 2, записывает 1, записывает 2" одинаково приводит к неконсистентным данным.
Read committed snapshot может помочь не в такой простой схеме, а в случае, когда в продолжительной транзакции есть запись данных в начале транзакции. Примерно так:
1. Считаем записи в таблице А
2. Записываем запись в таблицу А
3. Думаем о жизни, сущем и всё такое (42 секунды)
4. Записываем запись в таблицу Б
Пусть 1-й участник выполнил первые 2 пукнта, а 2-й только начал транзакцию. В блокировочнике 2-й ждёт потому что 1 наложил блокировку (X) на всю таблицу. В версионнике 2-й прочитает то состояние, которое было на момент начала транзакции. С одной стороны, да, ускорение, с другой - я совершенно не уверен, что все механизмы 1С адекватно переживут такое изменение поведения.
Поэтому, то что "Dynamics Ax ставит Shapshot по умолчанию" говорит лишь о том, что MS протестировала внутренние механихмы аксапты на то, что они будут работать ожидаемым образом. А вот 1С такого вроде не заявляла.
select wait_type, waiting_tasks_count, wait_time_ms, max_wait_time_ms, signal_wait_time_ms
from sys.dm_os_wait_stats
where wait_time_ms + signal_wait_time_ms<>0
order by wait_time_ms + signal_wait_time_ms descЕсли ожидания установки блокировок (чаще всего LCK_M_X, LCK_M_S для режима управляемых блокировок) держатся "в топе" (если не считать всякие SLEEPы и т.п.), тогда, конечно, надо бы постараться их уменьшить, но если там какой-нибудь PAGEIOLATCH_SH или CXPACKET, то решать надо совершенно другие проблемы.
Такой же самой неконсистентности мы можем добиться в обычной ситуации если документ2 проводится "задним числом" - движения документа1 никак не будут учитывать уже имеющихся движений документа1. Так что такая "неконсистентность" - вполне нормальная ситуация для базы на 1С.
Там где надо избежать такой неконсистентности в оперативном режиме работы - надо применять проверки после записи набора записей.
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms
REQUEST_FOR_DEADLOCK_SEARCH 40398 202203630 5189 202203630
XE_TIMER_EVENT 6739 202203816 30090 202202668
LAZYWRITER_SLEEP 5483819 404171462 11881043 103247
CXPACKET 122645427 196576331 47939 8810348
LOGMGR_QUEUE 1784647 202133531 6221089 84946
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 50428 202153506 4179 150
Ну и как я ее решу адекватно в УПП ? Написать свою новую версию УПП ? :-)
Проще вернуться в режим автоматических блокировок и уменьшать время транзакций при проведении оптимизацией кода.
Но ранее у меня вся оптимизация кода в УПП упиралась в длительную запись (именно запись) регистров партионного учета и длительный запрос чтения остатков по счету по плану счетов. Сейчас правда после аутсорсеров есть что оптимизировать... Палками кидать в меня не нужно по поводу проведения партий в онлайне - заказчику партии нужны именно в онлайне. Хотя конечно было бы неплохо разработать отдельный механизм для учета того, что они учитывают при помощи партий, но пока что переубедить их не удалось.
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms
REQUEST_FOR_DEADLOCK_SEARCH 40398 202203630 5189 202203630
REQUEST_FOR_DEADLOCK_SEARCH - не говорит о том, что проблема в дедлоках
Occurs while the deadlock monitor waits to start the next deadlock search. This wait is expected between deadlock detections, and lengthy total waiting time on this resource does not indicate a problem.
Я уже писал выше - не читающие под "блокируем" я понимаю - "начинаем изменять", т.е. накладываем X блокировку.
Я запутался. Вот ваша схема, по которой, как вы пишите, работает 1C с точки зрения MS SQL:
Как сработает блокировочник:
- читаем остатки мы, и блокируем их
- читает остатки сосед - ждёт пока отпустим
- записываем остатки
- читает остатки сосед , ну и уже понятно, получает отказ
Если у нас READ_COMMITТED, то перед первым шагом мы накладываем блокировку S, которая мешает другим транзакциям наложить X, но не S, а после первого шага снимаем её. Если мы говорим про управляемый режим, то при этом, на самом деле 1С наложит упр. блокировку на документ, на наборы движений и на разрезы итогов по существующим движениям. Но мы смотрим работу MS SQL и поэтому про упр. блокировки пока забыли.
На втором шаге - всё повторяется, опять наложили и сняли S блокировку (кого и где мы тут ждём, если, например, оба документа новые?). Даже если чтение 1-го шага еще не окончено, то ничего нам тут не мешает.
На третьем шаге, кстати, первая транзакция должна подождать, пока не снимется S блокировка с итогов регистра накопления. Перед началом изменения на этом шаге MS SQL Server выставляет X блокировки на удаляемые/создаваемые записи. Если таких записей много (более 5000), то блокировка может быть эскалирована до большей. После окончания изменения данных блокировка остаётся висеть до конца транзакции, поэтому ни S, ни X уже никто не навешает.
Четвёртый шаг ждёт окончания транзакции и делает свои движения, аналогично шагу 3.
Еще раз - кто и кого ждёт на втором шаге этой схемы?
Предположим пользователь запустил отчет по остаткам денег в кассе за 2 сентября. 1С преобразует запрос к виртуальной таблице регистра в запрос по двум таблицам - по итогам на последнюю дату системы (3999 год) с ограничением по измерениям и по движениям со 2 сентября по последнюю дату системы с теми же ограничениями по итогам. Затем из итогов отнимает приход и прибавляет расход, чтобы получить верные остатки на 2 сентября. При этом из-за грязного чтения вполне возможна ситуация, когда MS SQL прочитает данные из таблицы итогов и из таблицы движений рассогласованно. Чаще всего это, конечно, проявляется при получении итогов на начало месяца в конце месяца или за начало предыдущего месяца, когда итоги еще не расчитаны. Директор видит отрицательный остаток по кассе, медленно офигевает, зовёт кассира и главбуха, они говорят: "это всё кривая 1С"... Вопрос - что сказать 1Снику, когда его позовут объяснить, нахрена заплачено $N за систему, которая в принципе не умеет выводить остатки отличные от текущих?
Ну уже радует что в логике работы 1с вы разбираетесь, но ситуация конечно надуманая. Если в момент построения отчета В открытом периоде кто-то проводил такой не хилый документ списания по кассе, который, допустим, ещё и не провёлся а откатился в итоге то кассир получит отрицательную сумму но на текущий момент времени, а не на закрытый период. И как любой здоровый человек построит отчет ещё раз. Но ведь на то это и открытый период чтобы в нём что-то постоянно менялось :). Беда 1С именно в этом... в том что в принципе работа задним числом разрешена, и есть понятие "открытого периода". Поэтому логика отчетов вполне подходит... под логику системы. Описанное поведение как раз "укладывается" в мозгу бухгалтера, а вот "нельзя изменять проведённые документы"... как-то не очень укладывается :)
А что касается отчетов... я наверное об этом ещё статью напишу. Посмотрел я на это дело в Dynamics - там отчетов нет - "используйте Reporting Services" А вы его видели? Степень его убогости... и там всё тот же Read Uncommited, кстати :)))
Вы, наверное, не поняли. Попробую наглядно и подробно. Ситуация вполне моделируется, могу ради интереса попробовать в выходные простейшую конфу накидать, которая демонстрирует.
Сегодня 30.09.2011. Итоги в базе данных расчитаны до 31.08.2011.
Остаток на 01.11.3999 - 50 рублей. Каждый день с 02.09.2011 по 29.09.2011 есть по 100000 документов в день. Половина - приходы на 1000 рублей, половина - расходы на 1000 рублей.
Очевидно, что реальный остаток на начало дня 02.09.2011 - те же самые 50 рублей.
Дальше такой процесс:
1. Наш гипотетический директор запустил отчет по остаткам по кассе, чтобы посмотреть остаток на начало дня 02.09.2011.
2. MS SQL Server получил запрос, скомпилировал, построил план. План примерно такой, что нужно взять таблицу итогов, отфильтровать по кластерному индексу по периоду данные на 01.11.3999, получив из неё поле ресурса суммы, взять часть таблицы движений (опять же по кластерному индексу) от 02.09.2011 00:00:00 до 01.11.3999 00:00:00, при этом поле ресурса суммы взять с минусом для прихода и с плюсом для расхода. После получения всей этой выборки (на самом деле не после, а по мере выборки данных, но не суть) просуммировать поле ресурса суммы, сгруппировать как написано в запросе и выкинуть нулевые итоги, если они есть. Блокировок никаких нет.
3. Запрос начал выполняться по плану, все недостающие в памяти экстенты поставлены в очередь на чтение с диска и быстро-быстро прочитаны данные по итогам (там всего-то сотни или тысячи записей, а движений миллионы)
4. Кассир Людочка проводит новый документ "приход 1000 рублей". Сегодняшней датой. Неоперативного проведенияу неё, конечно, нет. Остатков контролировать не надо (это же приход).
5. MS SQL проводит документ: создаёт запись документа, изменяет данные в таблице итогов за 01.11.3999 (увеличили на 1000 руб), создаёт запись регистра накопления (приход на 1000 руб). Всё это, конечно, с учетом блокировок MS SQL и 1С.
6. Запрос отчета директора наконец-то добрался до тех страниц, в которых лежат сегодняшние данные. У него получилось 28*50000 расходов по 1000 рублей, 1 400 000 000 рублей за период, которые надо прибавить к конечному остатку 50 руб и 28*50000+1 приход по 1000 рублей, т.е. 1 400 001 000, которые надо вычесть из начального остатка. Итого 50 + 1400000000 - 1400001000 = -950 рублей.
7. Директор удивлён. Ведь он же тщательно выстроил бизнес-процессы, чтобы кассир мог проводить только оперативно, а выручка сдавалась в конце дня. Ведь он потратил 10 млн рублей только на лицензии 1С (а еще MS, а еще пришлось технику брать, еще за внедрение, за обучение...) и всего-то хочет узнать остаток в кассе на 2 сентября. Что сказать директору?
"и там всё тот же Read Uncommited"(с)
Имеют полное право. ;-) Естественно, при соответствующей этому схеме базы данных и системе "логических" блокировок на уровне платформы.
"...Reporting Services" А вы его видели? Степень его убогости"(с)
ОНИ уделяют больше внимание содержанию информации, а не внешней форме её представления. И у НИХ не возникает "проблем" подобных (28) сообщению. ОНИ об этом, в первую очередь, думают. А МЫ все "бантики" изображаем...
(30)
"...чисто гипотетически такая ситуация возможна, чтобы записи в таблицах итогов и движений были рассинхронизированы,"(с)
Реально будет возникать очень часто.
"...может в платформе и есть какой-то механизм проверки их синхронности."(с)
Есть. ;-) На уровне управления блокировками ручками.
"На практике удавалось воспроизвести?"(с)
Для этого не требуется воспроизведения на практике. Достаточно знать и понимать организацию схемы базы данных и логики её обработки.
"...представляете сколько всего так должно совпасть чтобы эту ситуацию получить?"(с)
Достаточно совпадения двух событий, как это описано в (28).
"повторное секундное нажатие кнопки сразу "исправляет проблему".(с)
Но, для этого пользователь должен знать, что эта "проблема" возникла. Или давить на кнопку несколько раз для подтверждения достоверности информации. Ну, или запускать отчет в монопольном режиме.
"все более-менее важные отчеты в 1С делают по закрытому периоду"(с)
А отчет "по остаткам по кассе"(с) и есть "более-менее" важный. И подобных отчетов, требующих 100% достоверности - много. И не по закрытому периоду.
(31)
"убеждает в том что моя статья "в тему" для 1с"(с)
Т.е. если есть бардак, то второй бардак не сильно усугубит первый. Да. Есть такой взгляд на
Эх. Пожалуй, и на эту стать поставлю "минус". :-(
P.S. Олег. Бардак надо не плодить, а устранять. И это редко получается двумя нажатиями кнопки мышки...
Посты вида
Есть. ;-) На уровне управления блокировками ручками.
Согласен с одним:
"читаем остатки мы, и блокируем их" читать как "читаем остатки и начинаем их изменять" - это на "причьем языке". Управляемый режим - "точку останова" поставили после "update" но до "Commit". Так наверное будет понятнее... правда не многим...
то пользователи бегут к вам и "бьют по морде". Можете уже не успеть решить :))))
Т.е. "вы предпочитаете запереться и подождать"? :))))
Компания 1С это делает (меняет производительность на целостность) уже много лет, контролируя остатки только при оперативном проведении :-) Так что хуже чем есть точно не станет :-)
1.Для управляемых блокировок придется переписать модули проведения всех документов/записи регистров? и перетаскивать доработки при обновлениях?
2. Есть примеры для ЗУПА?
3. Где почитать про идеи как допиливать модули проведения?
Пы.Сы. Как я понял, режим изменения блокировок распространяется на всю базу, а не конкретные объекты1С или физическиеТалицыБД . Потому и вопросы.:(
Пы.Сы.1 хотелось бы определить: "А стоит ли оно тогО?" в моей конкретной ситуации.
1) Ничего не нужно "допиливать" практически 1 - 2 места где производится контроль остатков нужно управляемую блокировку поставить, и то только в случае если включен контроль отрицательных остатков
2) В последней версии ЗУП-а управляемый режим стоит
3) в статье выше... ну или в журнале у меня... главная идея - это не сложно. Практически любая конфигурация переделывается на управляемый режим минут за 30. Нужно найти места где блокировки на самом деле нужны (контроль остатков) и там их поставить, либо как в математике: доказать что не нужны
Работа с СУБД. Управляемые блокировки.- При работе с Microsoft SQL Server версии 2005 и выше, используется режим управления версиями строк, если конфигурация использует режим управляемых блокировок. Используется уровень изоляции транзакций READ_COMMITED_SNAPSHOT. При чтении данных вне транзакций используется согласованное чтение. - Реализованные изменения приводят:
К уменьшению блокировок и взаимоблокировок при выполнении запросов, работающих в транзакции;
Исчезновению ошибок при выполнении запросов вне транзакции над часто модифицируемыми прикладными объектами;
Получению согласованных результатов отчета вне транзакции на момент выполнения отчета.
Выходит, все таки, истина была на стороне автора.
Олег (comol).
У нас с Вами получаются очень длинные и бесполезные разговоры. Я всегда пытаюсь в разговоре определиться О ЧЕМ мы разговариваем, а потом уже сыпать аргументами.
В текущем обсуждении я не отрицаю преимущества "версионники"(с). Я, вообще, не обсуждаю этот инструмент.
Я утверждаю, что:
"Для полноценного использования "Read commited shapshot"(с) требуются изменения в платформе. А не просто написание "двух команд"..."(с).
Понимаете, суть моего высказывания направлена на Ваше утверждение "написать две команды и всё будет хорошо". А это не так. Ну, чуть-чуть сложнее всё оказывается... ;-)
3 предпосылки:
1) Версионники в общем случае предпочтительнее блокировочников (чтение внутри транзакции меньше блокировок вызывает). Собственно самая спорная предпосылка, но в (51) вы с этим согласились.
2) Read commited shapshot включается для базы 2-мя командами (можете проверить :) ).
3) Read commited shapshot включает функционал версионирования для MS SQL (на уровне изоляции Read commited)
Итог - лучше станет. Не всегда и не везде конечно, но если много чтений в транзакции то однозначно лучше. А в принципе чтение в транзакции нормальная и хорошая практика.
В любом случае дальнейшую дискуссию продолжать бесполезно - публикация утратила свою актуальность с выходом 8.3. Все перейдут и сниму публикацию. Уже вторая которая утратила актуальность, это радует - работают в 1С
"спорить с вами без вариантов"(с)
Олег (comol).
Спорить с любым человеком "без вариантов", если собеседники не определились О ЧЕМ они спорят (разговаривают). Пожалуйста, перечитайте мою фразу (позицию, мнение) из (47) сообщения. И сравните со своими ответами. Темы обсуждения РАЗНЫЕ...
----
Одно из важных нововведений SQL2005 является <версионность>, т.е <пишущие> транзакции НИКОГДА не блокируют <читающих> транзакций. Для этого достаточно выполнить <ALTER DATABASE xxx SET READ_COMMITTED_SNAPSHOT ON> и база данных превращается в "версионную". Это нововведение позволит забыть проблемы "блокировок по таймауту" с которыми наша компания встречается ежедневно в виде обратной связи от 30 одновременно работающих пользователей. Мы рискнули и развернули БД на SQL2005, но режим "версионности" не включали.
--
Вопрос: включение версионности БД решит нам проблему "блокировок по таймауту" или для полноценного использования этого нововведения Вам нужно делать изменения в платформе ?
---
Ответ:
Нет, включение версионности не изменит поведения платформы. Использовать "версионность" SQL2005 не планируется.
Ну всё правильно:
- проблему так называемых "блокировок по таймауту" (интересно что под этим имели ввиду) вам версионность не решит. Решит только исправление аппаратного девайса ("hands") программистов :).
- Включение версионности действительно не изменит поведения платформы. А если вдруг у вас ещё и автоматические блокировки, то в принципе ничего не изменит :).
---
Цитата из текста статьи - "Включение уровня изоляции Read commited shapshot в MS SQL позволяет практически полностью избежать блокировок на уровне MS SQL при использовании управляемого режима"
--
Сопоставляем с (55) ... и?
В вашем случае опять же речь идёт о "взаимоблокировках". Потому как таймаут можно только так получить... Взаимоблокировки лечятся только ручками.. никакой "универсальной галочки" для этого нет, у меня речь идёт о вполне традиционных блокировках.
Естественно если deadlock-ов у вас нет, а есть timeout на ожидание то тогда нужно начинать конечно не с подобных статей... а с Чтения Дейта и Радченко :), а так же рассуждений о смысле жизни :)
Еще раз! Из ответа 1С разве не следует явно что поведение платформы не изменится? А значит блокировки (применительно к 1С) - останутся.
"В вашем случае опять же речь идёт о "взаимоблокировках". Потому как таймаут можно только так получить... " Хм, вы правда считаете, что блокировки могут быть только deadlock'овыми?))))) Неудачная попытка блокировки завершившаяся ввиду окончания выделенного таймаута - вполне обычная вещь в 1С 7.7, и вполне возможная в 1С 8.
Рискну предположить что вы не застали 1С 7.7 где можно было вдоволь налюбоваться на такие блокировки. восьмерочник небось
И - это не у меня. Прочтите внимательно (55). Это из партнерского FAQ. Данный вопрос я не задавал.
Самое интересное что на партнёрском форуме указанного сообщения не нашел :).
В 1С 7.7 конечно timeout без deadlock-а было нормальной ситуацией. Но в 1С 8 за такой таймаут нужно "руки программисту отрывать"... Я естествнно только про 1С 8 пишу, потому как 1С 7.7 система в сущности однопользовательская и ей "уже ничего не поможет" :).
цитата из C:/Program Files (x86)/1cv8/8.3.1.538/docs/ru/V8Update.htm
Работа с СУБД. Управляемые блокировки.
Как стало
При работе с Microsoft SQL Server версии 2005 и выше, используется режим управления версиями строк, если конфигурация использует режим управляемых блокировок. Используется уровень изоляции транзакций READ_COMMITED_SNAPSHOT. При чтении данных вне транзакций используется согласованное чтение.
Результат изменения
К уменьшению блокировок и взаимоблокировок при выполнении запросов, работающих в транзакции;
Исчезновению ошибок при выполнении запросов вне транзакции над часто модифицируемыми прикладными объектами;
Получению согласованных результатов отчета вне транзакции на момент выполнения отчета.
В результате, мы отказались от использования этих возможностей до приобретения дисковой полки - там посмотрим..
В нашем случае - tempdb - нагрузка выросла в пиках до 2х раз.
Процессор стал грузиться на 20-30% больше (2процессора х 4ядра).
Средняя нагрузка на процессор была 35%, в пиках до 80% (среднее по минуте). Когда стало до 100% - стало невозможно работать..
На сервере - 4 основных базы (Зарплата, Документооборот, Бухгалтерия, Самописная - на базе бухгалтерии).
Основная нагрузка идет от документооборота (Екатеринбург, Документооборот-Проф).
Пользователей - до 150 одновременно..
Ну про tempdb - это и так можно додуматься :)
На самом деле, принципиально - это не важно - включен он там или нет - работать будет. Но работать будет медленнее - версионирование съедает дополнительные ресурсы. А толку от этого никакого не будет..
Там это не к чему, так как к временной таблице одновременно доступ имеет только один породивший таблицу артефакт/объект/запрос..
Так а разница какая - что в первом случае 1С не догадалась изначально с рождением 8-ки пользовать управляемые блокировки?
Тогда причем тут "заставляем SQL работать как Oracle"? :)
работа в 1С В ПРИНЦИПЕ возможна только при наличии каких-либо блокировок (управ, неуправл, - лишь бы данные были "под присмотром").
Так и кто будет переводить на управляемые блокировки конфы? :)
Спасибо КЭП ;)
Вообще перевести на управляемые блокировки даже самую убогую конфу - дело нескольких дней максимум. Не говоря уже о том что все конфигурации 1С уже на управляемых блокировках
да? это как и перевод типовых на УФ - за неделю? :)
Где?
Если вы про "управляемый режим" - так он и так включен в свойствах конфы, и, если не ошибаюсь, "включение уровня изоляции" как раз и есть эта галочка "Режим управления блокировкой данных", - т.е. вы предлагаете включить то, что и так "включено" в типовых?
Но, как я помню, управляемые блокировки потому и "управляемые", что управляет им не 1с-платформа (аналогии не напрашивается на слова "1с платформа не управляет..."?), а устанавливается для всех и каждого из объектов блокировка, прописывается РежимБлокировкиДанных, и отслеживается блокировка/разблокировка по
Вот и спросил - кто сие делать будет? :)
- УФ никак не связаны с управляемыми блокировками
- Вы не совсем правильно понимаете разделение блокировок на блокировки СУБД и блокировки Сервера 1С. В случае управляемых блокировок существуют и те и другие
- Вы не совсем правильно понимаете смысл версионирования данных, и принципов его использования (в случае контроля остатков накладывается блокировка уровня сервера 1С и версионник не используется).
1.
2. comol, всё что вы понаписали верно только отчасти, какой части, RTFM.
3. Не забываем параметры 1211 и 1224 MS SQL, и помним что эскалация блокировок существует не только для записи, но и для чтения.
4. Размер "locks" для эскалации блокировок неявно присутствующей на сервере 1С установлен равной 20000 записей. По крайней мере мне о другом не известно.
1) Документ1 записывает данные в Регистр1
2) Документ2 читает данные из Регистра1
3) Документ1 записывает данные в Регистр2
На шаге 2) Документ2 получит данные из Регистра 1 с учетом движения Документ1 или нет ?
Т.к. неявная транзакция при проведении Документ1 еще не завершена...
Для меня было открытием что при базе MS SQL в режиме блокировочника на шаге 2 получаем ошибку блокировки, т.к. блокировка наложена записью в регистр Документом1. Я предполагал что блокировка будет снята после записи набора в Регистр1 и он будет доступен для чтения. Но я ошибался :-( Блокировка сохраняется до конца проведения документа, т.е. до окончания транзакции более верхнего уровня.
А еще больше огорчило что MS SQL накладывает блокировки по своему усмотрению и блокировки на уровне сервера приложений не возникает, а на уровне MS SQL возникает deadlock :-(
Вобщем режим версионника - единственный нормальный вариант повышения параллельности работы пользователей в 1С. В режиме блокировочника на практике проблема в принципе не решается :-( либо не получаем выигрыша либо еще хуже от дедлоков становится. Хотя в теории это возможно :-)
Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот
№ 91879
Создание 26.09.11 01:03
Обновление 27.09.11 00:20
Просмотры 102854
Загрузки 0
Рейтинг
150
Комментарии 127
Код открыт Не указано
Рубрики HighLoad оптимизация
Кому
Системный администратор
,
Программист
Тип файла Нет файла
Платформа Платформа 1С v8.3
Конфигурация Конфигурации 1cv8
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
