К сожалению, сейчас роль специалистов по Performance tuning и troubleshooting баз данных урезается только до последнего — troubleshooting'a: практически всегда к специалистам обращаются, только когда проблемы уже достигли критической точки, и их нужно решить «еще вчера». Да и то хорошо, если обратятся, а не отсрочат проблему покупкой еще более дорогого и мощного «железа» без детального аудита производительности и нагрузочных тестов. Ведь достаточно часто бывают разочарования: закупили оборудования на сумму в 2-5 раз дороже, а по производительности выиграли лишь 30-40%, весь прирост от которого через несколько месяцев съедается либо увеличением числа пользователей, либо экспоненциальным ростом данных, вкупе с усложением логики.

И сейчас, во времена когда активно растет количество архитекторов, тестеров и DevOps инженеров, а разработчики Java Core оптимизируют даже работу со строками, медленно, но верно наступает пора и оптимизаторов баз данных. СУБД с каждым релизом становятся настолько умнее и сложнее, что изучение как документированных, так и недокументированных нюансов и оптимизаций требует огромного количества времени. Ежемесячно выходит огромное количество статей и проводятся крупные конференции посвященные Oracle. Простите за банальную аналогию, но в этой ситуации, когда администраторы баз данных становятся подобными пилотам самолетов с бесчисленным количеством тумблеров, кнопочек, лампочек и экранов, уже неприлично нагружать их еще и тонкостями оптимизации производительности.