понедельник, 29 февраля 2016 г.

Опрос: рабочее место администратора SAP систем

Ссылка на статью
Как-то давно я просил вас поделиться программным обеспечением, которое вы используете для работы. Тогда я открыл для себя утилиту для создания скриншотов Greenshot и до сих пор её использую. 

Сегодня я решил провести опрос в нашей маленькой компании на тему рабочего места администратора. Укажите, пожалуйста, кто какую версию операционной системы и клиентского места SAP GUI использует на своей основной рабочей станции, на которой работает большую часть времени.

Спасибо. 

Результаты:


Windows 7/SAP GUI 7.40 победил. :)


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


среда, 24 февраля 2016 г.

SAP буферизация. Заключение

Ссылка на статью
На уровне сервера приложений SAP AS ABAP существует механизм буферизации. Этот механизм я описал в 4 постах:

Как вы помните из первого поста про память, на уровне инстанции SAP системы выделяют две области памяти: Shared Memory (память доступная для всех процессов) и Local Memory (индивидуальные области памяти для каждого рабочего процесса). Буферы SAP системы являются частью Shared Memory (рис. 1).

Рис. 1. Области памяти в SAP AS ABAP инстанции.

На уровне операционной системы (UNIX) области SAP Shared Memory создаются как отдельные единицы и имеют порядковый номер. Возможно их объединение в пулы, и, в этом случае, на уровне операционной системы выделяется одна область Shared Memory - пул (pool). Пулы также имеют порядковый номер. Мы, как администраторов SAP системы, можем использовать только пулы с номерами 10 и 40.

Для настройки областей SAP Shared Memory и пулов используются параметры вида:
ipc/shm_psize_nn = значение 
Здесь nn - номер области или пула (обязательно две цифры). Например, ipc/shm_psize_07.
Если значение параметра равно "0", значит данная область исключена из пула. Например, ipc/shm_psize_13 = 0 означает, что 13 область исключена из 10 пула.
Если значение отрицательное, то это означает, что данная область включена в пул, номер которого указан в значении. Например, ipc/shm_psize_33 = -10 означает, что область с номером 33 перенесена в 10-й пул.
Положительное значение возможно только для пулов (10 и 40) и указывает их размеры в байтах.

Посмотреть все области можно в транзакции ST02, если перейти по пути "Detail analysis menu -> Storage -> Shared memory detail" (рис. 2).

Рис. 2. Список Shared Memories с номерами.

В поле "Key" указан номер области. На этом экране так же можно увидеть какие области входят в 10 и 40 пулы.

В данном примере параметры пулов следующие (рис. 3).

Рис. 3. Размеры Shared Memory Pools.

В этом и этом постах я уже упоминал про использование утилиты sappfpar. С её помощью можно проверить профиль инстанции (и соответственно, всю инстанцию) на корректность конфигурации памяти. Как я уже упоминал, программа входит в состав SAP Kernel и может быть вызвана с уровня операционной системы командой вида:
 # sappfpar pf=/usr/sap/<sid>/SYS/profile/<instance_profile> check
В результатах работы программы можно найти список всех областей SAP Shared Memory с размерами и номерами, а также рекомендации по размерам пулов 10 и 40 (рис. 4).

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

Если программа выявит некорректные значения, то выдаст сообщения об ошибках и рекомендации (рис. 5).

Рис. 5. Рекомендации по конфигурации памяти от утилиты sappfpar.

Такая организация/конфигурация используется во всех Unix системах. В SAP note # 1137734 - Assignment of memory areas, shared memories and pools можно найти подробности, а во вложении списки областей SAP Shared Memory для каждой операционной системы.  

Стоит отметить, что конфигурация данных областей, кроме 10 и 40 пулов (ipc/shm_psize_10 и ipc/shm_psize_40), без четкого указания со стороны поддержки SAP не рекомендуется.

Настройка пулов очень важна, иначе иногда могут возникать проблемы (например, такие).


Как я уже упоминал в посте "SAP NetWeaver 7.4: особенности конфигурации памяти", в системах, начиная с версии SAP NetWeaver 7.4, в плане управления памятью появился целый ряд изменений и нововведений.
Отметим еще два:
  • Generic Table Buffer и Single Record Table Buffer были объединены в один - Table Buffer.
  • Shared Memory Pools (параметры ipc/shm_psize_10 и ipc/shm_psize_40) по-умолчанию деактивированы, но могут быть использованы, как и ранее.

Table Buffer отображается и может быть проанализирован в транзакции ST02 (рис. 6).

Рис. 6. Единый Table Buffer.

Размер его (в Мб) может быть указан через новый параметр rsdb/tbi_buffer_area_MB. Значение параметра (по-умолчанию) равное "1", означает, что размер вычисляется по формуле:
Размер в байтах = (rttb/buffer_length * 1024 + zsca/table_buffer_area) * 1,1

Список областей Shared Memory без пулов выглядит так, как на рисунке 7.

Рис. 7. Список Shared Memories в SAP NetWeaver 7.4.

Подробнее про это можно найти в SAP note # 1864189 - Incorrect display of Generic Key and Single Record Buffer in ST02 или по ссылке.


Буферы инстанции могут быть сброшены (обнулены) с помощью специальных команд, веденных в поле команд SAP нужной инстанции (рис. 8).

Существуют следующие команды:
  • /$SYNC - сброс всех буферов, кроме Program Buffer,
  • /$CUA - сброс CUA buffer,
  • /$TAB - сброс TABLE buffer (двух или одного),
  • /$NAM - сброс Nametab buffer,
  • /$DYN - сброс Screen buffer,
  • /$ESM - сброс Exp./ Imp. Shared Memory Buffer,
  • /$PXA - сброс Program Buffer (PXA).

Рис. 8. Сброс табличного буфера.

Сброс буферов может быть уместен при обнаружении некорректности в их работе, но стоит помнить, что при выполнении обнуления буфера падает производительность системы (особенно это актуально для продуктивных систем). Выполняйте данные команды только со 100 % пониманием того, что вы делаете. Дополнительную информацию можно найти тут.

среда, 17 февраля 2016 г.

Зачем я веду этот блог?

Ссылка на статью
Я начал свою профессиональную деятельность в 2002 году. Почти сразу судьба свела меня с системами SAP, которые я с тех пор и администрирую. Как я начинал свою карьеру и попал в SAP, я описывал в посте про своё 35-летие.

Проработав около 5 лет, я начал понимать, что мне стало тесно в роли SAP Basis консультанта. Захотелось передать свои знания, поделиться какими-то наработками и материалами.



Причин данного желания я вижу две.

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

Во-вторых, администраторы в своей массе, как мне кажется, более замкнутые и скромные люди, чем, например, функциональные консультанты. Специфика работы у них такая: работают либо в одиночку, либо в очень тесном кругу. С пользователями общаться не имеют ни нужды, ни стремлений. А поделиться задумками, мыслями, обсудить проблему и пути решения хочется.

Поэтому в 2008 году я зарегистрировал этот блог и написал свой первый пост.

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

Не скрою, что одно время мною владела идея немного заработать на блоге, или как сейчас говорят "монетизировать блог". Статистика посещения моего блога на данный момент такова: по рабочим дням примерно 60 уникальных посетителей и 130-150 просмотров. Бывают пиковые значения 95 и 220 соответственно, но происходит это очень редко. В месяц получается около 6500 - 7500 просмотров, при хорошем раскладе (рис. 1). Статистику я никогда не скрывал, она отображается внизу правой колонки. Согласитесь, что посещение не ахти какое. Мой опыт показывает, что увеличение частоты написания постов дает небольшой прирост посещаемости (+10-15 %), но при этом быстро истощает мои нервные и физические силы.

Рис. 1. Статистика блога sidadm за последний месяц.

Я повесил на свой блог два блока рекламы. Больше не вижу смысла, так как сам рекламу не люблю и использую "AdBlock" во всех своих браузерах. Теперь, внимание! За примерно 6 лет показа этих блоков рекламы от Google я "заработал" 63,71 $ (рис. 2)! Причем, вывести можно сумму от 100 $. Таким образом, на рекламе я не заработал ни копейки. Ну и, честно говоря, эта затея почти сразу стала представлять для меня чисто спортивный интерес.

Рис. 2. Статистика Google AdSense.

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

Я усвоил для себя мысль, что используя тематику "Администрирование систем SAP" и публикуя посты в одиночку, большую аудиторию не соберешь, а следовательно, на рекламе и подобных механизмах денег не заработаешь. Даже, ведя блог такое продолжительное время, как я. Признаюсь, это очень не просто. Блогов на тематику SAP, в которых 3-5 постов 4-5 летней давности в Интернете вагон и маленькая тележка.

