Trace file of directory /ORACLE/ SID /SAPTRACE/USERTRACE increase ceaseless

Question

Dear all,
Now I face a problem that the Trace file of directory /ORACLE/<SID>/SAPTRACE/USERTRACE increase ceaseless and very quickly, the trace files size was increased to 8G only two days,  so the directory always is full due to this.
So anybody could tell me this is why  ? and what method could help to decrease the trace log to produce ?
Thanks & Regards,
Michael

Answer 1

>
mho wrote:
> There could be various issues causing this. I recommend having a look at [1505012 - Unrequired Oracle trace data in R3trans and tp|https://service.sap.com/sap/support/notes/1505012], for an bug in R3trans and tp.
>
> If this does not match, then please tell us what's inside the files.
>
> Cheers Michael
Thanks for your reply, I saw the notes and use Transaction SM50 to check the trace level, the level is default ,
this system is our solution manager, although the directory is full but the system still could be connected.
The trace files contents as below：
u201C*** 2011-04-25 12:22:41.995
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [qertbFetchByRowID], [], [], [], [], [], [], []
Current SQL statement for this session:
SELECT * FROM "TBTCO" WHERE "JOBNAME" = :A0 AND "JOBCOUNT" = :A1
Call Stack Trace -
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
_ksedst38           CALLrel  _ksedst10           0 1
_ksedmp898          CALLrel  _ksedst0            0
_ksfdmp14           CALLrel  _ksedmp0            3
_kgerinv+140         CALLreg  00000000             32560400 3
_kgeasnmierr19      CALLrel  _kgerinv0           32560400 9548210 38FFDE0 0
                                                   ECDD670
__VInfreq__qertbFet  CALLrel  _kgeasnmierr+0       32560400 9548210 38FFDE0 0
chByRowID+2583                                    
_opifch2+3115        CALL???  00000000             2AFAEC3C 1E9B2F4 ECDD9D8 2
_opiefn0348         CALLrel  _opifch20           89 4 ECDDB7C
_opiefn21           CALLrel  _opiefn00           4E 4 ECDF698 0 0 0 0 0 0 0
_opiodr+1099         CALLreg  00000000             4E 4 ECDF698
_ttcpip+1273         CALLreg  00000000             4E 4 ECDF698 C
_opitsk+1017         CALL???  00000000            
_opiino1087         CALLrel  _opitsk0            0 0
_opiodr+1099         CALLreg  00000000             3C 4 ECDFC30
_opidrv819          CALLrel  _opiodr0            3C 4 ECDFC30 0
_sou2o45            CALLrel  _opidrv0            3C 4 ECDFC30
opimaireal112     CALLrel  _sou2o0             ECDFC24 3C 4 ECDFC30
_opimai92           CALLrel  opimaireal0       2 ECDFC5C
_OracleThreadStart@  CALLrel  _opimai+0           
4+708                                             
77E66060             CALLreg  00000000            
Binary Stack Dump -
========== FRAME [1] (_ksedst38 -> _ksedst10) ==========
Dump of memory from 0x0ECDD544 to 0x0ECDD554
ECDD540          0ECDD554 0040467B 00000000      [T...{F@.....]
ECDD550 00000001                             [....]           
========== FRAME [2] (_ksedmp898 -> _ksedst0) ==========
Dump of memory from 0x0ECDD554 to 0x0ECDD614
Could you help to check this issue ?
Thanks