SESSIONS_PER_USER 使用 nodejs 限制
SESSIONS_PER_USER limit with nodejs
我已经为这个问题苦苦挣扎了几个星期：
出于某种原因，我们连接到另一台机器上的 oracle 数据库的 nodejs 脚本开始出现 SESSIONS_PER_USER 限制错误，但我们没有打开任何其他数据库连接。我尝试了我们拥有的另一个用户，但它 returns 完全相同的错误。
最奇怪的是这个服务已经 运行 好几个星期了，这是它第一次给我们这个错误。
我们使用oracledb(https://github.com/oracle/node-oracledb)模块连接数据库。
我们询问了支持团队，但显然他们可以使用我们的用户连接数据库，但是当涉及到使用我们机器（ubuntu 服务器 14.04）中的帐户时，它会出现此错误。我尝试在我们的机器中搜索可能的 "cached" 会话或连接，但我没有在 google...
上找到很多关于此事的帮助
如果有人能就这个问题给我一些帮助，我将不胜感激，因为我不知道我还能做些什么。
提前致谢。
2 对于 any 配置文件来说是一个低得离谱的 SESSIONS_PER_USER 值。将它提高回 UNLIMITED 以用于您的应用程序配置文件。
应用程序或用户需要多个连接的合理原因有很多：
- 后台会话 - 许多工具和应用程序会自动创建一个或多个后台会话。这可能允许您的 IDE 到 运行 并发语句，或者可能用于在您打开 windows.
时异步检索元数据
- 调试 - Oracle 在调试时自动创建后台会话。
- 并行性 - 并行语句可以轻松产生数十个或数百个会话。
- Sniped 连接 - 如果您的数据库设置了非活动超时，一些会话将被终止但不会立即删除。它们有时在
GV$SESSION 中显示为 "sniped"，除非重新启动数据库或等待，否则无法摆脱它们。即使客户端完全没有任何连接，这些会话仍然计入您的限制。
- 连接池 - 我不熟悉你的应用程序设置，但我认为现在大多数应用程序都会自动创建多个连接。
- 日常使用 - 很多人经常同时使用不同的工具连接到数据库，或者使用一种工具连接多个 window打开。
如果有人说 "but our security rules!"，请他们阅读 DoD Security Technical Implementation Guide (STIG)。几乎可以肯定，他们的规则或某些安全审计的结果是基于该文件的。没有什么可以反对拥有大量或无限数量的并发会话。您只需在您的站点特定规则中证明它的合理性。
2 对于防止不必要的调用或防止大量打开的连接来说也是一个低得离谱的值。
很难预测不同的程序在达到该限制时会如何崩溃。找不到活动会话并不奇怪 - 也许程序会尝试自动生成 X 个线程，并在其中一些线程失败时立即将其全部杀死。
请您的管理员确切地解释他们想要完成的任务以及原因。
我的猜测是数据库配置不正确，资源稀缺。例如，参数 PROCESSES 和 SESSIONS 通常默认为低值。如果这些值保持在较小的值，例如 100，则会出现问题，用户不得不争夺连接。
减少数据库中的会话数会很有帮助。但是限制为 2 是不现实的。我见过很多数据库 运行 在旧硬件上运行，有数千个会话。
我继续自己回答这个问题，因为发生的事情是 IT 团队在我们开始出现问题的那一天更改了一些配置...用户配置从 UNLIMITED 请求到 2。碰巧在我们的代码中我们是使用称为 eachLimit 的异步 (nodejs) 方法，您可以在其中分配一个限制迭代次数，它是 2，但不知何故还是让它崩溃了（即使限制为 2）。
解决办法：去掉迭代器，手动1个1个（只有4个元素），反正还是很苛刻，因为我们每天都要做这个任务。
感谢大家的帮助！
我已经为这个问题苦苦挣扎了几个星期：
出于某种原因，我们连接到另一台机器上的 oracle 数据库的 nodejs 脚本开始出现 SESSIONS_PER_USER 限制错误，但我们没有打开任何其他数据库连接。我尝试了我们拥有的另一个用户，但它 returns 完全相同的错误。
最奇怪的是这个服务已经 运行 好几个星期了，这是它第一次给我们这个错误。
我们使用oracledb(https://github.com/oracle/node-oracledb)模块连接数据库。
我们询问了支持团队，但显然他们可以使用我们的用户连接数据库，但是当涉及到使用我们机器（ubuntu 服务器 14.04）中的帐户时，它会出现此错误。我尝试在我们的机器中搜索可能的 "cached" 会话或连接，但我没有在 google...
上找到很多关于此事的帮助如果有人能就这个问题给我一些帮助，我将不胜感激，因为我不知道我还能做些什么。
提前致谢。
2 对于 any 配置文件来说是一个低得离谱的 SESSIONS_PER_USER 值。将它提高回 UNLIMITED 以用于您的应用程序配置文件。
应用程序或用户需要多个连接的合理原因有很多：
- 后台会话 - 许多工具和应用程序会自动创建一个或多个后台会话。这可能允许您的 IDE 到 运行 并发语句，或者可能用于在您打开 windows. 时异步检索元数据
- 调试 - Oracle 在调试时自动创建后台会话。
- 并行性 - 并行语句可以轻松产生数十个或数百个会话。
- Sniped 连接 - 如果您的数据库设置了非活动超时，一些会话将被终止但不会立即删除。它们有时在
GV$SESSION中显示为 "sniped"，除非重新启动数据库或等待，否则无法摆脱它们。即使客户端完全没有任何连接，这些会话仍然计入您的限制。 - 连接池 - 我不熟悉你的应用程序设置，但我认为现在大多数应用程序都会自动创建多个连接。
- 日常使用 - 很多人经常同时使用不同的工具连接到数据库，或者使用一种工具连接多个 window打开。
如果有人说 "but our security rules!"，请他们阅读 DoD Security Technical Implementation Guide (STIG)。几乎可以肯定，他们的规则或某些安全审计的结果是基于该文件的。没有什么可以反对拥有大量或无限数量的并发会话。您只需在您的站点特定规则中证明它的合理性。
2 对于防止不必要的调用或防止大量打开的连接来说也是一个低得离谱的值。
很难预测不同的程序在达到该限制时会如何崩溃。找不到活动会话并不奇怪 - 也许程序会尝试自动生成 X 个线程，并在其中一些线程失败时立即将其全部杀死。
请您的管理员确切地解释他们想要完成的任务以及原因。
我的猜测是数据库配置不正确，资源稀缺。例如，参数 PROCESSES 和 SESSIONS 通常默认为低值。如果这些值保持在较小的值，例如 100，则会出现问题，用户不得不争夺连接。
减少数据库中的会话数会很有帮助。但是限制为 2 是不现实的。我见过很多数据库 运行 在旧硬件上运行，有数千个会话。
我继续自己回答这个问题，因为发生的事情是 IT 团队在我们开始出现问题的那一天更改了一些配置...用户配置从 UNLIMITED 请求到 2。碰巧在我们的代码中我们是使用称为 eachLimit 的异步 (nodejs) 方法，您可以在其中分配一个限制迭代次数，它是 2，但不知何故还是让它崩溃了（即使限制为 2）。
解决办法：去掉迭代器，手动1个1个（只有4个元素），反正还是很苛刻，因为我们每天都要做这个任务。
感谢大家的帮助！