翌日のレビュー用の設計書作成と、問い合わせ対応に追われ、
やや忙しい一日だった。
”やや” というのは、終電になるとかではなく、
なるべく定時頃に帰りたいので、その為に頑張らないと
終わらないという意味です。
昼食の休憩後、トイレに一度たっただけで、
約7時間ずーっとPCの前にいました。
設計書作成、電話対応、メール対応 ・・・ などなど
休憩を取らずに働き続ける。
タバコをやめてから、たまにこんな一日がある。
（今年から本格的に禁煙し、いまのところ1本も吸ってません！）
タバコを吸っていた頃は、長くても二時間毎に休憩をとってましたね。
タバコは確かにリラックスになるのですが、
今の方が断然仕事のスピードが速くなったと思う。
タバコをやめた事によって、喫煙所でのコミュニケーション
（結構大事だったりする）が減ってしまいましたが、
その他の方法でコミュニケーションを取るようにしているので、
問題はないでしょう。
タバコを吸っていた頃だったら、今日の帰りは2時間以上遅くなっていた事だろう・・・
2週間の広告掲載期間が終了して、今回の採用活動は終了。
数名の面接を行いましたが、自分の力不足を痛感しました。
基本的なQAは対応できるのですが、会話を広げていくのが下手だなあと実感しました。
その点、ウチの社長の話術には関心させられました。
まず、相手との会話が止まらない。
相手の趣味や特技の話になっても、何故か会話が成立する。
音楽、映画の話から、プロレス、大学の数学、電子回路 ？？？ などなど
何でそんな事まで知ってるの？
と、思わず面接中にツッコミを入れた事も・・・
とにかく、多方面の知識を持っている。
面接では、様々な話を通して、お互いを理解し合う事が重要だと思うので、
この能力を身に付けなければいけないなと反省・・・
少しずつ見習っていこう。
Oracleを使用していると、当然ですが、色々なエラーが発生します。
ORA-XXXXX
や
TSN-XXXXX
というメッセージです。
メッセージの内容を確認する為に、「データベース・エラー・メッセージ」
というものがあります。
でも、このマニュアルからでは、具体的な対処方法が分からない事が
良くあります。
そんな時、OTNのエラーメッセージ検索サービスは非常に便利です。
http://otn.oracle.co.jp/document/msg/index.html
これを使用すると、マニュアルと同じ内容も確認でき、
該当のメッセージに関連する掲示板の過去ログもリストアップされます。
この過去ログによって、エラーが解決される事は少なからずある筈です。
掲示板の内容なので、正規にサポートされる内容ではありませんが、
回答のレスをしている方々は、かなりのスペシャリスト揃いなので、
参考になる意見が多数あります。
私も、作業に余裕がある時は、よく利用しています。
回答のレスがメインですが、たまーに質問でも利用してます。
回答する事によって、人に説明する為の文章能力が鍛えられ
復習にもなる為、自分自身のスキルアップにも繋がります。
とにかくこの掲示板は、活気があって素晴らしいと思います。
OTNの回し者でも何でもないのですが、Oracleのエンジニアとしては、
非常にありがたいサイトです。
今後も、OTNの発展に期待してます。
今日は、初めて仕事とは全く関係のない話です。
私はサッカーが大好きです。
今もフットサルや7人制サッカーをやってます。
サッカー コンフェデレーションズカップ 日本 vs ブラジル戦
深夜3時8分からTV放送開始か・・・
どうしても観たかったので、この日は24時前に就寝して、
午前3時30分に目覚ましをセット。
ちなみに、家族に迷惑をかけないようにと、この日は一人で
別の部屋で寝ることにする。
（家族は妻と0歳の息子）
これで、試合終了後に寝れば、合計5時間くらいは寝れるから
仕事には支障は出ないだろう。
さあ寝ましょう ｚｚｚ
次に気がつくと、何だか外がうっすらと明るい・・・
あれ？
時計は5時8分。。。
がーん （ToT）
まだ少し観れると思い、リビングに向かう。
するとなんと・・・・・妻がテレビ観戦してました！
目覚ましはかけていない筈なのに・・・。
偶然目が覚めて、後半開始直後くらいから観てたらしいです。
彼女はいつからこんなにサッカーが好きになったんだろう・・・
私の影響である事は間違いないのだが。
なかなかめずらしいタイプの女性だと思う。
私が観はじめた時は、後半20分くらいからでした。
最後に大黒の同点ゴール、そして、あわや逆転のシーンも観れたので、
後半途中からでも。観て良かったです。
やっぱり大黒は凄い！
スペースへの飛び出し、一瞬のスピード、ポジショニング、ゴールへの嗅覚、
日本のFWでは間違いなくNo.1だと思う。
# ポストプレイ、テクニックなら、高原、柳沢の方が上かもしれないが。
なによりも、シュートが枠に行くし、常にゴールを狙う姿勢が素晴らしい。
スタメンで出て欲しい反面、相手が疲れてきた時に出てくると
非常に嫌なタイプのFWなので、今の使われ方がベストな気もする。
他に優秀なFWがいれば、後半からの出場には大賛成なんですけどね。
ジーコ監督は、もう鈴木の強運などに頼らずに、大黒の実力を認めて欲しい。
頑張れ！ジーコJAPAN！
亜才で私が立ち上げたグループ「データベースソリューショングループ」。
現在、社員募集中です。
興味がある方は詳しくはこちらから
↓↓↓↓
http://www.find-job.net/fj/showjob.cgi?id=40701
（05/07/03まで掲載予定）
さてさて、ただいまのグループ構成メンバーは、私を含め２人・・・。
全社員数（9名）から考えると、まあ悪くはないのかな。うん。
いやいや、私が亜才に参加した理由は、自分が中心となって、
出来るだけ多くのデータベースのスペシャリストを育成し、
儲かる会社を造りたいからです。
自身の経験から、データベースやインフラ系の技術者は、
業界で非常に重宝される存在である事を実感しています。
プログラマは多数いますが、インフラを理解している人は少ないですよね。
そして、インフラ系の技術者は一つの案件に入ると、なかなか顧客が手放して
くれないものです。
失ってしまうと変わりを見つけるのが大変です。
という事で、そんな素敵な技術者を育成し、会社を成長させるべく、
新たな人材を求めて採用活動を開始しました。
採用広告の中で、DBエンジニアの魅力を伝えるには、
どのような文章を書けば良いのか、試行錯誤の繰り返しです。
限られた文章の中では、上手く伝えられていない気がします。
そこで伝えられない部分については、面接の中でできる限り、
理解してもらえるように、色々な話をさせて頂いてます。
さてさて、いざ面接となると、また大変です。
私は、”面接は、しているのではなく、されている” という気持ちで臨む事が
重要と考えています。
我々の会社をPRして、相手に少しでも理解して選んで貰えるように。
入社後に『こんな会社だと思ってなかった』と落胆される事がないように。
就職、転職には、人生がかかっています。
相手は真剣です。
こちらはそれ以上に真剣に臨まなければいけません。
この数週間の間に、何名かの面接をする事になると思います。
私の思いを真剣に伝え、素晴らしい人材が採用できるように頑張ろう！
少し、会社の話を・・・
亜才は出来たばかりの新しい会社で、現在の社員数は9名。
（設立メンバー5名＋05年3～5月の間に4名入社）
2～3年後には30～50名程度の規模まで拡大する予定。
実は、私も『会社を造り、成長させていく』という事に魅力を感じ
この4月に亜才に転職してきたばかり。
そして、私の得意分野であるデータベースの技術者を育成し、
グループを拡大するという仕事を任せられ、今回は採用担当をしています。
今後、会社の規模が大きくなってきても、現在のように個々の意見を
尊重できる会社造りを目指してます。
最後に独り言・・・
自分のグループを拡大して会社を大きくできたら楽しいだろうなあ。
年収はいくら位になってるかなあ。
お金を気にせず、お正月に家族でハワイに行けるようになりたいなあ。
忙しくて行けなかったりして（^^;;q
車を買う時は常にキャッシュで！くらいにはなれるかなあ。
ついでに家もキャッシュで購入！とまでは、さすがに厳しいか。。。
> Q.init.oraファイルに定義されているパラメータが
> マニュアルに載っていないのですが・・・？
>
> 8iの環境の調査を行っていたところ、「MAX_TRANSACTION_BRANCHES」という
> パラメータが定義されていたのですが、マニュアルを見ても載っていません。
>
> 何故なんでしょう？？？
マニュアルの記載漏れ？
いやいや違います。（そんな事もたまにありますケド・・・）
私は8iからOracleに関わってきましたが、見覚えのないパラメータです。
となると、まず確認するのは、マニュアル「データベース移行ガイド」です。
このマニュアルでは、廃止、変更、追加となったパラメータが確認できます。
確認してみたところ、案の定、8iで廃止されたパラメータでした。
特に、他のパラメータに踏襲されたという記述はありませんが、
恐らくtransactionsあたりに吸収されたのではないかと（あくまで想像）。
ここら辺の話はサポートに確認しないと分かりません。
ちなみに廃止されたパラメータは、ディクショナリからも確認できます。
SQL> select * from v$obsolete_parameter;
この結果で ISSPECIFIED 列の値が「TRUE」となっているパラメータは、
パラメータファイルで定義されているものになります。
通常は、全て「FALSE」となってる筈です。
廃止パラメータが指定されている場合には、インスタンス起動時にエラーが
出力されますが、普通ににOPENされてしまいます。
このエラーは気にしていなかったのでしょうか・・・
これ以上は分かりませんので、構築当時の担当に確認してみましょう。
もしくはサポートへ。
尚、廃止された後も、隠しパラメータとして使用可能なものも残っています。
隠しパラメータは、「_（アンダースコア）」から始まるものです。
通常使用する必要はないと思います。
というか”隠し”なので、サポートから指示されない限り使用しないと
思いますけど。
でも、以下のマニアックな検証サイトでは、頻繁に使ってます（^^;;
これも熟練者のなせる技です。
http://www.insight-tec.com/mailmagazine/ora3/mail_back_index.html
（この連載を楽しく読める人は、Oracle通と名乗って良いでしょうね）
前回は、表領域の分割方針について書きました。
今回は、表領域の管理方式について書いてみます。
まず、表領域の管理方式は、大きく以下の２つに分かれます。
・ローカル管理表領域
・ディクショナリ管理表領域
これらの特性、概要については、毎度おなじみとなりましたが、
以下のサイトを参照下さい。「第2章 ローカル管理表領域」
http://otndnld.oracle.co.jp/skillup/oracle9i/2_1/index.html
ローカル管理表領域は、8iから採用され、9iでデフォルトの方式となりました。
私が9iの案件をやり始めた頃は、慣れ親しんだディクショナリ管理表領域を
採用していたケースがほとんどでした。
どんな新機能もそうですが、安定するまでは採用するのには勇気がいります。
（結構bugが・・・10gもR2が出ないと、提案するにはちょっと勇気が・・・）
9iもR2が出た頃になると、ローカル管理表領域が主流になってきました。
（私の知っている範囲の話ですが）
パフォーマンスが良くなったという事は、あまり実感した事はありませんが、
管理面でのメリットが大きい為、私もすっかりローカル管理派になりました。
さてさて、ローカル管理表領域には、エクステントの管理方式には、
2つの方式があります。
UNIFORM（エクステントサイズ固定）方式と、
AUTO ALLOCATE（Oracleによる自動管理）です。
双方メリット、デメリットがあるのですが、私の最近のお気に入りは、
UNIFORM方式です。
前述のサイトに記載がありますが、領域の無駄が多少発生しますが、
断片化の発生を防止できます。
デメリットである領域の無駄を発生させない為には、UNIFORMサイズを
小さくしてやれば良いのですが、これでは、大きなオブジェクトの場合に、
エクステント数が膨大になってしまい、パフォーマンスへ影響が
生じる可能性があります。
私は、UNIFORMサイズの異なる表領域を複数作成する事によって、
領域の無駄と、エクステント数の増加を極力防止するような方針を薦めています。
具体的には、以下のような感じになります。
表領域A（UNIFORM： 1MB）・・・ 100MB未満のオブジェクト格納用表領域
表領域B（UNIFORM： 10MB）・・・ 101～1GBのオブジェクト格納用表領域
表領域C（UNIFORM：100MB）・・・ 1GBを超えるオブジェクト格納用表領域
このようにすれば、デメリットの面をカバーできます。
前回の（その１）の方式と合わせると、
業務種別毎に分割して、さらにオブジェクトのサイズ種別で分割する
という方式になります。
この方式は、結構悪くない方式だと思っています。
当然、顧客要件に応じて、分割方針、管理方式は、その都度検討するので、
上記と異なる方針にする事はあります。
ここに書いたのは、あくまでも１例のお話です。
少しでも読んだ方の参考になれば嬉しいなと思います。
以上でユーザデータ表領域設計に関するお話は終了です。
容量計算も終わったので、ユーザデータ表領域の設計に取り掛かります。
これが一番面倒なタスクな気がします。
物理ディスク数、RAIDグループ数、等々の要件によって、
表領域をいくつ作成するか、どのように配置するか、を検討します。
表領域の構成は、大きく以下の3点を考慮して検討します。
・管理面
・耐障害性（障害時のリカバリ時間等）
・パフォーマンス
それぞれの観点については、こちらの「第1章 表領域分割・配置の観点」を参照
↓↓↓
http://otndnld.oracle.co.jp/skillup/oracle9i/2_1/index.html
管理面は、
⇒ 当然楽になるので「◎」
耐障害性は、
⇒ この表領域の障害時に、他の業務への影響は出ず、影響範囲を絞り込めるので「◎」
パフォーマンスは、
⇒ 負荷が集中する可能性があるので「×」
という風に、各方針について評価をして行きます。
そして検討した結果、どの方針を採用するか決定し、
例えば、以下のような分割方針を決定します。（ほんの１例です）
これは、複数のデータファイルで構成されている表領域にオブジェクトを作成した場合、
エクステントは、データファイルを順番に使用して割り当てられる為です。
～続く～
> Q．CREATE TABLE文実行時に以下のエラーが発生します。
>
> -------------------------------------------------
> ORA-03237：
> 指定サイズのINITIALエクステントは表領域（TS1）に
> 割当てできません。
> -------------------------------------------------
>
> 調査をした結果、以下の動作を確認しました。
> ・表領域（TS1）の空き領域は十分である。
> ・LOB列が含まれており、LOB列の定義を外すと、正常終了した。
> ・エラーが発生するのは9i環境で、8i環境では発生しません。
この現象は、LOB列と8iでは発生しないという事がポイントです。
まず、Oracleの仕様として、LOB列の場合は、db_block_size * 3
のサイズを1エクステント内に収める必要があります。
例えば、db_block_sizeが16Kである場合、LOB列を使用する為には、
16K*3=48Kのエクステントが必要となります。（1エクステントのサイズで）
では、表領域には、十分な空き領域があるにも関わらず、
何故1エクステントで48Kが確保できなかったのか？？？
理由は1つ。
ローカル管理表領域のエクステント管理方式としてUNIFORM方式を使用し、
そのUNIFORMサイズが48Kより小さかったから！
でしょうね。
UNIFORM方式の場合は、エクステントサイズは固定となるので、
1エクステントのサイズは全て固定となります。
なので、そのサイズが小さかった為に、LOBの仕様である、
db_block_size * 3 のエクステントが確保出来なかったのでしょう。
表領域をその他の方式とした場合は、以下の理由により、エラーは発生しません。
まず、ローカル管理表領域のもう一つの方式である、AUTO ALLOCATE の場合、
エクステントのサイズはOracleによって自動的に決定されるので、問題なし。
（セグメントサイズに従い64KB、1MB、8MB、64MBのエクステントを自動で確保）
もう一つ、ディクショナリ管理の場合。
この場合は、オブジェクト作成時にSTORAGE句に指定した値が使用されるので、
こちらもエラー発生は防止できます。
Oracle8iまでは、デフォルトの管理方式がディクショナリ管理であり、
それを利用していた為、8i環境ではエラーが発生しなかったのでしょう。
尚、UNIFORMサイズの変更を行うには、表領域を再作成しなくてはいけません。
Q．UNIX環境（HP-UX）で、importを途中で終了させる方法を教えて下さい。
話によると、開発機でimportを実行しているが、全然終わらず、
CPUとディスクI/Oの高負荷状態が続いて、他のテストに影響が
出てしまっているらしい。
ちなみに、このimportは強制終了しても、後日再実行すれば問題ないとの事。
という事であれば、ぱっと思いつくのは、以下の3つ。
１．importを実行しているセッション（画面）で「Ctrl+C」で終了する。
これが一番簡単。
２．killコマンドで終了させる。
３．OracleのSQLコマンドでセッションを終了させる
本来であれば、下位のセッション、プロセスから終了させるというのが正しいので、
３の方法を実行して、それでも終了できない場合には、１又は２を試行するという
順番が正しいと思いますが、私だったら、迷わず１ですね。
「Ctrl+C」！！！えぇぇぇいっ！死ねぇぇぇぇっ！
ちょっと表現が過激ですが、２も３もコマンドは「kill」ですからね（^^;;
では、２と３の方法の具体的な実施手順を書いておこう。
◆UNIXのkillコマンドで終了する方法
（1）psコマンドでimpのプロセスを確認する。
impのプロセスは、psコマンドから、「imp」をキーワードに検索する。
$ ps -ef | grep imp
orauser 28360 27235 19 15:29:32 pts/tb 0:01 imp scott/tiger file=./expdata.dmp
ここで出力されるプロセスID（左側。右のIDは親プロセスのID）を確認。
（2）確認したプロセスIDを指定して「kill」コマンドを実行。
$ kill 28360
このコマンドで終了しない場合は、シグナル9で強制終了させる。
$ kill -9 28360
＜注意事項＞
・プロセスIDの確認は慎重に。
・間違って親プロセス（右側）を指定しない事。
◆OracleのSQLコマンドで終了させる方法
（1）sqlplusにDBA権限のあるユーザで接続する。（SYS、SYSTEMなど）
$ sqlplus system/password
（2）impの実行セッションを確認する
SQL> select username,sid,serial#,process,program
from v$session where program like 'imp%';
USERNAME SID SERIAL# PROGRAM
------------------------------------------------------------
SCOTT 58 2035 imp@server1 (TNS V1-V3)
（3）上記で出力されたSID、SERIAL#を指定してセッションを強制終了させる。
SQL> alter system kill session '58,2035';
以上
