Skip to content

SC930 Output Page

Jump to bottom
Sean Paton edited this page Jul 4, 2017 · 20 revisions

SC930 Output Format

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.

Contents

  1. General Record Format
  2. Datatype Values
    2.1. Note about timezone offsets
  3. SC930 Record Types
  4. 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

General Record Format

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}

Datatype Values

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

Note about timezone offsets

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.

SC930 Record Types

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

Changes By Version

Version 1

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.

Version 2

  • REQUEL & REQUERY added - when a DBproc or repeated query is re-parsed.
  • Fix to PARM/PARMEXEC when displaying ingres date values. (bug 122172)

Version 3

  • Add ()() to SESSION BEGINS
  • Add QEP (SIR 122509)

Version 4

  • TDESC & COL added (SIR 122725)
  • UNKNOWN - added (SIR 122725)
  • QUERY became QRY (SIR 122725)
  • PARM, PARMEXEC, QEP no longer have timestamps (SIR 122725)

Version 5

  • 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.

Version 6

  • Added DBMS server class to '"SESSION BEGINS"' record (SIR 123293)

Version 7

  • 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)

Version 8

  • Added EQY 'end-query' record (SIR 124346)
  • QEP output is now in the "SET QEP SEGMENTED" style by default (SIR 124345)

Version 9

  • 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)

Version 10

  • 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)

Version 11

  • Added LOB locator support. (SIR 125454)

Version 12

  • Added vectorwise query support, record type IVW. (SIR 122137)

Version 13

  • Added SESSION ENDS record type (SIR 128503)

Version 14

  • Added username and database to SESSION ENDS record (SIR 128707)

Version 15

  • 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)

Version 16

  • Added CQEP record format for SC930 2 4 (SIR 129115)

Version 17

  • Added cpu, bior, biow and lockwait to EQY record (SIR 129469)

Version 18

  • 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.

Version 19

  • Added TXstate to end of EQY records (SIR 130518)

Version 20

  • 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.
Clone this wiki locally