Methods for resource consolidation in a computing environment

[0002] The present application claims the benefit of priority of commonly-owned provisional application serial No. 60,046,757, filed May 16, 1997, and entitled, METHODS FORRESOURCECONSOLIDATION IN ACOMPUTINGENVIRONMENT, the disclosure of which is hereby incorporated by reference.

[0003] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright 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 file or records, but otherwise reserves all copyright rights whatsoever.

[0004] The present invention relates generally to methodologies for consolidating resources in processing environments, such as a networked environment operating SQL database servers.

[0005] Computers are very powerful tools for storing and providing access to vast amounts of information. For instance, computer database servers are a common mechanism for storing information on computer systems while providing easy access to users. To support multiple clients concurrently accessing the system, the system must employ some sort of mechanism for managing its resources—that is, the devices, software, services, and subsystems which comprise the system. One approach is to provide resource management groups which are hierarchically formed. For instance, each resource management group may include a resource management process for managing resources allocated to its group, at least one process which is a descendant of the resource management process and not included in other resource management groups, and a resource management block for storing information on the resources managed by its own group. The resource management processes can be linked to each other in accordance with parent-child relationships between the respective resource management groups to form a resource management tree.

[0006] Each day more and more businesses are run from mission-critical systems which store information on resource-intensive systems, such as server-based SQL database systems. As a result, increasingly higher demands are being placed on those systems to provide enterprise-wide decision support. Accordingly, there is much interest in improving the performance of such system, particularly in terms of resource management. Accordingly, there is much interest in improving methodologies for managing and consolidating resources.

[0007] The present invention comprises a resource methodology which provides a framework for defining specific resource classes support for resource methods, and provides support for resource-independent commands, including those used in resource consolidation.

[0008] A Resource Consolidation methodology of the present invention works by starting with an empty resource set, then iteratively extends the set in a minimal fashion. At the end of the iteration, the initial resource set comprises sufficient resources. An important component to this approach is a Minimal Extension method. This method provides a directed, acyclic graph methodology that takes two graphs as input and extends one (the “primary”) so as to include the other one (the “secondary”). For efficiency, resources in the secondary graph are shared with those in the primary graph wherever possible.

[0009] The intent of the method is to add the contents of the secondary graph to the primary graph, sharing nodes wherever the graphs are compatible, while retaining the topology of the secondary graph, and doing so in a minimal amount of time. The Minimal Extension methodology is itself composed of submethods or sub-algorithms. The method iterates through each node in the secondary graph, and extends the primary if necessary to contain the node, using an Extend method. Extend first checks if the given node is compatible with a node in the primary. If not, it adds the node to the primary. These two steps (i.e., checking compatibility, and adding to the primary) would be easy if they did not have edges coming out of them, but since they may have edges, both of these methods are made more complicated.

[0010] A compatibility check, called Unify, checks not only the node itself but any descendants of the node. Unify compares the node against each node in the primary, invoking a Compare function. Compare first checks that the nodes are directly compatible (ignoring any descendants), then recursively invokes Compare to check whether the descendants are compatible between the two graphs. When Unify finds a compatible subgraph (a subgraph is a node plus its descendants), it returns. A graph addition algorithm, Add, is invoked if the node is not found to be compatible. It copies the node from the secondary graph to the primary graph, then minimally extends the primary graph to include the node's descendants, and finally adds the edges from the current node to the resulting nodes in the subgraph. Note that due to the minimal extension of the descend ants, Add is also recursive.

[0011] FIG. 1 is a block diagram illustrating a computer system in which the present invention may be embodied.

[0012] FIGS. 2-6 are diagrams of directed graphs, providing examples of operation of the resource consolidation methodology of the present invention.

[0013] FIGS. 7-8 are diagrams illustrating the problem of using a single virtual bindings map.

[0014] System Hardware

[0015] The invention may be embodied on a computer system such as the system 100 of FIG. 1, which comprises a central processor 101, a main memory 102, an input/output controller 103, a keyboard 104, a pointing device 105 (e.g., mouse, track ball, pen device, or the like), a screen display device 106, and a mass storage 107 (e.g., hard or fixed disk, removable disk, optical disk, magneto-optical disk, or flash memory). Processor 101 includes or is coupled to a cache memory 109 for storing frequently accessed information; memory 109 may be an on-chip cache or external cache (as shown). Additional output device(s) 108, such as a printing device, may be included in the system 100 as desired. As shown, the various components of the system 100 communicate through a system bus 110 or similar architecture. The system 100 may include, for instance, an IBM-compatible personal computer system, available from a variety of vendors (including IBM of Armonk, N.Y.).

[0016] Resource Consolidation in a Computing Environment

[0017] A. Introduction

[0018] The present invention comprises a computer-implemented (i.e., implemented in system 100) resource methodology which provides a framework for defining specific resource classes support for resource methods, and provides support for resource-independent commands, including those used in resource consolidation. Of the above features, the resource consolidation is the most complex in design.

[0019] B. Overview of Resource Consolidation Methodology

[0020] The Resource Consolidation methodology works by starting with an empty resource set, then iteratively extends the set in a minimal fashion. At the end of the iteration, the initial resource set comprises sufficient resources. An important component to this approach is a Minimal Extension method. This method provides a directed, acyclic graph methodology that takes two graphs as input and extends one (the “primary”) so as to include the other one (the “secondary”). For efficiency, resources in the secondary graph are shared with those in the primary graph wherever possible.

[0021] The following discussion will refer to the graphs shown in FIG. 2. Numbers are edge labels. Edges from a node with only one child are unlabeled. The intent of the method is to add the contents of the secondary graph to the primary graph, sharing nodes wherever the graphs are compatible, while retaining the topology of the secondary graph, and doing so in a minimal amount of time. The Minimal Extension methodology is itself composed of submethods or sub-algorithms. The method iterates through each node in the secondary graph, and extends the primary if necessary to contain the node, using an Extend method. Extend first checks if the given node is compatible with a node in the primary. If not, it adds the node to the primary. These two steps (i.e., checking compatibility, and adding to the primary) would be easy if they did not have edges coming out of them, but since they may have edges, both of these methods are made more complicated.

[0022] The compatibility check, called Unify, checks not only the node itself, but any descendants of the node. Unify compares the node against each node in the primary, invoking a Compare function. Compare first checks that the nodes are directly compatible (ignoring any descendants), then recursively invokes Compare to check whether the descendants are compatible between the two graphs. When Unify finds a compatible subgraph (a subgraph is a node plus its descendants), it returns.

[0023] A graph addition algorithm, Add, is invoked if the node is not found to be compatible. It copies the node from the secondary graph to the primary graph, then minimally extends the primary graph to include the node's descendants, and finally adds the edges from the current node to the resulting nodes in the subgraph. Note that due to the minimal extension of the descendants, Add is also recursive.

[0024] There are a number of factors that complicate this approach. One is that the information in the graphs is richer than that described above. Each edge has a label, and each node has a class. Multiple descendants of a node may have the same label. Each node in a class is guaranteed to have the same labeled edges, although the number of edges with a given label may be different for different classes. For instance, both a and A have edges labeled 1, 2, and 3, although A has two edges labeled 3. Compare must ensure that the classes and labels are compatible. Thus, a and A might match because they are of the same class, but b and C are definitely not compatible. All this information complicates the approach, but actually improves the running time, since it can be used to filter out nodes without doing a full node comparison.

[0025] Another factor is that if the secondary graph has multiple subgraphs that are compatible with one subgraph in the primary, then the above description might result in the secondary subgraphs being mapped onto the same subgraph in the primary, which is not what is desired. For instance, the subgraphs rooted at b and e might both be compatible with the graph rooted at C. But when Extend is complete, only one of the two is desired to be mapped to C. The method must track which primary nodes have already been mapped, so as to avoid mapping multiple objects in the secondary onto the same object in the primary.

[0026] Similarly, once a node has been mapped from the secondary to the primary, the method should record all of the descendant mappings. Otherwise, when the method completes, the secondary graph's topology may be lost. For instance, suppose a has been mapped to A. The process of doing the comparison should record the mappings of the entire subgraph; otherwise, d could be mapped to E, which is wrong since the edge labels would no longer be consistent (a->d is 1, but A->E is 3). To avoid this situation, the method tracks which secondary nodes have already been mapped.

[0027] The above two points lead to the requirement for a bidirectional mapping, or unification. When two nodes are found to be compatible, they are bound together, and are said to be “unified” for the time required to complete the Minimal Extension method. This mapping takes place during the Unify method.

[0028] Complicating the whole procedure further is the fact that the edges between two nodes are one of two types, use or contain. A contain relationship means that if the node is copied, than the descendant tree must also be copied. A use relationship means that even if the node is copied, it may still be possible to share the descendants with the Extend method. For example, once b is determined not to fit into the primary, g and h will need to be copied (because they are contained), but k is still a candidate for unification (because it is used). If in fact a had already been mapped to A, then k will already be mapped to H, and therefore when b's subgraph is added, it will already have a constraint on it.

[0029] Another problem which exists is that the number of node comparisons in the method, as described above, represents the worst case. Consider, for instance, that Extend may recursively call itself for each descendant. For instance, to compare a with A, all six of a's descendants must be compared to those of A. Suppose that during the Compare, k is found to be compatible with H, but something else is incompatible. Therefore a's subgraph will be added to the primary with Add. However, since Add recursively calls Extend when descendants are used, k will again be compared with H, even though it had already been compared. Consider further that Minimal Extension calls Extend once for each node. Clearly, the approach should avoid re-comparing nodes. It is also important not to compare against the newly added nodes when comparing later nodes in the same graph. That is, if Extend copies g to the primary graph, C should not be compared with g's copy later on. Another consideration is that the order in which the nodes are traversed matters. If b is checked before a, then b could get mapped to C. Therefore, when a is checked against A, C will not be available, and so a will have to be added as a new subgraph. The resulting extension could be sub-optimal. The method can avoid this problem, however, by comparing the nodes in the correct order.

[0030] Finally, consider the following situation: b is being compared to C, and it has been determined that b is compatible with C, g is compatible with F, and k is compatible with H. Suppose that it is now desired to compare h to G. In such a case, the system needs to remember that k has been mapped to H, because that mapping affects the topology. That is not a problem if the mappings are recorded as they take place. Consider the case, however, when h turns out to be incompatible with G. Recall that the purpose of mappings that are recorded is track the unification of two subgraphs. Since this occurs within Compare, the system has determined that the subgraphs are incompatible, and does not want to do the unification at all. In such a case, the mapping from k to H is removed, since it was only conditional on b's being mapped to C. The method must, therefore, be able to record potential mappings, but must be able to back out of those mappings if Compare rejects the possible unification.

[0031] To address these issues, implementation of the method is complicated. Specifically, the following features are introduced.

[0032] (1) A bi-directional unification record is added between the nodes of the primary and secondary graphs. This record serves two purposes: it ensures that the topology is handled correctly, as mentioned in the points above; and it provides coloring for the nodes, reducing the algorithm to linear time

[0033] (2) A check is added in Add to determine whether an edge is used or contained, resulting in the appropriate subgraph being handled with either Extend or Add, respectively.

[0034] (3) A cache is kept of the results of node comparisons, preventing repeated comparisons of the same nodes.

[0035] (4) A predefined order is employed for comparing classes of nodes, improving the likelihood that the classes with more descendants will get mapped first.

[0036] (5) A set of virtual bindings is employed, which stores potential mappings during Compare. If the Compare is successful, the virtual bindings are converted into real bindings.

[0037] C. Method Steps for Implementing Resource Consolidation Methodology

[0038] The methodology may be implemented as outlined below. Each method (with its routine names presented in parentheses) is followed by exemplary method steps.

[0039] Resource Consolidation (consolidate):

[0040] For each resource set:

[0041] Invoke Minimal Extension on the set

[0042] Minimal Extension (extend):

[0043] Initialize the nodes in the resource set

[0044] For each resource in the set, iterating through in tcf_hierarchy order:

[0045] Invoke Extend on the resource

[0046] Clean up

[0047] Extend (extend resource)

[0048] Try to Unify the resource, record the result in mapped_res (i.e., mapped resource)

[0049] If Unify failed, copy the subgraph rooted at the resource with Add, saving the result in mapped_res

[0050] Return mapped_res

[0051] Unify (unify_resource)

[0052] If resource is already bound, return binding

[0053] For each primary resource in the same class as the secondary resource:

[0054] Remove all the virtual bindings (this_merge_list, reset_merge_list)

[0055] Call Compare to compare the primary and secondary resources

[0056] If they match, call Bind to bind the two resources together, and return the primary resource

[0057] If no primary resource matches, return a failure

[0058] Compare (compare)

[0059] If the primary resource is already bound:

[0060] Set map to the binding

[0061] If map equals the secondary resource, return success, since the two resources are already bound together

[0062] Otherwise, return failure, since the primary resource is bound to something else

[0063] If the primary resource is not yet, bound:

[0064] If the secondary resource is bound, then return failure, since it must be bound to something other than the primary resource

[0065] Repeat the above steps by checking for bindings on the virtual list

[0066] If neither the primary nor secondary resources are yet bound, in either the real or the virtual list, invoke Compare 1 to actually compare the two resources

[0067] Compare1(compare1)

[0068] If the comparison between the primary and secondary resources has already taken place, then get the result from the cache

[0069] Otherwise, do the node comparison, and store the result in the cache; the node comparison assumes that the two nodes being compared are in the same class

[0070] If the two nodes are not compatible, return failure

[0071] Otherwise, for each type of edge label descending from the primary node:

[0072] Invoke Compare on the children of the primary and secondary resource with the specified label

[0073] If the Compare fails, return failure

[0074] The primary resource and secondary resource are compatible, as are their descendants.

[0075] Create a virtual binding between the two resources.

[0076] Bind (do_merge)

[0077] For each binding in the virtual bindings list:

[0078] Do any resource-specific merging of the two resources

[0079] Call BindResource to bind the two resources to each other

[0080] Add (add_resource_tree)

[0081] Create a new node that is an exact copy of the node in the secondary graph

[0082] Create a real binding between the original, secondary resource and the new, primary resource

[0083] For each contained edge label of the original resource's class:

[0084] For each child connected to the original resource through the specified label:

[0085] Invoke Add to add the child, recording the name of the resulting copy

[0086] Change the links in the copy to point to the copies of the children

[0087] For each used edge label of the original resource's class:

[0088] For each child connected to the original resource through the specified label:

[0089] Invoke Extend to unify or add the child, recording the name of the resulting binding

[0090] Change the links in the copy to point to the bindings of the children

[0091] Return the name of the copy

[0092] BindResource (bind_resource)

[0093] Bind the first resource to the second resource

[0094] Bind the second resource to the first resource

[0095] D. Examples of Minimal Extension

[0096] As an example, consider the following scenario, which is illustrated in FIG. 3. As shown at 301, the primary set consists of two nodes, A and B. The secondary set consists of one node, a. The a node is compatible with B. As illustrated at 303, Minimal Extension calls Extend(a). Extend calls Unify(a). Unify clears any virtual bindings, then looks at B, which is the same class as a, and calls Compare(B, a). Compare calls Compare1(B, a). Compare1 invokes B's node comparison function, and determines a is compatible. It creates a virtual binding between B and a.

[0097] As illustrated at 305, Unify then calls Bind. Bind finds the virtual binding, invokes B's merge function to merge a, and calls BindResource(B, a). BindResource makes a real binding. Unify(a) returns B. Extend(a) returns B. Minimal Extension cleans up, and is finished. The result is that a has been bound to B.

[0098] FIG. 4 illustrates a more complicated example. Consider the same situation, as shown at 401, but a is not compatible with B. Minimal Extension calls Extend(a) Extend calls Unify(a). Unify clears any virtual bindings, then looks at B, which is the same class as a, and calls Compare(B, a). Compare calls Compare1(B, a). Compare1 invokes B's node comparison function, and determines a is incompatible. It returns failure. Unify then returns failure. Extend invokes Add(a). As shown at 403, Add creates C, and creates a real binding between a and C. There are no children, so it just returns C. Extend(a) returns C. Minimal Extension cleans up, and is finished. The result is that a has been bound to C.

