前段时间，好友王胖子问了熊熊一个问题，他们的Oracle数据库，有个主要的表空间设置的自动增长，每次增长100M，却无法满足业务需求，问了一下Oracle方面，说是自动增长的步长太小了，于是胖子在数据库里查询了一下，有了以下的问题
胖子：“熊，在么，问个问题？”
熊熊：“？ 啥问题”
胖子：“看看，我这个数据文件设置的自动增长是100M，这个步长的单位是字节么？”
熊熊：“应该不是具体的数量，我真一时想不起来单位是什么了”
胖子：“我查了一下，我这个是12800，可是除以1024的话怎么也不是100啊”
熊熊：“让我想想，谁没事关注他啊，我们平时都是如果低于20%的可用空间，就自动增加数据文件了，那个自动增长只是给自己一个心理安慰罢了”
胖子：“。。。”
这段对话以后，熊熊觉得很没面子，确实，从来没想过那么深，对于这种表空间的容量激增情况，大多数是采用再加一个数据文件，这样也能降低I/O的负载，而且，频繁的数据文件自动增长，如果步长不足，导致不能马上满足增长需求，大量的DDL请求会导致死锁，严重的话会拖垮数据库，因此基本上熊熊对表空间的增长都采用增加数据文件的方法，当然，存在即合理，既然有自动增长这个选项，肯定是有其意义的，那么到底是怎么回事呢，居然没深入研究过，丢人啊~
于是赶紧查官方文档，终于找到了答案，如下图所示
熊熊给每个表空间都设置了自动增长，分别是每次5M到10M不等，跟胖子说，我用的是10M自增长，所以每次是1280，你丫用100M，所以是12800，这样的话肯定没有说服力，从官方文档显示，这个INCREMENT_BY代表的是所需的块数，那么一个块默认是8K，这样计算就有答案了。
1280*8192/1024/1024=10M
那么胖子那边的自增长就是12800*8192/1024/1024=100M，步长为100M，这样就合理了，让胖子用alter命令重新改了步长大小，并且先再手工增加一个数据文件缓解燃眉之急。
通过这件事情，虽然不算啥大事，但是感觉，学技术应该学本质，而不只是满足于会做事，熊熊一直说技术不是重点，但是从未否认过技术不重要，这就像比如Oracle，你的RAC、DG、GC、GG、TT等安装配置弄的很熟练了，但是不了解真正的原理，不了解事务本质，出了问题，照样没法解决，然后最后的办法就是大不了重装一下。
这个事让熊熊想起了刚学计算机的时候，基本上Windows系统出点问题，就会重做系统，以至于老妈总是说，熊熊的系统很少用超过一个月，基本上老是看熊熊在装系统~
就好比是去面试，面试官问我们，备份策略如何考虑啊？通常大家应该是按照自己很熟悉的正向思维去考虑问题，但是熊熊觉得不只如此，应该透过问题本质，就是面试官问这个问题的实际含义，备份恢复是数据的重中之重，不会随便问问技术细节，而是要问到本质，熊熊感觉，应该考虑到对方的数据当量是多少？ 如何考虑备份情况，要保留多长时间，出了问题如何恢复，对业务的影响，数据是否需要审计，有没有带库，存储是否存在单点？有没有做容灾考虑，备份采用的是内置的脚本策略（比如RMAN）还是第三方工具（比如NBU、TSM），恢复的时间，操作的复杂性，模拟演练等，总之，个人认为考虑的越全面，既是对自己的面试负责，也同时让对方觉得你够专业~
通过这件小事让熊熊感觉路还很长，光能够知其然还不够，更要知其所以然，这样我们才能在工作中出现问题的时候做到不慌乱，井然有序~
一家之言，仅供参考~
本文转自bear_cat51CTO博客，原文链接：http://blog.51cto.com/bearlovecat/1154014 ，如需转载请自行联系原作者
