数据库运行一段时间就自动停止,连接报ora 12514 错误

shengang34

查看下SGA、缓存和IO，SGA和缓存不要设置的太大；

前几天遇到过这个问题，是在AIX上，原因是IO有瓶颈，所有的业务都在1个磁盘上跑，造成一个磁盘繁忙总在80％以上，后来把数据放在裸设备上，平均分配磁盘后解决这个问题。

wanufay

谢谢大家的回复,今天早上又自动停止了一次,这次log记录比较全面.请高手再看看,11:20发现数据库自动断了,我马上上服务器startup,11;24启动好了.
Mon Jun  4 07:02:47 2007
Thread 1 advanced to log sequence 1686
  Current log# 2 seq# 1686 mem# 0: /export/home1/oracle2/oradata/orclsun3/redo02.log
Mon Jun  4 08:10:23 2007
Errors in file /export/home1/oracle2/OraHome5/admin/orclsun3/bdump/orclsun3_d002_15851.tr
c:
ORA-00600: internal error code, arguments: [17147], [0x5F8E0EFC0], [], [], [], [], [], []
Mon Jun  4 08:10:28 2007
Errors in file /export/home1/oracle2/OraHome5/admin/orclsun3/bdump/orclsun3_d002_15851.tr
c:
ORA-07445: exception encountered: core dump [kmnsbf()+48] [SIGBUS] [Invalid address align
ment] [0x5FDC8DC2A] [] []
ORA-00600: internal error code, arguments: [17147], [0x5F8E0EFC0], [], [], [], [], [], []
Mon Jun  4 08:10:53 2007
found dead dispatcher 'D002', pid = (21, 1)
Mon Jun  4 08:26:00 2007
Thread 1 advanced to log sequence 1687
  Current log# 3 seq# 1687 mem# 0: /export/home1/oracle2/oradata/orclsun3/redo03.log
Mon Jun  4 11:20:34 2007
Errors in file /export/home1/oracle2/OraHome5/admin/orclsun3/udump/orclsun3_ora_7631.trc:
ORA-07445: exception encountered: core dump [kghxal()+84] [SIGSEGV] [Address not mapped t
o object] [0xFFFFF90100000A38] [] []
Mon Jun  4 11:20:41 2007
Errors in file /export/home1/oracle2/OraHome5/admin/orclsun3/bdump/orclsun3_pmon_15813.tr
c:
ORA-07445: exception encountered: core dump [kghxcu()+452] [SIGSEGV] [Address not mapped
to object] [0xFFFFF901000002CE] [] []
Mon Jun  4 11:20:58 2007
MMON: terminating instance due to error 472
Instance terminated by MMON, pid = 15843
Mon Jun  4 11:22:47 2007
Starting ORACLE instance (normal)
Mon Jun  4 11:24:01 2007
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =330
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Warning: MAX_SHARED_SERVERS (2000) > PROCESSES (500)
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.3.0.
System parameters with non-default values:
  processes                = 500
  sessions                 = 3000
  sga_max_size             = 10737418240
  __shared_pool_size       = 1660944384
  shared_pool_size         = 0
  __large_pool_size        = 50331648
  large_pool_size          = 0
  __java_pool_size         = 117440512
  java_pool_size           = 0
  __streams_pool_size      = 50331648
  streams_pool_size        = 50331648
  nls_length_semantics     = BYTE
  resource_manager_plan    =
  sga_target               = 10737418240
  control_files            = /export/home1/oracle2/oradata/orclsun3/control01.ctl, /expor
