HikariCP: какие тайм-ауты на уровне базы данных следует учитывать для установки maxLifetime для Oracle 11g

Краткий ответ: нет (по умолчанию).

Для справки (чтобы включить сюда подробности на случай изменения ссылки), мы говорим о свойстве maxLifetime HikariCP:

Я предполагаю, что уровень подключения ничего не делает по этому поводу, потому что он рассчитывает на уровень пула выше, чтобы справиться с такими вещами. Это было невозможно с (теперь устаревшим) неявным пулом соединений, и я не знаю, является ли UCP (замена) делает это, но если вы используете HikariCP, вы их не используете.

Теперь, через 30 минут (обычно после многих повторных использований в разных целях) для заданного соединения HikariCP закрывает его и создает новое. Это имеет очень небольшую стоимость и устранило наши проблемы с долгоживущими соединениями. Мы довольны этим значением по умолчанию, но на всякий случай делаем его настраиваемым (см. 2 ниже).

(1) OracleDataSource не предлагает никаких точка конфигурации (свойство или системное свойство) для управления этим, и я наблюдал бесконечное время жизни.

(2) Ограничения на стороне сервера см. в параметре профиля IDLE_TIME. . Цитируя этот ответ:

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

Чтобы проверить, каково значение IDLE_TIME для вашего пользователя, объединив ответы из этих вопросов и ответов:

select p.limit
from dba_profiles p, dba_users u
where p.resource_name = 'IDLE_TIME' and p.profile = u.profile and u.username = '...'
;

Значение по умолчанию: UNLIMITED.

Обратите внимание, что в другом месте могут быть установлены другие ограничения (брандмауэр... ^{да, я был укушен этим, хотя в большинстве систем БД есть механизм проверки активности}), которые могут мешать. Так что лучше сделать его настраиваемым на случай, если такие проблемы обнаружатся при развертывании вашего продукта.

В Linux вы можете проверить максимальное время жизни физических подключений, отслеживая TCP-сокеты, подключенные к вашей базе данных. Я запускал приведенный ниже скрипт на своем сервере (с точки зрения БД, который является хостом client), он принимает 1 аргумент, ip:port вашего узла оракула, как показано в выводе netstat -tan ( или шаблон, если у вас несколько узлов).

#!/bin/bash
target="$1"
dir=$(mktemp -d)
while sleep 10
do
    echo "------------ "$(date)
    now=$(date +%s)
    netstat -tan | grep " $target " | awk '{print $4}' | cut -f2 -d: | while read port
    do
        file="p_$port"
        [ ! -e $file ] && touch $file
        ftime=$(stat -c %Z "$file")
        echo -e "$port :\t "$(( now - ftime))
    done
done
\rm "$dir"/p_*
\rmdir "$dir"

_{Если вы запустите это и остановите его с помощью Ctrl-C в течение sleep времени, он должен выйти из цикла и очистить временный каталог, но это не на 100% надежно}

В результатах ни один из портов не должен показывать значение, превышающее 1800 секунд (т.е. 30 минут), плюс-минус минута. См. пример вывода ниже, первый пример показывает 2 сокета выше 1800, они исчезли через 10 секунд.

------------ Thu Jul 6 16:09:00 CEST 2017
49806 :  1197
49701 :  1569
49772 :  1348
49782 :  1317
49897 :  835
49731 :  1448
49620 :  1830
49700 :  1569
49986 :  523
49722 :  1498
49715 :  1509
49711 :  1539
49629 :  1820
49732 :  1448
50026 :  332
49849 :  1036
49858 :  1016
------------ Thu Jul 6 16:09:10 CEST 2017
49806 :  1207
49701 :  1579
49772 :  1358
49782 :  1327
49897 :  845
49731 :  1458
49700 :  1579
49986 :  533
49722 :  1508
49715 :  1519
49711 :  1549
49732 :  1458
50026 :  342
49849 :  1046
49858 :  1026

_{Чтобы убедиться в этом, вам потребуется запустить скрипт более чем на 30 минут, потому что он не знает возраста сокетов, существовавших ранее}