在归档模式下的基于时间点的不完全恢复

在归档模式下的基于时间点的不完全恢复
sql>shutdown immediate

==
  对数据进行全备份  full backup database
==
sql> startup

==
  修改数据
  update test2 set.. 10:44:01
  drop table test1 10:45:05 ==>错误操作
==
sql>shutdown immediate

==
  备份事故现场
注意：
  在实际生产环境中，在做恢复的之前，一定要全备份目前的数据库,即：保存现场
  因为在恢复的过程不一定是一次可以恢复到我想得到状态。
==
  restore datafile
  现将之前全备份的所有数据文件(*.dbf)Copy回,不要恢复control file, redo logs等
==
sql>startup mount
sql>recover database until time '2009-11-27:10:45:01'
   Media recovery complete.
sql>alter database open resetlogs;
    Database altered
sql>conn test/test
sql>select table_name from user_tables;
    TABLE_NAME
    ----------
     TEST           
     TEST1          
     TEST2    
==
   这里发现之前drop 掉的table test1没有被删除了。

   接下来又要对整个数据进行一次全备份，因为以前的归档日志和数据都没有用了。
==     

在归档模式下的基于Cancel的不完全恢复,当前在线日志损坏

sql>shutdown immediate

==
  对数据进行全备份  full backup database
==
sql> startup

==
当前状态
==
sql> select table_name from user_tables

     TABLE_NAME
     ----------
     TEST

sql> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRS
---------- ---------- ---------- ---------- ---------- --- ---------------- ----
         1          1          0  104857600          1 YES UNUSED
         2          1          0  104857600          1 YES UNUSED
         3          1          1  104857600          1 NO  CURRENT          26-N

sql> alter system switch logfile;
sql> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRS
---------- ---------- ---------- ---------- ---------- --- ---------------- ----
         1          1          2  104857600          1 NO  CURRENT          27-N
         2          1          0  104857600          1 YES UNUSED
         3          1          1  104857600          1 YES ACTIVE           26-N

sql> create table test2 as select * from test;
sql> select table_name from user_tables
TABLE_NAME
----------
TEST
TEST2

sql> alter system switch logfile;
sql> select * from v$log;
    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRS
---------- ---------- ---------- ---------- ---------- --- ---------------- ----
         1          1          2  104857600          1 YES ACTIVE           27-N
         2          1          3  104857600          1 NO  CURRENT          27-N
         3          1          1  104857600          1 YES INACTIVE         26-N

sql> create table test3 as select * from test;
sql> select table_name from user_tables;
TABLE_NAME
-----------
TEST
TEST2
TEST3

sql> alter system switch logfile;
sql> select * from v$log;  ==>日志正好走完一个循环
    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRS
---------- ---------- ---------- ---------- ---------- --- ---------------- ----
         1          1          2  104857600          1 YES INACTIVE         27-N
         2          1          3  104857600          1 YES ACTIVE           27-N
         3          1          4  104857600          1 NO  CURRENT          27-N

sql> create table test4 as select * from test;
sql> select table_name from user_tables;

TABLE_NAME
-----------
TEST
TEST2
TEST3
TEST4

==
  修改数据

==
sql>shutdown immediate
==
  备份事故现场
注意：
  在实际生产环境中，在做恢复的之前，一定要全备份目前的数据库,即：保存现场
  因为在恢复的过程不一定是一次可以恢复到我想得到状态。
==
  restore datafile
  现将之前全备份的所有数据文件(*.dbf)Copy回,不要恢复control file, redo logs等
  并模拟当前日志文件丢失，可以直接删除
==
sql>startup mount
sql>recover database until cancel
ORA-00279: change 220847 generated at 11/27/2009 08:28:25
ORA-00289: suggestion : G:\ORACLE\ARC\ORCL_1_1.ARC
ORA-00280: change 220847 for thread 1 is in sequence #1

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
输入：auto

ORA-00279: change 221514 generated at 11/27/2009 13:29:04 needed for thread 1
ORA-00289: suggestion : G:\ORACLE\ARC\ORCL_1_2.ARC
ORA-00280: change 221514 for thread 1 is in sequence #2
ORA-00278: log file 'G:\ORACLE\ARC\ORCL_1_1.ARC' no longer needed for this
recovery

ORA-00279: change 222100 generated at 11/27/2009 13:32:35 needed for thread 1
ORA-00289: suggestion : G:\ORACLE\ARC\ORCL_1_3.ARC
ORA-00280: change 222100 for thread 1 is in sequence #3
ORA-00278: log file 'G:\ORACLE\ARC\ORCL_1_2.ARC' no longer needed for this
recovery

ORA-00279: change 222367 generated at 11/27/2009 13:34:18 needed for thread 1
ORA-00289: suggestion : G:\ORACLE\ARC\ORCL_1_4.ARC
ORA-00280: change 222367 for thread 1 is in sequence #4
ORA-00278: log file 'G:\ORACLE\ARC\ORCL_1_3.ARC' no longer needed for this
recovery

ORA-00308: cannot open archived log 'G:\ORACLE\ARC\ORCL_1_4.ARC'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 靠靠靠靠靠

SQL> recover database until cancel #再次输入
ORA-00279: change 222367 generated at 11/27/2009 13:34:18 needed for thread 1
ORA-00289: suggestion : G:\ORACLE\ARC\ORCL_1_4.ARC
ORA-00280: change 222367 for thread 1 is in sequence #4

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel #选Cancel因为此处ORCL_1_4.ARC没有归档
Media recovery cancelled.
SQL> alter database open resetlogs; #一定要 open resetlogs 重新生成log文件

Database altered.

sql>conn test/test
sql>select table_name from user_tables;
    TABLE_NAME
    ----------
     TEST           
     TEST1          
     TEST2   
     TEST3
==
   这里发现在恢复前当前日志的操作没有办法救回。TEST4没有办法找回了。

   接下来又要对整个数据进行一次全备份，因为以前的归档日志和数据都没有用了。
==     

posted @ 2009-12-01 14:53 gdufo| 编辑 收藏

Rman全备份不完全恢复数据库

posted @ 2009-12-01 09:58 gdufo| 编辑 收藏

9i和10g上rman全备的一点差别

我们知道，9i和10g下，用rman做全库备份时，rman会把数据文件、控制文件、参数文件等都备份，但是它们还有有差别的，先看看两者的备份日志：

--9i的rman全备日志

E:oracleora92in>rman target /

恢复管理器: 版本9.2.0.1.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

连接到目标数据库: SUK (DBID=1788145367)

RMAN> run{
2> allocate channel c1 type disk;
3> backup database format 'f:ackupsuk_%U';
4> sql 'alter system archive log current';
5> release channel c1;
6> }

分配的通道: c1
通道 c1: sid=17 devtype=DISK

启动 backup 于 22-6月 -07
通道 c1: 正在启动 full 数据文件备份集
通道 c1: 正在指定备份集中的数据文件
在备份集中包含当前的 SPFILE --备份参数文件
备份集中包括当前控制文件 --备份控制文件
输入数据文件 fno=00014 name=E:ORACLEORADATASUKHEBEI01.DBF
输入数据文件 fno=00001 name=E:ORACLEORADATASUKSYSTEM01.DBF
输入数据文件 fno=00002 name=E:ORACLEORADATASUKUNDOTBS01.DBF
输入数据文件 fno=00006 name=E:ORACLEORADATASUKSUK01.DBF
输入数据文件 fno=00007 name=E:ORACLEORADATASUKSUK02.DBF
输入数据文件 fno=00008 name=E:ORACLEORADATASUKSUK03.DBF
输入数据文件 fno=00003 name=E:ORACLEORADATASUKINDX01.DBF
输入数据文件 fno=00005 name=E:ORACLEORADATASUKUSERS01.DBF
输入数据文件 fno=00004 name=E:ORACLEORADATASUKTOOLS01.DBF
输入数据文件 fno=00009 name=E:ORACLEORADATASUKIND01.DBF
输入数据文件 fno=00010 name=E:ORACLEORADATASUKIND02.DBF
输入数据文件 fno=00011 name=E:ORACLEORADATASUKIND03.DBF
输入数据文件 fno=00012 name=E:ORACLEORADATASUKNEWUNDO01.DBF
输入数据文件 fno=00013 name=E:ORACLEORADATASUKNEWUNDO02.DBF
通道 c1: 正在启动段 1 于 22-6月 -07
通道 c1: 已完成段 1 于 22-6月 -07
段 handle=F:BACKUPSUK_07IKTQ6C_1_1 comment=NONE
通道 c1: 备份集已完成, 经过时间:00:02:27
完成 backup 于 22-6月 -07

sql 语句: alter system archive log current

释放的通道: c1


--可以看到，9i下，rman全备时是先备份参数文件、控制文件，再备份数据文件。
由于备份信息是放在控制文件中的，所以当次备份的控制文件是不包含当次的备份信息的（用include current controlfile也一样）.
在恢复时如果用备份的控制文件恢复，很可能遇到错误：

RMAN> restore database;

启动 restore 于 22-6月 -07

