Мастер-класс "SAP ландшафт и основы транспортной системы"

Коллеги, друзья и просто сочувствующие, хочу поделиться новостью. Во вторник, 18 мая 2021 года, я буду проводить мастер-класс на площадке портала "SAPLAND". Мастер-классом назвать, наверное, это событие было бы слишком громко. Скорее это будет лекция "сборная солянка" на тему "SAP ландшафт и транспортная система". 

Попытаюсь за 4 часа рассказать всё, что знаю про транспортную систему в ABAP инстанции SAP системы, собрав в одном материале все нюансы и хитрости. Глубоко вглубь настройки и конфигурации не полезем, но в ширину постараюсь охватить всё. Будем говорить про базовые вещи, которые существуют в SAP системах с версии SAP R/3 3.0 и по сей день. При подготовке стараюсь сделать материал максимально интересным для широкого круга специалистов. Ведь с транспортной системой сталкиваются и консультанты по модулям SAP системы, и ABAP-программисты, и SAP BASIS-консультанты/администраторы.

Если интересно, то регистрируйтесь и приходите. Формат мероприятия - онлайн. 

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

Тюнинг настроек памяти AS ABAP инстанции на реальном примере: результаты

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

Итак, с помощью SAP параметров были увеличены некоторые области памяти и буферы инстанции. В результате этого общая виртуальная память SAP инстанции выросла на 5,5 Гб (рис. 1 и 2).

Рис. 1. Виртуальная память SAP инстанции до корректировки. 

Рис. 2. Виртуальная память SAP инстанции после корректировки.

Но, как вы помните из прошлого поста, объём оперативной памяти сервера составляет 256 Гб, что вполне достаточно для увеличенного объёма памяти SAP инстанции. Поэтому и после увеличения аппетитов SAP инстанции swap область на сервере не используется (рис. 3). А значит  эффективность работы с памятью на уровне операционной системы не упала.

Рис. 3. Вывод команды top на сервере после корректировки.

Корректировки параметров были сделаны 14 апреля. После этого система проработала чуть больше недели. Основной экран транзакции ST02 на данный момент выглядит следующим образом (рис. 4). Инстанция перезагружалась 15 апреля, снимок экрана сделан 23 апреля (1).

Рис. 4. Основной экран транзакции ST02 после корректировки.

Какие выводы, глядя на этот экран, можно сделать:

1. Из Program Buffer (2) используется почти 800 Мб и на данный момент размера в 1 200 Мб достаточно. Ясно, что предыдущего размера в 300 Мб катастрофически не хватало. Параметры, отвечающие за этот буфер, пока корректировать нет необходимости.
2. Объёма CUA Buffer (2) системе до сих пор не хватает. Хотя количество swaps снизилось, но буфер надо бы увеличить ещё. Причём, обратите внимание, что не хватает именно объёма, а не максимального количества записей. Кто-то внимательный заметит, что я рекомендовал в прошлый раз размер буфера равный 6 000 Кб, а по факту он стоит 9 000 Кб. Дело в том, что по нему один раз уже были повторные корректировки: 15 апреля поднимали его размер ещё на 3 000 Кб. Поэтому изначальные изменения параметров были сделаны 14 апреля, а инстанция была повторно перезагружена 15 апреля, именно из-за CUA Buffer.
3. Размер Screen Buffer (2) требованиям системы удовлетворяет гораздо лучше, чем CUA. Можно было бы его не трогать. Но памяти на сервере много и размер буфера не большой, поэтому рекомендуется также немного увеличить и его. 
4. Пиковое использование области памяти Extended Memory (3) было зафиксировано на уровне 6 Гб. Из этого ясно, что предыдущего объёма в 4 Гб было недостаточно. Система с новыми значениями параметров проработала ещё мало. Но, так как рабочие процессы инстанции используют эту память в большом объёме и, памяти на сервере достаточно, я бы сразу порекомендовал ещё немного её увеличить. А после этого понаблюдать за системой на большем промежутке времени. 
5. Пиковое использование области Paging Area (3) за это время достигало более 400 Мб при размере области 256 + 256 = 512 Мб. В прошлый общий объём в 256 Мб, опять же, явно система упиралась. На втором шаге корректировки я бы рекомендовал увеличить ту часть этой области, что находится в оперативной памяти, соответственно увеличив общий объём.

