Таблица в SQL Server не будет возвращать более нескольких тысяч строк

Question

Использование SQL Server 2005. Я делал несколько простых запросов к таблице, содержащей около 200 тыс. Записей. На сегодняшний день, когда я приступил к работе, простой SELECT * FROM выполняется до тех пор, пока не получит около 20 тыс. Строк ... и затем остановится. Это не пройдет более 20 тысяч строк. Если я попытаюсь выбрать только ОДНУ строку, используя ORDER BY Created DESC, запрос будет выполняться бесконечно. Я никогда не сталкивался с этим раньше. Все остальные таблицы работают нормально. Возможно ли, что мой стол испортился? Это буквально произошло за одну ночь. Таблица принимает данные в реальном времени, но делает это (через форму) в течение нескольких месяцев без проблем. Возможно, какая-то ошибочная запись нарушает запрос? Если так, то как я мог найти это ... так как я больше не могу получить результат назад?

Я прошу прощения, если это расплывчато, но я не уверен, как еще это сказать.

Answer 1

Я бы предположил, что незафиксированная транзакция блокирует хотя бы одну из строк или страниц, которая несовместима с общими блокировками, требуемыми вашим запросом SELECT.

Чтобы устранить это, вы можете в одном окне SSMS выполнить запрос SELECT ..., который не прошел.

Затем во втором окне, пока первый запрос все еще выполняется и заблокирован, запустите следующий скрипт .

Это должно показать вам ошибочный SQL вместе с достаточным количеством деталей для его устранения.

SELECT Blocking.session_id          AS BlockingSessionId,
       Sess.login_name              AS BlockingUser,
       BlockingSQL.text             AS BlockingSQL,
       Waits.wait_type              WhyBlocked,
       Blocked.session_id           AS BlockedSessionId,
       USER_NAME(Blocked.user_id)   AS BlockedUser,
       BlockedSQL.text              AS BlockedSQL,
       DB_NAME(Blocked.database_id) AS DatabaseName
FROM   sys.dm_exec_connections AS Blocking
       INNER JOIN sys.dm_exec_requests AS Blocked
         ON Blocking.session_id = Blocked.blocking_session_id
       INNER JOIN sys.dm_os_waiting_tasks AS Waits
         ON Blocked.session_id = Waits.session_id
       RIGHT OUTER JOIN sys.dm_exec_sessions Sess
         ON Blocking.session_id = Sess.session_id
       CROSS APPLY sys.dm_exec_sql_text(Blocking.most_recent_sql_handle) AS BlockingSQL
       CROSS APPLY sys.dm_exec_sql_text(Blocked.sql_handle) AS BlockedSQL
ORDER  BY BlockingSessionId,
          BlockedSessionId 

Answer 2

SELECT COUNT (*) что-нибудь возвращает?Это точно (например, примерно 200 КБ)?Сколько времени это займет?

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

Answer 3

DBCC CHECKTABLE может использоваться для проверки целостности отдельной таблицы и ее индексов.

«SET ROWCOUNT» кажется наиболее вероятным виновником, но, вероятно, вы не устанавливаете его намеренно. Это значение / настройка могут быть заданы как фон для вас; в SSMS его можно настроить для применения ко всем окнам (Инструменты / Параметры / Выполнение запроса) или даже только к текущему окну (Запрос / Параметры запроса / Выполнение).

Существуют и другие (и, честно говоря, нелепые) возможности. Отслеживание сеанса (от входа в систему до отправленного запроса) через SQL Profiler может выявить больше и более тонкую информацию.

Answer 4

Была ли команда SET ROWCOUNT применена к вашему сеансу?