23 июля 2012 г.

Стандартные пользователи системы SAP

Как известно, после начальной установки любой SAP системы с ABAP-стэком мы имеем несколько стандартных мандантов:
  • 000 - эталонный мандант, "прародитель" рабочих мандантов системы; в данном манданте производятся работы по обновлению системы, настройке транспортной системы и так далее;
  • 001 - стандартный мандант, "прародитель" рабочих мандантов системы, в некоторых системах  (например, в SAP Solution Manager) может быть использован как рабочий мандант;
  • 066 - так называемый "Early Watch Client"; может быть использован службой поддержки компании SAP AG для доступа к системе клиента для анализа проблем, в частности с производительностью.
Вышеперечисленные манданты не рекомендуется изменять и, тем более, удалять.

В мандантах 000, 001 после установки системы есть 2 стандартных пользователя:
  • SAP* - используется при копировании мандантов, установки/продления лицензии (в случае ее скоропостижного окончания) и т.п.
    Раньше после установки пользователь имел начальный пароль: "06071992", который требовалось изменить в целях безопасности. В новых системах (SAP NetWeaver) во время инсталляции системы изменяется на пароль, указанный в качестве "Master Password":

    Экран установки SAP системы

    При удалении учетной записи остаётся псевдо-пользователь с начальным паролем "PASS", с помощью которого можно войти в систему. Подробности я описывал в посте: Как попасть туда, куда не пускают.

  • DDIC - используется при установке системы, обновлении, настройке и работе транспортной системы и других процессах.
    Блокировка/удаление ведет к останову многих процессов системы.
    Раньше после установки пользователь имел начальный пароль: "19920706", который требовалось изменить в целях безопасности. В новых системах (SAP NetWeaver) во время инсталляции системы изменяется на пароль, указанный в качестве "Master Password".
Иногда во время установки системы, основанной на SAP NetWeaver происходит сбой и, после вроде бы корректной установки, администратор не может войти в систему под стандартными пользователями с "Master Password".
В данном случае стоит попробовать старые стандартные пароли. Кстати, пароль - это дата выпуска первой SAP R/3 системы: 6 июля 1992 года.

Автор: Шиболов Вячеслав Анатольевич


20 июля 2012 г.

Вебинар про блейд-сервера Fujitsu

17 июля я присутствовал на вебинаре компании Fujitsu, посвященному линейки их блейд-серверов Fujitsu PRIMERGY BX.

Семейство Fujitsu PRIMERGY BX.
Линейка основана на процессорах Intel Xeon последнего поколения.

Данный семинар носит ознакомительный характер, технических нюансов не много, но для ознакомления с концепцией блейд-серверов (или их еще называют "лезвия") вебинар вполне подходит.

Прочитать про блейд-сервера можно кратко или подробно.

Презентация доступна тут.
Видео-запись вебинара выложил тут.

Для SAP систем недорогие блейд-сервера с типовой конфигурацией идеально подходят для серверов приложений.

Автор: Шиболов Вячеслав Анатольевич


17 июля 2012 г.

Резервное копирование SAP системы

Систему SAP можно представить в виде 3 компонент:
  • бинарное SAP ядро,
  • профили SAP системы и базы данных,
  • файлы базы данных, где располагается бизнес-логика, состоящая из ABAP-программ и настроек (записи настроечных таблиц), и данные-пользователей.
Все компоненты работают на сервере под управлением одной из операционных систем, поддерживаемой компанией SAP AG. Кроме перечисленного есть еще бинарные файлы СУБД (RDBMS), которые обеспечивают доступ к данным, хранящимся в базе данных и осуществляют функции синхронизации, консистентности данных и т.п.

Компоненты SAP системы.

По частоте изменения вышеуказанные компоненты делятся следующим образом:
  • бинарное ядро SAP системы обновляется только при обновлении SAP системы, в другое время в является неизменяемым набором данных,
  • профили системы и базы данных изменяются редко, только при изменении параметров SAP системы или базы данных,
  • база данных - наиболее динамично изменяющаяся часть системы.
Если не рассматривать уровень операционной системы, то для восстановления SAP системы в случае сбоя необходимо восстановление всех трех компонент. Это можно понять, если прочитать мой пост "Копирование SAP систем - I. Перенос/восстановление".

