怎么分析 oracle 归档日志

Posted 2023-04-18

　　环境：
　　AIX6.1
　　Oracle 11g RAC
　　故障：
　　数据库频繁出现归档日志空间不够，导致数据库无法登陆的故障。一查发现原因是归档日志切换频繁，操作系统空间不够。
　　确定原因：
　　[aix01@oracle]/oracle>df -g
　　Filesystem GB blocks Free %Used Iused %Iused Mounted on
　　/dev/hd4 0.50 0.28 44% 13674 17% /
　　/dev/hd2 3.00 0.67 78% 49208 23% /usr
　　/dev/hd9var 1.00 0.37 63% 9285 10% /var
　　/dev/hd3 2.00 1.03 49% 2407 1% /tmp
　　/dev/fwdump 1.00 0.99 2% 30 1% /var/adm/ras/platform
　　/dev/hd1 0.25 0.18 28% 465 2% /home
　　/dev/hd11admin 0.25 0.25 1% 5 1% /admin
　　/proc - - - - - /proc
　　/dev/hd10opt 0.50 0.28 44% 10241 14% /opt
　　/dev/livedump 0.25 0.25 1% 12 1% /var/adm/ras/livedump
　　/dev/oraclelv 30.00 11.29 63% 161681 6% /oracle
　　/dev/installlv 15.00 3.38 78% 6478 1% /install
　　/dev/crslv 10.00 3.35 67% 7807 1% /crs
　　/dev/wmsapplv 30.00 17.49 42% 15537 1% /wmprod
　　/dev/archivelv 29.25 29.25 1% 4 1% /arch1
　　/dev/backuplv 400.00 107.13 74% 306 1% /sysbackup
　　aix02:arch2 30.25 0.64 99% 3 1% /arch2
　　可以看到，/arch2里文件系统空间已经达到99%，/arch2是用来存放归档日志的文件系统，进而导致数据库出错。
　　提出问题：
　　这下问题来了，/arch2的空间是30G，每天备份脚本都会自动rman备份归档日志，并自动清除归档日志文件，按照正常情况下，数据库不可能一天产生这么大的归档日志量。
　　如何查询归档日志都是由什么应用产生的，这就是logminer的用途。
　　使用方法：
　　-- 1.指定要分析的日志文件
　　exec sys.dbms_logmnr.add_logfile(logfilename => \'/arch2/2_825_733092736.dbf\',options => dbms_logmnr.new);
　　-- 2.使用本地的在线数据字典分析归档日志
　　exec sys.dbms_logmnr.start_logmnr(options => sys.dbms_logmnr.dict_from_online_catalog);
　　-- 3.查询分析出来的归档日志内容，例如统计最大修改量的Schema
　　select seg_owner,count(*) from v$logmnr_contents group by seg_owner;
　　-- 4.增加别的日志文件
　　exec sys.dbms_logmnr.add_logfile(logfilename=>\'/arch2/2_825_733092736.dbf\');
　　-- 5.结束分析归档日志
　　exec sys.dbms_logmnr.end_logmnr;
　　下面是具体的过程：
　　SQL> exec sys.dbms_logmnr.add_logfile(logfilename => \'/arch2/2_825_733092736.dbf\',options => dbms_logmnr.new);
　　PL/SQL procedure successfully completed
　　SQL> exec sys.dbms_logmnr.start_logmnr(options => sys.dbms_logmnr.dict_from_online_catalog);
　　PL/SQL procedure successfully completed
　　SQL> select seg_owner,count(*) from v$logmnr_contents group by seg_owner;
　　SEG_OWNER COUNT(*)
　　-------------------------------- ----------
　　2237
　　SYS 688
　　TMS 60
　　SPHSY 70
　　SINOSYNEW 30
　　SINOSY 381
　　WAS 4551934
　　7 rows selected
　　SQL> execute dbms_logmnr.end_logmnr ;
　　PL/SQL procedure successfully completed
　　结论：
　　从上面查询结果可以看出操作量最大的用户是WAS用户，再具体看下v$logmnr_contents可以发现基本修改的内容是一致的。
　　与开发人员沟通后，最终确认是一个执行update过程存在问题，where条件未正确定位到记录，每执行一次都会导致大规模的修改数据。 参考技术A 用Logminer分析，可以得到原始的操作SQL语句，想看源代码，百度tomcoding

Oracle Rac数据文件和归档日志文件在ASM磁盘组上出现双份现象分析解决

在给客户做数据迁移之前进行数据库巡检，发现一个原来并没有留意的问题，在数据库里面查询发现数据文件和归档日志文件都为单份，但是通过grid用户进入asmcmd模式下，发现数据文件和归档日志文件都为两份且路径不同，感觉比较奇怪，在这里将现象分析及解决方式进行记录。

为了复现遇见的现象，首先在测试环境下进行归档日志的设置，设置成和生产环境一样的路径参数，发现场景复现，步骤如下：

1、更改数据库归档日志路径

su - oracle

sqlplus / as sysdba

SQL> alter system set log_archive_dest_1=LOCATION=+DATA/arch/ sid=* scope=both;

2、进行归档日志路径查看

SQL> archive log list;

3、查看归档日志路径下的文件

su - grid

asmcmd

asmcmd > cd data/arch

asmcmd > ls -l

asmcmd > cd data/racdb/archivelog/2022_03_10

asmcmd > ls

备注：发现两份竟然是mirror关系，删除arch路径下的归档日志，archivelog路径的的归档日志也会跟着一起自动删除。当切换归档日志时arch路径下会生成一个dbf结尾的归档日志，同时archivelog路径下也会在当天日期文件夹下自动生成一个asm自动管理的归档日志文件。

根据现象推测应该是asm管理文件机制导致的，查询资料得知是由于指定了归档日志的具体路径导致的，由于指定了具体路径，会在指定的路径下生成一份归档日志文件，但是asm机制也会按照自己的格式生成一份。解决办法就是在指定归档日志路径的时候直接指定asm磁盘组的名称即可，后边不用指定具体文件夹名称。

4、修改归档日志目标路径

5、切换归档后发现arch路径下不会新生成日志文件，最新生成的归档日志文件在DATA/RACDB/ARCHIVELOG/ ***（日期） 下只保存了一份。

6、根据归档日志的设置问题查找软件工程师在为表空间添加数据文件的脚本时候发现工程师为数据文件指定了具体的文件路径，这也是数据文件出现双份的原因。

数据文件解决方式是在数据迁移的时候直接使用rman setnewname 指定到+DATA目录，这样迁移完成后数据文件都在+DATA/RACDB/DATAFILE/路径下了。

7、总结

在使用asm磁盘组存储数据库的时候，无论在添加数据文件还是指定归档日志路径时候直接指定asm磁盘组名称即可，不需要指定具体路径，asm会自动管理数据文件路径，数据文件名以及归档日志具体路径和归档日志的名称。