Так что же мотивирует меня не бросать этот блог и продолжать писать? Информации сейчас в сети в разы больше, чем когда я начинал. В том числе и на русском языке. Можно далеко не ходить и взять для примера тот же портал SAPLand или знаменитый SAPForum.RU. Денег на ведении блога тоже не заработаешь. Так что же?

Ну, во-первых, меня мотивирует то, что данный ресурс содержит уже более 220 постов, и, как минимум, 60 % из них вполне актуальны и реально полезны. Бросить такой проект уже не так просто, как блог из 5 постов. К тому же у меня есть, хочется в это верить, постоянная аудитория, которая читает мой блог и изредка даёт об этом знать. Кстати, обратная связь тоже хороший мотивирующий фактор, и её никогда мало не бывает.

Во-вторых, и это главный аргумент, данный блог держит меня в тонусе. Писать по 3-5 постов в месяц - это комфортный для меня режим, при котором я могу выдавать качественный и полезный контент, а не посты по теме "проснулся, вошёл в систему, проверил логи, поел, пошел спать". :) Тот кто писал статьи или посты знает, что это далеко не так просто, как кажется на первый взгляд. Даже, если тема знакомая и простая, то при написании статьи необходимо собрать информацию из всех доступных источников и свести её воедино. Если есть пробелы в знаниях или хотя бы просто неуверенность в каких-то моментах, то необходимо найти все ответы и удостовериться в их точности. А про мало знакомую тему я и не говорю. Плюс для каждой статьи надо подготовить скриншоты, нарисовать пояснительные схемы. Поэтому для меня писать посты и статьи - это очень полезное занятие, которое обновляет мои собственные знания и при котором я более тщательно прорабатываю новые для себя темы. Существует такое утверждение, что человек лучше знает материал, если может объяснить его другому.

В-третьих, оформление информации и собственных мыслей в текстовом виде - это хороший навык, который пригодится при написании документации, справок или руководств на основной работе в качестве SAP Basis консультанта.

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

Если вам нужен будет совет или захотите что-то мне написать на эту тему, то мой адрес прежний - shibolov@gmail.com.


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


четверг, 4 февраля 2016 г.

Буферизация таблиц на уровне сервера приложений SAP - II

Ссылка на статью
В предыдущем посте я описал механизм буферизации таблиц в SAP системе на уровне сервера приложений AS ABAP. Осталось осветить еще пару моментов, связанных с этим механизмом.

Если в системе сконфигурирована только одна SAP инстанция (один сервер приложений), которая называется центральной (CI или PAS), то в работе буферизации проблем не возникает. Если в таблицу на уровне базы данных были внесены изменения, то записи в буфере отмечаются как "некорректные" (invalidated) и не используются до обновления их из базы данных.
Проблемы могут возникнуть, если в системе сконфигурированы дополнительные сервера приложений. Для сохранения консистентности данных в локальных табличных буферах всех инстанций необходим механизм синхронизации буферов (рис. 1).

Рис. 1. Синхронизация табличных буферов.

Рассмотрим пример. В локальных буферах инстанций А и Б хранятся записи таблицы T001. Рабочий процесс на инстанции А выполнил команду обновления записей в таблице (UPDATE T001). После этого интерфейс базы данных обновил данные на уровне базы данных и в табличном буфере инстанции А (или отметил их как "устаревшие"). Инстанция Б не знает об обновлении данных в таблице и использует устаревшие данные из своего локального табличного буфера.

Механизм синхронизации буферов, который решает проблему, работает следующим образом:
  1. Помимо изменений записей буферизированной таблицы T001 в базе данных и в буфере инстанции А (инстанции, рабочий процесс которой выполнил инициацию изменений), интерфейс базы данных вносит информацию об изменении в таблицу DDLOG.
  2. Все SAP инстанции периодически считывают записи из DDLOG и отмечают у себя в локальных буферах записи из этой таблицы, как "устаревшие". В данном примере это записи таблицы T001. 
Таким образом, сохраняется синхронность и консистентность данных в локальных буферах разных SAP инстанций.

Для активации механизма синхронизации буферов необходимо сконфигурировать следующие параметры:
  • rdisp/bufrefmode = sendon,exeauto.
  • rdisp/bufreftime = 120 (значение по-умолчанию).
Второй параметр (rdisp/bufreftime) задает в секундах периодичность чтения таблицы DDLOG SAP инстанциями. Нельзя выставлять ниже 60. Рекомендуемые значения от 60 до 120.

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

