问题描述
嗨,
[去] 压缩 (例如历史) 分区会影响OLTP压缩 (或任何其他压缩方案) 是否会导致对表上长时间运行的查询 (未引用该分区) 的中断?
假设查询正在通过保存昨天数据的分区,我们打算压缩与30天前关联的分区。光标会失效吗?
怎么样
1.在压缩发生期间,同一表上的分区交换操作?
2.不相关分区上的DML?会被封吗?
问候,
巴巴克。
[去] 压缩 (例如历史) 分区会影响OLTP压缩 (或任何其他压缩方案) 是否会导致对表上长时间运行的查询 (未引用该分区) 的中断?
假设查询正在通过保存昨天数据的分区,我们打算压缩与30天前关联的分区。光标会失效吗?
怎么样
1.在压缩发生期间,同一表上的分区交换操作?
2.不相关分区上的DML?会被封吗?
问候,
巴巴克。
专家解答
只要您在不同的分区上工作,就可以了,例如
话虽如此,你需要记住几件事
a) 如果你在你的表上做一个重型I/O操作 (压缩等),那么你的I/O子系统上的额外负载可能会对OLTP操作产生减慢的影响。通常,您尝试将如此高的I/O操作保持在安静的时间。
b) 如果您在整个表中都有全局索引,则指定 “更新索引” 的分区操作可能会类似地为这些索引条目引入争用。
--
-- session 1
--
SQL> create table t ( x int, y date , z char(100) )
2 partition by list ( x )
3 (
4 partition p1 values (1 ) compress,
5 partition p2 values (2 ) compress,
6 partition p3 values (3 ) compress,
7 partition p4 values (4 ) compress
8 );
Table created.
SQL>
SQL> insert /*+ APPEND */ into t select 1, sysdate, 'x' from dual connect by level <= 100000;
100000 rows created.
SQL> commit;
Commit complete.
SQL> insert /*+ APPEND */ into t select 2, sysdate, 'x' from dual connect by level <= 100000;
100000 rows created.
SQL> commit;
Commit complete.
SQL> insert /*+ APPEND */ into t select 3, sysdate, 'x' from dual connect by level <= 100000;
100000 rows created.
SQL> commit;
Commit complete.
SQL>
SQL> exec dbms_stats.gather_table_stats('','T')
PL/SQL procedure successfully completed.
--
-- Session 2
--
SQL> delete from t where x = 3 and rownum <= 10;
10 rows deleted.
--
-- Session 1 is unaffected
--
SQL> alter table t move partition p1 nocompress;
Table altered.
SQL>
话虽如此,你需要记住几件事
a) 如果你在你的表上做一个重型I/O操作 (压缩等),那么你的I/O子系统上的额外负载可能会对OLTP操作产生减慢的影响。通常,您尝试将如此高的I/O操作保持在安静的时间。
b) 如果您在整个表中都有全局索引,则指定 “更新索引” 的分区操作可能会类似地为这些索引条目引入争用。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




