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之后的一个备份。
====================================================================
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数量
然后查看 selectuser_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
页:
[1]