ORA-00445 (фоновый процесс PMON не запущен)
Эта ошибка произошла с Oracle 8.1.7. Она выдается, если сервер был запущен с помощью обычного скрипта startsap (например, startsap_majestix_00) от имени пользователя prdadm.
Возможный способ обхода – запускать сервер базы данных от имени пользователя oraprd с помощью svrmgrl:
% svrmgrl
SVRMGR> connect internal;
SVRMGR> startup;
SVRMGR> exit
ORA-12546 (запускайте процесс прослушивания с правильными правами)
Запускайте процесс прослушивания Oracle от имени пользователя oraids следующими командами:
# umask 0; lsnrctl start
В противном случае, вы можете получить сообщение об ошибке ORA-12546, поскольку сокеты не будут иметь нужных прав доступа. См. SAP Note 0072984.
ORA-27102 (не хватает памяти)
Эта ошибка произошла при попытке использовать значения MAXDSIZ и DFLDSIZ больше 1 Гбайта (1024x1024x1024). Кроме того, мы получили Linux Error 12: Cannot allocate memory.
10.7.13.10. [DIPGNTAB_IND_IND] в ходе R3SETUP
В общем случае, см. SAP Note 0130581 (прекращается работа R3SETUP на шаге DIPGNTAB). В ходе установки IDES-версии по каким-то причинам процесс установки использовал вместо правильного имени системы SAP, ''IDS'', пустую строку, "". Это приводит к небольшим проблемам при доступе к каталогам, поскольку пути генерируются динамически на базе SID (в данном случае, IDS). Поэтому вместо обращения к:
/usr/sap/IDS/SYS/...
/usr/sap/IDS/DVMGS00
используются следующие пути:
/usr/sap//SYS/...
/usr/sap/D00
Чтобы продолжить установку мы создали ссылку и дополнительный каталог:
# pwd
/compat/linux/usr/sap
# ls -l
total 4
drwxr-xr-x 3 idsadm sapsys 512 May 5 11:20 D00
|
|
|
drwxr-x--x 5 idsadm sapsys 512 May 5 11:35 IDS
lrwxr-xr-x 1 root sapsys 7 May 5 11:35 SYS -> IDS/SYS
drwxrwxr-x 2 idsadm sapsys 512 May 5 13:00 tmp
drwxrwxr-x 11 idsadm sapsys 512 May 4 14:20 trans
Мы также нашли документы SAP Notes (0029227 и 0008401), описывающие это поведение. Мы не столкнулись с подобными проблемами при установке SAP 4.6C.
10.7.13.11. [RFCRSWBOINI_IND_IND] в ходе R3SETUP
В ходе установки SAP 4.6C, эта ошибка возникла в результате другой ошибки, произошедшей ранее по ходу установки. В данном случае придется просмотреть соответствующие журнальные файлы и устранить исходную проблему.
Если после просмотра журнальных файлов выявлена только эта ошибка (проверьте SAP Notes), можно поменять STATUS соответствующего шага с ERROR на OK (в файле CENTRDB.R3S) и перезапустить R3SETUP. После установки надо выполнить отчет RSWBOINS из транзакции SE38. Дополнительную информацию о стадиях RFCRSWBOINI и RFCRADDBDIF см. в SAP Note 0162266.
10.7.13.12. [RFCRADDBDIF_IND_IND] в ходе R3SETUP
Здесь применяются те же ограничения: проверьте путем просмотра журнальных файлов, что эта ошибка не вызвана какими-то предыдущими проблемами.
Если подтверждается, что применим документ SAP Note 0162266, просто поменяйте STATUS соответствующего шага с ERROR на OK (в файле CENTRDB.R3S) и перезапустите R3SETUP. После установки надо выполнить отчет RADDBDIF из транзакции SE38.
Sigaction sig31: File size limit exceeded
|
|
|
Это сообщение об ошибке выдается в ходе запуска процессов SAP disp+work. Если SAP запускается скриптом startsap, запускаются отдельные подпроцессы, выполняющие грязную работу по запуску всех остальных процессов SAP. В результате, сам скрипт не получит уведомления, если что-то пойдет не так.
Чтобы проверить, нормально ли запустились процессы SAP, посмотрите на состояние процессов с помощью команды ps ax | grep SID, которая выдаст список всех процессов Oracle и SAP. Если похоже, что некоторых процессов не хватает или вы не можете подключиться к системе SAP, просмотрите соответствующие журнальные файлы, которые можно найти в каталоге /usr/sap/SID/DVEBMGSnr/work/. Надо просматривать файлы dev_ms и dev_disp.
Сигнал 31 выдается, если объем памяти, совместно используемой Oracle и SAP, превосходит заданный в файле конфигурации ядра, и от него можно избавиться, указав большее значение:
# большее значение для производственных систем 46C:
options SHMMAXPGS=393216
# меньшее значение, достаточное для 46B:
#options SHMMAXPGS=262144
Сбой при запуске saposcol
Есть ряд проблем с программой saposcol (версии 4.6D). Система SAP использует saposcol для сбора данных о производительности системы. Эта программа не нужна для использования системы SAP, так что проблему можно отнести к несерьезным. Более старые версии (4.6B) работают, но собирают не все данные (многие вызовы просто возвращают 0, например, для использования процессора).
|
|
|
Дополнительные сведения
Если вы интересуетесь, как обеспечивается двоичная совместимость с Linux, этот раздел для вас. Большинство материала взято из электронного письма, адресованного Terry Lambert <tlambert@primenet.com> в Список рассылки, посвящённый неформальным беседам о FreeBSD (http://lists.FreeBSD.org/mailman/listinfo/freebsd-chat) (ID письма: <199906020108.SAA07001@usr09.primenet.com>).
Как все это устроено?
FreeBSD поддерживает абстракцию, называемую ''загрузчик выполняемых классов''. Фактически, он является первой стадией системного вызова execve(2).
На самом деле, FreeBSD имеет список загрузчиков вместо одного, завершающийся загрузчиком #! для запуска любых командных интерпретаторов и скриптов.
Исторически сложилось, что единственный загрузчик в UNIX системах проверял ''магическое число'' (чаще всего первые 4 или 8 байт файла), чтобы определить, известен ли формат двоичного файла системе, и если да, то вызвал соответствующий загрузчик.
Если файл не опознавался системой как двоичный, системный вызов execve(2) возвращал ошибку, и текущий командный интерпретатор начинал выполнять файл как скрипт.
|
|
|
По умолчанию скрипт выполнялся ''текущим командным интерпретатором''.
Позднее, sh(1) был модифицирован, так, чтобы проверять первые два символа в файле, и если они оказывались :\n, то файл выполнялся как сценарий для csh(1) (утверждается, что SCO были первыми, кто сделал эту модификацию).
FreeBSD сейчас ведет себя по-другому: пробегает по списку загрузчиков,включающему специальный загрузчик #!, который вызывает нужный интерпретатор, указанный после этих символов до следующего пробела, или /bin/sh, если не нашел подходящего.
Для поддержки Linux ABI FreeBSD ищет магическое число, соответствующее двоичному файлу ELF (на этой стадии не различаются FreeBSD, Solaris, Linux или любая другая ОС поддерживающая формат ELF).
Далее, ELF-загрузчик определяет ''марку'' (brand) двоичного файла ELF (специальный комментарий в ELF-файле, отсутствующий в двоичных файлах ELF SVR4/Solaris).
Соответственно, Linux программы должны быть ''маркированы'' для Linux (например, с помощью утилиты brandelf(1)):
# brandelf -t Linux file
Когда это сделано, загрузчик ELF выявит марку Linux в файле.
Когда ELF-загрузчик находит ''марку'' Linux, он заменяет соответствующий указатель в структуре proc. Все системные вызовы индексируются через этот указатель (в традиционной UNIX системе это массив структур sysent[], содержащий системные вызовы). Кроме того, процесс помечается для специальной обработки вектора обработчиков сигналов, а также ряда других (небольших) исправлений, которые осуществляются специальным модулем ядра для поддержки Linux.
Вектор системных вызовов Linux содержит, среди прочего, список записей sysent[], адреса которых находятся в модуле ядра.
При выполнении системного вызова из двоичного файла Linux, код обработчика разыменовывает указатель на функцию системного вызова из структуры proc, и получает точки входа системных вызовов Linux, а не FreeBSD.
Плюс ко всему, в Linux–режиме динамически ''изменяется корень'' файловой системы при поиске файлов; фактически так же, как и параметр union при монтировании файловых систем (не путать с unionfs!). Сперва, файл ищется в каталоге /compat/linux/исходное_полное_имя и только затем, в случае неудачи, в /исходное_полное_имя. Это гарантирует, что программы, которым требуются другие программы, смогут работать (например, весь набор инструментальных средств Linux сможет работать в среде поддержки Linux ABI). Это также дает возможность Linux программам выполнять FreeBSD команды, если не найдется соответствующих Linux команд. Например, можно скопировать FreeBSD uname(1) в дерево каталогов /compat/linux, и Linux-программы не смогут разобраться, что они работают не в Linux.
Фактически, имеется ядро Linux в ядре FreeBSD; различные базовые функции, реализующие все услуги ядра, идентичны как в записях таблицы системных вызовов FreeBSD, так и в записях таблицы системных вызовов Linux: операции с файловой системой, виртуальная память, средства доставки сигналов, System V IPC … Единственное отличие в том, что FreeBSD-программы получают интерфейсные функции FreeBSD, а Linux-программы получают интерфейсные функции Linux (в большинстве более старых ОС есть только их собственные интерфейсные функции: функции берутся из статического глобального массива структур sysent[], а не из массива, полученного разыменованием динамически проинициализированного указателя в структуре proc процесса, выполняющего вызов).
Какая же реализация ABI для FreeBSD ''родная''? Это не имеет значения. Единственное различие (на данный момент, в будущем все может и, вероятно, изменится), пожалуй, в том, что функции системных вызовов FreeBSD зашиты в ядро, а для Linux они могут быть либо статически скомпонованы в ядро, либо получаться через модуль ядра.
Да, но можно ли назвать это эмуляцией? Нет. Это реализация ABI, а не эмуляция. Как таковой, эмулятор (или симулятор) отсутствует.
В таком случае, почему же иногда говорят об ''эмуляции Linux''? Чтобы ''насолить'' FreeBSD! Фактически, причина в том, что на момент первой реализации не существовало слова, которое бы точнее описывало этот процесс. Нельзя было сказать, что FreeBSD запускает приложения Linux (без перекомпиляции или загрузки соответствующего модуля ядра это невозможно). Но надо было как-то описать, что загружается — отсюда и ''эмулятор Linux''.
Дата добавления: 2018-10-26; просмотров: 272; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!