Остальные области я бы пока не трогал. И даже буфер Tables: Generic Key, не смотря на наличие 2-х swaps за 8 дней работы. Как показывает практика, небольшое количество swaps при работе этого буфера будет почти всегда.

Напомню ещё раз: угадать с первого раза со 100% точностью оптимальный размер буферов и областей не получится. Обычно процесс настройки состоит из нескольких шагов. Мои рекомендации на данном шаге это необходимость изменить значения следующих параметров:

• rsdb/cua/buffersize = 12 000
• zcsa/presentation_buffer_area = 12 000 000
• em/initial_size_MB = 10 240
• rdisp/PG_SHM = 65 536
• rdisp/PG_MAXFS = 98 304

Ну и на последок, давайте посмотрим, а как изменилась производительность системы не по субъективным ощущениям, а по объективным данным - цифрам. 

Базовым показателем производительности системы является среднее время отклика системы. При диалоговом режиме работы пользователей этот параметр - это среднее время отклика системы на шаг диалога. Общее время, которое система обрабатывала диалоговые шаги в рабочих процессах типа DIA, делится на количество выполненных шагов. Получается среднее время выполнения одного шага диалога. 

Корректно настроенная SAP система собирает эту информацию на постоянной основе с помощью служебных фоновых заданий. И результаты собранной статистики можно посмотреть в транзакции ST03 (ST03N). 

Как я уже написал выше, параметры были скорректированы 14 апреля. Посмотрим среднее время отклика системы за следующие недельные периоды:

• 29.03.2021 - 04.04.2021 (рис. 5),
• 05.04.2021 - 11.04.2021 (рис. 6),
• 12.04.2021 - 18.04.2021 (рис. 7),
• 19.04.2021 - 25.04.2021 (эта неделя) (рис. 8).

Рис. 5. Показатели времени отклика системы за период до корректировки -1.

Рис. 6. Показатели времени отклика системы за период до корректировки - 2.

Рис. 7. Показатели времени отклика системы за период после корректировки - 1.

Рис. 8. Показатели времени отклика системы за период после корректировки - 2.

Такого результата не ожидал даже я. Среднее время реакции системы на шаг диалога сократилось с 3,4 - 4,4 секунды до 0,8 - 0,7 секунды. То есть, как минимум в 4 раза! Сокращение времени отклика произошло за счёт интервалов, когда выполнялась работа на центральном процессоре. То есть раньше вместо расчётов, система занималась борьбой за ресурсы памяти. 

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

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

Тюнинг настроек памяти AS ABAP инстанции на реальном примере

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

Не достаточно просто купить сервер с большим объёмом оперативной памяти. Ни сервер приложений SAP, ни база данных не смогут использовать оперативную память больше того предела, который настроен через соответствующие системные параметры. 

Про важность настройки размеров буферов для базы данных Oracle я уже писал в этом посте. 

А что касается сервера приложений SAP, то каждый прекрасно понимает, что буферы и общие области оперативной памяти, используемые инстанцией SAP, имеют непосредственное влияние на производительность всей системы в целом. Причём, недостаточно один раз настроить размеры данных областей и успокоиться. Любая SAP система постоянно развивается: увеличивается количество пользователей, активируется новая функциональность системы, появляются новые процессы и программы, увеличивается объем хранящихся и обрабатываемых данных. Ну и, не в последнюю очередь, периодически обновляется сама система. Поэтому необходимо постоянно следить за тем, как система использует области памяти, отслеживать метрики производительности, анализировать показатели. И если это необходимо, то вносить изменения в конфигурацию через параметры SAP системы. При этом хороший администратор должен делать это до наступления критической ситуации, работая проактивно, а не реактивно. Я надеюсь, что этот пост поможет вам отточить "своё кунг-фу" по тюнингу параметров памяти SAP инстанции. :)

Ко мне обратился коллега, который попросил помочь настроить параметры использования памяти на одной из SAP систем. Причиной обращения были факты медленной работы системы и большого количества процессов в PRIV режиме (транзакция SM50) (рис. 1). 

Рис. 1. Список рабочих процессов в PRIV режиме.

Для начала необходимо собрать информацию о системе. Версия SAP системы - SAP ERP 6.0 с SAP_BASIS 700 и ядром 7.22 (рис. 2-4).

Рис. 2. Информация по версии системы - 1.

Рис. 3. Информация по версии системы - 2.

Рис. 4. Информация по версии системы - 3.

Платформа, как видно из этих же скриншотов, Solaris (SunOS 5.11), а в качестве базы данных используется Oracle 11.2. 

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

Оперативной памяти на сервере достаточное количество - 256 Гб (рис. 5). Памяти на уровне операционной системы хватает - область подкачки не используется (рис. 6). При этом мне известно, что весь сервер отдан текущей SAP системе, включающей в себя сервер базы данных и центральную инстанцию SAP.

Рис. 5. Информация из транзакции ST06.

Рис. 6. Вывод команды top на уровне операционной системы сервера. 

Я не знаком с особенностями и нюансами работы с оперативной памятью в операционной системе Solaris, но буду исходить из общих знаний работы Unix с памятью. Читали мой пост про оперативную память в Linux? Всё, что не отдано приложениям, операционная система использует под свои буферы, в частности, под файловый кэш. Но тут мы видим, что даже с учётом этого свободно 12 Гб оперативной памяти. И самый главный критерий, повторюсь, полностью свободная swap область.

Основным буферам базы данных Oracle отдано порядка - 35 Гб и 36 Гб (рис. 7). Суммарно получается около 71 Гб, что так же можно наблюдать у процессов "oracle" на уровне операционной системы (рис. 6). Целесообразность размеров буферов базы данных я здесь рассматривать не буду. У SAP есть рекомендации по параметрам базы данных Oracle, которые отражены в соответствующих SAP notes (вот эта статья, рис. 1). Отмечу лишь тот факт, что хорошая эффективность буфера в текущей системе подтверждена соотношением физических и логических чтений из базы данных (рис. 7). 

Для решения текущей задачи фиксируем, что серверу базы данных отдано порядка 71 Гб общей оперативной памяти. Значит, серверу приложений SAP можно отдать не меньше.

Рис. 7. Информация по производительности Oracle из транзакции ST06.

Вернувшись к основной проблеме, напомню, что переход рабочего процесса в PRIV режим происходит тогда, когда ему не хватает памяти из области Extended Memory и он начинает использовать SAP Heap Memory. Кто не помнит, читаем вот этот пост. Это может происходить, если квота, ограничивающая процессу память из Extended Memory, мала, или же, когда размер этой области слишком мал для текущего количества работающих в системе пользователей.

Основной инструмент для мониторинга использования памяти и буферов SAP инстанции это транзакция ST02. Заглянем в неё на текущей системе (рис. 8). 

Первое на что надо смотреть - когда сделан информационный слепок по системе (1) и время последнего рестарта инстанции (2). Так как во время рестарта происходит сброс всех буферов инстанции и их содержимого соответственно. В данном случае инстанция работает больше 6 месяцев. И для анализа это хорошо. Для основательного анализа желательно, чтобы система работала как минимум пару недель. Тогда собранная статистика будет достаточна. 

Глядя на экран, первое, что бросается в глаза сразу, это большое количество вытеснений из буфера (swaps) для следующих буферов инстанции:

• Program buffer (3),
• CUA buffer (3),
• Screen buffer (3),
• Tables buffers - оба (4),
• Export/Import buffer (5).

Рис. 8. Снимок экрана транзакции ST02.

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

Так что моя первая рекомендация в данном случае: увеличить вышеперечисленные буферы SAP инстанции. 

Обычно буфер определяется двумя параметрами: максимальный размер в байтах и максимальное количество хранимых записей (поля "Dir. Size"). Но при этом у Program Buffer и CUA Buffer один параметр - размер, а количество записей рассчитывается системой исходя из размера самого буфера. 

Текущие значения ключевых, в данном случае, параметров и рекомендации по их изменению представлены в таблице (рис. 9).

Рис. 9. Рекомендации по настройке буферов SAP инстанции.

Теперь переходим к общей памяти (рис. 8, поле 6). По многим областям зафиксировано достижение максимального размера областей (поле "MaxUse [KB]"). Это означает, что хотя бы однажды за период мониторинга данные заполняли буфер полностью и системе его не хватало. Чаще всего такая ситуация проявляется через генерацию ABAP-дампов того или иного типа. Поэтому тут так же рекомендация - увеличить размеры областей памяти Page Area и Extended Memory. Размер Roll Area пока можно не менять. 

Согласно документации рекомендации по увеличению обоснованы уже при достижении 85% от максимального объёма областей. Помните: действовать проактивно, а не реактивно.

Extended Memory хранится только в оперативной памяти, а Page Area состоит из области в памяти плюс файл на диске. Сначала используется область памяти, а при достижении предела  данные записываются в файл на диске.

Таким образом, мои рекомендации по новым значениям параметров для общих областей памяти представлены в следующей таблице (рис. 10).

Рис. 10. Рекомендации по настройке областей памяти SAP инстанции.

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

Текущий объём общей памяти, сконфигурированной для SAP инстанции, составляет примерно 7 Гб ( если прибавить сюда память для рабочих процессов) (рис. 11). Напоминаю, что просмотреть это можно, перейдя в транзакции ST02 -> "Detail Analysis Menu" -> "Storage".

Рис. 11. Общая память, используемая SAP инстанцией.

После применения параметров этот объём увеличится примерно на 5 Гб. Что в текущей системе приемлемо - оперативной памяти сервера достаточно.

Увеличивать параметры следует аккуратно, не спеша. Общие рекомендации следующие:

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

В данном случае я составил рекомендации. Теперь дело за коллегой. Необходимо аккуратно применил новые параметры к SAP системе. При изменении параметров обязательно понадобится перезагрузка SAP инстанции. 

В продолжении можно прочитать про результаты тюнинга и новые рекомендации по тюнингу.

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

Don't reboot it. Just patch!

 Мне кажется, получилась просто бомба!

Uptime funk you up! 

Всем хороших выходных. :)

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

Автоматический запуск/останов SAP инстанции на Linux: примеры использования

В прошлый раз я рассказал, как с помощью shell-скриптов интегрировать процесс запуска/останова SAP системы в процесс инициализации операционной системы Linux. Всего один скрипт, написанный по определённым правилам, и 2 ссылки на него для старта и останова (рис. 1). А в результате ваша SAP система будет останавливаться, когда операционная система отправляется в shutdown или reboot и аналогично запускаться при её старте. Это позволит получить работающую систему при внезапном незапланированном рестарте сервера. Особенно это актуально для дополнительных серверов приложений или кластерной конфигурации. Когда при сбое на основном узле кластера система должна стартовать на резервном узле без вмешательства администратора. Большинство систем построения отказоустойчивых кластеров имеет свои инструменты для старта-останова приложений, но иногда возможно и использование собственных разработок. Тем более если они тщательно протестированы и работают без сбоев.

Рис. 1. Пример расположения инициализационного скрипта и ссылок на него.

Вторая польза от этих скриптов в том, что вы можете использовать их для ручного останова, запуска или проверки состояния SAP системы. Скрипт для центральной инстанции запускает и останавливает не только SAP инстанцию, но и базу данных с сопутствующими процессами (например, процесс LISTENER). Опции, которые можно использовать для этого, я перечислял в прошлом посте (рис. 2). В случае решения каких-то проблем с системой (troubleshooting) лучше выполнять запуск/останов не скриптами, а командами, отслеживая внимательно выполнение каждого шага. А вот если система работает стабильно, то почему бы не облегчить себе немного жизнь: выполнить одну команду, вместо 2-4? :)

Рис. 2. Пример ручного использования инициализационного скрипта.

Третий момент, где мы можем использовать этот скрипт - это запланированный рестарт SAP системы целиком или только её части. Например, изменили вы параметры SAP инстанции и теперь вам необходимо выполнить рестарт инстанции, чтобы параметры подхватились системой. Если у вас есть такой shell-скрипт, то можно запланировать его запуск с нужными параметрами через планировщик операционной системы cron. И при планировании выбрать интервал времени, когда вы можете устроить downtime системе (рис. 3). Чаще всего это возможно сделать или в ночное время, или выходной день, в зависимости от требований к системе. 

Рис. 3. Пример планирования рестарта SAP инстанции через cron.

Главное после такого рестарта, не забудьте закомментировать или удалить запись в планировщике. А то в будущем возможен "сюрприз". 

Ну и последний пример применения скриптов инициализации - это резервное копирование. На текущем проекте резервное копирование выполняется средствами программного обеспечения HPE Data Protector (иногда называют Micro Focus Data Protector). А для серверов, как я уже рассказывал, используется система виртуализации VMware vSphere. Data Protector прекрасно умеет интегрироваться с VMware и при резервном копировании виртуальных машин использует снимки виртуальных машин (snapshots). Таким образом, происходит резервное копирование "замороженного" снимка виртуальной машины (то есть консистентного состояния всех виртуальных дисков) без прерывания работы основной системы. Для получения более консистентного снимка можно перед его созданием выполнить останов SAP системы вместе с базой данных. А после создания снимка SAP систему сразу же запустить, обеспечив её доступность для пользователей. Реализовать это можно через средства Data Protector. Перед выполнением запроса на создание снимка виртуальной машины программное обеспечение резервного копирования может из целевой операционной системы выполнить shell-скрипт  /usr/sbin/pre-freeze-script, а сразу же после создания - другой shell-скрипт /usr/sbin/post-thaw-script. Ну а в этих скриптах можно прекрасно использовать уже написанный инициализационный скрипт для SAP системы (рис. 4).

Рис. 4. Пример shell-скриптов для Data Protector.

Рис. 5. Журнал создания снимков VM для резервного копирования.

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

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

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

Автоматический запуск/останов SAP инстанции на Linux

В далёком 2010 году я выкладывал посты (часть 1, часть 2) про процесс запуска операционной системы HP-UX. Помимо этого там было описано как настроить автоматический запуск и останов SAP системы вместе с операционной системой. 

Потом, как вы помните, был пост, в котором я описывал процесс миграции системы на платформу x86_64 и операционную систему Linux. Пост назывался "История одной миграции SAP системы или Век живи, век учись! - III". Таким образом, система стала работать на операционной системе SUSE Linux Enterprise Server версии 11 SP4 и встал вопрос как автоматизировать запуск и останов SAP системы уже в данной операционной системе. 

Всё это я веду к тому, что в этот раз хочу рассказать как решил этот вопрос, может быть кому-то пригодится.

Операционная система SUSE Linux Enterprise Server 11, как и HP-UX, в качестве системы инициализации использует SysV. В этом случае процесс инициализации совместим со стандартом операционной системы System V. Тогда как почти все современные, на данный момент, дистрибутивы Linux (и SLES, начиная с версии 12) перешли на новую систему инициализации - systemd. Если кратко, то SysV основан на наборе shell-скриптов, а systemd это огромный программный универсальный комбайн с большим количеством функций (если интересны детали, то начать изучение можно с этого). А описание версий дистрибутивов (и систему инициализации, в частности) можно найти, например, на сайте DistroWatch.com. 

За основу shell-скриптов для решения поставленной задачи я взял скрипт, которым кто-то из читателей поделился в комментарии к старому посту про HP-UX. Но "из коробки" у меня скрипт не заработал. Точнее при ручном выполнении скрипта всё работало "на ура": система запускалась и останавливалась. А вот при запуске скрипта во время старта операционной системы возникали какие-то проблемы и он не срабатывал. Анализ показал, что в скрипте не работает изящное решение по выделению системного идентификатора SAP системы (и базы данных) SAPSID и DBSID из имени скрипта. То есть по какой-то причине при запуске скрипта процессом init не работал вот этот кусок кода:

FILENAME=`basename $0`

SAPSID=${FILENAME:6:3} 

В итоге, я заменил эти строки на прямое указание идентификатора системы в коде:

SAPSID=DLC 

Здесь DLC - это пример системного идентификатора системы.

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

Напоминаю ещё раз, что скрипты служат для автоматизации процесса запуска/останова старой SAP системы (используются скрипты startsap и stopsap) с базой данных Oracle на Linux, использующем систему инициализации SysV.

Инструкция по установке скриптов не сложная:

1. Для настройки запуска/останова SAP инстанции с базой данных Oracle cкопировать скрипт sapctlSID_CI в директорию /etc/init.d, переименовав имя файла и добавив в имя скрипта текущий SAPSID, командой вида:

cp sapctlSID_CI /etc/init.d/sapctl<SID>

2. Отредактировать файл /etc/init.d/sapctl<SID>, изменив в начале скрипта строки:

# Provides:          sapctlSID
и
SAPSID=SID 

Заменив значение SID на свой <SID>.

Например, 

# Provides:          sapctlDLC
...
SAPSID=DLC 

3. Права/полномочия на файл должны быть "755", а владельцы файла/группы: "root:root".

4. Следующая команда автоматически создаст ссылки в необходимых директориях /etc/init.d/rc*.d/ для запуска и останова SAP на нужном уровне ОС:

chkconfig --add sapctl<SID>

5. После выполнения вышеописанных шагов скрипт будет автоматически запускать и останавливать SAP систему вместе с базой данных ORACLE и процессами sapOScol и LISTENER на 3 и 5 уровнях операционной системы соответственно.

6. Вручную скрипт можно запускать командами со следующими опциями:

• /etc/init.d/sapctl<SID> status - показывает статус всех процессов SAP + DB;
• /etc/init.d/sapctl<SID> stop - останавливает все процессы SAP + DB;
• /etc/init.d/sapctl<SID> start - запускает все процессы SAP + DB;
• /etc/init.d/sapctl<SID> restart - сначала останавливают систему целиком, а потом запускает SAP + DB;
• /etc/init.d/sapctl<SID> r3stop - останавливает все процессы только SAP инстанции;
• /etc/init.d/sapctl<SID> r3start - запускает все процессы только SAP инстанции;
• /etc/init.d/sapctl<SID> r3restart - сначала останавливает, а потом запускает все процессы только SAP инстанции.

7. Для временного или постоянного отключения автоматического старта и останова SAP системы достаточно удалить ссылки из директорий /etc/init.d/rc*.d/ командой:

chkconfig --del sapctl<SID>

8. Скрипт с именем sapctlSID_DI предназначен для запуска/останова отдельной диалоговой инстанции SAP системы. Всё что относится к запуску базы данных из него удалено. Процесс установки и настройки идентичен вышеописанному. При работе в ручном режиме работают опции "status, stop, start и restart".

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

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

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