（備忘録）Linux 版 VMware Server 2.0 のインストール
会社の仕事で、様々な Windows と office の組み合わせ環境を構築する必要があったので VMware で構築しました。自端末は DELL のしょぼいデスクトップ PC なので沢山の VM を構築するディスクスペースも無ければ、複数動作させるだけの CPU パワーもありません。せっかく自前で用意した VMware Workstation も宝の持ち腐れってもんです。 というわけで、別の用途で使っている開発サーバに VMware Server 2.0 をインストールしてサーバ側で VM を走らせて、自端末から VMware Infrastructure Client 経由で VM を操作することにしました。さすがは Xeon E5450 （3.00GHz）、メモリ 8GB だけあります。物理コア数が４つなので、しょぼい Core2Duo E4600 とはわけが違います。VM がサク
サーバ監視項目でよく使う SNMP の MIB オブジェクト ID まとめ
サーバの監視において SNMP は必須技術なわけですが、MRTG や自前スクリプトは一度設定してしまうと、サーバが増減でもしない限り、設定ファイルを見直すことってほとんどありませんよね。 でもって、久々に改めて設定ファイルを見直してみると、設定してある MIB の OID が意味不明・・・なんだっけコレ？ってことが良くあります。※少なくとも僕の場合は、毎回調べ直してる気がする・・・ なので、よく使う MIB オブジェクト ID をまとめておこう・・・と考えました。これでこれからは迷わない。 ・・・と思ったらエントリを書き始めたらビックリ仰天！SNMP の知識すら忘れてます・・・再度お勉強です・・・ヽ(τωヽ)ﾉ SNMPによるネットワークシステムの監視第01回：第１回：SNMPの基礎 SNMPではマネージャ（NMS：Network Management Station）という管理機器がその
Oracle データベース復旧手順書とフルバックアップスクリプト
最近は業務の関係上、Oracle データベースの復旧手順書を作成していました。 Oracle のエンタープライズ分野の主流は RAC 構成になりますが、小規模システムではまだまだシングルインスタンス構成も多いことかと思います。実際システム構成的にはシングルインスタンスの方が遙かにシンプルで運用も楽です。 業務では RAC 構成のシステムを見ていますが、教育という側面からはシングルインスタンスをまずは教えるのが吉です。また部下に DBA の立場を担って貰うことを考えると、最低限知っておいて欲しいのはバックアップ＆リカバリ。システムダウン時に活躍するスキルを身につけて欲しいと願います。せっかくいろいろ資料を作ってきたので汎用化できる部分のみ公開しようと思います。 バックアップ方式について言えば最近の主流はもちろん Oracle が提供している Recovery Manager を使ったバックア
ドラクエ9が止められない止まらない
噛めば噛むほど味がでてくるドラクエ９が止まりません。 ※注意※ ドラクエ9に興味がない方は読み飛ばしてください。情報量ゼロです。w (*^ーﾟ)b プレイ時間が42時間23分の時点で手元が狂って思わずクリアしてしまいました。ただ単にレベル上げの為だけにラスボスのいるところで戦っていただけなのですが、目の前にいるヤツがどうしても気になって仕方がなくて、叩いてしまいました。 LV４０程度でしたが、結構余裕でした。基本、「おうえん」＋「ためる」を繰り返してハイパーテンション状態で叩いて 1200 前後のダメージを数回与えたら死にました。 今までの経験上、ラスボスを倒してしまうと、あっという間にテンションが下がるのが RPG の悲しいサガ。そういえば、初めて家族の名前を使って RPG やりました。なんだかコレも新鮮です。 でもですね、このドラクエ9は初めてラスボスを倒した後も楽しめています。という
Oracle では FGA 監査を利用している場合は select 文でも REDO ログは生成される
いきなり回答。監査を設定している場合には、当然の事ながら監査ログが出力されます。出力先を OS ではなく Oracle にしている場合、select 文を流すだけでも結果的に REDO ログ（監査ログの insert 分について）、アーカイブログが生成されます。 これ見落としがちですが、かなり注意が必要です。 以下詳細です。結論からすると、上記の前提を単に見落としていただけなのだが、これには正直参った。 Oracle を使う理由のひとつとして監査ログ機能の充実があります。Oracle 9i 以降を業務でお使いの方は、機微な情報を持つテーブルに対しては何かしらの監査を行っていることと思います。 10g では監査の種類として以下のようなものが用意されています。 ※参考ページ Oracle Japan / オラクル通信 / Oracle Database 10g 徹底検証レポート データベース・
Linux/UNIX 上でコマンドの実行履歴を残す方法
最近、セキュリティ関連の話が多いが身の回りで多いのですが、今回は、Linux / UNIX 系で誰がいつどのコマンドを実行したかってのをログにとる方法のお話しです。 「＠IT：止められないUNIXサーバの管理対策 第6回 - Page2」にも参考になるロギングの話が掲載されていますが、実行コマンドのログをとる方法は以下の５つが考えられます。 sudo を使って実行ログをとる .bash_history を定期的にバックアップして実行ログとして保存する script コマンドを使うことで実行ログ（画面出力のコピー）をとる システムアカウンティング機能（psacct）を有効にして実行ログをとる 実行シェルを改造し、ログを保存するようにする 僕が考えつくところで、セキュリティ的に最も強固であるのはシェルの改造と思います。但し、その OS 上で使える Shell をその改造 Shell のみに限定
Perl スクリプトで遅い場所を特定する方法 - Devel::Profiler / Devel::NYTProf
今仕事で書いてる Sledge アプリがあるのですが、先日負荷テストを行った結果びっくりすることに現行アプリの１０倍遅いことが判明してしまいました・・・orz Sledge フレームワーク自身が重くないことは今までの経験でわかってるのですが、どうにもソースを見直しているだけでは原因が特定できない・・・そんな活躍するのがプロファイラです。プロファイラの御陰で遅いヶ所を特定することができ、無事に想定するパフォーマンスを得ることができました。この内容に関してはまた別エントリにて。 さて、プロファイラを使うとプログラム実行時の各種情報を収集し、性能解析を行うことが可能です。プロファイラについてもう少し詳しくしるには 性能解析 - Wikipedia あたりを読むと良いでしょう。 プロファイラ（英: Profiler）は性能解析ツールであり、プログラム実行時の各種情報を収集する。特に、関数呼び出しの
(byte|文字列)計算系のバッチ処理と Inline::C の相性の良さ
どんなシステムにおいてもオンライン系の処理ばかりではなくバッチ処理系のプログラムというものが存在します。僕の場合、ユーザに見えない部分のプログラムが全体の７０％を占めているかもしれません。 バッチ処理は大量のデータを処理する場合が多いのが特徴のうちのひとつ。しかもその処理が想定時間内に終わらないと、どこぞのシステムのようにシステム全体に影響が出てしまいシステムダウンなんて最悪の状態になることもあります。あれに起因してバッチの突き抜けなんて効いたこともない言葉が生み出されたくらいだし。ｗ さて話を戻して、システムを運用しているとデータ量は当然右肩上がりで増えていきます。よってバッチ処理も当時の想定よりも時間がかかるようになってくるわけです。 僕が作ってるバッチ処理の多くは文字列処理や計算処理が多いです。オンライン系の言語と同じく perl で記述しているものが非常に多いわけですが、Devel
Linux 備忘録 ： Ext3 のジャーナルファイルの再作成の方法
1. まず始めに Ext3 上でファイルシステムの破損状況を調査する umount /dev/hda1 e2fsck -fn /dev/hda1 正常時 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/hda1: 150/4308992 files (10.7% non-contiguous), 3486771/8614848 blocks Parallelizing fsck version 1.20-WIP (17-Jan-2001)
strawberry perl に DB_File モジュールをインストールする方法
会社のえろい人に Windows で ActivePerl 使っている時点で負け。Strawberry Perl にスイッチしろって言われてから Strawberry Perl を愛用しています。Windows なのに ppm じゃなくて cpan 使ってモジュールを管理できるのがすごく自然な感じです。 もう ActivePerl には戻れません。 なんと言っても gcc 環境がくっついてくるので XS 系のモジュールもコンパイルできちゃうのが素晴らしいです。nmake.exe をダウンロードしてきて、あーだこーだとコンパイルできなくて悩まなくてすみます。コンパイルに失敗してもコマンドプロンプトを立ち上げて、いつものように、ちょこちょこっといじって手動でインストールを続行したりもできます。 がっ！・・・DB_File がなんだかうまく入らないことに気がつきました。ちょこちょこっとぐぐったら
Linux チューニング - Ext3 のパフォーマンスを最大化させる
じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで
perl で Captcha 認証（セキュリティ画像）をやる方法について
ユーザ登録とかでロボット等でのスパム登録を防止したりって用途に使われているアレです。こんなヤツ。 最近はブログのコメントとかのスパム防止でもよく見かけます。まずは基礎知識。このような画像で認証を行うことを Captcha っていいます。wikipedia の情報を引用すると、 CAPTCHA（キャプチャ、"Completely Automated Public Turing test to tell Computers and Humans Apart"; コンピュータと人間を区別する完全に自動化された公開チューリングテスト）は チャレンジ/レスポンス型テストの一種で、ユーザが人間であるかどうかを決定する計算処理に使われる。この用語はカーネギーメロン大学のLuis von Ahn、マヌエル・ブラム、Nicholas J. Hopper、IBMのJohn Langfordによって2000年に
Oracle - SQL*Loader のパフォーマンス考察
Oracle で大量の insert を高速に処理する方法の検討 ですでに検証済みですが、Oracle での最速の insert を求めるなら SQL*Loader を使うことです。もちろんテーブルの状態によって計測値はかわりますが、以前の検証結果では SQL*Loader はマルチテーブルインサートよりも６倍ほどはやいという結果でした。 というわけで、オンライン系はともかく、バッチ系の処理での大量 insert 処理に SQL*Loader を使っていなければ、今すぐ SQL*Loader の導入を検討するべきでしょう。 ってことを自分自身わかりつつ、つい最近まで時間がとれていなかったのですが、最近は時間ができたのでバッチ処理の見直しをしているところです。SQL*Load にもいろいろ速度と制約があるので、その辺をまとめていきたいと思います。 SQL*Loader ってなんですか？ って
NFS を使っていて .nfsXXXX みたいなファイルが生成されたときの対処方法
本業で Oracle 10g RAC を使っているのですが共有ディスクには NetApp Filer を使ってます。でもって Filer の接続方法としては DAS/SAN ではなくより簡易な NFS を使ってます。とっても便利な NetApp Filer の snapshot 機能。これを一度使ったらもう他のストレージには戻れません。と言うわけで NetApp Filer お奨めです。NetApp ファイラーを使用した超高速バックアップ＆リカバリ なんかも参考にどうぞ。 ってことを書きたかったわけではなく障害なんてのは予期せず発生するものです。ちょっと前の話ですが、バッチ処理で Oracle のアーカイブログファイルが予想外に大量に生成されてディスクが満杯になってしまいました。でもって障害通知メールでそのことに気がつきあわてて不要なログファイルを削除。 とまぁ通常のディスクならこれで問題
ロードアベレージに関する考察
ここ最近ロードアベレージについて調べています。本業の Oracle サーバのロードアベレージが最近高いのです。本日の夜はまだまだ安定した値。下のグラフは loadavg x 100 のグラフ。 Dual Core Xeon が２枚のサーバなので一般的なロードアベレージの解釈からすると４以下なら安全圏。ここ最近は６〜８という数値が多いわけですが、実際の体感的なパフォーマンスがそれほど悪いるわけではなくと言うか全然重く無くってイマイチ良く判らない。CPU とか他の数値は至って安全圏のものばかり。仕方がないので kernel 2.6 のソースを眺める日々がここ数日。とにかく kernel まわりの記事を手当たり次第読んでみました。 マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー Linux カーネルのコンテキストスイッチ処理を読み解く - naoyaのはてなダイアリー
CPAN の ダウンロード先（URL リスト）を変更する方法
「Sun Fire V20z を Webサーバ用に購入」や「Apache bench 対決 ： Xeon vs Opteron」の記事で書いたように、本業で使っている web サーバは Sun Fire V20z というサーバなんですが、Dell の Xeon サーバとかに比べてベンチマークで比較する数値以上に実務アプリ（Web + DB サーバアプリケーション）の動作がすこぶる機敏です。 ってな訳で、再びサーバ増設で Sun Fire V20z を購入してインストール作業をしているのですが、CPAN のインストールで苦戦中。どうも CPAN サーバによって MD5 - checksums で転けてしまうんです。具体的には、
mod_gzip で Vary: * を send すると IE で SSL の挙動が変になる
まず結論から。タイトル通り mod_gzip で Vary: * が http-header として送信されると SSL 通信中の場合に限って IE(Internet Explorer) は Cache-Control とかの内容に関わらずコンテンツをキャッシュしないようです（※特に IE7 全般と IE6 特定の version が変）。本来 Vary ヘッダは proxy の挙動を決定するためのヘッダのはずなのに IE(Internet Explorer) は Vary ヘッダの内容によって挙動が変わってしまうようです。 別の言い方をすると、SSL なページでブラウザの戻るボタン押したときに「ページを表示できません」(※ie6)とか「Webページの有効期限が切れています」(※ie7)とか表示されてしまう場合は proxy を使っていて Vary: * が send されているのが原因と
Oracle で大量の insert を高速に処理する方法の検討
久々に Oracle ネタです。以前 セッション管理に向いているデータベースは MySQL ? Oracle ? というエントリを書いたのですが、それとは別に insert の処理をどうしても高速化する必要に迫られました。今回高速化すべき要件として同一テーブルに大量のデータを一気に登録する作業です。いわゆる管理系業務で良くある csv のインポート的な機能に相当します。 さてそのような要件の場合、insert の方法は大きく分けて以下の方法が考えられます。それぞれどんなものかを知りたい方は本エントリー最後の参考を読むと理解できると思います。 アプリ側から csv のデータを読み込んで for 文で件数分ループして insert する マルチテーブルインサート機能を用いて、１つの insert で複数データを一括登録する バルクインサート処理を行う PL/SQL を定義して一括登録する SQ
Google AdSense の広告表示精度を高める方法 :: Drk7jp
セクション ターゲットを使用すると、サイトのコンテンツと広告を照合する場合に、強調または無視すべきテキストや HTML コンテンツのセクションを Google に知らせて、広告表示の精度をより向上させることができます。 セクション ターゲットの実装は、HTML を熟知したお客様にのみお勧めしています。 <!-- google_ad_section_start(weight=) --> 記事のタイトル<$MTEntryTitle$>や記事本文<$MTCommentBody$> <!-- google_ad_section_end --> <!-- google_ad_section_start(weight=ignore) --> バナー広告やリンク集を貼り付けているサイドバーやトップバー部分やコメントやトラックバック部分 <!-- google_ad_section_end --> です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Oracle の各種バージョン毎の接続可否一覧表（support matrix）