查归档日志文件每小时生成量

合集下载

oracle 归档日志文件路径设置

oracle 归档日志文件路径设置

oracle 归档日志文件路径设置2012-05-23 15:37:42| 分类:oracle | 标签:oracle log_archive_dest |举报|字号订阅1:首先查看是否是归档模式运行archive log list 命令(必须以sys身份运行)运行结果如下;2:通过上面的信息可以看出已经是归档模式了(如果是非归档模式参考博主的另一篇文章有关“归档日志与非归档日志切换”), 查看归档日志文件存放在哪个位置运行show parameter log_archive_dest 命令运行结果如下;3: 在上面的信息中可以看到,log_archive_dest 的路径为空,我们可以设置这个路径来存放归档日志文件,运行alter systemset log_archive_dest='d:/xxx/xxx' scope=spfile;(xxx代表存放路径,最好指定scope=spfile 否则的话重启db,则配置不会生效); 运行结果会出现在如下错误:第1 行出现错误:ORA-02097: 无法修改参数, 因为指定的值无效ORA-16018: 无法将LOG_ARCHIVE_DEST 与LOG_ARCHIVE_DEST_n或DB_RECOVERY_FILE_DEST 一起使用出现错误的原因是db_recovery_file_dest的参数已经被设置了,去查询一下看看,果真如此。

4: 查看db_recovery_file_dest 参数设置,运行showparameter db_recovery_file_dest 命令运行结果如下;可以看到已经默认设置了归档的路径。

5:db_recovery_file_dest是缺省的归档位置,下面把它设置为"空",然后设置log_archive_dest参数,指定另外一个非缺省的参数重启db 如下图运行shutdown immediate;运行startup mount;运行alter database open;运行show parameter db_recovery_file_dest 查看是否已经设置为空运行结果如下图可以看到已经设置为空下面接着使用alter system set log_archive_dest='xxxxxx' scope = spfile 设置归档日志文件路径运行结果如下图运行show parameter log_archive_dest 命令查看归档日志文件路径是否已经设置成功运行结果如下图可以看到已经设置成功执行alter system archive log current 命令进行手动归档运行结果如下查看归档日志文件,看看是否已经进行归档运行命令select name,completion_time from v$archived_log; 结果如下可以看到在些文件夹下面生成了归档日志文件。

数据库归档管理

数据库归档管理

数据库归档1、查看、更改归档路径在ORACLE10G中,默认的归档路径为$ORACLE_BASE/flash_recovery_area。

对于这个路径,ORACLE有一个限制,就是默认只能有2G的空间给归档日志使用,可以使用下面两个SQL语句去查看它的限制select * from v$recovery_file_dest;show parameter db_recovery_file_dest(这个更友好直观一些)当归档日志数量大于2G时,那么就会由于没有更多的空间去容纳更多的归档日志会报无法继续归档的错误。

如:RA-19809: limit exceeded for recovery filesORA-19804: cannot reclaim 10017792 bytes disk space from 2147483648 limitARC0: Error 19809 Creating archive log file to'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2007_04_30/o1_mf_1_220_ 0_.arc'这时我们可以修改它的默认限制,比如说将它增加到5G或更多,也可以将归档路径重新置到别的路径,就不会有这个限制了。

更改限制语句如下:alter system set db_recovery_file_dest_size=5368709102;或者直接修改归档的路径即可alter system set log_archive_dest_1='location=/u01/archivelog' scope =both;2、修改归档模式sql> archive log list;sql> shutdown immediate;sql> startup mount;sql> alter database archivelog;alter database noarchivelogsql> alter database open;sql> archive log list;3、确认归档是否生效alter system switch logfile;看对应的归档位置时候有archivelog产生。

Oracle归档日志文件

Oracle归档日志文件

Oracle归档⽇志⽂件今天数据群有⼈反应⽹站不能正常打开,经检查Oracle数据库远程连不上,提⽰信息:ORA-00257: archiver error. Connect internal only, until freed。

可能是archivelog满了。

以前学习SQL只关注CRUD,对⽇志了解甚少,此次宕机虽然对⽣成没有造成恶劣影响,但也是因为业务不熟悉所致,特花⼀天时间学习并记录Oracle⽇志归档功能。

.以下内容针对没有使⽤Oracle ASM磁盘组情况,使⽤了Oracle ASM磁盘组的情况以后分析。

