共计 3130 个字符，预计需要花费 8 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 DB2 数据库备份中 SQL2059W 错误如何处理，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
一生产 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 错误如何处理”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
