Как работают управляемые блокировки

Публикация № 1051660

Администрирование - Производительность и оптимизация (HighLoad)

Управляемые блокировки

121
Все типовые конфигурации содержат ошибки, потому как управляемые блокировки в 1С слишком уж "управляемые", при понижении уровня изоляции про некоторые "нюансы" просто забыли. Для создания и эксплуатации качественной системы, которая способна поддерживать транзакционную целостность данных при параллельной работе, информацию в этой статье желательно знать, хотя, конечно, ничего особо нового я не открыл.

Казалось, о работе сервера 1С и механизма блокировок за годы разработки уже знаешь всё, но 1С не перестаёт удивлять. Механизм управляемых блокировок создан 1С для того, чтобы по сути полноценно заменить механизм транзакционных блокировок на уровне сервера СУБД, отчасти из за политики "1С работает с любыми СУБД". Но на самом деле всё получилось не совсем так - далее проведём "лабораторную работу", и сделаем из неё выводы - в лучших традициях школьной физики :).

Итак начнём - простой кейс:

Конфигурация 2 объекта РС и Документ.

Конфигурация

Регистр сведений независимый, код следующий:

Блок кода 1

	Если Блокировать Тогда		
		Блокировка = Новый БлокировкаДанных();
		Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
		Элемент.Режим = РежимБлокировкиДанных.Исключительный;
		Блокировка.Заблокировать();
	КонецЕсли;
	
	Если ЧитатьЗапросом Тогда		
		Запрос = Новый  запрос();
		Запрос.Текст = "ВЫБРАТЬ
	            	   |	РегистрСведений1.Рес КАК Рес
	        	       |ИЗ
	    	           |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
		ТЗ = Запрос.Выполнить().Выгрузить();
	КонецЕсли;

	Если ЧитатьНабор Тогда		
		Набор = РегистрыСведений.РегистрСведений1.СоздатьНаборЗаписей();
		Набор.Прочитать();
	КонецЕсли;

	Если ЗаписатьНабор Тогда		
		Запись = набор.Добавить();
		Запись.Изм = Строка(Новый УникальныйИдентификатор());
		Запись.Рес = 3;	
		Набор.Записать();
	КонецЕсли;

Всё предельно просто.

Теперь Запускаем два сеанса.

Сеанс 1: Проводим документ с галкой "Блокировать". Ставим точку останова на строке:

"Если ЧитатьЗапросом Тогда".

Сеанс 2: Проводим документ с галкой "Читать запросом". 

Внимание вопрос: "Проведётся ли документ во втором сеансе или нет?"

Нам бы очень хотелось чтобы ответ на данный вопрос был "нет".

Тем не менее, документ проводится - без особых проблем.

 

Повторяем эксперимент - только во втором сеансе ставим галку "чтение набора"

Тот же вопрос "Проведётся?"

Очевидный ответ - "Конечно", ведь по сути что там что там чтение всего регистра.

Тем не менее наблюдаем примерно следующую историю: 

Конфликт блокировок

Таким образом, объектное чтение и чтение запросом работает по-разному. На мой взгляд, это в корне неправильно. При этом объектное чтение, очевидно, учитывает управляемые блокировки, а чтение запросом - ни коим образом.

Спойлер - эти тесты проводим пока в режиме "клиент-сервер".

Из эксперимента выше сделаем несколько первых выводов:

Вывод 1: 1С полностью игнорирует все управляемые блокировки при чтении в транзакции запросом.

Вывод 2: Объектное чтение и чтение запросом работает по разному

 

Тут можно сказать: "здравствуй фантомное чтение, неповторяющееся чтение". От "Грязного чтения" нас убережет MS SQL: в уровне изоляции READ COMMITED SNAPSHOT "грязное чтение" невозможно. Хотя я тоже сомневаюсь, потому как объектная модель 1С не полностью отражается в СУБД возможно могут быть нюансы, но примеров подобрать пока не удаётся.

 

Для того, чтобы понять на каком этапе своего развития в платформе 1С потеряли требование "согласованности данных" обратимся к истории.

Попробуем выполнить следующий код в разных версиях платформы:

 

Блок кода 2

	Запрос = Новый Запрос;
	Запрос.Текст = "ВЫБРАТЬ
	               |	СУММА(РегистрСведений1.Рес) КАК Рес
	               |ИЗ
	               |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1
	               |
	               |ДЛЯ ИЗМЕНЕНИЯ";
	Выборка = запрос.Выполнить().Выбрать();
	Выборка.Следующий();
	Количество = Выборка.Рес;
	
	
	
	Если Количество > 0 Тогда
		
		Запись = РегистрыСведений.РегистрСведений1.СоздатьМенеджерЗаписи();
		Запись.Изм = Строка(Новый УникальныйИдентификатор());
		Запись.Рес  = -1;
		Запись.Записать();
			
	КонецЕсли;

 

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

Этот код выполняется в транзакции - в обработке проведения документа в моём случае. Первую транзакцию нужно конечно остановить и попытаться провести вторую. По условию мы не должны уйти в минус.

 

1С 8.1  и ранее (ну или просто Автоматический режим блокировки)   

второй документ "висит на блокировке". После прохождения точки останова второй документ проводится, запись в РС не создаётся.

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

Секрет конечно в инструкции "для изменения", которая кроме всего прочего превращает S блокировку в U.

На уровне СУБД уровень изоляции MS SQL - SERIALIZABLE. MS SQL блокирует всё что надо и не надо. Чтобы получить несогласованные данные  надо очень постараться.

Но с параллельной работой в таком варианте конечно будут трудности, всем известно какие.

 

1С 8.2 и первые версии 8.3 (режим управляемых блокировок)

Появились "Управляемые блокировки". Самое главное что происходит с MS SQL при установке "управляемой блокировки" - уровень изоляции становится "READ COMMITED". 

Чтобы включить его в последних редакциях 8.3 нужно выполнить:

ALTER DATABASE databasename
SET ALLOW_SNAPSHOT_ISOLATION OFF
GO
ALTER DATABASE databasename
SET READ_COMMITTED_SNAPSHOT OFF
GO

Здесь уже немного похуже. Если точку останова в коде поставить после записи - всё отработает как и в предыдущем примере - транзакция установит X блокировку и всё будет OK. А вот если точку останова поставить после чтения - получим совместимые S блокировки - одна и та же информация будет считана двумя транзакциями.

Конечно данный уровень изоляции уже не охраняет нас от ошибок "фантомного" и "неповторяемого" чтения.

В приведённом примере, тем не менее, в большинстве случаев всё будет работать верно, потому что всё-таки поведение системы в транзакции более-менее прогнозируемо - если данные считаны, то на них устанавливается как минимум S блокировка. 

Конечно нужно добавить в этот код начало вроде:

		Блокировка = Новый БлокировкаДанных();
		Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
		Элемент.Режим = РежимБлокировкиДанных.Исключительный;
		Блокировка.Заблокировать();

и нам уже ничего не страшно.

Зачем я тогда делаю на этом акцент?

В данном примере вы читаете остатки (по сути) - их конечно нужно блокировать.

Но если у вас в транзакции происходит чтение элемента справочника, который в данный момент может изменять другая транзакция?

Вот тут как раз S блокировка очень сильно пригодилась бы. Но об этом дальше.

 

Современные версии 1С 8.3

Возвращаем обратно режим версионника:

ALTER DATABASE databasename
SET ALLOW_SNAPSHOT_ISOLATION ON
GO
ALTER DATABASE databasename
SET READ_COMMITTED_SNAPSHOT ON
GO

Выполняем код - получаем "-1" как в случае установки "точки останова" при чтении, так и в случае установки "точки останова" при записи.

Теперь можно сделать ещё один вывод:

Вывод 3: чем современнее версия 1С, тем больше возможности для параллельной работы и тем меньше шансов обеспечить согласованность данных.

 

А теперь "Гвоздь программы": файловая база - код приведенный в блоке кода 1 выполняем в ней. Единственное изменение - код чтения данных из регистра придётся перенести в обработку, т.к. в файловой базе два одинаковых документа параллельно провести не получится.

В обработке будет код:

      НачатьТранзакцию();
	  	 	Запрос = Новый  запрос();
			Запрос.Текст = "ВЫБРАТЬ
	            	   |	РегистрСведений1.Рес КАК Рес
	        	       |ИЗ
	    	           |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
			ТЗ = Запрос.Выполнить().Выгрузить();
	  ЗафиксироватьТранзакцию();

В документе ставим галку "блокировать" и точку останова, выполняем обработку - уверенно висит на блокировке. 

