• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Whatistnsnames
 

Whatistnsnames

on

  • 514 views

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 ...

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

Statistics

Views

Total Views
514
Views on SlideShare
514
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Whatistnsnames Whatistnsnames Document Transcript

    • The TNSNAMES.ORA file Networking TipsThe TNSNAMES.ORA fileWhat is it?When clients want to connect to an Instance, they need to know where the connectionrequest should be made, and how it should be made. The TNSNAMES.ORA file is a text file,located on each client machine, which gives the client these two crucial pieces ofinformation.Strictly speaking, clients don’t connect directly to an Instance at all. Instead, theyconnect to a Listener process, which knows where to establish the connection to theInstance on the client’s behalf. Therefore, a large part of the “where” information inTNSNAMES.ORA is related to identifying the machine on which the Listener is running, andthe port it is listening on. There is also an element which specifies which particularInstance the client wishes to connect to, since a single Listener process can be listening onbehalf of many Instances.The “how” information in the TNSNAMES.ORA file relates mainly to the networkingprotocol by which the client wishes to connect to the Instance (should it be TCP/IP,SPX/IPX and so on). There is also a part which informs the Listener whether the client isseeking a dedicated or shared server connection.Basic ConfigurationWe can see most of these elements coming together in the following simple example:DB9 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) ) )Whilst the layout is a bit convoluted (it doesn’t strictly need all those indents!), the basicinformation is straightforward enough. The Listener we are hoping to use to establish ourconnection is to be contacted using the TCP/IP protocol. It’s running on a machine calledMOZART, and it’s listening on port number 1521 (which happens to be the default portnumber).That gives us nearly everything we need to get in touch with the Listener itself.Copyright © Howard Rogers 2002 3/4/2002 Page 1 of 6
    • The TNSNAMES.ORA file Networking TipsI say “nearly everything”, because the use of the machine name “MOZART” is a bit of aproblem: that actually needs to be turned into an IP address somehow. Oracle has nomechanism for resolving server names into IP addresses of its own, but instead relies onstandard, external network resolution methods. For example, if you’re using Windows2000, you may well have Active Directory installed –in which case, it is up to Microsoft’snetworking software to convert “MOZART” into the IP address “192.168.0.1”. If you’re notusing Active Directory, you might have configured a local lmhosts file to resolve the name,or be using DNS.In the absence of any such external naming resolution mechanism, it’s legitimate toinclude the hard-coded IP address itself within the TNSNAMES.ORA file. Some would argue,indeed, that this is preferable –because then there’s no need to perform name resolution,and that should mean that User connections can be made faster than they otherwise wouldbe. That’s a fair point –but it also means that if your Server changes IP address one day(DHCP, anyone??!), none of your Users will be able to connect at all until they’ve manuallyaltered the TNSNAMES file –which is not a very desirable outcome.Nevertheless, assuming we can work out a physical IP address from the name “MOZART”,we can connect to the Listener. Our sample TNSNAMES.ORA then tells us that once we’retalking to the Listener, we should request a connection to the “db9.aldeburgh.local”service. It’s up to the Listener to work out what this actually means in practice –and it willuse the configuration information in its LISTENER.ORA file to do so. In this particular case,the LISTENER.ORA contains these lines:SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = db9.aldeburgh.local) (ORACLE_HOME = d:oracleora91) (SID_NAME = DB9) ) )…which means that a request to connect to “db9.aldeburgh.local” actually is interpretedto mean “connect me to the Instance called DB9”.This example TNSNAMES.ORA doesn’t explicitly say whether the connection to DB9 shoulduse dedicated or shared server connections, which means we’ll use a dedicated serverconnection, because that’s the default. If our database was configured to run in sharedserver mode, then we could have requested a dedicated connection, like this:DB9 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521))Copyright © Howard Rogers 2002 3/4/2002 Page 2 of 6
    • The TNSNAMES.ORA file Networking Tips ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) (SERVER=DEDICATED) ) )Notice the new parameter “SERVER=”, which goes under the ‘connect_data’ bit of the file.We could also have explicitly set “SERVER=SHARED”, to force shared server connections(but remember: this only works when you’ve already configured the entire database to runin shared server mode).This brings us to an interesting feature of the TNSNAMES.ORA file: it’s perfectly legitimateto have the one file reference the same Instance multiple times. You’d do that to giveyourself a choice of how to connect to it. For example, we might have this sort ofarrangement:USR = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) (SERVER=SHARED) ) )DBA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) (SERVER=DEDICATED) ) )Again, this example only makes sense if we assume that the DB9 database has already beenconfigured to run in shared server mode. What we’re doing here is referencing the sameInstance twice (“db9.aldeburgh.local”), once forcing shared server connections, and onceforcing dedicated server connections. Why would you want to do this? The clue is in thenames I’ve given to each of the connections: ordinary users might be expected to shareserver processes. But when I connect as a DBA to perform maintenance tasks, I really wantmy own dedicated set of database resources.Copyright © Howard Rogers 2002 3/4/2002 Page 3 of 6
    • The TNSNAMES.ORA file Networking TipsThe “USR” and “DBA” names I’ve used in this example are therefore known as “aliases”(more fully, “tnsnames aliases”), because they are just ‘hooks’ by which we indicate whichof the connections available in the TNSNAMES.ORA file we actually want to use at anygiven time.You choose which alias to use when you actually request the connection. In SQL*Plus, forexample, an ordinary user would type connect fred/bloggs@USR, whereas when I, theDBA, which to connect to do some heavy-duty maintenance, I’d type connectsys/oracle@DBA.In both cases, we end up connected to the DB9 Instance, because both aliases point to thesame Instance in the TNSNAMES.ORA. But I get a dedicated server process, the humbleuser gets a shared one.In a similar sort of way, it’s perfectly legitimate for a TNSNAMES.ORA file to containconnection information for many completely different Instances. Your Users might need toconnect to a ‘SALES’ database sometimes, and then to a ‘PURCHASES’ database at others.The TNSNAMES.ORA that would allow them to do this might look like this:SALES = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) ) )PURCH = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = monteverdi)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db8.aldeburgh.local) ) )The Users would then either type connect fred/bloggs@SALES or connectfred/bloggs@PURCH to switch between either database. Notice in this example, too,that it’s also permissible to have one TNSNAMES.ORA referencing databases which happento be housed on entirely different servers –SALES is running on “MOZART”, PURCH on“MONTEVERDI”.Copyright © Howard Rogers 2002 3/4/2002 Page 4 of 6
    • The TNSNAMES.ORA file Networking TipsAdvanced ConfigurationsIn more advanced configurations, you can also arrange the TNSNAMES.ORA to allow forwhat’s called ‘connect time failover’, meaning that if the User’s attempt to communicatewith the first Listener fails (perhaps because that Listener is, for some reason, not running),the connection request will automatically be directed to a second (and third, fourth and soon) Listener on a different machine. Such a TNSNAMES.ORA file might look like this:SALES = (DESCRIPTION = (FAILOVER = ON)(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = monteverdi)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) ) )The key parameter here is ‘failover=on’, which resides in the ‘description’ part of the file,rather than the ‘connect data’ bit. It’s actually on by default if you include the‘address_list’ parameter –though my earlier examples have already shown you that you canuse the ‘address_list’ parameter, and then only include one actual address –in which case,there’s nothing to failover to, and therefore, failover is effectively non-functioning.There are two caveats to mention about this sort of failover. It’s not the same thing as aUser losing a connection to one Instance, and being able to continue without interruptionon another. That’s called ‘transparent application failover’, and is configured completelydifferently.The second thing to mention is that connect time failover only works when you’re usingthe ‘automatic instance registration’ feature that was introduced in 8i. That’s becausethe Listener on the MONTEVERDI server can only know about the DB9 Instance running onMOZART if the Instance itself has told MONTEVERDI’s Listener that it is available. See mypaper “What is automatic instance registration, and is it useful?” for full details on thisfeature.There are other advanced things you can configure in the TNSNAMES.ORA, such as‘connection load balancing’ but again, I’ll leave the details to another paper, “How do Iconfigure failover and load balancing options?”Copyright © Howard Rogers 2002 3/4/2002 Page 5 of 6
    • The TNSNAMES.ORA file Networking TipsLocationThe TNSNAMES.ORA file is therefore a key component of what is generically called ‘localnaming’ –meaning that each client does its own working out where to direct connectionrequests. That means the TNSNAMES.ORA file must reside on each User’s machine.Specifically, it has to reside in the ORACLE_HOMEnetworkadmin directory, unless youset an operating system environment variable (called TNS_ADMIN) to point to some otherdirectory.In other words, if I do this:C:> set TNS_ADMIN=D:ANYWHEREWEIRD…then I can house my TNSNAMES.ORA in the ‘d:anywhereweird’ directory (the equivalentcommand on Unix is, of course, ‘export TNS_ADMIN…’).Don’t run away with the idea that TNSNAMES.ORA is only for client PCs, though. When youwant databases to talk to other databases (using database links, for example), a Serveritself needs to know how to connect to another Server. Similarly, when an Instance onMONTEVERDI needs to automatically register with a Listener on MOZART, it needs to knowhow to connect to the Listener on MOZART. In such cases, a copy of TNSNAMES.ORA alsoneeds to reside on the Server –and again, it will reside in ORACLE_HOMEnetworkadmin,or wherever the TNS_ADMIN environment variable is set to.AlternativesHaving one copy of the TNSNAMES.ORA on every single User’s PC is OK when you’ve onlygot 10 Users. But when you’ve got 50 or 100 (or more, of course), maintaining that manycopies of the file becomes a right royal pain. At which point, you probably drop any ideaof using ‘local naming’ and instead start to think of configuring a central naming method,which is what the Oracle Names Server does for you. Again, I discuss Names Server indetail in another paper.The point I’d make here is that if you ever do decide to configure a Names Server, theprinciples on which it works are practically identical to the ones I’ve discussed here: itmight be a different method of telling us what to connect to, and how to do it, but thecore information it uses is just the same as what TNSNAMES.ORA provides –sounderstanding how the TNSNAMES.ORA does its stuff is still extremely useful.Copyright © Howard Rogers 2002 3/4/2002 Page 6 of 6