云解析_高性能数据库_安全稳定

时间:2021-09-28 13:46       来源: 微辰云

云解析_高性能数据库_安全稳定

您是否想过,从触发启动或重新启动到最终可供应用层使用,SAP HANA都在做些什么?

或者您经历过一次启动,您的系统比您计划的要花更长的时间才能可用,您正试图理解,它一直在做什么来避免它、改进它或计划下次使用它?

让我试着解释一下,因为你越了解哪些因素影响启动时间,你就越能判断和影响它,或者至少考虑到它。

当启动SAP HANA时,作为第一步,商城返利系统,守护程序服务就启动了。守护程序是一个轻量级服务,它设置其余服务(nameserver、indexserver、scriptserver、xsengine等)所需的环境变量,淘客推广渠道,然后按正确的顺序启动它们。

守护程序启动的所有服务基本上是彼此独立启动的,大数据分析是什么,下面详细介绍了9个步骤,在这些服务之间进行同步在某一点上彼此:

具有持久性的服务(例如nameserver、indexserver,…)需要打开它们的卷。

在卷可以打开之前,相应的文件系统需要在正确的装入点提供给正确的服务器。

处理此任务不是单个服务的工作的一部分。相反,如果您使用的是SAP HANA光纤通道存储连接器,则是nameserver服务装载所有服务的数据和日志卷。如果您不使用它,您需要确保在单个服务尝试打开其卷之前完成此任务。

打开卷基本上意味着获取该卷的文件句柄,因此我们谈论的是毫秒或最多秒。超过这个数量级的任何延迟通常是由保留冲突或其他与存储相关的问题引起的。

相关跟踪条目:

现在卷已打开,基本的低级持久性结构已从磁盘加载。由于它们以与磁盘上存储的结构非常相似的结构保存在内存中,因此不需要耗时或资源消耗的转换。相反,此步骤的持续时间主要受I/O限制。

更准确地说,以下任务在此步骤中完成:

迄今为止关于此步骤的说法暗示,此步骤的持续时间不应发生实质性变化。但是,如果其中一个促成因素本身有很大的差异,也就是:

持久性的大小,特别是卷的大小,那么它就可能发生撤消文件数基于磁盘的LOB数数据卷的读取性能

相关跟踪条目:

HANA 2的改进:

从HANA 2开始,压缩LOB可用。在许多其他优化中,打包LOB使用优化的持久性结构,允许在启动过程中更快地处理LOB,从而减少在第二步中花费的时间。

只要系统启动并运行,行存储就保存在共享内存中,由相应的HANA服务操作系统进程拥有。在关机期间,这个共享内存通常会被释放回操作系统,而在系统启动期间,整个启动时间的很大一部分将被用来再次将行存储加载到内存中。

将行存储加载到内存中所需的时间当然主要取决于行存储表的容量在系统中,但通常这一步是整个启动时间的主要贡献者。

为了节省时间,有一个优化,如果满足某些条件,允许在重新启动相应服务的情况下将包含行存储的共享内存保留在内存中。

长话短说-如果满足少数条件,则可以在服务/系统关闭的情况下将行存储保留在内存中,大数据治理平台,并在重新启动时将其重新连接到所有者服务,从而使从启动时磁盘冗余。SAP Note 2159435中提供了有关此功能的更多技术细节。

如果不满足任何条件,请将其保持在关闭状态和/或在启动时重新连接,行存储将在此步骤中从数据卷加载。

现在行存储已重新加载或重新连接,行存储需要回滚关闭前未提交的所有更改。

与加载和初始化持久性结构所花费的时间不同,加载或重新附加行存储所花费的时间可能会因启动而异,具体取决于:

行存储的大小是否满足保留和重新连接行存储的所有条件数据卷的读取性能,如果行存储无法保留,请重新启动行存储中需要回滚的更改量

相关跟踪条目:

正如在前面解释的步骤中,行存储必须回滚关闭前未提交的所有更改一样,HANA也需要对列存储进行一些清理。

在这个步骤中,垃圾收集器将清除所有版本,但任何列存储表的最新版本除外。如您所知,垃圾回收器会不断清理系统启动和运行时不再需要的版本—仍然—如果系统在事务仍处于打开状态且长时间(小时、天、周、一目了然……)未提交的时间点关闭,则可能还有一些版本需要清理在启动期间启动。

在HANA 1中,此步骤需要完全完成,然后才能继续重放日志。

此步骤所消耗的时间可能因启动而异,因为这在很大程度上取决于:

关闭前阻止垃圾收集的事务的存在用于处理历史清理文件的数据卷的读取性能在HANA版本上,由于这定义了该步骤是否阻止下一步

相关跟踪条目:

HANA 2中的改进:

使用HANA 2,异步执行垃圾收集过时版本。这意味着,它将允许下一步,即重放日志,并行地继续。