Prevent deadlocks in SM

1. Deadlock errors from logs :
7032( 8216) 02/27/2015 19:41:19 RAD I QCIM1E91787-DEBUG:trigger.add.default.folder.update.incidents:Current ID=SDxxxx
7032( 8216) 02/27/2015 19:41:20 RTE E Error: SQL State: 40001-1205 Message: [Microsoft][SQL Server Native Client 10.0][SQL Server]Transaction (Process ID 199) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
7032( 8216) 02/27/2015 19:41:20 RTE I Row Number = 1, Column number = -1
These errors go back to the old issue we had worked on. The solution was to set a batch size. It should be incremented based on the load of tickets. Details given below that were provided last time. I think you can try setting batch size to 125 for each server in case you still see the issue. Please note that if you change batch size, service restart is required.
To reduce the risk of deadlocks occurring for Interactions please enable batch size for table incidents . Details on batch size can be found on help server or here, pg #39 :

Steps to implement :
1. Login to SM as an administrator e.g. falcon
2. Select Tailoring > Tailoring Tools > Sequential Numbers
3. In the Class field, type incidents
4. Select Search
5. In the Batch Size filed type 50
6. Select Save

HP recommends you set the batch file size to the number of new records you expect users to create in an hour divided by the number of servers in the implementation. For example, if you expect to generate 200 incident records an hour and have only one server in your implementation, then set the Batch Size value to 200. If your system consists of multiple servers, such as in a horizontal scaling implementation, then divide the total records per hour by the number of servers. For example, a horizontal scaling implementation with two servers only needs a batch size of 100 for each server to equal 200 incidents per hour.

So, the recommended Batch Size for you = 45,000 tickets / (30 days * 6 working hours * 2 servers) = 125. If customer will frequently restart app server and be very concerned about the ID losing, then try 10, but if still can see the deadlock issue, then bigger Batch Size should be used.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s