问题标签 [sql-tuning]

I have inherited a large and slow stored procedure and it's giving me a nightmare:

I have SQL Server 2008 installed on my desktop with a copy of the production db. I am running everything from SSMS and I have tried straight SQL and SP. Time for Sp vs SQL is close enough to the same to not worry unduly about - its the time of local vs server that's concering me.

When I run the sproc "locally", it takes around 6 seconds to complete.

When I run the sproc against the server, it takes around 25 minutes to complete!!!

[Total inserts = 45,500]

I have tried to tune the SP as much as I can and avoided parameter sniffing but not sure WHY this should be SO much slower on a pretty much equivalent machine (I know SQL Server version is slightly different, but can't see whjy it would make THAT much difference?)

I know the SP isn't fantastic, but if it runs in 6 seconds locally, then its not total pants! If it took 60 seconds on the server then that would still be fine. There are 15 calls to this SP...so 15*0:06 is acceptable...15*25:00 is not!

Server has a pretty low load on it when these SP's are not running, and around 50% CPU when they are in progress (one core 100%?). Locally CPU never gets above 25%.

Apols for posting the whole SP...but can't see how else to show what its doing in case there is an option that can be set to improve things :(

我正在使用 SQL Server Profiler 来找出正在消耗 SQL 进程的进程，我发现事件类Audit Logout导致大量读取并消耗 cpu 进程。

正常吗？还是我的 SQL Server 配置有问题？

我对一个大表（超过 200 万行）进行了查询，需要大约 10 秒才能完成。有什么办法可以优化吗？查询如下：

表“ad_counts”：

date0 上的索引，但 date0 不是唯一的。

有什么想法吗？

编辑：解释：

Oracle Version: 11.1.0.7.0

我们的一个 Oracle RAC 实例中有更高的 IO 等待

一个 SQL 的执行时间较长 - 每次执行 1452.57 秒。这开始突然发生的一天。以前，查询 20k(:v4 参数) 记录最多需要 3-4 分钟

subscribeinfo 记录：5900 万（非并行）

收费记录：2k - 3k

SQL如下

选择 o.msisdn，o.spid，o.serviceid，o.ChargeReferenceID，o.channelID，o.nextchargetime，o.failtimestamp，o.lastmonfeeday，o.networkId，o.retryEndDateTime，o.trialType，o.subFlag，o .faultCode 来自 subscribeinfo o，chargerate r 其中 (o.monthbillid = :v1) and (((o.state = :"SYS_B_00") and (o.nextchargetime < :v2) and ((o.IsAutoExtend <> :"SYS_B_01 ") 或 ((o.IsAutoExtend = :"SYS_B_02") 和 (o.extendflag <> :"SYS_B_03")))) 或 (o.subFlag = :"SYS_B_04" 和 o.state = :"SYS_B_05" 和 o .retryenddatetime > :v2)) 和 (o.ChargeClassForSub = r.chargeclassidx) 和 ((r.chargemode = :"SYS_B_06" and r.activetype = :"SYS_B_07" and o.nextchargetime != :"SYS_B_08" ) 或 ( r.chargemode = :"SYS_B_09" 和 r.activetype <> :"SYS_B_10") or (r.chargemode >= :"SYS_B_11" and r.chargemode <= :"SYS_B_12" and r.basecharge >= :"SYS_B_13") or (r.chargemode = :"SYS_B_14") or (r .chargemode = :"SYS_B_15") 或 (r.chargemode = :"SYS_B_16") 和 (o.failtimestamp <= :v3) 和 (rownum <= :v4)

根据 AWR 报告 Top 5 Timed Foreground Events

直接路径读取 [平均等待时间：22 秒，%DB 时间：50.75%] DB 文件顺序读取 [平均等待时间：15 秒，%DB 时间：38.00]

我将无法发布完整的 AWR 报告，因为它受到限制。所以请询问详细信息我会发布

请在下面找到解释计划：

ID Exec Ord Operation Go To More Peek Bind Capt Bind Cost2 Estim Card LAST Starts LAST Output Rows LAST Over/Under Estimate1 PStart PStop 工作区 0 7 SELECT STATEMENT
23335 1 2577 1 6 COUNT STOPKEY [+] [+]
[+] 23335 1 2577 2 5 HASH JOIN [+] [+]
[+] 23335 20001 1 2577 8x over [+] 3 1 .. TABLE ACCESS FULL CHARGERATE [+] [+] 68 3035 1 3036 1x 4 4 .. 分区列表单 [+] 23266 25223 1 2577 10x over KEY KEY 5 3 ... 按本地索引 ROWID SUBSCRIBEINFO 访问表 [+] [+] [+]
[+] 23266 25223 1 2577 10x over KEY KEY 6 2 .... INDEX RANGE SCAN IDX_FAILTIMESTAMP_NEW [+] [+] [+] [+] 2435 1 2100765 KEY KEY

IOSTAT

Linux 2.6.16.46-0.12-smp (mdspdb01) 11/16/12

平均 CPU：%user %nice %system %iowait %steal %idle

设备：tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn

sda 5.71 39.53 121.79 665679995 2051190222

sdb 85.75 178.15 171.12 3000316741 2881953582

sdc 111.05 161.69 43.96 2723201251 740429949

我们为monthbilid、nextchargetime 和failtimestamp 字段创建了一个索引……尽管它的基数提高了1/6，但成本却增加了4-5 倍。但是oracle默认采用新索引

在 subscribeinfo(monthbillid, nextchargetime, failtimestamp) 本地表空间 IMUSE_INDEX 上创建索引 IDX_MONTHBILLQUERY；

dbms_stats.gather_index_stats('IMUSE01', 'IDX_MONTHBILLQUERY');

我们在 AWR 报告中有硬解析 = 0。我们也改变了 cursor_sharing = FORCE

现在 IO 得到控制。还是觉得，这不是根本原因。此外，我们为这个查询设置了专用实例，该查询每小时发生超过 10 次，检索 20k 条记录大约需要 100 秒。

谁能建议我是否将优化器模式作为 first_rows 或使用提示 first_rows(20000) 是否是一个好的决定。

到目前为止，我们已经禁用了 stats 作业，我们可以只为某些表或某些索引启用相同的功能吗？这可能吗？

我需要帮助来从包含一个特定对象（即产品）表和一个动态属性表的模型中查询。

假设我可以存储带有Chocolate, 等属性的 a ，也可以存储带有Price, Color,等属性Weight的 a 。 CarEngineGearsColor

在我的示例中，我有一个名为 Products 的表，其中包含以下列：

我有另一个名为dynamicAttributes以下列的表：

我从客户那里得到一个属性代码列表和一个值列表。

我可以获取每个属性的值类型（又名布尔、字符串、整数）。

从我的应用程序查询此模型的最佳选择是什么？

仅动态 sql 吗？使用 Pivot 关键字？

可以在包含大量数据的表中的 select 语句中使用的最大连接数，以便更好地获取时间（以获得更好的性能）。我的意思是，如果我有一个具有 50 个内部或左连接的 select 语句，那么拆分是否更好将 select 语句转换为具有较少连接数（4 或 5 个连接）的不同 select 语句并收集在数据集中。

我一直在解决这个问题，听到新的想法应该很高兴:)

我有一张像这样的数十亿条记录的表

以前我正在检索这样的数据

table_sp 是一个有 10k 条记录的小表（ID (int) (PK), NAME (varchar) (IX)）

@pr_id 和 @sp_names 是一列的表变量

查询非常快（大约 2-3 秒）；现在我不想区分具有不同 PR_ID 和相同 TAB_IX、TAB_ID、SP_ID 的记录

所以例如像这样的记录

应视为一。

唯一的方法似乎是做一个额外的 GROUP BY

像这样

问题在于性能，因为添加这个额外的 GROUP BY 操作看起来很痛苦。

您对改进查询有什么想法吗？

提前致谢 ：）

我需要有关附加查询的建议。该查询执行了一个多小时，并按照解释计划进行了全表扫描。我对查询调整相当陌生，并且会提出一些建议。首先，即使我使用的所有列都创建了索引，为什么还要进行全表扫描。其次，有没有可能我可以减少执行时间，所有访问的表都很大并且包含数百万条记录，即使这样我也想排除一些选项。感谢您的帮助。

询问：

查询计划：

考虑到每个表包含超过 100 列，我在上传整个表定义时受到限制。但是，请找到在 where 子句中访问的列的以下详细信息。希望这可以帮助。

我想知道在 Oracle 中将 cursor_sharing 参数设置为 "FORCE" 的权衡。因为这会尝试对任何 SQL 语句进行软解析，因此必须提高性能。但是默认值是“EXACT”，所以我想知道将其设置为 FORCE 或 SIMILAR 是否有任何危险。

我有一个从 SQL 执行时执行出色的查询。

它是表和查询之间的连接。这两个表都有近 400 万条记录。我试图提供提示的文档表上有位图索引。当我从蟾蜍看到时，解释计划确实表明他们正在帮助加入。

我提供了 2 个其他提示，看看它们是否有帮助。一种是直接路径 APPEND，另一种是利用 pda 上现有的 BTree 索引。

当对 SQL 中的替换变量运行此查询时，结果是即时的，但过程中的相同查询需要 8 秒或更长时间。

除了 DBA 尚未屈服的程序计划之外，如果有任何明显的遗漏，我可能会让您想到什么？提前致谢。

解释计划（来自 Toad 的绑定变量）

INSERT STATEMENT ALL_ROWSCost: 1,086,010 Bytes: 15,309,420 Cardinality: 364,510
11 LOAD AS SELECT TMP_SEARCH_GROSS_DOCS
10 TABLE ACCESS BY INDEX ROWID TABLE PDA Cost: 3 Bytes: 20 Cardinality: 1
9 NESTED LOOPS Cost: 1,086,010 Bytes: 15,309,420 Cardinality: 364,510
7 TABLE ACCESS BY INDEX ROWID TABLE ATTR 成本：23,893 字节：8,019,220 基数：364,510
6 位图转换为行 5 位图
或
2位图合并
1 位图索引范围扫描索引（位图） IDX_BMP_SEARCH_FN 4 位图合并
3 BITMAP INDEX RANGE SCAN INDEX (BITMAP) IDX_BMP_SEARCH_LN 8 INDEX RANGE SCAN INDEX IDX_PDA_EXP_DOC 成本：2 基数：1

基数 364,510 似乎关闭，因为该表包含 3738562 行，而对于 WHERE 中列的替换值，计数仅为 8892。

但同样，这个计划至少告诉我正在使用正确的索引，并且从 toad 编辑器运行得非常快。

PL/SQL 的实际计划仍然不可用。

不确定这是否会增加一些有价值的信息。但思想还是会编辑。谢谢