SSDT Тайм-аут публикации

Question

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

Я попытался установить свойство тайм-аута в реестре, как в блоге, но это не помогает ..

https://blogs.msdn.microsoft.com/sqlblog/2014/11/13/timeout-expired-while-publishing-to-sql-database-via-ssdt/

Когда я пытаюсь исследовать какую часть публиковать является причиной Задержка я мог бы определить это. Этот запрос продолжает работать в течение длительного времени, что приводит к таймауту во время публикации. Я запускал то же самое в Dev и production, и он запускался мгновенно и возвращает нулевые строки, так как у нас нет каких-либо пространственных индексов в системе.

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

SELECT * FROM 
    [sys].[spatial_indexes]   AS [si] WITH (NOLOCK) 
    INNER JOIN [sys].[objects]  AS [o] WITH (NOLOCK) 
ON [si].[object_id] =   [o].[object_id] INNER JOIN [sys].[spatial_index_tessellations] [sit] WITH (NOLOCK) ON [si].[object_id] = [sit].[object_id] AND [si].[index_id] = [sit].[index_id] 
WHERE [si].[is_hypothetical] = 0 

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

И OBJECTPROPERTY (. [О] [object_id], N'IsSystemTable ') = 0

SELECT * FROM 
    [sys].[spatial_indexes]   AS [si] WITH (NOLOCK) 
    INNER JOIN [sys].[objects]  AS [o] WITH (NOLOCK) 
ON [si].[object_id] =   [o].[object_id] INNER JOIN [sys].[spatial_index_tessellations] [sit] WITH (NOLOCK) ON [si].[object_id] = [sit].[object_id] AND [si].[index_id] = [sit].[index_id] 
WHERE [si].[is_hypothetical] = 0 
     AND OBJECTPROPERTY([o].[object_id], N'IsSystemTable') = 0  

Хенрик добавил предполагаемый план выполнения из SQL Sentry Plan Explorer:

Answer 1

Поскольку работает DBCC CHECKDB займет так много времени, чтобы заполнить указанную базу данных DataWarehouse, вместо этого я запустил DBCC CHECKALLOC и DBCC CHECKCATALOG и не видел никаких проблем.

После того, как статистика индекса была обновлена ​​в целевой базе данных, запрос теперь выполняется в секундах.

Answer 2

Хорошо, я столкнулся с той же проблемой, что и вы на этой неделе после того, как мы включили TF4199 в SQL Server 2014 SP1 CU6. Внезапно наши сборки для некоторых баз данных были таймингами, другие были в порядке. Мы думали, что это связано с размером dacpac, но наша самая большая БД не пострадала. Мы действительно пытались обновить статистику, они не сработали для нас. Ошибка SQLPackage.exe мы получали было:

*** Error extracting database:Could not extract package from specified database. 

Unable to reconnect to database: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. 
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. 
The wait operation timed out 

Так я взял то, что вы имели в запросе и сделал некоторые исследования. Используя SQL Sentry, я обнаружил, что схема соединения выглядит так:

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

sys.sysschobjs 
sys.sysobjvalues 
sys.sysidxstats 
sys.syssingleobjrefs 

запрос, который вы показали выше пошел от 51м 15с (да, он принял это долго), чтобы 0s. Вот код, который я использовал, чтобы исправить мою проблему обновления статики для указанных объектов (у нас был несколько БДА с проблемой):

exec sp_msforeachdb '   
use [?]; 
update statistics sys.sysschobjs; 
update statistics sys.sysobjvalues; 
update statistics sys.sysidxstats; 
update statistics sys.syssingleobjrefs; 
'; 

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