ODP.NET: предотвращение тайм-аутов соединения с пулами соединений

Question

На одном сайте я могу подключиться к базе данных Oracle с помощью SQL Developer, оставить его бездействующим в течение длительного времени (например,> 60 минут) и вернуться, и это нормально.На втором сайте, если он простаивает более 5-10 минут (я точно не учел), он оставляет SQL Developer в состоянии, когда новые операции будут прерваны, и мне нужно вручную «Отключить», а затем повторно подключиться, чтобысделать что-нибудь полезное.Это похоже на тайм-аут соединения на втором сайте, и я не знаю, что его вызывает (и я хотел бы знать, как его отключить, хотя это не мой главный вопрос).

Моя программа использует ODP.NET и обрабатывает данные, которые поступают рывками.Каждые 30 минут (для обсуждения) он будет обрабатывать кучу данных, которые будут включать несколько повторных соединений.Он также использует пул соединений.Я настроил пул подключений на использование продолжительности жизни 5 минут.

На втором сайте (а не на первом) я вижу, что моя программа получит исключения тайм-аута подключения (например, ORA-03113) в начале каждого всплеска данных.Я полагаю, что происходит то, что во время потока данных пул соединений используется по назначению.В конце потока проверяется «Время жизни соединения», и соединение не слишком старое, поэтому оно остается в пуле соединений.Затем, через 30 минут, когда поступают новые данные, соединение извлекается из пула (и не проверяется на время жизни или тайм-аута) и используется, а время ожидания истекает, как я вижу в SQL Developer.

Как можно избежать тайм-аута соединения, но при этом использовать пул соединений во время потоков?Из документации (и моего опыта) видно, что соединение проверяется на Lifetime только тогда, когда оно входит в пул, а не когда оно выходит.

Answer 1

Это действительно старый вопрос, но у меня возникли некоторые похожие проблемы с приложением, и поэтому я думаю, что некоторая информация может помочь всем, кто сталкивается с этим вопросом.

Резюме TL; DRзаключается в том, что драйверы ODP.NET и реализация .NET не очень хорошо взаимодействуют друг с другом, и, следовательно, обычный запуск параметров пула обычного соединения не работает точно так, как вы ожидаете.

• Срок действия соединения является основным нарушителем.Я не уверен, что этот блог по-прежнему применим, поскольку он довольно старый, но я еще не нашел никакой документации, чтобы опровергнуть его, и, похоже, он подтверждает поведение, которое я вижу.Согласно блогу, Connection Lifetime действительно завершает более старый сеанс, как и ожидалось, но проверка этого параметра происходит только при обращении к базе данных .Таким образом, другими словами, .NET.
• никогда не будет прерывать длительные бездействующие сеансы. Если в вашем профиле пользователя Oracle установлено значение IDLE_TIME (а не UNLIMITED), то в конечном итоге эти длительные сеансыпараметры холостого хода будут SNIPED по базе данных.Это может привести к возникновению проблем на стороне .NET, потому что, если вы не проверите явно, что ваши соединения все еще открыты, .NET будет обслуживать эти SNIPED соединения, как если бы они все еще были доступны (таким образом, выдает ошибку ORA вышеуказанного тайм-аута).
• Хитрость в решении этой проблемы состоит в том, чтобы убедиться, что в строке подключения указано Data Validation=True;.Это гарантирует, что .NET проверит подключение к сеансу, прежде чем оно будет обслуживать соединение до следующего вызова службы.Когда эта проверка видит сеанс SNIPED, она удаляет его из пула соединений .NET.

С учетом этой информации, наиболее вероятно, что первоначальная проблема OP возникла только на одном сайте изсочетание различных настроек базы данных и / или частоты .NET-вызовов к базе данных.Возможно, у него была проблема в обеих средах, но если бы пользователи в одной среде совершали вызовы достаточно часто, чтобы Connection Lifetime выполнял свою работу, он бы никогда не увидел эти таймауты в этой базе данных.

Теперь у меня все еще нет 'Выяснили, как прекратить простаивающее соединение в .NET до того, как произойдет какой-либо перехват Oracle IDLE_TIME, но если вы используете этот параметр Data Validation = True, то, надеюсь, вы сможете обойти эту проблему.

Answer 2

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

Тем не менее, с настройкой 5 минут Lifetime вы все равно можете достичь тайм-аута, когда ваш рывок станет больше, потому что, когда вы вернете соединения с пулом в следующем рывке, они будут уничтожены. Тогда пул будет занят созданием и удалением соединений и может привести к тайм-ауту соединения, когда нагрузка действительно большая.

Answer 3

Вы можете указать бесконечное время ожидания, установив для свойства OracleCommand.ConnectionTimeout значение 0. В этом случае время ожидания не будет (по крайней мере, на стороне клиента).

В этом случае также используется ConnectionPool.