优化性能是一项关键的管理活动。本主题概述了 可用于帮助提高性能的工具和资源 数据库。
监视有关 SAP HANA 数据库性能的过去和当前信息 对于防止性能问题和分析问题的根本原因非常重要。 一些可用于监控、分析和优化的关键工具和资源 这里介绍性能。
监测
SAP HANA 主控室和 SAP HANA Studio 都提供监控工具;这 SAP HANA 主控室的性能监视器对于分析特别有用 因为它并排显示系统性能和 当前正在应用的工作负载。
缓存
缓存在SAP HANA中被广泛使用，作为一种提高性能的策略 重用查询的数据，而不是每次都重新读取和处理数据 这是请求的。查询结果缓存用于缓存数据和 Plan 缓存可用于查询优化，通过存储 经常执行的 SQL 语句。
提示
提示是针对 SAP HANA 数据库服务器的说明，它会影响 处理数据库请求。它们通常用于优化 SAP HANA 性能或内存消耗，并且对 请求。SAP HANA提供用于各种用途的预定义提示，您可以 还可以创建用户定义的提示并将其应用于 Select 语句。
捕获和回放
借助 SAP HANA 捕获和重放，您可以捕获生产的工作负载 系统，并在目标系统上重放捕获的工作负载。这可以帮助您 评估更改后对性能或稳定性的潜在影响 硬件或软件配置。
SQL 计划稳定性
SQL 计划稳定性是一项通过捕获查询来保护查询性能的功能 在源系统中执行计划，并在目标系统中重用它们，以： 重新生成原始查询计划。这通常在系统之后使用 升级以保证新系统中查询的性能。计划 稳定性可以在 SAP HANA 驾驶舱中管理，也可以从命令行管理，如 SAP HANA 故障排除和性能分析中所述 指南。
管理带宽
为了帮助管理员管理带宽，一组配置参数是 可用于管理 HANA 文件输入/输出层，以平衡 不同设备和通道的吞吐量。这些参数可以应用于 特定使用类型，例如数据量、日志文件、备份。
缓存
有许多选项可用于使用缓存来提高性能。
缓存在 SAP HANA 中被广泛使用，作为一种通过重用查询来提高性能的策略 数据，而不是在每次请求数据时都重新读取和处理数据。 查询结果缓存用于缓存数据和计划缓存（请参阅以下内容） topic） 可用于通过存储 频繁 的执行计划进行查询优化 执行的 SQL 语句。
查询结果缓存适用于列存储表和视图，以及 在数据 主要是阅读;这是因为对基表的更新会使此类型失效 的缓存。此缓存的配置选项包括定义最大内存 缓存的预算，并定义缓存到的允许表或视图的列表 已应用。SAP 说明2014148指南中对此进行了详细描述 使用查询结果缓存。
静态结果缓存（有时称为缓存 views）和动态结果缓存是进一步的应用 的缓存。静态结果缓存是为特定视图创建的，并保持有效 在用户定义的保留期内。动态结果缓存为 类似但没有保留期;它保证了交易性 通过维护应用于基础的所有更改的增量记录来保持一致性 桌子。可以在 SAP 中找到静态和动态结果缓存的详细信息 HANA 故障排除和性能分析指南。
SAP HANA 主控室和 SAP HANA Studio 都具有管理和监控功能 缓存活动。
缓存大小
总体缓存大小由资源管理器控制。缓存可能不受严格限制 大小，但会根据可用内存按需增长。对象是 根据其可交换处置自动从缓存中卸载，并且 最近最少的使用值。但是，您可以定义上限和下限 使用 global.ini 文件的 MemoryObjects 部分中的一组配置参数的全局缓存大小。您可以设置 值可以作为绝对字节数或可用字节的百分比 内存（例如：global_cache_upper_limit_abs、global_cache_lower_limit_rel）。百分比值为 根据全局分配限值 （GAL） 或进程计算 分配限制 （PAL），以较小的值为准（即：单位：% MIN（GAL， PAL））。请参阅 SAP HANA 中的参数说明 有关详细信息，请参阅配置参数参考。
所有缓存的详细信息，包括大小和命中计数，可在 （可重置）监视视图M_CACHES其中每个缓存都可以通过 独特的CACHE_ID价值。SAP 中还提供了有关缓存的更多信息 注释 2502256 - 常见问题解答：SAP HANA 缓存。
计划缓存
计划缓存存储经常执行的 SQL 语句的执行计划，以便可以重用这些语句，而不必在每次运行语句时重新编译计划。管理员还可以使用计划缓存进行性能分析，以大致了解系统中执行的语句。
为管理员规划缓存
对于管理员来说，SQL 计划缓存对于监视整体 SQL 性能很有用，因为它 提供有关已编译查询的统计信息，例如执行次数、运行时 详细信息和锁定/等待统计信息。您可以使用此信息深入了解 经常执行的查询和慢速查询，并确定潜在的候选者 优化。
可以通过单击“顶部 SQL”在 SAP HANA 主控室中查看计划缓存 资源数据库中的对帐单卡 概述;然后，在“监视语句”屏幕上，选择“SQL 计划缓存”页。看 cockpit 文档（使用 SQL 计划监视和分析语句） 缓存）了解更多信息。
急切的驱逐
SQL 语句在需要时会保留在计划缓存中，但 从缓存中逐出的值很少。驱逐由以下人员自动进行 默认值，但如果您希望更仔细地管理此操作（或关闭逐出 完全）的配置设置可用于根据 使用频率或更平衡的有用性分数，这是自动的 计算。此配置参数位于 indexserver.ini 文件的 [SQL] 部分。
若要管理逐出，必须首先通过更改其默认值来激活 plan_cache_eager_eviction_mode 参数 （自动）更改为“自定义”。
默认情况下，不会使用超过两天的缓存计划会自动逐出。您可以更改此保留期，还可以更改扫描旧计划的计划缓存的频率。
| 保留期参数 | 违约 | 用法 |
|---|---|---|
| plan_cache_eager_eviction_mode | 自动 | 如果您希望更改默认逐出设置，请将其设置为“自定义”。将其设置为“关闭” 禁用计划缓存急切逐出。 |
| plan_cache_eager_eviction_time_based_retention_time | 2160 | 设置基于时间的逐出的最短保留期（以分钟为单位）。 将此值设置为负数将禁用此功能。 |
| plan_cache_eager_eviction_time_based_scan_period | 180 | 设置基于时间的逐出频率（以分钟为单位） 发生。 |
对于基于分数的逐出，计划缓存会定期为每个计划分配一个分数进行评估 它基于一系列标准，例如：执行频率、自上次以来的时间 执行。
可以配置基于分数的逐出，以逐出一定比例的低分数计划。默认情况下，每次运行缓存扫描时，都会逐出底部 10% 的计划。
| 基于分数的逐出的参数 | 违约 | 用法 |
|---|---|---|
| plan_cache_eager_eviction_score_based_rate | 3 | 设置要逐出的低分数计划的百分比。将此设置为 负数禁用此功能。 |
| plan_cache_eager_eviction_score_based_scan_period | 60 | 设置基于分数的逐出频率（以分钟为单位） 发生。 |
选择性删除计划缓存条目
在某些情况下，可能需要清除计划缓存，这可能是 例如，如果问题是由无效条目引起的，则这是必需的。一种选择是 使用以下 CLEAR 语句完全清除计划缓存：
但是，这需要时间，并且会产生相当大的性能开销 之后，因为所有 SQL 语句都必须从头开始解析和重新编译。 提高计划缓存质量的更好方法是删除单个 有选择地计划。您可以使用此处显示的 REMOVE 语句执行此操作，任如下所示： 标识特定计划编号或使用 WHERE 子句：
例如，以下命令2374637从 SQL 计划缓存：
WHERE 子句在M_SQL_PLAN_CACHE监视视图上操作 其中包含 90 多列。因此，此选项提供了许多可能性 用于从缓存中删除特定项目，同时对以下方面产生最小的负面影响 性能。以下示例说明了这一点;所有符合条件的计划 从缓存中删除：
本示例删除不常用的条目：
本示例删除无效的条目：
此示例删除查询特定表的条目：
对于 REMOVE 和 CLEAR 语句，都需要 OPTIMIZER ADMIN 权限。有关语法的完整详细信息，请参阅《SAP HANA SQL 参考指南》。
自动重新编译
可以使用“自动重新编译”功能，该功能能够检测 查询，然后根据此评估从 缓存，以便触发重新编译。
默认情况下，该功能处于禁用状态，但可以通过将 <service>.ini 文件的 sql 部分中的配置参数 plan_cache_auto_recompilation_enabled 设置为 来启用。启用功能后，重新编译 统计信息在监控视图中维护 M_SQL_PLAN_CACHE_AUTO_RECOMPILATION_STATISTICS。True
监视视图M_SQL_PLAN_CACHE_EXECUTION_ENGINE_STATISTICS显示执行统计信息 每个执行引擎。因此，此视图可能具有查询字符串的两个条目： 如果查询使用 HEX 和非 HEX 运行，则每个引擎都有一行;你可以使用 此信息用于比较每个计划的性能。如果查询仅运行 使用十六进制或非十六进制，则只有一行。
监视视图
以下监视视图包含缓存计划的详细信息：
- 例如，M_SQL_PLAN_CACHE_OVERVIEW包括最后的时间戳值 扫描基于时间/分数的逐出。
- 例如，M_SQL_PLAN_CACHE包括上次执行的时间戳值 计划的时间，以及当前计划缓存条目的详细信息的评分。
- M_SQL_PLAN_STATISTICS包括上次失效原因的值，例如， LOW_SCORE或已过期。
- M_SQL_PLAN_CACHE_AUTO_RECOMPILATION_STATISTICS保存有关触发的详细信息 自动重新编译。
- M_SQL_PLAN_CACHE_EXECUTION_ENGINE_STATISTICS EXECUTION_ENGINE专栏 指示是使用 HEX 引擎还是非 HEX 引擎来编译查询计划。 如果同时使用两个引擎，则视图显示每个引擎的一行 PLAN_ID。
-
提示
预定义和用户定义的提示可用于影响 SQL 的执行 查询。
提示是针对 SAP HANA 数据库服务器的说明，它会影响数据库的方式 请求已处理。SQL 优化器确定查询的访问路径，但 您可以通过在查询中指定提示来覆盖优化器，以强制执行某个 访问路径。提示通常用于优化 SAP HANA 性能或内存 消耗，并且对请求的结果集没有影响。预定义提示 SAP HANA提供了各种用途，可以从提示中列出这些用途 系统视图;请参阅适用于 SAP HANA 的 SAP HANA SQL 参考指南 平台了解更多详情。您还可以创建用户定义的提示和 将这些应用于 Select 语句。如果查询同时具有用户定义和 系统定义的提示，用户提示在首选项中使用。
为方便起见，您可以将查询与特定提示相关联，以便提示始终是 应用于运行时的查询。这可以在 SQL 中使用语句 ALTER 完成 SYSTEM ADD STATEMENT HINT 以及 SAP HANA cockpit 的 Statement Hints 应用中 （另请参阅系统视图STATEMENT_HINTS）。
作为将提示链接到 select 语句的替代方法，您可以将提示固定到 SQL 计划缓存中的特定执行计划。使用 ALTER 应用固定 SYSTEM PIN SQL PLAN CACHE ENTRY 指令并使用执行计划PLAN_ID 值链接到提示。请参阅《SAP HANA SQL 和系统视图参考》 指南和 SAP 说明 2400006 常见问题解答：SAP HANA 声明提示了解详细信息。
许多提示可用于缓存数据或数据副本，以提供“基于提示” 路由“功能，以便管理员可以准确控制哪个源 在选择数据源可用时使用，请参阅以下部分使用提示查询数据快照，了解 可用的可配置提示类。
使用提示查询数据快照
SAP HANA 中的多项功能使用数据快照来提高性能。您可以使用 可配置的提示类，作为在运行时控制数据的标准方式 从快照或数据库中选择。
SAP HANA 中的多项功能使用数据快照或复制数据来提高性能;这 包括：
-
结果缓存
-
异步表复制
-
系统复制（启用主动/主动读取）。
快照存在保存过时数据的风险，管理员需要能够指定 复制的数据可能滞后于实时数据的最大时间值。这 上面列出的功能都使用 RESULT_LAG（） 提示和一组标准可配置 提示类作为控制在运行时如何选择数据的常用方法（也 称为基于提示的路由）。提示类为管理员提供 在查询响应时间、查询负载、资源方面平衡系统的工具 数据的利用率和新鲜度。此外，它们将 SAP HANA 功能从 应用程序开发和管理员选择。
使用提示 RESULT_LAG（）
RESULT_LAG（） 提示需要两个参数值来确定：
-
哪个是首选数据源（快照或实时数据）
-
检索到的数据可能滞后于实时数据的时间。
RESULT_LAG（） 提示的语法如下所示 这里：
WITH HINT (RESULT_LAG(“<short_class_name>”, [seconds]))
类名：以下预定义的提示类可供使用 通过此提示，将详细描述这些以及用于配置它们的选项 下面。SQL 语句中仅使用名称的最后两个元素，因为 示例 'hana_cache'， 'hana_short' 等：
-
hint_result_lag_hana_cache - 对于结果缓存，默认滞后时间 value 是缓存保留时间
-
hint_result_lag_hana_atr - 对于异步表复制， 默认滞后时间值可以定义为配置参数
-
hint_result_lag_hana_sr - 对于系统复制（主动/主动），将 默认滞后时间值可以定义为配置参数
-
hint_result_lag_hana_es_atr - 用于扩展 存储副本节点，默认滞后时间值可以定义为 配置参数
-
hint_result_lag_hana_short
-
hint_result_lag_hana_long
请注意，客户和开发人员还可以添加自己的类（以及相应的类 配置值），但这些值不得使用 hana_* 或 sap_* 命名 公约。
秒：此参数是可选的时间值（以秒为单位）;这是 判断数据可接受的最大时间滞后;如果 快照或副本较旧，则不会使用它，并且查询将路由 数据源。如果未给出秒值，则将使用默认值。在 在某些情况下，可以通过设置配置选项来禁用此功能 - 请参阅 详情如下。
路由配置
每个提示类在 indexserver.ini 文件中都有自己的部分 （[hint_result_lag_hana_short] 例如，还必须为用户定义的类添加部分），其中 更多参数可用。所有类都具有 enable_features 参数;这就是“路由 参数，用于定义数据源的优先顺序 使用。下表显示了每个设置的默认enable_features设置 类，例如，hana_long类默认定义为 序列“resultcache，atr，sr”的意思是：来自 resultcache 的数据是 首选，如果不是，则来自副本表（异步表 replication），否则来自辅助系统的数据（系统复制）。这 定义的最大滞后时间值相同，适用于整个数据序列 来源（下面给出了一个示例）：
| 类 | 参数 | 默认设置（首选源序列） |
|---|---|---|
| hana_cache | enable_features | 结果缓存 |
| hana_atr | enable_features | ATR的 |
| hana_sr | enable_features | 锶 |
| hana_es_atr | enable_features | es，atr |
| hana_short | enable_features | ATR，SR |
| hana_long | enable_features | 结果缓存，ATR，SR |
本文更详细地介绍了如何在这三个应用领域中的每一个领域中使用这些类 在以下小节中。
结果缓存的提示类
使用类hana_cache目标视图/表的结果缓存 如果启用并适用该函数，则该函数被利用。这显示在 以下示例：
SELECT * FROM V1 WITH HINT( RESULT_LAG ( 'hana_cache', 30) );
如果给定提示的秒（时间）参数值，则它将覆盖任何 已为视图定义的保留时间值。例如，30 秒 上面示例中定义的时间滞后将覆盖一百分钟的保留期 创建缓存时定义的时间段：
ALTER VIEW v1 ADD CACHE RETENTION 100;
SAP HANA 中详细介绍了结果缓存和动态结果缓存 故障排除和性能分析指南。
异步表复制的提示类
可以使用 hana_atr 类来访问 复制的表。
SELECT * FROM T1 WITH HINT( RESULT_LAG ('hana_atr') , 10 );
If the current lag time for the data on the replica is less than the stated value for the [seconds] parameter (10 seconds in this example) then the query is executed on the replicated table, otherwise it would be executed on the source.
More Configuration Options for Class hana_atr
| Parameter: | atr_default_lag_time |
|---|---|
| Purpose | The default lag time value for this class. This value will be applied if no seconds value is entered with the hint on the SQL command line. |
| Default | -1 In this case if no seconds value is entered with the hint the query is always routed to the replica. |
| Unit | seconds |
| Parameter: | atr_ignore_lag_time |
|---|---|
| Purpose | Set this to true to disable the check for the specified lag time so that the query will always access replica tables regardless of the value entered with the hint and the default lag time setting. |
| Default | false |
For more information refer to the Asynchronous Table Replication section of this guide.
Hint Class for System Replication (Active/Active read enabled)
You can use the class hana_sr for system replication and select data from the secondary system. This is shown in the following example:
SELECT * FROM T1 WITH HINT( RESULT_LAG ('hana_sr', 60) );
If this is used in a situation where the result cache might also be available, the following table shows specifically which data source is used in either of the two possible cases (result cache available yes or no):
| enable_features | Result Cache Available? | Data Source |
|---|---|---|
| sr,resultcache | Yes | Secondary (cache used) |
| sr,resultcache | No | Secondary |
| resultcache,sr | Yes | Primary (cache used) |
| resultcache,sr | No | Secondary |
| 锶 | 是的 | 二 次 |
| 锶 | 不 | 二 次 |
| 结果缓存 | 是的 | 主数据库（使用的缓存） |
| 结果缓存 | 不 | 主要 |
下表显示了主系统上的行为。如果应用程序 直接连接到辅助系统，结果缓存也可以在 二 次。有关更多信息，请参阅活动/活动（阅读 Enabled） 部分。
类 hana_sr 的更多配置选项
其他参数也可用于 hana_sr 提示类：
| 参数： | sr_default_lag_time |
|---|---|
| 目的 | 此类的默认滞后时间值。将应用此值 如果未在 SQL 命令行上输入带有提示的值。 |
| 违约 | -1 在这种情况下，如果未输入带有提示的秒值，则查询始终路由 次要的。 |
| 单位 | 秒 |
| 参数： | sr_ignore_lag_time |
|---|---|
| 目的 | 将此设置为 true 可禁用指定滞后时间的检查。 |
| 违约 | 假 |
| 参数： | sr_enable_primary_redirection_for所有错误 |
|---|---|
| 目的 | 路由语句将重定向到所有主语句 错误。 |
| 违约 | 真 |
| 参数： | sr_enable_primary_redirection |
|---|---|
| 目的 | 此参数用于错误处理：如果内存不足错误 发生在辅助设备上，或者如果超过滞后时间，则 routed 语句将被重定向到主语句并执行。 |
| 违约 | 真 |
使用HANA_SHORT和HANA_LONG的示例
hana_long hana_short您可以在 与其他特定于应用程序的提示类结合使用。在这里，我们给出两个 例子;在第一个中给出了 seconds 参数的值，在第二个中给出了 seconds 参数的值 配置文件中指定的每个数据源的默认值为 使用。例如，hana_long 的配置文件可以是 如下：
示例代码
[hint_result_lag_hana_long] enable_features = resultcache,atr,sr atr_default_lag_time = 10 sr_default_lag_time = 20
enable_features 参数将数据源的顺序指定为： 结果缓存优先，其次是表副本，否则系统复制 辅助系统。
示例 1在此示例中，查询中给出了一个秒值 并且此值在所有三种情况下都用于评估是否缓存/复制 数据是可以接受的。
SELECT * FROM V1 WITH HINT( RESULT_LAG ('hana_long') , 10 );
首先，如果结果缓存数据小于 seconds 参数值（10 秒），则查询 将从这里读取数据。如果结果缓存太陈旧，则 复制的表数据将根据 seconds 参数值和 if 此数据太陈旧，则系统复制的数据将被评估为 确定是在主系统还是辅助系统上执行查询。如果没有 的缓存源可用（秒值小于当前滞后时间） 然后访问主系统。
示例 2在以下示例中（参考相同的序列 三个数据源）查询中未给出时间值，并且默认滞后 每个数据源的值用于评估数据源是否 可以接受：
SELECT * FROM V1 WITH HINT( RESULT_LAG ('hana_long') );
默认值为：对于结果缓存，预定义的保留期，对于 atr 和 sr，为 ini 参数值 在 [hint_result_lag_hana_long] 部分中定义，即异步复制atr_default_lag_time（10 秒） 在上面的示例代码中）和sr_default_lag_time for system 复制（在上面的示例代码中为 20 秒）。
管理带宽（文件 IO 限制）
一组配置参数可用于管理 HANA 文件输入/输出 层，以平衡不同设备和通道的吞吐量。
配置选项
HANA 文件 IO 层尝试使用基础 IO 的全部带宽 设备/通道，以保证最大的数据库性能。但是，使用同一 IO 设备的服务、服务实例和组件 或通道争夺 IO 带宽，管理员可能能够优化整个服务或某些组件的吞吐量 在服务中，通过设置此处描述的配置参数的值。
可配置的参数位于 相关 <service>.ini 配置文件的 [fileio] 部分：
-
max_throughput - 应用于整个服务的总吞吐量的限制
-
max_read_throughput - 应用于读取请求的限制
-
max_write_throughput - 应用于写入请求的限制
这些参数定义 IO 吞吐量的上限，以兆字节/秒 （MB/s） 为单位。每个 IO 请求都遵守限制 定义，文件 IO 层在这些限制内平衡请求。例如，在以下配置中，读取请求 将被限制为 80MB/s，而写入请求（以及整个服务的吞吐量）将被限制为 100MB/秒：
max_throughput=100 max_read_throughput=80
默认情况下，不会对每个参数应用任何限制（所有参数的默认值为 零），但遵守其他匹配参数应用的限制。限制值不能保证吞吐量达到限制 指定;如果有其他读取和写入竞争相同的 IO 带宽，则可能无法实现这些速度。
给 更精确的控制，每个参数都可以使用以下使用类型之一多次应用，然后应用 限制到相应的文件类型：
- DATA（数据量）
- LOG（支持使用值“-1”排除此类型的选项，请参阅下面的示例。
- LOG_MIRROR
- 备份（请参阅下面的示例和有关范围的注释。
- DATA_BACKUP
- LOG_BACKUP
- CATALOG_BACKUP
- ROOTKEY_BACKUP
例
max_write_throughput[DATA] = 100 max_read_throughput[BACKUP] = 100 max_read_throughput[DATA_BACKUP] = 100
这些用法类型是指应用限制的文件类型，而不是 IO 的类型 请求。因此，例如，使用类型 DATA 是指对 DataVolume文件。请注意不同 BACKUP 参数的作用域：type BACKUP 是指对备份文件的所有操作，但不包括数据、日志和 目录备份，它们都有单独的参数。此外，FileIO 限制是 HANA 功能，不会扩展到 backint 等外部工具。可以限制对本地备份文件的写入 使用 max_write_throughput[BACKUP]，但无法以这种方式限制对 backint 端点的写入。
例
更多示例：
| max_throughput = 250 | 对整个服务应用 250MB/s 吞吐量的限制。 |
| max_write_throughput[备份] = 100 | 写入备份介质的可用带宽限制为最大 100MB/s。 |
| max_write_throughput[对数] = -1 | 值“-1”可用于 LOG 类型，以防止限制写入日志文件的请求，因为这会 对整体数据库性能有严重影响。如果设置了此值，则不会对日志文件应用任何限制 写。 |
虽然可以定义相当复杂的规则集，但用于评估和测试目的 （参见下面的监控队列），建议只设置一个或两个参数值。设置非常小的值不是 推荐。此外，FileIO 层的平衡算法经过优化，可以处理大于最大页面的限制值 大小 （64MB），因此可能难以监视和测试小于 64 的限制值。
监控队列
在将请求移交给文件系统执行之前，它们会排队 SubmitQueue。但是，如果限制处于活动状态，则首先将请求添加到 ThrottleQueue 应用节流参数，然后将它们交给 SubmitQueue。例如，如果配置了 100MB/s 的油门，则 ThrottleQueue 每秒将向 SubmitQueue 移交 100MB 的请求。
您可以使用两个监视视图来查看已配置的 FileIO 的效果 油门和排队活动：
-
M_VOLUME_IO_TOTAL_STATISTICS：可用于监控物理和有效吞吐量（请参阅 以下关于重置聚合值的说明）
-
M_VOLUME_IO_SUBMIT_STATISTICS：可用于监控 FileIO 层队列
通过M_VOLUME_IO_TOTAL_STATISTICS进行监控：
此视图中 SIZE 字段的单位值是字节，TIME 字段的单位值是 在此视图中是微秒，因此底层 IO 的吞吐量“T” 设备/通道可以计算为：
T = (TOTAL_(IO/READ/WRITE)_SIZE * 1000 * 1000) / (TOTAL_(IO/READ_WRITE)_TIME * 1024 * 1024)
在应用限制之前，请检查物理吞吐量值 T，然后决定 在节气门参数的有意义的值上。
同样，FileIO 层用户观察到的吞吐量“t”可以计算为：
t = (TOTAL_(IO/READ/WRITE)_SIZE * 1000 * 1000) / (TOTAL_PROCESSING_(/READ_WRITE)_TIME * 1024 * 1024)
如果激活了限制，则 T 应该或多或少保持稳定，但 t 应该保持稳定 反映配置的油门。
注意
此视图的所有列都会聚合一段时间内的值。在一段时间内获得有意义的值 间隔可以执行以下任一操作：
-
请参阅统计服务器视图HOST_VOLUME_IO_TOTAL_STATISTICS（和 相应的增量列）
-
使用具有可重置的监控视图的“重置”版本 计数器，并且仅包含自 上次重置主视图。您可以重置此视图的计数器 通过运行以下 reset 命令，该命令在 当前时间：
ALTER SYSTEM RESET MONITORING VIEW SYS.M_VOLUME_IO_TOTAL_STATISTICS_RESET;
指 有关更多详细信息，请参阅《SAP HANA SQL 参考指南》和 SAP HANA 的“分析 I/O 吞吐量和延迟”部分 故障排除和性能分析指南。
下表给出了用于 监测：
| 列 | 值 |
|---|---|
| TOTAL_READ_SIZE TOTAL_WRITE_SIZE | 从列 TYPE 中读取或写入使用情况的总大小（单位：字节）。总计 读取和写入的大小很简单： TOTAL_IO_SIZE = TOTAL_READ_SIZE + TOTAL_WRITE_SIZE. |
| TOTAL_IO_TIME TOTAL_READ_TIME TOTAL_WRITE_TIME | 这些值显示在物理上执行 IO 请求所花费的时间（单位：微秒） 设备/通道。 请注意，由于读取和写入重叠，TOTAL_IO_TIME 与 TOTAL_READ_TIME + TOTAL_WRITE_TIME 不同。 节流对这些时间影响不大，它们只是反映了 底层 IO 设备/通道的物理功能。 |
| TOTAL_PROCESSING_TIME TOTAL_PROCESSING_READ_TIME TOTAL_PROCESSING_WRITE_TIME | 这些值显示 IO 请求在 FileIO 层中使用 应用了限制限制。这些是用户可以的时间 测量他们何时执行 IO 请求。 |
通过M_VOLUME_IO_SUBMIT_STATISTICS进行监控
此视图显示哪些 IO 请求已添加到队列层次结构中 FileIO 层。
| 视图 | 显示 |
|---|---|
| DISPATCH_SUBMIT_QUEUE_*_SIZE | 这些列显示直接添加到 SubmitQueue 的请求的总大小。如果没有 应用限制，此处反映所有 IO 活动，显示如何 快速将上层将请求推送到 FileIO 层。 |
| DISPATCH_THROTTLE_QUEUE_*_SIZE | 这些列显示添加到 ThrottleQueue 的请求的总大小，显示速度 上层在限制时将请求推送到 FileIO 层 处于活动状态。 |
| THROTTLED_DISPATCH_SUBMIT_QUEUE_*_SIZE | 这些列显示从 ThrottleQueue 移动到 SubmitQueue 显示请求的推送速度。 |
扫一扫
2525
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
