RACChecker

Тема разработки и адаптации приложений под RAC очень обширна и многогранна и затрагивает практически все аспекты создания прикладного ПО для СУБД Oracle Database.
Но, тем не менее, для того чтобы гарантировать что ваше приложение корректно будет работать в RAC, необходимо убедиться, что оно не использует технологии и механизмы которые в RAC в не работают.
Вот перечень этих технологий:

  • каналы (пакет DBMS_PIPE) - не синхронизируются между узлами кластера;

  • глобальные контексты приложений - также не синхронизируются между узлами кластера;

  • сигналы (пакет DBMS_ALERT) - сигналы тоже не синхронизируются между узлами кластера;

  • задания управляемые через пакет DBMS_JOB - крайне не рекомендуется использовать в RAC, поскольку задания этого пакета не поддерживают сервисы, и привязка заданий может быть задана только жестко к узлам, при привязке задания к узлу оно не переживает failover текущего экземпляра, при отсутствии привязки задание может выживать после падения узла (начиная с 10.2.0.3) но запускается при этом на произвольном узле.


    Методы борьбы с вышеперечисленными технологиями мы подробно рассматриваем на нашем семинаре RAC Deep Dive for Developers

    Довольно часто приложение имеет большие объемы PL/SQL-кода (сотни тысяч и даже миллионы строк кода), и вспомнить о том, в каком месте используется тот же DBMS_PIPE крайне сложно: код давно отлажен и работает, а его автор уже давно не работает в компании.
    Для того, что облегчить анализ серверной части кода (хранимых процедур PL/SQL) я разработал утилиту RACChecker. Эта утилита поможет быстро ответить на вопрос: готово ли, в минимальной степени, ваше приложение при переходе в RAC.
    RACChecker анализирует ваш исходный код и находит объекты и строки кода, где вы используете технологии, которые в RAC не работают.

C:\RAC\Utils\RACChecker>RACChecker.exe help=y

RAC Checker for ISV: Release 0.0.1 - Development on 14.09.2008 23:29:23

Utility for check correctly PL/SQL for Oracle RAC

Copyright (c) 2008, Igor Melnikov. All rights reserved.


You can control how RACChecker runs by entering the RACChecker command followed
by various arguments. To specify parameters, you use keywords:

Format: RACChecker parameter=value TYPE=value

Example: RACChecker USERID=scott/tiger@orcl TYPE=PIPE
RACChecker USERID=demo/demo@demo TYPE=ALL

Keyword Description (Default)
--------------------------------------------------
SCHEMAS schemas in which check ALL-for all schemas (ALL)
HELP print this message: Y/N (N)
TYPE object type: PIPE,ALERT,CONTEXT,JOB,ALL (ALL)
REPORT_FILE file name for output report
SEQUENCES Show all user sequences (Y)
USERID Oracle connection string


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

  • пользователь в строке подключения (параметр USERID) должен иметь права на чтение словаря (dictionary);

  • утилита опционально может находить некэшируемые последовательности (с ними тоже возможны проблемы в RAC);

  • пока не поддерживается анализ зашифрованного кода (с помощью утилиты wrap), т.е. код должен быть скомпилирован в открытом виде;

  • для своей работы утилита требует установленной среды выполнения .NET Framework 3.5, а также ODP.NET Provider 11.1.0.6.21 - рекомендуется установить версию поставляемую с Instant Client - она небольшая по размеру.


Конечно никакого волшебства в работе этой утилиты нет: она всего лишь анализирует соответствующие представления словаря.
Уже есть история успеха (Success Story :-) ):
с помощью этой утилиты мне за пару минут удалось быстро проанализировать 750 тыс. строк кода в приложении нашего партнера-разработчика и определить модули и строки которые вызовут проблемы в RAC.

Надеюсь с помощью RACChecker вы быстро определите проблемные места при переходе в RAC!

Ссылка для скачивания: RACChecker.

P.S. Приветствуются рекомендации и замечания по функционалу ...

9 комментариев:

  1. Анонимный14/1/09 1:23 PM

    Доброго времени суток! у меня есть вопрос. есть ли какие нюансы использования dbms_lock в среде RAC?

    ОтветитьУдалить
  2. Мой опыт показывает, что никаких проблем с dbms_lock в RAC не возникает !

    ОтветитьУдалить
  3. Анонимный15/1/09 12:06 PM

    Спасибо за ответ. У меня появился еще один вопросик. Применил вышеуказанную программку racchecker. в логе она мне выдала такую вот запись:
    Checking lock issue
    found in function LOCK_FINISH - line 1

    функция LOCK_FINISH выглядит следующим образом (тут я привожу отформатированный вид. в оригинале она написана в одну строчку):

    create or replace function GG."LOCK_FINISH" (user_lock integer)
    return integer
    as
    res integer;
    begin
    res := dbms_lock.release (user_lock);
    return (0);
    end;

    я так понимаю что всё же есть некоторые вопросы с dbms_lock в среде RAC?

    ОтветитьУдалить
  4. Тут понимаете в чем дело:
    dbms_lock в RAC работает, но если вы им злоупотребляете, то это может стать узким местом (по аналогии с "горячими" блоками).
    Сейчас я подготовил более новый релиз RACChecker и убрал в нем анализ на DBMS_LOCK. В новом релизе есть масса новых возможностей (напр анализ wrapped-кода).

    ОтветитьУдалить
  5. Анонимный19/1/09 12:19 PM

    Большое спасибо. Обязательно опробуем новую версию :) у меня появился походу еще немного вопросов (кстати, если я задаю вопросы которые ответы на которые можно почерпнуть в документации, буду благодарен если меня перенаправят на конкретный документ. я искал, но что-то не нашел ответов. не исключаю что плохо искал...). Так вот. интересует работоспособность функций

    dbms_session.unique_session_id
    dbms_application_info.read_client_info
    dbms_application_info.set_client_info

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

    заранее благодарен.

    ОтветитьУдалить
  6. После смены ноды dbms_session.unique_session_id дает другой идентификатор, приложение не может найти его в своих внутренних таблицах и падает.

    Так подсказал мне мой ясновидящий шар. Поскольку я не знаю версии Oracle, OS, названия приложения, на чем оно написано, что делает и т.д.

    ОтветитьУдалить
  7. Анонимный19/1/09 1:15 PM

    :) версия 10.2.0.4, установлена на windows 2003. Извеняюсь что сразу не сообшщил.
    По поводу dbms_session.unique_session_id - большое спасибо. я не знал что после смены ноды она дает другой идентификатор. Вы мне очень помогли.

    ОтветитьУдалить
  8. "глобальные контексты приложений - также не синхронизируются между узлами кластера;"

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

    ОтветитьУдалить
  9. Нет, при failover Вам необходимо восстановить контекст сессии самостоятельно.

    ОтветитьУдалить