Параметр время ожидания в Oracle

мы застряли в ситуации, когда один из наших процессов занимает 3 часа вычислений, не касаясь базы данных. Соединение, которое было принято перед вызовом процесса, закрывается Oracle сервер и любой последующий запрос или фиксация вызывают закрытое исключение соединения.

нам кажется, что проблема связана с Oracle, закрывающей соединение, которое простаивает так долго по какой-то причине.

мы попытались изменить EXPIRE_TIMEOUT в заменить sqlnet.но это тоже не помогло.

Что мы можем сделать, чтобы решить эту проблему?

6
connection oracle python-idle

4 ответов

какие ошибки вы получаете при попытке использовать подключение?

Oracle по умолчанию не закрывает соединение из-за бездействия. Вы можете настроить профиль с IDLE_TIME, чтобы заставить Oracle закрыть неактивные соединения, но это не похоже на то, что вы это сделали. Вы также можете настроить Oracle для обнаружения мертвых соединений и закрытия соединения, если клиент не отвечает - Если клиент похоронен в течение трех часов, возможно, что он не отвечает своевременно мода. Но это кажется менее вероятным, ad требует дополнительных шагов настройки.

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

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

7

Ирфан

  1. пожалуйста, убедитесь, что у вас есть resource_limit=TRUE в init.Ora-файл для вступления изменений в силу.

  2. кроме того, проверьте, назначен ли пользователь, для которого вы пытаетесь установить ограничение, профилю по умолчанию.

select profile from dba_users where username = 'TEST_USER';
  PROFILE1

выберите профиль, имя_ресурса, ограничение из dba_profiles где профиль ПРОФИЛЬ1='' и
имя ресурса ='IDLE_TIME'

3 если пользователь asigned к пользовательскому профилю, убедитесь, что параметры для пользовательского профиля установлены согласованно. Вы также должны посмотреть параметр connect_time (по умолчанию или в пользовательском профиле в зависимости от того, что относится к вам. После превышения времени соединения соединение прекращается . )

и, наконец, обратите внимание, что если текущая сессия началась до того, как был установлен параметр, он не будет принят в силу. Изменение kick-in только со следующего сеанса после внесения изменений.

Полезные ссылки.

http://www.adp-gmbh.ch/blog/2005/april/17.html
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:453256655431

спасибо,

Раджеш

3

независимо от того, какую базу данных вы используете, это плохая идея предположить, что ваше соединение будет жить, когда вы хотите его использовать. Один из способов справиться с этим-создать функцию для возврата активного соединения с соответствующей базой данных и вызывать ее каждый раз, когда вам нужен дескриптор/объект/что угодно для данной базы данных. Подпрограмма поддерживает список баз данных и связанных с ними объектов подключения. Если объект подключения, когда функция вызывается, все хорошо и объект возвращается после того, как функция делает что-то с ним, чтобы убедить базу данных держать дескриптор/объект/что угодно открытым. Если нет объекта live connection, подпрограмма открывает новый и возвращает его. Полезно иметь вторую рутину, которая останавливается на таймере, который истекает через 1 минуту или около того. Когда таймер истекает и вызывается вторая подпрограмма, он просматривает список подключений к базе данных, ища те, у которых нет активности в течение заданного периода времени (что-то значительно меньше, чем значение тайм-аута сеанса базы данных). Те, которые были неактивны слишком долго, закрываются и очищаются.

0

кажется, причина connection closed exception то же самое, что @Justin Cave упоминается в его ответе:

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

фактическое сообщение об ошибке Oracle, которое вы получаете, будет указывать, из этих альтернатив причина твоей проблемы.

если еще кто-то хочет знать IDLE_TIME и CONNECT_TIME настроено для профиля, затем можно выполнить следующий запрос:

select * from user_resource_limits user_resource where user_resource.resource_name in ('IDLE_TIME','CONNECT_TIME');
0