2016年12月7日

[Database] Transportable Tablespaces and READ ONLY in Oracle Database 12c

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

先日、トランスポータブル表領域を使って、同じ表領域のデータファイルを2個のデータベースに同時に接続することができない(表領域をSQL*PlusでREAD ONLYにした後にもかかわらず、です)ことに気付いたお客様と一緒に作業しました。これは12cでの新しい挙動であり、多くのお客様がまだこの変更に気付いていないことでしょう。以下に変更点とその理由、そしてこの変更が貴社の環境に影響する場合の対処法について説明します。

What Changed?

12cR1から、トランスポータブル表領域の移行のインポートフェーズの間、data pumpは表領域をread writeに設定します。これはつまり、トランスポータブル表領域を使用して、表領域を2つの異なるデータベースに同時にフックすることはできない、ということです。

Why Was This Change Made?

以下のようないくつかの要因があって変更されました。

まず第一に、データベースが増加するにつれて、多くのパーティションやサブパーティションを含む表または索引のための多くのパーティションやサブパーティションを含む表領域を処理する場合にパフォーマンスが低下することがありました。この理由(あまりにひどい場合はお詫びします)は、表領域を移動しているけれども当該表領域内の全ての表が操作の対象ではない場合には、空き領域を再利用できるようにしているためです。たとえば、5個の表のパーティションを含む表領域データファイルを移動することはできますが、それらの表のうち2個しか関心がない場合があります。その場合、別の3個の表が使用するセグメントは再利用対象のデッドスペースになります。

12c以前は、エクスポート・フェーズで最初にエクスポート対象の全てのセグメントを記録し、インポート・フェーズで当該セグメントをインポートすることで、この領域を再利用していました。これにより、インポート対象外のセグメントのスペースをすべて解放することができました。これは確かにうまくいきましたが、bigfile表領域が数十テラバイトにまで達するにつれ、パフォーマンスの劣化が激しくなりました。文字通り数日かかることもありました。そのため、12cでは異なる方式を実装しました。もうエクスポート時にセグメントを記録せず(これは11gへのバックポートとしても利用できます)、インポート時に表領域のビットマップを再計算します。ビットマップの再計算にあたっては、DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPSを呼び出し、数時間を要する可能性があった以前の方法に比べてあっという間で終了します。
したがって、多数のデータセグメントを含む場合、トランスポータブル表領域のエクスポート、インポートの両方でこの変更により、非常にパフォーマンスが改善されます。

この変更を実施した2番目の理由は、トランスポータブル表領域を使って、Timezone(TSTZ)データを持つ異なるバージョンのTimestampを使うデータベースに対し、表領域のデータベースへのインポートを実現するためです。12cより前では、データベース間でTSTZデータを移動するにあたり多くの制限がありましたが、徐々にこれらの制限を緩和して制限を取り除くことができました。ここでDatabaseユーティリティガイド (11.2.0.4) から引用してみます。
Oracle® Database Utilities 11g Release 2 (11.2)
Considerations for Time Zone File Versions in Transportable Tablespace Mode
https://docs.oracle.com/cd/E11882_01/server.112/e22490/dp_import.htm#SUTIL3777
Oracle® Databaseユーティリティ 11gリリース2 (11.2)
トランスポータブル表領域モードでのタイムゾーン・ファイルのバージョンに関する考慮点
http://docs.oracle.com/cd/E16338_01/server.112/b56303/dp_import.htm#SUTIL3777
12cR1から、より高いtimezoneバージョンを持つデータベースに表領域を移動する際にもTSTZデータを取り扱うことができます。これは、表領域データファイルを開き、この目的のために12cで作成された機能を使ってTSTZデータを修正することによって実現しています。つまり、12cを使うとトランスポータブル表領域をより多くのシナリオで利用でき、さらにTimezoneデータを含むTimestampがある場合に、結果として得られるインポートがより完全になることを意味します。

まとめると、トランスポータブル表領域のインポート時にデータファイルをread writeで開くように変更した結果、処理はより高速になり、このテクニックがより幅広く適用できるようになった、ということです。

But Neither of those Benefits Affect Me, and I Like the Old Behavior!

当該目的のために明示的にパラメータを実装することで、旧バージョンの挙動を許可することが可能な場合がありますが、このパラメータを使用する場合、次のような欠点があります。我々が旧バージョンの挙動を許すことができる可能性があります。
  1. 比較対照とすべきエクスポートされたセグメントのリストがないため、トランスポータブル表領域をimpdp操作中にインポートされたセグメントを構成することはできません。ユーザーが明示的にプロシージャDBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPSを呼び出すまで、当該セグメントはデッドスペースになります。
  2. インポート対象の任意の表領域にTSTZデータが含まれている場合、
    • インポートするデータベースのtimezoneバージョンが正確にエクスポートされたデータベースのそれと一致する必要があります。
    • 一致しない場合、インポートは失敗します。
    しかしながら、旧バージョンの挙動を残すという目的を達成するために、新しいパラメータを必要としていません。
    もしファイルをOSレベル(もしくはASM)でREAD ONLYに設定すると、その設定により、データベースレベルでread writeに設定することはできなくなります。これはつまり、未使用のセグメントを空き領域に再利用しないということを意味し、結果としてTSTZの修正は実行されません。この場合、移行先のデータベースのTimezoneバージョンがインポート対象のデータのそれと一致しなければ、TSTZデータを持つ任意の表はインポート時に削除されます。

    データ・ポンプ開発チームはこの変更によって得られるメリットが、機能の損失よりもはるかに上回るものと見てしまいがちですが、たくさんのお客様がデータ・ポンプの様々なユースケースをもち、データ・ポンプに対する位置づけが千差万別であることを認識しています。そのため、前述のようにオプションの提供を希望される場合は、是非エンハンスメント・リクエストを検討くださると幸甚です。

    [Database] Questions You Asked: I installed the latest PSU, why am I still getting this error?

    原文はこちら。
    https://blogs.oracle.com/In-Memory/entry/questions_you_asked_i_installed

    Database In-Memoryチームはこの数ヶ月Database In-Memoryの新機能について知らせるためにコンファレンスへ数多く参加してきました。これらのコンファレンスにはOpen World、East Coast Oracle Users Conference (ECO)、Bulgarian Oracle User Group (BGOUG) コンファレンス、German Oracle User Group (DOAG) コンファレンス、SANGAM16(All India Oracle Users Group (AIOUG) conference)が含まれますが、ご参加いただいたり、ご質問いただいた皆様に感謝申し上げます。
    引き続き尋ねられる質問の一つにPatch Set Updates (PSUs)があります。現在も引き続きPSU(MOS Note 854428.1を参照)やCritical Patch Updates (CPUs) をインストールし、Database In-Memoryの修正を得ようとしている人を探しています。
    Patch Set Updates for Oracle Products (Doc ID 854428.1)
    https://support.oracle.com/rs?type=doc&id=854428.1
    Critical Patch Updates, Security Alerts and Third Party Bulletin
    http://www.oracle.com/technetwork/topics/security/alerts-086861.html 
    この件について以前エントリをUpしましたが、重要なので繰り返します。
    Oracle Database In-Memory Bundle Patch 10 Released
    https://blogs.oracle.com/In-Memory/entry/oracle_database_in_memory_bundle3
    Database In-Memoryは2014年6月のOracle Database 12c Release 1 Patch Set (12.1.0.2) からご利用いただけるようになりました。以後、多くの機能強化と修正を加えましたが、こうした変更を全て取得する唯一の方法は、Database Proactive Bundle Patch(MOS Note 1937782.1を参照)として知られるものを入手することです。
    12.1.0.2 Database Proactive Bundle Patches / Bundle Patches for Engineered Systems and DB In-Memory - List of Fixes in each Bundle (Doc ID 1937782.1)
    https://support.oracle.com/rs?type=doc&id=1937782.1
    多くの人がDatabase Proactive Bundle PatchはEngineered Systemsのためのみにあると考えてらっしゃいますし、他の方はPSUsやCPUsに全ての修正が含まれていないと考えてらっしゃいます。MOS Note 1937782.1に記載されているように、各Bundle Patchには追加の予防的な修正とともに全てのDatabase PSUでの修正が含まれています。これらの予防的な追加修正のいくつかは全てのDatabase In-Memoryの修正を含んでいます。

    基本的に、Database In-Memoryを利用する場合には、最新のDatabase Proactive Bundle Patchを適用してください。

    結局のところ、車輪を再発明したり、既に修正されている問題を発見したり、既に提供済みの改善機能を利用しなかったりするのは意味がありませんから。

    [Database] Upgrade to Oracle Database 12.2 - Slides are available

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

    ブリュッセルとユトレヒトでのワークショップにはたくさんの方に参加いただき、非常に楽しかったです。ブリュッセルでのワークショップのうち、午前中はマイクの問題で聞きづらくなってしまい申し訳ありませんでした。
    お約束の通り、ワークショップで利用したスライドがダウンロードいただけるようになっています。
    Upgrade, Migrate and Consolidate to Oracle Database 12.2 and the Cloud
    Slides Oracle 12.2 Upgrade Migrate Consolidate
    [注意]
    このスライドは初版なので、Oracle Database 12cR2用にアップデートが完了していない箇所があります。もちろん12cR2の顧客事例はスライド内にはありません。しかしながら、いつも通りOracle Database 12cR2を早期に導入しようとしているのであれば、既にOracle Cloudで利用できますし、まもなくオンプレミスでもご利用いただけるようになりますので、その際には将来の顧客事例ということで、是非ご連絡ください。

    2016年12月2日

    [Database] Introducing PGX - Parallel Graph Analytics - 2.2.1

    原文はこちら。
    https://blogs.oracle.com/labs/entry/introducing_pgx_parallel_graph_analytics

    OracleのR&D LabsからParallel Graph Analytics (PGX) 2.2.1がリリースされました。
    Oracle Labs PGX Downloads
    http://www.oracle.com/technetwork/oracle-labs/parallel-graph-analytics/downloads/index.html
    これは、透過的に並列化可能なアルゴリズムをフレームワークが記述するためのDSLを使ってグラフのアルゴリズム的解析と、SQLライクなクエリ言語を使ったグラフのパターンマッチング、その両方のグラフ解析を実施するための高性能なツールキットです。
    PGQL · Property Graph Query Language
    http://pgql-lang.org/
    Groovyシェルを使って対話的に利用することも、様々なAPIを使った自動化ワークフローに統合することもできます。
    既にPGXのことをご存知であれば、PGX 2.2.1の新機能をご覧ください。
    PGX 2.2.1 Documentation
    What is New in PGX 2.2
    https://docs.oracle.com/cd/E56133_01/2.2.1/whatsnew/whatsnew.html
    グラフ解析は、あなたが持っているデータで明示的に表現されるものではなく、既に持っているデータ要素間の関係のネットワークで表現される潜在情報を明らかにします。

    Who Has A Graph?

    みんな持っています。あるフィールドを共有するデータがある場合(リレーショナルデータベースを使用している場合)、知っているかどうかに関わらず、グラフを持ちます。
    ソーシャルネットワークのおかげでグラフ分析が知られています。最も明白でアクセス可能なグラフの例が、ソーシャルネットワークが生成する友人間のネットワークです。この例は非常に鮮明ゆえに、ソーシャルネットワーク分析はこの種の技術が適しているという印象を作り出します(とはいえ、真実以上のものはないのですが)。グラフ分析のパワーは、グラフの頂点がすべて同じ種類のものではない場合に顕著に現れます。 例えば次のような場合です。
    • ある頂点が人で、ある頂点が評価した動画であるグラフを作成します(マトリックス因数分解や、アルゴリズム技術を使うと、推奨エンジンを作成することができます)。そして実際、これはNetflixが実施している推奨方法です。
      Using PGX as a Recommendation Engine
      https://docs.oracle.com/cd/E56133_01/2.2.1/use-cases/recommendation/index.html
      • リコメンデーションとは予測です。既存データを使って存在しないデータを外挿したり、データ内の潜在的な関係を予測したいどんな領域にも、このテクニックだけを応用することができます。
    • 異常検出
      どのような関係がデータセット内で典型的であるかを検出します。例えば、特定の専門分野の医師がどんな薬をどのようなランクで処方しているのかを基にして、典型的ではない医師を特定します。また、保険の請求や保険金請求者、車両事故をグラフでモデリングし、地理的に近い複数の請求の両方の立場の関係者を見つけ出して、保険金の搾取高位を検出します。
      Detect Anomalies in a Healthcare System
      https://docs.oracle.com/cd/E56133_01/2.2.1/use-cases/healthcare-fraud/index.html
    • 電力グリッドのモデリングや、オフラインのグリッド個々の要素のダウンストリーム効果を判断して、脆弱性の識別やメンテナンスを計画します。
      Modeling an Electric Network With PGX
      https://docs.oracle.com/cd/E56133_01/1.2.0/use-cases/electric-network/index.html
    これらはグラフ解析の利用例の一例に過ぎません。別の興味深い例として、どうやってAmerican Revolutionが利用可能なメタデータやこうしたテクニックを使えなくさせたのか、という以下の記事です。
    Using Metadata to find Paul Revere
    https://kieranhealy.org/blog/archives/2013/06/09/using-metadata-to-find-paul-revere/
    ここがポイントです。テクノロジ業界はグラフ解析のアプリケーションの表面をほとんど傷つけず、PGXによって、これまで政府にのみ利用可能になっていた数学のツールがすぐ使えるようになりました。

    Using PGX

    たくさんのチュートリアルがご利用いただけますが、PGXを操作するにあたって主要な手順はシンプルです。
    Tutorials
    https://docs.oracle.com/cd/E56133_01/2.2.1/tutorials/index.html
    PGXツールキットをダウンロード、インストールしてから、コマンドラインで実行するのはプログラムpgxを実行するのと同じぐらい簡単です。pgxはPGXシェルとグラフ・エンジン(リモートにデプロイされているものでもOK)の組み込みインスタンスを始動します。

    一般的な利用パターンはシンプルです。
    1. (SQLデータベース、Oracle NoSQL、フラットファイル、Hadoop、Apache Sparkなどから)グラフをロードする
    2. 多くのビルトインされている(もしくはカスタム開発した)アルゴリズムのうちの一つもしくは複数をグラフに対して実行する。アルゴリズムは通常新しいプロパティをグラフの頂点やエッジに追加する。
      Algorithms
      https://docs.oracle.com/cd/E56133_01/2.2.1/reference/algorithms/index.html
    3.     PGQLを使ってアルゴリズムを用いたパターンマッチを実行する
    このプロセスの手順を必要に応じて繰り返すことができ、結果を使ってレポートの生成やCSVファイルの出力ができます。PGXのJava APIやNode.jsのAPIを使っている場合、自動化されたワークフローに参加させることもできます。これらの手順全てをGroovyスクリプトとして保存し、再実行することができます。グラフ解析の重要な要素の一つは、再生産できること、アップデートされたデータに対して後で適用できることです。

    Examples

    Groovy Shell

    PGXを手早く動かすにあたっては、Groovyシェルが最も簡単です。これを使うと対話的にグラフ解析ができます。例えば以下のような感じです。
    graph = session.readGraphWithProperties(
      "../gameofthrones/stormofswords.json").undirect();
    
    prop = analyst.eigenvectorCentrality(g);
    graph.queryPgql(
      "SELECT v.id(), v.eigenvector WHERE (v)
                ORDER BY DESC(v.eigenvector)")

    PGQL

    Property Graph Query Language(PGQL)はオープンソースのSQLライクなグラフをクエリするための言語です。特に、値による制約(例:eigenvector > 0.9)とともに、トポロジーの制約を指定することができます。これらを使って、グラフの接続内で探索するパターンを指定することができます。
    SELECT v.id() WHERE (t WITH t.id() = 'Tyrion') -[]-> () -[]-> (v)
    
    この例では、TyrionというIDを持つ頂点に間接的に接続されている全ての頂点を検索しています。

    Recursive topological constraints

    パスクエリを定義し利用すると、再帰的にパターンを適用することもできます。以下は2人の共通の祖先を全て探す例です。
    PATH has_parent := () -[:has_father|has_mother]-> ()
    SELECT ancestor.name
    WHERE
      (:Person WITH name = 'Mario') -/:has_parent*/-> (ancestor:Person),
      (:Person WITH name = 'Luigi') -/:has_parent*/-> (ancestor)
    
    上記の例では、Marioのクエリは、ancestorという名前のMarioの祖先のある場所で頂点を定義しています。第2のLuigiの制約では、ancestorが、Mario用に定義された同じ頂点がある(つまり両方の祖先と同じ人物)ことを発見することを求めています。出力は、SQLの結果セットとは似ていない結果セットですが、これをレポートの生成や後続の処理に使用できます。

    Green-Marl

    Green-Marlは、ファーストクラスの言語要素として、頂点、エッジ、プロパティ、幅優先、深さ優先の検索を持つグラフアルゴリズムを記述するための言語です。特に、ループ構造は、同時実行性を管理するコードを記述しなくても、ランタイムによって透過的に並列化されるため、記述したアルゴリズムは自動的に利用可能な処理能力の全てを利用します。

    PGXには多数のアルゴリズムが組み込まれていますが、自身でアルゴリズムを記述しコンパイルすることができるため、必要な分析タスクを柔軟に実行することができます。
    proc weighted_degree_centrality( g: graph,
      weightProp: E_P<double>; outputProperty: N_P<double> ) {
    
        // Get the range of weight values
        int minWeight = min( curr_edge : g.edges ) { curr_edge.weightProp }; // find the lowest weight value
        int maxWeight = max( curr_edge : g.edges ) { curr_edge.weightProp }; // find the highest weight value
    
        foreach ( vtx : g.nodes ) { // iterate every node
            double weight = 0;
            for ( curr_edge : vtx.outEdges ) { // sum the weights
                weight += curr_edge.weightProp;
            }
            // Compute and assign the weighted result for this vertex
            vtx.outputProperty = vtx.degree()  * ( ( weight - minWeight ) + 1 );
        }
    }
    

    Using PGX with Apache Zeppelin

    PGXのこのリリースには、Apache Zeppelinのインタープリタが含まれています。これは"notebook"サーバと言われるもので、解析のステップ、これらのステップの説明、インタラクティブかつ協働して分析を実施したり、インタラクティブなレポートの形で結果を保持する方法を取得するための簡便な方法を提供します。
    Apache Zeppelin
    https://zeppelin.apache.org/
    利用にあたっては、Zeppelinをインストールし、Zeppelinインタープリタをダウンロードして、Zeppelinのinterpreterディレクトリにインストールして、新しいnotebookを構成する必要があります。
    Oracle Labs PGX Downloads
    http://www.oracle.com/technetwork/oracle-labs/parallel-graph-analytics/downloads/index.html

    Performance

    グラフはPGXのメモリ上にあるため、パフォーマンスはメモリの容量と利用可能なCPUの個数によってのみ制限を受けます。Javaエンジンはオフヒープストレージと非常に効率的なデータ構造を使うため、サーバークラスのハードウェアが有用ではあるにせよ、驚くほど大きなグラフをラップトップで分析することができます。そして、アルゴリズム分析、パターンマッチング分析の両方を並列化するので、どんなコンピュート・リソースも十分に活用することができます。
    大量のデータがある場合、データを他の場所にあるメモリに取り込むインメモリ解析が不便になる可能性があります。 ただし、次の点を考慮してください。
    • グラフ解析の特徴の1つとして、指定された任意のアルゴリズムで、頂点を任意の順序で何回も訪れることができます。
    • HadoopやSparkのような環境では、データが複数のマシンに分散しており、それらのマシンでHadoopやSparkが動作するため、共有コンピュート・リソースで利用される変数の単純なアップデートでさえもネットワークI/Oが発生します。そして変数は何度も更新される可能性があり、ときにはグラフのノードの個数の倍になることがあります(ネットワークアクセスはネットワークI/Oに比べて数桁遅いのです)
    要約すると、グラフ解析の性質ゆえに、1回のグラフをロード(して、そしてメモリアクセスの速度で解析を実行できる)するI/Oコストは例えばSparkのGraphXよりもずっと低コストです。
    PGXには、単一のノードに収まらない大きなグラフを解析するための、複数のマシンにセットアップ可能な分散分析エンジンも含まれています。

    2016年12月1日

    [Integration] Processing high volumes of updates to a single row using OSA

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

    今日の世界では、指数関数的にデータが生成されています。このような情報をすべて収集して処理して興味深い傾向を発見するための新しいビッグデータ・テクノロジーが利用できますが、即時対応する必要があったり、特定の項目の現在の状況を知りたいという場合もあります。このような要求を実現するために、すべての着信データを保存することもできますが、トレードオフとして、不要なデータを大量に保持し、ユーザーが最初に最新のレコードを決定するクエリを作成する必要があります。別の手法として、データベースの更新を行うこともできますが、デバイスが頻繁にステータスメッセージを送信する可能性があるIoT領域のような、単一の行が頻繁に更新されるシナリオでは、データベースの競合が発生する可能性があります。
    この問題を解決する方法の一つとして、あまり知られていませんが、Oracle Stream Analytics(OSA)の利用があります。OSAは、SQLに類似しSQL-99に準拠しつつも、インメモリでの操作と問題を非常に効率的な解決のために、追加の構文を備えた、Continuous Query Language(以下CQL)という非常に洗練された言語を利用することができます。不要なデータベースの更新を避けるという課題は、OSAが十分に、しかもたった1個のクエリでとても簡単に解決します。
    はじめにOSAランタイムの基本情報を説明します。非常に使い安いOSAのユーザーインターフェースを使い、わずかな時間でアプリケーション全体を開発することができるだけでなく、JDeveloperを使用した従来の方法でもアプリケーションを開発することができます。JDeveloperを使用して開発する場合、「イベント処理ネットワーク(Event Processing Network、以下EDN)」と呼ばれるアプリケーション・モデルを理解する必要があります。
    EPN
    EPNは、アプリケーションからのデータフローを処理します。EPNには実行させたいCQLを保持するCQLプロセッサノードが含まれます。今回のケースでは、数十行のJavaコードを使って書き込むという比較的複雑なタスクを実行するためのCQLを、下図のような非常にシンプルな文を使い、非常に簡単かつ効率的にメモリ内で実行します。
    CQL
    このクエリでは、必要な属性(SELECT * FROM InputChannelも使用できます)のみを選択し、CQL構文を使用してストリームをデバイスIDで"ROWS 1"を使ってパーティション化します("ROWS 1"は、各デバイスID毎に1個の行だけという意味です)。このデバイスIDごとの1行を"RANGE 2 SECONDS"で指定した2秒間保持し、結果を2秒毎(SLIDE 2 SECONDS)に出力します。ここで、"RANGE"と"SLIDE"で指定した値が同じ時間間隔の場合、本質的には2秒ごとに(クエリに状態を持たずに)最初からやり直すことになります。

    [注意]
    2秒が長いという場合には、1秒もしくはミリ秒単位で時間を指定してください。

    このテストでは、データはランダムに生成されますが、データと結果が正確かどうかを確認します。今回は、Oracle BAM 12cにデータを送信します。JMS Mapメッセージとしてデータを自動的に書き出すJMSアダプタを使用してOSAアプリケーションからデータを出力するようにします(設定はイベント・タイプ名をOSA JMS構成に指定するだけです。標準のJMSアダプタはコンバータクラスを使わずにJMSメッセージを作成します)。今回こうした理由は、以下の点で便利だからです。
    • BAMのEnterprise Message Sources(以下EMS)をBAM 12c管理者ページで簡単に構成でき、Mapメッセージ属性をデータオブジェクトへ割り当てることができる。
    • OSAおよびBAMで全て完結し、Javaコードを一切各必要がない


    このテストのために、空のデータオブジェクトから始め、EMSメトリックをリセットすることをお忘れなく。

    私たちのBAM EMSは "Upsert" で構成されています。これは、レコードが存在しない場合は、(deviceIDとして定義されているキーに基づいて)レコードを挿入し、当該デバイスIDを持つ行がデータオブジェクト(つまりデータベース表)に既に存在する場合には、更新することを意味します。

    まず、管理した状態で少量のデータセットを送信し、期待どおりに動作することを確認しましょう。たった10個の一意のデバイスIDに対応する30個のイベントを送信し、各イベント間には意図的にわずかな遅延を挟むことにします。


    10個の異なるデバイスIDがサンプル中にあり、10個のメッセージが永続化されているため、10個のメッセージのみが送信されたというBAM EMSのメトリックが正しいことがわかります。

    デバイスID毎にdeviceCodeとcodeValueを調査すると、これらのメッセージがBAMダッシュボードでユーザーに見てもらいたい直近10メッセージ(各デバイスから送信された最新のメッセージ)であることがわかります。

    ”Upsert”の操作のためのキーフィールドが2個ある場合、次のようにコンマで区切られたpartition by句の両方にそれらを並べることができます。

    データオブジェクトにはもっと多くの行の組み合わせがあるかもしれませんが、Device ID、Device Codeの組み合わせの1エントリだけにしておきます。

    是非ご自身で試してください。そうすれば、デバイスの最新の状態を非常に迅速かつ簡単に提供するという目標を達成していることを目の当たりにされることでしょう。同じ行を何度も更新するためにデータベースの競合を潜在的に発生させる可能性がある、不要なJMSメッセージを生成し、ネットワークを介して送信し、Queueに配置した後に、BAMのEMSがQueueから取り出し、処理する必要はなくなります。ユーザーにデバイスの最新状態のメッセージを配信するという目的を満足するためのソリューションの効率を非常に簡単に、大幅に向上しました。そして、追加ボーナスとして、迅速に上書きされるメッセージを生成しないために他の目的にCPU利用率を節約できたので、運用効率も向上しました。

    2016年11月28日

    [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の次のステップを説明する予定です。

    2016年11月25日

    [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_PLANSOPTIMIZER_ADAPTIVE_STATISTICSという2個のパラメータを導入し、OPTIMIZER_ADAPTIVE_FEATURESというパラメータを削除します。
    • bug# 21171382 に対するパッチ(Patch 21171382: AUTO DOP COMPUTES A HIGH DOP UNNECESSARILY)
    • オプティマイザ・プリファレンスAUTO_STATS_EXTENSIONSONでない場合には、拡張統計の自動作成を無効化します。
    パッチ適用時には、以下の操作を実施して、OPTIMIZER_ADAPTIVE_FEATURESSPFILEから削除されていることを確認してください。
    alter system reset optimizer_adaptive_features;
    すでにOracle Database 12.1にアップグレードしているけれどもパフォーマンス上の問題が発生している場合には、どちらのパッチも効果があります。
    ご注意いただきたいのは、OPTIMIZER_DYNAMIC_SAMPLING をデフォルト値以外に設定することは必ずしも必要ではない、ということです。その理由は、新しい両パラメータをデフォルト設定で利用すると、パッチがアダプティブ動的サンプリング(adaptive dynamic sampling)の利用を無効化し、Oracle Database 12.2のデフォルトの挙動に一致するためです。