Документ создан: 29.06.2010

Некоторые ошибки и их устранение

SP2-1503/SP2-0152

Windows Server 2003 R2 с установленным на нём Oracle Client 10.2.0.4.
При запуске sqlplus от имени пользователя с администраторскими полномочиями коннект осуществляется без проблем. Но при попытке подключиться к базе от имени пользователя без администраторских полномочий появляется ошибка:

SP2-1503: Невозможно инициализировать интерфейс вызовов Oracle
SP2-0152: Возможно, ORACLE функционирует неправильно

Вызвано это невозможностью создать global object пользователем без администраторских полномочий. Я решил проблему так:

  1. Создал группу ora_dba (имя группы, в данном случае, значения не имеет);
  2. Ввёл в эту группу всех пользователей, которым нужно работать с Oracle Client;
  3. Пуск, Администрирование, Локальная политика безопасности;
  4. В списке слева находим и разворачиваем "Локальные политики";
  5. Переходим на "Назначение прав пользователя";
  6. В списке справа находим "Создание глобальных объектов" и открываем его двойным щелчком мыши;
  7. Щёлкаем на "Добавить пользователя или группу…", затем на "Типы объектов…", ставим галочку против "Группы" и нажимаем "Ок";
  8. В поле "Введите имена выбираемых объектов" вводим имя группы в нотации server\group_name (srv1\ora_dba). Можно нажать на кнопку "Проверить имена";
  9. Далее - "Ок", и снова - "Ок";
  10. Просим пользователей перелогиниться в системе.

Результат - ошибок нет, пользователь счастлив и может работать.

ORA-28759: сбой при открытии файла

При выполнении обращения из БД (под Windows) к серверу с поддержкой SSL (по HTTPS) появилась ошибка:

> select  utl_http.request ('https://SERVER.DOMAIN.RU/',NULL,'file:\PATH\TO\owm\wallets\','PASSSWORD')  from dual;
select	utl_http.request ('https://SERVER.DOMAIN.RU/',NULL,'file:\PATH\TO\owm\wallets\','PASSSWORD')  from dual
        *
ошибка в строке 1:
ORA-29273: сбой запроса HTTP
ORA-06512: на  "SYS.UTL_HTTP", line 1722
ORA-28759: сбой при открытии файла
ORA-06512: на  line 1

Суть проблемы в том, что Oracle Wallet Manager (OWM) при редактировании wallets меняет разрешения на доступ к файлу. В результате файл становится доступным только пользователю, от которого был запущен OWM.

Решение:
Измените разрешения на доступ к файлу так, чтобы пользователь, от которого работает Oracle DB, имел доступ хотя бы на чтение.

PL/SQL Developer и Windows x64.

Бывает что, при попытке соединиться с сервером из PL/SQL Developer, только что установленного на 64-разрядную ОС Windows, возникает ошибка:

ORA-12154: TNS:could not resolve the connect identifier specified

Скорее всего PL/SQL Developer был установлен по-умолчанию — в "C:\Program Files (x86)\". Решение — поставить в другое место, имя которого без наличия скобок, запятых, точек и т.п., например, в корень диска C:\.

Ошибка компиляции при установке Oracle Client

INFO: /usr/bin/ld: cannot find -lclntsh
/usr/bin/ld: skipping incompatible /usr/lib/libpthread_nonshared.a when searching for /usr/lib/libpthread_nonshared.a
/usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.a

Первоначально пробуем выполнить:

$ORACLE_HOME/bin/genclntsh

Для Ubuntu 14.04 вероятно придётся пересоздать symlink:

sudo rm /usr/lib/libpthread_nonshared.a
sudo ln -s /usr/lib/i386-linux-gnu/libpthread_nonshared.a /usr/lib/libpthread_nonshared.a

и создать новый:

sudo ln -s /usr/lib/i386-linux-gnu/libc_nonshared.a /usr/lib/libc_nonshared.a

и снова пробуем выполнить:

$ORACLE_HOME/bin/genclntsh

SQL Developer, Oracle XE и ORA-12705 в Linux

При попытке из SQL Developer в Linux подключиться к СУБД Oracle XE наткнулся на ошибку "ORA-12705: Cannot access NLS data files or invalid environment specified." Выяснилось, что не обошлось без "особенностей" java, а именно: при запуске приложения, java считывает значение переменной LANG и при LANG=ru_RU.UTF-8 (проверенно) мы получаем ORA-12705. Решение: менять значение переменной LANG, например, на POSIX. Я теперь запускаю так:

LANG=POSIX /opt/oracle/product/11.2.0/client_1/sqldeveloper/sqldeveloper.sh

При попытке настроить Jasper Reports Integration столкнулся с этой же ошибкой при настройке соединения Tomcat. Решается путём создания "$CATALINA_BASE/bin/setenv.sh" с добавлением в него следующих параметров запуска Java:

-Duser.language=en -Duser.region=en

У меня содержимое файла выглядит так:

export JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.region=en"

Проблемы с external job (sjsec 6a)

В какой-то момент стал получать ошибку:

ORA-27370: job slave failed to launch a job of type EXECUTABLE
ORA-27300: OS system dependent operation:accessing job scheduler service failed with status: 2
ORA-27301: OS failure message: The system cannot find the file specified.
ORA-27302: failure occurred at: sjsec 6a
ORA-27303: additional information: The system cannot find the file specified.
ORA-06512: at "SYS.DBMS_ISCHED", line 196
ORA-06512: at "SYS.DBMS_SCHEDULER", line 486
ORA-06512: at line 1

Это происходило в Oracle, установленном на сервер под управлением Windows.
Решение — убедитесь и при необходимости запустите сервис OracleJobScheduler<SID>.
Где SID — SID вашего экземпляра БД.

ORA-01075 you are currently logged on

Нашёл решение здесь, но решил у себя продублировать. Итак, если при подключении к БД получаем что-то типа:

ERROR:
ORA-01075: you are currently logged on

нужно выполнить следующие шаги:

  1. подключаемся к системе под именем пользователя, от которого запущен Oracle;
  2. убеждаемся, что нет работающих Oracle-процессов ;
  3. выполняем ipcs (должны получить нечто похожее):
    $ ipcs
    
    ------ Сегменты совм. исп. памяти --------
    ключ   shmid      владелец права байты nattch     состояние
    0x00000000 7241728    oracle     640        4096       0                       
    0x00000000 7274497    oracle     640        4096       0                       
    0x2683ca7c 7307266    oracle     640        4096       0                       
    
    ------ Массивы семафоров --------
    ключ   semid      владелец права nsems     
    0xde840770 14319618   oracle     640        176       
    0xde840771 14352387   oracle     640        176       
    0xde840772 14385156   oracle     640        176       
    0xde840773 14417925   oracle     640        176       
    0xde840774 14450694   oracle     640        176
  4. "убиваем" совместные сегменты памяти и семафоры
    1. для сегментов памяти:
      ipcrm -m <shmid из предыдущего шага>
    2. для семафоров:
      ipcrm -s <shmid из предыдущего шага>
  5. пробуем подключиться.

SQLDeveloper из Oracle 11g (64 bit) на Windows (64 bit)

При запуске sqldeveloper, который идёт в комплекте с Oracle 11G (11.2.0.4.0, 64bit) и установлен на Windows Server 2008 R2 (64 bit), получаем окно, в котором нас просят указать путь к java.exe. Однако, при указании пути к java, которая идёт вместе с Oracle или же к другой java 64 bit, ничего не происходит, кроме того, что снова появляется это же окно.
Если же пытаемся запустить "%ORACLE_HOME%\sqldeveloper\sqldeveloper\bin\sqldeveloper", то при указании пути к java получаем сообщение:

WARNING: Could not find jvm.cfg! in 'C:\app\oracle\product\11.2.0\dbhome_1\jdk\jre\lib\jvm.cfg'

Как ни парадоксально, но это решается установкой java 32-bit и добавлением в файл "%ORACLE_HOME%\sqldeveloper\sqldeveloper\bin\sqldeveloper.conf" строки, в которой с помощью SetJavaHome задан JAVA_HOME (путь к java), например так:

SetJavaHome C:\app\Java\jdk1.7.0_76_32bit

ORA-00845: MEMORY_TARGET not supported on this system

На Windows я с такой ошибкой пока не встречался, а на linux решение простое:

  • правим (или добавляем при остутствии) в "/etc/fstab" строку
    shmfs                   /dev/shm                tmpfs   size=12g        0 0

    Где:
    size — размер больше или равен объёму выделяемой для всех экземпляров Oracle памяти. В нашем случае он равен 12Gb (size=12g).

  • перемонтируем устройство:
    mount -o remount shmfs
  • проверяем:
    mount | grep -E "^shm"

    должны получить что-то похожее на следующее:

    shmfs on /dev/shm type tmpfs (rw,size=12g)

ORA-12034: materialized view log on "SCHEMA"."MVIEW" younger than last refresh

Можно смотреть ноту 204127.1 на Metlink.
В некоторых случаях помогает:

exec DBMS_MVIEW.refresh('"SCHEMA"."MVIEW"','C');

Проблемы при повторной конфигурации 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. Т.е. не прокатывает строка вида:

INSERT INTO mytable (header, customer, body) VALUES ('header','customer','VERY LONG STRING');

Один из вариантов решения: неименованный PL\SQL-блок и биндинг переменных. Т.е. примерно так:

DECLARE
  vBody               clob;
  vHeader         VARCHAR2(1000);
  vCustomer       VARCHAR2(25);
BEGIN
  vBody := TO_CLOB('very long string');
  vHeader := 'header';
  vCustomer := 'customer';
  EXECUTE IMMEDIATE 'insert into mytable (header, customer, body) values (:1,:2,:3)' using vHeader, vCustomer, vBody;
END;

Пересоздание сессии в удалённой БД (dblink)

Разработчики стали жаловаться, что, при обращении к объекту, размещённому в удалённой БД, через database link, появляется следующая ошибка:

ORA-06540: PL/SQL: compilation error
ORA-06553: PLS-907: cannot load library unit SCHEMA.OBJ1@DL (referenced by SCHEMA.OBJ@DL)

При создании линка с тем же параметрами подключения, но с новым именем, проблем не возникает. Доступа к удалённой БД на уровне DBA нет. Поэкспериментировал на тех серверах, к которым DBA-доступ есть, и обратил внимание, что сессия для линка создаётся один раз и при следующих обращениях через тот же линк, окружение остаётся неизменным. В нашем случае, вероятно, создание сессии произошло в момент, когда не все объекты были в целостном состоянии. Коль так, нужно пересоздать сессию. Убить нашу сессию мы не можем, т.к. нет полномочий. Как быть? А вот как:

  1. удаляем существующий database link;
  2. создаем database link с тем же именем, но с подключением к любому другому серверу (про другую схему того же сервера сказать ничего не могу — не проверял);
  3. выполняем любой запрос к удалённой БД через созданный линк;
  4. удаляем только что созданный линк;
  5. создаём заново линк, но уже с нужными параметрами подключения.

В результате, на требуемом нам сервере будет создана новая сессия. Проблема была решена. Такой вот lifehack.

 
Recent changes RSS feed Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki Donate