Ошибка ora 6512

The ORA-6512 is a generic placeholder for the PLSQL call stack when an exception is unwound. Each line generated provides information on the PLSQL program unit and line number that results in the actual error.

Cause: Backtrace message as the stack is unwound by unhandled exceptions.
Action: Fix the problem causing exception or write an exception handler for this condition. Or you may need to contact your application administrator or DBA.

ORA-06512 is simply a series of related messages issued at different levels of Oracle. in which the message directly preceding ORA-06512 will list the reason for the error.

The ORA-06512 error itself does not indicate the actual error. It normally indicates the line number at which the Oracle PL/SQL code has caused an error. There will be another main error that occurred in your process and that error happened in the line number as mentioned in the ORA-06512 message description.

Example 1

declare
myname varchar2(5);
begin
myname := 'Nimish Garg';
end;
/
ERROR at line 1:
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 4

Here the main error is “character string buffer too small” for the variable “myname” and it can be corrected by increasing the size of “myname”

Solution:

declare
myname varchar2(20);
begin
myname := 'Nimish Garg';
end;
/

Example 2

create table products (id integer, description varchar2(5));
CREATE OR REPLACE PROCEDURE TEST_ERROR_STACK AS
  V_ID INTEGER;
  V_DESCRIPTION VARCHAR2(100);
BEGIN
  v_ID := 100;
  v_DESCRIPTION := '2007 Honda CRV';
  INSERT INTO PRODUCTS VALUES (V_ID, V_DESCRIPTION);
END TEST_ERROR_STACK;
/

Procedure created.
SQL> exec TEST_ERROR_STACK;
BEGIN TEST_ERROR_STACK; END;

*
ERROR at line 1:
ORA-12899: value too large for column "SCOTT"."PRODUCTS"."DESCRIPTION" (actual:14, maximum: 5)
ORA-06512: at "SCOTT.TEST_ERROR_STACK", line 7
ORA-06512: at line 1

Solution

The actual error for this test case scenario is ORA-12899: value too large for column. For determining what code may have caused the ORA-12899, we need to look at the entire call stack and the program unit and line of code where the error originates. The ORA-6512 is an important placeholder that reports the PLSQL call stack for a specific error that originates from a PLSQL program unit or anonymous block.

The actual error will allows be at the top of the call stack. i.e ORA-12899: value too large for column. The PLSQL call stack is read from the bottom up:

ERROR at line 1:
ORA-12899: value too large for column "SCOTT"."PRODUCTS"."DESCRIPTION" (actual:14, maximum: 5)
ORA-06512: at "SCOTT.TEST_ERROR_STACK", line 7
ORA-06512: at line 1

Walking the Call Stack:

Line 7 in SCOTT.TEST_ERROR_STACK is the line of code that is executing when the error is thrown. You can use the PLSQL call stack to line up the source and line numbers reported to identify the offending specific line of code. i.e Use SQL Developer, SQL PLUS or query the source from the user_source.

In our scenario above, line 7 points to the code:

INSERT INTO PRODUCTS VALUES (V_ID, V_DESCRIPTION);

If we perform a code review around this line of code, we will see we have written code that tries to insert a larger string than the table column can hold.

Option 1: Query the Data Dictionary for the source and identify the line of code.

SQL> COL TEXT HEADING 'SOURCE LINE' FORMAT A60
SQL> select text, line from user_source where name='TEST_ERROR_STACK';

SOURCE LINE                                                        LINE
------------------------------------------------------------ ----------
PROCEDURE TEST_ERROR_STACK AS                                         1
  V_ID INTEGER;                                                       2
  V_DESCRIPTION VARCHAR2(100);                                        3
BEGIN                                                                 4
  v_ID := 100;                                                        5
  v_DESCRIPTION := '2007 Honda CRV';                                  6
  INSERT INTO PRODUCTS VALUES (V_ID, V_DESCRIPTION);                  7
END TEST_ERROR_STACK;                                                 8

8 rows selected.

OR

SQL>  COL TEXT HEADING 'SOURCE LINE' FORMAT A60
SQL> select text, line from user_source where name='TEST_ERROR_STACK'and LINE=7;

SOURCE LINE                                                        LINE
------------------------------------------------------------ ----------
  INSERT INTO PRODUCTS VALUES (V_ID, V_DESCRIPTION);                  7

Option 2: Use a SQL Tool such as SQL Developer to navigate to the offending line of code.

Choose the “Go to Line” option from the Navigate Menu to move the focus to the offending line of code in the source editor.

ORA-06512 troubleshooting

Conclusion

The ORA-6512 error is a generic placeholder for reporting the PLSQL call stack and can be very helpful for finding the offending line of code that results in a specific error. The ORA-6512 is not the actual error but is used to provide additional information for the specific line number in the PLSQL program unit that caused the actual error reported at the top of the call stack. Once the line number is identified, this information can be used as a starting place for further investigation that may be in the form of a code review, adding additional debug statements around that section of code as appropriate or identifying specific SQL that may be causing issues which can then be isolated outside the code and tested standalone for root cause.

Источник

Ernst Leber sent me an email today. He hit an error at a customer upgrading to Oracle 19.9.0 on Exadata with AutoUpgrade. ORA-1422 and ORA-6512 from SYS.DBMS_STATS in Post Upgrade were signaled – and he better flashed back to the Guaranteed Restore Point. He found even a MOS note but still had questions. So time to blog about it in case you hit this error sequence as well.

What happens, and when does it happen?

At first, this is not an AutoUpgrade issue. You may see the same error stack in the post upgrade phase regardless of method (AutoUpgrade, dbupgrade or DBUA) you use to upgrade your database.

This is the error sequence Ernst spotted in the AutoUpgrade console:

Errors in database [ABCD1]
Stage     [GRP]
Operation [STOPPED]
Status    [ERROR]
Info    [
Error: UPG-2000
[Unexpected exception error]
Cause: Creation of GRP failed
For further details, see the log file located at /u01/app/oracle/cfgtoollogs/autoupgrade/ABCD/ABCD1/103/autoupgrade_20210504_user.log]

-------------------------------------------------
Logs: [/u01/app/oracle/cfgtoollogs/autoupgrade/ABCD/ABCD1/103/autoupgrade_20210504_user.log]
-------------------------------------------------


DATABASE NAME: E661
         CAUSE: ERROR at Line 781619 in [/u01/app/oracle/cfgtoollogs/autoupgrade/ABCD/ABCD1/103/dbupgrade/catupgrd20210504111655e660.log]
        REASON: ORA-01422: exact fetch returns more than requested number of rows
        ACTION: [MANUAL]
        DETAILS: 01422, 00000, "exact fetch returns more than requested number of rows"
// *Cause: The number specified in exact fetch is less than the rows returned.

Not nice – but luckily there is a GRP. And he could flash back to it.

In addition, the upgrade summary showed this:

Oracle XML Database                    UPGRADED      19.9.0.0.0  00:01:08
Datapatch                                                        00:01:47
Final Actions                                                    00:01:52
Post Upgrade
    ORA-01422: exact fetch returns more than requested number of rows
    ORA-06512: at "SYS.DBMS_STATS", line 40753
    ORA-06512: at "SYS.DBMS_STATS", line 40037
    ORA-06512: at "SYS.DBMS_STATS", line 38914
    ORA-06512: at "SYS.DBMS_STATS", line 38023
    ORA-06512: at "SYS.DBMS_STATS_INTERNAL", line 24646
    ORA-06512: at "SYS.DBMS_STATS_INTERNAL", line 24633
    ORA-06512: at "SYS.DBMS_STATS", line 37679
    ORA-06512: at "SYS.DBMS_STATS", line 38596
    ORA-06512: at "SYS.DBMS_STATS", line 39740
    ORA-06512: at "SYS.DBMS_STATS", line 40185
    ORA-06512: at "SYS.DBMS_STATS", line 40734
    ORA-06512: at line 149
