Ошибка инсталяции oracle под Linux

Ставил oracle 10g on Linux (oracle linux 5 64bit). При запуске инсталлера такая ошибка:

bash-3.1$ ./runInstaller
Starting Oracle Universal Installer…No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2008-02-29_10-43-09AM. Please wait …bash-3.1$ Exception in thread “main” java.lang.UnsatisfiedLinkError: /tmp/OraInstall2008-02-29_10-43-09AM/jre/1.4.2/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at sun.security.action.LoadLibraryAction.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.NativeLibLoader.loadLibraries(Unknown Source)
at sun.awt.DebugHelper.<clinit>(Unknown Source)
at java.awt.Component.<clinit>(Unknown Source)

Solution: install 32bit package libXP-1.0.0-8.i386.rpm (check note 443617.1)

Эта ошибка вызвана отсутствием пакета который должен ставится по умолчанию. Такое происходит когда при инсталяции linux, выбирается Custom и лишние пакеты не включаются. Кстати oracle рекомендует (может мягко сказано) выбор типа инсталляции Workstation. Смотрите note 401167.1:

“However, de-selecting any “default RPM” groupings or individual RPMs can result in failed RDBMS installation attempts, and as such, is not supported by Oracle Support Services. “

Мистическая ошибка инсталляции 10g on Linux :)

Расскажу забавный случай инсталляции oracle 10g on linux. Админы поготовили Linux сервер и отдали мне на установку базы. Нужно было ставить 10g 64bit. Запускаю installer все нормально, но в конце установки появляются сообщения что невозможно залинковать объекты, netca тоже не запускается.

Запускаю ntetca в ручную, ошибка:

bash-3.1$ netca

UnsatisfiedLinkError exception loading native library: njni10

java.lang.UnsatisfiedLinkError: jniGetOracleHome

at oracle.net.common.NetGetEnv.jniGetOracleHome(Native Method)

at oracle.net.common.NetGetEnv.getOracleHome(Unknown Source)

at oracle.net.ca.NetCA.main(Unknown Source)

Oracle Net Services configuration failed. The exit code is -1

Нахожу ноту Note:308788.1, не помогает. Проверяем еще раз все ли пакеты поставлены, все на месте, переменные окружения. Тут закрадываетя подозрение, а какая битность линукса? Ну конечно 32bit! 🙂 Это из раздела – сисадмины шутят 🙂

Как определить битность системы? Смотрите Note:469497.1 В кратце выполяем uname -a и смотрим первую строку, правая часть, там должно фигурировать 64, для 64 bit linux.

Solution: Problem caused by installing 64bit oracle software on 32bit os linux.

Заметки с hotsos’06. Искусство решения проблем.

Докладчик: Kerry Osborn

Эта тема посвящена решению проблем в компьютерных системах. Автор Kerry Osborn, был много лет руководителем одной из консалтинговых компатий и по своему роду деятельнеости ему приходилось работать со многими проффесионалами, умными и якрими людьми, однако он заметил, что способность быстро решать сложные проблемы, очень слабо коррелирует с интеллектуальными способностями или огромным техническим опытом. Тогда почему же некоторые люди лучьше решают проблемы, чем другие, имея одинаковый уровень интеллекта, этику работы и тех. основы?

Автор Керри Осборн, пытался ответить на этой вопрос не один год, надо заметить что он не психолог, а человек который как и мы непосредственно занимается решением проблем, поэтому это больше заметки опытного человека, чем подтвеждение теории прсихологии.

Для бизнесс критической системы, любая проблема имеет прямую связь с убытками, поэтому основная задача – решить проблему как можно быстрее. Пусть это иногда не решает суть проблемы, но важно как можно быстрее восстановить работу, после чего можно уже заняться сутью.

Процесс решения проблем имеет следующие этапы.

  • Дефинировать проблему. Достаточно странно, но этот шаг один из самых сложных. Для технических людей, может быть очень сложно оценить насколько проблема имеет влияние на бизнес. Мы больше думаем в зачениях техн. показателей, а не влиянии на бизнесс процессы. Это важный вопрос, потому что, от того как мы продефинируем проблему, зависит набор конечных решений.
  • Сбор данных. Основная проблема – отделить зерна от плевел. Это похоже на работу следователя, он собирает все свидетельства которые доступны, и потом отбирает из них факты. Т.е. важно непредвзято собрать все доступные свидетельства.
  • Постулирование причин. Та информация, которая была собрана, должна быть подтверждена на опыте, тоже относиться к предположениям, которые были сделаны. Основная проблема – в том, чтобы не перейти к этому этапу слишком быстро с предыдущего этапа, с недостаточной информацией.
  • Возможные решения. На основе предположений сделанных на пред. этапе., вырабатываються возможные решения. Этот этап требует творчества, чтобы получить как можно больше решений.
  • Последовательность применения решений, один из важных шагов который определяет как быстро мы прийдем к решения проблемы.

Советы по решению проблем.

• Нарисовать схему

• Использовать аналогии

• Изменить определение проблемы.

• Взять паузу. Было замечено, что если решение не приходит, имеет смысл отстраниться на некоторое время, и тогда решение или идея как бы всплывает сами.

• Вербализация проблемы. Обсудить проблему.

• Усомниться в традиционном решении. Если проблема не решаеться, можно попробовать противоположный от традиционного подход.

• Усомниться в необходимости. Самый быстрый способ, что либо сделать – не делать это.

• Принять неопределенность. Было замечено что люди которые хорошо себя чуствуют в ситуации неопределенности – лучьше решают проблемы.

• Не поддаваться стрессу. Стресс очень плохо влияет на творчество, но к сожалению наша работа связана сос стрессом, мы не может этого избежать, но мы можем научиться управлять стрессом.

Негативные поведенческие привычки:

  • У меня есть молоток и все выглядит как палец. Или симптом лени. У меня уже есть молоток в руках, зачем тратить время, чтобы взять плоскогубцы? Пример. Приложение обращаеться к базе считывает всю таблицу целиком, потом выбирает необходимые записи.
  • Шпион против шпиона. Есть люди, которые держат свои знания в секрете, это дает им чувство безопастности относительно своего места работы. Или еще хуже – они используют свои знания как оружие. Эта стратегия показывает эффектвность для них какоето время, но почти во всех случаях заканчиваеться плачевно. Взаимосотрудничество – очень хорошее средство для генерации идей. Это ключ к шагу генерирования идей. Чем больше вариантов решений, тем больше шансов на успех.
  • Наблюдатели не-гориллы. Был проведен эксперимент. Группу людей попросили наблюдать за баскетбольным матчем в течении 30 сек – и считать количество пассов – передач мяча. Потом их спросили –не видили ли они что нибудь странного? Только несколько человек подняли руки – они видели то что для других было большим сюрпризом- в середине фильма – на середину зала вышел человек переодетый в гориллу и начал бить себя в грудь. Часто бывает, что человек со свежим взглядом, сразу указывает на очень логичное решение проблемы, над которой бились часами. Вообщем – часто попасть под влияние деталей достаточно легко.
  • Гудини. Был знаменит способностью выбираться из любой тюрьмы на несколько часов. Однажды, в одной из попыток, он пытался открыть замок, но ему это не удавалось сделать в течении нескольких часов. Когда же он совсем отчаялся и сел на пол прислонившись к двери спиной, дверь сама открылась – т.к. была просто не запертой. Он попался на собственное предположение – пытаясь сделать невозможное – открыть незапертый замок.
  • Стресс. Психологами было проведено исследование – двум группам было дано задание, но дной группе сказали, что на выполнение этой задачи требуеться 1 минута, а другой 3 минуты. Однако в обеих группах, выполенение было прервано ровно через 1 минуту. Оказалось, что в группе которая думала что у них есть больше времени, задание было выполнено в 2 раза лучьше чем в первой, хотя время выполнения было одинаково.
  • Ошибки могут рассматриваться как неудача или как возможнось научиться. Например, в компании 3M, разрабатывали очень сильный клей, но в результате получили очень слабый, вместо того чтобы его выкинуть, он лег в основу для 3M отрывных заметок. Люди успешные в решение проблем – люди любознательные и используют вызовы как возможность научиться.
  • Страус. Это ситуация когда проблемы игнорируються и не решаються, надеясь на то что они решаться сами. Иногда действительно, в сложных системах, при опр. обстоятельствах, внезапно моджет появиттся проблема, и так же внезапно исчезнуть, однако зачастую эти проблемы появляються все чаще и чаще, пока не настанет момент, когда их игнорировать уже возможности не будет. Поэтому лучьше всего решать проблему тогда когда она появляеться
  • Основная характеристика здесь – завышенная уверенность в себе. Пример, ставить в продуктион изменения без тестирования на тестовой. Хорошая доза осторожности с здоровым риском, повысят стабильность системы.
  • Крестоносец. Помню ходили слухи, что есть памады вызавающие рак, и чтоб проверить надо потереть золотым кольцом. Тоже самое – в компютероном мире, существует множество мифов. Люди успешные в решении проблем, стремяться протестировать сущесвующие общепризнанные взгляды на вещи.
  • Маньяк. Человек который стремиться довести все до конца без учета необходимости. Например потратить неделю чтобы выйграть 1% в производительности

Решение проблем это неотъемлемая часть нашей работы, над которой мы зачастую не задумываемся. Мы можем бысто и качественно решать проблемы если сможем учитывать вышепрведенные моменты.

Впечатления о конфереции hotsos’06, Даллас, США

В марте, 2006 года, с 5-9 числа, предоставилась возможность посетить конференцию HOTSOS по настройке производительности баз Oracle, которая проходила в Далласе, штат Техас, USA. Эта конференция устраиваеться уже несколько лет подряд и хорошо себя зарекомендовала. Организатором конференции является консалтинговая фирма hotsos, которая специализируеться в области настройки производительности oracle систем и проходила в конференс зале одной из гостиниц.

На конференции присутствовали около 500 человек участников. Из выступающих, выступали наверное человек 6 технических людей из oracle, 1 человек из компании SUN, а также целый ряд всемирно известных экспертов –J. Lewis, T. Kyte и др. Приятно был удивлен втретив своего земляка Юрия Великанова, который также выступал на конференции с очень интересной темой. Приятно было, также увидеть выступление замечательного специалиста Tanel Poder из Эстонии.

Лекции проходили в двух сессиях параллельно, с 8.30 до 18.00, каждый день. Интересный момент происходил в конце каждого дня, на сцену ставили большой стол, за который садились ряд экспертов , и можно было задать любой вопрос этому президиуму. J. Lewis, на вопрос о будующем баз данных, спрогнозировал, что скоро мы будем запускать oracle на мобильных телефонах, там можно будет делать все что угодно, кроме разве что нормально позвонить 🙂 Вообщем было очень много информации, очень интересно и полезно. Было, конечно, что и не понарвилось. Несколько выступлений, на мой взгляд, были очень низкого уровня. На уровне студента который начал подготовеу за ночь до экзамена. Меня тогда это очень удивило, особенно на фоне многих ярких и интересных презентаций.

В целом, мероприятие очень понравилось, если есть возможность обязательно стоит посетить.

Защелки. (Latching)

Защелки используются для защиты структур памяти от записи другим процессом. По смыслу это тоже самое что и локировка, но защелка имеет более ограничивающий характер – eсли процесс залокировал от записи ресурс памяти с помощью защелки, то другие процессы не могут даже читать этот ресурс. Защелка также более простая структура, за счет отсутствия поддержки очередей ожидания. Здесь также используются простые и атомарные операции работы с CPU (tests and sets, load and clear, compare and swap). Благодаря этому, использование защелки требует мало ресурсов и поэтому эффективнее других механизмов защиты памяти.

Защелка применяется в основном для защиты памяти SGA, там где требуется скорость, но по причине эксклюзивного доступа, защелка не должна быть использована продолжительно. (Эксклюзивный доступ как пример источника проблем хорошо иллюстрирует проблемы с парсингом shared pool’a, где защелка держится на весь период парсинга)

Если процесс хочет получить доступ к ресурсам защищаемым защелкой, то используются два режим ожидания: willing to wait или immediate. В первом случае, процесс предполагает что ресурс скоро освободится, поэтому он решает ждать. В этом случае, для ожидания, процесс делает холостую нагрузку на процессор. Для операционной системы, однако, эта нагрузка вполне реальная загрузка процессора которая влияет на работу всей системы. Зачем же тогда для ожидания использовать процессор таким влияющим на работу другим способом? Почему бы просто не освободить процессор и сделать его доступным для других процессов?

Дело в том, что бы освободить процессор необходимо переключение контекста процессора. Переключение контекста – дорогостоящая операция: освобождение значений регистров, их сохранение, поиск следующего процесса и заполнение значений регистров, поиск и изменение структур ядра, которые защищены локировками оп. системы. Поэтому в большинстве случаев, простое ожидание на CPU, выгоднее чем переключение контекста (кончно, в случае когда выполняется условие кратковременности использования защелки).

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

Основные задачи настройки Shared Pool

SharedPool (SP) это область памяти которая используется для кэширования таких структур как объекты data dictionary, sql код, планы. SP состоит из двух основных областей: library cache для кэширования кода and data dictionary cache для кэширования информации об объектах базы данных. Когда пользователь запускает sql то информация об объектах, которые этот sql задействует, выбирается из таблиц описывающих все объекты базы – data dictionary. Так определяется структура таблиц, проверяются имена колонок и их типы, проверяется есть ли у вас права на запрашиваемые операции. Такая операция называется парсингом (parsing). После парсинга, оптимизатор должен определить самый лучший план выполнения запроса. Это происходит путем анализа статистики (которая тоже хранится в dd) и составлением многих вариантов планов с их стоимостью, на основе которой выбирается лучший план выполнения. Такой план выполнения для каждого sql хранится в Library Cache. Как вы видите, эти операции требуют значительных ресурсовэто в первую очередь CPU и управляющие структуры памяти Эти ресурсы можно сэкономить, если всю эту информацию хранить в памяти и в случае повторного запроса, он выполнится значительно быстрее.

Как сразу видно, кэширование такой информации имеет смысл для сред в которых очень часто выполняются одинаковый, стандартизированный код, те OLTP (Online Transaction Processing). Пример OLTP запросов может быть следующий. Пользователь заполняет информацию о клиенте, и выбирает нужный счет из списка всех счетов конкретного клиента. Чтобы получить этот список пользователь направляет запрос в базу данных, где существует таблица со списком счетов. Такой запрос должен выполнится в доли секунды иначе пользователь не сможет нормально работать, потому что таких списков на одной форме может быть с десяток. Как видим, в таких системах очень критично время отклика, те то как быстро клиент получит ответ на свой запрос. Так как сами запросы часто короткие, то львиную долю времени может занимать парсинг, до 90% от общего времени выполнения. Поэтому, в таких системах, оптимизация кэширования имеет очень большое значение.

Однако существует другой тип систем, где кэширование посредством sp не так важно. Это системы отчетности или DWH. Время выполнения запросов в этих системах может быть очень большим, это может быть несколько минут, или даже часы. А время подготовки самого запроса относительно его выполнения очень небольшое и может достигать несколько секунд, что приемлемо. Если пользователь готов ждать минуты, то несколько секунд он просто не заметит. Поэтому улучшать и настраивать эту область кэширования просто не целесообразно. Кроме того, запросы в таких системах сложно стандартизировать.

Основная задача настройки SP это уменьшение парсинга. Когда объект не найден в кеше, нужно потратить очень большое количество ресурсов, на один простой sql может приходится 20-30 latch локировок и значительное количество CPU. В многопользовательских системах конкуренция за эти ресурсы может вызвать сильные замедления работы. Поэтому первая задача настройки SP, это уменьшение hard parsing..

Основные области настройки:

1. Повышение кооперативного использования объектов в памяти

a. Приведение стиля написания sql к одному стандарту. Это связано с тем, что два одинаковых по смыслу запроса, но отличающихся, допустим пробелом, oracle будет воспринимать как два разных запроса. Так происходит потому, что для поиска одинакового запроса используется hash функция на основе текста запроса.. Если текст отличается, то и соответственно результат hash функции будет различным.

b. Использование bind variables. Здесь нужно заметить, что Bind variables хорошо применимы для oltp систем, где большинство sql запросов стандартизированы, однако для DWH приложений их применение может оказаться невыгодным, тк отсутствие конкретных значений аргументов, влияет отрицательно на вычисление корректного плана выполнения.

2. Создание условий для хранения (кэширования) SQL в памяти

a. Выделение необходимого объема памяти. Это предотвращает удаление объектов из памяти по причине нехватки памяти. Однако слишком много памяти может привести к снижению производительности, по причине слишком длинного списка объектов (LRU).

b. Проведение обслуживающих работ в периоды низкой активности. DDL операции и такие как сбор статистики, truncate, grant вызывают инвалидацию объектов, что приводит к hard pars запросов использующих эти объекты.

3. Уменьшение фрагментации. SP рассчитан на кэширование небольших блоков, которые могут понадобится снова. Такие процессы как MTS, кэширование backupа и параллельного выполнения, используют большие блоки, причем эта информация используется только единожды. Это не соотв. назначению SP и поэтому снижает ее эффективность.

a. Использование LARGE_POOL для shared серверов, backup и parallel execution

b. Использование резервирования памяти

c. Уменьшение кол-ва анонимных PLSQL блоков

d. Закрепление (PIN) в памяти больших объектов

Что не помогает:

Простое увеличение памяти не помогает. Если просто увеличить размер памяти для SP и не решать проблемы с запросами – не приводить их к совместно использоваемому виду, то память рано или поздно заполнится снова, и при увеличенном объеме ситуация только усложнится, так как на работу с большим кешем требуется больше ресурсов.

Проблемы с Shared Pool можно чаще всего ожидать сразу после входа системы в production, когда bind variables не используются. Это связано с тем, что на тестовой среде, в однопользовательском режиме, все может прекрасно работать. Однако при повышении количества пользователей, наблюдается значительная конкуренция за ресурсы sp, время выполнения запросов увеличивается в разы и система практически останавливается.

Как видим, SP, является ключевой областью памяти в SGA, неоптимальная работа с которой может привести к значительному замедлению работы всей системы. Поэтому очень важно корректно использовать механизмы кэширования запросов как на стадии разработки, так и в боевом режиме работы системы.