oracle如何监控日志,windows清理oracle监听日志
如何查看oracle监听日志文件
Oracle日志查看 一.Oracle日志的路径: 登录:sqlplus "/as sysdba" 查看路径:SQL select * from v$logfile; SQL select * from v$logfile;(#日志文件路径) 二.Oracle日志文件包含哪些内容:(日志的数量可能略有不同) control01.ctl example01.dbf redo02.log sysaux01.dbf undotbs01.dbf control02.ctl redo03.log system01.dbf users01.dbf control03.ctl redo01.log SHTTEST.dbf temp01.dbf 三.Oracle日志的查看方法: SQLselect * from v$sql (#查看最近所作的操作) SQLselect * fromv $sqlarea(#查看最近所作的操作) Oracle 数据库的所有更改都记录在日志中,从目前来看,分析Oracle日志的唯一方法就是使用Oracle公司提供的LogMiner来进行,因为原始的日志信息我们根本无法看懂,Oracle8i后续版本中自带了LogMiner,而LogMiner就是让我们看懂日志信息的工具,通过这个工具可以:查明数据库的逻辑更改,侦察并更正用户的误操作,执行事后审计,执行变化分析。
创新互联主要从事成都做网站、成都网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务栾川,十余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:13518219792
oracle rac 监听日志在什么位置
你在操作系统上执行命令:lsnrctl status 查看监听状态
会输出一些信息
可以看到一个叫listener.log的文件,便是监听的日志,按照路径找到即可。
版本不同,可能名字也会有变化,12c的叫log.xml
oracle数据库的警告日志如何查看
测试环境中出现了一个异常的告警现象:一条告警通过 Thanos Ruler 的 HTTP 接口观察到持续处于 active 状态,但是从 AlertManager 这边看这条告警为已解决状态。按照 DMP 平台的设计,告警已解决指的是告警上设置的结束时间已经过了当前时间。一条发送至 AlertManager 的告警为已解决状态有三种可能:1. 手动解决了告警2. 告警只产生了一次,第二次计算告警规则时会发送一个已解决的告警3. AlertManager 接收到的告警会带着一个自动解决时间,如果还没到达自动解决时间,则将该时间重置为 24h 后首先,因为了解到测试环境没有手动解决过异常告警,排除第一条;其次,由于该告警持续处于 active 状态,所以不会是因为告警只产生了一次而接收到已解决状态的告警,排除第二条;最后,告警的告警的产生时间与自动解决时间相差不是 24h,排除第三条。那问题出在什么地方呢?
分析
下面我们开始分析这个问题。综合第一节的描述,初步的猜想是告警在到达 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日志文件查看方法:
1、以sysdba权限用户登录数据库。
2、执行sql语句:
select * from v$logfile;
3、结果显示即为日志路径:
4、另外还有其他的操作日志可用以下两个sql语句查询:
select * from v$sql;--(#查看最近所作的操作)
select * fromv $sqlarea;--(#查看最近所作的操作)
如何启动Oracle的监听日志
启动监听日志的步骤如下:
1.首先查看当前监听的状态
[oracle@oel ~]$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 01-JUL-2012 13:29:58
Copyright (c) 1991, 2011, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oel)(PORT=1521)))
STATUS of the LISTENER
————————
Alias listener
Version TNSLSNR for Linux: Version 11.2.0.3.0 – Production
Start Date 01-JUL-2012 13:12:51
Uptime 0 days 0 hr. 17 min. 7 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Listening Endpoints Summary…
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oel)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary…
Service “orcl” has 1 instance(s).
Instance “orcl”, status READY, has 1 handler(s) for this service…
Service “orclXDB” has 1 instance(s).
Instance “orcl”, status READY, has 1 handler(s) for this service…
The command completed successfully
从上面显示信息来看,我们监听正常。并且没有看到Listener Log File的信息。
2.进入监听配置,查看监听详细信息
[oracle@oel ~]$ lsnrctl –进入监听配置
LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 01-JUL-2012 13:35:00
Copyright (c) 1991, 2011, Oracle. All rights reserved.
Welcome to LSNRCTL, type “help” for information.
LSNRCTL show –查看监听参数信息
The following operations are available after show
An asterisk (*) denotes a modifier or extended command:
rawmode displaymode
rules trc_file
trc_directory trc_level
log_file log_directory
log_status current_listener
inbound_connect_timeout startup_waittime
snmp_visible save_config_on_stop
dynamic_registration enable_global_dynamic_endpoint
oracle_home pid
connection_rate_limit
LSNRCTL show log_status –查看监听日志状态
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oel)(PORT=1521)))
LISTENER parameter “log_status” set to OFF
The command completed successfully
上面信息显示Listener parameter “log_status” set to OFF说明监听日志是关闭的。这是时候我们需要启动监听日志。
3.设置当前监听,如果有多个监听,在修改监听配置的时候需要指定某个具体的监听,我这里只有一个默认的Listener,所以不需要设置。我这里还是演示一下。
LSNRCTL show current_listener
Current Listener is LISTENER
LSNRCTL set current_listener Listener
Current Listener is Listener
LSNRCTL show current_listener
Current Listener is Listener
4.启动监听日志,并且保存配置信息
LSNRCTL set log_status on –设置监听日志状态为on
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oel)(PORT=1521)))
LISTENER parameter “log_status” set to ON
The command completed successfully
LSNRCTL save_config –保存监听配置
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oel)(PORT=1521)))
Saved listener configuration parameters.
Listener Parameter File /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Old Parameter File /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.bak
The command completed successfully
5.在查看监听状态
[oracle@oel ~]$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 01-JUL-2012 13:44:32
Copyright (c) 1991, 2011, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oel)(PORT=1521)))
STATUS of the LISTENER
————————
Alias listener
Version TNSLSNR for Linux: Version 11.2.0.3.0 – Production
Start Date 01-JUL-2012 13:12:51
Uptime 0 days 0 hr. 31 min. 41 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Listener Log File /u01/app/oracle/diag/tnslsnr/oel/listener/alert/log.xml
Listening Endpoints Summary…
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oel)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary…
Service “orcl” has 1 instance(s).
Instance “orcl”, status READY, has 1 handler(s) for this service…
Service “orclXDB” has 1 instance(s).
Instance “orcl”, status READY, has 1 handler(s) for this service…
The command completed successfully
通过上述配置之后,看到了Listener Log File /u01/app/oracle/diag/tnslsnr/oel/listener/alert/log.xml
最后我们可以通过监听日志来查询里面的详细信息
[oracle@oel ~]$ grep ‘2012-07-01T13:45:40′ /u01/app/oracle/diag/tnslsnr/oel/listener/alert/log.xml|more
msg time=’2012-07-01T13:45:40.302+08:00′ org_id=’oracle’ comp_id=’tnslsnr’
分享文章:oracle如何监控日志,windows清理oracle监听日志
标题链接:http://pwwzsj.com/article/dsippdh.html