В зависимости от указанной выше частоты внесения изменений, можно выделить следующие шаги по резервному копированию системы:
  • сохранение текущей версии бинарного SAP ядра после каждого обновления системы (которое включает обновление SAP ядра),
  • сохранение файлов профилей SAP системы и базы данных после каждого изменения параметров системы. Профили SAP системы обычно загружаются в базу данных и изменяются через транзакцию RZ10. Поэтому копия их в базе данных существует. Но я рекомендую все таки делать копию отдельно. Можно просто в директорию на свою рабочую станцию. Благо файлы небольшого размера. 
  • сохранение файлов базы данных я рассмотрю более детально.
База данных ORACLE состоит из нескольких важных частей:
  • дата-файлы, в которых хранится вся информация. Располагаются в директориях /oracle/<SID>/sapdataX.
  • онлайн-журналы работы базы данных. 4 группы по 2 копии каждого журнала. Директории /oracle/<SID>/origlog<A,B> и /oracle/<SID>/mirrlog<A,B>.
  • оффлайн-журналы работы базы данных (если база данных работает в режиме ARCHIVE MODE). Директория /oracle/<SID>/oraarch.
  • control-файлы, в которых содержится вся информация о структуре инстанции базы данных. Обычно 3 копии, которые распределены по поддиректориям директории /oracle/<SID>.

Процедура восстановления базы данных, упрощенно, выглядит следующим образом:
  1. восстановление дата-файлов,
  2. восстановление control-файлов,
  3. применение оффлайн-журналов ORACLE (если необходимо).
Рекомендуемый компанией SAP AG цикл резервного копирования базы данных выглядит так:

Рекомендуемый цикл резервного копирования базы данных.

Цикл состоит из 28 дней.
Каждый день рекомендуется делать онлайн ("горячий") бэкап базы данных.
Каждый день необходимо делать две копии оффлайн-журналов ORACLE в разные директории/на разные ленты.
Раз в цикл необходимо делать хотя бы один оффлайн ("холодный") бэкап базы данных.
Раз в неделю обязательная логическая проверка базы данных и проверка одного созданного бэкапа на наличие ошибок чтения.

Для осуществления процедуры резервного копирования компания SAP поставляет набор утилит BR*TOOLs. В частности, brbackup - для резервного копирования дата-файлов, brarchive для копирования оффлайн-журналов ORACLE.
Конфигурационный файл данной утилиты - init<SID>.sap, который располагается в той же директории, что и профайлы ORACLE.

Можно использовать утилиту резервного копирования RMAN, которую предоставляет ORACLE. Или продукты сторонних производителей, например HP DataProtector.

Я всегда считал, что если есть возможно делать оффлайн бэкап базы данных каждый день, то почему бы не делать. И делал. Оффлай бэкап состоит из следующих шагов:
  1. Останов базы данных. Сервер приложений SAP продолжает работать, но рабочие процессы теряют соединение с shadow-процессами базы данных.
  2. Копия всех дата-файлов и control-файла.
  3. Запуск базы данных. Рабочие процессы SAP инстанции восстанавливают соединение до процессов базы данных.
Онлайн бэкап проходит несколько иначе:
  1. Первое табличное пространство переводится в специальный режим BEGIN BACKUP.
  2. Производится копирование дата-файлов первого табличного пространства.
  3. Первое табличное пространство переводится в нормальный режим работы.
  4. Шаги 1-3 повторяются для всех табличных пространств базы данных.
  5. Создается резервная копия оффлайн-журналов, которые были созданы во время процедуры онлайн бэкапа.
При создании онлайн резервной копии базы данных ORACLE пользователи могут работать с SAP системой, как обычно. При оффлайн - понятное дело, нет.

Но недавно я понял, что при создании оффлайн резервной копии базы данных происходит обнуление буферов ORACLE, так как база данных останавливается. И каждое утро, после ночной резервной копии происходит провал производительности системы до того момента, пока база данных не заполнит буферы данными. Чем больше инстанция и больше буферы, тем больше провал производительности, так как буферы базы данных играют существенную роль.

Исходя из этих рассуждений, мне кажется, что стоит следовать рекомендациям компании SAP AG и создавать ежедневные онлайн резервные копии. А оффлайн делать раз в неделю или реже (но минимум раз в цикл).

Подробности про резервное копирование можно найти в курсе SAP ADM505 - Database Administration (Oracle) - Unit 2.

Автор: Шиболов Вячеслав Анатольевич


12 июля 2012 г.

Новая версия miniSAP системы

Про предыдущую версию я писал в этом посте. Это была система на основе SAP NetWeaver 7.0.

Новая версия называется SAP NetWeaver AS ABAP 7.02 SP6 32-bit Trial. Также доступна версия 64 бита. По описанию кажется, что версия отличается лишь одной цифрой, да и та только во втором разряде после точки, но на деле все не так просто. Распространяемая версия представляет собой SAP EHP 2 for SAP NetWeaver 7.0 базируемый на новом SAP kernel 7.20 и использует базу данных MaxDB 7.8.01.018. В состав дистрибутива входит последняя версия SAP GUI 7.20.

Скачать можно на портале SAP Community Network: тут (регистрация бесплатная).

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

Требования к системе подросли:
  • Windows XP SP2, Windows Server 2003 или Windows Vista. Английская версия.
  • минимум 2 Гб ОЗУ (желательно 4-8 Гб),
  • файл подкачки минимум 6 Гб,
  • Intel Pentium III 1.1 GHz или выше,
  • 50 Гб на HDD (35 Гб занимает система с базой данных после установки),
  • отсутствие установленной SAP системы с SID = NSP и системным номером = 00.
Документацию по установке и использованию искать в start.htm.

9 июля 2012 г.

Fujitsu FlexFrame for SAP

В среду, 27 июня, я участвовал в вебинаре компании Fujitsu, посвященному продукту FlexFrame for SAP.
Основные особенности:
  • с аппаратной точки зрения основано на архитектуре x86, блейд-сервера типовой конфигурации, серьезный дисковый массив. Апгрейд заменой блейдов.
  • в качестве операционной системы используется Suse Linux, причем используется единый образ операционной системы, который производится совместными усилиями компаний Fujitsu и SAP в недрах Вальдорфа. Можно самому патчить образ, если есть желание.
  • с программной точки зрения это отказоустойчивый симметричный кластер.
  • есть веб-интерфейс для мониторинга всей системы.
Контрольная панель Fujitsu FlexFrame for SAP.

  • управление производится с помощью набора команд командной строки shell.
  • на всех серверах установлен FlexFrame agent, который отслеживает состояние не только серверов, но и компонент SAP WAS и базы данных. Причем агент обладает набор предустановленных правил для самостоятельной реакции на то или иное событие (например, перезапуск процесса ORACLE LISTENER в случае его сбоя). 
  • очень масштабируемая система, много вещей делается "из коробки" и с минимумом временных затрат и сил администратора.
Плюсы использования Fujitsu FlexFrame.

В целом, интересное решение. Выложил запись вебинара и презентацию.

Основная страница решения на сайте производителя - тут.

Автор: Шиболов Вячеслав Анатольевич


5 июля 2012 г.

Вышла новая версия SAP GUI 7.30. Первый взгляд

На днях компания SAP AG обновила релиз клиентского программного обеспечения, выпустив SAP GUI 7.30 for Windows. Установочный диск можно скачать на http://service.sap.com/installations.

Поддержка предыдущей версии SAP GUI 7.20 заканчивается 9 апреля 2013 года.
Новая версия будет поддерживаться до 15 июля 2015 года.

Процесс установки не отличается чем-то особенным. Запускаем PRES1\GUI\WINDOWS\WIN32\SetupAll.exe.

Рис. 1. Установка SAP GUI 7.30 - 1.

2 июля 2012 г.

Logical Volume Manager (LVM) своими руками. Часть III


Это пост является продолжением цикла про LVM (первая часть, вторая часть).

Команды для сбора информации о файловых системах, структуре LVM и т.п.:
  • # bdf - список монтированных файловых систем.
  • # ll /dev/*/group - клевая команда для просмотра контрольных файлов всех Volume Groups сервера. Бывает полезна при поиске свободного minor-номера для новой Volume Group.
  • # cat /etc/fstab - список всех файловых систем, которые монтируются при старте ОС,
  • # vgdisplay -v - информация о всех Volume Groups и 
  • # vgdisplay -v vg01 - о конкретной.
  • # lvdisplay -v /dev/vg01/lvol1 - информация о Logical Volume lvol1, можно попробовать общий случай:
  • # lvdisplay -v /dev/vg01/lv* - информация о всех Logical Volume из Volume Group vg01 (если при создании были паинькой и соблюдали соглашение об именовании: lv* для Logical Volume и vg* для Volume Group).
  • # pvdisplay -v /dev/dsk/c0t1d0 - информация о Physical Volume.
Расширение Volume Group (добавление диска), Logical Volume:
  1. # pvcreate -f /dev/rdsk/c0t2d0 - подготовить диск для подключения к LVM,
  2. # vgextend vg01 /dev/dsk/c0t2d0 - добавить в существующую Volume Group vg01 новый диск.
  3. # lvextend -L 48000 /dev/vg01/lvol1 - расширить Logical Volume lvol1 до размера 48000 МБ.
  4. Расширить файловую систему на lvol1 (до этой операции, хоть диск (Logical Volume) и стал больше, но файловая система не сможет его использовать):
    - # umount /data - отмонтировать файловую систему,
    - # extendfs -F vxfs /dev/vg01/rlvol1 - расширить файловую систему на все свободное место,
    - # mount /data - монтировать расширенную файловую систему,
    - # bdf - проверить новый размер.
Уменьшение файловой системы и Logical Volume делается очень редко, так как перед этим необходимо удалить данные, сделав резервную копию, а после уменьшить файловую систему и Logical Volume командами newfs и lvreduce.

Ломать, не строить. Команды удаления Logical Volume:
  1. # umount /data - отмонтировать файловую систему,
  2. # lvremove -f /dev/vg01/lvol1 - удалить Logical Volume с опцией "force" (не смотря на наличие файловой системы и данных),
  3. # vi /etc/fstab - отредактировать список монтируемых файловых систем при старте ОС,
  4. # vgdisplay -v vg01 - проверить отсутствие Logical Volume.
Удаление физического диска из Volume Group:
  1. # pvmove /dev/dsk/c0t1d0 /dev/dsk/c0t2d0 - переместить данные с диска c0t1d0 на другой диск из Volume Group (если не указывать второй диск, то команда сама разместит на оставшиеся диски в Volume Group, конечно, при наличии места на них),
  2. # pvdisplay -v /dev/dsk/c0t1d0 - проверка того, что на диске нет данных (ни одного физического экстента - PE),
  3. # vgreduce vg01 /dev/dsk/c0t1d0 - удалить диск из Volume Group vg01,
  4. # vgdisplay -v vg01 - проверить изменения.

Удаление Volume Group:
  1. # lvremove -f /dev/vg01/lvol1 - удалить все Logical Volumes,
  2. # vgreduce vg01 /dev/dsk/c0t1d0 - удалить все диски, кроме одного,
  3. # vgremove vg01 - удалить Volume Group vg01,
  4. # rm -ir /dev/vg01 - удалить директорию vg01.
Можно удалить проще: одной командой
- # vgexport /dev/vg01 - удалит всё, ни о чем не спрашивая. :)

Активация/деактивация Volume Group:
  • # vgchange -a n vg01 - деактивирует Volume Group vg01, удаляя ее из LVM-таблицы ядра системы,
  • # vgchange -a y vg01 - активирует Volume Group vg01, делая возможным монтирование файловых систем из нее (автоматическая активация проводится при старте ОС),
  • # vgchange -a r vg01 - активация Volume Group vg01 в режиме "только для чтения".
Последовательности команд верны для файловых систем HFS, JFS. Есть дополнительная опция, которую можно приобрести у HP - Online JFS. Там есть "вкусные вещи", типа уменьшения/увеличения файловой системы без отмонтирования и т.п. Основная команда - fsadm.

Очень скучные посты получаются. :) Остался в плане еще один на эту тему.

Автор: Шиболов Вячеслав Анатольевич