I am new in connecting azure MySQL database from Spring boot application.
Below is the snippet mentioned in application.properties
spring.datasource.url=jdbc:mysql://XXXX.mysql.database.azure.com:3306/MyDbName
spring.datasource.username= ******
spring.datasource.password= ******
I have faced the following exception
org.springframework.jdbc.support.MetaDataAccessException: Could not get Connection for extracting meta data; nested exception is org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: Unknown system variable 'query_cache_size'
I have googled and somewhere it was mentioned that it is required to update the version of MySQLConnector to 8.0.13
Please help me find the solution.
Based on your exception , its not because of Azure mysql. Its because of system variable 'query_cache_size'. refer : java.sql.SQLException: Unknown system variable 'query_cache_size'
I too have met this bundle of joy on azure MySQL. As dvo mentions it places this variable in when it thinks it is under version 8.0.3.
From com.mysql.cj.NativeSession.java...
if (!versionMeetsMinimum(8, 0, 3)) {
queryBuf.append(", ##query_cache_size AS query_cache_size");
queryBuf.append(", ##query_cache_type AS query_cache_type");
}
But as my Azure MySQL version is 8.0.15 which matches my driver version then I suspect whilst the database may well be version 8 part of the stack the driver deals with is not.
Edit:
From https://learn.microsoft.com/en-us/azure/mysql/concepts-limits
Current known issues
MySQL server instance displays the wrong server version after connection is established. To get the correct server instance engine version, use the select version(); command.
So I'm guessing that this is the problem and as it stands Azure MySQL 8 will not work with the java mysql connector.
I'll probably look at building the connector myself and hard coding in the version number to 8.0.15. What joy.
Edit Edit:
Modified ServerVersion.java parseVersion(…) to return
return new ServerVersion(8, 0, 15);
Which works around the problem enough for me to carry on with my work.
It's a problem Microsoft should be fixing ASAP on their side.
Related
I'm trying to connect to my on-premise Oracle database in order to migrate and copy some tables over to Azure SQL, but am not able to do so despite making sure all the connection parameters match the provided values in tnsnames.
Am I missing something? The error says the socket is closed but haven't gotten any useful information other than this prior issue, but doesn't contain any solution. I currently use Oracle 11.2.0.3 so the ADF connector should support this version.
Not sure what else I need to check. Any thoughts would be greatly appreciated!
Your screenprint shows you are using the AutoResolveIntegrationRuntime but as you say your Oracle db is on-premises you would need a Self-hosted Integration runtime (SHIR) as per this article. You would still need an SHIR for an IaaS Oracle db. Ideally the SHIR should be 'close' to the datasource so probably on-premises in the same network.
Do you have any proxy or firewall configured?
Have you tried creating the linked service and then testing the connection? Sometimes it occurred to me that I failed to test the connection of a new linked service but when creating it and retesting the connection is successful ...
I've been having a lot of problems connecting SQL Workbench/J to Amazon Athena through the JDBC connector. Also, the instructions seem to vary between these two help resources:
http://docs.aws.amazon.com/athena/latest/ug/athena-sql-workbench.html
https://s3.amazonaws.com/athena-downloads/drivers/JDBC/docs/Simba+Athena+JDBC+Driver+Install+and+Configuration+Guide.pdf
Here's the error message:
[Simba]JDBC Connection Refused: [Simba]JDBC Required Connection Key(s): AwsRegion; [Simba]JDBC Optional Connection Key(s): AwsCredentialsProviderArguments, AwsCredentialsProviderClass, BinaryColumnLength, ComplexTypeColumnLength, ConnectTimeout, MaxCatalogNameLength, MaxColumnNameLength, MaxErrorRetry, MaxSchemaNameLength, MaxTableNameLength, ProxyHost, ProxyPort, ProxyPWD, ProxyUID, S3OutputEncOption, Schema, SocketTimeout, StringColumnLength, UseAwsLogger
The documentation at #1 is deprecated, as you might gather from the different filenames in the two guides. Amazon hasn't fully cleaned up their docs, since switching from their homegrown JDBC driver to the driver they've OEMed from Simba.
You did not provide the JDBC URL you're using, so I cannot provide a specific correction, but the error message you got seems pretty clear -- you apparently didn't build your JDBC URL correctly. It's missing the mandatory AwsRegion setting.
Note the URL syntax from the PDF guide for the JDBC driver you're using --
jdbc:awsathena://AwsRegion=[Region];UID=[AccessKey];PWD=[SecretKey];S3OutputLocation=[Output];[Property1]=[Value1];[Property2]=[Value2];...
Here is how I have done it
Make sure you have Java8 installed
Download the latest Athena jar
Make a new driver in sql work bench
Add the jdbc connection and username/password
location would be location you logged into the account and what setting is in the url Thus my url is: jdbc:awsathena://athena.us-east-2.amazonaws.com:443
Username= Access Key Id; Password= Secret Access Key
Then do not forget the extended properties! set the s3_staging_dir to the bucket you created for your Athena results, or you will need to look and see what the default bucket is created. This bucket must start with aws-athena-query-results
Update version 2.07
Bucket is now S3OutputLocation not s3_staging_dir:
I am trying to connect my grails project to Oracle databse(Oracle 12c) in windows(8) system. However, whenever I run my application I get following exception :
Caused by: org.apache.commons.dbcp.SQLNestedException:
Cannot create PoolableConnectionFactory (ORA-28040:
No matching authentication protocol)
Caused by:
java.sql.SQLException: ORA-28040:
No matching authentication protocol
According to internet suggestion I also tried editing my *.ora file but it is not working.
I added following snippet in sqlnet.ora file :
SQLNET.ALLOWED_LOGON_VERSION=10
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=10
SQLNET.ALLOWED_LOGON_VERSION_SERVER=10
Here i tried assigning (10,11,12) but neither of them is working.
Can anyone please help me with this ?
I deleted the ojdbc14.jar file and used ojdbc6.jar instead and it worked for me
Here is some text I found at experts-exchange:
Bug 14575666
In 12.1, the default value for the SQLNET.ALLOWED_LOGON_VERSION
parameter has been updated to 11. This means that database clients
using pre-11g JDBC thin drivers cannot authenticate to 12.1 database
servers unless theSQLNET.ALLOWED_LOGON_VERSION parameter is set to the
old default of 8.
This will cause a 10.2.0.5 Oracle RAC database creation using DBCA to
fail with the ORA-28040: No matching authentication protocol error in
12.1 Oracle ASM and Oracle Grid Infrastructure environments.
Workaround: Set SQLNET.ALLOWED_LOGON_VERSION=8 in the
oracle/network/admin/sqlnet.ora file.
This except for adding the following to sqlnet.ora
SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 8
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
If you get "ORA-01017: invalid username/password; logon denied" error, then you need to re-create your password.
I resolved this issue by using ojdbc8.jar.
Oracle 12c is compatible with ojdbc8.jar
I was using eclipse and after trying all the other answers it didn't work for me.
In the end, what worked for me was moving the ojdb7.jar to top in the Build Path. This occurs when multiple jars have conflicting same classes.
Select project in Project Explorer
Right click on Project -> Build Path -> Configure Build Path
Go to Order and Export tab and select ojdbc.jar
Click button TOP to move it to top
Very old question but providing some additional information which may help someone else. I also encountered same error and I was using ojdbc14.jar with 12.1.0.2 Oracle Database. On Oracle official web page this information is listed that which version supports which database drivers. Here is the link and it appears that with Oracle 12c and Java 7 or 8 the correct version is ojdbc7.jar.
In the ojdbc6.jar is for 11.2.0.4.
Except for adding the following to sqlnet.ora
SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 8
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
I also added the following to both the Client and Server, which resolved my issue
SQLNET.AUTHENTICATION_SERVICES = (NONE)
Also see post
ORA-28040: No matching authentication protocol
Adding
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
is the perfect solution
sql.ora directory
..\product\12.1.0\dbhome_1\NETWORK\ADMIN
My Initial error is : ORA-28040: No matching authentication protocol exception
My DB version is 12.2 (Solaris) and client version is 11.2 ( windows). I have added below in both server and client sqlnet.ora
SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 8
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
while connecting, I have got invalid username and password hence I have recreated the password ( same password ) in database which is resolved my issue.
While for most cases replacing ojdbc driver jar will be the solution, my case was different.
If you are certain you are using correct ojdbc driver. Double check if you are actually connecting to the database you are thinking you are. In my case jdbc configuration (in Tomcat/conf) was pointing to different database that had different Oracle version.
just install ojdbc-full, That contains the 12.1.0.1 release.
Context
I have been debugging an Oracle Weblogic Server 10.3.0.0 JDBC Connection which is logging the error code:
BEA-001112
After some searching around I found a bit of an explanation here:
http://docs.oracle.com/cd/E21764_01/core.1111/e10106/dbac.htm#BHCFFAJF
Although it does depend on the actual exception being thrown, I believe this means:
there was an error when testing a new connection in the JDBC Connection Pool before handing it off to be used by the application.
Question
Does anyone know of a list of Weblogic Error Codes that has a general description for the specific Error Code?
In Oracle portfolio WebLogic is a part of Oracle Fusion Middleware (OFMW). Thus the error code (or message) list is a part of OFMW documentation.
As the links a quite difficult to find for uninitiated here's direct links to a few different releases.
WebLogic 10.3.3
WebLogic 10.3.6
WebLogic 12.1.3
They are not much descriptive, but hopefully can give you at least an introduction. You can also index them by subsystem. Clicking on a message (or message range) will bring up the details.
Cause: The specified data source connection pool has been configured with one or
more attributes to test the pool connections. One of those test attempts failed. The
associated error is printed.
Action: Check the associated error to see what the problem is and correct it.
Normally, this indicates that a connection was lost to the database (the database is
down). This needs to be corrected by the database administrator.
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.