oracle 11g 插入数据，查询数据很慢，该如何查看，在线等。

Question

各位大牛，需要看哪些数据，我这里可以远程采集。如下有部分数据，麻烦各位帮忙分析下。
oracle@report:/oracle/app/admin/ora11g1/adump> toptop - 14:44:08 up 223 days,  3:58,  4 users,  load average: 2.34, 2.72, 3.04
Tasks: 387 total,   2 running, 385 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.8%us,  0.4%sy,  0.0%ni, 90.9%id,  6.8%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  24532420k total, 24392840k used,   139580k free,   219724k buffers
Swap: 25173812k total,  2095320k used, 23078492k free, 18888896k cached  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                
27947 oracle    15   0 11.9g 252m 250m R   71  1.1   0:01.47 oracle                                                                 
19112 oracle    15   0 11.9g 876m 864m D   12  3.7   0:09.97 oracle                                                                 
14391 root      16   0  2664  376  324 S    8  0.0   1067:57 guard-userspace                                                        
    1 root      16   0   796   76   40 S    0  0.0  63:26.53 init                                                                   
    2 root      RT   0     0    0    0 S    0  0.0   0:08.29 migration/0                                                            
    3 root      34  19     0    0    0 S    0  0.0   0:00.09 ksoftirqd/0                                                            
    4 root      RT   0     0    0    0 S    0  0.0   0:05.98 migration/1                                                            
    5 root      34  19     0    0    0 S    0  0.0   0:00.18 ksoftirqd/1                                                            
    6 root      RT   0     0    0    0 S    0  0.0   0:05.36 migration/2                                                            
    7 root      34  19     0    0    0 S    0  0.0   0:16.19 ksoftirqd/2                                                            
    8 root      RT   0     0    0    0 S    0  0.0   0:05.93 migration/3        
--------------------------------------------------------------------------------SQL> select MAX_UTILIZATION,INITIAL_ALLOCATION from v$resource_limit;MAX_UTILIZATION INITIAL_ALLOCATION
--------------- ----------------------------------------
            150        150
            170        170
            262       2460
            158        968
              0          0
              0          0
              0          0
              0          0
              0          0
              0          0
              0          0MAX_UTILIZATION INITIAL_ALLOCATION
--------------- ----------------------------------------
              0          0
              0          0
             16        748
             19  UNLIMITED
     4294967295        187
              0        187
              5        187
             36        187
             24  UNLIMITED
              0        340
              1  UNLIMITEDMAX_UTILIZATION INITIAL_ALLOCATION
--------------- ----------------------------------------
            129        120
------------------------------------------------------------------------------------
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             125.00         0.00      1656.00          0       1656
sdb               0.00         0.00         0.00          0          0
sdc               0.00         0.00         0.00          0          0
sdd             576.00    163256.00         0.00     163256          0
VxVM19000         0.00         0.00         0.00          0          0
VxVM30000        47.00     23272.00         0.00      23272          0
VxVM30001        95.00     42560.00         0.00      42560          0
VxVM30002        84.00     32280.00         0.00      32280          0
VxVM30003        84.00     32280.00         0.00      32280          0
VxVM30004        76.00     33376.00         0.00      33376          0
VxVM30005         0.00         0.00         0.00          0          0
VxVM30006         0.00         0.00         0.00          0          0
VxVM30007         0.00         0.00         0.00          0          0
VxVM30008         0.00         0.00         0.00          0          0
VxVM30009         0.00         0.00         0.00          0          0
VxVM30010         0.00         0.00         0.00          0          0
VxVM30011         0.00         0.00         0.00          0          0
VxVM3             0.00         0.00         0.00          0          0Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             138.61         0.00      2035.64          0       2056
sdb               0.00         0.00         0.00          0          0
sdc               1.98         0.00        15.84          0         16
sdd             748.51    173124.75       823.76     174856        832
VxVM19000         0.00         0.00         0.00          0          0
VxVM30000        94.06     21520.79       380.20      21736        384
VxVM30001        97.03     38455.45       142.57      38840        144
VxVM30002       122.77     45370.30       110.89      45824        112
VxVM30003       109.90     30154.46        39.60      30456         40
VxVM30004       112.87     37330.69       110.89      37704        112
VxVM30005         1.98         7.92         7.92          8          8
VxVM30006         1.98         7.92         7.92          8          8
VxVM30007         1.98         7.92         7.92          8          8
VxVM30008         1.98         7.92         7.92          8          8
VxVM30009         1.98         7.92         7.92          8          8
VxVM30010         0.00         0.00         0.00          0          0
VxVM30011         0.00         0.00         0.00          0          0
VxVM3             1.98         0.00        15.84          0         16

Answer 1

oracle@report:/oracle/app/admin/ora11g1/adump> free -m
             total       used       free     shared    buffers     cached
Mem:         23957      23826        131          0        212      18606
-/+ buffers/cache:       5007      18949
Swap:        24583       2046      22537

Answer 2

查询数据很慢，应该首先说明是如何查询数据的，SQL语句是什么，表结构是什么，数据库版本是什么，执行计划是什么，SQL执行要多长时间，表数据量大小多少，系统硬件结构如何等。你的问题是什么你都没有描述清楚，就贴出一堆数据。这样的话别人也没办法帮你做分析。

Answer 3

1.插入数据，为什么说是查询很慢？2.你给一堆 额外的信息，主要的信息不给出来? sql和执行计划，数据量大小和索引情况

