服务器打开警报就不显示日志,跟踪日志和警报日志

1.警报日志*

(在这个目录下/opt/oracle/admin/SONE/bdump，然后 vi alert_sone.log 可以查看日志内容，这是第一种方法)

alert*.log 在background_dump_dest oracle系统日志

警告日志中包括各种提示性日志信息和各种警告、错误信息。

它的名字是alert_数据库SID.log，它的位置用初始化参数background_dump_dest设置.

利用文本编辑器的搜索功能,在警告日志中快速查找信息.

如:

(1)坏块错误ORA-1578或ORA-1498。即数据文件产生了坏块

(2)在线日志切换间隔

(3)数据库启动参数

(4)在数据库启动后,又做了什么主要的操作,增加了什么东西

(5)Oracle认为需要让DBA知道的警告和错误信息。如：

Mon Oct 13 20:03:27 2008

ARC0: Archiving not possible: No primary destinations

ARC0: Failed to archive thread 1 sequence 1636

(6)检查点信息。当log_checkpoints_to_alert参数设为真时，

检查点信息会被记入告警日志。

如果你想详细观察检查点的行为，将此参数设为真是很有帮助的。

如果你并不打算详细了解检查点的行为，保留此参数为假就行。

因为当此参数为真时，

这加重了Oracle对告警日志写操作的负担。

redo block address (这是RBA的意思)

alter system checkpoint

(7)最后一次的启动时间

DBA应该每日查看警告日志,发现问题,解决问题.

2.跟踪文件*

background_dump_dest

user_dump_dest

*****目的：(1)获取用户操作SQL  (2)获取SQL的统计信息：statistics和等待事件：wait event

下面主要研究用户的跟踪文件

(1)

sys:

[alter system set sql_trace=true scope=both; ]

grant select any dictionary to scott;

grant alter session to scott;

sqlplus scott/tiger

alter session set sql_trace=true;

select count(*) from  emp;

update emp set ename='test' where empno=7369;

commit;

select spid from v$process

where addr=(select paddr from v$session

where sid=

(select sid from v$mystat where rownum=1));*可以获取跟踪日志文件(这是第二种方法)

30109

quit

oracle:cd /u01/app/oracle/admin/orcl/udump

ls -l *30109*

orcl_ora_30109.trc

(2)tkprof orcl_ora_30109.trc out.txt sys=no  record=sql.txt(这是第三种方法)

*用tkprof格式化工具，sys=no不记录系统信息，record=sql.txt记录了用户的SQL语句

vi out.txt      统计信息

vi sql.txt      用户SQL

SQL_TRACE

sys:alter system set sql_trace=true(false) scope=both;

SQL> connect system/oracle

Connected.

SQL> grant alter session to scott;

sqlplus scott/tiger

alter session set sql_trace=true;

alter session set tracefile_identifier ="21";

select * from  emp,dept;(select * from emp where empno=7963)

alter session set sql_trace=false;

select spid from v$process where addr=(select paddr from v$session where sid=(select sid from v$mystat where rownum=1));

30109

quit

oracle:cd /u01/app/oracle/admin/orcl/udump

ls -l *30109*

orcl_ora_30109.trc

tkprof orcl_ora_30109.trc out.txt sys=no  record=sql.txt

vi out.txt 统计资料和执行计划

vi sql.txt 用户执行的SQL

逻辑读＝一致性读＋当前读；物理读＝disk到物理内存

在你的语句之下，首先是一个表格，它通常有三行组成，

它显示该查询各阶段的重要的执行统计数据。这三行代表查询的三个主要阶段：

解析(Parse)：此阶段是Oracle的优化器为SQL语句生成执行计划的阶段。

执行(Execute)：此阶段是服务器进程按照执行计划执行语句的阶段。

抓取(Fetch)：此阶段是服务器进程从表中抓取结果的阶段。

只有Select语句才需要此阶段，Update、Insert、Delete

等这些DML语句并不需要抓取行。

这个表格通常包括八列，这八列意义如下：

Call：说明了语句执行的每个阶段。

Count：此阶段的执行次数。

CPU：完成此阶段工作所耗的CPU时间，单位是毫秒。

Elapsed：完成此阶段工作所耗费的CPU时间再加上等待的时间，

单位也是毫秒。

Disk：完成此阶段工作所用的物理读次数。

Query：完成此阶段工作所用的一致读次数。consistent

Current：完成此阶段工作所用的当前读次数。

consistent Query和Current Query 加起来就是逻辑读。

逻辑读的两种类型

Current当前读: 为修改而读buffer，就是当前读,DML命令将块读进Buffer是为了修改

update

(块数)

consistent一致读: 因查询而读buffer，是一致读,SELECT

(块数)

当前读、一致读和起来是逻辑读

(块数)

select name,value from v$sysstat

where name in ('session logical reads',

'db block gets','consistent gets')

[

Oracle中更新语句的重启动

考虑一个简单的update语句：

update test set x=1 where y=1;

它是分为两步：

1. 根据where条件找出表中满足更新条件的数据行；

2. 更新步骤1中所找出的数据行的x值。

假如test表很大，update要执行好几分钟，而且在步骤1期间有人将某一行的y值改为2并提交了，那么在步骤2中，这个y=2的行是否还会被更新x列呢？

这种情况下，Oracle会选择“重启动”更新。

其实，Oracle在执行DML语句时，会用到两种不同的方式去读取数据块：

1. 一致读：在“找到”需要修改的数据行时，会采用consistent read

2. 当前读：在“获取”数据块来实际更新数据行时，会采用current read

Oracle就是通过这样来判断是否需要重启动的。

具体到上面的例子中，首先Oracle会利用一致读找到所有y=1的数据行，因此就算读取期间有别的会话修改了某一行的y值(如从y=1变为y=2)，Oracle也会利用undo数据将该行的y列恢复到读取的那个时刻的值(即y=1)，所以这一行还是会被读取。然后，当要实际更新这一行的时候，Oracle会利用当前读去获取数据块的最新版本，由于被提交过了，所以读到的y值是2，与之前一致读中的y=1不符。所以Oracle就知道了需要“重启动”这个update操作。

Oracle重启动的流程：

1. 回滚之前的修改操作

2. 进入select for update模式，锁定需要修改的行

3. 对锁定的行进行修改操作

]

db block gets: Number of times a CURRENT block was requested

consistent gets: Number of times a consistent read was requested for a block.

session logical reads: The sum of "db block gets" plus "consistent gets". This includes logical reads of database blocks from either the buffer cache or process private memory.

逻辑读

物理读

Rows：完成此阶段工作所操作的行数。

接下来一行：“Misses in library cache during parse:

”说明硬解析的次数，

本例中语句的执行进行了一次硬解析。

“Optimizer mode”是优化器模式，

这个我们会在SQL调优章节中详细讲述它的意义。

最后几行是执行计划，这也是后面章节的内容。

另外，我们在目标文件中还会发现大量的其他语句，注意，我们在跟踪其间，

只执行了一条SQL语句，跟踪文件中其他的语句，其实就是所谓的递归调用。

也就是为了完成我们的语句，Oracle内部执行的一些其他的SQL语句。

通过观察跟踪文件的目标文件，我们可以观察到比较精确的CPU时间、

物理读逻辑读等信息，这有助于我们了解一条SQL语句是否有效。

10046事件

sqlplus scott/tiger

alter session set timed_statistics=true;

alter session set max_dump_file_size=unlimited;

alter session set tracefile_identifier ="0121";

alter session set events '10046 trace name context

forever,level 12';

variable t number

exec :t:=7396;

select * from emp e,dept d

where e.empno=:t **“:t表示绑定变量”

and e.deptno=d.deptno ;

alter session set events '10046 trace name context off';

quit

/u01/app/oracle/admin/orcl/udump

tkprof test_ora_3516_21.trc  out5.txt sys=no  record=sql5.txt

Event 10046 - Enable SQL Statement Trace---跟踪SQL,

有执行计划,

邦定变量和等待的统计信息,level 12最具体

ALTER SESSION SET EVENTS

'10046 trace name context forever, level 12';

级别level参考如下图:

Level

Action

1

Print SQL statements, execution plans and

execution statistics

4

As level 1 plus bind variables

8

As level 1 plus wait statistics

Emit statistics for Oracle kernel internal function calls

(also called “wait events”) listed in v$event_name

12

As level 1 plus bind variables and

wait statistics

sys:

select * from v$session;

execute sys.dbms_system.set_sql_trace_in_session(303,908,TRUE);

execute sys.dbms_system.set_sql_trace_in_session(303,908,FALSE);

---------------------

set timing on:打开时间开关

SQL> connect scott/tiger

已连接。

SQL> select count(*) from emp;

COUNT(*)

----------

14

SQL> set timing on

SQL> select count(*) from emp;

COUNT(*)

----------

14

已用时间:  00: 00: 00.00

SQL> select count(*) from mobil

COUNT(*)

----------

2821

已用时间:  00: 00: 00.07

SQL> set timing off：关闭时间开关

----------------

set autotrace:

SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]}

[EXP[LAIN]] [STAT[ISTICS]]

On      exp  ：按正常情况显示声明的输出，同时在后面补加上执行计划。

On  stat ：按正常情况显示声明的输出，同时在后面补加上统计资料。

On      ：按正常情况显示声明的输出，同时在后面补加上执行计划和统计资料。

Trace exp  ：不显示声明原来的输出，只显示执行计划。

Trace stat ：不显示声明原来的输出，只显示统计资料。

Trace     ：不显示声明原来的输出，显示统计资料和执行计划。

Off      ：关闭Set auto ，恢复正常状态

使用autotrace的前提：

(1)用户有PLUSTRACE角色，

用$ORACLE_HOME\sqlplus\admin\plustrce.sql

建立；

(2)有plan_table表；

sys:@$ORACLE_HOME/sqlplus/admin/plustrce.sql

grant plustrace to scott;

sql>set timing on

SQL> show autotrace

autotrace OFF

SQL> set autotrace on

set autotrace traceonly

set autotrace off

SQL> show autotrace

autotrace ON EXPLAIN STATISTICS

SQL> select * from dept;

SQL> select * from dept where deptno like '%0';

SQL> select * from dept where deptno=

(select max(deptno) from dept);

----------------------

statistics_level = { all | typical | basic }

V$STATISTICS_LEVEL，其中记录着各种资料是否被收集

timed_statistics