findstrコマンドご存知ですか？

Linuxでは、grepコマンドを使えば、あるディレクトリ配下のファイルを文字列検索することができます。

Windowsにも、似たコマンドがあることは、意外と知られていないので、ここで紹介しようと思います。


[元ネタ]findstrで正規表現を検索する
http://www.atmarkit.co.jp/fwin2k/win2ktips/511findstr/findstr.html


基本的な文法としては、こんな感じです。

findstr /S /c:"<検索文字列>" <ファイル正規表現>

このコマンドで、

実行しているパス配下の、
検索文字列を含む、
ファイル正規表現に合致する

ファイルを列挙してくれます。


詳しい使用方法は、ヘルプを見て欲しいところですが、
ファイル正規表現の部分に、ついつい　[*.*]なんてやりがちです。

確かに検索できるのですが、バイナリファイルの中身を見に行こうとするため、
パソコンがビープ音とともに応答不能になることがありますので、注意が必要です。
（実際、やらかしました・・・ビープ音がオフィス中に響き渡るので、恥ずかしいです）


サクラエディタをインストールすれば、grep検索もできるのですが、
運用中のサーバーにソフトをインストールするのは、ご法度なので、
結構重宝してます。

Windows Updateしたら、BOOTMGR is missingに遭遇

今日は、休日出勤でトラブルに見舞われたので、投稿しようと思います。

開発機として使用しているHyper-Vサーバーを、Windows Updateしました。
Window Update後は、再起動を要求されるわけですが、
再起動後の画面には、

BOOTMGR is missing

なる文字が・・・

状況について、以下におさらいします。

• 機体は、DELL PowerEdge R410
• アップデートしたのは、Windows Server 2008 R2（無印） on Hyper-VのホストOS
• BOOTMBRってことは、マスターブートレコードに異常が発生したのか？

Windows Updateでなんでマスターブートレコード(以下MBR)に異常が発生するのか、

いまいち解せないのですが、発生したものはしょうがないので、

何とかします。

ポイントとしては、MBRを何とかすれば治るんじゃないか？　ということ。

同じ現象に陥った方のために、以下にやったことを羅列してみます。

1. Windows Server 2008 R2のディスクをCDブートで起動
2. リカバリモードを呼び出す
3. 自動修復が提案されるので、OKして再起動
4. 治らない
5. Windows Server 2008 R2のディスクをCDブートで起動
6. リカバリモードを呼び出す
7. 自動修復を無視して、コマンドプロンプトを起動する。
8. bootrec /rebuild　を実行して再起動
9. 治らない
10. Windows Server 2008 R2のディスクをCDブートで起動
11. リカバリモードを呼び出す
12. bootrec /bootfix   bootrec /bootmbr を実行して再起動
13. 治らない
14. Windows Server 2008 R2のディスクをCDブートで起動
15. 自動修復が提案されるので、OKして再起動
16. 治った

イマイチ治った理由がよくわからないのですが、

OS起動までこぎつけられました。

これで、一安心・・・とおもいきや、

Hyper-Vゲストが起動できません。

「選択した仮想マシンの起動中にエラーが発生しました。」

だそうで・・・

きっと、ハイパーバイザーが壊れたか、設定がうまく読み込まれていないのではないかと

推測されます。

ただ、ゲストOSのエクスポートが可能だったので、ゲストをすべてエクスポートして、

別のマシンへインポートしたところ、ちゃんと起動してくれました。

やれやれ・・・といったところです。

お約束ですが、断り文句を書いておきます。

同じ症状だとしても、同じ手法で解決できるとは限りません。

「BOOTMGR is missing」が発生する要因は、他にもありますので、

参考になさる場合は、あくまで自己責任でお願いします。

あけましてOracleトラブル

本ブログを御覧の皆様、あけましておめでとうございます。

本年も、きっとトラブルの多き年となるかと思いますが、
何とか乗り越えていきたいと思います。

私の勤めている社長が、

「トラブルをトラブルと捉えるか、糧と捉えるかで大きく違う。
問題を克服することで、大きく成長しよう。」

と、年初の挨拶があったので、今年も、大いにトラブルを解決していこうと思います。
（本当は、トラブルの芽を摘んでいきたい・・・けど、、、）


さて、今年１発目のトラブルは、素敵なOracleのトラブルです。

Oracleの古いバージョンを使い続けなければならないジレンマを抱えている場合、
すでに解決済みにも関わらず、運用の良し悪しで大変な目に合うことが、
多々あることは、言わずもがなといったところでしょう。

ある運用しているサーバー（W2k3 + Ora9iR2）で、あるビューが
突然読めなくなったという問い合わせがありました。
通常の運用には、影響が出ていないのですが、最近拡張したビューがよろしくないとのこと。


サーバーのログを漁ったら、以下のようなエラーが発生してました。

ORA-01114: ファイル201(ブロック番号XXXXXX)への書込みI/Oエラーが発生しました。
ORA-27069: skgfdisp: ファイルの範囲外でI/O処理を試みました。
OSD-04026: 無効なパラメータが渡されました。 (OS 523989)
ORA-01114: ファイル201(ブロック番号XXXXXX)への書込みI/Oエラーが発生しました。
ORA-27069: skgfdisp: ファイルの範囲外でI/O処理を試みました。
OSD-04026: 無効なパラメータが渡されました。 (OS 523989)

ブロック番号云々というエラーから、表領域に何か異常があるのではないかと推測。
ただ、メインの表領域がおかしくなっている場合は、インスタンスがAbortされるはずなので、
テンポラリ表領域が怪しいと考えました。

ひとまず、テンポラリ表領域を追加して様子を見たところ、状況は改善せず。
再起動の許可が降りた段階で、Oracleを再起動しました。

稼働が確認できたので、ゆっくり状況を確認していくと、
テンポラリ表領域が4GBを超えて、作成されていました。
そんなに激しいソートでもかましているのかと邪推しつつ、テンポラリ表領域を作り直し、
自動拡張をOFFにして様子を見ることにしました。


自動拡張が悪いとは、あまり言いたくないのですが、初期構築の前提条件を
根本から見なおす必要があるような気がした、新年の幕開けでした。

ちなみに、4GBを超える表領域を作成すると、表領域が壊れることがあるのは、
Oracle 9i(9.2.0.1.0?)のバグらしいです。
バグとはいえ、自動拡張を安易に信じるのは、やめようと思いました。