MySQL Bugs: #69273: SQL Server 2008 R2 DTS sends data to MySQL 5.5 "MySQL Server Gone Away"

Bug #69273	SQL Server 2008 R2 DTS sends data to MySQL 5.5 "MySQL Server Gone Away"
Submitted:	17 May 2013 21:31	Modified:	20 Jun 2013 13:38
Reporter:	Marco Hernandez	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: DML	Severity:	S1 (Critical)
Version:	5.5.28-29.3-log	OS:	Linux (by sitegrounds.com)
Assigned to:		CPU Architecture:	Any
Tags:	dts, gone away, sql server

Description:
I work in an organization that owns a local SQL Server 2008 R2 and it is used to store all forms of information, including sales. We need to send sales data to a MySQL Server on the internet on a dayly basis (once every night). We have been doing this for a few months now and all was well, until we updated ODBC Drivers to 5.2. After that, and after some fixes later, the DTS is failing every time with a message that says "MySQL Server gone away". We have been looking for a way to fix this thinking it may be Bandwith problems, or query problems, We even sent a ticket to the people at SiteGrounds.com, who provide us with MySQL Databases where all the data is being sent to. The funny thing is, we have three DTS that send data to the same server, and only one fails consistently.

Details:
------
SQL SERVER 2008 R2:
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) Apr 2 2010 15:48:46 Copyright(c)  Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: ) 

MYSQL ODBC 5.2

MYSQL SERVER 5.5.28-29.3-log

How to repeat:
1. Create a DTS that sincs sales data of 7 days (about 1000 rows each day)

2. Put the DTS to run every night

3. When the DTS runs, it fails with a message "MySQL Server Gone Away", or similar

Thank you for the bug report. If 1 of 3 DTS has this issue Why do you think is a server bug?. Please check http://dev.mysql.com/doc/refman/5.5/en/gone-away.html . Thanks.

I don't think it is a bug per-se, I just don't know how to fix it! If the Server "Goes away" because we bombard it with INSERT statements (which is essentially what a DTS does) that impacts the performance, then HOW tell me, HOW can we optimize this? What can we do to make sure that the data does cross the cable into our database? and seriously of all SQL statements, HOW idoes an INSERT make it into the slow query log? (ours do!) Remember this is a DTS that runs once every day, sends anything from 1000 to 5000 rows each day, and that data has to cross, we even use MyISAM to compensate for performance, but if the server "Goes Away" we have to wait for the next day to sincronize and next day there will be more data, and therefore, it will be more likely that it will "go away", so assuming this is a bandwidth or concurrency problem HOW do we make it not "go away"? and seriously WHY does it go away? can't it just "stay there" and become a bit slower?

Thank you for the feedback. Did you read the Manual and tested the wait_timeout changes?. Also notice here isn't a forum to discuss the use of the product instead is to report bugs repeatable with test cases provide by preference. Thanks.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".