Oracle код формата появляется дважды
Обновлено: 04.07.2024
Windows Server 2003 R2 с установленным на нём Oracle Client 10.2.0.4.
При запуске sqlplus от имени пользователя с администраторскими полномочиями коннект осуществляется без проблем. Но при попытке подключиться к базе от имени пользователя без администраторских полномочий появляется ошибка:
Вызвано это невозможностью создать global object пользователем без администраторских полномочий. Я решил проблему так:
Создал группу ora_dba (имя группы, в данном случае, значения не имеет); Ввёл в эту группу всех пользователей, которым нужно работать с Oracle Client; Пуск, Администрирование, Локальная политика безопасности; В списке слева находим и разворачиваем "Локальные политики"; В списке справа находим "Создание глобальных объектов" и открываем его двойным щелчком мыши; Щёлкаем на "Добавить пользователя или группу…", затем на "Типы объектов…", ставим галочку против "Группы" и нажимаем "Ок"; В поле "Введите имена выбираемых объектов" вводим имя группы в нотации server\group_name ( srv1\ora_dba ). Можно нажать на кнопку "Проверить имена";Результат - ошибок нет, пользователь счастлив и может работать.
ORA-28759: сбой при открытии файла
Суть проблемы в том, что Oracle Wallet Manager (OWM) при редактировании wallets меняет разрешения на доступ к файлу. В результате файл становится доступным только пользователю, от которого был запущен OWM.
Решение:
Измените разрешения на доступ к файлу так, чтобы пользователь, от которого работает Oracle DB, имел доступ хотя бы на чтение.
ORA-12154: TNS:could not resolve the connect identifier specified
PL/SQL Developer и Windows x64.
sqlplus
При попытке подключиться с помощью sqlplus, используя Easy Connect, тоже можно получить ошибку:
Для решения убедитесь, что " $ORACLE_HOME/network/admin/sqlnet.ora " или вообще не содержит параметра " NAMES.DIRECTORY_PATH ", или данный параметр имеет одним из значений (или единственным значением) " EZCONNECT ":
Ошибка компиляции при установке Oracle Client
Первоначально пробуем выполнить:
Для Ubuntu 14.04 вероятно придётся пересоздать symlink:
и создать новый:
и снова пробуем выполнить:
SQL Developer, Oracle XE и ORA-12705 в Linux
При попытке настроить Jasper Reports Integration столкнулся с этой же ошибкой при настройке соединения Tomcat. Решается путём создания " $CATALINA_BASE/bin/setenv.sh " с добавлением в него следующих параметров запуска Java:
У меня содержимое файла выглядит так:
Проблемы с external job (sjsec 6a)
В какой-то момент стал получать ошибку:
Это происходило в Oracle, установленном на сервер под управлением Windows.
Решение — убедитесь и при необходимости запустите сервис OracleJobScheduler<SID>.
Где SID — SID вашего экземпляра БД.
ORA-01075 you are currently logged on
Нашёл решение здесь, но решил у себя продублировать. Итак, если при подключении к БД получаем что-то типа:
нужно выполнить следующие шаги:
подключаемся к системе под именем пользователя, от которого запущен Oracle;SQLDeveloper из Oracle 11g (64 bit) на Windows (64 bit)
Как ни парадоксально, но это решается установкой java 32-bit и добавлением в файл " %ORACLE_HOME%\sqldeveloper\sqldeveloper\bin\sqldeveloper.conf " строки, в которой с помощью SetJavaHome задан JAVA_HOME (путь к java), например так:
ORA-00845: MEMORY_TARGET not supported on this system
На Windows я с такой ошибкой пока не встречался, а на linux решение простое:
правим (или добавляем при остутствии) в " /etc/fstab " строкуГде:
size — размер больше или равен объёму выделяемой для всех экземпляров Oracle памяти. В нашем случае он равен 12Gb (size=12g).
должны получить что-то похожее на следующее:
ORA-12034: materialized view log on "SCHEMA"."MVIEW" younger than last refresh
Можно смотреть ноту 204127.1 на Metlink.
В некоторых случаях помогает:
Проблемы при повторной конфигурации Oracle XE.
Один из вариантов повторной конфигурации Oracle XE заключается в удалении " /etc/sysconfig/oracle-xe " (для Red Hat) и выполнении " /etc/init.d/oracle-xe configure ". Однако, если у вас имеется созданное вами табличное пространство в указанном вами файле данных, выполните обязательно бэкап этого табличного пространства. Указанный скрипт выполнит пересоздание DBID для известных ему файлов данных, но не тронет те, что вы создали. Таким образом, после старта системы вы не сможете ни получить доступ к вашим файлам, ни подключить их к БД, т.к. в них прописаны старые DBID. Будьте внимательнее.
ORA-01704: string literal too long
При работе с Oracle через JDBC, столкнулся с проблемой в виде ошибки "ORA-01704: string literal too long". Оказывается, в некоторых случаях (JDBC — один из них) нельзя просто взять и вставить строку длиной больше 4000 символов в поле таблицы. Даже если это поле типа CLOB. Т.е. не прокатывает строка вида:
Пересоздание сессии в удалённой БД (dblink)
Разработчики стали жаловаться, что, при обращении к объекту, размещённому в удалённой БД, через database link, появляется следующая ошибка:
создаем database link с тем же именем, но с подключением к любому другому серверу (про другую схему того же сервера сказать ничего не могу — не проверял); выполняем любой запрос к удалённой БД через созданный линк; создаём заново линк, но уже с нужными параметрами подключения.В результате, на требуемом нам сервере будет создана новая сессия. Проблема была решена. Такой вот lifehack.
К сожалению, воспроизвести ситуацию уже невозможно, но, вероятно, могла помочь и следующая последовательность действий:
Certificate of the remote server does not match the target address.
Эта заметка относится к Oracle Database 12.2.
В wallet-файле есть необходимый сертификат, но при обращении к ресурсу получаем ошибку:
Ещё один широко известный в узких кругах ресурс:
ORA-27369: job of type EXECUTABLE failed with exit code: 274662
ORA-00392: log 1 of thread 1 is being cleared, operation not allowed
При открытии БД с resetlogs получаем ошибку:
Вероятно, первая команда " alter database open resetlogs " завершилась неудачно и в control-файле redo остались в статусе CLEARING/CLEARING_CURRENT:
Можно попробовать использовать следующие команды:
а затем уже повторить:
На metalink есть документ (Doc ID 1352133.1)
ORA-31640: unable to open dump file "FILENAME" for read
При выполнении импорта средствами Oracle DataPump столкнулся с этой ошибкой (видна в лог-файле). Дамп-файлы были размещены на NFS-разделе, который был смонтирован не совсем корректно. Подсмотрел здесь параметры, которые помогли решить проблему:
Читайте также: