昨日は記念すべき第一回のグループ会を実施しました。
まあ、グループといっても私を含めて2名だけなのですが・・・


普段は、別々の現場へ行っているので、状況の把握をしなくてはいけません。
全社の定例で月に一度会うのですが、どうしてもその時には、
全体の話で盛り上がってしまい、あまり個別に話ができないのです。


思えば2人だけで話をした事はあまりなかったなあ・・・


最初は、あまり形式にこだわらず、フリートークでやっていこうと思う。
その中で、コミュニケーションの向上と、スキルアップに繋がれば良いと思う。


ちなみに、渋谷のドトールコーヒー本店に行きました。
ここは、ドトールの中で日本一広いらしい。


ドトールと言えば、狭いイメージがあるが、
確かに、真中に噴水のようなものがあって、

広々として良い雰囲気だった。

誰かに教えたくなるようなドトールだった。


毎度の事ですが、物理設計の重要なタスクとして、
オブジェクトの容量計算をしなくてはいけません。


これを基に、表領域構成、ファイル配置等々検討していきます。

各テーブル/インデックスのレコード長を見積もって、想定件数を乗じて、と・・・


容量見積りの考え方については、以下のURLが参考になります。
http://otndnld.oracle.co.jp/skillup/oracle9i/3_1/index.html


レコード長、PCTFREE値、ブロックサイズ等を入力して、
概算容量を算出できるエクセルシートを使っているので、
頭を使わなくても出来る作業です。


簡単なのですが、オブジェクト数が多いと非常に辛い。。。
単純な力作業です。


早く部下を付けて、こういう作業をやらせないといけないな(^^;;


顧客レビューから単純作業まで、Oracleに関連する事は、
ほとんど一人でやってしまっているのが現状。


自分の思い通りに出来るので気楽なんですけど。

なんて事を思っていてはいかん!

いいかげんマネージメント能力を身に付けなくては・・・

部下を求めて採用活動を頑張ろう!

昨日は、先日本番リリースを迎えたプロジェクトの打ち上げでした。

今回のプロジェクトは、途中に大きなトラブルも遅れもなく、非常に順調でした。


複数のプロジェクトの管理を行っている顧客側のマネージャーが、


「このプロジェクトの打ち合わせだけは、いつも安心して参加してましたよ。
  他のはツッコミどころが多くて・・・。
  このプロジェクトがここまで順調に進んだのは、
  ○○さん(プロジェクトリーダー)のおかげですよ!」


とおっしゃっていました。


私もその通りだと思いました。

1年間一緒に仕事をしてきて、この方の統率力は本当に素晴らしいと感じました。


 ・ いつ誰が何をすべきという事を完璧なまでに指示ができる。
 ・ 自分の失敗は素直に認める。
 ・ そして、”笑いも取れる”。


今の私にとって、理想のリーダー像です。


ちなみに次のプロジェクトでも一緒に仕事をする事になりました。
少しずつ近づけるように頑張っていこう。


約1年後のリリースに向けて、新案件に本格的に参画し始めました。
現行システムのリプレース案件です。
Oracle8やら8iやら複数のデータベースが存在しているシステムを
一つにまとめて、9iのRAC環境へと移行します。


基本設計は、ほぼ完了している状態なので、物理設計からが担当です。

まずは、要件が不明なところをヒアリングしていきます。

・最大同時接続数は?
・各テーブルの想定格納件数は?
・現行存在している各スキーマの役割は?

などなど


物理設計をしっかり行っておかないと、後々大変です。
特にRACの場合はRAWデバイスですからね。

表領域の見積もり間違いとかがあると、lvolの拡張や追加が発生して、
ちょっと面倒な事になっちゃいます。


# 過去に大量のvg、lvolの構成変更を行った経験アリ。。。
# この時は、設計ミスというよりは、顧客からの要件追加の為でしたが。


以下のOTNの情報は、物理設計のポイントが良くまとまっていて、
特に経験の浅いDBAにはオススメ!
http://otn.oracle.co.jp/skillup/oracle9i/index.html

このような連載をどんどん続けていって欲しいものです。


今後は、このブログで物理設計の各項目の設計ポイントなどを、書いていこうかな。


だいぶ過去の出来事のような気がしてしまいますが、
今年のゴールデンウィークは、10連休の人が結構いましたね。


これぞ大型連休!

私もきっちりお休み zzz


さて、連休というと喜ぶのは、お客さん。
お客さんというのは、もちろんSEの立場からみたお客さん。

何が嬉しいって?休暇じゃないですよ。


システムを停止できるチャンスなんですから!


新システムのリリースなんていう事になると、規模にもよりますが、
ゴールデンウィーク、お盆休み、年末年始、なんて最高です!


ちょっとしたメンテナンスの場合でも、土日だけじゃちょっと不安だから
予備日を考えて3連休に、なんて事もよくある事。


今度の担当システムのリリース予定は、来年のゴールデンウィーク頃・・・
後から代休を取るといっても、なかなかまとめて取れないものです。


1年後の話だけど、ちょっと悲しい・・・

本番リリースとなると、必ずあるのが移行の立会い。


先日の土日を利用して、旧システムからのデータ移行などを行いました。

どの案件でも大抵リハーサルを行っているので、移行実施中にトラブルが
起きるような事はあまりなく、数時間待機してるだけなので、とにかく暇です。


まあ、移行当日は暇である事が最良なのですが。


今回の立会いは日中なので良かったのですが、夜間から翌朝リリース後に
安定稼動するまで立会い、となるとかなり辛いです。
寝ている訳にはいきませんしね。


他の仕事を片付けるにしても、夜中にやってるという事が嫌になっちゃいます。

それに、安定稼動確認後、その日は代休として昼前に帰宅したとしても
1日寝て終わりですしね。


さてさて、今回のシステムは無事に稼動を開始しました。

代休使って、平日休暇を満喫しよう!


STATSPACKの少し便利な機能を使ってみよう。(レベル7編)


◆レベル7:セグメント単位のアクセス状況表示


デフォルトのレベルでは、表領域レベルのI/O状況は確認できますが、
セグメント単位では分かりませんでした。


9iR2(9.2.0)からの新機能で、レベル7でのスナップショット取得により、
これがみれるようになったらしいです。

では、こちらも確認してみましょう。


取得方法はレベル6の時と同様で、指定値を「7」にするだけ。


SQL> conn perfstat/password
SQL> execute statspack.snap (i_snap_level => 7);


あとは同様にレポートを作成するだけ。
セグメントの状況は、こんな感じで出てきました。


********************************************************************************

Top 5 Logical Reads per Segment for DB
-> End Segment Logical Reads Threshold:     10000

                                           Subobject  Obj.       Logical
Owner      Tablespace Object Name          Name       Type         Reads  %Total
---------- ---------- -------------------- ---------- ----- ------------ -------
SCOTT      USERS      EMP                             TABLE       21,280   49.13
SCOTT      USERS      DEPT                            TABLE       11,920   27.52
SCOTT      INDX       EMP_PK                          INDEX        4,848   11.19
SCOTT      USERS      DEPT_PK                         INDEX        4,544   10.49
SYS        SYSTEM     FILE$                           TABLE          320     .74
          -------------------------------------------------------------

********************************************************************************


同じような内容で、「op 5 Physical Reads per Segment」や
「Top 5 Buf. Busy Waits per Segment」などが出力されます。


これらを参考にして、負荷の高いオブジェクトを別表領域に作成して、
別の物理ディスクへ分散するなどが検討できそうです。


また、RAC(Real Application Clusters)環境の場合は、
「Top 5 CU Blocks Served (RAC) per Segment」をいうセクションも
出力され、セグメント単位のGlobal Cache発生状況が確認できるので、
これも便利ですね。


最後にSTATSPACKが使用する領域のお話。


9iR1の時には、インストール時点で約64MBを使用するという事でした。
9iR2では、機能追加により、約100MBになったらしい。


これを知らずに、100MBのワーク用表領域にインストールしたところ、
一気に空き領域が無くなって焦りました。。。


新機能の情報は定期的に確認しないといけないな、と反省。


尚、インストール後は、スナップショットのレベル、保存数によって、
容量が少しずつ増加していきます。


<今日のおさらい>


9iR2(9.2.0)からは、レベル7の指定によって、セグメント単位の
アクセス状況(上位5つ)が確認できるようになった。


9iR2(9.2.0)からは、インストール時点での使用領域が100MBに増加したので注意が必要。

STATSPACKの少し便利な機能を使ってみよう。(レベル6編)


今日はスナップショットレベル(デフォルト「5」、最大「10」)の変更によって
取得できる情報を確認してみる事にする。
今後の案件で活用する為に、社内での検証もしておかないと。


◆レベル6:SQL実行計画の表示


9iR1(9.0.1)から、レベル6でのスナップショット取得により、
SQLの実行計画が確認できるようになったらしい。


以前は、STATSPACKのレポートから重いSQLが確認できたとしても、
そのSQLの実行計画を確認するには、SQLトレースを取得しなければ
いけなかったから、これは便利そうだな。

早速、試してみよう。


ではまず、レベル6で取得してみよう。


SQL> conn perfstat/password
SQL> execute statspack.snap (i_snap_level => 6);


それで、適当にフルスキャンが発生するようなSQLを実行して・・・
実行後に、スナップショットを取得する。(上記と同じコマンド発行)

では、まずは普通にレポートを作成して中身を見てみよう。


SQL> conn perfstat/password
SQL> @$ORACLE_HOME/rdbms/admin/spreport.sql



問題のSQLを発見。


********************************************************************************
                                                     CPU      Elapsd
  Buffer Gets    Executions  Gets per Exec  %Total Time (s)  Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
         12,795            1       12,795.0   58.6     0.59      1.26 1315228457
Module: SQL*Plus
select count(*) from TEST_TAB1 where COL1 like '%a%'

********************************************************************************


中間一致検索のSQLですね。
当然フルスキャンが発生しているのですが・・・
まあまあ、ここからが本題!


sprepsql.sqlを実行し、このレポート中の「Hash Value」値を使用する事で、
実行計画が表示できるらしい。

では、やってみよう。


SQL> conn perfstat/password
SQL> @$ORACLE_HOME/rdbms/admin/sprepsql.sql



通常のレポート作成と同様にbeginとendのsnap_idを指定して・・・
次のところで「Hash Value」値を指定する。


Specify the Hash Value
~~~~~~~~~~~~~~~~~~~~~~
hash_valueに値を入力してください: 1315228457
Hash Value specified is: 1315228457



以降は同様にレポート名を指定すると出来上がり!
レポートの内容は、こんな感じになりました。

********************************************************************************

--------------------------------------------------------------------------------
| Operation                      | PHV/Object Name     |  Rows | Bytes|   Cost |
--------------------------------------------------------------------------------
|SELECT STATEMENT                |----- 184110842 -----|       |      |   1939 |
|SORT AGGREGATE                  |                     |     1 |   22 |        |
| PARTITION RANGE ALL            |                     |       |      |        |
|  TABLE ACCESS FULL             |TEST_TAB1            |    52K|    1M|   1939 |
--------------------------------------------------------------------------------

********************************************************************************


フルスキャンが発生している事を確認できました。
今回の例は簡単なSQLでしたが、結構使えそうな機能です。



<今日のおさらい>
9iからは、レベル6の指定によって、SQLの実行計画が確認できるようになった。


◆レベル6でのスナップショット取得コマンド
 execute statspack.snap (i_snap_level => 6);


◆SQL実行計画表示スクリプト
 @$ORACLE_HOME/rdbms/admin/sprepsql.sql


※全てPERFSTATユーザで実行




昔話。オラクルマスター奮戦記(最終章)


現在のPlutinumとは比較になりませんが、現在のGoldに相当する
オラクルマスターPlutinum(8i)を取得した頃のお話です。


■2002年1月~


昨年の10月末にGoldを取得して以来、Plutinum取得に向けた勉強は
お休みしていましたが、そろそろ始めないといけません。

残りの3科目を2ヶ月に1科目ずつ合格すれば、6月末には取得できる事になり、
根拠なしに掲げた目標の1年以内に取得する事を達成できます。


# 本当は入社後1年のつもりでしたが、さすがに自分のスキルで
# Plutinumをあと3ヶ月というのは無理と感じたので、
# Oracleに出会ってから1年以内という事にしよう、と勝手に納得する事にしました。


この頃の仕事はというと、運用・保守の案件に入り、障害対応の他、
技術問い合わせ対応、改善要望への対応などを行なう事になりました。

担当範囲は広く、Oracle、OS(HP-UX)、バックアップソフト、
基盤系の運用シェル100本くらい。と多くありました。
これらのものを理解しておいて、顧客と対応しなければいけません。


元々の担当者を別案件に使いたい為、私に引き継ぐ為という事でした。
元担当者がバックアップしてくれるとはいえ、素人に毛が生えた程度の
私では到底対応できないと思いました。

が、なんとか乗り越えて、この案件のおかげでOracleだけでなく、
OSやハードの知識が少し付きました。

結果的には、良い選択だったようです。
スパルタ教育?に感謝!


本当かどうか分かりませんが、私が選ばれた理由は、

「元担当者と顔が似てるから」だとか・・・。

『おいおい・・・』
確かに似てるんですけどね。。。


さてさて、オラクルマスター奮戦記なので、オラクルマスターについて書くのですが、
これといったネタは無いんですよね。

試験の結果と勉強法などを簡単に書いておきます。

まず、基本的な進め方はこうでした。


1.黒本をとりあえず最後まで読む。
2.約1ヶ月後くらいに試験を予約してしまう
3.iStudyと黒本を併用しながら各章毎に理解度を深めていく。
4.iStudyをやりまくる。


このような感じで

2002年2月中 パフォーマンス・チューニング合格(47/57 合格ライン38点)
2002年3月末 バックアップ・リカバリ合格(50/60 合格ライン42点)
2002年5月末 ネットワーク合格(55/59 合格ライン41点)


ネットワークはなんでこんなに時間がかかったのかは覚えてないです。
多分、一番簡単なものを残しておいたので、気が緩んでしまい、
なかなか勉強を開始しなかったんだと思います。


ともあれ、見事にOracleに出会ってから1年以内でPlutinumを取得できました。


Silverの「Oracle入門」はギリギリでしたが、他は危なげなく合格。
無敗で乗り切りました。


Plutinumも取得し、Oracleとも1年間お付き合いをし、今後もこの業界で
やっていく自信が少しつきました。
今思えば、この頃は完全に名前だけのペーパーPlutinumでしたが、
資格取得によって、少なからず知識は豊富になり、成長できたと思います。

その後、資格に負けないようにと努力した結果、今の自分があるような気がします。


”肩書きは人を作る”という事でしょうかね。


■おまけ。その後のオラクルマスター取得状況


2003年に制度改定により、改定前のPlutinumはGold相当になり、
新Plutinumとして、さらに高度な新資格が制定されました。


私のPlutinumは8iだったので、とりあえず9iのGoldに移行しておこうと
約1年半ぶりくらいに受験をしました。2003年12月下旬の事。

結果は、45/53(合格ライン37点)で合格。


試験対策に使用したのは、日経BP社の「9i新機能」の本とiStudy。
移行試験対策の黒本って出ないんですよね・・・。
欲しがっている人は多いと思うのですが。


そして、翌年の2004年2月。
仕事が少し暇な状況だったので、過去に一度構築をした事がある
Oracle9i Application Serverの資格に挑戦してみました。


結果は、71/83(合格ライン53点)で合格。

しかし、せっかく取得したのですが、これ以降 Application Serverの
仕事はしてません。。。


■今後の展望


いつかは、新Plutinumを取得したいですね。
社長も取れと言ってたし。(本気?)
でも、100万弱のお金がかかるんですよねえ。


まずは、会社に対して
「これまでの私の業績を考えたら100万くらい軽いでしょ!だからお金出して!」
と言えるように頑張ろう!


これで、私のオラクルマスター奮戦記は一旦終了。

次は、新Plutinumの奮戦記を書く予定。

いつになるやら・・・

昔話。オラクルマスター奮戦記(その2)


9i以降のSilverと同等の資格に相当するものでしょうか。
オラクルマスターGold(8i)を取得した頃のお話です。


■2001年8月頃


  DBAチームに出向する事になり、1ヶ月が経過。
  7月末にSilverを取得したものの、未だ仕事の内容はサッパリ状態。
  この頃、先輩に付き添い、理解出来ないまま、Oracleインストール、
 DB作成などをやっていました。
  初めてUNIXというものに触れる事になりました。

  『インストールなんてボタンを押すだけでしょ!』

 と楽観していましたが、
  いやいや、舐めてもらっちゃあ困ります!
 コンピュータの知識ゼロに近い私にとっては、なんとも難しいものでした。


  だって、CD-ROM入れても反応しないんですもん!

  (HP-UXだったので、手動でのマウントが必要でした)


  「マウントって何ですか?」
  「lsコマンドって何ですか?」
  「シェルって何ですか?」
 「Xウインドウって・・・?」


 本当、宇宙語でも聞いている気分でした。
 この頃『自分にはやっていけない。もう辞めよう。』と思う事が度々ありました。


  いやいや、今思い出すだけでも最悪ですね。こんなド素人。。。
  契約を切らずに教育し続けてくれた出向先に感謝です。
 
 # 結局このまま、現在も契約を続けています。
  # この頃の借りは、利子を付けて既に返済しました。多分・・・その筈・・・。


  DB作成の中で、制御ファイルやら、初期化パラメータやら、Goldの「DBA編」に
  載っているようなキーワードが出てきました。
  『なるほど、よく分からないけど、やっぱり「DBA編」の知識は必須なんだな』
  と思ったのですが、壁にぶち当たっていた私は、モチベーションが低下気味で、
  資格の勉強をする気分にはなれませんでした。


■2001年9月頃


  『ここで会社を辞めたら何をしようか。フリーター生活に戻って良いのか?』
  自問自答を繰り返しながら出た結論はこうでした。

  『とりあえず1年間は頑張ってみよう!』

  根拠も何もないのですが、とにかくそう思ったんです。
  で、何を頑張るかというと、
  『1年以内にオラクルマスターPlutinum(8i)を取得するのだ!』という事。
  それまでには、あとこれだけの試験に合格しなくてはいけません。


  ・DBA
  ・PL/SQL
  ・パフォーマンス・チューニング
  ・バックアップ・リカバリ
  ・ネットワーク


  うーん。大変そうだ。。。

 でも、これの全てに合格できるようじゃないと、DBAとしては役に立たない、と言われたので、
 『じゃあ、さっさと取得して見返してやるぅ!』

 と気合を入れ、前述した5科目の黒本(翔泳社のオラクルマスター教科書)を衝動買い。
  買ってしまえば、やらない訳にはいきませんからね。


 # ちなみに黒本は全てビックカメラのパソコン館で購入。
  # しっかりポイント貯めなきゃ損ですから。


 実際、この頃、障害(リカバリ)テストやら、性能テストやらをやっていたので、
 (隣で見ているだけでしたが・・・)キーワード等を調べるのにも役に立ちました。


 それでは、まずはDBAとして必須の知識になる、その名の通り「DBA編」から始めよう。
  一通り流し読みを終えて、目標設定の為、受験日を予約する事にする。
  Silverの時の試験と比べると範囲がかなり広く、内容も濃いから、1ヶ月後くらいで良いかな。
  という事で、10月中旬に受験する事に決定。


■2001年10月


 とにかく黒本を読んで読んで読みまくる。
  そして、今回は、通勤の電車内でも問題が出来るようにと、iStudyではなく
 通称「赤本」(NRIラーニングの問題集)を使用。
  試験日まで、あと1週間くらいの時点で、かなり自信がついてきた。
  残りの1週間は、復習あるのみ。


 そして、試験当日。
 相変わらず、試験開始までは緊張が激しい。
 試験が始まってしまえば、大分落ち着くのだが。
 自分の中では万全の準備ができた自信があったので、スラスラ解ける。

 『これは絶対合格』と確信に満ちて、終了ボタンをクリック!

 53/64(合格ライン42点)で見事合格!

 これでようやく見習いDBAになれるかな。

  次はPL/SQL。これはプログラミング系だから簡単かな。
 研修ではJAVAをやってたし。それに問題も20問だしね。
 まだ、教科書をほとんど見ていない状態でさっそく2週間後くらいの
 10月末に受験を予約。


 1週間くらい、通勤時と自宅で勉強して、ほぼ完璧。
  「DBA編」に比べると、かなり簡単な印象。
 こちらも、黒本と赤本のみで勉強をしました。
 さて、オラクルマスター試験も、これで4回目。
 もうベテランです。
 
 なのですが、やっぱり試験当日は緊張するものです。
 『次回からは、緊張してる時間減らす為に朝イチに受験しよう。』と決意。
 
 試験はというと、絶対合格はもちろん、満点の自信さえありました。
 さて結果は・・・


 17/20(合格ライン14点)・・・あれ?3問も間違えてた?

 ま、いっか。合格だし、気にしない気にしない。

 これでGoldです。金ですよ金!

 Silverと比べると、大分重みがあります。


 仕事も、ほんの少しだけ分かってきました。
 オラクルマスターの勉強をする事で、少しずつ会話ができるようになってきました。
 宇宙語も少しずつ理解できるようになってきました。


 さて、いよいよPlutinumだ!と行きたいところだったのですが、
 Goldを取得して一安心してしまい、Plutinumの勉強は、結局年明けから開始する事になるのでした。


 続く