pass the days -10ページ目

bonds


学生時代、AUSという国への短期留学から帰ってきた次の日から聴き狂っていた曲。

siren's reverb と共に。

ひたすら聴いたな。


永遠に胸の内にあるアーティスト。




しみじみと、小田急なうな時間。

photo:01




ナゴヤを喰いに行く。

iPhoneからの投稿

oracle #4


フィギュアスケート見入ってしまいますね。

美しー。

ロシアまで行って応援したかったなー。

というか、アスリートはすげぇなほんと。

ストイックだよ、根性が半端じゃないな。

刺激を喰らいますわ毎度。


では、本日はoracleの監査について書きます。

監査とはユーザ処理やバッチ処理によるデータベースの動きを証跡として記録することで、企業の内部統制の強化に必要不可欠な機能として利用されるものです。

ではまずどのようなフローで監査がされるかというと、

1.データベースに対し何らかの操作を実施する。
2.操作が監査対象かデータベースがチェックする。
3.監査情報を出力する。

というような流れになっています。

それにより、データの情報漏洩や改竄等の不正行為を防ぐ事が可能となります。

では、監査はどーやって設定できるか?

それは、初期化パラメータ
audit_trail
で設定できます。

値は、
NONE:無効
DB:DB監査証跡
OS:OS監査証跡
DB,EXTENDED:sqlbind列が追加
XML:XML形式のOS監査証跡
XML,EXTENDED: sqlbind列が追加


ここで、上記パラメータを設定しただけでは何も出力されません。

ということで、AUDIT文で監査対象を個別に指定します。

実はこの指定方法も3種類あります。

奥が深いですね。

1.文監査
発行されたSQLの種類によって監査対象を指定。

2.権限監査
発行されたSQLが使用したシステム権限の種類によって監査対象を指定。

3.オブジェクト監査
発行されたSQLがアクセスしたオブジェクトと、オブジェクトに対する操作の種類によって監査対象を指定。

この監査機能、べんきょーしていてとても奥が深い故に様々な機能との組み合わせがあることが判明した為、じっくり紹介していきたいと思います。


ではー。


ブンデスリーガもかなり面白いわ。



今度スポーツショップ行ってガット張り替えねば。

よし:)

iPhoneからの投稿

recipe #3


今夜は久々にゆったりできた為ウザいほどのこーしん笑

実は8年間お世話になっていた冷蔵庫とおさらばして、おにゅーの冷蔵庫を遂に昨日購入しました。

少し大きめになったんで、わくわくしてます。

もう霜が無駄に付く心配も当面はないだろーう。

なので早速オーブン要らずのデザートが完成してたので味見。

ティラミス。

photo:01



若干牛乳が多すぎた為、べちゃべちゃで失敗やん。

photo:02



更に専用のココアパウダーがない為飲料で使用しているココアの粉末で代用。


でも、まぁまぁだが少し甘すぎた。


y:)

iPhoneからの投稿

mai chirda


今夜は1人銭湯。

銭湯にて風呂上がりにゆったり読書なうです。

完全自分の世界。

悪くないね。

好きな曲聴いて、好きな本読んで、畳に寝そべる。

オヤジやん。

もう少しいよーかな。

photo:01





yoshi:)





iPhoneからの投稿

recipe #2


今日はキムティーが残ってる為、残り物を使ったれしぴー。

走った後の飯、涙が出るほど美味い。。。

まずは、キムチの冷奴胡麻油添え。

photo:01



絹豆富
キムチ
白髪ネギ
胡麻油
煎り胡麻

意外と香ばしい胡麻油とさっぱりした豆富の絡みがかなりマッチしてますぜ。

そして主食は、

韓国風スタミナ丼

photo:02



まず豚肉炒め、味付けにキムチ少量。
そんでドンブリにご飯を盛った上で、グリーンカールを一口サイズにちぎり淵に盛り付け。
炒めた豚肉、キムチを真ん中に盛り付け、更にそのままのキムチを少量のせる。

最後に千切りした白髪ネギ、今回糸唐辛子がない為鷹の爪を適当にまぶし、胡麻油を小さじ分かけておしまい。

グリーンカール
キムチ
白髪ネギ
豚バラ
ご飯
胡麻油
鷹の爪

かなりサクッとできるスタミナ男料理。


冷奴かなりうめぇ。


よ:)




iPhoneからの投稿

chima


うーす。

今日は定時であがれた為、両親が遊びに来てるということで六本木の居酒屋たちに連れて行った。

そのうちの1つ。

わだ家。

photo:01



いーとこだね、オシャレやん。

こじんまりとした隠れ家的個室で津軽弁炸裂。

店員から津軽弁を覚えに来るお店初めてや笑

色々思い出話やら近況についてなど話して、両親も喜んでいるよーで良かった。


オヤジは相変わらずビールオタの為、ピッチャーを特別に用意。

そこだけは似つかなかったなー笑

photo:02




またいつ会えるかわからない、このいっときを大事にしないとな。


いつかだ。

その為のいまだ。



今日も走ろう。

photo:03



終末論神。

iPhoneからの投稿

artee #12


仕事、本日より遂に一大イベントがスタートを切りわふぉーい。

出社前にまた恵比寿行きましたよん。

ベッティナ ランス 写真展
女神たちの楽園
Made In Paradise
セレブたちの美しき幻想と気品

@東京都写真美術館

photo:01



世界中のモデルを被写体にした作品展。
ポージングは多様で、各被写体の内面や心情、人間性を華やかに且つ少し官能的に表現したものだった。

ベッティナ ランスさんはフランスのカメラマンで、パリ国立図書館をはじめパリを中心に活動している方だそー。

特に好きだった作品は、

Vanessa Paradis
Daria Werbowy
She Qi

さん出演のもの。

photo:02




道端ジェシカさんもキレイだなー。



よ:)

iPhoneからの投稿

oracle #3

ぐっどいぶにんぐ。

風呂上がりに足を布団に潜り込ませるあの瞬間。

ヤバイよね?


前回に続き、indexについて。

今日は少し遅めなので短めに書きます、ご了承下さい。

そもそも、索引って使われてるのか?という確認はどーするのか、というところに着目します。

不要な索引のチェックですね。

これは下記手順で実現できます。

1.索引の使用状況を監視する設定を有効化する

コマンド
alter index index_name monitoring usage;

2.一定期間アプリケーションを動作させる。

3.v$object_usageビューで索引の使用状況を確認する。

コマンド
select index_name, table_name, monitoring, used, start_monitoring, end_monitoring from v$object_usage;

monitoring:監視されているかどうか
used:監視中に索引が使用されたかどうか

このような結果を踏まえ、不要な索引があると判断した場合は削除するなりなんなりと対策への第一歩を踏むことができるでしょー。

索引についてはひとまずここまで。

photo:01




先日自宅付近のBARで惚れたワインの一種オロロッソを嗜んでグナーイ。

では。


よ:)

iPhoneからの投稿

artee #11


怒濤のミーティングラッシュなうです。


先日恵比寿に友人と行ってきました。

渋谷慶一郎
「音楽の公開制作'MASSIVE LIFE FLOW'」
@gallery KoKo

photo:01



渋谷慶一郎さんはピアニストで、所謂音楽家。

そんな彼がある期間当galleryで音楽制作を公開で手掛けるという面白い企画だった。

このgalleryはちょくちょく行かせて頂いているのですが、内装は白を基調としてレトロなマンションに少し手を加えたようなとても好みなデザインとなっています。

当日はエレピやミキサーと沢山の機器が揃っていましたが、グランドピアノ演奏しか観れなく少し残念。


改めて鍵盤できる人ってすげぇと思いましたよん。

photo:02




いろはすみかんおいしい。


では。


よー:)


iPhoneからの投稿q

oracle #2


こんばん。

休憩のカルピスしみーる。

最近プライベートでも時間の管理がスムーズに進んだりと良い傾向かなと思ってます。

ただ時間がほしー!な毎日ですが。
気付いたらヨボヨボですね。

さて、今日もoracleについて書きまーす。

前回は索引(index)について、手動でメンテナンスが必要かどうか及びではどのような基準で判断するか紹介しました。

今回は早速手動メンテナンスが必要となった場合どーするかを紹介します。

メンテナンス手法は2つあります。

1つ目が索引の再構築。

これは、テーブルのデータを元にゼロから新たに索引を作成し直すことで削除済みエントリによる無駄な領域確保をクリーンにする効果があります。

※注意点
索引を再構築という事で、一度使用している索引を作成するので一時的に2つ分のディスク領域が必要になります。

コマンド
alter index index_name rebuild;

オンラインで実行する場合
alter index index_name rebuild online;


2つ目は、索引のコアレス。

前回紹介した索引の探索方法、Btree方式での隣り合ったリーフブロックを結合し、削除済みエントリが占有している領域を解放する方法です。

コマンド
alter index index_name coalesce;

これらの処理を実行することで、検索のパフォーマンスは格段に上がるでしょー。

おさらいですが、そもそも索引てどんな時に使用するかというと、oracleにはたくさんのテーブルがありユーザが欲しいデータを引っ張ってくる際に様々なテーブルを結合したり照らし合わせたりと1つ1つ検索をかけるのです。

その際に不要なオブジェクトまでも検索をしてしまわないよう対策をとるのが今回紹介した処理なのです。

自分もまだあまりイメージがわかないですが、図にしてみると分かりやすいのではないでしょうか?

yoshi:)




iPhoneからの投稿