High DB2 activity of IBM Connections Homepage database

High DB2 activity of IBM Connections Homepage database

Hello friends,
during the last week we experienced a extremely high log processing of the homepage database in one of our IBM Connections 4.5 environment.

The values were all configured by default like this:

Log file size (4KB)                         (LOGFILSIZ) = 1024
Number of primary log files                (LOGPRIMARY) = 26
Number of secondary log files               (LOGSECOND) = 52

With this parameters each log file got created faster then it has been archived, the result of this behavior was that the system was slowly running out of harddisk space and all we could do was to setup a crontab, which removed all the archived logs once an hour to prohibit an impact.

We also found out that the size compressed backups grew from 900 MG to 20 GB within a few days.

 

In an agreement with our customer we restarted the Connections environment to ensure there is nothing wrong with one of the applications. So after the restart we experienced that the SystemOut.log of the Connections InfraCluster and the db2diag.log of the Instance with the Homepage database was throwing errors because the transaction log was too small — with the result that the Search application could not have been started anymore successfully.
So we raised the values on those parameters: (on both HADR sites)

Log file size (4KB)                         (LOGFILSIZ) = 8196
Number of primary log files                (LOGPRIMARY) = 26
Number of secondary log files               (LOGSECOND) = 52

We also actived the Log Compression on both DB2 sides (HADR), which was a really good thing!

Archive compression for logarchmeth1    (LOGARCHCOMPR1) = ON

After increasing the size of the logfile we were able to start the search application again and the problem with the high activity seems to be fixed with the restart of Connections. To solve this issue or find a workaround we already opened a PMR to work out a fix with the IBM.

The issue is most probably related to an issue with the search index. There was already an issue with the search application in IC3

There it says to fire a SQL query to find out if there are duplicate entries in the the table. But the schema has changed. So we used:

SELECT T1.FILESCONTENT_ID, T1.UPDATE_TIME
FROM HOMEPAGE.SR_INDEX_DOCS T1,
(SELECT FILESCONTENT_ID, COUNT(*) NUM
FROM HOMEPAGE.SR_INDEX_DOCS
WHERE FILESCONTENT_ID IS NOT NULL
GROUP BY FILESCONTENT_ID
HAVING COUNT (*) > 1) T2
WHERE T1.FILESCONTENT_ID IS NOT NULL AND T1.FILESCONTENT_ID=T2.FILESCONTENT_ID

which gave us a file with more than 160 MB of size…

I`m pretty sure, that this is the issue. We will not use the provided scripts by IBM, as they are written for IC3. We need to wait for the scripts and a new technote for IC4.5 . What a bad error that really threatens the whole system stability of IBM Connections!

I`ll keep you updated 😉

kind regards.

Christian Weghaus

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *