Grid用户密码丢失但可SSH登录时,应直接用sqlplus / as sysasm执行ALTER USER sys IDENTIFIED BY 新密码修改ASM实例SYS用户密码;若SSH也无法登录,则需root权限重建grid用户、重置密码、修复权限并重启CRS。

Grid用户密码丢失,但还能用grid用户ssh登录节点
这种情况最常见:你人在RAC节点上,ssh grid@node1能进系统,只是忘了sqlplus / as sysasm或crsctl操作时的密码。根本不用碰密码文件,直接改ASM实例口令即可。
关键点在于:Grid Infrastructure的SYSASM密码和Oracle数据库的SYS密码是两套体系,改的是+ASM实例里的SYS用户(它在ASM中等价于Grid用户身份)。
- 先确认当前ASM实例名:
crsctl stat res -t | grep asm,通常叫ora.asm,对应实例名是+ASM1、+ASM2等 - 用grid用户连本地ASM:
export ORACLE_SID=+ASM1; sqlplus / as sysasm - 执行:
ALTER USER sys IDENTIFIED BY <new_password>;</new_password>——注意必须带as sysasm,否则报ORA-01031 - 改完后所有节点都要同步验证:
sqlplus sys/<new_password>@+ASM2 as sysasm</new_password>(替换为对应实例名)
连grid用户SSH都登不进去,但有root权限
这是真断联场景:grid账号被锁、密码全忘、甚至用户被删。此时必须靠root提权重建grid OS用户,并恢复其对GI的控制权。
Grid用户本质是OS级账户,它的权限靠UID/GID和/etc/group中的oinstall、asmadmin、asmdba、asmoper组成员关系决定,不是数据库里某条记录。
- 用root创建grid用户:
useradd -u 1100 -g oinstall -G asmadmin,asmdba,asmoper grid(UID和组名需与原环境一致,查/etc/passwd和/etc/group备份) - 重置密码:
echo "<new_password>" | passwd --stdin grid</new_password>(Linux)或passwd grid(交互式,Windows类系统不适用) - 检查
$ORACLE_HOME归属:chown -R grid:oinstall $ORACLE_HOME,尤其$ORACLE_HOME/bin/oracle必须属grid且setuid位开启(chmod 6751) - 最关键的一步:运行
roothas.sh或rootcrs.sh(取决于单节点HAS还是完整CRS),它会重新校验grid用户权限并注册服务
RAC环境下orapw文件不在本地磁盘,而在ASM中
19c RAC默认把密码文件放在ASM磁盘组里,路径是+GRID/orapw<asm_instance_name></asm_instance_name>,不是$ORACLE_HOME/dbs/。想用orapwd直接覆盖?行不通——orapwd只能写文件系统,不能写ASM。
必须走ASM命令链,且所有节点都要操作,漏一个节点,那个节点就永远认不出新密码。
- 先用已有凭证(如root或另一个可用grid用户)连ASM:
asmcmd -p - 删旧密码文件:
rm +GRID/orapw+ASM1(按实际ASM实例名替换) - 生成新密码文件:
orapwd file='+GRID/orapw+ASM1' password=<new_password> format=12.2</new_password>——format=12.2是19c必需参数,漏了会报ORA-15173 - 强制所有节点重新读取:
crsctl stop crs; crsctl start crs(在每个节点依次执行) - 验证:
sqlplus sys/<new_password>@+ASM1 as sysasm</new_password>,再换节点试+ASM2
改完还是ORA-01017或ORA-01031?盯死这三个位置
Grid密码问题的失败,90%不是命令输错,而是环境状态没对齐。别信“执行完了”,得亲眼看到证据。
-
crsctl check cluster -all输出里每个节点的“CRS active”和“CSS active”必须都是YES;任一NO,sysasm认证直接失效 -
asmcmd ls +GRID/能看到orapw+ASM1,且ls -l显示大小>0;如果文件不存在或为0字节,说明orapwd根本没写进ASM -
ps -ef | grep pmon确认+ASM1进程确实跑在grid用户下,不是root或oracle;用户错了,权限校验直接绕过
真正卡住人的,从来不是语法,而是ASM磁盘组是否在线、CSS守护进程是否同步、grid用户的GID是否和asmadmin组定义一致——这些都得手动敲命令看输出,不能跳步。


















