U.S. patent application number 14/506935 was filed with the patent office on 2015-01-29 for getting dependency metadata using statement execution plans.
The applicant listed for this patent is Microsoft Corporation. Invention is credited to David I. Noor, Kaarthik Sivashanmugam.
Application Number | 20150032703 14/506935 |
Document ID | / |
Family ID | 44912636 |
Filed Date | 2015-01-29 |
United States Patent
Application |
20150032703 |
Kind Code |
A1 |
Sivashanmugam; Kaarthik ; et
al. |
January 29, 2015 |
GETTING DEPENDENCY METADATA USING STATEMENT EXECUTION PLANS
Abstract
A database statement can be identified in a software artifact
that is configured to issue the database statement. At least one
execution plan for the database statement can be retrieved, and
reference(s) to database object(s) can be identified in the
execution plan(s). Metadata from the reference(s) can be assembled,
where the metadata can reflect one or more dependencies of the
software artifact on the object(s). The metadata can be included in
a data structure.
Inventors: |
Sivashanmugam; Kaarthik;
(Bellevue, WA) ; Noor; David I.; (Redmond,
WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Microsoft Corporation |
Redmond |
WA |
US |
|
|
Family ID: |
44912636 |
Appl. No.: |
14/506935 |
Filed: |
October 6, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12778128 |
May 12, 2010 |
8862563 |
|
|
14506935 |
|
|
|
|
Current U.S.
Class: |
707/692 ;
707/705 |
Current CPC
Class: |
G06F 16/1748 20190101;
G06F 16/907 20190101; G06F 16/2455 20190101 |
Class at
Publication: |
707/692 ;
707/705 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. A computer system comprising: at least one processor; and a
memory comprising instructions stored thereon that when executed by
the at least one processor cause the at least one processor to
perform acts comprising: identifying a database statement in a
software artifact that is configured to issue the database
statement, the database statement being a request to perform an
operation on a database or a reference to the request; retrieving
at least one execution plan for the database statement, the at
least one execution plan identifying sub-operations to be performed
in accomplishing an overall operation according to the database
statement; identifying in the at least one execution plan one or
more references to one or more database objects; assembling
metadata from the one or more references, the metadata reflecting
one or more dependencies of the software artifact on the one or
more database objects; and including the metadata in a data
structure.
2. The computer system of claim 1, wherein the acts further
comprise using the metadata to perform one or more impact analysis
operations.
3. The computer system of claim 1, wherein the acts further
comprise using the metadata to determine data lineage of a software
artifact that includes the database statement.
4. The computer system of claim 1, wherein the performing of the
acts is done without receiving user input that identifies one or
more names of the one or more database objects.
5. The computer system of claim 1, wherein the acts further
comprise augmenting other dependency metadata with the metadata
from the one or more references, the other dependency metadata
being metadata extracted without identifying references in a
database statement execution plan.
6. The computer system of claim 1, wherein the acts further
comprise correlating the metadata, wherein correlating comprises
determining that the metadata includes one or more duplicate
metadata entries, and wherein the acts further comprise, in
response to determining that the metadata include the one or more
duplicate entries, eliminating the one or more duplicate
entries.
7. The computer system of claim 1, wherein: the metadata comprises
multiple entries; and the acts further comprise: correlating the
metadata; eliminating one or more duplicate entries in the metadata
found while correlating the metadata; and augmenting other
dependency metadata with the metadata from the one or more
references, the other dependency metadata being metadata extracted
without identifying references in a database statement execution
plan.
8. A computer-implemented method comprising: identifying a database
statement in a software artifact that is configured to issue the
database statement, the database statement being a request to
perform an operation on a database or a reference to the request;
retrieving at least one execution plan for the database statement,
the at least one execution plan identifying sub-operations to be
performed in accomplishing an overall operation according to the
database statement; identifying in the at least one execution plan
one or more references to one or more database objects; and
assembling metadata from the one or more references, the metadata
reflecting one or more dependencies of the software artifact on the
one or more database objects, and the assembling of the metadata
comprising including the metadata in a data structure.
9. The method of claim 8, wherein the method further comprises
using the metadata to perform one or more impact analysis
operations.
10. The method of claim 8, wherein the method further comprises
using the metadata to determine data lineage of a software artifact
that includes the database statement.
11. The method of claim 8, wherein the method is performed without
receiving user input that identifies one or more names of the one
or more database objects.
12. The method of claim 8, wherein the metadata comprises multiple
entries and the method further comprises correlating the
metadata.
13. The method of claim 12, wherein correlating comprises
determining that the metadata includes one or more duplicate
entries, and the method further comprises, in response to
determining that the metadata includes one or more duplicate
entries, eliminating the one or more duplicate entries.
14. The method of claim 8, wherein the method further comprises
augmenting other dependency metadata with the metadata from the one
or more references, and wherein the other dependency metadata
comprises metadata extracted without identifying references in a
database statement execution plan.
15. One or more computer-readable storage media having
computer-executable instructions embodied thereon that, when
executed by at least one processor, cause the at least one
processor to perform acts comprising: identifying a database
statement in a software artifact that is configured to issue the
database statement, the database statement being a request to
perform an operation on a database or a reference to the request;
retrieving at least one execution plan for the database statement,
the at least one execution plan identifying sub-operations to be
performed in accomplishing an overall operation according to the
database statement; identifying in the at least one execution plan
one or more references to one or more database objects; and
assembling metadata from the one or more references, the metadata
reflecting one or more dependencies of the software artifact on the
one or more database objects, and the assembling of the metadata
comprising including the metadata in a data structure.
16. The one or more computer-readable storage media of claim 15,
wherein the acts further comprise using the metadata to perform one
or more impact analysis operations.
17. The one or more computer-readable storage media of claim 15,
wherein the acts further comprise using the metadata to determine
data lineage of a software artifact that includes the database
statement.
18. The one or more computer-readable storage media of claim 15,
wherein the performing of the acts is done without receiving user
input that identifies one or more names of the one or more database
objects.
19. The one or more computer-readable storage media of claim 15,
wherein the acts further comprise augmenting other dependency
metadata with the metadata from the one or more references, and
wherein the other dependency metadata comprises metadata extracted
without identifying references in an execution plan.
20. The one or more computer-readable storage media of claim 15,
wherein the acts further comprise correlating the metadata and
eliminating one or more duplicate entries identified while
correlating the metadata.
Description
RELATED APPLICATIONS
[0001] The present application is a continuation of U.S.
application Ser. No. 12/778,128, filed May 12, 2010, which is
incorporated herein by reference. If any disclosures are
incorporated herein by reference and such incorporated disclosures
conflict in part or whole with the present disclosure, then to the
extent of conflict, and/or broader disclosure, and/or broader
definition of terms, the present disclosure controls. If such
incorporated disclosures conflict in part or whole with one
another, then to the extent of conflict, the later-dated disclosure
controls.
BACKGROUND
[0002] A database may store dependency information for its objects
in its system catalogs and/or views, or using some other mechanism.
Such dependency information may be used for impact analysis, data
lineage, and/or some other functionality.
SUMMARY
[0003] The tools and techniques described herein relate to using
database statement execution plans to obtain dependency metadata
(i.e., metadata that represents dependencies between objects). As
used herein, a database statement is a request to perform an
operation on a database or a reference to such a request. For
example, the request may be a request to modify at least a portion
of a database, a request to perform a query on a database, etc. A
database statement may be in a particular language, such as a
structured query language (SQL) dialect. An execution plan is a
data structure that lists sub-operations to be performed in
accomplishing the overall operation requested by a database
statement.
[0004] In an embodiment, the tools and techniques can include
identifying a database statement in a software artifact that is
configured to issue the database statement. A software artifact
refers to a software component on one or more computer readable
media, where the software component can use database statements.
The software artifact may be in any of various forms, such as a
program or portion of a program, instructions executed by a
program, a SQL Server.RTM. Integration Services (SSIS) package,
etc. At least one execution plan for the database statement can be
retrieved, and reference(s) to database object(s) can be identified
in the execution plan(s). Metadata from the reference(s) (i.e.,
metadata extracted using the reference(s)) can be assembled, where
the metadata can reflect one or more dependencies of the software
artifact on the object(s). The metadata can be included in a data
structure.
[0005] This Summary is provided to introduce a selection of
concepts in a simplified form. The concepts are further described
below in the Detailed Description. This Summary is not intended to
identify key features or essential features of the claimed subject
matter, nor is it intended to be used to limit the scope of the
claimed subject matter. Similarly, the invention is not limited to
implementations that address the particular techniques, tools,
environments, disadvantages, or advantages discussed in the
Background, the Detailed Description, or the attached drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 is a block diagram of a suitable computing
environment in which one or more of the described embodiments may
be implemented.
[0007] FIG. 2 is schematic diagram of a dependency metadata
environment.
[0008] FIG. 3 is a flowchart of a technique for getting dependency
metadata using database statement execution plans.
[0009] FIG. 4 is a flowchart of another technique for getting
dependency metadata using database statement execution plans.
[0010] FIG. 5 is a flowchart of yet another technique for getting
dependency metadata using database statement execution plans.
DETAILED DESCRIPTION
[0011] Embodiments described herein are directed to techniques and
tools for improved retrieval and assembly of dependency metadata by
using database statement execution plans. Such improvements may
result from the use of various techniques and tools separately or
in combination.
[0012] Such techniques and tools may include getting dependency
information of a database statement by sending the statement to a
database server and requesting execution plan(s) for the statement.
The information in the execution plan(s) can be used to identify
the statements' dependencies on the objects in the server. For
example, a database statement may be identified in a software
artifact, and an execution plan for the database statement may be
retrieved from a database server. The retrieved execution plan can
be parsed, and references in the execution plan to objects can be
identified. Using those references, dependency metadata can be
assembled. The dependency metadata can reflect dependencies of the
software artifact on the objects referenced in the execution plan.
The dependency metadata can also be processed by correlating it
(i.e., by comparing different parts of the metadata, such as to
identify duplicates), removing duplicates that may be found,
assembling the metadata, and using the metadata to augment other
dependency metadata (e.g., metadata extracted for other database
statements using the same technique, and/or metadata extracted
using other techniques that may not use execution plans).
[0013] Accordingly, one or more substantial benefits can be
realized from the tools and techniques described herein. For
example, the information available in an execution plan generated
by a database server can be used to extract dependency metadata for
a database statement corresponding to the plan. Thus, dependency
data can be extracted for a software artifact that is configured to
issue that statement. Accordingly, dependency metadata for a
software artifact may be identified and assembled without a user
even identifying object names to provide to a database server.
[0014] However, the subject matter defined in the appended claims
is not necessarily limited to the benefits described herein. A
particular implementation of the invention may provide all, some,
or none of the benefits described herein. Although operations for
the various techniques are described herein in a particular,
sequential order for the sake of presentation, it should be
understood that this manner of description encompasses
rearrangements in the order of operations, unless a particular
ordering is required. For example, operations described
sequentially may in some cases be rearranged or performed
concurrently. Techniques described herein with reference to
flowcharts may be used with one or more of the systems described
herein and/or with one or more other systems. For example, the
various procedures described herein may be implemented with
hardware or software, or a combination of both. Moreover, for the
sake of simplicity, flowcharts may not show the various ways in
which particular techniques can be used in conjunction with other
techniques.
I. Exemplary Computing Environment
[0015] FIG. 1 illustrates a generalized example of a suitable
computing environment (100) in which one or more of the described
embodiments may be implemented. For example, one or more such
computing environments can be used as a database server and/or an
environment for getting dependency metadata using database
statement execution plans. Generally, various different general
purpose or special purpose computing system configurations can be
used. Examples of well-known computing system configurations that
may be suitable for use with the tools and techniques described
herein include, but are not limited to, server farms and server
clusters, personal computers, server computers, hand-held or laptop
devices, multiprocessor systems, microprocessor-based systems,
programmable consumer electronics, network PCs, minicomputers,
mainframe computers, distributed computing environments that
include any of the above systems or devices, and the like.
[0016] The computing environment (100) is not intended to suggest
any limitation as to scope of use or functionality of the
invention, as the present invention may be implemented in diverse
general-purpose or special-purpose computing environments.
[0017] With reference to FIG. 1, the computing environment (100)
includes at least one processing unit (110) and memory (120). In
FIG. 1, this most basic configuration (130) is included within a
dashed line. The processing unit (110) executes computer-executable
instructions and may be a real or a virtual processor. In a
multi-processing system, multiple processing units execute
computer-executable instructions to increase processing power. The
memory (120) may be volatile memory (e.g., registers, cache, RAM),
non-volatile memory (e.g., ROM, EEPROM, flash memory), or some
combination of the two. The memory (120) stores software (180) that
can include one or more software applications implementing getting
dependency metadata using database statement execution plans.
[0018] Although the various blocks of FIG. 1 are shown with lines
for the sake of clarity, in reality, delineating various components
is not so clear and, metaphorically, the lines of FIG. 1 and the
other figures discussed below would more accurately be grey and
blurred. For example, one may consider a presentation component
such as a display device to be an I/O component. Also, processors
have memory. The inventors hereof recognize that such is the nature
of the art and reiterate that the diagram of FIG. 1 is merely
illustrative of an exemplary computing device that can be used in
connection with one or more embodiments of the present invention.
Distinction is not made between such categories as "workstation,"
"server," "laptop," "handheld device," etc., as all are
contemplated within the scope of FIG. 1 and reference to
"computer," "computing environment," or "computing device."
[0019] A computing environment (100) may have additional features.
In FIG. 1, the computing environment (100) includes storage (140),
one or more input devices (150), one or more output devices (160),
and one or more communication connections (170). An interconnection
mechanism (not shown) such as a bus, controller, or network
interconnects the components of the computing environment (100).
Typically, operating system software (not shown) provides an
operating environment for other software executing in the computing
environment (100), and coordinates activities of the components of
the computing environment (100).
[0020] The storage (140) may be removable or non-removable, and may
include non-transitory computer-readable storage media such as
magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs,
or any other medium which can be used to store information and
which can be accessed within the computing environment (100). The
storage (140) stores instructions for the software (180).
[0021] The input device(s) (150) may be a touch input device such
as a keyboard, mouse, pen, or trackball; a voice input device; a
scanning device; a network adapter; a CD/DVD reader; or another
device that provides input to the computing environment (100). The
output device(s) (160) may be a display, printer, speaker,
CD/DVD-writer, network adapter, or another device that provides
output from the computing environment (100).
[0022] The communication connection(s) (170) enable communication
over a communication medium to another computing entity. Thus, the
computing environment (100) may operate in a networked environment
using logical connections to one or more remote computing devices,
such as a personal computer, a server, a router, a network PC, a
peer device or another common network node. The communication
medium conveys information such as data or computer-executable
instructions or requests in a modulated data signal. A modulated
data signal is 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
include wired or wireless techniques implemented with an
electrical, optical, RF, infrared, acoustic, or other carrier.
[0023] The tools and techniques can be described in the general
context of computer-readable media. Computer-readable media are any
available media that can be accessed within a computing
environment. By way of example, and not limitation, with the
computing environment (100), computer-readable media include memory
(120), storage (140), and combinations of the above.
[0024] The tools and techniques can be described in the general
context of computer-executable instructions, such as those included
in program modules, being executed in a computing environment on a
target real or virtual processor. Generally, program modules
include routines, programs, libraries, objects, classes,
components, data structures, etc. that perform particular tasks or
implement particular abstract data types. The functionality of the
program modules may be combined or split between program modules as
desired in various embodiments. Computer-executable instructions
for program modules may be executed within a local or distributed
computing environment. In a distributed computing environment,
program modules may be located in both local and remote computer
storage media.
[0025] For the sake of presentation, the detailed description uses
terms like "determine," "choose," "adjust," and "operate" to
describe computer operations in a computing environment. These and
other similar terms are high-level abstractions for operations
performed by a computer, and should not be confused with acts
performed by a human being, unless performance of an act by a human
being (such as a "user") is explicitly noted. The actual computer
operations corresponding to these terms vary depending on the
implementation.
II. System and Environment for Getting Metadata Using Database
Statement Execution Plans
[0026] FIG. 2 is a block diagram of a dependency metadata
environment (200) in conjunction with which one or more of the
described embodiments may be implemented. The dependency metadata
environment (200) can include a software artifact (210), which can
include database statements, or in other words the software
artifact (210) can include instructions to issue one or more
database statements, such as by issuing the statements to one or
more database servers. The illustrated software artifact (210) in
FIG. 2 can include two database statements: statement 1 (212) and
statement 2 (216). Database statement 1 (212) can be issued to
database server 1 (220), and the processing of statement 1 (212) by
database server 1 (220) can depend on one or more objects (222),
which may be accessed locally and/or remotely by database server 1
(220). Thus, the processing of statement 1 (212) and the processing
of the software artifact (210) depends on the state and
availability of the objects (222). Database statement 2 (216) can
be issued to another database server, database server 2 (230), and
the processing of statement 2 (216) by database server 2 (230) can
depend on one or more objects (232), which can be accessed locally
and/or remotely by database server 2 (230). For example, the
database servers (220 and 230) can be servers for relational
databases, and they can respond to SQL language database
statements.
[0027] In processing database statement 1 (212), database server 1
(220) can follow an execution plan, execution plan 1 (240).
Execution plan 1 (240) may be generated by database server 1 (220)
upon receiving database statement 1 (212). Alternatively, plan 1
(240) may be a pre-existing plan. For example, database server 1
(220) may cache execution plans that are generated, so that the
plans can be reused when the same database statement is received
again at a later time. Similarly, database server 2 (230) can
follow another execution plan, execution plan 2 (250), when
processing database statement 2 (216).
[0028] Referring still to FIG. 2, the dependency metadata
environment (200) can also include a metadata extraction
environment (260). For example, the metadata extraction environment
(260) can include one or more database servers and/or database
clients, or it may be in a separate system, such as a separate
system dedicated to dependency metadata extraction and/or to impact
analysis and lineage assessments. The metadata extraction
environment (260) can perform an identify statements operation
(262) to identify the statements (212 and 216) from the software
artifact (210). The identify statements operation (262) can be
performed by parsing the software artifact (210) and extracting
identified statements (212 and 216). Alternatively, the identify
statements operation (262) may be performed in some other manner,
such as by executing the software artifact (210) and analyzing
statements (212 and 216) issued by the software artifact as the
artifact executes.
[0029] The metadata extraction environment (260) can also perform a
get plans operation (264), which can include retrieving from
database servers (220 and 230) execution plans (240 and 250) for
the identified statements (212 and 216). This may include
retrieving more than one execution plan per database statement,
such as where a database statement is processed in multiple
batches, with one execution plan being generated for each
batch.
[0030] The metadata extraction environment (260) can also perform a
parsing and reference identification operation (266) on the
retrieved execution plans (240 and 250) to identify object
references in the plans (240 and 250). Such object references in an
execution plan (240 or 250) can reveal the objects (222 or 232)
that the processing of the corresponding statement (212 and 216)
depends on. Thus, the references to objects in an execution plan
(240 or 250) can show that the processing of the corresponding
statement (212 or 216) depends on those objects, and thus that the
software artifact (210) that would issue the corresponding
statement (212 or 216) also depends on those objects. Performing
the parsing and reference identification operation (266) may
include invoking a parsing module for a particular language dialect
(e.g., a particular SQL dialect) or a particular database server
type. For example, one parser may be used for execution plans from
Microsoft SQL Server.RTM. database servers, another parser may be
used for execution plans from Oracle database servers, and other
parsers may be used for other types of database servers. The
corresponding parser can parse the execution plan, and translate
the results into a form that is useable by other components of the
metadata extraction environment (260).
[0031] Using those references identified in the plans (240 and
250), the metadata extraction environment (260) can perform a
correlation, assembly, and augmentation operation (272) on the
resulting dependency metadata (270). The correlation can include
comparing and determining correlations between different entries in
the dependency metadata (270), which may include determining
whether any duplicate entries are present in the dependency
metadata (270). This can be done using known sorting and/or
matching techniques. Such duplicates can then be eliminated, such
as by deleting one out of two duplicate references. Assembling can
include assembling references identified in an execution plan (240
or 250) into dependency metadata (270) in a data structure,
possibly after translating, storing, or otherwise processing the
references and/or data structure. Similarly, augmenting can include
using the dependency metadata (270) to augment other dependency
metadata (possibly after correlating the dependency metadata
extracted using the execution plan (240 or 250) with the other
dependency metadata). For example, the other dependency metadata
may include metadata that was extracted from other execution
plan(s) (e.g., augmenting dependency metadata extracted using plan
1 (240) and metadata extracted using plan 2 (250)) and/or
dependency metadata obtained by some other technique, such as a
technique that does not involve extracting the metadata using
execution plans. For example, the other metadata may have been
obtained by sending requests for dependency metadata for particular
objects to one or more database servers.
[0032] The metadata extraction environment (260) can also perform a
metadata publication and use operation (274), which can include
publishing the dependency metadata (270) in a metadata repository
(280) and using the dependency metadata (270), such as in impact
analysis and lineage operations. For example, this can include
using the dependencies metadata in the metadata repository (280)
for impact analysis and for determining data lineage of the
software artifact (210), the statements (212 and 216), and/or the
objects (222 and 232). Such impact analysis and lineage operations
may be performed using existing operations, such as existing data
lineage queries and existing impact analysis techniques.
[0033] While the operations (262, 264, 266, 272, and 274) have been
described as being performed in one metadata extraction environment
(260), the operations could be performed in different environments.
For example, use of the published metadata may be performed in a
different environment. As another example, the identify statements
operation (262) may be performed in a different environment from
the get plans operation (264) and the parsing and reference
identification operation (266).
[0034] An example will now be discussed for extracting metadata
using an execution plan for a specific database statement from a
software artifact. A software artifact may include the following
SQL database statement: "SELECT*FROM ABC". This statement requests
the selection of all columns (as indicated by the use of "*") from
an object named ABC. For example, ABC may be the name of a database
table in a database named DB, and the ABC database table may have
six columns named COL1, COL2, COL3, COL4, COL5, and COL6. An
extraction environment can parse the software artifact and identify
the "SELECT*FROM ABC" database statement within the artifact. The
extraction environment can also request an execution plan for this
database statement. This request can be made to the same database
server to which the database statement will be sent when the
software artifact executes. Execution plans may be retrieved in
various different formats, depending on the type of database server
that will be providing the plan. For example, plans may be
estimated execution plans that can be generated without actually
processing the database statement, or actual execution plans that
are generated when database statements are actually processed. It
may be desirable for the retrieved execution plan to be an
estimated plan, so that resources are not used in actually
processing the database statement. Additionally, execution plans
may be provided in different formats, such as XML formats or plain
text formats. As one example, in a SQL Server.RTM. environment, the
following commands can be used to retrieve an XML version of an
estimated execution plan for the "SELECT*FROM ABC" database
statement:
[0035] GO
[0036] SET SHOWPLAN_XML ON;
[0037] GO
[0038] SELECT*
[0039] FROM ABC;
[0040] GO
[0041] SET SHOWPLAN_XML OFF;
[0042] GO
[0043] The returned execution plan can be loaded and parsed. In
this case, the parsing will reveal in the execution plan references
to the database DB, the database table ABC, and the columns COL1,
COL2, COL3, COL4, COL5, and COL6. This in turn reveals that the
software artifact that includes the "SELECT*FROM ABC" statements
depends on these objects. Accordingly, the references to these
objects can be assembled into dependency metadata and correlated,
and the dependency metadata may be used to augment other metadata
of the software artifact. The dependency metadata can be published
in a metadata repository so that it can be used, such as in
performing impact analysis and lineage operations.
III. Techniques for Getting Dependency Metadata Using Database
Statement Execution Plans
[0044] Several techniques for getting dependency metadata using
database statement execution plans will now be discussed. Each of
these techniques can be performed in a computing environment. For
example, each technique may be performed in a computer system that
includes at least one processor and a memory including instructions
stored thereon that when executed by the at least one processor
cause the at least one processor to perform the technique (a memory
stores instructions (e.g., object code), and when the processor(s)
execute(s) those instructions, the processor(s) perform(s) the
technique). Similarly, one or more computer-readable storage media
may have computer-executable instructions embodied thereon that,
when executed by at least one processor, cause the at least one
processor to perform the technique.
[0045] Referring to FIG. 3, a technique for getting dependency
metadata using database statement execution plans will be
discussed. The technique can include retrieving (310) from a
database server at least one execution plan for a database
statement. For example, the database statement may be a SQL
statement. Also, the database statement may be a statement
identified in a software artifact. One or more references to one or
more objects can be identified (320) in the execution plan(s).
Metadata from the reference(s) can be assembled (330) in a data
structure on one or more computer readable storage media. Also, the
metadata can reflect one or more dependencies on the object(s),
such as dependencies of the software artifact on the object(s).
[0046] Additionally, other dependency metadata can be augmented
with the metadata from the reference(s). The other dependency
metadata can include metadata identified in one or more other
execution plans for one or more other database statements. Also,
the other metadata may include metadata extracted without
identifying references in a database statement execution plan.
[0047] The metadata from the reference(s) may include multiple
entries, and the technique can include correlating (340) the
metadata. Additionally, correlating (340) can include determining
(350) whether the metadata includes one or more duplicate entries.
If so, then the technique can include eliminating (360) the one or
more duplicate entries. The at least one execution plan can include
multiple execution plans. For example, there may be more than one
execution plan per database statement, as discussed above (e.g.,
one execution plan per batch). Additionally, there may be multiple
database statements in the software artifact, with one or more
execution plans per database statement. Additionally, the one or
more references can include at least one reference in each of two
or more of the multiple execution plans.
[0048] Referring now to FIG. 4, another technique for getting
dependency metadata using database statement execution plans will
be discussed. In the technique, a database statement, such as a SQL
statement, can be identified (410) in a software artifact. At least
one execution plan for the database statement can be retrieved
(420), and one or more references to one or more objects can be
identified (430) in the execution plan(s). Metadata from the
reference(s) can be assembled (440) in a data structure. The
metadata can reflect one or more dependencies of the software
artifact on the object(s).
[0049] The reference(s) can include multiple references, and the
technique can include correlating the metadata. The correlation can
include determining whether the metadata includes one or more
duplicate entries. If so, then the technique can further include
eliminating the duplicate entry or entries. The technique can also
include augmenting other dependency metadata with the metadata from
the reference(s). For example, the other dependency metadata may
include metadata identified in one or more other execution plans
for one or more other database statements and/or dependency
metadata extracted without identifying statements in a database
statement execution plan.
[0050] Referring now to FIG. 5, yet another technique for getting
dependency metadata using database statement execution plans will
be discussed. The technique can include retrieving (510) at least
one execution plan for a database statement, such as a SQL
statement. The database statement may be a statement identified in
a software artifact. One or more references to one or more objects
can be identified (520) in the execution plan(s). Moreover,
metadata from the reference(s) can be assembled (530) in a data
structure. The metadata can reflect one or more dependencies on the
object(s). The one or more dependencies can be one or more
dependencies of the software artifact on the object(s). The
technique can also include augmenting (540) other dependency
metadata with the metadata from the reference(s). The other
dependency metadata can include metadata extracted without
identifying statements in an execution plan and/or metadata
identified in one or more other execution plans for one or more
other database statements. The technique may also include
correlating the metadata and eliminating one or more duplicate
entries identified while correlating the metadata.
[0051] Although the subject matter has been described in language
specific to structural features and/or methodological acts, it is
to be understood that the subject matter defined in the appended
claims is not necessarily limited to the specific features or acts
described above. Rather, the specific features and acts described
above are disclosed as example forms of implementing the
claims.
* * * * *