HikariCP:Vilka tidsgränser på databasnivå bör övervägas för att ställa in maxLifetime för Oracle 11g

Kort svar:inget (som standard).

För säkerhets skull (för att inkludera detaljer här om länken ändras) talar vi om egenskapen maxLifetime av HikariCP:

Den här egenskapen styr den maximala livslängden för en anslutning i poolen. En anslutning som används kommer aldrig att tas bort, först när den stängs kommer den att tas bort. Vi rekommenderar starkt att du ställer in det här värdet, och det bör vara minst 30 sekunder kortare än någon databas eller infrastruktur pålagd anslutningstid. Ett värde på 0 indikerar ingen maximal livslängd (oändlig livstid), givetvis beroende på inställningen idleTimeout. Standard:1800000 (30 minuter)

Enligt min erfarenhet är det bra att HikariCP gör det. Såvitt jag kan säga som standard tillämpar Oracle inte en maximal livslängd för anslutningar (varken på JDBC-drivrutinsidan (1) eller på serversidan(2)). Så i detta avseende "infrastrukturpålagd anslutningstid " är +oändlighet -- och det var ett problem för oss, eftersom vi observerade problem med långlivade anslutningar. Det betyder också att alla värden är "minst 30 sekunder mindre ", inklusive standard :)

Jag förmodar kopplingslagret gör inget åt detta eftersom det räknar med att poollagret ovan klarar av sådant. Det var inte möjligt med (nu utfasad) implicit anslutningspool, och jag vet inte om UCP (ersättningen) gör det, men om du använder HikariCP använder du inte dessa.

Nu, efter 30 minuter (vanligtvis efter många återanvändningar för olika ändamål) för en viss anslutning, stänger HikariCP den och skapar en ny. Det har en mycket liten kostnad och löste våra problem med långlivade anslutningar. Vi är nöjda med den standarden, men gör den ändå konfigurerbar för säkerhets skull (se 2 nedan).

(1) OracleDataSource erbjuder ingen konfigurationspunkt (egenskap eller systemegenskap) för att kontrollera det, och jag observerade oändlig livstid.

(2) För gränser på serversidan, se profilparametern IDLE_TIME . Citerar det här svaret:

Oracle kommer som standard inte att stänga en anslutning på grund av inaktivitet. Du kan konfigurera en profil med en IDLE_TIME för att få Oracle att stänga inaktiva anslutningar.

För att verifiera vad som är värdet på IDLE_TIME för din användare, genom att kombinera svar från denna 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ärdet är UNLIMITED .

Observera att det kan finnas andra gränser som tillämpas på annat håll (brandvägg...) som kan störa. Så du bör göra det konfigurerbart , om sådana problem upptäcks när du distribuerar din produkt.

På Linux kan du verifiera maximal livslängd för fysiska anslutningar genom att övervaka TCP-sockets anslutna till din databas. Jag har kört skriptet nedan på min server (ur DB-synpunkt är det klienten host), tar det ett argument, ip:port av din orakelnod, som den visas i utdata från netstat -tan (eller ett mönster om du har flera 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"

_{Om du kör det och stoppar det med ctrl-c under sleep tid bör den lämna slingan och rensa upp tempkatalogen, men detta är inte 100 % idiotsäkert}

I resultaten ska ingen av portarna visa ett värde som överstiger 1800 sekunder (dvs 30 minuter), ge eller ta en minut. Se exempelutdata nedan, det första exemplet visar 2 uttag över 1800s, de är borta 10s senare.

------------ 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 måste köra skriptet i mer än 30 minuter för att se det, eftersom det inte känner till åldern på sockets som fanns tidigare}