连接器故障排除¶

本主题提供了排查 Snowflake Connector for ServiceNow®V2 问题的指南。

本主题内容：

备注

以下部分介绍了存储过程，这些过程是在连接器数据库的 PUBLIC 架构中定义的。在调用这些存储过程之前，选择该数据库作为会话使用的数据库。

例如，如果该数据库名为 my_connector_servicenow，请运行以下命令：

USE DATABASE my_connector_servicenow;

Copy

验证与 ServiceNow® 实例的连接¶

要验证 Snowflake Connector for ServiceNow®V2 能否访问 ServiceNow® 实例，请调用 TEST_CONNECTION 存储过程，该过程在连接器数据库的 PUBLIC 架构中定义：

CALL TEST_CONNECTION();

Copy

如果连接器设置正确，存储过程将返回以下响应：

{
  "responseCode": "OK",
  "message": "Test request to ServiceNow® succeeded."
}

Copy

例如，如果连接器的数据库名为 my_connector_servicenow，并且您希望验证与 ServiceNow® 实例的连接，请运行以下命令：

USE DATABASE my_connector_servicenow;
CALL TEST_CONNECTION();

Copy

验证对 ServiceNow® 实例中特定表的访问权限¶

要验证 Snowflake Connector for ServiceNow®V2 能否访问 ServiceNow® 实例中特定表中的数据，请调用 TEST_TABLE_ACCESS 存储过程，该过程在连接器数据库的 PUBLIC 架构中定义：

CALL TEST_TABLE_ACCESS('<table_name>');

Copy

其中：

table_name: 指定 ServiceNow® 实例中的表的名称。

如果连接器设置正确，并且数据可供连接器使用的用户使用，则存储过程将返回以下响应：

{
  "responseCode": "OK",
  "message": "Test request to ServiceNow® succeeded."
}

Copy

备注

如果表为空，或者由于 ACLs，所有行都对连接器隐藏，则消息将显示为：Test request to ServiceNow® succeeded but it didn't return any record. 在这种情况下，请确保表确实为空。如果从 UI 中可以看到任何行，则意味着连接器无法引入它们。

比较 ServiceNow® 和 Snowflake 中的表行数¶

要比较 ServiceNow® 和 Snowflake 中某个表的当前行数，请调用 CHECK_ROW_COUNT 过程：

CALL CHECK_ROW_COUNT('<table_name>');

Copy

或

CALL CHECK_ROW_COUNT('<table_name>', <max_sys_created_on>);

Copy

其中：

table_name: 指定 ServiceNow® 实例中的表的名称。
max_sys_created_on: 对 sys_created_on 列的最大值指定其他可选的筛选器。只有与此筛选器匹配的行才会被计算在内。此参数的默认值为 NULL，意味着此时不会应用筛选器。此参数有助于仅比较已引入到 Snowflake 中的记录计数，而不考虑最近创建于 ServiceNow® 中但尚未引入到 Snowflake 的记录。

如果过程超时，则过程无法使用 stats API 确定 ServiceNow® 中表的行数。这可能意味着，该表中的行数太多而无法通过此 API 统计。

备注

返回的行数可能会有所不同。ServiceNow® 表包含的行可能比同等的 Snowflake 表更多。这可能是由为 ServiceNow® 中的指定表设置的访问控制列表规则 (ACLs) 导致的。

连接器使用不同的端点来检索有关 ServiceNow® 表中的行数的信息。连接器使用 stats 获取有关表的信息，包括行数。它用 table 将数据引入 Snowflake。

检查行的引入状态¶

要在 ServiceNow® 和 Snowflake 中的所有可能位置查看行的引入状态，请调用 CHECK_RECORD_HISTORY 过程：

CALL CHECK_RECORD_HISTORY('<table_name>', '<sys_id>');

Copy

其中：

table_name: 指定 ServiceNow® 实例中的表的名称。
sys_id: 指定要检查的行的 sys_id。

该过程会返回一个包含以下属性的 JSON 对象：

属性	描述
`table_name`	表的名称。
`sys_id`	ServiceNow® 中行的唯一标识符。
`status`	行的引入状态。
`is_present_in_servicenow`	如果该行存在于 ServiceNow® 中的表中，则为 `true`；否则为 `false`。
`is_present_in_servicenow_audit_table`	如果在 ServiceNow® 中的审计表中跟踪该行，则为 `true`；否则为 `false`。
`is_present_in_snowflake_destination_table`	如果行已引入且在 Snowflake 中的 `dest_db` 数据库中可用，则为 `true` ；否则为 `false`。
`event_log_records`	代表事件日志中的条目（具有此 `sys_id` 的行的事件日志）的 JSON 对象数组。每个对象均包含以下属性，这些属性对应于事件日志表中指定数据更改时间戳和事件类型的列： `sys_updated_on` `event_date` `event_type`

确定表是否经过了删除审计¶

Snowflake Connector for ServiceNow®V2 依靠审计将记录删除操作传播到 Snowflake。

要验证 ServiceNow® 中的给定表是否配置为审计记录删除操作，请调用 CHECK_IF_AUDIT_ENABLED 存储过程：

CALL CHECK_IF_AUDIT_ENABLED('<table_name>');

Copy

其中：

table_name: 指定 ServiceNow® 实例中的表的名称。

该存储过程会检查指定表的 audit 和 no_audit_delete 配置，并显示出有关是否已启用审计的信息。

获取故障排除数据¶

要获取故障排除数据，请调用 GET_TROUBLESHOOTING_DATA 存储过程：

CALL GET_TROUBLESHOOTING_DATA(<from_timestamp>, <to_timestamp>);

Copy

其中：

from_timestamp: 指定应提取数据的日期范围起始点（UTC 时区）。
to_timestamp: 指定应提取数据的日期范围结束点（UTC 时区）。

此存储过程会以表格格式返回以下数据：

配置信息
连接器遇到的错误
引入历史记录

以下示例展示了如何调用此存储过程：

USE DATABASE my_connector_servicenow;
  CALL GET_TROUBLESHOOTING_DATA('2024-02-05 10:00:00', '2024-02-10 22:30:00');

Copy

您可以将返回的数据以 CSV 格式保存，并发送给 Snowflake 支持部门 (https://community.snowflake.com/s/article/How-To-Submit-a-Support-Case-in-Snowflake-Lodge)。

恢复无法访问的对象¶

连接器需要连接器数据库外部的多个数据库对象。如果这些对象不可用，连接器将出现故障或停止正常运行。对象可能不可用的情况包括：

删除对象。
重新创建对象而不保留或恢复所需的授权。
撤销连接器使用这些对象所需的授权。

在大多数情况下，您可以通过重新创建这些对象并授予必要的权限来手动恢复这些对象。以下部分介绍了如何恢复不同的对象。

恢复连接器仓库¶

如果连接器失去对其仓库的访问权限，请通过调用 UPDATE_WAREHOUSE 存储过程来配置新仓库。

恢复 ServiceNow® 数据的数据库和架构¶

如果 ServiceNow® 数据的数据库或架构被删除，则唯一的恢复方法是运行 UNDROP 命令。如果此命令不可用，则您必须重新安装连接器并再次引入 ServiceNow® 数据。

如果包含 ServiceNow® 数据的视图被删除，它应该会在下次负责创建它们的后台任务运行时自动重新创建。

如果包含 ServiceNow® 数据的其中一个表（事件日志或原始数据表）被删除，您无法使用 UNDROP TABLE 命令来恢复它，请执行以下操作来开始再次引入 ServiceNow 表：

确保为此 ServiceNow® 表删除事件日志和原始数据表。
禁用 ServiceNow® 表。
使用 DELETE_TABLE 过程。
启用 ServiceNow® 表。

恢复连接器的通知集成¶

如果连接器失去通知集成对象的访问权限，请再次执行配置警报过程，并根据需要重新创建通知集成对象。

如果电子邮件通知是通过 Snowsight 配置的，那么您只需禁用并重新启用它们，即可恢复必要的外部对象。