LVM в операционной системе Linux

В своём блоге несколько лет назад я делал памятку по системе Logical Volume Management (LVM) в операционной системе HP-UX. Четыре части статьи можно найти по тегу LVM.

К счастью, LVM в Linux очень похож на LVM в HP-UX (рис. 1).

Рис. 1. Концепция LVM в Linux.

Все понятия идентичны. На физических дисках или разделах дисков создаются физические тома (Physical Volumes). Эти тома объединяются в группы томов (Volume Groups). Один физический том может принадлежать только одной группе томов. Внутри группы томов пространство разбивается на логические тома (Logical Volumes). Соответствие между логическими и физическими томами происходит через единицу выделения пространства - Physical Extent, который равен по размеру Logical Extent. Карта распределения и соответствия LE и PE произвольная. Размер PE определяется в момент создания Volume Group и фиксирован во всё время существования группы (по-умолчанию, 4 Мб). Внутри логического тома можно создать файловую систему и смонтировать её в дереве общей файловой системы Linux.

Краткая последовательность создания:

1. Для создания разделов можно использовать команды gdisk (GPT формат) или fdisk (MBR формат). При создании раздела указать тип LVM (код 8E или 8E00).
2. На разделах создать физические тома (Physical Volumes) командой вида:
    # pvcreate /dev/sdaX /dev/sdbY 
3. Создать группу томов (Volume Group) командой вида:
    # vgcreate -s размер_PE VGname /dev/sdaX /dev/sdbY 
4. Создать необходимое количество логических томов (Logical Volumes) командами вида:
    # lvcreate -l/-L размер -n LVname VGname 
5. Активировать группу томов командой вида:
    # vgchange -a y VGname 
   или
    # lvm vgchange -a y VGname 
6. Создать файловые системы и смонтировать их, например командами:
    # mkfs -t xfs /dev/VGname/LVname
    # mount /dev/VGname/LVname /mount/XXX 

Если необходимо расширить файловую систему, то последовательность следующая:

1. Расширить группу томов, создав и добавив физический том, если это необходимо:
    # pvcreate /dev/sdbZ
    # vgextend VGname /dev/sdbZ 
2. Расширить логический том и файловую систему командами вида:
    # lvextend -L размер /dev/VGname/LVname
    # resize2fs /dev/VGname/LVname 

Можно сместить Physical Extents одного физического тома на другой (sdaX -> sdcZ). Например, для вывода его из состава группы томов. Использовать команду вида:

 # pvmove /dev/sdaX /dev/sdcZ 

Второй аргумент можно не указывать, тогда команда "разбросает" PE на то свободное место, которое есть в группе томов.

В Linux есть дополнительные команды просмотра информации по LVM:

 # pvs 

 # vgs 

 # lvs 

Они отображают информацию по всем физическим томам, группам томов и логическим томам в системе, соответственно (рис. 2).

Рис. 2. Пример вывода информации по LVM разделам в системе.

Есть возможно указать конкретные поля, которые необходимо вывести, например:
 # lvs -o lv_name,lv_size,device 
Информация по всем столбцам по команде вида:
 # lvs -o help 

Есть у LVM в Linux расширенные возможности:

1. Создание snapshots, которые очень полезны при резервировании файловой системы с гарантией от изменений во время процесса. Смотрите справку на опцию -s команды lvcreate.
2. Поддержка программного RAID 0/1/5/6/10.
3. Создание кэш разделов на основе, например, SSD, для медленных и больших разделов.
4. Поддержка кластерных конфигураций.

Есть команды vgexport/vgimport, которые позволяют переносить группы томов с одного сервера на другой или при настройке кластерной конфигурации.

В отличии от HP-UX, в Linux LVM реализуется через Device Mapper, который генерирует реальные имена устройств вида /dev/dm-X. А файлы вида /dev/VGname/LVname по сути являются символьными линками на эти файлы. Но рекомендуется работать именно с линками, так как Device Mapper не гарантирует соответствие файлов устройств /dev/dm-X самим устройствам после перезагрузки.

Не воспрещается использовать графические утилиты для конфигурации LVM. Хотя по мне, это не так изящно. В SLES это yast2 (модуль disk или Partitioner) (рис. 3), в RHEL - gnome-disk-utility.

Рис. 3. Раздел Partitioner утилиты Yast.

Дополнительно можно почитать хорошую Wiki-статью по LVM.

P.S. Поздравляю всех причастных с прошедшим днём системного администратора или просто сисадмина! :)


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

Опрос: версии SAP ERP

Кто бы что не говорил, а система SAP ERP это ключевая разработка компании SAP и ядро всей инфраструктуры предприятия. Поэтому давайте проведем опрос: какие версии SAP ERP систем у вас работают?

Укажите все версии этой системы, которые так или иначе у вас работают: тестовые, разработки, архивные, продуктивные, IDES, "песочницы". Не стоит указывать системы, которые вы поставили только для себя и где никто не работает. :)

Про версии SAP системы можно посмотреть этот пост.

Если у вас старая система, то стесняться не стоит. Я знаю много компаний, у которых есть старые версии систем. Хотелось бы через вас увидеть общую картину.

Опрос завершён. Всем спасибо за участие.

В опросе учтены голоса 52 человек. Результаты на рис. 1.

Рис. 1. Результаты опроса.

В лидеры вырывается версия системы SAP ERP 6.0 EHP7. А последний Enhancement Package (8) для этой системы еще пока не так популярен. Скорее всего в силу даты выхода.

SAP S/4 HANA пока тоже не так популярна у нас в стране: 12 % или 10 инсталляций. Причем, только 2 инсталляции отдельные. В остальных случаях, они как часть зоопарка других версий систем.

На удивление, много еще старых, не поддерживаемых компанией SAP, версий. В данном случае, это SAP R/3 версий 4.0 и 4.6C, SAP R/3 4.7 и SAP ERP 2004. Всего таких систем 16 или 19 %.

Распределение участников по странам и городам России представлено на рис. 2 и 3.

Рис. 2. Распределение участников опроса по странам.

Рис. 3. Распределение участников опроса из России по городам. 

Есть вероятность, что участники из США и Норвегии являются клиентами VPN-анонимайзеров, но может быть кто-то и оттуда читает мой блог. :)


P.S. Поменял сервис опросов с simpoll.ru на pollservice.ru. Первый ограничил количество бесплатных опросов до 3-х. Посмотрим, как отработает этот.

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

Обновление SAP GUI for Windows и SAP GUI for Java

Для системы SAP есть два типа клиентских места:

• SAP GUI for Windows - набор программного обеспечения, устанавливаемого на операционные системы семейства Microsoft Windows,
• SAP GUI for Java - набор программного обеспечения, который работает на виртуальной машине Java. В следствии этого он является платформо-независимым и может быть установлен в операционные системы Windows, Linux или macOS (она же Mac OS X или OS X).

Как я недавно писал, SAP на данный момент поддерживает 2 версии клиентского места SAP GUI for Windows - 7.40 и 7.50. Версия SAP GUI for Java, рекомендуемая к установке, - 7.40. Про эту версию можно почитать посты: общий и про установку на Mac OS X.

Текущую версию SAP GUI for Windows можно посмотреть, нажав в окне SAP Logon левой клавишей мыши в левый верхний угол  и выбрав пункт "Информация о SAP Logon..." (рис. 1 и 2).  

Рис. 1. Просмотр версии SAP GUI for Windows.

Рис. 2. Информация о версии SAP GUI for Windows.

Для SAP GUI for Windows ещё есть возможность определения версии без запуска SAP GUI через утилиту sapver или VB скрипты (рис. 3 и 4). Возможен запуск в интерактивном режиме или из командной строки. Таким способом можно определить версии SAP GUI на рабочих станциях пользователей в автоматическом режиме. Утилиты и подробности можно найти в SAP note # 526199 - Determining installed front-end version with command line.

Рис. 3. Пример вывода утилиты sapver.

Рис. 4. Пример использования VB скриптов для определения версии SAP GUI.

Информация о версии SAP GUI for Java доступна через пункт меню "Справка -> О SAP GUI" (рис. 5 и 6).

Рис. 5. Просмотр версии SAP GUI for Java.

Рис. 6. Версия SAP GUI for Java.

Обе версии, и для Windows, и для Java, необходимо периодически обновлять. И тут есть небольшое отличие: для SAP GUI for Windows выпускаются пакеты поддержки или патчи, а для SAP GUI for Java есть такое понятие как исправление (revision). В первом случае это отдельный, небольшой, относительно основного пакета ПО, бинарный файл, который устанавливается поверх уже установленной основной версии SAP GUI. Все патчи кумулятивные, то есть устанавливать надо только целевой или последний, он содержит все предыдущие исправления. Процесс установки пакета поддержки идентичен процессу установки основной версии SAP GUI for Windows. Есть еще hotfix - это дополнительные пакеты поддержки, которые выходят между основными и содержат критические исправления для конкретного пакета поддержки. Про них я писал тут. Историю и график выхода новых патчей для поддерживаемых на данный момент версий можно найти в SAP note # 1053737 - Expected release dates for SAP GUI for Windows.

Что же касается SAP GUI for Java, то тут обновления это полностью собранное клиентское место новой версии или revision. Устанавливать его можно на компьютер без установленного клиентского места. Историю и график выхода новых версий обновлений можно найти в SAP note # 1229666 - Expected release dates for SAP GUI for Java revisions.

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

Как стать SAP BASIS администратором

Кто такой SAP Basis администратор? Это специалист, который отвечает за техническую часть SAP системы. От него зависит, чтобы система работала. Пользователи должны подключаться к системе и получать результат, заданный при проектировании системы. Например, если задача системы получать вводимые от пользователя данные и выдавать сводный отчет, то данные должны сохраняться, а отчеты их отображать. Чтобы поддерживать систему, необходимо обладать знаниями об её архитектуре. Для контроля работы необходим мониторинг работы. Безопасность на уровне системы и пользователей, а также система резервного копирования помогают сохранить функционирование системы. Инструменты для мониторинга и настройки производительности позволяют настроить не просто работающую систему, а систему удовлетворяющую по времени реакции и скорости выполнения операций техническому проекту и ожиданиям пользователей. Умение разворачивать и обновлять системы тоже нужный навык.

Общая картина необходимых навыков выглядит так (нажмите на картинку для увеличения).

На верхнем уровне все навыки делятся на 3 большие части (подробности по ссылкам на каждом из навыков):

• аппаратное обеспечение и операционные системы,
• базы данных,
• SAP NetWeaver.

Схему можно распечатать (на А4 получается читабельно) и повесить на стенку. :)

Так же рекомендую пост "Азы администрирования: с чего начать", а для получения практических навыков - программу обучения SAP Basis.


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

Учебный курс в HPE: H7091S - Enterprise Linux Systems Administration

С 26 по 30 июня в учебном центре Hewlett-Packard Enterprise я прослушал курс по администрированию корпоративных Linux систем. Полное название курса - H7091S - Enterprise Linux Systems Administration (код GL250).

Последний раз на обучении в HP я был в 2004 году. Тогда офис компании располагался рядом с московским офисом SAP - на Космодамианской набережной. Сейчас они уже давно базируются рядом с метро Войковская, в бизнес-центре "Метрополис".

Учебный центр соответствует всем стандартам. :) Чай, кофе, молоко, вода. Удивило большое количество травяных видов чая: чабрец, мята, ромашка, шиповник. Можно было заварить с мёдом, который был там же. Кофе, чего я еще не видел, варят бесплатные автоматы (рис. 1).

Рис. 1. Меню кофейного автомата.

Жалею, что не попробовал, что скрывается за надписью кисель. :) В далекие 2000-е еще были печеньки в неограниченном доступе, но сейчас времена другие. На обеды выдают продуктовую валюту в размере 300 рублей/сутки. Принимают её в нескольких кафе вокруг бизнес-центра (рис. 2).

Рис. 2. Продуктовые карточки в учебном центре HPE.

Курс читал Прилипко Георгий Алексеевич. В 2003 году я у него слушал курс по LVM, MirrorDisk и файловой системе JFS (код H6285S). На сколько я понял, преподавательский состав - это давно сформировавшаяся команда "зубров", стойко читающая курсы уже много лет. Очень приятно было встретить в учебном центре Максима Мошкова. Я считаю его лучшим преподавателем, которого я когда либо видел. Он сейчас читает курсы по VMware. Максим уже не так молод, как был в 2003 году, когда я слушал у него курс по MC/ServiceGuard, да и я уже изменился. :) (рис. 3). Если кто не узнал, то на фото Максим с бородой, а я крайний слева.

Рис. 3. Курс в HP в 2003 году.

Георгий Алексеевич же совсем не изменился, такой же хитрый прищур, много шуток и баек. Я считаю его преподавателем на твердую четвёрку. Отличительная его черта это большой опыт и любовь к Unix. Но в этом курсе не хватало глубины и охвата материала. Местами пробегали очень быстро, получая только список команд и конфигурационных файлов, а душа просила полной картины с архитектурой и идеологией. В оправдание можно заметить, что советов и интересных решений тоже было достаточно.

Очень понравились материалы курса. Курс посвящен администрированию корпоративных Linux систем, а это Red Hat Enterprise Linux и SUSE Linux Enterprise Server. Версии в курсе рассматривались последние: 7-я для RHEL и 12-я для SLES. Материал построен так, что освещает и общие моменты, и нюансы обеих систем. В качестве тренировочной системы была развернута CentOS, которая фактически является бесплатным клоном RHEL. К клону RHEL, кстати, можно отнести и Oracle Linux, который поддерживается для установки систем SAP. Получаем полный охват всех Linux систем, которые нужны администратору SAP систем. Практические задания отличные, широкие возможности делать с системой всё что хочется. :) Дистрибутив, кстати, тоже можно было поменять и спокойно делать лабораторные задания, для SLES они тоже были описаны.

Кроме официальных материалов Георгий Алексеевич раздал всем слушателям копии своих собственных заметок по Unix/RHEL на 24-х страницах.

Некоторые комментарии, мысли и советы от Георгия Алексеевича (через мои заметки).

Если говорить о выборе дистрибутива, то SUSE Linux ближе к классическому Unix, чем Red Hat. Так же он более "дружелюбен" к системному администратору.

Unix, в отличии от Windows, познаваемый. Потому что база одна для разных дистрибутивов и остается от версии к версии.

Была система MULTICS, написали UNICS, которая была не для больших машин. "CS" - Computer Systems. Потом превратилась в UNIX.

Задача системного администратора - минимизировать действия администратора для обеспечения работоспособности системы.

Команды помогающие определить местоположение на машине:
# pwd
# id
# tty
# uname -a
# echo $DISPLAY

Как посмотреть релиз Linux:
# grep -i linux /etc/*-release

Рекомендации:

• при установке чего-либо по инструкции ставить галочки напротив выполненных пунктов.
• использовать sudo -i вместо su - , потому что sudo сохраняет все действия в журналы.
• символьные линки надо делать относительными, а не абсолютными от корня, чтобы они работали при смене корня, например, по NFS.
• создать alias "rm = rm -i" для борьбы от случайного удаления содержимого всей файловой системы.
• логи надо чистить командой # > file, так как эта команда просто перемещает указатель на начало файла, иначе можно не угадать с полномочиями на файл и, память не освободится пока процесс не закончит писать в файл.
• при использовании GRUB2 - ставить пароль на изменения GRUB, иначе можно попасть в систему без пароля root.
• для проверки файлов password+shadow использовать # pwck, group+gshadow - # grpck.
• файл /etc/shells содержит все shell скрипты, которые могут быть присвоены пользователю.
• # type <cmd_name> - показывает cmd_name это alias или команда.
• # find / -perm -4000 -ls -- поиск файлов с битом "s" на полномочиях.
• # find -type l  -- поиск символьных линков.
• # grep -v -e "^$" -e "^#" -- показывает из текстового файла непустые строки и не строки комментариев.
• # tail -f file&  -- можно запустить отображение нескольких журналов по мере поступления сообщений в одном терминале.

Менеджер устройств udev имеет правила в /etc/udev/ и /usr/lib/udev/. Поиск начинается с /etc/,

а в /usr/lib/ попадают правила из пакетов. Поэтому редактировать правила надо в /etc/dev/. Чтобы отменить правило, нужно создать пустое правило в /etc/dev/.

Создание копий /etc/ и /dev/:
# cd /
# find etc dev | cpio -pmvdn /s

У каждого файла свой inode, который уникален внутри файловой системы. Директория это файл со списком имен и inodes.

# lsmod - список подключаемых модулей ядра Linux.

NVidia поддерживается лучше, чем ATI/AMD. Тут не уверен, что информация не устарела. :)

Чтобы отправить команду в фон: Ctrl + Z и # BG %1
команда # jobs - список работающих фоновых заданий.

# yum clean all - приводит в порядок базу RPM, чистит временные каталоги в /var/, которые использует RPM/YUM.

Файл /proc/partitions - это то, что видит ядро.

# unidgen -- генератор уникальных номеров.

Если fsck не проходит, то можно попробовать примонтировать только на чтение командой вида # mount -o ro

5% в файловой системе резервируется для процессов root, чтобы он мог писать даже, если avail = 0%.

При монтировании по NFS, по-умолчанию, root становится nfsnobody (Red Hat) или nobody (SLES).

В целом, я получил от курса, что планировал: нюансы администрирования RHEL и SLES, в отличии от HP-UX, который я активно изучал, но который похоже становится историей. К тому же, цена, в отличии от курсов компании SAP, очень демократичная.

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

Как настроить резервное копирование базы данных на магнитную ленту

В 2012 году я опубликовал пост "Резервное копирование SAP системы", в котором я представил SAP систему в виде трех компонент (рис. 1):

• бинарное SAP ядро,
• профили SAP системы и базы данных,
• файлы базы данных.

Рис. 1. Технические компоненты SAP системы.

Все компоненты важны для работы системы, а в случае сбоя необходимо их восстановление. Из всех трёх самой главной частью является база данных, в которой SAP сконцентрировал все данные, какие было возможно: данные системы, настройки, учетные записи пользователей, ABAP-программы и т.д. Остальные компоненты можно заменить: бинарное ядро скачать с сайта поддержки, профайлы восстановить, скопировав с соседней системы и внеся поправки. База данных же индивидуальна и хранится только у вас.

SAP система предоставляет набор утилит для администрирования базы данных. Этот набор утилит называется BR*Tools (ранее SAPDBA) (статьи на эту тему: часть 1, часть 2). Помимо прочего в набор входят 2 утилиты для создания резервных копий: brbackup и brarchive. Как можно догадаться из имен утилит, первая предназначена для резервирования файлов базы данных, а вторая для журнальных файлов Oracle (про журнальные файлы я писал тут и тут).

Файл настройки утилит администрирования базы данных с именем init<SID>.sap находится в директории /oracle/<SID>/<DB_vers>/dbs/ (для ОС Unix) и /oracle/<SID>/<DB_vers>/database/ (для ОС MS Windows).

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

Обычно ленты используются в виде пула (набора лент), отдельно для файлов данных, отдельно для оффлайн журналов Oracle. Чтобы работать с магнитными лентами, операционная система должна видеть ваши устройства для чтения/записи на ленты.

В файле настройки утилит базы данных от SAP важны следующие строки:

backup_mode = all  
# Описывает какие компоненты базы данных добавлять в резервную копию.

backup_type = offline 
# Как выполнять резервную копию: с остановом базы данных (offline) или нет (online). Подробности тут.

backup_dev_type = tape
# Указывается тип устройства для резервных копий, в данном случае, это лента.

compress = no
# Сжимать резервированные данные (yes) или нет (no), можно использовать аппаратное сжатие самой ленточной библиотеки (hardware) или утилиту brtools (brtools).

tape_copy_cmd = dd
# Какую команду использовать для копирования (cpio, cpio_gnu) или (dd, dd_gnu). Я предпочитаю dd.

cpio_flags = -ovB
cpio_in_flags = -iuvB
# Ключи для команды cpio, важны, если указана именно она в предыдущем параметре.

dd_flags = "obs=64k bs=64k"
dd_in_flags = "ibs=64k bs=64k"
# Входные и выходные ключи для команды dd. Отличаются для Windows и Unix. Про их настройку я писал тут.

tape_size = 100G
# Размер ленты. Если не угадать, то ленты будет не хватать, а процесс создания резервной копии будет прерываться. Рекомендуется указывать на 5-10 % меньше, чем есть на самом деле. Критичен для команды dd, которая не проверяет конец ленты. cpio отрабатывает событие 'конец ленты' корректнее.

tape_address = /dev/rmt/0mn
tape_address_rew = /dev/rmt/0m
# Имена устройств для ленточного устройства для утилиты brbackup. Зависит от ОС. Первый файл без автоматической перемотки после команды записи/чтения, второй с автоматической перемоткой ленты.

tape_address_arch = /dev/rmt/1mn
tape_address_rew_arch = /dev/rmt/1m
# Имена устройств для ленточного устройства для утилиты brarchive. Зависит от ОС. Первый файл без автоматической перемотки после команды записи/чтения, второй с автоматической перемоткой ленты. Используются, если используется ленточное устройство отличное от того, что для brbackup.

volume_archive = (EI7A01, EI7A02, EI7A03, EI7A04, EI7A05,
                  EI7A06, EI7A07, EI7A08, EI7A09, EI7A10,
                  EI7A11, EI7A12, EI7A13, EI7A14, EI7A15,
                  EI7A16, EI7A17, EI7A18, EI7A19, EI7A20,
                  EI7A21, EI7A22, EI7A23, EI7A24, EI7A25,
                  EI7A26, EI7A27, EI7A28, EI7A29, EI7A30)
# Указывается список заголовков лент, которые будут использоваться для созданий копий журналов Oracle посредством утилиты brarchive. Заголовок состоит из '<SID>' системы, буквы 'A' от слова archive и номера. Количество зависит от цикла бэкапа и количества лент в наличии. Ленты используются по кругу. Если указать вместо списка 'SCRATCH', то при копировании заголовок ленты будет игнорироваться.

volume_backup = (EI7B01, EI7B02, EI7B03, EI7B04, EI7B05,
                 EI7B06, EI7B07, EI7B08, EI7B09, EI7B10,
                 EI7B11, EI7B12, EI7B13, EI7B14, EI7B15,
                 EI7B16, EI7B17, EI7B18, EI7B19, EI7B20,
                 EI7B21, EI7B22, EI7B23, EI7B24, EI7B25,
                 EI7B26, EI7B27, EI7B28, EI7B29, EI7B30)
