监控发现数据库服务器I/O比较高,查询发现一条占用I/O相对很高的SQL。
1 | delete from IVL_DEBUG.MED_BRD_PGM_VOD; |
这条SQL每十分钟执行一次,提交给开发人员,既然是全表删除,让他改成truncate,不要用delete,但开发人员很强势,老子一次就删2万多条数据,怎么会占你I/O。
在下治好低头哈腰的给他解释了半天,delete是不会回收空间的,咱们数据库的表空间很充足,数据文件还自动扩展,你用delete删除数据之后,这部分空间虽然被置成可用状态了,但表空间充足的情况下,并不会被使用,这样这张表就会越删越大,你虽然只删除2万多条数据,但是这SQL要走全表扫描。
也不知道他是真不懂还是装糊涂,只好给他看数据了,我查了下表大小,将近12GB。
1 | SQL> select bytes/1024/1024/1024 from dba_segments where segment_name='MED_BRD_PGM_VOD'; |
查询发现,这张表的确就6万多条数据。
1 | SQL> select count(*) from IVL_DEBUG.MED_BRD_PGM_VOD; |
查询这张表上并没有索引。
1 | SQL> select index_name from dba_indexes where table_name='MED_BRD_PGM_VOD'; |
通过move命令清理这张表的碎片。
1 | SQL> alter table IVL_DEBUG.MED_BRD_PGM_VOD move; |
再次查询,这张表的大小变成正常大小,仅有4MB。
1 | SQL> select bytes/1024/1024 from dba_segments where segment_name='MED_BRD_PGM_VOD'; |
给他看了这些数据,然后根据数据和他解释,这张表,2万多条的记录,正常就不到4MB,就算是4MB,你delete一次,删除了4MB的数据,但是这4MB的空间不会被利用,比如下次又进来4MB数据,这张表就变成了8MB,你再用delete删除这张表的所有数据,虽然你只删2万多条,4MB的数据,但是数据库由于全表扫描,要读8MB的磁盘,下次就是12MB,表会越来越大。就像之前那表已经12GB了,你一次虽然只删除2万多条数据,但是数据库要读12GB的磁盘,就占用了大量的I/O。
原文地址:http://www.dbdream.com.cn/2018/03/15/oracle%E6%95%B0%E6%8D%AE%E5%BA%93%E9%A2%91%E7%B9%81delete%E5%AF%BC%E8%87%B4%E8%A1%A8%E7%A2%8E%E7%89%87%E6%A1%88%E4%BE%8B/