Database Validation

Database migration includes a number of checks on the quality of the resulting database.

The first of these is a check of database constraints that may have been either enabled or disabled without data checks. If constraint errors are detected, the migration process corrects them. Where a constraint is enabled, the process also attempts to ensure that the data it covers is appropriate for the constraint. Generally, this succeeds without issue, and the change is simply noted in the migration log. However, if it fails, the migration process also fails with an error similar to:
ERROR: One or more constraints cannot be enabled (step number 99).
If this occurs, the names of the constraints that cannot be enabled are listed in the migration log. Restarting the migration at this time does not help this issue, and the database is unusable for production work. First, a database administrator or a Flexera support engineer must manually correct the issue with the underlying data. Once the data has been corrected, the migration process will be able to be restarted safely.

At the end of the migration process, there is a final schema check of the upgraded database to ensure that the upgrade has been successful. Messages from this database check may appear in your console towards the end of the process, after the migration itself is completed.

This check is included for the three main system databases: the compliance database, the inventory database, and the data warehouse database.

When these checks are run, the upgrade has already been completed without errors, and the database is likely to be usable. These are additional checks to look for irregularities in the database that may cause future operational problems. These kinds of irregularities may occur because:
  • The earlier database had previously been changed (either by database administrators or by a Flexera consultant) in ways that are not supported by the product
  • A previous migration updated the database in ways that were not entirely correct, but not previously detected
  • Something has occurred in the present migration that did not raise an error in the migration, but leaves the database in a less than perfect condition.
Such causes can produce a range of possible issues, including:
  • Missing tables, indexes, columns, or foreign keys
  • Extra indexes, columns or foreign keys
  • Incorrectly configured columns (the size differs, or their nullability)
  • An index configured in unexpected ways, either in its uniqueness, its clustering status, or in the columns it covers.

For the above cases, assistance from a database administrator or Flexera support engineer is also required to correct the schema. In many cases, the issues described in the log can be remedied in place, without requiring that the database migration process is restarted.