Oracle⽇志操作模式分为两种:ARCHIVELOG、NOARCHIVELOG连接Oracle终端windows系统:sqlplusLinux系统:先登录ssh,切换到oracle⽤户,再启动sqlplus登录oracle查看当前⽇志操作模式通⽤⽅法:SELECT log_mode from v$database;sys⽤户:开启⽇志归档启⽤归档⽇志前要先停⽌数据库shutdown immediate;数据库以mount⽅式启动startup mount;改变⽇志模式启⽤数据库归档alter database archivelog;关闭归档alter database noarchivelog;打开数据库alter database open;查看归档⽇志信息archive log list;查看默认闪回归档存储路径show parameter db_recovery_file_dest;Oracle11g版本,ORACLE默认的⽇志归档路径为闪回恢复区($ORACLE_BASE/fast_recovery_area)。

对于这个路径,Oracle有⼀个限制,就是默认只有4G的空间,⽽且不只是归档⽇志的默认路径,也是备份⽂件和闪回⽇志的默认地址,这样的话归档⽇志锁使⽤的空间就达不到4G。

查询oracle归档空间利用率 -回复

查询oracle归档空间利用率 -回复

查询oracle归档空间利用率-回复题目:查询Oracle归档空间利用率导语:Oracle数据库的归档空间是用于存储已完成的日志文件(也称为归档日志)的地方。

归档日志是在正常事务提交后自动生成的,以确保数据的完整性和恢复性。

在长时间运行的数据库中,归档空间可能会占用大量的磁盘空间,因此了解归档空间的利用率对数据库管理员来说至关重要。

本文将介绍如何查询Oracle归档空间的利用率。

第一步:查询数据库的归档模式在Oracle数据库中,归档模式有两种:归档模式(ARCHIVELOG)和非归档模式(NOARCHIVELOG)。

归档模式将数据库的日志文件保存到归档目录中,而非归档模式则不执行该操作。

要查询数据库的归档模式,可以使用以下SQL查询:SELECT log_mode FROM vdatabase;当结果为`ARCHIVELOG`时,表示数据库处于归档模式。

当结果为`NOARCHIVELOG`时,表示数据库处于非归档模式。

第二步:查询数据库的归档日志目录如果数据库处于归档模式,归档日志文件将存储在归档日志目录中。

要查询数据库的归档日志目录,可以使用以下SQL查询:SELECT value FROM vparameter WHERE name ='log_archive_dest_1';查询结果将显示归档日志目录的路径。

这个路径可以是文件系统路径或ASM路径,具体取决于数据库的配置。

第三步:查询归档日志文件的利用率要查询归档日志文件的利用率,可以使用以下SQL查询:SELECT (SUM(blocks) * (SELECT block_size FROM vdatabase)) / (1024 * 1024) AS total_size_mb,(SUM(blocks) - SUM(blocks_remaining)) * (SELECTblock_size FROM vdatabase) / (1024 * 1024) AS used_size_mb, SUM(blocks_remaining) * (SELECT block_size FROMvdatabase) / (1024 * 1024) AS remaining_size_mb,(SUM(blocks) - SUM(blocks_remaining)) / SUM(blocks) * 100 AS used_percentageFROM varchived_log;该查询将返回归档日志文件的总大小、已使用大小、剩余大小和利用率百分比。

timebasedrollingpolicy原理详解_理论说明

timebasedrollingpolicy原理详解_理论说明

timebasedrollingpolicy原理详解理论说明1. 引言1.1 概述在计算机科学领域,日志记录是我们追踪和排查软件运行问题的重要手段。

而时间滚动策略(Time-based Rolling Policy)作为一种常用的日志管理机制,在日志记录中扮演着重要角色。

该策略允许我们根据一定的时间规则对日志文件进行滚动,从而有效地管理和维护大量的日志数据。

1.2 文章结构本文将详细介绍timebasedrollingpolicy原理,旨在帮助读者全面了解这一策略的基本原理、作用以及具体实现步骤。

首先,我们将从基本原理入手,深入探讨timebasedrollingpolicy是如何实现日志文件滚动管理的。

接着,我们将说明时间滚动策略在日志管理中的应用场景和优势,并通过具体实例分析进一步加深对其工作原理的理解。

1.3 目的本文旨在帮助读者深入了解timebasedrollingpolicy原理,并清晰地展示其在实际场景中的应用及潜在价值。

通过阅读本文,读者将能够全面把握这一策略的核心概念,并了解到使用timebasedrollingpolicy管理日志文件所带来的实际益处。

此外,我们还将探讨未来发展方向和趋势,为读者提供进一步研究的参考。

2. timebasedrollingpolicy原理详解:2.1 基本原理:timebasedrollingpolicy是一种日志框架中的滚动策略,它可以根据设定的时间间隔来自动进行日志文件的滚动。

