Oracle Trace文件过量生成问题解决

随着Oracle技术本身的不断发展,“自动化”和“智能化”的数据库时代已经来临。无论是运维管理、开发调试,传统DBA们的工作内容都已经发生了很大变化。一些诸如内存池划分调整、归档日志管理等功能,都已经被Oracle自动或者半自动的特性所解决。对新一代DBA而言,保持不断学习的精神,接受新问题,发现属于自己的一片新天地,才是当务之急。

今天,和一个朋友解决了一个运维环境问题。笔者感觉很有意思,记录下来,供需要的朋友不时之需。

 

1、问题说明

 

今天,一个朋友从QQ上提出问题,说在测试环境的一台10gR2库,近期突然生成很多Trace Dump文件。每个文件大小在4-5M,频率每分钟若干次。几天之内占用了上百G的空间,删除无用文件之后依然产生。

Oracle Trace文件从本质上是Oracle前后台进程在特殊的情景下,例如开启跟踪模式、运行异常,自动向文件系统中输出的诊断文件。Trace文件通常以trc结尾,包含进程环境信息、运行过程和故障点输出。对Oracle官方和管理人员而言,Trace文件是诊断的重要依据。

正常运行情况下,每台数据库都会生成一些trc文件,每个文件大小在几k左右,是不会产生朋友遇到的问题的。

之后,朋友将数据库alert log和一个trace文件样本发给笔者。Trace文件大小在4M左右,明显超过正常大小。之所以还要alert log,是因为Oracle在生成trace文件时候,通常对应alert log中有相应记录。

 

2、问题分析

 

朋友的数据库环境是Oracle 10gR2,具体版本是10.2.0.3.0.。从alert log中,可以发现是一个标准的Windows数据库环境。

 

 

System parameters with non-default values:

processes                = 150

sga_target               = 612368384

control_files            = D:\ORADATA\ORACLE10\CONTROL01.CTL, D:\ORADATA\ORACLE10\CONTROL02.CTL, D:\ORADATA\ORACLE10\CONTROL03.CTL

db_block_size            = 8192

compatible               = 10.2.0.3.0

db_file_multiblock_read_count= 16

db_recovery_file_dest    = D:\oracle\product\10.2.0\flash_recovery_area

db_recovery_file_dest_size= 2147483648

undo_management          = AUTO

undo_tablespace          = UNDOTBS1

remote_login_passwordfile= EXCLUSIVE

 

 

在alert log中,我们果然发现了很多异常点。从若干天之前,就不断报错异常。

 

 

Wed Jan 21 12:49:10 2015

db_recovery_file_dest_size of 2048 MB is 0.00% used. This is a

user-specified limit on the amount of space that will be used by this

database for recovery-related files, and does not reflect the amount of

space available in the underlying filesystem or ASM diskgroup.

Wed Jan 21 12:49:11 2015

Completed: alter database open

Wed Jan 21 12:49:22 2015

Errors in file d:\oracle\product\10.2.0\admin\oracle10\bdump\oracle10_j002_2524.trc:

 

Wed Jan 21 12:49:28 2015

Errors in file d:\oracle\product\10.2.0\admin\oracle10\bdump\oracle10_j000_2516.trc:

 

Wed Jan 21 12:49:34 2015

Errors in file d:\oracle\product\10.2.0\admin\oracle10\bdump\oracle10_j003_3752.trc:

 

Wed Jan 21 12:49:35 2015

Errors in file d:\oracle\product\10.2.0\admin\oracle10\bdump\oracle10_j002_2524.trc:

ORA-12012: 自动执行作业 26 出错

ORA-08102: 未找到索引关键字, 对象号 239, 文件 1, 块 1674 (2)

 

 

之后,每隔约5秒钟,就生成一个trace文件,对应内容相同。

 

 

Mon Mar 23 09:30:52 2015

Errors in file d:\oracle\product\10.2.0\admin\oracle10\bdump\oracle10_j002_4348.trc:

ORA-12012: 自动执行作业 26 出错

ORA-08102: 未找到索引关键字, 对象号 239, 文件 1, 块 1674 (2)

 

Mon Mar 23 09:30:55 2015

Errors in file d:\oracle\product\10.2.0\admin\oracle10\bdump\oracle10_j001_1376.trc:

ORA-12012: 自动执行作业 4 出错

ORA-08102: 未找到索引关键字, 对象号 239, 文件 1, 块 1674 (2)

 

Mon Mar 23 09:30:56 2015

Errors in file d:\oracle\product\10.2.0\admin\oracle10\bdump\oracle10_j001_1376.trc:

ORA-12012: 自动执行作业 4 出错

ORA-08102: 未找到索引关键字, 对象号 239, 文件 1, 块 1674 (2)

 

 

再打开trace文件,文件名称为:oracle10_j000_5820。Jxxx通常为Oracle的自动作业Job后台进程,自动按照执行的规则后台执行。其中,包括了报错功能点:

 

 

*** 2015-03-23 09:30:38.468

ksedmp: internal or fatal error

Current SQL statement for this session:

update sys.job$ set failures=0, this_date=null, flag=:1, last_date=:2,  next_date = greatest(:3, sysdate),  total=total+(sysdate-nvl(this_date,sysdate)) where job=:4

 

 

执行job$修改操作时候,发出的错误信息。

诊断的依据中,“对象239,文件1,块1674(2)”是很好的入手点。从提示信息看,似乎这个对象遇到了坏块情况。文件1是system表空间,应该是Oracle内部对象。

由于笔者不能实际操作问题库,所以找到了类似的环境进行简单检查。

 

 

SQL> select * from v$version;

 

BANNER

—————————————————————-

Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – Prod

PL/SQL Release 10.2.0.3.0 – Production

CORE  10.2.0.3.0    Production

 

TNS for 32-bit Windows: Version 10.2.0.3.0 – Production

NLSRTL Version 10.2.0.3.0 – Production

 

 

找到object_id=239对象。

 

 

SQL> select object_name, object_type, status from dba_objects where object_id=239;

 

OBJECT_NAME          OBJECT_TYPE         STATUS

——————– ——————- ——-

I_JOB_NEXT           INDEX               VALID

 

 

报错对象是一个索引对象,对应的段结构。

 

 

SQL> select SEGMENT_TYPE, TABLESPACE_NAME, HEADER_FILE, HEADER_BLOCK, BLOCKS, EXTENTS from dba_segments where segment_name=’I_JOB_NEXT’;

 

SEGMENT_TYPE       TABLESPACE_NAME      HEADER_FILE HEADER_BLOCK     BLOCKS    EXTENTS

—————— ——————– ———– ———— ———- ———-

INDEX              SYSTEM                         1         1673          8          1

 

 

对应的索引段结构很小,只有一个extents,合计八个数据块。注意:头块编号为1673。报错块号为1674,是段头块后面第一个数据块。

熟悉Oracle段结构的朋友一定知道,索引段后第一个数据块就是索引树的根节点块。报错信息很可能是出现了索引段损坏的情况。

 

3、问题修复

 

在Oracle中,坏块是很难处理的一种故障。从官方角度,坏块的来源有两个:一个是软硬件存储之间的不兼容,另一个是Oracle内部Bug。处理坏块的手段有很多,落实到这个案例中,索引段坏块是比较好处理的一种。

最简单的处理策略是尝试rebuild索引,让数据库重新整理结构。模拟操作:

 

 

SQL> alter index I_JOB_NEXT rebuild;

Index altered

 

 

让朋友在环境上进行测试,发现执行成功,索引状态也是valid。但是问题依然存在,trace文件还会生成。

索要最新的alert log之后,发现报错信息变化。

 

 

Mon Mar 23 10:15:35 2015

Errors in file d:\oracle\product\10.2.0\admin\oracle10\bdump\oracle10_j002_6932.trc:

ORA-00604: 递归 SQL 级别 1 出现错误

ORA-08102: 未找到索引关键字, 对象号 239, 文件 1, 块 65946 (2)

ORA-12012: 自动执行作业 26 出错

ORA-08102: 未找到索引关键字, 对象号 239, 文件 1, 块 65946 (2)

 

Mon Mar 23 10:15:37 2015

Errors in file d:\oracle\product\10.2.0\admin\oracle10\bdump\oracle10_j001_7056.trc:

ORA-00604: 递归 SQL 级别 1 出现错误

ORA-08102: 未找到索引关键字, 对象号 239, 文件 1, 块 65946 (2)

ORA-12012: 自动执行作业 4 出错

ORA-08102: 未找到索引关键字, 对象号 239, 文件 1, 块 65946 (2)

 

 

注意,报错内容发生了变化。块号变化到了system表空间另一个位置。说明:rebuild操作生效,修改了index的结构,但是错误依然存在。

笔者的一种猜想是:也许rebuild操作并不能直观反映数据表的数据情况,而报错问题是在索引数据和表段数据的不一致。尝试解决方法:drop后重新create索引对象。

 

 

SQL> drop index i_job_next;

Index dropped

 

SQL> create index i_job_next on job$ (next_date);

Index created

 

 

之后,问题解决。

 

4、结论

 

相对于各种复杂问题,今天这个问题相对比较单纯简单。但是这个问题告诉我们教训。首先,问题处理要从核心线索入手,层层深入,最后定位问题。其次,对于一些想当然的概念,如rebuild,要更加深层次理解含义,更详细的分析。

不可复制的“去IOE”

“IOE”并不当代表IBM、Oracle和EMC三家国际品牌的IT厂商,而是特指:“I”是IBM的缩写,指的是IBM小型机;“O”是Oracle的缩写,指的是Oracle数据库;“E”是EMC的缩写,指的是EMC存储设备。这里的“IOE”架构为针对传统行业企业关键应用而设计,基于向上扩展(Scale-up)技术高端设备以及围绕着它们开发的大型数据库和商业中间件。

对于绝大多数企业来说,不仅要了解自身的技术需求是否合适采用“去IOE”技术,还需要拥有庞大的技术团队,并具有自我试验的精神和决心,但这只是效仿阿里巴巴“去IOE”的必要不充分条件。

一旦企业用户效仿阿里巴巴选择分布式+自行开发开源系统,就意味着它将从此迈入孤独之旅,软件的开发将没有可以借鉴的经验,也没有战略合作伙伴。此外,貌似通过开源社区讨论对技术可控,但软件的可控性实际上要低于硬件的可控性,一旦开发核心人员发生变故,整套系统的开发成果都将有付诸东流的风险。

去IOE”到底是节省成本的命题还是成本转移的命题,也是值得企业用户推敲的。

最近,“去IOE”风声正劲。

阿里巴巴集团高调宣布今年“去IOE”成功,引发互联网行业甚至传统行业企业的热议:一、现在已经采用的IOE系统是否要效仿阿里巴巴进行替换?二、未来采用的系统是否不再优先考虑“IOE”架构?

企业用户要想获得这两大问题的个性化答案,其实还需要对这背后隐藏的若干潜在问题进行思路梳理。问题无外乎集中在如下几点:“去IOE”到底指的是什么?阿里巴巴为什么要“去IOE”?“去IOE”对于企业用户尤其是具有一定规模的企业来讲是否普遍适用?未来系统的选择是集中式还是分布式,商用系统还是开源系统?IOE系统的成本是否就高于非IOE系统,可控性是否就劣于后者?IBM、Oracle和EMC企业的产品是否代表的就是专有昂贵的集中式系统?

什么是“去IOE

当业界热议“去IOE”时,首先需要给“IOE”一个相对明确的定义。实际上,“IOE”并不当代表IBM、Oracle和EMC三家国际品牌的IT厂商,而是特指:“I”是代表IBM的缩写,指的是IBM小型机;“O”是Oracle的缩写,指的是Oracle数据库;“E”是EMC的缩写,指的是EMC存储设备。这里的“IOE”架构是针对传统行业企业关键应用而设计的,基于向上扩展(Scale-up)技术高端设备以及围绕着它们开发的大型数据库和商业中间件。

因此,如果将“去IOE”简单地理解成去掉三家国际品牌IT 厂商无疑是误读。这三家企业作为商用产品提供商,在互联网普遍推崇分布式与向外扩展(Scale-out)技术、开源软件、云服务中也一直处于活跃的态势。比如EMC的VMware是x86架构服务器云计算的基础,其公有云存储服务也开展得风生水起;开源分布式数据库MySQL实际上隶属于Oracle;IBM一直是开源软件的重要支持者与贡献者,其Power服务器也不再仅仅是拥有强大Scale-up能力的专有小型机的代名词。PowerLinux开始强调Scale-out分布式能力和对开放的系统的支持,而近期成立的OpenPOWER联盟更是开放了POWER内核IP授权,Google的加盟也使得Power未来在互联网行业的迅速推进成为可能。明年POWER8芯片的问世或将使得业界对Power服务器的变身刮目相看。

去IOE”的试验精神

阿里巴巴集团从2010年开始的“去IOE”运动耗时3年,经过1.7万名内部技术人员的努力,在今年高调宣布“去IOE”成功。据悉,除了支付宝完成了“去IE”目前依旧采用Oracle数据平台,阿里巴巴最大的现金流结算系统也完成了“去O”的工作,基本实现了“去IOE”的既定目标。

这里的一组数字值得关注,即耗时3年和1.7万名人员,阿里巴巴无疑将自身作为风险极高的“去IOE”创新试验品,下定决心才有了现在的成果。众所周知,在国外,Google、亚马逊等代表性互联网企业根本就不存在“去IOE”问题,因为它们构建系统之初从小规模起步日渐发展到超大规模,采用Scale-out的分布式系统是其“路径依赖”的结果。而“IOE”的系统架构则依据传统企业对IT的需求,基于Scale-up技术的高端设备以及围绕着它们开发的大型数据库和商业中间件。

阿里巴巴后来总结“去IOE”是“技术门槛很高、技术风险很大、水很深”的技术改革,敢冒如此风险的首要原因就是,考虑成本可控、技术可控等因素,不愿继续增加成熟商用系统以满足阿里巴巴特别是淘宝爆炸式业务增长的架构需求。由于其中的特殊性和特定性,这一过程虽然具有示范效应,但却有着太多不可复制的底层技术细节。比如互联网交易系统对数据一致性要求低于传统银行,但任何交易都存在数据复杂性与一致性的协调问题。因而虽然阿里巴巴采用分布式架构处理部分交易系统,但也需要对分布式开源数据库进行大量定制化改造。

一些具有一定技术规模的大型企业也曾经尝试“去IOE”,但在实施过程中出现技术反复,这其中甚至包括技术实力雄厚的电信运营商。因此绝大多数企业不仅要了解自身的技术需求是否合适采用“去IOE”技术,还需要拥有庞大的技术团队,并具有自我试验的精神和决心,但这只是“去IOE”的必要不充分条件。单凭这几点,企业效仿阿里巴巴将现在已经采用的“IOE”系统进行替换,就是风险极高的事。换句话说,阿里巴巴的“去IOE”运动是不可复制的。为此,多数企业对阿里巴巴“去IOE”运动思考落脚点开始集中在,未来将要采用的新系统是否不再优先考虑“IOE”系统?

去IOE”的实质

阿里巴巴为什么要“去IOE”?因为集中式部署很难适应互联网大规模应用对扩展性的要求,与其说是“去IOE”,更不如说其实质是分布式架构+开源系统替代了集中式架构+商用系统。

众所周知,IOE架构有效地支撑着绝大多数非互联网企业的关键业务。但大型企业自身技术的逐渐成熟,尤其是技术团队自主开发能力的增强,使得部分企业认为对大型IT厂商依赖过多,成本偏高,技术上逐渐产生依赖感,如何在未来新系统中实现技术可控与成本可控成为“去IOE”思想产生的重要原因。

