OCP笔记

==演练数据文件丢失的恢复：==============================================================

测试环境：oracle 11g x64 linux / archivelog

1. 建立一个表空间test，数据文件为test01.dbf  并建立一张表test_tbl

　　create tablespace test datafile '/u01/test01.dbf' size 20M;

　　create table test_tbl (id number) tablespace test;

　　insert into test_tbl values(33);

　　commit;

2. 删除test01.dbf

　　0.查看v$recover_file

　　a. 在操作系统层面删除test01.dbf

　　　　　　rm /u01/test01.dbf

　　b.再次查看v$recover_file表，将会显示有一条记录，代表有一个需要恢复的文件, 记住此文件的编号（假设为4）

　　c.验证此时无法再次读取test_tbl表。

　　　　alter system checkpoint;

　　　　退出并重新进入sqlplus,然后select * from test_tbl，此时会无法看到表的内容。

3.恢复test01.dbf

　　a.重新test01.dbf文件

　　　　alter database create datafile 4　　（4代表/u01/test01.dbf文件在ORACLE里的编号）

　　b.进行恢复（应用日志进行前滚）

　　　　recover datafile 4

　　　　恢复完成后，执行select * from test_tbl将会出错，显示如下错误：

　　　　　　ERROR at line 1:
　　　　　　ORA-00376: file 5 cannot be read at this time
　　　　　　ORA-01110: data file 5: '/u01/test01.dbf'

　　c.上线

　　　　alter database datafile 4 online

4.验证

　　再次执行select * from test_tbl，成功。

结论：

　　只要数据库在archivelog模式，之后建立的任何的数据文件都有可能在丢失后找回来。如果是在开启archivelog之前建立的数据文件，则需要一个archivelog之后的一个备份。

====================================================================

[adr]

Automatic Diagnostic Repository=ADR

show parameter diag:查看

 

show home

help set home

set home diag/rdbms/orcl/orcl

show alert -tail -f

 

 [表分析及空间整理]

 dbms_stats.gather_table_stats(ownname=>'jnsn',

　　　　　　　　　　　　　　　　tabname => 'test_table',

　　　　　　degree => 10);   //cpu数量

然后查看 select  user_tables中的记录数。

增加大量记录后，查看占用空间情况 user_segement

全部DELETE后，再次查看user_segement

会发现空间并没有减少。

段收缩：

alter table name enable row movement

alter table name move;  //INDEX将失效，TRIGGER等也将失效

alter table name shink space {COMPACT||CASCADE};  //回收高水位

[建索引]

create index ....   online'  //一定要加ONLINE参数，否则会造成整表锁定，需要很久才能完成.online只在开始及结束时锁表，中间建立的时侯不锁表。

查看索引的状态: user_indexes中的状态status

 

 【spfile pfile】

create pfile from spfile

create spfile from pfile

默认的文件名是spfileSID.ora