728x90

Error description

  • when there are applications in rollback or commit state, db2 get
    snapshot for locks on <db2_name> may receive sql1042c error.
    E.g.
    $ db2 get snapshot for locks on sample
    SQL1042C  An unexpected system error occurred.  SQLSTATE=58004
    Some other utility which relies on the service of monitor
    component could also be affected, e.g db2top. In db2top, using
    'U' option to collect lock information may also cause db2top
    exited with sql1042c error.
    The following records could be found in db2diag.log if turning
    on the database manager configuration parameter DIAGLEVEL to 4:
    2013-03-12-03.43.12.074851-240 I243248E595           LEVEL: Info
    PID     : 19365                TID : 46913030187328  KTID :
    xxxxxx
    PROC    : db2sysc
    INSTANCE: db2inst1             NODE : 000            DB   :
    SAMPLE
    APPHDL  : 0-21                 APPID:
    *LOCAL.db2inst1.130312073953
    AUTHID  : DB2INST1             HOSTNAME: host123
    EDUID   : 41                   EDUNAME: db2agent (instance)
    FUNCTION: DB2 UDB, database monitor, sqm_snap_appl_locks,
    probe:10
    DATA #1 : <preformatted>
    Snapshot cannot obtain lock information for application with app
    handle 13. Application in commit/rollback.
    The following records could be found in db2 trace:
    | | | | sqm___sqm_write_lock_waits entry [eduid 224497 eduname
    db2agent]
    | | | | sqm___sqm_write_lock_waits exit
    | | | sqm_snap_appl_locks data [probe 10]
    | | | sqm_snap_appl_locks exit [rc = 0x000004D2 = 1234]
    | | sqm___sqm_snap_db_locks exit [rc = 0x000004D2 = 1234]
    | | sqm___sqm_free_dbcb_list entry [eduid 224497 eduname
    db2agent]
    | | sqm___sqm_free_dbcb_list exit
    | sqm___sqlmonssagnt exit [rc = 0x000004D2 = 1234]
    | sqlm_buffer_postprocess entry [eduid 224497 eduname db2agent]
    | sqlm_buffer_postprocess data [probe 1]
    | sqlm_buffer_postprocess data [probe 2]
    | sqlm_buffer_postprocess exit
    | sqm___sqlmfree entry [eduid 224497 eduname db2agent]
    | sqm___sqlmfree exit [rc = 0xFFFFFFFF = -1]
      sqm___sqlmonssbackend exit [rc = 0xFFFFFFFF = -1]
    

Local fix

  • using db2pd -locks -db <db_name> to collect lock information
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * ALL                                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * when there are applications in rollback or commit state, db2 *
    * get                                                          *
    * snapshot for locks on <db2_name> may receive sql1042c error. *
    *                                                              *
    *                                                              *
    *                                                              *
    * E.g.                                                         *
    *                                                              *
    *                                                              *
    *                                                              *
    * $ db2 get snapshot for locks on sample                       *
    *                                                              *
    * SQL1042C  An unexpected system error occurred.               *
    * SQLSTATE=58004                                               *
    *                                                              *
    *                                                              *
    * Some other utility which relies on the service of monitor    *
    *                                                              *
    * component could also be affected, e.g db2top. In db2top,     *
    * using                                                        *
    * 'U' option to collect lock information may also cause db2top *
    *                                                              *
    * exited with sql1042c error.                                  *
    *                                                              *
    *                                                              *
    *                                                              *
    * The following records could be found in db2 trace:           *
    *                                                              *
    *                                                              *
    *                                                              *
    * | | | | sqm___sqm_write_lock_waits entry [eduid 224497       *
    * eduname                                                      *
    * db2agent]                                                    *
    *                                                              *
    * | | | | sqm___sqm_write_lock_waits exit                      *
    *                                                              *
    * | | | sqm_snap_appl_locks data [probe 10]                    *
    *                                                              *
    * | | | sqm_snap_appl_locks exit [rc = 0x000004D2 = 1234]      *
    *                                                              *
    * | | sqm___sqm_snap_db_locks exit [rc = 0x000004D2 = 1234]    *
    *                                                              *
    * | | sqm___sqm_free_dbcb_list entry [eduid 224497 eduname     *
    *                                                              *
    * db2agent]                                                    *
    *                                                              *
    * | | sqm___sqm_free_dbcb_list exit                            *
    *                                                              *
    * | sqm___sqlmonssagnt exit [rc = 0x000004D2 = 1234]           *
    *                                                              *
    * | sqlm_buffer_postprocess entry [eduid 224497 eduname        *
    * db2agent]                                                    *
    * | sqlm_buffer_postprocess data [probe 1]                     *
    *                                                              *
    * | sqlm_buffer_postprocess data [probe 2]                     *
    *                                                              *
    * | sqlm_buffer_postprocess exit                               *
    *                                                              *
    * | sqm___sqlmfree entry [eduid 224497 eduname db2agent]       *
    *                                                              *
    * | sqm___sqlmfree exit [rc = 0xFFFFFFFF = -1]                 *
    *                                                              *
    * sqm___sqlmonssbackend exit [rc = 0xFFFFFFFF = -1]            *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Upgrade to DB2 db2_v97fp6                                    *
    ****************************************************************
    

Problem conclusion

  • The fix will be included in DB2 db2_v97fp6
    

Temporary fix

  • using db2pd -locks -db <db_name> to collect lock information
    


http://www-01.ibm.com/support/docview.wss?uid=swg1IC78490

728x90
728x90

Problem(Abstract)

An 'SQL0433N Value "XXXX" is too long' error is returned when the TIMESTAMDIFF scalar function is run against a database with Oracle compatibility.

Symptom

SQL0433N Value "XXXX" is too long. SQLSTATE=22001

Cause

Subtraction of timestamp values returns DECFLOAT(34), representing the difference as a number of days. As a result, you can not use the TIMESTAMPDIFF scalar function because it depends on the default behavior of timestamp subtraction. Similarly, subtraction of date values returns DECFLOAT(34), which also represents a number of days, because date values are really TIMESTAMP(0). For more details on the functions that are changed under date_compat mode, please go through the 'DATE data type based on TIMESTAMP(0)' in the Related URL below.


Environment

Environments where databases are created with Oracle compatibility mode enabled.

Diagnosing the problem

The following test case can help you determine if you are encountering the problem:

  1. Set the DB2_COMPATIBILITY_VECTOR registry variable as below to enable all of the supported Oracle compatibility features:

    db2set DB2_COMPATIBILITY_VECTOR=ORA
    db2stop
    db2start
     
  2. Created the oratest database for testing purpose: 

    db2 create db oratest
    DB20000I  The CREATE DATABASE command completed successfully. 

  3. Running the TIMESTAMPDIFF scalar function will return SQL0433N error as below:

    db2 "values(TIMESTAMPDIFF(4,CHAR(TIMESTAMP('2001-09-29-11.25.42.483219')-TIMESTAMP('2001-09-26-12.07.58.065497'))))"

    1
    -----------
    SQL0433N  Value "2.970652982893518518518518518518519" is too long. SQLSTATE=22001

Resolving the problem

This is a restriction on the Oracle compatibility mode. A comparison of the tradeoffs needs to be done to determine if Oracle compatibility mode is more necessary than the use of these functions. one of the solutions below can be used as a work around when the database has been created with Oracle compatibility mode enabled:



o  Reducing the length of the timestamp

    db2 "values(TIMESTAMPDIFF(4,CHAR(TIMESTAMP('2010-04-01-09.43.05')-TIMESTAMP('2010-05-01-09.43.05'))))"
      1
      -----------
       
                0
        1 record(s) selected.


o  Multiply the DECFLOAT result to get the units you are interested in.  
    db2 "values ( TIMESTAMP('2001-09-29-11.25.42.483219')-TIMESTAMP('2001-09-26-12.07.58.065497') ) /* days */ * 24 /* hours per day */ * 60 /* minutes per hour */"
      1                                         
      ------------------------------------------
             4277.740295366666666666666666666668

        1 record(s) selected.


http://www-01.ibm.com/support/docview.wss?uid=swg21567168

728x90
728x90


Problem(Abstract)

After disabling Self Tuning Memory (ie. SELF_TUNING_MEM =OFF in DB CFG), the STMM log file is still updated with messages every 3 minutes.

Symptom

Note from DB CFG that STMM is disabled:


$ db2 get db cfg |grep -i self_tuning_mem
Self tuning memory                    (SELF_TUNING_MEM) = OFF


From stmm.log file we can see events like the following still being dumped:

2013-05-24-09.34.38.373583-180 I195993E593         LEVEL: Event
PID     : 2961                 TID  : 139972652820224PROC : db2sysc 0
INSTANCE: db2inst2             NODE : 000          DB   : INTERSEC
APPHDL  : 0-8                  APPID: *LOCAL.DB2.130524032237
AUTHID  : DB2INST2
EDUID   : 25                   EDUNAME: db2stmm (INTERSEC) 0
FUNCTION: DB2 UDB, Self tuning memory manager, stmmMemoryTunerMain, probe:0
MESSAGE : ZRC=0x0000067F=1663
DATA #1 : String, 115 bytes
Going to sleep for 180000 milliseconds.
Interval = 185, State = 1, intervalsBeforeStateChange = 10, lost4KPages = 0

2013-05-24-09.37.38.365898-180 I196587E454         LEVEL: Event
PID     : 2961                 TID  : 139972652820224PROC : db2sysc 0
INSTANCE: db2inst2             NODE : 000          DB   : INTERSEC
APPHDL  : 0-8                  APPID: *LOCAL.DB2.130524032237
AUTHID  : DB2INST2
EDUID   : 25                   EDUNAME: db2stmm (INTERSEC) 0
FUNCTION: DB2 UDB, Self tuning memory manager, stmmMemoryTunerMain, probe:1528
MESSAGE : Starting New Interval



Cause

Turning OFF STMM via DB CFG parameter disables STMM feature, however it does not disable STMM logging.


Diagnosing the problem

Check whether SELF_TUNING_MEM parameter is disabled or not into DB CFG configuration.

db2 get db cfg |grep -i self_tuning_mem

SELF_TUNING_MEM parameter must be set to OFF like below:


Self tuning memory                    (SELF_TUNING_MEM) = OFF

Check the last events from stmm.log file in order to confirm that it is still being updated.


Resolving the problem

In order to completely disable STMM set the following DB2 registry variable as follows:

db2set DB2STMM=OFF

Run db2stop / db2start 

The stmm.log file will not have further updates with new messages.


http://www-01.ibm.com/support/docview.wss?uid=swg21640056

728x90
728x90


Problem(Abstract)

I receive the below error when applying the DB2 Enterprise Server Edition license on a 32-bit Linux system:

LIC1449N The license was not installed due to a platform restriction. 

Explanation: 
This DB2 product is only supported in trial mode, also known as "Try and Buy" mode, on this platform. 

User response: 
Continue to use this product in trial mode, or install one which is fully supported on this platform. 

Cause

DB2 Enterprise Server Edition v9.5 and higher is only supported in Test and Development mode on 32-bit Linux systems.

Resolving the problem

A DB2 Enterprise Server Edition permanent license may only be applied on a 64-bit Linux system.

Here are your options: 

  • Upgrade the OS to 64-bit Linux and then install Enterprise Server Edition and license.
  • Purchase another DB2 edition such as DB2 Workgroup Server Edition or DB2 Express Edition. You will need to also obtain and apply the corresponding permanent license.
  • Purchase DB2 Developer's Edition for 32-bit Linux. The Developer's Edition license certificate (db2dede.lic) can be applied on top of a Enterprise Server Edition install without any problems.


http://www-01.ibm.com/support/docview.wss?uid=swg21421213

728x90
728x90

DB2에는 복구 히스토리 파일(db2rhist.asc)이 있는데 주로 테이블스페이스 생성, 삭제, 로그 아카이빙 등과 같은 유틸리티성 작업이 기록된다. 이 파일이 일정 크기 이상으로 커지면 Commit이 완료되는데 오래 걸리는 현상이 발생한다. 

아래 포스트를 보면 DPF환경에서 히스토리 파일이 약 240MB인 경우에 트랜잭션 행(hang)현상이 발생했다고 한다.



The history file in DB2 is a critical file that is usually overlooked.


Earlier this week I work with a customer that had been experiencing hangs on certain partitions (Yes this is DPF) daily since upgrading to a later fixpack, and intermittently on the earlier fixpack.


We found that DB2 was stuck in uninteruptable kernel code. As this was Linux, the usual tools to get a kernel trace were not available. Looking at the db2support provided by the customer, I saw that the db2rhist.asc (aka history file) was > 240MB.


The customer was advised to prune the history file, so that it only contained 1o days of history. This resulted in the db2rhist.asc only being 8 MB (which is still reasonable big). Since the pruning of the history file no further hangs have been experienced to date.


There are numerous cases where a large history file causes a slow down and even hang like symptoms. In a majority of cases where there is high load activity the history file can grow quickly and there are DB2 internal options so that Loads are not logged in the history file - see DB2 support for details.


It is good practice to keep the history file as small as possible.



좀 심한 경우에는 600MB까지 늘어난 경우도 있다.


Dear all,
I wrote some weeks ago about a problem with all the committing transactions blocked for many seconds in a Commit Active state. Well, finally I solved it and I just would like to share this information.

 As I suspected there was a lock. I suspected log writing due to thecommit active state and I was right. Using truss on the db2loggw process I found that when the db2 was blocked it was waiting on a Unix semaphore. I didn't find a way to find on AIX a command that gives you the pid of the semaphore locking process (you have the last operation process pid, that was the db2loggw itself). This semaphore lock appear just after a statx on
the db2rhist.asc file, so I tried to understand what was happening with that file.

Oh well, the file was pretty big: 600MB. I suspected the db2logmgr and infact it was accessing the file during the lock. once again, truss helped me. It was reading/seeking into the file... when it finished it did a semop on the same semaphore (an unlock obviously) and the db2loggw started to write again and everything was unblocked and working correctly.

I removed the db2rhist.asc and the db2rhist.bak and reduced the REC_HIS_RETENTN variable to 7 days (we keep backup for less than a week) while the default is 366...

Anyway I have some questions for any DB2 folk around here. First of all anything happened just when there was an asnapply or asncap committing transaction on the database (the replication processes). Second is that I do not understand while the db2logmgr must read so many data from the db2rhist.asc: is it responsible of the history rotation process or whatever?

