月別アーカイブ: 2015年8月

箱根湯本駅まで往復

ケイデンス・センサーを付けてみた

最近、iPhoneが高機能サイクルコンピュータになるアプリ「Runtastic Road Bike PRO GPS サイクルコンピュータ」を使い始めましたが、iPhone単体だとGPS信号でのみ速度・走行距離の計測をするため、正確な値が得られていないような気がしたため「TOPEAK(トピーク) パノバイク ブルートゥース スマート スピード & ケイデンス センサー」というケイデンス(1分間あたりのクランクの回転数・単位はrpm)と車速がわかるセンサーを愛車に付けてみました。

テストを兼ねて箱根湯本駅まで往復

ケイデンスセンサーのテストを兼ねて、短い夏休みの最終日、自宅のある藤沢から箱根湯本駅まで往復(83km弱)してみました。

箱根湯本駅往復コース

小田原まで国道1号線をひた走る間は比較的平坦な道のりですが、小田原城を過ぎて箱根登山鉄道のガードをくぐったあたりから箱根湯本駅までずっと上り坂が続きます。(海抜約100m)

復路は途中まで往路と同じですが、大磯から国道134号線を海沿いに走るコースです。

涼しいと楽

今日は一応8月最終日ですが、猛暑だった頃が嘘のような涼しさです。昨日はずっと雨がふっていたので路面が若干濡れていてペイント上でスリップをしないように気をつけて走りましたが、涼しいとやはり走るのは楽です。

ただし、湿度は高目なので途中の給水はまめに行いました。

ケイデンス80rpm以上をキープ

今までは力まかせに重いギアでこいでいましたが、今日はせっかくケイデンス・センサーを付けたので、ケイデンス80rpm以上をキープするように注力してみました。

単調な道が続いてだんだんケイデンスが落ちてくると、これまでだったらギアを変えずにそのまま我慢していましたが、今日は躊躇なく1段軽くして80rpm以上をキープするようにしてみました。

ケイデンスが落ちてくるのは、上り坂なのか、向かい風なのか、それとも体力が落ちているからなのか、重いギアでガシガシ走っているとよくわからないのですが、80rpmを意識しているとそれがよくわかるような気がします。

ケイデンスをキープするということはタイヤから路面に伝わる力が変わらないということなので上り坂でもスピードがそれほど落ちません。

箱根湯本駅に到着

箱根湯本に到着

箱根湯本駅に至る道はだんだん急になって途中ギアを一番軽くする箇所もありましたが、ケイデンスに注意したおかげで初めてにしてはそれほど力を使い切る感もなく目的地に到着できました。

上の写真は坂を登りきって左端の箱根湯本駅までラストスパートしているところですが、左上のケイデンスは82rpmありますしスピードもそこそこ出ています。

箱根湯本駅

 

今日まで夏休みですが、箱根山の警戒レベルが上がっていることと、平日であること、それよりもまだ9時前なので人通りは少なかったです。

箱根山は遠い

箱根山

写真は昨日までの雨で普段より水量の多い早川ですが、この山を越えたところに芦ノ湖があります。箱根駅伝の5区を走る選手はここ箱根湯本から山道を一気に登っていきます。

私もいつかは箱根ヒルクライムに挑戦したいと思いますが、相当減量しないと。。。

スピードが速すぎる?

箱根湯本駅まで事前に測ったところ42km弱のはずだったのですが、Runtastic Road Bike PROが示す距離は49km弱とかなりの誤差があります。途中のスピードも「こんなに速くていいのかな?」というくらいの表示です。

実はケイデンス・センサーを取り付けた後にアプリ内でタイヤの外周をセットするようになっているのですが、その値を間違って多めに設定してしまったようです。感じとしては2割くらい速くなっているようです。

走行距離も速度を積算しているようなので、実際より多めに出てしまっています。

もう一度外周を正確に測り直して設定する必要がありそうです。

初の100km超え?

箱根湯本往復2015.08.31

 

帰りは国道134号線沿いに海を見ながら帰りました。アプリ上は走行距離104km以上と初の100km超えを達成したように見えますが、前述のように2割くらい多めに算出されていますので、リアルな100km超えはまた次の機会に挑戦します。

それでも、全走行時間のうちケイデンス80-94rpmの時間が45%、平均ケイデンスが78rpmだったので、初めてにしてはまずまずでした。

戦後70年に亡き祖父を想う

両祖父はシベリア抑留経験者

私の祖父は2人ともすでに他界していますが、共に旧満州で70年前に敗戦を迎えその後3年間シベリアに抑留されました。

極寒の地で強制労働に従事させられ、多くの同胞ははかなくも命を落としました。2人は必死に生き延び無事に帰国してそれぞれの家族と再会するのですが、それまでの3年間は熾烈を極めました。

2人は満州時代からお互いをよく知る仲でもあったのですが、やがてその子供同士が結ばれ生まれたのが私です。だから祖父たちに想いを馳せるとその運命に驚かずにはいられません。

抑留経験はあまりにも過酷だったのでしょう、私は直接じっくり話を聞いた覚えがないのですが、例えば「ノルマ」という言葉、これはロシア語で「強制的に与えられた仕事」の意味だそうでシベリア抑留者が持ち帰った言葉とも言われています。例えば「1日で丸太の伐採10本」というノルマを達成できないと食事を抜かれたりという生活が毎日続きました。

ある時は、毒がはいっているとわかっているまんじゅうを出されたことがあったらしく、仲間の一人が空腹に耐えかね食べてしまい目の前で口から泡を吹いて死んでしまったこともあったそうです。

母方の祖父は今から34年前に亡くなったのですが、旧制一高(現東京大学)で学んだくらい聡明であるだけでなく、亡くなる直前まで日記を書いていたような実直な人でした。シベリア抑留時代も必死に記録を続け、その一部をかろうじて持ち帰りました。

祖父が亡くなった後、祖父をよく知る方々が苦労してその記録を一冊の本にまとめました。

遺稿集「生き残る」

生き残る

これが祖父が残したかけがえのない記録をまとめた本ですが、自分だけでなく後世にも残すべき貴重な内容なので昨年くらいから少しずつ電子化しようとしています。

昭和20年8月9日から始まる記録ですが、はしがきの部分だけこの場を借りて紹介したいと思います。


はしがき

満州国熱河省で役人生活をしていた私は承徳で終戦の日を迎えた。この地に在った西南防衛司令部は「命に依り……」と称していち早く司令官以下錦州市へ引き揚げながら、残留部隊とくに憲兵隊と在郷軍人会に命じて在留全邦人の徹底抗戦を強要した。女子供だけの疎開が八月十四日になって辛くも実現した。

入院中の一在郷軍人が、周囲のはからいで妻子と同じ引揚列車に乗り込もうとしたとき、駅警戒中の憲兵はうむを云わさず彼をひきずり降ろした。割当の済んだ客車の一つを、急に軍用車に変更になったからと乗客を下車させ、目の前で軍用貨物を積み込んだが、それは日本酒と麦酒の詰まった函の他将校家族の洗濯盥から下駄箱まで忘れない引越荷物だった。

聖徳放送局は憲兵隊におさえられ、十四日正午の玉音放送をはじめ終戦処理に関する報道は完全に禁止された。省公署の無電室でたまたま聴いていた数名の者も「この完全なデマ放送」を絶対に口外せぬことを誓約させられた。愚劣極まる混乱が十九日まで続いた。
省次長岸谷隆一郎氏は「徹底抗戦」のナンセンスと全邦人の急速疎開を主張した。進駐軍を待つためにはごく少数の幹部だけ残留すれば充分だとの彼の意見は、結局圧しつぶされた。一万三千の一般民団員はこの日へ兵営になっている承徳離宮に収容された。次長は最後の一人が行進の列に加わるのを見届けてから、自宅で夫人、二令嬢と毒を仰いで自決した。

我々は民団員なので、抑留されるなどとは夢にも考えず、ただ暴民から生命を護ってもらうために、離宮入りをしたのだと思っていた。しかし、我々の身柄を捕らえたソ連外蒙進駐軍の隊長は、一般民団員と兵隊との間に何の区別も見出してはくれなかたった。その理由についてはいろいろの説があった。進駐軍の側から事前交渉で「非戦団員は八月十六日までに奉天錦州の線まで後退させよ。爾後の残留者は戦闘員とみなす」との通牒をこちらの憲兵が握りつぶしたという説。六十万あった筈の関東軍を捕虜にしてみたら四十五万しかなかったので、不足分の穴埋めに地方人を捕らえたのだという説。

