DB2数据库备份中SQL2059W错误如何处理

发布时间:2021-11-17 11:22:51 作者:小新
来源:亿速云 阅读:137

这篇文章将为大家详细讲解有关DB2数据库备份中SQL2059W错误如何处理,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。

一生产AIX服务器上,DB2数据库需要备份,备份中报SQL2059W错误,具体信息如下:

$ 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.

这个错误提示一般跟操作系统关系较大,而非DB2数据库的错误。
1、检查文件系统是不是大文件系统,是否有limits限制;
2、检查目录所在的空间是否充足;

其一

1、查看活动的卷

# 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"的文件系统为JFS2,是支持大文件系统的。对于JFS文件系统,在大多数实例中,多个文件系统使用大小配置为4 MB 的公用日志。例如,在初始安装后,根卷组中的所有文件系统将逻辑卷 hd8 用作公用 JFS 日志。缺省逻辑卷分区大小是 4 MB,缺省日志大小是一个分区,因此,根卷组通常包含一个 4 MB 的 JFS 日志。当文件系统超过 2 GB 或使用单个日志的文件系统空间的总量超过 2 GB时,缺省日志大小可能不足。一般来说普通JFS支持的最大文件为2G;支持大文件的JFS为64G;JFS2支持的大文件为1T

2、检查/etc/security/limits文件中的参数,特别注意FSIZE的值。如果出现备份时出现SQL2059W错误,可以vi修改/etc/security/limits文件中的FSIZE的值为-1,注意此更改将在系统重新启动后生效。
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有没有剩余可扩展的空间

# 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、命令扩展/backup目录

扩展前
# 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

扩展后

# 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

再次备份,发现已经成功了。

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

HAPPYDB.0.db2inst2.NODE0000.CATN0000.20130307202616.001
 

经检查发现该数据库的备份文件比较大,有21G多大。所以引起了上述SQL2059W错误。

关于“DB2数据库备份中SQL2059W错误如何处理”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,使各位可以学到更多知识,如果觉得文章不错,请把它分享出去让更多的人看到。

推荐阅读:
  1. 在golang中怎样处理错误
  2. 如何在Vue中处理错误图片

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

db2 sql2059w 数据库

上一篇:怎么用java实现根据一个经纬度查询附近的楼盘信息

下一篇:jquery如何获取tr里面有几个td

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》