The information in 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 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.

If the following are true, this KB will apply.
  • the output in the are mostly <_nil_ type="info"/> and takes a long time to display completely. To view the tags, you can perform a browser search for "". The <_nil_ type="info"/> xml elements will be listed below the element.

nil xml elements

  • when the 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 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
    • Conditions:
      • Name: is empty
      • Value: is empty
    • Click Save

Related Problem: PRB1194232

Seen In

SR - IRM - Audit Management - New York 2019 Q3
SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - GRC Workbench - New York 2019 Q3
SR - IRM - PA Premium Integration - New York 2019 Q3
SR - IRM - Policy and Compliance - Madrid 2019 Q2
SR - IRM - Risk Management - New York 2019 Q3
SR - IRM - SIG Assessment Legacy - Madrid 2019 Q1
SR - IRM - Vendor Risk Management - Madrid 2019 Q1
SR - Security - Integration Framework - Madrid 2019 Q2
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - SIR - Security Incident Response - Madrid 2019 Q2
SR - SIR - Security Incident Response PA Content - New York 2019 Q3
SR - SIR - Store SecOps Setup Assistant - Madrid 2019 Q2
SR - SIR - Store Threat Core - Madrid 2019 Q2
SR - SIR - Store Trusted Security Circles Client - New York 2019 Q3
SR - VR - Vulnerability Response - New York 2019 Q3

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-03-16 04:14:22