重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
Oracle日志文件查看方法:
让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:主机域名、网站空间、营销软件、网站建设、巩留网站维护、网站推广。
1、以sysdba权限用户登录数据库。
2、执行sql语句:
select * from v$logfile;
3、结果显示即为日志路径:
4、另外还有其他的操作日志可用以下两个sql语句查询:
select * from v$sql;--(#查看最近所作的操作)
select * fromv $sqlarea;--(#查看最近所作的操作)
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就是让我们看懂日志信息的工具,通过这个工具可以:查明数据库的逻辑更改,侦察并更正用户的误操作,执行事后审计,执行变化分析。
首先了解什么是外部表,与其它表的区别,建立一个简单的外部表(主要看操作过程),最后我们用外部表查看ORACLE报警日志
1.了解oracle外部表
外部表定义:结构被存放在数据字典,而表数据被放在OS文件中的表
作用:在数据库中查询OS文件的数据,还可以将OS文件数据装载到数据库中
与其它表的区别:在外部表上不能执行DML操作,也不能在外部表上建索引,只能执行select操用
2.建一个简单的外部表1.建一个OS上的文件
因为外部表主要是查看OS上的文件,首先在OS上建一个文件
mkdir -p /oracle/ext
vi /oracle/ext/ext.dat
10,20,30
40,50,60
70,80,90
2.授予用户权限,并建立目录对象
在此我们先建一个新用户
create user test identified by “123” default tablespace test quota unlimited on test;
用户授权
SQL grant create any directory to test;
建立目录对象
SQL conn test / 123
Connected.
SQL create directory ext as '/oracle/ext';
Directory created.
3.建立外部表
SQL create table exttable(
id number,name varchar2(10),i number
)organization external
(type oracle_loader
default directory ext
access parameters
(records delimited by newline
fields terminated by ','
)location('ext.dat')
);
4.测试
SQL select * from exttable;
ID NAMEI
---------- ---------- ----------
10 20 30
40 50 60
70 80 90
测试成功,可见在数据库中可以查询OS文件的数据
2. 使用外部表查看oracle报警日志
由于在上面实验中已建立了一个用户,并赋相应的权限,而且也有了OS文件(即报警文件alert_SID.log),所以在此直接建立目录对象并建立外部表就可以了。
1.建立目录对象
SQL conn test / 123
Connected.
SQL create directory bdump as '/oracle/u01/app/oracle/admin/db2/bdump';
Directory created.
2.建立外部表
SQL create table alert_log(
text varchar2(400)
)organization external
(type oracle_loader
default directory bdump
access parameters
(records delimited by newline
)location('alert_db2.log')
);
3.测试
首先查看能否查到alert_db2.log的内容
SQL select * from alert_log where rownum 10;
TEXT
--------------------------------------------------------------------------------
Thu Jun 11 00:51:46 2009
Starting ORACLE instance (normal)
Cannot determine all dependent dynamic libraries for /proc/self/exe
Unable to find dynamic library libocr10.so in search paths
RPATH = /ade/aime1_build2101/oracle/has/lib/:/ade/aime1_build2101/oracle/lib/:/a
de/aime1_build2101/oracle/has/lib/:
LD_LIBRARY_PATH is not set!
The default library directories are /lib and /usr/lib
Unable to find dynamic library libocrb10.so in search paths
Unable to find dynamic library libocrutl10.so in search paths
9 rows selected.
测试成功
然后我们测试查报警信息’ORA-%’
SQL select * from alert_log where text like 'ORA-%';
TEXT
--------------------------------------------------------------------------------
ORA-00202: control file: '/oracle/u01/app/oracle/product/10.2.0/db2/dbs/cntrldb2
.dbf'
ORA-27037: unable to obtain file status
ORA-205 signalled during: ALTER DATABASE MOUNT…
ORA-00301: error in adding log file '/home/oracle/oracle/oradata/testdb/redo01.l
og' - file cannot be created
ORA-27040: file create error
ORA-1501 signalled during: CREATE DATABASE db2
ORA-00200: control file could not be created
TEXT
--------------------------------------------------------------------------------
ORA-00202: control file: '/oracle/u01/app/oracle/product/10.2.0/db2/dbs/cntrldb2
.dbf'
ORA-27038: created file already exists
ORA-1501 signalled during: CREATE DATABASE db2
ORA-00200: control file could not be created
ORA-00202: control file: '/oracle/u01/app/oracle/product/10.2.0/db2/dbs/cntrldb2
.dbf'
ORA-27038: created file already exists
ORA-1501 signalled during: CREATE DATABASE db2
测试成功,
可见我们可以使用外部表来方便的查看ORACLE的报警信息
1、检查oracle监听服务运行状态,输入lsnrctl status命令来查看,看到提示信息TNS:no listener,表示监听没有启动,
2、监听没有启动,则需要输入lsnrctl start启动监听服务,当看到提示信息"The command completed successfully",则表示启动成功,
3、以system用户身份登陆oracle,sqlplus /nolog,conn as sysdba,
4、提示Connected to an idle instance。则表示连接成功,下面开始启动oracle实例服务,输入startup命令,当看到如图的提示信息,则启动完成,就可以正常使用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 组件,那么需要对源码文件进行定制化修改。
1、在桌面上找到 计算机,右键管理,点击服务和应用程序,双击服务,找到oracle的四个服务,这里我们只需要启动两个即可。如图
2、点击电脑左下角的开始--运行,输入sqlplus,回车。
3、出现命令窗口,
4、用户名填写scott 回车,密码填写scott,等待几秒。
5、以上就是成功连接上Oracle数据库。
6、执行select * from v$version ,就会出现如图。完成效果图。