このエントリーは #kabepy Advent Calendar 2013 の18日目です。

昨日のエントリは akifumu さんの「 #kabepy Advent Calender　武蔵小杉　ポケット」でした。

今日のお題はクライミング・シューズです。
昨年の #kabepy アドベント・壁ンダーでもシューズ関連のエントリがあったと思うので、これからクライミングをやってみようかなーと考えてる方はそちらも覗いてみてください。

で、誰かも書いていましたが、ボルダリングで使用する唯一の道具がクライミング・シューズです。
あ、一応すべり止めでチョークの粉は使いますが、身に付けるものとしてはシューズのみです。
あれ、裸でクライミング・シューズ履いてるみたいに聞こえる。
そういう訳じゃないです。念のため。

サッカーでもバスケでも陸上でもシューズはとても重要ですが、クライミングでももちろん重要です。
しかもシューズしか使わないので、しっかり自分に合ったシューズを履いているかどうかの違いが占めるウェイトは、快適さや上達によってとても大きいものです。

名前や見た目のかっこよさでシューズを選ぶと後悔することになります。（自戒）

間違っても
「なになに？Pythonボルダリングクラブ？　じゃぁPython履かないと」
とか言って、ノリでシューズを選んでは行けません。（超自戒）


「俺がPythonだ！うぇ〜い」とか言って盛り上がるかと思ったらガチで「シューズはちゃんと選ぼうよ」とか結構本気で怒られることになります。
そんな人はいないと思いますが。


クライミング・シューズの選び方は、少しググってみれば色々でてきますが、個人的には足の形に合っているかどうかと、サイズがとても重要だと思います。
3日目のエントリで @yotchang4s さんも書いていますが、クライミングはつま先で小さなホールドに乗ります。
この時にブカブカのシューズでは、シューズの先が体重を支えきれず滑り落ちてしまいます。
ですので、シューズのつま先の部分にぎゅっと足を詰め込めるように通常の靴よりも小さめのサイズを選びます。
で、この小さなシューズに足を詰め込むというところで、シューズの形が足に合っていないと痛くて立つことすらできません。
シューズの形には大きく2つの特性があります。
・縦の曲がり方：つま先が下がっているか、平坦な形か
・横の曲がり方：つま先が内側に曲がっているか、まっすぐな形か

言葉じゃわかりにくいですね。
こんな感じです。
下の写真は初心者がノリで選ぶと後悔することになるかもしれない（「かもしれない」ですよ。誰か後悔した人がいるかどうかは知りません）その名も「Python」です。かっこいいですね。



だいぶ履きこんだのでクタってますが、つま先が下に下がってるのがわかります。

一方こちらのシューズは平坦です。

（指の付け根のあたりが削れてますね。つま先でちゃんと乗れてないのがバレちゃいますね。）

次は横方向の曲がり方です。
超かっこいいPython。

内側にむかって曲がっています。

ではこちら。

まっすぐですね。

この曲がり方が自分の足の形に合っていないと、足をぎゅーぎゅーに詰め込んだ時に涙が出るほど痛いと感じます。
立つことができないほど痛いのでは話になりませんし、実際に登った時に痛くてつま先でホールドに乗れないでは本末転倒です。
かと言って、足の形に合わないシューズなのに痛くないように大きなサイズを選んでも、結局つま先でホールドにのれません。
ゴリゴリのクライマーは「痛いくらいのサイズがいいんです」とか言ったりしますが、痛くて登るのが楽しくないのは意味がありません。
ということなので、シューズを選ぶときは、とにかく色んな種類のシューズの、色んなサイズを試履しまくってまずは足の形に合うものを見つけましょう。
そうじゃないと、結局すぐに買い直すハメになります。

クライミングジム内にもショップが併設されていることがありますが、サイズが揃ってなかったりすることもありますので、目黒　目白のカラファテさんなんかがしっかりアドバイスしてくれてお勧めです。
それと、同じサイズのタグがついていても、UK表示とUS表示では実寸が違うなんてことがあります。
試履は実店舗で、購入は通販とかやるとサイズ違いになることもあるのでご注意を。



