on 04-20-2011 5:15 AM
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
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,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
>
> 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
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
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
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
24 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.