Post Upgrade                                                     00:00:06

So in the post upgrade phase, the error happens.

There is a MOS Note, and a patch

Ernst found already MOS Note: 2525596.1 – Database Upgrade to 12.2, 18c, 19c fails with ORA-01422, ORA-06512 for SYS.DBMS_STATS. In this note he could read the exact error pattern he saw as well – and the recommendation to apply patch 29213893 to cure this issue.

In addition, the note explains that he hit unpublished BUG 29213893 – DBMS_STATS FAILING WITH ERROR ORA-01422 WHEN GATHERING STATS FOR USER$ TABLE. But it doesn’t give more detail. Actually, the bug’s subject is a bit misleading as it describes the result but doesn’t say anything about the root cause.

The ORA-1422 happens for gather_table_stats on a table sharing its name with remote table.

So you see this effect when:

select OBJ#, DATAOBJ#, NAME, LINKNAME, NAMESPACE, TYPE# from obj$ where name='USER$';

      OBJ#   DATAOBJ# NAME                           LINKNAME             NAMESPACE  TYPE#
---------- ---------- ------------------------------ -------------------- ---------- ----------
     92815      92815 USER$                          DB2K2                         1          2   
        22         10 USER$                                                        1          2

You see that USER$ has two entries – one with the additional attribute “LINKNAME”.

These two rows cause the trouble – and of course, you MUST NOT delete anything here.

What is the solution?

You need to apply a patch. Patch 29213893 will cure this misbehavior. When you apply it, it will exchange two plb files in ?/rdbms/admin:

  • prvtstai.plb – Package Body dbms_stats_internal
  • prvtstas.plb – Package dbms_stats_internal

The README tells you:

Oracle Database 19 Release 19.11.0.0.210420DBRU

OPTIMIZER Patch for Bug# 29213893 for Generic Platforms

This patch is non-RAC Rolling Installable.
This patch is Data Guard Standby-First Installable.

So unfortunately you can’t apply it rolling in a RAC environment. And as all patch bundles (RUs, RURs, BPs) are always “RAC rolling”, this patch will never make it into an RU or BP.

But for me, this means that you should include this patch by default into your new home provisioning procedure to avoid such issues.

Further Links and Information

  • MOS Note: 2525596.1 – Database Upgrade to 12.2, 18c, 19c fails with ORA-01422, ORA-06512 for SYS.DBMS_STATS
  • Patch 29213893
  • BUG 29213893 – DBMS_STATS FAILING WITH ERROR ORA-01422 WHEN GATHERING STATS FOR USER$ TABLE
  • Oracle 19c Installation with 19.11.0, OJVM and one-off patches

–Mike

Источник

Code you wrote has 1.5 mistakes:

  • 1st: if there’s no such row in U_SPONSOR table, select won’t return NULL as you thought, but no_data_found you should handle; I presume that’s what happened to you
  • 0.5th: remove single quotes from ':new.u_sponsorid' in dbms_output.put_line as you’ll display literally that, not the ID value.

Sample tables and trigger:

SQL> create table u_sponsor (u_sponsorid number);

Table created.

SQL> create table user_registration(u_sponsorid number);

Table created.

SQL> create or replace trigger trg_iu_sponsor
  2    before insert or update of u_sponsorid on user_registration
  3    for each row
  4  declare
  5    l_sponsorid varchar2 (2000);
  6  begin
  7   select u_sponsorid
  8     into l_sponsorid
  9     from u_sponsor
 10     where u_sponsorid = :new.u_sponsorid;
 11  exception
 12    when no_data_found then
 13      raise_application_error(-20010,
 14        'Not a valid SPONSORID: '|| :new.u_sponsorid);
 15  end;
 16  /

Trigger created.

Testing: master row first:

SQL> insert into u_sponsor values (200);

1 row created.

Two details:

SQL> insert into user_registration values (100);
insert into user_registration values (100)
            *
ERROR at line 1:
ORA-20010: Not a valid SPONSORID: 100
ORA-06512: at "SCOTT.TRG_IU_SPONSOR", line 10
ORA-04088: error during execution of trigger 'SCOTT.TRG_IU_SPONSOR'


SQL> insert into user_registration values (200);

1 row created.

SQL>

However, I guess you used a trigger to enforce referential integrity just for educational purposes, because — if you want to do that properly, create a foreign key constraint. Something like this:

SQL> create table u_sponsor (u_sponsorid number primary key);

Table created.

SQL> create table user_registration(u_sponsorid number references u_sponsor);

Table created.

SQL> insert into u_sponsor values (200);

1 row created.

SQL> insert into user_registration values (100);
insert into user_registration values (100)
*
ERROR at line 1:
ORA-02291: integrity constraint (SCOTT.SYS_C009854) violated - parent key not found


SQL> insert into user_registration values (200);

1 row created.

SQL>

Источник

Problem Description

——————————-

You are creating a trigger that includes an exception handling block. You wish to raise a user defined error when a certain condition is met within the trigger body using keyword RAISE.

Inside your error handling block you also include a call to RAISE_APPLICATION_ERROR.

Consider this code example —

create table tmp (col1 char(40));

create table violations (col1 varchar2(30));

CREATE OR REPLACE TRIGGER DEMO_RULE_001

BEFORE INSERT OR UPDATE ON TMP

FOR EACH ROW

DECLARE

RULE_001 EXCEPTION;

BEGIN

IF :NEW.col1 = ‘mike’ THEN

dbms_output.put_line(:new.col1);

INSERT INTO VIOLATIONS values (‘violation logged’);

— Raise rule

RAISE RULE_001;

END IF;

EXCEPTION

WHEN RULE_001 THEN

RAISE_APPLICATION_ERROR (-20001,’Guideline Violation, Rule-001.’);

END;

When this trigger is executed, you receive the ora-4088 and ora-6512 errors.

ORA-04088: error during execution of trigger ‘SCOTT.DEMO_RULE_001’

Solution Description

——————————-

You cannot use both RAISE, within the execution block of a trigger, and RAISE_APPLICATION_ERROR, within the exception block.

Explanation

————————

RAISE forces execution to move into the exception block.RAISE_APPLICATION_ERROR, within the exception block, terminates the program.If the trigger body does not complete, the triggering SQL statement and any

SQL statements within the trigger body are rolled back. Thus, execution completes unsuccessfully with a runtime error and it appears as if none of the code within the trigger body gets executed.

Consider this corrected code —

CREATE OR REPLACE TRIGGER DEMO_RULE_001

BEFORE INSERT OR UPDATE ON TMP

FOR EACH ROW

DECLARE

RULE_001 EXCEPTION;

BEGIN

IF :NEW.col1 = ‘mike’ THEN

dbms_output.put_line(:new.col1);

INSERT INTO VIOLATIONS values (‘violation logged’);

— Raise rule

RAISE RULE_001;

END IF;

EXCEPTION

WHEN RULE_001 THEN

—raise_application_error(-20001, ‘Guideline Violation, Rule-001.’);

dbms_output.put_line(‘Guideline Violation, Rule-001.’);

END;

Oracle Support Doc ID 103293.1

Источник

Автор признателен руководителям и сотрудникам ЗАО «Нефтегазсистемы»,
начальникам и персоналу вычислительных центров региональных управлений ОАО «Транснефть»,
c чьей помощью был разработан и внедрен данный Oracle-проект.

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

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

Ошибка ORA-00020

ORA-00020: maximum number of
processes (num) exceeded

         / превышено максимальное
количество процессов (ном)

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

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

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

Из
практики:

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

Ошибка ORA-00060

ORA-00060: deadlock detected
while waiting for resource

         / во время ожидания ресурса
произошла взаимоблокировка

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

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

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

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

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

Из
практики:

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

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

Ошибка ORA-00600

ORA-00600:
internal error code, arguments: [num],[?],[?],[?],[?],[?] ,[?],[?]

         / код внутренней ошибки,
аргументы: [ном],[?],[?],[?], [?],[?],[?],[?]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из
практики:

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

Ошибка ORA-01400

ORA-01400: cannot
insert NULL into (PLIPEKN.EDITIONS.ID)

         / Пропущен первичный ключ
или обязательный

           (NOT NULL) столбец, или NULL во время операции INSERT

ORA-06512: at
«PLIPEKN.WORKS_LOG», line 16

ORA-04088: error
during execution of trigger ‘PLIPEKN.WORKS_LOG’

ORA-06512: at
«PLIPEKN.WORKS$RP», line 831

ORA-01085:
preceding errors in deferred rpc to «PLIPEKN.WORKS$RP. REP_UPDATE»

ORA-02063:
preceding 5 lines from PLI_NORD

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

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

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

Из
практики:

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

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

create or replace
trigger EDITIONS_COR

  before insert
or update on EDITIONS

  for each row

begin

  if INSERTING
then

    select
EDITIONS_SEQ.nextval into :new.ID from DUAL;

  end if;

 
:new.CORDATE:=SYSDATE;

 
:new.USERNAME:=USER;

end;

Ошибка ORA-01403

ORA-01403: data not found

         / данные не найдены

ORA-06512: на
«PLIPEKN.DRFEAT$RP», строки 321

ORA-01085: ошибка обработки в
задержанном rpc в «PLIPEKN.DRFEAT$RP. REP_UPDATE«

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

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

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

Из
практики:

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

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

Ошибка ORA-01591

ORA-01591: lock held by
in-doubt distributed transaction 6.58.10015

         / блокировка, удерживаемая
распред. транзакцией 6.58.10015,

           находящейся в неопр. сост.

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

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

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

Из
практики:

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

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

Ошибка ORA-02049

ORA-02049: time-out:
distributed transaction waiting for lock

         / таймаут: распределенная
транзакция ждет блокировку

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

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

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

Из
практики:

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

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

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

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

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

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

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

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

Ошибка ORA-02266

ORA-02266: unique/primary
keys in table referenced by enabled

           foreign keys

         / таблица имеет некие уникальные/первичные
ключи,

           на которые ссылаются внешние ключи

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

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

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

select
CONSTRAINT_NAME, TABLE_NAME, STATUS

from
USER_CONSTRAINTS

where
R_CONSTRAINT_NAME in (

 
select CONSTRAINT_NAME

  from
USER_CONSTRAINTS

  where
TABLE_NAME=’TABNAM’);

Из практики:

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

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

Ошибка ORA-02449

ORA-02449: unique/primary keys in table referenced by
foreign keys

         / уникальный/первичный
ключ в таблице,

           на которую
ссылаются по внешнему ключу

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

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

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

select * from
USER_CONSTRAINTS where table_name = «TABNAM»;

Из практики:

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

Ошибка ORA-03113

ORA-03113:
end-of-file on communication channel

         / конец файла по
коммуникационному каналу

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

Причина:       По коммуникационному каналу передан сигнал
конца файла, который не был обработан соответствующим образом программным
обеспечением 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

ORA-04030: out of
process memory when trying to allocate 524316 bytes

           (pga heap, KSFQ Buffers)

         / выход за пределы
памяти процесса при попытке выделить

           524316 байт (стр)

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

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

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

Из
практики:

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

Ошибка ORA-04052

ORA-04052: error
occurred when looking up remote object

          
REPADMIN.SYS @ULAN.WORLD

         / ошибка возникла
во время поиска удаленного объекта

           REPADMIN.SYS
@ULAN.WORLD

ORA-00604: error
occurred at recursive SQL level 2

ORA-12154:
TNS:could not resolve service name

ORA-06512: at
«SYS.DBMS_REPCAT_MAS», line 674

ORA-06512: at
«SYS.DBMS_REPCAT», line 516

ORA-06512: at line 2

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

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

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

Из практики:

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

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

Ошибка ORA-06502

ORA-06502: PL/SQL:
numeric or value error

         / PL/SQL: ошибка в числе или в
значении

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

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

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

Из практики:

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

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

Ошибка ORA-12011

ORA-12011: execution of 1
jobs failed

         / сбой при выполнении 1
задания

ORA-06512: at «SYS.DBMS_IJOB», line 255

ORA-06512: at «SYS.DBMS_JOB»,
line 218

ORA-06512: at line 2

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

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

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

Из
практики:

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

Ошибка ORA-23308

ORA-23308: object
PLIPEKN.COUNTRY$RU does not exist or is invalid

         / объект PLIPEKN.COUNTRY$RU
либо неправильный,

           либо не
существует

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

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

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

Из
практики:

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

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

ВНИМАНИЕ
!

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

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

Ошибка ORA-23309

ORA-23309: object
PLIPEKN.COUNTRY of type TABLE exists

         / объект PLIPEKN.COUNTRY типа
TABLE существует

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

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

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

Из
практики:

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

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

Ошибка ORA-23312

ORA-23312: not
the masterdef according to …

         / не masterdef согласно …

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

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

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

Из
практики:

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

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

Ошибка ORA-23313

ORA-23313: object
group PLIPEKN7 is not mastered at PLI_BONN.WORLD

         / схема PLIPEKN7 не явл.главной для PLI_BONN.WORLD

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

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

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

Из практики:

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

Ошибка ORA-23374

ORA-23374: object
group PLIPEKN0 already exists

         / мастер—группа PLIPEKN0 уже существует

ORA-06512: at
«SYS.DBMS_SYS_ERROR», line 86

ORA-06512: at
«SYS.DBMS_REPCAT_MAS», line 1598

ORA-06512: at
«SYS.DBMS_REPCAT», line 113

ORA-06512: at line 2

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

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

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

Из практики:

Причина:
Ошибка возникает при попытке
«прицепить» дест-сайт к мастер-группе деф-сайта, если на этом дест-сайте
такая мастер-группа уже существует. Эта ситуация возникает, если сайт пытаются
пересоздать (см. Часть 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):

select GNAME from
ALL_REPOBJECT

where
ONAME=’BRANCH’ and TYPE=’TABLE’;

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

Листинг скрипта
на подсчет записей всех таблиц БД

set echo off

set feed off

set term off

set head off

set pages 10000

col L newline

————————————————————

spool temp.sql

————————————————————

prompt set head off

prompt set feed off

prompt set term on

prompt set recsep off

—prompt set echo off

prompt variable iC number;;

prompt execute :iC:=0;;

prompt begin

select

  ‘select :iC + count(*) into :iC’,’from
‘||T.TABLE_NAME||’;’ L

from

  ALL_REPOBJECT R, USER_TABLES T

where

  R.GNAME=’PLIPEKN0′ and R.TYPE=’TABLE’ and

  R.ONAME = T.TABLE_NAME

/

prompt end;;

prompt /

prompt select :iC from DUAL;;

—prompt set feed on

spool off

————————————————————

set term on

set pages 0

————————————————————

@temp

————————————————————

set pages 23

set feed on

set head on

Сформированный и
запускаемый далее скрипт Temp.sql имеет следующий вид:

set
head off

set
feed off

set
term on

set
recsep off

variable
iC number;

execute
:iC:=0;

begin

 
select :iC + count(*) into :iC from BRANCH;

 
select :iC + count(*) into :iC from CONOPF;

.

.

.

select
:iC + count(*) into :iC from TYPEM;

select
:iC + count(*) into :iC from TYPEOBJECT;

end;

/

select
:iC from DUAL;

/

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

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

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

select GNAME,
count(*) from ALL_REPOBJECT

where
TYPE=’TABLE’

group by GNAME

order by GNAME;

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

select ONAME from
ALL_REPOBJECT

where
(GENERATION_STATUS <> ‘GENERATED’) and TYPE=’TABLE’;

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

select GNAME,
ONAME from ALL_REPOBJECT

where
STATUS=’ERROR’ and TYPE=’TABLE’ order by GNAME;

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

select GNAME,
count(*) from ALL_REPOBJECT

where
STATUS=’ERROR’ and TYPE=’TABLE’

group by GNAME

order by GNAME;

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

select R.GNAME,
count(A.ID) CNT

from
ALL_REPOBJECT R, EDITIONS A

where

  R.TYPE=’TABLE’
and R.ONAME=A.TABNAME and

 
trunc(A.CORDATE)=trunc(SYSDATE-1)

group by R.GNAME

order by
count(A.ID);

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

GNAME                                CNT

——————————
———

PLIPEKN6                              
4

PLIPEKN0                              
6

PLIPEKN4                             
35

PLIPEKN5                             
93

PLIPEKN3          
                  143

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

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

select

 
ID, to_char(TIMESTAMP,’DD.MM.YYYY HH24:MI:SS’) TIME,

 
substr(MASTER,1,15) MR, substr(GNAME,1,8) GR,

 
substr(ONAME,1,12) OB, substr(MESSAGE,1,40)

from

 
USER_REPCATLOG

where

 
STATUS=’ERROR’ and TYPE=’TABLE’;

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

select

 
ID, to_char(TIMESTAMP,’DD.MM.YYYY HH24:MI:SS’) TIME,

 
substr(MASTER,1,15) MAST, substr(ONAME,1,12) OB,

 
STATUS, REQUEST, ERRNUM

from

 
USER_REPCATLOG

where

 
GNAME=’PLIPEKN0′

order
by ID;

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

select

 
ID, to_char(TIMESTAMP,’DD.MM.YYYY HH24:MI:SS’) TIME,

 
substr(MASTER,1,15) M, substr(GNAME,1,12) G,

 
substr(ONAME,1,12) O, STATUS, REQUEST, ERRNUM

from

 
USER_REPCATLOG

where

 
ROWNUM < 10;

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

   select count(*) from
USER_REPCATLOG;

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

select  
substr(GNAME,1,12) GR, count(*) REQ_NUM

from    
USER_REPCATLOG

group
by GNAME

order
by GNAME;

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

select

 
substr(GNAME,1,12) GR, REQUEST, STATUS, count(*) REQ_NUM

from

 
USER_REPCATLOG

group
by

 
GNAME, REQUEST, STATUS

order
by

 
GNAME, REQUEST, STATUS

;

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

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

select count(*) from
DEFTRAN;

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

select
substr(DBLINK,1,20), count(*) CNT from DEFTRANDEST

group by DBLINK
order by DBLINK;

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

select

 
substr(DD.DBLINK,1,20) DL,

 
trunc(D.START_TIME) ST,

  count(DD.DEFERRED_TRAN_ID) CT

from

  DEFTRANDEST DD,
DEFTRAN D

where

  DD.DEFERRED_TRAN_ID=D.DEFERRED_TRAN_ID

group by

 
substr(DD.DBLINK,1,20), trunc(D.START_TIME)

order by

  DL, ST

;

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

DL                  
ST               CT

———————
——— ———

PLI_ANTA.WORLD      
29-FEB-00       939

PLI_ANTA.WORLD      
01-MAR-00      6160

PLI_ANTA.WORLD      
02-MAR-00      7546

PLI_ANTA.WORLD      
03-MAR-00       245

