免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: 无风之谷

[WebLogic] 中间件WebLogic/Tuxedo/GoldenGate的排错与优化(获奖名单已公布) [复制链接]

论坛徽章:
0
发表于 2012-02-16 20:56 |显示全部楼层
Shell_HAT 发表于 2012-02-16 11:26
回复 47# zorrohu


1个小时几G?  {:2_167:}

晕子一个

论坛徽章:
1
技术图书徽章
日期:2014-07-11 16:30:58
发表于 2012-02-17 21:40 |显示全部楼层
本帖最后由 manULinux 于 2012-02-17 21:41 编辑

干了快3年了一值是前后台 文档一条龙。呵呵。

论坛徽章:
59
2015七夕节徽章
日期:2015-08-24 11:17:25ChinaUnix专家徽章
日期:2015-07-20 09:19:30每周论坛发贴之星
日期:2015-07-20 09:19:42ChinaUnix元老
日期:2015-07-20 11:04:38荣誉版主
日期:2015-07-20 11:05:19巳蛇
日期:2015-07-20 11:05:26CU十二周年纪念徽章
日期:2015-07-20 11:05:27IT运维版块每日发帖之星
日期:2015-07-20 11:05:34操作系统版块每日发帖之星
日期:2015-07-20 11:05:36程序设计版块每日发帖之星
日期:2015-07-20 11:05:40数据库技术版块每日发帖之星
日期:2015-07-20 11:05:432015年辞旧岁徽章
日期:2015-07-20 11:05:44
发表于 2012-02-17 21:54 |显示全部楼层
1、WebLogic内存溢出专题探讨

Weblogic内存遗漏,不外乎也就两种情况,一种是虚拟机内存参数设置不合理,造成Weblogic运行一段时候后内存分配不足,而造成内存遗漏的发生;第二种情况不外乎就是我们的程序写的不好,分配的内存没有及时的释放而造成内存泄漏情况的发生。
关于内存泄漏问题,我们一般会从应用程序出发,去审核代码,做到代码级的优化,然后再调整应用服务器(BEA WebLogic8.1)和数据库 (Oracle9i)的参数,最后当然是调整操作系统和网络的性能(包括硬件升级)。这是一种MDA的先进做法。
2、Goldengate数据迁移注意事项及常见问题

这个我没有做过,暂时不知道。
3、Tuxedo中IPC相关故障探讨

1. 非图形界面下的安装
./tuxedo81_aix_32bit.bin -i console 加入 -i console则不需要图形支持

2.察看版本和patch信息
$TUXDIR/bin/tmadmin -v

3.对ubb文件只做语法检查(不真正的load成TUXCONFIG 真正tmloadcf -y)
tmloadcf -n ubb  

4.tmboot/tmshutdown中的几个参数介绍
-A 只启动/停止Tuxedo管理服务,如BBL
-S 所有服务被启动/停止
-g grpname 只启动/停止属于制定组名的服务
-i svrid 只启动/停止制定ServID的服务
-s svrname 只启动/停止制定服务名的服务

5. tuxedo有关域(domain)管理的命令
$ dmadmin
>pd -d LocalTUXDomainID 显示与本地域关联的其他域
>co -d LocalTUXDomainID -R RemoteDomainID 手动连接远程域

6.如何清除IPC资源
如果你不想用tmshutdown停止或者当$TUXCONFIG文件被误删除而无法shutdown TUXEDO服务时,可以尝试直接删除当前用户的ipc资源,如下:
ipcs | grep `logname` | awk '{print "ipcrm -"$1,$2}' |sh -x

7.反编译tuxconfig 生成 ubb文件
a) tmunloadcf 查看当前TUXCONFIG中的ubb内容
b) export TUXCONFIG=`pwd`/tuxconfig 比较简单的设置TUXCONFIG的命令

8.Tuxedo非正常状态下的关闭
1) 执行tmshutdown -y,如果shutdown不成功,转入下一步(此时一般来说,TUXEDO的状态已经处于
不正常了)。
2)执行tmipcrm -y,如果shutdown不成功,转入下一步。
3)要用到AWK,所以要求在Unix下,或者在WINDOWS下装了Cygwin。
3)执行ipcrm `ipcs|grep $USER|awk '{print " -"$1" "$2}'`。
执行了3)肯定就可以关闭掉了。
一般情况下,我也懒得那么麻烦,在非生产机上经常来一个killall -9,将该用户所有的进程都杀掉。

