17 个解决方案
#1
你所插入数据的那张表，是否索引过多？
如果数据量很大又有过多的索引很慢
大数据量可以把表按没个字段或几个字段分区
如果数据量很大又有过多的索引很慢
大数据量可以把表按没个字段或几个字段分区
#2
最后一句话什么意思可否说的具体点。数据量也就10W条左右吧。要插入的这个表有一个主键还有一个unique。另外，我是从一个数据库导入到另一个数据库的，在代码中是先将记录取出放到记录集中的。我想是不是如果按分页的方法，一部分一部分的分批次取到记录集中，分批地导入到目的表中，这样会改善点。但是我感觉这个数据量也不大啊。代码部分看起也不大有问题的感觉
#3
要插入的这张表的各个表很多外键是互相关联的，我插入的时候由于一些表没有数据，仅仅是插了这张表，某些外键主键是用临时的数来填充的（当然这些数都是唯一的，记录是可以插入的），是不是这些表之间的关联会导致速度越来越慢。期待高手空降中。。。。
#4
另外，我用360的流量监控软件打开发现一个现象
程序名称 上传速度 下载速度
TNSLSNR 23K/S 8.4M/S
我的程序 8.4M/S 23k/S
这个流量速度正常不正常
程序名称 上传速度 下载速度
TNSLSNR 23K/S 8.4M/S
我的程序 8.4M/S 23k/S
这个流量速度正常不正常
#5
你通过这个SQL监控下该session占用的内存是不是超过了200MB
select * FROM v$sesstat a,v$statname b WHERE a.statistic#=b.statistic# AND NAME LIKE '%mem%' and sid=<sid>
然后检查v$sort_usage表看该session是不是使用到了临时段来存储中间数据。
如果都查出结果的话，表明那条SQL已经占用太多内存，所以改用磁盘空间来读写，速度将会变慢，这时可以考虑调整_pga_max_size参数或优化sql
select * FROM v$sesstat a,v$statname b WHERE a.statistic#=b.statistic# AND NAME LIKE '%mem%' and sid=<sid>
然后检查v$sort_usage表看该session是不是使用到了临时段来存储中间数据。
如果都查出结果的话，表明那条SQL已经占用太多内存，所以改用磁盘空间来读写，速度将会变慢，这时可以考虑调整_pga_max_size参数或优化sql
#6
能否具体些楼上的，ORACLE不是太熟。另外，SID如何获取
#7
sid的定位不太容易讲清楚，你可以试着在那条SQL运行的时候执行下面语句，在得出的结果集里找一下：
select a.sid,a.sql_id,b.sql_text FROM v$session a,v$sqlarea b WHERE a.sql_id=b.sql_id
当然，更粗暴的办法是啥都不管，直接执行 alter system set "_pga_max_size"=400M,然后再运行SQL看速度有没有提高
select a.sid,a.sql_id,b.sql_text FROM v$session a,v$sqlarea b WHERE a.sql_id=b.sql_id
当然，更粗暴的办法是啥都不管，直接执行 alter system set "_pga_max_size"=400M,然后再运行SQL看速度有没有提高
#8
把你的代码扔了，改用db_link导入数据
或者直接用impdp/expdp
或者直接用impdp/expdp
#9
我在PLSQL中的SESSION中看到了这个SESSION，ID好像是138，用你第一个SQL执行看了下，结果如下
1 138 20 301852 20 session uga memory 1 1856888586
2 138 21 301852 21 session uga memory max 1 3840343119
3 138 25 640728 25 session pga memory 1 4148600571
4 138 26 5359320 26 session pga memory max 1 507777907
5 138 164 0 164 redo k-bytes read (memory) 2 399143205
6 138 166 0 166 redo k-bytes read (memory) by LNS 2 3857180019
7 138 439 0 439 workarea memory allocated 64 2433935387
8 138 462 10 462 sorts (memory) 64 2091983730
1 138 20 301852 20 session uga memory 1 1856888586
2 138 21 301852 21 session uga memory max 1 3840343119
3 138 25 640728 25 session pga memory 1 4148600571
4 138 26 5359320 26 session pga memory max 1 507777907
5 138 164 0 164 redo k-bytes read (memory) 2 399143205
6 138 166 0 166 redo k-bytes read (memory) by LNS 2 3857180019
7 138 439 0 439 workarea memory allocated 64 2433935387
8 138 462 10 462 sorts (memory) 64 2091983730
#10
分批提交，不要等10W都查完了再提交，好比1000条提交一次
#11
alter system set "_pga_max_size"=1024M
我刚才执行了这个语句，貌似效果不大。
我现在在改用分页的方法来试验下。
我刚才执行了这个语句，貌似效果不大。
我现在在改用分页的方法来试验下。
#12
把sql弄出来帮你分析分析
#13
从oracle到oracle导入，还是数据泵吧。
#14
分批提交，试试看
#15
上代码，才知道
#16
分批提交了，效果好了很多。
#17
一次提交那么多，肯定有问题！
#1
你所插入数据的那张表，是否索引过多？
如果数据量很大又有过多的索引很慢
大数据量可以把表按没个字段或几个字段分区
如果数据量很大又有过多的索引很慢
大数据量可以把表按没个字段或几个字段分区
#2
最后一句话什么意思可否说的具体点。数据量也就10W条左右吧。要插入的这个表有一个主键还有一个unique。另外，我是从一个数据库导入到另一个数据库的，在代码中是先将记录取出放到记录集中的。我想是不是如果按分页的方法，一部分一部分的分批次取到记录集中，分批地导入到目的表中，这样会改善点。但是我感觉这个数据量也不大啊。代码部分看起也不大有问题的感觉
#3
要插入的这张表的各个表很多外键是互相关联的，我插入的时候由于一些表没有数据，仅仅是插了这张表，某些外键主键是用临时的数来填充的（当然这些数都是唯一的，记录是可以插入的），是不是这些表之间的关联会导致速度越来越慢。期待高手空降中。。。。
#4
另外，我用360的流量监控软件打开发现一个现象
程序名称 上传速度 下载速度
TNSLSNR 23K/S 8.4M/S
我的程序 8.4M/S 23k/S
这个流量速度正常不正常
程序名称 上传速度 下载速度
TNSLSNR 23K/S 8.4M/S
我的程序 8.4M/S 23k/S
这个流量速度正常不正常
#5
你通过这个SQL监控下该session占用的内存是不是超过了200MB
select * FROM v$sesstat a,v$statname b WHERE a.statistic#=b.statistic# AND NAME LIKE '%mem%' and sid=<sid>
然后检查v$sort_usage表看该session是不是使用到了临时段来存储中间数据。
如果都查出结果的话，表明那条SQL已经占用太多内存，所以改用磁盘空间来读写，速度将会变慢，这时可以考虑调整_pga_max_size参数或优化sql
select * FROM v$sesstat a,v$statname b WHERE a.statistic#=b.statistic# AND NAME LIKE '%mem%' and sid=<sid>
然后检查v$sort_usage表看该session是不是使用到了临时段来存储中间数据。
如果都查出结果的话，表明那条SQL已经占用太多内存，所以改用磁盘空间来读写，速度将会变慢，这时可以考虑调整_pga_max_size参数或优化sql
#6
能否具体些楼上的，ORACLE不是太熟。另外，SID如何获取
#7
sid的定位不太容易讲清楚，你可以试着在那条SQL运行的时候执行下面语句，在得出的结果集里找一下：
select a.sid,a.sql_id,b.sql_text FROM v$session a,v$sqlarea b WHERE a.sql_id=b.sql_id
当然，更粗暴的办法是啥都不管，直接执行 alter system set "_pga_max_size"=400M,然后再运行SQL看速度有没有提高
select a.sid,a.sql_id,b.sql_text FROM v$session a,v$sqlarea b WHERE a.sql_id=b.sql_id
当然，更粗暴的办法是啥都不管，直接执行 alter system set "_pga_max_size"=400M,然后再运行SQL看速度有没有提高
#8
把你的代码扔了，改用db_link导入数据
或者直接用impdp/expdp
或者直接用impdp/expdp
#9
我在PLSQL中的SESSION中看到了这个SESSION，ID好像是138，用你第一个SQL执行看了下，结果如下
1 138 20 301852 20 session uga memory 1 1856888586
2 138 21 301852 21 session uga memory max 1 3840343119
3 138 25 640728 25 session pga memory 1 4148600571
4 138 26 5359320 26 session pga memory max 1 507777907
5 138 164 0 164 redo k-bytes read (memory) 2 399143205
6 138 166 0 166 redo k-bytes read (memory) by LNS 2 3857180019
7 138 439 0 439 workarea memory allocated 64 2433935387
8 138 462 10 462 sorts (memory) 64 2091983730
1 138 20 301852 20 session uga memory 1 1856888586
2 138 21 301852 21 session uga memory max 1 3840343119
3 138 25 640728 25 session pga memory 1 4148600571
4 138 26 5359320 26 session pga memory max 1 507777907
5 138 164 0 164 redo k-bytes read (memory) 2 399143205
6 138 166 0 166 redo k-bytes read (memory) by LNS 2 3857180019
7 138 439 0 439 workarea memory allocated 64 2433935387
8 138 462 10 462 sorts (memory) 64 2091983730
#10
分批提交，不要等10W都查完了再提交，好比1000条提交一次
#11
alter system set "_pga_max_size"=1024M
我刚才执行了这个语句，貌似效果不大。
我现在在改用分页的方法来试验下。
我刚才执行了这个语句，貌似效果不大。
我现在在改用分页的方法来试验下。
#12
把sql弄出来帮你分析分析
#13
从oracle到oracle导入，还是数据泵吧。
#14
分批提交，试试看
#15
上代码，才知道
#16
分批提交了，效果好了很多。
#17
一次提交那么多，肯定有问题！