都知道alter table move 或shrink space可以收缩段，用来消除部分行迁移，消除空间碎片，使数据更紧密，但move跟shrink space还是有区别的。
Move会移动高水位，但不会释放申请的空间，是在高水位以下(below HWM)的操作。
而shrink space 同样会移动高水位，但也会释放申请的空间，是在高水位上下(below and above HWM)都有的操作。

Move解决问题：
a. 我们可以使用move将一个table从当前的tablespace上移动到另一个tablespace上：
alter table t move tablespace tablespace_name;
b. 我们还可以用move来改变table已有的block的存储参数,如：
alter table t move storage (initial 30k next 50k);
c.另外，move操作也可以用来解决table中的行迁移的问题。

使用move的一些注意事项：
a. table上的index需要rebuild：
在前面我们讨论过，move操作后，数据的rowid发生了改变，我们知道，index是通过rowid来fetch数据行的，所以，table上的index是必须要rebuild的。
alter index index_name rebuild online；

b.move时对table的锁定
当我们对table进行move操作时，查询v$locked_objects视图可以发现，table上加了exclusive lock

c.关于move时空间使用的问题：
当我们使用alter table move来降低table的HWM时，有一点是需要注意的，这时，当前的tablespace中需要有1倍于table的空闲空间以供使用

Shrink space语法：
alter table shrink space [ | compact | cascade ];
alter table shrink space compcat;
收缩表，但会保持 high water mark;
alter table shrink space;
收缩表，降低 high water mark;
alter table shrink space cascade;
收缩表，降低 high water mark，并且相关索引也要收缩

用shrink有两个前提条件:
1、表必须启用row movement，如：
alter table nonsrt.TAB_EZG_BIZ_UNCONTRACTED enable row movement;
alter table nonsrt.TAB_EZG_BIZ_UNCONTRACTED shrink space;
2、表段所在表空间的段空间管理(segment space management)必须为auto

segment shrink分为两个阶段：
1、数据重组(compact):通过一系列insert、delete操作，将数据尽量排列在段的前面。在这个过程中需要在表上加RX锁，即只在需要移动的行上加锁。由于涉及到rowid的改变，需要enable row movement.同时要disable基于rowid的trigger.这一过程对业务影响比较小。
2、HWM调整：第二阶段是调整HWM位置，释放空闲数据块。此过程需要在表上加X锁，会造成表上的所有DML语句阻塞。在业务特别繁忙的系统上可能造成比较大的影响。
注意：shrink space语句两个阶段都执行。
shrink space compact只执行第一个阶段。
如果系统业务比较繁忙，可以先执行shrink space compact重组数据,然后在业务不忙的时候再执行shrink space降低HWM释放空闲数据块。

V$SESSION_WAIT displays the current or last wait for each session.

1、SID
Session identifier; maps to V$SESSION.SID

2、EVENT
session当前等待的事件，或者最后一次等待事件

3、WAIT_TIME
If the session is currently waiting, then the value is 0. If the session is not in a wait, then the value is as follows:
Value>0 – Value is the duration of the last wait in hundredths of a second
Value=-1 – Duration of the last wait was less than a hundredth of a second
Value=-2 – Parameter TIMED_STATISTICS was set to false

4、SEQ#
session等待事件将触发其值自增长

5、P1, P2, P3
等待事件中等待的详细资料

6、P1TEXT, P2TEXT, P3TEXT
解释说明p1,p2,p3事件

7、State
Wait state:
WAITING – Session is currently waiting
WAITED UNKNOWN TIME – Duration of the last wait is unknown; this is the value when the parameter TIMED_STATISTICS is set to false
WAITED SHORT TIME – Last wait was less than a hundredth of a second
WAITED KNOWN TIME – Duration of the last wait is specified in the WAIT_TIME column

