У меня возникла следующая проблема: решила я обновить Solman 7.1 с SPS13 на SPS14. Перед этим за неделю сделала апдайт базы даных (Sybase) до 16.0 SP01 PL03, client тоже обновила. Взяла последний SUM SUM10SP16 PL02 и в общем и целом почти весь процесс прошел без больших приключений, ошибки пошли лишь в Execution фазе. Застряла на последней (уже 89% update сделано): :
SUM:

SQLSTMTSTD.OUT


Запуская R3trans -d получаем следующее:
( т.е. САП не связывается с базой данных, которая up and running. С isql я спокойно захожу на нее)
Почитав ноте 1817091 и 1607816 (Windows), я обновила еще раз клиент (ту же версию, которая и до этого была), но это не помогло. Больше хороших мыслей не пришло. Такое впечатление, что СУМ при удалении shadow instance что-то сделал, что теперь мешает соединению. Может при копировании кернел что-то забыл? Вроде нет, я проверила.
Могу показатъ другие логи. Ничего интересного я пока не нашла.
sapmmc:
ASCS01 up (muss3p 2), SCS02 down (mucs3p 1), mucs3p 0 down
Может у кого-нибудь из вас, коллеги, будет идея, что тут можно еще сделать/где посмотреть, чтобы SAP снова стал общаться с базой данных?
Заранее спасибо, Полина

Нота 1817091 - SYB: Could not load SYB library sybdrvodb64.dll. when connecting to a Sybase ASE database

sap2me, спасибо большое за ответ. Но я же писала, что этот ноте я видела и установила sybase client заново. К сожалению, положительных результатов это не принесло

Я бы посмотрел в сторону переменных среды окружения и наличия библиотек по путям, которые может просматривать, хотябы, r3trans.
Начните с path. Глобальной и юзерской.

Посмотрела еще вчера, но ничего подозрителъного не обнаружила. SUM вроде бы ничего не потер:
User variable (user <sid>adm):
PATH=E:\usr\sap\S3P\DVEBMGS05\exe;E:\usr\sap\S3P\DVEBMGS04\exe;E:\usr\sap\S3P\DVEBMGS00\exe;E:\sybase\S3P\ASE-16_0\jobscheduler\bin;E:\sybase\S3P\ASE-16_0\dll;E:\sybase\S3P\ASE-16_0\bin;E:\sybase\S3P\OCS-16_0\lib3p64;E:\sybase\S3P\OCS-16_0\lib3p;E:\sybase\S3P\OCS-16_0\dll;E:\sybase\S3P\OCS-16_0\bin; E:\usr\sap\S3P\SYS\exe\uc\NTAMD64;\\mucs3p\sapmnt\S3P\SYS\global\syb\NTAMD64\sybodbc;E:\sybase\S3P\OCS-16_0\bin;E:\sybase\S3P\ASE-16_0\jobscheduler\bin;E:\sybase\S3P\ASE-16_0\bin;E:\sybase\S3P\ASE-16_0\dll;E:\sybase\S3P\DBISQL-16_0\bin;E:\sybase\S3P\OCS-16_0\dll;E:\sybase\S3P\OCS-16_0\lib3p64;E:\sybase\S3P\OCS-16_0\lib3p;E:\usr\sap\hdbclient;E:\usr\sap\S3P\SUM
system variables:
PATH=E:\sybase\S3P\SCC-3_3\bin;C:\ProgramData\Oracle\Java\javapath;E:\usr\sap\S3P\DVEBMGS00\exe;E:\sybase\S3P\ASE-16_0\jobscheduler\bin;E:\sybase\S3P\ASE-16_0\dll;E:\sybase\S3P\ASE-16_0\bin;E:\sybase\S3P\OCS-16_0\lib3p64;E:\sybase\S3P\OCS-16_0\lib3p;E:\sybase\S3P\OCS-16_0\dll;E:\sybase\S3P\OCS-16_0\bin;E:\usr\sap\S3P\SYS\exe\uc\NTAMD64\\mucs3p\sapmnt\S3P\SYS\global\syb\NTAMD64\sybodbc;E:\sybase\S3P\DBISQL-16_0\bin;C:\Program Files\CommVault\Simpana\Base;C:\Windows\System32

pollik
меня смущает один факт - переменная, которую Вы выделили, является технической шарой для работы SAP в Windows.
я ведь правильно понял, что именно там лежит эта библиотека?
НО!
1. более нет ни одной строки подобного рода в переменной
2. а работает ли эта шара? а видит ли её R3trans?
3. а правильные ли полномочия доступа на ней?

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

