數據庫服務器報警實例分析

本文小編為大家詳細介紹“數據庫服務器報警實例分析”，內容詳細，步驟清晰，細節處理妥當，希望這篇“數據庫服務器報警實例分析”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

報警信息是來自于一個異機備庫。可以看到這臺服務器空間只有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分鐘。很快問題就得到了修復，而回過頭來，問題怎么會是現在這個情況，我想起還是以前做數據遷移的時候，發現這個服務器自帶的磁盤空間不夠，于是申請了一塊較大容量的硬盤，但是換盤的時候我休假了，結果這個事情就一直擱置下來， 數據還是一直在原來的分區存放。

所以從這個整體來看，這個問題的發生時由于一連串細小的原因導致的，各種原因最后就觸發了最終的問題。

讀到這里，這篇“數據庫服務器報警實例分析”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。