Got Error 139 From Storage Engine When Dumping Table

Joerg, Thanks for your reply. I found out that this error was limitation row length of 8000 bytes on InnoDB. I have check the dump sql file and one particular table is causing error 139. What I did is just to use innodb row size too large MyISAM engine rather than InnoDB for a specific table only. BTW, the machine has barracuda format 24GB memory and Quad-Core CPU. The platform is RHEL 5.5 x64 and mysql-server-5.0.77-4.el5_4.2. *Rob Wultsch *and Prabhat Kumar, thanks for your mysql max row size response. Regards, James On Tue, Jul 6, 2010 at 5:19 PM, Joerg Bruehe wrote: > James, all, > > > James Corteciano wrote: > > Hi All, > > > > I have received mysql row size too large error message "ERROR 1030 (HY000) at line 167: Got error > 139 > > from storage engine" when importing dump database to MySQL server. The > MySQL > > server is using InnoDB. I have google it and it's something problem on > > exceeding > > a row-length limit in the InnoDB table. > > you are putting overload on our crystal balls - why don't you tell us

Row Size Too Large (> 8126)

> (at least!) the MySQL version and the platform? > > > "error 139" looks like it is some Unix/Linux. > On all these platforms, the exit code "139" means the process died > because of signal 11 ("segmentation violation", "SIGSEGV"), > and then a core dump was taken (indicated by the value 128). > 139 == 11 + 128. > > You should use your debugger of choice to get a stack backtrace, unless > this was already done automatically during crash analysis / recovery. > > > > > > Any have idea how to fix this? > > Only when the backtrace is known, there may be some educated guesses > about the cause of the problem. > But all such effort is wasted unless you tell the versions. > > > Jörg > > -- > Joerg Bruehe, MySQL Build Team, Joerg.Bruehe@stripped > ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin > Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven > Amtsgericht Muenchen: HRA 95603 > > Thread• Got error 139 from storage engine (InnoDB)JamesCorteciano5Jul • Re: Got error 139 from storage engine (InnoDB)RobWultsch5Jul • Re: Got error 139 from storage engine (InnoDB)PrabhatKumar5Jul • Re: G

Status: Not a Bug Impact on me: None Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical) Version:4.1.10 OS:FreeBSD (FreeBSD 4.11-STABLE) Assigned to: View Add Comment Files Developer Edit Submission

Innodb_file_format=barracuda

View Progress Log Contributions [6 May 2005 20:17] Tim Gustafson Description: I have mysql row limit an InnoDB table, DocumentVariants, that has a BLOB field in it. The table has about 22GB of data in it. When I run mysqldump on the table, I get this error message: mysqldump: Error 1030: Got error 139 from storage engine when dumping table `DocumentVariants` at row: 1594 Row 1594 is a http://lists.mysql.com/mysql/222105 row whose 'ID' column is 9221. When I run a query in the mySQL command line tool, I get this error: mysql> delete from DocumentVariants where ID = 9221; ERROR 1030 (HY000): Got error 139 from storage engine It would seem that perhaps my InnoDB table is corrupt. When I run "check table" on the table, it does not report any errors: mysql> check table DocumentVariants https://bugs.mysql.com/bug.php?id=10424 extended; +---------------------------+-------+----------+----------+ | Table | Op | Msg_type | Msg_text | +---------------------------+-------+----------+----------+ | archives.DocumentVariants | check | status | OK | +---------------------------+-------+----------+----------+ What's the best way to fix this problem? I can't dump the table to a .sql file because mysqldump dies as a result of the problem, and I can't delete the offending row because it causes the same error as the dump does. Will running an "alter table DocumentVariants type=innodb" work? If it does, it will take hours to run on this table I think because it's so large. What are the chances of that fixing the problem? Am I likely to loose data in this table as a result of this error? Thanks! How to repeat: It's hard to say - I think it's a one-time sort of glitch. Suggested fix: Unknown [6 May 2005 20:42] Miguel Solorzano Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.mysql.com/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to 'Open'. Thank you for your interest in MySQL. Additional info: miguel@hegel:~/dbs/4.1$ bin/perror 13

contributorsReferencesBlogProfessional partnersHostingSupportTrainingInstallationIntegrationCustomizationSurvey creationTemplate design Log in Log in Log in with TwitterLog in with GoogleLog in with GitHub Forgot Login? Sign up IndexRulesSearchRecent Topics Welcome, Guest Username: Password: Forgot your password? Forgot your username? Forum English support https://www.limesurvey.org/forum/installation-a-update-issues/59022-got-error-139-from-storage-engine forums Installation & update issues Got error 139 from storage engine TOPIC: https://ellislab.com/forums/viewthread/154842/ Got error 139 from storage engine Got error 139 from storage engine 5 years 6 months ago #59022 jamyles Offline Fresh Lemon Posts: 5 Karma: 0 We have an active survey that errors with "Got error 139 from storage engine" when trying to update a row. This survey row size has several text boxes per page. Reading the MySQL documentation, it appears that InnoDB can only handle 8000 bytes per row including the first 768 bytes of each blob (text, in this case) in the row. LimeSurvey is configured with $databasetabletype='InnoDB', but it appears it's still trying to do more than InnoDB can handle. Is there a solution to this problem? row size too Switch to MyISAM? LimeSurvey 1.87+ (build 8518) MySQL 5.0.45 using InnoDB Thanks in advance. The administrator has disabled public write access. JavaScript is currently disabled.Please enable it for a better experience of Jumi. Got error 139 from storage engine 5 years 6 months ago #59026 c_schmitz Offline LimeSurvey Team Posts: 1020 Thank you received: 135 Karma: 97 Yeah definately a switch to MyIsam should solve the issue. Best regards Carsten Schmitz LimeSurvey project leader The administrator has disabled public write access. Got error 139 from storage engine 5 years 6 months ago #59061 jamyles Offline Fresh Lemon Posts: 5 Karma: 0 That's what I was figuring. I did some testing, and it doesn't seem there's any way to use more than 9-10 text fields in a single survey. Any time a user fills all of them with 768 or more characters, the UPDATE will fail. I realize this probably means a significant change to the database schema to fix properly. Is there any plan to do this? Failing that, could the survey admin be warned about this when $databasetablety

Me? Password forgot password? This is an archived forum and may no longer be relevant. The active forums are here. Advanced Search Error 139 - Too Many Custom Fields J. Hull Posted: 11 May 2010 09:35 PM Joined: 2007-02-06132 posts I just got my first Error 1030: Got error 139 from storage engine MySQL error. I'm guessing this is because I have too many custom fields. This is a single site installation, 6 channels, 75 custom fields total. The breakdown in custom fields is (per channel) 2, 9, 3, 2, 59. That last one I actually need to have ALOT more custom fields and is the one that is currently failing. I may need to rethink how I have everything organized - is there a maximum number of custom fields/weblogs that I can work towards? Thank you. Lisa Wess Posted: 11 May 2010 09:37 PM [ # 1 ] Joined: 2004-05-1420446 posts Hi, J. Hull - 75 custom fields shouldn't be causing you any issues. What version and build of EE are you on, and what extensions are you running? J. Hull Posted: 11 May 2010 09:41 PM [ # 2 ] Joined: 2007-02-06132 posts EE v2.0.1pb01 build 20100121 No extensions (yet). Lisa Wess Posted: 11 May 2010 09:43 PM [ # 3 ] Joined: 2004-05-1420446 posts Moved to the appropriate forum. Was this an upgrade or a fresh installation of 2.0? And is your database running in MyISAM or InnoDB? What kinds of fieldtypes are you utilizing? And lastly - I need you to upgrade to 2.0.2 before we troubleshoot further. Edit to Add: What version of MySQL and PHP are you running? J. Hull Posted: 18 June 2010 01:57 PM [ # 4 ] Joined: 2007-02-06132 posts Sry for the long delay - finally got everything set up locally and database transferred over - running on the latest version of MAMP PRO and the latest EE 2.0.2. Everything seems to be working fine now, so I'm thinking it might have been some combination of the Windows/MySQL box I was running the online install on. Just to be sure before I go forward though - is there a maximum amount of custom fields I can have per channel? These are a mix of text and text area, some fie