Quantcast
Channel: Oracle Blogs 日本語のまとめ
Viewing all 760 articles
Browse latest View live

[WLS] Configuring Datasource Fatal Error Codes

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

JDBCの操作に関するよく知られたエラーコードは、データベースがシャットダウン中もしくはすでに停止しているとか、構成の問題であると解釈されます。このエラーが発生した場合、後続の操作が失敗し、ハングアップするか、完了までに時間がかかるため接続を維持したくありません。こうしたエラーコードは、"fatal-error-codes"という値を接続プールのパラメータで利用しデータソース構成で構成することができます。この値はエラーコードをカンマで区切ったリストです。SQLExceptonがJDBCの操作で見られたり、sqlException.getErrorCode()が構成済みのコードのいずれかに一致したりする場合、接続を接続プールに返さずに接続を閉じます。
以前のOC4Jアプリケーション・サーバー(Oracle Internet Application Server)の場合、任意の接続でこれらのエラーのいずれかが発生した場合には、接続プール中の全ての接続を閉じましていましたが、WebLogic Serverでは、致命的なエラーが発生した接続を閉じるだけにしました。これにより、使用できないデータベースの場合に加え、問題のある接続に固有のエラーコードを追加することができます。
Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1.1)
致命的エラー・コードの定義
http://docs.oracle.com/cd/E80149_01/wls/JDBCA/jdbc_datasources.htm#CJAIGEAAOracle® Fusion Middleware Administering JDBC Data Sources for Oracle WebLogic Server 12c (12.2.1.2.0)
Define Fatal Error Codes
http://docs.oracle.com/middleware/12212/wls/JDBCA/jdbc_datasources.htm#JDBCA520
以下のエラーコードは事前構成済みで、無効化することはできません。個々のデータソースについて、これらのドライバや別のドライバに対応したエラーコードを追加することができます。
ドライバの種類デフォルトの致命的エラーコード
Oracle Thin Driver3113, 3114, 1033, 1034, 1089, 1090, 17002
WebLogic or IBM DB2 driver-4498, -4499, -1776, -30108, -30081, -30080, -6036, -1229, -1224, -1035, -1034, -1015, -924, -923, -906, -518, -514, 58004
WebLogic or IBM Informix driver-79735, -79716, -43207, -27002, -25580, -4499, -908, -710, 43012
以下は致命的なエラーコード文字列を既存のデータソースに追加するためのWLSTスクリプトです。
# java weblogic.WLST fatalerrorcodes.py import sys, socket, os hostname = socket.gethostname() datasource="JDBC GridLink Data Source-0" connect("weblogic","welcome1","t3://"+hostname+":7001") edit() startEdit() cd("/JDBCSystemResources/" + datasource ) targets=get("Targets") set("Targets",jarray.array([], ObjectName)) save() activate() startEdit() cd("/JDBCSystemResources/" + datasource + "/JDBCResource/" +  datasource + "/JDBCConnectionPoolParams/" + datasource ) set("FatalErrorCodes","1111,2222") save() activate() startEdit() cd("/JDBCSystemResources/" + datasource ) set("Targets", targets) save() activate()
実験的に、RESTで試してみました。
localhost=localhost
editurl=http://${localhost}:7001/management/weblogic/latest/edit
name="JDBC GridLink Data Source-0"

curl -v --user weblogic:welcome1 -H X-Requested-By:MyClient -H Accept:application/json -X GET ${editurl}/JDBCSystemResources/${name}/JDBCResource/JDBCConnectionPoolParams?links=none"

curl -v --user weblogic:welcome1 -H X-Requested-By:MyClient -H Accept:application/json -H Content-Type:application/json -d "{}" -X POST "${editurl}/changeManager/startEdit"

curl -v --user weblogic:welcome1 -H X-Requested-By:MyClient -H Accept:application/json -H Content-Type:application/json -d "{ targets: [] }" -X POST "${editurl}/JDBCSystemResources/${name}"

curl -v --user weblogic:welcome1 -H X-Requested-By:MyClient -H Accept:application/json -H Content-Type:application/json -d "{ fatalErrorCodes: '1111,2222' }" -X POST "${editurl}/JDBCSystemResources/${name}/JDBCResource/JDBCConnectionPoolParams"

curl -v --user weblogic:welcome1 -H X-Requested-By:MyClient -H Accept:application/json -H Content-Type:application/json -d "{ targets: [ { identity: [ servers, 'myserver' ] } ] }" -X POST "${editurl}/JDBCSystemResources/${name}"

curl -v --user weblogic:welcome1 -H X-Requested-By:MyClient -H Accept:application/json -H Content-Type:application/json -d "{}" -X POST "${editurl}/changeManager/activate"

curl -v --user weblogic:welcome1 -H X-Requested-By:MyClient -H Accept:application/json -X GET "${editurl}/JDBCSystemResources/${name}?links=none"

[Java] Java SE Offerings

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

Javaエコシステムは非常に多様です。無数のデバイスやサーバーに能力を供給しています。世界中のクラウドインフラストラクチャにとって重要なものです。Java Platform Standard Edition (Java SE) は汎用コンピューティングにとっての中核となるJavaプラットフォームであり、それ自体が多様です。
Oracle Java Platform Groupが考える、Java SEに関するOracleの主要な4領域での取り組みについて以下で説明します。

1) OpenJDK http://openjdk.java.net/
OpenJDKは、Java Platform Standard Editionおよび関連プロジェクトのオープンソース実装で協力する場です。OpenJDKへの強いコミットメントはこれまでと変わらず、先頃JDK 10プロジェクトを開始しました。
JDK 10
http://openjdk.java.net/projects/jdk10/
OpenJDKには、エコシステム全体にわたって幅広く参加いただいています。
The OpenJDK Open Source Project on Open Hub
https://www.openhub.net/p/openjdk
OracleはSunを買収して以来、一貫して活動を続け、広がってきました。 たとえば、Red Hat、Canonical、SUSEなどの主要なLinuxディストリビューターやその他の当事者は、このオープンソースコード・ベースのバイナリを生成して出荷します。ソースコードは一般的なGNU General Public License v2の下で入手できます。つまり、完全に無償です。
また、数多くの目的のためにソースコードをライセンス供与したいと考えている企業は商用ソースライセンスも入手できますし、そうしている企業は数多くあります。例えばHP、SAP、IBMなどなどの企業は、自身のハードウェアやOS製品を生産しており、そういった製品向けに商用グレードのJava SEを利用できるようにするために商用ソースライセンスを利用しています。

2) OracleのJava SE実装(Oracle JDKおよびOracle JRE)
Oracle JRE/JDKはOracleによるJava SEの実装です。SAPやRed Hat、IBM、HPなどの多くの企業が自身の顧客に対して自身の実装を提供しているのと同様に、OracleもOracleの実装を提供しています。バイナリ配布には主要な2個のチャネルがあります。


これらのバイナリは、java.com/licenseに記載されているように、大部分のユースケースについては無償です。
Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX
http://www.oracle.com/technetwork/java/javase/terms/license/index.html

3) Oracle Java SE Advanced / Java SE Advanced Desktop / Java SE Suite
Oracleは、Java SE実装とは別に、企業ユーザーをターゲットとする高度なツールと機能も提供しています。
Oracle Java SE Advanced and Oracle Java SE Suite
http://www.oracle.com/us/technologies/java/java-se-suite-394230.html
これらの機能には、企業内でのJavaの監視、管理および展開に役立つツール、高度なランタイム診断と監視のためのツールだけでなく、Java SE 6やJava SE 7といった古いバージョンのJava SEへのサポートやアップデートへのアクセスも含まれます。これらの商用機能は、My Oracle SupportもしくはOTNから個別のダウンロードとして提供されます。Oracle JREと対話する必要がある場合、商用機能はデフォルトでオフになっており、 -XX:+UnlockCommercialFeaturesフラグをJVM実行時に指定して有効化できます。
Java Platform, Standard Edition Tools Reference
Advanced Runtime Options
http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BABCBGHF
この特定の商用機能に関する詳細は、以下のURLにある表1-1を参照してください。
Oracle Java SE and Oracle Java Embedded Products
http://www.oracle.com/technetwork/java/javase/terms/products/index.html

 4) Java SE embedded
(2) での記載通り、Oracle JRE/JDKはたいていのユースケース、汎用目的のデスクトップやサーバー上で実行している場合はでは無料です。お客様がOracle JDK/JREをある種のデバイス(例えばレジ)に組み込みたい場合、無料のBCLライセンスは適用されません。
Oracle Java SE Embedded
http://www.oracle.com/technetwork/java/embedded/embedded-se/overview/index.html
このような場合は商用のJava SE embeddedライセンスを交渉する必要があります。Java SE embeddedでは、リソース制限のあるデバイスや、組み込み向けのチップセットのための追加のバイナリオプションも提供しています。

[Java] Java EE 8 - Community Survey Results and Next Steps

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

Java EE Community Surveyにご協力いただきありがとうございます。1693件の回答があり、その結果をもって、JavaOne 2016でのOracleが提案したJava EEロードマップの提案を含む、21個の異なるコンポーネント・テクノロジーの重要性をランク付けしました。ロードマップの詳細は以下のAnil GaurのJavaOne 2016キーノートの動画をご覧ください。


アンケートの結果の詳細、および分析は以下のリンクからどうぞ。
Java EE Survey Results and Java EE 8
https://java.net/projects/javaee-spec/downloads/download/Java%20EE%20Survey%20Results%20December%202016.pdf 
下図は、コミュニティからのフィードバックを受けてランク付けしたものをまとめたもので、左から右へ最も重要と回答があったものから順に並んでいます。
Score ranking

Conclusions

このアンケート結果を基にしてJava EE 8提案を見直し、実装上の考慮事項について、追加でレビューしました。その結果、以下のように結論付けました。
  • REST (JAX-RS 2.1) と HTTP/2 (Servlet 4.0) の2つは、アンケートの結果最も重要なテクノロジーということがわかりました。この2つとJSON-Bで、上位6個のテクノロジーの3個を占めています。Java EE 8向けのこれらのテクノロジーの新しいAPIの多くが既に完成しています。これらのテクノロジー、および関連するJSON-Pアップデートを使いJava EE 8をできるだけ早く提供することは大きな価値があります。
  • CDI 2.0、Bean Validation 2.0、JSF 2.3は直接的に調査しませんでしたが、これらのテクノロジーは大幅に進歩しており、Java EE 8に含められる予定です。
  • アンケート結果に基づき、OAuth と OpenID Connect に対するJava EE標準の作成を加速することを検討しました。これはJava EE 8のタイムフレームでは実現できないでしょうが、引き続きJava EE 8のSecurity 1.0の作業を進めていきます。
  • JavaOneで、ConfigurationとHealth CheckingをJava EE 8に加える提案をしたところ、アンケート結果では高いランクに位置づけられています。しかしながら、更なるレビューの結果、この取り組みのスコープはJava EE 8の提供全体を遅らせる可能性があるため、Java EE 8をできる限り速やかに完成させるためには、これらのテクノロジーをJava EEに含めることを延期するのが最善であると結論づけました。
  • Management、JMS、MVCはアンケート結果では優先度が高くないという評価でした。このランキングはJava EE 8からのこれらの領域の新しいAPIを取り下げるという我々の提案を補強するものです。したがってManagement 2.0 (JSR 373)、 JMS 2.1 (JSR 368) を取り下げることにしました。MVCについては、JSR 371をスタンドアロン・コンポーネントとして完成させるため、別のコミュニティメンバーもしくは組織に移転する可能性を検討中です。

こうした結果にあわせ、Java EE 8提案を改定しようとしています。下表はOracleの当初のJava EE 8提案と改訂したJava EE 8提案を、特に新規API開発に焦点を絞ってまとめたものです。


Next Steps

上記アンケート結果と実装上の考慮事項を基に、改訂されたJava EE 8提案を進めていきます。Java EE 8に関する更なるフィードバックをお寄せになる場合は、まだプロジェクトメンバーでない場合はプロジェクトに参加していただいた上で、更に議論するためにメーリングリストに投稿してください。

[Cloud] Sales CloudにProcess Cloud Serviceの画面を埋め込む

$
0
0
このエントリは、JPOUG Advent Calendar 2016の12月23日分です。
JPOUG Advent Calendar 2016
https://jpoug.doorkeeper.jp/events/53797
昨日は@mutatsuさんでした。
分割読み込みでフラッシュバック問合せの利用
https://mutatsu.wordpress.com/2016/12/22/%E5%88%86%E5%89%B2%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E3%81%A7%E3%83%95%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A5%E3%83%90%E3%83%83%E3%82%AF%E5%95%8F%E5%90%88%E3%81%9B%E3%81%AE%E5%88%A9%E7%94%A8/
今年は仕事色の薄い内容を書きたかったのですが、色々ありまして、「OracleのSaaSとPaaSを組み合わせる」という、昨年に引き続き非常に仕事色の濃いエントリでございます……。

ユースケースと要求事項

見積作成にあたり値引き率が高い場合、その値引率に対し上長から承認を得る必要がある、という業務上のルールは多くの企業で存在します。商談を管理するシステムであれば、そういった要求に対応するため、基本的な承認ワークフロー機能を有していることがほとんどです。ところが、20%までは上長の承認不要、20~40%は1段(直接の上長のみ)、40~60%までは2段、それ以上は3段、4段…といった具合に、値引き率に応じて承認階層を増やす仕組みまで備わっていることは少ないようです。
こういった多段階承認の要求を実現する場合、別の汎用ワークフロー製品を組み合わせることがよくありますが、今度は、以下のような要求が出てきます。
  • 承認申請をあげるために別システムのUIを開き、コピー&ペーストするなんて論外でしょ
  • 情報転記を自動化できたとしても、やはり明示的に別システムにログインするのではなく、ワークフローのUIが組み込まれていて欲しいなぁ
  • ワークフロー製品とのために別のIDを使ってログインしたくないので、Single Sign-onは必須ですな
このような要求事項を解決するにはどうすればよいでしょうか。

今回利用するもの

今回は、Oracle Sales CloudとOracle Process Cloud Service (PCS) を組み合わせた例をご紹介します。PCSで作成した承認申請アプリケーションの開始フォームを、Oracle Sales CloudのUIに埋め込み、Sales Cloudのデータを初期値としてPCSのUIに設定できれば、要求事項は解決できそうに見えます。具体的には、以下のような感じです。
  • Sales Cloudの営業>商談に新しいタブを追加する
  • 当該タブにPCSで作成したアプリケーションのUIを埋め込む
  • タブをクリックすると、Sales Cloudのデータを初期値として利用したPCSの開始フォームが開く
