和开发同学讨论的一个技术问题(r8笔记第73天）

今天下午的时候，有一位开发同事找我，说有一个技术问题想请教一下。 当然正如他所说，这个问题比较奇怪，而且已经影响了他的测试流程，他说有一个表查看对应的表空间但是显示为空，所以插入不了数据。我们之前做过一次数据迁移，他想让我帮忙看看，能不能修改一下表空间的设置。 好了，问题到这里，看起来已经比较明显了，一个表对应的表空间是必须有的属性，所以应该不会存在为空的情况，而插入不了数据，应该和这个表空间设置没有关系，另有其他的原因，而且他说这个表里面有700多万的数据，现在只剩下90万左右，数据是怎么被清理了？ 到了这个时候，听起来有了一些头绪，当然我在19楼，他在3楼，我是不大愿意来来回回跑动，如果一两句话能解决的事情，或者远程简单支持就能搞定，就不用 那么麻烦了，所以简单聊了下，就开启了远程协助，他给我复现了问题，当然是通过plsqldev来复现的，我看到他在表对象右键属性，弹出的窗口里确实显 示表空间为空，当然到了这里，我就明白了问题的原因，这肯定是个分区表。 当然我是运行了一条sql，select * from user_tab_partitions where table_name='CLIENT_LOG'; 可以看到确实存在大量的分区信息，淡然表空间都清一色指向了同一个表空间，所以由此可以看出表空间也算是一个误导，当然从图形工具来看，也可以理解，因为分区表中含有多个分区，每个分区的表空间都可以不同，那么这个表属于哪个表空间，确实也不好说。 那么第二个问题，他说插入不了数据，原来表里的数据有几百万，现在只剩下了几十万，这个怎么来解释。如果没有头绪我可以先从系统级别入手。使用top可以 看到系统的CPU使用率极高，基本idle都是个位数，从top的命令可以看出确实存在大量的进程是CPU 100%的节奏，所以在做一些简单的查询时，也会有卡顿的情况。 我查看了v$session的情况，发现active session有100多个，而且有90%的session都卡在了同一个语句上，这个语句是delete from client_log_real这样的sql语句，一看到这个语句。就感觉很奇怪，怎么会出现如此多的active session,而且每个session都在尝试做delete操作。如果细想，这种情况的可能性也很明显，那就是这个表太大了或者执行计划出现了偏差， 导致效率低下，第一次的没有执行完成，然后第二次的又开始执行，如此反复，卡住了上百个session，当然和开发同事确认，他们有个程序是通过 crontab来触发的delete操作。而且这个表的数据也确实很多，目前是没5分钟触发一次，按照这种情况，5分钟之内还删除不了数据，而且这还是一 个全表数据删除，可见数据量应该不小，当然我在稍后进行查询，结果也吓我一跳。 SQL> select count(*)from client.CLIENT_LOG_REAL; COUNT(*) ---------- 177377492 里面竟然有多大1亿多条数据，如此看来，5分钟难怪删除不了了。 所以对于这种问题，当务之急是释放这些严重消耗资源的进程，简单做了确认，就使用awk生成了动态的删除脚本，可以看到系统的负载马上是降了下来，但是稍 后还是会继续存在这些卡住的进程。因为这种操作方式还是存在一些不严谨的地方，每次都是delete from的操作，那么每次都需要清空数据，为何不用truncate呢，就算每次清理了数据，反复delete，高水位线的影响也会越来越大。所以可以建 议他们使用delete from xxx where 带有条件的删除，或者直接使用truncatew删除。 然后是他们所说的最后一个问题，就是为什么原来里面有几百万的数据，现在只有几十万的数据，这个如果按照一般的思路还真不好判别，查看 dba_tab_modifications是一种方式，还有中方式就是查看user_tables,user_objects的信息，当然我看到这个表 的创建时间created的值是今天，也就意味着这个表在今天被重建了。这也可以作为部分数据和预期有差距的一个原因。明白了这一点后，开发同学的这几个 疑问也算是解决了，当然后续还有一些问题，也算是好好锻炼了一把优化的技巧。也基本都做了分析和定位，争取尽快得以解决。