公司数据库有一个table数据量非常大,每年大约125G,为了提升效能,今年春节期间将次table分为12个区,依照日期分,每月一个.上班后发现一个分区分得有点问题,删除之后重新分区.10多分钟后产线反映数据库无法使用.查看数据库,发现索引失效.重新建立后OK.
查找索引失效的原因发现,原来建的index非全局索引,也不是局部索引.第一次使用分区表,还是依照正常table建立索引的方式建的,书看的不够仔细.
后来用户又反映网页不能用,发现是有个select语句跑不出来.那个select查询两张表,却用了三曾嵌套,查看执行计划,发现cost很高,修改过Sql之后解决问题.这个语句效率虽然低,但在之前的环境下不会这么慢,百思不得其解.后来又陆续发现一些效率低下的Sql,修改之后CPU的使用率从原来的70%降低到20%.
第二天晚上,用户反映修改过的那段Sql又跑不出来了,怀疑是因为索引建的有问题,既不是全局索引,也不是局部索引,决定重新建立新table取代久的table.建立好新的table, 再建立局部索引.交换table的名字,写了一个存储过程将旧表里的数据导到新表(逐步导入,产线新的数据直接进新表,不影响生产).之后产线反映正常.
过了一天,晚上3点,产线反映无法连接数据库,TNS达到限制.查看数据库进程时发现原本只要1秒就跑出来结果的select max(barcode_no) from component_old一直跑不出来,这个表原本有3亿多笔记录,转了一天的数据,转走了6000万笔,原本只需一秒,现在10多分钟都跑不出来.回想起刚开工时这个表查询是很快的,过了一天变的非常慢,明明有索引,却发生全表扫描,看来是这个表的索引出了问题.再回想standby在recover时报的数据块错误,应该是哪个文件坏了.用DBV检查了几个报有坏块的文件,有些是好的,有些是坏的.
第二天上班,将standby切换成active,使用单位反映可以连上数据库,但无法使用.再次用select max(barcode_no) from component_old,跳出一个DBF文件损坏.但用HDD检查工具没有发现坏道,说明HDD是逻辑损坏.到这里,已经完全说明查询速度慢是index文件有坏块造成,select max(barcode_no) from component_old所用的索引文件的块正好损坏,故一直跑不出结果.计划明天将DB EXP出来,IMP到一台新的DB上.