Answer 4

sql语句有很多，因为是报表数据仓库，实时入库数据，凌晨生成报表。存储过程好几十个。数据库版本是Oracle11.1，24G内存，200W用户，sql执行时间的话，用查询来看，查询100条数据都要1分钟左右。我这里有一份awr日志，貌似没上传的选项。

Answer 5

1. 这个插入数据，我按照和其他局点的对比，慢太多了。查询也一样，100条数据，要查询1分钟左右2. 插入的数据是实时插入的，一次插入的数据不会很多，应该是10W以内，sql比较多，因为是通讯话单，一线没有索引。AWR日志到是有，貌似不能上传

Answer 6

你这个是整个系统性能的分析了，而不是某条SQL语句的问题了。上传AWR报告可以通过网盘，然后分享链接到这里的方式完成。

Answer 7

公司网络只能上这种it网站，网盘上不了。我上传到itpub上面了。我贴个链接出来，大家帮忙分析下，我对awr日志不熟悉。谢过了
http://www.itpub.net/forum.php?mod=viewthread&tid=1786715&page=1#pid21384554
你这个是整个系统性能的分析了，而不是某条SQL语句的问题了。上传AWR报告可以通过网盘，然后分享链接到这里的方式完成。

Answer 8

通过 set timing on;设置查看执行花费时间，如果熟读面一般考虑使用存储过程；至于存储过程的优化要看具体情况了...

Answer 9

感谢建议。不过因为是数据仓库，有实时数据入库，存储过程比较多。好几十个，sql都不复杂的，比较简单的汇总，逻辑运算而已。只是数据库很慢，不管是插入数据，运行sql，查询数据，都比较慢。
你可以在itpub 上看我发的awr报告，在10楼
http://www.itpub.net/forum.php?mod=viewthread&tid=1786715&page=1#pid21384554

Answer 10

从AWR报告来看，应该是重做日志的频繁切换导致数据库出现严重等待。应该是做了大量的INSERT,UPDATE操作，且频繁的提交导致。根据楼主所说是报表数据仓库，建议不做归档日志，增加重做日志文件组和重做日志文件大小。另外，还发现了UNDO的写入和使用很高，适当增加UNDO的空间大小，以满足DML大数据量操作的需要。最后，能够对SQL语句进行一次全方位的检查，避免频繁的提交，应该根据数据量选择批量提交，减少重做日志的切换和检查点的发生。

Answer 11

感谢哥们回复，因为有实时数据入库，所以一直有insert 和 commit操作，sql语句比较多，有很多数据需要实时入库，批量提交不好实现。生产库上的数据，应该还是要归档的。上次增加了缓冲区的大小，但还是慢

Answer 12

环境上已经有6组redo file，默认的1  2 3  ，每个redo日志文件有50M，新增了3个，每个redo文件有500M，这个是之前就加好的，但还是慢。

Answer 13

那这个就是要看你们怎么协调了，因为显然问题是出现在重做日志上面，1秒钟产生3.2GB的重做日志，现在你所有的重做日志加起来才多大？然后频繁的提交，重做日志还在归档，又请求重做日志空间，这就是典型的log file switch (checkpoint incomplete)。建议你把6个重做日志每个至少设置为2G，但是你这么大空间的重做日志一旦要写入到归档日志也需要很长时间，这就是我建议你不做归档的原因。另外，实时入库和批量提交并不冲突，不知道楼主为什么说不好实现？调整重做日志是治标不治本，关键还是要检查SQL数据量大要有对应的插入更新策略

Answer 14

不好意思哈，这么久才回，一秒钟产生3MB的重做日志吧，你是不是看错了位数了呀。3,241,497.3，因为有其他很多点也用的是类似一样的sql，速度比这个快得多。完全不在一个档次。实时入库是有一批话单过来了之后，我们这边就入库，然后提交了。
那这个就是要看你们怎么协调了，因为显然问题是出现在重做日志上面，1秒钟产生3.2GB的重做日志，现在你所有的重做日志加起来才多大？然后频繁的提交，重做日志还在归档，又请求重做日志空间，这就是典型的log file switch (checkpoint incomplete)。建议你把6个重做日志每个至少设置为2G，但是你这么大空间的重做日志一旦要写入到归档日志也需要很长时间，这就是我建议你不做归档的原因。另外，实时入库和批量提交并不冲突，不知道楼主为什么说不好实现？调整重做日志是治标不治本，关键还是要检查SQL数据量大要有对应的插入更新策略

Answer 15

哦，是的，算错了，那现在调整了重做日志之后还很慢么？有最新的AWR报告么？你的慢是指入库的时候慢还是查询慢还是不管什么操作都慢？

Answer 16

Mem:  24532420k total, 
      24392840k used,
Swap: 25173812k total, 
       2095320k used,内存太紧张了。 up 223 days,
都跑了两百多天了，可以在业务非高峰起把服务器重启一下整个重启一下。

Answer 17

最近加班，不好意思哈，没时间回，最新的awr日志在：http://www.itpub.net/thread-1786715-1-1.html，第17楼，有修改前和修改后的，就增加了redo log 的大小。

Answer 18

查看了调整redo log之后，出现local write wait等待事件比较严重，建议检查应用是否存在一些truncate table语句的？通常是由于truncate才会出现这样的等待。若是存在，建议查看相关的table的定义，并且贴出来看看。并且建议打开10046事件看看ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';