|
Problem IC67172
|
Status: Closed |
DATABASE RESTART SHOWS SQLO_ACCD "ACCESS DENIED" ERRORS WITH LOGARCHMETH1 SET TO non DISK like TSM:MGMTCLASS |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
If we have the following setting in Logarchmeth1
TSM:MCA_DWH_LOGS1
being MCA_DWH_LOGS1 the TSM Management Class for archiving logs,
on database restart we might experience the following errors if
we previously crashed with open transactions and the database
was left in an inconsistent state:
2010-01-27-11.55.22.589466+060 E209394A896 LEVEL: Error
(OS)
PID : 4075576 TID : 2830 PROC : db2sysc
5
INSTANCE: db2001dw NODE : 005 DB :
DWH00001
APPHDL : 5-51 APPID: *N5.db2001dw.100127105522
AUTHID : DB2001DW
EDUID : 2830 EDUNAME: db2agent (DWH00001) 5
FUNCTION: DB2 UDB, oper system services, sqlomkdirp, probe:10
MESSAGE : ZRC=0x840F0001=-2079391743=SQLO_ACCD "Access Denied"
DIA8701C Access denied for resource "", operating
system return code
was "".
CALLED : OS, -, mkdir
OSERR : EACCES (13) "Permission denied"
DATA #1 : File name, 21 bytes
MCA_DWH_LOGS1db2001dw
DATA #2 : signed integer, 4 bytes
488
DATA #3 : signed integer, 4 bytes
488
DATA #4 : String, 105 bytes
Search for ossError*Analysis probe point after this log entry
for further
self-diagnosis of this problem.
2010-01-27-11.55.22.590669+060 I210291A1688 LEVEL: Error
(OS)
PID : 4075576 TID : 2830 PROC : db2sysc
5
INSTANCE: db2001dw NODE : 005 DB :
DWH00001
APPHDL : 5-51 APPID: *N5.db2001dw.100127105522
AUTHID : DB2001DW
EDUID : 2830 EDUNAME: db2agent (DWH00001) 5
FUNCTION: DB2 Common, OSSe, ossErrorIOAnalysis, probe:100
CALLED : OS, -, mkdir
OSERR : EACCES (13) "Permission denied"
DATA #1 : String, 119 bytes
A total of 2 analysis will be performed :
- User info
- Path access permission
Target file = MCA_DWH_LOGS1db2001dw
DATA #2 : String, 188 bytes
Real user ID of current process = 1010
Effective user ID of current process = 1010
Real group ID of current process = 1004
Effective group ID of current process = 1004
DATA #3 : String, 209 bytes
Information of each subdirectory leading up to the first
inaccessible one is shown in the format below :
<UID>:<GID>:<permissions> (subdirectories)
Cannot descend any further than the above subdirectory.
CALLSTCK:
[0] 0x090000000ACACEFC pdOSSeLoggingCallback + 0x34
[1] 0x0900000007D1F424 oss_log__FP9OSSLogFacUiN32UlN26iPPc +
0x1C4
[2] 0x0900000007D1F900 ossLogSysRC + 0xA0
[3] 0x0900000007D3F08C
ossErrorIOAnalysis__FCPC21OSSErrorAnalysisParam + 0xC4C
[4] 0x0900000007D41108 ossErrorAnalysis@AF12_1 + 0x48
[5] 0x090000000CA9D52C sqloSystemErrorHandler + 0x54
[6] 0x090000000D5945C0 sqloSystemErrorHandler@glue7A9 + 0x124
[7] 0x090000000BA04D44 sqlomkdirp + 0xF0
[8] 0x090000000CB5477C sqlpgCreateArchivePath__FPcT1UiT1 +
0x9C
[9] 0x090000000CB54620
sqlpgCreateArchivePath__FPcT1UiT1@glue142F + 0x7C
The system should continue with crash recovery after these
messages.
There have been instances with very large multinode systems
where many of the nodes produded these errors giving the
impression that the system was hung just printing this
information.
Note that the error shows the following:
Target file = MCA_DWH_LOGS1db2001dw , which is actually the TSM
setting for the management class plus the instance name.
This issue can also happen with other settings for Logarchmeth1
that are not DISK, like VENDOR |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* ALL *
****************************************************************
* PROBLEM DESCRIPTION: *
* DATABASE RESTART SHOWS SQLO_ACCD "ACCESS DENIED" ERRORS WITH *
* LOGARCHMETH1 SET TO non DISK like TSM:MGMTCLASS *
* *
* If we have the following setting in Logarchmeth1 *
* *
* TSM:MCA_DWH_LOGS1 *
* *
* being MCA_DWH_LOGS1 the TSM Management Class for archiving *
* logs, on database restart we might experience the following *
* errors if we previously crashed with open transactions and *
* the database was left in an inconsistent state: *
* *
* 2010-01-27-11.55.22.589466+060 E209394A896 LEVEL: *
* Error (OS) *
* PID : 4075576 TID : 2830 PROC : *
* db2sysc 5 *
* INSTANCE: db2001dw NODE : 005 DB : *
* DWH00001 *
* APPHDL : 5-51 APPID: *
* *N5.db2001dw.100127105522 *
* AUTHID : DB2001DW *
* EDUID : 2830 EDUNAME: db2agent (DWH00001) *
* 5 *
* FUNCTION: DB2 UDB, oper system services, sqlomkdirp, *
* probe:10 *
* MESSAGE : ZRC=0x840F0001=-2079391743=SQLO_ACCD "Access *
* Denied" *
* DIA8701C Access denied for resource "", operating *
* system return code *
* was "". *
* CALLED : OS, -, mkdir *
* OSERR : EACCES (13) "Permission denied" *
* DATA #1 : File name, 21 bytes *
* MCA_DWH_LOGS1db2001dw *
* DATA #2 : signed integer, 4 bytes *
* 488 *
* DATA #3 : signed integer, 4 bytes *
* 488 *
* DATA #4 : String, 105 bytes *
* Search for ossError*Analysis probe point after this log *
* entry for further *
* self-diagnosis of this problem. *
* *
* *
* *
* 2010-01-27-11.55.22.590669+060 I210291A1688 LEVEL: *
* Error (OS) *
* PID : 4075576 TID : 2830 PROC : *
* db2sysc 5 *
* INSTANCE: db2001dw NODE : 005 DB : *
* DWH00001 *
* APPHDL : 5-51 APPID: *
* *N5.db2001dw.100127105522 *
* AUTHID : DB2001DW *
* EDUID : 2830 EDUNAME: db2agent (DWH00001) *
* 5 *
* FUNCTION: DB2 Common, OSSe, ossErrorIOAnalysis, probe:100 *
* CALLED : OS, -, mkdir *
* OSERR : EACCES (13) "Permission denied" *
* DATA #1 : String, 119 bytes *
* A total of 2 analysis will be performed : *
* - User info *
* - Path access permission *
* *
* Target file = MCA_DWH_LOGS1db2001dw *
* DATA #2 : String, 188 bytes *
* Real user ID of current process = 1010 *
* Effective user ID of current process = 1010 *
* Real group ID of current process = 1004 *
* Effective group ID of current process = 1004 *
* DATA #3 : String, 209 bytes *
* Information of each subdirectory leading up to the first *
* inaccessible one is shown in the format below : *
* <UID>:<GID>:<permissions> (subdirectories) *
* *
* *
* Cannot descend any further than the above subdirectory. *
* CALLSTCK: *
* [0] 0x090000000ACACEFC pdOSSeLoggingCallback + 0x34 *
* [1] 0x0900000007D1F424 oss_log__FP9OSSLogFacUiN32UlN26iPPc *
* + 0x1C4 *
* [2] 0x0900000007D1F900 ossLogSysRC + 0xA0 *
* [3] 0x0900000007D3F08C *
* ossErrorIOAnalysis__FCPC21OSSErrorAnalysisParam + 0xC4C *
* [4] 0x0900000007D41108 ossErrorAnalysis@AF12_1 + 0x48 *
* [5] 0x090000000CA9D52C sqloSystemErrorHandler + 0x54 *
* [6] 0x090000000D5945C0 sqloSystemErrorHandler@glue7A9 + *
* 0x124 *
* [7] 0x090000000BA04D44 sqlomkdirp + 0xF0 *
* [8] 0x090000000CB5477C sqlpgCreateArchivePath__FPcT1UiT1 + *
* 0x9C *
* [9] 0x090000000CB54620 *
* sqlpgCreateArchivePath__FPcT1UiT1@glue142F + 0x7C *
* *
* The system should continue with crash recovery after these *
* messages. *
* There have been instances with very large multinode systems *
* where many of the nodes produded these errors giving the *
* impression that the system was hung just printing this *
* information. *
* *
* Note that the error shows the following: *
* Target file = MCA_DWH_LOGS1db2001dw , which is actually the *
* TSM setting for the management class plus the instance name. *
* *
* This issue can also happen with other settings for *
* Logarchmeth1 that are not DISK, like VENDOR *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 version 9.7 Fix Pack 2 *
**************************************************************** |
| Local Fix: |
Update Logarchmeth1 to DISK and reset it again to TSM:MGMTCLASS
after database has been restarted |
| available fix packs: |
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
Problem was first fixed in DB2 version 9.7 Fix Pack 2 |
| Workaround |
not known / see Local fix |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC67351
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 12.03.2010
26.04.2010
26.04.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP2
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.2
|
 |
