Lotus Notes/Domino (R) をこよなく愛して。。。。

ようこそ、Notes/Domino ファン & ブロガーのみなさん !


【ご注意】 このブログはビジネスに活用いただくためのものですので、以下の点を守ってご利用願います。


1. 他社あるいは他人への誹謗中傷のコメントはご遠慮ください。

2. コメントはビジネスとして問題のない言葉、表現を使ってください。

3. Webで一般公開されていない、具体的な個人や法人を特定するコメントはご遠慮ください。

4. 個人情報の記載は行わないでください。


上記を守られないコメントは、こちらの判断で削除させていただきますのでご了承願います。


尚、このサイトの掲載内容は私自身の見解であり、メーカーとは全く関係はありません。

また、メーカーのビジネスに利害を及ぼすために記載している訳ではありません。


ここに記載されている内容は、私自身の経験からの記載であり、内容が正確でない場合もあることをご理解の上、ご利用願います。


ご利用に際しては、左側のフレームに記載しております【注】をご一読の上、利用条件を守ってご利用ください。

1 | 2 | 3 | 4 | 5 | 最初次のページへ >>

DBのReplica移動のLogicがV11.0.1 FP2で変更?!

V11.0.1 FP2でDBのReplica移動をする際にLogicが変更されているようです。

どのVersionから変更されたのかは把握できていませんがV9.0.1 FP10と動作が異なることが確認できています。

 

DBのReplica移動の場合、別のServerに移動する場合と、同一Server内でFolderを変更する場合がありますが、動作が変わったのは後者となります。

 

V9.0.1 FP10の場合は、Compact -cを発行した場合と同じ動作で、TMPファイルが生成され、このファイルにDBのCopyが行われ、完了後にTMPファイルがRenameされて元のDBが削除されるという動きをします。

 

この動きは、AdminPの処理ログやExplorerで移動先のFolderを見ていれば確認できます。

 

ところが、V11.0.1 FP2では、別のCluster ServerにReplica作成する場合と同じ動作をします。

 

つまり、

 

1) 相手先Server(この場合、自身のServerですが)のReplica作成権限の確認

2) Replica Stubの作成

3) Replicatorで高速Replicaの開始

4) Replica完了のMonitoringを行い完了を確認

5) 移動元DBの削除

 

という動作となります。

 

上記4)が完了するまで、新しいFolderのDBはDBの初期化が行われていない状態で、DBにAccessすることはできません。

 

処理の統一化が行われたのかも知れませんが、この動作の変更での違いは、移動元DBのReplica設定で「一時的Replica禁止」の設定が行われていた場合となります。

 

V9.0.1 FP10はCompact -cと同じ動きなので全く問題なく動作しますが、V11.0.1 FP2では、上記3)の段階でReplicaが開始されますが、Replicaが行えず、AdminPのProcessが上記4)の段階で止まったままとなります。

 

Explorerで移動先のFolderを見ていれば、初期状態のファイル容量のまま、増加して行かないことが確認できます。

 

動作の違いはマニュアルなどに記載は見つかっていませんが、ご注意ください。

 

 

V11.0.1 FP2に上げてからLock ManagerのLong Held Lockが頻発?

V9.0.1 FP10からV11.0.1 FP2に上げてから、Lock ManagerのLong Held Lockが頻発するようになった気がします。

 

Server起動後から発生していますので、何らかのServer Codeの変更が影響していると見ています。

 

Transaction Loggingを有効にしているServerで頻発するようですので、Transaction Log関係ではないかと思われます。

極稀に発生するServer無応答障害

関係している会社ではV9.0.1FP10にHFを当てた状態で利用しているのですが、極稀にServerが全く応答しない時間が5-15分程度発生するという障害が発生しています。

 

Port監視しているシステムからの通知で、DominoがDownしているように見えると言う状態です。

 

パターンとしては、以下の2パターンが確認できています。

 

1) Domino自体がDownしているように見える

 

この場合は、監視システムからDevice Down/HTTP Downが報告されてきますが、Console Logを見ても一切Restartされた形跡はなく、かつ、この障害が発生している間はConsole Logに一切書き込みがなく、Dominoが完全停止しているように見えるというものです。

 

2) HTTPサービスがDownしているように見える

 

この場合は、監視システムからHTTP Downのみ報告され、Console Logには障害時間内もRouterの配信Logが記録されており、Domino Server自体は動作していると思われるというものですが、HTTPのAccess Logを見ると、障害が発生している間は一切Logが書かれておらず、かつ、SemaphorTimeoutが数多く発生していると言うものです。

 

どちらの障害も一定時間のみ発生し、その後自然復旧してしまうため、障害解析が極めて困難な状態です(障害解析を行うには、障害が発生している時にNSDを取得することが必要です)。

 

HCLに問い合わせても、「障害発生時にNSDを取得してください」と言われるだけで、それ以上踏み込んだNSD取得方法などのガイドは行ってもらえません。

この状態だと、発生頻度が極めて低い障害の場合、NSDが取得できず解析も行えず、お蔵入りしてしまうというのが世の常です。

 

1)の障害は、Console LogやSEMDEBUGも書き込まれていない状態が確認できている為、解析情報を取得するのは極めて困難と思われますが、2)の障害はSEMSEBUGが書き込まれている為、Programによる検知が可能です。

 

Semaphore Timetoutは通常でも起こる可能性があり、これ自体が起こったからと言って、障害に繋がるとは限りませんが、2)の障害が発生する場合には、短時間に大量のSemaphore Timeoutが起こることが特徴です。

 

こういう場合、Dominoが自動的にNSDを取得してくれれば助かるのですが、残念ながら現在のVersionではそのような処理は行われません。

 

そういうことから、以下のようなCodeで一定間隔に規定以上のSemaphore Timeoutが発生した場合に限り、NSDを取得するようなProgramで監視することが考えられます。

つまり、以下のSample Codeの場合は、300秒(5分)の間に一定数(以下の場合20個)のSemaphore Timeoutが確認された場合にはNSDを取得するというものです。

 

@echo off
setlocal enabledelayedexpansion
cls
SET DomProgDIR=D:\Lotus\Domino\
SET DomTechDIR=E:\Lotus\Domino\data\IBM_TECHNICAL_SUPPORT\
SET SCRIPTDIR=D:\admincmd\debug\
SET MaxLineCnt=20
SET PreLineCnt=0
SET CurLineCnt=0
del %SCRIPTDIR%log.txt
cd /d %DomTechDIR%
:Loop
IF !PreLineCnt!==0  (
for /f "usebackq" %%A in (`type semdebug.txt ^| find /c /v ""`) do (
 set PreLineCnt=%%A
 set CurLineCnt=%%A
)
) ELSE (
for /f "usebackq" %%A in (`type semdebug.txt ^| find /c /v ""`) do set CurLineCnt=%%A
)
SET /a Diff=!CurLineCnt!-!PreLineCnt!>nul
If !Diff! gtr %MaxLineCnt% (
ECHO %date% %time% SEMDEBUG Line Count : !CurLineCnt! >> %SCRIPTDIR%log.txt
ECHO %date% %time% Execute nsd due to many semaphore timeout >> %SCRIPTDIR%log.txt
cd /d %DomProgDir%
NSD >> %SCRIPTDIR%log.txt
) ELSE (
ECHO %date% %time% SEMDEBUG Line Count : !CurLineCnt! >> %SCRIPTDIR%log.txt
SET PreLineCnt=!CurLineCnt!
cscript "%SCRIPTDIR%sleep300.vbs" //B
Goto Loop
)

 

このScriptをWindowsのTask SchedulerでServer起動時のScriptとして実行すれば、NSDを自動取得することが可能となります。

 

最初はNSD取得部分はコメントアウトして、SEMDEBUGのLine数の増加を把握した上で、環境に応じてMaxLineCntを調整頂くと良いと思います。

その調整期間が面倒と言う場合は、過去のSEMDEBUGをダウンロードしてLNDを使って時間を変換して(SEMDEBUG.txtは通常の状態でEditorで見ても発生日時が分かりません)発生頻度の把握をしてください。

 

 

 

1 | 2 | 3 | 4 | 5 | 最初次のページへ >>