The difference between sid and service_name in oracle

Reprinted from: http://blog.csdn.net/zhangzl1012/article/details/50752572

 

 Let me tell you a little story. In June 2015, a customer migrated the database from a single instance database to a RAC. The JAVA application fails to connect to the database, but PL/SQL can connect to the database. Because the project is relatively large, although it is switched in the middle of the night, it cannot accept a long-term business stoppage. At the time, I was only scratching the surface of ORACLE technology. After consulting the company's research and development, the suggestion they gave me is: referring to the connection parameters of PL/SQL, change the url of the jdbc connection in spring from jdbc:oracle:thin:@10.2.0.2:1521:orcl to jdbc:oracle: thin:@(DESCRIPTION =(ADDRESS_LIST =(ADDRESS =(PROTOCOL = TCP)(HOST = 10.2.0.2)(PORT = 1521)))(CONNECT_DATA =(SERVICE_NAME = orcl))), the problem is solved, I was quite Admire the company's development. Now it seems that this is not the best solution. By explaining the difference between SID and SERVICE_NAME, I will give a better solution.

        Before explaining SID and SERVICE_NAME, let's talk about an example. An instance is a collection of processes and memory required by an operating system to access a database. Instances can be started even without any data files. But to access the database, the database file must be loaded into the instance. The difference between an instance and a database can be summed up simply as: an instance is temporary, it exists only as long as the associated process and memory collection exists, while a database is permanent, it exists as long as the file exists. An instance can only correspond to one database, but a database can be corresponding to multiple instances (such as RAC). RAC is a system in which multiple instances open a database file at the same time. Structurally, there are multiple machines. Each machine runs an instance, and each instance opens the same database (this is realized by disk sharing technology). Caches need to be synchronized between instances to ensure that multiple instances are completely consistent and will not conflict or even overwrite each other.

      SID or INSTANCE_NAME is used to uniquely identify the instance. SERVICE_NAME is newly introduced by oracle8i. Before 8i, a database could only be corresponded by one instance, but with the requirement of high performance and the use of parallel technology, a database can be corresponded by multiple instances, such as RAC. In order to take full advantage of all instances and make client connection configuration simple, ORACLE proposes the concept of SERVICE_NAME. This parameter corresponds directly to the database, not an instance.

      After learning about SID and SERVICE_NAME , I suddenly felt that the solution used in the previous story was not the best solution, because SERVICE_NAME appeared to deal with concurrency technology and simplify client connection configuration. A better solution should be found via SERVICE_NAME . There are three ways to know that JDBC connects to ORACLE by looking for JDBC help:

Format 1: jdbc:oracle:thin:@// (double slashes here are optional) <host>:<port>/<service_name> (SID is also available here)
Format 2: jdbc:oracle:thin:@< host>:<port>:<SID> (serivce_name will not work here)
Format 3: jdbc:oracle:thin:@<TNSName> 

       It is not difficult to see that before the use of RAC in the story, JDBC was connected using format 2. After using RAC, the number of instances increased, the SID was no longer unique, and format 2 could not fully utilize all resources. The connection method for R&D reference PL/SQL happens to use format three. Because the java application server is separated from the database server, there is no oracle server and client on the application server. Although the solution does not use TNSName, but uses the connection description of TNSName, the effect is the same. Since JDBC has three connection schemes, let's look at the first scheme again. In addition to the previous explanation, I think everyone already knows how to modify the problem in the story, just change it to jdbc:oracle:thin:@// 10.2.0.2:1521 /orcl, and this format Single instance databases are also supported. This is also the original intention of ORACLE to increase SERVICE_NAME after 8i .

      You can see that SID is relative to the instance, SERVICE_NAME is a concept relative to the database

Do a test locally. Generally, the default SID and SERVICE_NAME of a single-instance oracle are the same during installation. We first connect to the database and modify SERVICE_NAME. Methods as below:

1. Enter sqlplus / as sysdba in cmd to connect to the database

2. Enter show parameter service_name to view the current service name (can be omitted)

3.输入alter system set service_names='new_service_name' scope=both

本地sid与service_name都是orcl,这里service_name改为‘kk’然后在java的jdbc连接中设置url='jdbc:orcl:thin:@localhost:1521:orcl'可以连接上。设置成'jdbc:orcl:thin:@localhost:1521:kk'则连接不上。并报错:TNS:listener dose not currently know of SID given in connect descriptor。可以看出是监听器不能识别这个sid。把listener.ora文件中的SID_NAME改为kk则报:TNS:listener could not hand off client connection,即监听器不能处理这个客户端连接。

但是如果用jdbc:oracle:thin:@//<host>:<port>/<service_name>的形式填写地址则orcl和kk都可以连接上

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326021835&siteId=291194637