Обычно я использую Microsoft SQL Server Management Studio 2012 (11.0.3000.0) с результатами запроса, отображаемыми в виде сетки. По состоянию на 3 или 4 дня назад результаты запроса были довольно медленными, но только с перерывами. Например, простой запрос, такой как

SELECT GETDATE() 

потребуется 7 секунд (в соответствии с SSMS) для отображения текущей даты / времени. Если я запускаю запрос с включенной трассировкой / профилировщиком, я вижу, что запрос выполняется почти сразу же, даже если таймер SSMS продолжает работать, и в течение некоторого времени результаты не отображаются. Результирующее значение даты / времени совпадает с тем, которое отображает трассировка / профилировщик для столбца "StarTime". Обычно запрос возвращается через 1 секунду или менее, но если я выполню 5 или 6 раз, я поймаю проблему, и для ее завершения потребуется некоторое время.

Когда это происходит, мой четырехъядерный ноутбук будет загружать процессор до 25% (полное ядро используется в течение всего периода времени), пока не будет построена сетка.

Я подключаюсь к локальному серверу (в моей локальной сети), который находится под очень малой нагрузкой, и, похоже, ни у кого в моей компании нет подобных проблем. Я установил SSMS 2014, чтобы увидеть, помогло ли это (не помогло). Думая, что это проблема с составлением самой DataGrid, я установил .NET 4.6, который тоже не помог.

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

Кажется, это не проблема сети:

Reply from 192.168.10.47: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.10.47:
    Packets: Sent = 24, Received = 24, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

У кого-нибудь есть предложения по поводу того, что я должен попробовать?

Я на Windows 7 (x64).

1 ответ1

0

Я смог найти проблему, выполнив запрос во время мониторинга процесса с помощью Process Monitor из SysInternalSuite. При отображении результатов запроса в сетке SQL Server Management Studio создает файл .tmp в C:\Users\username\AppData\Local\Temp\ named tmp ####. Tmp (где # - это случайно сгенерированные символы),

По какой-то причине мой временный каталог был заполнен более чем 40 000 этими файлами (все они пусты), и Process Monitor показывал, что когда мой запрос не отображал результаты, он выдавал тысячи ошибок "NAME COLLISION", пытаясь найти новое имя для временного файла, который он пытался создать.

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

Удаление всех файлов .tmp из этого временного каталога немедленно решило мою проблему.

Надеюсь, это поможет кому-то еще.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .