Книга "Тайм-менеджмент для системных администраторов"

Продолжаю рассказ о книжной полке администратора SAP систем. 

Закончил чтение книги Томаса Лимончелли "Тайм-менеджмент для системных администраторов" и хочу поделиться своим мнением.

Книг об управлении временем и задачами я прочитал достаточное количество. Все они несут примерно одинаковые и в основном здравые идеи. Но эта книга особенная. Автор - настоящий системный администратор с не одним десятком лет опыта за плечами, который при этом активно интересуется темой управления временем. То есть эта книга про нас. Об этом вы поймете сразу же, с первых страниц. Томас очень точно подмечает основные черты и психологические нюансы типичных системных администраторов. От этого портрета он и отталкивается в своей книге. Делится советами и решениями, которые помогут в работе именно таким как мы. 

Книга небольшая, читается очень легко и быстро. Язык изложения простой, местами с юмором, есть даже комиксы. :) Не смотря на то, что книга написана в 2007 году, 80-90% советов актуальны и сейчас.

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

Лично я для себя открыл несколько интересных моментов, которые обязательно постараюсь внедрить в свою жизнь и работу. 

Книгу настоятельно рекомендую как к прочтению, так и к добавлению в личную библиотеку. В сети книга ищется (и находится) легко. 

Книгу посоветовал Дмитрий Куликовский в своём рассказе о работе системного администратора Yandex. Если ещё не смотрели, то настоятельно рекомендую ознакомиться. 

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

Конфигурирование SAP системы - IV

В 2013 году я написал цикл статей про параметры AS ABAP части SAP системы. В постах я описал где они хранятся и как их изменять. Можете освежить свои знания и прочитать статьи еще раз:

• Конфигурирование SAP системы - I,
• Конфигурирование SAP системы - II,
• Конфигурирование SAP системы - III.

Как вы помните, параметры AS ABAP части SAP системы хранятся в профилях (profiles). До версии SAP NetWeaver 7.1 было 3 профиля (рис. 1). В более свежих системах содержимое двух профилей было объединено в один и общее количество профилей сократилось до 2-х (для системы с одной инстанцией). Об этом я рассказывал в этом посте. 

Рис. 1. Последовательность чтения SAP параметров и профили SAP.

Сегодняшний рассказ будет больше посвящён резервным копиям профилей SAP. Как вы поняли из моих предыдущих постов: параметры - это очень важная часть SAP системы. От них зависит стабильность работы системы, её производительность и безопасность. С помощью параметров мы выделяем аппаратные и программные ресурсы для SAP системы. При некорректных значениях ряда параметров система может работать крайне не стабильно или вообще не подняться.

Поэтому необходимо соблюдать ряд правил при работе с параметрам SAP системы.

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

Правило 2. Профили SAP хранятся в операционной системе в виде текстовых файлов. Расположены файлы, в случае Unix, в директориях /usr/sap/<SID>/SYS/profile и /sapmnt/<SID>/profile. В случае Windows это директория <DISK>:\usr\sap\<SID>\SYS\profile. SAP не рекомендует изменять параметры на уровне операционной системы. Поэтому второе правило говорит о том, что SAP профили необходимо загрузить в базу данных. Сделать это можно в транзакции RZ10. И в дальнейшем изменение параметров производить там же.

Правило 3. Если вы изменяете параметры в SAP профиле, то ПЕРЕД операцией всегда делайте резервную копию предыдущей версии файла.

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

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

Рис. 2. Просмотр сохранённых версий профиля SAP.

По любой старой версии профиля всегда можно просмотреть административные данные: имя профиля, версию, когда и кем были внесены изменения  (рис. 3).

Рис. 3. Просмотр административных данных старой версии профиля.

Ну и конечно же можно открыть содержимое профиля и просмотреть все значения параметров SAP.

Теперь перейдём на уровень операционной системы и посмотрим что с профилями там.

При ведении профилей SAP через транзакцию RZ10 в каждом файле автоматически генерируется заголовок с полезной информацией. В заголовке можно найти версию профиля, дату активации и автора. Дополнительно добавляются комментарии для всех изменённых параметров (рис. 4).