9.隐藏显示服务
隐藏服务
unadvertise (unadv) {-q qaddress [-g groupname] [-i srvid] |
-g groupname -i srvid} service
显示服务
advertise (adv) {-q qaddress [-g groupname] [-i srvid] | -g groupname -i srvid}
service[:func]

上面两个命令只能在单独登录tmadmin时使用。
重复登录tmadmin后出现
TMADMIN_CAT:199: WARN: Cannot become administrator.Limited set of commands available.
提示不能使用上面命令。

10.sh命令直接执行tuxedo操作

$echo pclt |tmadmin
$echo pq |tmadmin |grep Machine

11.WSL配置参数
WSL的配置重点要注意其CLOPT中几个关键参数的指定:
-m, -M, -x, WSH启动的最大、最小个数,及每个WSH可同时处理的并发请求数,
"-M" * "-x" = MAXWSCLIENTS;
-I, 客户端与服务器端建立连接的超时时间;
-N, 客户端发起请求的响应超时时间;
-T, 客户端在与服务器端建立连接后,允许最大的空闲时间;
-H, 穿防火墙时,防火墙的ip
-p, WSH分配的起始端口
-P, WSH分配的结束端口。 -p 9901 -P 9915 指定端口范围 9901-9915

12.UBB文件中MAX。。的配置
MAXWSCLIENTS <= Tuxedo license
MAXSERVERS = SUM (MAX setting of servers)
MAXACCESSERS = (MAXSERVERS+MAXWSCLIENTS) * 117%


4、常见的中间件调优手段

2.1 JVM调优
2.1.1 垃圾收集和堆大小
  垃圾收集(GC)是指JVM释放Java堆中不再使用的对象所占用的内存的过程,而Java堆(Heap)是指Java应用程序对象生存的空间。堆大小决定了GC的频度和时间。堆越大,GC频度低,速度慢。堆越小,GC频度高,速度快。所以GC和堆大小是一组矛盾。为了获取理想的Heap堆大小,需要使用-verbosegc参数(Sun jdk: -Xloggc:<file>)以打开详细的GC输出。分析GC的频度和时间,结合应用最大负载所需内存情况,得出堆的大小。
通常情况下,我们建议使用可用内存(除操作系统和其他应用程序占用之外的内存)70-80%,为避免堆大小调整引起的开销,设置内存堆的最小值等于最大值即:-Xms=-Xmx。而为了防止内存溢出,建议在生产环境堆大小至少为256M(Platform至少512M),实际环境中512M~1G左右性能最佳,2G以上是不可取的,在调整内存时可能需要调整核心参数进程的允许最大内存数。对于sun和hp的jvm,永久域太小(默认4M)也可能造成内存溢出,应增加参-XX:MaxPermSize=128m。建议设置临时域-Xmn的大小为-Xmx的1/4~1/3, SurvivorRatio为8。

  为了获得更好的性能,建议在启动文件设置WebLogic为产品模式,此时sun和hp jvm JIT引擎为-server,默认情况下打开JIT编译模式对性能也有帮助。调整Chunk Size和Chunk Pool Size也可能对系统的吞吐量有提高。此外还需关闭显示GC: -XX:+DisableExplicitGC。

  当然在Intel平台上使用jRockit(使用参数-jrockit)无疑大大提高WebLogic性能。

2.1.2 jRockit调优
  jRockit支持四种垃圾收集器:分代复制收集器、单空间并发收集器、分代并发收集器和并行收集器。默认状态下,JRockit使用分代并发收集器。要改变收集器,可使用-Xgc:<gc-name>,对应四个收集器分其他为gencopy, singlecom, gencon以及parallel。为得到更好的响应性能,应该使用并发垃圾回收器:-Xgc:gencon,可使用-Xms和-Xmx设置堆栈的初始大小和最大值,要设置护理域-Xns为-Xmx的10%。而如果要得到更好的性能,应该选用并行垃圾回收器:-Xgc: parallel,由于并行垃圾回收器不使用nursery,不必设置-Xns。

  如果你的线程大于100或者在linux平台下,可以尝试使用瘦线程模式:-Xthinthread,同时关闭Native IO:-Xallocationtype:global。

  jRockit 还提供了强大的图形化监控工具Jrockit Management Console。欲详细了解JRockit可访问:http://edocs.bea.com/wljrockit/docs81/index.html