[0099] FIGS. 5A-B illustrate a complex example involving children. Assume a, b, c, and d are compatible with A, B, C, and D, respectively. Minimal Extension calls Extend(a). Extend calls Unify(a). Unify clears any virtual bindings, then looks at A, which is the same class as a, and calls Compare(A, a). Compare calls Compare1(A, a), which invokes A's node comparison function, and determines a is compatible. It stores the result of the comparison in the cache. It then iterates through each edge type descending from A. First it calls Compare(B, b). Compare calls Compare1(B, b), which invokes B's node comparison function, and determines b is compatible. It stores the result of the comparison in the cache. It then iterates through each edge type descending from B. It calls Compare(D, d). Compare calls Compare1(D, d), which invokes D's node comparison function, and determines d is compatible. It stores the result of the comparison in the cache. It then creates a virtual binding between D and d.

[0100] Popping the stack, Compare1(B, b) determines that B and b are compatible, and creates another virtual binding. Popping the stack, Compare1(A, a) checks the second edge, calling Compare(C, c). Compare calls Compare1(C, c), which invokes C's node comparison function, and determines if C is compatible. It stores the result of the comparison in the cache. It then iterates through each edge type descending from C. First it calls Compare(D, d). Compare finds that D is already bound, and it is indeed bound to d, so it returns success.

[0101] As illustrated in FIG. 5B, popping the stack, Compare1(C, c) determines that C and c are compatible, and creates another virtual binding. Popping the stack, Compare1(A, a) determines that A and a are compatible, and creates another virtual binding. Unify returns a's new binding, A, then calls Bind. Bind iterates through the virtual bindings, calling BindResource. BindResource creates a real binding for each virtual binding. Unify then returns A. Extend returns A. Minimal Extension then calls Extend(b); Extend calls Unify(b). Unify finds that b is already bound to B, so returns B to Extend, which returns B to Minimal Extension. Minimal Extension proceeds similarly for C and d. The result is that all of the nodes in the secondary have been unified with the compatible nodes in the primary.

[0102] FIGS. 6A-B present the most complex example. Consider the same set-up as before, except that c is not compatible with C. The first few steps will proceed exactly as before, the difference coming when c is compared to C. Compare(C, c) calls Compare1(C, c), which invokes C's node comparison function, and determines C is incompatible. It stores the result of the comparison in the cache. It then returns failure. Compare(C, c) returns failure, causing Compare1(A, a) and Compare(A, a) to return failure. There are no more objects in the same class as a in primary, so Unify(a) returns failure.

[0103] Extend(a) invokes Add(a). Add creates a copy of a, called E, and creates a real binding between a and E. Add then iterates through each contained label of a, adding the children. It startes with Add(b). Add(b) creates a copy of b, called F, and creates a real binding between b and F. Add finds no contained children of b, so it extends primary with its used children, calling Extend(d) to add or unify the child. Extend calls Unify(d). Unify clears the virtual bindings, then finds that D is the same class as d, and calls Compare(D, d). Compare finds no real or virtual bindings, so calls Compare1(D, d). Compare1 finds a cached comparison showing that D is compatible with d. There are no children of D, so it creates a virtual binding between D and d, and returns success. Compare(D, d) returns success.

[0104] Unify(d) calls Bind to create a real binding from the virtual binding, then returns D. Extend(d) returns D to Add(b). Add(b) then creates a new link from F to D, then returns F to Add(a). Add(a) records the name of label 1's copy, F, then calls Add(c) to add the other contained child. Add(c) copies C to G, creates a real binding, finds no contained children, and calls Extend(d) to add or unify the child. Extend(d) calls Unify(d), which finds that d is already bound to D, so returns D to Extend(d), which returns D to Add(c). Add(c) then creates a new link from G to D, then returns G to Add(a). Add(a) records the name of label 2's copy, G, finds there are no normal descendants, and creates the links from E to F and G. Add(a) finds no more descendants, so returns E to Extend(a), which returns E to Minimal Extension. The rest of the steps are similar to those in the previous example. As each node is found to be previously bound, Unify succeeds immediately. The result is that a's subgraph was found to be incompatible, so a, b, and C were copied, but since d was used, it was unified with D.

[0105] E. Improvements

[0106] In the above method, a step in Compare1 assumes that there is only one child of each label. It is the following step:

[0107] Invoke Compare on the children of the primary and secondary resource with the specified label

[0108] In the case where there are multiple edges with the same label, this approach will not work. Also, during Compare1, the labels from the primary resource are looped through, not the secondary, this means that if the primary has more descendants of the appropriate type than the secondary, there will not be a match, which is not correct. The primary is allowed to have more than the secondary. Note that these are a result of the code mishandling multiple edges with the same label. The algorithm iterates over edge labels, not edges. Thus, since each edge label may correspond to multiple edges, an improved version would include another loop handling the resources with the same label.

[0109] In addition, if there are cycles in the graph, the method does not work, since it is is intended to work with acyclic graphs. But because of overloading of functionality with other parts of the resource code, resources which are not dependent from a consolidation point of view can appear in the list of dependent resources. For instance, a replication server may specify itself as its identifier or ID server.

[0110] Finally, the use of a single virtual bindings map may be suboptimal. Consider the situation in FIG. 7. Assume that the e is compatible with H, and the subgraph rooted at b is compatible with those mapped at both B and C, with the exception of E, which is incompatible with d. Then the method will proceed by testing a against A, e against H, and establish a virtual link between e and H. Continuing to compare a's children, it will compare b against B, and C against D, and will establish another virtual link between C and D. It will then test d against E, but will find them incompatible, so Compare will return failure for B. The situation now appears as shown in FIG. 8. In the above-described implementation, the comparison would then fail completely, because it does not properly handle iterating through multiple links with the same label (i.e., it will not try b against A's other child 2, C).

[0111] If the algorithm implemented multiple links correctly, it would then test b's sub-graph against that rooted at C. It would find b and C compatible, and would then check C against F, but C still has a virtual binding to D. So Compare would fail, and Extend would end up copying the entire graph. The obvious reason this fails is because the virtual bindings were not erased when B's subgraph was found to be incompatible (instead, they would be erased the next time Unify was called). Erasing them when Compare fails would also cause an error, because then it would remove the necessary virtual link between e and H. The solution is to properly handle the backtracking as different links are tried, and erase just those virtual bindings that were added during the current level of recursion. This requires a more sophisticated data structure than the simple list of bindings currently used; instead, there should probably be stack of bindings that is pushed when Compare is entered, and popped when it is exited. The error does not currently manifest itself because it only occurs in rather sophisticated graphs (probably limited to those with multiple links with the same label).

[0112] F. Efficiency

[0113] The algorithm may be optimal in the number of node comparisons that it does, but the overhead is probably substantial. The following changes may reduce the overhead. Minimal Extension should call Extend only on root nodes. Above, it calls Extend on all the nodes in the secondary graph. But when Extend processes a root node, all the other nodes in the subgraph also get bound. Thus, there is no need to call Extend on the subgraph elements again. Note that the first thing Unify does is check to see if there is already a binding, so it will come back immediately for subgraph nodes, but it might be better not to process them in the first place. On the other hand, it is possible that the cost of finding the root nodes would outweigh the benefits. Note that the check for an already-bound node would need to remain in place, since, for example, two root nodes might point at the same child node.

[0114] One of the points mentioned in the discussion of the subtleties of the method was the fact that newly-added nodes in primary should not be considered candidates when trying to Unify nodes from secondary. The implementation does not make this check. Because nodes are bound when they are added, they will never successfully compare, so the method will not handle this incorrectly, but it is an unclear artifact of the implementation, and a potential source of extra overhead.

[0115] G. Conceptual Problems

[0116] The method described above marks the edges as being used or contained. It would make more sense for nodes to be marked as used or contained Consider that it makes no sense for a node to be contained by some resources but used by others. Seen from this light, the semantics of contain vs use is simple: contained nodes can only have one parent, whereas used nodes can have multiple parents. It may simplify or clarify the algorithm to reflect this interpretation in the resources.

[0117] Another problem is that the method by itself does not completely guarantee the topological compatibility—one of the topological checks is implemented by the node comparisons. For instance, suppose that in FIG. 2, a and A were not compatible. Then when C is consolidated, E is still available, and C conceivably could be consolidated with E. Because E has a parent, but C is a root node, they should not be considered topologically compatible. This problem does not show up because in cases where this is possible, the nodes have something like a usage attribute that makes the nodes incompatible. Since Minimal Extension's job is to handle the topological comparison, it should handle this case, instead of relying on the node comparisons to handle it

[0118] H. Implementation Problems

