Parametry grupowania połączeń ODP.NET

Question

Próbuję skonfigurować buforowanie połączeń dla mojej aplikacji .NET przy użyciu wersji ODP.NET 2.111.6.20. Baza danych to Oracle 11.1.

Używam następujący ciąg połączenia w mojej aplikacji .NET 2.0:

Data Source=prod; User Id=FAKE_USER; Password=FAKE_PASS; Pooling=true; Min Pool Size=2; Max Pool Size=5; Connection Timeout=30;"

Zgodnie z dokumentacją pula powinna zainicjować połączenie z 2 przyłączami i i przyrost do 5 połączeń w zależności od potrzeb. Nigdy nie powinno przekroczyć 5 połączeń.

To, co widzę, to to, że połączenia rosną 2 naraz i dorastają do 10 połączeń. Monitoruję połączenia w bazie danych Oracle, przesyłając kwerendę do tabeli sesji v $, więc wiem, że połączenia pochodzą z konkretnej aplikacji pochodzącej z mojej aplikacji.

Jeśli ktoś może mi pomóc określić, co może się dziać w puli połączeń w tej aplikacji, która może pozwolić na więcej niż maksymalna liczba połączeń, byłbym wdzięczny.

Próbka C# Code

Oto przykład kodu dokonywania połączeń do bazy danych:

const string connectionString = "Data Source=prod; User Id=FAKE_USER; Password=FAKE_PASS; Pooling=true; Min Pool Size=5; Max Pool Size=5; Connection Timeout=30;"; 

using (OracleConnection connection = new OracleConnection(connectionString)) { 
    connection.Open(); 

    using (OracleCommand command = new OracleCommand("ALTER SESSION SET TIME_ZONE='UTC'", connection)) { 
     command.ExecuteScalar(); 
    } 

    using (OracleTransaction transaction = connection.BeginTransaction()) { 
     const string procSql = @"BEGIN P_SERVICES.UPDATE_VERSION(:id, :version, :installDate); END;"; 
     using (OracleCommand command = new OracleCommand(procSql, connection)) { 
      command.Parameters.Add(new OracleParameter("id", OracleDbType.Varchar2) { Value = id }); 
      command.Parameters.Add(new OracleParameter("version", OracleDbType.Varchar2) { Value = version }); 
      command.Parameters.Add(new OracleParameter("installDate", OracleDbType.TimeStamp) { Value = dateUpdated }); 

      try { 
       command.ExecuteNonQuery(); 
      } catch (OracleException oe) { 
       if (Log.IsErrorEnabled) { 
        Log.ErrorFormat("Update Error: {0}", oe.Message); 
       } 

       throw; 
      } 

      transaction.Commit(); 
     } 
    } 
} 

Answer 1

znalazłem powód, że maksymalna połączenia widoczne w bazie danych rośnie obok liczby dozwolonych w ustawieniach puli połączeń w ciągu połączenia.

Application Pool z IIS został skonfigurowany tak, aby mieć „Maksymalna liczba procesów roboczych” określonych inny niż domyślny 1. Co znalazłem to, że liczba połączeń widoczne w bazie danych mogą dorastać do Max Pool Size * Number of Worker Processes .

Więc jeśli mam Max Pool Size z 5 i 5 Pracownik Procesy czym łączna liczba połączeń dozwolone jest 25. Tak więc wydaje się, że każdy proces Pracownik ma własne wystąpienie puli połączeń, które nie są udostępniane w innych procesach roboczych.

Answer 2

według Tom kyte:
połączenie jest układ fizyczny pomiędzy użytkownikiem a bazą danych .
Połączenie może być jeden z wielu typów - najpopularniejszy serwer DEDICATED i serwer SHARED.
Zero, jedna lub więcej sesji może zostać ustanowionych dla danego połączenia z bazą danych
Proces będzie używany przez sesję do wykonywania instrukcji.
Czasami istnieje jeden do jednego związek między CONNECTION-> SESJA-> PROCES (np. Normalne dedykowane połączenie z serwerem).
Czasami istnieje jedno do wielu z połączenia z sesjami .
Proces nie musi być dedykowany dla określonego połączenia lub sesji, na przykład gdy przy użyciu serwera współdzielonego (MTS), twoja SESJA pobierze proces z puli procesów w porządku , aby wykonać instrukcję. Po zakończeniu wywołania proces ten zostaje zwolniony z powrotem do puli procesów.
Tak działa
select username from v$session where username is not null pokaże aktualne seesions (nie przyłączy)
aby zobaczyć połączenia można użyć

select username, program from v$process; 

Przydatna książka o JDBC i Session VS Połączenie można znaleźć here

Answer 3

Ty może użyć tego zapytania do monitorowania stanów połączeń & statusów. Korzystając z tego zapytania, mogłem potwierdzić, że ustawienia ciągu połączenia działają, wyjaśnienie poniżej.

select COUNT(*) AS Connections 
     ,s.username 
     ,s.status 
     ,s.module 
     ,s.osuser 
from V$process p 
join V$session s on s.paddr = p.addr 
where NOT s.UserName IS NULL 
group by s.username 
     ,s.status 
     ,s.module 
     ,s.osuser 

Uruchomiłem to z 2 stron, które zrobiły kilka wyszukiwań baz danych.Oto moje odmienne wyniki:

Max Pool Size = 5

widziałem wahania w liczbie pod pustego modułu z samej nazwy użytkownika jako serwer WWW. Nie jestem pewien, dlaczego pojawili się pod tym wiadrem, a także na serwerze internetowym.

Max Pool Size = 1

Kiedy ogranicza wielkość puli, ja tylko kiedykolwiek widział 1 przyłącze dla modułu pusty, a 1 połączenie do serwera WWW, ale potem połączenia pojawiło się pod DBMS_SCHEDULER, który wskazuje mi, że reszta osób oczekujących była w toku?

Myślę, że to dowodzi, że Max Pool Size działa, ale nie jestem pewien.

Answer 4

Jeśli koniecznie musisz to naprawić, i jesteś gotów zlikwidować liczniki wydajności, ten wpis na blogu może być pomocny. Może to przynajmniej pomóc w zmniejszeniu rozbieżności między liczbą połączeń, które raportuje firma Oracle, a liczbą połączonych nielimitowanych połączeń .NET, które mają.

http://blog.ilab8.com/2011/09/02/odp-net-pooling-and-connection-request-timed-out/

Liczniki te wydają się oni być szczególnie przydatne:

NumberOfActiveConnectionPools 
NumberOfActiveConnections 
NumberOfFreeConnections 
NumberOfInactiveConnectionPools 
NumberOfNonPooledConnections 
NumberOfPooledConnections 
NumberOfReclaimedConnections 
NumberOfStasisConnections