0x00002AAAACDE8D5D _Z26sqlbDMSAddContainerRequestP12SQLB_POOL_CBP16SQLB_POOLCONT_CBP12SQLB_GLOBALSP14SQLB_pfParIoCbbm + 0x90D PID : 10379 TID : 46912992438016 PROC : db2sysc 0ĪPPHDL : 0-4492 APPID: *LOCAL.DB2.190621005919įUNCTION: DB2 Common, OSSe, ossGetDiskInfo, probe:130ĬALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol) It completes fine on primary but standby hits exactly the error you are seeing: -03.93+120 I1774E2661 LEVEL: Error (OS) When I will run on primary: db2 "create tablespace test managed by database using (file '/db2data/testts' 100 M)" (couldn't find a "smarter" way to hit EACCES on mount info). On both primary and standby: mkdir /db2data
Db2 10.5 permissions reset db2nrupdt code#
Note this must be TSA-controlled environment for Db2 to follow sqlhaCreateMount code path (because if this will be a separate mount, Db2 will add it to the TSA resource model)
To confirm this theory I've run a quick test with Db2 11.1. If not, this implies some odd OS issue that Db2 is a victim of and we would need more OS diagnostics (e.g strace from the cat /proc/mounts command) to understand it. Work OK run as Db2 instance owner ID (db2inst1). Hence I suggest to test whether all: cat /proc/mounts When we restart the standby server problem solves but we need to drop the tablespace and recreate it, is there any idea for this problem?įrom the error it looks to me that problem is not with the file access itself but rather /proc/mounts, which Db2 uses to do the mapping between containers and filesystems (to know e.g. We can not recreate the problem sometimes this problem occur and we don't know the reason of it, but the problem remains until server reboot. The mount options are as follws: /dev/sdf1 /dbdata1 ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0 SELinux is disabled and the sector size is 512 bytes. db2inst1 is the owner of /dbdata1/samdbTsContainer and permission is drwxr-xr-x, the result of su - db2inst1 “ulimit -Hf” is unlimited and ext3 is file system type and create tablespace statement is as follows: 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
Īll settings are equivalent on the primary and standby.
Db2 10.5 permissions reset db2nrupdt free#
There is free space available for the database and the specified path (/dbdata1/samdbTsContainer) exists on the server and we can create file manually on it. "TSPKGCACH" (ID "49") because it has been put into "ROLLFORWARD Probe:4628 MESSAGE : ADM12512W Log replay on the HADR standby has (SAMDB) 0 FUNCTION: DB2 UDB, buffer pool services, sqlbIncPoolState, Then, issue another ROLLFORWARDĭATABASE command to complete recovery of this table space. Connect to the database after the rollforward operationĬompletes and use the SET TABLESPACE CONTAINERS command to assignĬontainers to the table space. Is not enough space to create the containers associated with the "TSPKGCACH" (ID = "49") could not be createdĭuring the rollforward operation. Sqlblog_reCreatePool, probe:3134 MESSAGE : ADM6106E Table space : String, 36 bytes Cluster add mount operation failed: DATA #2 : String, 37 bytes /dbdata1/samdbTsContainer/TSPKGCACH.1 DATA #3 : SqlbDMSAddContainerRequest, probe:812 MESSAGE : (SAMDB) 0 FUNCTION: DB2 UDB, buffer pool services, (SAMDB) 0 FUNCTION: DB2 UDB, high avail services, sqlhaCreateMount, (SAMDB) 0 FUNCTION: DB2 UDB, high avail services, String, 25 bytes /dbdata1/samdbTsContainer DATA #3 : unsigned integer, MESSAGE : ECF=0x90000001=-1879048191=ECF_ACCESS_DENIEDĪccess denied CALLED : OS, -, fopen OSERR: EACCES (13) DATA #1 : String, 12 bytes /proc/mounts DATA #2 : (SAMDB) 0 FUNCTION: DB2 Common, OSSe, ossGetDiskInfo, probe:130 HOSTNAME: samdb-b EDUID : 155 EDUNAME: db2redom We have Db2 10.5.0.7 on centos 6.9 and TSAMP 3.2 as our high availability solution, when we create a tablespace in primary database we encounter the following errors in the standby:
0 kommentar(er)
