Oracle并发连接数的设置

不能连接Oracle数据库了 提示相关的错误

OERR: ORA TNS:no appropriate service handler found

客户端连接间歇性失败 报错ORA

Cause: the listener could not find any available service handlers that are

appropriate for the client connection

Action: run lsnrctl services to ensure that the instance(s) have registered

with the listener and are accepting connections 检查lsnrctl service instance已经注册

状态显示ready时 可以连接

When the listener believes the current number of connections has reached maximum load

it may set the state of the service handler for an instance to blocked and begin refusing

ining client connections with either of the following errors: ora or ora

采用服务动态注册的方式 由PMON 通过SERVICE_UPDATE 来得到目前连接情况 但SERVICE_UPDATE 有时间间隔

所以 listener显示的连接数和当前实际的连接数可能不同

查询解决方法:

查看一下数据库现有的进程数 是否已经达到参数processes的大小

select count(*) from v$process                         取得数据库目前的进程数

select value from v$parameter where name = processes 取得进程数的上限

如已达到上限 修改initSID ora中的processes的大小

重新启动数据库到nomount状态下 执行create spfile from pfile并startup open

查询数据库自启动以来最大的并发数量

修改最大连接数:

alter system set processes = scope = spfile

重启数据库:

shutdown immediate

startup

查看当前有哪些用户正在使用数据

SELECT osuser a username cpu_time/executions/ || s sql_fulltext machine

from v$session a v$sqlarea b

where a sql_address =b address order by cpu_time/executions desc

有的时候我们需要调整oracle数据库的最大链接数 而这个链接数的调整是在oacle下的dbs目录下init ora文件中调整的

ORACLE的连接数(sessions)与其参数文件中的进程数(process)有关 它们的关系如下

sessions=( *process+ )

但是我们增加process数时 往往数据库不能启动了 这因为我们还漏调了一个unix系统参数 它是核心参数中的semmns 这是unix系统的信号量参数 每个process会占用一个信号量 semmns调整后 需要重新启动unix *** 作系统 参数才能生效 不过它的大小会受制于硬件的内存或ORACLE SGA 范围可从 —— 不等

但是 Processes的修改不仅应该调整init<sid>ora文件中的参数 而且应该调整OS的内核参数 象AIX HPUX Solaris SCO UNIXWare都是这样 OS的调整是需要重新启动的 而且这个参数的设置不能简单按照多少个终端要连到这个服务器上而定 最关键是考虑会有多少同时连上的session（在使用一些共享连接的中间件时 一般就不需要太大） 当然还要考虑一些Oracle的后台进程 还有一些系统维护工作需要多一些连接等

我的atmp大前置机器上对oracle调整的时候 其使用的是unixware *** 作系统 在做链接数调整的时候 要先对核心参数进行调整

核心主要相关的参数的调整如下

SHMMAX   

SHMMIN   

SHMMNI   

SHMSEG   

SEMMNI   

SEMMSL   

SEMMNS   

SEMOPM   

其中semmni semmns semmsl要加大 至少要比processes大

SEMMNI（ ） 指定在核心中信号识别的数量 这是可以在任意给定时间被激活的唯一信号设置数量 缺省值是 最大值由系统自动调整产生

SEMMSL（ ） 指定每个信号识别中信号量的最大值 缺省值是

SEMMNS 除最大db外的所有db 的PROCESSES之和+ *最大db的PROCESSES+ *

实例数 如 个实例进程数分别为 则=（ + ）+ * + * =

tyle= LINE HEIGHT: %FONT FAMILY: 宋体 >SEMOPM（ ） 指定在每个系统调用semop中能够被执行的信号 *** 作量的最大值 缺省值是

SHMMAX（ ） 指定了共享内存部分大小的最大值 等于

× 物理内存字节数

SHMMNI（ ） 指定了系统范围内共享内存标识的最大值

SHMSEG（ ） 指定了与每个进程相关连的共享内存块（或标识）的数量 缺省值是 与每个进程相关连的共享内存块的最大值与进程拥有的未使用空间有关 因此 尽管一个进程拥有少于SHMSEG数值的共享内存块 它也有可能因为其有限的空间而不能与其它进程相联系

init ora中调整为

processes =                                            # SMALL

