共计 2241 个字符，预计需要花费 6 分钟才能阅读完成。
本文丸趣 TV 小编为大家详细介绍“数据库服务器报警实例分析”，内容详细，步骤清晰，细节处理妥当，希望这篇“数据库服务器报警实例分析”文章能帮助大家解决疑惑，下面跟着丸趣 TV 小编的思路慢慢深入，一起来学习新知识吧。
报警信息是来自于一个异机备库?？梢钥吹秸馓ǚ衿骺占渲挥?300 多 G，而剩余空间只剩下了不到 30G. 所以这样一个问题就很奇怪了。
这个服务器是否很老旧，答还在报修期内，其它配置也不差，一个配置较好的服务器怎么会只有 300G 左右的存储空间。
# fdisk -l
Disk /dev/sda: 299.4 GB, 299439751168 bytes
255 heads, 63 sectors/track, 36404 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0006ca1e 然后下面就是分区的设置信息，下面的一段内容给我提了个醒。
Disk /dev/sdb: 1798.7 GB, 1798651772928 bytes
255 heads, 63 sectors/track, 218673 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00062df9
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 218673 1756490841 83 Linux
由此可见，这个服务器的存储空间不是低配的 300G，其实还有一块更大容量的盘，这个问题看来就好解释了。
那么我们就花点时间快速修复下，我看了下表，那就给 10~20 分钟的时间吧。
但是现在我只看到分区的信息，不知道现在是否已经初始化了文件系统，所以还需要确认一下才能动手。这个时候可以使用 parted 来看。
# parted /dev/sdb
GNU Parted 2.1
Using /dev/sdb
Welcome to GNU Parted! Type help to view a list of commands.
(parted) print list
Model: DELL PERC H710P (scsi)
Disk /dev/sdb: 1799GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number 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: 1799GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number 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/U02
顺势挂载新分区
mount /dev/sdb1 /home/U01 修改权限
chown -R oracle:oinstall /home/U01
chown -R oracle:oinstall /home/U02
这个时候才是真正挪动数据到新的分区，这个过程会花点时间，不过相对来说，本地的复制相对会快很多。
mv /home/U02/* /home/U01
整个过程加上拷贝文件的时间大概花了 30 分钟。很快问题就得到了修复，而回过头来，问题怎么会是现在这个情况，我想起还是以前做数据迁移的时候，发现这个服务器自带的磁盘空间不够，于是申请了一块较大容量的硬盘，但是换盘的时候我休假了，结果这个事情就一直搁置下来，数据还是一直在原来的分区存放。
所以从这个整体来看，这个问题的发生时由于一连串细小的原因导致的，各种原因最后就触发了最终的问题。
读到这里，这篇“数据库服务器报警实例分析”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注丸趣 TV 行业资讯频道。