该策略基于时间对日志文件进行切割和命名,以便实现更高效地管理和存储大量的日志数据。

2.2 时间滚动策略的作用:时间滚动策略在日志管理中起到重要作用。

通过按照时间周期性地切分日志文件,可以将不同时间段产生的日志记录归类整理,方便查阅和分析。

同时,将过多的日志记录分散到多个小文件中,有助于降低单个文件过大带来的读写效率问题。

2.3 实现步骤:在实现timebasedrollingpolicy时,首先需要设置一个合适的时间间隔参数,例如按天、小时或分钟等单位来切分新的日志文件。

logread命令用法

logread命令用法

logread命令用法logread命令用法详解引言:在计算机系统中,日志文件是记录系统运行情况、错误信息和其他重要事件的重要工具。

通过阅读和分析日志文件,我们可以了解系统的运行状态,及时发现和解决问题。

在Linux系统中,logread命令是一个强大的工具,可以用于查看和分析系统日志文件。

本文将详细介绍logread命令的用法,帮助读者更好地理解和使用该命令。

一、logread命令概述logread命令是OpenWrt系统中的一个常用命令,用于查看和分析系统日志文件。

它可以显示系统日志文件的内容,并提供一些选项用于过滤和定制显示结果。

logread命令的基本用法如下:logread [选项]通过运行logread命令,我们可以查看系统日志文件的最新内容。

下面将详细介绍logread命令的各个选项和用法。

二、logread命令选项解析1. -h, help该选项用于显示logread命令的帮助信息。

运行logread -h命令即可查看详细的用法说明和选项解析。

2. -f, follow使用该选项可以实现实时跟踪日志文件。

logread -f命令会持续显示新的日志内容,并在有新的日志写入时自动滚屏。

这个选项在查找和应对系统问题时非常有用。

3. -n, lines通过该选项可以指定显示日志文件的行数。

logread -n 20命令将显示日志文件的最后20行内容。

我们可以根据实际需要设置显示行数。

4. -m, regex通过该选项可以使用正则表达式来过滤日志文件的内容。

logread -m "error"命令将显示所有包含"error"关键词的日志。

5. -p, period该选项用于指定显示日志文件的时间范围。

logread -p "2022-01-01 00:00:00,2022-12-31 23:59:59"命令将显示指定时间范围内的日志。

GoldenGateOGGORACLE数据复制实施方案

GoldenGateOGGORACLE数据复制实施方案

GoldenGateOGGORACLE数据复制实施⽅案GoldenGate OGG ORACLE数据复制实施⽅案2013/05/03 BY1 ORACLE数据复制⽅案环境要求1.1 操作系统环境要求1.1.1 磁盘要求数据库为集群⽅式。

要安装Oracle GoldenGate ⼆进制⽂件和其他⽂件到共享阵列。

数据库为主备HA⽅式。

要安装Oracle GoldenGate ⼆进制⽂件和其他⽂件到共享阵列。

复制软件本⾝的⼤⼩为200 MB左右。

为Oracle GoldenGate trails分配⾜够的磁盘空间,⼀般与GoldenGate分配到同⼀⽂件系统。

这些trails⽂件占⽤的磁盘空间依赖于处理的数据量⼤⼩,根据Trail⽂件的保存期限进⾏设置。

说明如下:Trail⽂件可以位于Oracle GoldenGate安装的本地驱动器上,它们也可以位于NAS或者SAN设备上。

对于存储在源端的那些trails⽂件,应该有⾜够的空间处理⽹络连接失败时的数据累积。

在典型配置下,第⼆个extract进程(data pump)通过⽹络从本地trail发送数据,当⽹络连接中断,发送将失败。

然⽽,读事务⽇志并且写到本地trail的主extract进程将继续。

这个extract进程不应该因失败⽽停⽌,因此应该有⾜够的磁盘空间来容纳数据累积。

在⽬标端的安装位置与空间建议与源端相同。

估算trail需要的空间的⽅法1. 估算⽹络不可⽤的最长时间。

2. 估算商业应⽤程序每⼩时⽣成多少事务⽇志。

3. 使⽤下⾯的公式计算需要的磁盘空间[每⼩时的⽇志量] x [宕机⼩时数] x .4 = trail需要的磁盘空间这个等式使⽤百分之四⼗是因为Oracle GoldenGate⼤约只需要⼀个事务⽇志中百分之四⼗的数据。