# Указывается список заголовков лент, которые будут использоваться для созданий копий файлов базы данных посредством утилиты brbackup. Заголовок состоит из '<SID>' системы, буквы 'B' от слова backup и номера. Количество зависит от цикла бэкапа и количества лент в наличии.  Ленты используются по кругу. Если указать вместо списка 'SCRATCH', то при копировании заголовок ленты будет игнорироваться.

expir_period = 30
# Указывается период в днях, в течении которого нельзя использовать ленту. Цифру необходимо согласовывать с количеством лент и частотой выполнения резервирования. Используется для исключения случайной перезаписи ленты с резервной копией.

tape_use_count = 100
# Счётчик, указывающий сколько раз можно использовать ленту для резервного копирования. После достижения этой цифры, утилита попросит заменить ленту. Нужен для исключения ситуации внезапного износа ленты и сбоя при восстановлении из резервной копии.


После внесения информации в файл настройки, необходимо подготовить магнитные ленты.
Чтобы записать заголовок на ленту необходимо на уровне ОС из под пользователя <sid>adm выполнить команду вида:

> brbackup -i force -v <tape_name> 
> brarchive -i force -v <tape_name> 

Первая команда для записи заголовка типа '<SID>B<XX>', вторая  - '<SID>A<XX>'. Заголовок пишется в файл (.tape.hdr0), который хранится в начале магнитной ленты. В него записывается заголовок ленты, дата последней записи резервной копии на эту ленту и счетчик использования.

Посмотреть эту информацию можно, использовав команды:

> brbackup -i show  
> brarchive -i show  

Запустить резервное копирование можно напрямую через команды на уровне ОС: brbackup, brarchive или утилиту brtools, либо выполнить разовое или периодическое планирование в транзакции DB13.

Дополнительно на тему можно почитать следующие посты:

- про блокировки, возникающие во время резервирования утилитами brbackup и brarchive,

- про файлы устройств в отказоустойчивом кластере.

В данном посте я описал минимальную настройку, необходимую для создания резервных копий базы данных на магнитную ленту средствами SAP. Можно настроить систему резервного копирования дальше. Использовать RMAN, например. А можно использовать сторонние утилиты, такие как HP Data Protector.


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

Использование транзакции SE03 для поиска объектов в запросах

В посте "Запись каталога объекта: изменение системы оригинала" я уже писал про транзакцию SE03 и как, используя её, поменять систему оригинала для объекта ABAP словаря системы.

У этой транзакции есть еще несколько полезных функций. Рассмотрим функции по работе с объектами в транспортных запросах.

В посте "Как перенести содержимое таблицы" я описывал процесс включения объекта словаря в транспортный запрос. В данном случае это было описание структуры таблицы. Запросы на перенос или транспортные запросы хранят те или иные объекты ABAP словаря. До деблокирования (release) запроса в нём хранятся лишь ссылки на объекты, а реальная информация выгружается в файлы запроса только во время процесса деблокирования. Как вы помните, после деблокирования транспортного запроса в файловой системе сервера приложений формируется 2 файла с номером запроса.

Итак, чтобы найти объект, который был включен в транспортный запрос, необходимо войти в транзакцию SE03, выбрать в древовидном меню пункт "Поиск объектов в запросах/задачах" и нажать на панели кнопку "Выполнить" или клавишу F8 на клавиатуре (рис. 1).

Рис. 1. Поиск объектов в запросах/задачах.

На экране выбора необходимо указать объект, который мы ищем, и, при желании, дополнительные фильтры: диапазон номеров запросов/задач, владельца запроса, период времени, который нам интересен и статус запроса (деблокирован или нет). Например, мы хотим найти все запросы, в которых содержится программа Z_DELETE_FROM_DEVACCESS (рис. 2).

Рис. 2. Поиск запросов, содержащих программу Z_DELETE_FROM_DEVACCESS.

После установки фильтров и нажатии на панели кнопки "Выполнить" на экране отобразятся запросы, удовлетворяющие фильтрам. В данном случае, это те, которые содержат программу Z_DELETE_FROM_DEVACCESS (рис. 3).

Рис. 3. Запросы, содержащие программу Z_DELETE_FROM_DEVACCESS.

У запроса можно посмотреть заголовок, в котором есть, например, дата деблокирования (рис. 4), журналы экспорта и импорта (рис. 5), в которых указано когда запрос деблокировали, были ли ошибки, в какую систему и когда импортировали и т.д.

Рис. 4. Заголовок запроса.

Рис. 5. Журнал экспорта и импорта запроса.

Нажав дважды на номер запроса, можно посмотреть, полное содержимое запроса (рис. 6).