2.2 Server调优
  WebLogic Server的核心组件由监听线程,套接字复用器和可执行线程的执行队列组成。当服务器由监听线程接收到连接请求后,将对它的连接控制权交给等待接收请求的套接字复用器。然后套接字复用器读取离开套接字的请求,并将此请求及相关安全信息或事务处理环境一起置入适当的执行队列中(一般为默认的执行队列)。 当有一个请求出现在执行队列中时,就会有一个空闲的执行线程从该队列中取走发来的该请求,并返回应答,然后等待下一次请求。因此要提高WebLogic的性能,就必须从调整核心组件性能出发。

2.2.1 尽量使用本地I/O库
WebLogic Server有两套套接字复用器:Java版和本地库。采用小型本地库更有效,尽量激活Enable Native IO(默认),此时UNIX默认使用CPUs+1个线程,Window下为双倍CPU。如果系统不能加载本地库,将会抛出java.lang.UnsatisfiedLinkException,此时只能使用Java套接字复用器,可以调整socket readers 百分比,默认为33%。该参数可以在Console Server Tuning Configuration配置栏里设置。

2.2.2 调整默认执行线程数
  理想的默认执行线程数是由多方面的因素决定的,比如机器CPU性能、总线体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。WebLogic生产环境下默认的线程为25个,随着CPU个数的增加,WebLogic可以近乎线性地提高线程数。线程数越多,花费在线程切换的时间也就越多,线程数越小,CPU可能无法得到充分利用。为获取一个理想的线程数,需要经过反复的测试。在测试中,可以以25*CPUs为基准进行调整。当空闲线程较少,CPU利用率比较低时,可以适当增加线程数的大小(每五个递增)。对于PC Server 和Window 2000,则最好每个CPU小于50个线程, 以CPU利用率为90%左右为佳。由于目前WebLogic执行线程没有缩小线程数的功能,所以应将参数Threads Increase设置为0,同时不应改变优先级的大小。

2.2.3 调整连接参数
  WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小,默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。这些参数可以在Console Server Tuning Configration配置栏里找到。

2.2.4 创建新的执行队列
  创建新的执行队列有助于解决核心业务优先、避免交叉阻塞、死锁和长时间处理的业务等问题。通常会将自己的执行队列和默认的执行队列设置不同的优先级,这里优先级不应设为9或者10。 定义一个新的执行队列很容易,利用View Excute Queue选项中的Configure a new Excute Queue链接即可定制新的执行队列。创建新的执行队列后,用户需要为应用程序的J2EE组件配置分配策略,以便它可以找到新的队列。举个例子:要将servlet或jsp捆绑到一个特定的执行队列,必须替换web.xml文件项,将wl-dispatch-policy初始化参数设置为自己的执行队列名。

<servlet>
<servlet-name>servletname</servlet-name>
<jsp-file>/directoryname/deployment.jsp</jsp-file>
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>NewExecuteQueueName</param-value>
</init-param>
</servlet>

  我们可以为一个jsp或者servlet乃至一个WEB应用设置自己的执行队列。同时也可以为EJB设置自己的执行队列。对于执行时间比较长的MDB,建议使用自己的执行队列。

2.3 JDBC调优
2.3.1 调整连接池配置
  JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗,建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。

  增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助,WebLogic能够为每一个连接缓存这些对象,此值默认为10。在保证数据库游标大小足够的前提下,可以根据需要提高Statement Cache Size。比如当你设置连接数为25,Cache Size为10时,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0。

  尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。 当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开。

  最后提一下驱动程序类型的选择,以Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动。而最新驱动器由于WebLogic server/bin目录下的类包可能不是最新的,请以Oracle网站为准: http://www.oracle.com/technology ... tdocs/jdbc9201.html

