API FOR PROGRAMMATIC RETRIEVAL AND REPLAY OF DATABASE TRACE
COPYRIGHT NOTICE AND PERMISSION
[0001] A portion of the disclosure of this patent document may contain matenal that is subject to copynght protection The copynght owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copynght nghts whatsoever The following notice shall apply to this document Copynght © 2004, Microsoft Corp
FIELD OF THE INVENTION
[0002] This invention relates to computing, and more particularly to analysis of database actions and performance, and more particularly to an application programming interface that allows customized and automated retneval and replay of trace data emitted by a database
BACKGROUND OF THE INVENTION
[0003] A database comprises a collection of data, typically descnbing the activities of one or more related organizations For example, a university database might include information about entities such as students, faculty, courses, and classrooms, and relationships between entities, such as student enrollment in courses, faculty teaching courses, and the use of rooms for courses A database management system, or DBMS, is software designed to assist in maintaining and utilizing large collections of data For the purpose ofthis document, however, the term "database," or
"database server" refers to either or both of a collection of data and DBMS software Thus, database 100 in Fig 1 can be considered both a collection of data and DBMS
[0004] Many kinds of databases are in use The first database model is widely attributed to Charles Bachman of General Electric in the early 1960's This was called the Integrated Data Store, and followed the network data model Later in the 1960's, IBM developed the Information Management System, which formed the basis for a hierarchical data model In 1970, Edgar Codd of IBM proposed the relational data model, which proved to be a watershed m the development of database systems The popularity of relational databases changed the commercial landscape Their benefits were widely recognized, and the use of databases for managing corporate data became standard practice Relational databases are the dominant model in use today
[0005] Various DBMS products, e g MICROSOFT SQL SERVER®, IBM DB2®, ORACLE DATABASE®, and SYBASE IQ® have greatly extended the capabilities of databases Databases can store a wide variety of data types, such as images and text, and can perform complex quenes on stored data Specialized systems have been developed by numerous vendors for creatmg data warehouses, consolidating data from several databases, and for carrying out specialized analysis
[0006] Databases have entered the internet age The use of a database to store data accessed through a web browser is widespread Quenes are generated through Web-accessible forms and answers are formatted usmg a markup language such as Hyper Text Markup Language (HTML) or Extensible Markup Language (XML) which can be displayed in a browser Databases continue to gain importance as more and more data is brought online and made ever more accessible through computer networking Today the field is being dnven by exciting visions such as multimedia databases, interactive video, streaming data, digital hbranes, a host of scientific projects, and corporate data consolidation and data mining Access to databases over global computer networks is commonplace
[0007] Refernng to Fig 1, a multitude of clients 101,102, and 103 may request services from a database 100 Typically, the service requests 101a, 102a, and 103a are Structured Query Language (SQL) quenes which ask a database for data matching certain cntena For example, the database introduced above might be requested via service request 101a, to return a list of all students with the last name of "Smith " The database 100 may determine a strategy for the best way to process such a service request 101a, gather the appropnate data, format the gathered data, and send the data back to client 101 A modem database 100 may be asked to perform hundreds or thousands of such operations simultaneously
[0008] In addition to retrieving data, databases may also be requested to update data For example, if database 100 is a bank database with account information, the data will need to be updated every time there is a deposit or a withdrawal from a particular account Another function of a database is to organize access to data to ensure that is updated in an orderly way, and to provide the most updated version of data for the multitude of requests that are made
[0009] There is no single best way to store, update, and manage access to data Changes in the way that data is stored can vastly improve the performance of a database Likewise, changes in the techniques for managing data requests and updates to data can increase performance On the other hand, such changes m data layout and access techniques can cause problems for the proper functioning of a database Changes may lead to poor performance, inability to process certain requests, errors in the data gathered and returned, and instability of a database
[0010] As a result, there is a need to monitor and analyze the performance of modem databases Through understanding the conditions that cause a database to perform well, or conversely, to experience problems, databases can be improved In response to this need, many modern databases are equipped with the ability to emit a trace data stream 104b
[0011] A trace data stream 104b contains information about the various operations of a database 100 Such a stream 104b may contain any information that is considered relevant for analysis In general, trace data streams 104b contain information describing the various service requests 101a, 102a, 103a that were made for a database Such descriptions may include the request made, the time of the request, and the client that issued the request Any output returned by the database may also be included in a trace data stream 104b As modern databases mcrease the number of services they provide, an increasing variety of data is available for inclusion m a trace data stream 104b
[0012] Typically, access to a trace data stream 104b is made through a chent computer 104 The client computer 104 may send a trace data request 104a to a database 100, thereby opening a connection to the trace data stream 104b Traditionally, a profiler application 105 is installed on the client computer 104 The profiler 105 allows a human to initiate a session through a Graphic User Interface (GUI) The profiler can display accumulated trace data in a window 108 The profiler can provide a menu of items allowing numerous functions 110 for the access and manipulation of trace data 104a Some of these functions 110 are shown in the exemplary profiler GUI 105 m Fig 1, such as save, open, pnnt, replay, etc Using this profiler application 105, a user may specify a database 100 to analyze, open a connection to the corresponding trace data stream 104b, and save the trace data collected in any number of locations, such as in a file, in a table, or on a server
[0013] Moreover, a user can instruct a profiler 105 to replay trace data Trace replay allows a sequence of queries represented in trace data to be generated and run on a database Thus, if, for example, changes or improvements are made to a database that experienced problems, a human can run a set of queries against the improved database to determine if it was properly fixed
[0014] As databases proliferate, the cost of analyzing and improving databases also increases Keeping a running store of all trace data for a single database could be very costly, an expense that multiplies with multiple databases Therefore it is necessary to strategically chose when to access and store trace data If a first database experiences a particular problem, it may be desired to replay the trace corresponding to the problem against a vanety of other databases Occasionally trace data is modified prior to replay to gather additional information and potentially narrow the possible causes of a database problem These modified traces may also be replayed against a large number of databases Thus the collection, modification, and replay can become an expensive and cumbersome task The traditional approach for database trace data accumulation, analysis, and replay can involve too much human time in operating a profiler application
[0015] In light of the heretofore unforeseen difficulties in the industry set forth above, there is an unacknowledged and unfilled need for improved systems and methods for gathering and replaying trace data
SUMMARY OF THE INVENTION
[0016] In consideration of the above-identified shortcomings of the art, the present invention provides systems and methods for programmatic retrieval and replay of database trace data A plurality of objects—trace and replay objects—can be designed to automatically perform operations upon invocation by custom computer processes Trace data can be saved to any of vanety of locations It can be manipulated for the purpose of storage or replay Trace data can be played back against any database server using numerous replay configuration options Replay notifications allow data to be changed just before it is submitted to a database for execution, and allow immediate examination of replay results and validation ofplayback correctness
[0017] Trace and replay objects greatly simplify manageability of trace data from several perspectives Designers of custom processes can now completely automate security audit and health monitonng of traced database servers Automatic venfication of new server releases and secunty packs can also be performed Custom processes can use the provided objects to flexibly access and manipulate the retneval, storage, and replay of database trace data Such custom processes can be designed to use the invention m ways that suit the particular needs of a given organization
[0018] Other advantages and features of the invention are described below
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] The API for programmatic retneval and replay of database trace in accordance with the present invention are further described with reference to the accompanying drawings in which
[0020] Figure 1 illustrates a pnor art system in which a profiler application can retrieve, view, store and replay database trace data reflection the vanous service requests of a database and/or other operations performed by the database,
[0021] Figure 2a is a block diagram broadly representing the basic features of an exemplary computing device suitable for use in conjunction with vanous aspects of the invention,
[0022] Figure 2b is a block diagram representing a more detailed exemplary computing device suitable for use in conjunction with vanous aspects of the invention,
[0023] Figure 2c illustrates an exemplary networked computmg environment m which may computenzed processes, including those of the invention, may be implemented,
[0024] Figure 3 illustrates an API for programmatic retneval and replay of database trace data in which custom objects can be designed to automate the retneval, viewing, storage, and replay of database trace data,
[0025] Figure 4 illustrates vanous functions associated with retneval and storage of database trace data, including storage m a file, table, and server, and requests to store, modify, and replay trace data,
[0026] Figure 5 provides a UML diagram for a preferred embodiment of the arrangement of the vanous objects implementing the API of the present invention,
[0027] Figure 6 illustrates vanous functions associated with replay of database trace data, including replay from a file, table, or server, as well as starting, stopping, and pausing replay, in addition to providing a plurality of notification options during the replay, and finally providing any additional options, such as specifying a trace source, replay mode, and other options,
[0028] Figure 7 illustrates a class definition for an exemplary replay object,
[0029] Figure 8 illustrates exemplary declarations for callback notification events,
[0030] Figure 9 illustrates an exemplary definition for an IDataRecordChanger interface that can inhent from an IDataRecord interface, such as the IDataRecord interface that is known in the art,
[0031J Figure 10 illustrates an exemplary class definition for a trace replay options object,
[0032] Figure 11 displays two exemplary replay modes that can be selected from in replaying database trace data,
[0033] Figure 12 illustrates an exemplary object for use in connection with the object-oriented coding techniques of contemplated for use with the invention
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
[0034] Certain specific details are set forth m the following descnption and figures to provide a thorough understanding of various embodiments of the mvention Certain well-known details often associated with computing and software technology are not set forth in the following disclosure, however, to avoid unnecessarily obscuring the various embodiments of the mvention Further, those of ordinary skill in the relevant art will understand that they can practice other embodiments of the invention without one or more of the details descnbed below Finally, while vanous methods are descnbed with reference to steps and sequences m the following disclosure, the descnption as such is for providing a clear implementation of embodiments of the mvention, and the steps and sequences of steps should not be taken as required to practice this mvention
[0035] Vanous aspects of the mvention pertain to an API for programmatic retneval and replay of database trace data To fully disclose these vanous aspects, this descnption will begin by defining an API, a database, and trace data It will proceed to descnbe retneval and replay of trace data Aspects and implementations of programmatic retneval and replay will be discussed next Finally, a descnption of the general computmg and network environments suitable for use with the vanous embodiments of the invention is provided
[0036] An application programming interface ("API") is a computer process or mechanism that allows other processes to work together In the familiar setting of a personal computer runnmg an operating system and vanous applications such as MICROSOFT WORD® and ADOBE ACROBAT READER®, an API allows the applications to communicate with the operating system An application makes calls to the operating system API to invoke operating system services The actual code behind the operating system API is located m a collection of dynamic link hbranes ("DLLs")
[0037] Database software can also provide an API A database API allows processes to make calls to a database to invoke database services Modern database software such as MICROSOFT SQL SERVER®, IBM DB2®, ORACLE DATABASE®, and SYBASE IQ®, all provide APIs The vast majonty of enterpnse applications today use databases, and therefore also use the APIs that allow applications to access and manipulate those databases It is desirable to
provide these applications, whether client-side, middle-tier, or server-side applications, with the most responsive and scalable database API possible This is especially true for data access-intensive applications The API provided here can be incorporated into an operating system API, a database API, an API for some other application or service, or can stand alone The functions provided here are not limited to a particular device or host software environment
[0038] An API can be implemented, just like the operating system, application, or other software whose services are invoked, in the form of computer executable instructions These instructions can be embodied in many different forms Eventually, instructions are reduced to machine-readable bits for processmg by a computer processor Prior to the generation of these machine-readable bits, however, there may be many layers of functionality that convert an API implementation into various forms For example, an API that is implemented in C++ will first appear as a series of human-readable lines of code The API will then be compiled by compiler software into machme-readable code for execution on a processor
[0039] Recently, the proliferation of programming languages, such as C++, and the proliferation of execution environments, such as the PC environment, the environment provided by APPLE® computers, handheld computerized devices, cell phones, and so on has brought about the need for additional layers of functionality between the original implementation of programming code, such as an API implementation, and the reduction to bits for processmg on a device Today, a computer program initially created m a high-level language such as C++ may be first converted into an intermediate language such as MICROSOFT® Intermediate Language (MSIL) or JAVA® The intermediate language may then be compiled by a Just-in-Time (JIT) compiler immediately prior to execution in a particular environment This allows code to be run in a wide variety ofprocessmg environments without the need to distribute multiple compiled versions In light of the many levels at which an API can be implemented, and the continuously evolving techniques for creating, managmg, and processing code, the mvention is not limited to any particular programmmg language or execution environment The implementation chosen for description of various aspects of the invention is that of a managed MICROSOFT® NET class library This choice provides a convenient environment both for practicing and describing the mvention, but is in no way mtended to limit the invention to this implementation
[0040] Features of the API set forth herein provide a vehicle for automating the retrieval and replay of database trace data Various embodiments of the contemplated systems and methods are provided in Fig 3 Those mterested in analyzing database performance can create custom objects 330, 331, 332 that can use the API 309 to gather, manipulate, and replay trace data 304b according
to dieir individual needs The potential operations performed by custom objects 330, 331, 332 cannot be foreseen, as they will vary with the skills and requirements of a wide number of programmers However, the provided API 309 gives robust support for the various objects 330, 331, 332 that may be created While the mvention is not limited to the set of functions 310 disclosed in this document, the functions 310 provided are considered novel and useful both individually and as a group These functions 310 will be explained in further detail below, in connection with the automation of retrieval and replay of trace data 304b
[0041] Custom objects 330, 331, 332, and any other element identified as an object in the illustrations are discrete units of software typically generated using object-oriented programming techniques Moreover, the API 309 itself can be implemented as one or more objects One such exemplary object is illustrated in Fig 12, which diagrams the features of a typical COM object 1200 Other object types are available and widely used m the industry, and the object 1200 described here is intended as a nonhmiting example for the purpose of illustration Objects such as 1200 generally support one or more interfaces 1202, 1203, 1204, each ofwhich mcludes methods 1205 A method 1205 is typically a function or a procedure that performs a specific action and can be called by software, e g called by another object such as 330, 331, and 332 Such calling software is referred to as the "client" of the "server" object 1200 The methods 1205 that make up an interface
1203 are usually related to each other in some way In general, clients can access the services
provided by an object 1200 by invoking the methods 1205 in the object's interfaces 1202,1203,
1204 Clients are generally prohibited from accessing an object's data It should be noted that
functions described herein and in the claims as accomplished by an object may also be achieved
through multiple objects designed to interface with each other
[0042] Typically, an object 1200 is an instance of a specific class One class, for example, might contain objects that provide services for opening a connection to a database server, while another class might contain objects for writing data to a file Typically, a programmer knows an object's class pnor to running an instance ofthat object The class of an object is looked up in a class library Such a library has access to a directory of all available classes of objects A client can call a function m a library specifying the class of object it wants and the first supported interface to which it wants a pointer The library then causes a server that implements an object ofthat class to start running The library also passes back to the initiating client a pointer to the requested interface on the newly instantiated object The client can then ask the object directly for pointers to any other interfaces the object supports
[0043] Interfaces supported by objects are generally thought of as a contract between the object and its clients The object promises to support the interface's methods as the interface defines them, and the clients promise to mvoke the methods correctly Thus, an object and the clients must agree on a way to explicitly identify each interface, a common way to describe, or define, the methods in an interface, and a concrete definition ofhow to implement an interface
[0044] Thus, objects can be described in terms of the interface parameters that they inherit, as well as the class parameters that they inherit Where a class of objects has a function for writing data to a file, for example, an instance that inherits the class will also be able to write data to a file, as well as any additional features and functions provided m the instance Where a class supports a particular interface, an instance of the class inherits the "contract" and therefore also supports the interface The objects through which aspects of the invention are implemented generally conform to these programming principles and understandings of the definitions for objects, classes, inheritance, and interfaces However, it should be clear that modifications and improvements to object-oriented programming techniques are constantly occurring, and the invention is not limited to objects of a particular type or with any specific features The API provided can be implemented through objects of any kind now in use or later developed
[0045] A database is a collection of data, typically describing the activities of one or more related organizations For example, a university database might contain information about entities, such as students, faculty, courses, and classrooms, and relationships between entities, such as student enrollment in courses, faculty teaching courses, and the use of rooms for courses A database management system, or DBMS, is software designed to assist in maintaining and utilizing large collections of data For the purpose of this document, however, the term "database," or "database server" refers to either or both of a collection of data and DBMS software Thus, database 100 m Fig 1,300 m Fig 3, and 640 in Fig 6 illustrate database servers compnsmg both collections of data and DBMS Further distinction will be made when necessary
[0046] Many kinds of databases are in use The first database model is widely attributed to Charles Bachman of General Electric in the early 1960's This was called the Integrated Data Store, and followed the network data model Later in the 1960's, IBM developed the Information Management System, which formed the basis for a hierarchical data model In 1970, Edgar Codd of IBM proposed the relational data model, which proved to be a watershed m the development of database systems The popularity of relational databases changed the commercial landscape Their benefits were widely recognized, and the use of databases for managing corporate data became standard practice While relational databases are the dominant model m use today, the various
aspects of the invention are suitable for use in connection with any database presently in use or later developed that is capable of emitting trace data
[0047] Various DBMS products, e g MICROSOFT SQL SERVER®, IBM DB2®, ORACLE DATABASE®, and SYBASE IQ® have greatly extended the capabilities of databases Databases can store a wide variety of data types, such as images and text, and can perform complex quenes on stored data Specialized systems have been developed by numerous vendors for creating data warehouses, consolidating data from several databases, and for carrying out specialized analysis All such products and database configurations are suitable for use in connection with the systems and methods herein
[0048] Databases have entered the internet age The use of a database to store data accessed through a web browser is widespread Quenes are generated through Web-accessible forms and answers are formatted usmg a markup language such as Hyper Text Markup Language (HTML) or Extensible Markup Language (XML) which can be displayed in a browser Databases continue to gain importance as more and more data is brought online and made ever more accessible through computer networking Today the field is being dnven by exciting visions such as multimedia databases, interactive video, streaming data, digital hbranes, a host of scientific projects, and corporate data consolidation and data mining Where access to databases over global computer networks is commonplace, it should be clear that the systems and methods provided herein can be used regardless of the distance or type of connection between a client and a database
[0049] An API for programmatic retneval and replay of database trace data is provided The above generally descnbes an API and a database Trace data will be discussed next, followed by a discussion of retneval and replay of trace data, followed by a discussion ofprogrammatic retneval and replay, which will serve to particularly point out the features of the API descnbed generally above
[0050] Trace data is data indicating the operations of a database A typical database, such as 300 in Fig 3, will be requested to perform services for any number of clients, e g 301, 302, 303 Such requests are generally quenes formulated in Structured Query language (SQL), although as databases such as 300 grow more complex and provide a greater range of services, the types and volumes of requests also increase Modem databases are capable of emitting a stream of trace data 304b that contains information about requests and corresponding database operations Trace data can be useful in analyzing what a database 300 is requested to do and how the database 300 satisfies the requests Through this analysis, databases can be improved in terms of how data is stored, how quenes are managed, and in terms of the host of other services that modern databases provide
[0051] Trace data can be emitted from a database in any format Typically, because databases provide continuous services, trace data is emitted as a constant stream 304b of data organized according to a data transfer protocol By opening a connection to the trace data stream 304b, a client 304 can analyze and record the operations of the database 300 In this regard, trace data 304b is typically stored in one of three locations, as suggested in Fig 4 These locations comprise a file 403, a table 404, and a server 405 Because database trace data 304b is well understood in the industry, a detailed explanation of the precise formats for recording trace data 304 is not necessary here It will be appreciated that trace data 304b can be recorded m any format In general, however, formats for trace data, regardless of whether it is stored in a file 403, a table 404, or a server 405 may comprise a plurality records, or discrete units of data that convey some independent meaning
[0052] As an example of how trace data 304b is typically divided into records, consider a typical file 403 in which trace data is stored. Such a file 403 may include the following records
Header
2 bytes - header length
48 bytes - provider name
2 bytes - provider version
48 bytes - definition type
4 bytes - file options
48 bytes - Traced server name
Data Section
[0053] Each new database event usually starts with a TRACE_BEGIN_RECORD special column followed by one byte, which represents the length of the column followed by an event identifier and overall length of the event Then any other columns for the event are described Each event column record may contain information corresponding to a column identifier, a data length, and the data itself The data length is usually a single byte field
[0054] The above provides an example of how trace data may be divided into records in a trace data file 403 Exemplary record divisions for trace data stored in a table and trace data stored in a server are not provided here, because storage of trace data in these formats is commonplace, and in general comprises dividing data into records similar to the above while varying some parameters to format the trace data in the desired layout The above example suffices to show that trace data can
be divided into any number of records, and records can be organized in any number of ways The invention is not limited to a particular number or layout of records in a trace data file, a trace data table, or a trace data server
[0055] Retrieval of trace data refers to acquiring trace data electronically In various embodiments of the invention, retrieval may occur in a scenario such as that of Fig 3 in which a client 304 sends a request 304a for trace data to a database 300 The request 304a causes the database 300 or some other intermediate process (not shown) to transmit a trace data stream 304b to the chent 304 While Fig 3 represents a typical retrieval of trace data, It will be appreciated that any processes, or portions of processes, may run on or across any number of devices not shown, as explained with reference to the exemplary computing and networked environments below
[0056] Retrieval of trace data may be accompanied by storing the retrieved data, as in Fig 4 Trace data may be stored in a file 403, a table 404, or a server 405 Note that the process of storing trace data may mvolve some conversion of the trace data stream from the initial signal coming from a database 300 As explained above, the trace data may be formatted into a number of records according to the particular layout and presentation of the data desired m storage As suggested in Fig 4, the API 401 provided allows an exemplary custom object 400 to request retrieval of trace data and to specify storage of the trace data m a file 403, table 404, or server 405 Exemplary requests 410, 411, and 412 submitted to API 401 can specify retrieval of trace data The implementation of the API can connect to an appropriate database, retrieve the trace data stream, and write an appropriate output to 403,404, or 405 In various embodiments, the API may be configured to automatically select a default storage location, e g 403, 404, or 405 to be used when no storage location is indicated by exemplary custom object 400
[0057] Replay of trace data refers to causing a database to perform a series of operations identical to, or related to, a series of operations represented in a set of trace data For example, consider a set of trace data stored m a file 403 Imagine that the set of trace data m question caused a database 300 to perform abnormally, e g by returning incorrect, abnormal, or untimely results to a client 301, or to destabilize or crash. To investigate the series of events that led to the abnormality, it may be desirable to subject the database 300 to the same conditions as those that led to the abnormality In this situation, the appropriate set of trace data in file 403 can be used to formulate a sequence of service requests to replicate the former requests, eg 301 a Submitting such a sequence of requests amounts to replay of trace data Note that there may be a host of reasons to replay trace data, and investigation of abnormalities is merely one example The systems and methods herein can be used to replay trace data regardless of the purpose or intent of those who initiate such replay
[0058] Replay of trace data need not be agamst the same database as the database that initially emitted the trace Just as any database can be selected for retrieval of trace data, any database can be selected for replay This allows a database to be used for testing purposes that is separate from a database that has real-world responsibilities It also allows replay of trace data against a variety of database platforms and products, as desired
[0059] Just as trace data in a file 403 can be replayed to a database 300, trace data m a table 404 or a server 405 can be replayed Data stored in these various formats requires appropriate handling to properly format and submit the trace for replay, however identical trace data stored in any format 403,404, 405 can be used to generate an identical replay sequence for a database 300 As shown in Fig 4, an exemplary custom object 400 can request replay of trace data through the API 401 provided The request can specify the trace data to replay—which may also mdicate that the data is stored in file 403, table 404, or server 405, by generating requests 410, 411,412, and the API implementation 430 can then retneve the specified set of trace data from the file 403, table 404, or server 405 where the trace data resides and replay the trace data against a specified database
[0060] Occasionally it is desirable to modify trace data prior to replay For example, it may be suspected that a certain type of query is the cause of trouble A number of additional queries of the suspect type may be added to a stored set of trace data prior to replay to test this theory Alternatively, it may be beneficial to modify individual records of existing trace data sets Again, there may be any number of reasons alteration of trace data is desired prior to replay and the invention is not limited to any particular intent of those making use of the API herein Because it can be desirable to alter trace data prior to replay, the term replay as used herein refers not only to submitting an set of requests identical to those of recorded trace data, but also to submitting a set of requests related to those of recorded trace data As suggested in Fig 4, the API provided allows an exemplary custom object 400 to request the modification of trace data such as in requests 410,411, and 412 The implementation 430 of the API 401 can then modify the specified trace data whether it is located in file 403, table 404, or server 405
[0061] An API for programmatic retrieval and replay of database trace data is provided The above generally describes an API, a database, trace data, and retrieval and replay of trace data Systems and methods for programmatic retrieval and replay are discussed next, which will serve to particularly point out additional features of the API described generally above
[0062] For the purpose of this application, the term programmatic refers to being accessible by automated functions In other words, computerized instructions can be written that trigger a programmatic function with zero or reduced human mvolvement For example, consider a
computer user who has a bunch of numbers stored in a MICROSOFT WORD® document The user wishes to add the numbers One way to do this is to use a calculator application The computer user can open a calculator application and add any numbers using a mouse device for selecting the appropriate numbers But a calculator function does not typically expose the ability to write a computer program that programmatically retrieves and adds numbers A user with a very large amount of numbers to add or many sets of numbers may find it onerous to use the calculator application for such a task
[0063] Similarly, a computer user desiring to retrieve and/or replay a large amount of database trace data, or many sets of such trace data, may find it onerous to use a profiler application to do so "by hand " Instead, such a user may prefer to write a program that programmatically retrieves, stores, and replays trace data A user can specify when to retrieve trace data, from where to retrieve it, how to store it, how to modify it, when to replay it, and so on, as described in connection with the various aspects and embodiments herein All of these operations can be performed programmatically pursuant to the users specifications Using the systems and methods described herein, the creation of such programs is greatly facilitated
[0064] Retrieval of trace data in accordance with various embodiments of the inventions is illustrated in Fig 4 and Fig 5 Fig 4 points out the process and context for retrieval of trace data, while Fig 5 illustrates an implementation of the object(s) and mterface(s) used in providing the programmatic retrieval function Retrieval m connection with Fig 4 is discussed above, and the exemplary implementation in Fig 5 is discussed below
[0065] With reference to Fig 5, a Uniform Modeling Language (UML) diagram setting forth an implementation for an API in accordance with the systems and methods herem is provided At the top of Fig 5, element 500 provides functions ofproviding connection information, such as for connecting to a server or database, to the other objects of Fig 5 Element 501 provides functions for error reporting that can be accessed by the various other objects "fege elemonto 500 and 50-1 Element 502 is an interface for a data record, and element 504 is an interface for retrieving data The IDataReader interface 504 is known in the art It is a managed interface defined in the System Data namespace of the released with the MICROSOFT® NET framework The inclusion of this interface 504 in Fig 5 is for the purpose of specifically identifying the potential functions of an exemplary API, and is not intended to limit the invention to the IDataReader 504 interface in particular
[0066] Objects 506, 507, 508, 509, and 510 inherit from the IDataReader 504 interface The objects 508, 509, and 510 provide the functions of retrieving trace data to a server, to a table, and to a file, respectively Separate objects for these functions is beneficial, because a different set
of operations is required m reading and writing data to a file, table or server In the case of a server, access to trace data for modification ofrecords is typically unavailable, so object 508 inherits directly from object 506, without also inheriting from 507, as with objects 509 and 510 Functions provided by object 508 for retnevmg trace data and storing it m a file mclude TraceServer(), which formats trace data for storage m a server, Start(), which starts a retneval of trace data from a specified server, Pause(), which pauses a running retneval of trace data from a specified server, and Stop(),whic]gbops a running retneval of trace data from a specified server Because object 508 inhents from object 506, 508 also provides the functions Read Q for reading incoming data and Close ()for closmg a location m which data is stored. Further, object 508 provides the functions specified in the IDataReader interface 504 By providing these functions, object 508 allows users to access these functions programmatically and thereby automate
[0067] Objects 509 and 510 are illustrated as lnhenting from object 507 as well as object 506 This is for the reasons described above, namely, in preferred embodiments, it is beneficial to support record modification functions when trace data is saved to a table, as m 509, or a file, as m 510 To achieve this, object 507 inhents from 506 and provides an additional wnte function that can alter the records of stored trace data As illustrated in Fig 5, the wnte function conforms to an ITraceDataWnter interface 505, which sets up the requirements for wnting data and for properly notifying the appropnate objects of such a wnte operation Interface 505, m turn, makes use of an IDataRecordChanger interface 503 which inhents from the established EDataRecord interface 502 The IDataRecordChanger interface 503 is illustrated m another form m Fig 9
[0068] In the embodiment ofFig 9, two methods are specified for the IDataRecordChanger interface Those of skill will acknowledge that different or additional methods may be specified m such an interface without changing the fundamental operation of the invention The purpose of the interface as illustrated m Fig 9 is to provide a means to change data as data is bemg wntten or replayed In this regard, method SetValueO can takes an mdex of a column to be replaced (int I) and places a new value (object value) m that location. Method AddColumn()> on the other hand, adds a new column to trace data In this regard, a column identifier (mt columned) is provided to such a method as an argument, and an mdex for the newly generated column can be returned.
[0069] Thus, the use of an interface 503 to specify the requirements for changing trace data records delivered according to another interface 502 ultimately allows objects 509 and 510 to perform record modification operations Such record modification is useful for the purpose of replay When used m connection with the automated replay techniques provided herein, it allows for
on the fly modification and replay of trace data to provide high-powered database analysis never before achieved
[0070] All of the functions inherited by objects 509 and 510 are accessible programmatically by users, e g by exemplary custom object 400 Thus, while objects 509 and 510 are capable of writing trace data from a database stream to a table or file, respectively, as indicated by the TraceTable( ) and TraceFile( ) notations in the UML diagram, by virtue of their inheritance from object 507 they also support modification of the records stored in tables and files Further, by virtue ofthe inheritance from object 506, functions of reading database trace streams and closing connections to database trace streams are also supported by objects 509 and 510 Those who understand UML diagrams will appreciate this, and will further recognize the IDataReader interface 504 and the corresponding exemplary functions inherited from that interface
[0071] Moving now to embodiments ofthe invention that support programmatic replay of database trace data, refer to Fig 6, Fig 7, Fig 8, Fig 9, Fig 10, and Fig 11 Fig 6 provides a diagram that schematically illustrates the vanous operations that may be performed via an API that allows for programmatic replay of trace data Fig 7 through Fig 11 provide information about the vanous calls that can be exposed to access replay functions Note that a UML diagram is not provided here because such a diagram would not be interesting or informative This is because, in a prefened embodiment, the replay function objects need not lnhent from any preexisting objects That said, implementations ofthe invention which utilize inhentance could certainly be devised
[0072] Turning to Fig 6, again an exemplary custom object 600 is provided that can make vanous function calls 610,611, 612 to an API 601 The API 601 can be supported by an implementation 630 for carrying out the vanous operations that are requested ofthe API 601 The implementation 630 may utilize the vanous object onented design principles discussed herein, such as with reference to Fig 12 In carrying out the requested functions, the API implementation 630 may access and or modify trace data stored in a file 603, trace data stored m a table 604, and trace data stored in a server 605 The implementation 630 may also formulate and send a senes of quenes or other communications, related to trace data in 602,604, and 605 to a database 640 The implementation may concurrently retneve the trace data stream return 642 for the purpose of again storing such data in 603,604, or 605 for further analysis
[0073] The API may expose the ability to start, pause, or stop replay oftrace data 610 These features are also demonstrated m Fig 7 which provides pseudo code definition for a trace replay class of objects A custom object 600 that makes a call such as those provided in Fig 7 can specify a start operation for starting a replay, along with any number of start parameters Such
parameters might specify the location of the trace to be replayed, the time of replay, the database for the replay, and so on Similarly, pause and stop functions, as shown in Fig 7, may be accessed by exemplary custom object 600
[0074] The API may also expose the ability to request a notification 611 upon the occurrence of any number of events Such notifications can be used by custom object 600 for further useful advantage in replaying trace data These custom notifications are also illustrated in Fig 7 For example, custom object 600 might request notification prior to starting a replay This is shown also by the "event ReplayNotifyDelegate " line in Fig 7 This feature allows custom object 600 to, for example, examine trace datajust before replay, and make any changes to the various records as desired Similarly, notifications may be requested when replay is paused, as indicated in Fig 7 by the "event ReplayPauseDelegate ReplayPauseNotify" line Notifications may be requested when replay is restarted, as indicated in Fig 7 by the "event ReplayPauseDelegate ReplayStartNohfy, or when the trace data replay is stopped, as indicated in Fig 7 by the "event ReplayStopDelegate ReplayStopNoufy" line Notifications may be requested when trace data output from a particular replay is ready, as indicated m Fig 7 by the "event ReplayOutputNotifyDelegate ReplayOutputNotify" line Conversely, custom object 600 may not make a request for notification 611, and may simply choose to ignore these events
[0075] The ways in which these notifications 611 may be used by custom object 600 to coordinate the modification and replay of trace data are unlimited The scope of this patent extends to the use of the API disclosed, and to objects that make use of the API, regardless of whether those objects also include additional features beyond the scope of the invention The notion ofproviding notifications via an API for replaying trace data as disclosed herem is an advancement m itself that will support flexible, powerful design of custom objects making use of the provided API
[0076] The notification 61 la in Fig 6 represents the notification signal from the API 601 to the custom object It will be appreciated that any form of notification known in the art may be used, such as event objects or NET delegates, as suggested by the language of Fig 7 In various preferred embodiments, where a NET delegate is used for callback notification, the notification events may be declared as illustrated in Fig 8 The example here may be extended to other embodiments, with minor implementation differences As shown m Fig 8, the ReplayNotifyDelegate may declare the data pertaining to the subject notification This is also true of the other exemplary notification events
The notification events illustrated in Fig 8 are designed to carry sufficient information to allow for an event handler to intelligently choose appropriate actions in response to the notifications

