пересборка профиля инстанции после миграции с винды на линукс

jack_nsk

всем доброго времени суток,

тут экстренно свалился подарок в виде невзлетающей системы после миграции с винды на линукс
половину уже починил, осталось только профили переделать...
недавно попадала инфа, в которой говориться, что профиль инстанции и старт-профиль инстанции сливаются в экстазе в один единственный профиль инстанции. решил уж объединить беду с модернизацией...
но у меня есть подозрение, читает ли при старте инстанция профиль с уровня файловой системы или же подглядывает и в базу данных?
т.е. вопрос приоритетов параметров между профилем с уровня ОС и параметров профиля из базы данных.
R3trans -d дает крайне положительные результаты...
т.е. осталось заставить взлететь инстанцию...
и есть ли тулза, которая может вытащить из базы профиль, который был до миграции?
мне главное понять, тратить ли время на поиск подобных инструментов или же начать скрупулезно по-параметру создавать профиль на уровне оси в текстовом редакторе?

murenets

Однако, терзают меня страшные сомнения, что профили хранятся в базе данных.

шрам

не надо терзаться :mrgreen:

jack_nsk
табличка
TPFHT - заголовки существовавших профилей
TPFET - содержимое существовавших профилей.

выглядит это так:

Code:

SQL> desc sapsr3.tpfet;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 PFNAME                                    NOT NULL VARCHAR2(90)
 VERSNR                                    NOT NULL VARCHAR2(18)
 PARNAME                                   NOT NULL VARCHAR2(180)
 PARNR                                     NOT NULL VARCHAR2(12)
 COMNR                                     NOT NULL VARCHAR2(12)
 DENAME                                    NOT NULL VARCHAR2(30)
 CHKPRG                                    NOT NULL VARCHAR2(96)
 MODPROG                                   NOT NULL VARCHAR2(96)
 CREFPF                                    NOT NULL VARCHAR2(90)
 PSTATE                                    NOT NULL VARCHAR2(24)
 PVALUE                                    NOT NULL VARCHAR2(384)

SQL> select parname, pfname from sapsr3.tpfet where pfname='DEFAULT';

PARNAME
--------------------------------------------------------------------------------
PFNAME
--------------------------------------------------------------------------------
icm/HTTP/logging_0
DEFAULT

SAPDBHOST
DEFAULT

j2ee/dbtype
DEFAULT

З.ы. если, конечно, эти таблички не были почищены в порыве подъема СУБД, как это вобщемто рекомендуется :mrgreen:

murenets

Ух ты!
Не знал.
Думал, что в базе только значения по-умолчанию.

jack_nsk

шрам написал:

не надо терзаться :mrgreen:

jack_nsk
табличка
TPFHT - заголовки существовавших профилей
TPFET - содержимое существовавших профилей.

шрам, спасибо!
правда запрос результатов не дал

Code:

SQL> select parname,pvalue from sapsr3.tpfet where pfname='DEFAULT' and parname like 'DIR_';
no rows selected

смутило относительно значения параметра из рабочей базы DIR_CT_RUN
на уровне ОС в профиле после миграции парметр выглядит так
DIR_CT_RUN = $(DIR_EXE_ROOT)\$(OS_UNICODE)\NTAMD64

попробовал удалить профили, инстанция не стартовала

Code:

startsap
No instance profiles found
please send the tracefile /home/devadm/startsap.trc to support

шрам

по последнему пункту посоветую проверить вот что:
1. /etc/hosts
что нету паразитных записей типа
127.0.0.2 hostname hostname.domain
127.0.0.1 hostname hostname.domain
2. что профиль есть с именем правильного хоста на конце:
START_DVEBMGS00_<hostname>
либо <SID>_DVEBMGS00_<hostname>

у меня на линухе в профилях систем, этот параметр таков:

в 701 - отдельный START-профиль

Code:

DIR_CT_RUN = $(DIR_EXE_ROOT)/run

в 731

Code:

DIR_CT_RUN = $(DIR_EXE_ROOT)/$(OS_UNICODE)/linuxx86_64

в 740

Code:

DIR_CT_RUN = $(DIR_EXE_ROOT)/$(OS_UNICODE)/linuxx86_64

З.ы. объединение профилей пошло с 7.31. сдается мне, что это изменения на уровне ядра

а вообще странно... при гетерогеной миграции, инсталлятор должен был создать все профили

jack_nsk

шрам написал:

2. что профиль есть с именем правильного хоста на конце:
START_DVEBMGS00_<hostname>
либо <SID>_DVEBMGS00_<hostname>