いずれにしても民団を兵隊から区別してもらう数限りない努力が払われ、離宮抑留中から輸送の途中、更にウランバートルに着いてからも、口頭といわず文書といわず、スターリン首相、モロトフ外相、チョイバルサン外蒙政府首席をはじめ収容所長、政治指導員に至までの執拗な嘆願と要求が続けられたのだが、結局すべては無駄だった。かくて遡北の地における地獄の三年間がわれらを迎えたのである。

輸送中の貨車の中から私の日記は始まったのだが、収容所生活も労働が次第に強化され、帰還の近づいた頃は文字通り睡眠時間もなくなり、寸刻を見つけては場所を選ばず尻を下し、仮眠をとるのにせいいっぱいだったので、とても鉛筆を握る余裕がなかった。日記の上で回顧できる生活は、その頃のうちでも、とにかく時間的にも或る程度のゆとりのあったことを示すものである。

紙に不自由しながら苦労してこしらえた小さなノートが三冊溜ったが、苦心して無事持ち帰れたのは内二冊だけだった。その中から抄録してみることにした。

昭和二十三年一月


なぜ今、70年前の記録を見返す必要があるのか

このようなはしがきから始まる本ですが、なぜ罪もない民間人であった祖父がソ連の捕虜として捉えられ、シベリアの地で強制労働に従事させられなければならなかったのか?

平和な現代からは想像もできないような理不尽なことが70年前に実際に行われていたという事実は決して風化させてはなりません。

このはしがきは何度でも読み返さなければならないと思います。

祖父の配偶者である祖母は94歳の今も健在で、今日も私の家族と楽しく食事会をしましたが、そのような場でも祖母は必ず「戦争は二度としてはならない。」ということを何度も強調します。

近い将来、日本が戦争をする国になってしまったら、祖父母の世代に対して顔向けができません。

なぜ日本が無謀な戦争に突き進んでしまったのか、それを今真剣に考えるべき時だと思います。

オギノパンは自転車野郎御用達

神奈川県では有名なパン屋さん

神奈川県相模原市を本拠地とする「オギノパン」というパン屋さんがあります。
最近テレビでもよく紹介されていて、昔懐かしい「あげぱん」が人気の店です。

先日、横浜に買い物に行ったところ、デパートの一角の臨時店舗で名物のあんぱんを売っているのを偶然目にしたのですが、なぜかロードバイクが一緒に展示されていたので、そのことを店員さんに質問したところ、最近特にカロリーが必要なサイクリストにあげぱんが人気なのだそうです。

ということで、昨日の土曜日(8月8日)に家から片道20キロもかからない厚木店にロードバイクで行ってみることにしました。

暑くなる前に出発

最近は猛暑日が続いているので、なるべく早く出発するようにしています。

先週は朝4時半に出発して三浦半島の先端にある城ヶ島公園に行ってきたのですが、往路は日もまだ低く快調でした。

ところが、城ヶ島公園で少しゆっくり休憩し過ぎたので、出発が7時半くらいになってしまい復路は日差しが強くなってほとんど熱中症になりかけながらやっとのことで82キロの道のりを帰って来ました。

いつかは100キロ超えを達成したいと思っているのですが、この猛暑の中では無謀な挑戦なので、今週末は50キロ程度のコースを走ろうと考えていたところ、オギノパンのことを思い出したので行ってみることにしました。

結局出発は6時になってしまいましたが、なるべく最短コースを選んでオギノパン厚木店にまっしぐらです。

オギノパン往復

6時に出発したのは訳があって、実はこの厚木店は土日は7時に開店です。(平日は9時半開店)
あまり早く出発し過ぎても開店を待つことになってしまうので、7時半くらいに着くように出発しました。

オギノパン厚木店

オギノパンにはテラス席(向かって右)があって、焼きたてのパンをすぐに食べることができるようになってます。

バイクスタンド

ロードバイク用のバイクスタンドがあったりして、サイクリストにはうれしい店です。(この他にも店の外に清潔なトイレが完備されていたりもします。)

