在我给开发测试人员维护测试数据库的时候,我发现redo日志组只有3组,而且太小,只有50m,checkpoint老是有问题,无法切换,后来我通过给他们加多几组更大的日志组。为了使数据库日后的运行不出现日志切换不过去的问题,我自然必须把旧的几组日志删除。
首先,我新增的三组500m的日志组(原日志组大小为50m)。当我把第一个旧的日志组(50m)删除后,马上重建了一个500m的redo组1,以替换旧的日志组。当我删除redo group 2并重建一个大小为500m的日志组2回来的时候,老是报以下的错误。
ERROR at line 1:
ORA-19502: write error on file "/opt/oracle/app/oradata/yyy/xxx_data01.dbf", block number 53248 (block size=8192)
ORA-27072: File I/O error
Additional information: 4
Additional information: 53248
Additional information: 765952
当时我又是度娘又是MOS,两者的说法都是存储不足。但是我检查了一下,文件系统明明还有160G,怎么可能是存在不足呢?
我觉得不是存储的问题,既然报的是block size和number的问题,我怀疑很可能是在我删除日志文件组2,然后重建的过程中,是不是日志组里面还有数据没写入存储而导致了数据丢失,从而oracle为了保证数据的一致性,不让我重建该组。
最终,为了快速解决问题并不影响开发人员的测试,我觉得重建该数据库并给他们重新迁移数据。
当我花了几十分钟重建了数据库并迁移数据的时候,发现数据在导入的过程,当users表空间到了400m左右就再也无法读写,后台日志一直报表空间不足的错误。
后来我再次度娘和MOS,依然是每篇文章都说是因为空间不足。
最后,我仔细检查文件系统,根目录只剩了16m,还真的是因为存储不足。之前看到的160G是因为之前他们搞测试库的时候,发现了存储不足的问题,于是在/opt的下面另外挂了一个160G的文件系统,由于太隐蔽,挖了一个坑给我。
后来我把一个表空间删掉并新建到160g的目录下,把空间腾了出来,问题自然就解决了。