ORA-28391报错密码不对导致钱包或HSM关不了，远程帮你搞定故障

ORA-28391报错密码不对导致钱包或HSM关不了，远程帮你搞定故障

（引用来源：Oracle官方文档、Oracle技术支持社区案例、资深DBA实践经验总结）

遇到ORA-28391错误，提示密码不正确导致无法关闭加密钱包或硬件安全模块（HSM），这确实是个让人头疼的问题，你别急，这事儿听起来复杂，但很多时候解决起来并不像想象中那么难，我处理过不少这类情况，通过远程连接，大部分都能顺利搞定，下面我就把这里面的门道和解决步骤,用大白话给你讲清楚。

咱们得弄明白这个错误到底是啥意思。（引用来源：Oracle官方文档对ORA-28391的解释）Oracle数据库有一个叫“透明数据加密（TDE）”的功能，它能自动对数据文件进行加密解密，保护敏感数据，这个功能需要一个“钱包”来存放主加密密钥，这个钱包就像你家的保险箱，而密码就是开保险箱的钥匙，当你想要关闭这个钱包（比如进行维护或重启数据库）时，数据库会要求你输入密码进行验证，如果你输入的密码和当初创建或修改钱包时设置的密码对不上号，Oracle就会毫不客气地抛出ORA-28391错误，告诉你“密码不对，关不了”，同样道理，如果你使用的是更高级的HSM（可以理解为一个外部的、更安全的专用硬件保险箱）,密码错误也会导致无法正常断开连接或使其失效。

那为什么会出现密码不对的情况呢？根据我远程协助的经验，常见的原因就那么几种：（引用来源：技术支持社区中用户常见反馈）

1. 记错了密码：这是最普遍的原因，可能设置了复杂的密码，时间一长就忘了；或者当时记录密码的文档丢失、记混了，特别是如果有多套环境（开发、测试、生产），每套环境的钱包密码可能都不一样,很容易张冠李戴。
2. 密码中含有特殊字符：在设置密码时，如果包含了像, , , , , &, 这样的特殊字符，或者在密码开头结尾有空格，在通过命令行工具（比如sqlplus）或者某些脚本输入时，可能会因为 shell 环境（如Linux的bash）或工具本身的解析规则而导致实际传入数据库的密码和你预想的不一致，密码里的感叹号在bash里有特殊含义，可能需要用反斜杠\转义或者用单引号把整个密码括起来。
3. 钱包文件本身损坏：虽然不常见，但万一存放钱包密码信息的文件（通常是ewallet.p12或cwallet.sso）因为磁盘故障、异常关机等原因损坏了,也可能导致密码验证失败。
4. 权限问题：操作系统的用户权限不足，无法正确读取钱包文件，有时也可能引发类似问题,但通常会伴随其他权限错误。

知道了原因，咱们就来看看怎么通过远程操作来排查和解决，远程处理这类问题，核心思路就是“先确认，再尝试，有备份，最后动刀”。（引用来源：资深DBA的标准化故障处理流程）

第一步：建立安全的远程连接并确认环境 我会先让你通过SSH、VPN等安全方式让我连接到你的服务器，上来第一件事不是急着输密码,而是先搞清楚现状：

• 确认数据库状态：用sqlplus / as sysdba登录，查看数据库是否处于打开（OPEN）状态，以及TDE钱包当前是打开（OPEN）还是关闭（CLOSED）状态，可以用命令SELECT status FROM v$encryption_wallet;来查，如果状态已经是CLOSED，那可能问题已经变了,或者你正在尝试的操作不是关闭而是打开。
• 定位钱包文件：找到钱包文件的具体位置，通常它在$ORACLE_BASE/admin/$ORACLE_SID/wallet目录下，或者由sqlnet.ora文件中的ENCRYPTION_WALLET_LOCATION参数指定，确认ewallet.p12和cwallet.sso文件存在。

第二步：系统地尝试可能的密码 这是最关键的一步,需要耐心和细心。

• 回忆和检查：我会让你仔细回忆设置密码时的场景，检查所有可能记录密码的地方，比如密码管理器、文档、部署脚本、配置清单等。
• 规范输入方式：在通过sqlplus执行ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE;命令时，我会特别提醒你注意密码的输入格式。强烈建议使用单引号将密码括起来，以避免特殊字符被shell解释。ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY 'MyC0mpl3xP@ssw0rd!'; 如果密码里本身就包含单引号，那就需要做转义处理，或者尝试使用双引号（但要注意shell和sqlplus对双引号的处理可能不同，有时可能仍需单引号加转义）。
• 尝试常见“错误”：如果明确的密码不对，我会让你尝试一些常见的“变体”，是否开启了Caps Lock导致大小写不对？密码末尾是否不小心多了个空格？数字0和字母O、数字1和字母l是否搞混了？

第三步：如果密码确实忘了——启用备用方案 如果所有能想到的密码都试过了，还是报ORA-28391,那我们就要启动B计划了。

• 寻找自动登录钱包：检查钱包目录下是否存在cwallet.sso文件，这个文件是“自动登录钱包”，它允许数据库实例在启动时自动打开钱包，而不需要手动输入密码。如果这个文件存在且有效，那么恭喜你，问题可能就简单了。 你可以先尝试重启数据库实例，数据库启动过程中通常会自动加载cwallet.sso从而打开钱包，等数据库打开后，你再尝试关闭钱包，有时在这种情况下关闭钱包可以不提供密码（具体行为可能因Oracle版本而异），或者系统会使用自动登录凭证,从而绕过密码验证。
• 使用钱包重置工具（最后的手段）：如果上面方法都行不通，且你没有cwallet.sso自动登录钱包，或者它也不起作用，那就只能考虑“重设”钱包了。警告：此操作会使当前的钱包失效，并使用备份的主密钥来创建一个新的钱包，这意味着你必须要有TDE主密钥的备份！ 如果没有备份，加密的数据将永久无法解密，导致数据丢失！
  • 我会让你先确认是否有可用的主密钥备份，通常是通过ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS...命令创建的备份文件。
  • 备份当前整个钱包目录（以防万一）。
  • 停止数据库实例。
  • 之后，将当前的钱包文件（ewallet.p12和cwallet.sso）重命名或移动到其他位置（相当于删除旧钱包）。
  • 再然后，使用ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS...命令，根据备份文件导入主密钥,在这个过程中你会被提示设置一个新的钱包密码。
  • 启动数据库，并用新密码打开新钱包。 这个过程比较复杂，我会在远程连接上一步步指导你,确保每一步都准确无误。

第四步：根本预防 问题解决后，我肯定会提醒你做好预防措施,避免下次再掉进同一个坑里：

• 安全地记录密码：使用专业的密码管理工具来存储和管理所有重要密码。
• 定期测试密码：定期验证钱包密码是否有效。
• 规范密码设置：尽量避免使用shell敏感的特殊字符，如果要用,务必在脚本和文档中明确标注输入方式。
• 定期备份密钥：严格执行TDE主密钥的备份策略,并将备份文件存放在绝对安全的地方。

ORA-28391虽然棘手，但通过有条理的远程协作，从简单的密码输入技巧检查，到利用自动登录钱包，最后作为终极手段的重建钱包，绝大多数问题都是可以解决的，关键是保持冷静，一步步来,并且永远不要忘记备份的重要性。