2

我在我的应用程序中使用 Sybase 15，并且存在与嵌套连接相关的性能问题。我有存储过程，它从 2 个表中选择 2 列，并比较这 2 个表之间超过 10 列的相等性。但是当我运行这个存储时。proc.，结果需要 40 分钟。我在我的 proc 顶部添加了“set merge-join off”语句，然后结果需要 22 秒。但我需要另一种解决方案。我之前使用的是 sybase 12.5，没有任何类似的问题，我的 proc 需要 3 分钟才能得到结果。

我将服务器配置与 sp_configure 进行了比较，介于 15 和 12.5 之间，并且 sybase15 服务器配置（I/O 和内存配置设置）大于 sybase12.5 服务器。

Info: sybase15 位于pc 的系统资源非常好。

4

4 回答 4

4

和其他人一样，我有同情而不是真正的答案！我们看到一个问题，ASE 15 查询计划器大大低估了表扫描的成本，同样高估了使用聚集索引的成本。这导致合并连接成为建议的计划。禁用合并连接或设置 allrows_oltp optgoal有时会产生更好的查询计划。估计的成本还有很长的路要走，但是通过从表中删除一个选项，查询规划器可能会找到一个好的解决方案——尽管是通过错误的分析。

ASE 15 文档说它有一套更简洁的算法，而 ASE 12 规划器有很多特殊情况。也许一个特例说“如果你在连接中有聚集索引列，它会比表扫描更快”不会是一个坏主意...... :(

于 2009-10-20T03:26:21.573 回答
2

我刚刚花了 14 个小时来调试由于周末迁移 Sybase 15 引起的关键性能问题。

查询优化器一直在（对我们）做出一些非常奇怪的决定。

举个例子，

select a, b, c from table1, table2, table3 where ...

相对

create table #temp (col1 int, col2 int, ... etc)

insert #temp
select a, b, c from table1, table2, table3 where ...

我们及时进行了第一次运行，尽管进行了大量的返工，但无法让它在第二次做出正确的决定。我们甚至将查询拆分为临时表，但仍然得到不寻常的结果。

最后，我们求助于SET FORCEPLAN ON一些查询 - 这是在我们的 DBA 和 Sybase 上线 10 小时之后。该解决方案也来自应用程序开发人员，而不是来自 Sybase 工程师的任何建议。

所以为了节省一些时间，走这条路是我的建议。

于 2009-10-12T21:35:51.663 回答
1

Sybase 有效地重写了版本 15 的查询引擎，这意味着在 12.x 上运行超快的查询在新版本上可能运行得更慢，反之亦然。对此进行调试的唯一方法是将 12.x 查询计划与 15 查询计划进行比较，看看有什么不同之处。

于 2009-10-11T22:31:35.367 回答
1

每个关心这个问题的人都应该阅读这个文档：

http://www.sybase.com/files/White_Papers/ASE15-Optimizer-Best-Practices-v1-051209-wp.pdf

它有一个关于从 Sybase 12 迁移到 Sybase 15 的坦率警告。

报价：

...不要将 ASE 15 视为“只是另一个版本”。尽管我们想说的是，您可以简单地升级并将应用程序指向升级后的服务器，但数据库最基本领域之一的更改深度和广度，即查询执行，需要更集中的测试方案。本文旨在为您提供明确的事实和最佳实践，以尽可能地减少这项工作。

它继续讨论新的 ASE 15 查询优化器、相对于 OLTP 查询和 DSS（决策支持系统）查询。

不过，有个好消息：2009 年 3 月，Sybase 15.0.3 引入了兼容模式。请参阅以下文档：

http://www.sybase.com/detail?id=1063556

With this mode, you need not analyze queries to decide if they fit OLTP or DSS profiles.

于 2010-09-29T00:09:37.097 回答