Unable to delete a MySQL InnoDB table - innodb

I am using MySQL 5.1.56
I have a DB with about 70 tables and I have an issue with a particular corrupted table e.g. Table_X
When I try to access the table
mysql> select * from Table_x;
ERROR 1105 (HY000): Failed to read from the .par file
I am unable to add partitions to the table.
When I try to drop the table I see the below errors.
mysql> drop table Table_X;
ERROR 1051 (42S02): Unknown table 'Table_X'
The create query gives the error: ERROR 1050 (42S01): Table 'Table_X' already exists.
In my DB files locations, I can see the corresponding Table_X.frm, Table_X.ibd and Table_X.par files. But in addition, I also see a file '#sql-Table_X.frm' in the location.
When I check the 'Tables' table in the information_Schema DB, the Engine value is NULL for this particular table, where as it should have been InnoDb.
The table seems to be corrupted somehow.
I tried the Flush-tables command,but that did not help as well. I am still unable to drop and recreate the table.
I do not wish to take a backup of this particulate table, but I need to preserve other tables of the database. Is there any way, I can just recreate this individual table without having to restore the entire Database.

You can try to repair the table with the following statement :
REPAIR TABLE Table_X;
Take care, such query can induce a loss of data, but since you are trying to DROP the table, I guess this is not a matter for you.
You could also try to use the FRM file as a source for your table with
REPAIR TABLE Table_X USE_FRM;
PS : Can you give us the result of the following query ?
CHECK TABLE Table_X;
References :
https://www.tutorialspoint.com/mysql/mysql_repair_table_statement.htm
https://www.tutorialspoint.com/mysql/mysql_check_table_statement.htm

Related

MariaDB table missing but I can't recreate it

Something went wrong during a structure synchronization between two databases.
One of our production databases now is missing a key table 'customers' (which just about every other table has foreign keys to)
I'm trying to recreate the table from last night's backup (I don't want to restore the entire db - just recreate this table as the data in it does not change that much and I don't want to lose the transactional data from today)
The hassle seems to be that all the foreign key data for this table still exists in INFORMATION_SCHEMA.KEY_COLUMN_USAGE and I am getting 121 and 150 errors when I try run the CREATE TABLE query.
I've manually deleted all FK to the missing table and I am still getting errno 150 when trying to recreate the table. Any ideas where else there might be lost references to this table that is stopping me creating it again?
This was eventually resolved by multiple consultations of the SHOW ENGINE INNODB STATUS query.
The missing table had various indexes - example on the customer name there was an index "customer_name_idx". The CREATE TABLE query asked for this index to be created. The show engine innodb status return was "could not create table because index customer_name_idx already exists."
There was no reference to this index, to any primary key or to the table itself in any of the meta-data tables - I checked
INFORMATION_SCHEMA.INNODB_SYS_INDEXES
INFORMATION_SCHEMA.TABLE_SCHEMA
INFORMATION_SCHEMA.STATISTICS -INFORMATION_SCHEMA.TABLE
so I could not explain why this error was being thrown.
My guess, after the fact, is that MySQL is holding a cached copy of the information_schema meta data in memory and was consulting that, and maybe that only gets refreshed if you restart MySQL?
The solution was to give the indexes new names as a short term fix, and to rename them during our next scheduled downtime.
Once these were made, the table was created and the backup data could be reinstated.

MariaDB: SELECT INSERT from ODBC CONNECT engine from SQL Server keeps causing "error code 1406 data too long"

Objective: Using MariaDB I want to read some data from MS SQL Server (via ODBC Connect engine) and SELECT INSERT it into a local table.
Issue: I keep geting "error code 1406 data too long" even if source and destination varchar fields have the very same size (see further details)
Details:
The query which I'm trying to execute is in the form:
INSERT INTO DEST_TABLE(NUMERO_DOCUMENTO)
SELECT SUBSTR(TRIM(NUMERO_DOCUMENTO),0,5)
FROM CONNECT_SRC_TABLE
The above is the very minimal subset of fields which causes the problem.
The source CONNECT Table is actually a view inside SQL Server. The destination table has been defined so to be identical to the the ODBC CONNECT Table (same field names, same NULL constranints, same filed types ans sizes)
There's no issue on a couple of other VARCHAR fields
The issue is happening with a filed NUMERO_DOCUMENTO VARCHAR(14) DEFAULT NULL where the max length from the input table is 14
The same issue is also happening with 2 other fields ont the same table
All in all it seems to be an issue with the source data rather then the destination table.
Attemped workarounds:
I tried to force silent truncation but, reasonably, this does not make any difference: Error Code: 1406. Data too long for column - MySQL
I tried enlarging the destination field with no appreciable effect NUMERO_DOCUMENTO VARCHAR(100) DEFAULT NULL
I tried to TRIM the source field (hidden spaces?) and to limit its size at source to no avail: INSERT INTO DEST_TABLE(NUMERO_DOCUMENTO) SELECT SUBSTR(TRIM(NUMERO_DOCUMENTO),0,5) FROM CONNECT_SRC_TABLE but the very same error is always returned
Workaround:
I tried performing the same thing using a FOR x IN (src_query) DO INSERT .... END FOR and this solution seems to work: this means that the problem is not into the data itself but in how the engine performs the INSERT SELECT query

Copy SQLite table including metadata

I wanted to add a constraint to an existing column in my SQLite database. However, I read that it is not possible to do so.
I tried the solution from How do I rename a column in a SQLite database table?, but there seems to be missing the copying of all the metadata.
I pretty much want an exact copy of a given table, except for the new constraints.
How does the INSERT command look like to copy all the metadata, thus the indexes will increase correctly, for example.
I'm not a heavy user of sqlite3, but you can use the command line to get the data and "create table" and "create index" commands. I am using the 'History' DB from the Google chrome browser which has a table called "visits". The 'mode insert' command says to provide output in a format that can be used to input this data. The '.schema visits' command says to show the 'create table' and 'create index' statements. The 'select..' statement gives you the data. The database I used doesn't seem to have any foreign key constraints, but they could very well be part of the 'create table' information if your DB has any.
sqlite3 History
.mode insert
.schema visits
select * from visits;

SQLite dropped table not deleted

In the sqlite3 command line tool I dropped a table:
sqlite> DROP TABLE tableName;
It's a pretty big large table, so I would expect the sqlite file size to drop considerably. However, it hasn't changed at all.
What is the proper way to purge this table from the database completely?
The size of the file does not shrink when you delete a table in SQLite, you have to explicitely ask for it.
More info in the FAQ : http://www.sqlite.org/faq.html#q12
There are also some options to configure your database to have auto-vacuum enabled, you can find more info in the documentation of the VACUUM keyword here : http://www.sqlite.org/lang_vacuum.html and the PRAGMA option here : http://www.sqlite.org/pragma.html#pragma_auto_vacuum

SQLite "Drop table" error message: "SQL logic error or missing database"

I am running a SQLite database in memory and I am attempting to drop a table with the following command.
DROP TABLE 'testing' ;
But when I execute the SQL statement, I get this error
SQL logic error or missing database
Before I run the "Drop Table" query I check to make sure that the table exists in the database with this query. So I am pretty sure that the table exists and I have a connection to the database.
SELECT count(*) FROM sqlite_master WHERE type='table' and name='testing';
This database is loaded in to memory from a file database and after I attempt to drop this table the database is saved from memory to the file system. I can then use a third party SQLite utility to view the SQLite file and check to see if the "testing" exists, it does. Using the same 3rd party SQLite utility I am able to run the "Drop TABLE" SQL statement with out error.
I am able to create/update tables without any problems.
My questions:
Is there a difference between a memory database and a file database in SQLite when dropping a table?
Is there a way to disable the ability to drop a table in SQLite that I may have accentually turned on somehow?
Edit: It appears to have something to do with a locked table. Still investigating.
You should not have quotes in your DROP TABLE command. Use this instead:
DROP TABLE testing
I had the same problem when using Sqlite with the xerial jbdc driver in the version 3.7.2. and JRE7
I first listed all the tables with the select command as follows:
SELECT name FROM sqlite_master WHERE type='table'
And then tried to delete a table like this:
DROP TABLE IF EXISTS TableName
I was working on a database stored on the file system and so it seems not to effect the outcome.
I used the IF EXISTS command to avoid listing all the table from the master table first, but I needed the complete table list anyway.
For me the solution was simply to change the order of the SELECT and DROP.

Resources