使用通道 ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/22/2007 13:27:03
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 14 found to restore
RMAN-06023: no backup or copy of datafile 13 found to restore
RMAN-06023: no backup or copy of datafile 12 found to restore
RMAN-06023: no backup or copy of datafile 11 found to restore
RMAN-06023: no backup or copy of datafile 10 found to restore
RMAN-06023: no backup or copy of datafile 9 found to restore
RMAN-06023: no backup or copy of datafile 8 found to restore
RMAN-06023: no backup or copy of datafile 7 found to restore
RMAN-06023: no backup or copy of datafile 6 found to restore
RMAN-06023: no backup or copy of datafile 5 found to restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore

--10g的rman全备日志
C:>rman target /

恢复管理器: Release 10.2.0.1.0 - Production on 星期二 6月 19 10:50:18 2007

Copyright (c) 1982, 2005, Oracle. All rights reserved.

连接到目标数据库: ORA10G (DBID=3939087858)

RMAN> run{
2> allocate channel c1 type disk;
3> backup database format 'f:ackupsuk_%U';
4> sql 'alter system archive log current';
5> release channel c1;
6> }

分配的通道: c1
通道 c1: sid=145 devtype=DISK

启动 backup 于 22-6月 -07
通道 c1: 启动全部数据文件备份集
通道 c1: 正在指定备份集中的数据文件
输入数据文件 fno=00006 name=E:ORACLEORADATAORA10GHEBEI01.DBF
输入数据文件 fno=00005 name=E:ORACLEORADATAORA10GSUK01.DBF
输入数据文件 fno=00001 name=E:ORACLEORADATAORA10GSYSTEM01.DBF
输入数据文件 fno=00003 name=E:ORACLEORADATAORA10GSYSAUX01.DBF
输入数据文件 fno=00002 name=E:ORACLEORADATAORA10GUNDOTBS01.DBF
输入数据文件 fno=00004 name=E:ORACLEORADATAORA10GUSERS01.DBF
通道 c1: 正在启动段 1 于 22-6月 -07
通道 c1: 已完成段 1 于 22-6月 -07
段句柄=F:BACKUPSUK_05IKTQ08_1_1 标记=TAG20070622T125639 注释=NONE
通道 c1: 备份集已完成, 经过时间:00:01:26
通道 c1: 启动全部数据文件备份集
通道 c1: 正在指定备份集中的数据文件
备份集中包括当前控制文件
在备份集中包含当前的 SPFILE
通道 c1: 正在启动段 1 于 22-6月 -07
通道 c1: 已完成段 1 于 22-6月 -07
段句柄=F:BACKUPSUK_06IKTQ2U_1_1 标记=TAG20070622T125639 注释=NONE
通道 c1: 备份集已完成, 经过时间:00:00:05
完成 backup 于 22-6月 -07

sql 语句: alter system archive log current

释放的通道: c1


可以看出，10g下全库备份的备份顺序与9i是相反的，它先备份数据文件，再备份控制文件、参数文件。
oracle已经意识到9i的这个不足，在10g中修复了。


在9i中，应该设置控制文件字段备份来避免上述问题。

E:oracleora92in>rman target /

恢复管理器: 版本9.2.0.1.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

连接到目标数据库: SUK (DBID=1788145367)

RMAN> run{
2> allocate channel c1 type disk;
3> CONFIGURE CONTROLFILE AUTOBACKUP ON;
4> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'f:ackupc
n_%F';
5> backup database format 'f:ackupsuk_%U';
6> sql 'alter system archive log current';
7> release channel c1;
8> }

正在使用目标数据库控制文件替代恢复目录
分配的通道: c1
通道 c1: sid=12 devtype=DISK

新的 RMAN 配置参数:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
已成功存储新的 RMAN 配置参数

新的 RMAN 配置参数:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'f:ackupcn_%F
';
已成功存储新的 RMAN 配置参数

启动 backup 于 22-6月 -07
通道 c1: 正在启动 full 数据文件备份集
通道 c1: 正在指定备份集中的数据文件
输入数据文件 fno=00014 name=E:ORACLEORADATASUKHEBEI01.DBF
输入数据文件 fno=00001 name=E:ORACLEORADATASUKSYSTEM01.DBF
输入数据文件 fno=00002 name=E:ORACLEORADATASUKUNDOTBS01.DBF
输入数据文件 fno=00006 name=E:ORACLEORADATASUKSUK01.DBF
输入数据文件 fno=00007 name=E:ORACLEORADATASUKSUK02.DBF
输入数据文件 fno=00008 name=E:ORACLEORADATASUKSUK03.DBF
输入数据文件 fno=00003 name=E:ORACLEORADATASUKINDX01.DBF
输入数据文件 fno=00005 name=E:ORACLEORADATASUKUSERS01.DBF
输入数据文件 fno=00004 name=E:ORACLEORADATASUKTOOLS01.DBF
输入数据文件 fno=00009 name=E:ORACLEORADATASUKIND01.DBF
输入数据文件 fno=00010 name=E:ORACLEORADATASUKIND02.DBF
输入数据文件 fno=00011 name=E:ORACLEORADATASUKIND03.DBF
输入数据文件 fno=00012 name=E:ORACLEORADATASUKNEWUNDO01.DBF
输入数据文件 fno=00013 name=E:ORACLEORADATASUKNEWUNDO02.DBF
通道 c1: 正在启动段 1 于 22-6月 -07
通道 c1: 已完成段 1 于 22-6月 -07
段 handle=F:BACKUPSUK_01IKTVM1_1_1 comment=NONE
通道 c1: 备份集已完成, 经过时间:00:01:55
完成 backup 于 22-6月 -07

启动 Control File and SPFILE Autobackup 于 22-6月 -07
段 handle=F:BACKUPCN_C-1788145367-20070622-00 comment=NONE
完成 Control File and SPFILE Autobackup 于 22-6月 -07

sql 语句: alter system archive log current

释放的通道: c1

posted @ 2009-12-01 09:24 gdufo| 编辑 收藏

数据文件出现坏快的解决之四(实际诊断案例)

问题：用户查询一个表时，报数据文件有坏块

目标：用户可以接受丢失这些坏块的数据，但该数据文件其它的好块应该可以查询数据。

下面是具体的步骤：

1.询问用户徐工出错的表名，收集出错信息
出错表名：
fsgazhjf.fsgazhjf_tac_20061018
trace文件中的出错信息：

***
Corrupt block relative dba: 0xb8428b33 (file 737, block 166707)
Fractured block found during user buffer read
Data in bad block -
type: 6 format: 2 rdba: 0xb8428b33
last change scn: 0x0000.0a66398d seq: 0x1 flg: 0x00
consistency value in tail: 0xbddc0601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

2.根据出错块id，查询出该块对应的物理表，跟第一步收集的比对
select * from dba_extents
where file_id=737 and block_id <= 166707 and (block_id + blocks - 1) >= 166707;

FSGAZHJF FSGAZHJF_TAC_20061018 TABLE FSGAZHJF_GSM_10 1201 737 166665 1048576 128 737

结果：的确是该表:FSGAZHJF_TAC_20061018，用户FSGAZHJF，表空间FSGAZHJF_GSM_10

3.查询该表，看报错信息是否和第一步一致
select count(1) from fsgazhjf.fsgazhjf_tac_20061018;

结果：果然报错

4.收集该表的所有索引
select * from dba_indexes where owner='FSGAZHJF' and lower(table_name)='fsgazhjf_tac_20061018';
no rows
结果：无索引

5.用dbv工具来check bad block
SQL> select file_id||' '||file_name from dba_data_files where file_id=737;

FILE_ID||''||FILE_NAME
------------------------------------------------------------------------------
--------------------
737 K:ORADATAORA8FSGAZHJF_GSM_10_50.DBF

C:>dbv file='K:ORADATAORA8FSGAZHJF_GSM_10_50.DBF' blocksize=8192 logfile='h:dbv.log'

DBVERIFY: Release 8.1.7.4.1 - Production on 星期四 11月 9 10:57:13 2006

(c) Copyright 2000 Oracle Corporation. All rights reserved.

DBVERIFY: Release 8.1.7.4.1 - Production on 星期四 11月 9 10:57:13 2006

(c) Copyright 2000 Oracle Corporation. All rights reserved.

DBVERIFY - 检验开始：FILE = K:ORADATAORA8FSGAZHJF_GSM_10_50.DBF
标记为损坏的页面166708
***
Corrupt block relative dba: 0xb8428b34 (file 0, block 166708)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0xcf012b08
last change scn: 0x0000.0a91bf69 seq: 0x1 flg: 0x00
consistency value in tail: 0x0ccc0601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

标记为损坏的页面166709
***
Corrupt block relative dba: 0xb8428b35 (file 0, block 166709)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0xce00e7e9
last change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00
consistency value in tail: 0x0ce80601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

标记为损坏的页面166710
***
Corrupt block relative dba: 0xb8428b36 (file 0, block 166710)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0xce00e7ea
last change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00
consistency value in tail: 0x0ce80601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

标记为损坏的页面166711
***
Corrupt block relative dba: 0xb8428b37 (file 0, block 166711)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0xce00e7eb
last change scn: 0x0000.0a910ce8 seq: 0x1 flg: 0x00
consistency value in tail: 0x39910601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

DBVERIFY - 完成检验

检查的页面总数 ：262144
处理的页面总数（数据）：262010
失败的页面总数（数据）：0
处理的页面总数（索引）：0
失败的页面总数（索引）：0
处理的页面总数（其它）：9
空的页面总数 ：120
标记损坏的页面总数：4
汇集的页面总数 ：0

检查结果：4个坏块，块号是166708 ~ 166711 ，经查询，发现都在一个extent里，属于同一张表

6.开始打标记
具体过程：
C:>sqlplus sys/change_on_install

SQL*Plus: Release 8.1.7.0.0 - Production on 星期四 11月 9 12:18:08 2006

(c) Copyright 2000 Oracle Corporation. All rights reserved.

连接到:
Oracle8i Enterprise Edition Release 8.1.7.4.1 - Production
With the Partitioning option
JServer Release 8.1.7.4.1 - Production

SQL>exec dbms_repair.admin_tables('REPAIR_TABLE',1,1,'USERS');

PL/SQL 过程已成功完成。

SQL>exec dbms_repair.admin_tables('ORPHAN_TABLE',2,1,'USERS');

PL/SQL 过程已成功完成。

SQL> declare
2 cc number;
3 begin
4 dbms_repair.check_object(schema_name => 'FSGAZHJF',object_name => 'FSGAZHJF_TAC_20061018',corrupt_count => cc);
5 dbms_output.put_line(a => to_char(cc));
6 end;
7 /

PL/SQL 过程已成功完成。

SQL>
SQL> select count(1) from repair_table;

COUNT(1)
----------
5

***这里发现5个坏快，dbv发现的是4个
SQL>
***具体信息参考repair_table.xls

发现marked_corrupt列 已经为true,可能不需执行
exec dbms_repair.skip_corrupt_blocks(schema_name => 'FSGAZHJF',object_name => 'FSGAZHJF_TAC_20061018',flags => 1);
了，通过下面的查询，确认不需要执行了

SQL> select count(1) from FSGAZHJF.FSGAZHJF_TAC_20061018;

COUNT(1)
----------
18804767

7.为该表建立两个索引
建立成功

证明可以对该表进行全表扫描了，问题解决，但丢失5个块的数据

posted @ 2009-11-25 22:31 gdufo| 编辑 收藏

数据文件出现坏快的解决之三(做个小试验)

试验的目的：
1.查找含坏块的数据的所有的rowid，从而得到损坏的数据量
2.查找损坏表的现在可用的数据量
3.根据1和2得到该表的本来的总的数据量

试验步骤：
1)参照 数据文件出现坏块时之五(如何利用dbms_repair来标记和跳过坏块)的第一步和第二部
  建了表空间block,用户test1107,表test,初始化了数据4512行,模拟了数据坏块，
  并用dbv得到所有的坏块ID(34~52,68~87)
 
2)参照 数据文件出现坏快时之三(如何查找坏块所含的数据表名称和数据的rowid)的步骤，查找出所有的坏块包含的rowid
  select /*+ index(test1107, i_test)*/ rowid
  from test1107.test
  where  dbms_rowid.rowid_to_absolute_fno(rowid,'TEST1107','TEST')=13
  and  (dbms_rowid.rowid_block_number(rowid) between 34 and 52 or
  dbms_rowid.rowid_block_number(rowid) between 68 and 87);
 
  结果返回了1598行坏记录
 
3)参照 数据文件出现坏块时之六(设置内部事件使exp跳过坏块)
    先exp报错，后来设置了events事件，然后exp出来，显示有 2914行，抓屏幕如下:
   
    C:\Documents and Settings\liguohua>exp test1107/aaaa tables=test file=d:\work\temp\test.dmp
  即将导出指定的表通过常规路径 ...
  . . 正在导出表                            TEST
  EXP-00056: 遇到 ORACLE 错误 1578
  ORA-01578: ORACLE 数据块损坏（文件号13，块号34）
  ORA-01110: 数据文件 13: 'D:\ORACLE\ORADATA\BLOCK.DBF'
  导出成功终止，但出现警告。

    C:\Documents and Settings\liguohua>alter system set events='10231 trace name context forever,level 10';    
   
    C:\Documents and Settings\liguohua>exp test1107/aaaa tables=test file=d:\work\temp\test.dmp
    即将导出指定的表通过常规路径 ...
     . . 正在导出表                            TEST       2914 行被导出
    在没有警告的情况下成功终止导出。
   
  结果表示有2914行记录可用
  另外一种方法，其实可以用

       select count(1) from test1107.test where rowid  not in
        (
          select /*+ index(test1107, i_test)*/ rowid
           from test1107.test
           where  dbms_rowid.rowid_to_absolute_fno(rowid,'TEST1107','TEST')=13
           and  (dbms_rowid.rowid_block_number(rowid) between 34 and 52 or
           dbms_rowid.rowid_block_number(rowid) between 68 and 87)
         );

   来查询可用的记录数，这样比较简单
4)1598 + 2914 = 4512，正好和原表总记录数吻合!

5)恢复events参数
  alter system set events='10231 trace name context off'; 