Рис. 6. Содержимое запроса.

Таким образом, можно найти все запросы, содержащие искомые объекты.

Также данный раздел транзакции SE03 позволяет анализировать объекты в запросах. Для этого необходимо в древовидном меню выбрать пункт "Анализ объектов в запросах/задачах" и нажать на панели кнопку "Выполнить" или клавишу F8 на клавиатуре (рис. 7).

Рис. 7. Анализ объектов в запросах.

На следующем экране указываем номер запроса и система выдает экран с объектами, содержащимися в запросе (рис. 8).

Рис. 8. Анализ объектов в запросе.

На данном экране можно посмотреть следующую информацию:

• список всех объектов запроса,
• записи каталогов объектов,
• класс разработки, систему оригинала, уровень переносов в транспортной системе и целевую систему,
• зависит ли объект от манданта системы и блокирован ли он в данный момент,
• атрибуты объекта на одном экране, нажав соответствующую кнопку на панели (рис. 9).

Рис. 9. Атрибуты программы Z_DELETE_FROM_DEVACCESS.

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

Как узнать кто импортировал транспортный запрос

Если в SAP системе настроен ручной импорт транспортных запросов на изменения, то импорт (или перенос) запросов осуществляется вручную в транзакции STMS. При "доверительных" отношениях внутри группы внедрения запросы на изменения, например, в тестовую систему могут переносить многие члены проектной группы. Чтобы выяснить кто случайно или не случайно выполнил импорт/перенос нужно сделать следующее.

Войти в транзакцию STMS и выбрать очередь необходимой системы. В меню выбрать пункт "Перейти к -> Импорт: история" (рис. 1).

Рис. 1. Переход в историю импорта.

По-умолчанию, окно истории выглядит так, как это показано на рис. 2. Можно задать фильтры по дате/времени, владельцу или номеру запроса.

Рис. 2. История импорта в систему.

В столбце "Владелец" указано имя пользователя, который создал данный запрос на изменения, но это не означает, что именно он импортировал его в систему.

Чтобы посмотреть кто перенёс запрос, необходимо выбрать пункт меню "Обработать -> Показать больше" (рис. 3).

Рис. 3. Отображение больше информации в истории импорта.

После этого на экране истории импорта появится поле "Пользователь", в котором отображено имя пользователя, который запустил импорт запроса в систему (рис. 4).

Рис. 4. Отображение пользователя, который импортировал запрос в систему.

Таким образом, можно выяснить кто и в какое время импортировал транспортный запрос.


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

Навыки SAP BASIS администратора - IV

Этой серией статей (первая часть, вторая часть, третья часть) я делаю попытку классифицировать и систематизировать навыки, необходимые SAP BASIS специалисту. 

Все навыки изначально были разделены на 3 крупные группы:

• аппаратное обеспечение и операционные системы,
• базы данных,
• SAP NetWeaver.

Пришло время рассмотреть основную и самую большую группу навыков - "SAP NetWeaver". 

В идеале, если в компании где вы занимаете должность специалиста или эксперта по администрированию систем SAP, выделены отдельные специалисты по администрированию уровней аппаратного обеспечения, операционных систем и баз данных, вы концентрируете свои усилия только на этой группе знаний и навыков. В "не идеале", всё равно эта часть должна занимать 60-70 % ваших знаний.

Как я уже писал в первой части статьи, в данной группе я выделил 4 подгруппы:

• SAP Solutions,
• AS ABAP,
• AS Java,
• SAP Frontend.

Под SAP Solutions я понимаю следующие навыки:

1. Знания о том, какие решения-системы (SAP BI, SAP ERP, SAP MDM и т.д.) SAP предлагает на рынке. Важны знания по архитектуре решений и последовательность их установки-разворачивания, примерные аппаратные ресурсы для установки и т.п.
2. Навыки работы с SAP Support Portal. Прежде всего это поиск и применение к системе SAP notes, поиск и работа с документацией (SAP Help Portal, документация по установке и настройке систем и решений), инициирование диалога (messages) со службой поддержки SAP, поиск и скачивание дистрибутивов и обновлений для продуктов SAP, работа с таблицей PAM и т.п. На моём блоге статьи на эту тему можно найти, например, по данному тегу. 
3. Отдельно выделю навыки необходимые для работы с системой SAP Solution Manager. Конечно, по этой системе на рынке есть отдельные специалисты, но эта система все таки ближе к администраторам SAP систем, чем SRM или CRM, например. Поэтому навыки по установке/настройки сценариев для администрирования систем нужны. По Solution Manager есть SAP семинар - "SM100 - SAP управление решением. Конфигурация для операций" или книги издательства SAP PRESS.

Все виды клиентских мест выделены в группу "SAP Frontend":

1. SAP GUI for Windows или for Java. Навыки по установке, конфигурации, обновлению, централизации управления и решению проблем.
2. Работа через тонкого клиента - настройка ITS, решение проблем, вопросы производительности.
3. Можно еще отдельно выделить всё возрастающий набор специализированных клиентских мест. Например, таких как SAP Business Explorer (BEx) или SAP Business Client. Но знание по ним стоит изучать только при прямой работе с ними.

Тут тоже можно покопаться в моем блоге: например, про SAP GUI for Windows - ссылка 1, ссылка 2, ссылка 3 или поиск по тегу. Про SAP GUI for Java - общая статья, установка на Mac OS. Про активацию ITS.

Администрирование сервера приложений SAP можно разделить на две большие части:

• AS ABAP или сервер приложений ABAP,
• AS Java - сервер приложений Java.

По AS ABAP для ориентира я выделил следующие знания и навыки:

• архитектура сервера приложений AS ABAP,
• установка, а как более глубокий навык - копирование и миграция SAP систем,
• запуск/останов AS ABAP,
• навыки конфигурации сервера приложений,
• мониторинг и решение проблем,
• вопросы безопасности. Здесь же администрирование пользователей, роли/полномочия, центральное ведение пользователей (CUA),
• обновление системы: установка SAP нот, пакетов поддержки, стеков (SPS), EHP и обновление версии SAP системы,
• создание резервных копий и восстановление в случае сбоев,
• вопросы производительности,
• система управления изменениями или транспортная система (TMS): настройка системы, управление запросами на перенос, управление мандантами системы (создание их и копирование тоже здесь),
• вопросы интеграции, например, знание механизмов RFC,
• печать из AS ABAP,
• управление фоновыми заданиями,
• архивация данных на уровне SAP системы,
• основы ABAP. Для администратора обязательными я бы выделил следующие моменты: знание словаря данных, семантики языка на базовом уровне и навыки работы с отладчиком.

Знания и навыки по данной группе можно найти прежде всего на SAP курсах:

• "SAPTEC" - общий технический курс для SAP BASIS администраторов и ABAP программистов,
• "ADM100 - AS ABAP: Администрирование, часть I" - базовый и самый полезный курс для начинающего базисника,
• "ADM103 - AS ABAP – Углубленное администрирование" - продолжение ADM100,
• "ADM325 - AS ABAP – Логистика программного обеспечения. Транспортная система" - все вопросы, касающееся TMS и обновления.
• "ADM315 - AS ABAP Анализ производительности" - вопросы производительности ABAP части SAP системы,
• "ADM900 - SAP Security - Основы",
• "ADM940 - Концепция полномочий для SAP S/4HANA и SAP Business Suite",
• "ADM950 - Управление безопасностью в системах SAP",
• "ADM960 - SAP NetWeaver AS – Безопасность".

Ну и много информации в моём блоге: по тегам AS ABAP, например. 

Так же много навыков можно получить, пройдя мои курсы по практике SAP Basis администрирования.

По AS Java следует начать со следующих знаний и навыков:

• архитектура сервера приложений AS Java,
• установка, а как более глубокий навык - копирование и миграция AS Java,
• запуск/останов AS Java,
• навыки конфигурации сервера приложений AS Java,
• мониторинг и решение проблем,
• вопросы безопасности и управления пользователями,
• обновление системы: установка пакетов поддержки, стеков (SPS), EHP и обновление версии SAP системы,
• создание резервных копий и восстановление в случае сбоев,
• вопросы производительности,
• система управления изменениями или транспортная система (TMS): настройка системы, управление запросами на перенос,
• вопросы интеграции,
• печать из AS Java: прежде всего это настройка и управление сервером печати PDF-форм - Adobe Document Services (ADS).

Курсы по AS Java - ADM200 или ADM800, про который я писал совсем недавно. На моем блоге тег AS Java.

Конечно, это не все навыки и знания. Я постарался выделить те, которые считаю важными на основании своего опыта работы с SAP системами. То есть базовые знания, которые следует нарабатывать хорошему SAP BASIS специалисту.

А дальше идти туда, куда поведет именно ваш профессиональный путь. Скорее всего это будет в той или иной мере специализация, то есть изучение конкретных решений (систем SAP) или отдельных вопросов из вышеперечисленных: например, производительность систем или безопасность. 

Надеюсь, этот материал будет полезен тем, кто хочет стать профессионалом в этой области. Если у кого-то есть дополнения, то пишите в комментариях или мне на почтовый ящик shibolov@gmail.com.

Удачи!

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