cancel
Showing results for 
Search instead for 
Did you mean: 

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

Former Member
0 Kudos

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

Accepted Solutions (0)

Answers (3)

Answers (3)

former_member205110
Active Participant
0 Kudos

Hi MIcahel

You could use the parameter MAX_DUMP_FILE_SIZE in init.ora to limit the size of the trace file.

You mentioned the file size is increasing I would recommend to see any dumps or sys logs thats being generated in your system.It could be that users facing some connection issue. Try to check the connectivity of your system.

Regards,

Former Member
0 Kudos

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

Former Member
0 Kudos

>

> 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

Former Member
0 Kudos

Hm, you should check:

- if all the errors come from table TBTCO (job table - SM36/SM37 data) or if other tables are affected as well

- you should check the TBTCO table for consistency

SQL> analyze table tbtco validate structure cascade;

If there is any sign of corrupt blocks i suggest you also open a OSS message, they are the experts in handling these cases. Please also read these notes:

[1413928 - Index corruption/wrong results after rebuild index ONLINE|https://service.sap.com/sap/support/notes/1413928]

[808201 - Block corruption, ORA-600 4512, ORA-600 KTSF_RSP_BITMAP|https://service.sap.com/sap/support/notes/808201]

[23345 - Consistency check of ORACLE database|https://service.sap.com/sap/support/notes/23345]

Of course you can also post the findings here, we will try to help too. But as i said corruption issues should be taken seriously and actions should be planned carefully.

Cheers Michael

Former Member
0 Kudos

Hm, you should check:

> - if all the errors come from table TBTCO (job table - SM36/SM37 data) or if other tables are affected as well

> - you should check the TBTCO table for consistency

>

SQL> analyze table tbtco validate structure cascade;

>

> If there is any sign of corrupt blocks i suggest you also open a OSS message, they are the experts in handling these cases. Please also read these notes:

> [1413928 - Index corruption/wrong results after rebuild index ONLINE|https://service.sap.com/sap/support/notes/1413928]

> [808201 - Block corruption, ORA-600 4512, ORA-600 KTSF_RSP_BITMAP|https://service.sap.com/sap/support/notes/808201]

>

> [23345 - Consistency check of ORACLE database|https://service.sap.com/sap/support/notes/23345]

>

> Of course you can also post the findings here, we will try to help too. But as i said corruption issues should be taken seriously and actions should be planned carefully.

>

> Cheers Michael

Thanks for your reply,

you are right, the table's index need to be rebuild.

After rebuild the index, the issue was fixed.

Best Regards,

Michael

Former Member
0 Kudos

SAPTRACE directory contains the alert logs, user and background traces of the database. Sometimes some core files are placed there also. All those files can be deleted, except the background and usertrace directories. This will reduce the space, but i dont think you can stop this file to increase.

I think too much activity at your DB helps to increase this file. But it's natural.