专用服务器模式（MTS）和共享服务器模式

转载

小麦苗123 2021-04-17 21:47:41

专用服务器模式（MTS）和共享服务器模式

连接ORACLE服务器一般有两种方式：专用服务器连接（dedicated server）和共享服务器连接（shared server）。那么两者有啥区别和不同呢？下面我们将对这两者的区别与不同一一剖析。

专用服务器模式（dedicated server）模式

在专用服务器模式中，用户进程运行在客户端的机器上，专用服务器进程运行在数据库服务器，用户进程和专用服务器进程是两种不同类型的进程。

对于专用服务器模式，在用户登录时，ORACLE总会创建一个新的服务进程，这通常称为专用服务器配置。这个服务器进程会在会话生存期中专门为这个连接服务。对于每一个会话，都会生成一个新的专用服务器进程，会话与专用服务器进程之间存在一对一的映射关系。按照定义，这个专用服务器不是实例的一部分。用户进程（也就是想要连接数据库的程序）会通过某种网络通道（如TCP/IP Socket）与这个专用服务器进程直接通信，并由这个服务器进程接收和执行用户进程提交的SQL。用户进程与专用服务器进程是一一对应关系。默认使用专用模式

专用服务器模式（dedicated server）的一个很重要的特点就是UGA(用户全局域)是存储在PGA(进程全局域)中的，这个特性也很好说明了当前用户的内存空间是按照进程来进行分配的。

专用服务器模式适用场景：

1：只有少量的客户端连接系统或数据仓库系统。数据集市系统等

2：联机事务处理系统（OLTP）。当然联机事务处理系统必须要符合下面两个条件

A 用户连接请求数大于共享进程

B 事务大部分是长事务或者大事务

共享服务器模式（shared server）

共享服务器（shared server），正式的说法是多线程服务器（Multi-Threaded Server）或MTS。如果采用这种连接方式，就不会对每条用户连接创建另外的线程或新的进程。在连接建立的时候，Listener首先接收到客户端的建立连接的请求，然后Listener去生成一个叫做调度器(dipatcher)的进程与客户端进行连接。调度器把把客户端的请求放在SGA(系统全局域)的一个请求队列中，然后在共享服务器连接池中查找有无空闲的连接，然后让这个空闲的服务器进程进行处理。处理完毕以后再把处理结果返回给用户。共享服务器模式的请求流程如下所示

利用共享服务器，我们不必为10,000 个数据库会话创建10,000 个专用服务器（这样进程或线程就太多了），而只需建立很少的一部分进程/线程，顾名思义，这些进程/线程将由所有会话共享。这样Oracle 就能让更多的用户与数据库连接，否则很难连接更多用户。如果让我的机器管理10,000个进程，这个负载肯定会把它压垮，但是管理100 个或者1,000 个进程还是可以的。采用共享服务器模式，共享进程通常与数据库一同启动，使用ps命令可以看到这个进程。

数据库连接概述

共享服务器模式缺点：

采用专用服务器连接模式比采用共享服务器连接模式效率要高。因为ORACLE共享服务器方式也有诸多缺点。

1)共享服务器的代码路径比专用服务器长，所以它天生就比专用服务器慢。（这个观点来自David Dai博客）

2)存在人为死锁的可能，因为它是串行的，只要一个连接阻塞，则该服务器进程上的所有用户都被阻塞，并且极可能死锁。

3)存在独占事务的可能，因为如果一个会话的事务运行时间过长，它独占共享资源，其它用户只能等待，而专用服务器，每个客户端是一个会话。

4)共享服务器模式限制了某些数据库特性，例如：不能单独启动和关闭实例，不能进行介质恢复，不能使用Log Miner，并且SQL_TRACE没有意义(因为是共享而不是当前会话的)。共享服务服务器连接，会话的跟踪信息可能分布在不同的独立跟踪文件中，重建会话比较困难。除非必须要用共享模式，如系统负载太重或特定的性能，否则专用服务器是最佳选择。

