Browse Prior Art Database

Contextual Database Performance Measurer Disclosure Number: IPCOM000121952D
Original Publication Date: 1991-Oct-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 127K

Publishing Venue


Related People

Clark, DK: AUTHOR [+1]


A program is described which is used to examine, diagnose and determine the many performance variables in implementing code to run against a Database Manager.

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

Contextual Database Performance Measurer

      A program is described which is used to examine, diagnose
and determine the many performance variables in implementing code to
run against a Database Manager.

      The present invention is used for specifically identifying
(recommending) efficient implementations of database code rather than
performing traditional measurement of application path speed. Good
database methods can be exploited. Means are in place to answer
questions like "At what point does a unit of work (pending
transactions up until a COMMIT/ROLLBACK) reach a threshold where
performance of the system becomes degraded (i.e., how granulated or
grouped should transaction sets be with respect to transaction log
size)?",  "Is it wiser to COMMIT 100 particular transactions by every
20 transactions (5 COMMITs) or one commit every 100 transactions?"
and "What combination of specific transactions offers the best
possible performance solution?". Timings are measured for the
objective(s) using a different implementation. The implementation
test case can be carefully tuned as major or minor changes are
required in the measurement process. Preliminary study is completed
prior to doing a performance conscious design.

      Objects of the invention include:
     1) Measure performance timings of conveniently tried arbitrary
sets of multiple database operations, static and/or dynamic, and
present results in a report.
     2) Identify performance conscious threshold of pending
transactions up until a COMMIT or ROLLBACK (i.e., performance with
respect to transaction log constraints).
     3) Number 2 above in combinations of particular transaction
     4) Timings based on various conveniently tried methods of using
the database.
     5) Traditional transaction timing.
     6) Traditional process timing.

      The method of input for specific implementation tries shall be
flat files containing SQL. The input can also optionally be C
functions identified in a recognizable syntax used in the input flat
file. The recognizable syntax would be further elaborated to support
interprocess coordination (for multiple instances in system) and
variable determination of flat file interpretation. Those skilled in
the art will recognize input methods may vary without leaving the
spirit of the invention. A report generated may take many forms,
including statistics and cross reference comparisons. In a
multitasking environment, many in stances of the invention running in
a system will help identify constraints in a multitasking environment
to show relationships between the performance of each process.

      Advantages of the invention include:
     1) Measuring performance implementations as a conveniently tried
multiplicity of trials varying COMMIT/ROLLBACK to determine best
     2) Measuring a multiplicity of implementations for 1 objective
and reporting comparison information.