The Road to Genecialist!

Windows Server 2008のバックアップ・リカバリ～その一　バックアップで取得したバックアップファイルを使って、新しくサーバーをリカバリしてみます。

最初は全く同じサーバーに戻すことを想定した同じサイズのHDDに戻すパターンです。ちなみに500GBのHDDでデータが10GBしかなくても復元先HDDは最低500GB用意しなければならないのです。

新しくVMを作り(HDDは元のサーバーと同様15GB)、バックアップファイルが保管されているHDDを接続します。
Windows Server 2008のインストールDVDを読み込ませ、インストールを開始する。

言語設定はそのまま「次へ」をクリックし


「今すぐインストール」ではなく「コンピュータを修復する」をクリックする。


「システム回復オプション」ではすでにOSがインストールされていればインストールされているOS名が表示されますが、今回はまっさらなサーバーを使用するので空欄になっています。
「次へ」をクリックします。


回復ツールの選択で「Windows Complete PC復元」をクリックします。


すると、接続されているHDD等のメディアから最新のバックアップが自動的に読み込まれ、データ情報が表示されますので確認して「次へ」をクリック。
必要であれば「特定のバックアップを復元する」を選択します。


バックアップの復元方法の選択ですが、バックアップからリカバリするHDDはフォーマットされてしまうのでそれを避ける設定や、リカバリ終了後に自動で再起動するよう設定などができます。「次へ」をクリック。


リカバリの設定確認で間違いがないかを確かめたら「完了」をクリックしてリカバリをスタートします。


リカバリ対象HDDはフォーマットされてしまうのでメッセージが出てきます。チェックを入れて「OK」をクリック。


リカバリが始まりました。


リカバリが終了したので自動的に再起動となりました。


再起動後のサーバーマネージャです。フルコンピュータ名など、バックアップ元の設定と変わりありません。ネットワークだけは「ローカルエリア接続2」だったのが「ローカルエリア接続3」になり、DHCPでの接続になっていました。どうしても同じにならない部分はどれくらいあるのだろうか？


インストール済みの機能もそのままです。


バックアップをとる前の状態をバックアップしたので、バックアップは初期状態です。


容量の小さいHDDでの作業だったので10分強で終了しました。

DB2のバックアップ・リカバリを勉強し始めました（DB2のバックアップ・リカバリ）。

同じジャンルを様々な製品で一気に勉強してみようと思いました。まずはWindows Server 2008でのバックアップとリカバリ。

バックアップは標準のウィザードを利用してHDDにとり、
リカバリは下記三パターンを試してみる。
１．同じサイズのHDDに戻すパターン
２．大きいHDDに戻すパターン
３．小さいHDDに戻すパターン（失敗パターン）

テスト機の構成は下記の通り。
フルコンピューター名：ADC-2008-1
ワークグループ：VM-SERVERS1
ローカルエリア接続2：192.168.0.13, IPv6(有効)
HDD：15GB(サーバーのインストールをしただけの状態)

それではまずバックアップの取得から。

サーバーマネージャーを開き、


左ペインから「記憶域」→「Windows Serverバックアップ」を選択。


バックアップの機能をインストールしていなかったために、使用できない状態でした。ですので一度、左ペインの「機能」へ移動し、インストールします。


「機能の追加」をクリックすれば「機能の追加ウィザード」が表示されますので「Windows Server バックアップの機能」を選択します（今回はコマンドラインでの実行はしないので「コマンドラインツール」は未選択のままにしました）。


インストール確認画面が出て、「インストール」ボタンをクリックすればインストールが始まります（Windows Server 2008からは、追加インストールする際にインストールDVDを使わなくてすむようになったのでとても便利。その分Diskを喰いますが）。



機能の画面で「Windows Server バックアップの機能」がインストールされていることが確認できます。


改めて「Windows Serverバックアップ」へ移動すると今度は正しく情報表示画面になりました。まだ一度もバックアップを取得していないので情報は何も表示されません。


右ペインの「バックアップ(1回限り)」をクリックしてウィザードを開きます。


1回限りのバックアップなので「別のオプション」しか選ぶことができません。


バックアップの構成の選択では「サーバー全体」か「カスタム」の二種類のバックアップを選べます。今回はサーバーに接続しているHDDへのバックアップを行うので「カスタム」を選びました。


「ボリューム(E:)」がバックアップ先なのでバックアップ対象からは除外します。


バックアップ先を選択します。今回はローカルドライブです。


ローカルドライブが複数存在する場合には選択できるようになっています。「ボリューム(E:)」を選択。


シャドーコピーのデータについてのバックアップオプションを選択します。今回はWindows標準のリカバリーをするので「VSSの完全バックアップ」を選択。


最後に確認画面が表示されるので間違いがないかを確かめて「バックアップ」ボタンをクリック。バックアップが開始します。


バックアップが始まると「バックアップの進行状況」ウィンドウが表示されます。下の写真は完了後ですが、進行状況がリアルタイムに表示されます。このウィンドウは閉じることができますが、同じ情報が「Windows Serverバックアップ」の画面にも表示されます。


バックアップの実績ができるとバックアップの情報が表示されるようになります（「最新のバックアップ」「すべてのバックアップ」）。


バックアップ先のディレクトリを見てみると、XMLでの設定ファイルとともにVHDファイルが保存されていることがわかります。15GBのHDD容量ですが、使用済みは7GBほどなのでバックアップファイルのサイズも7GBほどとなっています。


次はこのファイルを使って新しいサーバーを作ってみたいと思います。

ntp_config.cのソースファイルを見ていたら、"maxpoll: provided value (%d) is above maximum (%d)"というメッセージがあった。

maxpollの最大値は16とされているので、ntp.conf内で"maxpoll 20"と設定をするとエラーメッセージが出力されると思ってテストした。
開発1号機：ntp-4.1.2-4.EL3.1
開発2号機：ntp-4.2.0.a.20040617-4.EL4.1

試みその一

試してみました。"maxpoll 20"で。

結果(1号機)：
ntpd.log
"
15 Sep 12:57:51 ntpd[31704]: running as uid(38)/gid(38) euid(38)/egid(38).
15 Sep 12:57:51 ntpd[31704]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)
15 Sep 12:57:53 ntpd[31704]: peer 123.456.789.098 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
15 Sep 12:58:06 ntpd[31704]: peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
15 Sep 12:59:00 ntpd[31704]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_ntp, 2 events, event_restart' (0xc621)
15 Sep 12:59:00 ntpd[31704]: kernel time discipline status change 41
15 Sep 12:59:00 ntpd[31704]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_ntp, 3 events, event_peer/strat_chg' (0x634)
15 Sep 12:59:00 ntpd[31704]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_ntp, 4 events, event_sync_chg' (0x643)
15 Sep 12:59:34 ntpd[31704]: kernel time discipline status change 1
15 Sep 13:57:50 ntpd[31704]: offset 0.000048 sec freq 7.999 ppm error 0.000052 poll 4
15 Sep 14:57:51 ntpd[31704]: offset -0.000238 sec freq 9.235 ppm error 0.000054 poll 5
15 Sep 15:57:51 ntpd[31704]: offset 0.000064 sec freq 8.666 ppm error 0.000020 poll 6
15 Sep 16:57:51 ntpd[31704]: offset -0.000692 sec freq 8.988 ppm error 0.002022 poll 7
15 Sep 17:57:51 ntpd[31704]: offset -0.000660 sec freq 8.863 ppm error 0.000429 poll 10
15 Sep 18:57:51 ntpd[31704]: offset -0.000444 sec freq 8.859 ppm error 0.000740 poll 11
15 Sep 19:36:13 ntpd[31704]: kernel time discipline status change 9
15 Sep 19:57:51 ntpd[31704]: offset -0.008352 sec freq 8.179 ppm error 0.003542 poll 11
15 Sep 20:57:51 ntpd[31704]: offset 0.002172 sec freq 8.547 ppm error 0.004831 poll 12
15 Sep 21:57:51 ntpd[31704]: offset 0.000417 sec freq 8.598 ppm error 0.004275 poll 12
15 Sep 22:57:51 ntpd[31704]: offset 0.000660 sec freq 8.638 ppm error 0.003704 poll 12
15 Sep 23:57:51 ntpd[31704]: offset -0.000731 sec freq 8.594 ppm error 0.003282 poll 13
16 Sep 00:57:51 ntpd[31704]: offset -0.000750 sec freq 8.548 ppm error 0.002843 poll 13
16 Sep 01:57:51 ntpd[31704]: offset -0.000750 sec freq 8.548 ppm error 0.002843 poll 13
16 Sep 02:57:51 ntpd[31704]: offset -0.000750 sec freq 8.548 ppm error 0.002843 poll 13
16 Sep 03:57:51 ntpd[31704]: offset -0.008941 sec freq 8.275 ppm error 0.004778 poll 13
16 Sep 04:57:51 ntpd[31704]: offset -0.008941 sec freq 8.275 ppm error 0.004778 poll 13
16 Sep 05:57:51 ntpd[31704]: offset 0.004730 sec freq 8.419 ppm error 0.007990 poll 14
16 Sep 06:57:51 ntpd[31704]: offset 0.004730 sec freq 8.419 ppm error 0.007990 poll 14
16 Sep 07:57:51 ntpd[31704]: offset -0.000711 sec freq 8.397 ppm error 0.007436 poll 14
16 Sep 08:57:51 ntpd[31704]: offset -0.000711 sec freq 8.397 ppm error 0.007436 poll 14
16 Sep 09:57:51 ntpd[31704]: offset -0.000711 sec freq 8.397 ppm error 0.007436 poll 14
16 Sep 10:57:51 ntpd[31704]: offset -0.000711 sec freq 8.397 ppm error 0.007436 poll 14
16 Sep 11:57:51 ntpd[31704]: offset -0.000711 sec freq 8.397 ppm error 0.007436 poll 14
16 Sep 12:57:51 ntpd[31704]: offset -0.005281 sec freq 8.317 ppm error 0.006833 poll 14
16 Sep 13:57:51 ntpd[31704]: offset -0.005281 sec freq 8.317 ppm error 0.006833 poll 14
16 Sep 14:57:51 ntpd[31704]: offset -0.005281 sec freq 8.317 ppm error 0.006833 poll 14
16 Sep 15:57:51 ntpd[31704]: offset -0.005281 sec freq 8.317 ppm error 0.006833 poll 14
16 Sep 16:57:51 ntpd[31704]: offset 0.011501 sec freq 8.492 ppm error 0.010268 poll 15
16 Sep 17:57:51 ntpd[31704]: offset 0.011501 sec freq 8.492 ppm error 0.010268 poll 15

