如何查看oracle監(jiān)聽日志文件

Oracle日志查看 一．Oracle日志的路徑： 登錄：sqlplus "/as sysdba" 查看路徑：SQL select * from v$logfile; SQL select * from v$logfile;(#日志文件路徑) 二．Oracle日志文件包含哪些內(nèi)容：（日志的數(shù)量可能略有不同） 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日志的查看方法： SQLselect * from v$sql (#查看最近所作的操作) SQLselect * fromv $sqlarea（#查看最近所作的操作） Oracle 數(shù)據(jù)庫的所有更改都記錄在日志中，從目前來看，分析Oracle日志的唯一方法就是使用Oracle公司提供的LogMiner來進(jìn)行，因為原始的日志信息我們根本無法看懂，Oracle8i后續(xù)版本中自帶了LogMiner,而LogMiner就是讓我們看懂日志信息的工具,通過這個工具可以：查明數(shù)據(jù)庫的邏輯更改，偵察并更正用戶的誤操作，執(zhí)行事后審計，執(zhí)行變化分析。

創(chuàng)新互聯(lián)主要從事成都做網(wǎng)站、成都網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)欒川,十余年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792

oracle rac 監(jiān)聽日志在什么位置

你在操作系統(tǒng)上執(zhí)行命令：lsnrctl status 查看監(jiān)聽狀態(tài)

會輸出一些信息

可以看到一個叫l(wèi)istener.log的文件，便是監(jiān)聽的日志，按照路徑找到即可。

版本不同，可能名字也會有變化，12c的叫l(wèi)og.xml

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)致緩沖隊列堆積。下面我們通過兩個方面驗證上述猜想：首先通過日志可以得到隊列在大約 20000s 內(nèi)推送了大約 2000 次，即平均 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)行定制化修改。

如何查看oracle的日志文件

Oracle日志文件查看方法：

1、以sysdba權(quán)限用戶登錄數(shù)據(jù)庫。

2、執(zhí)行sql語句：

select?*?from?v$logfile;

3、結(jié)果顯示即為日志路徑：

4、另外還有其他的操作日志可用以下兩個sql語句查詢：

select?*?from?v$sql;--(#查看最近所作的操作)

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

如何啟動Oracle的監(jiān)聽日志

啟動監(jiān)聽日志的步驟如下：

1.首先查看當(dāng)前監(jiān)聽的狀態(tài)

[oracle@oel ~]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 01-JUL-2012 13:29:58

Copyright (c) 1991, 2011, Oracle. All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oel)(PORT=1521)))

STATUS of the LISTENER

————————

Alias listener

Version TNSLSNR for Linux: Version 11.2.0.3.0 – Production

Start Date 01-JUL-2012 13:12:51

Uptime 0 days 0 hr. 17 min. 7 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora

Listening Endpoints Summary…

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oel)(PORT=1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

Services Summary…

Service “orcl” has 1 instance(s).

Instance “orcl”, status READY, has 1 handler(s) for this service…

Service “orclXDB” has 1 instance(s).

Instance “orcl”, status READY, has 1 handler(s) for this service…

The command completed successfully

從上面顯示信息來看，我們監(jiān)聽正常。并且沒有看到Listener Log File的信息。

2.進(jìn)入監(jiān)聽配置，查看監(jiān)聽詳細(xì)信息

[oracle@oel ~]$ lsnrctl –進(jìn)入監(jiān)聽配置

LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 01-JUL-2012 13:35:00

Copyright (c) 1991, 2011, Oracle. All rights reserved.

Welcome to LSNRCTL, type “help” for information.

LSNRCTL show –查看監(jiān)聽參數(shù)信息

The following operations are available after show

An asterisk (*) denotes a modifier or extended command:

rawmode displaymode

rules trc_file

trc_directory trc_level

log_file log_directory

log_status current_listener

inbound_connect_timeout startup_waittime

snmp_visible save_config_on_stop

dynamic_registration enable_global_dynamic_endpoint

oracle_home pid

connection_rate_limit

LSNRCTL show log_status –查看監(jiān)聽日志狀態(tài)

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oel)(PORT=1521)))

LISTENER parameter “l(fā)og_status” set to OFF

The command completed successfully

上面信息顯示Listener parameter “l(fā)og_status” set to OFF說明監(jiān)聽日志是關(guān)閉的。這是時候我們需要啟動監(jiān)聽日志。

3.設(shè)置當(dāng)前監(jiān)聽，如果有多個監(jiān)聽，在修改監(jiān)聽配置的時候需要指定某個具體的監(jiān)聽，我這里只有一個默認(rèn)的Listener，所以不需要設(shè)置。我這里還是演示一下。

LSNRCTL show current_listener

Current Listener is LISTENER

LSNRCTL set current_listener Listener

Current Listener is Listener

LSNRCTL show current_listener

Current Listener is Listener

4.啟動監(jiān)聽日志,并且保存配置信息

LSNRCTL set log_status on –設(shè)置監(jiān)聽日志狀態(tài)為on

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oel)(PORT=1521)))

LISTENER parameter “l(fā)og_status” set to ON

The command completed successfully

LSNRCTL save_config –保存監(jiān)聽配置

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oel)(PORT=1521)))

Saved listener configuration parameters.

Listener Parameter File /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora

Old Parameter File /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.bak

The command completed successfully

5.在查看監(jiān)聽狀態(tài)

[oracle@oel ~]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 01-JUL-2012 13:44:32

Copyright (c) 1991, 2011, Oracle. All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oel)(PORT=1521)))

STATUS of the LISTENER

————————

Alias listener

Version TNSLSNR for Linux: Version 11.2.0.3.0 – Production

Start Date 01-JUL-2012 13:12:51

Uptime 0 days 0 hr. 31 min. 41 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora

Listener Log File /u01/app/oracle/diag/tnslsnr/oel/listener/alert/log.xml

Listening Endpoints Summary…

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oel)(PORT=1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

Services Summary…

Service “orcl” has 1 instance(s).

Instance “orcl”, status READY, has 1 handler(s) for this service…

Service “orclXDB” has 1 instance(s).

Instance “orcl”, status READY, has 1 handler(s) for this service…

The command completed successfully

通過上述配置之后，看到了Listener Log File /u01/app/oracle/diag/tnslsnr/oel/listener/alert/log.xml

最后我們可以通過監(jiān)聽日志來查詢里面的詳細(xì)信息

[oracle@oel ~]$ grep ‘2012-07-01T13:45:40′ /u01/app/oracle/diag/tnslsnr/oel/listener/alert/log.xml|more

msg time=’2012-07-01T13:45:40.302+08:00′ org_id=’oracle’ comp_id=’tnslsnr’

本文題目：oracle如何監(jiān)控日志,windows清理oracle監(jiān)聽日志
瀏覽路徑：http://chinadenli.net/article19/dsippdh.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、App設(shè)計、移動網(wǎng)站建設(shè)、品牌網(wǎng)站建設(shè)、面包屑導(dǎo)航、軟件開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)