老熊的三分地-Oracle、UNIX、数据恢复 的评论 http://www.laoxiong.net 老熊的生活、Oracle及UNIX技术、Oracle数据恢复工具、观点 Sat, 04 Feb 2012 23:09:31 +0000 http://wordpress.org/?v=2.7.1 hourly 1 warmbreeze 对于 防火墙、DCD与TCP Keep alive 的评论 http://www.laoxiong.net/firewall-dcd-and-tcp-keep-alive.html/comment-page-1#comment-1338 warmbreeze Wed, 18 Jan 2012 01:31:15 +0000 http://www.laoxiong.net/?p=900#comment-1338 写的太好了 写的太好了

]]> roger 对于 防火墙、DCD与TCP Keep alive 的评论 http://www.laoxiong.net/firewall-dcd-and-tcp-keep-alive.html/comment-page-1#comment-1337 roger Tue, 17 Jan 2012 11:12:30 +0000 http://www.laoxiong.net/?p=900#comment-1337 顶你！ 顶你！

]]> 老熊 对于 防火墙、DCD与TCP Keep alive 的评论 http://www.laoxiong.net/firewall-dcd-and-tcp-keep-alive.html/comment-page-1#comment-1336 老熊 Tue, 17 Jan 2012 02:20:26 +0000 http://www.laoxiong.net/?p=900#comment-1336 @ochef, 谢谢您的肯定。 @ochef, 谢谢您的肯定。

]]> ochef 对于 防火墙、DCD与TCP Keep alive 的评论 http://www.laoxiong.net/firewall-dcd-and-tcp-keep-alive.html/comment-page-1#comment-1335 ochef Tue, 17 Jan 2012 02:16:26 +0000 http://www.laoxiong.net/?p=900#comment-1335 写得太好了，特别是最后总结的两点，曾经遇到过类似案例，是一套AIX5.3 + 9.2.0.1的RAC。 写得太好了，特别是最后总结的两点，曾经遇到过类似案例，是一套AIX5.3 + 9.2.0.1的RAC。

]]> 老熊的三分地-Oracle、UNIX、数据恢复 » Blog Archive » 防火墙、DCD与TCP Keep alive 对于 Oracle与防火墙 的评论 http://www.laoxiong.net/oracle_and_firewall.html/comment-page-1#comment-1334 老熊的三分地-Oracle、UNIX、数据恢复 » Blog Archive » 防火墙、DCD与TCP Keep alive Mon, 16 Jan 2012 16:22:22 +0000 http://www.laoxiong.net/?p=90#comment-1334 [...] 在以前我写的一篇文章《Oracle与防火墙》中提到，网络防火墙会切断长时间空闲的TCP连接，这个空闲时间具体多长可以在防火墙内部进行设置。防火墙切断连接之后，会有下面的可能： [...] [...] 在以前我写的一篇文章《Oracle与防火墙》中提到，网络防火墙会切断长时间空闲的TCP连接，这个空闲时间具体多长可以在防火墙内部进行设置。防火墙切断连接之后，会有下面的可能： [...]

]]> myownstars 对于 修改隐含参数_library_cache_advice解决性能问题一例 的评论 http://www.laoxiong.net/resolve-performance-problem-using-library-cache-advice-parameter.html/comment-page-1#comment-1331 myownstars Thu, 12 Jan 2012 08:46:32 +0000 http://www.laoxiong.net/?p=857#comment-1331 老熊， 请问为何这两个等待会比其他latch竞争更加消耗资源： 从等待来看，latch: cache buffers chains和cursor: pin S都会引起CPU的急剧增加，而其他的latch竞争同样也会引起CPU的上升，虽然上升没有前者大 谢谢 老熊， 请问为何这两个等待会比其他latch竞争更加消耗资源：
从等待来看，latch: cache buffers chains和cursor: pin S都会引起CPU的急剧增加，而其他的latch竞争同样也会引起CPU的上升，虽然上升没有前者大

谢谢

]]> 老熊 对于 Hint的常见错误使用方式 的评论 http://www.laoxiong.net/common-incorrect-using-hints.html/comment-page-1#comment-1330 老熊 Tue, 10 Jan 2012 14:22:31 +0000 http://www.laoxiong.net/?p=819#comment-1330 的确是个很奇怪的现象。下面是我测试的结果，第1次带有nologging，redosize为0，但是第2次insert仍然带有nologging，redosize就变成了1100，第3次insert不带有nologging，redosize仍然是1100。 SQL> set autot on SQL> insert into t2 select * from t1 nologging; 已创建10行。 执行计划 ---------------------------------------------------------- Plan hash value: 3617692013 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | 11402 | 946K| 40 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| T1 | 11402 | 946K| 40 (0)| 00:00:01 | -------------------------------------------------------------------------- 统计信息 ---------------------------------------------------------- 266 recursive calls 8 db block gets 40 consistent gets 0 physical reads 0 redo size 1767 bytes sent via SQL*Net to client 1149 bytes received via SQL*Net from client 6 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 10 rows processed SQL> insert into t2 select * from t1 nologging; 已创建10行。 执行计划 ---------------------------------------------------------- Plan hash value: 3617692013 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | 11402 | 946K| 40 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| T1 | 11402 | 946K| 40 (0)| 00:00:01 | -------------------------------------------------------------------------- 统计信息 ---------------------------------------------------------- 0 recursive calls 1 db block gets 7 consistent gets 0 physical reads 1100 redo size 908 bytes sent via SQL*Net to client 950 bytes received via SQL*Net from client 4 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 10 rows processed SQL> insert into t2 select * from t1 ; 已创建10行。 执行计划 ---------------------------------------------------------- Plan hash value: 3617692013 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | 11402 | 946K| 40 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| T1 | 11402 | 946K| 40 (0)| 00:00:01 | -------------------------------------------------------------------------- 统计信息 ---------------------------------------------------------- 1 recursive calls 1 db block gets 7 consistent gets 0 physical reads 1100 redo size 908 bytes sent via SQL*Net to client 941 bytes received via SQL*Net from client 4 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 10 rows processed 我们再做另一个测试，第1次插入不带nologging，而第2次插入带nologging，这一次测试不带nologging的redosize反而是0了。 SQL> truncate table t2; 表被截断。 SQL> set autot on SQL> insert into t2 select * from t1; 已创建10行。 执行计划 ---------------------------------------------------------- Plan hash value: 3617692013 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | 11402 | 946K| 40 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| T1 | 11402 | 946K| 40 (0)| 00:00:01 | -------------------------------------------------------------------------- 统计信息 ---------------------------------------------------------- 1 recursive calls 8 db block gets 13 consistent gets 0 physical reads 0 redo size 1769 bytes sent via SQL*Net to client 1143 bytes received via SQL*Net from client 6 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 10 rows processed SQL> insert into t2 select * from t1 nologging; 已创建10行。 执行计划 ---------------------------------------------------------- Plan hash value: 3617692013 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | 11402 | 946K| 40 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| T1 | 11402 | 946K| 40 (0)| 00:00:01 | -------------------------------------------------------------------------- 统计信息 ---------------------------------------------------------- 1 recursive calls 1 db block gets 7 consistent gets 0 physical reads 1100 redo size 909 bytes sent via SQL*Net to client 954 bytes received via SQL*Net from client 4 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 10 rows processed 看起来这应该是autotrace的问题，准确的结果应该是看v$sesstat里面的redosize统计值。 的确是个很奇怪的现象。下面是我测试的结果，第1次带有nologging，redosize为0，但是第2次insert仍然带有nologging，redosize就变成了1100，第3次insert不带有nologging，redosize仍然是1100。

SQL> set autot on
SQL> insert into t2 select * from t1 nologging;

已创建10行。

执行计划
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 11402 | 946K| 40 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T1 | 11402 | 946K| 40 (0)| 00:00:01 |
--------------------------------------------------------------------------

统计信息
----------------------------------------------------------
266 recursive calls
8 db block gets
40 consistent gets
0 physical reads
0 redo size
1767 bytes sent via SQL*Net to client
1149 bytes received via SQL*Net from client
6 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
10 rows processed

SQL> insert into t2 select * from t1 nologging;

已创建10行。

执行计划
----------------------------------------------------------
Plan hash value: 3617692013
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 11402 | 946K| 40 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T1 | 11402 | 946K| 40 (0)| 00:00:01 |
--------------------------------------------------------------------------

