トラブルシューティング集 - ソフトウェア

Interstage Shunsaku Data Manager
トラブルシューティング集
Windows/Solaris/Linux
J2X1-3651-03Z0(01)
2008年6月
まえがき
本書の目的
本書は、Interstage Shunsaku Data Manager（以降、Shunsakuと略します）におけるトラブルを迅速に解決することを目的と
しています。
本書は、Shunsakuにおけるトラブルへの対処方法、トラブル事例およびQA（よくある質問と回答）について説明していま
す。また、詳細な調査を行う場合に必要となる調査資料の採取方法についても説明しています。
本書の読者
本書は、以下の読者を対象としています。
・ Shunsakuを利用して、システムを設計する人
・ Shunsakuを利用して、アプリケーションを開発する人
・ Shunsakuを利用して、システムを構築する人
・ Shunsakuで構築した業務システムを運用管理する人
前提知識
本書を読む場合、以下の知識が必要です。
・ Shunsakuの機能や構成に関する知識
・オペレーティングシステムに関する知識
・ XMLに関する知識
・フェイルオーバに関する知識
本書の構成
本書は、以下により構成されています。
第1章トラブル対処の概要
Shunsakuのトラブルの対処方法について説明しています。
第2章トラブル対処の事例
利用者自身で解決できる、事象と対処方法（トラブル対処の事例）を説明しています。
第3章調査資料の採取
利用者自身で解決できず、当社へ調査依頼する場合に必要な、調査資料の種類と採取方法について説明しています。
付録A QA集
Shunsakuの利用における、よくある質問とその回答について説明しています。
出版年月および版数
平成19年 6月初版
平成19年 8月第2版
平成20年 6月第3版
-i-
変更履歴
追加・変更内容
ポート番号の表示例を変更しました。
(例：33101→23101)
変更箇所
1.6.2
マニュアルコード
J2X1-3651-03Z0(01)
著作権表示
Copyright 2007-2008 FUJITSU LIMITED
- ii -
目　次
第1章トラブル対処の概要.........................................................................................................................................................1
1.1 トラブルの種類.....................................................................................................................................................................................1
1.2 異常の検出と運用への影響...............................................................................................................................................................2
1.3 トラブルの切分けと対処......................................................................................................................................................................2
1.3.1 エラー事象の確認と対処.............................................................................................................................................................2
1.3.2 処理結果異常の確認と対処........................................................................................................................................................3
1.3.3 プロセスダウンの確認と対処........................................................................................................................................................3
1.3.4 ハングアップ状態の確認と対処...................................................................................................................................................4
1.3.5 性能問題の確認と対処................................................................................................................................................................5
1.4 Shunsakuシステムの復旧....................................................................................................................................................................7
1.4.1 異常状態からの復旧手順............................................................................................................................................................7
1.4.2 アプリケーションを配置したサーバがダウンした場合の対処.....................................................................................................8
1.4.3 コマンド実行中にサーバがダウンした場合の対応.....................................................................................................................9
1.4.4 Shunsakuシステムの再構築.......................................................................................................................................................11
1.5 性能問題時の対処............................................................................................................................................................................16
1.5.1 conductorの性能問題.................................................................................................................................................................16
1.5.2 directorの性能問題....................................................................................................................................................................17
1.5.3 searcherの性能問題...................................................................................................................................................................18
1.5.4 sorterの性能問題........................................................................................................................................................................18
1.5.5 アプリケーションの性能問題......................................................................................................................................................19
1.6 フェイルオーバ関連の異常への対処...............................................................................................................................................20
1.6.1 共用ディスク障害時の復旧........................................................................................................................................................20
1.6.2 searcherのフェイルオーバからの復旧.......................................................................................................................................20
1.6.3 縮退からの復旧..........................................................................................................................................................................22
第2章トラブル対処の事例.......................................................................................................................................................23
2.1 事例一覧...........................................................................................................................................................................................23
2.2 開発時の異常....................................................................................................................................................................................24
2.2.1 API利用全般..............................................................................................................................................................................24
2.2.2 検索時の異常.............................................................................................................................................................................25
2.2.3 集計時の異常.............................................................................................................................................................................25
2.2.4 XML変換時の異常....................................................................................................................................................................26
2.3 運用時の異常....................................................................................................................................................................................28
2.3.1 データ登録時の異常..................................................................................................................................................................28
2.3.2 データ更新時の異常..................................................................................................................................................................29
2.3.3 ソート時の異常...........................................................................................................................................................................41
2.3.4 ディスク容量不足への対策........................................................................................................................................................41
2.4 リカバリ時の異常...............................................................................................................................................................................43
2.4.1 ディレクタデータファイルの入出力異常....................................................................................................................................43
2.4.2 バックアップデータが不当.........................................................................................................................................................45
2.4.3 リカバリ手順の誤り......................................................................................................................................................................47
2.4.4 ディレクタデータファイルの容量不足........................................................................................................................................50
2.4.5 オペレーションログファイルの入出力異常................................................................................................................................52
2.4.6 最新のバックアップデータではない..........................................................................................................................................54
2.4.7 更新ログデータが不連続...........................................................................................................................................................56
2.4.8 文字コードの誤り........................................................................................................................................................................57
2.4.9 searcherの異常検出...................................................................................................................................................................59
第3章調査資料の採取............................................................................................................................................................61
3.1 資料の種類........................................................................................................................................................................................61
3.2 必須資料の採取方法........................................................................................................................................................................62
3.2.1 動作環境ファイル.......................................................................................................................................................................62
3.2.2 動作ログファイル........................................................................................................................................................................64
3.2.3 性能ログファイル........................................................................................................................................................................65
3.2.4 システムログ/イベントログ...........................................................................................................................................................67
- iii -
3.2.5 利用者の操作記録.....................................................................................................................................................................67
3.2.6 ダイレクトアクセスキー定義ファイル...........................................................................................................................................68
3.3 事象共通資料の採取方法................................................................................................................................................................68
3.3.1 検索式、リターン式、ソート式.....................................................................................................................................................68
3.3.2 APIスナップのログ......................................................................................................................................................................69
3.3.3 アプリケーションソース...............................................................................................................................................................69
3.3.4 XMLデータ................................................................................................................................................................................70
3.3.5 シェルスクリプトまたはバッチ.....................................................................................................................................................70
3.4 プロセスダウン時の資料採取...........................................................................................................................................................70
3.4.1 プロセスダウンの調査資料........................................................................................................................................................70
3.4.2 ディレクタデータファイル............................................................................................................................................................71
3.4.3 サーチデータファイル................................................................................................................................................................71
3.4.4 オペレーションログファイル........................................................................................................................................................71
3.4.5 ロードモジュール........................................................................................................................................................................72
3.4.6 mapファイル（Windows）.............................................................................................................................................................72
3.4.7 coreスタックトレース....................................................................................................................................................................72
3.4.8 コアファイル................................................................................................................................................................................74
3.5 ハングアップ時の資料採取..............................................................................................................................................................75
3.5.1 ハングアップの調査資料...........................................................................................................................................................75
3.5.2 ロードモジュール........................................................................................................................................................................76
3.5.3 mapファイル（Windows）.............................................................................................................................................................76
3.5.4 プロセスダンプ............................................................................................................................................................................76
3.5.5 プロセス情報...............................................................................................................................................................................77
3.6 性能問題時の資料採取....................................................................................................................................................................78
3.6.1 性能問題の調査資料.................................................................................................................................................................78
3.6.2 性能情報（Solaris）.....................................................................................................................................................................79
3.6.3 性能情報（Linux）.......................................................................................................................................................................81
3.6.4 性能情報（Windows）.................................................................................................................................................................83
付録A QA集............................................................................................................................................................................87
A.1 全般...................................................................................................................................................................................................87
A.1.1 検索条件....................................................................................................................................................................................87
A.1.2 データ更新................................................................................................................................................................................87
A.1.3 文字種の同一視........................................................................................................................................................................88
A.1.4 アプリケーションおよびコマンドの競合関係.............................................................................................................................88
A.1.5 トランザクション制御..................................................................................................................................................................88
A.1.6 アクセス制御..............................................................................................................................................................................88
A.2 設計...................................................................................................................................................................................................89
A.2.1 サーバ／ネットワーク.................................................................................................................................................................89
A.2.2 データ形式................................................................................................................................................................................89
A.2.3 文字コード..................................................................................................................................................................................90
A.2.4 性能見積り.................................................................................................................................................................................90
A.2.5 定量値........................................................................................................................................................................................91
A.3 導入...................................................................................................................................................................................................91
A.3.1 動作環境の設定........................................................................................................................................................................91
A.3.2 インストール・セットアップ..........................................................................................................................................................92
A.4 開発...................................................................................................................................................................................................93
A.4.1 提供API.....................................................................................................................................................................................93
A.4.2 開発環境....................................................................................................................................................................................94
A.4.3 動作環境....................................................................................................................................................................................94
A.4.4 検索結果のデータ.....................................................................................................................................................................94
A.4.5 検索式........................................................................................................................................................................................95
A.4.6 リターン式...................................................................................................................................................................................96
A.4.7 サンプル.....................................................................................................................................................................................96
A.5 運用...................................................................................................................................................................................................96
A.5.1 データ取込み／取出し.............................................................................................................................................................96
A.6 保守...................................................................................................................................................................................................97
- iv -
A.6.1 モニタリング................................................................................................................................................................................97
A.6.2 バックアップ／リカバリ...............................................................................................................................................................97
A.6.3 サーバ構成変更........................................................................................................................................................................98
A.6.4 縮退............................................................................................................................................................................................98
A.7 連携...................................................................................................................................................................................................99
A.7.1 データベース連携.....................................................................................................................................................................99
索引......................................................................................................................................................................................100
-v-
第1章トラブル対処の概要
本章では、Shunsakuのトラブルへの対処方法について説明します。
1.1 トラブルの種類
ここでは、トラブルの事象の種類について説明します。
事象
・エラー
何らかの異常を検出し、エラーメッセージが出力される現象です。
・処理結果異常
処理は正常終了するが、実際の処理内容が不当である現象です。
・ Shunsakuプロセスダウン
Shunsakuのプロセスが処理を継続することができなくなり、異常終了してしまった状態です。エラーメッセージが出力
されます。
・ハングアップ（無応答状態）
何らかの異常や内部矛盾により、想定している時間内で結果が返却されない現象です。単に処理に時間がかかっ
ているだけの性能問題であるかどうか確認する必要があります。
・性能問題
処理は正常に行われるが、想定している時間内で結果が返却されない現象です。
参照
エラーメッセージの出力先には、以下があります。
・システムのログ
・コマンドの応答
・ ShunsakuのAPIの戻り値
その他（フェイルオーバ関連）
フェイルオーバ運用を行っている状態でプロセスダウンが発生した場合、以下の処理が行われます。
・ディレクタサーバのフェイルオーバ運用時
－待機サーバへの切替え
・サーチサーバまたはsearcherのフェイルオーバ運用時
－代替searcherへの切替え
－ searcher接続待ち状態への移行
－縮退
フェイルオーバ運用を行っている場合には、異常が発生しても、運用は問題なく継続されます。ただし、性能面への影響
などを考慮し、速やかに元の状態に復旧することをお勧めします。
-1-
フェイルオーバについての詳細は、“導入・運用ガイド”の“HA機能”を参照してください。
1.2 異常の検出と運用への影響
異常の検出および運用への影響
運用中にShunsakuの各プロセス（conductor、director、sorterおよびsearcher）に異常が発生した場合、異常が発生したプ
ロセスが配置されているサーバ上のシステムログ（syslog）またはイベントログには、Shunsakuの異常発生を通知するメッ
セージが出力されます。
発生した異常によっては、運用を継続できない場合があります。
以下に異常発生時における運用への影響について示します。
メッセージ
コード
運用中アプリケーショ
ンへの影響
原因
運用への影響度
shn06000
u
shn06002
u
conductor異常終了
Shunsakuシステムが復旧するまでShunsakuに
対する接続ができません。
切断
－
shn02003
u
shn02012
u
shn30302
u
director異常終了
directorが復旧するまでShunsakuに対する検
索および更新ができません。
－
取消し
shn02000
e
searcherへの通信処
理で異常発生
自動的に縮退またはフェイルオーバが行わ
れ、終了後、運用を再開することができます。
ただし、縮退した場合には、異常発生前と同
等の性能は発揮できなくなります。
－
取消し
shn07015
u
sorter異常終了
Shunsakuシステムが復旧するまでソートおよ
び集計を行うことができません。
影響なし
影響なし
コネクショトランザク
ン
ション
1.3 トラブルの切分けと対処
ここでは、基本的なトラブルの切分け方法と対処について示します。
1.3.1 エラー事象の確認と対処
エラー事象の場合には、出力メッセージの意味や対処方法を下記のどちらかで確認し、事象を特定します。
・メッセージ集
・ shunprtmsgコマンド
shunprtmsgコマンドの使用例を以下に示します。
メッセージコード“shn22000u”の意味や対処を表示する場合
-2-
shunprtmsg -shn 22000
shn22000u
Director's identifier has not been entered.
［メッセージの意味］
コマンドの入力パラメタとして必要なdirector識別子が未入力です。
［システムの処理］
このコマンドの処理を中止します。
［利用者の処置］
対象となるdirector識別子を指定し、再実行してください。
参照
shunprtmsgコマンドについては、“コマンドリファレンス”を参照してください。
メッセージの意味や対処方法、“第2章トラブル対処の事例”を確認し、必要な処置を行ってください。
メッセージの意味や対処方法、事例で問題が解決しない場合には、調査資料を採取し当社技術員(SE)にお知らせくだ
さい。
資料の採取方法については、“第3章調査資料の採取”を参照してください。
1.3.2 処理結果異常の確認と対処
処理結果異常の場合には、以下のように事象を特定します。
・エラーメッセージが出力されている場合
出力メッセージの意味や対処方法を“メッセージ集”またはshunprtmsgコマンドで確認し、事象を特定します。
・エラーメッセージが出力されていない場合
処理結果のデータなど、メッセージ以外の情報をもとに、事象を特定します。
メッセージの意味や対処方法および“第2章トラブル対処の事例”を確認し、必要な処置を行ってください。
メッセージの意味や対処方法、事例で問題が解決しない場合には、調査資料を採取し当社技術員(SE)にお知らせくだ
さい。
資料の採取方法については、“第3章調査資料の採取”を参照してください。
1.3.3 プロセスダウンの確認と対処
プロセスダウンの可能性がある場合、以下を参照して事象を特定してください。
問題を特定したら、調査資料を採取し当社技術員(SE)にお知らせください。
資料の採取方法については、“第3章調査資料の採取”を参照してください。
Shunsakuのプロセスがダウンしコアファイルが採取されたことを知る手段を時系列に従い以下に説明します。
1. APIまたはコマンドのメッセージコードの確認
-3-
－ APIの場合
Shunsakuを停止していないにもかかわらず、APIのメッセージコードが以下に示すものになった場合、プロセス
ダウンの可能性があります。
- conductor：shn06003u
- director ：shn02013u
- searcher ：shn04005u
- sorter ：shn07016u
－コマンドの場合
Shunsakuを停止していないにもかかわらず、コマンドが出力したメッセージコードが以下に示すものになった
場合、プロセスダウンの可能性があります。
- conductor：shn26023u
- director ：shn22011u、shn22010u、shn30364u（searcher縮退またはsearcherフェイルオーバの可能性）
- searcher ：shn24009u
- sorter ：shn27021u
2. システムログ（イベントログ）の確認
1.のいずれかに該当する場合、以下に示すメッセージコードがシステムログ（イベントログ）に出力されているかどう
かを検索します。
－ conductor：shn06003u
－ director ：shn02013u
－ searcher ：shn04005u
－ sorter ：shn07016u
3. コアファイルの有無確認
2.のメッセージの行末に表示されている識別子に該当する動作環境ファイルを参照します。
動作環境ファイルのCoreFileFolderパラメタに指定しているパス配下に、2.のエラーメッセージで表示されているコ
アファイルが存在するかどうかを確認します。
1.3.4 ハングアップ状態の確認と対処
ハングアップの可能性がある場合、以下を参照して事象を特定してください。
問題を特定したら、調査資料を採取し当社技術員(SE)にお知らせください。
資料の採取方法については、“第3章調査資料の採取”を参照してください。
ハングアップ状態は、単に実行時間が長くなっているだけの状態と見間違える可能性があります。
以下の手順でハングアップ状態になっているかどうか判断してください。
別画面から以下のコマンドを投入し、CPU使用率で判別します。
mpstat
-p
[実行間隔(秒)]
[実行回数]
備考. 実行回数を省略した場合、無限に実行されます。
-4-
例）1秒おきに60回（1分間）採取
mpstat
-p
1
60
出力された情報のうち、“usr”+“sys” の数値に着目し、ある程度時間が経過しても変動がないといった傾向が見られたと
きは、ハングアップ状態であると判断してください。
別画面から以下のコマンドを投入し、CPU使用率で判別します。
mpstat
-P
ALL
[実行間隔(秒)]
[実行回数]
備考. 実行回数を省略した場合、無限に実行されます。
例）1秒おきに60回（1分間）採取
mpstat
-P
ALL
1
60
出力された情報のうち、“%user”+“%system”の数値に着目し、ある程度時間が経過しても変動がないといった傾向が見
られたときは、ハングアップ状態であると判断してください。
タスクマネージャを起動し、「プロセス」タブの“CPU”に着目してください。イメージ名で“shun”の名のつくexeの数値にあ
る程度時間が経過しても変動がないという傾向が見られたときは、ハングアップ状態であると判断してください。
1.3.5 性能問題の確認と対処
性能問題の可能性がある場合、以下を参考にして事象を特定してください。
データの更新または削除を行っている場合、以下について確認します。
・ searcherごとのデータ量の偏り
・ディレクタデータファイルのフラグメンテーション率
上記に当てはまらない場合には、以下を参照して事象を特定してください。
・一般的な確認（プロセスごとの調査）
searcherごとのデータ量の偏り
searcherごとのデータ量に偏りがある場合や、サーチデータファイルのフラグメンテーション率（無駄な領域の割合）が増
加している場合は、検索性能が低下することがあります。
そのため、以下の手順でサーチデータの偏りやフラグメンテーション率を確認し、サーチデータの再配置を行ってくださ
い。
1. shundstateコマンドを実行し、データの偏りやフラグメンテーション率を確認します。
shundstate -s director識別子 -p disk
-5-
2. データの偏りやフラグメンテーション率が高い場合、shundresendコマンドを実行し、サーチデータの再配置を行い
ます。
shundresend -s director識別子
3. shundstateコマンドを実行し、再配置後のデータの偏りやフラグメンテーション率が0%となっていることを確認しま
す。
shundstate -s director識別子 -p disk
詳細は、“導入・運用ガイド”の“サーチデータの再配置”を参照してください。
ディレクタデータファイルのフラグメンテーション率
データの削除または更新を大量に行っている場合、ディレクタデータファイルのフラグメンテーション率（無駄な領域の割
合）が増加し、検索性能が低下することがあります。
そのため、以下の手順でフラグメンテーション率を確認してください。
フラグメンテーション率が高かった場合には、ディレクタデータファイルの最適化を行ってください。
1. shundstateコマンドを実行し、フラグメンテーション率を確認します。
shundstate -s director識別子 -w
2. フラグメンテーション率が高い場合、shundcdsコマンドを実行し、ディレクタデータファイルの最適化を行います。
shundcds -s director識別子
3. shundstateコマンドを実行し、最適化後のフラグメンテーション率が0%となっていることを確認します。
shundstate -s director識別子 -w
詳細は、“導入・運用ガイド”の“ディレクタデータファイルの最適化”を参照してください。
一般的な確認（プロセスごとの調査）
上記に当てはまらない場合、shuncstateコマンドでコネクション情報を採取し、問題箇所の特定と対処を行います。
性能問題への一般的な対処方法については、“1.5 性能問題時の対処”を参照してください。
例）現在のコネクションの状態を表示
shuncstate -s shunc -c
コマンドの詳細については、“コマンドリファレンス”を参照してください。
アプリケーションの処理が完了済みの場合、または詳細な調査が必要な場合には、性能ログで問題箇所を特定します。
性能ログの出力先および内容については、“3.2.3 性能ログファイル”および“導入・運用ガイド”の“性能ログの出力情
報”を参照してください。
-6-
アプリケーション側の問題であった場合、アプリケーション開発元にご相談ください。
コマンドでは原因が特定できない、または、Shunsakuシステムについて、詳細な調査を必要とする場合には、“3.6 性能
問題時の資料採取”に従って資料を採取し、当社技術員(SE)にお知らせください。
1.4 Shunsakuシステムの復旧
Shunsakuのプロセスがダウンした場合の影響と復旧方法を説明します。
1.4.1 異常状態からの復旧手順
Shunsakuで運用を継続できない異常が発生した場合、管理者がShunsakuの異常の原因を取り除いたあと、Shunsakuを
再起動することで、運用を再開することができます。
Shunsakuにおける異常発生から復旧までの流れは、以下の手順となります。
1. 異常原因の対処
異常が発生したサーバ上のシステムログ（syslog）またはイベントログに出力されるShunsakuのメッセージに対する
利用者の対処方法にしたがって、異常となった原因を取り除いてください。
注意
メッセージに対する利用者の処置については、“メッセージ集”を参照してください。
2. Shunsakuの再起動
異常となった原因を取り除いたあと、対象サーバでshunsysstartコマンドを実行して、Shunsakuを再起動します。
-7-
shunsysstart
-n Shunsakuシステム名
Shunsakuを再起動すると自動的に通常運用が再開されます。
3. サーチデータの再配置
searcherに異常が発生していた場合、Shunsakuを再起動すると縮退後の運用から通常運用に自動的に遷移しま
す。ただし、縮退でほかのsearcherに割り振られたサーチデータは縮退前の状態には復旧されません。searcher間
のサーチデータを均等にする場合、shundresendコマンドを実行し、サーチデータの再配置を行います。
shundresend -s
director識別子
注意
サーチデータの再配置を行っている間は、shundimportコマンド、APIによる検索用データの更新はできません。
1.4.2 アプリケーションを配置したサーバがダウンした場合の対処
運用中にアプリケーションを配置するサーバが電源断などでダウンした場合、アプリケーションが確立していたコネクショ
ンは、確立された状態にあり、Shunsakuの資源を占有しています。
そのまま業務を継続すると、最大同時接続数を超えたコネクション確立によるエラー、更新途中のデータへの更新要求
のエラー、メモリ使用量の増加といった事象が発生することがあります。
そのため、業務を継続する前にコネクションを強制切断し、そのコネクションが占有していたShunsaku資源を解放します。
そのあと業務を再開します。
アプリケーションを配置するサーバがダウンしてから復旧までの流れは、以下の手順となります。
-8-
1. コネクション状態の確認
conductorを配置しているサーバにおいてshuncstateコマンドを実行し、ダウンしたアプリケーションを配置するサー
バのコネクションの状態を確認します。
shuncstateコマンドの詳細は、“コマンドリファレンス”または“導入・運用ガイド”の“モニタリング・ロギング”を参照し
てください。
2. コネクションの強制切断
ダウンしたアプリケーションが配置されたサーバ上のアプリケーションのコネクションが存在する場合、conductorを
配置しているサーバでshunctermコマンドを実行し、コネクションを強制切断します。
shuncterm -s conductor識別子 -h ホスト名またはIPアドレス
hオプションには、アプリケーションが動作していたサーバのホスト名またはIPアドレスを指定します。
3. アプリケーションの再起動
アプリケーションを再起動し、業務を再開します。
1.4.3 コマンド実行中にサーバがダウンした場合の対応
director用のコマンドを実行中にサーバがダウンした場合、コマンドの実行結果は正常終了か、異常終了かのどちらかと
なります。
directorが停止している場合、directorを再起動して、以下の手順に従ってコマンドを再度実行するかどうかを決定してく
ださい。
以下に、director用コマンド別の対処方法を説明します。
・ shundbackupコマンド
・ shundcdsコマンド
・ shundclearコマンド
・ shundexportコマンド
・ shundimportコマンド
・ shundrecoverコマンド
・ shundresendコマンド
・ shundrestrictコマンド
shundbackupコマンド
コマンドのオプションによって手順が異なります。
・ bオプション指定によるバックアップ開始宣言を実行中であった場合、shundbackupコマンドのbオプションを再度実行
し、ディレクタデータファイルのバックアップを実施してください。
・ eオプション指定によるバックアップ終了宣言を実行中であった場合、shundbackupコマンドは正常終了しています。
-9-
・ cオプション指定によるバックアップ開始宣言のキャンセルを実行中であった場合、shundbackupコマンドは正常終了
しています。
shundcdsコマンド
shundstateコマンドを実行し、フラグメンテーション率（Fragments）を確認します。
・フラグメンテーション率がshundcdsコマンド実行前から小さくなっている場合、shundcdsコマンドは正常終了しました。
・フラグメンテーション率がshundcdsコマンド実行前から小さくなっていない場合、shundcdsコマンドは異常終了しまし
た。
shundcdsコマンドを再度実行してください。
shundclearコマンド
shundstateコマンドを実行し、検索対象となる総レコード件数（Records）を確認します。
・レコード件数が0件の場合、shundclearコマンドは正常終了しました。
・レコード件数が0件になっていない場合、shundclearコマンドは異常終了しました。shundclearコマンドを再度実行して
ください。
shundexportコマンド
コマンドのオプションによって手順が異なります。
・ oオプション指定による外部ファイルへの抽出を実行中の場合、出力ファイルを削除し、shundexportコマンドを再度
実行してください。
・ dオプション指定による、データ削除処理中の場合、shundstateコマンドを実行し、検索対象となる総レコード件数
（Records）を確認します。
－ directorのレコード件数がshundexportコマンド実行前から減少している場合、shundexportコマンドは正常終了し
ています。
－ directorのレコード件数がshundexportコマンド実行前と同じ場合、shundexportコマンドは異常終了しています。
shundexportコマンドを再度実行して、データの削除を行ってください。
shundexportコマンドの前に、shundrestrictコマンドで更新抑止または検索更新抑止をしていた場合は、shundrestrictコマ
ンドから再度実行してください。詳細は、“shundrestrictコマンド”を参照してください。
shundimportコマンド
shundstateコマンドを実行し、検索対象となる総レコード件数（Records）を確認します。
・レコード件数がshundimportコマンド実行前から変更されている場合、shundimportコマンドは正常終了しました。
・レコード件数がshundimportコマンド実行前から変更されていない場合、shundimportコマンドは異常終了しました。
shundimportコマンドを再度実行してください。
shundrecoverコマンド
コマンドのオプションによって手順が異なります。
・ bオプション指定によるリカバリ開始宣言を実行中であった場合、shundrecoverコマンドのbオプションを再度実行し、
ディレクタデータファイルのリカバリを実施してください。
・ eオプション指定によるリカバリ終了宣言を実行中であった場合、shundrecoverコマンドのbオプションから再度実行
し、ディレクタデータファイルのリカバリを実施してください。
- 10 -
・ cオプション指定によるリカバリ開始宣言のキャンセルを実行中であった場合、shundrecoverコマンドは正常終了して
います。
・ lオプション指定によるオペレーションログファイルのリカバリを実行中であった場合、shundrecoverコマンドのlオプショ
ンを再度実行し、オペレーションログファイルのリカバリを実施してください。
shundresendコマンド
shundstateコマンドを実行し、directorに接続されているsearcherの情報を確認します。
・ searcherの検索対象となるデータ量（DataSize）が均等に配置されている場合、shundresendコマンドは正常終了しま
した。
・ searcherの検索対象となるデータ量（DataSize）が均等に配置されていない場合、shundresendコマンドは異常終了し
ました。
shundresendコマンドを再度実行してください。
shundrestrictコマンド
コマンドのオプションによって手順が異なります。
・ awオプション指定による更新抑止の設定を実行中であった場合、shundrestrictコマンドのawオプションを再度実行し
てください。
・ arwオプション指定による検索更新抑止の設定を実行中であった場合、shundrestrictコマンドのarwオプションを再度
実行してください。
・ rオプション指定による抑止の解除を実行中であった場合、directorの再起動によって抑止は解除されるため、再度
実行は必要ありません。
1.4.4 Shunsakuシステムの再構築
OS障害またはディスク障害などが発生し、インストール後の環境が破壊された場合、Shunsakuシステムのバックアップデータ
（注）を元にShunsakuシステム（ディレクタサーバ、サーチサーバまたはソートサーバ）を再構築することができます。
通常の対処で問題が解決しない場合には、バックアップデータを元にShunsakuシステムを再構築してください。
注）バックアップデータ
・動作環境ファイル
・ディレクタデータファイル
・ダイレクトアクセスキー定義ファイル
バックアップデータを元にしたShunsakuシステムの再構築は、以下の手順で行います。
・ディレクタサーバの再構築
・サーチサーバまたはソートサーバの再構築
ディレクタサーバの再構築
ディレクタサーバの再構築は、以下の手順で行います。
- 11 -
1.Shunsakuのインストール
カスタムインストールを使用して、ディレクタサーバのインストールを行います。必要な機能をすべて選択してくださ
い。
conductorを配置するディレクタサーバの場合、インストールする機能の選択で「conductor」機能も選択してください。
参照
ディレクタサーバのインストールについては、“インストールガイド”の“ディレクタサーバ増設時のインストールおよび
セットアップ”の“Shunsakuのインストール”を参照してください。
2.動作環境の各種定義ファイルのリカバリ
動作環境ファイルおよびダイレクトアクセスキー定義ファイルのリカバリを行います。
参照
動作環境ファイルおよびダイレクトアクセスキー定義ファイルのリカバリについては、“導入・運用ガイド”の“Shunsaku
の動作環境ファイルのバックアップおよびリカバリ”を参照してください。
3.セットアップ
ディレクタサーバのセットアップを行います。
ポート番号の定義
システム用動作環境ファイルのDirectorパラメタに指定されているポート番号を“services”ファイルに指定します。
[Directorパラメタの項目]
- searcherへの検索要求を発行するポート番号
- searcherへの更新要求を発行するポート番号
- 要求受付ポート番号
[指定先]
- Solaris/Linuxの場合
/etc/services
- Windowsの場合
Windowsのインストール先のフォルダ\system32\drivers\etc\services
また、以下の指定を“services”ファイルに行います。
- conductorが配置されたディレクタサーバの場合
システム用動作環境ファイルのConductorパラメタに指定されている「要求受付ポート番号」を指定します。
- searcherが配置されたディレクタサーバの場合
システム用動作環境ファイルのSearcherパラメタに指定されている「directorからの要求を受け付けるポート番
号」を指定します。
- 12 -
- sorterが配置されたディレクタサーバの場合
システム用動作環境ファイルのSorterパラメタに指定されている「conductorからのソート要求を受け付けるポー
ト番号」を指定します。
参照
ポート番号の定義の詳細については、“インストールガイド”の“director用ポート番号の定義”、“searcher用ポート
番号の定義”、“sorter用ポート番号の定義”および“システム用動作環境ファイルの作成”を参照してください。
サービス登録
Shunsakuの各プロセスをサービスに登録します。
conductor
shuncserviceコマンドを実行し、conductorをサービスに登録します。
shuncservice -s conductor識別子 -n Shunsakuシステム名 -a
director
shundserviceコマンドを実行し、directorをサービスに登録します。
shundservice -s director識別子 -n Shunsakuシステム名 -a
searcher
shunsserviceコマンドを実行し、searcherをサービスに登録します。
shunsservice -s searcher識別子 -n Shunsakuシステム名 -a
sorter
shunoserviceコマンドを実行し、sorterをサービスに登録します。
shunoservice -s sorter識別子 -n Shunsakuシステム名 -a
ホスト名の登録
システム用動作環境ファイルで、外部にあるサーバをIPアドレスを用いずにホスト名を指定している場合は、以下
のファイルに外部にあるサーバのIPアドレスおよびホスト名を指定します。
- Solaris/Linuxの場合
/etc/hosts
- Windowsの場合
Windowsのインストール先のフォルダ\system32\drivers\etc\hosts
- 13 -
参考
ホスト名の登録の指定形式については、“インストールガイド”の“ホスト名の登録”を参照してください。
OSの設定
OSの設定を行います。
参照
OSの設定については、“インストールガイド”の、ディレクタサーバの“OSの設定”を参照してください。
4.ディレクタデータファイルおよびオペレーションログファイルのリカバリ
ディレクタデータファイルおよびオペレーションログファイルが破壊されている場合、リカバリを行ってください。
注意
－ディレクタデータファイルおよびオペレーションログファイルのリカバリを行う場合、Shunsakuを起動しておく必要
があります。
－ディレクタデータファイルおよびオペレーションログファイルが配置されるディレクトリが存在しない場合は、Shunsaku
の起動前に再作成してください。
参照
ディレクタデータファイルおよびオペレーションログファイルのリカバリについては、“導入・運用ガイド”の“バックアッ
プ・リカバリ”を参照してください。
5.管理サーバGUI機能の追加
管理コンソールを利用する場合、管理サーバGUI機能を追加します。
なお、管理コンソールは、単一サーバで運用するシステムの場合にだけ利用できます。
参照
管理サーバGUI機能の追加については、“インストールガイド”の“管理サーバGUI機能のインストールおよびセット
アップ”を参照してください。
注意
管理コンソール起動後に、以下を再度設定してください。
－動作環境ファイルのバックアップ先
－ directorのバックアップディレクトリ名
- 14 -
サーチサーバまたはソートサーバの再構築
サーチサーバまたはソートサーバの再構築は、以下の手順で行います。
1.Shunsakuのインストール
サーチサーバまたはソートサーバのインストールを行います。
参照
サーチサーバの場合には、“インストールガイド”の“サーチサーバでのShunsakuのインストール”を参照してくださ
い。
ソートサーバの場合には、“インストールガイド”の“ソートサーバ増設時のインストールおよびセットアップ”の“Shunsaku
のインストール” を参照してください。
2.動作環境ファイルのリカバリ
サーチサーバまたはソートサーバの動作環境ファイルのリカバリを行います。
参照
動作環境ファイルのリカバリの詳細は、“導入・運用ガイド”の“Shunsakuの動作環境ファイルのバックアップおよびリカ
バリ”を参照してください。
3.セットアップ
サーチサーバまたはソートサーバのセットアップを行います。
ポート番号の定義
システム用動作環境ファイルのSearcherパラメタまたはSorterパラメタに指定されているポート番号を“services”ファ
イルに指定します。
[Searcherパラメタ（サーチサーバの場合）]
- directorからの要求を受け付けるポート番号
[Sorterパラメタ（ソートサーバの場合）]
- conductorからのソート要求を受け付けるポート番号
[指定先]
- Solaris/Linuxの場合
/etc/services
- Windowsの場合
Windowsのインストール先のフォルダ\system32\drivers\etc\services
- 15 -
参照
ポート番号の定義の詳細は、“インストールガイド”の“searcher用ポート番号の定義”または“sorter用ポート番号の
定義”を参照してください。
サービス登録
searcherおよびsorterをサービスに登録します。
[サーチサーバの場合]
shunsserviceコマンドを実行し、searcherをサービスに登録します。
shunsservice -s searcher識別子 -n Shunsakuシステム名 -a
[ソートサーバの場合]
shunoserviceコマンドを実行し、sorterをサービスに登録します。
shunoservice -s sorter識別子 -n Shunsakuシステム名 -a
ホスト名の登録
システム用動作環境ファイルで、ディレクタサーバが、IPアドレスを用いずにホスト名を指定している場合は、以下
のファイルにディレクタサーバのIPアドレスおよびホスト名を指定します。
- Solaris/Linuxの場合
/etc/hosts
- Windowsの場合
Windowsのインストール先のフォルダ\system32\drivers\etc\hosts
OSの設定
サーチサーバまたはソートサーバのOSの設定を行います。
参照
OSの設定については、“インストールガイド”の、各サーバの“OSの設定”を参照してください。
1.5 性能問題時の対処
Shunsakuで性能問題が発生した場合の対処方法を説明します。
1.5.1 conductorの性能問題
conductorの性能問題が発生した場合の対処を以下に示します。
- 16 -
1.5.2 directorの性能問題
directorの性能問題が発生した場合の対処を以下に示します。
- 17 -
1.5.3 searcherの性能問題
searcherの性能問題が発生した場合の対処を以下に示します。
1.5.4 sorterの性能問題
sorterの性能問題が発生した場合の対処を以下に示します。
- 18 -
1.5.5 アプリケーションの性能問題
アプリケーションの性能問題が発生した場合の対処を以下に示します。
- 19 -
1.6 フェイルオーバ関連の異常への対処
Shunsakuのフェイルオーバ関連の異常についての復旧方法を説明します。
1.6.1 共用ディスク障害時の復旧
ディレクタサーバのフェイルオーバ機能の利用中に、運用サーバと待機サーバで共通に使用する共用ディスクが故障し
た場合、クラスタシステムは故障を検知し、クラスタグループ（クラスタアプリケーション）のフェイルオーバが発生します。
この場合、ハードウェアの交換など、故障したリソースの原因を取り除き、再度、クラスタグループ（クラスタアプリケーショ
ン）を起動することで、業務を再開することができます。
ディレクタデータファイルおよびオペレーションログファイルを配置した共用ディスクが故障した場合、故障したリソースの
復旧後に、データの復旧が必要となります。
復旧手順の詳細は、利用しているクラスタシステムにより異なります。
“導入・運用ガイド”の“共用ディスク破壊時のリカバリ手順”に従って復旧してください。
参照
ディレクタサーバのフェイルオーバの詳細については、“導入・運用ガイド”の“HA機能”を参照してください。
1.6.2 searcherのフェイルオーバからの復旧
searcherのフェイルオーバの復旧手順について、以下に示します。
・代替searcher切替え時の復旧
・ searcher接続待ち状態からの復旧
参照
searcherのフェイルオーバの詳細については、“導入・運用ガイド”の“HA機能”を参照してください。
代替searcher切替え時の復旧
searcherのフェイルオーバが発生すると、ディレクタサーバのイベントログまたはシステムログ（syslog）に、以下のメッセー
ジが出力されます。
shn01903i: Searcher connection was broken. (192.168.10.1,23501)
(director) [shund1] Shunsaku System Name=shunsaku
shn01904i: Switching to alternative searcher. (director) [shund1]
Shunsaku System Name=shunsaku
shn01110i: Connected to searcher. (192.168.10.20,23501) (director)
[shund1] Shunsaku System Name=shunsaku
- 20 -
復旧手順
異常が発生したsearcherとフェイルオーバにより稼働中の代替searcherを元の構成に戻す場合には、異常が発生したsearcher
の復旧後に以下の手順で行います。
1. 復旧が完了したsearcherを配置したサーバでshunsysstartコマンドを実行し、searcherを起動します。
shunsysstart
-n
Shunsakuシステム名
復旧が完了したsearcherを起動すると、稼働中の代替searcher内のサーチデータが復旧が完了したsearcherに自
動的に再配信されます。
再配信が完了すると、稼働中の代替searcherは、代替待機状態となり、ほかのsearcher異常に備えます。
稼働中の代替searcherからの自動再配信中は、以下の操作が実行できません。
－アプリケーションによる更新操作
－ shundbackupコマンド
－ shundcdsコマンド
－ shundclearコマンド
－ shundexportコマンド
－ shundimportコマンド
－ shundrecoverコマンド
－ shundresendコマンド
－ shundrestrictコマンド
－ shunsyscfgeditコマンド
－ shunsysstopコマンド
以上により、システムが元の構成に戻り、フェイルオーバ運用が再開されます。
searcher接続待ち状態からの復旧
縮退可能なsearcher数（DegradableSearcherCntパラメタ）を指定した運用で、指定値を超える数のsearcher（注）で異常が
発生した場合、ディレクタサーバのシステムログ（syslog）またはイベントログに、以下のメッセージが出力され、searcher接
続待ちの状態に移行します。
注）代替searcherへ切り替わった数は、異常searcher数には含まれません。
shn01906w: Searchers to operate are insufficient. Number of searchers
=18 (director) [shund1] Shunsaku System Name=shunsaku
復旧手順
1. shundstateコマンドを実行し、directorの稼動状況(State)が“WAITING”であることを確認します。
shundstate -s director識別子
- 21 -
2. shundstateコマンドにpオプションを指定し、searcherの稼動状況(State)が“INACTIVE”のsearcherを確認します。
その際、使用しているsearcherと代替searcherの一覧情報を用意しておくと、確認が容易になります。
shundstate -s director識別子 -p
3. 2.で確認した稼動状態が“INACTIVE”の全searcherについて、異常を取り除いたあと、searcherを配置したサーチ
サーバでshunsysstartコマンドを実行し、searcherを起動します。
shunsysstart -n Shunsakuシステム名
4. 異常が発生したすべてのディレクタサーバでshundstateコマンドを実行し、directorの稼動状況(State)が“ACTIVE”
になるまで待ちます。
縮退が発生していた場合には、引き続き縮退からの復旧作業を行います。
詳細は、“1.4.1 異常状態からの復旧手順”を参照してください。
1.6.3 縮退からの復旧
サーチサーバに異常が発生した場合、縮退により、最小限の時間で自動的に運用が継続されます。ただし、正常なsearcher
へ割り振られるサーチデータの量が増加するため、縮退前と同等の性能は期待できなくなります。
性能上問題となるような場合には、異常となった原因を取り除いたあと、システムを再起動してください。システムを再起
動すると縮退後の運用から通常運用に自動的に遷移します。ただし、縮退で他のsearcherに配布されたサーチデータは
縮退前の状態には復旧されないため、データの再配置を行ってください。
詳細は、“1.4.1 異常状態からの復旧手順”を参照してください。
サーチデータの再配置を行っている間は、データ更新はできません。
- 22 -
第2章トラブル対処の事例
本章では、Shunsakuのトラブル対処の事例（事象と対処方法）について説明します。
2.1 事例一覧
Shunsakuの利用における異常の事例（事象と対処方法）一覧を以下に示します。
開発時の異常
メッセージ
コード
概要
詳細
java.lang.
Unsatisfie
dLinkErro
r
API利用全般
API利用時の異常の全般
（なし）
検索時の異常
検索結果の異常（文字ばけ）
（なし）
集計時の異常
集計結果の異常
CC0514
CSV形式データのXML変換時の異常
XML変換時の異常
XCC0600
Symfowareとの連携時のXML変換異常
運用時の異常
メッセージ
コード
（なし）
shn30306
u
概要
データ登録時の異常
大量件数データのXML変換時の性能問題
ディレクタデータファイルの入出力異常
データ更新時の異常（注1）
shn30307
u
shn30410e
詳細
データ更新時の異常(注2)
オペレーションログファイルの入出力異常
サーチデータファイルの入出力異常
shn30351
u
ディレクタデータファイルの容量不足
shn30353
u
オペレーションログファイルの容量不足
shn30393
u
レコード件数が最大値に達した
shn30396
u
ディレクタデータファイルのサイズが最大値
に達した
shn30398
u
データ更新時の異常
オペレーションログファイルのサイズが最大
値に達した
shn30337
u
サーチデータファイルの容量不足
（なし）
ソート時の異常
大量件数のソート処理時の性能問題
（なし）
共用ディスク障害
ディレクタサーバのフェイルオーバ
- 23 -
メッセージ
コード
shn01904i
shn01906
w
概要
searcherのフェイルオーバ
詳細
searcherのフェイルオーバ
注1）“導入・運用ガイド”の“バックアップ・リカバリ”の“リカバリ”を参照してください。
注2)“導入・運用ガイド”の“HA機能”の“サーチデータファイルのリカバリ”を参照してください。
リカバリ時の異常
メッセージ
コード
概要
詳細
shn30318
u
ディレクタデータファイルの入出力異常
shn30328
u
バックアップデータが不当
shn30331
u
リカバリ手順の誤り
shn30332
u
ディレクタデータファイルの容量不足
shn30335
u
リカバリ時の異常
オペレーションログファイルの入出力異常
shn30338
u
最新のバックアップデータではない
shn30341
w
更新ログデータが不連続
shn30355
u
文字コードの誤り
shn30364
u
searcherの異常検出
2.2 開発時の異常
開発時の異常の事例を以下に示します。
2.2.1 API利用全般
java.lang.UnsatisfiedLinkError が発生する。(Java API)
【現象】
ShunsakuのJava APIを利用したアプリケーションを実行すると、java.lang.UnsatisfiedLinkError が発生する。
【確認方法】
以下の条件を満たす場合、本現象が発生していると判断できます。
－ ShunsakuのJava APIを利用したアプリケーションを実行した。
－【現象】に記載のエラーが発生した。
- 24 -
【原因】
ShunsakuのAPI機能をインストールせず、shunapi.jarをコピーしてアプリケーションを実行した場合に発生するエラー
です。
【問題発生時の対処方法】
Shunsakuのインストーラを使用して、アプリケーションの実行環境にShunsakuのAPI機能をインストールしてください。
2.2.2 検索時の異常
検索結果の文字ばけ
【現象】
ShunsakuのJava APIで検索を行い、結果をブラウザで表示すると、“―”として登録した文字が“!)”などに文字ばけす
る。
【確認方法】
～, ∥, －, ￠, ￡, ￢などの文字が文字ばけする場合、本現象が発生していると判断できます。
【原因】
Shunsakuに取り込むXML文書の文字コードにUTF-8を設定し、システム用動作環境ファイルのCharacterCodeパラメタに
EUCを設定している可能性があります。
ShunsakuのJava APIでは、UTF-8からEUCへの文字のコード変換をJavaが提供しているコード変換機能を使用して
行います。
しかし、このコード変換機能では、すべてのUTF-8の文字をEUCの文字に変換することができません。そのため、
ShunsakuのJava APIでデータを取り込んだときに、特定の文字で文字ばけが発生した状態でShunsakuにデータが取
り込まれており、検索したときにも文字ばけした状態で、検索結果が出力されています。
【事前に問題を回避する方法】
Shunsakuに取り込むXML文書の文字コードと、動作環境ファイルのCharacterCodeパラメタで指定する文字コードを
統一してください。
UTF-8を推奨します。
【問題発生時の対処方法】
ありません。
2.2.3 集計時の異常
集計結果の異常
【現象】
集計機能を複数回実行するとJavaの標準提供関数であるreplaceメソッド(StringBufferクラス) が以下の異常動作（注）
をする。
［replace 関数呼出前の文字列］
- 25 -
提案製品名：Internet Navigware Server動作OSとして、以下のLinuxもサ
ポートしてほしい。
・RedHat Enterprise Linux ES
［replace 関数呼出後の文字列］
提案製品名：
Internet NavigNavigNavigNavigNavigNavigNavigNavigNavigNavigNav
igNavigNavigNavigNavig
注）空白をWeb画面に表示するため replaceメソッドを使用して“ ”に置き換える処理を実行したところ
で、“ ”以降の文字が破壊されます。
【確認方法】
Java VMが以下のバージョンの場合、本現象が発生していると判断できます。
－ JDK/JRE1.3.1_03のFJVM 1.3.1
(バージョン表記：build 1.3.1_03_FUJITSU_MODIFIED-B08)
【原因】
富士通製Java VMの既存障害です。
【事前に問題を回避する方法】
以下の方法で回避できます。
1. FJVMを起動する際のオプション（通常はjavaコマンドのオプション）として、以下のオプションを追加指定しま
す。
（サーブレットの場合は、bin.parameterに指定）
-XX:-SpecialArraycopy
2. HotSpot ClientVMまたはHotSpot ServerVMを使用します。
【問題発生時の対処方法】
ありません。
2.2.4 XML変換時の異常
・ XCC0600：CSV形式データのXML変換時の異常
・ CC0514：Symfowareとの連携時のXML変換異常
CSV形式データのXML変換時の異常
【現象】
CSV形式のファイルをサンプルコマンドでXML変換すると、以下のメッセージが出力される。
- 26 -
[出力メッセージ]
[XCC0600:CSVResultsetオブジェクトが生成できませんでした。
詳細:XCV0074 CSVファイルの解析に失敗しました。XXXXX行。
詳細:XCV0063 CSVファイルのデータカラム数がYYYではありません]
【確認方法】
以下の条件を満たす場合、本現象が発生していると判断できます。
－ XML変換機能の入力がCSVファイルである。かつ、
－変換実行時に【現象】に記載のエラーが表示された。
【原因】
入力CSVファイルの項目数が行によって異なっていることが原因です。
【事前に問題を回避する方法】
入力CSVファイルの項目数を統一してください。
【問題発生時の対処方法】
入力CSVファイルの項目数を統一して、再度XML変換を実行してください。
Symfowareとの連携時のXML変換異常
【現象】
サンプルコマンドでXML変換を実行すると、以下のメッセージが出力される。
[出力メッセージ]
% sh shunvrdb2xml.sh -m zmap01.xml -driver com.fujitsu.symfoware.jdbc.SYMDriver
-url "jdbc:symforda://kurage.tohoku.fujitsu.com:2002/VWS;schema=E01" -user agent
-passwd agent.. -o OutFile001 -sql "SELECT * FROM AGL_HEAD"CC0514:ResultSetが取得
できませんでした。
詳細：指定されたメソッドは当ドライバではサポートされていません
【確認方法】
以下の条件を満たす場合、本現象が発生していると判断できます。
－ XML変換機能で、Symfowareとの連携を行っている。かつ、
－【現象】に記載のエラーが発生した。
【原因】
XML変換機能でサポート対象外のバージョン・レベルのSymfowareサーバと接続したためです。
- 27 -
【事前に問題を回避する方法】
Symfoware Serverを以下のバージョンにしてください。
また、以下のバージョンのSymfoware Serverで提供されるJDBCドライバを利用してください。
－ Solaris版：7.0以降
－ Linux版：V7.0L10以降
－ Windows版：V7.0L10以降
Symfoware ServerおよびJDBCドライバのバージョンの詳細については、“インストールガイド”を参照してください。
【問題発生時の対処方法】
ありません。
2.3 運用時の異常
運用時の異常の事例を以下に示します。
2.3.1 データ登録時の異常
大量件数データのXML変換時の異常
【現象】
少量データの場合（たとえば10万件以下）では10数秒で処理が終了するが、大量データ（たとえば100万件以上）の
場合に処理が数時間にわたり処理が終了しない。
【確認方法】
以下の条件を満たす場合、本現象が発生していると判断できます。
－少量データでは正しく変換できる。かつ、
－データ量を増やすと処理が終了しない、または、エラーとなる。
【原因】
メモリ不足です。
マッピングルールファイルに「集約する」指定（parentRuleタグでcontroller属性を指定）している場合、ひとつのXML
文書として出力されるために、メモリ使用量が増加して処理遅延が発生します。
【事前に問題を回避する方法】
以下の方法で回避できます。
1. メモリの増設
2. データサイズの見直し
3. マッピングルールの見直し（集約している場合やめる）
【問題発生時の対処方法】
特に集約の必要がない場合は、parentRuleタグによる集約条件の指定（controller属性）を止めて、再度変換を行って
ください。
- 28 -
2.3.2 データ更新時の異常
・ shn30351u：ディレクタデータファイルの容量不足
・ shn30353u：オペレーションログファイルの容量不足
・ shn30393u：レコード件数が最大値に達した
・ shn30396u：ディレクタデータファイルのサイズが最大値に達した
・ shn30398u：オペレーションログファイルのサイズが最大値に達した
・ shn30337u：サーチデータファイルの容量不足
ディレクタデータファイルの容量不足
【現象】
コマンドまたはアプリケーションを実行すると、以下のメッセージが出力される。
[出力メッセージ]
shn30351u:There is not enough space in the data file folder. [shund1]
ディレクタデータファイルを格納するディスクの空き領域の不足です。
復旧方法は、エラー発生時の操作およびdirector用動作環境ファイルにOperationLogFolderパラメタを設定している
かどうかで異なります。
以降に示す復旧方法から、発生する事象に対応した方法を選択して、復旧を行ってください。
【問題発生時の対処方法】
表2.1 選択可能な復旧方法
エラー発生時の操作
director用動作環境ファイルの
OperationLogFolderの設定
選択可能な
復旧方法(注1)
Shunsaku APIの実
行
shundimportコマンド
shundbackupコマンド
なし
1 (注2)
あり
1 または 2 (注2)
shundcdsコマンド
なし
1 または 3
あり
1～3
注1）復旧方法の内容は、以下のとおりです。
－ [復旧方法1]
Shunsakuシステムを停止して、ディレクタデータファイルの格納先を変更する方法です。
－ [復旧方法2]
shundrecoverコマンドを使用してリカバリする方法です。
Shunsakuシステムを停止せずに復旧したい場合に有効です。
－ [復旧方法3]
Shunsakuシステムを停止して、shundexportコマンドで抽出したファイルをshundimportコマンドで取り込む方法で
す。
フラグメンテーション率が高い場合に有効です。
注2）ShunsakuのAPIの実行によるエラーであっても、フラグメンテーション率が高い場合には、[復旧方法3]での
復旧が有効です。
- 29 -
なお、実際のコマンドの使用法については、“導入・運用ガイド”および、“コマンドリファレンス”を参照してください。
復旧方法1
Shunsakuシステムを停止して、ディレクタデータファイルを容量の大きなディスクに複写し、再起動する方法の手順を
説明します。
1. 状態の確認
shundstateコマンドで、表示項目のDataFileStatusが“FULL”となっていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/05/10 10:09:53
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
10:09:53 ACTIVE
----/--/-- --:--:-100000
FULL
NORMAL
12000
40.0GB
10.0KB
5.020
ReadSize
2
2.00MB
2. Shunsakuシステムの停止
shunsysstopコマンドによりShunsakuシステムを停止します。
shunsysstop -n shunsaku
3. ディレクタデータの複写
director用動作環境ファイルのDataFileFolderパラメタに指定したディレクトリ配下の資材をすべて容量の大きな
ディスクに複写します。
- Solaris/Linuxの場合
cpコマンドなど
cp -rp
/Shunsaku/data
/Shunsaku2/data
- Windowsの場合
xcopyコマンドなど
xcopy /r /e
D:\Shunsaku
E:\Shunsaku
4. DataFileFolderの変更
director用動作環境ファイルのDataFileFolderパラメタに手順3.で複写したディレクトリを指定します。
- Solaris/Linuxの場合
DataFileFolder
/Shunsaku2/data/
- 30 -
- Windowsの場合
DataFileFolder
E:\Shunsaku\
5. Shunsakuシステムの起動
shunsysstartコマンドによりShunsakuシステムを起動します。
shunsysstart
-n
shunsaku
6. 状態の確認
shundstateコマンドで、表示項目のDataFileStatusが“NORMAL”となっていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/05/10 10:14:06
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
10:14:06 ACTIVE
----/--/-- --:--:-100000
NORMAL
NORMAL
12000
40.0GB
10.0KB
5.020
ReadSize
2
2.00MB
上記の手順により復旧され、運用を再開することができます。
復旧方法2
Shunsakuシステムを停止せずに、shundrecoverコマンドによってリカバリを行う方法を説明します。
この方法は、以下の条件にすべて当てはまるときに選択することができます。
《条件》
－ director用動作環境ファイルにOperationLogFolderパラメタを設定している。
－ディレクタデータをバックアップしている。
－ディスクを交換する時にOSの再起動を必要としない。
注意
複数のdirectorで1つの業務を運用している場合、かつ、shundrecoverコマンドによりバックアップ時点または指定した
時点までリカバリを行った場合には、他のすべてのdirectorについてもshundrecoverコマンドにより同じ時点までリカバ
リするようにしてください。
- 31 -
1. 状態の確認
shundstateコマンドで、表示項目のDataFileStatusが“FULL”となっていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/05/10 11:32:14
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
11:32:14 ACTIVE
2006/05/10 11:28:07
100000
FULL
NORMAL
12000
40.0GB
10.0KB
5.020
ReadSize
2
2.00MB
2. リカバリの開始
shundrecoverコマンドのbオプションでリカバリ開始宣言を行います。
shundrecover -s shund1 -b
3. ディスクの交換
ディレクタデータを格納しているディスクを容量の大きなディスクに交換します。
4. ディレクタデータ格納先の作成
交換したディスクにdirector用動作環境ファイルのDataFileFolderパラメタに指定されているディレクトリを作成し
ます。
5. リストア
バックアップしたディレクタデータをリストアします。
OSのコマンドまたはディスク装置によるコピー機能を使用して、ディレクタデータファイルのバックアップデータ
をリストアします。
- Solaris/Linuxの場合
cpコマンドなど
cp -rp /Backup/data/shund1 /Shunsaku/data/shund1
- Windowsの場合
xcopyコマンドなど
xcopy /r /k
E:\Backup\shund1
D:\Shunsaku\shund1
6. リカバリの終了
shundrecoverコマンドの eオプションで最新状態までリカバリを行い、運用を再開します。
shundrecover -s shund1 -e
- 32 -
7. 状態の確認
shundstateコマンドで、表示項目のDataFileStatusが“NORMAL”となっていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/05/10 11:38:22
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
11:38:22 ACTIVE
2006/05/10 11:28:07
100000
NORMAL
NORMAL
12000
40.0GB
10.0KB
5.020
ReadSize
2
2.00MB
上記の手順により復旧され、運用を再開することができます。
復旧方法3
shundexportコマンドで抽出したファイルを、shundimportコマンドで取り込むことで復旧を行う方法を説明します。
1. 状態の確認
shundstateコマンドで、表示項目のDataFileStatusが“FULL”となっていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/05/10 13:21:02
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:21:02 ACTIVE
----/--/-- --:--:-100000
FULL
NORMAL
12000
40.0GB
10.0KB
5.020
ReadSize
50
2.00MB
2. すべてのトランザクションの停止
すべてのアプリケーションを停止し、データの検索および更新が行われないようにしてください。
3. ディレクタデータの抽出
shundexportコマンドで、ディレクタデータをテキストファイルに抽出します。
shundexport -s shund1
-o /shundata/exp_data.txt
- 33 -
4. Shunsakuシステムの停止
shunsysstopコマンドによりShunsakuシステムを停止します。
shunsysstop -n
shunsaku
5. ディレクタデータの削除
director用動作環境ファイルのDataFileFolderパラメタに指定したディレクトリに存在するdirector識別子名のディ
レクトリを削除します。
6. Shunsakuシステムの起動
shunsysstartコマンドによりShunsakuシステムを起動します。
shunsysstart -n shunsaku
7. ディレクタデータの取込み
shundimportコマンドで、3.で抽出したテキストデータを取り込みます。
shundimport -s shund1 -f
/shundata/exp_data.txt
8. 状態の確認
shundstateコマンドで、表示項目のDataFileStatusが“NORMAL”となっていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/05/10 13:25:05
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:25:05 ACTIVE
----/--/-- --:--:-100000
NORMAL
NORMAL
0
40.0GB
10.0KB
0.000
ReadSize
0
0.00MB
上記の手順により復旧され、運用を再開することができます。
注）ディレクタデータを抽出する際に、抽出ファイルを格納するディスクの空き容量が十分あることを事前に確
認してください。
抽出ファイルのサイズ取得（見積り）方法は、“導入・運用ガイド”の“資源の見積り”を参照してください。
【事前に問題を回避する方法】
ディレクタデータファイルの格納先の空き領域が不足した場合、その対処を完了するまでは業務が継続できなくなっ
てしまいます。
このような事態に備えるため、設計および運用において予防措置を行っておく必要があります。
- 34 -
予防措置の詳細は、“2.3.4 ディスク容量不足への対策”の“ディレクタデータファイルへの対策”を参照してください。
オペレーションログファイルの容量不足
【現象】
コマンドまたはアプリケーションを実行すると、以下のメッセージが出力される。
[出力メッセージ]
shn30353u:There is not enough space in the operation log folder. [shund1]
オペレーションログファイルを格納するディスクの空き領域の不足です。
オペレーションログファイルとは、Shunsakuの更新操作を更新ログデータとして蓄積するファイルです。Shunsakuの運
用中に、オペレーションログファイルを格納するディスクの空き領域が不足すると、コマンドおよびアプリケーションが
エラーとなる場合があります。
【問題発生時の対処方法】
ディレクタデータファイルをバックアップします。
これにより、バックアップ以前のオペレーションログファイルが自動的に破棄され、運用を再開することができます。
以下に示す方法で、ディレクタデータファイルをバックアップし、運用を再開させてください。
複数のdirectorで1つの業務を運用している場合は、バックアップした時点を合わせるために、すべてのdirectorでバッ
クアップを実施してください。
1. 状態の確認
shundstateコマンドで、表示項目のOperationLogStatusが“FULL”となっていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/05/10 09:24:47
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
09:24:47 ACTIVE
----/--/-- --:--:-100000
NORMAL
FULL
12000
40.0GB
10.0KB
5.020
ReadSize
2
2.00MB
2. バックアップ開始宣言
shundbackupコマンドのbオプションでバックアップ開始宣言を行います。
shundbackup -s shund1 -b
注）複数のdirectorで1つの業務を運用している場合、すべてのdirectorに対してshundbackupコマンドを実
行してください。
- 35 -
3. ディレクタデータファイルの退避
ディレクタデータファイルをバックアップします。
director用動作環境ファイルのDataFileFolderパラメタに指定したディレクトリ配下にdirector識別子名のディレク
トリがあります。
director識別子名のディレクトリ配下のファイルをすべてバックアップしてください。
バックアップには、以下のOSのコマンドまたはディスク装置によるコピー機能を使用してください。
- Solaris/Linuxの場合
cpコマンドなど
cp -rp /Shunsaku/data/shund1 /Backup/data/shund1
- Windowsの場合
xcopyコマンドなど
xcopy /r /k D:\Shunsaku\shund1 E:\Backup\shund1
4. バックアップ終了宣言
shundbackupコマンドのeオプションで、バックアップ終了宣言を行います。
shundbackup -s shund1 -e
注）複数のdirectorで1つの業務を運用している場合、すべてのdirectorに対してshundbackupコマンドを実
行してください。
5. 状態の確認
shundstateコマンドで、表示項目のOperationLogStatusが“NORMAL”となっていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/05/10 09:33:55
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
09:33:55 ACTIVE
2006/05/10 09:31:50
100000
NORMAL
NORMAL
12000
40.0GB
0.08KB
5.020
ReadSize
2
2.00MB
上記の手順により、表示項目のOperationLogStatus の“FULL”状態が解消され、運用を再開することができま
す。
なお、実際のコマンドの使用法については、“導入・運用ガイド”および“コマンドリファレンス”を参照してくださ
い。
- 36 -
【事前に問題を回避する方法】
オペレーションログファイルの格納先の空き領域が不足した場合、その対処を完了するまでは業務が継続できなく
なってしまいます。
このような事態に備えるため、設計および運用において予防措置を行っておく必要があります。
予防措置の詳細は、“2.3.4 ディスク容量不足への対策”の“オペレーションログファイルへの対策”を参照してくださ
い。
レコード件数が最大値に達した
【現象】
コマンドまたはアプリケーションにより、データの追加をするとシステムログ、および、コマンドまたはアプリケーション
に、以下のメッセージが出力される。
－システムログ
shn30393u The addition processing has been stopped because
the maximum record number will be exceeded if data is added.
add=追加対象件数 remain=格納可能件数 maximum=最大件数
(director) [shund1] Shunsaku System Name=shunsaku
－コマンドまたはアプリケーション
shn30394u The addition processing has been stopped because
the maximum record number will be exceeded if data is added.
add=追加対象件数 remain=格納可能件数 maximum=最大件数
[shund1]
【原因】
shundimportコマンドまたはアプリケーションによる追加処理において、格納されているレコード件数と、追加しようとし
たレコード件数の合計が、最大件数を超えてしまうため、追加処理を中止しました。
この場合、トランザクションはロールバックされます。
【問題発生時の対処方法】
このメッセージが出力された場合、格納可能件数以上のレコードを追加することはできません。
不要なレコードを削除して件数を減らすか、または、directorを増設し、conductor用動作環境ファイルのInsertPointパ
ラメタでデータ格納先directorを変更してください。
ディレクタデータファイルのサイズが最大値に達した
【現象】
shundimportコマンドまたはアプリケーションにより、データの追加、削除または更新をすると、システムログ、および、
コマンドまたはアプリケーションに、以下のメッセージが出力される。
- 37 -
－システムログ
shn30396u The size of the director data file to be used has
reached the maximum.Max file size=最大サイズ(MB) (director)
[shund1] Shunsaku System Name=shunsaku
－コマンドまたはアプリケーション
shn30351u:There is not enough space in the data file folder.
[shund1]
【原因】
shundimportコマンドまたはアプリケーションによる追加、削除または更新処理において、追加、削除または更新処理
を実施した結果、ディレクタデータファイルのサイズが最大サイズを超えてしまうため、追加、削除または更新処理を
中止しました。
この場合、トランザクションはロールバックされます。
また、shundstateコマンドで表示されるDataFileStatusは、“LIMIT”となり、その後のshundimportコマンドおよびアプリ
ケーションからの追加、更新または削除処理はエラーとなります。
【問題発生時の対処方法】
以下のいずれかの操作で復旧してください。
－ shundcdsコマンドが実行できる状況の場合
shundcdsコマンドによるディレクタデータファイルの最適化を行ってください。または、ディレクタデータファイルの
格納先ディスクの容量の増設を行ってください。
－ shundcdsコマンドが実行できない状況の場合
以下のいずれかの操作で復旧してください。
- Shunsakuシステムを停止し、ディレクタデータファイルの格納先を変更
- shundrecoverコマンドを使用したリカバリ操作による復旧
- shundexportコマンドを使用した復旧
復旧方法の詳細は、“ディレクタデータファイルの容量不足”の“【問題発生時の対処方法】”を参照してください。
ポイント
以下のdirectorのコマンドは実行可能です。
・ shundbackupコマンド
・ shundcdsコマンド
・ shundclearコマンド
・ shundexportコマンド
・ shundrecoverコマンド
- 38 -
・ shundresendコマンド
・ shundrestrictコマンド
・ shunsyscfgeditコマンド
・ shunsysstopコマンド
オペレーションログファイルのサイズが最大値に達した
【現象】
shundimportコマンドまたはアプリケーションにより、データの追加、削除または更新をすると、システムログ、および、
コマンドまたはアプリケーションに、以下のメッセージが出力される。
－システムログ
shn30398u The size of the operation log file to be used has
reached the maximum. Max file size=最大サイズ(MB) (director)
[shund] Shunsaku System Name=shunsaku
－コマンドまたはアプリケーション
shn30353u:There is not enough space in the operation log
folder. [shund1]
【原因】
shundimportコマンドまたはアプリケーションによる追加、削除または更新処理において、追加、削除または更新処理
を実施した結果、オペレーションログファイルのサイズが最大サイズを超えてしまうため、追加、削除または更新処理
を中止しました。
この場合、トランザクションはロールバックされます。
また、shundstateコマンドで表示されるOperationLogStatusは、“LIMIT”となり、その後のshundimportコマンドおよびア
プリケーションからの追加、更新または削除処理はエラーとなります。
【問題発生時の対処方法】
shundbackupコマンドによるディレクタデータファイルのバックアップを実施してください。その後、ディレクタデータファ
イルのバックアップ周期について見直しを実施し、オペレーションログファイルのログ量を減らすようにしてください。
復旧方法の詳細は、“オペレーションログファイルの容量不足”の“【問題発生時の対処方法】”を参照してください。
ポイント
以下のdirectorのコマンドは実行可能です。
・ shundbackupコマンド
・ shundcdsコマンド
・ shundclearコマンド
- 39 -
・ shundexportコマンド
・ shundimportコマンド
・ shundrecoverコマンド
・ shundresendコマンド
・ shundrestrictコマンド
・ shunsyscfgeditコマンド
・ shunsysstopコマンド
サーチデータファイルの容量不足
【現象】
コマンドまたはアプリケーションを実行すると、以下のメッセージが出力されます。
－ディレクタサーバのシステムログ
shn30337u There is not enough space in the search data file in
a searcher. searcher=(SchSvr01:shuns01) [shund1]
－サーチサーバのシステムログ
shn30414e There is not enough space in the search data file
folder. (searcher) [shuns01]
－コマンド
shn30337u There is not enough space in the search data file in
a searcher. searcher=(SchSvr01:shuns01) [shund1]
－アプリケーション
shn30415e There is not enough space in the search data file
folder. [shuns01]
サーチデータファイルを格納するディスクの空き領域の不足です。
【問題発生時の対処方法】
異常が発生したsearcherが動作しているサーチサーバのShunsakuシステムを停止してください。
searcher用動作環境ファイルのSearchDataFileFolderパラメタに容量の大きなディスクを指定し直して、Shunsakuシス
テムを再起動してください。
－サーチサーバのフェイルオーバ機能を使用している場合には、“導入・運用ガイド”の“サーチサーバのフェイル
オーバ運用”を参照して、操作してください。
- 40 -
－サーチサーバのフェイルオーバ機能を使用していない場合には、shundresendコマンドによりサーチデータの再
配置を実施してください。
2.3.3 ソート時の異常
大量件数のソート処理時の性能問題
【現象】
conductorのレスポンスタイムが遅くなる。
【確認方法】
以下の条件を満たす場合、本現象が発生していると判断できます。
－ソートを行っている。かつ、
－ソートを指定しない場合のレスポンス件数を調査すると、レスポンス件数が1000件を大きく超える。
【原因】
大量データの検索結果に対するソート処理を行っており、その処理で時間がかかっています。
【事前に問題を回避する方法】
ソートを行う場合は、あらかじめ1000件程度に絞り込めるような検索条件を指定してください。なお、sorterで返却でき
るデータの最大件数は1000件です。
【問題発生時の対処方法】
検索条件式を修正し、再度検索を行ってください。
2.3.4 ディスク容量不足への対策
Shunsakuのディスク資源での容量不足への、事前の対策を以下に示します。
・ディレクタデータファイルへの対策
・オペレーションログファイルへの対策
ディレクタデータファイルへの対策
ディレクタデータファイルの容量不足への事前の対策には、以下があります。
・ディレクタデータファイルの格納先ディスクの設計
設計段階で、ディレクタデータファイルを格納するディスクとして、以下の考慮が必要です。
－ディレクタデータファイルのサイズの見積り
ディレクタデータファイルのサイズの見積りを行います。
－ディレクタデータファイルの最大サイズおよび警戒値の見積り
ディレクタデータファイルのサイズの見積り結果から、ディレクタデータファイルの最大サイズおよび警戒値の見
積りを行います。ディレクタデータファイルの格納先には最大サイズと同じサイズ以上の空き容量を確保してくだ
さい。
- 41 -
－ディレクタデータファイルを格納するディスクの使用用途
ディレクタデータファイルを格納するディスクは、他のファイルを配置せず、専用ディスクとするように設計してくだ
さい。
・運用時における予防措置
検索データの削除や更新処理が大量に発生した場合に、ディレクタデータファイルの中に無駄な領域が増え、検索
性能の劣化につながることがあります。
また、無駄な領域が増えることによる、ディレクタデータファイルの格納先の空き領域が少なくなり、shundcdsコマンド
によるディレクタデータファイルの最適化ができなくなる状態が発生します。
そうならないためにも、以下の措置を行ってください。
－ディレクタデータファイルの最大サイズおよび警戒値の設定
director用動作環境ファイルの以下のパラメタに、ディレクタデータファイルの最大サイズおよび警戒値を設定し
てください。
- 最大サイズ：MaxDataFileSizeパラメタ
最大値を超えた場合、更新処理は行われず、更新処理を含むトランザクションはロールバックされます。
- 警戒値：WarningDataFileSizeパラメタ
警戒値を超えた場合、システムのログに警告メッセージ（shn30395w）が出力されます。
－ディレクタデータファイルの監視と最適化
モニタリング機能（shundstateコマンド）でディレクタデータの総量やフラグメンテーション率を監視し、shundcdsコ
マンドによる定期的なディレクタデータファイルの最適化を実施するように運用設計を行ってください。
詳細は、“導入・運用ガイド”の“director用動作環境ファイルの実行パラメタ”および“モニタリング・ロギング”を参照してく
ださい。
オペレーションログファイルへの対策
オペレーションログファイルの容量不足への事前の対策には、以下があります。
・オペレーションログファイルの格納先ディスクの設計
設計段階で、オペレーションログファイルを格納するディスクとして、以下の考慮が必要です。
－ディレクタデータファイルのバックアップ周期を決定し、オペレーションログファイルに格納される更新ログデータ
のデータ量からディスクの容量を決定します。
更新ログデータのデータ量は、ディレクタデータファイルのバックアップ終了後、次回のバックアップまでにディレ
クタデータファイルに対して行われた更新のデータ量となります。
更新ログデータのデータ量からオペレーションログファイルのサイズの見積りを行い、更新ログデータが十分格
納できるだけの領域を用意してください。
－オペレーションログファイルの最大サイズおよび警戒値の見積り
オペレーションログファイルのサイズの見積り結果から、オペレーションログファイルの最大サイズおよび警戒値
の見積りを行います。オペレーションログファイルの格納先には最大サイズと同じサイズ以上の空き容量を確保
してください。
・運用時における予防措置
以下の措置を行ってください。
- 42 -
－オペレーションログファイルの最大サイズおよび警戒値の設定
director用動作環境ファイルの以下のパラメタで、オペレーションログファイルの最大サイズおよび警戒値を設定
してください。
- 最大サイズ：MaxOperationLogSizeパラメタ
最大値を超えた場合、更新処理は行われず、更新処理を含むトランザクションはロールバックされます。
- 警戒値：WarningOperationLogSizeパラメタ
警戒値を超えた場合、システムのログに警告メッセージ（shn30397w）が出力されます。
－オペレーションログファイルの監視とバックアップ周期の変更
運用後は、オペレーションログファイルを格納しているディスクの空き領域が不足しないように、モニタリング機能
（shundstateコマンド）でオペレーションログファイルの使用中サイズを監視してください。
もし、更新ログデータのデータ量が設計時よりも増加し、ディスクの空き領域が不足した場合は、バックアップ周
期を短くすることでオペレーションログファイルの領域不足の発生を避けることができます。
詳細は、“導入・運用ガイド”の“director用動作環境ファイルの実行パラメタ”および“モニタリング・ロギング”を参照し
てください。
2.4 リカバリ時の異常
リカバリ時の異常の事例を以下に示します。
・ shn30318u：ディレクタデータファイルの入出力異常
・ shn30328u：バックアップデータが不当
・ shn30331u：リカバリ手順の誤り
・ shn30332u：ディレクタデータファイルの容量不足
・ shn30335u：オペレーションログファイルの入出力異常
・ shn30338u：最新のバックアップデータではない
・ shn30341w：更新ログデータが不連続
・ shn30355u：文字コードの誤り
・ shn30364u：searcherの異常検出
2.4.1 ディレクタデータファイルの入出力異常
【現象】
shundrecoverコマンドによるリカバリ処理中に、以下のメッセージが出力されリカバリがエラーとなる。
[出力メッセージ]
shn30318u : An I/O error has occurred with a director data file.errno=
エラー番号 [shund1]
ディレクタデータファイルを配置したディスクに入出力障害が発生しています。
【確認方法】
directorの状態は、“RECOVER”（リカバリ中）のままとなっています。
また、ディレクタデータファイルの状態は、“IOERROR”となっています。
- 43 -
そのため、アプリケーションによる検索および更新はできない状態となっています。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:00:00
Time
State
LastBackedUp
Records
13:00:00 RECOVER
2006/08/31 22:00:00
10000
DataFileStatus
OperationLogStatus
ReadRecords
IOERROR
NORMAL
10000
DataSize
OperationLogSize
ReadTime(sec)
9.67MB
20.8MB
0.829
Fragments(%)
ReadSize
66
9.78MB
【問題発生時の対処方法】
再度、ディスクを交換後、バックアップデータのリストアから実施します。
1. ディレクタデータファイルを配置するディスクを交換します。
ディスクの活性保守ができない場合は、Shunsakuシステムを停止し、ディスク交換後、Shunsakuシステムの再起
動を行います。
2. shundstateコマンドでdirectorの状態およびファイルの状態を確認します。
3. directorの状態が“ACTIVE”の場合、shundrecoverコマンドでリカバリ開始宣言を行います。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30327i:
[shund1]
shun: INFO: shn21002i:
-b
Starting process... [shund1]
Recovery start declaration processing has been completed.
Processing has been completed. [shund1]
4. 再度、ディレクタデータファイルのバックアップデータのリストアを行います。
5. shundrecoverコマンドでリカバリを行います。
以下は、最新状態までのリカバリを例としています。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30334i:
shun: INFO: shn21002i:
-e
Starting process... [shund1]
Recovery end declaration processing is complete. [shund1]
Processing has been completed. [shund1]
6. shundstateコマンドでdirectorの状態が“ACTIVE”、およびディレクタデータファイルの状態が“NORMAL”となっ
ていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:10:00
- 44 -
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:10:00 ACTIVE
2006/08/31 22:00:00
10000
NORMAL
NORMAL
10000
9.67MB
20.8MB
0.829
ReadSize
66
9.78MB
7. shundbackupコマンドでディレクタデータファイルをバックアップします。
8. 運用を再開します。
2.4.2 バックアップデータが不当
【現象】
shundrecoverコマンドによるリカバリ終了宣言時に、以下のメッセージが出力されエラーとなることがある。
[出力メッセージ]
shn30328u : There is an error with the backup data that has been restored. [shund1]
リストアされたディレクタデータファイルは不当です。
【原因】
リストアされたディレクタデータファイルのバックアップデータが誤っています。
ディレクタデータファイルのバックアップデータは以下の種類のファイル群から成り立っています。
これらは、shundbackupコマンドで採取したバックアップデータでなければなりません。一部のファイルが欠如していた
り、または、他の時点で採取したバックアップデータと混在していた場合、shundrecoverコマンドのeオプションによるリ
カバリ終了宣言時にshn30328uのエラーメッセージが出力され、リカバリがエラーとなります。
【問題発生時の対処方法】
正しいバックアップデータをリストアした後、再度、shundrecoverコマンドのeオプションによるリカバリ終了宣言を実行
してください。
1. shundstateコマンドで表示される、directorの稼働状況が“ACTIVE”の場合、リカバリ開始宣言を行います。
（directorの稼働状況が“RECOVER”の場合、不要です。）
- 45 -
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30327i:
[shund1]
shun: INFO: shn21002i:
-b
Starting process... [shund1]
Recovery start declaration processing has been completed.
Processing has been completed. [shund1]
2. 正しいバックアップデータをリストアします。
3. shundrecoverコマンドでリカバリ終了宣言を実行します。
以下は、最新状態までのリカバリを例としています。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30334i:
shun: INFO: shn21002i:
-e
Starting process... [shund1]
Recovery end declaration processing is complete. [shund1]
Processing has been completed. [shund1]
4. shundstateコマンドで表示される、directorの稼働状況が“ACTIVE”であることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:10:00
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:10:00 ACTIVE
2006/08/31 22:00:00
10000
NORMAL
NORMAL
10000
9.67MB
20.8MB
0.829
ReadSize
66
9.78MB
5. shundbackupコマンドでディレクタデータファイルをバックアップします。
6. 運用を再開します。
【注意事項】
shundrecoverコマンドでリカバリを行うことができるのは、shundbackupコマンドで採取したディレクタデータファイルの
バックアップデータのみです。
そのため、Shunsakuシステムを停止した状態でディレクタデータファイルをバックアップした場合は、以下の操作で復
旧してください。
ただし、オペレーションログファイルを使用している場合でも、復旧できる時点は、バックアップした時点のみとなりま
す。
復旧後、ディレクタデータファイルのバックアップを行う場合は、shundbackupコマンドによるバックアップを行うようにし
てください。
Shunsakuシステムを停止した状態でバックアップを採取した場合の復旧方法を以下に示します。
- 46 -
1. Shunsakuシステムを停止します。
shunsysstop -n shunsaku (Shunsakuシステム名)
shn30579i:Stopping Shunsaku system. [shunsaku]
shn30582i:Stopping conductor. [shunsaku]
shn30583i:Stopping sorter. [shunsaku]
shn30584i:Stopping director. [shunsaku]
shn30580i:Shunsaku system has been stopped. [shunsaku]
2. Shunsakuシステムを停止した状態で採取したディレクタデータファイルのバックアップデータをリストアします。
3. Shunsakuシステムを起動します。
shunsystart -n shunsaku (Shunsakuシステム名)
shn30567i:Activating Shunsaku system. [shunsaku]
shn30573i:Activating director. [shunsaku]
shn30572i:Activating sorter. [shunsaku]
shn30571i:Activating conductor. [shunsaku]
4. shundstateコマンドで表示される、directorの稼働状況が“ACTIVE”であることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:10:00
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:10:00 ACTIVE
2006/08/31 22:00:00
10000
NORMAL
NORMAL
10000
9.67MB
20.8MB
0.829
ReadSize
66
9.78MB
5. shundbackupコマンドでディレクタデータファイルをバックアップします。
6. 運用を再開します。
2.4.3 リカバリ手順の誤り
【現象】
shundrecoverコマンドによるリカバリ終了宣言時に、以下のメッセージが出力されリカバリがエラーとなることがある。
[出力メッセージ]
- 47 -
shn30331u : The backup data are not restored in director data folder,
or director data file is invalid. [shund1]
ディレクタデータファイルのバックアップデータがリストアされていない、または、ディレクタデータファイルが無効な状
態です。
【原因】
以下の3つの原因が考えられます。
原因1
shundrecoverコマンドのbオプションによるリカバリ開始宣言とeオプションによるリカバリ終了宣言の間に、バックアッ
プデータがリストアされていません。
以下のように、リカバリ手順において、バックアップデータをリストアする契機が誤っている場合、本エラーメッセー
ジが出力されます。
図2.1 誤ったバックアップデータのリストア例
原因2
shundrecoverコマンドのeオプションによるリカバリ終了宣言がエラーとなった後にバックアップデータをリストアせ
ずに、再度、eオプションによるリカバリ終了宣言が実行されています。
shundrecoverコマンドのeオプションによるリカバリ終了宣言では、ディレクタデータファイルに対して書き込みを行
います。
リカバリ処理中にエラーとなった場合には、ディレクタデータファイルがリカバリ処理途中状態となってしまうため、
再度、バックアップデータのリストアから実行する必要があります。
原因3
リストアしたバックアップデータは、shundbackupコマンドで採取した、バックアップデータではありません。
- 48 -
shundrecoverコマンドでリカバリを行うことができるのは、shundbackupコマンドのbオプションによるバックアップ開
始宣言とeオプションによるバックアップ終了宣言の区間で採取されたバックアップデータのみです。
それ以外の方法で採取されたバックアップデータを使ってリカバリを行おうとすると本エラーメッセージが出力さ
れ、リカバリがエラーとなります。
【問題発生時の対処方法】
以下の手順でリカバリを行ってください。
1. shundstateコマンドで表示されるdirectorの稼働状況が“ACTIVE”の場合、リカバリ開始宣言を行います。
（directorの稼働状況が“RECOVER”の場合は、不要です。）
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30327i:
[shund1]
shun: INFO: shn21002i:
-b
Starting process... [shund1]
Recovery start declaration processing has been completed.
Processing has been completed. [shund1]
2. 再度、ディレクタデータファイルのバックアップデータをリストアします。
shundbackupコマンドの-bと-eの間（バックアップ区間）で採取された正しいバックアップデータをリストアしてくだ
さい。
3. shundrecoverコマンドでリカバリ終了宣言を実行します。
以下は、最新状態までのリカバリを例としています。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30334i:
shun: INFO: shn21002i:
-e
Starting process... [shund1]
Recovery end declaration processing is complete. [shund1]
Processing has been completed. [shund1]
4. shundstateコマンドで表示されるdirectorの稼働状況が“ACTIVE”であることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:10:00
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:10:00 ACTIVE
2006/08/31 22:00:00
10000
NORMAL
NORMAL
10000
9.67MB
20.8MB
0.829
- 49 -
ReadSize
66
9.78MB
5. shundbackupコマンドでディレクタデータファイルをバックアップします。
6. 運用を再開します。
2.4.4 ディレクタデータファイルの容量不足
【現象】
shundrecoverコマンドによるリカバリ処理中に、以下のメッセージが出力されリカバリがエラーとなる。
[出力メッセージ]
shn30332u : There is not enough space in the data file folder. [shund1]
ディレクタデータファイルの領域が不足しています。
【確認方法】
directorの状態は、“RECOVER”（リカバリ中）のままとなっています。
また、ディレクタデータファイルの状態は、リカバリ処理がエラーとなったため、“IOERROR”となっています。
そのため、アプリケーションによる検索、および更新はできない状態となっています。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:00:00
Time
State
LastBackedUp
Records
13:00:00 RECOVER
2006/08/31 22:00:00
10000
DataFileStatus
OperationLogStatus
ReadRecords
IOERROR
NORMAL
10000
DataSize
OperationLogSize
ReadTime(sec)
9.67MB
20.8MB
0.829
Fragments(%)
ReadSize
66
9.78MB
【原因】
shundrecoverコマンドによるリカバリ処理中に、ディレクタデータファイルが配置されたディスクに空き領域がなくなった
ため、エラーメッセージを出力してリカバリ処理を終了しました。
【問題発生時の対処方法】
ディレクタデータファイルを配置するディスクの空き領域を作成するか、または、容量の大きなディスクに交換後、リカ
バリを再度実行します。
1. Shunsakuシステムを停止します。
directorの状態が“RECOVER”であるため、システムを強制停止させます。
shunsysstop
shun: INFO:
shun: INFO:
shun: INFO:
shun: INFO:
shun: INFO:
-n shunsaku -e
shn30802i: Forced stop of Shunsaku system has started. [shunsaku]
shn30582i: Stopping conductor. [shunsaku]
shn30583i: Stopping sorter. [shunsaku]
shn30584i: Stopping director. [shunsaku]
shn30803i: Shunsaku system has been forcibly stopped. [shunsaku]
- 50 -
2. ディレクタデータファイルを配置するディスクの空き領域を作成するか、または、容量の大きなディスクに交換し
ます。
3. Shunsakuシステムを再起動します。
shunsysstart -n shunsaku (Shunsakuシステム名)
shun: INFO: shn30567i: Activating Shunsaku system. [shunsaku]
shun: INFO: shn30573i: Activating director. [shunsaku]
shun: INFO: shn30572i: Activating sorter. [shunsaku]
shun: INFO: shn30571i: Activating conductor. [shunsaku]
4. shundstateコマンドでdirectorの状態およびファイルの状態を確認します。
リカバリがエラーとなっているため、ディレクタデータファイルの状態は“IOERROR”となっています。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:10:00
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:10:00 ACTIVE
2006/08/31 22:00:00
10000
IOERROR
NORMAL
10000
9.67MB
20.8MB
0.829
ReadSize
66
9.78MB
5. shundrecoverコマンドでリカバリ開始宣言を行います。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30327i:
[shund1]
shun: INFO: shn21002i:
-b
Starting process... [shund1]
Recovery start declaration processing has been completed.
Processing has been completed. [shund1]
6. 再度、ディレクタデータファイルのバックアップデータのリストアを行います。
7. shundrecoverコマンドでリカバリを行います。
以下は、最新状態までのリカバリを例としています。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30334i:
shun: INFO: shn21002i:
-e
Starting process... [shund1]
Recovery end declaration processing is complete. [shund1]
Processing has been completed. [shund1]
- 51 -
8. shundstateコマンドでdirectorの状態が“ACTIVE”、およびディレクタデータファイルの状態が“NORMAL”となっ
ていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:20:00
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:20:00 ACTIVE
2006/08/31 22:00:00
10000
NORMAL
NORMAL
10000
ReadSize
9.67MB
20.8MB
0.829
66
9.78MB
9. shundbackupコマンドでディレクタデータファイルをバックアップします。
10. 運用を再開します。
2.4.5 オペレーションログファイルの入出力異常
【現象】
shundrecoverコマンドによるリカバリ処理中に、以下のメッセージが出力されリカバリがエラーとなる。
[出力メッセージ]
shn30335u : An I/O error has occurred with an operation log
file.errno=エラー番号 [shund1]
オペレーションログファイルを配置したディスクに入出力障害が発生しています。
【確認方法】
directorの状態は、“RECOVER”（リカバリ中）のままとなっています。
また、オペレーションログファイルの状態は、“IOERROR”となっています。
そのため、アプリケーションによる検索、および更新はできない状態となっています。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:00:00
Time
State
LastBackedUp
Records
13:00:00 RECOVER
2006/08/31 22:00:00
10000
DataFileStatus
OperationLogStatus
ReadRecords
NORMAL
IOERROR
10000
DataSize
OperationLogSize
ReadTime(sec)
9.67MB
20.8MB
0.829
Fragments(%)
ReadSize
66
9.78MB
【問題発生時の対処方法】
まず、オペレーションログファイルのリカバリを実施してから、ディレクタデータファイルのリカバリを行ってください。た
だし、オペレーションログファイルが壊れたため、バックアップ時点へのリカバリのみ可能となります。
- 52 -
1. オペレーションログファイルを配置するディスクを交換し、オペレーションログファイルのリカバリを行います。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30344i:
shun: INFO: shn21002i:
-l
Starting process... [shund1]
Operation log files have been recovered. [shund1]
Processing has been completed. [shund1]
参考
ディスクの活性保守ができない場合は、Shunsakuシステムを停止し、ディスク交換後、Shunsakuシステムを再起
動する必要があります。
2. shundstateコマンドでdirectorの状態およびファイルの状態を確認します。
3. directorの状態が“NORMAL”の場合、shundrecoverコマンドでリカバリ開始宣言を行います。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30327i:
[shund1]
shun: INFO: shn21002i:
-b
Starting process... [shund1]
Recovery start declaration processing has been completed.
Processing has been completed. [shund1]
4. 再度、ディレクタデータファイルのバックアップデータのリストアを行います。
5. shundrecoverコマンドでバックアップ時点までのリカバリを行います。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30334i:
shun: INFO: shn21002i:
-e -p
Starting process... [shund1]
Recovery end declaration processing is complete. [shund1]
Processing has been completed. [shund1]
6. shundstateコマンドでdirectorの状態が“ACTIVE”、およびオペレーションログファイルの状態が“NORMAL”と
なっていることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:10:00
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:10:00 ACTIVE
2006/08/31 22:00:00
10000
NORMAL
NORMAL
10000
9.67MB
20.8MB
0.829
- 53 -
ReadSize
66
9.78MB
7. shundbackupコマンドでディレクタデータファイルをバックアップします。
8. 運用を再開します。
2.4.6 最新のバックアップデータではない
【現象】
shundrecoverコマンドによるリカバリ終了宣言時に、以下のメッセージが出力されリカバリがエラーとなる。
[出力メッセージ]
shn30338u : There is an error with the backup data that has been restored. [shund1]
リストアされたディレクタデータファイルは、最終バックアップ時刻に採取されたバックアップデータと異なるため、リカ
バリできません。
【原因】
リストアされたディレクタデータファイルのバックアップデータが、shundstateコマンドの“LastBackedUp”で表示される
最終バックアップ時刻に採取されたデータ（最新のバックアップ）ではありません。
そのため、オペレーションログファイルに蓄積された更新ログデータを適用するリカバリ処理（最新状態までのリカバ
リ、または任意の時点までのリカバリ）では、バックアップデータと更新ログデータの整合性がとれていないため、本エ
ラーメッセージを出力してリカバリ処理がエラーとなります。
図2.2 shn30338uのエラーメッセージが出力される例
- 54 -
【問題発生時の対処方法】
最後に採取したバックアップデータをリストアしてから、shundrecoverコマンドのeオプションによるリカバリ終了宣言を
実行してください。
1. shundstateコマンドで表示されるdirectorの稼働状況が“ACTIVE”の場合、リカバリ開始宣言を行います。
（directorの稼働状況が“RECOVER”の場合、不要です。）
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30327i:
[shund1]
shun: INFO: shn21002i:
-b
Starting process... [shund1]
Recovery start declaration processing has been completed.
Processing has been completed. [shund1]
2. 最後に採取したバックアップデータをリストアします。
3. shundrecoverコマンドでリカバリ終了宣言を実行します。
以下は、最新状態までのリカバリを例としています。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30334i:
shun: INFO: shn21002i:
-e
Starting process... [shund1]
Recovery end declaration processing is complete. [shund1]
Processing has been completed. [shund1]
4. shundstateコマンドで表示されるdirectorの稼働状況が“ACTIVE”であることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:10:00
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:10:00 ACTIVE
2006/08/31 22:00:00
10000
NORMAL
NORMAL
10000
9.67MB
20.8MB
0.829
5. shundbackupコマンドでディレクタデータファイルをバックアップします。
6. 運用を再開します。
- 55 -
ReadSize
66
9.78MB
2.4.7 更新ログデータが不連続
【現象】
shundrecoverコマンドによる最新状態までのリカバリ、または、任意の時点までのリカバリ処理中に、以下のメッセージ
が出力されリカバリがエラーとなる。
[出力メッセージ]
shn30341w : Recovery processing has been completed. Recovery point=リ
カバリ時刻 Cause=原因 [shund1]
Causeに示す理由により、表示された時刻までリカバリしました。
【確認方法】
上記【現象】のエラーメッセージが出力されている場合、本現象が発生していると判断できます。
なお、リカバリ処理は、メッセージで表示された時刻までを復旧し、directorの状態を“ACTIVE”にするため、復旧され
ている範囲については、アプリケーションによる検索および更新が可能な状態となります。
【原因】
shundrecoverコマンドによる最新状態までのリカバリ、または、任意の時点までのリカバリ処理中に、更新ログデータの
不連続を検出したため、エラーメッセージを出力してリカバリ処理を終了しました。
Cause（メッセージの出力項目）の理由により、オペレーションログファイルの格納されている更新ログデータが、利用
者が指定した時点までの復旧（最新状態までの復旧、または指定した時点までの復旧）ができない状態となっていま
す。
そのため、Shunsakuシステムは、リカバリ可能な時点まで復旧した場合に本警告メッセージを出力してリカバリを終了
させます。
なお、更新ログデータが適用できない理由（Cause）は、次のとおりです。
Cause
原因
リカバリ時点
shundimport -n
shundimportコマンドのnオプション（更新ロ shundimportコマンドのnオプションを
グデータを採取しない）が実行されている。実行する直前までリカバリすることが
できます。
shundexport -n
shundexportコマンドのnオプション指定に
よるXML文書の削除（削除ログデータを採
取しない）が実行されている。
shundexportコマンドのnオプション指
定によるXML文書の削除を実行す
る直前までリカバリすることができま
す。
shundrecover -p
shundrecoverコマンドのpオプション（時刻
指定、またはバックアップ時点）によるリカ
バリが実行されている。
時刻指定、またはバックアップ時点へ
のリカバリを実行した直前の時点まで
リカバリすることができます。
operation log is
discontinuous
オペレーションログファイルのリカバリを実
行した、または、オペレーションログファイ
ルを採取しない更新を行ったため、更新ロ
グが不連続となっている。
更新ログデータが不連続となった直
前までリカバリすることができます。
- 56 -
【問題発生時の対処方法】
リカバリ処理において、本メッセージが出力された場合、メッセージで表示された時刻以降の時点への復旧はできま
せん。
このような事態にならないように、以下の契機では、必ずディレクタデータファイルのバックアップを行うようにしてくだ
さい。
－ shundimportコマンドのnオプションによるXML文書の取込みまたは削除処理を行った場合
－ shundexportコマンドのnオプションによるXML文書の削除処理を行った場合
－ shundrecoverコマンドのeオプションおよびpオプション指定による、バックアップ時点または任意の時点までのリカ
バリを行った場合
－ shundrecoverコマンドのlオプションによるオペレーションログファイルのリカバリを行った場合
－ director用動作環境ファイルの実行パラメタ“OperationLogFolder”を変更した場合
2.4.8 文字コードの誤り
【現象】
shundrecoverコマンドによるリカバリ終了宣言時に、以下のメッセージが出力されリカバリがエラーとなる。
[出力メッセージ]
shn30355u : The data which is not well-formed XML document exists. [shund1]
整形式でないXML文書が存在します。または、データの文字コードに誤りがあります。
【原因】
以下の文字コードが異なっています。
－システム用動作環境ファイルのCharacterCodeパラメタに設定した文字コード
－ディレクタデータファイルのバックアップデータの文字コード
【問題発生時の対処方法】
システム用動作環境ファイルのCharacterCodeパラメタに設定した文字コードをディレクタデータファイルのバックアッ
プデータの文字コードに変更後、バックアップデータのリストアからリカバリ処理を再実行してください。
1. Shunsakuシステムを停止します。
shunsysstop -n shunsaku (Shunsakuシステム名)
shn30579i:Stopping Shunsaku system. [shunsaku]
shn30582i:Stopping conductor. [shunsaku]
shn30583i:Stopping sorter. [shunsaku]
shn30584i:Stopping director. [shunsaku]
shn30580i:Shunsaku system has been stopped. [shunsaku]
2. システム用動作環境ファイルのCharacterCodeパラメタを正しい文字コードに変更し、全サーバに配布します。
- 57 -
3. Shunsakuシステムを起動します。
shunsystart -n shunsaku (Shunsakuシステム名)
shn30567i:Activating Shunsaku system. [shunsaku]
shn30573i:Activating director. [shunsaku]
shn30572i:Activating sorter. [shunsaku]
shn30571i:Activating conductor. [shunsaku]
4. リカバリ開始宣言を行います。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30327i:
[shund1]
shun: INFO: shn21002i:
-b
Starting process... [shund1]
Recovery start declaration processing has been completed.
Processing has been completed. [shund1]
5. 再度、ディレクタデータファイルのバックアップデータをリストアします。
6. shundrecoverコマンドでリカバリ終了宣言を実行します。
以下は、最新状態までのリカバリを例としています。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30334i:
shun: INFO: shn21002i:
-e
Starting process... [shund1]
Recovery end declaration processing is complete. [shund1]
Processing has been completed. [shund1]
7. shundstateコマンドで表示される、directorの稼働状況が“ACTIVE”であることを確認します。
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:10:00
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:10:00 ACTIVE
2006/08/31 22:00:00
10000
NORMAL
NORMAL
10000
9.67MB
20.8MB
0.829
8. shundbackupコマンドでディレクタデータファイルをバックアップします。
9. 運用を再開します。
- 58 -
ReadSize
66
9.78MB
2.4.9 searcherの異常検出
【現象】
shundrecoverコマンドによるリカバリ終了宣言時に、以下のメッセージが出力されリカバリがエラーとなる。
[出力メッセージ]
shn30364u : The director is not ready to receive requests. [shund1]
directorは受付可能状態ではありません。
【原因】
shundrecoverコマンドのbオプションによるリカバリ開始宣言とeオプションによるリカバリ終了宣言の区間において、
searcherの異常を検出したため、リカバリ処理を継続することができませんでした。
リカバリ処理では、現在使用しているsearcherの情報についても、ディレクタデータファイルに対して書き込みを行い
ます。そのため、リカバリ処理中にsearcherの異常を検出した場合には、ディレクタデータファイルがリカバリ処理途中
状態となってしまうため、再度、バックアップデータのリストアから実行する必要があります。
【問題発生時の対処方法】
searcherを復旧させた後、バックアップデータのリストアからリカバリ処理を再実行してください。
1. 異常となったsearcherを復旧し、searcherを起動します。
2. shundstateコマンドで表示されるdirectorの稼働状況が“ACTIVE”の場合、リカバリ開始宣言を行います。
（directorの稼働状況が“RECOVER”の場合、不要です。）
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30327i:
[shund1]
shun: INFO: shn21002i:
-b
Starting process... [shund1]
Recovery start declaration processing has been completed.
Processing has been completed. [shund1]
3. 再度、ディレクタデータファイルのバックアップデータをリストアします。
4. shundrecoverコマンドでリカバリ終了宣言を実行します。
以下は、最新状態までのリカバリを例としています。
shundrecover -s shund1
shun: INFO: shn21001i:
shun: INFO: shn30334i:
shun: INFO: shn21002i:
-e
Starting process... [shund1]
Recovery end declaration processing is complete. [shund1]
Processing has been completed. [shund1]
5. shundstateコマンドで表示されるdirectorの稼働状況が“ACTIVE”であることを確認します。
- 59 -
shundstate -s shund1
Shunsaku shundstate 2006/09/01 13:10:00
Time
State
Fragments(%)
LastBackedUp
Records
DataFileStatus
DataSize
OperationLogStatus
ReadRecords
OperationLogSize
ReadTime(sec)
13:10:00 ACTIVE
2006/08/31 22:00:00
10000
NORMAL
NORMAL
10000
9.67MB
20.8MB
0.829
6. shundbackupコマンドでディレクタデータファイルをバックアップします。
7. 運用を再開します。
- 60 -
ReadSize
66
9.78MB
第3章調査資料の採取
本章では、利用者自身で解決できず、当社へ調査依頼する場合に必要な、調査資料の種類と採取方法について説明
しています。
3.1 資料の種類
Shunsakuのトラブルの調査に必要な資料の種類と概要を以下に示します。
なお、各事象の発生のトリガーは、以下の2つに大別できます。
・アプリケーション（API）の実行
・コマンドの実行
必須資料
Shunsakuのトラブル調査に必ず必要な資料です。
採取資料
概要
動作環境ファイル
Shunsakuの各プロセスの動作を制御するた
めのファイルです。
動作ログファイル
Shunsakuの各プロセスでの動作履歴を保持
するファイルです。
性能ログファイル
Shunsakuの各プロセスの性能情報を保持す
るファイルです。
システムログ/イベントログ
OSの管轄下にあるロギングファイルです。
OSやアプリケーションが出力する全事象が
出力されます。
利用者の操作記録
実際の操作手順、エラーメッセージなどを把
握するための資料です。
ダイレクトアクセスキー定義ファ
イル
ダイレクトアクセス機能で利用するダイレクト
アクセスキー名を定義するファイルです。こ
のファイルは、ダイレクトアクセス機能を利用
している場合にだけ必要です。
事象共通の資料
発生事象や条件により必要となる資料です。
採取資料
概要
検索式、リターン式、ソート式
ShunsakuのAPIに指定した検索式、リターン
式およびソート式です。
（APIエラー発生時のみ必要）
APIスナップのログ
APIスナップを利用している場合に採取され
るAPIの各種入出力情報です。
（APIエラー発生時のみ必要）
アプリケーションソース
ShunsakuのAPI（Java/.NET/C）を使用して
いるアプリケーションソースです。
XMLデータ
Shunsakuに格納しているXML文書です。
- 61 -
採取資料
概要
シェルスクリプトまたはバッチ
業務で利用しているシェルスクリプトまたは
バッチです。
事象個別の資料
発生事象により個別に必要となる資料です。
事象
プロセスダウン
採取資料
ディレクタデータファイル
サーチデータファイル
オペレーションログファイル
ロードモジュール
mapファイル（Windows）
coreスタックトレース
コアファイル
ハングアップ
ロードモジュール
mapファイル（Windows）
プロセスダンプ
プロセス情報
性能問題
性能情報（CPU使用状況、ネットワーク負荷状況、メモリ使
用状況I/O発生状況）
・性能情報（Solaris）
・性能情報（Linux）
・性能情報（Windows）
操作例の動作OS
本マニュアル内のコマンド操作例は、以下のオペレーティングシステムでの操作例を記載しています。
・日本語Solaris 9 オペレーティングシステム
・ Red Hat Enterprise Linux AS (v.4 for x86)
・ Red Hat Enterprise Linux ES (v.4 for x86)
・ Microsoft(R) Windows Server(R) 2003, Standard Edition
3.2 必須資料の採取方法
Shunsakuのトラブル調査に必ず必要な資料の採取方法を示します。
3.2.1 動作環境ファイル
動作環境ファイルは、Shunsakuにおける各プロセスの動作を制御するためのファイルです。
以下の動作環境ファイルが存在します。
・システム用動作環境ファイル
・ conductor用動作環境ファイル
- 62 -
・ director用動作環境ファイル
・ sorter用動作環境ファイル
・ searcher用動作環境ファイル
・ API用動作環境ファイル
動作環境ファイルは、Shunsakuの構成を把握するうえで必要となる基本的な情報です。
動作環境ファイルの詳細は、“導入・運用ガイド”の“動作環境ファイルの実行パラメタ”を参照してください。
採取方法
以下の動作環境ファイルを採取してください。
各動作環境ファイルは、以下の場所に存在します。
なお、動作環境ファイルの格納先のパスは、「/etc/opt/FJSVshnsk/etc/」までは各動作環境ファイルで共通です。
・システム用動作環境ファイル
/etc/opt/FJSVshnsk/etc/system/Shunsakuシステム名.cfg
・ conductor用動作環境ファイル
/etc/opt/FJSVshnsk/etc/conductor/conductor識別子.cfg
・ director用動作環境ファイル
/etc/opt/FJSVshnsk/etc/director/director識別子.cfg
・ sorter用動作環境ファイル
/etc/opt/FJSVshnsk/etc/sorter/sorter識別子.cfg
採取方法
・ searcher用動作環境ファイル
/etc/opt/FJSVshnsk/etc/sorter/sorter識別子.cfg
採取方法
・ API用動作環境ファイル
/etc/opt/FJSVshnsk/etc/api/api.cfg
各動作環境ファイルは、以下の場所に存在します。
なお、動作環境ファイルの格納先のパスは、「Shunsakuのインストール先のフォルダ\Shunsaku\etc\」までは各動作
環境ファイルで共通です。
・システム用動作環境ファイル
Shunsakuのインストール先のフォルダ\Shunsaku\etc\system\Shunsakuシステム名.cfg
- 63 -
・ conductor用動作環境ファイル
Shunsakuのインストール先のフォルダ\Shunsaku\etc\conductor\conductor識別子.cfg
・ director用動作環境ファイル
Shunsakuのインストール先のフォルダ\Shunsaku\etc\director\director識別子.cfg
・ sorter用動作環境ファイル
Shunsakuのインストール先のフォルダ\Shunsaku\etc\sorter\sorter識別子.cfg
・ searcher用動作環境ファイル
Shunsakuのインストール先のフォルダ\Shunsaku\etc\searcher\searcher識別子.cfg
・ API用動作環境ファイル
Shunsakuのインストール先のフォルダ\Shunsaku\etc\api\api.cfg
3.2.2 動作ログファイル
動作ログは、Shunsakuの各プロセスでの動作履歴を保持するファイルです。
以下の動作ログが存在します。ただし、各動作環境ファイルのLogFileSizeパラメタに0が指定されている場合は採取され
ません。
・ conductor用動作ログファイル
・ director用動作ログファイル
・ sorter用動作ログファイル
・ searcher用動作ログファイル
注意
上記に加え、アプリケーションの各種入出力情報を保持するAPIスナップのログファイルがあります。必要に応じて採取
してください。
採取の詳細については、“3.3 事象共通資料の採取方法”を参照してください。
【searcherが複数存在する場合のsearcher特定方法】
・エラー、プロセスダウン発生時
システムログ／イベントログに出力されているエラーメッセージの文末に表示されているsearcher識別子の動作ログ
ファイルが必要です。
システムログ／イベントログについては、“3.2.4 システムログ/イベントログ”を参照してください。
・性能問題、ハングアップ発生時
アプリケーションの性能劣化・ハングアップの場合は、searcherの特定が困難なため、全searcherの動作ログファイル
が必要です。
- 64 -
searcher用コマンドのハングアップの場合は、コマンドのsオプションに指定したsearcher識別子の動作ログファイルが
必要です。
採取方法
各プロセスの動作環境ファイルのLogFileFolderパラメタに指定したパスに存在するファイルをすべて採取してください。
[格納場所：LogFileFolderパラメタ（省略時）]
－ Solaris/Linuxの場合
LogFileFolder
/var/opt/FJSVshnsk/log/プロセス名/
－ Windowsの場合
LogFileFolder
"C:\Program Files\Interstage Shunsaku\Shunsaku\log\プロセス名\"
備考. プロセス名：“conductor”、“director”、“sorter”または“searcher”
[ファイル形式]
－ LogFileSwitchパラメタを指定していない場合
- プロセス識別子.log
- プロセス識別子_世代番号_old.log（存在する場合のみ採取）
例）directorの場合（プロセス識別子：shund1）
shund1.log
shund1_1_old.log
－ LogFileSwitchパラメタを指定している場合
- プロセス識別子_0_YYYYMMDDhhmm.log
- プロセス識別子_世代番号_old_YYYYMMDDhhmm.log（存在する場合のみ採取）
例）directorの場合（プロセス識別子：shund1）
shund1_0_200510220000.log
shund1_1_old_200510211235.log
備考.プロセス識別子：各プロセスの識別子
世代番号：世代を表す数字
YYYY：年、MM：月、DD：日、hh：時、mm：分
3.2.3 性能ログファイル
Shunsakuの各プロセスの性能情報を保持するファイルです。
以下の性能ログが存在します。ただし、各動作環境ファイルのPfmFileSizeパラメタに0が指定されている場合は採取され
ません。
・ conductor用性能ログファイル
- 65 -
・ director用性能ログファイル
・ sorter用性能ログファイル
・ searcher用性能ログファイル
性能ログの出力情報については、“導入・運用ガイド”の“性能ログの出力情報”を参照してください。
採取方法
各プロセスの動作環境ファイルのPfmFileFolderパラメタに指定したパスに存在するファイルをすべて採取してください。
[格納場所：PfmFileFolderパラメタ（省略時）]
－ Solaris/Linuxの場合
PfmFileFolder
/var/opt/FJSVshnsk/log/プロセス名/
－ Windowsの場合
PfmFileFolder
"C:\Program Files\Interstage Shunsaku\Shunsaku\log\プロセス名\"
備考. プロセス名：“conductor”、“director”、“sorter”または“searcher”
[ファイル形式]
・ PfmFileSwitchパラメタを指定していない場合
－プロセス識別子_pfm.log
－プロセス識別子_pfm_世代番号_old.log（存在する場合のみ採取）
例）directorの場合（プロセス識別子：shund1）
shund1_pfm.log
shund1_pfm_1_old.log
・ PfmFileSwitchパラメタを指定している場合
－プロセス識別子_pfm_0_YYYYMMDDhhmm.log
－プロセス識別子_pfm_世代番号_old_YYYYMMDDhhmm.log
（存在する場合のみ採取）
例）directorの場合（プロセス識別子：shund1）
shund1_pfm_0_200510220000.log
shund1_pfm_1_old_200510211235.log
備考.プロセス識別子：各プロセスの識別子
世代番号：世代を表す数字
YYYY：年、MM：月、DD：日、hh：時、mm：分
- 66 -
3.2.4 システムログ/イベントログ
システムログ
システムログは、SolarisまたはLinuxにおけるOSの管轄下にあるロギングファイルです。OSやアプリケーションが出力す
る全事象が出力されます。
Shunsakuのエラーメッセージも出力されます。
イベントログ
イベントログは、Windowsにおけるハードウェア・ソフトウェアなどの情報収集・監視サービスです。
OSやアプリケーションが出力する全事象が出力されます。
Shunsakuのエラーメッセージも出力されます。
採取方法
以下のシステムログ/イベントログをすべてのサーバで採取してください。
システムログ
/var/adm/messages ファイル
/var/log/messages ファイル
システムログは、すべての世代（messages.*）を採取してください。
イベントログ
イベントログは、以下の手順で採取します。
Windows 2000またはWindows Server 2003の場合
1. [スタート]ボタンから、[設定]-[コントロールパネル]をクリックします。
2. [管理ツール]をダブルクリックします。
3. [イベントビューア]をダブルクリックします。
4. 「アプリケーションログ」にカーソルを合わせ、[操作]メニューで“ログファイルの名前を付けて保存”を選択しま
す。
5. 保存画面で保存先とファイル名を入力し、ファイル形式はテキスト形式かCSV形式のどちらかを選択します。
ここで保存したファイルはテキストエディタまたはExcelで参照可能となります。
Windows Server 2008の場合
1. [管理ツール]の [イベントビューア]を起動します。
2. 「Windowsログ」の「アプリケーション」にカーソルを合わせ、[操作]メニューで“イベントに名前を付けて保存”を
選択します。
3. 保存画面で保存先とファイル名を入力し、ファイル形式はテキスト形式かCSV形式のどちらかを選択します。
3.2.5 利用者の操作記録
利用者の操作記録は、実際の操作手順、エラーメッセージなどを把握するための資料です。
- 67 -
採取方法
以下の手順で採取してください。
1. 異常事象の発生した操作または発生のきっかけとなった操作（アプリケーション・コマンド）を端末画面上で特定し
ます。
2. 特定した操作の開始から終了または異常終了まで、一連の作業の流れがわかる範囲をテキストファイルに保存し
てください。
エラーメッセージが画面に出力されている場合には、そのエラーメッセージも含めたものを採取するようにしてくだ
さい。
正常に実行できるケースとできないケースがわかっている場合には、双方を実行した際の操作のログも採取してくださ
い。
なお、本番業務の運用中に問題発生した場合で、アプリケーションでログを採取する仕組みを用意している場合には、
そのログも採取してください。
利用者の操作記録が残っていない場合には、エラーが発生するまでの操作（アプリケーション・コマンド）情報を可能な
範囲で収集してください。
3.2.6 ダイレクトアクセスキー定義ファイル
ダイレクトアクセスキー定義ファイルは、ダイレクトアクセスキー名を定義するファイルです。ダイレクトアクセス機能の詳細
は、“アプリケーション開発ガイド”の“ダイレクトアクセス機能”を参照してください。
採取方法
以下に格納されているダイレクトアクセスキー定義ファイルを採取してください。
なお、ダイレクトアクセスキー定義ファイルのファイル名は、director用動作環境ファイルのDirectKeyListFileパラメタで定
義されています。
・ Solaris/Linuxの場合
/etc/opt/FJSVshnsk/etc/director/
・ Windowsの場合
Shunsakuのインストール先のフォルダ\Shunsaku\etc\director\
3.3 事象共通資料の採取方法
トラブルの事象や条件により必要となる資料の採取方法を示します。
3.3.1 検索式、リターン式、ソート式
ShunsakuのAPIに指定した検索式、リターン式およびソート式です。
この資料は、APIエラー発生時のみ必要な資料です。
- 68 -
・異常の原因となった各式を特定できる場合
ShunsakuのAPIに指定した各式をテキストファイルに保存します。
・異常の原因となった各式を特定できない場合
APIスナップによる出力レベル2でのロギングを行っている場合は、APIスナップ用ログファイルを採取してください。
APIスナップ機能による出力レベル2でのロギングを行っていない場合は、SnapLevelパラメタで2を指定して再現テス
トを実施し、APIスナップ用ログファイルを採取してください。
迅速な調査を可能とするためにも、APIスナップ機能による出力レベル2でのロギングを行うことを推奨します。
3.3.2 APIスナップのログ
APIスナップを利用している場合に採取されるAPIの各種入出力情報です。
この資料は、APIエラー発生時のみ必要な資料です。
APIスナップのログファイルは、アプリケーションのプロセスごとに作成されます。このファイルは、API用動作環境ファイルの
SnapLevelパラメタで1または2を設定している場合に採取されます。
APIスナップを利用している場合には、API用動作環境ファイルのLogFileパラメタに指定したパスに存在する、以下の形
式のファイルをすべて採取してください。
・ LogFileに指定したファイル名 + _プロセスID. + LogFileに指定したファイルの拡張子
・ LogFileに指定したファイル名 + _プロセスID. + LogFileに指定したファイルの拡張子.x
x：数字（1～）
例）
Solaris/Linuxの場合
LogFileに指定した絶対パス名
実際に作成されるログファイル
=>
=>
/api/api.log
/api/api_2435.log
Windowsの場合
LogFileに指定した絶対パス名
実際に作成されるログファイル
=>
=>
C:\api\api.log
C:\api\api_2435.log
APIスナップの詳細については、“アプリケーション開発ガイド”の“アプリケーションのデバッグ”を参照してください。
3.3.3 アプリケーションソース
ShunsakuのAPI（Java/.NET/C）を使用しているアプリケーションソースです。
この資料は、APIエラー発生時のみ必要な資料です。
必須ではありませんが、調査の過程で、APIの使用方法に誤りがあると思われた場合、または再現テストが必要となった
場合に、提供を依頼することがあります。また、性能問題の調査の過程で、ヒット件数や返信要求件数などの性能問題の
要因となる数値を検証する場合に、提供を依頼することがあります。
- 69 -
3.3.4 XMLデータ
Shunsakuに格納しているXML文書です。
必須ではありませんが、調査の過程で再現テストが必要となった場合、提供を依頼することがあります。
なお、お客様のご都合により、XMLデータを採取できない場合には、下記の情報を採取してください。
・レコード件数
・平均レコード長
・タグの構造
3.3.5 シェルスクリプトまたはバッチ
業務で利用しているシェルスクリプトまたはバッチです。
必須ではありませんが、調査の過程で再現テストが必要となった場合、提供を依頼することがあります。
3.4 プロセスダウン時の資料採取
Shunsakuの運用中にプロセス（conductor、director、searcher、sorter）のダウンが発生した際の、調査資料の採取につい
て説明します。
3.4.1 プロセスダウンの調査資料
プロセスダウンの調査をする場合、以下の資料を採取する必要があります。
・必須資料
必須資料として以下の資料が必要です。
－動作環境ファイル
－動作ログ
－システムログ(イベントログ)
－ユーザ操作のログ
－ダイレクトアクセスキー定義ファイル（ダイレクトアクセス機能を利用時のみ）
各資料の詳細および採取方法については、“3.2 必須資料の採取方法”を参照してください。
・事象共通の資料
事象や発生条件などにより、事象共通資料として以下の資料が必要です。
－検索式、リターン式、ソート式（APIエラー発生時のみ必要）
－ APIスナップのログ（APIエラー発生時のみ必要）
－アプリケーションソース
－ XMLデータ
－シェルスクリプトまたはバッチ
各資料の詳細および採取方法については、“3.3 事象共通資料の採取方法”を参照してください。
- 70 -
・事象個別の資料
プロセスダウンの調査をする場合、事象個別の資料として以下の資料が必要です。
－ディレクタデータファイル
－サーチデータファイル
－オペレーションログファイル
－ロードモジュール
－ mapファイル（Windowsの場合のみ必要）
－ coreスタックトレース
－コアファイル
各資料の詳細および採取方法については、以降の3.4.2 ディレクタデータファイル～3.4.8 コアファイルの説明を参照
してください。
3.4.2 ディレクタデータファイル
Shunsakuに取り込み後のXML文書です。
必須ではありませんが、調査の過程で再現テストが必要となった場合、提供を依頼することがあります。
ディレクタデータファイルは、director用動作環境ファイルのDataFileFolderパラメタに指定したパス配下に存在します。
なお、お客様のご都合により、ディレクタデータファイルを採取できない場合には、ディレクタデータファイルの情報（lsコ
マンド、または、dirコマンドの表示内容）を採取してください。
3.4.3 サーチデータファイル
directorからsearcherに配布され、サーチサーバのディスクに格納された検索用データです。
必須ではありませんが、調査の過程で再現テストが必要となった場合、提供を依頼することがあります。
サーチデータファイルは、searcher用動作環境ファイルのSearchDataFileFolderパラメタに指定したパス配下に存在しま
す。
なお、お客様のご都合により、サーチデータファイルを採取できない場合には、サーチデータファイルの情報（lsコマン
ド、または、dirコマンドの表示内容）を採取してください。
3.4.4 オペレーションログファイル
Shunsakuの更新操作を更新ログデータとして蓄積するファイルです。
shundrecoverコマンドでのエラー発生時のみ必要です。
このファイルは、director用動作環境ファイルのOperationLogFolderパラメタが設定されている場合に採取されます。
OperationLogFolderパラメタを設定している場合には、OperationLogFolderパラメタに指定したパス配下を採取してくださ
い。
オペレーションログファイルの詳細については、“導入・運用ガイド”の“バックアップ・リカバリ”を参照してください。
- 71 -
3.4.5 ロードモジュール
プロセスダウン時には、原因の特定のためにコアファイルとセットで必要となります。
各ロードモジュールの格納場所とファイル名は、以下のとおりです。
Solaris/Linuxの場合
conductor
/opt/FJSVshnsk/sbin/shuncdmn
director
/opt/FJSVshnsk/sbin/shunddmn
searcher
/opt/FJSVshnsk/sbin/shunsdmn
sorter
/opt/FJSVshnsk/sbin/shunodmn
Windowsの場合
conductor
Shunsakuのインストール先のフォルダ\Shunsaku\sbin\shuncdmn.exe
director
Shunsakuのインストール先のフォルダ\Shunsaku\sbin\shunddmn.exe
searcher
Shunsakuのインストール先のフォルダ\Shunsaku\sbin\shunsdmn.exe
sorter
Shunsakuのインストール先のフォルダ\Shunsaku\sbin\shunodmn.exe
3.4.6 mapファイル（Windows）
プロセスダウン時には、原因の特定のためにコアファイルとセットで必要となります。
mapファイルの格納場所は、以下のとおりです。
conductor
Shunsakuのインストール先のフォルダ\Shunsaku\sbin\shuncmemfuncmap
director
Shunsakuのインストール先のフォルダ\Shunsaku\sbin\shundmemfuncmap
searcher
Shunsakuのインストール先のフォルダ\Shunsaku\sbin\shunsmemfuncmap
sorter
Shunsakuのインストール先のフォルダ\Shunsaku\sbin\shunomemfuncmap
3.4.7 coreスタックトレース
障害の初期切り分けとして、採取されたコアファイルからデバッガを使ってスタックトレースを採取します。
問題箇所の特定のために必須となります。
・採取方法(Solarisの場合）
・採取方法（Linuxの場合）
・採取方法（Windowsの場合）
coreスタックトレースは、以下の手順で採取します。
- 72 -
採取方法(Solarisの場合）
1. スーパーユーザー権限でadbデバッガを起動します。
adb /opt/FJSVshnsk/sbin/プロセス名 coreファイル名（絶対パス）
例）以下は、directorプロセスがダウンした場合の例です。
adb /opt/FJSVshnsk/sbin/shunddmn core_15928.040831.054704
core file = core_15928.040831.054704 -- program ``shunddmn'' on platform SUNW,Ultra-Enterprise
SIGSEGV: Segmentation Fault
2. デバッガ上で以下を入力し（$も含みます）、スタックトレースを表示させます。
$c
例）
$c
do_entry(1970918,e,61b38,61850,5ba38,0) + b08
_thread_start(63580,0,0,0,0,0) + 40
上記の表示をテキストファイルに保存してください。
3. デバッガ上で以下を入力し（$も含みます）、adbデバッガを停止します。
$q
採取方法（Linuxの場合）
1. スーパーユーザー権限でgdbデバッガを起動します。
gdb /opt/FJSVshnsk/sbin/プロセス名 coreファイル名（絶対パス）
例）以下は、searcherプロセスがダウンした場合の例です。
gdb /opt/FJSVshnsk/sbin/shunsdmn core_11216.040907.203435
GNU gdb Red Hat Linux (5.2-2)
Copyright 2002 Free Software Foundation, Inc.
：
2. デバッガ上で以下を入力し、スタックトレースを表示させます。
thread apply all bt
例）
- 73 -
(gdb) thread apply all bt
Thread 4 (process 11216):
：
上記の表示をテキストファイルに保存してください。
3. デバッガ上で以下を入力し、gdbデバッガを停止します。
q
採取方法（Windowsの場合）
1. mapファイルを動作環境ファイルのCoreFileFolderに指定したフォルダ配下にコピーします。mapファイルの格納場
所については、“3.4.6 mapファイル（Windows）”の記述を参照してください。
2. 1.でコピーしたmapファイルのファイル名を以下に変更します。
ファイル名：shunmemfuncmap
3. 動作環境ファイルのCoreFileFolderに指定したフォルダ上で、Administrator権限を持つユーザにて以下のコマン
ドを実行します。
Shunsakuのインストール先のフォルダ\Shunsaku\sbin\shunstacktrace coreファイル名
コマンドの出力結果をテキストファイルに保存してください。
3.4.8 コアファイル
coreスタックトレースで原因の特定ができなかった場合に必要となるため、提供を依頼することがあります。
コアファイルが必要となった場合には、エラーメッセージの行末に表示されている識別子に該当する動作環境ファイルの
CoreFileFolderパラメタに指定しているパス配下のコアファイルを採取してください。
例）メッセージの例（directorの場合）
shn02013u : Core file has been obtained. Core file name is core_15928.040831.054704. (director) [shund1]
メッセージの詳細については、“メッセージ集”を参照してください。
Solarisの場合
参考
cocoreツール
xcrashパッケージがインストールされている場合、cocoreツールにより、コアファイルおよびコアファイルの解析に必要な
ファイルを圧縮して採取することができます。
- 74 -
[採取方法]
1. cocoreツールを起動します。
/opt/xcrash/cocore coreファイル名（絶対パス名）
2. 圧縮ファイル名を問い合せるメッセージに対し、任意のファイル名を入力します。
3.5 ハングアップ時の資料採取
Shunsakuの運用中に操作がハングアップ状態となった際の、調査資料の採取について説明します。
3.5.1 ハングアップの調査資料
ハングアップの調査をする場合、以下の資料を採取する必要があります。
・必須資料
必須資料として以下の資料が必要です。
－動作環境ファイル
－動作ログ
－性能ログ
－システムログ(イベントログ)
－ユーザ操作のログ
－ダイレクトアクセスキー定義ファイル（ダイレクトアクセス機能を利用時のみ）
各資料の詳細および採取方法については、“3.2 必須資料の採取方法”を参照してください。
・事象共通の資料
事象や発生条件などにより、事象共通資料として以下の資料が必要です。
－検索式、リターン式、ソート式（APIエラー発生時のみ必要）
－ APIスナップのログ（APIエラー発生時のみ必要）
－アプリケーションソース
－ XMLデータ
－シェルスクリプトまたはバッチ
各資料の詳細および採取方法については、“3.3 事象共通資料の採取方法”を参照してください。
・事象個別の資料
ハングアップの調査をする場合、事象個別の資料として以下の資料が必要です。
－ロードモジュール
－ mapファイル（Windowsの場合のみ必要）
－プロセスダンプ
－プロセス情報
- 75 -
各資料の詳細および採取方法については、以降の3.5.2 ロードモジュール～3.5.5 プロセス情報の説明を参照してく
ださい。
3.5.2 ロードモジュール
ハングアップ時にプロセスダンプの解析のためにプロセスダンプとセットで必要となります。
ロードモジュールの格納場所は、“3.4.5 ロードモジュール”を参照してください。
3.5.3 mapファイル（Windows）
ハングアップ時にプロセスダンプの解析のため、プロセスダンプとセットで必要となります。
Shunsakuの動作プラットフォームがWindowsの場合に必要なファイルです。
mapファイルの格納場所は、“3.4.6 mapファイル（Windows）”を参照してください。
3.5.4 プロセスダンプ
ハングアップ状態を内部的な視点から解析するうえで必要となります。
プロセスダンプは、以下の手順で採取します。
採取方法
1. psコマンドにより、ハングアップ状態となっているプロセスのID(PID)を調べます。
例) directorプロセスの場合
ps -ef | grep shunddmn
2. スーパーユーザー権限でプロセスダンプを採取します。
gcore PID
カレントディレクトリにcore.PIDというファイル名で出力されます。
採取方法
Administrator権限を持つユーザでshunsyskillコマンドを使用してプロセスダンプを採取します。このコマンドは、採取対
象プロセスごとにオプションが分かれています。
1. shunsyskill.exeの格納先ディレクトリへ移動します。
cd Shunsakuのインストール先のフォルダ\Shunsaku\sbin
2. プロセスダンプを採取します。
－ conductorの場合
shunsyskill -c conductor識別子
- 76 -
－ directorの場合
shunsyskill -d director識別子
－ searcherの場合
shunsyskill -s searcher識別子
－ sorterの場合
shunsyskill -o sorter識別子
それぞれ、各識別子の動作環境ファイルのCoreFileFolderパラメタに定義されたパス配下にcore_PID.日付.時刻
のファイル名で出力されます。
3.5.5 プロセス情報
以下の情報がプロセスダンプと合わせて必要となります。
以下に各情報の採取方法を示します。
備考. Windows版では、プロセス情報を取得する手段は、Visual Cなどを使用したデバッグ作業になってしまうため、外
部に公開できる手順はありません。
採取方法
プロセスのスタックトレース
1. psコマンドにより、ハングアップ状態となっているプロセスID(PID)を調べます。
例) directorプロセスの場合
ps -ef | grep shunddmn
2. スーパーユーザー権限で、対象PIDのスタック情報をトレースします。
pstack PID
出力結果をテキストファイルに保存してください。
プロセス内のシステムコールトレースの情報
スーパーユーザー権限で、前述のPIDを使用して以下のコマンドを実行し、30秒程度経過したらCtrl+Cで強制終了
させてください。
strace -f -p PID -o 出力ファイル
出力ファイルが資料となります。
- 77 -
IPCリソース使用状況
コマンドのハングアップの場合、IPC資源不足の可能性も考えられます。
以下のコマンドを実行し、出力結果を保存してください。
ipcs -a
3.6 性能問題時の資料採取
Shunsakuの運用中に性能問題が発生した際の、調査資料の採取について説明します。
3.6.1 性能問題の調査資料
性能問題の調査をする場合、以下の資料を採取する必要があります。
・必須資料
必須資料として以下の資料が必要です。
－動作環境ファイル
－動作ログ
－性能ログ
－システムログ(イベントログ)
－ユーザ操作のログ
－ダイレクトアクセスキー定義ファイル（ダイレクトアクセス機能を利用時のみ）
各資料の詳細および採取方法については、“3.2 必須資料の採取方法”を参照してください。
・事象共通の資料
事象や発生条件などにより、事象共通資料として以下の資料が必要です。
－検索式、リターン式、ソート式（APIエラー発生時のみ必要）
－ APIスナップのログ（APIエラー発生時のみ必要）
－アプリケーションソース
－ XMLデータ
－シェルスクリプトまたはバッチ
各資料の採取方法については、“3.3 事象共通資料の採取方法”を参照してください。
・事象個別の資料
性能問題の調査をする場合、事象個別の資料として以下の資料が必要です。
－性能情報（Solaris、Linux、Windows）
性能情報として、以下のシステム情報を採取する必要があります。
- CPU使用状況
- ネットワーク負荷状況
- メモリ使用状況
- I/O発生状況
- プロセス情報
- 78 -
性能情報は、検索の開始から終了までの間に、すべてのディレクタサーバで採取します。
各資料の採取方法については、以降の3.6.2 性能情報（Solaris）～3.6.4 性能情報（Windows）の説明を参照してくだ
さい。
3.6.2 性能情報（Solaris）
Solarisにおける性能問題の調査に必要な性能情報の採取方法を示します。
・ CPU使用状況
・ネットワーク負荷状況
・メモリ使用状況
・ I/O発生状況
・プロセス情報
CPU使用状況
複数CPU使用率を監視するには、mpstatコマンドを使用します。
mpstat -p [実行間隔(秒)] [実行回数]
備考. 実行回数を省略した場合、無限に実行されます。
表示例）
CPU minf mjf xcal
0
0
0
1
1
1
0
1
intr ithr
214 114
3
2
csw icsw migr smtx
25
0
0
0
31
0
1
0
srw syscl
0
38
0
45
usr sys
0
0
0
0
wt idl
0 100
0 100
備考. CPU使用率＝(usr+sys)%
ネットワーク負荷状況
ネットワークの使用状況を監視するには、netstatコマンドを使用します。
netstat -in
表示例）
Name
dr0
eth0
lo0
Mtu
1268
1500
9216
Network
192.168.0
192.169.0
127
Address
192.168.0.1
192.169.0.2
127.0.0.1
Ipkts
4340
4116
2
Ierrs
0
0
0
Opkts
14
6748
2
Ipkts：受信したパケットの数
Ierrs：受信したパケット内でエラーを起こしていたパケットの数
Opkts：送信したパケットの数
Oerrs：送信したパケット内でエラーを起こしていたパケットの数
Collis：衝突（コリジョン）を起こしたパケットの数
- 79 -
Oerrs
0
0
0
Collis
0
0
0
メモリ使用状況
メモリの使用状況を監視するには、vmstatコマンドを使用します。
スワップイン（スワップアウトされたデータを物理メモリに読み込む）およびスワップアウト（物理メモリのデータをハードディ
スクに書き出す）のメモリ量を調べることができます。
vmstat -S [実行間隔(秒)] [実行回数]
備考. 実行回数を省略した場合、無限に実行されます。
表示例）
kthr
memory
r b w
swap free si
0 0 0 1293368 806752 0
page
so pi po
0 0 0
disk
fr de sr f0 s0 s1 s4
0 0 0 0 0 0 0
faults
in
sy
217
83
cpu
cs us sy id
55 0 0 100
si：1秒当たりのスワップインのメモリ量（キロバイト）
so：同じくスワップアウトのメモリ量（キロバイト）
I/O発生状況
ディレクタサーバのディスクI/Oの使用状況を監視するには、iostatコマンドを使用します。
iostat -ctx [実行間隔(秒)] [実行回数]
備考. 実行回数を省略した場合、無限に実行されます。
表示例）
device
lofi1
sd0
sd1
sd2
nfs1
r/s
0.0
0.0
0.2
0.2
0.0
extended device statistics
w/s
kr/s
kw/s wait actv
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
4.8
5.6
65.0
0.0
0.2
0.5
11.1
24.1
0.0
0.0
0.0
0.0
0.0
0.0
0.0
svc_t
0.0
0.3
42.3
36.3
0.1
%w
0
0
0
0
0
%b
0
0
2
0
0
tty
tin tout
0 484
cpu
us sy wt id
11 20 1 69
プロセス情報
プロセスの動作状況を監視するには、psコマンドを使用します。
ps -elfy
表示例）
S
UID
PID PPID
S
root 21715 21714
shunsys shundir1 60432
C PRI NI
RSS
0 59 20 20328
SZ
23296
WCHAN
STIME TTY
? 16:35:55 ?
- 80 -
TIME CMD
0:00 shunddmn
S
root 21706 21705
shunsys shundir2 60432
0
58 20 20336
23304
? 16:35:55 ?
0:00 shunddmn
備考. RSS：プロセスの実メモリ使用量
3.6.3 性能情報（Linux）
Linuxにおける性能問題の調査に必要な性能情報の採取方法を示します。
・ CPU使用状況
・ネットワーク通信状況
・メモリ使用状況
・ I/O発生状況
・プロセス情報
CPU使用状況
CPUの使用状況を監視するには、mpstatコマンドを使用します。
mpstatコマンドが存在しない場合は、sysstatパッケージをインストールしてください。
複数のCPUを実装しているマシンの場合は、以下の例を参照してください。
mpstat -P ALL [実行間隔(秒)] [実行回数]
備考. 実行回数を省略した場合、無限に実行されます。
また、シングルCPUの場合は、以下の例を参照してください。
mpstat [実行間隔(秒)] [実行回数]
備考. 実行回数を省略した場合、無限に実行されます。
表示例）
xx:xx:xx CPU
xx:xx:xx all
%user
0.00
%nice %system
0.00
0.50
%idle
99.50
intr/s
103.98
備考. CPUの使用率=%user+%system
ネットワーク通信状況
ネットワークの使用状況を監視するには、擬似ファイル /proc/net/dev を参照してください。
view /proc/net/dev
これは送受信したパケット数、エラーと衝突（コリジョン）の回数、その他の基本的な統計を与えています。
フォーマットは、以下のとおりです。
Inter-|
Receive
| Transmit
face |bytes
packets errs drop fifo frame compressed multicast |bytes
packets errs drop fifo colls carrier compressed
- 81 -
lo: 2776770 11307
eth0: 1215645 2751
0
0
0
0
0
0
0
0
0
0
0
0
2776770 11307
1782404 4324
0
0
0
0
0
0
0
427
0
0
Receive/packets ：受信したパケットの数
Receive/errs ：受信したパケット内でエラーを起こしていたパケットの数
Transmit/packets：送信したパケットの数
Transmit/errs ：送信したパケット内でエラーを起こしていたパケットの数
Transmit/colls ：衝突（コリジョン）を起こしたパケットの数
メモリ使用状況
メモリの使用状況を監視するには、vmstatコマンドを使用します。
スワップイン（スワップアウトされたデータを物理メモリに読み込む）およびスワップアウト（物理メモリのデータをハードディ
スクに書き出す）のメモリ量を調べることができます。
vmstat [実行間隔(秒)] [実行回数]
備考. 実行回数を省略した場合、無限に実行されます。
表示例）
procs
r b w swpd free
1 0 0 22016 36076
memory
swap
buff cache si
2140 80676
9
io
so
21
bi
96
system
bo in
63 156
cs
583
cpu
us sy
35 2
id
63
si：1秒当たりのスワップインのメモリ量（キロバイト）
so：同じくスワップアウトのメモリ量（キロバイト）
I/O発生状況
ディレクタサーバのディスクI/Oの使用状況を監視するには、iostatコマンドを使用します。
iostatコマンドが存在しない場合は、sysstatパッケージをインストールしてください。
iostat -x [実行間隔(秒)] [実行回数]
表示例）
avg-cpu:
%user
%nice
0.01
0.00
Device:
rrqm/s wrqm/s
/dev/sda
0.01
0.18
/dev/sda1
0.00
0.00
%sys
0.01
r/s
0.03
0.00
%idle
99.98
w/s rsec/s
0.12
0.30
0.00
0.00
wsec/s
2.45
0.00
rkB/s
0.15
0.00
プロセス情報
プロセスの動作状況を監視するには、psコマンドを使用します。
ps -elfy
- 82 -
wkB/s
1.23
0.00
avgrq-sz
18.20
12.21
avgqu-sz
0.09
0.00
await
59.50
55.11
svctm
0.99
32.70
%util
0.02
0.00
0
0
表示例）
S
UID
PID
S
root 21715
shunsys shundir1
S
root 21706
shunsys shundir2
PPID
21714
60432
21705
60432
C PRI NI
RSS
0 59 20 20328
SZ
23296
0
23304
58 20 20336
WCHAN
STIME TTY
? 16:35:55 ?
? 16:35:55 ?
TIME CMD
0:00 shunddmn
0:00 shunddmn
備考. RSS：プロセスの実メモリ使用量
3.6.4 性能情報（Windows）
Windowsにおける性能問題の調査に必要な性能情報の採取方法を示します。
採取方法
Windows 2000またはWindows Server 2003の場合
1. [管理ツール]で[パフォーマンス]をダブルクリックして、システムモニタを起動します。
2. システムモニタの[パフォーマンスログと警告]の[カウンタログ]をクリックします。
3. 詳細ウィンドウの空白部分を右クリックして、ポップアップメニューから[新しいログの設定]を選択します。
4. [新しいログの設定]画面で任意のログファイル名（perfなど）を入力して、[OK]をクリックします。
5. [全般]タブの[カウンタの追加]をクリックして、[カウンタの選択]画面を表示させます。
6. [カウンタの追加]画面の[パフォーマンスオブジェクト]で[Memory]を選択後、[一覧からカウンタを選ぶ]の以下の各
カウンタを選択して、[追加]をクリックします。
-->メモリ使用量を採取
（カウンタごとに[追加]をクリックする必要があります。）
－ Available Bytes
－ Pages/sec
－ Page Faults/sec
－ Pages Input/sec
－ Page Reads/sec
7. [カウンタの追加]画面の[パフォーマンスオブジェクト]で[Processor]を選択後、[一覧からカウンタを選ぶ]の以下の
各カウンタを選択して、[追加]をクリックします。
-->CPU使用状況を採取
（カウンタごとに[追加]をクリックする必要があります。）
－ %Processor Time
－ Interrupts/sec
- 83 -
8. [カウンタの追加]画面の[パフォーマンスオブジェクト]で[System]を選択後、[一覧からカウンタを選ぶ]の以下のカ
ウンタを選択して、[追加]をクリックします。
-->CPU使用状況を採取
－ Processor Queue Length
9. [カウンタの追加]画面の[パフォーマンスオブジェクト]で[PhysicalDisk]を選択後、[一覧からカウンタを選ぶ]の以下
の各カウンタを選択して、[追加]をクリックします。
-->I/O発生状況を採取
（カウンタごとに[追加]をクリックする必要があります。）
－ %Disk Time
－ Disk Bytes/sec
－ Avg. Disk Bytes/Transfer
－ Current Disk Queue Length
10. [カウンタの追加]画面の[パフォーマンスオブジェクト]で下記の項目を選択後、[すべてのカウンタ]を選択し、[追
加]をクリックします。
－ Windows 2000の場合：[TCP]
－ Windows Server 2003の場合：[TCPv4]
-->ネットワーク通信状況を採取
11. [カウンタの追加]画面の[閉じる]をクリックします。
12. [ログファイル]タブの[ログファイルの種類]のドロップダウンリストから下記の項目を選択し[構成]をクリックします。
その後、[ログファイルの構成]画面でログファイルの出力先として任意のフォルダとファイル名を入力して[OK]をク
リックします。
－ Windows 2000の場合：[テキストファイル(カンマ区切り)]
－ Windows Server 2003の場合：[テキストファイル(CSV)]
13. [ログファイル]タブの[ファイル名のサフィックス]のドロップダウンリストから[mmddhhmm]を選択します。
14. [スケジュール]タブの[ログの停止]の[指定時間を経過後]に[2分]を設定して、[適用]をクリックしたあとに[OK]をク
リックします。
15. 約2分経過するとログの採取が完了して、詳細ウィンドウのログのアイコンが緑色から赤色に変わりますので、上記11.
で指定したフォルダ配下のログファイル（テキストファイル）を採取してください。
16. タスクマネージャを起動し、[プロセス]タブのハードコピーを採取してください。
-->プロセス情報を採取
Windows Server 2008の場合
1. [管理ツール]の[信頼性とパフォーマンスモニタ]を起動します。
- 84 -
2. [信頼性とパフォーマンスモニタ]のナビゲーションウィンドウで、[データコレクタセット]を展開し、[ユーザー定義]
を右クリックして、[新規作成]-[データコレクタセット]をクリックします。データコレクタセットの作成ウィザードが起動
します。
3. データコレクタセットの名前を入力し、[手動で作成する]を選択して、[次へ]をクリックします。
4. [ログデータを作成する]-[パフォーマンスカウンタ]をチェックし、[次へ]をクリックします。
5. [パフォーマンスカウンタ]の[追加]をクリックし、カウンタを追加します。
a. リストボックスの[Memory]を展開し、以下の各カウンタを追加します。
-->メモリ使用量を採取
- Available Bytes
- Pages/sec
- Page Faults/sec
- Pages Input/sec
- Page Reads/sec
b. リストボックスの[Processor]を展開し、以下の各カウンタを追加します。
-->CPU使用状況を採取
- %Processor Time
- Interrupts/sec
c. リストボックスの[System]を展開し、以下の各カウンタを追加します。
-->CPU使用状況を採取
- Processor Queue Length
d. リストボックスの[PhysicalDisk]を展開し、以下の各カウンタを追加します。
-->I/O発生状況を採取
- %Disk Time
- Disk Bytes/sec
- Avg. Disk Bytes/Transfer
- Current Disk Queue Length
e. リストボックスの[TCPv4]を展開し、すべてのカウンタを追加します。
-->ネットワーク通信状況を採取
6. [次へ]をクリックします。
7. データの保存場所を指定し、[次へ]をクリックします。
- 85 -
8. [保存して閉じる]を選択し、[完了]をクリックします。
9. 作成したデータコレクタセットのパフォーマンスカウンタのプロパティを表示し、以下のプロパティを設定します。
a. [パフォーマンスカウンタ]タブの[ログフォーマット]を[カンマ区切り]に設定します。
b. [ファイル]タブの[ファイル名のフォーマット]をMMddHHmmに設定します。
c. [OK]をクリックします。
10. [信頼性とパフォーマンスモニタ]のナビゲーションウィンドウで、作成したデータコレクタセットを選択し、右クリックの
[プロパティ]をクリックします。
11. [停止条件]タブの[全体の期間]を2分に設定し、[OK]をクリックします。
12. [信頼性とパフォーマンスモニタ]のナビゲーションウィンドウで、作成したデータコレクタセットを選択し、右クリックの
[実行]をクリックして実行します。
約2分経過するとログの採取が完了します。上記7.で指定したフォルダ配下のログファイル（テキストファイル）を採
取してください。
13. タスクマネージャを起動し、[プロセス]タブのハードコピーを採取してください。
-->プロセス情報を採取
- 86 -
付録A QA集
本章では、Shunsakuの利用における、よくある質問と回答について示します。
A.1 全般
機能全般における、よくある質問とその回答について示します。
A.1.1
検索条件
指定可能な検索条件は何ですか？
検索条件には、以下の種類が利用できます。
・パス式（要素ノード）
・テキスト式（テキストノードの値)または属性式（属性ノードの値）
・キーワードと比較演算子
－パターン（詳細な検索条件を指定できる部分一致）
－文字列（完全一致、文字列の大小比較）
－数値（数値比較）
さらに、各検索条件は、AND演算とOR演算で組み合わせることができます。
詳細については、“アプリケーション開発ガイド”を参照してください。
フリーワード検索は、完全一致ですか？部分一致ですか？
両方ともに可能です。
検索API発行時に、完全一致、部分一致を指定します。
A.1.2
データ更新
データを追加する場合、多重更新は可能ですか？
・データ追加の場合
－アプリケーションによる追加の場合（ShunsakuのAPI）
可能です。
－コマンドによる追加の場合（shundimportコマンド）
差分データを追加することはできますが、多重での実行はサポートしていませ
ん。
・データ削除の場合
－アプリケーションによる削除の場合（ShunsakuのAPI）
通常の削除：後続のアプリケーションはエラーとなります。
ダイレクト削除：可能です。
－コマンドによる削除の場合（shundimportコマンド）
多重での実行はサポートしていません。
－コマンドによる削除の場合（shundexportコマンド）
多重での実行はサポートしていません。
- 87 -
・データ更新の場合
－アプリケーションによる更新の場合（ShunsakuのAPI）
通常の更新：後続のアプリケーションはエラーとなります。
ダイレクト更新：後続のアプリケーションはエラーとなります。
－コマンドによる更新の場合
コマンドによる更新機能はありません。
A.1.3
文字種の同一視
文字種（大文字／小文字）を意識せずに検索する方法を教えてください。
システム用動作環境ファイルおよびdirector用動作環境ファイルの以下のパラメタを利用
することで、文字種（大文字／小文字）を意識せずに検索することができます。
・ ANKmix ：半角英字の大文字／小文字の同一視
・ KNJmix ：全角英字の大文字／小文字の同一視
これらは、Shunsakuシステム単位およびディレクタサーバのdirector単位に指定できま
す。
詳細については、“導入・運用ガイド”を参照してください。
なお、アプリケーション側の設定だけで同様のことを行う場合には、検索条件を「OR」で
結合するなど、条件式を複数指定する必要があります。
A.1.4
アプリケーションおよびコマンドの競合関係
データ格納中の検索は可能ですか？
データ格納中に検索を行うことは可能です。
Shunsakuは、サーチサーバのメモリ上に展開されたデータを検索し、クライアントへ返却
する際の検索結果のデータは、ディレクタサーバから獲得します。
そのため、データが追加されていく場合には、検索結果への影響はありません。
ただし、データが更新／削除されていく場合には、クライアントへの返却データの獲得時
にデータがなくなっていることがあるため、正しく検索結果を取得できない可能性があり
ます。
したがって、可能な限り更新系と検索系の操作が重ならないような、運用上の考慮は必
要です。
A.1.5
トランザクション制御
直前にユーザが行った操作を取り消し、元に戻すといった機能はありますか？
トランザクション機能を提供しています。
一連のデータ操作（追加、更新、削除）を、一括して有効または無効にすることができま
す。
詳細については、“アプリケーション開発ガイド”を参照してください。
A.1.6
アクセス制御
Shunsakuのデータに対して、RDBのようにユーザID／パスワードによるアクセス制御機
能はありますか？
- 88 -
ユーザIDによるアクセス制御機能はありません。
アプリケーション側でWebの認証機構やシングルサインオン機構などを利用した対応に
なります。
A.2 設計
設計時における、よくある質問とその回答について示します。
A.2.1
サーバ／ネットワーク
複数のサーチサーバをハードウェア仕様が異なるサーバで混在させて運用するときの
考慮点は何ですか？
サーチサーバのCPUクロック数、メモリサイズなどの仕様が異なるマシンが混在すると、
検索結果を返す時に、一番性能の低い（遅い）サーチサーバの検索結果を待ってから
アプリケーションに結果を返します。
システム全体のパフォーマンスは、その一台に依存してしまうため、複数のサーチサー
バのハードウェア仕様は、同一にすることを推奨します。
詳細については、“導入・運用ガイド”を参照してください。
ディレクタサーバとサーチサーバを別セグメントのLAN上に構築した場合、Shunsakuの
動作上で何か影響はあるでしょうか
両セグメント間でTCP/IP通信が可能となるようにLAN環境の設定（ルーティングなど）を
行う必要はありますが、Shunsakuのディレクタサーバとサーチサーバを別セグメントのLAN
上に配置しても問題はありません。
ただし、Shunsaku本来の性能を発揮するためには、ディレクタサーバとサーチサーバは
専用線にするようにしてください。ディレクタサーバとサーチサーバ間にShunsakuの処理
と関係のないデータが流れる場合、回線負荷などによる性能への影響が発生する可能
性があります。
A.2.2
データ形式
Shunsakuで管理対象とするデータ形式は何でしょうか。
整形式のXML文書(well-formed XML document)です。
ただし、XML宣言やDTDは検索対象にはなりません。
また、データ格納時にも、XML宣言のencodingは利用されません。
詳細については、“アプリケーション開発ガイド”の“XML文書についての留意事項”を
参照してください。
なお、ShunsakuにXML文書を直接取り込む場合は、1ファイルに複数のXML文書を連
続して格納しておくことにより、1回の操作で複数のXML文書を取り込むことが可能で
す。Shunsakuは、1ファイルに格納された複数のXML文書をルートとなる開始タグから終
了タグまでを1レコードとして区切り管理します。
制御文字(0x01～0x08）を含むXML文書をShunsaku へ取り込むことは可能でしょう
か？
制御文字を含むXML文書をShunsakuシステムに取り込むことはできません。
取込み時に、以下のエラーメッセージが出力され異常となります。
「shn30355u The data which is not well-formed XML document exists.」
このため、制御文字を代替文字（表示互換があり、かつ、検索式に使用されない文字）
に変換して、取込み処理を実施してください。
Shunsakuシステムは、「well-formed XMLデータ」を扱います。
- 89 -
制御文字の文字参照を扱うことは可能でしょうか？（0x01 を  と表記）
制御文字の文字参照を使用することはできません。
A.2.3
文字コード
Shunsakuに格納するXML文書の文字コードは統一する必要がありますか？
XML文書の文字コードは、統一しておく必要があります。
以下については、同じ文字コードを使用してください。
・ Shunsakuに取込むXML文書
・システム用動作環境ファイルのCharacterCodeパラメタに指定する文字コード
・検索式、リターン式、ソート式およびダイレクトアクセスキーの文字コード
・ダイレクトアクセスキー定義ファイルに指定する、テキスト式または属性式の文字コー
ド
・ shundexportコマンドに指定する、検索式ファイルの検索式の文字コード
UTF-8に統一することを推奨します。
なお、XML宣言中のエンコーディング方式の宣言は、データ格納時に利用されません。
Shunsakuでサポートしている文字コードは何でしょうか。
Shunsakuでは、以下の文字コードをサポートしています。
・ UTF-8
・ Shift-JIS（日本語）
・ EUC-JP（日本語）
・ GB18030（中国語）
・ GB2312（中国語）
・ Big5（中国語）
・ KSC5601（ハングル文字（韓国語））
注意
UTF-8はBOM（Byte Order Mark）なしの形式で利用してください。
A.2.4
性能見積り
ハードウェアの見積り時に最低限考慮すべき点は何でしょうか。
ハードウェアの仕様や個数は、以下を考慮して決定する必要があります。
・業務システムの性能要件（ピークTPS、同時アクセス数）
・データ量（最大データ長）
・データ件数
・システムの運用方法
- 90 -
性能見積りについては、当社技術員(SE)にお問い合わせください。
Shunsakuへのデータ登録性能の基礎値を教えてください。
データ取り込みコマンド（shundimport）によるデータ登録性能は、目安として4MB/sec程
度です。また、APIを使ったデータ登録性能もほぼ4MB/secと考えることができます。
なお、本値はあくまで目安値です。多重度や平均レコード長、レコード件数などに依存
します。実機での事前検証を含め、性能見積りについては、当社技術員(SE)にお問い
合わせください。
A.2.5
定量値
Shunsakuで扱えるデータ量（レコード件数、データサイズ）の制限があれば教えてくださ
い。
Shunsakuに格納するデータ量については、ハードウェアの実装量に依存する上限はあ
りますが、件数やサイズの制限は設けていません。
ただし、1回の検索、ソート・集計時の返却レコード数には、以下の制限があります。
・検索：10万件以内
・ソート・集計：1000件以内
Shunsakuのdirectorおよびsearcherプロセスが利用できるメモリ量の制限（1.3～1.5GB）と
いう観点から、およその目安として以下のように考えてください。
・ 1 directorで扱えるデータ件数：2500万件
（データ件数は動作環境ファイルのパラメタや動作条件によって変わります）
・ 1 searcherで扱える総XMLデータサイズ
－メモリ検索の場合：1.0GB
－ディスク検索の場合：50GB
（縮退時の配付分を考慮した値です。件数には依存しません）
参照
詳細については、“導入・運用ガイド”の“資源の見積り”を参照してください。
なお、上記の目安値を超えるような場合は、directorまたはsearcherプロセスを増加させる
ことで対応できます。
A.3 導入
導入時における、よくある質問とその回答について示します。
A.3.1
動作環境の設定
動作環境ファイルのパラメタは、自分で設定する必要がありますか？
標準インストール時には、省略値でShunsakuが設定します。
システム環境に合わせてパラメタ設定したい場合は、カスタマイズすることができます。
詳細は、“導入・運用ガイド”を参照してください。
- 91 -
インストール・セットアップ
A.3.2
サーバのIPアドレスを変更する場合、Shunsakuの設定は何を変更すればいいですか？
以下の場合で、操作手順が異なります。
・ Shunsakuの動作環境ファイルにIPアドレスを手動で設定している場合
・管理コンソールを使用している場合(V7.0系/V8.0系/V9.0系)
注意
すでにIPアドレスを変更してしまったときは、一度変更前の状態に戻してから以下の作
業を実施してください。
Shunsakuの動作環境ファイルにIPアドレスを手動で設定している場合
1. shunsysstopコマンドで、Shunsakuシステムを停止します。
2. 各動作環境ファイルのIPアドレスを変更します。
VL
V6.0系
V7.0系/V8.0系/V9.0系
動作環境ファイル名
パラメタ名
conductor用動作環境ファイル
SorterInfo
searcher用動作環境ファイル
DirSvrName
システム用動作環境ファイル
Conductor
Director
Sorter
Searcher
AlternativeSearcher
API用動作環境ファイル
Host
3. サーバのIPアドレスを変更します。
4. Shunsakuシステムを再起動します。
管理コンソールを使用している場合(V7.0系/V8.0系/V9.0系)
注意
すでにIPアドレスを変更してしまったときは、一度変更前の状態に戻してから以下の作業を実施してください。
1. 管理コンソールの[一括操作]タブより、Shunsakuシステムを停止します。
2. 管理コンソールの左フレームで[統合管理]タブを選択し、[Interstage Shunsaku Data Manager]を選択します。
3. 右フレームにサーバの一覧が表示されるので、IPアドレスを変更するサーバの左のチェックボックスにチェックを入れ
[削除]ボタンをクリックします。（削除するサーバのサーバ名をメモしておきます）
4. 管理コンソールからログアウトします。
5. サーバの IP アドレスを変更します。
6. Shunsakuの動作環境ファイルにIPアドレスを設定している場合のみ定義変更を行います。
7. Windowsのサービスコントロールパネルより[Interstage JServlet （OperationManagement)]サービスを再起動させま
す。
- 92 -
8. 付随するサービス(Interstage Operation Tool)の再起動についての問い合わせが出ますので「はい（Y）」を選択し
てください。
9. 管理コンソールに再度ログインし、管理コンソールの[統合管理]タブを選択し、[Interstage Shunsaku Data Manager]
をクリックします。
10. 右画面の[サーバ追加]タブを選択し、以下の情報を入力して、[追加]をクリックします。
－サーバ名：手順2でメモしたもの
－ IPアドレス：変更後のアドレス
－ユーザ名：Administrator
－パスワード：DirectorサーバのAdministratorのパスワード
11. 管理コンソールの[一括操作]タブより、Shunsakuシステムを再起動します。
Windows Defenderの警告について教えてください。
Windows Defenderが有効になっている場合、Shunsakuの標準インストールをすると、
Windows Defenderの履歴およびイベントビューアのシステムログに、以下のWindows
Defenderからのメッセージが出力されることがあります。
これは、Windows Defenderのリアルタイム保護エージェントがサービスのソフトウェアの
登録を監視しているためで、そのまま使用して問題ありません。
また、標準インストール中、およびカスタムインストール後のShunsakuサービスの登録時
に、Windows Defenderのアイコンがタスクバーの通知領域に表示されることがあります。
この場合、Windows Defenderを開き、「コンピュータの設定に対する変更を確認する」の
画面で、[操作を適用する]をクリックしてください。
・ Windows Defenderの履歴のメッセージ
このプログラムは、望ましくない動作をする可能性があります。
・イベントビューアのシステムログ
Windows Defenderリアルタイム保護エージェントで、変更が検出されました。これら
の変更を行ったソフトウェアに潜在的リスクがないか分析することをお勧めします。こ
れらのプログラムの動作方法に関する情報を使用して、これらのプログラムの実行を
許可するか、コンピュータから削除するかを選択できます。プログラムまたはソフトウェ
ア発行者を信頼できる場合のみ、変更を許可してください。Windows Defenderは許
可された変更を元に戻せません。
A.4 開発
開発時における、よくある質問とその回答について示します。
A.4.1
提供API
どのようなAPIが提供されていますか？
現在、以下の機能のAPIを提供しています。
・データの追加
・データの更新
・データの削除
・ヒット件数の取得
- 93 -
・検索結果の一覧の取得
・検索結果の詳細の取得
・検索結果のソートまたは集計
・トランザクションの有効・無効（自動／手動コミット、ロールバック）
・ヒット件数上限値の設定と解除
詳細については、“アプリケーション開発ガイド”およびShunsakuのAPIのリファレンスを
参照してください。
A.4.2
開発環境
使用可能な開発環境を教えてください。
特別な規定はありません。
以下のAPI種別に合った、いろいろなアプリケーション開発環境があります。
・ Java API
・ .NET API
・ C API
Shunsakuが対応するアプリケーション開発環境の詳細については、“インストールガイド”
の“アプリケーション開発環境の情報”を参照してください。
A.4.3
動作環境
ShunsakuのAPIを使用したアプリケーションは、Shunsakuがインストールされたマシン
で動作させる必要がありますか？
アプリケーションとShunsakuは、別サーバにも配置できます。
インストーラが用意されており、カスタムインストール時にAPIのみを選択しライブラリ
（ShunsakuのAPI）を配置することが可能です。
詳細については、“インストールガイド”を参照してください。
なお、インターネットを利用した接続形態では、外部の不正アクセスからデータを守るた
めに、Shunsaku、アプリケーションサーバおよびデータベースサーバはイントラネット内
に配置してください。
さらに、ファイアウォールにDMZという第3のネットワークを追加して、そのネットワークに
社外公開用のWebサーバを設置することにより、Webサーバをファイアウォールの管理
下に置き、不正アクセスを防止します。ファイアウォールを超えるアクセスは、アプリケー
ションサーバを経由した通信方法を採用します。また、ネットワーク上のデータ漏洩や改
ざんからデータを守るために、アプリケーションサーバより外部ではSSLなどの暗号化通
信を使用してください。
A.4.4
検索結果のデータ
検索結果データの順番は、どのように決まりますか？
ソート機能の利用により、特定の項目をキーに指定した順序（昇順／降順）で並びます。
ソート機能を利用しない場合には、以下の順序で並びます。
・ directorが1つの場合
Shunsakuに格納されている順序で並びます。
・ directorが複数の場合
- 94 -
1つのdirector内のデータは、Shunsakuに格納されている順序で並びます。director
番号が指定されている場合は、番号の昇順に並びます。
StartPointパラメタが指定されている場合は、その順に並びます。
なお、DomainやFileに対する検索の場合は、返信順序が保証できませんので、ソー
ト式の指定を推奨します。
詳細は、“導入・運用ガイド”を参照してください。
検索結果をXML形式でブラウザに表示することは可能ですか？
以下のような開始タグから終了タグまでの値をそのまま取り出すことができるXML文書取
出し用のリターン式が用意されています。
ブラウザに表示する場合は、XML宣言を付加する処理をアプリケーション側で行うことで
1件ごとの表示が可能です。
<doc>
<employee>
<eno>123456789</eno>
<name>富士通太郎</name>
<sno>1001</sno>
<phone>1234-5678</phone>
</employee>
</doc>
詳細については、“アプリケーション開発ガイド”を参照してください。
A.4.5
検索式
全件検索式と、前方一致検索式(条件なし)の2つの式を論理積で指定して検索をしまし
た。結果として全件ヒットとなり、前方一致が効いてないようですが、正しいですか？
正しいです。前方一致、後方一致の記号（^、$）のみを条件式に指定した場合、“前方一
致かつ条件なし”あるいは“後方一致かつ条件なし”の検索を行います。この際の検索
の仕様は、一般的な正規表現と同様に全件ヒットする仕組みになっています。
なお、Shunsakuの場合はXML形式のデータを対象としますので、検索対象のタグも意
識する必要があり、検索対象のタグが存在する文章がすべてヒットする仕様になってい
ます。
空文字('')検索について教えてください。
Shunsakuでは、XML形式のデータを取り扱うため、空要素という取り扱いになり、以下の
いずれかのように動作します。
・「== ''」 (完全一致の空文字)
「空要素のタグ」への検索になります。
<aaa></aaa>という空要素の文書がヒットします。
例)
検索式
/doc/detail/taxi == ''
/doc/detail/taxiが示す要素ノードの値が空文字と等しい場合に真となります。
・「= ''」
空要素がタグの要素の一部である状態は存在しません。
- 95 -
<aaa></aaa>という文書はヒットしません。
検索式に"/root = 'X & ( A & B | C )'"と記述する(制御記号間に空白を含める)とエラー
になりますが、これは正しい結果でしょうか？
正しい結果ではありません。条件式中のキーワードは、無用な空白やタブ文字を含まな
いように指定してください。
キーワードに、二重引用符(" ")や引用符(' ')で囲った部分に空白を指定した場合、
Shunsakuではその空白も検索対象として扱います。
アプリケーションソースを見やすくするなどのために空白を入れることは、本来の意図し
た検索と異なった検索を実行することになります。
A.4.6
リターン式
複数のリターン項目を取得した場合に返却されるリターン項目の区切り文字を変更でき
るようにする予定はありますか？
区切り文字を変更可能にする予定はありません。
なお、Java APIまたは.NET APIの場合には、以下のメソッドを利用することで、区切り文
字を意識する必要がなくなります。
・ Java APIの場合
getStringArrayメソッドにより、リターン項目単位のStringの2次元配列を取得できま
す。
・ .NET APIの場合
getDividedDataメソッドにより、リターン項目単位のStringのジャグ配列を取得できま
す。
A.4.7
サンプル
ShunsakuのAPIで検索画面を作る場合のサンプルソースはありますか。
パッケージ内にサンプルソースは含まれていません。
なお、マニュアルには、APIの使用例として、サンプルソースが記載されています。この
サンプルソースをそのままコピーして、アプリケーションプログラムとすることができます。
詳細については、“アプリケーション開発ガイド”を参照してください。
A.5 運用
運用時における、よくある質問とその回答について示します。
A.5.1
データ取込み／取出し
データの格納方法にどのようなものがありますか？
データを格納するためのコマンド（shundimport）を用意しています。
また、アプリケーションからAPIによって追加・削除といったデータ操作も可能です。
Shunsakuに格納されているXMLデータを外部へ抽出する機能はありますか？
shundexportコマンドを利用することで、XML文書を外部ファイルへ抽出できます。
詳細は、“コマンドリファレンス”を参照してください。
なお、Shunsakuに対して全件レコードがヒットする条件を指定し、その結果を出力するア
プリケーションを別途作成することもできます。
- 96 -
A.6 保守
保守時における、よくある質問とその回答について示します。
A.6.1
モニタリング
Shunsakuのメッセージは、Systemwalkerで監視可能ですか？
一般的なアプリケーションメッセージと同等レベルで監視可能です。
メッセージの出力形式については、“メッセージ集”を参照してください。
システムログや動作ログにshn04000eのメッセージが出力されていますが、運用に影響
はありますか？
本メッセージが単独で出力されている場合は、運用上の支障はありません。
本メッセージと同一時間帯に、エラーを示すメッセージ(shnXXXXXu)が出力されている
場合は、このエラー原因を取り除いてください。
A.6.2
バックアップ／リカバリ
バックアップ／リカバリ時にサービスを停止する必要はありますか？
shundbackupコマンドを使用したバックアップ時には、サービスを停止する必要はありま
せん。
ただし、オペレーションログファイルを使用した運用でない場合は、バックアップ中は、ア
プリケーションからの更新操作（データの追加、削除、または更新）はエラーとなり、実行
することはできません。
shundrecoverコマンドを使用したリカバリ時には、サービスを停止する必要があります。ま
た、バックアップ中、またはリカバリ中は、以下のコマンドを実行することはできません。
[バックアップ中]
・ shundbackupコマンドによるバックアップ開始宣言
[リカバリ中]
・ shundrecoverコマンドによるリカバリ開始宣言
[共通]
・ shundcdsコマンド
・ shundclearコマンド
・ shundexportコマンド
・ shundimportコマンド
・ shundrecoverコマンド
・ shundresendコマンド
・ shundrestrictコマンド
・ shunsyscfgeditコマンド
・ shunsysstartコマンド
・ shunsysstopコマンド
バックアップ／リカバリの詳細については、“導入・運用ガイド”の“バックアップ・リカバリ”
を参照してください。また、コマンド間およびアプリケーションとの競合関係について
は、“導入・運用ガイド”の“競合関係”を参照してください。
- 97 -
A.6.3
サーバ構成変更
directorを新規追加する場合の手順について教えてください。
新たなdirectorを起動する場合の作業手順は、以下のとおりです。
1. 新規追加するdirectorおよびsearcherのセットアップを行います。
セットアップ方法については、“インストールガイド”の“ディレクタサーバ増設時の
インストールおよびセットアップ”を参照してください。
2. conductorを配置しているディレクタサーバでシステム用動作環境ファイルを編集
し、全サーバに配布します。編集時に追加する実行パラメタには、以下のものがあ
ります。
－新しいsearcher用のSearcherパラメタ
－新しいdirector用のDirectorパラメタ
3. サーチサーバおよびディレクタサーバ上でshunsysstartコマンドを実行し、searcher
およびdirectorを起動します。
4. Shunsaku Fileを使用している場合、conductorを配置しているディレクタサーバで
conductor用動作環境ファイルを編集します。編集時に追加する実行パラメタに
は、以下のものがあります。
－ File
－ Domain
－ InsertPoint
5.
conductorを配置しているディレクタサーバ上でshunsyscfgeditコマンドを実行
します。
6.
shundserviceコマンドを実行し、directorをサービスに登録します。
コマンドの詳細は、“コマンドリファレンス”を参照してください。
directorの追加方法の詳細は、“導入・運用ガイド”の“directorの追加およびディレクタ
サーバの増設”を参照してください。
注意
同一サーバ内でdirectorやsearcherを追加する場合、メモリ使用量などを再度見積り、
サーバの資源が十分足りていることを確認してください。
A.6.4
縮退
サーチサーバがハードウェア障害でダウンした際に数十秒間検索を受け付けなくなりま
す。回避方法を教えてください。
ハードウェア異常時の仕様で、縮退による自動復旧が作動しています。
縮退とは、異常が発生したsearcherのサーチデータを残りのsearcherに配布する機能で
す。ただし、縮退中はデータの検索および更新操作（追加・更新・削除）はできません。
縮退が完了したあと、運用を継続することができます。
ハードウェア異常時の縮退処理は、回避できません。
- 98 -
縮退の基本的な動作は、以下のとおりです。
・ハードウェア障害でサーチサーバがダウンした場合
検索時にタイムアウトが発生するまで待ち状態となり、タイムアウト後、縮退を開始し
ます。
タイムアウト時間は、director用動作環境ファイルのSearcherWTimerパラメタで設定
された値で、標準では180秒です。
・ソフトウェア異常でsearcherのダウンを検出できる場合
検索時に即時にエラー復帰し、縮退を開始します。
なお、代替searcherによるフェイルオーバ運用を行っている場合、上記のどちらの場合に
も、まず、代替searcherへの切替えが行われます。
代替searcherが存在しない、または、代替searcherへの切替えに失敗した場合には、縮
退が開始します。
縮退および代替searcherによるフェイルオーバ運用については、“導入・運用ガイド”
の“サーチサーバのフェイルオーバ機能”を参照してください。
A.7 連携
連携時における、よくある質問とその回答について示します。
A.7.1
データベース連携
既存のRDBMSと連携して使う場合、どんな方式がありますか？
既存のRDBMSからデータを抽出し、ShunsakuでXMLデータを運用するシステムを構築
します。抽出元がSymfowareデータベースの場合には、Symfoware Serverとの連携機能
（shunrdbコマンド）を使って、簡単にデータ抽出ができます。
データベース連携機能については、“データベース連携ガイド”を参照してください。
RDBから差分を抽出し、Shunsakuに反映することは可能ですか？
Symfoware Serverとの連携機能を使用すれば可能です。
この場合、差分の単位は1XML文書となり、要素（タグ）単位での反映はできません。
連携可能なSymfoware Serverについては、“インストールガイド”を参照してください。
- 99 -
索　引
トラブル対処の事例.................................................................23
トラブルの切分けと対処.............................................................2
トラブルの種類...........................................................................1
[A]
APIスナップのログ...................................................................69
[C]
coreスタックトレース..................................................................72
[は]
ハングアップ...............................................................................1
ハングアップ時の資料採取.....................................................75
ハングアップ状態の確認と対処................................................4
必須資料の採取方法..............................................................62
フェイルオーバ...........................................................................1
フェイルオーバ関連の異常への対処.....................................20
プロセス情報............................................................................77
プロセスダウン............................................................................1
プロセスダウン時の資料採取..................................................70
プロセスダウンの確認と対処.....................................................3
プロセスダンプ.........................................................................76
[M]
mapファイル..............................................................................72
[S]
searcherのフェイルオーバからの復旧.....................................20
Shunsakuシステムの復旧...........................................................7
[X]
XMLデータ..............................................................................70
[あ]
アプリケーションソース.............................................................69
アプリケーションを配置したサーバがダウンした場合の対処.....
8
異常状態からの復旧手順..........................................................7
異常の検出と運用への影響......................................................2
運用時の異常..........................................................................28
エラー.........................................................................................1
エラー事象の確認と対処...........................................................2
オペレーションログファイル......................................................71
[ま]
文字ばけ...................................................................................25
[ら]
リカバリ時の異常......................................................................43
利用者の操作記録..................................................................67
ロードモジュール......................................................................72
[か]
開発時の異常..........................................................................24
共用ディスク障害時の復旧.....................................................20
検索式、リターン式、ソート式..................................................68
コアファイル..............................................................................74
コマンド実行中にサーバがダウンした場合の対応...................9
[さ]
サーチデータファイル..............................................................71
シェルスクリプトまたはバッチ...................................................70
事象共通資料の採取方法......................................................68
システムログ/イベントログ.........................................................67
集計結果の異常......................................................................25
縮退からの復旧........................................................................22
処理結果異常............................................................................1
処理結果異常の確認と対処......................................................3
資料の種類..............................................................................61
事例一覧..................................................................................23
性能問題....................................................................................1
性能問題時の資料採取..........................................................78
性能問題時の対処..................................................................16
性能問題の確認と対処..............................................................5
性能ログファイル......................................................................65
[た]
調査資料の採取......................................................................61
ディレクタデータファイル..........................................................71
動作環境ファイル.....................................................................62
動作ログファイル......................................................................64
トラブル対処の概要...................................................................1
- 100 -

Download Report