oracle连接数过多导致系统非常慢分析总结
Oracle大最插入数据一段时间之后变慢问题解决方法
Oracle⼤最插⼊数据⼀段时间之后变慢问题解决⽅法 因为系统业务需要，需要从数据中⼼导⼊12年的历史数据到系统。
每天平均1000千左右。
有⼀个表有200多个字段，基中还包括⼏个clob字段。
导⼊⽅式是⽤http向服务器⼀天⼀天的请求数据。
每次请求⼀天。
不能请求太多天，因为服务器请求太多天，有可能返回不了数据。
导致失败，Java的JDBC接⼝写⼊。
每次写数据都是⼀条⼀条的写⼊。
刚开始还算顺利，接⼝过来的数据都能写⼊进数据库。
但问题出现在写⼊1个⽉数据左右就开始慢慢的出现卡顿的情况。
写⼊⼀条记录的数据，有时10⼏秒，有⼏⼏分钟。
最坏的时候，就⼀条数据⼏个⼩时还没有写⼊成功，导致整个同步进程严重拥堵。
每次卡死之后，重启数据库服务⼜可以正常写⼊。
但每次写⼊⼀段时候之后，⼜卡死。
试过以下⽅法都不见效：1、停⽌所有的触发器2、接收数据表使⽤nologging表。
3、分次提交，⼀次不要只提交⼀条记录。
⼀次提交⼀天记录。
最后在⽹上找到了解决⽅法。
也是分次提交，但不是使⽤executeUpdate()执⾏，⽽是使⽤了先addBatch(), 再executeBatch()的⽅式。
具体见代码中的： public int executeBatch(String sql, List<Object[]> params) ⽅法。
附操作数据库的代码package bh.ojdbc.util;import java.sql.CallableStatement;import java.sql.Connection;import java.sql.DriverManager;import java.sql.PreparedStatement;import java.sql.ResultSet;import java.sql.ResultSetMetaData;import java.sql.SQLException;import java.util.ArrayList;import java.util.HashMap;import java.util.List;import java.util.Map;import org.apache.log4j.Logger;import bh.getjzdata.Para;import bh.util.SetRW;import bh.util.Tool;/*** 对jdbc的完整封装**/public class JDBCUtil {private static Logger logger = Logger.getLogger(JDBCUtil.class);private static String driver = null;private static String url = null;private static String username = null;private static String password = null;private CallableStatement callableStatement = null;//创建CallableStatement对象private Connection conn = null;private PreparedStatement pst = null;private ResultSet rst = null;/* static {try {// 加载数据库驱动程序Class.forName(driver);} catch (ClassNotFoundException e) {System.out.println("加载驱动错误");System.out.println(e.getMessage());}} */public JDBCUtil(){this.driver = Para.oracle_driver;this.url = Para.oracle_url;ername = Para.oracle_userid;this.password = Para.oracle_password;}public JDBCUtil(String driver,String url ,String username,String password) {this.driver = driver;this.url = url;ername = username;this.password = password;}/*** 建⽴数据库连接* @return 数据库连接*/public Connection getConnection() {try{if (this.conn!=null && !this.conn.isClosed()){return this.conn;}}catch(Exception e){}try {// 加载数据库驱动程序try {Class.forName(driver);} catch (ClassNotFoundException e) {System.out.println("加载驱动错误");System.out.println(e.getMessage());e.printStackTrace();logger.error(Tool.getExceptionDetail(e));}// 获取连接conn = DriverManager.getConnection(url, username,password);} catch (SQLException e) {System.out.println(e.getMessage());logger.error(Tool.getExceptionDetail(e));}return conn;}public int executeUpdate(String sql, Object[] params) {return executeUpdate(sql,params,true);}/*** insert update delete SQL语句的执⾏的统⼀⽅法* @param sql SQL语句* @param params 参数数组，若没有参数则为null* @return 受影响的⾏数*/public int executeUpdate(String sql, Object[] params,boolean isCloseAll) {// 受影响的⾏数int affectedLine = 0;try {// 获得连接conn = this.getConnection();if (!isCloseAll && conn.getAutoCommit()){conn.setAutoCommit(false);}// 调⽤SQLpst = conn.prepareStatement(sql);// 参数赋值if (params != null) {for (int i = 0; i < params.length; i++) {pst.setObject(i + 1, params[i]);}}/*在此 PreparedStatement 对象中执⾏ SQL 语句，该语句必须是⼀个 SQL 数据操作语⾔（Data Manipulation Language，DML）语句，⽐如 INSERT、UPDATE 或 DELETE语句；或者是⽆返回内容的 SQL 语句，⽐如 DDL 语句。
Oracle 查询慢的原因总结
Oracle查询慢的原因总结查询速度慢的原因很多，常见如下几种：1、没有索引或者没有用到索引（这是查询慢最常见的问题，是程序设计的缺陷）2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足5、网络速度慢6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）7、锁或者死锁（这也是查询慢最常见的问题，是程序设计的缺陷）8、sp_lock，sp_who，活动的用户查看，原因是读写竞争资源。
9、返回了不必要的行和列10、查询语句不好，没有优化可以通过如下方法来优化查询：1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。
数据量（尺寸）越大，提高I/O越重要。
2、纵向、横向分割表，减少表的尺寸（sp_spaceuse）3、升级硬件4、根据查询条件，建立索引，优化索引、优化访问方式，限制结果集的数据量。
注意填充因子要适当（最好是使用默认值0）。
索引应该尽量小，使用字节数小的列建索引好（参照索引的创建），不要对有限的几个值的字段建单一索引如性别字段5、提高网速；6、扩大服务器的内存，Windows 2000和SQL server 2000能支持4-8G的内存。
配臵虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配臵。
运行 Microsoft SQL Server？ 2000 时，可考虑将虚拟内存大小设臵为计算机中安装的物理内存的 1.5 倍。
如果另外安装了全文检索功能，并打算运行Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配臵为至少是计算机中安装的物理内存的 3 倍。
将 SQL Server max server memory 服务器配臵选项配臵为物理内存的 1.5 倍（虚拟内存大小设臵的一半）。
7、增加服务器 CPU个数；但是必须明白并行处理串行处理更需要资源例如内存。
oracle性能分析报告
Oracle性能分析报告1. 引言Oracle是一种高效的关系数据库管理系统，但在使用过程中可能会遇到性能问题。
本文将介绍如何通过分析Oracle性能来识别并解决潜在的问题。
2. 数据收集要进行性能分析，首先需要收集相关数据。
以下是一些常用的数据收集方法：- 监视系统参数：使用Oracle自带的工具，如AWR报告和ASH报告，可以监视系统参数的变化和性能指标。
- 分析SQL语句：通过跟踪和分析执行时间较长的SQL 语句，可以找到性能瓶颈所在。
- 监视数据库等待事件：通过查看等待事件的情况，可以了解系统的瓶颈。
- 监视资源利用率：监视CPU、内存和磁盘等资源的利用率，以了解系统的健康状况。
3. 数据分析收集到数据后，需要对数据进行分析以识别性能问题。
以下是一些常用的数据分析方法： - 比较不同时间段的性能指标：通过比较不同时间段的性能指标，可以发现系统的变化和趋势。
- 查找长时间运行的SQL语句：通过识别执行时间较长的SQL语句，可以找到潜在的性能问题。
- 分析等待事件：通过查看数据库等待事件的情况，可以确定系统的瓶颈所在。
- 分析资源利用率：通过监视资源利用率，可以确定系统是否存在资源瓶颈。
4. 性能优化通过数据分析，可以确定性能问题的原因。
以下是一些常用的性能优化方法：- 优化SQL查询：对执行时间较长的SQL语句进行优化，如增加索引、重写查询等。
- 调整系统参数：根据系统的需求，调整相关的系统参数，如缓冲区大小、并发连接数等。
- 优化存储结构：对表的存储结构进行优化，如分区、索引等。
- 调整硬件配置：根据系统的需求，调整硬件配置，如增加CPU、内存等。
5. 总结通过以上的步骤，可以对Oracle数据库的性能进行分析和优化。
收集相关数据、分析数据、识别问题、优化性能是一个迭代的过程，需要不断调整和优化。
只有对Oracle性能进行持续监测和优化，才能确保系统的高效运行。
以上是关于Oracle性能分析报告的步骤和方法的介绍。
Oracle 系统性能变慢常规处理诊断及定位处理方法
PROMO_ID NOT NULL NUMBER
QUANTITY_SOLD NOT NULL NUMBER(10,2)
AMOUNT_SOLD NOT NULL NUMBER(10,2)
SQL> select
2 tenth tenth,
PROD_ID NOT NULL NUMBER
CUST_ID NOT NULL NUMBER
TIME_ID NOT NULL DATE
--分区表
select a.owner ,segment_name,a.partition_name , a.bytes , a.blocks ,b.blocks ,
a.blocks / b.blocks from dba_segments a , dba_tab_partitions b
3 min(PROD_ID) low_val,
4 max(PROD_ID) high_val,
5 max(PROD_ID) - min(PROD_ID) width,
2、
a、查询操作系统进程、DB SID和SQL语句，锁等待的语句
select * from v$sql where address in
(select sql_address
from v$session a
where paddr In
( select addr from v$process where spid
15 ;
TENTH LOW_VAL HIGH_VAL WIDTH HEIGHT
---------- ---------- ---------- ---------- ----------
oracle连接速度慢经验
oracle连接速度慢经验
很多程序开发人员在开发的过程中，经常会发现在很多人使用oracle数据库的时候，会出现连接不上，或者很卡，经常断，下面介绍一个方法，可以缓解这个问题。
下面是店铺收集整理的oracle连接速度慢经验，希望对大家有帮助~~
oracle连接速度慢经验
工具/原料
oracle数据库
windows等版本系统
方法/步骤
很多软件开发人员用plsql登陆数据库的时候常常会遇上这样的情况，很多时候信息都是正确的，但是就是连接不上，如下图所示：下面介绍一个方法解决该问题，首先打开你的电脑，找到如下图所示的文件：
邮件点击hosts文件，选择用文本编辑器打开，如下图所示：
打开hosts文件，会出现如下图所示的文件，记得不要去随意改它，如下图所示：
在文本的最后面，添加进去你的oracle数据库的ip地址及主机名，如下图所示，保存后即可，会发现访问变得流畅了。
6这个方法的原理是，根据tcp，ip协议的标准，添加一个映射关系。
oracle连接。
oracle运行变慢如何办
Tablespace 的IO reads/writes也没有异常, 但是wait明显增加.
初步确定是IO问题.
第四步, 察看OS的信息
1. top 命令（输出为实验室数据，仅作格式参考）
load averages: 0.05, 0.10, 0.09 10:18:32
在buffer busy waits等待事件中
P1 = file#
P2 = block#
P3 = id ( 此id对应为等待的原因)
按照p1,p2,p3 group是为了明确buffer busy waits的等待集中在哪些对象上。
Metalink对buffer busy waits等待事件的描述有如下一段话：
输出结果显示最多的等待事件是buffer busy waits。
进一步分析，找出等待的原因
Select count(*), p1, p2, p3 from v$session_wait where event = ‘buffer busy waits’ group by p1,p2,p3;
“If P3 shows that the "buffer busy wait" is waiting for a block read to complete then the blocking session is likely to be waiting on an IO wait (eg: "db file sequential read" or "db file scattered read" for the same file# and block#.”
Oracle数据库性能优化分析
千里之行，始于足下。
Oracle数据库性能优化分析Oracle数据库性能优化分析是指对Oracle数据库进行综合性能分析和优化的过程。
通过分析数据库的运行状况、识别潜在的性能瓶颈、确定解决方案并实施优化措施，可以提高数据库的性能和效率。
以下是Oracle数据库性能优化分析的一般步骤：1. 收集性能数据：通过Oracle的性能监控工具，如AWR报告、统计信息收集等，收集数据库的性能数据，包括CPU利用率、I/O响应时间、锁定情况等。
2. 确定性能瓶颈：通过分析性能数据，确定数据库中存在的性能瓶颈，如高CPU使用率、高IO等待、长时间的锁等待等。
3. 优化SQL语句：分析执行频次较高的SQL语句，通过重写SQL语句、调整索引和统计信息等方式，优化SQL语句的执行计划，减少IO开销和CPU消耗。
4. 优化数据库结构：根据应用的需求和查询模式，调整表结构、分区策略、索引设计等，以提高查询性能和数据访问效率。
5. 优化数据库配置参数：调整数据库的配置参数，包括缓冲区大小、日志大小、并发连接数等，以最大限度地利用硬件资源，提高数据库的吞吐量和响应时间。
6. 确保数据完整性和一致性：通过使用合适的约束和触发器，确保数据的完整性和一致性，防止数据错误和冲突对性能造成负面影响。
第1页/共2页锲而不舍，金石可镂。
7. 监控和调优：定期监控数据库的性能指标，如响应时间、吞吐量等，及时识别和解决潜在的性能问题，保持数据库的高可用性和性能稳定性。
需要注意的是，性能优化是一个综合性的工作，需要结合具体的应用场景和需求来进行分析和优化，没有一种通用的解决方案，需要根据实际情况进行定制化的优化措施。
同时，性能优化是一个持续改进的过程，需要定期评估数据库的性能状况，并根据需求进行调整和优化。
oracle浅析导致数据库性能问题的常见原因
oracle浅析导致数据库性能问题的常见原因
㈠不合理的⼤表全表扫描
v$session_longops视图记录了超过6秒的所有SQL语句
这其中绝⼤部是全表扫描的语句！
㈡语句共享性不好
常出没在OLTP，由于app没有合理使⽤绑定变量，导致⼤量重复的语句Parse，浪费⼤量的shared pool，使CPU利⽤率居⾼不下㈢过量的排序操作
有个原则：能不排序就不排序
特别是multi-pass，与事务设计、缺乏索引、优化器的选择等均有关系
㈣⼤量递归SQL语句
由sys执⾏，以⼤量的空间管理sql语句为甚
常见于⼤数据处理
作为DBA，⼤数据处理前，主动进⾏存储空间的分配
㈤优化器和统计信息
代码有时候，在测试环境能跑，到了⽣产环境就“萎”了
这是因为，⽣产环境没有及时采集统计信息，导致Oracle优化器不了解最新的数据和应⽤情况，⽽错误地选择了⾮优化的执⾏路径所以，我们需及时采集统计信息，保证基于CBO的优化器能欢快运⾏
㈥不合理的参数设置
系统参数⼀定要调，还要合理地调
主要是些内存参数、进程参数等
㈦存储部署不合理
由于存储部署不合理导致I/O效率低下
处理⽅案：ASM、RAID10等
㈧频繁的数据库连接操作
主要是C/S结构⽐较常见，⼏乎绝迹于B/S了
㈨ Redo Log 设计不合理
Redo log⽂件设计太⼩，频繁触发checkpoint事件，导致内存紧张和I/O繁忙
Redo log⽂件⽂件组太少，则可能使归档⽆法赶上redo entries产⽣的速度。
ORACLE最大连接数满常见问题
oracle 11g 大量废连接占满数据库连接问题处理
问题描述：
数据库不断出现大量无用连接，超过数据库最大连接数，导致新的连接无法建立，访问不通数据库
问题分析：
服务器netstat连接数，大量连接来自办公网连接，不断在增加，通过服务器spid查看数据库对应的sid，查看session会话，点击pl/sql 工具菜单，选择会话，选择所有会话，查看到sid对应的事务是pl/sql.exe为pl/sql客户端连接，关闭所有技术人员的pl/sql客户端，依然不释放连接，原因是技术人员使用pl/sql出现非主动关闭，如网络异常断开，断电等导致关闭客户端连接也不释放
SQL> show parameter processes #最大连接
SQL> alter system set processes = value scope = spf—————————————
在 oracle中，要经常查看process:
查看ORACLE最大进程数：
SQL> select count(*) from v$session #连接数
SQL> Select count(*) from v$session where status='ACTIVE' #并发连接数
论Oracle数据库的性能优化问题
论Oracle数据库的性能优化问题Oracle数据库是一款流行的企业级数据库软件，但其性能优化问题也是不可避免的。
在实际应用中，如果Oracle数据库出现性能问题，将有严重的影响和损失。
因此，本文将讨论如何优化Oracle数据库的性能问题。
首先，针对Oracle数据库的性能瓶颈，可以通过调整数据库参数来提高性能。
Oracle数据库有很多参数可以配置，例如，缓存区大小、连接数、内存分配等。
通过针对不同的应用场景调整不同的参数配置，可以最大化地利用数据库的性能。
其次，针对SQL的性能问题，可以通过改进SQL语句来提高性能。
SQL优化是一项复杂的工作，但可以通过分析SQL执行计划来发现性能瓶颈，例如，缺乏索引、大表连接、高开销的子查询等。
并可以通过添加索引、优化查询语句等方式来提高数据库的性能。
除此之外，还可以通过加强硬件设备等方面来提升数据库性能。
例如，扩展数据库服务器的内存和硬盘容量，可以提高数据库的读写速度。
而使用高速网络设备如IB网络和10/100G以太网设备等，也可提高数据库的数据传输速度。
此外，Oracle数据库的性能优化也需要管理进程的支持与配合。
例如，数据库管理员需要监控数据库服务器硬件和软件性能，例如Oracle数据库的内部锁、等待事件、I/O活动等等。
在监控到性能问题后，需要在业务空档期进行优化，如调整SQL语句、更改数据库参数等。
总之，提高Oracle数据库的性能需要全面考虑软硬件配置、SQL语句等多个方面的因素。
通过合理的参数配置、SQL优化和硬件支持等方式，可以优化数据库的性能，提高应用的稳定性和响应速度。
Oracle超出最大连接数问题及解决
pga_aggregate_target=720M
# processes、sessions是扩大并发连接数，是同时使用。
# 公式： sessions = processes *1.1 +5
processes=600
sessions=665
2、在监听参数文件LISTENER.ORA 文件中增加参数
direct_handoff_ttc_listener = off
3、重新启动数据库服务。
B.修改windows配置
1、修改Windows系统中Boot.ini文件
/3GB /PAE
说明：修改操作系统中Boot.ini文件，可以使Oracle使用更多的内存空间。
2、修改用户组策略中锁定内存页大小权限。
后来查到有可能是oracle 10g for win32的一个bug，上网下了补丁，打完补丁后的版本是:10.2.0.3；也曾怀疑是不是windows 2003的tcp连接数不够,上网查说好像是有这毛病,下了个2003的补丁,把tcp连接数扩到了1000,结果能够达到可以有250个并发连接,但是再多就又连不上了。
设置的最大连接数（默认值为150）select value from v$parameter where name = ‘processes’;
修改最大连接数alter system set processes = 300 scope = spfile;
都知道，当数据库最大连接数不够时会出现客户端连接间歇性失败，报错ORA-12519。设置大点一般就可以了。但是做大型项目的时候还是会遇到一些不正常的问题，比如：设置最大连接数800，但是正常连接200多个就会报错，这也是我在一次面试中得知的。回来因为自己的垃圾机器上没有装Oracle，就查了些资料，发现还真的有这个问题，不过不是什么难题，貌似很多人遇到过，看来我们真的做项目太少了吧，顶多同时测试的也就十多个人。
ORACLE数据库变得非常慢解决方案一例
ORACLE数据库变得非常慢解决方案一例数据库变得非常慢[/b][/b]接到客户报告最近数据库速度慢了好多,同样的应用慢了4,5倍.我做了个statspack,没发现什么问题,主要信息:Cache Sizes (end)~~~~~~~~~~~~~~~~~Buffer Cache: 3,104M Std Block Size:8KShared Pool Size: 400M Log Buffer:3,072KLoad Profile~~~~~~~~~~~~ Per Second Per Transaction--------------- ---------------Redo size: 394,918.91 68,578.62Logical reads: 40,718.26 7,070.82Block changes: 3,516.66 610.68Physical reads: 1,673.37 290.59Physical writes: 63.58 11.04User calls: 122.83 21.33Parses: 22.04 3.83Hard parses: 2.23 0.39Sorts: 10.36 1.80Logons: 0.38 0.07Executes: 54.35 9.44Transactions: 5.76% Blocks changed per Read: 8.64 Recursive Call %: 46.61Rollback per transaction %: 0.00 Rows per Sort: 1601.81Instance Efficiency Percentages (Target 100%)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: 99.99 Redo NoWait %: 100.00Buffer Hit %: 95.91 In-memory Sort %: 99.99Library Hit %: 98.08 Soft Parse %: 89.90Execute to Parse %: 59.45 Latch Hit %: 99.88Parse CPU to Parse Elapsd %: % Non-Parse CPU:Shared Pool Statistics Begin EndMemory Usage %: 86.59 86.84% SQL with executions>1: 88.19 88.59% Memory for SQL w/exec>1: 94.34 94.96Top 5 Timed Events~~~~~~~~~~~~~~~~~~ % TotalEvent Waits Time (s) Ela Time-------------------------------------------- ------------ ----------- -------- db file scattered read 585,373 5,110 36.24latch free 38,146 3,331 23.63db file sequential read 328,881 2,096 14.87PX Deq: Txn Recovery Start 645 1,124 7.97db file parallel write 3,840 754 5.35****************************AIX系统:***********************************#iostat 5 5tty: tin tout avg-cpu: % user % sys % idle % iowait0.0 2.5 16.4 2.8 69.7 11.1Disks: % tm_act Kbps tps Kb_read Kb_wrtnhdisk0 20.9 141.9 33.0 1176852937 1037907344hdisk1 20.4 136.6 31.3 1136554209 996356546hdisk2 12.6 140.3 56.6 702195893 1487895240hdisk3 10.6 249.1 39.5 1887071251 2001871356cd0 0.0 0.0 0.0 0 0tty: tin tout avg-cpu: % user % sys % idle % iowait0.0 339.4 22.1 6.6 19.0 52.4Disks: % tm_act Kbps tps Kb_read Kb_wrtnhdisk0 95.6 615.2 152.0 2112 964hdisk1 96.0 612.0 150.8 2156 904hdisk2 83.0 2470.4 226.4 11524 828hdisk3 7.0 60.0 12.6 300 0cd0 0.0 0.0 0.0 0 0tty: tin tout avg-cpu: % user % sys % idle % iowait0.0 460.4 31.3 7.7 13.1 47.9Disks: % tm_act Kbps tps Kb_read Kb_wrtnhdisk0 95.4 648.0 158.4 1844 1396hdisk1 98.4 679.2 163.4 1896 1500hdisk2 89.6 2595.2 260.2 12088 888hdisk3 5.8 44.8 10.2 212 12cd0 0.0 0.0 0.0 0 0tty: tin tout avg-cpu: % user % sys % idle % iowait0.0 364.5 21.9 7.4 14.9 55.9Disks: % tm_act Kbps tps Kb_read Kb_wrtnhdisk0 96.6 750.9 177.9 1152 2604hdisk1 95.2 773.3 177.7 1176 2692hdisk2 70.2 2002.5 205.1 9740 276hdisk3 5.0 132.8 8.4 152 512cd0 0.0 0.0 0.0 0 0************FZYC1/#sar 5 5AIX FZYC1 3 4 000177DF4C00 06/06/0610:15:40 %usr %sys %wio %idle10:15:45 15 2 63 1910:15:50 19 3 56 2210:15:55 22 5 54 2010:16:00 20 10 51 2010:16:05 25 9 51 15Average 20 6 55 19******************FZYC1/#ps -ef |pgUID PID PPID C STIME TTY TIME CMDroot 1 0 0 Dec 07 - 29:33 /etc/initroot 4158 1 0 Dec 07 - 0:00 /usr/lib/methods/ssa_daemon -lssa0root 4446 11096 0 Dec 07 - 182:03 /usr/dt/bin/dtsessionroot 5014 1 0 Dec 07 - 1577:46 /usr/sbin/syncd 10root 5958 10322 0 Dec 07 - 24:57 /usr/lpp/X11/bin/X -x abx -x dbe -x GLX -D /usr/lib/X11//rgb -T -force :0 -auth /var/dt/A:0-aWkfiaroot 10322 1 0 Dec 07 - 0:01 /usr/dt/bin/dtlogin -daemonroot 10610 1 0 Dec 07 - 0:00 /usr/lib/errdemonroot 10926 4446 0 Dec 07 - 0:00 /usr/dt/bin/dttermroot 11096 10322 0 Dec 07 - 0:00 dtlogin -daemonroot 11364 17626 0 Dec 07 pts/0 0:00 /bin/kshroot 11620 1 0 Dec 07 - 0:00 imqsmdem imqsrv.ini /etc/IMNSearch/dbcshelp/...我发现iowait太高了,怀疑是这个系统同步进程root 5014 1 0 Dec 07 - 1577:46 /usr/sbin/syncd 10照成的,aix系统不怎么熟,会不会是这个照成数据库变慢呢? 要不要喀嚓掉它?我怀疑不是数据库的问题,因为应用没什么变化,定期维护也有做.问题情况简要叙述:客户报告数据库越来越慢,业务快无法进行了,近期并没有上什么新的应用和大的改变. 收集信息:statspack 发现top5等待首位为db scatter readaix topas 和iostat 发现iowait 严重,超过50% busy保持90%分析:查询top sql,v$sesstat+v$statname发现awms 应用进程db session logical reads等磁盘读写严重awms应用为实时查询(很频繁),查询sql的执行路径为,主要sql为对一些基表进行全表扫描.基表数据量不大(5-8w)左右,理论上查询io并不应该太髙.进一步查发现,该表dml较多,照成表不断扩大,碎片增多,对该表的full scan代价越来越大.仅仅凭112m的大小并不会照成太严重的io,但是该表被用于实查询,并且由于是full scan,在查询完成后会被至到LRU列表的least used 端.因此照成频繁的读写.内存不够用,引起了过多的swap.(这里为推测的原因,并不能肯定是正确的)解决:把表重建(truncate掉重插数据,或者move表然后重建索引),这些基表不大,并且频繁使用,由于这些特性,所以将其keep到buffer中--alter table table_namestorage (buffer_pool keep)观察了些时间,数据性能恢复了./archiver/tid-248860.html小记：不明原因的解决了ORACLE慢的问题近来发现ORACLE服务器超级慢，而且慢并不是由应用程序性能导致的，就连运行proc 预编译程序都很慢，可见问题还是出在ORACLE服务器本身。
oracle 查询慢的原因总结
查询速度慢的原因很多，常见如下几种：1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足5、网络速度慢6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列10、查询语句不好，没有优化可以通过如下方法来优化查询:1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。
数据量（尺寸）越大，提高I/O越重要.2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)3、升级硬件4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。
注意填充因子要适当（最好是使用默认值0）。
索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段5、提高网速;6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。
配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。
运行Microsoft SQL Server? 2000 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的 1.5 倍。
如果另外安装了全文检索功能，并打算运行Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。
将SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍（虚拟内存大小设置的一半）。
7、增加服务器CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。
使用并行还是串行程是MsSQL自动评估选择的。
Oracle连接数太多报错-ORA-12516错误
Oracle ORA-12516 错误解析(2007-05-09 17:20:51)转载分类：Oracle数据库五一期间，负责的内蒙项目的数据库连接的时候突然出现“ORA-12516: TNS: 监听程序找不到符合协议堆栈要求的可用处理程”的异常，很是郁闷！！可看看Tomcat还在正常连接着，可PL/SQL怎么着就登录不了，报这个异常，一时之间把我吓坏了，还以为数据库又出现什么问题了！！于是就赶紧去网上查查。
得到了一系列的答案，其中下面这个我还是比较认可的。
ORA-12516:TNS:监听程序无法找到匹配的信息栈的可用句柄错误ORA-12520:解决方法：查了一下，原来是以前设置共享服务器时SESSION设了170，PROCESSES设了150，共享服务器时就肯定够用，专用服务器就不行了，后来改为SESSION设555，PROCESSES设500。
重启数据库，正常了。
然后又马上再查了，PROCESSES已经达到140了，奇怪，不可能有这么多人，再查SESSION发现只有30多，想了一下，哦！原来是共享服务器SHARED_SERVER设了100，就将它改成了10。
解决方法：加大PROCESSES后来，我把数据库给停了，但并没有按照上面的说法去增加PROCESSES，重新启动之后，连接就正常了，个人认为是访问量达到了设置的最大限，不过上面的解决方法是可以解决的，并且也比较彻底。
如果大家以后再遇到这种问题，可以尝试着把PROCESSES放大来解决这个问题！！ORA-12516错误的处理分类：数据库Oracle技术2007-06-08 11:47 5734人阅读评论(1) 收藏举报解决过程：1、查看当前会话数、processes和sessions值，发现session数和2个参数的值已经非常逼近SQL*Plus: Release 10.2.0.1.0- Production on星期一 10月915:50:21 2006Copyright (c) 1982, 2005, Oracle. All rights reserv ed.SQL> conn /as sysdba已连接。
ORACLE数据库变得非常慢解决方案一例
ORACLE数据库变得非常慢解决方案一例最近在为一个项目做数据库优化，发现ORACLE数据库运行得特别慢，简直让人头大。
今天就来给大家分享一下我是如何一步步解决这个问题的，希望对你们有所帮助。
事情是这样的，那天老板突然过来，一脸焦虑地说：“小王，你看看这个数据库，查询速度怎么这么慢？客户都投诉了！”我二话不说，立刻开始分析原因。
我打开了数据库的监控工具，发现CPU和内存的使用率都很高，看来是数据库的压力确实很大。
然后，我开始查看慢查询日志，发现了很多执行时间很长的SQL语句。
这时，我意识到，问题的根源可能就在这些SQL语句上。
一、分析SQL语句1.对执行时间长的SQL语句进行优化。
我检查了这些SQL语句的写法，发现很多地方可以优化。
比如，有些地方使用了子查询，我尝试将其改为连接查询，以提高查询效率。
2.检查索引。
我发现有些表上没有合适的索引，导致查询速度变慢。
于是，我添加了合适的索引，以提高查询速度。
3.调整SQL语句的顺序。
有些SQL语句的执行顺序不当，导致查询速度变慢。
我调整了这些语句的顺序，使其更加合理。
二、调整数据库参数1.增加缓存。
我发现数据库的缓存设置比较低，导致查询时需要频繁读取磁盘。
我适当增加了缓存大小，以提高查询速度。
2.调整线程数。
我发现数据库的线程数设置较低，无法充分利用CPU资源。
我将线程数调整为合适的值，以提高数据库的处理能力。
3.优化数据库配置。
我对数据库的配置文件进行了调整，比如调整了日志文件的存储路径和大小，以及调整了数据库的备份策略等。
三、检查硬件资源1.检查CPU。
我查看了CPU的使用情况，发现CPU负载较高。
我建议公司采购更强大的CPU，以提高数据库的处理能力。
2.检查内存。
我发现内存的使用率也很高，于是建议公司增加内存容量。
3.检查磁盘。
我检查了磁盘的读写速度，发现磁盘的I/O性能较低。
我建议公司更换更快的磁盘，以提高数据库的读写速度。
四、定期维护1.定期清理数据库。
Oracle SQL执行缓慢的原因以及解决方案
Oracle SQL执行缓慢的原因以及解决方案
Oracle SQL执行缓慢的原因的分析，如果Oracle数据库中的某张表的相关数据已是2亿多时，同时此表也创建了相关的4个独立的相关索引。
由于业务方面的需要，每天需分两次向此表中插入300万条记录。
由于数据量大，每次插入耗时3个小时以上，严重影响效率。
因此，修改了系统的算法，将此表中只存储当天新增记录。
将此表truncate后，第二天执行对此表的update操作时，非常耗时。
表中有2亿多条数据的时候，此Oracle sql语句耗时59秒；表中有300万条数据的时候，此Oracle sql语句耗时几个小时。
咨询DBA后，得出结论，需重建索引。
重建后，6秒完成此操作。
但第三天问题依然出现。
DBA正在查找原因。
难道每次truncate表，都需要重建索引？
对于这个问题，DBA也没有给出合理的解释，推测主要原因是Oracle复杂的查询优化算法。
最终，DBA给出的解决方案：
1.truncate table ....
2.drop index.....
3.insert data .....
4.create index ...
5.analyze table table_name compute statistics;
重新生成统计数据
调整后，整个操作耗时非常少。
Oracle 查询慢的原因总结
Oracle查询慢的原因总结查询速度慢的原因很多，常见如下几种：1、没有索引或者没有用到索引（这是查询慢最常见的问题，是程序设计的缺陷）2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足5、网络速度慢6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）7、锁或者死锁（这也是查询慢最常见的问题，是程序设计的缺陷）8、sp_lock，sp_who，活动的用户查看，原因是读写竞争资源。
9、返回了不必要的行和列10、查询语句不好，没有优化可以通过如下方法来优化查询：1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。
数据量（尺寸）越大，提高I/O越重要。
2、纵向、横向分割表，减少表的尺寸（sp_spaceuse）3、升级硬件4、根据查询条件，建立索引，优化索引、优化访问方式，限制结果集的数据量。
注意填充因子要适当（最好是使用默认值0）。
索引应该尽量小，使用字节数小的列建索引好（参照索引的创建），不要对有限的几个值的字段建单一索引如性别字段5、提高网速；6、扩大服务器的内存，Windows 2000和SQL server 2000能支持4-8G的内存。
配臵虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配臵。
运行 Microsoft SQL Server？ 2000 时，可考虑将虚拟内存大小设臵为计算机中安装的物理内存的 1.5 倍。
如果另外安装了全文检索功能，并打算运行Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配臵为至少是计算机中安装的物理内存的 3 倍。
将 SQL Server max server memory 服务器配臵选项配臵为物理内存的 1.5 倍（虚拟内存大小设臵的一半）。
7、增加服务器 CPU个数；但是必须明白并行处理串行处理更需要资源例如内存。
oracle RAC集群后速度变慢处理
症状：OLAP上执行的程序连到RAC后，比原来单机的时候慢了。
测试方法:1.对一张大表全表扫描和建新表，比较RAC和单机上的速度，如果两者速度差不多，则排除RAC问题，因为RAC是新上的。
如果这一步测出RAC没问题，则继续下一步测试。
2.清空OLAP的db buffer cache，在OLAP上通过dblink访问单机和RAC，比较两者的速度，判断问题是否出在网络上。
在执行第1步时就判断出问题出在RAC上，RAC上全表扫描比单机慢很多。
如下：单实例查询大表的效率：SQL> select /*+ full(cu_customer) */ count(*) from customer_temp; COUNT(*)----------2434230Elapsed: 00:00:00.73 --sql执行时间都是取的多次执行后的时间。
测试RAC查询大表的效率：SQL> select /*+ full(cu_customer) */ count(*) from customer_temp; COUNT(*)----------2434230Elapsed: 00:00:02.97RAC比单实例慢了2秒多，而且RAC一直跑不进2秒内。
既然问题出在RAC上，现在RAC上所有东西都是值得怀疑的，如何定位问题呢？采取了以下方法：1.节点1删除RAC集群，重装了oracle软件，把库的rman备份恢复到了节点1的本地硬盘上，在这个节点上以上sql速度很快，排除节点1硬件问题。
2.把盘柜格式化成ext3，在节点2上dd测试本地硬盘和盘柜的速度，都正常，排除节点1和盘柜硬件问题。
3.节点2重装oracle软件，在节点2上把库的rman备份恢复到了盘柜上，sql速度也很快，所以节点2服务器、盘柜IO、各种驱动、光纤都是没有问题的。
4.在节点2重装了一个单节点的RAC，再测试同一张表，速度又下来了，所以问题应该出在asm上。
Oracle在HPUXIA64平台登陆缓慢问题分析
Oracle在HPUXIA64平台登陆缓慢问题分析今年以来，在某客户现场遇到了2次HPUX IA64平台11g及12c 某些版本登陆速度缓慢的问题(包含本地及远程sqlplus/jdbc登陆都慢)，经过大量测试分析，最终确定Oracle的某些PSU存在缺陷，导致在HPUX IA64平台上登陆时间大幅增加。
具体的版本如下：1、11.2.0.4PSU20181016，本地sqlplus登陆300-400ms,同比11.2.0.4.8以下版本不到100ms，11.2.0.1则不到10ms;2、12.2.0.1PSU20180417，本地sqlplus登陆500ms-1s，同比12.2.0.1PSU20180129以下版本大约100ms。
问题描述对某厂商生产系统核心库深度巡检中，发现在类似的登陆频度下，11g和12c的登陆消耗差距巨大：11.2.0.4.8版本库：12.2.0.1PSU20180417：可以看到12c登陆消耗的DB TIME高达48%,为11g的400倍，消耗时间为3423s,为11g的122倍！问题分析按前面的脚本分别测试sqlplus本地连接，11g小于30ms，12c 为400ms，差距10倍以上。
11.2.0.4.8:12.2.0.1PSU2018106:登陆连接分析通过在Oracle MOS上开SR，给出如下跟踪建议：1. 创建针对dbatest用户的logon trigger，自动产生10046（测试完毕以后，请删除这个trigger< drop trigger sqlldr_logon >）。
•••••••CREATE OR REPLACE TRIGGER sqlldr_logonAFTER LOGON ON DBATEST.SCHEMABEGINexecute immediate 'alter session set tracefile_identifier="sqlldr"';execute immediate 'alter session set events ''10046 trace name context forever, level 12''';END;/2. 开启net trace••••••••••••••••••••Action Plan==========1). Please add the following into clientmachine,sqlnet.oraTRACE_LEVEL_CLIENT=16TRACE_DIRECTORY_ CLIENT=/tempTRACE_TIMESTAMP_CLIENT=TRUEDIAG_ADR_EN ABLED=off2).In server sqlnet.ora,add the following items.==========--Add to a srever SQLNET.ORA file==========NAMES.DIRECTORY_PATH= (TNSNAMES)TRACE_TIMESTAMP_SERVER=TRUEDIAG_ADR_ENA BLED=offTRACE_LEVEL_SERVER = 16TRACE_TIMESTAMP_CLIENT = ONTRACE_DIRECTORY_SERVER = /temp/nettrace==========3). --Add the following in listener.oraDIAG_ADR_ENABLED_LISTENER = OFF3. 服务器端测试••$rm /tmp/12.log$ /usr/local/bin/tusc -aepo /temp/12.log -T %H:%M:%S sqlplus dbatest/dbatest@ORADBClient net trc可以看出08:04:11.899客户端发起连接：但是Server端08:04:12.127才开始接收请求，延迟0.22ms,说明不少时间消耗在OS层面的处理上面：分析tusc的文件，发现2个系统调用消耗绝大多数时间：a.sigtimedwait调用超时36次，消耗391msb.登陆成功前read系统调用消耗437ms而检查登陆正常的11g及12c版本库，发现没有sigtimedwait系统调用，read系统调用在10ms左右！4.版本测试尝试打上最新的PSU20190716，故障现象依旧。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Tue Jan 19 10:52:49 2010
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn5
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
19-JAN-2010 10:32:38 * (CONNECT_DATA=(SID=ora9jsy)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.2.1)(PORT=1076)) * establish * ora9jsy * 0
19-JAN-2010 10:32:39 * (CONNECT_DATA=(SID=ora9jsy)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.2.1)(PORT=1077)) * establish * ora9jsy * 0
TNS-12500: TNS:listener failed to start a dedicated server process
TNS-12540: TNS:internal limit restriction exceeded
TNS-12560: TNS:protocol adapter erroห้องสมุดไป่ตู้
TNS-00510: Internal limit restriction exceeded
通过检查listener.log时发现2010-1-19号0点到14点43分之间，个别时间段192.168.2.1这个ip地址每隔几秒就会建立一个连接，总共有300多个连接数，而正常时192.168.2.1这个ip只有1-2个连接数，可以看出这次连接数增多是由这个ip不断连接引起的。
Tue Jan 19 10:57:04 2010
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn5
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
2 数据库环境
2.1 数据库系统
版本 环境 数据库名 实例名 IP地址 所在主机
9.2.0.8 单机 ora9 ora9 xxxxx P570a
3 故障分析
当时通过同事查连接数，LOCAL=NO的进程连接数已经达到990,而正常时只有100-150左右，查询alert.log时发现1.19号有以下报错
4 总结及建议
建议用户检查192.168.2.1这个中间件应用服务器，看有什么异常导致连接数突然增多，目前用户数大概100-150左右，分配给数据库使用的物理内存已经够用，如果以后业务发展连接数达到1000以上，可以分配更多的物理内存给数据库使用。
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
19-JAN-2010 10:33:34 * (CONNECT_DATA=(SID=ora9jsy)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.2.1)(PORT=1125)) * establish * ora9jsy * 0
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
通过查询文档，表示进程不能启动或者创建
depinfo = 11,：is the o/s errno [EACCES] error may indicate the requested file is not available which may be an effect that the process did not start and hence its proc entries were not created.
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
Tue Jan 19 11:12:04 2010
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
oracle 连接数过多导致系统非常慢分析总结
个人分类：数据库维护
1 问题描述
2010年1月19日，客户数据库外面客户端无法连接，这时系统非常慢，连操作系统命令ls显示也出不来,然后通过杀掉进程，重启中间件应用服务器，重启数据库后，数据库恢复正常。
现把本次数据库故障分析过程总结如下。
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
19-JAN-2010 10:33:33 * (CONNECT_DATA=(SID=ora9jsy)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.2.1)(PORT=1124)) * establish * ora9jsy * 0
19-JAN-2010 10:32:38 * (CONNECT_DATA=(SID=ora9jsy)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.2.1)(PORT=1074)) * establish * ora9jsy * 0
Tue Jan 19 10:50:49 2010
skgpspawn failed:category = 27142, depinfo = 17, p = fork, loc = skgpspawn5
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
skgpspawn failed:category = 27142, depinfo = 11, p = fork, loc = skgpspawn3
查询listener.log时从2010-1-19下午14:43时开始报TNS-12540错误,超出内存限制，外面客户端无法再连接进来。
19-JAN-2010 14:43:36 * (CONNECT_DATA=(SID=ora9jsy)(CID=(PROGRAM=oracle)(HOST=wfzyk)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.40.30.236)(PORT=48365)) * establish * ora9jsy * 12500
19-JAN-2010 10:33:42 * (CONNECT_DATA=(SID=ora9jsy)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.2.1)(PORT=1135)) * establish * ora9jsy * 0