posted @ 2009-11-25 22:30 gdufo| 编辑 收藏

数据文件出现坏快的解决之二(设置内部事件使exp跳过坏块)

和数据文件出现坏块时之五中提到的前几步一样，先模拟出坏块，然后用dbv检查，此时，不用dbms_repair，而用下面的方法：

1.先exp该表试验一下

在这种情况下，如果有备份，需要从备份中恢复
如果没有备份，那么坏块部分的数据肯定要丢失了

在这个时候导出是不允许的:

E:\>exp eygle/eygle file=t.dmp tables=t

Export: Release 9.2.0.4.0 - Production on 星期一 3月 8 20:54:15 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集

即将导出指定的表通过常规路径 ...
. . 正在导出表 T
EXP-00056: 遇到 ORACLE 错误 1578
ORA-01578: ORACLE 数据块损坏（文件号4，块号35）
ORA-01110: 数据文件 4: 'E:\ORACLE\ORADATA\EYGLE\BLOCK.DBF'
导出成功终止，但出现警告。

2.当然，对于不同的情况需要区别对待 ，如果损失不是数据而是重要的oracle内部信息，则不能用set event
首先你需要检查损坏的对象，使用以下SQL：

--------------------------------------------------------------------------------

SQL> SELECT tablespace_name, segment_type, owner, segment_name

  2            FROM dba_extents

  3           WHERE file_id = 4

  4             and 35 between block_id AND block_id + blocks - 1

  5     ;

TABLESPACE_NAME                SEGMENT_TYPE       OWNER

------------------------------ ------------------ -------------------------

SEGMENT_NAME

---------------------------------------------------------------------------

BLOCK                          TABLE              'EYGLE'

'T'

--------------------------------------------------------------------------------

3.如果损失的是数据,ok，可以设置内部事件，使exp跳过这些损坏的block

10231事件指定数据库在进行全表扫描时跳过损坏的块

ALTER SYSTEM SET EVENTS='10231 trace name context forever,level 10' ;

SQL> ALTER SYSTEM SET EVENTS='10231 trace name context forever,level 10' ;

系统已更改。

然后我们可以导出未损坏的数据

SQL> host
Microsoft Windows XP [版本 5.1.2600]
(C) 版权所有 1985-2001 Microsoft Corp.

E:\

E:\>exp eygle/eygle file=t.dmp tables=t

Export: Release 9.2.0.4.0 - Production on 星期一 3月 8 20:57:13 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集

即将导出指定的表通过常规路径 ...
. . 正在导出表 T 8036 行被导出
在没有警告的情况下成功终止导出。

这时候数据成功导出.
然后我们可以drop table，recreate，然后导入数据

本例中
我们损失了

8192 - 8036 = 156 行数据

4.重建表，再导入

SQL> connect eygle/eygle
已连接。
SQL> drop table t;

表已丢弃。

SQL> host
Microsoft Windows XP [版本 5.1.2600]
(C) 版权所有 1985-2001 Microsoft Corp.

E:\Oracle\ora92\bin>cd \

E:\>imp eygle/eygle file=t.dmp tables=t

Import: Release 9.2.0.4.0 - Production on 星期一 3月 8 21:12:38 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

经由常规路径导出由EXPORT:V09.02.00创建的文件
已经完成ZHS16GBK字符集和AL16UTF16 NCHAR 字符集中的导入
. 正在将EYGLE的对象导入到 EYGLE
. . 正在导入表 "T" 8036行被导入
成功终止导入，但出现警告。

E:\>exit

SQL> select count(*) from t;

COUNT(*)
----------
8036

完成数据恢复

最后如果要取消events设置，做以下操作：

如果你在初始化参数中设置的
注释之

如果在命令行设置的
alter system set events='10231 trace name context off';

posted @ 2009-11-25 22:29 gdufo| 编辑 收藏

数据文件出现坏快的解决之一(如何利用dbms_repair来标记和跳过坏块)

http://blog.chinaunix.net/u1/50863/showart_400574.html

第一步：准备试验环境(建表空间，用户，表，初始化一些数据，然后破坏对应的数据文件)

E:\Oracle\ora92\bin>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on 星期一 3月 8 20:27:15 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
E:\ORACLE\ORADATA\oracle92\SYSTEM01.DBF
E:\ORACLE\ORADATA\oracle92\UNDOTBS01.DBF
E:\ORACLE\ORADATA\oracle92\app01.DBF

grant dba to test1107;

SQL> create tablespace block datafile 'd:\oracle\oradata\block.dbf' size 2M;
表空间已创建。
SQL> create user test1107 identified by aaaa default tablespace block;
用户已创建
SQL> conn test1107/aaaa;
已连接。
SQL> create table test tablespace block as select * from all_tables;
表已创建。
SQL> insert into test select * from test;
已创建8行。
SQL> /
已创建16行。
SQL> /
已创建32行。
SQL> /
已创建64行。
SQL> /
已创建128行。
SQL> /
已创建256行。
SQL> /
已创建512行。
SQL> /
已创建1024行。
SQL> /
已创建2048行。
SQL> /
已创建4096行。
SQL> /
insert into test select * from test
*
ERROR 位于第 1 行:
ORA-01653: 表test1107.TEST无法通过8（在表空间BLOCK中）扩展

SQL> create index i_test on test(table_name);

Index created

SQL> alter system checkpoint;

System altered

SQL> connect sys/sys as sysdba
已连接。
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。

--使用UltraEdit编辑block.dbf，修改几个字符

SQL> startup
ORACLE 例程已经启动。

Total System Global Area   72424008 bytes
Fixed Size                   453192 bytes
Variable Size              46137344 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
数据库已经打开。
QL> select count(*) from test1107.test;

select count(*) from test1107.test

ORA-01578: ORACLE 数据块损坏（文件号13，块号9）
ORA-01110: 数据文件 13: 'D:\ORACLE\ORADATA\BLOCK.DBF'

第二步：利用dbv检查数据文件

dbv file='d:\oracle\ora92\block.dbf' blocksize=8192 logfile='d:\work\temp\dbv.log'
  日志：
   DBVERIFY - 验证完成

   检查的页总数         ：256
   处理的页总数（数据）：112
   失败的页总数（数据）：0
   处理的页总数（索引）：17
   失败的页总数（索引）：0
   处理的页总数（其它）：10
   处理的总页数 (段)  : 0
   失败的总页数 (段)  : 0
   空的页总数            ：102
   标记为损坏的总页数：15
   汇入的页总数           ：0

第三步：利用dbms_repair包进行处理
1.创建管理表：
SQL> connect sys/sys as sysdba
Connected to Oracle9i Enterprise Edition Release 9.2.0.1.0
Connected as SYS

SQL> exec DBMS_REPAIR.ADMIN_TABLES('REPAIR_TABLE',1,1,'USERS');

PL/SQL procedure successfully completed

SQL> exec DBMS_REPAIR.ADMIN_TABLES('ORPHAN_TABLE',2,1,'USERS');

PL/SQL procedure successfully completed

2.检查坏块：

 declare
    cc number;
 begin
    dbms_repair.check_object(schema_name => 'TEST1107',object_name => 'TEST',corrupt_count => cc);
    dbms_output.put_line(a => to_char(cc));
 end;

 15

PL/SQL 过程已成功完成。     

看到这里用dbms_repair.check，检查的结果corrupt_count＝15，有15个块损坏，和dbv的结果一致。

check完之后，在我们刚在创建的REPAIR_TABLE中查看块损坏信息：   

SQL> SELECT * from repair_table
在这个table中，可以看到损坏的block的信息，这里的信息和我们用dbv得到的一致。
我这个实验是在9i下模拟的，注意看MARKED_CORRUPT的值，这里经过check_object后，已经标识为TRUE了。
所以可以直接进行第四步了。按照oracle文档上的说法，在8i下，check_object只会检查坏块，MARKED_CORRUPT为false需要使用第3步，fix_corrupt_blocks定位 ，修改MARKED_CORRUPT为true，同时更新CHECK_TIMESTAMP。
这里我们经过实验，确认在9i下跳过第3步，是完全可行的。那么8i是否需要执行第三步，我没有实验过，但推测应该是不可以跳过的。  

3.定位坏块：

dbms_repair.fix_corrupt_blocks     

只有将坏块信息写入定义的REPAIR_TABLE后，才能定位坏块。 
declare
  cc number;
begin
  dbms_repair.fix_corrupt_blocks(schema_name => 'TEST1107',object_name => 'TEST',fix_count => cc);
  dbms_output.put_line(a => to_char(cc));
end;

4.跳过坏块：

我们前面虽然定位了坏块，但是，如果我们访问table还是会得到错误信息。   
这里需要用skip_corrupt_blocks来跳过坏块：

SQL> exec dbms_repair.skip_corrupt_blocks(schema_name => 'TEST1107',object_name => 'TEST',flags => 1);

PL/SQL procedure successfully completed

SQL> select count(*) from test1107.test;

  COUNT(*)
----------
      4490

5.处理index上的无效键值；

SQL> declare
  2  cc number;
  3  begin
  4  dbms_repair.dump_orphan_keys(schema_name => 'TEST1107',object_name => 'I_TEST',object_type => 2,
  5  repair_table_name => 'REPAIR_TABLE',orphan_table_name => 'ORPHAN_TABLE',key_count => CC);
  6  end;
  7  /

PL/SQL procedure successfully completed