注意:这个公式只是⼀个保守的估算,应该在配置好Oracle GoldenGate后,做测试来决定trail⽂件需要的准确空间。

Oracle导致Redo日志暴增的SQL语句排查

Oracle导致Redo日志暴增的SQL语句排查

Oracle导致Redo⽇志暴增的SQL语句排查⼀、概述最近数据库频繁不定时的报出⼀些耗时长的SQL,甚⾄SQL执⾏时间过长,导致连接断开现象。

下⾯是⼀些排查思路。

⼆、查询⽇志的⼤⼩,⽇志组情况SELECT L.GROUP#,LF.MEMBER,L.ARCHIVED,L.BYTES /1024/1024 "SIZE(M)",L.MEMBERSFROM V$LOG L,V$LOGFILE LFWHERE L.GROUP# = LF.GROUP#;查询结果:从上图可以看出⽬前共分为10个⽇志组,每个⽇志组2个⽂件,每个⽂件⼤⼩为3G。

三、查询Oracle最近⼏天每⼩时归档⽇志产⽣数量SELECT SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH:MI:SS'), 1, 5) Day,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '00', 1, 0)) H00,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '01', 1, 0)) H01,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '02', 1, 0)) H02,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '03', 1, 0)) H03,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '04', 1, 0)) H04,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '05', 1, 0)) H05,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '06', 1, 0)) H06,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '07', 1, 0)) H07,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '08', 1, 0)) H08,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '09', 1, 0)) H09,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '10', 1, 0)) H10,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '11', 1, 0)) H11,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '12', 1, 0)) H12,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '13', 1, 0)) H13,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '14', 1, 0)) H14,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '15', 1, 0)) H15,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '16', 1, 0)) H16,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '17', 1, 0)) H17,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '18', 1, 0)) H18,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '19', 1, 0)) H19,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '20', 1, 0)) H20,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '21', 1, 0)) H21,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '22', 1, 0)) H22,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '23', 1, 0)) H23,COUNT(*) TOTALFROM v$log_history aWHERE first_time >= to_char(sysdate -10)GROUP BY SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH:MI:SS'), 1, 5)ORDER BY SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH:MI:SS'), 1, 5) DESC;查询结果从上图可以看出业务⾼峰期每⼩时产⽣40个⽇志⽂件左右(⽬前设定的每个⽇志⽂件⼤⼩为3G),平均1.5分钟产⽣⼀个3G的⽇志⽂件。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

在O racle数据库中,通过v$archived_log数据字典视图查询该数据库的归档日志文件的生成情况。

如果你以为在rac下需要查的gv$archvied_log视图,这其实是一个错误的想法。

无论在单实例数据库,还是多实例的RAC数据库,都是查这个视图来获取信息。

查当天每小时的归档日志生成量
select logtime,
count(*),
round(sum(blocks * block_size) / 1024 / 1024) mbsize
from (select trunc(first_time, 'hh') as logtime, a.BLOCKS, a.BLOCK_SIZE from v$archived_log a
where a.DEST_ID = 1
and a.FIRST_TIME > trunc(sysdate))
group by logtime
order by logtime desc;
查最近一周每天的归档日志生成量
select logtime,
count(*),
round(sum(blocks * block_size) / 1024 / 1024) mbsize
from (select trunc(first_time, 'dd') as logtime, a.BLOCKS, a.BLOCK_SIZE from v$archived_log a
where a.DEST_ID = 1
and a.FIRST_TIME > trunc(sysdate - 7))
group by logtime
order by logtime desc;
如果你需要知道RAC下各个节点的归档日志情况,我将上面脚本略作修改,增加thread#列。

查当天每小时的各个实例的归档日志生成量
select THREAD#,
logtime,
count(*),
round(sum(blocks * block_size) / 1024 / 1024) mbsize
from (select a.THREAD#,
trunc(first_time, 'hh') as logtime,
a.BLOCKS,
a.BLOCK_SIZE
from v$archived_log a
where a.DEST_ID = 1
and a.FIRST_TIME > trunc(sysdate))
group by THREAD#, logtime
order by THREAD#, logtime desc;
查最近一周每天的各个实例的归档日志生成量
select THREAD#,
logtime,
count(*),
round(sum(blocks * block_size) / 1024 / 1024) mbsize from (select THREAD#,
trunc(first_time, 'dd') as logtime,
a.BLOCKS,
a.BLOCK_SIZE
from v$archived_log a
where a.DEST_ID = 1
and a.FIRST_TIME > trunc(sysdate - 7))
group by THREAD#, logtime
order by THREAD#, logtime desc;。

相关文档
最新文档