Performance issues while promoting life cycle

Hi All,

Some times it takes long time to promote life cycle of a object. I tried to enable the trace for the session to 10 and found that it is trying to do full fetch on SysObj operations taking long time. Here is the extract of trace file for the session.

Wed Feb 17 09:22:27 2010 039403 [DM_SYSOBJECT_T_FULL_FETCH]info: "Full Fetch of SysObj id=0996b43f805bee0f cache_vstamp=1693."
Wed Feb 17 09:22:27 2010 271220: 2773212[1] SessionID:0196b43f8008bf2a DBID:466 commit
Wed Feb 17 09:22:27 2010 277294 [DM_SYSOBJECT_T_FULL_FETCH]info: "Full Fetch of SysObj id=0996b43f805bee11 cache_vstamp=1693."
Wed Feb 17 09:22:35 2010 134634: 2773212[1] SessionID:0196b43f8008bf2a DBID:466 commit
Wed Feb 17 09:22:35 2010 141056 [DM_SYSOBJECT_T_FULL_FETCH]info: "Full Fetch of SysObj id=0996b43f805bee13 cache_vstamp=1693."
Wed Feb 17 09:22:41 2010 839952: 2773212[1] SessionID:0196b43f8008bf2a DBID:466 commit
Wed Feb 17 09:22:41 2010 845934 [DM_SYSOBJECT_T_FULL_FETCH]info: "Full Fetch of SysObj id=0996b43f805bee15 cache_vstamp=1693."
Wed Feb 17 09:22:48 2010 475270: 2773212[1] SessionID:0196b43f8008bf2a DBID:466 commit
Wed Feb 17 09:22:48 2010 481425 [DM_SYSOBJECT_T_FULL_FETCH]info: "Full Fetch of SysObj id=0996b43f805bee17 cache_vstamp=1693."
Wed Feb 17 09:22:55 2010 490448: 2773212[1] SessionID:0196b43f8008bf2a DBID:466 commit
Wed Feb 17 09:22:55 2010 496601 [DM_SYSOBJECT_T_FULL_FETCH]info: "Full Fetch of SysObj id=0996b43f805bee19 cache_vstamp=1693."
Wed Feb 17 09:23:02 2010 873697: 2773212[1] SessionID:0196b43f8008bf2a DBID:466 commit
Wed Feb 17 09:23:02 2010 905758 [DM_SYSOBJECT_T_FULL_FETCH]info: "Full Fetch of SysObj id=0996b43f805bee1b cache_vstamp=1693."

However if we restart the database and content server, every thing comes normal and again after couple of weeks performance issues starts again.

What DM_SYSOBJECT_T_FULL_FETCH means? Is it full fetch on dm_sysobject table?

Any one faced this kind of issues before. I attached complete trace file.

I would really appreciate if you share your inputs/ideas about this issue.

Thanks in advance for your responses.

Kind regards,

Raju

0196b43f8008bf2a

Find more posts tagged with

Comments

araju

Never mind, issue is related to java method server, it ran out of memory. I restarted the method server and increased max memory parameter in start up script from 1G to 2G. Every thing looks fine at this moment. Hope it solves the issue.

I have question, Is it good practice to bounce(restart) java method server and webcache server on regular basis?

Thanks in advance for your response.

DCTM_Guru

Best practice - NO. Have to - maybe.

What version of SCS and JMS are you using?

araju

We are using 6.5 SP1 on AIX.

DCTM_Guru

If you have performance problems with FETCH, then I would check to see if the dm_sysobject_s, dm_sysobject_r tables are indexed optimally.

araju

Thanks a lot Johnny for your response.

We have around 5.4 million rows in dm_sysobject_s and 24.9 million rows in dm_sysobject_r tables. I know these tables will be really huge.

I will ask DBA to analyze these tables.

dm_sysobject_s has indexes on following columns:

R_OBJECT_ID
I_CHRONICLE_ID
OBJECT_NAME
R_LOCK_OWNER
ACL_DOMAIN, ACL_NAME
R_MODIFIER
R_POLICY_ID
OWNER_NAME

dm_sysobject_r has indexes on following columns:

R_OBJECT_ID, I_POSITION
R_OBJECT_ID, I_FOLDER_ID
R_OBJECT_ID, R_VERSION_LABEL
R_OBJECT_ID, R_ASPECT_NAME