sid системы sap что это

21) Система SAP Monitor

Что такое системный мониторинг?

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

Почему ежедневные базовые проверки / мониторинг системы?

Как мы осуществляем мониторинг системы SAP?

Проверка серверов приложений (SM51)

Эта транзакция используется для проверки всех активных серверов приложений.

Здесь вы можете увидеть, какие службы или рабочие процессы настроены в каждом случае.

Мониторинг рабочих процессов для отдельных экземпляров SM50:

Эта транзакция отображает много информации, как:

Некоторые из типичных проблем:

Мониторинг общесистемных рабочих процессов (SM66)

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

Мониторинг загрузки рабочего процесса на всех активных экземплярах в системе.

С помощью экрана Global Work Process Overview можно сразу увидеть:

Пользователь приложения мониторинга (AL08 и SM04)

Эта транзакция отображает всех пользователей активных экземпляров.

Мониторинг процессов обновления (SM13)

Выполните транзакцию SM13, введите ‘ * ‘ в поле USER и нажмите кнопку.

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

Но если обновление не активно, найдите следующую информацию:

Мониторинг записей блокировки (SM12)

Выполните транзакцию SM12 и введите «*» в поле «Имя пользователя».

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

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

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

Журнал системы мониторинга (SM21)

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

Мы проверяем журнал за предыдущий день со следующим выбором / опцией:

Резюме мелодии (ST02)

Шаг 1: Перейдите к ST02, чтобы проверить сводку мелодии.

Шаг 2: Если вы видите какие-либо значения красного цвета, в SWAPS дважды нажмите на то же самое.

Шаг 3: На приведенном ниже экране нажмите на вкладку « Текущие параметры »

Шаг 4: Запишите значение и параметры профиля

Шаг 5: Перейдите к RZ10 (для изменения значений параметров профиля).

Шаг 6: Сохраните изменения.

Шаг 7: Перезагрузите сервер, чтобы изменения вступили в силу.

Источник

SID Tables in #SAP #BW

Introduction

BW uses a concept where characteristics are identified with masterdata identification numbers. (In german Stammdaten Identifikationsnummer, hence the name SID). This is different then the standard description in a star schema where dimensions contain characteristic values.

With this fact in mind there are a couple different things compared to a regular star schema as the true characteristic value is not to be found in dimensiontables.

SID-Tables

Introducing SID-tables or SID’s in BW characteristics does separate BW objects completely from the use of characteristics. This allows to use the same SID tables from a characteristic multiple times with a reference to it. It can be used in InfoCubes, master data or hierarchies.
The fact that SID’s are always of the INT4 type can have a positive impact on perfromance compared to, for example a producthierarchy key which is 18 char long as only the SID value is stored in the dimension. Another advantage is that SID allows characteristic with compounded keys without violating the concept of SID. For example customer sales is compounded to salesorg, division and distribution channel. This primary key can be handled in SID-tables. This allows access on BW objects as for those InfoObjects only the SID tables are needed to be accessed.

(By the way compounding characteristics always have a negative impact on reporting performance and should only be used where necessary)

The following table describes the SID tables for the InfoObject 0CUST_SALES.

As an InfoObject can be used in multiple BW objects like InfoCubes and master data a deletion of masterdata entries and the respective SID entry can be critical when entries already have been used. In this case a deletion of masterdata is impossible. For BW to know that masterdata entries have been used it is documented in two SID tables called DATAFL and INCLFL. DATAFL is used in dimensions of InfoCubes or attributes of masterdata attributes while INCLFL is used in inclusiontables of external hierarchies.

As soon as a SID entry is used in an InfoCube it is flagged in master data with a value ‘X’ and from now on the masterdata entry cannot be deleted anymore. The disadvantage of this is once the flag is set it won’t be deleted even if the masterdata entry is not in use anymore which makes deletion of masterdata only possible with time intense checks.

The name of SID-tables is related to the object name and in case of a standard InfoObject /BI0/Sxxxxxxxxxx and customer objects /BIC/Sxxxxxxxxx.

SID entries in dimensiontables

Extending the snowflake schema with SID has a significant impact on the datamodel and the structure of it. Especially the use of navigational attributes, timedependent and external hierarchy as well as texts. BW is unique in using SID.

The relationship between dimensiontables and master data tables is established through the SID of the corresponding InfoObject. In the dimensiontables only SID values are stored and never directly characteristic values. Writing the value directly would be a similar good option but there is a couple advantages over that using SID. The INT4 value is a performance gain compared to characteristics with long char values. Referencing with SID tables allows the identification of characteristics that are compounded.

Источник

Как развернуть SAP HANA: разбираем разные методы

