Browse Prior Art Database

Merging of TRACE Data from Distributed Systems

IP.com Disclosure Number: IPCOM000122412D
Original Publication Date: 1991-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 2 page(s) / 101K

Publishing Venue

IBM

Related People

Barnard, T: AUTHOR [+11]

Abstract

Disclosed is a process that allows distributed systems to independently trace what is occurring, while still allowing the later merging of the data into a combined report showing the sequence of related events between the distributed systems.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Merging of TRACE Data from Distributed Systems

      Disclosed is a process that allows distributed systems to
independently trace what is occurring, while still allowing the later
merging of the data into a combined report showing the sequence of
related events between the distributed systems.

      When running distributed databases, there is work going on in
different systems to perform what is thought of as a single
operation.  Each system provides various levels of 'trace' data.  The
problem is to design a mechanism that allows for reporting of related
trace events even though they were independently traced on different
systems with different clocks and may be occurring in parallel.  It
should be possible to produce such a report for synchronous events,
but not for asynchronous events.  However, even for asynchronous
events, it should be possible to show them in relation to when they
were requested to start.

      The first part of this solution was for each system to continue
to timestamp all 'trace' records that it produces with the timestamp
of the system it is on so that they can be sequenced within that
system.  Then to sequence (related) events between systems, the
requesting system will send a local timestamp along with each request
to the serving system.  The system that is acting as server will
accept the timestamp from the requestor, and every trace event that
it records will contain the local timestamp as well as the timestamp
that was received along with the request (requestor timestamp).  This
along with a unique system identifier is the change required in the
data that is traced.

      The second part of this solution was for a reporting program
that reads the trace data to determine the proper sequence of events
so that they can be reported in the 'proper' sequence (actual
sequence for synchronous events, but only in the sequence in which
they were initiated for some asynchronous events).  To actually get
the records into the proper sequence, any two-level sorting mechanism
is adequate.

      The first thing that the reporting program does is read in each
trace record and create a SORT key for it that will put it into the
proper sequence.  For records that are not related to a distributed
request the sort key is composed of: -    The Location name (where
the trace event occurred) -    The timestamp of the trace record -
The sequence number of the trace record

      For trace records that are for a d...