如何查看oracle的日志文件？

1、因?yàn)閛racle運(yùn)行在Linux系統(tǒng)下，首先，要連接Linux系統(tǒng)。

專注于為中小企業(yè)提供成都做網(wǎng)站、成都網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)平山免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了成百上千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

2、切換到oracle安裝用戶下。 我的用戶是 oracle。

3、運(yùn)行oracle的環(huán)境變量，在oracle 的根目錄下面，運(yùn)行 soruce .bash_prfile 命令， 以便 ? ? ? ?輸入相關(guān)命令。

4、運(yùn)行命令： cd $ORACLE_HOME 進(jìn)入oracle的安裝目錄。

5、在此輸入命令： find -name listener.log ，查找監(jiān)控日志文件。

6、運(yùn)行命令 cd ?到查看到的日志文件目錄。

7、運(yùn)行cat listener.log命令 查看日志文件。

如何查詢Oracle數(shù)據(jù)庫的操作日志

查看歸檔模式

conn /as sysdba

archive log list

如果數(shù)據(jù)庫為歸檔模式的話，可以通過logmnr來進(jìn)行挖掘日志文件查看這些信息的。如果是非歸檔模式。對(duì)不起無法查看了

開啟后臺(tái)進(jìn)程跟蹤，

設(shè)置參數(shù)(initsid.ora)

.backgroudn_dump_dest=目錄名 -- 指定根蹤文件存放的路徑

.user_dmup_test=目錄名 --指定用戶信息跟蹤文件的存放路徑

.用戶的跟蹤文件(.trc), 用TKPROF 來格式化用戶跟蹤文件

SQL 語句跟蹤即可。

.imed_statistics=true; --設(shè)置啟用 sql_trace =true;

.user_dump_dest=目錄 --指定跟蹤文件的存放路徑

.max_dump_file_size=5M --指定跟蹤文件最大尺寸

.SQL_TRACE=TRUE;

.動(dòng)態(tài)改變 ：alter session set sql_trace=true;

或者打開生成的跟蹤文件:

默認(rèn)在..\oralce\admin\user\udump\*.trc，由于oralce 生成的*.trc 直接打開格式不規(guī)格，看得很累，可以用tkprof gk 來格式化 ：c:\tkprof ora00001.trc a.txt

怎么獲取oracle數(shù)據(jù)庫變化日志

Oracle數(shù)據(jù)庫診斷文件(日志)查看

Diagnostic File（診斷文件）

1：診斷文件的作用

Diagnostic files ：

包含了后臺(tái)遇見重大事件的信息。

被用于解析問題，

被用于日常管理日志文件。

2：診斷文件日志的分類

分為兩類：

1： alterSID.log

-----background trace files （后臺(tái)進(jìn)程跟蹤文件）

2： trace files ---

-----user trace file （用戶trace 文件）

1：對(duì)于Background trace files文件的命名：

命名方式： SID_processname_PID.trc 對(duì)應(yīng)解釋 SID_進(jìn)程名_進(jìn)程號(hào).trc

2: 對(duì)于user trace files 的文件命名為:

SID_ora_PID.trc 解釋： SID_ora_進(jìn)程號(hào).trc

3：對(duì)于 alertSID.log 說明：

這個(gè)文件是為了記錄： 1：記錄一些操作命令

2：記錄主要事件的結(jié)果

3：以及日常的操作信息

4：被用于診斷數(shù)據(jù)庫錯(cuò)誤

每一個(gè)entry 都有一個(gè)time stamp（時(shí)間戳）和它關(guān)聯(lián)

該文件必須被ORACLE DBA管理

這個(gè)文件的位置在： BACKGROUND_DUMP_DEST

通過 show parameter dump 查看這個(gè)文件的位置：

這個(gè)文件中也包含數(shù)據(jù)庫的啟動(dòng)信息相當(dāng)于pfile或者spfile的內(nèi)容。

用管理員登錄：

