Oracle Blogs 日本語のまとめ

Oracle Blogsの主としてテクノロジー製品のエントリを日本語でご紹介します（オリジナルのエントリを投稿することもあります）。厳密性をご所望の方は原文をどうぞ。よい内容でしたら原文に対し、"Good Entry, thanks!"でもいいので、是非コメントお願いします（Typoや誤訳はコメント欄からどうぞ）。なお、このエントリは個人の見解であり、所属する会社の公式見解ではありません。また、エントリ内でご紹介している製品・サービスは国内導入時期が未定の場合もありますのでご了承下さい。

Good entries on Oracle Blogs are put into Japanese. Mainly this blog covers technology products. Opinions expressed in this blog is my personal one and does not represent the official opinion of Oracle Corporation and my employer.

[Java] A quick update on Java EE

原文はこちら。
https://blogs.oracle.com/theaquarium/entry/a_quick_update_on_java

OracleはJavaコミュニティに対し、Managemennt 2.0 (JSR 373) とJMS 2.1 (JSR 368) を取り下げる予定であることをお知らせしています。MVCについては、コミュニティからのフィードバックに対し、MVCを別のコミュニティメンバーもしくはコミュニティを構成する組織に可能な限り任せ、JSR 371をスタンドアロンコンポーネントとして完成してもらうことを目指して現在研究中です。

こうした変更はJavaOne 2016で紹介した改訂版Java EEロードマップと一貫しています。ロードマップでは、OracleはこれらのJSR をJava EEに含めないことを提案していました。詳細はJavaOne 2016基調講演のAnil Gaurのパートと、Linda DeMichielのJava EE 8 Updateのプレゼンテーションをご覧ください。

JavaOne基調講演

Java EE 8 Update

この変更は、OracleがJava EEコミュニティアンケートを受けて、上記テクノロジーの重要度の順位付けを反映したものです。Managemennt、JMS、MVCは調査対象のテクノロジーの中で最下位近辺の順位でした。近いうちにアップデートとして、調査結果の全体像とJava EE 8の次のステップを説明する予定です。

[Database] Enabling ADAPTIVE Features of Oracle 12.2 in 12.1

原文はこちら。
https://blogs.oracle.com/UPGRADE/entry/enabling_adaptive_features_of_oracle

Oracle Database 12.2では、新たな分割されたアダプティブ・パラメータであるOPTIMIZER_ADAPTIVE_FEATURES と OPTIMITER_ADAPTIVE_STATISTICS が導入されます。
詳細は、以下のエントリをご覧ください。

OPTIMIZER_ADAPTIVE_FEATURES obsolete in Oracle 12.2
https://blogs.oracle.com/UPGRADE/entry/optimizer_adaptive_features_obsolete_in
[Database] Optimizer Adaptive Features in the Exadata Express Cloud Service
https://orablogs-jp.blogspot.jp/2016/10/optimizer-adaptive-features-in-exadata.html

Optimizer Adaptive Features in the Exadata Express Cloud Service
https://blogs.oracle.com/optimizer/entry/optimizer_adaptive_features_in_the
[Database] OPTIMIZER_ADAPTIVE_FEATURES obsolete in Oracle 12.2
https://orablogs-jp.blogspot.jp/2016/11/optimizeradaptivefeatures-obsolete-in.html

しかし、オンプレミス版のOracle Database 12.2はまだ出ていません。では、Oracle Database 12.2にアップグレードする際にはどうしたらよいのでしょうか。Oracle Database 12.1のアダプティブ機能をどうすればよいのでしょうか。

Recommendations for Adaptive Features in Oracle Database 12c Release 1 (12.1) (Doc ID 2187449.1)
https://support.oracle.com/rs?type=doc&id=2187449.1

Oracle Database 12.1からアップグレードする際にはOracle Database 12.2のデフォルトを採用することを推奨しています。これは以下の2個のパッチを適用することで実現できます。この方法を推奨アプローチと呼んでいます。

bug# 22652097 に対するパッチ（Patch 22652097: PROVIDE SEPARATE CONTROLS FOR ADAPTIVE PLANS AND ADAPTIVE STATISTICS FEATURES）
OPTIMIZER_ADAPTIVE_PLANSとOPTIMIZER_ADAPTIVE_STATISTICSという2個のパラメータを導入し、OPTIMIZER_ADAPTIVE_FEATURESというパラメータを削除します。
bug# 21171382 に対するパッチ（Patch 21171382: AUTO DOP COMPUTES A HIGH DOP UNNECESSARILY）

AUTO_STATS_EXTENSIONS

ON

パッチ適用時には、以下の操作を実施して、OPTIMIZER_ADAPTIVE_FEATURESがSPFILEから削除されていることを確認してください。

alter system reset optimizer_adaptive_features;

すでにOracle Database 12.1にアップグレードしているけれどもパフォーマンス上の問題が発生している場合には、どちらのパッチも効果があります。
ご注意いただきたいのは、OPTIMIZER_DYNAMIC_SAMPLING をデフォルト値以外に設定することは必ずしも必要ではない、ということです。その理由は、新しい両パラメータをデフォルト設定で利用すると、パッチがアダプティブ動的サンプリング（adaptive dynamic sampling）の利用を無効化し、Oracle Database 12.2のデフォルトの挙動に一致するためです。

[Database] OPTIMIZER_ADAPTIVE_FEATURES obsolete in Oracle 12.2

原文はこちら。
https://blogs.oracle.com/UPGRADE/entry/optimizer_adaptive_features_obsolete_in

Oracle Database 12.1のパラメータである

OPTIMIZER_ADAPTIVE_FEATURESは、Oracle Database 12.2で廃止されました（つまり、アップグレードするとSPFILEから削除されます）。

このパラメータに変わり、2個のパラメータが導入されます。そのうち1個はデフォルトで有効化、他方は無効化されています。

OPTIMIZER_ADAPTIVE_PLANS=TRUE （デフォルト値）
OPTIMITER_ADAPTIVE_STATISTICS=FALSE （デフォルト値）

OptimizerのプロダクトマネージャであるNigel Baylissが既に詳細な説明とともにエントリをアップしています。

Optimizer Adaptive Features in the Exadata Express Cloud Service
https://blogs.oracle.com/optimizer/entry/optimizer_adaptive_features_in_the[Database] Optimizer Adaptive Features in the Exadata Express Cloud Service
https://orablogs-jp.blogspot.jp/2016/10/optimizer-adaptive-features-in-exadata.html

とはいえ、オンプレミス版Oracle Database 12.2はまだ利用できないので、この機能をOracle Database 12,1で取り扱うにはどうすればよいのでしょうか。

詳細は以下のエントリでご紹介します。

Enabling ADAPTIVE Features of Oracle 12.2 in 12.1
https://blogs.oracle.com/UPGRADE/entry/enabling_adaptive_features_of_oracle
[Database] Enabling ADAPTIVE Features of Oracle 12.2 in 12.1
https://orablogs-jp.blogspot.jp/2016/11/enabling-adaptive-features-of-oracle.html

[Databae] New Oracle Optimizer White Paper

原文はこちら。
https://blogs.oracle.com/optimizer/entry/new_oracle_optimizer_white_paper

Oracle Optimizerの新しいホワイトペーパーがご覧いただけるようになりました。以下のリンクから、Optimizer with Oracle Database 12cをクリックしてダウンロードしてください。

Query Optimization - Learn More
http://www.oracle.com/technetwork/database/database-technologies/query-optimization/learnmore/index.html

コンテンツやフォーマットをMariaのやり方に合わせたので、過去のバージョンをご覧になったことがあれば取っつきやすいかと思いますが、主要な相違点は、ホワイトペーパー内のスクリプトの個数を減らし、約30ページにまでページ数を削減した点です。そうしなければ、簡単に40ページ越えしていたことでしょう。その代わりに、サンプルをGitHubに挙げておきました。

DW-VLDB - This is a top level repository for code examples related to Data Warehousing and Very Large Databases.
https://github.com/oracle/dw-vldb

ホワイトペーパーの内容に対するフィードバックは、このエントリ（もちろん原文にです！）のコメント欄にお願いします。もっとサンプルがほしい、という場合にはお知らせくだされば、ToDoリストに追加する予定です。当然ながら、より詳細に説明するため、他にもエントリを（スクリプトはGitHubに）投稿するつもりです。

最後に、OTNには、Optimizerページで参照されているその他のホワイトペーパーが多数掲載されています。執筆時点では、これらはOracle Database 12c Release 1を対象にしていますが、当然ながら更新されていきます。

[Java] Announcing: JDK 8 MOOC: Lambdas and Streams, December 2nd!

原文はこちら。
https://blogs.oracle.com/thejavatutorials/entry/announcing_jdk_8_mooc_lambdas

Oracle Massive Open Online Courseに新たにコース「JDK 8 Lambdas and Streams」の追加を発表できうれしく思っています。12月2日からスタートです。

JDK 8 Massive Open and Online Course: Lambdas and Streams Introduction, 2016
https://apexapps.oracle.com/pls/apex/f?p=44785:145:10040796816707::NO:RP,145:P145_EVENT_ID,P145_PREV_PAGE:5067,2

もし筆者と同じなのであれば、経験豊かなJavaプログラマーで、Javaをオブジェクト指向言語として理解していると思いますが、ラムダ式を見たことがあっても、すらすら書くのはまだちょっと、という感じではないでしょうか。

そんな方は、たくさんの人たちと一緒に、ラムダ式とStreams APIを使ったJavaの関数型プログラミングを最新かつ無料のMassive Open Online Course（MOOC）で勉強していきましょう。コースは12月2日から開始し、たった3週間です。ですが、以下を含めてたくさんのことを学ぶことになるでしょう。

日常の問題にラムダ式を適用する
匿名クラスをラムダ式に書き換える
並べ替え、最大・最小の識別、ならびに重複排除問題にStreams APIを適用する
ラムダ式を適用すべき場合（すべきでない場合）を判断する
Collectorsを使う
ParallelStreamsを使ってパフォーマンスを向上させる
ラムダ式のデバッグ

是非参加のボタンをクリックし、コースの詳細を読んで、以下の動画をご覧ください（原文にはボタンがあります。この訳文では上記リンクをクリックして参加登録してください）。12月2日にお会いしましょう！

[WLS, Database] AGL Datasource Support for URL with @alias or @LDAP

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/agl_datasource_support_for_url

Oracle JDBCドライバでは、接続URLに @alias を持つことができ、ホスト名やポート番号、サービス名といった情報を多数のデータソース間で共有する外部のtnsnames.oraファイルに配置することができます。筆者の知見では、（コンピュータ毎に1箇所で）接続情報をより簡単に管理するため、この機能は近年人気が出てきています。情報をさらに一箇所で集中管理するため、URLで @LDAP を使い、接続情報をLDAPサーバから取得することができます。詳細はデータベースのJDBC開発者ガイドをご覧ください。

Oracle® Database JDBC Developer's Guide 12c Release 1 (12.1)
Data Sources and URLs
https://docs.oracle.com/database/121/JJDBC/urls.htm#JJDBC28267
Oracle® Database JDBC開発者ガイド 12cリリース1 (12.1)
データソースおよびURL
http://docs.oracle.com/cd/E57425_01/121/JJDBC/urls.htm#JJDBC28267

このURLフォーマットは汎用データソースならびにマルチ・データソースでサポートしていますが、Active GridLink (AGL) データソースではサポートしていませんでした。その理由は、AGLデータソースURLは長形式フォーマットのURLの中で (SERVICE_NAME=value) を持つ必要があったためです。
WebLogic Server 12.2.1.2.0 (PS2) より、URLは @alias や @ldap 形式も利用できるようになりましたが、 @alias や @ldap を含まない短形式フォーマットはまだサポートされておらず、エラーが発生し動作しませんので、エイリアスやLDAPエントリに格納されたデータベース・サービス名を利用することを強く推奨します（SIDは使わないでください）。AGLのパフォーマンスを最適化するには、エイリアスやLDAPストアで負荷分散やリトライ回数、遅延などの機能を持つ長形式フォーマットのURLを使う必要があります。

ALIAS の例

以下の構成を持つtnsnames.oraファイルを作成します。

tns_entry=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC-scan-address)(PORT=port))(CONNECT_DATA=(SERVICE_NAME=service)))
通常、$ORACLE_HOME/network/adminに作成されます。
以下ののようなURLを使ってWebLogic Serverのデータソース・ディスクリプタを作成します。

jdbc:oracle:thin:@tns_entry
以下のシステムプロパティをWebLogic Serverコマンドラインに追加します。

-Doracle.net.tns_admin=$ORACLE_HOME/network/admin

LDAP の例

LDAP/LDAPSのWebLogic Serverデータソース・ディスクリプタを以下のURLのように作成します。

jdbc:oracle:thin:@ldap://ldap.example.com:7777/sales,cn=OracleContext,dc=com

JDBC Driverの要件

ちょっと落とし穴があります。この機能をサポートするより賢いucp.jarファイルを使う必要があります。そのための方法は2つあります。

12.1.0.2のucp.jarに対するWebLogic Serverのパッチを入手する
（Bug #2319035 - UCP DOESN'T SUPPORT ALIAS URL FOR RAC CLUSTER)
Oracle Database 12cR2のucp.jarファイルを待つ。GAになったタイミングでエントリを投稿する予定です。

[Database] SPFILE Parameter: max_pdbs - a must for Single Tenant

原文はこちら。
https://blogs.oracle.com/UPGRADE/entry/spfile_parameter_max_pdbs_a

時として、私の仕事は一日の最後に笑顔にする側面があります。
オスロからキールへ向かう船上でのOUGN Conferenceの講演の中で、Johannes Ahrendsと同席しました。

CarajanDB - Blog Johannes Ahrends
http://www.carajandb.com/en/blogs/blog-jahrends-en

その後、シングルテナントを指向するお客様に不可欠なPDBの個数を制限する公式の方法がなぜ存在しないのかを議論していました。ハンズオン環境を立ち上げ、休憩の間ちょっと試してみましたが、DROP PLUGGABLE DATABASEを実行しない限り、unplug/plugオペレーションでCONTAINER$中に残ってしまうため、CONTAINER$の制限は正しいソリューションではないことがわかりました。たとえ残りを削除したとしても、COTAINER$への制約をつける方法は上手くいきません。
翌朝の朝食でヨハネスはトリガーについて言及し、すぐにトリガーを発行しました。しかしながら、データ・ディクショナリを使いこなす場合にデータベースのサポートを維持することはよい考えではありません。
そのため、私は社内に問合せ、はっきりと「これを望んでいない人がいる」というメッセージを受け取りました。
オラクルで長く働いているので、この意味がわかります、物事をさらに議論したくないときは、「誰か」を責めるのが一般的です。「誰か」の背後に完全に隠れることができますからね。
Oracle Database 12.2のテストおよび試用を開始し、リリースラベル間のinit.oraパラメータを収集し、変更点や追加箇所を検出していたときに大きな驚きがありました。そして明らかに、その驚きがここに現れたのです。

MAX_PDBS
http://docs.oracle.com/database/122/REFRN/MAX_PDBS.htm#REFRN-GUID-55526BAC-DCB2-4C76-9ACF-1E3D2047E267

つまり、パラメータの説明によると、CDBやApplication ROOTで許容するPDBの最大個数という意味です。
私は驚き、うれしくなり、そして自分の環境ですぐに試さなくては、と思いました。既に自身の環境には3個のPDB（PDB$SEEDは含めていません）がありました。

SQL> alter system set max_pdbs=3;
System altered.

SQL> show pdbs

CON_ID CON_NAME               OPEN MODE  RESTRICTED
------ ---------------------- ---------- ----------
2      PDB$SEED               READ ONLY  NO
3      PDB1                   READ WRITE NO
4      PDB2                   READ WRITE NO
5      CLONE_PDB              MOUNTED

SQL> alter system set max_pdbs=2;
alter system set max_pdbs=2
*
ERROR at line 1:
ORA-32017: failure in updating SPFILE
ORA-65331: DDL on a data link table is outside an application action.

そんなわけで、（少なくとも私の環境では）エラーメッセージが少々粗いですが、このパラメータは求めていたことを実現してくれています。シングルテナント環境では、この値を1に設定し、このコンテナデータベースに対し、2個目のPDBの作成やプラグインをさせないようにしましょう。
まっさらのコンテナデータベースを使い別のテストを実施しました。

SQL> show pdbs

CON_ID CON_NAME      OPEN MODE  RESTRICTED
------ ------------- ---------- ----------
2      PDB$SEED      READ ONLY  NO

SQL> alter system set max_pdbs=1;
System altered.

SQL> show parameter max_pdbs

NAME                     TYPE     VALUE
------------------------ -------- ----- 
max_pdbs                 integer      1

SQL>  create pluggable database pdb1 admin user adm identified by adm  file_name_convert=('/u02/oradata/CDB2/pdbseed','/u02/oradata/CDB2/pdb1');
Pluggable database created.

SQL>  create pluggable database pdb2 admin user adm identified by adm  file_name_convert=('/u02/oradata/CDB2/pdbseed','/u02/oradata/CDB2/pdb2');

create  pluggable database pdb2 admin user adm identified by adm  file_name_convert=('/u02/oradata/CDB2/pdbseed','/u02/oradata/CDB2/pdb2')
*
ERROR at line 1:
ORA-65010: maximum number of pluggable databases created


