什么是oracle 日志文件

重做日志redo

log

file是lgwr进程从oracle实例中的redo

log

buffer写入的，是循环利用的。就是说一个redo

log

file(group)

写满后，才写下一个。

归档日志archive

log是当数据库运行在归档模式下时，一个redo

log

file(group)写满后，由arcn进程将重做日志的内容备份到归档日志文件下，然后这个redo

log

file(group)才能被下一次使用。

不管数据库是否是归档模式，重做日志是肯定要写的。而只有数据库在归档模式下，重做日志才会备份，形成归档日志。

一般来说，归档日志结合全备份，用于数据库出现问题后的恢复使用。

重做日志是循环使用的。比如说，有三个重做日志组a、b、c。那么，当a写满后，系统就调用arcn进程，将a备份为归档日志，同时b已经开始使用了。

假设你只有两个组a、b，如果某种情况下，a正在备份，未结束，还不能继续使用，而b也写满了，这个时候，数据库就会出现挂起的情况。所以一般情况下，重做日志最好是三个组或者再多一点，而且大小要适当。

实际上，一个重做日志组满了后，就开始写入归档日志。不是等abc都写满了，再归档，这样肯定就是出现挂起的情况了，oracle不是这样的，归档日志和重做日志都是物理上的文件，只是存放的目录不同，而且重做日志的文件名不变，而归档日志的文件名是备份时系统生成的。

重做日志备份为归档日志后，系统就会把重做日志的内容清空，但文件依然存在，准备下一次使用。

重做日志纪录了你所有做过的dml语句，重做日志循环使用，写满一轮后就要覆盖前面的。如果你是用热备模式，当重做日志写满一个后就将内容写入归档日志，以备将来恢复数据用。

只有数据库运行在归档模式并且初始化参数archive_log_start等于true时，arcn进程才能被启动，进行自动归档。

如果数据库运行在归档模式但archive_log_start等于false时，需要dba手工归档。

重做日志文件也叫联机日志文件,一般数据库有几个日志文件(例如有三个,编号分别为1,2,3)先写1,当1满时再写2,当2满时再写3,当3满时1就归

档出来,产生一个文件写到磁盘上,这个文件就叫归档日志文件1归档出来后,新的联机日志文件又写到1中,将原来的覆盖,(即联机日志是循环使用的)一

般当产生一个检查点或联机日志写满一定程度时会产生一个归档日志文件

监听日志在$ORACLE_BASE/diag/tnslsnr/hostname/listener/trace目录下，文件名为listenerlog

上面的hostname根据你的实际主机名而定

查看Oracle数据库的用户登录的记录档案是从log文件中挖出用户登录信息。

1、创建数据字典文件（data-dictionary）

（1）首先在initora初始化参数文件中，指定数据字典文件的位置，也就是添加一个参数UTL_FILE_DIR，该参数值为服务器中放置数据字典文件的目录。

如：UTL_FILE_DIR = ($ORACLE_HOME\logs) ,重新启动数据库，使新加的参数生效。

（2）创建数据字典文件：

SQL> connect /as sysdba

SQL> execute dbms_logmnr_dbuild(dictionary_filename =>

'dictora',dictionary_location => 'G:\oracle\logs');

PL/SQL procedure successfully completed

2、创建要分析的日志文件列表：

（1）创建分析列表，即所要分析的日志：

SQL> execute dbms_logmnradd_logfile(LogFileName =>

'G:\ORACLE\ORADATA\ORADBSP\REDO04LOG',Options => dbms_logmnrnew);

PL/SQL procedure successfully completeds

（2）添加分析日志文件（一次添加1个为宜）：

SQL>

execute dbms_logmnradd_logfile(LogFileName =>

'G:\ORACLE\ORADATA\ORADBSP\REDO05LOG',

Options => dbms_logmnrADDFILE);

PL/SQL procedure successfully completed

3、使用logMiner进行日志分析：

（1）无限制条件，即用数据字典文件对要分析的日志文件所有内容做分析：

SQL> execute dbms_logmnrstart_logmnr

(DictFileName => 'G:\oracle\logs\dictora');

PL/SQL procedure successfully completed

oracle 归档日志

归档日志(Archive Log)是非活动的重做日志备份通过使用归档日志,可以保留所有重做历史记录,当数据库处于ARCHIVELOG模式并进行日志切换式,后台进程ARCH会将重做日志的内容保存到归档日志中当数据库出现介质失败时,使用数据文件备份,归档日志和重做日志可以完全恢复数据库

