I have been trying to find who deleted Store Procedure in MYSQL Database. All I got his
SELECT * FROM mysql.general_log WHERE user_host rlike '(user)+' ;
But not able to fetch anything .
Is there any best understandable way to recover the Deleted Store procedure or any other object in MYSQL.
Execute
show variables like 'gen%';
Ensure that general_log is ON.
Look for general log filename.
Execute
show variables like 'data%';
Look for data directory root path.
Go to the data directory root. Copy the general log file somewhere.
Open maked log copy in any text editor. Search it for Query event and DROP PROCEDURE statement, look for connection number.
Search the file from the line found to the start of file (up) for this connection number. Look for closest Connect event for this connection number, and look the account.
I am having the weirdest error of all.
Sometimes, when creating or altering tables, I get the 'table already exists' error. However, DROP TABLE returns '#1051 - unknown table'. So I got a table I cannot create, cannot drop.
When I try to drop the database, mysqld crashes. Sometimes it helps to create another db with different name, sometimes it does not.
I use a DB with ~50 tables, all InnoDB. This problem occurs with different tables.
I experienced this on Windows, Fedora and Ubuntu, MySQL 5.1 and 5.5. Same behaviour, when using PDO, PHPMyAdmin or commandline. I use MySQL Workbench to manage my schema - I saw some related errors (endlines and stuff), however none of them were relevant for me.
No, it is not a view, it is a table. All names are lowercase.
I tried everything I could google - flushing tables, moving .frm files from db to db, reading mysql log, nothing helped but reinstalling the whole damn thing.
'Show tables' reveals nothing, 'describe' table says 'table doesn't exist,' there is no .frm file, yet 'create table' still ends with an error (and so does 'create table if not exists') and dropping database crashes mysql
Related, yet unhelpful questions:
Mysql 1050 Error "Table already exists" when in fact, it does not
MySQL Table does not exist error, but it does exist
Edit:
mysql> use askyou;
Database changed
mysql> show tables;
Empty set (0.00 sec)
mysql> create table users_has_friends (id int primary key);
ERROR 1050 (42S01): Table '`askyou`.`users_has_friends`' already exists
mysql> drop table users_has_friends;
ERROR 1051 (42S02): Unknown table 'users_has_friends'
And such, all the same: table doesn't exist, yet cannot be created;
mysql> drop database askyou;
ERROR 2013 (HY000): Lost connection to MySQL server during query
Names change, this is not the only table / database I've run into problems with
I've seen this issue when the data file is missing in the data directory but the table definition file exists or vise-versa. If you're using innodb_file_per_table, check the data directory to make sure you have both an .frm file and .ibd file for the table in question. If it's MYISAM, there should be a .frm, .MYI and a .MYD file.
The problem can usually be resolved by deleting the orphaned file manually.
Going on a wild guess here, but it seems like innodb still has an entry for your tables in a tablespace, probably in ibdata. If you really don't need any of the data, or if you have backups, try the following:
Delete all schemas (excluding mysql)
shut down the database
Make sure that all folders in your data directory have been removed properly (again, excluding mysql)
delete ibdata and log files
restart the database. It should recreate the tablespace and logs from scratch.
The fix turns out to be easy; at least what I worked out, worked for me.
Create a table "zzz" on another MySQL instance, where zzz is the problem table name.
(i.e. if the table is called schrodinger, substitute that for zzz whever written.)
It does not matter what the definition of the table is. It's a temporary dummy;
Copy the zzz.frm file to the database directory on server where the table should be,
making sure file ownership and permissions are still correct on the file.
On MySQL, you can now do "show tables;", and the table zzz will be there.
mysql> drop table zzz;
...should now works. Clear any zzz.MYD or ZZZ.MYI files in the directory if necessary.
I doubt this is a direct answer to the question case here, but here is how I solved this exact perceived problem on my OS X Lion system.
I frequently create/drop tables for some analytics jobs I have scheduled. At some point, I started getting table already exists errors half-way through my script. A server restart typically solved the issue, but that was too annoying of a solution.
Then I noticed in the local error log file this particular line:
[Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
This gave me the idea that maybe if my tables contained capital letters, MySQL would be fooled into thinking they are still there even after I had dropped them. That turned out to be the case and switching to using only lowercase letters for table names made the problem go away.
It is likely the result of some misconfiguration in my case, but hopefully this error case will help someone waste less time trying to find a solution.
This is an old question but I just hit the same issue and an answer in one of the related issues linked at the top was just what I needed and far less drastic than deleting files, tables, shutting down the server etc.
mysqladmin -uxxxxxx -pyyyyy flush-tables
If will are stock with this error 1051 and you only want to delete the database and import this again do this steps and all gonna be just fine....
in Unix envoriment AS root:
rm -rf /var/lib/mysql/YOUR_DATABASE;
OPTIONAL -> mysql_upgrade --force
mysqlcheck -uUSER -pPASS YOUR_DATABASE
mysqladmin -uUSER -pPASS drop YOUR_DATABASE
mysqladmin -uUSER -pPASS create YOUR_DATABASE
mysql -uUSER -pPASS YOUR_DATABASE < IMPORT_FILE
Regards,
Christus
In my case the problem was solved by changing the ownership of the mysql data directory to the user that ran the application. (In my case it was a Java application running Jetty webserver.)
Even though mysql was running and other apps could use it properly, this app had a problem with that. After changing the data directory ownership and resetting the user's password, everything worked properly.
I was having this problem with one particular table. Reading the possible solutions i've did some steps like:
Search for orphan files: didn't exist anyone;
execute: show full tables in database;: didn't see the problematic one;
execute: describe table;: returned table doesn't exist;
execute: SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';: returned Empty set;
Search by the phpMyAdmin manually the query above: didn't exist;
And, after those steps, i check again with the show tables; and... vualá! the problematic table was gone. I could create it and drop it with the same problematic name with no problem, and i didn't have even to restart the server! Weird...
I had this problem and hoped deleting the IBD file would help as posted above but it made no difference . MySQL only recreated a new IBD file . In my case, there are actually similar tables in other databases in the same MySQL instance . Since the FRM file was missing , I copied the FRM file from the similar table in another database , restarted MySQL and the table worked correctly .
I ran into this error after I created a table and deleted it, then wanted to create it again.
In my case, I had a self-contained dump file so I dropped my schema, recreated it and imported tables and data using the dump file.
It happens at our site (but rarely) usually when an "event" happens while running certain scripts that do a lot of rebuilding. Events include network outages or power problems.
What I do for this on the very rare occasions it happens - I use the heavy-handed approach:
I needed to simply get rid-of-and-rebuild the particular table. I'm usually in a position that this is OK since the table is being built. (Your situation may be different if you need to recover data)
As an admin, go into the mysql installation (on windows its may be "...program files/mysql/MySQL Server xx/data/<schemaname>
Find the offending file with the table name in the <schemaname> folder - and delete it.
Check for orphaned temporary files and delete them too. #...frm files if they happen to be there.
MySQL will let you CREATE the table again
I've had this problem on a couple of different databases over a long time (years). It was a stumper because the contradicting messages. The first time I did a variation of the deleting/rebuilding/renaming database as described in the other answers and managed to get things going, but it definitely takes longer that way. Lucky for me it's always happened to reference tables that are being rebuilt - DROP'd and CREATEd - typically in the morning. Rarely got the problem but came to recognize it as a special quirky case. (I'll restate : if you need to recover the data look to the other solutions.)
it isn't a table belonging to another user, or in another database
it isn't the upper/lower case issue, I use all lower-case, but that was an interesting issue!
it was extra extra frustrating seeing responses with variations of "it definitely was <there/not-there/some-other-user-table-case> and you're just not doing it right" :)
the table didn't show on "show tables"
the table was (always was/had been) an INNODB table.
trying to DROP the table gave the error message that the table doesn't exist.
but trying to CREATE the table gave the error message that the table already exists.
using mysql 5.0 or 5.1
REPAIR is ineffective for this problem
As a security minded person, in the off chance that an SQL injection ever happens I'd like to minimize the damage caused. One such possibility is that there are queries that can read and write information to a file on the local file system. This is clearly a major issue in the case of a security breach, and the usage for these commands is fairly limited in day to day usage. Optionally, it could be turned on for an isolated period of time in case I have the need for import and exporting data, but I would like to have it turned off explicitly any other time. No amount of googling or skimming the MySQL manual has led me to a specific setting that allows me to disable this option.
I know I could easily just revoke the privilege for all users, but I'd like a simpler solution that by default increases my security (at least in this specific case).
Does anyone know of any setting or way to deactivate any file interactions in MySQL?
Thanks!
http://dev.mysql.com/doc/refman/5.6/en/load-data.html says:
Also, to use LOAD DATA INFILE on server files, you must have the FILE privilege.
http://dev.mysql.com/doc/refman/5.6/en/select-into.html says:
The SELECT ... INTO OUTFILE 'file_name' form of SELECT writes the selected rows to a file. The file is created on the server host, so you must have the FILE privilege to use this syntax.
You can also set the secure_file_priv config variable:
By default, this variable is empty. If set to the name of a directory, it limits the effect of the LOAD_FILE() function and the LOAD DATA and SELECT ... INTO OUTFILE statements to work only with files in that directory.
In Percona Server, secure_file_priv has an additional usage:
When used with no argument, the LOAD_FILE() function will always return NULL. The LOAD DATA INFILE and SELECT INTO OUTFILE statements will fail with the following error: “The MySQL server is running with the –secure-file-priv option so it cannot execute this statement”.
I am trying to upload a 32mb MYSQL database into a pre-existing database, but the php admin on my shared hosting has a 10mb limit... I have tried zipping it up - but when the server unzips the database, the uncompressed file is too large for the server to handle.
Is it possible to split the database up and upload it by pasting it in parts as an SQL query - I assume I would need each chunk to have something at the start of it which says
"Import this data into the pre-existing tables in the database"
What would this be?
At the moment there is a few hundred lines saying things like "CREATE" and "INSERT INTO"
You might try connecting to the database remotely with mysql workbench, or command line tool mysql. If you can do that, you can run:
source c:/path/to/your/file.sql
and you won't be constrained by phpmyadmin's upload size restrictions. Most shared hosting I've seen allows it. If not, you may just need to grant permissions for the user#host in phpmyadmin (or whatever the interface is).
The dump file created by mysqldump is just a set of SQL statements that will rebuild your tables.
To load it in in chunks I'd recommend either dumping it out in sets of tables and loading them one by one or if required the dump file should be roughly in the same (pseudo) format:
Set things up ready for loading
CREATE TABLE t1;
INSERT INTO TABLE t1...;
INSERT INTO TABLE t1...;
CREATE TABLE t2;
INSERT INTO TABLE t2...;
INSERT INTO TABLE t2...;
Finalise stuff after loading
You can manually split the file up by keeping the commands at the start and finish and just choosing blocks for individual tables by looking for their CREATE TABLE statements.
I have a database backup for which SQL Server Management Studio says that it has three files in it: an .mdf file, an .ndf file and one .ldf file. This secondary data file (the .ndf one) was created for no obvious reason, so I want to remove it altogether (without losing data, of course), preferably during while the database is being restored from the backup.
Is this at all doable?
Ok, found a solution.
First back up the database.
Execute this:
USE database_name;
Then execute this, and replace logical_ndf_file_name with the logical name of your NDF file (which you can easily find out via Database->Properties_Files):
DBCC SHRINKFILE('logical_ndf_file_name', EMPTYFILE);
ALTER DATABASE database_name REMOVE FILE logical_ndf_file_name;
I ran the empty followed by ndf drop during produciton load successfully. I think it is important to run the drop ndf in the same transaction as the empty to ensure the database doesn't try to write to the file you are deleting, but then after an empty the database marks the files unusable, evidenced by attempting another empty shorty after.