t/home1/oracle2/oradata/orclsun3/control02.ctl, /export/home1/oracle2/oradata/orclsun3/co
ntrol03.ctl
  db_block_size            = 8192
  __db_cache_size          = 8824815616
  db_cache_size            = 0
  compatible               = 10.2.0.1.0
  db_file_multiblock_read_count= 8
  db_recovery_file_dest    = /export/home1/oracle2/OraHome5/flash_recovery_area
  db_recovery_file_dest_size= 2147483648
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  undo_retention           = 900
  remote_login_passwordfile= EXCLUSIVE
  db_domain                = wires.cc
  dispatchers              = (PROTOCOL=TCP)(DISPATCHERS=5) (POOL=on), (ADDRESS=(PROTOCOL=
TCP)(HOST=218.*.*.*)) (DISPATCHERS=5) (POOL=on), (ADDRESS=(PROTOCOL=TCP)(HOST=192.16
8.3.245)) (DISPATCHERS=5) (POOL=on)
  shared_servers           = 20
  max_shared_servers       = 2000
  max_dispatchers          = 50
  shared_server_sessions   = 200
  session_cached_cursors   = 40
  job_queue_processes      = 100
  parallel_max_servers     = 55
  background_dump_dest     = /export/home1/oracle2/OraHome5/admin/orclsun3/bdump
  user_dump_dest           = /export/home1/oracle2/OraHome5/admin/orclsun3/udump
  core_dump_dest           = /export/home1/oracle2/OraHome5/admin/orclsun3/cdump
  audit_file_dest          = /export/home1/oracle2/OraHome5/admin/orclsun3/adump
  session_max_open_files   = 20
  db_name                  = orclsun3
  open_cursors             = 600
  pga_aggregate_target     = 2147483648
  aq_tm_processes          = 0
  _olap_parallel_update_threshold= 2147483647
PMON started with pid=2, OS id=7761
PSP0 started with pid=3, OS id=7763
MMAN started with pid=4, OS id=7765
DBW0 started with pid=5, OS id=7767
DBW1 started with pid=6, OS id=7769
DBW2 started with pid=7, OS id=7771
DBW3 started with pid=8, OS id=7773
DBW4 started with pid=9, OS id=7775
DBW5 started with pid=10, OS id=7777
DBW6 started with pid=11, OS id=7779
LGWR started with pid=12, OS id=7781
CKPT started with pid=13, OS id=7783
SMON started with pid=14, OS id=7785
RECO started with pid=15, OS id=7787
CJQ0 started with pid=16, OS id=7789
MMON started with pid=17, OS id=7791
Mon Jun  4 11:24:10 2007
starting up 5 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'..
.
MMNL started with pid=18, OS id=7793
Mon Jun  4 11:24:11 2007
starting up 5 dispatcher(s) for network address '(ADDRESS=(PROTOCOL=TCP)(HOST=218.106.120
.94))'...
starting up 5 dispatcher(s) for network address '(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.3.2
45))'...
starting up 20 shared server(s) ...
Mon Jun  4 11:24:19 2007
ALTER DATABASE   MOUNT
Mon Jun  4 11:24:23 2007
Setting recovery target incarnation to 2
Mon Jun  4 11:24:23 2007
Successful mount of redo thread 1, with mount id 706013603
Mon Jun  4 11:24:23 2007
Database mounted in Exclusive Mode
Completed: ALTER DATABASE   MOUNT
Mon Jun  4 11:24:24 2007
ALTER DATABASE OPEN
Mon Jun  4 11:24:24 2007
Beginning crash recovery of 1 threads
parallel recovery started with 16 processes
Mon Jun  4 11:24:28 2007
Started redo scan
Mon Jun  4 11:24:29 2007
Completed redo scan
598 redo blocks read, 58 data blocks need recovery
Mon Jun  4 11:24:29 2007
Started redo application at
Thread 1: logseq 1687, block 15626
Mon Jun  4 11:24:29 2007
Recovery of Online Redo Log: Thread 1 Group 3 Seq 1687 Reading mem 0
  Mem# 0: /export/home1/oracle2/oradata/orclsun3/redo03.log
Mon Jun  4 11:24:29 2007
Completed redo application
Mon Jun  4 11:24:29 2007
Completed crash recovery at
Thread 1: logseq 1687, block 16224, scn 23317941
58 data blocks read, 58 data blocks written, 598 redo blocks read
Mon Jun  4 11:24:30 2007
Thread 1 advanced to log sequence 1688
Thread 1 opened at log sequence 1688
  Current log# 1 seq# 1688 mem# 0: /export/home1/oracle2/oradata/orclsun3/redo01.log
Successful open of redo thread 1
Mon Jun  4 11:24:31 2007
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Jun  4 11:24:31 2007
SMON: enabling cache recovery
Mon Jun  4 11:24:32 2007
Successfully onlined Undo Tablespace 1.
Mon Jun  4 11:24:32 2007
SMON: enabling tx recovery
Mon Jun  4 11:24:32 2007
Database Characterset is AL32UTF8
replication_dependency_tracking turned off (no async multimaster replication found)
WARNING: AQ_TM_PROCESSES is set to 0. System operation might be adversely affected.
Mon Jun  4 11:24:38 2007
db_recovery_file_dest_size of 2048 MB is 0.05% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Mon Jun  4 11:24:38 2007
Completed: ALTER DATABASE OPEN

