[20150309]热备份与redo.txt

[20150309]热备份与redo.txt

-- 最近一段时间看关于备份的书籍,提到热备份期间,如果对某块做dml操作,redo 日志里面是包含整个数据库,防止出现块分裂。
-- http://blog.itpub.net/267265/viewspace-1441552/

--实际上仅仅第1次会做,后续的dml就不会做这样的操作,做一个测试例子:

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

SCOTT@test> alter tablespace users begin backup ;
Tablespace altered.

2.开始测试:
SCOTT@test> set autot traceonly
SCOTT@test> update dept set loc=upper(loc) ;

4 rows updated.

Execution Plan
----------------------------------------------------------
Plan hash value: 921533340

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | UPDATE STATEMENT   |      |     4 |    32 |     3   (0)| 00:00:01 |
|   1 |  UPDATE            | DEPT |       |       |            |          |
|   2 |   TABLE ACCESS FULL| DEPT |     4 |    32 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------

Statistics
----------------------------------------------------------
          0  recursive calls
          5  db block gets
          8  consistent gets
          0  physical reads
       9664  redo size
        834  bytes sent via SQL*Net to client
        784  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          4  rows processed

SCOTT@test> commit ;
Commit complete.

--可以发现产生的redo size=9664.

3.如果我后续依旧做这样的操作:
SCOTT@test> update dept set loc=lower(loc) ;
4 rows updated.

Execution Plan
----------------------------------------------------------
Plan hash value: 921533340
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | UPDATE STATEMENT   |      |     4 |    32 |     3   (0)| 00:00:01 |
|   1 |  UPDATE            | DEPT |       |       |            |          |
|   2 |   TABLE ACCESS FULL| DEPT |     4 |    32 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------
Statistics
----------------------------------------------------------
          0  recursive calls
          5  db block gets
          8  consistent gets
          0  physical reads
       1436  redo size
        837  bytes sent via SQL*Net to client
        784  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          4  rows processed

SCOTT@test> commit ;
Commit complete.

--可以发现产生的redo size=1436.

--再次证明,仅仅第1次产生的redo包含整个数据块,后续的修改就不需要这样了。

时间: 2024-10-05 10:28:04

[20150309]热备份与redo.txt的相关文章

[20170215]再次理解flush redo.txt

[20170215]再次理解flush redo.txt --链接: http://blog.itpub.net/267265/viewspace-1992583/ http://blog.itpub.net/267265/viewspace-1992840/ 在Oracle 11g里,Data Guard 切换多了一个新的功能:flush redo. flush redo就是出现问题时,Flush可以把没有发送的redo从主库传送到standby数据库.而只要主库能启动到mount状态,那么F

[20161003]触发器与redo.txt

[20161003]触发器与redo.txt --对于触发器,我个人认为对于dba是最讨厌的东西,它使得维护变得困难,不小心就陷入陷阱里面. --我曾经跟开发讲过建立一个触发器相当于给表建立一个索引.除非万不得以不要建立触发器. --昨天看了一个例子,重复作者的测试来说明问题: http://orasql.org/2016/09/22/how-even-empty-trigger-increases-redo-generation/ 1.环境: SCOTT@test01p> @ ver1 POR

[20120417]select生产redo.txt

select生成redo主要有几个原因,常见的主要是修改表记录太多,在commit后,由于记录已经不在数据缓存,在下次select时,再修改相关信息,称为快速提交. 做一个测试: 1.快速提交产生的: SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise

[20160222]Oracle 11G Data Guard Failover

[20160222]Oracle 11G Data Guard Failover-flush redo.txt --链接: http://blog.csdn.net/tianlesoftware/article/details/6256542 在Oracle 11g里,Data Guard 切换多了一个新的功能:flush redo. Flush 能把没有发送的redo 从主库传送到standby库. 只要主库能启动到mount 状态,那么Flush 就可以把没有发送的归档和current on

[20150109]关于热备份.txt

[20150109]关于热备份.txt --热备份仅仅冻结数据文件以及控制文件对应的CHECKPOINT_CHANGE#.昨天别人提到如果热备份长时间没有完成或者结束,异常关机会出 --现一些问题,容易导致误判.自己做一个测试. 1.建立测试环境: SYS@test> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ----

[20150309]使用冷备份做恢复的问题.txt

[20150309]使用冷备份做恢复的问题.txt --做一个例子,说明冷备份做不完全恢复的问题. 1.测试环境: SCOTT@test> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ---------------------------------------------------------------- x86_

[20150308]热备份和数据库检查点.txt

[20150308]热备份和数据库检查点.txt --今天看书,提到在热备份前,会做了一个数据文件检查点操作. --实际上这个很好理解: 开始热备份时候,做了一个数据文件检查点操作,因为热备份时备份要产生的日志很大,数据库必须要知道那个时候开始,做这项工作. 保证了在热备份期间,只有在发出热备份命令之后的时间里修改的块可能会被写到数据文件上. --自己做一个简单检查: SCOTT@test> @ver1 PORT_STRING                    VERSION       

[20150309]逻辑读产生CBC Latch的解析.txt

[20150309]逻辑读产生Cache Buffer Chain(简称CBC) Latch的解析.txt --参考链接http://blog.csdn.net/guoyjoe/article/details/8585391,自己也做1次. 逻辑读的过程 1.Oracle以每个块的文件号.块号和类型做HASH运算,得到HASH值.根据HASH值,到HASH表中取出指定块的内存地址 2.获取CBC Latch(实验的重点测试部分) 3.根据HASH值,搜索CBC链表 4.根据DBA找到BH(Buf

[20150309]sqlplus set array最小2.txt

[20150309]sqlplus set array最小2.txt --上午做测试发现1个问题,设置array=1是无效的,在sqlplus下set array最小是2.自己做一个人测试: 1.建立测试环境: SCOTT@test> @ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ---------------------------