When issuing a statement to MySQL8 server:
SELECT SQL_NO_CACHE *
FROM <table-name>;
I get this warning:
Warning, 1681, 'SQL_NO_CACHE' is deprecated and will be removed in a
future release.
I would like to ask if there is any successor of the SQL_NO_CACHE that works or is planned to work with MySQL 8.x?
Does SQL_NO_CACHE actually work with MySQL 8.x or it is omitted by the server?
https://dev.mysql.com/worklog/task/?id=10837 says:
Since 8.0 still has (i.e. silently ignores) the SQL_NO_CACHE syntax and always returns false on the have_query_cache variable, maintain deprecation warnings for both like we do in 5.7 for a while.
more readings on this subject:
https://mysqlserverteam.com/mysql-8-0-retiring-support-for-the-query-cache/
"Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck."
and
"The query cache has been disabled-by-default since MySQL 5.6 (2013)"
Just noticed it, damn it was so useful -_-
Keep using it until it's removed or try SELECT column, now() FROM myTable instead.
I suppose the call will force mysql to not use the cache.
Related
My production uses MySQL 5.7 and I run h2 (MODE=MySQL) for tests. My connection string is like:
jdbc:h2:mem:ci_main;IGNORECASE=TRUE;MODE=MySQL;
I used Hibernate 5.6.3 with MySQL57InnoDBDialect.
It has been working fine with h2 version 1.4.196. But recently, I've tried to upgrade h2 to version 2.0.204 and SQL statements started to fail. The error was 42001 complaining about a column name value, which I believe is a keyword. It seemed at some point between the 2 versions, h2 became more restrictive on the SQL syntax than MySQL 5.7.
If I were writing SQL statements, I could have quoted the column name. But I'm using hibernate (which works fine with MySQL 5.7) and I do not want to change the column name just because of this.
Is there a way to let h2 be more "compatible" with MySQL 5.7?
Thanks.
You can add ;NON_KEYWORDS=VALUE to JDBC URL.
Usually you should also have ;DATABASE_TO_LOWER=TRUE in addition to ;MODE=MySQL for better compatibility.
Today I had to rebuild our BugZilla installation. It has been painful, mainly because I unintentionally incurred an upgrade from MySQL 5.7 to MySQL 8.0. Now BugZilla is reporting an SQL syntax error. In an attempt to debug this, I connected directly to the database using the MySQl client and ran the following query:
SELECT * FROM groups;
This results in the error:
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'groups' at line 1
The same query works for any other table, just not "groups". I am exhausted and have no energy left to solve this. I am guessing that MySQL 8.0 introduced "GROUPS" as a keyword. I would appreciate some help.
Upon investigation it turns out that MySQL 8.0 has indeed introduced "groups" as a keyword, and BugZilla needs to be modified to quote the table name in all places. Unfortunately the database code is shared among many different types of database which all use different characters to quote table names.
My final solution was to switch to using PostgreSQL.
After upgrading from Oracle 11/12 to 18/19 I get this error: ORA-01036: illegal variable name/number.
The error occurred in a query like this:
SELECT * FROM (SELECT * FROM TABLE) MY_TABLE WHERE ROWNUM <= :P_ROWNUM
(Subquery + binding parameters)
The identical query works properly with the Oracle 11.2.0.4 or 12.1.0.2 client. It fails with the Oracle Client 18c or 19c.
PS: The Oracle Server is version 18c 64x for Windows.
I use Delphi 10.1.2 with ADO components (dbGO). I also tried with Delphi 13.3.3 but the behavior is the same.
It seems to be a problem in the Oracle OLE DB provider (ORAOLEDB).
If I don't use ADO but DevArt Unidac all worked as expected.
Someone can help me?
Max
Your query is fine. We ran into a similar issue when migrating from 12.1 to 19. In our case, we have a custom OLE DB provider that interfaces with OraOLEDB (and others) using the Microsoft OLE DB Provider Templates (ATL). When attempting to upgrade from 12.1.x to 19c we started seeing the strange and confusing "ORA-01036: illegal variable name/number" error for parameterized SELECT queries. The queries would succeed the first time they were executed but subsequent executions would fail when all we did was change the parameter value (the queries were executed sequentially). I went on a wild goose chase trying to diagnose the issue and finally decided it had to be an Oracle caching bug of some kind. Yesterday, I experimented with the cache-related connection string attributes and found that adding the MetaDataCacheSize attribute and setting its value to 0 (zero) resolved the issue for us. None of the current Oracle patches appear to address this issue, at least none of those that mention the ORA-01036 error.
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.
All,
New to Oracle and am tasked with seeing why a query will not complete in 12c but runs totally fine in 11g. The query will complete in 3-4 minutes on 11g, but will sit and process until you cancel it on 12c.
I'd like to view the features that are enabled, primarily anything dealing with query optimization. How can I do this?
youn can take a look at:
v$ses_optimizer_env
v$sys_optimizer_env
That said: I would start to take a look at the execution plan: Maybe the difference is not a question of Features, but a result of different statistics in the given Systems.
Oracle has an option to emulate optimizer behavior from older versions on the new one. Try to add hint OPTIMIZER_FEATURES_ENABLE('your version of 11g') on 12c, or run this statement within the same session before execution of the query on 12c (assume the version of 11g where query is running fine is 11.2.0.4):
ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE='11.2.0.4';