У меня есть RO-доступ в представлении SQL. Этот запрос ниже времен. Как этого избежать?
select
count(distinct Status)
from
[MyTable] with (NOLOCK)
where
MemberType=6
Сообщение об ошибке, которое я получаю:
Msg 121, уровень 20, состояние 0, строка 0
При получении результатов с сервера произошла ошибка транспортного уровня (поставщик: поставщик TCP, ошибка: 0 - период таймаута семафора истек.)
Хотя есть определенная нестабильность сети или что-то мешающее вашему соединению (возможно, 15 минут, что вы можете пересекать границу NAT или что-то в вашей сети отбрасывает сессию), я бы подумал, что вы хотите такой простой?), чтобы вернуться хорошо в течение любого ожидаемого времени (например, 1 с).
Я бы поговорил с вашим администратором базы данных и получил индекс, созданный в базовых таблицах в MemberType, Status. Если нет ни одной базовой таблицы или они более сложны и создаются с помощью представления или UDF, и вы используете SQL Server 2005 или выше, попросите его рассмотреть индексирование представления (в основном материализуя представление индексированным образом).
Ваш запрос, вероятно, прекрасен. "Срок таймаута семафора истек" - это ошибка сети, а не таймаут SQL Server.
например. см. http://support.microsoft.com/kb/325487
По-видимому, существует какая-то сетевая проблема между вами и SQL Server.
edit: Однако, по-видимому, запрос выполняется за 15-20 минут, прежде чем дать сетевую ошибку. Это очень долгое время, поэтому, возможно, сетевая ошибка может быть связана с длительным временем выполнения. Оптимизация базового представления может помочь.
Если [MyTable] в вашем примере является представлением, можете ли вы опубликовать определение представления, чтобы мы могли оптимизировать его?
Пожалуйста, проверьте журнал событий системы Windows на наличие каких-либо ошибок специально для "Источник события: Dhcp". Это, скорее всего, сетевая ошибка, связанная с DHCP. Время аренды истекло. Это не должно быть проблемой, связанной с SQL Server или самим запросом.
Просто выполните поиск в Интернете: "Срок таймаута семафора истек", и вы получите много предложений, что может быть решением вашей проблемы. К сожалению, решение этой проблемы не представляется возможным.
Вы можете поместить индекс в MemberType.
У вас есть индекс, определенный в столбце "Статус" и столбце "Тип пользователя"?
сколько у вас записей? есть ли какие-либо индексы на столе? попробуйте следующее:
;with a as (
select distinct Status
from MyTable
where MemberType=6
)
select count(Status)
from a
Моя команда периодически сталкивалась с этими проблемами при длительном запуске пакетов служб SSIS. Это происходит с момента обновления Windows-сервера.
Наши серверы служб SSIS и SQL находятся на отдельных серверах виртуальных машин.
Работая с нашей командой Wintel Servers, мы перезагрузили оба сервера, и на данный момент проблема исчезла.
Инженер сказал, что они не уверены, что проблема заключается в исправлениях или новых VMTools, которые они обновили одновременно. Сейчас мы будем отслеживать, и если проблемы с таймаутом повторятся, сначала они попытаются откатить драйвер VMXNET3, а затем, если это не сработает, убрать исправления июньского накопительного пакета.
Так что для нас проблема не имеет ничего общего с нашими SQL-запросами (мы загружаем миллиарды новых строк, поэтому он должен работать долго).
Это происходит потому, что запущен другой экземпляр сервера sql. Поэтому вам нужно сначала убить, а затем вы можете войти в SQL Server.
Для этого перейдите в Диспетчер задач, а затем в "Убить или завершить задачу" службу SQL Server, затем перейдите в Services.msc и запустите службу SQL Server.
Хотя у меня возникнет искушение винить мои проблемы - я получаю ту же ошибку с моим запросом, которая намного, намного больше и включает много циклов - в сети, но я думаю, что это не так
К сожалению это не так просто. Запрос выполняется в течение 3+ часов до получения этой ошибки и, по-видимому, происходит сбой в одно и то же время, если это просто запрос в SSMS и задание на SQL Server (пока не рассматривал детали этого, поэтому не уверен, что это та же ошибка определенно то же самое место, хотя).
Так что на случай, если кто-то придет сюда с подобной проблемой, этот поток: https://www.sqlservercentral.com/Forums/569962/The-semaphore-timeout-period-has-expired
предположить, что это также может быть аппаратная проблема или фактический тайм-аут.
Мои циклы не являются четными (они зависят от уровня продаж в данном месяце) с точки зрения времени, требуемого для каждого, поэтому для расчета хорошего месяца требуется около 20 минут (запрос рассчитан на 4 года).
Таким образом, вполне возможно, что мне нужно оптимизировать мой запрос. Я бы даже сказал, что это вероятно, так как некоторые изменения, которые я внес, включили новые таблицы, которые являются кучей... Итак, еще один раунд индексации моих данных перед тем, как перейти к конфигурации виртуальной машины и аппаратным тестам.