统计信息
----------------------------------------------------------
0 recursive calls
1 db block gets
7 consistent gets
0 physical reads
1100 redo size
908 bytes sent via SQL*Net to client
950 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed

SQL> insert into t2 select * from t1 ;

已创建10行。

执行计划
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 11402 | 946K| 40 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T1 | 11402 | 946K| 40 (0)| 00:00:01 |
--------------------------------------------------------------------------

统计信息
----------------------------------------------------------
1 recursive calls
1 db block gets
7 consistent gets
0 physical reads
1100 redo size
908 bytes sent via SQL*Net to client
941 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed

我们再做另一个测试，第1次插入不带nologging，而第2次插入带nologging，这一次测试不带nologging的redosize反而是0了。

SQL> truncate table t2;

表被截断。

SQL> set autot on
SQL> insert into t2 select * from t1;

已创建10行。

执行计划
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 11402 | 946K| 40 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T1 | 11402 | 946K| 40 (0)| 00:00:01 |
--------------------------------------------------------------------------

统计信息
----------------------------------------------------------
1 recursive calls
8 db block gets
13 consistent gets
0 physical reads
0 redo size
1769 bytes sent via SQL*Net to client
1143 bytes received via SQL*Net from client
6 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed

SQL> insert into t2 select * from t1 nologging;

已创建10行。

执行计划
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 11402 | 946K| 40 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T1 | 11402 | 946K| 40 (0)| 00:00:01 |
--------------------------------------------------------------------------

统计信息
----------------------------------------------------------
1 recursive calls
1 db block gets
7 consistent gets
0 physical reads
1100 redo size
909 bytes sent via SQL*Net to client
954 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed
看起来这应该是autotrace的问题，准确的结果应该是看v$sesstat里面的redosize统计值。

]]> bamboo 对于 Hint的常见错误使用方式 的评论 http://www.laoxiong.net/common-incorrect-using-hints.html/comment-page-1#comment-1329 bamboo Tue, 10 Jan 2012 13:00:20 +0000 http://www.laoxiong.net/?p=819#comment-1329 INSERT INTO T1 SELECT * FROM T2 NOLOGGING; 这个sql语句是不会产生redo日志，以下是我做的实验 （1）这个sql是用nologging，在执行计划中，redosize是0 SQL> set autotrace on; SQL> insert into emp01 select * from emp nologging; 14 rows created. Execution Plan ---------------------------------------------------------- Plan hash value: 3956160932 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | 14 | 518 | 3 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| EMP | 14 | 518 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 461 recursive calls 5 db block gets 123 consistent gets 16 physical reads 0 redo size 671 bytes sent via SQL*Net to client 581 bytes received via SQL*Net from client 4 SQL*Net roundtrips to/from client 8 sorts (memory) 0 sorts (disk) 14 rows processed （2）下面sql不添加nologging，redo size是不为0的 SQL> insert into emp01 select * from emp; 14 rows created. Execution Plan ---------------------------------------------------------- Plan hash value: 3956160932 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | 14 | 518 | 3 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| EMP | 14 | 518 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 1 recursive calls 3 db block gets 8 consistent gets 0 physical reads 940 redo size 675 bytes sent via SQL*Net to client 571 bytes received via SQL*Net from client 4 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 14 rows processed INSERT INTO T1 SELECT * FROM T2 NOLOGGING;
这个sql语句是不会产生redo日志，以下是我做的实验
（1）这个sql是用nologging，在执行计划中，redosize是0
SQL> set autotrace on;
SQL> insert into emp01 select * from emp nologging;

14 rows created.

Execution Plan
----------------------------------------------------------
Plan hash value: 3956160932

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 14 | 518 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| EMP | 14 | 518 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------

Statistics
----------------------------------------------------------
461 recursive calls
5 db block gets
123 consistent gets
16 physical reads
0 redo size
671 bytes sent via SQL*Net to client
581 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
8 sorts (memory)
0 sorts (disk)
14 rows processed
（2）下面sql不添加nologging，redo size是不为0的
SQL> insert into emp01 select * from emp;

14 rows created.

Execution Plan
----------------------------------------------------------
Plan hash value: 3956160932

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 14 | 518 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| EMP | 14 | 518 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------

Statistics
----------------------------------------------------------
1 recursive calls
3 db block gets
8 consistent gets
0 physical reads
940 redo size
675 bytes sent via SQL*Net to client
571 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
14 rows processed

]]> Sidney 对于 修改隐含参数_library_cache_advice解决性能问题一例 的评论 http://www.laoxiong.net/resolve-performance-problem-using-library-cache-advice-parameter.html/comment-page-1#comment-1323 Sidney Mon, 02 Jan 2012 13:59:24 +0000 http://www.laoxiong.net/?p=857#comment-1323 老熊， 想再问一个问题，recreatable内存块unpin的时候需要链接到shared pool，所以需要获取shared pool latch。这个地方有什么oracle 文档说明吗，或者是否有实验可以证明？ 虽然这样的解释很自然，但是这样意味着sql开始执行，需要把cursor pin住，所以要获取一次shared pool latch, 执行结束的时候，unpin cursor，又需要再获取一次shared pool latch。代价可能太大了。 我们做一个oradebug dump heapdump 2的时候，打印出来的LRU List都是unpinned的recreatable的内存快，我很好奇，被pinned住的内存块是不是真的不在LRU list上面，还是实事上一直在LRU list上面，仅仅是dump的时候被跳过而已。另外的一种可能性是，share pool里的LRU List采取了类似buffer poo里面LRU+TCH的算法，share pool latch只是去更新TCH，当然，这只是猜测而已。Jonathan Lewis在他的新书“Oracle Core”提到这个问题 如果我在一个pl/sql做一个循环，把一条使用绑定变量的sql执行1000次，shared pool latch获取的次数只有72次。 最后，下面的creatable应该是recreatable :-) ---quote--- 在oracle中kghupr1这个函数是干什么的呢，简单来说就是un-pin recreatable内存块，其主要目的是要将creatable的内存块链接到shared pool的LRU链表中，在这个过程中要持有shared pool latch。 老熊，
想再问一个问题，recreatable内存块unpin的时候需要链接到shared pool，所以需要获取shared pool latch。这个地方有什么oracle 文档说明吗，或者是否有实验可以证明？
虽然这样的解释很自然，但是这样意味着sql开始执行，需要把cursor pin住，所以要获取一次shared pool latch, 执行结束的时候，unpin cursor，又需要再获取一次shared pool latch。代价可能太大了。

我们做一个oradebug dump heapdump 2的时候，打印出来的LRU List都是unpinned的recreatable的内存快，我很好奇，被pinned住的内存块是不是真的不在LRU list上面，还是实事上一直在LRU list上面，仅仅是dump的时候被跳过而已。另外的一种可能性是，share pool里的LRU List采取了类似buffer poo里面LRU+TCH的算法，share pool latch只是去更新TCH，当然，这只是猜测而已。Jonathan Lewis在他的新书“Oracle Core”提到这个问题

如果我在一个pl/sql做一个循环，把一条使用绑定变量的sql执行1000次，shared pool latch获取的次数只有72次。

最后，下面的creatable应该是recreatable :-)

---quote---
在oracle中kghupr1这个函数是干什么的呢，简单来说就是un-pin recreatable内存块，其主要目的是要将creatable的内存块链接到shared pool的LRU链表中，在这个过程中要持有shared pool latch。

]]> Sidney 对于 修改隐含参数_library_cache_advice解决性能问题一例 的评论 http://www.laoxiong.net/resolve-performance-problem-using-library-cache-advice-parameter.html/comment-page-1#comment-1322 Sidney Mon, 02 Jan 2012 13:00:15 +0000 http://www.laoxiong.net/?p=857#comment-1322 老熊， 这句话怎么理解，是因为这两个latch获取的次数多？ latch: cache buffers chains是不是应该是 latch:cache buffers lru chain? 从等待来看，latch: cache buffers chains和cursor: pin S都会引起CPU的急剧增加，而其他的latch竞争同样也会引起CPU的上升，虽然上升没有前者大 老熊，
这句话怎么理解，是因为这两个latch获取的次数多？ latch: cache buffers chains是不是应该是 latch:cache buffers lru chain?

从等待来看，latch: cache buffers chains和cursor: pin S都会引起CPU的急剧增加，而其他的latch竞争同样也会引起CPU的上升，虽然上升没有前者大

]]>