SQL> drop pluggable database pdb1 including datafiles;
Pluggable database dropped.

SQL>  create pluggable database pdb2 admin user adm identified by adm  file_name_convert=('/u02/oradata/CDB2/pdbseed','/u02/oradata/CDB2/pdb2');
Pluggable database created.

確かなソリューションのように見えます。

しかしながら、Oracle ACE DirectorのFranck Pachotのエントリもご覧ください。このパラメータによって発生する問題について記載しています。

Oracle 12cR2: MAX_PDBS
http://blog.dbi-services.com/oracle-12cr2-max_pdbs/

[Cloud] Oracle Container Cloud Service - Managing Containers Easily on Oracle Public Cloud

原文はこちら。
https://community.oracle.com/community/cloud_computing/infrastructure-as-a-service-iaas/oracle-container-cloud-service/blog/2016/11/14/oracle-container-cloud-service-managing-containers-easily-on-oracle-public-cloud

本日Oracle Container Cloud Service (Container CS) の一般提供を発表できることに非常にわくわくしております。Oracleが買収し、Container CSというクラウドサービスに変化させたStacnEngineコンテナ管理ソフトウェアを使った非常にわくわくする旅路でした。

（筆者は）元々のStackEngineチームに属していましたので、個人的にもコアの設計原則である”easy-to-use”が、競合他社製品と比べてContainer CSの大きな差別化要素として使われていることに興奮しています。
この使い勝手のよさが、Container CSのいくつかの主要な差別化機能になっています。

(1) Container CSは、Dockerコンテナアプリケーションを実行するワーカーノードにパワーを供給するために必要なIaaS Computeをどのようなキャパシティでも簡単にプロビジョニングすることができます。プロビジョニング後、すぐにプラットフォームを使うことができます。実施することは、ご自身のコンテナを持ち込み。気軽に実行する、これだけです。さらに、複数のContainer CSインスタンスを必要に応じて自由に使いたいとお客様は思ってらっしゃることでしょう。開発チームやDevOpsチーム用のインスタンスを展開し、個々人のためにその他のインスタンスを展開してください。これにより、お客様がDockerワークロードをラップトップから開放しコンテナ環境に簡単に移すことができます。

(2) Container CSには1クリックで展開できる、たくさんのサンプル・コンテナ・アプリケーションがあります。このサンプルには、シンプルかつたった1個のイメージと、すぐに実行できるテンプレート中のランタイム情報とで構成されている、Service（サービス）と呼ばれるものと、オーケストレーションが定義された、複数のホストにわたって展開可能な複数イメージのアプリケーションである、Stack（スタック）と呼ばれるものがあります。これらのServiceとStackの長所は、お客様がこうしたサンプルやこれらのサンプルのビルド方法を活用し、自身のアプリケーションをモデリングする上で役立てることができる、という点です。

(3) Container CSのUIは、TCPチェックを含む多くのネイティブ機能と理解しやすい色分けされたヘルスチェックを使っています。そのため、UIからステータスの前後関係と実行中のコンテナの状態を理解することができます。しかし、最大の前後関係はデプロイメントの機能を通じて与えられるものと考えます。デプロイメントは、コンテナ化されたアプリケーションを実行した際に作成されます。デプロイメントによって、デプロイメント全体の健康状態とともに、コンテナが何を実行しているのかという意味で個々のコンテナを確認することができます。

標準の"docker ps"コマンドでターミナルに表示される情報と比較してみてください。下の画面ショットで、速く確認できる情報には限りがあります。おおよそ、コンテナのリスト、ネイティブDocker名とアップタイムぐらいです。ターミナル・ウインドウを使うオブザーバーで、コンテナが実際にしていることがわかるのでしょうか。
下図で、アプリケーションや、実行中のアプリケーションは何かわかるでしょうか。

では、これを次の2画面と対比してみてください。この画面では記述名を持つ、Container CSで動作している全てのデプロイメントを確認できます。
デプロイメントビューのからみでコンテナを見ることができます。最初の画面では、実行中の全てのデプロイメントとその健康状態を表示しています。

下図では、デプロイメントの一つに関する詳細をご覧いただけます。このケースでは、この環境の全てのホストに渡ってデプロイされているELKロギングアプリケーションが良好な状態であることがわかります。

Oracle Public CloudのContainer CSチーム（と筆者）にとって、今日は我々のコンテナ管理テクノロジーをご利用いただくためにお披露目でき、非常にうれしい日です。

無料トライアルは、以下のURLの［無料トライアル］のリンクをクリックし、［Oracle Cloud PaaSおよびIaaS］をクリックすると登録できます。詳細情報も以下のURLからどうぞ。

Oracle Container Cloud Service
https://cloud.oracle.com/ja_JP/container

[Java] Visual VM in JDK 9 and Beyond

原文はこちら。
https://blogs.oracle.com/java-platform-group/entry/visual_vm_in_jdk_9

Visual VMはJava Virtual Machine上で動作しているコードに関する情報を提供するツールで、Oracle JDK 6、7、8で提供されています。
Visual VMの詳細情報はNetBeans Profiler and Visual VM blogをご覧ください。

NetBeans Profiler
https://blogs.oracle.com/nbprofiler/

JDK 9から、Visual VMはOracle JDKに同梱されません。Visual VMをOracle JDK 9以後で使いたい場合には、Visual VMオープンソースプロジェクトサイトからダウンロードすることができます。

VisualVM - All-in-One Java Troubleshooting Tool
https://visualvm.github.io/

[Linux] Oracle Linux 7.3 Available Now

原文はこちら。
https://blogs.oracle.com/linux/entry/oracle_linux_7_update_3

Oracle LinuxチームとVirtualizationチームはx86-64向けOracle Linux 7 Update 3の一般提供を発表できることをうれしく思っています。

サブスクリプションを持つユーザーの方は、ISOをMy Oracle Supportからダウンロードできます。ISOイメージはOracle Software Delivery Cloudからもダウンロードできます。

My Oracle Support
https://support.oracle.com/
Oracle Software Delivery Cloud
http://edelivery.oracle.com/linux/

個々のRPMパッケージはPublic YumサーバおよびUnbreakable Linux Network (ULN)から入手できます。

Oracle Linux Yum Server
http://yum.oracle.com/
Unbreakable Linux Network
https://linux.oracle.com/

このリリースでは、UEK Release 4 (UEK R4)がOracle Linux 7 ISOイメージに初めて同梱されています。新しいOracle Linux 7 Update 3をインストールすると、デフォルトでUEK R4で起動しますが、既存のOracle Linux環境をアップデートするには明示的にUEK R4をインストールする必要がありますのでご注意ください（既存のUEK R3カーネルを自動的に置き換えることはしません）。

Kernel Support with Oracle Linux 7 Update 3

Oracle Linux 7 Update 3 ISOイメージには、Unbreakable Enterprise Kernel (UEK) とRed Hat Compatible Kernel (RHCK)の2種類のカーネルパッケージが同梱されており、インストールされます。インストールプロセスで、UEKをデフォルトカーネル、RHCKを代替カーネルとしてとして起動するよう構成します。

Oracle Linux 7 Update 3 ISOイメージには以下のカーネルパッケージが含まれています。

kernel-uek-4.1.12-61.1.18.el7uek (UEK R4u2 +errata)
kernel-3.10.0-514.el7

Oracle Linux 7 Update 3は引き続きサポートしますが、最新のUEK R3u7以後を同梱することはありません。

Application Compatibility

Oracle LinuxはRed Hat Enterprise Linuxとユーザー空間の互換性を維持していますが、OSの基礎になるカーネルバージョンには依存しません。ユーザー空間の既存のアプリケーションは引き続きOracle Linux Update 3とUEK R4との組み合わせで変更せずに実行できますし、既にRHEL 7やOracle Linux 7で動作保証されているアプリケーションに対し、再度動作検証・保証する必要はありません。

Notable in Oracle Linux 7 Update 3:

UEFI Secure Boot Support

このアップデートで、UEFIセキュアブートが有効化されているシステム上にOracle Linux 7をインストール、利用することができます。Oracle Linux 7 Update 3ではUEFIセキュアブートを完全にサポートしています。

Oracle Linux 7 Update 3のその他の新機能や変更は、製品ドキュメントのリリースノートをご覧ください。

Oracle Linux 7 Document Library
https://docs.oracle.com/cd/E52668_01/index.html

Oracle Linuxはダウンロード、利用、配布は無償です。アップデートやエラータも無料でご利用いただけます。サポートについては、どのシステムでサポート契約が必要かを決めてください。

Oracle Linux OS and Support
http://www.oracle.com/linux
Free Updates and Errata for Oracle Linux
https://blogs.oracle.com/linux/free-updates-and-errata-for-oracle-linux
Oracle Linux Supoprt
http://www.oracle.com/us/technologies/linux/support/overview/index.html

これがOracle Linuxを開発、テスト、本番システムのための理想的な選択肢たらしめています。全システムを最新かつセキュアに保ちながら、個々のシステムでどのサポート範囲がベストなのかを決めてください。Oracle Linux Premier Supportを持つお客様は、Oracle Kspliceを使ったゼロダウンタイムカーネルアップデートやOracle OpenStack for Oracle Linuxのサポートも受けることができます。

Oracle Ksplice
http://www.oracle.com/us/technologies/linux/ksplice-datasheet-487388.pdf
Oracle OpenStack for Oracle Linux
http://www.oracle.com/technetwork/server-storage/openstack/linux/documentation/datasheet-oracle-openstack-2296038.pdf

[Database] Upgrades to Oracle Database 12.2.0.1 (and Downgrades)

原文はこちら。
https://blogs.oracle.com/UPGRADE/entry/upgrades_and_downgrades_to_oracle

Oracle Database 12c Release 2 (12.2) がNASおよびEMEAゾーンのDatabase Cloud Service、Exadata Cloud Serivice、Exadata Express Cloud Serviceでご利用いただけるようになりました。Oracle Database 12.2のドキュメントも公開されています。
（訳注）

Oracle Database Cloud Service - What's New in Oracle Database
http://docs.oracle.com/cloud/latest/dbcs_dbaas/whatsnewindb.htm
All Books for Oracle® Database Online Documentation Library 12c Release 2 (12.2)
http://docs.oracle.com/database/122/nav/portal_booklist.htm

DBUAやコマンドライン上で catctl.pl を使い直接アップグレードをサポートするバージョンは以下の通りです。

Oracle Database 11.2.0.3
Oracle Database 11.2.0.4
Oracle Database 12.1.0.1
Oracle Database 12.1.0.2

Oracle Database 11.2.0.3より前のバージョンは直接アップグレードのサポート対象外です。11.2.0.3より前のバージョンをお使いの場合、Data PumpのようなツールやTransportable Tablespaces（トランスポータブル表領域）などといったテクニックを使うと、アップグレードにあたって2段階、3段階の移行作業をしなくてすむようになります。もちろん、Oracle Cloudへの移行時にも同様のことが言えます。

ダウングレードについては、CDB以外について、アップグレードする前のバージョンにダウングレードすることができます。

[Java] Hung JVM due to the threads stuck in pthread_cond_timedwait()

原文はこちら。
https://blogs.oracle.com/poonam/entry/hung_jvm_due_to_the

このエントリでは、Javaプロセスのハングが実際にはJava/JVMが原因ではなく、OSの問題が原因で起こるという複数のシナリオについて説明していきます。今回説明するどちらのハングもLinux OSで発生します。
それでは、最初のケースを見ていきましょう。この例では、スレッドがJavaの Thread.sleep() を呼び出すところでスタックしているようです。プロセスのスタックトレースから、2個のスレッドに関心を当ててみましょう。