SAP HANA — популярная in-memory СУБД, включающая сервисы хранилищ (Data Warehouse) и аналитики, встроенное промежуточное ПО, сервер приложений, платформу для настройки или разработки новых утилит. За счет устранения задержек традиционных СУБД с SAP HANA можно сильно увеличить производительность систем, обработку транзакции (OLTP) и бизнес-аналитику (OLAP).

Развернуть SAP HANA можно в режимах Appliance и TDI (если говорить о продуктивных средах). Для каждого варианта у производителя есть свои требования. В этом посте мы расскажем о преимуществах и недостатках разных вариантов, а также для наглядности — о наших реальных проектах с SAP HANA.

SAP HANA состоит из 3 основных компонентов – хоста, инстанса и системы.

Хост — это сервер или операционная среда для работы СУБД SAP HANA. Его обязательные компоненты — CPU, ОЗУ, СХД, сеть и ОС. Хост предоставляет ссылки на директории инсталляции, данных, логов или непосредственно на СХД. При этом СХД для инсталляции SAP HANA не обязательно должна располагаться на хосте. Если у системы несколько хостов – потребуется либо общее хранилище, либо такое, что доступно по требованию со всех хостов.

Инстанс — набор системных компонентов SAP HANA, установленных на одном хосте. Основные компоненты — это Index Server и Name Server. Первый, который называется также «рабочим сервером», обрабатывает запросы, управляет актуальными хранилищами данных и ядрами БД. Name Server хранит информацию о топологии инсталляции SAP HANA — о том, где работают компоненты и какие данные находятся на сервере.

Система – это один или несколько инстансов с одинаковым номером. По сути это отдельный элемент, который можно включить, отключить или скопировать (сделать резервную копию). Данные распространяются в памяти различных серверов, которые составляют систему SAP HANA.

Система может быть сконфигурирована как однохостовая (один инстанс на одном хосте) или мультихостовая, распределенная (несколько инстансов SAP HANA распределены по нескольким хостам, на каждый хост приходится по одному инстансу). В мультихостовых системах каждый инстанс должен иметь один и тот же номер. Система SAP HANA идентифицируется с помощью System ID (SID) – уникального номера, состоящего из трех буквенно-цифровых символов.

Виртуализация SAP HANA

Одним из главных ограничений SAP HANA является поддержка только одной системы — одного инстанса с уникальным SID сервера. Для более эффективного использования аппаратного обеспечения или уменьшения количества серверов в ЦОД можно использовать виртуализацию. Таким образом другие ландшафты могут сосуществовать на одном сервере с системами, имеющими меньшие требования (непродуктивные системы). Для резервного HA/DR-сервера виртуализация может повысить скорость переключения между продуктивными и непродуктивными виртуальными машинами.

SAP HANA включает поддержку гипервизора VMWare ESX. Это означает, что разные системы SAP HANA – инсталляции SAP HANA с различными номерами SID – могут сосуществовать на едином хосте (общем физическом сервере) в разных виртуальных машинах. Каждая виртуальная машина должна работать в поддерживаемой ОС.

Для продуктивных сред виртуализация SAP HANA имеет серьезные ограничения:

Топологии SAP HANA

Перейдем к развертыванию SAP HANA. Здесь определены две топологии.

Требования SAP к железу

К аппаратному обеспечению для HANA у SAP есть обязательные требования. Они касаются продуктивных сред — для non-prod достаточно минимальных характеристик. Итак, вот требования для продуктивных сред:

Развертываем SAP HANA в режимах Appliance и TDI

Теперь перейдем к практике и расскажем о том, как реализовать SAP HANA в режимах Appliance и TDI. Используем для этого наши платформы SAP HANA на основе серверов BullSequana S и Bullion S, которые сертифицированы SAP для работы в этих режимах.

Небольшая справка о продуктах. BullSequana S на базе Intel Xeon Scalable включает в себя различные модели, до 32 CPU в одном сервере. Сервер построен по модульной конструкции, обеспечивающей масштабируемость до 32 CPU и такого же количества графических процессоров. Оперативная память – от 64 ГБ до 48 ТБ. Среди особенностей BullSequana S – поддержка корпоративного ИИ для улучшенной производительности, ускорение аналитики данных, усовершенствование вычислений в памяти, модернизация с помощью виртуализации и облачных технологий.

Bullion S поставляются с CPU семейства Intel Xeon E7 v4 Family. Максимальное количество процессоров — 16. ОЗУ масштабируется со 128 ГБ до 24 ТБ. Большое количество функций RAS обеспечивает высокий уровень доступности для критически важных инфраструктур наподобие SAP HANA. Bullion S подходят для массовой консолидации ЦОД, работы с приложениями In-Memory, миграции мейнфреймов или устаревших систем.

SAP HANA Appliance

Appliance – преднастроенное решение, включающее сервер, СХД и пакет ПО для внедрения «под ключ», с централизованной службой поддержки и оговоренным уровнем производительности. Здесь HANA поставляется в виде предварительно настроенного аппаратного и программного обеспечения, полностью интегрированного и сертифицированного. Устройство в режиме Appliance готово к установке в ЦОД, а операционная система, SAP HANA и (если необходим) дополнительный инстанс VMWare уже сконфигурированы и установлены.

Сертификация SAP определяет гарантированный уровень производительности, а также модель CPU, объем RAM и СХД. После сертификации изменить конфигурацию без потери гарантии нельзя. Для масштабирования платформы HANA SAP предлагает три варианта.

Решения BullSequana S для SAP HANA в режиме Appliance

*Optional E7-8890/94v4
Решения Bullion S для SAP HANA в режиме Appliance

Все решения Bull в режиме Appliance с версии SAP HANA SPS 12 сертифицированы. Оборудование устанавливается в стандартную 19-дюймовую стойку 42U, с двумя источниками питания — внутренними PDU. Сертификацию SAP имеют серверы:

Вот пример конфигурации СХД EMC Unity 450F в нашем сетапе:

SAP HANA TDI

Альтернативой Appliance является режим TDI (Tailored Data center Integration), в котором можно выбирать конкретных производителей и компоненты инфраструктуры в зависимости от пожеланий заказчика – с учетом выполняемых задач и рабочей нагрузки. Например, SAN может быть повторно использован в ЦОД, при этом некоторые диски отводятся под установку HANA.

По сравнению с Appliance, в режиме TDI пользователю дается гораздо большая свобода в выполнении требований. Это значительно упрощает интеграцию HANA в ЦОД — можно выстроить собственную кастомизированную инфраструктуру. Например, варьировать тип и количество процессоров в зависимости от нагрузки.

Для расчета мощностей рекомендуется использовать SAP Quick Sizer — простой инструмент, выдающий требования к ЦП и памяти для разных рабочих нагрузок в SAP HANA. Затем для планирования IT-ландшафта можно обратиться в SAP Active Global Support. После этого аппаратный партнер SAP HANA преобразует результаты расчетов в разные возможные конфигурации системы — как на топовом, так и на более простом железе. В режиме TDI для серверов допустимо использовать CPU Intel E7, включая Intel Broadwell E7 и Skylake-SP (Platinum, Gold, Silver с 8 и более ядрами на процессор), а также IBM Power8/9.

Серверы поставляются без СХД, коммутаторов и стоек, но требования к аппаратной части остаются такими же, как в режиме Appliance — те же сингл-ноды, решения с вертикальным или горизонтальным масштабированием. SAP требует, чтобы использовались только сертифицированные серверы, СХД и коммутаторы, но это не страшно — у большинства производителей практически все оборудование сертифицировано.

Проверка производительности должна проводиться при помощи тестов HWCCT (Hardware Configuration Check Tool), которые позволяют проверить соблюдение определенных KPI SAP. И есть требование, не связанное с железом: HANA, ОС и гипервизор (опционально) должны быть инсталлированы специалистами с сертификацией SAP. Только системы, где соблюдаются все перечисленные правила, могут получать поддержку SAP, связанную с производительностью.

Линейка серверов BullSequana S в режиме TDI аналогична линейке в режиме Appliance, но без СХД, коммутаторов и стойки. К ним можно устанавливать любые СХД из списка сертифицированных SAP — VNX, XtremIO, NetApp и другие. Например, если VNX5400 соответствует требованиям к производительности SAP HANA, можно подключить СХД Dell EMC Unity 450F как часть конфигурации TDI. При необходимости инсталлируются адаптеры FC (1 или 10 Гбит/с), а также Ethernet-свитчи.

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

Appliance + TDI: HANA для интернет-магазина

Интернет-магазин Mall.cz, входящий в состав Mall Group, был основан 2000 году. Имеет филиалы в Чехии, Словакии, Польше, Венгрии, Словении, Хорватии и Румынии. Это крупнейший интернет-магазин в стране, продающий до 75 тысяч товаров в день, его выручка по итогам 2017 года составила порядка 280 миллионов евро.

Обновление инфраструктуры ЦОД требовалось в связи с миграцией на SAP HANA. Оцениваемый сайзинг составлял 2×6 ТБ для среды prod и 6 ТБ для сред test/dev. При этом требовалось решение с аварийным восстановлением для продуктивной среды SAP HANA в active-active кластере.

На момент объявления тендера у заказчика имелась система под SAP на базе стандартных стоечных и блейд-серверов. Два ЦОДа, располагавшиеся на расстоянии примерно в 10 км друг от друга, были укомплектованы различными СХД – IBM SVC, HP и Dell. Ключевые системы работали в режиме аварийного восстановления.

Сначала заказчик запросил сертифицированное решение в режиме Appliance для SAP HANA для всех систем (среды Production и test/dev) с ростом до 12 ТБ. Но из-за ограничений бюджета стали рассматривать другие варианты – например, большее количество CPU с модулями ОЗУ меньшего объема (модули по 64 ГБ вместо модулей по 128 ГБ). Кроме того, для оптимизации цены рассматривалось совместное СХД для сред Production и test/dev.

Сошлись на 4 CPU и 6 ТБ RAM для среды Production, с возможностью роста. Для сред test/dev в режиме TDI решили обойтись менее дорогостоящими CPU — получилось 8 CPU и 6 ТБ RAM. Из-за большего количества функций, запрашиваемого заказчиком, — репликация, бэкап, совместные среды Production и test/dev на второй площадке — вместо внутренних дисков задействовали СХД DellEMC Unity в конфигурации full-flash. Кроме того, заказчик запросил решение с аварийным восстановлением на базе репликации системы HANA (HSR) с кворумной нодой на третьей площадке.

Итоговая конфигурация для среды Prod состояла из сервера BullSequana S400 на Intel Xeon P8176M (28 ядер, 2.10 ГГц, 165 Вт) и с 6 ТБ ОЗУ. СХД — Unity 450F 10x 3.84 ТБ. В целях disaster recovery для среды Prod использовали BullSequana S400 на Intel Xeon P8176M (28 ядер, 2.10 ГГц, 165 Вт) с 6 ТБ ОЗУ. Для среды test/dev взяли сервер BullSequana S800 с Intel Xeon P8153 (16 ядер, 2.00 ГГц, 125 Вт) и 6 ТБ ОЗУ плюс СХД Unity 450F 15x 3.84 ТБ. В качестве кворума, серверов приложений (VxRail Solution) и решения для бэкапа (DataDomain) наши специалисты установили и настроили серверы DellEMC.

Оборудование готово к будущему апгрейду. Заказчик ожидает рост сайзинга HANA в 2019 году, и ему останется только установить в стойки новые модули.

Appliance: HANA для крупного интегратора в сфере туризма

На этот раз нашим клиентом стал крупный поставщик ИТ-услуг, занимающийся разработкой технологических решений для туристических компаний. Заказчик запустил амбициозный проект SAP HANA для внедрения новой биллинговой системы. Требовалось решение в режиме Appliance с 8 ТБ ОЗУ для сред Production и PreProd. В соответствии с рекомендациями SAP, заказчик выбрал вариант с вертикальным масштабированием.

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

Мы предложили и реализовали решение, сертифицированное SAP, включающее в себя два сервера Bullion S16 – для сред Prod и PreProd. Оборудование работает на процессорах Intel Xeon E7-v4 8890 (24 ядра, 2.20 ГГц, 165 Вт) и оснащается 16 ТБ ОЗУ. Для BW и сред Dev/Test установили девять серверов Bullion S4 (22 ядра, 2.20 ГГц, 150 Вт) по 4 ТБ ОЗУ. В качестве СХД использовалась гибридная EMC Unity.

Такое решение обеспечивает поддержку масштабирования для всех элементов устройства – например, до 16 сокетов с CPU Intel Xeon E7-v4. Администрирование в этой конфигурации упрощено – в частности, для переконфигурирования или разбиения сервера на партиции.

Appliance + TDI: HANA для металлургов

ГМК «Норильский никель» — один из крупнейших производителей никеля и палладия — решил обновить свою аппаратную платформу SAP HANA для обеспечения работы критически важных бизнес-приложений и проектов. Требовалось расширение существующего ландшафта в части вычислительных мощностей. Одним из главных условий, выдвинутых заказчиком, стала высокая доступность платформы – несмотря на аппаратные ограничения.

Для продуктивных сред мы использовали сервер Bullion S8 и СХД в режиме SAP HANA Appliance. Для HA и test/dev платформу развернули в режиме TDI. Использовали один сервер Bull Bullion S8, два Bull Bullion S6 и гибридную СХД. Такая комбинация позволила существенно увеличить скорость работы приложений ландшафта SAP, увеличить объем вычислительных мощностей и ресурсов хранения данных и минимизировать операционные расходы. Немаловажно, что у клиента осталась возможность масштабирования до 16 CPU.

Приглашаем на SAP Форум

В этом посте мы разобрали развертывание SAP HANA разными способами, постарались осветить преимущества и недостатки доступных вариантов. Если у вас появились какие-то вопросы по внедрению SAP HANA, мы будем рады ответить на них в комментариях.

Всех, кто заинтересовался решениями Bull и возможностями их внедрения под SAP HANA, приглашаем на крупнейшее SAP-событие года: 17 апреля в Москве пройдет SAP Форум 2019. Ждем вас у нашего стенда в зоне IoT: расскажем много интересного, а также разыграем множество призов.

Источник