Microsoft sql server ошибка 1205

Симптомы

Предполагается, что таблицы, которая имеет также columnstore индексы в 2014 Microsoft SQL Server. При выполнении параллельного запроса, содержащего операторы внешнего соединения для таблицы внутри запроса может вызвать взаимоблокировку, и появляется следующее сообщение об ошибке:

Ошибка 1205
Транзакция (идентификатор процесса n) был взаимно универсальный объект ожидания ресурсов с другим процессом и выбран в качестве жертвы взаимоблокировки. Запустите транзакцию повторно.

Примечание. Эта проблема возникает только при максимальная степень параллелизма (MAXDOP) устанавливается на больше 1.

Решение

Сначала проблема была исправлена в следующем накопительном обновлении SQL Server.

Накопительное обновление 1 для пакета обновления 1 для SQL Server 2014 г/en-us/help/3067839

Накопительного обновления 8 для SQL Server 2014 г/en-us/help/3067836

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

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

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание посетите следующий веб-узел корпорации Майкрософт:

http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Статус

Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».

MSSQLSERVER_1205

Область применения: SQL Server (все поддерживаемые версии)

Сведения

attribute	Значение
Название продукта	SQL Server
Идентификатор события	1205
Источник события	MSSQLSERVER
Компонент	SQLEngine
Символическое имя	LK_VICTIM
Текст сообщения	Транзакция (с идентификатором процесса %d) вызвала взаимоблокировку ресурсов %.*ls с другим процессом и была выбрана в качестве жертвы для ее разрешения. Запустите транзакцию повторно.

Объяснение

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

• Транзакция1 обновляет строку Таблица1.Строка1, в то время как транзакция2 обновляет строку Таблица2.Строка2.
• Transaction1 пытается обновить Table2.Row2 , но блокируется, так как Транзакция2 еще не зафиксирована и не спустила блокировки.
• Транзакция 2 теперь пытается обновить Table1.Row1 , но заблокирована, так как Транзакция1 не зафиксирована и не спустила блокировки.
• Взаимоблокировка происходит из-за того, что транзакция1 ожидает завершения транзакции2, а транзакция2 ожидает завершения транзакции1.

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

Действие пользователя

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

Во избежание взаимоблокировок можно изменить выполняемое приложение. Выбранную «жертвой» транзакцию можно выполнить повторно, вероятность ее успешного выполнения высока и зависит от того, какие операции выполнялись одновременно.

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

Источник

Исправление: Ошибка при выполнении параллельного запроса, содержащего операторы внешнего соединения в SQL Server 2014 1205

Симптомы

Предполагается, что таблицы, которая имеет также columnstore индексы в 2014 Microsoft SQL Server. При выполнении параллельного запроса, содержащего операторы внешнего соединения для таблицы внутри запроса может вызвать взаимоблокировку, и появляется следующее сообщение об ошибке:

Ошибка 1205
Транзакция (идентификатор процесса n) был взаимно универсальный объект ожидания ресурсов с другим процессом и выбран в качестве жертвы взаимоблокировки. Запустите транзакцию повторно.

Примечание. Эта проблема возникает только при максимальная степень параллелизма (MAXDOP) устанавливается на больше 1.

Решение

Сначала проблема была исправлена в следующем накопительном обновлении SQL Server.

Накопительное обновление 1 для пакета обновления 1 для SQL Server 2014 г/en-us/help/3067839

Накопительного обновления 8 для SQL Server 2014 г/en-us/help/3067836

Каждый новый накопительный пакет обновления для SQL Server содержит все исправления и все исправления безопасности, входившие в состав предыдущего накопительного обновления. Извлечь последние накопительные обновления для SQL Server:

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

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

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание посетите следующий веб-узел корпорации Майкрософт:

http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».

Источник

Ошибка 1205 при настройке репликации транзакций

Эта статья поможет устранить проблему, которая возникает при настройке репликации транзакций в SQL Server.

Оригинальная версия продукта: SQL Server
Исходный номер базы знаний: 2674882