日志 *** 作模式:ARCHIVELOG NOARCHIVELOG

1,改变日志 *** 作模式:

检查当前日志 *** 作模式

SELECT log_mode from v$database;

关闭数据库,然后装载数据库

SHUTDOWN IMMEDIATE

STARTUP MOUNT

改变日志 *** 作模式,然后打开数据库

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

2,执行手工归档

从oracle database 10g开始,当将日志 *** 作模式转变未ARCHIVELOG模式时,oracle会自动启动ARCH进程如果要使用手工归档那么在改变日志 *** 作模式时必须使用命令ALTER DATABASE ARCHIVELOG MANUAL

需要注意,使用手工归档方式,数据库管理员必须手工执行归档命令如果没有执行手工归档命令,日志组的原有内容将不能被覆盖ALTER DATABASE ARCHIVELOG MANUAL 命令是为了与先前的版本兼容而保留的,将来的oracle版本会淘汰该命令,使用手工归档方式是,数据库管理员可以执行以下命令归档重做日志:

ALTER SYSTEM ARCHIVELOG ALL;

3,配置归档进程

初始化参数LOG_ARCHIVE_MAX_PROCESSES用于指定例程初始启动的最大归档进程个数,当将数据库转变为ARCHIVELOG模式时,默认情况下oracle会自动启动两个归档进程通过改变初始化参数LOG_ARCHIVE_MAX_PROCESS的值,可以动态地增加或降低归档进程的个数:

ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=3;配置归档位置和文件格式

当数据库处于ARCHIVELOG模式时,如果进行日志切换,后台进程将自动生成归档日志,归档日志的默认位置为%oracle_home%rdbms,在oracle database 10g中,归档日志的默认文件格式为ARC%S_%R%T为了改变归档日志的位置和名称格式,必须改变相应的初始化参数,1,初始化参数LOG_ARCHIVE_FORMAT用于指定归档日志的文件名格式,设置该初始化参数时,可以指定以下匹配符:

%s: 日志序列号:

%S: 日志序列号(带有前导0)

%t: 重做线程编号

%T: 重做线程编号(带有前导0)

%a: 活动ID号

%d: 数据库ID号

%r RESETLOGS的ID值

从10g开始,配置归档日志文件格式时,必须带有%s,%t和%r匹配符,配置了归档文件格式后,必须重启数据库

2,使用LOG_ARCHIVE_DEST配置归档位置

如果不使用备用数据库,只需要将归档日志存放到本地目录配置本地归档位置可以使用初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_DUPLEX_DEST,其中,第一个参数用于设置第一个归档位置,第二个参数用于指定第二个归档位置

ALTER SYSTEM SET log_archive_dest='d:demoarchive1';ALTER SYSTEM SET log_archive_duplex_dest='d:demoarchive2';3,使用LOG_ARCHIVE_DEST_n配置多个归档位置

初始化参数LOG_ARCHIVE_DEST_n用于指定多个归档位置,该参数最多可以指定10个归档位置通过使用初始化参数LOG_ARCHIVE_DEST_n,不仅可以配置本地归档位置,还可以配置远程归档位置

如果既要在主节点上生成归档日志,又要将归档日志传递到备用节点,那么必须使用参数LOG_ARCHIVE_DEST_n该参数与LOG_ARCHIVE_DEST具有如下区别;初始化参数LOG_ARCHIVE_DEST_n可以配置本地归档位置和远程归档位置,而初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_DUPLEX_DEST只能配置本地归档位置

初始化参数LOG_ARCHIVE_DEST_n可以配置多达10个归档位置,而初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_DUPLEX_DEST最多只能配置两个归档位置

初始化参数LOG_ARCHIVE_DEST_n 不能与初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_DUPLEX_DEST同时使用

因为初始化参数LOG_ARCHIVE_DEST_n不能与初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_DUPLEX_DEST同时使用,所以必须禁用初始化参数LOG_ARCHVE_DEST和LOG_ARCHIVE_DUPLEX_DEST当使用初始化参数LOG_ARCHIVE_DEST_n配置本地归档位置时,需要指定LOCALTION选项当配置远程归档位置时,需要指定SERVICE选项

示例如下:

ALTER SYSTEM SET log_archive_duplex_dest='';ALTER SYSTEM SET log_archive_dest='';

ALTER SYSTEM SET log_archive_dest_1='location=d:demoarchive1';ALTER SYSTEM SET log_archive_dest_2='location=d:demoarchive2';ALTER SYSTEM SET log_archive_dest_3='location=d:demoarchive3';ALTER SYSTEM SET log_archive_dest_4='service=standby';配置远程归档位置时,SERVICE选项需要指定远程数据库的网络服务名(在tnsnamesora文件中配置)4,使用LOG_ARCHIVE_DEST_n选项

使用初始化参数LOG_ARCHIVE_DEST_n配置归档位置时,可以在归档位置上指定OPTIONAL或MANDATORY选项指定MANDATORY选项时,可以设置REOPEN属性

OPTIONAL:该选项是默认选项使用该选项时,无论归档是否成功,都可以覆盖重做日志

MANDATORY:强制归档使用该选项时,只有在归档成功之后,重做日志才能被覆盖

REOPEN:该属性用于指定重新归档的时间间隔,默认值为300秒,必须跟在MANDATORY后

例:

Alter system set log_archive_dest_1=’location=d:demoarchive1 mandatory’;Alter system set log_archive_dest_2=’location=d:demoarchive2 mandatory reopen=500’;Alter system set log_archive_dest_3=’location=d:demoarchive3 optional’;5,控制本地归档成功的最小个数

使用初始化参数LOG_ARCHIVE_MIN_SUCCEED_DEST控制本地归档的最小成功个数Alter system set log_archive_min_succeed_dest=2;6,使用初始化参数LOG_ARCHIVE_DEST_STATE_n控制归档位置的可用性设置该参数为ENABLE(默认值),表示会激活相应的归档位置;设置该参数为DEFER,表示禁用相应归档位置当归档日志所在磁盘损坏或填满时,DBA需要暂时禁用该归档位置

Alter system set log_archive_dest_state_3=defer;(禁用)Alter system set log_archive_dest_state_3=enable;(启用)显示归档日志信息

1,使用ARCHIVE LOG LIST命令可以显示日志 *** 作模式,归档位置,自动归档机器要归档的日志序列号等信息

2显示日志 *** 作模式

SELECT name,log_mode FROM v$database;

3,显示归档日志信息

Col name format a46

Select name, swquence#, first_change# FROM v$archived_log;Name用于表示归档日志文件名,sequence#用于表示归档日志对应的日志序列号,firs_change#用于标识归档日志的起始SCN值

4、执行介质恢复时,需要使用归档日志文件,此四必须准确定位归档日志的存放位置通过查询动态性能视图v$archive_dest可以取得归档日志所在目录

SELECT destination FROM v$archive dest;

5,显示日志历史信息

SELECT FROM v$loghist;

THREAD#用于标识重做线程号,SEQUNCE#用于标识日志序列号,FIRST_CHANGE#用于标识日志序列号对应的起始SCN值,FIRST_TIME用于标识起始SCN的发生时间SWICTH_CHANGE#用于标识日志切换的SCN值

6显示归档进程信息

进行日志切换时,ARCH进程会自动将重做日志内容复制到归档日志中,为了加快归档速度,应该启用多个ARCH进程通过查询动态性能视图V$ARCHIVE_PROCESSES可以显示所有归档进程的信息!

SELECT FROM v$archive_processes;

Porcess用于标识ARCH进程的编号,status用于标识ARCH进程的状态(ACTIVE:活动,STOPPED:未启动),log_sequence用于标识正在进行归档的日志序列号,state用于标识ARCH进程的工作状态==========================================用Oracle归档日志进行恢复的方法

用Oracle归档日志进行恢复的方法

联机重演日志没有丢失应使用完成恢复，如联机重演日志损坏，而又没有备份，就只能进行不完全恢复。

一、完全恢复：

1．使用命令“svrmgrl”调用行方式服务器管理；2．输入命令“connect internal”，然后输入命令“startup mount’；3．输入命令“recover database;”

4．按下ENTER，接受默认值。

5．然后输入命令“alter database open;”完成数据库恢复。

二、不完全恢复

警告：

应用不完成恢复前，必须将数据库做一次完全冷备份，因为应用不完全恢复后，联机重演日志将重置，以前的所有日志不可用。

如果恢复不成功，数据库就不能使用了。再次强调，做完全冷备份后再应用不完全恢复。

