新炬运维避坑指南连载（二十-ORACLE专题）

IT那活儿 2024-12-11

336

点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！

指南1分钟速览：

数据库ORA-01000错误
数据表truncate缓慢
Redhat9.4安装oracle19c-rac集群
SQL运行超时
一体机计算节点扩容失败
批量任务执行缓慢
Oracle数据库国产操作系统业务积压
坏块导致备份失败
gi安装互信步骤无法通过
OGG空间告警，数据trail文件无法自动删除
OGG复制进程延迟很高

一

数据库ORA-01000错误

1.1 现象

某业务数据库ORA-01000 错误，查得为open_cursors设定问题。

1.2 处置过程

查得数据库当前游标参数，目前查出来是300，确实有点小，尝试修改到1000，依然报错，业务研发提出要修改到2000，实则修改这么大是不合理的。

再次修改到2000，业务测试依然报错，查询v$open_cursor确认语句，反馈业务查找代码，业务最终查得原因为应用程序打开了游标，却没有在它完成工作后没有及时关闭。

1.3 新炬建议

1）深入理解错误本质

ORA-01000错误的直接原因
此错误通常指示数据库中的open_cursors参数设置不足以满足当前会话的游标需求。然而，这仅仅是表象，背后可能隐藏着更深层次的问题。
分析参数调整的效果
在初次尝试将open_cursors从300增加到1000后，问题未解决，这提示我们单纯增加参数值可能不是解决问题的根本方法。

2）合理评估和调整参数

参数调整的合理性
当业务研发提出将open_cursors增加到2000时，应谨慎评估这一需求的合理性。过高的参数值不仅可能掩盖潜在的程序问题，还可能带来不必要的资源消耗和性能影响。
逐步测试与反馈
在调整参数后，应通过实际业务测试来验证效果，并密切关注数据库的性能和资源使用情况。

3）优化业务逻辑和代码

代码审查与优化
业务团队应仔细审查应用程序中与数据库交互的代码，特别是游标的使用情况。确保每个打开的游标在完成其工作后都能被及时关闭，避免资源泄露。
资源管理策略
在应用程序中实施有效的资源管理策略，如使用连接池管理数据库连接和游标，以减少资源消耗和提高性能。

二

数据表truncate缓慢

2.1 现象

业务侧反馈只有几百行的表在truncate时较慢。

2.2 处置过程

业务在truncate表时反映较慢，但表数据量很小，核实表行数确实很少，但在truncate时较慢，等再次truncate时观察等待事件，发现IO类等待事件较高。

查找相关资料，可能盘存在坏块，或者初始值大。

核查原因1不可能，查表的ddl，表初始值很大。与业务沟通，业务也不清楚为啥这个表初始值这么大。

重建表，使用默认初始值后，等有业务数据，需要truncate时核查执行时间，执行时间恢复正常。

2.3 新炬建议

1）规范的DDL操作至关重要

本案例的核心问题在于表的初始设置（如初始存储参数）不当，这直接导致了即便是在数据量很小的情况下，TRUNCATE操作也会因为需要处理大量的未使用空间而变慢。

这强调了在进行数据库设计和表创建时，必须遵循规范的DDL操作，合理设置表的各项参数，避免因为不恰当的初始设置而引发后续的性能问题。

2）定期审查和优化数据库结构

数据库的结构和参数设置会随着业务的发展而逐渐变得不合理，因此定期审查和优化数据库结构是非常必要的。

通过定期审查，可以发现并解决潜在的性能问题，优化表结构和参数设置，提高数据库的整体性能和稳定性。在本案例中，如果定期进行了数据库结构的审查和优化，或许就能更早地发现并解决表初始值过大的问题。

三

redhat9.4安装oracle19c-rac集群

3.1 现象

从官方下载的数据库安装包是19.3版本，不支持redhat9.4.故需要在安装集群前需要做升级操作。

3.2 处置过程

1）grid镜像升级

解压grid19.3 安装包后，需要将19.23版本的grid的psu,dbru,ojvm做升级操作。

./gridSetup.sh -applyRU ./Patch/36233126 -applyOneOffs ./Dbru/36233263,./Ojvm/36199232

2）升级完成后正常安装grid

3）创建磁盘组

4）oracle镜像升级

