2017-01-29 5 views
1

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

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

System.Data.Entity.Core.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details.

System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)

System.ComponentModel.Win32Exception: The semaphore timeout period has expired

System.Data.SqlClient.SqlException (0x80131904): A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)

System.ComponentModel.Win32Exception (0x80004005): The specified network name is no longer available

System.Data.Entity.Infrastructure.CommitFailedException: An error was reported while committing a database transaction but it could not be determined whether the transaction succeeded or failed on the database server. See the inner exception and http://go.microsoft.com/fwlink/?LinkId=313468 for more information. > System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)

System.ComponentModel.Win32Exception: The specified network name is no longer available`

System.Data.Entity.Core.EntityException: An exception has been raised that is likely due to a transient failure. If you are connecting to a SQL Azure database consider using SqlAzureExecutionStrategy.

System.Data.Entity.Core.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details.

System.Data.SqlClient.SqlException: A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) -

System.ComponentModel.Win32Exception: An existing connection was forcibly closed by the remote host

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

EDIT:

Я не бегу Azure.

Я также получаю много первичных ключевых ошибок нарушения также:

System.Data.Entity.Infrastructure.DbUpdateException: An error occurred while updating the entries. See the inner exception for details.

System.Data.Entity.Core.UpdateException: An error occurred while updating the entries. See the inner exception for details.

System.Data.SqlClient.SqlException: Violation of PRIMARY KEY constraint 'PK_dbo.MissileDataReferences'. Cannot insert duplicate key in object 'dbo.MissileDataReferences'. The duplicate key value is (4277, 2, 448388).

ответ

1

Раздражает не так ли? Да, вы получите их на любом сайте с большим объемом.

Похоже, что даже Microsoft представила политику повторения Azure в SQL Azure. Вы надеетесь, что даже они могут гарантировать связь между своим веб-сайтом и их базой данных в том же центре обработки данных в той же сети. Но они не могут.

Вы можете включить это для Azure (вы не говорите, используете ли вы Azure, но я подозреваю, что нет). См. https://docs.microsoft.com/en-us/azure/sql-database/sql-database-connectivity-issues, где требуются изменения строки подключения.

https://msdn.microsoft.com/en-us/library/dn456835(v=vs.113).aspx также охватывает EF6 на Azure.

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

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

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

+0

Я отредактировал свое оригинальное сообщение с дополнительной информацией. В настоящее время я не делаю никаких попыток (что я знаю). Если Entity Framework не запустит повторные попытки (что, я думаю, не так), я никогда не должен видеть нарушения первичного ключа (но я получаю их все время - наиболее распространенная ошибка, которую я получаю). – FlipperBizkut

+0

Вам не нужна логика повтора для реализации дублирующих ключевых ошибок. Например, если вы совершаете крупные объекты с несколькими отношениями одновременно. Я бы выкопал код, чтобы увидеть, где именно возникают дублирующие ключевые ошибки, и попытаться выяснить способ их ограничения. Не так много вы можете сделать для сетевых ошибок, кроме политики повтора. – Etienne

Смежные вопросы