Я получаю
ORA-30926: невозможно получить стабильный набор строк в исходных таблицах
в следующем запросе:
MERGE INTO table_1 a
USING
(SELECT a.ROWID row_id, 'Y'
FROM table_1 a ,table_2 b ,table_3 c
WHERE a.mbr = c.mbr
AND b.head = c.head
AND b.type_of_action <> '6') src
ON ( a.ROWID = src.row_id )
WHEN MATCHED THEN UPDATE SET in_correct = 'Y';
Я запустил table_1
, у него есть данные, а также я выполнил внутренний запрос (src
), который также имеет данные.
Почему возникла эта ошибка и как она может быть решена?
Это обычно вызвано дубликатами в запросе, указанном в предложении USING. Вероятно, это означает, что TABLE_A является родительской таблицей, и один и тот же ROWID возвращается несколько раз.
Вы можете быстро решить проблему, используя DISTINCT в своем запросе (фактически, если "Y" - это постоянное значение, которое вам даже не нужно помещать в запрос).
Предполагая, что ваш запрос верен (не знаете ваши таблицы), вы можете сделать что-то вроде этого:
MERGE INTO table_1 a
USING
(SELECT distinct ta.ROWID row_id
FROM table_1 a ,table_2 b ,table_3 c
WHERE a.mbr = c.mbr
AND b.head = c.head
AND b.type_of_action <> '6') src
ON ( a.ROWID = src.row_id )
WHEN MATCHED THEN UPDATE SET in_correct = 'Y';
Вероятно, вы пытаетесь несколько раз обновлять одну и ту же строку целевой таблицы. Я просто столкнулся с той же проблемой в выражении слияния, которое я разработал. Убедитесь, что ваше обновление не затрагивает одну и ту же запись более одного раза при выполнении слияния.
Если бы сегодня была ошибка на 12c, и ни один из существующих ответов не соответствовал (в выражении WHERE не было дубликатов, без детерминированных выражений). Мое дело было связано с этой другой возможной причиной ошибки, в соответствии с текстом сообщения Oracle (выделение ниже):
ORA-30926: невозможно получить стабильный набор строк в исходных таблицах
Причина. Устойчивый набор строк не может быть получен из-за большой активности dml или неопределенного предложения where.
Слияние было частью более крупной партии и было выполнено в живой базе данных со многими параллельными пользователями. Не нужно было менять выражение. Я только что совершил транзакцию до слияния, затем выполнил слияние отдельно и снова совершил транзакцию. Таким образом, решение было найдено в предлагаемом действии сообщения:
Действие: удалите любые недетерминированные предложения where и переиздайте dml.
NETWORK_LINK
который подключается напрямую к исходной базе данных) на этапе сбора статистики, и ваша выделенная заметка, вероятно, объясняет это. К счастью, только статистика была затронута.
Как устранить ошибки ORA-30926? (Doc ID 471956.1)
1) Определите утверждение об ошибке
изменить события набора сеансов '30926 уровень ошибки имени трещины 3;
или
изменить события системного набора "30926 trace name errorstack off;
и наблюдайте за .trc файлами в UDUMP, когда это происходит.
2) Найдя инструкцию SQL, проверьте, правильно ли она (возможно, с помощью плана объяснения или tkprof, чтобы проверить план выполнения запроса) и проанализируйте или вычислите статистику по соответствующим таблицам, если это не было сделано в последнее время. Также могут помочь перестроение (или падение/воссоздание) индексов.
3.1) Является ли оператор SQL MERGE? оцените данные, возвращаемые предложением USING, чтобы убедиться, что в объединении нет повторяющихся значений. Измените оператор слияния, чтобы включить детерминированное предложение where
3.2) Является ли это оператором UPDATE через представление? Если это так, попробуйте заполнить результат просмотра в таблицу и попробуйте обновить таблицу напрямую.
3.3) Есть ли триггер на столе? Попробуйте отключить его, чтобы убедиться, что он все еще не работает.
3.4). Содержит ли оператор неизмеримое представление в "IN-Subquery"? Это может привести к возврату повторяющихся строк, если запрос имеет предложение "FOR UPDATE". См. Bug 2681037
3.5) Имеются ли в таблице неиспользуемые столбцы? Удаление этих данных может помешать ошибке.
4) Если модификация SQL не устраняет ошибку, проблема может быть связана с таблицей, особенно если есть цепочка строк. 4.1) Запустите оператор "АНАЛИЗ ТАБЛИЦЫ VALIDATE STRUCTURE CASCADE" во всех таблицах, используемых в SQL, чтобы увидеть, есть ли какие-либо повреждения в таблице или ее индексах. 4.2) Проверяйте и удаляйте любые CHAINED или migrated ROWS на столе. Есть способы минимизировать это, например, правильную настройку PCTFREE. Использовать примечание 122020.1 - цепочка строк и миграция 4.3) Если таблица дополнительно указана в разделе "Упорядочено", см. Примечание 102932.1 - Мониторинг цепочек строк в IOT