Как увеличить таймаут блокировок sql

Устранение ошибок времени ожидания запроса

Предположим, что приложение запрашивает данные из базы данных SQL Server. Если запрос не возвращает данные в течение заданного значения времени ожидания (обычно 30 секунд), приложение отменяет запрос и создает одно из следующих сообщений об ошибке:

Истекло время ожидания. Срок ожидания истек до завершения операции, или сервер не отвечает. Выполнение инструкции прекращено.

System.Data.SqlClient.SqlException: истекло время ожидания. Срок ожидания истек до завершения операции, или сервер не отвечает.

Объяснение

Эти ошибки возникают на стороне приложения. Приложение задает значение времени ожидания, и по его истечении оно отменяет запрос. На стороне SQL Server отмена запроса со стороны клиента вызывает событие «Внимание», ошибку 3617 (MSSQLSERVER_3617). Если время ожидания на стороне приложения равно 0 (без ограничения по времени), ядро СУБД выполняет запрос до его завершения.

• В платформе .NET Framework System.Data.SqlClient значение времени ожидания задается в свойстве CommandTimeout.
• В API ODBC значение времени ожидания задается с помощью атрибута SQL_ATTR_QUERY_TIMEOUT в функции SQLSetStmtAttr.
• В API Java Database Connectivity (JDBC) значение времени ожидания задается с помощью метода setQueryTimeout.
• В OLEDB значение времени ожидания задается через свойство DBPROP_COMMANDTIMEOUT структуры DBPROP .
• В VBA (Excel) значение времени ожидания задается через свойство ADODB.Command.CommandTimeout.

Время ожидания запроса отличается от свойства времени ожидания подключения. Последнее определяет время ожидания успешного подключения и не участвует в выполнении запроса. Дополнительные сведения см. в разделе Время ожидания запроса не совпадает с временем ожидания подключения.

Действия по устранению неполадок

На данный момент наиболее распространенной причиной времени ожидания запросов являются неэффективные запросы. Это означает, что запрос выполняется дольше, чем предопределенное значение времени ожидания запроса. Ускорение выполнения запроса является рекомендуемой первой целью устранения неполадок. Вот как проверить запросы:

Используйте расширенные события или трассировку SQL для определения запросов, которые вызывают ошибки времени ожидания. Вы можете отслеживать событие Внимание вместе с sql_batch_completed и расширенными событиями rpc_completed и сопоставлять их с одним и тем же session_id . Если вы заметили, что за завершенным событием сразу последует событие внимания, а длительность завершенного события примерно соответствует параметру времени ожидания, то запрос определен. Пример:

Примечание. В этом примере запрос SELECT выполнялся почти ровно 30 секунд и был остановлен. Событие «Внимание» с одинаковым идентификатором сеанса указывает, что запрос был отменен приложением.

Имя	Session_id	Sql_text	Длительность (в микросекундах)	Timestamp
sql_batch_started	54	Выберите … от клиентов, ГДЕ cid = 192937	NULL	2021-09-30 09:50:25.0000
sql_batch_completed	54	Выберите … от клиентов, ГДЕ cid = 192937	29999981	2021-09-30 09:50:55.0000
Внимание	54	Выберите … от клиентов, ГДЕ cid = 192937	40000	2021-09-30 09:50:55.0400

Примечание. В SQLCMD и SSMS значение времени ожидания равно 0 (без ограничения по времени), и запросы можно проверить и изучить.

ALTER EVENT SESSION [setOptions] ON SERVER ADD EVENT sqlserver.existing_connection(SET collect_options_text=(1) ACTION(package0.event_sequence,package0.last_error,sqlos.system_thread_id,sqlserver.context_info,sqlserver.session_id,sqlserver.sql_text)), ADD EVENT sqlserver.login(SET collect_options_text=(1) ACTION(sqlos.system_thread_id,sqlserver.context_info,sqlserver.sql_text)) 

using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using System.Data.SqlClient; using System.Data; namespace ConsoleApplication6 < class Program < static void Main() < string ConnectionString = "Data Source=.\sql2019;Integrated Security=SSPI;Initial Catalog=tempdb;"; string queryString = "exec test"; using (SqlConnection connection = new SqlConnection(ConnectionString)) < connection.Open(); SqlCommand command = new SqlCommand(queryString, connection); // Setting command timeout to 10 seconds command.CommandTimeout = 10; //command.ExecuteNonQuery(); try < command.ExecuteNonQuery(); >catch (SqlException e) < Console.WriteLine("Got expected SqlException due to command timeout "); Console.WriteLine(e); >> > > > 

Время ожидания запроса не совпадает с временем ожидания подключения

Время ожидания запроса отличается от времени ожидания подключения или времени ожидания входа. Превышение времени ожидания подключения или входа возникает в том случае, если начальное подключение к серверу базы данных достигает предопределенного времени ожидания. На этом этапе запрос не был отправлен на сервер. Эти сообщения являются примерами ошибки времени ожидания подключения или входа:

Истекло время ожидания соединения. Время ожидания истекло при попытке обработки подтверждения предварительного согласования. Возможно, произошел сбой во время предварительного согласования, или сервер не смог ответить вовремя. Время, затраченное на попытки подключиться к этому серверу, составило: [Pre-Login] initialization=23; handshake=14979;

Истекло время ожидания. Срок ожидания истек до завершения операции, или сервер не отвечает. System.ComponentModel.Win32Exception (0x80004005): Время ожидания операции истекло.

Значение времени ожидания подключения является параметром на стороне клиента и обычно равно 15 секундам. Дополнительные сведения об устранении неполадок со временем ожидания подключения см. в разделе Устранение неполадок со временем ожидания подключения. Сведения об устранении неполадок со временем ожидания запросов см. в этом видеоролике.

Обратная связь

Были ли сведения на этой странице полезными?

Настройка времени ожидания удаленного запроса (параметр конфигурации сервера)

В этом разделе описываются способы настройки параметра конфигурации сервера remote query timeout в SQL Server с помощью среды SQL Server Management Studio или Transact-SQL. Параметр remote query timeout позволяет задать время ожидания SQL Server (в секундах), в течение которого может выполняться удаленная операция. Значение по умолчанию для этого параметра составляет 600, что означает ожидание в течение 10 минут. Если задать для этого параметра значение 0, время ожидания отключается. Это значение применяется к исходящему соединению, которое Компонент Database Engine создает в качестве удаленного запроса. Это значение не влияет на запросы, получаемые ядром СУБД Компонент Database Engine. Запрос будет ожидать до момента его завершения.

Для разнородных запросов параметр remote query timeout задает время ожидания удаленным поставщикам в секундах (инициализированное в объекте команд с помощью свойства набора строк DBPROP_COMMANDTIMEOUT) результирующих наборов. Это значение также используется, чтобы задать DBPROP_GENERALTIMEOUT, если это поддерживается удаленным поставщиком. Это приведет к тому, что время ожидания других операций станет равно указанному числу секунд.

Для удаленных хранимых процедур параметр remote query timeout задает число секунд, которое должно пройти после отправки удаленной инструкции EXEC перед тем, как истечет время ожидания удаленной хранимой процедуры.

В этом разделе

• Перед началом работыПредварительные требованияБезопасность
• Настройка параметра времени ожидания удаленного запроса с помощью следующих средств:Среда SQL Server Management StudioTransact-SQL
• Дальнейшие действия.После настройки параметра remote query timeout

Перед началом

Предварительные требования

• Это значение можно установить только при разрешенных соединениях с удаленными серверами.

Безопасность

Разрешения

Разрешения на выполнение хранимой процедуры sp_configure без параметров или только с первым параметром по умолчанию предоставляются всем пользователям. Для выполнения процедуры sp_configure с обоими параметрами для изменения параметра конфигурации или запуска инструкции RECONFIGURE необходимо иметь разрешение ALTER SETTINGS на уровне сервера. Разрешение ALTER SETTINGS неявным образом предоставлено предопределенным ролям сервера sysadmin и serveradmin .

Использование среды SQL Server Management Studio

Настройка параметра время ожидания удаленного запроса

1. В обозревателе объектов щелкните правой кнопкой мыши сервер и выберите пункт Свойства.
2. Выберите узел Соединения .
3. В поле Подключения удаленного серверав области Время ожидания удаленного запроса введите или выберите значение от 0 до 2 147 483 647, соответствующее максимальному времени ожидания SQL Server (в секундах).

Использование Transact-SQL

Настройка параметра время ожидания удаленного запроса

1. Установите соединение с компонентом Компонент Database Engine.
2. На панели «Стандартная» нажмите Создать запрос.
3. Скопируйте следующий пример в окно запроса и нажмите кнопку Выполнить. В этом примере описывается использование хранимой процедуры sp_configure для задания значения параметра remote query timeout равным 0 сек., чтобы отключить время ожидания.

