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
阅读(3403) | 评论(0) | 转发(0) |
