當前位置:首頁 » 數據倉庫 » logminer跨資料庫
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

logminer跨資料庫

發布時間: 2023-07-03 03:12:51

『壹』 資料庫系統中的常見故障有哪些

新增archives 時的狀況:
條件和假設:自上次鏡像備份以來已經生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的鏡像(冷)拷貝;archive log(s) 可用。
恢復步驟:
1. 如果資料庫尚未關閉,則首先把它關閉: $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2. 將備份文件抄送回原始地點: 所有Database Files
所有Control Files(沒有archive(s) 或redo(s) 的情況下,control files 的更新無任何意義)
所有On-Line Redo Logs (Not archives) init.ora file(選項)
3. 啟動資料庫: $ svrmgrl
svrmgrl> connect internal
svrmgrl> startup
數據文件, 重作日誌和控制文件同時丟失或損壞:
條件和假設:Archivelog Mode; 有同步的所有所失文件的鏡像(冷)拷貝;archive log(s) 可用
恢復步驟(必須採用不完全恢復的手法):
1. 如果資料庫尚未關閉,則首先把它關閉: $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2. 將備份文件抄送回原始地點:
所有Database Files
所有Control Files
所有On-Line Redo Logs(Not archives)

init.ora file(選項)

3. 啟動資料庫然而並不打開:

svrmgrl>startup mount

4. 做不完全資料庫恢復,應用所有從上次鏡像(冷)備份始積累起來的archives:

svrmgrl> recover database until cancel using backup controlfile;

......

......

cancel

5. Reset the logfiles (對啟動而言不可省略):

svrmgrl> alter database open resetlogs;

6. 關閉資料庫並做一次全庫冷備份。

數據文件和控制文件同時丟失或損壞:

條件和假設:Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷貝;archive log(s) 可用

恢復步驟:

1. 將冷拷貝的datafiles(s) 和control file(s) 抄送回原始地點:

$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf

$ cp /backup/control1.ctl /disk1/control1.ctl

2. 以mount 選項啟動資料庫:

$ svrmgrl

svrmgrl> connect internal

svrmgrl> startup mount

3. 以舊的control file 來恢復資料庫:

svrmgrl> recover database until cancel using backup controlfile;

*** 介質恢復完成

(須在應用完最後一個archive log 後cancel )

4. Reset the logfiles (對啟動而言不可省略):

svrmgrl> alter database open resetlogs;

重作日誌和控制文件同時丟失或損壞時:

條件和假設:Control Files 全部丟失或損壞;Archivelog Mode; 有Control Files 的鏡像(冷)拷貝

恢復步驟:

1. 如果資料庫尚未關閉,則首先把它關閉:

$ svrmgrl

svrmgrl> connect internal

svrmgrl> shutdown abort

svrmgrl>exit

2. 以Control File 的鏡像(冷)拷貝覆蓋損壞了的Control File:

$ cp /backup/control1.ctl /disk1/control1.ctl

3. 啟動資料庫然而並不打開:

$ svrmgrl

svrmgrl> connect internal

svrmgrl> startup mount

4. Drop 壞掉的redo log (排除硬體故障):

svrmgrl> alter database drop logfile group 2;

5. 重新創建redo log:

svrmgrl> alter database add logfile group 2 '/orig_loc/log2.dbf' size 10M;

6. 以舊的control file 來恢復資料庫:

svrmgrl> recover database until cancel using backup controlfile;

(必須馬上cancel )

7. Reset the logfiles (對啟動而言不可省略):

svrmgrl> alter database open resetlogs;

8. 關閉資料庫並做一次全庫冷備份

只發生歸檔重作日誌丟失或損壞時:

根據不同環境和情況,選擇下述手段之一:

a. 馬上backup 全部datafiles (如果系統採用一般熱備份或RMAN 熱備份)

b. 馬上正常關閉資料庫並進行冷備份(如果系統採用冷備份)

