Oracle实时数据抽取项目问题总结

Oracle实时数据抽取项目问题总结

项目背景介绍

项目主要是将Oracle、MySQL、SQLServer、Db2等其他数据库的实时变更数据同步到其他异构数据库中。本篇文章主要是讨论oracle的实时采集，通过Logminer捕获归档日志，然后将提取后的数据推送到Kafka中。

项目使用的技术框架

使用的核心框架：https://github.com/debezium/debezium 用于捕获归档日志，然后推送到kafka中。

Debezium框架是基于Kafka Connect实现的，分为source端和sink端。

source: 负责将源库的数据放入kafka中；

sink: 负责将kafka的数据落入目标库中；

source和sink的调度管理统一交给kafka connect来负责。

如何获取归档日志

Debezium实现的Oracle source端，将数据同步到kafka中，有Logminer和XStream两种实现方式，其中Logminer是oracle数据库自带的，不需要额外收费；而XStream需要额外收费的。因此，今天主要介绍的是Logminer的方式获取归档日志。

Logminer获取归档日志的步骤

这里只介绍一个大概的步骤，具体详细步骤请参考Oracle官方文档，里面有比较详细的步骤。

1. 首先需要开启oracle数据库归档日志；
2. 使用Logminer程序DBMS_LOGMNR.ADD_LOGFILE 增加需要采集的日志，这一步很重要，也是今天问题的核心。
3. 调用开始采集 DBMS_LOGMNR.START_LOGMNR 程序；
4. 查询V$LOGMNR_CONTENTS 视图，从而获取归档文件中的数据；
5. 调用DBMS_LOGMNR.END_LOGMNR 程序结束.

Oracle归档日志和重做日志

因为实时数据采集主要是作用在归档日志和重做日志上，如果对这两种日志不理解，将导致Logminer出现的错误无法有一个清晰的认知，从而无法解决现场实际面临的各种问题。

重做日志

也被称为redo log，主要是用来进行数据库恢复的，你对数据库表的任何数据操作，都会首先将变更写入重做日志中，用来在数据库宕机时能及时恢复数据，里面记录了数据的详细变更记录。默认数据库会有3个重做日志文件，可以通过查询V$LOGFILE获取。这3个重做日志文件是轮流使用的，当第一个用满后将切换到第二个、当第二个用满之后切换到第三个，当第三个用满之后切换到第一个，切换之后目标重做日志就被覆盖了，也就是丢失了。例如当第一个用满后将切换到第二个，那么原来第二个重做日志上的数据就丢失了。当然，这个重做日志的文件大小和个数都是可以配置的。

特点：及时写入，自动循环覆盖

归档日志

归档日志主要是重做日志的一个备份，也可以用来进行数据的恢复，也可以用来进行数据库的同步。由于重做日志会循环使用，并且还会出现覆盖丢失的情况，因此，需要将重做日志放到别的地方进行备份存储，这也就诞生了归档日志。归档日志默认是不开启的，需要配置数据库才能使用，并且需要占用许多存储，因此需要及时的清理。重做日志会定时的存储成归档日志，并且在切换的时候也会存储到归档日志中，防止重做日志丢失。

特大：自动触发写入、可永久存储

问题：ora-01291: missing logfile

有了Logminer和归档日志和重做日志的简单介绍之后就可以进入今天的正题了，我们在实时抽取oracle归档日志的时候发现，当数据量很大的时候经常会出现oracle错误：ora-01291: missing logfile，提示找不到重做日志文件了。

首先我们需要分析Logminer的第二步：DBMS_LOGMNR.ADD_LOGFILE，这一步不仅需要将归档日志添加到Logminer引擎中，还需要将重做日志也需要添加进来，因为归档日志的数据并不是及时的，需要配合归档日志 + 重做日志才能保证及时性，但是重做日志又有被覆盖的可能，因此就会出现ora-01291错误。了解了问题原因，那么我们如何解决问题呢？既然只有在数据量很大的时候才会出现，那么我们可以将重做日志的个数增加到10个，每个文件大小增加到5G。这个调整需要谨慎操作，官方的说法是最好将重做日志的切换时间控制在半小时左右。这样就不会出现ora-01291的错误了，因为重做日志的切换频率降低了、文件个数也增加了。例如Logminer目前正在读取重做日志5 + 归档日志，只有当oracle此时立马把 重做日志5，6，7，8，9，0,1,2,3,4,5（以10个重做日志为例）全部写满才会导致重做日志5丢失，而此时每个操作日志的大小为5G，总共需要写入50G的数据，你不可能那么快写入50GB，当你写入的时候Logminer已经读取完了，因此就不会再出现找不到重做日志的问题了。

问题：日志定位耗时

当数据库产生了大量归档日志的时候，Logminer需要定位到某一个表的起始SCN点很耗时。这个问题可以调整配置来实现，Debezium有大量的配置用来控制SCN点的增量范围和每次获取时间设置等，需要根据自身的场景进行合理调整。

配置名	默认值	描述
log.mining.batch.size.min	1000	The minimum SCN interval size that this connector attempts to read from redo/archive logs. Active batch size is also increased/decreased by this amount for tuning connector throughput when needed.
log.mining.batch.size.max	100000	The maximum SCN interval size that this connector uses when reading from redo/archive logs.
log.mining.batch.size.default	20000	The starting SCN interval size that the connector uses for reading data from redo/archive logs.
log.mining.sleep.time.min.ms	0	The minimum amount of time that the connector sleeps after reading data from redo/archive logs and before starting reading data again. Value is in milliseconds.
log.mining.sleep.time.max.ms	3000	The maximum amount of time that the connector ill sleeps after reading data from redo/archive logs and before starting reading data again. Value is in milliseconds.
log.mining.sleep.time.default.ms	1000	The starting amount of time that the connector sleeps after reading data from redo/archive logs and before starting reading data again. Value is in milliseconds.
log.mining.sleep.time.increment.ms	200	The maximum amount of time up or down that the connector uses to tune the optimal sleep time when reading data from logminer. Value is in milliseconds.
log.mining.view.fetch.size	10000	The number of content records that the connector fetches from the LogMiner content view.
log.mining.archive.log.hours	0	The number of hours in the past from SYSDATE to mine archive logs. When the default setting (0) is used, the connector mines all archive logs.