OracleとEBSとSiebelと駄文と。

Oracle製品ファンとして、見たこと聞いたこと調べたことを綴っています。

IE10でもEBSが使えるようになりました

EBS

※本記事はInternet Explorer 10 Certified with Oracle E-Business Suiteの紹介です。

  • OSはwin7だとか
  • R12の場合Compatibility Mode にするとか
  • JREは
    32bitの場合1.6.0_03 (32-bit) 以上もしくは1.7.0_10 (32-bit) 以上
    64bitの場合1.6.0_32 (64-bit) 以上もしくは 1.7.0_10 (64-bit) 以上だとか

各種制限はありますが、IE10がCertifyされたようです。詳細は元記事参照。

と書いている私はfirefox派だったりします。

Oracleの研修・試験料が2013/10/1から値上げ

認定試験/資格

だそうですよ奥様。
http://www.oracle.com/jp/education/news/price-revision201310.html

Oracle MasterもApplicationsも、22,260円→27,930円、って25%以上も値上げですよ？これはいろいろとイタイ。直近受験を考えている人は９月までに受験チケットを購入してもよいかもしれないですね。研修を受講するなら、できれば９月までに。

EBS５つのミス6/5：運用編

※本記事はTop Five Errors Customers Make When Maintaining E-Business Suite 12 (Part 6) の紹介です。

エントリが６つだと後でわかったから、開き直りの6/5番目エントリ。以下、内容の私なりの解釈です。正確な情報は上記リンクから元記事を読んでくださいませ。

  1. AutoConfigで更新されるファイルを手動で更新する。
    ->Autoconfigで上書きされるから、カスタマイズはAutoConfig Noteのセクション４に従って。
  2. Shared APPL_TOPを使わずに複数のAP層を別々にメンテナンスする。
    ->たとえば、webノード４つがLinuxで、コンカレント＋RACのノード４つSolarisにあったらパッチは８回適用しなきゃなんなくてダルい。コンカレントノードをLinuxに持っていって、Shared APPL_TOPすればパッチ適用は１回になる。
  3. 初期化パラメータファイルの値を最大値にする。
    ->危険。OEMや他のパフォーマンス調査ツールを使って設定値を決めましょう。本番化前にパフォーマンステストを行うことも忘れずに。
  4. 使ってないモジュールのinvalid objectは無視。
    ->使ってなくても、DBには登録されてます。障害の元になるから、invalid objectは調査し解消すべき。
  5. パフォーマンスを向上させるため、export/importを使う。
    ->export/importでパフォーマンス向上するかもしれないけど、indexの調査や非効率なSQLを調査すべき。fragment化＝パフォーマンス劣化、ではない。

パフォーマンスが問題ならこちらもどうぞ：Debugging General Performance Issues with Oracle Apps

EBS５つのミス5/5：アップグレード編

※本記事はFive Errors Customers Make When Upgrading E-Business Suite 12 (Part 5) の紹介です。

べからず集のアップグレード編。以下、内容の私なりの解釈です。正確な情報は上記リンクから元記事を読んでくださいませ。

  1. DBUAはEBSのデータベースアップグレードには役立たない。
    ->ちゃんと使えます。マニュアルでのアップグレードを好む技術者もいるけど。DBUAでできないからマニュアルでアップグレードしなきゃいけないことがあったらSRあげてください。
  2. 本番アップグレード前に1回テストすれば十分。
    ->本番前に最低３回はテストして成功させること推奨。
  3. EBSに特化した資料じゃなくて、一般的な資料を使う。
    ->たとえばDBに関しても、通常のDBアップグレード資料を参照するだけじゃなくてEBSのテクノロジースタックの資料を見ましょう。
  4. 新モジュールを使う予定が無いので、Release Update Packs（RUPs）に含まれる新モジュールをスキップする。
    ->RUPsに含まれるモジュールをインストールするよう指示されたら追加してください。でないと将来のパッチ適用でエラーの原因になることがあります。
  5. 別のEBS環境から、ファイルを手動でコピーする。
    ->後でパッチ適用時にトラブルになるから、ファイルの変更はパッチか資料で指示された方法・内容で行ってください。

EBS５つのミス4/5：移行編

※本記事はFive Errors Customers Make When Migrating E-Business Suite 12 (Part 4)の紹介です。

