[20150225]Delayed Block Cleanout.txt

[20150225]Delayed Block Cleanout.txt

--主要原因是buffer太小或者修改的信息太大,大于buffer 的10%,出现一些块在dml时已经不在buffer。这样在提交时剩下的block不触
--摸,仅仅修改undo段的提交标志,表示事务已经结束。

--这样仅仅在下次select或者操作相应的数据块是在修改itl槽以及块内的信息,清除lb标识。
--昨天看了Apress.Oracle.Database.Transactions.and.Locking.Revealed.1484207610.pdf。
--参考文档,改进一下做一个测试:

1.建立测试环境:

SCOTT@test> @ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.3.0     Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

CREATE UNDO TABLESPACE UNDOTBS2 DATAFILE
  '/u01/app/oracle11g/oradata/test/undotbs02.dbf' SIZE 4M AUTOEXTEND OFF
ONLINE
RETENTION NOGUARANTEE
BLOCKSIZE 8K
FLASHBACK ON;

create table small ( x int, y char(500) );
insert into small select rownum, 'x' from all_users;
commit;
exec dbms_stats.gather_table_stats( user, 'SMALL' );

--建立sql脚本test2.sql:
set verify off
begin
for i in 1 .. 5000
loop
update small set y = i where x= &1;
commit;
end loop;
end;
/
exit

--建立shell脚本如下test2.sh:
sqlplus -s scott/btbtms @test2 1 &
sqlplus -s scott/btbtms @test2 2 &
sqlplus -s scott/btbtms @test2 3 &
sqlplus -s scott/btbtms @test2 4 &
sqlplus -s scott/btbtms @test2 5 &
sqlplus -s scott/btbtms @test2 6 &
sqlplus -s scott/btbtms @test2 7 &
sqlplus -s scott/btbtms @test2 8 &
sqlplus -s scott/btbtms @test2 9 &

2.开始测试:

alter system set undo_tablespace = UNDOTBS2;

SCOTT@test> update dept set loc=UPPER(loc) ;
7 rows updated.

SCOTT@test> alter system flush BUFFER_CACHE ;
System altered.
--我已经转储了数据缓冲。

SCOTT@test> commit ;
Commit complete.
--这样提交不写

SCOTT@test> variable x refcursor ;
SCOTT@test> exec open :x for select * from dept ;
PL/SQL procedure successfully completed.

$ ./test2.sh
--等待结束.我保险执行了2次。

SCOTT@test> set serveroutput on format wrapped
SCOTT@test> print x
ERROR:
ORA-01555: snapshot too old: rollback segment number 239 with name "_SYSSMU239_1274966276$" too small

--可以发现出现了ORA-01555错误。

SCOTT@test> column spare1 noprint
SCOTT@test> column spare2 noprint
SCOTT@test> column spare3 noprint
SCOTT@test> column spare4 noprint
SCOTT@test> column spare5 noprint
SCOTT@test> column spare6 noprint
SCOTT@test> select * from sys.undo$ where name='_SYSSMU239_1274966276$';
       US# NAME                                USER#      FILE#     BLOCK#     SCNBAS     SCNWRP    XACTSQN    UNDOSQN      INST#    STATUS$        TS#      UGRP#       KEEP    OPTIMAL      FLAGS
---------- ------------------------------ ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
       239 _SYSSMU239_1274966276$                  1         10        288          0          0          0          0          0          3          5

时间: 2024-11-14 11:38:27

[20150225]Delayed Block Cleanout.txt的相关文章

[20150228]Delayed Block Cleanout 2.txt

[20150228]Delayed Block Cleanout 2.txt --前几天我自己做了1次Delayed Block Cleanout的例子,我一直有一个疑问. --链接如下:http://blog.itpub.net/267265/viewspace-1441526/ --如果我很久不查询这些块,scn会是多少呢?这个一直是我的疑问,重复测试: 1.建立测试环境: SCOTT@test> @ver1 PORT_STRING                    VERSION   

[20150130]块清理(block cleanout).txt

[20150130]块清理(block cleanout).txt 1.建立测试环境: create table t2 as select * from dept ; SCOTT@test> select rowid,t2.* from t2; ROWID                    DEPTNO DNAME          LOC ------------------ ------------ -------------- ------------- AAAOQdAAEAAAAGG

[20170419]关于块scn号.txt

[20170419]关于块scn号.txt --//数据块里面有许多scn号相关. --//数据块本身有三处记录的相应的SCN:数据块头的SCN(block scn).ktbbh结构下的 kscnbas,kscnwrp(cleanout scn).ITL信息中的 --//scn/fsc(commit scn 有时候会是control scn),有时候会存在一点点混乱,通过例子说明: 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                

关于Undo Internal的研究

原文链接:http://www.eygle.com/internal/undo_internal.htm 本文就Undo的内部结构作初步探讨: 我们通过实验来看一下回滚段的内部结构. 测试脚本及过程如下: 首先创建一个测试表create table ud ( n number );insert into ud values(1);insert into ud values(2);commit; 然后执行一个事物:select * from ud;update ud set n=1000 wher

ORA-01555错误详解

ORA-01555错误详解   ORA-01555(快照过旧)问题让很多人感到十分头痛.最近我们的生产系统上也报出了ORA-01555错误.就结合这次案例将ORA-1555问题作个案例分析,并浅析产生原因和各种解决办法. 如果要了解1555错误产生的原因,就需要知道ORACLE的两个特性:一致性读(Consistent Get)和延迟块清除(Delayed Block Cleanout).此外,还要知道关于回滚段的一些配置参数. 相关参数 先看下Oracle中关于UNDO有哪些配置参数: SQL

redo 和 undo 之二

5.分析redo redo的管理是数据库的一个串行点,每个oracle数据库实例都只有一个LGWR进程,所有的事务都会要求LGWR进程去管理,写他们的各自的redo,每个操作的LGWR写的越多,就会使系统越慢.所以我们就要时刻关注每一个事务生成的rodo的量. 如何查看redo的量呢? 你可能会想到用sql*plus内置的特性AUTOTRACE来查看,但是有个问题Tom说这个特性只能查看比较简单的DML语句,对于一些复杂的操作我们还是需要查看两个动态性能表: V$MYSTAT: 其中有每个会话的

《Oracle高性能自动化运维》一一3.3 Redo产生场景

3.3 Redo产生场景我们知道,Oracle Redo是以条目(Redo Entries/Records)的形式记录数据库的所有更改操作(OP).更改操作主要包括:数据库物理文件更改:主要指的是数据库物理文件的增减等操作:数据库运行状态更改:数据库当前状态版本的更改(Current Status Version),例如数据库检查点(Checkpoint)等操作:数据库后台进程写操作:数据库后台进程对数据库的操作,例如DBWR写磁盘.LGWR写日志等操作:DML事务操作:DML事务对数据的更改操

ORACLE 回滚段详解

ORACLE 回滚段   回滚段概述  回滚段用于存放数据修改之前的值(包括数据修改之前的位置和值).回滚段的头部包含正在使用的该回滚段事务的信息.一个事务只能使用一个回滚段来存放它的回滚信息,而一个回滚段可以存放多个事务的回滚信息.  回滚段的作用  事务回滚:当事务修改表中数据的时候,该数据修改前的值(即前影像)会存放在回滚段中,当用户回滚事务(ROLLBACK)时,ORACLE将会利用回滚段中的数据前影像来将修改的数据恢复到原来的值.  事务恢复:当事务正在处理的时候,例程失败,回滚段的信

[20171113]修改表结构删除列相关问题2.txt

[20171113]修改表结构删除列相关问题2.txt --//测试看看修改表结构删除列产生的redo向量,对这些操作细节不了解,分析redo看看. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ----------------------------------------------