oracle的dump命令

一.Memory Dumps 1).Global Area ALTER SESSION SET EVENTS ‘immediate trace name global_area level n’; 1 包含PGA 2 包含SGA 4 包含UGA 8 包含indrect memory 2).Library Cache ALTER SESSION SET EVENTS ‘immediate trace name library_cache level n’; 1 library cache统计信息 2 包含hash table histogram 3 包含object handle 4 包含object结构（Heap 0） 3).Row Cache ALTER SESSION SET EVENTS ‘immediate trace name row_cache level n’; 1 row cache统计信息 2 包含hash table histogram 8 包含object结构 4).Buffers ALTER SESSION SET EVENTS ‘immediate trace name buffers level n’; 1 buffer header 2 level 1 + block header 3 level 2 + block contents 4 level 1 + hash chain 5 level 2 + hash chain 6 level 3 + hash chain 8 level 4 + users/waiters 9 level 5 + users/waiters 10 level 6 + users/waiters 5).Buffer ALTER SESSION SET EVENTS ‘immediate trace name buffer level n’; n为某个指定block的rdba，该命令可以转储某个block在buffer中的所有版本。 6).Heap ALTER SESSION SET EVENTS ‘immediate trace name heapdump level level’; 1 PGA摘要 2 SGA摘要 4 UGA摘要 8 Current call(CGA)摘要 16 User call(CGA)摘要 32 Large call(LGA)摘要 1025 PGA内容 2050 SGA内容 4100 UGA内容 8200 Current call内容 16400 User call内容 32800 Large call内容 7).Sub Heap Oracle 9.0.1版本之前 ALTER SESSION SET EVENTS ‘immediate trace name heapdump_addr level n’; 若n为subheap的地址，转储的是subheap的摘要信息 若n为subheap的地址+1，转储的则是subheap的内容 Oracle 9.2.0版本之后 ALTER SESSION SET EVENTS ‘immediate trace name heapdump_addr level n, addr m’; 其中m为subheap的地址 n为1转储subheap的摘要，n为2转储subheap的内容 8).Process State ALTER SESSION SET EVENTS ‘immediate trace name processstate level n’; 9).System State ALTER SESSION SET EVENTS ‘immediate trace name systemstate level n’; 10).Error State ALTER SESSION SET EVENTS ‘immediate trace name errorstack level n’; 0 Error stack 1 level 0 + function call stack 2 level 1 + process state 3 level 2 + context area 11).Hang Analysis ALTER SESSION SET EVENTS ‘immediate trace name hanganalyze level n’; 12).Work Area ALTER SESSION SET EVENTS ‘immediate trace name workareatab_dump level n’; 1 SGA信息 2 Workarea Table摘要信息 3 Workarea Table详细信息 13).Latches ALTER SESSION SET EVENTS ‘immediate trace name latches level n’; 1 latch信息 2 统计信息 14).Events ALTER SESSION SET EVENTS ‘immediate trace name events level n’; 1 session 2 process 3 system 15).Locks ALTER SESSION SET EVENTS ‘immediate trace name locks level n’; 16).Shared Server Process ALTER SESSION SET EVENTS ‘immediate trace name shared_server_state level n’; n取值为1~14 17).Background Messages ALTER SESSION SET EVENTS ‘immediate trace name bg_messages level n’; n为pid+1 二.File Dumps 1).Block Oracle 7之前 ALTER SESSION SET EVENTS ‘immediate trace name blockdump level n’; n为block的rdba Oracle8以后 ALTER SYSTEM DUMP DATAFILE file# BLOCK block#; ALTER SYSTEM DUMP DATAFILE file# BLOCK MIN minimum_block# BLOCK MAX maximum_block#; 2).Tree Dump ALTER SESSION SET EVENTS ‘immediate trace name treedump level n’; n为object_id 3).Undo Segment Header ALTER SYSTEM DUMP UNDO_HEADER ‘segment_name’; 4).Undo for a Transaction ALTER SYSTEM DUMP UNDO BLOCK ‘segment_name’ XID xidusn xidslot xidsqn; 5).File Header ALTER SESSION SET EVENTS ‘immediate trace name file_hdrs level n’; 1 控制文件中的文件头信息 2 level 1 + 文件头信息 3 level 2 + 数据文件头信息 10 level 3 6).Control file ALTER SESSION SET EVENTS ‘immediate trace name controlf level n’; 1 文件头信息 2 level 1 + 数据库信息 + 检查点信息 3 level 2 + 可重用节信息 10 level 3 7).Redo log Header ALTER SESSION SET EVENTS ‘immediate trace name redohdr level n’; 1 控制文件中的redo log信息 2 level 1 + 文件头信息 3 level 2 + 日志文件头信息 10 level 3 8).Redo log ALTER SYSTEM DUMP LOGFILE ‘FileName’; ALTER SYSTEM DUMP LOGFILE ‘FileName’ SCN MIN MinimumSCN SCN MAX MaximumSCN TIME MIN MinimumTime TIME MAX MaximumTime LAYER Layer OPCODE Opcode DBA MIN FileNumber . BlockNumber DBA MAX FileNumber . BlockNumber RBA MIN LogFileSequenceNumber . BlockNumber RBA MAX LogFileSequenceNumber . BlockNumber; 其中time = (((((yyyy – 1988)) * 12 + mm – 1) * 31 + dd – 1) * 24 + hh) * 60 + mi) * 60 + ss; 9).Loghist ALTER SESSION SET EVENTS ‘immediate trace name loghist level n’; 1 dump控制文件中最早和最迟的日志历史项 1 dump 2^n个日志历史项 systemstate dump 介绍   当数据库出现严重的性能问题或者hang了的时候，我们非常需要通过systemstate dump来知道进程在做什么，在等待什么，谁是资源的持有者，谁阻塞了别人。在出现上述问题时，及时收集systemstate dump非常有助于问题原因的分析。        在一些情况下，数据库会自动生成systemstate dump, 比如出现了“WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK”。         systemstate dump大部分时候需要手工生成，具体的命令为： 如果连接很多，比如几千个连接，那么生成dump可能需要几十分钟，而且会占用几百M磁盘空间） 1. 用sysdba登录到数据库上： $sqlplus / as sysdba 或者 $sqlplus -prelim / as sysdba <==当数据库已经很慢或者hang到无法连接 SQL>oradebug setmypid SQL>oradebug unlimit; SQL>oradebug dump systemstate 266; 等1~2分钟 SQL>oradebug dump systemstate 266; 等1~2分钟 SQL>oradebug dump systemstate 266; SQL>oradebug tracefile_name;==>这是生成的文件名 2. 通常除了systemstate dump，最好同时生成hang analyze来直观地了解数据库进程间的等待关系。 $sqlplus / as sysdba 或者 $sqlplus -prelim / as sysdba <==当数据库已经很慢或者hang到无法连接 SQL>oradebug setmypid SQL>oradebug unlimit; SQL>oradebug dump hanganalyze 3 等1~2分钟 SQL>oradebug dump hanganalyze 3 等1~2分钟 SQL>oradebug dump hanganalyze 3 SQL>oradebug tracefile_name;==>这是生成的文件名 对于RAC数据库，需要各个实例在同一时间的systemstate dump,那么登录到任意一个实例（无需在所有实例执行）： $sqlplus / as sysdba 或者 $sqlplus -prelim / as sysdba <==当数据库已经很慢或者hang到无法连接 SQL>oradebug setmypid SQL>oradebug unlimit SQL>oradebug -g all dump systemstate 266  <==-g all 表示针对所有实例生成dump 等1~2分钟 SQL>oradebug -g all dump systemstate 266 等1~2分钟 SQL>oradebug -g all dump systemstate 266 在RAC上生成hang analyze: SQL>oradebug setmypid SQL>oradebug unlimit SQL>oradebug -g all hanganalyze 3 等1~2分钟 SQL>oradebug -g all hanganalyze 3 等1~2分钟 SQL>oradebug -g all hanganalyze 3 上面的命令执行后会在每个实例都生成systemstate dump，生成的信息放到了每个实例的backgroud_dump_dest下的diag trace文件中。 上面的这些命令执行三次是为了比较进程的变化情况，查看是真的hang了，还是很慢。 systemstate dump有多个级别： 2:     dump (不包括lock element) 10:   dump 11:   dump + global cache of RAC 256: short stack （函数堆栈） 258: 256+2   -->short stack +dump(不包括lock element) 266: 256+10 -->short stack+ dump 267: 256+11 -->short stack+ dump + global cache of RAC level 11和 267会 dump global cache, 会生成较大的trace 文件，一般情况下不推荐。 一般情况下，如果进程不是太多，推荐用266，因为这样可以dump出来进程的函数堆栈，可以用来分析进程在执行什么操作。 但是生成short stack比较耗时，如果进程非常多，比如2000个进程，那么可能耗时30分钟以上。这种情况下，可以生成level 10 或者 level 258， level 258 比 level 10会多收集short short stack, 但比level 10少收集一些lock element data. 另外对于RAC系统，请关注Bug 11800959 - A SYSTEMSTATE dump with level >= 10 in RAC dumps huge BUSY GLOBAL CACHE ELEMENTS - can hang/crash instances (Doc ID 11800959.8)。这个Bug在11.2.0.3上被修复，对于<=11.2.0.2的RAC，当系统中的lock element 很多的时候，如果执行level 10、266或者 267的systemstate dump时，可能会导致数据库hang或者crash，这种情况下可以采用level 258。 下面是生成systemstate dump的测试，用来查看每个level占用的空间： 这个例子中有37个进程： -rw-r----- 1 oracle oinstall    72721 Aug 31 21:50 rac10g2_ora_31092.trc==>256 (short stack, 每个进程2K) -rw-r----- 1 oracle oinstall  2724863 Aug 31 21:52 rac10g2_ora_31654.trc==>10    (dump，每个进程72K ) -rw-r----- 1 oracle oinstall  2731935 Aug 31 21:53 rac10g2_ora_32214.trc==>266 (dump + short stack ，每个进程72K) RAC: -rw-r----- 1 oracle oinstall 55873057 Aug 31 21:49 rac10g2_ora_30658.trc ==>11   (dump+global cache，每个进程1.4M) -rw-r----- 1 oracle oinstall 55879249 Aug 31 21:48 rac10g2_ora_28615.trc ==>267 (dump+global cache+short stack，每个进程1.4M) 所以，可以看出如果dump global cache(level 11和267，那么占用的空间比其他级别大很多）。