ORA-28390报错自动登录钱包没开但加密钱包可能开的情况及远程修复方法

ORA-28390这个报错，就是数据库知道你用了透明数据加密（TDE）来保护数据，但在它需要访问被加密的数据时，却找不到打开加密“保险箱”（即加密钱包）的钥匙，你描述的情况“自动登录钱包没开但加密钱包可能开”是一个非常典型且有点微妙的场景，我们来拆解一下。

理解“自动登录钱包没开但加密钱包可能开”是什么意思。

根据Oracle的官方文档对透明数据加密钱包管理的描述,Oracle TDE主要使用两种钱包文件：

1. 加密钱包：这是主钱包文件，通常命名为ewallet.p12，这个文件本身是被一个密码保护的，里面存储了真正的加密主密钥，你可以把它想象成一个需要输入密码才能打开的坚固的主保险箱。
2. 自动登录钱包：这个文件通常命名为cwallet.sso，它的作用是“免密登录”，如果这个文件存在且配置正确，数据库实例启动后就能自动打开钱包，不需要DBA手动干预输入密码，这就像是在主保险箱上装了一个指纹锁，数据库自己的进程就是那个有权限的指纹。

“加密钱包可能开”指的是那个主保险箱ewallet.p12是存在的，并且状态可能是“已打开”（因为之前有人手动输入密码打开过，并且没有关闭）。“自动登录钱包没开”指的是那个免密登录文件cwallet.sso不存在，或者虽然存在但由于某种原因没有被数据库识别或使用。

为什么这种情况下会出问题？

引用自Oracle Support的知识库文章和多位资深DBA在社区（如Oracle Community, OTN）中的解释，核心原因在于数据库进程的“记忆”和依赖，当数据库服务器重启后，所有进程都是全新的，这时，它会按照预设的规则去寻找钱包：

• 它会首先寻找cwallet.sso（自动登录钱包），如果找到了并且有效，皆大欢喜，钱包自动打开。
• 如果找不到cwallet.sso，或者该文件无效，它就会“等待”有人来手动输入密码打开主钱包ewallet.p12。

在你描述的情况里,可能是在一次数据库重启后，由于没有自动登录钱包，数据库一直处于“等待手动打开”的状态，但也许之前某次登录时，有DBA通过SQL*Plus连接后执行了ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "password";，这只是在当前数据库会话的内存中将钱包打开了，对于数据库的后台进程而言，钱包可能仍然是关闭的，或者，钱包的状态在内存中变得不一致，当有新的会话或后台进程（比如SMON、DBWn）需要访问加密数据（例如读取一个加密表空间的数据块）时，它们会发现自己没有权限访问密钥，于是就会抛出ORA-28390错误。

远程修复方法（假设你无法直接接触服务器桌面，只能通过命令行连接）

远程操作的核心思路是：重新建立一个稳定、可靠的 wallet 打开状态，最好是创建并依赖自动登录钱包，一劳永逸。

第一步：确认当前状态 通过SQL*Plus或其他客户端远程连接到数据库，以SYSDBA身份执行：

SELECT * FROM V$ENCRYPTION_WALLET;

重点关注WRL_PARAMETER（钱包位置）和STATUS（状态），这个视图是判断钱包状态最权威的来源，状态可能是CLOSED, OPEN, OPEN_NO_MASTER_KEY等，这个步骤能帮你确认钱包的真实状态，而不是猜测。

第二步：尝试重新打开主钱包（如果状态不是OPEN） 如果状态显示为CLOSED，说明钱包确实关了，你需要使用已知的密码手动打开它：

ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "你的钱包密码";

执行成功后,再次查询V$ENCRYPTION_WALLET，状态应该变为OPEN，这时，普通的加密数据访问应该可以恢复了，但这只是临时解决方案，数据库重启后问题会再现。

第三步：创建自动登录钱包（根治问题） 这是最关键的一步，既然自动登录钱包缺失或无效，我们就创建一个新的，这个操作需要在数据库服务器本地的Oracle用户命令提示符下执行，但可以通过远程终端会话（如SSH）来完成。

1. 确保钱包目录存在且有写权限,目录路径就是第一步查到的WRL_PARAMETER。
2. 切换到Oracle软件安装用户（通常是oracle）。
3. 设置好正确的ORACLE_HOME和ORACLE_SID环境变量。
4. 使用Oracle提供的mkstore工具来创建自动登录钱包，命令格式如下：

   $ORACLE_HOME/bin/mkstore -wrl <钱包目录路径> -createAutoLoginLocal

   mkstore -wrl /u01/app/oracle/admin/ORCL/wallet -createAutoLoginLocal 这个命令会在指定目录下生成（或重置）cwallet.sso文件。-createAutoLoginLocal参数特别重要，它创建的是用于本机的自动登录钱包。

第四步：验证和重启测试 创建完成后，再次通过SQL*Plus检查钱包状态，可能已经是OPEN（因为创建过程有时会触发打开），为了确保万无一失，最好重启数据库实例（如果业务允许的话）：

SHUTDOWN IMMEDIATE;
STARTUP;

数据库启动后,立刻查询V$ENCRYPTION_WALLET，状态应该直接就是OPEN，而不需要你手动输入密码，尝试访问一个加密表进行测试。

重要注意事项（引用自实际操作中的经验教训）：

• 权限问题：确保cwallet.sso文件的属主和权限是正确的（通常是Oracle软件安装用户和oinstall组，权限一般为600），权限不对会导致自动登录失效。
• 钱包备份：在执行任何钱包操作前，强烈建议远程备份整个钱包目录，可以使用SCP或SFTP命令将钱包目录下载到本地安全位置，误操作可能导致数据永久无法访问。
• 密码安全：如果自动登录钱包用于生产环境，需评估安全风险，自动登录虽然方便，但也意味着任何能访问服务器操作系统权限的人都能间接访问加密数据，有时企业安全策略要求只能使用手动打开方式。

解决“ORA-28390且自动登录钱包没开”的问题，关键在于通过远程命令行工具，先确认状态，再手动打开钱包恢复服务，最后通过mkstore工具创建自动登录钱包，从而实现重启后的自愈能力，整个过程依赖于对TDE钱包两种类型及其工作原理的清晰理解。