通常认为，一种糟糕的技术是为每个原子DB活动创建自己的数据库会话。
你有时可能会遇到这样的策略，比如：
- 在循环中处理大量项目时，循环中的每个处理步骤都会创建一个DB会话，执行一小组SQL语句并终止会话
- 轮询进程每秒检查一次SQL结果，每次都在一个新的DB会话中
但是频繁连接和断开DB会话会产生什么成本？
数据库活动的内部记录(AWR/ASH(没有答案，因为建立数据库连接不是SQL活动。
系统负载的简单比较为创建连接的价格提供了模糊提示。
示例：
- 具有4个旧CPU内核(Intel Xeon E312xx，2.6 GHz(的单个主机上的空闲数据库实例
- 一个外部(不在DB主机上(SQLPlus客户端；从DUAL选择SYSTIMESTMP"；每个DB会话
- SQLPlus调用之间的延迟是指每秒创建和销毁1个连接的时间
- 6个线程处于活动状态，每个线程每秒创建1个会话
结果：
- 在4个CPU节点上的空闲数据库CPU负载平均为0.22%
- 有6个线程创建和销毁会话，每秒CPU负载为6.09%
- io等待也发生，平均为1.07%
- 因此，这6个线程平均分配了5.87%的4个CPU节点
- 相当于6个线程一个CPU节点的23.48%，或每个线程3.91%
这意味着：
每秒连接和断开一次Oracle数据库会话的成本约为数据库服务器CPU核心的4%
记住这个值应该有助于考虑是否值得更改与会话创建相关的流程行为。
p.s.：这不考虑在客户端创建会话的额外成本。
表面的实际答案取决于你如何定义"连接"-应用程序所知道的连接是连接，还是到数据库的网络连接，或者是数据库服务器进程&内存用来做任何处理？理论上的总体答案是，建立一些应用程序上下文并启动包含一些内存分配的DB服务器进程，然后在应用程序运行完SQL语句后进行相反的操作，这一过程是"昂贵的"。这在彼得·拉姆的回答中得到了衡量。
在实践中，期望处理大量用户的长时间运行的应用程序会创建一个连接池(例如，在Node.js或Python中(。这些在应用程序的使用寿命内保持开放。从应用程序的角度来看，从池中获取连接以执行某些SQL是一个非常快速的操作。创建连接池的初始成本(最多几秒钟的启动时间(可以在应用程序的进程寿命内摊销。
可以通过额外使用"数据库驻留连接池"来减少数据库层上的服务器进程数量(从而减少开销成本(。
在支持Oracle的高可用性功能方面，这些连接池对Oracle还有其他好处，通常是透明的。但这不是话题。