oracle的日志文件有以下几种: 警告日志,trace日志,audit日志,redo日志,归档日志 a.警告日志:也就是alert log,使用初始化参数 show parameter backgroud_dump_dest查看 b.trace日志:一般存放session追踪的信息,使用show parameter user_dump_dest查看 c.audit日志:审计的信息,对应系统初始化参数audit_file_dest d.redo日志:存放数据库的更改信息,select * fro

trc,trm文件介绍:trc:系统的跟踪文件(trace),当系统启动时或运行过程中出现错误时,系统会自动记录跟踪文件到指定的目录,以便于检查,这些文件需定期维护删除.trm:伴随着.trc文件产生,一个.trm对应一个.trc文件..trm文件包含.trc文件的结构化信息1.oracle用户登录数据库2.查看lsnrctl状态3.查看Trace Level字段,级别为0-16,当然级别越高,收集的信息就相对越全面,目前平台一天产生几个G的文件大小4.关闭监听日志跟踪文件,lsnrctl tr

1.转储指定的块:需要两个信息:文件号和块号 BYS@bys1>alter system dump datafile 1 block 100; System altered. 2.定位找出user tracefile的位置: BYS@bys1>show parameter user_dump_dest; NAME                                 TYPE        VALUE ------------------------------------ ----

注:本文为原著(其内容来自 腾科教育培训课堂).阅读本文注意事项如下: 1:所有文章的转载请标注本文出处. 2:本文非本人不得用于商业用途.违者将承当相应法律责任. 3:该系列文章目录列表: 一:<OCM 基本班课程表> 二:<OCM_第一天课程:OCM课程环境搭建> 三:<OCM_第二天课程:Section1 —>配置 Oracle 网络环境 > 四:<OCM_第三天课程:Section1 —>表空间的操作和管理.服务配置 > 五:<OC

http://blog.itpub.net/17203031/viewspace-772718/ Data Pump数据泵是Oracle从10g开始推出的,用于取代传统exp/imp工具的数据备份还原组件.经过若干版本的演进和修改,Data Pump已经非常成熟,逐渐被越来越多的DBA和运维人员接受. 相对于传统的exp/imp,Data Pump有很多优势,也变得更加复杂.数据泵一个最显著的特点就是Server-Side运行.Exp/Imp是运行在客户端上面的小工具,虽然使用方便,但是需要处理

SQL> show parameter dump NAME                                 TYPE        VALUE------------------------------------ ----------- ------------------------------background_core_dump                 string      partialbackground_dump_dest                

作为Oracle官方自带的一种基本性能诊断工具,SQL Trace可以用来评估当前正在运行的SQL语句的效率,同时为该语句生成统计信息等,并保存这些信息到指定路径下的跟踪文件(trace)当中.SQL Trace会将一条SQL语句或者PL/SQL包执行过程全部输出到跟踪文件(trace)当中,可以通过分析跟踪文件(trace)来分析SQL语句的执行效率并进行性能诊断与优化. 通常来说trace文件的内容不易于理解与阅读,Oracle官方还提供了工具tkprof对trace文件进行格式化处理,本文

1:数据安装操作练习:考试题目 1: Creating a database & Server Configuration --[101]-- #创建数据库 1. Create the database #使用dbca创建一个PROD1数据库,包括Sample Schema,启用archivelog,没有EM. 1.1 Create a PROD1 database with dbca, including Sample Schema, enable archivelog, without EM

注:本文为原著(其内容来自 腾科教育培训课堂).阅读本文注意事项如下: 1:所有文章的转载请标注本文出处. 2:本文非本人不得用于商业用途.违者将承当相应法律责任. 3:该系列文章目录列表: 一:<OCM 基本班课程表> 二:<OCM_第一天课程:OCM课程环境搭建> 三:<OCM_第二天课程:Section1 ->配置 Oracle 网络环境 > 四:<OCM_第三天课程:Section1 ->表空间的操作和管理.服务配置 > 五:<OC

http://www.orapub.cn/posts/1624.html 一.以下在Oracle APP中执行: 1) Set the Profile Option: ‘Initialization SQL Statement – Custom’ at the USER level to the following statement all on one line: 在用户层设置配置文件 Initialization SQL Statement – Custom的值为以下脚本(一般粘帖复制即可

思维导图 Oracle优化10-SQL_TRACE解读 Oracle优化11-10046事件 概述 当我们想了解一条SQL或者是PL/SQL包的运行情况时,特别是当他们的性能非常差时,比如有的时候看起来就好好像卡在什么地方一样,该如何入手呢? 是不是恨不得钻进去看下到底发生了什么? 好在Oracle提供了我们这样的一种方法使用SQL_TRACE来跟踪SQL的执行情况,通过SQLTRACE我们可以很容易的知道当前正在执行的SQL正在干什么. 以下操作基于Oracle Database 11g En

思维导图 10053事件概述 我们在查看一条SQL语句的执行计划时,只看到了CBO最终告诉我们的执行计划结果,但是我们并不知道CBO为何要这样做. 特别是当执行计划明显失真时,我们特别想搞清楚为什么CBO会做出这样的一个选择,那么就可以用10053事件来分析SQL分析过程的trace文件. 同10046事件一样,10053事件依然无法在官网上找到相关的信息. 10053事件为我们真正的揭开蒙在CBO身上的面纱. 如何做10053事件分析 Connected to Oracle Database

思维导图 Oracle优化10-SQL_TRACE解读 Oracle优化11-10046事件 概述 当我们想了解一条SQL或者是PL/SQL包的运行情况时,特别是当他们的性能非常差时,比如有的时候看起来就好好像卡在什么地方一样,该如何入手呢? 是不是恨不得钻进去看下到底发生了什么? 好在Oracle提供了我们这样的一种方法使用SQL_TRACE来跟踪SQL的执行情况,通过SQLTRACE我们可以很容易的知道当前正在执行的SQL正在干什么. 以下操作基于Oracle Database 11g En

1    说明 在11g中,查看GRID的日志,会进入$ORACLE_HOM/log. [grid@cndba.cn ~]$ cd $ORACLE_HOME/log/ [grid@cndba.cn log]$ ls crs  diag  rac1 [grid@cndba.cn log]$ cd rac1 [grid@cndba.cn rac1]$ ls acfs  admin  afd  alertrac1.log  client  crflogd  crfmond  crsd  cssd  c

一.前言 oracle这么一个庞大的东西,出点问题真是太常见了.开个博客,用于记录遇到的问题吧. 持续更新. 二.问题列表 归档日志满,引起的问题. 一台服务器,用了很久了,某天,出现了磁盘空间占满的问题,发现是大量的trc.trm文件.至于为啥会有大量的此类文件呢,因为归档日志空间满了. 后面dba使用rman删除了多余的归档日志,即恢复了. 优先查看trace下面的log文件(C:\app\Administrator\diag\rdbms\scm\scm\trace): 参考:https:/

在ORACLE数据库中,如果不对监听日志文件(listener.log)进行截断,那么监听日志文件(listener.log)会变得越来越大,想必不少人听说过关于"LISTENER.LOG日志大小不能超过2GB,超过会导致LISTENER监听器无法处理新的连接",当然这个不是真理,不会绝对出现,只是发生在老旧的32bit Linux或Unix系统下面,真实的原因是一些32bit OS自带的文件系统不支持2GB以上的文件,导致监听服务进程(tnslsnr)append write日志文件

温故而知新 SMON功能(一) SMON(system monitor process)系统监控后台进程,有时候也被叫做system cleanup process,这么叫的原因是它负责完成很多清理(cleanup)任务.但凡学习过Oracle基础知识的技术人员都会或多或少对该background process的功能有所了解. 曾几何时对SMON功能的了解程度可以作为评判一位DBA理论知识的重要因素,至今仍有很多公司在DBA面试中会问到SMON有哪些功能这样的问题.首先这是一道开放式的题目,并

掌握该技术最根本的是需要搞清楚session跟踪文件存放的路径和生成跟踪文件的命名规则,不然,在已经存在成全上万trc文件的生产环境中,要想快速正确的找到跟踪其他SESSION产生的trc文件就如大海捞针. 跟踪其它session,一般是根据sid+serial#进行跟踪,但trc文件生成的名称跟SID和Serial#无关系,只是根SPID有关系而已. 所以,搞清楚session跟踪文件存放的路径和生成跟踪文件的命名规则就非常重要了,下面来介绍一下. 1.  SESSION跟踪文件存放的路径 由

1.  先安装SQL Server 2008 R2或其他版本的数据库. 2.  打开profiler, 选择新建一个trace,连接到要监控的SQL Server数据库实例. 打开 SQL Server Mangement—>工具—>SQL Server Profiler,具体如下图:    3. 在通用界面下,输入trace名称,使用标准的模板.选择保存到文件,指定文件目录,设置文件最大size,勾上“enable file rollover(启用文件滚动更新)“和“server proce

sid_list=`/bin/ps -ef |/bin/grep smon |/bin/grep -v grep | /bin/cut -f3 -d_` host_name=`hostname` cdate=`date +%Y_%m_%d_%H_%M_%S` export ORACLE_BASE=/oracle export ORACLE_HOME=$ORACLE_BASE/admin #dumpfile tracefile  incident listener for sid in $sid_