一个细小的空间问题触发的报警(r11笔记第68天)
公众号:杨建荣的学习笔记 · 作者:杨建荣 · 发布:2017-02-07 22:42:50 · 原文链接
今天有一个数据库服务器报警,报警信息是来自于一个异机备库。可以看到这台服务器空间只有300多G,而剩余空间只剩下了不到30G.所以这样一个问题就很奇怪了。
这个服务器是否很老旧,答还在报修期内,其它配置也不差,一个配置较好的服务器怎么会只有300G左右的存储空间。
# fdisk -lDisk /dev/sda: 299.4 GB, 299439751168 bytes255 heads, 63 sectors/track, 36404 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0006ca1e然后下面就是分区的设置信息,下面的一段内容给我提了个醒。
Disk /dev/sdb: 1798.7 GB, 1798651772928 bytes255 heads, 63 sectors/track, 218673 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisk identifier: 0x00062df9 Device Boot Start End Blocks Id System/dev/sdb1 * 1 218673 1756490841 83 Linux
由此可见,这个服务器的存储空间不是低配的300G,其实还有一块更大容量的盘,这个问题看来就好解释了。
那么我们就花点时间快速修复下,我看了下表,那就给10~20分钟的时间吧。
但是现在我只看到分区的信息,不知道现在是否已经初始化了文件系统,所以还需要确认一下才能动手。这个时候可以使用parted来看。
# parted /dev/sdbGNU Parted 2.1Using /dev/sdbWelcome to GNU Parted! Type 'help' to view a list of commands.(parted) print list Model: DELL PERC H710P (scsi)Disk /dev/sdb: 1799GBSector size (logical/physical): 512B/512BPartition Table: msdosNumber Start End Size Type File system Flags 1 32.3kB 1799GB 1799GB primary ext3 boot....确认后目前还没有初始化数据,那么我所做的工作就可以改进了,ext3是很早之前的设置,我们最起码得ext4,或者xfs,但是现在的配置我们使用df -T查看目前都是ext4,所以为了统一,还是保守设置为了ext4.
重新格式化一下。
# mkfs -t ext4 /dev/sdb1然后使用parted查看,信息就一目了然了。
Model: DELL PERC H710P (scsi)Disk /dev/sdb: 1799GBSector size (logical/physical): 512B/512BPartition Table: msdosNumber Start End Size Type File system Flags 1 32.3kB 1799GB 1799GB primary ext4 boot这个时候有个脑筋急转弯就需要我来做了。目前根目录/下有一个U01的软链接 指向/home/U01,也就意味着目前的数据都是从/home目录下取得,换句话说就是从根目录下取得的。
我们新设置了分区,就需要把数据挪过区,怎么尽可能平滑的挪动呢,我们要保持/U01的软链接不动。
首先停止异机备库的数据库服务和监听
创建一个U01的目录来切换。mkdir /home/U02
移花接木
mv /home/U01/* /home/U0
顺势挂载新分区
mount /dev/sdb1 /home/U01修改权限
chown -R oracle:oinstall U01chown -R oracle:oinstall U02
这个时候才是真正挪动数据到新的分区,这个过程会花点时间,不过相对来说,本地的复制相对会快很多。
mv /home/U02/* /home/U01
整个过程加上拷贝文件的时间大概花了30分钟。很快问题就得到了修复,而回过头来,问题怎么会是现在这个情况,我想起还是以前做数据迁移的时候,发现这个服务器自带的磁盘空间不够,于是申请了一块较大容量的硬盘,但是换盘的时候我休假了,结果这个事情就一直搁置下来, 数据还是一直在原来的分区存放。
所以从这个整体来看,这个问题的发生时由于一连串细小的原因导致的,各种原因最后就触发了最终的问题。
