点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
9. table or view ‘’does not exist报错处理
告警：OB500租户的占用内存大小超限，占用内存 100.08 GB。前期观察，后期进行重启observer进程，释放内存。Ocean Base 3.2.3集群长时间不重启（超过200天），日志中没有“weak read service task statistics”信息，正常是几秒一刷新，这个是因为 tsc 时钟回退引起，属于已知bug（ tsc时钟回退会影响面比较广，可能会引发其他各种问题，包括500租户内存不释放/OMS stroe链路突然不动），建议重启集群或者升级3.2.3 bp9以后版本，目前为3.2.3 bp5版本。定期重启可以作为临时措施，以防止系统长时间运行后出现性能降低或资源泄漏。“weak read service task statistics”日志缺失表明了后台服务可能存在异常。定期检查此类关键日志信息，确保系统正常运行。建立和优化资源使用的监控，特别是内存和CPU使用情况。使用如Prometheus等工具，可以帮助您更好地理解资源使用模式和及时发现问题。实施动态资源管理机制，根据负载和资源使用情况自动调整资源分配，以优化性能和资源利用率。使用OceanBase提供的诊断工具来分析和确定性能瓶颈或配置问题，如OBAdmin、OCP等。确保集群中所有节点的系统时间严格同步，防止由时间偏差引起的问题。
业务进行ddl后，马上dml报错。SQL执行错误，当前SQL：insert into xxx select * from xxx
Java.sql.SQLTransientConnectionException:(conn=2958368) ORA-00600：internal error code，arguments：
-4029(获取 Schema 失败)，Schema error
业务进行重跑即可，建议业务DDL和DML同一对象时，中间间隔最少秒级别时间，等待数据库进行DDL状态同步。业务在进行DDL操作后，可以设定一个固定的延时（如几秒），以确保Schema的异步刷新能够完成。这个延时的长度可以根据实际的系统性能和观察来调整。升级数据库版本至4.x版本，新版本可能改善了Schema刷新机制。升级前，需要详细评估新版本的特性，以及与现有系统的兼容性。在应用层增加错误捕捉和自动重试的逻辑，特别是针对诸如Schema获取失败这类可预见的错误。这可以通过编程在捕获到特定错误后，延迟一段时间后重试。通过增强对数据库操作的监控，尤其是DDL和DML操作的监控，可以更好地理解Schema刷新的实时状态和性能影响。确保所有相关操作都有详细的日志记录，方便出现问题时快速定位和分析。在数据库管理层面，探索是否有可能配置或优化Schema管理和刷新策略，减少由于Schema版本不一致导致的问题。
导入csv数据报错 Error: ORA-01400: cannot insert Nul into 'ACTION ID业务中空值字段使有用字符串"null"表示，也有用空值表示，odc导入字符串是当成了空值，字段不允许空值，故报错。修改导出内容null > \N即可，\N表示为空值，"null"即可正常按照字符串导入。在导出CSV文件之前，确保所有字段的数据格式标准化，对于空值的表示使用一致的方式（如使用\N表示空值）。这可以通过编写脚本或使用数据转换工具来实现。在导入数据之前，运行自动化脚本检查数据完整性，确保所有必填字段非空，以及数据格式符合数据库要求。确保在数据导入过程中有详细的日志记录，记录哪些数据行失败以及失败的原因。这有助于后续的错误分析和数据修正。在导入过程中设置容错级别，允许一定数量的错误发生而不中断整个导入过程，同时记录这些错误以便后续处理。
补丁更新时提示/tmp空间不足，导致补丁更新失败，不能继续。实施磁盘空间监控，特别是对 tmp 和其他关键文件系统的监控。可以使用如 df 和 du 命令的脚本自动化监控，或者使用更高级的监控工具，如 Nagios、Zabbix等。配置自动清理机制，定期清理 tmp 目录中的旧文件和临时文件。可以通过cron作业来实现，例如每天运行一次清理脚本。在执行补丁更新之前，进行预检查，包括检查磁盘空间、系统兼容性和备份完整性。这可以通过更新脚本中的预检步骤来实现。
OMS配置了反向增量的用户后，迁移速度变慢，由几百MB每秒降至几十KB每秒。版本4.1.0的OMS，配置了oms_drc用户后，迁移链路会自动设置sink.enablePartitionBucket参数为true。对于分区数特别多的表，就会迁移特别慢。确保团队成员对OMS及其相关配置参数有充分的理解。这包括了解每个参数的作用、适用场景和潜在的副作用。任何配置变更都应该经过充分测试，并且有明确的文档记录，以便在出现问题时可以追溯和回滚。- 设置系统性能监控，特别是在执行数据迁移和同步任务时。
- 监控关键指标，如数据传输速率、CPU和内存使用情况。
定期评估数据迁移策略的有效性，尤其是在数据库架构或数据量发生变化时。对于具有大量分区的表，考虑使用专门的迁移策略。例如，可以分批迁移分区，或调整并行处理分区的策略。
使用业务提供的匿名块进行问题复现，确定问题可以复现：begin
insert into tab1 select * from tab2;
commit;
end;
/
摘取未生效的事务，替换insert表tab1问题未复现，替换select表tab2问题复现。取消匿名块手动执行提交，问题复现。事务未提交时可以查到此行数据，提交后立即查询数据不存在。设置set ob_enable_trace_log=1收集sql详细trace信息，提交后未发现异常。怀疑有程序后台删数据？通过gv$sql_audit定位目标表相关事务sql，事务提交后发现存在一条delete删除操作：delete from tab1 where rowid ='xxxxxxx';
启用SQL审计功能，对所有对敏感表（如tab1）的操作进行记录，包括INSERT、UPDATE和DELETE等操作，以追踪数据变动的来源。考虑在关键表上设置触发器，记录所有修改操作的详细信息，包括操作类型、操作时间、操作者和数据变更前后的状态。在执行关键事务操作时，增加逻辑判断和错误处理，确保每个事务都能正确提交或在遇到错误时提供明确的回滚。确保所有后台任务和业务逻辑都有清晰的文档说明和逻辑定义，避免非预期的数据操作影响主要业务流程。对数据库中的关键数据进行定期的一致性和完整性检查，及时发现和解决数据问题。
一备集群被其他OCP接管并解耦为主集群，原OCP无法管控进行迁出失败。delete from ob_server where cluster id = ?
delete from ob_zone where cluster_id = ?
delete from ob_tenant where cluster_id = ?
delete from ob_cluster where id = ?
确保所有集群的状态和归属都被实时监控并记录，这有助于在类似情况下快速了解集群的当前管理状态。制定明确的集群管理策略，包括集群如何被接管、迁移和解耦的标准操作流程。为集群的迁入、迁出和接管等操作制定标准化流程，并确保所有操作均按此流程执行。开发自动化工具来处理集群的迁移和解耦操作，减少直接操作数据库的需要，降低人为错误。
修改参数precheck.skippable_flags = {"DB_DATA_TYPE":true}忽略类型检测。通过dbcat导出表元数据，替换rowid类型为varchar2(18)，将DDL语句在目标租户执行创建表结构。OMS迁移需添加四个伪劣及UK唯一索引（此部分需手动添加）。通过OMS配置全量及增量同步即可。在迁移前彻底测试和验证数据类型映射的准确性，确保 ROWID 转换为 VARCHAR2(18) 后，所有数据都能正确表示且不会引起数据丢失或错误。迁移完成后进行数据验证和审计，比较源数据库和目标数据库中的数据，确保迁移过程中数据的完整性和一致性没有受到影响。对于涉及修改数据类型和添加索引的操作，考虑开发自动化脚本来处理，以减少人工操作的需要，降低错误发生的风险。编写详细的迁移操作文档，包括每一步的操作指南、预期效果以及可能遇到的问题和解决策略。在迁移过程中实施实时监控，及时捕捉可能出现的问题和异常。
table or view ‘’does not exist报错
提示table or view ‘’does not exist。排查业务日志中排查关于该表的操作记录，该表属于建表后再删除的逻辑。发现该表在当日业务进行查询前有一条相对异常的删除记录，协调业务侧排查自身程序。确保数据库有完整的审计功能，记录所有DDL操作（如CREATE, DROP, ALTER等）。这不仅可以帮助追踪问题发生的原因，还可以预防未授权或错误的操作。定期审查谁有权限对重要表执行DDL操作，并确保这些权限严格按照最小权限原则分配。在应用层面，改进错误处理逻辑，当尝试访问不存在的表或视图时，提供更详细的用户通知和建议的操作步骤。对用户进行教育，让他们了解尝试访问不存在对象的潜在后果，并教授如何验证对象状态或谁可以联系以解决此类问题。在数据库管理系统中设置监控和警报，以便在发生重要的DDL操作（如表的删除）时能够及时通知数据库管理员或业务团队。
查询sql连接，发现其中一条查询sql占用900+个活跃连接。排查该sql查询慢的原因，发现查询的表没有索引，所以触发了900+次全表扫描，从而导致业务查询过程中cpu攀升。对于被频繁查询的列添加适当的索引，尤其是查询条件中涉及的列。确保索引策略与查询模式相匹配，以最大限度减少全表扫描。分析并重写效率低下的SQL查询，使用更高效的查询逻辑和结构。例如，避免不必要的子查询，使用更有效的连接（JOIN）类型等。使用数据库性能监控工具，实时监控数据库活动和资源使用情况。通过配置数据库的资源管理器，为不同的用户和会话设置CPU和内存使用限制，防止单一进程占用过多资源影响整个系统。新炬运维避坑指南连载合集链接：
https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzUxNTYzMjA5Mg==&action=getalbum&album_id=2846038717288693763#wechat_redirect
