HikariCP:Hvilke timeouts på databaseniveau skal overvejes for at indstille maxLifetime for Oracle 11g

Kort svar:ingen (som standard).

For en god ordens skyld (for at inkludere detaljer her, hvis linket ændres), taler vi om ejendom maxLifetime af HikariCP:

Denne egenskab styrer den maksimale levetid for en forbindelse i poolen. En ibrugt forbindelse vil aldrig blive trukket tilbage, først når den er lukket, vil den derefter blive fjernet. Vi anbefaler på det kraftigste at indstille denne værdi, og den bør være mindst 30 sekunder mindre end nogen database eller infrastruktur pålagt forbindelsestid. En værdi på 0 angiver ingen maksimal levetid (uendelig levetid), naturligvis underlagt idleTimeout-indstillingen. Standard:1800000 (30 minutter)

Efter min erfaring er det en god ting, at HikariCP gør det. Så vidt jeg kan se håndhæver Oracle som standard ikke en maksimal levetid for forbindelser (hverken på JDBC-driversiden (1) eller på serversiden(2)). Så i denne henseende er "infrastrukturpålagt forbindelsestid " er +uendeligt -- og det var et problem for os, da vi observerede problemer med langvarige forbindelser. Det betyder også, at enhver værdi er "mindst 30 sekunder mindre ", inklusive standarden :)

Jeg formoder forbindelseslaget gør ikke noget ved dette, fordi det regner med poollaget ovenover til at klare sådanne ting. Det var ikke muligt med (nu forældet) implicit forbindelsespulje, og jeg ved ikke, om UCP (erstatningen) gør det, men hvis du bruger HikariCP, bruger du dem ikke.

Nu, efter 30 minutter (normalt efter mange genbrug til forskellige formål) for en given forbindelse, lukker HikariCP den og opretter en ny. Det har en meget lille omkostning og løste vores problemer med langlivede forbindelser. Vi er tilfredse med denne standard, men gør den stadig konfigurerbar for en sikkerheds skyld (se 2 nedenfor).

(1) OracleDataSource tilbyder ikke noget konfigurationspunkt (egenskab eller systemegenskab) til at kontrollere det, og jeg observerede uendelig levetid.

(2) For serversidegrænser, se profilparameteren IDLE_TIME . Citerer dette svar:

Oracle vil som standard ikke lukke en forbindelse på grund af inaktivitet. Du kan konfigurere en profil med en IDLE_TIME for at få Oracle til at lukke inaktive forbindelser.

For at bekræfte, hvad værdien af IDLE_TIME er for din bruger, ved at kombinere svar fra denne Q&A:

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

Standardværdien er UNLIMITED .

Bemærk venligst, at der kan være andre grænser håndhævet andre steder (firewall...), som kan forstyrre. Så du må hellere gøre det konfigurerbart , i tilfælde af at sådanne problemer opdages, når du implementerer dit produkt.

På Linux kan du bekræfte maksimal levetid for fysiske forbindelser ved at overvåge TCP-sockets forbundet til din database. Jeg har kørt scriptet nedenfor på min server (fra DB synspunkt er det klienten host), tager det 1 argument, ip:port af din oracle node, som den vises i output af netstat -tan (eller et mønster, hvis du har flere noder).

#!/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"

_{Hvis du kører det og stopper det med ctrl-c under sleep gang, skulle den forlade sløjfen og rydde op i temp-mappen, men dette er ikke 100 % idiotsikkert}

I resultaterne må ingen af portene vise en værdi, der overstiger 1800 sekunder (dvs. 30 minutter), giv eller tag et minut. Se eksempel output nedenfor, første prøve viser 2 stikkontakter over 1800s, de er væk 10s senere.

------------ 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

_{Du skal køre scriptet i mere end 30 minutter for at se det, fordi det ikke kender alderen på sockets, der eksisterede før}