あ、そうなんだ？そんなん考えたことも無かった、が（個人的に）多い移行編。以下、内容の私なりの解釈です。正確な情報は上記リンクから元記事を読んでくださいませ。

  1. 9iからデータをexportして、10gや11gにimportする。
    ->10g以降のdatabaseにはdatapumpを使いましょう。さらに、関連するNoteをちゃんと読みましょう。10gや11gにデータをimportする場合のデータ移行元は10g以降である必要があります。
  2. Linux x86_64は11iのAP層のOSとして認定されている。
    ->認定されてません。11iならDB層のみ、R12ならAP層・DB層どちらでもOK。
  3. 新しいプラットフォームに移行するため、新環境でFresh Installし、データはexport/importで移行する。
    ->Rapidwizじゃなくて移行ツールを使いましょう。Note.438086.1あたり参照。
  4. 11iのAP層にExalogicを使う。
    ->Exalogicは11iのAP層には使えません。R12のAP層ならOK。DB層にExadataを使うのは、11iでもR12でもOK。
  5. テクノロジースタックのインストールやアップグレードを行うのに、全インストールメディアが必要。
    ->必要な部分だけでOKです。

EBS５つのミス3/5：パッチ編

※本記事はFive Errors Customers Make When Patching E-Business Suite 12 (Part 3)の紹介です。

これも、ミス、というより誤解ですね。ぐさぐさ刺さりすぎて私のライフはもう・・・。以下、内容の私なりの解釈です。正確な情報は上記リンクから元記事を読んでくださいませ。

  1. パッチは全てhotpatch*1、 nocheckfileで実行できる。
    ->パッチは緊急の場合AP層を止めずに適用できるとPAAでガイドされてない限り、メンテナンスモードにして適用しましょう。nocheckfileはパッチ適用時間を大幅に短縮しますが、nocheckfileを指定していいケースはレアです
  2. パッチは手動で（＝ファイルを個別に置き換える）適用できるし、手動じゃなくても適用できる。
    ->adpatchではなく、個別にファイルを置き換える方法はサポートされません。パッチ適用前に戻す単純な方法はありません。*2
  3. パッチのワーカー数を増やせば、パッチ適用時間は短くなる。
    ->ワーカー数のデフォルトが最適ではないケースがあるのも事実。デフォルト数での実行時間をベンチマークとして、ワーカー数を変えて計測し、最適なワーカー数を見つけましょう。パッチ適用中にワーカー数を変更することはできません。
  4. 使ってないモジュールのパッチ適用が失敗したら、スキップする。
    ->使ってようが使ってなかろうが、パッチ適用時のエラーは０を目指すべき。前提条件やパッチ適用の手順も確認して。
  5. パッチ適用時のログはデフォルトのままにする。
    ->パッチ適用のたび、ログは一意にしましょう。例えば<パッチ番号>.logとか。じゃないとサイズが莫大になって後で調査するのが大変。ワーカーログもパッチ適用ごとに変えましょう。

*1:メンテナンスモードにせずにパッチ適用

*2:なので、パッチ適用前に戻したい場合はファイルを個別にバックアップから戻すのではなくて、全体をバックアップから戻せって話ですね

EBS５つのミス2/5：クローン編

EBS

※本記事はFive Errors Customers Make When Cloning E-Business Suite 12 (Part 2)の紹介です。

今回、ミス、というより誤解ですね。書いてて私にぐさぐさ刺さってくる・・・。以下、内容の私なりの解釈です。正確な情報は上記リンクから元記事を読んでくださいませ。

  1. Rapid Cloneは、環境コピーを作る選択肢の一つ。
    ->むしろ唯一の選択肢。Rapid Cloneで不都合があればSRをあげてください。
  2. precloneは、1回実行すればいい。
    ->コピー用にサービスを止める前に、precloneは毎回必ず実行すること。precloneによって更新されるcloneディレクトリは、バックアップをとるのも忘れずに。
  3. 32bitのLinuxから64bitのLinuxに移行するのにRapid Cloneを使う。
    ->Rapid Cloneで32bitOSから64bitOSに乗り換えても、64bitOS上に32bitの環境ができるだけ。こちらも参考にどうぞ。
  4. 同じ場所にclone環境を作っておいて、セントラルインベントリの更新を忘れる。
    ->cloneの際はセントラルインベントリの更新も忘れずに。環境削除の際はセントラルインベントリも削除すること。
  5. clone環境作っても、完全なコピーではない。
    ->ノード名など、ハードウェア由来の部分は違うけど、パッチ履歴等は同じです。



ハード環境違えばバックアップ等の運用系プログラムに影響あったりするから、当然完全コピーじゃないじゃん？とケチつけたくなりますが他は・・・いたたたた。
セントラルインベントリについては、KROWN#14410のグローバルインベントリあたりの記述も参考にどうぞ。