Oracle 连接被 IIS 耗尽
我们的 Oracle (9i) DBA 打电话给我报告我的 IIS (v6) Web 服务器已耗尽可用连接。
我创建了一个测试页（经典 ASP），它基本上创建 ADODB.Connection 和 ADODB.Recordset 对象，连接到数据库，打开基本记录集，循环它，关闭记录集和连接并将对象设置为空。这就是 Web 服务器上的大多数应用程序所做的事情。
在与 DBA 交谈时，我打开了测试网页。 DBA 能够看到我已连接并记下ID（我假设该ID 帮助他跟踪连接）。页面加载完成，因此，两个对象都发生了Close方法。
DBA 说即使我关闭了浏览器，连接仍然显示。
最终连接消失了，我认为是因为应用程序池回收了。
所以我的问题是：这正常吗？调用 Close 方法后连接是否应该不会消失……或者至少会话已关闭？
我不确定这是否有帮助甚至相关，但我们在网络服务器上的事件查看器中定期看到这些错误：
Event Type: Information
Event Source: Application Error
Event Category: (100)
Event ID: 1004
Date: 7/21/2010
Time: 7:34:20 AM
User: N/A
Computer: VMADE02
Description:
Reporting queued error: faulting application w3wp.exe, version 6.0.3790.3959, faulting module orantcp9.dll, version 9.2.0.6, fault address 0x00005741.
Our Oracle (9i) DBA called me to report that my IIS (v6) web server has exhausted the available connections.
I created a test page (Classic ASP) that basically creates ADODB.Connection and ADODB.Recordset objects, connects to a database, opens a basic recordset, loops through it, closes the recordset and connection and sets the objects to nothing. This is what most of the applications on the web server do.
While speaking with the DBA I opened the test web page. The DBA was able to see that I connected and noted the ID (I assume this ID helps him track the connection). The page finished loading, therefor, the Close method of both objects have occurred.
The DBA said that the connection was still showing, even after I closed the browser.
Eventually the connection went away, I assume because the Application Pool recycled.
So my question is: Is this normal? Should the connection not go away after the Close method is called.. or at least the session is closed?
I'm not sure if this is helpful or even related, but we've seen these errors periodically in the event viewer on the our web servers:
Event Type: Information
Event Source: Application Error
Event Category: (100)
Event ID: 1004
Date: 7/21/2010
Time: 7:34:20 AM
User: N/A
Computer: VMADE02
Description:
Reporting queued error: faulting application w3wp.exe, version 6.0.3790.3959, faulting module orantcp9.dll, version 9.2.0.6, fault address 0x00005741.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
“页面已完成加载，因此，两个对象的 Close 方法一定都已发生。”
这个“必须”其实并非如此。当应用程序内存不足或有时间需要清理时，垃圾收集器就会运行（并执行 COM 对象的析构函数）。每次 IIS 完成页面服务时，这两种情况都不会发生。 Raymond Chen 最近写了一篇关于垃圾回收实际上是什么的好文章的意思，而不是人们认为的意思。他谈论的是 .NET，但同样的原则也适用于此。垃圾收集尝试模拟无限的内存供应。它对 Oracle 的了解不够，无法尝试模拟无限供应的 Oracle 连接。
您只需显式调用 Close() 即可。
在 .NET 中，您可以使用“using”块，它模拟 C++ 样式的堆栈对象 RIIA 语义。但这对于经典 ASP 没有任何帮助。
"The page finished loading, therefor, the Close method of both objects must have occurred."
That "must" is actually not the case. The garbage collector runs (and executes your COM objects' destructors), when the application is low on memory, or when it's got some time to kill. Neither of those conditions is guaranteed to happen every time IIS finishes serving a page. Raymond Chen recently wrote a good article about what garbage collection actually means, as opposed to what people think it means. He's talking about .NET, but the same principles apply here. Garbage collection attempts to simulate an infinite supply of memory. It doesn't know enough about Oracle to try to simulate an infinite supply of Oracle connections.
You'll just have to call Close() explicitly.
In .NET, you could use a "using" block, which simulates C++-style stack-object RIIA semantics. But that's no help in classic ASP.
我不确定这篇文章是否真的那么有用，因为 COM 使用引用计数机制而不是 CLR 垃圾收集器模型。这就是为什么他将对象设置为 Nothing，以显式释放该对象。
当连接池实际上并没有关闭连接时关闭连接。它只是将其释放回池中。我听说过有关连接池“出错”的故事，所以也许尝试禁用它。您还可以指定连接超时值。
据我所知，这两个都可以在应用程序的连接字符串中设置。
I'm not sure that article is actually that useful since COM uses a reference counting mechanism vs CLRs garbage collector model. That's why he set the objects to Nothing, to explicitly release the object.
Closing a connection when connection pooling doesn't actually close the connection. It merely releases it back to the pool. I have heard stories about connection pooling "gone wrong", so perhaps try disabling it. You could also specify a value for the connection timeout.
As far as I am aware both of these can be set in the connection string for the application.