DB2數(shù)據(jù)庫備份中SQL2059W錯(cuò)誤如何處理

這篇文章將為大家詳細(xì)講解有關(guān)DB2數(shù)據(jù)庫備份中SQL2059W錯(cuò)誤如何處理，小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

一生產(chǎn)AIX服務(wù)器上，DB2數(shù)據(jù)庫需要備份，備份中報(bào)SQL2059W錯(cuò)誤，具體信息如下：

$ db2 backup db happydb online to /backup include logs
SQL2059W  A device full warning was encountered on device "/backup".
Do you want to continue(c), terminate this device only(d), abort the utility(t) ? (c/d/t) t
SQL2001N  The utility was interrupted.  The output data may be incomplete.

這個(gè)錯(cuò)誤提示一般跟操作系統(tǒng)關(guān)系較大，而非DB2數(shù)據(jù)庫的錯(cuò)誤。
1、檢查文件系統(tǒng)是不是大文件系統(tǒng)，是否有l(wèi)imits限制；
2、檢查目錄所在的空間是否充足；

其一

1、查看活動(dòng)的卷

# lsvg -o
rootvg

# lsvg -l rootvg
rootvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
hd5                 boot       1       2       2    closed/syncd  N/A
hd6                 paging     24      48      2    open/syncd    N/A
hd8                 jfs2log    1       2       2    open/syncd    N/A
hd4                 jfs2       1       2       2    open/syncd    /
hd2                 jfs2       40      80      2    open/syncd    /usr
hd9var              jfs2       4       8       2    open/syncd    /var
hd3                 jfs2       8       16      2    open/syncd    /tmp
hd1                 jfs2       140     280     2    open/syncd    /home
hd10opt             jfs2       16      32      2    open/syncd    /opt
lg_dumplv           sysdump    8       8       1    open/syncd    N/A
paging00            paging     50      50      1    open/syncd    N/A
lv002               jfs2       248     496     2    open/syncd    /backup

"/backup"的文件系統(tǒng)為JFS2，是支持大文件系統(tǒng)的。對(duì)于JFS文件系統(tǒng)，在大多數(shù)實(shí)例中，多個(gè)文件系統(tǒng)使用大小配置為4 MB 的公用日志。例如，在初始安裝后，根卷組中的所有文件系統(tǒng)將邏輯卷 hd8 用作公用 JFS 日志。缺省邏輯卷分區(qū)大小是 4 MB，缺省日志大小是一個(gè)分區(qū)，因此，根卷組通常包含一個(gè) 4 MB 的 JFS 日志。當(dāng)文件系統(tǒng)超過 2 GB 或使用單個(gè)日志的文件系統(tǒng)空間的總量超過 2 GB時(shí)，缺省日志大小可能不足。一般來說普通JFS支持的最大文件為2G；支持大文件的JFS為64G；JFS2支持的大文件為1T

2、檢查/etc/security/limits文件中的參數(shù)，特別注意FSIZE的值。如果出現(xiàn)備份時(shí)出現(xiàn)SQL2059W錯(cuò)誤，可以vi修改/etc/security/limits文件中的FSIZE的值為-1，注意此更改將在系統(tǒng)重新啟動(dòng)后生效。
default:
        fsize = -1
        core = 0
        cpu = -1
        data =-1
        rss = 65536
        stack = 65536
        nofiles =32768      #（-1是無限制）
        core_hard = 0
root:
nobody:
db2inst2:
        core = -1
        data = 491519
        stack = 32767
        rss = -1
        fsize = -1
        nofiles =10000
 

其二

1、查看ROOTVG有沒有剩余可擴(kuò)展的空間

# lsvg rootvg
VOLUME GROUP:       rootvg                   VG IDENTIFIER:  00c5febb00004c0000000120b573a76a
VG STATE:           active                   PP SIZE:        256 megabyte(s)
VG PERMISSION:      read/write               TOTAL PPs:      1092 (279552 megabytes)
MAX LVs:            256                      FREE PPs:       244 (62464 megabytes)
LVs:                12                       USED PPs:       848 (217088 megabytes)
OPEN LVs:           11                       QUORUM:         1 (Disabled)
TOTAL PVs:          2                        VG DESCRIPTORS: 3
STALE PVs:          0                        STALE PPs:      0
ACTIVE PVs:         2                        AUTO ON:        no
MAX PPs per VG:     32512                                    
MAX PPs per PV:     1016                     MAX PVs:        32
LTG size (Dynamic): 256 kilobyte(s)          AUTO SYNC:      no
HOT SPARE:          no                       BB POLICY:      relocatable

2、命令擴(kuò)展/backup目錄

擴(kuò)展前
# df -g /backup
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/lv002        40.00     14.85   63%     3856     1% /backup

# chfs -a size=+22G /backup
Filesystem size changed to 130023424

擴(kuò)展后

# df -g /backup
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/lv002        62.00     36.85   41%     3856     1% /backup

# lsvg -l rootvg
rootvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
hd5                 boot       1       2       2    closed/syncd  N/A
hd6                 paging     24      48      2    open/syncd    N/A
hd8                 jfs2log    1       2       2    open/syncd    N/A
hd4                 jfs2       1       2       2    open/syncd    /
hd2                 jfs2       40      80      2    open/syncd    /usr
hd9var              jfs2       4       8       2    open/syncd    /var
hd3                 jfs2       8       16      2    open/syncd    /tmp
hd1                 jfs2       140     280     2    open/syncd    /home
hd10opt             jfs2       16      32      2    open/syncd    /opt
lg_dumplv           sysdump    8       8       1    open/syncd    N/A
paging00            paging     50      50      1    open/syncd    N/A
lv002               jfs2       248     496     2    open/syncd    /backup

$ db2 backup db happydb online to /backup include logs
 
Backup successful. The timestamp for this backup p_w_picpath is : 20130307202616

再次備份，發(fā)現(xiàn)已經(jīng)成功了。

$ cd /backup
$ ls -l
total 81305984
-rw-r-----    1 db2inst2 db2grp   21463318528 Mar 07 20:32

HAPPYDB.0.db2inst2.NODE0000.CATN0000.20130307202616.001
 

經(jīng)檢查發(fā)現(xiàn)該數(shù)據(jù)庫的備份文件比較大，有21G多大。所以引起了上述SQL2059W錯(cuò)誤。

關(guān)于“DB2數(shù)據(jù)庫備份中SQL2059W錯(cuò)誤如何處理”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。