Pro*C 性能差异

Question

我在以下场景中运行，这让我很头疼，因为我找不到我所看到的行为的确切解释。我声明了以下内容：

struct test_struct
{
    long testv1;
    char testv2[51];
    long testv3;
};

以及Oracle 10g中对应的表：

CREATE TABLE test_table
(
    testv1 NUMBER(10, 0),
    testv2 VARCHAR(50),
    testv3 NUMBER(4, 0)
);

要访问此表中的数据，我有一个函数：

bool getTestData(long test_var1, struct test_struct *outStruct)

在这里我看到了我需要解释但不能解释的差异。如果函数体如下所示：

EXEC SQL BEGIN DECLARE SECTION;
    long testvar1_param = test_var1;
    struct test_struct *resStruct = outStruct;
EXEC SQL END DECLARE SECTION;

EXEC SQL SELECT testv1, testv2, testv3
    INTO :resStruct
    FROM test_table
    WHERE testv1 = :testvar1_param;

如果函数的主体看起来像这样，我会得到较慢的性能：

EXEC SQL BEGIN DECLARE SECTION;
    long testvar1_param = test_var1;
    long *testv1_res = &(outStruct->testv1);
    char *testv2_res = outStruct->testv2;
    long *testv3_res = &(outStruct->testv3);
EXEC SQL END DECLARE SECTION;

EXEC SQL SELECT testv1, testv2, testv3
    INTO :testv1_res, :testv2_res, :testv3_res
    FROM test_table
    WHERE testv1 = :testvar1_param;

第二次的表现相差很大。

有谁知道什么可以解释这种行为？

Answer 1

对于乍一看无法解释的性能问题：打开包括等待在内的 sql 跟踪。

ALTER SESSION SET TRACEFILE_IDENTIFIER = "some_unique_identifier";
dbms_support.start_trace (binds=>true,waits=>true);

运行您的代码，使其提交并优雅地断开连接。不要使用 dbms_support.stop_trace，因为它可能会阻止行源操作的假脱机。 在生成的跟踪文件中，您将找到准确的 sql 文本，因为它被解析，等待影响 sql 和行源操作的事件。行源操作显示了运行 sql 时 sql 计划的准确程度。

• 检查解析次数
• 检查是否使用了绑定变量。
• 检查预期计划的行源操作。

对于您的问题 - 必须以随机方式一一获取大量行 - 我希望找到

• 1 个游标声明
• 1 次解析
• 打开/获取/关闭游标的循环

对于这些场景来说，不要解析每个选择是非常重要的。解析可能比执行花费更多时间。

剩下的一个问题是：为什么要一一获取所有行？这是某种数据复制操作吗？

Answer 2

您是否考虑了缓存的影响？我想不会。

如果您运行第一个查询定时，然后运行第二个查询定时，其中 testvar1_param 值是相同的，第二个在明显不同的时间完成。哪个查询首先运行并不重要，第二个版本会更好。

这是因为 where 谓词在两个查询中是相同的，并且结果集中的数据在两个查询中是相同的。通常后续查询相同的查询在您针对索引查询时运行得更快，因为您从不去表获取结果集，它来自缓存它的 SGA。

尝试为 testvar1_param 使用不同的值，并使用完全不同的 parm 值对每个 from 运行 10 次查询。它们会在时间上非常非常接近。

你使用的是 tkprof 对吗？

Answer 3

我的意思是时机（因为它是开发，对吗？）

ALTER SYSTEM SET TIMED_STATISTICS = TRUE;

这改进了 oracle 在性能跟踪方面为您提供的功能。