ORA-00054: ресурс занят и получен с указанным значением NOWAIT или истекло время ожидания

Почему я получаю эту ошибку базы данных при обновлении таблицы?

ОШИБКА в строке 1: ORA-00054: ресурс занят и получен с указанным значением NOWAIT или истекло время ожидания

Ваша таблица уже заблокирована каким-либо запросом. Например, вы, возможно, выполнили команду «выбрать для обновления» и еще не зафиксировали / откатили и не запустили еще один запрос на выборку. Сделайте коммит / откат перед выполнением вашего запроса.

отсюда ORA-00054: ресурс занят и получен с указанным NOWAIT

Вы также можете посмотреть информацию о sql, имени пользователя, машине, порте и перейти к фактическому процессу, который содержит соединение

SELECT O.OBJECT_NAME, S.SID, S.SERIAL#, P.SPID, S.PROGRAM,S.USERNAME,
S.MACHINE,S.PORT , S.LOGON_TIME,SQ.SQL_FULLTEXT 
FROM V$LOCKED_OBJECT L, DBA_OBJECTS O, V$SESSION S, 
V$PROCESS P, V$SQL SQ 
WHERE L.OBJECT_ID = O.OBJECT_ID 
AND L.SESSION_ID = S.SID AND S.PADDR = P.ADDR 
AND S.SQL_ADDRESS = SQ.ADDRESS;

Пожалуйста, убейте сессию Oracle

Используйте запрос ниже, чтобы проверить информацию об активной сессии

SELECT
    O.OBJECT_NAME,
    S.SID,
    S.SERIAL#,
    P.SPID,
    S.PROGRAM,
    SQ.SQL_FULLTEXT,
    S.LOGON_TIME
FROM
    V$LOCKED_OBJECT L,
    DBA_OBJECTS O,
    V$SESSION S,
    V$PROCESS P,
    V$SQL SQ
WHERE
    L.OBJECT_ID = O.OBJECT_ID
    AND L.SESSION_ID = S.SID
    AND S.PADDR = P.ADDR
    AND S.SQL_ADDRESS = SQ.ADDRESS;

убить как

alter system kill session 'SID,SERIAL#';

(Например alter system kill session '13,36543',;)

Ссылка http://abeytom.blogspot.com/2012/08/finding-and-fixing-ora-00054-resource.html

Существует очень легко обойти эту проблему.

Если вы выполняете трассировку 10046 в своей сессии (Google это ... слишком много, чтобы объяснить). Вы увидите, что перед любой операцией DDL Oracle делает следующее:

LOCK TABLE 'TABLE_NAME' NO WAIT

Так что, если в другой сессии есть открытая транзакция, вы получите ошибку. Так что исправить это ... барабанная дробь, пожалуйста. Создайте свой собственный замок перед DDL и пропустите «NO WAIT».

Специальная записка:

если вы делаете разбиение / удаление разделов, oracle просто блокирует раздел. - так что вы можете просто заблокировать подраздел раздела.

Итак ... Следующие шаги решают проблему.

1. LOCK TABLE 'TABLE NAME'; - вы будете «ждать» (разработчики называют это зависанием). до сеанса с открытой транзакцией, фиксирует. Это очередь. так что может быть несколько сессий впереди вас. но вы не ошибетесь.
2. Выполнить DDL. Затем ваш DDL запустит блокировку без ожидания. Тем не менее, ваша сессия приобрела замок. Так что ты хороший.
3. DDL авто-коммит. Это освобождает замки.

Операторы DML будут «ждать», или, как разработчики называют, «зависать», пока таблица заблокирована.

Я использую это в коде, который запускается из задания для удаления разделов. Работает нормально. Он находится в базе данных, которая постоянно вставляется со скоростью несколько сотен вставок в секунду. Нет ошибок

если вам интересно Делать это в 11г. Я делал это в 10g и раньше, и раньше.

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

SELECT * FROM V$SESSION WHERE STATUS = 'ACTIVE'

Найти SID,

SELECT * FROM V$OPEN_CURSOR WHERE SID = --the id

Это происходит, когда сеанс, отличный от сеанса, используемого для изменения таблицы, удерживает блокировку, вероятно, из-за DML (обновление / удаление / вставка). Если вы разрабатываете новую систему, вполне вероятно, что вы или кто-то из вашей команды выдает оператор обновления, и вы можете прервать сеанс без особых последствий. Или вы можете выполнить коммит из этого сеанса, как только узнаете, у кого этот сеанс открыт.

