本博客的目的是逐步解释跟踪AMDP方法的过程，以分析性能并指出任何性能瓶颈。
需求是分析任何AMDP方法的性能，这使我们对其在模块化单元中的执行时间有一个公平的认识，例如在任何模块化单元中的后续AMDP方法调用AMDP方法。开发人员希望利用AMDP语句跟踪实用程序来满足此要求。
3.1事务SAT
SAT事务为我们提供给定事务或报表程序中处理块的性能快照。此事务提供任何给定方法、任何给定子例程或任何函数模块等的执行时间，云服务器价格，以及其占总数的百分比。随着新的代码下推技术的出现，人工智能可以做什么，越来越多的代码被下推到数据库层，我们看到AMDP方法的增加。然而，SAT事务让我们知道AMDP方法需要花费多少时间，但是它在SAT分析快照中显示为单行，云服务器好还是，并称为数据库过程（DB:Exec）。
当AMDP方法不是那么直接时，就会产生限制。如果AMDP方法本身有数千行代码，并且在一个AMDP方法中使用多个AMDP方法调用，人工智能有哪些领域，会怎么样。请看下面的屏幕截图。
您可以在这里看到一个AMDP方法CL\ U FR\天\计算=计算\U FR\天\计划在其处理过程中花费了大约28%的时间（5.2秒）。当我们看到这个AMDP方法时，我们发现它有大约1500行代码，其中包含来自with in的多个AMDP方法调用。因此，很难通过SAT结果指出性能瓶颈。
3.2事务ST05
事务ST05也是分析性能的有力工具。它提供各种跟踪，如SQL跟踪、缓冲区跟踪、RFC跟踪等来跟踪和分析结果。对于AMDP方法，SQL跟踪提供类似于SAT事务的结果。它提供了一行结果，说明此数据库过程占用了多少时间。但究竟是什么导致了这么长时间，从结果来看还不清楚。请看下面的屏幕截图。
在这里可以看到ST05跟踪还提供了AMDP方法性能的高级视图。它告诉我们大约5.3秒是AMDP方法的执行时间，但是它没有提供导致这个执行时间的任何进一步信息。
以下步骤逐步解释AMDP方法跟踪的过程：
4.1运行事务AMDP\u UTILS
此事务提供我们系统中存在的AMDP实用程序的列表。
4.2 RS\u AMDP\u STMT\u trace Report
双击RS\u AMDP\u STMT\u TRACE report name and following screen出现。
这里我们看到类似于事务ST05的自解释按钮，您可以打开和关闭AMDP语句跟踪。
单击"激活跟踪"按钮，然后运行您的事务。
一旦您的事务完成，单击"停用跟踪"按钮，然后单击"显示跟踪条目"按钮以显示跟踪结果。
在我们当前的示例中，我们看到方法CL\u FR\u DAYS\u CALCULATION=>CALC\u FR\u DAYS\u PLAN需要5.2秒。让我们用AMDP\u UTILS事务跟踪它，并尝试找出它的性能瓶颈。
步骤5.1：为当前用户激活AMDP跟踪
运行事务AMDP\u UTILS，然后选择语句RS\u AMDP\u STMT\u trace。
单击"激活跟踪"按钮。
显示确认消息，当前用户的跟踪已打开用户。
第5.2步：
现在运行事务，事务完成后，数据与大数据专业，单击"停用跟踪"按钮。
第5.3步：
现在单击"显示跟踪条目"按钮。
出现以下屏幕。
它列出事务中的所有AMDP方法调用，并显示每个AMDP方法的执行时间。一旦在这里可以看到我们的AMDP方法CL\U FR\U DAYS\U CALCULATION=>CALC\U FR\U DAYS\U PLAN\U AMDP需要5.4秒
向右滚动
我们会看到一列"Display"。我们可以针对任何特定的AMDP点击此按钮，它将显示AMDP方法中每个处理块的详细信息。
步骤5.4：
点击AMDP方法CL\U FR\U DAYS\U CALCULATION=>CALC\U FR\U DAYS\U PLAN\U AMDP前面的显示按钮
出现以下屏幕。
我们可以从这里看到，在5.4秒中，执行一个基础AMDP CL\ U FR\ U DAYS\ U CALCULATION=>CALC\ U OUTB\ U QTY\ U EXTEN时花费了3.35秒。其他AMDP的执行情况相当正常。
第5.5步：
由于我们现在知道了性能难点，我们只能将分析重点放在这个AMDP中。在分析这个AMDP CL\u FR\u DAYS\u CALCULATION=>CALC\u OUTB\u QTY\u extn之后，我们发现在它的一个SELECT查询中不必要地放入了SELECT DISTINCT。此SELECT DISTINCT导致底层SELECT查询运行缓慢。
删除此SELECT DISTINCT后，性能将大大提高。我们可以看到此更改后的统计信息。
代码更改后的AMDP跟踪：
代码更改后的SAT跟踪：
曾经可以看到性能的改进。
