ORA-28398报错导致加密钥匙无法重包，远程帮忙修复方案分享

ORA-28398报错导致加密钥匙无法重包，远程帮忙修复方案分享

最近在处理一个客户的Oracle数据库问题时，遇到了一个比较棘手的错误：ORA-28398，这个错误直接导致了一个关键功能——加密列的钱包重包操作无法进行，由于是远程支持，不能直接操作服务器，所以整个过程需要清晰的思路和谨慎的步骤，下面我就把这次解决问题的实际过程和思路分享出来,希望能给遇到类似情况的朋友一些参考。

我们需要明白ORA-28398这个错误到底是什么意思，根据Oracle官方的解释，这个错误信息通常是“cannot reencrypt wallet with a new password because auto-login wallet is being used”，用大白话讲就是：你试图给一个配置了“自动登录”功能的加密钱包修改密码（也就是重包操作），但系统告诉你不行，自动登录钱包是一种为了方便而设计的钱包，它在数据库启动时不需要手动输入密码就能自动打开,但代价就是你不能随意更改它的密码了。

遇到这个报错，我们解决问题的核心思路就非常明确了：必须先将自动登录钱包转换成需要手动输入密码的标准钱包，然后才能执行重包操作，操作完成后，如果需要，可以再转换回自动登录钱包。

是我在远程协助客户时执行的具体步骤，整个过程需要数据库管理员权限，并且需要极其小心，因为操作不当可能导致钱包损坏,进而引发数据无法访问的严重问题。

第一步：确认当前钱包的状态和位置

在动手之前，必须先搞清楚现状，我让客户在数据库服务器上，使用数据库软件所有者账号（通常是oracle），通过SQL*Plus连接到数据库,执行了以下命令：

SQL> SELECT * FROM V$ENCRYPTION_WALLET;

这个命令会返回钱包的状态和它的完整路径，果然，返回信息显示钱包状态是“OPEN”，并且钱包类型明确标注为“AUTOLOGIN”，这完全印证了ORA-28398报错的原因——我们正在对一个自动登录钱包进行重包操作。

第二步：备份！备份！备份！

这是整个过程中最重要的一步，我反复向客户强调了三次，任何对钱包的操作都有风险，一旦钱包文件损坏，加密数据就可能永远丢失，我指导客户找到上一步查询到的钱包文件路径（通常是ewallet.p12和cwallet.sso），将这两个文件复制到一个安全的备份目录下，这样即使后续操作出现意外,我们也有后悔药可吃。

第三步：关闭数据库

要修改钱包配置，需要先关闭数据库，我让客户执行了正常的关闭命令： SQL> SHUTDOWN IMMEDIATE; 等待数据库完全关闭后,再次连接到空闲实例。

第四步：将自动登录钱包转换为标准钱包

这是关键的一步，我们使用Oracle提供的命令行工具mkstore，我让客户切换到钱包文件所在的目录，然后执行： mkstore -wrl <钱包所在目录路径> -convertToLocal 这个命令的作用就是将自动登录钱包（cwallet.sso）转换回标准钱包（ewallet.p12），执行成功后，目录下的cwallet.sso文件会被删除，只留下ewallet.p12文件。

第五步：重新创建自动登录钱包（可选，但通常是需要的）

虽然我们的目的是重包，但生产环境为了重启方便，一般还是会需要自动登录功能，我们先为当前的标准钱包创建一个自动登录版本，执行命令： mkstore -wrl <钱包所在目录路径> -createAutoLogin 这个命令会重新生成cwallet.sso文件，钱包既是标准的（有ewallet.p12），又是自动登录的（有cwallet.sso）。

第六步：启动数据库并测试

我们尝试启动数据库： SQL> STARTUP; 如果数据库能正常启动，说明钱包的自动登录功能依然有效,我们的转换操作没有破坏钱包本身。

第七步：执行重包操作

终于可以解决最初的问题了，由于钱包现在已经是标准钱包（尽管也有自动登录文件），重包操作的限制已经解除，执行重包命令： SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<旧密码>"; SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<新密码>"; SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "<新密码>"; 这里需要注意的是，第一条命令中的“旧密码”是转换前那个标准钱包（ewallet.p12）的密码，重包操作成功后，钱包的密码就被更新为“新密码”了。

第八步：验证和收尾

重包完成后，我让客户再次执行了第一步的查询命令SELECT * FROM V$ENCRYPTION_WALLET;，确认钱包状态为“OPEN”，并且没有错误信息，也简单查询了一下加密的表，确保数据可以正常访问，我建议客户再次执行一次完整的数据库重启，以验证在新的密码下,自动登录功能是否依然完美工作。

远程协助的注意事项

在整个远程过程中,有几个点需要特别留意：

1. 沟通清晰：每一步命令的目的和可能产生的结果，都要提前向客户解释清楚,获得他们的理解和同意。
2. 密码安全：重包操作涉及钱包密码的变更，新密码需要符合安全策略，并且要通过安全的方式传递给客户,并指导其妥善保存。
3. 应急预案：提前和客户商量好，如果操作失败，如何快速回退到备份的钱包文件,将停机时间降到最低。

通过以上这些步骤，我们最终成功解决了ORA-28398报错，并完成了加密钥匙的重包工作，整个过程虽然不涉及特别高深的技术，但需要对Oracle钱包的机制有清晰的理解，并且每一步都要稳扎稳打，希望这个来自实际运维案例的分享能对大家有所帮助。 参考自Oracle官方文档对ORA-28378的解释及mkstore工具的使用说明,并结合实际运维经验进行）