1）基于变化的恢复(change-based recovery)要执行基于变化的恢复，需要知道丢失日志之前的系统写入归档重演日志的最大的变化号(SCN)，然后可以启动恢复语句恢复数据库直到改变scn_number，其中比scn_number是写到已归档重演日志文件顺序号386的SCN(即，小于丢失日志顺序号387的SCN)。可以从V$log_history视图中得到SCN信息。

select first_change# from v$log_history where sequence#=387;其中387为最后一个有效的日志文件号加1,该例是查找386

知道了SCN后，使用下述步骤完成恢复

1．使用命令“svrmgrl”调用行方式服务器管理；2．输入命令“connect internal”，然后输入命令“startup mount’；3．输入命令“recover database until change 9999;”

4．在回答Oracle第一个归档重演日志建议信息时，输入“auto”,Oracle在找到第387号重演日志之前停止恢复。

5．用命令“alter database open resetlogs;”打开数据库。(应用该命令前请确认数据库已备份，如打开失败，日志将不可用)2)基于停止的恢复(cancel-based recovery)

1．使用命令“svrmgrl”调用行方式服务器管理；2．输入命令“connect internal”，然后输入命令“startup mount’；3．输入命令“recover database until cancel;”,Oracle提示需要的第一个归档重演日志文件名．按下ENTER键接受缺省文件名，并且—路ENTER直到询问顺序号387的日志。输入“cancel”，停止恢复 *** 作。

4．用命令“alter database open resetlogs;”打开数据库。(应用该命令前请确认数据库已备份，如打开失败，日志将不可用)3)基于时间的恢复(time-based recovery)

为使用基于时间的恢复，必须知道记录在V$log_history归档重演日志序号387（丢失重演日志）的时间，通过执行查询语句“select time from v$log_history where sequence#=387;”得到。本例得到的时间是：2002-06-23 14：42：04现在开始实施恢复。

1．使用命令“svrmgrl”调用行方式服务器管理；2．输入命令“connect internal”，然后输入命令“startup mount’；3．输入命令“recover database until time '2002/06/23 14:42:04';”,Oracle提示需要的第一个归档重演日志文件名，输入“auto”，Oracle恢复归档重演日志直到序号为387的日志，停止恢复 *** 作。

4．用命令“alter database open resetlogs;”打开数据库。(应用该命令前请确认已数据库已备份，如打开失败，日志将不可用)提示： 使用基于时间的恢复，时间的格式是YYYY/MM/DD HH24:MI:SS,并且用单引号括起。

附：如何启用Oracle的归档方式

1参照以下内容编辑initora文件：

log_archive_start = true

log_archive_dest_1 = " LOCATION=D:\Oracle\oradata\ORCL\archive "og_archive_format = %%ORACLE_SID%%T%TS%SARC2关闭数据库

svrmgrl> connect internal

svrmgrl> shutdown normal

3然后启动实例并安装该数据库，但不打开数据库。

svrmgrl> startup mount

4接着，发布下列更改数据库的命令。

Svrmgrl> alter database archivelog;

5现在，数据库已经更改为归档方式，您可以打开数据库。

svrmgrl> alter database open;

提示：也可以使用DBA studio工具启用数据库的归档方式， *** 作很简单=============================================================ORACLE归档模式的设置

在ORACLE 数据库的开发环境和测试环境中，数据库的日志模式和自动归档模式一般都是不设置的，这样有利于系统应用的调整，也免的生成大量的归档日志文件将磁盘空间大量的消耗。但在系统上线，成为生产环境时，将其设置为日志模式并自动归档就相当重要了，因为，这是保证系统的安全性，有效预防灾难的重要措施。这样，通过定时备份数据库和在两次备份间隔之间的日志文件，可以有效的恢复这段时间的任何时间点的数据，可以在很多时候挽回或最大可能的减少数据丢失。

一、 要使OARCLE 数据库进行日志的自动归档，需要做两方面的事情；1．是数据库日志模式的设置(可为Archive Mode 和No Archive Mode)；2．就是自动归档模式设置(Automatic archival,可为Enabled 和Disabled)。

二、 如何查看数据库的现行日志和自动归档模式的设置可用archive log list 命令来查看。

运行在日志自动归档模式下的数据库系统查看结果如下（一般是生产环境）：

SQL> archive log list

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /backup/archivelog

