使用具有多个架构的 Oracle 客户端从 ASP.NET 应用程序获取请求超时异常
我们有一个使用 Oracle 客户端的 ASP.NET 应用程序。在连接字符串中，我们指定 3 个基本属性：数据源、用户 ID 和密码。我们正在使用连接池。我们的数据驻留在 2 个不同的 Oracle 模式中。大多数请求都是针对 Schema1 中的数据。超时来自对 schema2 数据的调用
连接是否可能隐式绑定到架构？
这可以解释很多事情。由于大多数调用都是针对 schema1 中的数据，因此池中充满了仅适用于 schema1 的连接。然后调用来自 schema2 的数据，并且池中的连接都无法满足请求，我们得到超时。
感谢您的帮助， - 格雷格
We have an asp.net application that uses the Oracle client. In the connection string, we specify the 3 basic attributes: data source, User Id, and Password. We are using connection pooling. Our data resides in 2 different Oracle schemas. Most of the requests are for data from Schema1. The timeouts are coming from calls for data from schema2
Is it possible that the connections are implicitly tied to a schema?
That would explain a lot. Since most of the calls are for data from schema1, the pool gets filled with connections that are only good for schema1. Then a call comes for data from schema2 and none of the connections in the pool can satisfy the request and we get the timeout.
Thanks for any help,
- Greg
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Oracle 连接始终与模式绑定，默认为用户自己的模式。如果您使用两个不同的连接字符串，您应该已经有两个单独的池，因此我怀疑您可能已经达到了数据库的总体会话数上限。
您的“SESSIONS”实例参数是什么。将其与连接中的“最大池大小”设置进行比较。我认为 11g 的默认值是 100，但你没有提到哪个版本。您可能需要增加进程，或降低最大池大小。
您应该在看到这些超时时查询 V$SESSION 以了解有多少实际 Oracle 会话。
按用户名从 v$session 组中选择用户名、count(1)；
An Oracle connection is always tied to a schema, the default is the user's own schema. If you use two different connection strings, you should already have two separate pools, so I suspect it may be that you have hit the maximum sessions overall for the database.
What is your "SESSIONS" instance parameter. Compare that to your "Max Pool Size" setting in the connection. Default I think is 100 for 11g, but you didn't mention which version. You may need to bump PROCESSES up, or lower Max Pool Size.
You should query V$SESSION at the time you see these timeouts to see how many actual Oracle sessions.
select username, count(1) from v$session group by username;