HI
I want to trace and monitor arcsde.
I have red ESRI Article ID: 35704 on how to set variable intercept.
We are not using Arcgis server
The client application (customized arcgis desktop 10.1) is using sde (10.1) direct connection to oracle gdb (11.2).
Can I trace and monitor in this case by using sde intercept to know the bottlenecks.
Hi
I have enabled sdeintercept and some extract is given below. Please help me to interpret this.
W 33:53.753] Command: GetDbmsInfo
[R 33:53.753] Long: 0
[R 33:53.753] Long: 1
[R 33:53.753] Long: 7798895
========================================
[W 33:53.753] Command: ExecuteSpatialQuery
[W 33:53.753] Long: 1
[R 33:53.762] Long: 0
========================================
[W 33:53.762] Command: NextBuffer
[W 33:53.762] Long: 1
[W 33:53.762] Long: 0
[W 33:53.762] Long: 0
[W 33:53.762] Long: 0
[W 33:53.762] Short: -1
[W 33:53.762] Long: 1
[R 33:53.762] Long: 0
========================================
[W 33:53.762] Command: CloseStream
[W 33:53.762] Long: 1
[W 33:53.762] Long: 1
[R 33:53.762] Long: 0
========================================
This piece of information isn't really providing much info.
hi
I am facing problem of slow response when using geoprocessing tools (direct connect arcsde with oracle)
How to set proper time to record in intercept ?
The intercept file is very huge to paste complete content
How to get meaningful info from intercept ?
hi
The sdeintercept and sdetrace files are too large and contain lot of information.
How to limit the information ?
How to get meaningful information ?
Hi,
I found that SDE Intercept is helpful when looking for errors or other specific problems, e.g. details on database errors. The deltas between timestamps are some indication of how long specific actions take, but I find these hard to interpret in general.
I frequently have to investigate performance problems on Oracle ArcSDEs, and I find SQL traces a lot more helpful than SDE intercepts. Other RDBMS have similar tracing facilities, but I'm not familiar with those.
Martin
As an ArcSDE API programmer, I prefer to use SDETRACE over SDEINTERCEPT. The trace corresponds to client API calls, not the calls made inside the server executive to the database itself.
Use of the trace environment is simple -- Just create two environment variables:
SDETRACELOC=C:\TEMP\trace
SDETRACEMODE=vf
Then invoke Desktop. Remember to disable the trace by removing or altering the SDETRACELOC variable, or you'll quickly run out of disk while significantly slowing enterprise geodatabase performance.
But if you want to know what is happening between the SE_stream_execute and the first SE_stream_fetch you'll need to use the database's tracing features.
- V
Right. I guess it depends on your point of view and on what problems you're trying to solve. A developer might want to see a trace of the implemented workflow (I use AWK to extract an uninterpreted sequence of SQL calls from oracle SQL-traces and analyse them in MS Excel).
My normal job is to find out why something is slow, so my first interest is to identify areas where Oracle spends an unsual amount of time. If I can reproduce the problem, SQL traces with tkprof are the way to go, otherwise tools like Statspack or AWR help identify critical statements. Then, I can either fix things from the Oracle side - indexes, optimizer parameters, more memory, ... - or I go to development to find out if wether the statements can be fixed.
Martin
Thanks to all for your suggestions..