I am facing problem with Oracle 11g Express hosted on Linux Centos 6.4. This server is relocated from one place to another, this relocation changes the IP of server.
We have changed the IP in tnsname.ora and listerner.ora files. After these changes when we are trying to connect to database instance from server we are getting error “Connected to idle instance”. If we are trying it to connect from client using SQL developer we are getting error “Status : Failure -Test failed: Listener refused the connection with the following error: ORA-12505, TNS: listener does not currently know of SID given in connect descriptor”.
We have restarted this server and database multiple time (through option Start and Stop database under Oracle menu) multiple time, but still we are getting the same error.
Request you to please help to resolve this issue.
The local connection via sqlplus user/passwd (as opposed to sqlplus user/passwd#TNSALIAS) is not impacted by IP address or by contents of tnsnames.ora. It also does not require a listener at all, the listener could be stopped or not defined at all in listener.ora. In other words, you did something wrong here.
My guess is that you are mislead into thinking that you've started the database, when in fact it is not started. Check if you have a process called ora_MYORACLE_pmon.
Also the file tnsname.ora is irrelevant; Oracle only checks tnsnames.ora.
we resolved this issue, actually we were missing server address in some files it was still referring old address.
initXE.ora missing local listener parameter, then we added this parameter to it and it start working.
May be this is not the generalise solution but it work in our case.
This behavior is expected if the listener was originally configured with an ALTER SYSTEM command like ALTER SYSTEM SET LOCAL_LISTENER=''; and that command specified the SCOPE=MEMORY option or if the SCOPE is left to default and the database was started with a pfile.
To fix it, reissue all ALTER SYSTEM commands from before the restart. Or at least one that identifies the LOCAL_LISTENER. And set SCOPE=BOTH.
Related
I did a fresh install of Maxscale, and I was trying to set up a Read-Write-Split service on a master-slave mariadb cluster.
When I was trying to connect with DataGrip or DBeaver, I got the following error message:
[HY000][1927] Capability mismatch (bdd-master)
But when I use the mysql command line client, it works well.
Do you have any idea of what could be wrong?
MaxScale sends a Capability mismatch error when it detects that the client application requests a protocol capability that one of the backend databases cannot support. In general, this should not happen as MaxScale tries to mimic the backend database and calculates the capabilities so that these sort of mismatches do not happen.
There are some known bugs that can cause this, both in MaxScale as well as old versions of MariaDB and MySQL. Upgrading to the latest possible version of MaxScale should help solve any problems you might see.
Additionally, you should disable the query cache in the database if you are using MySQL as there is a bug in MySQL (and old MariaDB versions as well) that causes these sort of problems to appear.
It seems that is related to the router used (readwritesplit).
Datagrip send this command when it initiate the connection:
set autocommit=1, session_track_schema=1, sql_mode = concat(##sql_mode,',STRICT_TRANS_TABLES')
It seems that some of theses parameters are not supported by readwritesplit.
I'm trying to stop Grakn server but it doesn't stop. When I query status, it says both server and storage are running.
I thought it's related with this issue. However this issue is solved long before.
I did some operations like insert, match, delete with Python client. Is it possible one of them didn't close well?
I can't run any query on Python client or console now, it gives this error:
Unable to create connection to Grakn instance at localhost:48555
Cause: io.grpc.StatusRuntimeException
UNAVAILABLE: io exception
It's possible that the server has actually stopped but the terminal process doesn't know about it.
Grakn Core 1.8 runs as a Java process. You can check if there is a server instance by running:
jps
If there is a Grakn instance, it will be named GraknServer, and you can force quit it if necessary using kill.
After that you can restart Grakn using ./grakn server start as normal.
I'm helping to write a program that manages VMs remotely. When I try to connect to a XenServer machine to discover the hypervisor, I get a "Unable to connect: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory" error. I've tried creating the cacert.pem file that it's looking for, but that doesn't fix anything. I've read that this certain error isn't accurately showing what's wrong.
This only happens when I use the Java bindings - I can successfully connect to the machine with virsh. I turned on debug mode for libvirt and tried to connect with both the bindings and virsh. The only major difference that I saw is virsh calling several virEvent type methods that libvirt doesn't do. (As I think about it, this may just be libvirt using my custom ConnectAuth class that doesn't prompt for a password)
Using:
libvirt 0.9.12 --with-xenapi
libvirt-java 0.4.7
I can't seem to find anybody else who has had this problem. Any help would be appreciated!
We ended up having to modify the Connect object in libvirt-java. The object was still valid, but somehow an error was being thrown. It's a messy hack, but we just ignore the certain error that is thrown and pass up the Connect object and are able to connect.
I am tranfering a file from one server to another using "Core FTP mini-sftp-server" on source side and WinSCP on destination side (both servers are running Windows).
I am logging in these two machine using local admin account which are same on both servers.
I have been doing this process manually:
Start MSFTP server on source
Start WinSCP on destination, connect to source and get the file.
Now I want to automate it and i tried the following
Start msftp from command line on source.
On destination in winscp.exe console:
open login:password#IPAdress
get <file> <destination>
close
exit
The problem with this is if I do it for the first time everyday, it asks me to update the key at the destination side saying:
"WARNING POTENTIAL SECURITY BREACH! The server’s host key does not
match the one WinSCP has is cache. This means that either the server
administrator has charged the host key, the server presents different
key under certain circumstances, or you have actually connected to
another computer pretending to be the server"
I have to manually do it (click on Update) at first and then for the following copies, the automation works.
Question:
How can I update the key using cmd line while connecting to the server?
Can I prevent the source to generate new key daily? Or should I do it?
You should prevent the source server generating a new key - there is absolutely no reason to do so. The server's public key identifies the server, and so this identity shouldn't be changed.
You are losing any security by connecting to a SSH server that changes public key every day.
Anyway, if that's your only option, recent WinSCP allows accepting any host key automatically using the -hostkey=* switch of the open command:
open -hostkey=*
You lose any security by doing that, but you are already, so it makes no difference.
I've got a number of ASP.Net websites (.Net v3.5) running on a server with a SQL 2000 database backend. For several months, I've been receiving seemingly random InvalidOperationExceptions with the message "Internal connection fatal error". Sometimes there's a few days in between, while other times there are multiple errors per day.
The exception is not limited to one site in particular, though they share business and data access assemblies. The error seems to always be thrown from SqlClient.TdsParser.Run(). It sometimes is thrown from old-school direct SqlCommand.Execute() calls, while other times it is thrown from Linq2Sql code.
I've been assured by the network guys that there are no errors or packets lost on their end. Has anyone else experienced this? Could it be a driver problem? We have been unable as of yet to pinpoint a specific trigger for this exception.
We're running II6 on Windows Server 2003.
After a few months of ignoring this issue, it started to reach a critical mass as traffic gradually increased. Under heavy load, including some crawlers, things got crazy and these errors poured in nonstop.
Through trial and error, we eventually tracked down a handful of SqlCommand or LINQ queries whose SqlConnection wasn't closed immediately after use. Instead, through some sloppy programming originating from a misunderstanding of LINQ connections, the DataContext objects were disposed (and connections closed) only at the end of a request rather than immediately.
Once we refactored these methods to immediately close the connection with a C# "using" block (freeing up that pool for the next request), we received no more errors. While we still don't know the underlying reason that a connection pool would get so mixed up, we were able to cease all errors of this type. This problem was resolved in conjunction with another similar error I posted, found here: Why is my SqlCommand returning a string when it should be an int?
Sounds like the database connection is getting dropped or timing out.
We recently had similar issues moving to IIS 6 from IIS 5 connecting to SQL 2000. Our issue was solved by increasing number of ephemeral ports available.
Look at the usage of the ephemeral ports by the IIS server. The default max no. of ports available is normally 4000. You might want to consider increasing this if the sites on your server are particularly busy or your application is making a lot of database calls.
You can monitor these first to see if going over max limit.
Search Microsoft Knowledge base for "MaxUserPort" and "TcpTimedWaitDelay" and make necessary registry changes. Make sure you back up registry or snapshot server before making the changes. Will need to reboot for changes to take effect.
You should double check your database and recordset connection are being closed after use. Not closing will use up this port range unnecessarily.
Check the efficiency of your stored procedures anyway as they might be taking longer than they need too.
"If you rapidly open and close 4000 sockets in less than four minutes, you will reach the default maximum setting for client anonymous ports, and new socket connection attempts fail until the existing set of TIME_WAIT sockets times out." - from http://support.microsoft.com/kb/328476
Check your server's LOG folder (\program files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG or similar) for files named SqlDump*.mdmp and SqlDump*.txt. If you do find any you'll have to take it to Product Support.
I was creating a new EF Core project and was trying to create the database to an external Linux server instead of a Windows Server or local one. After hours of searching I found out that I am using MySQL instead of the Microsoft SQL server.
I found it weird that everyone was using 1433 instead of the usual 3306. So to fix my 'Internal connection fatal error' I had to set up a docker instance of SQL Server bound to its default port of 1433.
It literally was that simple. In the docker repo look for "microsoft-mssql-server" and run the image as described neatly in the description below. Everything works now and I am able to push my database from my EF Core project to an external server.