分布式架构+开源系统是否就意味着技术可控值得推敲。原来的软件设计使得早期的IT系统强调单机可靠性和单机性能,但随着云计算的崛起,软件层面的可靠性、可扩展性设计降低了业务对底层服务器单机的可靠性和性能的要求。为此,IBM Power服务器也在不断变化。在拥有强大Scale-up技术的基础上,Power开始逐步淡化小型机形象,强调其在Scale-out上的分布式能力。实际上,IBM引以为傲的“Wston”系统就是由90台Power 750服务器构建的处理平台。而在最新一期HPC500强排行榜,就有16套Power系统上榜,其集群能力与x86服务器相比并无伯仲之分。

在开源系统和商用系统的博弈之中,企业需要考虑方法论问题,即需要考虑一个系统的功能性需求和非功能性需求。在企业新业务新系统的创新中容易首先考虑功能性需求,即创新的系统是否能够解决当下的问题。但当其满足需求之后,企业将很快面临非功能性需求的压力,即如何构建一套稳定的系统。有多少人员能够维护好开源系统,不断进行开源中的Bug修改,按照系统的新要求加入新的功能并不断优化。

这恰恰就是商用系统存在的价值,毕竟系统从特定条件下的“可用”到能够向其他企业推广商用,这其中的门槛很高,商用软件用户可以通过与商用系统厂商的战略合作,了解其他类似用户的做法,获取经验防患未然。因此,一旦企业用户效仿阿里巴巴选择分布式+自行开发开源系统,就意味着它将从此迈入孤独之旅,软件的开发将没有可以借鉴的经验,也没有战略合作伙伴。而且,貌似通过开源社区讨论对技术可控,但软件的可控性实际上要低于硬件的可控性,一旦开发核心人员发生变故,整套系统的开发成果都将有付诸东流的风险。

成本可控是“去IOE”的另一重要原因,但实际发生的也许只是成本的迁移。企业投资购置成熟高端设备和商用中间件,可以只关注业务的创新,而功能的实现、扩展、优化、安全的保障等都由商用系统厂商交付。如果企业采用低端分布式设备和自行开发开源软件,确实降低了初始投资,但却转移了成本。

阿里巴巴在“去IOE”中就谈到,原来只需要几十台小型机,现在却要面临数千台x86服务器,必须重新架构全新的运维体系把这种复杂性对上层进行“封装”。 如果企业此时又选择了自行开发开源软件,固然再次节省了软件投资,但实际成本又将转移到自身技术人员队伍的建设上,比如阿里巴巴就拥有1.7万人的庞大技术团队。因此,“去IOE”到底是节省成本还是成本转移,也是值得企业用户推敲的。

【编后语】

企业发展对信息技术的依赖性,信息技术手段的丰富和增强,促使企业有更多的技术方案和硬件平台选择,故去IOE化是信息化技术发展的趋势,也能提高企业信息化技术能力,也能降低信息化建设的成本,增强企业的技术研发实力和话语权,去IOE事件成为近年来行业内的热门话题。

若是企业选择去IOE的信息化建设道路,须弄清楚:去IOE概念,为什么要去IOE去IOE对企业投资成本的影响,那些业务场景适合非IOE技术架构,用什么技术和产品替代IOE平台,企业去IOE进程与力度等,换句话说企业必须弄清楚去IOE的本质和核心。

对于非互联网企业绝大多数情况下,IOE平台的时候会采购相应的维保服务,若是推动去IOE化,也会采购去IOE服务,不过比商业软硬件产品的维保费和License费用至少低40%。我们公司拥有一批互联网行业内实践过“去IOE”的技术精英,同时熟悉各行业的业务和流程,去IOE服务商-上海热璞网络科技有限公司愿为您企业的信息化建设保驾护航,企业文化:诚信是立足之本,口碑是客户认可的标志,技术、服务、信誉是核心竞争力。