Part2问题报错

多次使用数据库工具登录数据库会报错ORA-12537，十次中有两次会报错，登录方式是 PLSQL Developer ，连接信息是 SCAN IP:端口/服务名。

Part3问题定位1

检查了数据库监听正常、连接数正常、后台报警日志正常以后，暂时没有了思考方式。

在咨询大佬以后，他给出了一个方向就是开启监听trace。

3.1、 查看监听状态

咱们就把其中涉及到的信息进行展示，Trace Level 代表Trace是否开启。Service "cw2" has 1 instance(s). 代表要开启的服务名。

#########节点1#########
[grid@ ~]$ lsnrctl status
Trace Level               off
Service "cw2" has 1 instance(s).
  Instance "cw21", status READY, has 1 handler(s) for this service...
复制

#########节点2#########
[grid@ ~]$ lsnrctl status
Trace Level               off
Service "cw2" has 1 instance(s).
  Instance "cw22", status READY, has 1 handler(s) for this service...
复制

3.2、开启监听trc日志

[grid@ ~]$ lsnrctl 
LSNRCTL> set trc_level 16

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))
LISTENER parameter "trc_level" set to support
The command completed successfully

##查看监听trc状态
[grid@ ~]$ lsnrctl status、

Trace Level               support
Listener Trace File       /u01/app/grid/diag/tnslsnr/cw21/listener/trace/ora_57410_140325609761856.trc
复制

Listener Trace File这个是转储的trc文件。 节点1和2都需要操作开启trc，生成的trc文件都需要转储。

3.3、格式化trc日志

trcasst是oracle自带的格式化trace工具

##节点1
 trcasst /u01/app/grid/diag/tnslsnr/cw21/listener/trace/ora_57410_140325609761856.trc > /tmp/cw21.txt

##节点2
trcasst /u01/app/grid/diag/tnslsnr/cw22/listener/trace/ora_57705_139728913017920.trc > /tmp/cwgxdjzdb22.txt
复制

看不懂，感觉没有报错关键字。 这里我就不贴了，简单的来说，给相关大佬和百度后，都说这个监听日志没问题，所以监听的trc日志主要是为了证明链接的信息和花费资源，而不是错误。

3.4、关闭trc日志

[grid@ ~]$ lsnrctl 
LSNRCTL> trace off
复制

节点1和2都需要操作关闭trc日志。

Part4问题定位2

这个时候没有太好的办法，那就只能从各类监听日志入手 listener.log \ tnsnames.ora \ sqlnet.ora 。

4.1、查看sqlnet.ora

[root@ ~]# find /u01/ -name sqlnet.ora
/u01/app/19.3.0/grid/network/admin/sqlnet.ora

[root@ ~]# cat /u01/app/19.3.0/grid/network/admin/sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
复制

路径有samples的不要，这个是范例模板，不是真实环境所应用的文件。

4.2、确认tnsnames.ora

[root@ ~]# find /u01/ -name tnsnames.ora

/u01/app/oracle/product/19.3.0/db/network/admin/tnsnames.ora

[root@ ~]# cat /u01/app/oracle/product/19.3.0/db/network/admin/tnsnames.ora

CW2 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = cw2-scan)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = cw21)
    )
  )
复制

4.3、查看listener.log监听日志

##########节点1
[root@ trace]# cd /u01/app/grid/diag/tnslsnr/cwgxdjzdb21/listener/trace/
[root@ trace]# cat  listener.log | grep "OMDBb"
* establish * cw2 * 0
复制

##########节点2
[root@ trace]# cd /u01/app/grid/diag/tnslsnr/cw21/listener/trace/
[root@ trace]# cat  listener.log | grep "OMDBb"
* establish * cw2 * 12518
复制

首先是查看你使用plsql登陆的用户信息是什么，我这里的事OMDBb，然后再通过搜寻关键查找每条我登录用户信息。其中如果登录信息这行最后一个数字是登录信息。如果不是0，就是异常错误的。 百度以后表示这个参数就是异常12518。 从这里发现，节点1的登录没有报错，报错的都是节点2. 为了再次验证，我是用 sqlplus 用户/密码@节点2IP（物理IP、虚拟IP）:1521/服务名的方式验证，发现就是节点2登陆会报错 12518，而节点1不会，所以只需要验证节点2的问题即可。

4.4、strace追踪登陆报错

strace -T -t -f -o strace_slow.log sqlplus / as sysdba
#-f 跟踪由fork调用所产生的子进程. 
#-t 在输出中的每一行前加上时间信息. 
#-T 显示每一调用所耗的时间. 

strace -T -t -f -o /tmp/strace_slow2.log sqlplus 业务用户/密码@节点2物理IP:1521/服务名

strace -T -t -f -o /tmp/strace_slow1.log sqlplus 业务用户/密码@节点2物理IP:1521/服务名
复制

经过两个节点的对比strace文件对比

41922 12:30:17 getsockname(9, {sa_family=AF_INET, sin_port=htons(28347), sin_addr=inet_addr("10.29.92.73")}, [16]) = 0 <0.000026>
41922 12:30:17 getsockopt(9, SOL_SOCKET, SO_SNDBUF, [2626560], [4]) = 0 <0.000036>
41922 12:30:17 getsockopt(9, SOL_SOCKET, SO_RCVBUF, [1061296], [4]) = 0 <0.000025>
41922 12:30:17 setsockopt(9, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000027>
41922 12:30:17 fcntl(9, F_SETFD, FD_CLOEXEC) = 0 <0.000022>
41922 12:30:17 rt_sigaction(SIGPIPE, {SIG_IGN, ~[ILL TRAP ABRT BUS FPE SEGV USR2 TERM XCPU XFSZ SYS RTMIN RT_1], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fedc3fa6630}, {SIG_DFL, [], 0}, 8) = 0 <0.000028>
41922 12:30:17 write(9, "\0\351\0\0\1\0\0\0\1>\1,\fA \0\377\377\177\10\0\0\1\0\0\237\0J\0\0\24\0"..., 233) = 233 <0.000061>
41922 12:30:17 read(9, "", 8208)        = 0 <0.001952>
41922 12:30:17 setsockopt(9, SOL_SOCKET, SO_SNDTIMEO, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0 <0.000033>
41922 12:30:17 setsockopt(9, SOL_SOCKET, SO_RCVTIMEO, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0 <0.000027>
41922 12:30:17 close(9)                 = 0 <0.000063>
复制

这个是异常节点的文档，大佬回答说没有获取任何信息就关闭了，应该是权限异常，对比正常节点的strace信息，发现正常节点的信息获取量比异常多得多。

4.5、再次观察listener.log报错

让我再看看listener.log文件

[oracle@primary ~]$ tail -f $ORACLE_BASE/diag/tnslsnr/$(hostname -s)/listener/trace/listener.log
...
Tue Mar 04 19:25:51 2019
04-MAR-2019 19:25:51 * (CONNECT_DATA=(SERVICE_NAME=ORCL)(CID=(PROGRAM=D:\instantclient\sqlplus.exe)(HOST=MACHINE_NAME)(USER=edchen))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.12.123)(PORT=51385)) * establish * ORCL * 12518
TNS-12518: TNS:listener could not hand off client connection
TNS-12546: TNS:permission denied
TNS-12560: TNS:protocol adapter error
TNS-00516: Permission denied
Linux Error: 13: Permission denied
复制

4.6、根据TNS信息再次百度

On the first node.
$ ls -al $ORACLE_HOME/bin/oracle
-rwsr-s--x 1 oracle asmadmin 534683872 Mar 12 16:08

On the second node.
$ ls -al $ORACLE_HOME/bin/oracle
/oracle/database/product/11.2.0/dbhome_1/bin/oracle not found
复制

$ cd $ORACLE_BASE
$ ls -l
total 2
drwxr-xr-x 3 oracle oinstall 96 Mar 12 16:09 product

$ cd product
$ ls -l
total 0
drwx------. 70 oracle oinstall 4096 Jun 21  2024 product
复制

注意是这里的权限异常

正常
cd $ORACLE_BASE
drwxr-xr-x. 71 oracle oinstall 4096 Jun 21  2024 product

问题
cd $ORACLE_BASE
drwx------. 70 oracle oinstall 4096 Jun 21  2024 product
复制

Part5问题解决

本来我是打算直接修改这个

[oracle@cwgxdjzdb22 oracle]$ ls -lrt $ORACLE_BASE
total 4
drwxr-xr-x. 70 oracle oinstall 4096 Jun 21  2024 product
复制

但是群友们的意思是最好使用Mos的工具才安稳点

5.1、使用调整权限工具

[root@cw21 tmp]# chmod 755 permission.pl 

[root@cw21 tmp]# ls -lrt permission.pl 
-rwxr-xr-x 1 grid oinstall 2451 Sep  6 14:02 permission.pl
复制

5.2、在正常节点执行脚本

在正常节点跑这个脚本以前最好处理无用的垃圾文件，因为这个是具体到文件的赋权，我做这个操作，统计了一下赋权的语句，有2207890条

[root@cw21 tmp]# ./permission.pl /u01/

Following log files are generated
logfile      : permission-Mon-Jan-06-14-55-50-2025
Command file : restore-perm-Mon-Jan-06-14-55-50-2025.cmd
Linecount : 1103945
复制

5.3、传输生成文件

[root@cw21:/soft]# scp restore-perm-Mon-Jan-06-14-55-50-2025.cmd permission-Mon-Jan-06-14-55-50-2025 cw22:/soft

复制

5.3、替换主机名、实例名

[root@cw22:/soft]# sed -i 's/cw21/cw22/g' restore-perm-Mon-Jan-06-14-55-50-2025.cmd
[root@cw22:/soft]# sed -i 's/cw21/cw22/g' restore-perm-Mon-Jan-06-14-55-50-2025.cmd
[root@cw22:/soft]# sed -i 's/ASM1/ASM2/g' restore-perm-Mon-Jan-06-14-55-50-2025.cmd
复制

5.3、修改脚本权限并执行

[root@hisdb01:/soft]# chmod 755 restore-perm-Mon-Jan-06-14-55-50-2025.cmd
[root@hisdb01:/soft]# ./restore-perm-Mon-Jan-06-14-55-50-2025.cmd
复制

5.4、健康检查

[grid@hisdb01:~]$ cluvfy comp software -n all -verbose
This software is "325" days old. It is a best practice to update the CRS home by downloading and applying the latest release update. Refer to MOS note 2731675.1 for more details.

Verifying Software home: /u01/app/19.3.0/grid ...1414 files verified
Verifying Software home: /u01/app/19.3.0/grid ...PASSED

Verification of software was successful.

CVU operation performed:      software
Date:                         Nov 30, 2022 8:40:05 PM
CVU home:                     /u01/app/19.3.0/grid/
User:                         grid
复制

注意： 因为这个恢复脚本是具体到文件，所以会有一些（很多）报错。主要是因为正常节点的文件在问题节点不一定有，所以注意报错内容，如果是aud、log之类的这些报错，没有具体文件和路径，是不用管的。

Part6反思梳理

如果你觉得我写的特别凌乱，说明我当时的思路就特别凌乱。后来总结反思如下。

1、遇到ORA-12537报错，如果是集群请确定是哪个节点报错，还是全都报错？

2、确定数据库报错节点以后，请定位listener.log文件来搜寻自己的登录日志信息，并确定登陆报错具体信息

3、确定具体信息以后，大概有三个报错思路， 一个是ll 的权限和属主属组、一个是ORACLE_BASE/product/这里product的权限和属主属组、 观看白名单sqlnet.ora的设置 ，关于属主和属组这个问题，粗鲁点直接改，精细点就用Mos脚本