Симптомы

Рассмотрим следующий сценарий.

• Репликацию транзакций настраивают в SQL Server.
• Топология репликации транзакций состоит из нескольких издателей.
• Издатели реплицируют данные в одну базу данных подписчика.
• Агенты распространителя работают непрерывно или по частому расписанию. Например, агенты распространителя запускаются каждую минуту.

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

Ошибка 1205
Транзакция (идентификатор процесса %d) была взаимоблокирована на ресурсах %.*ls с другим процессом и была выбрана в качестве жертвы взаимоблокировки. Повторно запустите транзакцию.

Если включить флаг трассировки 1222 для перенаправления сведений о взаимоблокировках в журнал ошибок SQL Server, появится сообщение об ошибке, примерно следующее:

update MSreplication_subscriptions задать transaction_timestamp = cast(@P1 как binary(15)) + cast(case datalength(transaction_timestamp) при значении 16 isnull(substring(transaction_timestamp, 16, 1), 0) иначе 0 заканчиваются как binary(1)), «time» = @P2 where UPPER(publisher) = UPPER(@P3) и publisher_db = @P4 и publication = @P5 и subscription_type = 0

update MSreplication_subscriptions задать transaction_timestamp = cast(@P1 как binary(15)) + cast(substring(transaction_timestamp, 16, 1) as binary(1)), «time» = @P2 where UPPER(publisher) = UPPER(@P3) и publisher_db = @P4 и publication = @P5 и subscription_type = 0 и (substring(transaction_timestamp, 16, 1) = 0 или datalength(transaction_timestamp) MSreplication_subscriptions неверна. Если оценка числа строк неправильная, ядро СУБД SQL Server может использовать неправильный метод для обновления базы данных.

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

Решение

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

Способ 1. Использование DBCC UPDATEUSAGE команды

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

Команда DBCC UPDATEUSAGE определяет правильные значения для строк, используемых страниц, зарезервированных страниц, конечных страниц и количества страниц данных для каждой секции в таблице. Если эти значения верны, DBCC UPDATEUSAGE команда не возвращает данные. При обнаружении и исправлении DBCC UPDATEUSAGE неточных значений возвращает обновленные строки и столбцы.

Метод 2. Использование инструкции ALTER INDEX

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

Дополнительная информация

При возникновении проблемы, упоминаемой в разделе «Симптомы» , оценка числа строк для MSreplication_subscriptions системной таблицы может быть выше 4 294 967 296. Чтобы проверить значение rowcount, используйте один из следующих методов.

Способ 1. Использование SQL Server Management Studio

Чтобы использовать SQL Server Management Studio для проверки значения rowcount для системной MSreplication_subscriptions таблицы, выполните следующие действия.

1. Запустите SQL Server Management Studio, а затем подключитесь к экземпляру сервера подписчика.
2. Разверните узел Базы данных, а затем — базу данных подписчика.
3. Разверните узел Таблицы, а затем — Системные таблицы.
4. Щелкните правой кнопкой мыши dbo. MSreplication_subscriptions, а затем выберите Свойства.
5. Выберите Хранилище, а затем проверьте значение rowcount в поле Количество строк .

Метод 2. Использование инструкции запроса

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

Источник

Error 1205 when you configure transactional replication

This article helps you resolve a problem that occurs when you configure transactional replication in SQL Server.

Original product version: В SQL Server
Original KB number: В 2674882

Symptoms

Consider the following scenario:

• You configure transactional replication in SQL Server.
• The transactional replication topology consists of several publishers.
• The publishers replicate data into the same subscriber database.
• The distribution agents run continuously or run on a frequent schedule. For example, the distribution agents run every minute.

In this scenario, the distribution agents may be involved in a deadlock scenario and may be selected as a deadlock victim. When this issue occurs, you may receive an error message that resembles the following:

Error 1205
Transaction (Process ID %d) was deadlocked on %.*ls resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

If you enable trace flag 1222 to redirect the deadlock information into the SQL Server Error Log, you receive an error message that resembles one of the following:

update MSreplication_subscriptions set transaction_timestamp = cast(@P1 as binary(15)) + cast(case datalength(transaction_timestamp) when 16 then isnull(substring(transaction_timestamp, 16, 1), 0) else 0 end as binary(1)), «time» = @P2 where UPPER(publisher) = UPPER(@P3) and publisher_db = @P4 and publication = @P5 and subscription_type = 0

update MSreplication_subscriptions set transaction_timestamp = cast(@P1 as binary(15)) + cast(substring(transaction_timestamp, 16, 1) as binary(1)), «time» = @P2 where UPPER(publisher) = UPPER(@P3) and publisher_db = @P4 and publication = @P5 and subscription_type = 0 and (substring(transaction_timestamp, 16, 1) = 0 or datalength(transaction_timestamp) MSreplication_subscriptions system table is incorrect. If the rowcount estimate is incorrect, the SQL Server database engine may use an incorrect method to update the database.

Typically, the correct rowcount estimate is equal to the number of subscriptions in the database. If you use the Subscription Streams feature, the rowcount estimate is equal to the number of subscriptions multiplied by the number of configured streams for each subscription.

Resolution

To resolve this issue, use one of the following methods.

Method 1: Use the DBCC UPDATEUSAGE command

To resolve this issue, update the incorrect rowcount value. To do this, run the following command:

The DBCC UPDATEUSAGE command determines the correct values for rows, used pages, reserved pages, leaf pages, and data page counts for each partition in a table. If these values are correct, the DBCC UPDATEUSAGE command returns no data. If inaccurate values are found and corrected, DBCC UPDATEUSAGE returns the rows and columns that are updated.

Method 2: Use the ALTER INDEX statement

To resolve this issue, rebuild the indexes that are associated with the MSreplication_subscriptions table. To do this, use the following statement:

More information

When the issue that is mentioned in the Symptoms section occurs, the rowcount estimate for the MSreplication_subscriptions system table can be as high as 4,294,967,296. To check the rowcount value, use one of the following methods.

Method 1: Use SQL Server Management Studio

To use SQL Server Management Studio to check the rowcount value for the MSreplication_subscriptions system table, follow these steps:

1. Start SQL Server Management Studio, and then connect to the subscriber server instance.
2. Expand Databases, and then expand the subscriber database.
3. Expand Tables, and then expand System Tables.
4. Right-click dbo.MSreplication_subscriptions, and then select Properties.
5. Select Storage, and then verify the rowcount value in the Row count field.

Method 2: Use a query statement

To check the rowcount value for the MSreplication_subscriptions system table, run the following query:

Источник

Error 1205 when you configure transactional replication

This article helps you resolve a problem that occurs when you configure transactional replication in SQL Server.

Original product version: В SQL Server
Original KB number: В 2674882

Symptoms

Consider the following scenario:

• You configure transactional replication in SQL Server.
• The transactional replication topology consists of several publishers.
• The publishers replicate data into the same subscriber database.
• The distribution agents run continuously or run on a frequent schedule. For example, the distribution agents run every minute.

In this scenario, the distribution agents may be involved in a deadlock scenario and may be selected as a deadlock victim. When this issue occurs, you may receive an error message that resembles the following:

Error 1205
Transaction (Process ID %d) was deadlocked on %.*ls resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

If you enable trace flag 1222 to redirect the deadlock information into the SQL Server Error Log, you receive an error message that resembles one of the following:

update MSreplication_subscriptions set transaction_timestamp = cast(@P1 as binary(15)) + cast(case datalength(transaction_timestamp) when 16 then isnull(substring(transaction_timestamp, 16, 1), 0) else 0 end as binary(1)), «time» = @P2 where UPPER(publisher) = UPPER(@P3) and publisher_db = @P4 and publication = @P5 and subscription_type = 0

update MSreplication_subscriptions set transaction_timestamp = cast(@P1 as binary(15)) + cast(substring(transaction_timestamp, 16, 1) as binary(1)), «time» = @P2 where UPPER(publisher) = UPPER(@P3) and publisher_db = @P4 and publication = @P5 and subscription_type = 0 and (substring(transaction_timestamp, 16, 1) = 0 or datalength(transaction_timestamp) MSreplication_subscriptions system table is incorrect. If the rowcount estimate is incorrect, the SQL Server database engine may use an incorrect method to update the database.

Typically, the correct rowcount estimate is equal to the number of subscriptions in the database. If you use the Subscription Streams feature, the rowcount estimate is equal to the number of subscriptions multiplied by the number of configured streams for each subscription.

Resolution

To resolve this issue, use one of the following methods.

Method 1: Use the DBCC UPDATEUSAGE command

To resolve this issue, update the incorrect rowcount value. To do this, run the following command:

The DBCC UPDATEUSAGE command determines the correct values for rows, used pages, reserved pages, leaf pages, and data page counts for each partition in a table. If these values are correct, the DBCC UPDATEUSAGE command returns no data. If inaccurate values are found and corrected, DBCC UPDATEUSAGE returns the rows and columns that are updated.

Method 2: Use the ALTER INDEX statement

To resolve this issue, rebuild the indexes that are associated with the MSreplication_subscriptions table. To do this, use the following statement:

More information

When the issue that is mentioned in the Symptoms section occurs, the rowcount estimate for the MSreplication_subscriptions system table can be as high as 4,294,967,296. To check the rowcount value, use one of the following methods.

Method 1: Use SQL Server Management Studio

To use SQL Server Management Studio to check the rowcount value for the MSreplication_subscriptions system table, follow these steps:

1. Start SQL Server Management Studio, and then connect to the subscriber server instance.
2. Expand Databases, and then expand the subscriber database.
3. Expand Tables, and then expand System Tables.
4. Right-click dbo.MSreplication_subscriptions, and then select Properties.
5. Select Storage, and then verify the rowcount value in the Row count field.

Method 2: Use a query statement

To check the rowcount value for the MSreplication_subscriptions system table, run the following query:

Источник

description	title	ms.custom	ms.date	ms.service	ms.reviewer	ms.subservice	ms.topic	helpviewer_keywords	ms.assetid	author	ms.author
MSSQLSERVER_1205	MSSQLSERVER_1205 | Microsoft Docs		04/04/2017	sql		supportability	reference	1205 (Database Engine error)	9fe3f67c-df3c-4642-a3a4-ccc0e138b632	MashaMSFT	mathoma

MSSQLSERVER_1205

[!INCLUDE SQL Server Azure SQL Database Azure SQL Managed Instance]

Details

Attribute	Value
Product Name	SQL Server
Event ID	1205
Event Source	MSSQLSERVER
Component	SQLEngine
Symbolic Name	LK_VICTIM
Message Text	Transaction (Process ID %d) was deadlocked on %.*ls resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Explanation

Resources are accessed in conflicting order on separate transactions, causing a deadlock. For example:

• Transaction1 updates Table1.Row1, while Transaction2 updates Table2.Row2
• Transaction1 tries to update Table2.Row2 but is blocked because Transaction2 hasn’t yet committed and hasn’t released its locks
• Transaction2 now tries to update Table1.Row1 but is blocked because Transaction1 hasn’t committed and hasn’t released its locks
• A deadlock occurs because Transaction1 is waiting for Transaction2 to complete, but Transaction2 is waiting for Transaction1 to complete.

The system will detect this deadlock and will choose one of the transactions involved as a ‘victim’. It will then issue this error message, rolling back the victim’s transaction. For detailed information, see Deadlocks.

User Action

Deadlocks are in most cases application-related issues and require application developers to make code changes. One approach when you receive error 1205 is to execute the queries again. See this blog for an example of how to retry — handle the deadlock and re-execute the query: Deadlock Simulator app for Developers: How to Handle a SQL Deadlock issue in Your App

You can also revise the application to avoid deadlocks. The transaction that was chosen as a victim can be retried and will likely succeed, depending on what operations are being executed simultaneously.

To prevent or avoid deadlocks from occurring, consider having all transactions access rows in the same order (Table1, then Table2). This way, although blocking might occur, a deadlock will be avoided.

For more information, see Handling Deadlocks and Minimizing Deadlocks.

Error 1205

Severity Level 13

Message Text

Transaction (Process ID %d) was deadlocked on {%Z} resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Explanation

This error occurs when Microsoft® SQL Server™ encounters a deadlock. A deadlock occurs when two (or more) processes attempt to access a resource that the other process holds a lock on. Because each process has a request for another resource, neither process can be completed. When a deadlock is detected, SQL Server rolls back the command that has the least processing time and returns error message 1205 to the client application. This error is not fatal and may not cause the batch to be terminated.

Action

In some instances, a deadlock condition will cause a DB-Library function (such as dbsqlexec, dbsqlok, dbresults, or dbnextrow) to return FAIL. It is always the responsibility of the program to check the return codes from each DB-Library function. If FAIL is returned by one of these DB-Library functions, the program should cancel the batch and not attempt to continue. In some cases, it is possible to continue execution of subsequent functions in the batch. However, because a deadlock situation occurred and the functions that caused it were rolled back, later functions in the batch will probably fail with a more serious error, such as «object not found».

In other instances, a deadlock condition will not cause a DB-Library function to return FAIL. In these cases, the program must check for error message 1205 in the message handler and use the dbsetuserdata function to communicate this to the application. The program must then check for the deadlock indicator after every DB-Library call and should cancel the batch if a deadlock is detected.

Although it may seem unnecessary to cancel a batch after receiving a 1205 deadlock message, it is necessary because the server does not always terminate the batch in a deadlock situation. If the batch is not canceled, any attempt to submit a new batch can result in a DB-Library error 10038 «Results Pending».

You can also use the SET DEADLOCK_PRIORITY statement (LOW or NORMAL). SET DEADLOCK_PRIORITY controls how the session reacts when in a deadlock situation. If set to LOW, the process will be the preferred victim of a deadlock situation. If set to NORMAL, the session will use the default deadlock-handling method.

If a deadlock situation continues, it is often useful to use trace flag 1204 to gather more information. Trace flag 1204 prints out the deadlock chains and victim, as shown in this sample output:

*** Deadlock Detected ***
 ==> Process 7 chosen as deadlock victim
 == Deadlock Detected at: 1998-09-10 16:39:29.17
 == Session participant information:
 SPID: 7 ECID: 0 Statement Type: UPDATE
 Input Buf: update t1 set c1 = c1  where  c1 = 2

 SPID: 8 ECID: 0 Statement Type: UPDATE
 Input Buf: update t1 set c1 = c1  where  c1 = 1


 == Deadlock Lock participant information:
 == Lock: KEY: 2:117575457:1 (010001000000)
 Database: tempdb
 Table: t1
 Index: i1
  - Held by: SPID 7 ECID 0 Mode "S"
  - Requested by: SPID 8 ECID 0 Mode "X"
 == Lock: KEY: 2:117575457:1 (020002000000)
 Database: tempdb
 Table: t1
 Index: i1
  - Held by: SPID 8 ECID 0 Mode "S"
  - Requested by: SPID 7 ECID 0 Mode "X"

This deadlock information can be interpreted as follows:

• The first section displays the deadlock victim and time of deadlock, along with the sessions involved in the deadlock. For each session, the current SPID, statement type, and a portion of the input buffer are displayed.
• The second section displays details about the locks involved in the deadlock. From the output above, note that the deadlock involves key locks on table t1, index i1. The deadlock output shows which processes own the locks involved in the deadlock and which sessions are waiting for the locks to be granted as well as the associated lock modes.
• The process that has generated the least amount of log volume will, by default, be chosen as the deadlock victim and be rolled back automatically. To influence which session is rolled back, set the DEADLOCK_PRIORITY for a session.

See Also

Deadlocking

Errors 1000 — 1999

SET DEADLOCK_PRIORITY

Trace Flags