Стоит добавить, что механизм синхронизации буферов работает не только для табличного буфера, но и для других (например, PXA).

В системе посмотреть настройки и записи в таблице DDLOG можно нажав в транзакции ST02 последовательность кнопок "Detail analysis menu -> Additional functions: Buffer synchron." (рис. 2).

Рис. 2. Настройки и записи синхронизации буферов.

Полезные ноты на данную тему:

При анализе таблиц, в контексте буферизации на уровне SAP инстанции, возможны следующие проблемные ситуации:
  • таблица, которую следует буферизировать, не буферизируется,
  • таблица, которую не следует буферизировать, буферизируется. Например, таблица, данные в которой часто изменяются.
Выявить проблемы с буферизацией поможет транзакция ST10 - Table Call Statistics. Данный инструмент позволяет просмотреть статистику по количеству обращений к таблицам со стороны базы данных и ABAP-процессора, а также информацию по буферизации.

На начальном экране транзакции ST10 следует выбрать пункты "All Tables", "This Server" и "Since Startup" и нажать кнопку "Show Statistics" (рис. 3).

Рис. 3. Начальный экран транзакции ST10.

Статистика отображается в виде таблицы (рис. 4).

Рис. 4. Статистика по таблицам системы.

Настроена ли буферизация для таблицы можно увидеть в поле "Buf key opt":
  • ful - полная буферизация,
  • gen - буферизация по ключу,
  • sng - буферизация единичных записей,
  • пусто - буферизация отключена.

В поле "Buffer State" для буферизированных таблиц можно обнаружить следующие значения:
  • Valid - записи таблицы в буфере и могут быть прочитаны при запросе,
  • Invalid - записи в таблице устарели, потому что операция изменения в базе данных еще не завершена,
  • Pending - записи в таблице устарели, но они не будут обновлены при следующем обращении, потому что не прошел период завершения операции изменения в базе данных,
  • Loadable - записи в таблице устарели, но будут обновлены при следующем обращении к таблице со стороны ABAP-процессора,
  • Loading - записи таблицы в данный момент подгружаются в буфер из базы данных,
  • Absent, Displaced - записи таблицы еще не в буфере (например, не было ни одного обращения к ним),
  • Multiple - статус возникает для таблиц, для которых активна буферизация по ключу, когда часть областей данных в буфере, а часть нет,
  • Error - при загрузке данных в буфер произошла ошибка, буферизация невозможна. 

Для анализа буферизированных таблиц следует отсортировать таблицу по столбцу "DB Activity - Rows Affected" (рис. 5). Таблицы в топе количества чтений и настроенном буфере должны быть выбраны для дальнейшего изучения. Здесь возможны две причины: 
  • таблица часто перезагружается в буфер из-за размера или частоты изменений,
  • тип буферизации не удовлетворяет условиям WHERE в запросах к таблице. 
Рис. 5. Список таблиц с большим количеством чтений из базы данных.

Также можно проанализировать количество "Invalidations" и "Changes" для буферизированных таблиц, отсортировав список по соответствующим столбцам. Таблицы из топ - кандидаты на предмет корректировки настроек буферизации (рис. 6, 7).


Рис. 6. Список таблиц с большим количеством "сбоев" при чтении буфера.

Рис. 7. Список таблиц с большим количеством изменений.

При нажатии на панели кнопки "Next view" можно посмотреть объём, который каждая таблица занимает в буфере и максимальный размер, который она занимала с момента старта инстанции (рис. 8).

Рис. 8. Анализ объема, занимаемого таблицей в буфере.

Внимание стоит уделить таблицам, которые занимают больше 1 Мб и имеют много "Invalidations" и таблицам, которые занимают больше 5 Мб.

Предупреждение: никогда не отключайте буферизацию для таблиц из области имен SAP без прямого указания на это в SAP нотах.


Для анализа не буферизированных таблиц можно нажать на панели кнопку "Not buffered" и отсортировать по столбцу "ABAP Processor Requests - Total" (рис. 9).

Рис. 9. Анализ не буферизированных таблиц.

Здесь стоит обратить внимание на небольшие таблицы (< 5 Мб), содержащие настройки системы и, либо сгенерированные в процессе настройки (например, таблицы типа Aххх, где xxx>499), либо из области имен клиента (Y* или Z*). Также необходимо учитывать частоту изменений данных в таблице (столбец "Changes").

Для таблиц из области имен SAP указания следует искать в SAP нотах.


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