数据库导出导入后，执行计划都出问题了？

显示全部楼层 · 2012-5-14 12:35:05

SELECT count(a.id) FROM books a WHERE a.kindid = 10;

Execution Plan
----------------------------------------------------------
0SELECT STATEMENT Optimizer=CHOOSE
10 SORT (AGGREGATE)
21 TABLE ACCESS (BY INDEX ROWID) OF 'BOOKS'
32 INDEX (RANGE SCAN) OF 'SYS_KINDID' (NON-UNIQUE)

Statistics
----------------------------------------------------------

0recursive calls

0db block gets
8441consistent gets
5287physical reads

0redo size
381bytes sent via SQL*Net to client
503bytes received via SQL*Net from client

2SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)

1rows processed
=========================================
Execution Plan
----------------------------------------------------------
0SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1 Bytes=2)
10 SORT (AGGREGATE)
21 INDEX (RANGE SCAN) OF 'SYS_KINDID' (NON-UNIQUE) (Cost=4
Card=1856 Bytes=3712)

Statistics
----------------------------------------------------------

0recursive calls

0db block gets
18consistent gets
17physical reads

0redo size
380bytes sent via SQL*Net to client
503bytes received via SQL*Net from client

2SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)

1rows processed

为什么第一个执行计划中会多出
21 TABLE ACCESS (BY INDEX ROWID) OF 'BOOKS'

第二个执行计划是数据库搬迁前...
第一个是用 EXP/IMP 把用户所有数据导到新数据库后，一切都不正常了...重建了索引..还是不行...
这样搬迁后，一般都需要怎么处理，让数据库可以和原数据库性能一致？谢谢...

千问 · 2012-5-14 12:35:05

很奇怪的，这种情况一般不会发生的

千问 · 2012-5-14 12:35:05

搬迁后，是不是只要重建下索引就可以了？还需要其他什么处理吗？

千问 · 2012-5-14 12:35:05

我的数据库也搬迁过很多次，也都是用EXP/IMP的方法做的。
每次搬迁过后所有的JOB都失效的，都用DBMS包删除掉重新创建的。
关于性能方面，经过EXP/IMP操作后，数据表和索引的存储一般都会更紧凑，出现性能原因我考虑是两个方面，一方面没有考虑到存储参数，导致数据表的扩展块太小太多，导致磁盘读写的效率下降。另一方面是没有对数据表和索引做分析，使得统计数据同实际情况不符，当使用CBO（基于代价的优化）时会产生效率代下的SQL执行计划。
因此数据库搬迁时，如果操作系统、数据库版本没有变化，最好不要使用EXP/IMP的方式，使用数据库全备再恢复的方式就不会存在这些问题。

千问 · 2012-5-14 12:35:05

最初由 jiangjp2000 发布
[B]我的数据库也搬迁过很多次，也都是用EXP/IMP的方法做的。
每次搬迁过后所有的JOB都失效的，都用DBMS包删除掉重新创建的。
关于性能方面，经过EXP/IMP操作后，数据表和索引的存储一般都会更紧凑，出现性能原因我考虑是两个方面，一方面没有考虑到存储参数，导致数据表的扩展块太小太多，导致磁盘读写的效率下降。另一方面是没有对数据表和索引做分析，使得统计数据同实际情况不符，当使用CBO（基于代价的优化）时会产生效率代下的SQL执行计划。
因此数据库搬迁时，如果操作系统、数据库版本没有变化，最好不要使用EXP/IMP的方式，使用数据库全备再恢复的方式就不会存在这些问题。 [/B]

谢谢分享经验...

千问 · 2012-5-14 12:35:05

重新分析一下表与索引即可.

千问 · 2012-5-14 12:35:05

呵呵，太复杂了
其实imp之后，把table，index，index column全部重新分析一遍就好了
最初由 jiangjp2000 发布
[B]我的数据库也搬迁过很多次，也都是用EXP/IMP的方法做的。
每次搬迁过后所有的JOB都失效的，都用DBMS包删除掉重新创建的。
关于性能方面，经过EXP/IMP操作后，数据表和索引的存储一般都会更紧凑，出现性能原因我考虑是两个方面，一方面没有考虑到存储参数，导致数据表的扩展块太小太多，导致磁盘读写的效率下降。另一方面是没有对数据表和索引做分析，使得统计数据同实际情况不符，当使用CBO（基于代价的优化）时会产生效率代下的SQL执行计划。
因此数据库搬迁时，如果操作系统、数据库版本没有变化，最好不要使用EXP/IMP的方式，使用数据库全备再恢复的方式就不会存在这些问题。 [/B]

千问 · 2012-5-14 12:35:05

最初由 jiangjp2000 发布
[B]我的数据库也搬迁过很多次，也都是用EXP/IMP的方法做的。
每次搬迁过后所有的JOB都失效的，都用DBMS包删除掉重新创建的。
关于性能方面，经过EXP/IMP操作后，数据表和索引的存储一般都会更紧凑，出现性能原因我考虑是两个方面，一方面没有考虑到存储参数，导致数据表的扩展块太小太多，导致磁盘读写的效率下降。另一方面是没有对数据表和索引做分析，使得统计数据同实际情况不符，当使用CBO（基于代价的优化）时会产生效率代下的SQL执行计划。
因此数据库搬迁时，如果操作系统、数据库版本没有变化，最好不要使用EXP/IMP的方式，使用数据库全备再恢复的方式就不会存在这些问题。 [/B]

　　　如果是使用ＥＸＰ／ＩＭＰ的话，统计信息也应该一起被导入导出，为什么还要从新分析呢？

千问 · 2012-5-14 12:35:05

最初由 liuxuejunjx 发布
[B]呵呵，太复杂了
其实imp之后，把table，index，index column全部重新分析一遍就好了
[/B]
如果是使用ＥＸＰ／ＩＭＰ的话，统计信息也应该一起被导入导出，为什么还要从新分析呢？