如何收集HANA Trace 等支持信息.docx

如何收集HANA Trace 等支持信息Skip to end of metadata /wiki/pages/viewpage.action?pageId=356419679 Attachments:19 Added byAllen Yang, last edited byAllen Yangon Oct 25, 2013(view change)Go to start of metadata目录 1Trace 管理需要什么权限? 2配置 Trace File Rotation 3配置 Traces 3.1不同 traces 类型的比较 3.2SQL Trace 3.2.1SQL Trace 选项 3.3性能 Trace 3.3.1性能 Trace 选项 执行性能差的问题 3.4Kernel Profiler 3.4.1Kernel Profiler 选项 3.5其他 Database Traces 3.5.1Database Traces Parameters (待添加) 建模问题 (激活/重新部署) 安全问题 3.5.2End-to-End Traces 3.5.3Expensive Statements Trace 4在 SAP HANA Studio 中搜集和下载诊断信息 4.1HANA Update/Backup Issue 5利用 Support Script 收集诊断信息本文档将帮助您收集宝贵的 trace 文件，在面对经常遇到的问题时能够获得更好的支持。客户必须在重启系统之前收集好相应的 trace 文件，因为一旦重启，所有重要的支持信息都会丢失。注意: 下面提到的所有配置项，在所需的 trace 文件被收集后，应该被还原为默认值。Trace 管理需要什么权限?配置所需的权限或角色配置 trace file rotation系统权限 INIFILE ADM配置 trace系统权限 TRACE ADMIN配置 kernel profilerSUPPORT 标准角色或者有系统权限 RESOURCE_ADMIN 和 TRACE_ADMIN 两者之一配置 Trace File RotationTrace File Rotation 通过限制trace files的大小及数量来防止其无限制地增长。你可以在系统中为全部服务或单个服务配置 trace file rotation。1. 在Administration Editor中，选择Configuration标签。2. 根据你是为系统所有服务还是为个别服务配置 trace file rotation，以下列出不同的步骤操作：选择描述所有服务1.找到 global.ini 文件，展开trace部分2.配置maxfiles参数，指定 trace file 可以保存的最大数量3.配置maxfilesize参数，指定每个 trace file 可以达到的最大存储值，该参数以 byte 为单位注意global.ini 中maxfiles和maxfilesize这两个参数的默认值分别为10和10000000个别服务1.找到相应服务的配置文件(如 indexserver.ini)，并展开trace部分如果没有trace部分, 请右键点击*.ini文件, 选择 Add Section. 来新建一个 section2.配置maxfiles参数，指定 trace file 可以保存的最大数量3.配置maxfilesize参数，指定每个 trace file 可以达到的最大存储值，该参数以 byte 为单位注意如果trace部分没有上述的两个参数，或者 trace 部分是新建的，请右键点击trace，选择Add Parameter当一个 trace file 达到指定的最大存储值，它将停止保存更多的 trace 数据，同时一个新的 trace 文件将被生成。当 trace 文件的数量达到指定的最大值且需要再新建一个 trace 文件的时候，最早的一个 trace 文件将被删除，如此类推。注意statistics server 会定期地检查 diagnosis file 的大小和数量。这些定期检查的阈值应该与 trace file rotation 中的配置一致。（The threshold values for these checks (check 50 and 51) should be in line with the configured trace file rotation）配置 TracesHANA提供多种 trace 来获取与数据库系统操作相关的详细信息。你可以在 Administration editor 中的Trace Configuration标签中激活和配置 trace。你可以配置以下几种 trace:Trace默认配置/状态SQL traceInactive (未激活)Performance traceInactive (未激活)Kernel profiler traceInactive (未激活)Global database traceActive with default trace level ERROR ( trace level 为 ERROR 时激活)Database traceActive with default trace level ERROR( trace level 为 ERROR 时激活)User-specific traceNot specified (未规定)End-to-End traceActive with default trace level ERROR( trace level 为 ERROR 时激活)Expensive statements traceInactive (未激活)1. 在Administration editor 中选择Trace Configuration标签2. 根据你想要配置的 trace 类型，点击笔状按钮(Edit Configuration)，将会出现一个Trace Configuration对话框3. 根据所需做出配置，对于不同的 trace 类型，Trace Configuration对话框会提供不同的可选项注意如果需要还原 trace 的默认状态或配置，请在Trace Configuration对话框中选Restore Defaultstrace 所记录的数据将被保存在 trace file 中，你可以在Diagnosis Files标签下查看不同 traces 类型的比较No.类型描述场景1SQL Trace收集所有被执行SQL语句的相关信息 (如错误，结果，受影响的行)找出详细的SQL执行计划和步骤2Performance Trace以SQL语句和内部操作为单位收集信息 (如执行时间，被读和写的数据大小，网络通信状况)运行期间的性能变差等问题3Kernel Profiler Trace收集 query 处理过程中的相关信息，如被频繁调用或者效率低，代价大的执行路径等用来分析某些不能安装第三方软件的系统上出现的性能问题，或者数据库中不能被 performance trace 检测的部分4Database Trace收集来自具有不同配置的多个HANA服务器的信息具体的HANA问题，如意想不到的返回数据，模型激活错误，安全问题等5User-Specific Trace收集HANA中特定的应用信息或用户信息许多用户在一个 instance 上同时操作6End-to-End Trace由SAP HANA外部应用触发的 trace7Expensive StatementsTrace专门收集执行时间超过某个设定值的SQL语句 (默认值为1000000 microseconds)有一个job ticket执行了很长时间或被挂起SQL TraceSQL trace 收集所有被执行的SQL语句的相关信息，并将其保存至一个 trace file 中供进一步的分析使用。所收集的信息包括每个语句的总体执行时间，被影响记录的数量，被报告的潜在错误 (如违背了唯一性约束unique constraint violations)，数据库连接被占用等等。因此，可以先从 SQL trace 入手去理解语句以及他们对应用和系统性能的潜在影响，同时也能够在语句层面上确定可能存在的性能瓶颈。SQL trace 信息被保存在 trace file 中，你可以在 Administration editor 中的Diagnosis Files标签中找到它们。注意写 SQL trace file 会显著地影响数据库的性能，它们也会占据磁盘很大的存储空间，因此并不推荐 SQL trace 一直处于激活状态。SQL Trace 选项你可以在 Administration editor 中的Trace Configuration标签中激活SQL trace你可以在下列的 trace level 中选择：Trace Level描述ERROR收集返回结果为错误的语句的相关信息ERROR_ROLLBACK收集返回结果为错误的或者出现回滚的语句的相关信息ALL收集所有语句的信息ALL_WITH_RESULTS收集所有语句的信息,包括关于结果的详细统计数据. 注意该选项会导致 SQL trace 收集到的数据量在短期内迅速增长下面为附加的可选配置: 通过设置筛选条件，可以将被 trace 的语句限制在某个数据库、应用上的用户或者是某个应用，又或者是限制在某些语句类型和表。所有符合该筛选条件的语句将被记录并保存到指定的 trace 文件中。 为 trace 文件自定义一个名字如果你没有给定一个特定于用户的名字, trace 文件会按照如下的规则命名: $HOST 是服务的主机名(比如, indexserver) $PORT 是服务的端口号 $COUNT是一个自动生成的3位数字，以000开始并每次加1。当多个文件被创建时，它可以作为一个文件计数器使用 你可以根据实际需求修改 flush interval。在 trace 的过程中，连接中的消息会被缓存。一旦被缓存的消息数达到 flush interval 的值，这些消息将被写入 trace file 中。性能 TracePerformance trace 是植入在SAP HANA数据库中的一个性能 trace 工具。它在数据库内核中记录着单个 query 处理过程中每个步骤的性能指标（performance indicator (wikipedia)）。收集到的信息包括某个步骤所需的处理时间，被读和写的数据大小，网络传输状况，以及针对操作者或处理流程的信息(比如被用作输入和输出的记录数量)如果你想分析一个命令的性能，我们建议在开启 performance tracing 后马上执行该命令，并于其执行完毕后马上停止 performance tracing。当你停止tracing时，结果会被保存至trace file中，你可以在 Administration editor 中的Diagnosis Files标签中找到它们。SAP HANA studio 不能帮助你分析这些 trace file，你需要使用另外的一个可以读输出格式为(*.tpt)的文件的工具来。SAP Support 有工具专门用来评测 performance trace。注意Performance trace 工具比较适用于专家使用。你需要对被分析的系统组件有着深刻的理解才能很好的解释被收集的信息。性能 Trace 选项你可以在 Administration editor 中的Trace Configuration标签中激活 performance trace有以下几种配置选项可用: 可以专门为某个特定的数据库用户，或某个特定的应用用户，或某个特定的应用进行配置。如果是在 end-to-end trace scenario 中激活 performance trace，还可以指定passport trace level作为一个附加的筛选条件，这样能让只有符合相应 passport level 的请求才会被 trace。 除默认的 trace data 外，还可以额外 trace 执行计划 激活 function profilerFunction profiler 是一个基于源码仪表的（source code instrumentation (wikipedia)），具有极细粒度的 performance tracing 工具。对于在数据库内核上完成的执行步骤，它提供了更多详尽的信息，以此来弥补 performance trace 在这方面的不足。 指定 trace 数据在 performance trace 停止后自动保存时所用的文件名 指定 tracing 操作持续的时间如果要 trace 某个特定的 scenario，请确保输入一个大于该 scenario 持续时间的数值。如果没有指定 scenario，而是要对系统整体性能进行 trace，请输入一个合理的数值。Trace 将会在执行到指定的时间后自动停止。执行性能差的问题 错误场景：一个sql/mdx请求（或者是某些操作导致一个内部请求，如data preview导致一个“select”）在较新版本的HANA中所花的时间比久版本的要多 Howto: 打开系统中的 Administration editor，到trace configuration标签中 点击Performance Tracesection中的Edit Configuration 重命名trace file，并开启两个子选项 点击Finish，回到 sql editor 中执行 query 在 query 返回期待的结果后，到trace configuration标签中点击Performance Trace 中的 Edit Configuration，之后点击Finish 在Diagnosis Files标签中，用先前步骤中设置的命名搜索 performance trace 文件。打开并下载整个 trace file。 Trace file: performance trace file 更多的信息，请参照Performance Issues.Kernel ProfilerKernel profiler 是植入在SAP HANA数据库中的一个抽样 profiler。举个例子，它收集 query 处理过程中的相关信息，如被频繁调用或者效率低，代价大的执行路径等它可以用来分析那些不能安装第三方软件的系统的性能问题，或者某些不能被 performance trace 访问的数据库部分。如果你想分析一个语句，我们建议在开启 kernel profiler 后马上执行该语句，并在其执行完毕后马上停止 kernel profiler。这样做可以避免对无关语句做出不必要的记录，也可以减少对系统性能的负面影响。当 tracing 结束时，结果将被保存至 trace file 中，你可以在Administration editor 中的Diagnosis Files标签下找到它们。SAP HANA studio 无法帮助你分析这些 trace file，你需要使用另外的工具来读取分析这些有特殊输出格式的文件，譬如 KCacheGrind 或 DOT。注意Kernel profiler 工具比较适用于专家使用。你需要对 SAP HANA 数据库内核的源代码有着深刻的理解才能很好的解释被收集的信息Kernel Profiler 选项你可以在 Administration editor 中的Trace Configuration标签中激活 performance trace当你开始 tracing 时，可以指定如下的选项： Kernel profiler 在两次 call stack 检索间需要等待的时间 激活 kernel profiler 后，它会多次检索相关线程的 call stack，如果指定了 wait time，它必须等待的时长为被配置的时间减去上次检索所花费时间。 到达 memory limit 时暂停 tracing Kernel profiler 可能会占用很多的内存。为了防止SAP HANA数据库由于 profiling 而用尽内存，可以给 tracing 配置一个内存的限制值，使其不能用超过这个值。当 tracing 停止时，你可以配置输出的格式。其他 Database Traces其他一些 database trace 可以用来获取系统活动的详细信息，包括特定组件的 database trace，end-to-end analysis trace 和 expensive statement trace你可以在 Administration editor 中的Trace Configuration标签中激活和配置这些 trace，并在Diagnosis Files标签中找到对应的 trace files。Database Tracesglobal database，database和user-specific traces 存储在.trc 文件中，它们为多个系统服务做 trace，其中一些 trace 经常是默认开启的。注意在Trace Configuration对话框中不是所有的 trace 组件都是可见的，如果要查看所有的附加组件，请选择Show All Components有以下 trace level 可选：Trace Level描述NONETracing 被关闭，但是错误信息仍会被记录ERROR (default) and FATAL错误信息会被记录WARNING可能存在问题的状况都会被记录INFO数据库中的活动信息都会被记录DEBUG用来debug的详细信息都会被记录注意global database trace 中设置的 trace level 将会在所有服务器中生效。database trace 中设置的 trace level 只会在特定的服务器中生效。如果在这两种trace中设置了不同的 level，则 database trace level 将会覆盖 global database trace level。举个例子，如果你在 global database trace 中将 authentication component trace level 设置为DEBUG，同时又在 index server的database trace 中将其设置为WARNING，则 index server 将只会 trace WARNING 级别以上的信息，而忽略 INFO 和 DEBUG 级别的。Parameters (待添加)想要获得重要的 trace 文件，需要设置一些有用的参数。ComponentParameterDescriptionIndexserverauthorizationexecutormdxrepositorytransactionimportexportnameserverstatisticserverscriptserverpreprocessorxsenginecompileserver建模问题 (激活/重新部署) 错误场景：在激活/重新部署 attribute / analytic / calculation view时出错 Howto: Trace Configuration标签中打开 Database Trace 选择show all components并搜索executor 和 mdx，将 indexserver 组件中它们的值设为 ”DEBUG“ 实施 activation/redeployment （激活/重新部署） Diagnosis Files标签中，根据activation/redeployment 的时间，搜索并打开 indexserver 相应的trace file 点击Show entire file并下载 Trace file: indexserver trace file安全问题 错误场景：用户没有权限执行某些操作 Howto: 与建模问题类似，将 indexserver 组件中*”*authorization*“*参数的值设为DEBUG 到Diagnosis Files标签中下载indexserver trace Trace file: indexserver trace fileEnd-to-End TracesEnd-to-end trace由SAP HANA数据库外部的应用触发。为SAP HANA数据库组件配置的默认trace level通常是足够的，因此没必要去修改。如果在你的landscape中需要更多的end-to-end analysis 信息，请参考SAP Library for Solution Manager on SAP Help Portal at/solutionmanager71underApplication HelpSAP LibraryTechnical OperationsRoot Cause AnalysisEnd-to-End Analysis Overview.Expensive Statements TraceExpensive statements trace 专门收集那些执行时间超过一个阈值（默认为1000000 microseconds）的SQL语句。Expensive statements 可能会降低数据库的性能。你也可以在Performance标签下监控 expensive statements。在 SAP HANA Studio 中搜集和下载诊断信息为了协助 SAP Support 分析和诊断你的系统，你可以收集的诊断信息打包到一个zip文件，之后你可以下载之并将其作为 support message 的附件。即使无法连接到数据库，仍旧可以完成这个操作。需要如下的前提条件 :数据库连接状态前提条件已连接要收集诊断信息，你需要一个具有选择系统表和视图的SQL权限的用户，并使用该用户登陆到系统中。 要下载和删除已收集的诊断信息时，你需要以管理员身份（user adm）登陆到操作系统，或者在被提示时能够提供所需的证书。未连接你需要以管理员身份（user adm）登陆到操作系统，或者在被提示时能够提供所需的证书。1. 在 Administration editor 中选择Diagnosis Files标签。注意如果没有连接到数据库，Administration editor 会以diagnosis mode 打开。2. 选择Diagnosis Information - Collect.系统通过执行 Python 脚本fullSystemInfoDump.py 来收集相关数据并将其保存到一个 zip 文件。这个操作可能需要一些时间，可以选择在后台运行。3. 要下载保存诊断信息的 zip 文件，需要如下操作：a) 选择Diagnosis Files - List.如果有提示，请输入操作系统管理员(user adm) 的用户名和口令。Diagnosis Information对话框弹出，显示那个保存着诊断信息的 zip 文件，一同被列出的还有保存有历史收集信息的 zip 文件。b) 选中相关的 zip 文件并选择Download Collection.c)指定下载位置4. 可选项: 删掉你不再需要的旧文件，选中它们并选择Delete CollectionsHANA Update/Backup Issue 错误场景：HANA数据库不能成功地从老版本更新或生成一个备份 Howto: 升级 登上主机 (OS level)，下载名字为hdbupd.log 的upgrade log，路径为(/var/tmp/hdb_upgradeor /usr/tmp/hdb_upgrade) 备份* 在Diagnosis Files中下载backup.log。更多关于backup/recovery 的信息，请参考Backup, Restore and Recovery Trace file: hdbupd.log or backup.log利用 Support Script 收集诊断信息使用 Python 写的支持脚本 fullSystemInfoDump.py，即使是在无法通过SQL来获取到时，你也可以收集你系统里的信息。之后你便可以将这些信息添加到 suppor message 中。注意可以在 SAP HANA studio 中完成这项任务。fullSystemInfoDump.py 脚本是系统安装的一部分，它位于$DIR_INSTANCE/exe/python_support 目录下，并可以通过命令行执行。要成功执行这个脚本，你需要以操作系统的管理员身份 (user adm) 登陆。于脚本所在目录下执行python fullSystemInfoDump.py。如果系统无法通过SQL获取，脚本将会开始收集 support information 而不会从系统表中将数据导出。脚本将创建一个 zip 文件来保存被收集的系统信息，并将之存放在_DIR_GLOBAL/sapcontrol/snapshots_ 目录下。DIR_GLOBAL一般指向/usr/sap/SYS/global 。注意以下几点: zip 文件的名字为如下格式：fullsysteminfodump_.zip。文件名中的 timestamp 为UTC。SAPLOCALHOSTFULL 和 SAPSYSTEMNAME 取自sapprofile.ini 文件。 脚本执行的时候会将 zip 文件的输出路径显示在 console 中。如果需要搜索该文件，可以执行命令 hdbsrvutil -z | grep DIR_GLOBAL= 执行命令python fullSystemInfoDump.py -h可以显示使用信息。 执行命令python fullSystemInfoDump.py -version可以显示版本信息。fullSystemInfoDump.py 所收集的诊断信息日志文件所有关于已被收集的信息会在 console 中显示，同时会被写到一个名为log.txt的文件中，并最终保存在 zip 文件里。Trace 文件下列文件被放在一个与 trace file 同名的文件里。出于存储的原因，只有最近7天的 trace file 被完整保存；而更早的 trace file 只会保存最新的 10,000 行。 $DIR_INSTANCE/trace/daemon_.trc $DIR_INSTANCE/trace/indexserver_alert_.trc $DIR_INSTANCE/trace/indexserver_.trc $DIR_INSTANCE/trace/nameserver_alert_.trc $DIR_INSTANCE/trace/nameserver_history.trc $DIR_INSTANCE/trace/nameserver_.trc $DIR_INSTANCE/trace/preprocessor_alert_.trc $DIR_INSTANCE/trace/preprocessor_.trc $DIR_INSTANCE/trace/statisticsserver_alert_.trc $DIR_INSTANCE/trace/statisticsserver_.trc配置文件 每个 configuration file 都被完整的收集和保存在与 *.ini 文件同名的文件中。 $DIR_INSTANCE/exe/config/attributes.ini $DIR_INSTANCE/exe/config/daemon.ini $DIR_INSTANCE/exe/config/executor.ini $DIR_INSTANCE/exe/config/extensions.ini $DIR_INSTANCE/exe/config/filter.ini $DIR_INSTANCE/exe/config/global.ini $DIR_INSTANCE/exe/config/indexserver.ini $DIR_INSTANCE/exe/config/inifiles.ini $DIR_INSTANCE/exe/config/localclient.ini $DIR_INSTANCE/exe/config/mimetypemapping.ini $DIR_INSTANCE/exe/config/nameserver.ini $DIR_INSTANCE/exe/config/preprocessor.ini $DIR_INSTANCE/exe/config/scriptserver.ini $DIR_INSTANCE/exe/config/statisticsserver.ini $DIR_INSTANCE/exe/config/validmimetypes.ini数据库系统的日志文件下面的 backup log file 被完整的收集在 $DIR_INSTANCE/trace/backuplog 目录中。执行期间的 dump 信息每个 indexserver 会创建有一个包含有关于 thread，stack contexts等信息的runtime dump并保存在indexserver_runtimedump.trcSQL 连接可用的情况下收集到的额外信息下列的系统表和 monitoring view 的所有行都被导出到一个与表名有着相同名字的 CSV 文件中。 SYS.M_INIFILE_CONNECTIONS with CONNECTION_ID 0 SYS.M_INIFILE_CONTENTS SYS.M_LANDSCAPE_HOST_CONFIGUR