2.4 WEB调优
2.4.1 调整WEB应用描述符
  WEB应用除代码之外的调优比较简单,仅仅是对一些WEB应用描述符的调整。首先关闭Session Monitoring Enabled,仅仅在Cluster环境下设置Session复制(优先使用内存复制),在保证应用正常运行的情况下,设置较短的Session超时时间。 同时生产环境下无需检查Jsp和servlet:JSPPage Check Secs和Servlet Reload Check Secs均设为-1,关闭JSPKeep Generated 和JSPVerbose对性能也有帮助。此外,还可以对jsp进行预编译,有两种方法:激活precompile选项;使用weblogic.appc事先编译,建议采用后者。

2.5 JMS调优
  1. 增加-Dweblogic.JMSThreadPoolSize=n(至少为5),以提高处理JMS的线程数,在jRockit上增加-XXenablefatspin以减少加锁冲突;
  2. 采用文件存储策略,将同步写策略设置为Direct-Write,同时在windows平台上启用磁盘写入缓存;
  3. 使用分布式目的地时,激活连接工厂Load Balancing Enabled ,Server Affinity Enabled;
  4. 为减少服务器不必要的JMS请求路由,如果多个目的地之间存在事务,则部署在同一JMS服务器上,尽量将连接工厂部署到JMS服务器所在的WebLogic实例上,集群环境下,则最好将连接工厂部署到集群中的所有服务器上,而集群中每个JMS服务器和目的地成员尽量使用类似的设置;
  5. 启用消息分页存储功能,以释放内存,可以为JMS服务器和目的地设置, 激活Messages Paging Enabled和Bytes Paging Enabled,同时使用限额防止服务器耗尽接收消息的所有可用内存空间;
  6. 在运行WebLogic Server进程之外的生产者务必使用流控制, 并增大Send Timeout;
  7. 将JMS Server Expiration Scan Interval设很大的值,能禁止主动扫描过期消息;
  8. 使用FIFO或者LIFO方式处理目的地消息;
  9. MDB的max-beans-in-free-pool不应大于最大MDB线程数(默认线程数/2+1)。

2.6 EJB调优
2.6.1 调整pool和cache
  initial-beans-in-free-pool定义SLSB启动时实例的个数,默认为0,可以调大到正常并发数的大小,以减少初始响应时间。max-beans-in-free-pool为最大个数,默认1000对SLSB来说,在频繁创建和删除实例的情况下很有帮助,一般不用调整,至少设为默认线程数,过大容易造成内存溢出。而对Entity Bean来说,由于是匿名的,所以当频繁使用finder、home和create方法时可以调大。

  对SFSB来说,尽量将max-beans-in-cache参数设置得足够的大,以满足Bean实例对最大并发用户数的要求,可以避免有状态会话Bean过多的钝化行为。而idle-timeout-seconds尽量设置小,如果SFSB不用于存储Web应用会话状态可以设置为0。

  对于Entity Bean来说, max-beans-in-cache同样可以首先采用默认值1000,监控实例缓存和钝化的情况,再做适当调整。

  并行策略concurrency-strategy定义了实体Bean如何管理锁,有四种策略: Exclusive、Databse、ReadOnly、Optimistic。效率依次提高,可靠性依次降低,尽量避免使用互斥策略,如果Bean无需更新操作,使用只读策略,更甚的是,如果Bean的内容不会改变,可设置read-timeout-seconds为0,乐观并行策略时采用事务间缓存策略,在entity-cache描述符中将cache-between-transactions元素设为true。

2.6.2 优化事务隔离级别和事务属性
  对EJB组件来说,有四种事务隔离水平:

TRANSACTION-SERIALIZABLE:在处理完成之前拒绝其他处理的读入、可扩展性或插入数据操作;
TRANSACTION-REPEATABLE-READ:防止处理修改正在被其他处理调用的数据;
TRANSACTOIN-READ-COMMITTED:防止对正在被其他处理修改的数据执行写锁定;
TRANSACTION-READ-UNCOMMITTED:允许处理读入未受权的数据以及允许在向结果中添加记录时可以忽略处理。
   以上隔离水平依次降低,效率和性能依次提高。因此,建议选用满足在业务数据完整性要求前提下水平最低的隔离级别。

  对于事务属性的设置也是如此,对于删除、修改和插入操作设置为Required,而对于只读操作设置为Supports或者NotSupports。

2.6.3 其他一些小技巧
  1. 利用finders-load-bean的默认值true,既可以避免“n+1”的查询问题,又可以提高系统的性能;
  2. 使用delay-updates-until-end-of-tx参数的默认值true,除非应用程序对某些变化有特别的要求;
  3. 应用程序在每个业务方法调用后不需要进行存在性检查,将check-exists-on-method设定为false,以提高程序的性能;
  4. 同一应用内, 将enable-call-by-reference设置为 true;
  5. reentrant设置为false,避免事先加载子数据。


论坛徽章:
1
技术图书徽章
日期:2014-07-11 16:30:58
发表于 2012-02-17 22:14 |显示全部楼层
4、常见的中间件调优手段
谈谈这个吧 。
基本上是
1 log 输入 tail -f 看文件日志。
2 调用 cl32 调用tuxedo  程序。
3 观察日志。与返回结果。
1)如果程序core  使用file core 可以看到是哪个程序产生的core 文件,如果是你当前的程序
那么直接
$>gdb -o core
gdb> where
看堆栈情况。观察哪个地方出现文件。  
2)如果是调用SQL 报错基本上输入会加上 SQLCODE 打印, SQL是否出现问题。哪行打印的可以使用log4c
如果是可以使用
$>oerr ora  ( SQLCODE值)
查看什么原因导致的SQL问题。
4 程序逻辑问题当然这个跟具体的业务要求了。 修改文件 保存,编译,返回第2步骤 LOOP(直到业务逻辑正确,程序运行正常,可以写测试报告了呵呵。)

注意:
善用 输出信息
1 必要的输入是要有的。 关键是如果你的程序部署到生产上,用户投诉让你查个问题。你找不到错误输出信息。那完了。
2 不要加过多的输出,弄的几乎把每个步骤都打印出来。 多大的空间能够呀。有些业务几乎是没秒10多个进来在加那么多没有必要的东西。查个问题的多费劲呀。当然调试GDB是不太好用的可以详细加输出,但调试完通过后请让你的程序干净些。
可读性
公司一般会要求编码格式,不过基本上是Ctrl+c Ctrl+v  改改就完了。 有的连自己为什么这么写都不清楚,以后别人维护起来你让不让人活了。(有点个人情绪。没办法。来气。受害者。) 试过各类的格式工具对tuxedo 的支持都不是很理想。一直想写个工具,对tuxedo 和jsp 想这些特殊的程序 进行格式化优化工具。(还在完善中......)。
性能
1 SQL  SQL直接行影响 tuxedo 程序能能,主键,索引, exists ,  类型,等等,各个方面影响 程序的性能。说以写好tuxedo 程序首先的写好SQL。
2 就是C语言的编程能力, 变量初始化。 避免溢出,程序core 掉。 多余的变量去掉。
使用DECODE函数来减少处理时间
        使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表.
        示例:
        SELECT COUNT(*),SUM(SAL)
        FROM EMP
        WHERE DEPT_NO = 0020
        AND ENAME LIKE ‘SMITH%';
       
        SELECT COUNT(*),SUM(SAL)
        FROM EMP
        WHERE DEPT_NO = 0030
        AND ENAME LIKE ‘SMITH%';
       
        可以用DECODE函数高效地得到相同结果
        SELECT COUNT(DECODE(DEPT_NO,0020,'X',NULL)) D0020_COUNT,
        COUNT(DECODE(DEPT_NO,0030,'X',NULL)) D0030_COUNT,
        SUM(DECODE(DEPT_NO,0020,SAL,NULL)) D0020_SAL,
        SUM(DECODE(DEPT_NO,0030,SAL,NULL)) D0030_SAL
        FROM EMP
        WHERE ENAME LIKE ‘SMITH%';
       
        类似的,DECODE函数也可以运用于GROUP BY 和ORDER BY子句中
建议用UNION替换OR (适用于索引列)
        通常情况下, 用UNION替换WHERE子句中的OR将会起到较好的效果. 对索引列使用OR将造成全表扫描. 注意, 以上规则只针对多个索引列有效. 如果有column没有被索引, 查询效率可能会因为你没有选择OR而降低.
        在下面的例子中, LOC_ID 和REGION上都建有索引.
高效:
        SELECT LOC_ID , LOC_DESC , REGION
        FROM LOCATION
        WHERE LOC_ID = 10
        UNION
        SELECT LOC_ID , LOC_DESC , REGION
        FROM LOCATION
        WHERE REGION = “MELBOURNE”
       
低效:
        SELECT LOC_ID , LOC_DESC , REGION
        FROM LOCATION
        WHERE LOC_ID = 10 OR REGION = “MELBOURNE”
        注意:
        WHERE KEY1 = 10 (返回最少记录)
        OR KEY2 = 20 (返回最多记录)
        ORACLE 内部将以上转换为
        WHERE KEY1 = 10 AND
        ((NOT KEY1 = 10) AND KEY2 = 20)
建议 如何删除重复记录
        高效的删除重复记录方法 (因为使用了ROWID)
        DELETE FROM EMP E
        WHERE E.ROWID > (SELECT MIN(X.ROWID)
        FROM EMP X
        WHERE X.EMP_NO = E.EMP_NO);
建议 用TRUNCATE替代DELETE全表
        当删除表中的所有记录时,如果不需要恢复,建议使用TRUNCATE而不是DELETE ALL,既不占用回滚段,也能加快速度。
建议 多使用COMMIT
        在程序中尽量避免特大事务,多使用COMMIT, 这样程序的性能得到提高,也会因为COMMIT所释放的资源而减少。
        当然要注意,COMMIT次数也不能太频繁,频繁同样会增加数据库负担。
建议 用Where子句替换HAVING子句
        避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,那就能减少这方面的开销.
        示例:
低效:
        SELECT REGION,AVG(LOG_SIZE)
        FROM LOCATION
        GROUP BY REGION
        HAVING REGION != ‘SYDNEY'
        AND REGION != ‘PERTH'
       
高效:
        SELECT REGION,AVG(LOG_SIZE)
        FROM LOCATION
        WHERE REGION != ‘SYDNEY'
        AND REGION != ‘PERTH'
        GROUP BY REGION
建议 用EXISTS替代IN
        在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行联接.在这种情况下, 使用EXISTS(或NOT EXISTS)通常将提高查询的效率.
        示例:
低效:
        SELECT *
        FROM EMP (基础表)
        WHERE EMPNO > 0
        AND DEPTNO IN (SELECT DEPTNO
        FROM DEPT
        WHERE LOC = ‘MELB')
       
高效:
        SELECT *
        FROM EMP (基础表)
        WHERE EMPNO > 0
        AND EXISTS (SELECT ‘X'
        FROM DEPT
        WHERE DEPT.DEPTNO = EMP.DEPTNO
        AND LOC = ‘MELB')
建议 用NOT EXISTS替代NOT IN
        无论在哪种情况下,NOT IN都是最低效的 (因为它对子查询中的表执行了一个全表遍历).可以把它改写成外连接(Outer Joins)或NOT EXISTS.
        示例:
        SELECT …
        FROM EMP
        WHERE DEPT_NO NOT IN (SELECT DEPT_NO
        FROM DEPT
        WHERE DEPT_CAT='A');
(方法一: 高效)
        SELECT ….
        FROM EMP A,DEPT B
        WHERE A.DEPT_NO = B.DEPT(+)
        AND B.DEPT_NO IS NULL
        AND B.DEPT_CAT(+) = ‘A'
       
(方法二: 最高效)
        SELECT ….
        FROM EMP E
        WHERE NOT EXISTS (SELECT ‘X'
        FROM DEPT D
        WHERE D.DEPT_NO = E.DEPT_NO
        AND DEPT_CAT = ‘A');
建议 用表连接替换EXISTS
        通常来说 , 采用表连接的方式比EXISTS更有效率。
        SELECT ENAME
        FROM EMP E
        WHERE EXISTS (SELECT ‘X'
        FROM DEPT
        WHERE DEPT_NO = E.DEPT_NO
        AND DEPT_CAT = ‘A');
       
(更高效)
        SELECT ENAME
        FROM DEPT D,EMP E
        WHERE E.DEPT_NO = D.DEPT_NO
        AND DEPT_CAT = ‘A' ;
建议 用EXISTS替换DISTINCT
        当提交一个包含一对多表信息(比如部门表和雇员表)的查询时,避免在SELECT子句中使用DISTINCT。一般可以考虑用EXIST替换。
        示例:
低效:
        SELECT DISTINCT DEPT_NO,DEPT_NAME
        FROM DEPT D,EMP E
        WHERE D.DEPT_NO = E.DEPT_NO
       
高效:
        SELECT DEPT_NO,DEPT_NAME
        FROM DEPT D
        WHERE EXISTS ( SELECT ‘X'
        FROM EMP E
        WHERE E.DEPT_NO = D.DEPT_NO);
建议避免在索引列上使用计算
        WHERE子句中,如果索引列参与计算,优化器将不使用索引而使用全表扫描。
        示例:
低效:
        SELECT …
        FROM DEPT
        WHERE SAL * 12 > 25000;
       
高效:
        SELECT …
        FROM DEPT
        WHERE SAL > 25000/12;
建议 避免在索引列上使用NOT
        避免在索引列上使用NOT, NOT会产生在和在索引列上使用函数相同的影响. 当ORACLE”遇到”NOT,会停止使用索引转而执行全表扫描。
        示例:
低效: (不使用索引)
        SELECT …
        FROM DEPT
        WHERE NOT DEPT_CODE = 0;
       
高效: (使用了索引)
        SELECT …
        FROM DEPT
        WHERE DEPT_CODE > 0;
       
        需要注意的是,在某些时候, ORACLE优化器会自动将NOT转化成相对应的关系操作符。
        NOT > to <=
        NOT >= to <
        NOT < to >=
        NOT <= to >
建议 用>=替代>
        如果DEPTNO上有一个索引,
       
高效:
        SELECT *
        FROM EMP
        WHERE DEPTNO >=4
       
低效:
        SELECT *
        FROM EMP
        WHERE DEPTNO >3

论坛徽章:
1
技术图书徽章
日期:2014-07-11 16:30:58
发表于 2012-02-17 22:15 |显示全部楼层
有时间在来。呵呵。

论坛徽章:
0
发表于 2012-02-18 09:33 |显示全部楼层
看到大家的踊跃发言,很感动;籍此机会,希望给更多的阅读者或多或少带来一些火花般的启迪。

大家提到的方方面面已经很多很好了,在此只是还需要注意一些更大尺度的把握:
"双刃性":许多事情或者措施,都是双向的,依据经验选择一个好的平衡点,才能达到收益最大化

(1) 比如楼上同仁提到的跟踪内存,如果只是打开Verbose GC尚好,的确会产生很多日志,不过日志量不会大到较严重影响系统的程度,比较常用;但要是上OptimizeIt和Jprobe,小马拖大车的吭哧吭哧,的确会让生产系统严重滞缓,慎用;

(2) 再比如同仁提到的NativeIO,打开的确会提高吞吐性能(要不以前的老名字怎么叫Perfemance Pack呢),但由于以共享库的方式,通过JNI引入了C语言本地代码,也是发生系统Core Dump的一大诱因,经常需要上个补丁什么的;
    而且这里大家需要注意知其然并知其所以然,当年设计开发时内部讨论引入NativeIO,最大的动力,并不是因为所谓“C语言比Java快”,而是因为早年的JDK的Socket编程,只能支持到Send/Recv(),或者说Read/Write()这样的同步接口;而异步Socket的大并发高容量的Select/Poll()机制API,C语言却已成熟多年;引入异步IO,才是当年的真正本意。现在新版JDK已经很好的实现异步IO了,所以WeLogic的控制台很多措辞其实都悄悄变了。

(3) 再比如同仁提到的集群(即Cluster),其实并不是每次请求来都轮询(Round-Robin),或者根据机器负载来平衡;这种负载均衡,其实只对新请求如此,对于老请求(就是同一个浏览器端,已经发过Http请求,而cookie或session尚未超期),其实是粘连(Sticky)的,即老往同一个机器上送,而不是自由分发;其实大家看到WebLogic在SessionID中编码了主地址和备地址,就能猜到。所以前面的分发器配合时,不是越“均衡”越好,也需要粘连算法;


"鲁棒性":一般而言,大型业务系统的稳定性重于高效性;在修订故障,引入参数或者调优系统时,需要充份考虑这点
"鲁棒性"这个词,相信大家在学校里《现代控制理论》中就早早接触到了。比如我们国家的航天事业神舟飞船,如果火箭发射中,受大气中的风、云,气流等稍微扰动一下,那么高速飞行,如果没有很强的抗干扰性或者说输入收敛性,早就不知道偏哪里去了。另外,比如说Windows界面用起来再舒服,大家在服务器领域还是喜欢Unix;同样是PC Server,跟愿意跑Linux,其实这里面至关重要的,也有个系统鲁棒性的问题;Windows有点小操作不当,或者不兼容,框就弹出来了甚至蓝屏了,各子系统耦合度高,整体系统非常脆弱而容易一个点触发全线崩溃;Unix系统却常常有一颗坚实的"心",并不会因为一些应用程序的错误或子系统故障而全线崩溃。(从这里,其实也多少能看到当年贝尔实验室人员的扎实理论功底)。

那么我们在调整中间件系统时,也需要注意对全局的影响;一旦故障发生,我们的设置,是让其收敛的,还是扩散的。

(1) 比如同仁提到的,用ipcrm清理Tuxedo残余,其实实践中很好;因为IPC资源在Tuxedo中大量使用(每个Server都有消息队列;WSL/WSH,以及BBL和Serve间有共享内存,还有大量的信号量等等),如果有什么IPC资源混乱,最终导致BBL锁住,这种错误就会灾难性的扩散到整个全局,导致全程堵塞也不是不可能;

(2) 再比如有同仁提到的新执行队列,现在应该叫Work Manager了,也是一个很好的实践;如果大家共用一个大线程池的话,一种业务卡壳,然后前端人员通常就会不断关闭重开窗口刷,然后线程池就被占满并开始暴涨,并逐渐内存等各资源吃紧,然后所有业务都开始不太灵光了。

等等。。。

论坛徽章:
0
发表于 2012-02-18 09:41 |显示全部楼层
本帖最后由 三人行必有吾师 于 2012-02-18 12:05 编辑

对了,现在这三本书已经全线上架了,比如WebLogic这本书,在各大图书网站输入"WebLogic",加“运维”或者“实战”关键词,都能找出来

由此给大家曾经带来的不便,表示歉意!

论坛徽章:
0
发表于 2012-02-18 10:32 |显示全部楼层
本帖最后由 vsyour 于 2012-02-18 10:36 编辑

视内存大小而定对JVM进行调优
  1. if [ "${together}" = "MNAOM" ];then   
  2.             nohup $JRE_HOME/bin/java -Duser.timezone=UTC -server -Xms256m -Xmx1024m -XX:MaxNewSize=256m -XX:PermSize=128m -XX:MaxPermSize=512m -cp $JAVACP ${SPGPROC_ID} $BOARD_FRAME $BOARD_SLOT>/dev/null 2>&1 &
  3.         elif [ "${together}" = "SPSPG" ]; then
  4.             nohup $JRE_HOME/bin/java -Duser.timezone=UTC -server -Xms256m -Xmx2048m -XX:MaxNewSize=256m -XX:PermSize=128m -XX:MaxPermSize=512m -cp $JAVACP ${SPGPROC_ID} $BOARD_FRAME $BOARD_SLOT>/dev/null 2>&1 &
  5.         else
  6.             echo "Only base board can excute."
  7.             rm $FLAG_STARTING_FILE >> $LOGFILE
  8.             exit 1;
  9.         fi
复制代码

论坛徽章:
0
发表于 2012-02-18 20:35 来自手机 |显示全部楼层
精华帖呀,赞!!!

论坛徽章:
0
发表于 2012-02-18 21:20 |显示全部楼层
WebLogic有安装配置部署的经历,并有项目中实施配置集群的经历。
借宝地,我想向给位高手请教,配置WEBLOGIC两个节点集群的时候,poxy_server一定需要配置吗?poxy_server是配置在其中的一个节点上,并不加入集群。在实施过程中,配置了poxy_server,如果关闭了poxy_server,就无法访问。那么如果配置poxy_server的节点宕机了,那么是不是集群就无法发挥作用呢?是否是配置方法出了问题。还有weblogic集群配合F5实现负载均衡,能实现吗?当时我们只有干掉集群,配置单节点的DOMAIN,再通过F5虚拟地址实现访问?还有其他更好的方法吗?小弟,在这里致谢了先!
GoldenGate有基本了解,通过了ORACLE认证,尚无实施经历,希望有熟悉的朋友分享资料。谢谢了。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP