不能连接Oracle数据库了 提示相关的错误
创新互联专业IDC数据服务器托管提供商，专业提供成都服务器托管，服务器租用，珉田数据中心，珉田数据中心，成都多线服务器托管等服务器托管服务。
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的修改不仅应该调整initsid 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
SQLconn / 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
Redo log 是用于恢复和一个高级特性的重要数据 一个redo条目包含了相应操作导致的数据库变化的所有信息 所有redo条目最终都要被写入redo文件中去 Redo log buffer是为了避免Redo文件IO导致性能瓶颈而在sga中分配出的一块内存 一个redo条目首先在用户内存(PGA)中产生 然后由oracle服务进程拷贝到log buffer中 当满足一定条件时 再由LGWR进程写入redo文件 由于log buffer是一块 共享 内存 为了避免冲突 它是受到redo allocation latch保护的 每个服务进程需要先获取到该latch才能分配redo buffer 因此在高并发且数据修改频繁的oltp系统中 我们通常可以观察到redo allocation latch的等待 Redo写入redo buffer的整个过程如下
在PGA中生产Redo Enrey 服务进程获取Redo Copy latch(存在多个 CPU_COUNT* ) 服务进程获取redo allocation latch(仅 个) 分配log buffer 释放redo allocation latch 将Redo Entry写入Log Buffer 释放Redo Copy latch;
shared strand
为了减少redo allocation latch等待 在oracle 中 引入了log buffer的并行机制 其基本原理就是 将log buffer划分为多个小的buffer 这些小的buffer被成为strand(为了和之后出现的private strand区别 它们被称之为shared strand) 每一个strand受到一个单独redo allocation latch的保护 多个shared strand的出现 使原来序列化的redo buffer分配变成了并行的过程 从而减少了redo allocation latch等待
shared strand的初始数据量是由参数log_paralleli *** 控制的;在 g中 该参数成为隐含参数 并新增参数_log_paralleli *** _max控制shared strand的最大数量;_log_paralleli *** _dynamic则控制是否允许shared strand数量在_log_paralleli *** 和_log_paralleli *** _max之间动态变化
HELLODBA select nam ksppinm val KSPPSTVL nam ksppdesc from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm LIKE _% AND upper(nam ksppinm) LIKE %LOG_PARALLE% ; KSPPINM KSPPSTVL KSPPDESC _log_paralleli *** Number of log buffer strands _log_paralleli *** _max Maximum number of log buffer strands _log_paralleli *** _dynamic TRUE Enable dynamic strands
每一个shared strand的大小 = log_buffer/(shared strand数量) strand信息可以由表x$kcrfstrand查到(包含shared strand和后面介绍的private strand g以后存在)
HELLODBA select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != ; INDX STRAND_SIZE_KCRFA HELLODBA show parameter log_buffer NAME TYPE VALUE log_buffer integer
关于shared strand的数量设置 个cpu之内最大默认为 当系统中存在redo allocation latch等待时 每增加 个cpu可以考虑增加 个strand 最大不应该超过 并且_log_paralleli *** _max不允许大于cpu_count
注意 在 g中 参数_log_paralleli *** 被取消 shared strand数量由_log_paralleli *** _max _log_paralleli *** _dynamic和cpu_count控制
Private strand
为了进一步降低redo buffer冲突 在 g中引入了新的strand机制——Private strand Private strand不是从log buffer中划分的 而是在shared pool中分配的一块内存空间
HELLODBA select * from V$sgastat where name like %strand% ;POOL NAME BYTES shared pool private strands HELLODBA select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa = ;INDX STRAND_SIZE_KCRFA
Private strand的引入为Oracle的Redo/Undo机制带来很大的变化 每一个Private strand受到一个单独的redo allocation latch保护 每个Private strand作为 私有的 strand只会服务于一个活动事务 获取到了Private strand的用户事务不是在PGA中而是在Private strand生成Redo 当flush private strand或者mit时 Private strand被批量写入log文件中 如果新事务申请不到Private strand的redo allocation latch 则会继续遵循旧的redo buffer机制 申请写入shared strand中 事务是否使用Private strand 可以由x$ktcxb的字段ktcxbflg的新增的第 位鉴定
HELLODBA select decode(bitand(ktcxbflg ) ) used_private_strand count(*) from x$ktcxb where bitand(ksspaflg ) != and bitand(ktcxbflg ) != group by bitand(ktcxbflg );USED_PRIVATE_STRAND COUNT(*)
对于使用Private strand的事务 无需先申请Redo Copy Latch 也无需申请Shared Strand的redo allocation latch 而是flush或mit是批量写入磁盘 因此减少了Redo Copy Latch和redo allocation latch申请/释放次数 也减少了这些latch的等待 从而降低了CPU的负荷 过程如下
事务开始 申请Private strand的redo allocation latch (申请失败则申请Shared Strand的redo allocation latch) 在Private strand中生产Redo Enrey Flush/Commit 申请Redo Copy Latch 服务进程将Redo Entry批量写入Log File 释放Redo Copy Latch 释放Private strand的redo allocation latch
注意 对于未能获取到Private strand的redo allocation latch的事务 在事务结束前 即使已经有其它事务释放了Private strand 也不会再申请Private strand了
每个Private strand的大小为 K g中 shared pool中的Private strands的大小就是活跃会话数乘以 K 而 g中 在shared pool中需要为每个Private strand额外分配 k的管理空间 即 数量* k
g:SQL select * from V$sgastat where name like %strand% ;POOL NAME BYTES shared pool private strands HELLODBA select trunc(value * KSPPSTVL / ) * * from (select value from v$parameter where name = transactions ) a (select val KSPPSTVL from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_paralleli *** _mul ) b;TRUNC(VALUE*KSPPSTVL/ )* * g:HELLODBA select * from V$sgastat where name like %strand% ;POOL NAME BYTES shared pool private strands HELLODBA select trunc(value * KSPPSTVL / ) * ( + ) * from (select value from v$parameter where name = transactions ) a (select val KSPPSTVL from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_paralleli *** _mul ) b;TRUNC(VALUE*KSPPSTVL/ )*( + )*
Private strand的数量受到 个方面的影响 logfile的大小和活跃事务数量
参数_log_private_mul指定了使用多少logfile空间预分配给Private strand 默认为 我们可以根据当前logfile的大小(要除去预分配给log buffer的空间)计算出这一约束条件下能够预分配多少个Private strand
HELLODBA select bytes from v$log where status = CURRENT ;BYTES HELLODBA select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))* (select to_number(val KSPPSTVL) from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_mul ) / / ) as calculated private strands from dual;calculated private strands HELLODBA select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;actual private strands
当logfile切换后(和checkpoint一样 切换之前必须要将所有Private strand的内容flush到logfile中 因此我们在alert log中可能会发现日志切换信息之前会有这样的信息 Private strand flush not plete 这是可以被忽略的) 会重新根据切换后的logfile的大小计算对Private strand的限制
HELLODBA alter system switch logfile;System altered HELLODBA select bytes from v$log where status = CURRENT ;BYTES HELLODBA select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))* (select to_number(val KSPPSTVL) from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_mul ) / / ) as calculated private strands from dual;calculated private strands HELLODBA select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;actual private strands
参数_log_private_paralleli *** _mul用于推算活跃事务数量在最大事务数量中的百分比 默认为 Private strand的数量不能大于活跃事务的数量
HELLODBA show parameter transactionsNAME TYPE VALUE transactions integer transactions_per_rollback_segment integer HELLODBA select trunc((select to_number(value) from v$parameter where name = transactions ) * (select to_number(val KSPPSTVL) from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_paralleli *** _mul ) / ) as calculated private strands from dual;calculated private strands HELLODBA select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;actual private strands
注 在预分配Private strand时 会选择上述 个条件限制下最小一个数量 但相应的shared pool的内存分配和redo allocation latch的数量是按照活跃事务数预分配的
lishixinzhi/Article/program/Oracle/201311/17848
oracle增大并发写入最简单的方法是使用SQL_TRACE对其进行跟踪。您没有提到Oracle版本,版本或平台。因此,我假设您至少使用的是10gR2版本。因此,使用DBMS_MONITOR来开...1. oracle的数据模式是:用户建在表空间上,表建在用户上
2. 一个用户的表就象自己的私有财产一样,没有自己或管理员授权别的用户是不能查询或修改的;
3. 对于不同用户下的同名表,都是独立的数据对象,如user1.table1和user2.table1是相互独立的,用户分别操作自己的表是不影响其他用户的;