8、SECONDS_IN_WAIT
If WAIT_TIME = 0, then SECONDS_IN_WAIT is the seconds spent in the current wait condition.
If WAIT_TIME > 0, then SECONDS_IN_WAIT is the seconds since the start of the last wait, and SECONDS_IN_WAIT – WAIT_TIME / 100 is the active seconds since the last wait ended.

9、Wait_time和Second_in_wait字段值与state相关
如果state值为Waiting，那么wait_time值无用。Second_in_wait值是实际的等待时间(单位：秒)。
如果state值为Wait unknow time，那么wait_time值和Second_in_wait值都无用。
如果state值为Wait short time，那么wait_time值和Second_in_wait值都无用。
如果state值为Waiting known time，那么wait_time值就是实际等待时间(单位：秒)，Second_in_wait值无用。

10、应用p1,p2,p3进行等待事件的分析
v$session_wait视图的列代表的缓冲区忙等待事件如下：
P1—与等待相关的数据文件的全部文件数量。
P2—P1中的数据文件的块数量。
P3—描述等待产生原因的代码。
例：select p1 “File #”, p2 “Block #”, p3 “Reason Code”
　　from v$session_wait
　　where event = ‘buffer busy waits’;
如果以上查询的结果显示一个块在忙等待，以下的查询将显示这一块的名称和类型：
select owner, segment_name, segment_type
　from dba_extents
　where file_id = &P1　and &P2 between block_id and block_id + blocks -1;
我们也可以查询dba_data_files以确定等待的文件的file_name，方法是使用v$session_wait中的P1。
从v$session_wait中查询P3(原因编码)的值可以知道session等待的原因。原因编码的范围从0到300，下列为部分编码所代表的事项：
0 块被读入缓冲区。
100 我们想要NEW(创建)一个块，但这一块当前被另一session读入。
110 我们想将当前块设为共享，但这一块被另一session读入，所以我们必须等待read()结束。
120 我们想获得当前的块，但其他人已经将这一块读入缓冲区，所以我们只能等待他人的读入结束。
130 块被另一session读入，而且没有找到其它协调的块，所以我们必须等待读的结束。缓冲区死锁后这种情况也有可能产生。所以必须读入块的CR。
200 我们想新创建一个block，但其他人在使用，所以我们只好等待他人使用结束。
210 Session想读入SCUR或XCUR中的块，如果块交换或者session处于非连续的TX模式，所以等待可能需要很长的时间。
220 在缓冲区查询一个块的当前版本，但有人以不合法的模式使用这一块，所以我们只能等待。
230 以CR/CRX方式获得一个块，但块中的更改开始并且没有结束。
231 CR/CRX扫描找到当前块，但块中的更改开始并且没有结束

1 SQL ordered by Elapsed Time
记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间 Elapsed Time = CPU Time + Wait Time)。
Elapsed Time(S): SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒。Elapsed Time = CPU Time + Wait Time
CPU Time(s): 为SQL语句执行时CPU占用时间总时长，此时间会小于等于Elapsed Time时间。单位时间为秒。
Executions: SQL语句在监控范围内的执行次数总计。
Elap per Exec(s): 执行一次SQL的平均时间。单位时间为秒。
% Total DB Time: 为SQL的Elapsed Time时间占数据库总时间的百分比。
SQL ID: SQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQL ID的地方。
SQL Module: 显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。
SQL Text: 简单的sql提示，详细的需要点击SQL ID。

2 SQL ordered by CPU Time:
记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。

3 SQL ordered by Gets:
记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets)。

4 SQL ordered by Reads:
记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读)。

5 SQL ordered by Executions:
记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。

6 SQL ordered by Parse Calls:
记录了SQL的软解析次数的TOP SQL。说到软解析(soft prase)和硬解析(hard prase)，就不能不说一下Oracle对sql的处理过程。

7 SQL ordered by Sharable Memory:
记录了SQL占用library cache的大小的TOP SQL。Sharable Mem (b)：占用library cache的大小，单位是byte。

8 SQL ordered by Version Count:
记录了SQL的打开子游标的TOP SQL。

9 SQL ordered by Cluster Wait Time:
记录了集群的等待时间的TOP SQL

1.ASH占用的内存大小
ASH的采集信息保存在内存中，在旧的信息被采样到AWR中后，可被新采集的信息覆盖，重启oracle后该信息被清除。分配给ASH的内存大小可以查询到：
SQL> select pool, name, bytes/1024/1024 From v$sgastat where name like ‘%ASH %’;

POOL NAME BYTES/1024/1024
———— ————————– —————
shared pool ASH buffers 4

2.mmon进程与mmnl进程
2.1）快照由一个称为 MMON 的新的后台进程（及其从进程）以及MMNL后台进程自动地每隔固定时间采样一次。我们先来看一下10g的概念指南中对这两个新增加的后台进程的介绍：
MMON进程负责执行多种和管理相关（manageability-related）的后台任务
例如：当某个测量值（metrics）超过了预设的限定值（threshold value）后提交警告,创建新的 MMON 隶属进程（MMON slave process）来进行快照(snapshot),捕获最近修改过的 SQL 对象的统计信息
2.2）MMNL进程负责执行轻量级的且频率较高的和可管理性相关的后台任务
例如:捕获会话历史信息，测量值计算等。
2.3）AWR的采样工作默认是由MMON进程每个1小时执行一次，ASH信息同样会被采样写出到AWR负载库中。虽然ASH buffer被设计为保留1小时的信息，但很多时候这个内存是不够的，当ASH buffer写满后，另外一个后台进程MMNL将会主动将ASH信息写出。

3.SYSAUX表空间
AWR 使用几个表来存储采集的统计数据，所有的表都存储在新的名称为 SYSAUX 的特定表空间中的 SYS 模式下，并且以 WRM$_* 和 WRH$_* 的格式命名。前一种类型存储元数据信息（如检查的数据库和采集的快照），后一种类型保存实际采集的统计数据。H 代表“历史数据 (historical)”而 M 代表“元数据 (metadata)”
使用sql语句： select table_name from dba_tables where table_name like ‘WRM$%’ or table_name like ‘WRH$%’;查询
当SYSAUX表空间满后，AWR将自动覆盖掉旧的信息，并在警告日志中记录一条相关信息：
ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition WRH$_ACTIVE_3533490838_1522 by 128 in tablespace SYSAUX

4.采样频率和保留时间
可以通过查询视图dba_hist_wr_control或（wrm$_wr_control）来查询AWR的采样频率和保留时间。默认为每1小时采样一次，采样信息保留时间为(7/10g|8/11g)天。
SQL> select * from dba_hist_wr_control;

DBID SNAP_INTERVAL RETENTION TOPNSQL
———- ——————– ——————– ———-
3393548168 +00000 00:30:00.0 +00010 00:00:00.0 DEFAULT
或者
SQL> select DBID, SNAP_INTERVAL, SNAPINT_NUM, RETENTION from wrm$_wr_control;

DBID SNAP_INTERVAL SNAPINT_NUM RETENTION
———- ——————– ———– ——————–
3393548168 +00000 00:30:00.0 1800 +00010 00:00:00.0

修改采集频率和保存时间： exec dbms_workload_repository.modify_snapshot_settings(interval=>30, retention=>5*24*60);
Note：输入的retention参数值不能被目前库中保存的数据的范围小（如果要减少保存时间，需要先删除历史数据）

5.采样数据量
由于数据量巨大，把所有ASH数据写到磁盘上是不可接受的。一般是在写到磁盘的时候过滤这个数据，写出的数据占采样数据的10%，写出时通过direct-path insert完成，尽量减少日志生成，从而最小化数据库性能的影响。