Убираем галку "блокировать" в документе (но не точку останова) конечно без проблем читает регистр.

Итак, в завершение "чудес" управляемых блокировок получаем их разную работу в файловой и клиент-серверной версии.

Вывод 4: Управляемые блокировки в файловой и клиент-серверной версиях работают по-разному. В файловой - "нормально".

 

Теперь о косяках в типовых. Для примера возьму УТ 11.

Перед записью в набор движения естественно читаются, происходит это в функции "ТекстЗапросаТаблицаТоварыНаСкладах(Запрос, ТекстыЗапроса, Регистры)" - для Товаров на складах. 

Так вот, "косяк" потенциально будет во всех строчках этого запроса где "точка" фигурирует дважды:

"КОГДА ЕСТЬNULL(ТаблицаТовары.Назначение.ДвиженияПоСкладскимРегистрам, ЛОЖЬ)"

"И (НЕ ТаблицаТовары.Склад.ИспользоватьОрдернуюСхемуПриОтгрузке

И ТаблицаТовары.Номенклатура.ТипНоменклатуры В"

Что в этом плохого? 

Ну вот представьте - начали вы проведение документа пока склад ещё был не ордерным, а в процессе проведения кто-то его поменял на ордерный...

Или тип номенклатуры сменил с "товара" на "услугу". Он это сможет влёгкую сделать. А вы потом не сможете доказать что "когда я нажимал кнопку всё было хорошо". Все проверки, включая конечно "обработку проверки заполнения" документ пройдёт ещё до изменения данных. 

Кроме того - есть прекрасная возможность в один регистр записать данные исходя из информации что склад ордерный, а в другой - нет, и всё это в одной транзакции. Это и есть так называемое "фантомное чтение", которое, как мы помним, для "READ COMMITED SNAPSHOT" вполне возможно. 

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

"Эти справочники защищены от изменений, не так всё просто" - напрашивается комментарий. На самом деле всё просто. Распределенная база, полный обмен. Задано небольшое число элементов в транзакции. В каждом справочнике есть код:

Процедура ПередЗаписью(Отказ)

	Если ОбменДанными.Загрузка Тогда
		Возврат;
	КонецЕсли;

Который отключает все эти проверки. В удаленной базе они могли быть пройдены, но на тот момент в ней не было актуальной копии документов, или вообще не было и не будет этих документов.

Для корректной работы проведения документа нужно чтобы на все считываемые неявным соединением таблицы накладывались разделяемые блокировки.

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

Вывод 5: В типовых конфигурациях не учитывается необходимость блокировать записи таблиц с которыми происходит неявное соединение при проведении

Что делать я думаю понятно? Если есть параллельная работа в базе - реально параллельная, то по-хорошему при проведении документа нужно накладывать ещё кучу разделяемых блокировок, которые помогут избежать подобных ситуаций.

Почему на это не особенно обращают внимание? Да потому что эти ошибки видны только в случае реальной параллельной работы большого количества пользователей, да и то крайне редки. Если у вас много пользователей в базе 1С, у вас скорее всего наберётся несколько куч проблем более актуальных, чем описанный выше кейс. Ну а у кого всё хорошо и все вопросы решены скорее всего уже правильно расставлены блокировки, и такие крупные компании редко работают на типовых базах. Но вообще знать о таком "поведении" платформы нужно, как и учитывать его в проектах, которые ориентированы на большое количество параллельно работающих пользователей. Ведь пока мы (1С-ники) не научимся корректно работать с системами, в которых 1000+ активных пользователей и обеспечивать в них согласованность данных SAP нам на рынке не подвинуть. 

P.S. Всё описанное выше "не баг а фича", вполне нормально документировано на ИТС, который всё равно никто не читает  на котором вы можете детально ознакомиться с описанием работы управляемых блокировок "от Вендора" https://its.1c.ru/db/v8314doc#bookmark:dev:TI000000535 

P.P.S. Если это прочитают коллеги из 1С - тут нет "камня в огород типовых" или в сторону реализации управляемых блокировок (хотя конечно хм...). Из статьи выше должно по задумке стать очевидным, что прикладным разработчикам очень не хватает возможности выбирать уровень изоляции с которым будет начинаться транзакция (в т.ч. неявная). READ COMMITED для проведения документов списания товара это слишком лайтово. Всех косяков, с этим связанных, не выловить.
 

121

Специальные предложения

Лучшие комментарии
177. kolya_tlt 08.05.19 15:53 Сейчас в теме
Люто плюсую по выводу №5. Но моя практика показала, что платформа просто не справляется с таким количеством блокировок. Сервер 1С просто ложился каждые два часа. Кейс был абсолютно такой же - движения документа зависели от галок номенклатуры и мы блокировали ссылки номенклатур документа, который проводится. Пришлось от этой идеи отказаться :(
acanta; comol; +2 Ответить
165. alex_sh2008 4 07.05.19 18:35 Сейчас в теме
(164)Уровни изоляции уже есть в скл сервере, в 1С достаточно просто транслировать объектные блокировки на реляционную базу, а то что сейчас сделали мне вообще не понятно.
Остальные комментарии
Избранное Подписка Сортировка: Древо
1. w.r. 476 29.04.19 19:50 Сейчас в теме
15. starik-2005 1971 30.04.19 10:44 Сейчас в теме
16. comol 4082 30.04.19 11:28 Сейчас в теме
(1) Правильная и хорошая статья. То о чём я пишу в своей на ИТС конечно не напишут. Вернее инфу можно найти и на ИТС, мелким шрифтом в разных местах, не в базовой статье конечно
37. w.r. 476 30.04.19 20:23 Сейчас в теме
(16)

К слову, про файловые и клиент серверные версии, есть такая табличка с сайта 1С, которая абсолютно все объясняет

39. comol 4082 30.04.19 22:29 Сейчас в теме
(37)
которая абсолютно все объясняет

Как бы мне хотелось чтобы это было так.
Конечно она не объясняет почему управляемые блокировки - пусть даже не всю таблицу в файловой и клиент серверной версии работают по-разному
41. acanta 74 30.04.19 22:31 Сейчас в теме
(37) эта табличка показывает как правильно называется составляющие технического решения Сама проблема в применении к 1с в том, что специалист по sap (например) при переходе с 1с на что то другое имеет и квалификацию и полномочия и возможность прямого доступа к данным при помощи СУБД не используя ни код ни платформу ни лицензии 1с.
Достаточно описания структуры метаданных.
А 1с ник при такой работе с данными чего то нарушает, а без соответствующего сертификата ещё и не имеет необходимой квалификации.
"либо крестик снимите либо трусы наденьте."
38. w.r. 476 30.04.19 20:26 Сейчас в теме
(16)

И ещё вопрос - зачем для чтения (ЧитатьЗапросом) используете исключительную блокировку, а не разделяемую
40. comol 4082 30.04.19 22:30 Сейчас в теме
(38) Ну для контроля остатков должна быть исключительная... А то ведь кто-то ещё прочитает
45. w.r. 476 30.04.19 23:10 Сейчас в теме
(40)

Это только мое предположение, но мне кажется, что дело здесь в объекте НаборЗаписей. Платформа его интерпретирует как объект, производящий запись данных (даже только при чтении набора) и работает с ним не так, как с объектом Запрос. Я бы обратился с этим вопросом в поддержку фирмы 1С ради интереса
48. comol 4082 30.04.19 23:35 Сейчас в теме
(45) Всё так. И это будет официальная позиция 1С. Но суть в том что чтобы правильно наложить все блокировки при чтении запросом нужно или выполнить его дважды или полноценно разбирать, а это уже сделать из 1С сервер СУБД по сути :)
49. acanta 74 01.05.19 08:53 Сейчас в теме
(48) Ни менеджер среднего звена ни бухгалтер с екселем и выгрузкой из СУБД тоже в этом комбайне не нуждаются. А для операторов достаточно любой (той же веб надстройки над любой СУБД) для формирования и распечатки первички.
И тогда все те же блокировки возникают на уровне коммуникации между людьми и решаются так же.
Если есть проблемы с коммуникациями, то полноценно заменить их при помощи 1с не получится.
И если за 20 лет существования 1с проблема параллельной работы с контролем остатков не решена до сих пор, значит на нее нет спроса в данном сегменте.
А те сегменты где такая потребность есть уже давно заняты.
50. comol 4082 01.05.19 12:49 Сейчас в теме
(49)
А те сегменты где такая потребность есть уже давно заняты

