service name oracle что это
Service name oracle что это
Имя экземпляра базы данных
Экземпляр базы данных состоит из области SGA и процессов ORACLE. Имя экземпляра базы данных указывается в файле инициализации init.ora параметром instance_name.
Оракловский системный идентификатор SID (System IDentifier – системный идентификатор) является уникальным именем, которое однозначно идентифицирует экземпляр/базу данных. Хранится в переменной среды ORACLE_SID и используется утилитами и сетевыми компонентами для доступа к базе данных.
Здесь можно почитать, как переименовать базу данных.
Глобальное имя базы данных
Для того, чтобы база данных была уникально идентифицирована в глобальном масштабе используется глобальное имя базы данных. Оно состоит из имени базы данных и домена базы данных. Так как две базы данных в одном домене не могут иметь одинаковые имена, то глобальное имя базы данных будет уникальным.
Имена службы (сервиса) базы данных.
Кроме понятия SID существует также и понятие SERVICE NAME, которые зачастую не различают. Тем не менее, для пользователей база данных ORACLE представляет собой службу (сервис) операционной системы. Имя сервиса (SERVICE_NAME) – это сравнительно новое понятие, введенное начиная с СУБД Oracle 8i. SERVICE_NAME определяет одно или ряд имен для подключения к одному экземпляру базы данных. То есть можно указать несколько имен сервиса, ссылающихся на один экземпляр, с различными настройками. Понятие служба БД используется для логического группирования сеансов с целью иметь обобщенную единицу слежения и управления при использовании общей БД разными приложениями. Службу рекомендуется связывать с набором приложений, объединенных общими свойствами, пороговыми характеристиками или правилами потребления ресурсов СУБД.
Возможные значения SERVICE_NAME указываются в сетевых установках Oracle и регистрируются в качестве службы БД процессом listener.
Стандартный способ получения SID и SERVICE_NAME, который работал до десятой версии СУБД Oracle – это использование утилиты lsnrctl. Для этого достаточно воспользоваться командой services:
В выводе команды мы можем видеть системный идентификатор, он же – SID (Instance), и имя сервиса – SERVICE_NAME (Service). В данном случае они совпадают, но это бывает не всегда.
Этот запрос для ORA10g покажет все зарегистрированные сервисы. Помимо сконфигурированных вами сервисов, всегда имеются две внутренние службы: SYS$BACKGROUND используется внутренними процессами СУБД, а к SYS$USERS причисляются соединения пользователей, не указавших желаемую им службу.
Итог: Если база данных зарегистрирована листенером, как службу с определенным SERVICE_NAME, тогда в tnsnames.ora можно использовать значение параметра SERVICE_NAME, иначе нужно будет использовать значение SID.
2 Identifying and Accessing the Database
This chapter explains how databases are identified and how clients access them. This chapter contains the following topics:
Understanding Database Instances
Figure 2-1 One Instance for Each Database
Description of «Figure 2-1 One Instance for Each Database»
Some hardware architectures allow multiple computers to share access to data, software, or peripheral devices. Oracle Real Application Clusters (Oracle RAC) (Oracle RAC) can take advantage of such architecture by running multiple instances on different computers that share a single physical database.
Figure 2-2 Multiple Instances Associated with an Oracle RAC Database
Description of «Figure 2-2 Multiple Instances Associated with an Oracle RAC Database»
Understanding Database Services
Figure 2-3 One Service for Each Database
Description of «Figure 2-3 One Service for Each Database»
A service name can identify multiple database instances, and an instance can belong to multiple services. For this reason, the listener acts as a mediator between the client and instances and routes the connection request to the appropriate instance. Clients connecting to a service need not specify which instance they require.
Figure 2-4 shows clients connecting to multiple services associated with one database.
Figure 2-4 Multiple Services Associated with One Database
Description of «Figure 2-4 Multiple Services Associated with One Database»
Associating multiple services with one database enables the following functionality:
A single database can be identified different ways by different clients.
A database administrator can limit or reserve system resources. This level of control enables better allocation of resources to clients requesting one of these services.
Oracle Database Administrator’s Guide for additional information about initialization parameters
Oracle Database SQL Reference for additional information about the ALTER SYSTEM statement
Oracle Database Reference for additional information about the SERVICE_NAMES parameter
Oracle Database PL/SQL Packages and Types Reference for additional information about the DBMS_SERVICE package.
Connecting to a Database Service
The following example shows the tnsnames.ora entry for the preceding Easy Connect connect descriptor and database service:
This section contains the following topics:
About Connect Descriptors
A connect descriptor is comprised of one or more protocol addresses of the listener and the connect information for the destination service in the tnsnames.ora file. Example 2-1 shows a connect descriptor mapped to the sales database.
Example 2-1 Connect Descriptor
As shown in Example 2-1, the connect descriptor contains the following parameters:
The ADDRESS section contains the following:
PROTOCOL parameter, which identifies the listener protocol address. The protocol is tcp for TCP/IP.
The CONNECT_DATA section contains the following:
INSTANCE_NAME parameter, which identifies the database instance. The instance name is optional.
The INSTANCE_NAME parameter in the initialization parameter file defaults to the SID entered during installation or database creation.
About IPv6 Addresses in Connect Descriptors
A host can use IP version 4 (IPv4) and IP version 6 (IPv6) interfaces. IPv6 addresses and host names that resolve to IPv6 addresses are usable in the HOST parameter of a TNS connect address, which can be obtained through any of the supported Net naming methods listed in Table 2-1.
End-to-end connectivity using IPv6 in Oracle Database 11 g requires the following configuration:
The client TNS connect address must connect to the Oracle Net Listener on the IPv6 endpoint.
The database instance configured for Oracle Net Listener must listen for connection requests on IPv6 endpoints.
For a given host name, Oracle Net attempts to connect to all IP addresses returned by Domain Name System (DNS) name resolution until a successful connection is established or all addresses have been attempted. Suppose that in Example 2-1 the sales-server host is an IPv4-only host that is accepting client connections. DNS maps sales-server to the following IP addresses:
IPv6 address 2001:0DB8:0:0::200C:417A
IPv4 address 192.168.2.213
In this case, Oracle Net first tries to connect on the IPv6 address because it is first in the DNS list. In this example sales-server does not support IPv6 connectivity, so this attempt fails. Oracle Net proceeds to connect to the IPv4 address, which succeeds.
About the Protocol Address
The preceding example shows a TCP/IP protocol address that specifies the host of the listener and a port number. Client connect descriptors configured with this same protocol address can send connection requests to this listener.
About Service Registration
Specifying an Instance Name
Specifying a Service Handler
When the listener receives the client request, it selects one of the registered service handlers. Depending on the type of handler selected, the communication protocol used, and the operating system of the database server, the listener performs one of the following actions:
Hands the connect request directly off to a dispatcher.
Sends a redirect message back to the client with the location of the dispatcher or dedicated server process. The client then connects directly to the dispatcher or dedicated server process.
Spawns a dedicated server process and passes the client connection to the dedicated server process.
After the listener has completed the connection operation for the client, the client communicates directly with the Oracle database without the listener’s involvement. The listener resumes listening for incoming network sessions.
The following are considerations when specifying service handlers:
If database resident connection pooling is enabled on the server, then specify (SERVER=pooled) to get a connection from the pool. If database resident connection pooling is not enabled on the server, then the client request is rejected, and the user receives an error message.
«Understanding Service Handlers» for a description about these service handler types
«About the Listener and Connection Requests» for a discussion about how the listener works with service handlers
Oracle Call Interface Programmer’s Guide and Oracle Database Administrator’s Guide for additional information about enabling and configuring database resident connection pooling
Understanding Service Handlers
Service handlers act as connection points to an Oracle database. A service handler can be a shared server process or a dedicated server process, or pooled.
This section contains the following topics:
About Dispatchers
The shared server architecture uses a dispatcher process to direct client connections to a common request queue. An idle shared server process from a shared pool of server processes picks up a request from the common queue. This approach enables a small pool of server processes to serve a large number of clients. A significant advantage of the shared server model over the dedicated server model is reduced system resources, enabling support of an increased number of users.
The listener uses the dispatcher as a type of service handler to which it can direct client requests. When a client request arrives, the listener performs one of the following actions:
Hands the connection request directly to a dispatcher.
Issues a redirect message to the client, containing the protocol address of a dispatcher. The client then terminates the network session to the listener and establishes a network session to the dispatcher, using the network address provided in the redirect message.
The listener uses direct hand off whenever possible. Redirect messages are used, for example, when dispatchers are remote to the listener.
Figure 2-5 shows the listener handing a connection request directly to a dispatcher.
The listener receives a client connection request.
The listener hands the connect request directly to the dispatcher.
The client is now connected to the dispatcher.
Figure 2-5 Direct Hand-Off to a Dispatcher
Description of «Figure 2-5 Direct Hand-Off to a Dispatcher»
Figure 2-6 shows the role of a dispatcher in a redirected connection.
The listener receives a client connection request.
The listener provides the location of the dispatcher to the client in a redirect message.
The client connects directly to the dispatcher.
Figure 2-6 Redirected Connection to a Dispatcher
Description of «Figure 2-6 Redirected Connection to a Dispatcher»
About Dedicated Server Processes
In a dedicated server configuration, the listener starts a separate dedicated server process for each incoming client connection request dedicated to servicing the client. After the session is complete, the dedicated server process terminates. Because a dedicated server process has to be started for each connection, this configuration may require more system resources than shared server configurations.
A dedicated server process is a type of service handler that the listener starts when it receives a client request. To complete a client/server connection, one of the following actions occurs:
The dedicated server inherits the connection request from the listener.
The dedicated server informs the listener of its listening protocol address. The listener passes the protocol address to the client in a redirect message and terminates the connection. The client connects to the dedicated server directly using the protocol address.
One of the preceding actions is selected based on the operating system and the transport protocol.
If the client and database exist on the same computer, then a client connection can be passed directly to a dedicated server process without going through the listener. This is known as a bequeath protocol. The application initiating the session spawns a dedicated server process for the connection request. This happens automatically if the application used to start the database is on the same computer as the database.
In order for remote clients to connect to dedicated servers, the listener and the database instance must be running on the same computer.
Figure 2-7 shows the listener passing a client connection request to a dedicated server process.
The listener receives a client connection request.
The listener starts a dedicated server process, and the dedicated server inherits the connection request from the listener.
The client is now connected directly to the dedicated server.
Figure 2-7 Connection to a Dedicated Server Process
Description of «Figure 2-7 Connection to a Dedicated Server Process»
Figure 2-8 shows the role of a dedicated server in a redirected connection.
The listener receives a client connection request.
The listener starts a dedicated server process.
The listener provides the location of the dedicated server process to the client in a redirect message.
The client connects directly to the dedicated server.
Figure 2-8 Redirected Connection to a Dedicated Server Process
Description of «Figure 2-8 Redirected Connection to a Dedicated Server Process»
About Database Resident Connection Pooling
Database resident connection pooling provides a connection pool in the database server for typical Web application usage scenarios in which an application acquires a database connection, works on it for a relatively short duration, and then releases it. Database resident connection pooling pools «dedicated» servers. A pooled server is the equivalent of a server foreground process and a database session combined.
Database resident connection pooling complements middle-tier connection pools that share connections between threads in a middle-tier process. In addition, it enables sharing of database connections across middle-tier processes on the same middle-tier host and even across middle-tier hosts. This results in significant reduction in key database resources needed to support a large number of client connections, thereby reducing the database tier memory footprint and boosting the scalability of both middle-tier and database tiers. Having a pool of readily available servers has the additional benefit of reducing the cost of creating and closing client connections.
Database resident connection pooling provides pooling for dedicated connection s across client applications and processes. This feature is useful for applications that must maintain persistent connections to the database and optimize server resources (such as memory).
Clients obtaining connections out of the database resident connection pool are persistently connected to a background process, the connection broker, instead of the dedicated servers. The connection broker implements the pool functionality and performs the multiplexing of inbound connections from the clients to a pool of dedicated servers with sessions.
When a client must perform database work, the connection broker picks up a dedicated server from the pool and assigns it to the client. Subsequently, the client is directly connected to the dedicated server until the request is served. After the server finishes processing the client request, the server goes back into the pool and the connection from the client is restored to the connection broker.
Figure 2-9 Dedicated Server Processes Handling Connections Through the Connection Broker Process
Description of «Figure 2-9 Dedicated Server Processes Handling Connections Through the Connection Broker Process»
Understanding Naming Methods
Network route to the service, including the location of the listener through a protocol address
The following CONNECT command uses a connect string that has a complete connect descriptor as the connect identifier instead of a net service name. The string should be entered on a single line. It is shown on two lines because of page width.
When net service name sales is used, connection processing takes place by first mapping sales to the connect descriptor. This mapped information is accessed by naming method s. The following naming methods are available:
Easy Connect naming
Choosing a Naming Method
Selecting the appropriate naming method for mapping names to connect descriptors depends upon the size of the organization.
For a small organization with only a few databases, use Easy Connect naming to make TCP/IP connections with the host name of the database server or local naming to store names in tnsnames.ora file on the clients.
For large organizations with several databases, use directory naming to store names in a centralized directory server.
For an Internet network, configure the application Web servers needed to connect to the databases with the local naming method.
Table 2-1 summarizes the relative advantages and disadvantages of each naming method and provides recommendations for using them in the network.
Table 2-1 Naming Methods: Advantages and Disadvantages
| Naming Method | Description | Advantages/Disadvantages | Recommended for: |
|---|---|---|---|