6.初始化参数statistics_level
AWR的行为受到参数STATISTICS_LEVEL的影响。这个参数有三个值：
BASIC：awr统计的计算和衍生值关闭.只收集少量的数据库统计信息.
TYPICAL：默认值．只有部分的统计收集.他们代表需要的典型监控oracle数据库的行为.
ALL : 所有可能的统计都被捕捉. 并且有操作系统的一些信息.这个级别的捕捉应该在很少的情况下,比如你要更多的sql诊断信息的时候才使用.

7.快照管理
7.1）执行
exec dbms_workload_repository.create_snapshot();
7.2）查询
select * from wrh$_active_session_history
7.3）删除
exec dbms_workload_repository.drop_snapshot_range(low_snap_id => 90, high_snap_id => 96, dbid => 1160732652);

8. 基线管理
8.1）创建baseline，保存这些数据用于将来分析和比较
exec dbms_workload_repository.create_baseline(start_snap_id => 1003, end_snap_id => 1013, ‘apply_interest_1’);

8.2）删除baseline
exec DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(baseline_name => ‘apply_interest_1’, cascade => FALSE);

一、ASH
若是一个普通的会话（我是指没有大量地耗费资源），则对于性能调整来说无足轻重。但若该会话在活动时大量占用了资源（比如：CPU，内存，I/O等），该会话信息的丢失，将无法评测当时的系统瓶颈究竟是什么。令DBA高兴的是，oracle10g中保留下了v$session_wait中的这些信息。
在10g中新出现了一个视图：v$session_wait_history。这个视图保存了每个活动session在v$session_wait中最近10次的等待事件。但这对于一段时期内的数据库性能状况的监测是远远不够的，为了解决这个问题，在10g中还新添加了一个视图：v$active_session_history。这就是ASH（active session history）。
典型的情况下,为了诊断当前数据库的状态，需要最近的五到十分钟的详细信息。然而，由于记录session的活动信息是很费时间和空间的，ASH采用的策略是：保存处于等待状态的活动session的信息，每秒从v$session_wait中采样一次，并将采样信息保存在内存中。

二、AWR
ASH的采样数据是保存在内存中。而分配给ASH的内存空间是有限的，当所分配空间占满后，旧的记录就会被覆盖掉；而且数据库重启后，所有的这些ASH信息都会消失。这样，对于长期检测oracle的性能是不可能的。在Oracle10g中，提供了永久保留ASH信息的方法，这就是AWR（auto workload repository）。
由于全部保存ASH中的信息是非常耗费时间和空间的，AWR采用的策略是：每小时对v$active_session_history进行采样一次，并将信息保存到磁盘中，并且保留7天，7天后旧的记录才会被覆盖。这些采样信息被保存在视图wrh$_active_session_history中。而这个采样频率（1小时）和保留时间（7天）是可以根据实际情况进行调整的，这就给DBA们提供了更加有效的系统监测工具。
AWR永久地保存系统的性能诊断信息，由SYS用户拥有。一段时间后，你可能想清除掉这些信息；有时候为了性能诊断，你可能需要自己定义采样频率来获取系统快照信息。Oracle 10g在包dbms_workload_repository中提供了很多过程，通过这些过程，你可以管理快照并设定基线(baselines)。
其实，AWR记录的信息不仅是ASH，还可以收集到数据库运行的各方面统计信息和等待信息，用以诊断分析。
AWR的采样方式是，以固定的时间间隔为其所有重要的统计信息和负载信息执行一次采样，并将采样信息保存在AWR中。
可以这样说：ASH中的信息被保存到了AWR中的视图wrh$_active_session_history中。ASH是AWR的真子集。

三、总结
这样，我们就知道了ASH和AWR产生的原因和功能。ASH保存了系统最新的处于等待的会话记录，可以用来诊断数据库的当前状态；而AWR中的信息最长可能有1小时的延迟，所以其采样信息并不能用于诊断数据库的当前状态，但可以用来作为一段时期内数据库性能调整的参考。
对于这些视图间的继承关系图：

其中视图dba_hist_active_sess_history是wrh$_active_session_history和其他几个视图的联合展现，通常通过这个视图进行历史数据的访问。