在歸檔模式下的基于時間點的不完全恢復

在歸檔模式下的基于時間點的不完全恢復
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| 編輯 收藏