И будут заняты другими пока проблема не будет решена :)
51. starik-2005 1971 01.05.19 15:06 Сейчас в теме
(49) проблема решается тем, что остатки контролируются после записи движений. И тот документ, при проведении которого зарегистрирован минус, просто отменяет транзакцию. Это сложно понять современным 1С-никам, но, с другой стороны, и не надо - без них разберутся.
Akvals; vano-ekt; chernov.gigansk.ru; zakiap; acanta; +5 Ответить
52. acanta 74 01.05.19 15:10 Сейчас в теме
(51) зарегистрирован минус на когда?
При одновременном проведении двух документов с одинаковым временем запрос это вообще может определить?
53. starik-2005 1971 01.05.19 15:55 Сейчас в теме
(52) ну у обоих пользователей документ не проведется, что такого? Фактически две транзакции. В первой остаток меняется, во второй меняется, вот первая транзакция записывает регистр, в это время в модуле регистра срабатывает событие "при записи", там читается остаток по отбору из записанного уже набора записей и проверяется, есть ли минус. Если есть - отказ. То же самое во втором документе. Если у обоих внезапно стал минус - ну оба отвалятся и потом кто-то снова проведет документ.

Сам SQL (если говорить о СУБД) не пишет данные одновременно - он одновременно в очередь поместить может. А пишет отдельный поток.

ЗЫ: Вообще в компьютере нет ничего "одновременного" в плане записи на один диск. И для целостности софт делает sync, чтобы быть уверенным в изменениях. А вот при чтении мы можем что-то взять из кеша дважды, но, опять же, кеш обнолвляется при записи, которая не одновременна. Такой вот "парадокс".
54. acanta 74 01.05.19 16:16 Сейчас в теме
(53)Вы меня простите, не хочу никого обидеть. Но вот есть два спринтера. Они пересекают финиш и срывают ленточку одновременно. Приз достанется кому то одному, что тут такого.
Но журнал регистрации отключен в конфигураторе, а запросы к журналу транзакций превратили бы 1с в СУБД, а если учитывать файловую систему с кэшами и буферами то и в ось..
И вот уже программист 1с заводит регистр сведений и прописывает очередь проведения с учётом приоритета пользователей по своему усмотрению.
Сначала проводить все документы Тани, затем Васи и и только потом МарьИвановны. И все они на процентах.
59. starik-2005 1971 01.05.19 20:53 Сейчас в теме
(54) ну вот пересекают они финишь, но один оказался в очереди раньше - никуда не деться. И второй при записи регистра упирается в Х-блокировку ресурса уже на сервере SQL и будет ждать. Если регистры во всех документах записываются в одной последовательности, то дедлока не будет - будет простая очередь ожидания. Именно для этого в свое время придумали механизм записи регистров при записи документа - там последовательность строго блюдется. А еще в УПП лет сто назад (в 8.1) контроль регистра остатков был сделан в модуле набора записей этого регистра. И ничего не тормозило у товарищей с нормальной техникой, и никогда (ни разу) не было никаких случайных отрицательных остатков. Читайте "библию разработчика 1С" - там это уже лет надцать как описано. А то, что себе придумывают люди - это от незнания.
55. alex_sh2008 4 01.05.19 18:17 Сейчас в теме
(51) С таким подходом производительность вашего приложения упадет в разы на больших нагрузках
46. SanchoD 164 30.04.19 23:22 Сейчас в теме
(40) Сейчас в тренде новый подход к проведению. Сначала проводим документ as is. А потом снимаем остатки на регистрах. Вышли в минус - откатываем транзакцию.
zakiap; w.r.; acanta; +3 Ответить
47. comol 4082 30.04.19 23:34 Сейчас в теме
(46) "Сейчас" это лет 5 или 6 вроде? :)). Но суть дела не меняет - всё равно надо накладывать исключительную блокировку.
56. alex_sh2008 4 01.05.19 18:19 Сейчас в теме
(47)Не только исключительную но и уменьшать количество записей в одной транзакции, лучше сделать несколько последовательных транзакции ,1 строка 1 транзакция , чем 1 транзакцию для записи 100 строк.
57. acanta 74 01.05.19 18:43 Сейчас в теме
(56) даже в этом случае документ или справочник с табличными частями при изменении или добавлении строки будет записан целиком. Или нет?
58. alex_sh2008 4 01.05.19 19:33 Сейчас в теме
(57) На ваши транзакции наложится еще главная транзакция на весь документ или справочник. Поэтому все эти танцы с бубнами просто пустая затея. Не забывайте есть транзакция 1С и транзакция сервера базы данных, это разные вещи, если вы делаете блокировку в коде 1С это во все не означает что эта блокировка происходит на sql сервере, блокировки на скл сервере включаются только тогда когда действительно происходит запись/чтение данных самой 1С. Чем быстрее будет выполнен код 1С в транзакции тем меньше будет блокировок.

Если хотите добиться максимальной параллельности выполнения транзакций:
1. максимально исключите использование табличных частей у документов и справочников.
2. Используйте минимум транзакций в своем коде, включайте транзакции только тогда когда это действительно необходимо.
3. Не выполняете в транзакции какие либо емкие операции
4. проверяйте остатки и другие параметры не во время записи данных, а во время подготовки данных перед записью, до начала основной транзакции записи данных. Например во время редактирования данных в табличной части документа.
creatermc; Aleskey_K; zakiap; acanta; +4 Ответить
61. acanta 74 01.05.19 22:54 Сейчас в теме
(58) не понимаю, вы хотите сказать что блокировка сервера 1с накладывается на объект метаданных 1с (например документ или справочник с табличными частями, но без подчинённых справочников или записей регистра сведений)
62. alex_sh2008 4 01.05.19 22:59 Сейчас в теме
(61)Ну да, за исключением документов, все движения тоже по падают в транзакцию и блокируются (в зависимости от режима записи/чтения)
60. comol 4082 01.05.19 22:49 Сейчас в теме
(56)
лучше сделать несколько последовательных транзакции ,1 строка 1 транзакция , чем 1 транзакцию для записи 100 строк

лучше конечно... но согласованность данных при такой истории обеспечить намного сложнее.
63. alex_sh2008 4 01.05.19 23:03 Сейчас в теме
(60)Это вопрос планирования архитектуры приложения и методик разработки. Много конечно из 1С не выжать но что то можно.
2. Evil Beaver 6347 29.04.19 20:23 Сейчас в теме
Читал-читал, а все свелось к тому что "блокируйте все, что надо и не блокируйте то, чего не надо"...

В свое время управляемые блокировки мне коллега объяснил, как мьютекс. Блокировка это мьютекс. Обьектное чтение захватывает его автоматом, а запрос - нет. Вот и все объяснение.

А писать параллельный код правильно - да сложно, и без косяков никак. Тут Олег прав :)
17. comol 4082 30.04.19 11:30 Сейчас в теме
(2) свелось к тому что "блокируйте всё что надо, само не заблокируется за вас" :).
Технически там наверное всё-таки не мьютекс.... надо доп. инфу хранить и между серверами синхронизировать.
в SQL захватывается автоматом, а в 1С этого не стали делать... я думаю просто потому что очень сложно реализовать технологически.
197. Evil Beaver 6347 12.05.19 19:34 Сейчас в теме
(17) "Мьютекс" - это абстрактно, чтобы было проще объяснить принцип: захватил/отпустил. А что там внутри - это один БГ ведает.
3. Rustig 1201 29.04.19 21:38 Сейчас в теме
(0) интересная работа!
то, что система несовершенна - стало очевидным.

