System diagnostic tests

The System Diagnosis tool checks the functioning of the SA core components and the ability of managed servers to interact with the SA core. You can troubleshoot most of the errors that occur within the SA core with the SA diagnosis tool.

The System Diagnosis tool tests the SA core components first, and then, optionally, tests any servers in the managed environment that you specify. The System Diagnosis tool performs intensive testing of core components’ functionality:

• Standalone Tests: Test as much of the functionality of a component as possible without the use of other SA components. Standalone Tests verify base level functionality and a component’s ability to respond to XML-RPC calls.
• Comprehensive Tests: Test the full functionality of all core components.

  Upon completion of Comprehensive Tests, the System Diagnosis tool displays the success or failure of each test, the test results, and error information for any tests that failed.

The core components are not tested in a specific order; however, the tests generally occur in this order:

• Component Standalone Tests

• Component Comprehensive Tests

The following topics are discussed in this section:

• Core Components tested by the system diagnosis tool
• Data access engine tests
• Software repository tests
• Web services data access tests
• Command engine tests
• Model Repository Multimaster component tests

Core Components tested by the system diagnosis tool

The component tests simulate all the component functionality. In addition to errors, the tests verify that each component is functioning within certain conditions (for example, whether database connections are near maximum on the Data Access Engine).

The System Diagnosis tool tests the following components:

• Model Repository

• Data Access Engine

• Software Repository (and Word Store)

• Command Engine

• Server Agents on SA Core servers

• OS Build Manager

• Model Repository Multimaster Component

• Web Services Data Access Engine

Data access engine tests

The following section describes the tests that occur during Data Access Engine diagnostic tests.

Standalone tests

• Check for the current Data Access Engine version.
• Check for the current Model Repository database version.
• Verify that all Oracle objects are valid.
• Obtain a Device object.
• Obtain a MegaDevice object.
• Verifies advanced query functioning.
• Verify a Device object.
• Obtain the list of facilities.
• Obtain the names of the Data Access Engine cronbot jobs.
• Check whether the usage of database connections is below the acceptable level.
• Check whether any database connection has been open more than 600 seconds.
• Check whether the Data Access Engine and Model Repository are in the same facility.
• Verify that all Model Repository garbage-collectors are running when the Model Repository is running in multimaster mode.
• If the Data Access Engine is configured as the central multimaster Data Access Engine:
  • Check whether multimaster transactions are being published.
  • Check whether multimaster transactions are showing up at remote facilities.
  • Check for multimaster transaction conflicts.

Comprehensive tests

• Test connectivity to the Model Repository on the configured port.
• Test connectivity to the Command Engine on the configured port.
• Test connectivity to the Software Repository on the configured port.

Errors caused by additional database privileges

If an additional privilege (permission) has been made manually to the Oracle database (Model Repository), the following error message might appear:

Test Results: The following tables differ between the Data Access Engine and the Model Repository: facilities.

To fix this problem, revoke the database grant. For instructions, see the “Troubleshooting System Diagnosis Errors” section in the SA 10.50 Install Guide.

Software repository tests

The following section describes the tests that occur during Software Repository diagnostic tests.

Standalone tests

None.

Comprehensive tests

• Test whether a file that is not a package can be uploaded to the Software Repository process that serves encrypted files. This test verifies whether the file is present in the Software Repository file system and that the file size matches the source.
• Verify that a file can be downloaded from the Software Repository.
• Verify whether the Software Repository process that serves unencrypted files is running and serving files.
• Try to download a file without encryption.
• Verify that a package can be uploaded to the Software Repository and that the package is registered with the Model Repository.
• Verify that a package can be deleted from the Software Repository and removed from the Model Repository.

Web services data access tests

The following section describes the tests that occur during Web Services Data Access diagnostic tests.

Standalone tests

• Connect to the Web Services Data Access Engine and retrieve its version information.

Comprehensive tests

• Connect to the Web Services Data Access Engine.
• Read a server record from the Model Repository and thereby check connectivity to the Model Repository.

Command engine tests

The following section describes the tests that occur during Command Engine diagnostic tests.

Standalone tests

• Check the state machine.
• Check session tables.
• Check lock-down status.
• Check for signature failures.
• Check command and service tables.
• Check the facility cache.

Comprehensive tests

• Check Data Access Engine connectivity.
• Check security signatures.
• Check lock operation.
• Run an internal script.
• Run an external script.

Model Repository Multimaster component tests

The following section describes the tests that occur during Model Repository Multimaster Component diagnostic tests.

Standalone tests

• Check the ledger state by examining the ledger file.
• Report the total number of messages sent, number of messages still in the ledger file (for example, not confirmed by all listeners), and the sequence number of the last message confirmed by each listener.
• Check the sender health by examining the state of the Outbound Model Repository Multimaster Component.
• Check the receiver health by examining the state of the Inbound Model Repository Multimaster Component.

Comprehensive tests

None.