Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

mysql #1030 - Got error 127 from storage engine

2,548 views
Skip to first unread message

Chris Sharman

unread,
Apr 27, 2005, 3:56:34 AM4/27/05
to
Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9,
php_msql client 3.23.49

Using the issue tracker 4.0.4 package, it broke with no error indication.
Using phpmyadmin indicates #1030 - Got error 127 from storage engine
on the issues table.

I'm guessing it's a mysql corruption.
Can anyone confirm ?
How can I fix it ?
Is there any known issue which could cause it ?

Cross-posted to VAMP

Thanks,
Chris

Mike Rechtman

unread,
Apr 27, 2005, 4:33:41 AM4/27/05
to

Chris Sharman wrote:
> Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9,
> php_msql client 3.23.49

<most of OP snipped>
>
> Cross-posted to VAMP
^^^^ Is this a NNTP group,
and if so what is its full name, pretty please.
>
> Thanks,
> Chris
>
Thanks,
Mike

issinoho

unread,
Apr 27, 2005, 4:38:28 AM4/27/05
to

Possible database corruption, have you tried repairing the table,

REPAIR TABLE <table-name>

Ref,
http://www.databasejournal.com/features/mysql/article.php/10897_3300511_2

Chris Sharman

unread,
Apr 27, 2005, 4:54:37 AM4/27/05
to
Mike Rechtman wrote:
>> Cross-posted to VAMP
>
> ^^^^ Is this a NNTP group,
> and if so what is its full name, pretty please.

No.
Meant to post it, sorry.
http://www.issinoho.com:8080/phpbb2/index.php
New & quiet at present, but hopefully will become a useful resource.

Chris

issinoho

unread,
Apr 27, 2005, 4:56:10 AM4/27/05
to

Chris Sharman

unread,
Apr 27, 2005, 5:23:31 AM4/27/05
to
issinoho wrote:
> Chris Sharman wrote:
>> Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9,
>> php_mysql client 3.23.49

>>
>> Using the issue tracker 4.0.4 package, it broke with no error indication.
>> Using phpmyadmin indicates #1030 - Got error 127 from storage engine
>> on the issues table.
>>
>> I'm guessing it's a mysql corruption.
>> Can anyone confirm ?
>> How can I fix it ?
>> Is there any known issue which could cause it ?
>
> Possible database corruption, have you tried repairing the table,
>
> REPAIR TABLE <table-name>
>
> Ref,
> http://www.databasejournal.com/features/mysql/article.php/10897_3300511_2

Thanks for that - repaired, but lost 9 out of 12 rows - this is only a
test table at present, but that data loss doesn't encourage me to use
this in earnest - is mysql usually this unreliable ?
This is about the first day the database has been tried out by more than
one user.

Thanks, Chris

issinoho

unread,
Apr 27, 2005, 5:43:27 AM4/27/05
to

VAMP has been running flawlessly for months now; I've also used MySQL
both on Linux & Windows and have never encountered corruption or loss.

