Обнаружение «ORA-29283: недопустимая файловая операция» только во втором блоке кода (первый блок также выполняется успешно, который также использует UTL_FILE)

У меня есть файл SQL, который содержит 2 блока кода, оба используют функции UTL_FILE для записи 2 разных файлов в одном каталоге.

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

Мой код выглядит следующим образом:

DECLARE
   fileHandler UTL_FILE.FILE_TYPE;
   vline varchar2(4000);
 BEGIN
   fileHandler := UTL_FILE.FOPEN('STAGING_REPORT', 'Report_1.csv', 'W',4000);

    UTL_FILE.FCLOSE(fileHandler);

end;
/

DECLARE
   fileHandler UTL_FILE.FILE_TYPE;
   vline varchar2(4000);
 BEGIN
   fileHandler := UTL_FILE.FOPEN('STAGING_REPORT', 'Report_2.csv', 'W',4000);

   UTL_FILE.FCLOSE(fileHandler);

end;
/ 

Когда я пытаюсь выполнить это в SQLDeveloper, я сначала выполнил два блока отдельно. В этом сценарии первый блок был выполнен успешно, но второй блок выдал ошибку ORA-29283.

Во второй попытке я попытался выполнить оба блока одновременно, т.е. выбрал их оба и нажал RUN. В этом сценарии мой первый блок тоже выполняется успешно, а второй - нет.

После множества таких попыток в настоящее время оба блока выдают ошибку ORA_29283.

В STAGING_REPORT нет файлов отчетов (REPORT_1 и REPORT_2). UTL_FILE.FOPEN создают их во время выполнения.

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

Я использую Oracle 12c. Что мне здесь не хватает?

(Я уже проверил разрешения и другие базовые вещи, такие как разрешение на каталог, и если каталог существует, как я ранее упоминал, этот код выполнялся полнедели назад и частично выполнялся, когда я выполнял его вручную)

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


person Mighty God Loki    schedule 17.09.2019    source источник
comment
Вы используете RAC? И если да, то каталоги существуют на всех узлах; и файлы не существуют ни на одном узле? Я подозреваю, что вы видите это время от времени, когда попадаете в разные экземпляры. Хотя я ожидаю, что одна сессия будет последовательной. (Ваша вторая попытка все еще запускает блоки последовательно, а не параллельно.)   -  person Alex Poole    schedule 17.09.2019
comment
Я не уверен, что означает RAC на данный момент, но каталог находится на удаленном сервере Linux. Этот каталог имеет символическую ссылку. (Ваша вторая попытка все еще запускает блоки последовательно, а не параллельно, кстати.) Я уже подозревал это, но не был уверен, как я могу смягчить это, не могли бы вы дать несколько советов?   -  person Mighty God Loki    schedule 18.09.2019
comment
RAC - это Реальные кластеры приложений. По сути, ваша база данных используется на нескольких серверах. Если у вас есть доступ, запустите select * from v$active_instances; и посмотрите, сколько строк возвращается - если только одна, то проблема не в этом. Но у вас может быть несколько удаленных серверов Linux, и каталог должен существовать на всех из них.   -  person Alex Poole    schedule 18.09.2019
comment
Привет, Алекс, спасибо за объяснение. Я попробовал запрос и обнаружил, что есть два активных сервера, и перепроверил каталог. Каталог присутствует на обоих серверах. Есть два сервера 41 и 42 (которые я видел в результате запроса), но строка подключения, используемая перед этими блоками, относится к 42, то есть только 42 подключен, все равно присутствие или отсутствие dir на 41 (другой сервер) повлияет на этот код (который работает на 42)?   -  person Mighty God Loki    schedule 18.09.2019
comment
Вы подключаетесь к конкретному экземпляру? (И вы повторно подключаетесь между ними?) На самом деле это не та область, о которой я много знаю, мне неясно, может ли она все еще передаваться другому экземпляру - даже min-session. Возможно, стоит проверить / спросить администраторов баз данных, если происходит что-то необычное, может быть, один узел перегружен? (Кроме того, я думаю, проверьте, что привилегии одинаковы для всего пути до каталога на обоих серверах, поэтому может ли учетная запись Oracle читать / писать в нее; и существует ли целевой файл уже на любом сервере ...)   -  person Alex Poole    schedule 18.09.2019
comment
Если у вас есть доступ, вы также можете посмотреть идентификатор документа MoS 1313404.1, и есть другие документы о дальнейшем исследовании этой ошибки, если она не окажется чем-то простым.   -  person Alex Poole    schedule 18.09.2019


Ответы (1)


Во втором запросе вы пропустили расширение файла. Добавьте .csv или какое-либо другое расширение, следовательно, недопустимая операция с файлом.

person Himanshu Ahuja    schedule 17.09.2019
comment
На самом деле исходный код имеет правильное расширение. Я ошибся в указанном коде. Но сейчас исправил. - person Mighty God Loki; 17.09.2019
comment
Можете ли вы поделиться выводом, запустив эти 2 еще раз, или, возможно, файл не был закрыт по причине сбоя второго блока. Попробуй сначала запустить второй блок, я думаю, это не подведет - person Himanshu Ahuja; 17.09.2019
comment
Мой вывод выглядит следующим образом: Error report: ORA-29283: invalid file operation ORA-06512: at "SYS.UTL_FILE", line 536 ORA-29283: invalid file operation ORA-06512: at line 5 29283. 00000 - "invalid file operation" *Cause: An attempt was made to read from a file or directory that does not exist, or file or directory access was denied by the operating system. *Action: Verify file and directory access privileges on the file system, and if reading, verify that the file exists. - person Mighty God Loki; 18.09.2019
comment
Также, как вы упомянули, я уже пробовал сначала выполнить второй блок, но все равно получил ошибку в этом блоке. Также я попытался вставить новый анонимный блок между ними с функцией utl_file.fcloseall, но это тоже не сработало. Я не понимаю, почему файл из первого блока будет мешать выполнению второго блока, потому что оба они имеют разные имена - person Mighty God Loki; 18.09.2019