oracle資料庫的日誌文件

㈠ Oracle的日誌文件存儲在什麼位置

1、通過sqlplus命令連接資料庫，查看伺服器是否已經開啟歸檔。

㈡ oracle如何查看日誌文件

oracle日誌查看
一．oracle日誌的路徑：
登錄：sqlplus
"/as
sysdba"
查看路徑：sql>
select
*
from
v$logfile;
sql>
select
*
from
v$logfile;(#日誌文件路徑)
二．oracle日誌文件包含哪些內容：（日誌的數量可能略有不同）
control01.ctl
example01.dbf
redo02.log
sysaux01.dbf
undotbs01.dbf
control02.ctl
redo03.log
system01.dbf
users01.dbf
control03.ctl
redo01.log
shttest.dbf
temp01.dbf
三．oracle日誌的查看方法：
sql>select
*
from
v$sql
(#查看最近所作的操作)
sql>select
*
fromv
$sqlarea（#查看最近所作的操作）
oracle
資料庫的所有更改都記錄在日誌中，從目前來看，分析oracle日誌的唯一方法就是使用oracle公司提供的logminer來進行，因為原始的日誌信息我們根本無法看懂，oracle8i後續版本中自帶了logminer,而logminer就是讓我們看懂日誌信息的工具,通過這個工具可以：查明資料庫的邏輯更改，偵察並更正用戶的誤操作，執行事後審計，執行變化分析。

㈢ oracle資料庫的警告日誌如何查看

‍測試環境中出現了一個異常的告警現象：一條告警通過 Thanos Ruler 的 HTTP 介面觀察到持續處於 active 狀態，但是從 AlertManager 這邊看這條告警為已解決狀態。按照 DMP 平台的設計，告警已解決指的是告警上設置的結束時間已經過了當前時間。一條發送至 AlertManager 的告警為已解決狀態有三種可能：1. 手動解決了告警2. 告警只產生了一次，第二次計算告警規則時會發送一個已解決的告警3. AlertManager 接收到的告警會帶著一個自動解決時間，如果還沒到達自動解決時間，則將該時間重置為 24h 後首先，因為了解到測試環境沒有手動解決過異常告警，排除第一條；其次，由於該告警持續處於 active 狀態，所以不會是因為告警只產生了一次而接收到已解決狀態的告警，排除第二條；最後，告警的告警的產生時間與自動解決時間相差不是 24h，排除第三條。那問題出在什麼地方呢？

分析

下面我們開始分析這個問題。綜合第一節的描述，初步的猜想是告警在到達 AlertManager 前的某些階段的處理過程太長，導致告警到達 AlertManager 後就已經過了自動解決時間。我們從分析平台里一條告警的流轉過程入手，找出告警在哪個處理階段耗時過長。首先，一條告警的產生需要兩方面的配合：

• metric 數據

• 告警規則

• 將 metric 數據輸入到告警規則進行計算，如果符合條件則產生告警。DMP 平台集成了 Thanos 的相關組件，數據的提供和計算則會分開，數據還是由 Prometheus Server 提供，而告警規則的計算則交由 Thanos Rule（下文簡稱 Ruler）處理。下圖是 Ruler 組件在集群中所處的位置：



首先，圖中每個告警規則 Rule 都有一個 active queue（下面簡稱本地隊列），用來保存一個告警規則下的活躍告警。

其次，從本地隊列中取出告警，發送至 AlertManager 前，會被放入 Thanos Rule Queue（下面簡稱緩沖隊列），該緩沖隊列有兩個屬性：

capacity（默認值為 10000）：控制緩沖隊列的大小，

maxBatchSize（默認值為 100）：控制單次發送到 AlertManager 的最大告警數

了解了上述過程，再通過翻閱 Ruler 源碼發現，一條告警在放入緩沖隊列前，會為其設置一個默認的自動解決時間（當前時間 + 3m），這里是影響告警自動解決的開始時間，在這以後，有兩個階段可能影響告警的處理：1.緩沖隊列階段2.出緩沖隊列到 AlertManager 階段（網路延遲影響）由於測試環境是區域網環境，並且也沒在環境上發現網路相關的問題，我們初步排除第二個階段的影響，下面我們將注意力放在緩沖隊列上。通過相關源碼發現，告警在緩沖隊列中的處理過程大致如下：如果本地隊列中存在一條告警，其上次發送之間距離現在超過了 1m（默認值，可修改），則將該告警放入緩沖隊列，並從緩沖隊列中推送最多 maxBatchSize 個告警發送至 AlertManager。反之，如果所有本地隊列中的告警，在最近 1m 內都有發送過，那麼就不會推送緩沖隊列中的告警。也就是說，如果在一段時間內，產生了大量重復的告警，緩沖隊列的推送頻率會下降。隊列的生產方太多，消費方太少，該隊列中的告警就會產生堆積的現象。因此我們不難猜測，問題原因很可能是是緩沖隊列推送頻率變低的情況下，單次推送的告警數量太少，導致緩沖隊列堆積。下面我們通過兩個方面驗證上述猜想：首先通過日誌可以得到隊列在大約 20000s 內推送了大約 2000 次，即平均 10s 推送一次。結合緩沖隊列的具體屬性，一條存在於隊列中的告警大約需要 (capacity/maxBatchSize)*10s = 16m，AlertManager 在接收到告警後早已超過了默認的自動解決時間（3m）。其次，Ruler 提供了 3 個 metric 的值來監控緩沖隊列的運行情況：

thanos_alert_queue_alerts_dropped_total

thanos_alert_queue_alerts_pushed_total

thanos_alert_queue_alerts_popped_total

通過觀察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丟失的總數，也能佐證了緩沖隊列在某些時刻存在已滿的情況。

解決通過以上的分析，我們基本確定了問題的根源：Ruler 組件內置的緩沖隊列堆積造成了告警發送的延遲。針對這個問題，我們選擇調整隊列的 maxBatchSize 值。下面介紹一下這個值如何設置的思路。由於每計算一次告警規則就會嘗試推送一次緩沖隊列，我們通過估計一個告警數量的最大值，得到 maxBatchSize 可以設置的最小值。假設你的業務系統需要監控的實體數量分別為 x1、x2、x3、...、xn，實體上的告警規則數量分別有 y1、y2、y3、...、yn，那麼一次能產生的告警數量最多是(x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn)，最多推送（y1 + y2 + y3 + ... + yn）次，所以要使緩沖隊列不堆積，maxBatchSize 應該滿足：maxBatchSize >= (x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn) / (y1 + y2 + y3 + ... + yn)，假設 x = max(x1,x2, ...,xn), 將不等式右邊適當放大後為 x，即 maxBatchSize 的最小值為 x。也就是說，可以將 maxBatchSize 設置為系統中數量最大的那一類監控實體，對於 DMP 平台，一般來說是 MySQL 實例。

注意事項

上面的計算過程只是提供一個參考思路，如果最終計算出該值過大，很有可能對 AlertManager 造成壓力，因而失去緩沖隊列的作用，所以還是需要結合實際情況，具體分析。因為 DMP 將 Ruler 集成到了自己的組件中，所以可以比較方便地對這個值進行修改。如果是依照官方文檔的介紹使用的 Ruler 組件，那麼需要對源碼文件進行定製化修改。


‍‍

㈣ oracle 聯機重做日誌文件和重做日誌文件有什麼區別

聯機重做日誌文件是：redo
log
資料庫的每一個操作都會產生日誌，記錄在這里，做回滾、recovery等都需要這個，它有問題資料庫起不來。
重做日誌是
Archive
log
，資料庫如果不開歸檔模式，不會產生archive
log。如果開了，redo
log文件寫滿了，就會復制到一個archive
log
文件，然後redo
log
重復使用。這個主要用於資料庫的備份恢復。

㈤ 如何查看oracle的日誌文件

1、因為oracle運行在Linux系統下，首先，要連接Linux系統。

㈥ oracle的日誌文件有哪些

在Oracle資料庫中，有一種日誌文件叫做重做日誌文件，他就是大家俗稱的：redolog。在redolog中又分為兩種：在線重做日誌與歸檔日誌。
ONLINE Redo log
在線重做日誌(online redo log )主要用於：Oracle資料庫所在伺服器突然掉電、突然重啟或者執行shutdown abort等命令使得在伺服器重新啟動之後，Oracle資料庫沒有辦法正常的啟動實例。此時，在線重做日誌就派上了用場，Oracle會使用在線重做日誌，把資料庫恢復到伺服器掉電前的那一個時刻，從而使得資料庫能正常的啟動起來 。
在Oracle資料庫中，默認情況下，至少會有兩個重做日誌組，而且每個組裡面至少包含了一個重做日誌文件。日誌組不會自動增加，在一個寫滿之後，會自動去寫下一個。在下一個被寫滿之後會又從第一個開始寫起。
Archive redo log
歸檔日誌(archive log)主要用於硬體級別的錯誤：磁碟的壞道導致無法讀寫、寫入的失敗、磁碟受損導致資料庫數據丟失。這就要使用歸檔日誌文件，通過歸檔日誌文件，把資料庫恢復到歸檔日誌所在的時間點上然後再通過在線重做日誌文件把資料庫恢復到當前的時間點上。
對於歸檔日誌文件，可以理解為在線重做日誌文件的備份。即當一個重做日誌文件被填滿了之後，歸檔日誌文件就會把其備份保留一份。（因為上面說了，在線重做日誌文件會自動的覆蓋）所以，歸檔日誌文件就是舊的在線日誌文件的備份。

㈦ 如何查看oracle的日誌文件

Oracle日誌文件查看方法：

1、以sysdba許可權用戶登錄資料庫。
2、執行sql語句：

select*fromv$logfile;

3、結果顯示即為日誌路徑：

select*fromv$sql;--(#查看最近所作的操作)
select*fromv$sqlarea;--（#查看最近所作的操作）

㈧ 什麼是oracle 日誌文件

oracle的日誌文件是記錄資料庫變化的一個憑證. oracle的文件可以分為 數據文件、控制文件和重做日誌文件(也就是咱們平時說的redo), oracle的日誌文件時分組存放的, 一個oracle資料庫最少使用3個日誌文件存放這些信息, 以防寫滿之後的溢出, 為了防止資料庫的災難性宕機, 日誌文件可以提供一個支持, 可以把資料庫恢復到宕機之前的某個時間點, 我們也經常對日誌文件做一些操作, 常用的操作如下:
1.查詢系統使用的是哪一組日誌文件：
select * from v$log;

2.查詢正在使用的組所對應的日誌文件：
select * from v$logfile;

3.強制日誌切換：
alter system switch logfile;

4.查詢歷史日誌：
select * from v$log_history;

5.查詢日誌的歸檔模式：
select dbid,name,created,log_mode from v$database;

6.查詢歸檔日誌的信息：
select recid,stamp,thread#,sequence#,name from v$archived_log;

7.增加與刪除日誌文件組
alter database add logfile group 1 ('/home1/oracle/oradata/ora8i/log1a.log'),'/home2/oracle/oradata/ora8i/log1b.log') size 100M;

alter database drop logfile group 1;

8.增加與刪除日誌成員
alter database add logfile member '/home1/oracle/oradata/ora8i/log1a.log' to group 1,'/home1/oracle/oradata/ora8i/log2a.log' to group 2;

alter database drop logfile member '/home1/oracle/oradata/ora8i/log1a.log' ;

9.日誌文件移動
alter database rename file '/home1/oracle/oradata/ora8i/log1a.log' to '/home2/oracle/oradata/ora8i/log1a.log';
執行該命令之前必須保證該日誌文件物理上已經移動到新目錄

10.清除日誌文件
alter database clear logfile '/home1/oracle/oradata/ora8i/log1a.log';
該命令不能用刪除組及組成員命令刪除日誌時使用

㈨ 如何正確刪除ORACLE歸檔日誌文件

一、首先刪除歸檔日誌物理文件，歸檔日誌一般都是位於archive目錄下，AIX系統下文件格式為「1_17884_667758186.dbf」，建議操作前先對資料庫進行備份，刪除時至少保留最近幾天的日誌用於資料庫恢復。

二、把歸檔日誌的物理文件刪除後，我們就可以正常登入ORACLE了，但是還沒完全把歸檔日誌刪除干凈，ORACLE的controlfile中仍然記錄著這些archivelog的信息，在oracle的OEM管理器中有可視化的日誌展現出，當我們手工清除archive目錄下的文件後，這些記錄並沒有被我們從controlfile中清除掉，接下去我們要做的就是這個工作。
我們利用RMAN進行刪除操作，操作步驟如下：(window客戶端系統為例)
1.指定資料庫實例
C:/Documents and Settings/Administrator>SET ORACLE_SID =orcl
2.連接資料庫
C:/Documents and Settings/Administrator>RMAN TARGET SYS/sysadmin@orcl
3.查看歸檔日誌的狀態
RMAN> list archivelog all;
4.手工刪除歸檔日誌文件
RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
說明：
SYSDATA-7，表明當前的系統時間7天前，before關鍵字表示在7天前的歸檔日誌，如果使用了閃回功能，也會刪除閃回的數據。
同樣道理，也可以刪除從7天前到現在的全部日誌，不過這個命令要考慮清楚，做完這個刪除，最好馬上進行全備份資料庫
DELETE ARCHIVELOG from TIME 'SYSDATE-7'; 刪除從7天前到現在的全部日誌,慎用
UNIX/LINUX下也可以通過FIND找到7天前的歸檔數據，使用EXEC子操作刪除
find /oraarchive -xdev -mtime +7 -name "*.dbf" -exec rm -f {} ;
這樣做仍然會在RMAN里留下未管理的歸檔文件
仍需要在RMAN里執行下面2條命令
crosscheck archivelog all;
delete expired archivelog all;
所以還不如上面的方法好用，不過用FIND的好處就是，可以在條件上，和EXEC子項上做很多操作，實現更復雜的功能
5.退出rman
RMAN> exit

㈩ Oracle資料庫由哪幾種文件組成

Oracle資料庫由資料庫文件、日誌文件、控制文件組成。

Oracle資料庫12c引入了一個新的多承租方架構，使用該架構可輕松部署和管理資料庫雲。此外，一些創新特性可最大限度地提高資源使用率和靈活性，如Oracle Multitenant可快速整合多個資料庫，而Automatic Data Optimization和Heat Map能以更高的密度壓縮數據和對數據分層。

這些獨一無二的技術進步再加上在可用性、安全性和大數據支持方面的主要增強，使得Oracle資料庫12c成為私有雲和公有雲部署的理想平台。

(10)oracle資料庫的日誌文件擴展閱讀：

Oracle資料庫升級注意事項：

1、備份配置參數

資料庫升級前的配置參數要備份，如PGA大小。這樣資料庫升級後還可以升級前的配置，而不至於使用安裝升級時的默認配置。

2、檢查版本兼容

確認資料庫升級後是否對生產環境上的代碼有影響，如果發現一處有影響，則要在全部范圍內檢查類似的情況。

3、客戶端同步升級

同時升級開發者本地環境或應用程序的資料庫客戶端升級到與資料庫伺服器相同版本。

4、確保程序正常運行

資料庫升級後確保升級後的資料庫不會對連接該庫的應用程序有影響。