oracle数据库的日志文件

㈠ Oracle的日志文件存储在什么位置

1、通过sqlplus命令连接数据库，查看服务器是否已经开启归档。

㈡ 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日志的查看方法：
sql>select
*
from
v$sql
(#查看最近所作的操作)
sql>select
*
fromv
$sqlarea（#查看最近所作的操作）
oracle
数据库的所有更改都记录在日志中，从目前来看，分析oracle日志的唯一方法就是使用oracle公司提供的logminer来进行，因为原始的日志信息我们根本无法看懂，oracle8i后续版本中自带了logminer,而logminer就是让我们看懂日志信息的工具,通过这个工具可以：查明数据库的逻辑更改，侦察并更正用户的误操作，执行事后审计，执行变化分析。

㈢ 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 组件在集群中所处的位置：



首先，图中每个告警规则 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 联机重做日志文件和重做日志文件有什么区别

联机重做日志文件是：redo
log
数据库的每一个操作都会产生日志，记录在这里，做回滚、recovery等都需要这个，它有问题数据库起不来。
重做日志是
Archive
log
，数据库如果不开归档模式，不会产生archive
log。如果开了，redo
log文件写满了，就会复制到一个archive
log
文件，然后redo
log
重复使用。这个主要用于数据库的备份恢复。

㈤ 如何查看oracle的日志文件

1、因为oracle运行在Linux系统下，首先，要连接Linux系统。

㈥ oracle的日志文件有哪些

在Oracle数据库中，有一种日志文件叫做重做日志文件，他就是大家俗称的：redolog。在redolog中又分为两种：在线重做日志与归档日志。
ONLINE Redo log
在线重做日志(online redo log )主要用于：Oracle数据库所在服务器突然掉电、突然重启或者执行shutdown abort等命令使得在服务器重新启动之后，Oracle数据库没有办法正常的启动实例。此时，在线重做日志就派上了用场，Oracle会使用在线重做日志，把数据库恢复到服务器掉电前的那一个时刻，从而使得数据库能正常的启动起来 。
在Oracle数据库中，默认情况下，至少会有两个重做日志组，而且每个组里面至少包含了一个重做日志文件。日志组不会自动增加，在一个写满之后，会自动去写下一个。在下一个被写满之后会又从第一个开始写起。
Archive redo log
归档日志(archive log)主要用于硬件级别的错误：磁盘的坏道导致无法读写、写入的失败、磁盘受损导致数据库数据丢失。这就要使用归档日志文件，通过归档日志文件，把数据库恢复到归档日志所在的时间点上然后再通过在线重做日志文件把数据库恢复到当前的时间点上。
对于归档日志文件，可以理解为在线重做日志文件的备份。即当一个重做日志文件被填满了之后，归档日志文件就会把其备份保留一份。（因为上面说了，在线重做日志文件会自动的覆盖）所以，归档日志文件就是旧的在线日志文件的备份。

㈦ 如何查看oracle的日志文件

Oracle日志文件查看方法：

1、以sysdba权限用户登录数据库。
2、执行sql语句：

select*fromv$logfile;

3、结果显示即为日志路径：

select*fromv$sql;--(#查看最近所作的操作)
select*fromv$sqlarea;--（#查看最近所作的操作）

㈧ 什么是oracle 日志文件

oracle的日志文件是记录数据库变化的一个凭证. oracle的文件可以分为 数据文件、控制文件和重做日志文件(也就是咱们平时说的redo), oracle的日志文件时分组存放的, 一个oracle数据库最少使用3个日志文件存放这些信息, 以防写满之后的溢出, 为了防止数据库的灾难性宕机, 日志文件可以提供一个支持, 可以把数据库恢复到宕机之前的某个时间点, 我们也经常对日志文件做一些操作, 常用的操作如下:
1.查询系统使用的是哪一组日志文件：
select * from v$log;

2.查询正在使用的组所对应的日志文件：
select * from v$logfile;

3.强制日志切换：
alter system switch logfile;

4.查询历史日志：
select * from v$log_history;

5.查询日志的归档模式：
select dbid,name,created,log_mode from v$database;

6.查询归档日志的信息：
select recid,stamp,thread#,sequence#,name from v$archived_log;

7.增加与删除日志文件组
alter database add logfile group 1 ('/home1/oracle/oradata/ora8i/log1a.log'),'/home2/oracle/oradata/ora8i/log1b.log') size 100M;

alter database drop logfile group 1;

8.增加与删除日志成员
alter database add logfile member '/home1/oracle/oradata/ora8i/log1a.log' to group 1,'/home1/oracle/oradata/ora8i/log2a.log' to group 2;

alter database drop logfile member '/home1/oracle/oradata/ora8i/log1a.log' ;

9.日志文件移动
alter database rename file '/home1/oracle/oradata/ora8i/log1a.log' to '/home2/oracle/oradata/ora8i/log1a.log';
执行该命令之前必须保证该日志文件物理上已经移动到新目录

10.清除日志文件
alter database clear logfile '/home1/oracle/oradata/ora8i/log1a.log';
该命令不能用删除组及组成员命令删除日志时使用

㈨ 如何正确删除ORACLE归档日志文件

一、首先删除归档日志物理文件，归档日志一般都是位于archive目录下，AIX系统下文件格式为“1_17884_667758186.dbf”，建议操作前先对数据库进行备份，删除时至少保留最近几天的日志用于数据库恢复。

二、把归档日志的物理文件删除后，我们就可以正常登入ORACLE了，但是还没完全把归档日志删除干净，ORACLE的controlfile中仍然记录着这些archivelog的信息，在oracle的OEM管理器中有可视化的日志展现出，当我们手工清除archive目录下的文件后，这些记录并没有被我们从controlfile中清除掉，接下去我们要做的就是这个工作。
我们利用RMAN进行删除操作，操作步骤如下：(window客户端系统为例)
1.指定数据库实例
C:/Documents and Settings/Administrator>SET ORACLE_SID =orcl
2.连接数据库
C:/Documents and Settings/Administrator>RMAN TARGET SYS/sysadmin@orcl
3.查看归档日志的状态
RMAN> list archivelog all;
4.手工删除归档日志文件
RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
说明：
SYSDATA-7，表明当前的系统时间7天前，before关键字表示在7天前的归档日志，如果使用了闪回功能，也会删除闪回的数据。
同样道理，也可以删除从7天前到现在的全部日志，不过这个命令要考虑清楚，做完这个删除，最好马上进行全备份数据库
DELETE ARCHIVELOG from TIME 'SYSDATE-7'; 删除从7天前到现在的全部日志,慎用
UNIX/LINUX下也可以通过FIND找到7天前的归档数据，使用EXEC子操作删除
find /oraarchive -xdev -mtime +7 -name "*.dbf" -exec rm -f {} ;
这样做仍然会在RMAN里留下未管理的归档文件
仍需要在RMAN里执行下面2条命令
crosscheck archivelog all;
delete expired archivelog all;
所以还不如上面的方法好用，不过用FIND的好处就是，可以在条件上，和EXEC子项上做很多操作，实现更复杂的功能
5.退出rman
RMAN> exit

㈩ Oracle数据库由哪几种文件组成

Oracle数据库由数据库文件、日志文件、控制文件组成。

Oracle数据库12c引入了一个新的多承租方架构，使用该架构可轻松部署和管理数据库云。此外，一些创新特性可最大限度地提高资源使用率和灵活性，如Oracle Multitenant可快速整合多个数据库，而Automatic Data Optimization和Heat Map能以更高的密度压缩数据和对数据分层。

这些独一无二的技术进步再加上在可用性、安全性和大数据支持方面的主要增强，使得Oracle数据库12c成为私有云和公有云部署的理想平台。

(10)oracle数据库的日志文件扩展阅读：

Oracle数据库升级注意事项：

1、备份配置参数

数据库升级前的配置参数要备份，如PGA大小。这样数据库升级后还可以升级前的配置，而不至于使用安装升级时的默认配置。

2、检查版本兼容

确认数据库升级后是否对生产环境上的代码有影响，如果发现一处有影响，则要在全部范围内检查类似的情况。

3、客户端同步升级

同时升级开发者本地环境或应用程序的数据库客户端升级到与数据库服务器相同版本。

4、确保程序正常运行

数据库升级后确保升级后的数据库不会对连接该库的应用程序有影响。