Error ora 06519 - Исправление ошибок и поиск оптимальных решений проблем

AUTONOMOUS_TRANSACTION pragma is a subprogram marked with this pragma can do SQL operations independently and its commit or roll back those operations, without committing or rolling back the data in the main transaction. Subprogram doing independent Units of Work with Autonomous Transactions.

Main advantage:
1. Autonomous transaction is work fully independent.
2. It shares no locks, resources, or commit-dependencies with the main transaction.
3. You can do work like log events, increment retry counters, and so on, even if the main transaction rolls back.

Error:
We have TEST user on PDB1 database

--create or replace procedure with Autonomous transaction create or replace procedure update_salary is pragma autonomous_transaction; begin update test.emp set salary = salary +100 where employee_id = 100; end; /


--Use updates_salary prcedure in this transaction

 set serveroutput on

 declare

 l_salary number;

 begin

 select salary into l_salary from emp where employee_id = 100;

 dbms_output.put_line(l_salary);

 update_salary;

 end;

 /

ERROR at line 1: ORA-06519: active autonomous transaction detected and rolled back ORA-06512: at "TEST.UPDATE_SALARY", line 6 ORA-06512: at line 6

Cause
For UPDATE_SALARY automonous_trasaction procedure which is created act as seperate transaction. It independend from main transaction.
So you need to specifiy the ROLLBACK and COMMIT for it in the procedure.

Solution
Use rollback and commit statement in the automonous_trasaction procedure/function/trigger to avoid error.

Modified the procedure with commit/rollback will execute it successfully
--create or replace procedure with Autonomous transaction create or replace procedure update_salary is pragma autonomous_transaction; begin update test.emp set salary = salary +100 where employee_id = 100; commit; end; /

--Use updates_salary prcedure in this transaction set serveroutput on declare l_salary number; begin select salary into l_salary from emp where employee_id = 100; dbms_output.put_line(l_salary); update_salary; end; / PL/SQL procedure successfully completed.

Источник

Содержание

Smart way of Technology
Worked in Database technology for fixed the issues faced in daily activities in Oracle, MS SQL Server, MySQL, MariaDB etc.
ORA-06519: active autonomous transaction detected and rolled back
ORA-06519: active autonomous transaction detected and rolled back
Ramugvs’s Blog
Here is some Tech Info…..
ORA-06519: active autonomous transaction detected and rolled back ORA-06512 in Oracle SOA (BPEL / OSB / ESB)
ORA-06519 error
Error ora 06519 active autonomous transaction detected and rolled back
Введение
Почему имеет смысл использовать эту возможность
Выполнение DDL в триггерах
Запись в структуру базы данных в функциях, вызываемых из SQL
Как использовать автономные транзакции
За и против
Скрипты

Smart way of Technology

Worked in Database technology for fixed the issues faced in daily activities in Oracle, MS SQL Server, MySQL, MariaDB etc.

ORA-06519: active autonomous transaction detected and rolled back

Error:
We have TEST user on PDB1 database

—create or replace procedure with Autonomous transaction
create or replace procedure update_salary
is
pragma autonomous_transaction;
begin
update test.emp set salary = salary +100 where employee_id = 100;
end;
/

—Use updates_salary prcedure in this transaction
set serveroutput on
declare
l_salary number;
begin
select salary into l_salary from emp where employee_id = 100;
dbms_output.put_line(l_salary);
update_salary;
end;
/

ERROR at line 1:
ORA-06519: active autonomous transaction detected and rolled back
ORA-06512: at «TEST.UPDATE_SALARY», line 6
ORA-06512: at line 6

Solution
Use rollback and commit statement in the automonous_trasaction procedure/function/trigger to avoid error.

Источник

Ramugvs’s Blog

Here is some Tech Info…..

ORA-06519: active autonomous transaction detected and rolled back ORA-06512 in Oracle SOA (BPEL / OSB / ESB)

javax.xml.ws.soap.SOAPFaultException: Exception occurred when binding was invoked. Exception occured during invocation of JCA binding: “JCA Binding execute of Reference operation ‘DoTheOperation’ failed due to: Stored procedure invocation error. Error while trying to prepare and execute the SCHEMA.PACK_MAIN.SAMPLE_SP. An error occurred while preparing and executing the SCHEMA.PACK_MAIN.SAMPLE_SP. Cause: java.sql.SQLException: ORA-06519: active autonomous transaction detected and rolled back ORA-06512: at ” SCHEMA.PACK_MAIN.SAMPLE_SP “, line 1751 ORA-06512: at line 1 “. The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution.

First of all, this issue occurs in different scenarios, each scenario has its own workaround. Please examine listed cases for suitable scenario for easy solution.

Before getting in to explanation:

Here the Original cause info…..

ORA-06519:	active autonomous transaction detected and rolled back
Cause:	Before returning from an autonomous PL/SQL block, all autonomous transactions started within the block must be completed (either committed or rolled back). If not, the active autonomous transaction is implicitly rolled back and this error is raised.
Action:	Ensure that before returning from an autonomous PL/SQL block, any active autonomous transactions are explicitly committed or rolled back. ———————————————————————– 06520 through 06529 reserved for Foreign function errors

Scenario 1: If Error occurred in Oracle Fusion middleware/ SOA

Cause: In Oracle Fusion/SOA DB adapters ‘COMMIT is Basic behavior of DB adapter’, by changing DB adapter properties, default behavior can changed. But in normal situation, SOA component try to commit the transaction at the end of the process (Design time controls are available to manipulate COMMIT and ROLLBACK).

Solution: Solution for this issue, it’s depends on the situation, to resolve this issue, follow DB adapter level configuration or Use component design time controls or introduce “PRAGMA AUTONOMOUS_TRANSACTION” in PL/SQL code.

Note: If same error occurs after using listed solution, follow Scenario 2.

Here is sample PL/SQL Stored proc code with PRAGMA AUTONOMOUS_TRANSACTION to use inner commits or rollbacks.

PROCEDURE TEST_PROC
(x_MESSAGE OUT NOCOPY VARCHAR2
,p_SOME_ID IN NUMBER
)
IS
PRAGMA AUTONOMOUS_TRANSACTION;
lc_MESSAGE VARCHAR2(240);
l_SOME_ID NUMBER;
BEGIN
———- Do some thing ———-
COMMIT;
———- Do some thing ———-
COMMIT;
IF nvl(p_SOME_ID ,0) = 0 THEN
x_MESSAGE := ‘Error’;
ROLLBACK;
END IF;
———- Do some thing ———-
COMMIT;
END TEST_PROC;

Scenario 2: If Error occurred in Oracle Fusion middleware/ SOA , After applying Scenario 1.

Cause: SOA Service testing might have taken place when Database Store Procedure or Function or DB code pack in compile and commit mode.

In this situation, there won’t be any visible hanging or dead lock threads in SOA console. But under the DB adapter layer the communication is totally blocked for new changes and it’s still trying to work with old ‘Database Store Procedure or Function or DB code pack’.

Solutions: In this case there are two different solutions are available.

Solution 1: Kill Active connections in DB or bounce DB (Yah, this might not be a good trick, Try it out, this magic will work).

Solution 2: If DB bounce is not possible (It’s not that easy while working with Oracle APPS/EBS/EBZ, WMS, OTM ect), Bounce SOA Server.

Note: Why SOA bounce required? Some where the deadlock needs to clear. Sometimes it will lead into bounce both DB and SOA.

Источник

ORA-06519 error

I have a table and creat index,like follows:
create table T
*(*
ID NUMBER not null,
PROCESSED_FLAG VARCHAR2(1),
PAYLOAD VARCHAR2(20)
*)*

create index T_IDX on T (DECODE(PROCESSED_FLAG,’N’,’N’))

Then I insert some data
ID P PAYLOAD
———- — ———————
1 Y payload 1
2 N payload 2
3 Y payload 3
4 N payload 4
5 Y payload 5

Then I create a functioin like follows:

create or replace function get_first_unlocked_row
return t%rowtype
as
resource_busy exception;
pragma exception_init(resource_busy,-54);
l_rec t%rowtype;
begin
for x in (select rowid rid
from t
where decode(processed_flag,’N’,’N’)=’N’)
loop
begin
select into l_rec*
from t
where rowid=x.rid and processed_flag=’N’
for update nowait;
return l_rec;
exception
when resource_busy then null;
when no_data_found then null;
end;
end loop;
return null;
end;

Then call the function like follows:
declare
l_rec t%rowtype;
begin
l_rec:=get_first_unlocked_row;
dbms_output.put_line(‘I got row ‘||l_rec.id||’, ‘||l_rec.payload);
end;
*/*

The result is follows:
I got row 2, payload 2

Then I use autonomous to try again

declare
pragma autonomous_transaction;
l_rec t%rowtype;
begin
l_rec:=get_first_unlocked_row;
dbms_output.put_line(‘I got row ‘ || l_rec.id ||’, ‘||l_rec.payload);
end;
*/*

The result is follows:
I got row 4, payload 4
declare
*
Line 1 raise error:
ORA-06519: active autonomous transaction detected and rolled back
ORA-06512: line 7

Источник

Error ora 06519 active autonomous transaction detected and rolled back

Function Based Indexes, by Tomas Kyte

Эта статья впервые была размещена на сайте www.oramag.ru

От редакции Russian Oracle Magazine

В этом номере ROIM с любезного разрешения автора начинается публикация серии статей Т.Кайта (Tomas Kyte), известного автора и ведущего колонки «Ask Tom» журнала Oracle Magazine. Не часто можно встретить столь глубокое знание предмета и искреннее желание поделиться с читателями. Мы продолжим перевод и публикацию работ Т.Кайта в следующих номерах журнала. Самые нетерпеливые наши читатели могут ознакомиться с творчеством Т.Кайта на его личном сайте http://govt.oracle.com/

tkyte , могут обратиться к нему с вопросами в Oracle Magazine http://osi.oracle.com/wa/ask/owa/ask_tom_pkg.main. Я хотел бы, чтобы Вы при чтении этих статей испытали такую же радость, что и я при подготовке их к печати.

Введение

Автономные транзакции предоставляют новый метод контролирования транзакций в хранимых процедурах. Автономные транзакции позволяют создавать новые подтранзакции (subtransaction), которые могут сохранять или отменять изменения вне зависимости от родительской транзакции. Мы рассмотрим, разбирая конкретные примеры:

Почему имеет смысл использовать эту возможность
Как использовать автономные транзакции
За и против автономных транзакций
Примеры использования

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

SQL> create table t ( x int );
Table created.

SQL>
SQL> create or replace procedure insert_into_t
2 as
3 pragma autonomous_transaction ;
4 begin
5 insert into t values ( 1 );
6 commit;
7 end;
8 /
Procedure created.

SQL> select * from t;
no rows selected

SQL> begin
2 insert into t values ( -1 );
3 insert_into_t;
4 rollback;
5 end;
6 /
PL/SQL procedure successfully completed.

SQL> select * from t;
X
———-
1

В вышеприведенном примере, мы создали процедуру INSERT_INTO_T. В этой процедуре используется новая прагма AUTONOMOUS_TRANSACTION. Эта директива сообщает базе данных, что данная процедура будет выполняться как новая подтранзакция, независимая от родительской транзакции. Эта процедура просто вставляет запись со значением ‘1’ в таблицу T и сохраняет изменения. Затем мы создаем анонимный PL/SQL-блок, в котором вставляется значение –1 в таблицу T, вызывается хранимая процедура INSERT_INTO_T и rollback — откат изменений. До внедрения автономных транзакций, оператор commit в процедуре INSERT_INTO_T сохранял бы не только ту работу, которую выполнила процедура (вставка ‘1’), но и любую внешнюю работу, выполненную сессией, но еще не сохраненную (вставка ‘-1’ в анонимном блоке). Оператору Rollback нечего было делать, поскольку оператор commit в процедуре сохранил обе вставки. Мы же видим, что в случае с автономными транзакциями это не так. Работа, выполненная в процедуре, помеченной AUTONOMOUS_TRANSACTION, была сохранена, в то время как работа, выполненная вне автономной транзакции, была отменена.

Предыдущие версии Oracle поддерживали внутренние автономные транзакции. Они известны как рекурсивные SQL-операции. Например, при выборе из некэшируемой последовательности, выполняется рекурсивная транзакция для немедленного увеличения последовательности. Это обновление последовательности сразу же сохраняется, и становится видимым для других транзакций, при этом для всей транзакции сохранение еще не выполнялось. Кроме того, если вы откатите транзакцию, то увеличение последовательности останется неизменным, оно не будет откачено вашей транзакцией, поскольку эти изменения уже сохранены. Управление памятью и другие внутренние операции выполняются аналогичным рекурсивным способом.

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

Почему имеет смысл использовать эту возможность

Аудит, который нельзя откатить

Раньше разработчики приложений часто задавали вопрос: “Как можно надежно отследить попытку модифицировать информацию?”. Для этого многие пытались (и безуспешно) использовать триггеры. Триггер должен обнаружить обновление, и если пользователь изменяет данные, которые он не имет права менять, триггер должен создавать аудит-запись и прерывать обновление. К сожалению, при откате обновления, откатывается также и аудит-запись, то есть все или ничего, ошибка должна реализоваться или о ней не будет никаких сведений. Теперь, с появлением автономных транзакций, мы сможем надежно зафиксировать в аудит-таблице попытку выполнить операцию, а также откатить саму операцию. И это даст нам возможность сказать конечному пользователю, что он не может изменять эти данные и что у нас есть запись о пытке это сделать .

Вот небольшой пример:

SQL> REM Создадим для своей работы копию демонстрационной таблицы EMP.
SQL> REM Предоставим всем пользователям право модифицировать эту
SQL> REM таблицу.
SQL> create table emp as select * from scott.emp;
Table created.

SQL> grant all on emp to public;
Grant succeeded.

SQL> REM Это аудит-таблица. Мы будем фиксировать
SQL> REM имя пользователя, дату предпринятой попытки и
SQL> REM некоторое сообщение, описываещие операцию,
SQL> REM которую пытались выполнить над таблицей emp.
SQL> create table audit_tab (uname varchar2(30), dt date, msg varchar2(4000));
Table created.

SQL> create or replace trigger emp_trigger
2 before update of SAL on emp
3 for each row
4 declare
5 — эта прагма позволит нашему триггеру сохранить
6 — запись в аудит-журнале.
7 — Мы можем затем прервать выполнение оператора,
8 — вызвавшего триггер, не допустив обновления
9 pragma autonomous_transaction;
10 l_cnt number;
11 begin
12 — Этот запрос проверяет, действительно ли работник,
13 — данные о котором меняются, подчиняется сотруднику,

— выполняющему обновление.Для построения иерархии удобно
— использовать конструкцию connect by.

15 — Поскольку предложение where обрабатывается после того,
16 — как иерархия построена,здесь можно использовать exists
17 select count(*)
18 into l_cnt
19 from dual
20 where exists ( select empno
21 from emp
22 where empno = :new.empno
23 start with mgr =
24 (select empno from emp where ename=USER)
25 connect by prior empno = mgr );
26
27 — Если exists ничего не возвращает, значит мы пытаемся
30 — обновить данные о работнике, нам не подчиненного.
28 — Необходимо зафиксировать попытку и прервать выполнение
29 — этой операции. Зарплата сотрудника не будет обновлена,
31 — а у нас останется запись об этой попытке изменения.
32 if ( l_cnt = 0 )
33 then
34 insert into audit_tab values ( user, sysdate,
35 ‘Попытка обновления зарплаты ‘ ||
36 :new.ename || ‘-‘ || :new.empno);
37 commit;
38
39 raise_application_error( -20001,

‘Вы пытаетесь сделать то, что вы не имеете права ‘||

41 ‘ делать, и мы знаем об этом’);
42 end if;
43 end;
44 /
Trigger created.

Итак, вот что мы имеем на данный момент: таблицу EMP, данные которой мы хотим защитить, таблицу AUDIT_TAB, в которую мы будем записывать неудачные попытки обновления данных (попытки, которые мы предотвратили), и триггер, который использует автономную транзакцию для выполнения своей работы. Теперь попробуем выполнить некоторые DML операции, используя учетные записи различных пользователей, и посмотрим, что получится:

SQL> show user
USER is «DEMO_AUTONOMOUS»
SQL> REM Сначала мы попытаемся обновить запись, используя
SQL> REM учетную запись demo. Это нам не удастся, как покажет
SQL> REM результат выборки из emp, приведенный ниже, однако,
SQL> REM запись о попытке будет присутствовать в аудит-таблице.
SQL> select empno, ename, mgr, sal
2 from emp where ename = ‘ADAMS’; SQL> update emp set sal = sal*2 where ename = ‘ADAMS’;
update emp set sal = sal*2 where ename = ‘ADAMS’
*
ERROR at line 1:
ORA-20001: Вы пытаетесь сделать то, что вы не имеете права делать, и мы знаем об этом
ORA-06512: at «DEMO_AUTONOMOUS.EMP_TRIGGER», line 36
ORA-04088: error during execution of trigger ‘DEMO_AUTONOMOUS.EMP_TRIGGER’

SQL> select empno, ename, mgr, sal
2 from emp where ename = ‘ADAMS’; SQL> select * from audit_tab;

UNAME DT MSG
—————————— ——— ——————————
DEMO_AUTONOMOUS 10-JUN-99 Попытка обновления зарплаты
ADAMS-7876

Поскольку пользователь DEMO_AUTONOMOUS не имеет подчиненных сотрудников в таблице EMP, это обновление завершается неудачно. Выборка (SELECT) из таблицы EMP демонстрирует, что обновление не было произведено, а выборка из таблицы AUDIT_TAB показывает, что нам удалось обнаружить и зафиксировать попытку обновления.

Теперь, рассмотрим пользователя, который может обновлять некоторые данные. Пользователь SCOTT имеет одного работника (ADAMS), который подчиняется ему.

SQL> show user
USER is «SCOTT»

SQL> REM Теперь, попробуем сделать то же самое, используя
SQL> REM учетную запись пользователя, который имеет подчиненных
SQL> REM ему работников.Эти действия будут успешными, как
SQL> REM показано ниже.
SQL> select empno, ename, mgr, sal
2 from demo_autonomous.emp where ename = ‘ADAMS’; SQL> update demo_autonomous.emp set sal = sal*2 where ename = ‘ADAMS’;
1 row updated.

SQL> select empno, ename, mgr, sal
2 from demo_autonomous.emp where ename = ‘ADAMS’; SQL> REM Попробуем теперь обновить запись, которую мы не имеем
SQL> REM права обновлять (нашу собственную зарплату), и тут мы
SQL> REM будем схвачены.
SQL> select empno, ename, mgr, sal
2 from demo_autonomous.emp where ename = ‘SCOTT’; SQL> update demo_autonomous.emp set sal = sal*2 where ename = ‘SCOTT’;
update demo_autonomous.emp set sal = sal*2 where ename = ‘SCOTT’
*
ERROR at line 1:
ORA-20001: Вы пытаетесь сделать то, что вы не имеете права делать, и мы знаем об этом
ORA-06512: at «DEMO_AUTONOMOUS.EMP_TRIGGER», line 36
ORA-04088: error during execution of trigger ‘DEMO_AUTONOMOUS.EMP_TRIGGER’

SQL> select empno, ename, mgr, sal
2 from demo_autonomous.emp where ename = ‘SCOTT’; SQL> connect demo_autonomous/demo_autonomous
Connected.

SQL> select * from audit_tab;

UNAME DT MSG
—————————— ——— ——————————
DEMO_AUTONOMOUS 01-JUN-99 Попытка обновления зарплаты
ADAMS-7876
SCOTT 01-JUN-99 Попытка обновления зарплаты
SCOTT-7788

Итак, здесь показано, что SCOTT может обновлять некоторые данные, но вновь, при попытке обновления данных, которые он не имеет права обновлять, SCOTT был схвачен.

Выполнение DDL в триггерах

Раньше нужно было использовать пакет DBMS_JOB, чтобы спалировать выполнение DDL-предложений после фиксации (commit) транзакции. Этот способ доступен и сейчас, и во многих случаях он является по-прежнему правильным решением . Привлекательной стороной использования DBMS_JOB для планирования выполнения DDL-предложений является то, что это позволяет включить DDL-предложения в транзакцию. Если триггер ставит работу (job) в очередь на выполнение, а эта работа создает пользователя, то при откате родительской транзакции, работа, создающая пользователя, будет также отменена. Ни записей в вашей таблице пользователей, ни пользователя базы данных. Используя же в этом сценарии автономные транзакции, вы создадите пользователя базы данных, но не вставите запись в таблицу жителей. [ Прим. редактора: то есть в ту таблицу, вставка в которую была причиной возбуждения автономной транзакции. Автор здесь предупреждает о возможном нарушении целостности данных.] Принимать решение о том, какой именно метод использовать, нужно в зависимости от требований к системе.

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

SQL> create user demo_ddl identified by demo_ddl;
User created.

SQL> REM В триггере приведенном ниже, мы хотим предоставить
SQL> REM привилегии CONNECT и RESOURCE другим пользователям.
SQL> REM Поэтому, у нашего пользователя должны права на connect
SQL> REM и resource с параметром WITH ADMIN OPTION, так чтобы он
SQL> REM мог передавать эти привилегии другим пользователям.

SQL> grant connect, resource to demo_ddl with admin option ;
Grant succeeded.

SQL> REM Кроме того, поскольку мы хотим создавать и удалять
SQL> REM пользователей в триггере, мы должны иметь привилегии
SQL> REM CREATE и DROP USER, выданные напрямую. Во время
SQL> REM выполнения триггера роли не доступны.
SQL> REM Роли могут быть доступны во время выполнения процедуры
SQL> REM или функции, но не триггера.

SQL> grant create user to demo_ddl;
Grant succeeded.

SQL> grant drop user to demo_ddl;
Grant succeeded.

SQL> connect demo_ddl/demo_ddl
Connected.

SQL> REM Создание таблицы для хранения наших пользователей. Мы
SQL> REM создадим триггер на эту таблицу, срабатывающий после
SQL> REM вставки для каждой строки (after insert for each row),
SQL> REM для создания учетных записей. Мы в дальнейшем можем (но
SQL> REM не будем этого делать) расширить пример и сделать
SQL> REM триггер, срабатывающий после обновления для каждой
SQL> REM строки (after update for each row), чтобы разрешить
SQL> REM изменение паролей и ролей. Мы также создадим триггер
SQL> REM (delete for each row), срабатывающий после удаления
SQL> REM любой строки этой таблицы.

SQL> create table application_users ( uname varchar2(30), pw varchar2(30),
2 role_to_grant varchar2(4000) );
Table created.

SQL> create or replace trigger application_users_aifer
2 after insert on application_users
3 for each row
4 declare
5 — эта прагма позволит нашем триггеру выполнять DDL
6 pragma autonomous_transaction;
7 begin

— Динамический sql будет рассмотрен в другом разделе

9
10 execute immediate
11 ‘grant ‘ || :new.role_to_grant ||
12 ‘ to ‘ || :new.uname ||
13 ‘ identified by ‘ || :new.pw;
14 end;
15 /
Trigger created.

Этот триггер строчного уровня объявлен как автономная транзакция. Это позволяет данному триггеру выполнять DDL-предложения. Мы также используем в этом примере новую возможность задействования динамического sql, появившуюся в PL/SQL, которую мы рассмотрим подробнее в другом разделе. Когда этот триггер сработает, он будет выполнять оператор следующего вида «grant connect, resource to some_username identified by some_password». Этот оператор выполняет команды CREATE USER и GRANT за один проход. Преимуществом этого является то, что если одно из вышеуказанных простых предложений прервется, мы прервем также и родительскую вставку, строка не будет вставлена в таблицу APPLICATION_USERS, и мы сохраним условие целостности. С другой стороны, если бы мы использовали два предложения для создания и предоставления привилегий пользователю, то оператор CREATE USER мог завершиться успешно, а оператор GRANT мог завершиться неудачно. Неудачное завершение оператора GRANT должно вызвать откат вставки, оставляя нас в состоянии, когда учетная запись пользователя создана, привилегии же не предоставлены, и записи в таблице APPLICATION_USERS не существует. Имейте в виду, что многострочная вставка в таблицу APPLICATION_USERS может поставить нас в такое же затруднительное положение, и в этом заключается одна из проблем, связанных с автономными транзакциями. Это похоже на проблему с последовательностями: откат не отменяет увеличение значения в последовательности. Это делает последовательности чрезвычайно удобными для параллельного выполнения (многие пользователи могут одновременно выбирать из них значения), но делает их непригодными для генерации непрерывных последовательностей чисел (откат транзакции после выборки NEXTVAL из последовательности всегда будет оставлять дырку). Вы, как разработчик, должны осознавать это и разрабатывать свои приложения, принимая это во внимание.

Теперь давайте закончим наше приложение:

SQL> create or replace trigger application_users_adfer
2 after delete on application_users
3 for each row
4 declare
5 — эта прагма позволит нашем триггеру выполнять DDL
6 pragma autonomous_transaction;
7 begin
8 execute immediate ‘drop user ‘ || :old.uname;
9 end;
10 /
Trigger created.

SQL> REM Проверим, вставив пользователя, которого хотим создать
SQL> insert into application_users values
2 ( ‘NewUser’, ‘NewPW’, ‘connect, resource’ );
1 row created.

SQL> REM Для проверки сделанного посмотрим, существует ли новая
SQL> REM учетная запись и затем присоединимся, как новый
SQL> REM пользователь

SQL> select * from all_users where username = ‘NEWUSER’;<> SQL> connect newuser/newpw
Connected.

SQL> select * from session_roles;

SQL> REM Выше показано, что пользователь с указанным паролем
SQL> REM создан и соответствующие роли ему предоставлены.
SQL> REM Теперь, попробуем проверить ‘удаление’ пользователя

SQL> connect demo_ddl/demo_ddl
Connected.

SQL> delete from application_users;
1 row deleted.

SQL> commit;
Commit complete.

SQL> select * from all_users where username = ‘NEWUSER’;
no rows selected

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

Запись в структуру базы данных в функциях, вызываемых из SQL

Время от времени возникает необходимость выполнять DML-операции из среды, в которой могут выполняться только SQL-операции select. Это часто случается при работе с инструментами для написания отчетов. Например, в группу internet-новостей comp.databases.oracle.misc пришло письмо следующего содержания: >Привет,
>
>Вот непростой вопрос:
>
>- Я использую приложение, которое может выполнять только
>- SQL предложения.
>- SQL предложения могут вызывать функции, определенные
>- пользователем.
>- Эти функции, в свою очередь, могут вызывать процедуры.
>
> Однако, я обнаружил, что процедура, которая вызывается, не может
> выполнять обновления, вставку и удаления. Как можно обойти это?
>
>Например:
>select myfunc(parent) from dual;
>
>Function myfunc
>.
>bom_exploder(parent) ведомости материалов (BOM explosion), которая вставляет записи в >таблицу temp.
> Здесь вопрошающий хочет перенести выжимку из ведомости материалов (BOM — Bill Of Materials) в другую таблицу. Затем данные BOM-выжимки могут быть выбраны и отображены инструментарием построения отчетов. Создание такой выжимки является процедурной операцией, она не может быть эффективно выполнена с помощью представления или одиночного запроса. Инструментарий для построения отчетов может выполнять только предложения SELECT. Сегодня эта проблема, используя автономные транзакции, решается легко. Ниже приводится пример этого. Вместо выжимки из ведомости материалов мы создадим некую иерархию, основанную на таблице EMP. Мы напишем функцию, которая будет брать номер отдела, строить иерархию сотрудников, которые управляют людьми, работающими в этом отделе, и записывать эту иерархию во временную таблицу. Кроме того, появится возможность сортировать на каждом из уровней иерархии по любому столбцу, как вы пожелаете (этого нельзя сделать в запросе, использующем connect by). Эта функция будет возвращать сообщение об успешном или неудачном завершении. В случае успешного завершения, может быть выдан другой select для выбора результирующего множества. В итоге, используя только предложение SELECT, мы сможем вставить данные:

SQL> REM создание таблицы демонстрационных (demo) данных
SQL> create table emp as select * from scott.emp;
Table created.

SQL> REM Мы будем использовать временную таблицу для хранения
SQL> REM наших данных. Поскольку мы используем АВТОНОМНЫЕ
SQL> REM транзакции для заполнения этой таблицы, мы * должны *
SQL> REM использовать временную таблицу уровня сессии,
SQL> REM а не временную таблицу уровня транзакции, так как наша
SQL> REM автономная транзакция должна сохранить изменения
SQL> REM (commit).
SQL> REM Таблица уровня транзакции будет всегда выглядеть пустой
SQL> REM для родительской транзакции

SQL> create global temporary table hierarchy
2 on commit preserve rows
3 as select 0 seq, 0 lev, emp.* from emp where 1=0;
Table created.

Таблица EMP, созданная выше, содержит данные нашего приложения. Мы напишем к ней запросы, чтобы получить иерархию сотрудников. Временная таблица HIERARCHY действительно является временной таблицей. Способ, которым мы ее определили — «on commit preserve rows», позволяет нашей сессии (и всем транзакциям в этой сессии) увидеть данные сессии, записанные в эту таблицу. Эта таблица будет выглядеть пустой для всех других сессий, до тех пор, пока они не запишут в нее свои данные. При построении иерархии таблицы EMP, с помощью процедуры, описанной ниже, мы запишем построенную иерархию во временную таблицу.

Итак, перейдем к коду, который будет строить иерархию для заданного отдела. Мы должны иметь возможность вызывать эту функцию из SQL, а функция будет вставлять данные во временную таблицу. Раньше это невозможно было сделать . Если процедура изменяла состояние базы данных (выполняла вставку, обновление, удаление), она не могла быть вызвана из SQL. Прагма autonomous_transaction позволяет преодолеть это.

SQL> REM Наша функция заполняет временную таблицу.
SQL> REM Эта функция принимает на входе номер отдела. Мы начнем с
SQL> REM менеджеров данного отдела (то есть сотрудников, управляющих
SQL> REM кем-либо в этого отделе). Мы сможем также поддерживать
SQL> REM возможность сортировки.
SQL> REM Результат этой процедуры похож на запрос с connect by, но он
SQL> REM позволяет упорядочивать данные на любом уровне и подуровне,
SQL> REM что невозможно сделать, используя connect by.
SQL> REM Эта процедура *похожа* на запрос:
SQL> REM select * from emp
SQL> REM start with empno = 😡
SQL> REM connect by prior mgr = empno
SQL> REM (order by something)
SQL> REM Это отличается от случая, когда order by используется для
SQL> REM каждого поддерева иерархии, а НЕ для всей иерархии.

SQL> create or replace
2 function create_hierarchy( p_deptno in number,
3 p_order_by in varchar2 default NULL )
4 return varchar2
5 as
6 pragma autonomous_transaction;
7
8 — Нам придется динамически открывать наши курсоры, так как
9 — во время компиляции мы не знаем предложения «order by».
10 — Следовательно, необходимо использовать ref cursor.
11 type refCur is ref cursor;
12

— l_seq используется для сохранения порядка строк в таблице

14 — temp при их выборке.
15 l_seq number default 0;
16 l_cur refCur;
17
18
19 — Эта процедура внутри функции выполняет всю работу.
20 — Это рекурсивная процедура. Она берет открытый курсор и
21 — для каждой строки из этого курсора добавляет ее в
22 — результирующий набор, а затем рекурсивно обрабатывает
23 — людей, которые работают под руководством этого сотрудника.
24 procedure explode( p_cur in out refcur,
25 p_level in number )
26 is
27 l_rec emp%rowtype;
28 l_cur refCur;
29 begin
30 loop
31 fetch p_cur into l_rec;
32 exit when p_cur%notfound;
33
34 l_seq := l_seq+1;
35 insert into hierarchy
36 values ( l_seq, p_level,
37 l_rec.empno, l_rec.ename, l_rec.job, l_rec.mgr,
38 l_rec.hiredate, l_rec.sal, l_rec.comm, l_rec.deptno );
39
40 open l_cur for ‘select *
41 from emp
42 where mgr = 😡 ‘ ||
43 p_order_by
44 USING l_rec.empno;
45
46 explode( l_cur, p_level+1 );
47 end loop;
48 close p_cur;
49 end;
50
51 begin
52 — Начнем с очистки нашей временной таблицы. На всякий
53 — случай, вдруг мы уже запускали такой запрос в этой сессии.
54
55 delete from hierarchy;
56
57 — Первоначальным набором людей будут те, кто управляет кем-
58 — либо в интересующем нас отделе
59
60 open l_cur for ‘select *
61 from emp
62 where empno in ( select mgr
63 from emp
64 where deptno = 😡 ) ‘ ||
65 p_order_by
66 USING p_deptno;
67
68 — Детализировать этот набор (и каждый поднабор)
69 explode( l_cur, 1 );
70

— то будет выдано сообщение
— ORA-06519: active autonomous transaction detected and rolled
— back
— (обнаружена активная автономная транзакция и выполнен откат),
— которое удалит все наши строки!

76 commit;
77
78 — В случае успешного завершения, возвращаем соответствующее

— сообщение.
— Обработчик исключений, представленный ниже, возвращает
— сообщение об ошибке, в случае неудачного завершения.
return ‘Ok, результирующий набор создан’;

82 exception
83 when others then
84 rollback;
85 return sqlerrm;
86 end;
87 /
Function created.

Итак, вот наша процедура. Она начинает работу с запроса «select * from emp where empno in ( select ALL mgr сотрудников в отделе X ) order by «. Этот запрос открывается в главном блоке и передается в процедуру ‘explode’. Процедура принимает этот запрос и выбирает из него данные. Для каждой строки из этого результирующего набора, процедура строит другой запрос: на этот раз набор всех работников, менеджером которых является текущий сотрудник. Этот запрос передается процедуре, которая делает тоже самое снова (и снова) до тех пор, пока не будет достигнут конец дерева. Рекурсия ‘разворачивается’, и функция завершается. В иерархической таблице создан результирующий набор. Выбрать его теперь легко. Вот несколько примеров, использующих эту технику:

SQL> REM Теперь проверим это. Начнем с отдела номер 20. Будем
SQL> REM упорядочивать по имени работника (ename) на каждом
SQL> REM уровне иерархии
SQL> select create_hierarchy( 20, ‘order by ename’ ) msg from dual;
MSG
——————————

Ok, результирующий набор создан

SQL> REM Выведем теперь результат на экран. Должны быть выведены
SQL> REM все руководители отдела 20, упорядоченные по имени –
SQL> REM под каждым из них мы увидим их подчиненных
SQL> REM (упорядоченных по имени) и так далее и так далее.

SQL> select lpad(‘ ‘,lev*2,’ ‘)|| ename ename, hiredate, job, deptno
2 from hierarchy
3 order by seq;

SQL> REM Выполним то же самое, упорядочив на этот раз по дате
SQL> REM приема на работу.

SQL> select create_hierarchy( 20, ‘order by hiredate’ ) msg from dual;
MSG
——————————

Ok, результирующий набор создан
SQL> select lpad(‘ ‘,lev*2,’ ‘)|| ename ename,
2 lpad(‘ ‘,lev*2,’ ‘)|| hiredate hiredate_str, job, deptno
3 from hierarchy
4 order by seq; SQL> REM Проверим, что получится, если задать неверный параметр:
SQL> select create_hierarchy( 20, ‘order by bogus’ ) msg from dual;
MSG
——————————

ORA-00904: invalid column name

Как использовать автономные транзакции

Использовать автономные транзакции очень просто, никаких специальных параметров init.ora, ни событий сессии – просто прагма autonomous_transaction в PL/SQL-блоке. Программист должен заботиться о выполнении сохранения изменений или их откате в автономной транзакции. Если он не делает этого, то возникает ошибка :

SQL> declare
2 pragma autonomous_transaction;
3 begin
4 insert into t values ( 1 );
5 end;
6 /
declare
*
ERROR at line 1:
ORA-06519: active autonomous transaction detected and rolled back
ORA-06512: at line 4

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

SQL> REM Создадим демонстрационную таблицу с первичным ключом
SQL> create table t ( x int primary key );
Table created.

SQL> REM Вставим туда некоторые данные…
SQL> insert into t values ( 1 );
1 row created.

SQL> REM Теперь, в автономной транзакции попытаемся вставить
SQL> REM такую же запись. Поскольку автономная транзакция не
SQL> REM может “видеть” несохраненные данные своей родительской
SQL> REM транзакции, мы заблокируем сами себя.

