自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

DB2 Capture程序的正確解析,專家答疑版

數(shù)據庫
在這里我們主要向大家講述的是DB2 Capture程序的正確解析,專家答疑版,其中包括工程程序進程,修剪進程,以下就是正文主要內容描述。

文章主要向大家講述的是專家答疑之DB2 Capture程序的正確解析,我們大家都知道DB2 Capture程序是一個非常關鍵的應用程序,在數(shù)據庫復制的實際解決方案中表現(xiàn)尤為突出。這個程序的主要的作用就是追蹤在DB2服務器上對復制源所做的更改。

如果有更改的話,會將這些更改的記錄保存在一張?zhí)厥獾谋碇?CD表)。

 

通常情況下,這個應用程序時運行在控制服務器上。不過具體運行在哪個位置,根據操作系統(tǒng)的不同可以有不同的選擇。作為數(shù)據庫管理員,必須要將Capture程序牢牢的掌握在手中。讓其在關鍵的時候發(fā)揮關鍵的作用。具體的來說,需要在必要的時候,啟動如下幾個DB2 Capture程序相關的進程。

一、工程程序進程

 

如上圖所示,既然Capture程序主要用來監(jiān)測數(shù)據源表的變動并將相關的記錄保存到CD表中,那么必然要有一個進程,好像一只眼睛一樣,時刻盯著數(shù)據源表數(shù)據的的變化情況。如果有變化的話,即使告知其他進程。這個進程就叫做工作程序進程。通常情況下,當啟動Capture進程的時候,這個工作程序進程就會啟動。

 

工作程序進程與復制源所駐留的DB2數(shù)據庫相連,監(jiān)視復制源的更改情況。同時,其也決定了Capture程序的啟動方式(即根據相關的參數(shù)來決定是以熱啟動方式或者以冷啟動方式來啟動Capture程序)。當這個工作程序進程啟動的時候,它就會讀取活動的數(shù)據庫日志,以判斷相關的復制源(如基礎表、視圖)等等是否進行了更改。

只要啟動了這個進程,那么這個監(jiān)測會一直持續(xù)下去。也就是說,并不是用戶對復制源作了更改,才觸發(fā)這個進程。而是無論復制源是否有更改,這個進程一直都存在(只要啟動了DB2 Capture程序)。對于這個進程,筆者認為數(shù)據庫管理員需要從以下幾個方面去了解。

一是其監(jiān)測的內容來源。工作程序進程會讀取活動的數(shù)據庫日志。不過對于DB2數(shù)據庫來說,數(shù)據庫日志包括兩部分,分別為重做日志緩存與重做日志文件。由于內存的速度要比硬盤速度快的多,所以為了提高數(shù)據庫的性能,系統(tǒng)往往是先將數(shù)據存儲在內存中。然后在符合一定的條件下,再將內存中的數(shù)據保存到數(shù)據文件中。

而內存中的事務日志又可以分為兩類,分別為已落實的事務記錄(即已經遞交的事務)與未落實的事務記錄(還沒有遞交的事務)。工作程序進程在工作過程中,會收集內存中屬于每個事務的所有記錄,并每個一個固定的時間將收集到的已經落實的事務寫入到對應的CD表中。故其數(shù)據源其實是內存中已經落實了的事務記錄。

二是需要注意,一個時間間隔的問題。即隔多少時間,將相關的記錄保存到CD表中。如果這個時間間隔設置的比較長,那么數(shù)據的同步性就比較差。而如果設置的比較短的話,又會影響數(shù)據庫的性能。一般情況下,只要采取數(shù)據庫的默認設置即可。但是如果數(shù)據源表中的數(shù)據更改非常頻繁,則需要根據實際情況來合理調整這個時間參數(shù),以提高數(shù)據庫性能。

筆者的建議是,先采用默認的值,并進行數(shù)據庫性能的監(jiān)測。如果發(fā)現(xiàn)這個值不合適的話,則可以適當調整并繼續(xù)監(jiān)測其對數(shù)據庫性能的影響。經過幾次調試之后,就可以得到一個相對合理的時間間隔值。

二、修剪進程

如上圖所示,工作DB2 Capture程序進程會將復制源表的變化都保存到CD表中。而這個CD表中的數(shù)據又會根據不同的應用最終復制到其他的目的表中。也就是說,這個CD表只是一個中間表。一般用戶不會直接從這個表中讀取數(shù)據,而是通過其他的表來訪問CD表中的相關信息。此時就會引出一個新的問題。即隨著時間的推移,這個CD表中的數(shù)據會越來越多。

 

這不僅會影響數(shù)據庫的性能,而且還會浪費存儲的空間。由于CD表中的數(shù)據會根據一定的規(guī)則復制到目標表中。為此就需要有一種機制,來不定時的清理CD表中的數(shù)據,將垃圾數(shù)據清除出去。此時就需要用到修剪進程。

根據實際的應用,這個CD表中的數(shù)據可以分為兩種類型。一是CD表中的數(shù)據已經被復制到其他目的表中了,此時這個CD表中的數(shù)據已經沒有任何作用了。二是CD表中的數(shù)據雖然沒有被復制到其他表中,但是已近過了有效期限。此時這個數(shù)據也已經沒有用途了,也需要清除。針對這兩種不同的情況,又可以將修剪進程分為正常修剪進程與保留限制進程。

正常修剪進程就是指,當修剪集表和修剪控制表中的值顯示已經將組成這些行的事務復制到依賴于該CD表的所有目標表時,就會將CD表中的相關行以及工作單元表中相應的行刪除。簡單的說,就是需要用到這個CD表中的目標表已經將數(shù)據復制過去了,此時這個CD表中的相關記錄就會被刪除。不過需要注意,修剪也不是時刻進行的。

也就是說,不是目的表將CD表中的數(shù)據復制過去,這個表中的數(shù)據就被刪除了。另外需要注意的是,目的表只是把CD表中的數(shù)據復制過去,而不是剪貼過去。這主要是因為可能有多張目的表需要用到這個CD表中的數(shù)據。修剪進程會沒隔一段時間來檢查一下,是否滿足這個條件。如果滿足的話,就將CD表中的記錄刪除。而這個時間間隔是由參數(shù)PRUNE_INTERVAL決定的。

很顯然這個參數(shù)的值會影響到修剪進程的效率。如何這個參數(shù)的值設置的比較大,那么修剪進程作業(yè)的時間間隔就會比較長,這在一定程度上會提高數(shù)據庫的性能。但是如果設置的太長的話,則CD表中的記錄就會比較多,又會給數(shù)據庫的性能造成負面的影響。為此數(shù)據庫管理員必須要根據復制源數(shù)據更新的頻率,在必要的情況下要手工調整這個參數(shù)。

如果目的表永遠不從這個CD表中復制記錄,難道修剪進程永遠不刪除CD表中的記錄嗎?其實不然。在修剪進程中,除了正常修剪之外,還有一個保留限制修剪。這個這個修剪中,進程會檢查CD表中某些記錄的存在時間,是否超過了有效期。如果超過了的話,則保留限制修剪進程就會刪除CD表中的行以及工作單元表中相應的行。

這個CD表中的有效期是有參數(shù)RETENTION_LIMIT來控制的。顯然這個參數(shù)也非常的重要。如果這個參數(shù)設置的比較短,那么可能還沒等用戶復制記錄,表中記錄就會因為過了有效期而導致數(shù)據被刪除。但是如果設置的比較長的話,那么垃圾數(shù)據就會越來越多,浪費存儲空間,影響數(shù)據庫性能。

對此筆者的建議是,數(shù)據庫管理員需要在性能、存儲空間、RETENTION_LIMIT參數(shù)之間取得一個均衡的值。一般情況下,只要數(shù)據庫性能與存儲空間允許,則***將這個參數(shù)的值設置的比較長一點。以免這表中的數(shù)據在目的表還沒有復制之前就被刪除。

除了以上這兩個進程外,DB2 Capture程序還有管理進程、串行化進程等等。不過這些進程要么是數(shù)據庫自動管理的,要么就是對于Capture程序的影響不是很大??傊皇菙?shù)據庫管理員關注的重點,為此筆者就不做過多的闡述。筆者認為,從數(shù)據庫性能的角度考慮,數(shù)據庫管理員主要是要關注這個幾個進程中涉及到的時間間隔參數(shù)。

這些參數(shù)是把雙刃劍。設置的好,可以提高數(shù)據庫性能。如設置的不好,相反會降低數(shù)據庫的效率。

【編輯推薦】

  1. IBM DB2數(shù)據庫與注意事項_DB2編程的描述
  2. DB2 并行版本中的查詢優(yōu)化登峰造極!
  3. DB2數(shù)據庫進行備份在AIX如何操作?
  4. 對DB2 增量備份的正確運用描述
  5. DB2 存儲過程的異常處理器類型有幾種?

 

責任編輯:佚名 來源: 網絡整理
相關推薦

2010-08-09 13:15:05

DB2 Capture

2010-08-02 10:52:31

DB2取得當前時間

2015-10-23 16:35:11

DB2導出LOB

2010-08-20 08:52:25

DB2死鎖

2010-08-17 15:24:43

DB2數(shù)據移動

2010-08-11 15:48:04

DB2編程

2010-08-11 15:48:04

DB2編程

2010-08-09 16:16:58

DB2取得當前時間

2010-07-30 14:14:11

DB2快照函數(shù)

2010-09-06 16:36:20

DB2快照函數(shù)

2010-08-13 13:40:47

DB2編程序

2010-09-07 16:11:19

執(zhí)行DB2命令

2010-08-06 13:20:00

DB2鎖等待

2010-07-27 12:33:14

DB2數(shù)據庫

2010-08-02 14:03:49

DB2驅動類型

2010-08-18 15:14:08

DB2恢復命令

2009-07-06 17:34:26

遠程復制DB2

2010-08-06 11:28:51

DB2取得當前時間

2010-08-17 15:42:30

DB2 增量備份

2010-08-11 15:04:03

DB2備份
點贊
收藏

51CTO技術棧公眾號