Thread 26755: (state = IN_VM)
 - java.lang.Thread.interrupt0() @bci=0 (Interpreted frame)
 - java.lang.Thread.interrupt() @bci=51, line=852 (Interpreted frame)
 - oracle.core.ojdl.BufferedLogWriter.stopFlusher() @bci=17, line=380
(Interpreted frame)

Thread 21714: (state = BLOCKED)
 - java.lang.Thread.sleep(long) @bci=0 (Interpreted frame)
 - oracle.core.ojdl.BufferedLogWriter$Flusher.run() @bci=30, line=401
(Interpreted frame)

スレッド #26755 は、Thread.sleep() を実行しているスレッド #21714 に割り込みしようとしています。スレッド#21714はプロセス内の他スレッドが進行できないようにするBLOCKED状態に留まっているため、その結果プロセスがハングしています。
では、ネイティブ・スタックトレースを見てみましょう。

Thread 26755:
#0  0xf77e7430 in __kernel_vsyscall ()
#1  0x4dcc31b9 in __lll_lock_wait () from /lib/libpthread.so.0
#2  0x4dcbe550 in _L_lock_677 () from /lib/libpthread.so.0
#3  0x4dcbe421 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x064ff034 in os::Linux::Event::unpark() ()
#5  0x064fc60a in os::interrupt(Thread*) ()

Thread 21714:
#0  0xf77e7430 in __kernel_vsyscall ()
#1  0x4dc0fc43 in __lll_lock_wait_private () from /lib/libc.so.6
#2  0x4db94348 in _L_lock_9835 () from /lib/libc.so.6
#3  0x4db91f27 in calloc () from /lib/libc.so.6
#4  0x4dcc0e1c in pthread_cond_timedwait@GLIBC_2.0 () from /lib/libpthread.so.0
#5  0x064fefa1 in os::Linux::Event::timedwait(timespec*) ()
#6  0x064fc2bf in os::sleep(Thread*, long long, bool) ()
#7  0x063d5d90 in JVM_Sleep ()

pthread_cond_timedwait() 関数に期間としてどのような値を渡したのか疑問に思われるかもしれません。このときの値は5秒でしたので、5秒後 pthread_cond_timedwait() は待機状態から復帰しているはずです。
pthread_cond_timedwait()は、他スレッドとの調整に利用するpthread_cond_t* condとpthread_mutex_t* mutexという引数を受け入れます。

pthread_cond_timedwait(3) - Linux man page
https://linux.die.net/man/3/pthread_cond_timedwait

ではcondとmutexの両引数を見てみましょう。

(gdb) print *((pthread_cond_t*)0xad533ff0)
$3 = {__c_lock = {__status = 0, __spinlock = 17}, __c_waiting = 0xad534050}

(gdb) print *((pthread_mutex_t*)0xad533fd8)
$4 = {__m_reserved = 2, __m_count = 0, __m_owner = 0x54d2, __m_kind = 0, __m_lock = {__status = 1, __spinlock = 0}} 
__m_owner = 0x54d2 = 21714

 (gdb) print *$11->_osthread->_interrupt_event
$14 = {<CHeapObj> = {<No data fields>}, _count = 0, _nParked = 1,
cachePad = {-2.3622328335110874e-90, 4.2439915835115547e-313,
    1.4480588116526359e-314, 4.2439915866735748e-313}, _mutex =
{{__m_reserved = 2, __m_count = 0, __m_owner = 0x54d2, __m_kind = 0,
__m_lock = {
        __status = 1, __spinlock = 0}}}, _cond = {{__c_lock = {__status
= 0, __spinlock = 17}, __c_waiting = 0xad534050}}, FreeNext = 0xbad, Immortal = 1}

上のデータから、スリープ状態にあるスレッドが_mutexを所有していること、割り込もうとしているスレッドが_mutexを取得してスリープ状態にあるスレッドにシグナルを送信しようと待機していることがわかります。よく見ると、スリープ状態のスレッドは、_mutexのリリースする前に（callocで）メモリアロケーションを完了するためにネイティブ・ヒープのロックを待っています。

そのため、スレッドがpthread_cond_timedwait()で無限にスタックするのは、JVMが問題なのではなく、Linuxのカーネルレベルのロック同期に伴う問題であることがわかりました。

では、別のケースを見ていきましょう。このケースでは、3個のスレッドが__pthread_cond_timedwait()でスタックしており、プロセス中の他のスレッドの進行を抑止しています。

----------------- 11374 -----------------
0x00000032f1c0ba0e      __pthread_cond_timedwait + 0x13e
0x00007fb1453bbf94      _ZN13ObjectMonitor4waitElbP6Thread + 0x224
0x00007fb1454a0d83      _ZN18ObjectSynchronizer4waitE6HandlelP6Thread + 0x53
0x00007fb14520b34b      JVM_MonitorWait + 0x1fb
0x00007fb13d010eee      * java.lang.Object.wait(long) bci:0 (Interpreted frame)
0x00007fb13d005a82      * java.lang.Thread.join(long) bci:70 line:1214 (Interpreted frame)
0x00007fb13d005a82      * iasauto.execution.GetCfgRunDTE.execute() bci:864 line:504 (Interpreted frame)
0x00007fb13d005a82      * iasauto.execution.RunOneJob.execute() bci:1675 line:1521 (Interpreted frame)
0x00007fb13d005a82      * iasauto.execution.RunOneJob.main(java.lang.String[]) bci:18 line:58 (Interpreted frame)
0x00007fb13d000438      <StubRoutines>
0x00007fb14519e8d0      _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread + 0x1e0
0x00007fb1453ca829       _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_  + 0x19
0x00007fb14519e6e5      _ZN9JavaCalls4callEP9JavaValue12methodHandleP17JavaCallArgumentsP6Thread + 0x25
0x00007fb1451d99f7       _Z17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread  + 0x147
0x00007fb1451c753f      jni_CallStaticVoidMethod + 0x20f
0x0000000040002284      JavaMain + 0x2a4

----------------- 31490 -----------------
0x00000032f1c0ba0e      __pthread_cond_timedwait + 0x13e
0x00007fb1453bbf94      _ZN13ObjectMonitor4waitElbP6Thread + 0x224
0x00007fb1454a0d83      _ZN18ObjectSynchronizer4waitE6HandlelP6Thread + 0x53
0x00007fb14520b34b      JVM_MonitorWait + 0x1fb
0x00007fb13d010eee      * java.lang.Object.wait(long) bci:0 (Interpreted frame)
0x00007fb13d005a82      * java.lang.Thread.join(long) bci:70 line:1214 (Interpreted frame)
0x00007fb13d005a82      * iasauto.engine.LocalTaskProcess.execute() bci:70 line:206 (Interpreted frame)
0x00007fb13d005a82      * iasauto.engine.TaskProcess.executeLocal(boolean) bci:277 line:751 (Interpreted frame)
0x00007fb13d005a82      * iasauto.engine.TaskProcess.run() bci:631 line:289 (Interpreted frame)
0x00007fb13d005f5c      * java.lang.Thread.run() bci:11 line:682 (Interpreted frame)
0x00007fb13d000438      <StubRoutines>
0x00007fb14519e8d0      _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread + 0x1e0
0x00007fb1453ca829       _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_  + 0x19
0x00007fb14519e246       _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread  + 0x116
0x00007fb14519e2c7      _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread + 0x47
0x00007fb145230c12      _Z12thread_entryP10JavaThreadP6Thread + 0xa2
0x00007fb1454d3401      _ZN10JavaThread3runEv + 0x121

----------------- 11681 -----------------
0x00000032f1c0ba0e      __pthread_cond_timedwait + 0x13e
0x00007fb1453bbf94      _ZN13ObjectMonitor4waitElbP6Thread + 0x224
0x00007fb1454a0d83      _ZN18ObjectSynchronizer4waitE6HandlelP6Thread + 0x53
0x00007fb14520b34b      JVM_MonitorWait + 0x1fb
0x00007fb13d010eee      * java.lang.Object.wait(long) bci:0 (Interpreted frame)
0x00007fb13d005a82      * java.util.TimerThread.mainLoop() bci:201 line:509 (Interpreted frame)
0x00007fb13d005a82      * java.util.TimerThread.run() bci:1 line:462 (Interpreted frame)
0x00007fb13d000438      <StubRoutines>
0x00007fb14519e8d0      _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread + 0x1e0
0x00007fb1453ca829       _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_  + 0x19
0x00007fb14519e246       _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread  + 0x116
0x00007fb14519e2c7      _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread + 0x47
0x00007fb145230c12      _Z12thread_entryP10JavaThreadP6Thread + 0xa2
0x00007fb1454d3401      _ZN10JavaThread3runEv + 0x121
0x00007fb1453cbcdf      _Z10java_startP6Thread + 0x13f

これまでの調査から、これは以下のコミットで関連する修正が完了したLinuxカーネルの問題であると信じています。

futex: Ensure get_futex_key_refs() always implies a barrier
https://github.com/torvalds/linux/commit/76835b0ebf8a7fe85beb03c75121419a7dec52f0

まとめると、見かけ上JavaプロセスがハングしているのはJava/JVMの問題っぽく見えたとしても、本当の理由はそうではないことがあります。私たちはスレッドのネイティブスタックトレースをよく見て、何が原因でスレッドが停止しているのか、どこでスタックしているのか、を理解する必要があります。

[Java] Crashes in ZIP_GetEntry

原文はこちら。
https://blogs.oracle.com/poonam/entry/crashes_in_zip_getentry

先日、以下のようなスタックトレース付きで、アプリケーションクラッシュに関する数多くの報告が、様々なお客様や製品グループから寄せられました。

Stack: [0xb0c00000,0xb0c80000],  sp=0xb0c7c890,  free space=498k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc_psr.so.1+0x700]  memcpy+0x2f8
C  [libzip.so+0xd19c]
C  [libzip.so+0x2380]  ZIP_GetEntry+0xe4
C  [libzip.so+0x2800]  Java_java_util_zip_ZipFile_getEntry+0xc4
j  java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J+0
j  java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J+0
j  java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+31
j  java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+2
j  java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2

ほとんどの場合、JVMインスタンス実行中にアクセスしているjarファイルを変更、上書きした際にZIP_GetEntryにてクラッシュが発生しています。パフォーマンスの理由により、HotSpot JVMのメモリはmmapを使い各Jarファイルのセントラルディレクトリ構造にマップします。こうすることで、Jarファイルからエントリを読み取る必要がある都度セントラルディレクトリ構造データをディスクから読み取ることを避けています。Jarファイルをディスク上で変更、上書きする場合、以前に読み取ったJVMのデータのコピーがディスク上のJarファイルと一致しなくなり、変更されたJarファイルからエントリを読み取り、ロードしようとするとアプリケーションクラッシュが発生することがあります。

Java 1.6.0_23以後では、プロパティを使ってJarファイルのセントラルディレクトリ構造メモリマッピングのマッピングを抑止することができます。

-Dsun.zip.disableMemoryMapping=true

このプロパティを有効にすると、JVMはJarファイルのエントリを読み出す都度ディスク上のJarファイルからセントラルディレクトリ構造を読み取る必要があるため、アプリケーションのパフォーマンスに影響することにご注意ください。そのため、JVMがJarファイルのイメージをロードしている間は、Jarファイルを変更したり上書きしたりしないようにすることがベストです。

Java 9では、このZIPクラッシュを以下の機能強化で解決しました。

JDK-8142508: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk
https://bugs.openjdk.java.net/browse/JDK-8142508

この変更に対するコード・レビューのスレッドは以下からどうぞ。

RFR: JDK-8142508: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036495.html

この機能強化はmmapを使うZIPファイルのネイティブ実装をJava実装に置き換え、上述のアプリケーションクラッシュのリスクを除去しています。

[Integration, BAM] BAM 12c Persistence Payload For High Throughput

原文はこちら。
https://blogs.oracle.com/integration/entry/bam_12c_persistence_payload_for

Oracle BAM 12cから、Enterprise Message Source (EMS) 構成の「ソースからデータ・オブジェクト・フィールドへのマッピング（Source To Data-Object Field Mapping）」で新しいオプション「ペイロードの永続性（Persistence Payload）」と呼ばれる新しいが提供されていることにお気づきかもしれません。

Oracle® Fusion Middleware Monitoring Business Activity with Oracle BAM 12c (12.2.1.2.0)
Creating Oracle BAM Enterprise Message Sources
Creating an Enterprise Message Source: Steps
http://docs.oracle.com/middleware/12212/bam/bam-user-guide/GUID-AC477556-20B3-4B2B-8F4E-53A176C60242.htm#BAMUG1954

このチェックボックスをオンにすると、ペイロードの変換が不要になります。BAM 12cにデータを送信し、移入しようとしているデータオブジェクトの名前を含む正しい操作を実行するために必要なものは、全てペイロード自身が持っているからです。

（訳注）
ドキュメントには、"Check this box if the EMS payload does not contain the data-object field mapping information."（EMSペイロードにdata-objectフィールドマッピング情報が含まれていない場合にチェックを入れてください）とあります。また、この設定を有効にした場合、datetime仕様と、XML Message Formatting （XMLメッセージ書式設定）プロパティは利用できません。

以下の例のように、JAXBを使ってBAMで必要とするペイロードをプログラムで構築することができます。

これにより、1個のJMSメッセージ内に複数のメッセージを束ねて送信できるようになります。BAMはその後個々の列に分割し、あたかもメッセージが個々で送信されている場合と同様にBAMダッシュボード内で利用します。

個別に送信した場合よりもずっと多くのイベントを送信することができます。

[Java] G1 and Flight Recorder's -XX:FlightRecorderOptions=stackdepth option

原文はこちら。
https://blogs.oracle.com/poonam/entry/g1_and_flight_recorder_s

先頃。お客様から次のような報告がありました。

G1GCで -XX:FlightRecorderOptions=stackdepth=512 を指定し JFR (Java Flight Recorder) を使うとパフォーマンスの劣化が見られた。しかしstackdepth (スタックの深さ) の設定は同じで同じ設定でParallel GCの場合にはパフォーマンスに影響はなかった。

このフライト・レコーディングの結果、低パフォーマンスの原因はJFRCheckpointという操作によって生じる停止であることがわかりました。この JFRCheckpoint による停止は -XX:FlightRecorderOptions=stackdepth=512 を指定して記録を開始する場合においてのみ発生し、 -XX:FlightRecorderOptions=stackdepth=3 を指定した場合には発生しませんでした。
考えられる理由を調べてみましょう。The time taken by the JFRCheckpoint 操作の所要時間は、ディスクに書き出すために必要なデータの量に直に比例します。G1GCでは、TLAB (Thread Local Allocation Buffer) のサイズが小さいため、実質的に数多くの 'Allocation in TLAB' イベントと 'Allocation outside TLAB' イベントが生成されます。スタックの深さをstackdepthオプションで増やすと、G1GCでは他のGCに比べてずっと多くのスタックトレースデータをディスクに書き込む必要があります。
簡単なテストを実行することにしました。GCが頻繁に発生するアプリケーションをまず、Parallel GCで実行し、その後G1 GCで実行しました。これらの両方のテストでは、HotSpot Defaultの記録を開始し、その後プロファイル設定を使って手作業で時間を修正した記録を開始しました。その結果以下のことがわかりました。

G1GCの場合、GCイベントの個数はParallel GCに比べて遙かに多い。
TLABはG1では小さいため、Parallel GCの場合に比べてより多くのアロケーション・イベントが発生する。
両GCでの2分間のプロファイル記録で生成されたファイルのサイズを比較すると、G1 GCでは約3MBなのに対し、Parallel GCでは約600KBだった。これは示しているG1 GCでディスクに書き込むデータ量がParallel GCの場合に比べて大きいことを示している、この結果、JFRCheckpointによる長時間の停止が発生する原因になっている。

まとめると、G1GCでJFRを使っている場合、stackdepthで指定するスタックの深さはデフォルト値（デフォルトは64）を使う。もしくはJFRCheckpointオペレーションの長時間の停止が見られる場合には、ずっと小さな値をstackdepthに指定して実行することを推奨します。

[Java] Advanced Management Console 2.5 is Released

原文はこちら。
https://blogs.oracle.com/thejavatutorials/entry/advanced_management_console_2_5

Advanced Management ConsoleはOracle Java Standard Edition (SE) AdvancedとOracle Java SE Suiteという商用製品のコンポーネントです。

Oracle Java SE Advanced & Suite Products
http://www.oracle.com/technetwork/java/javaseproducts/overview/index.html

このAdvanced Management ConsoleはJavaのバージョンや貴社内のJavaアプリケーションの利用を管理する上で役に立ちます。
最新のver 2.5では以下の機能が追加されています。

Advanced Management ConsoleエージェントでのJava Usage Tracker (JUT)の収集
Mac OS X上のJava Runtime Environment (JRE) の管理
アプリケーション名をシンプル化
Javaアプリケーションの詳細情報表示で以下の内容を含むようになりました

ホスト名/IPアドレス
JREのパス

登録: 投稿 (Atom)