随着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中，可以发现是一个标准