Таймауты SQL в CRM 4.0 - сбой импорта настроек

Question

При импорте настроек в CRM 4.0 происходит сбой импорта с сообщением «универсальная ошибка SQL».Если копнуть немного глубже, сообщение об ошибке действительно означает, что истекло время ожидания.Та же ошибка возникает при попытке создать новую сущность.

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

Увеличение времени ожидания:

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSCRM \ OLEDBTimeout

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

https://community.dynamics.com/product/crm/crmtechnical/b/crmdavidjennaway/archive/2008/09/04/sql-timeouts-in-crm-generic-sql-error.aspx

Профилировщик SQL отображает набор вставок и обновлений, связанных с метаданными, в CRM,а затем вызов хранимой процедуры

exec p_RecreateIndexes

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

Есть ли способ найти причину задержки в этой процедуре или какое-то другое решение, которое я могу попробовать?

Answer 1

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

Answer 2

Я только что столкнулся с точно такой же проблемой, и я импортировал только 2 сущности.

Я нашел ваши вопросы, когда я искал p_RecreateIndexes, когда увидел их в файлах трассировки.

Я закончилзапуск exec p_RecreateIndexes в SQL Server.После завершения - около 2 минут - я возобновил импорт сущности, и он заработал.

Answer 3

Похоже, что операция переиндексации занимает некоторое время - что было бы ожидаемым, если размер данных большой, а фрагментация высокая.Это также зависит от того, что именно делает эта хранимая процедура, и сколько ядер / процессоров у вас есть - и сколько SQL Server разрешено использовать.

Позволяет ли приложение отложить эту операцию?Вы сможете запустить его вручную через Management Studio - если это не нарушит работу приложения.

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

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

Или обратитесь к поставщику, если у вас есть поддержка?

Если вы выполнили этот запрос через Management Studio, он бы завершился.... выполнение этого даст вам приблизительное время, необходимое для (временно) установки тайм-аута.