建站
咨詢
售后
建站咨詢
新聞中心
隨著大數(shù)據(jù)時代的到來，數(shù)據(jù)庫作為數(shù)據(jù)存儲和管理的重要工具，越來越得到人們的重視。在數(shù)據(jù)庫管理中，Oracle數(shù)據(jù)庫作為市場份額更大的商業(yè)數(shù)據(jù)庫管理系統(tǒng)，備受關(guān)注。而其中日志文件，作為數(shù)據(jù)庫管理中的重要組成部分，更是備受重視，它不僅能夠記錄數(shù)據(jù)庫操作，還能夠讓錯誤的回滾、事務(wù)的恢復(fù)變得更為容易。本文將從Oracle數(shù)據(jù)庫日志文件的定義、作用、種類及讀取等角度，。
創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計、鎮(zhèn)原網(wǎng)絡(luò)推廣、重慶小程序開發(fā)、鎮(zhèn)原網(wǎng)絡(luò)營銷、鎮(zhèn)原企業(yè)策劃、鎮(zhèn)原品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供鎮(zhèn)原建站搭建服務(wù)，24小時服務(wù)熱線：028-86922220，官方網(wǎng)址：www.cdcxhl.com
一、Oracle數(shù)據(jù)庫日志文件是什么？
Oracle數(shù)據(jù)庫日志文件是數(shù)據(jù)庫管理系統(tǒng)中的一種特殊文件，他們用于記錄數(shù)據(jù)庫的操作和事務(wù)事件。Oracle數(shù)據(jù)庫日志文件包括Redo日志文件和Archive日志文件兩種。當(dāng)數(shù)據(jù)庫發(fā)生更新時，Oracle將新數(shù)據(jù)寫到客戶端的臨時表中，同時將這些更改操作記錄在日志文件中，我們稱之為“ redo日志”?！癮rchive日志”是redo日志的備份，記錄了全部日志的情況下會自動刪除redo日志，以節(jié)省磁盤空間并減少I / O操作。
二、Oracle數(shù)據(jù)庫日志文件的作用
1.數(shù)據(jù)恢復(fù)
因為Oracle數(shù)據(jù)庫日志文件能夠記錄表空間、數(shù)據(jù)塊以及Oracle數(shù)據(jù)庫內(nèi)日志傳輸?shù)雀鞣N類型的需要安全恢復(fù)的信息，所以在意外宕機或者數(shù)據(jù)出錯的情況下，Oracle數(shù)據(jù)庫就可以通過恢復(fù)日志文件來對數(shù)據(jù)庫進行相應(yīng)的恢復(fù)操作，這是其最基本的作用。
2.數(shù)據(jù)恢復(fù)與災(zāi)難恢復(fù)
因為Oracle數(shù)據(jù)庫的日志文件是記錄著數(shù)據(jù)庫中每次發(fā)生變化的過程，所以在萬一出現(xiàn)數(shù)據(jù)庫災(zāi)難的情況下，只有通過數(shù)據(jù)恢復(fù)進行災(zāi)難恢復(fù)操作，才能盡可能的避免數(shù)據(jù)庫出現(xiàn)更大的損失。
3.讓錯誤的回滾變得容易
錯誤的回滾操作是指當(dāng)事務(wù)的部分子操作失敗，決定放棄繼續(xù)處理這個事務(wù)，撤銷以前的工作，即回滾操作。利用Oracle數(shù)據(jù)庫日志文件的記錄軌跡，就能方便地將數(shù)據(jù)回滾到之前的狀態(tài)。
4.數(shù)據(jù)庫的完整性
由于Oracle數(shù)據(jù)庫日志文件能夠記錄數(shù)據(jù)的全部更改過程，所以如果中途遇到意外情況導(dǎo)致數(shù)據(jù)庫意外停機，其日志文件能夠避免主要數(shù)據(jù)出錯、重復(fù)提交等問題的發(fā)生，從而保障數(shù)據(jù)庫的完整性。
三、Oracle數(shù)據(jù)庫日志文件的種類
1. Redo日志文件
Redo日志文件是記錄相關(guān)千變?nèi)f化的操作內(nèi)容的日志，主要是記錄各種數(shù)據(jù)修改操作。由于該日志文件中紀(jì)錄的操作內(nèi)容是十分豐富的，所以除了數(shù)據(jù)庫恢復(fù)操作外，還可以為Oracle數(shù)據(jù)庫服務(wù)諸如性能分析、數(shù)據(jù)歸檔與恢復(fù)等方面的應(yīng)用提供有力支持。
2.Archive日志文件
Oracle數(shù)據(jù)庫為了減少磁盤、I/O操作的時間，降低相應(yīng)的開銷，將創(chuàng)建的redo日志文件歸檔為archive日志文件，這是一個副本。與redo日志相比，archive日志文件需要通過手動歸檔的方式來進行備份。在archive日志文件的備份過程中，日志文件必須轉(zhuǎn)移到另一個地方或者另一個磁盤來存放，因為必須避免數(shù)據(jù)庫中的磁盤空間不夠或日志文件被I/O操作破壞。
四、Oracle數(shù)據(jù)庫日志文件的讀取
1.日志瀏覽器
Oracle日志瀏覽器是通過實時的文本日志文件的解析展示給需要的人的。該工具可以極大地提高工作效率，因為他可以查看一些數(shù)據(jù)庫的細(xì)節(jié)。Oracle日志瀏覽器提供了用戶界面，可以讓用戶選擇一個存儲在Oracle數(shù)據(jù)庫中的日志文件。用戶還可以瀏覽特定的日志數(shù)據(jù)流。Oracle日志瀏覽器能夠幫助用戶更加深入地認(rèn)識Oracle數(shù)據(jù)庫日志文件的重要性。
2.恢復(fù)工具
Oracle數(shù)據(jù)庫同時提供了完善的恢復(fù)工具，這些工具可以在需求時對日志文件進行恢復(fù)操作。而從最基本的XLOG到更高級的別名方式，Oracle數(shù)據(jù)庫日志文件有了更多的操作和實現(xiàn)方式，其中最為常見和實用的日志確定方法有“時間點恢復(fù)”和“SCN恢復(fù)”。
綜上所述，Oracle數(shù)據(jù)庫日志文件是數(shù)據(jù)庫管理系統(tǒng)中的一個重要組成部分，它不僅能夠記錄數(shù)據(jù)庫操作，還能夠讓錯誤的回滾、事務(wù)的恢復(fù)變得更為容易。同時，Oracle數(shù)據(jù)庫日志文件還具有數(shù)據(jù)恢復(fù)、完整性保障等多種作用，在Oracle數(shù)據(jù)庫管理中發(fā)揮著至關(guān)重要的作用。因此，，不僅對Oracle數(shù)據(jù)庫管理的學(xué)習(xí)，對提高Database Administrator的工作效率，都有著重要的意義。
相關(guān)問題拓展閱讀：
- oracle數(shù)據(jù)庫的警告日志如何查看
- oracle日志文件存儲在哪個表空間
- 如何打開oracle 的 log文件
oracle數(shù)據(jù)庫的警告日志如何查看
?測試環(huán)境中出現(xiàn)了一個異常的告警現(xiàn)象：一條告警通過 Thanos Ruler 的 HTTP 接口觀察到持續(xù)處于 active 狀態(tài)，但是從 AlertManager 這邊看這條告警為已解決狀態(tài)。按照 DMP 平臺的設(shè)計，告警已解決指的是告警上設(shè)置的結(jié)束時間已經(jīng)過了當(dāng)前時間。一條發(fā)送至 AlertManager 的告警為已解決狀態(tài)有三種可能：1. 手動解決了告警2. 告警只產(chǎn)生了一次，第二次計算告警規(guī)則時會發(fā)送一個已解決的告警3. AlertManager 接收到的告警會帶著一個自動解決時間，如果還沒到達(dá)自動解決時間，則將該時間重置為 24h 后首先，因為了解到測試環(huán)境沒有手動解決過異常告警，排除之一條；其次，由于該告警持續(xù)處于 active 狀態(tài)，所以不會是因為告警只產(chǎn)生了一次而接收到已解決狀態(tài)的告警，排除第二條；最后，告警的告警的產(chǎn)生時間念亂與自動解決時間相差不是 24h，排除第三條。那問題出在什么地方呢？
分析
下面我們開始分析這個問題。綜合之一節(jié)的描述，初步的猜想是告警在到達(dá) AlertManager 前悉含的某些階段的處理過程太長，導(dǎo)致告警到達(dá) AlertManager 后就已經(jīng)過了自動解決時間。我們從分析平臺里一條告警的流轉(zhuǎn)過程入手，找出告警在哪個處理階段耗時過長。首先，一條告警的產(chǎn)生需要兩方面的配合：
metric 數(shù)據(jù)
告警規(guī)則
將 metric
數(shù)據(jù)輸入
到告警規(guī)則進行計算，如果符合條件則產(chǎn)生告警。DMP 平臺集成了 Thanos 的相關(guān)組件，數(shù)據(jù)的提供和計算則會分開，數(shù)據(jù)還是由 Prometheus Server 提供，而告警規(guī)則的計算則交由 Thanos Rule（下文簡稱 Ruler）處理。下圖是 Ruler 組件在集群中所處的位置：
看來，想要弄清楚現(xiàn)告警的產(chǎn)生到 AlertManager 之間的過程，需要先弄清除 Ruler 的大致機制。官方文檔對 Ruler 的介紹是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。
不難推測，Ruler 應(yīng)該是在 Prometheus 上封裝了一層，并提供一些額外的功能。通過翻閱資料大致了解，Ruler 使用 Prometheus 提供的庫計算告警規(guī)則，并提供一些額外的功能。下面是 Ruler 中告警流轉(zhuǎn)過程：
請點擊輸入圖片描述
請點擊輸入圖片描述
首先，圖中每個告警規(guī)則 Rule 都有一個 active queue（下面簡稱本地隊列），用來保存一個告警規(guī)則下的活躍告警。
其次，從本地隊列中取出告警，發(fā)送至 AlertManager 前，會被放入 Thanos Rule Queue（下面簡稱緩沖隊列），該緩沖隊列有兩個屬性：
capacity（默認(rèn)值為 10000）：控制緩沖隊列的大小，
maxBatchSize（默認(rèn)值為 100）：控制單次發(fā)送到 AlertManager 的更大告警數(shù)
了解了上述過程，再通過翻閱 Ruler 源碼發(fā)現(xiàn)，一條告警在放入緩沖隊列前，會為其設(shè)置一個默認(rèn)的自動解決時間（當(dāng)前時間 + 3m），這里是影響告警自動解決的開始時間，在這以后，有兩個階段可能影響告警的處理：1. 緩沖隊列階段2. 出緩沖隊列到 AlertManager 階段（
網(wǎng)絡(luò)延遲
影響）由于測試環(huán)境是局域網(wǎng)環(huán)境，并且也沒在環(huán)境上發(fā)現(xiàn)網(wǎng)絡(luò)相關(guān)的問題，我們初步排除第二個階段的影響，下面我們將注意力放在緩沖隊列上。通過相關(guān)源碼發(fā)現(xiàn)，告警在緩沖隊列中的處理過程大致如下：如果本地隊列中存在一條告警，其上次發(fā)送之間距離現(xiàn)在超過了 1m（默認(rèn)值，可修改），則將該告警放入緩沖隊列，并從緩沖隊列中推送最多 maxBatchSize 個告警發(fā)送至 AlertManager。反之，如果所有睜高笑本地隊列中的告警，在最近 1m 內(nèi)都有發(fā)送過，那么就不會推送緩沖隊列中的告警。也就是說，如果在一段時間內(nèi)，產(chǎn)生了大量重復(fù)的告警，緩沖隊列的推送頻率會下降。隊列的生產(chǎn)
方太
多，消費方太少，該隊列中的告警就會產(chǎn)生堆積的現(xiàn)象。因此我們不難猜測，問題原因很可能是是緩沖隊列推送頻率變低的情況下，單次推送的告警數(shù)量太少，導(dǎo)致緩沖隊列堆積。下面我們通過兩個方面驗證上述猜想：首先通過日志可以得到隊列在大約 20230s 內(nèi)推送了大約 2023 次，即平均 10s 推送一次。結(jié)合緩沖隊列的具體屬性，一條存在于隊列中的告警大約需要 (capacity/maxBatchSize)*10s = 16m，AlertManager 在接收到告警后早已超過了默認(rèn)的自動解決時間（3m）。其次，Ruler 提供了 3 個 metric 的值來監(jiān)控緩沖隊列的運行情況：
thanos_alert_queue_alerts_dropped_total
thanos_alert_queue_alerts_pushed_total
thanos_alert_queue_alerts_popped_total
通過觀察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丟失的總數(shù)，也能佐證了緩沖隊列在某些時刻存在已滿的情況。
解決通過以上的分析，我們基本確定了問題的根源：Ruler 組件內(nèi)置的緩沖隊列堆積造成了告警發(fā)送的延遲。針對這個問題，我們選擇調(diào)整隊列的 maxBatchSize 值。下面介紹一下這個值如何設(shè)置的思路。由于每計算一次告警規(guī)則就會嘗試推送一次緩沖隊列，我們通過估計一個告警數(shù)量的更大值，得到 maxBatchSize 可以設(shè)置的最小值。假設(shè)你的業(yè)務(wù)系統(tǒng)需要監(jiān)控的實體數(shù)量分別為 x1、x2、x3、…、xn，實體上的告警規(guī)則數(shù)量分別有 y1、y2、y3、…、yn，那么一次能產(chǎn)生的告警數(shù)量最多是(x1 * y2 + x2 * y2 + x3 * y3 + … + xn * yn)，最多推送（y1 + y2 + y3 + … + yn）次，所以要使緩沖隊列不堆積，maxBatchSize 應(yīng)該滿足：maxBatchSize >= (x1 * y2 + x2 * y2 + x3 * y3 + … + xn * yn) / (y1 + y2 + y3 + … + yn)，假設(shè) x = max(x1,x2, …,xn), 將不等式右邊適當(dāng)放大后為 x，即 maxBatchSize 的最小值為 x。也就是說，可以將 maxBatchSize 設(shè)置為系統(tǒng)中數(shù)量更大的那一類監(jiān)控實體，對于 DMP 平臺，一般來說是 MySQL 實例。
注意事項
上面的計算過程只是提供一個參考思路，如果最終計算出該值過大，很有可能對 AlertManager 造成壓力，因而失去緩沖隊列的作用，所以還是需要結(jié)合實際情況，具體分析。因為 DMP 將 Ruler 集成到了自己的組件中，所以可以比較方便地對這個值進行修改。如果是依照官方文檔的介紹使用的 Ruler 組件，那么需要對源碼文件進行定制化修改。
??
告警日志文件是一類特殊的跟蹤文件（trace file）。告警日志文件命名爛察一般為alert_.log，其中SID為ORACLE數(shù)據(jù)庫脊歷空實例名稱。數(shù)據(jù)庫告警日志是櫻瞎按時間順序記錄message和錯誤信息。
oracle日志文件存儲在哪個表空間
日志文件分為重做日志文件（redo log file）和歸檔日志文件（archive log file）。
SQL> select group#, status, member from v$logfile;
GROUP# STATUS MEMBER
–
C:\ORACLE\ORADATA\ORCL\REDO03.LOG
C:\ORACLE\ORADATA\ORCL\REDO02.LOG
C:\ORACLE\ORADATA\ORCL\REDO01.LOG
redo log fiel有多個組group構(gòu)成。一個group中能包括不止一個log file，日志信息是寫到group的每個logfile中，握敗所以一個group中的log file存儲著一樣的信息。當(dāng)一個group寫滿之后就轉(zhuǎn)到下一個group中，段孝顫稱之為日志切換。
當(dāng)所有g(shù)roup都寫滿了后，就重頭開始從之一個group開始，原來的內(nèi)容將被覆蓋丟失。如果不想被丟失，可以采用歸檔模式慎并，即將數(shù)據(jù)保存到archive log file中。歸檔模式會給系統(tǒng)帶來一定的性能問題。
查看database采用哪種模式：
SQL> select dbid,name,log_mode from v$database;
DBID NAME LOG_MODE
—–
ORCL NOARCHIVELOG
歸檔日志路徑由SPFILE的log_archive_dest參數(shù)確定。
SQL> show parameter log_archive_dest;
NAME TYPEVALUE
log_archive_deststring
log_archive_dest_ string
log_archive_dest_ string
log_archive_dest_ string
log_archive_dest_ string
log_archive_dest_ string
log_archive_dest_ string
log_archive_dest_ string
log_archive_dest_ string
log_archive_dest_ string
log_archive_dest_ string
log_archive_dest_state_string enable
log_archive_dest_state_string enable
log_archive_dest_state_string enable
log_archive_dest_state_string enable
log_archive_dest_state_string enable
log_archive_dest_state_string enable
log_archive_dest_state_string enable
log_archive_dest_state_string enable
log_archive_dest_state_string enable
log_archive_dest_state_string enable
警告日志文件alert_sid.log保存著例行的信息和錯誤信息，它的路經(jīng)是：
SQL> select value from v$parameter where name=’background_dump_dest’;
VALUE
c:\oracle\diag\rdbms\orcl\orcl\trace
SQL> show parameter background_dump_dest;
NAME TYPEVALUE
background_dump_dest string c:\oracle\diag\rdbms\orcl\orcl\trace
用戶跟蹤文件是oracle出現(xiàn)異常時自動創(chuàng)建的文本文件，它與警告文件一起構(gòu)成了完整的故障信息描述體系。
SQL> select value from v$parameter where name=’user_dump_dest’;
VALUE
c:\oracle\diag\rdbms\orcl\orcl\trace
SQL> show parameter user_dump_dest;
NAME TYPEVALUE
user_dump_deststring c:\oracle\diag\rdbms\orcl\orcl\trace
oracle日志不在如扒慶表空間里，請問你要看的時redo log 還是archive？
你可以在SQLplus 中查詢他們的位置：
select * from v$logfile
查詢archive log：
show parameter log_archive_dest
如果你說的alter日志渣握（就是此冊記錄oracle日?；顒拥模?/p>
show parameter background_dump_dest;
查詢?nèi)罩疚募顟B(tài)和表空間
select * from v$log;
select * from v$logfile;
oracle日志不在表空間里，請問你要看的鉛纖虧豎汪時redo log 還是archive？
你可以在SQLplus 中查詢他們的位置：
select * from v$logfile
查詢archive log：
show parameter log_archive_dest
如果你說槐神的alter日志（就是記錄oracle日常活動的）
show parameter background_dump_dest;
查詢?nèi)漳顦蛑疚念澑叽a件狀態(tài)和表空間茄哪
select * from v$log;
select * from v$logfile;
如何打開oracle 的 log文件
在輸入imp命令的時候可以指定生成日志文件，如執(zhí)行命令：
imp 用戶名/密碼@數(shù)據(jù)庫實例名 file=C:\data\filename.dmp log=C:\data\寬彎logname.log fromuser=scott
其中在C:\data\路徑拆缺下的logname.log就是日志文件，可用文本方式打開，如旅巧辯圖：
打開內(nèi)容如下：
關(guān)于oracle 數(shù)據(jù)庫日志文件的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
成都服務(wù)器租用選創(chuàng)新互聯(lián)，先試用再開通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）提供簡單好用，價格厚道的香港/美國云服務(wù)器和獨立服務(wù)器。物理服務(wù)器托管租用：四川成都、綿陽、重慶、貴陽機房服務(wù)器托管租用。
網(wǎng)站名稱：深入探究Oracle數(shù)據(jù)庫日志文件的重要性 (oracle 數(shù)據(jù)庫日志文件)
文章起源：http://www.dlmjj.cn/article/dhecope.html