そんなわけで、
俺がPythonだ！
とかそんなネタは忘れて、足にあったシューズで快適なボルダリング生活をどうぞ。

私の汚いシューズでPythonダサいと思われたら困るので、メーカーのかっこいい写真へのリンクを貼っとく。
http://climbs.shop-pro.jp/?pid=34817118

このエントリーは #kabepy Advent Calendar 2013 の13日目です。

昨日のエントリは @inoshiro さんの「外壁初体験 in 鷹取山」でした。


今日のお題は「吉祥寺Volnyの紹介」です。

#kabepy の部活はB-Pump秋葉原がメインですが、私は東京の西側に住んでることもあり、B-Pump荻窪か、吉祥寺Volnyに行くことが多いです。
一時期Volnyのメイヤーも取れてたんですが、しばらくお休みしている間に奪還されました。

では基本的な情報です。

所在地：東京都武蔵野市吉祥寺北町1-18-3


大きな地図で見る

電話番号：0422-77-6381
Webサイト：http://climbingcaffe.jugem.jp
営業時間：平日 14:00～23:00／土日祝 11:00～21:00

ジム内の様子


見てわかるように、それほど広くないジムです。
写真には写っていませんが、左手側手前に垂直壁。8級〜4級くらい。
右手側にスラブ。8級〜7級。
その隣に写真右側に写っているちっこいホールドの傾斜壁。
左手がゆるい傾斜壁で6級〜3級。
右手奥から正面がキツ目の傾斜壁で、課題レベルを表すシールはあまり貼ってなくて、ジムに用意されている課題管理シートを見ながら登るようになっています。
多分4級くらい〜上限なしな感じだと思います。（私はまだそこまで辿りつけてないので…）

このジムのいいところ。
1.利用料金が少しお安めです。
それと月会員の料金も、平日のみ or 平日+週末で別プランがあるので、がっつり通いたい場合はよいかもしれません。

2.狭い分、1つの課題に集中できる。
これはB-Pumpに通ってるといつも思うのですが、ちょっと難しめの課題にトライして、うまくいかないとすぐに違う課題に逃げちゃうことがあります。
でもここだと別の課題があんまりありませんｗ
集中して課題にトライできます。

3.きちんと体を使わないとクリアできないように課題が設置されている。
腕力だけでワシワシ登れる課題はあまりありません。
足がちゃんと使えてないときつい課題が多いです。
それと、基本は手足限定課題になっていて、しかも足はつま先でちゃんと乗れないとスタートすらできないような感じのものが多いです。
なので、初心者だといきなりスタートすらさせてもらえずに凹むことがあるかもしれませんが、ここできっちり基本を抑えると、他のジムに行った時に同じ等級でも楽に感じます。

ちょっと残念なところ
鍵のかかるロッカーがありません。
どうしても気になるなら、吉祥寺駅内のコインロッカーを使いましょう。
それと、やはり狭いので混んでる時は素直に時間を変えるほうがいいかもしれません。


個人的にはまったりと登れるジムで気に入っています。
行く機会があったら是非ご一緒しましょう。

このエントリーは #kabepy Advent Calendar 2013 の9日目です。

昨日のエントリは @kiris さんの「#kabepy Advent Calendar 2013 #8 スランプの時にやったこと」でした。


壁、登ってますか？

私は3ヶ月ほど気力と体力が低迷しており、実はずっと登っていません。
そんな私がアドベント壁ンダーに参加しちゃっていいのか気になりますが、とりあえず9日目を担当します。


今日のお題は「地方遠征のススメ」です。

インドアボルダーの皆さんは普段決まったジムに通ってる方が多いんじゃないでしょうか。
ジム毎に初回の会員登録の料金がかかりますし、同じジムの課題を順番にクリアしていく楽しみもありますので、日常的に通うジムは2つとか3つくらいなもんだと思います。
（#kabepy の手遅れ達はカード入れに5,6枚程、色んなジムの会員証が入ってるでしょうけど）
私も普段はB-Pump 荻窪店か吉祥寺Volnyがホームグラウンドで、それ以外のジムは誰かに誘われたりイベント事なんかで行くくらいです。

