使用 Dapper 和 Oracle 的奇怪 SQL 性能问题答案

【问题标题】：Strange SQL performance issue using Dapper & Oracle使用 Dapper 和 Oracle 的奇怪 SQL 性能问题
【发布时间】：2016-05-18 11:23:03
【问题描述】：

我在 Dapper 度过了愉快的时光，并且没有遇到任何真正的问题，这让我发疯了。

鉴于此对包内的 Oracle 方法的调用

begin
  package.method(in_table => :in_table,
                 in_clob_type => :in_clob_type,
                 out_error_table => :out_error_table);
end;

来自 PL/SQL 开发人员或任何其他需要的 Oracle 工具大约2秒运行。
从标准 C# 控制台测试应用程序中大约需要。 2-3 秒。
从 IIS 托管的 WebAPI 应用程序中，它大约需要。 10-12 秒。

相同的 SQL，相同的参数，相同的数据库和相同的用户。应用程序中的所有其他 SQL 都可以完美运行

var errorTable = string.Empty;
var parameters = new DynamicParameters();

parameters.Add("in_table", "table-name");
parameters.Add("in_clob_type", 0);
parameters.Add("out_error_table", dbType: DbType.String, size: 32, direction: ParameterDirection.Output);

db.Query("package.nethod", parameters, commandType: CommandType.StoredProcedure);

// Query or Execute makes no difference
// db.Execute"package.nethod", parameters, commandType: CommandType.StoredProcedure);

errorTable = parameters.Get<string>("out_error_table");

有人对调试此问题的最佳方法有任何想法吗？

更新 1：

WebAPI 和控制台代码都为包函数中的插入和更新过程生成 1708 条不同的 SQL 语句。 SQL 调用之间只需要更长的时间，但我还看不到模式。

更新 2：

深入挖掘，而不是我的代码，所以它需要更长的时间，发现一个调用创建一些临时表，我们将流程所需的数据加载到其中。如果我将此注释掉并仅提供现有的表名，则需要 2-3 秒。

表创建过程中的某些东西似乎阻塞了其余的过程？如果我将所有方法标记为 PRAGMA AUTONOMOUS_TRANSACTION 10-12 秒。如果我在特定或共享事务中创建表，则需要 10-12 秒。如果我在没有事务的情况下创建它们 10-12 秒。

【问题讨论】：

在报告 10-12 秒时，您是只计算 Dapper 代码的执行时间，还是整个 WebAPI 调用的时间？
在实际 db.Query 或 Execute 调用之前和之后直接使用秒表对象。
你也在使用 dapper 的控制台应用程序？查询有多复杂？
我实际上有一个非常相似的问题，但不是包或 dapper。从 toad 运行查询大约需要 1 秒，但从 web 应用程序运行它很容易 20。我注意到，当我们稍微更改查询时，它会在 web 应用程序中运行一次很快，然后又回到慢速运行。事实证明，查询优化器使其运行速度变慢。插入： /*+ OPT_PARAM('_OPTIMIZER_USE_FEEDBACK' 'FALSE') */ 在查询中，它突然与网络应用程序和 toad 一致。可能不是您的问题，但不妨试一试。
您能否在您的数据库上设置一些跟踪，以确认在两个应用程序中生成的 SQL 是相同的？ See here 获取一些设置解决方案。

标签： c# oracle11g ado.net dapper

【解决方案1】：

我无法弄清楚为什么表格创建会导致流程中的任何延迟，事实上，鉴于表格的非常简单的性质，我看不出有任何可能的方式，所以我采取了不同的方式方向。

我没有在用户架构中创建临时表，而是将这些表创建为标记为 ON COMMIT DELETE ROWS 的全局临时表。

现在一切都按预期在 2 秒或更短的时间内运行 :-)

感谢您的所有帮助，如果您对延迟有任何想法，请随时分享。

【讨论】：