З.ы. ну и в качестве workaround: бросьте dll-ку в DVEBMGSnn\exe и SYS\exe, чтобы она попала в каталоги ядра.

ну саму библиотеку на дисках вы нашли? она в одном из указанных вами каталогах?

суть ноты 1817091 не в том, что вам тупо заново нужно переустановить софт. А в том, что софт не находит библиотеку по одному из своих путей. улавливаете разницу?

шрам, sap2me, вы правы. Спасибо за то, что подвинули меня на размышления в нужном направлении. Оказалось вот что:
R3trans искал sybdrvodb64.dll или может еще какие, связанные с ним dll в DVEBMGSnn\exe, но не нашел иx там после того, как мой SUM сначала стер весь kernel, а потом скопировал его обратно скорее всего с SYS\exe, где dll-filov Sybase clienta нет (в фазе MAIN_PROFEND/SUBMOD_INSTNR_REV/MOD_INSNR_POST насколько я понимаю). Т.е. на мой взгляд это bug SUM10SP16 PL02. Оказалось, что в моем случае надо было вручную скопировать всю директорию E:\usr\sap\S3P\SYS\global\syb\NTAMD64\sybodbc v DVEBMGSnn\exe, после чего R3trans перестал выдавать ошибку и SUM тоже заработал дальше.
Всем огромное спасибо за советы!

pollik
хорошо, что все получилось
однако, кмк, Вы не совсем правы
Вы пошли по пути workaround, НО!

ODBC клиент, по своей идеологии, и не должен входить в kernel и соответственно не должен попадать в DVEBMGSnn\exe при отработке sapcpe, который как раз и копирует обновлённое ядро на место его запуска DVEBMGSnn\exe из каталога sapmnt\SID\exe
Этот клиент должен лежать отдельно, дабы его можно было обновлять независимо от ядра и не терять при манипуляциях с ядром (в ядре есть своя библиотека для коннекта к БД, как правило).

Поэтому, я все-таки повторно рекомендую уделить внимание переменной среды - PATH и добиться того, чтобы эта библиотека "искалась" по тому пути, куда она инсталлируется по нотам и рекомендациям (E:\usr\sap\S3P\SYS\global\syb\NTAMD64\sybodbc).

Шрам, +100500

2 ТС: постарайтесь сделать все правильно, чтобы в следующий раз опять не заниматься поиском решения.

шрам, avlag, вот и я думала, что клиент не должен входить в kernel и не обязан попадать в DVEBMGSnn\exe при отработке sapcpe. Но вы знаете, я посмотрела на других наших системах, где у нас тоже Sybase и там, как ни странно именно эти фаилы клиента были в DVEBMGSnn\exe, v SYS\exe иx не было нигде. И я уверена, что никто из моих коллег их туда вручную не копировал. Скорее всего, когда делается обновление клиента, при перезапуске SAP (как рекомендуется в ноте 1817091) нужные фаилы копируются именно в DVEBMGSnn\exe. В моем случае, так как я была еще в execution фазе, то не могла перезапустить систему. В обшем в следующий раз, когда буду обновлять клиента, посмотрю внимательно, что там происходит.
PATH=\\mucs3p\sapmnt\S3P\SYS\global\syb\NTAMD64\sybodbc я проверяла, все отлично работает, такого же плана путь есть и на другой системе в PATH, и там все работает. Но на всякий случай, я могу изменить его. Я все же сколоняюсь к тому, что SUM 16 не чисто работал.
avlag, что я с Вашей точки зрения сделала неправильно?

С моей точки зрения вы сделали неправильно, что пошли по пути "все и так работает".
Дело в том, что сейчас вы не знаете, как все планировалось SAP'ом на самом деле. И при очередном апгрейде ядра/системы/клиента базы, вы можете опять попасть в такую же ситуацию. Когда обновлятор не поймет того, что в системе не по его правилам, и пристрелит ненужное с его точки зрения.
А если рассматривать ситуацию шире, то при смене человека, настраивавшего текущее состояние, на другого, который не в курсе, что "кое-что в системе может быть не совсем по стандарту", новый человек попадет в такую же ситуация, как и вы.
Поэтому или надо до конца разобраться почему и что произошло и привести к стандарту, или четко документировать свои действия для будущих поколений (да и для себя тоже)

Я не могу точно сказать, как это должно выглядеть в вашем случае (Sybase/Win), но, к примеру, с обновлением клиента Oracle под *NIX-системами можно получить забавные результаты, если клиент используется не линком на определенную версию, а напрямую из исходной папки.

Как-то так