OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P19 docx

OCA/OCP Oracle Database 11g All-in-One Exam Guide 136 A Word on Oracle Net and Communication Protocols Oracle Net is a layered protocol: it runs on top of whatever communications protocol is supported by your operating system. Historically, Sqlnet could work with all the popular protocols (with the exception of NetBIOS/NetBEUI, which has limited functionality and cannot be used for large database systems: it cannot be routed), but in release 11g Oracle’s network support is limited to TCP, TCP with secure sockets, Windows Named Pipes (or NMP), and the newer Sockets Direct Protocol (or SDP) over Infiniband high- speed networks. This reduction in protocol support is in line with industry standards. All operating systems also have an Inter-Process Communication (or IPC) protocol proprietary to the operating system—this is also available to Oracle Net for local connections where the user process is on the same machine as the server. This layering of Oracle Net on top of whatever is provided by your operating system provides Oracle platform independence. You, as DBA, do not need to know anything about the underlying network; you configure Oracle Net to use whatever protocol has been configured by your network administrators. You need not concern yourself with what is happening at a lower networking layer. TCP is, for better or worse, undoubtedly the most popular protocol worldwide, so that is the one used in the examples that follow. The use of industry standard protocols means that there need be no dependency between the server-side and the client-side platforms. There is no reason why, for example, a client on Windows cannot talk to a database on Unix. As long as the platform can offer a TCP layer 4 interface, then Oracle Net can use it. With regard to conformance with the Open Systems Interconnection (or OSI) seven-layer model to which all IT vendors are supposed to comply, Oracle Net maps on to layers 5, 6, and 7: the session, presentation, and application layers. The protocol adapters installed with the standard Oracle installation provide the crossover to layer 4, the transport layer, provided by your operating system. Thus Oracle Net is responsible for establishing sessions between the end systems once TCP (or whatever else you are using) has established a layer 4 connection. The presentation layer functions are handled by the Oracle Net Two Task Common (or TTC) layer. TTC is responsible for any conversions necessary when data is transferred between the user process and the server process, such as character set changes. Then the application layer functions are the user and server processes themselves. Establishing a Session When a user, through their user process, wishes to establish a session against an instance, they may issue a command like CONNECT STORE/ADMIN123@ORCL11G Of course, if they are using a graphical user interface, they won’t type in that command. but will be prompted to enter the details into a logon screen—but one way or another that is the command the user process will generate. It is now time to go into what actually happens when that command is processed. First, break down the command into its components. There is a database user name (“STORE”), followed by a database password (“ADMIN123”), and the two are separated by a “/” as a delimiter. Then there is an “@” symbol, followed by a connect string, “ORCL11G”. The “@” symbol is an indication to the user process that a network connection is Chapter 4: Oracle Networking 137 PART I required. If the “@” and the connect string are omitted, then the user process will assume that the instance you wish to connect to is running on the local machine, and that the always-available IPC protocol can be used. If the “@” and a connect string are included, then the user process will assume that you are requesting a network connection to an instance on a remote machine—though in fact, you could be bouncing off the network card and back to the machine on to which you are logged. Connecting to a Local Instance Even when you connect to an instance running on your local machine, you still use Oracle Net. All Oracle sessions use a network protocol to implement the separation of user code from server code, but for a local connection the protocol is IPC: this is the protocol provided by your operating system that will allow processes to communicate within the host machine. This is the only type of connection that does not require a database listener; indeed, local connections do not require any configuration at all. The only information needed is to tell your user process which instance you want to connect to. Remember that there could be several instances running on your local computer. You give the process this information through an environment variable. Figure 4-2 shows examples of this on Linux, and Figure 4-3 shows how to connect to a local database on Windows. Figure 4-2 Local database connections—Linux OCA/OCP Oracle Database 11g All-in-One Exam Guide 138 Remember that the only difference between platforms is the syntax for setting environment variables, as demonstrated in Figures 4-2 and 4-3. Name Resolution When connecting using Oracle Net, the first stage is to work out exactly what it is you want to connect to. This is the process of name resolution. If your connect statement includes the connect string “@orcl11g”, Oracle Net has to work out what is meant by “orcl11g”. This means that the string has to be resolved into certain pieces of information: the protocol you want to use (assume that this is TCP), the IP address on which the database listener is running, the port that the listener is monitoring for incoming connection requests, and the name of the instance (which need not be the same as the connect string) to which you wish to connect. There are variations: rather than an IP address, the connect string can include a hostname, which then gets further resolved to an IP address by a DNS server. Rather than specifying an instance by name, the connect string can include the name of a service, which (in a RAC environment) could be made up of a number of instances. In a single-instance environment, services can Figure 4-3 Local database connections—Windows Chapter 4: Oracle Networking 139 PART I still be used—perhaps to assist with tracking the workload imposed on the database by different groups of users. You can configure a number of ways of resolving connect strings to address and instance names, but one way or another the name resolution process gives your user process enough information to go across the network to a database listener and request a connection to a particular instance. Launching a Server Process The database listener, running on the server machine, uses one or more protocols to monitor one or more ports on one or more network interface cards for incoming connection requests. You can further complicate matters by running multiple listeners on one machine, and any one listener can accept connection requests for a number of instances. When it receives a connect request, the listener must first validate whether the instance requested is actually available. Assuming that it is, the listener will launch a new server process to service the user process. Thus if you have a thousand users logging on concurrently to your instance, you will be launching a thousand server processes. This is known as the dedicated server architecture. Later in this chapter you’ll see the shared server alternative where each user process is handled by a dedicated dispatcher process, but shared by multiple user processes. In the TCP environment, each dedicated server process launched by a listener will acquire a unique TCP port number. This will be assigned at process startup time by your operating system’s port mapping algorithm. The port number gets passed back to the user process by the listener (or on some operating systems the socket already opened to the listener is transferred to the new port number), and the user process can then communicate directly with its server process. The listener has now completed its work and waits for the next connect request. EXAM TIP If the database listener is not running, no new server processes can be launched—but this will not affect any existing sessions that have already been established. Creating a Listener A listener is defined in a file: the listener.ora file, whose default location is in the ORACLE_HOME/network/admin directory. As a minimum, the listener.ora file must include a section for one listener, which states its name and the protocol and listening address it will use. You can configure several listeners in the one file, but they must all have different names and addresses. TIP You can run a listener completely on defaults, without a listener .ora file at all. It will listen on whatever address resolves to the machine’s hostname, on port 1521. Always configure the listener.ora file, to make your Oracle Net environment self-documenting. OCA/OCP Oracle Database 11g All-in-One Exam Guide 140 As with other files used to configure Oracle Net, the listener.ora file can be very fussy about seemingly trivial points of syntax, such as case sensitivity, white spaces, and abbreviations. For this reason, many DBAs do not like to edit it by hand (though there is no reason not to). Oracle provides three graphical tools to manage Oracle Net: Enterprise Manager (Database Control or Grid Control), the Net Manager, and the Net Configuration Assistant. The latter two tools are both written in Java. There is considerable overlap between the functionality of these tools, though there are a few things that can only be done in one or another. This is an example of a listener.ora file: LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1)(PORT = 1521)) ) LIST2 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1522)) (ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1.bplc.co.za)(PORT = 1522)) ) ) The first section of this file defines a listener called LISTENER, monitoring the local hostname on the default port, 1521. The second section defines another listener called LIST2. This listener monitors port 1522 on both the hostname address and a loopback address. To create the listener, you need do nothing more than create an entry in the listener.ora file, and start it. Under Windows the listener will run as a Windows service, but there is no need to create the service explicitly; it will be created implicitly the first time the listener is started. From then, if you wish, it can be started and stopped like any other Windows service. Figure 4-4 shows the Net Manager’s view of the listener LIST2, and Figure 4-5 shows it through the Net Configuration Assistant. Note that the Net Manager lets you configure multiple listening addresses for a listener (Figure 4-4 shows the loopback address), whereas the Net Configuration Assistant does not: it can only see the one address of the hostname; there is no prompt for creating or viewing any other. Database Registration A listener is necessary to spawn server processes against an instance. In order to do this, it needs to know what instances are available on the computer on which it is running. A listener finds out about instances by the process of “registration.” EXAM TIP The listener and the instance must be running on the same computer, unless you are using RAC. In a RAC environment, any listener on any computer in the cluster can connect you to any instance on any computer. Chapter 4: Oracle Networking 141 PART I Figure 4-4 A listener definition as created or viewed with the Net Manager Figure 4-5 A listener definition as created or viewed with the Net Configuration Assistant OCA/OCP Oracle Database 11g All-in-One Exam Guide 142 There are two methods for registering an instance with a database: static and dynamic registration. For static registration, you hard-code a list of instances in the listener.ora file. Dynamic registration means that the instance itself, at startup time, locates a listener and registers with it. Static Registration As a general rule, dynamic registration is a better option, but there are circumstances when you will resort to static registration. Dynamic registration was introduced with release 8i, but if you have older databases that your listener must connect users to, you will have to register them statically. Also some applications may require static registration: typically management tools. To register an instance statically, add an appropriate entry to the listener.ora file: LIST2 = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1522)) ) ) SID_LIST_LIST2 = (SID_LIST = (SID_DESC = (ORACLE_HOME = /u01/oracle/app/product/11.1.0/db_1) (SID_NAME = ocp11g) ) ) This entry will configure the listener called LIST2 to accept connection requests for an instance called ocp11g. It says nothing about whether the instance is running or even exists at all. The directive ORACLE_HOME is only required if the database listener is not running from the same Oracle Home as the instance. If this is the case, then this directive will let the listener find the executable file that it must run to launch a server process. Usually, this is only necessary if configuring a listener to make connections to instances of a different version, which have to be running off a different home. Dynamic Instance Registration This is the preferred method by which an instance will register with a listener. The initialization parameter local_listener tells the instance the network address that it should contact to find a listener with which to register. At instance startup time, the PMON process will use this parameter to locate a listener, and inform it of the instance’s name and the names of the service(s) that the instance is offering. The instance name is defined by the instance_name parameter, and the service_names parameter will have defaulted to this suffixed by the db_domain parameter, which will default to null. It is possible to create and start additional services at any time, either by changing the value of the service_names parameter (which can be a comma-delimited list, if the instance is to offer several services) or programmatically using the DBMS_SERVICE package. Any change to the services must be registered with the local listener. If this is not done, the listener won’t know what services are being offered, and will therefore not Chapter 4: Oracle Networking 143 PART I be able to set up sessions to them. The PMON process will register automatically once a minute, but at any time subsequent to instance startup you can force a re-registration by executing the command SQL> alter system register; TIP You will need to register your instance with the listener with alter system register if you have restarted the listener, or if you started the database instance before starting the listener or you can wait a minute for PMON to register. Dynamic registration is a better option than static registration because it ensures that only running instances and available services are registered with the listener, and also that there are no errors in the instance and service names. It is all too easy to make mistakes here, particularly if you are editing the listener.ora file by hand. Also, when the instance shuts down, it will deregister from the listener automatically. From release 9i onward, dynamic registration requires no configuration at all if your listener is running on the default port, 1521. All instances will automatically look for a listener on the local host on that port, and register themselves if they find one. However, if your listener is not running on the default port on the address identified by the hostname, you must specify where the listener is by setting the parameter local_listener and re-registering, for example, SQL> alter system set local_listener=list2; SQL> alter system register; In this example, the local_listener has been specified by name. This name needs to be resolved into an address in order for the instance to find the listener and register itself, as described in the following section. An alternative technique is to hard-code the listener’s address in the parameter: SQL> alter system set local_listener='(address=(protocol=tcp)(host=127.0.0.1)(port=1522))'; This syntax is perfectly acceptable, but the use of a name that can be resolved is better practice, as it places a layer of abstraction between the logical name and the physical address. The abstraction means that if the listening address ever has to be changed, one need only change it in the name resolution service, rather than having to change it in every instance that uses it. Techniques for Name Resolution At the beginning of this chapter you saw that to establish a session against an instance, your user process must issue a connect string. That string resolves to the address of a listener and the name of an instance or service. In the discussion of dynamic instance registration, you saw again the use of a logical name for a listener, which needs to be resolved into a network address in order for an instance to find a listener with which to register. Oracle provides four methods of name resolution: easy connect, local OCA/OCP Oracle Database 11g All-in-One Exam Guide 144 naming, directory naming, and external naming. It is probably true to say that the majority of Oracle sites use local naming, but there is no question that directory naming is the best method for a large and complex installation. Easy Connect The Easy Connect name resolution method was introduced with release 10g. It is very easy to use—it requires no configuration at all. But it is limited to one protocol: TCP. The other name resolution methods can use any of the other supported protocols, such as TCP with secure sockets, or Named Pipes. Another limitation is that Easy Connect cannot be used with any of Oracle Net’s more advanced capabilities, such as load balancing or connect-time failover across different network routes. It is fair to say that Easy Connect is a method you as the DBA will find very handy to use, but that it is not a method of much use for your end users. Easy Connect is enabled by default. You invoke it with connect string syntax such as SQL> connect store/admin123@jwlnx1.bplc.co.za:1522/ocp11g In this example, SQL*Plus will use TCP to go to port 1522 on the IP address to which the hostname resolves. Then if there is a listener running on that port and address, it will ask the listener to spawn a server process against an instance that is part of the service called ocp11g. Easy Connect can be made even easier: SQL> connect store/admin123@jwlnx1.bplc.co.za This syntax will also work, but only if the listener running on this hostname is using port 1521, and the service name registered with the listener is jwlnx1.bplc.co.za, the same as the computer name. Local Naming With local naming the user supplies an alias, known as an Oracle Net service alias, for the connect string, and the alias is resolved by a local file into the full network address (protocol, address, port, and service or instance name). This local file is the infamous tnsnames.ora file, which has caused DBAs much grief over the years. Consider this example of a tnsnames.ora file: ocp11g = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1.bplc.co.za)(PORT = 1522)) ) (CONNECT_DATA = (service_name = ocp11g) ) ) test = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = serv2.bplc.co.za)(PORT = 1521)) ) (CONNECT_DATA = Chapter 4: Oracle Networking 145 PART I (sid = testdb) ) ) This tnsnames.ora file has two Oracle Net service aliases defined within it: ocp11g and test. These aliases are what your users will provide in their connect statements. The first entry, ocp11g, simply says that when the connect string “@ocp11g” is issued, your user process should use the TCP protocol to go the machine jwlnx1.bplc.co.za, contact it on port 1522, and ask the listener monitoring that port to establish a session against the instance with the service name ocp11g. The second entry, test, directs users to a listener on a different machine and asks for a session against the instance called testdb. TIP There need be no relationship between the alias, the service name, and the instance name, but for the sake of your sanity you will usually keep them the same. Local naming supports all protocols and all the advanced features of Oracle Net, but maintaining tnsnames.ora files on all your client machines can be an extremely time-consuming task. The tnsnames.ora file is also notoriously sensitive to apparently trivial variations in layout. Using the GUI tools will help avoid such problems. Directory Naming and External Naming Directory naming points the user toward an LDAP directory server to resolve aliases. LDAP (the Lightweight Directory Protocol) is a widely used standard that Oracle Corporation (and other mainstream software vendors) is encouraging organizations to adopt. To use directory naming, you must first install and configure a directory server somewhere on your network. Oracle provides an LDAP server (the Oracle Internet Directory) as part of the Oracle Application Server, but you do not have to use that—if you already have a Microsoft Active Directory, that will be perfectly adequate. IBM and Novell also sell directory servers conforming to the LDAP standard. Like local naming, directory naming supports all Oracle Net features—but unlike local naming, it uses a central repository, the directory server, for all your name resolution details. This is much easier to maintain than many tnsnames.ora files distributed across your whole user community. External naming is conceptually similar to directory naming, but it uses third- party naming services such as Sun’s Network Information Services (NIS+) or the Cell Directory Services (CDS) that are part of the Distributed Computing Environment (DCE). The use of directories and external naming services is beyond the scope of the OCP syllabus. The Listener Control Utility You can start and stop listeners through Database Control, but there is also a command-line utility, lsnrctl (it is lsnrctl.exe on Windows). The lsnrctl commands can be run directly from an operating system prompt, or through a simple . register. Oracle provides four methods of name resolution: easy connect, local OCA/ OCP Oracle Database 11g All-in-One Exam Guide 144 naming, directory naming, and external naming. It is probably. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 136 A Word on Oracle Net and Communication Protocols Oracle Net is a layered protocol: it runs on top of whatever communications protocol. Database 11g All-in-One Exam Guide 142 There are two methods for registering an instance with a database: static and dynamic registration. For static registration, you hard-code a list of instances