建站
咨詢
售后
建站咨詢
新聞中心
隨著互聯(lián)網(wǎng)應(yīng)用的不斷增多，數(shù)據(jù)成為公司最為重要的資產(chǎn)之一，而數(shù)據(jù)庫則成為數(shù)據(jù)存儲(chǔ)與處理的重要工具。在眾多的數(shù)據(jù)庫軟件中，Oracle作為業(yè)界著名的數(shù)據(jù)庫軟件，以其高可靠性、高性能和高安全性而被廣泛應(yīng)用。
網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)建站！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了靜安免費(fèi)建站歡迎大家使用！
在Oracle數(shù)據(jù)庫中，日志文件是其重要組成部分之一。它記錄了數(shù)據(jù)庫發(fā)生的所有修改操作，包括增、刪、改等操作，為數(shù)據(jù)的穩(wěn)定性和完整性提供保證。本文將。
一、Oracle數(shù)據(jù)庫日志文件的作用
在Oracle數(shù)據(jù)庫的運(yùn)行過程中，日志文件扮演著至關(guān)重要的作用。Oracle數(shù)據(jù)庫日志文件共有三種：
1. 控制文件(Control File)
控制文件包含了數(shù)據(jù)庫的結(jié)構(gòu)及其狀態(tài)的信息，如數(shù)據(jù)文件的名稱和位置、日志文件的名稱和位置、備份信息等。控制文件對數(shù)據(jù)庫的恢復(fù)和重建非常重要。
2. 數(shù)據(jù)文件(Data File)
數(shù)據(jù)文件是指存儲(chǔ)數(shù)據(jù)的物理文件，它包含了表空間、數(shù)據(jù)塊、段以及數(shù)據(jù)項(xiàng)等數(shù)據(jù)庫對象的物理結(jié)構(gòu)和信息。通常情況下，數(shù)據(jù)文件分為數(shù)據(jù)文件組(Data File Group)，每個(gè)數(shù)據(jù)文件組擁有一組日志文件。
3. 日志文件(Redo Log File)
日志文件記錄了Oracle數(shù)據(jù)庫所有的修改操作，可以對于故障的回滾和恢復(fù)。它記錄了數(shù)據(jù)庫所做的每一個(gè)操作，創(chuàng)建表、修改表、刪除表都可以在日志文件中找到。由于日志文件的記錄操作比數(shù)據(jù)文件的記錄操作更快，因此它們非常適合用于故障恢復(fù)和歸檔。
日志文件由兩個(gè)或多個(gè)日志組成，每個(gè)日志文件的大小可能會(huì)達(dá)到幾個(gè)GB到TB的級(jí)別。目前Oracle數(shù)據(jù)庫默認(rèn)設(shè)置了2個(gè)日志文件，每個(gè)日志文件的大小為50MB。
二、Oracle數(shù)據(jù)庫日志文件的管理技巧
Oracle數(shù)據(jù)庫日志文件對于數(shù)據(jù)庫的穩(wěn)定性和完整性有著非常重要的作用，因此對于日志文件的管理也需要引起我們的重視。下面就介紹一下Oracle數(shù)據(jù)庫日志管理的相關(guān)技巧：
1. 常規(guī)維護(hù)
在Oracle數(shù)據(jù)庫的運(yùn)行過程中，我們需要注意對于日志文件的常規(guī)維護(hù)，包括備份日志文件、刪除舊日志文件、增加新日志文件等。
備份日志文件：在備份日志文件時(shí)，更好將備份文件存儲(chǔ)在不同的磁盤中，以備數(shù)據(jù)災(zāi)難時(shí)使用。
刪除舊日志文件：當(dāng)舊日志文件已無效時(shí)，我們需要將它們刪除以騰出空間。
增加新日志文件：在Oracle數(shù)據(jù)庫中，每組日志文件可以擁有多個(gè)日志文件，當(dāng)當(dāng)前的日志文件已滿時(shí)，我們就應(yīng)該考慮增加新日志文件。
2. 日志文件的性能優(yōu)化
在Oracle數(shù)據(jù)庫中，我們需要特別注意日志文件的性能優(yōu)化，以提升數(shù)據(jù)庫的運(yùn)行性能。通常情況下，我們可以通過順序?qū)懭氪疟P的方式來優(yōu)化日志文件的性能。
3. 控制文件管理
對于Oracle數(shù)據(jù)庫控制文件的管理也非常重要?？刂莆募饕涗浟藬?shù)據(jù)庫的整體信息，包括數(shù)據(jù)文件、日志文件、數(shù)據(jù)庫大小等信息。當(dāng)控制文件損壞或丟失時(shí)，數(shù)據(jù)庫很可能無法再次啟動(dòng)，因此控制文件的管理需要引起我們的重視。
4. 數(shù)據(jù)庫恢復(fù)與日志文件
在Oracle數(shù)據(jù)庫發(fā)生故障時(shí)，我們需要利用日志文件進(jìn)行恢復(fù)。在進(jìn)行數(shù)據(jù)庫恢復(fù)時(shí)，我們需要了解Oracle數(shù)據(jù)庫的工作機(jī)制，而日志文件是關(guān)鍵的恢復(fù)信息源。我們需要回滾所有未提交的操作，并將所有提交的操作重新應(yīng)用到恢復(fù)數(shù)據(jù)庫中。
以上就是對于Oracle數(shù)據(jù)庫日志文件的作用與管理技巧的詳細(xì)介紹。對于日志文件的常規(guī)維護(hù)、優(yōu)化性能以及恢復(fù)數(shù)據(jù)庫等都需要我們了解與掌握，以保證數(shù)據(jù)庫運(yùn)行的穩(wěn)定性和完整性。
相關(guān)問題拓展閱讀：
- ORACLE如何刪除歸檔日志文件？
- oracle數(shù)據(jù)庫的警告日志如何查看
ORACLE如何刪除歸檔日志文件？
可以嘗試這種方法：
1. 進(jìn)入rman
2. connect target /
3. crosscheck archivelog all;
4. delete expired archivelog all;
這時(shí)候我們再去OEM中看就一定看不到，如果你的從來沒有做過這個(gè)動(dòng)作的話，祥坦我們可以比較從這個(gè)動(dòng)作前的controlfile后動(dòng)作后的controlfile的大小!
ORACLE正確刪除歸檔并回收空間的方法
ORACLE正確逗簡刪除歸檔并回收空間的方法
一個(gè)ORACLE歸檔日志經(jīng)常滿，表現(xiàn)為/oraarchive 這個(gè)文件空間占用100％大家一定抱怨ORACLE為何沒有歸檔維護(hù)工具，很多人直接刪除了事，錯(cuò)了，ORACLE有，而且很智能，可以正確的刪除歸檔和FLASHBACK，不過切記,ORACLE歸檔日志對于ORACLE的數(shù)據(jù)恢復(fù)和備份非常重要，不到萬不得已不要?jiǎng)h除歸檔日志。
刪除歸檔日志的過程
以O(shè)RACLE用戶身份登錄到數(shù)據(jù)庫服務(wù)器主機(jī)或通過網(wǎng)絡(luò)連接
進(jìn)入ORACLE數(shù)據(jù)備份工具謹(jǐn)指桐
rman target/
或rman target/@orcl
在命令窗口里面執(zhí)行
DELETE ARCHIVELOG ALL COMPLETED BEFORE ‘SYSDATE-7’;
oracle數(shù)據(jù)庫的警告日志如何查看
?測試環(huán)境中出現(xiàn)了一個(gè)異常的告警現(xiàn)象：一條告警通過 Thanos Ruler 的 HTTP 接口觀察到持續(xù)處于 active 狀態(tài)，但是從 AlertManager 這邊看這條告警為已解決狀態(tài)。按照 DMP 平臺(tái)的設(shè)計(jì)，告警已解決指的是告警上設(shè)置的結(jié)束時(shí)間已經(jīng)過了當(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í)間，如果還沒到達(dá)自動(dòng)解決時(shí)間，則將該時(shí)間重置為 24h 后首先，因?yàn)榱私獾綔y試環(huán)境沒有手動(dòng)解決過異常告警，排除之一條；其次，由于該告警持續(xù)處于 active 狀態(tài)，所以不會(huì)是因?yàn)楦婢划a(chǎn)生了一次而接收到已解決狀態(tài)的告警，排除第二條；最后，告警的告警的產(chǎn)生時(shí)間念亂與自動(dòng)解決時(shí)間相差不是 24h，排除第三條。那問題出在什么地方呢？
分析
下面我們開始分析這個(gè)問題。綜合之一節(jié)的描述，初步的猜想是告警在到達(dá) AlertManager 前悉含的某些階段的處理過程太長，導(dǎo)致告警到達(dá) AlertManager 后就已經(jīng)過了自動(dòng)解決時(shí)間。我們從分析平臺(tái)里一條告警的流轉(zhuǎn)過程入手，找出告警在哪個(gè)處理階段耗時(shí)過長。首先，一條告警的產(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ì)分開，數(shù)據(jù)還是由 Prometheus Server 提供，而告警規(guī)則的計(jì)算則交由 Thanos Rule（下文簡稱 Ruler）處理。下圖是 Ruler 組件在集群中所處的位置：
看來，想要弄清楚現(xiàn)告警的產(chǎn)生到 AlertManager 之間的過程，需要先弄清除 Ruler 的大致機(jī)制。官方文檔對 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 提供的庫計(jì)算告警規(guī)則，并提供一些額外的功能。下面是 Ruler 中告警流轉(zhuǎn)過程：
請點(diǎn)擊輸入圖片描述
請點(diǎn)擊輸入圖片描述
首先，圖中每個(gè)告警規(guī)則 Rule 都有一個(gè) active queue（下面簡稱本地隊(duì)列），用來保存一個(gè)告警規(guī)則下的活躍告警。
其次，從本地隊(duì)列中取出告警，發(fā)送至 AlertManager 前，會(huì)被放入 Thanos Rule Queue（下面簡稱緩沖隊(duì)列），該緩沖隊(duì)列有兩個(gè)屬性：
capacity（默認(rèn)值為 10000）：控制緩沖隊(duì)列的大小，
maxBatchSize（默認(rèn)值為 100）：控制單次發(fā)送到 AlertManager 的更大告警數(shù)
了解了上述過程，再通過翻閱 Ruler 源碼發(fā)現(xiàn)，一條告警在放入緩沖隊(duì)列前，會(huì)為其設(shè)置一個(gè)默認(rèn)的自動(dòng)解決時(shí)間（當(dāng)前時(shí)間 + 3m），這里是影響告警自動(dòng)解決的開始時(shí)間，在這以后，有兩個(gè)階段可能影響告警的處理：1. 緩沖隊(duì)列階段2. 出緩沖隊(duì)列到 AlertManager 階段（
網(wǎng)絡(luò)延遲
影響）由于測試環(huán)境是局域網(wǎng)環(huán)境，并且也沒在環(huán)境上發(fā)現(xiàn)網(wǎng)絡(luò)相關(guān)的問題，我們初步排除第二個(gè)階段的影響，下面我們將注意力放在緩沖隊(duì)列上。通過相關(guān)源碼發(fā)現(xiàn)，告警在緩沖隊(duì)列中的處理過程大致如下：如果本地隊(duì)列中存在一條告警，其上次發(fā)送之間距離現(xiàn)在超過了 1m（默認(rèn)值，可修改），則將該告警放入緩沖隊(duì)列，并從緩沖隊(duì)列中推送最多 maxBatchSize 個(gè)告警發(fā)送至 AlertManager。反之，如果所有睜高笑本地隊(duì)列中的告警，在最近 1m 內(nèi)都有發(fā)送過，那么就不會(huì)推送緩沖隊(duì)列中的告警。也就是說，如果在一段時(shí)間內(nèi)，產(chǎn)生了大量重復(fù)的告警，緩沖隊(duì)列的推送頻率會(huì)下降。隊(duì)列的生產(chǎn)
方太
多，消費(fèi)方太少，該隊(duì)列中的告警就會(huì)產(chǎn)生堆積的現(xiàn)象。因此我們不難猜測，問題原因很可能是是緩沖隊(duì)列推送頻率變低的情況下，單次推送的告警數(shù)量太少，導(dǎo)致緩沖隊(duì)列堆積。下面我們通過兩個(gè)方面驗(yàn)證上述猜想：首先通過日志可以得到隊(duì)列在大約 20230s 內(nèi)推送了大約 2023 次，即平均 10s 推送一次。結(jié)合緩沖隊(duì)列的具體屬性，一條存在于隊(duì)列中的告警大約需要 (capacity/maxBatchSize)*10s = 16m，AlertManager 在接收到告警后早已超過了默認(rèn)的自動(dòng)解決時(shí)間（3m）。其次，Ruler 提供了 3 個(gè) metric 的值來監(jiān)控緩沖隊(duì)列的運(yù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ù)，也能佐證了緩沖隊(duì)列在某些時(shí)刻存在已滿的情況。
解決通過以上的分析，我們基本確定了問題的根源：Ruler 組件內(nèi)置的緩沖隊(duì)列堆積造成了告警發(fā)送的延遲。針對這個(gè)問題，我們選擇調(diào)整隊(duì)列的 maxBatchSize 值。下面介紹一下這個(gè)值如何設(shè)置的思路。由于每計(jì)算一次告警規(guī)則就會(huì)嘗試推送一次緩沖隊(duì)列，我們通過估計(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。也就是說，可以將 maxBatchSize 設(shè)置為系統(tǒng)中數(shù)量更大的那一類監(jiān)控實(shí)體，對于 DMP 平臺(tái)，一般來說是 MySQL 實(shí)例。
注意事項(xiàng)
上面的計(jì)算過程只是提供一個(gè)參考思路，如果最終計(jì)算出該值過大，很有可能對 AlertManager 造成壓力，因而失去緩沖隊(duì)列的作用，所以還是需要結(jié)合實(shí)際情況，具體分析。因?yàn)?DMP 將 Ruler 集成到了自己的組件中，所以可以比較方便地對這個(gè)值進(jìn)行修改。如果是依照官方文檔的介紹使用的 Ruler 組件，那么需要對源碼文件進(jìn)行定制化修改。
??
告警日志文件是一類特殊的跟蹤文件（trace file）。告警日志文件命名爛察一般為alert_.log，其中SID為ORACLE數(shù)據(jù)庫脊歷空實(shí)例名稱。數(shù)據(jù)庫告警日志是櫻瞎按時(shí)間順序記錄message和錯(cuò)誤信息。
oracle數(shù)據(jù)庫 日志文件的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于oracle數(shù)據(jù)庫 日志文件,深入了解Oracle數(shù)據(jù)庫日志文件的作用與管理技巧,ORACLE如何刪除歸檔日志文件？,oracle數(shù)據(jù)庫的警告日志如何查看的信息別忘了在本站進(jìn)行查找喔。
成都網(wǎng)站設(shè)計(jì)制作選創(chuàng)新互聯(lián)，專業(yè)網(wǎng)站建設(shè)公司。
成都創(chuàng)新互聯(lián)10余年專注成都高端網(wǎng)站建設(shè)定制開發(fā)服務(wù),為客戶提供專業(yè)的成都網(wǎng)站制作,成都網(wǎng)頁設(shè)計(jì),成都網(wǎng)站設(shè)計(jì)服務(wù);成都創(chuàng)新互聯(lián)服務(wù)內(nèi)容包含成都網(wǎng)站建設(shè)，小程序開發(fā)，營銷網(wǎng)站建設(shè)，網(wǎng)站改版，服務(wù)器托管租用等互聯(lián)網(wǎng)服務(wù)。
本文名稱：深入了解Oracle數(shù)據(jù)庫日志文件的作用與管理技巧 (oracle數(shù)據(jù)庫 日志文件)
網(wǎng)址分享：http://www.dlmjj.cn/article/coocece.html
