Windows Server 2003 R2 с установленным на нём Oracle Client 10.2.0.4.
При запуске sqlplus от имени пользователя с
администраторскими полномочиями коннект осуществляется без проблем. Но при попытке подключиться к базе от имени пользователя без
администраторских полномочий появляется ошибка:
SP2-1503: Невозможно инициализировать интерфейс вызовов Oracle SP2-0152: Возможно, ORACLE функционирует неправильно
Вызвано это невозможностью создать global object пользователем без администраторских полномочий. Я решил проблему так:
ora_dba (имя группы, в данном случае, значения не имеет);server\group_name (srv1\ora_dba). Можно нажать на кнопку "Проверить имена";Результат - ошибок нет, пользователь счастлив и может работать.
При выполнении обращения из БД (под 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, только что установленного на 64-разрядную ОС Windows, возникает ошибка:
ORA-12154: TNS:could not resolve the connect identifier specified
Скорее всего PL/SQL Developer был установлен по-умолчанию — в "C:\Program Files (x86)\". Решение — поставить в другое место, имя которого без наличия скобок, запятых, точек и т.п., например, в корень диска C:\.
При попытке подключиться с помощью sqlplus, используя Easy Connect, тоже можно получить ошибку:
$ sqlplus t1/t1@10.7.0.57:1521/xe SQL*Plus: Release 11.2.0.4.0 Production on Sat Feb 16 16:14:23 2019 Copyright (c) 1982, 2013, Oracle. All rights reserved. ERROR: ORA-12154: TNS:could not resolve the connect identifier specified
Для решения убедитесь, что "$ORACLE_HOME/network/admin/sqlnet.ora" или вообще не содержит параметра "NAMES.DIRECTORY_PATH", или данный параметр имеет одним из значений (или единственным значением) "EZCONNECT":
$ grep "NAMES.DIRECTORY_PATH" $ORACLE_HOME/network/admin/sqlnet.ora NAMES.DIRECTORY_PATH= (TNSNAMES,EZCONNECT)
$ sqlplus t1/t1@10.7.0.57:1521/xe SQL*Plus: Release 11.2.0.4.0 Production on Sat Feb 16 16:19:51 2019 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production SQL>
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 в 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"
В какой-то момент стал получать ошибку:
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 вашего экземпляра БД.
Нашёл решение здесь, но решил у себя продублировать. Итак, если при подключении к БД получаем что-то типа:
ERROR: ORA-01075: you are currently logged on
нужно выполнить следующие шаги:
$ 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
ipcrm -m <shmid из предыдущего шага>
ipcrm -s <shmid из предыдущего шага>
При запуске 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
На 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)
Можно смотреть ноту 204127.1 на Metlink.
В некоторых случаях помогает:
exec DBMS_MVIEW.refresh('"SCHEMA"."MVIEW"','C');
Один из вариантов повторной конфигурации Oracle XE заключается в удалении "/etc/sysconfig/oracle-xe" (для Red Hat) и выполнении
"/etc/init.d/oracle-xe configure". Однако, если у вас имеется созданное вами табличное пространство в указанном вами файле данных, выполните обязательно бэкап этого табличного пространства. Указанный скрипт выполнит пересоздание DBID для известных ему файлов данных, но не тронет те, что вы создали. Таким образом, после старта системы вы не сможете ни получить доступ к вашим файлам, ни подключить их к БД, т.к. в них прописаны старые DBID. Будьте внимательнее.
При работе с 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;
Разработчики стали жаловаться, что, при обращении к объекту, размещённому в удалённой БД, через 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-доступ есть, и обратил внимание, что сессия для линка создаётся один раз и при следующих обращениях через тот же линк, окружение остаётся неизменным. В нашем случае, вероятно, создание сессии произошло в момент, когда не все объекты были в целостном состоянии. Коль так, нужно пересоздать сессию. Убить нашу сессию мы не можем, т.к. нет полномочий. Как быть? А вот как:
В результате, на требуемом нам сервере будет создана новая сессия. Проблема была решена. Такой вот lifehack.
К сожалению, воспроизвести ситуацию уже невозможно, но, вероятно, могла помочь и следующая последовательность действий:
SQL> rollback; SQL> ALTER session close DATABASE link DL;
Эта заметка относится к Oracle Database 12.2.
В wallet-файле есть необходимый сертификат, но при обращении к ресурсу получаем ошибку:
> SELECT substr(utl_http.request('https://www.habr.com', NULL, 'file:/home/oracle/last_used_wallet', 'pwdtst123'),1,50) r FROM dual; SELECT substr(utl_http.request('https://www.habr.com', NULL, 'file:/home/oracle/last_used_wallet', 'pwdtst123'),1,50) r FROM dual * ERROR at line 1: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1501 ORA-24263: Certificate of the remote server does NOT match the target address. ORA-06512: at "SYS.UTL_HTTP", line 380 ORA-06512: at "SYS.UTL_HTTP", line 1441 ORA-06512: at line 1
В utl_http.request в данном релизе добавили аргумент "https_host", который должен соответствовать CN из SSL-сертификата и который выручает, когда адрес сайта отличается от адреса, на который был выпущен сертификат. Однако, firefox, например, не даёт информации о CN (или я не знаю где искать), потому пришлось задействовать openssl:
$ openssl s_client -showcerts -connect habr.com:443 < /dev/null 2>/dev/null | sed -n -e '/ 0 s:/ s/.*CN=\(.*\)/\1/p' habrahabr.ru
"habrahabr.ru" и есть то значение, которое необходимо подставить:
> SELECT substr(utl_http.request('https://www.habr.com', NULL, 'file:/home/oracle/last_used_wallet', 'pwdtst123',https_host=>'habrahabr.ru'),1,50) r FROM dual; R ------------------------------------------------------- <!DOCTYPE html> <html lang="ru" class="no-js"> <
Ещё один широко известный в узких кругах ресурс:
$ openssl s_client -showcerts -connect bash.im:443 < /dev/null 2>/dev/null | sed -n -e '/ 0 s:/ s/.*CN=\(.*\)/\1/p' app42.lolwut.it
> SELECT substr(utl_http.request('https://bash.im', NULL, 'file:/home/oracle/last_used_wallet', 'pwdtst123',https_host=>'app42.lolwut.it'),1,50) r FROM dual; R ------------------------------------------------------- <!doctype html> <html id="godtier"> <head> <title
Если при выполнении shell-скрипта, вызываемого посредством scheduler job'а с типом "external", вы получаете "ORA-27369: job of type EXECUTABLE failed with exit code: 274662", проверьте "$ORACLE_HOME/rdbms/admin/externaljob.ora". Параметры run_user и run_group должны соответствовать пользователю и группе от чьего имени запущен oracle.
$ cat $ORACLE_HOME/rdbms/admin/externaljob.ora # $Header: externaljob.ora 16-dec-2005.20:47:13 rramkiss Exp $ ... ... # run_user = nobody # run_group = nobody run_user = oracle run_group = oinstall
При открытии БД с resetlogs получаем ошибку:
SQL> ALTER DATABASE open resetlogs; ALTER DATABASE open resetlogs * ERROR at line 1: ORA-00392: log 1 of thread 1 IS being cleared, operation NOT allowed ORA-00312: online log 1 thread 1: '/opt/oracle/oradata/lsyb/redo01a.log'
Вероятно, первая команда "alter database open resetlogs" завершилась неудачно и в control-файле redo остались в статусе CLEARING/CLEARING_CURRENT:
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,MEMBERS,ARCHIVED,STATUS,FIRST_CHANGE# from v$log order by first_change# ; GROUP# THREAD# SEQUENCE# MEMBERS ARCHIVED STATUS FIRST_CHANGE# --------------- --------------- --------------- --------------- --------- ------------------ --------------- 2 1 0 2 YES CLEARING 6434801030343 3 1 0 2 YES CLEARING 6434801030352 1 1 0 2 NO CLEARING_CURRENT 6434801030360
Можно попробовать использовать следующие команды:
SQL> ALTER DATABASE clear unarchived logfile GROUP 1 ; DATABASE altered. SQL> ALTER DATABASE clear unarchived logfile GROUP 2 ; DATABASE altered. SQL> ALTER DATABASE clear unarchived logfile GROUP 3 ; DATABASE altered.
а затем уже повторить:
SQL> ALTER DATABASE open resetlogs; DATABASE altered.
На metalink есть документ (Doc ID 1352133.1)