共享服务器连接模式的优点在于服务器进程的数量可以得到控制，不大可能出现连接数过多而造成服务器内存崩溃。但是由于增加了复杂度以及请求相应的队列，可能性能上会有所下降。

MTS减少的内存实际上是专用服务器模式下每个用户连接到操作系统进程所需的内存，但它却使用SGA的Large_Pool来分配UGA，拆东墙补西墙，所减少的内存是很少的。如果用户会话的连接和断开很频繁，数据库进程的创建和删除的开销会非常大，这种情况最好采用共享服务器模式(否则，应该使用连接池技术)。如果客户端一次连接终身使用(会话生命周期内)，使用共享服务器模式的意义不大。因为大部分时间，一个会话就连接到一个服务器进程，无法共享服务器进程。

判断数据库使用的连接模式

1：查看V$SESSION视图

SQL> select distinct server from v$session;

SERVER

---------

DEDICATED

NONE

如果SERVER字段的值除了DEDICATED,还有NONE，则说明当前实例启动了共享服务器，并且SERVER为NONE的会话正使用共享服务器连接，同时，如果只显示有DEDICATED，则不能说明服务器就一定工作在专用服务器下面，此时也有可能启动了共享模式。只是目前连接到数据库的都是专用服务器模式。

2：通过参数shared_server判断

如果shared_server值为0，则表示数据库没有启动共享服务模式。这个参数是配置shared server必须的，而且只有这个参数是必须的。它指定了当实例启动的时候 shared server process 启动的数量，不要将这个参数设置得太大，否者启动数据库instance的时候就会花更多时间,ORACLE启动过后会根据负载来动态调整shared_servers

SQL> show parameter shared_server

NAME                                 TYPE                             VALUE

------------------------------------ -------------------------------- ------------------------------

max_shared_servers                   integer                          40

shared_server_sessions               integer

shared_servers                       integer                         1

SQL>

max_shared_servers：oracle在同一个时刻最大能够使用的shared server process.不要将这个参数设置小于shared_servers,如果动态修改shared_servers大于max_shared_servers，oracle会覆盖max_shared_servers的值，此时你需要修改max_shared_servers.同时也不能大于processes。这个参数是为了给占用很大资源操作而设的(批处理)，为了预留一些process 给DBA任务(rman备份)，

shared_server_sesions: 指定了总共允许的的shared server session 的数量。如果设置了这个参数，那么就不要将这个值超过sessions，如果没有设置这个值，那么只要还有空闲的session,就可以被使用。设置这个值是为专用连接预留的User Sessions.

3：通过lsnrctl services区分。

启用了共享服务器模式，可以通过调度器(dipatcher)的进程区分确认。

[oracle@DB-Server ~]$ lsnrctl services;

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 06-JAN-2015 23:46:30

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.16.22)(PORT=1521)))

Services Summary...

Service "EPPS" has 2 instance(s).

  Instance "EPPS", status UNKNOWN, has 1 handler(s) for this service...

    Handler(s):

      "DEDICATED" established:0 refused:0

         LOCAL SERVER

  Instance "EPPS", status READY, has 8 handler(s) for this service...

    Handler(s):

      "D006" established:0 refused:0 current:0 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=10895))

      "D005" established:0 refused:0 current:0 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=2469))

      "D004" established:0 refused:0 current:0 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=13008))

      "D003" established:0 refused:0 current:0 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=17578))

      "D002" established:2 refused:0 current:1 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=44614))

      "D001" established:2 refused:0 current:1 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=32323))

      "D000" established:1 refused:0 current:1 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=22216))

      "DEDICATED" established:0 refused:0 state:ready

         LOCAL SERVER

Service "EPPS_XPT" has 1 instance(s).

  Instance "EPPS", status READY, has 8 handler(s) for this service...

    Handler(s):

      "D006" established:0 refused:0 current:0 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=10895))

      "D005" established:0 refused:0 current:0 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=2469))

      "D004" established:0 refused:0 current:0 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=13008))

      "D003" established:0 refused:0 current:0 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=17578))

      "D002" established:2 refused:0 current:1 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=44614))

      "D001" established:2 refused:0 current:1 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=32323))

      "D000" established:1 refused:0 current:1 max:1022 state:blocked

         DISPATCHER

         (ADDRESS=(PROTOCOL=tcp)(HOST=DB-Server.localhost.localdomain)(PORT=22216))

      "DEDICATED" established:0 refused:0 state:ready

         LOCAL SERVER

没有启用共享服务器模式，则不会有调度器(dipatcher)的进程

[oracle@DB-Server ~]$ lsnrctl services;

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 06-JAN-2015 23:56:25

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.16.22)(PORT=1521)))

Services Summary...

Service "EPPS" has 1 instance(s).

  Instance "EPPS", status UNKNOWN, has 1 handler(s) for this service...

    Handler(s):

      "DEDICATED" established:0 refused:0

         LOCAL SERVER

The command completed successfully

其他一些不能完全确认的判断方式。

select * from v$shared_server; ---有记录，且STATUS字段为WAIT(COMMON)，则说明启动共享；

---status为TERMINATED或者无记录，则说明没有启动共享服务器

select * from v$dispatcher; ---有无记录都不能说明启动共享服务器，只能说明是配置了dispatchers参数

select * from v$circuit ; ---有记录说明当前有使用共享模式的连接，无记录则不能判定服务器模式

关闭数据库共享模式

只需要将参数shared_servers设置为0，即可关闭数据库的共享模式。执行该脚本后，所有以共享方式连接到数据库都不能成功，但是未释放的共享连接会继续保持连接，直到断开为止。

alter system set shared_servers=0;

如果同时将参数shared_servers和max_shared_servers都设置为0，那么共享连接方式将被终结。所有的共享方式连接都会断开（已经连接的会话也会断开）

SQL> show parameter shared_servers

NAME                                 TYPE                             VALUE

------------------------------------ -------------------------------- --------

max_shared_servers                   integer                          40

shared_servers                       integer                          4

SQL> alter system set shared_servers=0 scope=both;

System altered.

SQL> alter system set max_shared_servers=0 scope=both;

System altered.

开启数据库共享模式

默认情况下，数据库都是专用服务器模式，如何开启共享服务器模式呢？一般只需要设置shared_servers这个参数，将其值设置为大于0即可开启服务器共享模式。其他的共享服务器参数可以不用设置，但是最好也设置一下max_shared_servers参数

SQL> alter system set shared_servers=1 scope=both;

System altered.

SQL> alter system set max_shared_servers =24 scope=both;

System altered.

但是在实际测试情况中发现，参数dispatchers也会影响到数据库开启共享服务器模式，如下所示，将参数dispatchers设置为空，shared_servers设置为1

SQL> show parameter shared

NAME                                 TYPE                             VALUE

------------------------------------ -------------------------------- --------

hi_shared_memory_address             integer                          0

max_shared_servers                   integer                          0

shared_memory_address                integer                          0

shared_pool_reserved_size            big integer                      26843545

shared_pool_size                     big integer                      0

shared_server_sessions               integer

shared_servers                       integer                          0

SQL> alter system set dispatchers='' scope=both;

System altered.

SQL> alter system set shared_servers=1 scope=both;

System altered.

SQL>

此时以共享连接方式方式连接数据库会遭遇“ORA-12523: TNS: 监听程序无法找到适用于客户机连接的例程"错误。设置参数dispacthers后即可开启共享连接模式。如果参数dispacthers不为空，那么只要设置了参数shared_servers大于0即可。

SQL> alter system set dispatchers='(PROTOCOL=TCP)';

System altered.

结论：如果dispatches参数设置为空的话，不能启动共享服务器。

