weblogic连接池配置_weblogic连接scan ip_weblogic长连接(5)

事务可能意外中断，回滚时间很长，事务恢复时过高的并行度可能引起负载增加。

表中大量的行长时间被锁住。

如果事务意外中断，长时间的回滚（恢复）过程中，可能严重影响SQL性能（因为查询时需要回滚块）。

事务还未提交时，影响SQL性能，比如本文中提到的情况。

消耗过多UNDO空间。

对于DELETE大事务，有些版本的oracle在空闲空间查找上会有问题，导致在INSERT数据时，查找空间导致过长的时间。

对于RAC，由于一致性读的代价更大，所以大事务的危害更大。

那么，现在我们可以知道，全表扫描过程还会产生单块读的情况有，读UNDO块。

对于这条SQL，要解决其速度慢的问题，有两种方案：

在表上建个索引，如果类似的SQL还要多次执行，这是最佳方案。

取消SQL，重新执行。因为已经没有事务在运行，重新执行只是会产生事务清除，但不会回滚UNDO记录来构建一致性读块。

继续回到问题，从统计数据来看，每秒只构建了少量的一致性读块（CR block created，table scan blocks gotten这两个值均为2），每秒的table scan rows gotten值为98.4，通过dump数据块可以发现块上的行数基本上在49行左右，所以一致性读块数和行数是匹配的。session logical reads每秒为97.6，由于每回滚一条undo记录都要记录一次逻辑读，这个值跟每秒获取的行数也是匹配的（误差值很小），与data blocks consistent reads - undo records applied的值也是很接近的。问题到这儿，产生了一个疑问，就是单块读较多（超过70），因此可以推测，平均每个undo块只回滚了不到2条的undo记录，同时同一数据块上各行对应的undo记录很分散，分散到了多个undo块中，通常应该是聚集在同一个块或相邻块中，这一点非常奇怪，不过现在已经没有这个环境（undo块已经被其他事务重用），不能继续深入地分析这个问题，就留着一个疑问，欢迎探讨（一个可能的解释是块是由多个并发事务修改的，对于这个案例，不会是这种情况，因为在数据块的dump中没有过多ITL，另外更不太可能是一个块更新了多次，因为表实在很大，在短时间内不可能在表上发生很多次这样的大事务）。

在最后，我特别要提到，在生产系统上，特别是OLTP类型的系统上，尽量避免大事务。

performance

在某些环境下，运行11.2版本的RAC的服务器上，连接了多个public网络，那么就会有如下的需求：

给其他的，或者说是新的public网络增加新的VIP地址。

在新的public网络上增加SCAN VIP.

在新的VIP地址上配置

在新的SCAN VIP地址上配置

实际上从11.2版本开始，grid infrastructure（以下可能会简写为GI）就是一个完整的clusterware，不仅仅是用于，也可以用作应用软件的高可用性。上述的4个需求中，第1个是毫无疑问需要的；第2个需求对运行在grid infrastructure上的应用是必要的；第3个需求在运行在grid infrastructure上的来说是必要的；第4个需求，是针对的，这个需求有点难度，因为在一套grid infrastructure中只能允许有一个SCAN LISTENER的存在，由于可以不通过SCAN IP而是直接通过VIP地址连接，所以这个新的SCAN可以不需要，但是为了完整，我们可以用变通的方法来实现。weblogic连接scan ip

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-30053-5.html