*以下は、サポート契約締結中のお客様に2015年4月号として配信しているサポートレターより一部抜粋して掲載しています。 平成 27 年（2015年）7 月 1 日（水）に 3 年ぶりの実施となる「うるう秒」について、弊社オラクルプロダクトサポートにも Oracle Database, Oracle WebLogic Server, Oracle Business Intelligence への影響のお問合せが増加しております。 そこで今回は、Oracle Database, Oracle WebLogic Server, Oracle Business Intelligence のうるう秒に対する対応についてご案内いたします。 「うるう秒」とは うるう秒は、原子時計と天文時のずれを調整する仕組みで、両者のずれが 0.9 秒以内に保たれる様に実施されます。今回のうるう秒は現在のうるう秒が取り
Tweet 前回紹介した SystemTap は、システムの管理や保守を行う人にとってだけでなく、Linux カーネルの開発やシステムの開発を行う人にとっても有用なツールです。 SystemTap を使うと、任意の箇所に遅延を挿入したり、メモリーの内容を書き換えたりすることもできます。そのため、意図的に競合状態を発生させることで問題事象を再現させたり、意図的にエラー状態を発生させることでトラブルが生じないかどうかを試験したりすることができます。そこで、今回は SystemTap を用いて試験を行った事例について紹介したいと思います。 ここで紹介している内容は、トラブル発生時の対処フローを確認したい場合に試すことができます。例えば、フリーズ事象が発生した場合には、 SysRq キーを使って情報を取得する練習ができます。 また、 KernelOops イベントが発生した場合に備えて、 /pro
Tweet 第1回では、カーネルパニックが発生した場合の情報取得方法として、 kdump を紹介しました。今回は、カーネルパニックまで至らない場合の情報取得方法として、シリアルコンソールを紹介します。 シリアルコンソールとは、カーネルが出力するメッセージを取得するための、比較的信頼できる方法です。 平常時であれば、カーネルが出力したメッセージは syslog デーモンによって /var/log/messages に保存されるようになっています。そのため、カーネルが出力したメッセージを確認したい場合、 /var/log/messages の内容を確認すれば済みます。 では、シリアルコンソールが役に立つのは、どのような場合なのでしょうか？それは、シリアルコンソールと syslog の動作方法の違いが意味を持つ場合です。 syslog デーモンは、カーネルが出力したメッセージを読み出して /va
Tweet カーネルパニックは予期していない時に起こります。それが起こらないように備えることは誰にもできません。だから、「もし自分が管理しているシステムでそれが起こったらどうしよう」と考えてみることには意味があります。 カーネルパニックが起こったとき、あなたが気にするのは、「どうしてだろう？」、でありまた、「どうすれば元のように動作させられるだろう？」のはずです。２つ目の疑問は、多くの場合１つ目の疑問の結果に依存します。つまり、あなたは「どうしてカーネルパニックが発生したか」を調べることになります。それについて、（カーネルが正常に動作している今）できることを考えてみましょう。 カーネルパニックになるということは、「カーネルがパニックした」、すなわち「何が何だかよくわからない」状態になるということですから、それが発生してから論理的な処理はできません（できないからこそパニックしているわけです）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
