点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
- goldendb 长时间执行sql导致cn断连处理
Oceanbase 备份恢复失败。
发现备份环境与恢复环境的OB版本信息不一致，将恢复环境的版本升级后，再次执行恢复成功。在执行备份和恢复之前，确保所有环境中的软件版本完全一致。如果必须进行版本升级，建议同时更新备份环境和恢复环境，以避免兼容性问题。在备份和恢复的流程中加入自动版本检查步骤，如果发现版本不一致，自动提示或阻止操作，减少人为错误。确保备份和恢复操作中有详细的日志记录，包括执行的具体命令、时间、执行状态和任何错误信息。对失败的恢复尝试进行详细的错误分析，找出失败的原因，并根据日志信息进行问题定位和解决。定期审查和更新备份策略，确保其满足当前的业务需求和技术环境。
容器服务中的单个pod在某个时间点内存突增，导致服务访问故障。需要在保证服务正常运行的前提下排查问题原因。业务反应部署的一个服务中的三个pod，其中一个pod内存突增，而此时访问服务已出现故障。在后台定位定位故障pod，使用kubectl edit pod xxxxx -n xxxx 修改故障pod当前标签的值，使其与deployment的标签不匹配，此时故障pod不再受控制器托管，请求也不会落到故障pod上，那么RS会由于当前控制器实际管理pod比期望pod数量少而新增一个pod。提醒业务方检查服务是否可用，在业务反馈服务正常之后，在故障pod中导出dump.hprof内存快照，使用mat工具分析内存快照，发现服务存在内存泄漏的情况。告知业务系统发生内存泄漏的原因是由于其业务在容器中存放大文件照片，导致GC困难，建议业务系统的开发人员，将大对象分割成指定大小的数个小对象进行处理，更有利于GC收集器对其进行回收，避免内存泄漏，最后将从控制器孤立出来的pod手动删除。使用如Prometheus配合Grafana的告警规则可以自动触发警报并执行初步自动化响应措施。2）针对Kubernetes Pod配置合理的资源请求（requests）和限制（limits）确保开发人员遵循最佳实践，例如使用流处理大文件，避免一次性加载到内存中。在持续集成/持续部署（CI/CD）流程中加入性能测试和资源使用效率的评估，以自动识别可能的性能问题。
etcd的master节点不断选举，由于apiserver通常会使用etcd作为存储后端，存储集群状态信息，所以会导致apiserver的leader也不断选举。因为应用节点要与apiserver进行交互，来管理和调度应用程序，上述故障会导致应用节点与apiserver及时的或者正确的通信，影响业务应用的使用。1）检查相关的master节点上的etcd服务运行的状态以及相关events发现etcd集群不断的在选举，从而导致apiserver也不断在选举，因为apiserver配置的环路地址，并且etcd又在不同的主机上面，那么etcd无法通过apiserver的环路地址进行通信。怀疑etcd选举与网卡发生切换有关，所以首先从控制台将有发生网卡切换的节点驱逐。3）将发生过网卡切换的节点提报给硬件厂商，检查相关的网卡硬件硬件厂商更换网卡硬件后，重新纳入该节点到集群，并将该节点设为不可调度状态。使用网络监控工具（如Nagios、Zabbix等）来实时监控网络状态，特别是跨主机通信的稳定性，以便及时发现并解决网络问题。定期对网络进行压力测试和性能评估，以确保网络配置能够承受高负载情况。使用 etcdctl 工具定期检查 etcd 集群的健康状态和性能指标。根据集群运行情况和业务需求调整 etcd 的配置参数，如心跳间隔、选举超时等。确保 etcd 集群具有足够的节点数，以支持故障转移和高可用性。确保关键组件，如 etcd 和 apiserver，都有足够的网络冗余和备份连接。
cn节点重启，dbproxy.log发现Out of memory。查看dbproxy.log发现ErrMsg:Out of memory(need xxx bytes)，结合主机部署的osw日志，发现dbproxy进程内存使用率达到10%，触发oom，查看cn节点部署的长事务采集脚本，发现有一条执行时间超10分的抽取数据，初步判断由该语句导致。在和原厂沟通后确认为版本问题，内存清理存在缺陷。在抽取数据时，对于大结果集语句，cn会将各dn查询结果汇总，再返回客户端，在此过程中可能会导致cn重启。针对导致OOM的长时间运行的SQL，进行详细的性能分析和优化。使用EXPLAIN PLAN或类似工具分析查询执行计划，识别并优化耗时的操作，比如添加合适的索引，调整查询逻辑等。对于可能产生大量结果集的查询，考虑实施分页或者限制返回结果集的大小。根据应用需求和服务器能力，适当增加CN节点的内存配额或优化内存使用方式，以避免因资源不足而触发OOM。实施实时内存使用监控，及时发现和响应内存异常使用情况。工具如Prometheus和Grafana可以用来设置内存使用警报。根据数据库的具体负载调整数据库配置参数，如工作内存（work_mem）、缓冲区大小（buffer pool size）等，以提高查询效率和系统稳定性。监控并管理长时间事务，设定超时时间或警告阈值，避免单一事务占用过多资源。
和业务确认该存储过程在哪个节点执行，登录该节点查看gener日志，发现报错：ORA-06575:Package or function xxxx is in an invalid state。和业务沟通，提供测试案例，开启事务测试存储过程，并监控spe日志发现存储过程在执行insert xx select 时报错，后手动执行select语句发现该语句涉及表不存在。找到原因后反馈业务侧，重建表后，存储过程调用正常。1）确保所有数据库对象（如表、存储过程等）的定义都存档在版本控制系统中不仅有助于追踪变更历史，也方便在出现问题时快速还原或重建丢失的对象。例如，在执行关键操作前进行存在性检查（如检查表或视图是否存在）。包括检查所有存储过程的状态是否有效，以及它们依赖的数据库对象是否完整。
国产操作系统欧拉安装Oracle19C碰到报错问题。PRVG-0282 : failed to retrieve the operating system distribution ID报错异常退出。cat $ORACLE_HOME/cv/admin/cvu_config找到CV_ASSUME_DISTID取消注释。root.sh执行报错ins_rdbms.mk:840。上传libpthread_nonshared.a包，修改libpthread_nonshared.a权限后，在/usr/lib64下创建过软连接了：ln -s libpthread.a libpthread_nonshared.aPlease check your installation, HotSpot does not work correctlywhen installed in the JDK 1.2 Linux Production Release, orwith any JDK 1.1.x release.Could not create the Java virtual machine.将/usr/lib64/libnsl-2.17.so 复制到目录下：cd /usr/lib64/
ln -s libnsl-2.17.so libnsl.so.1
ln -s libnsl.so.1 libnsl.so
- log里：/usr/lib64/libaio.so.1: undefined reference to `__stack_chk_fail@GLIBC_2.4'
把libaio.so.1替换为新的，注意替换libaio.so.1.0.1 ，查看软连接libaio.so.1要链接到新的so文件上。对于每一个问题和其解决方案，进行详细的文档记录，这不仅帮助未来遇到相同问题的快速解决，还有助于知识的传承。确保在修改系统文件或配置时保留原始文件的备份，以便在新的配置不起作用时可以快速回滚。在实际生产部署前，对修改后的环境进行充分的测试，确保所有的Oracle功能正常，性能符合预期。在项目初期，评估软件与操作系统之间的兼容性，包括支持的库文件、依赖的系统工具和预期的系统配置。国产操作系统默认包与红帽操作系统是不同的，安装报错多数为so包无法解析，需要从红帽操作系统把对应包拿来替换，并重新更新软连接。
查看alert日志，频繁报****Encountered error ORA-6550.****根据日志提示信息为某物化视图刷新失败，查询DBA_MVIEWS视图发现MASTER_LINK为到已下线数据库的dblink。1）深入分析物化视图的刷新策略和频率，以确定是否需要调整以避免未来的失败使用DBMS_MVIEW.EXPLAIN_MVIEW来分析物化视图的能力和限制，这有助于确定物化视图是否配置正确。确保在链接失败或物化视图刷新出现问题时能够及时通知管理员。定期检查所有数据库链接的有效性和物化视图的状态。
select xx from xx from id=? 全表扫描。原因是ID字段创建索引时，写成了xx(‘id’),导致创建索引时创建的不是单字段索引，而是成了普通函数索引。1）使用 EXPLAIN PLAN 命令来验证查询是否真正使用了索引例如，如果意图是创建单字段索引，则应确保使用正确的语法，如 CREATE INDEX idx_name ON table_name (id); 而非 xx(‘id’)。3）除了修正索引外，还可以检查查询条件本身是否有优化空间例如，确保查询条件中的数据类型与索引字段类型一致，避免隐式类型转换，这也可能导致索引失效。确保所有数据库操作，包括索引创建，都遵循最佳实践。6）定期对开发者和数据库管理员进行SQL优化和索引设计方面的培训增强开发者和数据库管理员对索引如何影响查询性能的理解。包括定期评估现有索引的效果和必要性，以及定期清理未使用或重复的索引。在进行任何大规模数据更新（如批量导入）之前和之后，检查并优化索引，确保索引的维护不会影响系统性能。
一个一个地清理回收站中的表对象，而不是通过purge dba_recyclebin命令。找到回收站为何急剧增长的原因。1）如果频繁出现ORA-01555错误，考虑增加撤销表空间的大小可以通过调整撤销表空间来提供更多的撤销记录容量，从而支持更长时间的查询和更大的事务。3）在进行大规模数据删除操作前，评估并优化撤销参数如undo_retention，以保留足够的撤销信息。定期监控撤销使用情况并根据数据库的实际运行情况调整策略。6）实施监控系统以跟踪UNDO的使用情况，及时发现潜在问题当UNDO使用接近阈值时自动通知数据库管理员，以便及时采取措施。包括定期清理回收站和不再需要的数据，以优化数据库性能并防止空间浪费。确保在不影响数据库性能的前提下进行。
某日收到数据库连接数过高的告警，业务也反应查询变慢。检查teledb相关的组件的可用性，发现多个底层库连接数过高，数据库压力大；停止业务和dbproxy后，底层库的连接数任然没有释放；查询到底层库存在大量otter用户的连接，怀疑跟同步有关系；停止所有全量同步后，启动dbproxy业务逐步恢复正常。监控Teledb数据库连接数、负载、性能等指标，并设置相应的预警阈值。当数据库连接数异常升高时，及时发出警报，以便进行调查和处理。确保其配置和同步策略符合业务需求，并不会对数据库性能产生不良影响。特别是针对全量同步操作，需要谨慎设置同步时间和频率，以避免对数据库造成过大压力。4）持续监测数据库性能和负载情况，并根据监测结果进行相应的优化和调整定期评估数据库的性能瓶颈和瓶颈原因，并采取相应的措施进行优化。新炬运维避坑指南连载合集链接：
https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzUxNTYzMjA5Mg==&action=getalbum&album_id=2846038717288693763#wechat_redirect
