Browse Prior Art Database

Efficient Storage Management for a Temporal Performance Database

IP.com Disclosure Number: IPCOM000109033D
Original Publication Date: 1992-Jul-01
Included in the Prior Art Database: 2005-Mar-23
Document File: 5 page(s) / 199K

Publishing Venue

IBM

Related People

Wang, PC: AUTHOR

Abstract

Unlike "traditional" databases, which contain only current data, temporal databases retain all data for a given time interval. Each data element in a temporal database has two facets - a value and the time when the value was generated. Since a data element, in a temporal database, has a "timestamp" associated with it, an update essentially creates a new element, and therefore does not replace the prior element. The net result is that a temporal database can hold all the historical data for a given time interval. The problem a temporal database presents is one of storage capacity. Data elements are always being created and added to the database. Nothing is ever removed/ replaced.

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

Efficient Storage Management for a Temporal Performance Database

       Unlike "traditional" databases, which contain only
current data, temporal databases retain all data for a given time
interval.  Each data element in a temporal database has two facets -
a value and the time when the value was generated.  Since a data
element, in a temporal database, has a "timestamp" associated with
it, an update essentially creates a new element, and therefore does
not replace the prior element. The net result is that a temporal
database can hold all the historical data for a given time interval.
The problem a temporal database presents is one of storage capacity.
Data elements are always being created and added to the database.
Nothing is ever removed/ replaced.

      A database which maintains a history log of all
performance-related information with regard to a "database system" is
a temporal database in nature.  Since the size of this database is
monotonically increasing, a solution to the storage capacity problem
must be addressed.  This article provides such a solution.
BACKGROUND

                            (Image Omitted)

For the system depicted, the performance data is collected via a set
of collection commands (i.e., SAMPLE COMMAND, EVENT MONITOR COMMANDS)
and stored into files in real time.  Later, the information in these
files will be stored into the performance database off-line using
'STORE' command.  A database system administrator can then use SQL
query to generate performance reports from the performance database.
The advantage of using a database to store performance data is
'better organized information' and 'more flexible reports'.  The
reason to store the collected performance data into an intermediate
file first before putting it into the performance database is to
minimize the overhead imposed on the database system during the
collection in real time, since writing data to a file is much faster
than inserting records into database.

      The schema of the performance database should be designed to
encompass all data collected in the intermediate files.  In other
words, the information content of those intermediate files is
replicated in the performance database with a different format (i.e.,
relational data model).  As time goes by and more performance data is
collected, the size of the performance database is going to be
monotonically increasing and eventually run out of storage.
THE DESIGN OF THE PERFORMANCE DATABASE

      The performance database is designed to have distinct
separation between two major parts of the performance database, 'Raw
Data' and 'Summary Statistics'.  Summary statistics part contains the
performance statistics summary information and raw data part contains
the detailed performance data.  Raw Data part is the exact replicate
of the data collected in the intermediate files.  Summary statistics
part is the summary statistics generated by postproces...