Thanks a lot to everybody and bye.

Matteo Gelosa
I.NET S.p.A.



어쩄든 History FIle 에 액세스하는 동안 Commit이 느려진다는 점은 IBM문서에서 나와있으나, 어느정도 크기 이상이 되었을 때 성능에 문제가 있다던지 하는 기준은 없다. 가능하면 작게 유지하는 것이 좋다는 게 공식적인 입장이다.


다만 최근에 출시된 10.1 버전 Fixpack 2 부터는 History FIle이 커져도 성능에 영향을 주지 않도록 변경된 것으로 보인다.



http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.wn.doc/doc/c0060645.html

http://veryuglyboxer.blogspot.kr/2010/01/history-file.html

http://www.dbforums.com/db2/1652165-applicaiton-staying-long-time-commit-active-state.html

http://database.ittoolbox.com/groups/technical-functional/db2-l/application-in-commit-active-status-4428765

http://dbaspot.com/ibm-db2/195591-commit-active-problem-solved-db2rhist-asc.html

http://www-01.ibm.com/support/docview.wss?uid=swg21575692




728x90
728x90



Problem(Abstract)

A very large db2rhist.asc file can cause performance degradation to DML that modifies tables.

Symptom

Poor performance during inserts, updates and deletes. The application snapshots will show applications in COMMIT-ACTIVE longer than it should


Cause

During a log archive, DB2 writes to the db2rhist.asc file. As the file gets larger, the writes takes longer than usual. During this time any inserts, updates and deletes attempting to COMMIT during a log switch have to wait for the db2rhist.asc update to complete. This can momentarily 'freeze' the system for a few seconds.

This problem usually affects customers who use flash copy to backup the database. As DB2 backup is not invoked directly, the db2rhist.asc does not get pruned despite the RETENTION setting.


Diagnosing the problem

Disable HADR for isolation, as it may cause COMMIT-ACTIVE as well

 

Resolving the problem

Reduce the size of the db2rhist.asc via the prune force command periodically


http://www-01.ibm.com/support/docview.wss?uid=swg21575692

http://dbaspot.com/ibm-db2/195591-commit-active-problem-solved-db2rhist-asc.html


728x90
728x90

Question

If you think that the DB2® index manager might be the origin of a problem, collect diagnostic data that you or IBM® Software Support can use to diagnose and resolve the problem.

Cause

Background

There are many flavours of index-related corruption problems, for instance:

  • Unique index contains duplicates with different RID(s) or same RID(s)
  • Multiple index entries pointing to the same RID
  • Index key is out of place (wrong index key order)
  • Row exists, but index keys do not exist in any or some of the indexes
  • Index entry pointing to an empty data slot or unused data slot or RID is invalid
  • Incorrect previous or next index page pointers, incorrect high key or other corruptions on index pages

Even if you see the same return code from the same function or probe point, problems could vary from one to another. For instance, when SQLI_NOKEY error is received from index function "procLeaf2Del" or "sqlischd" during a delete or update, you could be hitting problems 3, 4, or 6. 

If "row not found" or "bad page" type of error is received when an index is used to fetch the RID for a delete, update or select, then you could be hitting problems 3 or 5. 

In short, for each problem, a DB2 support analyst will need to look at the data collected, and analyze it to determine root cause. To have data collected as much as possible at the first failure point as well as preserving necessary log files are often critical to the root cause determination. 

Since index corruption or index data inconsistency type of errors could be caused by DB2 defects or by other issues such as hardware problems, it is necessary to collect the proper diagnostic data in order to determine the potential cause of the error. 


DB2 tools to detect these problems 

DB2 products offer a variety of tools to detect index or data corruption problems and index or data mismatch problems. 

  1. An off-line db2dart /t (table inspection) would be able to detect corruption symptoms 1, 2, 3, 6 of the above list. For example:

    Table resides in table space id 4, and object id of table is 2, the database name is T30, the output is "inspTsi4oi2.rpt":
    db2dart T30 /t /tsi 4 /oi 2 /scr n /rptn inspTsi4oi2.rpt

  2. The RUNSTATS command with a special registry variable set will collect statistics as well as detect corruption symptoms 4, 5 of the above list. For example:

    db2stop
    db2set DB2_KEYDATACHECK=IXSTATDATADEBUG
    db2start

    db2 connect to <database>
    db2 -v "runstats on table <tableschema>.<tabname> and detailed indexes all allow read access"

    NOTE: After each RUNSTATS, you need to save the contents of the sqllib/db2dump directory. You can do so by moving the entire content to another location. As long as the RUNSTATS does not return with DB2 completed successfully, you will need to report this to DB2 support.

Some enhancements are currently being investigated. The goal is to improve the existing tools for serviceability and usability in future releases in the above areas.

Answer

You often need an advanced knowledge of DB2 in order to determine whether the problem is an index corruption or an index or data inconsistency problem. Therefore you should always contact IBM support organization to help you recover from these problems.



For index-related corruption or index or data inconsistency problems, the following information is typically required:

  • the contents of the DB2DUMP directory
  • the on-disk version of the related index pages (collected via the db2dart tool)
  • related data page(s) for the index or data object (collected via the db2dart tool)
  • database transaction log files, which are used to understand the past history of the index or table object that encountered the error.

The following steps are the recommended best practice for data collection (and database recovery) when an error related to index corruption occurs. NOTE: DO NOT perform these steps unless you have been asked to do so by an IBM DB2 Support analyst. 

  1. Collect the standard diagnostic information using the db2support command. This should include all the files in DB2DUMP directory (or the path specified by DIAGPATH in the dbm configuration).

    There are cases where the corruptions are caused by a disk problem, and you do not care about root cause analysis of the problem. In these situations, skip step 2, and go directly to step 3.

  2. Run db2dart as indicated below (note: if this is a multi-partition DPF environment, then you will need to run db2dart on the partition where failure occurred):

    db2dart <dbname> /t /tsi <pool id> /oi <object id> /rptn inspTsi<poolid>oi<objectid>_bcrashrec.rpt

    In general, this inspection should be fairly quick. If the database is mission critical database and needs to be brought up online immediately, then you may skip this step at this time.

  3. Restart your database and verify crash recovery completes successfully.


    If crash recovery completes successfully and you cannot take the time needed to collect this data for root cause analysis of the problem, skip steps 4, 5 and 6 and go directly to step 7.


    If the restart fails, and it is determined to be a problem redoing or undoing an index record, then you can mark an index invalid (e.g. db2dart <dbname> /mi /oi <objectID> /tsi <tablespaceID>). INDEXREC will control when the invalid index object will be recreated.
  4. To prevent the previous failing application from accessing the table again before the problem on the related index or table is resolved, you can lock the table in exclusive mode. Use the following command:


    db2 +c "LOCK TABLE <SCHEMA NAME>.<TABLENAME> IN EXCLUSIVE MODE"


    The "+c" turns off the auto commit, since LOCK TABLE is only effective within the unit of work.


    If you do care about the availability of the rest of the tables in the same table space as the problem table, instead you may also want to consider quiescing the table spaces for the table object. For example:


    db2 "QUIESCE TABLESPACES FOR TABLE <SCHEMA NAME>.<TABLE NAME> EXCLUSIVE"


    NOTE: QUIESCE command will also quiesce the index table space if the index object is in a separate table space. In a partitioned database environment, this command will only quiesce the portion on current node.

  5. Run db2dart against the index and table object.


    If the problem is an index NOKEY error, then a number of db2dart commands will be printed in the db2diag.log file. Search for these commands (using eithergrep on UNIX® or find on Windows®) and save them in a file. Edit the file, replace "DBNAME" with the database name. If the problem has been hit multiple times, then there could be some duplicate entries. You only need to keep the latest set of db2dart commands.

    If it is the data manager that reports row not found or bad page, then NO db2dart commands are printed out. You can determine the pool id, object id, data page number from the db2diag.log entries. For example:


    2006-06-17-11.32.59.941406+000 I235565A460 LEVEL: Severe
    PID : 9224396 TID : 1 PROC : db2agent (SAMPLE) 0
    INSTANCE: db2inst NODE : 000 DB : OB8
    APPHDL : 0-78 APPID: ....
    FUNCTION: DB2 UDB, data management, sqldDeleteRow, probe:1329
    RETCODE : ZRC=0x87040001=-2029780991=SQLD_BADPAGE "Bad Data Page"
    DIA8500C A data file error has occurred, record id is "".


    2006-06-17-11.32.59.964241+000 I236403A380 LEVEL: Severe
    PID : 9224396 TID : 1 PROC : db2agent (SAMPLE) 0
    INSTANCE: db2inst NODE : 000 DB : OB8
    APPHDL : 0-78 APPID: ...
    MESSAGE : PAGE OBJECT IDENTIFIERS:
    DATA #1 : String, 54 bytes
    Tablespace ID = 15, Object ID = 8737, Object Type = 0


    2006-06-17-11.32.59.964448+000 I236784A350 LEVEL: Severe
    PID : 9224396 TID : 1 PROC : db2agent (SAMPLE) 0
    INSTANCE: db2inst NODE : 000 DB : OB8
    APPHDL : 0-78 APPID: ...
    MESSAGE : PAGE NUMBERS:
    DATA #1 : String, 35 bytes
    Obj Page = 297, Pool Page = 787527


    In this case, the data page is 787527, pool id is 15 and object id is 8737.

    The commands that you need are:

    1. db2dart <dbname> /dd /tsi <pool id> /oi <object id> /ps <data page number>p /np 1 /v y /scr n /rptn dTsi<poolid>oi<objectid>.rpt

      ...where <data page number> is 787527p using the example above, "p" is used to indicate this is pool relative page which is important for DMS table space.

    2. db2dart <dbname> /di /tsi <pool id> /oi <object id> /ps 0 /np <large enough value to dump all index pages> /v y /scr n /rptn iTsi<poolid>oi<objectid>_0-<pagenum>.rpt.rpt


      Note: The command might take longer to run if a large /np value is specified. Ideally, you should collect as much data as possible. At minimum, it should be no less than 100 pages.

      If table is not too big, also dump the whole table. If the table is too big to dump, select a reasonably large number so that at least a part of the table can be dumped, for example:

      db2dart <dbname> /dd /tsi <pool id> /oi <object id> /ps <data page to start> /np <large enough number> /v y /scr n /rptn dTsi<pool id>oi<object id>_0-<page num>.rpt

      where <data page to start> would be "0" if you want to dump the whole table, or <data page number - 100>p if the table is too big to dump (using the example, that would be "787427p"). Replace the <pool id> and <object id> with the actual number.

  6. Run RUNSTATS to check for any index or data inconsistency. For example:


    db2stop
    db2set DB2_KEYDATACHECK=IXSTATDATADEBUG
    db2start
    db2 connect to <db>
    db2 -v "SELECT INDSCHEMA, INDNAME FROM SYSCAT.INDEXES WHERE TABSCHEMA='<TABLE SCHENAME>' AND TABNAME='<TABLENAME>' "


    Then use the index schema name and index name from the above SELECT output for the following RUNSTATS command:

    db2 -v "runstats on table <tableschema>.<tabname> and index <index schema>.<index name> allow read access"


    NOTE: You need to perform the RUNSTATS on all of the indexes defined on the offending table; after each RUNSTATS command, you need to save the contents of the sqllib/db2dump directory (or DIAGPATH, if you're not using the default path).


    RUNSTATS on a large table could take a while and the table will not be available for updates while RUNSTATS is running. In a multi-partition DPF environment, RUNSTATS is done on a per partition basis.


    If you had quiesced the table space at step 4, then unquiesce the table spaces before you terminate the database connection. You will need to use the same user id for the QUIESCE command in order to reset:


    db2 -v "QUIESCE TABLESPACES FOR TABLE <SCHEMA NAME>.<TABLE NAME> RESET" 


    Once all the RUNSTATS commands are completed, you need to collect the db2diag.log along with the content of sqllib/db2dump (or content of DIAGPATH).

  7. If it is determined that the index is corrupted (that is, if either RUNSTATS or db2dart /t inspection returns with an error), then proceed with rebuilding the index as follows:


    db2 "REORG INDEXES ALL FOR TABLE <SCHEMA NAME>.<TABLE NAME> ALLOW NO ACCESS"


    Applications cannot access your table while the above REORG is running. If you need the table to be available immediately, you can choose to run the above REORG INDEXES command with ALLOW READ ACCESS or ALLOW WRITE ACCESS options. Be aware, however, that the database is at risk of being brought down again if the previous failing application is run against the table before the REORG completes.


    If you are not concerned with root cause analysis of the problem, you do not need to collect any additional information and can skip the subsequent steps.

  8. Collect table or index DDLs. You can use the db2look utility to do so. For example: 

    db2look -d <database> -l -e -a -t <table name> -o table.ddl


  9. Collect transaction log files

    You will only know which log files to collect after a DB2 Support analyst examines the data collected thus far. In general, they will ask you to send a raw log file. In some special cases, they may ask you to format the file and only send the relevant log files. The number of log files required will depend on when the problem was introduced, so it might be necessary to retrieve older log files from archive. 

  10. Additional information that may be important to root cause analysis or known APAR identification. For example:
    • What type of workload is typically running against the table?
    • Did you perform any actions that you don't normally do on this table, for instance any REORG INDEXES/TABLE commands, load or import operations, a high utilities workload, or restore or rollforward operations?
    • Were there any other unusual occurrences? For example, if there were recent hardware problems, provide the operating system error log. This would involve collecting the errpt -a output on AIX® or /var/adm/messages file on Solaris.


http://www-01.ibm.com/support/docview.wss?uid=swg21244563

728x90
728x90


Problem(Abstract)

Tivoli Storage Manager crash

Symptom

Tivoli Storage Manager does not start after crash


Cause

Disk failure on DB2 database files

Diagnosing the problem

During Tivoli Storage Manager start up, the following errors are reported:

ANR0172I rdbdb.c(1465): Error encountered performing action 
ActivateDatabase. 
ANR0162W Supplemental database diagnostic information: -1224:**No State
Information Available (128)**:-1224 (**No Other Information Available 
(206)**). 
ANR0172I rdbdb.c(1009): Error encountered performing action 
InstanceStop. 
ANR0162W Supplemental database diagnostic information: -1032:**No State
Information Available (89)**:-1032 (**No Other Information Available 
(72)**). 

The db2diag.log reports: 

2010-02-19-15.29.08.326780+060 I289570185E438 LEVEL: Warning 
... 
MESSAGE : Crash Recovery is needed. 
2010-02-19-15.30.13.948634+060 I289572079E2547 LEVEL: Severe 
PID : 8492 TID : 47197773097280PROC : db2sysc 0 
INSTANCE: tsmb1 NODE : 000 DB : TSMDB1 
APPHDL : 0-7 APPID: *LOCAL.tsmb1.100219142908 
AUTHID : TSMB1 
EDUID : 65 EDUNAME: db2redow (TSMDB1) 0 
FUNCTION: DB2 UDB, buffer pool services, sqlbVerifyCBITS, probe:1110 
MESSAGE : ZRC=0x86020019=-2046689255=SQLB_CSUM "Bad Page, Checksum 
Error" 
DIA8426C A invalid page checksum was found for page "". 

DATA #1 : String, 64 bytes 
Error encountered trying to read a page - information follows : 
DATA #2 : String, 97 bytes 
CBIT verification error 
bitExpected is 0, userByte is 181, sector 63 (from head of page, 0 
based) 
DATA #3 : Page ID, PD_TYPE_SQLB_PAGE_ID, 4 bytes 
1196993 
DATA #4 : Object descriptor, PD_TYPE_SQLB_OBJECT_DESC, 72 bytes 
Obj: {pool:6;obj:5;type:1} Parent={5;5} 
... 


Resolving the problem

The db2diag messages indicate that the table ID 5 has corruption (see last message line: " {pool:6;obj:5;type:1} ".


You can do two different recoveries.

1) Restore the database to a point in time before the disk corruption occurred,

Or

2) Follow DB2 steps to determine if the corruption is only in the index tables and do a DB2 reorg.

