博文说明【前言】：

    本文将通过个人口吻介绍在ORACLE中的Server_name和实例名SID的相关概念，在目前时间点【2017年5月22号】下，所掌握的技术水平有限，可能会存在不少知识理解不够深入或全面，望大家指出问题共同交流，在后续工作及学习中如发现本文内容与实际情况有所偏差，将会完善该博文内容。

本文参考文献引用链接：

1、http://blog.csdn.net/luman1991/article/details/56286371

2、http://blog.csdn.net/yaksok/article/details/52130228

正文：

案例分析：

一、引入关系：

服务器=公司

数据库=运维支持部（数据库分为单机和集群环境，也就是部门的人数多少关系）

数据库集群环境=运维支持部门（假设部门有小丽，小美两名员工，对应SID1，SID2）

数据库连接请求=公司员工或者其他部门请求运维部提供技术支持

数据库服务器=装载了数据库的服务器，也就是拥有活跃运维部门的公司，当然服务器除了装载数据库，我还可以安装其他软件提供其他服务

二、工作过程：

1、老王是研发部门的一个员工，在连接数据库的发现无法连接，因此在公司内部沟通平台发送了一个请求，请求运维部查看下数据库服务是否异常。

2）运维部的小丽接受了这个问题，也就是小丽给老王提供了这次服务，最终顺利解决该问题

3）过了一周，老王又发现数据库连接有问题，又在公司内部沟通平台发送了一个请求，请求运维部查看下数据库服务是否异常。

4）运维部的小美接受了这个问题，也就是小美给老王提供了这次服务，最终顺利解决该问题

三、案例分析：

1、这里真实提供服务的就是SID（第一次是小丽SID1，第二次是小美SID2，第三次也是两者之一）

2、运维支持部门，在公司内部沟通平台对应有一个虚拟用户（Server_name），用户将反馈提交给该用户，然后由该虚拟用户去调度后方真实节点提供服务，使用过JIRA平台的小伙伴应该深有感触。

3、用户不用关系，真实给我提供服务的人是谁，每次只需要将问题提交给该虚拟用户（server_name），就会有支持人员来解决我的问题。

注意：在这里用户如果知道运维部里面具体有谁，也可以配置成直接将问题分配给比如小丽，也就是说，在配置数据库连接信息时，可以配置成直接连接SID，也可以配置成连接server_name，然后由server_name去调控SID去处理请求。

总结：

SID：

一个数据库可以有多个实例（如RAC集群环境），SID用来标识数据库内部每个实例的名字，就好像一个部门里，每个人都有一个自己的名字（小丽和小美等）。

SERVICE_NAME：

数据库对外宣称的名字，它就像一个部门的名字，这个部门的名称在数据库的看门大爷（listener）那里有登记。看门大爷一看你是要找SERVICE_NAME这个部门（运维部），就告诉你我们公司确实有这个部门，于是你就找到了，连接就建立了。

对于集群来说，每个节点的SID 是不一样的，但是SERVICE_NAME 可以包含所有节点。

一句话来说就是：

SID是对内部来说的，是实例级别的一个名字，用于数据库内部之间称呼。

SERVICE_是对外的，是数据库级别的一个名字，用来告诉外面的人，我数据库叫"SERVICE_NAME"。

这些易混淆的名字，你只要记住，他们不是指数据库，就是指实例，就这两个东西，别无其它。他们具体用哪个名字，要看针对对象。是对数据库，还是对操作系统，还是对外部连接请求。分清楚这点，就不容易混了

结尾：

     感谢阅读，祝有收获的一天，谢谢！