建站
咨詢
售后
建站咨詢
新聞中心
Oracle數(shù)據(jù)庫(kù)作為一種高性能的關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)，被廣泛運(yùn)用于各行各業(yè)的數(shù)據(jù)管理和處理，其在實(shí)際應(yīng)用中具有重要的意義。但是在數(shù)據(jù)庫(kù)操作過(guò)程中，難免會(huì)出現(xiàn)各種各樣的問(wèn)題和錯(cuò)誤，如何追蹤和解決這些問(wèn)題，就需要通過(guò)查看數(shù)據(jù)庫(kù)日志文件來(lái)獲得關(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è)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)
數(shù)據(jù)庫(kù)日志是數(shù)據(jù)庫(kù)管理系統(tǒng)在工作過(guò)程中，自動(dòng)生成的一種記錄了數(shù)據(jù)庫(kù)活動(dòng)情況的信息記錄文件。這些日志記錄包括錯(cuò)誤日志、事務(wù)日志、歸檔日志等等。這些日志記錄非常重要，可以方便用戶進(jìn)行故障排除、日常運(yùn)維以及性能分析等工作。
在Oracle數(shù)據(jù)庫(kù)中，有兩種主要日志類型：重做日志和歸檔日志。重做日志主要用于記錄每一次的數(shù)據(jù)庫(kù)更改操作，并在數(shù)據(jù)庫(kù)出現(xiàn)故障時(shí)進(jìn)行恢復(fù)；歸檔日志則是對(duì)數(shù)據(jù)庫(kù)內(nèi)容的全量備份，通常用于備份數(shù)據(jù)庫(kù)和恢復(fù)整個(gè)數(shù)據(jù)庫(kù)。
那么，如何深入解析Oracle數(shù)據(jù)庫(kù)的日志內(nèi)容，掌握關(guān)鍵信息？下面，我們將從以下幾個(gè)方面進(jìn)行探討：
1、在Oracle數(shù)據(jù)庫(kù)中查看日志文件
在Oracle數(shù)據(jù)庫(kù)中，可以通過(guò)以下幾種方式來(lái)查看日志文件：
（1）使用日志文件文件名稱
可以直接使用日志文件的文件名稱進(jìn)行查看：
SQL> select * from v$log_file;
（2）使用redo日志組
使用redo日志組就需要按照redo日志的組編號(hào)來(lái)進(jìn)行查詢，查看當(dāng)前正在使用的redo日志：
SQL> select * from v$log;
2、查看日志文件中的錯(cuò)誤信息
數(shù)據(jù)庫(kù)日志文件中尤其是錯(cuò)誤日志等，對(duì)于定位故障和解決問(wèn)題至關(guān)重要。在日常運(yùn)維中需要經(jīng)常留意并進(jìn)行監(jiān)控。查看錯(cuò)誤日志的方式有以下兩個(gè)：
（1）查看數(shù)據(jù)庫(kù)的日志文件
可以使用以下命令來(lái)查看錯(cuò)誤日志：
SQL> show parameter background_dump_dest
可以查看到錯(cuò)誤日志所在的路徑
SQL> host cd /u01/app/oracle/diag/rdbms/orcl/ORCL/trace
SQL> ls -l *trc
（2）使用Oracle的內(nèi)置工具
Oracle數(shù)據(jù)庫(kù)提供了一個(gè)內(nèi)置工具 – 追蹤信息工具，通過(guò)該工具可以查看數(shù)據(jù)庫(kù)中的錯(cuò)誤日志以及其它信息，使用方法如下：
SQL> alter session set events ‘10046 trace name context forever, level 12’;
使用這個(gè)命令后，會(huì)將系統(tǒng)的所有SQL語(yǔ)句都輸出到日志文件中?？梢酝ㄟ^(guò) “write trace” 文件查看，其中包含了足夠詳細(xì)的SQL執(zhí)行信息、錯(cuò)誤信息等等。
3、查看數(shù)據(jù)庫(kù)中的事務(wù)日志
事務(wù)日志是記錄事務(wù)的變化的日志。每當(dāng)一個(gè)事務(wù)被更改時(shí)，Oracle便會(huì)在它的事務(wù)日志文件中用log操作記錄這個(gè)變化，用于恢復(fù)和回滾。查看數(shù)據(jù)庫(kù)中事務(wù)日志的信息，可以通過(guò)以下兩種方法：
（1）使用Oracle的內(nèi)置函數(shù)
可以使用oracle內(nèi)置函數(shù) dbms_flashback_transactions來(lái)查看數(shù)據(jù)庫(kù)中的事務(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ù)庫(kù)的管理人員會(huì)使用第三方工具來(lái)進(jìn)行對(duì)Oracle數(shù)據(jù)庫(kù)日志文件的分析，以便獲得更為詳細(xì)的日志信息。比如，常用的工具有 Quest Central for Oracle 、Toad for Oracle等等。
在分析Oracle數(shù)據(jù)庫(kù)日志時(shí)，需要了解日志文件的結(jié)構(gòu)，掌握常見(jiàn)的錯(cuò)誤信息和日志記錄等，以便更快地定位問(wèn)題和解決問(wèn)題。同時(shí)，在維護(hù)和管理Oracle數(shù)據(jù)庫(kù)時(shí)，需要注重日志記錄的推送和備份，以及對(duì)備份文件進(jìn)行安全控制。
深入解析oracle數(shù)據(jù)庫(kù)日志內(nèi)容是Oracle數(shù)據(jù)庫(kù)管理人員必須具備的技能之一，能夠幫助用戶更快速、更準(zhǔn)確地定位問(wèn)題并解決問(wèn)題，保證數(shù)據(jù)庫(kù)的正常運(yùn)行。
相關(guān)問(wèn)題拓展閱讀：
- oracle數(shù)據(jù)庫(kù)的警告日志如何查看
- 什么是oracle 日志文件
oracle數(shù)據(jù)庫(kù)的警告日志如何查看
?測(cè)試環(huán)境中出現(xiàn)了一個(gè)異常的告警現(xiàn)象：一條告警通過(guò) Thanos Ruler 的 HTTP 接口觀察到持續(xù)處于 active 狀態(tài)，但是從 AlertManager 這邊看這條告警為已解決狀態(tài)。按照 DMP 平臺(tái)的設(shè)計(jì)，告警已解決指的是告警上設(shè)置的結(jié)束時(shí)間已經(jīng)過(guò)了當(dāng)前時(shí)間。一條發(fā)送至 AlertManager 的告警為已解決狀態(tài)有三種可能：1. 手動(dòng)解決了告警2. 告警只產(chǎn)生了一次，第二次計(jì)算告警規(guī)則時(shí)會(huì)發(fā)送一個(gè)已解決的告警3. AlertManager 接收到的告警會(huì)帶著一個(gè)自動(dòng)解決時(shí)間，如果還沒(méi)到達(dá)自動(dòng)解決時(shí)間，則將該時(shí)間重置為 24h 后首先，因?yàn)榱私獾綔y(cè)試環(huán)境沒(méi)有手動(dòng)解決過(guò)異常告警，排除之一條；其次，由于該告警持續(xù)處于 active 狀態(tài)，所以不會(huì)是因?yàn)楦婢划a(chǎn)生了一次而接收到已解決狀態(tài)的告警，排除第二條；最后，告警的告警的產(chǎn)生時(shí)間念亂與自動(dòng)解決時(shí)間相差不是 24h，排除第三條。那問(wèn)題出在什么地方呢？
分析
下面我們開(kāi)始分析這個(gè)問(wèn)題。綜合之一節(jié)的描述，初步的猜想是告警在到達(dá) AlertManager 前悉含的某些階段的處理過(guò)程太長(zhǎng)，導(dǎo)致告警到達(dá) AlertManager 后就已經(jīng)過(guò)了自動(dòng)解決時(shí)間。我們從分析平臺(tái)里一條告警的流轉(zhuǎn)過(guò)程入手，找出告警在哪個(gè)處理階段耗時(shí)過(guò)長(zhǎng)。首先，一條告警的產(chǎn)生需要兩方面的配合：
metric 數(shù)據(jù)
告警規(guī)則
將 metric
數(shù)據(jù)輸入
到告警規(guī)則進(jìn)行計(jì)算，如果符合條件則產(chǎn)生告警。DMP 平臺(tái)集成了 Thanos 的相關(guān)組件，數(shù)據(jù)的提供和計(jì)算則會(huì)分開(kāi)，數(shù)據(jù)還是由 Prometheus Server 提供，而告警規(guī)則的計(jì)算則交由 Thanos Rule（下文簡(jiǎn)稱 Ruler）處理。下圖是 Ruler 組件在集群中所處的位置：
看來(lái)，想要弄清楚現(xiàn)告警的產(chǎn)生到 AlertManager 之間的過(guò)程，需要先弄清除 Ruler 的大致機(jī)制。官方文檔對(duì) 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)。
不難推測(cè)，Ruler 應(yīng)該是在 Prometheus 上封裝了一層，并提供一些額外的功能。通過(guò)翻閱資料大致了解，Ruler 使用 Prometheus 提供的庫(kù)計(jì)算告警規(guī)則，并提供一些額外的功能。下面是 Ruler 中告警流轉(zhuǎn)過(guò)程：
請(qǐng)點(diǎn)擊輸入圖片描述
請(qǐng)點(diǎn)擊輸入圖片描述
首先，圖中每個(gè)告警規(guī)則 Rule 都有一個(gè) active queue（下面簡(jiǎn)稱本地隊(duì)列），用來(lái)保存一個(gè)告警規(guī)則下的活躍告警。
其次，從本地隊(duì)列中取出告警，發(fā)送至 AlertManager 前，會(huì)被放入 Thanos Rule Queue（下面簡(jiǎn)稱緩沖隊(duì)列），該緩沖隊(duì)列有兩個(gè)屬性：
capacity（默認(rèn)值為 10000）：控制緩沖隊(duì)列的大小，
maxBatchSize（默認(rèn)值為 100）：控制單次發(fā)送到 AlertManager 的更大告警數(shù)
了解了上述過(guò)程，再通過(guò)翻閱 Ruler 源碼發(fā)現(xiàn)，一條告警在放入緩沖隊(duì)列前，會(huì)為其設(shè)置一個(gè)默認(rèn)的自動(dòng)解決時(shí)間（當(dāng)前時(shí)間 + 3m），這里是影響告警自動(dòng)解決的開(kāi)始時(shí)間，在這以后，有兩個(gè)階段可能影響告警的處理：1. 緩沖隊(duì)列階段2. 出緩沖隊(duì)列到 AlertManager 階段（
網(wǎng)絡(luò)延遲
影響）由于測(cè)試環(huán)境是局域網(wǎng)環(huán)境，并且也沒(méi)在環(huán)境上發(fā)現(xiàn)網(wǎng)絡(luò)相關(guān)的問(wèn)題，我們初步排除第二個(gè)階段的影響，下面我們將注意力放在緩沖隊(duì)列上。通過(guò)相關(guān)源碼發(fā)現(xiàn)，告警在緩沖隊(duì)列中的處理過(guò)程大致如下：如果本地隊(duì)列中存在一條告警，其上次發(fā)送之間距離現(xiàn)在超過(guò)了 1m（默認(rèn)值，可修改），則將該告警放入緩沖隊(duì)列，并從緩沖隊(duì)列中推送最多 maxBatchSize 個(gè)告警發(fā)送至 AlertManager。反之，如果所有睜高笑本地隊(duì)列中的告警，在最近 1m 內(nèi)都有發(fā)送過(guò)，那么就不會(huì)推送緩沖隊(duì)列中的告警。也就是說(shuō)，如果在一段時(shí)間內(nèi)，產(chǎn)生了大量重復(fù)的告警，緩沖隊(duì)列的推送頻率會(huì)下降。隊(duì)列的生產(chǎn)
方太
多，消費(fèi)方太少，該隊(duì)列中的告警就會(huì)產(chǎn)生堆積的現(xiàn)象。因此我們不難猜測(cè)，問(wèn)題原因很可能是是緩沖隊(duì)列推送頻率變低的情況下，單次推送的告警數(shù)量太少，導(dǎo)致緩沖隊(duì)列堆積。下面我們通過(guò)兩個(gè)方面驗(yàn)證上述猜想：首先通過(guò)日志可以得到隊(duì)列在大約 20230s 內(nèi)推送了大約 2023 次，即平均 10s 推送一次。結(jié)合緩沖隊(duì)列的具體屬性，一條存在于隊(duì)列中的告警大約需要 (capacity/maxBatchSize)*10s = 16m，AlertManager 在接收到告警后早已超過(guò)了默認(rèn)的自動(dòng)解決時(shí)間（3m）。其次，Ruler 提供了 3 個(gè) metric 的值來(lái)監(jiān)控緩沖隊(duì)列的運(yùn)行情況：
thanos_alert_queue_alerts_dropped_total
thanos_alert_queue_alerts_pushed_total
thanos_alert_queue_alerts_popped_total
通過(guò)觀察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丟失的總數(shù)，也能佐證了緩沖隊(duì)列在某些時(shí)刻存在已滿的情況。
解決通過(guò)以上的分析，我們基本確定了問(wèn)題的根源：Ruler 組件內(nèi)置的緩沖隊(duì)列堆積造成了告警發(fā)送的延遲。針對(duì)這個(gè)問(wèn)題，我們選擇調(diào)整隊(duì)列的 maxBatchSize 值。下面介紹一下這個(gè)值如何設(shè)置的思路。由于每計(jì)算一次告警規(guī)則就會(huì)嘗試推送一次緩沖隊(duì)列，我們通過(guò)估計(jì)一個(gè)告警數(shù)量的更大值，得到 maxBatchSize 可以設(shè)置的最小值。假設(shè)你的業(yè)務(wù)系統(tǒng)需要監(jiān)控的實(shí)體數(shù)量分別為 x1、x2、x3、…、xn，實(shí)體上的告警規(guī)則數(shù)量分別有 y1、y2、y3、…、yn，那么一次能產(chǎn)生的告警數(shù)量最多是(x1 * y2 + x2 * y2 + x3 * y3 + … + xn * yn)，最多推送（y1 + y2 + y3 + … + yn）次，所以要使緩沖隊(duì)列不堆積，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。也就是說(shuō)，可以將 maxBatchSize 設(shè)置為系統(tǒng)中數(shù)量更大的那一類監(jiān)控實(shí)體，對(duì)于 DMP 平臺(tái)，一般來(lái)說(shuō)是 MySQL 實(shí)例。
注意事項(xiàng)
上面的計(jì)算過(guò)程只是提供一個(gè)參考思路，如果最終計(jì)算出該值過(guò)大，很有可能對(duì) AlertManager 造成壓力，因而失去緩沖隊(duì)列的作用，所以還是需要結(jié)合實(shí)際情況，具體分析。因?yàn)?DMP 將 Ruler 集成到了自己的組件中，所以可以比較方便地對(duì)這個(gè)值進(jìn)行修改。如果是依照官方文檔的介紹使用的 Ruler 組件，那么需要對(duì)源碼文件進(jìn)行定制化修改。
??
告警日志文件是一類特殊的跟蹤文件（trace file）。告警日志文件命名爛察一般為alert_.log，其中SID為ORACLE數(shù)據(jù)庫(kù)脊歷空實(shí)例名稱。數(shù)據(jù)庫(kù)告警日志是櫻瞎按時(shí)間順序記錄message和錯(cuò)誤信息。
什么是oracle 日志文件
重做日志redo
log
file是lgwr進(jìn)程從oracle實(shí)例中的redo
log
buffer寫(xiě)入的，是循環(huán)利用的。就是說(shuō)一個(gè)redo
log
file(group)
寫(xiě)滿后，才寫(xiě)下一個(gè)。
歸檔日志archive
log是當(dāng)數(shù)據(jù)庫(kù)運(yùn)行在歸脊返檔模式下時(shí)，一個(gè)redo
log
file(group)寫(xiě)滿后，由arcn進(jìn)程將重做日志的內(nèi)容備份到歸檔日志文件下，然后這個(gè)redo
log
file(group)才能被下一次使用。
不管數(shù)據(jù)庫(kù)是否是歸檔模式，重做日志是肯定要寫(xiě)的。而只有數(shù)據(jù)庫(kù)在歸檔模式下，重做日志才會(huì)備份，形成歸檔日志。
一般來(lái)說(shuō)，歸檔日志結(jié)合全備份，用于數(shù)據(jù)庫(kù)出現(xiàn)問(wèn)題后的恢復(fù)使用。
重滾野姿做日志是循環(huán)使用的。比如說(shuō)，有三個(gè)重做日志組a、b、c。那么，當(dāng)a寫(xiě)滿后，系統(tǒng)就調(diào)用arcn進(jìn)程，將a備份為歸檔日志，同時(shí)b已經(jīng)開(kāi)始使用了。
假設(shè)你只有兩個(gè)組a、b，如果某種情況下，a正在備份，未結(jié)束，還不能繼續(xù)使用，而b也寫(xiě)滿了，這個(gè)時(shí)候，數(shù)據(jù)庫(kù)就會(huì)出現(xiàn)掛起的情況。所以一般情況下，重做日志更好是三個(gè)組或者再多一點(diǎn)，而且大小要適當(dāng)。
實(shí)際上，一個(gè)重做日志組滿了后，就開(kāi)始寫(xiě)入歸檔日志。不是等abc都寫(xiě)滿了，再歸檔，這樣肯定就是出現(xiàn)掛起的情況了，oracle不是這樣的，歸檔日志和重做日志都是物理上的文件，只是存放的目錄不同，而且重做日志的文件名不變，而歸檔日志的文件名是備份時(shí)系統(tǒng)生成的。
重做日志備份為歸檔日志后，系統(tǒng)就會(huì)把重做日志的內(nèi)大絕容清空，但文件依然存在，準(zhǔn)備下一次使用。
重做日志紀(jì)錄了你所有做過(guò)的dml語(yǔ)句，重做日志循環(huán)使用，寫(xiě)滿一輪后就要覆蓋前面的。如果你是用熱備模式，當(dāng)重做日志寫(xiě)滿一個(gè)后就將內(nèi)容寫(xiě)入歸檔日志，以備將來(lái)恢復(fù)數(shù)據(jù)用。
只有數(shù)據(jù)庫(kù)運(yùn)行在歸檔模式并且初始化參數(shù)archive_log_start等于true時(shí)，arcn進(jìn)程才能被啟動(dòng)，進(jìn)行自動(dòng)歸檔。
如果數(shù)據(jù)庫(kù)運(yùn)行在歸檔模式但archive_log_start等于false時(shí)，需要dba手工歸檔。
重做日志文件也叫聯(lián)機(jī)日志文件,一般數(shù)據(jù)庫(kù)有幾個(gè)日志文件(例如有三個(gè),編號(hào)分別為1,2,3)先寫(xiě)1,當(dāng)1滿時(shí)再寫(xiě)2,當(dāng)2滿時(shí)再寫(xiě)3,當(dāng)3滿時(shí)1就歸
檔出來(lái),產(chǎn)生一個(gè)文件寫(xiě)到磁盤(pán)上,這個(gè)文件就叫歸檔日志文件.1歸檔出來(lái)后,新的聯(lián)機(jī)日志文件又寫(xiě)到1中,將原來(lái)的覆蓋,(即聯(lián)機(jī)日志是循環(huán)使用的).一
般當(dāng)產(chǎn)生一個(gè)檢查點(diǎn)或聯(lián)機(jī)日志寫(xiě)滿一定程度時(shí)會(huì)產(chǎn)生一個(gè)歸檔日志文件.
oracle數(shù)據(jù)庫(kù)日志內(nèi)容的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于oracle數(shù)據(jù)庫(kù)日志內(nèi)容,深入解析Oracle數(shù)據(jù)庫(kù)日志內(nèi)容，掌握關(guān)鍵信息,oracle數(shù)據(jù)庫(kù)的警告日志如何查看,什么是oracle 日志文件的信息別忘了在本站進(jìn)行查找喔。
成都網(wǎng)站設(shè)計(jì)制作選創(chuàng)新互聯(lián)，專業(yè)網(wǎng)站建設(shè)公司。
成都創(chuàng)新互聯(lián)10余年專注成都高端網(wǎng)站建設(shè)定制開(kāi)發(fā)服務(wù),為客戶提供專業(yè)的成都網(wǎng)站制作,成都網(wǎng)頁(yè)設(shè)計(jì),成都網(wǎng)站設(shè)計(jì)服務(wù);成都創(chuàng)新互聯(lián)服務(wù)內(nèi)容包含成都網(wǎng)站建設(shè)，小程序開(kāi)發(fā)，營(yíng)銷網(wǎng)站建設(shè)，網(wǎng)站改版，服務(wù)器托管租用等互聯(lián)網(wǎng)服務(wù)。
網(wǎng)站題目：深入解析Oracle數(shù)據(jù)庫(kù)日志內(nèi)容，掌握關(guān)鍵信息 (oracle數(shù)據(jù)庫(kù)日志內(nèi)容)
新聞來(lái)源：http://www.5511xx.com/article/ccsheje.html