These notifications may also comprise mechanisms to influence the execution of Replay In this regard, the following exemplary information can be included with notification events such as those ofFig 8
RecordNumber - can specify a row number of a trace record to be replayed
currentRecord - can be a trace record currently being replayed A custom object could examine the columns of such a record, and modify it directly
skipRecord - by setting a skip record flag to "true," a custom object handler could ask the API not to replay a particular trace record
[0077] The additional features illustrated in Fig 7 are, first, a function identified here as a 'TraceReaderWnter Output" function As implied by the language used, this allows a custom object 600 to retrieve the trace data output that is emitted by a database as a result of a replay Such output data may be modified prior to storage A "ConnecuonlnfoBase Connection" function allows a custom object to specify information pertaining to connecting to a database or other appropriate server For instance, a particular database address and communications protocol might be specified The API can then programmatically open a connection to the specified database at such time as required by a custom object 600
[0078] Finally with respect to Fig 7, the "TraceReplayOptions" function allows custom object 600 to specify any number of additional options Exemplary options that might be made available in a preferred API are illustrated in Fig 10 The object that provides the options for the trace data API can provide any of the illustrated five options as well as any other options that may be devised or found to be useful A size of a replay thread pool can be controlled This option can be utilized to prevent replay from opening too many threads and overburdening system resources A wait time can be specified prior to "killing" or terminating a hung process For instance, if a connection to a database is not properly executing, that process can be given a specified amount of time before termination A frequency of polling for hung processes can be set This allows a user to specify how much system resources should be devoted to polling In very stable environments, it is likely that less frequent polling is desired A replay mode can be specified This option is further illustrated in Fig 11 Two modes are contemplated herein First, a sequential replay mode, m which trace data is replayed to a database in the same order it was collected in a trace data storage area Second, a "connection level synchronized" mode, in which all events pertaining to a particular client are replayed sequentially, but any global sequence of events is not preserved, l e client requests are assumed to be mdependent of each other For example, if a single client generated one-tenth ofthe requests for particular database, an aspect ofthe invention allows that same one-tenth of database
requests to be replayed sequentially against a database As with the other functions herein that can be accessed programmatically, this allows for flexible control of the details of replay
[0079] Finally, referring back to Fig 10, an object may specify whether actual database query results should be returned, or simply the results for operations that generated errors This option highlights a useful aspect of the invention, namely that in addition to trace data, the actual results—query results or errors—can be collected during replay, and this feature can, moreover, be controlled by an object that provides for control of replay options
[0080] Thus the API and the various supporting objects disclosed herein greatly simplify the management of trace data from several perspectives First, they enable user to completely automate security audit and health monitoring of traced server Second, they allow for automatic functional verification of new server releases and security packs
Exemplary computing and network environment
[0081] With reference to Figure 2a, an exemplary computing device 200 suitable for use in connection with the systems and methods of the mvention is broadly described In its most basic configuration, device 200 typically includes a processing unit 202 and memory 203 Depending on the exact configuration and type of computing device, memory 203 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc) or some combination of the two Additionally, device 200 may also have mass storage (removable 204 and/or non-removable 205) such as magnetic or optical disks or tape Similarly, device 200 may also have input devices 207 such as a keyboard and mouse, and/or output devices 206 such as a display that presents a GUI as a graphical aid accessing the functions of the computing device 200 Other aspects of device 200 may include communication connections 208 to other devices, computers, networks, servers, etc using either wired or wireless media All these devices are well known in the art and need not be discussed at length here
[0082] Figure 2b illustrates a somewhat more detailed example of a suitable computing device from Fig 2a and peripheral systems The computing system environment 220 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention Neither should the computing environment 220 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 220
[0083] The invention is operational with numerous other general purpose or special purpose computing system environments or configurations Examples of well known computing
systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like
[0084] The invention may be implemented in the general context of computer-executable instructions, such as program modules, being executed by a computer Generally, program modules include routines, programs, objects, components, data structures, etc that perform particular tasks or implement particular abstract data types The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network In a distnbuted computing environment, program modules may be located in both local and remote computer storage media including memory storage devices
[0085] With reference to Figure 2b, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 241 Components of computer 241 may include, but are not limited to, a processmg unit 259, a system memory 222, and a system bus 221 that couples various system components including the system memory to the processing unit 259 The system bus 221 may be any of several types ofbus structures including a memory bus or memory controller, a penpheral bus, and a local bus using any of a vanety ofbus architectures By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Penpheral Component Interconnect (PCI) bus also known as Mezzanine bus
[0086] Computer 241 typically includes a vanety of computer readable media Computer readable media can be any available media that can be accessed by computer 241 and includes both volatile and nonvolatile media, removable and non-removable media By way of example, and not limitation, computer readable media may compnse computer storage media and communication media Computer storage media includes both volatile and nonvolatile, removable and nonremovable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer
241 Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a earner wave or other transport mechanism and includes any information delivery media The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media Combinations of the any of the above should also be mcluded within the scope of computer readable media
[0087] The system memory 222 mcludes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 223 and random access memory (RAM) 260 A basic input/output system 224 (BIOS), containing the basic routines that help to transfer information between elements within computer 241, such as during start-up, is typically stored in ROM 223 RAM 260 typically contams data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 259 By way of example, and not limitation, Figure ^illustrates operating system 225, application programs 226, other program modules 227, and program data 228
[0088] The computer 241 may also mclude other removable/non-removable, volatile/nonvolatile computer storage media By way of example only, Figure^ illustrates a hard disk drive 238 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 239 that reads from or writes to a removable, nonvolatile magnetic disk 254, and an optical disk drive 240 that reads from or writes to a removable, nonvolatile optical disk 253 such as a CD ROM or other optical media Other removable 'non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like The hard disk drive 238 is typically connected to the system bus 221 through an non-removable memory interface such as interface 234, and magnetic disk drive 239 and optical disk drive 240 are typically connected to the system bus 221 by a removable memory mterface, such as interface 235
[0089] The drives and their associated computer storage media discussed above and illustrated in Figure 2b, provide storage of computer readable instructions, data structures, program modules and other data for the computer 241 In Figure 2b, for example, hard disk drive 238 is illustrated as storing operating system 258, application programs 257, other program modules 256, and program data 255 Note that these components can either be the same as or different from
operating system 225, application programs 226, other program modules 227, and program data 228 Operating system 258, application programs 257, other program modules 256, and program data 255 are given different numbers here to illustrate that, at a minimum, they are different copies A user may enter commands and information into the computer 241 through input devices such as a keyboard 251 and pointing device 252, commonly referred to as a mouse, trackball or touch pad Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like These and other input devices are often connected to the processing unit 259 through a user input interface 236 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB) A monitor 242 or other type of display device is also connected to the system bus 221 via an interface, such as a video interface 232 In addition to the monitor, computers may also mclude other peripheral output devices such as speakers 244 and printer 243, which may be connected through a output peripheral interface 233
[0090] The computer 241 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 246 The remote computer 246 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 241, although only a memory storage device 247 has been illustrated m Figure 2b The logical connections depicted in Figure 2b include a local area network (LAN) 245 and a wide area network (WAN) 249, but may also include other networks Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet
[0091] When used in a LAN networking environment, the computer 241 is connected to the LAN 245 through a network interface or adapter 237 When used in a WAN networking environment, the computer 241 typically includes a modem 250 or other means for establishing communications over the WAN 249, such as the Internet The modem 250, which may be internal or external, may be connected to the system bus 221 via the user input interface 236, or other appropriate mechanism In a networked environment, program modules depicted relative to the computer 241, or portions thereof, may be stored m the remote memory storage device By way of example, and not limitation, Figure 2b illustrates remote application programs 248 as residing on memory device 247 It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used
[0092] It should be understood that the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of
both Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, may take the form ofprogram code (i e instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention In the case ofprogram code execution on programmable computers, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device One or more programs that may implement or utilize the processes described in connection with the invention, e g through the use of an API, reusable controls, or the like Such programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or mterpreted language, and combined with hardware implementations
[0093] Although exemplary embodiments refer to utilizing the present invention in the context of one or more stand-alone computer systems, the mvention is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computmg environment Still further, the present invention may be implemented in or across a plurality of processing chips or devices, and storage may similarly be effected across a plurality of devices Such devices might include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems such as automobiles and airplanes
[0094] An exemplary networked computing environment is provided in Fig 2c One of ordinary skill in the art can appreciate that networks can connect any computer or other client or server device, or in a distributed computing environment In this regard, any computer system or environment havmg any number of processing, memory, or storage units, and any number of applications and processes occurring simultaneously is considered suitable for use in connection with the systems and methods provided
[0095] Distributed computing provides sharing of computer resources and services by exchange between computing devices and systems These resources and services include the exchange of information, cache storage and disk storage for files Distributed computmg takes advantage of network connectivity, allowing clients to leverage their collective power to benefit the entire enterprise In this regard, a variety of devices may have applications, objects or resources that may implicate the processes described herem
[0096] Fig 2c provides a schematic diagram of an exemplary networked or distributed computing environment The environment comprises computing devices 271, 272, 276, and 277 as well as objects 273,274, and 275, and database 278 Each ofthese components 271,272,273,274, 275,276,277 and 278 may compnse or make use of programs, methods, data stores, programmable logic, etc The components 271, 272, 273, 274, 275, 276, 277 and 278 may span portions of the same or different devices such as PDAs, audio/video devices, MP3 players, personal computers, etc Each component 271, 272, 273, 274, 275, 276, 277 and 278 can communicate with another component 271, 272, 273, 274, 275, 276, 277 and 278 by way of the communications network 270 In this regard, any entity may be responsible for the maintenance and updating of a database 278 or other storage element
[0097] This network 270 may itself compnse other computing entities that provide services to the system of Fig 2c, and may itself represent multiple interconnected networks In accordance with an aspect ofthe invention, each component 271,272,273, 274, 275,276, 277 and 278 may contain discrete functional program modules that might make use of an API, or other object, software, firmware and/or hardware, to request services of one or more ofthe other components 271, 272, 273,274, 275, 276, 277 and 278
[0098] It can also be appreciated that an object, such as 275, may be hosted on another computing device 276 Thus, although the physical environment depicted may show the connected devices as computers, such illustration is merely exemplary and the physical environment may alternatively be depicted or descnbed compnsing vanous digital devices such as PDAs, televisions, MP3 players, etc, software objects such as interfaces, COM objects and the like
[0099] There are a vanety of systems, components, and network configurations that support distnbuted computing environments For example, computmg systems may be connected together by wired or wireless systems, by local networks or widely distnbuted networks Currently, many networks are coupled to the Internet, which provides an infrastructure for widely distnbuted computing and encompasses many different networks Any such infrastructures, whether coupled to the Internet or not, may be used in conjunction with the systems and methods provided
[0100] A network infrastructure may enable a host of network topologies such as client/server, peer-to-peer, or hybnd architectures The "client" is a member of a class or group that uses the services of another class or group to which it is not related In computing, a chent is a process, l e, roughly a set of instructions or tasks, that requests a service provided by another program The client process utilizes the requested service without having to "know" any working details about the other program or the service itself In a client/server architecture, particularly a
networked system, a client is usually a computer that accesses shared network resources provided by another computer, e g, a server In the example of Fig 2c, any component 271, 272, 273, 274, 275, 276,277 and 278 can be considered a client, a server, or both, depending on the circumstances
[0101] A server is typically, though not necessarily, a remote computer system accessible over a remote or local network, such as the Internet The client process may be active m a first computer system, and the server process may be active in a second computer system, communicating with one another over a communications medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information-gathering capabilities of the server Any software objects may be distributed across multiple computmg devices or objects
[0102] Chent(s) and servers) communicate with one another utilizing the functionality provided by protocol layer(s) For example, HyperText Transfer Protocol (HTTP) is a common protocol that is used in conjunction with the World Wide Web (WWW), or "the Web " Typically, a computer network address such as an Internet Protocol (IP) address or other reference such as a Universal Resource Locator (URL) can be used to identify the server or client computers to each other The network address can be referred to as a URL address Communication can be provided over a communications medium, e g, chent(s) and servers) may be coupled to one another via TCP/IP connection(s) for high-capacity communication
[0103] In hght of the diverse computmg environments that may be built according to the general framework ofprovided in Fig 2a and Fig 2b, and the further diversification tiiat can occur in computing in a network environment such as that of Fig 2c, the systems and methods provided herein cannot be construed as limited in any way to a particular computmg architecture Instead, the present invention should not be limited to any single embodiment, but rather should be construed in breadth and scope in accordance with the appended claims

