Qualquer coisa que acione uma recompilação (alteração web.config, app_offline.htm, alteração de arquivo .aspx, etc.) faz com que o uso da CPU no núcleo atinja o máximo. Se você repetir o processo, ele maximiza o uso da CPU no próximo núcleo, até que o uso geral da CPU esteja em 100%.

Eu conectei windbg com extensões sos e parece que para cada núcleo máximo há 1 thread preso em System.AppDomain.Unload(System.AppDomain) e outro preso em Oracle.DataAccess.Client.OracleTuningAgent.DoScan().

Primeiro tópico

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

Segunda conversa

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

Parece que o AppDomain.Unload está aguardando a conclusão do OracleTuningAgent.DoScan, mas esse encadeamento está bloqueado ou em suspensão.

A Oracle confirmou o problema (bug # 9648040) e é uma prioridade máxima. Enquanto isso, as possíveis soluções alternativas são:

1. Reverter para 11gR1/cliente anterior
2. Adicione 'Self Tuning=false' à string de conexão. É claro que você perderá os benefícios do ajuste automático.

-Scott