Follow these steps to start the DB2 data collection:
$ db2stop 

SQL1064N DB2STOP processing was successful. 

Now run db2dart command for tablespaceid 6 or run for whole database. 
$ db2dart TSMDB1 /DB 
The requested DB2DART processing has completed successfully! 
Complete DB2DART report found in: 
/home/tsminst1/sqllib/db2dump/DART0000/TSMDB1.RPT 

Messages in RPT file:
Warning: The database state is not consistent.

Warning: Errors reported about reorg rows may be due to the inconsistent state of the database.
 

Error: Duplicate found at same slot in unique index. Lvl(1) Page,slot,rid current:2311036p,1008,x6000050319000000 prev:2311036p,1008,x5100AC5E180000
Error: Duplicate found at same slot in unique index. Lvl(1) Page,slot,rid current:2249254p,344,x0D00071D19000000 prev:2249254p,344,x5700AF5E18000000
Error: Duplicate found at same slot in unique index. Lvl(1) Page,slot,rid current:2248938p,951,x4C00FF7419000000 prev:2248938p,951,x4100BC5E18000000
Error: Duplicate found at same slot in unique index. Lvl(1) Page,slot,rid current:2223926p,957,x55002C6A19000000 prev:2223926p,957,x2A00B95E18000000
Error: Duplicate found at same slot in unique index. Lvl(1) Page,slot,rid current:2223926p,958,x81002C6A19000000 prev:2223926p,958,x2900B95E18000000
Error: Duplicate found at same slot in unique index. Lvl(1) Page,slot,rid current:2223926p,959,x17002C6A19000000 prev:2223926p,959,x2800B95E18000000
Error: Duplicate found at same slot in unique index. Lvl(1) Page,slot,rid current:2223926p,960,x18002C6A19000000 prev:2223926p,960,x2700B95E18000000

Index page corruption can be corrected by running the following command below :

Get the table name (This example is using the message output provided in the message: "{pool:6;obj:5;type:1} "):
db2 "select tabname from syscat.tables where tableid=5 and tbspaceid=6" 

Get the schema name:
db2 list tables 

Run db2 reorg command ( substituting value of schema name. tablename ) 

db2 " REORG INDEXES ALL FOR TABLE schemaname. table_ame ALLOW NO ACCESS"

If there is still an issue, DB2 support will need the full db2dart output for further analysis.


http://www-01.ibm.com/support/docview.wss?uid=swg21421841

http://www.ibm.com/developerworks/data/library/techarticle/dm-1208corruptiondb2/

728x90
728x90

SQL30082N Security processing failed with reason “26″


SQL Error [28000]: [jcc][t4][207][11243][3.59.81] Connection authorization failure occurred.  Reason: GSSAPI non-retryable error. ERRORCODE=-4214, SQLSTATE=28000


DB2 JDBC및 Native Client 연결 관련하여 다음과 같은 오류가 발생하여, 검색한 결과 유사한 내용을 찾을 수 있었습니다.

linux에서 설정하는 패스워드 알고리즘 관련 문제였습니다. 참고하시기 바랍니다.


If you are getting

SQL30082N Security processing failed with reason „15“ („PROCESSING FAILURE“)

