There are a number of ways in which origins can be incorrect.
- old origin no longer used
- origin renamed to a new origin
- robot is upgraded to become a hub so robotname appears as the hub's origin
- someone accidentally changed the name of the hub
- old TEST or DEV environment origins no longer used or that should NOT show up in the PROD env.
- qos_processor script changing the origin - depending on the script, it could be matching/changing origin for unintended devices.
Perform a backup before changing any data and confirm the backup was successful!!! You must exercise caution if you decide to delete any origins. We recommend that you consult with your DBA or the individual who maintains the NimsoftSLM database before performing any of the actions below.
If you want to keep the data for your old origins you can simply just UPDATE the origin value to the new origin value, e.g., that you created in the hub GUI under->Settings origin override section:
?? SELECT * FROM S_QOS_DATA WHERE ORIGIN = '<OLD/BAD ORIGIN_NAME>'
?? UPDATE S_QOS_DATA SET origin= '<new_origin_name>' WHERE origin =
?? '<old_bad_origin>' OR nim_origin = '<old_bad_origin>'
Then while you have the AccountAdmin (Accounts and Contacts) selected, refresh your browser and then choose Edit->Account and the old/bad origin should be eliminated from the displayed list of Ownership (origins).
You may also have to issue the query below but run a SELECT first to check the CM_COMPUTER_SYSTEM table as well then issue the query only if you have to:
?? UPDATE CM_COMPUTER_SYSTEM SET origin = ?<new_origin_name>? WHERE origin
?? = ?<old_bad_origin>?
If you want to just "cleanup" the old data and origins:
?? SELECT DISTINCT ORIGIN FROM S_QOS_DATA (to generate a list of unique origins)
Identify the "old" or "bad" origins
?? SELECT * FROM S_QOS_DATA WHERE ORIGIN = '<OLD/BAD ORIGIN_NAME>'
This will show you the rows in S_QOS_DATA with that origin. Deleting those rows will delete those old origins. It will also delete any QOS raw data samples which are associated with those lines so be careful and consider the effects and decide as to whether or not you need to keep the origins/data for any reason, e.g., reports/reporting, regulatory requirements, PCI compliance, etc.
?? DELETE from S_QOS_DATA WHERE origin = '<old/bad origin_name>'
If they are very "old" origins, there may not be any recent data and any recent data may be listed under the new/correct origin. You can see this by selecting those rows and using the black drop down arrow to run 'Get Statistics' which will show you when the last QOS samplevalue was collected.
In the case of a robot name being displayed as an origin instead of a hub name, support cannot advise on how this could happen - unless someone in the past mistakenly set the origin override on a robot, or accidentally deployed the hub probe to a robot temporarily, or made some other naming/node role change. There's no "accidental" way for an origin to get "misappropriated" - it would have to have been a result of some sort of manual action / configuration step.
You may only have to do this next step below if you find that there is data still associated with the old/invalid origin as evidenced by SLM->Tools->Database Status row output when you use the black drop down arrow in the SLM portlet to 'Get Statistics' results on the rows relating to the old origins:
On the robot where <probe_name> is located, find the folder \Nimsoft\niscache\ and delete all the files in that folder. If you need to do this for remote robots you can use the niscache_cleaner_1.1 attached to this Article.
Once you have emptied the folder, restart the robot. This will clear any cached data that refers to the old/invalid origin.
If you don?t need to or you?re not required to keep the leftover data for any of the old origins you've identified:
a. Deactivate the data_engine
b.? Run the query:
?? DELETE FROM S_QOS_DATA WHERE ORIGIN = '<old_or_invalid_origin_name>'
c. Activate data_engine
d. If any of the origins still show up after refreshing your browser for UMP while you have the AccountAdmin portlet (Accounts and Contacts) displayed as depicted in the screen shot above, you'll also want to deactivate the discovery_server, and delete any rows that refer to the old/undesired origins with this query.
?? DELETE from CM_COMPUTER_SYSTEM where origin = '<old/bad_origin_name>'
e. Re-run discovery (use the USM Discovery Wizard and 'Run Discovery Now') for the relevant scope/node(s).
Note also that if you need to keep any old QOS data and you are delaing with a small amount of data, you can simply MERGE the data TO the NEW origin using the SLM Merge function.
To merge QOS data manually to the correct/new origin (for a given QOS/small amount of data):
1. Open the Service Level Manager (SLM) Portlet and Choose Tools->Database Status then select the desired QoS or choose ?Cancel? to view ALL of the rows
2. Make sure you have the 'Active Objects' Tab selected (default)
3. Sort on the Quality of Service column
4. Hold down the Ctrl-key and select the QoS objects (of the same QoS type) and then rt-click and select "Merge Objects"
5. Then choose in which 'direction' you want to merge the data, e.g., TO the new/correct origin that contains the QOS data being currently collected
6. You can also choose to delete the source QoS after merge (recommended)
7. Click Merge
Last Step, Summarized
In UMP or the web admin console refresh the browser and the old/bad origin should disappear. If not then clear the browser cache and close the browser and reopen it.
In UMP->Account-Contacts, check the AccountAdmin portlet Accounts via the Edit icon for the Account(s) to see if the old/bad origins have been eliminated.
In IM under Security->Account Administration, check the given Account(s) and the Ownership window to see if the old origins have been eliminated.
***Note that in Infrastructure Manager 4.10 the Account Administration option has been removed. Account admin tasks have all been moved to UMP Accounts and Contacts (AccountAdmin portlet) in the new version.
Best Practices/Other Notes
DBA Administration tools - note that if possible you should use the backend NimsoftSLM database tool of your choice instead of the SLM when dealing with a lot of data, e.g., MS SQL Server Studio, Toad etc. This allows you to execute and Save queries, as well as observe any errors that may occur during query execution.
- In general, as per the results of a select statement query against the S_QOS_DATA tables, if there is no data associated with an old, or invalid origin it can normally be safely deleted.
- If you have a collection of very old data, e.g., data that is many years old with no reason/no contractual or regulatory reasons to keep it, you can safely delete the data from S_QOS_DATA for that origin. To speed things up in cleaning out/removing the old origins, you can run more comprehensive queries such as the following which uses a date value as well but remember to backup the data and confirm the backup was successful since the following actions will delete a significant amount of QOS data.
Another Common Scenario ('leftover' origins)
In some case a given robot may have been upgraded to a hub via installation/configuration, and you see leftover origins, e.g., lowercase robot name shows up in the origin field in S_QOS_DATA and there IS associated data there for that given origin, e.g., aoonocmon03 and the new origin is a different origin name, e.g., AOO_EXT_HUB03
First check for the origin as a Robot/node name in the IM. When you find it take note of the robot name. Then open the hub probe and check the Hub->General->Settings button and check the current hub origin name and take note of it. That is the NEW origin name.
IF there is NO DATA in S_QOS_DATA for the given origin as per:
???? SELECT * from S_QOS_DATA where origin = '<old/bad_origin>'
You can simply delete it using:
???? DELETE FROM S_QOS_DATA where origin = '<old/bad_origin>'
IF there is still data existing under the old origin name (robotname in this case) and you need to keep it for some reason, then you can MERGE the data to the NEW origin)
???? UPDATE S_QOS_DATA SET origin= '<new_origin_name>' WHERE origin =
????? '<old_bad_origin>' OR nim_origin = '<old_bad_origin>'
???? SELECT* from S_QOS_DATA where origin = '<old/bad_origin>'
...to make sure all the data has been updated to the new origin, hence, you should get 0 rows.
IF you still see leftover/old/bad origins in UMP under Account->Contacts, when you Edit the Account. and view-> Ownership (origins) then you have to delete the relevant entries for the old/bad origin in the CM_ACCOUNT_OWNERSHIP table.
???? SELECT * FROM CM_ACCOUNT_OWNERSHIP
???? DELETE FROM CM_ACCOUNT_OWNERSHIP where origin = '<old/bad_origin>'
To ensure you refresh the view in UMP don't just refresh the browser, e.g., press F5, also make sure you switch from one Tab to another then back to re-check that the origins have been deleted. if the origin(s) still show up log out and log back in again to UMP and/or check for the existence of any data associated with the old origin.
ProcedureSee Introduction section.