[JDev] Maven Integration with JDeveloper 11g (11.1.2.0.0)

JDeveloper 11gR2 (11.1.2.0.0) から、Apache Maven 2.0との連携が可能になりました。設定方法などを説明した資料をOTNにUpしました。

Working With Maven Projects In Oracle JDeveloper 11g
http://www.oracle.com/technetwork/developer-tools/jdev/maven11g-090173.html

また、MavenプロジェクトをJDeveloperで作成する方法や、Mavenプロジェクトをインポートする方法を説明した、簡単なビューレットを作成しました。



原文はこちら。
http://blogs.oracle.com/dana/entry/maven_integration_with_jdeveloper_11g
- 0 件のコメント:
カテゴリ

[Data Integration] Zero Downtime Migration to Oracle Exadata with Oracle GoldenGate

企業が性能、拡張性および柔軟性をより一層求めるため、システムの更新、移行、統合、管理運用は今日のIT環境ではよくあることです。こうした活動は通常「計画停止」を必要としますが、世界で使われていたり、24時間×7日間の可用性を求められるシステムにおいては、計画停止さえもビジネスに混乱をもたらすことがあります。

最近、データベースをExadataに統合したいというお客様が多くなっています。こうしたプロジェクトが始まると、収益や生産性、顧客満足に影響を与えるビジネスクリティカルなシステムの可用性を妨げないソリューションをも探してらっしゃいます。Oracle GoldenGateはリアルタイム、異種環境でのデータレプリケーションが可能で、こういった移行や統合のプロジェクトでは非常に重宝します。例えばDB2やSQL Server、昔のOracle Databaseといった古い環境と新しいExadataをリアルタイムで同期します。新環境を準備してテストしている間に、Oracle GoldenGateは新しいトランザクションを本番環境からすべて収集し、準備ができ次第Oracle Exadataに転送するのです。システムの同期が完了したら、アプリケーションや利用者はダウンタイムなしですぐにExadataを利用することができるのです。

Oracle GoldenGateをExadataへの移行のために選択された、GSI Commerce Inc.のグループ企業であるe-Dialogというお客様をご紹介します。このお客様は世界に向けて統合デジタルマーケティングソリューションを提供されています。マルチチャネル・マーケティングやキャンペーン分析サービスで扱っているメッセージ量は急速に増加しはじめたので、より高性能を求めてExadataに移行することに決定されました。それと同時に、移行中でもビジネスを継続できるようにするため、Oracle GoldenGateを使って半年をかけて段階的に移行を完了させました。Oracle GoldenGateの双方向レプリケーション機能により、e-Dialogは既存システムとExadataをともに実行させることができました。e-Dialogの成功事例をご覧いただいて、Oracle GoldenGateを使ってOracle Exadataへの移行を成功させる方法を知って頂ければと思います。

e-Dialog Ensures Business Continuity with Virtually No System Downtime During Infrastructure Migration
http://www.oracle.com/us/corporate/customers/customersearch/e-dialog-1-goldengate-ss-405432.html

［参考URL］
Oracle Exadata Database Machine
http://www.oracle.com/us/products/database/database-machine/index.html

Oracle Golden Gate
http://www.oracle.com/us/products/middleware/data-integration/goldengate/index.html

e-Dialog
http://www.e-dialog.com/


原文はこちら。
http://blogs.oracle.com/dataintegration/entry/zero_downtime_migration_to_oracle
- 0 件のコメント:
カテゴリ ,

[Identity Management] ODSEE 11.1.1.5.0 released

Oracle Directory Server Enterprise Edition 11gR1 PS1(11.1.1.5.0) がリリースされ、ダウンロード可能になりました。これは旧Sunのバージョンでいうところの7.1です。

Oracle Identity Management 11g Download

ご質問などはOTNの専用フォーラムでどうぞ。

Forum: Oracle Directory Server Enterprise Edition/Sun DSEE


原文はこちら。
http://blogs.oracle.com/sduloutr/entry/odsee_11_1_1_5



- 0 件のコメント:
カテゴリ

[Java] Java SE 6 Update 26 is released!

Java SE 6 Update 26がリリースされました。以下のURLからダウンロードできます。

Java SE Downloads
http://www.oracle.com/technetwork/java/javase/downloads/index.html

このリリースにはセキュリティの改善と不具合修正を含みます。詳細はリリースノートをご確認ください。

Update Release Notes
http://www.oracle.com/technetwork/java/javase/6u26releasenotes-401875.html


原文はこちら。
http://blogs.oracle.com/javase/entry/java_se_6_update_26
- 0 件のコメント:
カテゴリ

[Hardware, Database] SPARC Enterprise M8000 with Oracle 11g Beats IBM POWER7 on TPC-H @1000GB Benchmark

OracleのSPARC Enterprise M8000は、SPARC64 VII+プロセッサ、Sun Storage F5100 フラッシュアレイストレージ、Oracle Solaris、Oracle Database 11g Release 2という構成で、TPC-Hのベンチマークで 209,533 QphH@1000GB、価格性能比で$10.13/QphH@1000GB という数値を出しました。これは、1 TB TPC-H意思決定支援のベンチマークにおけるIBM POWER7サーバの性能を上回る性能をOracle SPARCサーバが出したことになります。
Oracleはハードウェアとソフトウェアスタックの統合による性能に焦点を当てています。実装の詳細（コア数やスレッド数など）はシステム性能の重要なメトリックを曖昧にしてしまいますが、SPARC VII+ プロセッサはPOWER7プロセッサよりも低速であっても、SPARC Enterprise M8000サーバはIBM Power 780よりも高性能なのです。
  • SPARC Enterprise M8000はIBM Power 780よりも27%高速である。IBMの評判高いシングルスレッドでの性能の良さがスループットに現れていない。
  • OracleはIBM Powerを性能で上回っている。これは、IBMの着目するコア単位の性能よりも、Oracleが着目した統合システム設計のほうが、よりお客様に対する価値を提供することを意味する。
  • リフレッシュ機能において、SPARC Enterprise M8000はIBM Power 780より3.8高速である。 これも、IBMの評判高いシングルスレッドでの性能の良さがこの重要な機能に貢献していない。
  • SPARC Enterprise M8000はHP Superdome 2 (1.73 GHz Itanium 9350)より49%高速である。
  • SPARC Enterprise M8000はHP Superdome 2 (1.73 GHz Itanium 9350)よりも価格性能比で16％上回っている。
  • SPARC Enterprise M8000 serverはリフレッシュ機能においてHP Superdome 2 (1.73 GHz Itanium 9350) より2倍速い。
  • Oracleはストレージ冗長性レベル3を使った。これはTPC-H 2.14.0仕様で定義されており、最高レベルである。
  • サーバ実装の詳細（コア数やスレッド数など）はシステム性能の重要なメトリックを曖昧にしてしまうため、完全なハードウェアとソフトウェアスタックの性能に着目すべきである。
  • このTPC-Hの結果はSPARC Enterprise M8000がDSSシステム（意思決定支援システム）が必要とする大きなデータベースを扱うことができることを示している。CPUの負荷が高い状態のOracle Database 11gR2であっても、16GB/secを上回るI/Oスループットを得た。
性能比較表
Oracle、HP、IBMから販売されている、比較可能なエンタープライズクラスのシステムの公開されている結果をまとめました。各システムのRAMは512GBです。
TPC-H @1000GB
System
CPU type
Proc/Core/Thread		 Composite
(QphH)		 $/perf
($/QphH)		 Power
(QppH)		 Throughput
(QthH)		 DB Available
SPARC Enterprise M8000
3 GHz SPARC64 VII+
16 / 64 / 128		 209,533.6 $10.13 177,845.9 246,867.2 Oracle 11g 09/22/11
IBM Power 780
4.14 GHz POWER7
8 / 32 / 128		 164,747.2 $6.85 170,206.4 159,463.1 Sybase 03/31/11
HP SuperDome 2
1.73 GHz Intel Itanium 9350
16 / 64 / 64		 140,181.1 $12.15 185,297.7 142,601.7 Oracle 11g 10/20/10
［凡例］
QphH = ハードウェアとソフトウェアを組み合わせたシステム全体のTPC-Hパフォーマンス（値が大きいほどよい）
$/QphH = ハードウェアとソフトウェアを組み合わせたシステム全体の価格対性能比（小さいほどよい）
QppH = システムパワー
QthH = スループット
完全なベンチマーク結果はTPCベンチマークのウェブサイトにUpされています。
http://www.tpc.org

構成の概要と結果
サーバ:
SPARC Enterprise M8000
16 x SPARC64 VII+ 3.0 GHz プロセッサ (64コア, 128スレッド)
512 GB RAM
12 x internal SAS (12 x 300 GB) ディスクドライブ外部ストレージ:
4 x Sun Storage F5100 Flash Array device, each with
80 x 24 GB Flash Modules

ソフトウェア:
Oracle Solaris 10 8/11
Oracle Database 11g Release 2 Enterprise Edition

監査結果:
Database Size: 1000 GB (Scale Factor 3000)
TPC-H Composite: 209,533.6 QphH@1000GB
Price/performance: $10.13/QphH@1000GB
Available: 09/22/2011
Total 3 year Cost: $2,122,555
TPC-H Power: 177,845.9
TPC-H Throughput: 246,867.2
Database Load Time: 1:27:12

ベンチマークについて
TPC-Hベンチマークは、データウェアハウスや意思決定支援システムの実証のためにTPC（Transaction Processing Council）が定めた性能ベンチマークです。TPC-Hの測定結果はお客様がいくつかの意思決定支援システムの性能を評価するために用意されています。管理された条件下にある標準的なデータベースにてベンチマーク用のクエリおよび更新処理を実行します。異なるTPC-Hデータベースサイズ（100GB、300GB、1000GB、3000GB、10000GB）の性能予測および性能比較はTPCが許可しておりません。TPC-Hは、データウェアハウス向けで、業界特化していない汎用的なベンチマークであり、これは意思決定アプリケーションではよくある大量の複雑なクエリで構成されています。これには、データウェアハ ウスからのデータロードやパージを模するため、insert、deleteの操作も含みます。TPC-Hでは、特定のコンピュータシステム上の特定のデータベース管理システムというように、ハードウェアとソフトウェアを組み合わせて性能を測定します。
TPC-Hで報告される主要な性能指標は、TPC-H Composite Query-per-Hour Performance Metric (QphH@SF、SFとはRAWデータのGBの数で、スケールファクタと呼ばれる)と呼ばれます。QphH@SFは、単一ユーザ、複数ユーザの両モードでクエリを処理するシステムの性能を簡単に表現することを意図しています。ベンチマークには価格性能比（price/performance）のレポートが必要です。この値は、QphHをハードウェア、ソフトウェア、そして3年間分の保守費用の合計で割った値です。

キーポイントとベストプラクティス
  • 4個のSun Storage F5100 フラッシュアレイデバイスをベンチマークで使いました。F5100デバイスにはそれぞれ80個のフラッシュモジュール（FMODs) が入っています。各F5100から20個のFMODが一つのSAS 6GB HBAにつながっています。一つのF5100デバイスはシーケンシャルリードで4.16 GB/secの性能を示し、4個のF5100を使うと、16.62GB/secとリニアにスケールすることがわかりました。
  • Oracle Databaseの秒間スループットは16GB/secでした。
  • Oracle Solaris 10 8/11はほとんどチューニングしていません。
  • SPARC Enterprise M8000とOracle Solarisは、1000件以上のOracleのパラレルプロセスのシステム負荷を効率的に管理しました。
  • Oracle databaseのファイルはSolaris Volume Manager (SVM) でミラーリングされていました。2個のF5100アレイが別の2個のF5100アレイにミラーリングされていました。IO性能もよく、すべてのFMODに負荷分散されていました。 SVMミラーのおかげで、耐久性試験の一つであるディスク/コントローラ障害テストはOracle Databaseに対して透過的でした。
参考URL
開示説明書

SPARC Enterprise M8000 209,533.6 QphH@1000GB, $10.13/QphH@1000GB, avail 09/22/11, IBM Power 780 QphH@1000GB, 164,747.2 QphH@1000GB, $6.85/QphH@1000GB, avail 03/31/11, HP Integrity Superdome 2 140,181.1 QphH@1000GB, $12.15/QphH@1000GB avail 10/20/10, TPC-H, QphH, $/QphH tm of Transaction Processing Performance Council (TPC). 詳細は www.tpc.org でどうぞ。


原文はこちら。
http://blogs.oracle.com/BestPerf/entry/20110603_m8000_tpch_h_1000gb
- 0 件のコメント:
カテゴリ , ,

[SOA] Solving EAI with SOA Suite

ITに携わってきた人間は、新しい考え方で同じ問題を解決する傾向があります。EAI関連の盛り上がりと、7、8年前の、非常に複雑なシステム連携の問題を解決するためのプロジェクトを思い出しました。
そのプロジェクトで解決しようとしたことは以下のようなことでした。
  • システム間連携のインターフェースの標準化
  • プロトコル変換
  • ソース・ターゲットシステム間でのデータマッピング
  • 補償ロジックによるトランザクションの整合性
EAIは非常に複雑なソリューションでした。このソリューションは不安定なだけでなく、プロプライエタリの技術に立脚しているためコストがかかってしまいましたが、仕事としてやってきました。
EAIのパターンは以下のようです。
  1. ハブ&スポーク(Hub-and-Spoke)一つのビジネスシステム(Hub)を使う親会社や持ち株会社のような考え方。このシステムはビジネスユニットが使うシステムと連携されている
  2. バス(Bus)メッセージバスは以下のものを組み合わせたもの
    • 共通データモデル
    • 共通コマンドセット
    • 異種システムが共通インターフェースを介して通信することのできるメッセージング基盤
しかし、以下のような欠点があると結論づけました。
  • 特に中小企業(SMBs)にとって初期投資のコストが高い。
  • かなりの先行事業設計が必要だが、多くの管理者にとって想像できないものであり、投資をためらうものである。
  • ほとんどのEAIプロジェクトはポイント・ツー・ポイント(P2P)連携からスタートすることが通常だが、アプリケーションが増えると早晩管理不能になる。
  • P2P連携で密結合しているために維持管理が高コストで時間がかかる
  • プロプライエタリな統合ブローカー実装を進化させるためのサービス料（つまり標準技術ではない、ということ）
  • プロプライエタリなインターフェースを用いた静的なデータ統合はWebに展開することが難しい
SOAの登場により、ITの課題だけでなく、ビジネス上の課題として連携を見るという新しい考え方に進化しました。このビジネスメリットを第一に考えることにより、我々はビジネスに不可欠なシステム間の連携にプライオリティを置くことができました。そこで、システム間のポイント統合ではなく、再利用やサービス化を通してビジネス機能を組み立てることに着目しました。
最近、古いEAIベースのハブ・スポーク型EAIからSOA Suiteへの移行プロジェクトに参加していました。明らかになったのは、我々の使命がプロプライエタリなEAIシステムからSOA Suiteへ完全移行することであったとしても、SOAの原則とSOAベースのツールを使えば非常に複雑なソリューションを簡単にできるということでした。
15のシステム間を200本の連携があったものをSOA Suiteに移行する必要があったのですが、要件をシステムの振る舞いから抽出する一方で、分析フェーズにて2つの原則から浮かび上がった個別の連携パターンを見つけました。
  1. 使用しているプロトコルとメッセージタイプ
  2. ソース－ターゲット間でマッピングするシステムのデータ構造
4個のハイレベルコンポーネントを使って、一つの連携パターンを作成しました。
このパターンでは、ソリューションの核となる4個の再利用可能なサービスに着目しました。
  • Inbound Reader Service: このサービスは要求されているメッセージプロトコルやメッセージタイプを使ったインバウンドメッセージを受け付ける。Oracle Service bus (OSB) はこのようなサービスを実装するには最良。OSBがこういうサービスを実装する上では最良であり、プロキシサービスの形で多くのプロトコル間で入力を読み取るよう構成することができる。
  • Structural Validator Service: メッセージが構造的に問題がないかを検証するサービス。これはメッセージプロセッササービスが有効なメッセージだけを処理することを保証する。スキーマの検証やファイル構造の検証などが該当する。
  • Message processor Service: オーケストレーションをベースにした、業務の妥当性と変換を実施する詳細のビジネスロジックを提供するサービス。SCAベースのSOA Suiteを使ってBPELで実装する。このプロセスを作成するためには、一般的なBPEL XPath関数を使って動的変換を実現する。
  • Message Publisher: 動的なコンテンツベースルーティングを使ってメッセージをターゲットシステムに配信するサービス。SCA (Mediator)もしくはOSBを使う。
SOA Suiteベースで提案したソリューションにより、EAIプロジェクトに要したトータルの費用の一部でEAIを置き換えることができ、かつハブ・スポークパターンのエッセンスは維持することができたのです。


原文はこちら。
- 0 件のコメント:
カテゴリ

[WLS] Using the Dashboard to Isolate Poor Performance to the Back End

WebLogic診断ダッシュボード(WebLogic Diagnostics Dashboard)はWebLogic Serverに組み込まれていますが、11gR1PS2 (10.3.3)で刷新され、高速・軽量で、以前のものよりもインタラクティブになっており、グラフィカルなビューで現在何が起きているのかを手早く知ることができます。コンソールにログインすると、右下の「Charts and Graphs」に「Monitoring Dashboard」へのリンクがありますので、クリックしてみてください。

問題の本質にたどりつくため、サーブレットの応答時間と、システムスレッドプールに関連するメトリックとオープンしている接続の件数の相関関係に注目することにしました。そこで、新しいビューを「ユーザービュー」の下に作成し、「メトリック・ブラウザ」を使えるようにしました。まずは、調査対象のサーバインスタンスを選択し、「実行」ボタンをクリックします。すると３個のリンクと、その左側にコンテキストによって変化する選択ボタンが現れるので、タイプ、インスタンス、特定のメトリックを選択し、そのメトリックを右側のスペースにドラッグアンドドロップすると、新しいグラフができあがります。その他のメトリックについても同様に実施します。ビルトインの尺度法がない場合でも、簡単に構成することができます。間違えた場合や、値が変化して作成したマッピングでは意味をなさないような場合でもドラッグアンドドロップで元に戻すことができますし、問題のメトリックを単にドラッグして新しいグラフや別のグラフを作成することもできます。個々のグラフをそれぞれ個別に計測期間を長くしたり短くしたりすることもできます。最後に左側のスタートボタンを押すと、計測を開始します。

このビューから、高負荷であっても正常に稼働していることをすぐに確認できるようになりました。負荷発生ツールからの平均接続件数および応答時間は一定でした。
 WebLogic Serverスレッドプールランタイムの統計情報を使うと、サーバでの処理に関して別の見方ができます。
  • サーバは負荷に対応するためにどれぐらいの個数のスレッドを作成しているか
  • どれぐらいの負荷度合か
  • アイドルスレッドおよびその他のスレッドをセルフチューニングでどれぐらい使っているか
セルフチューニングスレッドプールはサーバに組み込まれているものですが、これが待ち状態の処理件数と各スレッドが処理完了速度を定常的に監視し、チェックしています。この情報を使ってスレッドを追加すべきか待ち行列に入れるかを決めます。この説明は以下のエントリに詳しいです。

Threads Constraints in Work Managers
https://blogs.oracle.com/WebLogicServer/entry/threads_constraints_in_work_ma

"Hogging Threads"というものがあります。”Hogger”とは処理に長時間要しているスレッドのことですが、処理終了に4秒以上かかっているHogging Threadsを調査し始めました。ほとんどのアプリケーションでは4秒が生存期間で、例外は出なかったのです。hogging threadsの個数をサンプリングすれば、バックエンドシステムで起こっていることが簡単にわかります。

[訳注] Hogging Threadはあえて日本語にせず、hogging threadとしています。

このグラフのはじめでは、処理の到着を待っているアイドルスレッドが多数あります。3:47から3:49にかけてhogging threadsの個数にスパイクが発生しています。これは何らかの理由で処理に時間がかかっているようです。サーバが新しいスレッドを作成せず、リクエストを待ち行列に入れているので、処理待ちのリクエストの件数が増えていることがわかります。長期にわたってスレッドが必要でないのであれば、たくさんのスレッドをアドホックに作成したくないので、システムは本当に必要になるまでスレッドの作成を抑制しています。
hogging threadが定期的な作業フローを終了できないと想定し始めたので、かなりの数の新しいスレッドが追加されていることが確認できます。最後に、我々はすべてのhog threadが引き戻されていることがわかります。保留中のリクエストはなくなり、即時実行可能な60個の追加された空きスレッドが残っていることがわかります。

同じ時間帯で計測した実行時間のグラフでも同様です。システムの処理が遅くなるにつれてスループットが徐々に小さくなっています。負荷が安定しているにもかかわらず、接続ユーザ数が増加しているのは、処理完了を待っている接続ユーザが増えているためである、ということがわかります。この応答していない特定のサーブレットとの相関も明らかです。この場合、平均レスポンスタイムは通常時のほぼ2倍になります。前のグラフと合わせて見ると、突然スループットが急増して、バックログがなくなったことがわかります。
問題のサーブレットを開発チームとレビューしたところ、レガシーシステムに接続しているUNIXプロセスのプールに直接渡されているといることが問題で、対応策があることがわかりました。EJBやJDBC、JMSなどをアプリケーション内で使用していたため、このサブシステムに関わるメトリックをサンプリングし、問題を特定しようとしました。
このツールの問題点は、作成したビューをインポート／エクスポートする術が現時点では存在しないということです。回避策として、トリッキーではありますが、保存済みのコンソール設定を収集しました。
<Domain_Home>/servers/<管理サーバ名>/data/console/ConsolePreferences.xml に、 カスタムダッシュボードビューの説明も含めて、コンソールに保存したすべての設定が含まれています（このエントリを記載している時点での内容です）。重要な部分は、以下で始まる部分です。
<portlet-preference definitionLabel="dashboard" user="weblogic">
保証はありませんが、管理サーバ停止中に単純にカット＆ペーストしてこの部分をファイルに書き出したところ、グラフがよみがえりました。

今後、WebLogic Diagnosticsを使って、効率的にプロパティのアーカイブを維持し、事象発生後にダッシュボードにログインして同じ情報を見ることができる方法をご案内する予定です。


原文はこちら。
https://blogs.oracle.com/WLSPERFORMANCE/entry/tricks_for_working_with_the
- 0 件のコメント:
カテゴリ
登録: 投稿 (Atom)