[0119] The use of two lists to represent the real and virtual bindings is not optimal. Specifically, the duplicated code in Compare is suboptimal. One solution is to change the representation to a list of bindings, and another list that indicates whether each binding is real or virtual.

[0120] A related problem is that virtual bindings are cleared at the beginning of Unify, as mentioned above. Instead, they should be cleared when a real binding is established. This is a simpler change than actually fixing the bindings to track the level of backtracking. Ideally, Add would not bind resources together itself, rather than calling BindResource. Also, information from tcf_hierarchy should ideally be derived from information in the individual classes.

[0121] I. Better consolidation

[0122] The goal of Minimal Extension is to minimally consolidate the resources from secondary. A standard heuristic used to minimize resource usage is to consolidate larger resources before smaller resources. Minimal Extension uses tc_f_hierarchy to implement this heuristic, by specifying the class order in which to do the consolidation. The particular ordering comes from assuming that subgraphs with more nodes (e.g., SQL servers) should be consolidated before subgraphs with fewer nodes. There are two problems with using tcf_hierarchy: it does not handle multiple subgraphs of the same type, and the assumption is not always true. For the first case, consider a resource set with two SQL servers; one is normal, the other has an extra p device of size 100. Based on the above heuristic, the second server should be handled first. But since they are both SQL servers, they will not be distinguished by tc_f_hierarchy, and will be handled in an arbitrary order.

[0123] For the second case, consider that l devices are handled before p devices. This normally makes sense, since an l device requires a SQL server, and all that goes with it. But suppose there is a resource set in which a p device requests 500 megabytes. If the current minimal set already has such a device, it would be better for the consolidation to handle it first, but instead, the l device's p device will probably be consolidated. One possible solution to both of these problems is to provide a dynamic weighting scheme. Minima Extension could call a procedure which dynamically calculates the order in which the nodes should be handled. Ideally, it would provide only the root nodes. A simple scheme might base the weight on the number of nodes in the subgraph; this solution would handle the first case above, but not the second. A more powerful scheme could assign a weight to each type of resource; for instance, each 10 megs of p device might cost 1 point, each process might cost 10, each machine might cost 50. Such an approach would allocate 50 points to the above 500 meg p device, but only about 13 to the typical SQL server, so the p device would be allocated first.

[0124] Note that it is still possible for the approach to get into trouble; doing perfectly optimal resource consolidation in the general case is NP-complete, and all possibilities are not tried, in some cases problems will occur. By using an appropriate weighting algorithm, it should be possible to reduce the cost of some scenarios that now cause problems. Furthermore, by changing the weights, the method can be adjusted for different requirements (e.g., minimizing the amount of disk space, rather than the number of machines).

[0125] J. Other Notes

[0126] There are some aspects of the method that have not been explained, because they are related to the specific application of the graph algorithm to the resource tree. One point which benefits from further explanation is the following step in Bind.

[0127] Do any resource-specific merging of the two resources

[0128] “Merging” a node in the secondary graph into the primary graph means updating the primary resource so that it incorporates information from the second resource. This step is required because compatibility between two resources does not mean they are identical. For instance, two p devices may be otherwise identical, but have different sizes. Unless there is an attribute that specifically prevents them from being merged, they can be considered compatible (because whatever can be done with the smaller resource can also be done with the larger). But if the primary resource is the smaller, it must be increased in size so that it can contain the larger. This merging is accomplished through the merge method on the given resource. Note that when a node is copied through Add, as opposed to unified through Unify, it does not require a merge.

[0129] There have been references to “node comparisons”, meaning the node-specific mechanism that is used to determine if two nodes are directly compatible. The comparison is done in the resource-specific compare method (this method is distinct from a resource set's compare method, which implements the Compare routine described above). A resource class implements compare as a comparison between the attributes. In an earlier version of the Resource Consolidation method, each resource comparison included comparisons of its dependent resources; although this made the code simpler, it did not allow the possibility of Compare1 caching the results.

[0130] While the invention is described in some detail with specific reference to a single preferred embodiment and certain alternatives, there is no intent to limit the invention to that particular embodiment or those specific alternatives. Thus, the true scope of the present invention is not limited to any one of the foregoing exemplary embodiments but is instead defined by the appended claims.