点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
业务人员误清除CRM核心字典表，导致大量业务异常。1）业务反馈该表被清除后，尝试基于时间点没有历史数据，检查该表的DDL时间发现做过DDL；2）通过flashback进行闪回，发现该数据库未开启truncate闪回，无法恢复删除时间点的数据；3）业务反馈可以从其它地市库取数，通过OMS抽数过来进行恢复，2w行数据迁移10分钟未结束，检查表上存在trigger，与业务沟通停掉相关业务，关闭触发器后完成恢复。2）推动OB改进版本，开启回收站，提高误操作恢复效率。1）可视化运维平台监控到某核心系统数据库CPU异常增高，紧急介入处理抓取异常SQL，此时数据库连接数已满，抓取的SQL都比较慢，很难定位到具体SQL，与客户沟通后重启，重启proxy未能正常恢复，申请切主后仍然未能恢复；2）通过OBA抓取到两张核心业务表对应的业务SQL比较慢，绑定执行计划后仍然未能恢复，从后台检查统计信息视图发现这两张核心业务表在版本后手动收集过统计信息，删除手动收集的统计信息后CPU恢复正常，系统恢复正常。3）核心表尽量避免手工收集统计信息。
OceanBase SQL远程计划SPF变慢被放大，效率低下。1）业务上线之后遇到一条sql超时，执行效率很低，反馈过来要求优化排查。对比其他库查询该sql的执行历史，发现并不慢，对比执行计划也一样，只是远程算子位置不一样，手工将该sql涉及的表副本leader切到同一台server上；2）后续在测试环境复现分析，limit截断算子正常是流式执行，外层传参进入内层，匹配到一条数据后就会停止，继续下面的执行，但是慢的执行计划有个exchange的远程查询推入，会进行查询重写，相当于外层传参一次，b表会全表数据拿出来进行一次比对，这个过程进行160次，导致变慢被放大。1）如果有可能，对可能出现这类问题的业务整理，以使用table_group固定；2）关闭rebalance参数，对表副本进行固定，但是时间长了会造成节点负载不均衡；3）加强SQL性能监控，对少量这类执行计划进行转换优化。
1）检查执行报错的SQL语句，是个insert into ... select ... from ...left join... where ...执行计划显示存在全表扫描，检查当前temp使用率很低，手工执行语句中的select部分语句，可以执行成功，同时观察temp表空间使用率，实际该SQL占用temp 表空间46%，约40g；2）既然单独可以执行成功，temp表空间剩余还有一半多，那就说明存在其他SQL语句在这个时候占用大量temp表空间，导致insert语句不能分配到足够多的temp表空间导致执行失败；3）查找时间点前后大量占用temp的SQL语句，执行计划就有300多行，先几张表left join，然后结果再union，union后的结果再left join，总计left join高达75次，where条件过滤效果很差，部分表统计信息过期，执行次数为0，通过对相关SQL进行优化后解决。2）加强对temp表空间使用监控，运用自动化运维手段对temp占用超过一定阀值的SQL进行截断查杀；3）运用自动化手段对temp进行清理，防止部分高耗temp的语句引发其他业务影响；4）temp主要用于排序和分组，对于AP与TP混用系统，可以对AP用户单独指定临时表空间。
1）根据SQL_ID查出该SQL语句存在2个子游标，实际执行过程中使用到的复合索引对应的谓词条件过滤性较差，而另一个子游标对应的复合索引存在某列不在where条件中，因此优化器并未将其评估为最优执行计划;2）通过sqlhc报告确认到近期均采用的是谓词条件过滤性较差的执行计划，此结果也验证了研发人员反馈该语句近期响应缓慢的现象;3）查表最近统计信息数据量变化未超过10%，意味着统计信息任务不会对该表进行收集，因此该Hash Value对应的执行计划未发生变化。- 创建过滤性良好的复合索引(注意：索引列均存在于where条件)，同时对该表重新搜集统计信息，并指定no_invalidate=false将shared pool中有依赖关系的shared cursor失效，此后成功解决此异常.
1）加强对慢查询的监控，及时发现异常SQL并对其进行调优;2）增加对SQL语句执行计划突变的监控。
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
3）分析原因为：最大虚拟内存值设置过小，无法支持ES的运行；4）将vm.max_map_count 的值修改，重启ES，依旧启动失败；Memory locking requested for elasticsearch process but memory is not locked
6）查看ES配置文件elasticsearch.yml 发现 bootstrap.memory_lock: false，这个时候就需要限制住ES占用的内存情况，可选少用swap。在/etc/elasticsearch/elasticsearch.yml 开启了 bootstrap.memory_lock: false这个配置，elasticsearch官网建议生产环境需要设置bootstrap.memory_lock: true。发生系统swapping的时候ES节点的性能会非常差，也会影响节点的稳定性。所以要不惜一切代价来避免swapping。swapping会导致Java GC的周期延迟从毫秒级恶化到分钟，更严重的是会引起节点响应延迟甚至脱离集群。所以最好限制住elasticsearch占用的内存情况，可选少用swap。
BC Linux lvm 缩容后重新挂载后数据盘丢失。GDDB单机环境安装可用空间为3.6T，但实际发现数据盘总可用大小为1.9T。检查环境可知，系统采用gpt分区管理。同时发现数据库采用lvm管理。于是决定对数据盘进行lvm扩容。RAID磁盘一块盘可以创建最多4个primary分区。所以当时在划分pv时，只划分了500G。并且成功扩容VG容量到2.4T。又因为GDDB厂商建议扩容到3T。因此又进行了pv的创建。在创建过程中发现无法创建第五个主分区。因此尝试采用扩展分区进行LVM扩容。分区创建成功后，需用toggle dev/sdn lvm 进行标识。结果发现扩展分区打标成功，但是还是无法识别成lvm的pv。且尝试添加pv到VG当中失败。思考之后，决定进行lv的缩容，然后划分更大的PV。于是执行了lvreduce 命令，随后进行vg的缩容。缩容后重新创建了更大的pv，并成功标识为lvm磁盘，添加进了VG。Linux 扩容成功后需要重新挂载，于是执行resize2fs命令进行重新挂载。resize2fs命令执行失败。同时发现容量并未扩展。根据linux建议，启用partprobe命令或重启Linux生效。执行了partprobe发现没有改变，因此尝试重启主机。发现迟迟未启动。联系后台管理员，以console口接入，发现主机进入了安全模式。尝试手动挂载lv到数据目录，提示超级块损坏。查询文件系统为ext4系统，尝试使用chkfs进行修复。发现大量块损坏。决定对lv进行Remove，重新挂载。但重新挂载后数据盘丢失。linux lvm是个坑，做LVM扩容前必须做相应的预演。尽可能不要对linux下的lvm进行缩容。
mysql8.0.23，二进制日志未自动清理，设置了binlog_expire_logs_seconds的值，由于日志未自动清理，导致挂载点使用率过高报警。expire_log_days和binlog_expire_logs_seconds两个参数，binlog_expire_logs_seconds的优先级高于expire_log_days。binlog_expire_logs_seconds的值设置为604800（单位秒，即7天），expire_log_days的值为0（表示日志不自动清理）。经过检查发现，在修改过参数之后未执行flush logs使参数生效。完善变更步骤，在变更步骤中确保flush logs被执行。
某19.13数据库的SCN多次发生跳变，导致goldendb做日志集解析时间比往常增加了很多，对迁移割接产生影响。查看数据库的alert日志中 SCN变化的原因是通过dblink分布式的事务导致的，并不是本地的事务，SCN的变化的源头是另一个12.1.0.2版本数据库。1）评估当前数据库scn风险：scn上限是2的48次方减1（即281474976710655），从Oracle12.2开始，scn允许的最大值是2的63次方减1，当前19.13数据库的scn是：17839739901756，还有很大的空余，暂无风险；2）与业务沟通后，业务修改dblink密码，使得dblink不可用；业务调整逻辑，改为jdbc直连，不采用dblink方式。3）给原厂提建议，goldendb对日志解析机制需要优化。
mysql往goldendb数据库数据迁移过程遇到的2个问题：1）source表结构时，全库导入，导致goldendb数据库中存在多种存储引擎；2）导入结构时按照源库默认排序导入，但是goldendb数据库不支持，导致数据无法传入。1）MySQL5.7的版本中系统表里含除innodb以外的存储引擎，导致做部分DDL语句的时候，会报错事务中存在多种存储引擎，这种情况只能重装数据库，再此导入时，不导入MySQL系统库。2）创建表结构时用了源数据库默认的数据库排序方式：utf8_general_ci，这个排序goldendb数据库(mysql8.0)不支持，数据无法正常导致导入，就需要修改数据库的排序方式;修改时需注意，要修改数据级别的排序方式，表的排序方式，还会涉及字段上的排序方式，都需要做调整;调整的语句可以通过查询系统表来统一生成。1）谨慎创建数据库结构，尽可能多的了解mysqldump出的表结构（sql语句 ）的含义，例如，字符集、存储引擎，排序规则，甚至是注释中的内容。
