Вопросы Теги

TFS 2015 CodeSense Cleanup

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

Я выполнил запросы, которые широко доступны, например этот: 

SELECT TOP 3 o.name, 
SUM(reserved_page_count) * 8.0 / 1024 SizeInMB,
SUM(CASE 
WHEN p.index_id <= 1 THEN p.row_count
ELSE 0
END) Row_Count
FROM sys.dm_db_partition_stats p
JOIN sys.objects o
ON p.object_id = o.object_id
GROUP BY o.name
ORDER BY SUM(reserved_page_count) DESC

Чтобы найти это: 

name             SizeInMB       Row_Count
tbl_Content      313489.765625  10090278
tbl_Version      33400.828125   27518951
tbl_AggregateMap 10638.539062   32955145

И еще этот запрос: 

SELECT Owner = 
CASE
WHEN OwnerId = 0 THEN 'Generic' 
WHEN OwnerId = 1 THEN 'VersionControl'
WHEN OwnerId = 2 THEN 'WorkItemTracking'
WHEN OwnerId = 3 THEN 'TeamBuild'
WHEN OwnerId = 4 THEN 'TeamTest'
WHEN OwnerId = 5 THEN 'Servicing'
WHEN OwnerId = 6 THEN 'UnitTest'
WHEN OwnerId = 7 THEN 'WebAccess'
WHEN OwnerId = 8 THEN 'ProcessTemplate'
WHEN OwnerId = 9 THEN 'StrongBox'
WHEN OwnerId = 10 THEN 'FileContainer'
WHEN OwnerId = 11 THEN 'CodeSense'
WHEN OwnerId = 12 THEN 'Profile'
WHEN OwnerId = 13 THEN 'Aad'
WHEN OwnerId = 14 THEN 'Gallery'
WHEN OwnerId = 15 THEN 'BlobStore'
WHEN OwnerId = 255 THEN 'PendingDeletion'
END,
SUM(CompressedLength) / 1024.0 / 1024.0 AS BlobSizeInMB
FROM tbl_FileReference AS r
JOIN tbl_FileMetadata AS m
ON r.ResourceId = m.ResourceId
AND r.PartitionId = m.PartitionId
WHERE r.PartitionId = 1
GROUP BY OwnerId
ORDER BY 2 DESC

Чтобы найти 

Owner           BlobSizeInMB
CodeSense       264426.749071121093
VersionControl  8728.462930678710
TeamTest        477.505887984375
ProcessTemplate 2.953623771484
FileContainer   0.024445533203

И хотя VersionControl = 8GB кажется вполне нормальным, учитывая наш код, CodeSense безумно большой. Я нигде не нашел информации об этой функции или о том, как ее отключить. Пожалуйста, помогите!

PS: Если это связано с функцией CodeLens в VS, мы ее тоже не используем.

0
задан 13 March 2019 в 16:02
1 ответ

Эта функция называется CodeIndex, поэтому я не мог найти ее раньше.

Вот вся информация, необходимая для ее настройки: https://docs.microsoft.com / en-us / visualstudio / ide / codeindex-command? view = vs-2015

Я выключил его и сейчас пытаюсь уничтожить индекс, но он выдает ошибку

TF246018: операция с базой данных превысила предел тайм-аута и имеет был отменен. Убедитесь, что параметры операции правильно.

Но это другая проблема ...

РЕДАКТИРОВАТЬ: Вот что произошло. Я проверил средство просмотра событий на уровне приложений и обнаружил, что истекло время ожидания:

EXEC CodeSense.prc_DeleteAggregates @ partitionId = 1

Я проверил SP,и он делал 3 вещи

  • Вызов prc_iPrepareExecution , который ничего не делает: RETURN 0
  • Удалить из [CodeSense]. [tbl_AggregatorInputQueue] @ где равно 1. Таблица была пуста, поэтому делать там нечего.
  • Удалить из [CodeSense]. [Tbl_AggregateMap] , где @partitionId равно 1. Я запросил БД и обнаружил, что не было строк с другими идентификаторами разделов. Кроме того, выполнение SELECT COUNT (*) занимало более 5 минут, поэтому я отменил его, и тогда меня осенило: Я мог бы просто усечь таблицу, потому что единственный идентификатор раздела в моем случае - 1 . Это спасло меня от засорения диска кучей бесполезных журналов транзакций и удаления материала партиями.

Конечно, я усек его, но из соображений точности я затем повторно запустил TFSConfig CodeIndex / destroyCodeIndex в моей коллекции и на этот раз это сработало.

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

Я вернулся к журналу событий и обнаружил ] EXEC CodeSense.prc_DeleteOrphanedFiles @ partitionId = 1, @ createdBefore = 17.03.2019 21:05:28 на этот раз истекло время ожидания!

Этот SP создает таблицу в памяти, что нужно удалить, а затем удаляет их. Я создал копию этого SP с предложением TOP 100000 , чтобы ограничить количество строк, удаляемых за раз, и запустил его несколько раз, пока он не избавился от 2M + строк.

Однако в какой-то момент что-то еще должно быть ответственным за очистку таблиц tbl_FileReference , tbl_FileMetadata и особенно tbl_Content .

Я нашел сообщение в блоге , в котором предлагалось запустить EXEC prc_CleanupDeletedFileContent 1 один раз, а затем EXEC prc_DeleteUnusedFiles 1, 0, 100000 несколько раз.

Через 25 минут большой двоичный объект CodeSense полностью исчез 

Owner           BlobSizeInMB
VersionControl  8728.347916602539
TeamTest        477.505887984375
ProcessTemplate 2.953623771484
FileContainer   0.024445533203

Однако tbl_Content все еще огромен, и запрос все еще выполняется

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

РЕДАКТИРОВАТЬ 2 : Прошло более 24 часов, а запрос все еще выполняется. Выполнение диагностического запроса говорит мне, что tbl_Content действительно сжимается, и когда я использую параметр «Сжать файлы» в SQL Management Studio, файлы данных начинают иметь намного больше свободного места, так что он работает!

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

Удачи, если вы оказались в такой же ситуации.

1
ответ дан 4 December 2019 в 15:44

Теги

Похожие вопросы