wanufay

涉及的.trc文件为：
/export/home1/oracle2/OraHome5/admin/orclsun3/bdump/orclsun3_pmon_15813.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /export/home1/oracle2/OraHome5
System name:    SunOS
Node name:      e10k-2
Release:        5.9
Version:        Generic_118558-28
Machine:        sun4u
Instance name: orclsun3
Redo thread mounted by this instance: 1
Oracle process number: 2
Unix process pid: 15813, image: oracle@e10k-2 (PMON)

*** 2007-06-04 11:20:41.906
*** SERVICE NAMESYS$BACKGROUND) 2007-06-04 11:20:41.904
*** SESSION ID3000.1) 2007-06-04 11:20:41.903
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0xfffff901000002ce, PC: [0x104141ea4, kghxcu()+452]
*** 2007-06-04 11:20:41.922
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [kghxcu()+452] [SIGSEGV] [Address not mapped to object] [0xFFFFF901000002CE] [] []
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedmp()+744         CALL     ksedst()             000000480 ? 1066DE2AC ?
                                                   000000000 ? 1066DADA0 ?
                                                   1066D9B08 ? 1066DA508 ?
ssexhd()+1240        CALL     ksedmp()             000106400 ? 10652D164 ?
                                                   10652D000 ? 00010652D ?
                                                   000106400 ? 10652D164 ?
sigacthandler()+44   PTR_CALL 0000000000000000     10652A000 ? 1066E1EF0 ?
                                                   10652712C ? 00010652A ?
                                                   00000000B ? 000000067 ?
kghxcu()+452         PTR_CALL 0000000000000000     00000000B ? 1066E1EF0 ?
                                                   1066E1C10 ? 000000000 ?
                                                   105747E50 ? 106528F48 ?
kgllcu()+204         CALL     kghxcu()             106527B18 ? 5F2706B78 ?
                                                   5EAE604B0 ? 5F26FFB78 ?
                                                   3690100000000 ? 000003000 ?
kslilcr()+1084       PTR_CALL 0000000000000000     106527B18 ? 000000003 ?
                                                   5EAE604B0 ? 000000190 ?
                                                   000105400 ? 106528C08 ?
ksl_cleanup()+1880   CALL     kslilcr()            1065277D8 ? 5EAE604B0 ?
                                                   10574BA08 ? 10652A578 ?
                                                   10652A000 ? 106527000 ?
ksuxfl()+2256        CALL     ksl_cleanup()        5F34BF8F8 ? 10652A06C ?
                                                   000000050 ? 000000005 ?
                                                   000000000 ? 000000003 ?
ksuxda()+28          CALL     ksuxfl()             10652A000 ? 000000000 ?
                                                   380007774 ? 000000001 ?
                                                   000000000 ? 5F34BF810 ?
ksucln()+1684        CALL     ksuxda()             000000001 ? 000380007 ?
                                                   000380000 ? 000000000 ?
                                                   000000001 ? 380007720 ?
ksbrdp()+924         PTR_CALL 0000000000000000     5F78CDA10 ? 10652A000 ?
                                                   00010652A ? 04663850C ?
                                                   000106400 ? 10652A950 ?
opirip()+824         CALL     ksbrdp()             105F40000 ? 00038000E ?
                                                   10652A5B0 ? 105F40000 ?
                                                   000105F40 ? 100EE1AC0 ?
opidrv()+1204        CALL     opirip()             106534000 ? 000106400 ?
                                                   00010653C ? 380007000 ?
                                                   000106534 ? 1066E42B0 ?
sou2o()+80           CALL     opidrv()             106537360 ? 000000000 ?
                                                   000000032 ? 106534098 ?
                                                   000000032 ? 000000000 ?
opimai_real()+268    CALL     sou2o()              FFFFFFFF7FFFF918 ?
                                                   000000032 ? 000000004 ?
                                                   FFFFFFFF7FFFF940 ?
                                                   105E0F000 ? 000105E0F ?
main()+152           CALL     opimai_real()        000000003 ?
                                                   FFFFFFFF7FFFFA18 ?
                                                   000000000 ? 000000000 ?
                                                   00247D65C ? 000014800 ?
_start()+380         CALL     main()               000000001 ?
                                                   FFFFFFFF7FFFFB28 ?
                                                   000000000 ?
                                                   FFFFFFFF7FFFFA20 ?
                                                   FFFFFFFF7FFFFB30 ?
                                                   100000000 ?

qguang

They know this kind of shit better than anyone

ZALBB

最初由 shengang34 发布
[B]查看下SGA、缓存和IO，SGA和缓存不要设置的太大；

前几天遇到过这个问题，是在AIX上，原因是IO有瓶颈，所有的业务都在1个磁盘上跑，造成一个磁盘繁忙总在80％以上，后来把数据放在裸设备上，平均分配磁盘后解决这个问题。 [/B]

不明白你说的：所有的业务都在1个磁盘上跑　是什么意思？
难道数据不是存放在阵列上？

ZALBB

Subject:  ORA-600 [17147]
  Doc ID:  Note:138580.1 Type:  REFERENCE
  Last Revision Date:  25-MAY-2007 Status:  PUBLISHED


Note: For additional ORA-600 related information please read Note 146580.1

PURPOSE:            
  This article discusses the internal error "ORA-600 [17147]", what
  it means and possible actions. The information here is only applicable
  to the versions listed and is provided only for guidance.

ERROR:              
  ORA-600 [17147] [a] [c] [d] [e]

VERSIONS:           
  versions 7.0 to 9.2

DESCRIPTION:        

  Oracle has detected that the magic number in a memory chunk header has
  been overwritten.

  This is a heap (in memory) corruption and there is no underlying data
  corruption.

  The error may occur in the one of the process specific heaps
  (the Call heap, PGA heap, or session heap) or in the shared heap (SGA).
  
FUNCTIONALITY:      
  HEAP MANAGEMENT

IMPACT:            
  PROCESS FAILURE
  MEMORY CORRUPTION, POSSIBLE INSTANCE FAILURE.
  NON DATA CORRUPTIVE - No underlying data corruption.

SUGGESTIONS:

  Many are one time occurrances.

  Please see if the problem is reproducable.

  Have the hardware vendor check all system memory for possible errors.

  For repeatable occurrances, please submit the trace
  files and alert.log to Oracle Support Services for further analysis.

  Known Issues:

还有文档　Doc ID:  Note:403891.1 　说这是个BUG,在10202修复。
建议楼主还是开TAR吧，DBA解决不了这类问题。

shengang34

最初由 ZALBB 发布
[B]

不明白你说的：所有的业务都在1个磁盘上跑　是什么意思？
难道数据不是存放在阵列上？ [/B]

是在阵列上，但是当时用户在规划的时候没有考虑周全，划分VG的时候就只指定一个磁盘，所有的数据都放在这个VG上，所以造成我说的情况！

最后的结果就我上面所说的。。。

shengang34

sga_target = 10737418240

sga设置10G，是否太大？系统一共内存多少？缓存多少？？？？

有时候不是版本越高越好，如果条件允许，可以尝试在10。2。0。1下跑几天，有问题在升到10。2。0。2跑。。。

遇到过一次这样的情况，10。2。0。3下跑，老出问题，最后重装到10。2。0。1没有任何问题。。。

花好月不圆

Warning: MAX_SHARED_SERVERS (2000) > PROCESSES (500)
这个警告有点少见

wanufay

最初由 shengang34 发布
[B]sga_target = 10737418240

sga设置10G，是否太大？系统一共内存多少？缓存多少？？？？

有时候不是版本越高越好，如果条件允许，可以尝试在10。2。0。1下跑几天，有问题在升到10。2。0。2跑。。。

遇到过一次这样的情况，10。2。0。3下跑，老出问题，最后重装到10。2。0。1没有任何问题。。。 [/B]

我的机器是sun e10000，内存６４Ｇ，swap 87G,因此sga设置10G应该没什么问题吧？

Warning: MAX_SHARED_SERVERS (2000) > PROCESSES (500)是因为我将参数MAX_SHARED_SERVERS 设为了２０００，不知道这个会不会有影响？