when connecting to the db2 database using db2 CONNECT TO dbname USER username or

Connection authorization failure occurred. Reason: Local security service non-retryable error. ERRORCODE=-4214, SQLSTATE=28000

when connecting remotely (via JDBC driver) read on. I finally found what causes this error and a solution!

[ad]

Environment

Problem

Tho whole problem is in the format of the passwords in/etc/shadow. DB2 doesn't seem to like the passwords generated when changing password using the standard passwd command. In Fedora Core 10 the password is hashed using sha-512 and the entry for user username looks like:

username:$6$ef­WWOYRY$z5DNL1kLQ­U4AmPkFBqbQh6LOh­0Qjxq654dS9jE46iP­Np8Zces8I4bP8GLZ3G3RWLo/­6o.LYOV5neYSKxXbL­.M1:14375:0:99999:7:::

Solution

DB2 works fine with passwords hashed with standard crypt function. Password in the desired format can be obtained by callingopenssl passwd desiredPassword. The output of openssl can be passed to usermod --password The complete command to change user's password then look like:

usermod --password `openssl passwd desiredPassword`usename

Bigger image

I tried to hand-edit /etc/shadow and insert salted MD5 password, which can be obtained by openssl passwd -1 desiredPasswordand the connection was sucessfuly established. To sum it up, the whole problem in the end seems to be that DB2 doesn't like SHA-512 hashes in /etc/shadow. on the other hand, it works fine with hashes generated by crypt and MD5.

Changing default algorithm in Fedora Core

Fedora Core contains a nice tool authconfig. To change the default hashing algorithm to MD5 run

authconfig –passalgo md5 –update

All the passwords inserted in the password database will be stored in MD5 from now on. It will, of course, not change the hashes of the current passwords.

Ubuntu

Ubuntu ships with sha512 as default hash algorithm for passwords in /etc/shadow. The easiest way to change the default algorithm is to edit the file /etc/pam.d/common-password and change the line that reads

password [success=1 default=ignore] pam_unix.so obscure sha512

to

password [success=1 default=ignore] pam_unix.so obscure md5

The information about the algorith is also included in the file/etc/login.defs, which is used by chpasswd for example. Therefore change the line

ENCRYPT_METHOD SHA512

to

ENCRYPT_METHOD MD5



http://blog.stastnarodina.com/honza-en/spot/db2-sql30082n-security-processing-failed-with-reason-15/

http://www-01.ibm.com/support/docview.wss?uid=swg21623221

728x90
728x90

Problem(Abstract)

db2diag.log file may get filled with "Detected client termination" error messages.

Symptom

Following errors may be seen in db2diag.log file.

2012-10-07-03.31.44.562773+480 I559988E520 LEVEL: Error

    PID : 2160 TID : 140574011156224PROC : db2sysc 
    INSTANCE: db2inst1 NODE : 000 DB : SAMPLE 
    APPHDL : 0-4470 APPID: 202.27.30.1.2101.121006192554 
    AUTHID : PSOGALAG 
    EDUID : 568 EDUNAME: db2agent (SAMPLE) 
    FUNCTION: DB2 UDB, common communicati on, sqlcctest, probe:50 
    MESSAGE : sqlcctest RC 
    DATA #1 : Hexdump, 2 bytes 
    0x00007FD9EFFF6780 : 3600 

    2012-10-07-03.31.44.543149+480 I560509E538 LEVEL: Error 
    PID : 2160 TID : 140574002767616PROC : db2sysc 
    INSTANCE: db2inst1 NODE : 000 DB : SAMPLE 
    APPHDL : 0-4510 APPID: 202.27.30.1.2286.121006192634 
    AUTHID : PSOGALAD 
    EDUID : 570 EDUNAME: db2agent (SAMPLE) 
    FUNCTION: DB2 UDB, common communication, sqlcctcptest, probe:11 
    MESSAGE : Detected client termination 
    DATA #1 : Hexdump, 2 bytes 
    0x00007FD9EF7F6748 : 3600 


Resolving the problem

Function sqlcctcptest() tests if the client connection is active and function sqlcctest() tests whether the connection is still valid.


If you don't want such messages to be logged into db2diag.log file, you can set DB2CHECKCLIENTINTERVAL to zero.

For Example : Issue following:

    1) db2set DB2CHECKCLIENTINTERVAL=0 
    2) db2stop 
    3) db2start

Note : This variable specifies the frequency of TCP/IP client connection verifications during an active transaction. It permits early detection of client termination, instead of waiting until after the completion of the query. If this variable is set to 0, no verification is performed.


http://www-01.ibm.com/support/docview.wss?uid=swg21613530

728x90

+ Recent posts