数据库管理-第三十一期 新处理的几个问题（20220816）

第三十一期 新处理的几个问题

新的一期，回归技术，最近在一体机上和Oracle 19c上处理的小问题。

1 tmpfs ON /dev/shm

Oracle在使用ASMM（Automatic Shared Memory Management）自动共享内存管理来自动管理SGA各组件内存大小时，是需要通过使用挂载在/dev/shm的tmpfs来使用共享内存的。在一般的操作系统配置中会对这一挂载点进行配置：

tmpfs	/dev/shm	tmpfs	defaults,size=xxx k|m	0 0

这里的size要么是内存总大小，要么一个略大于SGA配置的值，我倾向于设置为前者。这次出现的问题是一台新装的X9M-2一体机。在完成dbca建库以后，在启动数据库的时候报错：

SQL> startup
ORA-27125: unable to create shared memory segment
Linux-x86_64 Error: 12: Cannot allocate memory
Additional information: 4648
Additional information: 536870912

这就很奇快，但是无论是操作系统/etc/sysctl.conf中的kernel.shmall配置，还是df-h、ipcs -u都没有明显问题。尝试过一系列检查、刷内存、重启服务器等操作后并未解决问题。因此回归检查/etc/fstab，一体机安装的自动生成配置如下:

tmpfs          /dev/shm        tmpfs   defaults,size=515147m 0 0

df -h |grep /dev/shm
tmpfs                                504G  2.0G  502G   1% /dev/shm

因此尝试用最传统的方式来调整这个size值：

head -1 /proc/meminfo
MemTotal:       527509796 kB -->获取内存总大小以k为单位的值

tmpfs           /dev/shm        tmpfs   defaults,size=527509796k 0 0 -->将tmpfs的size单位从m改为k

mount -o remount /dev/shm
df -h |grep /dev/shm
tmpfs                                504G  2.0G  502G   1% /dev/shm

完成以上操作后，数据库启动过程恢复正常。由于我并不是一个专职的Linux运维工程师，所以我只能怀疑在以m为单位时5115147*1024=527510528略大于系统读取到的527509796，造成了tmpfs其实并没有正确的挂载，导致使用ASMM的数据库无法启动。

2 SQL monitor

这是一个去年下半年装的另一台X8M-2的一体机，运行了有一段时间了，但是使用量和压力并不是太大，性能表现相当出色，因此平时监控也就检查下运行状态、性能表现概况。但是上周一个业务说有个SQL比较卡，在我想在EM上通过SQL Monitor看执行计划的时候，发现了报错：

ORA-12801: error signaled in parallel query server PPA7, instance xxdbadm02.bigdata.xxx.com:xxdbaas2 (2)

为了快速解决问题，麻烦业务方通过PLSQL Developer前台生产语句的执行计划，通过与对表、索引信息的比对，发现是因为涉及分区太多、返回比例极小、缺少索引，导致一体机的offload和smart scan并未展现出该有的性能，将缺失索引加上以后，SQL执行速度恢复正常。
当然这个并不是本节的主要问题，在有EM的情况下，SQL Monitor还是很有用的，对于分析SQL执行、提供优化建议非常便利。而且数据库执行啥东西报错总归要处理。经过基础排查，这个问题确实没影响到生产，因此在MOS上开了个SR。
手动执行收集SQL Monitor的SQL也会有相同的报错：

SQL> select /*+ noparallel */ dbms_sqltune.report_sql_monitor (sql_id=>'3zdnrumk95mh6', report_level=>'ALL', type=>'ACTIVE') from dual;
ERROR:
ORA-12801: error signaled in parallel query server PPA7, instance
xxdbadm02.bigdata.xxx.com:xxdbaas2 (2)
ORA-06512: at "SYS.DBMS_SQLTUNE", line 18940
ORA-22921: length of input buffer is smaller than amount requested
ORA-06512: at "SYS.DBMS_SQLTUNE", line 14318
ORA-06512: at "SYS.DBMS_SQLTUNE", line 19036
ORA-06512: at "SYS.DBMS_SQLTUNE", line 19367
ORA-06512: at line 1

经过上周五到周日三天两夜的排查，中间解决了部分sys的synonym失效的问题、部分dictionary和fixed object统计信息问题后，最终在国外后台老哥协助下，配合使用22921trace，最终发现为一bug（Bug 32266262，Doc ID 2102131.1），与隐藏参数_report_capture_cycle_time有关，这个参数影响的是一个12c引入的新功能Automatic Report Capturing Feature，而这个bug目前在Oracle后台还是处于“not feasible to fix无法修复的状态”，但是提供了workaround：

SQL> alter system set "_report_capture_cycle_time"=0 scope=both sid='*'; /* Default is 60 seconds */

Restart all DB instances one by one

在本周一也就是昨晚申请割接维护窗口完成相关操作后，恢复正常。

3 总结

本期内容涉及的问题相对较少，但也希望对大家有所帮助，继续：知道写了些啥。