The Hierarchy page is loading too slow. Unable to load the page the all.

Article:TECH152338  |  Created: 2011-01-31  |  Updated: 2011-08-15  |  Article URL http://www.symantec.com/docs/TECH152338
NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.
Article Type
Technical Solution


Environment

Issue



The Hierarchy page (in the SMP 7.0 Console, under Settings>Notification Server>Hierarchy) is not loading the all or takes too long to load.


Error



In some cases it will display a 'Request Timed Out' or a 'Symantec Management Server Error' page


Environment



Noticed first with Symantec Management Platform 7.0 SP5


Cause



The cause was the fact that the Hierarchy Maintenance Page tries to load Urgent Hierarchy Replication rules (to get their status) and if there is a huge number of Urgent Rules still hanging around causes a delay in loading this page.

All locations within the SMP core that create urgent hierarchy rules, set the ‘DeleteOnCompletion’ property to true, indicating that the rule will be deleted shortly after replication has completed.

There are a number of things that could cause the buildup of instances as seen on the customer database.
1. There is a solution that creates instances of the UrgentHierarchyRule without setting the ‘DeleteOnCompletion’ property to true.
2. Replication is never completing meaning the rules never get a change to delete themselves.
3. The schedule ‘NS.Quarter-Hour.{5834ae07-1160-4037-8a25-67aebf6a254e}’ is not being run.
4. When the UrgentHierarchyRules write entries into the ‘ItemToDelete’ table, they use the current datetime on the NS and add 60 seconds. If the SQL Servers date time varies from the NS date time then these rows will not be deleted either. I.e. current NS date is 1/1/2011 while the SQL Server current date is 1/1/1970 for whatever reason


Solution



1. Run this query to check the number of rows of Urgent Replication Rules:

SELECT COUNT (*) FROM NSInternal_ItemInstalled nsi
JOIN Item i on nsi.Guid = i.Guid
JOIN ItemClass ic On i.Guid = ic.Guid
WHERE ic.ClassGuid = '8122C5CA-182C-490E-8D22-602F896F5E25'
AND nsi.ProductUninstalled = 0
 

2. The following queries should set all the Urgent Replication Rules to uninstalled. This will set the page to avoid checking those Urgent Replication Rules statuses. You may need to wait until NS.Daily runs in order to see the changes applied.
Note:  check Replication Activity with the report to determine if there are any Urgent Rules running.

UPDATE NSInternal_ItemInstalled
SET ProductUninstalled = 1
FROM NSInternal_ItemInstalled nsi
JOIN Item i on nsi.Guid = i.Guid
JOIN ItemClass ic On i.Guid = ic.Guid
WHERE ic.ClassGuid = '8122C5CA-182C-490E-8D22-602F896F5E25'


UPDATE Item
SET ProductUninstalled = 1
FROM Item i
JOIN ItemClass ic On i.Guid = ic.Guid
WHERE ic.ClassGuid = '8122C5CA-182C-490E-8D22-602F896F5E25'

--In this way, if you need to undo the change, you can always update again and set the ProductUninstalled to 0.

3. Run the query in step 1 in a regular basis to see if there is a possibility of getting again a large number of Urgent Replication Rules..

 


Supplemental Materials

SourceETrack
Value2326493


Article URL http://www.symantec.com/docs/TECH152338


Terms of use for this information are found in Legal Notices