关于oracle 10g bdump文件增长问题，请不吝指教！

日志如下：
DUMP OF REDO FROM FILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG'
 Opcodes *.*
 DBAs (file#, block#):
      (1, 1674)
 RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
 SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
 Times: creation thru eternity
 FILE HEADER:
Compatibility Vsn = 169869568=0xa200100
Db ID=1226708882=0x491e1792, Db Name='ORCL'
Activation ID=1226680978=0x491daa92
Control Seq=2374=0x946, File size=102400=0x19000
File Number=3, Blksiz=512, File Type=2 LOG
 descrip:"Thread 0001, Seq# 0000000109, SCN 0x0000003f21ee-0x0000003fb4b7"
 thread: 1 nab: 0x16f97 seq: 0x0000006d hws: 0x5 eot: 0 dis: 0
 resetlogs count: 0x29a8cc17 scn: 0x0000.0008297b (534907)
 resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000
 prev resetlogs count: 0x21d66184 scn: 0x0000.00000001 (1)
 prev resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000
 Low  scn: 0x0000.003f21ee (4137454) 12/08/2009 10:40:37
 Next scn: 0x0000.003fb4b7 (4175031) 12/08/2009 22:22:14
 Enabled scn: 0x0000.0008297b (534907) 09/30/2009 10:42:31
 Thread closed scn: 0x0000.003f7ed5 (4161237) 12/08/2009 22:05:11
 Disk cksum: 0x6833 Calc cksum: 0x6833
 Terminal recovery stop scn: 0x0000.00000000
 Terminal recovery  01/01/1988 00:00:00
 Most recent redo scn: 0x0000.00000000
 Largest LWN: 2048 blocks
 End-of-redo stream : No
 Unprotected mode
 Miscellaneous flags: 0x0
 Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
 
REDO RECORD - Thread:1 RBA: 0x00006d.0000e3b0.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.003f7ed7 SUBSCN:  1 12/08/2009 22:06:53
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:  0 OP:17.3
Crash Recovery at scn:  0x0000.003f7ed5
 
REDO RECORD - Thread:1 RBA: 0x00006d.00013fe1.01b4 LEN: 0x0048 VLD: 0x01
SCN: 0x0000.003fa4aa SUBSCN:  1 12/08/2009 22:22:06
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:  0 OP:18.3
Reuse redo entry
Range reuse: tsn=4 base=16780869 nblks=4
 
REDO RECORD - Thread:1 RBA: 0x00006d.00014678.00f0 LEN: 0x0048 VLD: 0x01
SCN: 0x0000.003fa538 SUBSCN:  1 12/08/2009 22:22:06
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:  0 OP:18.3
Reuse redo entry
Range reuse: tsn=4 base=16780917 nblks=4
 
REDO RECORD - Thread:1 RBA: 0x00006d.00016226.01e8 LEN: 0x0048 VLD: 0x01
SCN: 0x0000.003fb030 SUBSCN:  1 12/08/2009 22:22:12
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:  0 OP:18.3
Reuse redo entry
Range reuse: tsn=4 base=16781861 nblks=4
END OF REDO DUMP
----- Redo read statistics for thread 1 -----
Read rate (ASYNC): 47050Kb in 1.03s => 44.61 Mb/sec
Total physical reads: 47050Kb
Longest record: 22Kb, moves: 0/127037 (0%)
Change moves: 58065/257210 (22%), moved: 14Mb
Longest LWN: 1024Kb, moves: 10/10508 (0%), moved: 1Mb
Last redo scn: 0x0000.003fb4b5 (4175029)以4M速度增长，文件系统空间受不了了，请帮忙解决下，非常感谢！

解决方案 »

  1.   


    REDO log 默认有3个组，每个log 文件默认是50m，他们是来回切换的，循环使用的，满了之后就切换到另一个组了，不知道楼主指的满是什么？------------------------------------------------------------------------------
    Blog： http://blog.csdn.net/tianlesoftware
    网上资源： http://tianlesoftware.download.csdn.net
    相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx
    Q Q 群：62697716 
      

  2.   


    我指的是BDUMP文件不断增长，我机器空间满的很快，每次手工删除后不一会又快满了，受不了
      

  3.   


    udump下的trc文件可以通过配置不让产生,利用命令 
    alter system set sql_trace=false;
    其他的不能修改，只能手动的启动trace，手动的关闭trace.比如：
    alter system set events 'immediate trace name off';楼主的情况应该是trace没有关闭导致的..
    ------------------------------------------------------------------------------
    Blog： http://blog.csdn.net/tianlesoftware
    网上资源： http://tianlesoftware.download.csdn.net
    相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx
    Q Q 群：62697716 
      

  4.   


    我查了下，trace已经关闭了的，不知道为什么还会这样
    继续等待答案，谢谢大家的提示。