|
|
We faced an "unexpected" behaviour of the JDBC-Server during the execution of massive parallel SQL-SELECT Statements.
No idea why this happend, because we run ACE for years without any problems.
The support gave the advice to enable minimum trace (CONNX.JDBC.DEBUGLEVEL = 1).
As I understand this will write trace information to ONE file.
If you have a situation where it is unpredicable when you really need the trace information, the "ONE file" strategy is not helpful. Beacuse the file gets bigger and bigger.
If all works fine, the file gets gigantic and is of no help. If a problem occurs after, lets say 2 years, you have a very big file and only the very last records are of any interest.
I hope you get the problem.
I would like to have mutliple trace files. There are some ways to do it.
Strategy-1: wrap-around two files. Trace goes into TraceFile-1. if TraceFile-1 is full (limit pre-set via parameter), then TraceFile-2 will be used. If TraceFile-2 is full, then TraceFile-1 is reused.
Strategy-2: A sequence of trace files like (traceFile-1, trace-File-2, etc.). manual housekeeping can delete "old" traceFiles, where "old" means no error occurred and the information is no help for R&D
Hope this idea will find many "likers".
Kind Regards Christian Held
| Use Case | Provide TraceInformation for R&D |
