Проблемы с производительностью при миграции с Sybase 12.5 на Sybase 15 - PullRequest
Новая
       6

Проблемы с производительностью при миграции с Sybase 12.5 на Sybase 15

1 голос
/ 09 мая 2011

Мы находимся в процессе миграции нашей БД на Sybase 15. Хранимые процедуры, которые работали нормально в Sybase 12.5, имеют низкую производительность в Sybase 15. Однако при добавлении 'set merge_join off' Syabse 15 работает быстрее.Есть ли способ использовать хранимые процессы Sybase 12.5, как в Sybase 15 / или с минимальными изменениями?Есть ли у нас какие-либо альтернативные способы, кроме переписывания всего хранимого процесса?

Ответы [ 4 ]

1 голос
/ 11 ноября 2011

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

Если это маленькое приложение, и вы просто хотите, чтобы оно работало без подсказки о некоторых или всех новых оптимизаторах, статистике индекса, изменении данных, триггерах входа в систему, затем используйте режим совместимости или, возможно, лучше, ограничьте Оптимизатор до allrows_oltp , избегая dss и mix (которые будут использовать хеш-соединения и объединения слиянием соответственно.)

Если это большая система, и у вас есть время, я думаю, вы должны узнать об этом, разрешить хотя бы смешивать, если не dss, и убедиться, что вы

обновлять статистику индексов (гораздо важнее иметь статистику по 2-м и последующим столбцам индексов, чтобы оптимизировать право на слияние и хэш-соединения.) понять DATACHANGE (чтобы найти таблицы, которые требуют обновления статистики.) триггеры входа в систему (может быть полезно для настройки некоторых сессий / пользователей на пониженные или повышенные уровни оптимизации - см. веб-сайт Sypron с описанием Роба Вершура.) убедитесь, что у вас есть доступ к sp_showplan (используйте инструмент, или получите sa_role, или используйте технику Роба Версхора для предоставления поддержки).

Новые оптимизаторы хороши, но я думаю, что это правда, что они требуют времени и энергии, чтобы понять и сделать работу. Если у вас нет времени и энергии и вам не нужна дополнительная производительность, просто придерживайтесь allrows_oltp или даже режима совместимости (у меня нет опыта работы с последним, но как-то мне это кажется неправильным.)

0 голосов
/ 30 марта 2015

В оптимизаторе Sybase 15 используется больше алгоритмов объединений, т. Е. Объединение слиянием, соединение с использованием хэша, соединение с вложенным циклом и т. Д.

Где, как и в Sybase 12.5, наиболее часто используемый алгоритм объединения - это соединение с вложенным циклом.Помимо включения режима совместимости (он будет использовать оптимизатор Sybase 12.5 и не даст никаких преимуществ оптимизатора Sybase 15), вы можете играть с различными целями оптимизации.

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

-- server-wide default:
sp_configure 'optimization goal', 0, 'allrows_oltp'

-- session-level setting (overrides server-wide setting):
set plan optgoal allrows_oltp

-- query-level setting (overrides server-wide and session-level settings):
select * from T1, T2 where T1.a = T2.b plan '(use optgoal allrows_oltp)'

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

Примечание. После установки значения allrows_oltp выполните надлежащее тестирование, чтобы выяснить, не затронут ли этот запрос какой-либо другой запрос

Более подробную информацию о целях оптимизации можно найти здесь

0 голосов
/ 11 апреля 2013

Я бы сказал, попытайтесь найти основную причину проблемы. У нас тоже была проблема с одним из наших процедур, когда время увеличилось с 27 до 40 минут.При диагностике и исправлении процедуры потребовалось всего 6 ошибок (что составило 27 минут).Оптимизатор ASE15 и обработка запросов намного лучше, чем 12.5.

Если у вас нет времени, просто установите режим совместимости на уровне сеанса для этого процесса.

"установите compatibility_mode на"

Но сравните результаты.

Кроме того, если у вас есть время, попробуйте использовать DBCC (302,310) и 3604 (для перенаправления), чтобы понять, почему оптимизатор использует такой оператор LAVA.

Отличная статья Роба V

0 голосов
/ 09 мая 2011
...