Добрый день.
Есть тут кто админит SAP под Oracle?
Проблема следующая - мне админы SAP говорят, что для каждой инстанции должна быть отдельная физическая база, но почему так должно быть не говорят (утверждают что рекомендации SAP), я предлагаю им в одной базе хранить.
Кто-нибудь хранит в одной физической базе данные нескольких инстанций SAP, какие могут быть проблемы?

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

А почему Вас волнует (раз есть базисники, то это их головняк) как именно будут "разложены" БД по SAP-ландшафту ?

Мне, как DBA, не совсем удобно админить большое количество небольших по размеру БД.

Ivan KВиталий Перевозчиков,

Если в конторе только САПовские базы, и базисники нормальные, то оракловый админ по большому счету там не нужен, т.к базисники все делают сами, и все свои инструменты для этого у них есть.
С моей точки зрения, очень удобно засунуть каждую маленькую САПовскую базу в отдельную схему, но если САПерам так удобно и САП рекомендует, то лучше смириться.

А причина отдельного хранения - хотя бы организация файлов (каждая система в своем каталоге /oracle/<SID> и в своем owner-е ora<SID>). Также весьма удобно переносить такие независимые базы на новое железо или консолидировать базы. Удобно переименовывать системы, т.к достигается большая степень изоляции от других систем (баз). Если ошибешься при переименовании или restore датафайлов, то permissions не позволят повлиять на другие базы.

Также база устанавливается в едином пакете с приложением, обновление идет также отдельным wizard-ом. Зачастую вмешательства в структуру САПовских баз (к примеру создание своего ТБС) приводят к неподдерживаемой конфигурации и ошибкой в саповских br-тулзах. Удобство ораклового админа тут, получается, вещь второстепенная

Спасибо за ответ.
Еще хотел по поводу бекапов спросить, мы отказались от тулзов от САПА, и бекапим RMAN-ом, в чем могут быть проблемы?

Ivan KВиталий Перевозчиков,

Если верно настроить канал в файле init<SID>.sap, то BR-тулзы будут вызывать RMAN и могут бекапить базу на ленту.
Но в свое время я тоже отказался от BR-тулзов, т.к они не всегда дружили с Data Protector-ом, несмотря на то, что у DP есть интеграция с BR-tools (Не всегда цепляли правильную спецификацию, т.е формально запускался бекап базы, а бекапились только архив логи и наоборот)
Сейчас юзаем TSM, но все SAP-базы продолжают бекапиться RMAN-ом без SAP-овских утилит. В итоге BR-tools (как следствие и сам САП) об этом не знают. По факту все SAP-овские отчеты утверждают, что базы не бекапятся уже несколько лет, но на эти пункты забивается большой болт.
Насколько помню, ни разу в случае восстановлений(как плановых, так и после сбоев) я не пользовался ни BR-тулзами ни встроенными средствами DataProtector или TSM. Предпочитал командную строку RMAN.

Мы тоже отказались в пользу Networker. Тулзы насколько я помню еще табличные прострранства в read-only переводят при бекапе.