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

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 I

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

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

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

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

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

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

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

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

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

(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