|
|
马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。如果您注册时有任何问题请联系客服QQ： 83569622 。
您需要 登录 才可以下载或查看，没有帐号？注册
x
如何查看trace文件
====================
如何去读取core跟踪文件
====================
This article will discuss what a core dump is, and what should be done if you
receive a core dump from an Oracle product.
Problem Explanation:
====================
A core dump is an image copy of the state of a process, which is produced if
the process attempts to do something not allowed by the Operating System. The
process information is written to a file named "core", which is usually
created in the current working directory of the process.
Some of the things a program might attempt to do that would cause a core dump
include: trying to execute an illegal/unknown instruction, trying to access
memory outside the allowed range, or trying to use an unavailable resource.
A core file contains much information to aid in determining why a process
crashed. One of the things contained in a core file is a called stack trace,
which identifies what commands a process has, or was attempting to execute.
Sometimes a trace file is automatically produced by an Oracle process, and is
normally indicated with an ORA-07445 error. When this occurs, a file with the
extension ".trc" will be produced. To find this file, check your
init<SID>.ora for the parameters "user_dump_dest" and "background_dump_dest".
The trace file will typically be located in one of these directories.
A trace file is not always produced automatically, and the solution of this
article will discuss how to manually produce a call stack trace.
Search Words:
=============
segmentation fault
ORA-7445
dbx gdb dde adb sdb debug
debugger
Solution Description:
=====================
Before attempting to manually create a stack trace from a core file, please
verify the following:
* Your swap space is 2 to 3 times the amount of physical memory (RAM)
installed on the system, or whichever is greater of the following
2 items: 1GB or 2 times the size of all SGAs combined.
You can approximate the size of an SGA with this formula:
((db_block_size * db_block_buffers)+shared_pool+log_buffers)/.9
For help with how to check swap space, refer to PRE 1016233.6.
* You are using a supported compiler/linker. Check the Installation
Guide for Operating System requirements.
NOTE: On Solaris systems, make sure that "/usr/ccs/bin" is
before "/usr/ucb" in the PATH environment variable.
You can confirm this using the following command:
% which ld
The path returned should be "/usr/ccs/bin/ld".
* You have at least 50MB of free space available in "/tmp".
Creating a Stack Trace from a Core File
=======================================
To create a stack trace from a core file, perform the following steps:
1. Determine which executable program caused the core dump:
To determine which executable caused a core dump, change to the
directory where the core file is located, and use the "ile"
command.
For example, if you had a core file in your home directory,
"/home/user", use the following commands:
% cd /home/user
% file core
core: ELF 32-bit MSB core file SPARC Version 1, from 'sqlplus' --这里from后面是引起core的源头
The "rom" information indicates that 'sqlplus' caused the core
dump.
(a) If your system does not display "rom" information when using
the "file" command, and your are NOT using SCO UNIX, try the
following command instead:
% cd /home/user
% strings core | head -10
CORE
CORE
CORE
sqlplus <<----- first executable program
sqlplus
-h system-23_getm TERM=xterms
console
ORACLE_HOME
guicommon/tk2
/SQLPlus/mesg/SP2US.msb
This will display the first 10 text entries in the core file.
Start at the first line and look for an entry which is an
executable program. In the example above, 'sqlplus' caused
the core dump.
(b) If you are using SCO UNIX, use the following command instead:
% cd /home/user
% strings core | head -75 | tail -25
2. Determine which debugger exists on your system.
There are many different debuggers in the UNIX world. Look at
the list below of the most common debuggers, then check your
system for one of them.
Common debuggers
================
dbx, gdb, dde, adb, sdb, debug
If these debuggers exist on your system, they would most
likely be located in one of the following directories:
/bin, /usr/bin, /opt/langtools/bin, /usr/ccs/bin, /usr/ucb
To search your system for a debugger, you can use the "which"
command, which will search only the directories in your current
PATH, or the "find" command, which can search the entire system.
For example, to search for the dbx debugger:
% which dbx
no dbx ...
% find / -name "bx" -print
/usr/ccs/bin/dbx
3. Now that you have located a debugger, you are ready to use it
to produce the stack trace. The Unix command "script" will
capture the output of a terminal session and write it to a file.
You will use "script" to capture the output of the debugger as
shown below.
First change directories to the location where the core file is
located.
4. The next step depends upon which debugger you are using:
(a) If you are NOT using the "de" or "ebug" debugger, do this:
------------------------------------------------------------
% script mystack.trc
% <debugger> $ORACLE_HOME/bin/<executable> core
where <debugger> is the debugger you are using, and <executable>
is the executable program which caused the core dump.
(b) If you are using the "dde" debugger, use this command:
------------------------------------------------------
% script mystack.trc
% dde -ui line core $ORACLE_HOME/bin/<executable>
(c) If you are using the "debug" debugger, use this command:
--------------------------------------------------------
% script mystack.trc
% debug <display option> -c core $ORACLE_HOME/bin/<executable>
where <display option> is not entered, unless "debug" starts
an X window session, in which case <display option> equals
"-i c".
5. Now look at the table below and find your debugger in the first
column, then enter the command in the second column to produce the
stack trace.
debugger command to produce stack
======== ========================
dbx where
gdb bt
dde tb
adb $c
sdb t
debug stack
6. Exit the debugger program:
- if you are using the "adb" debugger, exit using <Ctrl>
- if you are using any of the other debuggers, exit with the
command "q"
7. After exiting the debugger, issue the command "exit" at the shell
prompt. You should receive a "Script Done" message.
You now have a stack trace in the file named "mystack.trc", and you can send
this file to Oracle Support for further analysis.
Solution Explanation:
=====================
The call stack trace in the "mystack.trc" file can be useful to Oracle Support
in determining why a core dump from an Oracle product occurred.
==================
Call Stack
==================
查看错误的方法
一般忽略前面2到3个功能
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp+0148 bl ksedst 1024F568C ?
ksfdmp+0018 bl 01FDAAFC
kgeriv+0118 bl _ptrgl
kgesiv+0080 bl kgeriv FFFFFFFFFFFFED0 ?
9FFFFFFF0007EF0 ?
BADC0FFEE0DDF00D ?
BADC0FFEE0DDF00D ?
BADC0FFEE0DDF00D ?
ksesic3+005c bl kgesiv BADC0FFEE0DDF00D ?
BADC0FFEE0DDF00D ?
BADC0FFEE0DDF00D ?
000000000 ? 110580178 ?
ksmdpg+039c bl ksesic3 2D3000002D3 ? 000000000 ?
0000028B8 ? 000000000 ?
0000028B8 ? 000000001 ?
00000000B ? 102C760F4 ?
opidcl+0234 bl 01FDAC58
opidrv+045c bl opidcl 11000C5C8 ? 000000000 ?
sou2o+0028 bl opidrv 32003FBE38 ? 0A020FA78 ?
000000000 ?
main+01a4 bl 01FDA6C0
__start+0090 bl main 000000000 ? 000000000 ?
ksedmp,ksfdmp,kgeriv可以忽略
操作系统错误一定要看/var/adm/ras/errlog或者errpt,solaris下是/var/adm/message
==================
600错误
==================
1.1 Abstract
============
This documents provides guidelines for customers to be able to do an initial analysis of
problems related to internal errors (ora-600) and core dumps (ora-7445) with the use of
Metalink by searching for the relevant keywords. After finding a set of documents, either
bug database entries or notes, these must be correlated to the specific circumstances
to further narrow down the search results. Hints to do this are given.
1.2 Introduction
=================
It is often the case that certain problems have been already discovered earlier and
are documented in Metalink notes and in published bug information. With the proper
techniques it is often possible to narrow down on a particular bug that matches your
problem and find documented workarounds or patch information. This document is mainly
aimed at rediscovering bugs in Oracle code that cause internal errors or core dumps
but it may be equally applicable to all kinds of problems that may be encountered.
The following paragraphs aim at extracting the relevant keywords out of the trace
file to find the documents that are relevant to the specific error condition. It also
tries to help in further narrowing down the list of relevant documents by correlating
them to the specific circumstances of the error.
Fix
2.1 ORA-00600: internal error code, arguments: [argument1] [argumentX] ....
==========================================================================
The internal argument ora-600 is raised within the Oracle kernel when an exceptional
condition occurs, inside the kernel code at various stages of processing, so called
assertions are executed, these are certain conditions that must be true to be able
to proceed. The assertions are internal health checks and guard over the integrity
of memory and data of the instance and the database. When such an assertion fails, an
ora-600 error is raised with either a numeric or alphanumeric first argument and
possibly more arguments depending on the particular error. Note that not all internal
errors ora-600 are necessary fatal errors causing the session to terminate, some are
quite benign, others however can be severe so they must always be carefully investigated.
--有些600错误是良性的，有些是严重的
2.1.1 The first argument of the internal error ora-600
======================================================
The single most important piece of information is the first argument of the internal
error, either numeric or alphanumeric, it uniquely identifies the specific module
where it was raised and what assertion was failing, always include this first argument
in your keyword search when trying to rediscover known problems.
2.2 ORA-07445: exception encountered: core dump
==============================================
A core dump is an exceptional condition similar to the internal error ora-600, however,
the big difference being that the kernel did not anticipate the error, while in the case
of the internal error the exceptional condition was discovered by an assertion which is a
predefined check, the core dump happens because the operating system at some point aborts
the process because it is doing a forbidden action such as trying to access an area of
memory that does not belong to the process, this is why core dumps are often referred to
as access violations. The term 'core dump' stems from a period when memory was stored with
the use of magnetic cores, in computer terminology 'core' equates to 'memory'. A core
dump means that the memory of the process was dumped in a file 'core' on the file system.
--是由于如做了一些禁止的动作（象一个进程访问了不属于自己进程的内存区域）使操作系统中断
'core' ='memory'
2.2.1 Identify the failing module
=================================
It is important to know in what internal module the core dump occurs, this is often printed
together with the error but not always, if not refer to the section 3.2.5 Call Stack Trace,
at any rate, if known include the failing module in your keyword search.
3.1 Trace files
===============
For both internal errors and core dumps a trace file is written in either user_dump_dest for
user processes and background_dump_dest for background processes, the trace files for both
types are treated in the same manner although the particular information in the trace files,
whether a certain section is present, may depend on the particular error. In case of a core
dump it is possible for the kernel to still dump relevant information by calling the dump
routines such as ksedmp() because the error is trapped by a signal handler, on the other
hand, for most internal errors, the process is crashed (aborted) when the dump is ready.
3.2 Relevant sections in Trace files
====================================
While not intended to provide a detailed explanation or in depth understanding, the following
sections in the trace file can usually be identified, this will help you to glean the relevant
keywords for the search and understand the specific conditions under which the error
occured, you should then be able to narrow down on your search results.
3.2.1 Header
============
The header section includes such information as the name of the trace file, the specific oracle
version, ORACLE_HOME ,system name, node name, OS version, instance name and process
information, while not directly relevant for your keyword search it is vital later to correlate
the documents to your problem.
3.2.2 Error Section
===================
The error as it was written in the alert.log is usually repeated possibly along with some
extra information dependent on the error, when an internal error occurs, a developer
may have decided to write some crucial state information apart from the ora-600 arguments
directly to the trace file, when this is the case, those are usually gems for your search.
3.2.3 Current SQL statement for this session
============================================
You may or may not know what was being conducted at the time of the error, while common keywords
like 'insert', 'update' or 'delete' may not be beneficial to your search (they are simply too
common) this is of course very useful to correlate documented rediscovery information to your
problem. If for example a certain bug has in its rediscovery information that it happens
on insert only and you are performing a delete statement, then it is safe to say that this bug is not your problem.
See also 3.2.6 Cursor Dump in case the current sql statement is not present in the trace file.
3.2.4 PL/SQL Call Stack
=======================
This section is present if the session was performing pl/sql, it shows what user or internal
pl/sql packages where called, Call Stacks are read bottum up, if there are Oracle packages in
there, include them in your keyword search.
3.2.5 Call Stack Trace
======================
The modules listed in the call stack trace provide excellent keywords that can be used for
rediscovery, they usually uniquely identify specific bugs, however, care must be taken to
discard the top and bottom modules. Modules such as the following must be ignored : sigacthandler(),
ssexhd(), ksedmp(), ksesicX(). (where X is a number that designates the number of extra arguments
to an ora-600 besides the first). All kse* and kge* modules in general can be ignored, they stand for
Kernel Service Error and Kernel Generic Error respectively, these are modules that are invoked AFTER
the error has occurred and perform such tasks as dumping the trace file and as such are common to
most internal errors and core dumps and will not help in narrowing down your search. The same goes
for the bottom modules that are always present because they are used to initiate process startup,
everyting below (and including) opiexe() can safely be ignored. When you include three or four
relevant modules from the top of the call stack trace (together with some other relevant keywords),
this will usually result in the relevant documents to pop up on a Metalink search, if none are
returned you may have to reduce the number of modules searched upon, removing the modules
further down the stack from the search. If you still have no results returned you may have hit
upon a yet undiscovered problem.
3.2.6 Cursor Dump
=================
Even when the current sql statement is not listed in the top section of the trace file together with
the error, the cursor dump can still reveal the sql statement being performed at time of error. Simply
search for 'current cursor' identify the cursor number and scroll down until you find the cursor with that
number, as a bonus you may also be able to identify the bind variables (if any) used for the statement
in this section. See Note:154170.1 for further information.
--查找current cursor
3.2.7 Process State - Session State Object
==========================================
A process state is a list of the process state objects, it is beyond the scope of this document to
explain these in detail, for now it is enough to understand that state objects are used to organize
memory objects that contain the relevant state information of a session in an hierarchical manner, one
of the state objects contains relevant session information that helps in narrowing down the specifics
of the error condition. Simply search for 'program' in your trace file and you will find a section
similar to the following :
--查找program看是由于什么类型的程序造成的，如OCI ，JDBC
SO: 7000000223acfe0, type: 4, owner: 700000022357868, flag: INIT/-/-/0x00
(session) trans: 7000000230d47a0, creator: 700000022357868, flag: (18100041) USR/- BSY/-/-/-/-/-
DID: 0001-0012-00000083, short-term DID: 0000-0000-00000000
txn branch: 0
oct: 2, prv: 0, sql: 70000002831a5a0, psql: 70000002831a5a0, user: 48/ISIS
O/S info: user: someuser, term: SOMETTY01, ospid: 628:1948, machine: BOX\SOMETTY01
program: someprogram.exe
application name: someprogram.exe, hash value=0
last wait for 'db file sequential read' blocking sess=0x0 seq=1054 wait_time=16729
file#=1, block#=2ec3, blocks=1
temporary object counter: 0
When a specific program is being used, you may want to include that in your keyword search, whether it
is an oracle client program or not, we sometimes provide information on third party products in relation
to Oracle on an 'as is' basis. Try to identify what type of program is being used, these include JDBC
(thin or OCI), Pro*C, OCI etc. Some problems are for example specific to JDBC, that will help greatly in
identifying the problem.
4.1 Use 'Advanced Search'
=========================
To find relevant bug database entries (more likely to contain call stack trace modules) always perform
the Advanced search and make sure to check the 'Bug Database' check box from the 'sources' section on
the right of the page, in addition to the 'Knowledge Base' that are the Notes written by Oracle personnel.
Uncheck the 'Technical Forum' checkbox at first, when nothing is found in the knowlege base and bug database,
some relevant info maybe found in the forums (this is not to downplay the forums, they just have a different
use). The tips on the advanced search page provide further guidelines on how to search efficiently.
4.2 General Comments on keyword searches
========================================
The important thing is: trial and error, when a search returns an overwhelming mount of documents, try to
narrow down by including another keyword that is unique to your problem, on the other hand, when no results
are returned, omit a few, if you have included too many modules from a call stack trace, delete some from
your search but retain the topmost module(s), the specific module may have been called from a different one
to yours when the bug was discovered or the call stack trace was not clearly documented in the bug.
4.3 No relevant bug or document is found
========================================
You may of course be the first customer to have hit upon a yet undiscovered problem, in that case, file a
service request using Metalink and try to describe in detail what is the problem, you may also include
a summary of the analysis that you have already performed based on the these guidelines.
4.4 Provide Feedback
====================
If you find documents that are unclear or you think contain errors, or if you think you can add some relevant
information based on your experience using our products, please use the feedback button and state the
document number and your comment (use the 'Technical Library feedback/questions' radio button in step 2).
We are very grateful for quality feedback as it improves our knowledge base.
5.1 Correlate bugs and documents to your problem
================================================
Now that you have gained more understanding of the problem by browsing through the trace files relevant
sections, identified sufficiently suitable keywords both in terms of quantity and quality (uniqueness),
you fired your search and you are presented with some relevant documents. The Notes are usually clear enough,
they go through a well defined process of QA and will provide you with detailed circumstances to match your problem.
Bugs can be more cumbersome to read, try scrolling down to the bottom immediately (click 'Go to End') to find the
'rediscovery' or 'release note' section (or search for it) to match the bug description with your specifics. A closed
published bug should have such a section unless it is a duplicate of another bug, in that case the base bug
must be checked for it. You are hitting a certain bug if you can match all circumstances listed in the rediscovery
information to your problem AND the designated fix (either a patch or workaround) solves the problem.
6.0 Summary
===========
Good search keywords include error messages, first arguments of internal errors and relevant internal
module names, program names and type may narrow down additionally. Correlate with the documented
rediscovery information. If unsure, file a service request with your findings, this helps the analyst.
====================
7445 lookup
====================
http://metalink.oracle.com/metal ... NOT&id=208922.1
=====================
DUMP 本地管理的临时表空间文件
ALTER SYSTEM DUMP TEMPFILE 'E:\ORACLE\ORADATA\ORC9\sk_TEMP.DBF' BLOCK 1;
=====================
=====================
DUMP 日志
=====================
The 'alter session' command is used to dump redo headers.
Use the 'alter system dump logfile' to dump log file contents.
只要操作系统是一样的，可以在另一个数据库发送该命令
~~~~~~~~~~~~~~~
常用的语句和方法
1. To dump records based in DBA (Data Block Address)
2. To dump records based on RBA (Redo Block Address)
3. To dump records based on time
4. To dump records based on layer and opcode
5. Dump the file header information
6. Dump an entire log file:
1. To dump records based on DBA (Data Block Address)
--------------------------------------------------
他将dump出指定范围的块的信息
From sqldba or svrmgr, issue the following command:
ALTER SYSTEM DUMP LOGFILE 'filename'
DBA MIN fileno . blockno
DBA MAX fileno . blockno;
Example:
========
ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V7323/dbs/arch1_76.dbf'
DBA MIN 5 . 31125
DBA MAX 5 . 31150;
This will cause all the changes to the specified range of data blocks to be
dumped to the trace file. In the example given, all redo records for file #5,
blocks 31125 thru 31150 are dumped.
2. To dump records based on RBA (Redo Block Address)
-------------------------------------------------
查看所有重做记录信息
This will dump all redo records for the range of redo
addresses specified for the given sequence number and block number.
Syntax:
ALTER SYSTEM DUMP LOGFILE 'filename'
RBA MIN seqno . blockno
RBA MAX seqno . blockno;
Example:
ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V7323/dbs/arch1_76.dbf'
RBA MIN 2050 . 13255
RBA MAX 2255 . 15555;
3. To dump records based on time.
------------------------------
DUMP出指定时间段间的重做信息
Using this option will cause redo records created within the time range
specified to be dumped to the trace file.
From sqldba or svrmgr, issue the following command:
ALTER SYSTEM DUMP LOGFILE 'filename'
TIME MIN value
TIME MAX value;
Example:
========
ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V7323/dbs/arch1_76.dbf'
TIME MIN 299425687
TIME MAX 299458800;
Please Note: the time value is given in REDO DUMP TIME
4. To dump records based on layer and opcode.
------------------------------------------
该语句可以dump出指定操作类型和记录类型
LAYER and OPCODE are used to dump all log records for a particular type of
redo record, such as all dropped row pieces.
From sqldba or svrmgr, issue the following command:
ALTER SYSTEM DUMP LOGFILE 'filename'
LAYER value
OPCODE value;
Example:
========
ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V7323/dbs/arch1_76.dbf'
LAYER 11
OPCODE 3;
5. Dump the file header information:
---------------------------------
This will dump file header information for every
online redo log file.
From sqldba or svrmgr, issue the following command:
alter session set events 'immediate trace name redohdr level 10';
6. Dump an entire log file:
------------------------
From sqldba or svrmgr, issue the following command:
ALTER SYSTEM DUMP LOGFILE 'filename';
Please note:
Fully qualify the filename, and include the single quotes.
Example:
========
ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V7323/dbs/arch1_76.dbf'; |
|
|Archiver|小黑屋|手机版|壹佰网 ERP100
( 京ICP备19053597号-2 )
IP卡
狗仔卡
发表于 2008/6/28 16:28:08
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主