建站
咨詢
售后
建站咨詢
新聞中心
Oracle數(shù)據(jù)庫作為一種高性能的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)，被廣泛運用于各行各業(yè)的數(shù)據(jù)管理和處理，其在實際應(yīng)用中具有重要的意義。但是在數(shù)據(jù)庫操作過程中，難免會出現(xiàn)各種各樣的問題和錯誤，如何追蹤和解決這些問題，就需要通過查看數(shù)據(jù)庫日志文件來獲得關(guān)鍵信息。
成都創(chuàng)新互聯(lián)專注于尋甸企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城網(wǎng)站建設(shè)。尋甸網(wǎng)站建設(shè)公司,為尋甸等地區(qū)提供建站服務(wù)。全流程按需求定制制作，專業(yè)設(shè)計，全程項目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)
數(shù)據(jù)庫日志是數(shù)據(jù)庫管理系統(tǒng)在工作過程中，自動生成的一種記錄了數(shù)據(jù)庫活動情況的信息記錄文件。這些日志記錄包括錯誤日志、事務(wù)日志、歸檔日志等等。這些日志記錄非常重要，可以方便用戶進(jìn)行故障排除、日常運維以及性能分析等工作。
在Oracle數(shù)據(jù)庫中，有兩種主要日志類型：重做日志和歸檔日志。重做日志主要用于記錄每一次的數(shù)據(jù)庫更改操作，并在數(shù)據(jù)庫出現(xiàn)故障時進(jìn)行恢復(fù)；歸檔日志則是對數(shù)據(jù)庫內(nèi)容的全量備份，通常用于備份數(shù)據(jù)庫和恢復(fù)整個數(shù)據(jù)庫。
那么，如何深入解析Oracle數(shù)據(jù)庫的日志內(nèi)容，掌握關(guān)鍵信息？下面，我們將從以下幾個方面進(jìn)行探討：
1、在Oracle數(shù)據(jù)庫中查看日志文件
在Oracle數(shù)據(jù)庫中，可以通過以下幾種方式來查看日志文件：
（1）使用日志文件文件名稱
可以直接使用日志文件的文件名稱進(jìn)行查看：
SQL> select * from v$log_file;
（2）使用redo日志組
使用redo日志組就需要按照redo日志的組編號來進(jìn)行查詢，查看當(dāng)前正在使用的redo日志：
SQL> select * from v$log;
2、查看日志文件中的錯誤信息
數(shù)據(jù)庫日志文件中尤其是錯誤日志等，對于定位故障和解決問題至關(guān)重要。在日常運維中需要經(jīng)常留意并進(jìn)行監(jiān)控。查看錯誤日志的方式有以下兩個：
（1）查看數(shù)據(jù)庫的日志文件
可以使用以下命令來查看錯誤日志：
SQL> show parameter background_dump_dest
可以查看到錯誤日志所在的路徑
SQL> host cd /u01/app/oracle/diag/rdbms/orcl/ORCL/trace
SQL> ls -l *trc
（2）使用Oracle的內(nèi)置工具
Oracle數(shù)據(jù)庫提供了一個內(nèi)置工具 – 追蹤信息工具，通過該工具可以查看數(shù)據(jù)庫中的錯誤日志以及其它信息，使用方法如下：
SQL> alter session set events ‘10046 trace name context forever, level 12’;
使用這個命令后，會將系統(tǒng)的所有SQL語句都輸出到日志文件中?？梢酝ㄟ^ “write trace” 文件查看，其中包含了足夠詳細(xì)的SQL執(zhí)行信息、錯誤信息等等。
3、查看數(shù)據(jù)庫中的事務(wù)日志
事務(wù)日志是記錄事務(wù)的變化的日志。每當(dāng)一個事務(wù)被更改時，Oracle便會在它的事務(wù)日志文件中用log操作記錄這個變化，用于恢復(fù)和回滾。查看數(shù)據(jù)庫中事務(wù)日志的信息，可以通過以下兩種方法：
（1）使用Oracle的內(nèi)置函數(shù)
可以使用oracle內(nèi)置函數(shù) dbms_flashback_transactions來查看數(shù)據(jù)庫中的事務(wù)日志，例如：
SQL> set serveroutput on
SQL> declare
v_transaction_id raw(8);
begin
v_transaction_id := ‘0F02023008000001’;
dbms_output.put_line(‘Transaction Id:’ || utl_raw.cast_to_varchar2(v_transaction_id));
dbms_flashback_transactions.get_transaction_info(transaction_id => v_transaction_id);
end;
/
（2）使用第三方工具
通常，Oracle數(shù)據(jù)庫的管理人員會使用第三方工具來進(jìn)行對Oracle數(shù)據(jù)庫日志文件的分析，以便獲得更為詳細(xì)的日志信息。比如，常用的工具有 Quest Central for Oracle 、Toad for Oracle等等。
在分析Oracle數(shù)據(jù)庫日志時，需要了解日志文件的結(jié)構(gòu)，掌握常見的錯誤信息和日志記錄等，以便更快地定位問題和解決問題。同時，在維護和管理Oracle數(shù)據(jù)庫時，需要注重日志記錄的推送和備份，以及對備份文件進(jìn)行安全控制。
深入解析oracle數(shù)據(jù)庫日志內(nèi)容是Oracle數(shù)據(jù)庫管理人員必須具備的技能之一，能夠幫助用戶更快速、更準(zhǔn)確地定位問題并解決問題，保證數(shù)據(jù)庫的正常運行。
相關(guān)問題拓展閱讀：
- oracle數(shù)據(jù)庫的警告日志如何查看
- 什么是oracle 日志文件
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ī)則進(jìn)行計算，如果符合條件則產(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 集成到了自己的組件中，所以可以比較方便地對這個值進(jìn)行修改。如果是依照官方文檔的介紹使用的 Ruler 組件，那么需要對源碼文件進(jìn)行定制化修改。
??
告警日志文件是一類特殊的跟蹤文件（trace file）。告警日志文件命名爛察一般為alert_.log，其中SID為ORACLE數(shù)據(jù)庫脊歷空實例名稱。數(shù)據(jù)庫告警日志是櫻瞎按時間順序記錄message和錯誤信息。
什么是oracle 日志文件
重做日志redo
log
file是lgwr進(jìn)程從oracle實例中的redo
log
buffer寫入的，是循環(huán)利用的。就是說一個redo
log
file(group)
寫滿后，才寫下一個。
歸檔日志archive
log是當(dāng)數(shù)據(jù)庫運行在歸脊返檔模式下時，一個redo
log
file(group)寫滿后，由arcn進(jìn)程將重做日志的內(nèi)容備份到歸檔日志文件下，然后這個redo
log
file(group)才能被下一次使用。
不管數(shù)據(jù)庫是否是歸檔模式，重做日志是肯定要寫的。而只有數(shù)據(jù)庫在歸檔模式下，重做日志才會備份，形成歸檔日志。
一般來說，歸檔日志結(jié)合全備份，用于數(shù)據(jù)庫出現(xiàn)問題后的恢復(fù)使用。
重滾野姿做日志是循環(huán)使用的。比如說，有三個重做日志組a、b、c。那么，當(dāng)a寫滿后，系統(tǒng)就調(diào)用arcn進(jìn)程，將a備份為歸檔日志，同時b已經(jīng)開始使用了。
假設(shè)你只有兩個組a、b，如果某種情況下，a正在備份，未結(jié)束，還不能繼續(xù)使用，而b也寫滿了，這個時候，數(shù)據(jù)庫就會出現(xiàn)掛起的情況。所以一般情況下，重做日志更好是三個組或者再多一點，而且大小要適當(dāng)。
實際上，一個重做日志組滿了后，就開始寫入歸檔日志。不是等abc都寫滿了，再歸檔，這樣肯定就是出現(xiàn)掛起的情況了，oracle不是這樣的，歸檔日志和重做日志都是物理上的文件，只是存放的目錄不同，而且重做日志的文件名不變，而歸檔日志的文件名是備份時系統(tǒng)生成的。
重做日志備份為歸檔日志后，系統(tǒng)就會把重做日志的內(nèi)大絕容清空，但文件依然存在，準(zhǔn)備下一次使用。
重做日志紀(jì)錄了你所有做過的dml語句，重做日志循環(huán)使用，寫滿一輪后就要覆蓋前面的。如果你是用熱備模式，當(dāng)重做日志寫滿一個后就將內(nèi)容寫入歸檔日志，以備將來恢復(fù)數(shù)據(jù)用。
只有數(shù)據(jù)庫運行在歸檔模式并且初始化參數(shù)archive_log_start等于true時，arcn進(jìn)程才能被啟動，進(jìn)行自動歸檔。
如果數(shù)據(jù)庫運行在歸檔模式但archive_log_start等于false時，需要dba手工歸檔。
重做日志文件也叫聯(lián)機日志文件,一般數(shù)據(jù)庫有幾個日志文件(例如有三個,編號分別為1,2,3)先寫1,當(dāng)1滿時再寫2,當(dāng)2滿時再寫3,當(dāng)3滿時1就歸
檔出來,產(chǎn)生一個文件寫到磁盤上,這個文件就叫歸檔日志文件.1歸檔出來后,新的聯(lián)機日志文件又寫到1中,將原來的覆蓋,(即聯(lián)機日志是循環(huán)使用的).一
般當(dāng)產(chǎn)生一個檢查點或聯(lián)機日志寫滿一定程度時會產(chǎn)生一個歸檔日志文件.
oracle數(shù)據(jù)庫日志內(nèi)容的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于oracle數(shù)據(jù)庫日志內(nèi)容,深入解析Oracle數(shù)據(jù)庫日志內(nèi)容，掌握關(guān)鍵信息,oracle數(shù)據(jù)庫的警告日志如何查看,什么是oracle 日志文件的信息別忘了在本站進(jìn)行查找喔。
成都網(wǎng)站設(shè)計制作選創(chuàng)新互聯(lián)，專業(yè)網(wǎng)站建設(shè)公司。
成都創(chuàng)新互聯(lián)10余年專注成都高端網(wǎng)站建設(shè)定制開發(fā)服務(wù),為客戶提供專業(yè)的成都網(wǎng)站制作,成都網(wǎng)頁設(shè)計,成都網(wǎng)站設(shè)計服務(wù);成都創(chuàng)新互聯(lián)服務(wù)內(nèi)容包含成都網(wǎng)站建設(shè)，小程序開發(fā)，營銷網(wǎng)站建設(shè)，網(wǎng)站改版，服務(wù)器托管租用等互聯(lián)網(wǎng)服務(wù)。
新聞標(biāo)題：深入解析Oracle數(shù)據(jù)庫日志內(nèi)容，掌握關(guān)鍵信息 (oracle數(shù)據(jù)庫日志內(nèi)容)
新聞來源：http://www.fisionsoft.com.cn/article/ccsheje.html