2：下面是實(shí)戰(zhàn)操作：

首先用sysdba登錄后執(zhí)行：

[sql]

SQL show parameter dump

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

background_core_dump string partial

background_dump_dest string d:\app\topwqp\diag\rdbms\orcl\

orcl\trace

core_dump_dest string d:\app\topwqp\diag\rdbms\orcl\

orcl\cdump

max_dump_file_size string unlimited

shadow_core_dump string none

user_dump_dest string d:\app\topwqp\diag\rdbms\orcl\

orcl\trace

可以看到這些文件的路徑信息。

根據(jù)顯式的信息我找到我的文件位置：

目錄結(jié)構(gòu)如下：

下面說一下如何才能記錄信息到這些日志文件，需要一些開關(guān)，如果不開，記錄的只是

一點(diǎn)點(diǎn)信息而已：

兩種方式 能夠讓用戶tracing

1：session 級(jí)別的：

使用如下命令：

ALTER SESSSION SET SQL_TRACE = TRUE

第二種是執(zhí)行如下存儲(chǔ)過程：

dbms_system.SET_SQL_TRACE_IN_SESSION

第二個(gè)方式是 instance級(jí)別的：

設(shè)置初始化參數(shù)： SQL_TRACE = TRUE

一般采用session級(jí)別的。因?yàn)樵O(shè)置instance級(jí)別的容易造成log文件過大；

可以通過alterSID.log文件中的信息制作pfile 或者spfile文件啟動(dòng)

數(shù)據(jù)庫。

下面采用session級(jí)別的修改sql_trace為true即可在user_dump_dest中對(duì)應(yīng)文件中看到相應(yīng)的信息。

[sql]

SQL conn /as sysdba

已連接。

SQL alter session set sql_trace = true;

會(huì)話已更改。

執(zhí)行過后：查看

orcl_ora_7188.trc文件信息 PS：如果不知道哪個(gè)文件就把這個(gè)目錄下的全部刪除，再執(zhí)行sql就會(huì)看到生成的文件：

查看這個(gè)文件信息如下：

很詳細(xì)的執(zhí)行信息：

比如一個(gè)語句為：select * from dual

這個(gè)文件中會(huì)生成如下信息：

[plain]

*** 2013-06-13 22:58:20.776

=====================

PARSING IN CURSOR #1 len=18 dep=0 uid=0 oct=3 lid=0 tim=9184375464 hv=942515969 ad='232363f8' sqlid='a5ks9fhw2v9s1'

select * from dual

END OF STMT

PARSE #1:c=0,e=32,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9184375458

EXEC #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9184376205

FETCH #1:c=0,e=109,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=1,tim=9184376423

STAT #1 id=1 cnt=1 pid=0 pos=1 obj=115 op='TABLE ACCESS FULL DUAL (cr=3 pr=0 pw=0 time=0 us cost=2 size=2 card=1)'

FETCH #1:c=0,e=2,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=9184376893

是對(duì)這個(gè)sql的執(zhí)行的詳細(xì)解讀分析

下面貼上今天的部分執(zhí)行的信息：

[plain]

*** 2013-06-13 22:58:20.776

=====================

PARSING IN CURSOR #1 len=18 dep=0 uid=0 oct=3 lid=0 tim=9184375464 hv=942515969 ad='232363f8' sqlid='a5ks9fhw2v9s1'

select * from dual

END OF STMT

PARSE #1:c=0,e=32,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9184375458

EXEC #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9184376205

FETCH #1:c=0,e=109,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=1,tim=9184376423

STAT #1 id=1 cnt=1 pid=0 pos=1 obj=115 op='TABLE ACCESS FULL DUAL (cr=3 pr=0 pw=0 time=0 us cost=2 size=2 card=1)'

FETCH #1:c=0,e=2,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=9184376893

*** 2013-06-13 23:15:15.474

=====================

