當執行乙個大的事務或資料量比較大時，停止整合抽取程序ex1，發現不能停止，然後直接kill，此時，再start ex1，發現ex1是running狀態，但checkpoint lag一直在增加，也獲取不到scn。然後再
kill ex1,
alter ex1, begin now,
start ex1,
info ex1
檢視之後，仍然是相同的情況。
ggsci (win7ora as src_ogg@orcl) 407> info ex1extract ex1 last started 2017-11-29 09:23 status running
checkpoint lag 00:00:10 (updated 00:00:08 ago)
process id 3854
log read checkpoint oracle integrated redo logs
2017-11-29 09:24:02
scn 0. (0)
經分析，應該是整合抽取的讀取點有記錄在db的某個系統表裡，造成，即使修改begin now，也不起作用。經查詢ogg reference文件，有看到如下一段說明
發現即使alter ex1, begin now之後，上面的first scn也未變化，所以此引數無法調整抽取程序的讀取點，即不能跳過某些日誌或事務。
簡單的delete程序之後，重新add extract，結果相同。
最終，將程序unregister extract ex1 database之後，再重新register，first scn有發生變化。
ggsci (win7ora as src_ogg@orcl) 407> info ex1extract ex1 last started 2017-11-29 10:23 status running
checkpoint lag 00:00:10 (updated 00:00:08 ago)
process id 3856
log read checkpoint oracle integrated redo logs
2017-11-29 14:58:42
scn 0.6794325 (6794325)
停止程序提示處於recovery狀態
ggsci (win7ora as src_ogg@orcl) 408> stop ex1sending stop request to extract ex1 ...
stop request pending. recovery is not complete.
this normal stop will wait and checkpoint recovery's work when recovery has finished.
to force extract to stop now, use the send extract ex1, forcestop command..
ggsci (win7ora as src_ogg@orcl) 409> info ex1extract ex1 last started 2017-11-29 10:23 status running
checkpoint lag 00:00:09 (updated 00:00:01 ago)
process id 3856
log read checkpoint oracle integrated redo logs
2017-11-29 14:59:04
scn 0.6794344 (6794344)
ggsci (win7ora as src_ogg@orcl) 406> send ex1, statussending status request to extract ex1 ...
extract ex1 (pid 3856)
current status: in recovery[1]: processing data
current read position:
redo thread #: 1
sequence #: 0
rba: 0
timestamp: 2017-11-29 09:50:36.000000
scn: 0.0 (0)
current write position:
sequence #: 0
rba: 0
timestamp: 2017-11-29 10:23:14.560000
extract trail: ./dirdat/ea
ggsci (win7ora as src_ogg@orcl) 432> send ex1, statussending status request to extract ex1 ...
extract ex1 (pid 1304)
current status: in recovery[1]: processing data
current read position:
redo thread #: 1
sequence #: 3221
rba: 7516312
timestamp: 2017-11-29 14:59:13.000000
scn: 0.6794348 (6794348)
current write position:
sequence #: 0
rba: 0
timestamp: 2017-11-29 10:23:14.560000
extract trail: ./dirdat/ea
ggsci (win7ora as src_ogg@orcl) 439> send ex1, statussending status request to extract ex1 ...
extract ex1 (pid 2528)
current status: recovery complete: processing data
current read position:
redo thread #: 1
sequence #: 3221
rba: 9566584
timestamp: 2017-11-29 15:01:06.000000
scn: 0.6794877 (6794877)
current write position:
sequence #: 45
rba: 3074
timestamp: 2017-11-29 15:01:05.188000
extract trail: ./dirdat/ea
ref:
關於整合抽取程序重啟後的現象分析
當執行乙個大的事務或資料量比較大時，停止整合抽取程序ex1，發現不能停止，然後直接kill，此時，再start ex1，發現ex1是running狀態，但checkpoint lag一直在增加，也獲取不到scn。然後再 kill ex1,alter ex1,begin now,start ex1,i...
關於Ehcache集群快取在應用重啟後的載入問題
sunchun122 發表於 12 2 12 11 1年前,0回 436閱 討論區 技術分享 9月22日 星期六下午 osc源創會 西安 正在報名 中 我的問題是 1 這個問題是最重要的，按照我的配置，快取的資料會被儲存到.data檔案裡面，也就是儲存到磁碟。那麼我的問題就來了，為什麼當我把應用重啟...
關於mysql重啟後丟失PID檔案的解決方法
步驟如下 先要確認錯誤原因 starting mysql.error the server quit without updating pid file tmp mysqld mysqld.pid 可以看出tmp路徑下的mysqld.pid檔案找不到了。原因 tmp是臨時資料夾，服務每次重啟都會清空...