不能連線資料庫收集Systemstate Dumps資訊
PURPOSE ------- The purpose of this note is to provide a method for taking system state dumps on the very rare occasions when connect internal is not possible. SCOPE & APPLICATION ------------------- This document is intended for Oracle database administrators and support analysts. Taking System State Dumps without Connecting to Oracle ------------------------------------------------------ If you are encountering a database hanging situation, you need to take system state dumps so that Oracle Support can begin to diagnose the cause of the problem. Whenever you take such dumps for a hang it is important to take at least 3 of them a few minutes apart, on all instances of your database. That way there is evidence showing whether a resource is still being held from one time to the next. Ordinarily, you can take a systemstate dump in the case of a hanging situation in one of two ways: 1. alter session set events 'immediate trace name SYSTEMSTATE level 10'; or 2. $ sqlplus connect sys/passwd as sysdba oradebug setospidoradebug unlimit oradebug dump systemstate 10 (Note, do not use any semi colons in oradebug. If using a version older than 9, you will need to use svrmgrl; connect internal) When using one of these two methods, be sure to disconnect and connect internal again in between dumps. That way each dump will be in a separate ora_ .trc trace file in your user_dump_dest. On very rare occasions it is not possible to make the svrmgrl or sqlplus connection necessary for issuing these commands. In that event, there is still a back door method of getting the systemstate dump using a debugger like dbx, if that is available on your system. The process you attach to will most likely dump core and be killed, so do not attach to an Oracle background process. Here is the syntax: dbx -a PID (where PID = any oracle shadow process) dbx() print ksudss(10) ...return value printed here dbx() detach First, you will need to find a shadow process: (saki) % ps -ef |grep sqlplus osupport 78526 154096 0 12:11:05 pts/1 0:00 sqlplus scott/tiger osupport 94130 84332 1 12:11:20 pts/3 0:00 grep sqlplus (saki) % ps -ef |grep 78526 osupport 28348 78526 0 12:11:05 - 0:00 oracles734 (DESCRIPTION=(LOCAL osupport 78526 154096 0 12:11:05 pts/1 0:00 sqlplus scott/tiger osupport 94132 84332 1 12:11:38 pts/3 0:00 grep 78526 You will attach to shadow PID 28348, enter the print ksudss (10) command when the prompt comes back, and detach: (saki) % dbx -a 28348 Waiting to attach to process 28348 ... Successfully attached to oracle. warning: Directory containing oracle could not be determined. Apply 'use' command to initialize source path. Type 'help' for help. reading symbolic information ... stopped in read at 0xd016fdf0 0xd016fdf0 (read+0x114) 80410014 lwz r2,0x14(r1) (dbx) print ksudss(10) 2 (dbx) detach You will find a systemstate in the user_dump_dest directory under the PID trace (and probably a useless core file as well). (saki) % ls -lrt *28348* -rw-r----- 1 osupport dba 46922 Oct 10 12:12 ora_28348.trc core_28348: total 72 -rw-r--r-- 1 osupport dba 16567 Oct 10 12:12 core drwxr-xr-x 7 osupport dba 12288 Oct 10 12:12 ../ drwxr-x--- 2 osupport dba 512 Oct 10 12:12 ./ You will find the usual header information in the trace file. On 7.3.4 OPS systems this will be followed by some lock information. Then the system state begins. On Oracle8 OPS and non-OPS systems, and on 7.3.4 non-OPS systems the system state immediately follows the header information. Here is the beginning of our dump: Dump file /oracle/mpp/734/rdbms/log/ora_28348.trc Oracle7 Server Release 7.3.4.4.1 - Production With the distributed, replication, parallel query, Parallel Server and Spatial Data options PL/SQL Release 2.3.4.4.1 - Production ORACLE_HOME = /oracle/mpp/734 System name: AIX Node name: saki Release: 3 Version: 4 Machine: 000089914C00 Instance name: s734 Redo thread mounted by this instance: 2 Oracle process number: 0 Unix process pid: 28348, image: ksinfy: nfytype = 0x5 ksinfy: calling scggra(&se) scggra: SCG_PROCESS_LOCKING not defined scggra: calling lk_group_attach() ksinfy: returning *** SESSION ID:(12.15) 2000.10.10.12.11.06.000 ksqcmi: get or convert ksqcmi: get or convert *** 2000.10.10.12.12.08.000 =================================================== SYSTEM STATE ..... Make sure there is an END OF SYSTEM STATE in the file. You can grep for it or do a search in vi. If it is not there then the dump is not complete, possibly because max_dump_file size is too small in the init.ora. Update for 10g and higher: In some cases, no connections are allowed on the instance (in some ORA-20 situations for example). As of 10.1.x, there is a new option with SQL*Plus to allow access to an instance to generate traces. sqlplus -prelim / as sysdba For example export ORACLE_SID=PROD ## Replace PROD with the SID you want to trace sqlplus -prelim / as sysdba oradebug setmypid oradebug unlimit; oradebug dump systemstate 10
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/15747463/viewspace-774064/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料庫連線不能建立.資料庫
- 不能建立sqlserver資料庫連線SQLServer資料庫
- 不能連線資料庫如何解決資料庫
- 收集資料庫統計資訊需要收集直方圖資訊.資料庫直方圖
- SQL 記錄資料庫連線數資訊SQL資料庫
- 6 收集資料庫統計資訊資料庫
- 用Navicat連線資料庫-資料庫連線(MySQL演示)資料庫MySql
- 連線資料庫資料庫
- 資料庫連線資料庫
- 通過Java程式測試資料庫連線資訊Java資料庫
- 通過連線檢視資料庫相關資訊資料庫
- 【SQL】Oracle資料庫資料量及效能資訊收集SQLOracle資料庫
- 【SCRIPT】Oracle資料庫基本資訊收集指令碼Oracle資料庫指令碼
- Script:收集資料庫安全風險評估資訊資料庫
- JDBC連線資料庫JDBC資料庫
- java連線資料庫Java資料庫
- Mybatis連線資料庫MyBatis資料庫
- Mongodb資料庫連線MongoDB資料庫
- mysqli連線資料庫MySql資料庫
- 資料庫的連線資料庫
- 連線mysql資料庫MySql資料庫
- 資料庫連線池資料庫
- 資料庫連線==odbc資料庫
- 資料庫連線字串資料庫字串
- jmeter連線資料庫JMeter資料庫
- 連線資料庫-mysql資料庫MySql
- 通過觸發器記錄資料庫連線資訊觸發器資料庫
- Windows平臺下不能建立資料庫連線出錯分析(2)Windows資料庫
- Windows平臺下不能建立資料庫連線出錯分析 (1)Windows資料庫
- 《四 資料庫連線池原始碼》手寫資料庫連線池資料庫原始碼
- 資料庫連線池-Druid資料庫連線池原始碼解析資料庫UI原始碼
- (轉)PHP連線資料庫之PHP連線MYSQL資料庫程式碼PHP資料庫MySql
- 資料庫不能直連怎麼造資料呢資料庫
- 如果ORACLE已經連線不上如果產生一個資料庫級別的systemstate dump檔案Oracle資料庫
- 資料來源連線資料庫資料庫
- [資料庫連線字串] Access 連線字串(轉)資料庫字串
- [資料庫連線字串]Access連線字串(轉)資料庫字串
- 各種連線資料庫的連線字串資料庫字串