а если абстрагироваться от названий "автоматический" и "управляемый", можно ли огласить (описать) алгоритм "на пальцах" - как должна вести себя блокировка записей таблиц при параллельной работе пользователей?
(желательно на примере) есть у кого красивая идея?
18. comol 4082 30.04.19 11:30 Сейчас в теме
4. Rustig 1201 29.04.19 21:43 Сейчас в теме
(0) в 8.1 (на обычных формах) всегда была возможность программировать свою функциональность по блокировкам - то есть в каждом конкретном случае разработчику приходилось прорабатывать механизм и тестировать все варианты "идеальной" параллельной работы самим, не надеясь на встроенный механизм автоматич. блокировок.
как сейчас усложнилась технология на управляемых формах - не знаю. наверное, усложнилась...
5. bulpi 157 29.04.19 23:11 Сейчас в теме
Я знал! Я предполагал! Я чувствовал! Автор молодец, грамотно изложил мои подсознательные подозрения :)
6. par_62 30.04.19 06:46 Сейчас в теме
Нет программ,в которых " и рыбку съесть и ... ( по тексту)". Обычно оценивается вероятность тех или иных событий. Вероятность изменения неордерного склада на ордерный - минимальна в процессе работы и обычно выполняется только специалистом учета или администратором системы. Если это нет - вопрос к организаторам учета на предпииятии и к специалистам внедрения.
vdscom; Alias; +2 Ответить
19. comol 4082 30.04.19 11:32 Сейчас в теме
(6) всё так конечно... просто задача хорошей ИС обеспечить согласованность данных при любой ситуации...
7. Kami4 30.04.19 07:21 Сейчас в теме
Возьму на заметку, всё подробно и с полным анализом!
8. Rustig 1201 30.04.19 07:33 Сейчас в теме
На мой взгляд, проблема блокировок заключается в том, что пока не закончилась транзакция операции, кто-то пытается изменить что-то связанное с данной операцией. Чем длительнее транзакция, тем более вероятно, что будут блокировки.
Отсюда рекомендация - сократить транзакции по времени.
К примеру, при проведении документа запускаются 10 проверок, сведения записываются поочередно в разные 10 регистров накоплений, и все это в одной транзакции. Возможно, стоит попробовать отделить какой-то регистр , и записывать в него в отдельной транзакции - в другом месте и в другое время....
В свое время я доработал отправку счетов по электронке - создал кнопку - так в период массовых рассылок - когда три бухгалтера отправляют в течение часа по 20 писем - стали возникать блокировки... Когда письмо уходит через электронную почту - транзакция по времени становится длительной - ждем ответа от электронки - ушло письмо или нет, чтобы изменить статус письма в 1С...
Тогда я создал регистр сведений "Очередь отправки писем". Блокировки исчезли, поскольку письма вставали в очередь мгновенно, а отправкой занимался робот в фоновом режиме...Делал на платформе 8.1 на БП 1.6 лет 5 назад. До сих пор работают по этой схеме.
В дальнейшем в УТ 11 перешли на расчет себестоимости при проведении реализации в отдельной транзакции - в другом месте и в другое время. Так они сократили время транзакции проведения реализации, и уменьшили вероятность возникновения блокировок.
9. nvv1970 30.04.19 07:54 Сейчас в теме
Олег, может объясните что делает флаг ALLOW_SNAPSHOT_ISOLATION? К чему этот привет из прошлого?
1с его сто лет как не использует для переключения снепшотов. А msdn как-то не до конца понятно это объясняет. Например, здесь достаточно подробно (хотя это и не документация) https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server. Однако, snapshot и rcsi - это два разных уровня изоляции, а речь вроде как об уровне snapshot.
20. comol 4082 30.04.19 11:42 Сейчас в теме
(9) Ну насколько я помню этот флаг включает версионник для базы в MS SQL. Без него read commiten snapshot не включите.
В последних версиях MS SQL он включен по умолчанию при создании новой БД, видимо 1С это детектит.
В статье речи об уровне изоляции snapshot нет - везде конечно read commiten snapshot. Сам уровень изоляции snapshot прокомментировать не могу - не разбирался. 1С его не использует.
24. nvv1970 30.04.19 12:00 Сейчас в теме
(20)
В статье речи об уровне изоляции snapshot нет - везде конечно read commited snapshot. Сам уровень изоляции snapshot прокомментировать не могу - не разбирался. 1С его не использует.
Да, все верно. Snapshot будет тяжеловат для 1С. Не встречал, чтобы его использовали где-то... Поспрашиваю на sql.ru
Ну насколько я помню этот флаг включает версионник для базы в MS SQL. Без него read commiten snapshot не включите.
В последних версиях MS SQL он включен по умолчанию при создании новой БД, видимо 1С это детектит.
А вот тут - НЕТ.
Прикрепил файлик... Нигде, кроме master и msdb данный режим не используется. Это собственно два разных, режима. И на сколько я понимаю по различным описаниям на msdn - никак не пересекающихся. Один флаг отвечает за включение версионирования уровня RCSI, второй Snapshot. Думал, что вы, как человек бывалый, мне про это подробнее ответите )) Очевидно, что платформа первым флагом не оперирует. А рекомендация устанавливать два флага появилась с каких-то бородатых годов и сейчас вероятно не актуальна. SI появился кажется в 2005. И возможно там нужно было оба флага устанавливать.
Прикрепленные файлы:
25. comol 4082 30.04.19 12:06 Сейчас в теме
(24)
А рекомендация устанавливать два флага появилась с каких-то бородатых годов и сейчас вероятно не актуальна


Ну вообще 2017 год MSDN:

The following statements activate snapshot isolation and replace the default READ COMMITTED behavior with SNAPSHOT:

SQL

Копировать
ALT ER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON

ALT ER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON

Я не разработчик Micrisoft и даже не MVP по MS SQL, поэтому обычно следую документации если это работает.

А ещё я буду долго ржать если второй флаг без первого не работает и 1С по факту не использует версионность :)))))))))))))))
30. nvv1970 30.04.19 13:11 Сейчас в теме
(25) В документации же нет указания "нажимать все кнопки одновременно" )) Скорее трудности перевода.
Это два разных уровня изоляции. С разным поведением для чтения и модификации, с разными сценариями использования, с разной нагрузкой на tempdb. Достаточно погуглить Read committed Snapshot Isolation VS Snapshot Isolation
В общем случае MS не рекомендует использовать SNAPSHOT ISOLATION, а ограничиваться RSCI.

А то что флаг READ_COMMITTED_SNAPSHOT точно работает без ALLOW_SNAPSHOT_ISOLATION проверял лично еще на совместимости 8.2.16 - при равномерной нагрузке продуктовой базы поведение в части блокировок СУБД ну очень явно отличалось.
42. comol 4082 30.04.19 22:33 Сейчас в теме
(30)
А то что флаг READ_COMMITTED_SNAPSHOT точно работает без ALLOW_SNAPSHOT_ISOLATION

Ну верю... Не только у 1С есть косяки в документации

MS не рекомендует использовать SNAPSHOT ISOLATION

ХЗ что это такое. Его никто не использует

Скорее трудности перевода.
у меня всё норм с английским. По-другому перевести фразу "выполните эти инструкции SQL чтобы включить Read commited snapshot вместо Read commited" трудно.
198. Evil Beaver 6347 12.05.19 19:37 Сейчас в теме
(25)
и 1С по факту не использует версионность :)))))))))))))))


Использует. На ИС, по-моему, Андрей Бурмистров, показывал графики с разницей замеров между режимами.
10. frkbvfnjh 558 30.04.19 08:46 Сейчас в теме
Еще больше запутался с этими блокировками, теперь ваще не хочу программировать на 1С. Держать столько нюансов по работе с блокировками в голове, которые к тому же еще и меняю от платформы к платформе - это не нормально и не реально. Пока 1С определится как им нужно работать с блокировками пострадает много народу
acanta; wowik; +2 Ответить
11. Rustig 1201 30.04.19 09:24 Сейчас в теме
(10) волков бояться - в лес не ходить - и на первомайские шашлыки не ездить... :)
13. nvv1970 30.04.19 09:45 Сейчас в теме
(10) стоп-стоп.... никакой путаницы нету )))
Может автор немного сумбурно что-то изложил - так это только потому, что затронуты лишь отдельные специфические моменты, а не представлена вся система целиком.
В 1с нет ничего загадочного и нового, что есть в мире программирования, и все предельно просто.
Практически все лежит не в технической плоскости, а в плоскости логики и математики.
Что касается механизма управляемых блокировок, то он намного проще (на много порядков), чем блокировки СУБД (я вам не скажу за всю Одессу, а за MSSQL - скажу).

"пока создатели автомобилей не определятся куда водителям ехать - пострадает много народу"
Что это за.... ? ))) Как работать с блокировками - должна определиться не 1С, а автор программного кода, т.е. вы сами. По моему статьи про яблоки более чем достаточно. А детали поведения платформы (неявные управляемые блокировки) описаны в документации и немного в статье. Вы их должны знать. А наиболее очевидно и просто выяснить что генерирует блокировки, а что нет - посмотреть по техжурналу.
CSiER; Dach; comol; +3 Ответить
12. Dach 284 30.04.19 09:39 Сейчас в теме
Куда печальней, что нет нормальных инструментов, позволяющих с помощью менеджера 1с-ных блокировок посмотреть - какие блокировки наложены, на какие таблицы, кем и когда, с возможностью адекватного их завершения и т.д. Мониторить все это дело нечем, грубо говоря. И ТЖ тут тоже не особо помощник
babys; herfis; acanta; Rustig; comol; YPermitin; +6 Ответить
14. YPermitin 5599 30.04.19 10:44 Сейчас в теме
(12)
ожностью адекватного их завершения и т.д. Мониторить все это дело нечем, грубо говоря. И ТЖ тут


