<Oracle优化新常态> 第九章 7X24两面人

前半生

<Oracle优化新常态>第一章

<Oracle优化新常态>第二章强拆（1）

<Oracle优化新常态>第二章强拆（2）

<Oracle优化新常态>第三章 三大配置

<Oracle优化新常态>第四章 分库分表

<Oracle优化新常态> 第六章 SQL优化大法

<Oracle优化新常态> 第七章 五大禁止

<Oracle优化新常态> 第八章 WHO-IT方法简介

正文

在一个7X24小时运行系统中，业务不能终止，也不能暂停，似乎也没有低峰期。在这样的系统中必须ONLINE方式做数据维护工作。

比如说重建索引，重定义表，压缩表，降低高水位！ 作为DBA的我们确实不愿意深夜时间段中去做数据维护的！而小仙所服务的老板，业务基本上没有高低峰，很多事情只好安排在白天做，夜晚和白天做都一样，为啥不争取白天做呢？夜晚做容易伤害龙体的。

话说我们有这样个案例，其中某个表有个BLOG字段，里面存放半年前上线的功能。就是第三方风控给的评价结果，主要是些CHAR的结构体。JAVA开发人员把这些存进了BLOG里面。随着时间的推移，该字段长到了40GB！

数据库所在的系统目录已经达到了64%的使用率，而且这还是停了在线热备份的结果。再无视它的后果是不勘的！ 也向领导提出加硬盘空间的事情，不过一直没有什么回应。唯有向领导和开发人员反映段比较大的事情。开发人员商议后，觉得这些数据使用完了，保留也没有什么价值。为此进行了删除操作！

领导要求把数据空间给压缩掉，减小。

对表的释放其占用的空间回表空间的方式有两种

一 MOVE 到其它表空间上，在MOVE的过程中ORACLE自己会重新整理数据，使得数据紧密存在一个数据块上。这样就比较少的空闲块，类似于WINDOWS的磁盘整理。

二 是本表所在的表空间进行SHRINK

使用 alter table tbname shrink space 来收缩表段

1. 实现原理
   实质上构造一个新表(在内部表现为一系列的DML操作,即将副本插入新位置，删除原来位置的记录)
   靠近末尾处(右端)数据块中的记录往开始处(左端)的空闲空间处移动(DML操作)，不会引起DML触发器
   当所有可能的移动被完成，高水位线将会往左端移动(DDL操作)
   新的高水位线右边的空闲空间被释放(DDL操作)

2. 实现前提条件
   必须启用行记录转移(enable row movement)
   仅仅适用于堆表,且位于自动段空间管理的表空间(堆表包括:标准表,分区表,物化视图容器,物化视图日志表)

3. 不能实现收缩的表
   群集表
   具有LONG类型列的表
   LOB段(尽管表本身可以被缩小)，注，10gR2以后版本支持对LOB段的收缩
   具有基于提交的物化视图的表(因为禁用了触发器)
   具有rowid物化视图的表(因为rowid发生了变化)
   IOT映射表IOT溢出段
   索引基于函数的表
   未启用行记录转移的堆表

4. 段收缩的优点
   提高缓存利用率，提高OLTP的性能
   减少磁盘I/O，提高访问速度，节省磁盘空间
   段收缩是在线的，索引在段收缩期间维护，不要求额外的磁盘空间

5. 两个选项
   cascade:缩小表及其索引，并移动高水位线，释放空间
   compact:仅仅是缩小表和索引，并不移动高水位线，不释放空间
   alter table tbname shrink space 相当于带cascade参数

如果采纳小仙上面建议的分库和分表的方式，就不需要缩小表来提高查询性能。可惜如今大量的混合系统，表太大，高水太高导致很多查询和统计缓慢！

而面对7X24小时，没有停机维护的时间窗口，该怎么办呢？

而SHRINK 办法是会阻塞业务的，阻塞时间长短可不一定，看IO快慢了。不管怎么样阻塞一笔交易，就损失利润，这是领导所不容许的。

问题找到了，解决办法会有很多的，很显然SHRINK 无法ONLINE 模式去操作。或许将来是可以的，不过目前还不行！

解决方案是 --------两面人

什么是两面人？ 比如说该表，我们假设叫做 risk_result。我们在新建个同个结构的表，叫做risk_result_B， B面的风控表。

这个表需要开发人员配合，就是把该表登记在应用数据字典中，在管理页面上搞个数据维护栏。在该栏的板块中 设置两个按钮 分别是风控A面表和风控B面表，或者是单选HTML控件。该功能是互斥的，选择了A，那么业务向A表插入数据，若选择了B就向B面插入业务数据。

这样在不影响正常交易下，就可以在后台做数据维护工作，降低高水位。

你说查询怎么办？ UNION ALL 两面就行。