归档大小日志计算
- 格式:doc
- 大小:17.50 KB
- 文档页数:2
oracle 归档日志解析摘要:一、归档日志概述二、归档日志的作用三、归档日志的解析方法四、归档日志解析的应用场景五、总结与建议正文:随着大数据时代的到来,Oracle 数据库归档日志在各行各业中发挥着越来越重要的作用。
本文将对归档日志进行简要概述,分析其作用,介绍解析方法,并讨论应用场景。
最后给出总结与建议。
一、归档日志概述Oracle 归档日志(Archive Log)是一种用于记录数据库事务日志的技术。
它可以将数据库中的更改操作(如插入、更新和删除)记录下来,以便在出现故障时恢复数据。
归档日志采用增量方式记录,即每次更改操作后,日志文件会逐步变大。
二、归档日志的作用1.数据恢复:归档日志可以在数据库发生故障时,用于恢复数据至故障发生前的状态。
2.数据审计:归档日志可以记录所有对数据库的更改操作,方便审计人员追溯和分析数据变更原因。
3.性能优化:通过分析归档日志,可以找出数据库性能瓶颈,为优化数据库性能提供依据。
三、归档日志解析方法1.手工解析:通过编写SQL 语句或使用第三方工具,查询归档日志文件内容,分析日志中的数据。
2.使用Oracle 提供的事件解析工具:如DBMS_LOGSTD.REPORT 等,可以方便地生成归档日志的报表和统计数据。
3.使用第三方归档日志分析工具:如Oracle 的Partner 产品OraInsight 等,可以提供更丰富的归档日志分析功能。
四、归档日志解析的应用场景1.数据库故障排查:通过分析归档日志,可以找出导致数据库故障的原因,快速恢复业务。
2.性能监控与优化:分析归档日志中的SQL 语句执行情况,找出性能瓶颈,优化数据库性能。
3.数据审计与追溯:归档日志可以记录所有数据变更操作,方便审计人员分析和追溯数据变更原因。
4.数据库安全分析:通过分析归档日志,可以监控数据库访问权限和操作,提高数据库安全。
五、总结与建议归档日志在数据库管理中具有重要意义。
对于数据库管理员而言,应充分利用归档日志进行故障排查、性能优化和数据审计等工作。
oracle 日志归档原理Oracle数据库日志归档(Archive Log Mode)是数据库管理系统中用于实现数据库可恢复性的重要机制。
在归档模式下,Oracle数据库会将已填满的联机重做日志文件的内容复制到单独的归档日志文件中,并且只有在当前的日志内容被安全地归档后,才会覆盖或重新使用这些联机重做日志。
以下是Oracle日志归档的基本原理:1.联机重做日志:•Oracle数据库运行时会产生一系列的联机重做日志文件(Online Redo Logs),这些文件按照日志组的方式组织,每个日志组内包含一个或多个日志成员。
•当数据库执行事务处理时,所有对数据库的修改都会以重做记录的形式写入当前活动的日志组中。
2.日志切换:•随着数据库操作的进行,当前日志组填满后,会触发日志切换(Log Switch),即系统开始往下一个日志组中写入新的重做记录。
•在非归档模式下,旧的日志组可以被覆盖和重复使用;而在归档模式下,必须先将旧日志组的内容归档才能进行切换。
3.归档过程:•归档是由后台进程ARCn (Archiver) 自动完成的,或者管理员可以通过手动方式将填满的联机重做日志文件复制到指定的归档位置。
•归档日志文件具有与原始联机日志相同的逻辑内容,并带有唯一的日志序列号(Log Sequence Number, LSN),以便在恢复过程中确定应用重做记录的顺序。
4.作用:•在发生故障需要恢复数据库时,通过应用归档日志中的重做记录,可以将数据库状态恢复到故障发生前的任意时间点(Point-in-Time Recovery, PITR)。
•对于数据库镜像、数据保护以及维护高可用性环境如Data Guard(物理/逻辑standby数据库)也是至关重要的。
ORACLE数据库归档日志满后造成无法启动/连接的处理方法在\app\Administrator\diag\rdbms\orcl\orcl\trace(其中orcl根据具体的数据库实例名称而定)路径下的log中可以看到以下信息:ORA-19815: W ARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.Wed Jan 9 15:00:29 2013************************************************************************You have following choices to free up space from flash recovery area:1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,then consider changing RMAN ARCHIVELOG DELETION POLICY.2. Back up files to tertiary device such as tape using RMANBACKUP RECOVERY AREA command.3. Add disk space and increase db_recovery_file_dest_size parameter toreflect the new space.4. Delete unnecessary files using RMAN DELETE command. If an operatingsystem command was used to delete files, then use RMAN CROSSCHECK andDELETE EXPIRED commands.ORA-19815: W ARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.这句日志意思是db_recovery_file_dest_size已经满了,导致数据库无法启动。
查询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;该查询将返回归档日志文件的总大小、已使用大小、剩余大小和利用率百分比。
中央存档服务器的硬盘需求由所要求的快速归档,慢速归档和消息归档所需的空间决定。
∙快速归档所要求的空间取决于被存档值的归档设置,数据类型和时间特性。
快速归档的值在数据库中以压缩格式储存,并且每个测量值需要大约10 到15 个字节。
在一些情况下可用更高的压缩比。
∙慢速归档的每个测量值占32 个字节。
∙一条带有最大数目过程值变量及注释的消息需要4 KB 的存储空间。
一条最小值的消息需要172 字节的存储空间。
计算:您可以通过以下公式来计算每秒所需要的最大存储空间:存储空间需求[字节/秒] = x * 15 字节/值+ y * 32 字节/值+ z * 4096 字节/值在这:x: 每秒快速归档值的平均个数y: 每秒慢速归档值的平均个数z: 每秒消息的平均个数为计算n天所需的空间,您只需将“存储空间需求[字节/秒]”的结果乘以n 天所折算成的秒数。
计算实例:以下为假设:假设描述No.每秒快速归档值的数量1 x = 10,000 值/秒每秒慢速归档值的数量2 y = 10 值/秒3 z = 2 值/秒每秒2 个消息4 n =5 天数,在这1 天= 24 * 3600 秒=86400 秒5 天所需存储空间字节数= 5 * 86400 秒* (10,000 值/秒* 15 字节/值+ 10 值/秒* 32 字节/值+ 2 值/秒* 4096 字节/值)5 天所需存储空间字节数= 5 * 86400 秒* (150,000 字节/秒+ 320 字节/秒+ 8192 字节/秒)5 天所需存储空间字节数= 5 * 86400 秒* (158,512 字节/秒)5 天所需存储空间字节数= 68,477,184,000 字节转换为GB :5 天所需存储空间GB = 68,477,184,000 字节/ (1024 * 1024 * 1024 )= 63.774 GB5 天所需存储空间GB ≈ 64 GB从WinCC V6.2 开始:以上展示的计算应用于WinCC V6.2 之前版本。
目录结构(UNIX 系统)MQSeries 系统管理附录 B. 目录结构(UNIX 系统)图64显示了与特定队列管理器关联的数据和日志目录的一般布局。
所示的目录适用于缺省安装。
如果对它作更改,那么文件和目录的位置将相应作修改。
有关产品文件的位置信息,请参阅以下之一:∙Chapter 3. "Installing the MQSeries for AIX Server"在MQSeries AIX 版V5.1 快速入门一书中∙Chapter 3. "Installing the MQSeries for HP-UX Server"在MQSeries HP-UX 版V5.1 快速入门一书中∙Chapter 3. "Installing the MQSeries for Sun Solaris Server"在MQSeries Sun Solaris 版V5.1 快速入门一书中图64. 启动队列管理器后的缺省目录结构(UNIX 系统)在图64中,该布局代表了队列管理器已使用一段时间后的MQSeries。
您所拥有的实际结构取决于队列管理器上已执行了哪些操作。
在缺省情况下,下列目录和文件位于目录/var/mqm/qmgrs/qmname/ 中。
amqalchk.fil包含有关上一个检查点的信息的检查点文件。
auth/该目录包含了与权限关联的子目录和文件。
@MANGLED该文件包含了用于所有各类的权限节。
procdef/该目录对每个进程定义包含了一个文件。
每个文件包含了用于关联的进程定义的权限节。
@MANGLED该文件包含了用于进程定义类的权限节。
qmanager/@MANGLED该文件包含了用于队列管理器类的权限节。
self该文件包含了用于队列管理器对象的权限节。
queues/该目录对每个队列都包含了一个文件。
每个文件包含了用于关联队列的权限节。
@MANGLED该文件包含了用于队列类的权限节。
WinCC变量归档记录占用的空间计算例子A、慢速归档时一条变量归档记录占用32 字节的空间,每个变量以2 分钟为归档周期,一周之内会产生5040 条记录,若有5000 个变量的归档,则单个数据片段的大小计算为:32×5000×5040=806400000 byte ==> 约等于800MB考虑到留出20%的余量,设定单个数据片段为1G所有数据归档期限是两个月,因此所有段的尺寸为单个片段尺寸乘以单个片段的个数,即:1GB×9=9GBB、快速归档时一条变量归档记录占用3 字节的空间,每个变量以2 秒钟为归档周期,一周之内会产生302400 条记录,若有50 个变量的归档,则单个数据片段的大小计算为:3×50×302400=45360000 byte ==> 约等于46MB考虑到留出20%的余量,设定单个数据片段为60MB所有数据归档期限是两个月,因此所有段的尺寸为单个片段尺寸乘以单个片段的个数,即:60MB×9=540MB 片段大小再taglogging里的快速归档变量和慢速归档变量里设置从 WinCC V6.2 之后,其他的计算比旧版本更容易,因为所有数据都是以压缩的形式存在的。
快速归档所要求的空间取决于被存档值的归档设置,数据类型和时间特性。
快速归档的值在数据库中以压缩格式储存,并且每个测量值需要大约 10 到 15 个字节。
在一些情况下可用更高的压缩比。
因此,以上的计算列表可以提供一个粗略的估算。
然而,压缩的处理意味着没有一种简单的方法来准确地算出所需空间从 WinCC V6.2 以后。
1. HORN编辑器中有两个选项页,第一页指定报警类型(至于是否确认,那要看你的要求了)和报警TAG,也就是要指定TAG的报警类型;2.第二页指定报警声音,也就是报警TAG对应相应的报警声音,这个声音文件是WAV类型的;3.HORN组态起来还是很方便的。
Db2数据库归档日志频繁解决方法问题现象:数据库dbbde执行命令:Db2 db2stop forceDb2 db2start运行一段时间后发现,归档日志目录中日志增长很快,日志个数很多,但是日志均未写满。
每个日志只有约3M.如图S0224497.LOG-S0*******.LOG查看实际配置Log file size (4KB) (LOGFILSIZ) = 10000Number of primary log files (LOGPRIMARY) = 10Number of secondary log files (LOGSECOND) = 20一个归档日志的大小为:4KB*10000=40M 由配置看归档日志大小正常,则可能是犹豫数据库提交事物过于频繁导致归档频率加快。
解决方法:db2 activate database dbbde归档日志恢复正常。
整理:由activate database命令初始化的数据库可以由deactivate database命令关闭,也可以通过stop database manager(或db2stop)命令关闭。
如果使用activate database命令初始化一个数据库,那么最后一个与数据库断开连接的应用就不会关闭数据库。
由于命令db2stop关闭了数据库实例,重新启动数据库没有进行激活操作activate会导致每一个连接断开后会提交事物并归档,导致了日志归档频率大的问题。
同时,如果在database没有激活之前,就在应用中使用connect to database_name或隐式连接,那么应用就必须要进行等待,直到数据库管理器启动了你要连接的数据库。
一般第一个应用会引发等待数据库管理器执行数据库启动的所有开销。
可以使用activate database database_name这样的命令启动特定的数据库。
这个命令就会免除第一个应用程序连接上来的时候等候数据库初始化所花费的时间。
oracle 归档日志概念解释在Oracle数据库中,归档日志(Archived Logs)是一种重要的数据库日志,用于记录数据库发生的所有变更操作,以便在系统故障或数据损坏时进行数据库恢复。
以下是有关归档日志的一些关键概念和解释:1. 日志文件:Oracle数据库通过日志文件(Redo Log)记录所有对数据库的变更操作。
这包括插入、更新和删除操作。
日志文件的作用是保留数据库的变更历史,以便在需要时进行恢复。
2. 在线日志和归档日志:日志文件分为在线日志和归档日志两种类型。
在线日志包含当前正在进行的事务的日志信息,而归档日志包含已经完成的事务的日志信息。
当在线日志满了或发生特定的切换事件时,其中的日志会被归档到归档目录中。
3. 归档目录:归档日志被存储在一个被称为归档目录(Archive Destination)的特定位置。
这可以是本地磁盘、网络位置或远程服务器。
在配置归档目录时,确保有足够的磁盘空间存储归档日志,因为这对数据库的正常运行和故障恢复至关重要。
4. 日志切换:当在线日志文件满了或发生某些事件时,数据库会执行一个日志切换(Log Switch)。
这时,当前的在线日志文件会被标记为不可用,并且一个新的在线日志文件会开始记录新的变更。
同时,旧的在线日志文件会被归档。
5. 数据库恢复:归档日志对数据库的恢复非常关键。
如果数据库发生故障,系统可以利用归档日志中的信息,从最后一个完整备份以来的任何时间点将数据库还原到一致的状态。
这种恢复过程称为“介质恢复”(Media Recovery)。
总的来说,归档日志是Oracle数据库中一项关键的功能,它确保了数据库的可靠性和一致性,同时提供了故障恢复的能力。
redo日志切换频率推算出存放归档日志所需的空间
我们可以通过日志切换频率推算出存放归档日志所需的空间,这样对存储规划有很好的指导意义。
可以按照如下步骤完成归档日志空间规划预估任务。
1.查看数据库日志文件的大小
sys@bomsdb> select distinct(bytes/1024/1024) MB from v$log;
MB
----------
200
如果上面的查询返回不止一条,说明你的系统中存在不同大小的redo log。
应该强烈抵制这种事情的发生。
确保数据库具有相同大小的redo log,便于管理和使用。
2.查询获得系统归档日志的切换频率及大小
sys@bomsdb> select max (first_time) max_first_time,
2 to_char (first_time, 'yyyy-mm-dd') day,
3 count (recid) count_number,
4 count (recid) * 200 size_mb
5 from v$log_history
6 group by to_char (first_time, 'yyyy-mm-dd')
7 order by 1
8 /
MAX_FIRST_TIME DAY COUNT_NUMBER SIZE_MB
-------------- ---------- ------------ ----------
20 2010-12-24 40 8000
20 2010-12-25 50 10000
20 2010-12-26 45 9000
20 2010-12-27 46 9200
20 2010-12-28 44 8800
20 2010-12-29 46 9200
20 2010-12-30 47 9400
20 2010-12-31 45 9000
20 2011-01-01 47 9400
20 2011-01-02 44 8800
20 2011-01-03 48 9600
20 2011-01-04 53 10600
20 2011-01-05 45 9000
20 2011-01-06 52 10400
20 2011-01-07 48 9600
20 2011-01-08 52 10400
20 2011-01-09 49 9800
20 2011-01-10 50 10000
20 2011-01-11 46 9200
20 2011-01-12 52 10400
20 2011-01-13 53 10600
20 2011-01-14 48 9600
20 2011-01-15 51 10200
20 2011-01-16 49 9800
24 rows selected.
从上面的统计结果可以知道,每天的归档情况比较一致,说明业务的压力比较平均。
平均每天会完成45次日志切换,生成10G大小的归档日志。
不同业务类型的归档日志生成的频率和规律并不相同。
如果您的系统中个别几天会运行大批量的Batch任务很有可能出现突发的归档日志的需求。
3.计算获得存放归档日志的需求
为安全起见,每天生成归档日志大小的20%作为冗余。
就本系统来说存放每天的归档日志的总空间需求便是10+10*20%=12G。
既然知道了每天需要归档存放空间的大小,因此便可以根据不同的备份恢复策略得到最后的空间需求。
因为系统每周都会使用RMAN完成数据库的全备份,因此仅需保留一周的归档日志即可。
因此最后的归档日志的空间需求大小是12*7=84G。
对于具有批处理业务的系统需要考虑峰值带来的影响。
不过只要按照这个原则来计算,都可以找到一个比较合理的归档日志空间需求。
4.小结
为了避免因分配过大的归档日志空间而浪费存储资源,建议对系统运行过程中的归档日志的生成情况做好分析。