Knowledge Article

Best Practices for making changes to an active Manager run in BMC Performance Assurance for Servers
Back to Answers Printer Friendly Rate this Page

Knowledge Article ID: KA310873 Version: 1.0 Status: Published Published date: 01/20/2011

Problem
The goal of this document is to cover how to make changes to an active Manager run, which changes require a Manager run to be resubmitted, and when changes will be applied to an active Manager run.

NOTE: This document was originally published as Solution SLN000000168714.

BMC Performance Assurance for Servers 7.4.10, 7.4.00, 7.3.00, 7.2.00 Unix Solution Section I: Overview
There are 4 scripts executed by an active Manager run that collects, processes, and transfers data. These are:

The [date]-[date].Manager script (Jan-01-2004.00.00-Dec-31-2004.23.59.Manager)

o The .Manager script is created when a Manager run is submitted and the same script is used for the
entire duration of the Manager run

o The .Manager script is scheduled to run 'COLLECT_LEAD_TIME' minutes before the start of data
collection. By default the COLLECT_LEAD_TIME is 30 minutes and is configurable under Options -> Collect tab -> "Run script before collection time". In Perform version 7.1.20 and earlier the .Manager script was executed 15 minutes before data collection start time.

o The .Manager script creates and schedules all of the other scripts used for data collection, data transfer,
and data processing

o The .Manager script will remove itself from cron/pcron when the End Date of the Manager run has been
reached

o In Perform version 7.2.00 and later the *.Manager script executes the udrCollectMgr processes which
handle data collection and data transfer for the Manager run

The [date]-[date].Collect script (Jan-01-2004.00.00-Jan-01-2004.23.59.Collect)

o A new .Collect script is created each day by the .Manager script o In Perform version 7.2.00 and later, the *.Collect script's only purpose is to ensure that there is a
udrCollectMgr process running for the Manager run. It will run every 'Collector restart interval' minutes and

start a new udrCollectMgr process to take over data collection and data transfer for the run if one isn't already running.

o In Perform version 7.1.20 and earlier, the .Collect script is scheduled to run at the specified start time of
data collection. So, if data collection is scheduled to run from 00:00 to 23:59 the .Collect script will be scheduled to run each day at 00:00. The data collection start time is controlled by the Daily Begin field in Manager.

o In Perform version 7.1.20 and earlier, the .Collect script will remove itself from cron/pcron when it has
finished starting data collection

o In Perform version 7.1.20 and earlier, if Collector Restart is enabled in Manager, after the .Collect script
has started data collection it will reschedule itself as the '[date]-[date].Collect query' script. This script will run every 'Restart Interval' (by default 15 minutes) to query each remote node to ensure that data collection is running.

The [date]-[date].XferData script (Jan-01-2004.00.00-Jan-01-2004.23.59.XferData)

o A new .XferData script is created each day by the .Manager script o The .XferData script is scheduled by Manager to run Processing Delay minutes after data collection has
completed. So, if the Options => Advanced Features => Other => Processing Delay is set to 10 minutes (the default) and the Daily End is set to 23:59 then the .XferData script will be scheduled to run at 00:09 (10 minutes after data collection completes)

o The .XferData script will remove itself from cron/pcron when it has finished all data transfer attempts o The .XferData script executes the .ProcessDay script when all data transfer attempts have been
executed, or when all expected data is present on the managing node (whichever comes first)

o In Perform version 7.2.00 and later the purpose of the *.XferData script is to check if all data has been
transferred to the console by the udrCollectMgr process or if the Transfer Duration has elapsed. Once either of those two events has happened it will execute the *.ProcessDay script.

The [date]-[date].ProcessDay script ((Jan-01-2004.00.00-Jan-01-2004.23.59.ProcessDay)

o A new .ProcessDay script is created each day by the .Manager script o The .ProcessDay script is executed by the .XferData script after data transfer is complete (or time has
expired)

Section II: Making changes to a Manager run

The rule: You should only press the green activate button in the Manager GUI when scheduling a new Manager run. Do not press the activate button again after making modifications to an active Manager

Each night the .Manager script will read all of the files that define your Manager run. This includes:

Your .vcmds file The Workload definition file (.an file) specified for the run All the Domain files (.dmn files) specified for the run

What that means is that any changes made to the .vcmds, .an file, or .dmn file will propagate into the next execution of the Manager run without it being re-activated.

The changes will be propagated into the Manager run when the new scripts are created at night. But, keep in mind that all of the scripts for a day of data collection and data processing are created at the same time - 15 minutes before data collection begins. What that means is that changes to data collection will be seen starting with the data collection run on the night of your change, but changes to data processing will occur the next night. So, if a change is made to a Manager run that collects data from 00:00 to 23:59 and has a 31 minute processing delay:

Change made Seen for data collection Seen for data processing
Jan 1, 2004 @ 10:00 Jan 2, 2004 @ 00:00 Jan 3, 2004 @ 00:30

So, if on January 1st at 10:00 a new workload is added to the .an file for a Manager run, the new workload will not appear in Visualizer until January 3rd (it will be applied to the data collected on January 2nd). The reason is that the data processing scripts for the data collected on January 1st have already been created. So, even though the workload characterization has changed, the .ProcessDay script that is scheduled to run that night has already been created with the old workload characterization.

Changes to some Manager options require that the run be stopped and restarted
There are some fields in a Manager run that should not be modified until the old Manager run is stopped and restarted. These fields are:

The 'Output Files Directory' from the Main Manager GUI -> Data tab The 'Data Source' toggle from the Main Manager GUI -> Data tab The 'Start Date' from the Main Manager GUI -> Schedule tab The 'End Date' from the Main Manager GUI -> Schedule tab The 'Use time stamp for output directory' button from the Options -> Advanced Features -> Other tab

All other fields within the .vcmds file can be modified without stopping and restarting the Manager run. All fields in the .an file and .dmn files can be modified without stopping and restarting the Manager run.

Section III: Frequently Asked Questions

Question 1
Is there an easy way to make changes to a Manager run and have them applied to the run immediately. For example add a node for data collection at 10:00 and have it start collecting data immediately and process that data that night? What about add a workload to the .an file and have it process today's workload with that new workload characterization? Unfortunately there is no easy way to get a change applied to a Manager run immediately. The files that define the base Manager run (.vcmds file, .an file, .dmn files) are only referenced when the scripts are created at night. From that point forward the run is controlled by files in the Manager output directory such as the [date]-[date].Variables file, the [date][date].NItable file, and the scripts themselves. For that reason adding a node to the domain (.dmn) file won't have any effect on the active Manager run because the active node list is stored in the [date]-[date].NItable file. Likewise, adding a workload to the Workload definition (.an) file won't have any effect on the active Manager run because the workload definition that will

be used is store within the .ProcessDay script itself.

Question 2
Is there any way to stop and restart a Manager run in such a way that all collected data (the data from the beginning of the day collected by the old Manger run, and the data collected after the Manager run has been restarted) will be processed by the new Manager run which includes my desired change? There is no seamless way to do this. In Perform version 7.2.00 and later it is possible but it isn't simple. Once you've made you change to the Manager vcmds file, Domain (dmn) file, or Analyze Commands (.an) File you would need to do the following: 1. 2. 3. 4. Put a run.quit file into the existing Manager Output Directory for the run. Find the running udrCollectMgr process from the Manager run you just stopped and kill it. Rename the *.vcmds file to a new name. Submit the Manager run under the new vcmds file name with a start date of today's date without

changing the start time of data collection (so if it was 00:00 leave it at that).

In general changes to your Manager run are best handled when you can wait a 24-hour period for the change to take effect. In Perform version 7.1.20 and earlier there is no easy way to do that. Stopping the original Manager run will cause the data collected by that Manager run to be left on the remote node (as the new Manager run will not know the data exists and will thus not transfer it). Hence, the only data that will be processed and available in Visualizer will be the data collected from the time that the new Manager run was activated.

Question 3
What happens if I don't deactive my existing Manager run but do press the green active button after making changes to its .vcmds file? In Perform version 7.2.00 and later the Manager GUI should reject your attempt to reactive the already active Manager run. In Perform version 7.1.20 and earlier there will be two Manager runs using the same .vcmds file active. That means that each Manager run will attempt to issue data collection requests for the same set of nodes, process the data from the same set of nodes, and create Visualizer files for the same set of nodes. This will certainly result in wasted processing time, but can result in other problems as well. It is best to ensure that only one Manager run is active for any .vcmds file. Until one of the Manager runs is stopped there will be two Visualizer files created having the same name and containing the same data but in different Manager output directories.

Question 4

If I absolutely need a change to occur in my Manager run immediately, what can I do? First, ask yourself, "Why do I need this change to happen immediately? Why can't I wait 24 hours for this to happen?" Trying to make a change that happens immediately will introduce a great deal of unnecessary risk into your environment since it isn't well support and could mean the entire Manager run will fail. There are two basic options at this point: A. If you are willing to lose data from the current day for the period before the change was made, stop and restart your Manager run. Data collection will start on the next whole hour and whatever change was made will be part of this new Manager run. The data collected from before the change will never be transferred to the managing node and it won't be processed by the re-activated Manager run. You must stop the previously activated Manager run or data will be double processed - the whole day by the original Manager run and the part of the data including your change by the new Manager run. That means that the data from whichever run finishes last will end up being populated into Visualizer (which will typically be the original run - not what you want). B. If you cannot lose any data you should contact Technical Support for suggestions. Technical Support may be able to suggest the necessary modifications to the existing configuration files in the Manager Output Directory to apply the change you want to make to the existing Manager run. This is somewhat risky as incorrectly applied changed could cause data processing to fail. For Perform version 7.2.00 and later, see the answer to 'Question 2' for an overview of what you need to do.

Knowledge Article
How can I change nodes with missing metric groups from Warnings to OK state in UDR Collection Manager (UCM) status reports?
Back to Answers Printer Friendly Rate this Page

Knowledge Article ID: KA295604 Version: 1.0 Status: Published Published date: 01/20/2011

Problem
How can I change nodes with missing metric groups from Warnings to OK state in UDR Collection Manager (UCM) status reports?

This document was originally published as Solution SLN000000203444.

BMC Performance Assurance for Virtual Servers 7.5.00, 7.4.10, 7.4.00, 7.3.00, 7.2.00 BMC Performance Assurance for Servers 7.5.00, 7.4.10, 7.4.00, 7.3.00, 7.2.00

 Unix console Windows console Solution Section I: Introduction

In the Collector Status Reporting (CSR) reports nodes and domains can be in one of three different states: OK, Warning, or Failed. A node will be assigned an 'OK' state for data collection if data collection has been successfully started on the remote node and data is being collected for all configured metric groups. A node will be assigned a 'Warning' state for data collection if data collection has failed to start on the remote node, or if data collection has failed for one or more configured metric groups on the remote node. A node will be assigned a 'Failed' state for data collection after data collection has failed and the time for all configured retries have passed. By default, it is quite likely that some configured metric groups will not be collected on almost every node. For example, the Solaris collector will attempt to gather the 'SRM Statistics' group which will only be enabled on machines using the Solaris Resource Manager. Each operating system has at least one group that is unlikely to be collected on the majority of the machines in an environment. This means that almost all nodes will be assigned a 'Warning' status for data collection. Even nodes where data collection has been requested but the Perform product isn't even installed will be assigned a 'Warning' status for most of the day because by default UDR Collection Manager (UCM) will continue to issue a start collection request (if previous ones have failed) over the first 90% of the collection interval (just under 22 hours). This means that in order to make the collection status useful a mechanism is needed to filter the groups that are known to be uncollectible on a machine. This will allow nodes with successful collection (collecting the configured groups we believe they should collect) to appear in 'OK' state and those with collection problems will appear in 'Warning' state. This is where the udrCollectFilter command comes in.

Section II: Running udrCollectFilter for a specific node against a specific collection interval
During normal data collection when the remote node is able to communicate back to the console on port 6768 the remote node will send status messages to the console indicating data collection problem. The messages are reported in the Collection Status Reporting (CSR) reports under the 'Messages' section of each nodes status page. For example, here are some messages for a node called 'topgun':

Thu May 19 23:30:06 2005 [UCM-Information] Collect request sent from console and received by the agent Thu May 19 23:30:06 2005 [Agent-Information] Collect Request - Data Collection pending Fri May 20 00:00:00 2005 [Agent-Information] Collect Request - Data Collection active Fri May 20 00:00:15 2005 [Agent-Information] Collect Request - Agent repository write active Fri May 20 00:00:25 2005 [Agent-Warning] Metric group not supported SRM Statistics
These messages indicate that topgun received and accepted a data collection request from the console at 11:30 PM, started collecting the data at midnight, and notified the console that data for the 'SRM Statistics' group was requested, but is not being collected on the machine. This missing group causes the node to appear in 'Warning' state in the CSR reports. The udrCollectFilter command can be used to tell the CSR reports that the missing 'SRM Statistics' group is acceptable for this node. The command to run is:

> $BEST1_HOME/bgs/bin/udrCollectFilter -d Mar-16-2006 -n topgun

This will create a file called 'topgun.flt' in the /usr/adm/best1_default/local/manager/filter directory on the console using the groups that were not collected on March 16th 2006. The '-d MM-DD-YYYY' flag is optional. If the -d date flag is not specified then all groups that have failed to collect at any point will be included in the nodes filter file. The contents of the topgun.flt file created by the udrCollectFilter command is in this case just a single line:

"SRM Statistics"
This indicates that if the agent on node 'topgun' reports that the 'SRM Statistics' metric group isn't being collected that is OK, and the node can be reported in 'OK' state rather than 'Warning' state. If some time in the future another group were to stop being collected node 'topgun' would be reported in 'Warning' state again. Using udrCollectFilter enables specific groups to be filtered while maintaining the alerting feature if another group unexpectedly stops being collected.

NOTE: You should only run udrCollectFilter against a data collection request that has completed to get a complete list of groups to be filtered. Group that haven't been terminated by the collector but contain no data will not show as unavailable until data collection has completed.

NOTE: By default udrCollectFilter will not overwrite an existing filter file for the node. You must specify the '-r' flag to force an existing filter file to be overwritten.

Section III: Running udrCollectFilter against all nodes

The udrCollectFilter command can also be run to create filter files for all nodes that have sent messages to the console. The command to run udrCollectFilter against all nodes is simply: $BEST1_HOME/bgs/bin/udrCollectFilter If there is already an existing [hostname].flt file for a node the udrCollectMgr process will not overwrite it. Instead it will only create new [hostname].flt files. If you wanted to overwrite existing [hostname].flt files it would be necessary to specify the '-r' flag.

Section IV: Inadvertently masking real problems with udrCollectFilter

The udrCollectFilter command will create filter entries for any metric groups which currently aren't being collected on a machine. That means that if udrCollectFilter is run against a machine that is having collection problems critical groups may be added to the filter list for that machine. For example, here are messages for node 'topcat':

Wed May 18 23:30:04 2005 [UCM-Information] Collect request sent from console and received by the agent Thu May 19 00:24:42 2005 [Agent-Information] Collect Request - Data Collection active Thu May 19 00:24:57 2005 [Agent-Warning] Metric group currently has no data available for collection Cpu Statistics Thu May 19 00:24:58 2005 [Agent-Warning] Metric group not available PRM

Configuration Thu May 19 00:24:58 2005 repository write active Thu May 19 23:59:19 2005 Collection Complete Thu May 19 23:59:19 2005 collected for metric group Thu May 19 23:59:19 2005 collected for metric group Thu May 19 23:59:19 2005 collected for metric group Thu May 19 23:59:19 2005 collected for metric group Thu May 19 23:59:19 2005 complete Fri May 20 00:04:02 2005 configured metric groups Fri May 20 00:04:08 2005 transfer successful Fri May 20 00:04:08 2005 in Agent repository

[Agent-Information] Collect Request - Agent [Agent-Information] Collect Request - Data [Agent-Warning] Collect Request - Data not Cpu Statistics [Agent-Warning] Collect Request - Data not Raid Configuration [Agent-Warning] Collect Request - Data not Raid Statistics [Agent-Warning] Collect Request - Data not User Id Statistics [Agent-Information] Collect Request - Processing [UCM-Warning] No data collected for some of the [UCM-Information] Collect Request - Agent data [UCM-Information] Collect Request - Data deleted

Running udrCollectFilter will create a topcat.flt file that looks like this:

"PRM Configuration" "Cpu Statistics" "Raid Configuration" "Raid Statistics" "User Id Statistics"
Note that the 'Cpu Statistics' group is included in that list. That could be the sign of a data collection problem on the machine which should be investigated. If it were determined that 'Cpu Statistics' shouldn't be filtered then the /usr/adm/best1_default/local/manager/filter/topcat.flt file could be edited and the 'Cpu Statistics' line could be deleted. This would cause the node to report in Warning state for the 'Cpu Statistics' group until the problem was resolved.

By default udrCollectFilter will not overwrite an existing filter file for the node. You must specify the '-r' flag to force an existing filter file to be overwritten.

Section V: Development documentation

Here is some documentation created by Development during the design of udrCollectFilter which describes some of the command line options available. Creating baseline filters (command format: udrCollectFilter [n "computer_name"] [d "date"] ] [ -b "best1_home"] [ -r] ) From the udrCollectFilter command line an option can be set to cause creation of filter files. A filter file will be created in the filters directory for each

unique node in the event log directory. Each event log file (and any backups) will be read and we will add one line per unique group in the file. Use of the n option will allow creation/update of a single computer. Use the d option to specify a date restraint - to use only results for a specific date. Use of the r option will cause overwrite of any existing filters found. Default behavior is to create only those filters that arent already present. Example:

Mdow1.flt "NT Internet Info Services Statistics" "NT NetBEUI Statistics" "NT NetBEUI Resource Statistics"
3.1.4 Filtering With the existing collection status report we have had many requests to avoid displaying the status of computers with certain missing groups as warnings. This should be done on the console side by allowing a user to specify what groups they wish to ignore. It would also be beneficial to allow a user to create a baseline filter from existing results. A filter file per node (for 7.1.01 computers and later) will be added to the new BEST1_HOME/local/manager/filters directory. The name of the computer will be used for the filename. Each file will contain a list of groups that will be ignored - one group per line. It will also be possible to specify a "global" filter per platform. This will allow a user to specify one set of groups that will be used whenever a computer with missing groups is examined and no filter file for that computer is found. There will be one UNIX file bmc-UNIX.flt and one Windows file bmc-Windows.flt. These files will only be used when a computer level filter file is not found. The UDR collection manager component will utilize this information and when missing groups are encountered, it will compare them against the filtered groups. If all groups are accounted for, then no warning status will be reported. The status report will display the OK health in the "Collect" column. The number of groups filtered will be shown on the status page in the request details section.

Legacy ID
15063344 SLN15063344 SLN000015063344 20000760

Knowledge Article
How can Perform UDR capacity planning data be manually transferred from the remote agent node to the Perform console server?
Back to Answers Printer Friendly Rate this Page

Knowledge Article ID: KA340164 Version: 1.0 Status: Published Published date: 01/20/2011

Problem
Processes available for manually transferring the Perform capacity planning data from the Perform remote agent server to the Perform console server when manager run does not successfully transfer the data.

NOTE: This Knowledge Article was originally published as Resolution 210290.

BMC Performance Assurance for Microsoft Windows Servers 7.5.00, 7.4.00, 7.3.00, 7.2.00 BMC Performance Assurance for Unix 7.5.00, 7.4.00, 7.3.00, 7.2.00 Manager Solution Section I: UNIX Perform Console Options
There are three options available to recover from a failed data transfer for all supported releases of Perform and one additional option for Perform version 7.4.10 and later: A. For Perform version 7.4.00 and later only: Re-run the [date]-[date].XferData script with the '-r' flag. B. Use the UDR Collection Manager (UCM) command line utility to recover the Manager run that failed to transfer the data. C. Transfer the data using the best1collect run command from the command line D. Manually transfer the data using an external tool such as ftp or scp

For Perform version 7.4.00 and later Option A: For Perform version 7.4.00 and later: Re-run the [date]-[date].XferData script
The [date]-[date].XferData script supports a new '-r' recovery option to allow it to automatically recover failed data transfer and initiate data processing. If the *.XferData script is being kept in the Manager Output Directory (not automatically deleted) after the Manager run completes it can be re-run to re-transfer and then execute re-processing for the Manager run. For example, to re-try data transfer for the Manager run in the '/bmc/perform/manager/run1/Mar-16-2008.15.16' Manager Output Directory for the April 24th 00:00 - 23:59 Manager run:

/bmc/perform/manager/run1/Mar-16-2008.15.16/Apr-23-2008.00.00-Apr-232008.23.59.XferData -r & INFO: Thu Apr 24 13:06:13 CDT 2008 XferData Starting UDRCollectManager in recovery mode. udrCollectMgr: manager run was initiated INFO: Thu Apr 24 13:06:13 CDT 2008 XferData Recovery RC=0, Run is initiated.. INFO:Thu Apr 24 13:06:14 CDT 2008 XferData recovery started. udrCollectMgr: time is expired for manager run udrCollectMgr: manager run is registered and complete for date specified
The [date]-[date].XferData script will initiate udrCollectMgr processes to handle the data transfer and then once the transfer phase is complete it will initiate the [date]-[date].ProcessDay script to re-process the data.

For all supported releases of Perform (including 7.4.00 and later) Option B: Use the UCM Command Line Utility
To recover failed data transfer using the UCM command line executable:

$BEST1_HOME/bgs/bin/udrCollectMgr -b /usr/adm/best1_default -d MM-DD-YYYY -v /path/name.vcmds -r

For example:

$BEST1_HOME/bgs/bin/udrCollectMgr -b /usr/adm/best1_default -d 04-23-2005 -v /home2/best1data/files/topgun_daily.vcmds -r

The -r parameter restarts Manager runs that have been aborted, or runs that are already complete. Specify this option along with the required run date and the script file name (VCMDS), which identifies the run. When run after the run has finished (so in transfer recovery mode) the command will only attempt to re-transfer data from the nodes defined as part of the specified Manager run that failed to transfer data previously. It will not attempt to re-transfer data from nodes that already successfully sent their data to the console.

Option C: Transfer the data using the best1collect

Transfer the data using the best1collect command from the command line. However, this method requires that you know a good deal about exactly where the data resides on the remote computer. The following is an example of the command:

$BEST1_HOME/bgs/scripts/best1collect -n [NODENAME] -B [BEST1_COLLECT_HOME] -d [REMOTE_DATA_REPO] -D [MANAGING_NODE_DATA_REPO] -b [DATE_TIME_STAMP_DIR] -p PUSH

$BEST1_HOME; Generally specified as /usr/adm/BEST1_nn, where nn is the product version number -n NODENAME; The hostname of the agent node -B BEST1_COLLECT_HOME; Generally specified as /usr/adm/BEST1_nn. -D MANAGING_NODE_DATA_REPO; The data repository on the managing node (where you want the data to end up) -b DATE_TIME_STAMP_DIR; The date/time stamp directory where the data resides on the agent node. This is in the format Mmm-dd-yyyy.hh.mm - for Manager run started data collection, hh.mm will typically be '00.00' (midnight). -p PUSH|PULL; The type of data transfer to use. A PUSH type transfer will delete the data from the agent node after the transfer is complete. A PULL type transfer will not delete the data from the agent node. Use PUSH unless a firewall prevents the PUSH type transfer from working properly. More information regarding data transfer in Perform can be find in Resolution

140635.) The following is an example of the command that would transfer the data from a UNIX agent computer that would transfer data from the /usr/adm/BEST1_nn/collect directory (where nn is the product version number) on the agent computer topgun to the /BEST1data directory on the managing node:

> $BEST1_HOME/bgs/scripts/best1collect -n topgun -B /usr/adm/best1_7.2.00 -d /usr/adm/best1_default/collect -D /best1data -b Sep-23-2004.00.00 -p PUSH

For a Windows agent computer, use the same parameters but specify Windows paths instead, as shown in the following example:

> $BEST1_HOME/bgs/scripts/best1collect -n winmachine -B "C:\\Program Files\\BMC Software\\PATROL3\\BEST1\\7.2.00" -d "C:\\Program Files\\BMC Software\\PATROL3\\BEST1\\7.2.00\\History" -D /best1data -b Sep-23-2004.00.00 -p PUSH
For Windows, make sure that if there are spaces in the paths that the command line parameter is enclosed in double-quotes (as in the example above). Also ensure that the directory separators are specified as two backslashes, not a single backslash. The following is an example of the messages you might receive for a successful transfer request:

best1collect on [managing node]: requesting a push of collected data via the Service Daemon... Node : [remote node]. Start from: Mon Mar 18 00:00:00 2002. Sun Dec 8 15:12:19 2002 *Node: [agnent node] has acknowledged Push request successfully.

Option D: Manually transfer the data

Transfer the UDR data using an external transfer tool if necessary.

Section II: Windows Perform Console

The PATROL Perform Manager on the Windows managing console assumes that the data is already present on the managing node when executing a Manager run that uses the Use existing data option. Therefore, you need to use another method to get the data to the managing node before running Manager again to reprocess the data.

Option A: For Perform version 7.4.00 and later: Use the 'Recover' option in the GUI
In Perform version 7.4.00 and later there is a new 'Recover' option in the Perform console Manager 'Schedule' GUI to recover data transfer and data processing.

Step 1
Open the Perform console and select the Manager -> Schedule object in the left-pane. That will bring up the Manager Schedule list.

Step 2
Select the target Manager run for transfer recover. Right-click and select 'Recover' from the menu. That will pop-up a message box that says the following:

Executing : "%BEST1_HOME%\bgs\bin\best1man.exe" "%BEST1_HOME\local\manager\B1_Mmm-dd-yyyy.hh.mm.ss_[run_name]_###\ [run_name].msf" -id #### -s MM-DD-YYYY -r Step 3

Click OK in that Information dialog. That will start a Manager run to re-transfer and re-process the data once the transfer is complete. Note that the 'Scheduler' will continue to list the job as 'FINISHED' but it will really be reprocessing.

Option B: Using the UCM Command Line Utility

To recover failed data transfer using the UCM command line executable:

%BEST1_HOME%\bgs\bin\udrCollectMgr -b %BEST1_HOME% -d MM-DD-YYYY -v X:\path\name.msf -r

The -r parameter restarts Manager runs that have been aborted, or runs that are already complete. Specify this option along with the required run date and the script file name (VCMDS), which identifies the run. When run after the run has finished (so in transfer recovery mode) the command will only attempt to re-transfer data from the nodes defined as part of the specified Manager run that failed to transfer data previously. It will not attempt to re-transfer data from nodes that already successfully sent their data to the console.

Option C: Using the Collect Data Wizard

The Collect Data Wizard includes functionality to transfer this type of data in this type of situation.

Step 1
Start the Collect Data Wizard by choosing Start => Programs => BMC PATROL => Perform => Collect Data.

Step 2
The Collect Data Wizard window is displayed. Click the Start a collect process on a Console or Agent computer option (the icon shows a green traffic light).

Step 3
Click Next on the Welcome to the Collect Wizard window.

Step 4
The Select the Collection Mode window is displayed. Click Standard Mode, and then click Next.

Step 5
The Select Computers window is displayed. On this window there are two options. a. Select the Agent computer or network address radio button, and in the edit box, type in the list of computers from which to transfer data, separated by commas. b. Alternately, if the list of computers is long, create a text file (using a text editor such as Notepad) that contains a list of all the computers from which you want to transfer data. This text file should contain a list of computers, with one computer name on each line in the text file. Once the text file is created, Choose the Select a file that contains the computers to collect radio button and then either type the full path to the file into its edit box, or click the Browse button to browse to the file.

NOTE: The agent nodes must have the same remote data repository path for the text file method to work.

Step 7
In the Repositories and Actions window, fill in the following three edit boxes: a. Top box: The directory on the managing computer where the data should be transferred. b. Middle box: Where does the data reside on the agent computer (it needs to be the same for all computers). c. Bottom box, choose the data transfer type. The options are Pull data or Push data.

Step 8
Click the Next button.

Step 9
The Data Collection Frequency window is displayed. Enter how frequently you want the data collected, summarized, and saved. Click Next.

Step 10
The Collection Schedule window is displayed. In the Begin and End by Date and Time section, enter the date and time that corresponds to the date/time stamp directory of the data on the remote computer. Manager passes this directory from the managing computer so it will be the same on all remote computers (if Manager initially collected the data).

Step 11
Click the Next button.

Step 12
The Completing the Collect wizard window is displayed. This lists the command that is going to be run. Click Finish here to get back to the main collect data window.

Step 13
The messages generated by the transfer will appear in the messages window. Check each computer and make sure that the message Request was completed successfully on node: [nodename] was generated. For each computer that failed to transfer the data, it may be necessary to try a different transfer type (such as PULL instead of PUSH) or to manually transfer the data.

Legacy ID
1012242 KM-1012242 KM-000001012242 KM-000001012242

Knowledge Article
What are the format flags available for the udrCollectStat command?
Back to Answers Printer Friendly Rate this Page Knowledge Article ID: KA307660 Version: 1.0 Status: Published Published date: 01/20/2011

Problem BMC Performance Assurance for Microsoft Windows Servers 7.4.10, 7.4.00, 7.3.00, 7.2.00 BMC Performance Assurance for Unix 7.4.10, 7.4.00, 7.3.00, 7.2.00 Perform Unix and Windows console Solution
The udrCollectStat command is a command line interface to the data available in the UDR Collection Manager (UCM) Status Report HTML pages. This command can be used to get basic status information that could then be used as input to another script or to create a daily e-mail report. All of the information available from udrCollectStat is also available from the Collector Status Reporting HTML pages. Information regarding the udrCollectStat command is also documented in the online help. Select the Help button on the Collect Status report, then select the "Generating Status Information from the Command Line" link.

NOTE: This document was originally published as Solution SLN000000228509.

Within the udrCollectStat command line utility options can be specified to control both the format and what information is presented when the command is run. When run from UNIX, the b option must specify a valid BEST1_HOME. An optional f option is available to allow a greater level of flexibility in choosing the output format. When specified, the -f flag supports a list of option that contains specifiers to be replaced by the actual information they represent. This allows a user to specify which fields, in which order, and how to separate the fields. If the -f format flag is not specified any important fields for debugging will be reported. Using the e 'errors only' option causes udrCollectStat to output only those items (runs or computers) that contain errors (in either health of collection or transfer). Using the w 'warnings only' option causes udrCollectStat to output only those items that contain warnings (in either health of collection or transfer) Using the o option causes udrCollectStat to output only those items that contain no errors or warnings. A combination of these options may be specified or none in which case the default will be to output all items. Four different major output options are available:

'-O' flag: Run Overview

-O flag: Output overview of a run or all runs that fall in a given date. The r option can be used to specify a specific run to limit output details to just that run. The d option can be used to specify a date to show data for all runs that started on that date. Or neither flag can be specified to output a list of all runs.

udrCollectStat O [ -b best1_home] format] [ e ] [ w ] [ -o ]

Available '-f' format specifiers:

[ -r run_name or d date]

