Below are some of the tracing options supported by the Content Server:
ca_store_trace Traces the Centera code
workflow_agent_trace Traces actions of the workflow agent
file_store_trace Traces reading/writing to a normal filestore
dql_update_trace Trace DQL update statement processing
rpctrace Traces all RPC calls made by all DFC clients
dqltrace Traces DQL statements issued to the Content Server
sql_perf_trace For Oracle, gives timing information for SQL statements
group_cache_trace Traces group cache building and dynamic groups
trace_http_post Traces communication between the JMS and CS
crypto_trace Traces dmcryptokeymgr.cxx
acs_connector_trace Traces ACS and CS communication
docbroker_trace Traces CS to docbroker communication
log_authentication_errors Identical to trace_authentication
trace_authentication Traces authentication functionality
ticket_trace Traces login ticket allocation, and authentication
net_ip_addr Prints out some hostname IP Addresses
stack_walk_off Will force CS NOT to walk to stack on an exception
development Debugging asserts - used for development
assert_fatal Will the CS die during an assert - used for development
ecpool_trace Traces dmExecutionContextPool
nettrace_all Traces netwise layer
nettrace Traces netwise layer
audit_purge_policy_cache_trace Tracing of dmSession::ValidateAuditPurgePolicyCaches, dmUpdateAuditPurgePolicyChangeTime, and dmCompareAuditPurgePolicyChangeTime
How to enable tracing:
There are two options to enable and disable Content Server tracing.
(1)Startup Option (Requires Content Server restart to take effect)
Unix: Example: dm_shutdown_cs67 -orpctrace -osqltrace
Windows: Use Documentum Server Manager to edit the service and add tracing (example: -orpctrace -osqltrace).
The tracing will be active until the corresponding startup option has been removed and the Content Server has been restarted.
(2)iAPI Options (No Content Server restart required to take effect)
#Example commands to enable:
API> apply,c,NULL,SET_OPTIONS,OPTION,S,sqltrace,VALUE,B,T
API> apply,c,NULL,SET_OPTIONS,OPTION,S,docbroker_trace,VALUE,B,T
API> apply,c,NULL,SET_OPTIONS,OPTION,S,rpctrace,VALUE,B,T
API> apply,c,NULL,SET_OPTIONS,OPTION,S,ticket_trace,VALUE,B,T
API> apply,c,NULL,SET_OPTIONS,OPTION,S,trace_authentication,VALUE,B,T
It would be advisable to do API> reinit,c after each command to ensure the tracing has been activated. It may also be recommended to verify the logs immediately after entering the command to ensure they contain the relevant level of tracing.
#Examples commands to disable:
API> apply,c,NULL,SET_OPTIONS,OPTION,S,sqltrace,VALUE,B,F
API> apply,c,NULL,SET_OPTIONS,OPTION,S,docbroker_trace,VALUE,B,F
API> apply,c,NULL,SET_OPTIONS,OPTION,S,rpctrace,VALUE,B,F
API> apply,c,NULL,SET_OPTIONS,OPTION,S,ticket_trace,VALUE,B,F
API> apply,c,NULL,SET_OPTIONS,OPTION,S,trace_authentication,VALUE,B,F
Again, after each CMD, do API> reinit,c to deactivate the tracing.
NOTES:
Some of the above tracing options can have a certain performance impact on the Content Server and should be applied with caution in production environments. Normally, they will be applied only at request of EMC Support/Engineering and for the only purpose of troubleshooting a specific issue. Ideally, the tracing should be enabled just prior to reproducing the issue under investigation and disabled immediately after the test has been completed. Also, where possible, the corresponding tracing should be collected in production environments outside working hours.
