oracle+监听会挂掉吗,为什么监听会自动停止

10.2.0.4下遇到过一例，是在RMAN备份时侦听挂掉

TNS Listener Crash with Core dump [ID 549932.1]

In this Document

Symptoms

Cause

Solution

References

Applies to:

Oracle Net Services - Version: 10.2.0.3.0 to 11.1.0.6.0 - Release: 10.2 to 11.1

Generic UNIX

Checked for relevance on 30-SEP-2011.

Symptoms

There may be heavy load on the CPU shooting up to 100%.

The number of sessions in the database is well below the upper or maximum limit defined in the parameter  file.

The listener crashes suddenly during  this heavy CPU load generating the core.

(Optional) Listener.Ora has SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF.

Listener Log:

-------------

.....

.....

19-NOV-2007 13:40:49 * (CONNECT_DATA=(SID=ORAC)(CID=(PROGRAM=C:\pegasos\te\usys\bin\uniface.exe)(HOST=TERVI-NB179)(USER=kjokioja))) * (ADDRESS= (PROTOCOL=tcp)(HOST=10.12.152.5)(PORT=1670)) * establish * ORAC * 12518

TNS-12518: TNS:listener could not hand off client connection

TNS-12571: TNS

acket writer failure

TNS-12560: TNS

rotocol adapter error

TNS-00530: Protocol adapter error

Linux Error: 104: Connection reset by peer

19-NOV-2007 13:40:49 * (CONNECT_DATA=(SID=ORAC)(CID=(PROGRAM=C:\pegaos\te\usys\bin\uniface.exe)(HOST=TERVI-0184A)(USER=paitasal))) * (ADDRESS=(PROTO COL=tcp)(HOST=10.12.176.136)(PORT=1574)) * establish * ORAC * 12518

TNS-12518: TNS:listener could not hand off client connection

TNS-12547: TNS:lost contact

TNS-12560: TNS

rotocol adapter error

TNS-00517: Lost contact

Linux Error: 32: Broken pipe

.........

........

The Operating system log (/var/log/messages) may show the following :

tnslsnr[5841]: segfault at 0000000000000018 rip 0000003eab66854d rsp 0000007fbfff9230 error 4

tnslsnr[6469]: segfault at 0000000000000018 rip 0000003eab66854d rsp 0000007fbfff9420 error 4

tnslsnr[7375]: segfault at 0000000000000018 rip 0000003eab668bb3 rsp 0000007fbfff9c70 error 4

Gdb on the core file generated shows the following stack :

#gdb  /home/oracle/db_1/bi/tnslsnr core.7375   Core was generated  by `/opt/oracle/ora102/bin/tnslsnr LISTENER -inherit'.

Program terminated with  signal 11, Segmentation fault.

Reading symbols from /opt/oracle/ora102/lib/libclntsh.so.10.1...(no debugging symbols found)...done.

........

.........

(gdb) bt

#0  0x00000032b7468bb3 in _int_free () from  /lib64/tls/libc.so.6

#1  0x00000032b74691f6 in free () from /lib64/tls/libc.so.6

#2  0x000000000040f01f in nsglhe ()

#3  0x00000000004114e9 in nsglma ()

#4  0x00000000004061cb in main ()

(gdb) where

#0  0x00000032b7468bb3 in _int_free () from /lib64/tls/libc.so.6

#1  0x00000032b74691f6 in free () from /lib64/tls/libc.so.6

#2  0x000000000040f01f  in nsglhe ()

#3  0x00000000004114e9 in nsglma ()

#4  0x00000000004061cb in main ()

The core indicates that the program terminated with signal 11, Segmentation fault .

SIGSEGV is reported for improper memory handling .The default action for a program upon receiving

SIGSEGV is abnormal termination. This action will end the process.

The virtual memory stats (vmstat) output may show huge paging/swapping activity .

For Example:

-------------

$vmstat 5 7 The si and so column under the swap section suggests the amount of memory swapped in from disk (/s)and amount of memory swapped to disk (/s) respectively.

procs                      memory    swap          io     system         cpu

r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id

2  0  0  27124   3940   1160  74528   0 1304  956  5360  272   191  51  21  98

3  0  0  27080   3756   1180  72580   0 260  2552   388  218   429  90  10  89

14  2  1  26808   5096   1188  69868  84 1108 2016  9064  490   567  59  22  96

4  0  0  25548   5912   1192  73032   0   0   436     0  478   736  50  50   0

5  0  0  25548   3940   1192  73548   0   0  1560     0  301   385  93   7   0

1  1  1  25548   3336   1192  71800   8 176  2848   432  258   147  91   9  88

1  0  0  25544   4124   1200  70480 116  60   836    60  171   200  97   3  92

Note: You may also use the top command to check the system memory usage.

Cause

Extensive paging/swapping activity is a clear  indication that the sytem is running out of the physical memory.

Solution

Solution :

1. Increase the physical memory of the system.

OR

2. Apply the Patch 6139856 for unpublished Bug 6139856 if available for your platform.

OR

3. Configure Hugepages on the OS. Ref : Note 361323.1

A Note on HugePages:

Hugepages is a mechanism that allows the Linux kernel to utilise the multiple page size capabilities of modern hardware architectures.  Its important to know that utilising a huge amount of physical memory with the default page size consumes the TLB and adds processing overhead. The Linux kernel is able to set aside a portion of physical memory to be able be addressed using a larger page size. Since the page size is higher, there will be less overhead managing the pages with the TLB. In the Linux 2.6 series of kernels, hugepages is enabled using the CONFIG_HUGETLB_PAGE feature when the kernel is built. Systems with large amount of memory can be configured to utilise the memory more efficiently by setting aside a portion dedicated for hugepages. The actual size of the page is dependent on the system architecture. A typical x86 system will have a Huge Page Size of 2048 kBytes. The huge page size may be found by looking at the /proc/meminfo :

# cat /proc/meminfo |grep Hugepagesize Hugepagesize: 2048 kB

For more on configuring Hugepages please refer Note 361323.1

References

NOTE:361323.1 - HugePages on Linux: What It Is... and What It Is Not...

BUG:6752308 - LISTENER DIED BY SEGFAULT AFTER TNS ERROR

相关内容

产品

Oracle Database Products > Oracle Database > Net Services > Oracle Net Services > SQL*Net > Listener issues

关键字

HUGEPAGES;SIGNAL;SIGNAL 11;TNSLSNR;VIRTUAL MEMORY

错误

836;SEGFAULT;TNS-12518;TNS-530;TNS-12571;TNS-12547;TNS-517;TNS-12560

返回页首返回页首

Copyright (c) 2012, Oracle. All rights reserved.