[ -f

%v = manager script %r = name of manager run %d = date of manager run %ct = start time of collection %s = state of run %ch = health of collection [Error, Warning, OK] %th = health of transfer [Error, Warning, OK, NA] %e = total number of errors %w = total number of warnings %o = total number of oks %V = version \' = single quote \" double quote \n = new line \r = carriage return

 \t = tab %% = percent
For example:

"%r, %d, %s, %ch, %th"

will output:

[run name], [run_date], [state], [collect_health], [transfer_health] > $BEST1_HOME/bgs/bin/udrCollectStat -O -f operations_daily, 10-10-2006, COMPLETE, 2, topgun_daily, 10-10-2006, COMPLETE, 2, 1 operations_daily, 10-11-2006, COMPLETE, 2, topgun_daily, 10-11-2006, COMPLETE, 2, 1 topgun_daily, 10-12-2006, COMPLETE, 2, 1 operations_daily, 10-12-2006, COMPLETE, 2, "%r, %d, %s, %ch, %th" 1 1

'-D' flag: Run Detail

-D flag: Output details for a specific run. To view output for a specific run use the s option to specify a script and the d option to specify the run date. The r option may be used in place of the s option, but the user should be aware that there may be duplicate manager run names for the same date. (the script and date are the unique identifiers) If the d option is used without either a s or r option, detailed information for every registered run on that date will be output. If neither d, s or r are specified, information for every registered run across every date will be output.

udrCollectStat D [-s (-v) manager script] [r run_name] [d date] [ -b best1_home] [ -f format] [ e ] [ w ] [ -o ]

Available '-f' format specifiers:

%v = manager script %r = name of manager run %d = date of manager run %n = name of computer (node) %na = name of agent computer (proxy host or same as name of computer) %no = computer OS %V = computer version %a = application type %i = instance name %R = console data repository %Ra = agent data repository %s = state of computer collection/transfer %ch = health of collection [Error, Warning, OK] %ce = last collect error id %ces = last collect error string %cel = last collect error level [Error, Warning, Information]

 %th = health of transfer [Error, Warning, OK, NA] %te = last transfer error %tes = last transfer error string %tel = last transfer error level [Error, Warning, Information] %ta = transfer attempts %tg = number of groups transferred %tb = number of bytes transferred %tt = total transfer time (in seconds) %xe = last data deletion error %xes = last data deletion error string %xel = last data deletion error level [Error, Warning, Information] %xa = delete attempts %gc = groups configured %gad = groups active with data %gan = groups active with no data %gtd = groups terminated with data %gtn = groups terminated with no data %gtf = groups terminated and filtered \' = single quote \" double quote \n = new line \r = carriage return \t = tab %% = percent
For example:

-f "%n: %s, %ch, %ce, %th, %te [%xe]"

will output:

[computer name]: [state], [collect_health], [last_collect_error], [transfer_health], [last_transfer_error] [[last_delete_error]] > $BEST1_HOME/bgs/bin/udrCollectStat -D -f "%d %n: %s, %ch, %ce, %th, %te [%xe]" 10-17-2006 topgun: COLLECT_RUNNING, WARNING, 98, N/A, 0 [0] 10-17-2006 operations: COLLECT_RUNNING, WARNING, 98, N/A, 0 [0] 10-16-2006 operations: COMPLETE, WARNING, 98, OK, 54 [57] 10-16-2006 topgun: ABORTED, WARNING, 98, ERROR, 107 [107]

'-G' flag: Generate status report

-G: Generate status reports. This will update the .xml pages in the status directory for the web-based status report. Use the s option to specify a script and the d option to specify the run date.

'-E' flag: Comma separated list of errors codes and definitions

-E: Output a comma separated list of all error ids, levels and strings (no options) For example:

> $BEST1_HOME/bgs/bin/udrCollectStat -E ID, Severity, Description 0, Information, Normal Operation 1, Error, No conditions in alert 2, Information, Drill down request received 3, Information, Drill down request cleared 4, Error, Bad selector received in message 5, Error, Invalid metric request received 6, Error, Policy file does not exist 7, Warning, Cannot reach agent for alert <-- cut --> Legacy ID
15105952 SLN15105952 SLN000015105952 20014487

Knowledge Article
What is the best way to identify UDR data that has been left on remote nodes and transfer that data to the console or delete it?
Back to Answers Printer Friendly Rate this Page

Knowledge Article ID: KA342394 Version: 2.0 Status: Published Published date: 12/12/2011 Updated: 12/12/2011

Problem
Over time I have agent data 'stranded' on my clients. This results from the push processes not completing as expected. I need a way to occasionally cleanup this data on the clients to assure I don't fill up the filesystems. If there is a way to list the collect data on ALL my clients that would be fine. Then I could somehow follow up with a push or delete for the data as needed. Ideally, if there ways a way to push ALL data from ALL clients as a global 'clean up', that would be great.

BMC Performance Assurance for Virtual Servers 7.5.10, 7.5.00, 7.4.10, 7.4.00, 7.3.00, 7.2.00

 BMC Performance Assurance for Servers 7.5.10, 7.5.00,7.4.10, 7.4.00, 7.3.00, 7.2.00 Perform console Solution
This question is answered in four part:

How can I prevent data from being stranded on remote nodes forever? How can I list the data is stranded in the data repository on my remote nodes? How can I transfer the data in the data repository on my remote nodes to the console? How can I delete the data in the data repository on the remote nodes from the console? Is there any automatic way to report and recover failed transfers?

Section I: How can I prevent data from being stranded on remote nodes forever?
When the data collection request is issued from Manager, an option can be specified to instruct the Perform Agent on the remote node to automatically delete the data from the remote node if it has never been deleted (generally because it has never been successfully transferred to the console). That option can be specified in Unix Manager under Options -> Advanced Features -> Other -> 'Delete collected data on agent computer if transfer fails' (Days/Hours). That option can be specified in Windows Manager under Properties -> Collect tab -> 'Automatic data deletion an agent computer' 'Delete collect data if transfer fails' (Days/Hours). Make sure you specify a time period less than 27 days if you have unpatched Perform version 7.2.00 remote node because a value of 27 days or more caused Perform Agent problems.

Section II: How can I list the data is stranded in the data repository on my remote nodes?
Perform version 7.2.00 and later remote nodes support a 'best1collect' flag that allows you to get a list of Mmm-ddyyyy.hh.mm directories are still on the remote node. The command to run is: Unix:

$BEST1_HOME/bgs/scripts/best1collect -n [remote hostname] -p LIST

Windows:

%BEST1_COLLECT_HOME%\bgs\bin\best1collect.exe -n [remote hostname] -p LIST

Here is some sample output:

$BEST1_HOME/bgs/scripts/best1collect -n operations -p LIST Manager Daemon: INFO - A Manager Daemon is currently running using port 57201 Manager Daemon: INFO - This is a normal condition best1collect on topgun: requesting a listing of collected data via the Service Daemon... Node : operations.

Fri Apr 27 17:43:11 2007 VERSION = "7.3.00" ROOT_REPOSITORY_NAME = "/apps/perform/best1_7.3.00/perform/history" NODE_SELECTOR = "operations" INSTANCE_SELECTOR = "noInstance" STATUS = 0 STATUS_EXPLANATION = "Success" ---Node ----------Instance ----------Time ---noInstance noInstance ---Apr-27-2007.00.00 Mar-23-2006.00.00

operations operations -----------

*Node: operations has acknowledged List request successfully.

This output shows there are two different UDR repositories still on the remote node 'Apr-27-2007.00.00' (today's active collection) and a standed 'Mar-23-2006.00.00' UDR data repository. You must run the query against one node at a time. Therefore, it would be necessary to write some custom scripts to parse a domain/policy file to get a list of machines.

Section III: How can I transfer the data in the data repository on my remote nodes to the console?
KA340164 -- How can Perform UDR capacity planning data be manually transferred from the remote agent node to the Perform console server? If you caught the transfer failure within 7 days then you can use the 'udrCollectMgr' command to pull the data from the remote notes for that day. If you are beyond the 7 day window then you'll need to use the 'best1collect' command to transfer the data yourself. If it is a Perform version 7.2.00 or later remote node you can use the PULL_DELETE option to transfer the data to the console and then have it automatically deleted after the transfer has completed.

Section IV: How can I delete the data in the data repository on the remote nodes from the console?
There is no good way to tell a remote node to delete data in its data repository from the Perform console. If it is a Perform version 7.2.00 or later remote node you can use the PULL_DELETE option to transfer the data to the console and then have it automatically deleted after the transfer has completed. If it is a Perform version 7.1.41 or earlier remote node there really isn't a great way to delete the data from the command line on the console. You could use the 'PUSH' type transfer to transfer the data to the Perform console and have it deleted from the remote node (assuming a firewall didn't prevent the PUSH type transfer).

Section V: Is there any automatic way to report and recover failed transfers?
The UDR Collection Manage (UCM) status reports will tell you if data was successfully transferred from the remote nodes to the console each night. You can find the HTML reports in the $BEST1_HOME/local/manager/status directory on Unix or see then via the PATROL-Manager - Status Reports link in the Perform console. There currently isn't any proactive notification within the product that data transfer has failed. It would be possible to write a custom script to alert on failed transfers using the output from the $BEST1_HOME/bgs/bin/udrCollectStat command on Unix or the %BEST1_HOME%\bgs\bin\udrCollectStat.exe command on Windows. Some information on how to use that command is documented in KA307660 -- What are the format flags available for the udrCollectStat command? Technical Support has created an unsupported proof-of-concept command for the Unix console that uses udrCollectStat output (and other Manager output) to report on collect, transfer, processing, and populate status. You can find that script here ftp://ftp.bmc.com/pub/perform/gfc/tools/processing_status.tar.Z. Usage and sample output are in the comments at the top of the script. I don't believe anything like that really exists for the Windows console.

Legacy ID
10035731 KM-10035731 KM-000010035731 KM-000010035731

Knowledge Article
What is the quickest way to recover from a populate failure in Manager on the BMC Performance Assurance for Unix console?
Back to Answers Printer Friendly Rate this Page

Knowledge Article ID: KA307987 Version: 1.0 Status: Published Published date: 01/20/2011

Problem
When using Unix populate (also called 'mpopulate') to populate Visualizer files into the Oracle database it may be necessary to manually execute the population event if there is a failure during nightly processing. This could be due to the database being offline for maintenance, a problem with the database tablespace (such as it being full), or some other reason. What is the fastest way to recover a failed mpopulate run?

BMC Performance Assurance for Virtual Servers 7.5.00, 7.4.10, 7.4.00, 7.3.00, 7.2.00 BMC Performance Assurance for Servers 7.5.00, 7.4.10, 7.4.00, 7.3.00, 7.2.00 Unix Solution
For the Manager runs where you still have the *.ProcessDay script from the day when population failed you should be able to re-run just the populate step of the Manager run using the following command:

> /[Manager Output Directory]/[Start]-[End].ProcessDay -p

For example, to populate the Visualizer file from March 16th if you have the *.ProcessDay script and the Visualizer file from that day:

> cd [Manager Output Directory] > ./Mar-16-2006.00.00-Mar-16-2006.23.59.ProcessDay -p

This tells the ProcessDay script to only run the populate event. For Manager runs where the *.ProcessDay script has been deleted you'll need to run the mpopulate command by hand from the command line. The command to run is:

> /usr/adm/best1_V.V.VV/bgs/scripts/mpopulate.sh -f /path/visfile.vis dbuser -p dbpass -d DBINSTANCE -l /path/logfile.log -t 1 -s

where:

-u

/path/visfile.vis is the full path to the Visualizer file (or just the name of the Visualizer file if you are running the
command from within the Manager Output Directory (where the Visualizer file resides)

 dbuser is the Database Username (the 'Db_Username' field from the *.Variables file in the Manager Output
Directory)

dbpass is the unencrypted Database Password (alternately, you could specify the '-P [encrypted password]'
instead and use the 'Db_Password' field from the *.Variables file in the Manager Output Directory)

DBINSTANCE is the Database Instance name (the 'Db_Instance' field from the *.Variables file in the Manager
Output Directory)

/path/logfile.log is the mpopulate log file. This can be any file.

Note for VMWare data type Visualizer files

In Perform version 7.4.10 and earlier the VMWare Visualizer files are created using a different process than the normal system Visualizer files and they won't be populated when the '*.ProcessDay -p' command is run. The problem is that the list of Visualizer files that will be populated is build when the Visualizer files are created. That list of created files is then used in the population step. When you run the '*.ProcessDay -p' command it doesn't have that list of VMWare type Visualizer files that had been created by the 'Extract' step so it doesn't know to populate them. There is no way to get those files automatically populated without re-running the whole data processing steps. In Perform version 7.5.00 the VMware Visualizer files are no longer created through this alternate method so they should be populated by the '*.ProcessDay -p' command.

Legacy ID
15104412 SLN15104412 SLN000015104412 20013528