Ora 01403 описание ошибки

Время на прочтение
17 мин

Количество просмотров 4.9K

Предисловие

Убедительная просьба, рассматривать данный текст только как продолжение к статье о «Событийной модели логирования». Эта статья будет полезна тем, у кого уже реализовано логирование событий в БД и кто хотел бы осуществлять сбор статистики и начать проводить аналитику этих событий. Только представьте, что ваша БД сможет информировать вас о критичных сбоях системы, накапливать информацию о событиях в БД (кол-во повторений, период повторений и т.д.). И всё это без использования стороннего ПО силами одного PL/SQL.

Введение

В этом цикле статей будет показано как реализованный функционал «логирования» позволяет фиксировать факт возникновения не только ошибок (сообщение с типом «Error»), но и сообщений с предупреждением (тип «Warning»), информативных сообщений (с типом «Info») и т.д., поэтому, в рамках данных статей введём термин — «Модель логирования событий» (далее по тексту — «модель») или коротко «Логирование событий», где под «событием» подразумевается некоторое ожидаемое действие, возникшее в ходе штатной/внештатной работы алгоритма.

Модель логирования позволяет реализовать:

1. Единый подход в обработке и хранении событий (статья)

2. Собственную нумерацию и идентификацию событий происходящих в БД

3. Единый мониторинг событий (статья в разработке)

4. Анализ событий происходящих в БД (статья в разработке)

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

Для чего это нужно?

Для начала давайте рассмотрим пример. Вы реализовали логирование ошибок в вашей БД. С течением времени в ваш лог «прилетают» самые разнообразные ошибки. Предположим, имеются две ошибки вида «no_data_found» возникшие в двух разных процедурах при двух разных запросах (select). Первая ошибка возникла при попытке найти «email» клиента, что в принципе не является критичной ошибкой. Вторая ошибка возникла при попытке найти номер лицевого счета клиента, что вполне может являться критичной ошибкой. При этом если мы посмотрим в таблицу лога (из статьи), то увидим, что указанные ошибки будут храниться с одинаковым кодом 1403 (ORA-01403) в столбце msgcode. Более того, текст указанных ошибок будет практически аналогичным (текст полученный с помощью функции SQLERRM) за исключением имен объектов, на которых произошла ошибка. Для того чтобы понять является ли критичной конкретная ошибка, разработчику необходимо вникать в текст ошибки, смотреть в каком объекте возникла ошибка и на основе этой информации сделать вывод о срочности исправления. При этом, если мы сможем задать более четкое описание ошибки отличное от текста Oracle (SQLERRM), то это позволит упростить понимание причин возникновения и способов решения ошибки.

 Из этого примера видно, что одна и та же ошибка «no_data_found» (ORA-01403: данные не найдены) может иметь совершенно разное значение с точки зрения бизнес логики, а значит нам необходимо разработать механизм, который позволит идентифицировать каждое событие происходящее в БД как отдельное событие с нашим внутренним уникальным кодом и текстом события (отличную от Oracle). Таким образом мы решаем две проблемы:

1) В месте возникновения ошибки мы устанавливаем уникальный код ошибки. В будущем это позволяет достаточно быстро найти место возникновения ошибки. Также, наличие уникальных кодов позволяет нам произвести точечный подсчет повторений и на основании этой информации принять решение об устранении данной ошибки.

2) Дополнительный «читаемый» текст позволяет сильно упростить понимание ошибки. В таблице выше показано, как одна и та же ошибка может запутать или разъяснить пользователю сведения об ошибке.

Надеюсь мне удалось объяснить зачем необходимо кодировать события в таблице логов. Далее по тексту, будут введены термины «Архитектурный лог» и «Пользовательский лог». На примере процедуры поиска активного номера телефона клиента будет показано как и зачем создано разделение на архитектурный и пользовательский лог.

Архитектурное логирование событий

Давайте рассмотрим пример, имеется процедура поиска активного номера телефона принадлежащего конкретному клиенту (для примера его id = 43). Предположим, что при постановке задачи для разработчика не было описания каких-либо особых условий т.е. по условиям задачи предполагалось, что для конкретного пользователя (id = 43, идентификатор передается в качестве параметра) в таблице client_telnumbers всегда будет хотя бы одна запись с номером телефона клиента и признаком «активный» (значение поля enddate равно дате 31.12.5999 23:59:59, что означает что номер используется клиентом. В случае, любой другой даты в указанном поле означает, что номер перестал быть активным и более не используется), поэтому наша процедура будет выглядеть примерно так:

Исходный код демонстрационной процедуры

procedure p_get_telnumber(p_userid    in number,
                          p_telnumber out number,
                          p_errcode   out number,
                          p_errtext   out varchar2)
  is
    v_objname   varchar2(60) := utl_call_stack.concatenate_subprogram(utl_call_stack.subprogram(1));
    v_telnumber client_telnumbers.telnumber%type;
  begin
    select telnumber
      into v_telnumber
      from client_telnumbers
     where id = p_userid
       and enddate = to_date('31.12.5999 23:59:59', 'dd.mm.yyyy hh24:mi:ss');

    p_telnumber := v_telnumber;
    p_errcode   := 1;
  exception
    when others then
      pkg_msglog.p_log_err(p_objname    => v_objname,
                           p_msgcode    => SQLCODE,
                           p_msgtext    => SQLERRM,
                           p_paramvalue => 'p_userid = '||p_userid,
                           p_backtrace  => dbms_utility.format_error_backtrace);
      raise;
  end p_get_telnumber;

  Если мы будем использовать логирование ошибок как показано в предыдущей статье, то с течением времени обнаружим, что идентифицировать ошибки из данной процедуры будет сложно. Поэтому для всех ошибок попадающих в обработку исключения «WHEN OTHERS» реализована процедура pkg_msglog.p_log_archerr, которая при первом возникновении ошибки автоматически присваивает ей уникальный код и сохраняет ошибку в таблице лога. В дальнейшем, при повторении данной ошибки процедура найдет ранее созданный код и использует его при логировании в таблице лога.

В итоге, после добавления блока «архитектурного» логирования (строки с 18 по 24), наша процедура будет выглядеть следующим образом:

Исходный код демонстрационной процедуры

procedure p_get_telnumber(p_userid    in number,
                          p_telnumber out number,
                          p_errcode   out number,
                          p_errtext   out varchar2)

  is
    v_objname   varchar2(60) := utl_call_stack.concatenate_subprogram(utl_call_stack.subprogram(1));
    v_telnumber client_telnumbers.telnumber%type;
  begin
    select telnumber
      into v_telnumber
      from client_telnumbers
     where id = p_userid
       and enddate = to_date('31.12.5999 23:59:59', 'dd.mm.yyyy hh24:mi:ss');

    p_telnumber := v_telnumber;
    p_errcode   := 1;
  exception
    -- Архитектурное логирование
    when others then
      pkg_msglog.p_log_archerr(p_objname    => v_objname,
                               p_msgcode    => SQLCODE,
                               p_msgtext    => SQLERRM,
                               p_paramvalue => 'p_userid = '||to_char(p_userid),
                               p_backtrace  => dbms_utility.format_error_backtrace);
      raise;
  end p_get_telnumber; 

  На этапе написания текста процедуры разработчик не всегда может предугадать возникновение той или иной ошибки (если честно, не всегда есть на это время), поэтому на начальном этапе ему достаточно «отлавливать» абсолютно все ошибки возникающие в данной процедуре с помощью оператора «WHEN OTHERS». Таким образом мы можем ввести новый термин (в рамках данного цикла статей), «Архитектурные логирование» — это логирование всех ошибок, возникновение которых не предполагается при штатной работе алгоритма. Для функционала «Архитектурных ошибок» были созданы объекты: отдельный справочник ошибок messagecodes_arch и процедура pkg_msglog.p_log_archerr создания записи в таблице лога для указанного типа ошибок.

Исходный код таблицы

create table messagecodes_arch(objectname  varchar2(120) not null,
                               sqlerrcode  number        not null,
                               msgcode     varchar2(10)  not null,
                               insertdate  date          default sysdate,
                               constraint pk_msgcode_arch_id primary key (objectname,sqlerrcode));

Обратите внимание, что при использовании описанной модели «архитектурного» логирования у вас появляется функционал позволяющий максимально быстро реагировать на первое появление ошибки (в конкретной функции/процедуре). Для этого необходимо реализовать отдельный мониторинг архитектурных ошибок, который постараюсь продемонстрировать в следующей (третьей) статье. Использование процедуры pkg_msglog.p_log_archerr не требует каких-либо действий кроме описания входных параметров.

Таким образом мы можем создать базовый шаблон процедуры (функции), использование которого позволит вам гарантированно отлавливать все архитектурные ошибки в вашем коде.

Шаблон процедуры/функции с архитектурным логированием

  -- Шаблон процедуры/функции для построения Событийной модели логирования
  -- Обратите внимание, что каждый блок "begin ... end" содержит исключение вида "when others",
  -- который осуществляет логирование Архитектурных ошибок.
  -- Все остальные исключения вида "no_data_found", "too_many_rows" и др. 
  -- будут осуществлять логирование Пользовательских ошибок
  procedure p_procedure_name(p_param1  in number,
                             p_param2  in varchar2,
                             p_param3  in date,
                             /* others param */
                             p_errcode out number,
                             p_errtext out varchar2)
  is
    v_objname varchar2(60) := utl_call_stack.concatenate_subprogram(utl_call_stack.subprogram(1));
    /* variable */
    v_msgcode   messagelog.msgcode%type;
    v_msgtext   messagelog.msgtext%type;
  begin
  
    /* code */

    begin
    
      /* code */
  
    exception
      -- Пользовательское логирование
      when no_data_found then
        v_msgcode := 'USR0000'; -- внутренний код
        v_msgtext := pkg_msglog.f_get_errcode(v_msgcode);
        pkg_msglog.p_log_wrn(p_objname    => v_objname,
                             p_msgcode    => v_msgcode,
                             p_msgtext    => v_msgtext,
                             p_paramvalue => 'p_param1 = '||to_char(p_param1)
                                                ||', p_param2 = '||p_param2
                                                ||', p_param3 = '||to_char(p_param3,'dd.mm.yyyy hh24:mi:ss'));
	      p_errcode := -1;
        p_errtext := v_msgtext;                                           
    end;   
    
    /* code */
    
    /* result */
    p_errcode := 1;
  exception
    -- Пользовательское логирование
    when no_data_found or too_many_rows then
      v_msgcode := 'USR0000';  -- внутренний код
      v_msgtext := pkg_msglog.f_get_errcode(v_msgcode);
      pkg_msglog.p_log_wrn(p_objname    => v_objname,
                           p_msgcode    => v_msgcode,
                           p_msgtext    => v_msgtext,
                           p_paramvalue => 'p_param1 = '||to_char(p_param1)
                                                ||', p_param2 = '||p_param2
                                                ||', p_param3 = '||to_char(p_param3,'dd.mm.yyyy hh24:mi:ss'));
    	p_errcode := -1;
      p_errtext := v_msgtext;
    -- Архитектурное логирование
    when others then
      pkg_msglog.p_log_archerr(p_objname    => v_objname,
                               p_msgcode    => SQLCODE,
                               p_msgtext    => SQLERRM,
                               p_paramvalue => 'p_param1 = '||to_char(p_param1)
                                                ||', p_param2 = '||p_param2
                                                ||', p_param3 = '||to_char(p_param3,'dd.mm.yyyy hh24:mi:ss'),
                               p_backtrace  => dbms_utility.format_error_backtrace);
      raise;
 end p_procedure_name;

В рамках событийной модели логирования, предполагается, что все архитектурные ошибки будут исправляться отдельной задачей т.е. основная цель это устранить повторное появление ошибок с кодом «SYS****» в таблице лога. В указанной задаче вам необходимо либо устранить причины возникновения данной ошибки, либо добавить отдельную обработку ошибки отличную от «when others», которую в дальнейшем будем назвать «пользовательское» логирование (в рамках данного цикла статей).

Пользовательское логирование событий

Предположим, что однажды в нашей процедуре get_telnumber произошла «архитектурная ошибка». В частности, для конкретного пользователя в таблице client_telnumbers хранится два номера телефона с признаком «активный». В таком случае, процедура «упадёт» с ошибкой «ORA-01422: too_many_rows». При этом, наш функционал архитектурного логирования сгенерировал новый код ошибки «SYS0061» и создал запись в таблице лога.

Самое важно в такой ситуации это не откладывать «на потом» исправление архитектурных ошибок. В идеале, необходимо создать отдельную задачу (баг) и в рамках неё устранить ошибку.

Предположим ,что была создана отдельная задача для устранения ошибки и назначена разработчику. В рамках этой задачи, разработчик совместно с технологом, аналитиком и др. коллегами пришел к выводу, что указанная ошибка носит систематический характер, является некорректной работой системы и требует исправления. В качестве мер исправления было решено добавить обработку события «too_many_rows» с последующим логированием события в таблице лога и выводом текста ошибки для пользователя.

Для этого в процедуре get_telnumber добавлено исключение (exception) «too_many_rows» пользовательского логирования. Также, был создан справочник пользовательских ошибок отличный от архитектурного справочника, тем что в него все записи добавляются разработчиком «вручную». Наверное это самое слабое место во всей архитектуре логирования. Предполагается, что разработчик должен описать исключение (exception) и создать для него уникальный код ошибки. Также, желательно к указанной ошибке сформулировать читаемый текст ошибки (для своих коллег, пользователя, техподдержки и т.д.), что бывает иногда очень сложным (из личного опыта).

Таблица пользовательских ошибок и процедура их «регистрации» будет выглядеть следующим образом:

Исходный код таблицы пользовательских ошибок и процедуры регистрации

create table messagecodes(msgcode     varchar2(10)  not null,
                          rustext     varchar2(500) not null,
                          msgpriority number(1)     default 1,
                          insertdate  date          default sysdate,
                          lastupdate  date          default null,
                          constraint pk_messagecodes_id primary key (msgcode));

-- Пример регистации пользовательских ошибок
begin
  pkg_msglog.p_insert_msgcode('USR0001','Не найден адрес электронной почты клиента id = $1!',1);
  pkg_msglog.p_insert_msgcode('USR0002','Не найден лицевой счет клиента id = $1!',5);
  pkg_msglog.p_insert_msgcode('USR0003','Для клиента id = $1 найдено два и более активных номеров телефона!',1);
  pkg_msglog.p_insert_msgcode('USR0004','Номер мобильного телефона не соответствует маске (clientid = $2)',1);
  commit;
end;

v_msgcode := 'USR0003'; -- внутренний код
v_msgtext := pkg_msglog.f_get_errcode(p_msgcode  => v_msgcode,
                                      p_msgparam => to_char(p_userid));

После того, как мы «зарегистрировали» пользовательскую ошибку «USR0003» и добавив отдельную обработку пользовательского логирования (строки с 19 по 28), наша процедура get_telnumber будет выглядеть следующим образом:

Исходный код демонстрационной процедуры

  procedure p_get_telnumber(p_userid    in number,
                            p_telnumber out number,
                            p_errcode   out number,
                            p_errtext   out varchar2)
  is
    v_objname   varchar2(60) := utl_call_stack.concatenate_subprogram(utl_call_stack.subprogram(1));
    v_telnumber client_telnumbers.telnumber%type;
    v_msgcode   messagelog.msgcode%type;
    v_msgtext   messagelog.msgtext%type;
  begin
    select telnumber
      into v_telnumber
      from client_telnumbers
     where id = p_userid
       and enddate = to_date('31.12.5999 23:59:59', 'dd.mm.yyyy hh24:mi:ss');

    p_telnumber := v_telnumber;
    p_errcode   := 1;
  exception
    -- Пользовательское логирование
    when too_many_rows then
      v_msgcode := 'USR0003'; -- внутренний код
      v_msgtext := pkg_msglog.f_get_errcode(v_msgcode,to_char(p_userid));
      pkg_msglog.p_log_wrn(p_objname    => v_objname,
                           p_msgcode    => v_msgcode,
                           p_msgtext    => v_msgtext,
                           p_paramvalue => 'p_userid = '||to_char(p_userid));
      p_errcode := -1;
      p_errtext := v_msgtext;
    -- Архитектурное логирование
    when others then
      pkg_msglog.p_log_archerr(p_objname    => v_objname,
                               p_msgcode    => SQLCODE,
                               p_msgtext    => SQLERRM,
                               p_paramvalue => 'p_userid = '||to_char(p_userid),
                               p_backtrace  => dbms_utility.format_error_backtrace);
      raise;
  end p_get_telnumber;

При повторном возникновении ошибки «too_many_rows» обработка события пройдет по нашему сценарию «пользовательского» логирования. Таким образом мы можем ввести второй термин (в рамках данного цикла статей), «Пользовательские логирование» — это логирование всех ошибок, возникновение которых предполагается и ожидается при нештатной работе алгоритма. В итоге, пользователь получит читаемый текст ошибки с кодом «USR0003», также, мы же всегда сможем подсчитать количество ошибок с указанным кодом. В случае большого количества ошибок у нас на руках будет «живая» статистика частоты возникновения ошибки и их количества, что позволит нам выйти на руководство с предложением по доработке/оптимизации процесса.

Давайте рассмотрим еще один пример (кейс из реального случая), в момент когда процедура get_telnumber по id клиента находит один «активный» номер телефона иногда возникает ситуация, что номер телефона не принадлежит мобильному оператору. Ситуации бывают разные иногда указанный номер мог быть номером городской телефонной сети, иногда номером международного оператора, а иногда вообще набор из нескольких цифр и т.д. Основным требованием от бизнес-заказчика было использование номера телефона российских операторов мобильной связи. Поэтому было решено добавить проверку соответствия найденного номера некому «корректному» шаблону (строки с 18 по 29). В случае обнаружения некорректного номера, логировать данное событие отдельным кодом «USR0004» и типом «WRN». Добавим функцию проверки корректности номера телефона, если номер соответствует шаблону (требованиям), то вернем номер телефона, иначе пустое значение.

Исходный код демонстрационной процедуры

  procedure p_get_telnumber(p_userid    in number,
                            p_telnumber out number,
                            p_errcode   out number,
                            p_errtext   out varchar2)
  is
    v_objname      varchar2(60) := utl_call_stack.concatenate_subprogram(utl_call_stack.subprogram(1));
    v_telnumber    client_telnumbers.telnumber%type;
    v_newtelnumber client_telnumbers.telnumber%type;
    v_msgcode      messagelog.msgcode%type;
    v_msgtext      messagelog.msgtext%type;
  begin
    select telnumber
      into v_telnumber
      from client_telnumbers
     where id = p_userid
       and enddate = to_date('31.12.5999 23:59:59', 'dd.mm.yyyy hh24:mi:ss');
    
    v_newtelnumber := f_check_telnumber(v_telnumber);
    if v_newtelnumber is not null then
      p_telnumber := v_telnumber;
      p_errcode   := 1;
    else
      -- Пользовательское логирование
      v_msgcode := 'USR0004'; -- внутренний код
      v_msgtext := pkg_msglog.f_get_errcode(v_msgcode,to_char(p_userid));
      pkg_msglog.p_log_wrn(p_objname    => v_objname,
                           p_msgcode    => v_msgcode,
                           p_msgtext    => v_msgtext,
                           p_paramvalue => 'p_userid = '||to_char(p_userid));
      p_errcode := -1;
      p_errtext := v_msgtext;
    end if;
  exception
    -- Пользовательское логирование
    when too_many_rows then
      v_msgcode := 'USR0003'; -- внутренний код
      v_msgtext := pkg_msglog.f_get_errcode(v_msgcode,to_char(p_userid));
      pkg_msglog.p_log_wrn(p_objname    => v_objname,
                           p_msgcode    => v_msgcode,
                           p_msgtext    => v_msgtext,
                           p_paramvalue => 'p_userid = '||to_char(p_userid));
      p_errcode := -1;
      p_errtext := v_msgtext;
    -- Архитектурное логирование
    when others then
      pkg_msglog.p_log_archerr(p_objname    => v_objname,
                               p_msgcode    => SQLCODE,
                               p_msgtext    => SQLERRM,
                               p_paramvalue => 'p_userid = '||to_char(p_userid),
                               p_backtrace  => dbms_utility.format_error_backtrace);
      raise;
 end p_get_telnumber;

После сбора статистических данных по конкретной ошибке с кодом «USR0004», руководству стало понятно, что ошибка актуальна и количество ошибок с течением времени не только не уменьшается, а наоборот растет с линейной прогрессией. В дальнейшем, были выявлены источники «кривых» данных и были установлены внутренние требования по первичной обработке номера телефона клиентов. В итоге, со временем количество ошибок уменьшилось до нуля. И этого нельзя было добиться до тех пор, пока у всех участвующих лиц не возникло понимание о масштабе проблемы.

Выполняя самый банальный запрос в таблицу лога с группировкой по типу сообщения (msgtype), имени объекта (objname) и вашему внутреннему коду ошибки (msgcode) за отдельный квартал, вы сможете увидеть реальную картинку частоты возникновения той или иной ошибки. Как только в вашей БД появляется ошибка с большим количеством повторений вы всегда сможете выявить это событие и принять решение об устранении.

Исходный код запроса

select msgtype, 
       objname, 
       msgcode, 
       count(*) 
  from messagelog
where insertdate between to_date('01.01.2021', 'dd.mm.yyyy') and to_date('31.03.2021', 'dd.mm.yyyy')
group by msgtype, objname, msgcode
order by 4 desc

Заключение

В заключении наверное скажу банальную вещь, о том что ваша БД является сложным механизмом ежесекундно выполняющая рутинные операции. Прямо сейчас в БД могут происходить различные ошибки. Критичные, которые вы исправляете практически сразу или некритичные, о которых вы можете вообще не знать. И если у вас нет информации о подобных ошибках, то возникает вопрос: «Нужно ли их вообще исправлять? Или можно подождать до тех пор, пока проблема не всплывёт?». Вопрос наверное «риторический».

Я же данной статьёй хотел показать один из способов ведения логирования с кодированием отдельных событий. Данный метод требует некоторых «обязательств» от разработчика и в нынешнее время этого тяжело добиться. В следующей статье постараюсь показать один из способов мониторинга ошибок основанный напрямую по кодам ошибок созданных в текущей статье.

Спасибо за внимание.

Возможные ошибки и методы их устранения

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

Ошибка ORA-00020

По
документации:

Причина:
Операция потребовала ресурс,
оказавшийся недоступным. Максимальное количество процессов определяется
параметром инициализации PROCESSES.
Когда этот максимум превышается, никакие запросы больше обрабатываться не
могут.

Действие:
Повторите операцию еще раз через
несколько минут. Если это сообщение выдается часто, закройте ORACLE,
увеличьте параметр PROCESSES в файле
параметров инициализации, и запустите ORACLE вновь.

Из
практики:

Действие:
Требуется увеличить параметр PROCESSES в
файле INIT<SID>.ORA, причем для деф-сайта этот параметр должен
быть больше, чем для дест-сайта. Для БД СИСТЕМЫ было рекомендовано
установить этот параметр в 300 для дест-сайта и 400 для деф-сайта.

Ошибка ORA-00060

По
документации:

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

Действие: Либо:

·        
выдайте команду ROLLBACK и перезапустите все команды, входящие в последнюю транзакцию;

·        
подождите, пока блокировка не
закончится (возможно, через несколько минут), и перезапустите те команды, на
которых произошел откат. 

Из
практики:

Причина:
Ошибка может возникнуть при
перегенерации сайта на БД, куда был неудачно выполнен полный импорт БД другого
сайта (см. Часть 2, Глава 3: Перенос основной БД на сервер с другой ОС).

Действие: Попробуйте удалить мастер-группы вместе с объектами и
повторить генерацию сайта.

Ошибка ORA-00600

По
документации:

Причина:
Это общее внутреннее сообщение для
исключительных ситуаций программ ORACLE. Оно указывает, что процесс столкнулся с неожиданным
событием нижнего уровня. Причинами,
вызывающими это сообщение, могут быть: 

·        
истечение времени
ожидания; 

·        
поломка файла; 

·        
сбойные ситуации при проверке
данных в памяти; 

·        
сообщения ввода/вывода,
аппаратного обеспечения, памяти; 

·        
некорректно
восстановленные файлы.

Первый
аргумент — это номер внутреннего сообщения; другие аргументы — различные 
числа, имена и символьные строки. (Для получения более полной информации см. 
раздел «Обращение в службу поддержки пользователей ORACLE«.)
Числа могут  меняться в зависимости от версии сервера ORACLE.

Действие:
Отправьте описание этой ошибки в
службу поддержки пользователей ORACLE, сопроводив его информацией о: 

·        
событиях, которые привели к
ошибке; 

·        
предпринятых вами действиях,
которые привели к ошибке; 

·        
состоянии операционной системы и ORACLE
на момент ошибки; 

·        
подробностях всех необычных
обстоятельств, предшествовавших получению сообщения ORA-00600; 

·        
содержимом всех файлов трассировок,
созданных в результате ошибки; 

·        
относящихся к этому случаю
реакциях сигнального файла. 

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

Из
практики:

Действие:
Это одна из самых скверных ошибок.
При ее возникновении рекомендуется обратиться к группе технической поддержки Oracle.
Но существует также еще одна рекомендация: настройте работу в Oracle через
протокол IPC.

Ошибка ORA-01400

По документации:

Причина: При вводе или редактировании записи Вы не задали
значение обязательного (NOT
NULL) столбца.

Действие: Задайте значение для каждого столбца NOT NULL или измените определение таблицы так, чтобы
разрешить  устанавливать пустые значения столбцов.

Из
практики:

Причина:
Возникает при попытке сделать изменение
в таблице при отключенном или отсутствующем триггере EDITIONS_COR (который расчитывает и устанавливает системный
идентификатор записи ID).

Действие:
Включите (поставьте Enabled с
помощью Oracle Schema
Manager) либо создайте
триггер EDITIONS_COR:

Ошибка ORA-01403

По
документации:

Причина: В программе на базовом языке были выбраны все записи.
Код возврата от операции FETCH равен +4. Это означает, что из запроса на были
извлечены все записи.

Действие: Прекратите обработку для данного оператора SELECT.

Из
практики:

Причина:
Ошибка ORA-01403 является большим сюрпризом. Она возникает в самом важном месте – при выполнении
удаленной транзакции, и, притом, из-за множества причин, большинство которых
Вам еще не известно. Эта трудно распознаваемая ошибка обязательно будет время
от времени у Вас возникать.

Действие:
Дело может быть в следующем: не
обновлено поле, по которому разрешаются конфликты (отключен или отсутствует
триггер ТАБЛИЦА_COR, который расчитывает и устанавливает поле CORDATE, по которому как раз и разрешаются конфликты методом Latest Timestamp — см. пример триггера _COR выше при описании ошибки ORA-01400). Эта ошибка не возникает, если транзакция по данной
записи идет одна, без встречной.

Ошибка ORA-01591

По
документации:

Причина:
Была попытка доступа к ресурсу,
заблокированному «повисшей» распределенной транзакцией, находящейся в
состоянии подготовки.

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

Из
практики:

Причина:
Ошибка диагностирует возникновение
«смертельных объятий», зацикливании процессов друг на друге. Может возникнуть
при попытке удалить из мастер-группы дест-сайт, если одна из БД других
сайтов остановлена.

Действие:
Запустите БД всех сайтов и в
состоянии мастер-группы NORMAL повторите операцию.

Ошибка ORA-02049

По
документации:

Причина:
Превышено время ожидания блокировки
распределенной транзакции. Это время задается в параметре инициализации DISTRIBUTED_LOCK_TIMEOUT.

Действие:
Эта ситуация трактуется как
тупиковая, поэтому происходит откат вашей команды. Установите в параметре
инициализации DISTRIBUTED_LOCK_TIMEOUT более длительный интервал времени ожидания; затем
закройте и перезапустите экземпляр СУБД.

Из
практики:

Причина:
Ошибка может порождаться при
возникновении «смертельных объятий», связанных с тем, что кончилось время
ожидания выполнения распределенной транзакции, заданное в конфигурационном
файле параметром DISTRIBUTED_LOCK_TIMEOUT.

Действие:
Увеличьте значение указанного
параметра и перезагрузите БД.

ПРИМЕЧАНИЕ 1.

На момент внедрения этот параметр можно снизить до 60
(1 мин), чтобы долго не ожидать результатов выполнения небольших тестов по
проверке репликации. Во время же эксплуатации лучше увеличить этот параметр,
например, до 300 (5 мин).

ПРИМЕЧАНИЕ 2.

Такое сообщение может появиться при выполнении
административных запросов, причем не адекватным образом, например, при переводе
группы в NORMAL, затем сразу в QUIESCED
(для проверки). Транзакций в этом случае быть не должно (кроме, возможно,
системных). Подождите немного и повторите попытку.

ПРИМЕЧАНИЕ 3.

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

Ошибка ORA-02266

По
документации:

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

Действие:
Перед удалением таблицы отключите все
ссылки внешних ключей на уникальные или первичные ключи. Посмотреть имеющиеся
ссылки и их статус Вы можете с помощью следующего SQL-запроса:

Из практики:

Причина:
Фирма Oracle
инструктирует, что эта ошибка возникает при попытке сделать DROP или TRUNCATE на
таблицу со связями. Но при репликации эта ошибка может возникнуть в случае,
если на дест-сайте таблица имеет статус Error.

Действие:
Для исправления ситуации требуется
приостановить мастер-группу (Suspend),
удалить таблицу (Remove) из
мастер-группы деф-сайта (не удаляя физически), дождаться удаления из дест-сайта,
затем опять ее добавить (Add) и
активизировать мастер-группу (Resume).

Ошибка ORA-02449

По документации:

Причина: Была попытка уничтожить таблицу, хотя она имела еще
какие-то уникальные или первичные ключи, на которые ссылаются внешние ключи.

Действие:
Перед удалением таблицы удалите все
ссылки внешних ключей на уникальные или первичные ключи. Посмотреть имеющиеся
ссылки Вы можете с помощью следующего SQL-запроса:

select * from
USER_CONSTRAINTS where table_name = «TABNAM»;

Из практики:

Причина:
Возникает при попытке удалить таблицу
с первичным или уникальным ключем, если на нее ссылается другая таблица (см.
выше: ORA-02266).

Ошибка ORA-03113

По документации:

Причина:       По коммуникационному каналу передан сигнал
конца файла, который не был обработан соответствующим образом программным
обеспечением SQL*Net (двухзадачным программным обеспечением). Это
сообщение может быть выдано, если теневой двухзадачный процесс, связанный с SQL*Net, завершился ненормально, или же на устройстве связи
между процессами  произошел физический сбой (сеть или сервер отключились от
коммуникации).

Действие:      Если это сообщение было выдано при попытке
осуществить связь, проверьте установочные файлы для соответствующего драйвера SQL*Net и убедитесь, что программное обеспечение SQL*Net на сервере установлено правильно. Если сообщение было
выдано после того, как связь правильно установилась, и ошибка не связана с
физическим сбоем, проверьте файл трассировки, если таковой был создан на
сервере в момент сбоя. Существование файла трассировки может указать вам на то,
что эта ошибка — внутренняя ошибка ORACLE, требующая вмешательства
службы поддержки пользователей ORACLE.

Из практики:

При
возникновении этой ошибки рекомендуется посмотреть трассировочные файлы (обычно
находятся в каталоге RDBMS80TRACE). Как
правило, это связано с потерей связи или неисправностью на сервере, возникших
во время выполнения процесса в Oracle.

Эта
ошибка часто возникает при прохождении на сервер большого пакета транзакций или
подтверждений от них (см. Часть 2, Глава 3: Если пропала связь с сервером),
но может возникнуть и во время выполнения административных запросов (например,
одновременный запуск добавления достаточно больших таблиц в несколько
мастер-групп).

Конкретно
эта ошибка может возникнуть при попытке создания на удаленном сервере большой
таблицы (команда create table TAB as select * from USER.TAB@DBLINK или
аналогичный процесс в Мультимастере). В этом случае рекомендуется
послать администратору удаленного сервера дамп для импорта больших файлов
(можно целой группы или всей БД), а затем лишь сгенерить репликационную
поддержку для этих таблиц.

Ошибка ORA-04030

По
документации:

Причина:
Собственная память системного
процесса исчерпана.

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

Из
практики:

Выделяемая
под процессы память на сервере исчерпалась. Причины могут быть разные. На Netware-сервере
это обычно происходит при фрагментации кэш-памяти и помогает только
перезагрузка сервера.

Ошибка ORA-04052

По
документации:

Причина:
Ошибка возникла во время поиска
удаленного объекта.

Действие:
Исправьте ошибку. Убедитесь, что на
удаленной базе данных были запущены все необходимые командные файлы создания
представлений данных, используемых для запроса/поиска объектов базы данных. См.
книгу Сервер ORACLE7. Руководство администратора.

Из практики:

Причина: Ошибка может возникнуть при ручном «толкании»
административных запросов (Apply all admin requests now).

Действие: Посмотрите, не «уронили» ли Вы при этом сервер. Если
да – перезапустите его.

Ошибка ORA-06502

По документации:

Причина: Произошла ошибка арифметическая, числовая, строковая,
преобразования или правила целостности. Например, такая ошибка  может произойти
при попытке присвоить значение NULL
переменной, описанной как NOT NULL, или при
попытке присвоить целое, больше переменной, описанной как NUMBER(2).

Действие: Измените данные, которыми вы манипулируете, или  их
описание таким образом, чтобы они не противоречили друг другу.

Из практики:

Причина:
Ошибка может возникнуть при
перегенерации сайта на БД, куда уже был выполнен полный импорт БД другого сайта
(см. Часть 2, Глава 3: Перенос основной БД на сервер с другой ОС).

Действие: Необходимо удалить мастер-группы вместе с объектами и
повторить генерацию сайта (на самом деле так просто отделаться от этой ошибки
не всегда удается).

Ошибка ORA-12011

По
документации:

Причина:
DBMS_IJOB.RUN обнаружил ошибку. Запуск одного или нескольких
заданий привел к ошибке, которую не удалось обработать.

Действие:
Посмотрите в журнале предупреждений,
какое задание не смогло запуститься и почему.

