казинакАндрей Панфилов...Однако DBA в том виде, в котором они сейчас существуют, не нужны.и в каком таком виде они существуют сичас?скажем так... я не могу припомнить что за последние лет 10 наммне ДБА хоть как-то существенно помогли, максимум что можно ожидать - это в тебя кинут нотой с металинка (как будто у самого навыка поиска и доступа нет) и на этом все закончится, зато случаев когда откровенно не делают свою работу могу вспомнить довольно много, вот примеры в порядке уменьшения выбешивания:
просишь чистенькую базу и русскими словами пишешь какие примерно ресурсы нужны и что там будешь создавать - в ответ просят заполнить какую-то ими самими разработанную форму. Вот зачем мне это вообще? Если формализовали у себя процесс, то и создавайте сами эти заявки, зачем мне с этим разбираться если мне нужен сервис с определенными параметрами?

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

спрашивают нужно ли делать резервные копии - идите сами и спрашивайте у владельца системы какие RTO/RPO ему нужны или руководствуйтесь внутренними регламентами

в случае каких-то непонятных тормозов начинают переводить стрелки на админов OC, СХД или виртуализации - вы работаете с этими людьми в одной компании, идите и разбирайтесь с проблемой самостоятельно, мне совершенно не интересно на чем крутится ваша база - мне интересен сервис.

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

SERG1257Как автор похожей формы могу ответить. Я так понимаю, что база нужна не Андрею Панфилову, а проекту. По факту ДБА нужен центр затрат (статья расходов) и имя человека от бизнеса ответственного за проект. У ДБА имеется туева хуча баз и владельцев, а вот у разработчика как правило один так что разработчику на этот вопрос ответить проще.Для начала у разработчика по одному проекту баз обычно около пяти (примерно столько окружений регламентирует SDLC), помимо этого может быть несколько заказчиков, и у каждого заказчика свои тараканы в головесвой взгляд на то как нужно строить IT-инфраструктуру и процессы в ней, но вот вникать во все эти тонкости IT-процессов конкретного заказчика нет ни времени, не желания. В подавляющем большинстве случаев для приложения нужен некий стандартный джентельменский набор привилегий в СУБД, а заполнение всяких форм - это разведение бюрократии, причем совсем не в том месте где нужно: если формы вам нужны для CMDB, то честь вам и хвала, за то что ведете CMDB, но в этом случае заявки должны быть в духе "хочу как там, но только с перламутровыми пуговицами". Однако в большинстве случаев ситуация несколько иная: IT-инфраструктура требует заполнения заявок, а CMDB у них отсутствует, что приводит к довольно забавным ситуациям: перенесли приложение в другое окружение, а оно не работает, потому что информацию о требуемых настройках взять неоткуда (ну не из почты же эти заявки заново собирать?).
SERG1257А простите откуда это возьмет ДБА, кто должен создавать эти скрипты?
...
Сгенерировать из тестовой среды. Или это для тестовой среды?Ну что значит откуда возьмет? Как по мне так должен сам сочинить из формального описания типа: "во время установки релиза мы будем создавать таблицы, индексы, процедуры, тригеры и т.п." (могут быть различные вариации, например предоставлен набор скриптов для создания объектов в схеме - а какие привилегии для этого нужны пусть сам DBA решает), а как оно ляжет в вашу базу - это уже ваша забота, т.е. хотите напрямую привилегии выдавайте, хотите через роль, хотите базовые роли используйте. А скрипты со среды разработки вам ничем не помогут: у меня могут быть свои собственные предпочтения типа использования ASM, OMF, создание роли для раздачи привилегий, которые будут конфликтовать с вашим собственным мировоззрением.