What is Claimed:
1. system for supporting programmatic retrieval and replay of database trace data, comprising:
a first functional element comprising a plurality of machine readable instructions for retrieving database trace data;
a first exposed function call whereby custom computer processes canprogrammatically initiate the operation of said first functional element;
a second functional element comprising a plurality of machine readable instructions for storing database trace data;
a third functional element comprising a plurality of machine readable instructions for replaying database trace data; and
a third exposed function call whereby custom computer processes can programmatically initiate the operation of said third functional element.
2. The system of claim 1, wherein said second functional element comprises a plurality of machine readable instructions for storing database trace data one or more of a file, a table, and a server.
3. The system of claim 1, further comprising a fourth functional element comprising a plurality of machine readable instructions for modifying stored database trace data.
4. The system of claim 3, further comprising a fourth exposed function call whereby custom computer processes can programmatically initiate the operation of said fourth functional element.
5. The system of claim 1, wherein said first Junctional element comprises one or more objects that inherit from an IDataReader interface.
6. The system of claim 1, wherein said third functional element comprises a plurality of machine readable instructions for notifying a custom computer process prior to replaying trace data.
7. The system of claim 1, wherein said third functional element comprises a plurality of machine readable instructions for notifying a custom computer process when database output from a replay is available for a custom computer process.
8. The system of claim 1, wherein said third functional element comprises a plurality of machine readable instructions for notifying a custom computer process when a replay is stopped.
9. The system of claim 1, wherein said third functional element comprises a plurality of machine readable instructions for a sequential replay mode in which substantially all database service requests for a particular database are replayed.

