Проблема производительности Sybase 15

Question

Я работаю с Sybase 15 в своем приложении, и есть проблемы с производительностью, связанные с вложенными объединениями. У меня есть хранимая процедура, которая выбирает 2 столбца из 2 таблиц и сравнивает равенства более 10 столбцов между этими 2 таблицами. Но когда я запускаю этот стор. proc., результат занимает 40 минут. Я добавил инструкцию "set merge-join off" в начало моего процесса, тогда результат занимает 22 секунды. но мне нужно еще одно решение без этого. Я использовал sybase 12.5 и раньше, и не было никаких подобных проблем, и мой процесс занял 3 минуты для результата.

Я сравнил конфигурации сервера с sp_configure между 15 и 12.5 и конфигурациями сервера sybase15 (настройки ввода-вывода и конфигурации памяти) больше, чем у сервера sybase12.5.

Информация: системные ресурсы, расположенные на компьютере sybase15, действительно хороши.

Answer 1

Так же, как и у других, у меня сочувствие, а не реальный ответ! Мы видим проблему, когда планировщик запросов ASE 15 в значительной степени недооценивает стоимость сканирования таблицы и аналогичным образом переоценивает стоимость использования кластерного индекса. Это приводит к объединению объединения, являющемуся предлагаемым планом Отключение объединений слиянием или установка allrows_oltp optgoal иногда приводит к лучшему плану запросов. Сметные расходы все еще далеки, но, сняв один вариант со стола, планировщик запросов может найти хорошее решение, хотя и с неправильным анализом.

В документах ASE 15 говорится, что у него гораздо более чистый набор алгоритмов, тогда как у планировщика ASE 12 было несколько особых случаев. Возможно, особый случай, который гласит: «Если у вас есть столбец кластеризованного индекса в объединении, это будет быстрее, чем сканирование таблицы», не было бы такой плохой идеей ...: (

Answer 2

Я только что провел 14 часов на работе, отлаживая критические проблемы с производительностью, которые возникли в результате миграции Sybase 15 на выходных.

Оптимизатор запросов принимает (для нас) очень странные решения.

Взять пример,

select a, b, c from table1, table2, table3 where ...

против

create table #temp (col1 int, col2 int, ... etc)

insert #temp
select a, b, c from table1, table2, table3 where ...

У нас был первый запуск вовремя, и мы не смогли заставить его принять правильное решение во 2-й инстанции, несмотря на большую переработку. Мы даже разбили запрос на временные таблицы, но все же получили необычные результаты.

В конце мы обратились к SET FORCEPLAN ON для некоторых запросов - это после 10 часов работы наших администраторов баз данных и Sybase на линии. Решение пришло не только от разработчиков Sybase, но и от разработчиков приложений.

Так что, чтобы сэкономить время, выбери этот маршрут - мое предложение.

Answer 3

Каждый, кто занимается этой проблемой, должен прочитать этот документ:

http://www.sybase.com/files/White_Papers/ASE15-Optimizer-Best-Practices-v1-051209-wp.pdf

В нем есть откровенное предупреждение о миграции с Sybase 12 на Sybase 15.

Quoteth:

... не относитесь к ASE 15 как к "просто другой релиз ". Столько, сколько мы бы хотел бы сказать, что вы могли бы просто обновить и направить ваши приложения на модернизированные серверы, глубина и Ширина перемен в одном из самых основные области базы данных, запрос выполнение, требует более целенаправленного режим тестирования. Эта статья предназначена предоставить вам ясные факты и лучшие практики, чтобы уменьшить это усилия столько, сколько практически возможно.

Далее речь пойдет о новом оптимизаторе запросов ASE 15, запросах OLTP и DSS (система поддержки принятия решений).

Однако , есть хорошие новости : в марте 2009 года Sybase 15.0.3 ввел режим совместимости. Смотрите следующий документ:

http://www.sybase.com/detail?id=1063556

В этом режиме вам не нужно анализировать запросы, чтобы определить, соответствуют ли они профилям OLTP или DSS.

Answer 4

Sybase эффективно переписал механизм запросов для версии 15, что означает, что запросы, которые выполнялись очень быстро на 12.x, могут работать намного медленнее на более новой версии, и наоборот. Единственный способ отладки - сравнить план запроса 12.x с планом запроса 15 и посмотреть, что происходит по-другому.