SERG1257Уверен, что вопрос был немного другим типа какую стратегию резервирования рекомендует вендор. В случае отсутствия рекомендаций будет применена внутренняя стандартная схема.Смотрите какая штука, во-первых, сохранность данных - это целиком и полностью ответственность DBA, метрики RTO и RPO - целиком бизнесовые, поэтому если вас интересует стратегия резервного копирования, то идите и сами разбирайтесь в владельцем ИС в том, что ему действительно нужно (условно если вам в заявке прилетела куча девяток после запятой для RTO, то стендбай должен сам по себе материализоваться, а не заставлять разработчика создавать еще одну заявку), приплетать сюда разработчика или вендора смысла нет никакого (разве чтобы потом стрелки перевести: "вот нам тут так порекомендовали, а оно пару суток восстанавливается").
SERG1257Андрей Панфиловв случае каких-то непонятных тормозов начинают переводить стрелки на админов OC, СХД или виртуализацииЭ-э тут скорее не перевод стрелок "кто виноват", а поиск решения "что произошло". Все было хорошо до часа Ч. Вопрос кто что поменял в час Ч.
Андрей Панфиловмне совершенно не интересно на чем крутится ваша базаесли разработчик накатил маленький незаметный патчик в рамках CI/CD, то этот патчик вполне мог быть причиной тормозов.Вот смотрите какой мой взгляд на проблемы типа "база неожиданно встала колом": во-первых, бизнес "покупает" ИС целиком, т.е. концепция "бить в рынду и привлекать всех подряд когда все сломалось" довольно часто имеет место быть, но в основном к решению подобного рода проблем в первую очередь привлекают разработчиков, во-вторых, со стороны DBA тупо переводить стрелки на разработчиков - это контрпродуктивно (при мне вот такие DBA пару раз самоопиздюливались), здесь правильной стратегией со стороны operations является следующая:
- сравнить паттерн текущей нагрузки с тем что было до этого - здесь главное понять с чем сравнивать (существуют некие корреляции с рабочим временем, временем года, закрытием финансового года)
- узнать производились ли какие-то (не)регламентные работы (обновления ИС, связанного ПО, сетевой инфраструктуры, СХД и пр.), были ли бизнесовые движения в сторону увеличения нагрузки (массовое подключение новых пользователей, увеличение потока данных за счет новых продуктов, рекламы и пр.) - приезжать в офис пораньше после проведение регламентных работ видится вообще крутой стратегией, правда это уже на грани фантастики, я всего одного человека такого знаю, в основном народ предпочитает ночевать в офисе после того как все уже сломалось
- выяснить, имеет ли место быть ли оверпровиженинг
- показать разработчику, что сейчас в проблемном месте вот так, а раньше было так (т.е. конкретный запрос стал дольше выполняться, или раньше запросов таких не было вообще, а теперь появились, а ежели диски начали медленнее крутиться, то и не беспокоить разработчика вообще)

Правда это я живу в идеальном мире, кардинально отличающимся от реальности, обычно бывает так:
- ой, у нас все плохо
- ну пришлите awr чтоли
- ой, пока не можем, DBA в дороге, на совещании, на обеде, в туалете, еще где

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


SERG1257у них совершенно нелинейная зависимость между ресурсами и счетомЗато там ползунок можно по ночам влево откручивать и экономить деньги

SERG1257Да не вопрос. Но когда уже есть инфрастуктура, наняты админы перевод всего (а не только разработки) в облако выглядит странной идеей.Проблема здесь прежде всего в том, что в России все IT нищее, "на западе" (хотя я живу формально на востоке) все устроено несколько попроще: особых проблем в том что компания вбухала деньги в IT-проект и потом его успешно просрала нет, т.е. то что какие-то проекты не выстреливают считается совершенно нормальным, поэтому здесь люди считают что на начальном этапе проекта разместить его в облаке, чтобы не закупать оборудование и нанимать персонал, - это выгодно (ответить на вопрос почему облако оказывается больше чем в два раза дороже обычного хостинга я не могу), во-вторых, здесь очень сильно развит аутсорсиг, ну вот к примеру я первый раз приехал в Мельбурн еще в 2006 и довольно долго удивлялся, что у местного самого крупного телекома ( https://www.telstra.com.au/) в штате по сути нет operations - это полностью передано на аутсорсинг, при таком раскладе как-то без разницы где у тебя сервера установлены в облаке или нет, в облаке, видимо, получается выгоднее.