As a BizTalk consultant I always implement BAM to do basic auditing. This is besides the BAM a business analist would want to see. The basic functionality of this audit trial is:
- When was the message received
- Where did it came from
- Where did it go
- What happend to the message
- Any important business decision made in an orchestration
I write this audit data into a BAM view, and it has proven to be valuable information. From time to time you will get questions regarding messages and it’s always nice to have this information. Besides that you can set nice alerts ( if you use them) on specific events and have people mailed in case things go wrong. So this is nice and i wouldn’t want to do an implementation without it.
But there is a downside to it. All these audit records also write some data in a not very well documented database BAMAlertsApplication. And over time there could be millions of rows in them. Below is a sample of the BAMAlertsApplication
Image may be NSFW.
Clik here to view.
The records are just piling up and are consuming more and more resources from your SQL server. I had noticed this behaviour before and posted a question about it on the MDSN forums see “How to clean up the BAMAlertsApplication database.” And the answer of a MS Employee was to open a case by Microsoft. Yesterday the BizTalk Administrator of the customer that I work for, asked me if there was anything I could do about the size of this database that just kept on growing and growing. The administrator even pointing me to my own discussion on MSDN and stated that he wanted to indeed start a case with MS.
This triggered me to have a look at the database and by looking at the stored procedures ( I was looking for remove/archive/delete stored procedures) I noticed the NSVacuum stored procedure. This triggered me to see what it did. So I turned to the almighty google to see what it knew about NSVacuum. I got only 2 results !.The first post wasn’t really encouraging, since it increased the databases
Image may be NSFW.
Clik here to view.
.
But looking at the code of the stored procedure I was convinced that it did some cleaning. So I dropped the “BizTalk” keyword from the search to have another look…..
Image may be NSFW.
Clik here to view.
This was not too encouraging either, only three real results this time. But fortunately the first one pointed me to a Microsoft document with usefull information. It turned out that NSVaccum was exactly what we needed. And after some runs the databas has now shrunk to a more reasonable size. See the picture below.
Image may be NSFW.
Clik here to view.
So, the takaway is….., do NOT forget to schedule NSVacuum if you are using BAM !….
I really hope this is usefull for other people in the future, if it is, please leave reaction on my blog, it will keep me motivated to share my BizTalk experiences with the community !
