2015年9月25日金曜日

ソフトウェア品質の特性の6特性


1. 機能性
  • 要求機能を満たしている
  • 画面や帳票が業務に適している。
  • 業務手順、プロセスとうまく連携している、すなわち,ユーザー要件、目的に合致していること,
  • ソフトウェアやデータが故意や過ちで使用されたり破壊されたりしない。 (信頼性の方が意味付けとしては、正しいのか)
2. 信頼性
  • システムが必要なときに利用できる。
  • 故障(システムダウン)しない。 システムダウンしても迅速に復旧が可能。
  • 代替手順、処理が準備されていること。
3.使用性
  • 操作が容易である。
  • 習得しやすい、使いやすい。


4. 効率性
  • レスポンスが早い
  • 処理時間が短い。
  • リソースを浪費しない。





5. 保守性
  • プログラムやシステムの変更や修正・テスト・拡張が容易に可能。
  • プログラムの作りがシンプルである。

6. 移植性
  • 導入負荷が小さい,他のシステム環境下に容易に移行し稼動できる。
  • オープンな環境下で使用に対応できる。

2015年1月14日水曜日

nzsql コマンド行 オプション

オプション 説明
-a スクリプトからの入力をすべてエコー
-A 桁揃えなしの表出力モード (-P format=unaligned)
-c query 単一の照会 (またはスラッシュ・コマンド) を実行して、終了
-d dbname 接続先のデータベース名を指定
-D dbname 接続先のデータベース名を指定
-schema schemaname dbname 内の接続先スキーマ名を指定します。
-e バックエンドに送信される照会をエコー
-E 内部コマンドで作成される照会を表示
-f filename ファイルから照会を実行し、終了
-F string フィールド区切り文字を設定 (デフォルト: "|") (-P fieldsep=)
-host host データベース・サーバー・ホストを指定 (デフォルト: domain socket)
-H HTML 表出力モード (-P format=html)
-l 利用可能なデータベースをリスト表示し、終了
-n readline 機能を無効化
-o filename 照会の出力を file name (|pipe) に送信
-port port データベース・サーバー・ポートを指定します (デフォルト: hardwired)。
-P var[=arg] プリント・オプションの 'var' を 'arg' に設定
-q 静粛な照会実行 (メッセージなしで照会のみを出力)
-R string レコード区切り文字を設定 (デフォルト: 改行コード) (-P recordsep=)
-Rev バージョン情報を表示し、終了
-rev バージョン情報を表示し、終了
-s シングル・ステップ・モード (照会ごとに確認)
-S シングル・ライン・モード (改行で照会が終了)
-t 行のみをプリント (-P tuples_only)
-time 照会が完了するまでに経過した時間を印刷
-T text HTML 表タグ・オプションを設定 (幅、境界線) (-P tableattr=)
-u username データベース・ユーザー名を指定
-U username データベース・ユーザー名を指定
-v name=val nzsql 変数の 'name' を 'value' に設定
-V バージョン情報を表示し、終了
-W password データベース・ユーザーのパスワードを指定
-pw password データベース・ユーザーのパスワードを指定
-x 拡張表出力を有効化 (-P の拡張版)
-X 起動ファイル (~/.nzsqlrc) を読み込まない
-h or -? ヘルプを表示

nzsql 内部スラッシュ オプション

オプション 説明
\a 桁揃えあり・なしのモードの切り替え
\act 現在アクティブなセッションを表示
\c[onnect] [dbname [user] [password]] 新しいデータベースに接続
\C title 表タイトル
\copy ... クライアント・マシンへのデータ・ストリームに対し SQL COPY を実行
\d table 表 (またはビュー、インデックス、シーケンス、シノニム) を説明
注: \d オプションについては、詳細出力に対してはプラス記号 (+) を追加できます。例えば、\d+ tableまたは \dpu+ name と指定できます。
\d{t|v|i|s|e|x} 表/ビュー/インデックス/シーケンス/一時表/外部表をリスト表示
\d{m|y} マテリアライズ・ビュー/シノニムをリスト表示
\dS{t|v|i|s} システムの表/ビュー/インデックス/シーケンスをリスト表示
\dM{t|v|i|s} システム管理の表/ビュー/インデックス/シーケンスをリスト表示
\dp name ユーザー権限をリスト表示
\dpu name ユーザーに付与される権限をリスト表示
\dpg name グループに付与される権限をリスト表示
\dgp name ユーザーの付与権限をリスト表示
\dgpu name ユーザーに付与される付与権限をリスト表示
\dgpg name グループに付与される付与権限をリスト表示
\d{u|U} ユーザー/ユーザー・グループをリスト表示
\d{g|G|Gr} グループ/グループ・ユーザー/リソース・グループ・ユーザーをリスト表示
\da[+] name 集約をリスト表示、+ でフィールドを追加
\dd [object] 表、型、関数、演算子のコメントをリスト表示
\df[+] name 関数をリスト表示、+ でフィールドを追加
\dl[+] name ライブラリーをリスト表示、+ でフィールドを追加
\do 演算子をリスト表示
¥dO name 表またはビューの列を、列名のアルファベット順にリスト表示
\dT データ型をリスト表示
\e [file] 現在の照会バッファーまたは [file] を外部エディターで編集
\echo text テキストを標準出力 (stdout) に書き出す
\f sep フィールド区切り文字を変更
\g [file] 照会をバックエンドに送信 (結果は [file] または |pipe)
\h [cmd] SQL コマンドの構文に関するヘルプを表示。すべてのコマンドの構文ヘルプを表示するには * を付加
\H HTML モードの切り替え (デフォルトはオフ)
\i file file から照会を読み取り、実行
\l すべてのデータベースをリスト表示
\o [file] すべての照会結果を [file] または | パイプ に送信
\p 現在の照会バッファーのコンテンツを表示
\pset opt 表の出力 opt = {format|border|expanded|fieldsep| null|recordsep|tuples_only|title|tableattr|pager} を設定
\q nzsql コマンドを終了
\qecho text テキストを照会出力ストリームに書き出す (\o を参照)
\r 照会バッファーをリセット (クリア)
\s [file] 履歴をプリント、または [file] に保存
\set var value 内部変数を設定します。変数または引数なしで \set を指定すると、現行セッションの変数およびそれらの値のリストが表示されます。
\t 行のみを表示 (デフォルトはオフ)
\time 照会にかかる時間をプリント
\T tags HTML 表タグ
\unset var 内部変数を設定解除 (削除)
\w file 現在の照会バッファーを file に書き込む
\x 拡張出力の切り替え (デフォルトはオフ)
\! [cmd] Shell エスケープまたはコマンド

2014年8月31日日曜日

ささややかなビッグデータ

300万件や5000万件のデータで四苦八苦していたあの頃は何なんだろうと思う。10万件のデータをExcelに落として65536件に入りませんと新入社員の頃、言ってたのは何だったのか。

目の前には5億件のデータが簡単に入っており、いとも簡単に扱うことができる。

5億件のデータを1分で3件正しいかを判断するコツを人間が掴んだとしても、24時間(1日で4320件しか見れない。全部見るのに115740日、約317年間だ。人で言えば、3~4世代、引き継がれる。
でもSQL文だと5分以内で戻ってくる。

そして、これをシュミレーションをする為に30倍、40倍のデータにしている訳であるが、これも、あっという間にできてしまった。。。。家に帰って、朝起きてトーストを食べている間に。

200億件。

このデータの正しさは何なのか?

200億件とわかるのは、count文を発行したからである。決して目で見たわけではない。
金額の合計・平均がわかるのは、sum文、avg文を発行して、コンピューターが返してくれるからである。決して200億件、すべて足して、件数で割った訳ではない。

そんなデータがいとも簡単に手元で扱えるようになったことにに、素晴らしいさと若干恐れも感じる今日この頃である。

2014年8月2日土曜日

各社の買収された製品に思うこと

大手のメーカー、ソフトウェアベンダーが買収を続けているが、それらを使ってみて感じることは、どんどん品質としてはバラツキがでてきていて、無秩序な状態になっているなと感じる。以前は、各社とも、一定の品質があった。品質を語るには、あまりに自分には知識はないが、たとえば、マーケットからは見えずらいが、アーキテクチャ・デザインをした際のソフトウェアの柔軟性、長く使っていく為に必要な製品自体の性能、状態をモニタリング、評価できる機能、コアダンプへの出力内容、保守時における手順のやりやすさ、など、あまりビジネスに関係ないところにおいても、一定の配慮がされていた。不足している製品があっても、それに追いつこうとする意志を感じられた。

しかし、今やマーケットやその製品ビジネスバリューで、あまりにもたくさん買って、製品毎のマーケット別ポートフォリオは存在しているのだが、そこまでかなという感じだ。

なんとなく良さそうなのだが、実際の業務で使ってみると、不備が多々、見受けられるパターンがある。その時、今までの製品は、あれだけの品質を保っているのに、なぜなんだろうと、当然ながらの質問を購入者は思う。

一方、ベンダー側も、一定の品質に保とうと一定の努力はしているのだが、決定的に大事だった技術者が辞めてしまったり、マーケットとしての価値が下がったりして品質改善のコストは少額になったりして、買収された製品の中でも当然ながら、バラツキが出てくる。

うーん。まあ、使える製品、使えない製品として統廃合されていくことは正しいが、今後も延々とこの繰り返しなんだろうなと思うと、これって一体何なのかなー、と思うことが多い。

例えはいいか別として、水や電気やガスのインフラは、一定の品質を保っている。ここは、崩れてはダメな部分だ。崩れないように、日々、保守を実施している。ソフトウェアも同様だ。ただ、ソフトウェアは進化し続けている。その中で一定の品質の安定さが欲しいと思うことが多い。
まあ、銀行やその他、数多くのシステムが一定の正常さで動いているわけ(このブログもそうだし)であり、それを一定の安定さと受け止めればいいわけであるが、決定的に、建築や水やガスとは異なるものだということは、その中にいるものとしては思う。


2014年7月25日金曜日

nzload memo②

①外部表形式でのロードと実はスピードが変わらないとブログで報告している人は、英語系では多数。本当か、検証してみる必要あり。ただ、インターフェースファイルが多いと外部表定義も多くなるので、それは管理がめんどくさい。外部表自体を動的に都度作成・削除することも可能だと思うが、GROOMの処理との関連が気になる。

②営業資料は結構なスピードでの資料になっているが、結局はロード元(ファイル格納場所)のストレージの性能がパフォーマンスに大きく関わる。Netezza内には通常ファイルは格納できないので、別途通常のストレージに置いてからのロードになる。

2014年7月21日月曜日

Netezza Tool  Aginity



NetezzaへSQL DeveloperやSI Object BrowserやPL/SQL Developerのようにアクセスするクライントツールである。使いづらいところもあるが、それなりに使える。フリーツールであるが、ユーザー登録は必要。ライセンスが登録したメールに送られてくる。

http://www.aginity.com/workbench/netezza/

後は、付属しているAdministorator Toolかな。

2014年6月25日水曜日

netezza _V_RELATION_COLUMN

_V_RELATION_COLUMNは、テーブル内の利用可能な列の情報を参照可能。DB、スキーマ別のテーブル名、列名、型を参照可能。

2014年6月9日月曜日

単体テストのと結合テストの異常系テスト内容について

単体テスト(UT/PT)の異常系テスト内容と結合テスト(サブシステム内)の異常系テスト内容は、結局何が異なるのか? とクライントから指摘されたことがある。
結局は、同レベルのことしかできないのではないか?、という内容である。この発言は、UT/PTの中でモジュール単位のテストとプログラム単位のテストの2つのテストを実施していることが前提となっている。つまり、PTの中で、ある程度結合してテストをしていて、その単位がIT(サブシステム内)の機能単位とあまり変わらない為である。

実際に実施してみると、運用ツールとしてSkyWalk(ジョブ・ツール)で実施して、UT/PTと同様のエラーケースを実施したりと、あまり意味がないよね、運用ツールを使って動かしたことが唯一のテストかーみたいな話になる。

かと言って、障害リカバリーを見据えたテストをしたいが、そこまで品質が追いついていない。

2014年5月27日火曜日

netezza _v_dual

OracleのDUALと同じ扱いのNetezzaのViewは、下記だと思う。





In Netezza:
select current_date from _v_dual;

2014年5月15日木曜日

nzload memo①

Netezzaのnzloadの検証をして、わかった点を下記に記す。OracleやDB2のLoader機能と同一の機能を期待していると、痛い目に合う。適切な時期に簡単な技術検証をしておくべきである。

① オラクルのCTLファイルと同様、制御ファイルの考え方はあるが、使えるものではない。単純にスキーマやDB、ロードテーブル、コマンド・オプションの記述等の指定ができるだけである。致命的なケースとしては、ファイル内容に合わせて列指定におけるロードができない点。固定長ファイルでないと列指定はできない。

② 日付やタイムスタンプをロード時にデフォルトで挿入することはできない。オラクルならば、制御ファイルの中で、項目名 DEFAULT SYSDATEでロード時の処理タイムスタンプ等を格納できるが、Netezzaではできない。

③ ファイル・デリミタ、日付デリミタ等は可能。日付の形式も指定可能。エラーの最大許容件数の指定、ログの出力先の変更も可能。固定長ファイル形式はそれなりに使える。

2013年10月17日木曜日

JP1 & SPSS Modelerer Server memo

1. ShellからSPSS Modeler Batchを起動
         SPSSサーバ上にストリームファイルを配置
    SPSSサーバーが二重化していた場合は、その起動方法を確認

2. ShellからPython APIでC&DS経由でのSPSSジョブ起動
    SPSSストリーム定義は、ファイルシステムではなく、リポジトリ定義
    C&DS上でのジョブ定義
    監査ログはC&DSが出力。No1の場合は、shellで自ら出力
    DB認証はC&DS定義。負荷分散はC&DSが自ら実施。

2013年6月24日月曜日

思い込みによるデータストアの違い

大分見えてきた仕様について、データーフローダイアグラムで仕様を落とすようにという指示の元、処理機能記述書を記述してみた。それをチーム内レビューしてみたら、どうにも話が合わない。相手は、データストアに対する処理とデータフローに入れる為の処理は異なるというのだ。こちらは、データストアはテーブルのイメージで、そこからSQLでデータを抽出すればよいのだから、処理機能記述書には、そのSQLの内容を書けばよいと思っていた。

しかし、彼はその発想ではなく、データストアは、Javaのエンティティ・オブジェクトのイメージだから、データストアの処理とデータフローの処理は、確実に分離しているのだ。

おっと、自分がどれだけ先入観に、とらわれているんだと思った。長年のやり方に、はまってしまっていることを反省したが、日々の中では気付かないことも多々あるのだろう。

ちょっとした考察。

2013年4月16日火曜日

トヨタ カイゼンの為の訓示(鬼十訓)

リーンも参考にした トヨタ生産方式を開発した大野耐一さんの訓示のメモ。
マインドの持ち方の話ということで自己啓発的な側面もあるが、カイゼンというものに対する態度という意味で、真摯に取り組んでみることが大切ということを感じた。

特に下記の5点については、今から私自身が変えるべきポイントという意味で強い刺激を受けた。

・モノをつくるのではなく、「必要なモノをつくる」。
・まずやらせるな。まずやってみせろ。
 汗をかかせるな。知恵に欠けてくる。
・多忙を改めたいなら、仕組みを改めることだ。
・やさしいことはくり返し言え。
・「できる」信念も、「できない」信念も強さは同じだ。

第1訓
君はコストだ。まずムダを削れ。それなくして能力は展開できない。

ムダは隠れる。仕事の隠しごとをまずやめよ。
小さな数字を集めろ。大きなムダが見えてくる。
過去の数字で計画を立てるな。過去のムダを引き継ぐことになる。
生産性で自分をはかれ。忙しさは生産性ではない。
モノをつくるのではなく、「必要なモノをつくる」。

第2訓
始めたらねばれ。できるまでやめるな。中途半端はクセになる。

わかったつもりになるな。「まだ」に発見がある。
応急処置を避けよ。「その場でとことん」をクセにしろ。
「できるかぎりやる」でなく、「できるまでやる」んだ。
満足しても慢心するな。自信があっても過信をするな。

第3訓
困れ。困らせろ。安易を好む人と決定的な能力格差がつく。

大増産を小増員でやれ。成長の秘密はそこにしかない。
仕事は「可能か」で決めるな。つねに「必要か」で決めよ。
答えを教えるな。考えさせる工夫をしろ。
ほしいときは「なくても」で、上げたければ「下げたら」で発想せよ。
人を動かすには気持ちを揺さぶる。揺さぶるには困難を持ち込む。

第4訓
ライバルは君より優秀だ。すなわち君は「今」始めることでのみ勝てる。

様子を見すぎるな。タイミングに見放される。
なんでもその場でやれ。なんでもすぐ片づく。
明日でも対策は見込めるが、今日なら良策が仕込める。
積み上げが、仕事を鍛え上げる。

第5訓
仕事に痕跡を刻め。十割を命じられても十一割めを自前の知恵でやれ。

「できた」で止まるな。「もっとできる」に進め。
言葉通りにやらず、言葉に知恵を足せ。
一律を避けよ。労働強化のもとになる。
教えるな。気づかせろ。

第6訓
平伏させず心服させろ。そのためにはだれより長い目で人を見ることだ。

適材適所に「適時」を加えよ。
手をかけ時間をかける。そうしてこそ人から声がかかり始める。
まずやらせるな。まずやってみせろ。
汗をかかせるな。知恵に欠けてくる。

第7訓
「できる」とまず言え。そこに方法が見つかる。

「できる」を信じる。「できない」は疑う。
知恵は平等だ。知恵の引き出し方で差がつく。
評論家を評価するな。批判で判断を終えるな。
多忙を改めたいなら、仕組みを改めることだ。

第8訓
失敗を力にしろ。真の自信も運もリカバリーから生まれる。

成果を上げるには、ネを上げないことだ。
「失敗だ」とあきらめるな。「失敗にしたくない」と発想せよ。
支持されたいなら、指示を減らすんだ。
数字の嘘を見抜け。教師は現場である。

第9訓
労働強化を避けよ。人間「ラクになるには」に一番頭が働く。

「平均的に」はラクではない。「最速で」がラクである。
失敗パターンを改善せよ。成功パターンも改善せよ。
目標値が高ければ、出発点は低くていい。
利潤で決めていいが、利潤だけで決めてはならない。

第10訓
お客の叱声は成功の呼び声だ。逃すな。いじけるな。考え抜け。

相手を変えたいなら、自分が変わるんだ。
むずかしいことはやさしく言え。やさしいことはくり返し言え。
「できる」信念も、「できない」信念も強さは同じだ。
いいチームにせよ。いいチームができたら改善せよ。

2013年1月11日金曜日

データ・サイエンティスト

昨年ころから、ビッグデータと結びつけられてデータ・サイエンティストという言葉が、そこそこ出てきたという気がする。データ科学、科学的思考、統計学、可視化技術、先端コンピューティングという複雑なData scientistの領域で、複雑なデータの問題の解決に従事する人を呼ぶそうだ。

ビッグデータとデータ・サイエンティストは、元々は別物の話であるが、昨年からのビッグデータの高まりから、同様に理解されていることが多い。

データ統計解析環境として、「R」と呼ばれるオープンソースがあるらしい。今年は少し試してみようかと思う。
http://cran.md.tsukuba.ac.jp/

2012年12月31日月曜日

In no time, year end !

気づいたら、年の瀬であり、今年も終わってしまいますね。
12月は、ほとんど投稿ができなかったのは反省。年明けは、2-3日に1Postを継続したいな

2012年11月30日金曜日

Oracle Transparent Gateway / Oracle Connectivity→ Oracle Gateway

Oracle Connectivityと呼ばれていた機能が、Oracle Transparent Gatewayと合わさり、Oracle Gatewayという名前に変えて、11gより展開されている。無償という話だが、本当か。

Oracle & MySQLで検証してみるか。

2012年11月27日火曜日

emacs org-mode memo

Emacs23から同梱されたアウトラインエディタ。
ファイルの拡張子を.orgにすることで自動的にモード変更される。

アウトライン編集、箇条書きのリスト化、表入力

[Command]
TAB
M-RET

2012年11月22日木曜日

2012年11月21日水曜日

DRIVING_SITE memo

DRIVING_SITEヒントを使用すると、問合せが実行されるサイトを指定可能。
オプティマイザを無効にする場合は、手動で実行サイトを指定。

データベースリンク間で非効率な実行計画が実行されている場合、本ヒントも有効。
もしくはジョインをどちらかのテーブルに寄せる。 これは設計が元々悪いのか!

2012年11月20日火曜日

スキーマ・オブジェクトの依存性

依存オブジェクトと参照オブジェクトについては良く言われている。
昔の時代は、依存性が正しい形であっても、実行時エラーで落ちるような時代があった認識している。(昔からオラクルを触っているメンバーは、皆そう言う人が多い。)
 しかし、今のマニュアルを参照する限り、実行時もしくは参照時に検証、再コンパイル行うの、問題がないと記述されている。但し、その影響として、以下2点があると書かれている。

1. 無効になったオブジェクトが多数ある場合は、初期実行時の待機時間が長時間になる可能性がある。 (但し、逆を言えば、依存性を見つつ、再コンパイルしているということ、と理解している。)
2. 無効になったオブジェクトを別セッションで同時に実行していた場合、以下のORAエラーが発生する。
  ORA-04061 -- stringの既存状態は無効になりました。
      原因: プロシージャが変更または削除されたため、無効になった既存状態またはストアド・プロ
              シージャと矛盾が発生した既存状態を使用して、ストアド・プロシージャの実行を再開しよ
              うとしました。
      処置: 再試行してください。このエラーでは、すべてのパッケージの既存状態に再初期化が
              必要です。
  ORA-04064 --- 実行されませんでした。stringは無効になりました  
      原因: 無効になったストアド・プロシージャを実行しようとしました。 
      処置: 再コンパイルしてください。
  ORA-04065 ---実行されませんでした。stringを変更または削除しています
     原因: 変更または削除されたストアド・プロシージャを実行しようとしたため、コール元プロシー
              ジャからのコールができません。
      処置: その依存関係を再コンパイルしてください。
  ORA-04068 ---パッケージstringstringstringの既存状態は廃棄されました。  
      原因: ストアド・プロシージャを実行しようとして、4060から4067のいずれかのエラーが発生し
      した。  
      処置: アプリケーション状態を完全に再初期化してから、プロシージャを再試行してください。

上のマニュアルを信じる場合、間違ったオブジェクトをUpせず、アプリ処理を無風状態にしておけば、どんなにInvalidが増えても、時間をかければ自動的にValidになるということで、昔の時代の認識は、もう過去のものということになる。本当かな?

あと、コンパイル系の検証、再コンパイルは、DBMS_UTILITY(11gのリンク)UTL_RECOMP(11gのリンク)が有効。

2012年11月15日木曜日

Think occasionally

本番機で稼動しているプログラムを参考にプログラムを書くことがある。コーディング規準の形に沿っているので、作業がしやすい為である。ただ、ソースをよく読んでいくと、まったく機能していないエラーハンドリングとかをよく見つける。この開発者は本当にテストを実施してきたのだろうかと疑問に思う。これでイイと思って、ロクにテストもしていないことがわかるプログラム程、いやなものはない。

2012年11月12日月曜日

DataPump 11g R2

11gR2版。TABLE_EXISTS_ACTIONのパラメータの動きに注意。

Oracle Data Pump Import(impdp) のパラメータ
http://docs.oracle.com/cd/E16338_01/server.112/b56303/dp_import.htm#i1010670

Oracle Data Pump Export(impdp) のパラメータ
http://docs.oracle.com/cd/E16338_01/server.112/b56303/dp_export.htm#i1006293

あと、方法としては以下の3つ。通常使うのは1番が多いけど。PL/SQL内で完結させることもできるということがわかった。
  1. コマンドライン・クライアントexpdpおよびimpdp
  2. PL/SQLパッケージDBMS_DATAPUMP
  3. PL/SQLパッケージDBMS_METADATA

2012年11月5日月曜日

SQL Plan Management

共有SQL領域から実行計画をロードすることも可能。便利だ。

DECLARE
  my plan PLS_INTEGER
BEGIN
  my plan := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE( sql_id = > 'SQL_ID' );
END;
/




oracle manual

[構文]
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE (
   sql_id            IN  VARCHAR2,
   plan_hash_value   IN  NUMBER   := NULL,
   sql_text          IN  CLOB,
   fixed             IN  VARCHAR2 := 'NO',
   enabled           IN  VARCHAR2 := 'YES')
 RETURN PLS_INTEGER;

DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE (
   sql_id            IN  VARCHAR2,
   plan_hash_value   IN  NUMBER   := NULL,
   sql_handle        IN  VARCHAR2,
   fixed             IN  VARCHAR2 := 'NO',
   enabled           IN  VARCHAR2 := 'YES')
 RETURN PLS_INTEGER;

DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE (
   sql_id            IN  VARCHAR2,
   plan_hash_value   IN  NUMBER   := NULL,
   fixed             IN  VARCHAR2 := 'NO',
   enabled           IN  VARCHAR2 := 'YES')
 RETURN PLS_INTEGER;

DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE (
   attribute_name   IN VARCHAR2,
   attribute_value  IN VARCHAR2,
   fixed            IN VARCHAR2 := 'NO',
   enabled          IN VARCHAR2 := 'YES')
  RETURN PLS_INTEGER;
 
【パラメータ】











2012年10月30日火曜日

Outline & OAF

後で詳細にトレースすること。
OAFで実行されるSQLをStored Outline化し、DBA_OUTLINES、V$SQLを参照して、使われるかどうかを見たが、使われず。一度ログオフして、再度参照するとDBA_OUTLINEのUSE列が変化した。VO側のキャッシュのせいなのだろうか?


2012年10月27日土曜日

Migrate From Stored Outline To SQL Plan Management

Stored Outlineは次バージョン以降で廃止が予定されているということで、SQL Plan Management Plan(以下、SPM)をオラクルは今後推奨。また、Stored OutlineからSPMへのi移行を実施するパッケージ・プロシージャが提供されている。

【必要な権限】
DBMS_SPMパッケージに対する実行権限
ADMINISTER SQL MANAGEMENT OBJECT権限

だと思う。

【移行方法】
DBA_OUTLINES のMIGRATED列が  'NOT-MIGRATED'のアウトラインが、移行前のアウトラインである。 DBMS_SPM.MIGRATE_STORED_OUTLINE ファンクションを使用してアウトラインを
ベースラインに移行するCATEGORY 列を用いて対象を絞り込んで移行するには以下の様に設定する。
-----------------------
DECLARE
  my_rep CLOB;
BEGIN
  my_rep := DBMS_SPM.MIGRATE_STORED_OUTLINE( 
  attribute_name => 'CATEGORYの列を指定', 
  attribute_value => 'OUTLINE名を指定'
  );
END;
/
---------------------- 

【格納されているベースラインの実行計画を見る方法】
select * from table(dbms_xplan.display_sql_plan_baseline(sql_handle=>'XXXXXX'));
【格納されているベースラインを使用したかどうかを確認する方法】
 Stored Outlineでは、DBA_OUTLINESやV$SQLを参照するとアウトラインを使用したかどうかが
 わかるが、ベースラインでは、そのようなビューは見当たらない。あくませ、Acceptedしている
 かどうかである。

その場合、
 1. set autotrace traceonly explainでNotesを見るか
 2. select * from table(dbms_xplan.display_cursor('SQL_ID','CHILD_NUMBER')); 
 でSQL_IDとCHILD_NUMBERを指定してNotesを見るかのどちらかである。
'XXXXXX'は、dba_sql_plan_baselinesビューのsql_handle列を指定する。

2012年10月25日木曜日

emacs -- config --

とりあえず。勉強は続ける。

;; ツールバーを非表示
(tool-bar-mode 0)

;; カラム数を表示
(column-number-mode t)

;; TABの表示幅
(setq-default tab-width 4)

;; 時計の表示
(display-time-mode t)

;; 行番号を常に表示する
(global-linum-mode t)

;; Title Bar
(setq frame-title-format "%f")

;; cua-modeの設定
(cua-mode t) ; cua-mode on
(setq cua-enable-cua-keys nil) ; CUAキーバインドを無効

フィルタ述語とアクセス述語

基本をメモ

フィルタ述語: 行頭の番号に対応するオペレーションの実行時に、取得したデータから 対象データを抜粋(フィルタ)する処理

アクセス述語: 行頭の番号に対応するオペレーションの実行時に、表示された述語を使用して データにアクセスしたことを示す。一般にINDEX Scan系の処理の場合に表示される。

アクセス述語の場合、データが選択的に選ばれるため、ブロックアクセス量は少なく、
フィルター処理はデータにアクセスした後に絞込みをかける為、アクセス述語に比べるとブロック数
は多い。

2012年10月22日月曜日

問い合わせによる一時変数の置換 --- refactoring ---

一時変数は、一時的でかつローカルな使用の為、メソッドの内容を理解してたどり着く必要がある。つまり、長いメソッドになりがちである。それらを問い合わせメソッドにしてしまうことにより、内容の理解を容易にし、他のメソッドからも呼び出すことが可能になる。

[リファクタリングを行いやすい状況]
 ・ 一度だけ代入される一時変数
 ・  代入される値をつくる式が副作用を起こしにくい。

[Example: from Refactoring by Martin Fowler]
double basePrice = _itemprice * _quantity;
if (basePrice > 10000)
  return basePrice * 0.95
else
  return basePrice * 0.98


   if (baseProce() > 1000)
     return basePrice * 0.95
   else
     return basePrice * 0.98

double basePrice() {
  return _itemprice * _quantity;
}

2012年10月12日金曜日

CURSOR_SHARING Memo

============================================
CURSOR_SHARINGでは、同じカーソルを共有するSQL文の種類を判断。
    FORCE
      既存のカーソルを共有する場合、またはカーソル・プランが最適ではない場合に、新しいカーソルの作成が許可される。
    SIMILAR
      リテラルがわずかに異なっても、その他が同じSQL文であれば、
    その異なるリテラルがSQL文の意味または計画が最適化される程度のいずれかに
    影響しないかぎり、カーソルが共有される。
    EXACT
      同一のテキストを含む文のみに、前述のカーソルの共有が許可される。
============================================

9i当時はSimilarにすることで、複数のリテラル値でも共有カーソル化されると売りだったが、
現状のオラクルコメントは以下の通り。優れたカーソル共有」機能には更に分析が必要。

CURSOR_SHARING=SIMILARの設定は11.1以降のリリースでは推奨されません。
次のリリース(12.1)ではこの値は廃止される可能性があります。
11.1以降のリリースではCURSOR_SHARING=FORCEを設定し、3.でも紹介した11.1の
新機能「優れたカーソル共有」を利用することが推奨されています

2012年10月9日火曜日

GitHub Manual

とりあえず、ソースを「GitHub」にUpしてみた。使い方は、まだわかっていないが、WWWに転がっている各種ドキュメントを見ながらやると、何だかんだで、できてしまうのが、今の時代の凄さを感じるな、やはり。

http://git-scm.com/documentation

SQL Developer Custom Report 001 - v$sql_monitor -

SQL Developerでのレポート作成実施。v$sql_monitorからsqlを抽出し、その実行計画を子レポートで出力する。

ダウンロードして、SQL Developerのレポートタブで取り込んでください。
間違っていたりしたら、改善ポイントを御指摘頂けると、嬉しいです

RealtimeSQLMonitor_ExecutePlan.xml

2012年9月30日日曜日

CxOとSI

デザイン・パターン、アジャイル、XP、TDD、Continuous Integration、リーン等の開発プロセス改善の進展や、クラウド等の技術改革は、IT業界に居る私にとっては、とてもホットなネタ(古いネタもあるが)ばかりで面白い。

しかし、「CxO」と呼ばれる経営層には、何の興味も沸かない事項だと思う。売上も利益も上昇し、可視化される形で見えないのだから。企業全体の枠組の中において、ITは密接してつながっているのだが、やはり「ツール」、「わからないもの」、「金はかかるが、金を生み出さないもの」としての位置づけにしかなっていない。

在庫が削減されて、かつ在庫高がYTYで減少し、キャッシュフロー計算書にも明確なキャッシュの増額が見えない限り、上記のコンセプトは、全くもって、CxOのココロには響かない。SIerのコストが安くなるぐらいの理解しかしていないんだと思う。

読みやすいコードを書き、カバレッジを最大限満たしたテストを実施し、作らない開発で今までのものを再利用する。それはそれで知見を持ちつつ、ビジネスにインパクトを与えてCxOが面白いと思う話題を提供する必要がある。彼らの世界で生きる必要があるのである。そこで、「達人プログラマー」の話はしてはいけない。あまりにも、ビジネスを見ず、XPそのものに興味を持ってしまう人が多いと思う。 かくいう私も、その傾向はある。

XPそのものに興味を持ちつつも、ビジネスにインパクトを与える為に最も近い道は、結局、自分でサービス、製品を開発して、市場で売っていくしかないと思う。そうしないシステム・インテグレーションは、テック・マニアになるか、 標準プロセスマニアになるか、テックのことを何も知らずに、知らないが故に強みを発揮するビジネスコンサルタントになるしかない。CxOが気にいるのはビジネス・コンサルタントである。何故なら、CxOの興味のある事柄を掘り下げ、分析、考え、提案してくれるからである。

この負け試合を必ずひっくり返してやろうと思っている。

2012年9月18日火曜日

Bloom where God has planted you.

自分はキリスト教でも何でもないが、久しぶりにココロに響いたコトバなので、記しておこう。本は読まないと思うけど、このコトバだけで充分だ。  「あなたが置かれたところで咲きなさい」


渡辺和子さんの著作「置かれた場所で咲きなさい」より

2012年8月26日日曜日

RAC その①

少しまとめ。

1.HA構成       
    アクティブ-スタンバイ構成 。CPUライセンスは最小になる可能性は高い。
  スタンバイ側はリソースをDLPARで設定して最小限しておく。

2. 共有ディスク構成       
    シェアード・エブリシング   
    ノード追加時のI/O競合がネック。H/WのSpecを考慮する。

3. 非共有ディスク構成       
    シェアード・ナッシング   
    H/W故障時に一部のデータにアクセス不可。可用性に弱点。

4. RAC(共有ディスク + キャッシュ・フュージョン)       
    共有ディスク単体に比べれば、一定の数までノードを追加できる。
    100ノードまでのスケジュールアウトを実現(オラクル社の公式見解)
  キャッシュ・フュージョンは、インターコネクトを使用したメモリ内に展開されているデータの同  
  期。データファイルではない。

2012年7月31日火曜日

The Agile Dilemma

これは正しいレポートだと思う。あまりにもAgileは喧伝されすぎているし、その背後にある難しさが隠されている。Agileには、一定のガバナンスとルールを制定することが必要だと思う。それは開発者に対してではなく、プロジェクトに対してである。

物議を醸すVokeの報告がAgile採用者に警告

2012年7月27日金曜日

DECODE

 DECODE 
      数値の等価、大小関係を評価するには SIGN 関数。
      SIGN ( expr
      Return:[+1:整数、0:ゼロ、-1:負数]

   最小 、最大を評価するには、GREATEST関数、LEAST関数
   GREATEST ( expr_list )
   LEAST ( expr_list )
      Return: 最も小さい、大きい数。文字列。

2012年7月3日火曜日

PureSystem

 メモ。Flex System Managerの2重化は必要ないのか?

 Expert Integrated System
   PureFlex ---  サーバー、ストレージ、ネットワーク、そして仮想化の一元管理、最適管理
       power , x86
       Storage V7000
       Integrated (Flex System Manager)
       PowerVM
   PureApplication
+ Application -- パターン化による最適化

2012年6月27日水曜日

Continuous Integration -001-

継続的インテグレーション」の翻訳版が2009年(USでは2007年)に発刊され、昨年は「継続的デリバリー」も発刊された。クライアントの中でも、本で記述された内容まではいかないが、ビルド、デプロイの自動化をスクラッチで実装する事例がでてきた。
今年の目標はRQM + RTCの連携検証にJenkinsを絡めて、トータルな継続的デリバリーの基盤を構築したい。とかく、開発者としての興味がある範囲なので、面白いということが先行するが、目指すところは、ムダの排除だと思っている。ビルドミス、リグレッションテストミス、デプロイミスといったビジネスと関係ないところのミスを最大限低減することである。

2012年6月13日水曜日

FAH-GL Tuning Memo

・ 初期化パラメータの調整
・ 統計情報の最適化(特に初期実行時)
・ 「会計の作成」のパラレル化(CPUスレッド数を意識)、アドオン・コンカレントマネージャの作成。
・  「会計のプログラム」のプロセッサ数、一回あたりの処理単位の調整(自環境でのベンチマーク実施は必須)
・ バッチ処理実施時における「XLA_EVENTS」の未処理データの扱い。標準プログラムのSQLが未処理データを常に参照する為、本当に必要な範囲で「XLA_EVENTS」に取り込む。取り込み時はバルクAPIを使えるならば、使ったほうがよい。
・ 各コンカレントマネージャのポーリング時間の調整。
・ アドオンの取込の際にFAHのテーブルを見てチェックロジックを入れる場合は、アプリケーションIDとイベント区分を必ず入れること。FAHのテーブルは、その2つでパーティション化されている為。

Clean Coder (Chapter6. Practice)

この本に限ってではないけど、西洋の人達は、「型」とか「乱取り」とか、「サムライ」とか「禅」というコトバが、いつでも好きだな。際限の無い目的思考から離れ、その日常の生活の中での繰り返し(ミニマム)を大事にする。逆に目的をきちんと考えずに説明資料を作成したり、行動を実施する日本人は、西洋人のプレゼン・スタイル、説明スタイルを見習っているのに。。

日本人の自分としては、「Practice」というコトバが好きだ。際限の無い「Practice」を継続的に続けることが、プロフェッショナルとしての1つのルールだと思う。

2012年6月5日火曜日

Clean Coder (Chapter5. TDD)

Clean CoderのTDDの3原則はくどく感じたので、自分なりの解釈を記述してみる。
  • ソースコードを記述する前に失敗する単体テストケースを記述すること。ソースコードが完成する直前には、自動化されたテストケースが完成している。(Coverage 90%以上)
  • 単体テストケースを記述することは、モジュールの疎結合を目指すことになる。(テストが実施できるソースを開発するようになる為)
  • ソースコード完成時に、数分以内に完了するリグレッション・テストが用意可能になる。(変更に対する恐れがなくなる。自動化された単体、受入テストケースが無い場合、結局は大丈夫だと思って実施しないテストケースがでてくるが、その内容が自動化されたテストケースに含まれることになり、より堅牢になる)

2012年5月23日水曜日

Oracle DB Cache Clear

10gからの進歩ですね。忘れずに。

共有プール クリア
 (ライブラリキャッシュ<解析済のSQLやPL/SQL等>、データディクショナリキャッシュ)
ALTER SYSTEM FLUSH SHARED_POOL;

データベースバッファ キャッシュ クリア(10g~)
(データファイルから読み込まれたデータ・ブロックのコピーが格納される領域)
ALTER SYSTEM FLUSH BUFFER_CACHE ;  

2012年5月21日月曜日

strings & files

滅多に使うことはないと思うが、stringsコマンド
「ファイルから文字列相当と認識できる部分を探して表示する」
バイナリファイルとかが有効。バイナリファイルがコンパイル時に内部に取り込んだディレクトリとかをgrepと合わせて検索することが可能

$ strings -f /user/bin/*.exe  XXXXX.exe | grep .....

みたいな感じかな。今まで数回しか使ったこない。

こちらの方が使うかな。fileコマンド。
指定されたファイルを分析して、ファイルの種類」を表示してくれます。
$ file [file name]でOK.

2012年5月16日水曜日

emacs (dired) -起動-

同じフリーである「Sakura Editior」等に戻りたくなる気持ちに負けず、「emacs」 を無理やり使っているが、少しづつ慣れてきた。今更ながら、「ディレクトリエディタ(dired)」について学ぶ。

C-x dM-x dired

別フレームで起動したい場合は、C-x 5 ddired-other-frame 
別ウィンドウでC-x 4 d (dired-other-window


2012年4月14日土曜日

V$SQL_PLAN

V$SQLから調査したいSQLを探し出した後、ADDRESS、HASH_VALUEやSQL_IDでV$SQL_PLANから実行計画を取得し、整形するスクリプト(小田さんのページから借用)

【パターン①】
column id format 999 newline
column operation format a20
column options format a15
column object_name format a22 trunc
column optimizer format a3 trunc


select id
, lpad (' ', depth) || operation operation
, options
, object_name
, optimizer
, cost
from v$sql_plan
where hash_value = &hash_value
and address = '&address'
start with id = 0
connect by
(prior id = parent_id
and prior hash_value = hash_value
and prior child_number = child_number
)
order siblings by id, position;


【パターン②】
column id format 999 newline
column operation format a20
column options format a15
column object_name format a22 trunc
column optimizer format a3 trunc


select id
, lpad (' ', depth) || operation operation
, options
, object_name
, optimizer
, cost
from v$sql_plan
where sql_id = &sql_id
start with id = 0
connect by (prior id = parent_id
and prior sql_id = sql_id
and prior child_number = child_number
)
order siblings by id, position;