SQL> SELECT * FROM ORPHAN_TABLE;

22 rows selected

表示损失了22行数据

我们根据这个结果来考虑是否需要rebuild index.

6.重建freelist：rebuild_freelists

SQL> exec dbms_repair.rebuild_freelists(schema_name => 'TEST1107',object_name => 'TEST');

PL/SQL procedure successfully completed

posted @ 2009-11-25 22:28 gdufo| 编辑 收藏

oracle 约束管理

1.define constraints as immediate or deferred

sql> alter session set constraint[s] = immediate/deferred/default;

     set constraint[s] constraint_name/all immediate/deferred;

sql> alter table add constraint ck_sales_1 initially immediate/deferred/default;
    
     alter table modify constraint ck_sales_1 initially

immediate/deferred/default;
    

2. sql> drop table table_name cascade constraints

  sql> drop tablespace tablespace_name including contents cascade constraints

3. define constraints while create a table

sql> create table xay(id number(7) constraint xay_id primary key deferrable

sql> using index storage(initial 100k next 100k) tablespace indx);

    primary key/unique/references table(column)/check

4.enable constraints

sql> alter table xay enable novalidate constraint xay_id; #enable novalidate 新

数据应用规则，旧数据不管
5.enable constraints

sql> alter table xay enable validate constraint xay_id; #enable validate 新数据

应用规则，旧数据也要检查

同样还有：disable novalidate, disable validate

6.disable constraints

sql> alter table sales disable constraint fk_1

sql> truncate table sales

7.using the exceptions table
#生效约束时将不符合约束条件的记录写入到exceptions table,反复检查，直至没有错误

sql> start d:\xxx\utlexcpt.sql
sql> desc exceptions
sql> alter table sales add constraint ch_sales_1(qty>15)
     enable validate exceptions into exceptions

8.obtaining constraint information
  dba_constraints dba_cons_columns

sql> select constraint_name, constraint_type. deferrable,deferred, validated
     from dba_constraints where owner='HR' and table_name ='employee'

sql> select c.constraint_name, c.constraint_type,cc.column_name
     from dba_constraints c, dba_cons_columns cc
     where c.owner ='HR' and c.table_name = 'employee'
     and c.owner = cc.owner and c.constraint_name = cc.constraint_name
     order by cc.position;

posted @ 2009-11-23 20:32 gdufo| 编辑 收藏

oracle 权限管理

1.system privileges: view => system_privilege_map ,dba_sys_privs,session_privs

2.grant system privilege

sql> grant create session,create table to managers;

sql> grant create session to scott with admin option;

with admin option can grant or revoke privilege from any user or role;

3.sysdba and sysoper privileges:

sysoper: startup,shutdown,alter database open|mount,alter database backup controlfile,

alter tablespace begin/end backup,recover database

alter database archivelog,restricted session

sysdba: sysoper privileges with admin option,create database,recover database until

4.password file members: view:=> v$pwfile_users

5.O7_dictionary_accessibility =true restriction access to view or tables in other schema

6.revoke system privilege

sql> revoke create table from karen;

sql> revoke create session from scott;

7.grant object privilege

sql> grant execute on dbms_pipe to public;

sql> grant update(first_name,salary) on employee to karen with grant option;

8.display object privilege : view => dba_tab_privs, dba_col_privs

9.revoke object privilege

sql> revoke execute on dbms_pipe from scott [cascade constraints];

10.audit record view :=> sys.aud$

11. protecting the audit trail

sql> audit delete on sys.aud$ by access;

12.statement auditing

sql> audit user;

13.privilege auditing

sql> audit select any table by summit by access;

14.schema object auditing

sql> audit lock on summit.employee by access whenever successful;

15.view audit option : view=> all_def_audit_opts,dba_stmt_audit_opts,dba_priv_audit_opts,

dba_obj_audit_opts

16.view audit result: view=> dba_audit_trail,dba_audit_exists,dba_audit_object,

dba_audit_session,dba_audit_statement

posted @ 2009-11-23 16:33 gdufo| 编辑 收藏

oracle 用户管理

Managing users

1.create a user: database authentication

sql> create user juncky identified by oracle default tablespace users
     temporary tablespace temp quota 10m on data
     password expire
     [account lock|unlock]
     [profile profilename|default];

2.change user quota on tablespace

sql> alter user juncky quota 0 on users;

    #0  代表以后不能再新增对像,之前已经建好的还将保留

3.drop a user

sql> drop user juncky [cascade];
   #[cascade],删除与用户相关的所有对像，如table, index,trriger
   #如果当前用户正连接在oracle上，是不能够被删除的。

4. monitor user

view: dba_users , dba_ts_quotas

posted @ 2009-11-23 16:00 gdufo| 编辑 收藏