Замедлите запрос INFORMATION_SCHEMA
Другая конфигурация, которой я наслаждался, кладет мою домашнюю папку под репозиторий мерзавца. Каждый раз, когда я перемещаюсь в новую машину, я просто синхронизирую к другой машине. Никакой смысл в использовании сложного программного обеспечения с графический интерфейсами пользователя.:-)
Оставленные соединения известны за генерацию крупного recordsets, если обстоятельства разрешают. Я иногда сталкивался с этим видом проблемы, и у меня нет быстрого и легкого ответа. Я нашел, что проигрывание вокруг с запросом, например, путем создания запроса одно соединение за один раз, является лучшим способом удаться, какое соединение является casuing проблема.
Вы попытались провести избранный подсчет (*) от таблиц в запросе, чтобы видеть, есть ли у одного из них неожиданно высокое, рассчитывают строки?
МЛАДШИЙ
Больше мыслей: не ясно до сих пор, связана ли проблема с сервером или если бы запрос является патологическим и уничтожил бы любой сервер. Я предполагаю, что Вы могли скопировать базу данных в другой сервер и попробовать запрос снова.
Как насчет того, чтобы изменить запрос, чтобы быть чем-то как:
SELECT t.TABLE_NAME, ISNULL(pk_ccu.COLUMN_NAME,'') PK, ISNULL(fk_ccu.COLUMN_NAME,'') FK
FROM INFORMATION_SCHEMA.TABLES t
LEFT JOIN
( INFORMATION_SCHEMA.TABLE_CONSTRAINTS pk_tc INNER JOIN INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE pk_ccu
ON pk_ccu.CONSTRAINT_NAME = pk_tc.CONSTRAINT_NAME
)
ON pk_tc.TABLE_NAME = t.TABLE_NAME AND pk_tc.CONSTRAINT_TYPE = 'PRIMARY KEY'
LEFT JOIN
( INFORMATION_SCHEMA.TABLE_CONSTRAINTS fk_tc INNER JOIN INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE fk_ccu
ON fk_ccu.CONSTRAINT_NAME = fk_tc.CONSTRAINT_NAME
)
ON fk_tc.TABLE_NAME = t.TABLE_NAME AND fk_tc.CONSTRAINT_TYPE = 'FOREIGN KEY'
Я думаю, что внутренние объединения должны быть безопасными начиная с tc, и ccu таблицы должны иметь соответствие записям. Выполнение запроса этот путь улучшают время выполнения?
-
1Это doesn' t замедляются, пока я не добавляю последнее соединение. Запрос возвращает 5 004 записи. выберите количество () из INFORMATION_SCHEMA.TABLES - 3 716 избранных количеств () от INFORMATION_SCHEMA.TABLE_CONSTRAINTS - 2 224 избранных количеств (*) от INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE - 2221 – 23 June 2009 в 19:06
-
2Посмотрите редактирование к моему сообщению. – John Rennie 23 June 2009 в 20:02
-
3Да, это возвращает его к выполнению через несколько секунд, спасибо. I' d все еще любят пытаться узнать, почему, из сотен серверов, запускающих это приложение, только этот решил быть медленным. – 24 June 2009 в 16:21
-
4You' d имеют к, пристально смотрит на данные в таблицах для наблюдения, почему, но принимают во внимание, что общее количество записей в объединяемых таблицах могло быть 376*2224*2221*2224*2221, который является, erm, большое количество. Обычно столбцы, к которым присоединяются, индексируются, и соединение очень эффективно, однако с левыми соединениями, я видел, что SQL разочаровывается в индексации и обращении к сканированиям таблицы. Это делает вещи очень медленными. Точно, как SQL решает это я don' t знают. – John Rennie 24 June 2009 в 18:07
Вы проверили, чтобы видеть, блокируетесь ли Вы?
Так как Вы перешли к глубине получения плана выполнения, я предполагаю, что Вы имеете, но это всегда стоит спросить. В зависимости от того, в каком уровне изоляции Вы работаете и что другое действие работает на системе, Вы могли ожидать блокировок.
Таблицы могли быть высоко фрагментированы?
Можно проверить системные таблицы на фрагментацию на SQL 2000 (не SQL 2005 или позже). См. запись в блоге Kalen Delaney на системной фрагментации таблицы для получения дополнительной информации там. (Если таблицы не являются очень большими, однако, высокие уровни фрагментации могли бы вводить в заблуждение. Я обычно использую 1K страницы как показывает опыт.)
Экземпляр SQL имеет Большую Проблему Перфекта?
Я действительно не уверен, является ли проблемой план здесь - из ссылки похоже, что у Вас есть план с некоторыми раскормленными соединениями, но если бы на самом деле очень немного строк возвращаются затем, я не думаю, что те соединения сделали бы производительность ужасной, если у Вас нет других проблем. Я видел планы, которые переоценили rowcounts много и работали очень хорошо, это - недооцениваемые количества строки, которые обычно уничтожают меня. (Если другие знают об экземплярах, где это могло бы быть неправильно, я хотел бы услышать о них!)
В этой точке я лично сделал бы быструю проверку sql среды на поле для проверки вещей взгляд, как я ожидаю. Я часто находил эти проблемы, "почему является этот запрос медленным" выводом к нахождению, что существует большая проблема перфекта.
- опции sp_configure, такие как maxdop, минута памяти / макс., блокируют настройки
- проверьте Журнал ошибки SQL на любые предупреждения относительно задержки диска, удостоверьтесь, что то, когда это запустило его, смогло использовать большие страницы, если я ожидаю, что это будет использовать большие страницы и т.д.
- регулярно планируются sql задания, завершающиеся в нормальном timerange?
- проверьте любые счетчики perfmon, которые Вы собираете, чтобы видеть, ли они в нормальном диапазоне.
Просто мысль, механизм оптимизатора в SQL, 2000 раньше испытывал затруднения в попытке найти наиболее оптимизированный queryplan для операторов больше чем с 4 внутренними объединениями, и я думаю, что это еще более твердо с левыми соединениями.
Поскольку Вы видите в quereplan Вас, если, он работал, многие многим запрашивают.
Лучшая практика для SQL, 2000 должен разбить код при необходимости в данных из более затем 4 таблиц.
/Håkan Winther
-
1