解压oracle19.3安装包，需要将19.23版本的oracle的psu和mlr做版本升级。

./runInstaller -applyRU ./Patch/35037840 -applyOneOffs ./MLR/35859251

5）安装db和dbca建库

3.3 新炬建议

1）预先规划与系统兼容性检查

确认软件版本兼容性
在安装之前，必须详细检查Oracle官方文档或MOS（Metalink Online Support，现更名为My Oracle Support）上的兼容性矩阵，确保Oracle 19c RAC支持Redhat9.4。在本案例中，虽然Oracle 19c本身不支持直接安装在Redhat9.4上，但通过升级补丁包可以实现兼容性。
规划升级路径
由于Oracle 19.3安装包最初不支持Redhat9.4，我们需要明确升级的具体步骤和所需的补丁包。这包括Grid Infrastructure和Oracle Database的PSU（Patch Set Update）、DBRU（Database Rollup Patch）和MLR（Media Life Rollup）等补丁。

2）补丁与升级管理

下载并验证补丁包
从Oracle官方网站或MOS下载所需的补丁包，并验证其完整性和适用性。确保下载的补丁包与当前安装的Oracle版本和操作系统版本完全兼容。
执行补丁升级
按照Oracle官方文档或MOS文章（如本案例中的MOS参考文章2982833.1）的指示，正确执行补丁升级。在升级过程中，应密切关注任何错误消息或警告，并及时解决。
测试验证
在升级完成后，进行全面的测试验证，以确保Grid Infrastructure和Oracle Database的性能和稳定性未受影响。

3）集群配置与部署

创建磁盘组
在Grid Infrastructure安装完成后，根据实际需求创建磁盘组。这包括规划磁盘组的名称、大小、冗余级别等参数。
安装Oracle Database
使用升级后的Oracle安装包执行数据库安装。在安装过程中，注意选择正确的安装选项和配置参数。
数据库创建与配置
使用DBCA（Database Configuration Assistant）创建数据库，并根据业务需求进行必要的配置。

四

SQL运行超时问题

4.1 现象

业务侧反馈SQL运行超时。

4.2 处置过程

1）查看等待会话及等待事件

发现用户SQL均为并行插入,属于OLAP应用。同时发现有大量” log file switch checkpoint incomplete”事件。

解决办法：

可以通过增大日志大小来减少日志切换频率来缓解。

2）进一步观察

发现有大量”direct path read temp“, ” direct path write temp“等待。

解决办法：

将临时表建立在不同于数据表所在的磁盘组，分布IO到不同的磁盘，优化IO性能。

3）数据库节点4重启后异常停止

分析：是由于BUG导致，需打上相应补丁。

4.3 新炬建议

1）优化日志管理

增大REDO LOG的容量
在处理SQL运行超时的问题时，发现大量“log file switch checkpoint incomplete”事件是导致性能瓶颈的重要因素。这表明当前REDO LOG的容量不足以应对高频率的日志切换。通过增大REDO LOG的容量，可以有效减少日志切换的频率，从而避免因此类等待事件导致的性能下降。此外，合理配置REDO LOG组的大小和数量，可以进一步提高数据库的健壮性和恢复能力。
监控与调优
除了增大REDO LOG容量外，还需要定期对日志切换的频率和性能进行监控，以确保系统稳定运行。同时，根据业务负载的变化，适时调整REDO LOG的配置，以应对可能的性能挑战。

2）优化存储架构

临时表空间与数据表空间的分离
在处理过程中，观察到大量“direct path read temp”和“direct path write temp”等待事件，这通常是由于临时表空间与数据表空间共享同一磁盘资源导致的IO争用。通过将临时表空间建立在不同于数据表空间的磁盘组上，可以有效分散IO负载，提高数据库的整体性能。此外，合理的磁盘布局和配置也是确保数据库高效运行的关键因素。
存储资源评估与规划
在进行数据库设计时，应充分考虑存储资源的评估与规划。根据业务需求和性能要求，合理规划数据表空间、临时表空间、REDO LOG等关键存储组件的布局和配置，以确保系统的高性能和可扩展性。

3）及时更新与补丁管理

及时更新数据库补丁
在处理过程中，发现数据库节点重启后异常停止是由于BUG导致的。这再次强调了及时更新数据库补丁的重要性。数据库厂商会定期发布补丁来修复已知的安全漏洞和性能问题，因此，及时关注并应用这些补丁是确保数据库安全稳定运行的关键措施。
补丁管理流程
建立完善的补丁管理流程，包括补丁的收集、测试、审批和部署等环节。在部署补丁前，应进行充分的测试以确保补丁的兼容性和稳定性。同时，保持与数据库厂商的密切沟通，及时了解最新的补丁信息和安全漏洞情况。

五

一体机计算节点扩容失败

5.1 现象

一体机计算节点扩容失败。

5.2 处置过程

新增节点前期环境配置（交换机端口、域名解析、用户属组、互信等）；
检查数据库备份；
拷贝GI软件；
添加新增节点；
创建三个节点实例；
启动实例验证节点添加是否正常。

问题发现：

添加了三次都是异常终止，没有明显报错，之后一次添加一个节点创建成功两个节点，第三个节点不能加入；提SR后回复是19.5版本的RAC最多支持添加10个节点。
因为我们扩容之前是8个节点，前两次尝试是一次性添加三个节点，共11个节点，所以报错。如果需要扩容计算节点至10个节点以上，需要升级至19.20以上。

5.3 新炬建议

1）深入了解版本限制与兼容性

在进行任何系统扩容或升级之前，深入理解当前系统版本的功能限制和兼容性至关重要。

本案例中，由于未充分了解Oracle RAC 19.5版本的节点数限制（最多支持10个节点），导致在尝试一次性扩容超过限制时遭遇失败。

这一教训提醒我们，在规划系统扩容时，必须仔细查阅官方文档或咨询技术支持（如SR），以明确版本限制和可能的兼容性问题。

2）逐步验证与分阶段实施

扩容过程中，采用逐步验证和分阶段实施的方法可以显著降低风险。

在本案例中，如果在一开始只尝试添加一个节点进行验证，而不是一次性添加多个节点，可能更早地发现问题所在，从而避免不必要的资源浪费和时间延误。

逐步验证不仅有助于及时发现问题，还能为后续的扩容操作提供宝贵的参考经验。

3）备份与恢复计划的完善

在扩容或升级之前，完善的数据备份和恢复计划是不可或缺的。

本案例中，虽然提到了检查数据库备份，但并未详细说明备份的完整性和恢复测试的细节。在实际操作中，应确保备份数据的完整性和可恢复性，以便在扩容失败或发生意外情况时能够迅速恢复系统。

此外，制定详细的恢复计划和应急预案也是保障系统稳定性的重要措施。

4）版本升级与长期规划

针对版本限制导致的扩容问题，长期来看，版本升级是不可避免的选择。

在制定扩容计划时，应综合考虑当前系统的稳定性、业务需求以及未来发展趋势，制定合适的版本升级策略。

同时，也需要关注新版本的功能特性、性能改进以及潜在的兼容性问题，确保升级过程的顺利进行和升级后的系统稳定运行。

六

批量任务执行缓慢

6.1 现象

业务反馈某批量任务近期相比之前延迟结束，需DBA分析根本原因，并给出解决方案。

6.2 处置过程

收集统计信息，详细步骤如下：

检查之前SQL的索引使用情况；
检查当前活动连接；
收集统计信息；
收集信息过程中，检查活动连接；
执行测试SQL；
观察新的索引使用情况；
重新收集统计信息后，问题成功解决。

6.3 新炬建议

1）深入理解索引优化与选择

在处理类似批量任务延迟结束的问题时，首要关注的是SQL查询的效率。索引作为数据库优化查询速度的关键工具，其选择和使用直接决定了查询的性能。

当表拥有多个索引时，数据库优化器会根据统计信息和查询条件来选择最合适的索引。然而，如果统计信息过时或索引设计不合理，优化器可能会选择低效的索引，导致查询性能下降。

因此，DBA需要定期审查索引的使用情况，确保优化器能够基于最新的统计信息作出正确的索引选择。同时，对于复杂的查询，可以通过手动指定索引或调整查询逻辑来优化性能。

2）关注执行计划的稳定性和一致性

执行计划是数据库执行SQL语句的具体步骤，其稳定性和一致性对于保证查询性能至关重要。

在某些情况下，由于统计信息的变更、表数据的增减或查询条件的变化，执行计划可能会突然发生变化，导致查询性能急剧下降。

因此，DBA需要密切关注执行计划的变化，并在发现性能问题时及时进行分析和调整。在查看各子游标执行计划时，不仅要关注评估值，还要关注实际返回值与评估值之间的差异，以判断执行计划是否合理。

此外，对于频繁变化的查询，可以考虑使用查询计划绑定等技术来固定最优的执行计划。

3）利用执行计划绑定优化性能

当SQL语句存在多个可能的执行计划时，数据库优化器会根据统计信息和查询条件动态选择最优的执行计划。

然而，在某些情况下，由于统计信息的误差或查询条件的特殊性，优化器可能无法总是选择最优的执行计划。

此时，DBA可以通过执行计划绑定技术来手动指定最优的执行计划，以确保查询性能的稳定性和一致性。执行计划绑定不仅可以解决性能波动问题，还可以提高查询的响应速度和吞吐量。

4）定期维护统计信息的准确性

统计信息是数据库优化器进行决策的重要依据，其准确性直接影响到查询性能。如果统计信息过时或不准确，优化器可能会选择低效的索引或执行计划，导致查询性能下降。

因此，DBA需要定期维护和更新统计信息，以确保其能够准确反映表数据的实际情况。在进行批量数据更新、删除或新增操作后，应及时重新收集统计信息，以便优化器能够基于最新的数据分布和特征进行决策。

此外，对于频繁变化的表或查询，可以考虑设置自动更新统计信息的策略，以减少人工干预的成本和风险。

七

Oracle数据库国产操作系统业务积压

7.1 现象

Oracle数据库国产操作系统替换影响到了客户内存库的数据传输，导致业务积压。

7.2 处置过程

7.2.1 oracle软件安装完毕，做dg同步，同一时间可能会有很多库进行，会占用大量网络带库，影响其他数据库的数据传输

本次案例就是影响到了客户内存库的数据传输，导致业务积压。

提前协调网络侧对要进行的dg源端和目标端同步主机进行限速；
在dg duplicate同步脚本的通道上使用rate 100m参数也进行限速；
尽量把duplicate同步脚本放到晚上业务低峰期跑。

7.2.2 补丁问题

1）Opatch工具如果升级的版本太高会报错

比如11G的数据库软件，Opatch升级到12.2.0.1.23以后：

opatch version
./opatch: line 839: [: too many arguments
./opatch: line 839: [: too many arguments
Java (1.7) could not be located. OPatch cannot proceed!
OPatch returns with error code = 1

解决方法：

将Opatch 的jre删除，将oracle_home下的jdk/jre拷贝到Opatch目录下。

rm -rf OPatch/jre
cp -r $ORACLE_HOME/jdk/jre OPatch/

2）18C 19C的数据库在更打补丁时会提示互信问题，但是反复验证互信又没问题

--执行这条命令会提示没有权限，看上去是互信问题
cluvfy comp admprv -n hn103f0601rs1,hn103f0602rs1 -o user_equiv -sshonly -verbose
--执行这条命令会提示PRVG-0282报错
cluvfy stage -pre crsinst -n hn103f0601rs1,hn103f0602rs1
找到/oracle目录下所有的cvu_config文件，确认是否都去掉了oel5的注释#
Find oracle -name cvu_config
#CV_ASSUME_DISTID=OEL5
把这行的注释#去掉，修改后
CV_ASSUME_DISTID=OEL5

然后重新验证互信关系，通过后继续打补丁。

3）/tmp权限问题导致打补丁提示OPATCHAUTO-72035报错

检查/tmp目录是777权限看上去没有问题，但是打补丁依然报错，可以尝试重新赋权chmod 777 tmp。

7.3 新炬建议

1）网络带宽管理与数据同步优化

提前规划与协调
在进行大规模的数据库DG同步时，必须提前与网络团队协调，确保有足够的带宽资源。同时，制定详细的网络使用计划，避免高峰时段进行高带宽消耗的操作。
限速措施
在DG同步脚本中采用限速参数（如rate 100m），以减少对网络的冲击。此外，还可以考虑使用网络设备的QoS功能来进一步管理带宽。
时间管理
将高带宽消耗的操作安排在业务低峰期进行，以减少对正常业务的影响。这要求项目团队具备高度的灵活性和时间管理能力。

2）补丁更新与版本兼容性

严格版本控制
在升级Opatch或其他关键工具时，必须严格控制版本兼容性。对于旧版本的数据库软件，避免升级到过高版本的Opatch，以免出现兼容性问题。
环境一致性
确保所有数据库节点的环境配置一致，包括JDK/JRE版本、环境变量等。这有助于减少因环境差异导致的补丁安装问题。
详细日志与错误排查
在补丁安装过程中，开启详细日志记录功能，以便在出现问题时进行快速排查。同时，对于常见的错误代码和提示信息，应提前准备相应的解决方案。

3）互信验证与权限管理

深入排查互信问题
当遇到看似互信问题但实际上互信验证通过的情况时，应深入排查系统配置和权限设置。特别是针对新版本的数据库软件，可能存在未知的兼容性问题或配置要求。
修改配置文件
在某些情况下，修改系统配置文件（如cvu_config）以匹配特定的环境要求可能是必要的。然而，在修改前务必备份原始文件，并确保了解修改的影响。
权限管理
确保所有关键目录（如/tmp）具有正确的权限设置。尽管某些目录看似权限无误，但在特定操作或软件版本下仍可能出现问题。因此，在出现问题时应重新检查并调整权限设置。

八

坏块导致备份失败

8.1 现象

oracle数据库有坏块导致备份失败。

8.2 处置过程

备份日志报错：

rman-03009 ora-19566:exceeded limit of 0 corrupt blocks for file ....

通过v$database_block_corruption和dba_extents系统表查看到坏块所在对象是一个索引，夜间数据库负载低峰期进行重建索引规避。

但是在备份时发现，坏块上没有数据库对象，依然备份报错，影响备份。

--通过添加参数允许在备份中包含1个损坏的快，参考文档Doc ID 1900424.1
set maxcorrupt for datafile 229 to 1;
--重新格式化不属于任何对象的坏块，参考文档Doc ID 336133.1
这个操作起来步骤就比较多了，主要过程是新建一个对象，把这个损坏的块分给这个新对象以让这个逻辑坏块重新被格式化。

8.3 新炬建议

1）及时识别与定位问题

当备份日志中出现如rman-03009 ora-19566的错误时，应立即意识到可能存在数据块损坏的问题。通过查询v$database_block_corruption和dba_extents等系统表，能够迅速定位到具体的损坏对象和数据文件。

2）灵活应对不同情况

对于非关键或即将替换/下线的数据库，重建受影响的索引可能是一个快速且有效的解决方案。这种方法简单直接，能够快速恢复备份功能，但需注意对业务的影响和数据的完整性。

对于重要生产库，则应采取更为谨慎和全面的处理措施。在发现坏块不属于任何现有对象时，直接重建索引可能无法解决问题。此时，需要深入考虑如何安全地处理这些孤立的坏块，以避免对生产环境造成更大的影响。

3）利用Oracle高级功能

通过设置maxcorrupt参数允许在备份中包含一定数量的损坏块，是一种灵活的解决方案。这可以在不中断备份流程的情况下，暂时绕过坏块问题。然而，这种方法只是权宜之计，不能作为长期解决方案。

重建逻辑上不属于任何对象的坏块需要更复杂的操作，如新建一个对象并将损坏的块分配给该对象以重新格式化。这种方法虽然复杂，但能够彻底解决问题，并保证数据的完整性和一致性。

4）加强备份与恢复策略

此次事件再次强调了定期备份和验证备份完整性的重要性。只有确保备份的可靠性，才能在数据丢失或损坏时迅速恢复。

考虑引入更高级的数据保护技术，如数据镜像、快照或云备份等，以提高数据的安全性和可用性。

九

gi安装互信步骤无法通过

9.1 现象

gi安装互信步骤无法通过。

9.2 处置过程

环境：redhat 6.5 安装12c 12.1.0.2 gi

1）使用的可视化界面安装的gi,在互信时报错

PRVF-4008 :User equivalence unavailable on all the specified nodCause: User equivalence doesn't
PRVF-4098:User equivalence not found for node ""xxxxxxxx""

2）检查互信ssh hostname date 可返回

$ ssh ***1 date
Warning: Permanently added 'xxxxxxxx' (ECDSA) to the list of known hosts.
Thu Aug 8 17:44:46 CST 2024

3）重新互信依然报错,runcluvfy.sh预安装检查

PRVG-2019 : Check for equivalence of user ""grid"" from node ""xxxxxxx1"" to node ""xxxxxxxx2"" failed
PRKC-1044 : Failed to check remote command execution setup for node xxxxxxxx2 using shells /usr/bin/ssh and /usr/bin/rsh
xxxxxxxxx: Connection refused

怀疑是ssh返回值包含warning提示造成误检测。

4）修改/etc/ssh/ssh_config

注释掉StrictHostKeyChecking no 默认级别是ask，选择no时，如果公钥检查不通过则会有警告信息。

UserKnownHostsFile /dev/null 指定一个或多个用户认证主机缓存公钥文件，注释后默认为~/.ssh/known_hosts。

5）执行以下再次验证互信通过

su – grid
ssh ***db1 date
ssh ***db1-priv date
ssh ***db2 date
ssh ***db2-priv

9.3 新炬建议

1）确认SSH配置与主机公钥管理策略

在进行多节点互信配置时，确保SSH配置文件中的选项（如StrictHostKeyChecking和UserKnownHostsFile）设置正确是至关重要的。

特别是在首次配置时，可能会遇到SSH公钥检查不通过的问题，从而影响互信过程。将StrictHostKeyChecking设置为no或确保UserKnownHostsFile指向正确的用户公钥缓存文件，可以避免因公钥校验失败导致的配置错误。

2）处理SSH警告信息影响配置检测

SSH警告信息（如公钥更改警告）可能会影响互信检测工具的正常工作。要注意检查SSH返回的警告信息是否干扰了系统的互信检测流程。

在处理这种问题时，首先确认SSH配置和主机公钥是否正常，然后验证互信配置的正确性，以确保警告信息不会对最终的互信结果产生负面影响。

3）测试和验证SSH连接的实际情况

在执行安装或配置步骤前，单独测试SSH连接（如通过ssh user@hostname date命令）可以帮助确认SSH连接是否正常工作，并排除潜在的连接问题。确保能够在所有相关节点之间无障碍地执行SSH命令，是成功完成互信配置的基础。

4）使用合适的工具进行互信检测

在进行系统配置检查时，工具如runcluvfy.sh提供了详细的错误信息，可以帮助定位问题。在遇到互信失败时，利用这些工具进行预检查和排查是非常有效的。

根据工具提供的错误信息，采取相应的解决步骤，如修复SSH配置或调整权限设置，可以有效解决互信问题。

5）关注并解决网络和安全配置带来的影响

网络配置或安全加固设置（如防火墙、SELinux、SSH配置等）可能会影响节点之间的互信配置。务必检查网络配置是否允许所需的通信协议和端口，以及安全加固设置是否会阻止必要的网络操作。通过系统日志和网络配置检查，确保所有相关设置不会干扰正常的互信过程。

十

ogg空间告警，数据trail文件无法自动删除

10.1 现象

ogg空间告警，设置保留策略，数据trail文件也无法自动删除。

10.2 处置过程

ogg安装在主机目录/back_data空间使用率高，发现其中/back_data/ogg/dirdat数据文件目录占用达1.8T，其中最早是到2024年1月份，查看数据文件ep对应的进程ext-p，序列号已经到ep028742，目录下最早的是ep026914，管理进程mgr配置的清理策略是保留3天。

从日志来看确实有清理动作，但是清理的日志文件序列号26913很小，无法满足空间要求，同时看到pum-p进程这是投递进程的日志切换序列号是26914，因为清理使用usecheckpoints参数，也就是确保所有进程对该文件没有访问，持续往后推进，这里不免怀疑管理进程把本地trail文件序列号与远程trail文件序列号当成一样对待，都要确保序列号不再使用，这里可能也是bug，没搜到相关补丁或修复说明。

使用修改目标端trail文件的方式，让ep在目标端的序列号进行追赶，以加快源端trail文件的删除，一天追50~70个文件，大约是50G~70G。

stop pum-p

10.3 新炬建议

1）源端与目标端Trail文件的明确区分

在GoldenGate（OGG）的部署中，源端（Extract进程）和目标端（Replicat或Pump进程）的Trail文件虽然功能相似，但在管理和维护上应被视为两个独立的系统部分。

从本案例中可以看出，由于Trail文件的命名或管理策略未明确区分源端和目标端，导致管理进程（mgr）在处理清理策略时可能出现了混淆，错误地将源端和目标端的Trail文件序列号视为同一套系统内的文件，从而影响了清理策略的有效性。

改进措施：

命名规范
确保源端和目标端的Trail文件在命名上有明显的区分，例如通过前缀或后缀来区分，以便管理进程能够准确识别并处理。
配置明确
在GoldenGate的配置文件中，明确指定源端和目标端Trail文件的存储路径和命名规则，避免混淆。

2）细致分析日志，发现潜在问题

日志是系统行为的重要记录，通过细致分析日志，可以发现许多隐藏的问题和线索。

在本案例中，通过查看GoldenGate的日志文件，发现了管理进程（mgr）在清理Trail文件时存在的问题，即清理的日志文件序列号远低于实际需求，这直接导致了空间告警的问题。

改进措施：

定期审查日志
建立定期审查GoldenGate日志的机制，特别是关注与清理策略、文件切换等相关的日志信息。
增强日志记录
如果当前日志记录不够详细，可以考虑调整GoldenGate的配置，增加相关日志记录的详细程度，以便更好地跟踪问题。

3）理解并使用好usecheckpoints参数

usecheckpoints参数是GoldenGate中一个重要的配置选项，它决定了管理进程在清理Trail文件时是否依赖于检查点信息。

在本案例中，由于usecheckpoints参数的使用，管理进程在清理文件时过于保守，导致大量不再需要的Trail文件被保留。

十一

OGG复制进程延迟很高

11.1 现象

复制进程严重延时，超过10小时，Time Since Checkpoint 过高，通过info看到是在不断变化，trail文件存在丢失的情况。

11.2 处置过程

排查原因：

通过查看当前会话，发现存在慢SQL，根据SQL信息发现缺少统计信息，大表数据结构和数据是分开导入的，索引创建后，没有正常刷入统计信息。

调整：

调大的trail文件保留时间。
查询延迟时段的慢SQL，优化慢SQL，主要是调整统计信息。
夜间业务较多，将原来的复制进程拆成多个进程。

11.3 新炬建议

1）合理设置Trail文件保留时间

根据业务的实际数据量和复制进程的负载，设置合适的Trail文件保留时间可以有效防止数据丢失。Trail文件保留时间过短可能导致数据丢失或复制进程延迟，而设置过长则可能占用过多的存储资源。通过合理配置Trail文件保留时间，可以确保在出现延迟或丢失的情况下，有足够的历史数据用于恢复和处理。

2）优化慢SQL查询

定期监控和优化数据库中的慢SQL查询是确保数据复制顺畅的关键。慢SQL通常会占用过多的资源，导致复制进程延迟。通过分析和优化这些查询（如调整索引、更新统计信息），可以显著提高数据库性能，并减少对复制进程的影响。

3）更新和维护统计信息

数据库的统计信息是查询优化的基础。如果统计信息不准确或过时，会导致SQL查询性能下降。定期更新统计信息，尤其是在数据结构和数据发生变更后，是确保数据库性能的关键步骤。这包括在创建索引后立即刷新统计信息，以确保优化器能够利用最新的数据分布信息。

4）拆分复制进程以应对高负载

在高业务负载情况下，拆分复制进程可以有效减轻单个进程的负担，减少延迟。例如，可以将大表的复制任务分配给多个进程处理，这样不仅可以提高复制效率，还可以提高系统的整体稳定性。合理规划复制进程的拆分，可以减少由于单个进程负载过重导致的性能瓶颈。

5）监控和调整复制进程配置

监控复制进程的性能指标（如延迟、Time Since Checkpoint等）并根据实际情况进行调整是至关重要的。定期检查复制进程的状态，及时调整相关配置（如Trail文件保留时间、进程数量等），可以有效避免由于配置不当导致的性能问题。使用监控工具及时发现并解决问题，有助于保持数据复制过程的稳定和高效。