关于参数dispatchers的设置，可以使用下面命令

alter system set dispatchers='(protocol=TCP)(disp=8)(serv=xxx)’

前面表示的是协议，disp表示调度器(dipatcher)的进程数量，service分别指定要采用共享服务器模式的服务名称。使用上面的模式指定只启动某个服务的共享模式，如果要设置所有服务都使用共享模式，则设置为：

alter system set dispatchers='(PROTOCOL=TCP)';

如何判断某个会话采用的那种连接方式呢？

1：查看V$SESSION视图

SELECT SID, USERNAME, OSUSER, MACHINE,TERMINAL, SERVER FROM V$SESSION WHERE USERNAME IS NOT NULL;

COL USERNAME FOR A20

COL OSUSER FOR A10

COL MACHINE FOR A20

COL TERMINAL FOR A20;

SELECT SID, USERNAME, OSUSER, MACHINE,TERMINAL, SERVER

FROM V$SESSION

USERNAME为NULL表示的是数据库后台进程，

2：查看连接数据库的tns配置文件，如下所示

1：以共享服务器模式连接数据库

TEST =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.16.22)(PORT = 1521))

    (CONNECT_DATA =

       (SERVER = SHARED)

      (SERVICE_NAME = epps)

2：以专用服务器模式连接数据库

TEST =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.16.22)(PORT = 1521))

    (CONNECT_DATA =

       (SERVER = DEDICATED)

      (SERVICE_NAME = epps)

TEST =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.16.22)(PORT = 1521))

    (CONNECT_DATA =

      (SERVICE_NAME = epps)

参考资料：

http://blog.csdn.net/tianlesoftware/article/details/5695784

http://wenku.baidu.com/view/9b0f7f8a84868762caaed57c.html

http://www.itpub.net/thread-1714191-1-1.html

ORACLE中STATUS为INACTIVE但是SERVER为SHARED状态的会话浅析

我们知道当ORACLE数据库启用共享服务器模式时，通过共享服务器模式连接到数据库的会话是有一些特征的。在v$session里面，其SERVER的状态一般为SHARED和NONE，为SHARED时，表示当前会话正在执行SQL语句，其占用共享服务器进程，会话的STATUS状态为ACTIVE；当会话状态STATUS处于INACITVE时，它的SERVER字段值一般为NONE，意味着此时并没有共享服务器进程服务该会话，这个详细请见v$session中server为none与shared值解析这篇博客。但是最近在一数据库中突然见到一些会话STATUS为INACTIVE，但是SERVER状态为SHARED的会话，如下所示：

其实发现这个问题是因为在追查一个TNS-12535的问题时发现的。当时突然出现短暂的数据库（Oracle 10g R2）连接不上的情况，nmon监控发现当时的整体资源开销都非常小，也分析过AWR、ASH报告，并没有发现很特殊的情况，但是在bdump下面发现shared server进程生成的trc文件。例如下面一个 epps_d004_24858.trc，截图所示:

在这篇博客”TNS-12535: TNS:operation timed out案例解析”里面我分析、构造过出现TNS-12535错误的场景。但是我们分析ASH报告和查询dba_hist_active_sess_history时发现出现问题的时间段，active会话的数量不超过4个。所以可以排除是这种情形。后面检查发现共享服务器模式的会话居然有STATUS为INACTIVE但是SERVER为SHARED状态的会话，而且数量较多，本身这台服务器的max_shared_servers参数为32，所以当大量INACTIVE会话一直占用shared server进程时，当ACITVE会话需要shared server服务进程时就会由于shared server进程不够而处于等待状态，时间长了就会出现TNS-12535错误。那么就有可能出现active session不多，但是连接不上数据库的这种情况。分析至此，那么就有两个问题需要解决：1 为什么INACTIVE的会话会占用shared server进程不释放？ 2 这个分析必须要经测试验证确认. 3:如何解决这个问题?

SQL> show parameter max_shared_servers;

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

max_shared_servers                   integer     32

SQL>

关于第一个问题，刚刚开始一直没有找到答案，后面才在oracle metalink上面找到了答案,官方文档High Number Of Shared Servers Usage In 10g When Compared To 9i (文档 ID 444950.1)里面有相关介绍，如下摘抄所示：

APPLIES TO:

Oracle Server - Enterprise Edition - Version: 9.2.0.1 to 10.2.0.3
This problem can occur on any platform.

SYMPTOMS

On 10g having a shared server configuration and seeing many sessions with "STATUS" "INACTIVE" but still these sessions are not releasing the shared server process.

When you query from V$SESSION

SQL>select sid,server,status FROM v$session WHERE SID='154';

SID SERVER STATUS
---------- --------- --------
154 SHARED INACTIVE

In 9i The shared server process is released.

SQL> select SID,Server,STATUS from V$Session where SID=10;

SID SERVER STATUS
---------- --------- --------
10 NONE INACTIVE

In 10g Since the sessions are not releasing the shared server processes, Number of shared server processes increases and will cause new connections to terminate with a message max limit(MAX_SHARED_SERVERS) for shared_servers exceeded.

If you trace the session then you will observe the following wait events.

WAIT #0: nam='virtual circuit status' ela= 30000256 circuit#=7 status=2 p3=0
obj#=-1 tim=745725456
*** 2006-11-28 14:46:43.906
WAIT #0: nam='virtual circuit status' ela= 30000250 circuit#=7 status=2 p3=0
obj#=-1 tim=775725785

CAUSE

When using WORKAREA_SIZE_POLICY=AUTO, In 10g for certain operations (Like SORT) SQL memory can intentionally spill into the PGA of the shared server rather than taking up space in shared memory. When data spills to the PGA the session has to stay tied to that specific shared server. And hence the Process in Inactive can still be holding a shared server until it is terminated.

SOLUTION

The behavior observed is expected in 10g when WORKAREA_SIZE_POLICY is set to automatic.

Use WORKAREA_SIZE_POLICY=MANUAL to prevent the SORT operation to spill over the PGA. This will make sure the session doesn't require any more shared server process and the SHARED_SERVER will be released by the process when it is in INACTIVE status.

BUG 5689608 can be referred for more information

REFERENCES

BUG:5689608 - INACTIVE SESSION IS NOT RELEASING SHARED SERVER PROCESS

当数据库参数WORKAREA_SIZE_POLICY = AUTO时，在10g中对于某些SQL操作（如SORT）所用的SQL内存，可能有意地放入（ spill over这里没有翻译为溢出）共享服务器的PGA当中，而不是占用共享内存（shared memroy）中的空间。当数据放入到PGA时，会话必须保持绑定到该特定的共享服务器（shared server）。因此，处于非活动状态的进程仍可以持有共享服务器，直到会话终止。

另外，解决方案里面也介绍，可以将参数WORKAREA_SIZE_POLICY设置为MANUAL，这样可以阻止排序操作将数据放入PGA当中。这个设定可以确保会话不会要求更多的共享服务器进程，并且当会话变成INACTIVE状态时，共享服务器很快就能释放。

那么第一个问题解决了，接下来我们来看第二个问题，后面我观察时，发现出现问题的时候，ACTIVE和INACTVIE的shared server数量等于32了. 那么我们接下来看看，如何构造这种状态的会话

在共享连接方式的会话1中执行下面SQL

SQL> show user;

USER is "TEST"

SQL> create table test as select * from dba_objects;

Table created.

SQL> create or replace package cursor_package as

  2  cursor mycursor is select * from test order by object_name;

  3  end;

  4  /

Package created.

SQL> begin

  2   open cursor_package.mycursor;

  3   end;

  4   /

PL/SQL procedure successfully completed.

SQL> create or replace procedure test_case is

  2  l_row TEST%rowtype;

  3  begin

  4  if cursor_package.mycursor%isopen then

  5  fetch cursor_package.mycursor into l_row;

  6  end if;

  7  end;

  8  /

Procedure created.

SQL> select sys_context('userenv', 'sid') from dual;

SYS_CONTEXT('USERENV','SID')

--------------------------------------------------------------------------------

如上所示，我们知道这个会话ID为932，此时开启另外一个会话2，查看会话ID为932的状态。如下所示

SQL> select sid, serial#, status ,server from v$session where sid=932;

       SID    SERIAL# STATUS   SERVER

---------- ---------- -------- ---------

       932         23 INACTIVE NONE

在会话1中执行下面SQL语句，如下截图所示：

SQL> exec test_case;

PL/SQL procedure successfully completed.

SQL>

然后去会话2中检查会话ID为932的状态，此时就会出现STATUS为INACTIVE，SERVER状态为SHARED的会话状态了。

关于如何解决这个问题，我们并没有将将参数WORKAREA_SIZE_POLICY设置为MANUAL，因为修改这个参数过后，需要调整sort_area_size,hash_area_size等参数. 在复杂环境下，一个固定值比较难满足各个时段的需求。这个数据库实例本身max_shared_server的值（32）比较小，我们将其调整为48，另外本身设置了一个crontab作业，定期清理那些空闲超过一段时间的INACTIVE会话。

参考资料：

High Number Of Shared Servers Usage In 10g When Compared To 9i (文档 ID 444950.1)

V$SESSION是基础信息视图，用于找寻用户SID或SADDR。不过，它也有一些列会动态的变化，可用于检查用户。在该视图中，每一个连接到数据库实例中的session都拥有一条记录，包括用户session及后台进程如DBWR，LGWR，arcchiver等等。
V$SESSION视图包含很多列，涉及到session信息、client信息以及application信息等。其中，server列信息表示该session的连接类型，也就是咱们常说的共享服务器连接或者专用服务器连接。那有没有其他服务器连接类型呢？下面我们就看一下Oracle11g官方文档中server列的几个取值：

DEDICATED
SHARED
PSEUDO
POOLED
NONE

其中，DEDICATED表示专用服务器连接，SHARED表示共享服务器连接，这两个大家较为熟悉；
PSEUDO和kill session相关，如果发出ALTER SYSTEM去终止session的会话，等待60秒后没有终止session，会收到一个信息表明session已标识为终止。被标记为终止的session在v$seession的status为KILLED，对应的server值可能为PSEUDO；
PO OLED和Oracle 11g推出的驻留连接池（Database Resident Connection Pool）特性相关，驻留连接池提供了数据库层面上的连接池管理机制，为应对高并发、短会话前端应用进行有益的尝试， PO OLED表示使用驻留连接池技术的连接；
NONE表示空闲的共享服务器连接。

About Me
...............................................................................................................................
● 本文整理自网络，大部分来源于潇湘隐者的博客
● 本文在itpub（http://blog.itpub.net/26736162）、博客园（http://www.cnblogs.com/lhrbest）和个人微信公众号（xiaomaimiaolhr）上有同步更新
● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/
● 本文博客园地址：http://www.cnblogs.com/lhrbest
● 本文pdf版及小麦苗云盘地址：http://blog.itpub.net/26736162/viewspace-1624453/
● 数据库笔试面试题库及解答：http://blog.itpub.net/26736162/viewspace-2134706/
● QQ群：230161599 微信群：私聊
● 联系我请加QQ好友(646634621)，注明添加缘由
● 于 2017-04-28 09:00 ~ 2017-04-30 22:00 在魔都完成
● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解
● 版权所有，欢迎分享本文，转载请保留出处
...............................................................................................................................
拿起手机使用微信客户端扫描下边的左边图片来关注小麦苗的微信公众号：xiaomaimiaolhr，扫描右边的二维码加入小麦苗的QQ群，学习最实用的数据库技术。