Dynamic Dervice Groups (DDGs) in Server Automation are dynamically maintained lists of SAmanaged servers that grows and
contracts as servers are added and removed from theSA environment. They are very handy, but if used incorrectly DDGs can
have a negative effecton the performance of the SA database server as their memberships are recalculated hourly; if the rules
defining the DDGs are inefficient and/or there are a very large number of DDGs in the environment, their recalculations
can make the SA database very busy.
SA versions prior to SA 10.10 have a tool to assist with evaluating the performance of DDGsin the SA environment.
This tool is introduced via the SA Rollups (product patches that can be obtained from HP Support). The tool/script is
called dump_dyn_group_rules. If installed, the tool will be located in the directory /opt/opsware/support on slice servers
in the SA environment.
The script dump_dyn_group_rules can be simply run by the root user on a SA slice by issuing the command
/opt/opsware/support/dump_dyn_group_rules. Appending the option (-h) to theend of the command will print
out a short help text with options available for user with the command. The two main uses of the command are
to print out information about DDGs andto calculate their current membership and how long it takes to calculate that membership.
For example:To print out the information about a DDG with ID 12345 the command is simply
The output would look something like this..
role_class_full_name: Device Groups Public DDG_with_contains
modified_by: : chuck
modified_dt: : 20151216T20:29:35
rule: ((device_interface_ip EQUAL_TO '10.126.150.71'))
rule (raw):(eJyNk8tuwjAQRX+FnTcVsoGEtLuImooKEcqriwpZrmNaI9eOkoCKEP9eO4SQ8CrbuffOHD9mC5hWCylYKtQXeKrBhxoIRRJJuiGK/nBTGmjFTTXhkrNUx0SEpoiaLa8FIUR9I1l jElFm3eAZz3odTF5GwXRIxriPO5NgBIyLfQsZxlwZ0xYQ3/fxbxTzJBFava6UAdBW+theIFoedTAd9IKB7ceLODnoe7aG68GC7c6pc2OtqtdY9OeSMEmTxMKcRO6mKrnWVK44STdRdnvd2cWr6g ouw5l13o1Vihh5nWcBgnXUcOvIgfU2OgHecxqp4FzYJjliprqu1zyIZ4U0pnkThJy2i1rtTNnNd//N0RGPqflclhC/Tf0+mQQWziT0Kmac7EGyoOM5FYJKozMEr4Rw4+mKv1B0LT/XzYMVi5HvC 2hA59Hq4NLIce7OTqflcW+C4fjdH+ECoLJh1wD+ANk8Ihk=)
sql: SELECT DISTINCT dvc_id from (select /* ResourceTypeView.01 */ devices.* from truth.devices where devices.DVC_ID in (((((select /* RA.device_b ase_view */ distinct devices.dvc_id from (select /* RA.device_intf_comps */ devices.dvc_id as dvc_id, interfaces.ip_address as device_interface_i p, interfaces.hw_addr as device_interface_mac from truth.devices left join truth.interfaces on devices.dvc_id = interfaces.dvc_id) device_intf_comp s, truth.devices where devices.opsw_lifecycle != 'DELETED' and devices.dvc_id = device_intf_comps.dvc_id and upper(device_intf_comps.device_inter face_ip) = '10.126.150.71')))))) devices
Of note here is the creator of the DDG, when it was created, the rule(s) that define its membership, and the resulting SQL created
by SA and submitted to the Oracle DB when membership for the DDG is calculated. Running the command without the DDG's ID
(12345 in this case) would result in the rool reporting on ALL DDGs present in the SA environment.
The second use of the script is to have the tool also submit the SQL defining the DDG's membership to the SA Oracle database
and report back how long it takes for the SQL to execute, and the current membership of the DDG. This will give some idea of
the impact the DDG has on the database (the longer it takes, the more expensive it is for the database to calculate the membership).
Adding on the example above, to get the additional information, the syntax would be
/opt/opsware/support/dump_dyn_group_rules 12345 -t
The extra information will be present at the bottom of the output and take the form
time_to_execute: 1 devices in 0.089 seconds.
As before, running the command and NOT supplying a DDG ID will cause the tool to evaluate ALL DDGs present in
the SA environment AND execute the SQLs associated to each DDG's membership. Care should be taken in running
the command against all DDGs if its unknown how many DDGs there are or if there's any suspicion that their calculation
is already impacting the SA database, as recalculating all of these SQLs at once could negatively impact
the performance of the SA database. A safer first step would be to run the command without the -t option to find out
how many DDGs there are and then use the -t option with DDG IDs supplied to evaluate a particular DDG.
It is possible to run the -t option and not supply a DDG ID, but be aware that it could take the command some time
to complete depending on the number of DDGs and this should only be done when the SA environment is not
busy to avoid impacting any jobs being run by SA.