～中略～

17 Sep 13:57:52 ntpd[31704]: offset -0.001231 sec freq 8.443 ppm error 0.009870 poll 15
17 Sep 14:57:52 ntpd[31704]: offset -0.001231 sec freq 8.443 ppm error 0.009870 poll 15
17 Sep 15:57:52 ntpd[31704]: offset -0.004637 sec freq 8.407 ppm error 0.008715 poll 16
17 Sep 16:57:52 ntpd[31704]: offset -0.004637 sec freq 8.407 ppm error 0.008715 poll 16

～中略～

18 Sep 16:57:53 ntpd[31704]: offset -0.001362 sec freq 8.397 ppm error 0.007723 poll 16
18 Sep 17:57:53 ntpd[31704]: offset -0.001362 sec freq 8.397 ppm error 0.007723 poll 16
18 Sep 18:57:53 ntpd[31704]: offset 0.000106 sec freq 8.397 ppm error 0.006729 poll 17
18 Sep 19:57:53 ntpd[31704]: offset 0.000106 sec freq 8.397 ppm error 0.006729 poll 17

～中略～

19 Sep 10:57:53 ntpd[31704]: offset 0.000106 sec freq 8.397 ppm error 0.006729 poll 17
19 Sep 11:57:53 ntpd[31704]: offset 0.000106 sec freq 8.397 ppm error 0.006729 poll 17
19 Sep 12:57:53 ntpd[31704]: offset -0.002818 sec freq 8.386 ppm error 0.006008 poll 16
19 Sep 13:57:53 ntpd[31704]: offset -0.002818 sec freq 8.386 ppm error 0.006008 poll 16

～中略～

21 Sep 17:57:55 ntpd[31704]: offset 0.004329 sec freq 8.395 ppm error 0.006312 poll 16
21 Sep 18:57:55 ntpd[31704]: offset 0.004329 sec freq 8.395 ppm error 0.006312 poll 16
21 Sep 19:57:55 ntpd[31704]: offset 0.000772 sec freq 8.398 ppm error 0.005748 poll 17
21 Sep 20:57:55 ntpd[31704]: offset 0.000772 sec freq 8.398 ppm error 0.005748 poll 17

～中略～

22 Sep 11:57:56 ntpd[31704]: offset 0.000772 sec freq 8.398 ppm error 0.005748 poll 17
22 Sep 12:57:56 ntpd[31704]: offset 0.000772 sec freq 8.398 ppm error 0.005748 poll 17
22 Sep 13:57:56 ntpd[31704]: offset -0.004090 sec freq 8.382 ppm error 0.005540 poll 16
22 Sep 14:57:56 ntpd[31704]: offset -0.004090 sec freq 8.382 ppm error 0.005540 poll 16

～中略～

23 Sep 21:57:57 ntpd[31704]: offset -0.004090 sec freq 8.382 ppm error 0.005540 poll 16
23 Sep 22:57:57 ntpd[31704]: offset -0.004090 sec freq 8.382 ppm error 0.005540 poll 16
23 Sep 23:33:31 ntpd[31704]: kernel time discipline status change 1
23 Sep 23:57:57 ntpd[31704]: offset 0.000000 sec freq 8.382 ppm error 0.000203 poll 6
24 Sep 00:57:57 ntpd[31704]: offset 0.000000 sec freq 8.382 ppm error 0.000005 poll 6
24 Sep 01:57:57 ntpd[31704]: offset 0.000000 sec freq 8.382 ppm error 0.000005 poll 6
24 Sep 02:57:57 ntpd[31704]: offset 0.000624 sec freq 7.146 ppm error 0.000218 poll 9
24 Sep 03:57:57 ntpd[31704]: offset 0.003131 sec freq 7.178 ppm error 0.000655 poll 10
24 Sep 04:57:57 ntpd[31704]: offset 0.004188 sec freq 7.312 ppm error 0.000528 poll 8
24 Sep 05:57:57 ntpd[31704]: offset 0.000421 sec freq 8.024 ppm error 0.000102 poll 9
24 Sep 06:57:57 ntpd[31704]: offset 0.000054 sec freq 8.189 ppm error 0.000016 poll 6
24 Sep 07:57:57 ntpd[31704]: offset 0.000132 sec freq 8.311 ppm error 0.000022 poll 7
24 Sep 08:57:57 ntpd[31704]: offset -0.000058 sec freq 8.335 ppm error 0.001162 poll 9
"

ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*123.456.789.098 123.456.789.1    2 u  429  512  377    0.135   -0.022   0.028

 LOCAL(0)        LOCAL(0)        11 l   41   64  377    0.000    0.000   0.004

なぜ途中でpolling 16から6に戻ってしまったのかはこのログからだと不明です。"kernel time discipline status change 1"はntpデーモンを起動したときにも出てくるメッセージなので、もしかしたら途中でデーモンが落ちた？？謎です。

そもそも期待していたエラーが出なかったのが残念でした。