You may just be unlucky :-(

For the record, VAMP is running on 4.1.8, perhaps (9) has some issues;
maybe you could backfit (8) if you continue to have a problem.

Mike Rechtman

unread,
Apr 27, 2005, 5:41:14 AM4/27/05
to

Chris S. & issinoho
Thanks for the pointer.
Mike.

Chris Sharman

unread,
Apr 27, 2005, 6:16:58 AM4/27/05
to
issinoho wrote:
> Chris Sharman wrote:
>> Thanks for that - repaired, but lost 9 out of 12 rows - this is only a
>> test table at present, but that data loss doesn't encourage me to use
>> this in earnest - is mysql usually this unreliable ?
>> This is about the first day the database has been tried out by more
>> than one user.
>
> VAMP has been running flawlessly for months now; I've also used MySQL
> both on Linux & Windows and have never encountered corruption or loss.
>
> You may just be unlucky :-(
>
> For the record, VAMP is running on 4.1.8, perhaps (9) has some issues;
> maybe you could backfit (8) if you continue to have a problem.

That's something - what sort of usage are you seeing ?
My installation was ok until yesterday, when I rolled issue-tracker out
from me personally to 3/4 other users - and one of them entereed some
data at more or less the same time as me.
I wonder if it relates to the version discrepancy between mysql server &
the php mysql client - although I see from php/php_info.php that you're
running a nearly identical config to mine.

I also get this warning from phpMyAdmin:
"The mbstring PHP extension was not found and you seem to be using
multibyte charset. Without mbstring extension phpMyAdmin is unable to
split strings correctly and it may result in unexpected results."

As I don't seem to have an mbstring extension (I assume the VMS port
doesn't have it), and I'm not aware of any non-ascii character
requirements (on our UK English site) I've been ignoring it.

Thanks
Chris

issinoho

unread,
Apr 27, 2005, 8:19:02 AM4/27/05
to

I also have the mbstring comment in phpmyadmin.

Carl Karcher

unread,
Apr 27, 2005, 6:56:56 AM4/27/05
to
In a previous article, Chris Sharman <chris....@sorry.nospam> wrote:

->Thanks for that - repaired, but lost 9 out of 12 rows - this is only a
->test table at present, but that data loss doesn't encourage me to use
->this in earnest - is mysql usually this unreliable ?
->This is about the first day the database has been tried out by more than
->one user.

I've seen this (the dreaded 127 error) as well with a PHP application
written by a completely inexperienced non-programmer (which of course
shouldn't matter). Yet MYSQL has run for weeks reliably as the backend
(no php) for RT - a far more complex and intense application (see
http://www.bestpractical.com/rt/) with just one little problem:

SELECTING or INSERTING TEXTLONG columns (fields) longer than 65021 bytes
(which RT uses for column content in it's attachment table) will
result in:

ERROR 2027: Malformed packet
or
ERROR 2013: Lost connection to MySQL server during query

This occurs when either the client or server is vms (7.3-2
TCP5.4-ECO2) and the request traverses a network. When both client and
server are vms, all is well. It's not yet clear if this is a mysql
problem.

--
-- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison
-- karcher.n...@waisman.wisc.edu

Jean-François Piéronne

unread,
Apr 27, 2005, 4:13:53 PM4/27/05
to
Hi,

> Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9,
> php_msql client 3.23.49
>
> Using the issue tracker 4.0.4 package, it broke with no error indication.
> Using phpmyadmin indicates #1030 - Got error 127 from storage engine
> on the issues table.
>

Which storage engine have you used?

Only Innodb work correctly, MyISAM is know to have some problem.
Anyway ony Innodb support transaction, so I strongly suggest to only use
this storage engine, this is the default on OpenVMS and probably in
future MySQL version.

> I'm guessing it's a mysql corruption.
> Can anyone confirm ?
> How can I fix it ?
> Is there any known issue which could cause it ?
>
> Cross-posted to VAMP
>
> Thanks,
> Chris
>

Jean-François

Chris Sharman

unread,
Apr 28, 2005, 3:59:01 AM4/28/05
to
Jean-François Piéronne wrote:
>> Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9,
>> php_msql client 3.23.49
>>
>> Using the issue tracker 4.0.4 package, it broke with no error indication.
>> Using phpmyadmin indicates #1030 - Got error 127 from storage engine
>> on the issues table.
>
> Which storage engine have you used?
>
> Only Innodb work correctly, MyISAM is know to have some problem.
> Anyway ony Innodb support transaction, so I strongly suggest to only use
> this storage engine, this is the default on OpenVMS and probably in
> future MySQL version.

Innodb is the default, right ? I didn't change it. [vms]my.cnf has lines
relating to innodb, and the rest are commented out. I didn't make any
changes.
I wondered about skip-networking & safe-updates, but didn't turn them
on, since I didn't really understand the implications. Should I ?

But the repair article I saw said it was only for MyISAM - which may be
why it didn't repair innodb that well, I suppose.

Thanks,
Chris

Jean-François Piéronne

unread,
Apr 28, 2005, 10:25:12 AM4/28/05
to
Chris Sharman wrote:
> Jean-François Piéronne wrote:
>
>>> Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9,
>>> php_msql client 3.23.49
>>>
>>> Using the issue tracker 4.0.4 package, it broke with no error
>>> indication.
>>> Using phpmyadmin indicates #1030 - Got error 127 from storage engine
>>> on the issues table.
>>
>>
>> Which storage engine have you used?
>>
>> Only Innodb work correctly, MyISAM is know to have some problem.
>> Anyway ony Innodb support transaction, so I strongly suggest to only
>> use this storage engine, this is the default on OpenVMS and probably
>> in future MySQL version.
>
>
> Innodb is the default, right ? I didn't change it. [vms]my.cnf has lines
> relating to innodb, and the rest are commented out. I didn't make any
> changes.

Right, Innodb is the default, but you can specify when you create a
table which storage engine you want to use for this table.
You can use
mysql> show table status like 'my_table';

to check which storage engine is used.

Chris Sharman

unread,
Apr 29, 2005, 3:51:30 AM4/29/05
to jf.pi...@laposte.net
Jean-François Piéronne wrote:
> Chris Sharman wrote:
>> Jean-François Piéronne wrote:
>>>> Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9,
>>>> php_msql client 3.23.49
>>>>
>>>> Using the issue tracker 4.0.4 package, it broke with no error
>>>> indication.
>>>> Using phpmyadmin indicates #1030 - Got error 127 from storage engine
>>>> on the issues table.
>>>
>>> Which storage engine have you used?
>>>
>>> Only Innodb work correctly, MyISAM is know to have some problem.
>>> Anyway ony Innodb support transaction, so I strongly suggest to only
>>> use this storage engine, this is the default on OpenVMS and probably
>>> in future MySQL version.
>>
>> Innodb is the default, right ? I didn't change it. [vms]my.cnf has
>> lines relating to innodb, and the rest are commented out. I didn't
>> make any changes.
>
> Right, Innodb is the default, but you can specify when you create a
> table which storage engine you want to use for this table.
> You can use
> mysql> show table status like 'my_table';
>
> to check which storage engine is used.

You've guessed it JF - every table in every db has engine MyISAM, not
innodb. That could be my problem, I guess. But I haven't created
anything myself - I just ran the setup stuff I was told to run for
mysql, and then for issuetracker - is there some way to check/change the
default ? Some way to change (unload/drop/create/reload) existing tables
& dbs ? Would it give the applications any problems, or would the
changes be transparent ?

Thanks,
Chris

Chris Sharman

unread,
Apr 29, 2005, 3:54:03 AM4/29/05
to
Jean-François Piéronne wrote:
> Chris Sharman wrote:
>> Jean-François Piéronne wrote:
>>>> Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9,
>>>> php_msql client 3.23.49
>>>>
>>>> Using the issue tracker 4.0.4 package, it broke with no error
>>>> indication.
>>>> Using phpmyadmin indicates #1030 - Got error 127 from storage engine
>>>> on the issues table.
>>>
>>> Which storage engine have you used?
>>>
>>> Only Innodb work correctly, MyISAM is know to have some problem.
>>> Anyway ony Innodb support transaction, so I strongly suggest to only
>>> use this storage engine, this is the default on OpenVMS and probably
>>> in future MySQL version.
>>
>> Innodb is the default, right ? I didn't change it. [vms]my.cnf has
>> lines relating to innodb, and the rest are commented out. I didn't
>> make any changes.
>
> Right, Innodb is the default, but you can specify when you create a
> table which storage engine you want to use for this table.
> You can use
> mysql> show table status like 'my_table';
>
> to check which storage engine is used.

You've guessed it JF - every table in every db has engine MyISAM, not


innodb. That could be my problem, I guess. But I haven't created
anything myself - I just ran the setup stuff I was told to run for
mysql, and then for issuetracker - is there some way to check/change the
default ? Some way to change (unload/drop/create/reload) existing tables
& dbs ? Would it give the applications any problems, or would the
changes be transparent ?

Thanks,
Chris

>> I wondered about skip-networking & safe-updates, but didn't turn them

issinoho

unread,
Apr 29, 2005, 6:55:50 AM4/29/05
to

For the record, VAMP is using InnoDB, however some other databases
within my MySQL installation are in fact MyISAM. Now I haven't
explicitly set the engine type at any point, so I can only conclude that
the SQL script that creates the database is specifying it.

Chris Sharman

unread,
Apr 29, 2005, 11:22:19 AM4/29/05
to
Jean-François Piéronne wrote:

> Chris Sharman wrote:
>
>> Jean-François Piéronne wrote:
>>> Which storage engine have you used?
>>>
>>> Only Innodb work correctly, MyISAM is know to have some problem.
>>> Anyway ony Innodb support transaction, so I strongly suggest to only
>>> use this storage engine, this is the default on OpenVMS and probably
>>> in future MySQL version.
>>
>> Innodb is the default, right ? I didn't change it. [vms]my.cnf has
>> lines relating to innodb, and the rest are commented out. I didn't
>> make any changes.
>
> Right, Innodb is the default, but you can specify when you create a
> table which storage engine you want to use for this table.
> You can use
> mysql> show table status like 'my_table';
>
> to check which storage engine is used.

Seems like MyISAM is the default, and the only engine supported for the
system tables.
I've put "default-table-type=innodb" in the [mysqld] section of my.cnf
and restarted - it wasn't there before.

I've also done: "alter table <name> type=innodb;" to all my issue
tracker tables (but not to mysql or mysql_help). Doing that seemed to
lose some data too, but I'm hoping that that will be the end of the
suspect data.

What are the known problems with the MyISAM engine ?
What engine are other people seeing used (show table status;) ?
Has anyone got a default-table-type set ?

Thanks,
Chris

Jean-François Piéronne

unread,
May 2, 2005, 3:39:16 AM5/2/05
to
Chris Sharman wrote:
> Jean-François Piéronne wrote:
>
>> Chris Sharman wrote:
>>
>>> Jean-François Piéronne wrote:
>>>
>>>> Which storage engine have you used?
>>>>
>>>> Only Innodb work correctly, MyISAM is know to have some problem.
>>>> Anyway ony Innodb support transaction, so I strongly suggest to only
>>>> use this storage engine, this is the default on OpenVMS and probably
>>>> in future MySQL version.
>>>
>>>
>>> Innodb is the default, right ? I didn't change it. [vms]my.cnf has
>>> lines relating to innodb, and the rest are commented out. I didn't
>>> make any changes.
>>
>>
>> Right, Innodb is the default, but you can specify when you create a
>> table which storage engine you want to use for this table.
>> You can use
>> mysql> show table status like 'my_table';
>>
>> to check which storage engine is used.
>
>
> Seems like MyISAM is the default, and the only engine supported for the
> system tables.

Correct, don't convert system tables, MyISAM is the only supported
engine for the system tables (mysql database)

> I've put "default-table-type=innodb" in the [mysqld] section of my.cnf
> and restarted - it wasn't there before.
>

It was in the MYSQL_ROOT:[VMS.MYSQL]run_mysqld.com
which use the qualifier --default-storage-engine=InnoDB

note also the --ansi qualifier, if you don't need this just remove it.

> I've also done: "alter table <name> type=innodb;" to all my issue
> tracker tables (but not to mysql or mysql_help). Doing that seemed to
> lose some data too, but I'm hoping that that will be the end of the
> suspect data.
>
> What are the known problems with the MyISAM engine ?

The most frequent problem is a corruption of the lengh of the record.
Most of the time a repair fix the problem.


> What engine are other people seeing used (show table status;) ?
> Has anyone got a default-table-type set ?
>


I know site which use MySQL on VMS using InnoDB on multi GB database
with millions records without more problems than on another OS, which
do't mean without any problems ;-)


Jean-François

madhu...@hotmail.com

unread,
Nov 16, 2017, 1:16:19 AM11/16/17
to
Hi

i m getting a very peculiar error can you please help me out

http://prntscr.com/hb3c5m

1030 got error -1 from storage engine

Stephen Hoffman

unread,
Nov 16, 2017, 10:15:58 AM11/16/17
to
On 2017-11-16 06:16:17 +0000, madhu...@hotmail.com said:

> On Wednesday, April 27, 2005 at 1:26:34 PM UTC+5:30, Chris Sharman wrote:
>> Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9, php_msql client 3.23.49
>
>
> i m getting a very peculiar error can you please help me out
>
> http://prntscr.com/hb3c5m
>
> 1030 got error -1 from storage engine

I'm going to assume that a ~dozen-year-old posting from the
OpenVMS-focused comp.os.vms usenet news newsgroup probably isn't
directly related to the operating system nor to the MySQL configuration
that's in use and that's returning this particular "1030 got error -1
from storage engine" error, and will assume that some search engine
probably led you somewhat astray; to an old posting found in the Google
Groups web interface to the comp.os.vms newsgroup and its archives.

That "1030 got error -1 from storage engine" is usually claimed to be a
storage engine error, either due to a configuration setting error, or
due to an out-of-storage error.

Some probably-closer-to-what-you-want and
probably-closer-to-what-you're-running discussions:

https://dba.stackexchange.com/questions/111529/mysql-error-1030-got-error-1-from-storage-engine-when-doing-insert-update

https://stackoverflow.com/questions/26591708/mysql-error-1030-got-error-1-from-storage-engine

https://bugs.mysql.com/bug.php?id=69907

If those don't work, I'd gather a few more details from the MySQL
database logs, and would post a few more details at either
StackOverflow or maybe at one of the MySQL-related forums; version,
host operating system and version, and the relevant parts of the
database log around the error. https://forums.mysql.com/index.php?82=

If you are running MySQL, see if you're running the most recent MySQL.

If you really are running MySQL on OpenVMS, there are some notes and a
recent beta of MariaDB — MariaDB is a very-compatible fork of MySQL —
available:
http://neilrieck.net/docs/openvms_notes_mysql_mariardb.html
http://www.theberrymans.com/php_kits/

And welcome to the comp.os.vms usenet news newsgroup!


--
Pure Personal Opinion | HoffmanLabs LLC

Neil Rieck

unread,
Nov 17, 2017, 7:30:52 AM11/17/17
to
1) What version of MySQL and OpenVMS are you using?

2) I see you are using testdb, testtable, and testid. Is this a new installation or something that has worked for years but now is presenting a problem (because you are using test* to debug a problem), or something you installed years ago but haven't used for a long while?

Just googling "mysql 1030" I see that others claim to have fixed this problem with the chown command.

On OpenVMS this is done with:

$set file filespec/owner=whatever1/prot=(whatever2)
where filespec is usually all the stuff in, and under, the MySQL root

###

As Hoff has already suggested, you may wish to replace MySQL-5.* with MariaDB-5.5-58 from Mark Berryman BUT I suggest you get everything working properly with your current installation before you begin (unless you only have a test database). You do not want to run into file ownership and protection problems when you invoke the script to upgrade your database.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net/docs/openvms_notes_mysql_mariardb.html

0 new messages