ocp原廠培訓筆記(第七天)

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 <ts_name> including contents;
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住.