安装和升级 > 升级 ThingWorx > 手动升级 > Linux 手动升级 > 手动就地升级到 9.0.x、9.1.x 和 9.2.x：Linux
手动就地升级到 9.0.x、9.1.x 和 9.2.x：Linux
要确定升级路径，请参阅升级表格。下列步骤仅适用于就地升级。要进行迁移升级，请参阅手动迁移至 ThingWorx 9.x：Linux。
* 
目前，不支持 H2 的大整数/时区数据库迁移脚本。这些迁移脚本针对其他受支持的数据库进行了详细说明。如果存在现有 H2 数据库且需要进行时区修正，则必须迁移至受支持的数据库，例如 PostgreSQL 或 MS SQL。如果应用程序将在未进行时区修正的情况下运行，则可在 H2 上升级至 ThingWorx 的最新版本。请注意，您将跳过前面提到的设置 ThingWorx 服务器时区部分。
A.) 升级前 
1. 如果您使用的是 RHEL 操作系统，请先验证是否已升级至支持的版本，然后再升级 ThingWorx。有关详细信息，请参阅系统要求。
* 
仅 RHEL 8.2 支持 ThingWorx 9.1。
2. 在开始升级之前，建议执行以下操作：
◦ 数据库转储
◦ 备份 ThingworxStorage 和 ThingworxPlatform 文件夹中的所有数据。
◦ 备份 Tomcat_home 文件夹。这包括 bin、conf、lib、temp、webapps 和 work 文件夹。
3. 如果除 ThingWorx 平台外，还使用 ThingWorx Apps：
a. 请验证 ThingWorx Apps 版本是否支持要升级到的 ThingWorx 版本。请参阅 ThingWorx Apps Upgrade Support Matrix (ThingWorx Apps 升级支持一览表)。
b. 进行平台升级之前，必须先执行一些步骤。在继续下一步骤之前，请参阅升级 ThingWorx Apps。
4. 如果还安装了 Navigate，请在 ThingWorx Navigate 兼容性一览表处验证兼容性。
5. 从 PTC 软件下载页面获取 ThingWorx 的最新版本。
* 
在当前用户具有写入权限的文件夹中下载并提取 ThingWorx 内容。需要具有写入权限，因为更新脚本会在此过程中创建一些文件。
6. 验证您是否正在运行所需版本的 Tomcat 和 Java。有关版本要求的信息，请参阅系统要求。
* 
如果必须升级 Java 版本，请在升级 Java 前先升级 ThingWorx。
7. 当您升级 MSSQL、Azure SQL 或 H2 时，如果数据表中缺少任何自定义索引字段值，升级将失败。在开始升级过程之前，请验证是否所有自定义索引字段均具有值。
* 
如果不能执行此操作，则升级将失败，您必须再次部署较旧版本 (如果进行了架构更新，则需要回滚/恢复数据库)，并添加缺失的索引值或从数据表中移除自定义索引，然后再执行升级。
8. 将以下内容添加到 Apache Tomcat Java 选项中：
-Dlog4j2.formatMsgNoLookups=true
B.) 导出流和值流数据 (仅适用于 InfluxDB) 
* 
仅在使用 InfluxDB 1.7.x (用于 ThingWorx 8.5.x 或 9.0.x) 至 InfluxDB 1.8.x (用于 ThingWorx 9.1.x 或 9.2.x) 升级 ThingWorx 时需要此部分中的步骤。
1. 从 InfluxDB 1.7.x/MS SQL/PostgreSQL 中导出数据：
a. 以管理员身份登录到 ThingWorx。
b. 单击“导入/导出”>“导出”。
c. 使用下列选项：
▪ 对于“导出选项”，请选择“至文件”。
▪ 对于“导出类型”，请选择“数据集合”。
▪ 对于“集合”，请选择“流”。
▪ 单击“导出”。
d. 对于值流数据，请重复步骤 a-c。
e. 将从系统信息库创建的流数据和值流数据的导出文件夹移动到安全位置作为备份。
C.) 停止并删除 ThingWorx Web 应用程序 
1. 停止 Tomcat。
2. 强烈建议您先备份以下两个文件夹，然后再继续操作：
◦ Apache Software Foundation/Tomcat x.x/webapps/Thingworx
◦ /ThingworxStorage
3. 如果当前 Tomcat 版本较旧，且不受目标 ThingWorx 版本支持，则需要更新为受支持的 Tomcat 版本。
4. 要保留现有安装的 SSO 配置，请备份 <Tomcat 安装目录>\webapps\Thingworx\WEB-INF 文件夹中的 web.xml。
5. 备份 /ThingworxStorage/esapi 目录中的 validation.properties 文件，然后将其删除。
* 
validation.properties 文件将在启动 ThingWorx 时创建。如果要保留所做的任何更改，请将此文件保存在 ThingworxStorage 目录之外的位置，然后继续移除 esapi 目录。启动时，ThingWorx 将重新创建该文件，您可以将自定义正则表达式重新添加到自动生成的 validation.properties 文件中。
有关其他信息，请参阅本主题。
6. 转至 /Apache Software Foundation/Tomcat x.x/webapps 下的 Tomcat 安装，然后删除 Thingworx.war 文件和 Thingworx 文件夹。
D.) 设置 ThingWorx 服务器时区 
如果要在 H2 上进行升级，请跳过此步骤。对于其他所有数据库，可将以下参数添加到 Tomcat Java 选项，以设置 ThingWorx 服务器时区：
-Duser.timezone=UTC
E.) 更新架构并迁移数据 (仅适用于 PostgreSQL) 
* 
所有升级均需且仅需本部分中的步骤 1。
如果是 ThingWorx 8.4.x 或 8.5.x --> 9.0.x、9.1.x 或 9.2.x 版本的升级，请执行本部分中的其余步骤。
如果是 ThingWorx 9.0.x 或 9.1.x --> 9.1.x 或 9.2.x 版本的升级，请跳过本部分中的其余步骤。
1. 运行位于 ThingWorx 软件下载的 update 文件夹中的以下脚本 (从要升级的版本开始)：
thingworxPostgresSchemaUpdate8.4-to-8.5.sh
thingworxPostgresSchemaUpdate8.5-to-9.0.sh
thingworxPostgresSchemaUpdate9.1-to-9.2.sh
* 
无需运行 thingworxPostgresSchemaUpdate9.0-to-9.1.sh 脚本，因为 9.1 中不存在架构更新。虽然出于完整性目的，update 文件夹中包含了脚本，但该脚本却为空脚本且仅适用于执行自动升级过程的用户。
* 
仅当从 ThingWorx 8.4.x 或 8.5.x 升级至 9.0.x、9.1.x 或 9.2.x 时，才需执行本部分中的其余步骤。如果从 ThingWorx 9.0.x 升级至 9.1.x 或 9.2.x.，则可跳过本部分中的其余步骤。
2. 运行大整数/时区设置脚本以准备要迁移的数据库：
* 
如果已使用 UTC 运行 ThingWorx，则对于大整数更改，仍需运行迁移，但可同时为 sourceTZ 和 targetTZ 参数 (在以下步骤中的某些脚本中可用) 提供 UTC 值。
thingworxPostgresDBSetupBigIntTimezoneDataUpdate.sh
3. 要查找所有支持的时区，请使用以下命令：
select pg_timezone_names()
* 
在为以下数据迁移脚本指定时区时，所指定的时区名称必须与 pg_timezone_names() 脚本所显示的正式名称之一完全匹配。
4. 运行模型迁移脚本以迁移所有模型数据：
* 
在运行脚本前，请在文本编辑器中打开脚本，以确保其默认环境值 (例如服务器、端口、时区等) 均正确无误且满足当前环境。如果脚本内定义的任何默认值不适用于当前环境，请通过指定一个或多个命令行自变量来覆盖运行脚本时的默认值。
thingworxPostgresModelTablesDataUpdate.sh
* 
用法：
thingworxPostgresModelTablesDataUpdate.sh [-h <server>] [-p <port>] [-d <Thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>]
示例：
thingworxPostgresModelTablesDataUpdate.sh -sourceTZ US/Eastern -targetTZ Etc/UTC
5. 运行以下各个架构迁移脚本，以创建所有数据表数据、流数据和值流数据的备份表：
* 
出于性能方面的原因，这些脚本实际上不会在这些表中创建原始数据的副本。相反，这些脚本会将这些现有的表从 "<original-table-name>" 重命名为 "<original-table-name>_backup"。由此可避免执行实际复制数据的过程，因为这一过程可能会比较耗时。对这些现有的表 (进而成为备份表) 进行重命名后，即会以原始名称创建新表。这些新表为空，并且与原始表具有相同的作用 (因为它们的名称与原始表相同)。这些新表将在后面的步骤中用迁移数据进行填充。
thingworxPostgresDataTableSchemaUpdate.sh
thingworxPostgresStreamSchemaUpdate.sh
thingworxPostgresValueStreamSchemaUpdate.sh
6. 打开新的命令提示符窗口并运行以下数据迁移脚本，以迁移备份表中的数据表数据：
* 
在运行脚本前，请在文本编辑器中打开脚本，以确保其默认环境值 (例如服务器、端口、时区等) 均正确无误且满足当前环境。如果脚本内定义的任何默认值不适用于当前环境，请通过指定一个或多个命令行自变量来覆盖运行脚本时的默认值。
thingworxPostgresDataTableDataUpdate.sh
* 
用法：
thingworxPostgresDataTableDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]
示例：
thingworxPostgresDataTablesDataUpdate.sh -sourceTZ US/Eastern -targetTZ Etc/UTC
启动此迁移脚本后，请等待，直到控制台上显示一条消息，指示可以安全地重新启动 Tomcat。显示该消息后，可以安全地继续执行下一步，即使此迁移脚本尚未执行完毕也是如此。
7. 打开新的命令提示符窗口并运行以下数据迁移脚本，以迁移备份表中的流数据和值流数据：
* 
在运行脚本前，请在文本编辑器中打开脚本，以确保其默认环境值 (例如服务器、端口、时区等) 均正确无误且满足当前环境。如果脚本内定义的任何默认值不适用于当前环境，请通过指定一个或多个命令行自变量来覆盖运行脚本时的默认值。
thingworxPostgresStreamDataUpdate.sh
thingworxPostgresValueStreamDataUpdate.sh
* 
用法：
thingworxPostgresStreamDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]
thingworxPostgresValueStreamDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]
示例：
thingworxPostgresStreamDataUpdate.sh -sourceTz US/Eastern -targetTZ Etc/UTC -chunkSize 5000
thingworxPostgresValueStreamDataUpdate.sh -sourceTz US/Eastern -targetTZ Etc/UTC -chunkSize 5000
启动这两个迁移脚本后，请不要继续执行下一步操作，直到这些迁移脚本以及数据表迁移脚本 (在上一步中开始运行) 已成功完成运行。
8. 手动验证以下脚本是否已全部成功完成运行：thingworxPostgresDataTableDataUpdate.sh、thingworxPostgresStreamDataUpdate.sh 和 thingworxPostgresValueStreamDataUpdate.sh。验证是否已成功迁移所有数据表数据、流数据和值流数据。
9. 运行清理脚本以移除迁移过程中所需的任何临时数据库对象：
* 
尽管此脚本确实会对升级过程中创建的临时数据库对象执行一些清理操作，但此脚本并*不*会删除在上述步骤中创建的任何备份表，也不会修改这些备份表中的任何数据。此行为是有意而为之的，可确保数据不会遭到意外删除。如果要删除这些备份表，则必须手动将其删除。
thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh
脚本故障排除
* 
必须针对 ThingWorx 数据库运行以下命令。
• 错误代码 23505 表示插入时存在重复键唯一约束违规。要解决此问题：
a. 运行以下命令：
Select * from migration_log where status = -1 OR status = 0.
b. 记录所返回的各个行的 fromId 和 toId 范围。
c. 在数据表中查询从迁移日志写入的 entry_ids 。
d. 如果对于任意范围，记录全部都在，则将 0 或 -1 均更改为 1。如果记录在某个范围内部分缺失，请尝试一个较小的块大小，或删除已迁移到表格中的记录，然后再次尝试迁移。
• 要查找所有支持的时区，可使用以下命令：
select pg_timezone_names()
您必须使用最先列出的正式名称，才能使 PostgreSQL 根据给定时间戳自动解析日期偏移量。
• 要验证是否已迁移全部 entry_ids，请使用与以下代码段类似的 SQL 查询：
SELECT entry_id FROM data_table_backup EXCEPT SELECT entry_id FROM data_table
SELECT entry_id FROM data_table EXCEPT SELECT entry_id FROM data_table_backup
• 如果系统中使用的环境变量为 PGPASSWORD，则必须将该变量传递到 -r 参数中，才能设置运行脚本时应使用的密码。
F.) 更新架构并迁移数据 (仅适用于 MSSQL) 
* 
所有升级均需且仅需本部分中的步骤 1。
如果是 ThingWorx 8.4.x 或 8.5.x --> 9.0.x、9.1.x 或 9.2.x 版本的升级，请执行本部分中的其余步骤。
如果是 ThingWorx 9.0.x 或 9.1.x --> 9.1.x 或 9.2.x 版本的升级，请跳过本部分中的其余步骤。
1. 将 ThingWorx 软件下载中的整个 update 文件夹复制到 MS SQL 服务器中，并运行位于 update 文件夹中的以下脚本 (从要升级的版本开始)：
thingworxMssqlSchemaUpdate8.4-to-8.5.sh
thingworxMssqlSchemaUpdate8.5-to-9.0.sh
thingworxMssqlSchemaUpdate9.1-to-9.2.sh
* 
无需运行 thingworxMssqlSchemaUpdate9.0-to-9.1.sh 脚本，因为 9.1 中不存在架构更改。虽然出于完整性目的，update 文件夹中包含了脚本，但该脚本却为空脚本且仅适用于执行自动升级过程的用户。
* 
仅当从 ThingWorx 8.4.x 或 8.5.x 升级至 9.0.x、9.1.x 或 9.2.x 时，才需执行本部分中的其余步骤。如果从 ThingWorx 9.0.x 升级至 9.1.x 或 9.2.x.，则可跳过本部分中的其余步骤。
2. 运行大整数/时区设置脚本以准备要迁移的数据库：
* 
如果已使用 UTC 运行 ThingWorx，则对于大整数更改，仍需运行迁移，但可同时为 sourceTZ 和 targetTZ 参数 (在以下步骤中的某些脚本中可用) 提供 UTC 值。
thingworxMssqlDBSetupBigIntTimezoneDataUpdate.sh
3. 运行模型迁移脚本以迁移所有模型数据：
* 
在运行脚本前，请在文本编辑器中打开脚本，以确保其默认环境值 (例如服务器、端口、时区等) 均正确无误且满足当前环境。如果脚本内定义的任何默认值不适用于当前环境，请通过指定一个或多个命令行自变量来覆盖运行脚本时的默认值。
thingworxMssqlModelTablesDataUpdate.sh
* 
用法：
thingworxMssqlModelTablesDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>]
示例：
thingworxMssqlModelTablesDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC
4. 运行以下各个架构迁移脚本，以创建所有数据表数据、流数据和值流数据的备份表：
* 
出于性能方面的原因，这些脚本实际上不会在这些表中创建原始数据的副本。相反，这些脚本会将这些现有的表从 "<original-table-name>" 重命名为 "<original-table-name>_backup"。由此可避免执行实际复制数据的过程，因为这一过程可能会比较耗时。对这些现有的表 (进而成为备份表) 进行重命名后，即会以原始名称创建新表。这些新表为空，并且与原始表具有相同的作用 (因为它们的名称与原始表相同)。这些新表将在后面的步骤中用迁移数据进行填充。
thingworxMssqlDataTableSchemaUpdate.sh
thingworxMssqlStreamSchemaUpdate.sh
thingworxMssqlValueStreamSchemaUpdate.sh
5. 打开新的命令提示符窗口并运行以下数据迁移脚本，以迁移备份表中的数据表数据：
* 
在运行脚本前，请在文本编辑器中打开脚本，以确保其默认环境值 (例如服务器、端口、时区等) 均正确无误且满足当前环境。如果脚本内定义的任何默认值不适用于当前环境，请通过指定一个或多个命令行自变量来覆盖运行脚本时的默认值。
thingworxMssqlDataTableDataUpdate.sh
* 
用法：
thingworxMssqlDataTableDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]
示例：
thingworxMssqlDataTableDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000
启动此迁移脚本后，请等待，直到控制台上显示一条消息，指示可以安全地重新启动 Tomcat。显示该消息后，可以安全地继续执行下一步，即使此迁移脚本尚未执行完毕也是如此。
6. 打开新的命令提示符窗口并运行以下数据迁移脚本，以迁移备份表中的流数据和值流数据：
* 
在运行脚本前，请在文本编辑器中打开脚本，以确保其默认环境值 (例如服务器、端口、时区等) 均正确无误且满足当前环境。如果脚本内定义的任何默认值不适用于当前环境，请通过指定一个或多个命令行自变量来覆盖运行脚本时的默认值。
thingworxMssqlStreamDataUpdate.sh
thingworxMssqlValueStreamDataUpdate.sh
* 
用法：
thingworxMssqlStreamDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]
thingworxMssqlValueStreamDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]
示例：
thingworxMssqlStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000
thingworxMssqlValueStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000
启动这两个迁移脚本后，请不要继续执行下一步操作，直到这些迁移脚本以及数据表迁移脚本 (在上一步中开始运行) 已成功完成运行。
7. 手动验证以下脚本是否已全部成功完成运行：thingworxMssqlDataTableDataUpdate.sh、thingworxMssqlStreamDataUpdate.sh 和 thingworxMssqlValueStreamDataUpdate.sh，并验证是否已成功迁移所有数据表数据、流数据和值流数据。
8. 运行清理脚本以移除迁移过程中所需的任何临时数据库对象：
* 
尽管此脚本确实会对升级过程中创建的临时数据库对象执行一些清理操作，但此脚本并*不*会删除在上述步骤中创建的任何备份表，也不会修改这些备份表中的任何数据。此行为是有意而为之的，可确保数据不会遭到意外删除。如果要删除这些备份表，则必须手动将其删除。
thingworxMssqlDBCleanupBigIntTimezoneDataUpdate.sh
脚本故障排除
• 要查找所有支持的时区，请使用以下命令：
select * from sys.time_zone_info
• 要验证是否已迁移全部 entry_ids，请使用与以下代码段类似的 SQL 查询：
select dt.entry_id, dtb.entry_id from [thingworx].[twschema].[data_table_backup] dtb full join [thingworx].[twschema].[data_table] dt on dtb.entry_id = dt.entry_id where dtb.entry_id is null or dt.entry_id is null
G.) 更新架构和迁移数据 (仅适用于 Azure SQL) 
* 
所有升级均需且仅需本部分中的步骤 1。
如果是 ThingWorx 8.4.x 或 8.5.x --> 9.0.x、9.1.x 或 9.2.x 版本的升级，请执行本部分中的其余步骤。
如果是 ThingWorx 9.0.x 或 9.1.x --> 9.1.x 或 9.2.x 版本的升级，请跳过本部分中的其余步骤。
1. 运行位于 ThingWorx 软件下载的 update 文件夹中的以下脚本 (从要升级的版本开始)：
* 
平台中存在的权限数量可能会影响完成升级所用的时间。较多的权限可能会增加完成升级所用的时间。
thingworxAzureSchemaUpdate8.4-to-8.5.sh
thingworxAzureSchemaUpdate8.5-to-9.0.sh
thingworxAzureSchemaUpdate9.1-to-9.2.sh
* 
无需运行 thingworxAzureSchemaUpdate9.0-to-9.1.sh 脚本，因为 9.1 中不存在架构更新。虽然出于完整性目的，update 文件夹中包含了脚本，但该脚本却为空脚本且仅适用于执行自动升级过程的用户。
* 
用法：
./thingworxAzureSchemaUpdate8.4-to-8.5.sh -d ^database^ -h ^server^ -l ^username^ [-i ^serverInstance^] [-p ^port^] [-o ^option^]
示例：
./thingworxAzureSchemaUpdate8.4-to-8.5.sh -d thingworx -h test.sqldatabase.net -l sqlAdmin
2. 运行大整数/时区设置脚本以准备要迁移的数据库：
* 
如果已使用 UTC 运行 ThingWorx，则对于大整数更改，仍需运行迁移，但可同时为 sourceTZ 和 targetTZ 参数 (在以下步骤中的某些脚本中可用) 提供 UTC 值。
thingworxAzureDBSetupBigIntTimezoneDataUpdate.sh
3. 运行模型迁移脚本以迁移所有模型数据：
* 
在运行脚本前，请在文本编辑器中打开脚本，以确保其默认环境值 (例如服务器、端口、时区等) 均正确无误且满足当前环境。如果脚本内定义的任何默认值不适用于当前环境，请通过指定一个或多个命令行自变量来覆盖运行脚本时的默认值。
thingworxAzureModelTablesDataUpdate.sh
* 
用法：
thingworxAzureModelTablesDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]
示例：
thingworxAzureModelTablesDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000
4. 运行以下各个架构迁移脚本，以创建所有数据表数据、流数据和值流数据的备份表：
* 
出于性能方面的原因，这些脚本实际上不会在这些表中创建原始数据的副本。相反，这些脚本会将这些现有的表从 "<original-table-name>" 重命名为 "<original-table-name>_backup"。由此可避免执行实际复制数据的过程，因为这一过程可能会比较耗时。对这些现有的表 (进而成为备份表) 进行重命名后，即会以原始名称创建新表。这些新表为空，并且与原始表具有相同的作用 (因为它们的名称与原始表相同)。这些新表将在后面的步骤中用迁移数据进行填充。
* 
执行下面的数据表脚本时，将显示以下预期警告：Warning! The maximum key length for a clustered index is 900 bytes. The index 'data_table_indexes_pkey' has maximum length of 902 bytes. For some combination of large values, the insert/update operation will fail.
thingworxAzureDataTableSchemaUpdate.sh
thingworxAzureStreamSchemaUpdate.sh
thingworxAzureValueStreamSchemaUpdate.sh
5. 打开新的命令提示符窗口并运行以下数据迁移脚本，以迁移备份表中的数据表数据：
* 
在运行脚本前，请在文本编辑器中打开脚本，以确保其默认环境值 (例如服务器、端口、时区等) 均正确无误且满足当前环境。如果脚本内定义的任何默认值不适用于当前环境，请通过指定一个或多个命令行自变量来覆盖运行脚本时的默认值。
thingworxAzureDataTableDataUpdate.sh
* 
用法：
thingworxAzureDataTableDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]
示例：
thingworxAzureDataTableDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000
启动此迁移脚本后，请等待，直到控制台上显示一条消息，指示可以安全地重新启动 Tomcat。显示该消息后，可以安全地继续执行下一步，即使此迁移脚本尚未执行完毕也是如此。
6. 打开新的命令提示符窗口并运行以下数据迁移脚本，以迁移备份表中的流数据和值流数据：
* 
在运行脚本前，请在文本编辑器中打开脚本，以确保其默认环境值 (例如服务器、端口、时区等) 均正确无误且满足当前环境。如果脚本内定义的任何默认值不适用于当前环境，请通过指定一个或多个命令行自变量来覆盖运行脚本时的默认值。
thingworxAzureStreamDataUpdate.sh
thingworxAzureValueStreamDataUpdate.sh
* 
用法：
thingworxAzureStreamDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]
thingworxAzureValueStreamDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]
示例：
thingworxAzureStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000
thingworxAzureValueStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000
启动这两个迁移脚本后，请不要继续执行下一步操作，直到这些迁移脚本以及数据表迁移脚本 (在上一步中开始运行) 已成功完成运行。
7. 手动验证以下脚本是否已全部成功完成运行：thingworxAzureDataTableDataUpdate.sh、 thingworxAzureStreamDataUpdate.sh 和 thingworxAzureValueStreamDataUpdate.sh。验证是否已成功迁移所有数据表数据、流数据和值流数据。
8. 运行清理脚本以移除迁移过程中所需的任何临时数据库对象：
* 
尽管此脚本确实会对升级过程中创建的临时数据库对象执行一些清理操作，但此脚本并*不*会删除在上述步骤中创建的任何备份表，也不会修改这些备份表中的任何数据。此行为是有意而为之的，可确保数据不会遭到意外删除。如果要删除这些备份表，则必须手动将其删除。
thingworxAzureDBCleanupBigIntTimezoneDataUpdate.sh
H.) 升级至 Java 11 
* 
Java 11 对于 ThingWorx 9.2.0 及更高版本而言必不可少。有关详细信息，请参阅系统要求。
1. 若要升级至 Java 11，则需执行以下步骤。如果已安装了 Java 11，请跳过此部分。
a. 下载 OpenJDK 或 Java 11。
b. 在 Linux 上安装 jEnv：
i. Git 复制 jEnv 信息库：
git clone https://github.com/jenv/jenv.git ~/.jenv
ii. 将 jEnv 添加至 $PATH：
echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.bash_profile
iii. 初始化 jEnv：
echo 'eval "$(jenv init -)"' >> ~/.bash_profile
iv. 更新于 ~/.bash_profile 中所作的更改：
source ~/.bash_profile
v. 设置 JAVA_HOME 环境变量：
jenv enable-plugin export
vi. 重新启动当前 shell 壳会话：
exec $SHELL -l
vii. 运行以下命令后，JAVA_HOME 变量将由 jEnv 自动设置，具体取决于当前使用的 Java 环境：
jenv doctor
c. 添加 Java 环境：
i. 添加任意环境。所有 Java 安装均位于 /usr/lib/jvm/ 中。使用 jenv add 命令。以下示例：
jenv add /usr/lib/jvm/java-11-amazon-corretto
jenv add /usr/lib/jvm/jdk-11.0.7
ii. 检查 jenv 的所有可用 Java 版本：
jenv versions
iii. 设置全局 Java 环境：
jenv global <version>
iv. 设置特定于壳的 Java 环境：
jenv shell <version>
v. 验证由 jenv 设置的当前版本：
jenv versions
vi. 更新 Tomcat Java 设置中的路径。
I.) 部署 ThingWorx.war 文件并重新启动 
1. 复制新的 Thingworx.war 文件，然后将其置于以下 Tomcat 安装位置：/Apache Software Foundation/Tomcat x.x/webapps。
2. 启用扩展导入。默认情况下，所有用户的扩展导入均处于禁用状态。将以下内容添加至 platform-settings.json 文件。添加下列 ExtensionPackageImportPolicy 参数或将其更新为 true，以允许导入扩展。
"ExtensionPackageImportPolicy": {
"importEnabled": <true or false>,
"allowJarResources": <true or false>,
"allowJavascriptResources": <true or false>,
"allowCSSResources": <true or false>,
"allowJSONResources": <true or false>,
"allowWebAppResources": <true or false>,
"allowEntities": <true or false>,
"allowExtensibleEntities": <true or false>
},
3. 如果使用 H2 作为 ThingWorx 的数据库，则必须将用户名和密码添加到 platform-settings.json 文件中。
},
"PersistenceProviderPackageConfigs":{
"H2PersistenceProviderPackage":{
"ConnectionInformation":
{
"password": "<changeme>",
"username": "twadmin"
}
},
4. 启动 Tomcat。
5. 要恢复 SSO 配置：
a. 从备份 web.xml 文件中复制 SSOSecurityContextFilter 块。
b. 在新创建的 web.xml 文件中，将 SSOSecurityContextFilter 块粘贴到最后一个 AuthenticationFilter 块的后面。
6. 要启动 ThingWorx，请在 Web 浏览器中转至 <servername>\Thingworx。使用以下登录信息：
◦ 登录名：Administrator
◦ 密码：<源服务器管理员密码>
J.) 导入流和值流数据 (仅适用于 InfluxDB) 
* 
仅在使用 InfluxDB 1.7.x (用于 ThingWorx 8.5.x 或 9.0.x) 至 InfluxDB 1.8.x (用于 ThingWorx 9.1.x 或 9.2.x) 升级 ThingWorx 时需要此部分中的步骤。
1. 为 InfluxDB 1.8.x 创建新的持久化方案提供工具，或为现有 1.7.x 持久化方案提供工具提供新的连接信息。
2. 将流数据和值流数据导入到服务器。针对流数据和值流数据执行以下步骤。
a. 以管理员身份登录到 ThingWorx 9.x。
b. 单击“导入/导出”>“导入”。
c. 使用下列选项：
i. 对于“导入选项”，请选择“自文件”。
ii. 对于“导入类型”，请选择“数据”。
iii. 对于“导入源”，请选择“文件信息库”。
iv. 对于“文件信息库”，请选择“系统”。
v. 对于“路径”，请提供一个有效的系统信息库路径。
K.) 升级其他组件 
• 如果要使用“集成连接器”，则必须获取并安装最新版本的 Integration Runtime。有关详细信息，请参阅集成连接器的集成运行时服务的初始设置。
• 如果要升级 MSSQL JDBC 驱动程序，请验证系统要求并参阅针对 MSSQL 配置 ThingWorx 以查找相应的驱动程序。
• 如果从 8.x 升级至 9.x 且具有 Java 扩展，则请参阅将 Java 扩展从 8.x 迁移至 9.x。
• 如果将 ThingWorx Analytics 用作解决方案的一部分，则可以使用两个安装程序来处理组件升级：
◦ Analytics Server - 安装或升级 Analytics Server 和 Analytics Extension
◦ Platform Analytics - 安装或升级 Descriptive Analytics 和 Property Transforms
有关升级过程的详细信息，请参阅升级、修改和修复 ThingWorx Analytics
H.) 运行 9.2+ 的清理脚本 
如果要升级至 ThingWorx 9.2 或更高版本，则必须运行清理脚本以移除在升级过程中创建的临时表格。
运行 thingworx<database_name>DBCleanupPermissionTempTableUpdate.sh，清理位于 <installDir>/schema/update 中的脚本。
脚本需用到参数，例如：
-h <server>
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
系统将提示您输入数据库用户密码，该密码通过 -u 或 -l 参数传递。
M.) 故障排除 
• 如果由于自定义索引字段缺少值而导致升级失败，则必须再次部署较旧版本 (如果进行了架构更新，则必须回滚/恢复数据库)，并添加缺失的索引值或从数据表中移除自定义索引，然后再执行升级。
启动 ThingWorx 平台后，检查平台的应用程序日志。如果您使用的是 MSSQL、PostgreSQL 或 H2，则系统可能会显示以下属性冲突错误消息。
故障排除错误
应用程序日志错误
解决方案
Error in copying permissions: Problems migrating database
除 MSSQL 升级时会显示此迁移错误外，当存在任何已配置运行时权限且名称包含超过 256 个字符的已迁移服务、属性或事件名称时，也会显示此错误。要修复此错误，请将所有服务、属性和事件名称限制为 256 个字符以下。
[L: ERROR] [O: c.t.p.m.BaseReportingMigrator] [I: ] [U: SuperUser] [S: ]
[T: localhost-startStop-1] Thing: <Name of Thing>, has a property which conflicts
with one of the following system properties: isReporting,reportingLastChange,reportingLastEvaluation.
Please refer to the ThingWorx Platform 8.4 documentation on how to resolve this problem.
作为添加到 ThingWorx Platform 8.4 中的“事物状态”功能的一部分，以下属性之前已添加到可报告事物形态中，且用于对实现此形态的事物进行状态评估：
• isReporting
• reportingLastChange
• reportingLastEvaluation
如果事物、事物模板或事物形态中已存在上述属性名称之一，则在启动此平台时，应用程序日志中将出现以下错误。要解决此问题，必须移除每个受影响实体中发生冲突的属性，并更新任何关联的实体 (例如“混搭”或“服务”) 以适应此更改。如果没有此更新，则关联的事物无法正确显示其报告状态，也无法进行更新/保存。正确更新这些实体后，系统会显示平台特定的报告属性，并将其用于评估设备是否已连接并实现通信。
[L: ERROR] [O: c.t.p.m.BaseReportingMigrator] [I: ] [U: SuperUser]
[S: ] [T: localhost-startStop-1] ThingTempate: <Name of ThingTemplate>, has a
property which conflicts with one of the following system properties:
isReporting,reportingLastChange,reportingLastEvaluation.
Please refer to the ThingWorx Platform 8.4 documentation on how to resolve this problem.
[L: ERROR] [O: c.t.p.m.BaseReportingMigrator]
[I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] ThingShape:
<Name of ThingShape>, has a property which conflicts with one of the following system properties:
isReporting,reportingLastChange,reportingLastEvaluation. Please refer to the ThingWorx Platform
8.4 documentation on how to resolve this problem.
这对您有帮助吗?