问题描述
嗨，汤姆，
最近，我们遇到了一些奇怪的问题，这些问题是由如下的SQL插入执行引起的（分步执行） ：
第1步：在（...），银行的数值中插入约65,000条记录；
第二步：插入到银行TMP中选择... ，插入约60000条记录；
第三步：插入银行UC
(ChkDat、AgtOrg、ChkSts、TMercId、T条款号、SRref、，
TxnAmt、ActNo、CcyCod、TTxnDt、TTxnTm、CrdNo、费用，
银行日期...)
选择/*+ use_hash(p, t) */
不同的“20151023”、t.AgtOrg、t.ChkSts、t.TMercId、t.T术语号、t.SRrefNo、t.txnamt
、t.ActNo、t.CcyCod、t.TTxnDt、t.TxnTm、t.Fee、t.TxnTm、t.CrdNo、，
t.银行日期...
来自银行TMP p、银行CHK t
其中， p.TTxnDt=trim(t.TTxnDt)和p.TTxnTm=t.TTxnTm
和t.字段1=p.TSRefNo和t.TxnAmt=p.TxnAmt
这个第3步语句插入了大约65,000行。这个步骤就是我所说的“奇怪的问题”，因为它的效率远低于我的笔记本电脑。
顺便提一下，银行UC是一个分区表，按月份划分，在这个表中大约有75万条记录。
完成该语句需要长达90秒的时间。
然后，我们将这些表应用到我的笔记本电脑上进行测试。哎呀，第3步在10秒内完成，没有任何数据缓冲区。
执行计划显示，在我们的服务器上，在我们的笔记本电脑上，在66秒内，在我们的服务器上，将在68秒内完成。两个执行计划都是这样的：
--------------------------------------------------------------------
| ID |操作|名称|行|字节|TempSpc|开销（%CPU）|时间|
--------------------------------------------------------------------
| 0 | SELECT语句| | 586 | 410K| | 5472 (1)| 00:01:06 |
1 |唯一哈希| 586 | 410K| | 5472 (1)| 00:01:06 |
|* 2 |散列连接| | 586 | 410K| 7056K| 5471 (1)| 00:01:06 |
| 3 |表访问全部|银行| 65025 | 6286K| | 1265 (1) | 00:00:16 |
4 |表访问完全|银行TMP | 58579 | 34M| 2119 (1)| 00:00:26 |
--------------------------------------------------------------------
而且，由于我们的程序每天都会删除表，因此，银行和银行的记录只有不到70000条，就在上面的3条SQL语句完成后（大约在上午5:20 ）。由于这2个表在22:00~02:00期间会自动收集表状态，因此我们使用DBMS_STATS.Lock_STATS包锁定这2个表的状态，以确保2个表在执行计划中不会是“1行”。然而，这完全没有意义。
然后我们检查了AWR报告，但在“按运行时间排列的前10个SQL顺序”中没有找到SQL语句（步骤3 ） ，尽管它花费的时间超过90秒，而且它应该在前10个SQL中排名第一。之后，我们检查了gv$sql区域和dba_hist_sql_text ，也找不到这个步骤3的SQL。但是，同一会话在同一时间内执行的其他SQL语句（经过时间少于90秒）记录在AWR报告中。
在60分钟AWR报告期间，数据库时间为24分钟。
服务器环境的效率比我的笔记本电脑低得多，而且在这种情况下没有记录执行历史，这不是很有趣吗？
我们将银行的表和银行的表保存在缓冲池中，银行的所有索引也保存在缓冲池中。不幸的是，什么都没有改变。
接下来我们应该做什么来找出问题的瓶颈，这是个问题？
任何帮助都会被感激。：)
最近，我们遇到了一些奇怪的问题，这些问题是由如下的SQL插入执行引起的（分步执行） ：
第1步：在（...），银行的数值中插入约65,000条记录；
第二步：插入到银行TMP中选择... ，插入约60000条记录；
第三步：插入银行UC
(ChkDat、AgtOrg、ChkSts、TMercId、T条款号、SRref、，
TxnAmt、ActNo、CcyCod、TTxnDt、TTxnTm、CrdNo、费用，
银行日期...)
选择/*+ use_hash(p, t) */
不同的“20151023”、t.AgtOrg、t.ChkSts、t.TMercId、t.T术语号、t.SRrefNo、t.txnamt
、t.ActNo、t.CcyCod、t.TTxnDt、t.TxnTm、t.Fee、t.TxnTm、t.CrdNo、，
t.银行日期...
来自银行TMP p、银行CHK t
其中， p.TTxnDt=trim(t.TTxnDt)和p.TTxnTm=t.TTxnTm
和t.字段1=p.TSRefNo和t.TxnAmt=p.TxnAmt
这个第3步语句插入了大约65,000行。这个步骤就是我所说的“奇怪的问题”，因为它的效率远低于我的笔记本电脑。
顺便提一下，银行UC是一个分区表，按月份划分，在这个表中大约有75万条记录。
完成该语句需要长达90秒的时间。
然后，我们将这些表应用到我的笔记本电脑上进行测试。哎呀，第3步在10秒内完成，没有任何数据缓冲区。
执行计划显示，在我们的服务器上，在我们的笔记本电脑上，在66秒内，在我们的服务器上，将在68秒内完成。两个执行计划都是这样的：
--------------------------------------------------------------------
| ID |操作|名称|行|字节|TempSpc|开销（%CPU）|时间|
--------------------------------------------------------------------
| 0 | SELECT语句| | 586 | 410K| | 5472 (1)| 00:01:06 |
1 |唯一哈希| 586 | 410K| | 5472 (1)| 00:01:06 |
|* 2 |散列连接| | 586 | 410K| 7056K| 5471 (1)| 00:01:06 |
| 3 |表访问全部|银行| 65025 | 6286K| | 1265 (1) | 00:00:16 |
4 |表访问完全|银行TMP | 58579 | 34M| 2119 (1)| 00:00:26 |
--------------------------------------------------------------------
而且，由于我们的程序每天都会删除表，因此，银行和银行的记录只有不到70000条，就在上面的3条SQL语句完成后（大约在上午5:20 ）。由于这2个表在22:00~02:00期间会自动收集表状态，因此我们使用DBMS_STATS.Lock_STATS包锁定这2个表的状态，以确保2个表在执行计划中不会是“1行”。然而，这完全没有意义。
然后我们检查了AWR报告，但在“按运行时间排列的前10个SQL顺序”中没有找到SQL语句（步骤3 ） ，尽管它花费的时间超过90秒，而且它应该在前10个SQL中排名第一。之后，我们检查了gv$sql区域和dba_hist_sql_text ，也找不到这个步骤3的SQL。但是，同一会话在同一时间内执行的其他SQL语句（经过时间少于90秒）记录在AWR报告中。
在60分钟AWR报告期间，数据库时间为24分钟。
服务器环境的效率比我的笔记本电脑低得多，而且在这种情况下没有记录执行历史，这不是很有趣吗？
我们将银行的表和银行的表保存在缓冲池中，银行的所有索引也保存在缓冲池中。不幸的是，什么都没有改变。
接下来我们应该做什么来找出问题的瓶颈，这是个问题？
任何帮助都会被感激。：)
专家解答
按占用时间计算的前SQL是基于该期间内的所有执行，而不是基于单个最长执行。如果您有大量执行数千次的次秒语句，则累计时间将比单个90秒查询还要长。
如果要确保SQL语句显示在AWR中，则可以为其设置颜色：
http://docs.oracle.com/database/121/ARPLS/d_workload_repos.htm#ARPLS69108
但是，如果要分析语句，则应该使用SQL跟踪或autotrace来执行该语句，以获取该语句的统计信息。
https://oracle-base.com/articles/misc/sql-trace-10046-trcsess-and-tkprof
如果要确保SQL语句显示在AWR中，则可以为其设置颜色：
http://docs.oracle.com/database/121/ARPLS/d_workload_repos.htm#ARPLS69108
但是，如果要分析语句，则应该使用SQL跟踪或autotrace来执行该语句，以获取该语句的统计信息。
https://oracle-base.com/articles/misc/sql-trace-10046-trcsess-and-tkprof
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
