Ingres jdbc trace
From PTAGISWiki
JDBC tracing is available in both the JDBC driver and in the JDBC server (Ingres 2.6) or
Data Access Server (Ingres 2006). This is documented in the Ingres Connectivity Guide
for Ingres 2006 in the JDBC chapter, and in System Administrator’s Guide (Chapter 2:
Overview of Ingres -> Ingres Architecture -> JDBC Connectivity -> Tracing) for Ingres
2.6. The traces (client versus server) provide different information and are independent
of each other, but complementary regarding the information they provide. Depending on
the problem, one may be more helpful than the other. The JDBC driver trace shows what
type of JDBC calls the application is making to the JDBC driver (and responses) plus
the underlying information sent, as a result, to the JDBC/DAS server. The JDBC/DAS
server trace shows the communications to the driver plus the GCA communications to the DBMS.
Ingres 2.6
1. JDBC Driver Tracing
The Ingres JDBC Driver supports both DriverManager and DataSource tracing.
Trace information consists of JDBC method entrance and exit points with corresponding parameter
and return values.
Internal Ingres JDBC Driver tracing may be enabled by defining system properties on the java command
line (-D flag). The following properties are supported (<id> and <level> values are described below):
Property Value Description
edbc.trace.log <log> Log file path and name
edbc.trace.<id> <level> Numeric tracing level
edbc.trace.timestamp true Timestamp each trace
Note that edbc.trace.timestamp is missing in the official documentation mentioned above.
Internal driver tracing permits separate tracing level settings for the following trace IDs (<id>):
Trace ID Description
IO Communication IO modules
EDBC Standard JDBC Interface
EDBCX Extension JDBC Interface
The tracing level determines the type of information which is logged.
The following levels are currently defined:
Level Description
1 Errors
2 High level method invocation
3 High level method details
4 Low level method invocation
5 Low level method details
2. JDBC Server Tracing
Add one or more of the following trace entries to the config.dat file and then restart
the JDBC server (or the entire Ingres installation). There is also a way to turn this tracing
on and off dynamically, but requires sending a special module and script. Let me know if
that is needed as well. The levels range from 1 (errors and warnings only) to 5 (or 7 for
API) for detailed tracing including message buffer dumps.
Parameter in config.dat Value (example) Description
ii.<machine>.jdbc.*.gca_trace_level: 5 <- tracing from the GCA layer
ii.<machine>.jdbc.*.api_trace_level: 5 <- tracing from the OpenAPI layer
ii.<machine>.jdbc.*.trace_level: 5 <- tracing from the mainline JDBC Server logic
ii.<machine>.jdbc.*.trace_log: 'c:\\temp\\jdbcsrv.log' <- path/name of output trace file
Ingres 2006 R2
This is well documented in the Ingres Connectivity Guide for Ingres 2006 in the JDBC chapter.
1. JDBC Driver Tracing
Documented in “Chapter 11: Understanding JDBC Connectivity” -> section “JDBC Tracing” (pages 194-196)
2. DAS Tracing
Documented in “Chapter 9: Configuring the Data Access Server” –> section “How You Enable DAS Tracing”
(pages 141-142)
Note
By default, the trace output does not include timestamps, so it is not possible to analyze timings.
To get the timestamp added to the trace output (only available on the GCA trace output), add the
following line as well:
Parameter in config.dat Value (example) Description
ii.<machine>.jdbc.*.gca_trace_time: 1 <- add timestamps to GCA trace output
This is also true for Ingres 2006 DAS tracing … add:
Parameter in config.dat Value (example) Description
ii.<machine>.gcd.*.gca_trace_time: 1 <- add timestamps to GCA trace output
ii.<machine>.gcd.*.gca_trace_level: 5 <- tracing from the GCA layer
On Windows, particularly for performance, you may consider using ramdisk. This is a freeware tool
that creates a virtual disk in memory.
Tracing from Ingres on Windows is very slow and tracing to a file on ramdisk will speed it up by at
least 10x usually. The only downside is that the trace file size is limited by the amount of memory
allocated to ramdisk.
On Unix and Linux, the Ingres tracing is reasonably fast, so a tool like ramdisk is not needed.
On snapper, I can do a test edbc driver trace like this:
java -Dedbc.trace.log=/tmp/java.log -Dedbc.trace.EDBC=5 -Dedbc.trace.IO=5 -Dedbc.trace.EDBCX=5 -Dedbc.trace.timestamp=true -cp .:./edbc.jar EdbcInfo
And I get this result:
CA-EDBC JDBC Driver [1.3]: Fri Jan 04 13:17:43 PST 2008 EDBC-Driver: registered EDBC-Driver.acceptsURL( jdbc:edbc://host:port/db): true EDBC-Driver.getMajorVersion(): 1 EDBC-Driver.getMinorVersion(): 3
DAS server tracing
get the DAS listen address from iinamu
pitblade:ingres > iinamu Ingres 2006 Release 2 NAME SERVICE MANAGEMENT UTILITY -- -- Copyright (c) 2004 Ingres Corporation IINAMU> show servers DASVR * 54085 COMSVR * 54082 IINMSVR * 54079 IINAMU> quit
JDBC trace sample invocation
This is the command that I used to create a jdbc trace to give to Ingres tech support:
bash-2.05# uname -a; pwd SunOS pitblade 5.9 Generic_118558-17 sun4u sparc SUNW,Sun-Fire-V210 /dsk2/ptagis-1.0 bash-2.05# ./bin/run.sh -Dingres.jdbc.trace.log=/tmp/iijdbc.log -Dingres.jdbc.trace.drv=5 -Dingres.jdbc.trace.ds=5 -Dingres.jdbc.trace.msg=5 -Dingres.jdbc.trace.msg.tl=5 -Dingres.jdbc.trace.msg.nl=5 -Dingres.jdbc.trace.timestamp=true SqlBomb /dsk2/ptagis-1.0/web/ptagis/WEB-INF/db.properties getDatasources Initializing the SqlBomb class from "/dsk2/ptagis-1.0/web/ptagis/WEB-INF/db.properties". Using the driver "com.ingres.jdbc.IngresDriver".
