The information in xmlstats.do is used as part of the pre-flight checks when there is a need to perform a AHA transfer of your instance from Primary to the standby side. If the xmlstats.do is very large, manual interventions may be required before the transfer can take place which may impact the time taken to perform the transfer of your instance.
- the output in the xmlstats.do are mostly <_nil_ type="info"/> and takes a long time to display completely. To view the tags, you can perform a browser search for "glide.build.tag". The <_nil_ type="info"/> xml elements will be listed below the glide.build.tag element.
- when the xmlstats.do page is saved to the local disk, the file size at least a few megabytes.
- the sys_status table has a large number of records where the name and value is empty
Steps to Reproduce
The <_nil_ type="info"/> in the xmlstats.do is retrieved from the data in sys_status table.
1. One of the common cause of these large number of invalid sys_status records (where the name and value fields are empty) is the instance admin has made changes to an out of the box ACL - *.* where the admin has added roles to this ACL.
2. The roles for the *.* ACL would be different from that in the create ACL for the sys_status table.
3. A user who is having a role that is listed in the create ACL for the sys_status table will be able to create a record but will be prevented from populating the values in that row as the role is not included in the *.* ACL.
In general, if there are any differences in the roles listed in "Require role" between the following ACLs for the user performing the insert and the user is not having the required role, this will result in invalid records in sys_status
- allows the creation of a row in sys_status table
- allows the populating of values in the columns of sys_status row
For more information on ACL, please refer to "ACL rule types" in our Product Documentation website
To resolve this,
1. Ensure that the roles in the "Required role" in *.* ACL and the Create ACL of the sys_status table are consistent and the user performing the insert has the required roles
With reference to the example in the Steps to reproduce section, you may want to revert the *.* ACL to one which is out of the box (which is having either no roles or the role: snc_internal, depending on the release). You may want to compare the *.* ACL against a subproduction instance which is of the same release and the *.* ACL has not been modified. Alternatively, make the required changes to the roles in the "Required role" list in a subproduction instance to test if the number of invalid sys_status records has stopped increasing.
2. After which, for the cleanup of the invalid sys_status records, you can filter for records where name is empty and value is empty and perform the delete of the records via UI. If the number of records is too large, please reach out to Support who will be able to clean up these records on your behalf. There will not be any downtime required for this cleanup.
- Support may need to perform the cleanup as per point 2 above to prevent any issues with automation such as AHA, clone.
- If you need time to figure out the changes needed to the ACLs and if the number of invalid records in sys_status is growing, please consider performing point 2 above first and implementing a table cleanup record for continuous clean up.
For the table cleanup record, navigate to Automated Test Framework > Administration > Table Cleanup
- filter for Tablename is sys_status to check if there is an existing record
- click New and use the following:
- Tablename: Component Status [sys_status]
- Matchfield: sys_created_on
- Age in seconds: 0
- Active: checked
- Name: is empty
- Value: is empty
- Click Save
Related Problem: PRB1194232