Из
практики:

Причина:
Ошибка возникает при попытке
запустить задачу PUSH, которая до этого
находилась в состоянии BROKEN, причем, предварительный перевод ее в состояние NORMAL не помогает –
задача или сама через некоторое время устанавливается в BROKEN, или это происходит после попытки ее запустить. Это может произойти по
причине выполненного ранее  выполнилось автоматически при установке в это
состояние пакета транзакций).

Ошибка ORA-23308

По
документации:

Причина:
Указанное имя введено неправильно или
пусто, заданный тип неправилен, объект не является правильным объектом базы данных
или не существует как тиражируемый объект с соответствующим состоянием.

Действие:
Проверьте, что объект существует,
доступен пользователю и, если требуется, является правильным объектом в списке ALL_REPOBJECT.

Из
практики:

Причина:
Ошибка возникает при несоответствии
структуры таблицы одного сайта с другим (например, при перегенерации
репликационной поддержки).

Действие:
Тщательно сверьте структуру указанной
таблицы на деф-сайте и дест-сайте. Возможно, на деф-сайте
была изменена ее структура, типы полей или ограничения вне DDL-механизма ORM.

ВНИМАНИЕ
!

Эта ошибка может создать заколдованный круг: при ее удалении на дест-сайте вне
DDL-механизма ORM остаются неудаленными $RP и $RR модули и операции Remove
затем Add для этой таблицы на деф-сайте вызывает ошибку.
Удаление вышеназванных модулей тоже не помогает. Не помогает также
соответствующая операция alter
table для этой таблицы в БД дест-сайта
(вне ORM). При попытке удаления этой таблицы из мастер-группы деф-сайта
(с тем, чтобы это удаление распространилось на дест-сайт) также
возникает ошибочный административный запрос, поскольку из мастер-группы дест-сайта
в этом случае нельзя удалить таблицу с несоответствующей структурой.

Рекомендуется следующее: сделайте соответствующую
операцию alter
table для этой таблицы в БД дест-сайта
через механизм ORM. Если при этом также возникнет ошибка можно поступить
иначе: удалите таблицу из БД дест-сайта с помощью SQL*Plus
(отключив предварительно ограничения) и создайте заново (можно пустую). Затем
можно попытаться удалить эту таблицу из мастер-группы деф-сайта,
подождать окончания административного запроса на обоих сайтах и вновь добавив
таблицу в мастер-группу. Если и это не поможет, то пересоздайте всю
мастер-группу путем удаления и последующего подключения к ней этого сайта с
отключенной опцией Use
existing object.

Ошибка ORA-23309

По документации:

Причина:       Объект уже существует в том же пространстве имен,
возможно с другим типом или формой.

Действие:      Удалите объект или повторите запрос со значением
TRUE логического параметра RETRY или USE_EXISTING_OBJECT.

Из
практики:

Причина:
Ошибка может возникнуть после
добавления на мастер-группу деф-сайта нового дест-сайта, если на дест-сайте
уже есть такая таблица, но ее структура другая. Ошибка возникает независимо от
того, была ли включена или отключена опция Use existing object при создании мастер-группы и включении в нее таблиц
на дест-сайте.

Действие:
Удалите эту таблицу в БД дест-сайта
и повторите добавление этого сайта на мастер-группу дест-сайта.

Ошибка ORA-23312

По документации:

Причина: Имя схемы пусто или неправильно введено,
запрашиваемая заданная база данных не является оригиналом, или один из
оригиналов не считает вызываемую базу данных оригиналом.

Действие:
Если заданное имя схемы и оригинала
правильны, соединитесь с оригиналом и повторите запрос, или переместите masterdef, использовав RELOCATE_masterdef.

Из
практики:

Причина:
Ошибка может возникнуть при
перегенерации репликационной поддержки для сайта, где объекты имеют статус Error (см. Часть 2, Глава 3: Работа с административными запросами, Решение
проблем при создании мастер-групп).

Действие: Удалите всю группу с объектами с этого сайта (или
только Error-объекты) и перегенерите репликацию.

Ошибка ORA-23313

По документации:

Причина:
Имя схемы пусто или неправильно
введено, запрашиваемая база данных не является оригиналом или запрашиваемая
база данных не считает заданную базу данных оригиналом.

Действие:
Если заданное имя схемы правильно,
соединитесь с текущим оригиналом и повторите запрос, установите запрашиваемую
базу данных оригиналом с помощью ADD_MASTER_DATABASE или используйте SWITCH_SNAPSHOT_MASTER, если запрашиваемая база данных является узлом копии.

Из практики:

Причина:
Ошибка возникает, если мастер-БД с
мастер-группы деф-сайта уже удалена.

Ошибка ORA-23374

По документации:

Причина: Данная мастер-БД уже реплицирована данной
мастер-группой.

Действие: Выберите другую мастер-группу или мастер-БД.

Из практики:

Причина:
Ошибка возникает при попытке
«прицепить» дест-сайт к мастер-группе деф-сайта, если на этом дест-сайте
такая мастер-группа уже существует. Эта ситуация возникает, если сайт пытаются
пересоздать (см. Часть 2, Глава 3: Пересоздание дест-сайта), для чего
сначала его «отрывают» от мастер-группы деф-сайта, а потом (переведя ее
в состояние QUIESCED) пытаются опять присоединить.

Действие: Удалите в режиме NORMAL мастер-группу с дест-сайта
со всеми ее объектами, т.е. отметьте опцию Drop all objects in the group (на предупреждение, что объекты группы сохранятся на
других сайтах – нажмите OK). Затем повторите присоединение (Properties… => Destinations => Add… => Asysnc, Use
existing objects, Copy row
data).

SQL-команды по анализу и управлению репликацией