PARSING IN CURSOR #1 len=289 dep=0 uid=0 oct=3 lid=0 tim=10199053291 hv=2462394820 ad='232017e0' sqlid='7cfz5wy9caaf4'

SELECT NAME

NAME_COL_PLUS_SHOW_PARAM,DECODE(TYPE,1,'boolean',2,'string',3,'integer',4,'file',5,'number',

6,'big integer', 'unknown') TYPE,DISPLAY_VALUE

VALUE_COL_PLUS_SHOW_PARAM FROM V$PARAMETER WHERE UPPER(NAME) LIKE

UPPER(:NMBIND_SHOW_OBJ) ORDER BY NAME_COL_PLUS_SHOW_PARAM,ROWNUM

END OF STMT

PARSE #1:c=0,e=438,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=10199053285

=====================

PARSING IN CURSOR #2 len=210 dep=1 uid=0 oct=3 lid=0 tim=10199056088 hv=864012087 ad='29162590' sqlid='96g93hntrzjtr'

select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt,

timestamp#, sample_size, minimum, maximum, distcnt, lowval, hival,

density, col#, spare1, spare2, avgcln from hist_head$ where obj#=:1 and

intcol#=:2

END OF STMT

PARSE #2:c=0,e=568,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=3,tim=10199056084

EXEC #2:c=0,e=1024,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=3,tim=10199057412

FETCH #2:c=0,e=30,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=3,tim=10199057533

STAT #2 id=1 cnt=0 pid=0 pos=1 obj=411 op='TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=2 pr=0 pw=0 time=0 us)'

STAT #2 id=2 cnt=0 pid=1 pos=1 obj=413 op='INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=2 pr=0 pw=0 time=0 us)'

=====================

PARSING IN CURSOR #2 len=210 dep=1 uid=0 oct=3 lid=0 tim=10199057848 hv=864012087 ad='29162590' sqlid='96g93hntrzjtr'

select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt,

timestamp#, sample_size, minimum, maximum, distcnt, lowval, hival,

density, col#, spare1, spare2, avgcln from hist_head$ where obj#=:1 and

intcol#=:2

END OF STMT

EXEC #2:c=0,e=25,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=3,tim=10199057844

FETCH #2:c=0,e=13,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=3,tim=10199058128

EXEC #1:c=0,e=7034,p=0,cr=4,cu=0,mis=1,r=0,dep=0,og=1,tim=10199060756

FETCH #1:c=15600,e=13882,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=10199075783

FETCH #1:c=0,e=21,p=0,cr=0,cu=0,mis=0,r=5,dep=0,og=1,tim=10199076326

STAT #1 id=1 cnt=6 pid=0 pos=1 obj=0 op='SORT ORDER BY (cr=0 pr=0 pw=0 time=0 us cost=2 size=2115 card=1)'

STAT #1 id=2 cnt=6 pid=1 pos=1 obj=0 op='COUNT (cr=0 pr=0 pw=0 time=8 us)'

STAT #1 id=3 cnt=6 pid=2 pos=1 obj=0 op='HASH JOIN (cr=0 pr=0 pw=0 time=6 us cost=1 size=2115 card=1)'

STAT #1 id=4 cnt=35 pid=3 pos=1 obj=0 op='FIXED TABLE FULL X$KSPPI (cr=0 pr=0 pw=0 time=70 us cost=0 size=81 card=1)'

STAT #1 id=5 cnt=1915 pid=3 pos=2 obj=0 op='FIXED TABLE FULL X$KSPPCV (cr=0 pr=0 pw=0 time=19 us cost=0 size=203400 card=100)'

關(guān)于alter_SID.log中的內(nèi)容如下： 今天的：

注意這個(gè)文件中包含Oracle啟動(dòng)的參數(shù)信息：可以利用這些信息配置spfile或者pfile文件嘗試用這個(gè)配置的文件啟動(dòng)數(shù)據(jù)庫也可以的

[plain]

Thu Jun 13 22:13:43 2013

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Picked latch-free SCN scheme 2

Using LOG_ARCHIVE_DEST_1 parameter default value as D:\app\topwqp\product\11.1.0\db_1\RDBMS

Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST

Autotune of undo retention is turned on.

IMODE=BR

ILAT =18

LICENSE_MAX_USERS = 0

SYS auditing is disabled

Starting up ORACLE RDBMS Version: 11.1.0.6.0.

Using parameter settings in server-side spfile D:\APP\TOPWQP\PRODUCT\11.1.0\DB_1\DATABASE\SPFILEORCL.ORA

System parameters with non-default values:

processes = 150

memory_target = 412M

control_files = "D:\APP\TOPWQP\ORADATA\ORCL\CONTROL01.CTL"

control_files = "D:\APP\TOPWQP\ORADATA\ORCL\CONTROL02.CTL"

control_files = "D:\APP\TOPWQP\ORADATA\ORCL\CONTROL03.CTL"

db_block_size = 8192

compatible = "11.1.0.0.0"

db_recovery_file_dest = "D:\app\topwqp\flash_recovery_area"

db_recovery_file_dest_size= 2G

fast_start_mttr_target = 0

undo_tablespace = "UNDOTBS1"

remote_login_passwordfile= "EXCLUSIVE"

db_domain = ""

dispatchers = "(PROTOCOL=TCP) (SERVICE=orclXDB)"

audit_file_dest = "D:\APP\TOPWQP\ADMIN\ORCL\ADUMP"

audit_trail = "DB"

db_name = "orcl"

open_cursors = 300

diagnostic_dest = "D:\APP\TOPWQP"

Thu Jun 13 22:13:46 2013

PMON started with pid=2, OS id=1888

Thu Jun 13 22:13:46 2013

VKTM started with pid=3, OS id=4296 at elevated priority

Thu Jun 13 22:13:46 2013

DIAG started with pid=4, OS id=6804

VKTM running at (20)ms precision

Thu Jun 13 22:13:46 2013

oracle如何查看日志文件

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)行，因?yàn)樵嫉娜罩拘畔⑽覀兏緹o法看懂，oracle8i后續(xù)版本中自帶了logminer,而logminer就是讓我們看懂日志信息的工具,通過這個(gè)工具可以：查明數(shù)據(jù)庫的邏輯更改，偵察并更正用戶的誤操作，執(zhí)行事后審計(jì)，執(zhí)行變化分析。

oracle數(shù)據(jù)庫的警告日志如何查看

測(cè)試環(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(cè)試環(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ī)制。官方文檔對(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 上封裝了一層，并提供一些額外的功能。通過翻閱資料大致了解，Ruler 使用 Prometheus 提供的庫計(jì)算告警規(guī)則，并提供一些額外的功能。下面是 Ruler 中告警流轉(zhuǎn)過程：

請(qǐng)點(diǎn)擊輸入圖片描述

請(qǐng)點(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ò)延遲影響）由于測(cè)試環(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)象。因此我們不難猜測(cè)，問題原因很可能是是緩沖隊(duì)列推送頻率變低的情況下，單次推送的告警數(shù)量太少，導(dǎo)致緩沖隊(duì)列堆積。下面我們通過兩個(gè)方面驗(yàn)證上述猜想：首先通過日志可以得到隊(duì)列在大約 20000s 內(nèi)推送了大約 2000 次，即平均 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ā)送的延遲。針對(duì)這個(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í)體，對(duì)于 DMP 平臺(tái)，一般來說是 MySQL 實(shí)例。

注意事項(xiàng)

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

網(wǎng)站標(biāo)題：oracle數(shù)據(jù)如何日志,oracle怎么看日志
分享網(wǎng)址：http://chinadenli.net/article13/dsejogs.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、ChatGPT、搜索引擎優(yōu)化、定制網(wǎng)站、小程序開發(fā)、網(wǎng)站設(shè)計(jì)公司

廣告

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