Рис. 4. Пример профиля SAP с уровня операционной системы.

При этом каждый раз, когда мы в транзакции RZ10 нажимаем на кнопку "Сохранить" и активируем изменённый профиль, на уровне операционной системы создаётся копия старого профиля. В системах до SAP NetWeaver 7.1 это была одна копия с расширением .BAK, которая каждый раз перезаписывалась. То есть хранилось 2 копии профиля - текущая и предыдущая (рис. 5).

Рис. 5. Пример списка профилей SAP на уровне операционной системы.

А, начиная с SAP NetWeaver 7.1 все предыдущие версии профиля хранятся в виде отдельных копий с расширениями .1, .2, .3 и так далее (рис. 6). Только не путайте эти числа с версиями профиля в RZ10, они не совпадают. В данном случае, это версии копий файла на уровне операционной системы.

Рис. 6. Пример списка профилей SAP на уровне операционной системы.

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

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

Без паники! Внеочередные скидки на пакеты обучения SAPADM 2.0

Есть такая древняя мысль: "Посеешь мысль - пожнешь действие, посеешь действие - пожнешь привычку, посеешь привычку - пожнешь характер, посеешь характер - пожнешь судьбу". Я верю в силу привычки. Что такое привычка? Это действие, которое человек выполняет постоянно, но при этом по-минимуму затрачивает свои умственные, ментальные и физические ресурсы. Хорошая привычка за время может превратиться в потрясающий объем совершённого полезного действия, который приносит неоценимую пользу и вклад в развитие человека. Имеешь привычку читать каждый день по 45-60 минут, получаешь за год 25-30 прочитанных книг. Занимаешься спортом 3 раза в неделю, получаешь в конце года хорошую фигуру, самочувствие и здоровье. Выработал привычку делать свою работу хорошо в любых ситуациях, получаешь на выходе выше зарплату, не попадаешь под сокращение или быстро находишь новое место в случае увольнения.

Для системного администратора привычка это вообще что-то родное и понятное. Можно провести аналогию с автоматизацией рутинных, но важных и полезных операций для обеспечения устойчивой работы обслуживаемой системы.

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

...я увидел на стадионе видного футболиста, который интенсивно тренировался, хотя накануне его исключили из команды. Я поинтересовался, почему он так рьяно все делает, ведь его выгнали. Ответ его был таков: «Если я сейчас не буду тренироваться, то тогда меня потом никуда и не пригласят». И действительно, вскоре он играл в другой команде.
   Очень важное замечание для нашего времени и для тех, кто временно остался без работы.

Не только в психологии, но и во всех сферах жизни можно найти подтверждение этой мысли.

Вот в спорте говорят:

Конечно это шутка, но даже и она не просто так. :)

Ну а если серьёзно, то я давно понял, что в занятиях физкультурой и спортом главное это постоянство. Если условия не очень благоприятные (приболел, закрыли спортзал или не достаточно времени), то всё равно необходимо заниматься даже в минимальном объёме. У меня, например, без занятий происходит мощный откат - как в физической форме или в силовых показателях, так и в самочувствии. Поэтому за столько лет - ходить в зал или как-то заниматься вошло в привычку и стало второй натурой. 

В личном плане тоже есть теория, что человек с хорошим набором привычек (фоновых качеств), может лучше устроить свою жизнь. Кому интересна эта мысль, можете прочитать книгу Тимура Гагина "Занимательная физика отношений, или За жизнь и про любовь". 

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

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

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

Потому что в связи с текущей ситуацией в стране и мире, я делаю внеочередные скидки на свои обучающие пакеты нового курса SAPADM 2.0.

Весь апрель цена каждого пакета составляет 16 000 12 000 рублей.

Для получения скидки необходимо написать мне на почтовый ящик shibolov@gmail.com, указав в теме письма название курса SAPADM 2.0 и кодовое слово "Карантин".

При оплате сразу двух первых доступных пакетов дополнительная скидка.
В этом случае общая стоимость составит 22 000 рублей.

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

Будьте здоровы!

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

SUSE Linux Enterprise Server 11SP4: установка и настройка в VMware

Уже давно в своих постах я рассказываю про операционную систему SUSE Linux, которую можно использовать как платформу для разворачивания SAP систем. Компания SUSE тесно сотрудничает с компанией SAP. У них даже есть серия дистрибутивов специально подготовленных для разворачивания SAP систем: SUSE Linux Enterprise Server for SAP Applications. Предыдущие посты про эту операционную систему можно найти по ссылкам:

- "SUSE Linux Enterprise Server как платформа для SAP системы",

- "SUSE Linux Enterprise Server как платформа для SAP системы. Обновление",

- "SUSE Linux Enterprise Server 15 for SAP шагает по планете".

На данный момент поддерживаются 3 ветки версий SLES (рис. 1).

Рис. 1. Поддерживаемые версии SUSE Linux Enterprise Server.

Сегодня хотел поделиться опытом разворачивания дистрибутива SUSE Linux Enterprise Server 11 SP4 for SAP Applications в среде VMware. Версия операционной системы не сама свежая, но ещё поддерживается, как компанией производителем, так и продуктами SAP. 

Последняя на текущий момент версия ESXi 6.7 данную операционную систему также поддерживает в полном объёме. 

Предыдущие мои установки были в виртуальной среде VirtualBox. Эта отличается только тем, что в последних шагах разворачивания операционной системы необходимо установить набор расширений VMware, который называется VMware Tools. Сделать это можно, выполнив несколько шагов:

1. Подключить образ диска с VMware Tools, выбрав соответствующий пункт меню виртуальной машины «Actions -> Guest OS -> Install VMware Tools». 
2. Внутри операционной системы открыть терминал, перейти в пользователя root. 
3. Скопировать файл VM*tar.gz во временную директорию, распаковать и выполнить установку командами: 
   # mount /dev/cdrom /media 
   # cp /media/VM*.tar.gz /tmp 
   # cd /tmp
   # tar -zxvf VM*.tar.gz 
   # /tmp/vmware-tools-distrib/vmware-install.pl --default 
4. Перезагрузить операционную систему.
5. Проверить корректность установки командой:
   # /etc/init.d/vmware-tools status 

   Статус должен быть running (рис. 2).

Рис. 2. Проверка статуса установки набора расширений VMware Tools.

Официальную страницу с инструкцией можно найти тут.

Ну и свою полную инструкцию по разворачиванию SUSE Linux Enterprise Server 11 SP4 for SAP Applications в виртуальную машину VMware и подготовки к установке SAP системы я выложил на страницу с инструкциями и памятками этого блога. 

Скачать можно по этой этой ссылке (zip-архив, 2495 Кб).

Ещё один момент: учтите, что во время установки операционной системы в виртуальную машину VMware почему-то не работает корректно управление курсором мыши. Всё можно сделать с помощью клавиатуры и клавиши Tab, но будьте к этому готовы. После установки VMware Tools всё работает корректно.

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

Пятничный юмор

Как вы наверняка знаете, название компании SAP это аббревиатура, которая по немецки расшифровывается как Systemanalyse und Programmentwicklung или по английски System Analysis and Program Development. Ну а по русски это звучит -  Системный анализ и разработка программ.

Это всё официально. А за глаза, за более чем 40 летнее существование компании люди, кто сталкивался с их продуктами, придумали другие расшифровки. Которые иногда может быть более точно отражают отношение и суть компании и её продуктов. :) Предлагаю как раз такую подборку:

Переведу:
1 - Несколько Высокомерных Программистов,
2 - Программа Повышения Зарплаты,
3 - Страдание После Приобретения,
4 - Начало Установки Патчей.

А вот еще несколько:

И перевод:
1 - Извините За Продуктив,
2 - Вышлите Следующий Платёж,
3 - Страдание После Приобретения (страдай дважды :)),
4 - Начинай Добавление Людей (Сотрудников, как я понимаю),
5 - Медленно И Болезненно.

Ну это всё шутки, конечно. И SAP мы все любим. :-*

P.S. Добавил результаты последнего опроса про отпуск. Кому интересно, переходим по ссылке.


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

Как пересоздать online redo log files Oracle

Не так давно в моём рассказе про опыт миграции одной SAP системы я упоминал о ситуации, когда онлайн журнальные файлы (redo log files) Oracle оказались узким местом при импорте данных. Решением стало пересоздание данных файлов намного большего размера. Давайте поговорим об этом более детально.

Про журнальные файлы Oracle я рассказывал в этом посте. Существует два вида данных журналов - онлайн и оффлайн. Вторые являются копией первых при активации режима работы базы данных - ARCHIVELOG MODE. Именно про этот режим в большей степени был мой прошлый пост. Сегодняшний же рассказ про первый вид - online redo log files.

Посмотреть список онлайн журналов, их размер и расположение можно тремя способами:

1. Запустить в транзакции DB13 задание Check Database и просмотреть журнал выполнения (рис. 1).
     
2. В утилите BR*Tools перейти по меню "2 - Space management -> 7 - Additional space functions -> 3 - Show redolog files -> cont, cont, cont" (рис. 2).
     
3. В утилите SQLPlus выполнить 2 SQL-запроса:
   col MEMBER format a38; 
   SELECT v$logfile.group#, v$logfile.member, v$log.bytes/1024/1024 as FS_SIZE,  v$log.status
   FROM v$logfile
   LEFT JOIN v$log ON v$logfile.group#=v$log.group#
   ORDER  BY v$logfile.group#, v$logfile.member; 
   
   
   Первый запрос изменяет формат экрана для удобного просмотра результатов работы второго. А второй собирает информацию из двух системных представлений (Oracle Views) V$LOGFILE и V$LOG. Результатом будет список онлайн журналов с размером и статусом (рис. 3).

Рис. 1. Просмотр информации об онлайн журналах в DB13.

Рис. 2. Просмотр информации об онлайн журналах в BR*Tools.

Рис. 3. Просмотр информации об онлайн журналах в SQLPlus

Как видно из снимков экранов в данном случае в системе 4 группы онлайн журнальных файлов, в каждой группе по 2 копии файлов, а размер каждого файла 200 Мб. Данные журналы используются по кругу, предыдущая информация каждый раз перезаписывается. В текущий момент времени запись может производиться только в одну группу. На снимках экранов это четвёртая группа файлов, она имеет статус CURRENT. Те журнальные файлы, записи в которых уже были внесены в дата-файлы, имеют статус INACTIVE. То есть система помечает, что их можно перезаписать. И существует еще статус ACTIVE, когда указатель переключился на следующий журнал, но перезаписывать журнал ещё нельзя. Так как СУБД ещё не зафиксировала данные изменения в дата-файлах.

Задача пересоздания онлайн журналов может возникнуть по разным причинам. Например, для решения проблемы с производительностью, когда в системном журнале Oracle наблюдаются ошибки вида 'Chekpoint not complete' (SAP note 79341 - Checkpoint not complete) и рекомендуется увеличить размер журнальных файлов. Или как в моей истории при импорте большого объёма данных в систему. Иногда бывает необходимо перенести файлы журналов в другое место, изменить состав групп или решить другие  подобные административные задачи. 

Пересоздать отдельную группу онлайн журнальных файлов можно на живую, при работающей системе. Единственное условие - группа не должна использоваться, то есть должна находиться в статусе INACTIVE. Для выполнения операции придётся использовать SQLPlus. В BR*Tools такой функциональности не предусмотрено. Ну и, как вы поймёте из описания процедуры, необходимо выбрать период с минимальной нагрузкой на систему. Нам необходимо чтобы во время проведения операции переключение между группами журналов происходило как можно реже. 

Итак, перейдём к процедуре и инструментарию (набору SQL-запросов и команд). Для примера увеличим размер online redo log files до 250 Мб.

1. В терминале операционной системы переключаемся в пользователя <ora>sid. Входим в SQLPlus и открываем подключение к базе данных командами:
   sqlplus /nolog 
   connect /as sysdba 
     
2. Для начала необходимо просмотреть информацию о текущем состоянии онлайн журнальных файлов, выполнив 2 SQL-запроса из списка выше (пункт 3) (рис. 4).
   
   

   

   Рис. 4. Процесс пересоздания онлайн журнальных файлов - 1.

     
3. После этого выбираем первую неактивную группу онлайн журнальных файлов для удаления. В данном случае это группа 1 (G11). Удаление группы производится SQL-запросом вида:
   ALTER DATABASE DROP LOGFILE GROUP 1; 
   
   
   После выполнения в списке журнальных файлов данной группы быть не должно (рис. 5).
   
   

   

   Рис. 5. Процесс пересоздания онлайн журнальных файлов - 2.

     
4. Открыть еще один терминал операционной системы и в нём удалить файлы только что удалённой группы онлайн журналов. Для этого использовать команды вида:
   rm /oracle/EI8/origlogA/log_g11m1.dbf 
   rm /oracle/EI8/mirrlogA/log_g11m2.dbf 
   
   
   Для удаления файлов необходимо иметь достаточные полномочия: суперпользователя root, пользователя <ora>sid (Oracle до версии 11g) либо пользователя oracle (при использовании базы данных Oracle 12c и выше) (рис. 6).
     

   

   Рис. 6. Процесс пересоздания онлайн журнальных файлов - 3.

     
5. Вернуться в терминал с SQLPlus и создать удалённую группу онлайн журнальных файлов Oracle заново SQL-запросом вида:
   ALTER DATABASE ADD LOGFILE GROUP 1 
   ('/oracle/EI8/origlogA/log_g11m1.dbf', 
   '/oracle/EI8/mirrlogA/log_g11m2.dbf') 
   SIZE 250M; 
   
   
   После этого данная группа должна появиться в списке. Статус UNUSED означает что база данных эти журналы еще ни разу не использовала (рис. 7).
      

   

   Рис. 7. Процесс пересоздания онлайн журнальных файлов - 4.

   
   Если необходимо создать группу онлайн журнальных файлов с одним файлом, без зеркалирования, то в SQL-запросе в скобках указываем только один файл.
     
6. Повторить шаги, описанные в пунктах 3-5, для следующих групп онлайн журнальных файлов имеющих статус INACTIVE.
      
7. Для того, чтобы выполнить операцию удаления и создания для группы, файлы которой находятся в статусе ACTIVE или CURRENT, можно выбрать 2 способа. В первом случае просто подождать. Рано или поздно система заполнит текущий журнальный файл и переключится на следующий.
   Во втором же случае можно выполнить следующие SQL-запросы:
   

   ALTER SYSTEM SWITCH LOGFILE; 

   ALTER SYSTEM CHECKPOINT; 
   
   Первый запрос принудительно переключает текущий журнал Oracle на следующий, а второй инициирует принудительное выполнение контрольной точки базы данных (Checkpoint). В этом случае все записи из журнала фиксируются в дата-файлах и журнал освобождается (рис. 8).
     
   

   

   Рис. 8. Пример переключения текущего журнального файла.

        
8. В итоге после пересоздания всех групп журнальных файлов у вас должна получиться требуемая вам картина (рис. 9).  

Рис. 9. Онлайн журнальные файлы после пересоздания.

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

На данную тему существует SAP note 309526 - Enlarging redo log files.
Как факультатив ещё можно прочитать SAP note 1627481 - Preemptive redolog switches in Oracle 11.2 and higher.

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

Особенности конфигурации файла /etc/services для SAP в SUSE Linux

Как знают постоянные читатели моего блога, в последнее время я начал плотно работать с операционной системой Linux (в частности SUSE Linux) в качестве платформы для разворачивания SAP систем. Сегодня расскажу ещё об одной особенности, с которой лично столкнулся.

После базовой установки ABAP-части SAP системы на операционную систему SUSE Linux обнаружил, что не корректно работают некоторые транзакции. В частности, транзакции, которые используются в системе с несколькими серверами приложений (я упоминал про это в этом посте). Прежде всего это транзакция AL08 - просмотр пользователей всех серверов приложений, выполнивших вход в систему. Также проблемы возникают в транзакциях SM21 (системный журнал) и SM20 (журнал безопасности) при попытке дистанционно просмотреть журналы других инстанций. Например, на начальном экране транзакции AL08 в старых версиях SAP систем не отображается ни одной активной инстанции, даже текущей (рис. 1).

Рис. 1. Не корректно работающая транзакция AL08.

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

Дело в том, что внутри данных транзакций используется функциональный модуль TH_SERVER_LIST (для просмотра используем транзакцию SE37), который в свою очередь вызывает внутреннюю C-функцию SAP ядра ThSysInfo (рис. 2).

Рис. 2. Пример исходного кода функционального модуля TH_SERVER_LIST.

Если мы попробуем протестировать работу данного функционального модуля, нажав на панели соответствующую кнопку (рис. 3).

Рис. 3. Тестирование работы функционального модуля TH_SERVER_LIST.

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

Рис. 4. Тестирование работы функционального модуля TH_SERVER_LIST.

Для просмотра результатов необходимо щелкнуть на строке таблицы LIST напротив надписи "Результат" (рис. 5).

Рис. 5. Просмотр результатов теста.

На экране появится строка таблицы (рис. 6).

Рис. 6. Просмотр результатов теста.

Функциональный модуль вызывает функцию SAP ядра, которая должна вернуть имя сервиса или номер порта текущей инстанции SAP системы. А в данном случае мы видим какой-то tick-port. Что это? 

Дело в том, что во всех Unix-like операционных системах сервисы, которые работают в системе, должны быть зарегистрированы. Имена сервисов, используемые ими порты и протоколы описаны в файле /etc/services.

К слову сказать, в MS Windows этот файл тоже есть и находится по пути - C:\Windows\System32\drivers\etc\services.

Если сервис не зарегистрирован, то есть не описан в этом файле, то ни одно приложение не может его использовать. Инстанции SAP системы не исключение и все свои сервисы должны описать в этом файле. Строки обычно добавляются автоматически в конец файла в процессе инсталляции SAP системы (рис. 7).

Рис. 7. Пример строк SAP системы в файле /etc/services.

Но разработчики операционных систем семейства Linux, в частности SUSE Linux, решили добавить в этот файл все возможные сервисы, которые могут быть в системе. Наверное, это сделали из лучших побуждений - чтобы потом после разворачивания почти любого приложения, всё работало. В итоге, сразу после инсталляции операционной системы данный файл уже имеет больше 12 000 строк сервисов!

Детальный анализ показал, что с номером порта, который используется текущей инстанцией, в этом файле уже есть записи (рис. 8).

Рис. 8. Строки с нашим номером порта для сервиса Tick Port.

Узнаёте? :) Это и есть то, что возвращает наша функция SAP ядра. То есть происходит поиск по номеру порта до первого совпадения. Имя сервиса считывается и передаётся ABAP-программе.

Решением данной проблемы может быть удаление или комментирование всех строк, в которых используются порты SAP системы. Этот список я приводил в этом посте. Так как портов очень много, то эта задача может быть не простой. По-хорошему стоит ещё и проанализировать какие сервисы используются в системе, а какие нет. Чтобы случайно что-нибудь не сломать.

Поэтому я применил другое решение. Можно после установки SAP системы перенести строки с сервисами SAP системы из конца файла /etc/services в его начало (рис. 9).

Рис. 9. Перенос строк с SAP сервисами в начало файла /etc/services.

Тогда функциональный модуль TH_SERVER_LIST будет находить верное вхождение сервиса в файле, так как оно стоит первым, и выдавать корректный результат (рис. 10).

Рис. 10. Пример корректной работы функционального модуля.

И если в работе транзакций были проблемы по вышеописанной причине, то они исчезнут. Только имейте в виду, что для применения изменений возможно придётся выполнить рестарт SAP системы.

Надеюсь, что эта информация кому-то пригодится.

Похожие проблемы описаны в SAP notes:

• 947726 - Sec audit: SM20 does not display all existing servers,
• 2135427 - TH_SERVER_LIST Does Not Provide Dispatcher Service.

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