点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！故障节点主机日志存在“Cannot allocate memory” 无法分配内存报错；数据库alert日志出现“ORA-15025:
could not open disk "/dev/asmdisk/asmdisk103"、“I/O error“、
“ORA-27102: out of memory”、“Linux-x86_64 Error: 12: Cannot
allocate memory”
2. 处置方法
1）检查主机参数配置，主机未配置hugepage参数，数据库未使用hugepage进行内存管理。
2）调整主机参数，禁用主机numa功能，设置主机内存hugepage参数，并重启所有节点主机和实例，经一段时间的观察，主机内存使用率正常。
HugePages 是 Linux 操作系统的一个内核特性，让操作系统可以支持现代硬件架构的大页面容量功能。对于 Oracle 数据库，通过启用 HugePages 并使用大页面，可以用一个页表条目代表一个大页面，而不是使用许多条目代表较小的页面，从而可以管理更多内存，减少操作系统对页面状态的维护并提高 TLB 缓存命中率。4. 新炬建议
完善系统上线流程，将不同资产的上线纳入线上管理，并基于平台完善各类资产上线基线检查场景（像上线安全基线一样，形成各类组件的标准化集成基线检查）。如果暂无平台管理，也需要手动检查大页。国产化数据库有悬挂事务，期间通过杀ORACLE端2PC，国产化数据库悬挂事务，后发现CPU使用率较高，决定重启资源proxy释放资源。重启后2pc恢复正常，悬挂恢复正常。但由于大量的跨区访问导致oracle有大量2pc未正常回滚，导致数据库再业务访问订单表期间一直报正在回滚，强制根据报错的事务ID回滚后业务恢复正常。2. 处置方法
1）国产化数据库有悬挂，期间通过杀ORACLE端2PC，国产化数据库悬挂事务及重启proxy、server释放资源。3）数据库存在分布式事务锁，检查数据库并未发现有分布式，等待事件中有“undo segment recover”等待显示该表在回滚；4）通过调整fast_start_parallel_rollback=false 参数加快回滚速度，需要重启数据库，观察回滚仍然没有结束；后根据业务提供的事物ID，手动插入基表强制回滚后，访问恢复正常。事务分成两个阶段进行提交，包括准备阶段与提交阶段。2阶段事务及易出现在跨库的DML操作，例如DBLINK ，异构跨库变更等。因为是分成两个阶段提交，故在事务提交方面存在一些不足：
在事务管理器向所有服务发送提交事务Commit阶段时，某些参与者可能发生网络抖动，无法正常接收到Commit请求，从而导致每个参与者的数据不一致。当有一个参与者出现通信超时，其余所有参与者将一直阻塞无法释放资源单点故障风险：如图可知，资源管理器统一协调所有参与者，一旦资源管理器出现故障，则参与者无法完成Commit操作，会一直处于阻塞状态。尽管资源管理器会重新选举，当还是无法解决之前遗留的阻塞问题。所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。4. 新炬建议
针对异常2pc场景固化到平台，对异常判断后能自动或者白屏化处理。
切换完成后，备库为主库，观察数据库状态为IDLE状态(异常)，手动将库设置为active状态，但瞬间大量的应用连接导致连接风暴，导致数据库无法登陆，因未冻结HACS服务导致再次发生主备库切换，又因第一次主备库切换后当时的主库（现备库）已宕库，从而无法进行接管，导致主备库都挂起。2. 处置过程
1）TT库连接数爆满(2000)，在这些连接中发现有大量清理table_xxxx表所致的latch等待。2）操作引起应用进程弹性扩展导致TT 库连接数爆满，HACS因连接数爆满无法连接到TT库，以为TT库异常进而触发主备切换，第一次切换成功后，又出现短时间内应用连接风暴触发HACS进行第二次切换，导致TT库挂起。3. 新炬建议
1）约束业务侧清理操作时均放到晚上或者版本期间执行，并且减少单次提交数量(<1000)。2）运维人员完善主备操作流程，在TT库发生主备切换后，检查数据库，HA服务状态观察正常之后冻结HA，防止HA软件自主判断导致数据库发生二次切换 ，再恢复完成备库后在解冻HA服务。业务运行缓慢，同时收到告警数据库主机内存使用率高。登录数据库检查发现在白天有rman进程存在，查询数据库rman备份记录显示昨晚rman备份未完成，检查rman日志发现rman进程僵死，杀掉rman进程后恢复正常。因为RMAN本身会消耗大量的IO资源，一般全备RMAN放在非业务高峰期间进行。增加每日rman备份是否成功的告警，对前一天晚上没有完成的rman备份及时发现并考虑终止，防止影响白天业务。1. 现象
某场地Oceanbase数据库主副本节点cpu飙高导致业务连接失败以及大量悬挂事务，其他库CPU和内存无异常，有悬挂事务。
2. 处置过程
1）检查告警主机CPU使用情况，发现主节点飙高，有超过80%的情况；2）利用obstack对cpu飙高的主机抓取堆栈信息，以便根因分析；5）kill 主中心observer进程，业务租户分区主切其他中心；7）拉起主中心observer进程，至此业务恢复。3. 新炬建议
1）加强各类包括OB在内的国产数据库应急方案制定，完善各类国产数据库监控体系，当出现问题后及时根据应急方案进行处置。2）根据抓取的堆栈信息，后续定位为数据库BUG，Oceanbase的plan_Cache泄露导致paln_cache打满，建议升级版本。
确认本次攻击是由wls9-async组件导致，在反序列化处理输入信息时存在缺陷，攻击者可以在/_async/AsyncResponseService路径下传入恶意的XML格式的数据。2. 处置方案
1）通过前端nginx限制/_async路径跳转；2）识别被注入脚本，协同安全组确认是否被执行补丁升级，测试验证后上线生产；3）跟业务沟通，检查安全组设置的白名单，修改为域名根路径进行限制。3. 新炬建议
定期对各类开源组件进行升级，并配置好相关白名单，从而降低各类安全风险。1. 现象
业务迁移到容器云平台上线后，用户反映服务访问缓慢，经过查看大量日志，发现某中心coredns 域名解析存在告警级别报错，怀疑与coredns解析域名迟缓有关。
2. 处置过程
排查Coredns服务日志报错问题，Coredns配置参数，Coredns配置资源，域名解析地址查询及k8s内域名解析测试等。具体操作如下：
1）查看coredns 资源使用情况，docker stats xxxx；2）进入容器测试域名解析情况；kubectl exec -it -n kube-system node-exporter-dpv79 sh；3）查询coredns报错日志情况：kubectl logs -n kube-system coredns-955d54cc8-4blqs；4）查看coredns配置kubectl -n kube-system edit cm coredns；5）扩充coredns单个服务节点内存限制上限为500M；6）扩充coredns副本数为3个节点，增加高可用高并发能力；7）添加dns缓存代理提高集群dns性能即搭建Nodelocaldns cache服务解决cordns域名解析延迟问题。k8s在大规模并发情况下存在一个coredns5秒超时的问题，原因是镜像底层库 DNS 解析行为默认使用 UDP 在同一个 socket 并发 请求 A (ipv4地址) 和 AAAA (ipv6地址)记录。由于 UDP 无状态，两个请求可能会并发创建 conntrack连接跟踪 表，连接跟踪表存放于系统内存中，可以用cat proc/net/nf_conntrack查看，最终会被 DNAT目标地址转换 成同一个集群 DNS 的 Pod IP ，最终它们的五元组就相同了，就会导致 conntrack 冲突。由于 conntrack 的创建和插入是不加锁的，最终后面插入的 conntrack 表项就会被丢弃，导致dns 的 pod 副本只有一个实例的情况就很容易发生，造成现象就是 DNS 5 秒延时，从而请求超时。4. 新炬建议
上线之前，增加大并发请求测试，针对coredns解析进行性能测试2、部署dns缓存代理，当大并发请求时出现，避免出现coredns超时5秒的情况。数据库在表空间存在大量空闲空间的情况下，INSERT语句报无法扩展表空间错误ORA-1683。快速添加数据库表空间文件，解决数据无法插入问题，快速恢复业务。通过分析数据库alert日志，从13:01开始出现ORA-1683表空间无法扩展的报错，索引分区XXXX.IDX_XXXX_202208_PKpartitionPART_210需要在表空间TBS_XXXX_IDX申请1024个连续块的extent，blocksize为8192，即需要申请一个8M的extent（extent由数据文件中一定数据量的连续块构成）；表空间在8月9日14:51之后添加了3个数据库文件来缓解ORA-1683压力，分析表空间为系统管理区，即区的大小不是人为决定，是系统自动管理，根据表的大小自动设置，在系统管理区的模式下，extent的大小随表的增大而增大，如下面的测试，表的初始extent大小为65535bytes，即64K，随着表的变大，当表的大小超过了1M，即到了第16个extent时，则需要申请1047576的extent，即1M，当表进一步变大，区大小将会变成8M，甚至更大的区（索引同理），上面的alert日志报错中，索引分区需要申请8M的extent但失败，通过分析dba_free_space视图，该视图记录的是各个数据文件“连续块”大小（详细见附件），以数据文件500为例，它的空闲空间中包含了133个大小为65536的连续块，总大小计算起来约8.3M，但133个都是互相不连续的，申请超过65536这部分就不能重用，这个数据文件的最大连续块只有3670016，约3.5M，当索引分区需要申请8M的连续块时，显然这里不能提供，表空间的其它数据文件也存在相同情况，大量都是1M或者以下，存在碎片问题，最大的连续块也只有约3.5M，最终insert语句申请8M连续块失败并抛出ORA-1683错误。当表比较大时，对于全表扫描这样的操作，大的extent比较合适，在系统管理区大小的方式下，当表比较小时，区也比较小，当表大时，区也随之变大，但会带来一定的碎片问题，这种方式可以在空间的利用率和全扫描的性能之间找到一种平衡，大多数的情况下也是使用系统管理区方式。如果可以明确某个表或索引它会很大，可以直接建一个统一区大小，并且区比较大的表空间，即使用uniformsize，如1M或者8M，无论表多大，创建在上面的表/索引的区大小都一样，减少碎片问题的产生。4. 新炬建议
通过数据治理，增加对数据库表空间碎片监控，定期对碎片率较高的表空间进行碎片整理，具体利用停机窗口对碎片率较大的表进行MOVE压缩等操作。1. 现象
4个节点主备架构的国产库，主节点告警连接不上，备节点接管转为主库提供服务。2. 处置过程
3）因数据库表字段名称为中文字段，触发数据库BUG，导致数据库重启，主从架构下可以自动处理故障节点，备节点自动接管业务，业务影响较短。3. 新炬建议
2）建立数据库模型管控标准，任何上线都需要通过评审，从而规避中文字符别名；3）根据原厂版本发布情况后期进行版本升级。
2）通过部署的db2pd-d库名-latch自动任务收集日志，发现问题发生时间点有大量的Latch；3）通过部署的psmon工具报告，分析psmon报告发现有insertinto一张表次数多且等latch时间长；对表做runstats收集最新的统计信息后，发现此表的碎片非常严重；4）通过与业务沟通此表每日实时入数据，但是每天也都会delete数据，业务需要没办法改变一边insert一边delete的现状.2. 处置过程
1）针对当前问题以及现有条件，目前最严重的问题为insertinto时寻找空快导致latch过高，因此对表开append属性，每次insert直接到高水位线处即可解决insert的问题；2）表开了append之后，一边insert一边delete会导致表的高水位线涨的疯快，且碎片化程度更高；3）治本的解决办法为找到此表的交易类sql，确保此表的全部交易类sql都走索引，避免碎片导致sql变慢，然后每个季度的停机窗口都对此表做reorg重组，降低高水位线。3. 新炬建议
增加DB2碎片监控，并利用数据治理定期进行碎片整理。
