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官方文档，里面有比较详细的步骤。

首先需要开启oracle数据库归档日志；
使用Logminer程序DBMS_LOGMNR.ADD_LOGFILE 增加需要采集的日志，这一步很重要，也是今天问题的核心。
调用开始采集 DBMS_LOGMNR.START_LOGMNR 程序；
查询V$LOGMNR_CONTENTS 视图，从而获取归档文件中的数据；
调用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.