ora 03114 not connected to oracle что это такое
ORA-03114 not connected to ORACLE
Every day first user who is trying to login from application getting ORA-03114 error. After 3 attempts the application is logging to database. Once logged in everything is working fine for all users for the whole day.
Same issue again on next day who is logging in for the 1st time.
What could be the reason for this kind of behavior. Please suggest on how to fix this issue.
Answers
The reason is likely there is a DBA who
— doesn’t read documentation
— doesn’t use online resources
— can only be bothered to post questions like ‘My car doesn’t work, please fix my car’ without doing any troubleshooting himself and without providing any details.
Your request must be considered insulting and rude.
I have read the online info and tried some troubleshooting. But could not get the reason for this issue. The listener log looks good and no error on alertlog about the timed out.
That is the reason I requested here to know if anyone has faced similar issue.
I am not insulting anyone here or being rude with anyone.
The last time i faced this issue it was because the session was disconnected by the DBA(read: Myself).
Probably you can check truss on your listener.
Also it would be helpful to check what entries exist in the alert log before this error is encountered.
User tried to login at 7:50, after 3 failed attempts the user got logged in, listener.log shows connection details at 7:54
— There are no erros in listener.log
01-OCT-2013 07:46:58 * service_update * abc * 0
01-OCT-2013 07:54:00 * (CONNECT_DATA=(SERVICE_NAME=ABC)(CID=(PROGRAM=D:\Apa?Software?Foundation\Tom\bin\tom**5.exe)(HOST=CM*****APP)(USER=SYSTEM))) * (ADDRESS=(PROTOCOL=tcp)(HOST=app server ip)(PORT=57279)) * establish * ABC * 0
01-OCT-2013 07:54:02 * service_update * abc * 0
— No erros in the alter log.
Your reported error code (ora-03114) seems to indicate a possibility that the app is either issuing sql statements before it ever gets connected, or the established connection is getting dropped. Either way, I wouldn’t expect to find much about it in the listener log. The listener only handles the request to get connected to the database. Once that connection is made, the listener is completely out of the picture. You can even stop the listener and it will have no effect on established connections.
ORA-03114 not connected to ORACLE
Answers
Raju, what full version of Oracle is the target datbase? What kind of applciation? Running locally or remote using what version of the Oracle client? What full version of the OS supports the database, the applciation?
We have encountered numerous ORA-03114 errors over the years which would occur causing the existing connection to be broken, but almost all of these errors were due to version specific bugs and a couple of these bugs were also platform specific.
Do you have DCD (dead connection detection) in use? There is an Oracle support note 1550470.1 about DCD and this issue. There are also current notes for EBS auto-invoicing, datapump, rman, and some other products hitting this error but I did not see any note about just connecting.
Since you should know what kind of front-end application is in use and the code base it is written in you should be able to perform a better problem search on support.
Also, Do you start the application everyday? Keep an eye on the system resource when you try to connect to oracle for first time everyday.
Are you sure it is not something like the user starting to work before dns has properly served the location of the server? I often have that issue with my home ISP and websites, no Oracle involved. A couple of reload page and all is fine. Stupid ISP.
All I’m asking to check here is whether or not tnsping is able to make the connection to the said listener
Now you are saying to use it to check the connection to the listener.
Previously you were saying to check the connection to the database.
«try tnsping for the database from a client to see if the connection is being made to the database»
«I’m not expecting there to be any report but just the confirmation whether or not application is able to connect with the database»
«Are you suggesting when the below command is executed we won’t even get a notification for whether or not the connection was successfully made:
Assuming ofcourse RACNODE1 is a valid database instance which is up and running and reachable?
ORA-03113: конец файла в канале связи через
2 часа и 10 минут мой сценарий заканчивается
У меня есть следующие настройки TCP
Когда скрипт работал, я проверил, что TCP-соединение было установлено на моем конце, но на стороне базы данных (машина сервера базы данных) такого соединения не было.
Моя теория такова, что каким-то образом сервер базы данных прерывает соединение. И когда моя система отправляет первый тест активности активности через 2 часа (7200 секунд), она обнаруживает, что соединение больше не активно, и закрывает соединение, и сценарий возвращается.
Я не могу понять, почему система базы данных теряет соединение? Есть ли какие-либо настройки в конце базы данных для увеличения детализации? Или это может быть связано с некоторыми настройками брандмауэра? Кроме того, через 2 часа и 10 минут мы можем догадаться, что 2-часовая часть исходит из tcp_keepalive_time, то есть 10-минутной части. Любая повторная попытка на стороне базы данных?
РЕДАКТИРОВАТЬ : администратор БД и я посмотрели на проблему, я вижу, что TCP-соединение установлено как ESTABLISHED на моем конце, и он не увидел никакого соединения, идущего с моей стороны.
3 ответа
Мы попытались установить SQLNET.EXPIRE_TIME на 10 минут. Но это не сработало. Мы отскочили от сервера базы данных, но он все еще не работал. Возможно, некоторые последние брандмауэры могут не видеть пакеты DCD в качестве действительного трафика, как упомянуто в статье упоминается в статье (также предоставлено @ user1683793 выше). Наконец, мы изменили время keepalive до 25 минут (на клиентском компьютере), чтобы на tcp-соединении был некоторый трафик. К счастью, брандмауэр, похоже, рассматривает пакет поддержки активности как трафик.
У нас было что-то похожее, когда наш брандмауэр сбрасывал соединения Pro * C примерно через два часа, если в этот период у нас не было никаких действий. Нашим решением было сделать:
Каждые 15 минут для каждого соединения с базой данных, чтобы поддерживать активность.
Если я правильно помню, время tcp keep alive, на которое вы ссылаетесь выше, используется только в том случае, если соединение имеет вызов setsockopt с SO_KEEPALIVE. Поскольку фактическое соединение с Oracle управляется Oracle, у нас нет возможности узнать, установлено оно или нет.
В следующий раз, когда я получу внимание наших администраторов баз данных, мне нужно будет заставить их изменить это значение и посмотреть, как это повлияет на ситуацию. Позже во второй ссылке они говорят:
Если значение SQLNET.EXPIRE_TIME меньше времени ожидания простоя соединения FW, то брандмауэр будет рассматривать этот пакет как активность, и время простоя (отключение брандмауэра) никогда не произойдет, пока процессы клиента и сервера не будут активны.
Я ожидаю, что это именно то, что нам нужно.
Некоторые ошибки и их устранение
SP2-1503/SP2-0152
Windows Server 2003 R2 с установленным на нём Oracle Client 10.2.0.4.
При запуске sqlplus от имени пользователя с администраторскими полномочиями коннект осуществляется без проблем. Но при попытке подключиться к базе от имени пользователя без администраторских полномочий появляется ошибка:
Вызвано это невозможностью создать global object пользователем без администраторских полномочий. Я решил проблему так:
ORA-28759: сбой при открытии файла
При выполнении обращения из БД (под Windows) к серверу с поддержкой SSL (по HTTPS) появилась ошибка:
Суть проблемы в том, что 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 Client
Первоначально пробуем выполнить:
Для Ubuntu 14.04 вероятно придётся пересоздать symlink:
и снова пробуем выполнить:
SQL Developer, Oracle XE и ORA-12705 в Linux
У меня содержимое файла выглядит так:
Проблемы с external job (sjsec 6a)
В какой-то момент стал получать ошибку:
ORA-01075 you are currently logged on
Нашёл решение здесь, но решил у себя продублировать. Итак, если при подключении к БД получаем что-то типа:
нужно выполнить следующие шаги:
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 получаем сообщение:
Как ни парадоксально, но это решается установкой 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 решение простое:
Где:
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, появляется следующая ошибка:
В результате, на требуемом нам сервере будет создана новая сессия. Проблема была решена. Такой вот lifehack.
К сожалению, воспроизвести ситуацию уже невозможно, но, вероятно, могла помочь и следующая последовательность действий:
Certificate of the remote server does not match the target address.
Эта заметка относится к Oracle Database 12.2.
В wallet-файле есть необходимый сертификат, но при обращении к ресурсу получаем ошибку:
» habrahabr.ru » и есть то значение, которое необходимо подставить:
Ещё один широко известный в узких кругах ресурс:
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-разделе, который был смонтирован не совсем корректно. Подсмотрел здесь параметры, которые помогли решить проблему: