rowids and logical logs and fragmented tables
Posted in 2009
Topics: Transactions, Locking & Isolation, Logging & Checkpoints
I searched for this in the mailing list with no joy. BACKGROUND ============ We have a script which parses logical logs and produces a text output of the transactions in parallel, so that transaction behaviour can be viewed synchronically for debugging purposes. Handy for long-held transactions blocking others, deadlocks etc.. The information logged includes the table name (grokked from the systable info) and the rowid as reported by the logs when relevant, eg for HUPDATE here: http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.adref.doc/adref260.htm?resultof=%22%6c%6f%67%69%63%61%6c%22%20%22%6c%6f%67%69%63%22%20%22%6c%6f%67%22%20%22%66%6f%72%6d%61%74%22%20 We then use the rowid to track down the row we are interested in. PROBLEM ========= The problem we are having is that the rowids reported by the logs obviously don't exist in fragmented tables (that have no rowids) - fine. So how do we map the "rowids" reported by the logical log to the rows in the db? I've not been able to find a way. TIA, Ian
Hello Ian, if V 11.5 then maybe ifx_row_id see http://groups.google.nl/group/comp.databases.informix/browse_thread/thread/d4b257dc8e298a9c?hl=nl# it does seq scans.... so maybe you can have them file a fea. Superboer On 12 feb, 12:54, the_duke_of_hazzard <ian.mi...@gmail.com> wrote: > I searched for this in the mailing list with no joy. > > BACKGROUND > ============ > > We have a script which parses logical logs and produces a text output > of the transactions in parallel, so that transaction behaviour can be > viewed synchronically for debugging purposes. Handy for long-held > transactions blocking others, deadlocks etc.. > > The information logged includes the table name (grokked from the > systable info) and the rowid as reported by the logs when relevant, eg > for HUPDATE here: > > http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.ad... > > We then use the rowid to track down the row we are interested in. > > PROBLEM > ========= > > The problem we are having is that the rowids reported by the logs > obviously don't exist in fragmented tables (that have no rowids) - > fine. > > So how do we map the "rowids" reported by the logical log to the rows > in the db? I've not been able to find a way. > > TIA, > > Ian