SQL Server 2008 Query работает медленно, но быстро разрабатывается.

У меня есть запрос, который выполняется примерно за 2-4 минуты на производстве, но выполняется за пару секунд при разработке. Обе эти базы данных находятся на одном и том же сервере. (никаких лекций о разработке и производстве, производство действительно все еще находится в разработке).

Я имею в виду, что я могу просто открыть два окна запроса и последовательно получить два разных результата. Я запустил RedGate SQLCompare, и разницы в схемах (индексах и т. д.) нет. Я отключил сайт, который подключается к БД, поэтому не должно быть никаких подключений, кроме моего сеанса Management Studio.

Что может быть причиной этого? Я создаю базу данных разработки, копируя производственную (в Management Studio щелкните правой кнопкой мыши базу данных и нажмите «Копировать базу данных»)

Это действительно странно. Я не хочу вносить какие-либо изменения в индекс, потому что странно то, что копия молниеносно работает, а производство очень, очень медленно, но по сути это должны быть точные копии.


person JustAProgrammer    schedule 09.04.2009    source источник


Ответы (6)


Я не знаю специфики SQLServer, но обычно это происходит из-за различий в статистике таблиц в двух базах данных. Посмотрите на планы запросов, чтобы увидеть, отличаются ли они. Запустите версию SQLServer команд «анализировать таблицу» или «анализировать схему».

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

Что-то еще, чтобы проверить - и это просто я показываю свое невежество - но действительно ли «копирование базы данных» копирует данные или только определения объектов?

person SquareCog    schedule 09.04.2009
comment
Да, статистику нужно смотреть в первую очередь. Вы можете запустить EXEC sp_updatestats в качестве своего рода огнемета, чтобы увидеть, дает ли это какие-либо первоначальные улучшения. В остальном SquareCog прав: ищите проблемы с конфигурацией (особенно с дисками/дисками). - person Michael K. Campbell; 10.04.2009
comment
Большое спасибо за комментарий о EXEC sp_updatestats - это полностью решило мою проблему. Я подозреваю, что индексы не использовались, потому что они устарели, несмотря на их воссоздание! - person jocull; 01.11.2013

Вы не предоставляете никаких подробностей о структуре БД или рассматриваемом SQL-запросе, но если вы уверены, что настройка одинакова для обеих сред, то это может быть просто объем данных в вашей производственной БД, который выделяет в- эффективный запрос.

person MadMurf    schedule 09.04.2009

Хорошо, спасибо всем. Я думаю, что проблема была связана с фрагментацией индекса. Я думал, что Copy Database просто скопировал файлы. Я сделал DBCC DBREINDEX для каждой таблицы, и теперь все работает отлично. Всем спасибо!

person JustAProgrammer    schedule 09.04.2009

В моем случае это произошло из-за того, что производственная база данных находится за пределами площадки (другой город), а база данных разработки находится в здании. дух. Запрос возвращал много данных, и, конечно, этот объем данных занимает больше времени по внешней сети. Я просто не соединил точки, так как производственная БД была намного быстрее, чем старая коробка разработки, и большинство наших запросов не возвращают достаточно данных для сети, чтобы быть фактором скорости. Скорее, это так, но рабочий блок настолько быстрее, что даже при более медленном сетевом соединении большинство запросов по-прежнему возвращались быстрее, чем из блока разработки.

person AaronS    schedule 17.08.2011

Попробуйте запустить профилировщик SQL, чтобы увидеть, что работает в рабочей среде.

person Jordan Johnson    schedule 09.04.2009

Красные ворота по умолчанию игнорируют статистику и такие вещи, как коэффициент заполнения.

person gbn    schedule 09.04.2009
comment
какие? не могли бы вы уточнить? - person Mitch Wheat; 13.04.2009
comment
Редактировать проект, последняя вкладка (параметры?), см. в игнор-листе. И кнопка Red Gate по умолчанию. - person gbn; 13.04.2009