如何查看数据库alert日志文件

1、登录Oracle服务器，切换到oracle用户下

#su - oracle

注：需要进入到命令行模式下

2、进入到sqlplus接口

$sqlplus '/as sysdba'

注意：使用角色sysdba

3、查询alter日志目录

show parameter dump

4、找到alert日志

管理数据库主要做好以下3方面的内容:

一、数据库定期备份

首先利用数据库自带的命令行工具将数据库备份下来,然后将该文件以日期参量重命名。

数据库定期备份的原因:

1)、有些数据是随时变化的,备份可以记录某时间点的数据;

2)、如数据库故障,可以随时还原。

二、数据库优化

1)、进行sql语句的执行优化;

2)、减少应用和数据库的交互次数、同一个sql语句的执行次数;

3)、整理数据库实体的碎片(特别是对某些表经常进行insert和delete动作,尤其注意,索引字段为系列字段、自增长字段、时间字段,对于业务比较频繁的系统,最好一个月重建一次);

4)、减少表之间的关联,特别对于批量数据处理,尽量单表查询数据,统一在内存中进行逻辑处理,减少数据库压力(java处理批量数据不可取,尽量用c或者c++ 进行处理,效率大大提升);

5)、对访问频繁的数据,充分利用数据库cache和应用的缓存;

6)、数据量比较大的,在设计过程中,为了减少其他表的关联,增加一些冗余字段,提高查询性能。

三、数据库日志文件管理

1、查看数据库中日志文件；

默认是三个组,这是数据库创建时自己添加的三个日志文件组；

2、添加日志文件组并添加成员。

简单来说，储存引擎分为两大类。针对事务处理(OLTP)和针对分析型(OLAP)。

事务性处理优化架构的数据库通常面对用户，为具体的程序设计。在使用中往往磁盘的寻道时间会是负载的瓶颈。更具体细分的一哈，主要分为两大流派：

日志结构流派，具体的有BitCask、SSTables、LSM-tree等都属于此类;

原地更新流派，B-tree类型是这一类的代表。像我们熟悉的关系型数据库和非关系型数据库。mysql,mongodb等等。

分析型的不面向最终用户，一般是业务分析师使用。需要在短时间扫描百万条记录，磁盘带宽通常是瓶颈。数据库有c-store等。面向列储存是这种数据库工作负载比较流行的解决方案。

希望是你期望的答案~~~~~~~

‍测试环境中出现了一个异常的告警现象：一条告警通过 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 组件，那么需要对源码文件进行定制化修改。

‍‍

以上就是关于如何查看数据库alert日志文件全部的内容，包括:如何查看数据库alert日志文件、数据库如何管理、什么是日志型数据库，什么是事务性数据库能举例简单说明吗谢谢等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！