E
---------- ------------------ ---------- --------------
1 ACTIVE 7420181 29-4月 -15
2 NOT ACTIVE 0
3 NOT ACTIVE 0
5 NOT ACTIVE 0
6 NOT ACTIVE 0
7 ACTIVE 7420021 29-4月 -15
8 NOT ACTIVE 0
9 NOT ACTIVE 0
11 NOT ACTIVE 0
12 NOT ACTIVE 0
已选择10行。
此时一号和七号文件处于活动的状态，并且记录此时SCN，作为下一次恢复的起点！
备份就是直接拷走备份的数据文件。
关闭数据文件7的活动状态：
SQL> alter tablespace CHAO end backup;
表空间已更改。
SQL> select * from v$backup where file#=7;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- --------------
7 NOT ACTIVE 7420021 29-4月 -15
如果要完全备份，这样操作是不是能把人搞疯！
SQL> alter database begin backup;
alter database begin backup
*
第 1 行出现错误:
ORA-01146: 无法启动联机备份 - 文件 1 已在备份中 ORA-01110:
数据文件 1: '/u01/app/oracle/oradata/orcl3939/system01.dbf'
SQL> alter tablespace system end backup;
表空间已更改。
这个地方感觉不是太爽！需要关闭之前的热状态！
SQL> alter database begin backup;
数据库已更改。
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- --------------
1 ACTIVE 7420464 29-4月 -15
2 ACTIVE 7420464 29-4月 -15
3 ACTIVE 7420464 29-4月 -15
5 ACTIVE 7420464 29-4月 -15
6 ACTIVE 7420464 29-4月 -15
7 ACTIVE 7420464 29-4月 -15
8 ACTIVE 7420464 29-4月 -15
9 ACTIVE 7420464 29-4月 -15
11 ACTIVE 7420464 29-4月 -15
12 ACTIVE 7420464 29-4月 -15
已选择10行。
结束备份的话直接alter database end backup;
这种备份的缺点：
1.会产生大量的redo log，是什么原因呢？
SQL> show parameter db_block_size
db_block_size integer 8192
[oracle@localhost ~]$ dumpe2fs /dev/sda1
bash: dumpe2fs: command not found
[oracle@localhost ~]$ su - root
口令：
[root@localhost ~]# dumpe2fs /dev/sda1
Block size: 1024
SQL> select 8*1024/1024 from dual;
8*1024/1024
-----------
8
8个操作系统块构成了一个数据块：
此时用os命令拷贝这个块，读取是按照os块读取，但是此时oracle一个事务正在修改这个块。最终 我们恢复时，oracle识别不了这个块 ！
oracle为了解决这个问题，只要在热备份状态下的块，操作这个数据块都会以日志方式记录下来，所以操作一个块会多8k日志量。
大概简述模拟这个过程：
select * from v$statname where name like '%redo%';统计了很多关于redo的信息，里面有redo size. SQL> select * from v$sesstat where sid=159;
SQL> select * from v$sesstat where statisti
c#=169 and sid=159;
可以插入一条数据，然后看产生多少日志（大概估计）。
然后执行表空间热备份下：
看下日志量
然后插入相同数据，查看日志量
感兴趣可以自行模拟。
|