А чем ТЖ не устроил в этом плане? Он фактически всегда дает ответы на вопросы:
- Кто поставил
- На что
- Сколько длится блокировка
- Причины конфликтов

С помощью ТЖ можно практически в реальном времени мониторить блокировки, если нужно. Такой опыт есть, даже где-то на ИС такое реализовывали. Но зачем? В нагруженных системах этот онлайн-мониторинг столько данных будет показывать, что стане бессмысленным.

Раскройте подробнее посыл, интересно узнать что еще нужно.
21. comol 4082 30.04.19 11:49 Сейчас в теме
(14) И умирает сервер если в ТЖ блокировки включить. А их надо бы как то фоново онлайн собирать - как MS SQL делает.
22. YPermitin 5599 30.04.19 11:55 Сейчас в теме
(21) Смотря как настроить и что искать. :) Возможно конфигурация, когда влияние сбора ТЖ будет минимальным.

Но, согласен. У SQL Server инструменты гораздо лучше в этом плане.
23. comol 4082 30.04.19 11:59 Сейчас в теме
(22)
Смотря как настроить
Запись всех блокировок в текстовый файл... ну это убийство дисковой подсистемы при любом раскладе. ИМХО конечно, но у меня настроить так чтобы работало быстро не получается....
26. nvv1970 30.04.19 12:07 Сейчас в теме
(23) вы о упрблокировках 1с? Неожиданно... Если исключить <property name="Locks"> и хоть какого-то порог длительности установить, то все весьма компактненько...
27. comol 4082 30.04.19 12:08 Сейчас в теме
(26) а если установить порог и длительность смысл их вообще собирать? :)))))
YPermitin; +1 Ответить
28. YPermitin 5599 30.04.19 12:21 Сейчас в теме
(27) обычно сбор ведь идет уже тогда, когда знаешь что ищешь.

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

Да что мы спорим :)
ТЖ это монстр, который надо готовить по необходимости)))

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

Если нужен прямо онлайн мониторинг, то пробовать отдельные диски и сервер для анализа данных с Эластиком!
31. comol 4082 30.04.19 14:18 Сейчас в теме
(28)
сбор ведь идет уже тогда, когда знаешь что ищешь

Сбор обычно идёт когда уже что то случилось и надо понять что...

Онлайн с ТЖ не получится... в Elastic тоже надо сначала выгрузить...
29. Rustig 1201 30.04.19 13:01 Сейчас в теме
(14) есть инструменты как консоль запросов, консоль заданий - открыл и мониторишь - вот такой инструмент нужен.
В сравнении с ТЖ - ТЖ перегруженный неудобный сложный. Консоль заданий - открыл и мониторишь...

Есть задачи и в не нагруженных системах - при которых было бы полезно мониторить блокировки. Да и потом в мониторе блокировок должен быть фильтр по объектам , которые мониторим...
YPermitin; +1 Ответить
36. YPermitin 5599 30.04.19 17:42 Сейчас в теме
(29) (33) Поддерживаю.

Вот был бы аналог Extended Events, то жизнь стала бы проще.

Сейчас удавалось передавать асинхронно данные ТЖ в ElasticSearch с помощью утилиты на .NET Core (C#). Но событий было ограниченное количество, т.к. фильтры были установлены. Сам ТЖ за сутки набирал всего 2 ГБ. Что будет, если собирать все блокировки не могу сказать. Возможно, что передача данных в ES займет значительный объем ресурсов.
85. DonAlPatino 130 06.05.19 13:03 Сейчас в теме
(36) Отдельная статья с рассказом "как готовить ТЖ и ЕЛКу" будет?
86. YPermitin 5599 06.05.19 13:05 Сейчас в теме
(85) а нужно?

В том плане, что об этом вроде и так много сказано. Даже на ИС был материал.
87. DonAlPatino 130 06.05.19 13:05 Сейчас в теме
(86) Пропустил видимо :-( Пошел искать...
88. YPermitin 5599 06.05.19 13:06 Сейчас в теме
(87) не найдете - пишите. Что-нибудь придумаем :)
33. Dach 284 30.04.19 15:39 Сейчас в теме
(14) в том то и дело, что собирать с помощью ТЖ все блокировки 1с-ные - тяжко как для сервера, так и потом для анализа.

А хотелось бы вот что: ставишь в консоли администрирования "Пороговое время = N минут", показать все блокировки, которые висят дольше порога. Фильтр на таблицы метаданных тоже бы неплохо. Нет, может я чего-то не знаю и такое уже кто-то сделал? Просто у менеджера блокировок ведь есть эта информация! Он же как-то дает это понять другим сеансам, другим rphost ну и т.д.! Взаимодействие между процессами и т.д. и т.п. Просто дайте нам тоже посмотреть, вот и все. Хотя бы посмотреть
herfis; Rustig; YPermitin; +3 Ответить
32. PerlAmutor 46 30.04.19 14:55 Сейчас в теме
(0)

Если Блокировать Тогда
Блокировка = Новый БлокировкаДанных();
Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
Элемент.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();
КонецЕсли;

Если ЧитатьЗапросом Тогда
Запрос = Новый запрос();
Запрос.Текст = "ВЫБРАТЬ
| РегистрСведений1.Рес КАК Рес
|ИЗ
| РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
ТЗ = Запрос.Выполнить().Выгрузить();
КонецЕсли;
Показать

Если после установки исключительной блокировки, таки прочитать что-нибудь из этого регистра сведений в той же транзакции. Блокировка на чтение сработает?
43. comol 4082 30.04.19 22:35 Сейчас в теме
(32)
той же транзакции
хоть заблокируйтесь и зачитайтесь :). Блокировка нужна для защиты от других транзакций.
66. PerlAmutor 46 03.05.19 06:09 Сейчас в теме
(43) Я о другом. В примерах, везде где ставится явная блокировка, впоследствии идет чтение данных и блокировка ставится на основании того, какие измерения были считаны. После этого в других транзакциях уже нельзя писать/читать те же измерения, что были заблокированы в первой транзакции. В статье идет установка блокировки, но, видимо, данные не читаются, так как для этого должны стоять две галочки одновременно и "Блокировать" и "ЧитатьЗапросом". Какая именно комбинация галочек установлена из статьи непонятно.
67. comol 4082 03.05.19 13:54 Сейчас в теме
(66) ничего не понял про галочки. В примере данные лочатся а потом читаются. Блокируется весь регистр потому что лень было делать более полноценный пример
68. PerlAmutor 46 03.05.19 15:23 Сейчас в теме
(67) Я сделал тестовую обработку, чтобы воспроизвести эффект, когда блокировка на чтение не ставится при явном задании исключительного варианта. Пробовал на 3 версиях платформы: 8.2, 8.3.7, 8.3.13. На трех конфигурациях ERP, ЗУП 2.5, БП2.0. Поведение везде одинаковое - регистр блокируется от чтения. Возможно дело именно в том, что если перед чтением данных не ставить никаких блокировок, то платформа даст это сделать, так как не будет выполняться попытка сравнения совместимости установленных блокировок (Исключительная+Никакая = Дает читать, Исключительная+Исключительная = Не дает читать) ?
Прикрепленные файлы:
ТестБлокировки.epf
69. comol 4082 03.05.19 18:42 Сейчас в теме
70. PerlAmutor 46 03.05.19 19:25 Сейчас в теме
(69) Все 3 базы клиент-серверные, на продакшене.

В общем я проверил. Заблокировал "Справочник.Пользователи", если открывать его в другой сессии или использовать консоль запросов, то данные из него прекрасно читаются. Но если запустить эту же обработку и попробовать установить Блокировку, то через 20 секунд выдает ошибку
"Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки"

Т.е. через управляемую блокировку можно обезопасить от чтения - идентичные объекты в разных сессиях с одним и тем же кодом, где идет попытка установки несовместимой блокировки. От запросов без использования объекта БлокировкаДанных - это не спасает.
71. PerlAmutor 46 03.05.19 19:59 Сейчас в теме
(70) Но вот что интересно. От ЗАПИСИ блокировка спасает. Установив исключительную блокировку в обработке на "Справочник.Пользователи" и попытавшись снять галочку "Показывать в списке" с последующей записью - я получаю все тот же конфликт блокировок.
Таким образом получается, что исключительная управляемая блокировка защищает от чтения только, если перед чтением идет попытка установки блокировки. Если нет, тогда она срабатывает уже при записи (видимо уже на уровне СУБД).
73. PerlAmutor 46 04.05.19 05:45 Сейчас в теме
(71) Правда, если блокировка будет снята после удачного чтения, но до попытки записи или в течении тех 20 секунд ожидания блокировки, то могут записаться некорректные данные. Таким образом в критичных местах надо обязательно использовать объект БлокировкаДанных явным образом, чтобы уберечь свой код от возможного чтения заблокированных данных.
76. comol 4082 06.05.19 00:04 Сейчас в теме
(70)
через управляемую блокировку можно обезопасить от чтения
можно конечно. Другой вопрос что это надо делать своими руками
75. comol 4082 06.05.19 00:03 Сейчас в теме
(68) Посмотрел. Ну ещё один пример аналогичный приведённому. Не ставим блокировки = не защищаемся. Собственно у вас они только в начале.
34. Dach 284 30.04.19 16:39 Сейчас в теме
И кстати, автор. По поводу блока кода №1. Замените набор регистра сведений набором регистра накопления - и Вы удивитесь)))

Спойлер:

Объектное чтение набора РС в транзакции накладывает неявную разделяемую управляемую блокировку.
Объектное чтение набора РН в транзакции НЕ накладывает неявную разделяемую управляемую блокировку.

Такое ощущение, что наборы записей РС и РН разные люди программировали в 1С.

Вывод 1: 1С полностью игнорирует все управляемые блокировки при чтении в транзакции запросом.

Ну и как бы логично, что игнорирует. Внутри транзакции запросом можно прочитать только "чистые" (закоммиченные) данные и их чистоту Вам СУБД гарантирует, а не сервер приложения. На самом деле, хотите обеспечить дополнительную "чистоту" и неизменность тех данных, которые читаете - ставьте перед чтением сами блокировку и именно на ней и отвалится выполнение кода по таймауту (если уже есть блокировка).
Именно, кстати, на чтении РС у Вас и отваливается выполнение по таймауту, так как см. выше - неявная разделяемая управляемая блокировка.

Отсюда, собственно и пошли все эти "старая методика - новая методика", вся суть которых заключается в "когда блокировать" - поближе к концу транзакции или подальше...

И с вот этим Вывод 5: В типовых конфигурациях не учитывается необходимость блокировать записи таблиц с которыми происходит неявное соединение при проведении

не могу согласиться.

Зачем блокировать то, что я в результате выполнения алгоритма менять не собираюсь? Как раз таки это избыточно будет. Собираюсь менять остатки - вот их и блокирую. Ну а то, что товар на момент чтения был товаром, а потом стал услугой - ну извините, сами себе злые буратины. Это уже уровень защиты в прикладной логике должен отвечать, при записи вида/свойства номенклатуры. А то так можно эту цепочку продлить еще и еще, у вида/свойства номенклатуры тоже свои реквизиты есть, у тех тоже свои и т.д. и т.п. Что же нам - все разименования блокировать? Не надо так )))
alexsey777; CSiER; comol; +3 Ответить
35. comol 4082 30.04.19 16:56 Сейчас в теме
(34)
хотите обеспечить дополнительную "чистоту" и неизменность тех данных, которые читаете - ставьте перед чтением

В этом весь смысл данной статьи :)))) Дело в том что в типовых 1С их не ставит... при проведении документа "с контролем" очевидно должна быть "дополнительная чистота"
44. comol 4082 30.04.19 22:38 Сейчас в теме
(34)
Что же нам - все разименования блокировать
именно так а никак иначе. Представьте что у вас меняется не "товар на услугу" а "вагон нефти" на "вагон хлора" в распределенной системе :)

Более того - проблема не в том что номенклатура из товара стала услугой... а в том что по регистру "товары на складах" она пройдёт как товар, а по регистру "себестоимость" уже как услуга. В рамках одной транзакции записываются оба регистра. Это ошибка согласованности данных.

А вцелом коммент очень дельный
sergathome; +1 Ответить
64. CheBurator 3402 01.05.19 23:08 Сейчас в теме
65. acanta 74 02.05.19 00:31 Сейчас в теме
Спасибо. Пробелы постепенно заполняются.
72. acanta 74 03.05.19 20:58 Сейчас в теме
Вы хотите сказать, что если на всю таблицу справочника пользователи наложить исключительную блокировку, то при обновлении ранее открытого списка мы получим пустой список или неполный?
А как же политика оптимистических блокировок?
74. PerlAmutor 46 04.05.19 20:11 Сейчас в теме
(72) Оптимистические и пессимистические блокировки относятся к объектным блокировкам, в основном касаются интерактивного варианта работы. Управляемые (транзакционные) блокировки не будут накладывать эти варианты блокировок на записи при использовании (это два разных механизма, которые друг о друге ничего не знают). Как я понимаю, с версии 8.3 в режиме Управляемых блокировок СУБД MSSQL использует уровень изоляции RCSI (Read Commited Snapshot Isolation), что позволяет повысить параллельность работы (concurency) за счет того, что в момент блокировки записи на чтение - копия (версия) данных (текущей транзакции) помещается в TempDb, а остальные транзакции читают основную версию. В моем случае, установка блокировки справочника Пользователи на чтение приводит к тому, что все остальные транзакции по факту читают старую (существующую) версию справочника, до завершения моей транзакции. Если другие транзакции попробуют явно установить блокировку через БлокировкаДанных или неявно, когда сама СУБД начнет её устанавливать, через попытку записи справочника - тогда блокировка встанет в очередь.Если мы хотим избежать рассогласованности данных в собственной транзакции и считаем, что изменение данных другими транзакциями критично для нашей бизнес-логики, то необходимо установить блокировку в явном виде, чтобы механизм Управляемых блокировок 1С и СУБД среагировал. В противном случае считается, что считанная ("старая" версия) данных имеет право на существование, так как заранее неизвестно завершится транзакция удачей или нет. И все кто не наложил блокировку в явном виде - сам отвечает за последствия. Это не является ошибкой, так как решение принимается исходя из логики прикладного решения, и в основном играет положительную роль, увеличивая параллельность работы системы. Проблема может возникнуть, если мы ничего не блокируем, считываем "старую" версию и на основании этой информации пишем в совершенно другое место (в этом случаем блокировок надо накладывать, как минимум, две)

Поправьте меня если я не прав.
sergathome; +1 Ответить
77. comol 4082 06.05.19 00:09 Сейчас в теме
(74) Во всём прав (вроде как) кроме того что к форме списка справочника это никак не относится ибо там нетранзакционное чтение данных, которому абсолютно покласть на все блокировки и уровни изоляции :)
78. Quantum81 06.05.19 10:46 Сейчас в теме
Авто!!! Напугал!
Ты должен исключение получить, когда будешь блокировать второй раз регистр. Т.е. проводи эксперимент при всегда включенной галке блокировать. Вот если ты смог заблокировать данные, то и читай их, зная что никто их не поправит в этот момент, т.к. ты наложил блокировку.
81. comol 4082 06.05.19 11:23 Сейчас в теме
(78) Галка "блокировать" это неявная установка управляемой блокировки просто.
82. Quantum81 06.05.19 11:49 Сейчас в теме
(81) Вы, наверно, меня не поняли. У вас же документ проводится. Если установлена галочка блокировать, то вы накладываете ЯВНУЮ управляемую блокировку на регистр. Так вот чтобы не получать неконсистентных данных - это надо делать ВСЕГДА (блокировать). Если вы блокировку не наложили перед чтением - то оно будет ГРЯЗНОЕ. Что здесь удивительного? :)
79. herfis 284 06.05.19 11:06 Сейчас в теме
Удивлен, что автор для многих открыл америку. Значит, статья в самом деле полезная.
ИМХО, если понимать, как работают блокировки СУБД и знать что управляемые блокировки не имеют никакого отношения к уровню СУБД, то вывод что управляемые блокировки никак не влияют на чтение запросами - очевиден.
Аналогичные реализации управляемых блокировок я еще на 7.7 припоминаю (с помощью внешних библиотек).
Астиг; sergathome; +2 Ответить
80. comol 4082 06.05.19 11:21 Сейчас в теме
(79)
вывод что управляемые блокировки никак не влияют на чтение запросами - очевиден

