分类： Oracle
2010-03-24 19:25:38
oracle
从不重要的文件丢失中恢复
1.临时文件丢失，数据不会down ，只会在alert.log 里面报错误
select * from v$tempfile;察看 临时文件
临时文件丢失了，怎么解决:
可以重新添加新的临时文件，或者直接通过多个临时表空间组成临时表空间组（这是10g 的新特性)，如果某一个临时表空间丢了，
oracle 会从组里自动找个可用的代替。
LOG 日志组
从上可以看出，log group 中的 member之间 必须 大小一致。但是 log group之间logfile大小可以不一样，
甚至member的数量都可以不一样。
切换后，arcn会归档，（相当于dump操作),归档日志文件大小是不一致的。
日志的 联机日志状态如果为 active，则 表示里面还包含了dbwr没有写回的脏数据。
select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ------------
1 1 2661 52428800 2 YES INACTIVE
9.4552E+12 25-SEP-09
2 1 2662 52428800 2 NO CURRENT
9.4552E+12 25-SEP-09
3 2 1391 52428800 2 YES INACTIVE
9.4552E+12 23-SEP-09
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ------------
4 2 1392 52428800 2 NO CURRENT
9.4552E+12 25-SEP-09
如果发生增量检查点，则 数据库只会修改控制文件头，不会触发dbwr 操作。
增量检查点的目的是 时刻告诉控制文件 scn值，rba 是什么在哪里。
1.临时表空间丢失， redo log member丢失，对库都不会有影响，只会由alert.log报警。
2.丢失某个组成员（解决办法:重建)
3.索引文件丢失（重建索引)
4.passwd文件丢失:重建password. orapword $ORACLE_HOME/dbs/
察看哪些用户被授予 dba权限
sql>select * from v$PWFILE_USERS;
select object_name from dba_objects where ....
重建passwd文件的过程:
Log in to the database by using OS authentication.
2. Set the REMOTE_LOGIN_PASSWORDFILE parameter
to NONE and restart the database.
3. Re-create the password file by using orapwd.
4. Set REMOTE_LOGIN_PASSWORDFILE to EXCLUSIVE.
5. Add users to the password file and assign
appropriate privileges to each user.
6. Restart the instance.
$ orapwd file=$ORACLE_HOME/dbs/orapwORCL
password=admin entries=5
entries=5 表示最多允许存储 5个sysdba用户。
自己独占password,选择 exclusive.( 密码文件不共享给其他数据库)
上面是操作系统验证，密码验证。
修改sys用户的文件，存在密码验证的方式。
关于passwd密码文件的理解，这个文件主要存储的是sysdba用户及其密码。
可以通过修改 数据库sys用户密码来修改这个文件，也可以通过 orapwd命令来修改。
任何有sysdba权限用户登陆上来之后，show user；
显示都是sys用户。
database下完全还原，不完全还原
不完全还原:
1>基于时间点
2>基于scn
3>基于auto,基于cancel
基于cancel 的不完全还原：指的，在还原时如果cancel了某些日志，对于cancel 的日志来说，这些日志不被应用到恢复数据文件过程中来
对于用户管理，rman 下还原的理解:
这都是针对media损坏的处理方法，而且是通过 server process来做恢复操作，
对于完全的恢复，会通过控制文件寻找scn和RBA(redo block address)，再查找redo里面
对应的 rba地址，并把它对应的信息，以及以后的信息都应用到数据块上去。
如果是不完全的恢复，会通过控制文件mount数据库，以后通过比对日志文件（归档，联机)和
数据文件来恢复数据库。
完全还原和不完全还原的理解:
完全还原的先提条件：
1>控制文件没有被改动（归档和在线日志文件没有丢失)
2>完全恢复，data打开后，过一段时间才会利用undo 回滚。这期间如果对数据读写，都是对 old img做操作。
不完全恢复：
1>对控制文件恢复，不论是重建还是从旧的文件里恢复，都是不完全恢复
2>不完全恢复的可能有,arc( 归档日志) 文件丢失，unarchived 联机日志丢失，current redo group丢失.
2>不完全恢复和完全恢复的区别是归档日志文件或在线日志文件没有完全被应用。
热备块:
alter tablespace example begin backup;
恢复数据文件之后，不会自动Online，需要手动来做。
对数据块备份的时候，数据表空间需要处于logging状态，否则丢失的数据可能找不回来。
不完全恢复的例子:
1.alter tablespace exam... begin backup;
2.copy
3..............................................end backup;
4.test
5.alter tablespace example offline immeidate;
6.recover datafiles ...;
7.alter tablespace ... online;
对数据的datafile 如果采用了offline immediate,需要介质恢复来进行还原。
rman 下的备份 和 user manager备份的区别:
rman的备份省去了寻找归档日志文件的过程。
rman会自动从最近的备份集把数据restore回来。recover 的时候，会利用 rman自动restore回来的归档来恢复。
rman>recover tablespace inv_tbs delete archivelog;
根据上面的命令，rman 会从备份结果集寻找归档日志文件，还原到操作系统上。（选择 delete archivelog会在还原结束后，把还原回来的archive log 再干掉)
1.不完全还原还原(必须还原整个库，不能只还原某个表空间）
2.表空间的不完全还原
（原理是，做auxiliary，把backup set备份集恢复到auxiliary里）再把 auxiliary 导入到实际的空间里。
一条命令可以实现2定义的所有操作
3.用户定义的不完全还原
1> SQL>recover database until time;
2> until cacel
3> using backup controlfiles; （告诉 rman ,当前控制文件不作为控制文件和数据文件的比较里)
用户管理的不完全恢复:
test
1> user-managed ：做一个冷拷贝
2>抓取时间点,找sysdate,时间戳
3>open的时候做操作,switch
4>shutdown(正常或不正常都可以)
5>启动数据库到mount状态
6>overwrite oldfiles(数据文件,没redo,控制文件)
7>recover database until time ''
8>open database resetlogs;
(oracle 10G的时候,恢复到某个时间点)
如8:30做了open resetlogs 之后 ,以后再错误，再进行不完全恢复的时候(恢复到某个时间点)，就无法指定恢复到8:30之前了.
处理过程:
alter session set nls_date_format='yyyy-mon-dd hh24:mi:ss';
select sysdate from dual;
conn scott/tiger;
create table testf(id number);
insert ...
commit;
shutdown abort;
startup mount;
RMAN>restore database(控制文件,数据文件)
RMAN>restore archivelog sequence between 14 and 22;
until sequence 15(不会到15,只会应用到 14)
restore database:不会恢复控制文件,只会从 backup set里面把数据文件恢复过来.
如果undo表空间丢失,如何恢复数据库
加offline参数屏蔽所有file.（详细见oracle 8i恢复手册)
rman下不完全恢复数据库
rman> run{
set until_time="to_date('w005-11-28:11:44:00','yyyy-mm-dd hh24:mi:55')";
restore database;
recover database;
alter database open resetlogs;
}
如何跨过以前的老的backup set来恢复数据文件,
1.把backup set设置为 unvailable
2.set until time(越过一个备份集,到我指定的备份集)
set until sequence 120 thread 1;
(rac 中第2个实例是 thread 2)
restore points:创建时刻的时间戳(存在数据库)
SQL>create restore point before load;
select * from v$restore_point;
time_stamp 和stamp比较,带时区功能,更准确,精度更高.
把握数据的能力和本领
还原控制文件 -> restore controlfile to '/oradata/ctlfile.bak' from autobackup;
重建控制文件->只会dump出结构,不会导出备份时间信息(新建的ctl file里面不会包含备份的信息)
重建控制文件的过程:
1.把数据库down机
2.启动到nomount状态
3.把...贴过来运行一把( recover.sql backup controlfile to trace生成的脚本)
4.recover database using backup controlfile;
恢复只读表空间,控制文件中记录的是 readonly
重建控制文件的时候,read only 的datafile 将变成 missing file,需要重新建立.
闪回:(9i的闪回,需要建立表结构,通过logminer来抓)
(基于 database的闪回)
truncate: flash back database ->open resetlogs
基于版本的查询:把所有历史数据找出,针对SQL语句来闪回,transaction
让recyclebin=on,才支持 flashback drop;
log里默认是on,sys用户不支持 recyclebin;
删除表的时候,constraints,index 都会被级联的删除.
DBA_FREE_SPACE:表空间,空间使用率满了,系统会自动清除掉那些保存在 recyclebin里的文件.
索引重回收站拿出来后,trigger ,constraints都会失效,都需要手工rebuild.
recyclebin 处理同名.
闪回表,会遵循一个策略,last in,first out;
如果闪回,先把最近一个时间点被删除的同名表恢复出来.
purge 表,则会删除最老的表.(最早被删除的同名表)
purge tablespace(干掉某个表空间下的recyclebin.
purge [user_,DBA_] recyclebin 干掉某个用户下的 recycle bin.
绕过回收站
1.drop table test purge;
2.drop tablespace
3.drop user cascade(用户级别被级连删除)
都会直接把数据删除而不放进回收站。
查看回收站:
show recyclebin;
select * from user_recyclebin;
闪回整个数据库:
Flashback Database Architecture
When you enable Flashback Database, the new RVWR background process is started. This
background process sequentially writes Flashback Database data from the flashback buffer to the
Flashback Database logs, which are circularly reused. Subsequently, when a FLASHBACK
DATABASE command is issued, the flashback logs are used to restore to the blocks’ before
images, and then redo data is used to roll forward to the desired flashback time.
The overhead of enabling Flashback Database depends on the read-write mix of the database
workload. Because queries do not need to log any flashback data, the more write-intensive the
workload, the higher the overhead of turning on Flashback Database.
Note: Flashback Database logs are not archived.
闪回buffer,flashback buffer(在share pool里面),
闪回日志比较特殊,闪回数据库是依靠闪回日志,logminer挖掘归档日志来保证一致性的.
truncate table emp;怎么恢复？
[先闪回到过去某个时刻,再利用归档日志log miner 做前滚)
闪回日志保留多久
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT EXCLUSIVE;
SQL> ALTER SYSTEM SET
2 DB_FLASHBACK_RETENTION_TARGET=2880 SCOPE=BOTH;
SQL> ALTER DATABASE FLASHBACK ON;
SQL> ALTER DATABASE OPEN;
数据库必须在归档模式才能用闪回.
Flashback Database: Examples
RMAN> FLASHBACK DATABASE TO TIME =
2> "TO_DATE('2004-05-27 16:00:00',
3> 'YYYY-MM-DD HH24:MI:SS')";
RMAN> FLASHBACK DATABASE TO SCN=23565;
RMAN> FLASHBACK DATABASE
2> TO SEQUENCE=223 THREAD=1;
SQL> FLASHBACK DATABASE
2 TO TIMESTAMP(SYSDATE-1/24);
SQL> FLASHBACK DATABASE TO SCN 53943;
SQL> FLASHBACK DATABASE TO RESTORE POINT b4_load;
闪回哪些条件下没有意义:
1.控制文件重建了
2.表空间被drop掉了
3.数据文件被shrunk(datafile 缩小)
shrunk的目的:
因为大量的delete ,会产生高水位,即使数据被释放,高水位还在.
truncate,move,shrunk的方式都可以降低高水位.
为了减少对不满空间的 block的 shrunk,HWM 收缩高水位,让有用数据全部放到 不满空间以下.
这是通过行迁移实现的,不会影响block 里面的pctfree参数.
flashback database,只能做一次,如果数据库已经闪回一次并alter database open resetlogs 了;
无法再次闪回了。
解决这个问题,我们可以把数据库flashback后,不立即resetlogs open,而是 readonly open.
查看有没有我们想闪回的数据,如果没有,再重新闪回.
查看闪回区是否还有空间.
p207面.
SQL> SELECT name, space_limit AS quota,
2 space_used AS used,
3 space_reclaimable AS reclaimable,
4 number_of_files AS files
5 FROM v$recovery_file_dest ;
NAME QUOTA USED RECLAIMABLE FILES
------------------------ ---------- ---------- ----------- -----
/u01/flash_recovery_area 5368709120 2509807104 203386880 226
guarantee restore point;
保证必须能够闪回数据库,如果不能继续保证,数据库会hang住.
