New IBM Traveler command tablerepair should be used after upgrading to version 9.0.1.15

Detlev Poettgen  November 18 2016 04:59:09 PM

This week IBM released IBM Traveler 9.0.1.15.

During the first start of the Traveler server task after upgrading to 9.0.1.15, Traveler will try to upgrade the database schema of the Traveler state database (Derby running Standalone or DB2/MS SQL running HA) to schema version 20160812.
The new schema will add new Primary key definitions to the GUIDMAP, PUSH, REPLICAS and TS_FILTERS tables.

Before upgrading the schema, the task will check if the existing records of the GUIDMAP, PUSH, REPLICAS and TS_FILTERS tables are consistent. If there are any inconsistent records, you will receive an error/warning message on the console.

You will have to fix these errors before the schema can be updated. To do that, you should use the new tablerepair command:

Tablerepair help	Displays usage information for the tablerepair command.
Tablerepair show tablename	Displays the number of users having records that might prevent a Primary Key from being added to the table. Option for tablename: GUIDMAP, PUSH, REPLICAS, TS_FILTERS or * for all.
Tablerepair repair tablename number_of_users	Repairs the table listed for the number of users specified by issuing a reset for the user. The Primary Key for the table will be added automatically once the table is repaired. Options for tablename: GUIDMAP, PUSH, REPLICAS, TS_FILTERS or * for all. Options for number_of_users: Integer > 1 or * to indicate all.

It is similar to the DBAccountsCheck Command, which was added with 9.0.1.9. Details can be found here.

After upgrading to 9.0.1.15 you should first check the console messages or your server log regarding this messages:

18.11.2016 13:05:59   Traveler: Upgrading IBM Traveler Database schema from version 20160301 to version 20160812
18.11.2016 13:06:05   Traveler: GUIDMAP has no records violating the constraint.
18.11.2016 13:06:05   Traveler: Primary key PK_GUIDMAP successfully created.
18.11.2016 13:06:05   Traveler: GUIDMAP table is repaired.
18.11.2016 13:06:05   Traveler: TS_FILTERS has no violating records.
18.11.2016 13:06:05   Traveler: Primary key PK_TSFILTERS successfully created.
18.11.2016 13:06:05   Traveler: TS_FILTERS table is repaired.
18.11.2016 13:06:05   Traveler: PUSH has no violating records.
18.11.2016 13:06:05   Traveler: Primary key PK_PUSH successfully created.
18.11.2016 13:06:05   Traveler: PUSH table is repaired.
18.11.2016 13:06:05   Traveler: REPLICAS has no violating records.
18.11.2016 13:06:05   Traveler: Primary key PK_REPLICAS successfully created.
18.11.2016 13:06:05   Traveler: REPLICAS table is repaired.

In my case everything was okay and no further action was needed.

I would recommend issuing following command to check if all is fine:

tell traveler tablerepair show *

[0860:0026-0D80] 18.11.2016 18:23:19   Traveler: GUIDMAP table is repaired.
[0860:0026-0D80] 18.11.2016 18:23:19   Traveler: TS_FILTERS table is repaired.
[0860:0026-0D80] 18.11.2016 18:23:19   Traveler: PUSH table is repaired.
[0860:0026-0D80] 18.11.2016 18:23:19   Traveler: REPLICAS table is repaired.

If any table can't get repaired, you will have to run the tabelrepair command with the repair option.

Example to fix the entries in the GUIDMAP table:

tell traveler tablerepair repair GUIDMAP 50

Will issue a tell traveler reset * username command for the first 50  effected users.

Warning:

Because the repair option will enforce an reset * command, have in mind, that the specific users will get an initial sync for their devices. So running the command in small batches will make sense.

• Kommentare [2]