柔中带刚，刚中带柔，淫荡中富含柔和，刚猛中荡漾风骚，无坚不摧，无孔不入！
全部博文（1669）
分类： Oracle
2011-12-05 11:43:50
问题情况：
系统在使用办理过程中出现慢、卡现象，打开处理延缓4-5秒
相关情况：
1． 用户数量：4400用户
2． 数据量：180G
3． 网络：内网
4． 服务器：1台应用服务器+1台数据库服务器+1台备份服务器
5． 中间件：weblogic6.1 SP4
6． 数据库：oracle 10.2.0.4
应用服务器性能情况：
应用服务器网络线路速度：网络应用中的数据传输比较大
weblogic设置：
。。。。。。
"%JAVA_HOME%binjava" -hotspot -ms1024m -mx1024m -classpath "%CLASSPATH%" -Dweblogic.Domain=mydomain -Dweblogic.ThreadPoolSize=500
。。。。。。
weblogic监控情况：
数据库服务器网络应用联网情况：网络应用数据传输较大
oracle参数设置：
。。。。。。
processes = 800
__shared_pool_size = 805306368
__large_pool_size = 16777216
__java_pool_size = 16777216
__streams_pool_size = 0
sga_target = 1610612736
db_block_size = 8192
__db_cache_size = 754974720
db_file_multiblock_read_count= 16
db_recovery_file_dest_size= 21474836480
job_queue_processes = 10
open_cursors = 5000
pga_aggregate_target = 847249408
。。。。。。
思考：
如何从系统整体角度优化调整
计划：
重建索引使用独立表空间
重建索引使用独立表空间的效果并不理想，问题未得到实质解决，在相同的RAID中使用独立表空间不会有效果，如果从索引方面考虑，索引重建在不同的RAID中的表空间、索引表空间的block块使用16K以上可以有效果。
考虑评估主要有几个方面：
程序代码、服务器性能、网络传输、应用配置、数据库配置
程序代码一直使用还是正常，数据量增长影响程序运行？可能性较小
应用配置和数据库配置已经较优了
剩下就是服务器性能和网络传输了
数据库服务器是新的，问题可能性较小；
应用服务器倒是很值得怀疑，应用服务器使用有5年了，配置：Intel® Xeon™ 3.00GHz 2.99GHz，4G内存，而且机房环境较差，灰尘大。
数据量的增大对应用服务器的性能造成了影响和可能性较大，但也无法证明这种推断。
网络传输，只是100M的交换机，也具有提升的空间。
仔细回想了一下，是在数据迁移使用新数据库服务器之前的2010年1月管理员就已经反馈速度有点影响了，当时注意力都集中在数据库服务器上，当时数据库服务器使用的是32位的windows操作系统，当时理解为32位操作系统的影响，认为使用64位的操作系统可以让速度得到改善，现在回想一下，或许当初已经是数据量增大影响了应用服务器的性能，只是当初并没有意识到，
当然，当初考虑整体的方案的时候也是存在疏漏，过多的考虑了数据库服务器，而没有想到应用服务器，道理是显而易见，数据量的增长必定对服务器的性能造成影响，包括数据库服务器和应用服务器，当时应该及时提出应用服务器的采购。
2010-04-28 继续调整
配置weblogic集群和代理，尝试分摊应用服务器的压力，使用了三个服务节点：myserver01、myserver02、myserver03,部署在三台服务器上，集群Mycluster,代理Proxyserver,管理服务admin
在访问的高峰期还是慢卡，问题并没有所改善，代理是可以分发访问，测试中还发现一个情况，如果直接访问指定IP的三个服务节点，速度是正常的，但如果通过80端口的代理进行访问则还是慢卡，很奇怪，会不会是80端口的并发请求太大了，影响了处理的速度？？，但代理所在的服务器也没出现CPU、内存的高使用
2010-04-30 处理总结
第一阶段：例行性调整(单服务器、单服务节点)
ThreadPoolSize：500调整为250
JDBC连接池：100/200调整为200/200
表现：空闲期系统很正常，高峰期系统慢、卡，达到15-20秒，高峰期数据库压力大，活动会话数大，容易出现长时间会话，应用服务器的CPU和内存压力并不大
推断：内网100M网络的问题，高峰期产生阻塞，或者应用服务的HTTP处理能力不足问题
第二阶段：分拆应用服务(使用三台应用服务器，配置weblogic集群，一个管理服务，一个代理服务(应用前端)，两个服务节点(应用后端))
ThreadPoolSize：管理服务(30)，代理服务(80)，节点服务(80)
JDBC连接池：30/60
表现：
表现：问题依旧，空闲期系统很正常，高峰期系统慢、卡，达到15-20秒，高峰期数据库正常，活动会话数正常，未出现长时间会话，应用服务器的CPU和内存压力并不大
高峰期时候，访问通过代理访问是慢、卡，但直接访问节点服务则速度很正常。
推断：排除内网网络问题，可能是由于前端应用的处理能力不足影响的问题，
操作系统“开始->运行->cmd”，输入“netstat /s”，在“TCP Statistics for IPv4”信息中，“Current Connections”显示的就是访问连接的总数，正常情况一般是200—400，高峰会达到500—600
第三阶段：调整优化前端应用的处理能力
ThreadPoolSize：代理服务由80调整为450，
socket reader：33调整为66
accept bocking：50调整为200
Thread Priority：5调整为3(线程优先级，值越小优先级越高)
表现：系统高峰期访问正常
总结：
1.可以通过windows的netstat /s观察访问连接情况
2.ThreadPoolSize可以设置大一点，虽然还不清楚它占用的是什么资源CPU？？内存？？
如果代理服务的ThreadPoolSize设小的话，它也不会全部用完，设置越小它使用的越少，设置越大，它使用越大
weblogic控制台的监控曲线也受ThreadPoolSize的影响，ThreadPoolSize小了，控制台的监控曲线也会卡
3.可以考虑socket reader和accept bocking参数的调整
4.JDBC的连接数初始值不能设太大，太大了容易消耗数据库资源，对数据库产生压力
5.单节点服务和集群代理多节点服务的设置考虑要区别对待
其实大并发访问量对HTTP服务处理能力有更高的要求，一般建议通过硬件分发处理，如F5分发控制
时间：2010-03-25
项目：B项目
情况：将数据文件从本地磁盘(E:)迁移到阵列磁盘柜(F:)
Microsoft Windows Server 2003 R2 SP1 Enterprise 32 Edition
oracle 9.2.0 oracle9.2.0.8补丁
处理总结：
1.创建init参数文件
C:Documents and SettingsAdministrator>sqlplus /nolog
SQL*Plus: Release 9.2.0.8.0 - Production on 星期四 3月 25 20:20:38 2010
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
SQL> connect sys/***@*** as sysdba
已连接。
SQL> create pfile from spfile;
文件已创建。
2.关闭数据库
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
3.文件转换目录
e:oracleoradataoanet*转移到F:oradataoranet
4.修改init参数文件中的控制文件路径
e:oracleora92databaseinitoanet.ora
5.使用init文件mount数据库
startup mount pfile='e:oracleora92databaseinitoanet.ora'
6.修改数据库中文件的路径
alter database rename file ‘原来文件1’,’ 原来文件2’ to ‘新的文件1’, ‘新的文件1’;(包括redo文件)
SQL> alter database rename file 'E:oracleoradataoanetCWMLITE01.DBF','E:orac
leoradataoanetDRSYS01.DBF','E:oracleoradataoanetEXAMPLE01.DBF','E:oracle
oradataoanetINDX01.DBF','E:oracleoradataoanetODM01.DBF','E:oracleoradat
aoanetREDO01.LOG','E:oracleoradataoanetREDO02.LOG','E:oracleoradataoane
tREDO03.LOG','E:oracleoradataoanetSYSTEM01.DBF','E:oracleoradataoanetTO
OLS01.DBF','E:oracleoradataoanetUSERS01.DBF','E:oracleoradataoanetXDB01.
DBF' to 'F:oradataoanetCWMLITE01.DBF','F:oradataoanetDRSYS01.DBF','F:orad
ataoanetEXAMPLE01.DBF','F:oradataoanetINDX01.DBF','F:oradataoanetODM01.D
BF','F:oradataoanetREDO01.LOG','F:oradataoanetREDO02.LOG','F:oradataoane
tREDO03.LOG','F:oradataoanetSYSTEM01.DBF','F:oradataoanetTOOLS01.DBF','F:
oradataoanetUSERS01.DBF','F:oradataoanetXDB01.DBF';
7.打开数据库，创建新spfile文件
alter database open;
create spfile from pfile;
注意：TEMP表空间不记录在控制文件中,删除原有temp表空间新建。
8.重启数据库
shutdown immediate
startup
数据迁移工作完成
时间：2010-03-12——14
项目：A项目
情况：数据库迁移，老的服务器硬件不稳定，新买了两台新服务器
工作计划：
1.2010-03-12早上安排一次巡检维护，并确认客户准备的服务器驱动；
2.2010-03-12 18:30关闭应用服务,暂停服务器上的exp备份计划，暂停已用数据库服务器的rmanfull任务计划，手动执行rmanfull备份，预计耗时4小时，22:30结束
3.2010-03-12 18:30安装一台服务器，包括硬盘raid的划分、安装操作系统、安装驱动、安装oracle、创建数据库、创建表空间。预计23:00完成
4.2010-03-12 在安装好的新服务器上设置任务计划，23:30执行exp备份，预计耗时10小时，第二天9:30结束
5.2010-03-13 9:00检查exp备份情况，将数据导入新数据库，预计耗时10小时，19:00结束,重新分析表和索引预计耗时3小时，23:00结束
6.2010-03-13 20:30修改weblogic配置文件，使用新数据库，启动应用服务测试，预计23:30结束，23:30关闭应用服务
7.2010-03-13 23:30配置oracle数据库归档模式，执行rmanarch和rmanfull备份，预计耗时4小时，第二天4:30结束。
8.2010-03-14 9:30检查rmanfull备份情况，安装另一台服务器作为备份、备用服务器，包括硬盘raid的划分、安装操作系统、安装驱动、安装oracle、创建数据库。预计12:30完成
9.2010-03-14 15:00设置数据备份方案，启用应用服务。整个迁移工作完成。
10.2010-03-15 早上检查exp备份情况，检查系统运行情况。
处理总结：
整个数据迁移工作顺利完成
数据量：170G
安装操作系统：Microsoft Windows Server 2003 R2 SP2 Enterprise X64 Edition
安装数据库：oracle 10.2.0.4WIN-x86-64 p6810189_10204_MSWIN-x86-64补丁
1.磁盘RAID配置
正式服务器：RAID10，只能使用总容量的1/2
备份、备用服务器：RAID50，可以使用总容量的3/4
2.exp导出和expdp导出
前面使用过expdp导出，120G的数据耗时3小时，但考虑到expdp只能导到本地，还需要网络传输的时间，这次考虑exp导出。
22：30开始，到了第二天10：30还没结束，查看“任务管理器”里面的联网信息，可以看到每个网卡的传输数据量
检查中CPU使用率较低，0%——1%，网络传输几乎没有，应该是数据传输已经断开了，已传输的数据有32G，线路速度是100M，留意到从墙壁的内网接口出来后还要经过一个H3C S1016交换机，这个交换机影响了exp的传输；
时间已经耗去，需要加快速度，考虑用回expdp方式，但开始之后又想到了一个问题，两台windows的服务器是没法设置共享的，expdp导出后也无法传输；
再考虑跳过交换机，使用直联线连接两台服务器，线路速度达到了1G，使用exp方式，170G的数据耗时3.5小时
结果：exp导出与expdp导出的速度跟线路速度有很大关系，所以在考虑传输数据或数据备份的时候，最好使用千兆线路速度(千兆网卡+千兆交换机或者直连线)，64位操作系统也有助于提高处理速度
