As others have said, you have problems which are goign to require serious re-evaluation of how you do business. You can keep patching things with virtual duct-tape, or you can come up with a plan to fix the problem.
However, a duct-tape solution for this particular problem would be to check for the existance of those columns first (using information_schema.columns), and then create the appropriate version of the stored procedure (or not at all). This will continue to create havoc, but it will at least buy you some time.
Check the MySQL error log. It looks like trying to read table 44 is actually crashing the server.
"Lost connection to MySQL server during query" is (or should be) heart-stopping time for a MySQL DBA because it often means that whatever your query just did has actually crashed the server.
The subsequent messages seem to bear this out:
mysqldump: Got error: 2003: Can't connect to MySQL server on 'localhost' (10061) when
trying to connect
Operation failed with exitcode 2
A quick test of mysqldump on Windows 7 against a MySQL server that is not running returns exactly that same error and exits with %ERRORLEVEL%
set to 2. The nature of error 10061 can be found with the perror
utility.
C:\>perror 10061
Win32 error code 10061: No connection could be made because the target machine actively refused it.
...so, check the MySQL error log. What's likely happening is that you're hitting corruption severe enough that in spite of innodb_force_recovery
, the MySQL Server is crashing. I will then usually restart on its own, but this takes time so may not complete before mysqldump gets an IP connection refused on the subsequent connection attempts. This should all show up in the error log.
I assume that when the dump does not yield any error, the table's data is non-corrupted.
Incorrect assumption. If the dump does not yield any error, it could also mean that that innodb_force_recovery
allowed the server to retrieve some of the data. A "successful" dump of a table only means it's not corrupted so severely that innodb_force_recovery
can't survive it.
1 (SRV_FORCE_IGNORE_CORRUPT)
Let the server run even if it detects a corrupt page. Try to make SELECT * FROM tbl_name
jump over corrupt index records and pages, which helps in dumping tables.
http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
Again, you should see chatter from InnoDB in the MySQL error log.
Final suggestion, don't use workbench. Use the mysql
command line client to explore the server schemata and use mysqldump
directly from the command line to try to restore individual schemas or individual databases.
update/additional:
how do you recover stored procedures? I get an error because they access corrupt tables
It shouldn't be because the procedures access corrupt tables, because stored procedures and functions aren't validated against their referenced tables in the way views are (drop a table that a view references, and then SHOW CREATE VIEW
doesn't work -- the same isn't the case with procs or functions)... MySQL doesn't care whether tables referenced by stored procedures and functions even exist (except at runtime)... however, unlike view definitions, which are stored in individual files, the definitions of procedures and functions are stored in the proc
table in the mysql
schema, which is a MyISAM table... so I would expect that you'd see error messages referencing that table and CHECK TABLE mysql.proc;
and REPAIR TABLE mysql.proc;
might get you going again. Note that the version of MySQL Server that you're using for your recovery needs to be the same release series (e.g. 5.5) or the table definition of mysql.proc
will be wrong... that shouldn't be the issue here, since if I read the question correctly, the crashed server and the recovery server are both 5.5.31.
If you can SELECT * FROM mysql.proc
then you can retrieve the definitions that way if for some reason the SHOW CREATE PROCEDURE
statement doesn't work.
And what options for a (partial) rescue are there for the tables that yielded an error in the dumps?
It depends on the nature and scope of the errors encountered. One option, discussed here, involves repeated INSERT ... SELECT ... LIMIT ... OFFSET
, extracting blocks of rows from readable pages into a MyISAM table (because you can't write to an InnoDB table while innodb_force_recovery
is on). There's also the Percona Data Recovery Tool for InnoDB, though I have never had occasion to use it.
Best Answer
As I understand the question, the scenario is one where users read values from the database outside a transaction, and later attempt updates. The requirement is that the database detect when a lost update might occur.
SQL Server does not provide a direct equivalent for the Oracle pseudo-column
ora_rowscn
because it does not exclusively use row versioning to implement transaction isolation levels (so row versioning information is not always present). Nevertheless, there are a number of ways to implement optimistic concurrency control with SQL Server.Using Row Version
One option is to add a
rowversion
column to the table. Often, this column will be given the same name in all tables (e.g.RV
). The general strategy is to read therowversion
value when reading data, and to check that the value is unchanged when updating the row later on:If the row has been modified, the
UPDATE
statement makes no changes and no error or warning is returned. It is up to the developer to check the number of rows affected by the statement, and take appropriate action (such as re-reading the source row, and alerting the user to the conflict).Using an optimistic cursor
Server-side cursors are often used in the scenario we are discussing. SQL Server contains native support for
OPTIMISTIC
server-side cursors via a number of interfaces (e.g. API, ODBC, Native Client). If arowversion
column is present, SQL Server uses that to implement optimistic concurrency, without the developer needing to retrieve and check therowversion
value explicitly. Using aTransact-SQL
cursor to demonstrate:If the row has been changed since data was read, a warning and an error is returned:
If the table does not contain a
rowversion
, SQL Server transparently uses a reliable checksum to detect row changes. The same warning and error is generated if the checksum comparison fails. Usingrowversion
is more efficient than using the internal checksums, but both are equally reliable.Note that a real implementation would be quite unlikely to use a global Transact-SQL cursor as shown above, but the concepts are the same when using whatever server-side cursor support is available within your development framework.