揚げパンとエッグカルボ

あげぱんを買おうとしたところ、「あと1分くらいお待ちいただければ、揚げたてのパンをお出しできますよ!」という店員さん。この辺の心遣いが憎いです!

その他、この店は少しボリュームのある調理パンがとても美味しそうで、右は「エッグカルボ」という中に卵が入ったなかなかの一品でした。

この2つでなんと358円なので、朝から得した気になりました。(あげぱんは110円です。)

この日は気温が高くなりそうだったので、急いで来た道を帰りました。(往復で約39キロ)

まさかの2日連続

今日(8月9日)は、特に目的地を決めずにひたすら北に向かって走ったのですが、小田急線の相武台前駅まで来たところ、このまま町田方面に行くかどうかでなんとなくその気分にならずに座間から厚木方面に向かうことにしました。

先週や昨日と比べかなり涼しかったこともあり、ちょっと無理してみようという思いも背中を押しました。

相武台前からオギノパン

厚木まで来たら、今度は昨日行ったオギノパンにまた行きたくなったので急遽寄り道です。

アーモンドチョコデニッシュとミートソースピザ

今日はあげぱん以外に挑戦してみようと思い、アーモンドチョコデニッシュ(左)とミートソースピザ(右)です。これで410円!コストパフォーマンス高いです。

名物丹沢あんぱん

昨日手ぶらで帰ったところ、奥さんから「お土産は?」と責められたので、今日は名物のあんぱんをおみやげに買って帰りました。(ロードバイクは荷物を入れるところがないので、袋をハンドルに結びつけるという恥ずかしいやり方で持ち帰りました。)

ダイエット目的でも始めた自転車ですが、途中のグルメを楽しむという楽しみが病みつきになりそうです。

帰りは昨日と同じ道。今日は52キロ、昨日と合わせて90キロ超え。いい汗をかきました。

STATSPACKデータをExcelでグラフ化する②〜DBバッファ編1〜

今週の名言

「自分が多数派の側にいると気付いたら、もう意見を変えてもいい頃だ。」
マーク・トウェイン

最近、マーク・トウェインの名言が多いですが、偶然です。

DBバッファの統計を調査する。

前回は、stats$snapshot表からスナップショット一覧を取得するSQL文を紹介しました。
今回から、応用編としてこの表とパフォーマンス・データが格納された表を結合して、1日の統計情報の推移を見てみます。
最初は取っ付き易いDBバッファについて調べてみましょう。

DBバッファヒット率の計算式

DBバッファの目的は、頻繁にアクセスされるDBブロックをなるべくメモリ(DBバッファ)に保持しておくことで、低速なディスクI/Oを回避することです。DBバッファ・ヒット率とは、要求されたDBブロックがバッファ内に存在していた割合を示すもので、以下の計算式によります。

DBバッファヒット率
=((CONSISTENT_GETS + DB_BLOCK_GETS)-(PHYSICAL_READS))➗(CONSISTENT_GETS + DB_BLOCK_GETS)✖️100

データ取得SQL文

DBバッファヒット率を取得する方法はいくつかありますが、ここではSTATS$BUFFER_POOL_STATISTICS表を使用する方法を紹介します。
この表はV$BUFFER_POOL_STATISTICSのスナップショットを保持しているものです。
また、DBバッファヒット率だけではなくBuffer Busy Wait統計情報も一緒に取得します。

今回のSTATSPACK環境は前回とは違って1時間ごとにスナップショットを取得している環境です。

select
os.INSTANCE_NUMBER
,to_char(trunc(os.SNAP_TIME,'mi'),'yyyy/mm/dd hh24:mi') sdate
--,os.SNAP_ID SNAP_ID1
--,ns.SNAP_ID SNAP_ID2
,nb.NAME buffer_pool_name
,decode(( (nb.CONSISTENT_GETS - ob.CONSISTENT_GETS)
         +(nb.DB_BLOCK_GETS   - nb.DB_BLOCK_GETS)),0,0,  -- 0除算回避
(trunc((((nb.CONSISTENT_GETS - ob.CONSISTENT_GETS)
         +(nb.DB_BLOCK_GETS   - nb.DB_BLOCK_GETS)
         )
         -(nb.PHYSICAL_READS  - ob.PHYSICAL_READS)
        )
        /((nb.CONSISTENT_GETS - ob.CONSISTENT_GETS)
         +(nb.DB_BLOCK_GETS   - nb.DB_BLOCK_GETS)
         )*100,1
       )
)
) bhr
,nb.BUFFER_BUSY_WAIT - ob.BUFFER_BUSY_WAIT bbw
from
STATS$SNAPSHOT os
,STATS$SNAPSHOT ns
,STATS$BUFFER_POOL_STATISTICS ob
,STATS$BUFFER_POOL_STATISTICS nb
where 1=1
and trunc(os.SNAP_TIME,'mi') between to_date('xxxx/xx/xx 00','yyyy/mm/dd hh24')
                                 and to_date('xxxx/xx/xx 23','yyyy/mm/dd hh24')
and trunc(ns.SNAP_TIME,'mi') = trunc(os.SNAP_TIME,'mi') + 1/24
and os.SNAP_ID               = ob.SNAP_ID
and os.DBID                  = ob.DBID
and os.INSTANCE_NUMBER       = ob.INSTANCE_NUMBER
and ns.SNAP_ID               = nb.SNAP_ID
and ns.DBID                  = nb.DBID
and os.INSTANCE_NUMBER       = ns.INSTANCE_NUMBER
and os.INSTANCE_NUMBER       = nb.INSTANCE_NUMBER
and os.INSTANCE_NUMBER       = 1
order by
os.instance_number
,to_char(os.SNAP_TIME,'yyyy/mm/dd hh24mi');

実行例

実行例は以下のようになります。

SQL> set pages 50
SQL> col BHR for 990.0
SQL> select
  2   os.INSTANCE_NUMBER
  3  ,to_char(trunc(os.SNAP_TIME,'mi'),'yyyy/mm/dd hh24:mi') sdate
  4  --,os.SNAP_ID SNAP_ID1
  5  --,ns.SNAP_ID SNAP_ID2
  6  ,nb.NAME buffer_pool_name
  7  ,decode(( (nb.CONSISTENT_GETS - ob.CONSISTENT_GETS)
  8           +(nb.DB_BLOCK_GETS   - nb.DB_BLOCK_GETS)),0,0,  -- 0除算回避
  9   (trunc((((nb.CONSISTENT_GETS - ob.CONSISTENT_GETS)
10           +(nb.DB_BLOCK_GETS   - nb.DB_BLOCK_GETS)
11           )
12           -(nb.PHYSICAL_READS  - ob.PHYSICAL_READS)
13          )
14          /((nb.CONSISTENT_GETS - ob.CONSISTENT_GETS)
15           +(nb.DB_BLOCK_GETS   - nb.DB_BLOCK_GETS)
16           )*100,1
17         )
18   )
19  ) bhr
20  ,nb.BUFFER_BUSY_WAIT - ob.BUFFER_BUSY_WAIT bbw
21  from
22   STATS$SNAPSHOT os
23  ,STATS$SNAPSHOT ns
24  ,STATS$BUFFER_POOL_STATISTICS ob
25  ,STATS$BUFFER_POOL_STATISTICS nb
26  where 1=1
27  and trunc(os.SNAP_TIME,'mi') between to_date('2015/07/28 00','yyyy/mm/dd hh24')
28                                   and to_date('2015/07/28 23','yyyy/mm/dd hh24')
29  and trunc(ns.SNAP_TIME,'mi') = trunc(os.SNAP_TIME,'mi') + 1/24
30  and os.SNAP_ID               = ob.SNAP_ID
31  and os.DBID                  = ob.DBID
32  and os.INSTANCE_NUMBER       = ob.INSTANCE_NUMBER
33  and ns.SNAP_ID               = nb.SNAP_ID
34  and ns.DBID                  = nb.DBID
35  and os.INSTANCE_NUMBER       = ns.INSTANCE_NUMBER
36  and os.INSTANCE_NUMBER       = nb.INSTANCE_NUMBER
37  and os.INSTANCE_NUMBER       = 1
38  order by
39   os.instance_number
40  ,to_char(os.SNAP_TIME,'yyyy/mm/dd hh24mi');

INSTANCE_NUMBER SDATE            BUFFER_POOL_NAME        BHR        BBW
--------------- ---------------- -------------------- ------ ----------
              1 2015/07/28 00:00 DEFAULT               100.0          0
              1 2015/07/28 01:00 DEFAULT               100.0          1
              1 2015/07/28 02:00 DEFAULT               100.0          0
              1 2015/07/28 03:00 DEFAULT               100.0          0
              1 2015/07/28 04:00 DEFAULT               100.0          0
              1 2015/07/28 05:00 DEFAULT               100.0          0
              1 2015/07/28 06:00 DEFAULT               100.0          1
              1 2015/07/28 07:00 DEFAULT               100.0          0
              1 2015/07/28 08:00 DEFAULT               100.0          0
              1 2015/07/28 09:00 DEFAULT               100.0          0
              1 2015/07/28 10:00 DEFAULT               100.0          0
              1 2015/07/28 11:00 DEFAULT               100.0          0
              1 2015/07/28 12:00 DEFAULT               100.0          0
              1 2015/07/28 13:00 DEFAULT               100.0          0
              1 2015/07/28 14:00 DEFAULT               100.0          1
              1 2015/07/28 15:00 DEFAULT               100.0          0
              1 2015/07/28 16:00 DEFAULT               100.0          2
              1 2015/07/28 17:00 DEFAULT                99.9          5
              1 2015/07/28 18:00 DEFAULT               100.0          0
              1 2015/07/28 19:00 DEFAULT               100.0          0
              1 2015/07/28 20:00 DEFAULT               100.0          0
              1 2015/07/28 21:00 DEFAULT               100.0          0
              1 2015/07/28 22:00 DEFAULT               100.0          0
              1 2015/07/28 23:00 DEFAULT               100.0          0

24行が選択されました。

この環境はアクティビティがほとんどないので、DBバッファヒット率はほぼ100%ですが、お手元のSTATSPACKではどのような結果が得られるでしょうか?
この結果を、MS Excelのシートにコピー&ペーストしてグラフにしていくのですが、その要領は次回で紹介します。

テーブルの結合列について

STATS$SNAPSHOT表の主キーを構成する列を確認すると「SNAP_ID,DBID,INSTANCE_NUMBER」の3つの列から成っていることがわかります。

SQL> select TABLE_NAME,CONSTRAINT_NAME,COLUMN_NAME,POSITION
  2  from USER_CONS_COLUMNS
  3  where CONSTRAINT_NAME = 'STATS$SNAPSHOT_PK'
  4  order by POSITION;

TABLE_NAME      CONSTRAINT_NAME    COLUMN_NAME       POSITION
--------------- ------------------ --------------- ----------
STATS$SNAPSHOT  STATS$SNAPSHOT_PK  SNAP_ID                  1
STATS$SNAPSHOT  STATS$SNAPSHOT_PK  DBID                     2
STATS$SNAPSHOT  STATS$SNAPSHOT_PK  INSTANCE_NUMBER          3

一方、結合表であるSTATS$BUFFER_POOL_STATISTICS表の外部キーを確認すると、同様に「SNAP_ID,DBID,INSTANCE_NUMBER」となっていることがわかります。

SQL> select TABLE_NAME,CONSTRAINT_NAME,COLUMN_NAME,POSITION
  2  from USER_CONS_COLUMNS
  3  where CONSTRAINT_NAME = 'STATS$BUFFER_POOL_STATS_FK'
  4  order by POSITION;

TABLE_NAME                    CONSTRAINT_NAME              COLUMN_NAME       POSITION
----------------------------- ---------------------------- --------------- ----------
STATS$BUFFER_POOL_STATISTICS  STATS$BUFFER_POOL_STATS_FK   SNAP_ID                  1
STATS$BUFFER_POOL_STATISTICS  STATS$BUFFER_POOL_STATS_FK   DBID                     2
STATS$BUFFER_POOL_STATISTICS  STATS$BUFFER_POOL_STATS_FK   INSTANCE_NUMBER          3

STATSPACKデータのグラフ化は、基本的にSTATS$SNAPSHOT表と関連する表を結合してデータを取得しますが、結合列はこれら3つの列を必ず指定するようにしましょう。

続く