PLI_ANTA.WORLD      
25-FEB-00      1580

PLI_ANTA.WORLD      
26-FEB-00       570

PLI_ANTA.WORLD      
27-FEB-00       165

PLI_ANTA.WORLD      
28-FEB-00      8753

PLI_ANTA.WORLD      
29-FEB-00      7491

PLI_ANTA.WORLD      
01-MAR-00      6160

PLI_ANTA.WORLD      
02-MAR-00      7546

PLI_ANTA.WORLD      
03-MAR-00       245

12
rows selected.

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

begin

 
DBMS_DEFER_SYS.DELETE_TRAN(

   
deferred_tran_id => ‘6.19.11941’,

   
destination
=> NULL);

end;

/

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

begin

 
DBMS_DEFER_SYS.DELETE_TRAN(

   
deferred_tran_id => »,

   
destination => NULL);

end;

/

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

DBMS_JOB.RUN(job
=> 204);

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

select count(*)
from DEFERROR;

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

begin

 
DBMS_DEFER_SYS.DELETE_ERROR(

   
deferred_tran_id => ‘8.55.21’,

   
destination => NULL);

end;

/

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

begin

 
DBMS_DEFER_SYS.EXECUTE_ERROR(

   
deferred_tran_id => ‘8.55.21’,

   
destination => ‘PLI_ANTA’);

end;

/

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

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

— Сводка по таблицам и датам последних правок

select TABNAME, count(TABNAME)
C, max(CORDATE) D

  from EDITIONS

  /*where CORDATE>SYSDATE-5*/

  group by TABNAME

  order by TABNAME;

— Сводка по видам правок за диапазон дат

select ACTION, count(ACTION)
C

  from EDITIONS

  where trunc(CORDATE)
between trunc(SYSDATE)-2 and trunc(SYSDATE)

  group by ACTION

  order by ACTION;

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

ACTION            C

——— ———

        1       431

        2       247

        3        44

— where to_char(CORDATE,’dd.mm.yy’)=to_char(SYSDATE-1,
‘dd.mm.yy’)

select TABNAME, count(TABNAME)
C

  from EDITIONS

  where trunc(CORDATE)=trunc(SYSDATE-1)

  and ACTION=1

  group by TABNAME

  order by TABNAME;

— Сводка по таблицам, которые правились за
предыдущие дни

select TABNAME, count(TABNAME)
C

  from EDITIONS

  where trunc(CORDATE)>trunc(SYSDATE-2)

  group by TABNAME

  order by TABNAME;

— Все изменения (добавления) за день (для сверки с
репликацией)

select TABNAME,TABKEY,ACTION,to_char(CORDATE,’dd.mm.yy
hh:mi:ss’) DL

  from EDITIONS

  where to_char(CORDATE,’dd.mm.yy’)=to_char(SYSDATE-1,’dd.mm.yyyy’)

—   and ACTION=1

  order by CORDATE;

— Общее кол-во изменений за день

select count(*) CNT

  from EDITIONS

  where to_char(CORDATE,’dd.mm.yyyy’)=to_char(SYSDATE,’dd.mm.yyyy’)

  and ACTION=1;

— Выборка добавленных в таблицу записей за 1 день

select T.ID, T.NAME, A.CORDATE

  from PIPECROSS T, EDITIONS
A

  where trunc(T.CORDATE)=trunc(SYSDATE-1)

  and T.ID=A.TABKEY and A.TABNAME=’PIPECROSS’
and A.ACTION=1

  and trunc(A.CORDATE)=trunc(SYSDATE-1)

  order by A.CORDATE;

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

В этом пункте перечислены параметры конфигурационного
файла 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-сайте).

Источник

Понравилась статья? Поделить с друзьями:
  • Ошибка ora 32004
  • Ошибка ora 305500
  • Ошибка ora 28040
  • Ошибка ora 28001
  • Ошибка ora 2000