最新日韩欧美在线综合网_成人在线视_自拍偷拍第八页_欧美又大又粗又硬又色A片_亚洲精品国产成人片_一级片手机在线

IT之道-艾銻知道

您當前位置: 主頁 > 資訊動態 > 艾銻分享 >

it運維: 分析DB2活動日志滿的原因及解決DB2日志滿方法與避免方案


2020-03-29 16:39 作者:admin 瀏覽量:
企業上云為什么是數字化轉型升級的第一步
 
 
3月17日我們分享了一篇文章,”無企業,不上云”,被各大平臺轉載分享,這讓我們看到了互聯網的熱情,也看到了企業對上云的渴望,艾銻無限作為阿里云的戰略合作伙伴,我們更樂意幫助企業上云,讓更多的企業邁向數字化時代.
 
我們相信每一家企業都是IT企業,每一家企業都是互聯網企業,每一家企業都是數字化企業,這一切的基礎都是基于云,云將會成為企業最重要的基礎設施,就像水、媒、電一樣的重要.
那為什么云對于企業來說如此重要呢,主要有以下五個方面:

1、應變力
云端快速部署、自由擴展的優勢,使網站、APP等應用上線、迭代更加靈活,提高了信息系統的運營效率。云以突出的應變能力,適應多變的企業信息化進程,降低試錯成本,加快研發進度,增強企業創新的信心。

2、穩定性
云環境為企業業務創造了一個穩定、可靠的空間,使用戶體驗更好,客戶滿意度顯著提升。互聯網產品獲得流量和用戶粘性的核心是用戶體驗,在線用戶流暢訪問,便捷操作,才會有較高的市場占有率。

3、性價比
云計算優異的性價比,為企業信息化大幅降低了成本。使企業可以把更多的資金,投入到業務創新中。傳統企業轉型升級存在著大量的不確定性,低成本的云計算幫助企業消除了資金上的顧慮。

4、安全性

轉型中的傳統企業,因對網絡環境不熟悉,擔心網絡攻擊、數據泄露等安全問題。云計算服務商有專業的技術和高效的服務體系,幫助企業保護數據安全、規避安全風險和提供海量數據查詢,企業可以專注于網站和應用程序,而不是基礎設施。
 
5、擴展性
 
在企業信息化的成本結構中,購買硬件軟件成本占比很高,而實際用于開發的支出就相應很低,并且耗費時間較長。如果完全基于云開架設IT系統,幾個小時就可完成基本框架。如果業務增加,就是直接購買服務器,邊際效益很低,采用云后,由于云計算的高擴展性,通過邊際效益可實現成本下降。
綜上所述,未來云就像我們用的水、電、媒一樣成為企業的必須品,也會是最重要的基礎設施一個部分,所以數字化轉型的企業,首先要上云,再考慮如何整合和重構企業內部的數據,從而讓計算起到主導作用,最終實現企業數字化轉型終極目標.
 
 

分析DB2活動日志滿的原因及解決DB2日志滿方法與避免方案

日志使用
下圖顯示了并發事務條件下,日志使用的示意
 
有3個并發的程序Process 1、Process 2、Process 3。每一個程序都有兩個事務。藍塊代表SQL語句,紅塊代表commit操作,綠塊代表rollback操作。每一個向下的箭頭都代表日志緩沖區的數據被刷新到日志磁盤上(默認是每一次提交操作都會導致日志緩沖被刷新到磁盤上)。
在T1時刻,事務A commit,日志緩沖區被刷新到磁盤上。
在T2時刻,事務B commit,日志緩沖區被刷新到磁盤上,此時日志X使用完,但由于X中的事務C還沒有提交,所以X此時還是活動日志。
在上圖中,如果事務C一直沒有提交操作,那么日志X將永遠是首個活動日志(oldest transaction log),后續的日志也是活動日志,其他應用最終會導致日志滿。
活動日志
如果一個日志中包含有未提交的事務,那么這個日志就是活動日志(也有其他情況,比如雖然所有事務已經提交,但對應的更改還沒有持久化到磁盤上)。
首個活動日志(First Active Log)
第一個活動日志,首個活動日志之后的日志(也就是編號比首個活動日志大的日志)都是活動日志,可以通過數據庫的snapshot查看first active log, current active log, 以及 last active log.
1
2
3
4
5
$ db2 get snapshot for db on sample | grep -i "File number"
File number of first active log      = 0
File number of last active log       = 2
File number of current active log     = 0
File number of log being archived     = Not applicable
日志滿原因
DB2總的可用活動日志的最大空間是有限制的,當達到限制之后,就會發生日志滿的問題,限制為(LOGPRIMARY + LOGSECOND) * LOGFILSIZ * 4KB
日志滿的原因無非兩種:
1.) 一個小事務hold住了首個活動日志,一直沒有提交,導致首個活動日志一直是活動狀態,不被釋放。這個跟堵車類似,一輛車因發動機故障(事務沒有提交)堵住路口(占用首個活動日志),即使后面的車都沒有問題(后續事務正常提交),也無法通過路口,且會越積越多,最終導致整個路都堵滿車(日志滿)。
2.) 有個事務非常大,迅速用盡了所有的日志。
日志滿的表現:
首先應用會報出SQL0964C錯誤:
1
2
3
4
$ db2 "insert into test select * from test"
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0964C The transaction log for the database is full. SQLSTATE=57011
其次,db2diag.log中會有以下報錯
1
2
3
4
5
6
7
8
9
10
2017-03-09-17.24.50.315000+480 E3234873F644     LEVEL: Error
PID   : 8532         TID : 13028     PROC : db2syscs.exe
INSTANCE: DB2INST1       NODE : 000      DB  : SAMPLE
APPHDL : 0-453        APPID: *LOCAL.DB2INST1.170309092321
AUTHID : MIAOQINGSONG     HOSTNAME: ADMINIB-PR7US3I
EDUID  : 13028        EDUNAME: db2agent (SAMPLE)
FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:2860
MESSAGE : ADM1823E The active log is full and is held by application handle
     "0-441". Terminate this application by COMMIT, ROLLBACK or FORCE
     APPLICATION.
日志滿的臨時處理:
1. 可以通過增加LOGSECOND來臨時增加可用的日志大小(修改時需要加上immediate選項使之立即生效);增加LOGPRIMARY并沒有用,因為需要重啟數據庫才能生效。
2. force掉hold住首個活動日志的的應用,在force之前,可以抓取snapshot,看一下這個應用的狀態:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
$ db2 get snapshot for database on sample | grep -i oldest
Appl id holding the oldest transaction   = 441
 
$ db2 get snapshot for application agentid 441
 
      Application Snapshot
 
Application handle             = 441
Application status             = UOW Waiting         <<--應用狀態為UOW Waiting
Status change time             = 2017-03-09 17:23:15.068895
Application code page           = 1386
Application country/region code      = 86
DUOW correlation token           = *LOCAL.DB2INST1.170309092244
Application name              = db2bp.exe
Application ID               = *LOCAL.DB2INST1.170309092244
 
..
 
Connection request start timestamp     = 2017-03-09 17:22:44.963163 <<--應用連庫時間
Connect request completion timestamp    = 2017-03-09 17:22:45.961157
Application idle time           = 4 minutes 7 seconds
 
..
 
UOW log space used (Bytes)         = 664
Previous UOW completion timestamp     = 2017-03-09 17:22:45.961157
Elapsed time of last completed uow (sec.ms)= 0.000000
UOW start timestamp            = 2017-03-09 17:23:02.770477 <<--當前事務開始時間
UOW stop timestamp             =              <<--當前事務結束時間為空,說明還沒有commit
UOW completion status           =
 
..
 
Statement type               = Dynamic SQL Statement
Statement                 = Close
Section number               = 201
Application creator            = NULLID
Package name                = SQLC2K26
Consistency Token             =
Package Version ID             =
Cursor name                = SQLCUR201
Statement member number          = 0
Statement start timestamp         = 2017-03-09 17:23:15.067789
Statement stop timestamp          = 2017-03-09 17:23:15.068893
Elapsed time of last completed stmt(sec.ms)= 0.000024
Total Statement user CPU time       = 0.000000
Total Statement system CPU time      = 0.000000
..
Dynamic SQL statement text:  
select * from t1
<<--一個事務中可能有多條SQL,這個只表示當前正在執行或者最后執行過的SQL,并不能表示就是這條SQL導致了日志滿,這里抓取到的是一條SELECT語句,SELECT語句不占用日志。
1
2
3
$ db2 "force application (441)"
DB20000I The FORCE APPLICATION command completed successfully.
DB21024I This command is asynchronous and may not be effective immediately.
日志滿的避免:
1.)根據抓取到的應用的snapshot,找應用開發人員查看為何不肯提交,這才是避免問題再次出現的根本辦法。
2.)從DB2管理層面,可以設置數據庫配置參數max_log和num_log_span
3.)可以寫腳本,以固定的間隔抓取database snapshot中的Appl id holding the oldest transaction, 如果長時間不發生變化(比如2天),就Force掉。
補充說明:
查看每個應用使用的日志大小:
1 $ db2 "select application_handle,UOW_LOG_SPACE_USED,UOW_START_TIME FROM TABLE(MON_GET_UNIT_OF_WORK(NULL,-1)) order by UOW_LOG_SPACE_USED"
也可以通過db2pd -db <dbname> -transactions 查看每個正在使用的日志的情況
重點關注的參數有:
ApplHandl
The application handle of the transaction.
SpaceReserved
The amount of log space that is reserved for the transaction.
LogSpace
The total log space that is required for the transaction, including the used space and the reserved space for compensation log records.
通過對DB2活動日志滿原因的分析我們就可以找到解決此問題的方法同時避免此問題的再次出現
 

相關文章

IT外包服務
二維碼 關閉
主站蜘蛛池模板: 久久久久久av | 99久久精品一区二区成人 | 亚洲免费福利 | 人体精品一二三区 | ▇精东视频▇在线观看视频 | 国产亚洲第一精品综合Av | 欧洲美女粗暴牲交免费观看 | 麻豆视频播放 | mimiai最新地址久久 | 麻豆tv在线观看入口 | 免费av在| 最新毛片网 | 国产在线色 | 91精品啪在线观看国产老湿机 | 欧美色综合网站 | 久久久久久九九 | 内射囯产旡码丰满少妇 | 狠狠躁夜夜a产精品视频 | 91精品综合久久久久久久久久久 | 欧产日产国产精品精品 | 久久久久久中文字幕2020 | 国产精品日本一区二区在线看麻豆 | 国产精品嫩草影院ccm | sss海量视频在线观看 | 国产专区视频 | 五月天桃花网 | 国产精品亚洲一区二区无码 | 中文字幕亚洲在线 | 男男无码GV片在线看 | 久久久久国产精品熟女影院浪 | 新白娘子传奇50集免费赵雅芝版 | 69视频播放 | 直接观看黄网站免费视频 | 边摸边脱边吃奶边做视频 | 阿娇囗交全套码在线观看 | 精品人妻伦九区久久AAA片69 | 久久av喷吹av高潮av萌白 | 性一交一乱一色一免费无遮挡 | 东方800av| 大地资源在线观看官网 | 黄色在线观看视频免费 |