Oracle pegs fornitore di dati processo di IIS quando il sito web è fermo

Question

Stiamo vivendo un brutto problema in Oracle 11g versione 2 in cui il processo w3wp prende il sopravvento e l'intero core del processore, e il debug mostra che il fornitore di dati Oracle sta lanciando ThreadAbortExceptions all'infinito . Uno sviluppatore ha trovato questo problema nel modo seguente:

1) visita un sito Web che utilizza le connessioni di dati Oracle a livello locale (http://localhost/OracleWebSite - usiamo IIS, non il server ASP.NET dev, per tutti i nostri siti). Ciò garantisce che il processo w3wp sia in esecuzione e che nel pool di app esista un pool Oracle attivo di connessioni.

2) Interrompere il sito Web (o eseguire un'operazione Ricostruisci tutto in Visual Studio sul sito Web in questione).

La gestione delle connessioni Oracle nelle applicazioni interessate (tutte le app Web Oracle) è ben consolidata e affidabile. Questo problema non si verifica se disabilitiamo il pool di connessioni. Questo problema non si verifica in Oracle 11g versione 1.

Answer 1

Questo è stato risolto. La correzione viene rilasciata in Oracle 11.2.0.1.2, disponibile sul sito Web oracle.com.

Sfortunatamente la correzione è attualmente disponibile solo tramite un account "My Oracle Support".

Questo è stato risolto in 11.2.0.2 e Patch 9.966.926 Oracle 11g 11.2.0.1 PATCH 5 ERRORE PER WINDOWS (64-bit AMD64 e Intel EM64T).

O WORKAROUND: disabilita l'autoregolazione aggiungendo "Self Tuning = false" alla stringa di connessione.

Answer 2

Tutto ciò che attiva una ricompilazione (modifica web.config, app_offline.htm, cambio file .aspx, ecc.) Causa l'utilizzo della CPU sul core per il massimo. Se si ripete il processo, si esaurisce l'utilizzo della CPU sul core successivo, fino a quando l'utilizzo complessivo della CPU è al 100%.

ho collegato windbg con estensioni sos ed assomiglia per ogni core maxed v'è 1 filo bloccato in System.AppDomain.Unload (System.AppDomain) e un'altra bloccato su Oracle.DataAccess.Client.OracleTuningAgent.DoScan ().

primo filo

• Oracle.DataAccess.Client.OracleTuningAgent.DoScan()
• Oracle.DataAccess.Client.OracleTuningAgent.TuningFunction()
• System.Threading.ExecutionContext.Run (sistema. Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
• System.Threading.ThreadHelper.ThreadStart()

secondo filo

• System.AppDomain.Unload (System.AppDomain)
• System.Web.HttpRuntime.ReleaseResourcesAndUnloadAppDomain (System.Object)
• System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext , System.Threading.ContextCallback, System.Object)
• System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal (System.Threading. _ThreadPoolWaitCallback)
• System.Threading._ThreadPoolWaitCallback.PerformWaitCallback (System.Object)

Sembra AppDomain.Unload è in attesa OracleTuningAgent.DoScan per finire, ma quel filo è bloccato o dormire.

Oracle ha confermato il problema (bug # 9648040) ed è una priorità assoluta. Nel frattempo, le possibili soluzioni sono:

1. Ripristinare 11gR1/in precedenza client
2. Add 'Self Tuning = false' alla stringa di connessione.Ovviamente perderete i vantaggi della sintonizzazione automatica.

-Scott