c++ - 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 因为它可能会阻止 rowsource 操作的假脱机。在生成的跟踪文件中，您将找到被解析的确切 sql 文本、影响 sql 和行源操作的等待事件。 rowsource 操作显示运行 sql 时 sql 计划的具体情况。

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

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

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

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

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