May 5, 2005 at 6:09 pm
I have Xml order files that I create from SQL. I recently created a SQL script that utilizes sp_OA to create and write the Xml files. Afterwards I read that sp_OA can cause performance issues and even SQL server crashes. I am going to be using this script throughout the day on servers across the country, so I need to know is sp_OA programming in SQL that dangerous????
Thanks,
Adam
May 6, 2005 at 12:54 am
Well, dangerous can ean different things, but in a way yes. The sp_OA* procs have always been known as 'troublemakers'. First of all they themselves have had several fixes for memoryleaks and other issues in service packs over the years, so who knows how well they are functioning at any moment. Secondly, if not 100% correctly used, their usage can mean leaked memory. If you are not correctly removing objects that are created in memory then you could run out of memory soon. For instance if your proc that creates the object encounters a problem and does not remove the object from memory.
Also note that they often allocate memory from the MemToLeave region, which is a) much smaller than the large data and procedure cache area, and b) used for several other important allocations. My recommendation would be to create the xml files in an outside application that reads data from SQL Server and then processes the xml.
May 9, 2005 at 2:50 am
Ken Henderson just posted a very good blog post describing these dangers.
May 9, 2005 at 6:26 am
Hopefully, SP4 will fix some of the memory leaks. It came out this last Friday.
The problem in our shop used to be that no-one did a code review of other's work. When we did start code reviews, we found that a lot of people forgot one of the most important things about sp_OA's... they forgot to close the connection and we started having some sever connection allocation problems. The fix, of course was to add code to close the connections but that didn't solve the memory leak problems. We reverted back to Linked Servers (which have their own set of nuances or is that nuisances?) to solve the memory leaks.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply