January 21, 2008 at 10:23 am
Trying to resolve why this API from Documentum keeps causing blocking issues. The issue is that users are being blocked with this update cursor coming from Documentum. What can I do to alleviate the locks?
I believe it is the logic of the update coming from the API (cursor). I've already rebuilt the tables, reindexed and still locks occur. They clear after about 30 secs- 1 minute. Any input would be appreciated.
January 21, 2008 at 12:01 pm
Try to find out what causes the pagelatch
1) exclusive updates
2) cpu-resources
3) i/o resources
http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/dw_perf_top10.mspx
What version of sql server 2000 are you using and what is its patch level (sp3, sp4, hotfixes)
January 22, 2008 at 8:07 am
We're running SQL 2000 SP3a.
It's an update statement that loops through in a cursor and updates the rows. Documentum controls the job due to it's object level updates.
We're thinking about defragmenting the disk drives to see if performance improves.
Any other suggestions?
January 22, 2008 at 2:59 pm
Defragmentation won't help much.
You can even polish your highway - scooter would not go any faster.
I can see only 2 suggestions:
1) improve Documentum software;
2) replace Documentum software with something matching your needs.
_____________
Code for TallyGenerator
January 23, 2008 at 10:01 am
No choice to change the application. Nested queries coming from a Documentum API is controlled by Documentum and not SQL Server is what I'm seeing. I have gathered perfstats and it shows that lck_m_s is the highest wait state due to escalation locks on the table needed by this badly designed way of updating groups and sub-groups. 2nd highest wait is NetworkIO which shows SQL server waiting for Documentum to recieve the data and move to the next update. Network is optimized on a gigabit environment so I guess more investigation is needed.
Thanks.
:unsure:
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply