/诊断方法

回收站对象过多造成查询dba_free_space缓慢

日常监控免不了监控表空间空闲信息,但是有时发现查询他非常缓慢,这是因为dba_free_space 里面条目过多,所以查询起来非常缓慢,为啥这个view里面条目如此
之多呢,有时候会发现里面的extent居然还是连续的, 其实这是因为drop 对象造成的,下面的例子可以展示一下这个场景:
create table t1 as select * from dba_tables where rownum<1000;
create table t2 as select * from dba_tables where rownum<1000; 
分别新建两个表,然后查询他们的extent情况
select * from dba_extents where segment_NAME IN (‘T1′,’T2’)

MAOB T1  TABLE USERS 0 4 520 65536 8 4
MAOB T1  TABLE USERS 1 4 528 65536 8 4
MAOB T1  TABLE USERS 2 4 536 65536 8 4
MAOB T1  TABLE USERS 3 4 7184 65536 8 4
MAOB T1  TABLE USERS 4 4 7192 65536 8 4
MAOB T1  TABLE USERS 5 4 7200 65536 8 4

MAOB T2  TABLE USERS 0 4 7208 65536 8 4   <<T2 是接着T1的最后一个extent分配的
MAOB T2  TABLE USERS 1 4 7216 65536 8 4
MAOB T2  TABLE USERS 2 4 7224 65536 8 4
MAOB T2  TABLE USERS 3 4 7232 65536 8 4
MAOB T2  TABLE USERS 4 4 7240 65536 8 4
MAOB T2  TABLE USERS 5 4 7248 65536 8 4

对两个表进行drop 之后,我们查询  dba_free_space情况
select * from dba_free_space where file_id=4 order by block_id

USERS 4 520 65536 8 4
USERS 4 528 65536 8 4
USERS 4 536 65536 8 4  <<<以上3个是T1的前三个extent 都是连续的,并没有进行合并
USERS 4 640 41943040 5120 4 
USERS 4 7184 65536 8 4
USERS 4 7192 65536 8 4
USERS 4 7200 65536 8 4 <<<以上3个是T1的后三个extent 都是连续的,并没有进行合并

USERS 4 7208 65536 8 4
USERS 4 7216 65536 8 4
USERS 4 7224 65536 8 4
USERS 4 7232 65536 8 4
USERS 4 7240 65536 8 4
USERS 4 7248 65536 8 4      <<以上6个是T2的extent,都是连续的,并没有进行合并
USERS 4 7256 524288 64 4   <<这个和T2的extents是连续的,但是也没有合并

 这些extents都是保持原样的出现在了dba_free_space,所以造成条目增多,我们接下来进行purge 
 purge recyclebin; 
我们再次查询  dba_free_space情况 select * from dba_free_space where file_id=4 order by block_id

USERS 4 520 196608 24 4           <<3个extent 已经合并成一个24blocks的新extent
USERS 4 640 41943040 5120 4
USERS 4 7184 1114112 136 4    <<6个extent 共计72个block连同原有的相邻extent 里面的64 个block合并成为了一个新的136block的extent
dba_free_space条目也大幅减少,所以对于recyclebin里面有着大量drop的表,尤其是这些表曾经分配了大量的extent,就会出现此类问题。

系统内存耗尽的案例分析

近日遇到一个RAC节点hang导致节点被重启的问题,最后经过分析,发现在系统运行一段时间后,系统内存就会耗尽,原本256G的内存,最后只剩几百M。
1. 问题时间段的TOP输出可以看到,内存只剩7G,而分析内存问题,TOP输出是不够的,一般情况下,Database的SGA和PGA是内存使用大户,所以,在TOP很难发现谁是使用内存最多的。
除非某些进程内存使用的格外明显
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Linux OSWbb v7.3.3
zzz ***Tue Feb 21 00:00:10 CST 2017
top – 00:00:12 up 14:16, 10 users, load average: 2.97, 2.31, 2.05
Tasks: 3087 total, 11 running, 3076 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.7%us, 2.8%sy, 0.0%ni, 83.7%id, 0.9%wa, 0.0%hi, 0.9%si, 0.0%st
Mem: 257948M total, 250464M used, 7484M free, 113M buffers
Swap: 65537M total, 0M used, 65537M free, 59868M cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1156 oracle 20 0 4232 568 380 R 101 0.0 0:01.67 gzip
20019 root RT 0 308m 89m 57m S 13 0.0 24:09.96 osysmond.bin
1160 oracle 20 0 11252 3492 836 R 9 0.0 0:00.17 top
49793 oracle 20 0 128g 1.2g 1.2g S 7 0.5 36:00.74 oracle
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2. 通过AWR,可以看到数据库很忙
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Name

 

DB Id

 

Instance

 

Inst num

 

Startup Time

 

Release

 

RAC
M2M

 

602741423

 

m2m1

 

1

 

20-Feb-17 17:02

 

11.2.0.4.0

 

YES
Host Name

 

Platform

 

CPUs

 

Cores

 

Sockets

 

Memory (GB)
node3

 

Linux x86 64-bit

 

56

 

28

 

2

 

251.90

 

Snap Id

 

Snap Time

 

Sessions

 

Cursors/Session

 

Instances
Begin Snap:

 

1054

 

21-Feb-17 00:05:46

 

2230

 

7.0

 

2
End Snap:

 

1055

 

21-Feb-17 01:22:37

 

1862

 

6.2

 

2
Elapsed:

 

 

76.85 (mins)

 

 

 

DB Time:

 

 

18,666.61 (mins)

 

 

 

<<<<<<<<<<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3. 但是Oracle的物理内存使用百分比只有33%,并不是oracle耗尽的主机内存。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Memory Statistics
    Begin    End
Host Mem (MB):    257,948.4    257,948.4
SGA use (MB):    77,824.0    77,824.0
PGA use (MB):    8,938.9    6,416.3
% Host Mem used for SGA+PGA:    33.64    32.66
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4. 注意:一般情况下Oracle的全部进程,如smon, pmon,lgwr等,都会分别使用SGA, PGA,以及一小部分内存作为进程本身使用(这部分一般很小)。
所以,这里的33%,可以代表Oracle全部使用的物理内存。
当然,出现一些bug的情况,如LMS异常使用内存等情况,就另当别论了。
参考案例:
RAC: LMS uses huge memory (Doc ID 1954701.1)
RAC LMS processes using huge PGA memory:
SQL> select pid,spid,program,pga_used_mem,pga_alloc_mem,pga_freeable_mem,pga_max_mem from v$process where program like ‘%LMS%’;
PID SPID USER PROGRAM PGA_USED_MEM PGA_ALLOC_MEM PGA_FREEABLE_MEM PGA_MAX_MEM
———- ———————— ————— ———————————————— ————
13 23698 oracle@grid06.prod.quova.com (LMS0) 1.0644E+10 1.6525E+10 0 1.6525E+10
14 23702 oracle@grid06.prod.quova.com (LMS1) 1.0644E+10 1.6525E+10 0 1.6525E+10
15 23706 oracle@grid06.prod.quova.com (LMS2) 1.0407E+10 1.6157E+10 0 1.6157E+10
16 23710 oracle@grid06.prod.quova.com (LMS3) 1.0599E+10 1.6455E+10 0 1.6455E+10
5. 分析过程中,也确认了一下,PGA曾经使用过的最大内存情况,可以看到PGA最大也就是使用10G,对应256G物理内存来说,很少。不是问题点
select * from dba_hist_pgastat  
SNAP_ID DBID INSTANCE_NUMBER NAME    VALUE
     1054  602741423    1 aggregate PGA target parameter       5.5835E+10
     1054  602741423    1 aggregate PGA auto target       4.3041E+10
     1054  602741423    1 global memory bound       1073741824
     1054  602741423    1 total PGA inuse       8010343424
     1054  602741423    1 total PGA allocated       9373099008
     1054  602741423    1 maximum PGA allocated       1.0711E+10
     1054  602741423    1 total freeable PGA memory 396361728
     1054  602741423    1 process count     2232
     1054  602741423    1 max processes count     3053
     1054  602741423    1 PGA memory freed back to OS       6.3224E+11
     1054  602741423    1 maximum PGA used for auto workareas  5028864
     1054  602741423    1 maximum PGA used for manual workareas   542720
     1054  602741423    1 bytes processed       1036738560
     1054  602741423    1 cache hit percentage      100
     1054  602741423    1 recompute count (total)     7478
   1055  602741423    2 aggregate PGA target parameter       4.8050E+10
     1055  602741423    2 aggregate PGA auto target       3.7282E+10
     1055  602741423    2 global memory bound       1073741824
     1055  602741423    2 total PGA inuse       6643825664
     1055  602741423    2 total PGA allocated       7995835392
     1055  602741423    2 maximum PGA allocated       9677304832
     1055  602741423    2 total freeable PGA memory 420085760
     1055  602741423    2 process count     2107
     1055  602741423    2 max processes count     2365
     1055  602741423    2 PGA memory freed back to OS       8.2417E+11
     1055  602741423    2 maximum PGA used for auto workareas 33622016
     1055  602741423    2 maximum PGA used for manual workareas   542720
     1055  602741423    2 bytes processed       1.3889E+10
     1055  602741423    2 cache hit percentage      100
     1055  602741423    2 recompute count (total)     8519
 
Line 384: 997 602741423 2 maximum PGA allocated 1.0699E+10
Line 967: 998 602741423 2 maximum PGA allocated 1.0699E+10 <<<<<<<<<<<<<<<10G
Line 1380: 983 602741423 1 maximum PGA allocated 1.0598E+10
Line 1436: 986 602741423 1 maximum PGA allocated 1.1655E+10
Line 1808: 1056 602741423 1 maximum PGA allocated 1.1055E+10
Line 2029: 997 602741423 1 maximum PGA allocated 1.3501E+10
Line 2350: 1018 602741423 1 maximum PGA allocated 1.0049E+10
Line 2376: 985 602741423 1 maximum PGA allocated 1.1624E+10
6. 最后,查看meminfo,发现了问题,PageTables占用了168G的内存, 加上SGA和PGA的使用,刚刚好250G左右。
PageTables是内存表,是不共享的,在内存很大的情况下,如果很大process访问内存的话,就会每个process都copy一份PageTables,最终导致大量内存自耗的情况
 
node3_meminfo_17.02.21.0000.dat
zzz ***Tue Feb 21 00:00:10 CST 2017
MemTotal:       264139120 kB  ===> 260 GB
MemFree:         7720156 kB   ===> 7 GB
Buffers:          116576 kB
Cached:         60954824 kB  ===> 60GB (include SGA)
SwapCached:            0 kB
Active:         61768656 kB
Inactive:       12761292 kB
Active(anon):   61284872 kB  ===>
Inactive(anon): 11620960 kB
Active(file):     483784 kB  ===> 500 MB
Inactive(file):  1140332 kB   ===> 1GB
Unevictable:      333944 kB
Mlocked:          223568 kB
SwapTotal:      67110908 kB
SwapFree:       67110780 kB
Dirty:              3764 kB
Writeback:             0 kB
AnonPages:      13793504 kB
Mapped:         58621868 kB
Shmem:          59376696 kB  
Slab:            1354844 kB   ===> 1 GB
SReclaimable:     351496 kB
SUnreclaim:      1003348 kB
KernelStack:       29248 kB
PageTables:     176260660 kB  ===> 168 GB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    199180468 kB
Committed_AS:   88076096 kB
关于PageTables,参考下图
 
7. 检查之前正常时间段的meminfo,可以发现,刚启动数据库时,PageTables只有700M,但是随着进程的增加,很快PageTables就增长上来了
meminfo_17.02.20.1400.dat
zzz ***Mon Feb 20 14:19:05 CST 2017
MemTotal:       264139120 kB
MemFree:        222005744 kB
Buffers:          112332 kB
 
SUnreclaim:       258840 kB
KernelStack:       11320 kB
PageTables:       747560 kB   <<<<<<<<<<<<<<<
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
 
Line 1113: PageTables:       752060 kB
Line 1157: PageTables:       769128 kB
Line 1201: PageTables:       769252 kB
Line 1245: PageTables:       758068 kB
Line 1289: PageTables:      2995368 kB   <<<<<<<<<<<<<<<<<
Line 1333: PageTables:      4314036 kB
Line 1377: PageTables:      5717752 kB
Line 1421: PageTables:      6107780 kB
Line 1465: PageTables:      6427636 kB
Line 1509: PageTables:      7307184 kB
Line 1553: PageTables:      8552708 kB
Line 1597: PageTables:      9382396 kB
Line 1641: PageTables:     10236492 kB
 
8. 既然问题找到了,如何解决呢?
Hugepages是解决这种问题的最好方案。
hugepages的内存块是2M(普通内存块是4K),首先内存管理的成本就降低500倍,而且hugepages的内存表是可以共享的。
 
9, 最终,配置hugepages,解决问题。
相关hugepages文档,请参考:
HugePages on Linux: What It Is… and What It Is Not… (Doc ID 361323.1)
HugePages on Oracle Linux 64-bit (Doc ID 361468.1)
HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux (Doc ID 749851.1)
Linux IA64 example of allocating 48GB SGA using hugepages (Doc ID 397568.1)
Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration (Doc ID 401749.1)
USE_LARGE_PAGES To Enable HugePages In 11.2 (Doc ID 1392497.1)

 题外话,oswatcher是Oracle分析和解决问题,非常有用的一个工具,在很多问题的分析上,都能提供很大的帮助。 所以强烈建议部署。

关于sys CPU usage 100%问题的分析

最近一个客户抱怨他的核心EBS数据库出现性能问题。这是一个10.2.0.3的数据库,
运行在Red Hat Enterprise Linux Server release 5.5 (Linux x86-64)操作系统上。

根据客户描述,由于需要维护UPS,他们重启了数据库,结果重启数据库后他们发现只要他们的应用
开始连接数据库,那么主机的sys CPU使用率就会变成100%, 但是user CPU使用率几乎是0.
而且只要停掉监听或者应用不开启新session连接数据库,这个问题就会消失。

如下是问题发生期间的vmstat输出,可见cpu中的sys(倒数第4列)几乎100%, CPU Run Queue (第1列)
非常高,而此时free memory还有20G(第4列),看来内存很充裕。

SNAP_INTERVAL 15
CPU_COUNT 32

zzz ***Fri Dec 2 17:05:03 CST 2016
procs ———–memory———- —swap– —–io—- –system– —–cpu——
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
48  0      0 22026868 213392 37138888    0    0    21    31   13   39  6  8 86  0  0
44  1      0 21968452 213392 37138900    0    0     0   360 1093  537  8 92  0  0  0
44  1      0 21941632 213392 37139028    0    0     0   288 1080  371  9 91  0  0  0
……
zzz ***Fri Dec 2 17:10:12 CST 2016
procs ———–memory———- —swap– —–io—- –system– —–cpu——
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
121  2      0 21495944 218356 37142412    0    0    21    31   13   39  6  9 85  0  0
122  4      0 21486192 218356 37142432    0    0     0   308  119  753  7 93  0  0  0
121  2      0 21478868 218364 37142424    0    0     0   592   97  517  5 95  0  0  0

首先我看了一遍客户提供的AWR,发现DB相当空闲,虽然CPU time占据了91.2,但是总的CPU Time
在119分钟的采样中只有18345秒(305分钟),相对于客户32个CPU Core来说不是个问题。

Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 38119 02-Dec-16 16:00:28 255 63.2
End Snap: 38121 02-Dec-16 18:00:18 193 48.7
Elapsed: 119.83 (mins)
DB Time: 335.30 (mins)  <<< 相当空闲

Top 5 Timed Events

Event    Waits    Time(s)    Avg Wait(ms)    % Total Call Time    Wait Class
CPU time         18,345         91.2    
os thread startup    971    937    965    4.7    Concurrency
latch free    582    657    1,128    3.3    Other
db file sequential read    4,712,799    345    0    1.7    User I/O
log file parallel write    247,562    258    1    1.3    System I/O

AWR中没发现什么异常,DB的alert log显示一些无法fork进程的消息,估计是资源紧张了。

Fri Dec  2 17:06:16 2016
Process q002 died, see its trace file
Fri Dec  2 17:06:16 2016
ksvcreate: Process(q002) creation failed

好吧,一般情况下如果我们发现CPU高,无论是sys的还是user的,我们一般的做法是先定位top function call
然后通过这些function call来定位oracle或者OS行为,并且通过这些call来搜索与匹配已知问题。
在linux上,最方便收集这些信息的就是用perf这个工具。关于perf,参见:

https://perf.wiki.kernel.org/index.php/Tutorial

结果客户说他们无法安装perf命令,不过他提到他的OS中显示很多错误:

Dec  2 17:05:23 erpdb1 kernel: BUG: soft lockup – CPU#5 stuck for 10s! [oracle:15668]
Dec  2 17:05:23 erpdb1 kernel: CPU 5:
Dec  2 17:05:23 erpdb1 kernel: Call Trace:
Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff8000e9a8>] __set_page_dirty_nobuffers+0xc2/0xe9
Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff80007c1b>] unmap_vmas+0x522/0x904
Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff80012d08>] unmap_region+0xb8/0x12b
Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff80011e45>] do_munmap+0x21b/0x29a
Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff800655ab>] __down_write_nested+0x12/0x92
Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff80121e88>] sys_shmdt+0x5b/0x133
Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff8005e28d>] tracesys+0xd5/0xe0

通过call stack,看来在回收内存时报错了,推测这个错误应当发生在进程退出阶段,
不过难以断定这些错误与sys cpu高的因果关系。

结合客户描述的现象,这看起来很像连接风暴,因此我们检查了ps的输出,发现进程数并未明显增加,
不过问题最严重的时间断片了。这些零碎的信息并不能给我们一个很清晰的线索。

$ awk ‘/$ORACLE_SID/{n++;next}/^zzz/{if(t)print t,”-“,n;t=$0;n=0}END{print t,”-“,n}’ XXXX_ps_16.12.02.1700.dat

zzz ***Fri Dec 2 17:04:18 CST 2016 – 235
zzz ***Fri Dec 2 17:04:33 CST 2016 – 236
zzz ***Fri Dec 2 17:04:48 CST 2016 – 229
zzz ***Fri Dec 2 17:05:03 CST 2016 – 228   <<<< 此时问题实际上已经发生了
zzz ***Fri Dec 2 17:05:19 CST 2016 – 178   <<<< 17:05 ~ 17:13 的断片了
zzz ***Fri Dec 2 17:13:19 CST 2016 – 283   <<<<
zzz ***Fri Dec 2 17:13:34 CST 2016 – 283
zzz ***Fri Dec 2 17:13:49 CST 2016 – 196

接下来看了top,发现虽然OS的sys CPU高,不过top的process都是oracle,表明此问题一定
与oracle有点关系。

zzz ***Fri Dec 2 17:05:03 CST 2016
top – 17:05:05 up  9:24,  3 users,  load average: 41.76, 28.54, 19.68
Tasks: 660 total,  45 running, 615 sleeping,   0 stopped,   0 zombie
Cpu(s):  8.3%us, 91.7%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  65993408k total, 44046040k used, 21947368k free,   213392k buffers
Swap: 62918564k total,        0k used, 62918564k free, 37139028k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
19610 oracle   25   0 9917m 8.5g 8.5g R 101.8 13.6   1:19.76 oracle
19756 oracle   25   0 9917m 7.0g 7.0g R 100.9 11.1   1:05.76 oracle
19760 oracle   25   0 9917m 6.7g 6.7g R 100.9 10.7   1:06.56 oracle
19942 oracle   25   0 9917m 5.1g 5.1g R 100.9  8.0   0:46.67 oracle
20107 oracle   25   0 9917m 3.1g 3.1g R 100.9  4.9   0:26.39 oracle
20204 oracle   25   0 9917m 1.2g 1.2g R 100.9  1.9   0:10.63 oracle
19486 oracle   25   0 9917m 9.3g 9.3g R 99.9 14.8   1:25.10 oracle
19721 oracle   25   0 9917m 6.9g 6.8g R 99.9 10.9   1:08.22 oracle

那么问题来了,oracle软件一般都是执行user code,因此大多数情况下会消耗user space
的CPU,怎么会消耗sys CPU呢? 先man一下top:

sy – This is the amount of time that the CPU spent running the kernel.
All the processes and system resources are handled by the Linux kernel.
When a user space process needs something from the system, for example
when it needs to allocate memory, perform some I/O, or it needs to
create a child process, then the kernel is running.

这说明oracle进程是有可能消耗kernel space的CPU的,比如申请内存,执行I/O等。
挑出上面的top列出的进程,在ps输出中找规律:

$ grep 19610 Dec*
TIME           USER       PID  PPID PRI %CPU %MEM    VSZ   RSS WCHAN  S  STARTED     TIME COMMAND
Dec 2 17:03:17 oracle  19610     1  14 78.5  0.9 10155628 605564 –   R 17:03:10 00:00:05 ora_q002_XXXX
Dec 2 17:03:32 oracle  19610     1  14 57.6  2.1 10155628 1437940 –  R 17:03:09 00:00:13 ora_q002_XXXX
Dec 2 17:03:47 oracle  19610     1  14 67.6  4.3 10155628 2868692 –  R 17:03:10 00:00:25 ora_q002_XXXX
Dec 2 17:04:02 oracle  19610     1  14 75.8  6.9 10155628 4559708 –  R 17:03:09 00:00:40 ora_q002_XXXX
Dec 2 17:04:18 oracle  19610     1  14 76.7  9.1 10155628 6015688 –  R 17:03:10 00:00:52 ora_q002_XXXX
Dec 2 17:04:33 oracle  19610     1  14 70.9 10.4 10155628 6865876 –  R 17:03:09 00:00:59 ora_q002_XXXX
Dec 2 17:04:48 oracle  19610     1  14 67.7 11.6 10155628 7684088 –  R 17:03:09 00:01:07 ora_q002_XXXX
Dec 2 17:05:03 oracle  19610     1  14 68.9 13.3 10155628 8838576 –  R 17:03:10 00:01:18 ora_q002_XXXX

$ grep 19756 Dec*

TIME           USER       PID  PPID PRI %CPU %MEM    VSZ   RSS WCHAN  S  STARTED     TIME COMMAND
Dec 2 17:03:47 oracle  19756     1  16 50.0  0.3 10155628 222508 –   R 17:03:44 00:00:02 oracleXXXX (LOCAL=NO)
Dec 2 17:04:02 oracle  19756     1  14 47.9  1.4 10155628 961764 –   R 17:03:43 00:00:09 oracleXXXX (LOCAL=NO)
Dec 2 17:04:18 oracle  19756     1  14 55.5  3.0 10155628 2021664 –  R 17:03:44 00:00:18 oracleXXXX (LOCAL=NO)
Dec 2 17:04:33 oracle  19756     1  14 68.4  5.6 10155628 3703572 –  R 17:03:43 00:00:34 oracleXXXX (LOCAL=NO)
Dec 2 17:04:48 oracle  19756     1  14 75.4  8.2 10155628 5459948 –  R 17:03:43 00:00:49 oracleXXXX (LOCAL=NO)
Dec 2 17:05:03 oracle  19756     1  14 80.6 10.9 10155628 7217680 –  R 17:03:44 00:01:04 oracleXXXX (LOCAL=NO)

从以上输出可以发现一个明显规律: 这些进程的RSS在1分多钟从几十M变成7~8G,但是VSZ却没有变化。
接着man ps

VSZ: virtual memory usage of entire process. vm_lib + vm_exe + vm_data + vm_stack
RSS: resident set size, the non-swapped physical memory that a task has used (in kiloBytes). (alias rssize, rsz).

任何一个oracle进程的VSZ约等于SGA加上这个进程的PGA(实际上VSZ还包含一些kernel内存),正常情况下一个进程的pga是很小的。
以上输出中VSZ没有改变,因此发生巨大变化的RSS申请的内存一定不是PGA而是SGA(因为如果增长的是PAG那么VSZ也会跟着增长)。
好吧,那么只有一个可能了,那就是这个进程在touch整个sga,为什么会这样?

我们需要再回到原点再看一眼AWR的数据库参数信息,赫然发现如下内容:

sga_max_size    10250878976
sga_target    8304721920
pre_page_sga    TRUE  <<<< 看这里

这个设置中的sga_max_size正好10g,与我们在ps中看到的VSZ正好相等。

问题的原因是客户设置了pre_page_sga=true,这样在oracle进程启动阶段会touch整个SGA,
这个过程中会调用OS的sys call来touch 整个 shared memory entry,因此引发了高SYS CPU消耗。
参见如下文档的描述:

Health Check Alert: Consider setting PRE_PAGE_SGA to FALSE (Doc ID 957525.1)

回过头来再看alert log,观察参数pre_page_sga是什么时候改的,发现它在很久以前的很多次重启就是true了。
也就是说,这个问题一直都存在,只是客户最近维护UPS之后才发现,维护UPS这个信息误导了我们。

一个IP packet reassembles failure导致的IPC Send timeout和实例驱逐

一般来说,对于IPC Send timeout,可能的情况有以下几种:

1、节点本地盘CPU等待队列超高或IO繁忙、空闲物理内存用尽等,这种情况往往是相互伴随发生的,可以从OSWatcher的vmstat和iostat来发现;

2、私网网络发生丢包或异常,从OSWatcher的netstat和trace route输出中可以看到;

3、DRM或skgxp等方面的Oracle Bug,如(Doc ID 1594578.1)

这个案例属于上述第二种,但由于处理过程比较反复,且最后一次重现时问题指向IP reassembles failure,而不是UDP packet drop,所以记录下来以备今后参考。

standby 磁盘IO性能较差,影响Primary性能

由于standby 磁盘IO性能较差,导致Primary的性能受到影响。
主库主要是等待”log file switch completion”,通过ASH dump分析,最终发现实际等待事件是”LGWR-LNS wait on channel”.这个事件基本上可以将问题归结到网络性能和standby的IO性能,而客户的传输模式是“MAXIMUM AVAILABILITY”
最后提出两个解决方案,
1. 更换性能更好的standby存储
2. 修改传输模式为MAXIMUM performance,并使用LGWR ASYNC传输模式

数据文件,通过List Bakcup在catalog的不同显示问题

1. 近日遇到一个小问题,在standby上连接controlfile进行全库备份,备份完成后,通过list bakcup,查询到的数据文件路径是“u01/data/****”
2. 但是在连接到catalog,并sync之后,发现数据文件的路径变成“+DATA/ora10g/datafile/***”, 这是Primary数据库的实际路径。
3. 为什么会发生这种情况呢?
这个问题是由于Standby数据库创建过程中,standby没有使用和primary相同的ASM存储,及ASM路径,而是使用的文件系统存放datafile。
这会涉及到db_file_name_convert和log_file_name_convert两个参数。

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569