-
Notifications
You must be signed in to change notification settings - Fork 1
SC930 Output Page
Current Version is 20 This document describes the output format for SC930 DBMS query tracing. SC930 output has a version number which is changed whenever the output format is changed. The version number is the number in brackets on the SESSION BEGINS record.
- General Record Format
-
Datatype Values
2.1. Note about timezone offsets - SC930 Record Types
-
Changes By Version
4.1. Version 1
4.2. Version 2
4.3. Version 3
4.4. Version 4
4.5. Version 5
4.6. Version 6
4.7. Version 7
4.8. Version 8
4.9. Version 9
4.10. Version 10
4.11. Version 11
4.12. Version 12
4.13. Version 13
4.14. Version 14
4.15. Version 15
4.16. Version 16
4.17. Version 17
4.18. Version 18
4.19. Version 19
4.20. Version 20
SC930 output files contain a series of records, one per line. Some record types include a timestamp, some do not. The general format is either:
{record type}:{timestamp 1}/{timestamp 2}:{record type specific information}
where: timestamp 1 is seconds since 1-Jan-1970 00:00:00 timestamp 2 is nanoseconds or
{record type}:{record type specific information}
PARM and PARMEXEC record types give values relating to specific datatypes. In most cases the representation is straightforward. Here are the formats listed with examples. The datatype ids given can be positive or negative. When negative the datatype will allow NULLs, when positive they will not. e.g. -3 is the equivalent of INGRESDATE WITH NULL
Datatype Id Format Example
Integer 30 nnn 123
Float 31 ffff.fff 123456789.123456789
Boolean 38 TRUE/FALSE TRUE
MONEY 5 nnn.nn 1001.99
Decimal 10 nnnn.nnn 101.101
Char 20 '<string value>' 'Some text'
Varchar 21 as above as above
C 32 as above as above
Text 37 as above as above
Ingres Date 3 Ingredate can hold different types of value - absolute dates, absolute date with time and intervals.
(DATETIME) CCYY/MM/DD HH:MM:SS.nnn (<GMT offset in secs>) (DATETIME) 2009/7/13 8:27:49.0 (-7200)
(DATE) CCYY/MM/DD 0:0:0.0 (<GMT offset in secs>) (DATE) 2009/7/13 0:0:0.0 (3600)
(INTERVAL) YY/MM/DD HH:MM:SS.nnn (INTERVAL) 10/0/0 0:0:0.0
ANSI Date 4 CCYY/MM/DD 2009/7/13
Time With Timezone 7 SSS,NNN +/- TZOFF 50400,0 +/- -3600 (which is 13:00:00.0-1:00)
where SSS is seconds since 00:00:00,NNN is nano-seconds and TZOFF is timezone offset in seconds
Time Without Timezone 6 as above as above
(see note below about timezone offsets)
Time With Local Timezone 8 as above as above
(see note below about timezone offsets)
Timestamp With Timezone 18 CCYY/MM/DD SSS NNN (TZOFF) 2009/11/10 50400 0 (-3600) (which 2009-11-10 13:00:00.0-1:00)
Timestamp Without Timezone 9 as above as above
(see note below about timezone offsets)
Timestamp With Local Timezone 19 as above as above
(see note below about timezone offsets)
Interval year to month 33 YY MM 123 4
Interval day to second 34 DD SSS NNN 7 50400 0
Byte 23 length:XX XX XX XX... 10:00 11 22 33 44 55 66 77 88 99 (i.e. 0x00112233445566778899)
where XX are byte values in hex
Byte Varying 24 as above as above
nchar 26 xxxx xxxx xxxx ...
where xxxx is two bytes in hex.
nvarchar 27 as above as above
long varchar 22 (length1/length2):'<value as string>'
where length1 and length2 are the high-order, low-order parts of an overall length. NB this representation can be problematic depending on the content of the data.
long nvarchar 28 (length1/length2):XXXX XXXX XXXX (0/32014):0048 0065 006c 006c 006f 0020...
where length1 and length2 are the high-order, low-order parts of an overall length.
long byte 25 (length1/length2):XX XX XX (0/32014):00 48 00 65 00 6c 00 6c 00 6f 00 20...
long nvarchar locator 29 locator id 12345678
where locator id is a reference used by JDBC or OpenAPI programs to handle long datatypes. Locator ids are not usually meaningful by themselves.
long byte locator 35 as above as above
long varchar locator 36 as above as above
Spatial 56 "as long byte" "as long byte"
Point 57 "as above" "as above"
MultiPoint 58 "as above" "as above"
Linestring 59 "as above" "as above"
MultiLinestring 61 "as above" "as above"
Polygon 62 "as above" "as above"
MultiPolygon 63 "as above" "as above"
GeometryCollection 65 "as above" "as above"
Curve 68 "as above" "as above"
Surface 69 "as above" "as above"
Polyhedral Surface 70 "as above" "as above"
Geometry (with Z co-ord) 71 "as above" "as above"
Point (with Z co-ord) 72 "as above" "as above"
Linestring (with Z co-ord) 73 "as above" "as above"
Polygon (with Z co-ord) 74 "as above" "as above"
MultiPoint (with Z co-ord) 75 "as above" "as above"
MultiLinestring (with Z co-ord) 76 "as above" "as above"
MultiPolygon (with Z co-ord) 77 "as above" "as above"
GeometryCollection (with Z co-ord) 78 "as above" "as above"
Curve (with Z co-ord) 79 "as above" "as above"
Surface (with Z co-ord) 80 "as above" "as above"
Polyhedral Surface (with Z co-ord) 81 "as above" "as above"
Geometry (with measure) 82 "as above" "as above"
Point (with measure) 83 "as above" "as above"
Linestring (with measure) 84 "as above" "as above"
Polygon (with measure) 85 "as above" "as above"
MultiPoint (with measure) 86 "as above" "as above"
MultiLinestring (with measure) 87 "as above" "as above"
MultiPolygon (with measure) 88 "as above" "as above"
GeometryCollection (with measure) 89 "as above" "as above"
Curve (with measure) 90 "as above" "as above"
Surface (with measure) 91 "as above" "as above"
Polyhedral Surface (with measure) 92 "as above" "as above"
Geometry (with Z co-ord & measure) 93 "as above" "as above"
Point (with Z co-ord & measure) 94 "as above" "as above"
Linestring (with Z co-ord & measure) 95 "as above" "as above"
unknown "< unknown type: don't know how to interpret data >" output when the datatype id not recognised
In the case of TIME WITH TIMEZONE (id 7) and TIMESTAMP WITH TIME ZONE (18) the TZOFF value in brackets is part of the data value itself e.g. 13:00:00.0-1:00 has an offset value of (-3600) regardless of the settings of the client.
In the case of TIME WITHOUT TIME ZONE (id 6), TIME WITH LOCAL TIME ZONE (8), TIMESTAMP WITHOUT TIME ZONE (9) and TIMESTAMP WITH LOCAL TIME ZONE (19) the offset represents the offset from the client's timezone and GMT. So for example a TIME WITHOUT TIME ZONE inserted from a client where II_TIMEZONE_NAME=GMT8 would have an offset of (28800). Strictly speaking this is not part of the data value itself but it will be used when the value needs to be converted to a datatype which does have a timezone. Remember that these values are the parameter values as received but they are not necessarily the target types, so one could easily have a cursor insert for example where the PARM value is a TIMESTAMP WITHOUT TIME ZONE but the target column in the database table is an INGRESDATE. As such the value would be converted and stored as GMT. To do so it would treat the original value as being in the timezone of the client and apply the relevant offset when doing the conversion.
Such a scenario is quite likely since the default behaviour of the Ingres ODBC driver is to send all date values as TIMESTAMP WITHOUT TIME ZONE.
The rationale behind showing the client timezone offset as if it were the data value's offset is that where the offset is needed (as with a conversion, or comparison) it is readily available. The alternative would be that the timezone of the client would need to be determined (at present this is not in the SC930 output) and applied. Also note that the offset displayed takes into account any daylight savings time associated with the timezone so e.g. the value 2012-01-03 10:00:00 sent from NA-PACIFIC would be displayed as 2012/1/3 36000 0 (-28800) since that timezone has an offset of -8 from GMT in January.
ABORT
Description: ABORT occurs when the deprecated SQL statement ABORT has been issued.
Format: ABORT has no record-specific information
Timestamp: Yes
Example:
ABORT:1247473672/127000003:
Versions:
- v1 - introduced
ABSAVE
Description: ABSAVE occurs when the deprecated SQL statement ABORT TO SAVEPOINT has been issued.
Format: ABSAVE has no record-specific information
Timestamp: Yes
Example:
ABSAVE:1247473672/127000003:
Versions:
- v1 - introduced
ADD-CURSORID
Description: ADD-CURSORID occurs when a cursor or prepared statement has been defined. The ID will appear in subsequent FETCH, EXECUTE and CLOSE records.
Format: (ID=/)()
Timestamp: Yes
Example:
ADD-CURSORID:1282829760/596089000:(ID=67/12)(cat_grant )
Versions:
- v1 - introduced
AUTOCOMMIT
Description: AUTOCOMMIT occurs when the autocommit status of the session is changed
Format: AUTOCOMMIT has no record-specific information
Timestamp: Yes
Example:
AUTOCOMMIT:1247473672/127000003:
Versions:
- v1 - introduced
BGNTRANS
Description: BGNTRANS occurs when the deprecated SQL statement BEGIN TRANSACTION has been issued.
Format: BGNTRANS has no record-specific information
Timestamp: Yes
Example:
BGNTRANS:1247473672/127000003:
Versions:
- v1 - introduced
CLOSE
Description: CLOSE occurs when a cursor is closed using SQL.
Format: (ID=/)
Timestamp: Yes
Example:
CLOSE:1282829760/723787000:(ID=67/12)
Versions:
- v1 - introduced
- v10 - removed misleading ROWCOUNT=xx as it's not actually a rowcount and the real rowcount is available in the EQY record. Also this record now only applies to SQL, for QUEL see QCLOSE
COL
Description: COL describes an individual column for tuples returned by a SELECT (see TDESC)
Format: Column number:datatype:length:precision
Columns are numbered from 0.
Datatypes are the internal numeric ids (see Datatypes section)
Precision is used for decimals and represents precision and scale.
See the macros DB_P_DECODE_MACRO, DB_S_DECODE_MACRO in iicommon.h which are useful for interpreting these values.
Timestamp: No
Example:
COL:0:-20:300:0 - first column has a datatype of CHAR(300) WITH NULL
Versions:
- v4 - introduced
COMMIT
Description: COMMIT occurs when the session's transaction is about to commit
Format: COMMIT has no record-specific information
Timestamp: Yes
Example:
COMMIT:1247473672/127000003:
Versions:
- v1 - introduced
CQEP
Description: CQEP shows the equivalent of SET QEP CONCISE.
Format:
This output is associated with SET SC930 2 4
Timestamp: NO
Example:
CQEP:QUERY PLAN 1,1, no timeout, of main query | {Hash Join(i) Heap Pages 1 Tups 1 D2 C0 {Proj-rest Heap Pages 1 Tups 1 D1 C0 {table1 (a) Heap Pages 9 Tups 1 Partitions 3 }}{Proj-rest Heap Pages 1 Tups 1 D1 C0 {table2 (b) Heap Pages 9 Tups 1 Partitions 3 }}};
Versions:
- v16 - introduced
DDLCONCUR
Description: DDLCONCUR occurs when the session's DDL concurrency status is changed. Only applies to a Star database
Format: DDLCONCUR has no record-specific information
Timestamp: Yes
Example:
DDLCONCUR:1247473672/127000003:
Versions:
- v1 - introduced
DELETE CURSOR
Description: DELETE CURSOR occurs when the SQL statement DELETE FROM table WHERE CURRENT OF cursor is issued.
Format: (ID=/)()
Timestamp: Yes
Example:
DELETE CURSOR:1285161693/892220000:(ID=303/1)(pm_cursor_static )
Versions:
- v1 - introduced
ENDTRANS
Description: ENDTRANS occurs when the deprecated SQL statement END TRANSACTION has been issued.
Format: ENDTRANS has no record-specific information
Timestamp: Yes
Example:
ENDTRANS:1247473672/127000003:
Versions:
- v1 - introduced
EQY
Description: EQY occurs when the DBMS passes control back to the front-end program. Colloquially it is an "End-Query" record but whether this is a helpful description depends on how one defines the scope of a query. A typical cursor operation will have ADD-CURSORID, FETCH and CLOSE records and each will have a corresponding EQY record.
Format: rowcount:error:cpu:(dior:diow):lock_wait:TXstate
The rowcount is the number of rows affected by the query. In cases where there is no change in rows per se, e.g. COMMIT, this will be -1. In cases of multiple errors the last one will be reported. cpu is the cpu used by the session in milliseconds, dior & diow are the time spent doing disk IO used for read and write respectively. lock_wait is the time spent waiting on locks in milliseconds. cpu if it cannot be measured may appear as -1. The TXstate shows whether we are "In a TX" (1) or "Not in TX" (0).
Timestamp: Yes
Example:
EQY:1427294893/826877714:42::0:(130:4):0:1
query completed successfully and affected 42 rows, no errors occurred, ~0ms cpu time was used, 130 dior and 4diow was used and 0ms time spent waiting on locks and we are in a transaction.
EQY:1427294893/828212058:-1::-1:(130:4):0:0
query completed successfully and is not in a transaction
EQY:1285145548/992479000:-1:E_US07D9:-1:(130:4):0:0
query returned error E_US07D9 and is not in a transaction Versions:
- v8 - introduced
- v17 - cpu, dior, diow and lock_wait added.
- v19 - Transaction State (In TX = 1, Not in TX = 0)
EXECUTE
Description: EXECUTE occurs when a prepared statement is executed.
Format: (ID=/)()
Timestamp: Yes
Example:
EXECUTE:1284742157/818910000:(ID=18/1)(ducommon4 )
Versions:
- v1 - introduced
EXECUTE PROCEDURE
Description: EXECUTE PROCEDURE occurs when a database procedure is executed.
Format: (ID=/)()
Timestamp: Yes
Example:
EXECUTE PROCEDURE:1284998438/221201000:(ID=0/0)(b120620_2p)
Versions:
- v1 - introduced
FETCH
Description: FETCH occurs when a cursor fetch is performed via SQL i.e. EXEC SQL FETCH
Format: (ID=/)
Timestamp: Yes
Example:
FETCH:1282829760/723787000:(ID=67/12)
Versions:
- v1 - introduced
- v10 - removed misleading ROWCOUNT=xx as it's not actually a rowcount and the real rowcount is available in the EQY record. Also this record now only applies to SQL, for QUEL see QFETCH
IVW
Description: IVW shows the Vectorwise algebra for the query. That is it shows the query in the form the Vectorwise engine understands.
Format:
Timestamp: Yes
Example:
IVW:1312463366/410004000:Window (Project (As (Aggr (Select (Select (MScan ( _tts = '_tts', [ '_rnum',
'_cts'] ) [ 'est_card' = '10' ] , >=(_tts._rnum, sint('4'))) , <=(_tts._rnum, sint('8'))) [ 'est_card' =
'1' ] , [_tts._cts] , [_col2_2 = min(_tts._rnum)] , 200), __VT_1_0_2_1), [_cts_1 = __VT_1_0_2_1._cts,
__VT_1_0_2_1._col2_2] ), [0, 10])
Versions:
- v12 - introduced
PARM
Description: PARM describes the parameters to a query. These are the values represented by ~V in the query text
Format: ,,:=
- parameters are numbered from 0
- Datatypes are the internal numeric ids
- length is the internal length not the declared length, e.g. in the case of VARCHAR it would be the value length+2
- precision-scale, in the case of DECIMAL values is the encoded value that represents both precision and scale. This is a two byte value where the high-order byte represents precision and the low-order one is the scale. The macros DB_P_DECODE_MACRO and DB_S_DECODE_MACRO may be used to decode the precision and scale respectively. These are defined in $II_SYSTEM/ingres/files/iiadd.h
- where length/precision-scale are not relevant to the datatype they will appear as 0.
- See Datatypes section for information on how the parameter values are formatted.
Timestamp: NO
Examples:
PARM:30,4,0:0=1
PARM:3,12,0:1=(DATETIME) 2009/11/10 14:44:0.0 (0)
PARM:-21,11,0:2='Some text'
PARM:10,6,2562:3=10.23
Versions:
- v1 - introduced
- v2 - fixes to ingresdate format output
- v4 - removed timestamp
- v7 - added length for format type of BYTE and VARYING BYTE
- v15 - added length and precision-scale.
PARMEXEC
Description: PARMEXEC describes the parameters to a database procedure.
Format: ,,:(parm name)=
- parameters are numbered from 0
- Datatypes are the internal numeric ids
- length is the internal length not the declared length, e.g. in the case of VARCHAR it would be the value length+2
- precision-scale, in the case of DECIMAL values is the encoded value that represents both precision and scale. This is a two byte value where the high-order byte represents precision and the low-order one is the scale. The macros DB_P_DECODE_MACRO and DB_S_DECODE_MACRO may be used to decode the precision and scale respectively. These are defined in $II_SYSTEM/ingres/files/iiadd.h
- where length/precision-scale are not relevant to the datatype they will appear as 0.
- See Datatypes section for information on how the parameter values are formatted.
Timestamp: NO
Example:
PARMEXEC:21,9,0:0(dbname)='c146265'
Versions:
- v1 - introduced,
- v2 - fixes to ingresdate format output
- v4 - removed timestamp
- v15 - added length and precision-scale
PREPCOMMIT (SECURE)
Description: PREPCOMMIT occurs when the SQL statement PREPARE TO COMMIT has been issued.
Format:
where high xid and low xid are the high and low components of the distributed transaction id.
Timestamp: Yes
Example:
PREPCOMMIT:1288966458/387281000:4cd4113a:613f6100
Versions:
- v1 - introduced (as SECURE)
- v9 - renamed to PREPCOMMIT and distributed transaction id added
QCLOSE
Description: QCLOSE occurs when a cursor is closed using QUEL.
Format: (ID=/)
Timestamp: Yes
Example:
QCLOSE:1282829760/723787000:(ID=67/12)
Versions:
- v10 - introduced
QEP
Description: QEP shows the equivalent of SET QEP. There will be one QEP record per line of qep output.
Format:
By default output is in the SET QEP SEGMENTED format. This can be switched with SET SC930 2 2 (tree).
Timestamp: NO
Examples:
QEP:QUERY PLAN 1,1, no timeout, of main query
QEP:
QEP: Proj-rest
QEP: Heap
QEP: Pages 2 Tups 113
QEP: D1 C1
QEP: /
QEP:cat_grant
QEP:Heap
QEP:Pages 4 Tups 113
QEP:QUERY PLAN 1,1, timed out, of main query
QEP:
QEP: Cart-Prod
QEP: Heap
QEP: Pages 3869893 Tups 3869893
QEP: D27 C39201
QEP: / \
QEP: Cart-Prod Proj-rest
QEP: Heap Heap
QEP: Pages 12325 Tups 24649 Pages 40 Tups 157
QEP: D18 C253 D9 C2
QEP: / \ /
QEP:------------ ------------ iirelation
QEP:|Connector | |Connector | cHashed(NU)
QEP:| | | | Pages 39 Tups 157
QEP:| 1 | | 2 |
QEP:------------ ------------
QEP: ------------
QEP: |Connector |
QEP: | |
QEP: | 1 |
QEP: ------------
QEP: |
QEP: Proj-rest
QEP: Heap
QEP: Pages 40 Tups 157
QEP: D9 C2
QEP: /
QEP:iirelation
QEP:cHashed(NU)
QEP:Pages 39 Tups 157
QEP: ------------
QEP: |Connector |
QEP: | |
QEP: | 2 |
QEP: ------------
QEP: |
QEP: Proj-rest
QEP: Heap
QEP: Pages 40 Tups 157
QEP: D9 C2
QEP: /
QEP:iirelation
QEP:cHashed(NU)
Versions:
- v3 - introduced
- v8 - changed to segmented style by default
- v15 - concise QEP format added
- v16 - separated concise format to CQEP
QFETCH_ Description: FETCH occurs when a cursor fetch is performed via QUEL i.e. RETRIEVE CURSOR cursor_name Format: (ID=/) Timestamp: Yes Example:
QFETCH:1282829760/723787000:(ID=67/12)
Versions:
- v10 - introduced
QRY (QUERY)
Description: QRY/QUERY shows an SQL statement.
Format:
Timestamp: Yes
Example:
QRY:1270560481/402490000?select user_name, dba_name from iidbconstants;
Versions:
- v1 - introduced (as QUERY)
- v4 - changed QUERY to QRY
- v5 - changed ':' before query text to '?' to assist general purpose lexers
QUEL
Description: QUEL shows a QUEL statement.
Format:
Timestamp: Yes
Example:
QUEL:1284742158/186028000?range of i=iiintegrity
Versions:
- v1 - introduced
- v5 - changed ':' before query text to '?' to assist general purpose lexers
REQUEL
Description: REQUEL occurs when a QUEL statement is re-parsed due to a repeated query being invalidated or aged out of cache.
Format:
Timestamp: Yes
Example:
REQUEL:1285147555/981200000?retrieve(du_usrstat=iiuser.status)where iiuser.name= ~V
Versions:
- v2 - introduced
- v5 - changed ':' before query text to '?' to assist general purpose lexers
REQUERY
Description: REQUERY occurs when an SQL statement is re-parsed due to a repeated query, or database procedure being invalidated or aged out of cache.
Format:
Timestamp: Yes
Example:
REQUERY:1282829760/730886000?create procedure iiqef_alter_db( dbname = char(32) not
null not default, access_on = integer not null not default, access_off = integer not
null not default, service_on = integer not null not default, service_off = integer not
null not default, last_table_id = integer not null not default) AS BEGIN EXECUTE
INTERNAL; END
Versions:
- v2 - introduced
- v5 - changed ':' before query text to '?' to assist general purpose lexers
RLSAVE
Description: RLSAVE occurs when the SQL statement ROLLBACK TO SAVEPOINT has been issued.
Format: RLSAVE has no record-specific information
Timestamp: Yes
Example:
RLSAVE:1247473672/127000003:
Versions:
- v1 - introduced
ROLLBACK
Description: ROLLBACK occurs when the session's transaction is about to rollback
Format: ROLLBACK has no record-specific information
Timestamp: Yes
Example:
ROLLBACK:1247473672/127000003:
Versions:
- v1 - introduced
SESSION BEGINS()
Description: SESSION BEGINS occurs when a session first connects to the DBMS
Format: (DBID=<db_id>)()()()(SVRCL=)()(:)(unique_sess_id)
The db_id is the numeric database id. It is the same as db_id from the iidatabase in iidbdb. infodb also reports it but in hex, the value here is in decimal.
The user name is the effective user name i.e if fred issues sql -ubob mydb it will report bob.
high xid and low xid are the high and low components of the distributed transaction id if specified with CONNECT ... WITH HIGHDXID=..., LOWDXID=... - otherwise these values are 0
The unique_sess_id session ID is a session ID is a value that is not reused and is unique across servers.
Timestamp: Yes
Example:
SESSION BEGINS(9):1285169441/689514000:(DBID=1281353063)(testenv )(myrole )(mygroup )
(SVRCL=INGRES )(mydb )(4cd4113a:613f6100)(104834)
Versions:
- v1 - introduced
- v3 - role and group added
- v6 - server class added
- v9 - database name, high and low xids added
- v18 - Unique session ID (not support in Ingres 10.2 and below. A zero value is generated instead). Version number increased with each version.
SESSION ENDS
Description: SESSION ENDS occurs when a session disconnects or is terminated. If the session terminated with a dropped GCA connection then the text "GCA dropped" appears. This will usually indicate a session that was killed, removed or died in some way.
Format: "GCA dropped":()
Timestamp: Yes
Example:
SESSION ENDS:1384345081/961415000:GCA dropped:(ingres )(iidbdb )
Versions:
- v13 - introduced
- v14 - username, database added
SVEPOINT
Description: SVEPOINT occurs when the SQL statement SAVEPOINT has been issued.
Format: SVEPOINT has no record-specific information
Timestamp: Yes
Example:
SVEPOINT:1247473672/127000003:
Versions:
- v1 - introduced
TDESC
Description: TDESC describes the tuples returned by a SELECT. It is followed by a COL record for each of the columns in the tuple.
Format: tuple descriptor id:column count:overall tuple length:result modifier bitmask
(The result modifier bitmask is as described in gca.h.)
Timestamp: No
Example:
TDESC:4:13:252:17
Versions:
- v4 - introduced
UNKNOWN
Description: UNKNOWN is the default used when the record type is not recognised. It shouldn't normally be seen and may indicate a bug or a diag version of SC930
Timestamp: No
Versions:
- v4 - introduced
XA_COMM
Description: XA_COMM occurs when an xa_commit operation is processed
Format: XID()::
Timestamp: Yes
Example:
XA_COMM:1288960834/770705000:XID(00000001:4:4:01020304:04030201:XA):00000000:0
Versions:
- v9 - introduced
XA_END
Description: XA_END occurs when an xa_end operation is processed
Format: XID()::
Timestamp: Yes
Example:
XA_END:1288960834/770705000:XID(00000001:4:4:01020304:04030201:XA):00000000:0
Versions:
- v9 - introduced
XA_PREP
Description: XA_PREP occurs when an xa_prepare operation is processed
Format: XID()::
Timestamp: Yes
Example:
XA_PREP:1288960834/770705000:XID(00000001:4:4:01020304:04030201:XA):00000000:0
Versions:
- v9 - introduced
XA_RBCK
Description: XA_RBCK occurs when an xa_rollback operation is processed
Format: XID()::
Timestamp: Yes
Example:
XA_RBCK:1288960834/770705000:XID(00000001:4:4:01020304:04030201:XA):00000000:0
Versions:
- v9 - introduced
XA_STRT
Description: XA_STRT occurs when an xa_start operation is processed
Format: XID()::
Timestamp: Yes
Example:
XA_STRT:1288960834/770705000:XID(00000001:4:4:01020304:04030201:XA):00000000:0
Versions:
- v9 - introduced
XA_UNKNOWN
Description: XA_UNKNOWN is the default used when an XA operation is being traced but the internal indicator of the operation is not recognised. It shouldn't normally be seen and may indicate a bug or a diag version of SC930.
Format: QM-:XID()::
Timestamp: Yes
Versions:
- v9 - introduced
This was the initial numbered version. The following record types were implemented:
ABORT ABSAVE ADD-CURSORID
AUTOCOMMIT BGNTRANS CLOSE
COMMIT DDLCONCUR DELETE CURSOR
ENDTRANS EXECUTE EXECUTE PROCEDURE
FETCH PARM PARMEXEC
QUEL QUERY RLSAVE
ROLLBACK SECURE SESSION BEGINS
SVEPOINT
Initial bug 120571, 'master bug' 122137 - all SC930 changes are linked to this bug.
- REQUEL & REQUERY added - when a DBproc or repeated query is re-parsed.
- Fix to PARM/PARMEXEC when displaying ingres date values. (bug 122172)
- Add ()() to SESSION BEGINS
- Add QEP (SIR 122509)
- TDESC & COL added (SIR 122725)
- UNKNOWN - added (SIR 122725)
- QUERY became QRY (SIR 122725)
- PARM, PARMEXEC, QEP no longer have timestamps (SIR 122725)
- For QUEL, QRY, REQUEL and REQUERY replace delimiter between timestamp and query text with '?'. This allows general purpose lexers to tokenise the remaining text as query text.
- Added DBMS server class to '"SESSION BEGINS"' record (SIR 123293)
- Fixed output of BYTE and BYTE VARYING values for PARM/PARMEXEC. Previously these were printed as if an ordinary string, which could cause problems with non-printing characters. 0 would terminate the string. Also added length to PARM for BYTE and BYTE VARYING. (SIR 124161)
- Added EQY 'end-query' record (SIR 124346)
- QEP output is now in the "SET QEP SEGMENTED" style by default (SIR 124345)
- Added XA_COMM, XA_END, XA_PREP, XA_RBCK, XA_STRT and XA_UNKNOWN (bug 124654)
- Changed SECURE to PREPCOMMIT and added high and low xid (bug 124687)
- Added database name and high and low xid to SESSION BEGINS (bug 124687)
- Removed ROWCOUNT= for CLOSE and FETCH as it's misleading and redundant - it's not a count of rows and the true rowcount is available in the EQY record. (SIR 124943)
- Added QCLOSE and QFETCH for cursor operations done via QUEL. CLOSE and FETCH which used to be both are now just SQL. (SIR 124943)
- Added LOB locator support. (SIR 125454)
- Added vectorwise query support, record type IVW. (SIR 122137)
- Added SESSION ENDS record type (SIR 128503)
- Added username and database to SESSION ENDS record (SIR 128707)
- Added length and precision-scale to datatype values (SIR 128927)
- Made long types consistent with equivalent non-long type (SIR 128928)
- Added SET QEP CONCISE/SC930 2 4 (SIR 128954)
- Added CQEP record format for SC930 2 4 (SIR 129115)
- Added cpu, bior, biow and lockwait to EQY record (SIR 129469)
- Added installation wide, unique session IDs to SESSION BEGINS records. NOTE: in Ingres 10.2 and below this functionality is not supported. A zero value will be generated in place of the unique session ID.
- Added TXstate to end of EQY records (SIR 130518)
- This is the first version implemented by the new SET SERVER_TRACE / SET SESSION_TRACE commands, which supersede trace point SC930.
- Trace start and end is now always indicated by a BEGINS / ENDS record. New TRACE BEGINS/TRACE ENDS/ALTER-TRACE records are used to show trace on/off by command.
- The version is now part of a (VER=nnn) element in the SESSION BEGINS, TRACE BEGINS, or ALTER-TRACE records.
- New NOTE: lines are used for informational annotations such as errors seen by the trace facility.
- X100 profiles can now be traced; the profile is enclosed in X100PROFILE:Begin and X100PROFILE:End records.
- The X100 algebra output tag has been changed to X100Q (it used to be IVW).
- The trace output filename now has the form: qtrace_dbname_ppp_hhhhh.log where dbname is the database name, ppp is the DBMS server process ID, and hhhhh is a hex number that distinguishes the session from all other active sessions.