alter index 索引名 rebuild; 试一试,可能解决不了问题。 我曾碰到和你一样的情况: 在一台正常的机器上有4万条数据,用程序导入11万条后 执行select count(*) from tbl1 where .....后cpu 到100%,奇慢.用程序删掉这11万条也不管用了。 要知道这11万条在一台PC上查询很快啊 所以,我猜测是oracle内部数据出问题了,但不知道在 哪,和服务器配置、oracle参数关系不大。 后来是用原来的备份恢复,这11万条就先摆着了。等我再去导的 时候看看是什么问题。
Fixed Size 73888 bytes
Variable Size 55681024 bytes
Database Buffers 16777216 bytes
Redo Buffers 172032 bytestoad下 : db_block_buffer 8192
db_block_size 2048
实际服务器:Total System Global Area 641183420 bytes
Fixed Size 102076 bytes
Variable Size 219357184 bytes
Database Buffers 421543936 bytes
Redo Buffers 180224 bytestoad下 : db_block_buffer 51458
db_block_size 2048
sga增大了一位呢,不会是配置的问题吧?若改,该怎么改?
试一试,可能解决不了问题。
我曾碰到和你一样的情况:
在一台正常的机器上有4万条数据,用程序导入11万条后
执行select count(*) from tbl1 where .....后cpu
到100%,奇慢.用程序删掉这11万条也不管用了。
要知道这11万条在一台PC上查询很快啊
所以,我猜测是oracle内部数据出问题了,但不知道在
哪,和服务器配置、oracle参数关系不大。
后来是用原来的备份恢复,这11万条就先摆着了。等我再去导的
时候看看是什么问题。
这会有关系么?在csdn上看到一篇文章这么写:
回复人: bacer(键盘制造) ( ) 信誉:100 2002-9-14 0:02:12 得分:20
我碰到一种情况
系统运行一段时间之后(大约2周),对某张操作比较频繁的表再次操作时候就会出现90%以上的cpu占用,drop后重新建立一个就没问题了
有人说创建表时候设置free和used参数可以解决,好像还是有问题有人碰到过么?
2002-10-14 20:36:39 得分:0
CPU占用100%通常是出现在执行了一个约束不完整的查询,或者使用了NOT IN导致大量全表扫描的查询,请检查你的SQL语句
我的sql会有问题么?可是明明只要3毫秒阿
请教KingSunSha(弱水三千),能说一个例子吗
我碰到的那张表是主表,另外还有好几个
子表,中间有外键约速,是否在大量数据导入的过程中破坏了
约速条件,导入时约速会disable吗
如果排除约束的问题,那原因谁知道?
等我再去导数据的
时候看看是什么问题。
有可能其他原因造成该表破坏了
我又一次就碰到过一个,使用主键查询一条记录,结果用了老半天
后来把表drop重新创建,就没有问题了
看等待事件是什么再查一下,看有哪些锁等待db_block_buffer 这个需要增加还有就是 sqlplus 中
alter session set sort_area_size = 10240000
试一下 ?
然后再执行查询xmbh 可以尝试建立索引试一下?