Abs*_*cle 1 oracle oracle-11g-r2 linux unix
我们有这么多来自前端用户的用户ID锁。我们需要向用户提供一个 shell 脚本，他们可以在操作系统级别运行该脚本，并在 DBA 不存在时自己解锁 ID。
脚本运行时需要解密 sys 密码，并在脚本成功执行后加密。（理想情况下他们不应该看到密码）
我们有多个数据库，所以参数只能以下面的方式传递。
示例语法： ./tmp/unlock_user.sh user instance_name
这要求太多了。我知道。如果有人可以提供帮助，那就太好了。
操作系统：通用 Linux
数据库：11gR2
我们有这么多来自前端用户的用户ID锁。
好的问题陈述。
比你想象的更常见。
我们需要向用户提供一个 shell 脚本，他们可以在操作系统级别运行该脚本，并在 DBA 不存在时自己解锁 ID。
不，你没有。
您需要找出用户为何如此频繁地锁定他们的帐户并解决该问题的根本原因，而不是试图修复症状。
sys密码需要在运行时解密才能运行脚本
不。
只是……不。
... & 脚本成功执行后加密。（理想情况下他们不应该看到密码）
应该永远是任何看到SYS密码的用户的可能性。
曾经。
请记住：您作为 DBA 的工作是清理其他人造成的混乱。 始终为自己保留最大和最好的工具。
我们有多个数据库，所以参数只能以下面的方式传递。
示例语法：./tmp/unlock_user.sh 用户实例名称
这可能是您的问题的一部分。
如果用户在不同的数据库不同的密码，那么他们将会让自己搞得一团糟并锁定自己出。
您的用户真的可以访问您的数据库主机吗？
接下来你会告诉我他们直接连接到数据库并运行 SQL ...
向前进 ...
如果用户和您的数据库之间有一个应用程序层，那么您应该考虑引入一个“应用程序”帐户，其凭据仅供应用程序使用，而用户永远不会知道。 所有数据库连接都将使用这些凭据进行，用户将不会在您的数据库中拥有自己的帐户。好的，这意味着您必须重新实现帐户身份验证，因为数据库不会为您做这件事，但这应该不是一项艰巨的工作。
使用应用程序帐户还有其他好处。
如果用户在这个“共享连接”模型中“把自己锁在外面”，应用程序仍然可以支持他们重置密码（或其他），因为应用程序有自己的凭据和到数据库的连接。如果用户拥有自己的凭据和连接，则他们无法进入数据库以在数据库中重置密码，因此您目前处于困境。
如果用户和数据库之间没有应用程序层（我会认真地问“为什么不”？），那么您可能需要考虑[更多]更具侵入性的东西，例如将 Oracle 连接到 Kerberos 或 [间接] 活动目录，为您的用户提供真正的单点登录体验。