前几天时候，公司里带我做业务的导师让我到其他部门给一位开发人员解决一个DB问题，当时我是既激动又紧张，到了开发同学那，发现是一个存储过程执行有问题：

看到这个报错信息我第一个反应就是，原来是个很简单的问题，接着我人也就放松下来了，毕竟第一次让我去给别人解决问题，我要是连问题都看不懂，那可就丢人丢大了。

然后我便开始着手解决。表空间不足嘛，不外乎两个原因：要么没有开自动扩展；要么是开了自动扩展，数据文件到了最大的上限。

OK，自动扩展是开着的，那么只能是数据文件到了最大的上限，我也不太清除数据文件最大可以到多少，既然满了，那我再给表空间添加一个就是了：

然而当回车敲下去的时候，却报错了：bigfile类型表空间无法添加数据文件。

bigfile是什么鬼？从来没听说过啊，当时我就蒙逼了。

上百度查询，发现这是表空间的一种类型，只支持一个数据文件，那看来数据文件是加不上了，怎么办呢，只好给导师打电话求教，说明情况后导师接着就道出了问题的关键：bigfile类型的数据文件最大可以到T级，为什么才60多G就空间不足了？尝试resize一下增大数据文件的最大空间。

针对这个问题其实我考虑过是不是磁盘的空间不足了，想要登到OS层查看一下磁盘的使用情况，但是开发同学说他没有权限，所以我只好把这个可能暂时抛到了脑后，决定先resize一下。

几分钟的漫长等待，终于迎来了...又一次报错。

文件I/O错误？！这一下可把我吓得不轻，我不会把里面的数据给搞坏了吧？？？然后又一想，感觉应该不会，毕竟是扩空间。然而问题还要解决，开发同学提醒是否可以设小一点如70G试试，但是我想的是100G明明并没有超出最大范围却报错，可能是本身有一些问题，设小一点又有什么意义，却是已经把磁盘空间不足的这个可能不知道抛到了哪里。

再次问过导师后，我决定新建一个常规的表空间，将用户的默认改到新的表空间上，这样以后不够了可以直接加数据文件，当当当一阵操作后，成功将用户的默认都转到了新的空间，开发同学执行存储过程测试，结果...

当时我的内心是极其崩溃的，它居然还是提示原来的表空间不足！！！

然后开发的同学告诉我，有一部分数据成功插入了新的表空间，此时我已经完全不知道该怎么办了，只好让导师下来解决。

导师下来后又执行了一次resize，依旧报错，然后告诉开发：可能是磁盘的空间不足了吧，然后又详细的解释了一下，问能否登上OS查看一下，结果这次开发居然说：哦对，我好像应该能登上。

...尼玛。

登上OS查看，发现确实是因为磁盘空间不足导致的，100G的硬盘，太老了，建议申请添上一块500G的盘，然后目前还剩下几个G，resize增大了几个G先凑合用。

问题到此就算是解决完了，然而有几个问题却值得我思考：

• 为什么我早就想到了磁盘空间不足的可能，却一直不抓住它？

开发的同学说没有权限的时候，我就暂时抛开了这个可能，结果后来彻底忘记了这个可能。

这儿我起码犯了两个错误：

1. 当我开始怀疑磁盘空间不足的可能时，我没有向开发的同学很清楚的解释这个可能，也没有说明我要登录OS的目的，而是直接就问是否能登录OS，假如当时我解释清楚这个可能，并说明要求登录OS的原因，那么开发的同学即使真的没有权限，也会针对这个要求想办法，尽量满足我的需要；

2. 当我暂时抛开这个可能去尝试其他方法时，最后都纠结于其他的各种问题中，最后导致完全遗忘了它。我没有把握住问题的本质与重点，反而陷入不太相关的一些问题中不能自拔；也没有发觉各个问题之间的联系，而是纠结于单个的独立问题。比如扩容时的文件I/O错误，其实就是因为磁盘空间不足导致的。

这两个错误，一个是因为我没有意识到交流的重要性；一个是因为我缺乏冷静的分析。

我一直是一个比较话少的人，我的职业更偏向技术，也不需要太多的话，然而我却并不知道，在职场中，有效的交流是极其重要的，所幸的是，现在我知道了。

至于第二个错误，还要说到下面的第二个问题。

• 为什么我没有完全发挥出自己分析并解决问题的能力？

我可以打包票的说，如果这个问题发生在我自己的电脑上，那么我解决它是没有任何问题的。

那么问题出在哪了？

我记得当初在学习数据库时，老师曾经告诉我们：以后做为一个DBA，一定要有自信，以及很强的抗压能力，因为以后出去了可能经常会出现你一个人解决问题而身边围了一圈人看着你这种场景，通常这一圈人里还大都是领导。所以DBA一定要能扛得住这种压力，并且自信、冷静地分析问题。

当然老师说的是那种传统行业或第三方公司的情况，我所在的互联网行业像这种围一圈领导的事情还是不太可能发生的，然而这足以说明DBA必须要具备的素质，不只是专业技能。

因此导致我无法冷静分析问题的因素不外乎这么几个：

第一次被指派去独立解决问题的紧张；开发同学一直盯着我的压力；第一次在生产库上直接操作的胆怯；还有，心态从一开始就没有摆正：我给自己打上了理所当然的实习生的标签，本应该是同事我却以实习生对前辈的方式去交谈与对待。

这些都导致了我不够自信，并无法静下心来分析问题。

当然初入职场，第一次难免会这样，而我需要做的，就是摆正心态，保持自信，不断磨砺，默默成长。

我吸取了教训，并继续努力。

在给开发同学解决完那个问题几天之后，我收到了导师的一封邮件，让我再下去一趟。因为那个开发的同学已经申请了500G的硬盘，现在需要将原来的100G中的数据迁到新的硬盘中。让我去做。

其实导师是提前给我发的邮件，但是当时我没有打开邮箱，直到需要我下去做了我才知道这件事，因此当我看到邮件中的内容是让我去做迁移我又懵了。

迁移可是大动作， 需要一系列的流程，具体我就不细说了，在我们6个实习生中也不是所有人都做过迁移，我下去之后开始的一段时间真的是完全不知道该怎么做，后来只好叫了另一个做过迁移的实习生下来帮忙。她虽然做过迁移，但是也是心里没底，所以下去的时候还抱着迁移的文档。

我一直挺纳闷，为啥迁移这样的大动作会让我这个从没做过的实习生自己来做，后来又问了开发同学具体的需求，才明白，原来不是迁库的迁移，而是本地数据文件迁移。这个就简单多了，说白了就是把数据文件换个地方。

想明白后就简单多了，我们两个讨论着开始做：

总的流程就是这样，cp时耗费了一段时间，然后第三步rename时报错：

明明已经完全对照数据文件修改了目录的权限，可还是报错权限问题。

查看了总目录的权限：完全正确；数据文件的权限：完全正确。针对某些可能网上搜索，也没找出答案。

因为在迁移的过程中tablespace是offline的，所以肯定会影响业务，并且当时已经到了吃饭的点开发同学要去吃饭，所以只能再将原表空间online，导师说等回来他看一下。

是因为什么原因呢？当然是权限不对，但不是数据文件和总目录的权限，而是子目录的权限。我当时和另一个实习同学都确信已经按照原目录修改了权限，但是还是权限出了问题。因为当时我们是按照datafile的权限640修改，但目录的权限却应该是755。

我又犯了哪些错误呢？

1) 粗心

虽然如果再给我多点时间我一定能解决这个问题，但是通常职场上不会给你时间让你解决自己犯下的错误，生产上更是如此，因此最好的办法就是不犯错误。不过人毕竟不是机器，总难免不会犯错，那么退而求其次，最起码犯了错要能及时发现并改正。

然而我最大的问题就是开始不但没能发现自己改错了权限，还坚信自己改对了并且没有去检查。为什么我坚信不疑的记忆会欺骗我呢？

我曾经在网易TED演讲上看到过相关的演讲，大意就是讲人们所坚信的记忆有时也会欺骗自己。我搞不懂具体的科学原理，但是我告诉自己：当所有的可能性都排除后，请试着再怀疑一次自己深信不疑的东西。

当然这只是在解决问题的过程中犯下的错误，接下来的几个才是真正潜在的，我没有立刻意识到但却至关重要的错误：

2) 迁移操作之前也看过别人做过，另一个实习生同学也将迁移的文档分享了，但是为什么我没有及时整理，以至于需要我来做的时候我毫无准备？

我给自己找了一堆的借口，但幸好现在我意识到，这些都只是借口。

3) 没有养成一直开着邮件，或上班就打开邮件的习惯

这个看起来似乎无所谓，但实际上这是非常重要的一个习惯，就这件事而言，如果我一直开着邮件，那么我会提前收到导师的通知，可以提前准备。而且一些重要的事情或需求也都是通过邮件来传达，因为我是实习生还没怎么接触到业务，因此很难意识到这些，如果等到成为真正的员工还没有这个习惯，或许会后悔的。

不过幸好，这件事让我意识到了这一点，为时不晚。

我不知道这两件事有没有给我的导师和开发的同学留下不好的印象，总之事情已经这样了，后悔也没用，我能做的就是总结下经验教训，尽量避免，下不为例。同时努力学习，有了足以应对一切的知识与技能，做事才会有底气。

分享给大家，希望能给初入职场的同学一点启示，与大家共勉。