连接器故障排除¶
Snowflake Connector for ServiceNow® 受 Connector 条款 的约束。
本主题提供了排查 Snowflake Connector for ServiceNow® 问题的指南。
本主题内容:
备注
以下部分介绍了存储过程,这些过程是在 连接器数据库 的 PUBLIC 架构中定义的。在调用这些存储过程之前,选择该数据库作为会话使用的数据库。
例如,如果该数据库名为 my_connector_servicenow
,请运行以下命令:
USE DATABASE my_connector_servicenow;
验证与 ServiceNow 实例的连接¶
要验证 Snowflake Connector for ServiceNow® 能否访问 ServiceNow 实例,请调用 TEST_SN_CONNECTION
存储过程,该过程在 连接器数据库 的 PUBLIC 架构中定义:
CALL TEST_SN_CONNECTION('<table_name>');
其中:
table_name
指定 ServiceNow 实例中的表的名称。
如果连接器设置正确,存储过程将返回指定表中的一行。
例如,如果您的连接器的数据库名为 my_connector_servicenow
,并且您希望通过从 ServiceNow 实例中名为 my_table
的表中检索行来验证连接,请运行以下命令:
USE DATABASE my_connector_servicenow;
CALL TEST_SN_CONNECTION('my_table');
比较 ServiceNow 和 Snowflake 中的表行数¶
要比较 ServiceNow 和 Snowflake 中某个表的当前行数,请调用 CHECK_SN_ROW_COUNT
过程:
CALL CHECK_SN_ROW_COUNT('<table_name>');
其中:
table_name
指定 ServiceNow 实例中的表的名称。
如果过程超时,则过程无法使用 stats
API 确定 ServiceNow 中表的行数。这可能意味着,该表中的行数太多而无法通过此 API 统计。
备注
返回的行数可能会有所不同。ServiceNow 表包含的行可能比同等的 Snowflake 表更多。这可能是由为 ServiceNow 中的指定表设置的访问控制列表规则 (ACLs) 导致的。
为表配置 数据范围开始时间 时,返回的行数可能会有所不同。ServiceNow 行数仍代表所有行的数量,而根据配置,只有有限数量的行会被引入 Snowflake。
连接器使用不同的端点来检索有关 ServiceNow 表中的行数的信息。连接器使用 stats
获取有关表的信息,包括行数。它用 table
将数据引入 Snowflake。
检查行的引入状态¶
要在 ServiceNow 和 Snowflake 中的所有可能位置查看行的引入状态,请调用 CHECK_RECORD_HISTORY
过程:
CALL CHECK_RECORD_HISTORY('<table_name>', '<sys_id>');
其中:
table_name
指定 ServiceNow 实例中的表的名称。
sys_id
指定要检查的行的
sys_id
。
该过程会返回一个包含以下属性的 JSON 对象:
属性 |
描述 |
---|---|
|
表的名称。 |
|
ServiceNow 中行的唯一标识符。 |
|
行的引入状态。 |
|
如果该行存在于 ServiceNow 中的表中,则为 |
|
如果在 ServiceNow 中的审计表中跟踪行,则为 |
|
如果行已引入且在 Snowflake 中的 |
|
代表 事件日志中的条目 <label-servicenow_connector_accessing_data_event_logs>`(具有此 :code:`sys_id 的行的事件日志)的 JSON 对象数组。 每个对象均包含以下属性,这些属性对应于事件日志表中指定数据更改时间戳和事件类型的列:
|
确定表是否经过了删除审计¶
Snowflake Connector for ServiceNow® 依靠审计将记录删除操作传播到 Snowflake。
要验证 ServiceNow 中的给定表是否配置为审计记录删除操作,请调用 CHECK_IF_AUDIT_ENABLED
存储过程:
CALL CHECK_IF_AUDIT_ENABLED('<table_name>');
其中:
table_name
指定 ServiceNow 实例中的表的名称。
该存储过程会检查指定表的 audit
和 no_audit_delete
配置,并显示出有关是否已启用审计的信息。
获取故障排除数据¶
要获取故障排除数据,请调用 GET_TROUBLESHOOTING_DATA
存储过程:
CALL GET_TROUBLESHOOTING_DATA(<number_of_days>);
其中:
number_of_days
指定应提取过去数据的天数。
此存储过程会以表格格式返回以下数据:
配置信息
连接器遇到的错误
引入历史记录
以下示例展示了如何调用此存储过程:
USE DATABASE my_connector_servicenow;
CALL GET_TROUBLESHOOTING_DATA(1);
您可以将返回的数据以 CSV 格式保存,并发送给 Snowflake 支持部门 (https://community.snowflake.com/s/article/How-To-Submit-a-Support-Case-in-Snowflake-Lodge)。
测试与 ServiceNow 之间的连接¶
要验证连接器能否访问 ServiceNow 实例,请调用 GET_CONNECTION_STATUS
存储过程。
此存储过程会检查设置过程中提供的密钥中所存储的连接和凭据。它会返回一个带有两个键的变体:
status
details
以下示例说明了如何调用 GET_CONNECTION_STATUS
存储过程:
USE DATABASE my_connector_servicenow;
CALL GET_CONNECTION_STATUS();
恢复无法访问的对象¶
连接器需要连接器数据库外部的多个数据库对象。如果这些对象不可用,连接器将出现故障或停止正常运行。对象可能不可用的情况包括:
删除对象。
重新创建对象而不保留或恢复所需的授权。
撤销连接器使用这些对象所需的授权。
在大多数情况下,您可以通过重新创建这些对象并授予必要的权限来手动恢复这些对象。以下部分介绍了如何恢复不同的对象。
恢复连接器仓库¶
如果连接器失去对其仓库的访问权限,请通过调用 CONFIGURE_WAREHOUSE 存储过程来配置新仓库。
恢复连接器密钥对象¶
如果连接器使用的 密钥对象 被删除,您必须在同一数据库和架构中使用相同的名称重新创建密钥。
要查看密钥的完全限定名称,请运行以下命令:
SELECT value:secret FROM GLOBAL_CONFIG WHERE key = 'connection_config';
此外,您必须为 连接器使用的自定义角色 授予对重新创建的密钥的 USAGE 权限。
如果密钥对象的数据库或架构被删除,您可以通过运行 UNDROP 命令来将其恢复。此命令还可以恢复密钥对象。
如果您无法使用 UNDROP
命令,那么您必须使用相同的名称重新创建数据库和架构。 您还必须为 连接器使用的自定义角色 授予对数据库和架构的 USAGE 权限。
恢复 API 集成¶
如果连接器使用的 API 集成 被删除,您必须使用相同的名称重新创建该集成。要查看连接器所需的 API 集成的名称,请运行以下命令:
SELECT value:apiIntegrationName FROM GLOBAL_CONFIG WHERE key = 'connection_config';
重新创建 API 集成时,请务必使用与之前相同的完全限定密钥名称和 ServiceNow 实例 URL。
要确定密钥的完全限定名称,请运行以下命令:
SELECT value:secret FROM GLOBAL_CONFIG WHERE key = 'connection_config';
要确定 ServiceNow 实例 URL,请运行以下命令:
SELECT value:serviceNowUrl FROM GLOBAL_CONFIG WHERE key = 'connection_config';
您还必须为 连接器使用的自定义角色 授予对重新创建的 API 集成的 USAGE 权限。
恢复 ServiceNow 数据的数据库和架构¶
如果 ServiceNow 数据的数据库或架构 被删除,则唯一的恢复方法是运行 UNDROP 命令。如果此命令不可用,则您必须重新安装连接器并再次引入 ServiceNow 数据。
如果 包含 ServiceNow 数据的视图 被删除,它应该会在下次负责创建它们的后台任务运行时自动重新创建。
如果包含 ServiceNow 数据的其中一个表( 事件日志 或 原始数据 表)被删除,您无法使用 UNDROP TABLE 命令来恢复它,请执行以下操作来开始再次引入 ServiceNow 表:
确保为此 ServiceNow 表删除事件日志和原始数据表。
使用 DELETE_TABLE 过程。
恢复连接器的自定义角色¶
如果删除了 连接器使用的自定义角色,您必须使用相同的名称重新创建。要确定连接器所需的角色的名称,请运行以下查询:
SELECT value FROM GLOBAL_CONFIG WHERE key = 'data_owner_role';
您还必须为该角色恢复列出的权限。您可以通过 GLOBAL_CONFIG 视图确定相应对象的名称。
此外,角色必须拥有包含 相应架构 中的 ServiceNow 数据的所有表和视图的所有权。
如果没有在此架构中手动创建其他表或视图,您可以通过运行 GRANT OWNERSHIP ON ALL TABLES/VIEWS IN SCHEMA ... TO ROLE ...
命令来恢复角色。
例如,如果 ServiceNow 数据存储在数据库 dest_db
和架构 dest_schema
中,要恢复名为 connector_resources_provider
的角色,请运行以下命令:
GRANT OWNERSHIP ON ALL TABLES IN SCHEMA dest_db.dest_schema TO ROLE connector_resources_provider;
GRANT OWNERSHIP ON ALL VIEWS IN SCHEMA dest_db.dest_schema TO ROLE connector_resources_provider;
还必须将重新创建的角色授予连接器数据库。例如,要为名为 connector_resources_provider
的角色授予数据库 my_connector_servicenow
,请运行以下命令:
GRANT ROLE connector_resources_provider TO DATABASE my_connector_servicenow;
恢复连接器的通知集成¶
如果连接器失去通知集成对象的访问权限,请再次执行 配置警报 过程,并根据需要重新创建通知集成对象。
如果电子邮件通知是通过 Snowsight 配置的,那么您只需禁用并重新启用它们,即可恢复必要的外部对象。