Database problems

Edit online

Database problems are related to issues with connecting to DB2 and MS SQL Server as well as retrieving information from these databases.

Windows MS SQL Server

During the import, MS SQL Server uses 99% of the physical memory.
To solve the problem, set the maximum amount of memory that can be used by MS SQL Server. For more information, see Server Memory Options and How to: Set a Fixed Amount of Memory (SQL Server Management Studio) in the MS SQL Server documentation.
The login process to MS SQL Server fails.
During a login process to MS SQL Server, the following error is displayed: 
Login failed for user 'username'. The user is not associated with a trusted SQL Server connection.
(Microsoft SQL Server, Error: 18452).

The cause of this error is that MS SQL Server is configured to use Windows Authentication mode and does not allow the use of MS SQL Server accounts. To solve this problem, enable the MS SQL Server Authentication in MS SQL Server. For more information, see Enabling the MS SQL Server Authentication Mode.

Linux DB2

License Metric Tool cannot connect to its database and the following error is written in the logs: Connection refused. ERRORCODE=-4499, SQLSTATE=08001.
The problem occurs because the DB2® database is not yet activated after a restart and is thus not accessible to License Metric Tool. To solve the problem, run the following command after you restart the database:
db2 activate db database_name
License Metric Tool cannot connect to the database. The default port range is modified.
The default local port range for Linux® is 32768-61000. If the default range is modified, it is possible that the DB2 port number is allocated to another local process. If the port number is pre-allocated, License Metric Tool cannot connect to DB2. Complete the following steps:
  • Ensure that IPv4 is being used.
  • Use the netstat command to check whether DB2 is listening on the expected port, and no other socket is pre-allocated the DB2 port.
  • If DB2 is not listening on the expected port, restart DB2 and check again.
It is impossible to establish a connection to a data source in the License Metric Tool web user interface with single sign-on enabled.
An error message is displayed after you saved the connection parameters on the Data Sources pane:
Unexpected WebSEAL Response.
Code: 0x38cf04d3
Error: DPWWA1235E
Please contact your system administrator. This may indicate an insufficient proxy HTTPS timeout.
To be able to save the connection parameters successfully, increase the https-timeout parameter in the ISAM Reverse Proxy configuration. For example, to set the timeout to 5 minutes, perform the following steps.
  1. Log on to IBM Security Access Manager.
  2. In the top navigation bar, click Secure Web Settings > Manage > Reverse Proxy.
  3. Select the instance and then, from the drop-down list on the right of the Reverse Proxy bar, select Manage > Configuration > Edit Configuration File.
  4. In the Advanced Configuration File Editor, locate the https-timeout parameter and specify the value of 300.
    Example:
    https-timeout = 300
  5. Click Save.
After upgrading DB2, the License Metric Tool server cannot start and the SRVE0296E error is written in the tema.log file.
After you upgrade DB2, the License Metric Tool server cannot start because it cannot access the SCHEMA_MIGRATIONS table. The following error is written in the tema.log file.
com.ibm.ws.webcontainer.webapp I SRVE0296E: 
[tema][/][Servlet.LOG]:.ERROR: initialization failed:
.org.jruby.rack.RackInitializationException: DBNAME: 
temadb - Java::ComIbmDb2JccAm::SqlSyntaxErrorException: 
The name of the object to be created is identical 
to the existing name "DBO.SCHEMA_MIGRATIONS" of type "TABLE".. 
SQLCODE=-601, SQLSTATE=42710, DRIVER=3.72.24from 
com.ibm.db2.jcc.am.hd.a(com/ibm/db2/jcc/am/hd.java:813)...

For information how to solve the problem, see: SQL0443N with -727 when calling catalog functions such as SYSIBM.SQLTABLES.

DB2 service cannot be started after system reboot. The problem occurs when DB2 is installed by a non-root user.
DB2 log file db2diag.log contains the following error.
FUNCTION: DB2 UDB, SQO Memory Management, 
"No Storage Available for allocation", 
DIA8305C Memory allocation failure occurred.
To solve the problem, change the ulimit value. For more information, see the following links.
All-in-One installation fails during the creation of the BigFix® database. The following error is written in the BESInstall.log log: SQL1205N The code page "1208" and/or territory code "0" that has been specified is not valid.
To solve the problem, perform the following steps.
  1. Go to the <AIO installer>/prereq/db2/server directory, and open the db2_run_setup.sh script.
  2. Add the following three lines before the exit $rc line.
    su - db2inst1 -c 'db2set DB2CODEPAGE=1208'
su - db2inst1 -c 'db2set DB2TERRITORY=1'
su - db2inst1 -c 'db2set DB2COUNTRY=1'
  3. Go to the <AIO installer>/tools directory, and run the cleanlmtenv.sh script to remove all components that were installed.
  4. Run the All-in-One installer again.

Both databases

After you restore the BigFix database, new data is not displayed in License Metric Tool.
To ensure that only newly created data is imported to License Metric Tool, the data that is stored in the BigFix database is marked with the so-called sequence number. The number is incremented with every change. Every import contains data starting from the sequence number reported during the last successful import to the current sequence number.

When the BigFix database is restored, the sequence number is restored to the value from the time when the database backup was created. Thus, it might happen that the sequence number after the restoration is lower than the sequence number reported during the last successful import. In such case, the first import after the database restoration does not include any data. After that import, the sequence number is updated and the next import contains new data.

However, data from the period between the database restoration and the first successful import is not imported which creates a gap. To solve the problem, go to Management > Advanced Server Settings, and change the value of the resynchronize_datasources_once parameter to true. Then, run an import. This import will be time-consuming as it will import all software scan data from the restored BigFix database to cover the gap. The subsequent imports will run in the normal operation mode.

Checking the database name.
The default database name is TEMADB, however it changed since earlier versions, where the database was called SUADB. You can check the name of your database in the database.yml file in one of the following directories.

Linux /opt/ibm/LMT/wlp/usr/servers/server1/config/database.yml

Windows C:\Program Files\IBM\LMT\wlp\usr\servers\server1\config\database.yml

In earlier versions, the default installation path is C:\Program Files\IBM\SUA or /opt/ibm/SUA.