30 июля 2010 г.

С днем системного администратора - 2010

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


Поздравляю всех системных администраторов с этим праздником!
Желаю, чтобы следующий год прошел еще продуктивнее, чтобы было поменьше сбоев и аварий и чтобы то, чем Вы занимаетесь, радовало Вас и кормило! ;)

А в дополнение, чтобы тема зря не пропадала, расскажу про кнопочку "ТОС" на серверах компании HP. Для удаленного администрирования сервера HP снабжаются управляющим процессором, который именуется MP (в старых моделях GSP). Отсюда есть такое понятие, как MP console или GSP console. На неё можно попасть локально, через терминальную консоль, или удаленно по telnet, если настроен удаленный доступ. MP console имеет свой набор команд, с помощью которых можно посмотреть логи сервера, подать сигналы "перезагрузка", "останов" серверу и так далее. Иногда возникает ситуация, когда сервер не хочет грузится, ну ни в какую, и причину не называет. Вот тогда может прийти на помощь кнопочка "Reset MP", она обычно выполняется в виде утопленной в корпус "пипочки" на задней части сервера. Нажимаете кнопочку, например, карандашом, и сервер производит "глубокую перезагрузку". Очень часто после этого начинает работать. ;)
Так вот, на днях точно в такой же "нокаут" ушла машинка RX2620. Исследование задней стороны сервера показало, что MP console на данную машине не установлена, а есть загадочная кнопка "TOC". Схожесть строения с "Reset MP" навела меня на мысль, что и функциональность она имеет схожую. Нажатие её помогло реанимировать сервер, а поиск информации показал, что "кнопка TOC посылает MP команду tc (Resets through transfer of control)", а "Trancfer of control" = TOC. В общем, кнопка работает также. :)

Вывод. Если сервер не хочет грузиться по непонятной причине, не торопитесь звонить в службу поддержки, нажмите "Reset MP", "Reset GSP" или "TOC". Может помочь. :)

Автор: Шиболов Вячеслав Анатольевич


28 июля 2010 г.

Ключ инсталляции/апгрейда

При установке системы SAP, основанной на SAP NetWeaver, программа установки (SAPINST) на одном из этапов запрашивает ключ инсталляции/апгрейда.


Подробности про этот ключ описаны в SAP note # 805390.

Существует 2 способа получить ключ:
  • официальный, который описан в SAP note # 811923. Он подразумевает, что у Вас установлена система SAP Solution Manager, в которой Вы можете сгенерировать ключ для установки новой системы. Подробности данного способа описаны мной в небольшой инструкции (zip-архив, 139 Кб).
  • неофициальный, почти хакерский. ;) Если под рукой нет системы SAP Solution Manager и, не смотря на пропаганду компании SAP AG, нет желания включать её в ландшафт, можно обойти проверку в программе установки системы (SAPINST). Процедура следующая: 
  1. После того, как программа установки выдаст экран с запросом ключа инсталляции/апгрейда, необходимо остановить программу установки;
  2. Войти в директорию установки (обычно это путь типа: C:\Program Files\sapinst_instdir\ERP\SYSTEM\ORA\CENTRAL\AS) и найти файл control.xml;
  3. Открыть файл на редактирование (например, программой MS Word) и найти в тексте блок следующего вида:
     var retval = eval(installer.invokeModuleCall(call));
     Trace("Installer", "Installer.checkSolManKey() done: ", retval);
     return retval;

     заменить последнюю строчку на return true;
      и сохранить файл control.xml;

  4. Запустить программу установки системы (SAPINST) и продолжить предыдущую инсталляцию:

  5. На экране запроса ключа инсталляции/апгрейда ввести любой набор цифр и продолжить установку:

Автор: Шиболов Вячеслав Анатольевич

23 июля 2010 г.

Старые журналы событий SAP и ORACLE

Сегодня мы поговорим о старых записях в журналах событий процессов SAP и ORACLE.

Процессы ORACLE:
  1. Лидером в рейтинге "самый бесполезный и быстрорастущий журнал событий" является лог процесса LISTENER. :) Файл журнала располагается в директории /oracle/<SID>/<ora_version_bit>/network/log и имеет имя - listener.log. В системе с несколькими диалоговыми инстанциями всего за год файл может "распухнуть" до 1,5 Гб!


    В Unix-е очистить его очень легко. Достаточно выполнить команду # > listener.log . В Windows придется перезапускать сервис LISTENER, а во время его останова - удалять содержимое файла. Либо поиграться с программа типа unlocker, но сервис для нормальной работы перестартовать потом все равно придётся. Вот тебе и первая выгода (с) ;)

  2. Основной журнал событий базы данных ORACLE - alert_<SID>.log. Место обитания - директория /oracle/<SID>/saptrace/background/. Растет не так быстро, но при долгой работе базы данных имеет размер исчисляемый десятками Мб. Автоматически не обнуляется. Значит этим должны заниматься мы. Какие плюсы от небольшого размера файла? Они очевидны - меньшие требования к дисковому пространству, удобство в анализе. Очищать целиком, право, не стоит: записи в нем, в отличии от предыдущего лога, очень важны. В Windows процедура понятна: останавливаете СУБД, открываете файл текстовым редактором, удаляете лишние строки, сохраняете файл, запускаете СУБД. Как хорошо, что продуктивных систем на Windows все таки не так уж много. ;) В Unix можно поиграться двумя комбинациями команд: wc и split. Первая команда (# wc -l alert_<SID>.log) поможет нам понять сколько всего записей в данном файле. Хорошо бы еще знать дату первой и последней записей. После этого делите файл на части командой # split -line_count alert_<SID>.log. Результат команды - несколько файлов, содержащие по line_count строк из файла alert_SID.log. Анализируете файлы. Содержащие старые ненужные строки удаляете. Оставшийся можно делить еще. В итоге, командой mv заменяете текущий файл alert_<SID>.log полученным укороченным.
Процессы SAP:
  1. В системе SAP есть отличный автоматический процесс (задание) под названием CleanUpLogs, который можно (нужно) запланировать в транзакции DB13 с некой периодичностью (например, 1 раз в неделю). Параметры хранения журналов событий и записей указываются либо в профайле init<SID>.dba (в случае использования SAPDBA (версия системы ниже SAP 4.6С)), либо в init<SID>.sap (использование BRTOOLS). Что и как удаляется можно посмотреть в данных профайлах и в журнале выполнения задания в DB13. Информацию можно почерпнуть в нотках - # 204499 и # 403704.





  2. Если база данных находится в режиме ARCHIVELOG и для создания резервных копий используются утилиты SAP: brbackup/brarchive, то стоит обратить внимание еще на один журнал системы. Это файл /oracle/<SID>/saparch/arch<SID>.log, в котором хранятся записи о том, на какой носитель и когда был скопирован тот или иной оффлайн журнал базы данных ORACLE. Старые записи из этого файла тоже можно почистить. Использовать можно те же способы, что и для файла alert_<SID>.log. 

  3.  Ну и еще можно заглянуть в транспортную директорию - /usr/sap/trans/. Там есть директория log, которую можно проверить на предмет существования в ней старых журналов, которые можно сархивировать в другое место или просто удалить. Ну и директория /usr/sap/trans/EPS/in, в ней хранятся в распакованном виде все пакеты поддержки, которые были установлены на систему или стоят в очереди на установку. Те которые уже были установлены просятся в /dev/null. ;)