I have an installation of Debian Stretch and a new installation of Mysql 8.0 (no changes in configuration yet). When I try to create a new user with:
mysql> CREATE USER 'myuser'#'localhost' IDENTIFIED BY 'xyz';
I got the following:
ERROR 1726 (HY000): Storage engine 'MyISAM' does not support system
tables. [mysql.db]
Any suggestion about what the problem could be?
Thank you
as #Mae suggested below, make sure you stop the server before you do any of these steps.
as #Sarel suggested this solution which performs all the steps I did below but does it the MySQL way which is probably safest.
mysqld --upgrade=FORCE
https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_upgrade
The server upgrades the data dictionary, the Performance Schema, and the INFORMATION_SCHEMA
Thanks, #Sarel!
My previous post for historical use:
I had restored a DB backup into my new dev MySQL 8 system without thinking and overwrote the MySQL database tables. It wasn't that hard to fix but just took a bit of hacking at it for a while and this is what fixed it.
alter table mysql.db ENGINE=InnoDB;
alter table mysql.columns_priv ENGINE=InnoDB;
after that, I was able to create a user with no problems.
The key was in the error message.
ERROR 1726 (HY000): Storage engine 'MyISAM' does not support system tables. [mysql.db]
So I knew it was mysql.db that was MyISAM and needed to be something else so I just changed it to InnoDB.
Hope that helps someone!
If your MySQL database is the wrong type that will work or the other alternative would be to initialize your db
mysqld --initialize
That'll recreate it all. If you can dump the SQL before you do that it's always best.
Do not run alter table to force it to change mysql.db to innodb. You will end up with a different error like 'Cannot load from mysql.db. The table is probably corrupted'. If you did do it the following will fix that too.
I restored a dump from 5.7 into a new 8.0 server and then had this problem.
To fix it stop the mysql service and then run this command to make mysql 8 upgrade the internal schemas:
mysqld --upgrade=FORCE
You can watch the logs to see its progress and if it has any errors.
I ran into the same problem after a fresh installation of MySQl 8.0 followed by reloading an old (v 5.7) dump file.
Solution was to delete and reinstall MySQL and this time created a new dump file from the 5.7 MySQL containing only my own tables excluding system tables and imported them into the v 8.0 MySQL. Everything works flawlessly.
You should maybe consider moving away from MyISAM. InnoDB is the default engine in MySQL since 5.6, MySQL 8.0 will be the last version that has limited support for it.
You can read up on the details in this Percona blog post
Different solution:
I had a MySQL dump of all my databases from MySQL 5.7, including the mysql table. After importing the whole dump folder (including this mysql table) I got this error.
After a complete reinstall of MySQL 8.0.21 and removing the mysql table from the dump folder everything worked as expected.
Related
I would like to use Oracle database instead of MySQL in Joomla. Is this possible with Joomla, is there a workaround or a solution on how to implement Oracle database with Joomla? Any information will be greatly appreciated.
It is said that it can be done, but it is not a job for beginners and took those guys 3 working days to do it.
Here's why that combination doesn't work by default:
The database and table creation script does not work without modification.
The connection and the database class are written to connect to MySQL and not to Oracle (so they all use MySQL functions).
Some of the extensions use native MySQL functions directly, instead of connecting using the Joomla Database interface (class).
This is what they did to make it work:
We fix the SQL installation script to accommodate the Oracle database in case of a new installation. In case of an existing installation, we export all the database, as well as its data to a SQL file, and then we modify the SQL file (using find and replace) to make it work with an Oracle database.
We load the modified installation file or the modified exported SQL file into the Oracle database.
We then create a copy of the Joomla database class, and then we modify all the functions to work with Oracle instead of MySQL.
We ensure that the Oracle drivers are properly installed and loaded by the php.ini file.
We rename the original MySQL database (you will know in the next step why) to something like database_name_old.
We switch to the new database class and fully test the website to see if some extensions are not working. If an extension ceases to work then it is a sign that this extensions is calling the original MySQL database (which no longer exists because it was renamed) directly.
Hopefully, you aren't a beginner and those guidelines will help you do it. Otherwise, check how much it might cost by visiting the page.
Backstory: I had this database dropped in my lap when the company, I began working for last October, won the contract. The developers gave me very little turn over, so I am digging back in my memory to when I maintained an Oracle DB in 2002. My skills are extremely dated, so please be gentle.
Oracle 10.2.0.0.0 Windows Server 2003
My customer now wants me to create a blank copy of an existing application/database for a future effort. My 1st idea was to clone the existing database and remove all the data. However, I seem to remember working on a project years ago that led me to believe I could clone the existing user/schema and not have the whole other database to maintain. There is a high possibility this new application will never be used, and I'd like to do the least amount of work as possible. The current database is small. Any suggestions would be appreciated.
You can export the database with the rows=n parameter:
exp username/password#db owner=abc rows=n
This will export everything except the data.
Then if you want to import it, you can change users if needed:
imp username/password#db fromuser=abc touser=xyz
I'd suggest to use datapump(expdp/impdp) from 10g onwards. You can go through following commands:
--Export dump in source server:
expdp user/password directory=oracle_directory dumpfile=mydump_abc.dmp logfile=mydump_abc_export.log schemas=abc content=metadata_only
--Import dump in destination server
impdp user/password directory=oracle_directory1 dumpfile=mydump_abc.dmp logfile=mydump_abc_restore.log remap_schema=abc:xyz
I have an installer wizard thing called 'install creator'. I want to include my mySQL database into the installer or find another way that the user, upon installation, can just use my database. Prob is-not everyone has MySQL installed on the computer and even then, the user doesn't know the name of the database or my password. Somehow the database must be created automatically upon install, and for my purposes, some of the tables created. How can one do this. Thanks
If you are just using MySQL as a local storage engine, as it seems to be what you are doing, then you should consider using Sqlite with JDBC, instead of MySQL. MySQL is really intended to be used on a server, where information from multiple users is stored, and where the database is accessed only indirectly through the programs that you create that run on the server. You could, in theory, package up MySQL and MySQL Connector/J which lets JDBC talk with MySQL; however, MySQL is a pretty big beast, and I don't think it's nice to do that to your users (also, don't forget that they might already have MySQL installed, and if you were to install MySQL for the first time, you would effectively be forcing them to use your root password). Unlike MySQL, sqlite is intended to provide the structure of SQL for use with lightweight, local file storage.
I have a web app hosted on BEA Weblogic 10.x with an Oracle 10g database backend.
It works perfectly with one database, but when we make a clone of it and try to use a different WebLogic and Oracle instance we are getting this error:
ERROR - Problem initializing invocation tracking - disabling
tracking xxxxclass.BadTableMappingException: Database column
xxxxPeriodEnding in database yyyyyyy, table zzzzzzz has an
unknown type: JDBC Type 91.
We get it every time we do a query that involves a column of type DATE. There was no ORA-XXXX code in the message.
I can access the database using SQL*Plus using the same access and do selects and updates on the same tables with no errors.
The answer to this question is not just a simple description of what a type 91 error is (although that will help) but what could be causing this given the circumstances described above.
I am using ojdbc14.jar for JDBC on both instances of weblogic.
I have no idea about the error, but have you considered the jdbc jar version and more importantly if the oracle DB needs to be updated.
I faced very weird problems with oracle, and struggled for a while to find at the end that installing some patches for oracle would solve the problem.
Set oracle.jdbc.V8Compatible=true.
This remaps the oracle DATE type to a DATETIME time in JDBC. This parameter was missing on the new Weblogic server.
I installed a default installation of PostgreSQL 8.4 on Windows 2003 Server, using the one-click installer provided. Running psql -l for the first time, I noticed there are three databases installed by default: postgres, template0, and template1.
Being security-minded, my initial reaction is to delete or change default configurations. However, I also know I haven't a clue regarding databases (as this install is my first step in self-learning about databases), so I thought I would ask first.
Is it safe to delete these?
Basically - no.
postgres database is here as a non-template database with reasonable guarantee that it exists - so any script that doesn't know where to connect to, can connect there.
if you will remove template1 - you will lose the ability to create new databases (at least easily).
template0 is there as a backup, in case your template1 got damaged.
While I can theoretically imagine a working database with no template* and postgres databases, the thing that bugs me is that i have no idea what (security-wise) you want to achieve by removing them.
You can delete the postgres but do not touch template0 or template1. The postgres database is there for convenience.