标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,683)
- DB2 (22)
- MySQL (73)
- Oracle (1,545)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (68)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (565)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (79)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- ORA-15411: Failure groups in disk group DATA have different number of disks.
- 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理
- ORA-00227: corrupt block detected in control file
- 手工删除19c rac
- 解决oracle数据文件路径有回车故障
- .wstop扩展名勒索数据库恢复
- Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障(文件offline)
- OGG-02771 Input trail file format RELEASE 19.1 is different from previous trail file form at RELEASE 11.2.
- OGG-02246 Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
标签归档:ORA-600[729]
ORA-00600[729]分析和处理方法
alert中ORA-00600[729]
Fri Apr 6 04:30:04 2012 Errors in file /oracle9/app/admin/crm/udump/crm2_ora_2548236.trc: ORA-00600: internal error code, arguments: [729], [1067976], [space leak], [], [], [], [], []
a. the first bracketed number [729] is the common argument for space leak problems.
b. the second number [1067976] is the number of bytes leaked by the error.
c. the third argument is always [space leak].
分析trace文件
*** 2012-04-06 04:30:04.656 *** SESSION ID:(1361.35607) 2012-04-06 04:30:04.648 ******** ERROR: UGA memory leak detected 1067976 ******** ****************************************************** HEAP DUMP heap name="session heap" desc=1103a05f0
a. the memory was leaked from the UGA area
b. the amount leaked is reported again in the text (1067976 bytes).
c. the above few lines describe this dump as SESSION HEAP with the descriptor 0x1103a05f0.
计算泄露内存大小
****************************************************** HEAP DUMP heap name="session heap" desc=1103a05f0 extent sz=0xff80 alt=32767 het=32767 rec=0 flg=3 opc=3 parent=110009628 owner=700000c3b6f5620 nex=0 xsz=0xff80 EXTENT 0 addr=1107dbf50 Chunk 1107dbf60 sz= 65392 free " " EXTENT 1 addr=1107cbf50 Chunk 1107cbf60 sz= 65392 free " " EXTENT 2 addr=110541da0 Chunk 110541db0 sz= 61312 free " " EXTENT 3 addr=11062ae88 Chunk 11062ae98 sz= 266264 freeable "kllcqgf:kllsltb" EXTENT 4 addr=1105dae88 Chunk 1105dae98 sz= 266264 freeable "kllcqgf:kllsltb" EXTENT 5 addr=110550d48 Chunk 110550d58 sz= 266264 freeable "kllcqgf:kllsltb" EXTENT 6 addr=110500d48 Chunk 110500d58 sz= 266264 freeable "kllcqgf:kllsltb" EXTENT 7 addr=1104e1df0 Chunk 1104e1e00 sz= 200 perm "perm " alo=200 Chunk 1104e1ec8 sz= 65192 free " " EXTENT 8 addr=1104c1df0 Chunk 1104c1e00 sz= 40720 perm "perm " alo=40720 Chunk 1104cbd10 sz= 56 free " " Chunk 1104cbd48 sz= 408 freeable "kcbl_structure_" Chunk 1104cbee0 sz= 6952 free " " Chunk 1104cda08 sz= 2424 freeable "kllcqc:kllcqslt" Chunk 1104ce380 sz= 14832 free " " EXTENT 9 addr=1104d1df0 Chunk 1104d1e00 sz= 65392 free " " EXTENT 10 addr=1104b1df0 Chunk 1104b1e00 sz= 544 free " " Chunk 1104b2020 sz= 88 freeable "kllcqc:kllcq " Chunk 1104b2078 sz= 64760 free " " EXTENT 11 addr=110427390 Chunk 1104273a0 sz= 65392 free " " EXTENT 12 addr=110417390 Chunk 1104173a0 sz= 65392 free " " EXTENT 13 addr=110407390 Chunk 1104073a0 sz= 65392 free " " EXTENT 14 addr=1103f7390 Chunk 1103f73a0 sz= 65392 free " " EXTENT 15 addr=1103e7390 Chunk 1103e73a0 sz= 65392 free " " EXTENT 16 addr=1103d7390 Chunk 1103d73a0 sz= 65392 free " " EXTENT 17 addr=1103c7390 Chunk 1103c73a0 sz= 408 free " " Chunk 1103c7538 sz= 2232 perm "perm " alo=2232 Chunk 1103c7df0 sz= 62752 free " " EXTENT 18 addr=1103b7390 Chunk 1103b73a0 sz= 65392 free " " EXTENT 19 addr=110370080 Chunk 110370090 sz= 2008 perm "perm " alo=2008 Chunk 110370868 sz= 63384 free " " EXTENT 20 addr=110360098 Chunk 1103600a8 sz= 20424 perm "perm " alo=20424 Chunk 110365070 sz= 44944 free " " Total heap size = 2172616 FREE LISTS: Bucket 0 size=56 Chunk 1104cbd10 sz= 56 free " " Bucket 1 size=88 Bucket 2 size=152 Bucket 3 size=168 Bucket 4 size=280 Chunk 1103c73a0 sz= 408 free " " Bucket 5 size=432 Bucket 6 size=536 Chunk 1104b1e00 sz= 544 free " " Bucket 7 size=1048 Bucket 8 size=2072 Bucket 9 size=4120 Chunk 1104cbee0 sz= 6952 free " " Bucket 10 size=8216 Chunk 1104ce380 sz= 14832 free " " Bucket 11 size=16408 Bucket 12 size=32792 Chunk 110365070 sz= 44944 free " " Chunk 110370868 sz= 63384 free " " Chunk 1104d1e00 sz= 65392 free " " Chunk 1103b73a0 sz= 65392 free " " Chunk 1103c7df0 sz= 62752 free " " Chunk 1103d73a0 sz= 65392 free " " Chunk 1103f73a0 sz= 65392 free " " Chunk 1104073a0 sz= 65392 free " " Chunk 1104b2078 sz= 64760 free " " Chunk 1103e73a0 sz= 65392 free " " Chunk 1104e1ec8 sz= 65192 free " " Chunk 1104273a0 sz= 65392 free " " Chunk 1104173a0 sz= 65392 free " " Chunk 1107cbf60 sz= 65392 free " " Chunk 110541db0 sz= 61312 free " " Chunk 1107dbf60 sz= 65392 free " " Bucket 13 size=65560 Bucket 14 size=131096 Bucket 15 size=262168 Bucket 16 size=524312 Bucket 17 size=2097176 Total free space = 1039056 UNPINNED RECREATABLE CHUNKS (lru first): PERMANENT CHUNKS: Chunk 1104e1e00 sz= 200 perm "perm " alo=200 Chunk 1104c1e00 sz= 40720 perm "perm " alo=40720 Chunk 1103c7538 sz= 2232 perm "perm " alo=2232 Chunk 110370090 sz= 2008 perm "perm " alo=2008 Chunk 1103600a8 sz= 20424 perm "perm " alo=20424 Permanent space = 65584 ******************************************************
FREEABLE and RECREATABLE chunks总和等于1067976 byte(leaked memory)
会话状态分析
*** 2012-04-06 04:30:04.658 ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [729], [1067976], [space leak], [], [], [], [], [] ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedmp+0148 bl ksedst 1029746FC ? ksfdmp+0018 bl 01FD4014 kgeriv+0118 bl _ptrgl kgesiv+0080 bl kgeriv 000000001 ? 000000002 ? 1100610D0 ? 000000000 ? 00000000A ? ksesic2+005c bl kgesiv FFFFFFFFFFF9320 ? 1101FAF78 ? 110006308 ? 1103A0818 ? 000000009 ? ksmuhe+026c bl ksesic2 2D9000002D9 ? 000000000 ? 000104BC8 ? 000000001 ? 00000000A ? 103164968 ? 12E0BE826D694B2F ? 000000000 ? ksmugf+0214 bl ksmuhe 110002A20 ? 110061238 ? 000000009 ? 102975DE8 ? ksuxds+170c bl ksmugf 000000000 ? 020000000 ? 1029754D0 ? ksudel+006c bl ksuxds 700000C3B6F5620 ? 100000001 ? opilof+03dc bl 01FD427C <--表示logoff opiodr+08cc bl _ptrgl ttcpip+0cc4 bl _ptrgl opitsk+0d60 bl ttcpip 11000CF90 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? opiino+0758 bl opitsk 000000000 ? 000000000 ? opiodr+08cc bl _ptrgl opidrv+032c bl opiodr 3C00000018 ? 4101FAF78 ? FFFFFFFFFFFF7B0 ? 0A000F350 ? sou2o+0028 bl opidrv 3C0C000000 ? 4A00E8B50 ? FFFFFFFFFFFF7B0 ? main+0138 bl 01FD3A28 __start+0098 bl main 000000000 ? 000000000 ? --------------------- Binary Stack Dump --------------------- ……………… ---------------------------------------- SO: 700000c3b6f5620, type: 4, owner: 700000c3c987a18, flag: INIT/-/-/0x00 --flag: (41) USR/- BSY/-/-/DEL/-/- shows that the session has been deleted (session) trans: 0, creator: 700000c3c987a18, flag: (41) USR/- BSY/-/-/DEL/-/- DID: 0002-0927-01D67CAD, short-term DID: 0000-0000-00000000 txn branch: 0 oct: 0, prv: 0, sql: 700000caf2c0e30, psql: 700000caf2c0e30, user: 52/MONITOR O/S info: user: oracrm, term: , ospid: 1490968, machine: zwq_crm2 program: exp@zwq_crm2 (TNS V1-V3) last wait for 'SQL*Net message from client' blocking sess=0x0 seq=59222 wait_time=1537 driver id=54435000, #bytes=1, =0 temporary object counter: 0 ----------------------------------------
a.在logoff的时候发生UGA中的session heap发生内存泄露
b.该进程是一个exp导出数据库程序,并且该程序已经被释放
出现ORA-00600[729]原因
Memory leak problems generally occur when Oracle is trying to free memory allocated to a process. The memory leak dump is generally discovered during session logoff, when Oracle frees the heaps that are allocated for the user process. When a user connects to Oracle, a user process is created and at that time the heap is allocated. Every process will have its own memory heap. The memory is organized in to heaps and every heap consists of one or more extents. Each extent contains a series of contiguous memory chunks, and these chunks can be either FREE or ALLOCATED. The Generic Heap Manager takes care of allocating and deallocating the memory chunks, with the help of FREE LISTS and LRU LISTS. Chunk types are as follows: 1. FREE 2. FREEABLE 3. RECREATABLE 4. PERMANENT 5. FREEABLE WITH MARK It is not mandatory that each extent contain only one type of chunk. Extents can contain various types of chunks. When processes require memory chunks, they are allocated as needed. Oracle keeps track of the amount of memory allocated for the process internally. When the process terminates, all of the memory that has been allocated for the process is automatically released. When the memory is released the allocated heaps are freed. Generally, when the heap is freed the only chunks that the process should identify as allocated are the PERMANENT chunks and FREE chunks on the freelist. If the process finds there are still FREEABLE or RECREATABLE chunks remaining, then the process has not properly deallocated the memory. This situation is considered a space leak.
ORA-00600[729]处理方案
1. If there are no other errors reported at the same time, this may be a case where the error was a rare occurrence and can be safely ignored. As a rule of thumb, leaks less than 90,000 bytes in size are considered to be of low significance. The solution in this case is to set event 10262 (see below). a. Set the following event in init.ora parameter file. This example disables reporting for space leaks less than 90000 bytes: event = "10262 trace name context forever, level 90000" b. Stop and restart the database. If the level is set to 1, space leak checking is disabled. This is not advised because large memory leaks will be missed. If the event is set to a value greater than 1, any space leak up to the number specified in the event is ignored. 2. Is the leak in the SGA? The alert.log should be reviewed for additional errors such as ORA-4030 and ORA-4031 to ensure there are no additional problems with the shared pool or operating system memory. 3. Does the error reproduce with a given task? If so, this is a case that should be investigated further because the leak could be a known bug. See Note 31056.1 ORA-600 [729] UGA Space Leak for a list of known bugs and fixes.
参考:Understanding and Diagnosing ORA-600 [729] Space Leak Errors [ID 403584.1]