Если у вас есть доступ к системе администрирования SQL, используйте ее, чтобы найти нарушающий сеанс. И, возможно, убить его.

Вы можете использовать v $ session и v $ lock и другие, но я предлагаю вам Google, как найти этот сеанс и как его убить.

В производственной системе это действительно зависит. Для оракула 10g и старше вы можете выполнить

LOCK TABLE mytable in exclusive mode;
alter table mytable modify mycolumn varchar2(5);

В отдельном сеансе, но подготовьте следующее, если это займет слишком много времени.

alter system kill session '....

Это зависит от того, какая у вас система, более старые системы, скорее всего, не будут фиксировать каждый раз. Это проблема, так как могут быть давно стоящие замки. Таким образом, ваша блокировка предотвратит любые новые блокировки и будет ждать блокировки, которая знает, когда она будет снята. Вот почему у вас есть другое заявление готово. Или вы можете поискать сценарии PLSQL, которые делают подобные вещи автоматически.

В версии 11g появилась новая переменная среды, которая устанавливает время ожидания. Я думаю, что это, вероятно, делает что-то похожее на то, что я описал. Имейте в виду, что проблемы с блокировкой не исчезают.

ALTER SYSTEM SET ddl_lock_timeout=20;
alter table mytable modify mycolumn varchar2(5);

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

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

• Я нашел оскорбительный сеанс с:

  SELECT * FROM V$SESSION WHERE OSUSER='my_local_username';

  Сеанс был неактивным , но все равно как-то удерживал блокировку. Обратите внимание, что вам может понадобиться использовать другое условие WHERE в вашем случае (например, try USERNAMEили MACHINEfields).

• Убил сеанс с помощью IDи SERIAL#приобрел выше:

  alter system kill session '<id>, <serial#>';

Под редакцией @thermz: Если ни один из предыдущих запросов open-session не работает, попробуйте этот. Этот запрос может помочь вам избежать синтаксических ошибок при уничтожении сессий:

• SELECT 'ALTER SYSTEM KILL SESSION '''||SID||','||SERIAL#||''' immediate;' FROM V$SESSION WHERE OSUSER='my_local_username_on_OS'

Просто проверьте процесс проведения сеанса и убейте его. Спина к норме.

Ниже SQL найдет ваш процесс

SELECT s.inst_id,
   s.sid,
   s.serial#,
   p.spid,
   s.username,
   s.program FROM   gv$session s
   JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id;

Тогда убей это

ALTER SYSTEM KILL SESSION 'sid,serial#'

ИЛИ

некоторые примеры, которые я нашел в сети, похоже, нуждаются в идентификаторе экземпляра, а также в сеансе уничтожения системы «130 620, @ 1»;

Ваша проблема выглядит так, как будто вы смешиваете операции DML и DDL. Посмотрите этот URL, который объясняет эту проблему:

http://www.orafaq.com/forum/t/54714/2/

Мне удалось поразить эту ошибку при простом создании таблицы! Очевидно, на столе, который еще не существовал, не было проблем с конкуренцией. В CREATE TABLEзаявлении содержался CONSTRAINT fk_name FOREIGN KEYпункт, ссылающийся на хорошо заполненную таблицу. Мне пришлось:

• Удалите предложение FOREIGN KEY из оператора CREATE TABLE
• Создайте ИНДЕКС для столбца FK
• Создать ФК

Эта ошибка произошла, когда у меня было 2 скрипта, которые я запускал. Я имел:

• Сеанс SQL * Plus, подключенный напрямую с использованием учетной записи пользователя схемы (учетная запись № 1)
• Другой сеанс SQL * Plus, подключенный с использованием другой учетной записи пользователя схемы (учетная запись № 2), но подключение через ссылку на базу данных в качестве первой учетной записи

Я запустил удаление таблицы, затем создание таблицы под учетной записью № 1. Я запустил обновление таблицы во время сеанса № 2. Не совершал изменений. Повторно запустил скрипт удаления / создания таблицы в качестве учетной записи # 1. Ошибка в drop table xкоманде.

Я решил это, запустив COMMIT;сеанс SQL * Plus учетной записи № 2.

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

Решение, данное ссылкой Шаши, является лучшим ... не нужно связываться с dba или кем-то еще

сделать резервную копию

create table xxxx_backup as select * from xxxx;

удалить все строки

delete from xxxx;
commit;

вставьте свою резервную копию.

insert into xxxx (select * from xxxx_backup);
commit;