#processes =                                             # MEDIUM

# processes =                                             # LARGE

From:! FE F A F! entry

修改oracle 的最大连接数

使用sys 以sysdba权限登录

c: sqlplus /nolog

SQL>conn / as sysdba

SQL>show parameter processes

NAME TYPE VALUE

aq_tm_processes integer

db_writer_processes integer

job_queue_processes integer

log_archive_max_processes integer

processes integer

SQL>alter system set processes= scope = spfile

系统已更改

SQL>show parameter processes

NAME TYPE VALUE

aq_tm_processes integer

db_writer_processes integer

job_queue_processes integer

log_archive_max_processes integer

processes integer

SQL>create pfile from spfile

文件已创建

lishixinzhi/Article/program/Oracle/201311/18790

查询数据库当前进程的连接数

select count(*) from v$process

查看数据库当前会话的连接数

elect count(*) from v$session

查看数据库的并发连接数

select count(*) from v$session where status= ACTIVE

查看当前数据库建立的会话情况

select sid serial# username program machine status from v$session

查询数据库允许的最大连接数

select value from v$parameter where name = processes

或者命令 show parameter processes

修改数据库允许的最大连接数

alter system set processes = scope = spfile

(需要重启数据库才能实现连接数的修改)

重启数据库

SQL>shutdown immediate

SQL>startup

查看当前有哪些用户正在使用数据

SQL>select osuser a username cpu_time/executions/ || s sql_fulltext machine

SQL>from v$session a v$sqlarea b

SQL>where a sql_address = b address

SQL>order by cpu_time/executions desc

备注 UNIX 个用户session对应一个 *** 作系统process 而Windows体现在线程

启动oracle

su oracle

SQL>sqlplus system/pwd as sysdba     //进入sql

SQL>startup                                      //启动数据库

SQL>lsnrctl start                               //启动监听

sqlplus /as sysdba

SQL>shutdown immediate  //关闭数据库

SQL>startup mount

lishixinzhi/Article/program/Oracle/201311/18867

MySQL数据库的默认最大连接数是：100，

对于多人开发的单体项目来说，虽然我们同时在用的连接不会超过10个，理论上100 绰绰有余，但是除了我们正在使用的连接以外，还有很大一部分 Sleep 的连接，这个才是真正的罪魁祸首。

分析到了问题的根源，我们就需要对症下药，依次解决：

修改MySQL最大连接数量

首先查看当前 Mysql 最大连接数量是多少：

show variableslike'%max_connections%'

这里我已经修改过了，所以是 1000，没有改过的童鞋应该还是 100，

然后查看从这次 mysql 服务启动到现在，同一时刻并行连接数的最大值：

show statuslike'Max_used_connections'

对于 MySQL 的最大连接数设置，在首次配置的时候设置一个较大的数值，以后在使用的过程中，周期的查询 Max_used_connections 然后根据他的值和服务器的性能确定一个最适合当前项目的最大连接数

最大连接数的修改有两种方式

使用 sql 语句(立即生效，但服务器重启后失效)：

setglobalmax_connections = 1000

1修改 /etc/my.cnf.添加 max_connections = 1000 永久有效。重启后生效

但更改最大连接数只能从表面上解决问题，随着我们开发人员的增多，Sleep 连接也会更多，到时候万一又达到了 1000 的上限，难道我们又得改成 10000 吗？这显然是非常不可取的。所以我们不仅要治标，还要治本。杀掉多余的 Sleep 连接就是治本

杀掉Sleep连接

我们可以通过 show_processlist 命令来查看当前的所有连接状态

可以发现， Sleep 的连接占了绝大多数。

MySQL 数据库有一个属性 wait_timeout 就是 sleep 连接最大存活时间，默认是 28800 s，换算成小时就是 8 小时，我的天呐！这也太长了！严重影响性能。相当于今天上班以来所有建立过而未关闭的连接都不会被清理。

执行命令：

showglobalvariableslike'%wait_timeout'

我们将他修改成一个合适的值，这里我改成了 250s。当然也可以在配置文件中修改，添加 wait_timeout = 250。这个值可以根据项目的需要进行修改，以 s 为单位。我在这里结合 navicat 的超时请求机制配置了 240s。

执行命令：

setglobalwait_timeout=250

---