SQL> declare
2 pragma autonomous_transaction;
3 begin
4 insert into t values ( 1 );
5 commit;
6 end;
7 /

declare
*
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource (обнаружена блокировка при ожидании ресурса)
ORA-06512: at line 4

За и против

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

За	Против
Разрешает выполнять commit в триггере	Параллельные запросы не могут выполняться в автономных транзакциях. Эти запросы будут выполняться последовательно.
Позволяет выполнять DML из SELECT	Блокировки могут возникать чаще, так как теперь отдельный пользователь может блокировать сам себя.
Предоставляет возможность создавать более модульные программы с меньшим побочным эффектом (позволяет избегать ситуаций типа «Эй – вы откатили мою работу!»)	Должны быть использованы на верхнем уровне анонимного блока, процедуры или функции. Не могут включаться во вложенные PL/SQL-блоки.
Позволяет реализовывать аудит, который не может быть отменен
Поскольку эта возможность является расширением рекурсивного SQL, она была встроена в ядро в течении длительного времени (а значит хорошо протестирована).

Скрипты

По этому адресу вы можете найти демонстрационные скрипты, использованные в этой статье. Они удаляют и создают пользователей, вызывают «demo_autonomous», «demo_ddl», and «demo_hierarchy».

Источник

May 7, 2021

I got ” ORA-06519: active autonomous transaction detected and rolled back ” error in Oracle database.

ORA-06519: active autonomous transaction detected and rolled back

Details of error are as follows.

ORA-06519: active autonomous transaction detected and rolled back.

Cause: Before returning from an autonomous PL/SQL block, all autonomous transactions started 
within the block must be completed (either committed or rolled back). If not, the active
 autonomous transaction is implicitly rolled back and this error is raised.

Action: Ensure that before returning from an autonomous PL/SQL block, any active autonomous
 transactions are explicitly committed or rolled back.

active autonomous transaction detected and rolled back

This ORA-06519 error is related to the returning from an autonomous PL/SQL block, all autonomous transactions started within the block must be completed (either committed or rolled back). If not, the active autonomous transaction is implicitly rolled back and this error is raised.

Ensure that before returning from an autonomous PL/SQL block, any active autonomous transactions are explicitly committed or rolled back.

To solve this error, Don’t forget to use commit; androllback; in the PL/SQL block,

Do you want to learn Oracle Database for Beginners, then read the following articles.

Oracle Tutorial | Oracle Database Tutorials for Beginners ( Junior Oracle DBA )

1,263 views last month, 1 views today

About Mehmet Salih Deveci

I am Founder of SysDBASoft IT and IT Tutorial and Certified Expert about Oracle & SQL Server database, Goldengate, Exadata Machine, Oracle Database Appliance administrator with 10+years experience.I have OCA, OCP, OCE RAC Expert Certificates I have worked 100+ Banking, Insurance, Finance, Telco and etc. clients as a Consultant, Insource or Outsource.I have done 200+ Operations in this clients such as Exadata Installation & PoC & Migration & Upgrade, Oracle & SQL Server Database Upgrade, Oracle RAC Installation, SQL Server AlwaysOn Installation, Database Migration, Disaster Recovery, Backup Restore, Performance Tuning, Periodic Healthchecks.I have done 2000+ Table replication with Goldengate or SQL Server Replication tool for DWH Databases in many clients.If you need Oracle DBA, SQL Server DBA, APPS DBA, Exadata, Goldengate, EBS Consultancy and Training you can send my email adress [email protected].- -Oracle DBA, SQL Server DBA, APPS DBA, Exadata, Goldengate, EBS ve linux Danışmanlık ve Eğitim için [email protected] a mail atabilirsiniz.

Источник

Error Message: {http://schemas.oracle.com/bpel/extension}bindingFault

First of all, this issue occurs in different scenarios, each scenario has its own workaround. Please examine listed cases for suitable scenario for easy solution.

Before getting in to explanation:

Here the Original cause info…..

Reference http://ora-06519.ora-code.com/

ORA-06519:	active autonomous transaction detected and rolled back
Cause:	Before returning from an autonomous PL/SQL block, all autonomous transactions started within the block must be completed (either committed or rolled back). If not, the active autonomous transaction is implicitly rolled back and this error is raised.
Action:	Ensure that before returning from an autonomous PL/SQL block, any active autonomous transactions are explicitly committed or rolled back. ———————————————————————– 06520 through 06529 reserved for Foreign function errors

Scenario 1: If Error occurred in Oracle Fusion middleware/ SOA {BPEL / OSB / ESB / ect}

Note: If same error occurs after using listed solution, follow Scenario 2.

Here is sample PL/SQL Stored proc code with PRAGMA AUTONOMOUS_TRANSACTION to use inner commits or rollbacks.

PROCEDURE TEST_PROC
(x_MESSAGE                 OUT NOCOPY VARCHAR2
,p_SOME_ID         IN    NUMBER
)
IS
PRAGMA AUTONOMOUS_TRANSACTION;
lc_MESSAGE      VARCHAR2(240);
l_SOME_ID        NUMBER;
BEGIN
———-   Do some thing ———-
COMMIT;
———-   Do some thing ———-
COMMIT;
IF nvl(p_SOME_ID         ,0) = 0 THEN
x_MESSAGE                 := ‘Error’;
ROLLBACK;
END IF;
———-   Do some thing ———-
COMMIT;
END TEST_PROC;

Scenario 2: If Error occurred in Oracle Fusion middleware/ SOA {BPEL / OSB / ESB / ect}, After applying Scenario 1.

Cause: SOA Service testing might have taken place when Database Store Procedure or Function or DB code pack in compile and commit mode.

Solutions: In this case there are two different solutions are available.

Solution 1: Kill Active connections in DB or bounce DB (Yah, this might not be a good trick, Try it out, this magic will work).

Solution 2: If DB bounce is not possible (It’s not that easy while working with Oracle APPS/EBS/EBZ, WMS, OTM ect), Bounce SOA Server.

Note: Why SOA bounce required? Some where the deadlock needs to clear. Sometimes it will lead into bounce both DB and SOA.

Good Luck.

Источник

Nested blocks, autonomous transactions and «Where do I commit?»

This question rolled into my In Box today:

If I have a procedure that is AUTONOMOUS_TRANSACTION that does an insert and then it calls a procedure with an insert, does the second procedure need a commit, or will the procedure with the AUTONOMOUS_TRANSACTION handle the commit? If you don’t know off the top of your head, don’t worry, I can build a test.

First of all, if you ever find yourself writing something like «If you don’t know off the top of your head, don’t worry, I can build a test.» then please by all means go right ahead and build yourself a test script.

By doing so, you will better understand the feature in question and remember what you learned. Plus you end up with a script you can share with the community on LiveSQL.

But I don’t mind answering such questions. That way I get to better understand the feature in question, remember what I learned, share a script on LiveSQL (link at bottom of post), and also add to my blog.

So here goes: the answer is NO. The «second» procedure — invoked by the first — does not have to include a COMMIT statement.

Would you like proof or more information about the autonomous transaction feature of PL/SQL? Then keep reading.

When you add this statement to the declaration section of a procedure or function…

PRAGMA AUTONOMOUS_TRANSACTION;

the following rule then applies:

Before the subprogram can be closed and control passed back to the calling block, any DML changes made within that subprogram must be committed or rolled back.

If there are any unsaved changes, the PL/SQL engine will raise the ORA-06519 exception, as shown below:

CREATE OR REPLACE FUNCTION nothing RETURN INTEGER
IS
   PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
   UPDATE employees SET last_name = 'abc';

   RETURN 1;
END;
/

BEGIN
   DBMS_OUTPUT.put_line (nothing);
END;
/

ORA-06519: active autonomous transaction detected and rolled back
ORA-06512: at "STEVEN.NOTHING", line 10
ORA-06512: at line 2

OK, so that’s the basic idea. Now let’s move on the specific question. What if an autonomous transaction procedure calls another procedure, which does not include the pragma shown above but does execute a DML statement and does not commit? Will we see an ORA-06519 error? The code below shows that we will not.

CREATE TABLE me_and_my_lovelies (name VARCHAR2 (100));

BEGIN
   INSERT INTO me_and_my_lovelies VALUES ('Grandpa Steven');
   INSERT INTO me_and_my_lovelies VALUES ('Loey');
   INSERT INTO me_and_my_lovelies VALUES ('Juna');
   COMMIT;
END;
/

CREATE OR REPLACE PROCEDURE not_auton_no_commit
   AUTHID DEFINER
IS
BEGIN
   UPDATE me_and_my_lovelies
      SET name = UPPER (name);
END not_auton_no_commit;
/

CREATE OR REPLACE PROCEDURE auton_commit
   AUTHID DEFINER
IS
   PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
   not_auton_no_commit ();

   COMMIT;
END auton_commit;
/

BEGIN
   auton_commit;
END;
/

SELECT COUNT(*) low_name
  FROM me_and_my_lovelies
 WHERE name <> UPPER (name)
/

LOW_NAME
--------
0

No error is raised. All rows have been updated. So let’s go back to the rule:

Before the subprogram can be closed and control passed back to the calling block, any DML changes made within that subprogram must be committed or rolled back.

You might be thinking: But the UPDATE statement (the «DML change») was not made «within» auton_commit. Yes and no. Yes, the UPDATE statement is not part of the text of auton_commit. But the UPDATE statement was executed within the scope of auton_commit. And that’s what counts. Any code executed by auton_commit, either «directly» in its executable section or «indirectly» by invoking another subprogram, is part of the autonomous transaction.

The only point at which the rule is applied is when PL/SQL attempts to close auton_commit and return control to the outer block.

LiveSQL script containing the above code here.

More information about autonomous transactions here.

Источник

Ошибки Оракла ORA-06000 — ORA-06999

В нотной записи PL/SQL допущена нота не той октавы

Группы шестой тысячи ошибок Oracle (по диапазонам кодов от 6000 до 6999):

Ошибки ORA-06000 — ORA-06099
Ошибки ORA-06100 — ORA-06199
Ошибки ORA-06200 — ORA-06299
Ошибки ORA-06300 — ORA-06399
Ошибки ORA-06400 — ORA-06499
Ошибки ORA-06500 — ORA-06599
Ошибки ORA-06600 — ORA-06699
Ошибки ORA-06700 — ORA-06799
Ошибки ORA-06800 — ORA-06899
Ошибки ORA-06900 — ORA-06999

Ошибки ORA-06000 — ORA-06099

ORA-06000 NETASY: открытие порта провалено
ORA-06001 NETASY: установка порта провалена
ORA-06002 NETASY: чтение порта провалено
ORA-06003 NETASY: запись порта провалена
ORA-06004 NETASY: провалено открытие диалогового файла.
ORA-06005 NETASY: провалено чтение диалогового файла
ORA-06006 NETASY: провалено выполнение диалога
ORA-06007 NETASY: неверный формат диалога
ORA-06009 NETASY: имя файла диалога слишком длинное
ORA-06010 NETASY: диалоговый файл слишком длинный
ORA-06011 NETASY: диалог слишком длинный
ORA-06017 NETASY: провалено получение сообщения
ORA-06018 NETASY: провалена отправка сообщения
ORA-06019 NETASY: неверное имя пользователя (строка соединения)
ORA-06020 NETASY: инициализация провалена
ORA-06021 NETASY: соединение провалено
ORA-06022 NETASY: провалено открытие канала
ORA-06023 NETASY: провалено открытие порта
ORA-06024 NETASY: ошибка VTM
ORA-06025 NETASY: ошибка конфигурации
ORA-06025 NETASY: ошибка конфигурации
ORA-06026 NETASY: провалено закрытие порта
ORA-06027 NETASY: провалено закрытие канала
ORA-06028 NETASY: невозможно инициализировать для журналирования
ORA-06029 NETASY: провалено назначение порта
ORA-06030 NETDNT: соединение провалено, нераспознанное имя узла
ORA-06031 NETDNT: соединение провалено, нераспознаное имя объекта
ORA-06032 NETDNT: соединение провалено, данные доступа отклонены
ORA-06033 NETDNT: соединение провалено, партнерское соединение отклонено
ORA-06034 NETDNT: соединение провалено, партнер неожиданно вышел
ORA-06035 NETDNT: соединение провалено, недостаточно привилегий
ORA-06037 NETDNT: соединение провалено, узел недоступен
ORA-06039 NETDNT: соединение провалено
ORA-06040 NETDNT: неверное имя пользователя
ORA-06041 NETDNT: отключение провалено
ORA-06042 NETDNT: получение сообщения провалено
ORA-06043 NETDNT: отправка сообщения провалена
ORA-06044 NETDNT: соединение провалено, превышена квота на количество байт

Ошибки ORA-06100 — ORA-06199

ORA-06102 NETTCP: нельзя выделить контекстную зону
ORA-06105 NETTCP: неизвестный удаленный хост
ORA-06106 NETTCP: провалено соединение сокета
ORA-06107 NETTCP: сетевой сервер Oracle не найден
ORA-06108 NETTCP: соединение с хостом провалено
ORA-06109 NETTCP: провалено получение сообщения
ORA-06110 NETTCP: провалена отправка сообщения
ORA-06111 NETTCP: отключение не удалось
ORA-06112 NETTCP: неверный размер буфера
ORA-06113 NETTCP: слишком много соединений
ORA-06114 NETTCP: поиск SID не удался
ORA-06115 NETTCP: невозможно создать логику Oracle
ORA-06116 NETTCP: невозможно создать процесс ORASRV
ORA-06117 NETTCP: невозможно создать процесс ORASRV: превышена квота
ORA-06118 NETTCP: невозможно установить связь с ORASRV
ORA-06119 NETTCP: ложный клиентский запрос
ORA-06120 NETTCP: сетевой драйвер не загружен
ORA-06121 NETTCP: доступ не удался
ORA-06122 NETTCP: установка провалена
ORA-06123 NETTCP: нельзя установить KEEPALIVE
ORA-06124 NETTCP: истекло время ожидания ORASRV
ORA-06125 NETTCP: ORASRV неожиданно завершился
ORA-06126 NETTCP: ORASRV невозможно открыть сетевое соединение
ORA-06127 NETTCP: невозможно изменить имя пользователя
ORA-06128 NETTCP: невозможно создать почтовый ящик
ORA-06129 NETTCP: невозможно передать собственность сокета к ORASRV
ORA-06130 NETTCP: доступ к хосту запрещен
ORA-06131 NETTCP: пользовательский доступ запрещен
ORA-06132 NETTCP: доступ запрещен, неверный пароль
ORA-06133 NETTCP: файл не найден
ORA-06134 NETTCP: нарушение привелегий доступа к файлу
ORA-06135 NETTCP: соединение отклонено, сервер останавливается
ORA-06136 NETTCP: ошибка во время установления соединения
ORA-06137 NETTCP: ошибка во время установления соединения
ORA-06138 NETTCP: ошибка во время установления соединения
ORA-06140 NETTCP: нет такого пользователя
ORA-06141 NETTCP: нет привилегий для пользователя
ORA-06142 NETTCP: ошибка получения информации пользователя
ORA-06143 NETTCP: превышено максимальное количество соединений
ORA-06144 NETTCP: SID (база данных) недоступен
ORA-06145 NETTCP: невозможно запустить ORASRV: образы не установлены

Ошибки ORA-06200 — ORA-06299

ORA-06250 NETNTT: нельзя выделить буферы отправки и приема
ORA-06251 NETNTT: нельзя перевести имя адресного файла
ORA-06252 NETNTT: не могу открыть адресный файл
ORA-06253 NETNTT: нельзя прочитать аргументы из адресного файла
ORA-06254 NETNTT: нельзя распределить соединение с кубом
ORA-06255 NETNTT: нельзя прочитать pid удаленного процесса
ORA-06256 NETNTT: удаленное ветвление не удалось
ORA-06257 NETNTT: нельзя отправить команду фоновому процессу
ORA-06258 NETNTT: нельзя выделить контекстную зону
ORA-06259 NETNTT: нельзя прочитать из удаленного процесса
ORA-06260 NETNTT: нельзя записать в удаленный процесс
ORA-06261 NETNTT: неудача nrange()
ORA-06262 NETNTT: неудача nfconn()
ORA-06263 NETNTT: недостаточно памяти в pi_connect
ORA-06264 NETNTT: ошибка протокола данных
ORA-06265 NETNTT: ошибка протокола разрыва
ORA-06266 NETNTT: неверная длина записи
ORA-06267 NETNTT: неверное состояние
ORA-06268 NETNTT: нельзя прочитать /etc/oratab

Ошибки ORA-06300 — ORA-06399

ORA-06300 IPA: Отключение не удалось
ORA-06301 IPA: Нельзя выделить контекстный драйвер
ORA-06302 IPA: нельзя подключится к удаленному хосту
ORA-06303 IPA: ошибка отправки сообщения
ORA-06304 IPA: ошибка получения сообщения
ORA-06305 IPA: недопустимый тип сообщения
ORA-06306 IPA: Ошибка записи длины сообщения
ORA-06307 IPA: нельзя сбросить соединение
ORA-06308 IPA: нет доступных соединений
ORA-06309 IPA: нет доступной очереди сообщений
ORA-06310 IPA: Переменная (ые) окружения не выствлена
ORA-06311 IPA: достигнуто максимальное число серверов
ORA-06312 IPA: указано неверное имя службы
ORA-06313 IPA: неудачная инициализация распределенной памяти
ORA-06314 IPA: установка события провалена
ORA-06315 IPA: неверная строка связи
ORA-06316 IPA: неверный SID базы данных
ORA-06317 IPA: локальный максимум пользователей превышен
ORA-06318 IPA: локальный максимум соединений превышен
ORA-06319 IPA: превышен максимум удаленных пользователей
ORA-06320 IPA: удаленный максимум соединений превышен
ORA-06321 IPA: нельзя достичь удаленной стороны
ORA-06322 IPA: фатальная ошибка распределенной памяти
ORA-06323 IPA: ошибка причины события

Ошибки ORA-06400 — ORA-06499

ORA-06400 NETCMN: не указано строки хоста по умолчанию
ORA-06401 NETCMN: неверный указатель драйвера
ORA-06402 NETCMN: ошибка получения сообщения разрыва
ORA-06403 Невозмжно выделить память
ORA-06404 NETCMN: неверное имя (строка соединения)
ORA-06405 NETCMN: ошибка сброса протокола
ORA-06406 NETCMN: ошибка отправки сообщения разрыва
ORA-06406 NETCMN: ошибка отправки сообщения разрыва
ORA-06407 NETCMN: невозможно установить окружение обработки
ORA-06408 NETCMN: некорректный формат сообщения
ORA-06413 Соединение не открыто
ORA-06416 NETCMN: ошибка на тесте
ORA-06419 NETCMN: сервер не может запустить Oracle
ORA-06420 NETCMN: поиск SID не удался
ORA-06421 NETCMN: обнаружена ошибка в считываемых данных
ORA-06422 NETCMN: ошибка в отправке данных
ORA-06423 NETCMN: ошибка в получении данных
ORA-06430 ssaio: штампы не совпадают
ORA-06431 ssaio: неверный номер блока
ORA-06432 ssaio: буфер не выровненный
ORA-06433 ssaio: ошибка LSEEK, невозможно найти запрошенный блок
ORA-06434 ssaio: ошибка чтения, невозможно прочитать указанный блок из файла базы данных
ORA-06435 ssaio: ошибка записи, невозможно записать требуемый блок в файл базы данных
ORA-06436 ssaio: неудачный асинхронный ввод/вывод по причине некорректных параметров
ORA-06437 ssaio: асинхранная запись не может записать в файл базы данных
ORA-06438 ssaio: асинхранное чтение не может прочитать файл базы данных
ORA-06439 ssaio: асинхронная запись вернула некорректное число байт
ORA-06440 ssaio: асинхронное чтение вернуло некорректное число байт
ORA-06441 ssvwatev: в вызов функции передан некорректный параметр
ORA-06442 ssvwatev: неудачное выполнение с неожиданным номером ошибки
ORA-06443 ssvpstev: в вызов функции передан некорректный параметр
ORA-06444 ssvwatev: неудачное выполнение с неожиданным номером ошибки
ORA-06445 ssvpstev: в вызов функции передан некорректный параметр
ORA-06446 ssvwatev: неудачное выполнение с неожиданным номером ошибки
ORA-06447 ssvpstev: в вызов функции передан некорректный параметр
ORA-06448 ssvwatev: неудачное выполнение с неожиданным номером ошибки
ORA-06449 Список IO или sysvendor не установлен

Ошибки ORA-06500 — ORA-06599

ORA-06500 PL/SQL: ошибка хранилища
ORA-06501 PL/SQL: программная ошибка
ORA-06502 PL/SQL: числовая или ошибка значения [значение]
ORA-06503 PL/SQL: функция возвращена без значения
ORA-06504 PL/SQL: возвращаемые типы результирующего набора переменных или запрос не совпадают
ORA-06505 PL/SQL: переменная требует более чем 32767 непрерывных байт памяти (расположенных последовательно)
ORA-06508 PL/SQL: не могу найти вызываемый программный модуль
ORA-06509 PL/SQL: ICD вектор пропущен для этого пакета
ORA-06510 PL/SQL: необработанное определенное пользователем исключение
ORA-06511 PL/SQL: курсор уже открыт
ORA-06512 в [значение] строка [значение]
ORA-06513 PL/SQL: индекс для PL/SQL таблицы за пределами диапазона для массива языка
ORA-06514 PL/SQL: удаленный вызов не может быть обратботан сервером
ORA-06515 PL/SQL: необработанное исключение [значение]
ORA-06516 PL/SQL: пакеты Probe не существуют или неработоспособные
ORA-06517 PL/SQL: ошибка Probe — [значение]
ORA-06518 PL/SQL: Версия Probe [значение] не совместима с версией [значение]
ORA-06519 Обнаружена активная автономная транзакция и сделан откат
ORA-06520 PL/SQL: Ошибка загрузки внешней библиотеки
ORA-06521 PL/SQL: Ошибка функции маппирования
ORA-06522 [значение]
ORA-06523 Превышено максимальное количество аргументов
ORA-06524 Неподдерживаемая опция : [значение]
ORA-06525 Несовпадение длины для данных CHAR или RAW
ORA-06526 Невозможно загрузить библиотеку PL/SQL
ORA-06527 Ошибка внешней процедуры SQLLIB: [значение]
ORA-06528 Ошибка выполнения профайлера PL/SQL
ORA-06529 Несовпадение версий — профайлер PL/SQL
ORA-06530 Ссылка на неинициализированный составной объект
ORA-06531 Ссылка на неинициализированную коллекцию
ORA-06532 Нижний индекс за пределами диапазона
ORA-06533 Нижний индекс далеко от расчетного
ORA-06534 Невозможно получить доступ к пакету Serially Reusable [значение]
ORA-06535 Строка предложения в [значение] NULL или с нулевой длиной
ORA-06536 Связанная переменная IN граничит с позицией OUT
ORA-06537 Связанная переменная OUT граничит с позицией IN
ORA-06538 Предложение нарушает [значение] прагму RESTRICT_REFERENCES
ORA-06539 Целью OPEN должен быть запрос
ORA-06540 PL/SQL: ошибка компиляции
ORA-06541 PL/SQL: ошибка компиляции — компиляция прервана
ORA-06544 PL/SQL: внутренняя ошибка, аргументы: [значение], [значение], [значение], [значение], [значение], [значение], [значение], [значение]
ORA-06545 PL/SQL: ошибка компиляции — компиляция прервана
ORA-06546 Предложение DDL выполнено в недопустимом контексте
ORA-06547 Предложение RETURNING должно использоваться с предложениями INSERT, UPDATE или DELETE
ORA-06548 Больше строк не требуется
ORA-06549 PL/SQL: неудачное динамическое открытие общего объекта (DDL): [значение]
ORA-06550 Строка: [значение], колонка [значение]: [значение]
ORA-06554 Пакет DBMS_STANDARD должен быть создан до использования PL/SQL
ORA-06555 Это имя зарезервировано для использования пользователем SYS
ORA-06556 Конвейер пуст, нельзя осуществить запрос unpack_message
ORA-06557 Пустые значения не разрешены для любых параметров для конвейера
ORA-06558 Буфер в dbms_pipe полон. Больше элементов не позволено
ORA-06559 Запрошен неверный тип данных, [значение], актуальный тип данных [значение]
ORA-06560 Позиция [значение] отрицательное или больше, чем размер буфера [значение]
ORA-06561 Указанное предложение не поддерживается пакетом DBMS_SQL
ORA-06562 Тип выходных аргументов должен совпадать с типом столбца или связанной переменной
ORA-06563 Указана процедура/функция верхнего уровня, нельзя иметь зависимые доли
ORA-06564 Объект [значение] не существует
ORA-06565 Нельзя выполнить [значение] внутри хранимой процедуры
ORA-06566 Указано неверное число строк
ORA-06567 Указано неверное количество значений
ORA-06568 Вызвана устаревшая ICD процедура
ORA-06569 Коллекция ограничена bind_array не содержащем элементов
ORA-06570 Объект разделяемого пула не существует, нельзя закрепить
ORA-06572 Функция [значение] содержит OUT аргументы
ORA-06573 Функция [значение] изменяет состояние пакета, и не может быть использована здесь
ORA-06574 Функция [значение] ссылается на состояние пакета, нельзя выполнить удаленно
ORA-06575 Пакет или функция [значение] в состоянии INVALID
ORA-06576 Неверное имя функции или процедуры
ORA-06577 Выходной параметр не связанная переменная
ORA-06578 Выходной параметр не может быть дублирующим связыванием
ORA-06579 Связанная переменная не настолько большая, для хранения выходного значения
ORA-06580 Недостаточно памяти для Hash Join при сохранении больших строк в памяти
ORA-06592 При выполнении предложения CASE, CASE не найден
ORA-06593 [значение] не поддерживается модулями PL/SQL скомпилированными для этой среды

Ошибки ORA-06600 — ORA-06699

ORA-06600 LU6.2 драйвер: Программное обеспечение SNA не загружено
ORA-06601 LU6.2 драйвер: Неверный ID базы данных [значение]
ORA-06602 LU6.2 драйвер: Ошибка распределения контекстной зоны
ORA-06603 LU6.2 драйвер: Ошибка распределения памяти
ORA-06604 LU6.2 драйвер: невозможно выделить сеанс с удаленным LU
ORA-06605 LU6.2 драйвер: Неожиданный возврат строки
ORA-06606 LU6.2 драйвер: Неожиданный отклик от SNA
ORA-06607 LU6.2 драйвер: Обнаружен сброс в состоянии отправки
ORA-06608 LU6.2 драйвер: Обнаружен сброс в состоянии приема
ORA-06610 LU6.2 драйвер: Неудача во время высвобождения памяти
ORA-06616 LU6.2 драйвер: Прикрепление LU не удалось
ORA-06622 LU6.2 драйвер: Невозможно прикрепиться к SNA

Ошибки ORA-06700 — ORA-06799

ORA-06700 TLI драйвер: сообщение некорректного типа от хоста
ORA-06701 TLI драйвер: записано некорректное количество байт
ORA-06702 TLI драйвер: нельзя выделить контекстную зону
ORA-06703 TLI драйвер: неудачная отправка сообщения разрыва
ORA-06704 TLI драйвер: не удалось получение ожидаемого сообщения разрыва
ORA-06705 TLI драйвер: удаленный узел не известен
ORA-06706 TLI драйвер: служба не найдена
ORA-06707 TLI драйвер: соединение не удалось
ORA-06708 TLI драйвер: не удалось получение сообщения
ORA-06709 TLI драйвер: не удалось отправить сообщение
ORA-06710 TLI драйвер: не удалась отправка сообщения разрыва
ORA-06711 TLI драйвер: ошибка при связывании
ORA-06712 TLI драйвер: ошибка при принятии
ORA-06713 TLI драйвер: ошибка при соединении
ORA-06720 TLI драйвер: поиск SID не удался
ORA-06721 TLI драйвер: запрос от поддельного клиента
ORA-06722 TLI драйвер: начальная установка соединения не удалась
ORA-06730 TLI драйвер: невозможно открыто клонированное устройство
ORA-06731 TLI драйвер: нельзя разместить t_call
ORA-06732 TLI драйвер: нельзя разместить t_disconn
ORA-06733 TLI драйвер: получение отключения не удалось
ORA-06734 TLI драйвер: нельзя подключиться
ORA-06735 TLI драйвер: клиент не может закрыть ошибочное подключение
ORA-06736 TLI драйвер: сервер не запущен
ORA-06737 TLI драйвер: соединение не удалось
ORA-06741 TLI драйвер: невозможно открыть устройство протокола
ORA-06742 TLI драйвер: нельзя разместить t_bind
ORA-06743 TLI драйвер: нельзя разместить t_bind
ORA-06744 TLI драйвер: нельзя связать прослушиватель
ORA-06745 TLI драйвер: прослушиватель уже запущен
ORA-06746 TLI драйвер: нельзя выделить t_call
ORA-06747 TLI драйвер: ошибка в прослушивании
ORA-06748 TLI драйвер: невозможно выделить t_discon
ORA-06749 TLI драйвер: опция через сеть не позволена
ORA-06750 TLI драйвер: синхронизация не удалась
ORA-06751 TLI драйвер: неодинаковая граница адресов
ORA-06752 TLI драйвер: ошибка в установке сигнала
ORA-06753 TLI драйвер: сопоставление имя-адрес не удалось
ORA-06754 TLI драйвер: невозможно получить адрес локального хоста
ORA-06755 TLI драйвер: нельзя закрыть конечную точку транспорта
ORA-06756 TLI драйвер: не могу открыть oratab
ORA-06757 TLI драйвер: сервер получил неверную команду
ORA-06760 TLI драйвер: истекло время чтения
ORA-06761 TLI драйвер: ошибка отправки
ORA-06762 TLI драйвер: ошибка чтения
ORA-06763 TLI драйвер: ошибка отправки отключения
ORA-06764 TLI драйвер: ошибка чтения отключения
ORA-06765 TLI драйвер: ошибка ожидания высвобождения
ORA-06766 TLI драйвер: закрытие не удалось во время высвобождения
ORA-06767 TLI драйвер: распределение во время высвобождения не удалось
ORA-06770 TLI драйвер: ошибка отправки версии
ORA-06771 TLI драйвер: ошибка чтения версии
ORA-06772 TLI драйвер: ошибка отправки команды
ORA-06773 TLI драйвер: ошибка чтения команды
ORA-06774 TLI драйвер: ошибка отправки режима разрыва
ORA-06775 TLI драйвер: ошибка чтения режима разрыва
ORA-06776 TLI драйвер: ошибка отправки параметров
ORA-06777 TLI драйвер: ошибка чтения параметров
ORA-06778 TLI драйвер: ошибка отправки кода
ORA-06779 TLI драйвер: ошибка чтения кода
ORA-06780 TLI драйвер: получение кода ошибки не удалось
ORA-06781 TLI драйвер: ошибка чтения строки согласования
ORA-06790 TLI драйвер: опрос не удался
ORA-06791 TLI драйвер: опрос вернул ошибку
ORA-06792 TLI драйвер: сервер не может запустить Oracle
ORA-06793 TLI драйвер: сервер не может создать новый процесс
ORA-06794 TLI драйвер: теневой процесс не может получить информацию о протоколе

Ошибки ORA-06800 — ORA-06899

ORA-06800 TLI драйвер: клиент SQL*Net SPX в другом состоянии во время переподключения
ORA-06801 TLI драйвер: прослушивание при переподключении SPX сервера не удалось
ORA-06802 TLI драйвер: невозможно открыть файл /etc/netware/yellowpages
ORA-06803 TLI драйвер: файл устройства IPX не может быть открыт
ORA-06804 TLI драйвер: не могу связать IPX адрес в инициализации
ORA-06805 TLI драйвер: нельзя отправить датаграмму SAP пакета для SPX
ORA-06806 TLI драйвер: нельзя завершить инициализацию протокола для SPX
ORA-06807 TLI драйвер: нельзя открыть файл драйвера сетевого устройства
ORA-06808 TLI драйвер: нельзя слинковать IPX и сетевые потоки
ORA-06809 TLI драйвер: нельзя очистить сеть IPX при инициализации SAP
ORA-06810 TLI драйвер: нельзя установить сеть IPX при нициализации SAP
ORA-06812 TLI драйвер: не могу прочитать адрес узла сети
ORA-06813 TLI драйвер: настроенный сетевой адрес некорректный
ORA-06814 TLI драйвер: файл SPX устройства не может быть открыт
ORA-06815 TLI драйвер: нельзя слинковать SPX и IPX потоки
ORA-06816 TLI драйвер: нельзя установить адреса SPX SAP
ORA-06817 TLI драйвер: не могу прочитать сетевой адрес Novell

Ошибки ORA-06900 — ORA-06999

ORA-06900 CMX: нельзя прочитать TNS директорию
ORA-06901 CMX: нет локального имени сопоставленного для локального приложения
ORA-06902 CMX: нельзя прикрепить к подсистеме cmx
ORA-06903 CMX: нельзя прочитать транспортный адрес удаленного приложения
ORA-06904 CMX: нет доступных транспортных адресов для удаленного приложения
ORA-06905 CMX: ошибка подключения
ORA-06906 CMX: не удается получить максимальный размер пакета из CMX
ORA-06907 CMX: ошибка во время подтверждения подключения
ORA-06908 CMX: ошибка во время передачи ORACLE_SID
ORA-06909 CMX: ошибка во время подтверждения ORACLE_SID
ORA-06910 CMX: нельзя запустить процесс Oracle на удаленной машине
ORA-06911 CMX: t_event вернула ERROR
ORA-06912 CMX: ошибка записи в datarq
ORA-06913 CMX: ошибка во время перенаправления подключения
ORA-06914 CMX: неожиданное событие во время запуска Oracle
ORA-06915 CMX: неизвестное t_event в datarq
ORA-06916 CMX: ошибка в чтении данных (t_datain)
ORA-06917 CMX: ошибка в чтении данных (слишком много байт прочитано)
ORA-06918 CMX: T_NOEVENT во время ожидания события
ORA-06919 CMX: ошибка во время записи запроса (неизвестное событие)
ORA-06920 CMX: getbrkmsg недопустимый тип данных
ORA-06921 CMX: getdatmsg недопустимый тип данных
ORA-06922 CMX: неверная длина записи
ORA-06923 CMX: недопустимое условие разрыва
ORA-06924 CMX: неверная длина сообщения разрыва
ORA-06925 CMX: отключение во время запроса подключения
ORA-06926 CMX: T_ERROR во время чтения данных
ORA-06927 CMX: T_DATAIN получено до прочтения всех данных
ORA-06928 CMX: неверный ORACLE_SID
ORA-06929 CMX: ошибка при отправке ORACLE_SID
ORA-06930 CMX: ошибка при проверке ORACLE_SID
ORA-06931 CMX: ошибка во время read_properties для сервера
ORA-06932 CMX: ошибка в локальном имени
ORA-06933 CMX: ошибка во время присоединения
ORA-06950 Нет ошибки
ORA-06951 Ошибка вызова операционной системы
ORA-06952 Удаленный выпуск завершения связи до пакета сброса
ORA-06953 Недостаточно виртуальной памяти
ORA-06954 Недопустимое имя файла
ORA-06955 Количество серверов баз данных превышает допустимое
ORA-06956 Не удалось получить имя локального хоста
ORA-06957 Нет доступных SID
ORA-06958 Нет доступа к файлу конфигурации
ORA-06959 Квота на буферный I/O слишком мала
ORA-06960 Нет доступа к журнальному файлу
ORA-06961 Недостаточно привилегий для операции
ORA-06970 X.25 драйвер: удаленный хост не известен
ORA-06973 X.25 драйвер: неверный размер буфера
ORA-06974 X.25 драйвер: поиск SID не удался
ORA-06975 X.25 драйвер: подключение к хосту не удалось
ORA-06976 X.25 драйвер: неудача при создании конечной точки
ORA-06977 X.25 драйвер: X.25 Level 2 провал
ORA-06978 X.25 драйвер: слишком много попыток обратного вызова
ORA-06979 X.25 драйвер: сервер не может запустить Oracle

На правах рекламы (см.
условия):

Ключевые слова для поиска сведений о значениях ошибок Oracle в диапазоне ORA-06000 — ORA-06999:

На русском языке: ошибки Oracle, коды оракловых ошибок;

На английском языке: ORA-06000 — ORA-06999.

Страница обновлена 28.09.2022

Источник