а можете пояснить почему для вас этот вывод очевиден?
Просто опыт говорит что в 1С работают одни разгильдяи и вот уж этого они точно не сделают? :)
83. herfis 284 06.05.19 11:59 Сейчас в теме
(80) Потому, что по тексту запроса невозможно в общем случае определить, пересечется ли получение результата запроса с управляемой блокировкой.
Ну вот смотрите. Наложил я блокировку по конкретному ТМЦ. А выбираю данные по всем ТМЦ из регистра за период. Анализом текста запроса невозможно определить - попадется ли там заблокированный ТМЦ. Анализом результата запроса это определить также невозможно - блокируемые данные могут использоваться как промежуточные и не входить в конечный результат. Приходим к тому, что контролировать это возможно только на уровне СУБД.
Но управляемые блокировки - это грубо говоря просто системный справочник. Полностью отдельно стоящая параллельная система. И ничего другого тут особо не придумаешь. Я бы реализовывал точно также. И как я уже говорил, подобные реализации были и для 7.7. Если не путаю, автор ToySQL что-то подобное продавал.
sergathome; +1 Ответить
89. comol 4082 06.05.19 13:11 Сейчас в теме
(83)
по тексту запроса невозможно в общем случае определить, пересечется ли получение результата запроса с управляемой блокировкой.
тем не менее СУБД это как то делает. Если очень хочется можно сначала прочитать а потом заблокировать. А можно тупо уровень изоляции поднять.
Я бы реализовывал точно также.
. Печально. Не смог донести видимо :(. Я бы такую херь делать не стал. И тому кто сделал по рукам бы надовал. Я бы дал возможность разработчику поднимать уровень изоляции. Или принудительно бы поднимал при проведении.
91. herfis 284 06.05.19 16:02 Сейчас в теме
(89) СУБД это делает с помощью блокировок СУБД. Уровень изоляции - это те же самые блокировки (плюс переключатель блокировочник/версионник в mssql).
С блокировками на уровне СУБД и поднятием уровня изоляций в 1С уже наигрались в автоматическом режиме блокировок. При проведении как раз и поднималось до Serializable. Но оказалось, что это не самый лучший вариант - слишком из пушки по воробьям. Целостность-то обеспечивается, но параллельность далеко не такая, как хотелось бы. Хотелось бы более тонкое управление блокировками, но его можно обеспечить только на прикладном уровне. Разбор полетов как раз и привел к появлению управляемых блокировок, которые можно применять "хирургически", а не "по площадям". Печально, что вы этого не понимаете. Здесь в принципе нет "более лучшей альтернативы".
ЗЫ. Хотя :) Если бы у 1С была своя СУБД, тогда 1С теоретически могла бы прямо транслировать управляемые блокировки в блокировки этой СУБД. Вот тогда бы могло получиться как вы хотите. Со сторонними СУБД на текущий момент это невозможно.
92. acanta 74 06.05.19 16:11 Сейчас в теме
(91) я понимаю в общих чертах что конфигурация на файловой СУБД и на sql с управляемыми блокировками долга быть не только написана с дополнительными командами заблокировать освободить, и даже не только с запросами (используя временные таблицы или нет) но и иметь другую архитектуру.
И несмотря на возможность открыть ее в конфигураторе, разработать конфигурацию для такого режима работы в файловой базе не получится и протестировать тоже.
94. spacecraft 06.05.19 16:23 Сейчас в теме
(92) да в общем-то нет. На то и универсальный объект Управляемые блокировки. Его стратегия определяет общие правила для разных СУБД. В том числе и для встроенного. Конечно есть особенности использования под разные СУБД, но они исключение из правила.
Это как запрос и СКД. В СКД тоже используется запрос, но он скорее руководство к действию, а не пошаговое выполнение.
Так и с управляемыми блокировками. Это объект (класс), который сам определяет, что и как заблокировать в самом sql.
95. comol 4082 06.05.19 16:26 Сейчас в теме
(92) (94) В общем то да. Я бы сказал "хорошая" конфигурация на 1С должна разрабатываться или под использование в файловой версии или под использование с конкретной СУБД.
Типовые конфигурации я не отношу к "хорошим" - я их отношу к "типовым".
93. comol 4082 06.05.19 16:22 Сейчас в теме
(91)
Уровень изоляции - это те же самые блокировки (плюс переключатель блокировочник/версионник в mssql)

"Садись два". Тут конечно нужно прочитать несколько матчасти. Уровень изоляции это намного более широкое понятие, и в общем случае не имеющее отношения к блокировочник/версионник.

Ещё раз постараюсь объяснить - надеюсь получится:

1) В СУБД реализованы НОРМАЛЬНЫЕ - ХОРОШИЕ блокировки. Которые вцелом всех устраивают.
2) Потому как в разных случаях разные требования к согласованности данных в СУБД придумали уровни изоляции. От Read Uncommited - когда нам "всё равно", до "Serializable" когда "не дай бог что сломается"
3) Блокировки в СУБД это целая нехилая система, с совместимостью, эскалацией, предварительным расчетом и т.п. которая ОЧЕНЬ сложна, но при этом отработана годами
4) УБ в 1С - это просто некие "флажки" - "тут можно, а тут нельзя", предельно упрощенная и не имеющая ничего общего с "тем как надо", более того - никак не распространяющаяся на реальные данные.


Так вот - 99% НОРМАЛЬНЫХ систем используют в своей работе механизм блокировок и транзакций от СУБД, потому как реализация аналогичного "очень трудна и дорога". И да, в них параллельность обеспечивается на лучшем уровне (Dynamix Ax и SAP (который не HANA)).

В 1С же не дали возможность нам использовать механизм транзакционных блокировок из СУБД, вместо этого напилили свой костыль, при помощи которого в теории можно обеспечить согласованность данных, но для этого надо просто умереть.

а про
более тонкое управление блокировками, но его можно обеспечить только на прикладном уровне
вы начитались методичек от 1С и просто не понимаете что это возможно БЕЗ 1С и БЕЗ управляемых блокировок.
96. spacecraft 06.05.19 16:27 Сейчас в теме
(93) а теперь отбросьте знания про последние версии mssql и оперируйте полным спектром поддерживаемых версий sql в 1С (в том числе и встроенной). А теперь создаете правило, которое поддерживается ими всеми и сразу.
97. acanta 74 06.05.19 16:32 Сейчас в теме
(96) что мешает 1с сузить поддерживаемые версии СУБД для каждого релиза конфигурации, как платформы к примеру.
Лицензионная политика ms sql?
98. spacecraft 06.05.19 16:34 Сейчас в теме
(97) предлагаете для каждой версии СУБД отдельную конфигурацию?
99. acanta 74 06.05.19 16:38 Сейчас в теме
(98) при запуске конфигурации пишут же обновите платформу. А почему не СУБД? Его надо заново покупать или только переустановить?
Оставьте свое сообщение

См. также

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С 16

Статья Системный администратор Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    1879    EugeneSemyonov    10       

Мониторинг высоконагруженной системы 38

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    4010    Repich    4       

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux 73

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    7551    Sloth    11       

Анализ производительности APDEX 65

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    3111    93    YPermitin    7       

Неочевидные проблемы производительности: важность системного подхода при анализе 50

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    4578    Филин    12       

Ловля блокировок на связке "Microsoft SQL server - 1С" 38

Статья Системный администратор Программист Нет файла v8 v8::blocking MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    4005    fhqhelp    0       

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным 57

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    6440    igordynets    119       

И тогда наверняка нас захватят облака 18

Статья Программист Нет файла Бесплатно (free) Интеграция

Внимание! Данный текст содержит достаточно мало технических подробностей и готовых рецептов. Главным образом некоторые размышления на предмет будущего технологий и профессий. Некое лёгкое чтение на досуге.

28.06.2019    4442    comol    35       

Ускорение чтения правил обмена в УПП 1.3 в 20 раз! 69

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    4837    YPermitin    16       

Хотите снизить нагрузку на процессор сервера в 2 раза? 21

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В статье рассмотрено влияние частого запуска регламентных заданий на процессор сервера 1С.

27.06.2019    4444    Дмитрий74Чел    6       

Непридуманные истории по оптимизации. История 1 82

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    7875    Repich    117       

Оптимизация: неэффективные запросы 6

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

В большинстве случаев основной причиной медленной работы системы при многопользовательском режиме работы является блокировка данных СУБД (говорим про клиент-серверную версию). Блокировка - это не есть хорошо или плохо, это жизненно необходимая вещь при построении прикладной логики работы системы. Но блокировки таблиц, записей могут быть как вполне законными, так и далеко не всегда оправданными в каждой конкретной ситуации. Одной из самых распространенных причин неоптимальной блокировки ресурсов является некорректное написание запросов.

13.06.2019    2897    slayer-ekb    10       

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С 90

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Статистика базы данных Производительность и оптимизация (HighLoad)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    7931    ivanov660    5       