Oldest online log sequence 2131

Next log sequence to archive 2133

Current log sequence 2133

没有启动数据库日志模式和自动归档的数据库系统查看结果如下（一般是测试环境）：

SQL> archive log list

Database log mode No Archive Mode

Automatic archival Disabled

Archive destination /u01/app/oracle/product/817/dbs/archOldest online log sequence 194

Current log sequence 196

三 数据库日志模式的设置

在创建数据库时，可以在CREATE DATABASE 语句中指定数据库的日志模式。假如没有指明，则缺省为NOARCHIVELOG 模式。由于如果在创建数据库时指明是Archive Mode的话，会增加约20%的创建时间，而在以后启动INSTANCE 时再设置的话，一般只用去几秒的时间，所以一般在创建数据库时是不设置为ARCHIVE MODE 的。

将数据库的日志模式设置切换（Archive Mode 和No Archive Mode 之间的切换）的步骤和 *** 作如下：

1 关闭运行的数据库实例

SQL> shutdown

在进行日志模式切换之前，必须将运行的数据库正常关闭。

2 备份数据库

该备份跟以后产生的日志一起用于将来的灾难恢复（很重要，如要改为归档日志模式，没有这个数据库备份，仅有日志文件是无法从该时间点恢复的）。

3 启动数据库实例到mount 状态，但不要打开。

SQL> startup mount

4 切换数据库日志模式。

SQL> alter database archivelog;(设置数据库为归档日志模式)或SQL> alter database noarchivelog;(设置数据库为非归档日志模式)5 打开数据库

SQL> alter database open;

6 确认数据库现在处于归档日志模式。

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination for example: $ORACLE_HOME/dbs/archOldest on-line log sequence 275

Next log sequence 277

Current log sequence 278

7 将这个时间点的redo logs 归档

SQL> archive log all;

8 确认新产生的日志文件已在相应的归档目录下面。

四 自动归档模式设置(Automatic archival,可为Enabled 和Disabled)。

在该模式下，数据库启动一个arch 进程，专门负责将redo logs 写到系统归档设备的相应目录下。在数据库的参数文件中设置参数（一般是在$ORACLE_HOME/dbs/initora 文件中）：

LOG_ARCHIVE_START=

LOG_ARCHIVE_DEST=

LOG_ARCHIVE_FORMAT=

LOG_ARCHIVE_START:

其它oracle日志分为两种：

1、系统日志，就是程序运行的相关日志

2、是数据库本身运行是为了保障事务一致性的重做日志。

重做日志有几种状态：

在线联机日志和归档日志

归档日志就是将已经写满的在线联机日志写到另外的地方归档，以便数据库可以恢复到那个时刻！

1、

切换至oracle用户

2、进入Oracle安装目录下的app文件夹

3、新建目录并创建脚本文件（一定要在oracle用户下 *** 作）

arcclearsh 脚本内容如下

4、给文件分配权限（一定要在oracle用户下 *** 作）

5、给Oracle 用户创建计划任务（一定要在oracle用户下 *** 作）

新增内容

crontab 计划任务时间设置说明

6、重启 crontab 服务

‍测试环境中出现了一个异常的告警现象：一条告警通过 Thanos Ruler 的 >

分析

下面我们开始分析这个问题。综合第一节的描述，初步的猜想是告警在到达 AlertManager 前的某些阶段的处理过程太长，导致告警到达 AlertManager 后就已经过了自动解决时间。我们从分析平台里一条告警的流转过程入手，找出告警在哪个处理阶段耗时过长。首先，一条告警的产生需要两方面的配合：

metric 数据

告警规则

将 metric 数据输入到告警规则进行计算，如果符合条件则产生告警。DMP 平台集成了 Thanos 的相关组件，数据的提供和计算则会分开，数据还是由 Prometheus Server 提供，而告警规则的计算则交由 Thanos Rule（下文简称 Ruler）处理。下图是 Ruler 组件在集群中所处的位置：

看来，想要弄清楚现告警的产生到 AlertManager 之间的过程，需要先弄清除 Ruler 的大致机制。官方文档对 Ruler 的介绍是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。

不难推测，Ruler 应该是在 Prometheus 上封装了一层，并提供一些额外的功能。通过翻阅资料大致了解，Ruler 使用 Prometheus 提供的库计算告警规则，并提供一些额外的功能。下面是 Ruler 中告警流转过程：

首先，图中每个告警规则 Rule 都有一个 active queue（下面简称本地队列），用来保存一个告警规则下的活跃告警。

其次，从本地队列中取出告警，发送至 AlertManager 前，会被放入 Thanos Rule Queue（下面简称缓冲队列），该缓冲队列有两个属性：

capacity（默认值为 10000）：控制缓冲队列的大小，

maxBatchSize（默认值为 100）：控制单次发送到 AlertManager 的最大告警数

了解了上述过程，再通过翻阅 Ruler 源码发现，一条告警在放入缓冲队列前，会为其设置一个默认的自动解决时间（当前时间 + 3m），这里是影响告警自动解决的开始时间，在这以后，有两个阶段可能影响告警的处理：1 缓冲队列阶段2 出缓冲队列到 AlertManager 阶段（网络延迟影响）由于测试环境是局域网环境，并且也没在环境上发现网络相关的问题，我们初步排除第二个阶段的影响，下面我们将注意力放在缓冲队列上。通过相关源码发现，告警在缓冲队列中的处理过程大致如下：如果本地队列中存在一条告警，其上次发送之间距离现在超过了 1m（默认值，可修改），则将该告警放入缓冲队列，并从缓冲队列中推送最多 maxBatchSize 个告警发送至 AlertManager。反之，如果所有本地队列中的告警，在最近 1m 内都有发送过，那么就不会推送缓冲队列中的告警。也就是说，如果在一段时间内，产生了大量重复的告警，缓冲队列的推送频率会下降。队列的生产方太多，消费方太少，该队列中的告警就会产生堆积的现象。因此我们不难猜测，问题原因很可能是是缓冲队列推送频率变低的情况下，单次推送的告警数量太少，导致缓冲队列堆积。下面我们通过两个方面验证上述猜想：首先通过日志可以得到队列在大约 20000s 内推送了大约 2000 次，即平均 10s 推送一次。结合缓冲队列的具体属性，一条存在于队列中的告警大约需要 (capacity/maxBatchSize)10s = 16m，AlertManager 在接收到告警后早已超过了默认的自动解决时间（3m）。其次，Ruler 提供了 3 个 metric 的值来监控缓冲队列的运行情况：

thanos_alert_queue_alerts_dropped_total

thanos_alert_queue_alerts_pushed_total

thanos_alert_queue_alerts_popped_total

通过观察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丢失的总数，也能佐证了缓冲队列在某些时刻存在已满的情况。

解决通过以上的分析，我们基本确定了问题的根源：Ruler 组件内置的缓冲队列堆积造成了告警发送的延迟。针对这个问题，我们选择调整队列的 maxBatchSize 值。下面介绍一下这个值如何设置的思路。由于每计算一次告警规则就会尝试推送一次缓冲队列，我们通过估计一个告警数量的最大值，得到 maxBatchSize 可以设置的最小值。假设你的业务系统需要监控的实体数量分别为 x1、x2、x3、、xn，实体上的告警规则数量分别有 y1、y2、y3、、yn，那么一次能产生的告警数量最多是(x1 y2 + x2 y2 + x3 y3 + + xn yn)，最多推送（y1 + y2 + y3 + + yn）次，所以要使缓冲队列不堆积，maxBatchSize 应该满足：maxBatchSize >= (x1 y2 + x2 y2 + x3 y3 + + xn yn) / (y1 + y2 + y3 + + yn)，假设 x = max(x1,x2, ,xn), 将不等式右边适当放大后为 x，即 maxBatchSize 的最小值为 x。也就是说，可以将 maxBatchSize 设置为系统中数量最大的那一类监控实体，对于 DMP 平台，一般来说是 MySQL 实例。

注意事项

上面的计算过程只是提供一个参考思路，如果最终计算出该值过大，很有可能对 AlertManager 造成压力，因而失去缓冲队列的作用，所以还是需要结合实际情况，具体分析。因为 DMP 将 Ruler 集成到了自己的组件中，所以可以比较方便地对这个值进行修改。如果是依照官方文档的介绍使用的 Ruler 组件，那么需要对源码文件进行定制化修改。

‍‍

以上就是关于什么是oracle 日志文件全部的内容，包括:什么是oracle 日志文件、如何查看oracle数据库监听日志文件目录及大小、如何看Oracle数据库的用户登录的记录档案等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！