вот тут и начинается самое интересное...

я тоже всегда так думал, что в нижний регистр в линукс переписывать имя хоста
удалил профили инстанции, оставил только дефолтный
startsap

Code:

  {21:34:59 ## pushVHostsFromProfile() start: @=/usr/sap/DEV/SYS/profile/DEV_???*_?*
   _DUMMY=DEV_???*_?*
   _VHOST=sdedev DEV_DVEBMGS00_SDEDEV DEV_DVEBMGS00_SDEDEV.BAK DEV_DVEGS00_s_sdedevedevold

   {21:34:59 ## isVHostLocal() start: sdedev
    VHOST=sdedev
    _IS_LOCAL=1
   }21:34:59 ## isVHostLocal() done: 1

   VHOSTS= sdedev DEV_DVEBMGS00_SDEDEV DEV_DVEBMGS00_SDEDEV.BAK DEV_DVEGS00_s_sdedevedevold
  }21:34:59 ## pushVHostsFromProfile() done

похоже имена профилей берутся из базы...

jack_nsk

в-общем, проблему решил

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

Code:

SETENV_00 = DIR_LIBRARY=$(DIR_LIBRARY)
SETENV_01 = LD_LIBRARY_PATH=$(DIR_LIBRARY):%(LD_LIBRARY_PATH)
SETENV_02 = SHLIB_PATH=$(DIR_LIBRARY):%(SHLIB_PATH)
SETENV_03 = LIBPATH=$(DIR_LIBRARY):%(LIBPATH)
SETENV_04 = PATH=$(DIR_EXECUTABLE):%(PATH)

почесав репу, взял профиль инстанции от свежеустановленного NW7.40 SR1
порвал его на профиль инстанции и старт-профиль инстанции
(по крайней мере ещё на 702 требуется старт-профиль инстанции, экспериментировал на солмане)
startsap - вуаля!

правда при заходе в САП-систему SICK выдал грозное предупреждение о проблемах с базой,
но это уже совсем другая история

всем спасибо за поддержку и подсказки! :pivo:

шрам

8:51 pm

Цитата:

в-общем, проблему решил

кремЕнь!

avlag

шрам написал:

8:51 pm

Цитата:

в-общем, проблему решил

кремЕнь!

Этим кремнем бы да по некоторым частям тела тому, кто систему мигрировал, мигрировал, да не вымигрировал. А потом передал кремню.

jack_nsk

шрам написал:

З.ы. если, конечно, эти таблички не были почищены в порыве подъема СУБД, как это вобщемто рекомендуется :mrgreen:

решил проверить по гайду system copy - не нашел про это

Code:

2.2.2 Activities at Database Level
This section includes the adaptations that you have to make at database level in your target system.
Procedure
Before starting the SAP system, make sure that the logging mechanism of the database is active.
Check the parameters in the database profiles.
Delete all entries from the following tables: ALCONSEG, ALSYSTEMS, DBSNP, MONI, OSMON, PAHI, SDBAD, SDBAP, SDBAR.
Delete entries in the table DDLOGfor buffer synchronization.
Oracle only:
Delete all entries from the following tables: DBSTATHORA, DBSTAIHORA, DBSTATIORA, DBSTATTORA.
Delete the user OPS$<SOURCE_SAPSID>ADM(if existing).
If you changed the <DBSID>during the system copy, we recommend that you adapt the global_nameparameter by using the following SQL command:
alter database rename global_name to <NEW_DBSID>; If the parameter does not exist on your system, ignore this step.
SAP MaxDB only:
Run report RSSDBTICMCLEANUPin the following cases:

уже после, когда начал править параметры в профиле и сохранять его, он продолжил гадить в параметрах и имени профиля...

в rz10 - и под корень нужно выжигать виндовую ересь, а потом импортировать профили с уровня файловой системы!!!

jack_nsk

шрам написал:

8:51 pm

Цитата:

в-общем, проблему решил

кремЕнь!

8:51 pm - это МСК, а реально - 11:51 pm - это НСК
хотя это не предел, как-то до пол-пятого утра система не взлетала...

murenets

jack_nsk написал:

8:51 pm - это МСК, а реально - 11:51 pm - это НСК
хотя это не предел, как-то до пол-пятого утра система не взлетала...

А прийти на работу в 8-00 в пятницу, уйти в 10-30 в воскресенье?

(Мой рекорд)

Правила форума

пересборка профиля инстанции после миграции с винды на линукс

Кто сейчас на конференции