Для синхронизации SQL Source Control требуется несколько часов

Ситуация:

Мы используем локальные экземпляры SQL Server на наших ноутбуках и привязываем их к нашим репозиториям SVN с помощью Red-Gate SQL Source Control. Первоначально, когда мне выдали этот ноутбук, выполнение синхронизации «получить последнюю версию» и «фиксировать» проходило относительно быстро (‹ 2 минут для 1/4 до 4/4). Затем через несколько недель стало совершенно очевидно, что процесс резко замедлился, и теперь процесс занимает около 20 минут для одной синхронизации.

В этот момент я начал пробовать все основные тактики устранения неполадок для этой проблемы с SQL Source Control, выполняющим все, от удаления до переустановки; к обновлению версии до последней и даже переходу на различные более старые версии. Я протестировал SSC с локальным репозиторием, чтобы исключить сеть, с «рабочей папкой» и даже использовал облегченный репозиторий «Просто оцениваю». Все они были очень медленными; так же медленно, как и любой другой вариант, требующий не менее 20 минут для выполнения одной синхронизации.

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

В конце концов я обнаружил, что внезапно я мог синхронизировать базу данных намного быстрее (около 5 минут), если не было статических данных, связанных с репозиторием. Но проблема заключалась в том, что данные должны были быть связаны (либо данные конфигурации SSIS, либо статические данные RI), поэтому это был нежизнеспособный вариант, но он помогает немного точнее определить реальную проблему.

Теперь время синхронизации увеличилось примерно до 2 часов для одной синхронизации. Есть несколько других разработчиков, также занимающихся этой проблемой, одному из которых приходится ждать до 6 часов, чтобы получить последнюю версию.

Другая информация:

• Никакие другие приложения не работают медленно на этом ноутбуке.

• Диск представляет собой зашифрованный твердотельный накопитель, настроенный на использование 1 ГБ ОЗУ для кэширования.

• Мы провели тестирование с отключенным антивирусным/защитным программным обеспечением, и это не дало никаких результатов.

Что может быть причиной этого?


person artofsql    schedule 09.12.2014    source источник
comment
Я вижу, вы сделали это как самостоятельный ответ, чтобы вы могли добавить что-то в stackoverflow. Но здесь нет фактического вопроса. И ваш вопрос, скорее всего, будет закрыт как слишком широкий. Самостоятельный ответ не освобождает вас от обычных стандартов вопросов.   -  person JK.    schedule 09.12.2014
comment
Привет JK, Спасибо, что указали, что я забыл вопрос в конце. Ошибка копирования и вставки, кажется. Что касается вашего второго момента: вопрос может показаться широким, но устранение неполадок сторонних приложений может быть настолько сложным и неоднозначным, поэтому иногда это настолько конкретно, насколько это возможно, и только после нахождения решения вы можете лучше понять, каким был бы идеальный вопрос. Казалось, что лучшим подходом было бы структурировать вопрос, основываясь на том, что я знал тогда, те же вопросы, которые другие, занимающиеся этой проблемой, задавали бы и искали, чтобы помочь им найти решение.   -  person artofsql    schedule 09.12.2014


Ответы (1)


Проблема в первую очередь связана с Red-Gate SQL Compare \ Data Compare.

Симптом: система управления версиями SQL вызывает SC и SDC при синхронизации данных с репозиторием, и этот процесс занимает очень много времени.

Основная причина: SC и SDC создают множество (буквально тысячи в секунду) временных файлов в папке «%USERPROFILE%\AppData\Local\Temp\Red Gate» во время сравнения временных и рабочих базовые папки и по какой-то причине эти приложения не всегда удаляют старые файлы. Со временем количество потерянных файлов накапливается, и в результате получается фрагментированная папка, доступ к которой очень медленный. После нескольких месяцев работы с Red Gate над этой проблемой они, наконец, смогли воспроизвести эту проблему в своей лаборатории, и она была официально признана ошибкой в ​​соответствии с SC-7647.

В моем случае я обнаружил более 100 000 файлов в этой временной папке. После очистки файлов время, необходимое для синхронизации с SVN, сократилось примерно до 2 минут даже со статическими данными.

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

Следующий оператор командной строки попытается удалить все файлы старше 1 дня.

forfiles -p “C:\Users\<your username>\AppData\Local\Temp\Red Gate” /s /m *.* /d -1 /c “cmd /c del @path”

Для получения дополнительной информации ознакомьтесь с моим сообщением в блоге на эту тему по адресу http://artofsql.net/guides/improving-sql-source-control-and-sql-data-compare-performance/

person artofsql    schedule 09.12.2014
comment
SQL Source Control 3.8.4+ и SQL Data Compare 11.1.6.9+ должны намного лучше очищать временные файлы, созданные в сеансе. Они доступны на канале частых обновлений. Система контроля версий SQL также теперь будет пытаться очистить файлы, оставленные предыдущими сеансами. Источник: я работаю в Red Gate, вот примечания к выпуску. - person Graham; 11.03.2015
comment
Интересный. Служба поддержки Red Gate сообщила мне, что собирается уведомить меня, когда эта проблема будет решена, но пока этого не сделала. - person artofsql; 24.03.2015
comment
Это была моя попытка проинформировать вас (и любые другие заинтересованные стороны). Оглядываясь назад, я должен был также отправить вам по электронной почте исходный запрос в службу поддержки. Извиняюсь за путаницу, поэтому я обычно придерживаюсь написания кода. - person Graham; 15.04.2015
comment
@ Грэм - Не беспокойся. Команда, с которой я работаю, и я очень ценю ваше внимание к этому! Мы работаем с обновленной версией и обратимся в службу поддержки, если возникнут дополнительные проблемы. - person artofsql; 17.04.2015