USE AdventureWorks2022; GO EXEC sp_configure 'remote query timeout', 0 ; GO RECONFIGURE ; GO 

Дальнейшие действия. После настройки параметра remote query timeout

Параметр вступает в силу немедленно, без перезапуска сервера.

Типичные причины избыточных блокировок и методы оптимизации

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

Блокировка данных — это механизм поддержания целостности данных при работе в многопользовательской среде. Подробная информация о том, для чего нужны блокировки и как они реализованы в 1С:Предприятии 8, содержится в статье «Блокировки данных в 1С:Предприятии 8». Рекомендуется предварительно ознакомится с этим материалом для лучшего понимания настоящей статьи.

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

Значительная часть проблем, связанных с избыточными блокировками, может быть обнаружена путем анализа кода конфигурации и структуры метаданных. Имеется перечень типичных ошибок в коде и структуре данных, последствия которых достаточно хорошо изучены и легко предсказуемы. Анализ кода с использованием этого перечня позволяет решить большую часть проблем с блокировками, не углубляясь в детальную техническую информацию (текст запроса на языке SQL, системная информация о блокировке на уровне СУБД и т.д.).

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

• Неоптимальная работа запроса
• Методические ошибки при использовании объектов конфигурации
  • Константы
  • Последовательность
  • Регистры бухгалтерии
  • Регистры накопления

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

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

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

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

  Методические ошибки при использовании объектов конфигурации

  Проектные ошибки при выборе и проектировании структуры того или иного объекта метаданных для реализации прикладной функциональности, могут привести к большому количеству избыточных блокировок и как следствие к серьезному падению общей производительности системы.

  Ожидание на блокировке данных происходит в том случае, если две различные сессии 1С:Предприятия пытаются захватить один и тот же ресурс. При работе с разными ресурсами ожидание на блокировке не происходит. В данном контексте термин «ресурс» используется в качестве обозначения неделимой совокупности данных, которая блокируется (или не блокируется) только вся целиком.

  Таким образом, вопрос сводится к тому, какие именно ресурсы захватываются при выполнении того или иного действия с данными. Или, иначе говоря, насколько «мелко нарезаны» данные 1С:Предприятия.

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

  • Константы
  • Последовательность
  • Регистры бухгалтерии
  • Регистры накопления

  Ниже даны рекомендации по анализу и оптимизации каждого из перечисленных объектов. Объекты перечислены в порядке убывания «потенциальной опасности» для параллельности системы.

  Константы

  Не рекомендуется использовать константы для хранения постоянно меняющихся данных. Это приведет к возникновению избыточных блокировок и снижению общей производительности системы. Для хранения таких данных можно использовать другие объекты метаданных 1С:Педприятия (справочники, регистры и т.д.).

  Константы предназначены для хранения настроек, которые могут часто считываться, но не должны часто изменяться. Значения всех констант хранятся в одном ресурсе . Это означает, что при блокировке одной константы будут заблокированы все константы.

  Пример

  Перед программистами была поставлена задача вести общий счетчик количества документов, введенных в систему. Для реализации этой задачи была создана константа «КоличествоДокументов» и в процедуры «ОбработкаПроведения» каждого документа был вписан следующий код:

  Константы.КоличествоДокументов.Установить(Константы.КоличествоДокументов.Получить() + 1);

  Этот код выполняется в обработчике проведения документа, то есть в транзакции. Транзакция включает в себя множество сложных вычислений и операций с данными, которые производятся при проведении документа. Вследствие этого транзакция может выполнятся достаточно длительное время. При записи данной константы блокируются все константы (то есть становятся невозможными другие операции записи любых констант) причем эта блокировка удерживается до конца транзакции. Таким образом, в системе возникает избыточная блокировка, которая делает невозможной параллельную работу пользователей.

  Подобное решение способно полностью парализовать оперативную работу многопользовательской системы.

  Последовательность

  Не рекомендуется двигать границу последовательности при проведении документов. Это может привести к возникновению ожиданий на блокировках и снижению общей производительности системы. Операцию движения границы последовательности следует вынести из оперативных операций в регламентные, например выполнять регламентной обработкой с заданной частотой.

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

  При нормальной работе последовательность должна двигаться постоянно вперед (иначе не имеет смысла её двигать). Сбиваться назад последовательность должна редко, и после сбития последовательность уже не двигается. Не рекомендуется при проведении документов или формировании отчетов восстанавливать последовательность. Это следует делать регламентными операциями.

  Пример

  В системе, построенной на базе УПП, используется учетная политика, предполагающая вычисление себестоимости списываемых товаров в оперативном режиме (непосредственно в момент списания).

  

  Алгоритмы партионного учета в УПП используют последовательность «Партионный учет», имеющую одно измерение: «Организация».

  Для вычисления себестоимости списываемых товаров при проведении расходного документа необходимо переместить границу последовательности для данной организации на момент времени проводимого документа. Если два пользователя будут одновременно проводить расходные документы по одной организации (что весьма вероятно), то они будут блокировать друг друга. Такое поведение системы не является особенностью реализации последовательностей в 1С:Предприятии, но продиктовано требованиями самого алгоритма – необходимо знать точную последовательность расположения документов. То есть все конкурирующие по времени (одновременно проводящиеся) документы должны выстроиться друг за другом.

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

  Регистры бухгалтерии

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

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

  Пример 1

  В конфигурации определен регистр «Хозрасчетный» с измерениями «Организация» и «Валюта».

  

  При этом запрещено разделение итогов регистра:

  

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

  Пользователи будут блокировать друг друга в том случае, если движения:

  • относятся к одному и тому же периоду;
  • относятся к одному и тому же счету;
  • имеют одинаковые значения измерений, то есть организацию и валюту.

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

  Для решения этой проблемы следует включить режим разделения итогов (см. следующий пример).

  Пример 2

  Если для этого же регистра разрешить и включить режим разделения итогов, то ситуация изменится.

  Разрешим режим разделения итогов (в режиме конфигурирования):

  

  Включим режим разделения итогов (в режиме 1С:Предприятия):

  

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

  Однако, если при этом осуществляется контроль остатков по данному регистру, то эффекта от включения режима разделения не будет (см. пример 3).

  Пример 3

  Если при записи набора записей в регистр осуществляется контроль остатков (например, с целью недопущения получения отрицательных остатков), то режим разделения итогов не даст никакого эффекта (то есть, параллельности системы не повысится). Предположим, что в процедуре «ПередЗаписью» модуля набора записей регистра бухгалтерии «Хозрасчетный» выполняется следующий запрос:

  Запрос.Текст = "ВЫБРАТЬ | СуммаОстаток, | СуммаОстатокДт, | СуммаОстатокКт |ИЗ | РегистрБухгалтерии.Хозрасчетный.Остатки(&Период, &Счет, , Организация = &Организация)"; 

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

  Для того, чтобы минимизировать влияние этой блокировки на общую производительность системы, рекомендуется перенести ее как можно ближе к концу транзакции. Например, можно вынести эту проверку в модуль документа в обработчик события «ПриПроведении» после записи (в явном виде) всех движений по всем регистрам.

  Регистры накопления

  При проектировании регистра накопления следует помнить, что остатки по одному набору измерений хранятся в одном ресурсе регистра. То есть, степень параллельности при работе с регистром фактически зависит от состава его измерений. Состав измерений необходимо подбирать в соответствии с тем, насколько мелко должны быть «нарезаны» остатки, исходя из прикладной функциональности системы.

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

  Рассмотрим в качестве примера регистр накопления «ТоварыНаСкладах» со следующим составом измерений:

  

  Пример 1

  Предположим два пользователя одновременно проводят документы, которые записывают движения в данный регистр накопления. При этом первый пользователь пишет следующий набор записей:

  №	Склад	Номенклатура
  1	Основной склад	Кресло-качалка
  2	Основной склад	Кухонный гарнитур «Тинга-2»
  3	Склад №2	Мебельный гарнитур «Торэ»

  Второй пользователь пишет в этот же регистр следующий набор записей:

  №	Склад	Номенклатура
  1	Основной склад	Мебельный гарнитур «Торэ»
  2	Склад №2	Кресло-качалка

  Эти наборы записей не содержат строк, совпадающих по значениям всех измерений, поэтому ожидание на блокировке в данном случае не возникнет.

  Пример 2

  Предположим, что второй пользователь записывает следующий набор записей

  №	Склад	Номенклатура
  1	Основной склад	Кухонный гарнитур «Тинга-2»
  2	Склад №2	Кресло-качалка
  2	Оптовый склад	Спальный гарнитур «Инга-М»

  Этот набор записей содержит строку (№1), совпадающую по значениям всех измерений со строкой набора записей первого пользователя (№2).

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

  Регистр накопления так же поддерживает режим разделения итогов, который позволит в данной ситуации избежать блокировки (см. Пример 3).

  Пример 3

  Если для данного регистра накопления включен режим разделения итогов, то будет возможна параллельная запись двух наборов, даже в том случае если они содержат одинаковые (по значениям измерений) строки. Однако, если при этом используется контроль остатков, то режим разделения итогов не даст положительного эффекта. Иначе говоря, режим разделения итогов для регистра накопления работает аналогично регистру бухгалтерии. Для снижения влияния этой блокировки на общую производительность системы нужно перенести контроль остатков как можно ближе к концу транзакции.

  Блокирующее чтение остатков в начале транзакции

  Режим разделения итогов эффективно решает задачу исключения блокировки при записи остатков регистров бухгалтерии и накопления. Однако, для решения некоторых задач необходимо выполнять блокирующее чтение итогов. Классическим примером такой задачи является контроль остатков при проведении документа. Если в результате проведения документа остатки станут отрицательными, то транзакция должна быть отменена (проводить такой документ нельзя).

  Операция чтения остатков должна быть блокирующей, то есть необходимо запретить двум пользователям одновременно читать один и тот же остаток. Если чтение будет неблокирующим, то возможна ситуация, при которой два пользователя одновременно прочитают один и тот же остаток (например 10 единиц) и примут решение о возможности списания части этого остатка. Если сумма списаний двух пользователей будет больше 10, то в итоге остаток получится отрицательным. Например, первый пользователь спишет 8 единиц (8 меньше 10, следовательно операция разрешена), а второй пользователь спишет 6 единиц (на таком же основании). Результатом будет -4 единицы остатка, что недопустимо с точки зрения прикладной логики системы.

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

  • Разработчик, как правило, не контролирует порядок записи движений в разные регистры — запись обычно осуществляется автоматически платформой 1С:Предприятия. Запрос контроля остатков реализуется в модуле набора записей и вызывается при записи движений регистра. Если этот регистр будет записываться в начале транзакции (например, первым), то установленная блокировка будет мешать работе других пользователей в течение длительного периода времени (пока будут записываться все остальные регистры), и ее влияние на производительность системы может оказаться неоправданно большим.
  • В некоторых случаях, возможно, нет необходимости в контроле остатков, поскольку записываемые движения заведомо не могут привести к получению отрицательных остатков.

  Для того, чтобы минимизировать влияние блокирующего чтения остатков на производительность системы необходимо:

  • Проанализировать, какие именно остатки нуждаются в блокирующем чтении и при каких обстоятельствах. Например, контроль остатков не требуется при проведении приходного документа, поскольку он может только увеличить остатки. Так же не требуется контролировать остатки при перепроведении документа, который списывает в этот раз не больше остатков чем при первом проведении (этот контроль уже проводился). И так далее.
  • В начале транзакции (например, в обработчике ОбработкаПроведения документа) в явном виде записать движения по всем регистрам, которые в данном случае не требуют контроля остатков. Следует всегда придерживаться одинакового порядка записи регистров (например, алфавитного). Обратите внимание на то, что у всех записываемых регистров накопления и бухгалтерии должен быть включен разделитель итогов, а у наборов записей опция «БлокироватьДляИзменения» должна быть установлена в значение ЛОЖЬ.
  • Выполнить все остальные действия, которые должны быть выполнены в рамках этой транзакции.
  • В самом конце транзакции в явном виде записать движения по тем регистрам, которые требуют контроля остатков. Для наборов записей этих регистров следует установить опцию «БлокироватьДляИзменения» в значение ИСТИНА. Это необходимо для предотвращения взаимоблокировки. Именно в этот момент времени будет установлена блокировка остатков регистра по данному набору значений измерений.
  • Для каждого регистра выполнить запрос контроля остатков. Обратите внимание, что в данном случае нет необходимости использовать опцию «ДЛЯ ИЗМЕНЕНИЯ» (в автоматическом режиме) или явную управляемую блокировку (в управляемом режиме), поскольку проверяемые остатки уже заблокированы их записью не предыдущем шаге. Запрос должен считывать только отрицательные остатки по заданному набору значений измерений. Если такие записи имеются, то транзакция должна быть отменена. Если запрос вернул пустой результат, то транзакция должна быть зафиксирована.

  Выгрузка изменений во время работы пользователей

  Выгрузка изменений по плану обмена включает в себя этап считывания всех измененных записей из таблицы регистрации изменений. Запрос, выполняемый в транзакции, отрабатывает условие «все измененные объекты данного типа», поэтому на время работы транзакции блокируется возможность регистрации новых изменений для объектов данного типа. Это означает, что во время выгрузки изменений другие пользователи не смогут вносить новые изменения в объекты данного типа. Если к моменты выгрузки было зарегистрировано большое количество изменений, то выгрузка может занимать значительное время, что может привести к существенному снижению общей пропускной способности системы, появлению ошибок типа таймаут и т.п.

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

  Избыточные блокировки СУБД

  При работе в автоматическом режиме управления блокировкой 1С:Предприятие устанавливает высокую степень изоляции данных в транзакции на уровне СУБД. Это позволяет полностью исключить возможность получения нецелостных или некорректных данных без каких-либо специальных усилий со стороны прикладных разработчиков.

  Однако, при этом могут возникать некоторые избыточные блокировки на уровне СУБД. Эти блокировки связанны как с особенностями реализации механизмов блокировок в самой СУБД, так и с тем, что СУБД не может учитывать (и не учитывает) физический смысл и структуру объектов метаданных 1С:Предприятия.

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

  Подробная информация о методике перевода приложений в управляемый режим блокировки содержится в статье «Блокировки данных в 1С:Предприятии 8».

  Изменение большого количества данных в одной транзакции

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

  Иногда необходимо выполнить согласованные изменения нескольких объектов, например записать два зависимых документа, которые имеют смысл только вместе. Для того, чтобы поддержать целостность таких изменений необходимо открыть транзакцию в явном виде при помощи команды «ОткрытьТранзакцию()». При этом следует внимательно следить за тем, чтобы длительность транзакции была минимальной. Оптимальная длительность транзакции — несколько секунд. Транзакция, меняющая взаимозависимые данные, и длящаяся более 10 секунд может создать большие проблемы другим пользователям, поэтому для данного случая следует реализовать контроль целостности изменений каким-то другим способом (на прикладном уровне, а не на уровне платформы).

  Типичные примеры операций, которые не следует выполнять в одной большой транзакции:

  • Импорт данных
  • Закрытие месяца
  • Перепроведение документов за период

  Как увеличить таймаут блокировок sql

  исходные данные:
  1С 8.2 ЗКБУ
  база была сформирована из 1с ЗиК 7.7
  конфигурация типовая
  пробовались разные типы баз — файловая, терминал и sql (windows server 2008. sql server 2008.)
  размер базы — 800Мб
  платформа и конфигурация обновляются регулярно.
  С базой работают 2 расчётчика

  Проблема в следующем:

  При одновременном расчёте заработной платы разным сотрудникам, у одного из расчётчиков(рандомно) возникает следующая ошибка:

  Ошибка:
  : Ошибка при вызове метода контекста (Записать)
  НаборЗаписейРегистра.Записать(Истина, ТолькоЗапись, Истина, Ложь);
  по причине:
  Конфликт блокировок при выполнении транзакции:
  Microsoft SQL Server Native Client 10.0: Превышено время ожидания запроса на блокировку.
  HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=2D, Severity=10, native=1222, line=1

  В конфигураторе ссылается на следующую строку:

  // записываем набор перед расчетом каждой категории начислений
  Если ИмяРегистра = «ОсновныеНачисленияРаботниковОрганизаций» Тогда
  НаборЗаписейРегистра.Записать(Истина, ТолькоЗапись, Истина, Ложь);
  Иначе
  НаборЗаписейРегистра.Записать(Истина, ТолькоЗапись);
  КонецЕсли;
  ТолькоЗапись = Истина;

  Данная проблема возникает не только у нас. Фирма, которая осуществляет сопровождение сначала причиной называло медленный компьютер на котором стоит база (файловый вариант) или линии ЛВС(исключили эту причину сразу), базу перенесли на терминальный сервер — та же ошибка, на SQL то же самое.

  ЕСТЬ ли решение этой проблеме?

  Похожие публикации:

  1. End to end error count seagate как исправить
  2. Как выбрать допустимый элемент запуска в visual studio
  3. Как подключить код доступа майл ру
  4. Настройка vps ноде js что это