結果(2号機)：
ntpd.log
"
15 Sep 12:57:23 ntpd[20341]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)
15 Sep 12:57:24 ntpd[20341]: peer 123.456.789.098 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
15 Sep 12:57:25 ntpd[20341]: peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
15 Sep 13:00:09 ntpd[20341]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_ntp, 2 events, event_restart' (0xc621)
15 Sep 13:00:09 ntpd[20341]: synchronized to 123.456.789.098, stratum 2
15 Sep 13:00:09 ntpd[20341]: kernel time sync disabled 0041
15 Sep 13:00:09 ntpd[20341]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_ntp, 3 events, event_peer/strat_chg' (0x634)
15 Sep 13:00:09 ntpd[20341]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_ntp, 4 events, event_sync_chg' (0x643)
15 Sep 13:01:14 ntpd[20341]: kernel time sync enabled 0001
15 Sep 13:57:26 ntpd[20341]: offset 0.000076 sec freq -10.358 ppm error 0.000500 poll 7
15 Sep 14:57:29 ntpd[20341]: offset 0.001830 sec freq -10.103 ppm error 0.000667 poll 8
15 Sep 15:57:32 ntpd[20341]: offset 0.000819 sec freq -10.060 ppm error 0.000518 poll 9
15 Sep 16:57:35 ntpd[20341]: offset 0.003252 sec freq -10.038 ppm error 0.001683 poll 10
15 Sep 17:16:59 ntpd[20341]: kernel time sync enabled 0009
15 Sep 17:57:38 ntpd[20341]: offset 0.000493 sec freq -9.740 ppm error 0.000456 poll 11
15 Sep 18:57:41 ntpd[20341]: offset 0.001259 sec freq -9.586 ppm error 0.000766 poll 12
15 Sep 19:57:44 ntpd[20341]: offset -0.007421 sec freq -10.491 ppm error 0.008680 poll 12
15 Sep 20:57:48 ntpd[20341]: offset 0.001426 sec freq -10.404 ppm error 0.008847 poll 12
15 Sep 21:57:51 ntpd[20341]: offset 0.005827 sec freq -10.049 ppm error 0.004401 poll 13
15 Sep 22:57:54 ntpd[20341]: offset 0.000494 sec freq -10.019 ppm error 0.005333 poll 13
15 Sep 23:57:57 ntpd[20341]: offset 0.000494 sec freq -10.019 ppm error 0.005333 poll 13
16 Sep 00:58:00 ntpd[20341]: offset 0.000733 sec freq -9.997 ppm error 0.000239 poll 13
16 Sep 01:58:03 ntpd[20341]: offset 0.000733 sec freq -9.997 ppm error 0.000239 poll 13
16 Sep 02:58:06 ntpd[20341]: offset -0.007565 sec freq -10.227 ppm error 0.008298 poll 14
16 Sep 03:58:09 ntpd[20341]: offset -0.007565 sec freq -10.227 ppm error 0.008298 poll 14
16 Sep 04:58:12 ntpd[20341]: offset -0.007565 sec freq -10.227 ppm error 0.008298 poll 14
16 Sep 05:58:15 ntpd[20341]: offset 0.006732 sec freq -10.022 ppm error 0.014298 poll 14
16 Sep 06:58:18 ntpd[20341]: offset 0.006732 sec freq -10.022 ppm error 0.014298 poll 14
16 Sep 07:58:21 ntpd[20341]: offset 0.006732 sec freq -10.022 ppm error 0.014298 poll 14
16 Sep 08:58:24 ntpd[20341]: offset 0.006732 sec freq -10.022 ppm error 0.014298 poll 14
16 Sep 09:58:27 ntpd[20341]: offset 0.001910 sec freq -9.993 ppm error 0.004822 poll 14
16 Sep 10:58:30 ntpd[20341]: offset 0.001910 sec freq -9.993 ppm error 0.004822 poll 14
16 Sep 11:58:33 ntpd[20341]: offset 0.001910 sec freq -9.993 ppm error 0.004822 poll 14
16 Sep 12:58:36 ntpd[20341]: offset 0.001910 sec freq -9.993 ppm error 0.004822 poll 14
16 Sep 13:58:39 ntpd[20341]: offset 0.001910 sec freq -9.993 ppm error 0.004822 poll 14
16 Sep 14:58:42 ntpd[20341]: offset -0.000757 sec freq -10.004 ppm error 0.002667 poll 15
16 Sep 15:58:45 ntpd[20341]: offset -0.000757 sec freq -10.004 ppm error 0.002667 poll 15

～中略～

17 Sep 11:59:45 ntpd[20341]: offset 0.029060 sec freq -9.779 ppm error 0.028832 poll 15
17 Sep 12:59:48 ntpd[20341]: offset 0.029060 sec freq -9.779 ppm error 0.028832 poll 15
17 Sep 13:59:52 ntpd[20341]: offset 0.019983 sec freq -9.627 ppm error 0.009077 poll 16
17 Sep 14:59:55 ntpd[20341]: offset 0.019983 sec freq -9.627 ppm error 0.009077 poll 16

～中略～

18 Sep 15:01:07 ntpd[20341]: offset 0.021678 sec freq -9.462 ppm error 0.001695 poll 16
18 Sep 16:01:10 ntpd[20341]: offset 0.021678 sec freq -9.462 ppm error 0.001695 poll 16
18 Sep 17:01:13 ntpd[20341]: offset 0.001315 sec freq -9.457 ppm error 0.020363 poll 17
18 Sep 18:01:16 ntpd[20341]: offset 0.001315 sec freq -9.457 ppm error 0.020363 poll 17

～中略～

24 Sep 08:08:02 ntpd[20341]: offset 0.096578 sec freq -9.175 ppm error 0.051412 poll 17
24 Sep 09:08:05 ntpd[20341]: offset 0.096578 sec freq -9.175 ppm error 0.051412 poll 17
"

ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*123.456.789.098 123.456.789.1    2 u   9h  36h  377    1.188   96.578  51.412

 LOCAL(0)        LOCAL(0)        10 l   64   64  377    0.000    0.000   0.004

1号機とは違い、こちらはずっと安定してpolling 17となっています。polling 16から17になるまでに丸一日。polling 17になってからすでに五日半経っているのにまだ18にならない。
でも、36時間に一度の時刻調整でも数十ミリ秒のずれなんだからなかなかすごいと思う（開発サーバーで今回の実験中ほとんど無負荷だったのも影響しているだろうが）。

こちらのサーバーでも期待していたエラーは出力されませんでした。何かテストの仕方が間違っているのかも・・・


試みその二

ついでなので、maxpollとminpollの値が逆になるようにも設定してみました。"minpoll 14 maxpoll 10"で。
こちらは結果が出るのがとても早かったです。

結果(開発1号機)：
ntpd.log
"
14 Sep 13:27:34 ntpd[16798]: running as uid(38)/gid(38) euid(38)/egid(38).
14 Sep 13:27:34 ntpd[16798]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)
14 Sep 13:27:43 ntpd[16798]: peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
14 Sep 13:30:55 ntpd[16798]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_local_proto, 2 events, event_restart' (0xc521)
14 Sep 13:30:55 ntpd[16798]: kernel time discipline status change 41
14 Sep 13:30:55 ntpd[16798]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_local_proto, 3 events, event_peer/strat_chg' (0x534)
14 Sep 13:30:55 ntpd[16798]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_local_proto, 4 events, event_sync_chg' (0x543)
14 Sep 13:31:58 ntpd[16798]: kernel time discipline status change 1
14 Sep 14:27:34 ntpd[16798]: offset 0.000000 sec freq 8.386 ppm error 0.000011 poll 6
"
ntpq -p

# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*LOCAL(0)        LOCAL(0)        11 l    4   64  377    0.000    0.000   0.008

結果(開発2号機)：
ntpd.log
"
15 Sep 09:41:59 ntpd[19023]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)
15 Sep 09:42:00 ntpd[19023]: peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
15 Sep 09:45:14 ntpd[19023]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_local_proto, 2 events, event_restart' (0xc521)
15 Sep 09:45:14 ntpd[19023]: synchronized to LOCAL(0), stratum 10
15 Sep 09:45:14 ntpd[19023]: kernel time sync disabled 0041
15 Sep 09:45:14 ntpd[19023]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_local_proto, 3 events, event_peer/strat_chg' (0x534)
15 Sep 09:45:14 ntpd[19023]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_local_proto, 4 events, event_sync_chg' (0x543)
15 Sep 09:46:20 ntpd[19023]: kernel time sync enabled 0001
"

ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*LOCAL(0)        LOCAL(0)        10 l    5   64  377    0.000    0.000   0.004

エラーログは出力されなかったけれども、指定した時刻サーバーとは同期されませんでした。どうやら、minpollがmaxpollを上回る設定になっていると、時刻同期サーバーはLOCALとして動くようです（その他設定が間違っているときもそうなるのかはまた別の機会に調べます）。

前回（DB2のインストール ）新しくDB2をインストールしましたので、早速バックアップとリカバリコマンドを使ってみたいと思います。

まずは現状の確認を。データベース全体を見ていくと大変なので、"staff"テーブルを対象としていきます。

テーブルの設計については"DESCRIBE TABLE table_name"で確認することができます。


中身については全件選択してみましょう。"SELECT * FROM STAFF"
35レコードあります。


では、データベースのバックアップです。"BACKUP DATABASE SAMPLE TO backup_directory"


バックアップファイルはコマンドに指定したフォルダーに作成されます。


今回は下記のファイル名で作成されました。
"SAMPLE.0.DB2.NODE0000.CATN0000.20090923183402.001"

ファイル名の意味は下記の通りになります。
Alias.Type.Instance.Node.Catalogue.YYYYMMDDHHMMSS.Sequence
<IBM Developer Worksの「IBM DB2 UDBとOracleのバックアップおよびリカバリーの比較: 第 1 回」を参照>

それでは、どきどきしながらも、サクッとテーブルを消します。
"DROP TABLE STAFF"


ちゃんと消えてます。


消えました・・・

でも、バックアップをとっているので安心です。すかさずテーブルを復旧してみましょう。

"RECOVERY DATABASE SAMPLE TO END OF LOGS"


SQLエラーが出たのでInformation Centerを見てみた。
「
SQL1260N

データベース name は、ノード node-list でのロールフォワード・リカバリー用に構成されていません。

説明
指定されたデータベースは指定されたノードで、ロールフォワード・リカバリー用に構成されません。 ",..." がノード・リストの終わりに表示されている場合、ノードの完全なリストを見るには管理通知ログを調べてください。

データベースは指定のノードでロールフォワードされません。

