Комментарии 8
Возможно будет интересна статья с похожей идеей: https://db.cs.cmu.edu/papers/2017/p1009-van-aken.pdf
Они там и набор параметров автоматически определяют. Правда, тренировались не на Оракле, но какая разница.
Ну на самом деле не всегда. Сколько я в своей практике сталкивался с высоконагруженными СУБД, почти никогда такие методы не проходят.
Самая типичная причина — вы не можете повторить реальную базу на тестовом железе, чтобы там ее оптимизировать, поигравшись неизвестными параметрами.
И вы не можете сделать это на реальной промышленной базе.
Первое — потому что на тестовые железки очень редко тратят такие же деньги, как на промышленные, поэтому там другой размер базы, другая нагрузка, и в итоге — другой масштаб проблемы. Ну а почему на промышленной базе нельзя играться — я думаю и так понятно.
А если у вас есть деньги на стенд для нагрузочного тестирования, и время на само это тестирование — то как-то так складывается, что вы все-таки знаете большую часть ручек, которые можно покрутить с целью оптимизации.
Конечно, ставлю плюс за такой энтузиазм и кучу потраченного времени на саму статью.
Но… в общем-то, это все общеизвестно: и подход, и методика и такие куцые выводы. В оракле вообще гораздо важнее знать внутренние механизмы, и уже зная их можно заниматься не только тюнингом параметров, но и вообще траблшутингом как производительности, так и ошибок и багов. И, если уж заниматься таким копанием, то лучше брать боевые версии EE или SE, прикрутить systemtap, и покопать, например, насколько и в какие именно внутренние функции замедлились или ускорились после апгрейда 12.2 -> 18, 18 -> 19
В оракле вообще гораздо важнее знать внутренние механизмы, и уже зная их можно заниматься не только тюнингом параметров, но и вообщеТочно.
MaksimIvanov
С другой стороны: навскидку не усматриваю широкого упоминания, распространения такого подхода, в интернете, среди ит-специалистов, ДБА.Потому, что в реале такие подходы не работают. Именно для этого компания Oracle и понаписала всяких awr-ов, ash-ей, статпаков, addm-ов, адвайзеров и динамических оптимизаторов. Именно для этого компания Oracle и понасоздавала десяток видов индексов и множественные разнообразные механизмы ускорения сложных вычислений в среде СУБД. И понаписаны десятки книг про оптимизации запросов и СУБД. Вы не просто не сможете получить адекватное оборудование для теста. Вы не сможете получить адекватную нагрузку для теста. Часть параметров, которые вы собрались «настраивать» могут иметь самые неожиданные последствия, которые вообще будут проявляться только на определенных запросах, которые могут появляться 1 раз в сутки или в неделю. Нельзя просто дергать параметры в надежде, что будет лучше исходя из сегодняшних «улучшений». Это подход дилетанта. Необходимо досконально понимать на что и когда влияет определенный параметр. И менять его понимая и ожидая определенные изменения. Даже полноценно сформулировать что такое «лучше» и что такое «хуже» для сложной среды в реальности может быть очень сложно.
Иногда изменяя параметр, не понимая что делает, «активный» администратор-тестировщик приводит в неработоспособность части СУБД, о которых даже не подозревает. Особенно раздражает, когда достается такая изуродованная СУБД по наследству от уволившегося администратора. Не смотря на это таких администраторов руководство может восхвалаять (иногда притворно) за их сговорчивость и способность достигать кратковременные результаты уничтожая целостность СУБД и разрушая пока не очень видимые части СУБД. А когда приходится тратить существенные ресурсы и время на восстановление изуродованных частей СУБД тебя пытаются называть неквалифицированным.
Я забросил н@х такие развлечения вместе с самим Oracle.
Даже полноценно сформулировать что такое «лучше» и что такое «хуже» для сложной среды в реальности может быть очень сложно.
Да, в целом, если сильно упростить, то любой тюнинг — это практически всегда компромисс между кучей факторов.
Абсолютно поддерживаю, но, если посмотреть чуть глубже, то тут видим противостояние подходов к построению ИИ. И, как видим, подход "миллиард раз подергать за ручки" победил.
Говоря же о СУБД, думаю, что всякие оптимизаторы параметров смогут работать хорошо, когда будут иметь доступ к глобальной базе кейсов. Ведь, часто люди используют коробочный софт, который генерирует одинаковый профиль нагрузки у разных клиентов. Да и, уверен, самописный софт тоже очень похож друг на друга. Поэтому, перебрать все в рамках одной системы нереально. Но вот, если можно было бы увидеть, как каждый параметр влияет на быстродействие условного вордпресса на миллионах серверов по всему миру, то почему бы и нет?
Метод научного тыка, или как подобрать конфигурацию субд с помощью бенчмарков и оптимизационного алгоритма