OB52 — Не изменяемо в QA системе

У ваших консультантов появилась необходимость ввести данные в тестовую систему, пользуясь транзакциями OB52, S_ALR_87003642,
но у них появляется сообщение о том, что система в статусе «не изменяемо», хотя в продуктивной системе это действие разрешено?
Имеется три пути решения сложившейся ситуации:
1. Открыть мандант в системе тестирования на изменение и внести данные.
При помощи тр. SCC4 разрешаем изменение репозитария и настроек.
2. Изменить роль манданта в системе тестирования со значения «Тест» на «Продуктивный» при помощи той же транзакции SCC4
3. Описан в ноте Note 214132 — OB52: No current settings
И Вуаля! Все работает. Главное не забудьте вернуть настройки в исходное состояние после того, как консультант завершит ввод данных

А вот и нота:

Symptom

If it has been set in Customizing that no changes are to be made to the system, the posting periods can no longer be opened and closed (Transaction OB52).

Other Terms
V_T001B, SOBJ, V_T001B, CURSETTING

Reason and Prerequisites
The maintenance and transport object V_T001B is not declared as a current setting because of an incorrect delivery.

Solution
Start Transaction SOBJ and for object V_T001B set the flag "Current settings" in the header data.

Блокировка манданта от входа

Для блокировки, разблокировки манданта, используйте транзакцию se37
1. SCCR_LOCK_CLIENT (для блокировки манданта)
2. SCCR_UNLOCK_CLIENT (для разблокировки манданта)
Данная функция предназначена для блокировки\разблокировки манданта от входа пользователей. При блокировки манданта, всем пользователям попытавшимся войти в мандант будет появлятся сообщение «данный мандант блокирован от входа». Мандант доступен будет доступен для входа только пользователям SAP* и DDIC.
Для разблокировки:
1. Запустите тр. SE37
2. Введите имя модуля SCCR_UNLOCK_CLIENT
3. Нажмите F8 для активации
4. Введите номер манданта и нажмите (F8).

Для блокировки процедура аналогична, только с модулем SCCR_LOCK_CLIENT

Опубликовано в SAP

SAP STMS. Как узнать кто перенес запрос

Можно посмотреть в табличке TPALOG,

либо в истории импорта:

Пункт меню "Обработать" > "Показать больше" (Ctrl+Shift+F1) > столбец "Пользователь"

либо в истории импорта:

Правой кнопкой на заголовок таблицы > "показать больше". Добавится столбец "Пользователь"

NIPING

На сервере SAP:
niping -s -I 0

На клиенте:

Measuring throughput
niping -c -H <nipingsvr> -B 100000

Measuring RTT
niping -c -H <nipingsvr> -B 1 -L 100

Long LAN stability test:
niping -c -H <nipingsvr> -B 10000 -D 100 -L 360000


Long WAN test (stability):
niping -c -H <nipingsvr> -B 200 -D 1000 -L 36000

Long WAN test (idle timeouts):
niping -c -H <nipingsvr> -P -D 3600000

Short throughput/stability test:
niping -c -H <nipingsvr> -B 1000000 -L 100

MTU test:
niping -c -H <nipingsvr> -B <nnn>

Vary <nnn> according to these values: 500, 1000, 1400, 1500, 4000, 10000 and 40000

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

Раньше это считалось невозможным, но SAP выпустил утилиту, позволяющую переименовать систему. Особенно это удобно когда у вас виртуализация и нужно сделать из продуктивной системы тестовую, а копировать мандант по RFC или через транспортную систему долго.

 

Вам поможет SOFTWARE PROVISIONING MGR 1.0 (если ссылка не работает поиграйтесь с именем хоста websmp207.sap-ag.de, быть может он в это время не доступен:

https://websmp207.sap-ag.de/~form/handler?_APP=00200682500000001943&_EVENT=DISPHIER&HEADER=Y&FUNCTIONBAR=N&EVENT=TREE&TMPL=67838200100200018544&V=MAINT&TA=ACTUAL&PAGE=SEARCH

 

https://websmp207.sap-ag.de/~form/handler?_APP=00200682500000002672&_EVENT=DISPLAY&_SCENARIO=01100035870000000122&_HIER_KEY=501100035870000015092&_HIER_KEY=601100035870000179416&_HIER_KEY=601100035870000236470&_HIER_KEY=701100035871000563073&#wrapper

 

Общий принцип даной процедуры:

  1. Клонируем систему
  2. Запускаем клон, не давая ему сеть.
  3. Отключаем систему от сети, на место которой должна встать новая система.
  4. Переименовываем имя хоста на то, которое будет, IP-адрес.
  5. Правим конфигурационные файлы oracle, дабы избежать подключения к продуктивной базе.
  6. Запускаем SOFTWARE PROVISIONING. (для linux можн запустить SSH -Y дабы получить экран X11 у себя на клиенте).
  7. Производим переименование. (для windows два косяка: Косяк1 - переменная TMP и TEMP не должны указывать в каталог, где находится SAP система. Их нужно временно направить в другой каталог, например c:\temp. Косяк 2 - проверьте, что база остановлена - попробуйте переименовать каталог базы данных. Если не получается - смотрите кто держит файлы. Можно воспользоваться  unlocker. В моем случае это была почему-то оракловая java, хотя все службы были остановлены)
  8. Убеждаемся, что во всех профилях теперь указан правильный SID, имя хоста. Убеждается что каталог базы данных теперь тоже имеет нужное название.
  9. Отключаем архивлоги
  10. Запускаем SAP, молимся
  11. Заходим в систему. SM59 - грохаем RFC, ссылающиеся на продуктивных хост. RZ12, SMLG - убиваем лишние хосты. Проверяем SM51.
  12. SE06 выполняем постпроцессинг. Грохаем транспортную конфигурацию на этой системе. Останавливаем фоновые задания, далее с ними нужно будет разобраться. Стандартные нужно пересоздать в SM36, пользовательские отдать им на рассмотрение. DB13 пересоздаем задания.
  13. SECSTORE - убрать красные записи.
  14. SCC4, создаем новую запись о манданте, ведь мы не хотим чтобы на продуктиве и тесте были одинаковые номера мандантов.
  15. Выполняем локальное копирование (SCCL) манданта из старого в новое, не забыв о месте в тейблспейсах. Ведь новая система на данный момент будет содержать 2 копии продуктивного манданта.
  16. Заходим в новый мандант, выполняем BDLS
  17. Распространяем транспортную конфигурацию на новоявленный хост.
  18. SP12, проверка непротиворечивости
  19. Удаляем старый мандант
  20. Делаем оффлайн реорг таблиц, самых жирных особенно.
    пример :
    brspace -u / -f tbreorg -t  "COEP","VBFA","BSIS" -p 8
  21. Пересобираем статистику.
  22. Заказываем новую лицензию.
  23. Радуемся

 

В SAP EWM после перевода времени некорректно отображается время создания складской задачи

SAP Extended Warehouse Management. Проблема после перевода времени:

Нюанс в том, что в EWM для каждого склада можно выбрать свой часовой пояс.

1

 

 

 

 

 

 

 

Выбираем единицу логической цепочки

2

 

 

 

 

 

 

 

 

 

 

 

Видим, что часовой пояс по-прежнему RUS04, меняем его на нужный нам (RUS03 для Москвы)

3

Если Oracle не стартует из-за не верного параметра

Если Oracle не стартует из-за не верного параметра:

коннектимся к базе как умеем, например

sqlplus / as sysdba (если настроен NTS)

Выполняем:

     create pfile='d:\tmp\pfile.ora' from spfile;

Правим ошибочный параметр в pfile;

Запускаем базу с pfile

     startup pfile='d:\tmp\pfile.ora';

Создаем spfile из pfile обратно:

     create spfile from pfile='d:\tmp\pfile.ora';

Все отчеты SAP

Скачать все отчеты SAP (запуск транзакция SE38 или SA38) с описанием назначения

Файл достаточно большой, поэтому открываться в Word будет долго.

 

Опубликовано в SAP

Настройка SNC-туннеля SAPRouter

Допустим, вам нужно настроить SAPRouter с SNC для удаленных пользователей, например, людей из другого офиса.

Скачаем и распакуем saprouter (sapcar -xvf) и крипто библиотеку в, например, C:\saprouter .

Пропишем переменные окружения (пример):

SECUDIR=C:\saprouter

SNC_LIB=C:\saprouter\nt-x86_64\sapcrypto.dll

 

Далее создадим сертификаты и обменяемся ими:
Внимание, имена РЕГИСТРОЧУСТВИТЕЛЬНЫЕ ! CN в данном случае ИМЯ ХОСТА (работает и по короткому имени, без домена). Однако, CN может быть любым и не совпадать с именем машины, а использоваться для удобства понимания.
Сторона инициатора:

sapgenpse get_pse -v -noreq -p local.pse "CN=spb-initiator"
sapgenpse seclogin -p local.pse
sapgenpse export_own_cert -o spb-initiator.cer -p local.pse

Сторона акцептора:

sapgenpse get_pse -v -noreq -p local.pse "CN=msk-acceptor"
sapgenpse seclogin -p local.pse
sapgenpse export_own_cert -o msk-acceptor.cer -p local.pse

 

Обменяемся сертификатами, запишем в каталог C:\saprouter\nt-x86_64

На стороне инициатора положим файл msk-acceptor.cer , на стороне акцептора положим файл spb-initiator.cer

 

Выполним команду на стороне инициатора:

sapgenpse maintain_pk -a msk-acceptor.cer -p local.pse

И на стороне акцептора:

sapgenpse maintain_pk -a spb-initiator.cer -p local.pse

 

Настройки saproutetab:

Инициатор:

# Allow Outbound connections to SAProuter host2 will use SNC
KT "p:CN=msk-acceptor" <IP акцептора> 3299

# Allow all inbound connections
P * * *

Акцептор:

# accept incoming connections from SAProuter1
# with destination sapdp00 and 3298 on any host
KP "p:CN=spb-initiator" * sapdp00
KP "p:CN=spb-initiator" * 3298

 

Запуск saprouter:

Инициатор:

Saprouter -r -K p:CN=spb-initiator

Акцептор:

Saprouter -r -K p:CN=msk-acceptor

 

Строка String SAPROUTER в SAP GUI :

/H/<IP инициатора>/H/<IP акцептора>/H/

 

Проверка: 

Инициатор:

niping -c -H /H/<IP инициатора>/S/3299/H/<IP акцептора>/S/3299/H/<IP акцептора>

Акцептор:

niping -s

Получаем сообщение вида:

connect to server o.k.
send and receive 10 messages (len 1000)

------- times -----
avg 12.900 ms
max 13.548 ms
min 12.631 ms
tr 151.405 kB/s
excluding max and min:
av2 12.853 ms
tr2 151.963 kB/s

 

Если нет - читаем файл dev_rout. Если программа ругается на SNC - вы напутали что-то с сертификатами, наиболее вероятно перепутали инициатора, акцептора и кто какой сертификат ждет.

Если ругается на route permition denied - проверйяте saproutetab, видимо указали не верный IP. Возможно в c:\windows\system32\drivers\etc\services не описан порт sapdp00.

 

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

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

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

 

Инструкция на SCN:

http://wiki.scn.sap.com/wiki/display/Basis/How+to+setup+SNC+connection+between+SAProuters

Опубликовано в SAP

Права на каталоги SAP в Linux

В примере SM1 — SID системы

Можно использовать скрипты saproot.sh and oraroot.sh выставляющие нужные права или раздать их вручную:

 

Чтобы работал brtools и db13:

chown orasm1:sapsys /sapmnt/SM1/exe/brarchive
chown orasm1:sapsys /sapmnt/SM1/exe/brbackup
chown orasm1:sapsys /sapmnt/SM1/exe/brconnect
chown sm1adm:sapsys /sapmnt/SM1/exe/brrecover
chown sm1adm:sapsys /sapmnt/SM1/exe/brrestore
chown sm1adm:sapsys /sapmnt/SM1/exe/brspace
chown sm1adm:sapsys /sapmnt/SM1/exe/brtools
chmod 4774 /sapmnt/SM1/exe/brarchive
chmod 4774 /sapmnt/SM1/exe/brbackup
chmod 4774 /sapmnt/SM1/exe/brconnect
chmod 755 /sapmnt/SM1/exe/brrestore
chmod 755 /sapmnt/SM1/exe/brrecover
chmod 755 /sapmnt/SM1/exe/brspace
chmod 755 /sapmnt/SM1/exe/brtools

 

Пример:

-rwsrwxr--  1 orasid   sapsys    10022600 Aug 23 2012  brarchive
-rwsrwxr--  1 orasid   sapsys    10251536 Aug 23 2012  brbackup
-rwsrwxr--  1 orasid   sapsys    12179560 Aug 23 2012  brconnect
-rwxr-xr-x  1 sidadm   sapsys    10708840 Aug 23 2012  brrecover
-rwxr-xr-x  1 sidadm   sapsys     4140576 Aug 23 2012  brrestore
-rwxr-xr-x  1 sidadm   sapsys    12778384 Aug 23 2012  brspace
-rwxr-xr-x  1 sidadm   sapsys     4711664 Aug 23 2012  brtools

 

 


 

113747 - Owners and authorizations for BR*Tools

Solution

The following settings are required to call the BR*Tools correctly, especially when using transaction DB13 or DBACOCKPIT:

(1)
ora<sid> and <sid>adm on DB server have a search path on /sapmnt/<SID>/exe. (All br* are contained in this directory.)
ora<sid> belongs to the dba group,
<sid>adm belongs to the sapsys group,

(2)
<sid>adm on the database server has the rhosts entry: "+ <sid>adm".

(3)
The Oracle user ops$<sid>adm must be created in the DB and must have the role sapdba (not DBA) (see SAP Note 134592 for more information).

(4)
brarchive, brbackup, and brconnect belong to ora<sid> and have authorization 4774:
-rwsrwxr--   ora<sid>   sapsys   ...

Reason:
Both the operating system (OS) user ora<sid> and the OS user <sid>adm (for example, from SAP R/3, transactions DB13 or DBACOCKPIT) must be able to call these tools. These tools require access authorization to the database directories and files as well as to the log directories (saparch, sapbackup, sapcheck, and sapreorg) of the BR*Tools. To ensure that they can be executed by both ora<sid> and by <sid>adm, they must belong to the user ora<sid>, and the s-bit must be set.

(5)
brrestore, brrecover, brspace, and brtools belong to <sid>adm and have authorization 755:
-rwxr-xr-x   <sid>adm   sapsys   ...

Reason:
These tools may be used only by OS user ora<sid>, but not by <sid>adm. This ensures that the user <sid>adm does not have write permission for the log directories and therefore cannot create any logs. For this, no s-bit is set, and it is not necessary to define an owner other than the standard owner <sid>adm.
If the tools were started using <sid>adm, they would terminate immediately after the start due to the missing log authorization. However, the user ora<sid> can start the programs despite this and also has the required authorization for the log directories.

For example:
-rwsrwxr--  1 orasid   sapsys    10022600 Aug 23 2012  brarchive
-rwsrwxr--  1 orasid   sapsys    10251536 Aug 23 2012  brbackup
-rwsrwxr--  1 orasid   sapsys    12179560 Aug 23 2012  brconnect
-rwxr-xr-x  1 sidadm   sapsys    10708840 Aug 23 2012  brrecover
-rwxr-xr-x  1 sidadm   sapsys     4140576 Aug 23 2012  brrestore
-rwxr-xr-x  1 sidadm   sapsys    12778384 Aug 23 2012  brspace
-rwxr-xr-x  1 sidadm   sapsys     4711664 Aug 23 2012  brtools

Note 1:
On Linux and Solaris 11, you have to adjust the authorization for brarchive, brbackup, and brconnect manually if you want to create RMAN backups with the OS user <sid>adm. For more information, see SAP Note 776505.

Note 2:
Other BR*Tool authorizations apply for Oracle installations with the OS user oracle. For more information, see SAP Note 1598594.

Опубликовано в Linux, SAP

От чего бывает Internal lock administration error в SAP

Такое случается, когда система пытается заблокировать таблицу с кол-вом записей большем, чем значение, указанное в параметре
enque/table_size , по умолчанию равным 32000(kb) (что примерно 40 000 записей).

Опубликовано в SAP