(注: パーティション・データベース・サーバーを使用している場合、 ノード番号は、エラーの発生しているノードを示しています。 そうでない場合、これは関係のないものなので無視してください。)

ユーザーの処置
指定ノードでリカバリーが必要か確認して、 次にこのノードでデータベースの最新のバックアップ・バージョンをリストアしてください。
」

RECOVERYコマンドは"RESTORE DATABASE + ROLLFORWARD"なので、ROLLFORWARDしてくれようとしたんだと思います。次回確認しようと思います。

テーブルとデータは以前の通りに戻っているでしょうか？



戻っていますね。よかった。

BACKUPコマンドは、バックアップした場所の物理的な場所を覚えているため、RECOVERYコマンドを実行するときにバックアップファイルを指定する必要がありません。
ただ、バックアップファイルを移動したりしてコマンドを実行したときと違う場所に移動した場合にはRECOVERYコマンドが失敗します。


Information Centerを見てみた。
「
SQL2542N

指定されたソース・データベースの別名 database-alias とタイム・スタンプ timestamp に一致する、データベース・イメージ・ファイルがありません。

説明
バックアップ・イメージ・ファイルのファイル名は、データベース別名とタイム・スタンプのコンポーネントで構成されています。ファイル名は、ソース・データベース別名と、Database Restore 呼び出しに指定されたタイム・スタンプ・パラメーターから作成されます。 指定されたソース・データベースの別名とタイム・スタンプに一致する ファイル名が、ソース・ディレクトリーに存在しません。
以下の状態が適用される可能性があります。
１．バックアップへのパスがリストア・コマンドで誤って指定された。
２．バックアップ・イメージ、またはバックアップ・イメージがあるディレクトリーにアクセスする許可がない。
３．自動増分リストア操作を実行しており、データベース履歴内のタイム・スタンプとロケーションに基づいて必要イメージが見つからなかった。
４．パーティション・データベース環境でデータベースをリストアしており、そのデータベースがもう存在せず、さらにリストアされる最初のデータベース・パーティションがカタログ・パーティションではない。
５．TSM メディアからリストアしようとしており、現在のインスタンスにより使用される TSM API クライアント構成はバックアップ・イメージにアクセスできない。

ユーザーの処置
上記の状態に対する適切な応答は以下のとおりです。
１．データベース・バックアップ・イメージが、メディア・ソースに 存在することを確認してください。 結果的に一致するバックアップ・イメージへの正しいパスおよび正しいタイム・スタンプを指定して、操作を 再サブミットしてください。 リストア・コマンドの使用についての詳細は、DB2 インフォメーション・センターで、"using restore database utility" などの語句を使用して検索してください。
２．バックアップ・イメージ、およびバックアップ・イメージがあるディレクトリーにアクセスする許可があることを確認してください。
３．データベース履歴を調べて対応するバックアップ項目を確かめてから、 リストされているロケーションがバックアップ・イメージの実際のロケーションに一致することを確認してください。 データベース履歴を更新して、結果が一致するように操作をやり直すか、 または RESTORE INCREMENTAL ABORT コマンドを発行して、処理中に作成されたリソースをすべてクリーンアップしてください。
４．パーティション・データベースをリストアするときには、常にカタログ・パーティションを最初にリストアしてください。パーティション・データベース環境でのリストアについての詳細は、DB2 インフォメーション・センターで、"restore utility partitioned database" などの語句を使用して検索してください。
５．イメージを TSM から取得できるかを検査するには、db2adutl ユーティリティーに QUERY オプションを付けて使用します。別のサーバー上の別のインスタンスから取得したバックアップ・イメージをリストアする場合、オプション NODENAME、OWNER を必ず使用してください。またオプションで、バックアップ・イメージが最初にとられた TSM ノードの TSM 設定に対応する PASSWORD を使用してください。イメージを取得できることの確認が完了すると、同じオプションを RESTORE コマンドのオプション・ストリングに渡すことができます。db2adutl ユーティリティーについての詳細は、DB2 インフォメーション・センターで、"db2adutl" などの語句を使用して検索してください。
」

フォルダーへの定期バックアップであればバックアップファイルが見あたらないと言うことはないのでしょうが、テープから戻す場合には出やすいのかもしれませんね。
ログファイル・ヒストリーファイルを指定する項目があるので指定間違いの際にも出るでしょう。ログファイル・ヒストリーファイルをいじったパターンも試してみることにします。

本で5種類に分類された金融機関。三つ目は保険会社。保険会社は大きく生命保険会社と損害保険会社の二つに分けることができます。
どちらの会社も内閣総理大臣の免許を受けなければいけません。

●生命保険会社
・大手生命保険会社
・中堅/新規参入保険会社
・外資系生命保険会社
・損保系生命保険会社

●損害保険会社
・大手損害保険会社
・ダイレクト販売系保険会社
・外資系損害保険会社
・生保系損害保険会社

●大手生命保険会社は「保険レディー」と呼ばれる販売員での対面販売が中心となります。彼女らをよくエレベーターホールで見かけます。死亡保険が中心となっていますが、多種取りそろえています。

●中堅/新規参入保険会社は対面販売もしているけれども、ネットにも進出しています。

●外資系生命保険会社は外国の会社だけあって、「カタカナ生保」と呼ばれます。がん保険など傷害疾病定額保険に特化していましたが、最近は一般的な生命保険も取り扱うようになっています。

●損保系生命保険会社はその名の通り、損害保険会社が生命保険も一緒に販売しています。会社名にひらがながつくので「ひらがな生保」とも呼ばれます。
96年4月に保険業法が改正されたことにより、生損保の相互参入が認められて誕生しました。

●大手損害保険会社は多岐にわたる損害についての保険を取り扱っており、代理店経由での契約が主となっています。

●ダイレクト販売系保険会社はインターネットや電話を使って販売しています。

●外資系損害保険会社はその多くが自動車保険を取り扱っています。

●生保系損害保険会社は損保系生命保険会社の逆で、生命保険会社が損害保険も一緒に販売している形です。

保険会社は、顧客から集めた保険金から支払いを行い、経費に充てるが、残りは車内で眠らせておくのではなく、マーケットで運用しています。このため、保険会社はマーケットにおいて有力な機関投資家となっています。

各種保険の料金を決めるのにアクチュアリーという専門職があります。統計等の巣ペ死リストで、日本アクチュアリー会の会員とならなければ名乗ることができないようです。だいたい正会員となるまでに10年弱かかる難関資格だそうです。

先日勉強したDB2の管理コマンドを勉強するためにまずDB2をインストールした。

IBMのサイトからDB2-Expressをダウンロードし、任意のフォルダーに解凍。念のため、インストール前提条件を満たしているかを確認。

imageフォルダーにあるdb2prereqcheck.batをコマンドウィンドウで実行します（ダブルクリックでも動きますが、結果表示をした瞬間にウィンドウが閉じてしまいます・・・）。


"Installation Prereq is OK."

と表示されればシステム要件を満たしています。


それではsetup.exeを実行します。まずはランチパッド(LaunchPad)が起動しますが、ここではDB2の情報を教えてくれているだけなのでいきなり「製品のインストール」をクリックし、「新規インストール」ボタンをクリックしてしまいます。



やっとインストールのメニューが始まります。


ライセンス条項にはもちろん同意しましょう。


特にインストールにこだわりはないのでとりあえずは標準インストールをします。


何がインストールされるのかを確認するには「フィーチャーの表示(V)...」をクリックします。なぜかここだけテキストベースです。


応答ファイルを作成するかを選択できます。もし、この後何台にもインストールする必要があるのであれば、応答ファイルを作って、サイレントインストールするのが良いでしょう。


インストールフォルダーの選択。


DB2 Administration Server(DAS)のアカウント設定。


インスタンスの設定。

ポート番号や起動について設定できます。


インストール内容の確認。


インストールが終わりました。


Visual Studio用のアドインが用意されていました。今回は必要ないのでスルーします。


インストールが終了すると、ファースト・ステップが起動します。ローカルにインフォメーション・センターがインストールされず、インターネットにもつながらないのでエラーが出ましたが問題ないです。

自分で一からデータベースを作るのは大変なので、「SAMPLEデータベースの作成」ボタンを押して用意されているサンプルを使います。


SAMPLEデータベースの詳細設定を決めます。


1分半で終了です。


これでひとまずテスト環境ができました。

Club DB2ナイト・サークルに参加してきました。講師は生粋の(？)千葉っ子、高橋さん。

【管理ツール編】という募集だったのですが、実は【運用管理編】でした。

あまり詳しく知らないのに運用管理なんて・・・と思いましたが、勉強したことはたったの三つ。

・バックアップ(backup)
・表の再編成(reorg)
・統計情報の更新(runstats)

DB2の資格研修で勉強したことがあるのでおおよその動きを知っている言葉達だったので良かったです。

初っぱなに「ずきっ」と来た言葉。

『DB管理者の仕事で一番大切なのはバックアップです。で、RAIDはバックアップではありません。』

よ～く知っております。知っていますけどたぶんうちの現場では、外部ディスク装置を使い始めてからバックアップをとっていないのではないかなと思われます（災対機にデータを移行するためにダンプをとっていますが、それはバックアップに入るかしら？）。

バックアップの名称が少し気になりました。

通常、フルバックアップ(full backup)の後に差分バックアップ(incremental backup)と増分バックアップ(differential backup)を単独もしくは組み合わせで使うと思いますが、DB2ではここで言う差分バックアップを「デルタバックアップ(incremental delta)」と呼び、増分バックアップを「累積バックアップ(incremental)」と呼ぶんだそうです。

表の再編成はすぐにコマンドが出てくるくらい気になる作業です。たま～にこの言葉が聞こえてくるとうきうきしてきます。実作業を見たことはないんですが。

表の再編成には二種類あって、一つは、テーブルを一時領域にコピーし、再編成をしながら元の領域に戻していく「シャドー・コピー」。もう一つは、PCのデフラグのように空きスペースを少しずつ動かしながら行う「インプレース」。

統計情報の更新についてはかなり駆け足でしたが、DB2 9.1から自動runstatsはデフォルトONだそうです。

大規模DBなどにおいてアクセス・プランが変わってしまうのがいやであれば忘れずに自動化機能をOFFにするようにと注意がありました。"db2look -m"で統計情報のDDLをバックアップできるのでrunstatsする場合にはとっておくのも手だと言うことです。

大規模DBを触ったことがないのでイメージがつきませんが、アクセス・プランが変わることでどれくらいSQLのパフォーマンスが変わるのか体感してみたいです（そもそもここで言う大規模ってどのくらいのDBなのだろう？）。

この連休中にバックアップ・リストアくらいは試してみようかな。

先日、pam_tally.soの記述が二ファイル(loginとsystem-auth)に書かれていることで、ログイン失敗について厳しかったことが発覚した。

本番サーバーではsystem-authに記述していることもあり、開発の各サーバーでもログイン失敗のカウントはloginファイルではなく、system-authファイルに記述することに決めた。

作業は別に何をするわけでもなく、ただ、loginファイルに書かれている

"
auth required /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
account required /lib/security/$ISA/pam_tally.so per_user deny=3 no_magic_root reset
"

をsystem-authに書き写すだけ。

作業終了後、念のため動作確認をしてみた。telnetで接続し、わざと3回間違えてアカウントがロックされるかどうかを確認する。

RHEL3とRHEL4とで動作が違うことに気がついた。

RHEL3では、"deny=3"と設定すると「3回の間違いまでは許します」という動きに対し、
RHEL4では、"deny=3"と設定すると「3回失敗するとロックします」という動きだった。

当環境の詳細なバージョンは下記の通り
RHEL3(2.4.21-20)
pam(0.75)

RHEL4(2.6.9-43)
pam(0.77)

でも、"/usr/share/doc/pam-<version>/txts/README.pam_tally"に違いはないんだよなぁ・・・

先日、HULFTのver.5からver.6にあげる仕事をしたので、ver.7にあげてみようかなと思って試してみた。

まず、セゾン情報からテスト版をダウンロード。

インストールマニュアルを見ると、今までとはずいぶんと見た目が変わっていたのでクリーンインストールから始めた。

今までとは違って、テスト版はアップグレードインストールができません。本物は「新規インストール」と「アップグレードインストール」を手動で選ぶようです。

ver.6までと同じようにインストールは問題なく終わりました。[スタート]からHULFT管理画面をクリックするとエラーメッセージが表示されました。



動作環境を確認していなかったのですが、Windows Server 2003までだと".NET Framework 2.0 SP1"が、2008/Vistaは".NET Framework 3.5 SP1"が導入されていることが条件になっていました。

Microsoftから.NET Framework 2.0 SP1をダウンロードし、インストールしてから起動。

見た目は今時のアプリケーションという感じがしました。タブが使えるようになったので、複数ウィンドウを開いていてもウィンドウ間の移動が楽になりました。



テスト版なので、正規のアップグレードインストールができませんでしたが、今までのアップグレードと同様にhulconv.exeを実行することにより登録定義の引き継ぎが問題なくできました。

僕の現場で実際に使うようになるにはまだ何年もかかると思いますが、前もって知識の準備をして行ければと思います。

ぱっと気がついたver.6との違い。

・.NET Frameworkが必要
・ウィンドウがタブ表示となった
・hulft.ini(HULPATHが記述されたファイル)の保存場所がbinntになった
・システム動作環境設定にスケジューラが追加され、休日・祝祭日の設定が可能になった

HULFTの導入は何度も行っているけれども実際に定義を作ったりしたことはないので、これを機に少し勉強をしようと思う。

ntpq -pでの表示でpolling間隔の時間表示が秒から分に変わったことを書きました。

今日は分から時に変わりました。

polling 14では時刻同期間隔は273分です。

# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*123.456.789.098 123.98.1.90      2 u  61m 273m  377    0.169   11.501  16.782

 LOCAL(0)        LOCAL(0)        11 l   24   64  377    0.000    0.000   0.004

polling 15になると同期間隔は9時間(546分)になります。

# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*123.456.789.098 123.98.1.90      2 u  175   9h  377    1.110    0.228   0.985

 LOCAL(0)        LOCAL(0)        11 l   24   64  377    0.000    0.000   0.008

273分ぶりに時刻調整をしたのにもかかわらず、ずれが0.228ミリ秒だったというのが驚きです。

polling 14から15になるまでに約半日かかりました。明日のうちには16になるのかな？

NTP関連ですが、ntpqというコマンドがあります。

これは、ntpデーモンを起動しているときに、自分のサーバーがどの時刻サーバーと同期をとっているのか、どれくらい時刻差があるのかを確認できるコマンドです。

maxpoll 16で同期するにはどれくらい時間がかかるのか実験しているのですが、pollingが12になってから表示が変化しました。when列とpoll列です。

# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*123.456.789.098 123.98.1.90      2 u  61m  68m  377    0.110    0.281   0.142

 LOCAL(0)        LOCAL(0)        11 l   24   64  377    0.000    0.000   0.008

polling 11まではこれらの数値は秒数で2の4乗(16)から11乗(2048)まで表示されるのですが、polling 12からは分数が表示されるようになりました。数字の後ろについている"m"はminuteのmです。上記では、polling間隔が68分で、前回同期をとってから61分経過していることを表しています。whenの値ははじめは秒数でカウントされていましたが、あるところから分でのカウントに変わっていました。境目はどこなんだろう？

ちなみに、2行目のLOCALは64秒間隔での同期です。

polling 16は約18時間なので18hと表示されるのでしょうか？現場のサーバーに仕込んであるので明日が楽しみです。

RHEL4で確認してあります。

先月、サーバーの時刻設定を行う作業を行い、手動で時刻サーバーと同期を取る手順を入れていた。

本番サーバーでの作業は作業手順書を書いて、オペレーターに引き継いで行わなければならないので、時刻調整の所で下記メッセージを確認するように手順を書いた。

"
DD MMM hh:mm:ss ntpdate[xxxxx]: step time server 123.456.789.098 offset -xx.xxxxxx sec
"

実際に作業をお願いしたらntpdateコマンドを実行したところで問い合わせの電話が鳴った。

"
DD MMM hh:mm:ss ntpdate[xxxxx]: step time server 123.456.789.098 offset -xx.xxxxxx sec
"
ではなく
"
DD MMM hh:mm:ss ntpdate[xxxxx]: adjust time server 123.456.789.098 offset -xx.xxxxxx sec
"
だけれども正常に作業が出来ているのか？と。

"step"か"adjust"かの違いなので大丈夫ですと答えた後にソースを調べてみた。
すると、調整した秒数が0.5秒以上か未満かで出力メッセージが変わることがわかりました。

ntpdate.h(64)

#define	NTPDATE_THRESHOLD (FP_SECOND >> 1) /* 1/2 second */



ntpdate.c(1295)

 if (always_step) {

  dostep = 1;

 } else if (never_step) {

  dostep = 0;

 } else {

  absoffset = server->soffset;

  if (absoffset < 0)

   absoffset = -absoffset;

  dostep = (absoffset >= NTPDATE_THRESHOLD || absoffset < 0);

 }



 if (dostep) {

  if (simple_query || l_step_systime(&server->offset)) {

   msyslog(LOG_NOTICE, "step time server %s offset %s sec",

    stoa(&server->srcadr),

    lfptoa(&server->offset, 6));

  }

 } else {

#if !defined SYS_WINNT && !defined SYS_CYGWIN32

  if (simple_query || l_adj_systime(&server->offset)) {

   msyslog(LOG_NOTICE, "adjust time server %s offset %s sec",

    stoa(&server->srcadr),

    lfptoa(&server->offset, 6));

  }

調整幅が0.5秒未満の場合にはメッセージ"adjust time server・・・"が、0.5秒以上の場合にはメッセージ"step time server・・・"が表示されます。

"
[root@TESTSERVER root]# ntpdate -q 123.456.789.098
server 123.456.789.098, stratum 2, offset -0.000586, delay 0.02568
15 Sep 16:59:32 ntpdate[20923]: adjust time server 123.456.789.098 offset -0.000586 sec
[root@TESTSERVER root]# date
Tue Sep 15 16:59:36 JST 2009
[root@TESTSERVER root]# date 09151700
Tue Sep 15 17:00:00 JST 2009
[root@TESTSERVER root]# ntpdate -q 123.456.789.098
server 123.456.789.098, stratum 2, offset -15.117865, delay 0.02570
15 Sep 17:00:04 ntpdate[20926]: step time server 123.456.789.098 offset -15.117865 sec
[root@TESTSERVER root]# ntpdate 123.456.789.098
15 Sep 16:59:55 ntpdate[20927]: step time server 123.456.789.098 offset -15.117872 sec
[root@TESTSERVER root]# ntpdate -q 123.456.789.098
server 203.214.181.109, stratum 2, offset -0.000139, delay 0.02568
15 Sep 17:01:32 ntpdate[20932]: adjust time server 123.456.789.098 offset -0.000139 sec
[root@TESTSERVER root]# ntpdate 123.456.789.098
15 Sep 17:01:32 ntpdate[20932]: adjust time server 123.456.789.098 offset -0.000139 sec
"

上記のように、-qオプションをつけたときにもstepかadjustかを確認することが出来ます。

勉強になりました。
RHEL3/4で確認（ソースはRHEL5の物）

今朝、隣に座っている開発リーダーから質問があった。

「ねぇねぇ、この開発サーバーだけ、ログインに失敗するとfaillogに2カウントされるんだけど」

「？ん？どういう事？」と実演を見てみた。

"pam_tally.so"を設定していると"/var/log/faillog"というファイルが作成され、ログイン情報が記録される。
通常、ログインに失敗すると、失敗カウントが1ずつ増えていく。そして、設定した限界値に達するとその後のログインが出来なくなるわけです。
問題のサーバーでは通常1ずつ増えていく失敗カウントが2ずつ増えていくのです。

何か設定間違いをしてしまったのかと思い、"/etc/pam.d"にあるsystem-authファイルをチェックする。

"
auth required /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
account required /lib/security/$ISA/pam_tally.so per_user deny=3 no_magic_root reset
"
上記2エントリが追加されているだけで、怪しい箇所は見受けられない。一回のカウント数を決める箇所もないし・・・

少しググってみると、system-authに書く派とloginに書く派があることがわかったので、うちのサーバーのloginを見てみると・・・書いてありました。

サーバーの設定を変更する要件があって、僕はsystem-authに追加していたのですが、前任管理者はloginに追加していたのです。知らなかった・・・

デフォルトのloginにはpam_tally.soの記述など無く、設定は全てsystem-authを参照してねという
"
pam_stack.so service=system-auth
"
が全てのエントリについて記述されている。

通常は全ての動作はsystem-authを見てそれに従う設定になっています。

今回の事象ではまず、loginを読み込んでfaillogに1追加し、次にsystem-authを読み込んでfaillogに1追加するので、全体としては2追加されることになっていたのです。

loginからpam_tally.soのエントリを削除して解決です。

もう一つ罠が仕掛けられていました。"deny=2"と設定されていたのです。一回間違えると失敗カウントが2になり、限界値2に達し、その後はログイン出来なくなってしまいます・・・あぁつかいずらいサーバーだったこと

本で5種類に分類された金融機関。二つ目は証券会社。証券会社はおおよそ次の4種類に分けることができるようだ。

・総合証券会社
・ネット専業証券会社
・外資系証券会社
・インベストメントバンク

●総合証券会社は大手・銀行系・地場の3種類に分けることができる。
　大手は野村や大和など個人向け・企業向けサービスを行っています。銀行系はみずほやUFJなど、銀行が設立した会社で、銀行内に窓口があったりします。地場は古くから地方で業務を行っている会社になります。

●ネット専業証券会社はネット専業銀行と同じくインターネットを使用した証券会社です。銀行でもそうですが、手数料が安くなっています。
　大手がネットにも進出してきているので、他会社との提携や合併などで生き残りをかけています。

　申し込みから利用まですべてネット経由でできたので僕もネット証券会社を利用しています。

●外資系証券会社は一時期話題になったリーマン・ブラザーズやモルガン・スタンレーなどの日本進出企業です。

●インベストメントバンクは大手総合証券会社や外資系証券会社の一部の業態で、投資業務に特化した証券会社です。日本大手よりも外資系の方が得意としている分野になります。

本で5種類に分類された金融機関。一つ目は銀行。銀行はおおよそ次の8種類に分けることができるようだ。

・普通銀行
・ネット専業銀行
・流通系銀行
・信託銀行
・ゆうちょ銀行
・共同組織機関
・外資系銀行
・公的機関

このあたりはだいたいイメージがつくものばかり。ただ、流通系銀行（例：セブン銀行）・共同組織機関（例：農協）・公的機関（例：日本銀行）と言われてもピンとこないが、それぞれ実名を出すとわかる。

●普通銀行は都市銀行と地方銀行とに分けることができ、都市銀行はいわゆるメガバンクと呼ばれる銀行達になります（三菱UFJだけ点「・」が入るのが気になります）。

・三菱UFJフィナンシャル・グループ
・三井住友フィナンシャルグループ
・みずほフィナンシャルグループ
・りそなグループ

りそなグループはメガバンクとは自称していないようですが4大金融グループの一員です。考えてみれば、上記4銀行に口座を持っています。

●地方銀行はスルガ銀行や千葉銀行、千葉興業銀行など若干マイナーな地方のみで見かける銀行です（名前のまんま）。地方銀行は「社団法人全国地方銀行協会」の会員だそうです。ちなみに、銀行協会はそのほかにも「全国銀行協会」（都銀・地銀等だいたいの銀行が加入）「東京銀行協会」などいくつかあります。

●ネット専業銀行はジャパンネット銀行など、店舗を持たない銀行形態です。店舗を持たない分、金利が少し高く設定されています。

●流通系銀行は流通業・小売業をしていたイオンやセブンアンドアイが銀行業務に乗り出して作った銀行になります。地方にあるイオンやセブンイレブンで使用できるのでとても利便性に優れています。

●信託銀行は投資信託など顧客資産の管理運用を行う「信託業務」を主軸にしている銀行になります。

●ゆうちょ銀行は日本郵政公社の郵便貯金事業が分社化され株式会社ゆうちょ銀行となったものです。

●共同組織機関は特定の地域・組合員を対象とした金融機関です。農業協同組合や漁業共同組合などがそれに当たります。

●外資系銀行は2種類あるそうです。
1.シティバンクを代表とする、欧米の金融機関が日本支店/法人として出店しているもの
2.新生銀行をはじめとする、日本の既存銀行が外国資本を受けているもの

日本の老舗銀行と比べ新しい考えを早いうちから取り入れているのが特徴だそうです。

●公的機関は民間銀行が手を出しにくい分野でサービスを提供するために活動している日本政策投資銀行や住宅金融支援機構などの政府系の銀行などです。

logconfigの設定についてで思いついた"logconfig +syscall"の動きを試した。

時刻が調整されているサーバーでntpdを停止後、dateコマンドで時刻を2分ほどずらした。そしてntpdの起動を行い、下記のログが出力された。

"
10 Sep 10:15:09 ntpd[11346]: running as uid(38)/gid(38) euid(38)/egid(38).
10 Sep 10:18:42 ntpd[11346]: time reset 139.316135 s
10 Sep 10:18:42 ntpd[11346]: kernel time discipline status change 41
10 Sep 10:18:42 ntpd[11346]: synchronisation lost
10 Sep 10:20:23 ntpd[11346]: kernel time discipline status change 1
"

"time reset 139.316135 s"。前回予想したとおり、システムクロックに関するログが出力されるんだ。

今回のログで出力された"synchronisation lost"はソースを検索しても出てこないのだが、時刻がステップ調整されると一旦時刻サーバーとの接続がとぎれるらしい。その後、"kernel time discipline status change 1"が出ており、nptqコマンドで時刻同期が取れているので今のところはよしとする。

相変わらずRHEL3/4で確認。

銀行に派遣されているので、少し銀行業務について勉強しようと思う。
お客さんに業務についての講習を受けたいと直接言ってみたのだが、却下されてしまった。システムについては知識があっても、業務についての知識がないのはどうなんだろう・・・なので、本を読んで知識を得ようと思った。

本によると金融機関はおおよそ次の5種類に分けることができるようだ。

・銀行
・証券会社
・保険会社
・その他金融機関
・その他機関投資家

wikiで金融機関について検索したところ細かく13分類されていた。名前は聞いたことがあるけれども、普段あまり意識しないものばかり。

・銀行
・信用金庫
・信用協同組合（信用組合）
・商工中金
・労働金庫
・農業協同組合
・漁業協同組合（水産業協同組合）
・信金中央金庫
・農林中央金庫
・その他の政策金融機関
・保険会社
・証券会社
・貸金業者

13は細かいので本の通り5つメインで覚えていく。

システム・ガイド	IBMサーバーのスペック表と、装着可能なオプション類の構成ガイドです。導入機器見積の際にとても役に立ちます。

NTPの設定について③でよくわからずに設定した"logconfig"について試してみました。

"logconfig +syscall"
8 Sep 19:00:59 ntpd[14904]: running as uid(38)/gid(38) euid(38)/egid(38).
8 Sep 19:01:59 ntpd[14904]: kernel time discipline status change 41
8 Sep 19:02:34 ntpd[14904]: kernel time discipline status change 1

"logconfig +clockall"
8 Sep 19:00:57 ntpd[14110]: running as uid(38)/gid(38) euid(38)/egid(38).
8 Sep 19:01:57 ntpd[14110]: kernel time discipline status change 41
8 Sep 19:02:32 ntpd[14110]: kernel time discipline status change 1

"logconfig +peerall"
8 Sep 19:01:00 ntpd[511]: peer 123.456.789.098 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
8 Sep 19:01:01 ntpd[511]: peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
8 Sep 19:02:33 ntpd[511]: synchronized to 123.456.789.098, stratum 2
8 Sep 19:02:33 ntpd[511]: kernel time sync disabled 0041
8 Sep 19:09:04 ntpd[511]: kernel time sync enabled 0001

"logconfig +sysall"
8 Sep 19:00:58 ntpd[7444]: running as uid(38)/gid(38) euid(38)/egid(38).
8 Sep 19:00:58 ntpd[7444]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)
8 Sep 19:01:06 ntpd[7444]: peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
8 Sep 19:01:09 ntpd[7444]: peer 123.456.789.098 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
8 Sep 19:01:58 ntpd[7444]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_ntp, 2 events, event_restart' (0xc621)
8 Sep 19:01:58 ntpd[7444]: kernel time discipline status change 41
8 Sep 19:01:58 ntpd[7444]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_ntp, 3 events, event_peer/strat_chg' (0x634)
8 Sep 19:01:58 ntpd[7444]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_ntp, 4 events, event_sync_chg' (0x643)
8 Sep 19:02:33 ntpd[7444]: kernel time discipline status change 1
8 Sep 20:00:58 ntpd[7444]: offset 0.000020 sec freq 27.469 ppm error 0.000079 poll 5
8 Sep 21:00:58 ntpd[7444]: offset 0.001049 sec freq 23.676 ppm error 0.000335 poll 6
8 Sep 22:00:58 ntpd[7444]: offset 0.000274 sec freq 23.906 ppm error 0.000411 poll 8
8 Sep 23:00:58 ntpd[7444]: offset 0.000842 sec freq 23.919 ppm error 0.000359 poll 10
9 Sep 00:00:58 ntpd[7444]: offset 0.007946 sec freq 23.954 ppm error 0.002036 poll 10
9 Sep 01:00:58 ntpd[7444]: offset 0.020403 sec freq 24.032 ppm error 0.004302 poll 10
9 Sep 02:00:58 ntpd[7444]: offset 0.005241 sec freq 25.256 ppm error 0.002214 poll 9
9 Sep 03:00:58 ntpd[7444]: offset 0.002397 sec freq 25.342 ppm error 0.001221 poll 10
9 Sep 04:00:59 ntpd[7444]: offset 0.003058 sec freq 25.386 ppm error 0.000715 poll 10
9 Sep 05:00:59 ntpd[7444]: offset 0.004596 sec freq 25.436 ppm error 0.000736 poll 9
9 Sep 06:00:59 ntpd[7444]: offset 0.000054 sec freq 25.811 ppm error 0.000558 poll 9
9 Sep 07:00:59 ntpd[7444]: offset 0.002246 sec freq 25.838 ppm error 0.000567 poll 10
9 Sep 08:00:59 ntpd[7444]: offset 0.001653 sec freq 25.885 ppm error 0.000350 poll 9
9 Sep 09:00:59 ntpd[7444]: offset 0.000101 sec freq 25.960 ppm error 0.000172 poll 10

試してみて気がついたのは、syscallとclockallはそれぞれシステムクロックとハードウェアクロックについてのログレベルではないか？ということ。今回試したのは時刻同期をしているサーバーでntp.confを書き換えてntpdを再起動しただけなので、大幅な時刻調整は入っていない。そのため、ログには起動についてのログしか出ていないのではないか？

peerallは接続先サーバーの状態と、それに対応する自サーバーの状態についてのログレベルではないか？ということ。このレベルで初めて"synchronized to・・・"が記録されている。

sysallは上記全てを含んだログレベルではないか？ということ。で、それにプラスしてdriftfileへの書き込みについてのログを出している（ちなみに、毎時driftfileが変更されていることが確認できる）。

また少しずつ調べていきます。

HULFTを導入時に設定される環境変数のHULPATH。

テスト機ではWindowsの環境変数として設定されていたのでそういう物だと思っていた。

HULFTバージョンアップの際に"set hulpath"とコマンドプロンプトで実行して中身を確認しようとしたところ、"hulpathが設定されていません"と出てくる。でも、インストール中にhulpathをHULFT6のディレクトリに変更しますよとメッセージが出てくるのでおかしいなと思っていた。

昨日、ぼんやりとHULFTのマニュアルを読んでいたらそのわけが載っていた。

『
3.2　動作環境の設定について
　・・・
3.2.1　HULFT環境設定ファイルのあるディレクトリの設定
　HULFTが使用する環境設定ファイルのあるディレクトリを「hulft.ini」ファイルに設定します。セクション名は「PATH」、エントリ名は「HULPATH」です。インストール時にインストーラが自動的に設定しますが、変更を行いたい場合は、オペレーティングシステムディレクトリ(%windir%)にある「hulft.ini」ファイルをメモ帳などのエディタで変更してください。
【記入例】
[PATH]
HULPATH=C:\Program Files\hulft\etc
』

そういうことだったのか。これを知らない人がテスト機の設定をしたからWindowsの環境変数にHULPATHが設定されていたのだろう。納得。

ちなみにこの記述は管理ガイドの「第３章　Windows動作環境」に書いてありますので、その他OSについてはわかりません。

HULFT ver.5からHULFT ver.6にあげる仕事がありました。

手順はとても簡単でした。

1.HULFTを停止する。
2.新しいHULFTのインストールをする。
3.登録のインポートをする。
4.HULFTを起動する。

大まかには上記4項目の作業ですが、本番環境でバージョンアップするのが初めてだったので、念のため下記作業もプラスで行いました。

1.1.登録のバックアップをとる（utligenコマンド）。
1.2.登録の件数を数えておく。
3.1.登録の件数が変わっていないことを確認する。

バージョンアップの際には、自動的に既存のHULFTフォルダがインストール先に指定されます（バックアップフォルダが作成され、元のbinntとetcフォルダがコピーされます）。

今回はhulft5ではなくhulft6とフォルダ名を指定してインストールを行いました。バックアップフォルダの指定を外さないで進んだところ、バックアップするものがないのだから作る必要はありませんとメッセージが表示されました。ごもっとも・・・

ぺしぺしとインストールは何も問題なく終了したので、binntにあるhulconvコマンドで登録を新しいHULFTへ移行しました。元のHULFTのetcフォルダを指定して実行すれば自動的に登録がインポートされます（既存フォルダに上書きインストールという形であればインストール時にインポートされます）。

HULFTを起動して、テストデータの送受信をして終了しました。

今はver.7となったHULFT。でも、まだまだver.5が動いているんだよな・・・
今まで、新規インストールしかしたことがなかったから、5->6、6->7の練習を少ししておこうかしら。

NTPの設定について①、
NTPの設定について②の続き

各種設定の意味を調べてから新しくntp.confを書き直しました。

"
tinker panic 0

restrict default ignore
restrict 127.0.0.1
restrict 123.456.789.0 mask 255.255.255.0 nomodify notrap

server 123.456.789.098 minpoll 4 maxpoll 8
server 123.456.789.097 minpoll 4 maxpoll 8

server 127.127.1.0
fudge 127.127.1.0 stratum 11

driftfile /var/lib/ntp/drift
logconfig +syscall +clockall +sysall +peerall
logfile /var/log/ntpd.log
"
まず、ntpデーモンが自動的に終了しないように設定。
"restrict 123.456.789.0 mask 255.255.255.0"で同一LAN内でのアクセスを可能に。後のオプションは他のサーバーからアクセスが来たときに変更されることがないようにする物のようです（要調査）。

今回は参照時刻サーバーを二カ所設定していて、時刻調整間隔は短めの4から8にしてあります。今まで10に設定していて、ntpが動いている間に30秒もずれていたので、間隔を少し短くすることになりました。本番機だからどんな具合なのか見ることができずに残念です。

"logconfig"で指定すると詳細なログが出力されるようになります。どのオプションをつけるとどれだけ変わるのかはまだ未調査ですが、とりあえず全部乗せでいきました（要調査）。

"logfile"には起動/停止・最初に調整した時のずれ幅とdriftファイルを更新したログが出力されます。ログを見ると、driftファイルが一時間ごとに修正されていることがわかります。

ntp.confを書き換えたらntpdを再起動すれば作業完了です。新しい設定を読み込んで動いてくれます。

NTPの設定について①の続き

ntp.confの書き方。
"restrict"は接続サーバーを指定するのに使います。接続する先についても、接続してくる元についても書く必要があります。

"restrict default ignore"でまず、どこからのアクセスも拒否します（はじめに一切合切拒否するのはセキュリティ設定ではふつうのことです）。

"restrict 127.0.0.1"でローカルホストからのアクセスを許可します。これは、時刻サーバーにつながらないときには127.127.0.0をstratum 12の時刻サーバーとして時刻調整をする動きとなるので必要です。

"restrict 123.456.789.098"でこちらがアクセスする時刻サーバー/自サーバーを時刻サーバーとしてアクセスしてくるサーバーのIPを記述します。サーバー名で指定することも出来ますが、hostsファイルへの参照が必要になるのでIPの方が早いとのこと。

"server 123.456.789.098 minpoll 9 maxpoll 10"で時刻サーバーへの同期間隔を指定します。
"minpoll"で最短間隔を指定します。
"maxpoll"で最長間隔を指定します。
minpoll/maxpollを指定しない場合、minpollが64秒、maxpollが1024秒に設定されます。

同期感覚は3～17までを指定することが出来ます。また、指定した数字が直接秒数になるわけではなく、ここで指定する数字は2の指数となります。ですので、設定可能範囲は2^3秒（8秒）～2^17秒（約36時間）となります。

"fudge 127.127.0.0 stratum 12"で時刻サーバーと通信が出来ない場合に自サーバーを一時的に時刻サーバーと認識させます。stratumは時刻サーバーのランクで、最高が1になります。NICTの時刻サーバーなどがstratum1となり、NICTを参照している時刻サーバーがstratum2となり・・・と、一番正確な時刻サーバーから離れるにつれて数字が大きくなっていきます。

"driftfile /var/lib/ntp/drift"では自分のクロック周波数を記録しておくファイルを指定します。指定した時刻サーバーにアクセスできない場合には自分が仮の時刻サーバーになるからです。このファイルは毎時間更新されます。

RHEL3/4で確認

Linux

The Linux Documentation Project	LinuxのHOWTOや様々なガイドが公開されています。
The Network Time Protocol (NTP) Distribution	NTPについて詳しく書かれています。大変役に立ちました。
CUPS Software Users Manual	Linuxを使う上で鬼門の一つであろう印刷についてです。一通りオプションの使用法がわかります。

僕が管理を引き継いだシステムでNTPデーモンが停止する事象が半年で3回くらい発生しました。

ログを見てみると、
"
dd MMM HH:DD:SS ntpd[xxxx]: frequency error -503 PPM exceeds tolerance 500PPM
dd MMM HH:DD:SS ntpd[xxxx]: kernel time sync desabled 0001
dd MMM HH:DD:SS ntpd[xxxx]: time correction of 30 seconds exceeds sanity limit (30); set clock manually to the correct UTC time.
"
と出ていた。最終的には時刻サーバーとの時刻差が30秒に達し、設定値を超えたので終了しますというメッセージです。

ntp.confを確認すると
"
tinker panic 30 step 30
restrict default ignore
restrict 127.0.0.1
restrict 123.456.789.098
server 123.456.789.098 minpoll 9 maxpoll 10
fudge 127.127.0.0 stratum 12
driftfile /var/lib/ntp/drift
"
という設定になっていた。上から意味を書いていくと
「
時刻サーバーとのずれが30秒になったらデーモンを停止します。また、時刻サーバーとのずれが30秒になったら時刻を一気に修正します。
どのサーバーとの通信も拒否します。
127.0.0.1との通信は許可します（127.0.0.1はローカルホスト）。
123.456.789.098との通信も許可します。
123.456.789.098を時刻サーバーとします。時刻確認は512秒か1024秒です。
時刻サーバーにつながらないときには127.127.0.0をstratum 12の時刻サーバーとして時刻調整をします。
driftfileは/var/lib/ntp/driftにあります。
」

まず、1行目があり得なかった。30秒ずれると落ちるのに30秒ずれないと時刻をあわてて直さない設定なのです（ここで疑問なのは30秒もずれるのか）。

ntp.confの書き方。
"tinker panic"は時刻サーバーとのずれが設定した秒数を超えるとデーモンが停止するということ。0に設定するとずれ幅の如何に関わらず、デーモンは停止しない。
"tinker step"は時刻サーバーとのずれが設定した秒数を超えると一気に時刻を修正する。設定をしないと128ミリ秒以上ずれると一気に修正する。通常の時刻調整は1秒に0.5ミリ秒となっている（が、実際には数ミリ秒）。

RHEL3/4で確認

DB2

Club DB2	IBMのDB2の人たちが開催している勉強会
Unofficial DB2 BLOG	Club DB2のメンバーの一人が作っているブログ

先週の土曜日にIBMのDB2チームが開催しているClub DB2の『【土曜開催】 さわってみよう DB2 9.7』に参加してきました。

なぜかDB2の上位資格を持っている私ですが、実際にはほとんどDB2に触れたことがありません。試験対策本やDB2新機能の本を読んで楽しんでいるので多少は知っているつもり。

データベースってなんだか不思議な気がしてとても興味を持っているのですが、せいぜいSQLを書くくらいです（前の現場では4000行を超えるSQLを書いたことがあります）。

今回のハンズオンは題名からわかるとおり、どちらかというと初心者向けの会でした。会の流れとしては、まず「DBやSQLってどんな感じのものなの？」というお話を聞いて、後は用意されたテキストに沿ってSQLのお勉強＋DB2と仲良くなる時間となっていました。終了時間までは何をしてもOK！

SQLはだいたい知っているのでテキストはすぐに終わりました。ですので、普段触ることのないDB2でいろいろ遊んでいました。

・fromテーブルの作成
　DB2ではSQLの単語をテーブル名やカラム名に設定できると言うことを聞いていたので試してみました。
CREATE TABLE FROM(
SELECT SMALLINT,
FROM SMALLINT,
WHERE SMALLINT,
GROUP_BY SMALLINT,
ORDER_BY SMALLINT
);

　そして、適当なデータを挿入し、SELECT。

SELECT FROM FROM FROM
とか
SELECT SELECT FROM FROM WHERE WHERE ORDER BY ORDER_BY
という実務で発見したらぶちぎれそうなSQLを実行して楽しみました。

・新ロック機能"CS with CC"の体験
　何という言葉の短縮形だかは忘れてしまいましたが（CCは"Currently Committed"）、Oracleに近い動きができるように追加されたらしいです。

　DB2の元々の動きとしては、テーブルAのデータをUPDATEして未コミット状態でいる場合、ほかのユーザーがテーブルAをSELECTしてもロックがかかっている状態なのでデータの取得ができません。

　今回新しく追加されたこの機能を有効にした後に上記と同じSQLを実行すると、変更前のデータを読み込んできてくれます。

　これが良いか悪いかは現場によりますね。

・CLP Plus
　なんだかOracleに迎合しているような気がしますが、SQL *Plusにかなり近い感じでオペレーションすることができます。
　dual表を使用することもできますし、表示レイアウトをOracleのコマンドで設定することもできます（"set pages"や"set lin"など）。


　お勉強が終わったらIBMの人と、Club DB2に参加した人たちとの懇親会に行きました。

　土曜日に勉強・・・という感じですが、達成感のある午後でした。