跳转到主内容

使用 ALTER 系统减少 SAP HANA 数据库卷 reclaimer datavolume" 命令可能会导致性能问题或服务中断

Views:
29
Visibility:
Public
Votes:
0
Category:
data-ontap-7
Specialty:
nfs
Last Updated:

适用于

ONTAP 操作系统

解答

使用 SQL 命令 "alter system reclaimer datavolume xxx defragment" 截断 SAP HANA 数据文件可能会导致性能严重下降,在极少数情况下,可能会导致错误编号 865444 中所述的控制器中断。[1]如果通过 NFS 连接 SAP HANA ,并且为了节省磁盘空间而减小了非常大的 SAP HANA 数据文件的大小,则会发生此问题。
  
此 SQL 命令会导致 SAP HANA 复制数据文件中的大量数据块,从而导致更改率非常高。使用 NetApp Snapshot 技术进行 SAP HANA 数据库备份时,文件截断的预期空间节省效果将被抵消。此外,它还会导致服务器和存储 CPU 利用率非常高。此外,如果截断的文件是另一个文件的克隆,则不会节省空间。因此,截断操作可能不会节省大量空间。

因此, NetApp 不建议使用此 SQL 命令。在极少数情况下,如果 reclaimer 命令可能会很有用,例如系统的初始数据负载或删除大量数据, NetApp 建议将 reclaimer 命令拆分为多个步骤,以便每个步骤只回收文件的较小部分。 将对性能的影响降至最低。对于延迟敏感型操作, NetApp 建议将最大截断大小限制为 250 GiB ,对于可能希望运行较少截断命令的客户,则限制为 500 GiB 。
 
此外, NetApp 还提供了一个修补程序,所有运行基于 NFS 的 SAP HANA 的客户都应安装并配置该修补程序,这些客户打算使用上述命令。此修补程序可加快截断的内部处理速度,并允许客户将 CP 超时设置为更高的值,以避免在回收命令使用不当时发生数据服务中断。  
 
请考虑以下客户希望截断单节点 SAP HANA 数据卷的示例。如 SAP 注释 1870858 中所述,数据文件大小可从 SAP HANA Studio 列 ´的卷管理窗格中以( MB )为单位确定。´实际已用空间或 ´有效负载´ 以 ´已用大小( MB )表示´。
在此示例中,确定的值为:

  • SAP HANA 数据文件大小为 2.2 TB
  • 实际有效负载为 1 TB 
假设客户希望将文件大小缩减到 1.2 TB ,即有效负载的 120% 。因此,文件大小将减少 1 TB 。根据 NetApp 的建议,需要将截断拆分为 4 个操作,以便将最大截断大小限制为 250 GB 。
 
起始容量为 2.2 TB ,即有效负载的 220% :
第一步,文件大小应减少 250 GB 。新文件大小将为 1.95TB 或有效负载的 195% 。因此,此序列的第一步是:

第 1 步 => " 更改系统回收数据卷 195 碎片整理 "

使用此命令时, SAP HANA 将开始移动文件中的块并返回一条成功消息。此时,存储上的文件截断操作将开始。NetApp 建议等待 5 分钟,然后再运行下一个回收命令,以确保先前的文件截断操作已完成。其余命令序列将相应计算:

第 2 步 =>" 更改系统回收数据卷 170 碎片整理 " 在 SQL 命令返回
步骤 3 后等待 5 分钟 ="Alter system reclume datavolume 145 碎片整理 " 在 SQL 命令返回
步骤 4 后等待 5 分钟 ="alter system reclume 120 碎片整理 '

请注意,上述建议要求仅在 NetApp FAS 中使用一个技术报告配置 NFS 系统。
 
修补程序信息:
如上所述,安装修补程序后,该修补程序可以激活 2 个选项。
 
注意:在修改注册表选项之前,请确保您的 ONTAP 配置具有错误编号865444 的修复版本。集群模式首次在 8.3.2P5 中修复。在 8.2.4P5 中首次修复 7- 模式(目标)。检查错误工具是否有更新:

安装修补

system node run -node <Node name> -c "priv set diag; options wafl.cp.timeout 1799"

"priv set diag; options wafl.cp.timeout 1799"

程序后,应在每个节点上设置以下注册表选项以增加 CP 超时:对于集群模式:对于 7- 模式:不建议使用 1799 以外的值或默认值 600 ,否则可能会对 FAS 或 AFF 系统产生意外影响。
 
安装修补程序后,应在每个节点上设置以下注册表选项,以提高截断请求的整体性能:
对于集群模式:
  • system node run -node <Node name> -c "priv set diag; options wafl.buf.usage.prefetch 255"   
  • system node run -node <Node name> -c "priv set diag; options wafl.buf.usage.prefetch_for_clones_with_fbc 255" 
对于 7-模式:
  • priv set diag; options wafl.buf.usage.prefetch 255
  • priv set diag; options wafl.buf.usage.prefetch_for_clones_with_fbc 255
注:
  • wafl.buf.usage.prefetch 默认值为 64  
  • wafl.buf.usage.prefetch_for_clones_with_fbc 默认值为 4 

其他信息

回收命令序列可通过以下公式派生:

  1. 在最后一个命令之前运行的命令数量可以派生如下:
    c = ( i - f ) /t ,
    其中:
    • c 是要运行的命令数 (向下取整为最接近的整数)
    • i 是数据文件的初始大小
    • f 是数据文件的最终大小(有效负载 * 所需过载百分比,即 120% )
    • T 是所选的最大截断大小
  2. 每个命令的减少百分比可通过
    以下方式确定
    : pt = 100 * t / p ,其中:
    • pcT 是每个命令的减少百分比 (向下取整为最接近的整数)
    • p 是数据库的有效负载大小
    • T 是所选的最大截断大小
    • 对于延迟敏感型操作,容量为 250 GiB ;如果客户需要,容量为 500 GiB 希望发出更少的截断命令
  3. 要运行的第 n 个命令可通过以下命令确定:
    第 n 个命令: "alter system reclume datavolume x defragment"
    x = 100 * i / p - ( pct * n )
    ,其中:
    • i 是数据库的初始大小
    • p 是数据库的有效负载大小
    • p 是数据库的有效负载大小
    • n 是命令计数的迭代器
回收命令序列示例:
有效负载大小 = 3 TB   
  • I = 初始数据文件大小 = 7.2 TB (比有效负载大小大 240% )
  • F = 最终数据文件大小 = 3.6TB ( 1.2 倍有效负载)  
  • T = 最大截断大小 = 500 GiB = 0.5 TB
 
确定要在最后一个命令之前运行的回收命令的数量:
  • C = ( i - f ) / t ,
  • C = ( 7.2 TB - 3.6 TB ) /0.5 TB
  • C = 7.2 = > 7
 
确定每个命令的减少百分比:
  • PCT = 100 * t / p
  • PCT = 100 * 0.5 TB/3 TB = 16% 

第 N 个命令: "alter system reclume x defragment"
x = 100 * i / p - ( pct * n )

初始数据文件大小比有效负载大 240%= 3 TB
Command 1 => 'ALTER SYSTEM RECLAIM DATAVOLUME 224 DEFRAGMENT'
Command 2 => 'ALTER SYSTEM RECLAIM DATAVOLUME 208 DEFRAGMENT'
Command 3 => 'ALTER SYSTEM RECLAIM DATAVOLUME 192 DEFRAGMENT'
Command 4 => 'ALTER SYSTEM RECLAIM DATAVOLUME 176 DEFRAGMENT'
Command 5 => 'ALTER SYSTEM RECLAIM DATAVOLUME 160 DEFRAGMENT'
Command 6 => 'ALTER SYSTEM RECLAIM DATAVOLUME 144 DEFRAGMENT'
Command 7 => 'ALTER SYSTEM RECLAIM DATAVOLUME 128 DEFRAGMENT'
Command 8 => 'ALTER SYSTEM RECLAIM DATAVOLUME 120 DEFRAGMENT'

最终数据库大小比有效负载大 120%