WPS Portal project

Wednesday, August 06, 2008

DB2 tuning for WCM JCR v6 database

We are still in the WPS/WCM migration study process (from v5.1.0.4 to v6.0.1.3) and we experience a lots of problems due to the WCM data migration. We have a quite large WCM database (approx 10 Go), and as for today we have 2 big problems with the migration:

- WCM data migration takes 13 days to complete !
- After the import on the target v6 is completed, the portal serveris very slow (very bad response time caused by WCM).

We are currently re-starting the migration from scratch because these performances issues might be due to a problem in the DB2 collation configuration (see). The information provided in the infocenter is simply not correct and can lead to bad performances problems when installing the WCM JCR database....

I will do a specific and detail blog post to share our problem with everyone later on, but while searching for DB2 performances issues, I found these 2 articles which are very useful:

The first one is a very good synthesis of the main tuning tips and tricks (on WPS, WCM, LDAP, http server) that has been published so far on the subject (this is the better synthesis I have found so far, and it is very useful because there are so much distinct tuning guide on these topics and it is really hard to have a good overview of all required tuning actions):

Checklist for optimum performance of WCM 6.0 and 6.1

The second one is especially dedicated to WCM JCR database tuning for DB2 (there are a lot of tuning task that are presented here that I never seen before, but the author seems to be very knowledgeable):

IBM WebSphere Portal Web Content Manager and DB2 Tuning Guide.pdf (DeveloperWorks)

Hope this will help...

6 Comments:

  • Note: in our case, enabling the support for large pages lead to an important perfomances degradation...so be careful if you choose to apply it.

    As mentionned in the corresponding tuning task:
    "These values (memory assigned for large page) may need to be adjusted on systems with different amounts of physical memory".

    By Blogger Enguerrand SPINDLER, at August 06, 2008  

  • After changing the DB2 collation to IDENTITY (instead as UCA400_NO), I confirm that the WCM performances have been really enhanced. So UCA400_NO has a really bad impact on WCM JCR performances.

    Moreover, you can see there that in v6, some specific collation management tasks have been added in the installation process: see

    By Blogger Enguerrand SPINDLER, at August 24, 2008  

  • Also, changing the collation incredingly improved the WCM data import task (from v5 to v6).
    Whith the UCA400_NO collation, importing 6GB in the JCR DB takes approx 13days ! With the IDENTITY collation configuration, it takes "only" 3 days approx.

    By Blogger Enguerrand SPINDLER, at August 24, 2008  

  • I'm glad you found the performance checklist useful. Feel free to update the wiki with any of your comments and findings.

    By Anonymous Anonymous, at August 27, 2008  

  • Sorry, did you just say it took 3 days to import 3Gb? And that's *tuned* ??


    Why on earth would you even consider using something that performs so badly?

    Seriously, I'm baffleb

    By Anonymous Anonymous, at September 26, 2008  

  • Actuelly, it's 3 days for approx 10 GB of data...That's due to the design of the IBM migration process which is based on HTTP (all the content is moved through XML over HTTP, and the receiver which do the import is a simple servlet)...I aggree that's crazy

    By Blogger Enguerrand SPINDLER, at September 26, 2008  

Post a Comment

<< Home