我们将centos 6.9和TSAMP 3.2上的Db2 10.5.0.7作为我们的高可用性解决方案，当我们在主数据库中创建表空间时，在备用数据库中遇到以下错误：
2019-08-31-08.47.32.164952 + 270 I87056E2779级别：错误（OS） PID：4046 TID：47669095425792 PROC：db2sysc 0 实例：db2inst1节点：000 DB：SAMDB APPHDL：0-8 APPID：* LOCAL.DB2.190725231126 主机名：samdb-b EDUID：155 EDUNAME：db2redom （SAMDB）0功能：DB2 Common，OSSe，ossGetDiskInfo，探测器：130 消息：ECF = 0x90000001 = -1879048191 = ECF_ACCESS_DENIED 访问被拒绝CALLED：OS，-，fopen OSERR：EACCES（13）DATA＃1：字符串，12字节/ proc / mounts DATA＃2： 字符串，25个字节/ dbdata1 / samdbTsContainer DATA＃3：无符号整数， 8个字节
2019-08-31-08.47.32.185625 + 270 E89836E494级别：错误PID ：4046 TID：47669095425792 PROC：db2sysc 0 实例：db2inst1节点：000 DB：SAMDB APPHDL：0-8 APPID：* LOCAL.DB2.190725231126 主机名：samdb-b EDUID：155 EDUNAME：db2redom （SAMDB）0功能：DB2 UDB，高可用性服务， sqlhaGetLocalDiskInfo，探测：9433消息： ECF = 0x90000001 = -1879048191 = ECF_ACCESS_DENIED 访问被拒绝
2019-08-31-08.47.32.186258 + 270 E90331E484级别：错误PID ：4046 TID：47669095425792 PROC：db2sysc 0 实例：db2inst1节点：000 DB：SAMDB APPHDL：0-8 APPID：* LOCAL.DB2.190725231126 主机名：samdb-b EDUID：155 EDUNAME：db2redom （SAMDB）0功能：DB2 UDB，高可用性服务，sqlhaCreateMount， 探针：9746 RETCODE：ZRC = 0x827300AA = -2106392406 = HA_ZRC_FAILED“ SQLHA API调用错误”
2019-08-31-08.47.32.186910 + 270 I90816E658级别：错误PID ：4046 TID：47669095425792 PROC：db2sysc 0 实例：db2inst1节点：000 DB：SAMDB APPHDL：0-8 APPID：* LOCAL.DB2.190725231126 主机名：samdb-b EDUID：155 EDUNAME：db2redom （SAMDB）0功能：DB2 UDB，缓冲池服务， sqlbDMSAddContainerRequest，探测：812 MESSAGE： ZRC = 0x827300AA = -2106392406 = HA_ZRC_FAILED“ SQLHA API调用错误” DATA ：字符串，36字节集群添加安装操作失败：数据＃2：字符串，37字节/dbdata1/samdbTsContainer/TSPKGCACH.1数据＃3： 字符串，8字节SAMDB
2019-08-31-08.47.32.190537 + 270 E113909E951级别：错误PID ：4046 TID：47669095425792 PROC：db2sysc 0 实例：db2inst1节点：000 DB：SAMDB APPHDL：0-8 APPID：* LOCAL.DB2.190725231126 主机名：samdb-b EDUID：155 EDUNAME：db2redom （SAMDB）0功能：DB2 UDB，缓冲池服务， sqlblog_reCreatePool，探针：3134 MESSAGE：ADM6106E表空间 无法创建“ TSPKGCACH”（ID =“ 49”） 在前滚操作期间。最可能的原因是 没有足够的空间来创建与 表空间。前滚操作后连接到数据库 完成并使用SET TABLESPACE CONTAINERS命令进行分配 容器到表空间。然后，发出另一个ROLLFORWARD DATABASE命令完成此表空间的恢复。
2019-08-31-08.47.32.200949 + 270 E114861E592级别：错误PID ：4046 TID：47669095425792 PROC：db2sysc 0 实例：db2inst1节点：000 DB：SAMDB APPHDL：0-8 APPID：* LOCAL.DB2.190725231126 主机名：samdb-b EDUID：155 EDUNAME：db2redom （SAMDB）0功能：DB2 UDB，缓冲池服务，sqlbIncPoolState， 探针：4628 MESSAGE：ADM12512W HADR备用数据库上的日志重播具有 停在表空间上 “ TSPKGCACH”（ID为“ 49”），因为已将其放入“ ROLLFORWARD” 待处理”状态。
数据库有可用空间，并且服务器上存在指定的路径（/ dbdata1 / samdbTsContainer），我们可以在其上手动创建文件。 所有设置在主数据库和备用数据库上都是等效的。 db2inst1是/ dbdata1 / samdbTsContainer的所有者，权限是drwxr-xr-x，su-db2inst1“ ulimit -Hf”的结果是无限的，ext3是文件系统类型，并且创建表空间的语句如下：
CREATE LARGE TABLESPACE TSPKGCACH IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 8 K MANAGED BY DATABASE USING (FILE '/dbdata1/samdbTsContainer/TSPKGCACH.1' 5120) ON DBPARTITIONNUM (0) EXTENTSIZE 64 PREFETCHSIZE 64 BUFFERPOOL BP8KPKGCACH OVERHEAD 10.5 TRANSFERRATE 0.14 DATA TAG NONE NO FILE SYSTEM CACHING;
SELinux被禁用，扇区大小为512字节。挂载选项如下：
/dev/sdf1 /dbdata1 ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
有时无法发生该问题，我们无法重现该问题，我们不知道其原因，但是问题一直存在，直到服务器重新启动为止。 重新启动备用服务器后，问题解决了，但我们需要删除表空间并重新创建它，对这个问题有什么想法吗？
答案 0 :(得分：3)
从错误中可以看出，问题不在于文件访问本身，而在于/proc/mounts，Db2使用它来进行容器和文件系统之间的映射（例如，了解FS类型）。因此，我建议测试是否全部：
cat /proc/mounts
cat /proc/self/mounts
mount
工作正常，以Db2实例所有者ID（db2inst1）运行。如果不是这样，则意味着Db2是受害者的一个奇怪的操作系统问题，我们需要更多的操作系统诊断程序（例如，strace命令中的cat /proc/mounts）来理解它。
编辑：
为证实这一理论，我对Db2 11.1进行了快速测试。请注意，这必须是TSA控制的环境，Db2才能遵循sqlhaCreateMount代码路径（因为如果这是单独的安装，则Db2会将其添加到TSA资源模型中）
在主数据库和备用数据库上：
mkdir /db2data
chown db2v111:db2iadm /db2data
然后待命：
chmod o-rx /proc
（找不到在挂载信息上击中EACCES的“更智能”方式）。
当我在主计算机上运行时：
db2 "create tablespace test managed by database using (file '/db2data/testts' 100 M)"
它在主数据库上可以很好地完成工作，但是备用数据库恰好会遇到您看到的错误：
2019-06-21-03.00.37.087693+120 I1774E2661 LEVEL: Error (OS)
PID : 10379 TID : 46912992438016 PROC : db2sysc 0
INSTANCE: db2v111 NODE : 000 DB : SAMPLE
APPHDL : 0-4492 APPID: *LOCAL.DB2.190621005919
HOSTNAME: rhel-hadrs.kkuduk.com
EDUID : 61 EDUNAME: db2redom (SAMPLE) 0
FUNCTION: DB2 Common, OSSe, ossGetDiskInfo, probe:130
MESSAGE : ECF=0x90000001=-1879048191=ECF_ACCESS_DENIED
Access denied
CALLED : OS, -, fopen OSERR: EACCES (13)
DATA #1 : String, 12 bytes
/proc/mounts
DATA #2 : String, 8 bytes
/db2data
DATA #3 : unsigned integer, 8 bytes
1
CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol)
[0] 0x00002AAAB9CFD84B /home/db2v111/sqllib/lib64/libdb2osse.so.1 + 0x23F84B
[1] 0x00002AAAB9CFED51 ossLogSysRC + 0x101
[2] 0x00002AAAB9D19647 ossGetDiskInfo + 0xF07
[3] 0x00002AAAAC52402C _Z21sqlhaGetLocalDiskInfoPKcjPcjS1_jS1_ + 0x26C
[4] 0x00002AAAAC523C5F _Z16sqlhaGetDiskInfoPKcS0_jPcjS1_jS1_ + 0x29F
[5] 0x00002AAAAC521CA0 _Z16sqlhaCreateMountPKcS0_m + 0x350
[6] 0x00002AAAACDE8D5D _Z26sqlbDMSAddContainerRequestP12SQLB_POOL_CBP16SQLB_POOLCONT_CBP12SQLB_GLOBALSP14SQLB_pfParIoCbbm + 0x90D
[7] 0x00002AAAACE14FF9 _Z29sqlbDoDMSAddContainerRequestsP12SQLB_POOL_CBP16SQLB_POOLCONT_CBjP26SQLB_AS_CONT_AND_PATH_INFOP12SQLB_GLOBALS + 0x2D9
[8] 0x00002AAAACE0C20F _Z17sqlbDMSCreatePoolP12SQLB_POOL_CBiP16SQLB_POOLCONT_CBbP12SQLB_GLOBALS + 0x103F
[9] 0x00002AAAACDB1EAC _Z13sqlbSetupPoolP12SQLB_GLOBALSP12SQLB_POOL_CBPKciiiihiP19SQLB_CONTAINER_SPECllblsib + 0xE4C
->这是/ proc / mounts访问的问题，而不是目标路径本身，我可以在其中毫无问题地进行写操作：
[db2v111@rhel-hadrs ~]$ echo "test" > /db2data/testfile
如果这是路径访问问题：
chmod o+rx /proc
chmod a-rw /db2data
然后在待机状态下重做“ CREATE TABLESPACE”期间的错误将有所不同：
2019-06-21-03.07.29.175486+120 I35023E592 LEVEL: Error
PID : 10379 TID : 46912992438016 PROC : db2sysc 0
INSTANCE: db2v111 NODE : 000 DB : SAMPLE
APPHDL : 0-4492 APPID: *LOCAL.DB2.190621005919
HOSTNAME: rhel-hadrs.kkuduk.com
EDUID : 61 EDUNAME: db2redom (SAMPLE) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbCreateAndLockParent, probe:918
MESSAGE : ZRC=0x8402001E=-2080243682=SQLB_CONTAINER_NOT_ACCESSIBLE
"Container not accessible"
DATA #1 : <preformatted>
Failed at directory /db2data.
2019-06-21-03.07.29.175799+120 I35616E619 LEVEL: Severe
PID : 10379 TID : 46912992438016 PROC : db2sysc 0
INSTANCE: db2v111 NODE : 000 DB : SAMPLE
APPHDL : 0-4492 APPID: *LOCAL.DB2.190621005919
HOSTNAME: rhel-hadrs.kkuduk.com
EDUID : 61 EDUNAME: db2redom (SAMPLE) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbCreateAndLockParent, probe:722
MESSAGE : ZRC=0x8402001E=-2080243682=SQLB_CONTAINER_NOT_ACCESSIBLE
"Container not accessible"
DATA #1 : <preformatted>
Failed to create a portion of the path /db2data/testts2
（直接指向/ db2data的权限之后，几乎没有其他错误了）
这证明这是/ proc访问问题，您需要与操作系统团队一起对其进行调试。也许/ proc完全卸载了？
无论如何，实际的问题是db2sysc进程在EACCES上运行fopen时撞上/proc/mounts的db2sysc进程，您需要与OS团队进一步进行调试。
编辑：
在进行调试并证明错误由操作系统返回时，我们将不得不跟踪由Db2完成的open（）系统调用。 Strace可以做到，但是对于生产系统而言，开销太高了。如果您可以在系统上安装SystemTap，建议使用这样的脚本（这是基本版本）：
probe nd_syscall.open.return
{
if ( user_string( @entry( pointer_arg(1) ) ) =~ ".*mounts")
{
printf("exec: %s pid: %d uid: %d (euid: %d) gid: %d (egid: %d) run open(%s) rc: %d\n", execname(), pid(), uid(), euid(), gid(), egid(), user_string(@entry(pointer_arg(1)), "-"), returnval() )
}
}
它使用nd_syscall探针，因此即使没有内核debuginfo软件包也可以使用。您可以这样运行它：
$ stap open.stap
exec: cat pid: 24159 uid: 0 (euid: 0) gid: 0 (egid: 0) run open(/proc/mounts) rc: 3
exec: cat pid: 24210 uid: 0 (euid: 0) gid: 0 (egid: 0) run open(/proc/mounts) rc: 3
exec: cat pid: 24669 uid: 1111 (euid: 1111) gid: 1001 (egid: 1001) run open(/proc/mounts) rc: 3
exec: cat pid: 24734 uid: 1111 (euid: 1111) gid: 1001 (egid: 1001) run open(/proc/mounts) rc: -13
exec: cat pid: 24891 uid: 1111 (euid: 1111) gid: 1001 (egid: 1001) run open(/proc/self/mounts) rc: -13
exec: ls pid: 24971 uid: 1111 (euid: 1111) gid: 1001 (egid: 1001) run open(/proc/mounts) rc: -13
->在某个时候，我已经撤消了对/ proc的访问，并且打开尝试失败，并显示-13（EACCES）。您只需在看到错误并在Db2失败时查看是否记录了某些东西时在系统上启用它即可。