上でも書いたように、特定のジムに通うのにも、もちろんいいことがあります。
ですが今日はあえて違うジム。しかも近隣地域ではなく遠くの土地への遠征をお勧めしたいと思います。


地方遠征をお勧めする理由　その1　異なるクライマーコミュニティに触れられる。

東京でもジムによって雰囲気などが違いますが、地方のジムにいくと都内のジムとはまったく違ったコミュニティが形成されていることが多いです。
地方ではよくありがちなことですが、全員が顔見知りで、出身小学校、中学校、高校、職場などをお互いに知っていて、地域の先輩後輩の関係などがそのままジムの中にも持ち込まれていたりします。
自分の行きつけのジムでそんなのはちょっと勘弁してもらいたい感じですが、たまに遊びにいったジムでこのようなコミュニティが形成されていて、そこに混ざって登るのはなかなか楽しいものです。
教えたり教えられたりだけじゃなく、一緒におやつを食べて休憩したり、その土地の外岩の話を聞いたり。
毎回同じ壁、同じ課題に向き合ってるのとはまったく違う体験ができます。

# とは言っても、以前岩手県盛岡のジムで地元の人だと思って話をしてた人が、実は同じく旅行で来てた某都内のジムの店員さんだったなんていうこともありまして、なんだよどうりで都内のジムに詳しいわけだよとか思ったこともありますが。でもこんなのはレアケースです。



地方遠征をお勧めする理由　その2　課題のテーマが違う

これは別に地方じゃなくてもいいんですが。
屋内ボルダリングは人間が設置した課題を登るので、同じ等級の難易度の課題でも、設置者の意図や哲学によってまったく求められる動きが異なります。
私が普段通ってるジムでいうと、B-Pumpの6級くらいまでは基本ガバが多くて、足は指の付け根のあたりでも乗れるようなでかいホールドが多いです。
一方、吉祥寺Volnyは6級あたりからガバは少なめで指力が求められる課題が多く、ガバでもちょっと悪いので体の使い方をきっちりしないときつい感じです。
足は、スタートの時点でつま先じゃないと乗れないものがほとんどです。
こうした違いは、外岩のための練習としての屋内ボルダリングなのか、1つの独立したジャンルとしてのボルダリングなのか、課題を設置した人の哲学による違いだと思っています。
都内のジムでも、ジム毎にこれだけ違いがあるわけですから、地方へ行くとまったく課題の性格が違います。
横ムーブばっかりのジム。スローパーだらけのジム。スラブがやたら充実してるジム。
こうしたジムの方向性が見えてきたら、課題のクリアの仕方でもなんでもいいのでジムの人と話してみましょう。
どういうテーマで課題を設置してるのか聞けるかもしれませんし、なぜそのテーマなのかというところから、その人のクライミングに対する哲学が見えてきたりします。


地方遠征をお勧めする理由　その3　旅に出る言い訳として

旅に出る理由はなんでもよいと思っています。
例えば私もこんな理由で旅行に出てきました。

「うに丼食べたい」=>「北海道いくか！」
「チビ太のおでん食べたい」=>「静岡いくか！」
「ラフテー食べたい」=>「沖縄いくか！」

あれ、食べ物ばっかりだ。
まぁいいんですが。

で、どうでもいいような理由で旅にでるのもいいんですが、せっかく旅にでるのにその目的が弱いとなんかもったいなく感じてしまうことがあります。
旅費もバカにならないし。
そこで地方遠征です。
「牛たん食べたい」=>「仙台いくか！ついでに仙台で登るか！」
ほらなんか旅立ってもいい感じになりません？

「喫茶マウンテンに登ってみたい」=>「名古屋いくか！ついでに壁も登るか！」
ほら、なんか旅にテーマができた感じになった。

なんかちょっとした食べ物のためだけに旅にでる。なんか贅沢な感じ。
壁遠征のためだけに旅にでる。ちょっと手遅れ臭がして嫌。
だけど、ちょっと美味しい物食べたいし、ついでに壁も登れるから旅にでる。
いいじゃない。
旅行の計画を建てるのが楽しくなります。


ということで、地方遠征っていいよという話でした。
地方のジムを探すのは、[土地の名前]　[クライミングジム]とかで適当にググれば見つけられますけど、以下の本に都道府県別クライミングジムリストが載ってるので、眺めながら遠征先を考えるのも楽しいと思います。
インドアボルダリングBOOK (エイムック 2562)


ここで私事ですが、12月28日、29日に宮城県仙台に遠征に行きます。
一応仙台市内で29日まで営業しているジムも調査済み。
もしかすると30日は盛岡にいるかもしれないけど、ここはまだちょっと未定。

上記の日程あたりで宮城県付近にいるクライマーさんは、仙台で僕と握手！
なにかあれば @nakunaru まで。


以上、#kabepy Advent Calendar 2013の9日目でした。
明日は @tmasda さんです。

PostgreSQLでは、1テーブル/1インデックス毎に1ファイルが割り当てられる。
ディスク容量にあまり余裕がない場合などに、大きなファイルを持つテーブルを、別ディスクに移動させたければ、

    ALTER TABLE 表名 SET TABLESPACE テーブルスペース名;

などとして別領域へ移動させたい場合がある。

しかし、ファイル名には一意な数値が使用されているため、どのファイルがどのテーブルのものなのかパッと見では判別できない。

以前、テーブルのファイル名を確認する方法を調査した時には以下のような方法を見つけた。
http://hitai.blog72.fc2.com/blog-entry-86.html



内容は以下のような感じ。

１．データベースのディレクトリ名を調べる

    SELECT datid, datname FROM pg_stat_database;

    datid | datname
    -------+------------
    10793 | postgres
    16406 | testdb2
    16542 | testdb
    1     | template1
    10792 | template0

例えばtestdb2の場合、$PG_DATA/base/16406/ がファイルの格納ディレクトリということになる。

２．テーブルのファイル名を調べる

    SELECT relid, relname FROM pg_stat_all_tables;
    
    relid | relname
    -------+-------------------------
    16492 | customer3
    2601  | pg_am
    10308 | pg_toast_2619
    10750 | pg_toast_10748
    2610  | pg_index
    16410 | emp
    2612  | pg_language
    16436 | orditems
    16427 | ord
    2620  | pg_trigger
    1214  | pg_shdepend
    2608  | pg_depend
    16456 | customer
    ・・・

例えばemp表の場合、$PG_DATA/base/16406/16410 というファイルだということになる。


・・・ということだったのだけど、これはDBのデフォルトテーブルスペースに格納されたテーブルの場合。
テーブルや索引毎に個別にテーブルスペースが指定されている場合には、当然そのテーブルスペースの配下に格納される。
また、テーブルスペースを移動させた場合などに、ファイル名が変わってしまうことがあるが、ファイル名とrelidは、連動していないため、この方法ではファイル名が追えなくなってしまった。

ということで、手順を再確認してみた。



ケース１：テーブル名から、ファイル名を確認したい場合

１．そのテーブルのテーブルスペースを確認

    select schemaname, tablename, tablespace from pg_tables where tablename='テーブル名';

         schemaname     |        tablename        | tablespace
    --------------------+-------------------------+------------
     u01                | emp                     |

tablespace列が空欄の場合はDBのデフォルトディレクトリ。
tablespace列にテーブルスペース名があれば、該当テーブルスペースに格納されている。
デフォルトディレクトリの場合はステップ２へ。
特定テーブルスペースの場合はステップ３へ。

２．DBのデフォルトディレクトリを確認

    SELECT datid, datname FROM pg_stat_database;

    datid | datname
    -------+------------
    10793 | postgres
    16406 | testdb2
    16542 | testdb
    1     | template1
    10792 | template0

datid列がディレクトリ名を表すので、
$PG_DATA/base//
が該当ディレクトリとなる。

テーブルのファイル名を確認するためにはステップ４へ。


３．テーブルスペースのディレクトリを確認する

    SELECT * FROM pg_tablespace;

      spcname   | spcowner | spclocation | spcacl | spcoptions
    ------------+----------+-------------+--------+------------
     pg_default |       10 |             |        |
     pg_global  |       10 |             |        |
     test       |       10 | /data/test  |        |

テーブルのファイル名を確認するためにはステップ４へ


４．テーブル/インデックスのファイル名を確認する

    select relname, relfilenode from pg_class where relname='オブジェクト名';

     relname | relfilenode
    ---------+-------------
     t1      |       16943

relfilenode列がファイル名を表す。
ということで、DBのデフォルトディレクトリ、またはテーブルスペースのディレクトリの配下のrelfilenodeを探せばよい、ということになる。


ケース２：ファイル名からテーブルを特定する

１．ファイル名の確認

    select * from pg_class where relfilenode='nnnnn';
    ※nnnnnにファイル名を指定

    relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode |
    ---------+--------------+---------+-----------+----------+-------+-------------+---------------+-
     t1      |        16414 |   16572 |         0 |    16412 |     0 |       16943 |         16567 |

２．ネームスペースの確認
必要であればネームスペースの確認（同じ名前のオブジェクトが複数あり得る場合）

    select * from pg_namespace;

          nspname       | nspowner |               nspacl
    --------------------+----------+-------------------------------------
     pg_toast           |       10 |
     pg_temp_1          |       10 |
     pg_toast_temp_1    |       10 |
     pg_catalog         |       10 | {postgres=UC/postgres,=U/postgres}
     information_schema |       10 | {postgres=UC/postgres,=U/postgres}
     u01                |    16412 |

ステップ１のrelnamespaceと同じnspname列の行が、該当ネームスペース。


という感じ。


で、これがめんどくさい場合は、上のリンク先でもつかった oid2name ユーティリティがある。
こっちはpsql上ではなく、OSコマンドとして使う。

    > oid2name --help
        oid2name helps examining the file structure used by PostgreSQL.
        
        Usage:
          oid2name [OPTIONS]...
        
        Options:
          -d DBNAME    database to connect to
          -f FILENODE  show info for table with given file node
          -H HOSTNAME  database server host or socket directory
          -i           show indexes and sequences too
          -o OID       show info for table with given OID
          -p PORT      database server port number
          -q           quiet (don't show headers)
          -s           show all tablespaces
          -S           show system objects too
          -t TABLE     show info for named table
          -U NAME      connect as specified database user
          -x           extended (show additional columns)
          --help       show this help, then exit
          --version    output version information, then exit
        
        The default action is to show all database OIDs.
        
        Report bugs to .

ということで、例えばこんな感じ。

    oid2name -d testdb -H localhost -p 5432 -U postgres -x -i

    From database "introsql01":
      Filenode    Table Name    Oid  Schema  Tablespace
    ---------------------------------------------------
         16943            t1  16570     u01        test
         16946        t1_idx  16946     u01        test
         16903           emp  16438     u02  pg_default
         ・・・

これをみると、t1はテーブル作成直後は16570というoidと同じファイル名だったのが今は16943というファイル名に変わっていることがわかるし、どのテーブルスペースなのかも確認できるので、あとは

    select * from pg_tablespace;

または

    select * from pg_stat_database;

でディレクトリも確認できる。

テーブル名から追いたい場合は -t テーブル名 オプションで絞込みが可能

        oid2name -d testdb -H localhost -p 5432 -U postgres -t テーブル名

でいいし、ファイル名から追いたい場合も

        oid2name -d testdb -H localhost -p 5432 -U postgres -x | grep ファイル名

でよい。

ただしSJIS以外のマルチバイド文字を使ったテーブル名があり、Windows環境の場合は文字化けが発生するのでテキストファイルにリダイレクトして、エディタで見るのがよいかも。

        oid2name -d testdb -H localhost -p 5432 -U postgres -x > ファイル名

多分普通にインストールしたPostgreSQLならoid2nameユーティリティがいるはずだけど、もしいないようであれば、http://hitai.blog72.fc2.com/blog-entry-86.html のように適当なソースからビルドしたバイナリが使えるはず。

今までの記事
db2dartで学ぶDB2ストレージ・アーキテクチャ　その１　表スペース内のエクステントについて
db2dartで学ぶDB2ストレージ・アーキテクチャ　その２　SMPの拡張タイミングについて


DB2の表スペースの内部構造について検証している今回のシリーズも、これで３回目の更新となります。
db2dartというツールを使って、表スペースの内部構造を調べていくという、やればやるほど誰得な企画になって参りました。
でもやりかけちゃったんで、とことん突き詰めて行きたいとおもいます。

１回目の記事では、表スペースの領域確保の仕組みについて、基本的な事柄を確認しました。
それから２回目の記事では、表スペース内の空きエクステント情報を管理するSMP（スペース・マップ・ページ）が拡張されるタイミングを検証しました。

３回目の今日は、オブジェクト毎に取られるEMP（エクステント・マップ・ページ）について確認していきます。


まずは軽く復習です。
表スペースを作成した直後、コンテナー内には４つのエクステントが確保されているんでした。

        エクステントID  開始ページ番号  終了ページ番号  役割
            ------------------------------------------------------
                    なし        なし            なし       コンテナー・タグ
                    0             0               3             表スペース・ヘッダー
                    1             4               7             SMP（スペース・マップ・ページ）
                    2             8               11             オブジェクト表データ

そして、この表スペース内に表を作成すると、表のEMPと、データ・エクステントで2エクステントが最初に確保されます。

       エクステントID  開始ページ番号  終了ページ番号  役割
            ------------------------------------------------------
                    なし        なし            なし       コンテナー・タグ
                    0             0               3             表スペース・ヘッダー
                    1             4               7             SMP（スペース・マップ・ページ）
                    2             8               11             オブジェクト表データ
                    3           12               15            表のEMP
                    4           16               19            表のデータエクステント

このEMPの中に、その表が確保したエクステントの位置情報が格納されています。


そして、最初のデータ・エクステントが一杯になると、あとは1エクステントずつデータ・エクステントを拡張していきます。

       エクステントID  開始ページ番号  終了ページ番号  役割
            ------------------------------------------------------
                    なし        なし            なし       コンテナー・タグ
                    0             0               3             表スペース・ヘッダー
                    1             4               7             SMP（スペース・マップ・ページ）
                    2             8               11             オブジェクト表データ
                    3           12               15            表のEMP
                    4           16               19            表のデータエクステント
                    5           20               23            表のデータエクステント
                       ・・・・

はい、ここで疑問です。
データ・エクステントが増加していくと、EMPに格納されている情報も増加します。
ということは、いつかEMPエクステントも溢れてしまうのでは？

ということでデータを増幅させて内部動作を確認してみました。
前回までと同じように、適当な表スペースを作成し、そこに表を作成し、ひたすらデータを増幅させます。


ある程度データ量が増えたら、db2dartをつかってEMPのダンプをとります。

db2dart <DB名> /DEMP /OI <オブジェクトID> /TSI <表スペースID>

そんで出てきた結果が以下のような感じになります。

    Object specific mapping info:
    -----------------------------
    DAT extent anchor: 12
    Traversing extent map for object type: 0
       Pool: 7, Object: 4 EMP page class: 64,
       EMP pool page: 12, # entries: 1000
       Page LSN = 0001 3B37 FE46
       Pool relative page #'s :
          16     20     24     28     32
          36     40     44     48     52
          56     60     64     68     72
       〜〜中略〜〜
        3956   3960   3964   3968   3972
        3976   3980   3984   3988   3992
        3996   4000   4004   4008   4012

       Pool: 7, Object: 4 EMP page class: 64,
       EMP pool page: 13, # entries: 1000
       Page LSN = 0001 3BF7 4AF2
       Pool relative page #'s :
        4016   4020   4024   4028   4032
        4036   4040   4044   4048   4052
      〜〜中略〜〜
        7976   7980   7984   7988   7992
        7996   8000   8004   8008   8012

       Pool: 7, Object: 4 EMP page class: 64,
       EMP pool page: 14, # entries: 1000
       Page LSN = 0001 3CB6 979E
       Pool relative page #'s :
        8016   8020   8024   8028   8032
        8036   8040   8044   8048   8052
      〜〜中略〜〜
       11976  11980  11984  11988  11992
       11996  12000  12004  12008  12012

       Pool: 7, Object: 4 EMP page class: 64,
       EMP pool page: 15, # entries: 32
       Page LSN = 0001 9963 2E43
       Pool relative page #'s :
       12016  28020  44024  60028  76032
       92036 108040 124044 140052 156056
      172060 188064 204068 220072 236076
      252080 268088 284092 300096 316100
      332104 348108 364112 380116 396124
      412128 428132 444136 460140 476144
      492148 508152
       Pool: 7, Object: 4 EMP page class: 64,
       EMP pool page: 12016, # entries: 1000
       Page LSN = 0001 3D75 E4E6
       Pool relative page #'s :
       12020  12024  12028  12032  12036
       12040  12044  12048  12052  12056
      〜〜後略〜〜

まずこの中の、

DAT extent anchor: 12

この部分が、表を作成した時に取られた初期EMPの先頭ページ番号を表しています。
今回はエクステント・サイズが4で、1つ目に作成した表なので12ページから4ページ分がEMPエクステントです。

そして、

EMP pool page: 12, # entries: 1000

この部分が、EMPページのページIDと、その中に何エクステント分の情報が入っているかという情報です。
今回はページID12番には、1000個のエクステント情報があると言っています。
そして、その後ろの

       Pool relative page #'s :
          16     20     24     28     32
          36     40     44     48     52
          56     60     64     68     72
       〜〜中略〜〜
        3956   3960   3964   3968   3972
        3976   3980   3984   3988   3992
        3996   4000   4004   4008   4012

が、そのEMPページで管理しているエクステントの、先頭ページ番号になります。
数えると確かに1000個ありました。
したがって、このダンプ結果の「EMP pool page: nn」のところを見ていけば、いくつEMPエクステントが取られたのかが確認できます。

さらにいうと、
「先頭EMPエクステント」の「最終ページ」
には、拡張されたEMPの位置が記録されています。
今回の先頭EMPエクステントは、ページIDが、12, 13, 14, 15 の4ページあります。
この中の最終ページ（==ページID5）の中に、拡張されたEMPがあるということです。

それが上記のダンプ結果の

       EMP pool page: 15, # entries: 32
       Page LSN = 0001 9963 2E43
       Pool relative page #'s :
       12016  28020  44024  60028  76032
       92036 108040 124044 140052 156056
      172060 188064 204068 220072 236076
      252080 268088 284092 300096 316100
      332104 348108 364112 380116 396124
      412128 428132 444136 460140 476144
      492148 508152

の部分になります。
ここをみれば、どのくらい拡張されたのか一目で分かります。


とうことで、表毎に取られるEMP（エクステント・マップ・ページ）の位置が確認できました。


それでは次に、ページ・サイズによる違いを見てみます。
当然ページ・サイズが大きくなれば、1つのEMPページで、より多くの情報が格納できるはず。
ということで、各ページ・サイズで表スペースを作成し、データを増幅してダンプをとります。

やることは上と同じなので割愛。
結果としてはこうなりました。

       ・表の作成時に、初期EMPエクステントが確保される
        ・初期EMPエクステントの最終ページには、拡張したEMPエクステントの位置が記録される
        ・ページサイズが4Kの場合、EMP1ページにつき、1000エクステントが管理できる
        ・ページサイズが8Kの場合、EMP1ページにつき、2026エクステントが管理できる
        ・ページサイズが16Kの場合、EMP1ページにつき、4074エクステントが管理できる
        ・ページサイズが32Kの場合、EMP1ページにつき、8170エクステントが管理できる

このEMPも、領域見積もりの結果に1割くらい多めにしておけば十分に吸収できるサイズでしょう。
ただ、厳密にシビアな見積りが必要な場合には、当然考慮する必要があります。

※この検証は9.1で実施しており、新しいバージョンでは動作が違う可能性があります。


では今回はここまで。
次回からはINDEXのエクステントのとり方を検証してみたいと思っています。