Не думать о секундах свысока... 55

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    4640    vasilev2015    21       

Альтернативная стратегия управления блокировками 45

Статья Программист Архив с данными v8 v8::blocking 1cv8.cf Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    4068    zhichkin    15       

Странное потребление места на диске С 33

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    10877    kuzyara    12       

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С 50

Статья Системный администратор Программист Нет файла v8 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    8688    Elf1k    27       

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С 202

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В этой статье мы разберем механизм использования конфигурации "Анализ технологического журнала" на практике, и всего через 15 минут работы вы получите функциональный, удобный инструмент мониторинга проблем производительности базы 1С.

18.04.2019    18771    ivanov660    68       

Как разбить базу на файлы и не сойти с ума 108

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    9200    YPermitin    29       

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз 124

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    10246    w.r.    23       

Простое программное решение проблем с блокировками SQL 17

Статья Системный администратор Программист Нет файла v8 v8::blocking 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    6208    dmitrydemenew    38       

Производительность сервера 1С и фоновые задания 63

Статья Системный администратор Нет файла v8 1cv8.cf Россия Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

05.02.2019    11223    user715208    38       

Новый режим реструктуризации (обновление базы данных на сервере в режиме v2) 170

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная статья скорее является заметкой и отчетом об успешном использовании нового механизма реструктуризации баз данных 1С. Актуально для больших баз данных.

31.10.2018    19227    Dach    46       

Нетривиальные подходы в решении всем известных проблем: ускорение «больших» документов в 1С и ускорение поиска по подстроке. Как добиться эффекта в разы? 62

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто у пользователей 1С поиск информации по большим спискам данных по подстроке занимает продолжительное время. Павел Баркетов рассматривает причины торможения запросов с поиском по подстроке и описывает возможности и подходы к их оптимизации и ускорению. Также в статье разобраны причины длительного проведения «больших» документов (более 10 000 строк) и даны рекомендации по ускорению этих операций.

30.08.2018    11297    gallam99    31       

Кейс: как мы разрабатывали систему автоматизации анализа ошибок, связанных со скоростью работы 1С 43

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Бурмистров Андрей рассказывает о создании инструмента по автоматизации анализа неоптимальных запросов в коде 1С. Он поднимает вопрос о предпосылках создания этого инструмента, рассказывает о возникших форс-мажорных ситуациях, с которыми столкнулась команда в процессе разработки, и о том, как они с ними справлялись.

27.08.2018    7707    Andreynikus    20       

3000 пользователей на трехъядерном Athlon – сверхтонкий веб-клиент для 1С 97

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Юрий Лазаренко поделится опытом ускорения 1С нестандартными методами, в том числе с помощью http-сервисов. Он расскажет, как с помощью сверхтонкого клиента для 1С и интеграции с сайтом удалось добиться ускорения 1С на порядок. Также в статье приведена статистика по отчету о нагрузочном тестировании сверхтонкого клиента для 1С:ITIL.

16.08.2018    11649    TitanLuchs    28       

Когда условие в срезе последних даже вредит 20

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Спойлер: оптимизатор MSSQL видит внешние, по отношению к срезу, условия, и строит план с их учетом.

05.08.2018    8003    nicxxx    105       

Оптимизация без оптимизации: как мы ускорили 1С в 10 раз без трудоемкой оптимизации запросов и алгоритмов. Практический опыт 81

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Можно ли ускорить 1С, не оптимизируя запросы, не разбивая транзакции и не наращивая оборудование? В статье Аверьянова Алексея рассмотрены три практических кейса повышения производительности системы без трудоемкой оптимизации: отложенное резервирование «в один поток», отложенное создание и проведение реализаций.

26.07.2018    13478    avryanovalexey    100       

Альтернативные технологии нагрузочного тестирования серверной части кода прикладных решений на платформе 1С 56

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Евгений Филиппов знакомит с альтернативными технологиями нагрузочного тестирования серверной части кода прикладных решений на платформе 1С. Он рассказывает об узких местах традиционной технологии нагрузочного тестирования и методах их обхода путем переноса работы с клиентских соединений на фоновые задания и изменения способа управления сеансами. Также автор приводит примеры с реальных проектов, подтверждающие жизнеспособность предложенных технологий.

12.07.2018    8545    jf2000    10       

Архитектура ИТ-системы на базе 1С в крупной организации. Часть 2. Чудес не бывает 81

Статья Системный администратор Нет файла v8 УТ11 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Развернуто отвечаю, как мы боремся с зависаниями системы и вообще решаем проблемы. С примерами, но без слайдов.

04.07.2018    12493    Repich    74       

Архитектура ИТ-системы на базе 1С в крупной организации 101

Статья Системный администратор Нет файла v8 УТ11 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

В данной статье я хотел бы очень крупными мазками обрисовать архитектуру ИТ системы на базе 1С в крупных (более 1 тысячи пользователей) организациях. Она не несет какой либо образовательной цели, это просто попытка показать – «а как у нас».

02.07.2018    15069    Repich    112       

Взгляд на ошибки и платформу через призму HI-Load 53

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Поговорим об ошибках в целом и их влиянии на Hi-Load системы в частности. Может ли тут помочь платформа 1С? (да и должна ли в принципе?) Немного про сам Hi-Load на примере крупной БД. PS Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

18.06.2018    10300    Sergey.Noskov    27       

Простые регулярные выражения 59

Статья Программист Архив с данными v8 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Шпаргалка к экзамену "Эксперт по технологическим вопросам".

30.04.2018    12042    3    vasilev2015    30       

Неоптимальная работа запроса 130

Статья Программист Нет файла v8::Запросы Бесплатно (free) Производительность и оптимизация (HighLoad)

Шпаргалка к экзамену "Эксперт по технологическим вопросам".

27.04.2018    17297    vasilev2015    32       

Неоптимальности вида «план исполнения запроса "испортился"» - поиск и исправление 69

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Рассматривается один из частых типов проблем в рабочих базах (второй после блокировок, пожалуй... впрочем, часто и тесно с ними связанный). Материал относится к базам данных на связке «1С - MS SQL Server».

05.02.2018    14014    fhqhelp    20       

Пример поиска неоптимальности при загрузке SQL-сервера по CPU на 100% 83

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Вечер пятницы, ничто не предвещало.. Звонок из техподдержки: "центральная база розничной сети лежит". Далее расследование причин.

23.12.2017    15654    fhqhelp    32       

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте 130

Статья Системный администратор Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    24728    MrWonder    38       

Вопросы разработки, анализа производительности и оптимизации приложений 1С под управлением СУБД ORACLE 16

Статья Системный администратор Программист Нет файла v8 Oracle Бесплатно (free) Производительность и оптимизация (HighLoad)

Я являюсь сотрудником Комсомольского-на-Амуре филиала компании «Сухой». Наше предприятие производит боевую авиационную технику и комплектующие для гражданской авиационной техники. В статье я вам расскажу про свой опыт работы со связкой 1С и СУБД ORACLE.

05.09.2017    10677    user597755_vices2015    2       

Оптимизируй это! Или MS SQL и Экспертный подход творят чудеса! 208

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

В статье речь пойдет про взаимодействие сервера 1С с MS SQL. Мы очень часто слышим, как важно оптимизировать все критические участки системы заблаговременно, в плановом режиме, как надо, «от и до» во всех деталях. Но в реальной жизни бывает по-другому. Очень часто клиенты обращаются к нам, когда система уже не дает работать: «спасите, помогите, болит очень сильно, надо решать». Об одном из таких случаев я и хотел бы вам сегодня рассказать.

11.07.2017    29397    R.Tsarenko    32       

Планы запросов - это просто! 309

Статья Программист Нет файла v8::Запросы Бесплатно (free) Производительность и оптимизация (HighLoad)

Наверное, каждый 1С-ник задавался вопросом "что быстрее, соединение или условие в ГДЕ?" или, например, "сделать вложенный запрос или поставить оператор В()"? В данной статье я не дам вам исчерпывающих инструкций по чтению планов запроса. Но я постараюсь объяснить доходчиво - что это такое и с какой стороны к ним подойти.

04.07.2017    32150    Evil Beaver    58       

PostgreSQL на Windows – реальная альтернатива для высоконагруженных систем на базе 1С 158

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Многие интересуются PostgreSQL, но не знают, насколько хорошо будет она работать с уже существующими системами. «Инфософт» - одна из первых компаний, кто опробовал PostgreSQL на Windows. О своем опыте перехода рассказывает руководитель отдела информационных технологий компании.      

23.06.2017    37791    a.doroshkevich    113