设为首页 收藏本站
查看: 1538|回复: 0

[经验分享] OCP读书笔记(18)

[复制链接]

尚未签到

发表于 2015-6-17 07:02:52 | 显示全部楼层 |阅读模式
  OLTP 表压缩
压缩始终是非常占用CPU的过程,并且需要花费一定时间,通常,如果压缩数据,则数据必须解压缩后才能使用。虽然此要求在数据仓库环境中是可以接受的但在OLTP环境中可能无法接受
现在,在Oracle数据库11g中,可以执行以下命令:



create table my_compressed_table (
  col1 number(20),
  col2 varchar2(300),
  ...
)
compress for all operations
  “compress for all operations”子句在所有DML活动(如 INSERT、UPDATE等)上执行压缩,压缩在所有DML活动上发生,而不像oracle11g之前的版本那样,只在直接路径加载上发生
  OLTP table compress的原理
  当我们对一个表使用alter table  compress for oltp语句时,对已有的数据不受影响。但是他对一个块中新insert或update的行最开始也不受影响,直到这个数据块达到PCTFREE时才触发压缩,于是,现在新的压缩其实就是从老的方法:对每条新增的行做compress,变成了对一个block中的所有行批量处理,这样就让大部分的insert/update语句没有性能上的损失,只对insert/update导致某个块刚好达到PCTFREE的语句有一些负载
  当一个块由于触发压缩,而导致块的数据又低于PCTFREE的临界点后,这个块又可以接受更多的数据,会又一次达到PCTFREE,就会又一次压缩
  由于压缩作为触发事件发生,而不是在插入行时发生,因此在正常的DML进程中压缩对性能没有任何影响。压缩被触发后,对CPU的需求肯定会变得很高,但在其他任何时间CPU影响都为零,因此压缩也适用于OLTP应用程序
  OLTP compressed table和传统老的compressed table的空间利用情况的比较



conn /as sysdba
grant select on dba_objects to scott;
conn scott/tiger
create table newcomp compress for oltp as select * from dba_objects;
create table oldcomp compress as select * from dba_objects;
create table notcomp as select * from dba_objects;
select table_name, compress_for from user_Tables where table_name in ('NEWCOMP','OLDCOMP','NOTCOMP');
select segment_name, sum(bytes)/1024 KB from user_extents where segment_name in ('NEWCOMP','OLDCOMP','NOTCOMP') group by segment_name;
  两种压缩方式在最开始的时候差不多大



update newcomp set object_name = object_name||'abc';
update oldcomp set object_name = object_name||'abc';
update notcomp set object_name = object_name||'abc';
commit;
select segment_name, sum(bytes)/1024 KB from user_extents where segment_name in ('NEWCOMP','OLDCOMP','NOTCOMP') group by segment_name;
  在大量更新后,我们发现,传统的表压缩逐渐丢失了自己压缩的特性,而OLTP compressed table却依然保持良好的压缩性能



drop table OLDCOMP purge;
drop table NEWCOMP purge;
drop table NOTCOMP purge;
  收缩段



SQL> grant select on dba_objects to scott;
SQL> conn scott/tiger
SQL> create table t as select * from dba_objects;
SQL> create index ind_t on t(object_id);
SQL> exec dbms_stats.gather_table_stats('scott', 't', cascade=>true);
SQL> select num_rows, blocks from user_tables where table_name='T';
SQL> delete t where rownum commit;

SQL> exec dbms_stats.gather_table_stats('scott', 't', cascade=>true);
SQL> select num_rows, blocks from user_tables where table_name='T';
SQL> alter table t enable row movement;
SQL> alter table t shrink space compact;
SQL> exec dbms_stats.gather_table_stats('scott', 't', cascade=>true);
SQL> select num_rows, blocks from user_tables where table_name='T';
SQL> alter table t shrink space;
SQL> exec dbms_stats.gather_table_stats('scott', 't', cascade=>true);
SQL> select num_rows, blocks from user_tables where table_name='T';

SQL> select status from user_indexes where table_name='T' --段收缩之后索引仍然有效(valid);
SQL> delete t;
SQL> commit;
SQL> alter table t shrink space;----默认执行两步
SQL> exec dbms_stats.gather_table_stats('scott', 't', cascade=>true);
SQL> select num_rows, blocks from user_tables where table_name='T';
  处理挂起的事务
暂停失败的事物,不要回退,处理故障后继续运行源语句(9i的新特性)
当事务缺少某些资源不能运行的时候数据库会有两种处理方法:
一:自动的回退,当我们运行大的事物时,回退是很大的工作量
二:数据库可以将事物挂起,等待新的资源到来,继续进行处理没有完成的事物,我们可以设置等待的时间,可以检测等待的资源



SQL> drop tablespace t2m including contents and datafiles;
SQL> create tablespace t2m datafile '/u01/app/oracle/oradata/orcl/t2m.dbf' size 1m autoextend off;
SQL> conn scott/tiger
SQL> drop table e purge;
SQL> create table e tablespace t2m as select * from emp;
SQL> insert into e select * from e;
SQL> /
insert into e select * from e
ORA-01653: 表 SCOTT.E 无法通过 8 (在表空间 T2M 中) 扩展
  只回退当前的语句,其他插入还在,等待我们结束事务。



conn /as sysdba
SQL> grant execute on dbms_resumable to scott;
SQL> grant resumable to scott;
conn scott/tiger
SQL> alter session enable resumable timeout 3600;
  启用挂起的特性



conn /as sysdba
grant select on v_$mystat to scott;
SQL> select sid from v$mystat where rownum=1;
--查看当前的会话
SQL> select dbms_resumable.get_session_timeout(151) from dual;
SQL> insert into e select * from e;
--现在挂起不动了,等待资源,我们新开一个会话
SQL> conn system/a
SQL> select event from v$session_wait where sid=151;
--看151会话在等待什么
SQL> select error_msg from dba_resumable;
SQL> select file_id from dba_data_files where tablespace_name='T2M';
SQL> alter database datafile 7 resize 3m;
--再回到第一个会话,我们看到
14336 rows inserted
SQL> commit;
  
  

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-78003-1-1.html 上篇帖子: OCP prepare 20140701 下篇帖子: ocp 042 第二章 数据库安装
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表