その前に、PCSとSales Cloudについて…。

Oracle Process Cloud Service (PCS)って?

Oracle Cloud Platformの一つのサービスで、クラウド上で利用可能なBPM (Business Process Management) ツールです。PCSはワークフローに必要な機能だけでなく、ビジネスルール機能も備えています。そのため、先ほどのユースケースのように、ビジネスルールを使って値引率に応じて承認階層を算定したり、値引き率が低い場合には上長の承認無しでプロセスを進めたり、といった判断のロジックをプロセスに埋め込まずに、後から変更できるよう外出しすることができます。
PCSの詳細は以下のURLからどうぞ。ただ、Java Cloud ServiceやDatabase Cloud Serviceと異なり、試使用のリクエストはWebページからできませんので、ご所望の方は、貴社担当の日本オラクルの営業にお問合せください。
Process Cloud Service
http://cloud.oracle.com/ja_JP/process

Oracle Sales Cloudって?

今風に言えば、Customer Experienceの向上を支援するためのSaaSです。昔風に言えば、顧客管理・営業支援のアプリケーションです。
Sales Cloud
https://cloud.oracle.com/ja_JP/sales-cloud

    Single sign-onはどうやって実現する?

    PCSとSales Cloudが同一アイデンティティドメインに所属していれば、同じユーザーID、パスワードでアクセスできます。さらに、Federated Single Sing-On使えば、オンプレミスで使っているLDAP、例えばActive Directoryに登録されたユーザーとパスワードでアクセスできます。Federated Single Sing-Onに関しては、詳しくは以下のドキュメントをご覧ください。
    Oracle Sales Cloud Securing Oracle Sales Cloud Release 11
    Implementing Federated Single Sign-On
    https://docs.oracle.com/cloud/latest/salescs_gs/OSCUS/OSCUS1728626.htm#OSCUS1728626

    Oracle® Cloud Using Oracle Process Cloud Service 16.4.5
    Configuring Federated SSO and Authentication
    https://docs.oracle.com/cloud/latest/process_gs/CPRCW/GUID-02911F68-A3E1-4E69-A1F5-06E65FB936F0.htm#CPRCW-GUID-02911F68-A3E1-4E69-A1F5-06E65FB936F0

    PCSで実施しておくこと

    まず、アプリケーションを作成します。今回は、単純にSales CloudにUIを貼り付けられればよいので、以下のようなプロセスにしています。


    実際に運用する場合は、UIからプロセスを開始し、値引き率で承認階層を判定、結果を起票者に通知するとともに、承認されたものについては、Sales Cloudの情報を更新するようなアプリケーションにする必要があるでしょう。


    フォームは、今回はシンプルにSales CloudのOpportunity IDとOpportunity Nameを表示するだけにしていますが、実際に利用するなら、Sales Cloudの情報を色々表示することになるでしょう。


    Sales CloudにUIを埋め込むためには、PCSのEmbeddable Process UI Componentsを使います。
    Oracle® Cloud Using Oracle Process Cloud Service 16.4.5
    Embedding Process UI Components in Other Applications
    http://docs.oracle.com/cloud/latest/process_gs/CPRCW/GUID-66587F65-C081-4961-BE92-6B1766586C14.htm#CPRCW-GUID-66587F65-C081-4961-BE92-6B1766586C14
    IFRAMEで取り出すためのコンポーネントがあるので、今回はそれを使います。URLは以下のようです。
    https://{PCSのURL}/bpm/components/pages/startform.html
    例えば、こんな感じです。
    https://process-xxxx.process.yyy.oraclecloud.com/bpm/components/pages/startform.html
    JSON形式でパラメータを設定すると、起動対象のPCSアプリケーションを指定することができます。以下はその例です(見やすくするため改行を入れていますが、実際には当然ながら1行で指定します)。
    https://process-xxxx.process.yyy.oraclecloud.com/bpm/components/pages/startform.html?startformData=
    {
      "processDefId":"default~Application!1.0~Process",
      "serviceName":"Process.service",
      "processName":"Process",
      "title":"てすと",
      "operation":"start",
      "startType":"START_PCS_FORM",
      "isDocsEnabled":true
    }
    [注意]
    ここで出てくるstartTypeには、旧来のBasic FormであればSTART_FORMを、新しいWeb Formの場合は、START_PCS_FORMを指定する必要があります。
    processDefId、serviceName、processName、operationなどは、以下のPCSのREST APIを使って取得した結果を設定します。
    REST API for Oracle Process Cloud Service
    Retrieve Process Definitions
    http://docs.oracle.com/cloud/latest/process_gs/CPRRA/op-process-definitions-get.html
    以下は取得結果の例です。
    {
    "levels": 0,
    "links": [
    {
    "href": "https://process-xxxx.process.yyy.oraclecloud.com/bpm/api/3.0/process-definitions",
    "length": 0,
    "rel": "self"
    },
    {
    "href": "https://process-xxxx.process.yyy.oraclecloud.com/bpm/api/3.0/",
    "length": 0,
    "rel": "parent"
    }
    ],
    "items": [
    {
    "processDefId": "default~Application!1.0~Process",
    "processName": "Process",
    "application": "default",
    "revision": "1.0",
    "domain": "default",
    "interfaces": [
    {
    "title": "Start from OSC(1.0)",
    "serviceName": "Process.service",
    "operation": "start",
    "startType": "START_PCS_FORM",
    "category": "",
    "args": [
    {
    "name": "formArg",
    "type": "{http://xmlns.oracle.com/bpm/forms/schemas/DemoForm}DemoForm",
    "location": "https://process-xxxx.process.yyy.oraclecloud.com/soa-infra/services/default/Application!1.0*soa_ad130b2e-fdf1-403f-9f88-552345f0e06b/forms/schemas/DemoForm.xsd",
    "schema": null,
    "primitive": false
    }
    ],
    "formMetadata": "webform://appId=;formId=;oId=;service=Process.service;operation=start;dn=default/Application!1.0*soa_ad130b2e-fdf1-403f-9f88-552345f0e06b/Process;formName=DemoForm;ns=http://xmlns.oracle.com/bpmn/bpmnCloudProcess/Application/Process;href=https://process-xxxx.process.yyy.oraclecloud.com/bpm/api/3.0/webforms/default~Application!1.0~Process~80a9e329-9f29-4052-9f38-fc5856a21ca1~a0d16f69-77e8-4431-97a6-97b5015d9100"
    }
    ],
    "processIcon": {
    "initials": "A",
    "colorCode": "rgb(197,182,79)"
    },
    "isDocsEnabledFlag": true,
    "isConversationEnabledFlag": false
    }
    ]
    }
    開始フォームに初期値を設定するためには、startform.htmlのパラメータとして、payloadを付けます。今回の場合は、opportunityIDとnameというテキストフィールドに初期値を設定するため、以下のような感じです(見やすくするため改行を入れていますが、実際には当然ながら1行で指定します)。
    https://process-xxxx.process.yyy.oraclecloud.com/bpm/components/pages/startform.html?startformData=
    {
      "processDefId":"default~Application!1.0~Process",
      "serviceName":"Process.service",
      "processName":"Process",
      "title":"てすと",
      "operation":"start",
      "startType":"START_PCS_FORM",
      "isDocsEnabled":true
    }
    &payload=
    {
      "opportunityID":"300000130602218",
      "name":"なまえ"
    }
    [注意]
    この開始フォームに初期値を設定する方法は、Web Formでのみ利用可能で、Basic Formでは使えません。

    できあがったら、アプリケーションをデプロイしておきます。

    Sales Cloudで実施しておくこと

    Sales Cloudには、サンドボックスという機能があり、これを使うと実運用中のサービスに影響を与えずに、カスタマイズの実施および動作確認することができます(もちろんカスタマイズが完了後、そのカスタマイズ内容を公開することもできます)。今回はサンドボックス環境で動作確認しています。
    カスタマイズのライフサイクルについては、以下のドキュメントをご覧ください。
    Oracle Sales Cloud Customizing Sales Release 11
    Customization Life Cycle
    https://docs.oracle.com/cloud/latest/salescs_gs/OACEX/OACEX1607004.htm#OACEX1607004
    ページにタブを追加するといったカスタマイズ手順は、以下ドキュメントをご覧下さい。
    Oracle Sales Cloud Customizing Sales Release 11
    Extending Simplified Pages
    Working with Subtabs
    https://docs.oracle.com/cloud/latest/salescs_gs/OACEX/OACEX1078865.htm#OACEX1906352
    Sales Cloudの設定の肝は、WebコンテンツのURLです。
    URLとして、上記のEmbeddable Process UIのstartform.htmlを指定するわけですが、下図の[URL定義]>[スクリプトの編集]に文字列として指定します。つまり、ダブルクォートで囲む必要があります。そのため、必然的にJSONのダブルクォートはエスケープする必要があります。

    Sales Cloudからのデータを初期値として渡したいので、Opportunityオブジェクトの内部IDであるOpportunity ID (OptyId) と、Opportunity Name (Name) を使い、文字列を連結してURLを作成していきます。最終的なURL文字列は以下のようになります(見やすくするため改行を入れていますが、実際には当然ながら1行で指定します)。
    "https://process-xxxx.process.yyy.oraclecloud.com/bpm/components/pages/startform.html?startformData=
    {
      \"processDefId\":\"default~Application!1.0~Process\",
      \"serviceName\":\"Process.service\",
      \"processName\":\"Process\",
      \"title\":\"てすと\",
      \"operation\":\"start\",
      \"startType\":\"START_PCS_FORM\",
      \"isDocsEnabled\":true
    }
    &payload=
    {
      \"opportunityID\":\"" + OptyId.toString() + "\",
      \"name\":\"" + Name + "\"
    }"
    URLを指定後、設定を保存しておきます。

    動作確認

    [営業]>[商談]を開きます。


    任意の商談をクリックします。この例ではTecra Data Inc.をクリックしています。このTecra Data Inc.がOpportunityオブジェクトのOpportunity Nameに相当します。


    作成したSub Tabをクリックします。


    無事にPCSアプリケーションのフォームが開き、Sales CloudのUIに埋め込まれていることがわかります。初期値として、Tecra Data Inc.も確認できます。


    コードらしいコードをほとんど書かずにUIを埋め込むことができました。開発者の立場からすると、コードを書きたくなるのですが、要望が各ツールの標準機能で賄え、さくっと作ることが求められるのであれば、こういうしくみを積極的に使うのもありですね。

    明日12月24日は吉田もとたかさんです。
    Happy holidays and have a great weekend!

    [Java] Java EE—the Most Lightweight Enterprise Framework?

    $
    0
    0
    原文はこちら。
    https://community.oracle.com/docs/DOC-1008823

    Recommendations for ensuring a productive development process

    昔々、J2EE、特にアプリケーションサーバーは非常に肥大化しheavyweightと考えられていました。開発者がアプリケーション開発のためにその技術を使うのはかなり面倒で、落胆させるものでした。しかし、J2EEフレームワークからJava EEに名前が変わってから、この前提は正しいとは言えません。Java EEが他のエンタープライズ・フレームワークと比較してどうなのか、フレームワークが軽量であるといえる条件はいったい何なのでしょうか。

    テクノロジーを選択する際、重要な考慮点の一つは、開発プロセスにおける開発者の生産性です。エンジニアはユースケースの実装や収益を生み出す機能を実装することに最大限の時間を割きます。それが、企業がそのゴールへ向かうために必要だからです。

    選択されたテクノロジとメソッドは、開発者がビルド、テスト、およびデプロイ、さらにアプリケーションの設定、ビジネスユースケースに関係のない部分の実装、ビルド環境や外部依存関係の構成といった部分で必要な時間を最小限に抑える必要があります。しかしながら、利用可能なテクノロジーのうち、大部分はこういったことに対応していません。

    Why Standards?

    他のフレームワークと比較した場合、Java EEの最大のメリットの一つは、利用するAPIが標準化されていることです。標準化と聞くとうんざりさせられたり、あまりイノベーティブでないように見えますが、これらの標準を使うことにはいくつかの利点があります。

    Integration of Specifications

    Java EEの特定のAPI、例えばContexts and Dependency Injection (CDI)やJAX-RS、JSON Processing (JSR 353)、Bean ValidationといったAPIは、協調して動作し、シームレスに繋がっています。特にCDIはアプリケーション・コンポーネント間の「糊」として利用されます。この仕様には、以下のような言葉で記載されています。
    "If the container does support specification A and B, then A has to integrate and work well with B seamlessly."
    (コンテナが仕様AとBをサポートする場合、AはBと統合し、シームレスに動作する必要がある)
    例えば、JAX-RSはリクエストやレスポンス・エンティティとして利用されるJsonObjectのようなJSONP型をサポートします。そして、Validationが失敗した場合には正しいHTTPステータスコードを含めてBean Validation機能の呼び出しをサポートしています(Listing 1)。
    @Path("duke") 
    public class DukeResource {
    @GET
    public JsonObject getDuke() {
    return Json.createObjectBuilder()
    .add("name", "Duke")
    .build();
    }
    @POST
    public void create(@Valid @NotPlayedYet Game game) {
    // game object has been validated at this point
    }
    }
    Listing 1. JSONP and Bean Validation integration of JAX-RS

    JSONP型の利用はcontent-typeがapplication/jsonであることを暗示し、Validationに失敗した場合には、HTTPステータスコード400 Bad Request が送信されることでしょう。これは設定コードを一切書かなくても自動的にやってくれます。
    別の例として、CDIを使うと開発者が任意のBeanやユーザー定義オブジェクトをJava EE管理対象コンポーネントに対して@Injectを使って注入することができます。Listing 2は、別のCDI Managed Beanをすぐに使うBean Validation Validatorの例です。
    public class GameNotPlayedValidator implements ConstraintValidator<Notplayedyet, Game> {
    @Inject
    GameHistory history;
    public void initialize(NotPlayedYet constraint) {
    // no initialization needed
    }

    public boolean isValid(Game game, ConstraintValidatorContext context) {
    return !history.exists(game);
    }
    }
    Listing 2. CDI integration of bean validation

    統合は仕様の主要な側面で、統合があるおかげで直接的な開発者体験を実現します。開発者は統合や構成作業を実施するアプリケーションサーバーに任せることができ、そのおかげえアプリケーションの業務ロジックに集中することができるのです。

    Convention-over-Configuration Driven Development

    Java EEのconvention-over-configuration(設定より規約、以下CoC)ドリブンなアプローチゆえに、ほとんどの現実世界のアプリケーションはそれほど多くの設定は必要ありません。厄介なXMLディスクリプタの時代は終わりました。単純なJava EEアプリケーションの場合、XMLファイルは必要ありません。

    宣言的アノテーションのおかげで、アノテーションが付いたシンプルなPOLOがHTTPリクエスト(@Path)を処理したり、トランザクション、監視、インターセプタを含む、Enterprise JavaBeans (EJB) Bean(@Stateless)として機能します。こうしたアプローチはこれまでに様々なフレームワークで検証済みであり、Java EEで標準化されてきました。

    XMLディスクリプタは今でもデプロイ時の構成のために利用することができますが、 CoCは開発者の生産性を最大化することに有用です。

    External Dependencies

    デプロイメント・アーティファクトに付属する特別な依存関係がなくても動作する現実世界のエンタープライズプロジェクトはごくまれです。しかし、これらの依存関係が必要な理由は、主として、ロギングやエンティティマッピングフレームワークや、Apache CommonsやGoogle Guavaなどの一般的なライブラリなど、ユースケースではなく、テクノロジーによってもたらされます。

    Java EE 7、特にJava 8とともに利用する場合は、たいていのユースケースをカバーする機能を備えているので、他の依存関係を必要としません。標準状態で備えていないものは、最小限のコードで実現できます。例えば、CDIプロデューサによる注入可能な設定、インターセプタによるサーキットブレーカ(Adam Bienのオープンソースライブラリを見てください)、Java 8のLambdaやStreamsを使った洗練されたコレクション操作といったものです。

    もちろん、ここで車輪の再発明をしないことを主張することができますが、実際には、数行のカスタムコードを保存するためだけに、メガバイトの外部依存関係をデプロイメント・アーティファクトに含めることは意味がありません。

    最大の問題は直接導入された依存性ではなく、推移的な依存性であることを経験上わかっています。推移的な依存関係は、アプリケーションサーバー上の既存のライブラリのバージョンと衝突し、激しい競合を引き起こすことが多々あります。 最終的に、開発者はプロジェクトに小さな機能を実装するよりも、競合の管理に多くの時間を費やします。これは、主としてユースケースドリブンの依存関係ではなく、テクノロジードリブンの依存関係の場合に当てはまります。

    Listing 3は、Adam BienのJava EE 7 Essentials Archetypeにインスパイアされた、シンプルなJava EEプロジェクトのMaven POM(project object model)ファイルの例です。
    AdamBien/javaee7-essentials-archetype - A quickstart maven archetype for creating greenfield JavaEE 7 projects
    https://github.com/AdamBien/javaee7-essentials-archetype
    <project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
     <modelVersion>4.0.0</modelVersion>
     <groupId>com.sebastian-daschner</groupId>
     <artifactId>game-of-duke</artifactId>
     <version>1.0-SNAPSHOT</version>
     <packaging>war</packaging>

     <dependencies>
         <dependency>
              <groupId>javax</groupId>
              <artifactId>javaee-api</artifactId>
              <version>7.0</version>
              <scope>provided</scope>
         </dependency>
     </dependencies>

     <build>
         <finalName>game-of-duke</finalName>
     </build>

     <properties>
         <maven.compiler.source>1.8</maven.compiler.source>
         <maven.compiler.target>1.8</maven.compiler.target>
         <failOnMissingWebXml>false</failOnMissingWebXml>
         <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
         </properties>
    </project>
    Listing 3. Java EE 7 Maven POM file

    もちろん、アプリケーションによっては、ソフトウェアの目的を達成するために重要なライブラリの統合が必要な場合もありますが、それは、ビジネス要件によってこれらの依存関係を正当化されるべきです。 一般に、外部のライブラリを最小限に抑えるための時間と労力を節約することに多大な意味があります。


    テストに関する依存関係では、JUnit、Mockito、または場合によってはArquillianなどのライブラリは重要で包含されているため、別の話ではありますが、テストについても依存関係に注意を払うことは理にかなっています。

    Thin Deployment Artifacts

    アプリケーションサーバーはJava EE APIを認識しているため、デプロイメント・アーティファクトにそれらを含める必要はなく、ビジネスロジックのみを最小のグルーコードと横断的関心事(cross-cutting-concerns)と共に含めればよいのです。

    従って、ビルドプロセスでたくさんの依存関係をコピーする必要がないため、こうしたキロバイトサイズのアーティファクトは非常に短いビルド時間ですみます。これは各ビルドごとに数秒の差が発生する可能性があります。開発者とContinuous Integration (CI) サーバーが費やしている余分な時間を合計すると、かなりの差になります。より頻繁にプロジェクトをビルドすればするほど、その影響はますます大きくなります。特にContinuous Delivery (CD) シナリオでは影響が大きくなります。

    短いビルド時間に加えて、小さいサイズのデプロイメント・アーティファクトは公開とデプロイメントの時間を短縮します。実装が既にランタイムに含まれているため、可動部分は常に最小です。

    The Ideal Framework for Docker

    これこそがJava EEがDockerなどのコンテナテクノロジで使用されるべき、完璧なフレームワークである理由です。 Dockerイメージはレイヤー構造で、イメージが構築される際、ベースイメージにはすでにOS、Javaランタイム、およびアプリケーションが含まれています。 したがって、ビルドごとに追加されるのは、デプロイメント・アーティファクトの最後の1キロバイトの薄いレイヤーだけです。この構造のおかげで、各ビルド時だけでなく、イメージのバージョン化や出荷時においても、大量のWARまたはスタンドアロンJARを使うアプローチに比べて時間とストレージを節約します。

    どの段階でも、デプロイメント・アーティファクトが小さいサイズであれば、非常に高速で生産的なデプロイメント・パイプラインを可能にします。

    Modern Application Servers

    J2EEアプリケーションサーバーは、開始時間やデプロイメント時間、インストールサイズ、およびリソースフットプリントに関して、重量級ソフトウェアの実行形態でしたが、Java EEという新しい世界では、これはもはや真実ではありません。

    WildFly、Payara、WebSphere Liberty、Profile、TomEEなどの最新のJava EE 7アプリケーション・サーバーはすべて数秒で起動してデプロイできます。内部が包括的にモジュール化されているため、必要なコンポーネントだけをロードし、可能な限り迅速に薄いアプリケーション・アーティファクトをデプロイすることができます。

    昨今のインストールサイズとフットプリントは非常に合理的です。アプリケーションサーバーは単純なサーブレットコンテナほど多くのリソースを消費しませんが、本格的なJava EE機能を備えています。面白いことに、実行中のブラウザインスタンスのほうが、より多くのメモリを消費します。

    そうは言っても、コンテナやオンプレミスであっても、サーバー毎にアプリケーションを1個のみデプロイすることができ、それが合理的である場合があります。その "one application per application server per container"(コンテナ毎にアプリケーションサーバ1つに対し1個のアプリケーション)のアプローチを使うと、最新のマイクロサービス・アーキテクチャに対する非常に生産的で柔軟性のあるソリューションを得ることができます。

    Packaging

    パッケージングについては、もはやEARファイルを使用する理由はありません。単一の専用サーバー上にアプリケーション全体を配置する方法では、その環境にすべてのコンポーネントをインストールする必要があります。これにより、ビルドとデプロイメントの時間がさらに短縮されます。それに加えて、この方法はEARファイルが引き起こしがちなクラスローディング階層の問題も回避します。

    大部分のクラウドとマイクロサービスのデプロイメントでは、スタンドアロンのJARパッケージを使用します。これらのJARパッケージには、アプリケーションとランタイム実装の両方が含まれます。 Java EEの世界では、WildFly Swarm、Payara Micro、TomEE Embeddedなどのベンダー固有のツールチェーンを使用してこのアプローチを実現できます。

    しかしながら、上述の理由により、可能であればビジネスロジックをランタイムから分離することを強く推奨します。これはつまりアプリケーションのコードのみを含むWARファイルにアプリケーションをパッケージングする、ということです。

    私見ですが、スタンドアロンのJARファイルは、技術的な理由ではなく、企業の「政治的」な問題のために、インストールや操作のプロセスを制御できない場合に便利な回避策と考えます。この方法であれば、デプロイメント・アーティファクトに必要なものすべてをまとめ、必要とするJavaランタイムを使い、かなりの技術的ではない問題を回避することができます。

    Recommendation for a Productive Development Process

    エンタープライズプロジェクトで最も生産的なソリューションは以下のようなものです。One of the most productive solutions for enterprise projects is the following:
    • Java EE 7とJava 8を提供されたAPIのみと共に使う
    • JAX-RSリソースやJPAといった最小限の配管を伴う、ビジネスロジックのみを含むキロバイトサイズのWARファイルをビルドする
    • Dockerイメージの構築 - 構成済みのアプリケーションサーバを含むベースイメージにWARファイルのみを追加
    • コンテナを使ってアプリケーションをデプロイするCD (Continuous Delivery) パイプラインによってリリース

    Conclusion

    ”heavyweight Java EE”の時代は確かに終わりました。Java EEの傘に含まれるAPIは、生産性が高く、楽しめる開発者体験と、標準内でのシームレスな統合を提供します。特に、アプリケーションコードをランタイムから分離するアプローチは、迅速かつ生産的な開発プロセスを可能にします。

    いくつかのベンダーによって始まった新しいMicroProfileイニシアチブにより、今後、Java EEの必要なコンポーネントがさらに少なくなる可能があります。
    MicroProfile.io - Optimizing Enterprise Java for a microservices architecture
    https://microprofile.io/

    See Also

    About the Author

    Sebastian Daschner (@daschners) はフリーランスのJavaコンサルタント、ソフトウェア開発者、アーキテクトです。彼はプログラミングとJava EEに熱心で、JCPに参加し、JSR 370のExpert Groupに参加し、GitHubのさまざまなオープンソースプロジェクトをハッキングしています。彼は6年以上Javaに取り組んでいます。Java以外にも、LinuxやDockerなどのコンテナテクノロジのヘビーユーザーです。自分のブログやTwitterでコンピュータサイエンスの実践を伝えています。
    sebastiandaschner blog
    https://blog.sebastian-daschner.com/

    [Database] Password Resets No Longer Require a Thick Connection (OracleClient) in SQL Developer

    $
    0
    0
    原文はこちら。
    http://www.thatjeffsmith.com/archive/2017/01/password-resets-no-longer-require-a-thick-connection-oracle-client-in-sql-developer/

    (訳注)
    原文では4.2以後というような表現になっていますが、4.1.5で試したところ、特に問題なくパスワードリセットできます。JDBCドライバとDatabaseのバージョン依存ですね。

    Oracle Database 12c JDBCドライバのアップデートのおかげで、パスワードのアップデートがデータベースへの接続を確立した状態でなくても可能になりました。
    4.2 EA2以前のバージョンでは、接続済みであること、もしくはOracle Clientが利用可能になっている必要がありました。

    以前紹介したエントリは、このサイトで最も読まれたエントリの一つです。期限が切れたパスワードを有していて、以前のパスワードをリセットする必要があるユーザーがどれほどあるのかが想像できます。
    Resetting Your Oracle User Password with SQL Developer
    http://www.thatjeffsmith.com/archive/2012/11/resetting-your-oracle-user-password-with-sql-developer/
    以前のリリースでは、デスクトップ管理者は、SQL Developerを停止するだけでなく、互換性のあるOracle Clientをも配置する必要があり、しかもSQL Developerを構成する必要がありました。もちろん、ユーザーはDBAに電子メールでヘルプを依頼することもできますけれど。

    でも、もうそんなことは必要ありません。非常に簡単になりました。
    単に Version 4.2 (現時点ではEarly Adopter 2ですが、リリース後はGA版を使ってください)をインストールし、接続を右クリック、これだけです。

    Oracle Clientの構成は不要です。

    では、(接続で定義済みのユーザーに対する)パスワードをリセットするため、当該接続を右クリックしましょう。

    こんな感じのダイアログが現れますので、旧パスワードと新パスワードを入力します。

    正しく動作すれば、OKをクリックしてダイアログを閉じてください。うまく動作しない場合は、エラーメッセージを確認してください。

    (TIPS)
    操作時に、接続プロパティのパスワード文字列を自動的にアップデートします。そのため、データベースのパスワードを変更後、接続で設定したパスワードを変更する必要はありません(もちろん、パスワードを保存することを選択した場合に限ります)。

    Curious to what JDBC driver your connection is actually using?


    (WindowsやLinuxの場合は)F5を押して、SHOW JDBCと打ち込んでください。

    [Cloud] Microservices messaging on Oracle Cloud using Apache Kafka

    $
    0
    0
    原文はこちら。
    https://community.oracle.com/community/cloud_computing/oracle-cloud-developer-solutions/blog/2017/01/05/microservices-messaging-on-oracle-cloud-using-apache-kafka

    この記事は2部構成の第1部です。Oracle Cloud Platformと幅広く使われているオープンソーステクノロジーを組み合わせ、サンプルアプリケーション(ソースコードはこちら)を使って、マイクロサービス間を疎結合の非同期メッセージベースで連携する方法を紹介します。
    Cloud Developer Portal Solutions
    https://cloud.oracle.com/developer/solutions
    第1部では、以下の内容を取り扱います。
    • 個々のマイクロサービスの開発
    • 非同期メッセージングを利用した疎結合連携
    • Oracle Cloud Serviceのセットアップおよびデプロイ
    第2部ではマイクロサービスのスケールについて取り扱います。

    利用するコンポーネント

    Oracle Cloud

    以下のOracle Cloud Serviceを使います。

    Description
    Application Container CloudJava SEマイクロサービスをデプロイ可能な、スケーラブルなプラットフォーム
    Compute CloudKafka クラスタ (broker) をホストするために利用

    オープンソース

    以下のオープンソーステクノロジーを使ってサンプルアプリケーションを構築します。

    Description
    Apache KafkaスケーラブルなPub-Subメッセージハブ
    JerseyRESTおよびSSEサービスを実装するために利用。(プラガブル)ランタイム/コンテナとしてGrizzlyを利用
    Mavenassemblyプラグインとともに)標準のJavaビルドツールとして利用。

    Microservicesにおけるメッセージング

    マイクロサービスベースのシステムは複数のアプリケーション(サービス)から構成されており、これらのサービスは、通常システム全体の特殊な側面(ビジネスシナリオ)にフォーカスしています。個々のサービスは、相互に連携せず独立して機能することもできますが、実際のところサービスは孤立して機能することはできず、お互いに通信して仕事を終わらせる必要があります。マイクロサービス間の通信を実装する上で複数の戦略を使うことができ、同期 vs 非同期スタイル、コレオグラフィ vs オーケストレーション、REST(HTTP)vs メッセージングといったくくりで分類されることがよくあります。

    サンプルアプリケーションのアーキテクチャ

    この記事のサンプルアプリケーションのユースケースはシンプルで、ランダムに生成されたデータ(Producerマイクロサービス)を別のエンティティ(Consumerマイクロサービス)が受け取り、最終的にはリアルタイムでユーザーが確認できるようにします。


    第1部では、高可用性の設定を考慮しておらず、1個のKafkaノードです。つまり、Kafkaクラスタに1個のサーバのみ存在し、ProducerとConsumerマイクロサービス(両方とも1インスタンスのみ)をApplication Container Cloudにデプロイします。

    上図で図示されている個々のコンポーネントを見ていきましょう。

    Apache Kafka

    Apache Kafkaは、「メッセージングシステムまたは分散コミットログとして実装されたストリーミングプラットフォーム」として広く知られています。もっと簡単な説明があればいいのですが。
    • 基本
      KafkaはJVM上で動作するScalaで記述された、Publish-Subscribeベースのメッセージングシステムで、パブリッシャ(Publisher)がトピック(Topic)にデータを書き込み、コンシューマ(Consumer)がこれらのトピックをポーリングしてデータを取得します。
    • 分散指向
      コンポーネント(broker、パブリッシャ、コンシューマ)はスケールアウト可能なように設計されています。
    • マスタ・スレーブアーキテクチャ
      トピック内のデータはクラスタ内の複数ノード間に(レプリケーション・ファクタに基づいて)分散されます。1個のノードのみが特定データのマスタとして機能し、0個以上のノードがそのデータのコピーを持つ、つまりフォロワーとして動作することができます。
    • パーティション
      トピックはさらにパーティション(Partition)に分割され、各パーティションは基本的にデータ(Key-Valueのペア)を格納するコミット・ログ(commit log)として振る舞います。データは不変で、厳密に順序付け(オフセットが各データエントリに割り当てられます)された上で、(構成に基づいて)永続化され、ディスクに保持されます。
    • 適した領域
      Kafkaは大容量の高速なリアルタイムストリーミングデータの処理に適しています。
    • JMSではない
      JMSと似てはいますが違います。JMS仕様を実装したものではなく、JMSベースのソリューションを置き換えるようなものではありません。
    Kafka brokerはKafkaサーバプロセス(ノード)以外の何者でもありません。複数のノードで、分散された、フォールトトレラントおよび水平方向にスケール可能なメッセージハブとして機能するクラスタを構成することができます。

    Producerマイクロサービス

    Producerマイクロサービスは、Kafka Java APIとJersey (JAX-RS参照実装)を使います。リアルタイムデータのPub-Subパイプラインを紹介するため、このマイクロサービスはハイペースでサンプルイベントを発行します。

    サンプルデータ

    Producerが生成したデータをメトリックのモデルとします。今回は、特定のマシンのCPU使用率であり、単純なキーと値のペア(名前、使用率など)と見做すことができます。 以下はその例です(属性Partitionは無視してください)
    : Partition 0
    event: machine-2
    id: 19
    data: 14%

    : Partition 1
    event: machine-1
    id: 20
    data: 5%

    Consumerマイクロサービス

    このシステムの2個目のマイクロサービスです。Producerと同様に、JerseyとKafkaのJava (Consumer) APIを使っています。このサービスで利用しているJerseyコンポーネントの中で注目すべきは、Server Sent Eventsモジュールです。このモジュールを使うと、サンプルアプリケーションで必要なsubscribe-and-broadcastセマンティクスを実装が容易になります(詳細は後で説明します)。
    両マイクロサービスは個別のアプリケーションとしてApplication Container Cloud Serviceにデプロイされ、独立して管理、スケールすることができます。

    Oracle Compute CloudへのApache Kafkaの構築

    複数の方法でApache KafkaをOracle Compute Cloud (IaaS)上に構築できます。

    Oracle Cloud Marketplaceの利用

    マーケットプレイスのApache KafkaのBitnamiイメージを使います。詳細ドキュメントは以下のURLをご覧ください。
    Oracle® Cloud
    Using Oracle Compute Cloud Service (IaaS)
    Creating an Instance from Oracle Cloud Marketplace
    http://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-D7CE3F3E-CC1B-443B-BAF9-E0F6B4FD7762.htm#STCSG-GUID-D7CE3F3E-CC1B-443B-BAF9-E0F6B4FD7762


    Oracle Compute CloudのVMを使う

    お好みのOSが動作するCompute CloudのVMをプロビジョニングするところから始めましょう。以下のドキュメントが役にたつことでしょう。
    Oracle® Cloud
    Using Oracle Compute Cloud Service (IaaS)
    Workflow for Creating Your First Instance
    http://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-DD966FCF-624B-45A3-88AF-8EC123CCBCFC.htm#STCSG-GUID-DD966FCF-624B-45A3-88AF-8EC123CCBCFC

    VMへのSSHアクセスの有効化

    構成を進める上で、まずOracle Compute Cloud VMへのSSHアクセスを有効化(セキュリティポリシーやセキュリティルールを作成)する必要があります。Oracle LinuxやOracle SolarisベースのVMに対する手順はそれぞれ以下を確認してください。
    Oracle® Cloud
    Using Oracle Compute Cloud Service (IaaS)
    Accessing an Oracle Linux Instance Using SSH
    http://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-D947E2CC-0D4C-43F4-B2A9-A517037D6C11.htm#STCSG-GUID-D947E2CC-0D4C-43F4-B2A9-A517037D6C11
    Accessing an Oracle Solaris Instance Using SSH
    http://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-C72CC64D-73C7-4150-8B5A-EB39D7F72327.htm#STCSG-GUID-C72CC64D-73C7-4150-8B5A-EB39D7F72327


    VMへのKafkaのインストール

    このセクションではOracle LinuxベースのVMを前提としています。
    以下のコマンドを使います。
    sudo yum install java-1.8.0-openjdk
    sudo yum install wget
    mkdir -p ~/kafka-download
    wget "http://redrockdigimark.com/apachemirror/kafka/0.10.1.0/kafka_2.11-0.10.1.0.tgz" -O ~/kafka-download/kafka-binary.tgz
    mkdir -p ~/kafka-install && cd ~/kafka-install
    tar -xvzf ~/kafka-download/kafka-binary.tgz --strip 1

    Kafkaのリスナーポートをオープン

    Oracle Application Container Cloudにデプロイされたマイクロサービスのため、Kafka brokerサービスへのアクセス(今回の場合は9092/tcp)を許可する必要があります。以下のドキュメントにユースケースの形ですばらしいリファレンスが提供されています。
    Oracle® Cloud
    Using Oracle Compute Cloud Service (IaaS)
    Setting Up Firewalls and Opening Ports for a Sample Scenario
    http://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-DE568AAF-39CE-462C-B605-B96AE4036825.htm#OCSUG292 
    Security Applicationを作成し、プロトコルと対応するポートを指定します。詳細は以下のドキュメントをご覧ください。
    Oracle® Cloud
    Using Oracle Compute Cloud Service (IaaS)
    Creating a Security Application
    http://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-4B073EF2-0D7C-4AD8-A40A-585C4E2F938C.htm#OCSUG183


    先ほど作成したSecurity Applicationを参照し、Security Ruleを作成します。この設定で、(ルールで定義したように)パブリック・インターネットから9092/tcpへのトラフィックを(Security Application構成毎に)許可します。詳細は以下のドキュメントを参照してください。
    Oracle® Cloud
    Using Oracle Compute Cloud Service (IaaS)
    Creating a Security Rule
    http://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-630622EC-160B-4523-88AD-F7B46463A0BE.htm#GUID-A3BEB363-C262-4F1E-909D-AA73AF2D65C9


    以下のような構成になるはずです。


    Kafka brokerの構成

    Compute Cloud環境用にKafkaサーバのプロパティファイル(<KAFKA_INSTALL>/config/server.properties)中の以下の属性を編集します。

    Compute CloudインスタンスのパブリックDNS

    パブリックIPが140.44.88.200であれば、パブリックIPに対応するFQDNはoc-140-44-88-200.compute.oraclecloud.comになります。

    属性
    listenersPLAINTEXT://<oracle-compute-private-IP>:<kafka-listen-port>
    (例) PLAINTEXT://10.190.210.199:9092
    advertised.listenersPLAINTEXT://<oracle-compute-public-DNS>:<kafka-listen-port>
    (例) PLAINTEXT://oc-140-44-88-200.compute.oraclecloud.com:9092

    以下はserver.propertiesファイルのスナップショットです。


    KAFKA_INSTALL/bin/zookeeper-server-start.sh config/zookeeper.propertiesを実行して、Zookeeperを起動します。


    KAFKA_INSTALL/bin/kafka-server-start.sh config/server.propertiesを実行して、Kafka Brokerを起動します。


    Zookeeper起動前にKafka brokerを起動しないでください。

    ソリューション概要

    イベントフロー・シーケンス

    これらのコンポーネントが協調してどのようにユースケース全体をサポートするのかを説明します。

    ProducerがKafka brokerにイベントをPush


    Consumer側では…

    • アプリケーションはデータ取得のためKafka brokerをポーリングします(KafkaではPoll/Pullモデルが使われています。よく見られるPushモデルではありません)
    • (ブラウザやHTTPクライアントといった)クライアントはシンプルなHTTP GETリクエストを特定のURL(例:https://<acc-app-url>/metrics)に送信してイベントをサブスクライブします。アプリケーション内でイベントが発生したときにクライアントがイベントを取得するという、1回のサブスクライブ後、クライアントはいつでも切断することができます。


    非同期+疎結合
    Consumerがメトリックデータを生成します。あるConsumerがブラウザベースのクライアント用のリアルタイムフィードを利用可能にしますが、同じデータに関する異なるビジネスロジックが実装されている複数のConsumer(例えば、処理や分析用途のためにメトリックデータを永続データストアにプッシュする)が存在する可能性があります。

    Server Sent Events (SSE)について

    SSEは、HTTPとWebSocketの中間的なものです。クライアントは接続リクエストを送信し、接続が確立すると接続は開いたままになり、サーバからデータを引き続き受信できます。
    • これは、サーバーのポーリングを回避できるため、単一のリクエストごとにHTTPリクエスト/レスポンスを張る方式に比べて効率的です。
    • 全二重であるWebSocketとは異なります。具体的には、クライアントとサーバは、接続が確立された後はいつでもメッセージを交換することができるますが、SSEでは、クライアントはリクエストを1回だけ送信します。
    このモデルは、クライアントが接続してデータが到着するのを待つだけなので、今回のサンプルアプリケーションに適しています(サブスクリプションした後は、サーバーと対話する必要がないためです)。

    その他の着目すべきポイント
    • SSEはW3Cで正式な仕様です。
      Server-Sent Events
      W3C Working Draft 08 February 2011
      https://www.w3.org/TR/2011/WD-eventsource-20110208/
    • データに対する具体的なメディアタイプが定められています。
    • ほとんどのブラウザでJavaScript実装があります。

    スケーラビリティ

    高いスループットとパフォーマンスを維持するために、このシステムのすべての部分がステートレスで水平方向にスケール可能であることに注意する必要があります。第2部では、スケーラビリティの側面をさらに深く理解し、Application Container Cloud Serviceで簡単にスケールさせる方法について説明します。

    コード

    このセクションでは、このサンプルで使った両方のマイクロサービスのコードの概要と重要なポイントを紹介します。

    Producer マイクロサービス

    アプリケーションのブートストラップ、イベント生成などを処理するクラスで構成されています。
    ClassDetails
    ProducerBootstrap.javaアプリケーションのエントリポイント。
    Grizzlyコンテナを起動する。
    Producer.java専用スレッドで動作。
    イベント生成の中核ロジックを含む。
    ProducerManagerResource.javaproducerプロセスの開始・停止のためのHTTP(s)エンドポイントを公開。
    ProducerLifecycleManager.javaExecutorServiceを使いProducerスレッドを管理するロジックを実装(ProducerManagerResourceが内部で利用)。

    Consumer マイクロサービス

    ClassDetails
    ConsumerBootstrap.javaアプリケーションのエントリポイント。
    Grizzlyコンテナを起動してConsumerプロセスを呼び出す。
    Consumer.java専用スレッドで動作。
    イベント消費の中核ロジックを含む。
    ConsumerEventResource.javaエンドユーザーがイベント消費するためのHTTP(s)エンドポイントを公開。
    EventCoordinator.javaイベントサブスクリプションおよびブロードキャスティングを実装するためのJersey SSEBroadcasterのラッパー(ConsumerEventResourceが内部で利用)。

    以下の理由で、Jersey SSE Broadcaster を使っています。
    • クライアントの統計情報を追跡する
    • クライアント接続が切断されると自動的にサーバーリソースを破棄する
    • スレッドセーフである

    Oracle Application Container Cloudへのデプロイ

    ここまででアプリケーションについて情報を得たので、ビルド、パッケージング、デプロイについて見ていきます。

    まずソースコード (zipファイル) をダウンロードしてください。このエントリの最初(原文からダウンロードする場合は最後)にリンクがあります。

    Metadata files

    manifest.json: 

    このファイルはいじらずにそのまま使うことができます。

    deployment.json

    Kafka brokerに対応する環境変数が含まれています。値はデプロイ前にユーザーが埋めるためにプレースホルダーとして残してあります。
    {
        "environment": {
            "KAFKA_CLUSTER":"<as-configured-in-kafka-server-properties>"
        }
    }
    この値(Oracle Compute CloudインスタンスのパブリックDNSのFQDN)は、Kafkaの server.propertiesファイル中の属性 advertised.listeners で構成した値と一致する必要があります。

    metadataファイルの詳細は、以下のドキュメントをご覧ください。
    Oracle® Cloud Developing for Oracle Application Container Cloud Service
    Creating Metadata Files
    http://docs.oracle.com/en/cloud/paas/app-container-cloud/dvcjv/creating-meta-data-files.html

    Build & zip

    manifest.jsonファイルだけを使ってJARをビルドしてZipで圧縮し、クラウドにデプロイできるアーティファクトを生成します。

    Producerアプリケーション

    cd <download_dir>/producer // mavenプロジェクトの展開場所
    mvn clean install
    zip accs-kafka-producer.zip manifest.json target/accs-kafka-producer.jar //you can also use tar to create a tgz file

    Consumerアプリケーション

    cd <download_dir>/consumer //mavenプロジェクトの展開場所
    mvn clean install
    zip accs-kafka-consumer.zip manifest.json target/accs-kafka-consumer.jar

    アプリケーションのzipファイルをOracle Storage cloudへアップロード

    まずOracle Storage Cloudに先ほど作成したアプリケーションのZipファイルをアップロードした上で、後続の手順でそのZipファイルを参照していきます。以下は必要なcURLコマンドです。
    (まだ作成していない場合は)Oracle Storage Cloudにコンテナを作成する
    curl -i -X PUT -u <USER_ID>:<USER_PASSWORD> <STORAGE_CLOUD_CONTAINER_URL>  
    (例) curl -X PUT –u jdoe:foobar "https://domain007.storage.oraclecloud.com/v1/Storage-domain007/accs-kafka-consumer/"  
    Zipファイルをコンテナにアップロード(ZipファイルはStorage Cloudのオブジェクトにすぎません)
    curl -X PUT -u <USER_ID>:<USER_PASSWORD> <STORAGE_CLOUD_CONTAINER_URL> -T <zip_file> "<storage_cloud_object_URL>" //template
    (例) curl -X PUT –u jdoe:foobar -T accs-kafka-consumer.zip "https://domain007.storage.oraclecloud.com/v1/Storage-domain007/accs-kafka-consumer/accs-kafka-consumer.zip"
    Producerマイクロサービスについても同じ手順を繰り返してください。

    Application Container Cloudへのデプロイ

    Zipファイルのアップロードが完了したら、アプリケーションをデプロイするために利用するApplication Container Cloud REST APIを使って当該ZipファイルのOracle Storage Cloudにおけるパスを参照することができます。以下はREST APIを使うcURLコマンドの例です。
    curl -X POST -u joe@example.com:password \    
    -H "X-ID-TENANT-NAME:domain007" \    
    -H "Content-Type: multipart/form-data" -F "name=accs-kafka-consumer" \    
    -F "runtime=java" -F "subscription=Monthly" \    
    -F "deployment=@deployment.json" \    
    -F "archiveURL=accs-kafka-consumer/accs-kafka-consumer.zip" \    
    -F "notes=notes for deployment" \    
    https://apaas.oraclecloud.com/paas/service/apaas/api/v1.1/apps/domain007  
    Producerマイクロサービスについても同じ手順を繰り返してください。

    デプロイ後

    Container Cloudコンソ―ルのApplicationsセクションの下にマイクロサービスを確認できるはずです。


    特定のアプリケーションの詳細情報を見ると、環境変数も存在するはずです。

    アプリケーションのテスト

    Producer

    accs-kafka-producerマイクロサービスのために、Kafka Producerプロセス(スレッド)をユーザーが開始する必要があります(これは単に柔軟性を提供するためです)。下表に記載の適切なコマンドを(cURLPostmanなどを使って)発行し、Producerプロセスを管理します。

    ActionHTTP verbURI
    開始GEThttps://<ACCS-APP-URL>/producer
    (例)https://accs-kafka-producer-domain007.apaas.us.oraclecloud.com/producer
    停止DELETE上と同様

    Producerを開始した後は、停止するまでイベントを発行し続けます。

    Consumer

    accs-kafka-consumerマイクロサービスでは、Kafka Consumerプロセスはアプリケーションとともに起動します。つまりメトリック収集のためにKafka brokerへのポーリングを開始します。前述の通り、Consumerアプリケーションは、リアルタイムにメトリックデータを見るための(Server Sent Eventsを使った)HTTP(s)エンドポイントを提供しています。
    下図のようなリアルタイムデータストリームを確認できるはずです。属性eventはマシン名とID、属性dataはCPU使用率を表します。
    属性Partitionは無視してください。これはスケーラビリティや負荷分散といった第2部で説明予定です。


    参考資料

    第2部はまた後ほど。

    [Support] January 2017 Critical Patch Update Released

    $
    0
    0
    原文はこちら。
    https://blogs.oracle.com/security/entry/january_2017_critical_patch_update

    Oracleは本日2017年1月のCritical Patch Update (CPU) をリリースしました。
    Oracle Critical Patch Update Advisory - January 2017
    http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
    このCPUは、Oracle Database Server、Oracle Enterprise Manager Grid Control、Oracle E-Business Suite、Oracle Industry Applications、Oracle Fusion Middleware、Oracle Sun製品、Oracle Java SE、Oracle MySQLといった幅広い製品群の修正を提供するものです。
    OracleはこのCPUをできる限り速やかに適用されることを推奨します。このCPUのサマリおよび分析は以下のMy Oracle Supportのドキュメントに記載があります(My Oracle Supportのアカウントが必要です)。
    January 2017 Critical Patch Update: Executive Summary and Analysis (Doc ID 2220314.1)
    https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2220314.1

    [Java] Java SE 8 Update 121 and More

    $
    0
    0
    原文はこちら。
    https://blogs.oracle.com/java/java-se-8-update-121-and-more

    Java SE 8u121(Java SE 8 update 121)がご利用いただけるようになりました。
    Java SE Downloads
    http://www.oracle.com/technetwork/java/javase/downloads/index.html
    このアップデートには重要なセキュリティの修正が含まれているため、Java SEをご利用の方がアップグレードされることをOracleは強く推奨します。新機能やバグの修正に関する情報はこのリリースに含まれていますので、リリースノートをご覧ください。
    Java Development Kit 8 Update Release Notes
    http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html
    [注意]
    2017年4月18日(PDT)に予定しているCritical Patch Updateから、全てのバージョンのJREはMD5を使って署名されたJARは署名されていないものとして取り扱います。詳細とテスト方法については、以下のエントリをご覧下さい。
    Oracle JRE will no longer trust MD5-signed code by default
    https://blogs.oracle.com/java-platform-group/entry/oracle_jre_will_no_longer
    [Java, Security] Oracle JRE will no longer trust MD5-signed code by default
    https://orablogs-jp.blogspot.jp/2016/10/oracle-jre-will-no-longer-trust-md5.html
     Oracle Java SE Embedded Version 8 Update 121もご利用いただけるようになりました。
    Oracle Java SE Embedded Downloads
    http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/index.html
    JRECreateツールを使ってカスタマイズしたJREを作成できます。まずは、対象とするプラットフォームに適したeJDK バンドルをダウンロードした上で、以下のURLの手順に従い、アプリケーション要件に適うJREを作成してください。
    Java Platform, Standard Edition (Java SE) 8
    Oracle Java SE Embedded: Developer's Guide
    Create Your JRE with jrecreate
    http://docs.oracle.com/javase/8/embedded/develop-apps-platforms/jrecreate.htm#JEMAG270
    その他、Java SE 7u131、Java SE 6u141もリリースしましたが、これらは両方ともOracle Java SE Supportの範囲でご利用いただけます。これらのリリースに関する情報は、以下のリリースノートをご覧ください。
    Oracle Java SE Support
    http://www.oracle.com/us/technologies/java/standard-edition/support/overview/index.html
    Java™ SE Development Kit 7, Update 131 (JDK 7u131)
    http://www.oracle.com/technetwork/java/javaseproducts/documentation/javase7supportreleasenotes-1601161.html#R170_131
    Java™ SE Development Kit 6, Update 141 (JDK 6u141)
    http://www.oracle.com/technetwork/java/javase/overview-156328.html#R160_141

    [Java] JSON-P 1.1 (JSR 374) in Public Review

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

    JSON-P 1.1 (JSR 374) がPublic Previewという重要な期間に入りました。
    JSR 374: JavaTM API for JSON Processing 1.1
    https://jcp.org/en/jsr/detail?id=374
    このPublic Reviewは、Proposed Final Draftに至る前の最後のJCP マイルストンです。そのため、出来るだけ速く皆さんからのコメントを得ることが重要なのです。期限は2017年2月16日です。

    そんなわけですから、ぱっぱとフィードバックしてしまいましょう。ドラフト仕様をご覧になって、フィードバックをお寄せ下さい。
    JSR-000374 JavaTM API for JSON Processing 1.1
    https://jcp.org/aboutJava/communityprocess/pr/jsr374/index.html
    json-processing-spec usersメーリングリスト
    https://java.net/projects/json-processing-spec/lists/users/archive

    [Database] Default Changes SPFILE Parameters - Oracle 12.2

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

    Parameters in Oracle Database 12.2.0.1 - part 4 of the series:
    Royと筆者はデフォルトの各バージョンのパラメータ設定を比較しました。比較したものは、Oracle Database 11.2.0.4、Oracle Database 12.1.0.2、Oracle Database 12.2.0.1です。ある変化が極めて興味深いものです。当然ながらメモリドリブンのパラメータはこのリストからは除外しています。
    赤でマークしているものが、リリース間で違いがあるものです。
    データベースは全てOracle Linux 6.8のファイルシステム上に構成しています(ASMではありません)。従って、ASM上に構築した場合や他のOS上で構築した場合では、値が異なることがあります。
    ParameterOracle 11.2.0.4Oracle 12.1.0.2Oracle. 12.2.0.1
    audit_sys_operationsFALSETRUETRUE
    compatible11.2.0.412.1.0.2.012.2.0
    control_file_record_keep_time7730
    db_securefilePERMITTEDPREFERREDPREFERRED
    dml_locks61614162076
    filesystemio_optionsNONENONEsetall
    job_queue_processes100010004000
    object_cache_optimal_size10240010240010240000
    optimizer_features_enable11.2.0.412.1.0.212.2.0.1
    parallel_max_servers488080
    parallel_min_servers088
    parallel_servers_target643232
    parallel_adaptive_multi_userTRUETRUEFALSE
    pre_page_sgaFALSETRUETRUE
    resource_limitFALSETRUETRUE
    sec_max_failed_login_attempts1034
    sec_protocol_error_trace_actionCONTINUETRACELOG
    spatial_vector_accelerationFALSEFALSETRUE
    sql92_securityFALSEFALSETRUE

    [Database] Deprecated Parameters in Oracle Database 12.2.0.1

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

    Oracle Database 12.2.0.1のパラメータに関する一連のエントリの第3弾です。
    以下は、Oracle Database 12.2.0.1でDEPRECATED(廃止予定)とされているパラメータです。
    • O7_DICTIONARY_ACCESSIBILITY
    • active_instance_count
    • asm_preferred_read_failure_groups
    • background_dump_dest
    • buffer_pool_keep
    • buffer_pool_recycle
    • commit_write
    • cursor_space_for_time
    • db_block_buffers
    • fast_start_io_target
    • instance_groups
    • lock_name_space
    • log_archive_start
    • parallel_adaptive_multi_user
    • plsql_debug
    • plsql_v2_compatibility
    • rdbms_server_dn
    • remote_os_authent
    • resource_manager_cpu_allocation
    • sec_case_sensitive_logon
    • serial_reuse
    • sql_trace
    • standby_archive_dest
    • unified_audit_sga_queue_size
    • user_dump_dest
    • utl_file_dir
    太字のものは、Oracle Database 12.2.0.1で新たに廃止予定(DEPRECATED)とされたものです。それ以外は12.2.0.1以前に既に廃止予定とされているものです。
    V$PARAMETERISDEPRECATED列も確認してください。

    [Database] Obsolete SPFILE Parameters in Oracle Database 12.2.0.1

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

    このエントリは、Oracle Database 12.2.0.1のinit.ora/SPFILEパラメータに関する一連のエントリの第2弾です。
    廃止されたパラメータは159個です(これらはV$OBSOLETE_PARAMETERSにあります)。
    • _app_ctx_vers
    • _average_dirties_half_life
    • _aw_row_source_enabled
    • _compatible_no_recovery
    • _data_transfer_cache_size
    • _db_no_mount_lock
    • _dlm_send_timeout
    • _dtree_bintest_id
    • _dtree_compressbmp_enabled
    • _evolve_plan_baseline_report_level
    • _fast_start_instance_recovery_target
    • _fic_max_length
    • _fic_outofmem_candidates
    • _idl_conventional_index_maintenance
    • _kgl_latch_count
    • _kks_free_cursor_stat_pct
    • _kspptbl_mem_usage
    • _lm_direct_sends
    • _lm_multiple_receivers
    • _lm_rcv_buffer_size
    • _lm_statistics
    • _log_archive_buffer_size
    • _log_io_size
    • _max_log_write_io_parallelism
    • _module_action_old_length
    • _optimizer_adaptive_plans
    • _optimizer_choose_permutation
    • _oracle_trace_events
    • _oracle_trace_facility_version
    • _plan_verify_local_time_limit
    • _plsql_conditional_compilation
    • _px_async_getgranule
    • _px_slaves_share_cursors
    • _seq_process_cache_const
    • _spr_use_hash_table
    • _sqlexec_progression_cost
    • _use_hidden_partitions
    • _very_large_partitioned_table
    • allow_partial_sn_results
    • always_anti_join
    • always_semi_join
    • arch_io_slaves
    • b_tree_bitmap_plans
    • backup_disk_io_slaves
    • cache_size_threshold
    • cell_partition_large_extents
    • cleanup_rollback_entries
    • close_cached_open_cursors
    • complex_view_merging
    • db_block_checkpoint_batch
    • db_block_lru_extended_statistics
    • db_block_lru_latches
    • db_block_lru_statistics
    • db_block_max_dirty_target
    • db_file_simultaneous_writes
    • dblink_encrypt_login
    • ddl_wait_for_locks
    • delayed_logging_block_cleanouts
    • discrete_transactions_enabled
    • distributed_recovery_connection_hold_time
    • distributed_transactions
    • drs_start
    • enqueue_resources
    • exclude_seed_cdb_view
    • fast_full_scan_enabled
    • freeze_DB_for_fast_instance_recovery
    • gc_defer_time
    • gc_files_to_locks
    • gc_latches
    • gc_lck_procs
    • gc_releasable_locks
    • gc_rollback_locks
    • hash_join_enabled
    • hash_multiblock_io_count
    • instance_nodeset
    • job_queue_interval
    • job_queue_keep_connections
    • large_pool_min_alloc
    • lgwr_io_slaves
    • lm_locks
    • lm_procs
    • lm_procs
    • lm_ress
    • lock_sga_areas
    • log_block_checksum
    • log_files
    • log_parallelism
    • log_simultaneous_copies
    • log_small_entry_max_size
    • logmnr_max_persistent_sessions
    • max_commit_propagation_delay
    • max_rollback_segments
    • max_transaction_branches
    • mts_circuits
    • mts_dispatchers
    • mts_listener_address
    • mts_max_dispatchers
    • mts_max_servers
    • mts_multiple_listeners
    • mts_servers
    • mts_service
    • mts_sessions
    • ogms_home
    • ops_admin_group
    • ops_interconnects
    • optimizer_adaptive_features
    • optimizer_max_permutations
    • optimizer_percent_parallel
    • optimizer_search_limit
    • oracle_trace_collection_name
    • oracle_trace_collection_path
    • oracle_trace_collection_size
    • oracle_trace_enable
    • oracle_trace_facility_name
    • oracle_trace_facility_path
    • parallel_automatic_tuning
    • parallel_broadcast_enabled
    • parallel_default_max_instances
    • parallel_degree_level
    • parallel_io_cap_enabled
    • parallel_min_message_pool
    • parallel_server
    • parallel_server_idle_time
    • parallel_server_instances
    • parallel_transaction_resource_timeout
    • partition_view_enabled
    • plsql_compiler_flags
    • plsql_native_c_compiler
    • plsql_native_library_dir
    • plsql_native_library_subdir_count
    • plsql_native_linker
    • plsql_native_make_file_name
    • plsql_native_make_utility
    • push_join_predicate
    • remote_archive_enable
    • row_cache_cursors
    • row_locking
    • sequence_cache_entries
    • sequence_cache_hash_buckets
    • serializable
    • shared_pool_reserved_min_alloc
    • snapshot_refresh_interval
    • snapshot_refresh_keep_connections
    • snapshot_refresh_processes
    • sort_direct_writes
    • sort_multiblock_read_count
    • sort_read_fac
    • sort_spacemap_size
    • sort_write_buffer_size
    • sort_write_buffers
    • spin_count
    • sql_version
    • standby_preserves_names
    • temporary_table_locks
    • text_enable
    • transaction_auditing
    • undo_suppress_errors
    • use_indirect_data_buffers
    • use_ism

    [Database] New SPFILE parameters in Oracle Database 12.2.0.1

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

    Oracle Database 12.2.0.1はOracle Cloudでご利用いただけます。
    そして、このリストは、Oracle Database 12.1.0.2と比較して新しいinit.ora/spfileのパラメータ46個をまとめたものです。これには可能な限りOracle Database 12.2リファレンスのドキュメントへのリンクを含めています。
    パラメータリンク説明
    allow_global_dblinks英語
    日本語
    データベース・リンクのLDAP参照をデータベースに許可するかどうか
    allow_group_access_to_sga英語
    日本語
    UNIXプラットフォームで共有メモリーへのgroupアクセスを制御
    approx_for_aggregation英語
    日本語
    集計問合せのための正確な問合せ処理を近似問合せ処理に置き換え
    approx_for_count_distinct英語
    日本語
    COUNT (DISTINCT expr)問合せを自動的にAPPROX_COUNT_DISTINCT問合せに置き換え
    approx_for_percentile英語
    日本語
    完全パーセンタイル関数をそれに対応する近似パーセンタイル関数に変換
    asm_io_processes英語
    日本語
    Oracle ASMのIOServerインスタンスで開始されるI/Oワーカー・プロセスの数を指定
    autotask_max_active_pdbs英語
    日本語
    PDBの最大値を指定し、同時に自動メンテナンス・タスクをスケジュール可能
    awr_pdb_autoflush_enabled英語
    日本語
    CDB内のすべてのPDBまたはCDB内の個々のPDBに対して、自動ワークロード・リポジトリ(AWR) のスナップショットを有効にするか無効にするかを指定
    cdb_cluster記載無しTRUEの場合、CDBクラスタモードで起動
    cdb_cluster_name記載無しCDBクラスタ名
    clonedb_dir英語
    日本語
    CloneDBビットマップ・ファイルを作成し、アクセスされるディレクトリ・パスを設定
    containers_parallel_degree英語
    日本語
    containers()を含む問合せの並列度を制御する。containers_parallel_degreeの値を設定した場合、containers()問合せのデフォルトのDOPをオーバーライドする。
    cursor_invalidation英語
    日本語
    DDL文のデフォルトで、遅延カーソル無効化を使用するか、即時カーソル無効化を使用するかを制御
    data_guard_sync_latency英語
    日本語
    Oracle Data Guardの同期REDO転送モード接続で、最初のレスポンス以降のログ・ライター(LGWR)プロセスの待機秒数を制御
    data_transfer_cache_size英語
    日本語
    RMAN RECOVER...NONLOGGED BLOCKコマンドの実行中にインスタンスによって消費されるデータ・ブロックの受信(通常はOracle Data Guard環境のプライマリ・データベースから)に使用されるデータ転送キャッシュのサイズ(バイト)
    default_sharing英語
    日本語
    アプリケーション・ルートにオブジェクトを作成する文の共有句の値
    disable_pdb_feature記載無しPDB機能の無効化
    enable_automatic_maintenance_pdb英語
    日本語
    CDB内のすべてのPDBまたはCDB内の個別のPDBに対して、自動メンテナンス・タスクの実行を制御
    enable_dnfs_dispatcher英語
    日本語
    Oracle Direct NFSクライアントのディスパッチャ・サポートを有効化
    enabled_PDBs_on_standby英語
    日本語
    Oracle Data Guardスタンバイ・データベースでレプリケートするプラガブル・データベース(PDB)リスト
    encrypt_new_tablespaces英語
    日本語
    新しく作成されたユーザー表領域を暗号化するかどうかを指定
    exafusion_enabled英語
    日本語
    Exafusion高速化キャッシュ・フュージョン・プロトコル機能を制御
    external_keystore_credential_location英語
    日本語
    TDEキーストアの資格証明を格納した外部キーストアの場所
    inmemory_adg_enabled英語
    日本語
    インメモリー・キャッシュ・サイズに加え、Active Data Guardのインメモリーが有効かどうかを指定
    inmemory_expressions_usage英語
    日本語
    どのインメモリー式(IM式)をインメモリー列ストア(IM列ストア)に移入して、問合せで使用可能にするかを制御
    inmemory_virtual_columns英語
    日本語
    どのユーザー定義仮想列がインメモリー仮想列(IM列)として格納されるかを制御
    instance_abort_delay_time英語
    日本語
    致命的なプロセスの異常終了や回復不能なインスタンス・エラーの発生時など、内部で起動されたインスタンスの中止までの遅延時間(秒)を指定
    instance_mode英語
    日本語
    インスタンスがread-write、read-only、read-mostlyのいずれかを示す
    long_module_action英語
    日本語
    より長い長さをモジュールおよびアクションに使用可能にする
    # Oracle Database 12cリリース2 (12.2.0.1)より前のOracle Databaseリリースでは、モジュールの長さは48バイトで、アクションの長さは32バイト
    max_datapump_jobs_per_pdb英語
    日本語
    PDBごとの同時Oracle Data Pumpジョブの最大数
    max_idle_time英語
    日本語
    セッションがアイドル状態にしておける最大分数
    max_iops英語
    日本語
    1つのプラガブル・データベース(PDB)に対して、1秒当たりに発行できるI/Oの最大数
    max_mbps英語
    日本語
    1つのプラガブル・データベース(PDB)に対して、1秒当たりに発行できるI/Oの最大数(MB)
    max_pdbs英語
    日本語
    CDBまたはアプリケーション・ルートで作成可能なプラガブル・データベース(PDB)数の制限
    ofs_threads英語
    日本語
    Oracleファイル・システムのリクエストに対するサービスを開始できるOracleファイル・システム(OFS)スレッドの最大数
    one_step_plugin_for_pdb_with_tde記載無しTDE暗号化データを持つPDBのための1ステッププラグインを容易にする
    optimizer_adaptive_plans英語
    日本語
    適応可能なプラン(adaptive plans)を制御
    optimizer_adaptive_statistics英語
    日本語
    適応統計(adaptive statistics)を制御
    outbound_dblink_protocols英語
    日本語
    データベース内のアウトバウンド・データベース・リンク用の通信に許可されたネットワーク・プロトコル
    remote_recovery_file_dest英語
    日本語
    プラガブル・データベース(PDB)のリフレッシュ操作中にソースが使用できない場合に、アーカイブ・ログ・ファイルの読取り元となるディレクトリ
    resource_manage_goldengate英語
    日本語
    データベース内でのOracle GoldenGate適用プロセスが管理対象のリソースかどうかを判定
    sga_min_size英語
    日本語
    プラガブル・データベース(PDB)に保証されたSGAサイズ
    shrd_dupl_table_refresh_rate英語
    日本語
    重複した表のリフレッシュ・レート(秒)
    standby_db_preserve_states英語
    日本語
    読取り可能なフィジカル・スタンバイ・データベースをプライマリ・データベースに変換するときに、インスタンスのユーザー・セッションおよびその他の内部状態を保持するかどうかを制御
    target_pdbs記載無しCDBの属性を調整するためのヒント
    uniform_log_timestamp_format英語
    日本語
    Oracle Databaseトレース(.trc)ファイルで共通タイムスタンプ書式を使用することを指定

    [Database] Having fun with PDB LOCKDOWN PROFILES

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

    Oracle Database 12.2(現時点ではOracle Database Cloud Serviceでご利用いただけます)には、PDBロックダウンプロファイルと呼ばれる新機能があります。実のところ、このパラメータはOracle Database 12.1.0.2に存在してはいたもののドキュメントに記載がなく、機能しませんでした。
    New (some undocumented) Parameters in Oracle 12.1.0.2
    https://blogs.oracle.com/UPGRADE/entry/new_undocumented_parameters_in_oracle

    PDB Lockdown Profiles

    PDB Lockdown Profilesは、主に高度に共有された環境でデータベースを使用しながらもセキュリティを必要とする場合に、アクセスの制限や有効化を細かく制御する方法です。このアイデアは、グラントの上に制限を埋め込む、すなわち特定のグラントを取り除く、というものです。たとえば、ALTER SYSTEMを実行しているときに、特定のPDBにログインしたユーザーのみに対しoptimizer_modeおよびcursor_sharingパラメータを変更できるように許可することができます。
    データベース概要の用語集のページには以下のような説明があります。
    A security mechanism to restrict operations that are available to local users connected to a specified PDB.
    指定されたPDBに接続中のローカル・ユーザーが使用可能な操作を制限するためのセキュリティ・メカニズム
    概要はConcept Guideに、詳細はSecurity Guideに記載があります。
    Oracle® Database Concepts 12c Release 2 (12.2)
    Overview of PDB Lockdown Profiles
    http://docs.oracle.com/database/122/CNCPT/overview-of-the-multitenant-architecture.htm#CNCPT-GUID-1F6D3E4F-786A-47A0-A36C-83BAB75FCDAE
    Oracle® Database概要 12cリリース2 (12.2)
    PDBロックダウン・プロファイルの概要
    http://docs.oracle.com/cd/E82638_01/CNCPT/overview-of-the-multitenant-architecture.htm#GUID-1F6D3E4F-786A-47A0-A36C-83BAB75FCDAE
    Oracle® Database Security Guide 12c Release 2 (12.2)
    Using PDB Lockdown Profiles to Restrict Operations on PDBs
    http://docs.oracle.com/database/122/DBSEG/configuring-privilege-and-role-authorization.htm#DBSEG-GUID-AB5E62DB-7E2A-4B5A-BA96-A2BD2DF15275
    Oracle® Databaseセキュリティ・ガイド 12cリリース2 (12.2)
    PDBロックダウン・プロファイルを使用したPDBでの操作の制限
    http://docs.oracle.com/cd/E82638_01/DBSEG/configuring-privilege-and-role-authorization.htm#GUID-AB5E62DB-7E2A-4B5A-BA96-A2BD2DF15275

    How-to-Lockdown-Profile

    新規作成したPDBを使って始めます。
    SQL> create pluggable database PDB2 admin user adm identified by adm file_name_convert=('/oradata/CDB2/pdbseed', '/oradata/CDB2/pdb2');
    まず、ロックダウンプロファイルを作成する必要があります。
    SQL> create lockdown profile P1;
    続いて、プロファイルを変更し、ALTER SYSTEMを使ってoptimizer_modeとcursor_sharingだけを変更できるようにします。
    SQL> alter lockdown profile P1 disable statement=('ALTER SYSTEM') clause=('SET') OPTION ALL EXCEPT=('optimizer_mode','cursor_sharing');
    最後に、PDBロックダウンプロファイルを有効化する必要があります。
    SQL> alter system set PDB_LOCKDOWN=P1;
    確認しましょう。
    SQL> show parameter pdb_l

    NAME          TYPE    VALUE
    ------------- ------- ------
    pdb_lockdown  string  P1

    Where the fun begins ...

    では、デフォルトのSYSユーザーで接続しましょう。定義により、SYSは共通ユーザーです。PDB2に切り替えます。
    $> sqlplus / as sysdba

    SQL> alter session set container=PDB2;

    SQL> alter system set sql_trace=TRUE;
    *
    ERROR at line 1:
    ORA-01031: insufficient privileges
    ほう。では、試してみましょう。
    SQL> alter system set cursor_sharing='FORCE';
    System altered.

    SQL> alter system set optimizer_mode='FIRST_ROWS_10';
    System altered.
    OK、動きましたね。でもまだSQL_TRACEをセッションレベルで変更できるでしょうか?もちろんできます。
    SQL> alter session set SQL_TRACE=TRUE;
    Session altered.
    ALTER SYSTEM だけを制限したのであって、ALTER SESSIONを制限してはいませんから、理に適っていますね。
    では、同様にこちらもやってみましょう。
    SQL> alter session set container=cdb$root;
    Session altered.

    SQL> alter lockdown profile P1 disable statement=('ALTER SESSION') clause=('SET') OPTION ALL EXCEPT=('optimizer_mode','cursor_sharing')
    Lockdown Profile altered.
    ドキュメントにはこんな例があります。
    CREATE LOCKDOWN PROFILE medium;
    ALTER LOCKDOWN PROFILE medium DISABLE STATEMENT=('ALTER SYSTEM');
    ALTER LOCKDOWN PROFILE medium ENABLE STATEMENT=('ALTER SYSTEM') CLAUSE=('FLUSH SHARED POOL');
    Oracle® Database Concepts 12c Release 2 (12.2)
    Example 19-6 Creating a PDB Lockdown Profile
    http://docs.oracle.com/database/122/CNCPT/overview-of-the-multitenant-architecture.htm#CNCPT-GUID-B964031E-8ACE-4603-8F1E-DD173BE5BA01
    Oracle® Database概要 12cリリース2 (12.2)
    例19-6 PDBロックダウン・プロファイルの作成
    http://docs.oracle.com/cd/E82638_01/CNCPT/overview-of-the-multitenant-architecture.htm#GUID-1F6D3E4F-786A-47A0-A36C-83BAB75FCDAE__GUID-AD907A15-AC08-4765-AE35-EFF48AE4014E
    これはALTER SYSTEMを使う場合、ALTER SYSTEM  FLUSH SHARED POOLコマンドのみを許可します。
    SQL> alter system set pdb_lockdown='MEDIUM';
      alter system set pdb_lockdown='MEDIUM'
    *
    ERROR at line 1:
    ORA-01031: insufficient privileges

    SQL> alter system set sql_trace=true;
    alter system set sql_trace=true
    *
    ERROR at line 1:
    ORA-01031: insufficient privileges
    もちろん、既存のプロファイルに追加して、特定の機能を無効化することもできます。
    SQL> alter session set container=cdb$root;
    Session altered.

    SQL> ALTER LOCKDOWN PROFILE medium DISABLE FEATURE=('XDB_PROTOCOLS');
    Lockdown Profile altered

    Which profiles do exist and what's defined?

    まず第1に、PDB_LOCKDOWNパラメータはPDBレベルで変更可能です。つまりこれは異なるPDBごとに異なるプロファイルを持つことができます。しかしテストした限りでは、PDBで1個のプロファイルのみがアクティブで有効化することはできません。

    既存のプロファイルとその内容を検索できるでしょうか。
    SQL>  select profile_name, rule_type, rule, clause, clause_option, status from DBA_LOCKDOWN_PROFILES order by 1;
    PROFILE_NAME   RULE_TYPE  RULE           CLAUSE     CLAUSE_OPTION   STATUS
    -------------- ---------- -------------- ---------- --------------- -------
    MEDIUM         STATEMENT  ALTER SYSTEM                              DISABLE
    MEDIUM         FEATURE    XDB_PROTOCOLS                             DISABLE
    P1             STATEMENT  ALTER SESSION  SET        CURSOR_SHARING  ENABLE
    P1             STATEMENT  ALTER SYSTEM   SET        OPTIMIZER_MODE  ENABLE
    P1             STATEMENT  ALTER SYSTEM   SET        CURSOR_SHARING  ENABLE
    P1             STATEMENT  ALTER SESSION  SET        OPTIMIZER_MODE  ENABLE
    P1             STATEMENT  ALTER SESSION  SET                        DISABLE
    P1             STATEMENT  ALTER SYSTEM   SET                        DISABLE
    PRIVATE_DBAAS                                                       EMPTY
    PUBLIC_DBAAS                                                        EMPTY
    SAAS                                                                EMPTY

    11 rows selected.

    Summary

    これは非常に強力な機能ですが、将来的には、特定のことがうまく動かない理由を調べるのが難しいかもしれません。ORA-1031のエラーが、常に正しいガイドをしてくれるでしょう。

    ちょっと困るところ
    常に物事を簡素化し、管理を容易にすることについて話していますが、PDB Lockdown Profilesを使うと、非常に物事が複雑になり得ますし、同僚を苛立たせる可能性があります(しないでくださいね)。 あまり物事を複雑にしないでくださいね。


    [Database] Release Dates Oracle Database 12.2.0.1 on-prem - Extended Support Waiving for Oracle 11.2.0.4 / 12.1.0.2

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

    (原文執筆時点での)昨晩最も重要なMOS Note: 742060.1がアップデートされ、オンプレミス版Oracle Database 12.2.0.1のリリース予定日が追加されました。
    さらに、Oracle Database 11.2.0.4および12.1.0.2の Waived Extended Support(無償Extended Support)の日付も延長されました。

    詳細は以下のURLをご覧ください。
    Release Schedule of Current Database Releases (Doc ID 742060.1)
    https://support.oracle.com/rs?type=doc&id=742060.1
    要約すると、
    • Exadata および SuperCluster 向けOracle Database 12.2.0.1 はまもなくリリースされる予定
    • Exadata/SuperCluster 向けOracle Database 12.2.0.1がリリースされた後、Intel Linux x86(訳注:原文ではx86と記載していますが、当然ながらx86-64です)およびSolarisプラットフォーム(SPARC、Intelとも) 向けOracle Database 12.2.0.1がリリースされる予定(詳細の日付は、先ほどのMy Oracle Supportのドキュメントをご覧ください)
    • Oracle Database 11.2.0.4の無償Extended Support期間が2018年12月末まで延長(これまでは2017年5月末が期限でした)
    • Oracle Database 12.1.0.2の無償Extended Support期間は2019年7月末日まで
    Oracle 12.2 12.1 11.2.0.4 Release Map

    [Java] JAX-RS 2.1 Reactive Client API

    $
    0
    0
    原文はこちら。
    https://blogs.oracle.com/PavelBucek/entry/jax_rs_2_1_reactive

    Marekに代わって、JAX-RSの共同Spec leadに選ばれたことを発表できうれしく思っています。ってわけで、この先数ヶ月間、おおよそJavaOne 2017までの間に関するエントリを記載します。

    様々な仕様における議論をフォローしているのであれば、昨年のJAX-RSの議論は非常に閑散としたものだったことにお気づきかもしれません。しかし、変わりつつあります。いや、既に変わりました。Expert Group (EG) はアップデートされたスケジュールで、主として以下の3件について作業をしています。
    • Reactive Client API
    • Server Sent Events
    • Non-blocking I/O
    最初の2件は、既に提案済みではあるものの、まだExpert Groupから祝福されてはいませんでした。そのため、(必要であれば)アップデートし、レビューの上、そのコメントを反映する必要がありますが、実際にReactive Client APIで発生しましたので、このエントリではその内容をまとめます。

    JAX-RS Reactive Client API

    まず、この機能の目的は、クライアント側でのリアクティブスタイルのプログラミングのサポートを含めることであって、それ以外のことはありません。また、別のクライアントを作成したくはありません。既存のものは既に同期および非同期のリクエスト実行をサポートしており、これをリアクションスタイルで拡張したいと考えています。
    簡単な例を見てみましょう。
    CompletionStage<Response> csResponse = ClientBuilder.newClient()
     .target("http://oracle.com")
    .request()
    .rx()
    .get();
    何か新しいものがあることに気付かれたことでしょう。戻り型がjavax.ws.rs.Responseでも、(rx()がasync()に置き換えられた場合には)Future <Response>でもなく、Client fluent API呼び出しチェーンにある新しいメソッド、rx()です。
    javax.ws.rs.Response
    http://docs.oracle.com/javaee/7/api/javax/ws/rs/core/Response.html 
    CompletionStageは、Java 8で導入された新しいインターフェースです。これはプラットフォームに組み込まれた唯一のリアクティブ標準です(詳細は後で)。今回、rx() メソッドが追加されたことにより、SyncInvoker/AsyncInvokerから、新しいRxInvokerに切り替えることができるようになりました。
    Interface SyncInvoker
    https://docs.oracle.com/javaee/7/api/javax/ws/rs/client/SyncInvoker.html
    Interface AsyncInvoker
    https://docs.oracle.com/javaee/7/api/javax/ws/rs/client/AsyncInvoker.html
    RxInvokerは他のメソッドと同じメソッドを定義しますが、同じ方法で指定された戻り値の型は持ちません。CompletionStageRxInvokerという、現在提案中のAPIで実施しているように、CompletionStageに対してサブクラスを作成し、再定義することができます。
    CompletionStageRxInvoker.java
    https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/javax/ws/rs/client/CompletionStageRxInvoker.java
    rx() メソッドにはいくつかのバリエーションがあります。1つはExecutorServiceの提供に関連し、もう1つはRxInvokerクラスの提供に関するものです。
    ExecutorService
    https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ExecutorService.html 
    前者は簡単に説明ができます。つまり、リアクティブな呼び出しは本質的に非同期であって、スレッドプールやExecutorServiceを指定できるようにしたい、ということです(例えば、後で再度呼び出されたり、クライアント全体にわたる非同期executorサービス構成を許可することによって削除されたりする可能性があります)。後者は拡張性に関するものです。

    Reactive Extensions

    リアクティブなアプリケーションをJavaで実装する場合、さまざまなフレームワークが提供する他のデータ型を知っていることがほとんどでしょう。Guava、RxJavaなどといった、これらのフレームワークは、CompletionStageと同様の機能を提供しますが、APIが異なります。特に、他の非標準フレームワークを使って作成されたアプリケーションを有していて、JAX-RSができるだけ簡単に使用できるようにしたい場合は、これらを使用すると便利です。 コード例を見てみましょう。
    Client client = ClientBuilder.newClient();
    client.register(FlowableProvider.class);

    Flowable<Response> csResponse = client.target("http://oracle.com")
    .request()
    .rx(FlowableInvoker.class)
    .get();
    ここで、JAX-RSのResponseを取得する際に、RxJava2のFlowableを利用できることがわかります。
    Flowable
    http://reactivex.io/RxJava/2.x/javadoc/io/reactivex/Flowable.html 
    FlowableProvider、FlowableInvokerとも、第三者が提供しています。たとえば、RxJava2の開発者コミュニティのJAX-RSが十分に重要と考える場合、これらのクラスを含む拡張モジュールがリリースされる可能性があります。また、いつものように、任意のJAX-RS実装は機能を選択でき、同様のプロバイダを実装の一部として提供することができます。
    変更される可能性があるため、詳細に入ることは避けますが、現時点では、これが拡張性の提供に関する最善の方法であるとの結論に達したようです。議論の経緯を知りたい方は、JAX-RS仕様のExpert Groupメーリングリストをご覧ください。

    新たに提案されたAPIを気に入ってもらえることを願っています。何かコメントがありましたら、JAX-RSプロジェクトのユーザーメーリングリストに投稿してください。

    Links, mailing lists, etc.

    [Docker] MONDAY SPOTLIGHT:Announcing the Oracle Container Registry

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

    Oracle Container Registryの一般提供を発表できうれしく思います。Container RegistryはOracle製品をDockerコンテナで使う上でシンプルにアクセスできるようにデザインされています。
    Oracle Container Registryから利用できる製品は以下の通りです。
    • Oracle Linux 7、6、5
    • Oracle JDK 8 (Server JRE)
    • Oracle WebLogic Server 12、Tuxedo、CoherenceおよびFusion Middleware Web Tier
    • Oracle Database 12c Standard Edition 2およびEnterprise Edition
    • MySQL 5.7 Community Edition
    Oracleは今後、製品を追加してリストを拡張していく予定です。
    現時点では、Oracle Container RegistryへのアクセスはUS、UK、オーストラリアのお客様に限定しています。

    How do I login to the Oracle Container Registry?

    ブラウザで以下のURLを開きます。
    Oracle Container Registry
    https://container-registry.oracle.com
    初めてこのサイトを訪れる場合、お持ちのOracle SSO資格証明との関連付けもしくは新規アカウントを作成する必要があります。[Register]をクリックして、以下のいずれかを選択します。
    • [I Already Have an Oracle Single Sign On Account] (既にOracle Single Sign Onアカウントを持っている)ため、既存のアカウントと関連付ける 
    • [I Don't Have an Oracle Single Sign On Account] (Oracle Single Sign Onアカウントを持っていない)ため、アカウントを新規作成する
    アカウントを作成、もしくは既存アカウントとの関連付けが済めば、ログインボタンをクリックしてContainer Registryにログインします。ライセンス契約条項を読んで受諾するよう表示が出てきます。Dockerコマンドラインツールを使ってイメージをダウンロードする際には、ライセンス契約条項を受け入れる必要があること、ライセンス契約条項の受諾は8時間のみ保持されることにご注意ください。
    ライセンス契約条項を受け入れた後、利用可能な製品カテゴリや、Dockerクライアントを使ってレジストリからPullする対象のイメージをチェックすることができます。

    How do I pull images using the Docker client?

    Web画面でライセンスを受諾すれば、Dockerクライアントを使ってログインし、イメージをPullできます。
    まず、docker loginコマンドを使ってContainer Registryにログインします。
    $ docker login container-registry.oracle.com
    Web画面で登録し、ライセンス契約条項を受け入れた際に利用したOracle SSO資格証明と同じものを使う必要があります。ログインに成功すると、イメージをPullできます。
    $ docker pull container-registry.oracle.com/java/serverjre
    各イメージにはドキュメントがあり、Container RegistryのWeb画面で確認できます。

    How do I store images locally?

    ローカルのDockerレジストリを配備して、Oracle Container Registryとローカルで作成および拡張されたイメージの両方を格納することを推奨します。これにより、インターネット経由で毎回ダウンロードせずに、ローカルでサーバーにイメージを配信できます。
    Oracle Linux Docker User Guideには、ローカル・レジストリの設定方法が記載されています。
    Oracle® Linux Docker User's Guide
    http://docs.oracle.com/cd/E52668_01/E75728/html/index.html

    How do I adapt and extend these images?

    Oracleは、お客様やユーザーがOracle製品をDockerコンテナ内で触ってみる上で便利な方法を提供する目的で、これらのイメージを提供しています。
    しかしながら、Oracle Docker Images GitHubリポジトリも提供しております。こちらには、基本製品のDockerfilesだけでなく、これらのイメージを拡張し、各製品のカスタムコンテナを作成するためのサンプルが含まれています。
    Official source for Docker configurations, images, and examples of Dockerfiles for Oracle products and projects
    https://github.com/oracle/docker-images
    このGitHubリポジトリファイルを使って再作成したり、オンプレミスの要件に合わせてベースイメージを適合させることもできます。

    Support

    DockerのサポートはOracle Linux BasicもしくはPremier Support Subscriptionsをお持ちのお客様であれば追加費用は必要ありません。
    有償サポートをご契約でない場合は、Oracle Communityフォーラムでピア・サポート(Peer Support:同じような立場の人からの支援)を受けることができます。
    Oracle Community Forum
    https://community.oracle.com/

    [Java] Java EE 8 - January recap

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

    1月はJava EE 8にとって慌ただしい月でした。直近で起こったアクティビティを簡単にまとめてみます。

    JSF 2.3、JSON-P 1.1、CDI 2.0がPublic Draft状態になっています。それぞれのPublic Draft期間が終了するまでにこれら3個の仕様をチェックし、フィードバックすることが重要です。
    JSRPublic Previewの期間
    JSR 372: JavaServer Faces (JSF 2.3) Specification
    https://jcp.org/en/jsr/detail?id=372
    2017/1/23 - 2017/2/21
    JSR 374: JavaTM API for JSON Processing 1.1
    https://jcp.org/en/jsr/detail?id=374
    2017/1/17 - 2017/2/16
    JSR 365: Contexts and Dependency Injection for JavaTM 2.0
    https://jcp.org/en/jsr/detail?id=365
    2017/1/31 - 2017/3/2

    JAX-RSについて言うと、3個のJAX-RS 2.1の高価な機能のうち2個、すなわちReactive Client APIとServer-sent Eventsのサポートに関する完全な提案ができたことで、かなりの進捗がありました。
    JAX-RS 2.1 Reactive Client API
    https://blogs.oracle.com/PavelBucek/entry/jax_rs_2_1_reactive
    https://orablogs-jp.blogspot.jp/2017/01/jax-rs-21-reactive-client-api.html
    [jax-rs-spec users] Server-Sent Events API proposal
    https://java.net/projects/jax-rs-spec/lists/users/archive/2017-01/message/142 
    Non Blocking I/Oプロバイダは3番目の高価な機能で、引き続きJAX-RS Expert Groupで議論されているはずです。
    JAX-RS Expert Group Mailing List Archive
    https://java.net/projects/jax-rs-spec/lists/users/archive
    JSR 380のSpec LeadであるGunnar Morlingは、Bean Validation 2.0の進捗について、間もなくEarly Draft Reviewを予定しているとのことです。この間、Draftの進捗状況を常に確認することができます。
    JSR 380: Bean Validation 2.0
    https://jcp.org/en/jsr/detail?id=380
    Bean Validation 2.0 Progress Report
    http://beanvalidation.org/news/2017/01/19/bean-validation-2-0-progress-report/
    Bean Validation 2.0 specification - WORK IN PROGRESS
    http://beanvalidation.org/latest-draft/spec/
    Servlet 4 Expert Groupでも作業が進んでいます。HTTP/2 (例:Server Push)の技術的実装の詳細のいくつかが現在議論されているということです。
    Servlet Specification : Users Mailing List
    https://java.net/projects/servlet-spec/lists/users/archive
    さらに、Security JSR (JSR-375) についての議論が今後数多く見られると思われます。
    Java EE Security API Specification : Expert Group Mailing List
    https://java.net/projects/javaee-security-spec/lists/jsr375-experts/archive/2017-01/
    最後に、MVCの仕様策定をコミュニティ主導に移転する件に対する投票が終了し、承認されました。つまり、ペーパーワークを進めることができるようになったということです。そして、Ivar Grimstadはまもなく正式に新しいMVC仕様のリードになるはずです。
    JSR #371 Model-View-Controller (MVC 1.0) Specification Transfer Ballot
    https://jcp.org/en/jsr/results?id=5907
    JSR 371: Model-View-Controller (MVC 1.0) Specification
    https://jcp.org/en/jsr/detail?id=371 
    具体的には、4個のJava EE 8仕様がPublic Draft(JSON-B 1.0、JSON-P 1.0、JSF 2.3、CDI 2.0)の状態にあります。それゆえ、仕様に関与し、テストし、これらの仕様に対するフィードバックを出すのにいいタイミングです。コントリビュートの出発点として、先日JCPが実施したAdopt A JSRのWebcastをご覧になるのをお奨めします。
    Adopt-a-JSR for Java EE
    http://linkis.com/www.youtube.com/2mnrm 
    まだまだ早期の段階ではありますが、Java EE 8参照実装(Reference Implementation)、つまりGlassFish 5に関わるアクティビティの復活を確認できます。
    glassfish - Java.net JIRA
    https://java.net/jira/browse/GLASSFISH/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
    その点で、Java.net終了のことを、明確かつ十分に意識しています。Java.netの終了によって、Java EE、つまりJava EEに関連するJSRやGlassFishを含むさまざまなRIに影響を与えないように努めており、できるだけ早くより具体的な詳細を共有する予定です。

    [Database] Dealing with very very long string lists using Database 12.2

    $
    0
    0
    原文はこちら。
    https://blogs.oracle.com/datawarehousing/entry/dealing_with_very_very_long

    Oracle Database 11gR2で、文字列値を取り扱うLISTAGG関数が導入されました。これは、行のグループから値を集計し、値が通常コンマまたはセミコロンで区切られた連結文字列を戻すために利用できます。また、独自の区切り記号を指定すれば、コード内でこれを判別できます。

    さまざまなフォーラムやブログの投稿から、開発者に広く使用されているようです。しかし、多くの人が強調してきた重要な問題が1つあります。非常に大きな文字列を含むデータセットに対してLISTAGGを使用すると、長すぎるリストを作成する可能性があります。これにより、次のようなオーバーフローエラーが発生します。
    ORA-01489: result of string concatenation is too long
    ORA-01489: 文字列を連結した結果、長さが最大長を超えました
    開発者やDBAにとってさらに面倒なことに、指定されたLISTAGG measure_expr内の値を連結するとORA-01489エラーが発生するかどうかを事前に判断することは非常に難しいため、(筆者自身を含め)多くの人がこの問題を解決するための回避策を提示しています。おそらく最も洗練されたシンプルなソリューションは、12cのMATCH_RECOGNIZE機能を使用することですが、これは12c Release 1を必要とするため、すべてのDBAや開発者が常に利用できるわけではありません。
    問題を再現したい場合、そしてサンプルのSHスキーマにアクセスできる場合は、次のクエリを実行してみてください。
    SELECT 
    g.country_region,
    LISTAGG(c.cust_first_name||''||c.cust_last_name, ',') WITHIN GROUP (ORDER BY c.country_id) AS Customer
    FROM customers c, countries g
    WHERE g.country_id = c.country_id
    GROUP BY country_region
    ORDER BY country_region;
    この記事のすべてのサンプルは、サンプルのSHスキーマを使用しています。オンプレミス版のOracle Database 12c Release 2がリリースされると、OTNのデータベース・ホーム・ページから、ご使用のプラットフォーム用のサンプル・ファイルをダウンロードできるようになるはずです。筆者はLiveSQL上ですぐに使えるチュートリアルがあるのですが、現在非常に長い文字列を使用する上で技術的な問題が発生しています(LISTAGGワークショップを実行すると 'Data out of range'エラーが発生する)。問題を解決次第、このブログの記事を更新し、このチュートリアルへのリンクを追加します。
    Oracle Live SQL
    https://livesql.oracle.com/apex/livesql/file/index.html

    What have we changed in 12.2?

    ORA-01489エラーを解決する方法の一つは、単純にVARCHAR2オブジェクトのサイズを増やすことです。

    Larger object sizes

    VARCHAR2 オブジェクトの最大サイズはDatabaseのパラメータMAX_STRING_SIZEで決まります。以下のコマンドを使って環境の設定を確認できます。
    show parameter MAX_STRING_SIZE
    筆者のデモ環境では、以下のような結果が返ってきます。
    NAME            TYPE   VALUE 
    --------------- ------ --------
    max_string_size string STANDARD
    Oracle RDBMS 12.1.0.2以前では、 VARCHAR2 のサイズの上限は4Kでしたが、Oracle RDBMS 12.1.0.2でこの制限が拡大され、32Kになりました。この拡大によって、多くの問題が解決する可能性がありますが、DatabaseのパラメータMAX_STRING_SIZEを変更する必要があります。MAX_STRING_SIZE = EXTENDEDを指定すると、新たに32767 バイトを上限に設定変更できます。
    ALTER SYSTEM SET max_string_size=extended SCOPE= SPFILE;
    しかし、ビッグデータ・ソースへの関心が高まるにつれ、大規模なデータ・セットに対する問合せでLISTAGG機能を使用した場合に、エラーORA-01489の可能性が依然高いことは明らかです。必要なのは、LISTAGG関数内の構文がもっと豊富に提供されることですが、これは、Database 12c Release 2の一部として実装されています。

    Better list management

    12cR2では、文字列サイズの大きさゆえにエラーが発生しそうなリストの管理がより簡単になりました。利用可能な新しいキーワードをご紹介しましょう。
    • ON OVERFLOW ERROR
    • ON OVERFLOW TRUNCATE
    • WITH COUNT vs. WITHOUT COUNT
    これらの機能のそれぞれをもうちょっと深掘りしてみましょう。

    1. Keeping Pre-12.2 functionality
    文字列長が長すぎた場合に既存コードで引き続きエラーを返したい場合、すばらしいことに、これがデフォルトの挙動です。 LISTAGG 文字列の長さが VARCHAR2 の制限を超えた場合、標準的なエラーが返ります。
    ERROR at line xxx:
    ORA-01489: result of string concatenation is too long
    ORA-01489: 文字列を連結した結果、長さが最大長を超えました
    しかしながら、可能であれば、オーバーフロー発生時にエラーが発生することを完全に明確にするため、LISTAGGコードに "ON OVERFLOW ERROR"を追加することをお勧めします。
    SELECT 
    g.country_region,
    LISTAGG(c.cust_first_name||’ ‘||c.cust_last_name, ‘,' ON OVERFLOW ERROR) WITHIN GROUP (ORDER BY c.country_id) AS Customer
    FROM customers c, countries g
    WHERE g.country_id = c.country_id
    GROUP BY country_region
    ORDER BY country_region;
    デフォルトでは、truncation(切り詰め)機能は無効化されており、エラーの発生を抑止したい場合には既存コードを変更する必要があることに注意することが重要です。

    2. New ON OVERFLOW TRUNCATE… keywords
    4Kもしくは32Kの境界で値のリストを切り詰めたい場合には、新規追加されたキーワードON OVERFLOW TRUNCATEを使う必要があります。以下はその例です。
    SELECT 
    g.country_region,
    LISTAGG(c.cust_first_name||’ ‘||c.cust_last_name, ‘,' ON OVERFLOW TRUNCATE) WITHIN GROUP (ORDER BY c.country_id) AS Customer
    FROM customers c, countries g
    WHERE g.country_id = c.country_id
    GROUP BY country_region
    ORDER BY country_region;
    切り詰めが発生すると、完全な値が切り詰められ、その時点でリストが切り捨てられたことをユーザーに示す方法を制御できます。 デフォルトでは、切り詰めが発生したことを示すインジケータとして3つのドット '...'を文字列に追加しますが、これを次のようにオーバーライドすることができます。
    SELECT 
    g.country_region,
    LISTAGG(c.cust_first_name||''||c.cust_last_name, ',' ON OVERFLOW TRUNCATE ‘***') WITHIN GROUP (ORDER BY c.country_id) AS Customer
    FROM customers c, countries g
    WHERE g.country_id = c.country_id
    GROUP BY country_region
    ORDER BY country_region;
    文字列長が超過した際、12.2以前の既存の挙動のままエラーを返したい場合は、デフォルトの挙動に従うか、もしくはキーワードを使って明示的にエラーを返すことを宣言することができます(個人的には、デフォルトの挙動に依存しないほうがよいと考えています)。
    SELECT 
    g.country_region,
    LISTAGG(c.cust_first_name||''||c.cust_last_name, ',' ON OVERFLOW ERROR) WITHIN GROUP (ORDER BY c.country_id) AS Customer
    FROM customers c, countries g
    WHERE g.country_id = c.country_id
    GROUP BY country_region
    ORDER BY country_region;
    この場合、通常のエラーメッセージを生成します。つまり、12.2以前の挙動のままです。
    ORA-01489: result of string concatenation is too long
    01489. 00000 - "result of string concatenation is too long"
    *Cause: String concatenation result is more than the maximum size.
    *Action: Make sure that the result is less than the maximum size.
    もちろん、新しいキーワードを省略しても同じ挙動になります。
    SELECT 
    g.country_region,
    LISTAGG(c.cust_first_name||’ ‘||c.cust_last_name, ‘,') WITHIN GROUP (ORDER BY c.country_id) AS Customer
    FROM customers c, countries g
    WHERE g.country_id = c.country_id
    GROUP BY country_region
    ORDER BY country_region;
    以前と同様、この場合も通常のエラーメッセージを生成するので、12.2以前の挙動と同じです。
    ORA-01489: result of string concatenation is too long
    01489. 00000 - "result of string concatenation is too long"
    *Cause: String concatenation result is more than the maximum size.
    *Action: Make sure that the result is less than the maximum size.

    3. How many values are missing?
    利用可能な領域に収まるようにリストから削除された値の個数を知る必要がある場合は、キーワード 'WITH COUNT'を使用できます。切り捨てられた文字列の最後に削除された値の個数が不要の場合、キーワード 'WITHOUT COUNT'を使用することができます。デフォルトの挙動は'WITHOUT COUNT'です。
    SELECT 
    g.country_region,
    LISTAGG(c.cust_first_name||''||c.cust_last_name, ',' ON OVERFLOW TRUNCATE'***' WITH COUNT) WITHIN GROUP (ORDER BY c.country_id) AS Customer
    FROM customers c, countries g
    WHERE g.country_id = c.country_id
    GROUP BY country_region
    ORDER BY country_region;
    4. Do we split values when truncation occurs? (切り詰めが発生した場合に値は分割されるのか?)
    いいえ、切り捨てを強制する場所を決定する際には、各値の全長を考慮に入れます。したがって、各国内の顧客名リスト作成時にLISTAGGを使用する場合、顧客のフルネームであるKeith Laker(ファーストネーム + ラストネーム)が常に含まれます。 完全な文字列(ファーストネーム + ラストネーム)をリストに追加するのに十分なスペースがなければ、文字列全体、 "Keith Laker"が削除され、切り捨てインジケータが挿入されます。 ラストネームが切り捨てもしくは削除された場合、ファーストネームだけが文字列の最後の値として存在することはありません。

    5. How do we calculate the overall length of the string values?(文字列の全長の計算方法は?)
    オーバーフローが発生したことを示す文字は値リストの後ろに追加されます。デフォルトの場合、その文字は3個のドット'...'です。オーバーフロー機能は、最大長からLISTAGG句の最後の完全な値の最後まで逆方向に移動した後、ユーザ定義の区切り文字(最終デリミタ)、ユーザ定義のオーバーフローインジケータ(切り捨てインジケータ)を追加した上で、 'WITH COUNT'による、リストから削除または切り捨てられた値の個数を示す出力を追加します。

    Summary

    Oracle Database 12c Release 2では、ORA-01489エラーに対し次の2つの方法で対処しました。
    1. VARCHAR2オブジェクトのサイズを32Kに増やした
    2. LISTAGGの拡張機能を使用して非常に長いリストの管理をより詳細に制御できるようにした
    そして、新しいキーワードが追加されています。
    • ON OVERFLOW TRUNCATE
    • ON OVERFLOW ERROR(デフォルトの挙動)
    • WITH COUNT(デフォルトの挙動)
    • WITHOUT COUNT

    うまくいけば、この新しい機能によって、長年にわたって作成された
    ORA-01489: result of string concatenation is too long
    ORA-01489: 文字列を連結した結果、長さが最大長を超えました
    というエラーを解決するためのすばらしい回避策は、標準のSQL機能で置き換えられることでしょう。
    Viewing all 760 articles
    Browse latest View live


    <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>