日本高清免费一本视频100禁_在线不卡欧美精品一区二区三区_国产一区二区好的精华液_中文综合在线_国产啊啊啊视频在线观看_大地资源网免费观看高清

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外包服務
IT電腦維護外包IT電腦維護外包
網站建設與維護IT網站建設與維護
IT設備采購服務IT設備采購服務
IT基礎設施服務IT基礎設施服務
IT應用及數據服務IT應用及數據服務
IT管理及流程服務IT管理及流程服務
二維碼 關閉
主站蜘蛛池模板: 亚州欧美在线_亚洲第一av在线播放_99er在线观看_日本欧美日韩_国产强被迫伦姧在线观看无码_啊灬啊灬啊灬啊高潮了_午夜看片网址_免费一级毛毛片 | 国内精品久久久久_免费国产小视频_国产免费看av_成年人的免费视频_69福利影院_国内精品一级片_韩日不卡视频_亚洲欧美综合区丁香五月小说 | av成人免费在线_色在线视频网站_国产ts视频_国内xxxx乱子另类_久久综合草_无码欧美熟妇人妻影院_九九热久久99国产盗摄蜜臀_色资源av | 成人性生活免费看_日韩区国产_成人精品视频99_2021精品极品国产色在线首页_亚洲中文字幕无码AV永久_久久久91av_1314免费观看www视频_欧洲美女与动性zozozo | 国产97碰免费视频_毛片全网站_日本在线观看www_久久精品一区二区三区四区五区_av喷水高潮喷水在线观看com_久久久av亚洲男天堂_亚洲成人日韩在线_亚洲一区蜜桃 | 18禁黄无遮挡网站免费_日本亚洲精品无码专区_狠狠爱免费视频_亚洲一区二区三区四区五区乱码_在线观看免费视频18_农村妇女野战bbxxx_欧美性生活精品_JK制服白丝超短裙自慰 | 中国日本在线视频中文字幕_a在线视频免费观看_午夜影院官网_在线不卡一区二区_黄色片网站日本_亚洲专区在线播放_娇妻被别人玩弄至高潮视频_久久91超碰人人澡人人爽 | 成年人视频在线看_欧美久久性视频_超碰aⅴ人人做人人爽欧美_噜噜噜91成人网_亚洲欧美丝袜精品久久_国产精品成人无码A片免费网址_91一二区_91久久久精品国产一区二区蜜臀 | 欧美成aⅴ人高清WW_亚洲色大成网站WWW永久麻豆_成全视频免费高清观看在线动漫_亚洲VA在线VA天堂VA欧美VA_2023天天操_视屏一区_a视频免费观看_国产成人综合久久精品 | 欧美日韩免费一_国产主播一区二区三区在线观看_欧美妇乱大交xxxxx_亚洲国产综合久久_久久一区二区免费视频_久久久国产精品麻豆_日本一区二区三区免费在线观看_www.youjizz.com国产 | 人人人妻人人澡人人爽欧美一区_91亚洲精品久久久中文字幕_亚洲第一网址_国产粗语刺激对白性视频_国产成人99_国产精品久久久一区二区三区网站_国产日韩在线视看第一页_欧美25p | 成人高清视频免费观看_国产精品VA在线观看无码_写真福利视频_精品国产经典三级在线看_密色av_国产欧美一区综合_中文字幕一二三区有限公司_久久久久97国产精 | 邻居少妇人妻互换_天天插日日插_91九色磁力_91tv最新地址入口_免费无人区男男码卡二卡_久久精品国产欧美日韩_扒开美女内裤狂揉下部_日本无限资源 | 国产精品18久久久_一本一道久久a久久精品_国产精品久久久久久高潮_九九在线国产视频_blacked蜜桃精品一区_亚洲最新av网站_免费av手机在线观看片_成人亚洲视频在线观看 | 欧美另类videosbestsex_亚洲av日韩av激情亚洲_国产欧美日韩在线播放_成年无码AⅤ片在线观看_青草精品视频_在线精品国产一区二区三区_四虎一区二区成人免费影院网址_日本视频在线 | 亚洲av无码专区青青草原_亚洲性射射_欧美乱子伦XXXX12在线_亚洲AV无码精品色午夜果冻_91精品国产综合久久久蜜臀图片_非她不可短剧免费观看_国产精品人成在线播放新网站_av一区二区免费 | 日本乱码一区二区三区芒果_成人在线观看免费_中文字幕亚洲欧美精品一区四区_国产又爽又猛又粗的A片_欧美情侣性视频_国产高清精品软件丝瓜软件_国产免费久久久久_亚洲美女视频网 | 久久综合九色综合欧美婷婷_我们的2018在线完整免费观看_噼里啪啦国语在线播放中文版_日本一区二区无卡高清视频_中文字字幕在线精品乱码_成人性影院_欧美成人精品不卡视频在线观看_玖玖热综合一区二区三区 | 青青草国产精品一区二区_亚洲九九九_成人福利视频在线_久久人妻无码一区二区三区_一本无码中文字幕手机在线_嫩草研究院在线观看_老司机免费_成人乱淫av日日摸夜夜爽节目 | 日韩女优一区二区三区_久久久久亚洲AV片无码V_日本国产一区_久久精品国产国产精品四凭_成av免费大片黄在线观看_日韩天堂一区_福利网站视频_国产精品人人妻人人爽久久 | 亚洲女同一区二区_色夜影院_一本一道久久a久久精品逆3p_日韩第六页_女人十八毛片a级毛片_无码av不卡一区二区三区_欧美三级日本三级_亚洲黄色的 | 亚洲最大在线视频_色成人在线_国产毛片18片毛一级特黄日韩a_91视频麻豆_国产91精品免费视频_自拍视频啪_69国产成人免费精品视频_先锋影音最新色资源站 | 日韩成人高清_精品韩国三级在线观看视频_天堂中文在线资源_久久久久91_最近最新中文第一页_日本丰满大乳无码免费看_日本韩国视频在线观看_无码人妻久久一区二区三区 | 麻豆911传媒_99在线精品视频在线观看_人人九九精_天天操天天射综合_特黄一毛二片一毛片_国产精品多久久久久久情趣酒店_久久综合给合综合久久_91久久精品亚洲中文字幕无码 | 99精品在线看_国产精品黑色蕾丝丁字裤_亚洲国产成人五月综合网_一区二区久久久_福利免费视频_久久青草av_人妻系列无码专区无码中出_芭乐草永久视频在线观看 | 久久综合精品国产一区二区三区_av不卡国产在线观看_天天躁日日躁狠狠躁性色AV_水蜜桃aⅴ无码专区_干干干日日日_国产精品成人一区二区不卡_国产一级黄色aaaa片_一区二区免费视频va | 精品人妻无码一区二区三区手机版_欧美日韩成人精品久久二区_免费成人av网址_免费看片www8x5xcom_内射欧美老妇WBB_掀开奶罩边躁狠狠躁苏玥视频_免费成人高清在线视频_毛片官网 | 成人一在线视频日韩国产_超碰在线公开97_久久亚洲精品国产一区_国产精品久久不能_午夜亚洲精品专区高潮日w_kaori肉感在线播放_www.四虎影视.com_欧美日韩久 | 亚洲国产无线乱码在线观看_中文幕无线码中文字蜜桃_日韩一区二区三区免费高清_超碰在线免费福利_岛国色网_老司机精品线观看视频_免费特级婬片日本高清视频_免费精品视频一区 | 日本黄色天堂_一级毛片免费毛片一级毛片免费_999久久久精品一区二区_日韩欧美中文字幕在线播放_丰满又黄又爽少妇毛片_免费污站18禁的刺激_亚洲成人欧美_经典国产乱子伦精品视频 | 欧美特级黄色片_字幕网91_av亚洲一区_欧美一区二区性_天天躁日日躁AAAAXXXX_亚洲欧美黑人猛交群_一级不卡免费视频_日本一本一区 黄色特级片_国产乱人伦精品一区二区_毛片一区二区三区_一级做a爱片久久_亚洲精品乱码久久久久久按摩观_久久久久久久国产精品影院_caoporn国产_全球AV集中精品导航福利 | 一区二区三区精_日韩在线视频精品_99精品欧美一区_国产色系视频在线观看_亚洲一区二区三区高清av_亚洲成人超碰_亚洲一区二区无码影院_97无码人妻福利免费公开在线视频 | 看国产一级片_亚洲中文无码av永久_污污小说h_国产成人影院_日韩一区二区三区四区五区_99国产麻豆精品_久久这里只有精品免费_亚洲日本天堂在线 | 色狠狠五月天_yellow毛片_免费看成人A片无码照片_国产视频福利一区_男人天堂网站_日本特级大片_成人在线观看免费网站_欧美日韩在线观看视频小说 | 午夜男女爽爽影院免费视频_国产成一区二区_日韩视频第一区_亚洲韩日精品_26uuu久久综合_亚洲综合国产一区二区三区_免费中文字幕日韩_九九热免费在线 | 99久久婷婷国产一区二区三区_性国产丰满麻豆videosex_99久久国产综合精品无码_国产一区99_就去色成人网_免费毛片一区二区三区久久久_国产四区在线观看_激情第一区仑乱 | 成人免费视频www在线观看我_日韩免费无码成人久久久久久片_91影院高清_一级毛片超级播放_亚洲综合伊人_911网站大全在线观看_成人综合婷婷国产精品久久_蝌蚪91在线 | 亚洲国产精_97伦理影院_国产放荡AV剧情演绎麻豆_国产不卡一区在线_亚洲天堂地址_又大又黄又粗又爽的免费视频_亚洲一及片_日产福利视频在线观看 | 男人进去女人爽免费视频_国内激情_午夜影院一级_狠狠做五月深爱婷婷_黄色一级大片免费_午夜久久久久久久久久久久_无码人妻丰满熟妇A片护士_免费看黄色大全 | 亚洲一区二区久久久久久_亚洲精品国产高清一线久久_丝袜美女被遭强高潮网站_鲁一鲁操一操_中文字幕精品视频在线观看_精品在线一区_中国成人亚色综合网站_久久久123 | 国产女合集_一级黄色靠逼_国产成人精品午夜福利在线播放_人成免费视频人成免费网_亚洲第一中文字幕在线_无码国模国产在线观看_一区网站在线观看_国产亚洲精品成人av久久ww |
网络维护咨询
服务器维护咨询
弱电项目咨询
桌面维护咨询
其它业务咨询