Нижеприведенные команды SQL и PL/SQL окажутся для администратора Oracle
полезными и часто необходимыми для.
анализа и управления распределенными транзакциями. Полный синтаксис
использования DBMS-процедур и структура представлений Словаря данных
приводятся в Приложении 3  и Приложении 4, соответственно.

Анализ объектов в мастер-группе

·        
Поиск мастер-группы для таблицы
(например, BRANCH):

·        
Кол-во записей по всем таблицам
мастер-группы (пример для PLIPEKN0). Используйте скрипт RowCntMg.sql (предварительно исправив в нем название нужной
мастер-группы или аналогичные скрипты для каждой мастер-группы: RwCntMg0.sql, …, RwCntMg7.sql), который формирует скрипт Temp.sql и запускает его
(создан по прототипу известного скрипта TabCount.sql автора Peter Koletzke):

·        
Кол-во модулей по всем
мастер-группам (если объекты – только
таблицы, то равно учетверенному кол-ву таблиц – Package и Package Body по
модулям $RP и $RR):

select count(*) from
ALL_REPGENERATED order by ONAME, TYPE;

·        
Кол-во модулей по каждой
мастер-группе (очень полезный запрос):

·        
Объекты, нуждающиеся в перегенерации
репликационной поддержки:

·        
Error-объекты на сайте (обязателен к применению):

·        
Кол-во Error-объектов по мастер-группам:

·        
Кол-во изменений по мастер-группам
за период времени (для определения
наиболее активных мастер-групп):

Результат выполнения запроса (пример):

Анализ административных запросов

·        
Ошибочные административные
запросы по таблицам (некоторые
ошибки, в частности, end—of—file…, могут
не войти):

·        
Административные запросы по
мастер-группе (PLIPEKNn):

·        
Административные запросы по
мастер-сайту первой очереди (для
выявления блокирующих административных запросов):

·        
Кол-во адм-запросов по всему
мастер-сайту (для общего контроля
выполнения):

   select count(*) from
USER_REPCATLOG;

·        
Кол-во административных
запросов по каждой мастер-группе (для
общего контроля выполнения):

·        
Кол-во каждого вида и статуса
административных запросов по каждой мастер-группе (для детального контроля выполнения):

Анализ транзакций

·        
Кол-во всех транзакций:

select count(*) from
DEFTRAN;

·        
Кол-во транзакций для каждого
сайта:

·        
Кол-во транзакций для каждого
сайта по дням формирования:

Результат выполнения запроса (пример):

·        
Удаление транзакций. Для удаления одной транзакции (например, с
идентификатором 6.19.11941) используется следующее DBMS-предложение (значение NULL параметра DESTINATION указывает
о применении команды ко всем мастер-сайтам):

Для удаления всех транзакций используется пустое
значение параметра DEFERRED_TRAN_ID:

·        
Перезапуск транзакций: данная функция отсутствует, но можно использовать
запуск соответствующей задачи, т.е. процесс PUSH для нужного дест-сайта,
например:

DBMS_JOB.RUN(job
=> 204);

·        
Кол-во ошибочных транзакций:

select count(*)
from DEFERROR;

·        
Удаление всех ошибочных
транзакций. Для удаления ошибочной
транзакции (например, с идентификатором 8.55.21) используется
нижеприведенная DBMS-процедура (значение NULL параметра
DESTINATION указывает
о применении команды ко всем мастер-сайтам). Если значение параметра DEFERRED_TRAN_ID не
указано (=>’’), то удаляются все ошибочные транзакции (см. RemErr.sql):

·        
Перезапуск ошибочных транзакций. Для перезапуска ошибочной транзакции (например, с
идентификатором 8.55.21) используется нижеприведенная DBMS-процедура (параметр DESTINATION не
должен иметь значение NULL, а
указывать на требуемый мастер-сайт). Если значение параметра DEFERRED_TRAN_ID не
указано (=>’’), то перезапускаются все ошибочные транзакции:

Анализ журнала правок БД (EDITIONS)

            В БД
рекомендуется создать и использовать специальную таблицу (например, EDITIONS), куда триггерами ТАБЛИЦА_LOG заносятся все изменения по таблицам
Вашей системы (находящимся только в БД Oracle). Анализ
этой таблицы полезен для сверки с выполненными и выполняемыми транзакциями.
Ниже приведен ряд полезных запросов (находятся в файле ShwAllEd.sql):

Пример
результата данного запроса (ACTION=1,2,3 – добавление,
изменение, удаление):

Необходимые конфигурационные параметры для репликаци

В этом пункте перечислены параметры конфигурационного
файла INIT<SID>.ORA, являющиеся важными для работы приложений. Эти
параметры должны иметь следующие значения.

·        
DISTRIBUTED_LOCK_TIMEOUT       =  300;

·        
DISTRIBUTED_TRANSACTIONS       
    =  5 (для
репликации Мультимастер увеличить до 12-20);

·        
GLOBAL_NAMES                        = TRUE;

·        
JOB_QUEUE_INTERVAL             =   10;

·        
JOB_QUEUE_PROCESSES                 =   4 (для репликации Мультимастер
увеличить до 10 — 12, т.е., примерно, удвоенное кол-во мастер-сайтов);

·        
OPEN_LINKS                      =   10;

·        
PARALLEL_MAX_SERVERS            =   10;

·        
PARALLEL_MIN_SERVERS            =    2;

·        
REPLICATION_DEPENDENCY_TRACKING =
TRUE;

·        
SHARED_POOL_SIZE – не менее 18000000, но не
более 40% ОЗУ сервера (если кроме Oracle на сервере не выполняются другие процессы), а если на сервере уже
установлены другие экземпляры Oracle (например, другая система или учебная БД), то сумма этих параметров не
должна превышать 40% ОЗУ;

·        
DML_LOCK – не менее 300;

·        
PROCESSES                      = 200 (при использовании репликации Мультимастер
увеличить: 300 на destination-сайте, 400 на definition-сайте).