10. The system of claim 1, wherein said third functional element comprises a plurality of machine readable instructions for a connection level replay mode in which substantially all database service requests sent to a database from an identified client or set of clients are replayed.
11. The system of claim 1, wherein said third functional element comprises a plurality of machine readable instructions for gathering substantially all database output associated with a replay.
12. The system of claim 1, wherein said third functional element comprises a plurality of machine readable instructions for gathering substantially only reported database errors associated with a replay.
13. A method for allowing a computerized process to programmatically retrieve and replay database trace data, comprising:
exposing a first function call for retrieving database trace data, wherein said first function call is exposed to custom computerized processes;
retrieving database trace data in response to invoking said first function call;
storing database trace data in a location specified by one or more of said custom computerized processes or in a location specified as a default location;
exposing a second function call for replaying database trace data, wherein said second function call is exposed to custom computerized processes; and
replaying database trace data in response to invoking said second function call.
14. The method of claim 13, wherein said storing comprises writing database trace data to one or more of a file, a table, and a server.
15. The method of claim 13, wherein said function call for retrieving comprises a plurality of function calls which operate to store database trace data in a plurality of locations, whereby a
storage location can be specified by custom computerized processes by invoking one or more of the plurality of function calls.
16. The method of claim 13, further comprising exposing a fourth function call for modifying database trace data, wherein said fourth function call is exposed to custom computerized processes.
17. The method of claim 16, further comprising modifying database trace data in response to invoking said fourth function call.
18. The method of claim 13, wherein said retrieving database trace data involves one or more objects that inherit from an IDataReader interface.
19. The method of claim 13, further comprising notifying a custom computer process prior to replaying trace data.
20. The system of claim 19, wherein notifying comprises returning an event object to a custom computer process.
21. The system of claim 19, wherein notifying comprises returning a delegate to a custom computer process.
22. The system of claim 19, wherein notifying comprises returning an interface to a custom computer process, wherein said interface defines parameters for modifying trace data records.
23. The system of claim 19, wherein notifying comprises returning an interface to a custom computer process, wherein said interface defines parameters for skipping trace data during said replaying.
24. The method of claim 13, further comprising notifying a custom computer process when database output from a replay is available for a custom computer process.
25. The method of claim 24, wherein notifying comprises returning an event object to a custom computer process.
26. The system of claim 24, wherein said notifying comprises returning a delegate to a custom computer process.
27. The method of claim 13, wherein replaying comprises notifying a custom computer process when a replay is stopped.
28. The method of claim 13, wherein said replaying comprises connecting to a database, wherein
the database is specified by a custom computer process.
29. The method of claim 13, wherein said replaying comprises controlling a size of a thread pool, wherein said thread pool size is specified by a custom computer process.
30. The method of claim 13, wherein said replaying comprises controlling a time interval which one or more elements in the system for supporting programmatic retrieval and replay of database trace data will wait prior to terminating a process that is not progressing.
31. The method of claim 13, wherein said replaying comprises controlling polling frequency for discovering processes that are not progressing.
32 The method of claim 13, wherein said replaying comprises utilizing a sequential replay mode in which substantially all database service requests for a particular database are replayed.
33. The method of claim 13, wherein said replaying comprises utilizing a connection level replay mode in which substantially all database service requests sent to a database from an identified client or set of clients are replayed.
34 The method of claim 13, wherein said replaying comprises gathering substantially all database output associated with a replay.
35 The method of claim 13, wherein said replaying comprises gathering substantially only reported database errors associated with a replay.
36 A computer readable medium bearing instructions for allowing a computerized process to programmatically retrieve and replay database trace data, comprising:
instructions for exposing a first function call for retrieving database trace data, wherein said first function call is exposed to custom computerized processes;
instructions for retrieving database trace data in response to invoking said first function call;
instructions for storing database trace data in a location specified by one or more of said custom computerized processes or in a location specified as a default location;
instructions for exposing a second function call for replaying database trace data, wherein said second function call is exposed to custom computerized processes; and
instructions for replaying database trace data in response to invoking said second function call.
37. A computer readable medium according to claim 36 wherein said instructions for storing comprise instructions for writing database trace data to one or more of a file, a table, and a server.
39. A computer readable medium according to claim 36 wherein said instructions for exposing a first function call for retrieving comprises instructions for a plurality of function calls which operate to store database trace data in a plurality of locations, whereby a storage location can be specified by custom computerized processes by invoking one or more of the plurality of function calls.
39. A computer readable medium according to claim 36 further comprising instructions for exposing a fourth function call for modifying database trace data, wherein said fourth function call is exposed to custom computerized processes.
40. A computer readable medium according to claim 39 further comprising instructions for modifying database trace data in response to invoking said fourth function call.
41. A computer readable medium according to claim 36, wherein said instructions for retrieving database trace data comprise one or more objects that inherit from an IDataReader interface.
computer readable medium according to claim 36 further comprising instructions for notifying a custom computer process prior to replaying trace data.
44. A computer readable medium according to claim 42 wherein instructions for notifying comprise instructions for returning an event object to a custom computer process.
45. A computer readable medium according to claim 42, wherein said instructions for notifying comprise instructions for returning an interface to a custom computer process, and wherein said interface defines parameters for modifying trace data.
45. A computer readable medium according to claim 42, wherein said instructions for notifying comprise instructions for returning an interface to a custom computer process, wherein said interface defines parameters for skipping trace data during said replaying.
46. A computer readable medium according to claim 42 wherein instructions for notifying comprise instructions for returning a delegate to a custom computer process.
47. A computer readable medium according to claim 36, further comprising instructions for notifying a custom computer process when database output from a replay is available for a custom computer process.
48. A computer readable medium according to claim 47, wherein instructions for notifying comprise instructions for returning an event object to a custom computer process.

49. A computer readable medium according to claim 4$, wherein said instructions for notifying comprise instructions for returning a delegate to a custom computer process.
50 A computer readable medium according to claim 36 wherein said instructions for replaying comprise instructions for notifying a custom computer process when a replay is stopped.
5z. A computer readable medium according to claim 36 wherein said instructions for replaying comprise instructions for connecting to a database, wherein the database is specified by a custom computer process.
computer readable medium according to claim 36 wherein said instructions for replaying comprise instructions for utilizing a sequential replay mode in which substantially all database service requests for a particular database are replayed.
53. A computer readable medium according to claim 36 wherein said instructions for replaying comprise instructions for utilizing a connection level replay mode in which substantially all database service requests sent to a database from an identified client or set of clients are replayed.
54 A computer readable medium according to claim 36 wherein said instructions for replaying comprise instructions for gathering substantially all database output associated with a replay.
55 A computer readable medium according to claim 36 wherein said instructions for replaying comprise instructions for gathering substantially only reported database errors associated with a replay.