c. 冒險前進!不做備份而讓資料庫接著跑,直等到下一個備份周期再做備份。這是在賭資料庫在下一個備份周期到來之前不會有需要恢復的錯誤發生。

注意:冒險前進的選擇:如果發生錯誤而需要資料庫恢復,則最多隻能恢復到出問題archive log 之前的操作現場。從另一個角度講,archive log(s) 出現問題時,資料庫若不需要恢復則其本身並沒有任何問題。

Oracle邏輯結構故障的處理方法:

邏輯結構的故障一般指由於人為的誤操作而導致重要數據丟失的情況。在這種情況下資料庫物理結構是完整的也是一致的。對於這種情況採取對原來資料庫的全恢復是不合適的,我們一般採用三種方法來恢復用戶數據。

採用exp/imp工具來恢復用戶數據:

如果丟失的數據存在一個以前用exp命令的備份,則可以才用這種方式。

1. 在資料庫內創建一個臨時用戶:

svrmgrl>create user test_user identified by test;

svrmgrl>grant connect,resource to test_user;

2. 從以前exp命令備份的文件中把丟失數據的表按照用戶方式倒入測試用戶:

$imp system/manager file=export_file_name tables=(lost_data_table_name…) fromuser=lost_data_table_owner touser=test_user constraint=n;

3. 用相應的DML語句將丟失的數據從測試用戶恢復到原用戶。

4. 將測試用戶刪除:

svrmgrl>drop user test_user cascede;

採用logminer來恢復用戶數據:

Logminer是oracle提供的一個日誌分析工具。它可以根據數據字典對在線聯機日誌、歸檔日誌進行分析,從而可以獲得資料庫的各種DML操作的歷史記錄以及各種DML操作的回退信息。根據這些用戶就可以將由於誤操作而丟失的數據重新加入資料庫內。

1. 確認資料庫的utl_file_dir參數已經設置,如果沒有則需要把這個參數加入oracle的初始化參數文件,然後重新啟動資料庫。下面例子中假設utl_file_dir=』/opt/oracle/db01』;

2. 創建logminer所需要的數據字典信息,假設生成的數據字典文本文件為dict.ora:

svrmgrl>execute dbms_logmnr_d.build(dictionary_filename=>'dict.ora', dictionary_location=>'/opt/oracle/db01』);

3. 確定所需要分析的日誌或者歸檔日誌的范圍。這可以根據用戶誤操作的時間來確定大概的日誌范圍。假設用戶誤操作時可能的日誌文件為/opt/oracle/db02/oradata/ORCL/redo3.log和歸檔日誌』/opt/oracle/arch/orcl/orclarc_1_113.ora』。

4. 創建要分析的日誌文件列表,按日誌文件的先後順序依次加入:

svrmgrl>execute dbms_logmnr.add_logfile(logfilename=>』/opt/oracle/arch/orcl/orclarc_1_113.ora』,options=>dbms_logmnr.NEW);

svrmgrl> execute dbms_logmnr.add_logfile(logfilename=>』 /opt/oracle/db02/oradata/ORCL/redo3.log』,options=>dbms_logmnr.ADDFILE);

5. 開始日誌分析,假設需要分析的時間在』2003-06-28 12:00:00』和』2003-06-28 13:00:00』之間:

svrmgrl>execute dbms_logmnr.start_logmnr(dictfilename=>』 /opt/oracle/db01/dict.ora』,starttime=>to_date(』 2003-06-28 12:00:00』,』YYYY-MM-DD HH:MI:SS』),endtime=>to_date(to_date(『2003-06-28 13:00:00』,』YYYY-MM-DD HH:MI:SS』));

6. 獲取分析結果:

svrmgrl>select operation,sql_redo,sql_undo from v$logmnr_contents;

7. 根據分析結果修復數據。

8.結束logmnr:

svrmgrl>dbms_logmnr.end_logmnr;

9. 用適當的方法對原資料庫進行資料庫全備份。

利用備份恢復用戶數據:

採用這種方法時並不是在原資料庫進行恢復,而是利用資料庫備份在新的機器上重新建立一個新的資料庫。通過備份恢復在新機器上將資料庫恢復到用戶誤操作前,這樣就可以獲得丟失的數據將其恢復到原資料庫。

1. 在新的機器上安裝資料庫軟體。

2. 對於採用帶庫備份的現場,需要在新的資料庫伺服器上安裝調試相應的備份管軟體。

3. 根據用戶誤操作的時間點進行基於時間點的資料庫恢復操作。對於沒有採用帶庫備份的現場,可以選取用戶誤操作前最近的備份磁帶進行恢復;對於才用帶庫備份的點可以通過基於時間恢復點恢復的rman腳本來進行恢復。

4.重新打開資料庫:

svrmgrl>alter database open resetlogs;

5. 從新的資料庫中獲取丟失的用戶數據,通過DML操作將其恢復到原資料庫中。

6. 用適當的方法對原資料庫進行資料庫全備份。

『貳』 深入分析Oracle資料庫日誌文件(1)

作為Oracle DBA 我們有時候需要追蹤數據誤刪除或用戶的拍則惡意操作情況 此時我們不僅需要查出執行這些操作的資料庫賬號 還需要知道操作是由哪台客戶端(IP地址等)發出的 針對這些問題 一個最有效實用而又低成本的方法就是分析Oracle資料庫的日誌文件 本文將就Oracle日誌分析技術做深入探討 一 如何分析即LogMiner解釋 從目前來看 分析Oracle日誌的唯一方法就是使用Oracle公司提供的LogMiner來進行 Oracle資料庫的所有更改都記錄在日誌中 但是原始的日誌信息我們根本無法看懂 而LogMiner就是讓我們看懂日誌信息的工具 從這一點上看 它和tkprof差不多 一個是用來分析日誌信息 一個則是格式化跟蹤文件 通過對日誌的分析我們可以實現下面的目的 查明資料庫的邏輯更改 偵察並更正用戶的誤操作 執行事後審計 執行變化分析 不僅如此 日誌中記錄的信息還包括 資料庫的更改歷史 更改類型(INSERT UPDATE DELETE DDL等) 更改對應的SCN號 以及執行這些操作的用戶信息等 LogMiner在分析日誌時 將重構等價的SQL語句和UNDO語句(分別記錄在V$LOGMNR_CONTENTS視圖的SQL_REDO和SQL_UNDO中) 這里需要注意的是等價語句 而並非原始SQL語句 例如 我們最初執行的是 delete a where c <> cyx ; 而LogMiner重構的是等價的 條DELETE語句 所以我們應該意識到V$LOGMNR_CONTENTS視圖中顯示的並非是原版的現實 從資料庫角度來講這是很容易理解的 它記錄的是元操作 因為同樣是 delete a where c <> cyx ; 語句 在不同的環境中 實際刪除的記錄數可能各不相同 因此記錄這樣的語句實際上並沒有什麼實際意義 LogMiner重構的是在實際情況下轉化成元操作的多個單條語句 另外由於Oracle重做日誌中記錄的並非原始的對象(如表以及其中的列)名稱 而只是它們在Oracle資料庫中的內部編號(對於表來說是它們在資料庫中的對象ID 而對於表中的列來說 對應的則是該列在表中的排列序號 COL COL 等) 因此為了使LogMiner重構出的SQL語句易於識別 我們需要將這些編號轉化成相應的名稱 這就需要用到數據字典(也就說LogMiner本身是可以不用數據字典的 詳見下面的分析過程) LogMiner利用DBMS_LOGMNR_D BUILD()過程來提吵鏈取數據字典信息 LogMiner包含兩個PL/SQL包和幾個視圖 dbms_logmnr_d包 這個包只包括一個用於提取數據字典信息的過程 即dbms_logmnr_d build()過程 dbms_logmnr包 它有三個過程 add_logfile(name varchar options number) 用來添加/刪除用於分析的日誌文件 start_logmnr(start_scn number end_scn number start_time number end_time number dictfilename varchar options number) 用來開啟日誌分析 同時確定分析的時間/SCN窗升賀孫口以及確認是否使用提取出來的數據字典信息 end_logmnr() 用來終止分析會話 它將回收LogMiner所佔用的內存 與LogMiner相關的數據字典 v$logmnr_dictionary LogMiner可能使用的數據字典信息 因logmnr可以有多個字典文件 該視圖用於顯示這方面信息 v$logmnr_parameters 當前LogMiner所設定的參數信息 v$logmnr_logs 當前用於分析的日誌列表 v$logmnr_contents 日誌分析結果 二 Oracle i LogMiner的增強 支持更多數據/存儲類型 鏈接/遷移行 CLUSTER表操作 DIRECT PATH插入以及DDL操作 在V$LOGMNR_CONTENTS的SQL_REDO中可以看到DDL操作的原句(CREATE USER除外 其中的密碼將以加密的形式出現 而不是原始密碼) 如果TX_AUDITING初始化參數設為TRUE 則所有操作的資料庫賬號將被記錄 提取和使用數據字典的選項 現在數據字典不僅可以提取到一個外部文件中 還可以直接提取到重做日誌流中 它在日誌流中提供了操作當時的數據字典快照 這樣就可以實現離線分析 允許對DML操作按事務進行分組 可以在START_LOGMNR()中設置MITTED_DATA_ONLY選項 實現對DML操作的分組 這樣將按SCN的順序返回已經提交的事務 支持SCHEMA的變化 在資料庫打開的狀態下 如果使用了LogMiner的DDL_DICT_TRACKING選項 Oracle i的LogMiner將自動對比最初的日誌流和當前系統的數據字典 並返回正確的DDL語句 並且會自動偵察並標記當前數據字典和最初日誌流之間的差別 這樣即使最初日誌流中所涉及的表已經被更改或者根本已經不存在 LogMiner同樣會返回正確的DDL語句 在日誌中記錄更多列信息的能力 例如對於UPDATE操作不僅會記錄被更新行的情況 還可以捕捉更多前影信息 支持基於數值的查詢 Oracle i LogMiner在支持原有基於元數據(操作 對象等)查詢的基礎上 開始支持基於實際涉及到的數據的查詢 例如涉及一個工資表 現在我們可以很容易地查出員工工資由 變成 的原始更新語句 而在之前我們只能選出所有的更新語句 三 Oracle i/ i的日誌分析過程 LogMiner只要在實例起來的情況下都可以運行 LogMiner使用一個字典文件來實現Oracle內部對象名稱的轉換 如果沒有這個字典文件 則直接顯示內部對象編號 例如我們執行下面的語句 delete from C A where C = gototop and ROWID = AAABg AAFAAABQaAAH ;如果沒有字典文件 LogMiner分析出來的結果將是 delete from UNKNOWN OBJ# where COL = HEXTORAW( d a d ae ) and ROWID = AAABg AAFAAABQaAAH ; 如果想要使用字典文件 資料庫至少應該出於MOUNT狀態 然後執行dbms_logmnr_d build過程將數據字典信息提取到一個外部文件中 下面是具體分析步驟 確認設置了初始化參數 UTL_FILE_DIR 並確認Oracle對改目錄擁有讀寫許可權 然後啟動實例 示例中UTL_FILE_DIR參數如下 SQL> show parameter utlNAME TYPEvalue utl_file_dir string/data /cyx/logmnr 這個目錄主要用於存放dbms_logmnr_d build過程所產生的字典信息文件 如果不用這個 則可以不設 也就跳過下面一步 生成字典信息文件 exec dbms_logmnr_d build(dictionary_filename => dic ora dictionary_location => /data /cyx/logmnr ); 其中dictionary_location指的是字典信息文件的存放位置 它必須完全匹配UTL_FILE_DIR的值 例如 假設UTL_FILE_DIR=/data /cyx/logmnr/ 則上面這條語句會出錯 只因為UTL_FILE_DIR後面多了一個 / 而在很多其它地方對這一 / 是不敏感的 dictionary_filename指的是放於字典信息文件的名字 可以任意取 當然我們也可以不明確寫出這兩個選項 即寫成 exec dbms_logmnr_d build( dic ora /data /cyx/logmnr ); 如果你第一步的參數沒有設 而直接開始這一步 Oracle會報下面的錯誤 ERROR at line :ORA : initialization parameter utl_file_dir is not setORA : at SYS DBMS_LOGMNR_D line ORA : at SYS DBMS_LOGMNR_D line ORA : at line 需要注意的是 在oracle for Windows版中會出現以下錯誤 : : SQL> execute dbms_logmnr_d build( oradict ora c:oracleadminoralog );BEGIN dbms_logmnr_d build( oradict ora c:oracleadminoralog ); END;*ERROR at line :ORA : Subscript outside of limitORA : at SYS DBMS_LOGMNR_D line ORA : at line 解決辦法 編輯 $ORACLE_HOME/rdbms/admindbmslmd sql 文件 把其中的TYPE col_desc_array IS VARRAY( ) OF col_description;改成 TYPE col_desc_array IS VARRAY( ) OF col_description; 保存文件 然後執行一遍這個腳本 : : SQL> @c:oracleora dbmsadmindbmslmd sqlPackage created Package body created No errors Grant succeeded 然後重新編譯DBMS_LOGMNR_D包 : : SQL> alter package DBMS_LOGMNR_D pile body;Package body altered 之後重新執行dbms_logmnr_d build即可 : : SQL> execute dbms_logmnr_d build( oradict ora c:oracleadminoralog );PL/SQL procere successfully pleted 添加需要分析的日誌文件 SQL>exec dbms_logmnr add_logfile( logfilename=> /data /cyx/rac arch/arch_ _ arc options=>dbms_logmnr new);PL/SQL procere successfully pleted 這里的options選項有三個參數可以用 NEW 表示創建一個新的日誌文件列表 ADDFILE 表示向這個列表中添加日誌文件 如下面的例子 REMOV lishixin/Article/program/Oracle/201311/18949

『叄』 如何查詢oracle資料庫操作日誌記錄

方法1:使用LogMiner工具
優點:可以完全挖掘日誌內容,找出所有執行過的SQL語句
缺點:
1. 如果沒有啟用歸檔日誌,則只能對聯機日誌進行挖掘
2. 需要掌握LogMiner的用法

訪法2:查看HIST視圖
優點:簡單,只要使用普通的select語句查詢
缺點:Oracle保留約1周的歷史,所以要查太早的就不可能了
-- 找出哪個資料庫用戶用什麼程序在最近三天執行過delete或truncate table的操作

舉例如下:
SELECT c.username,
a.program,
b.sql_text,
b.command_type,
a.sample_time
FROM dba_hist_active_sess_history a
JOIN dba_hist_sqltext b
ON a.sql_id = b.sql_id
JOIN dba_users c
ON a.user_id = c.user_id
WHERE a.sample_time BETWEEN SYSDATE - 3 AND SYSDATE
AND b.command_type IN (7, 85)
ORDER BY a.sample_time DESC;

『肆』 如何對oracle11g日誌分析

logminer作為相關的日誌分析工具集成與oracle中,我們可通過該工具清楚的分析重做相關日誌和歸檔日誌中的所有事物變化,並且可以准確的確定各種DML和DDL操作的具體時間和SCN值。
通過logminer我們可以實現:
1,確定數據的邏輯損壞的時間
2,跟蹤用戶執行的事務變化操作
3,跟蹤表的DML操作
如果我們要分析歸檔日誌,我們首先修改oracle歸檔日誌的模式,我們要把默認的歸檔路徑改成我們自己的路徑:
start mount;
alter database archivelog;
alter database open;
alter system set log_archive_dest_1='location=d:\oracle' scope=spfile;
alter system set log_archive_format='arch_%t_%s_%r.trc' scope=spfile;
查看我們修改過的歸檔路徑:
archive log list;
查看歸檔日誌:
select name,dest_id from v$archived_log;
如果查詢的沒有更改,我們需要重啟一下資料庫
安裝logminer,安裝logminer需要我們安裝下面的幾個包:
$ORACLE_HOME/rdbms/admin/dbmslm.sql
$ORACLE_HOME/rdbms/admin/dbmslmd.sql
$ORACLE_HOME/rdbms/admin/dbmslms.sql
這幾個腳本必須是sys用戶運行
@$ORACLE_HOME/rdbms/admin/dbmslm.sql
@$ORACLE_HOME/rdbms/admin/dbmslmd.sql
@$ORACLE_HOME/rdbms/admin/dbmslms.sql
添加數據字典,需要添加參數utl_file_dir,
alter system set utl_file_dir='/home/oracle/dir' scope=spfile;
添加supplement logging
首先查看
select name,supplemental_log_data_min from v$database;是否是yes
YES為打開狀態,會記錄session_info,username等信息
NO為關閉狀態,不會記錄sesion_info,username等信息
添加
alter database add supplemental log data;
關閉
alter database drop supplemental log data;
重啟資料庫,這樣我們剛才的兩個參數就會生效;
查看數據字典:
show parameter utl;
添加數據字典:
SQL> begin
2 dbms_logmnr_d.build(
3 dictionary_filename=>'logminer_dict.dat',
4 dictionary_location=>'/home/oracle/logminer');
5 end;
6 /
PL/SQL procere successfully completed.
或是:
execute dbms_logmnr_d.build(dictionary_filename=>'logminer_dict.dat',dictionary_location=>'/home/oracle/logminer');
創建登錄觸發器:
SQL> create or replace trigger on_logon_tigger
2 after logon on database
3 begin
4 dbms_application_info.set_client_info(sys_context('userenv','ip_address'));
5 end;
6 /
Trigger created.
我們就可以在V$SESSION視圖的CLIENT_INFO列中看到新登錄的客戶端IP地址了。那麼現在就可以在
添加要分析的歸檔日誌文件
SQL> begin
2 dbms_logmnr.add_logfile(
3 logfilename=>'/home/oracle/arch/arch_6_758944049_1.trc',options=>dbms_logmnr.new);
4 end;
5 /
PL/SQL procere successfully completed.

SQL> begin
2 dbms_logmnr.add_logfile(
3 logfilename=>'/home/oracle/arch/arch_7_758944049_1.trc',
4 options=>dbms_logmnr.addfile);
5 end;
6 /
PL/SQL procere successfully completed.

切換歸檔日誌:
alter system switch logfile;
開啟分析:
execute dmbs_logmnr.start_logmnr(dictfilename='/home/oracle/logminer/logminer_dict.dat');
或是:
execute dbms_logmnr.start_logmnr;
查詢歸檔日誌:
SQL> select name from v$archived_log;
NAME
--------------------------------------------------------------------------------
/home/oracle/arch/arch_6_758944049_1.trc
/home/oracle/arch/arch_7_758944049_1.trc
/home/oracle/arch/arch_8_758944049_1.trc
為了節約pga的空間,當我們分析完日誌後,移除不需要的日誌:
SQL> begin
2 dbms_logmnr.add_logfile(
3 logfilename=>'/home/oracle/arch/arch_7_758944049_1.trc',
4 options=>dbms_logmnr.removefile);
5 end;
6 /
PL/SQL procere successfully completed.

查詢結果在v$logmnr_contents;
查詢資料庫上面的操作
select scn,sql_redo,timestamp from v$logmnr.contents;
關閉分析
execute dbms_logmnr.stop_logmnr;
查詢的時候最好使用plsql查詢。