归档大小日志计算
oracle 归档日志解析
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 日志归档原理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数据库调整归档日志空间大小
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归档日志大小
1、创建2个新的日志组
alter database add logfile group 4 ('H:\ORACLE\ORADATA\YLZHIS\redo04.log') size 50M;
alter database add logfile group 5 ('H:\ORACLE\ORADATA\YLZHIS\redo05.log') size 50M;
1.alter database drop logfile group 1;
2.alter database drop logfile group 2;
3.alter database drop logfile group 3;
4、操作系统下删除原日志组1、2、3中的文件
2、切换当前日志到新的日志组
1.alter system switch logfile; select * from v$log;可能需要多次执行，确认日志已经切换到4或者5
2.alter system checkpoint;
3、删除旧的日志组
改变归档日志大小只有改变日志组的大小。
方法：加入新的大的日志文件，然后删掉旧的小的日志文件
假设现有三个日志组，每个组内有一个成员，每个成员的大小为1MB，现在想把此三个日志组的成员大小都改为10MB
先查询联机日志文件路径 select * from v$logfile
alter database add logfile group 3 ('H:\ORACLE\ORADATA\YLZHIS\redo03.log') size 50M;
6、切换日志组
1.alter system switch logfile; select * from v$log;可能需要多次执行，确认日志已经切换到4、5、6
查询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;该查询将返回归档日志文件的总大小、已使用大小、剩余大小和利用率百分比。
计算WINCC数据归档和时间的方法
中央存档服务器的硬盘需求由所要求的快速归档，慢速归档和消息归档所需的空间决定。
∙快速归档所要求的空间取决于被存档值的归档设置，数据类型和时间特性。
快速归档的值在数据库中以压缩格式储存，并且每个测量值需要大约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 之前版本。
MQ关于日志的规定
目录结构（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变量归档记录占用的空间
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组态起来还是很方便的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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.小结
为了避免因分配过大的归档日志空间而浪费存储资源，建议对系统运行过程中的归档日志的生成情况做好分析。