We have a series of Amazon Web Services servers running Amazon Linux and Oracle XE, which is used by a local app. OracleXE installs and runs just fine, our app can connect to the DB, everything is great.
For one of our particular servers, we needed to shut it down and archive it. Today, I need to bring it online. This is done by setting up a new AWS instance, creating a new virtual hard drive from backup snapshot, setting up a new public IP for the server and changing DNS settings to that the old domain points to the new IP, connecting up the restored virtual drive as the main drive, and starting it up.
OracleXE doesn't want to work. Using sqlplus to connector to localhost:1521/XE produces "ORA-12514: TNS:listener does not currently know of service requested in connect descriptor".
This system was working just fine when I snapshotted it and archived it the first time, and I hadn't changed any settings since restoring it. Everything should be exactly the same, so why is OracleXE now not working?
The listener.ora and tnsnames.ora had the host defined using the server's public domain name. I tried changing that to localhost, but it's still not working.
The only things I can think of that will be different are the server's public IP address, and the "rsa2 key fingerprint" (what Putty complains about due to the SSH key being the same but it being a new AWS instance). All the advice I've seen so far is for fixing config errors for ORA-12514 when setting up a new system or after restarting, but this is a system that was working fine but has been restored from snapshot.
Most likely, your listener uses dynamic instance registration.
For that to work, your listener must be listening to the default port (1521) or your instance must use the local listener parameter that defines the address of the listener where the instance should register it's existence.
So, check your local_listener parameter, check the servers tnsnames.ora and listener.ora. Also check your clients tnsnames.ora, it should point to your new server and listener.
Related
Has anyone encountered the NLA error after changing instance type for an EC2 instance?
Getting this error after upgrading a domain joined instance (t3.2xlarge) to the recommended instance type according to Computer Optimizer (m6i.2xlarge).
Cannot RDP using the local administrator account either, same NLA error.
Also made a re:post question but no answer yet.
Kind regards,
Ken
Things I have tried:
Changing back to t3.2xlarge, connected using domain credentials OK
Changing to m5.2xlarge, connected using domain crendentials OK
Added another NIC when it was on m6i.2xlarge, NLA error on the second interface.
(Don't think this matters, the instance is HVM) Upgraded to the latest PV driver, changing instance type to m6i.2xlarge, NLA error.
Launched a m6i.2xlarge instance in a different subnet(AZ), joined domain OK, connected using domain crendentials OK; changed to t3.2xlarge, NLA error; changed back to m6i.2xlarge, connected using domain crendentials OK
Launched another m6i.2xlarge instance in the same subnet as the t3.2xlarge, swapped the root volume, NLA error. Swapped back the volumes, connected OK.
All these tests leads me to think there is incompatibility b/w gen 5 Xeon processors and gen 6, which is strange, I thought at first it was a network card issue.
Copy pasted from my own answer on RE:POST
Managed to isolate the cause after performing some rescuing via SSM.
The issue seems to stem from the upgrade from the CPU generation leap.
I had always thought each component, Storage, Compute, and Networking are separate, but the ENI config was lost during the upgrade, so the server had trouble (i.e. did not know where the DNS server is) contacting the DCs for authentication.
Without this link to the DCs, NLA will never be met.
So if you are going to upgrade to the latest generation.
While on the current instance type (while you can RDP to the EC2 instance), navigate to System Properties and go to the Remote tab.
Untick the NLA option and apply and save the change.
Shutdown the instance and change to the desired instance type.
RDP to the instance using the Administrator account.
Here you will see that the network interface configuration is empty, so add your DNS server IP address back in here.
Confirm you have a connection to the DCs by pinging or something of the sort, then repeat step 1, but this time enable the NLA option and save.
Reboot and Voilà, you should now have access to the EC2 instance using your domain logins again.
Why I am curious:
I have always had issues when installing an Oracle Express Database. As in I have never had it work right the first time round. The next time I boot my computer after installing Oracle Express I consistently receive the common error:
TNS-12505: TNS:listener does not currently know of SID given in connect descriptor
I have managed to fix this issue using various methods however I have learned that the best method that works for me these days is to Reconfigure the Listener using SQL Plus. When the Listener fails SQL Plus is the only way I can connect to the OracleXE Server and after searching the Internet I'm not alone here.
The DDL that fixes this error - run from SQL Plus:
alter system set local_listener='(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1521))' scope=both;
The Question:
Why does re-configuring the Listener work? What does it do? I monitored my listener.ora file along with my TNSNames.ora file and they remain the same before and after I run the above code. So what did it do?
I read this entire Oracle LISTENER Documentation and I did not come out of it enlightened. Can anyone enlighten me?
Why does re-configuring the Listener work?
You are not reconfiguring the listener. That's why you don't see the listener configuration file change. You are changing the database configuration. The spfile is updated because the command you used had scope=both, which means the change is applied immediately - in memory - and written to that file, so it persists on database restart.
From the docs:
LOCAL_LISTENER specifies a network name that resolves to an address or address list of Oracle Net local listeners (that is, listeners that run on the same system as this instance).
and the default is:
(ADDRESS = (PROTOCOL=TCP)(HOST=hostname)(PORT=1521)) where hostname is the network name of the local host.
See also the alter system REGISTER clause:
Specify REGISTER to instruct the PMON background process to register the instance with the listeners immediately. If you do not specify this clause, then registration of the instance does not occur until the next time PMON executes the discovery routine. As a result, clients may not be able to access the services for as long as 60 seconds after the listener is started.
So what this means is that when the database starts, and then periodically, it tries to register its service name(s) with the listener; and it gets the info about the listener from the local_listener parameter. (There's also a remote_listener for data guard, not relevant here.)
Because the default is hostname the PC name is used directly in that parameter, and that will often resolve to the PCs LAN IP address (which can change each reboot to add to the confusion, if the IP is assigned by DHCP), which could be stored instead. If you're lucky the hostname will resolve to the same as localhost, but that isn't the case for you.
So... the database looks up its init parameter, and as a result tries to register with a listener at say 192.168.1.2. But the listener has started on localhost so it is listening on 127.0.0.1. The DB fails to register its service name, as it can't reach a listener; though that is only apparent if you look in the alert log. If you run lsnrctl services it won't show anything.
When you change the init parameter you are telling the DB to try to register against a listener on localhost instead - and as that is where it is actually listening, registration now works, and the listener recognises the service name on subsequent connection attempts. (Your question refers to the error message about SID, which is different, and not solved by your change.) Running lsnrctl services will now show the service name too. But that is a runtime, dynamic thing via the registration - not a change to the permanent configuration of the listener.
It's possible to have the listener listen on more than one address. The main thing is that the listener.ora, tnsnames.ora (if you use TNS aliases) and init parameter use consistent host names or IP addresses, so they are all resolving to and referring to the same thing, whether that is localhost (only reachable from that PC), or a LAN address (reachable across the nwtwork) or both.
You can also have an entry in the tnsnames.ora for the listener itself, rather than just for DBs. You can then use that TNS alias as the local_listener target, instead of spelling put the address and port, possibly making it easier to change later if needed.
I am trying to execute one simple desktop application in my system that is built upon java swing.
This application fetches the data from the oracle database which is present in computer A.
I did the development in computer A and built its jar and kept the jar in another system.
I have started all the services of oracle and created an ad hoc network between the two systems, but I am not able to execute the application from another computer. I googled a lot and did the mentioned changes. Still I am getting the same error of TNS listener.
IOException: The network adapter could not establish the connection.
finally I thought to put my code here. please look at the below code:
Class.forName("oracle.jdbc.driver.OracleDriver");
Connection connection =
DriverManager.getConnection("jdbc:oracle:thin:#//xxx.xxx.xxx.xxx:1521/XE"
,"system"
,"system" );
Please help me on this.
I have also tried modifying the tnsnames.ora file but was not helpful. can anybody please help me on this.
Check the listener.ora file - what is the IP address the service is binding to, i.e. what is the IP address specified in this file? If 127.0.0.1, that will explain why it works on Computer A but not B.
If this is the case you should fist stop teh listener service, backup the listener.ora, edit listener.ora, changing the IP address to the appropriate one for Computer A (accessible from Computer B), restart the listener, and retry.
Use tnsping to test the connection works, if you don't have TNS ping you can try "Telnet hostname port" (e.g. telnet computer-A 1521) and if it returns blank screen and flashing cursor on top left then the service is up.
I've got a RMI server running on a mac. Once I changed the server IP and restart the Application and clients, then clients keep connect to the old ip address with right bind and lookup address. I really have no idea what went wrong because the program is working on another linux server just with different port.
What the remote object clients got is Proxy[MinervaInterface,RemoteObjectInvocationHandler[UnicastRef [liveRef: [endpoint:[192.168.0.104:51815](remote),objID:[40d99efb:140ba232cec:-7fff, 6333954213550330995]]]]]
which 192.168.0.104 is the old IP and it should be 10.0.1.104
I've check the host file and my code, there is no anything like 192.168.0.*
Please help, Thank you.
UPDATE
I have confirmed this is a server registry problem. But I have already restarted the server. I did't remember what else did I do to the registry. Is there any way to set it manually?
UPDATE
I rune this code on that server InetAddress.getLocalHost().getHostAddress(), it returned 192.168.0.104, that can explain where this address came from. But there is no such address on the server now
SOLVED
I found java use a hostname to lookup localhost address, that hostname is not localhost and have not been updated by OS X Server for some reason. I updated the record from OS X Server console and solved this annoying problem.
NEVER THOUGHT ABOUT THAT
I created an EC2 linux box with: Oracle Database 11.2.0.1 64-bit Standard Edition One (ami-31739c58). Instance is running fine. I can connect to box from my personal computer using ssh (terminal in Mac OS Lion) by typing:
ssh -i predikto1.pem root#ec2-54-235-243-231.compute-1.amazonaws.com
I created a new EC2 security group opening port 1521 via TNS. I updated my tnsnames.ora file to include the correct public DNS. I was able to connect to the Oracle DB using SQL Developer from my laptop (Macbook Air).
I stopped the EC2 instance, waited a few days, and started back up the instance. The Public DNS name changed. So I went to tnsnames.ora file on my computer and updated the host field to reflect my latest (new) public DNS:
oradb=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=ec2-54-235-243-231.compute-1.amazonaws.com)(PORT=1521))
(CONNECT_DATA=
(SID = oradb)
)
)
I tried to connect from my laptop using SQL developer to the Oracle DB on EC2 and get an
error: TNS Listener does not currently know of SID given in connection descriptor.
I tried creating an elastic IP via EC2 instance screen and I assigned it to the instance. No luck substituting the host ec2-54-235-243-231.compute-1.amazonaws.com for the IP address either (IP is 54.235.243.231) in the TNSNAMES.ORA file. I have re-started and nothing.
Do you have the status "authorized" in "DB Security Group" for their "EC2 Security Group" ?
Try to use AWS RDS instead of AMI. It is super easy to setup. I spent days tweaking AWS AMI for Oracle (started with version 11, that had issues, then switched to 12, tweaked again...). With AWS RDS you can set whichever version you want (11, 12, roll back to 11 etc.). It takes all these setups easier than just configuring on your own.
With RDS - you can set oracle username, password, easily see when is running, stop it, IP address, manage access etc. (all from the UI console without ever SSH-ing to any server)..