Ora12154

501 views
474 views

Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
501
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ora12154

  1. 1. ORA-12154 Networking TipsWhat does ORA-12154 mean?ORA-12154 is perhaps one of the more infamous networking error messages you can get.The official description of it runs like this: Cause: Oracle Net could not locate the net service name specified in the tnsnames.ora configuration file. Action: Perform these steps: 1. Verify that a tnsnames.ora file exists. 2. Verify that there are not multiple copies of the tnsnames.ora file. 3. In the tnsnames.ora file, verify that the net service name specified in your connect string is mapped to a connect descriptor. 4. Verify that there are no duplicate copies of the sqlnet.ora file. 5. If you are using domain names, verify that your sqlnet.ora file contains a NAMES.DEFAULT_DOMAIN parameter. If this parameter does not exist, you must specify the domain name in your connect string. 6. If you are not using domain names, and this parameter exists, delete it or disable it by commenting it out. 7. If you are connecting from a login dialog box, verify that you are not placing an "@" symbol before your connect net service name. 8. Activate client tracing and repeat the operation. Cause: Oracle Net could not locate the database service name or net service name specified in the directory server. Action: Perform these steps: 1. Verify that the database service or net service name entry exists in the directory that this computer was configured to use. Verify that the sqlnet.ora file includes the following entry: NAMES.DIRECTORY_PATH=(ldap, other_naming_methods)Which is all nice and lovely –but doesn’t really explain what is going on, as far as I’mconcerned! So let’s take it a step at a time, and then maybe the official ‘action’ stepsmight make a bit more sense.Suppose that my tnsnames.ora file looks like this:DB9 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) ) )Copyright © Howard Rogers 2002 17/03/2002 Page 1 of 8
  2. 2. ORA-12154 Networking TipsThat tells me that by requesting a connection to “db9”, I’ll be directed to the Listenerrunning on the server called “MOZART” (that name needs to be resolved into an IP addressby something like lmhosts or Active Directory), listening on port 1521. When I get there,I’ll ask the Listener to connect to the Instance properly known as “db9.aldeburgh.local”Now, if there was a problem with any part of the ADDRESS aspect of this tnsnames entry, Iwouldn’t be getting ORA-12154 errors. I would instead get ORA-12514 errors (TNS: NoListener). The fact that this error number is a simple transposition of the one for thecould not resolve service name one is a perpetual source of confusion andfrustration, but you just have to live with it. Keep a keen eye on the actual errormessages received!So the problem isn’t there. It’s in the CONNECT_DATA part, or in the very first line. Theerror message tells us that we can’t work out what it is that you want to connect to.For example, and remembering what the tnsnames.ora looks like, look what happens whenI try and connect like this:SQL> connect system/manager@SALESERROR:ORA-12154: TNS:could not resolve service nameThe request was to connect to something aliased as “SALES” –yet my tnsnames.ora has noentry for such an Instance, only for something called “db9”. Oracle has searched thetnsnames.ora looking for an explanation of how to connect to “SALES” and simply can’tfind one.That’s a very simple reason for the 12154 error message. But things can get trickier. Whatabout this one:SQL> connect system/manager@db9ERROR:ORA-12154: TNS:could not resolve service nameHere, without altering my tnsnames.ora file in any way, I’ve correctly supplied the “db9”alias, and yet it’s still not working. Many first-timers rush to the conclusion that it’s a casesensitivity issue. My tnsnames.ora has an entry for “DB9” and I’ve tried to connect to“db9”… so perhaps that’s it? No. Case is not sensitive within the tnsnames.ora. In fact,there’s no obvious reason for my inability to connect this time… you just have to know thatthe existence of a sqlnet.ora file can throw things out.The job of sqlnet.ora is to inform Oracle what names resolution method we should be using(hostname, local names, names servers etc). It’s also a means of setting some defaultattributes for connections, such as whether they should be encrypted –or what domainname should be assumed for all connections. It’s that last one that happens to be stuffingthings up for us.Copyright © Howard Rogers 2002 17/03/2002 Page 2 of 8
  3. 3. ORA-12154 Networking TipsWhen I open my sqlnet.ora, I find this line:names.default_domain = worldWhat this means is that each and every connection string I type, unless it explicitlyincludes a domain name, will have a “.world” silently appended to it by Oracle. So when Itype connect system/manager@db9 what is actually being submitted is a connectsystem/manager@db9.world –which would be fine if that is what my tnsnames.oracontained… but as we know it doesn’t.There are two solutions to this problem. Either get rid of sqlnet.ora so that this silentaddition of domain names doesn’t happen. Or, alter tnsnames.ora so that the alias ‘db9’reads the full ‘db9.world’. Either method works fine:First, getting rid of sqlnet.ora:C:Documents and Settingshowardjr>type f:oracleora90networkadminsqlnet.oraThe system cannot find the file specified.C:Documents and Settingshowardjr>sqlplus system/manager@db9SQL*Plus: Release 9.0.1.0.1 - Production on Sun Mar 17 15:54:41 2002(c) Copyright 2001 Oracle Corporation. All rights reserved.Connected to:Oracle9i Enterprise Edition Release 9.0.1.1.1 - ProductionWith the Partitioning optionJServer Release 9.0.1.1.1 - ProductionNow, changing tnsnames.ora having put back the original sqlnet.ora:C:Documents and Settingshowardjr>type f:oracleora90networkadmintnsnames.oraDB9.world = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) ) )C:Documents and Settingshowardjr>sqlplus system/manager@db9SQL*Plus: Release 9.0.1.0.1 - Production on Sun Mar 17 15:50:52 2002(c) Copyright 2001 Oracle Corporation. All rights reserved.Connected to:Oracle9i Enterprise Edition Release 9.0.1.1.1 - ProductionWith the Partitioning optionJServer Release 9.0.1.1.1 – ProductionCopyright © Howard Rogers 2002 17/03/2002 Page 3 of 8
  4. 4. ORA-12154 Networking TipsOf course, it’s a bit daft to be continually making connections to a domain that doesn’tactually exist. So the real cure is not to get rid of sqlnet.ora, or to make meaninglessalterations to tnsnames.ora, but to make sure that the right domain name is supplied as adefault, and also to edit the tnsnames.ora so that if a User supplies just the short-formalias, the silent addition of the domain name still finds a match in the tnsnames.ora:C:Documents and Settingshowardjr>type f:oracleora90networkadmintnsnames.oraDB9.aldeburgh.local = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) ) )C:Documents and Settingshowardjr>type f:oracleora90networkadminsqlnet.oranames.default_domain = aldeburgh.localC:Documents and Settingshowardjr>sqlplus system/manager@db9SQL*Plus: Release 9.0.1.0.1 - Production on Sun Mar 17 15:59:12 2002(c) Copyright 2001 Oracle Corporation. All rights reserved.Connected to:Oracle9i Enterprise Edition Release 9.0.1.1.1 - ProductionWith the Partitioning optionJServer Release 9.0.1.1.1 - ProductionSo, I supply a connection request missing a domain entirely. Sqlnet.ora causes‘aldeburgh.local’ to be appended to that. An entry in tnsnames.ora exists for the short-form+domain name version. Hence the short-form can be resolved.Knowing this, can you now see why the official Oracle recommendations that I included atthe beginning of this paper ask you to perform the various checks that it does? Take themone by one: 1. Verify that a tnsnames.ora file exists. Obvious really. Without a tnsnames.ora at all, you’re not going to be connecting to anything, unless you’ve configured another naming method (see point 9 below). What you connect to has got to be resolved somehow. 2. Verify that there are not multiple copies of the tnsnames.ora file It’s no good making beautiful edits to your tnsnames.ora if there is a copy of the file in another directory somewhere –and Oracle happens to be using that copy and not the one you’ve been editing! (Don’t laugh –I once spent a good hour wondering why my extensive tnsnames.ora edits weren’t making the slightest bit of difference to connection behaviour!) By default, Oracle will use the copy in the ORACLE_HOMEnetworkadmin directory. But someone may have previously set theCopyright © Howard Rogers 2002 17/03/2002 Page 4 of 8
  5. 5. ORA-12154 Networking Tips environment variable TNS_ADMIN, which allows you to house your .ora files wherever that points to. Unfortunately, Oracle always searches the default location first, and ignores the TNS_ADMIN setting if it finds the right files there. So it’s quite easy to expend a lot of effort editing the TNS_ADMIN versions, not realising that they won’t actually be used. 3. In the tnsnames.ora file, verify that the net service name specified in your connect string is mapped to a connect descriptor Isn’t the English language a wonderful thing?! This gem of a sentence actually means “make sure that what you type after the “@” symbol in the ‘connect x/y@abc’ string matches what is listed as the alias in the tnsnames.ora file”. That’s the problem we first encountered, back on page 2. I was connecting to “SALES”, the tnsnames.ora only had an entry for “db9”. There wasn’t a match, so the SALES name couldn’t be resolved into anything meaningful. 4. Verify that there are no duplicate copies of the sqlnet.ora file. On the same principle that it is pointless editing a tnsnames file in TNS_ADMIN if the operational file can be found in ORACLE_HOMEnetworkadmin, it also makes no sense trying to edit the sqlnet.ora file in the TNS_ADMIN directory if the real one is still stored in the default location. We’ve seen that shortname+the default domain as supplied by sqlnet.ora must match the alias listed in tnsnames.ora… so editing sqlnet.ora may be needed to get a successful connection. But editing the non- working copy of the file won’t get you very far. 5. If you are using domain names, verify that your sqlnet.ora file contains a NAMES.DEFAULT_DOMAIN parameter. If this parameter does not exist, you must specify the domain name in your connect string. This is the exact problem I was describing on page 3. Sqlnet.ora’s spooky tendency to want to append domain names to supplied connect aliases means that we have to have an appropriate default set there to start with, and a matching alias+domain in the tnsnames.ora. This was the second option described on page 3. 6. If you are not using domain names, and this parameter exists, delete it or disable it by commenting it out. The converse is also true, as I demonstrated as the first possible solution on page 3. When there’s no sqlnet.ora, no domain name is appended to the connect alias supplied by the User, so the tnsnames.ora can also just have the short form alias (in my case, just “db9”). 7. If you are connecting from a login dialog box, verify that you are not placing an "@" symbol before your connect net service name. This is a slightly bizarre possibility. They’re talking about using, for example, the GUI version of SQL*Plus, which prompts you for a logon like this:Copyright © Howard Rogers 2002 17/03/2002 Page 5 of 8
  6. 6. ORA-12154 Networking Tips Users who have gotten into the habit of typing ‘connect system/manager@db9’ in the command line version of SQL*Plus sometimes make the mistake of thinking that the “@” symbol is a requirement even in the GUI, as I’ve shown in this example. It’s not: entered like this, I’ll actually be looking for an alias in my tnsnames file of “@db9” –for the GUI, anything entered in the ‘host string’ window is taken absolutely literally. 8. Activate client tracing and repeat the operation A counsel of despair, and not really a piece of meaningful advice for this particular error message. There are tracing utilities (such as TRCROUTE and TNSPING) which can help you see what happens when a connection is established, but if the problem is that the tnsnames.ora file can’t find a match to what you’ve requested a connection to, those utilities aren’t actually going to be of much use. 9. Verify that the database service or net service name entry exists in the directory that this computer was configured to use. Verify that the sqlnet.ora file includes the following entry: NAMES.DIRECTORY_PATH=(ldap, other_naming_methods) This piece of advice is actually quite sensible. Concentrate on the second sentence: the NAMES.DIRECTORY_PATH parameter in sqlnet.ora governs which names resolution method Oracle will use to work out what a User is trying to connect to. You need to make sure that the right naming method is selected, and that any and all files needed to make that method work actually exist. For example, I can generate an ORA-12154 by editing my sqlnet.ora so that it claims we are using the Host Naming names resolution method: C: >type f:oracleora90networkadminsqlnet.ora NAMES.DIRECTORY_PATH=(hostname) names.default_domain = aldeburgh.local C: >sqlplus system/manager@db9 SQL*Plus: Release 9.0.1.0.1 - Production on Sun Mar 17 16:43:53 2002 (c) Copyright 2001 Oracle Corporation. All rights reserved. ERROR: ORA-12154: TNS:could not resolve service nameCopyright © Howard Rogers 2002 17/03/2002 Page 6 of 8
  7. 7. ORA-12154 Networking Tips This error arises because actually, I’ve set things up to use the Local Naming method (in other words, use a local copy of tnsnames.ora to resolve service names). But here I am telling Oracle that it should use host naming… as you might expect, it’s just not going to work. Similarly, if I tell Oracle that I have a Names Server for name resolution, I really do need to actually have one configured and running! If you’re configured for one method, make sure that sqlnet.ora is aware of it, and make sure that the infrastructure that naming method requires actually exists, and works. In my case, editing the sqlnet.ora fixes the problem: C:>type f:oracleora90networkadminsqlnet.ora NAMES.DIRECTORY_PATH= (TNSNAMES) NAMES.DEFAULT_DOMAIN = aldeburgh.local C:Documents and Settingshowardjr>sqlplus system/manager@db9 SQL*Plus: Release 9.0.1.0.1 - Production on Sun Mar 17 16:55:16 2002 (c) Copyright 2001 Oracle Corporation. All rights reserved. Connected to: Oracle9i Enterprise Edition Release 9.0.1.1.1 - Production With the Partitioning option JServer Release 9.0.1.1.1 - Production The line in bold there shows that I’ve now told Oracle to use a tnsnames.ora, and we already know that I have that in place, with all the right entries. Hence the successful connection.I’ll just finally mention one other cause of ORA-12154: bad formatting in the tnsnames.ora.In particular, it can be very sensitive to the indentation and layout being played aroundwith. Take this as an example:C:>type f:oracleora90networkadmintnsnames.oraDB9.aldeburgh.local =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)))(CONNECT_DATA =(SERVICE_NAME = db9.aldeburgh.local)))C:>sqlplus system/manager@db9SQL*Plus: Release 9.0.1.0.1 - Production on Sun Mar 17 17:19:38 2002(c) Copyright 2001 Oracle Corporation. All rights reserved.ERROR:ORA-12154: TNS:could not resolve service nameSomeone’s been just a little too eager to get rid of all the indentations that were in theoriginal file (though, if you compare its actual contents to the one on page 1, you’ll seeCopyright © Howard Rogers 2002 17/03/2002 Page 7 of 8
  8. 8. ORA-12154 Networking Tipsthat there’s otherwise practically no difference). When the indentations go, somehowOracle loses its ability to distinguish the separate components, and thus to parse the fileinto meaningful bits and pieces. Everything else can be right (and in this particular test,everything else was correct), but this simple formatting error can cause the infamous error.So that’s ORA-12154. It’s not too tricky to resolve: just make sure your tnsnames.ora islaid out correctly; that what the User types after the “@” symbol matches up with whatyou’ve got listed as possible aliases in the tnsnames file; that you’ve taken into accountsqlnet.ora’s habit of silently appending bits and pieces to what is typed after the “@”symbol; that if you’re using a names resolution method, the infrastructure that methodrelies on is actually in place. Do all that, and the errors should go away.Copyright © Howard Rogers 2002 17/03/2002 Page 8 of 8

×