X

A blog about Oracle Technology Network Japan

Recent Posts

OCIでブロック・ボリュームを複数インスタンスにアタッチする

  すばらしいお知らせがあります。ブロック・ストレージ・ボリュームを共有して、Oracle Cloud Infrastructure上の複数のコンピュート・インスタンスに接続できるようになりました。 これまでは、複数のブロック・ボリュームを1つのコンピュート・インスタンスに接続することはできましたが、ボリュームを接続して読取り/書込みアクセスができるのは、一度に1つのコンピュート・インスタンスからのみに制限されていました。他のパブリック・クラウド・ベンダーでも同じような設計上の制限がありますが、一部のベンダーでは、共有の読取り専用ボリュームへのアクセスが可能な場合もあります。 Oracle Cloud Infrastructureからの本発表に伴って、読取り/書込みアクセスに対応する共有可能なボリュームを、複数のコンピュート・インスタンスに接続できるようになりました。クラウド・ストレージでのこの独自の機能により、Oracle Cloud Infrastructure Block Volumeサービスが提供する共有可能なボリュームを使用して、クラスタ対応ソリューションをデプロイおよび管理できます。   クラスタ対応ソリューションによる同時書込み この機能自体が、複数のコンピュート・インスタンスからの同時書込みの調整を処理するわけではありません。クラスタ対応のシステムまたはソリューションを別途用意して、複数インスタンスが接続された共有ストレージの上位にデプロイする必要があります。複数の同時書込みを調整できるクラスタ対応ソリューションには、Oracle RAC(入手およびサポートはOracle Cloud Infrastructure Databaseサービスを通した場合のみ)、Oracle Cluster File System(OCFS2)、IBM Spectrum Scale(オラクルとIBMのパートナーシップを通して利用可能)、GlusterFSなどがあります。 複数インスタンスの接続とOCFS2を使用するソリューションのセットアップ方法の例について詳しくは、「複数インスタンスへのブロック・ボリュームのアタッチ機能を利用したOracle Cloud Infrastructure上の共有ファイル・システムの作成」というブログ記事をご覧ください。   ユースケース この新しい機能は、2017年5月に登場したOracle Cloud Infrastructure Databaseサービスをサポートすることをおもな目的としていました。しかし当社は、この機能を一般にも公開してほしいという多数の要望を受け取りました。この機能によって、可用性が高く、耐久性があり、費用対効果に優れ、柔軟なパフォーマンスを発揮するブロック・ボリュームの利点を活用し続けることができ、クラスタ対応のデプロイメントと、この機能の処理に対応した任意のソリューションを作成および管理できるようになりました。 たとえば、以下のようなユースケースがあります。 大規模データベースに合わせて高度に最適化された共有ファイル・システム 共有ディスクによるパッチ適用と構成の管理 書き込むユーザーが1人、読み取るユーザーが複数いる共有カタログ・コンテンツ 分散システムから共有リポジトリへのログ・ファイルのアップロード この複数インスタンスの接続機能は、オラクルがIO500ベンチマークのトップ15にランクインするに当たっても重要な要素となりました(「Oracle Cloud Joins the IO500 Fastest File Systems in the World」をご覧ください)。   使ってみよう デフォルトでは、ボリュームは、同一機能を持ち常に使用可能な1つのインスタンスからの共有不可能な読取り/書込みアクセスのみが有効な状態で接続されます(ボリュームへの最初の接続で共有可能な読取り/書込みアクセスのオプションが選択されている場合を除く)。ボリュームへの共有可能な接続が確立されると、その後に設定される、同一ボリュームへの他のインスタンスからの接続も共有可能になります。 さらにオラクルは、読取り専用接続も共有できるようにしました。読取り専用アクセスでボリュームを接続すると、複数のコンピュート・インスタンスへの共有可能な読取り専用接続が有効になります。同時アクセス制御やクラスタ対応ソリューションがなくても、読取りを行う複数のユーザー間で共有ブロック・ボリュームのコンテンツを共有できます。 読取り/書込みアクセス用のブロック・ボリュームの共有は簡単でシームレスです。コンソールのAttach Block Volumeのページで1回クリックするだけで済みます。 複数インスタンスが接続された共有可能ボリュームにも、ボリューム・グループ、ディスクからディスクへのディープ・クローン、自動化されたバックアップなど、すべてのブロック・ボリューム機能を適用できます。デタッチされた既存のボリュームでも、未接続の新規ボリュームでも、複数インスタンスの接続機能を利用できます。以前に共有可能な読取り/書込みアクセスで接続されなかったボリュームを共有可能にしたい場合は、ボリュームをデタッチして、共有可能なボリュームとして再接続します。これまでと同様のOracle Cloud Infrastructure Block Volume SLAを引き続き適用できます。 複数インスタンスが接続された共有可能なブロック・ボリュームは、Oracle Cloud Infrastructure Console、CLI、SDK、Terraformを通して、Oracle Cloud Infrastructureのすべてのリージョンで使用できます。この機能に関して詳しくは、ブロック・ボリュームのドキュメントをご覧ください。 ブロック・ボリューム・ストレージに関する情報は、ブロック・ボリューム・サービスの概要およびFAQをご覧ください。OCFS2について詳しくは、OCFS2のユーザー・ガイドをご覧ください。 特徴と機能についての詳しい情報は、本ブログでの発表をご確認ください。エンタープライズの皆様に当社のクラウド・サービスを引き続き役立てていただくために、当社では皆様からのフィードバックを歓迎しています。当社がより良いサービスをご提供し続けるためのアイディアをお持ちの場合や、トピックに関わらず詳しい情報をお知りになりたい場合は、私までお問い合わせください。 ※本記事は、Max Verun (Principal Product Manager)による”Announcing Multiple-Instance Attachment of Shareable Read/Write Block Volumes“を翻訳したものです。

  すばらしいお知らせがあります。ブロック・ストレージ・ボリュームを共有して、Oracle Cloud Infrastructure上の複数のコンピュート・インスタンスに接続できるようになりました。 これまでは、複数のブロック・ボリュームを1つのコンピュート・インスタンスに接続することはできましたが、ボリュームを接続して読取り/書込みアクセスができるのは、一度に1つのコンピュート・インスタンスからのみに...

全国のOTNおすすめ技術者向けセミナー&イベント(2020年2月)

Oracle Cloud Infrastructure ハンズオン 「Oracle Cloud Infrastructure」は、オンプレミスからの大規模ワークロード移行に完全対応する次世代インフラ基盤です。本セミナーでは、Oracle Cloud Infrastructureのサービス概要のご紹介とともに、実際のクラウド環境を利用したハンズオンを半日で体感いただけます。 2/7【2月第1回】Oracle Cloud Infrastructure ハンズオン 2/18【2月第2回】Oracle Cloud Infrastructure ハンズオン 一歩進んだ分析でビジネスにチカラを!! ~あなたもデータ アナリスト~ Autonomous Database CloudおよびOracle Analytics Cloudの特徴や活用法についてご紹介し、実際にサービスを利用し、起動からデータロード、分析まで一連の流れを体感いただけます。 2/12 【2月第1回】一歩進んだ分析でビジネスにチカラを!! ~あなたもデータ アナリスト~ 2/19 【2月第2回】一歩進んだ分析でビジネスにチカラを!! ~あなたもデータ アナリスト~ 2/27 実践Kubernetesハンズオン ~OKEでKubernetesを体験しよう~ Oracle Cloudは大規模なコンテナの管理、デプロイおよび運用に適したクラウドサービスを複数提供しています。本ハンズオンセミナーではOracle Cloudが提供するコンテナ・サービスを実際に利用しKubernetes環境の構築からコンテナ・アプリケーションのデプロイ、CI/CDまでの一連の流れを体感いただけます。 AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。

Oracle Cloud Infrastructure ハンズオン 「Oracle Cloud Infrastructure」は、オンプレミスからの大規模ワークロード移行に完全対応する次世代インフラ基盤です。本セミナーでは、Oracle Cloud Infrastructureのサービス概要のご紹介とともに、実際のクラウド環境を利用したハンズオンを半日で体感いただけます。 2/7【2月第1回】Oracl...

Data SafeでAutonomous Data Warehouseの安全性を維持する - パート2

この連載のパート1では、既存のADWおよびOCI環境でData Safeを使用するための準備作業について確認しました。まだパート1を読んでいない場合や、ざっと復習したい場合は、こちらをご覧ください。 https://blogs.oracle.com/otnjp/keeping-your-autonomous-data-warehouse-secure-with-data-safe-part-1-ja パート2では、新しくデプロイしたData Safe環境をAutonomous Data Warehouseインスタンスに接続するプロセスについて確認していきます。オラクルのクラウド・サービスはどれもそうですが、Data Safeコントロール・センターは特定のOCI地域データセンター内にデプロイされています。このため、別のデータセンターに切り替える場合は、新しくData Safe環境をデプロイする必要が生じるのでご注意ください。 Data Safeサービス・コンソールの起動 パート1の最後でFrankfurtデータセンター内のData Safeを有効化しました。このため、新しく作成したOCI資格証明を使用してOracle Cloudにログインすると、ハンバーガー・メニューにData Safeが表示されます。 「Data Safe」を選択すると、Data Safeランディング・パッド・ページが表示されます。次のステップでサービス・コンソールを起動します(ランディング・パッド・ページには「Service Console」ボタンしか表示されないのに、なぜ自動的にサービス・コンソールを表示しないのかと不思議に感じるかもしれません。とても良い疑問です。この連載の最後にはランディング・パッド・ページにもっと多くの情報が表示されるので、そのときもう一度この点について考えましょう)。  「Service Console」ボタンをクリックすると、次のような新しいウィンドウが表示されます。   この時点では、グラフにもその他のページにも情報は表示されていません。これはまだデータウェアハウス・インスタンスを登録していないからです。登録は次のステップで行います。  Data SafeへのADWの登録 Data Safeライブラリに含まれるレポートを生成するには、Data SafeにADWを登録する必要があります。 はじめに、ページ上部のメニューから「Targets」タブを選択します。 「Register」ボタンをクリックするとフォームが表示されるので、ADWの接続情報を入力します。 Data Safeと連携できるのはAutonomous Databaseだけではありません。以下のクラウド・データベースも登録できます。 ただし、Data Safeでサポートされているのはサーバーレス・デプロイメントのAutonomous Databaseのみであり、"専用サーバー"は現在サポートされていません。詳しい情報はこちらを参照してください。 https://docs.oracle.com/en/cloud/paas/data-safe/udscs/supported-target-databases.html ADW(およびATP)の場合、最初に接続タイプをTLSに変更します。変更すると、フォームに追加フィールドが表示されます(通常DI/ETLまたはBIツールからADWの接続を設定している場合、この方法が一番わかりやすいでしょう)。  ADWインスタンスの登録には多くの情報を入力する必要があると思えるかもしれませんが、ご安心ください。ほとんどの必要情報を含んだzipファイルをOCI ADBコンソールからダウンロードできます。実質的に必要なのはインスタンスのウォレット・ファイルですが、その前にフォーム上部のフィールドを入力しましょう。   残るはADWインスタンスに関する情報です。入手方法を次のステップで説明します。 ADW接続情報の収集 ADWインスタンスのOCIコンソール・ページに切り替えて、"OCID"というラベルの行を見つけます。これが最初に入手する情報です。"Show"と"Copy"という2つのリンクがあります。 「Copy」をクリックしてからData Safeページに戻り、「OCID」フィールドに貼り付けます。このほかに、ホスト名、ポート、サービス名、ターゲット識別名、セキュア・ウォレット・ファイルなどの情報が必要です。これらを入手するため、ウォレット・ファイルをダウンロードします。ウォレット・ファイルにアクセスするには、「DB Connection」ボタンをクリックします。ポップアップ表示されたフォームで、「Download Wallet」ボタンをクリックしてパスワードを入力します。あとで必要になるので、このパスワードをメモしておいてください。 ファイルをダウンロードしたら、ファイルシステム上にあるファイルを解凍します。解凍したフォルダには以下のファイルが含まれます。  Data Safeのターゲット登録フォームに戻りましょう。次に入力する4つのフィールドのデータはtnsnames.oraファイルから確認できます。Data Safeレポートの実行は緊急性の高いワークロードではないので、今回の接続には"low service"を使用します。 "low service"についてご存知ない場合は、ADWドキュメントのセクション12の「Managing Concurrency and Priorities on Autonomous Data Warehouse」にざっと目を通すことをおすすめします。簡単に言うと、ADWインスタンスに接続するとき、low、medium、highのいずれかのサービスを選ぶ必要があります。このサービスは以下の特性を持つコンシューマ・グループ(LOW、MEDIUM、またはHIGH)にマッピングされます。      HIGH:リソース: もっとも多い、同時実行性: もっとも低い。問合せは並列で実行。 MEDIUM:リソース: HIGHより少ない、同時実行性: HIGHより高い。問合せは並列で実行。 LOW:リソース: もっとも少ない、同時実行性: もっとも高い。問合せは順番に実行。 いずれにせよ、ジョブが実行されれば問題ありません。tnsnames.oraファイルからlow-service接続用の情報を探します。以下のような行が見つかります。  adwdemo_low = (description=(address=(protocol=tcps)(port=1522)(host=xxxxxx.oraclecloud.com))(connect_data=(service_name=xxxxx_adwdemo_low.xxxxxxx))(security=(ssl_server_cert_dn="CN=xxxxxx.oraclecloud.com,OU=Oracle,O=Oracle Corporation,L=Redwood City,ST=California,C=US"))) host、port、service_name、ssl_server_cert_dnの値をコピーして、"TLS"プルダウン・メニュー項目の下にある4つのフィールドに貼り付けます。 フォームは以下のようになります。 あと少しです。Wallet Typeに"JKS Wallet"を設定します。Certificate/Walletには、ダウンロード後に解凍した接続ファイル"truststore.jks"を指定します。同じディレクトリ/フォルダにある"keystone.jks"ファイルをKeystore Walletに指定します。その下のフィールドには、zipされた接続ファイルをダウンロードするときにOCI ADWコンソール・ページで使用したパスワードを入力します。 最後に、ADWインスタンスのユーザー名/パスワードを入力します。このユーザーは、この連載のパート1で作成したDATASAFEです。      「Test Connection」ボタンをクリックする前に、PL/SQLスクリプトを実行する必要があります。このスクリプトは、新しいデータベース・ユーザーであるDATASAFEに権限を付与して、Data Safeのさまざまなチェックを問題なく実行できるようにするものです。 ダウンロード・ボタンをクリックして、dscs_privileges.sqlというPL/SQLスクリプトを見つけます。SQL Developer(または任意のツール)を使用し、標準のADMINユーザーとしてログインしてからスクリプトを実行します(コピー&貼付けを使用)。スクリプトのログをチェックすると、以下のようなメッセージが確認できます。 Enter value for USERNAME (case sensitive matching the username from dba_users) Setting USERNAME to DATASAFE Enter value for TYPE (grant/revoke) Setting TYPE to GRANT Enter value for MODE (audit_collection/audit_setting/data_discovery/masking/assessment/all) Setting MODE to ALL Granting AUDIT_COLLECTION privileges to "DATASAFE" ...  Granting AUDIT_SETTING privileges to "DATASAFE" ...  Granting DATA_DISCOVERY role to "DATASAFE" ...  Granting MASKING role to "DATASAFE" ...  Granting ASSESSMENT role to "DATASAFE" ...  Done. Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production Version 18.4.0.0.0 以上で接続をテストする準備が整いました。「Test Connection」ボタンをクリックすると、接続に成功し、緑のチェック・マークが表示されます。   最後に「Register Target」をクリックします。新しく登録したデータベースの情報がTargetページに表示されます。     ここではADWを新規ターゲットとして登録しただけなので、ホームページを含むその他のページはまだ空白です。     パート2のまとめ パート1では、Data Safeを使用できるように環境を準備し、地域データセンター(今回はFrankfurtデータセンター)内でData Safeを有効化しました。パート2では、既存のADWインスタンスを新しいターゲット・データベースとしてData Safeに登録しました。   パート3を近日公開予定 次の記事では、Data Safeに含まれるデータ検出機能とデータ・マスキング機能について確認する予定です。   詳細情報 オラクルのセキュリティ・チームは、Data Safeの学習に役立つコンテンツを多数作成しています。ここでは、個人的に使用しているブックマークを紹介します。 ドキュメント - まずはここから: https://docs.oracle.com/en/cloud/paas/data-safe/udscs/oracle-data-safe-overview.html Oracle.comのData Safeページ - https://www.oracle.com/database/technologies/security/data-safe.html データベース・セキュリティ・ブログ: https://blogs.oracle.com/cloudsecurity/db-sec https://blogs.oracle.com/cloudsecurity/keep-your-data-safe-with-oracle-autonomous-database-today https://blogs.oracle.com/cloudsecurity/keeping-your-data-safe-part-4-auditing-your-cloud-databases   ※本記事は、Keith Laker (Senior Principal Product Manager)による”Keeping Your Autonomous Data Warehouse Secure with Data Safe Part 2“を翻訳したものです。

この連載のパート1では、既存のADWおよびOCI環境でData Safeを使用するための準備作業について確認しました。まだパート1を読んでいない場合や、ざっと復習したい場合は、こちらをご覧ください。 https://blogs.oracle.com/otnjp/keeping-your-autonomous-data-warehouse-secure-with-data-safe-part-1-ja...

Data SafeでAutonomous Data Warehouseの安全性を維持する - パート1

サンフランシスコで開催されたOpenWorld 2019では、重要な発表の1つにOracle Data Safeがありました。Data Safeは、Oracle Autonomous Data Warehouse(ADW)に対応したまったく新しいクラウドベースのセキュリティ・コントロール・センターで、完全に無償でご使用いただけます。    具体的にはどんな機能があるのでしょうか。簡単に言うと、Oracle Data Safeは、不可欠なデータ・セキュリティ機能をOracle Cloud Infrastructureのサービスとして提供します。これらのサービスは、データの機密性の把握、データ・リスクの評価、機密データのマスキング、セキュリティ管理の実装と監視、ユーザー・セキュリティの評価、ユーザー活動の監視、データ・セキュリティ・コンプライアンス要件への対応に役立ちます。   こちらの短い動画が参考になります。     Data Safeコンソール Data Safeのメイン・コンソールであるダッシュボード・ページは次のように表示されます。  Autonomous Data Warehouse内に保存された各種のデータセットを直接確認できるので、次の処理が可能になります。     データベースがセキュアに構成されているかどうかを評価する GDPRの条項/備考、Oracle DatabaseのSTIGルール、CISベンチマークの推奨事項に基づいてリスクを調査し、軽減する 重要なユーザー、ロール、権限を明確にすることで、ユーザー・リスクを評価する 監査ポリシーを設定し、ユーザー・アクティビティを収集して、異常な行動を特定する 機密データを見つけて、その保存場所を把握する 機密データをマスキングして、本番以外のデータセットからリスクを除外する 既存のAutonomous Data WarehouseをData Safeに接続するのはごく簡単です。ここからは、その方法とデータセットに対して実行できるセキュリティ・レビューの種類を紹介しましょう。 Data Safeと連携するためのADWの設定 ここでは設定を簡単にするため、既存のADWインスタンスにLOCAL_SHという新規ユーザーを作成します。続いて、デモグラフィック、国、顧客の各表を、読取り専用の販売履歴デモ・スキーマから新しいlocal_shスキーマに追加でコピーします。  これにより、ADWをData Safeに接続したときにData Safeが検出する"機密"のデータ・ポイントがスキーマに含まれます。 CREATE USER local_sh IDENTIFIED BY "Welcome1!Welcome1"; GRANT DWROLE TO local_sh; CREATE TABLE local_sh.supplementary_demographics AS SELECT * FROM sh.supplementary_demographics; CREATE TABLE local_sh.customers AS SELECT * FROM sh.customers; CREATE TABLE local_sh.countries AS SELECT * FROM sh.countries; 顧客表にはどのようなデータが含まれるのでしょうか。 間違いなく個人の特定につながりそうな列がいくつかありますね。このような列は、開発者チームやビジネス・ユーザーに表示されないようにするか、マスキングしなくてはなりません。   ここまでで、非常に機密性の高いデータが含まれることが確認できました。 今回の例とは異なり、まっさらなADWにデータをロードする必要がある場合は、オラクルのドキュメント・ガイドに記載された手順を参照してください。このガイドでは、ユーザー・データをADWにロードする方法について説明しています。 https://docs.oracle.com/en/cloud/paas/autonomous-data-warehouse-cloud/tasks_load_data.html   次に、Data Safe接続プロセスで使用するユーザーをADWインスタンスに作成します。新しく作成することで、セキュリティ・レビュー・プロセスがいずれかのアプリケーション・ユーザーに関連付けられることを回避します。 CREATE USER datasafe IDENTIFIED BY "Welcome1!DataSafe1"; GRANT DWROLE TO datasafe; このあとで、インストール・スクリプトを実行する必要がありますが、スクリプトはデータベースの登録時にData Safeコンソールから入手できます。既存のアプリケーション・ユーザーに関連付けないようにしたのは、Data Safeの実行に必要なロールと権限をこのユーザーに付与するからです。   Oracle Cloudアカウントの種類の確認 Oracle Cloudを初めて使用する場合や、アカウントを作成したのが過去12か月以内である場合は、このセクションをスキップして問題ないでしょう。Oracle Cloudのクラウド・アカウントを2年以上前に作成している場合は、Data Safeにアクセスしようとすると、連携アカウントに関する警告メッセージが表示される可能性があります。 Data Safeへのアクセス クラウド・アカウントにログインし、左上にあるハンバーガー(3本の横線)メニューをクリックします。ポップアップ・メニューで、Autonomous Transaction Processingの下にData Safeが表示されます。   「Data Safe」をクリックすると、次のような画面が表示される場合があります。このメッセージが表示されない場合は、"Data Safeの有効化"セクションに進んでください。   メッセージが表示されても心配ありません。必要な作業は新しいOCIユーザーを作成することだけです。ハンバーガー・メニュー・リスト内を下方向にスクロールし、"Governance and Administration"が表示されたら、「Identity」→「Users」の順に選択します。 画面上部にある青色の大きな「Create User」ボタンをクリックし、各フィールドに値を入力して新規OCIユーザーを作成します。このユーザーはあとでData Safe環境の所有者として使用します。 新規ユーザーを作成した後に届く「ようこそ」メールには、以下のようにパスワードをリセットするためのリンクが記載されています。 新規ユーザーを作成したら、Data Safeがテナント内でリソースおよび自律型データベース・インスタンスにアクセスできるようにするため、正しい権限をすべて有効化する必要があります。 ここでは、DataSafeというユーザーのために、Data Safeで必要になる権限をすべて含んだ“administrators”グループをテナント内に作成してあります。  実際には、より慎重な方法として、Data Safe管理者専用の新規グループをセットアップし、このグループだけにOCI権限を割り当てると良いでしょう。このプロセスについての詳細情報はこちらを参照してください。 https://docs.oracle.com/en/cloud/paas/data-safe/udscs/required-permission-enabling-oracle-data-safe.html 簡単なおさらい ここでは、あらかじめセットアップしてあったAutonomous Data Warehouseインスタンスを使用しました。SQL Developerを使用して新規ユーザーを作成し、潜在的な機密情報を含む小さなデータセットの所有者にしました。機密データ・ポイントを含むことがわかっている既存のスキーマから、いくつかの表をコピーして、作業用データセットを作成しました。また、新しいOCIユーザーに対して、Data Safe導入環境の所有者として使用できるように設定しました。   Data Safeの有効化 ここまでで、Data Safeを使用する準備が整いました。ハンバーガー・メニューから「Data Safe」を選択します。このテナント・リージョンでのログインが初めての場合は、次のような画面が表示されます。画面から、Frankfurtデータセンターを使用中で、データセンターへのログインは今回が初めてであることがわかります。 次の段階へ進むには、大きな青色のボタンをクリックしてData Safeを有効化します。いつもの"作業中..."画面が表示されます。   その後、"準備完了"画面になります。   パート1のまとめ パート1はここまでです。次回は、Autonomous Data Warehouseインスタンスの登録方法を確認してから、顧客に関する機密データを含むオブジェクトを突き止めるときに役立つセキュリティ・レポートを実行します。 詳細情報 オラクルのセキュリティ・チームは、Data Safeの学習に役立つコンテンツを多数作成しています。ここでは、個人的に使用しているブックマークを紹介します。 ドキュメント - ますはここから: https://docs.oracle.com/en/cloud/paas/data-safe/udscs/oracle-data-safe-overview.html Oracle.comのData Safeページ - https://www.oracle.com/database/technologies/security/data-safe.html データベース・セキュリティ・ブログ: https://blogs.oracle.com/cloudsecurity/db-sec https://blogs.oracle.com/cloudsecurity/keep-your-data-safe-with-oracle-autonomous-database-today https://blogs.oracle.com/cloudsecurity/keeping-your-data-safe-part-4-auditing-your-cloud-databases ※本記事は、Keith Laker (Senior Principal Product Manager)による”Keeping Your Autonomous Data Warehouse Secure with Data Safe Part 1“を翻訳したものです。

サンフランシスコで開催されたOpenWorld 2019では、重要な発表の1つにOracle Data Safeがありました。Data Safeは、Oracle Autonomous Data Warehouse(ADW)に対応したまったく新しいクラウドベースのセキュリティ・コントロール・センターで、完全に無償でご使用いただけます。    具体的にはどんな機能があるのでしょうか。簡単に言うと、Oracl...

全国のOTNおすすめ技術者向けセミナー&イベント(2020年1月)

1/28 Oracle Cloud Infrastructure ハンズオン 「Oracle Cloud Infrastructure」は、オンプレミスからの大規模ワークロード移行に完全対応する次世代インフラ基盤です。本セミナーでは、Oracle Cloud Infrastructureのサービス概要のご紹介とともに、実際のクラウド環境を利用したハンズオンを半日で体感いただけます。 1/31 実践Kubernetesハンズオン ~OKEでKubernetesを体験しよう~ Oracle Cloudは大規模なコンテナの管理、デプロイおよび運用に適したクラウドサービスを複数提供しています。本ハンズオンセミナーではOracle Cloudが提供するコンテナ・サービスを実際に利用しKubernetes環境の構築からコンテナ・アプリケーションのデプロイ、CI/CDまでの一連の流れを体感いただけます。 AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。

1/28 Oracle Cloud Infrastructure ハンズオン 「Oracle Cloud Infrastructure」は、オンプレミスからの大規模ワークロード移行に完全対応する次世代インフラ基盤です。本セミナーでは、Oracle Cloud Infrastructureのサービス概要のご紹介とともに、実際のクラウド環境を利用したハンズオンを半日で体感いただけます。 1/31...

クイズに挑戦:ループ構造の比較(中級者向け)

ユーザーの手動入力をループ処理する場合に使用するループ構造、そこには多くの微妙な違いが... 著者:Simon Roberts、Mikalai Zaikin 2019年8月26日 過去にこのクイズの設問に挑戦したことがある方なら、どれ1つとして簡単な問題はないことをご存じでしょう。クイズの設問は、認定試験の中でも難しめのものに合わせています。「中級者向け」「上級者向け」というレベルは、設問の難易度ではなく、対応する試験による分類です。しかし、ほとんどすべての場合において、「上級者向け」の方が難しくなります。設問は認定試験対策として作成しており、認定試験と同じルールの適用を意図しています。文章は文字どおりに解釈してください。回答者を引っかけようとする設問ではなく、率直に言語の詳細な知識を試すものだと考えてください。 ループ構造を比較したいと思います。 以下のことを行うインタラクティブなコンソール・アプリケーションを書いているものとします。 プロンプトを表示する。 入力としてコマンドを読み取る。 入力がQだった場合、終了する。そうでない場合は、指定されたコマンドを実行し、手順1に戻る。   次のコード構造のうち、このシナリオを実装するために最適な選択肢はどれですか。1つ選んでください。 break文があるforループ 拡張forループ continue文があるwhileループ do/whileループ   解答:この設問では価値判断を求めています。多くの場合、こういった選択問題は悩ましいものです。しかし、この設問で求められているのはかなり一般的な判断です。すべての説明が終わるころには、皆さんにもそう思っていただけるはずです。 設問から2つの重要なポイントが読み取れます。この2つが、適切なループを選ぶ際の手がかりになります。1つ目は、手順1と2を少なくとも1回実行する必要があることです。つまり、少なくとも1回コマンドを読み取るまで、コードは終了しないはずであるということです。そのこととも密接に関連していますが、もう1つわかることは、コマンドを読み取ってからでなければ、プログラムを終了する判断はできないということです。 whileループを使おうとする場合、以上の要件が実装にどう影響するかを考えてみます。まずわかるのが、whileループの条件判定はループに入るときに行われるということです。つまり、条件判定はループ本体より先に実行されます。そのため、このループを使ってプログラムの実行と終了を制御する場合の1つの可能性としては、次の疑似コードに示すように、ループの開始前にプロンプトを表示してコマンドを読み取ることが考えられます。  プロンプトを表示する コマンドを読み取る While (コマンドが"Q"でない) コマンドを実行する ... 現時点では、このアプローチに問題はないように思えるかもしれません。しかし、さらに、次のプロンプトを表示して次のコマンドを読み取る必要があります。この処理はループごとに行う必要があるため、関連するコードをループの中に入れる必要があります。すなわち、同じコードを2か所に書かなければなりません。この条件は、コードに重複する部分が必要だと間接的に述べているのと同じことです。このコードは次のようになります。 プロンプトを表示する コマンドを読み取る While (コマンドが"Q"でない) コマンドを実行する プロンプトを表示する // 重複 コマンドを読み取る // 重複 End-while コードの重複は美しくなく、メンテナンスの際にエラーが起きやすくなります。別のアプローチとして、ループの前にダミーの値をコマンドに設定し、そのコマンドを実行しても何も行わないようにする方法も考えられます。こうすれば重複は回避されますが、実質的に動作を「ハッキング」する特殊な値を使っているため、やはりコードが複雑になり、理解しにくくなる可能性があります。 この問題は、whileループの使用にとって確かに打撃と考えられますが、価値判断を行う前に、他の可能性について考えてみます。 次は、標準forループについて見てみます。実は、forループは、whileループに飾り付けをしただけのものにすぎません。その飾りによって、ループ構造でよくある2つの状況に対処します。1つはループ内で使われる変数の初期化(同時に宣言が行われることもあります)、もう1つは反復に伴う、変数の更新です。しかし、forループの実体は、飾りが付いたwhileループにすぎません。その飾りのいずれかが今回のシナリオに役立つ可能性もありますが、プロンプトと入力読取りのコードが重複するという根本的な問題があることは変わりません。 次に、拡張forループについて見てみます。拡張forループは、Iterableオブジェクトのすべての要素を処理する際に、よりクリーンな手段を提供します(対象となるIterableは、Listなどのコレクションによって提供されるのが一般的ですが、常にそうであるとは限りません)。この問題では、コンソールから入力として項目を読み取る必要があり、入力値がQであればループは終了します。それに対して、拡張forループでは、Iterableから項目を取得し、利用できる項目がなくなったときに終了します。 ユーザーにプロンプトを表示して1行のテキストを読み取り、ユーザーの入力がQでなかった場合にStringを返し、ユーザーの入力がQだった場合には反復を終了するIterableオブジェクトを作ることはできますが、今回のシナリオで使うにはあまりに遠回りで複雑すぎます。この状況で拡張forループが推奨される理由が多いとは考えられないため、最後の選択肢について考えてみます。 残る選択肢は、do/whileループです。このループを繰り返すかどうかを決める条件判定は、do/while構造の最後に置かれます。これによって、いくつかの結果が生まれます。do/whileループは、常に少なくとも1回は実行されます。ループの条件判定に到達するためには、その本体を実行しなければならないからです。別の言い方をすれば、条件判定が行われる前にループの本体が実行されるということです。今回のシナリオには、こちらの方がはるかに適しています。ループ本体でプロンプトを表示し、コマンド入力を読み取ることができるからです。その結果、コードを重複させることなく、条件判定の前にプロンプトの表示と入力の読取りが行われることが保証され、クリーンでシンプルな構造が実現します。 この時点で、今回のシナリオに最適なのは選択肢Dであり、他の選択肢よりもはるかに優れていることは明らかでしょう。そのため、選択肢Dが正解で、A、B、Cは誤りであることがわかります。 いくつか補足しておきます。選択肢Aにはbreak文を使うとあり、選択肢Cにはcontinueを使うとあります。forとbreakの構造を代わりに使用することもできますが、いずれにしても、エレガントな解決策にはなりません。選択肢Aは、次のようにコーディングすることもできるでしょう。 for (;;) { // 事実上の無限ループ // プロンプトを表示する String input = // ユーザーの入力を読み取る if (input.equals("Q")) break; // ループの外に出る executeCommand(input); } しかし、do/whileループを使用したものに比べれば、やはり美しくありません。同じように、whileループでcontinueを使っても、クリーンな解決策に直結することはありません。 正解は選択肢Dです。   Java Magazine December 2019の他の記事 プロパティベース・テストを習得する Arquillian:簡単なJakarta EEテスト ArchUnitでアーキテクチャの単体テストを行う 新しいJava Magazine 作ってみよう:自分だけのテキスト・エディタ(パート1) クイズに挑戦:Collectorsの使用(上級者向け) クイズに挑戦:スレッドとExecutor(上級者向け) クイズに挑戦:ラッパー・クラス(中級者向け) 書評:Core Java, 11th Ed. Volumes 1 and 2 Simon Roberts Simon Roberts:Sun Microsystemsがイギリスで初めてJavaの研修を行う少し前にSunに入社し、Sun認定Javaプログラマー試験とSun認定Java開発者試験の作成に携わる。複数のJava認定ガイドを執筆し、現在はフリーランスでPearson InformITにおいて録画やライブによるビデオ・トレーニングを行っている(直接またはO'Reilly Safari Books Onlineサービス経由で視聴可能)。OracleのJava認定プロジェクトにも継続的に関わっている。   Mikalai Zaikin Mikalai Zaikin:ベラルーシのミンスクを拠点とするIBA IT ParkのリードJava開発者。OracleによるJava認定試験の作成に携わるとともに、複数のJava認定教科書のテクニカル・レビューを行っている。Kathy Sierra氏とBert Bates氏による有名な学習ガイド『Sun Certified Programmer for Java』では、3版にわたってテクニカル・レビューを務めた。

ユーザーの手動入力をループ処理する場合に使用するループ構造、そこには多くの微妙な違いが... 著者:Simon Roberts、Mikalai Zaikin 2019年8月26日 過去にこのクイズの設問に挑戦したことがある方なら、どれ1つとして簡単な問題はないことをご存じでしょう。クイズの設問は、認定試験の中でも難しめのものに合わせています。「中級者向け」「上級者向け」というレベルは、設問の難易度ではなく...

クイズに挑戦:スレッドとExecutor(上級者向け)

ExecutorServiceを使って行う具体的な処理の詳細 著者:Simon Roberts、Mikalai Zaikin 2019年8月26日 過去にこのクイズの設問に挑戦したことがある方なら、どれ1つとして簡単な問題はないことをご存じでしょう。クイズの設問は、認定試験の中でも難しいものに合わせています。「中級者向け」「上級者向け」というレベルは、設問の難易度ではなく、対応する試験による分類です。しかし、ほとんどすべての場合において、「上級者向け」の方が難しくなります。設問は認定試験対策として作成しており、認定試験と同じルールの適用を意図しています。文章は文字どおりに解釈してください。回答者を引っかけようとする設問ではなく、率直に言語の詳細な知識を試すものだと考えてください。 設問(上級者向け):RunnableおよびCallableを使ってワーカー・スレッドを作成し、ExecutorServiceを使って複数のタスクを同時に実行したいと思います。次のクラスについて: class Logger implements Runnable { String msg; public Logger(String msg) { this.msg = msg; } public void run() { System.out.print(msg); } } さらに、次のコード部分について: Stream<Logger> s = Stream.of( new Logger("Error "), new Logger("Warning "), new Logger("Debug ")); ExecutorService es = Executors.newCachedThreadPool(); s.sequential().forEach(l -> es.execute(l)); es.shutdown(); es.awaitTermination(10, TimeUnit.SECONDS); すべてのimport文(表示されていません)が適切に構成されており、コードがコンパイルできると仮定した場合、出力される可能性があるものはどれですか。2つ選んでください。 Error Debug Warning Error Warning Debug Error Error Debug Error Debug   解答:試験対象には、ExecutorsクラスおよびExecutorServiceインタフェースに関連するトピックが含まれています。Executorsクラスが提供するExecutorServiceインタフェースを実装したスレッド・プールも同様です。 Javaの初期のバージョンでは、スレッドの作成や管理はプログラマーの責任でした。また、スレッドは作成が高価であり、限られた、カーネルレベルのリソースでもあるため、「スレッド・プール」を作って、少数のスレッドで独立した小さなジョブを数多く処理できるようにするのが一般的でした。スレッド・プールという考え方は、小さなバックグラウンド・ジョブごとにスレッドを作り、各ジョブの完了後にそのスレッドを破棄するという方法に代わるものです。スレッド・プールでは、少数のスレッドを作って構成し、まとまった仕事(たとえば、Runnableオブジェクト)をスレッドに渡せるようにします。仕事がないスレッドのうち最初のものがジョブを引き受けて実行し、そのジョブが完了すると、そのスレッドは別のジョブを探します。 スレッド・プールは、Java 5でJavaのAPIの一部になりました。ExecutorインタフェースおよびExecutorServiceインタフェースは、スレッド・プールと、スレッド・プールがサポートする操作を汎用化したものです。また、静的ファクトリ・メソッドを含むクラスから、多くのExecutorService実装のインスタンスを生成できます。そのクラスがExecutorsです。java.util.concurrentパッケージには、これら3つの型のほか、多数の高水準なクラスやインタフェースが含まれています。こういったクラスやインタフェースは、並行プログラミングでよく生じる問題に対処しようとする開発者に活用してもらうことを意図したものです。 ベース・インタフェースのExecutorは、Runnableを実装したタスクを実行できます。通常は、ExecutorServiceを使うことが多いでしょう。これはExecutorのサブインタフェースです。ExecutorServiceには、Callableインタフェースを実装したタスクを処理する機能と、スレッド・プールの停止を制御する機能が追加されています。Callableインタフェースを使うことで、マネージャ・タスクから非同期的にタスクの結果を取得できるようになります。多くの場合、このマネージャ・タスクのコードが最初にジョブを送信しますが、必ずそうであるとは限りません。 ExecutorやExecutorServiceの実装は、送信された仕事を実行するために特定の戦略を使う必要はありません。実装の中には、固定サイズのプールを使って同時実行するものもあります。その場合、新しい仕事は、スレッドが利用できるようになるまで待機します。ワークロードが増加した際により多くのスレッドを開始し、需要が少なくなった際にスレッドをクリーンアップする実装もあります。また、1つのスレッドを使って単純にジョブを逐次処理する実装もあります。すべては個々の実装次第です。そのため、プログラマーはアプリケーションのアーキテクチャのニーズに適した実装を注意深く選択する必要があります。Executorsクラスの3つのファクトリ・メソッドでは、前述の動作が生成されます。 newFixedThreadPool newCachedThreadPool newSingleThreadExecutor 最初の2つは複数のワーカー・スレッドを使うプールを作成しますが、newSingleThreadExecutorはすべてのタスクを1つのバックグラウンド・スレッドで次々に実行するサービスを作成します。 本設問のコードでは、キャッシュド・スレッド・プールを使っています。このタイプのExecutorServiceは、必要に応じて新しいワーカー・スレッドを生成し、一定期間使用されなかったスレッドをクリーンアップします。しかし、キャッシュド・スレッド・プールには、作成できるスレッドの最大数に制限がないという重大な欠点があります。この動作により、高負荷時にリソース消費量が高くなり、パフォーマンスが低下する可能性があります。 設問のコードで作成しているプールには複数のスレッドがあることを踏まえれば、プールに送信されたジョブはおそらく同時実行されると考えることができます。そのため、開始される順番がどうであれ、相対的な処理の進み具合を予測することはできません。つまり、出力されるメッセージはどんな順番にもなり得るということです。ここから、選択肢AとBがいずれも正解であることがわかります。 ExecutorServiceが、送信された各ジョブを実行するのは、多くても1回です。状況によっては、ジョブが実行されないことや、完了前に停止されることもあるかもしれません。しかし、ジョブが複数回実行されることはありません。つまり、メッセージが重複することは絶対にありません。よって、選択肢Cは誤りです。 ExecutorServiceに対してshutdownメソッドを呼ぶと、新しいジョブのリクエストは拒否されるようになりますが、実行は最後のジョブが完了するまで続きます。そのため、設問のコードでは、3つのメッセージのうちいくつかが表示されないということはありません。以上より、選択肢Dも誤りであることがわかります。 1点補足しておきます。10秒以内にシャットダウンが完了しない場合、コードは末尾に到達することから、選択肢Dは正解かもしれないと考える方もいるかもしれません。3つのメッセージが確実に表示されると断言することはできるのでしょうか。 ここで、いくつかの見解が関連してきます。まず、このジョブが完了するまでに10秒かかる可能性は非常に低いということです。また、2つの選択肢(AとB)が明らかに正解であることを考えれば、このような起こりそうもないことは除外できます。 もちろん、ホストで極端な状況が発生すれば、ジョブが10秒以内に完了しない可能性もあります。そこから、選択肢Dはやはり正解かもしれないと思うかもしれません。たとえば、設問のコードが起動した瞬間に、OSのアップデートのインストールが始まった場合を考えてみてください。設問のコードには、仮想マシンが強制シャットダウン中であることを示す内容は含まれていないことに注意してください。このスレッド・プールのスレッドは非デーモン・スレッドであるため、ジョブが完了するまで仮想マシンはシャットダウンされません。そのため、プログラムの実行が許可されれば、3つのメッセージが表示されます。 正解は選択肢AとBです。   Java Magazine December 2019の他の記事 プロパティベース・テストを習得する Arquillian:簡単なJakarta EEテスト ArchUnitでアーキテクチャの単体テストを行う 新しいJava Magazine 作ってみよう:自分だけのテキスト・エディタ(パート1) クイズに挑戦:Collectorsの使用(上級者向け) クイズに挑戦:ループ構造の比較(中級者向け) クイズに挑戦:ラッパー・クラス(中級者向け) 書評:Core Java, 11th Ed. Volumes 1 and 2 Simon Roberts Simon Roberts:Sun Microsystemsがイギリスで初めてJavaの研修を行う少し前にSunに入社し、Sun認定Javaプログラマー試験とSun認定Java開発者試験の作成に携わる。複数のJava認定ガイドを執筆し、現在はフリーランスでPearson InformITにおいて録画やライブによるビデオ・トレーニングを行っている(直接またはO'Reilly Safari Books Onlineサービス経由で視聴可能)。OracleのJava認定プロジェクトにも継続的に関わっている。   Mikalai Zaikin Mikalai Zaikin:ベラルーシのミンスクを拠点とするIBA IT ParkのリードJava開発者。OracleによるJava認定試験の作成に携わるとともに、複数のJava認定教科書のテクニカル・レビューを行っている。Kathy Sierra氏とBert Bates氏による有名な学習ガイド『Sun Certified Programmer for Java』では、3版にわたってテクニカル・レビューを務めた。

ExecutorServiceを使って行う具体的な処理の詳細 著者:Simon Roberts、Mikalai Zaikin 2019年8月26日 過去にこのクイズの設問に挑戦したことがある方なら、どれ1つとして簡単な問題はないことをご存じでしょう。クイズの設問は、認定試験の中でも難しいものに合わせています。「中級者向け」「上級者向け」というレベルは、設問の難易度ではなく、対応する試験による分類です。しか...

クイズに挑戦:ラッパー・クラス(中級者向け)

Integerラッパー・クラスを使って2つの整数のインスタンスを作成したときに、値を比較する正しい方法 著者:Simon Roberts、Mikalai Zaikin 2019年8月26日 過去にこのクイズの設問に挑戦したことがある方なら、どれ1つとして簡単な問題はないことをご存じでしょう。クイズの設問は、認定試験の中でも難しいものに合わせています。「中級者向け」「上級者向け」というレベルは、設問の難易度ではなく、対応する試験による分類です。しかし、ほとんどすべての場合において、「上級者向け」の方が難しくなります。設問は認定試験対策として作成しており、認定試験と同じルールの適用を意図しています。文章は文字どおりに解釈してください。回答者を引っかけようとする設問ではなく、率直に言語の詳細な知識を試すものだと考えてください。 設問(中級者向け):Boolean、Double、Integer、などのラッパー・クラスを使ったコードを作成したいと思います。 次のコード部分について: String one = "1"; Boolean b1 = Boolean.valueOf(one); // line n1 Integer i1 = new Integer(one); Integer i2 = 1; if (b1) { System.out.print(i1 == i2); } どのような結果になりますか。1つ選んでください。 line n1で実行時例外が発生する true false コードは実行されるが、何も出力されない   解答:この設問は、プリミティブのラッパー・クラス、とりわけBooleanクラスとそのファクトリに関する奇妙な側面について問うものです。この設問で取り上げた内容がそっくりそのまま実際の試験に出題される可能性は低いでしょう。というのも、解けるかどうかは仕様を丸暗記しているか次第であり、試験ではそのような設問は回避されることが多いからです。ただし、この設問では、1つの問題で複数の側面にわたる理解と知識を確認しています。運が良ければ、その点がさらにおもしろいものになります。 ラッパーでは、インスタンスを取得する方法が主に3つあります。各ラッパーでは、valueOfという名前のメソッドで静的ファクトリが提供されています。また、ラッパー型の変数に、型が一致するプリミティブから代入する場合のように、コンテキストが十分明示的であれば、オートボクシングが行われます。オートボクシングは、構文の単なる省略表記で、コンパイラにvalueOfメソッドを呼び出すコードを書かせることができ、ソース・コードが簡潔になります。3つ目のアプローチは、newキーワードを使ってコンストラクタを呼び出すというものです。実は、この3つ目のアプローチはJava 9で非推奨になっています。この設問のねらいの1つは、なぜ非推奨になったのかを問うことにあります。 Javaで、newキーワードを使ってコンストラクタを呼び出すたびに起きる可能性があるのは、2つのことだけです。すなわち、指定されたとおりの名前の型の新しいインスタンスが生成されて返されるか、例外が発生するかのいずれかです。実のところ、これは制約です。現在では、一般的にファクトリ・メソッドが好まれています。これら2つの効果を持たせることができるうえに、追加の結果を提供することもできるからです。 コンストラクタでは不可能で、ファクトリでは可能な機能の1つに、リクエストに沿った既存のオブジェクトを返こすとがあります。Integerラッパーが不変であることを考えれば、同じ数値を表す、この型の2つのオブジェクトは完全に交換可能です。そのため、同じ値を表す2つのオブジェクトを作るのは、メモリの無駄です。さらに、このアプローチでは、このようなオブジェクトをequals(Object o)メソッドではなく==を使って比較できます。Integerクラスでは、通常、-128から+127までの値がこのようにして再利用されます。 (補足ですが、この動作は、new String("1")のようにしてStringオブジェクトを作成する代わりに、Stringリテラルを使用することと実質的に同じです。) ファクトリ・メソッドには有利な点があと2つあります。複数のファクトリを作成する場合、各メソッドを異なる名前にすることができます。つまり、適切であれば、同じ引数型リストを受け取れるということです。コンストラクタでは、互いが有効なオーバーロードである必要があるため、これを行うのは不可能です。 3つ目の有利な点は、コンストラクタでは指定されたとおりの名前の型のオブジェクトを必ず返すということです。ファクトリでは、代入において宣言された型に対応するものであれば、何でも返すことができます(インタフェースの実装も含みます。こうすることにより、実装の詳細をうまく隠すことができます)。 この設問にもっとも関連するのは、Boolean.valueOf(...)を使う場合です。この場合、厳密に2通りの定数オブジェクトを得ることになります。1つはBoolean.TRUE、もう1つはBoolean.FALSEです。この2つは、追加のメモリを占有することなく、必要に応じて何度でも再利用されます。この動作は、newの呼出しでは不可能です。 ところで、ほとんどのラッパーのファクトリは、NULL引数や、作成する型を適切に表していない文字列が渡された場合、例外をスローします。たとえば、Integer.valueOfファクトリを"5"ではなく"five"という引数で呼び出した場合です。ただし、java.lang.Booleanクラスのファクトリは、引数の文字列が存在し、"true"という値(大文字、小文字は区別しません)が含まれているかどうかを確認します。その条件を満たす場合は、値Boolean.TRUEを返します。そうでない場合は、引数についてそれ以上何も知らせることなく、Boolean.FALSEを返します。つまり、NULL引数やテキスト"nonsense"でファクトリを呼び出しても、Boolean.FALSEが返され、例外はスローされません。 そのため、line n1のコードでは、例外はスローされず、変数b1にBoolean.FALSEが代入されると判断できます。そのため、選択肢Aは誤りです。 次は、if文の動作と、そこで行われている比較について吟味する必要があります。 一般的なルールに、if文の条件式はboolean型でなければならないというものがあります。Booleanオブジェクトがアンボクシングされて、そのままboolean型になることは明らかでしょう。ここで疑問を感じたとしたら、コードがコンパイルできないのではということかもしれません。そう考えるのは、おかしなことではありません。Java 5でオートボクシングが導入されるまで、このコードはコンパイルできなかったからです。しかし、そう心配したとしても、その点について触れている選択肢はないため、見た目どおりの動作が起こると考えて問題ありません。 この場合、b1が参照するオブジェクトはfalse値を表していることを確認しました。そのため、ifの条件は満たされず、コードの本体は実行されません。そこから、選択肢Dは正解であると判断できます。 実行されないことはわかりましたが、この議論に関連して、if文の中にあるprint呼出しの引数が評価されるとしたら何が起こるかについて考えることには価値があると思われます。 Javaでは、2つの形態の等価比較を提供しています。1つは、コア言語の一部である==演算子です。もう1つは、実質的にAPI機能と言えるequals(Object o)メソッドです。このメソッドはjava.lang.Objectクラスで定義されているため、すべてのオブジェクトで利用できます。しかし、対象のクラスでこのメソッドが実装されていない場合、有用な動作とならない可能性があります。この2つは、どの場面にいずれを使うかを把握し、正しく使い分けることが重要です。しかし、この設問には登場するのは==演算子だけであるため、こちらを詳しく見てみます。 ==演算子では、2つの式の値を比較します。これは一見簡単なように思えますが、それぞれの値で式の基本型が異なる場合、簡単とは言い切れません。==の外見上の効果は2つの型でまったく異なるため、この事実は重要です。ところで、ここでは意図的に「式」という用語を使っています。変数はシンプルな式の1つです。変数の値と型という面から考えてみても、この議論は成り立ちます。ただしその場合、真実の一部だけを捉えていることになります。 式を大きく2つに分ければ、プリミティブ(boolean、byte、short、char、int、long、float、doubleという8つの型のいずれか)と、いわゆる参照となります。参照は、メモリ内の別の場所にあるオブジェクトを見つけるために使う値という意味で、ポインタとよく似ています。 式がプリミティブタイプである場合、実のところ、関心の対象はその式の値です。そのため、あるint式の値が32であれば、事実、その式の値は32をバイナリで表現したものになります。そんなことは当たり前だと言われるかもしれません。問題は、変数がたとえばInteger型への参照タイプであり、その変数が、32という値を含むオブジェクトを参照するために使用されているような場合です。この場合、変数の値は32にはなりません。そうではなく、32を含むオブジェクトをJVMが見つけられるようにするための魔法の数値(参照)になります。つまり、参照タイプ(前述の8つのプリミティブを除いたすべてのものを指すことを思い出してください。したがって、Integer式も含まれます)の場合、==という条件で判定されるのは、2つの式が同じ意味を持つかどうかではなく、厳密に同じオブジェクトを参照しているかどうかです。重要なことに、32という値を含む2つのIntegerオブジェクトがあり、その2つが異なるオブジェクトである場合、それぞれの参照値は異なることになります。そのため、==を使って、それぞれを参照する式を比較すると、結果はfalseになります。 ここまで来れば、次のコードがあった場合、 Integer v1 = new Integer("1"); Integer v2 = new Integer("1"); System.out.print(v1 == v2); 確実にfalseが出力されることは明白でしょう。先ほども触れましたが、newを呼び出すと、指定されたとおりの名前の型の新しいオブジェクトか、または例外が必ず生成されます。つまり、v1とv2は必ず違うオブジェクトを参照します。すなわち、==操作は必ずfalseを返します。 代わりに次のコードがあったとします。 Integer v1 = new Integer("1"); Integer v2 = 1; System.out.print(v1 == v2); 設問のコードととてもよく似ており、片方ではコンストラクタを呼び出し、もう片方ではアンボクシングを使っています。このコードでも、確実にfalseが出力されます。 コンストラクタで生成されるオブジェクトは一意な新しいオブジェクトであるため、オートボクシングされた値を生成するファクトリから返されるものとは異なります。 多くの場合、不変オブジェクトのファクトリは、同じ引数で呼ばれた場合には毎回同じオブジェクトを返すようにコードが書かれています。IntegerクラスのvalueOf(int)メソッドのAPIドキュメントには、次のように書かれています。 「このメソッドは、-128から127の範囲の値を常にキャッシュしますが、この範囲に含まれないその他の値をキャッシュすることもあります」 言い換えれば、次のコード Integer v1 = Integer.valueOf(1); Integer v2 = Integer.valueOf(1); System.out.print(v1 == v2); では、確実にtrueが出力されます。 先ほど引用した仕様は、valueOf(int)メソッドのドキュメントにのみ書かれており、valueOf(String)では触れられていません。しかし実際は、両方のメソッドで同じプーリング動作が見られます。 もちろん、この設問で扱っているのは2つのIntegerオブジェクトです。片方はコンストラクタで生成され、もう片方は(Integer.valueOf(int)メソッドを使って)オートボクシングで生成されています。つまり、if文の本体に入力されたとすれば、出力はfalseになりました。しかし、選択肢Dが正解であることはすでに確定しているため、選択肢BとCは誤りとなります。ここまで説明してきたことは、おもしろい補足にすぎません。もちろん、実際におもしろいと思っていただけると幸いです。正解は選択肢Dです。   Java Magazine December 2019の他の記事 プロパティベース・テストを習得する Arquillian:簡単なJakarta EEテスト ArchUnitでアーキテクチャの単体テストを行う 新しいJava Magazine 作ってみよう:自分だけのテキスト・エディタ(パート1) クイズに挑戦:Collectorsの使用(上級者向け) クイズに挑戦:ループ構造の比較(中級者向け) クイズに挑戦:スレッドとExecutor(上級者向け) 書評:Core Java, 11th Ed. Volumes 1 and 2 Simon Roberts Simon Roberts:Sun Microsystemsがイギリスで初めてJavaの研修を行う少し前にSunに入社し、Sun認定Javaプログラマー試験とSun認定Java開発者試験の作成に携わる。複数のJava認定ガイドを執筆し、現在はフリーランスでPearson InformITにおいて録画やライブによるビデオ・トレーニングを行っている(直接またはO'Reilly Safari Books Onlineサービス経由で視聴可能)。OracleのJava認定プロジェクトにも継続的に関わっている。   Mikalai Zaikin Mikalai Zaikin:ベラルーシのミンスクを拠点とするIBA IT ParkのリードJava開発者。OracleによるJava認定試験の作成に携わるとともに、複数のJava認定教科書のテクニカル・レビューを行っている。Kathy Sierra氏とBert Bates氏による有名な学習ガイド『Sun Certified Programmer for Java』では、3版にわたってテクニカル・レビューを務めた。

Integerラッパー・クラスを使って2つの整数のインスタンスを作成したときに、値を比較する正しい方法 著者:Simon Roberts、Mikalai Zaikin 2019年8月26日 過去にこのクイズの設問に挑戦したことがある方なら、どれ1つとして簡単な問題はないことをご存じでしょう。クイズの設問は、認定試験の中でも難しいものに合わせています。「中級者向け」「上級者向け」というレベルは、設問の難易度...

クイズに挑戦:Collectorsの使用(上級者向け)

クイズに挑戦:Collectorsの使用(上級者向け) Collectorsクラスから想定どおりの結果を得るために注意すべきこと 著者:Simon Roberts、Mikalai Zaikin 2019年8月26日 過去にこのクイズの設問に挑戦したことがある方なら、どれ1つとして簡単な問題はないことをご存じでしょう。クイズの設問は、認定試験の中でも難しいものに合わせています。「中級者向け」「上級者向け」というレベルは、設問の難易度ではなく、対応する試験による分類です。しかし、ほとんどすべての場合において、「上級者向け」の方が難しくなります。設問は認定試験対策として作成しており、認定試験と同じルールの適用を意図しています。文章は文字どおりに解釈してください。回答者を引っかけようとする設問ではなく、率直に言語の詳細な知識を試すものだと考えてください。 collectメソッドと、Collectorsクラスのグループまたはパーティションのデータを使ってコレクションに結果を保存したいと思います。次のStudentクラスがあり、初期化済みで未使用のStream<Student> sがスコープ内にあるとします。このsには、さまざまな年齢の学生が含まれています。 class Student { private String name; private Integer age; Student(String name, Integer age) { this.name = name; this.age = age; } public String getName() { return name; } public Integer getAge() { return age; } } 次のコード部分のうち、18歳未満の学生の数と18歳以上の学生の数が最適な方法で表示されるものはどれですか。1つ選んでください。 s.collect(Collectors.groupingBy( Student::getAge() >= 18, Collectors.counting())) .forEach((c, d) -> System.out.println(d)); s.collect(Collectors.groupingBy( a -> a.getAge() >= 18, Collectors.mapping( Student::getName, Collectors.counting()))) .forEach((c, d) -> System.out.println(d)); s.collect(Collectors.partitioningBy( a -> a.getAge() >= 18, Collectors.counting())) .forEach((c, d) -> System.out.println(d)); List<Integer> l = Arrays.asList(0, 0); s.forEach(w -> { if (w.getAge() >= 18) { l.set(1, l.get(1) + 1); } else { l.set(0, l.get(0) + 1); }}); l.forEach(System.out::println); 解答:この設問は、データを収集し、ある基準に従ってグループ化するいくつかの方法を示しています。選択肢A、B、Cでは、CollectorsクラスのユーティリティとStream.collectメソッドを使ってこれを実現しようとしています。選択肢Dでは、その処理を手作業で行おうとしています。 まずは、簡単な選択肢から見ていきます。選択肢Aのコードには、重大な構文エラーが存在します。ここでは、メソッド参照を使用し、次の式でメソッドを呼び出そうとしています。 Student::getAge() この構文は正しくありません。メソッド参照の構文をこのような形で使うことはできません。そのため、選択肢Aは誤りです。 通常、この試験では「人間コンパイラ」的な問題は避けられる傾向にあります。IDE全盛のこの時代では、コードを打ち込めばすぐに構文チェックが行われるため、そのようなスキルは役立つものではないからです。この選択肢が誤りであると判断できる理由がそれだけなら、実際の試験でこの選択肢が採用されることはないでしょう。しかし、この選択肢には、誤りであると判断できる理由が他に2つあります。1つは、別の選択肢にあるアプローチの方が設計的に優れていることです。少しばかりではありますが、実際の改善であることはもうすぐわかっていただけるはずです。2つ目の理由は、他に正解があるものの、この設問が単一選択問題であることです。そのため、別の答えを見つけた時点で、注意深くコードを見るようになり、エラーに気づくことになるはずです。ここでヒントとなるのは、この試験の際に、正しいと思われる最初の答えをそのまま解答に選ぶのは賢明でないということです。時間が足りない場合以外、他のすべての答えが確かに誤りであると納得するまで時間をかけるべきです。 注目すべきは、構文エラーを含む式 Student::getAge() >= 18 を正しい式 a -> a.getAge() >= 18 に置き換えれば、選択肢Aから正しい出力が得られ、その場合に問題となるのは設計の質だけであるという点です。 ただし、この時点で、選択肢Aをすぐに除外すべきであることは明らかであり、選択肢Aよりも優れた設計のアプローチが見つかって、その設計が優れている理由がわかることははっきりしています。 選択肢Bのコードは問題なくコンパイルでき、正しい結果が出力されます。これを理解するために、Collectionsクラスが持ついくつかの重要な動作について詳しく見てみます。groupingByメソッドは、関数(Function)を引数として受け取るCollector動作を生成します。この関数を、分類関数(classifier)と呼びます。たとえば、次のコードについて考えてみます。名前のストリームに対してgroupingByコレクション操作を実行するものです。 Stream.of("Fred", "Jim", "Sheila", "Chris", "Steve", "Hermann", "Andy", "Sophie") .collect(Collectors.groupingBy(n -> n.length())) ここでの分類関数は、名前(String)を受け取ってその長さを返す次の式です。 n -> n.length() 結果として、表1に示すようなMap<Integer, List<String>>が生成されます。 表1:キーと、各キーに関連付けられた値 分類関数からキーとして返されるそれぞれの値がこのMapにどのように格納されているかと、各キーに関連付けられた値が、そのキーを生成したストリームのアイテムすべてを含むListであることに注目してください。 groupingBy動作の亜種として、「ダウンストリーム・コレクタ」を持つものがあります。ダウンストリーム・コレクタを使うことにより、特定のキーを生成するアイテムを、同種のアイテムすべてからなるリストにそのまま追加するのではなく、後続のコレクション操作を使って各アイテムを処理することができます。これは、Listに送信されるアイテムを処理するセカンダリ・ストリーム・プロセスのようなものです。ダウンストリームでよく使われるコレクタの1つが、countingコレクタです。このコレクタを処理で使うことにより、値を名前のリストからリストの要素数に変えることができます。 次のコード Stream.of("Fred", "Jim", "Sheila", "Chris", "Steve", "Hermann", "Andy", "Sophie") .collect(Collectors.groupingBy( n -> n.length(), Collectors.counting())) は、表2に示すMap<Integer, Long>を返します。 表2:ダウンストリーム・コレクタを使用した場合のキーと、各キーに関連付けられた値 選択肢Bの動作はこの考え方に似ていますが、異なる点もいくつかあります。まず、分類関数(すなわち、結果のMapのキー)が数値ではなくブール値であることです。これは問題ありません。18歳以上の学生と18歳未満の学生を分類するという目的に沿っているからです。しかし、選択肢Bのコードでのダウンストリーム操作は1つではなく、2つの操作を連鎖させています。もちろんこのような連鎖は許可されており、大変役立つこともあります。しかし、この設問の場合、最初のダウンストリーム・コレクタで実際に行っているのは、各StudentオブジェクトからStudentの名前を抽出するマッピング操作です。2つ目のダウンストリーム・コレクタでは、その結果として得られる名前の数を数えています。 マッピング操作が結果を誤ることはありません。このコードでは実質的に、18歳以上の学生と18歳未満の学生の名前が数えられ、同じ数値が生成されます。ただし、これは無駄な努力です。そのため、このコードは効率の面でも、可読性の面でも、最適なものではありません。無関係で紛らわしいコードが含まれており、混乱が生じるリスクがあるからです。このような無駄な努力をしていない別の選択肢が後ほど登場するため、そこから選択肢Bは誤りであることがわかります。選択肢Bでは正しいレスポンスが生成されますが、もっとも効率のよい選択肢ではありません。 Collectorsクラスには、groupingBy動作のファクトリに加えて、似たような結果を生成する別のファクトリも存在します。このファクトリは、partitioningByと呼ばれています。動作の違いは、任意の型のキーを持つMapを作成するのではなく、Boolean型のキーを持つMapを作成するという点だけです。そのため、分類関数として関数(Function)ではなく条件(Predicate)を指定します。選択肢Cでは、partitioningBy動作を使って正しい出力が行われています。これは、2つの理由で選択肢Bよりも優れています。1つ目は、学生の名前を抽出するという無駄な手順が含まれていないことです。2つ目は、partitioningByが、単純なtrue/falseの結果を使ってグループ化するという目的のみに特化したものであることです。そのため、設計的に(少しばかり)優れた選択です。同じ論理で、(構文が有効だったとしても)選択肢Aより優れています。 手作業で分類するコードを使っている選択肢Dでも、正しい結果が生成される可能性があります。重大な問題は、このコードが副作用によって動作していることです。具体的に言えば、ラムダ式の外側にある変数を変更している部分です。この種の動作は、安全に同時実行(パラレル実行)することができません。ストリームは簡単にパラレル・モードで実行できるからこそ、特にストリームベースのシステムではこの種のコードは避けるべきです。 なお、この考え方が、ラムダ式(およびその登場より前のメソッド・ローカル・クラス)が設計されたときに漠然と示されていたことに注目すべきです。具体的に言うなら、ラムダ式やネスト・クラスの中からは、実質的にfinalである場合を除き、他のメソッド・ローカル変数へのアクセスが禁止されているという点です。選択肢Dのコードでは、実質的にfinalな参照を使って、参照先のListに格納されている可変データにアクセスすることで副作用が発生しています。 このコードは問題なくコンパイルでき、ストリームが逐次実行されれば、正しい結果が出力されます。ただし、設計はよくなく、ストリームがパラレルであれば失敗します。設計に問題があり、ストリームがパラレルの場合は失敗するため、選択肢Dは誤りです。 正解は選択肢Cです。   Java Magazine December 2019の他の記事 プロパティベース・テストを習得する Arquillian:簡単なJakarta EEテスト ArchUnitでアーキテクチャの単体テストを行う 新しいJava Magazine 作ってみよう:自分だけのテキスト・エディタ(パート1) クイズに挑戦:ループ構造の比較(中級者向け) クイズに挑戦:スレッドとExecutor(上級者向け) クイズに挑戦:ラッパー・クラス(中級者向け) 書評:Core Java, 11th Ed. Volumes 1 and 2 Simon Roberts Simon Roberts:Sun Microsystemsがイギリスで初めてJavaの研修を行う少し前にSunに入社し、Sun認定Javaプログラマー試験とSun認定Java開発者試験の作成に携わる。複数のJava認定ガイドを執筆し、現在はフリーランスでPearson InformITにおいて録画やライブによるビデオ・トレーニングを行っている(直接またはO'Reilly Safari Books Onlineサービス経由で視聴可能)。OracleのJava認定プロジェクトにも継続的に関わっている。   Mikalai Zaikin Mikalai Zaikin:ベラルーシのミンスクを拠点とするIBA IT ParkのリードJava開発者。OracleによるJava認定試験の作成に携わるとともに、複数のJava認定教科書のテクニカル・レビューを行っている。Kathy Sierra氏とBert Bates氏による有名な学習ガイド『Sun Certified Programmer for Java』では、3版にわたってテクニカル・レビューを務めた。

クイズに挑戦:Collectorsの使用(上級者向け) Collectorsクラスから想定どおりの結果を得るために注意すべきこと 著者:Simon Roberts、Mikalai Zaikin 2019年8月26日 過去にこのクイズの設問に挑戦したことがある方なら、どれ1つとして簡単な問題はないことをご存じでしょう。クイズの設問は、認定試験の中でも難しいものに合わせています。「中級者向け」「上級者向け」とい...

作ってみよう:自分だけのテキスト・エディタ(パート1)

新連載:階層化設計と反復型開発を使ってライン・エディタをテキスト・エディタに進化させる 著者:Ian Darwin 2019年8月20日 本記事のタイトルを読んだ方は、「なぜJavaでテキスト・エディタを作りたいのだろうか。JavaはエンタープライズWebアプリのためのものではないのか」と思うかもしれません。私の最初の答えは、「とんでもない」です。Javaは現在もデスクトップで使われており、活躍しています。私の次の答えは、一部のJava開発者にとって主な「安全地帯」であるWeb環境から離れることで、設計や、興味深い実装の問題に焦点を移すというものです。 本記事では、反復型実装により、簡単なラインモード・テキスト・エディタを作ることに的を絞ります。つまり、シンプルな実装から始め、新機能を追加しながら設計を更新し、その再実装を行います。 次回の記事では、このエディタをグラフィカルなデスクトップ・エディタに進化させます。形はさまざまに変わっても、実体が純粋なテキスト・エディタである点、つまり、プレーン・テキストのファイルを変更するプログラムであることは変わりません。プレーン・テキストとは、フォントや色が変わらないテキストです。バッチ・ファイルやスクリプト・ファイル、プログラムのソース・ファイル、構成ファイル、ログ・ファイルなど、今でも世界中でコンピュータ向けの情報の大部分に使われています。プレーン・テキスト・エディタと完全なワード・プロセッサの間には、大きな隔たりがあります。ワード・プロセッサは、文字の書体やサイズや色の選択、画像やスプレッドシートの埋め込み、テキストの左揃え、右揃え、中央揃えなどの多くの機能を備えています。短い連載記事でこれらすべてを紹介するのは難しいと思われることから、まずはプレーン・テキストに焦点を当てることにします。 エディタを設計する場合、主に2つのことを考える必要があります。1つはユーザー・インタフェース(UI)またはコマンド・レイヤー、もう1つはバッファ管理です。UIまたはコマンド・レイヤーでは、ユーザーがメモリ内のバッファに対して何をすることができるかを定義します。こういったタスクは、たとえば、ライン・エディタであれば簡単なコマンド、スクリーン・エディタならマウス操作、インタラクティブ・システムなら音声コマンドになるでしょう。バッファ管理とは、ユーザーがバッファ内のテキストをどのように扱うかということです。通常、テキスト・エディタ(およびその強力な親戚であるワード・プロセッサ)は、変更しているファイルのコピーをメモリ内に保持しています。このコピーは、メモリ内のバッファに保管されます。エディタでは、ユーザーがエディタを終了したとき、または何らかの「保存」コマンドが発行されたときに、この変更されたテキストが元のファイルの代わりにディスクに書き込まれます。バッファ管理はモデル・コードとしても知られ、メモリ内にある編集中のファイルの内容を管理することに関係しています。最終的なプロダクトを便利でメンテナンスしやすいものにするためには、UIとバッファ管理、そしてその間にあるすべての重要なインタフェースをうまく設計する必要があります。   コードのレイヤー間の境界 Javaインタフェースの定義は、コードの論理レイヤーを分離するための強力(で一般的)な方法です。アプリケーションのレイヤー間や、(現在または将来的に)複数の実装を持つ可能性が高いクラスでは、インタフェースを使うべきです。その結果、クラスが特定の実装ではなく、インタフェースに依存するようにすることができます。 この場合、BufferPrimsインタフェースが両方のニーズに合致します。このインタフェースはレイヤー境界であり、複数の実装を持ちます。これは、バックエンドにデータベースがあるアプリケーションに似ています。このようなアプリケーションではおそらく、中間(ビジネス・ロジック)レイヤーとデータベースのコードの間にインタフェースが存在するでしょう。これにより、JDBC、Java Persistence API(JPA)/Hibernate、場合によってはNoSQLデータベースを切り換えて使用できるようになります。JPAのEntityManagerやHibernateのSessionは、この目的では十分に汎用的だと言う方もいるでしょう。また、アプリケーション固有のインタフェースを使うことを提案する方もいるかもしれません。すべてのアプリケーションに当てはまる正しい1つの答えはなく、これは設計上の考慮事項になります。 エディタには、コマンド・レイヤーとバッファ管理レイヤーとの間のインタフェースが必要です。このレイヤー間のインタフェースはとても簡単なもので、たとえば次のようになります。 public interface BufferPrims { addLineAfter(int afterLine, String newLine); deleteLine(int lineNumber); replaceText(oldText, newText); } このインタフェースでは、バッファ管理がどのように動作するかについてコマンド・コードにほとんど伝えていません。同時に、UIがどのように動作するかについてバッファ管理に何も伝えていません。この点は重要です。相手方に影響を与えずに片方を交換できることが望ましいからです。これは、レイヤー化されたソフトウェア全般に当てはまります。レイヤーは、その上にあるレイヤーについて何も知るべきではありません(たとえば、さまざまなUIから呼び出せるようにするためです)。また、知っているべきなのは、直下のレイヤーを呼び出す方法だけで、他には何も必要ありません。 実際のエディタを作るためには、もう少し包括的なインタフェースが必要です。ここでは、次のようにまとめました。 public interface BufferPrims { final int NO_NUM = 0, INF = Integer.MAX_VALUE; void addLines(List<String> newLines); void addLines(int start, List<String> newLines); void deleteLines(int start, int end); void clearBuffer(); void readBuffer(String fileName); void writeBuffer(String fileName); int getCurrentLineNumber(); String getCurrentLine(); int goToLine(int n); int size(); // 古いコレクションの時点での行数 /** 1つまたは複数の行を取得 */ String getLine(int ln); List<String> getLines(int i, int j); /** 現在の行のみを対象に、最初またはすべての * 「古い」正規表現を「新しい」テキストに置き換える */ void replace(String oldRE, String newStr, boolean all) /** 各行の最初またはすべての検索対象を置き換える */ void replace(String oldRE, String newStr, boolean all, int startLine, int endLine); boolean isUndoSupported(); /** 直近の操作を元に戻す * オプション・メソッド */ default void undo() { throw new UnsupportedOperationException(); } } ほとんどの操作は単純と思われます。本記事のソース・コードでは、BufferPrimsインタフェースの3つの実装を提示しています。オプションのundoメソッドは、1つの実装には含まれていますが、他の2つには含まれていません。この実装については、以前にCommandデザイン・パターンについての記事で説明しました。 ここにはread()やwrite()を入れるべきではないと思う人や、メイン・プログラムで1行ずつファイルを読み取り、いずれかのadd()メソッドを使って行を取り込むべきだと考える人もいるかもしれません。このインタフェースにread()メソッドやwrite()メソッドがあるのは、効率のためです。1回の読取り操作でファイル全体を読み取るバージョンがあっても構わないでしょう。   バッファ管理 大きく異なる複数の実装が存在するのは、インタフェースが合理的な設計に基づいている証拠です。しかし、このことは効率について何も触れていません。効率を気にしないのであれば、1つのStringオブジェクトにすべてを保管することもできます。しかし、文字列は不変であるため、このアプローチでは多くの再割当てが必要になります。そのため、純粋な実装の基盤という面では、StringBuilderやStringBufferの方が優れています。実際には、バッファ・プリミティブ(BufferPrims)の最初の実装では、BufferPrimsStringBufferを使っています。 StringBufferには、バッファの内容を変更する組込みメソッドなどのいくつかのメリットがあります。しかし、本質的に単語のリストのリスト(さらに正確に言えば、行のリスト)であるものを表す自然な構造ではありません。StringBufferの実装(この実装が可能であることを示すために書くことにしました)では、行が始まる場所と終わる場所を見つけるためだけに、いくらかの作業が必要になります。 整合性を保つため、各行は改行文字1文字('\n')で終わり、キャリッジ・リターン('\r')は完全に禁止することを前提としました。このアプローチにより、改行文字を探すだけで行が終わる場所と次の行が始まる場所を見つけることができます。このクラスのほとんどの操作は、StringBufferのメソッドを呼び出して、そのStringBufferの特定の位置にある文字の取得や設定を行うことで終わります。 たとえば、次に示すのは現在の行の内容を取得するコードです。 @Override public String getCurrentLine() { int startOffset = findLineOffset(current); int len = findLineLengthAt(startOffset); return buffer.substring(startOffset, startOffset + len); } findLineOffsetメソッドでは、正規表現を使って行を検索します。これは改行文字を探すforループほど簡単ではありませんが、実行可能で純粋な実装だと言えます。 同様に、StringBufferベースの行検出にも、同じ2つのメソッドを使っています。 @Override public void deleteLines(int startLine, int endLine) { if (startLine > endLine) { throw new IllegalArgumentException(); } int startOffset = findLineOffset(startLine), endOffset = findLineOffset(endLine); buffer.delete(startOffset, endOffset + findLineLengthAt(endOffset) + 1); } おそらく、もっとも複雑なコマンドは置換コマンド(s)でしょう。「UIとコマンド構造」のセクションでは、いくつかの種類の置換コマンドについて説明します。UIレイヤーでは、すべてのコマンド・オプションを解析した後、次に示す2つのメソッドのいずれかを呼び出す必要があります。 void replace(String oldRE, String newStr, boolean all); void replace(String oldRE, String newStr, boolean all, int startLine, int endLine); all変数では、置換対象となるのが一致したすべての結果なのか、1つ目だけなのかを制御します。次に示すのが、replaceを1行で実装したものです。 @Override public void replace(String oldRE, String newStr, boolean all) { int startOffset = findLineOffset(current); int length = findLineLengthAt(startOffset); String tmp = buffer.substring(startOffset, length); tmp = all ? tmp.replaceAll(oldRE, newStr) : tmp.replace(oldRE newStr); buffer.replace(startOffset, length, tmp); } 第2の実装:バッファ・コードの第2の実装となるのが、BufferPrimsNoUndoです。この実装では、バッファのデータをList<String>に格納しています。行単位での処理は、こちらのデータ構造を使った方が簡単です。たとえば、現在の行を取得する処理は、次のコードだけで実現できます。 @Override public String getCurrentLine() { return buffer.get( lineNumToIndex(current)); } (行番号は1から始まりますが、Listのインデックスは0から始まります。そのため、lineNumToIndex()メソッドで行番号からリストのインデックスに変換しています。こうする方が、毎回1を引くよりもきれいに見えます。) 「行の削除」操作も簡単になります。 @Override public void deleteLines(int startLnum, int end) { int startIx = lineNumToIndex(startLnum); for (int i = startIx; i < end; i++) { if (buffer.isEmpty()) { System.out.println( "?Deleted all lines!"); break; } buffer.remove(startIx); // iではない } current = startLnum; } なお、このクラスのメソッドの一部が、AbstractBufferPrimsクラスに格納されていることに注意してください。このクラスは、両方のListベースの実装で使用しています。 第3の実装:最後のBufferPrimsWithUndoは、一歩先に進んだ実装で、その名のとおり「元に戻す」操作を実装しています。簡潔に言えば、バッファを変更する操作を行うたびに、その逆の操作を行うコードを含むラムダ式も作成されます。たとえば、ここでの「行の削除」操作は次のようになります。 @Override public void deleteLines(int startLnum, int end) { List<String> undoLines = new ArrayList<>(); for (int i = startLnum; i < end; i++) { if (buffer.isEmpty()) { System.out.println("?Deleted all lines!"); break; } undoLines.add(buffer.remove(i - 1)); } current = startLnum; if (!undoLines.isEmpty()) { pushUndo("delete lines " + startLnum + " to " + end, () -> addLines(startLnum, undoLines)); } } 一部の操作はBufferPrimsNoUndoととてもよく似ているため、実際には、super()を使ってAbstractBufferPrimsクラスの処理を再利用しています。 @Override public void addLine(String newLine) { super.addLine(newLine); pushUndo("add 1 line", () -> deleteLines(current, current)); } pushUndo()メソッドでは、説明文字列(GUIのあるエディタで使うためのもの)と、現在のコマンドを「元に戻す」操作を行うラムダ式をまとめるラッパー・オブジェクトを作成しています。deleteLines()の「元に戻す」操作では、削除された行すべてを追加できることが必要です。そのため、すべての行をListに格納し、削除の逆の操作であるaddLines()に渡しています。「元に戻す」のメカニズムと、そのメカニズムを実装するCommandデザイン・パターンの詳しい説明は、先ほど触れた記事をご覧ください。   UIとコマンド構造 すべてをゼロから再発明(通常、これはよくない考え方です)しなくてもよいように、このライン・エディタのUIには、UNIXのedコマンドのUIを堂々と拝借することにします。このUIは、何十年もの間にわたって標準であり続けており、exおよびviの両者のベースとなり、さらにはストリーム・エディタsedの大部分のベースとなりました。 次に示すのは、すべてのコマンドの基本フォーマットです。 [n,m]C[operands] この意味は次のとおりです。 角括弧は、その中のテキストが省略可能であることを示します。 nとmは行番号です(1から始まり、デフォルトは現在の行です。現在の行とは、最後に操作を行った行のことです)。 Cは1文字コマンドです(たとえば、dは削除、aは追加、sは置換)。適時最新のコマンド・リストは、ソース・プロジェクトのREADMEファイルに記載されています。 operands(オペランド)は、使用するコマンドによって異なります。 なお、小文字1文字でコマンドを表すという、このインタフェースの設計は、最初にこの設計が生み出されたころの、ユーザーとコンピュータとの間の非常に低速なキーボード・インタフェースの影響を受けたものであることには注目する価値があります。しかしこれは、設計を無制限に拡大させないことを意図した選択でもありました。つまり、可能なコマンドは26個ほどしか想定しなかったということです。よいことか悪いことか、後の開発者はいくつかの大文字コマンドを追加しました。今回のエディタで大文字コマンドは実装しませんが、最近のUNIXやLinuxのedではおそらく実装されているでしょう。 すべてのJavaアプリケーションには、起動のためのpublic static void main(String[] args)メソッドが必要です。通常、このメソッドではコマンドライン・オプション(存在する場合)を処理し、ファイルのチェックやオープンを行い、処理用のメソッドに制御を委譲します。一般的に、処理用のメソッドは静的でないインスタンス・メソッドです。今回の例でのメイン・プログラムは、LineEditor.javaに含まれています。 ここでのmainメソッド内にはループがあります。そこでは、コンソールから1行を読み取り、解析してエディタのコマンドである可能性が高いかを確認し、コマンドであれば、その文字を文字コマンド固有のルーチンに渡しています。メイン・コードのループは次のようになっています。 // エディタのメイン・ループ: while ((line = in.readLine()) != null) { ParsedCommand pl = LineParser.parse(line, buffPrims); if (pl == null) { System.out.println("?"); continue; } EditCommand c = commands[pl.cmdLetter]; if (c == null) { System.out.println( "?Unknown command in " + line); } else { c.execute(pl); } } 1文字コマンドを処理するコードは、Commands.javaで設定しています。具体的には、EditCommandオブジェクトの配列を使い、1文字と、コマンドを実装したラムダ式とのマッピングを行っています。任意のASCII文字を使えるよう、この配列の長さは255にしていますが、実際に実装されているのは20ほどしかありません。コマンド処理の簡単な例として、次にpコマンド(印刷を表す"print"の略です)の実装を示します。 // p - 行の印刷 commands['p'] = pl -> { buffPrims.getLines(pl.startNum, pl.endNum) .forEach(System.out::println); }; このコードの変数plは、ParsedCommand(以前はParsedLineでした)を表します。ParsedCommandは、コマンド、行番号の範囲、そしてオペランドを表すクラスです。ユーザーがコマンドを入力するたびに、LineParserクラスのparse()メソッドによって、そのコマンドを表すParsedCommandが作成されます。 コマンド・ハンドラの中には、先ほどのpのように、短くて扱いやすいものもあります。しかし、中にはかなり長いものもあります。興味がある方は、sコマンド(置換を表す"substitute"の略です)の実装をご覧ください。このコマンドでは、ある範囲の行に対して反復処理を行わなければならないだけでなく、デリミタに任意の文字を使用できなければなりません。さらに、デリミタが2回または3回存在することを確認し、最後のデリミタの後にgとpが任意の順番で存在しているかどうかも確認する必要があります。gは"global"(グローバル)または"go across the line"(行をまたぐ)を表します。このコマンドがない場合、edjでは最初に見つかった古いテキストのみが置き換えられます。最後にpを指定した場合、対象の行が印刷されます。以下に、有効なコマンドの例をいくつか示します。 s/him/them/ # 現在の行を対象に、最初の"him"を"them"に変更 s=him=them= # 上記と同じだが、違うデリミタを使用 2,3/him/them/ # 2行目から3行目を対象に、最初の"him"を"them"に変更 5,s/him/them/ # 5行目から末尾までを対象に、最初の"him"を"them"に変更 ,s/him/them/ # すべての行を対象に、最初の"him"を"them"に変更 s/him/them/g # すべての行を対象に、すべての"him"を"them"に変更 s/him/them/p # 現在の行を対象に、最初の"him"を"them"に変更し、 # 行を印刷 s/him/them/gp # 上記の2つの例を組み合わせたもの この構文を学ぶためには時間が必要です。また、すべての種類を正確に解釈するためには、数行のコードが必要になります(parseSubstitute()をご覧ください)。ただし、このコマンドの簡潔さと強力さを見れば、ed(およびそこから派生したviなどのエディタ)が今もオープンソースの世界でシステム管理者や開発者に愛用されている理由がわかります。   パラメータ化テスト 「早い段階から頻繁にテストする」というのは、信頼性の高いコードを書くための格言です。多数の単体テストを作成し、少しでも変更が発生したときに実行するということです。バッファ・プリミティブのテストは簡単で、ほとんどのコードに対してテストが存在します。3種類の実装に対してテストをコピー・アンド・ペーストすることを避けるため、ここではパラメータ化テストという、JUnit 4の機能を使います。@Parametersアノテーションを付加したメソッドからは、コンストラクタの引数(任意の型)リストが返されるようにします。このリストは、テスト・クラスの個々のインスタンスを作成するために使われます。テスト・クラスのフィールドは、コンストラクタによって設定されます。引数は任意の型でよいため、クラス・ディスクリプタ(たとえば、Reflection APIクラス)を使用しています。次に、BufferPrimsTestの関連部分を示します。 @RunWith(Parameterized.class) public class BufferPrimsTest { protected BufferPrims target; public BufferPrimsTest(Class<BufferPrims> clazz) throws Exception { target = clazz.newInstance(); } @Parameters(name = "{0}") public static Class<BufferPrims>[] params() { return (Class<BufferPrims>[]) new Class<?>[] { BufferPrimsStringBuffer.class, BufferPrimsNoUndo.class, BufferPrimsWithUndo.class }; } // @Testアノテーションを付加したメソッド... } コマンドおよび置換オペランドを解析するコードのテストも存在します。   さらなる作業 この状態のedjは、たとえ完全版が手元にあっても、使いたいと思うようなものではないでしょう。あるいは、viやそのさまざまな派生物のようなスクリーンベースのエディタであっても同じでしょう。edのコマンドの一部は実装されておらず、実装されているものもほとんどが不完全です。たとえば、行の範囲を解析する部分には、「検索」の機能がありません。実際のUNIXやLinuxにおけるedの実装では、開始行または終了行の行番号のいずれか(または両方)の代わりに、検索文字列を指定できます。検索文字列を、/pattern/と指定した場合は現在の行から前方(下方向)に検索でき、?pattern?と指定した場合は上方向に検索できます。コードは全体的に、このような機能を追加する必要がある場合、誰でも拡張して完全な実装にできるような設計になっています。   コードの再利用 設計全体を検証するために、UNIXのストリーム・エディタsedのとても簡単な概念実証実装を作成しました。UNIXのsedコマンドは、名前のついたファイル(ファイルが指定されていない場合は標準入力)を1行ずつ読み取り、コマンドラインで指定されていたすべての編集コマンドを各行に適用します。次に例を示します。 sed -e 's/old/new/g' -e 's=more=less=' file1 想像どおりかもしれませんが、file1内のすべての"old"を"new"に置換し、各行の最初の"more"を"less"に置換するものです。これは、バッチ・エディタというよりはストリーム・エディタです。file1は変更せず、変更結果を標準出力に書き込みます。 バッチ・エディタの作成、すなわち、コマンドにエラーがあったときやディスクがいっぱいになったときにファイルを安全に保つことは、今回の概念実証の範囲外です。 このStreamEditorでは、LineEditorとは異なり、1つのコマンドしか実装していません。ただし、実装しているのはもっとも複雑なs(置換)コマンドです。StreamEditorでは、行を解析するコードと置換コマンドの解析コードを再利用しています。このStreamEditorのプロトタイプでは、実装されている1つのコマンドは問題なく動作します。この概念実証のデモとして、stests(stream tests)という名前のシェル・スクリプトを作成しています。次回の記事では、バッファ処理コードを再利用する予定です。   コードの入手 このバージョンのエディタを、edj(editor in Java、「エッジ」のように発音します)と呼んでいます。繰り返しになりますが、全体を1か所で見てみたい方は、GitHubからコードをダウンロードできます。   まとめ 本記事では、かなり単純なテキスト・エディタをJavaだけで実装するために必要な構造の設計を行う際の問題や、その場合のコードの一部について見てきました。ここで、重要な点をいくつか挙げておきます。 行指向のパラダイムで正規表現の力を活用するUIの設計 UIと、土台になるバッファ管理コードとの間のインタフェースの設計 効率的である一方でわかりやすいバッファ管理の実装 UIの設計は、UNIXのedのUIをベースにしています。また、BufferPrimsのインタフェースは、筆者がかなり前に作成したこのエディタのC言語による再実装にかすかに似たものとなっています。その再実装自体は、『Software Tools』という書籍向けにRatForという教育用言語で書いた、さらにその前のバージョンがベースになっています。今回紹介したバージョンのインタフェースは、最初から完全な形で考えついたわけではなく、エディタの進化とともに何度か改訂を重ねた結果です。次回の記事では、このインタフェースを再利用して、実際に使用できるGUIテキスト・エディタを作成する方法を紹介したいと思います。   Java Magazine December 2019の他の記事 プロパティベース・テストを習得する Arquillian:簡単なJakarta EEテスト ArchUnitでアーキテクチャの単体テストを行う 新しいJava Magazine クイズに挑戦:Collectorsの使用(上級者向け) クイズに挑戦:ループ構造の比較(中級者向け) クイズに挑戦:スレッドとExecutor(上級者向け) クイズに挑戦:ラッパー・クラス(中級者向け) 書評:Core Java, 11th Ed. Volumes 1 and 2 Ian Darwin Ian Darwin(@Ian_Darwin):Java Champion。メインフレーム・アプリケーションから、UNIXおよびWindows向けのデスクトップ・パブリッシング・アプリケーション、Javaによるデスクトップ・データベース・アプリケーションやAndroid向けのヘルスケア・アプリまで、あらゆる開発を手がける。『Java Cookbook』、『Android Cookbook』(いずれもO'Reilly)の著者。また、Learning Tree Internationalでいくつかのコースを作成し、多くのコースで教えている。

新連載:階層化設計と反復型開発を使ってライン・エディタをテキスト・エディタに進化させる 著者:Ian Darwin 2019年8月20日 本記事のタイトルを読んだ方は、「なぜJavaでテキスト・エディタを作りたいのだろうか。JavaはエンタープライズWebアプリのためのものではないのか」と思うかもしれません。私の最初の答えは、「とんでもない」です。Javaは現在もデスクトップで使われており、活躍しています...

Arquillian:簡単なJakarta EEテスト

Arquillianフレームワークを使ってJakarta EEアプリケーションをテストする方法 著者:Josh Juneau 2019年8月20日 Webアプリケーションやエンタープライズ・アプリケーションのテストは、Java SEプロジェクトのテストよりもはるかに面倒になる場合があります。スコープが異なり、ほとんどの場合にテストするフェーズも異なる、さまざまな種類のファイルが存在するからです。Arquillianは、長い年月をかけて進化してきた強力で堅牢な、Java EEおよびJakarta EE向けのテスト・フレームワークです。JBossプロジェクト(現在はRed Hatの一部)によって開発されたもので、テストやその出力を拡張できる複数のアドオン拡張機能もあります。 Arquillianフレームワークはとても強力ですが、その背景にはある程度の複雑さがあります。テスト・クラスの設定は、行う必要があるテストのレベルに応じて、とても簡単な場合もあれば、かなり複雑な場合もあります。 本記事では、Arquillianフレームワークの構成と、このフレームワークを使用したテストについて紹介します。基本的なJakarta EE 8(Java EE 8と同等)アプリケーションの構成とビルドに加え、JUnit 4とArquillianを使ういくつかのテストについても触れます。いくつかの基本的な例を示した後は、特に重要な機能や拡張機能について説明します。いずれも、Java EEおよびJakarta EEのプロジェクトの検証機能を拡張できるものです。本記事の内容を理解するためには、Java EEまたはJakarta EEプロジェクトの基本的知識が必要です。 サンプル・アプリケーションはMavenを使ってビルドしています。Mavenプロジェクトに対応した任意のIDEを使えるはずですが、本記事の例ではApache NetBeans IDEを使っています。GitHubから、ArquillianExampleという名前の、Maven Webアプリケーション・プロジェクトのサンプルを取得しておくことをお勧めします。   環境を設定する Arquillianフレームワークを使う際に特に難しいことの1つが環境設定です。基本的なテストに必要となるのはわずかなMaven依存性だけですが、正しいバージョンの依存性を使わなければなりません。バージョンが正しくなかった場合、エラーにつながる不整合が起きる可能性があります。ゼロから始める場合は、コマンドラインまたはIDE(Apache NetBeansなど)からMavenアーキタイプを使ってMaven Webアプリケーション・プロジェクトを作成します。Apache NetBeansを使っている場合は、プラットフォームとしてJava EE 8を選んでください。 プロジェクトを作成したら、プロジェクトを右クリックしてPOMファイルを開き、リスト1に示す依存性を追加します。この依存性には、Arquillianの要件が含まれています(注:本記事のサンプル・ソース・コードを使用する場合、Jakarta EEプラットフォームとApache Derbyデータベースに関連する追加の依存性もあります)。 この依存性を眺めてみます。arquillian-bomアーティファクトがArquillianフレームワークの「部品表」になっており、すべての推移的依存性で使われます。POMファイルの標準の<dependencies>セクションには、JUnitフレームワークを追加しています。本記事の執筆時点では、まだJUnit 5はサポートされていないため、ここではJUnit 4を使っています。ただし、ArquillianでJUnit 5を使えるようにする作業も行われています。このAPIでJUnitを動作させるためには、Arquillian JUnitコンテナが必要です。お気に入りのテスト・フレームワークはTestNGだという方のために、このフレームワークを使えるコンテナも存在します。JBoss ShrinkWrap Resolverを使用して、ShrinkWrapをサポートしています。ShrinkWrapにより、コードから宣言的にデプロイメント・アーカイブを作成できます。その他の依存性は、arquillian-weld-ee-embeddedという名前の埋込みCDIコンテナにテスト・アーカイブをデプロイするために必要となります。実現しようとしている、テストのレベルに応じて、いくつかのデプロイメント・オプションが存在します。Weld埋込みコンテナは、データベース接続や、アプリケーション・サーバー・コンテナのその他の機能を使用せずにCDIをテストする場合に便利です。埋込みコンテナを活用することで、起動とテストがスムーズになります。データベース接続テストを実行する必要がある場合や、その他のアプリケーション・サーバー機能を使う必要がある場合は、リモート・コンテナにデプロイすることも可能です。後ほど、GlassFishサーバーに接続する方法も説明します。   小さなアプリケーションを書く この例で使うアプリケーションは、いくつかの小さなデータベース表を操作して、水泳プール会社とその顧客に関するレコードの作成、読取り、更新、削除(CRUD)を行うことができるというものです。Apache NetBeansやその他ほとんどのIDEでは、ウィザードを使用して、非常に短時間でアプリケーションを生成することができます。そのため、アプリケーションの初期生成は省略し、アプリケーション・ロジックのテスト部分を中心に説明します。 Poolはデータベースに格納でき、Customerオブジェクトに関連付けられています。本記事では、Java Persistence API(JPA)とEJB Beanを使って、Poolデータベース操作の単体テストを作成します。また、CDI Beanのテストについても説明します。このBeanでは、データベースを操作するEJB Beanにフロントエンドをバインドするビジネス・ロジックを実行します。なお、EJB BeanをRESTfulサービス呼出しに置き換えることもできる点に注意してください。その場合も、テストは同じように行われます。   基本的なCDI単体テストを書いて実行する それでは、とても簡単なCDIテストから始めます。この基本的なテスト用のCDI Beanでは、単純にCDI注入を使用して、Poolオブジェクトが適切に作成されていることを確認するテストを行います。テストを書く前に、テスト・クラスを適切に設定する必要があります。 一般的に、アプリケーションのビジネス・ロジックを含む各クラスに対応するテスト・クラスが存在する必要があります。この例でのテスト・クラスは、PoolControllerTestという名前です。このテスト・クラスからArquillianを利用する場合、クラス宣言の前に@RunWith(Arquillian.class)アノテーションを付加する必要があります。このアノテーションを使うと、Arquillianエンジンを使ってテストを実行するようテスト・フレームワークに伝えることができます。 各クラスには、指定したすべてのクラスやライブラリ、構成ファイルをテスト・パッケージ(WAR、EAR、JAR)に格納するデプロイメント・メソッドも必要です。このテスト・パッケージは、ビルド後、Arquillianエンジンによって選択済みテスト・コンテナに自動的にデプロイされ、実行されます。その際の出力は、コマンドラインまたはIDEに表示されます。 デプロイメント・パッケージを作るためには、@Deploymentアノテーションを付加したパブリックな静的メソッドからShrinkWrapアーカイブを返します(リスト2にこれを示します)。このデプロイメント・メソッドの中では、Builderパターンを使ってデプロイ可能アーカイブを構築します。その際に、作りたいアーカイブの種類を指定してShrinkWrapのcreate()メソッドを呼び出します。今回の例では、WebArchive.classを作成しています。別の種類のアーカイブには、標準JARを作るJavaArchive、EARファイルを作るEnterpriseArchiveなどがあります。テストで使う各クラスは、CLASSPATHに追加する必要があります。この追加は、addClass()、addClasses()、addPackage()、addPackages()の各メソッドを状況に応じて使用し、行います。また、addAsManifest()メソッドも呼び出し、beans.xmlファイルを追加してCDIを起動できるようにしている点に注意してください。デプロイ用のcreate()ビルダーの一部であるさまざまなメソッドの詳細については、ShrinkWrapのチュートリアルをご覧ください。 リスト3には、PoolControllerのソース・コードが含まれています。コンストラクタでは、2つのPoolオブジェクトを作成してArrayListに追加しています。このArrayListに対して、空でないことを確認するテストを行っています。CDIコントローラは、標準の@Injectアノテーションを使ってテスト・クラスに注入できます。この注入処理は、テスト・メソッドの直前に行う必要があります。このテストではJUnitを使うことから、テスト・メソッドに@Testアノテーションを付加します。また、テスト・メソッドでは、org.junit.Assertで定義されているアサーション・メソッドのいずれかを使って、テストが成功したかどうかを判定します。テスト・クラスの完全なソース・コードは、リスト4をご覧ください。他のJUnitテストと同じように、ブール値を返す式のテストに使用できるAssertionメソッドも複数存在します。選択できるAssertionメソッドのリストについては、JUnitのドキュメントをご覧ください。 IDEまたはコマンドラインからMavenビルドを実行するだけで、テストを実行できます。プロジェクトをビルドするたびにテストが実行されます。テストのみを実行するためには、コマンドラインからmvn testコマンドを使います。Mavenを使ってプロジェクトをビルドする場合や、コマンドラインからテストを実行する場合は、埋込みWeldコンテナ(このプロジェクト用に選択したデプロイメント・コンテナ)でテストが実行されます。テストを実行すると、次のような内容が出力されます。 Tests run:1, Failures:0, Errors:0, Skipped:0 org.javamagazine.arquillianexample.cdi.PoolControllerTest Results : Tests run:1, Failures:0, Errors:0, Skipped:0   JPAとGlassFishを構成する 実際のデータベースに対してテストを行うためには、いくつかのことを決める必要があります。PersistenceContextは、テスト・クラスに直接注入できます。ただし、トランザクションを管理するためにUserTransactionも注入する必要があります。この場合、テスト・クラス自体がCDIコントローラとして扱われます。このタイプのテストは、次のようになります。 @Test public void insertData(){ utx.begin(); em.joinTransaction(); Pool pool = new Pool(); // 値の設定 em.persist(pool); utx.commit(); em.clear(); } 本記事では、PersistenceContextは使わずに、リモートGlassFishサーバーにデプロイしてテストを行います。同じ依存性で動作するため、GlassFishの代わりにPayaraを使うこともできます。また、他のいくつかのサーバーを使うこともできます。リモート・サーバーに対してテストを行うことで、多くのメリットが生じます。たとえば、テスト環境ではなく実環境でテストができることや、言うまでもありませんが、本番環境でのユースケースに一致するように、データベース接続プールやサーバー環境設定を構成できることです。 リモート・サーバーに対してテストを行う場合、テストを実行する前にサーバーが稼働していなければなりません。そうでない場合、テストは失敗します。サーバーはArquillianエンジンの外にあるため、テストを実行するマシンと同じマシンにインストールされていても、「リモート」サーバーとして構成する必要があります。別の方法として、実際にリモートのサーバーを構成してテストを実行することもできます。 リモート・サーバー環境を設定するためには、src/test/java/resources領域に追加の設定が必要です。また、リスト5に示すような、arquillian-glassfish-remote-3.1への依存性をPOMファイルに追加する必要があります。GlassFishサーバーにログインするための資格証明を、リスト6に示すようにarquillian.xmlファイルに記述する必要があります。 コンテナ設定の属性の1つに、adminHostがある点に注意してください。この属性は、必要に応じて実際のリモート・サーバーに向けることができます。テスト・データベースを使用してテストを行えるように、test-persistence.xmlファイルをこのリソース領域に設定しておくとよいでしょう。test-persistence.xmlという名前の永続コンテキストを作成し、プロジェクトのsrc/test/java/resourcesフォルダに配置します。このファイルには、リモート・アプリケーション・サーバー・コンテナ内で構成されるデータソース用のJava Transaction API(JTA)接続構成を含める必要があります。 これでリモートGlassFishサーバー用の構成が整いました。次は、EJB Bean CustomerFacadeのテストを作成します。EJBテストは、src/test/javaフォルダに配置し、org.javamagazine.arquillianexample.session.CustomerFacadeTestという名前にする必要があります。CustomerFacadeTestのソース・コードをリスト7に示します。このテスト・クラスの宣言の前には、標準の@RunWith(Arquillian.class)アノテーションを含める必要があります。また、このクラスには、ShrinkWrapアーカイブを返すために、@Deploymentアノテーションを付加した静的メソッドが含まれている必要があります。 デプロイメント・メソッドは、createDeployment()という名前とし、そこには、EJBテストを実行するためにCLASSPATHに追加する必要がある各クラスへの参照を含めています。このデプロイメントでは、テスト・デプロイメント・アーティファクト内のCDIを構成するために、ビルダー・パターンを使って addAsManifestResource(EmptyAsset.INSTANCE,"beans.xml") を呼び出しています。このデプロイメントには、永続性コンテキストを構成するために、 addAsResource("test-persistence.xml", "META-INF/persistence.xml") の呼出しも含めています。 この場合、test-persistence.xmlファイルが、テスト・デプロイメントの標準のpersistence.xmlファイルとして読み込まれます。CustomerFacadeTest内のテスト・メソッドは非常にシンプルです。findAllCustomers()メソッドがCustomersエンティティの問合せを行ってその結果を返したかどうかを判定するために、Assert.assertTrueを呼び出しています。 実際のアプリケーションでは、EJB Beanを直接呼び出すのではなく、フロントエンドからCDIコントローラCustomerControllerを呼び出します。そこで、CustomerController CDI Beanが適切にアプリケーション・ロジックを呼び出して画面に結果を返すことを確認するテストを行う必要があります。リスト8に示すように、CDIコントローラのテストは、org.javamagazine.arquillianexample.cdi.CustomerControllerTestを使用して行います。EJBのテストとよく似ていますが、このテストではCustomerController getCustomerList()メソッドを呼び出し、メソッドに移入が行われていることを確認しています。インスタンスが生成される際に、CustomerControllerクラスによってcustomerListが移入されるため、このテストからはtrueという結果が返されるはずです。   テスト実行のオプション テストは、コマンドラインまたはIDEから実行できます。テストするファイルごとに別々にテストを実行することも、プロジェクトのすべてのテストをビルド・プロセスに利用することもできます。コマンドラインから1つのファイルのテストを実行するためには、コマンドラインを開いてプロジェクトのディレクトリに移動し、次のコマンドを発行します。 mvn test テストの結果は即座に表示されます。X個のテストが設定されている場合、X回成功する必要があります。Mavenビルドの一部としてテストを実行している場合、いずれかのテストが失敗したときは、ビルドも失敗するため、アプリケーションのパッケージ化は行われません。 視覚的なフィードバックを受け取りたい場合は、IDEでテストを行うとよいでしょう。NetBeans IDEでは、テスト・ファイルを右クリックするか、図1のようにプロジェクト自体を右クリックして「Test File」を選択することで、テストを実行できます。 図1:NetBeans IDE内で1つのテストを実行する NetBeans内でテストを実行した場合、テストの結果がTest Resultsパネルに表示されます。複数のテストがある場合、図2のように、失敗した各テストがパネルに表示されるため、そこから結果を解析して修正を行うことができます。パネルの左側には、簡単にテスト結果を移動するボタンや、テストを再実行するボタンもあります。 図2:Apache NetBeansのTest Resultsパネル   複数のコンテナによるテスト 別のコンテナでテストを行えるようにプロジェクトを構成するためには、POMファイルでMavenプロファイルを宣言することを検討します。Mavenプロファイルを使うことで、各コンテナに対する依存性をそれぞれ分離し、プロジェクトのビルド時に希望のプロファイルを選択することができます。また、リスト9に示すように、POMファイルでactiveByDefault要素をtrueに設定し、デフォルトのプロファイルを指定することも可能です。 各プロファイルには、コンテナに対する依存性が含まれています。activeByDefault要素を変更して、アクティブなコンテナを切り替えることができます。なお、IDEの中には、ユーザー・インタフェースで複数のMavenプロファイルから選択できるものもあることに注意してください。   高度な内容 Arquillianフレームワークには、テスト・クラスで使用して、テストの調整や実行の制御をさらに行うことができるテスト補助機能が多数含まれています。たとえば、先ほどの例でお見せしたように、注入ポイントは、@Injectアノテーションを使ってフィールドに作成することも、テスト・メソッドで引数として宣言して直接作成することもできます。 こちらも例で示しましたが、テスト・クラスにセッションBeanを注入するために、@EJB補助機能を使用します。その他の補助機能には、@PersistenceContext、@PersistenceUnit、@Resourceなどがあります。最初の2つは、永続コンテキストと永続ユニットを示します。@Resourceアノテーションは、Java Naming and Directory Interface(JNDI)で利用できるオブジェクトの注入に使用します。他の利用可能なJNDIリソースに対するリモート・コンテナ・テストを行う場合、このオプションが非常に役立ちます。 テストは、コンテナ・モードとクライアント・モードという2つのモードで実行できます。デフォルトはコンテナ・モードです。このモードでは、Arquillianのサポート・クラスを追加して@Deploymentを再パッケージ化することが可能なため、コンテナ内でリモート・テストを行うことができます。 クライアント・モードを選択した場合、@Deploymentの再パッケージ化やリモート・サーバーへのデプロイは行われません。JVM内でテスト・ケースが実行されるため、クライアントが外側からコンテナをテストすることができます。クライアント・モードで実行するためには、静的デプロイメント・メソッドに次のアノテーションを付加します。 @Deployment(testable=false) コンテナのテストとクライアントのテストの両方を実行するためには、デプロイメントでtestable=trueを宣言し、クライアント・モードで実行するテスト・メソッドに@RunAsClientアノテーションを付加します。クライアントとして実行する理由の1つに、Warp拡張機能を使ってフロントエンドのテストを行えるようにする点が挙げられます。Warp拡張機能を使うことで、クライアントサイドのテストを書いて、サーバーサイドのロジックを検証することができます。これにより、クライアントとサーバーの両方を使って行う結合テストが可能になります。   拡張機能 複数のArquillian拡張機能をArquillianと組み合わせることにより、さまざまなタイプのテストを実現できます。前述のとおり、Warp拡張機能を使用して、サーバーサイドのロジックを検証する、クライアントサイドのテストを書くことができます。よく使われる別の拡張機能に、Grapheneがあります。Grapheneは、JavaServer Faces(JSF)やSpring MVCで構築したフロントエンドをテストする場合に特に便利でしょう。Grapheneでは、Selenium WebDriverを使ってプログラム的な方法でブラウザを操作することができます。そのため、Javaコードを使用してフォームに入力することや、ビジネス・ロジックによってWebページを移動すること、そしてアサーションで動作のテストを行うことができます。その過程でコンテンツを検証し、UI内で適切な機能が実現されていることを確認することができます。Selenium WebDriverを使用する別の拡張機能であるDroneでは、ブラウザのライフサイクルを管理し、ブラウザをテスト・クラスに注入することができます。Graphene拡張機能はDroneとSeleniumに依存しているため、プロジェクトにいくつかの依存性を追加して、これらの拡張機能を利用できるようにする必要があります。Grapheneテストの@Deploymentは、「クライアント」モードで実行する必要があります。つまり、testable=false属性を含める必要があります。ユーザー・インタフェースのテスト用のデプロイメント・パッケージには、テストされるそれぞれのビューを含める必要があります。そのため、アプリケーションにcustomer.xhtmlという名前のビューが含まれている場合、次のようにして、@Deploymentメソッドでこのリソースを追加する必要があります。 .addAsWebResource("/customer.xhtml"); Grapheneにより、マークアップではなくJavaを使って、別々のページおよびそれらのページに含まれる個々の機能をテストすることが可能になる「ページ・オブジェクト」および「ページ断片」を作成できます。本記事ではこういった考え方について詳しくは説明しませんが、テストのニーズを満たせるように、このような機能を確認しておくことを強くお勧めします。   まとめ Arquillianフレームワークにより、エンタープライズ・アプリケーションでおもに利用されるコンポーネントのテストが実現します。そのため、Java EE/Jakarta EE開発者にとって欠かせないツールです。このフレームワークでは、的を絞った細かいテストをサポートしているため、選択したクラスや機能のみをテスト・デプロイメントに含めることができます。また、JSF、REST、サーブレット、Spring MVCなど、エンタープライズ開発で使用されるテクノロジーのテストを実現する多くの拡張機能が作成されている、成熟したテスト・フレームワークでもあります。   Java Magazine December 2019の他の記事 プロパティベース・テストを習得する ArchUnitでアーキテクチャの単体テストを行う 新しいJava Magazine 作ってみよう:自分だけのテキスト・エディタ(パート1) クイズに挑戦:Collectorsの使用(上級者向け) クイズに挑戦:ループ構造の比較(中級者向け) クイズに挑戦:スレッドとExecutor(上級者向け) クイズに挑戦:ラッパー・クラス(中級者向け) 書評:Core Java, 11th Ed. Volumes 1 and 2 Josh Juneau Josh Juneau(@javajuneau):アプリケーション開発者、システム・アナリスト、データベース管理者。おもに、Javaやその他のJVM言語を使った開発に従事。Oracle Technology NetworkやJava Magazineで多くの記事を執筆し、JavaやJava EEに関する複数の書籍をApressから出版している。JSR 372およびJSR 378のJCP専門家グループのメンバーを経験。NetBeans Dream Teamメンバー、Java Champion、CJUG OSS Initiativeのリーダーであり、JavaPubHouse Off Heapポッドキャストにレギュラー出演中。

Arquillianフレームワークを使ってJakarta EEアプリケーションをテストする方法 著者:Josh Juneau 2019年8月20日 Webアプリケーションやエンタープライズ・アプリケーションのテストは、Java SEプロジェクトのテストよりもはるかに面倒になる場合があります。スコープが異なり、ほとんどの場合にテストするフェーズも異なる、さまざまな種類のファイルが存在するからです。Arqui...

プロパティベース・テストを習得する

無数の値を使ってコードをテストする方法 著者:Johannes Link 2019年8月20日 JUnitなどのツールを使って単体テストを記述することは、コードの品質を確保するうえで欠かせない技術です。しかし、発生する可能性がある問題すべてを確認するために多くのテスト・ケースが必要となる関数の場合、テストは面倒でエラーが起こりやすくなります。その救世主となり得るのがプロパティベース・テスト(PBT)です。PBTにより、テスト・ケースを多数書く作業から解放されます。本記事では、PBTとは何か、JUnit 5プラットフォームでPBTを使用する方法、そしてどうすればサンプルベース・テストの拡張、場合によっては置き換えが可能かについて説明します。   サンプルベース・テスト 個々の測定値を受信(receive)し、それぞれの出現頻度を数えて集計するAggregatorクラスを扱っているとします。オブジェクトが意図どおりに動作するかどうかを確認するために、次の簡単なJUnit 5テストを使用できます。 import java.util.*; import org.junit.jupiter.api.*; class AggregatorTests { @Test void tallyOfSeveralValues() { Aggregator aggregator = new Aggregator(); aggregator.receive(1); aggregator.receive(2); aggregator.receive(3); aggregator.receive(2); Map<Integer, Integer> tally = aggregator.tally(); Assertions.assertEquals(1, (int) tally.get(1)); Assertions.assertEquals(2, (int) tally.get(2)); Assertions.assertEquals(3, (int) tally.get(1)); } } 多くの場合、この種のテストはサンプルベースと呼ばれます。具体的な入力例を使い、特定の状況において、生成された出力が意図した結果と一致しているかどうかを確認するからです。ほとんどの開発者は、何年あるいは何十年も似たようなテストを書いています。通常、一般的なプログラミング・エラーはそのようなテストでうまく検出できます。しかし、筆者の心の奥には、いつも1つの悩みの種がありました。Aggregatorが5つの測定値でも動作することは、どうすれば確認できるでしょうか。5,000個の要素がある場合や要素が何もない場合、負の値などもテストすべきなのでしょうか。虫の居どころが悪い日なら、自分のコードや同僚の開発者のコードに対する疑念が限りなく生じてきます。   プロパティ しかし、正確さに関するこの疑問には、別の角度から迫ることができます。どんな事前条件や制約(たとえば、入力パラメータの範囲)であれば、テスト対象の機能に対して特定の事後条件(計算結果)が得られるでしょうか。また、その過程で違反してはいけない不変量はどれでしょうか。 事前条件と、期待される特性の組合せを、プロパティと呼びます。 それでは、Aggregatorのいくつかのプロパティを簡単な日本語で表現してみます。 すべての測定値は、集計(tally)にキーとして出現する 測定されなかった値は、集計に出現しない 集計に出現した回数の合計は、受信した測定値の数と等しくなる 測定の順序によって集計結果が変わることはない 最初の文から3番目の文までは、いずれもかなり一般的な宣言です。最後の文が成立するためには、少なくとも2つの測定値が必要です。それぞれのプロパティは、要素リストが空でも、かなり長くても、その長さにかかわらず、任意の要素リストに適用できます。測定値は、Integer型の範囲全体に広がる可能性があり、重複することもあります。   プロパティ・テストの自動化 それでは、どうすれば自動テストにプロパティを使えるのでしょうか。宣言そのものは、コードに変換できそうです。最初のプロパティをJavaメソッドで表すのは簡単で、次のようになります。 boolean allMeasuredValuesShowUpAsKeys(List<Integer> measurements) { Aggregator aggregator = new Aggregator(); measurements.forEach(aggregator::receive); return measurements.stream() .allMatch(m -> aggregator.tally().containsKey(m)); } 実際に自動テストを行うために足りないのは、一連の入力リストを生成する方法と、メソッドにそのリストを提供する方法、そして条件がfalseを返したらすぐにテストを失敗させる方法です。これをすべて標準のJUnitにより行うこともできますが、専用の生成ロジックが多数必要になります。また、単純なケースは実現できますが、生成する値が複雑になり、ドメイン固有性が高まった場合、すぐに厄介になります。そこで、別のテスト・エンジンであるjqwikを使います。 jqwikを使う場合、先ほどのコードを実行可能なプロパティにするために必要となるのは、次の微調整だけです。 import java.util.*; import net.jqwik.api.*; class AggregatorProperties { @Property boolean allMeasuredValuesShowUpAsKeys( @ForAll List<Integer> measurements) { Aggregator aggregator = new Aggregator(); measurements.forEach(aggregator::receive); return measurements.stream() .allMatch(m -> aggregator.tally().containsKey(m)); } } このコードを詳しく見てみます。 プロパティは、コンテナ・クラスの中のメソッドです。メソッドには、わかりやすい名前をつけるべきです。すべての測定値がキーとして出現することを示すallMeasuredValuesShowUpAsKeysという名前では、プロパティの意図が適切に要約されています。 メソッドをプロパティ・メソッドとしてマークするためには、IDEやビルド・ツールでプロパティ・メソッドとして認識されるように、@Propertyアノテーションを付加する必要があります(IDEやビルド・ツールがJUnitプラットフォームをサポートしている場合)。 パラメータに@ForAllアノテーションを付加することで、フレームワークにインスタンスを生成させたいことをjqwikに伝えることができます。パラメータの型であるList<Integer>は、基本的な事前条件と見なされます。 プロパティの必要条件を伝えるもっとも簡単な形は、ブール値を返すことです。別の方法として、AssertJやJUnit 5自体などの任意のアサーション・ライブラリを使うことができます。 jqwikプロパティの実行が成功した場合、JUnitのテストが成功したときのように、何も起きません。他に指示を与えていない場合、jqwikでは異なる入力パラメータを使って各プロパティ・メソッドが1,000回ずつ実行されます。必要に応じて、この数はいくらでも多くすることも少なくすることもできます。   失敗するプロパティ 失敗するプロパティについて確認するために、リストの3番目にあるプロパティ(集計に含まれる、出現回数の合計は、受信した測定値の数と等しくなる)を取り上げます。 @Property boolean sumOfAllCountsIsNumberOfMeasurements( @ForAll List<Integer> measurements) { Aggregator aggregator = new Aggregator(); measurements.forEach(aggregator::receive); int sumOfAllCounts = aggregator.tally().values() .stream().mapToInt(i -> i).sum(); return sumOfAllCounts == measurements.size(); } 現在の集計関数にはバグが含まれているため、どの値も一度しかカウントされません。この場合、jqwikはそのバグを検知する例を見つけてくれるはずです。そして、そのとおりになります。次に出力を示します。 org.opentest4j.AssertionFailedError: Property [AggregatorProperties:sumOfAllCountsIsNumberOfMeasurements] falsified with sample [[0, 0]] |--------------------jqwik----------------- tries = 11 | # of calls to property checks = 11 | # of not rejected calls generation-mode = RANDOMIZED | parameters are randomly generated seed = -2353742209209314324 | random seed to reproduce generated values sample = [[0, 0]] originalSample = [[2068037359, -1987879098, 1588557220, -130517, ...]] かなり多くの情報が出力されました。テストの試行回数(tries)、実際にテストを実行した回数(checks)、乱数のシード(seed)、不成立のサンプル(sample)が表示されているのがわかります。また、場合によって役立つこともあるその他の情報も表示されています。 この例では、jqwikによって、重複した要素を持つリストが生成され、うまくバグが突き止めてられています。自分でサンプル・テストを書いた場合、このパターンを考えついたことも、考えつかなかったこともあるかもしれません。PBTライブラリを使うことで、追加のサンプルを考え出さなくとも、掘り下げたテストが実現しました。ただし、プロパティベース・テストで行われないことには注意する必要があります。このテストでは、プロパティが正しいことは証明できません。行われるのは、プロパティが成立しないサンプルを見つけようとすることだけです。   jqwikとJUnit 5の統合 jqwikはスタンドアロン・フレームワークではなく、JUnit 5にフックするテスト・エンジンです。JUnit 5は、テストを書いて実行する最新のアプローチを提供するだけでなく、実にさまざまなテスト・エンジン向けのプラットフォームとして設計されています。jqwikの設計上のメリットは、IDEやビルド・ツールに必要なのがJUnitプラットフォームとの統合だけで、個々のテスト・エンジンとの統合は必要ない点です。テスト・エンジンの開発者は、テスト仕様を検出して実行するパブリックAPIなどに悩む必要がないため、この点は大きなメリットになります。テスト・エンジンでは、自動的にIDEとビルド・ツールのサポートが継承されます。 さらに、JUnitプラットフォームでは、任意の数のエンジンを並行して使うこともできます。必要なのは、MavenやGradleの設定に依存性を1つ追加することだけです。Javaでもっとも多く使われている2つのIDEであるIntelliJとEclipseでは、現時点で十分にJUnit 5をサポートしています。GradleとMavenも同様です。   その他のjqwik機能 現在、jqwikには、プロパティベース・テストを実施する際に求められる必須機能がすべて搭載されています。たとえば、多くの標準の型をすぐに生成できます。Number、String、Character、Booleanの各型に加え、組込みのコンテナ型であるList、Set、Stream、Iterator、Optionalが認識されます。そのため、Set<List<String>>型のパラメータを使用でき、jqwikで自動的に文字列のリストのセットを生成してくれます。 プロパティ・メソッドのシグネチャでの値生成に直接的に影響を与えられるアノテーションが多数存在します。そこで、次のようにしてSet<List<String>>型を拡張します。  @ForAll @Size(3) Set<List< @CharRange(min='a', max='f') String>> aSetOfListsOfStrings この変更により、aからfまでの文字だけで構成される文字列のリストを含み、長さが3であるセットだけが生成されます。 値は、完全にランダムに生成されるわけではありません。空文字列、数値0、範囲の最大値および最小値といった、極端なケースや一般的な境界値が考慮されます。制約が十分に厳しければ、jqwikは可能な値の組合せすべてを網羅的に生成してくれます。   プログラムによる値生成 場合によっては、jqwikにデフォルトのジェネレータがないクラスを扱うこともあるでしょう。また、プリミティブタイプに関するドメイン固有の制約が特殊なため、既存のアノテーションでは不十分なこともあります。そういった場合は、パラメータ・ジェネレータの提供をテスト・コンテナ・クラスの別のメソッドに委譲できます。次に示すのは、プロバイダ・メソッドを使ってドイツの郵便番号を生成する方法の例です。 @Property @Report(Reporting.GENERATED) void letsGenerateZipis(@ForAll("germanZipi") String zipi) { } @Provide Arbitrary<String> germanZipi() { return Arbitraries.strings() .withCharRange('0', '9') .ofLength(5) .filter(z -> !z.startsWith("00")); } @ForAllアノテーションのStringの値は、同じクラス内にあるメソッド名を参照しています。このメソッドは、@Provideアノテーションが付加され、Arbitrary<T>型のオブジェクトを返すものとする必要があります。Tには、提供するパラメータの型を静的に記述します。 通常、パラメータ提供メソッドでは、最初にArbitrariesの静的メソッドを呼び出します。そしてほとんどの場合、その後に1つまたは複数のフィルタリング、マッピング、または組合せのアクションを行います。次のセクションでは、この点について説明します。 ❝ランダムな生成によって起きる問題の1つは、ランダムに選択された不成立のサンプルと、失敗するプロパティの背後にある問題との関係が多くのノイズによって埋もれることが多いという点にあります。❞ フィルタリング、マッピング、組合せ すべての値生成のベースタイプとして、Arbitraryクラスにはいくつかのデフォルト・メソッドがあり、それらのメソッドを使って生成動作を変更することができます。通常は、Arbitrariesクラスに存在する静的ジェネレータ関数のいずれかを最初に呼び出します。ほとんどのジェネレータ関数は、Arbitraryの特定のサブタイプを返します。このサブタイプにより、美しいインタフェースを通じて追加設定を行うことができます。 ここでは、1から300までの整数のうち、6の倍数である数を生成するものとします。以下に示すのは、これを実現する2つの方法です。 Arbitraries.integers() .between(1, 300) .filter(anInt -> anInt % 6 == 0) 次のように記述することもできます。 Arbitraries.integers().between(1, 50) .map(anInt -> anInt * 6) いずれの方法が優れているでしょうか。優劣がスタイルや可読性の問題にすぎない場合もありますが、それ以外の場合、選択する方法によってはパフォーマンスに影響を及ぼす可能性もあります。先ほどの2つの選択肢を比べた場合、与えられた仕様に近いのは前者であることがわかりますが、生成されたすべての値のうち6分の5がフィルタリングによって破棄されます。そのため、後者の方が効率的ですが、多少わかりにくくなっています。通常、プリミティブ値の生成は非常に高速であるため、効率性よりも可読性の方が重視されます。 多くの場合、実際のドメイン・オブジェクトには、ほとんど関連性のない別個の部分がいくつか存在します。たとえば、人を表すPersonには、姓と名が必要でしょう。 そのため、無関係のベース・ジェネレータを複数使用した後に、それらの生成結果を組み合わせるのがよいでしょう。次の例では、2つのArbitraryエンティティを組み合わせて1つにすることで、ドメイン・クラスPerson用のArbitraryを作成しています。 @Provide Arbitrary<Person> validPerson() { Arbitrary<String> firstName = Arbitraries.strings() .withCharRange('a', 'z') .ofMinLength(2).ofMaxLength(10) .map(this::capitalize); Arbitrary<String> lastName = Arbitraries.strings() .withCharRange('a', 'z') .ofMinLength(2).ofMaxLength(20); return Combinators .combine(firstName, lastName).as(Person::new); } このテクニックを使用して、8つまでのArbitraryエンティティを1つに組み合わせることができます。必要に応じて、独自のArbitraryエンティティを登録し、ドメインの型のパラメータすべてに自動的に適用されるようにすることもできます。   縮小の重要性 ランダムな生成によって起きる問題の1つは、ランダムに選択された不成立のサンプルと、失敗するプロパティの背後にある問題との関係が多くのノイズによって埋もれることが多いという点にあります。この懸念については、次に示す簡単な例で説明できます。 @Property(shrinking = ShrinkingMode.OFF) boolean rootOfSquareShouldBeOriginalValue( @Positive @ForAll int anInt ) { int square = anInt * anInt; return Math.sqrt(square) == anInt; } このプロパティは、2乗した値の平方根は元の値に等しくなければならないという自明な数学的概念を表しています。最初の行では、shrinkingアノテーション属性を使って縮小をオフにしています。このプロパティを実行すると、次のようなメッセージが表示されて失敗します。 originalSample = [1207764160], sample = [1207764160] org.opentest4j.AssertionFailedError: Property [rootOfSquareShouldBeOriginalValue] falsified with sample [1207764160] jqwikで見つかった、失敗するサンプルは無作為に選択したものです。この数値自体からは、失敗の原因に関する明確な手がかりは得られません。かなり大きい数だという事実も、偶然のことかもしれません。この時点で、ログを追加するか、デバッガを起動してこの問題に関する情報をさらに収集するかのいずれかを行うことになるでしょう。 ❝PBTは、関数、コンポーネント、プログラム全体に対して汎用的で望ましいプロパティを見つけることができるという考え方に基づいています。多くの場合、そういったプロパティは、ランダムに生成されたテスト・データでは成立しないでしょう。❞ それでは、別の方法をとり、ShrinkingMode.FULLを使って縮小をオンにしたうえでプロパティを再実行してみます。失敗するのは同じですが、見つかった不成立のsampleは変化していることがレポートからわかります。 sample = [46341] originalSample = [1207764160] 46,341という数はかなり小さく、元のサンプルとも違う数です。jqwikは、1,207,764,160で失敗した後も、同じように失敗する、より簡単なサンプルを探し続けます。この検索フェーズを縮小と呼びます。元のサンプルから始め、小さい数を探そうとするからです。 それでは、このケースで46,341が特殊な点は何でしょうか。皆さんの想像どおりかもしれませんが、46,341の2乗は2,147,488,281で、Integer.MAX_VALUEよりも少しだけ大きな値になります。そのため、整数のオーバーフローが発生します。つまり、前述のプロパティが成立するのは、Integer.MAX_VALUEの平方根までの整数のみです。 縮小は、PBTにおける重要なトピックです。縮小により、失敗したプロパティの分析の多くがはるかに簡単になるからです。また、PBTの不確定性も減らしてくれます。ただし、優れた縮小を実装するのは、複雑なタスクです。理論的に言えば、検索空間が非常に大きい場合があるという、検索問題に遭遇します。掘り下げた検索には時間がかかるため、縮小を効率的かつ高速に行うために多くの経験則を適用します。   プロパティ検出のパターン PBTの最初の一歩を踏み出すとき、適切なプロパティを探すのは難しいタスクだと感じるかもしれません。プロパティの代表的な例に比べれば、現実世界でのプロパティの特定には別の種類の考え方が要求されます。プロパティを探す際に参考になる一連の便利なパターンが役立つかもしれません。幸いにも、そのすべてを自力で探す必要はありません。PBTが誕生してからしばらく時間がたっているため、小さいながらもよく知られている、プロパティベース・テストのパターンのコレクションが存在します。筆者個人のリストは当然ながら未完のものですが、ここではいくつかの典型的なソースを挙げてみます。 プロパティとしてのビジネス・ルール:ドメイン仕様自体をプロパティとして解釈し、記述できる場合があります。たとえば、「年間取引高がXユーロより大きく、請求書の額がZユーロよりも大きいすべての顧客に対し、Y%の追加値引きを適用する」というビジネス・ルールを考えてみてください。これは、XとZに対してArbitrariesを使い、計算された値引率が実際にYであることを確認することで、そのままプロパティに変換できます。 逆関数:関数に逆関数がある場合、まずその関数を適用し、次に逆関数を適用すれば、元の入力が返されます。 べき等関数:べき等関数を複数回適用しても、結果は変わりません。たとえば、リストを2回並べ替えても、結果は変わりません。 不変関数:コードのプロパティには、ロジックを適用しても変わらないものがあります。たとえば、ソートやマッピングでは、コレクションのサイズは変わりません。また、リストから値をフィルタで除外しても、残った値の順序は元の順序と同じです。 交換可能性:一連の関数が交換可能である場合、関数を適用する順番を変えても最終的な結果は変わりません。たとえば、ソートしてからフィルタリングしても、フィルタリングしてからソートしても、同じ結果となります。 テスト・オラクル:テスト対象の関数の代替実装を知っている場合もあるでしょう。その場合は、テスト・オラクルとしてその実装を使うことができます。関数を使った結果はすべて、元の実装と代替実装で同じになるはずです。代替実装のサンプルをいくつか示します。 簡単で遅いものと複雑だが速いもの パラレルとシングルスレッド 自作と商用 古いもの(リファクタリング前)と新しいもの(リファクタリング後) 計算しにくいが検証しやすい:ロジックによっては、実行することは難しいが確認するのは簡単というものがあります。たとえば、素数を探す作業と、素数かどうかを確認する作業について考えてみてください。 帰納法(最初に小さな問題を解くこと):ドメイン・チェックを、ベース・ケースと、そのベース・ケースから導出された汎用的なルールに分割できるかもしれません。 ステートフル・テスト:特にオブジェクト指向の世界では、オブジェクトの動作を、有限の状態セットと、その状態を変化させるアクションがあるステート・マシンとして記述できることがよくあります。状態遷移空間の調査は、PBTの重要なユースケースです。そのため、jqwikはこれに対する特別なサポートを提供しています。 ファジング:予期しないさまざまな入力データを大量に投入しても、コードは決して誤動作すべきではありません。そのため、このパターンの主な考え方は、多種多様な入力を生成し、テスト対象の関数を実行して、以下のことを確認するというものです。 例外が発生しない。少なくとも、予期しない例外は発生しない。 HTTPリクエストに対してリターン・コード5xxが発生しない。さらに進んで、常に2xxステータスを要求する場合もある。 すべての戻り値が有効である。 ランタイムに適切なしきい値が設定されている。 ファジングは、既存のコードやシステムの堅牢性を詳細に調べる場合にさかのぼって行われることが多い手法です。 前述のパターンをコードに適用できるようになるためには、訓練が必要です。しかし、こういったパターンは、テスト記述者がスランプに打ち勝つための優れた開始点となるでしょう。自分のコードのプロパティについて考えれば考えるほど、サンプルベース・テストからプロパティベース・テストを導き出すチャンスを認識するようになります。プロパティベース・テストは、ときには補完的役割を果たし、ときには古いテストを置き換えるものとなります。   まとめ PBTは新しい技術ではなく、HaskellやErlangなどの言語では、10年超にわたって効果的に使われ続けています。PBTは、関数、コンポーネント、プログラム全体に対して汎用的で望ましいプロパティを見つけることができるという考え方に基づいています。多くの場合、そういったプロパティは、ランダムに生成されたテスト・データでは成立しないでしょう。 jqwikは、JVMベースのプロパティ・テスト・エンジンです。JUnit 5プラットフォーム用に構築されているため、あらゆる最新のIDEやビルド・ツールとの統合がシームレスです。(まだ)JUnit 5を使っていない方は、いくつかの代替ツールも利用できます。本記事は、PBTの表面をなぞったにすぎません。さらに深く知りたい方は、こちらのブログ・シリーズからご覧ください。 Java Magazine December 2019の他の記事 Arquillian:簡単なJakarta EEテスト ArchUnitでアーキテクチャの単体テストを行う 新しいJava Magazine 作ってみよう:自分だけのテキスト・エディタ(パート1) クイズに挑戦:Collectorsの使用(上級者向け) クイズに挑戦:ループ構造の比較(中級者向け) クイズに挑戦:スレッドとExecutor(上級者向け) クイズに挑戦:ラッパー・クラス(中級者向け) 書評:Core Java, 11th Ed. Volumes 1 and 2 Johannes Link Johannes Link(@johanneslink):およそ25年にわたってプロのソフトウェア開発者として活躍。2001年という早い時期からテスト駆動開発のとりこになり、その関連書籍も執筆している。初期のJUnit 5における中心的コミッターの1人で、jqwikのメイン開発者でもある。

無数の値を使ってコードをテストする方法 著者:Johannes Link 2019年8月20日 JUnitなどのツールを使って単体テストを記述することは、コードの品質を確保するうえで欠かせない技術です。しかし、発生する可能性がある問題すべてを確認するために多くのテスト・ケースが必要となる関数の場合、テストは面倒でエラーが起こりやすくなります。その救世主となり得るのがプロパティベース・テスト(PBT)です...

新しいJava Magazine

読み心地を改善し、投稿頻度を高めた新しいホームにようこそ 著者:Andrew Binstock 2019年8月27日 (※編集部注:本記事はオリジナル版のJava Magazineについての情報を翻訳したものです。Java Magazine 日本版は、Blog記事形式でお届けします。また、発行時期についても、現在のところ不定期となっておりますのでご了承ください。) いよいよ、長い間予告していたWebベースのJava Magazineが始動します。しばらく時間をかけて作業を行ってきましたが、この移行によっていくつかのメリットが生まれるため、きっと気に入っていただけるのではないかと思っています。 もっとも明らかな改善点は、記事がレスポンシブHTMLで表示されるようになったことです。PDFが読み込まれるのを待つことなく、オンラインで各記事を読むことができます。この新しい形式は、どんなサイズのモバイル機器にも適応します。さらに、クリックしてページを進めたり戻したりしなければならない複数ページの形式ではなく、スクロールできる1つのページとして記事が表示されます。 本誌は、ダウンロードできるPDFファイルとしては提供されなくなります。レスポンシブHTMLへの移行によって、ダウンロードできるPDF形式をあえて廃止しています。モバイル機器で記事を読む読者が増えるほど、PDFドキュメントの不便さが目立つようになってきました。説明をたどるためにページを行ったり来たりする必要がある、多くのコードが掲載された長い記事では特にそうです。 PDFは完全に廃止しますが、PDFのバックナンバーをダウンロードしたい方のために、2年分をAll Issuesタブから自由にダウンロードできるようにしています。 さらに、スケジュールを変更して月刊といたします。これまでの隔月の発行では、タイムリーな内容をお届けするのが非常に困難でした。新しいスケジュールによって、最新情報や耳よりなお知らせを今までよりも早く受け取れるようになります。このように書くのは、少しばかり不正確かもしれません。実際には、記事は1か月にわたって随時(通常はテーマごとに)公開されます。その後、公開した記事へのリンク、各記事をまとめるテーマ、その他の投稿済み記事を含むお知らせをお送りします。 要するに、コンテンツが増えて読み心地も改善されます。 このようなプロジェクトではとてもよくあることですが、私たちは皆さんのフィードバックを非常に頼りにしています。皆さんの思慮深いコメントや批判に応えて、細かい部分を調整し続ける予定です(もちろん、賛辞も大歓迎です)。 ぜひ、javamag_us@oracle.comにお送りください。これまでに意見をお寄せくださった方なら、私がすべてのコメントに目を通し、お答えしていることをご存じでしょう。 移行中はご不便をおかけしました。そして、新しいJava Magazineにようこそ。   Java Magazine December 2019の他の記事 プロパティベース・テストを習得する Arquillian:簡単なJakarta EEテスト ArchUnitでアーキテクチャの単体テストを行う 作ってみよう:自分だけのテキスト・エディタ(パート1) クイズに挑戦:Collectorsの使用(上級者向け) クイズに挑戦:ループ構造の比較(中級者向け) クイズに挑戦:スレッドとExecutor(上級者向け) クイズに挑戦:ラッパー・クラス(中級者向け) 書評:Core Java, 11th Ed. Volumes 1 and 2 Andrew Binstock Andrew Binstock(javamag_us@oracle.com、@platypusguy):Java Magazine編集長。Dr. Dobb's Journalの元編集長。オープンソースのiText PDFライブラリを扱う会社(2015年に他社によって買収)の共同創業者。16刷を経て、現在もロング・テールとして扱われている、Cでのアルゴリズム実装についての書籍を執筆。以前は UNIX Review で編集長を務め、その前には C Gazetteを創刊し編集長を務めた。妻とともにシリコン・バレーに住んでおり、コーディングや編集をしていないときは、ピアノを学んでいる。

読み心地を改善し、投稿頻度を高めた新しいホームにようこそ 著者:Andrew Binstock 2019年8月27日 (※編集部注:本記事はオリジナル版のJava Magazineについての情報を翻訳したものです。Java Magazine 日本版は、Blog記事形式でお届けします。また、発行時期についても、現在のところ不定期となっておりますのでご了承ください。) いよいよ、長い間予告していたWebベースの...

ArchUnitでアーキテクチャの単体テストを行う

アーキテクチャの欠陥をビルド時に発見 著者:Jonas Havers 2019年8月20日 開発組織がよく直面する問題に、コードの実装がもともとの設計やアーキテクチャからたびたびずれてしまうことがあるというものがあります。この問題は、大規模なプロジェクトでは特にですが、よく起きるものであるため、コードの実装と最初に定義されたアーキテクチャとの整合性をテストする新しいツールが登場しています。ArchUnitは、小さくシンプルで拡張可能な、オープンソースのJavaテスト・ライブラリです。このライブラリは、事前に定義したアプリケーション・アーキテクチャの特徴やアーキテクチャの制約を検証するためのものです。ArchUnitのテストは、単体テストとして記述して実行します。そのため、開発者やアプリケーション・アーキテクトが、作業に対するフィードバックを迅速に得ることができます。アーキテクチャの違反が含まれていた場合、このテストにより、ソフトウェアのビルドが確実に中断されます。 本記事では、アーキテクチャのテストを行うべき理由と、ArchUnitを使って実際にそのテストを開始する方法について説明します。本記事で紹介しているコード・スニペットや、さらなるサンプルは、筆者のGitHubリポジトリで公開しています。   アーキテクチャのテストを行うべき理由 ソフトウェアのアーキテクチャは、わかりやすく変更しやすいコードベースを実現するためや、ソフトウェアの品質目標に準拠するために重要な前提条件です。コードベースについて言えば、ソフトウェアのアーキテクチャの主な目標は、保守性、置換性、拡張性の3つです。それらの目標を達成する能力を最大化することにより、チームの反復作業の速度を高めることができます。すなわち、アプリケーションが成長したときに、機能追加やバグの修正を短時間で行うことができます。ソフトウェア・システムの保守性、置換性、拡張性を維持するためには、そのシステムがモジュール式になっており、相互依存ができる限り少なくかつ正確であることを保証する必要があります。そうすれば、凝集度が高くかつ疎結合であるシステムが実現します。 こういった目標は、一定のパターンやコード表記規則の導入により達成できます。その場合、該当するパターンや規則を完全に文書化したうえで、それに賛同している開発チーム全体に伝達する必要があります。 既存のソフトウェア・システムの保守が難しくなった場合、自動アーキテクチャ検証を事後導入することも適切な選択肢です。テストによって、技術的負債を段階的に減らしていくことができます。こうすることで、目標としたプロジェクト・アーキテクチャの実現に向けた進捗の監視や検証を行うことができます。   アーキテクチャのテストを記述する準備 通常、アプリケーション・アーキテクチャのコンセプトや構造をテストするためには、アーキテクチャ・モデルをコードにマッピングする作業か、既存のアプリケーションからアーキテクチャ・モデルを導出する作業が最初に必要になります。これを行う場合、あらかじめコード構造について考えておくだけでなく、アプリケーションのコードでどのようにすればドメイン・コンセプトや技術的コンセプトを特定できるか(または、特定できるようになるか)を考えておくことが必要です。これには、「コントローラ」や「サービス」などの具体的なアプリケーション・コンポーネントの技術用語や、「プロダクト」や「顧客」などのドメイン固有用語、そしてそれらの間の関係を特定することが含まれます。 用語、関係、表記規則に賛同したら、静的アーキテクチャのルール体系を作成できます。この体系により、開発者はそのルールに準拠したコードを書くことや変更することができます。つまり、レイヤーやパッケージ、クラスのネーミング方式、アノテーションなどを使用してコンセプトを実装することにより、メンタル・モデルをマッピングすることができます。   ArchUnitを選ぶ理由 最初のArchUnitライブラリは、Peter Gafert氏が2017年に作成しました。ArchUnitにより、アプリケーションのクラスを特別なJavaコード構造にインポートし、Javaの任意の単体テスト・フレームワークを使ってコードとその構造をテストすることができます。ArchUnitでは、実行可能テスト形式でアプリケーション・アーキテクチャの静的プロパティのルールを実装できます。たとえば、次のようなものです。 パッケージ依存性チェック クラス依存性チェック クラスとパッケージの包含性チェック 継承チェック アノテーション・チェック レイヤー・チェック サイクル・チェック さらに、コンストラクタ、メソッド、フィールド、メンバー、および「コード・ユニット」(すなわち、他のコードにアクセスできるメソッド、コンストラクタ、静的クラス初期化機能)のカスタム・テストを作成できます。これらのチェックを使用して、固有のアーキテクチャ制約に加え、ネーミング規則などのコーディング・ルールも検証することができます。 レイヤー間やパッケージ間の依存性をテストするツールにはさまざまなものがあります。これはアーキテクチャの検証において、とりわけレイヤー型アーキテクチャの場合、重要な懸念事項です。コードのlintツールにより、多くのコーディング・ガイドライン(クラスやメンバーのネーミングなど)に対処できますが、こういったツールはスコープが限られており、ルールがさらに複雑になった場合、部分的にしか使えなくなる可能性があります。その結果、複数のツールの組合せによってしか強制できないルールが出てくる可能性もあります(ときには、ツールを組み合わせても強制できないこともあります)。カスタム・テスト・スイートでさまざまなツールやAPI(Java Reflection APIやAspectJなど)、および追加言語(Groovyなど)を使用すると、初心者の場合は特に、結局のところ習得がいたずらに難しくなります。 対照的に、ArchUnitでは、特別なインフラストラクチャや新しい言語は一切必要ありません。ルールを検証するテストは、プレーンJavaで記述できます。ArchUnitでは、Javaバイトコードに変換された他の言語(Kotlinなど)のテスト・コードやアプリケーション・コードを扱うこともできます。ルールは任意の単体テスト・ツールで評価できますが、JUnit 4およびJUnit 5でテストを記述する場合の拡張サポートが存在します。 アーキテクチャが進化している場合、実装ルールも時間とともに進化します。組込みの自動実行テストを使用すると、組織は事前定義ルールからの逸脱があることを意識的に認めざるを得なくなります。後ほどレビューで偶然発見することや、決して発見できないことはなくなります。ArchUnitでは、逸脱の警告が可能です。 筆者の経験では、いったんArchUnitでルールを書き始めれば、次々とユースケースに気づきます。たとえば、サードパーティ製ライブラリの正しくない使用を避けることができ、「コードの臭い」のパターンと比較してテストすることにより、そういった兆候をプロジェクトから排除することもできます。ArchUnitのAPIによって創造性が刺激され、コード全体の品質を向上させるために行う、新しいチェックの発案や既存ルールの改善が容易になります。 さらに、ArchUnitライブラリには、一般的な事前定義ルールも用意されています。ライブラリにおいてすべての使用方法を予測するのは難しいため、拡張可能であることがなおさら重要です。拡張性を実現するため、ArchUnitではカスタム・チェックを記述する便利な方法を提供しています。具体的には、いくつかの事前定義された組合せ可能なビルディング・ブロックやインタフェースを使います。   内部動作 ArchUnitでは、リフレクションとJavaバイトコード分析を使用しています。Java Reflection APIから取得できない情報は、バイトコード・レベルで取得します。たとえば、Reflection APIでは、クラスへのアクセスまたはクラスからのアクセスについての情報を取得する方法は提供されていません。しかし、この情報はバイトコードに含まれています。つまり、2つのクラス間の依存性は、Javaバイトコード分析によってのみ取得できます。バイトコードを分析するために、ArchUnitライブラリではASMを使用します。ASMは、Javaバイトコードの読取り、書込み、操作を行う万能フレームワークです(詳しくは、本誌で以前特集したASMの記事をご覧ください)。 ASMを使用して、単体テストによく似ているものの、アーキテクチャ制約を対象にしたテストを記述することができます。たとえば、ArchUnitでアーキテクチャ・ルールを記述すると、次のようになります。 ArchRule rule = ArchRuleDefinition.classes() .that().resideInAPackage("..domain..") .should().onlyBeAccessed() .byAnyPackage("..domain..", "..application.."); 別の例を示します。 ArchRule rule = ArchRuleDefinition.methods() .that().arePublic() .and().areDeclaredInClassesThat().resideInAPackage("..adapters.primary.web..") .and().areDeclaredInClassesThat().haveSimpleNameEndingWith("Controller") .and().areDeclaredInClassesThat().areAnnotatedWith(Controller.class) .should().beAnnotatedWith(RequestMapping.class); ArchUnitは、3つの主要なAPIレイヤーに分かれています。Core、Lang、Libraryという3つのレイヤーですが、次のセクションではこの点について詳しく説明します。   使用の開始 ArchUnitライブラリは、Maven Centralから入手できます。まず、MavenまたはGradleで宣言を行い、依存性を取得する必要があります。その後は、Javaの任意の単体テスト・フレームワークを使用し、テストを記述して実行することができます。次に示すのは、Mavenユーザー向けのPOMエントリです。 <dependency> <groupId>com.tngtech.archunit</groupId> <artifactId>archunit</artifactId> <version>0.11.0</version> <scope>test</scope> </dependency> Gradleユーザー向けのPOMは次のようになります。 dependencies { testCompile 'com.tngtech.archunit:archunit:0.11.0' } ArchUnitでは、JUnit向けにArchUnitRunnerを提供しています。このランナーにより、コードの定型挿入文が減少します。また、複数のテストに使うクラスを毎回インポートしなくてもよいように、インポートしたクラスがURL別にキャッシュされます。JUnit 4でこのランナーを使う場合は、上記の依存性のarchunitアーティファクトをarchunit-junit4に置き換えます。JUnit 5では、archunit-junit5-apiおよびarchunit-junit5-engineアーティファクトを使用します。その他の情報は、インストール・ガイドに記載されています。 ArchUnitRunnerとJUnitを使う場合、ArchRulesは静的フィールド、または1つのJavaClasses引数を持つ静的メソッドのいずれかで定義できます。いずれの場合も、@ArchTestアノテーションを付加する必要があります。これにより、すでにインポートされてキャッシュされたクラスがランナーによって再利用され、ルールはキャッシュされたクラスを対象として評価されます。次に例を示します。 @RunWith(ArchUnitRunner.class) @AnalyzeClasses( packages = "com.company.app", importOptions = ImportOption.DoNotIncludeTests.class ) public class ArchitectureRulesTest { @ArchTest public static final ArchRule ruleAsStaticField = ArchRuleDefinition.classes() .should()... @ArchTest public static void ruleAsStaticMethod(JavaClasses classes) { ArchRuleDefinition.classes() .should()... } } JUnit 5では、ランナーを宣言する必要はありません。そのため、最初の行@RunWith(ArchUnitRunner.class)を削除できます。 前述のように、ArchUnitではチェックを単体テストとして記述します。その性質上、継続的インテグレーション(CI)パイプラインに特別な手順を導入する必要はありません。このテスト・スイートは、任意のCI環境やデプロイ・パイプラインに組み込むことができます。 既知のアーキテクチャ違反でテストが中断しないように、そういった違反を除外することができます。これを行うには、archunit_ignore_patterns.txtという名前のファイルをクラスパスのルート・ディレクトリに配置します。このファイルのそれぞれの行は正規表現と解釈され、報告された違反と照合されます。違反のメッセージがファイル内のパターンと一致した場合は、無視されます。1つのテストを無視するためには、テスト・クラスで@ArchIgnoreアノテーションを使います。バージョン0.11.0以降では、FreezingArchRuleという機能を使うこともできます。この機能は、ルールの違反が多すぎてすぐに修正できない場合に、現在の違反状態を保存するものです。とは言え一般論としては、テストを無視すべきではありません。ただし、これらのオプションを使うことで、アーキテクチャに関する既知の欠陥や侵害を含む、既存のソフトウェア・プロジェクトにArchUnitを組み込めるようになります。そうすれば、ルールを満たすことを目的として、修正やクリーンなアーキテクチャへの移行を繰り返すことができます。 また、異なるプロジェクト間で、共通のアーキテクチャ・ルールをコピーすることなく、簡単に共有して強制できるサードパーティ製Mavenプラグインもあります。   ArchUnitの中身 前述のように、ArchUnitは3つの主要APIであるCore、Lang、Libraryの各レイヤーに分かれています。 Core API:このレイヤーは、Reflection APIに似ています。さらに、バイトコードのインポート方法などの基本インフラストラクチャも扱います。コンパイル済みのJavaクラス・ファイルをインポートするためには、ClassFileImporterを使います。このインポーターでは、コンパイル済みのJavaクラスをインポートするさまざまな方法を提供しますが、もっとも便利な方法は、次に例を示すように、1つまたは複数のベース・パッケージを宣言することです。テスト・クラスやアーカイブ(JARなど)といった特定の場所を除外できます。 JavaClasses classes = new ClassFileImporter() .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_TESTS) .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_ARCHIVES) .importPackages("com.company.app"); インポーターから返されるのは、JavaClassesのインスタンスです。このインスタンスは、JavaClass型の要素のコレクションを表します。JavaClassは、1つのインポート済みクラス・ファイルを示します。 Coreのオブジェクトは、Reflection APIの同等のオブジェクトから命名されていますが、Javaというプリフィックスが追加されています。さらに、Core APIには代表的なクラスとして、JavaPackage、JavaMethod、JavaFieldなどもあります。以前にReflection APIを使ったことがある開発者なら、getName()、getMethods()、getRawType()、getRawParameterTypes()といったメソッドはおなじみでしょう。ArchUnitのCore APIにも、これらと同等のメソッドがあります。 追加のアクセス情報は、JavaMethodCall、JavaConstructorCall、JavaFieldAccessを使ってバイトコードから取得できます。たとえば、JavaClassインスタンスに対してgetAccessesFromSelf()を呼び出すことにより、インポート済みJavaクラスと、他の複数のインポート済みJavaクラスとの間でアクセスを反復させ、そのアクセスを分析することができます。同じようなアクセス・チェックは、getAccessesToSelf()、getFieldAccessesFromSelf()、getFieldAccessesToSelf()の各オブジェクト・メソッドで行うことができます。 Lang API:Coreのクラスだけを使ってアーキテクチャのテストを行うことは可能ですが、表現力に欠けることになります。これに対処するため、ArchUnitではLang APIで高レベルの抽象化を提供しています。このAPIでは、次の3つの中核コンポーネントで構成された、流れるようなインタフェースを提供します。 DescribedPredicate:関連クラスを選択する基準 ArchCondition:選択されたクラスが満たさなければならない条件 ArchRule:アーキテクチャのコンセプトを定義するルール Lang APIの大部分も同様に、流れるようなAPIとして構成されているため、IDEでは、使うAPIについての有益な提案を行うことができます。 クラスArchRuleDefinitionは、ArchRuleを定義するエントリ・ポイントとして使われます。先ほど触れた3つのAPIコンポーネントを使用して、提供されている選択基準および条件にとどまらず、ニーズを満たす独自のものを作成できます。 次の例では、ドメイン・クラスが他のドメイン・クラスまたはアプリケーション・クラスからのみアクセスされることを検証しています。 ArchRule rule = ArchRuleDefinition.classes() .that().resideInAPackage("..domain..") .should().onlyBeAccessed() .byAnyPackage("..domain..", "..application.."); ❝この構文は、AspectJのポイントカットの影響を受けています。❞ パッケージ表記法の「..」は、任意の数のパッケージを表します。この構文は、AspectJのポイントカットの影響を受けています。つまり、この例のArchRuleは、com.company.app.domain.modelなどのパッケージ内にある任意のクラスに適用されます(DescribedPredicate)。また、そのクラスがdomainパッケージまたはapplicationパッケージ内のクラス、あるいはそれらのパッケージのサブパッケージ内にあるクラスによってのみアクセスされることが検証されます(ArchCondition)。 ArchUnitルールのチェックに失敗した場合、ルールのテキストとすべての違反を内包するjava.lang.AssertionErrorが報告されます。この報告には、クラスと行番号も含まれています。 また、ArchRuleDefinition.noClasses()で始めることにより、クラス・ルールを否定することもできます。クラスだけでなく、コンストラクタ、メソッド、フィールド、メンバー、コード・ユニットを直接テストすることもでき、それぞれを否定する方法も存在します。 次に示すのは、Lang APIを使って長い記述をした例です。複雑なチェックがどのようなものになるかをご覧ください。この例はSpringフレームワークを対象としたもので、Springのモデル・ビュー・コントローラ(MVC)クラスのメソッドをチェックするために使用できます。 ArchRule rule = ArchRuleDefinition.methods() .that().arePublic() .and().areDeclaredInClassesThat() .resideInAPackage("..adapters.primary.web..") .and().areDeclaredInClassesThat() .haveSimpleNameEndingWith("Controller") .and().areDeclaredInClassesThat() .areAnnotatedWith(Controller.class) .or().areDeclaredInClassesThat() .areAnnotatedWith(RestController.class) .should().beAnnotatedWith(RequestMapping.class) .orShould().beAnnotatedWith(GetMapping.class) .orShould().beAnnotatedWith(PostMapping.class) .orShould().beAnnotatedWith(PatchMapping.class) .orShould().beAnnotatedWith(DeleteMapping.class); このルールでは、コントローラ内のパブリック・メソッドにSpring MVCのリクエスト・マッピング・アノテーションのいずれかが付加されていることを確認し、リクエストの処理に使われないパブリック・メソッドがコントローラに存在しないようにしています。選択されたクラスは、Controllerで終わる単純名を持ち、Spring MVCの@Controllerまたは@RestControllerアノテーションが付加され、..adapters.primary.web..パッケージまたはそのサブパッケージ内に存在しなければなりません。このようなルールにより、メソッド・レベルで強いコーディング規約を強制できます。 上記のようなルールを作成したら、そのルールをテスト結果に反映させるために、インポートしたJavaクラスに対してチェックを行う必要があります。 JavaClasses classes = new ClassFileImporter() ... ArchRule rule = ... rule.check(classes); Library API:このレイヤーには、さらに抽象化された複雑な事前定義ルールが含まれています。たとえば、ArchUnitでは、Architectures.LayeredArchitectureのインスタンスを使ってレイヤー型アーキテクチャの定義を作成し、個々のレイヤーに対してチェックを行うことができます。レイヤー型アーキテクチャは、レイヤー、名前、パッケージを規定することで簡単に定義できます。レイヤー型アーキテクチャとして表現できるポート・アダプタ・アーキテクチャの定義は、次のようなものになります。 Architectures.LayeredArchitecture portsAndAdaptersArchitecture = Architectures .layeredArchitecture() .layer("domain layer") .definedBy("com.company.app.domain..") .layer("application layer") .definedBy("com.company.app.application..") .layer("adapters layer") .definedBy("com.company.app.adapters.."); ここで、このアーキテクチャ定義を使用し、レイヤーに対してルールを定義することができます。ルールは、1つのテストに直接追加することも、次の例に示すように、個々のテストに保存されているインスタンス変数に追加することもできます。いずれの場合でも、whereLayerメソッドでレイヤー条件を追加します。 ArchRule applicationLayerRule = portsAndAdaptersArchitecture .whereLayer("application layer") .mayOnlyBeAccessedByLayers("adapters layer"); ArchUnitバージョン0.11.0では、Jeffrey Palermo氏が言うところのオニオン・アーキテクチャのセマンティックを検証するための新しい事前定義APIであるArchitectures.onionArchitecture()が追加されています。オニオン・アーキテクチャは、ポート・アダプタ・アーキテクチャに関連しています。このAPIも他と同じように使うことができますが、それぞれのアダプタを定義する必要があります。 Architectures.OnionArchitecture onionArchitecture = Architectures.onionArchitecture() .domainModels("com.company.app.domain.model..") .domainServices("com.company.app.domain.service..") .applicationServices("com.company.app.application..") .adapter("cli", "com.company.app.adapters.cli..") .adapter("web", "com.company.app.adapters.web.."); ArchUnitのLibrary APIには、スライスを扱うものがあります。スライスは、基本的にJavaクラスのサブセットのルール定義です。各サブセットは、パッケージの挿入辞のパターンに一致します。スライスの作成と、スライスに対するアサーションの実行には、SlicesRuleDefinitionを使用します。その結果、Slices APIのSliceRuleオブジェクトが生成されます。SlicesRuleDefinitionビルダーを使用してSliceRuleを作成し、循環依存を検出することができます。すなわち、スライス間に循環が発生していないことや、個々のスライスが相互に依存していないことを確認できます。たとえば、次のSliceRuleは推移的依存性の検出に役立ちます。 SliceRule layersShouldBeFreeOfCycles = SlicesRuleDefinition.slices() .matching("com.company.app.(*)..") .should().beFreeOfCycles(); SliceRule adaptersShouldNotDependOnEachOther = SlicesRuleDefinition.slices() .matching("com.company.app.adapters.(**)..") .should().notDependOnEachOther(); ここでも、照合の表記法はAspectJの構文の影響を受けたものになっています。最初のルールでは、appの1階層下位にあるパッケージのクラスを対象として、スライス間に循環が発生していないことを確認します。2つ目のルールでは、adaptersのすべてのサブパッケージ(たとえば、..adapters.primary.web..や..adapters.secondary.mongodb..)内にあるJavaクラスをグループ化し、それらすべてのスライス間の相互依存性をチェックします。   たとえば、Webコントローラ(プライマリ・アダプタ)からMongoDBリポジトリ(セカンダリ・アダプタ)に直接アクセスしている場合、ArchUnitでは次のエラーが生成されます。このエラーは、上記の2つ目のルールに対するものです。 java.lang.AssertionError:Architecture Violation [Priority:MEDIUM] - Rule 'slices matching 'com.company.app.adapters.(**)..' should not depend on each other' was violated (1 times): <strong>Slice primary.web calls Slice secondary.mongodb</strong> 先ほどの例でアスタリスクを1つだけ使ったとすれば、クラスはプライマリとセカンダリの2つのスライスにのみグループ化されたでしょう。エラー・メッセージにもそれが反映されることになります。 Library APIには、GeneralCodingRulesクラスも含まれています。このクラスには、多くのJavaプロジェクトで一般的に使われている静的コーディング・ルールが含まれ、いずれも自己記述的な名前で事前に定義されています。たとえば次のようなものです。 NO_CLASSES_SHOULD_ACCESS_STANDARD_STREAMS(クラスから標準ストリームへのアクセスを禁止します。標準ストリームとは、System.outやSystem.err、そしてprintStackTraceメソッドを指します。代わりにロギング・ライブラリを使います) NO_CLASSES_SHOULD_THROW_GENERIC_EXCEPTIONS(クラスから汎用例外をスローすることを禁止します。たとえば、RuntimeExceptionをスローする代わりに、IllegalArgumentExceptionのようなカスタム例外を使います) NO_CLASSES_SHOULD_USE_JAVA_UTIL_LOGGING(クラスでJavaユーティリティのロギングの使用を禁止します。SLF4JのバックエンドにLog4jやLogbackを使う場合に指定します)  NO_CLASSES_SHOULD_USE_JODATIME(クラスでJoda-Timeの使用を禁止します。最新のjava.time APIを使う場合に指定します)   テストを記述する際の留意事項 コードベースが大きい場合は、テストの際にクラス・ファイルのインポートをキャッシュすべきです。この手順により、テストの実行時間を大幅に削減できます。インポートしたクラスのキャッシュは、たとえばArchUnitRunnerで実現できます(JUnitサポートを使っている場合)。コードベースが小さい場合、クラスの再インポートによるオーバーヘッドは無視できます。 テスト対象のコンセプトは、可能な限り正確に記述された、ルールの要点を明確に伝えるものであることが重要です。複雑なルールの場合は、生成されるルール・テキストに依存するのではなく、明確でわかりやすいルール・テキストを使う方が理にかなっているでしょう。場合によっては、長いルール定義を、短くわかりやすい複数のルールに分割できることもあります。 また、実装されたルールに、何も考えずに従うべきではありません。同様に、あらかじめ考えることなく、簡単にテストを通過させるためにルールを変えるべきでもありません。ときには、新しいコンポーネントが既存のコンセプトに適合しないため、既存のルールの変更や拡張が必要になります。アーキテクチャが進化している場合、このようなことはよく起こります。しかし、前述のように、ArchUnitで提供されるテストを無視するオプションは、過剰に使用すべきではありません。未成熟なプロジェクトでは、特にそう言えます。   ArchUnitの代替プロダクトとその使用タイミング 言語レベルでは、Java 9で導入されたProject Jigsawのモジュール・システムが、意図せずにレイヤー間の依存性が発生することを防ぐために非常に役立ちます。モジュール依存性を明示的に指定するからです。残念ながら、この機能は既存のアプリケーションにはあまり役立ちません。Java 8以前を必要とする場合は、特にそうです。さらに、Jigsawで保証されるのはモジュール性とモジュール間の依存性だけです。これは品質の1つの側面でしかなく、ArchUnitで実行できるチェックです。 ArchUnitの代わりに使えるものに、jQAssistantがあります。このツールは、プロジェクトを分析し、生成された情報をNeo4jグラフ・データベースに格納するものです。jQAssistantではAsciiDocとの統合が提供されているため、テストをドキュメントに埋め込むことができます。ターゲット・アーキテクチャに移行しようとしている場合、これは実用的なツールです。商用プロダクトも存在します。その一例であるStructure101 Studioは、システムやアーキテクチャの監査に使われることが多い製品です。さらに、いくつかの静的コード解析ツールでは、ArchUnitで行うことの一部を実行できます。たとえば、DegraphやDeptectiveなどがあります。こういったツールの中には、ビルド環境や、場合によってはIDEに組み込めるものもあります。   まとめ ArchUnitは小さなライブラリですが、アプリケーションの規模を問わず、アーキテクチャや内部コードの品質の単体テストに使用できます。ArchUnitにより、短時間で容易かつ実践的に、コードの品質目標テストを始めることができます。ArchUnitによってビルド・プロセスの間に行われるテストで、Javaアプリケーションのアーキテクチャが、定義されたルールに準拠していることを確認できます。流れるようなAPIと細かく記述されたJavadocドキュメントに加え、公式ガイドでは、コードベースのチェックのためにArchUnitで提供されているさまざまなオプションについて説明されています。   Java Magazine December 2019の他の記事 プロパティベース・テストを習得する Arquillian:簡単なJakarta EEテスト 新しいJava Magazine 作ってみよう:自分だけのテキスト・エディタ(パート1) クイズに挑戦:Collectorsの使用(上級者向け) クイズに挑戦:ループ構造の比較(中級者向け) クイズに挑戦:スレッドとExecutor(上級者向け) クイズに挑戦:ラッパー・クラス(中級者向け) 書評:Core Java, 11th Ed. Volumes 1 and 2 Jonas Havers Jonas Havers(@JonasHavers):ドイツでフリーランスのフルスタック・ソフトウェア・エンジニアとソフトウェア・エンジニアリングの講師として活躍。主にeコマース関係のプロジェクトで、Java、Kotlin、Groovy、TypeScript、JavaScriptを組み合わせたWebアプリケーションを開発。リモート・ワークの支持者であるとともに、ブログで頻繁に発信している。

アーキテクチャの欠陥をビルド時に発見 著者:Jonas Havers 2019年8月20日 開発組織がよく直面する問題に、コードの実装がもともとの設計やアーキテクチャからたびたびずれてしまうことがあるというものがあります。この問題は、大規模なプロジェクトでは特にですが、よく起きるものであるため、コードの実装と最初に定義されたアーキテクチャとの整合性をテストする新しいツールが登場しています。ArchUni...

Java Magazine December 2019

※Java Magazineは本号よりWEB記事化されました。 2019年12月 プロパティベース・テストを習得する 著者:Johannes Link 無数の値を使ってコードをテストする方法   Arquillian:簡単なJakarta EEテスト 著者:Josh Juneau Arquillianフレームワークを使ってJakarta EEアプリケーションをテストする方法   ArchUnitでアーキテクチャの単体テストを行う 著者:Jonas Havers アーキテクチャの欠陥をビルド時に発見 新しいJava Magazine 著者:Andrew Binstock 読み心地を改善し、投稿頻度を高めた新しいホームにようこそ   作ってみよう:自分だけのテキスト・エディタ(パート1) 著者:Ian Darwin 新連載:階層化設計と反復型開発を使ってライン・エディタをテキスト・エディタに進化させる   クイズに挑戦:Collectorsの使用(上級者向け) 著者:Simon Roberts、Mikalai Zaikin Collectorsクラスから想定どおりの結果を得るために注意すべきこと   クイズに挑戦:ループ構造の比較(中級者向け) 著者:Simon Roberts、Mikalai Zaikin ユーザーの手動入力をループ処理する場合に使用するループ構造、そこには多くの微妙な違いが...   クイズに挑戦:スレッドとExecutor(上級者向け) 著者:Simon Roberts、Mikalai Zaikin ExecutorServiceを使って行う具体的な処理の詳細   クイズに挑戦:ラッパー・クラス(中級者向け) 著者:Simon Roberts、Mikalai Zaikin Integerラッパー・クラスを使って2つの整数のインスタンスを作成したときに、値を比較する正しい方法

※Java Magazineは本号よりWEB記事化されました。 2019年12月 プロパティベース・テストを習得する 著者:Johannes Link 無数の値を使ってコードをテストする方法   Arquillian:簡単なJakarta EEテスト 著者:Josh Juneau Arquillianフレームワークを使ってJakarta EEアプリケーションをテストする方法   ArchUnitでアーキテクチ...

もしもみなみんがDBをクラウドでうごかしてみたら 第16回 サービス制限について

もしもみなみんがDBをクラウドでうごかしてみたら 連載Indexページ ※本記事は2019/12/15時点のものになります みなさん、こんにちは。 先日、Oracle Cloud InfrastructureでもExadata X8の利用が可能になりました! Release Note  X8 Shapes for Exadata DB Systems Exadata Cloud Service(以降ExaCS)をはじめ、Databaseサービスを利用しようとしている方に「ExaCSのX8を利用したいんですが、すぐ作成可能ですか?」「作成しようとしたけれど、シェイプが選択できない/表示されないんです」「ExaCSやBare Metalなどを誤って作成してしまって高額請求が発生しまうようなことを防ぐ方法はありますか?」といったことをよく聞かれます。 これらに関係するのが、サービス制限というサービスごとの利用数の制限設定です。今回は、そのサービス制限について解説します。 サービス制限とは サービス制限は、利用者保護を目的としたサービスごとのリソース使用量の制限になります。たとえば、 ・ サービスの単価を認識せずに作成したら、単価の高いサービスだった ・ 部門やプロジェクト全体での利用など、利用者多い状況で一度にサービスを利用したら、意図せず利用量/数が大きくなっていた といった、利用者が意図せず高額な請求をう受け取ってしまうことがないように、すべての環境(テナンシ)にデフォルトでサービスごとに利用できるリソース数を制限しています。 そのため、制限数以上の数に達した状態で新たにサービスを追加しようとすると、エラーもしくは使用したいシェイプが選択できずに作成ができません。制限数以上の作成をしたい場合には、サービス制限の引上げをリクエストすることで増やすことができます。このように、デフォルトで制限数を設けておくことによって、意図せず大幅な利用(リソース的にも金額的にも)をすることを防ぐようにしています。例えば、ExaCSの場合は全シェイプでデフォルトは0に設定されています。そのため、サービス制限で制限されているリソース数を増やす、つまりサービス制限の引上げがまずは必要になります。例えば、Exadata Cloud Serviceの場合、サービス制限がデフォルトは0となっているのでサービス制限で制限されているリソース数を増やす、つまりサービス制限の引上げがまずは必要になります。その他のサービスも、現在利用しているサービス数がサービス制限数に達している状態で新たにリソースを使う場合には、同様です。 また、サービス制限とは別に、コンパートメントごとの割り当て設定も可能です。2つの違いは、サービス制限はテナント全体に対しての制限で、制限数の変更はオラクルが行います。一方コンパートメント割当の制限は、テナント管理者がそのテナント内のコンパートメントに対して、IAMポリシーを利用して設定します。なので、最初に必要なのはテナントのサービス制限を確認することです。 マニュアル OCI Document Service > Service Essentials > Service Limits  英語 / 日本語  サービス制限の確認方法 環境内のサービスごとのサービス制限の内容は、コンソールの『ガバナンス』 >『制限、割当ておよび使用状況』 から確認可能です。(この情報を見ることのことのできるユーザーは、管理者グループに属するか、アクセス権限(Tenancyのinspect limits)をIAMポリシーで設定する必要があります)   Tokyo Regionの場合 サービス制限 : 利用可能なリソース数 使用量 : 現在利用しているリソース数 使用可能 : 作成可能なリソース数 (=(1)-(2))  (3)が0の場合、サービスを作成しようとするとエラー、もしくは作成時に選択ができません。 その場合、サービス制限の引上げをリクエストして(1)の数を増やすようにしましょう! また、デフォルトの制限に関してはマニュアル(英語 / 日本語) から確認可能なので、クラウド・アカウントをアクティベーションしてすぐ使い始めたいという人は事前にマニュアルで確認してみてください。 この画面に関してよくある質問 質問「全リソースの制限が0になっているのですが、全てにサービス制限がかかってしまったのでしょうか」 → 全リソースの制限が0になっている場合、そのテナント自体が利用停止している状態を示します。その場合は、サービス制限の引上げリクエストではなく、テナントの利用について問い合わせてください。 質問 「サービスでDatabaseを選択したのに、Autonomous Databaseしか表示されていないように見えるのですが、一部のサービスしか表示されていないのはなぜですか」 → Autonomous Databaseのサービス情報しか出ていないのは、スコープでリージョンを選択されているためです。Database Cloud Service(Virtual Machine/Bare Metal/Exadata)を表示させたい場合は、スコープでアベイラビリティ・ドメイン(AD)を選択してください。これはサービスの属性に依るものです。Autonomous Databaseはリージョン・リソースで、Database Cloud Service(Virtual Machine/Bare Metal/Exadata)はADリソースになります。そのため、[スコープ]の選択リストでリージョンを選択するか、ADを選択するかで表示されるサービスが変わるようになっています。 Databaseサービスの中に絞ると、 ・リージョン(例:東京の場合はap-tokyo-1)を選択 : Autonomous Databaseのみ ・AD(例:AP-TOKYO-1-AD-1)を選択 : Database (Virtual Machine、Bare Metal、Exadata) が表示されます。   サービス制限の引上げ方法 サービス制限の確認画面にある、『サービス制限の引上げ』をクリックするとリクエストを入力する画面に移ります。   連絡先 (名前とメールアドレス) : リクエスト内容についての自動送信メール(通知)や、内容について確認が必要な場合はメール(英語)が来る可能性があります リソース制限の引上げ : サービス・カテゴリ、リソース、可用性ドメインごとの引上げ後の制限値 リクエストの理由 以上を記入したら、『リクエストの送信』をクリックして完了です。利用者保護を目的として内容が確認されたうえで承認されることから数日要する可能性があるので、あらかじめ利用し始めたいタイミングが決まっていれば、前もってリクエストしておくことをお勧めします。 この画面に関してよくある質問 質問「ExaCS X7のサービス制限を引き上げたのですが、新しくでたX8を利用できますか」 → サービス制限はサービスのシェイプなど種類毎に設定されているので、X8を利用したい場合にはX8のシェイプ名を指定してサービス制限の引上げをしてください。   まとめ Oracle Cloud Infrastructureでは高性能や専有型といった単価が比較的高めのサービスも多く、テナント内での利用リソース数/量が大きくなるような利用も想定していることから、エンタープライズ領域での利用も意識したこのような仕組みがあるのですね。例えば、Exadataba Cloud Serviceの場合は、対象のテナントにおいて、Monthly Flexでサービス制限の引上げ対象のサービスの最低料金以上をご購入いただいているか、という点もリクエストの承認の際に見られています。これも、「後から高額な請求が発生しないように」という目的があります。そういったチェックをすることで、未然に料金周りのトラブルを防ぎ、安心してお使いいただけるようにしています。 「すぐにxxサービスを利用開始したい」「xx月xx日から利用開始したい」という場合には、まずはこのサービス制限の値を確認してください。そして事前に希望の数まで利用可能な状態にしておくことで、希望されるタイミングからすぐにご利用いただけばと思います。   関連リンク ・Oracle Cloud Infrastructure ドキュメント サービス制限 英語/日本語 もしもみなみんがDBをクラウドでうごかしてみたら 連載Indexページ

もしもみなみんがDBをクラウドでうごかしてみたら 連載Indexページ ※本記事は2019/12/15時点のものになります みなさん、こんにちは。 先日、Oracle Cloud InfrastructureでもExadata X8の利用が可能になりました! Release Note  X8 Shapes for Exadata DB Systems Exadata...

Oracle CloudとGhostで無料ブログを簡単開設

オラクルは9月に、Oracle Cloudの新しいプラン、「Always Free」を発表しました。これで開発者や学生は、Oracle Cloudを完全に無料で使ってみることができます。Oracle Cloudを支持する開発者かつエバンジェリストである私は、このプランの熱烈なファンです。というのも、私は当社のクラウド・プラットフォームに全幅の信頼を寄せており、多くの開発者がOracle Cloudを体験するチャンスを手にすれば、その使いやすさを体感し、自社のクラウドへのニーズを満たすために間違いなくOracle Cloudを選択するであろうことを知っているからです。私はこのところ、新しい無料プランの使い道をいくつか紹介してきました。この記事を読んだ後は、私の他の記事もチェックして、無料プランをすぐに使ってみてください! Blast Off To The Cloud: Free Team Chat With Rocket.Chat In The Oracle Cloud Install & Run Discourse For Free In The Oracle Cloud Installing Node-RED In An Always Free VM On Oracle Cloud How To Setup And Run A Free Minecraft Server In The Cloud 本日の記事では、"Always Free" VMを1つ作成し、インターネット・アクセスができるように構成し、Docker(コンテナ管理用)、Ghost(Node.JSで記述された無料のブログ/CMSプラットフォーム。オープン・ソース)、Caddy Serverをインストールして、リバース・プロキシとして動作させ、TLS証明書を自動で管理し、新しいブログでHTTPS暗号化を使用できるようにします。複雑な手順はありません。この後のチュートリアルに従えば、15分であなたのブログもオンラインになるでしょう。 この後の手順は以下のようになっています。VMの作成方法をご存じの場合や、すでに作成している場合は、必要に応じて手順を飛ばしてください。 Always Free VMの作成 Ghostをインストールする前に Dockerのインストール Ghostのインストール Caddyのインストール Ghostの構成 Always Free VMの作成 Oracle Cloudを初めて使う場合は、まず完全無料のアカウントにサインアップします。クレジット・カードを登録する必要がありますが、「Always Free」サービスを使い続けている限り、料金を請求されることは絶対にありません。無料アカウントを作成したらログインして、Oracle Cloudダッシュボードを開きます。このような画面です。 さあ、VMを作成しましょう。「Create a VM instance」をクリックしてください。 インスタンスに名前を付け、必要に応じてイメージ・ソースを変更します。この後のインストラクションはデフォルトOS(Oracle Linux)用です。デフォルトのままにしておくのがいいかもしれません。 必要に応じて、「Show Shape, Network, Storage Options」をクリックし、可用性ドメインとインスタンス・タイプの両方が'Always Free Eligible'であることを確認してください。 インスタンスのシェイプも同じです。「Always Free Eligible」オプションを選択してください。 「Assign a public IP address」にチェックを入れておかないと、Webを通してVMにアクセスできません。 次に、公開鍵ファイルを選択します。このファイルには関連付けられた秘密鍵があり、VMの作成後、VMへのアクセスに使用されます。 「Create」をクリックすると、インスタンスの詳細ページに移動します。VMのステータスは'Provisioning'になっています。 少し待つと、インスタンスは'Available'になります。VMに割り当てられているパブリックIPアドレスをコピーします。このアドレスは、チュートリアルを進めていくなかで必要になります。 これでVMの準備ができました。VMの作成時にアップロードした公開鍵に関連付けられている秘密鍵を使用して、マシンにSSH接続します。 Ghostをインストールする前に Ghostをインストールする前に、いくつかの確認事項があります。この手順を省略すると、インストールできません。 ドメイン名レコード・セット まずは、VMのパブリックIPアドレスを、ドメイン名に関連付けます。Caddyでリバース・プロキシを作成し、無料でそのまま使用できるHTTPSを取得します。これはLet’s Encryptを使用して、通信用のSSLを自動で保護してくれます。私の場合は、ghost.toddrsharp.comというURLを使用するため、AレコードをDNSホストで追加し、私のVMのIPアドレスを指定します。 ドメイン(またはサブドメイン)にVMのIPアドレスを指定するには、ご使用のホスティング・プロバイダの指示に従ってください。これで、VMにSSH接続し、先に進む準備ができました。 ファイアウォールとセキュリティ・リストの構成 ファイアウォールとセキュリティ・リストでいくつかのポートを開いて、GhostアプリケーションをWebに公開する必要があります。まず、Oracle Cloudのダッシュボードで、VMのセキュリティ・リストに受信ルールを追加します。VMの詳細ページで、サブネットをクリックします。 サブネットの詳細ページで、「Security Lists」をクリックします。 デフォルトのセキュリティ・リストをクリックして、ルールを編集します。 「Add Ingress Rule」をクリックし、 'Source CIDR' 0.0.0.0/0(すべてのIPアドレス)にポート80,443を開くルールを入力します。 Dockerのインストール ここで、インスタンスにSSH接続し、インストール・プロセスを開始します。接続したら、sudo yum update -yを実行して、すべてを最新の状態にします。次に、Dockerをインストールします。   yum-config-manager --enable ol7_addons   yum install docker-engine       systemctl start docker     systemctl enable docker   view raw install-docker.sh hosted with ❤ by GitHub   次の手順に進む前に、以下のようにして、root以外のユーザーがDockerコマンドを実行できるようにします。   groupadd docker   service docker restart   usermod -a -G docker opc view raw enable-non-root.sh hosted with ❤ by GitHub   重要:opcユーザーがsudoを使わずにDockerコマンドを実行できるようにするには、ログアウトしてからログインし直す必要があります。 必要であれば、こちらを実行してDockerインストールを確認できます。 docker run hello-world Ghostのインストール VMにディレクトリを作成します。これは、ブログ関係の構成を保存したり、コンテナ・データの永続保存用にDockerコンテナにマッピングしたりするのに使用します。 mkdir /home/opc/ghost これでGhostをインストールできます。以下のコマンドを実行するだけです。   docker run -d \     --restart always \     --name ghost-blog \     -v /home/opc/ghost/content:/var/lib/ghost/content:z \     -p 2368:2368 \     -e url=https://ghost.toddrsharp.com \     ghost view raw install-ghost.sh hosted with ❤ by GitHub   ここでは、さまざまな引数を使ってdocker runを呼び出し、Docker Hubからghostイメージを実行しています(必要に応じて、run コマンドは実行前にイメージをpullします)。--restart alwaysを使うと、コンテナの終了時、またはDockerの再起動時(VMのリブートを含む)に、コンテナが毎回再起動するため、自分でサービスを作成する必要がありません。もちろんサービスを作成することもできますが、このアプリケーションではこのフラグがうまく機能します。コンテナの自動での起動について詳しく知りたい場合は、Dockerのドキュメントを参照してください。ここでは、VMの/home/opc/ghost/contentドライブを、Dockerコンテナの/var/lib/ghost/contentにマッピングしています。これで、コンテナが再起動しても、コンテンツとコンテナのSQLiteデータベースは保持されます。また、Ghostが実行されるポートであるポート2368を公開しています。コンテナがpullされて実行されたら、Caddyをインストールできます。途中でうまくいかなくなった場合、またはGhost Dockerコンテナの実行で問題が発生した場合は、Docker Hubのドキュメントを参照してください。 Caddyのインストール 先に進む前に、VMのポート80と443で、ファイアウォール・ポートを開く必要があります。以下のようにします。   sudo firewall-cmd --permanent --zone=public --add-port=80/tcp   sudo firewall-cmd --permanent --zone=public --add-port=443/tcp   sudo firewall-cmd —reload view raw firewall.sh hosted with ❤ by GitHub   Caddyをインストールするには、再びDockerを使用します。今回も1つのコマンドで完了します。ただし、そのコマンドを実行する前に、/home/opc/ghost/CaddyfileでCaddyの構成ファイルを作成し、vimまたはnanoで編集します。このように編集して、URLを、先ほどVMに指定したドメイン名に変更します。   https://your.domain.com {       proxy / ghost-blog:2368 {           transparent       }   } view raw Caddyfile hosted with ❤ by GitHub   このファイルによって、Caddyはドメインのリバース・プロキシとして動作し、すべてのトラフィックをhttp://ghost-blog:2368にリダイレクトします。さあ、Caddyを実行してみましょう。   docker run -d \     --restart always      --link ghost-blog:ghost-blog \     --name caddy \     -p 80:80 \     -p 443:443 \     -v /home/opc/ghost/Caddyfile:/etc/Caddyfile:z \     -v /home/opc/.caddy:/root/.caddy:z \     abiosoft/caddy view raw install-caddy.sh hosted with ❤ by GitHub   --linkフラグを使用して、Ghostコンテナに接続し、2つのコンテナ間でセキュアなトンネルを作成して、/etc/hostsファイルにエントリを追加し、ghost-blogをGhostコンテナのIPにマッピングします。VMボリュームをマウントしてCaddyfileを渡し、/home/opc/.caddyをマウントします。これで、CaddyがVMにTLS証明書を格納できるようになり、イメージが起動するたびに新しい証明書が生成されることがなくなります。このコマンドを実行すると、正しいTLS証明書が使われて、ドメインでブログが有効になります! Ghostの構成 構成したドメインでブログにアクセスし、URLの末尾に/ghostを追加して管理セクションにアクセスし、アカウントを作成し、構成を完了します。 アカウントを作成してログインすると、ブログをカスタマイズして、コンテンツを作成できるようになります!私のブログhttps://ghost.toddrsharp.comをご覧いただき、ご自分のブログではGhostを使ってどんなことができるか、参考にしてみてください。 Photo by Ante Hamersmit on Unsplash   ※本記事は、Todd Sharp (Developer Advocate)による”Stand Up A Free Blog In 15 Minutes With Ghost In The Oracle Cloud“を翻訳したものです。   AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

オラクルは9月に、Oracle Cloudの新しいプラン、「Always Free」を発表しました。これで開発者や学生は、Oracle Cloudを完全に無料で使ってみることができます。Oracle Cloudを支持する開発者かつエバンジェリストである私は、このプランの熱烈なファンです。というのも、私は当社のクラウド・プラットフォームに全幅の信頼を寄せており、多くの開発者がOracle Cloudを...

データの安全性を維持する - パート(4): クラウド・データベースの監査

寄稿者:Database Security、Senior Director、Ashok Swaminathan  Oracleデータベースは一般的には、きわめて機密性の高い情報が含まれる重要な資産となっています。そのため、データベースのアクティビティを定期的に監視して、データベース・アカウントが侵害されていないこと、および権限付きユーザーがアクセスしてはならないデータにアクセスしていないことを確認し、重要なデータにアクセスしようとする悪意のある操作を突き止め、調査する必要があります。この記事では、これらの問題への対処が可能となる、Data Safeの監査機能に焦点を当てて説明します。    Data Safe Activity Auditingを利用すれば、Oracle Cloudのデータベース上のユーザー・アクティビティを監視し、(業界や規制によるコンプライアンス要件に従って)監査レコードを収集、保持して、異常なアクティビティについてアラートをトリガーすることができます。機密データの変更、管理者やユーザーのアクティビティや、その他Center for Internet Security(CIS:米国インターネット・セキュリティー・センター)によって推奨されているアクティビティについて監査できます。データベース・パラメータや監査ポリシーが変更されたとき、管理者によるログインが失敗したとき、ユーザーのエンタイトルメントが変更されたとき、あるいはユーザーが作成または削除されたときのアラートを設定できます。Oracle Databaseには事前定義ポリシーが多数用意されており、そのいずれもData Safeで数回クリックするだけで有効化できます。  Data Safeダッシュボード(図1)ではアクティビティの傾向をすぐに確認できますが、ここにアラートの情報も含まれています。 このダッシュボードから、監査証跡(監査データを探すべきデータベース内の場所をData Safeに指定するもの)のステータスのチェックや、全体的な監査アクティビティの確認も可能です。 図1:Data Safe User Activity Auditingダッシュボード Data SafeのActivity Auditingの設定は、簡単な3つの手順で実行できます。  1.    監査するターゲットの選択 2.    収集する監査情報を示した監査ポリシーのプロビジョニング 3.    監査情報をどこから収集するかをData Safeに指定するための監査証跡の作成  この設定の完了後、Data Safeにより自動的に監査データが収集され、そのデータがセキュアなData Safeリポジトリに保存されます(このリポジトリは削除や変更ができないように、監査対象のデータベースとは分離されています)。Data Safe Activity Auditingでは、事前定義アラートに基づいて重要なイベントに関するアラートを設定できます。インタラクティブなレポートで監査データを確認し、必要に応じてフィルタを適用できます。また、セキュリティやコンプライアンスのニーズに合わせて、レポートを計画的に作成できます。  数種類のアクティビティ監査レポートが用意されています(図2)。たとえば、収集されたイベントやアラートのサマリー、監査対象のすべてのアクティビティ、監査ポリシーの変更、管理者のアクティビティ、ログイン・アクティビティ、データベース問合せ操作、DDL、DML、ユーザーおよびエンタイトルメントの変更に関するレポートがあります。生成されたアラートの表示、アラートへのフィルタの適用、アラートの検索も可能です。アラート・レポート、監査データ・レポートのいずれもカスタマイズして保存でき、PDF形式やXLS形式でダウンロードすることもできます。 図2:Admin Activityレポート Data Safeの監査機能は使いやすく、数回のクリックで有効化できます。Oracle Cloudでデータベースを運用していて、まだData Safeを利用されていない方には、このサービスを構成してデータベースの監査を最優先で行うことをお勧めします。 Data Safeはお使いのデータベース・サービスに含まれており、追加費用はかかりません。データをクラウド内で保護するための最高のツールの1つとなります。 Data Safeがユーザーやデータをクラウド内で保護する方法についての詳細情報は、このブログの以前の記事であるData Safe:Five Ways to Help Protect Your Digital AssetsおよびData SafeのWebページをご覧ください。   本記事は、Phil March (SR. Principal Product Marketing Director) による”Keeping your Data Safe Part 4 — Auditing your Cloud Databases“を翻訳したものです。   AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

寄稿者:Database Security、Senior Director、Ashok Swaminathan  Oracleデータベースは一般的には、きわめて機密性の高い情報が含まれる重要な資産となっています。そのため、データベースのアクティビティを定期的に監視して、データベース・アカウントが侵害されていないこと、および権限付きユーザーがアクセスしてはならないデータにアクセスしていないことを確認し、...

Oracle Cloud Notifications サービスを使ってみよう

クラウドの好きな機能をリストとしてまとめると、多くの開発者の"トップ10"リストに通知が入っていることはおそらくないでしょう。通知はどちらかというと"ユーティリティ"機能で、自動車のタイヤのようなもの。必要不可欠で、動かなければイライラさせられますが、順調に動いていれば考えることもほぼありません。 かつて私は通知をこのように捉えていましたが、最近になってオラクルのサービスOracle Notification Serviceを掘り下げるようになってからは変わりました。不思議なことに、このサービスについて学び色々と試すことにワクワクしている自分がいました。Oracle Notification Serviceは、Oracle Cloudの他のサービスと同じく、本当に使いやすく、分かりやすいように実装されています。また、Oracle Cloudの他のサービスだけでなく、外部のツールやサービスとも非常にスムーズに連携します。  ここでは、そんなOracle Notification Serviceについて詳しく見ていきます。 通知は広い概念を含む言葉であるため、その意味を明確にしましょう。アプリケーションで何かが起きたときに、ユーザーに電子メールを送信することがあります。たとえば、ファイルや注文の処理が終わったときに。 これが通知となる可能性があります。また、開発者やDevOpsエンジニアであれば、インフラストラクチャ内で何か変更があったときに、そのことを知りたいと思うのではないでしょうか。たとえば、DBのバックアップが開始した、完了したなど。 これも通知となる可能性があります。ユーザーや開発者が関わらない通知もあります。あるサーバーレス・ファンクションがあって、オブジェクトがObject Storageにアップロードされたときにこのファンクションを実行する必要がある場合に、その操作を通知によって処理できるのです。このように多種多様なアクティビティが"通知"という総称で表されますが、Oracle Notification Serviceは思い付く限りのすべてのシナリオに対処できます。  この記事で取り上げる内容は次のとおりです。 通知トピックの作成 トピックへのサブスクライブ 通知を受信するSlackアプリの作成 Oracle Cloud Infrastructure Java SDKによる通知の送信 Cloudのイベント経由での通知の自動送信 サービス・アラーム経由での通知の自動送信 Zapierによる通知からのGitHubイシューの自動作成 話題は盛りだくさんですので、すぐに1つ目に移りましょう! 通知トピックの作成 通知を使い始めるには、まずトピックを作成する必要があります。Oracle Cloudコンソールから、「Application Integration」→「Notifications」を選択します。 次に、「Create Topic」をクリックします。 トピック名と説明を入力して、「Create Topic」をクリックします。 これで、トピックのサブスクリプションのための準備が整いました。 トピックへのサブスクライブ 通知のサブスクリプションのために利用できるプロトコルはいくつかあります。 電子メール PagerDuty HTTPS(カスタムURL) Slack ヒント:この記事ではサブスクリプションとしての電子メールについては説明しませんが、電子メールのサブスクリプションを利用すれば、携帯電話の"非公開の組込み"電子メール・アドレスを使ってSMS通知を受け取ることができます。 ほとんどの通信会社でこの機能がサポートされています。便利な機能ですので、ぜひ試してみてください。 このブログ記事では、これらのプロトコルの一部について見ていきます。まずはSlackです。最初に、新しく作成したトピックをトピック・リストから選択します。 「Create Subscription」を作成します。 プロトコルとして「Slack」を選択します。このSlackサブスクリプションにはWebフックURLが必要になるため、このウィンドウを開いたままこのブログ記事の次のセクションに移り、新しいSlackアプリケーションを作成してWebフックURLを取得してください。 通知を受信するSlackアプリの作成 通知をSlackチャネルにパブリッシュするには、Slackアプリケーションを作成する必要があります。 まず、Slackを開いて「Create an App」をクリックし、アプリの名前を指定し、アプリを作成するワークスペースを選択して、「Create App」をクリックします。  次に、「Incoming Webhooks」をクリックします。 Webフックはデフォルトで無効であるため、有効にします。 「Add New Webhook to Workspace」をクリックします。 ワークスペースにアクセスするための権限を確認し、ポスト先のチャネルを選択して、「Allow」をクリックします。 これで新しく作成したWebフックURLを取得できます。このURLは少し後の手順で必要になります。 通知のポスト先のSlackチャネルを開き、歯車アイコンのメニューから「Add an app」をクリックします。 または、チャネル内で直接「Add an app」をクリックします。 新しいアプリを検索し、選択します。 チャネル内で確認メッセージが表示されます。 コンソールに戻り、Slack WebフックURLを貼り付けてサブスクリプション・ダイアログの入力を完了します。  この時点で、サブスクリプション確認用メッセージがこのSlackチャネルにポストされます。 このメッセージ内のリンクをクリックして、サブスクリプションを確認します。 次に、このSlackサブスクリプションをテストします。Oracle Cloudコンソールのトピック詳細ページに戻り、「Publish Message」をクリックします。 簡単なメッセージを入力し、「Publish」をクリックします。 Slackチャネルを開き、そのメッセージがポストされたことを確認します。 これで、Oracle Notification ServiceのトピックにサブスクライブできるSlackアプリの作成が完了しました。 Oracle Cloud Infrastructure Java SDKによる通知の送信 この記事ではすでに、かなり多くのことを学びました。通知トピックを設定し、そのトピックにサブスクライブし、トピックから通知を受信するためのカスタムのSlackアプリを作成し、簡単なテスト・メッセージをパブリッシュしました。しかし、すでに説明したように、アプリケーションからトピックやサブスクライバに通知を送信する必要があることも多いため、ここではトピックにメッセージをパブリッシュする小さなJavaアプリケーションについて見ていきます。トピック詳細ページからトピックのOCIDを取得する必要があります。このOCIDをコピーして、いつでも使える状態にします。 このデモの実行に必要なコード全体をGitHubで公開していますので、後でご自由にこのリポジトリを確認してください。 私はGradleが好きなので、まずはbuild.gradleファイルを作成して、Oracle Cloud Infrastructure Java SDKを依存先として含めます。 plugins {     id 'java'     id 'application' } group 'codes.recursive' version '0.1-SNAPSHOT' sourceCompatibility = 1.8 repositories {     mavenCentral() } application {     mainClassName = 'codes.recursive.OnsSendExample' } dependencies {     compile group: 'com.oracle.oci.sdk', name: 'oci-java-sdk-full', version:'1.9.0'     testCompile group: 'junit', name: 'junit', version:'4.12' } tasks.withType(JavaExec) {     systemProperties System.properties } view raw build.gradle hosted with ❤ by GitHub IDEでRun/Debugプロファイルを作成し、Oracle Notification ServiceのトピックOCIDを環境変数として設定します。 Ons.javaというクラスを作成します。このクラスを、SDKクライアントを呼び出してメッセージをパブリッシュするために利用します。このクラスには、引数としてtitleとmessageを受け取るsendNotfication()というメソッドが1つ含まれます。認証プロバイダを作成し、利用するプロファイルの名前を渡します(この例ではパスを指定していないため、デフォルトのOracle Cloud Infrastructure設定ファイルの場所[/.oci/config]が設定ファイル自体として利用されます)。次に、NotificationDataPlaneClientとMessageDetailsオブジェクトを作成します。このオブジェクトにタイトル(title)とメッセージ(message)が格納されます。  その後、MessageDetailsインスタンスを格納したPublishMessageRequestを作成し、最後にクライアント(client)にPublishMessageRequestを渡すことでメッセージをパブリッシュします。 この説明からは面倒で複雑だと感じられるかもしれませんが、以下のコードを見れば簡単だとお分かりいただけるはずです。 package codes.recursive; import com.oracle.bmc.auth.ConfigFileAuthenticationDetailsProvider; import com.oracle.bmc.ons.NotificationDataPlaneClient; import com.oracle.bmc.ons.model.MessageDetails; import com.oracle.bmc.ons.requests.PublishMessageRequest; public class Ons {     public void sendNotification(String title, String message) throws Exception {         String topicId = System.getenv("TOPIC_ID");         if( topicId == null ) {             throw new Exception("Please set a TOPIC_ID environment variable!");         }         ConfigFileAuthenticationDetailsProvider provider =  new ConfigFileAuthenticationDetailsProvider("DEFAULT");         NotificationDataPlaneClient client = NotificationDataPlaneClient.builder().region("us-phoenix-1")                 .build(provider);         MessageDetails messageDetails = MessageDetails.builder().title(title).body(message).build();         PublishMessageRequest publishMessageRequest = PublishMessageRequest.builder()                 .messageDetails( messageDetails )                 .topicId(topicId)                 .build();         client.publishMessage( publishMessageRequest );     } } view raw Ons.java hosted with ❤ by GitHub 次に、OnsSendExample.javaという必要最小限のメイン・クラスを作成し、このクラス内でOnsクラスのインスタンスを作成して通知を送信します。 package codes.recursive; import java.util.Date; public class OnsSendExample {     public static void main(String... args) throws Exception {         Ons ons = new Ons();         ons.sendNotification(                 "Test from Java",                 "This is a test notification sent by the Java SDK at " + new Date().toString()         );     } } view raw OnsSendExample.java hosted with ❤ by GitHub Slackチャネルをチェックして、配信されたことを確認できます。 Cloudのイベント経由での通知の自動送信 Cloudのイベントについては以前にこのブログで取り上げましたが、当時の背景情報は異なりますし、学び直すことは良いことですので、Cloudのイベント経由での通知の送信についても詳しく見ていきましょう。 そもそも、Cloudのイベントとはどういったものでしょうか。 多くのサービスはOracle Cloudで発行されるイベントであり、それらのイベントはCNCF Cloud Event仕様に従って構造化されたメッセージです。作成、読取り、更新、または削除(CRUD)の操作、リソースのライフサイクルの状態変更、あるいはリソースに影響を及ぼすシステム・イベントなどがイベントに該当します。  たとえば、バックアップの完了時または失敗時、あるいは Object Storage バケット内のファイルの追加時、更新時、または削除時にイベントが発行されます。 以下のように、Cloudのイベントを生成するさまざまなOCIサービスが存在します。 ブロック・ボリューム コンピュート データベース ネットワーク 通知 Object Storage サービスごとに使いやすいイベント・タイプが多数用意されているため、インフラストラクチャを監視するための大きな助けになります。例として、自律型データベースのイベント・タイプを見てみましょう。 バックアップ作成開始(Create Backup Begin) バックアップ作成終了(Create Backup End) インスタンス作成開始(Create Instance Begin) インスタンス作成終了(Create Instance End) リストア開始(Restore Begin) リストア終了(Restore End) さらに、ブロードキャストされるイベント・タイプ一式が存在するのは自律型データベースだけではありません。以下のように、Oracle Cloudのありとあらゆるデータベース関連要素にそれ独自のイベント・タイプが用意されています。 自律型データベース 自律型コンテナ・データベース 自律型Exadataインフラストラクチャ・インスタンス Exadataインフラストラクチャ VMクラスタ・ネットワーク VMクラスタ バックアップ先 データベース・ノード データベース・ホーム データベース Cloudのイベントを利用するには、ルールを作成します。ルールには、ルールがトリガーされる基になる特定のリソースや属性を指定するためのフィルタを含めることができます。さらに、ルールの条件が満たされたときに実行すべきアクションも作成します。 現時点では、ファンクション(Oracle Functionのサーバーレス・ファンクションを呼び出す)、ストリーミング(Oracle Streaming Serviceのストリームに対するメッセージを生成する)、通知(Oracle Notification Serviceトピックにイベントをパブリッシュする)の3つのタイプのアクションから選択できます。この3つ目のアクションについて、これから説明していきます。それでは、ルールを作成してみましょう。 Oracle Cloudコンソールのサイドバー・メニューで、「Application Integration」→「Events Service」を選択します。 次に、ルール・リストのページで、「Create Rule」を作成します。 名前と説明を入力します。 次に、このルールにフィルタを追加し、Object Storageサービスのイベント、特にObject Createイベントのみに制限するようにします。さらに、特定のバケットのみにフィルタを制限します。 次に、ルールがトリガーされたときに実行するアクションを定義します。この例では、Oracle Notification Serviceトピックを呼び出しましょう。 この時点でルールを保存してテストできます。テストするには、オブジェクトをObject Storageバケットにアップロードします。Slackチャネルにまったく新しいメッセージが送信されます。このメッセージは先ほど確認したものとは少し異なり、Cloudのイベント全体がJSON形式の文字列で表されていますが、このメッセージには、この通知からアクションを実行する必要がある場合に利用できる有用な情報が大量に含まれています。 サービス・アラーム経由での通知の自動送信 アラームはOracle Cloud内のリソースやインフラストラクチャを監視し続けるための非常に優れた手段です。アラームの作成は本当に簡単で、アラームが指定したしきい値に達すると、Oracle Notification Serviceに通知をパブリッシュできます。  ここでは、Object Storageバケットが1分に10回を超えるGetリクエストを受信した場合に通知をパブリッシュするアラームを作成してみましょう。 ただし、これはサンプルとしては不自然なものになっています。多くのサービスには便利なメトリックが用意されていて、それらを利用すればMonitoringサービスで継続的に監視できるのですから。 それでは、デモのアラームを作成してテストしてみます。コンソールのサイドバー・メニューで、「Monitoring」→「Alarm Definitions」を選択します。 次に、「Create Alarm」をクリックします。 名前を付け、重大性を選択し、アラーム・メッセージの本文を定義します。 次に、このアラーム用に評価されるメトリックを定義します。名前空間'oci_objectstorage'を選択し(他にも多数のオプションがあります)、メトリックに'GetRequests'を選択し、時間隔として1分、統計として'count'を選択します。ディメンション名として'resourceDisplayName'を追加し、特定のバケットをディメンション値として選択して、特定のObject Storageバケットだけになるようにこのメトリックをフィルタします。さらに、トリガー・ルールを'greater than'、値を1、トリガー間隔を1分とします。 これらの指定によって、1分間で1つを超えるGetリクエストが存在する場合にアラームがトリガーされます。 最後に、下にスクロールして通知の詳細を指定し、「Save alarm」をクリックします。 テストするには、指定したバケット内に保存されている画像に対して、何回か'GET'リクエストを実行します。最初のリクエストの後にアラームがトリガーされ、先ほどと同じようにSlackチャネルにメッセージがポストされます。 Zapierによる通知からのGitHubイシューの自動作成 記事の最後に、外部との統合の例を示そうと思っていましたが、今回は上記の例よりも少し"現実に近い"アプリケーションを取り上げることにします。この例では、Zapierによって作成されるHTTPS(カスタムURL)エンドポイントを使ってトピックにサブスクリプションを追加します。Zapierは、定められたトリガーに基づいて定められたアクションを実行する"Zap"を作成するためのプラットフォームであり、その考え方はIFTTT("if this then that")に似ています。 ここでは、Zapier Webフックをトリガー("これが起きたとき"というアクション)として作成し、GitHubを宛先として利用します("これをする"というアクション)。ここまでは大丈夫でしょうか?では、まず"Zap"を作成しましょう。'アプリ'として「Webhooks by Zapier」を選択し、トリガー・イベントとして「Catch Raw Hook」を選択します。 この設定によって、カスタムのWebフックURLが表示されます。この情報は後で必要になります。 次に、このZapのステップ2で、'アプリ'として「GitHub」を選択し、アクション・イベントとして「Create Issue」を選択します。 詳細情報として、プロジェクトのリポジトリ、イシューのタイトル、イシューの本文(この例ではOracle Notification Serviceからのメッセージ本文そのもの)を入力します。 保存し、この新しいWebフック用のサブスクリプションを作成します。 作成された新しいGitHubイシューを表示して、このサブスクリプションの動作を確認します。 有効にし、Oracle Cloudコンソールからメッセージをパブリッシュしてテストします。 CloudのイベントのJSONを解析することもできます。そのためには、一時的にZapのJavaScriptコードを利用して、その後GitHubイシューを作成して、整形されたチケットを生成します(さらに、特定のイベントタイプに絞り込むためのフィルタを追加するといったことも可能です)。 Zapierでは他にも、Jiraイシューの作成、SMSアラートの送信、Twitter統合など、実に多くの追加の統合機能を利用できます。  まとめ 私が通知を使い始めた当初はやや面白みがないと感じていました。しかしすぐに、通知が開発を容易にしてアプリケーションをよりインテリジェントにする大きな可能性を秘めていると分かりました。この記事の情報量が多いことは承知しており、 おそらく2~3つの記事に分割できたでしょうが、このような形でまとめたまま公開すべきものだと感じた次第です。この記事をぜひブックマークして、今後の参考資料としてお役立てください。ご質問については、以下のコメント欄からどうぞ。 お知らせ: この記事で使ったコードはGitHubでも公開されています。ぜひご覧ください。  https://github.com/recursivecodes/ons-demo Photo by AbsolutVision on Unsplash   ※本記事は、Todd Sharp (Developer Advocate)による”Complete Developers Guide To The Oracle Notification Service“を翻訳したものです。   AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

クラウドの好きな機能をリストとしてまとめると、多くの開発者の"トップ10"リストに通知が入っていることはおそらくないでしょう。通知はどちらかというと"ユーティリティ"機能で、自動車のタイヤのようなもの。必要不可欠で、動かなければイライラさせられますが、順調に動いていれば考えることもほぼありません。 かつて私は通知をこのように捉えていましたが、最近になってオラクルのサービスOracle...

全国のOTNおすすめ技術者向けセミナー&イベント(2019年12月)

12/5 一歩進んだ分析でビジネスにチカラを!! ~あなたもデータ アナリスト~ 本セミナーでは、Oracle Cloud を活用して、部門や社員が自ら一歩進んだ分析を行い、ビジネス上のインサイト(洞察)を獲得する方法を体験して頂きます。操作 PC をご用意しています。この機会にぜひご参加ください。 12/10 Oracle Cloud Infrastructure ハンズオン 「Oracle Cloud Infrastructure」は、オンプレミスからの大規模ワークロード移行に完全対応する次世代インフラ基盤です。本セミナーでは、Oracle Cloud Infrastructureのサービス概要のご紹介とともに、実際のクラウド環境を利用したハンズオンを半日で体感いただけます。 12/19 実践Kubernetesハンズオン ~OKEでKubernetesを体験しよう~ Oracle Cloudは大規模なコンテナの管理、デプロイおよび運用に適したクラウドサービスを複数提供しています。本ハンズオンセミナーではOracle Cloudが提供するコンテナ・サービスを実際に利用しKubernetes環境の構築からコンテナ・アプリケーションのデプロイ、CI/CDまでの一連の流れを体感いただけます。 AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。          

12/5 一歩進んだ分析でビジネスにチカラを!! ~あなたもデータ アナリスト~ 本セミナーでは、Oracle Cloud を活用して、部門や社員が自ら一歩進んだ分析を行い、ビジネス上のインサイト(洞察)を獲得する方法を体験して頂きます。操作 PC をご用意しています。この機会にぜひご参加ください。 12/10 Oracle Cloud Infrastructure ハンズオン 「Oracle...

もしもみなみんがDBをクラウドで動かしてみたら 第15回 Autonomous Databaseの自動スケーリングを設定してみよう

もしもみなみんがDBをクラウドでうごかしてみたら indexページ ▶︎▶︎ ※本記事は2019/11/20時点のものになります みなさん、こんにちは。 今回は、第13回で紹介したAutonomous DatabaseのOCPUスケール・アップ/ダウンを自動で行ってくれる、自動スケーリング機能について紹介したいと思います!   Autonomous Databaseの自動スケーリング機能とは Autonomous Databaseの自動スケーリング機能は、負荷状況に応じてOCPUリソースを自動でアップ/ダウンしてくれる機能です。 ・負荷状況に応じて、OCPU数とI/O帯域が変動 ・有効にしているOCPU数の最大3倍(*1)まで自動で即座に増減 ・インスタンス再起動やコネクション切断なく動的に実施 ・課金は1時時間あたりのOCPU利用状況に応じて決定   (*1) Autonomous Database Serverlessの最大OCPU数は128 OCPUなので、3倍の数が128を超える場合は最大128まで 手動で実行する場合との違いはあるの? 自動スケーリングによるスケール・アップ/ダウンした場合は、OCPU数に応じて設定される各種設定はそのままの設定で動き続けます。具体的には、メモリサイズや事前定義済の接続サービスで設定されているパラレル実行数や同時実行セッション数等の設定などは、有効にしているベースのOCPU数に基づいた設定が利用されます。 事前定義済のサービスについてはこちら : Autonomous Databaseの接続サービスとシェアについて   設定方法 Autonomous Databaseを新規で作成する際に、そのインスタンスで自動スケーリング機能を有効にするかどうかを指定します。後からの変更も可能です。 新規作成時の設定 自動スケーリングを有効にする場合には、『自動スケーリング』にチェックをいれてインスタンスを作成します 設定情報は、サービス詳細ページの『Autonomous Database 情報』から確認できます。 設定の変更方法 コンソール(WebUI)やREST APIなどで設定変更が可能です。設定の変更も、オンライン(インスタンス再起動なし)で実施されます。 ・コンソール サービス詳細ページの上部の『スケール・アップ/ダウン』をクリック 『自動スケーリング』のチェック有無で有効化/無効化を切り替えられます。切り替えはオンラインで行われるので、インスタンスの再起動はありません。   ・OCI CLI #OCI CLIのセットアップは完了している前提ですすめますので、まだこれからという方は下記をご参考にセットアップしてみて下さい ・マニュアル Oracle Cloud Infrastructure Documentation > コマンド・ライン・インターフェース > クイックスタート ・Oracle Cloud 公式ブログ コマンドライン(CLI)でOCIを操作する – Oracle Cloud Infrastructureアドバンスド OCI CLIで操作する際に対象リソースの識別子としてインスタンスのOCIDの情報が必要になるので、事前に確認しておきましょう。 設定状況は、oci db autonomous-database get でインスタンスの情報を出力することで確認可能です。 $ oci db autonomous-database get --autonomous-database-id <Autonomous Databaseインスタンスのocid> 例 $ oci db autonomous-database get --autonomous-database-id xxxx --query 'data.{"1.display-name":"display-name","2.cpu-core-count":"cpu-core-count","3.is-auto-scaling-enabled":"is-auto-scaling-enabled"}' {   "1.display-name": "ATPEM",    "2.cpu-core-count": 2,    "3.is-auto-scaling-enabled": false } 変更は、oci db autonomous-database update で --is-auto-scaling-enabled の設定をtrueもしくはfalseに更新することで設定変更されます。 $ oci db autonomous-database update --autonomous-database-id <Autonomous Databaseインスタンスのocid> --is-auto-scaling-enabled [true/false] 例 $ oci db autonomous-database update --autonomous-database-id xxxx --is-auto-scaling-enabled true .... $ oci db autonomous-database get --autonomous-database-id xxxx --query 'data.{"1.display-name":"display-name","2.cpu-core-count":"cpu-core-count","3.is-auto-scaling-enabled":"is-auto-scaling-enabled"}' {   "1.display-name": "ATPEM",    "2.cpu-core-count": 2,    "3.is-auto-scaling-enabled": true } ・ マニュアル OCI CLI Command Reference DB > autonomous-database > update     自動スケーリング機能を使ってみよう 実際に自動スケーリングを使った場合と使わない場合で負荷をかけて、どのようになるかを違いをみてみました 本検証の内容と設定 ・ 利用サービス :Autonomous Transaction Processing (ADWでも可) ・ OCPU数 : 2  ・ CPUボトルネックになる処理を並列実行 ・ 接続サービスはLOWを利用 ・ 自動スケーリングを有効/無効した環境でのCPU使用率や実行数などを確認 テストデータや利用したSQLは第13回同様、しばちょう先生の連載を参考にしていますのでぜひご参考までに。 しばちょう先生の試して納得!DBAへの道 第53回 SQLパフォーマンスの高速化の限界を目指せ!(1)   結果 Autonomous Databaseのサービス・コンソールから確認できるアクティビティ情報の各グラフを利用して、解説していきます。(平均値が表示されているグラフなので左右で全く同じグラフにはなりません) 左側が自動スケーリングが無効なインスタンスで、右側が有効にしているインスタンスです。09:59頃から処理を流し始め、10:03頃からCPU使用率が高くなっています。 まずはCPU使用率からみてみましょう。 無効化しているインスタンスは、処理数を増やしたところからずっとCPU使用率が100%で張り付き、リソースが逼迫している状態で動き続けています。対して有効化しているインスタンスは処理数を増やしたところで一気にCPU使用率が上昇しますが、スケール・アップされたため利用可能なコア数が増えことから、100%にはならずにリソースに少し余裕がある状況で実行されていますね。(もちろん負荷によっては3倍のリソースでも不足することもあるので、スケール・アップしたとしてもリソース枯渇する可能性はあります) 次に、Database Activityの情報を見てみます。 無効化しているインスタンスは、処理数を増やしたところからグレーの層(Scheduler)が出てきていますね。これは待機している処理/セッションがある状態を示しています。対して有効化しているインスタンスは、処理数が増えてCPU使用率が上昇したことから自動的にコア(OCPU)が増やされたため、処理に対して割り当てられるコアが増え、待機せずに処理が動いていることがわかるかと思います。 その結果、無効化の場合には22分かかった処理が、有効化にした場合には7分で完了しました。 さて、最後に課金がどのようになったのか見てみます。こちらもサービス・コンソールの画面から確認できるOCPU数のグラフ(1時間単位)です。今回、下記のグラフの矢印のあたりが自動スケール・アップされた時間帯ですが、、、あれ?OCPU数が2のまま?!お得?! 課金に関しては、ベースのOCPU数もしくは最大OCPU数 x 平均CPU使用率のどちらか大きい方になります。今回はスケールアップされたのは数分のみだったこともあり、上記計算式で課金対象のOCPU数はスケール・アップされたOCPU数ではなくベースの有効にしている2のほうが大きくなったので課金も2になったようですね。もちろん、計算式で最大OCPU数 x 平均CPU使用率の方が大きくなれば結果は変わるのでご注意ください。 ※課金の部分に関しては2019/11時点の情報であり利用状況によって異なりますので、あくまで参考情報として見てください。   まとめ 自動スケーリングを実際に利用してみて、CPU使用率が上昇し割り当て済のリソースよりも多くのリソースが必要となる状態において、処理実行中においても影響なく自動でコアが増え(スケール・アップ)、それにより処理が遅延せずに実行されたことがわかりました。 負荷状況に応じて自動でスケール・アップ/ダウンされる場合、課金面や実行中のトランザクションへの影響について気になる人も多いと思います。実行中のトランザクションの影響に関しても、インスタンスの再起動なく行われ、実際に高負荷な状況になっている際に勝手にリソースが増えていたので、実行中の処理に影響なくリソースが割り当てられて即座に利用できるというのは助かりますね。課金に関しては、ベースのOCPU数もしくは最大OCPU数 x 平均CPU使用率のどちらか大きい方。1時間あたりの最大値ではなく実際の利用状況に応じた決定になるというのはいい点ですね。     関連リンク ・Oracle Cloud Infrastructure ドキュメント Autonomous Database 英語/日本語 ・Autonomous Transaction Processing マニュアル 英語/日本語 ・Autonomous Data Warehouse マニュアル 英語/日本語 ・Release Note(英語) Auto scaling Autonomous Databases  ・Autonomous Database サービス・アップデート 日本語 ・Autonomous Database 技術詳細資料 日本語   もしもみなみんがDBをクラウドでうごかしてみたら indexページ ▶︎▶︎

もしもみなみんがDBをクラウドでうごかしてみたら indexページ ▶︎▶︎ ※本記事は2019/11/20時点のものになります みなさん、こんにちは。 今回は、第13回で紹介したAutonomous DatabaseのOCPUスケール・アップ/ダウンを自動で行ってくれる、自動スケーリング機能について紹介したいと思います!   Autonomous Databaseの自動スケーリング機能とは Autonomou...

データの安全性を維持する - パート(3):クラウド・データベースの評価

Russ Lowenthal Senior Director この記事は同時掲載記事です。オリジナル記事はこちらをご覧ください データベースのセキュリティを確保するための最初のステップは、データベースの現在の状態を把握することです。それには、データベースの構成方法、ユーザーの詳細、システムに格納されるデータの種類を知る必要があります。その一助となるのがOracle Data Safeです。データベースの構成の分析、データベース・ユーザーのリスク調査、データベース内に存在する機密データの種類やその保存されているデータの容量の分析を簡単に実行できます。 この記事では、Data Safeの評価機能に焦点を当てて説明します。なお、機密データの検出機能については後日取り上げます。Data Safeの評価には、「セキュリティ」と「ユーザー」の2種類があります。                      セキュリティ評価は、構成、セキュリティ制御の利用状況、およびユーザーの管理方法(権限、ロール付与を含む)を調査するものです。セキュリティ評価を利用することで、環境に対して不必要なリスクをもたらす可能性のある構成を特定できます。脆弱なパスワード・ポリシー、機密データベース・オブジェクトへの不必要なアクセス、アクセス制御の非適用などが当てはまります。セキュリティ評価結果のそれぞれで、調査で判明した内容の詳細、それが重要である理由、および(適宜)CIS、STIG、EU GDPRなどの該当するセキュリティ・フレームワークへの参照が示されます。以下の画像は調査結果の一例です。この例では、Datapump_EXP_FULL_DATABASEロールが複数のユーザーに付与されていて、そのロールに伴ってEXEMPT REDACTION POLICY権限が間接的に付与されています。この調査結果は助言的な性質のものであり、このロールや権限が付与されたユーザーに対してOracle Data Redactionのポリシーの効果が消失していることが分かるだけのものになっています。                      ユーザー評価はデータベース・アカウントに焦点を当てて、それらのアカウントのシステムに対するリスクのレベルを詳細に分析します。つまり、ユーザーのアカウントが侵害された場合、その侵害によってどの程度のダメージが発生し得るか、ということです。以下の画面から、ユーザーが誰であるかを確認し、あるユーザーを掘り下げて、その作成者、アカウントのステータス、最終ログオン日時、付与されているロールと権限を確認できます。また、パスワードの最終変更日時を確認し、「View Activity」をクリックして、そのユーザーがデータベース内で実行した操作まで掘り下げることもできます。このData Safeの機能は特に注目に値します。Oracleが製品を問わずこの種のビューを提供するのは初めてだからです。データベース侵害の最大の原因がアカウント侵害であることは、おそらく皆さんお気づきでしょう。だからこそ、侵害されたアカウントの立場からリスクへのアプローチを開始する必要があることは一理あります。Oracleは現在、ユーザー・アカウント内のリスク評価に役立つ機能を強化しており、Data Safeのこの分野も今後1年で急速に成長する見込みです。                      Oracle Cloudでデータベースを運用していて、まだData Safeを利用されていない方には、このサービスを構成してデータベースの評価を最優先で行うことをお勧めします。Data Safeはお使いのデータベース・サービスに含まれており、追加費用はかかりません。データをクラウド内で保護するための最高のツールの1つとなります。 Data Safeがユーザーやデータをクラウド内で保護する方法についての詳細情報は、Data Safeのホワイト・ペーパーか、新登場のデータベース・セキュリティEブック(第3版)のData Safeに関する新しい章をご覧ください。また、まだご覧でない場合は、Data Safeを紹介する全5回にわたるブログ記事シリーズのパート1、パート2をお読みください。   ※本記事は、Russ Lowenthal (Senior Director) による”Keeping your Data Safe, Part (3): Assessing Cloud Databases“を翻訳したものです。   AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

Russ Lowenthal Senior Director この記事は同時掲載記事です。オリジナル記事はこちらをご覧ください データベースのセキュリティを確保するための最初のステップは、データベースの現在の状態を把握することです。それには、データベースの構成方法、ユーザーの詳細、システムに格納されるデータの種類を知る必要があります。その一助となるのがOracle Data Safeです。データベー...

GraalVM によるOracle Cloud Infrastructure Monitoringサービスのパフォーマンス改善

Esteban Ginez 技術スタッフ主要メンバー GraalVMは汎用の仮想マシンであり、あらゆるプログラミング言語向けに高いパフォーマンスと完全な相互運用性を発揮するように作られています。 Oracle Cloud Infrastructureの多くのチームが、自チームのサービスをGraalVMイメージ上で運用することでパフォーマンスが向上したことを確認しています。Oracle Cloud InfrastructureのMonitoringサービスは先日GraalVMへの移行を完了し、現在は本番環境で運用されています。 MonitoringはOracle Cloud Infrastructure内部の基本サービスです。内部の全チームが、担当するサービスの健全性を監視するためにこのサービスを利用しています。Monitoringはメモリを大量に消費するアプリケーションで、Java Native Interface(JNI)呼び出しを非常によく利用します。Monitoringサービスはアプリケーションに対して、ホストやアプリケーションのメトリックの収集と操作、アラーム生成、通知のためのREST APIを提供しています。このサービスは、Oracle Cloud Infrastructureのすべてのサービスを起点とする数千万のデータ・ポイントを常時処理しています。また、Oracle Cloud Infrastructureのどこからでも利用でき、数十億件のメトリックを取り込んで数百万件のリクエストを処理しています。   GraalVMによる改善効果 GraalVM Enterprise Edition version 19.1コンパイラの最適化によってオブジェクトの割当て件数が減少し、全体的な実行スピードが改善しました。その結果、ガベージ・コレクションによる一時停止回数が減り、より少ない処理能力でワークロードを実行できるようになりました。Monitoringサービスが消費するCPUは全体で5 %減少し、さらにスループットが向上し、ガベージ・コレクションやその他のシステム・アクティビティにかかる時間も大幅に短縮されました。それぞれについて、以降のセクションで説明します。   ガベージ・コレクションの処理時間の短縮 Java 8 update 212と比較して、Monitoringサービスのガベージ・コレクションの処理時間は25 %少なく、アプリケーションの一時停止時間も17 %少なくなりました。アプリケーションの一時停止時間の減少について、以下のグラフに示します。   スループットの向上 Monitoringサービスに対するGraalVMの最適化によって、以下のグラフのとおり、Java 8 update 212と比較して1秒あたりトランザクション件数が10 %増加しました。   移行 MonitoringサービスのGraalVMへの移行プロセスはシンプルで透過的に行われました。サービスのコードとJVM構成を変更することなく、切り替えを実行できました。 結論として、幅広いケースやさまざまな負荷状況下で、GraalVMはJava 8 update 212よりも高いパフォーマンスを発揮します。Monitoringサービスはそのメリットを得られた格好の例と言えます。 Oracle Cloud InfrastructureはGraalVM Enterprise Editionを無償で提供しています。ぜひ実際にお試しいただき、Javaワークロードのパフォーマンス向上を体験してください。   ※本記事は、Esteban Ginez (PRINCIPAL MEMBER OF TECHNICAL STAFF) による”GraalVM Powers Oracle Cloud Infrastructure“を翻訳したものです。   AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

Esteban Ginez 技術スタッフ主要メンバー GraalVMは汎用の仮想マシンであり、あらゆるプログラミング言語向けに高いパフォーマンスと完全な相互運用性を発揮するように作られています。 Oracle Cloud Infrastructureの多くのチームが、自チームのサービスをGraalVMイメージ上で運用することでパフォーマンスが向上したことを確認しています。Oracle Cloud In...

Oracle Autonomous Data Warehouse アーキテクチャと戦略:Part3(全3回)

Bill Kleyman Switch、Digital Solutions、EVP | 業界インフルエンサー   3ブログ・シリーズのパート3:世界初、世界で唯一の自己保護型データベース・クラウド・サービス   ITやセキュリティの担当者は、データ侵害について考えただけで肝を冷やしますが、それにはもっともな理由があります。私たちは、データ侵害のコストが金銭的なものにとどまらないことを知っているのです。データ損失の影響は、ブランド、お客様、パートナーシップなど、さまざまなものに及びます。そしてデータをクラウドで管理するようになると、セキュリティ対策はいっそう複雑になります。 オラクルによる最近のセキュリティ・レポートによれば、クラウドとテナントの「Shared Responsibility Security Model」(責任共有セキュリティ・モデル:SRSM)にまつわる混乱が、多大なコストを発生させているとのことです。今年の調査に参加した企業のうち3分の1以上が、そのような混乱が原因でマルウェアに攻撃されたと答えています(34%)。またほぼ同じ割合の回答者(32%)が、監査リスクが増大したと答えました。 責任共有セキュリティ・モデルへの理解が不足しているため、データもリスクにさらされており、結果として権限のない人がデータにアクセスするという事例を30%の企業が経験していました。さらに29%の回答者が、混乱が生じた結果、パッチ未適用または構成を誤ったシステムが侵害されたと答えました。このことから、パブリック接続を使用しているクラウド・インフラストラクチャは、適切に構成されていないパブリック・サービスを狙うボットネットの攻撃を常に受けていることがよく分かります。 御社のクラウド環境は、セキュリティを念頭に置いて設計されている場合のみ、セキュリティが確保されているということを忘れないでください。たとえば最近の調査によれば、全S3サーバーのうちの7%が認証なしに外部から完全にアクセス可能であり、35%は暗号化されていないということです。過去6か月ほどの間に発生したインシデントから推測すれば(Risk Based Securityの最近の調査によると、2019年の前半だけで、3,813件のデータ侵害が報告され、41億件以上のレコードが流出したとのこと)、それらは決して価値の低いデータを格納していたわけではないはずです。   先に進む前に、3回連載のOracle Autonomous Data Warehouseのブログ・シリーズのパート1とパート2を読んでおくことをお勧めします。しかし、そんなことよりセキュリティについて今すぐに知りたいというのであれば、それもやむを得ないでしょう――セキュリティは重要で、急を要するトピックですから。 Oracle Database Securityのシニア・バイス・プレジデントであるVipin Samarはこのように述べています。「データは最も重要な資産ですが、適切に保護されていない場合は、非常に大きな重荷になります」。それでは、Oracle Autonomous Data Warehouseというソリューションを利用すると、他にはないどのようなメリットがあるのでしょうか。私の見たところでは、セキュリティ面が優れているようです。アーキテクチャ全体のDNAに、セキュリティが組み込まれているのです。説明しましょう。 Oracle Autonomous Data Warehouseは、すべてのデータを暗号化して保存します。承認されたユーザーとアプリケーションのみが、データベースへの接続時にデータにアクセスできます。それ以降、Autonomous Data Warehouseへのすべての接続では、証明書ベースの認証とSecure Sockets Layer(SSL)暗号化が使用されます。つまり、Autonomous Data Warehouseへの許可のないアクセスは発生せず、クライアントとサーバーとの間の通信は完全に暗号化され、妨害や改竄は不可能であるということになります。したがって、悪意ある攻撃(中間者攻撃など)が発生した場合でも、完全に暗号化された通信が傍受されることはなく、Autonomous Data Warehouseは安全に稼働し続けます。 優れた点は他にもあります。データやデータベースへの接続を暗号化するのに、手動による構成は一切必要ありません。Autonomous Data Warehouseがあなたの代わりにやってくれるからです――まさに自律的に。なぜそれが重要なのでしょうか。クラウド・プロバイダーの中には、ストレージ・リポジトリやバケットを実際には暗号化しないところもあるからです。前述のように、セキュリティ企業Skyhigh Networksによれば、すべてのS3バケットのうち、35%は暗号化されていません。そして、このようなセキュリティの欠如はすでに、大手企業に影響を与えています。 Autonomous Data Warehouseは自律的に通信を暗号化するだけではなく、Oracle Cloudのセキュリティ標準に基づいて、すべてのユーザーに強力なパスワードの複雑さのルールを適用しています。まさかと思うかもしれませんが、パスワード・ポリシーについては、今でも多くの企業が問題を抱えています。そのため、ユーザーがパスワードをもっと頻繁に変更していれば、またはもっと複雑なパスワードにしていれば防げたかもしれないデータ侵害が発生しているのです。強力なパスワードの複雑さのルールを適用していれば、御社の最も重要なデータ・ポイントが、厳しいセキュリティ・ポリシーから外れることはありません。 さらに制限を厳しくするには、ネットワーク・アクセス制御リスト(ACL)を指定します。ネットワークACLを指定することで、特定のAutonomous Data WarehouseデータベースのみがACLにあるアドレスからの接続を受け入れ、他のクライアント接続はすべて拒否されます。つまり、悪意のあるアクセス試行やなりすまし攻撃は失敗します。ネットワーク・アクセス制御リストでは、ADWデータベースにアクセスできるデバイスを細かく指定できます。 Oracle Autonomous Data Warehouseには、セキュリティのベスト・プラクティスをお客様のデータに実装する以外にも、他にはない特長があります。お客様のデータウェアハウスを自動で保護するのです。これがどんなにすばらしいかと問われれば、非常にすばらしいと私は答えます。   世界初、世界で唯一の自己保護が可能な自律型ウェアハウス これについては、Autonomous Data Warehouseブログ・シリーズのパート1とパート2で詳しく取り上げています。しかし、このサービスがユーザーのために実行する、強力な自律型プロセスが多数あることに触れておくのは重要なことです。 Oracle Autonomous Data Warehouseが自己稼働型であるというのは、ネットワーク構成、ストレージ、データベースのパッチ適用およびアップグレードをお客様に代わって行う、完全に管理されたデータウェアハウス・クラウド・サービスであるという意味です。お客様側ではDBAは必要ありません。 Oracle Autonomous Data Warehouseは自己修復型でもあります。すべてのコンポーネントは高可用性を念頭に置いて設計されており、バックアップは完全に自動化されています。つまり、このアーキテクチャは停止時間に対する保護を備えており、その保護は設計の中心に組み込まれています。データベースを稼働させ続けるためにデータ・プラットフォームがアクティブに働いてくれているのを知れば、あなたも夜や週末の時間を自由に使えるようになるでしょう。 Oracle Autonomous Data Warehouseは自己保護型です。 この種のデータベースとしては最初の自己保護型自動ウェアハウス・データベースですが、自己保護はOracle Cloudインフラストラクチャとデータベース・サービスのセキュリティから始まっています。Oracle Cloudインフラストラクチャの一部であるAutonomous Data Warehouseエコシステムの中では、セキュリティ・パッチは必要に応じて自動で適用されるため、脆弱性の存在する期間が短くなり、パッチが適用されていないシステムが抱えるリスクを軽減できます。 さらに、パッチ適用はスタック全体、つまりファームウェア、オペレーティング・システム(OS)、クラスタウェア、データベースを対象とします。お客様側で必要な手順はありません。パッチ・リリースを手動で追跡したり、スタックのさまざまなレイヤーで複数のパッチを追跡したりした日々はもう過去のものです。まさに「自己保護型」という言葉がぴったりです。 Oracle Autonomous Data Warehouseの自己保護型サービスは、データベースを含めたインフラストラクチャのセキュリティの状態を管理します。すべての処理が自動で行われ、ヒューマン・エラーの入り込む余地はありません。このエコシステムではここから、送受信中も、保存中も、バックアップされている間も、お客様のデータは常に暗号化されます。暗号化鍵は自動で管理され、ここでもお客様の介入は一切必要ありません。また、市場に出ている一部のデータ・ソリューションとは異なり、暗号化をオフにすることはできません。デフォルトでオンになっています。これほどまでにデータ侵害が蔓延している今の時代に、御社の大事なデータを暗号化せずにいていいはずがありません。 最後に、Oracle Autonomous Data Warehouse Cloudの管理作業は、ログに記録されて集められ、異常なアクティビティがないかどうか監視されます。そうです、ご想像の通り、Autonomous Data Warehouseサービスが異常な動作や異常なユーザー・アクセスをスキャンして、評価します。つまり、Autonomous Data Warehouseは定義済みのポリシーを使用してデータベース監査を行うため、お客様は何らかの異常のアクセスがあった場合にログを確認できます。 Autonomous Data Warehouseによる事前予防的かつインテリジェントな保護があるとはいえ、お客様はデプロイしているワークロードとデータに対して、セキュリティのベスト・プラクティスが適用されるように引き続き努めなければなりません。Oracle Database Securityのシニア・バイス・プレジデントであるVipin Samarはこのように述べています。「クラウドでのデータベースの保護は、共有責任です。オラクルがインフラストラクチャとネットワークを保護し、OSとネットワークの動作を監視し、OSとデータベースにパッチおよび更新を適用し、暗号化、適切な責任の分散、さまざまな認証を処理します」。 Samarはさらに続けます。「お客様企業は引き続き、アプリケーション、ユーザー、データを保護していく必要があります。そのためには、自社を標的とする攻撃をアプリケーションが阻止できるようにし、自社のユーザーがセキュリティのベスト・プラクティスに従い、ふさわしい管理によって機密データが保護されている状態を保つ必要があります。ある意味では、こうした要件は企業が現在利用しているオンプレミス・データベースの場合と同じであり、異なるのはセキュリティに関するインフラストラクチャの部分をオラクルがすでに引き受けているということだけです」。 自動で保護、自律的にインテリジェント 昨今の脅威を拡散させている媒体の規模、スピード、破壊力を考えると、当面の間、ビジネス・リーダーは心の安まるひまがなく、テクノロジーも停滞してはいられないでしょう。しかし、Oracle Autonomous Data Warehouseソリューションの一部である自動化されたセキュリティ・テクノロジーと、クラウドベースのID管理により、企業はリスクを管理できるようになります。 データとインフラストラクチャへの攻撃は、さまざまな形を取って行われます。国家を含む悪意ある攻撃者、APT攻撃、組織的犯罪、そして意図的ではない(または何らかの不満を抱いてなされる)内部の人間による脅威はすべて、御社のビジネスにも大きく関係しています。御社のインフラストラクチャ、オペレーティング・システム、アプリケーション、ユーザー、そしてもちろんデータベースが標的になる可能性があるのです。 データセットの価値がいよいよ増している今、いったん足を止めて、データベースについて十分に理解し、自社がどのようにデータを活用しているかを把握しましょう。 信じられないかもしれませんが、データなくしては何も進まない今の世の中で、自社のデータベースがどれほど安全なのか、機密データはどこに保存されているのか、実際にどれほどの量のデータを保有しているのかといったことを把握していない企業が多数あるのです。御社がそうであるなら、データの海を自分たちだけで泳いでいこうとはしないでください。 たとえばオラクルは先般、Oracle Autonomous Databaseの機能であるOracle Database Security Assessment Toolをリリースしました。このツールを使用すれば、先ほど挙げたような質問に答えられるようになります。このツールはさまざまなセキュリティ構成パラメータを確認して、不足している点を特定し、必要なセキュリティ・パッチを探します。そして暗号化、監査、アクセス制御などのセキュリティ対策が施されているかを確認し、ベスト・プラクティスと照らし合わせます。 このAssessment Toolで、自社の機密データはどこに格納されているか、どれほどのデータがあるのかを確認できます。Oracle Database Security Assessment Toolは個人を特定する情報、仕事のデータ、健康状態に関するデータ、財務データ、情報技術に関するデータなど、50種類以上の機密データについて、データベースのメタデータを検索します。そうしたデータのセキュリティ上のリスクを把握するためです。 また、この評価ツールは、検索結果に注目させたり、推奨事項を提示したりする機能があるため、グローバル企業の規制遵守に役立ちます。検索結果や推奨事項は、欧州連合の一般データ保護規則(EU GDPR)とCenter for Internet Security(CIS)ベンチマークの双方に対応しています。 御社のデータ(と評判)を守りたいのであれば、データ・セキュリティへの第一歩として、問題解決につながる質問に対する答えを考え、現在のデータの使用方法を把握し、スマートで自律したソリューションを活用することで、データの管理方法とデジタル・マーケットへのアプローチの方法を刷新することをお勧めします。覚えていてほしいのですが、まず取りかかるべきなのは、自社のデータ要件を十分に理解することです。つまり、以下の質問に答えられるようになってください。 データ量は増えているのか。管理が複雑になっているか。 セキュリティに関して「恐怖」を感じたことがあり、ポリシーの改善が必要とされているか。 現在使用しているデータ・システムには、インテリジェンスが全般的に不足していないか。 データ分析を適切に利用できていないために、競争上の優位性を失っていないか。 データを可視化できる優れたソリューションを使用しているか。 データの使用場所を増やしたり分散させたりしようとしているか。 ふさわしい種類のデータ駆動型アーキテクチャを見極めるのに役立つ質問は、他にもたくさんあります。Oracle Autonomous Data Warehouseがあれば、この難題に取り組むときに、当て推量で進むのを避けられます。自己稼働型、自己修復型、そして自己保護型であるという特長はすべて、御社がデータウェアハウスを最大限に活用できるようにするための設計です。 私が最初の投稿で書いたように、データは御社の業務にとって不可欠なものです。セキュリティも同じです。セキュリティは非常に重要であり、手抜きをする余地などありません。何よりも、時代遅れのアーキテクチャに足を引っ張られることのないように気をつけてください。環境が複雑化し、断片化が進むと、管理が難しくなるだけではなく、セキュリティのリスクが増大します。実際に、データ侵害の発生事例のうち85%は、すでに入手可能であったパッチが適用されていれば防げたかもしれないものです。Oracle Autonomous Data Warehouseのようなソリューションと、それを支える自己保護型アーキテクチャがあれば、そうした種類の脅威を排除し、本当に価値のあるもの、つまりユーザー、ビジネス、データに注意を集中させることができます。 Photo by Steven Su on Unsplash   ※本記事は、Bill Kleyman(EVP of Digital Solutions, Switch | Industry Influencer) による”Oracle Autonomous Data Warehouse: The world’s first and only self-securing database cloud service“を翻訳したものです。   AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

Bill Kleyman Switch、Digital Solutions、EVP | 業界インフルエンサー   3ブログ・シリーズのパート3:世界初、世界で唯一の自己保護型データベース・クラウド・サービス   ITやセキュリティの担当者は、データ侵害について考えただけで肝を冷やしますが、それにはもっともな理由があります。私たちは、データ侵害のコストが金銭的なものにとどまらないことを知っているのです。デー...

Database

基本からわかる!高性能×高可用性データベースシステムの作り方 第14回 AWRレポート作成とAWRスナップショット取得(PDB単位)

基本からわかる!高性能×高可用性データベースシステムの作り方 indexページ 第13回ではCDB全体のAWRレポートの作成とAWRスナップショットの取得に関するコマンドラインでの操作について説明しました。今回はPDB単位でのAWRについてです。Oracle Database 12c Release 2からはPDB単位でもAWRレポートを作成できるようになっています。CDB全体とは異なり、PDB単位のAWRスナップショット取得はデフォルトでは有効になっていません。 PDB単位のAWRスナップショット自動取得の有効化 CDB全体のAWRスナップショット取得はCREATE DATABASEした時点でデフォルトで有効になっています。CDB全体で作成したAWRレポートにはすべてのPDBのアクティビティが混在して記載されます。しかし、PDB単位のAWRスナップショットの自動取得はデフォルトでは無効になっています。 PDB単位のAWRスナップショット自動取得を有効にするには初期化パラメータAWR_PDB_AUTOFLUSH_ENABLEDをTRUEに設定します。この設定には2階層あって、CDB$ROOTで設定するとすべてのPDBで有効になります。個別のPDBで設定するとそのPDBでのみ有効になります。 SQL> SHOW PDBS     CON_ID CON_NAME                       OPEN MODE  RESTRICTED ---------- ------------------------------ ---------- ----------          2 PDB$SEED                       READ ONLY  NO          3 SIPDB19A1                      READ WRITE NO          4 SIPDB19A2                      READ WRITE NO SQL> ALTER SESSION SET CONTAINER=SIPDB19A1; セッションが変更されました。 SQL> ALTER SYSTEM SET AWR_PDB_AUTOFLUSH_ENABLED = TRUE; システムが変更されました。 SQL> SHOW PARAMETERS AWR_PDB_AUTOFLUSH_ENABLED NAME                                 TYPE                              VALUE ------------------------------------ --------------------------------- ------------------------------ awr_pdb_autoflush_enabled            boolean                           TRUE PDBごとのAWRスナップショットの取得間隔と保存期間の設定はPDBごとに設定でき、CDB全体の場合と同じくDBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGSプロシージャを使用します。各PDB上で実行し、設定単位は分です。以下の例は取得間隔(interval)を10分、保存期間(retention)を44640分(=60分×24時間×31日)に設定しています。 SQL> EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (interval=>10,retention=>44640); PL/SQLプロシージャが正常に完了しました。 設定の確認はAWR_PDB_WR_CONTROLビューを見ます。 SQL> SELECT CON_ID,SNAP_INTERVAL,RETENTION FROM AWR_PDB_WR_CONTROL;     CON_ID SNAP_INTERVAL        RETENTION ---------- -------------------- --------------------          3 +00000 00:10:00.0    +00031 00:00:00.0 PDB単位でのAWRスナップショットの手動取得もCDB全体の場合と同じくDBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOTプロシージャまたはファンクションを実行します。個別のPDB上で実行するとそのPDBのAWRスナップショットが作成されます。ファンクションをSELECT文で実行するとAWRスナップショットIDが返されるのはCDB全体の場合と同じです。PDBごとのAWRスナップショットIDはAWR_PDB_SNAPSHOTビューで調べることができます。 SQL> SELECT DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT() FROM DUAL; DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT() ------------------------------------------                                         14 SQL> SELECT MAX(SNAP_ID) FROM AWR_PDB_SNAPSHOT; MAX(SNAP_ID) ------------           14 PDB単位でのAWRスナップショットIDはPDBごとに独立したシーケンスです。CDB全体のスナップショットIDとも異なります。 PDB単位のAWRレポートの作成コマンド PDB単位のAWRレポートの作成にはsqlplusでOracleインスタンスに接続し、該当のPDBにログインしてAWRレポート作成のSQLスクリプトを実行します。CDB全体の場合と異なるのは個別のPDB上でSQLスクリプトを実行するというところです。 AWRレポートはHTMLもしくはテキスト形式のファイルとして出力されますが、そのファイルはsqlplusを起動したカレント・ディレクトリに作成されるため、ファイルを出力させたいディレクトリに移動してからsqlplusを起動します。管理者権限でログインします。 $ sqlplus / as sysdba SQL> ALTER SESSION SET CONTAINER=SIPDB19A1; セッションが変更されました。 AWRレポート作成のSQLスクリプトもCDB全体の場合と同じで、もっとも基本的なものがawrrpt.sqlです。awrrpt.sqlはログインしたデータベースのDBIDとOracleインスタンスでのAWRスナップショットからAWRレポートを作成します。CDB全体の場合と異なり、途中でPDB単位のレポートを作成するかが問われます。 sqlplusは@マークを付けたテキストファイルを読み取りそこに記述されているSQLスクリプトを実行します。awrrpt.sqlは$ORACLE_HOME/rdbms/admin/ディレクトリにあります。sqlplusは”?”の記号をORACLE_HOMEのディレクトリと解釈するため以下のように記述できます。 SQL> @?/rdbms/admin/awrrpt awrrpt.sqlを実行するとまず出力するファイル形式を問われます。デフォルトはHTML形式です。 Specify the Report Type ~~~~~~~~~~~~~~~~~~~~~~~ AWR reports can be generated in the following formats.  Please enter the name of the format at the prompt.  Default value is 'html'. 'html'          HTML format (default) 'text'          Text format 'active-html'   Includes Performance Hub active report report_typeに値を入力してください: 旧   1: select 'Type Specified: ',lower(nvl('&&report_type','html')) report_type from dual 新   1: select 'Type Specified: ',lower(nvl('','html')) report_type from dual Type Specified:                                  html ファイル形式はtextではなくデフォルトのhtmlをお勧めします。text形式はコピー&ペーストして報告書の作成などには便利ですが、長いSQL文が途中で省略されてしまいます。HTML形式はSQLが全文出力されます。「AWRレポートを提供してください」と言われたときは(デフォルトの)HTML形式のことだと思っておくとよいでしょう。 次にPDB単位のレポートを作成するかが問われます。PDB単位のレポートを作成するのでAWR_PDBを指定します。 Specify the location of AWR Data ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AWR_ROOT - Use AWR data from root (default) AWR_PDB - Use AWR data from PDB awr_locationに値を入力してください: AWR_PDB Location of AWR Data Specified: AWR_PDB 次はDBIDとOracleインスタンスの指定です。awrrpt.sqlの場合はこれらが今接続しているOracleインスタンスに決め打ちです。 Current Instance ~~~~~~~~~~~~~~~~ DB Id          DB Name        Inst Num       Instance       Container Name -------------- -------------- -------------- -------------- --------------  4081308537     SIDB19A                     1 sidb19a        SIPDB19A1 Root DB Id      Container DB Id AWR DB Id --------------- --------------- ---------------    4140346382      4081308537      4081308537 Instances in this Workload Repository schema ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   DB Id      Inst Num   DB Name      Instance     Host ------------ ---------- ---------    ----------   ------   4081308537     1      SIDB19A      sidb19a      jphppt07.jp. Using 4081308537 for database Id Using          1 for instance number 次に入力するnum_daysは何日前のAWRスナップショットまでさかのぼってリストに出すかです。何も入力せずにreturnを押すと記録が残っているすべてのAWRスナップショットがリストされます。以下の例では直近の1日分を出すために1と指定しています。 Specify the number of days of snapshots to choose from ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Entering the number of days (n) will result in the most recent (n) days of snapshots being listed.  Pressing <return> without specifying a number lists all completed snapshots. num_daysに値を入力してください: 1 Listing the last day's Completed Snapshots Instance     DB Name      Snap Id       Snap Started    Snap Level ------------ ------------ ---------- ------------------ ---------- sidb19a      SIDB19A              7  13 11月 2019 13:49   1                                   8  13 11月 2019 13:53   1 num_daysを入力するとAWRスナップショットを取得した時刻とそのSnap Idが列挙されます。2つのSnap Idを指定した間のAWRレポートが作成されます。begin_snapにはレポートする開始時刻のSnap Idを入力します。end_snapは終了時刻のSnap Idです。 Specify the Begin and End Snapshot Ids ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ begin_snapに値を入力してください: 7 Begin Snapshot Id specified: 7 end_snapに値を入力してください: 8 End   Snapshot Id specified: 8 最後に出力するファイル名を入力します。デフォルトの名前は指定したSnap Idから生成されています。enterを押すとAWRレポートが生成されます。画面にはHTMLが流れますが、それがsqlplusを起動したカレント・ディレクトリにファイルとして記録されます。 Specify the Report Name ~~~~~~~~~~~~~~~~~~~~~~~ The default report file name is awrrpt_1_7_8.html.  To use this name, press <return> to continue, otherwise enter an alternative. report_nameに値を入力してください: Using the report name awrrpt_1_7_8.html <p /> <p /> <p /> End of Report </body></html> Report written to awrrpt_1_7_8.html SQL> exit これでAWRレポートが生成されました。sqlplusからexitするとカレント・ディレクトリに指定したファイル名で出力されています。 基本からわかる!高性能×高可用性データベースシステムの作り方 indexページ  

基本からわかる!高性能×高可用性データベースシステムの作り方 indexページ 第13回ではCDB全体のAWRレポートの作成とAWRスナップショットの取得に関するコマンドラインでの操作について説明しました。今回はPDB単位でのAWRについてです。Oracle Database 12c...

データベースのセキュリティ評価・ユーザーリスク評価を可能にする Oracle Data Safe とは

  ユーザーは、Oracle Cloudの多くのメリットを利用することを熱望していますが、データの保護に役立つツールへ簡単にアクセスする必要もあります。   幸いなことに、Oracle Databaseのユーザーは、オンプレミスとクラウドの両方におけるデプロイメントをサポートする豊富なセキュリティ制御を利用できます。ただし、これらのソリューションのデプロイメントと継続的なサポートは、多くの場合は“自分でする”ことになっています。 Oracle Data Safeは、使いやすくオンプレミスでのデプロイメントを必要としない1つの統合されたクラウド・サービスで、5つの重要なデータ・セキュリティ機能をユーザーに提供します。 この記事では、次のそれぞれの機能を取り上げます。 セキュリティ評価 ユーザー評価 アクティビティ監査 データ検出 データ・マスキング たとえOracle Autonomous Databaseのようなマネージド・データベース・サービスを使用しても、ユーザーがサービスにアクセスするための構成方法にはかなりの自由があります。Data Safeのデータベース・セキュリティ評価機能は、セキュリティにマイナスの影響を与える構成の決定事項を表示し、脆弱性につながるギャップを特定するのに役立ちます。Data Safeのセキュリティ評価は、データベース構成の包括的なチェックを実行して、ユーザーのアカウント、権限およびロール付与、認可の制御、きめ細かな制御、監査、暗号化、構成パラメータなどの分野を調査します。また、組織のベスト・プラクティスと比較してギャップを特定し、優先順位付けされた推奨事項とEU GDPR、DISA STIGs、CISベンチマークなどの一般的なコンプライアンス条件へのマッピングを含む実用的なレポートを提供します。 Data Safeが実装する独自の新機能により、セキュリティ管理者はさまざまなデータベース・ユーザーによるリスクを評価できます。ユーザー・リスク評価機能は、データベース・ユーザーの評価を実行し、もっともリスクのあるユーザーを特定するためにユーザーのプロファイルの静的および動的な特性を調査します。ユーザー・リスクはグラフィカルに表示されるため、管理者は権限を越えている可能性のあるユーザーを迅速に判断したり、監査などの補正コントロールの適用を要求したりできます。 データベース監査は、おそらくデータベース・セキュリティと規制遵守のためにもっとも重要な制御です。Data Safeのユーザー・アクティビティ監査機能を使用すると、管理者は事前定義されたさまざまな監査ポリシーから選択をし、それらを1度のマウス・クリックでデータベースで有効化できます。そして、クラウド・データベースから監査記録の収集を開始し、それらはData Safeサービスに保存されてセキュアに維持されます。Data Safeのユーザーは、ユーザー・アクティビティの追跡や科学捜査の目的でインタラクティブ・レポートにアクセスでき、ルーチンの収集やレポート作成の目的でサマリー・レポートにアクセスできます。これらのレポートは、PDFでダウンロードでき、組織のコンプライアンス・プログラムに役立ちます。また、管理者は事前定義された多数のアラート・ポリシーから選択ができ、セキュリティ侵害を示す異常なアクティビティがあった場合はただちに通知を受け取ります。 データベース内に含まれるデータのタイプとデータの機密性により、そのデータを保護するために使用すべき制御が決定されます。Data Safeに含まれる機密データ検出機能により、セキュリティ管理者は、“自分はどのタイプの機密データを保持しているのか?”や“自分はどのくらいの機密データを保持しているのか?”といった重要な質問に素早く答えることができます。Data Safeの機密データ検出機能により、個人を識別できる情報、財務情報、健康情報、仕事に関連する情報、教育情報などのカテゴリーにわたって125を超える機密データタイプを自動検出できます。機密データ検出によって、ユーザーはデータの価値を理解しやすくなり、防御の優先順位付けができるようになります。 機密データのマスキングにより、テストシステムおよび開発システムからセキュリティ・リスクが排除され、エンタープライズによって保存される機密データ量が最小化されます。Data Safeのデータ・マスキング機能は、事前定義された50を超えるマスキング・フォーマットのライブラリによって機密アプリケーション・データを素早くマスキングする機能を提供します。デフォルトのマスキング・フォーマットは、機密データ検出機能を使用して検出された機密データのタイプを基に自動的に提案されます。データ・マスキングは、誕生日やクレジット・カード番号などの機密情報の列を変換するために使用でき、条件付きマスキングや複合マスキングなどのより複雑なデータ・マスキングのユースケースもサポートできます。  Oracle Databaseで使用可能なセキュリティのテクノロジーや機能により、顧客は高度にセキュアなデータベース環境を維持できます。Oracle Data Safeでは、これらの重要な機能をシンプルなクリックアンドセキュア・インタフェースで使用できるようになりました。セキュリティに関する詳しい専門知識は必要ありません。Data Safeはデプロイメントを必要としないサービスとして提供されるため、顧客はデータベースの保護に関連する運用コストを削減でき、規模に関係なくすべての顧客がデータを安全に維持できます。Data Safeによって、今やまさにセキュリティはクラウドへ移行する理由となりました。 5つの機能のうちの最初の機能であるセキュリティ評価へのドリルダウンを開始しますので、来週の同じ時間にアクセスしてください。Data Safeについての詳細情報は、こちらをご覧ください。このシリーズの最初のブログをお読みでない場合は、パート1を参照して製品の全体的な案内をご覧ください。    ※本記事は、Michael Mesaros (Director of Product Management) による”A Guided Tour of Oracle Data Safe “を翻訳したものです。 AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

  ユーザーは、Oracle Cloudの多くのメリットを利用することを熱望していますが、データの保護に役立つツールへ簡単にアクセスする必要もあります。  ...

無料クラウドへ -AWSからOCIへの移行

先週のOracle Open Worldで、オラクルは驚くべき発表をしました。Oracle Cloudで完全に無料のサービス枠(「Free Tier」)を提供するというものです。Twitterでは批判の声を見かけましたし、本当だろうかと疑っている人もいるでしょう。完全無料だなんて、ウソでしょう?いえ、本当です。完全に無料の枠があるのです。1か月限定ではありません。12か月だけでもありません。ずっと無料です。「Always Free」のサービスにはAutonomous Databaseが含まれ、2つのインスタンス(それぞれ1つのOCPUと20 GBのストレージを搭載)を利用できます。これだけあれば何ができるでしょうか。実にいろいろなことができます――それについては近いうちにまた記事を書きますので、注目しておいてください。2台の仮想マシン(それぞれ1/8 OCPUと1 GBのメモリを搭載)のコンピューティング能力も利用できます。驚くべき速さ、というわけにはいきませんが、一定のアプリケーションを実行するには十分ですから心配は無用です。この点についてもいずれ、ブログに記事を書くつもりです。ストレージも用意されており、2つのブロック・ボリューム(合計100 GB)、10 GBのオブジェクト・ストレージと10 GBのアーカイブ・ストレージ、ロードバランサ(1インスタンス)、帯域幅は10 Mbpsとなります。他も監視、通知、電子メール配信などの機能が提供されます。このチャンスを見逃す手はありません。ぜひ詳しい情報をご覧になり、今すぐにサインアップしてください。確認のためにクレジット・カード情報を入力する必要はありますが、知らないうちに課金されるということはありません。最近、他にもいくつか、クラウド・プロバイダの無料サービスにサインアップしてみたのですが、いずれの場合もまずクレジット・カード情報を登録する必要がありました。 実際に使ってみた 私はOracle Cloudの支持者ですが、開発者の1人ですから(マーケティングや販売の担当ではありません)、まずFree Tierを自分の手で触ってみて、その価値を確かめ、他の開発者にも役立ちそうであると確信してからでなければ、このような記事を書くことはしません。そのようなわけで、私はまず個人アカウントを作成し、自分のプライベートなブログを、Amazon Web ServicesからOracle CloudのFree Tierに移すことにしました。Oracleに入る前は、個人ブログをホストするのにAWSを何年も使っていて、Oracle Cloudに移行しようと動いたことはまだなかったので、今回Free Tierで試してみるというのはうってつけの機会でした。私のブログは非常にシンプルなアプリケーションになっています。データベースにはAmazon RDSでMySQLを使用し、ブログウェアはカスタマイズしたGrailsアプリケーションで、Apache TomcatでWARファイルとしてデプロイしています。イメージのホスティングにはS3、電子メール配信にはAmazon SESを使用しています。移行プランの概要はこうです。 DBをMySQL RDSからAutonomous DBに移行 イメージをS3からOCI Object Storageに移行 電子メール配信をOCI向けのSESに切り替え OCI VMでアプリケーションをデプロイ 最初の手順はもちろん、無料アカウントにサインアップして、新しいDBインスタンスとVMを起動することです。サインアップのプロセスと、最初の無料Autonomous DBインスタンスの起動については、以前に記事を書いていますので、必要であれば参照してください。 DBの移行 DBの移行は、SQL Developerを使用すれば面倒なこともなく、簡単です。SQL Developerでは、ウィザードの案内に従って移行を進めることができます。ただし注意点が1つ。移行を実行するには、いくつかの大きな権限を付与されたユーザーを使用する必要があります。移行を始める前に、このドキュメントをすべて読んでおいてください。いや、正直になりましょう。ドキュメントを最初から最後まで、本当に読みますか?そんなことしませんよね。でも、少なくともこのセクションだけは読んでください。移行時のユーザーに必要な権限について説明されています。  データの移行後には、MySQLではなくOracle DBを使うために、Grailsアプリケーションに少し変更を加える必要がありました。Hibernateの言語の設定を変更する、自動採番のキーではなくシーケンスが使用されるようにする、などの作業です。特別やっかいな作業はありません。アプリケーションのバックエンドを変更する場合は、こうした小さな調整作業は避けられないものです。 オブジェクトをS3から移行 私の場合、移動しなければならないイメージが100個ほどしかなかったので、これは比較的楽な作業でした。S3からすべてを手動でダウンロードし、Oracle Cloud Object Storageに自分でアップロードしました。もっと複雑な移行にも、もちろん対応しています。必要な場合はこちらのホワイトペーパーをご覧ください。オブジェクトの移動が済んだところで、SQLの更新クエリーを実行して、私の全ブログ記事にあるリンクを、OCI Object Storageの新しいリンク先に差し替えました。最後にコードを修正して、S3に指定されているものをOracle Cloudに変える必要がありました。そうすれば、新しくアップロードしたものも、古いAWSのバケットではなく、Object Storageに保存されることになります。私のGrailsアプリケーションはAWS SDKをGrailsプラグイン経由で使用するので、OCI SDK向けに変更しなければならないかと思っていましたが、OCI Object Storageには、既存のAWS SDKで使用できる、互換性のあるS3エンドポイントが用意されているので、問題ありませんでした。プラグインで手を加える必要があったのは、エンドポイントの変更と、いくらかの設定だけでした。私のControllerで、3行のコード(以下の4~6行目)を実行すれば完了です。 次に、Grails Mailプラグインの設定を、AWS SESサーバーからOCIサーバーに切り替えました。コンソールのサイドバーにあるメニュー、「Email Delivery」→「Email Configuration」で設定できます。 このようになりました。 Configurationページの「Manage SMTP Credentials」をクリックすると、ユーザー管理セクションに移動し、アプリケーションで使用する認証情報を生成できます。 アプリケーションのデプロイ さて、この時点で、DBを作成して移行し、オブジェクトを移行し、アプリケーションを構成して、新しい環境で使えるようになりました(Oracle CloudでDB、オブジェクト・ストア、電子メール配信サービスが使えるようになった)。次のステップは、アプリケーション自体のデプロイです。つまりコンピュート・インスタンスの作成が必要になります。まず、コンソールのダッシュボードに戻って、「Create a VM Instance」をクリックします。 インスタンスに名前を付け、OSイメージを選択します。 次に、インスタンスへの接続に使用するSSH公開鍵をアップロードし、「Create」をクリックします。 インスタンスを作成すると、インスタンスの詳細が表示されます。パブリックIPアドレスをメモします。これはマシンにSSH接続する際に使用されます(ユーザー名'opc'と、先ほど指定したSSH鍵を使用)。Webトラフィックを許可するには、受信ルールをいくつか追加する必要があります。ここに表示されているサブネットをクリックします。 サブネットの詳細ページの左のサイドバーで「Security Lists」をクリックし、デフォルトのセキュリティ・リストを選択して編集します。 受信ルールを追加して、ポート80と443のトラフィックを許可します。 これでコンピュート・インスタンスの準備ができました。トラフィックがブロックされている場合は、VM自体でローカルのファイアウォール・ポートを開く必要がある場合もあります。 ここで私は、Tomcatをインストールして、WARファイルをアップロードし、デプロイしました。私の場合、SSLの証明書をセットアップするという追加作業が必要になりましたが、この移行作業もたやすいものでした。 AWSとOCIの比較 さて、この移行で何が成し遂げられたのか、詳しく振り返ってみましょう。 コスト これは回答の出しやすい問題です。私はブログをホストするために、Amazonに毎月35ドル支払う必要がなくなりました。OCIの「常に無料」のサービスは、そう、常に無料です。AWSの無料枠のように、12か月限定ということもありません。 コスト:「常に無料」のOCIが文句なしの勝者です。 コストは重要ですが、他の点も考えてみましょう。 信頼性 AWSの数値データはなかなか見つからないので、比較は困難です。しかし、Autonomous DBは自己保護と自己修復が可能であり、実行中に実際に自らパッチを適用します。SLAでは99.995 %の信頼性が保証されています。1か月あたりの停止時間は2.5分未満ということです(パッチ適用を含む)。AWSの定期メンテナンス、パッチ適用、アップデートは、これにまったく及びません。 信頼性:Autonomous DBとAutonomous OS(Oracle Linux)は停止時間が少なく、Oracle Cloudの方が信頼性が高いことを、データは示しています。勝者はOCIです。  ユーザー・エクスペリエンス スクリーンショットを何枚かご覧ください。それが一番分かりやすいと思います。どちらのコンソールの方が統一感があり、見やすく、整理されていて、使いやすいか、ご自分の目で確かめてほしいのですが、結果は一目瞭然ではないでしょうか。以下のサンプルはすべて、1つ目がOCI、2つ目がAWSの順になっています。 コンピュート・インスタンスの一覧: セキュリティ・ルールの編集: オブジェクト・ストレージ・バケットの一覧。S3のインタフェースは使いやすくなってはいますが、AWSで提供される他のサービスの見た目や使い勝手とはまったく統一が取れていません。 DBインスタンスの作成。こちらも同じく、RDSのインタフェースはすっきりしてはいますが、他のAWSサービスとの統一感はありません。一方、OCIのインタフェースは整然としていて見やすく、統一感もあります。OCIコンソールに慣れてしまえば、ダッシュボードで他のサービスを使用する場合も戸惑うことはありません。Oracle Cloudのその他のサービスと、見た目や操作性が同じだからです。 ユーザー・エクスペリエンス:AWSにも素敵なインタフェースがいくつかありますが(サービスによって異なる)、EC2のように、時代遅れで古くさいものもあります。この分野の勝者はOCIです。OCIのインタフェースは整然としていて見やすく、統一感もあります。すっきりしていて、ごちゃごちゃした感じはありません。これまでのオラクル製品のユーザー・インタフェースの多くは、この点で優れていたとは言いがたいものもありますが、今回は近代的で見やすく、使いやすくなっています。  まとめ オラクルにはFree Tierがあります。本当に、無料です。支払いは一切発生しません。ずっと無料です。すばらしいことです。ぜひ使用すべきです。  Oracle CloudのFree TierでコンピュートおよびAutonomous DBを使用するにあたっての、あなたのアイデアをお聞かせください。共有してくださったアイデアは、今後のブログやビデオでご紹介させていただくことがあります。 Photo by Nghia Le on Unsplash   ※本記事は、Todd Sharp (OracleのDeveloper Advocate) による”Journey To The Free Cloud - Migrating From AWS To OCI“を翻訳したものです。 AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

先週のOracle Open Worldで、オラクルは驚くべき発表をしました。Oracle Cloudで完全に無料のサービス枠(「Free Tier」)を提供するというものです。Twitterでは批判の声を見かけましたし、本当だろうかと疑っている人もいるでしょう。完全無料だなんて、ウソでしょう?いえ、本当です。完全に無料の枠があるのです。1か月限定ではありません。12か月だけでもありません。ずっと無...

Oracle Autonomous Data Warehouse アーキテクチャと戦略:Part2(全3回)

3ブログ・シリーズのパート2:高度なデータ・プラットフォームの設計によるデータ管理のサポート 今日のデータドリブンな世界では、‘スマートな’つまりコグニティブなソリューションがブームになっています。中でも人気なのが、AI、機械学習、データ分析など、ビジネスが‘思考’し、データをより効果的に活用することを支援するソリューションです。何十億もの投資がコグニティブ・ソリューション分野に流れ込むため、これらのコグニティブ・ソリューションは今後数年にわたって広まると予想されます。 しかし、コグニティブ・データ・ソリューションの市場を推進するものは何でしょうか?第一に、データは非常に重要で価値のあるものです。第二に、ビジネス・プロセスをもっと直感的にインテリジェントにして、現代のビジネス環境での競争上の優位性を高めたいという一般的な願望があります。このビジネスのスマート化は、リーダーが市場動向に対応し、カスタマー・エクスペリエンスにプラスの影響を与え、高速で進化し続けるデジタル経済に適応できるようにするために絶対に必要です。このようなスマートなソリューションがないと、ビジネスは停滞し、受け身のまま市場ダイナミクスに反応することになってしまいます。  肝心なこととして、データドリブン・ソリューションの需要が増していることは、さまざまな業界で大量のデータが生成され、デジタル化されていることの直接の結果です。そして、そのデータ・フットプリントはひたすら増加し続けます。この3パートのブログ・シリーズの最初の投稿で、私は世界で生成されるデータ量は2018年の33ゼタバイト(ZB)から2025年には175 ZBに増加すると記しました。これを基に計算すると、世界のデータの90%はこの2年間で生成されたことになります。そして、このデータすべての管理に関する市場の反応として、世界のコグニティブ・ソリューション市場は2018~2022年の期間にほぼ50%のCAGRで成長するだろうとアナリストは予測しています。 説得力のある統計ではありますが、私にどういう関係があるのかと疑問に思われることでしょう。それはもっともで、その理由は次のとおりです。ビジネス・プロセス・データからインサイトを引き出し、データをベースとした予測によって人間による意思決定能力を向上させるのは、これらのコグニティブ・ソリューションなのです。これだけでもかなり重要なことですが、もしあなたが何もする必要がなかったとしたら、つまりデータの取得と処理を自動化できたら、あなたには何ができるかを想像してください。私に言わせれば、それこそがわくわくするような部分(経営陣を関与させる部分)が生まれるときです。 ビジネスがスマートなソリューションを活用し、デジタル・トランスフォーメーションの最先端のレベルの視界で適切な意思決定を行えることで、組織が市場の勢いを真に捉えることができるというのは素晴らしいことです。データウェアハウスの支援によって事前に検索可能なパターンに基づいて、特定の市場でどの製品の調子が良いかが分かることを想像してみてください。また、データや、クライアントとの以前の相互作用に基づいて、小売りやショッピングの体験を動的にカスタマイズできることを想像してみてください。競合の観点からすると、センチメント分析のようなソリューションを使用すると、機械学習を利用することで自社のサービスと同時に、競合他社のサービスに関連する市場センチメントをより深く理解できます。 コグニティブ・ソリューションについて、セキュリティの例があります。AIを使用したセキュリティ機能を使用すると、異常な行動を検出して事前に対応できます。同様に、コグニティブ・システムを使用することで、データ・メトリクスに基づいて不正を検出して阻止することができます。コグニティブ・エンジンについては、スマートで迅速にというのが新たな常識となっています。 Oracle Autonomous Data Warehouseが行うのは、まさにこのことです。Oracle Autonomous Data Warehouseは、応用機械学習を使用して自己チューニングし、データベースの稼働中に自動的にパフォーマンスを最適化します。まさに、提供するサービスや製品の中断と変換をサポートするために市場に対する展望を与えるソリューションを使用しているのです。Oracle Autonomous Data Warehouseは、次世代の自律型テクノロジーで構築されており、人工知能を使用してこれまでにない信頼性、パフォーマンス、そして柔軟性に優れたデータ管理を提供することで、データウェアハウスのデプロイを数秒で実現します。Oracle Autonomous Data Warehouseは、自動的つまり‘自律型’のデータ管理の概念に新たな意味をもたらします。次にその意味を説明します。 自己稼働。もしOracle Autonomous Data Warehouseに車輪があったら、それ自身で操縦をすることでしょう。ただし、ここでの自己稼働の要素は、ネットワーク構成、ストレージ、そしてデータベースのパッチおよびアップグレードを処理する完全に管理されたデータウェアハウスのクラウド・サービスを指します。顧客のDBAは必要ありません。 自己保護。この部分はまさに革命的で、業界では今まで類を見ません。データベースの自己保護部分により、アーキテクチャは常に最新のセキュリティ・パッチを実行できます。また、稼働中であっても、自律的に、すべて自分で異常行動を検出して更新を実行するのです!さらに、保存中のデータは、透過的データ暗号化(TDE)を使用してデフォルトで暗号化されます。最終的に、データベース・クライアントはSSL/TLS 1.2暗号化および相互に認証された接続を使用します。(独自の自己保護アーキテクチャについては、シリーズの3番目のブログで詳しく取り上げます。) 自己修復。誰も停止を経験したくありません。停止は大きなストレスの原因となり、ビジネスの流れに影響して止めてしまうこともあります。Oracle Autonomous Data Warehouseは、停止時間からの自動保護を備え、設計の中核に合わせて構築されています。すべてのコンポーネントに高可用性が組み込まれており、バックアップは完全に自動化されています。これは、活発に稼働して操作を維持するデータ・プラットフォームを入手したことで、夜と週末を取り戻すことができることを意味します。 素晴らしいではありませんか。この自律型のデータ車両のボンネットを開けて、実際にどう動くのかを見てみましょう。 Oracle Autonomous Data Warehouseの仕組み Oracle Autonomous Data Warehouseは、DevOpsプロセス全体への直接的なエンジンおよび統合ポイントです。何より、データドリブンのアプリケーションが機械学習を活用することによって、サードパーティのソリューションと並んでローカル・サービスを使用しながら強力な結果を提供できます。これは、既存の開発者向けツール、データ統合サービス、データ可視化、およびクラウド・オブジェクト・ストレージが、クラウドの能力を利用しながらOracle Autonomous Data Warehouseと簡単に統合することを意味します。 データから最大の価値を引き出すために、必要とされるあらゆる方法でデータを可視化できます。Oracle Data Visualization Desktopを利用するか、自身のサードパーティのビジネス・インテリジェンスやデータ可視化ソリューションを使用してください。 Oracleデータの可視化 最後に、そしてこれがより革命的な部分ですが、Oracleの機械学習は、SQLユーザー向けに設計されたノートブック・アプリケーションを提供し、高度な分析およびデータ・モデルに基づいたレポートの開発、記録、共有、および自動化を可能にするインタラクティブなデータ分析を提供します。 Oracle Machine Learning Notebook Apache ZeppelinテクノロジーをベースとするOracle Machine Learning SQLのノートブックを使用すると、予測モデルや分析手法の構築、評価、デプロイをチームで共同で実施することができます。 そのため、このSQLノートブックは、データ・サイエンティストがOracle Autonomous Data Warehouse(ADW)で機械学習を実行するためのインタフェースとして機能します。これらのノートブック・テクノロジーは、前提条件、アプローチ、根拠の文書化をサポートしながらスクリプトの作成をサポートすることで、データ・サイエンス・チームの生産性を向上させます。 優れたレベルの組込み自動化およびインテリジェント機能により、データウェアハウスを強力な機械学習とコグニティブ・ソリューションに結合できます。これにより、Oracleプラットフォームおよびそのクラウド・サービスのスケーラビリティとパフォーマンスを利用することで、データ・サイエンティスト、開発者、ビジネス・ユーザー間の迅速で容易なコラボレーションが可能になります。 要約しましょう。まとめると、データドリブンの自律型ソリューション、特にOracle Autonomous Data Warehouseには以下のようなメリットがあります。 データおよびデータウェアハウス・リソースの簡素化されたエンド・ツー・エンド管理 高パフォーマンスを含め、データ要件に合わせて完全に調整され‘すぐに使用可能’ アイドル状態のコンピューティング・シャットオフに関するインテリジェント機能による完全に柔軟な拡張 依存性およびリアルタイムのワークロード要件に基づく自動拡張 オンプレミス、ハイブリッド、またはマルチクラウドで実行されるソリューションをサポートする機能 ネイティブまたはサードパーティのデータ統合ツールを利用する機能 高パフォーマンスの問合せと同時ワークロード:さまざまなタイプのユーザー向けに事前構成されたリソース・プロファイルに基づいて、問合せパフォーマンスが最適化 大量のデータを移動する強力なデータ移行ユーティリティ データ・ストレージ、リポジトリ、およびAmazon AWS Redshift、SQL Server、他のデータベースを含む処理エンジンとの緊密な統合 セキュリティに関して不安のある方のために(不安のない方にも)、シリーズのパート3でこの重要なトピックについて取り上げ、そこではAutonomous Data Warehouseがすべてのデータ(休止中および稼働中)を暗号化されたフォーマットで保管する方法について詳述します。 最終的な結論:これからはデータドリブンです。データの準備を整えてください 業種や企業の規模に関係なく、データは未来に影響を与えます。データを利用するだけでなく、利用を簡単にする方法を見つけた組織こそが、デジタル経済において有意義で競争力のあるメリットを目にします。 私の見方では、オラクルのAutonomous Data Warehouseは、柔軟な拡張が可能で、迅速なクエリー・パフォーマンスを実現し、データベース管理を必要としない、使いやすくて完全に自律型のデータベースを提供します。これは、データの使用にまつわる複雑さを排除する種類のテクノロジーです。何よりも、これによって、データの力を真に利用し、データドリブンの未来において革新的で収益を可能にする活動を行うことができます。   ※本記事は、Bill Kleyman(EVP of Digital Solutions, Switch | Industry Influencer) による”The Oracle Autonomous Data Warehouse: Architecting Advanced Data Platforms to Support Data Management“を翻訳したものです。 AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

3ブログ・シリーズのパート2:高度なデータ・プラットフォームの設計によるデータ管理のサポート今日のデータドリブンな世界では、‘スマートな’つまりコグニティブなソリューションがブームになっています。中でも人気なのが、AI、機械学習、データ分析など、ビジネスが‘思考’し、データをより効果的に活用することを支援するソリューションです。何十億もの投資がコグニティブ・ソリューション分野に流れ込むため、これらの...

Database

基本からわかる!高性能×高可用性データベースシステムの作り方 第13回 AWRレポート作成とAWRスナップショット取得(CDB全体)

基本からわかる!高性能×高可用性データベースシステムの作り方 indexページ 第12回では、Oracle Databaseの性能分析をするとき、何を調べるときにどんなツールがあるかを俯瞰しました。今回はその1つ、AWRレポートの作成とAWRスナップショットの取得に関するコマンドラインでの操作についてです。「AWRレポートを提供してください」と言われたときに最低限知っておくべきことに絞って説明します。 AWRレポートとは Automatic Workload Repositoryとは、Oracle Database 10gで導入されたOracleインスタンス全体の実行統計を取得する仕組みです。AWRの機能を使用するためにはEnterprise EditionのDiagnostics Packのライセンスが必要です。Oracle初期化パラメータcontrol_management_pack_accessがDIAGNOSTICS+TUNING(デフォルト)もしくはDIAGNOSTICSである必要があります。 SQL> SHOW PARAMETERS control_management_pack_access NAME                                 TYPE    VALUE ------------------------------------ ------- ------------------- control_management_pack_access       string  DIAGNOSTIC+TUNING   Oracleインスタンスは起動している間、使用したCPU時間やI/O量などの実行統計値を観測しています。AWRスナップショットとは、Oracleインスタンスが起動されてからの累積実行統計値を特定時刻で表にINSERTしたものです。CREATE DATABASEした時点で、デフォルトでAWRスナップショットが1時間に1回取得されるように設定されています。AWRレポートとは、指定した2点のAWRスナップショット間の実行統計を、人間が読むのに適した形に整形したHTMLもしくはテキスト形式のファイルです。   AWRレポートの作成に指定する2点は連続している必要はなく、離れていてもかまいません。例えば24時間離れた2点を指定すると、1日の平均アクティビティを調べることができます。ただし、Oracleインスタンスを停止してしまうと実行統計がリセットされてしまうため、Oracleインスタンス再起動をまたいだ2点を指定したAWRレポートは無効です。 一般的には、性能分析には24時間といった長時間の平均値はあまり役に立ちません。そのため、多くの場合は分析したい時間帯に絞った連続した2点間のAWRレポートを作成することになります。 AWRレポートの作成コマンド AWRレポートの作成にはsqlplusでOracleインスタンスに接続し、AWRレポート作成のSQLスクリプトを実行します。AWRレポートはHTMLもしくはテキスト形式のファイルとして出力されますが、そのファイルはsqlplusを起動したカレント・ディレクトリに作成されるため、ファイルを出力させたいディレクトリに移動してからsqlplusを起動します。管理者権限(SYSまたはSYSTEMユーザー)でログインします。 $ sqlplus / as sysdba コンテナ・データベース構成でこの方法でログインすると、CDB$ROOTにログインしたことになります。CDB$ROOTでAWRレポートを作成すると、Oracleインスタンス全体の、つまりこのコンテナ・データベース上のすべてのプラガブル・データベース(PDB)の統計が出力されます。Oracle Database 12c Release 2からPDBごとのAWRスナップショットの取得やAWRレポートの作成ができるようになっています。今回はPDBごとのAWRの説明はしません。以下の説明はすべてコンテナ・データベース全体の場合のものです。 AWRレポート作成のSQLスクリプトにはいくつかあるのですが、もっとも基本的なものがawrrpt.sqlです。awrrpt.sqlはログインしたデータベースのDBIDとOracleインスタンスでのAWRスナップショットからAWRレポートを作成します。クラスタ構成のOracle Real Application Clusters(RAC)は複数のOracleインスタンスが1つのデータベースをマウントしています。RACでawrrpt.sqlを実行すると、そのsqlplusが接続している1つのOracleインスタンスのAWRレポートを作成します。 sqlplusは@マークを付けたテキストファイルを読み取りそこに記述されているSQLスクリプトを実行します。awrrpt.sqlは$ORACLE_HOME/rdbms/admin/ディレクトリにあります。sqlplusは”?”の記号をORACLE_HOMEのディレクトリと解釈するため以下のように記述できます。 SQL> @?/rdbms/admin/awrrpt awrrpt.sqlを実行するとまず出力するファイル形式を問われます。デフォルトはHTML形式です。 Specify the Report Type ~~~~~~~~~~~~~~~~~~~~~~~ AWR reports can be generated in the following formats.  Please enter the name of the format at the prompt.  Default value is 'html'. 'html'          HTML format (default) 'text'          Text format 'active-html'   Includes Performance Hub active report report_typeに値を入力してください: ファイル形式はtextではなくデフォルトのhtmlをお勧めします。text形式はコピー&ペーストして報告書の作成などには便利ですが、長いSQL文が途中で省略されてしまいます。HTML形式はSQLが全文出力されます。「AWRレポートを提供してください」と言われたときは(デフォルトの)HTML形式のことだと思っておくとよいでしょう。 Instances in this Workload Repository schema ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   DB Id      Inst Num   DB Name      Instance     Host ------------ ---------- ---------    ----------   ------   1650164401     2      RAC19B       rac19bst2    ptvm37.jp.or * 1650164401     1      RAC19B       rac19bst1    ptvm36.jp.or Using 1650164401 for database Id Using          1 for instance number Specify the number of days of snapshots to choose from ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Entering the number of days (n) will result in the most recent (n) days of snapshots being listed.  Pressing <return> without specifying a number lists all completed snapshots. num_daysに値を入力してください: ファイル形式の次はDBIDとOracleインスタンスの指定です。awrrpt.sqlの場合はこれらが今接続しているOracleインスタンスに決め打ちです。 次に入力するnum_daysは何日前のAWRスナップショットまでさかのぼってリストに出すかです。何も入力せずにreturnを押すと記録が残っているすべてのAWRスナップショットがリストされます。以下の例では直近の1日分を出すために1と指定しています。 num_daysに値を入力してください: 1 Listing the last day's Completed Snapshots Instance     DB Name      Snap Id       Snap Started    Snap Level ------------ ------------ ---------- ------------------ ---------- rac19bst1    RAC19B            3191  09 10月 2019 00:00   1                                3192  09 10月 2019 01:00   1                                3193  09 10月 2019 02:00   1                                3194  09 10月 2019 03:00   1                                3195  09 10月 2019 04:00   1                                3196  09 10月 2019 05:00   1                                3197  09 10月 2019 06:00   1                                3198  09 10月 2019 07:00   1                                3199  09 10月 2019 08:00   1                                3200  09 10月 2019 09:00   1                                3201  09 10月 2019 10:00   1                                3202  09 10月 2019 11:00   1                                3203  09 10月 2019 12:00   1                                3204  09 10月 2019 13:00   1                                3205  09 10月 2019 14:00   1                                3206  09 10月 2019 15:00   1                                3207  09 10月 2019 16:00   1 Specify the Begin and End Snapshot Ids ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ begin_snapに値を入力してください: num_daysを入力するとAWRスナップショットを取得した時刻とそのSnap Idが列挙されます。このSnap Idを2つ指定した間のAWRレポートが作成されます。begin_snapにはレポートする開始時刻のSnap Idを入力します。end_snapは終了時刻のSnap Idです。 Specify the Begin and End Snapshot Ids ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ begin_snapに値を入力してください: 3206 Begin Snapshot Id specified: 3206 end_snapに値を入力してください: 3207 End   Snapshot Id specified: 3207 Specify the Report Name ~~~~~~~~~~~~~~~~~~~~~~~ The default report file name is awrrpt_1_3206_3207.html.  To use this name, press <return> to continue, otherwise enter an alternative. report_nameに値を入力してください: 最後に出力するファイル名を入力します。デフォルトの名前は指定したSnap Idから生成されています。enterを押すとAWRレポートが生成されます。画面にはHTMLが流れますが、それがsqlplusを起動したカレント・ディレクトリにファイルとして記録されます。 <p /> <p />End of Report </body></html> Report written to awrrpt_1_3206_3207.html SQL> これでAWRレポートが生成されました。sqlplusからexitするとカレント・ディレクトリに指定したファイル名で出力されています。 $ ls *.html awrrpt_1_3206_3207.html 自動取得されるAWRスナップショットの制御 ここからは、AWRスナップショットの取得を制御する方法について説明します。Oracle Database Enterprise Editionでは、デフォルトでAWRスナップショットが定期的に取得されており、それは1時間ごとで保存期間は8日です。その設定はDBA_HIST_WR_CONTROLビューで確認することができます。 SQL> SELECT SNAP_INTERVAL,RETENTION FROM DBA_HIST_WR_CONTROL; SNAP_INTERVAL        RETENTION -------------------- -------------------- +00000 01:00:00.0    +00008 00:00:00.0 本番運用するデータベースでは、性能問題が発生した場合に、過去の問題がなかった時点の性能統計と比較することが問題個所の特定に役立つことがあります。保存期間をデフォルトの8日よりもかなり大きな値にしておくのはよくある運用です。また、取得間隔は狭いほどその時間帯の事象の解像度があがります。そのため自動取得される間隔をデフォルトの1時間よりも短い15分や30分にするのもまたよくある運用です。 AWRスナップショットの自動取得間隔と保存期間を変更するにはDBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGSプロシージャを使用します。設定単位は分です。以下の例は取得間隔(interval)を30分、保存期間(retention)を44640分(=60分×24時間×31日)に設定しています。 SQL> EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (interval=>30,retention=>44640); PL/SQLプロシージャが正常に完了しました。 SQL> SELECT SNAP_INTERVAL,RETENTION FROM DBA_HIST_WR_CONTROL; SNAP_INTERVAL        RETENTION -------------------- -------------------- +00000 00:30:00.0    +00031 00:00:00.0 AWRスナップショットの手動取得 性能テストを行うような場合、テスト開始と終了の間の時間帯に限定したAWRレポートを作成したくなります。そのためにはテストの開始と終了の時点でAWRスナップショットを取得しておきます。DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOTプロシージャを実行すると、その時点のAWRスナップショットが取得されます。 SQL> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT; PL/SQLプロシージャが正常に完了しました。 Webでよくみかけるのはこのプロシージャ実行の方法です。 AWRレポートを作成するにはスナップショットIDの指定が必要になりますが、レポートを作成するためにawrrpt.sqlを実行したときに取得時刻とスナップショットIDを目視で突合するのは少し不便です。CREATE_SNAPSHOTには実はプロシージャだけではなく、ファンクションもあります。この「ファンクション」の戻り値はスナップショットIDです。そのため、以下のSELECT文を実行するとAWRスナップショットが取得され、そのスナップショットIDが返ります。 SQL> SELECT DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT() FROM DUAL; DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT() ------------------------------------------                                       3258 まとめ 今回は「AWRレポートを提供してください」と言われたときに最低限知っておくべきことに絞って説明しました。 AWRレポートを作成するためには管理者権限(SYSまたはSYSTEMユーザー)でログインし、SQLスクリプト$ORACLE_HOME/rdbms/admin/awrrpt.sqlを実行します。ファイル形式はtextと依頼されない限りデフォルトのHTMLがよいでしょう。レポートを作成したい時間帯の開始と終了の2点のスナップショットIDを指定します。 基本からわかる!高性能×高可用性データベースシステムの作り方 indexページ  

基本からわかる!高性能×高可用性データベースシステムの作り方 indexページ 第12回では、Oracle Databaseの性能分析をするとき、何を調べるときにどんなツールがあるかを俯瞰しました。今回はその1つ、AWRレポートの作成とAWRスナップショットの取得に関するコマンドラインでの操作についてです。「AWRレポートを提供してください」と言われたときに最低限知っておくべきことに絞って説明します。...

Japan Oracle User Group (JPOUG) Oracle Databaseを中心とした座談会’19

    去る2019年5月17日に開催された Oracle Code Tokyo 2019 は、大勢の方にご来場いただき、大盛況のうちに終了することができました。 ご多忙中、足をお運びくださいました皆様 この場をお借りして改めて御礼申し上げます。 Oracle Code Tokyo 2019 講演資料ダウンロードページ:こちら Oracle Code Tokyo 2019においてJPOUGによるセッションが開催され、Oracle Database 19cをテーマに深く語りあっていただきました。 この座談会にて使用されたスライドと登壇者発言録および参加された会場のみなさんとのかけあいがまとめられたものを、JPOUGメンバーの方々から『Oracle Databaseを中心とした座談会'19』レポートとして書き下ろしていただきました。 ぜひご覧いただき当日の雰囲気含め楽しんでいただければと思います。 『Oracle Databaseを中心とした座談会'19』レポート * Japan Oracle User Group (JPOUG)は、Oracle Databaseを中心にMySQLやJavaなどのオラクル製品およびサービスはもちろんIT関連技術全般にわたる情報交換の場です。技術者やユーザーが主体となって世界のオラクル・ユーザー・グループの一員として活動しています。 JPOUGホームページ:http://www.jpoug.org/ * JPOUG主催のイベントの開催案内は、以下のコミュニティサイトを通じて登録者の方に通知されます。イベントやセミナーに参加してみたい方やJPOUGの活動に興味のある方は、ぜひメンバー登録をお願いします。 JPOUG Doorkeeperコミュニティ :https://jpoug.doorkeeper.jp/   AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

    去る2019年5月17日に開催された Oracle Code Tokyo 2019 は、大勢の方にご来場いただき、大盛況のうちに終了することができました。 ご多忙中、足をお運びくださいました皆様 この場をお借りして改めて御礼申し上げます。 Oracle Code Tokyo 2019 講演資料ダウンロードページ:こちら Oracle Code Tokyo...

もしもみなみんがDBをクラウドで動かしてみたら

本連載では、主にOracle CloudのOracle Database関連サービスをまだ触ったことがない方を対象に、Oracle Cloud 上でOracle Databaseを利用するためのステップや関連機能、Tipsなどをお届けしていきます。実際に触っていただく際のご参考にしていただければ幸いです。   著者紹介 南野 英梨子(みなみの えりこ) 日本オラクルに新卒で入社。以来、主にOracle Maximum Availability Architecture(MAA)に関わる機能や製品を担当。特に好きなのは、Oracle Active Data Guard や Oracle GoldenGate。Oracle Database の魅力やベストプラクティス、そしてそれを簡単に使えるOracle Cloudの魅力をお客様に伝えようと、日々邁進中。 目次 第1回 [OCI Classic] Oracle Database Cloud Serviceを使ってみよう 2017.9.20 公開 第2回 [OCI Classic] Oracle Database Cloud Serviceの中身をみてみよう 2017.10.20公開 第3回 [OCI Classic] 状態を見てみよう - モニタリングツール 2017.11.25公開 第4回 [OCI Classic] 必要な時に必要なだけ - リソース拡張 2017.12.18公開 第5回 [OCI Classic] 可用性構成を作ってみよう - Real Application Clusters 編 2018.1.26公開 第6回 [OCI Classic] 可用性構成を作ってみよう - Data Guard 編 - 2018.3.27公開 第7回 [OCI Classic] バックアップ&リカバリ 2018.4.23公開 第8回 [OCI Classic] 環境を複製してみよう 2018.7.20公開 第9回 Oracle Cloud InfrastructureでOracle Databaseを使ってみよう 2018.12.20公開 第10回 Oracle Cloud Infrastructure Exadata を使ってみよう 2019.1.24公開 第11回 Oracle Cloud Infrastructure Exadata の構成について 2019.4.19公開 第12回 リソース追加してみよう - スケール・アップ/ダウン OCI Exadata 編 2019.5.17公開 第13回 リソース追加してみよう - スケール・アップ/ダウン Autonomous Database 編 2019.5.17公開 第14回 Oracle Cloud Infrastructure Database を使ってみよう 2019.8.28公開 第15回 Autonomous Databaseで自動スケーリングを設定してみよう 2019.11.20公開 第16回 サービス制限について 2019.12.15公開   Oracle Cloud Infrastructure Database 関連リンク Oracle Cloud Infrastructure (OCI) ・Oracle Cloud Infrastructure 概要 ・Oracle Cloud Platform ご利用ガイド (使い始めていただく方へ) /Onboarding Session ・チュートリアル : Oracle Cloud Infrastructure を使ってみよう ・Oracle Cloud(PaaS/IaaS) : セミナー情報  ・マニュアル Oracle Cloud Infrastructure Document 英語 / 日本語 ・リリース・ノート 英語 ・Oracle Cloud Infrastructure トレーニング -オンデマンド・ビデオ/学習ラボ/資格など OCI Database サービス全体 ・サービス概要 Oracle Cloud Database Services  ・Oracle Database Cloud Service - 概要/価格/マニュアル/トライアル/事例 ・マニュアル Oracle Cloud Infrastructure Document Database 英語 / 日本語 ・Oracle Cloud Infrastructure 上で利用可能なOracle Databaseのサービスの比較 Autonomous Database ・サービス概要 Autonomous Data Warehouse / Autonomous Transaction Processing  ・Oracle Autonomous Data Warehouse Cloud(ADW) - 概要/価格/マニュアル/トライアル/事例 ・マニュアル Oracle Cloud Infrastructure Document Autonomous Database 英語 / 日本語 ・Autonomous Database 技術詳細 ・Autonomous Database サービス・アップデート ・しばちょう先生連載 番外編  Autonomous Database = 究極のOracle Database OCI Database - VM/BM (DBCS)  ・サービス概要 Database Cloud Service Virtual Machine / Bare Metal  ・Oracle Database Cloud Service - 概要/価格/マニュアル/トライアル/事例 ・マニュアル Oracle Cloud Infrastructure Document Database VM/BM 英語 / 日本語 ・使ってみよう!Oracle Cloud Infrastructure - Database OCI Exadata Cloud Service (ExaCS) ・サービス概要 Exadata Cloud Service ・Oracle Exadata Cloud Service - 概要/価格/マニュアル/トライアル/事例 ・マニュアル Oracle Cloud Infrastructure Document Exadata 英語 / 日本語 Gen 2 Exadata Cloud at Customer (ExaCC) ・サービス概要 Exadata Cloud at Customer ・マニュアル Oracle Cloud Infrastructure Document Exadata Cloud at Customer 英語 / 日本語 Oracle Cloud を今すぐ始める! Always Free サービス Oracle Cloud Free Tier + 30日間無償トライアルはこちら      

本連載では、主にOracle CloudのOracle Database関連サービスをまだ触ったことがない方を対象に、Oracle Cloud 上でOracle Databaseを利用するためのステップや関連機能、Tipsなどをお届けしていきます。実際に触っていただく際のご参考にしていただければ幸いです。   著者紹介 南野 英梨子(みなみの えりこ)日本オラクルに新卒で入社。以来、主にOracle...

しばちょう先生の試して納得!DBAへの道

はじめまして、こんにちは。この連載を担当する"しばちょう"こと柴田長(しばた つかさ)と申します。 日本オラクルのデータベース・スペシャリストとして、長年数多くのミッション・クリティカル案件への技術支援やお客様のシステムに最適なソリューション・デザインの提案、さらにはやパフォーマンス・トラブルの問題解決に従事してきました。数年間のマネジメントを経験ののち、2019年10月現在は、オラクルコーポレーションのデータベース開発部門の一員として、日本におけるExadataを中心としたデータベースの提案、及び、技術支援を担当しております。 これらの提案やトラブル解決を行う上で痛感していることは、SIer時代の開発現場やOracle GRID Centerでの実機検証の経験が確実に生かされているということです。経験しているからこそ、マニュアル棒読みの機能紹介では留まらず、瞬時にその機能の適用シナリオも含めて自信を持って自分の言葉(お客様に合わせた言葉)でお客様に提案できますし、早期にトラブル原因の当たりを付けたり解決のアイディアを閃いたりすることが可能になっていると思っています。 今回の連載は、正に体験して頂くことが主軸となります。単純な機能紹介ではなく手を動かして理解を深めて頂けるような連載にしていきたいと考えております。内容としては私が新人をDBAに育てる際に使用する課題をカスタマイズしたものであり、レベルとしては初級~中級を想定しております。これからDBAを目指される方、実機での作業から数年間離れられている方等々、多くの方にご活用頂ければ幸いです。 しばちょう先生(@tkssbt)をTwitterでフォローする しばちょう先生のキャリア軌跡 【最新記事】 番外編  Autonomous Database = 究極のOracle Database 2018.10.19公開 昨年サンフランシスコで開催されたOracle Open World にて初めてそのコンセプトが語られたAutonomous Database。そのコンセプトを具現化してリリースされた一つ目のクラウドサービスがAutonomous Data Warehouse Cloud (以降、ADW)です。既に数多くのお客様からご要望を頂いており、そのコストパフォーマンスの高さに驚きの声が上がっています。 今回は番外編として、Autonomous Databaseが求められる背景からそのコンセプト、さらにはADWの真価について、しばちょう先生から紹介させて頂きます。   【しばちょう先生の講演資料 & 動画ダウンロード】 【Oracle Database Connect 2018】エキスパートはどう考えるか?体感!パフォーマンスチューニングⅡ(前半) [logmi] 【Oracle Database Connect 2018】エキスパートはどう考えるか?体感!パフォーマンスチューニングⅡ(後半) [logmi] 【Oracle Code Tokyo 2017】Live Challenge!! SQLパフォーマンスの高速化の限界を目指せ! [PDF] [YouTube][Iogmi] 【Oracle Database Connect 2017】エキスパートはどう考えるか?体感!パフォーマンスチューニング [YouTube] 【Oracle DBA & Developer Day 2016】製品開発/技術のエキスパートが集結: 12cの本当の魅力を語り尽くす [PDF] 【Oracle DBA & Developer Day 2016】ストレージ管理のベスト・プラクティス ~ASMからExadataまで~ [PDF] 【Oracle Database Connect 2016】DB障害解決の極意 実体験に基づくトラブル対応と対策案 [PDF] [YouTube] 【Oracle Cloud Days Tokyo 2015】Oracle Database 12c最新情報 ~MAA Best Practice~ [PDF] 【Oracle DBA & Developer Day 2014】しばちょう先生による特別講義! RMANの運用と高速化チューニング [PDF] 【Oracle DBA & Developer Day 2013】高可用性ベスト・プラクティスによるデータ破壊対策完全版 [PDF] 【Oracle DBA & Developer Day 2012】管理性と性能を向上させる ASM と RMANの魅力 [WMV/MP4/PDF] 【Oracle DBA & Developer Day 2011】どこまでチューニングできるのか? [前編 WMV/MP4] [後編 WMV/MP4] [PDF] 番外編  Autonomous Database = 究極のOracle Database 2018.10.19公開 第55回 SQLパフォーマンスの高速化の限界を目指せ!(3) 2018.5.25公開 第54回 SQLパフォーマンスの高速化の限界を目指せ!(2) 2018.2.13公開 第53回 SQLパフォーマンスの高速化の限界を目指せ!(1) 2017.6.27公開 第52回 AWRレポートを読むステップ4: 特定時間帯に発生する性能劣化の原因特定 2017.4.25公開 第51回 AWRレポートを読むステップ3: オンライン・トランザクションのスループット低下の原因特定 2017.3.29公開 第50回 [Oracle Database 12c Release 2] Oracle Database Cloud Service上にデータベースを作成 2016.11.25公開 第49回 [Oracle Database 12c] ASMディスク・グループ内のディスクの置換 2016.10.31公開 第48回 [Oracle Database 12c] 時間隔パーティション表(インターバル・パーティション表)のクセ 2016.09.26公開 第47回 [Oracle Database 12c] オンライン・データファイルの移動 2016.08.26公開 第46回 [Oracle Database 12c] RMANバックアップからの表および表パーティションのリカバリ 2016.07.26公開 第45回 Recovery ManagerのSWITCHコマンドでリストア時間ゼロ 2016.05.26公開 第44回 Recovery ManagerのVALIDATEでリストア・リカバリに備える 2016.03.29公開 第43回 SQL実行計画の共有とセッションのオプティマイザ関連パラメータの調査方法 2016.01.25公開 第42回 [Oracle Database 12c] 拡張索引圧縮(Advanced Index Compression)を試してみる 2015.09.29公開 第41回 [Oracle Database 12c] オンラインでのパーティション移動 2015.08.27公開 第40回 AWRレポートを読むステップ2:アクセス数が多い表領域とセグメント 2015.07.27公開 第39回 AWRレポートを読むステップ1:バッファキャッシュ関連の待機イベントと統計情報 2015.05.26公開 第38回 Flashback Drop機能による削除表の復旧と注意点 2015.4.27公開 第37回 ORAchkを使用したデータベースのヘルス・チェック 2015.3.26公開 第36回 SQLのパース処理とバインド変数の理解 2015.1.20公開 第35回 ASMのミラーリングによるデータ保護(2) ~高速ミラー再同期~ 2014.11.14公開 第34回 ASMのミラーリングによるデータ保護(1) ~障害グループと冗長性の回復~ 2014.10.10公開 第33回 ASMのリバランスの動作 2014.09.10公開 第32回 標準監査の基本的な使い方 2014.08.04公開 第31回 ASMのストライピングとリバランスによるI/O性能の向上 2014.07.07公開 第30回 ASMディスク・グループの作成と使用量の確認 2014.06.05公開 第29回 UNDO表領域の管理~パフォーマンス・チューニング~ 2014.05.12公開 第28回 UNDO表領域の管理~保存期間の自動チューニング~ 2014.04.07公開 第27回 パーティション表の管理~ILMにおける表データの圧縮と索引の再構成~ 2014.03.10公開 第26回 パーティション化による削除処理のパフォーマンス向上 2014.02.12公開 第25回 パーティション化による問合せのパフォーマンス向上 2014.01.09公開 第24回 Recovery ManagerによるData Recovery Advisorの活用 2013.11.29公開 第23回 Recovery Managerにおけるバックアップ時間をResource Managerで制御 2013.10.31公開 第22回 Recovery Managerによる高速差分増分バックアップ 2013.09.30公開 第21回 Recovery Managerによる差分増分バックアップ 2013.08.27公開 第20回 フラッシュバック・データベースのオーバーヘッド 2013.08.06公開 第19回 フラッシュバック・データベースによる論理障害からの復旧 2013.06.28公開 第18回 表のオンライン再定義でDML文の遅延を回避 2013.06.11公開 第17回 表領域の縮小とセグメントの格納位置 2013.05.02公開 第16回 OLTP表圧縮によるキャッシュ・ヒット率の向上 2013.03.29公開 第15回 圧縮表への変更方法と注意点 2013.03.04公開 第14回 基本圧縮の効果的な活用 2013.02.06公開 第13回 行移行、行連鎖を理解し性能トラブルを未然に防ぐ(2) 2013.01.04公開 第12回 行移行、行連鎖を理解し性能トラブルを未然に防ぐ(1) 2012.12.05公開 第11回 オプティマイザ統計情報の管理 ~ヒストグラムの効果を体験してみる~ 2012.11.02公開 第10回 オプティマイザ統計情報の管理 ~保留中の統計情報を有効活用してみる~ 2012.09.27公開 第9回 オプティマイザ統計情報の管理 ~統計収集の失効を制御してみる~ 2012.08.17公開 第8回 オプティマイザ統計情報の管理 ~統計収集の高速化を体験してみる~ 2012.07.27公開 第7回 表領域の管理方法を理解 2012.06.27公開 第6回 続・SQLの実行計画からパフォーマンスの違いを読み解く 2012.04.26公開 第5回 SQLの実行計画からパフォーマンスの違いを読み解く 2012.03.29公開 第4回 続・データ領域管理の理解~ダイレクト・パス・インサートを試してみる~ 2012.02.28公開 第3回 データ領域管理の理解~SQLチューニングにも挑戦~ 2012.01.31公開 第2回 表と表領域の関係 2011.12.20公開 第1回 表領域の作成と拡張 2011.11.17公開 【しばちょう先生の質問コーナー】 しばちょう先生が連載記事の内容について読者の皆様からいただいたご質問にできるだけお答えします。 また、記事の感想や今後取り上げて欲しい内容などのご要望もお聞かせ下さい。お待ちしております。 しばちょう先生へのご質問方法 こちらのフォームからお願いします。 "お問い合わせ内容”欄に"しばちょう先生の記事について”と、該当する記事の号数またはURLを必ず記載してください。

はじめまして、こんにちは。この連載を担当する"しばちょう"こと柴田長(しばた つかさ)と申します。 日本オラクルのデータベース・スペシャリストとして、長年数多くのミッション・クリティカル案件への技術支援やお客様のシステムに最適なソリューション・デザインの提案、さらにはやパフォーマンス・トラブルの問題解決に従事してきました。数年間のマネジメントを経験ののち、2019年10月現在は、オラクルコーポレーショ...

図でイメージするOracle DatabaseのSQL全集

Oracle ACE 山岸 賢治(やまぎし けんじ)   Oracle SQLの各機能をイメージ図を交えて解説 SQLの初心者から上級者までを広く対象読者として、Oracle SQLの各機能の典型的な使用例を、学習効率が高いと思われる順序で、SQLのイメージ図を交えて解説します。 SQLをイメージつきで理解することで、素早くイメージからSQLを考えられるようになることを目標とします。   目次 第1回 さまざまな結合 第2回 集合演算など 第3回 分析関数 第4回 集約関数など 第5回 RollUp集計など 第6回 階層問い合わせ 第7回 再帰with句 第8回 PivotとUnPivot 第9回 Model句 AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。  

Oracle ACE山岸 賢治(やまぎし けんじ)   Oracle SQLの各機能をイメージ図を交えて解説 SQLの初心者から上級者までを広く対象読者として、Oracle SQLの各機能の典型的な使用例を、学習効率が高いと思われる順序で、SQLのイメージ図を交えて解説します。 SQLをイメージつきで理解することで、素早くイメージからSQLを考えられるようになることを目標とします。   目次 第1回 さまざまな...

基本からわかる!高性能×高可用性データベースシステムの作り方

Oracle Databaseは40年にわたる改良を続けてきたRelational Database Management Systemです。その間、パフォーマンスや可用性、運用性などの膨大な機能が追加されてきました。 本連載ではOracle Databaseの動作原理から、高パフォーマンスで可用性の高いシステムを構築するためになぜこの機能があるのか、なぜこういう構成にするのか、といった点を説明していきます。データベース管理者の方のみならず、アプリケーション開発者の方にもご活用いただければ幸いです。   著者紹介 日下部 明(くさかべ あきら) 日本オラクル Oracle Database担当。Oracle GRID Centerのラインマネージャとしてオラクルの持つ最新技術をパートナー各社と共同で検証し、多くのホワイトペーパーを執筆・レビューしてきました。以後、Oracle Databaseのセキュリティ製品のリリースマネージャを担当。これらの経験を元にミッションクリティカルな案件のソリューションデザインの提案などを担当しています。著書に「これは使えるOracle新機能活用術」(翔泳社)。 目次 第1回 オンプレミス環境でのOracle Grid InfrastructureとOracle Databaseのインストール 2018.3.26 公開 第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと 2018.4.18公開 第3回 ネットワーク経由で接続 2018.5.25公開 第4回 高可用性構成でのOracle Net構成(1) 2018.6.20公開 第5回 高可用性構成でのOracle Net構成(2) 2018.7.13公開 第6回 バックアップ/リカバリ(1)ユーザー管理バックアップ 2018.8.23公開 第7回 バックアップ/リカバリ(2)RMANの基本 2018.9.21公開 第8回 バックアップ/リカバリ(3)RMAN増分バックアップとリストア/リカバリ 2018.10.22公開 第9回 バックアップ/リカバリ(4)RMANでのバックアップ時間の短縮 2018.12.19公開 第10回 バックアップ/リカバリ(5)RMANでのリストア/リカバリ時間の短縮 2019.02.20公開 第11回 バックアップ/リカバリ(6)データファイルよりも小さな粒度でのリストア/リカバリ 2019.03.20公開 第12回 Oracle Databaseの性能統計モデルと性能分析ツール 2019.04.19公開 第13回 AWRレポート作成とAWRスナップショット取得(CDB全体)2019.10.15公開 第14回 AWRレポート作成とAWRスナップショット取得(PDB単位)2019.11.14公開

Oracle Databaseは40年にわたる改良を続けてきたRelational Database Management Systemです。その間、パフォーマンスや可用性、運用性などの膨大な機能が追加されてきました。本連載ではOracle Databaseの動作原理から、高パフォーマンスで可用性の高いシステムを構築するためになぜこの機能があるのか、なぜこういう構成にするのか、といった点を説明してい...

構築の自由 – 「Always Free」サービスと「Always Free Oracle Autonomous Database」が、Oracle Cloud無償トライアルで可能に

2019年9月16日(月)、Oracle Cloud Infrastructure(OCI)の大規模なアップデートを実施しました。これにより、学生やプロの開発者をはじめ、新しいビッグ・アイデアの早期実現を模索する誰もが、無料、無制限でOracle CloudおよびOracle Autonomous Databaseによるアプリケーションの構築、テスト、導入ができる仕組みを実現しました。このアップデートによりOCIに追加された一連の「Always Free」サービスには、「Always Free Oracle Autonomous Database」が含まれています。またこのアップデートにより、オラクルの既存の300ドル・30日間無料トライアルプログラムは、新しい統一された「Free Tier」へと生まれ変わり、全世界でご利用いただけるようになりました。 登録方法 「Always Free」サービスと無料トライアルを含む「Free Tier」を始める方法は、1度の登録で簡単に済むように効率化されています。オラクル・ユーザーが「Free Tier」へ登録する場合は、簡単な認証ステップに従って手続きを進めるだけで済み、クレジット・カード情報の入力も不要です。たとえば、Oracle Academyの生徒および講師、Oracle OpenWorldおよびOracle Code Oneの参加者、Oracle Groundbreakerのアンバサダー、Oracle Salesを利用する見込顧客は、クレジット・カードなしで登録できます。その他の新規ユーザーは登録時にクレジット・カード情報の提供が必要です。これは本人確認のみを目的としています。 「Always Free」サービスに登録し、この利用を開始するための所要時間は5分足らずです。oracle.com/jp/cloud/freeにて「Free Tier」のページを開き、ハイライトされたボタンをクリックして登録を進めていくだけです。なお、この登録手続きの2つ目のステップでは「Home Region」を選択することになります。「Always Free」サービスはその「Home Region」においてのみ提供されるため、これは重要です。またアカウント作成後にこの設定を変更することはできません。必ず、表示されるRegionsのリンクをクリックして、必要な「Always Free」サービスが提供されるグローバル・データ・センターを確認してから、最適な「Home Region」を選択するようにしてください。 Oracle Universal Creditsを使用し、サポート対象の商用OCIデータ・リージョンにてサービスを利用している現行の有償カスタマーの場合、そのアカウントに新しい「Always Free」サービスが自動的に追加されるため、あらためて登録を行う必要はありません。 「Always Free」サービスに含まれるもの 「Free Tier」の一環である新しい「Always Free」サービスでは、必要不可欠なIaaSおよびPaaSテクノロジーがカバーされており、十分なリソースが(利用している間はずっと)無料で提供されます。リリース時に利用可能な「Always Free」サービスの形式と仕様は以下のとおりです。これらの「Always Free」サービスは、オラクルの高パフォーマンスでミッション・クリティカルなクラウド・インフラストラクチャにて提供されるだけでなく、オラクルの優れたクラウド・データベースであるOracle Autonomous Databaseにも対応しています。 「Always Free Oracle Autonomous Database」でできること 「Always Free Oracle Autonomous Database」からは包括的なデータベース体験が提供され、さらには開発者や管理者、データ・サイエンティスト向けの組み込みツールも用意されています。しかもすべてが無料です。これは、実質的にすべてのタイプのデータ(リレーショナル、JSON、空間、グラフ、マルチメディア、XML、ファイルなど)にも、どのインターフェース(フルSQL、RESTデータ・アクセス、一般的なプログラミング言語用ドライバ)にも対応した、マルチモデル・データベースです。このサービスでは、Autonomous Transaction ProcessingとAutonomous Data Warehouseの両方のワークロード・タイプをサポートしています。また、SQLおよびPL/SQLでのスクリプティングのためのSQL Developer Webといった開発ツールが、パワフルなコマンドライン・ユーティリティと合わせて含まれています。開発者はOracle APEXのフル・マネージドのインスタンスも利用できるため、モバイルやデスクトップ・ブラウザ向けの現代的な美しいデザインにて、ローコード・アプリを迅速に構築し、デプロイすることができます。データ・サイエンティスト向けにはSQLノートブックが用意されており、機械学習モデルの構築に活用できます。 「Always Free Oracle Cloud Infrastructure」サービスでできること 「Always Free Oracle Cloud Infrastructure」サービスには、汎用「Compute VM」、ブロック、オブジェクト、アーカイブ・ストレージ、ロードバランサが含まれています。また無料のアウトバウンド・データ転送、モニタリング、通知も割り当てられます。ユーザーは、「Always Free Oracle Autonomous Database」と合わせてこの無料サービスのセットを活用することで、さまざまな言語やフレームワークにてアプリケーションを開発およびデプロイしたり、ロードバランシングやストレージのクローニングなどのエンタープライズ・インフラストラクチャ機能をテストしたりすることができます。 まとめ このように、「Oracle Cloud Free Tier」は新しい「Always Free」サービスと「Always Free Oracle Autonomous Database」を揃え、すべての開発者にとって画期的な仕組みとなりました。登録作業も簡単で、サービスも有益で幅広く、Oracle Autonomous Databaseのすべてを利用できるため、開発者はエンタープライズ・クラスのソリューションを構築するためのリソースを迅速に、かつ費用をかけずにクラウド上に確保することができます。そして何よりも素晴らしいのは、これが「Always Free」であるため、クラウド・プロバイダが設定した期日には作業内容が消失してしまうなどと心配することなく、このサービスを利用できることです。これらの新しい「Always Free」サービスにより、開発者の構築の自由度は飛躍的に拡大します。 * * * * * * * * * * * * * * * * * * * * * AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。 ※本記事は、Todd Bottgerによる”Freedom to Build - Announcing Oracle Cloud Free Tier with New Always Free Services and Always Free Oracle Autonomous Database“を翻訳したものです。

2019年9月16日(月)、Oracle Cloud Infrastructure(OCI)の大規模なアップデートを実施しました。これにより、学生やプロの開発者をはじめ、新しいビッグ・アイデアの早期実現を模索する誰もが、無料、無制限でOracle CloudおよびOracle...

全国のOTNおすすめ技術者向けセミナー&イベント(2019年10月)

10/3 【ゲーム業界向けセミナー】ゲーム業界におけるMySQL 世界で最も普及しているオープンソースデータベースであり、数多くのオンラインゲームのバックエンドを支えているMySQL。このMySQLを使って日々活躍されているインフラエンジニアの皆様に、ゲーム業界における最新MySQL事例をご紹介いただきます。(ご講演予定企業様(50音順):株式会社f4samurai、株式会社スクウェア・エニックス、グリー株式会社、LINE株式会社) 10/10 実践Kubernetesハンズオン ~OKEでKubernetesを体験しよう~ Oracle Cloudは大規模なコンテナの管理、デプロイおよび運用に適したクラウドサービスを複数提供しています。本ハンズオンセミナーではOracle Cloudが提供するコンテナ・サービスを実際に利用しKubernetes環境の構築からコンテナ・アプリケーションのデプロイ、CI/CDまでの一連の流れを体感いただけます。 10/17 Oracle OpenWorld 2019 フィードバックセミナー 東京 世界最大級のITテクノロジー/ソリューション・イベントである Oracle OpenWorld 2019 が、 2019年 9月16日~19日まで、サンフランシスコで開催されました。本セミナーでは、 Oracle OpenWorld 2019で注目sareta 最新テクノロジー情報をソリューションごとに分かり易くまとめ、ご紹介します。 Oracle University 無償セミナー(10月) Oracle University のセミナーに参加しませんか。みなさまのスキルアップを応援します!10月は ORACLE MASTER の最高峰 ORACLE MASTER Platinum の傾向と対策セミナーを実施します。その他 Java Module System 入門セミナーなどポイントを絞って解説します。 AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。

10/3 【ゲーム業界向けセミナー】ゲーム業界におけるMySQL 世界で最も普及しているオープンソースデータベースであり、数多くのオンラインゲームのバックエンドを支えているMySQL。このMySQLを使って日々活躍されているインフラエンジニアの皆様に、ゲーム業界における最新MySQL事例をご紹介いただきます。(ご講演予定企業様(50音順):株式会社f4samurai、株式会社スクウェア・エニックス、グ...

全国のOTNおすすめ技術者向けセミナー&イベント(2019年11月)

MySQL Innovation Day 2019 を開催 MySQL 8.0のGAリリース以降も積極的に新機能を追加し続けるMySQL。この度、プロダクトマネージャーMike Frank(セキュリティ担当)、Kenny Gryp(高可用性担当)、コミュニティマネージャー“LeFred”およびOracle LabsのVice President Nipun Agarwalの4名が来日し、最新技術情報をお話いたします。 ・11/7  東京会場 - 詳細はこちらから ・11/8  大阪会場 - 詳細はこちらから 11/14 実践Kubernetesハンズオン ~OKEでKubernetesを体験しよう~ Oracle Cloudは大規模なコンテナの管理、デプロイおよび運用に適したクラウドサービスを複数提供しています。本ハンズオンセミナーではOracle Cloudが提供するコンテナ・サービスを実際に利用しKubernetes環境の構築からコンテナ・アプリケーションのデプロイ、CI/CDまでの一連の流れを体感いただけます。 11/27 Oracle Database Technology Night Oracle OpenWorld 2019 でもアナウンスされた通り Oracle Database SE2 環境でもマルチテナント・アーキテクチャにおいてPluggable Database が3つまで作成可能になりました。そこで、Tech Night でも再びマルチテナントにフォーカスします。今回は再入門編として19c マルチテナントの基礎について解説します。 11/28 実例から学ぶ!トラブル・シューティング トラブルが発生した時の一連の対応を習得する 1 day セミナーです。運用を担当される方にお薦めです。※演習はありません。11/28 受講者に限り、動作確認環境をセミナー翌週(12/2~7)にオンラインにてご提供いたします。受講の復習としてアラートログやSQLトレースなどをご覧いただけます。 11/29 実例から学ぶ!パフォーマンス・チューニング パフォーマンス低下時に、原因がDBなのかSQLなのかを切り分ける方法を学ぶ 1 day セミナーです。STATSPACKとSQLトレースを使います。※演習はありません。11/29 受講者に限り、動作確認環境をセミナー翌週(12/2~7)にオンラインにてご提供いたします。受講の復習としてアラートログやSQLトレースなどをご覧いただけます。 AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。

MySQL Innovation Day 2019 を開催 MySQL 8.0のGAリリース以降も積極的に新機能を追加し続けるMySQL。この度、プロダクトマネージャーMike Frank(セキュリティ担当)、Kenny Gryp(高可用性担当)、コミュニティマネージャー“LeFred”およびOracle LabsのVice President Nipun...

Oracle Autonomous Data Warehouse アーキテクチャと戦略:Part1(全3回)

パート1:データ管理にインテリジェンスと自律性を注入 現代のコネクテッドな社会は、データによって命が与えられているとは言わないまでも、データによって牽引されています。信じられないでしょうか。しかし2025年までには、コネクテッドな人のデータ・インタラクション数は少なくとも18秒に1回になると考えられています。つまり1日当たり4,800回のインタラクションということになります。さらにその頃には、生成されるデータの4分の1以上が本質的にリアルタイムになり、その95%以上をリアルタイムのIoTデータが占めることになるでしょう。 こうしたデバイスや、新しいコネクテッドなシステムとのインタラクション・ポイントにより、世界のデータ・フットプリントは間違いなく成長し、2018年の33ゼタバイト(ZB)から2025年には175 ZBになると考えられています。これを基に計算すると、世界のデータの90%はこの2年間で生成されたことになります。また、今後5年間でどれだけのデータが飛躍的に生成されるかを想像すると、その量には目まいがしそうになります。 データドリブン市場を総体的に見てみると、データ管理に関するソリューションは増加の一途をたどり、減速の兆しは一切見えません。生成される膨大なデータを適切に管理するために、ビッグ・データとビジネス・アナリティクス(BDA)に関連するソフトウェアが急速に2大ソフトウェア・カテゴリになりつつあると、IDCは指摘しています。 「このビッグ・データおよびアナリティクスのおもな牽引役となっているのが、エグゼクティブレベルの取り組みと合わせて実施されるデジタル・トランスフォーメーションです。これにより企業は、現在の業務を深く評価することができ、それと同時に、より適切に、より速く、より包括的に、データとそこに関連するアナリティクスやインサイトにアクセスしたいという需要が生まれています」と、IDCのアナリティクス・情報管理を担当するグループ・バイス・プレジデントであるDan Vesset氏は述べています。「こうした需要に対応するため、企業は再構築に着手し、イノベーションの実現と競争力の維持を可能にする最新のテクノロジーへの投資を実施しています」 つまりは、どういうことでしょう。データ量がどんどん増え続け、また複合化され続けていくことは、明日も太陽が昇るのと同じくらい明白です。企業にとっては、そのデータの価値と最適な活用方法を把握することが非常に重要です。またこれは、さまざまなデータタイプを取り込む新しい方法や、それらを賢く処理する方法、またそれらを保護し、その安全性を確保する方法、そして市場に関するより良い意思決定にデータを活かす方法を学ぶことでもあります。データドリブンのソリューションがなければ企業は失速してしまいます。したがって自社が苦労して手にした天然資源であるデータから真の価値を抽出できないような状況は克服しなければなりません。 では、企業がデータドリブンのソリューションに投資しないと、どうなるのでしょう。その結果は、かなり恐ろしいものです。皆さんが好むと好まざるとにかかわらず、企業はこれからもデータを生成していきます。今後1年間でも相当な量を生成することになるでしょう。 そうしたデータには、御社の製品、サービス、ソリューション、顧客といった多数の情報が含まれています。しかし、それらの情報を関連付け、理解するための適切なデータ・エンジンがなければ、データはただそこにあるだけで、企業に必要な事業上の潜在力にはならないでしょう。 データドリブンのソリューションがなければ、競合他社からも市場からもあっという間に見向きもされない存在になってしまいます。業界のトレンドに迅速に反応することも、顧客のニーズを適切に把握することもできず、さらには、より良い意思決定のための信頼できるインサイトを獲得できないために、収益にも重大な影響が及ぶことになってしまうでしょう。 では、データを適切に使用しているか、あるいは適切なデータを使用しているかは、どのように見極めればよいのでしょう。これは、適切なパートナーの力で解決できる部分でもあります。しかしより簡単な方法を探すなら、以下のような非常に基本的な質問を自社に問いかけてみるという選択肢もあります。 1.さまざまなデータ・ポイントをまとめて、ビジネス上のより良い意思決定を行う力が自社にあるか。 2.自社のデータはサイロの中に眠っており、何にも活用されていないのではないか。 3.データ・アナリティクス・エンジンを活用して、市場や顧客、データの相関性を見極める手段が自社にあるか。 4.明確なデータ・ポイントにてビジネスの方向性にインパクトを与えられているか。 5.自社のデータ・ストリームが十分に可視化されているか、もしくはデータは保護もされず、利用されないままになっているのか。 自社のデータ・プラットフォームをコントロールするための最初のステップは、自社にデータ・管理上の課題があるかもしれないことを理解することです。しかし日々大量のデータが生成されている状態で、インテリジェントなデータ処理ソリューションをデザインするのは、いつでも簡単にできるものではありません。 この3パートのシリーズでは、データウェアハウスの世界、自律型データウェアハウスがどのように構築されているか、データおよび自律型データウェアハウスにより効果的なセキュリティ戦略を策定する方法について、検討します。 シンプルなデータ・ストレージとインテリジェントなデータウェアハウスの違い 私たちはデータに依存しており、そこからは情報の処理、保存、活用に関する新しい方法も創出されています。実際、データを単純に保管しておく(シンプルなストレージ)ことにおいても、インテリジェントなデータウェアハウスデータ(ストレージおよびデータの取得プロセスにインテリジェンスが直接統合されている)においても、新しい方法が誕生しています。 従来のシンプルなストレージ:これについては、自社のデータセンターにあるストレージ・アレイを思い浮かべください。もしくは、コロケーションやクラウドにあるストレージ・リポジトリを思い浮かべても構いません。こうした「シンプルな」ストレージ・メカニズムは、文字通り、データのみを保管するものです。これらはレジリエンスが高く、アーカイブ・ストレージも、さらにはオールフラッシュのパフォーマンスも可能です。また今後は、ストレージの活用や、ファイル・タイプ、パフォーマンスやエクスペリエンスの最適化の方法に関する、統計やアナリティクスも備えることになるでしょう。しかしこれらのソリューションでは、たいていの場合、データドリブンのアナリティクスの部分があったとしても最小限度に留まることになると考えられます。つまり、データを保存することにおいては、こうした最良のシステムからメリットを得られるものの、そうしたデータを適用および活用する方法を見つけるためには、やはりデータ・エンジンの力が必要だということです。 インテリジェンスドリブンのデータ・ストレージとウェアハウス:これらのシステムについては、従来のストレージやファイル・リポジトリとは異なり、パワフルなデータ取得エンジンと考えることができます。これらはデータを保存できるだけでありません。ERPシステムやクラウド・アプリケーション、バックエンドのデータベースといった、さまざまなデータ・ストリームと接続して、大量のデータを取得し、定量化し、関連付け、処理することもできます。こうしたデータのソースや構造も問いません。また多くのシンプルなストレージ・ソリューションとは異なり、インテリジェンスドリブンのデータウェアハウスは、構造化、非構造化、半構造化などのデータにも対応しています。そうしたデータに対し、パワフルなデータドリブン・ツールを活用して、ビジネス上のより良い意思決定を下すことが可能です。こうしたツールとはつまり、従来のストレージ・メソッドでは不可能であった、パターンやトレンドを見つけられるよう設計されたアプリケーションやサービスを指します。 ここに具体例を挙げましょう。データウェアハウスは、データ・アナリティクスやビッグ・データ処理に関連したソリューションと合わせることで、貴重な情報を新たなレベルへと引き上げることができます。パワフルなデータウェアハウス・ソリューションはデータの視覚化にも役立つため、ビジネスや市場に関するより良い意思決定につなげることができます。データウェアハウスとはデータの取得に有益なだけでなく、組織全体の過去データを保存し、それらを処理し、重要なビジネス分析やレポート、ダッシュボードに活用できるような、意思決定支援システムでもあります。 もう少し詳しく説明しましょう。皆さんは、大量のデータ・ストリームを扱う大企業の社員だとします。または、特定のトレンドやデータ分析ポイントに対応する必要のある企業の社員だと仮定しても構いません。御社では、どのようにデータウェアハウス・ソリューションを用い、自律型行動のレベルを構築しているでしょうか。とりわけ、データからさらなる価値を取得するために、AIや機械学習、さらに高度なデータ・アナリティクスといったコグニティブ(認知技術)ソリューションにどのように取り組んでいるでしょうか。 IDCによる最近の算出によれば、データ分析の対象となる世界のデータ量は、2025年には50倍に増えて5.2 ZBになり、コグニティブ・システムにて「触れられる」分析対象データの量は、同じく2025年には100倍に増えて1.4 ZBになるとのことです。 これを念頭に置くと、データの可能性を活かすには、データセンターの新しい取り組みをサポートするだけでなく、ビジネス自体がデータドリブンな世界の一員になるようにしなければなりません。 それこそが、自律型で、コグニティブなデータ処理が可能なデータウェアハウスによって、データの活用方法、インテリジェント・システムの利用方法、情報の可視化方法、および新たな競争優位性の獲得方法に革命をもたらす鍵になるのです。 さまざまなソースから収集し、Oracle Autonomous Data Warehouseにて集計されたデータをカスタム・ビューで表示できる、ダッシュボード 上の図には、新しいソリューション(このケースでは、Oracle Autonomous Data Warehouse)により、データを活用して競争優位性を創出する方法に変化がもたらされていることが示されています。 自律型ソリューションでは、基本的に、コグニティブ・システムを活用することで、遥かに効果的にデータを処理できるようになります。またこれにより、企業による市場のおもなトレンドや顧客の需要への対応を支援します。それだけでなく、データ分析が遥かに簡単になり、市場への先見的な対応も可能にするパワフルなダッシュボードも用意されています。そして何よりも素晴らしいのは、自律型のデータウェアハウスを活用することで、その大半が自動化されることです。しかし先を急ぎすぎてはいけません。まずは、自律型のデータウェアハウスで私たちが実際に意図していることを把握する必要があります。それを以下に示します。 Oracle Autonomous Data Warehouseは、柔軟な拡張が可能で、迅速なクエリー・パフォーマンスを実現し、データベース管理を必要としない、使いやすくて完全に自律型のデータウェアハウスを提供します。すべての標準SQLとビジネス・インテリジェンス(BI)ツールをサポートするよう設計されており、データウェアハウスのワークロードに合わせてチューニングされ最適化された環境にて、市場をリードするOracle Databaseのすべてのパフォーマンスを提供します。 サービスであるOracle Autonomous Data Warehouseでは、データベース管理を必要としません。ハードウェアの構成や管理の必要がなく、またソフトウェアをインストールする必要もありません。データウェアハウスの作成も、データベースのバックアップも、データベースのパッチやアップグレードも、必要に応じたデータベースの拡張や縮小も、Autonomous Data Warehouseが自動で行います。 「オラクルでは、企業が自社のITリソースに多大な負荷をかけることなく、企業の力を活かせるようにする方法を真剣に考えてきました。そうして開発されたのがOracle Autonomous Databaseです」と、Oracle Product Marketing ManagerのChristopher McCarthyは述べています。 ご存知のとおり、大前提は、さまざまなタイプの大量のデータを利用、管理する方法をシンプルにすることなのです。だからこそ、OracleのAutonomous Data Warehouseでは、チューニングを必要としないことで、データの取り扱いを簡単にしているのです。Autonomous Data Warehouseは「load and go」サービスとして設計されています。サービスを開始し、表を定義し、データをロードし、問合せを実行して、データから価値を獲得する。それだけです。本当に。 その好例はレンタカー会社のHertzです。同社はAutonomous Data Warehouseを活用して、IT管理のタスクを削減し、データ・セキュリティを向上させ、Oracle Autonomous Analytics Cloudにてデータを分析しています。それまでは、新しいデータベースをプロビジョニングするために必要な承認を取得し、実際にプロビジョニングし、チューニングし、データをロード可能な状態にするのに、全体で2週間が必要でした。しかしOracle Autonomous Data Warehouseにより、データのプロビジョニングとロードの時間がわずか8分になったのです。   Oracle Autonomous Data Warehouseのデモ Oracle Autonomous Data Warehouseにより、データやアナリティクスへのアクセスによるビジネス上のメリット獲得がどのように簡単になるのか、ここで詳しくご説明します。   繰返しになりますが、これは、データの活用を容易にし、データから迅速に結果を得られるようにすることを特に意図して設計されています。Autonomous Data Warehouseなら、チューニングは不要です。並列化、パーティション化、索引付け、圧縮といったことの詳細を考慮する必要もありません。サービスにより、高パフォーマンスな問合せを実現できるようにデータベースが自動的に構成されます。 さらにAutonomous Data Warehouseには、サービスの管理(サービスの作成や拡張などのタスクのため)や、サービスのモニタリング(データウェアハウスでの最近のアクティビティ・レベルの表示などのタスクのため)が可能な、クラウドベースのサービス・コンソールが含まれています。 また、簡単な問合せ、データの視覚化、コラボレーション機能を提供する、クラウドベースのノートブック・アプリケーションも含まれています。このノートブックは、他のビジネス・インテリジェンス・アプリケーションと合わせて使用するように設計されています。Apache ZeppelinテクノロジーをベースとするOracle Machine Learningのノートブックを使用すると、Oracle Autonomous Data Warehouseにて予測モデルや分析手法の構築、評価、デプロイをチームで共同で実施することができます。 また複数ユーザーのコラボレーション機能により、同じノートブックを複数のユーザーで同時に開くことも可能です。チームの誰かが変更を加えると、その変更は即座に反映されます。さらにこうしたデータドリブンのソリューションはセキュリティの面でも非常に有益です。セキュリティ、認証、監査に関する企業の要件に対応するため、Oracle Machine Learningのノートブックはオラクルのすべての標準に準拠し、データ、モデル、ノートブックへの権限ベースのアクセスに対応しています。 すべてをまとめる 私たちがデータを創出し続けていることには、疑問の余地がありません。また、競争に挑むすべての企業にとって、こうしたデータが極めて貴重であることも、私たちは理解しています。Oracle Autonomous Data Warehouseは単なる新しいデータ処理エンジンではありません。これは、データを取り込み、それをこれまでよりも遥かに簡単に処理している間にも、「思考」するように設計されています。皆さんが活用しようとしているテクノロジーは、データセットと皆さんが指定した問合せのタイプに基づいて、さまざまなタイプの入力データを自動的に理解し、実際に調整できるものです。それはつまり、皆さんは、データを設定することではなく、データから導き出される結果に、よりフォーカスできるということです。 そのためには、Oracle Autonomous Data Warehouseの裏側にあるアーキテクチャを漠然とでも知ることが非常に重要です。だからこそ私はこの製品のカバーを外し、その内側をのぞいてみたのです。 まとめ この3パートのブログ・シリーズのパート2では、Oracle Autonomous Data Warehouseのアーキテクチャをレビューし、そのおもな利点がどこにあるのか、さらには新しい高度な自律ソリューションによってデータの視覚化がどのように変わったのかについても検討します。 その前に、どうぞこちらのWebcastに登録して、Oracle Autonomous Data Warehouseの詳細や、そのおもな利点および優位性(AWSより8~14倍速いことについてなど)、世界初のセルフドライビング・データベースによる開始の容易さについてご確認ください。   AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。   ※本記事は、Bill Kleyman(EVP of Digital Solutions, Switch | Industry Influencer) による” The Oracle Autonomous Data Warehouse: a three-part series“を翻訳したものです。  

パート1:データ管理にインテリジェンスと自律性を注入 現代のコネクテッドな社会は、データによって命が与えられているとは言わないまでも、データによって牽引されています。信じられないでしょうか。しかし2025年までには、コネクテッドな人のデータ・インタラクション数は少なくとも18秒に1回になると考えられています。つまり1日当たり4,800回のインタラクションということになります。さらにその頃には、生成され...

Amazon RedShiftからOracle Autonomous Data Warehouseへの移行テクニック

  このブログでは、SQL DeveloperのAmazon Redshift Migration Assistantを使用して、既存のAmazon RedshiftをOracle Autonomous Data Warehouse(ADW) に移行する方法を簡単に説明致します。 しかしまずは、なぜAutonomous Data Warehouseへの移行が必要なのかをお話ししましょう。   アナリティクスによって競争優位性を高めて自社を差別化するデータドリブンの企業では、自社のすべてのデータソースから価値を抽出しています。企業の物理的データウェアハウスは、全社からデータを収集して分析に活用する上でかつては優れた仕組みでしたが、途方もないスピードでデータが生成されている現在のデジタル・ワールドでは、そのスピードに追い付けず、そうしたデータに対応するために必要なストレージや計算リソースを提供できない状態になっています。さらに、環境やデータのパッチ、アップグレード、セキュリティのための複雑なタスクを手動で実施することには、多大なるリスクも伴います。 こうしたニッチな市場に対応できる数少ないクラウド・ベンダーの1つが、ParAccelからライセンス供与された技術を活用した、フル・マネージドなデータウェアハウス・クラウド・サービスであるAmazon Redshiftです。これは早くから市場に投入されたサービスではあるものの、そのクエリー処理アーキテクチャでは同時実行性のレベルが厳しく制限されるため、大規模なデータウェアハウスやWebスケールのデータ・アナリティクスには適していません。Redshiftはハードウェア構成の固定されたブロックでのみ利用可能であるため、ストレージと関係なくコンピュータを拡張することはできません。これでは予備のキャパシティが必要となるため、利用者は実際に使用する以上に利用コストをかける必要があります。さらに、リサイジングにおいては読取り専用状態になり、またダウンタイムが必要になることもあるため、データを再配分するのに数時間を要することもあります。 一方Oracle Autonomous Data Warehouseは、データウェアハウスのワークロードに合わせてチューニングおよび最適化される、フル・マネージドのデータベースで、構造化データと非構造化データの両方に対応しています。パッチやチューニング、バックアップ、アップグレードも実質的にダウンタイムなしで自動的かつ継続的に実施できます。総合的な機械学習アルゴリズムにより、自動キャッシング、適応的な索引付け、高度な圧縮が促進され、最適化されたクラウド・データローディングによりパフォーマンスが圧倒的に向上するため、データからインサイトを迅速に導き出し、リアルタイムで重要な意思決定を下すことができます。人間による介入がごくわずかであるため、ヒューマン・エラーをほぼ解消することができ、セキュリティ侵害や機能停止も、そしてコストも最小限に抑えられるという、素晴らしい可能性が示唆されています。Autonomous Data Warehouseは、既存のオンプレミスのマートやデータウェアハウス、アプリケーションを実行する、最新のOracle Databaseのソフトウェアおよびテクノロジーに合わせて構築されているため、既存のデータウェアハウスやデータ統合、BIツールとの互換性が確保されています。 データウェアハウスの移行を戦略的に計画 以下に、Amazon Redshiftのオンデマンドの移行にも、手動での移行を後日実行するようスケジュールするためのスクリプトの作成にも対応できるワークフローを紹介します。 SQL DeveloperのMigration Assistantを使用して、Amazon Redshift(移行元)とOracle Autonomous Data Warehouse(移行先)の両方への接続を確立します。 SQL Developer 18.3またはそれ以降のバージョンをダウンロードします。これはクライアント・アプリケーションで、WindowsかMac OSXかに関係なく、ワークステーションやノートパソコンにインストールできます。このブログではMicrosoft Windowsで実行します。Amazon Redshiftの環境にアクセスするため、Amazon Redshift JDBCドライバをダウンロードします。 SQL Developerアプリケーションを開き、サード・パーティのドライバとしてRedshift JDBCドライバを追加します(ツール → プリファレンス → データベース → サード・パーティJDBCドライバ)。 「接続」パネルにてAmazon Redshiftデータベースへの接続を追加して新しい接続を作成し、「Amazon Redshift」タブを選択して、Amazon Redshiftの接続情報を入力します。 ヒント: 複数のスキーマを移行する場合は、マスター・ユーザー名にてAmazon Redshiftインスタンスに接続することをお薦めします。 仮想プライベート・クラウド(VPC)内にAmazon Redshift環境を適用している場合は、インターネットからクラスタにアクセスできることを確認する必要があります。公開インターネット・アクセスを可能にするための詳細については、こちらを参照してください。 長時間の問合せを実行中に、データベースへのAmazon Redshiftのクライアント接続がハングしたり、タイムアウトになったりしたように見える場合は、こちらに記載されているソリューション案を参照してください。   「接続」パネルにてOracle Autonomous Data Warehouseへの接続を追加して新しい接続を作成し、「Oracle」タブを選択して、接続情報とウォレット情報を入力します。Autonomous Data Warehouseをまだプロビジョニングしていない場合は、すぐにこれを実施してください。簡単にスタートするためのステップは、こちらを参照してください。無料トライアルのアカウントで始めることもできます。 これらを保存する前に、RedshiftとAutonomous Data Warehouseの両方の接続をテストします。 2.スキーマのキャプチャ/マップ:SQL Developerの「ツール」メニューからクラウド移行ウィザードを起動して、移行元データベース(Amazon Redshift)からメタデータのスキーマと表をキャプチャします。 まず、接続プロファイルからAWS Redshiftに接続し、移行する必要のあるスキーマを指定します。スキーマにあるすべてのオブジェクト(おもに表)が移行されます。データを移行するオプションもあります。Autonomous Data Warehouseへの移行は、スキーマ単位で行われます。スキーマ名を移行の一環として変更することはできません。 注:データを移行する際は、AWSアクセス・キー、AWS秘密アクセス・キー、Redshiftデータをアンロード[KI1] およびステージングする既存のS3バケットURIを指定する必要があります。セキュリティ資格証明には、S3にデータを格納するための権限が必要です。可能なら、移行用の個別のアクセス・キーを新しく作成することをお薦めします。後でセキュアなRESTリクエストにてAutonomous Data Warehouseにデータをロードする際に、同じアクセス・キーを使用します。 たとえばURIをhttps://s3-us-west-2.amazonaws.com/my_bucketのように指定すると、 移行アシスタントによって、バケット「my_bucket」に「oracle_schema_name/oracle_table_name」というフォルダが作成されます。 "https://s3-us-west 2.amazonaws.com/my_bucket/oracle_schema_name/oracle_table_name/*.gz" RedshiftのデータタイプがOracleのデータタイプにマップされます。同様に、Redshiftのオブジェクト名がOracleネーミング規則に基づいてOracle名に変換されます。Redshift関数を使用する列のデフォルトは、Oracleの同等の機能に置き換えられます。 3.スキーマの生成:接続プロファイルからAutonomous Data Warehouseに接続します。なお、この接続はスキーマとオブジェクトを作成するために移行全体で使用されるため、ユーザーには管理者権限が必要です。Autonomous Data Warehouseで作成される移行レポジトリのパスワードを入力します。このレポジトリは、移行完了後に削除することができます。移行に必要な生成済スクリプトを格納するための、ローカル・システムのディレクトリを指定します。すぐに移行を開始する場合は、「今すぐ移行」を選択します。 フォーマットのオプション、データをロードする際に有効化するパラレル・スレッド、移行時の拒否制限(拒否する行数のこと。この行数に達するとエラーが発生します)を制御するには、「拡張設定」を使用します。 サマリーを確認し、「終了」をクリックします。即時移行を選択した場合、移行が完了するまで移行ウィザードは開かれたままになります。即時移行を選択しなかった場合、必要なスクリプトが指定したローカル・ディレクトリに生成されるのみで、スクリプトは実行されません。 ローカル・ディレクトリに移行スクリプトを生成することを選択した場合は、次のステップに進みます。 データのステージング:アクセス資格証明および移行ウィザードのワークフローで指定したS3バケットを使用して、Redshiftの表からデータをアンロードし、そのデータをAmazon Storage S3に格納する(ステージング)には、Amazon Redshift環境に接続して、redshift_s3unload.sqlを実行します。  移行先スキーマのデプロイ:生成したスキーマとAmazon Redshiftから変換したDDLをデプロイするには、権限を持つユーザー(ADMINなど)としてAutonomous Data Warehouseに接続し、adwc_ddl.sqlを実行します。 データのコピー:Autonomous Data Warehouseに接続されている間に、adwc_dataload.sqlを実行します。このスクリプトには、S3からAutonomous Data Warehouseにデータをロードするために必要なすべてのロード・コマンドが含まれています。 移行結果の確認:移行タスクではローカル・ディレクトリに3つのファイル(MigrationResults.log、readme.txt、redshift_migration_reportxxx.txt)が作成されます。それぞれのファイルには、移行のステータスに関する情報が入っています。 問合せをいくつかテストし、Amazon Redshiftからすべてのデータが移行されていることを確認します。Oracle Autonomous Data Warehouseでは、さまざまなクライアント・アプリケーションからの接続をサポートしています。接続して、それらをテストしてみましょう。 まとめ 優れた柔軟性、インフラストラクチャ・コストの削減、オペレーション・オーバーヘッドの縮小など、Oracle Autonomous Data Warehouseには数々の優れたメリットがあります。こうしたOracleならではの価値は、インフラストラクチャ・サービス、プラットフォーム・サービス、アプリケーションといった各レイヤーからもたらされるインテリジェンスを活用できる、オラクルの総合的なクラウド・ポートフォリオから創出されています。オラクルにとって、オートノマス(自律型)エンタープライズとは、自動化されたリアクションに基づいてマシンがアクションに反応するような単なる自動化の枠を超えたものであり、応用された機械学習に基づき、完全な自律を可能にし、ヒューマン・エラーを排除し、これまでにないパフォーマンス、高度なセキュリティ、信頼性をクラウドにて実現するものです。   AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。 Cloudをまだお試しでない方は、無料トライアルをご利用下さい。   ※本記事は、Kiran Makarla (Marketing Director, Autonomous Databases) による”Migrate from Amazon Redshift to Oracle Autonomous Data Warehouse in 7 easy steps “を翻訳したものです。

  このブログでは、SQL DeveloperのAmazon Redshift Migration Assistantを使用して、既存のAmazon RedshiftをOracle Autonomous Data Warehouse(ADW) に移行する方法を簡単に説明致します。 しかしまずは、なぜAutonomous Data Warehouseへの移行が必要なのかをお話ししましょう。   アナリティ...

津島博士のパフォーマンス講座 第73回 オプティマイザ統計アドバイザについて

津島博士のパフォーマンス講座 indexページ▶▶  皆さんこんにちは、今年も残暑が厳しかったのですが、やっと過ごしやすい気候になってきましたね。 今回は、オプティマイザ統計を正しく収集できていないため、性能問題になっているシステムがまだ多いようですので、「Oracle Databaseにおけるオプティマイザ統計収集のベスト・プラクティス」を実施できるように、Oracle Database 12cR2(Oracle12cR2)から提供されたオプティマイザ統計アドバイザについて説明しますので、参考にしてください。 1. オプティマイザ統計アドバイザのコンポーネント オプティマイザ統計は、より効果的(短時間で正確)な収集ができるよう継続的に強化を行っています。ただし、その強化を見落としている方、オプティマイザ統計の収集方法を誤解している方がまだ多いようです。そのため、現状の収集方法を診断してくれるオプティマイザ統計アドバイザのコンポーネントから説明します。 (1)アドバイザ・ルール まずは、オプティマイザ統計アドバイザで最も重要なアドバイザ・ルールについて説明します。 アドバイザ・ルールは、統計アドバイザがベスト・プラクティスをチェックするために、Oracleから提供される標準になります。そのため、ベスト・プラクティスが変更された場合、アドバイザ・ルールも変更されます(現在は、23個のルールが提供されていて、V$STATS_ADVISOR_RULESビューで確認できます)。このルールは、以下のクラスに分類されていて、ユーザーの権限によって確認するルールやオブジェクトが異なります。 SYSTEM(1~6) このクラスは、統計収集のプリファレンス、自動統計収集ジョブのステータス、SQL計画ディレクティブの使用などを確認します。ANALYZE ANYとANALYZE ANY DICTIONARYの権限を持つユーザーが実行できます。 OPERATION(7~10) このクラスは、統計収集操作に対するルールで、デフォルトを使用しているか、SET_%_STATSプロシージャ(ユーザー定義の統計設定)を使用して作成されているかなどを確認します。これもANALYZE ANYとANALYZE ANY DICTIONARYの権限を持つユーザーが、すべてのスキーマの操作に実行できます(ANALYZE ANY DICTIONARY権限のないユーザーはSYS以外のすべてのスキーマ、ANALYZE ANY権限のないユーザーはSYSと自身のスキーマ、両方の権限のないユーザーは自身のスキーマのみになります)。 OBJECT(11~23) このクラスは、オブジェクトに対するルールで、統計の品質、統計の失効、統計の不要な収集などを確認します。統計収集権限を持つすべてのオブジェクトに実行できます。 それぞれのルールが分かりやすいように、以下に簡単な説明を記述しておきます。 ID NAME (DESCRIPTION) 説明 1 UseAutoJob (Use Auto Job for Statistics Collection) 自動統計収集ジョブを使用してください(特別な場合は手動で管理できますが、自動統計収集ジョブが推奨です) 2 CompleteAutoJob (Auto Statistics Gather Job should complete successfully) 自動統計収集ジョブ実行が失敗しています(アドバイザは推定原因を検出します) 3 MaintainStatsHistory (Maintain Statistics History) 統計履歴はリグレッションの場合に有効なので、正しく格納できるようにしてください(保存期間が大き過ぎず、パージが発生するかSYSAUXが拡張するかの確認) 4 UseConcurrent (Use Concurrent preference for Statistics Collection) 統計収集の実行が速いほど収集できる統計は多くなるので、すべてのリソースを使用できるように、Concurrentプリファレンスを使用してください 5 UseDefaultPreference (Use Default Preference for Stats Collection) グローバル・プリファレンスのデフォルトは、ほとんどの場合に最適だと考えられたものなので、デフォルト設定を使用してください 6 TurnOnSQLPlanDirective (SQL Plan Directives should not be disabled) SQL計画ディレクティブを無効にしないでください(これはデフォルトが無効になる前に導入されたものです) 7 AvoidSetProcedures (Avoid Set Statistics Procedures) ユーザー定義の統計設定(Set Statisticsプロシージャ)を回避策として使用している場合がありますが、一般的な方法ではないので避けてください 8 UseDefaultParams (Use Default Parameters in Statistics Collection Procedures) デフォルト・パラメータは、ほとんどの場合に最適だと考えられたものなので、統計収集はデフォルト値を使用してください 9 UseGatherSchemaStats (Use gather_schema_stats procedure) スキーマに対して実行して(gather_schema_statsプロシージャを使用して)、新しく作成したテーブルを確実に含めるようにしてください 10 AvoidInefficientStatsOprSeq (Avoid inefficient statistics operation sequences) 非効率的な統計収集(オンライン統計収集が行われている表に対する手動での統計収集)を避けてください 11 AvoidUnnecessaryStatsCollection (Avoid unnecessary statistics collection) 不要な統計収集(何も変わっていないときの統計収集)を避けてください 12 AvoidStaleStats (Avoid objects with stale or no statistics) 古くなった統計や統計のないオブジェクトを避けてください(全テーブルの統計が必要です) 13 GatherStatsAfterBulkDML (Do not gather statistics right before bulk DML) バルクDMLの直前に統計を収集しないでください(バルク挿入前に収集した統計はすぐに古くなります) 14 LockVolatileTable (Statistics for objects with volatile data should be locked) 揮発性データを持つオブジェクト(TRUNCATEと挿入の間のテーブル)で自動統計収集を実行したくない場合、そのオブジェクトの統計はロックしてください 15 UnlockNonVolatileTable (Statistics for objects with non-volatile should not be locked) 不揮発性のオブジェクトの統計はロックしないでください(しかし、大きな変更がないテーブルに対してはロックするのは良いことです) 16 MaintainStatsConsistency (Statistics of dependent objects should be consistent) 従属オブジェクトの統計は一貫するようにしてください 17 AvoidDropRecreate (Avoid drop and recreate object seqauences) テーブルを削除して再作成するよりも、TRUNCATEとIndex Unusableのダイレクト・パス・インサートをしてください(統計が削除されません) 18 UseIncremental (Statistics should be maintained incrementally when it is beneficial) 有益な場合は、増分統計収集を行ってください(統計アドバイザは、パーティション表に対して増分統計収集が効率的であることを検出します) 19 NotUseIncremental (Statistics should not be maintained incrementally when it is not beneficial) 有益でない場合は、増分統計収集を行わないでください 20 AvoidOutOfRange (Avoid Out of Range Histogram endpoints) 範囲外(古い統計)は過小見積りにつながる可能性があるので、避けてください 21 UseAutoDegree (Use Auto Degree for statistics collection) 大きなテーブルはパラレル・スキャンすることができるので、統計収集に自動パラレル度を使用してください(デフォルトのパラレル度が推奨) 22 UseDefaultObjectPreference (Use Default Object Preference for statistics collection) 統計収集にデフォルトのオブジェクト・プリファレンスを使用してください(表プリファレンスは、グローバル・プリファレンスより優先順位が高いので、これもデフォルト設定を使用してください) 23 AvoidAnalyzeTable (Avoid using analyze table commands for statistics collection) dbms_statsは、より確実にオプティマイザ統計を収集できるので、analyze tableコマンドを使用しないでください   (2)その他のコンポーネント 次に、その他のコンポーネントとして結果、推奨事項、アクションについて説明します。 アドバイザ結果 オプティマイザ統計アドバイザがデータベースに格納されている統計内容(データ・ディクショナリ上の統計履歴、統計操作ログ、SYSAUXに存在する現在の統計フットプリント)を分析し、ルールに従っていないと判断すると、アドバイザ結果が生成されます。オブジェクト失効などの一部の結果では情報のみを提供します。 アドバイザ推奨事項 各アドバイザ結果に基づいて、優れた統計の実現方法に関する推奨事項を生成します。例えば、統計収集時のサンプリング・ルール違反を検出すると、AUTO_SAMPLE_SIZEの指定を推奨します。また、単一の結果に複数の推奨事項が存在する場合、従う推奨事項を調査して決定する必要があります。各推奨事項には、理論的根拠(生成理由の説明)も含まれますが、結果によって生成されない可能性があります アドバイザ・アクション アドバイザ・アクションは、推奨事項を実装するSQLまたはPL/SQLスクリプトで、実行が可能な場合に含まれます。 このように、オプティマイザ統計収集の様々なことを分析してくれるので、まずは診断レベルからでも使用してみてください。 2. オプティマイザ統計アドバイザの基本タスク ここでは、オプティマイザ統計アドバイザを実行するための基本タスクについて説明します。 オプティマイザ統計アドバイザは、自動および手動タスク・モードをサポートしており、それぞれのモードの以下の基本タスクと関連する機能について説明していきます。 自動アドバイザ・タスク アドバイザ・レポートの生成 アドバイザ推奨事項の実装 手動タスクの作成と実行 アドバイザのフィルター機能 統計プリファレンスのオーバーライド機能   (1)自動アドバイザ・タスク 自動アドバイザ・タスクは、メンテナンス・ウィンドウの自動オプティマイザ統計収集ジョブの一部として、事前定義されたタスク'AUTO_STATS_ADVISOR_TASK'が自動的に実行されます。自動タスクは、結果および推奨事項を生成しますが、自動的にアクションまでは実装しません。そのため、アドバイザ・レポートを出力して、推奨事項が存在している場合、アクションを手動で実装する必要があります。以下のSQLで、自動タスクの実行状態を表示して、出力するレポートのEXECUTION_NAME(タスクの実行名)を確認できます。 SQL> SELECT task_name,execution_name,execution_start,execution_end,execution_type,status 2 FROM dba_advisor_executions 3 WHERE task_name = 'AUTO_STATS_ADVISOR_TASK' AND execution_end >= SYSDATE-2 ORDER BY 3; TASK_NAME EXECUTION_NAME EXECUTION_START EXECUTION_END EXECUTION_TYPE STATUS ------------------------ -------------- ------------------- ------------------- -------------- --------- AUTO_STATS_ADVISOR_TASK EXEC_42 2017/08/23 23:00:15 2017/08/23 23:00:20 STATISTICS COMPLETED AUTO_STATS_ADVISOR_TASK EXEC_52 2017/08/24 23:00:27 2017/08/24 23:00:40 STATISTICS COMPLETED   (2)アドバイザ・レポートの生成 オプティマイザ統計アドバイザは、通常のアドバイザ・フレームワークを使用するため、アドバイザの実行結果はDBA_ADVISOR_%ビューなどで表示できますが、統計アドバイザ・レポート(DBMS_STATSパッケージのREPORT_ADVISOR_TASKファンクション)が提供されているので、これを使用して生成します。オプションでEXECUTION_NAME(タスクの実行名)、TYPE(レポート・タイプ)、SECTION(レポート内のセクション)、LEVEL(レポート形式)パラメータを受け入れますが、通常はデフォルト値で問題ないと思います。以下のSQLは、自動アドバイザ・タスクに関するデフォルト・レポート(最新の実行名、TEXTタイプ、全てのセクション、TYPECAL形式)を表示します。 SQL> SET LINESIZE 200 SQL> SET LONG 1000000 SQL> SET PAGESIZE 0 SQL> SET LONGCHUNKSIZE 100000 SQL> SELECT dbms_stats.REPORT_ADVISOR_TASK('AUTO_STATS_ADVISOR_TASK') AS REPORT FROM dual;   デフォルト・セクション(ALL)では、アドバイザ・レポートに次のセクションが含まれています。 一般情報:GENERAL INFORMATION(タスク名、実行名、作成日および変更日) サマリー:SUMMARY(アドバイザ結果と違反するルールのまとめ) 結果:FINDINGS(各関連するルールと結果、その推奨事項)   以下のアドバイザ・レポートは、3つの結果が示されている例になります(ここでは1つのみ表示しています)。表示されているのは、UseDefaultParamsルールに対する推奨事項「統計収集はデフォルト・パラメータを使用してください」です。 GENERAL INFORMATION ------------------------------------------------------------------------------- Task Name : AUTO_STATS_ADVISOR_TASK Execution Name : EXEC_136 Created : 09-05-16 02:52:34 Last Modified : 09-05-16 12:31:24 ------------------------------------------------------------------------------- SUMMARY ------------------------------------------------------------------------------- For execution EXEC_136 of task AUTO_STATS_ADVISOR_TASK, the Statistics Advisor has 3 findings. The findings are related to the following rules: USEDEFAULTPARAMS, USEGATHERSCHEMASTATS, NOTUSEINCREMENTAL. Please refer to the finding section for detailed information. ------------------------------------------------------------------------------- FINDINGS ------------------------------------------------------------------------------- Rule Name: UseDefaultParams Rule Description: Use Default Parameters in Statistics Collection Procedures Finding: There are 367 statistics operations using nondefault parameters. Recommendation: Use default parameters for statistics operations. Example: -- Gathering statistics for 'SH' schema using all default parameter values: BEGIN dbms_stats.gather_schema_stats('SH'); END; Rationale: Using default parameter values for statistics gathering operations is more efficient. -------------------------------------------------------------------------------   (3)アドバイザ推奨事項の実装 アドバイザの推奨事項は、DBMS_STATSパッケージのIMPLEMENT_ADVISOR_TASKファンクションを使用して、すべてを自動的に実装することができます。以下のスクリプトは、自動タスクの最新の実行に関する推奨事項のすべてを実装して、その結果を表示します。 VARIABLE v_result CLOB DECLARE l_task_name VARCHAR2(32767) := 'AUTO_STATS_ADVISOR_TASK'; -- 自動タスク名; BEGIN :v_result := dbms_stats.IMPLEMENT_ADVISOR_TASK(task_name => l_task_name); END; / SET LONG 10000 SELECT XMLTYPE(:v_result) AS results FROM dual;   また、DBMS_STATSパッケージのSCRIPT_ADVISOR_TASKファンクションを使用して、アドバイザの推奨事項をスクリプトに変換して、編集してから実行することもできます(単一の結果に複数の推奨事項が存在する場合はこれを使用してください)。 (4)手動タスクの作成と実行 自動タスク以外に、固有のアドバイザ・タスクを作成して、いつでも実行することができます。DBMS_STATSパッケージのCREATE_ADVISOR_TASKファンクションとEXECUTE_ADVISOR_TASKファンクションを使用して、以下のようにアドバイザ・タスクの作成と実行を行います。オプションでTASK_NAMEとEXECUTION_NAMEパラメータを受け入れますが、指定されていない場合システム生成の名前が作成されます。 DECLARE L_task_name VARCHAR2(32767) := 'demo'; -- タスク名 BEGIN L_ask_tname := dbms_stats.CREATE_ADVISOR_TASK((task_name => l_task_name); END; / DECLARE L_task_name VARCHAR2(32767) := 'demo'; -- タスク名 L_exec_name VARCHAR2(32767) := NULL; -- 実行名 BEGIN L_exec_name := dbms_stats.EXECUTE_ADVISOR_TASK((task_name => l_task_name); END; /   手動タスクも自動タスクと同じように、このタスクに関連するレポートを生成してから、推奨事項が存在する場合にアクションを実装します。 (5)アドバイザのフィルター機能 次に、アドバイザ・タスクに対するフィルター指定ついて説明します。 アドバイザ・タスクは、いくつかのフィルターによって対象を絞り込むことが可能です。アドバイザの範囲は、以下の3種類のフィルター・ファンクションによって指定します(STATS_ADV_OPR_TYPEパラメータで、フィルターを適用するアドバイザ操作タイプも指定でき、NULLですべての操作タイプに適用されます)。 CONFIGURE_ADVISOR_OBJ_FILTER(オブジェクト・フィルター) このプロシージャを使用して、指定されたデータベース・スキーマまたはオブジェクトを含めるか、または除外します。オブジェクト・フィルターは、サポートされているワイルドカード(%)を使用して、所有者名およびオブジェクト名を指定できます。 CONFIGURE_ADVISOR_RULE_FILTER(ルール・フィルター) このプロシージャは、「(1)アドバイザ・ルール」で説明したルール名(NAME)を含めるか、または除外するかを指定します。 CONFIGURE_ADVISOR_OPR_FILTER(オペレーション・フィルター) このプロシージャは、指定されたDBMS_STATS操作(DBMS_STATSのプロシージャ)を含めるか、または除外するかを指定します。操作のIDと名前は、DBA_OPTSTAT_OPERATIONSビューから取得できます。   以下は、特定のオブジェクト(SHスキーマのCOUNTRIES表)を除外する例になります。 -- Turn off validation/reporting… for table SH.COUNTRIES DECLARE tname VARCHAR2(32767) := 'demo'; -- タスク名 filter_report clob; -- report of operation BEGIN filter_report := dbms_stats.CONFIGURE_ADVISOR_OBJ_FILTER(tname, NULL, NULL,'SH','COUNTRIES', 'DISABLE'); END; /   (6)統計プリファレンスのオーバーライド機能 最後に、統計プリファレンス・パラメータのオーバーライドについて説明します。 オプティマイザ統計アドバイザが、収集時のパラメータ入力値を変更するようにアドバイしても、いろいろな場所で統計収集していると簡単ではありません。そのため、Oracle12cR2からの統計プリファレンス・パラメータPREFERENCE_OVERRIDES_PARAMETERで、統計収集時にパラメータ入力値のオーバーライドを指定できるようになりました。これにより、データベースが統計収集プロシージャで指定したパラメータ値に従うかどうか制御できるので、アドバイザの推奨値で強制的に収集することが可能になります。つまり、パラメータが設定される優先順位が以下のようになります。 PREFERENCE_OVERRIDES_PARAMETERがFALSE(デフォルト)に設定されている場合の優先順位 統計収集(GATHER_%_STATS)プロシージャのパラメータ 表プリファレンス(特定の表、スキーマ内のすべての表、またはデータベース内のすべての表に設定) グローバル・レベルのプリファレンス(dbms_stats.SET_GLOBAL_PREFSプロシージャ) PREFERENCE_OVERRIDES_PARAMETERがTRUEに設定されている場合の優先順位 表プリファレンス(特定の表、スキーマ内のすべての表、またはデータベース内のすべての表に設定) グローバル・レベルのプリファレンス(dbms_stats.SET_GLOBAL_PREFSプロシージャ) 統計収集(GATHER_%_STATS)プロシージャのパラメータ   3. おわりに 今回は、オプティマイザ統計アドバイザについて説明しましたが、少しは参考になりましたでしょうか。これからも頑張りますのでよろしくお願いします。 それでは、次回まで、ごきげんよう。 津島博士のパフォーマンス講座 indexページ▶▶ 

津島博士のパフォーマンス講座 indexページ▶▶  皆さんこんにちは、今年も残暑が厳しかったのですが、やっと過ごしやすい気候になってきましたね。今回は、オプティマイザ統計を正しく収集できていないため、性能問題になっているシステムがまだ多いようですので、「Oracle Databaseにおけるオプティマイザ統計収集のベスト・プラクティス」を実施できるように、Oracle...

津島博士のパフォーマンス講座

はじめまして。本日からこの連載を始めます津島と申します。 長年に渡りデータベースの構築やパフォーマンスチューニングなどに従事し、最近では若手エンジニアの育成および大規模データベース案件などの支援に従事しております。今までの経験が少しでもお役に立てればと思い、この連載を始めることにいたしました。できるだけ長く続けたいと思いますのでよろしくお願いいたします。 Oracle Databaseは、技術の進化により非常に扱いやすくなったと思います。私自身も昔のバージョンを使用したころに比べると非常に楽になったと感じています。いろいろと進化したとはいえパフォーマンス問題が発生しなくなった訳ではありません。今でも多くの担当者が色々と苦労していると思います。その中でスキルや機能を知らずに苦労している場合もあるように思いますので、ここで紹介していけたらと考えています。 この連載では、このようなOracle技術者(データベース技術者)の方へのアドバイスとして様々なパフォーマンス問題を題材に解説していこうと考えています。既にデータベース運用を行っている管理者、これから管理者を目指す方までを対象に、様々な疑問に対して少しでも何かの手助けになればと願っています。   【津島博士の質問コーナー】 津島博士が連載記事の内容について読者の皆様からいただいたご質問にできるだけお答えします。 また、記事の感想や今後取り上げて欲しい内容などのご要望もお聞かせ下さい。お待ちしております。 QAページを見る 津島博士へのご質問方法 こちらのフォームからお願いします。 "お問い合わせ内容”欄に"津島博士の記事について”と、該当する記事の号数またはURLを必ず記載してください。   【最新記事】 第74回 パラレル実行とリソース管理について  皆さん、明けましておめでとうございます。今年も素敵な一年になりますようお祈り申し上げます。 今回は、苦労されている方も多い、パラレル実行と同時実行のリソース管理について説明しようと思います。後半に、これが簡単に利用できるようになっているOracle Autonomous Databaseについても説明していますので、参考にしてください。   第1回 パフォーマンス問題はなぜ起きるのか 2011.01.19公開 第2回 RAC(Real Application Clusters)の時のバッチ処理について 2011.02.02公開 第3回 Statspackから探る、パフォーマンス問題の原因特定方法 2011.02.16公開 第4回 パフォーマンスFAQ:良く聞かれる疑問点にお答えします 2011.03.02公開 第5回 オプティマイザとオプティマイザ統計の収集について 2011.04.06公開 第6回 パフォーマンスの基礎である索引について 2011.04.20公開 第7回 共有プールについて 2011.06.22公開 第8回 断片化について 2011.07.22公開 第9回 良いSQLについて 2011.08.31公開 第10回 パーティションについて 2011.09.14公開 第11回 良いSQLについて(2) 2011.10.26公開 第12回 I/O周りについて 2011.11.24公開 第13回 キャッシュ周りについて 2011.12.14公開 第14回 メモリ・チューニングについて 2012.01.24公開 第15回 バッチ処理について 2012.02.23公開 第16回 バックアップについて 2012.03.27公開 第17回 チューニングについて 2012.04.24公開 第18回 ロックについて 2012.04.24公開 第19回 UNDOデータとREDOログについて 2012.08.23公開 第20回 パラレル実行について 2012.08.28公開 第21回 索引について(2) 2012.09.26公開 第22回 パーティションについて(2) 2012.11.02公開 第23回 共有サーバー構成について 第24回 良いSQLについて(3) 第25回 良いSQLについて(4) 第26回 I/O周りについて(2) 第27回 オプティマイザとオプティマイザ統計の収集について(2) 第28回 表圧縮とLOBデータ型について 第29回 表結合とSQL自動変換について 第30回 UPDATEについて 第31回 再帰的問合せについて 第32回 SQL統計と実行計画の出力について 第33回 オプティマイザ統計の運用について 第34回 索引スキャンとSQL自動変換について 第35回 オプティマイザ統計の運用について(2) 第36回 遅くなるSQLについて 第37回 新しいSQLについて 第38回 SQLチューニングについて 第39回 パラレル実行について(2) 第40回 パラレル実行について(3) 第41回 SQL*Plusについて 第42回 SQL自動変換について(3) 第43回 パーティションについて(3) 第44回 SQL自動変換の注意点について 第45回 TEMP領域について 第46回 パーティション・プルーニングとハッシュ結合について 第47回 自己結合と分析ファンクションについて 第48回 分析ファンクションについて(2) 第49回 オプティマイザ統計の列統計とBツリー索引の圧縮について 第50回 SQL*Loader/外部表とライブラリ・キャッシュの待機について 第51回 SQL翻訳フレームワークについて 第52回 OR条件の続きとSQL計画ディレクティブの使用について 第53回 Oracle Database In-Memoryについて 第54回 Oracle Database In-Memoryについて(2) 第55回 オプティマイザ・ヒントについて 第56回 分析ファンクションのパラレル実行について 第57回 適応問合せ最適化について 第58回 Oracle Database In-Memoryについて(3) 第59回 パラレル実行の注意点と集合演算子について 第60回 Oracle Database 12cR2で強化されたSQL処理について 第61回 Oracle Database 12cR2のOracle Database In-Memoryについて 第62回 Oracle Database 12cR2のSQL*Plusについて 第63回 Oracle Database 12cR2のオプティマイザについて 第64回 複雑な表結合とSQL自動変換について 第65回 Oracle Database 12cR2のパーティションについて   第66回 パーティションのまとめとして  第67回 AWRの分析について  第68回 TEMP領域の続きとA-Rowsについて 第69回 Oracle Exadata Database Machineについて  第70回 マテリアライズド・ビューについて  第71回 マテリアライズド・ビューについて(2)  第72回 SQLパッチとヒント使用状況レポートについて 第73回 オプティマイザ統計アドバイザについて 第74回 パラレル実行とリソース管理について 番外編 津島博士のクイズ大会 第1弾 設問と回答 番外編 津島博士のクイズ大会 第2弾 設問と回答 【津島博士のビデオ講座】   津島博士のパフォーマンス講座「最新のチューニング手法」 昨年の「なぜ起きるのか」に続き、「どのようにチューニングするのか」について話します。 連載「パフォーマンス講座」では、あまり説明できていない効果的に行うためのチューニングの考え方、ツールの活用方法などを中心に解説します。 MP4 / WMV / プレゼン資料  

はじめまして。本日からこの連載を始めます津島と申します。 長年に渡りデータベースの構築やパフォーマンスチューニングなどに従事し、最近では若手エンジニアの育成および大規模データベース案件などの支援に従事しております。今までの経験が少しでもお役に立てればと思い、この連載を始めることにいたしました。できるだけ長く続けたいと思いますのでよろしくお願いいたします。Oracle Databaseは、技術の進化によ...

もしもみなみんがDBをクラウドで動かしてみたら 第14回 Oracle Cloud Infrastructure Database を使ってみよう 2019.8.28公開

もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶ ※本記事は2019/8時点のものになります   みなさん、こんにちは。 先日、Oracle Cloud Infrastructure (以降、OCI) Database – Virtual Machine(以降、VM) でも、Oracle Database 19cが利用可能になりました! これで、OCI Database-VMでもOracle Database 19cの環境を簡単に構築できるようになったので、今回はOCI Database –VM について解説していきます。 なお、先日開催したModern Cloud Day Tokyo (2019/8/6-2019/8/7)の資料も公開されています。 本連載に関連するものをいくつかピックアップしましたので、ぜひこちらも見てみてください。 [講演資料] Oracle Database 19c テクノロジーの全貌PDF オラクルクラウド移行を完了したゲストに聞Oracle Cloudを選択する理由&次世代インフラ/データベースクラウド最新情報PDF OracleCloud上での高可用性データベースのベストプラクティスと使ってわかった本当の実力PDF 次世代型データベース・クラウドの魅力に迫る ~ Autonomous Database Deep Dive ~PDF [ハンズオン資料] Oracle Autonomous Data WarehouseでデータドリブンをはじめようPDF Autonomous なデータベースを体験しよう Autonomous Database Hands-OnPDF ■1. OCI Database – VMはどんなサービス? OCI上でOracle Databaseを使えるサービスはいくつかありますが、違いについては第9回で解説しましたね。 今回は、その中の一つのOCI Database – VMについて紹介します。 OCI Database には、共有型として仮想マシン環境で利用するVirtual Machineと専有型で利用できるBare Metalのタイプがあります。(共有型と専有型の違いは、『Oracle Cloud Infrastructure Database –Oracle Databaseのサービス比較編』で詳しく説明しています) 今回のテーマのOCI Database-VMは、次の特徴があります。 4つのエディション : エディションによって利用可能なデータベースの機能が変わる 6つのシェイプ : OCPUはコンピュートあたり 1-24、メモリは15-320GB (2ノードRACの場合は倍) データベースのクラスタリング機能、Oracle Real Application Clusters(以降、RAC)が利用可能 データベースの複製機能、Oracle Active Data Guard/Data Guard構成を自動で構築可能 データベースに最適化されたバックアップ・リカバリ機能、Oracle Recovery Managerでの自動バックアップを設定可能 OSより上はユーザー管理 (OSログイン可能、root(sudo)権限あり)   ■2. OCI Database –VM を作ってみよう! - 事前準備 まずは、OCI Database-VMのマニュアルがどこにあるか、確認しましょう。 ・ 日本語 Oracle Cloud Infrastructure マニュアル> サービス> Database > ベア・メタルおよび仮想マシンのDBシステム ・ 英語 Oracle Cloud Infrastructure Manual > Service > Database >Bare Metal and Virtual Machine DB Systems 次に、OCI Database-VMで利用するシェイプについて。シェイプ毎に、コンピュートあたりのコア数/メモリ/ネットワーク帯域が決まっています。 ・ マニュアル Oracle Cloud Infrastructure Documentation > データベース > ベア・メタルおよび仮想マシンDBシステム > 仮想マシンDBシステム そして、OCI Database-VMの前提条件を確認しましょう! 利用したいリージョンとサービスの利用(サービス・リミット)が可能かを確認 OSログインに利用するSSH鍵認証の公開鍵を用意 コンパートメント、仮想クラウド・ネットワーク(VCN)、クライアントネットワークに利用するサブネットを用意 自動バックアップを有効化する場合やパッチ適用機能を利用する場合、オブジェクト・ストレージへアクセスできる状態 RAC構成を利用する場合、利用するサブネット上のイングレス/エグレスでポート22はオープンでセキュリティ・ルールがステートフル(デフォルト)な状態 ・ マニュアル Oracle Cloud Infrastructure Documentation > データベース > ベア・メタルおよび仮想マシンDBシステム > DBシステムの管理 > 前提条件 ■3. OCI Database –VM を作ってみよう! OCI Database –VMを作成する際に、選択・入力する項目は多く分けて2つです。 まずは、①DBシステム全体に関する情報(オレンジ枠)、次に②DBに関する情報(赤枠)の順で情報を入れていきます。 作成の流れは下記の資料に書いているので、本記事では作成・使うにあたっての解説をしていきます。 OCI Database –VM の作り方     3.1 DBシステム情報 DBシステムの情報として入力していく項目は、下記のようなものがあります。 コンパートメントの選択 : 事前に作成済のコンパートメントを指定 DBシステムの名前の指定 : 任意のシステム名 可用性ドメインの選択 : 可用性ドメイン(AD)の指定。(Tokyo Regionは1つなのでAD-1) シェイプ・タイプの選択 : 『仮想マシン』を選択 シェイプの選択 : シェイプの選択 DBシステムの構成 : 合計ノード数とOracle Database ソフトウェア・エディションの選択 ストレージの構成 : 「使用可能なストレージ(GB)」にDBのデータ領域として利用するサイズを指定 公開SSHキーの追加 : OSログイン時に利用する公開鍵をアップロードもしくは入力 ライセンス・タイプの選択 : ライセンス込みもしくはライセンス持ち込み(BYOL)を選択 ネットワーク情報の指定 : 仮想クラウド・ネットワーク(VCN)とサブネットを指定し、ホスト名などを指定 Advanced Option : フォルト・ドメインとタグを指定可能   DBシステムの情報についての補足説明 ここで、シェイプ/ノード数/エディション/ストレージ構成について、少し掘り下げてみましょう! ・シェイプの選択とDBシステムの構成 『シェイプの変更』をクリックすると、シェイプごとのコア数(最大/最小)とノード数(最大/最小)が表示されています。シェイプ名の末尾の数字は、コア数(OCPU)を指しているのでわかりやすいですね。 ここで、上記の図のノード数に注目してみましょう。 OCI-Databaseの作成画面では、RAC構成にしたいときにはノード数を2つにするとRAC構成になります。VM.Standard2.1だけ最大ノード数が1なのは、RAC構成の場合はシェイプがVM.Standard2.2以上である必要があるためです。そのため、例えばVM.Standard2.1を選択していると、下記の図のようにノード数の選択ボタンはグレーアウトしてしまいます。 なので、RAC環境にしたい場合は”シェイプでVM.Standard2.2以上を選択してノード数を2”にしましょう。 次はエディションについて。下記のようにエディションごとに利用可能な機能が異なるので要件に応じて選択してください。 従来の必要なオプションだけ追加していくエディションの考え方と違い、それぞれでオプションがバンドルされています。例えば、クラウドなのでセキュリティ観点からStandard Editionでも表領域暗号化がデフォルトで有効になっていたり、Enterprise EditionでもManagement Packs(Data Masking and Subsetting Pack, Diagnosticks and Tuning Packs)やReal Application Testingが利用可能です。 利用可能な機能とそのエディションをより細かく調べるには、データベース・ライセンス情報ユーザー・マニュアルを見てみてください。なお、作成後にエディションの変更はできません。 ・マニュアル Oracle Cloud Infrastructure Documentation > データベース > 仮想マシンDBシステム > サポートされているデータベースのエディションとバージョン ・ストレージの構成 OCI Database –VMは、リモートNVMe(ブロック・ストレージ)を利用します。用途は大きく分けて3つです。 1) 各コンピュートのローカル用の領域(S/W領域用ストレージ)でサイズは固定 2) データベースのデータ用の領域 : ASMで管理されるデータ用領域(DATAディスクグループ) 3) データベースのリカバリ用の領域 : ASMで管理されるリカバリ用の領域(RECOディスクグループ)。2の値をもとに自動算出 ストレージの構成のセクションで指定する『使用可能なストレージ(GB)』というのは、上記の2のデータベースのデータ用の領域を指します。 グレーアウトされている『合計ストレージ(GB)』は1/2/3全ての合計値を意味していて、これがこのDBシステムが利用するブロック・ストレージのサイズ(ブロック・ストレージの課金対象)になります。また、このサイズはRawサイズではなく、冗長化はとられた状態の実際に利用可能なサイズです。 ・ マニュアル Oracle Cloud Infrastructure Documentation > データベース > 仮想マシンDBシステム > 仮想マシンDBシステムのストレージ・オプション   3.2 データベース情報 システム上に自動構築されるデータベースの情報として入力していく項目は、下記のようなものがあります データベース名 : 任意のDB名の指定 データベースのバージョン : DBのバージョンを選択 PDB名(オプション) : バージョン12.1以上を指定した場合、任意のPDB名を指定。1PDB/1CDBで構築される 管理者資格証明の作成 : DBの管理者パスワードを入力 ワークロード・タイプの選択 : OLTPもしくはDSS データベース・バックアップの構成 : 自動バックアップの有効化が可能。保存期間は7/15/30/45/60日から選択 Advanced Options : 文字セット、各国語文字セット、タグを指定可能   データベース情報についての補足説明 ・データベースのバージョン データベースのバージョンは、各バージョンで利用可能な最新のパッチレベル(PSU/BP/RU)で作成されます。ただし、OCI Database-VMでは、上にある『使用可能なすべてのバージョンの表示』にチェックを付けると、最新から2つ前まで古いものが選択可能になります。例えば、テストのために少し古いパッチレベルの環境が必要な場合などに便利ですね。 ・ マニュアル Oracle Cloud Infrastructure Documentation > データベース > サポートされているデータベースのエディションとバージョン ■4. まとめ いかがでしたでしょうか。 Oracle Database 19cは、12.2ファミリーのLTS(Long Time Support)バージョンになります。そのため、19cを使ってみたい方や、既存環境のアップグレードや移行を検討されている方もいらっしゃると思います。 エディションの解説でも触れたように、Enterprise EditionではReal Application TestingやManagement Packsに含まれるTuning Packなどが利用可能です。短期間の検証環境として利用しやすくなっているので、ぜひ使ってみてください。 次回以降は、サービスの課金に関連するポイントについて解説していきたいと思います。   ページトップへ戻る▲    もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶ .iframe-responsive { position: relative; width: 100%; } .iframe-responsive iframe { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶ ※本記事は2019/8時点のものになります   みなさん、こんにちは。 先日、Oracle Cloud Infrastructure (以降、OCI) Database – Virtual Machine(以降、VM) でも、Oracle Database 19cが利用可能になりました! これで、OCI...

Oracle Cloud チュートリアルをはじめよう

今回は、Oracle Cloudの実際の利用手順に沿ったチュートリアルをご紹介します。初心者にも分かりやすい内容ですので、是非お手元でOracle Cloudを試してみて下さい。 チュートリアル:Oracle Cloudを利用した分析チュートリアル(基本編) このドキュメントでは、Oracle Autonomous Data WarehouseとOracle Analytics Cloudを組み合わせた環境で サンプルデータ(EXCELファイル)の分析を体験することができます。 体験後はお客様のEXCELデータも同じように分析できると思います。ぜひお試しください。 チュートリアル:Oracle Cloud Infrastructure を使ってみよう このドキュメントは Oracle Cloud Infrastructure (OCI) を使っていこう! という人のためのチュートリアル集です。各項ごとに画面ショットなどを交えながらステップ・バイ・ステップで作業を進めて、OCIの機能についてひととおり学習することができるようになっています。 チュートリアル:もしもみなみんがDBをクラウドで動かしてみたら 本連載では、主にOracle CloudのOracle Database関連サービスをまだ触ったことがない方を対象に、Oracle Cloud 上でOracle Databaseを利用するためのステップや関連機能、Tipsなどをお届けしていきます。実際に触っていただく際のご参考にしていただければ幸いです。  

今回は、Oracle Cloudの実際の利用手順に沿ったチュートリアルをご紹介します。初心者にも分かりやすい内容ですので、是非お手元でOracle Cloudを試してみて下さい。 チュートリアル:Oracle Cloudを利用した分析チュートリアル(基本編) このドキュメントでは、Oracle Autonomous Data WarehouseとOracle...

もしもみなみんがDBをクラウドで動かしてみたら 第12回 リソース追加してみよう - スケール・アップ/ダウン OCI Exadata 編 2019.5.17公開

もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶ ※本記事は2019/5時点のものになります こんにちは!今年のゴールデンウィークは長かったですが、皆様いかがでしたでしょうか。 今年のゴールデンウィーク前後は、オンプレミス版Oracle Database 19c(19.3) のLinux版がリリースされ、待望の第2世代のオラクル・クラウドOracle Cloud Infrastructure(OCI) の東京リージョンがオープンしたりと、私としては嬉しいニュースがいっぱい出てきました! 早速、東京リージョンにOCI Exadata/OCI Database/Autonomous Databaseを作ってみました。サクサク動いているので、ぜひ使ってみてください。 今回は、そんな東京リージョンのOCI Exadataでも実施した、スケール・アップ/ダウンについて解説したいと思います。 ■1. OCI Exadataのスケール・アップ/ダウンの対象は? OCI Exadata は、動的にCPUコア数を変更することが可能です。 このCPUコアというのは、コンピュート(VM)の”OS”側で認識しているActiveなコアを指します。また、DBシステム=サービス・インスタンス全体に対しての変更になります。そのため、例えばノード毎にCPUコア数を変えることはできないので、コンピュート数の倍数が指定可能になります。 コンピュートのCPUコア数が対象 0から利用しているシェイプ(Quarter/Half/Full)の利用可能なコア数の間で増減可能 増減単位はコンピュート数(例えば、Quarterは2コンピュートなので、2の倍数で指定) スケーリング(リソース変更)はオンライン ・マニュアル(以降は最新情報である英語マニュアルをポイントしていきます) 日本語 Oracle Cloud Infrastructure Documentation > Database > Exadata DBシステム 英語 Oracle Cloud Infrastructure Documentation > Database > Exadata DB systems ■2. スケール・アップ/ダウンしてみよう – コンソール編 では、実際にスケール・アップ/ダウンする方法を、まずはコンソール画面で見てみましょう。 対象のDBシステムの詳細ページに行き、『DBシステム情報』に表示されている現在の『CPUコア数』を確認しましょう。 前回の記事でも触れましたが、このCPUコア数はDBシステム(サービス・インスタンス)全体での有効なCPUコア数です。つまり、今回の環境のシェイプはQuarter=コンピュート2台のため、コンピュートあたり33CPUコアが有効になっています。 確認したら、システム名の下にある『スケール・アップ/ダウン』のボタンをクリック。 『CPUコア数』を指定するボックスが表示されるので、現在のリソース数から変更したいCPUコア数を入力します。 今回は、66から88に変更してみます。 ステータスが『スケーリング進行中』から『使用可能』になると、リソースの内容も変わり、スケーリング成功です。 なお、オンラインでのスケーリングなので、ステータスがスケーリング進行中でもサービスの使用は可能です。 ・マニュアル Oracle Cloud Infrastructure Documentation > Database > Exadata DBシステム > Exadata DBシステムの管理 > Exadata DBシステムを拡張するには ■3. スケールアップ/ダウンしてみよう – CUI編 CLI(OCI CLI/REST/Terraformなど)でもスケール・アップ/ダウンは可能です。今回は、OCI CLIでの方法を紹介します。 <事前準備> 1. OCI CLIのセットアップ 今回はセットアップは完了している前提ですすめますが、まだこれからという方は下記をご参考にセットアップしてみてください。 ・マニュアル Oracle Cloud Infrastructure Documentation > コマンド・ライン・インターフェース > クイックスタート ・Oracle Cloud 公式ブログ コマンドライン(CLI)でOCIを操作する – Oracle Cloud Infrastructureアドバンスド ちなみに、Oracle Cloud Developer ImageというOracle Cloudを利用する開発者向けのツールが全部入りのイメージが、マーケットプレイスから入手できるので、こちらを利用するとすぐにOCI CLIを使える状態になっているので簡単ですよ。 ・参考 [OCI]Oracle Cloud Developer Imageの発表 (2019/04/02) 2. db-system-idの確認 スケール・アップ/ダウンのコマンドで、対象リソースの識別子としてインスタンス(DBシステム)のOCIDの情報が必要になります。 ・コンソールからの確認 ・OCI CLIでの確認 $ oci db system list --compartment-id <コンパートメントのOCID> \ --query 'data[?"display-name"==`<表示名>`].{"display-name":"display-name","id":"id"}' 例 $ oci db system list --compartment-id <xxxxx> \ --query 'data[?"display-name"==`ExaCS`].{"display-name":"display-name","id":"id"}' [ { "display-name": "ExaCS", "id": "ocid1.dbsystem.oc1.ap-tokyo-1.<xxxxxx>" } ] <スケール・アップ/ダウン> まずは、OS側とデータベース側で認識しているCPUコア数を確認してみます。 -- OS側で認識しているActiveなコア数 #/bin/grep -c processor /proc/cpuinfo 66 -- DBインスタンス側で認識しているActiveなコア数 SQL> col name for a15 SQL> col value for a20 SQL> select inst_id,name,value from gv$parameter where name='cpu_count' INST_ID NAME VALUE ---------- -------------------- -------------------- 1 cpu_count 66 2 cpu_count 66 ハイパースレッディングが有効なので、各コンピュート/DBインスタンスで66コアが認識されていますね。 では、OCI CLIでスケール・アップしてみましょう。 $ oci db system update –cpu-count <OCPU数> --db-system-id <db-system-id> 例 --1.現在のOCPU数を確認 $ oci db system get --db-system-id xxx --query 'data.{"1.Name":"display-name",\ "2.shape":"shape","3.cpu-core-count": "cpu-core-count"}' { "1.Name": “ExaCS", "2.shape": "Exadata.Quarter2.92", "3.cpu-core-count": 66 } --2.88 OCPUにスケール・アップ $ oci db system update –cpu-count 88 --db-system-id <db-system-id> … --3.変更されたか確認 $ oci db system get --db-system-id xxx --query 'data.{"1.Name":"display-name",\ "2.shape":"shape","3.cpu-core-count": "cpu-core-count"}' { "1.Name": “ExaCS", "2.shape": "Exadata.Quarter2.92", "3.cpu-core-count": 88 } 再度、OS側とデータベース側で認識しているCPUコア数を確認してみます。 #/bin/grep -c processor /proc/cpuinfo 88 SQL> col name for a15 SQL> col value for a20 SQL> select inst_id,name,value from gv$parameter where name='cpu_count' INST_ID NAME VALUE ---------- -------------------- -------------------- 1 cpu_count 88 2 cpu_count 88 OS側だけではなく、DBインスタンス側でも認識しているコア数が増えていることがわかりますね。 ちなみに、oci db system-shape list コマンドで、各シェイプ毎の利用可能な最大OCPU数・スケーリングの単位(=ノード数)などが確認可能です。 $ oci db system-shape list --compartment-id <xxx> --availability-domain EWVY:AP-TOKYO-1-AD-1 \ --query 'sort_by(data,&"available-core-count") [?contains("shape",`Exadata`)]\ .{"1.shape":shape,"2.available-core-count":"available-core-count","3.core-count-increment"\ :"core-count-increment"}' --output table +---------------------+------------------------+------------------------+ | 1.shape | 2.available-core-count | 3.core-count-increment | +---------------------+------------------------+------------------------+ | Exadata.Quarter2.92 | 92 | 2 | | Exadata.Half2.184 | 184 | 4 | | Exadata.Full2.368 | 368 | 8 | +---------------------+------------------------+------------------------+ ・マニュアル OCI CLI Command Reference DB > system > update ■4. スケール・アップ/ダウンの影響は? OCI ExadataでのCPUコア数のスケール・アップ/ダウンは、オンラインで行われます。そのため、実行中のトランザクションが中止されたり、セッションが切れるということがなく、必要な時=リソースが逼迫している処理中でもスケール・アップが可能です。 繰り返しになりますが、OS側で認識しているActiveなコア数が変更されます。前述した例では、データベース側で認識する利用可能なコア数も動的に自動で変わりましたが、これはデータベース側の設定次第になります。 デフォルトではデータベース側で利用可能なコア数は、OS側で認識しているコア数になります。これはCPU_COUNTパラメータの設定になります。CPU_COUNTパラメータに明示的に数値を設定する、インスタンス・ケージング機能を利用している場合、そのインスタンスで利用可能なコア数を明示的に設定されている状態なので、OS側で利用可能なコア数が増減したとしても、インスタンス側で利用可能なコア数は固定されている状態です。そのため、インスタンス・ケージングを利用している場合は、CPUコアのスケール・アップ/ダウンをした後にデータベース側のCPU_COUNTを変更しないとデータベース側で利用するリソースは増減しないので、ご注意ください。 ・マニュアル Oracle Database データベース・リファレンス > CPU_COUNT CPUコア数を0にスケール・ダウンした場合は、利用可能なリソースがゼロ=全コンピュートが停止状態になります。スケール・ダウンとは別にコンピュートの停止機能もありますが、状態としては同じものの課金の部分が異なります。 コンピュートの停止はただコンピュートが停止されるだけで課金は継続されますが、スケール・ダウンでCPUコア数を0にした場合は課金もコンピュートも停止します。そのため、CPU部分の課金を停止したい場合には、コンピュートの停止ではなくCPUコア数を0にスケール・ダウンしてください。 ■5. まとめ 今回はOCI Exadataでのスケール・アップ/ダウンについて解説しました。 スケール・アップ/ダウンの機能は、「使いたい時に使いたいだけ」リソースを柔軟に増減できるクラウドならではのメリットなので、利用されたい方も多い機能だと思います。特にCLIについては、スケジューリングしたい場合や、スタンバイとしてOCI Exadataを利用しているケースで切り替え時にCPUを本番同等にするのに簡単にスクリプト化しておきたい場合など、色々なケースで利用可能かと思います。 サービスによってもスケール・アップ/ダウンの対象のリソースや動作に差がある場合があるので、利用するサービスごとに確認してくださいね。次回は、Autonomous Databaseでのスケール・アップ/ダウンについて解説しますので、ぜひそちらも見てみてください。   ページトップへ戻る▲    もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶

もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶ ※本記事は2019/5時点のものになります こんにちは!今年のゴールデンウィークは長かったですが、皆様いかがでしたでしょうか。 今年のゴールデンウィーク前後は、オンプレミス版Oracle Database 19c(19.3) のLinux版がリリースされ、待望の第2世代のオラクル・クラウドOracle Cloud...

基本からわかる!高性能×高可用性データベースシステムの作り方 第12回 Oracle Databaseの性能統計モデルと性能分析ツール

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   今回は、SQL実行環境をチューニングするにあたり、Oracle Databaseでは何を調べるときにどんなツールが用意されているかを整理します。個別のSQLの実行計画から、データベース・サーバー全体のリソースの使われ方の分析まで、Oracle Databaseの性能統計モデルの解説から行います。   1 SQL実行 SQLという言語の特徴の一つに、入力と出力の対応の定義のみを記述するというものがあります。SQLを見ただけでは、それがどのような手続き的アルゴリズムで実行されるかはわかりません。Javaなどの手続き的言語でデータ処理をプログラミングする場合、プログラマがデータ処理のアルゴリズムを記述します。これに対し、SQLではDBMSが手続き的アルゴリズムを自動生成します。 一般的に、同じ出力結果を得るための手続き的アルゴリズムは複数存在します。Oracle DatabaseではSQLを実行するとき、表や索引の構造および値の分布を考慮し、複数のアルゴリズムの候補から実行時間が最小と推測したものを採用します。この自動生成された手続き的アルゴリズムをSQL実行計画と呼びます。   SQL実行計画はOracleサーバー・プロセス(フォアグラウンド・プロセス)によってCPU上で処理されます。Oracleサーバー・プロセスがCPUにスケジューリングされ、CPU上で処理が進行している時間をCPU時間(CPU Time)と呼びます。しかし、処理の途中で必要なデータ・ブロックがデータベース・バッファ・キャッシュ上になく、ストレージから読み込む必要がでる場合があります。このような時、CPU上でのOracleサーバー・プロセスの処理の進行は「待機」させられます。データ・ブロックのキャッシュ・ミスを例に挙げましたが、CPU上での処理の進行を待機させる事象には様々なものがあります。Oracle Databaseではこれらの一つ一つの事象に名前が付けられており、どんな事象でどのくらいの時間SQL処理が待機させられたかがわかるようになっています。これらの事象を「待機イベント」といい、その時間を待機イベント時間(Wait Time)と呼びます。 Oracleサーバー・プロセスのCPU時間と待機イベント時間の合計をDB時間(DB Time)と呼び、SQL実行時間の短縮はこのDB時間の短縮を目標とするものです。最適なSQL実行計画の生成はCPU時間を短縮し、ハードウェア・リソースの適切な使用は待機イベント時間を短縮します。   SQL実行中に発生した待機イベントに対して、SQL実行中でないOracleサーバー・プロセスの待機動作をもたらす事象を「アイドル待機イベント」と呼びます。OracleクライアントはOracleサーバーに接続しているけれども、SQLを発行していない時間を考えます。このとき、Oracleサーバー・プロセスは何もしていないのではなく、Oracleクライアントからのリクエストを「待機」しています。これらのアイドル待機イベントによる待機時間をアイドル待機イベント時間(Idle Wait Time)と呼びます。ほとんどの場合、アイドル待機イベント時間は性能分析の観点からは無視できます。そのため、Oracle Databaseの性能分析ツールはDB時間(=CPU時間+待機イベント時間)に着目してレポートします。   2 Oracle Databaseの性能分析ツール Oracle Databaseにはいくつかの性能分析ツールが付属していますが、大別すると個別のSQL実行計画の分析にかかわるものと、複数セッションにわたるDB時間の分析にかかわるものに分類できます。     2.1 個別のSQL実行計画の分析 アプリケーション開発でSQLを記述している段階で行うことは、そのSQLを単発で実行したときに実行時間が要件を満たすようにSQL実行計画を決めることです。アプリケーションの性質がオンライン・トランザクション系なのか、分析系なのかで処理の傾向が異なります。 オンライン・トランザクション系のSQLは、表の中からごく少数の行を特定するものになる傾向があります。適切な索引を作成し、SQL実行計画は少ないデータ・ブロックへのアクセスになるよう目指します。そのため、個別のSQL実行時間は極めて短くなります。結合する表の数も少なく、索引アクセスになっているかを確認すればよいため、人間がSQL実行計画をみてもその良し悪しの判断が付きやすくなっています。 分析系のSQLは、表のかなりの割合の行にアクセスします。結合する表の数も多くなる傾向があります。そのため、索引を作成することが有効であるかの判断が難しくなります。索引の代わりにパーティショニングが効果的である場合があります。 オンライン・トランザクション系でも分析系でも、SQLチューニングの基本的な方針はアクセスするデータ・ブロック数を減らすことです。 SQL実行計画を調べる最も原始的なツールはEXPLAIN PLANやAUTOTRACEです。 ----------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ----------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 3 | 189 | 10 (10)| | 1 | NESTED LOOPS | | 3 | 189 | 10 (10)| | 2 | NESTED LOOPS | | 3 | 141 | 7 (15)| |* 3 | TABLE ACCESS FULL | EMPLOYEES | 3 | 60 | 4 (25)| | 4 | TABLE ACCESS BY INDEX ROWID| JOBS | 19 | 513 | 2 (50)| |* 5 | INDEX UNIQUE SCAN | JOB_ID_PK | 1 | | | | 6 | TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50)| |* 7 | INDEX UNIQUE SCAN | DEPT_ID_PK | 1 | | | ----------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter("E"."EMPLOYEE_ID"<103) 5 - access("E"."JOB_ID"="J"."JOB_ID") 7 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID" EXPLAIN PLANで推定されたSQL実行計画は実際に実行されるものと異なる場合があるので、簡易的な確認にしかなりません。正確なSQL実行計画を出力したい場合はDBMS_XPLAN.DISPLAY_CURSORプロシージャを使用します。 AUTOTRACEは実行時のデータ・ブロック・アクセス数なども出力できるため、EXPLAIN PLANよりももう少し有用です。 SQL実行計画に加えて、実行時にどのような待機イベントが発生したかの詳細を調べるにはSQLトレースを使用します。しかし、SQLトレースは莫大な量のログを生成するので、SQLトレースを取得すること自体がSQL実行時間に影響を与えます。また、一つ一つの待機イベント時間は極めて短いため、それらを把握しても削減すべき対象なのか判断するのは難しいところです。そのため、待機イベント時間の分析は個別の待機イベントを追跡するのではなく、待機イベントの種類ごとに累積した時間を検討します。そのためには後述するActive Session History(ASH)やAutomatic Workload Repository(AWR)レポートを使用します。   個別のSQLの実行時統計を調べるツールとして、Oracle Database 11gからリアルタイムSQL監視(SQL Monitor)という機能が導入されました。 リアルタイムSQL監視はOracle Enterprise Managerだけでなく、SQL開発に有用なクライアント・ツールであるSQL Developerからも使用することができます。そのため現在ではSQLトレースよりもリアルタイムSQL監視を使用します。リアルタイムSQL監視は以下のいずれかの条件を満たすSQLの実行時統計を取得します。 パラレル実行された 5秒以上消費した /*+ MONITOR */ヒント文が付けられた   2.2 複数セッションにわたるDB時間の分析 Oracle Databaseは複数のセッションを同時に接続することができ、複数のOracleクライアントからのリクエストを同時並行で処理を進めることができます。各Oracleサーバー・プロセスはCPU時間、待機イベント時間、アイドル待機イベント時間を目まぐるしく遷移していきます。複数のOracleサーバー・プロセスのアクティビティを合算し、全体として時間を消費している要素は何かを調べるツールにActive Session History(ASH)とAutomatic Workload Repository(AWR)レポート、statspackレポートがあります。   2.2.1 Active Session History Active Session HistoryはSQL実行状態にあるセッション(=アクティブなセッション)を1秒ごとにサンプリングし、全アクティブ・セッションのCPU時間、待機イベント時間を累積します。Active Session Historyのグラフの高さは、アクティブな状態のセッション数をあらわしています。占める割合の大きな要素を削減する(チューニングする)ことでSQL実行時間を削減できます。アクティブなセッション数がCPU数を超えていると、CPU数が不足しているかセッション数が多すぎることを示唆しています。CPUに同時にスケジューリングできるプロセス数の上限はCPU数であるため、それ以上の数のセッションがアクティブな場合、それらのセッションは何らかの待機イベントの状態として観測されます。   Oracle Enterprise ManagerのActive Session Historyの画面からは、時間消費の多いSQLやセッションを抽出することができます。Oracle Enterprise ManagerはASHとリアルタイムSQL監視を簡単に行き来することができるようになっています。   2.2.2 AWRレポート/statspackレポート ここまでで紹介してきたリアルタイムSQL監視やActive Session HistoryはOracleサーバー・プロセス(フォアグラウンド・プロセス)の消費する時間に着目するツールです。時間消費以外のアクティビティにも着目するOracleサーバー全体の総合的な分析ツールがAWRレポート/statspackレポートです。歴史的にはstatspackがOracle8iで実装され、それを改良したAWRがOracle Database 10gで実装されました。性能試験もしくは本番稼働のOracle Databaseの性能分析を依頼されたとき、最初に尋ねるのが「負荷の高い時間帯のAWRレポートかstatspackレポートはありますか?」です。 ASHは1秒ごとのフォアグラウンド・プロセスのサンプリングでしたが、AWR/statspackはASHに比べるとかなり長い間隔のレポートを想定しています。AWRはデータベースを作成した時点で自動的にスナップショットの取得を開始しており、その間隔はデフォルトで1時間です。statspackはスナップショットを定期的に取得する仕組みを設定しなければいけません。Oracleインスタンスは自身のアクティビティ、例えばREDOログ生成量はOracleインスタンス起動時からの累積値を保持しています。AWR/statspackはこれらの統計値をスナップショットとして表に保存します。スナップショットを取得した任意の2点を指定すると、その差分を計算してその期間の性能統計レポートを作成します。   AWRレポートはかなり詳細な項目が出力されますが、主に見るのは以下の項目です: Load Profile フォアグラウンド・プロセス待機イベント時間 リソース使用の多いSQL I/O統計 セグメント統計 Load ProfileはこのOracleインスタンスの負荷の概観です。DB時間、CPU時間、アクセス・ブロック数、更新ブロック数、REDOログ量、I/O量、SQL数などがわかります。   SQLを実行する主体はフォアグラウンド・プロセス(Oracleサーバー・プロセス)なので、フォアグラウンド・プロセスの待機イベント時間の大きな割合を占めるものを削減できると、SQL実行性能の改善が期待できます。AWRレポートには累積時間の大きな順で待機イベントが並びます。負荷の小さな時でもとにかく累積時間の大きな順に出てくるので、性能に影響があるかどうか(チューニング個所の候補になるか)の判断が必要になります。そのため、チューニングの検討をするときは負荷の高い時間帯のレポートを参照します。   バックグラウンド・プロセスも待機イベントは観測されていて、AWRレポートにはこれらも出力されます。通常はあまり見ることはありませんが、Oracle Databaseでファイルに書くプロセスはLGWRとDBWRのバックグラウンド・プロセスなので、書き込みI/Oに疑いがある場合はこれらも参照します。   3 自動チューニング ここまで紹介してきた分析ツールはOracleサーバーの状態を提示するためのものでした。その内容を解釈してチューニングを検討するのは人間の役割です。もう一歩踏み込んで、Oracle Databaseにはこれらの分析ツールの統計情報から、SQLの実行時間をさらに改善する余地があるかを自動探索させる機能があります。 AWRレポートにはOracleインスタンスのメモリ割り当てを増減させた場合のI/O量の推定などが出力されます。 SQLの実行に直接かかわる項目のアドバイザはSQLチューニング・アドバイザとSQLアクセス・アドバイザがあります。これらはAWRやASHなどから抽出されたSQLに対し、索引の作成などの提案を行います。   SQLチューニング・アドバイザとSQLアクセス・アドバイザはチューニング方法の提案を行い、それを実装するかの判断は人間が行います。Oracle Database 19cではさらに踏み込んで、索引の作成までを自動化するAutomatic Indexingの機能が実装されます。   ページトップへ戻る▲    「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   今回は、SQL実行環境をチューニングするにあたり、Oracle Databaseでは何を調べるときにどんなツールが用意されているかを整理します。個別のSQLの実行計画から、データベース・サーバー全体のリソースの使われ方の分析まで、Oracle Databaseの性能統計モデルの解説から行います。   1 SQL実行 SQ...

もしもみなみんがDBをクラウドで動かしてみたら 第11回 Oracle Cloud Infrastructure Exadata の構成について 2019.4.19公開

もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶ ※本記事は2019/4時点のものになります こんにちは。先日Oracle Technology Nightで、本連載の第9回でも取り上げたOracle Cloud Infrastructure(OCI)上のOracle Databaseのサービスの違いについて話してきました。連載記事よりも情報量は多く細かくなっているので、「どれを使ったらいいんだろう…」「どう違うんだろう…」と迷われた方、記事よりももっと詳細が知りたい方はぜひ下記の資料もご覧ください。 ・[資料] Oracle Cloud Infrastructure Database – Oracle Database のサービス比較編 (2019/03/29) では、今回の記事の内容に入りましょう! 前回はOracle Cloud Infrastructure(以降OCI) Exadataの概要と作り方を取り上げましたが、今回はOCI Exadataのサービス構成について解説します。 ■1. Oracle Cloud Infrastructure Exadataの構成 OCI ExadataはOracle Exadata Database Machine(以降Exadata)が利用可能なサービスです。 前回解説したように、作成時にいくつかインフラ側の設定を指定しましたが、図にすると下記のようなイメージとなります。 さらっとまとめると 指定したリージョン内で指定した1つのアベイラビリティ・ドメインに属します 同一アベイラビリティ・ドメイン内のクライアント・サブネットとバックアップ・サブネットを持ちます リモート・バックアップを取る場合は、Object Storageに取得されます フォルト・ドメインの指定はありません アクセス経路として、インターネット接続のほかVPNやFastConnect(閉域網)接続が可能です OCI Exadataのシステム構成としては、指定したシェイプに合わせてコンピュート・ストレージなど物理サーバーが専有の形で提供されます。下記は、Half Rack(Compute 4台、Storage 6台)の図です。 次の章から、コンピュートとストレージに分けて解説していきます。 ・マニュアル(以降は日本語マニュアルをポイントしていきます) 日本語 Oracle Cloud Infrastructure Documentation > Database > Exadata DBシステム 英語 Oracle Cloud Infrastructure Documentation > Database > Exadata DB systems ■2. OCI Exadataのコンピュートはどうなっているの? コンピュートはシェイプによってサーバー数が決まります。Base/Quarterは2台、Halfは4台、Fullだと8台です。 Oracle Grid Infrastructureで管理されており、コンピュート側はOracle Clusterwareでデータベース関連のプロセスの管理・監視が行われています。また、データベースはOracle Real Application Clustersでクラスタ構成となり、複数のコンピュートにまたがって一つのデータベースとして扱うことができるため、高い可用性・高性能な環境となります。 ・コンピュートの構成・管理 各コンピュートは、仮想マシンとして別物理サーバー上で動きます。 専有環境のためH/Wリソースとして利用可能な領域は全て割り当てられます。ただし、コア数(Oracle CloudではOCPU)を利用する分だけ有効にしますので、H/Wとしては割り当て済ですが課金を抑えるために必要な分だけに絞ることが可能です。また、システム全体なコア数(OCPU数)を指定して各コンピュートに割り振るため、有効なコア数はコンピュート数の倍数が指定可能です。一方で、ローカルストレージやメモリは、全て利用可能な状態になっているので変更はせずに済みます。 コア数(OCPU数)の変更は、オンラインで変更が可能です。つまり、データベースを止めずにトランザクション実行中に処理能力を上げることができます。オンライン・スケーリングについては、また別の回で解説するのでお楽しみに。 コンピュート内(OS以上)はユーザー管理の領域になり、コンピュート内に含まれるソフトウェアのパッチ適用やアップグレードはユーザー管理の範囲になるので、含まれるソフトウェアについて説明します。 ・コンピュート内のソフトウェア 環境作成後、OS、Oracle Grid Infrastructure(Clusterewareなど)とOracle Databaseが構築済の状態になっています。 各種ソフトウェアのインストール場所は固定されていて、下記の通りとなります。 ソフトウェア ディレクトリ 補足 Oracle Grid Infrastructure /u01/app/<version>/grid 例:/u01/app/18.1.0.0/grid 1環境につき1つインストールされます Oracle Database /u02/app/oracle/product//dbhome_ 例: /u02/app/oracle/product/18.0.0.0/dbhome_2 サブディレクトリとしてORACLE_HOMEごとにディレクトリが作られていきます クラウド・ツール /var/opt/oracle クラウドサービスの機能として提供されている監視・管理ツールが含まれます   よく間違えるのが、Oracle Databaseのインストール・ディレクトリが/u01ではなく/u02配下なのでご注意ください。 コンピュート内(OS以上)はユーザー管理の領域のため、OS含めこれらのパッチ適用やアップグレードはユーザー管理の範囲になるので、適用タイミングや判断はユーザーになので、これまで同様に定期的なパッチ適用を検討ください。 この中で特に忘れがちなのは、クラウド・ツールです。クラウドの新機能やアップデートが頻繁に入りますが、UIやCLIと連携して動くのがこのクラウド・ツールになりますので、最新機能を利用するためにもクラウド・ツールは定期的にアップデートするのがおすすめです。 ・マニュアル OSとクラウド・ツールに関して Oracle Cloud Infrastructure Documentation > Database > Exadata DBシステム> Exadata DBシステムの更新 Oracle DatabaseとOracle Grid Infrastructureに関して Oracle Cloud Infrastructure Documentation > Database > Exadata DBシステム> Exadata DBシステムの更新 ■3. OCI Exadata のストレージはどうなっているの? ストレージもシェイプによってサーバー数が決まり、専有環境のためH/Wリソースとして利用可能な領域は全て割り当てられます。Quarterは3台、Halfは6台、Fullだと12台です。 ・ストレージの構成・管理 ストレージ領域はOracle Automatic Storage Management(ASM)で管理・構成されます。ASMで管理されることで、サーバー数・ディスク数がいくつであろうと、ディスク・グループと呼ばれる一つの領域として扱うことができ、冗長構成がとられリバランスが自動的に行われます。冗長性は、OCI Exadataでは三重化(トリプル・ミラー)で組まれています。 ストレージはオラクル管理の領域になるので、ユーザーからストレージ(セル・サーバー)へ直接アクセスはできないのですが、ASMのインスタンスはコンピュート上で稼働するので、ユーザーもASMインスタンスへのアクセスや操作・情報参照は可能です。 ・ストレージの領域の割り当てられ方(サイズ) ディスクグループは、下記の2もしくは3個が用意されます。 ディスク・グループ名 用途 DATA Oracle Databaseのデータ関連の領域 RECO Fast Recovery Area(FRA)と呼ばれるOracle Databaseのバックアップ関連(RMANバックアップファイル/REDOなど)の領域 SPARSE Exadataスナップショット(SPARSE CLONE)の機能を利用する際に必要な領域   X6モデルだと上記に加えてDBFS/ACFSという別のディスク・グループが作成されますが、X7の場合は上記のディスク・グループのみとなっています。 それぞれに割り当てられるストレージ領域のサイズは、環境作成時の下記の選択によって変わります。 ・マニュアル Oracle Cloud Infrastructure Documentation > Database > Exadata DBシステム>ストレージ構成 ここでポイントなのが、「使用可能なストレージ容量」 のサイズは「データベース/データのサイズ」ではないということです。 使用可能なストレージ容量の中で、DATA/RECO/SPARSEの各ディスク・グループに割り当てられます。 コンピュート側のメモリと同じく、シェイプで決まっているH/Wリソースは全て割り当てられているので、拡張はできません。 ■4. OCI Exadata上で使えるデータベースの数は? 一般的なPaaSサービスは、1環境につき1データベースがユーザーに提供されますが、OCI ExadataやOCI Database - Bare Metalなどの専有環境では、リソースが許す限り1環境で複数データベースが作成できます。 最初に環境を作成したタイミングでは、環境上に1つデータベースが作成されている状態です。 追加でデータベースを作成したい場合には、『データベースの作成』をクリックし、作成したいデータベースの状況を入力します。 ちなみに、Oracle Grid Infrastructureのバージョンと同じもしくは下位のバージョンのデータベースが作成可能です。 Oracle Grid Infrastructureのバージョンは、環境を作成する時に選択したデータベースのバージョンによって決まります。 下記は2019/04現在利用可能なバージョンになります。 今回の環境は、初回のデータベースとして18cを選択していたので、Grid Infrastructureも18cで構築されています。 そのため、2個目以降のデータベースのバージョンとしては18cもしくは下位バーションが利用可能となるので、18c/12.2.0.2/12.1.0.2/11.2.0.4のデータベースを作成することが可能です。 なので、上記の例では追加するデータベースで12.2.0.1を選択してみました。 ・マニュアル Oracle Cloud Infrastructure Documentation > Database > Exadata DBシステム> サポートされているDatabaseエディションおよびバージョン ■5. まとめ 今回は、OCI Exadata の構成やリソース、そして利用可能なデータベース数について解説しました。 H/Wリソースは全て利用可能=最初から大きなサイズが割り当てられており、異なるバージョンの複数データベースが作成可能な環境です。そのため、例えばミッションクリティカルや大規模システムのデータベース、サーバー/データベース統合、既存システムのレプリケーション、複数バージョンでの検証・開発環境など、様々な利用ケースが考えられるので、適用可能なケースでぜひご利用いただければと思います。   ページトップへ戻る▲    もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶

もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶ ※本記事は2019/4時点のものになります こんにちは。先日Oracle Technology Nightで、本連載の第9回でも取り上げたOracle...

全国のOTNおすすめ技術者向けセミナー&イベント(2019年4月)

4月開催 MySQL 8.0 入門セミナー ~チューニング基礎編、SQLチューニング編~ MySQL入門セミナーをMySQL 8.0 対応版を札幌と仙台で開催します。 MySQLをチューニングする時に役立つ様々な機能やチューニングの基礎知識、オプティマイザの仕組み、実行計画を確認する際のポイントなど、さまざまなSQLチューニングの基礎について解説します。入門者の方におすすめのセミナーです。 4/22 Oracle Database Technology Night ~集え!オラクルの力(チカラ) 米国時間2019年2月13日に、最新のOracle Database 19cが、まずは Exadataプラットフォーム向けにリリースされました。今後、Oracle CloudやOn-Premiseの主要プラットフォーム向けにも順次提供される予定です。Oracle Database 19c は現在最新の Oracle Database 12c Release 2 ファミリーの最新および最終リリースであり、長期のサポートが提供されます。安定性および各種機能の強化、Autonomous Database 機能など、今注目すべき Oracle Database 19c についてご紹介します。 4/24 実践Kubernetesハンズオン ~OKEでKubernetesを体験しよう~ Oracle Cloudは大規模なコンテナの管理、デプロイおよび運用に適したクラウドサービスを複数提供しています。本ハンズオンセミナーではOracle Cloudが提供するコンテナ・サービスを実際に利用しKubernetes環境の構築からコンテナ・アプリケーションのデプロイ、CI/CDまでの一連の流れを体感いただけます。 オラクル認定資格試験 再受験無料キャンペーン実施中 2019年5月31日までのキャンペーン期間中、対象となるオラクル認定資格試験の受験のお申し込み時にプロモーションコード(RETAKE19JP)を入力すると、万が一合格できなかった場合に、無料で同一試験を受験できます。期間限定のお得なキャンペーンを利用して、皆さまの技術力の証明として認定資格の取得に是非チャレンジください。

4月開催 MySQL 8.0 入門セミナー ~チューニング基礎編、SQLチューニング編~ MySQL入門セミナーをMySQL 8.0 対応版を札幌と仙台で開催します。 MySQLをチューニングする時に役立つ様々な機能やチューニングの基礎知識、オプティマイザの仕組み、実行計画を確認する際のポイントなど、さまざまなSQLチューニングの基礎について解説します。入門者の方におすすめのセミナーです。 4/22...

基本からわかる!高性能×高可用性データベースシステムの作り方 第11回 バックアップ/リカバリ(6)データファイルよりも小さな粒度でのリストア/リカバリ

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   第10回までは、リストアはファイル単位で行うという暗黙の仮定を置いていました。RMANでバックアップを取得する最小単位は1本のデータファイルですが、リストア/リカバリの最小単位はデータファイルではありません。RMANはデータファイルよりも小さな単位である特定のデータブロックをリストア/リカバリすることが可能です。これをブロック・メディア・リカバリと呼びます。 Oracle Databaseは複数のデータファイルで構成されていますが、データファイル以上の単位でリストア/リカバリするためには、そのデータファイルを含む領域を一旦アクセスできない状態にする必要があります。   リストア対象 RMANコマンド 前提 CDB全体 RMAN> RESTORE DATABASE; OracleインスタンスをSHUTDOWNしてMOUNTで起動 PDB RMAN> RESTORE PLUGGABLE DATABASE xx; 該当PDBをMOUNT状態 表領域 RMAN> RESTORE TABLESPACE xx; 該当表領域をOFFLINE データファイル RMAN> RESTORE DATAFILE xx; 該当表領域をOFFLINE 該当表領域の全データファイルをOFFLINE データブロック RMAN> RECOVER DATAFILE xx BLOCK yy; データファイルがONLINEのまま可能   ブロック・メディア・リカバリでは、リカバリ対象のデータブロック以外の正常なデータブロックへのアクセスは可能にしたままリストア/リカバリすることが可能です。そのため、リカバリ対象のデータブロックにアクセスしないSQLは実行可能です。また、データファイル単位のリストア/リカバリよりも短時間でリカバリが完了します。   2 ブロック・メディア・リカバリの実行 ブロック・メディア・リカバリではRECOVERコマンドにどのデータファイルのどのデータブロックをリカバリするかを指定します。そのためには、破損が発生したデータブロックを把握する必要があります。SQL実行時に破損が検出されると、そのSQLのエラーとして破損データブロックの情報が出力されます。 SQL> r 1 select c1, 2 DBMS_ROWID.ROWID_RELATIVE_FNO(rowid) fno , 3 DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) bno 4* from t1 select c1, * 行1でエラーが発生しました。: ORA-01578: Oracleデータ・ブロックに障害が発生しました(ファイル番号18、ブロック番号131) ORA-01110: データファイル18: '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf' Oracle Databaseサーバー側に出力される情報としてはOracleインスタンスのalertファイルと、V$DATABASE_BLOCK_CORRUPTIONビューがあります。 2019-03-11T13:29:00.884624+09:00 Corrupt Block Found TIME STAMP (GMT) = 03/11/2019 13:29:00 CONT = 3, TSN = 6, TSNAME = USERS2 RFN = 18, BLK = 131, RDBA = 75497603 OBJN = 89853, OBJD = 89853, OBJECT = T1, SUBOBJECT = SEGMENT OWNER = BKTEST, SEGMENT TYPE = Table Segment Errors in file /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/trace/sidb18a_ora_6726.trc (incident=93361) (PDBNAME=SIPDB1): ORA-01578: Oracleデータ・ブロックに障害が発生しました(ファイル番号18、ブロック番号131) ORA-01110: データファイル18: '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf' SIPDB1(3):Incident details in: /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/incident/incdir_93361/sidb18a_ora_6726_i93361.trc SQL> SELECT FILE#,BLOCK#,BLOCKS FROM V$DATABASE_BLOCK_CORRUPTION; FILE# BLOCK# BLOCKS ---------- ---------- ---------- 18 131 1 また、RMANのデータ・リカバリ・アドバイザを使用すると、破損データブロックの特定からリカバリ・コマンドの生成および実行まで行うことができます。 ■障害個所の把握 RMAN> list failure; データベース・ロール: PRIMARY データベース障害のリスト ========================= 障害ID 優先度ステータス 検出時間 サマリー ------ -------- --------- -------- ------- 21862 HIGH OPEN 19-03-11 データファイル18: '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'には 破損したブロックが1つ以上含まれています RMAN> list failure 21862 detail; データベース・ロール: PRIMARY データベース障害のリスト ========================= 障害ID 優先度ステータス 検出時間 サマリー ------ -------- --------- -------- ------- 21862 HIGH OPEN 19-03-11 データファイル18: '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'には 破損したブロックが1つ以上含まれています 影響: 表領域USERS2内の一部のオブジェクトが使用できない可能性があります 親の障害ID 21862に対する子の障害リスト 障害ID 優先度ステータス 検出時間 サマリー ------ -------- --------- -------- ------- 21865 HIGH OPEN 19-03-11 ブロック131 (データファイル18): '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'はメディア破損しています 影響: オブジェクトT1 (BKTEST所有)は使用できない可能性があります ■修復スクリプトの生成 RMAN> advise failure; データベース・ロール: PRIMARY データベース障害のリスト ========================= 障害ID 優先度ステータス 検出時間 サマリー ------ -------- --------- -------- ------- 21862 HIGH OPEN 19-03-11 データファイル18: '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'には 破損したブロックが1つ以上含まれています 影響: 表領域USERS2内の一部のオブジェクトが使用できない可能性があります 親の障害ID 21862に対する子の障害リスト 障害ID 優先度ステータス 検出時間 サマリー ------ -------- --------- -------- ------- 21865 HIGH OPEN 19-03-11 ブロック131 (データファイル18): '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'はメディア破損しています 影響: オブジェクトT1 (BKTEST所有)は使用できない可能性があります 自動修復オプションを分析中です。これには少し時間がかかる場合があります チャネルORA_DISK_1の使用 チャネルORA_DISK_2の使用 チャネルORA_DISK_3の使用 チャネルORA_DISK_4の使用 チャネルORA_DISK_5の使用 チャネルORA_DISK_6の使用 チャネルORA_DISK_7の使用 チャネルORA_DISK_8の使用 チャネルORA_DISK_9の使用 チャネルORA_DISK_10の使用 チャネルORA_DISK_11の使用 チャネルORA_DISK_12の使用 チャネルORA_DISK_13の使用 チャネルORA_DISK_14の使用 チャネルORA_DISK_15の使用 チャネルORA_DISK_16の使用 自動修復オプションの分析が完了しました 必須の手動アクション ======================== 使用可能な手動アクションがありません オプションの手動アクション ======================= 使用可能な手動アクションがありません 自動修復オプション ======================== オプション 修復 説明 ------ ------------------ 1 ブロック131 (ファイル18)のブロック・メディア・リカバリを実行します 計画: 修復には、データが損失しない完全なメディア・リカバリが含まれます 修復スクリプト: /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/hm/reco_3037615942.hm RMAN> repair failure preview; 計画: 修復には、データが損失しない完全なメディア・リカバリが含まれます 修復スクリプト: /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/hm/reco_3037615942.hm 修復スクリプトの内容: # block media recovery recover datafile 18 block 131; ■修復の実行 RMAN> repair failure; 計画: 修復には、データが損失しない完全なメディア・リカバリが含まれます 修復スクリプト: /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/hm/reco_3037615942.hm 修復スクリプトの内容: # block media recovery recover datafile 18 block 131; この修復を実行しますか(YESまたはNOを入力してください)。 YES 修復スクリプトを実行しています recoverを19-03-11で開始しています チャネルORA_DISK_1の使用 チャネルORA_DISK_2の使用 チャネルORA_DISK_3の使用 チャネルORA_DISK_4の使用 チャネルORA_DISK_5の使用 チャネルORA_DISK_6の使用 チャネルORA_DISK_7の使用 チャネルORA_DISK_8の使用 チャネルORA_DISK_9の使用 チャネルORA_DISK_10の使用 チャネルORA_DISK_11の使用 チャネルORA_DISK_12の使用 チャネルORA_DISK_13の使用 チャネルORA_DISK_14の使用 チャネルORA_DISK_15の使用 チャネルORA_DISK_16の使用 チャネルORA_DISK_1: ブロックをリストアしています チャネルORA_DISK_1: バックアップ・セットからリストアするブロックを指定しています データファイル00018のブロックをリストアしています チャネルORA_DISK_1: バックアップ・ピース/u01/app/oracle/fast_recovery_area/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/backupset/2019_03_11/o1_mf_nnndf_TAG20190311T132556_g8crtonw_.bkpから読取り中です チャネルORA_DISK_1: ピース・ハンドル=/u01/app/oracle/fast_recovery_area/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/backupset/2019_03_11/o1_mf_nnndf_TAG20190311T132556_g8crtonw_.bkp タグ=TAG20190311T132556 チャネルORA_DISK_1: バックアップ・ピース1からブロックをリストアしました チャネルORA_DISK_1: ブロックのリストアが完了しました。経過時間: 00:00:01 メディア・リカバリを開始しています メディア・リカバリが完了しました。経過時間: 00:00:03 recoverを19-03-11で終了しました 障害の修復が完了しました ここまでは、破損データブロックの番号を特定し、その特定されたデータブロック番号をRECOVERコマンドに指定していました。しかし、V$DATABASE_BLOCK_CORRUPTIONビューに現れるすべての破損データブロックを一括でリカバリする方法もあります。RECOVERコマンドにCORRUPTION LISTを指定すると、破損を把握しているすべてのデータブロックをリカバリします。 RMAN> recover corruption list;   3 ブロック・メディア・リカバリのリストア元 ブロック・メディア・リカバリを実施する場合、リカバリの起点となるデータブロックはどこからリストアされるのでしょうか。 データファイル単位のリストアの場合、第8回で説明したように増分バックアップからのリストアはlevel 0をリストアしたのち順次level 1をリストアしていきます。増分更新バックアップではlevel 0にlevel 1を適用したファイルをリストアします。 ブロック・メディア・リカバリでは、RMANで取得したデータファイルの他にも、フラッシュバック・ログが設定されていた場合はそこからリストアしようとします。RMANでデータファイルのバックアップを取得する頻度は、高速増分バックアップでも1日1回で運用している場合が多く、バックアップを取得してから時間が経過している(更新が多い)場合があります。しかし、フラッシュバック・ログにはRMANのバックアップよりも新しい更新の状態が記録されていることが期待できます。リストアするデータブロックが最新の状態に近いほど、リカバリで適用するREDOログも少なくて済みます。そのため、ブロック・メディア・リカバリではフラッシュバック・ログからリストアしようとします。   フラッシュバック・ログからリストアできない場合、データファイルのバックアップからリストアしようとします。ブロック・メディア・リカバリではlevel 0のバックアップからリストアします。そのため、level 1の増分バックアップを取得していても、増分更新バックアップを適用していなければ、level 0までさかのぼってリストアします。REDOログの適用はlevel 0のバックアップの時点からとなるので、アーカイブREDOログがlevel 0バックアップの時点からの分が保存されていなければいけません。   4 ファイル破損の自動修復 RMANのリカバリを実行することになったということは、破損データブロックにアクセスしようとしたSQLに何らかのエラーが返っています。しかし、Oracle Databaseは破損を検出したデータブロックを自動的に修復し、SQLにエラーを返さずに処理を継続できる機能があります。   4.1 Oracle Automatic Storage Management(ASM) ASMはOracle Database専用のボリューム・マネージャ兼ファイルシステムとしての役割を担っており、Oracle Grid Infrastructureの機能として提供されています。ASMでは格納するファイルの冗長度をEXTERNAL(冗長化なし)、NORMAL(2重化)およびHIGH(3重化)から選択することができます。 NORMALまたはHIGHのASMディスクグループに格納されたファイルにアクセスした際に破損が検出されると、ミラーされた領域にアクセスしOracleクライアントにエラーを返すことなく処理を継続します。そして、破損が検出された領域はミラー領域のデータを使って自動的に修復されます。   4.2 自動ブロック・メディア・リカバリ Oracle Databaseのリモート・レプリケーション機能であるOracle Active Data Guardを構成すると、プライマリ・データベースで更新されたREDOログの情報がスタンバイ・データベースに転送され、スタンバイ・データベースではそのREDOログでリカバリが実施されます。そのため、Oracle Active Data Guardではプライマリ・データベースとスタンバイ・データベースのデータブロックの中身が同一になります。 プライマリ・データベースでデータブロックの破損が検出されると、Oracleクライアントにエラーを返さずに、スタンバイ・データベースから正常なデータブロックを取得してプライマリ・データベースを修復します。そして、Oracleクライアントにはエラーを返さずに処理を継続します。   今回は、データファイルよりも小さな粒度であるデータブロックを単位としてリストア/リカバリが可能であるブロック・メディア・リカバリについて説明しました。ブロック・メディア・リカバリでは、破損個所以外の正常なデータブロックにはアクセス可能なまま、破損データブロックだけをリストア/リカバリすることができます。また、ASMやActive Data Guardを構成すると、破損を検出してもOracleクライアントにはエラーを返さずに処理を継続することが可能です。   ページトップへ戻る▲    「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   第10回までは、リストアはファイル単位で行うという暗黙の仮定を置いていました。RMANでバックアップを取得する最小単位は1本のデータファイルですが、リストア/リカバリの最小単位はデータファイルではありません。RMANはデータファイルよりも小さな単位である特定のデータブロックをリストア/リカバリすることが可能です。こ...

全国のOTNおすすめ技術者向けセミナー&イベント(2019年3月)

Oracle Cloud Dayセミナーシリーズ 企業Cloud活用に向けて、各企業でお考えになるCloudソリューションの具体的な活用/導入について、さまざまなソリューションに分けたOracle Cloud Dayシリーズと題し、みなさまへお届けします。3月度開催情報は以下の通りです。 - 3/1 Cloud Security Day 世界のトレンドと国内先進事例 - 3/8 Container Native Day コンテナ/Kubernetesを容易に導入し、最大限のメリットを享受する方法とは - 3/13 Autonomous Database Day 簡単!高速!柔軟! Modern Styleデータ活用のリアリティ 3/7 DBをスピードアップさせたい!株式会社マイナビのMySQL活用事例紹介セミナー 成長を続ける大手人材広告企業 株式会社マイナビは、マイナビ賃貸ウェブサイトでどのようにMySQLを利用しているのか。その開発現場で活躍するIT開発統括部エンジニアの方にバージョンアップやレプリケーション構成での工夫についてお話しいただきます。また、MySQLの最新バージョン8.0のサマリーもお届けします。 3/15 Oracle Cloud Infrastructure ハンズオン ~Compute&Database~ 「Oracle Cloud Infrastructure」は、オンプレミスからの大規模ワークロード移行に完全対応する次世代インフラ基盤です。本セミナーでは、Oracle Cloud InfrastructureのCompute/Databaseを中心としたサービス概要のご紹介とともに、実際のクラウド環境を利用したハンズオンを行います。 3/27 実践Kubernetesハンズオン ~OKEでKubernetesを体験しよう~ Oracle Cloudは大規模なコンテナの管理、デプロイおよび運用に適したクラウドサービスを複数提供しています。本ハンズオンセミナーではOracle Cloudが提供するコンテナ・サービスを実際に利用しKubernetes環境の構築からコンテナ・アプリケーションのデプロイ、CI/CDまでの一連の流れを体感いただけます。 3/29 Oracle Database Technology Night ~集え!オラクルの力(チカラ) ~ [Oracle Cloud] 日本データセンター開設前に知っておくべきこと ~Oracle Databaseのサービス比較編 ~ 今回は日本データセンター開設に先駆けて、Oracle Cloud 上で提供される様々なDatabase サービスのスペック比較、機能差異や構成例等をテーマにお話しします。 Oracle University 無償セミナー (3月) Oracle University のセミナーに参加しませんか。みなさまのスキルアップを応援します! ORACLE MASTERやオラクル認定 Java 資格の無償試験対策セミナーを受講してオラクル認定資格試験にチャレンジしてください。オンラインセミナーも併設していますので遠方の方も受講いただけます。

Oracle Cloud Dayセミナーシリーズ 企業Cloud活用に向けて、各企業でお考えになるCloudソリューションの具体的な活用/導入について、さまざまなソリューションに分けたOracle Cloud Dayシリーズと題し、みなさまへお届けします。3月度開催情報は以下の通りです。 - 3/1 Cloud Security Day 世界のトレンドと国内先進事例 - 3/8 Container...

基本からわかる!高性能×高可用性データベースシステムの作り方 第10回 バックアップ/リカバリ(5)RMANでのリストア/リカバリ時間の短縮

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   第9回では、RMANでのバックアップの読み取りブロック数を減少させる高速増分バックアップと、バックアップの並列化によるバックアップ時間の短縮について説明しました。今回はRMANでのリストア/リカバリ時間の短縮について説明します。バックアップと同様に、リストア/リカバリも並列化することができます。   1 リストアの並列化 RMANでは、バックアップの並列化と同様に、複数のRMANチャネルを構成することによりリストアも並列化することができます。第9回でも説明しましたが、RMANのCONFIGUREコマンドでPRALLELISMを設定します。以下の例では並列度を4に設定しています。 RMAN> CONFIGURE DEVICE TYPE disk PARALLELISM 4; 新しいRMAN構成パラメータ: CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET; 新しいRMAN構成パラメータが格納できました 複数のRMANチャネルを設定した状態でRESTOREコマンドを発行すると、リストアが並列に実行されます。   2 リカバリの並列化 データファイルのリストアが完了した次に行うことは、REDOログの適用(リカバリ)です。REDOログにはデータベースに対する更新処理(チェンジ・ベクタ)がSystem Change Number(SCN)の順にシーケンシャルに記録されています。しかし、データベースへのチェンジ・ベクタの適用は並列に実行することが可能です。 メディア・リカバリの並列化は、何も設定しなくてもデフォルトで並列化されます。Oracle Database 11g Release 1以降では、RECOVERコマンドのPRALLEL句で並列度を指定しない場合はOracleインスタンスの初期化パラメータCPU_COUNTの値に等しい並列度でリカバリが実行されます。CPU_COUNTのデフォルト値はOSが認識しているCPUスレッド数です。 RMAN> RECOVER DATABASE [PARALLEL n]; メディア・リカバリが開始されると、PRnnというOracleインスタンスのバックグラウンド・プロセスが生成されます。PRnnはメディア・リカバリの間だけ生存するプロセスです。以下はCPU_COUNT=24の環境でリカバリを実行したときに生成されるPRnnプロセスをpsコマンドで見た例です。 $ ps -efH UID PID PPID C STIME TTY TIME CMD ... oracle 25342 1 31 15:43 ? 00:00:04 ora_pr00_sidb18a oracle 25344 1 14 15:43 ? 00:00:02 ora_pr01_sidb18a oracle 25346 1 31 15:43 ? 00:00:04 ora_pr02_sidb18a oracle 25348 1 20 15:43 ? 00:00:03 ora_pr03_sidb18a oracle 25350 1 19 15:43 ? 00:00:02 ora_pr04_sidb18a oracle 25352 1 19 15:43 ? 00:00:02 ora_pr05_sidb18a oracle 25354 1 12 15:43 ? 00:00:01 ora_pr06_sidb18a oracle 25356 1 27 15:43 ? 00:00:04 ora_pr07_sidb18a oracle 25358 1 7 15:43 ? 00:00:01 ora_pr08_sidb18a oracle 25360 1 6 15:43 ? 00:00:01 ora_pr09_sidb18a oracle 25362 1 7 15:43 ? 00:00:01 ora_pr0a_sidb18a oracle 25364 1 6 15:43 ? 00:00:00 ora_pr0b_sidb18a oracle 25366 1 5 15:43 ? 00:00:00 ora_pr0c_sidb18a oracle 25368 1 4 15:43 ? 00:00:00 ora_pr0d_sidb18a oracle 25370 1 8 15:43 ? 00:00:01 ora_pr0e_sidb18a oracle 25372 1 7 15:43 ? 00:00:01 ora_pr0f_sidb18a oracle 25374 1 6 15:43 ? 00:00:00 ora_pr0g_sidb18a oracle 25376 1 8 15:43 ? 00:00:01 ora_pr0h_sidb18a oracle 25378 1 12 15:43 ? 00:00:01 ora_pr0i_sidb18a oracle 25380 1 7 15:43 ? 00:00:01 ora_pr0j_sidb18a oracle 25382 1 7 15:43 ? 00:00:01 ora_pr0k_sidb18a oracle 25384 1 8 15:43 ? 00:00:01 ora_pr0l_sidb18a oracle 25386 1 15 15:43 ? 00:00:02 ora_pr0m_sidb18a oracle 25388 1 21 15:43 ? 00:00:03 ora_pr0n_sidb18a oracle 25390 1 21 15:43 ? 00:00:03 ora_pr0o_sidb18a REDOログから読み込まれたチェンジ・ベクタには、どのデータブロックに対しどのような変更を行ったかが記録されています。チェンジ・ベクタのデータブロック・アドレスをハッシュした値に基づいて、そのチェンジ・ベクタをどのPRnnプロセスが適用するかが決定されます。つまり、あるデータブロックのリカバリは特定のPRnnプロセスのみが担当します。複数のPRnnプロセスが同じデータブロックを変更するということはありません。 REDOログにはSystem Change Number(SCN)の順にチェンジ・ベクタが記録されており、1つのデータブロックは1つのPRnnプロセスからしか変更されないため、複数のチェンジ・ベクタによる複数のデータブロックのリカバリを複数のPRnnプロセスで並列に実行することが可能になっています。   リカバリ性能のボトルネックになる要素の一般的な傾向は、REDOログが配置されたストレージのシーケンシャルI/O性能ではなく、CPU性能もしくはデータファイルが配置されたストレージのランダムI/O性能になります。 莫大な量のREDOログをリカバリする事態になったとき、リカバリの進捗を「REDOログをxx本適用した」というようにREDOログの尺度で語ることになるのですが、ストレージのハードウェアの性能はランダムI/OのスループットよりもシーケンシャルI/Oのスループットの方がはるかに高い値を示すものなので、リカバリに時間がかかる原因が「REDOログを読むのが遅い」ということになっているのはまれなことです。 REDOログをどこから適用する必要があるかは、リストアしたデータファイルのバックアップをいつ取得したかによって決まります。リストアしたデータブロックの状態からリカバリしたい時点(障害発生直前の状態)までの更新の差分だけREDOログを適用することになります。そのため、バックアップを取得する間隔を短くしておくと、リカバリに必要なREDOログの量も少なくなります。バックアップはデータベースのストレージに負荷をかけるため、SQLの実行性能への影響を懸念してあまりとらないという設計をする人もいる(!)のですが、もしファイル破損が起きた場合の迅速な復旧という観点からは、毎日バックアップを取得することをお勧めします。第9回で説明した高速増分バックアップを使用すれば、前回のバックアップから更新されたデータブロックにのみアクセスするのでフルバックアップと比較してストレージの負荷を下げることができます。また、Data Guardのフィジカル・スタンバイを構成すると、スタンバイ・データベース側でバックアップを取得し、それをプライマリ・データベースにリストアすることも可能です。 ここまでの説明では、リストアをファイル単位で行うという暗黙の仮定を置いていました。RMANでバックアップを取得する最小単位は1本のデータファイルですが、リストア/リカバリの最小単位はデータファイルではありません。RMANはデータファイルの中の特定のデータブロックをリストア/リカバリすることが可能です。これをブロック・メディア・リカバリと呼びます。次回はブロック・メディア・リカバリの説明を予定しています。   ページトップへ戻る▲    「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   第9回では、RMANでのバックアップの読み取りブロック数を減少させる高速増分バックアップと、バックアップの並列化によるバックアップ時間の短縮について説明しました。今回はRMANでのリストア/リカバリ時間の短縮について説明します。バックアップと同様に、リストア/リカバリも並列化することができます。   1...

もしもみなみんがDBをクラウドで動かしてみたら 第10回 Oracle Cloud Infrastructure Exadata を使ってみよう 2019.1.24公開

もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶ ※本記事は2019/1時点のものになります 前回はOracle Cloud Infrastructure(以降OCI)で利用可能なOracle Databaseのサービスについて違いを解説しましたが、今回からはその中の一つ、OCI Exadataのサービスについて解説していきます。 ■1. Oracle Cloud Infrastructure Exadataとは Oracle Cloud Infrastructure Exadata(以降OCI Exadata)は、Oracle Databaseが高い可用性を備えつつ高いパフォーマンスを発揮できるOracle Exadata Database Machine(以降Exadata)が利用可能なサービスです。 同じようにOCI上でExadataを利用可能なサービスとしては、Autonomous Data WarehouseやAutonomous Transaction Processing などのAutonomous Databaseのサービスがありますが、OCI Exadataが他のサービスと大きく違うところは、全オプションが使える専有型のAutomatedサービスであるということです。   専有型 H/Wもユーザー専有となり、他のユーザーの環境と分離されるため、セキュリティ・性能を担保できる Automatedサービス OS以上は顧客管理。OS上の構築・運用・管理に有効な機能を、クラウドのツールでも提供。パッチ適用やメンテナンスの実施判断・作業タイミングは顧客判断 OSログインが可能でこれまで同様の管理方法を用いることができる(OS権限が必要な変更作業、サード・パーティのAgentの導入、ローカルにログやダンプファイルの配置など)ので、別途インスタンスやストレージサービスを立てる必要はない ■2. OCI Exadataを作ってみよう – 事前準備 OCI Exadataで利用可能なシェイプは、下記の通りです。 参照: Exadata DBシステム システム構成 環境をさわる前に、どこに情報があるのか=マニュアルの該当箇所を確認しておいてください。 (日本語) Oracle Cloud Infrastructure マニュアル> サービス> Database > Exadata DB システム (英語) Oracle Cloud Infrastructure Manual > Service > Database > Exadata DB Systems 次に、環境作成する前に必要な環境確認やインフラレイヤーでの準備をしましょう。インフラレイヤーでの各種設定は、マニュアルまたはOracle Cloud 公式ブログでのチュートリアルを参考にしてみてください。   事前準備 サービス・リミットとアベイラビリティ・ドメインで、OCI Exadataが利用可能であることを確認 コンパートメントの用意 VNC(仮想クラウド・ネットワーク)の用意 OCI Exadataでは、2つのサブネット(クライアント・サブネットとバックアップ・サブネット)が必要なので2つ作成 クライアント・サブネット内では全てのノード間で、TCPとICMPの疎通が必要なのでセキュリティ・リストのingress/egressの設定 特にVNCのネットワーク設定で赤字にした部分は、忘れがちなのでご注意ください。 ■3. OCI Exadataを作ってみよう – 環境作成 では、早速OCI Exadataを作ってみましょう。   ・Exadata DBシステムの作成ウィンドウを立ち上げる 左側のコンソールメニューから、Database > Bare Metal,VM,and Exadataを選択します 右上で表示されているアベイラビリティ・ドメインと左側に表示されているコンパートメントが正しいかを確認して、”Launch DB System”をクリックします ウィンドウが立ち上がると、DB System Information/Network Information/Database Informationの3つのセクションが表示されるので、それぞれに情報を入力していきます。 ・DB System Informationの情報を入力 ここでは、作成する環境(システム)に関する情報を選択・入力します。 DISPLAY NAME : 作成するシステムの任意の名前を入力。一覧で表示される名前など、作成するシステムを管理するのに使います AVAILABILITY DOMAIN : 環境を配置するアベイラビリティ・ドメインを選択 SHAPE TYPE : EXADATAを選択 SHAPE : 利用するシェイプ(ExadataのRackモデル)を選択 Exadata.<Rackモデル>1.<コア数>はX6、Exadata.<Rackモデル>2.<コア数>はX7 参照: Exadata DB システム > システム構成 CLUSTER NAME : 環境の全ノード(コンピュート)にまたがるクラスタ名を入力。文字で始まる11文字以内ので文字/数字/ハイフンのみで入力してください。 TOTAL CPU COUNT : 利用する全ノードの合計OCPU数を選択 * SHAPEで選択したRackに応じてノード数が決まり、そのノード数の倍数が選択可能です。今回はQuarter Rackを選択したので、2の倍数が選択可能になります LICENCE TYPE : LICENSE INCLUDEDもしくはBYOL(BRING YOUR OWN LICENSE)で選択可能。ライセンス持ち込みをしない場合は、前者を選択 SSH PUBLIC KEY : 公開鍵を登録 DATA ALLOCATION : DATABSE BACKUPS ON EXADATA STORAGE(ローカルへのバックアップを取得するかどうか)、CREATE SPARSE DISK GROUP(SPARSE DISKを作るかどうか=Exadata Snapshot機能を使うかどうか)を要件に合わせてチェックボックスにチェックをいれる * この選択によって、Storageの各記憶域(ASMのDisk Group)に割り当てられるサイズが決まります 参照 : Exadata DB システム >記憶域構成 Network Informationの情報を入力 次にシステムのネットワーク構成に関連する情報を入力していきます VIRTUAL CLOUD NETWORK : 事前準備で用意したVNCを指定 CLIENT SUBNET : 事前準備で用意したクライアント・サブネットを選択 BAKCUP SUBNET : 事前準備で用意したバックアップ・サブネットを選択 HOSTNAME PREFIX : 任意のホストネームを入力 ・Database Informationの情報を入力 最初に作成されるデータベースの情報を選択・入力します。2個目以降は、環境(システム)が出来上がってから後から追加していくことが可能です。 DATABSE NAME : 命名規則にそった任意のデータベース名を入力。アルファベットの文字で始まり、最大8文字の英数字(特殊文字は不可)を含めることができます。 DATABSE VERSION : データベースのバージョンを選択 PDB NAME : (オプション) 命名規則にそった任意のPDB名を入力 DATABASE ADMIN PASSWORD : データベースの管理者パスワードを入力します。入力した際に、入力ボックスの下のメッセージが黄緑であればOKです。(赤の場合は命名規則に引っかかっている状態) DATABASE WORKLOAD : ワークロードタイプを選択。これによって作成されるデータベースの状態が変わります。作成後に自分で各種の設定変更は可能です Advanced Options > CHARACTER SET / NATIONAL CHARACTER SET : デフォルトはAL32UTF8/AL16UTF16。他のキャラクタ・セットを使用する場合は選択して下さい。 最後に、選択・入力した情報を確認して”Launch DB System”をクリックして、環境が出来上がるのを待ちます ・作成したExadata DBシステムの状態を確認 作成したDBシステムがAVAILABLEステータスになったら作成完了です。専有型の環境のデプロイなので、Rackサイズによって前後しますが作成完了までに数時間かかります ・作成したExadata DBシステムに接続(OSログイン) Exadata DBシステムの情報は、”DB Systems”のページの一覧からシステム名をクリック、もしくは右側の『・・・』をクリックして”View DB System Details”をクリック DB System Detailページで、環境(システム)の情報を確認することが可能です。左下の方に”Resources”のタブがあるので、ここで”Nodes”を選択すると各ノードの情報を表示できます。 各ノードに設定されているIPアドレスを確認しましょう あとは、 IPアドレス(パブリックIP or プライベートIP(VNC内、VPN利用有無などネットワーク構成による)) システム作成時に使用した公開鍵のペアの秘密鍵 ユーザーはopcもしくはoracle を用いてOSへ接続可能です 参照: Exadata DBシステム > SSHを使用したComputeノードへの接続 ■4. まとめ 今回は、OCI Exadataの作成について簡単に触れてみました。これまで何度も、オンプレミスのExadataのセットアップを何時間もかけてやったことを思い出しながらやっていると、細かい知識がなくてもこれだけでExadataを使える状態になるのは本当に楽ですね。 次回以降では、もう少し具体的な詳細について解説していきたいと思います。   ページトップへ戻る▲    もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶

もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶ ※本記事は2019/1時点のものになります 前回はOracle Cloud Infrastructure(以降OCI)で利用可能なOracle Databaseのサービスについて違いを解説しましたが、今回からはその中の一つ、OCI Exadataのサービスについて解説していきます。 ■1. Oracle Cloud...

Copied from: Copied from: 全国のOTNおすすめ技術者向けセミナー&イベント(2019年2月)

2/12 APEX UG Meetup 2019#1 - #事例を共有しよう! 2019年第一回目のMeetupを開催します。今回は実際に現場で使われているAPEXにフォーカスを当てたセッションを集める予定です。 2/14 Autonomous Database Day 企業Cloud活用に向けて、各企業でお考えになるCloudソリューションの具体的な活用/導入について、さまざまなソリューションに分けたOracle Cloud Dayシリーズと題し、みなさまへお届けします。 2/20 Blockchain Day 企業Cloud活用に向けて、各企業でお考えになるCloudソリューションの具体的な活用/導入について、さまざまなソリューションに分けたOracle Cloud Dayシリーズと題し、みなさまへお届けします。 2/21 Oracle Database Technology Night ~集え!オラクルの力(チカラ) 「PL/SQL 最新情報」 Oracle Databaseを使用しているシステムの開発に欠かせないPL/SQLについて、主にOracle Database 11g以降のPL/SQLを対象に、パフォーマンス向上策や新機能を紹介いたします。 Oracle Code Tokyoに関する各種Meetup・セミナー・イベント情報 日本国内のデベロッパーを対象に、最新技術動向、ユースケース、トレンドに関するノウハウや技術情報を入手・共有できる「開発者による開発者のための」ディベロッパー(開発者)向けコミュニティ。Oracle Code Tokyo Night(Meetup セミナー)はこちらでチェック! オラクル認定資格試験  再受験無料キャンペーン開始のお知らせ オラクル認定資格試験の受験を検討されている方は必見!本年度もオラクル認定資格再受験無料キャンペーンを開始しました。2019年1月7日〜2019年5月31日のキャンペーン期間中、対象となるオラクル認定資格試験の受験のお申し込み時にプロモーションコード(RETAKE19JP)を入力すると、万が一合格できなかった場合に、無料で同一試験を受験できます。認定資格の取得に是非チャレンジください。

2/12 APEX UG Meetup 2019#1 - #事例を共有しよう! 2019年第一回目のMeetupを開催します。今回は実際に現場で使われているAPEXにフォーカスを当てたセッションを集める予定です。 2/14 Autonomous Database Day 企業Cloud活用に向けて、各企業でお考えになるCloudソリューションの具体的な活用/導入について、さまざまなソリューションに分...

もしもみなみんがDBをクラウドで動かしてみたら 第9回 Oracle Cloud InfrastructureでOracle Databaseを使ってみよう 2018.12.20公開

もしもみなみんがDBをクラウドで動かしてみたら Indexページ ▶▶   ※本記事は2018/12時点のものになります Oracle Gen 2 Cloud(第二世代)の基盤であるOracle Cloud Infrastructureでも利用可能なOracle Databaseのサービスは複数あります。今回は、それぞれのサービスについて紹介するとともに違いについて解説していきます。 ■1. Oracle Cloud Infrastructureで利用可能なOracle Databaseのサービス 今年10月に行われたOracle OpenWorld 2018では、OCIが日本にも開設されるということが発表されました!オラクルが2016年末から展開を開始していた第二世代のクラウド基盤を、日本国内でも利用できるのは楽しみですね。 これまでの記事では、現在の日本国内のデータセンター(DC)でも利用可能なOracle Cloud Infrastructure Classic(OCI-C)上でのDatabase Cloud Serviceを中心に書いてきましたが、今回からはOracle Cloud Infrastructure(OCI)上での内容を取り上げていきます! そもそも「Oracle Cloud Infrastructure(OCI)とは??これまでと何が違うの??」という方は、こちらをご覧下さい。 現在、OCI上のPaaSとしてOracle Databaseが利用可能なサービスは、5種類あります。 それぞれについて特徴を書いてみます。   OCI Database - Virtual Machines 仮想マシン(VM)で利用可能なデータベースのサービスです。 4つのエディションを選択可能でさらにOracle Real Application Clusters(RAC)が利用可能なので、ユーザーのニーズに合わせて様々なサイズ・構成で利用可能なサービスです。 OCI Database - Bare Metal 専有型のベアメタル環境で利用可能なDatabaseのサービスです。 4つのエディションを選択可能で、高いパフォーマンスのH/Wとネットワークを備えたベアメタル環境を、オンプレミスの自前サーバーと同様に他から影響を受けることなくワークロードを捌けるサービスです。 OCI Exadata Oracle Exadata Database Machine(Exadata)を丸ごと利用できる専有型のサービスです。 4種類のラックサイズを選択可能で、Enterprise Editionのオプション機能を全て利用可能なモデルで、Oracle Database向けの高いパフォーマンスと高い可用性を備えたサービスになります。 Autonomous Database Exadata上で動いているデータベースを安価で簡単に利用できるフルマネージド・サービスです。 「自己管理」「自己保護」「自己修復」を特徴とした自律型データベースのサービスで、ワークロードごとに事前定義・設定済の、DWH向けAutonomous Data WarehouseとOLTPやミックスワークロード向けAutonomous Transaction Processingの2種類のサービスを提供しています。   ■2. サービスごとの違い 前述した通り、同じOracle DatabaseのPaaSサービスでも、利用形態やサイズ、インフラの違いなどで複数のサービスを提供していますが、5つもあると「それぞれのサービスはどう違うのですか?」「今回xxという要件なのですが、どれを選んだら(利用したら)いいですか?」と、よく質問をいただきます。 なので、次は私自身がよく聞かれる観点でのサービスの違いを、簡単にまとめてみます。 ・ サービスの特徴・契約関連     OCI Database - Virtual Machines OCI Database - Bare Metal OCI Exadata Autonomous Data Warehouse/Autonomous Transaction Processing 管理 Automatedサービス = ユーザーはOS以上を管理 Full-Managedサービス OS提供形態 仮想 ベアメタル 仮想 - DBエディション Standard Edition Enterprise Edition High Performance Extreme Performance Standard Edition Enterprise Edition High Performance Extreme Performance Extreme Performance (全オプション) - 1環境上で利用可能なDB数 1 複数可 複数可 - H/W共有 共有 専有 専有 共有 最低利用期間 OCPU/Storage : 1時間 OCPU/Storage : 1時間 OCPU : 1時間、 Storage : 1ヶ月 OCPU/Storage : 1時間   まず特徴的なのは、OCI DatabaseやOCI Exadataは、AutomatedといわれるOS以上はユーザー管理が可能なサービスです。第2回でも触れましたが、OSにログイン可能ということは、データベースの操作や設定でOS権限が必要な機能も利用可能ですし、ログを直接見ることも可能です。またローカルにファイルを置くこともできるので、インポート・エクスポートの際にも便利です。 一方で、Autonomous Databaseの2つのサービスはFull-Managedサービスです。こちらは一般的なPaaSサービスで多い形になりますが、OS以下のインフラならびにデータベース管理自体もオラクルが管理します。そのため、ユーザーはデータベースを本当に簡単に利用可能で、第1章での紹介通り自律的な管理を行います。 その他、特徴を少しピックアップしてみると 他のユーザーのワークロードの影響を受けずに、データベースのパフォーマンスを出せるような環境を利用可能なのは、専有型のOCI ExadataとOCI Database - Bare Metal OCI Databaseでは、4つのエディションが選択可能で、上位オプション(図の中では下)になるにつれ利用可能なオプション機能が増え価格も変わるので、必要なオプションに応じた選択が可能 OCI ExadataとOCI Database - Bare Metalは、1つの環境(OS)上に複数のデータベースが作成可能 最後の複数データベースが利用可能ということは、多くのデータベースを利用する予定がある場合にはOS集約で管理工数を減らしたり、テスト環境を一時的に利用する際の追加コストなしで行える、などのメリットがあります。また、複数の異なるバージョン、パッチ差異があるデータベースも作成可能です。 分離と集約という観点で別環境にする場合と同一環境にする場合、どちらにもメリットデメリットがあるので一概には言えないですが、OSでの集約でメリットがある利用ケースであれば、この2つのサービスが選択肢になるかと思います。もちろんマルチテナント機能を利用したデータベースの集約もあります!この場合、OCI Database・OCI Exadataいずれでも実施可能です。 続いては、少し細かくなりますが、利用可能なリソースに関しです。 ・ サービスのインフラ部分や利用可能なリソースサイズ     OCI Database - Virtual Machines OCI Database - Bare Metal OCI Exadata Data Warehouse/Autonomous Transaction Processing H/W X7 X7 Exadata X6、X7 (以降、X7内容記載) Exadata Computer数 1 (RAC : 2) 1 Base/Quarter : 2 Half : 4、Full : 8 - CPU数 1 - 24 2 - 52 1 - 368 1 - 128 Memory サイズ 15GB - 320GB (シェイプ毎にサイズ倍増) 768GB 480GB – 5,760GB (720GB x Compute数) CPUコア数に応じて 自動設定 Storage サイズ 256GB – 40TB Block Storage、拡張可 16TB Local NVMe、固定 42.7 TB – 427.6TB Local Exadata Storage、固定 Base : 42.7TB、Quarter : 106.9TB Half : 213.8TB、 Full : 427.6TB 1TB - 128TB Local Exadata Storage、 1TBずつ拡張可能 ネットワーク 1-25GbE 2x25 GbE 2x25 GbE (Exadata 内通信はInfiniBand) - スケーリング - (Storageはオンライン) オンライン オンライン オンライン   リソースに関しては、基本的には自分が欲しいリソース数(サイズ)が割り当て可能なサービスがどれかを見ていただく形です。 小さくスタートしたい・とりあえず試してみたいという場合には、AutomatedサービスならOCI Database – Virtual Machine、そしてFull-ManagedのAutonomous Databaseのサービス(Autonomous Data Warehouse・Autonomous Transaction Processing) になります。Exadataをそのまま利用したい場合にはOCI Exadata、Exadata上のデータベースを簡単に気軽に利用可能なのがAutonomous Databaseの2つのサービスです。 少ないリソース数で細かく指定可能なのは、OCI Database – Virtual MachineやAutonomous Databaseの2つのサービス(Autonomous Data Warehouse・Autonomous Transaction Processing) OCPU以外のリソースが全て利用可能な状態になっているのが、OCI ExadataとOCI Database - Bare Metal オンライン・スケーリング対応しているのは、OCI Database – Virtual Machine以外 可用性の機能のReal Application Clusters(RAC)が利用可能なのは、2ノード以上で利用可能なOCI Database – Virtual Machines(Extreme Performance)とOCI Exadata。(図には記載していませんが、Autonomous Database もデフォルトでRACで動いています!) 3. さいごに 今回はいつもと少し違う観点の内容にしてみましたが、いかがでしたでしょうか。 これまで同様にサービスの利用方法をとりあげようかと思っていましたが、その前にOCI上で使えるOracle DatabaseのPaaSサービスの違いがわからないとどのサービスを使ったらいいか迷われてしまうかと思ったので、サービス概要をまとめてみました。 細かい内容(特にH/Wリソース周り)は、今後変更が入りやすい部分になるので最新情報をみていただきたいのですが、サービスの概要やざっくりとしたサイズ感などは参考にしていただけるのではないかと思います。 次回からは、これまでのようにサービスの使い方を紹介していこうと思いますので、来年もよろしくお願いします!   ページトップへ戻る▲    もしもみなみんがDBをクラウドで動かしてみたら Indexページ ▶▶

もしもみなみんがDBをクラウドで動かしてみたら Indexページ ▶▶   ※本記事は2018/12時点のものになります Oracle Gen 2 Cloud(第二世代)の基盤であるOracle Cloud Infrastructureでも利用可能なOracle Databaseのサービスは複数あります。今回は、それぞれのサービスについて紹介するとともに違いについて解説していきます。 ■1. Oracle...

基本からわかる!高性能×高可用性データベースシステムの作り方 第9回 バックアップ/リカバリ(4)RMANでのバックアップ時間の短縮

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   第8回ではRMANのバックアップ・ファイルのサイズを小さくする増分バックアップと、そのリストア/リカバリについて説明しました。増分更新バックアップを使用すると、バックアップ・ファイルのサイズを小さくできることと、リストア時のデータ移動量の最小化と、リカバリ時に適用するREDOログの開始点を最新の増分バックアップ取得時点からにすることを両立することができます。今回はRMANでのバックアップ時間を短縮する方法を扱います。バックアップ取得時のデータ・ブロックへのアクセスを減少させる高速増分バックアップと、バックアップの並列化について説明します。   1 増分バックアップの高速化 増分バックアップは、前回バックアップを取得した時点から更新が発生したブロックのみをバックアップ・ファイルとすることで、バックアップで生成されるファイル・サイズを小さくすることができます。Oracle Databaseの増分バックアップのデフォルトの動作は、データファイルのすべてのブロックを検査することで前回のバックアップから更新されたかを判断します。そのため、データファイルへのI/O量が削減されるわけではありません。   この動作を改良するために、Oracle Database 10g Release 1のEnterprise Editionで、増分バックアップのデータファイルのI/O量を削減するためのブロック・チェンジ・トラッキングという機能が導入されました。各データブロックが前回のバックアップから更新されたかどうかをBlock Change Tracking(BCT)ファイルに記録し、増分バックアップはこのBCTファイルを見て変更のあったデータブロックを読み取ります。そのため、更新されたデータブロックの範囲にもよりますが、増分バックアップの時間を大幅に短縮することができます。この仕組みを高速増分バックアップといいます。   高速増分バックアップを有効にするには、BCTファイルを作成します。 SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '+DATA/rac122a/bct.dbf' REUSE; RMANはOracleインスタンスに接続してバックアップを行うため、バックアップに関する統計情報を動的パフォーマンス・ビューで見ることができます。バックアップを行った時の各データファイルに対する読み取り量がV$BACKUP_DATAFILEビューに現れます。次のSQLでバックアップのブロック数がわかります。 SELECT TO_CHAR( COMPLETION_TIME,'YYYY/MM/DD-HH24:MI:SS') as COMPLETION_TIME,FILE#,DATAFILE_BLOCKS,BLOCKS_READ,BLOCKS,INCREMENTAL_LEVEL,USED_CHANGE_TRACKING,USED_OPTIMIZATION FROM V$BACKUP_DATAFILE ORDER BY COMPLETION_TIME; V$BACKUP_DATAFILEビューから読み取れるブロック数に関する列には以下のものがあります。 DATAFILE_BLOCK: データファイルの総ブロック数 BLOCKS_READ: RMANが読み取ったブロック数 BLOCKS: 生成されたバックアップ・ファイルのブロック数 BCTファイルの有無でlevel 1増分バックアップのブロック読み込み数(BLOCKS_READ)が変化する例を以下に示します。   この例では、増分バックアップを取得する前にSQLで更新を発行したわけではないので、増分バックアップで生成されたバックアップ・ファイルのブロック数(BLOCKS)はどちらの場合も1になっています。 BCTファイルがない場合でも、RMANは未使用ブロックの読み取りをスキップするので、データファイルの全ブロック数(DATAFILE_BLOCKS)よりも読み取ったブロック数(BLOCKS_READ)は小さくなります。しかし、BCTファイルを有効にした場合は読み取ったブロック数(BLOCKS_READ)はデータファイル全体のブロック数(DATAFILE_BLOCKS)に比べてかなり小さな値になります。   2 バックアップの並列化 Oracle DatabaseのEnterprise Editionでは、1つのRMANのBACKUPコマンドで複数のOracleサーバー・プロセスの接続を生成し、複数プロセスでバックアップを並列化することができます。1つのファイル転送経路をRMANチャネルと呼びます。デフォルトでは並列度は1で、1つのRMANチャネルによりバックアップされます。 並列度を変更するにはCONFIGUREコマンドでPARALLELISMを設定します。以下の例では並列度を4に設定しています。 RMAN> CONFIGURE DEVICE TYPE disk PARALLELISM 4; 新しいRMAN構成パラメータ: CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET; 新しいRMAN構成パラメータが格納できました RMANのバックアップの並列化のデフォルトの動作は、複数のファイルがあれば複数のファイルのバックアップを並列に行うというものです。ほとんどのデータベース構成ではこの動作で十分です。 Oracle Databaseの表領域のデータファイル構成は2種類あり、smallfileファイル表領域とbigfile表領域があります。Oracle9iまではsmallfile表領域のみでしたが、Oracle Database 10gでAutomatic Storage Management(ASM)とともにbigfile表領域が導入されました。これらの違いはデータファイルの個数とサイズの制限です。   データファイル数上限 データファイルごとの データブロック数上限 smallfile表領域 1022 2^22(4M)個 bigfile表領域 1 2^32(4G)個   smallfile表領域からbigfile表領域へ何が変わったかというと、表領域あたりのデータファイルの個数は1/1K倍に減少しましたが、1データファイル当たりのデータブロックの個数上限が1K倍に増加しました。そのため、表領域当たりのデータブロックの個数の総数上限はどちらもほぼ4G個で変わりがありませんが、データベース全体で管理するデータファイルの個数を減らすことができます。bigfile表領域はASMのように1つのファイルを複数の物理ストレージ・デバイスに分散する構成での使用を想定しています。 データブロックのサイズは多くの場合8192(8K)バイトが選択されます。このサイズでbigfile表領域を作成すると、1つのデータファイルは最大32T(8K×4G個)バイトにもなります。そのため、1つの巨大なデータファイルのバックアップを高速に行う仕組みが求められます。 RMANは1つのデータファイルを複数に分割してバックアップを取得することができ、これをマルチセクション・バックアップといいます。マルチセクション・バックアップにするにはBACKUPコマンドにSECTION SIZEを指定します。マルチセクション・フル・バックアップはOracle Database 11g Release 1で導入され、Oracle Database 12c Release 1からはマルチセクション増分バックアップに対応しました。マルチセクション増分バックアップは高速増分バックアップと複数のRMANチャネルとも組み合わせることが可能です。   以下の例はSECTION SIZEに1G(Byte)を指定した増分更新バックアップ用のレベル1増分バックアップです。 RMAN> BACKUP 2> SECTION SIZE 1G 3> INCREMENTAL LEVEL 1 4> FOR RECOVER OF COPY WITH TAG 'incr_update' 5> DATABASE ; もしSECTION SIZEが小さいためにセクション数が256を超える場合、セクション数が256になるようにサイズが調整されます。 また、複数のRMANチャネルの並列化によりバックアップ時間が短縮する暗黙の前提として、並列に実行される処理が複数の物理デバイスに分散しているというものがあります。特に、ストレージがハードディスクで構成されていた場合、1台のハードディスクに複数のI/Oリクエストを並列に発行してもスループットは向上しません。ASMのように1つのファイルが複数の物理デバイスに分散されるような構成を想定しています。 今回はRMANによるバックアップ時間の短縮について解説しました。Oracle Database 12c Release 1以降のEnterprise Editionでは、マルチセクション増分バックアップと高速増分バックアップ、増分更新バックアップ、そしてRMANチャネルの並列化を組み合わせることができます。 ページトップへ戻る▲    「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   第8回ではRMANのバックアップ・ファイルのサイズを小さくする増分バックアップと、そのリストア/リカバリについて説明しました。増分更新バックアップを使用すると、バックアップ・ファイルのサイズを小さくできることと、リストア時のデータ移動量の最小化と、リカバリ時に適用するREDOログの開始点を最新の増分バックアップ取得...

Copied from: 全国のOTNおすすめ技術者向けセミナー&イベント(2019年1月)

  1/16 開催:Oracle IDEAワークショップ カスタマージャーニーワークショップと実行のギャップを埋める!オラクル独自のイノベーションプロセスをご紹介。参加型のプログラムで、サンプルペルソナを用いて、カスタマージャーニーマップの作成、アイデア出し、プロトタイプ作成、効果検証まで一連のプロセスを実際にご体験頂きます。 1/28 開催:実際に操作してみよう!! Oracle Analytics Cloud ハンズオン トレーニング in 大阪 「Oracle Analytics Cloud」は、全社的な BI(エンタープライズ BI)から担当者によるセルフサービス BI までをカバーした包括的な可視化・分析クラウド サービスです。本トレーニングでは、担当者によるセルフサービス BI を想定し、実際に Web ブラウザ経由で Oracle Analytics Cloud にアクセスして、対象データの接続方法と可視化を体感して頂きます。 2/12 開催:APEX UG Meetup 2019 #1 今回のセミナーでは、今回は実際に現場で使われているAPEXにフォーカスを当てたセッションを開催します。 直前対策セミナー付きテストフェスト開催 直前対策セミナーの後に、実際の試験を受験する特別イベントを開催します。 今回は、「Oracle Certified Java Programmer, Silver SE 8」試験を受験する方を対象とした直前対策セミナー+テストフェストです。試験対策の総仕上げを行い試験にチャレンジしてください。 Oracle University 無償セミナー (1月) Oracle University のセミナーに参加しませんか。みなさまのスキルアップを応援します! ORACLE MASTER、オラクル認定 Java 資格の無償試験対策セミナーをはじめ、ORACLE MASTER の最高峰資格である ORACLE MASTER Platinum の試験を解説するセミナーを実施します。

  1/16 開催:Oracle IDEAワークショップ カスタマージャーニーワークショップと実行のギャップを埋める!オラクル独自のイノベーションプロセスをご紹介。参加型のプログラムで、サンプルペルソナを用いて、カスタマージャーニーマップの作成、アイデア出し、プロトタイプ作成、効果検証まで一連のプロセスを実際にご体験頂きます。 1/28 開催:実際に操作してみよう!! Oracle...

全国のOTNおすすめ技術者向けセミナー&イベント(2018年11月)

  【東京】 Oracle OpenWorldフィードバックセミナー 2018年 11月13日 15:00 – 17:00 @日本オラクル株式会社 本社(東京・外苑前) 10/22から10/25にかけてサンフランシスコで行われたOracle OpenWorld 2018。そこで発表された新製品や新機能の活用方法とともに、注目すべき最新テクノロジー情報ををご紹介します。 【東京】 Oracle University 無償セミナー(11月) 2018年 11月3日 13:00 – 17:00 @日本オラクル株式会社 本社(東京・外苑前) Oracle Database Cloud と連携するクラウド・アプリケーション開発セミナーや、Oracle Database Cloud Service 試験対策セミナーを実施します。その他、技術者のスキルアップを応援するセミナーを多数ご用意しています。 【東京】 直前対策セミナー付きテストフェスト開催 2018年11月 @日本オラクル株式会社 トレーニングキャンパス赤坂(東京・赤坂) 直前対策セミナーの後に、実際の試験を受験する特別イベントを開催します。ORACLE MASTER と Oracle 認定 Java 資格受験を検討されてい方は、この機会に是非チャレンジしてください。    

  【東京】 Oracle OpenWorldフィードバックセミナー 2018年 11月13日 15:00 – 17:00 @日本オラクル株式会社 本社(東京・外苑前) 10/22から10/25にかけてサンフランシスコで行われたOracle OpenWorld 2018。そこで発表された新製品や新機能の活用方法とともに、注目すべき最新テクノロジー情報ををご紹介します。 【東京】 Oracle...

基本からわかる!高性能×高可用性データベースシステムの作り方 第8回 バックアップ/リカバリ(3)RMAN増分バックアップとリストア/リカバリ

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   第7回ではRMANのバックアップ/リカバリの仕組みと、データ・リカバリ・アドバイザについて説明しました。今回は、バックアップ・ファイルのサイズを小さくする増分バックアップを扱います。増分バックアップをリストア/リカバリするには、どのバックアップ・ファイルをリストアし、どこの時点のREDOログからリカバリが開始されるのでしょうか。増分バックアップの欠点を改善する増分更新バックアップについても解説します。   1 フルバックアップからのリストア/リカバリ データベースの障害に備え、バックアップを取得しておくことは実質的に必須の運用です。最も基本的なバックアップは、データファイル全体を取得するフルバックアップです。フルバックアップを取得したデータベースでデータファイルに障害が発生した場合、リカバリ、つまりREDOログの適用はデータファイルのバックアップの取得を開始した時点からになります。そのため、リカバリ時間を最小にするためには、リストアするデータファイルは最も新しいバックアップからのものを優先します。RMANでは、フルバックアップを複数世代保持していると、restoreコマンドは自動的に最新のフルバックアップからリストアします。   フルバックアップのメリットは、すべてのデータブロックの直近のバックアップがあるため、リカバリ時間が最小になることです。リカバリ時間の観点からは、バックアップの間隔は短い方が良いのですが、フルバックアップをローカル・ストレージに何世代も保持することはストレージ容量の観点からはあまり現実的ではありません。そこで、前回のバックアップから更新されたデータブロックのみをコピーするという増分バックアップの機能がRMANにはあります。   2 増分バックアップ Oracle DatabaseではSystem Change Number(SCN)という単調増加するカウンタで更新の順序を管理しています。データファイルの各データブロックは更新されたときのSCNを記録しており、前回のバックアップ時点のSCNと比較することで、前回のバックアップから更新されたかを判断することができます。 増分バックアップの起点となるすべてのデータブロックのバックアップをlevel 0と呼びます。フルバックアップもlevel 0増分バックアップのどちらもすべてのデータブロックをコピーするというものですが、意味としては異なります。増分バックアップを取得するには、フルバックアップではなく増分バックアップのlevel 0をまず取得する必要があります。level 0の増分バックアップを取得するコマンドは以下のようになります。 RMAN> backup incremental level 0 database; level 0の時点から更新されたデータブロックの増分バックアップをlevel 1と呼びます。増分バックアップは前回のバックアップ時点から更新されたブロックを抜き出したものですが、「前回のバックアップ」が何を指すかによって、差分増分バックアップと累積増分バックアップの2種類があります。   差分増分バックアップは前回の増分バックアップ時点から更新されたデータブロックを抜き出します。1回目のlevel 1はlevel 0からの増分ですが、2回目以降のlevel 1は前回のlevel 1からの増分です。差分増分バックアップのコマンドは以下のようになります。 RMAN> backup incremental level 1; 累積増分バックアップはlevel 0増分バックアップ時点から更新されたデータブロックを抜き出します。1回目のlevel 1はlevel 0からの増分です。そして、2回目以降のlevel 1もlevel 0からの増分です。そのため、累積増分バックアップのファイル・サイズはバックアップを取得するにつれ徐々に大きくなっていきます。累積増分バックアップのコマンドはcumulativeというキーワードが付きます。 RMAN> backup incremental cumulative level 1; 累積増分バックアップよりも差分増分バックアップの方がlevel 1バックアップのファイル・サイズが小さくなるため優れているように思えますが、必ずしもそうとは言い切れません。違いはリストア/リカバリにも現れます。   3 増分バックアップからのリストア/リカバリ level 1バックアップはデータファイルの断片であるため、リストア/リカバリするためにはまず起点となるlevel 0バックアップをリストアします。その上にlevel 1バックアップをリストアします。差分増分バックアップと累積増分バックアップでは、どのlevel 1バックアップをリストアするかが異なります。   3.1 差分増分バックアップからのリストア/リカバリ 差分増分バックアップは前回の差分増分バックアップからの増分であるため、リストアするのはlevel 0とすべてのlevel 1になります。   差分増分バックアップからのリストア/リカバリもフルバックアップの場合と同様にRMANのrestoreコマンドとrecoverコマンドを使用します。restoreコマンドを発行するとlevel 0バックアップがリストアされます。 RMAN> restore datafile xx; そして、level 1バックアップがリストアされるのはrecoverコマンドを発行したときです。 RMAN> recover datafile xx; recoverコマンドを発行すると、RMANはすべてのlevel 1差分増分バックアップを正しい順序でリストアし、REDOログを適用します。REDOログの適用は最新のlevel 1を取得したところからです。   3.2 累積増分バックアップからのリストア/リカバリ 累積増分バックアップはlevel 0からの増分であるため、最新のlevel 1は以前に取得したlevel 1のすべての更新を含んでいます。そのため、リストアするのはlevel 0と最新のlevel 1のみです。   累積増分バックアップからのリストア/リカバリに使用するコマンドは差分増分バックアップの場合と同じです。restoreコマンドを発行するとlevel 0バックアップがリストアされます。 RMAN> restore datafile xx; そして、level 1バックアップがリストアされるのはrecoverコマンドを発行したときです。 RMAN> recover datafile xx; このとき、リストアされるのは最新のlevel 1累積増分バックアップのみです。その後、REDOログが適用されます。REDOログの適用は最新のlevel 1を取得したところからです。 差分増分バックアップはlevel 1バックアップのファイル・サイズが小さくなりますが、level 0とすべてのlevel 1差分増分を順にリストアしていく必要があります。これに対し、累積増分バックアップではlevel 1累積増分バックアップのファイル・サイズは徐々に大きくなっていきます。しかしリストアはlevel 0と最新のlevel 1累積増分のみで、差分増分バックアップよりもリストア時間の短縮が期待できます。 差分増分バックアップと累積増分バックアップには一長一短があります。これらのすきまを埋めるため、Oracle Database 10gで増分更新バックアップという機能が実装されました。   3.3 増分更新バックアップ 増分バックアップはフルバックアップに比べてファイル・サイズを小さくすることができますが、リストアにかかる時間が長くなります。増分更新バックアップのアイデアは、level 0バックアップにあらかじめlevel 1を適用したものをバックアップ側に用意しておくというものです。すると、リストアは、最新のlevel 1バックアップを取得した時点のデータファイル全体のイメージ1回で済みます。そして、REDOログの適用は最新のlevel 1バックアップを取得した時点のところからです。   増分更新バックアップは2つの操作から構成されます。1つ目は増分バックアップの取得で、2つ目は増分バックアップの適用です。 増分更新バックアップのためのコマンドにはfor recover of copyというキーワードが付きます。増分更新バックアップのためのlevel 1は差分増分でも累積増分のどちらでも構いません。 RMAN> backup incremental level 1 for recover of copy with tag 'incr_update' database; このコマンドはlevel 1となっていますが、もしlevel 0が取得されていなければ自動的にlevel 0が取得されます。tagはバックアップを区別する識別子です。 level 1を取得したら、recover copyコマンドでそれをlevel 0に適用します。 RMAN> recover copy of database with tag 'incr_update'; 増分更新バックアップからのリストア/リカバリの手順はフルバックアップや通常の増分更新バックアップと同じです。まず、該当するデータファイルをオフラインにし、restoreコマンドでリストアします。 RMAN> restore datafile xx; このとき、リストアされるのはlevel 1バックアップが適用されたlevel 0のデータファイルであり、リストアはこの1回のみです。リストアが完了したら、recoverコマンドでREDOログを適用します。 RMAN> recover datafile xx; リカバリが完了したら、該当データファイルをオンラインにするとSQLの実行が可能になります。 フルバックアップ、差分増分バックアップ、累積増分バックアップそして増分更新バックアップを説明してきましたが、どのバックアップ方法を選択してもRMANでのリストア/リカバリの手順は同じになることに気づかれたでしょうか?どのバックアップ方法であったとしても、restore/recoverコマンドは適切なバックアップ・ファイルを自動的に選択します。   4 Zero Data Loss Recovery Applianceの仮想フルバックアップ データファイル障害に備えて、最新のデータファイルに近い状態にしておく目的では増分更新バックアップは優れた機能です。しかし、増分更新バックアップでlevel 0にlevel 1を適用すると、それをロールバックすることはできません。また、REDOログによる更新の適用も時間を進める方向には可能ですが、時間をさかのぼる方向に変更することはできません。 テストなどで過去の状態のデータベースを複製したいというのはよくあることです。過去の状態のデータベースを複製するには、目的の時刻よりも前の時刻のフルバックアップもしくはlevel 0バックアップが必要です。そのため、過去の状態のデータベースを複製するという要件がある場合は、フルバックアップもしくはlevel 0を複数世代持つことになります。 Oracle Zero Data Loss Recovery Appliance(ZDLRA)はこれを特異な方法で解決します。ZDLRAはストレージに実体としてはlevel 1増分バックアップによるデータファイルの断片を保持するのですが、このデータファイルの断片をつなぎ合わせて、任意のバックアップ時点のデータファイル全体のイメージを構成することができます。これを仮想フルバックアップと呼びます。そのため、level 0を取得するのは最初の1度だけでよく、以降はlevel 1のみです。仮想フルバックアップの仕組みによって、バックアップ・ファイルのサイズを小さく抑えつつも、データファイルの障害に備えて最新のイメージを用意したいという要件と、テストのために過去のイメージを用意したいという要件を両立します。   ページトップへ戻る▲    「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   第7回ではRMANのバックアップ/リカバリの仕組みと、データ・リカバリ・アドバイザについて説明しました。今回は、バックアップ・ファイルのサイズを小さくする増分バックアップを扱います。増分バックアップをリストア/リカバリするには、どのバックアップ・ファイルをリストアし、どこの時点のREDOログからリカバリが開始される...

全国のOTNおすすめ技術者向けセミナー&イベント(2018年10月)

【東京】 はじめて使う Oracle Database Cloud Service 2018年 10月02日 18:30 – 20:00 @日本オラクル株式会社 本社(東京・外苑前) 今後 Database Cloud Service をご使用される方のため、必要最低限な知識を習得していただくことを目的としています。データベース・デプロイメントの作成・管理、ネットワーク制御、ク ラウド・ツールの使用、スケールアップ作業といった Database Cloud 全般の解説に加え、より知識を深めていただくために、実際のDatabase Cloud環境を使用したデモンストレーションも実施します。 【東京】 Autonomous Data Warehouse Cloud ハンズオン 2018年 10月05日 14:00 - 17:00 @日本オラクル株式会社 本社(東京・外苑前) Autonomous Database Cloud のご紹介、特徴や活用法についてご紹介し、実際にサービスを利用し、起動からデータロード、分析まで一連の流れを体感いただけます。 【東京】 Oracle Database Technology Night ~集え!オラクルの力(チカラ) 2018年10月10日 18:45 – 20:30 @日本オラクル株式会社 本社(東京・外苑前) Autonomous Databaseを支える基盤としても重要な Oracle Database 18c は、まずは Oracle Cloud と Exadata プラットフォームから提供開始されていましたが、7月よりいよいよ主要プラットフォームへ On-Premise のダウンロードが提供されました。そこでテック・ナイトでは、8月末より4回に渡って集中開催で "Oracle Database 18c テクノロジーシリーズ" と題し、各機能テーマごとに Oracle 18c の新機能や機能拡張を中心にポイントをお届けしています。 シリーズ最終回となる今宵は、Oracle Database 18c における SQL、PL/SQL や RAT、ユーティリティに対する機能拡張と、オプティマイザや In-Memory などパフォーマンス関連の機能強化についてお伝えします。   【東京】Oracle Code Night PGX ユーザー勉強会 #10「最新のグラフ分析フレームワーク Oracle Labs PGX を使ってみよう!」 2018年10月25日 17:30 – 19:45 @日本オラクル株式会社 本社(東京・外苑前) Oracle Labs PGX(Parallel Graph AnalytiX)は、グラフに対するクエリや分析のためのフレームワークです。本勉強会では、入門向けの解説に加え、実例を挙げての具体的な活用方法のご紹介など、実践に役立つTipsやユースケースに触れることが出来ます。ユーザーの皆様との交流を通じて、PGX情報交換の場としてもご活用ください。

【東京】 はじめて使う Oracle Database Cloud Service 2018年 10月02日 18:30 – 20:00 @日本オラクル株式会社 本社(東京・外苑前) 今後 Database Cloud...

基本からわかる!高性能×高可用性データベースシステムの作り方 第7回 バックアップ/リカバリ(2)RMANの基本

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   第6回ではオンライン・バックアップ/リカバリの仕組みと、ユーザー管理バックアップについて説明しました。今回は、物理バックアップのもう1つの選択肢であるRMAN(Recovery Manager)について解説します。RMANはOracle Databaseの構造を理解しているバックアップ・ツールであり、物理バックアップの第1選択肢です。データ・リカバリ・アドバイザを使用すると、障害個所の特定と復旧方法を自動生成することができます。   1 RMAN概要 RMANはOracle8で導入された物理バックアップ・ツールです。RMANでバックアップ/リストアを行うには、rmanコマンドでOracleインスタンスに接続します。rmanコマンドはアプリケーションからの接続と同様に、Oracleサーバー・プロセスを介してOracleインスタンスに接続します。Oracleサーバー・プロセスがOracleデータベースのファイルにアクセスする仕組みを使って、バックアップ/リストア/リカバリの操作を行います。   そのため、RMANはOracleデータベースの構造を理解しており、ユーザー管理バックアップではできなかったいくつかのことができるようになっています。 ASMファイルのバックアップ ASMはOracle Database専用のボリューム・マネージャ兼ファイルシステムであり、ASMファイルのバックアップにはRMANが必要です。 バックアップ中のファイルの検査 RMANはデータベース・ファイルの内部構造を理解しており、バックアップ中にファイルの破損を検出します。 増分バックアップ 前回のバックアップから更新されたデータブロックの増分をバックアップすることができます。 増分更新バックアップ フルバックアップにあらかじめ増分バックアップを適用しておくことができます。   RMANでのバックアップ/リストア/リカバリの時間を短縮するための機能は次回以降で解説する予定です。今回はまず基本のフルバックアップと、それを使用したリカバリを見ていきます。   2 RMANでバックアップ RMANでバックアップを取得してみましょう。まずはその前提の準備です。Oracle Databaseでは、オンライン・バックアップを取得するためにはアーカイブログ・モードである必要があります。また、バックアップ先として初期化パラメータDB_RECOVERY_FILE_DESTとDB_RECOVERY_FILE_DEST_SIZEが設定されているかを確認します。 $ sqlplus / as sysdba SQL> archive log list データベース・ログ・モード アーカイブ・モード 自動アーカイブ 有効 アーカイブ先 USE_DB_RECOVERY_FILE_DEST 最も古いオンライン・ログ順序 657 アーカイブする次のログ順序 659 現行のログ順序 659 SQL> select name,value from v$parameter where name like 'db_recovery_file%'; NAME VALUE ------------------------------ -------------------------------------------------- db_recovery_file_dest /u01/app/oracle/fast_recovery_area/SIDB18A db_recovery_file_dest_size 107374182400 rmanコマンドでログインするにはsqlplusコマンドと同様に、Oracleインスタンスが稼働しているOSに端末ログインしOS認証で接続する方法と、Oracleリスナー経由で接続する方法があります。 OS認証でログイン $ rman target / Oracleリスナー経由でログイン $ rman target sys/password@net_alias ここで、targetキーワードはバックアップ対象のデータベースにログインするという意味です。RMANでログインできたら、データベース全体をバックアップするbackup databaseコマンドを実行します。 $ rman target / Recovery Manager: Release 18.0.0.0.0 - Production on 金 9月 14 14:32:29 2018 Version 18.3.0.0.0 Copyright (c) 1982, 2018, Oracle and/or its affiliates. All rights reserved. ターゲット・データベース: SIDB18A (DBID=2255701400)に接続されました RMAN> backup database; backupを18-09-14で開始しています リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています チャネル: ORA_DISK_1が割り当てられました チャネルORA_DISK_1: SID=491 デバイス・タイプ=DISK チャネルORA_DISK_1: フル・データファイル・バックアップ・セットを開始しています チャネルORA_DISK_1: バックアップ・セットにデータファイルを指定しています 入力データファイル ファイル番号=00003 名前=/u01/app/oracle/oradata/SIDB18A/sysaux01.dbf 入力データファイル ファイル番号=00001 名前=/u01/app/oracle/oradata/SIDB18A/system01.dbf 入力データファイル ファイル番号=00005 名前=/u01/app/oracle/oradata/SIDB18A/undotbs01.dbf 入力データファイル ファイル番号=00007 名前=/u01/app/oracle/oradata/SIDB18A/users01.dbf チャネルORA_DISK_1: ピース1 (18-09-14)を起動します チャネルORA_DISK_1: ピース1 (18-09-14)が完了しました ピース・ハンドル=/u01/app/oracle/fast_recovery_area/SIDB18A/SIDB18A/backupset/2018_09_14/o1_mf_nnndf_TAG20180914T143236_fspkznlr_.bkp タグ=TAG20180914T143236 コメント=NONE チャネルORA_DISK_1: バックアップ・セットが完了しました。経過時間: 00:00:25 チャネルORA_DISK_1: フル・データファイル・バックアップ・セットを開始しています チャネルORA_DISK_1: バックアップ・セットにデータファイルを指定しています 入力データファイル ファイル番号=00009 名前=/u01/app/oracle/oradata/SIDB18A/pdb/sysaux01.dbf 入力データファイル ファイル番号=00011 名前=/u01/app/oracle/oradata/SIDB18A/pdb/users01.dbf 入力データファイル ファイル番号=00012 名前=/u01/app/oracle/oradata/SIDB18A/pdb/users201.dbf 入力データファイル ファイル番号=00010 名前=/u01/app/oracle/oradata/SIDB18A/pdb/undotbs01.dbf 入力データファイル ファイル番号=00008 名前=/u01/app/oracle/oradata/SIDB18A/pdb/system01.dbf チャネルORA_DISK_1: ピース1 (18-09-14)を起動します チャネルORA_DISK_1: ピース1 (18-09-14)が完了しました ピース・ハンドル=/u01/app/oracle/fast_recovery_area/SIDB18A/SIDB18A/6BC0721F0F147426E0532E97B90AEFA0/backupset/2018_09_14/o1_mf_nnndf_TAG20180914T143236_fspl0fs4_.bkp タグ=TAG20180914T143236 コメント=NONE チャネルORA_DISK_1: バックアップ・セットが完了しました。経過時間: 00:00:25 チャネルORA_DISK_1: フル・データファイル・バックアップ・セットを開始しています チャネルORA_DISK_1: バックアップ・セットにデータファイルを指定しています 入力データファイル ファイル番号=00006 名前=/u01/app/oracle/oradata/SIDB18A/pdbseed/undotbs01.dbf 入力データファイル ファイル番号=00004 名前=/u01/app/oracle/oradata/SIDB18A/pdbseed/sysaux01.dbf 入力データファイル ファイル番号=00002 名前=/u01/app/oracle/oradata/SIDB18A/pdbseed/system01.dbf チャネルORA_DISK_1: ピース1 (18-09-14)を起動します チャネルORA_DISK_1: ピース1 (18-09-14)が完了しました ピース・ハンドル=/u01/app/oracle/fast_recovery_area/SIDB18A/SIDB18A/6BBF79E8C8F75FCAE0532E97B90A997A/backupset/2018_09_14/o1_mf_nnndf_TAG20180914T143236_fspl16yl_.bkp タグ=TAG20180914T143236 コメント=NONE チャネルORA_DISK_1: バックアップ・セットが完了しました。経過時間: 00:00:03 backupを18-09-14で終了しました Control File and SPFILE Autobackupを18-09-14で開始しています ピース・ハンドル=/u01/app/oracle/fast_recovery_area/SIDB18A/SIDB18A/autobackup/2018_09_14/o1_mf_s_986826810_fspl1bgv_.bkp コメント=NONE Control File and SPFILE Autobackupを18-09-14で終了しました RMAN> backup databaseコマンドは、このコンテナ・データベースを構成するすべてのデータファイルのバックアップを取得します。RMANではbackupコマンドを発行したときにデータベースを構成するファイルが評価されるため、取り漏らしが発生しません。RMANで取得したバックアップの情報は、list backupコマンドで調べることができます。 RMAN> list backup; バックアップ・セットのリスト =================== BS Key Type LV Size Device Type Elapsed Time 終了時間 ------- ---- -- ---------- ----------- ------------ -------- 258 Full 2.38G DISK 00:00:05 18-09-14 BPキー: 258 ステータス: AVAILABLE 圧縮: NO タグ: TAG20180914T143236 ピース名: /u01/app/oracle/fast_recovery_area/SIDB18A/SIDB18A/backupset/2018_09_14/o1_mf_nnndf_TAG20180914T143236_fspkznlr_.bkp バックアップ・セット258のデータファイルのリスト File LV Type Ckp SCN Ckp時間 Abs Fuz SCN Sparse Name ---- -- ---- ---------- -------- ----------- ------ ---- 1 Full 19281773 18-09-14 NO /u01/app/oracle/oradata/SIDB18A/system01.dbf 3 Full 19281773 18-09-14 NO /u01/app/oracle/oradata/SIDB18A/sysaux01.dbf 5 Full 19281773 18-09-14 NO /u01/app/oracle/oradata/SIDB18A/undotbs01.dbf 7 Full 19281773 18-09-14 NO /u01/app/oracle/oradata/SIDB18A/users01.dbf BS Key Type LV Size Device Type Elapsed Time 終了時間 ------- ---- -- ---------- ----------- ------------ -------- 259 Full 1.81G DISK 00:00:04 18-09-14 BPキー: 259 ステータス: AVAILABLE 圧縮: NO タグ: TAG20180914T143236 ピース名: /u01/app/oracle/fast_recovery_area/SIDB18A/SIDB18A/6BC0721F0F147426E0532E97B90AEFA0/backupset/2018_09_14/o1_mf_nnndf_TAG20180914T143236_fspl0fs4_.bkp バックアップ・セット259のデータファイルのリスト コンテナID: 3、PDB名: PDB File LV Type Ckp SCN Ckp時間 Abs Fuz SCN Sparse Name ---- -- ---- ---------- -------- ----------- ------ ---- 8 Full 19281783 18-09-14 NO /u01/app/oracle/oradata/SIDB18A/pdb/system01.dbf 9 Full 19281783 18-09-14 NO /u01/app/oracle/oradata/SIDB18A/pdb/sysaux01.dbf 10 Full 19281783 18-09-14 NO /u01/app/oracle/oradata/SIDB18A/pdb/undotbs01.dbf 11 Full 19281783 18-09-14 NO /u01/app/oracle/oradata/SIDB18A/pdb/users01.dbf 12 Full 19281783 18-09-14 NO /u01/app/oracle/oradata/SIDB18A/pdb/users201.dbf BS Key Type LV Size Device Type Elapsed Time 終了時間 ------- ---- -- ---------- ----------- ------------ -------- 260 Full 878.02M DISK 00:00:02 18-09-14 BPキー: 260 ステータス: AVAILABLE 圧縮: NO タグ: TAG20180914T143236 ピース名: /u01/app/oracle/fast_recovery_area/SIDB18A/SIDB18A/6BBF79E8C8F75FCAE0532E97B90A997A/backupset/2018_09_14/o1_mf_nnndf_TAG20180914T143236_fspl16yl_.bkp バックアップ・セット260のデータファイルのリスト コンテナID: 2、PDB名: PDB$SEED File LV Type Ckp SCN Ckp時間 Abs Fuz SCN Sparse Name ---- -- ---- ---------- -------- ----------- ------ ---- 2 Full 14114869 18-08-08 NO /u01/app/oracle/oradata/SIDB18A/pdbseed/system01.dbf 4 Full 14114869 18-08-08 NO /u01/app/oracle/oradata/SIDB18A/pdbseed/sysaux01.dbf 6 Full 14114869 18-08-08 NO /u01/app/oracle/oradata/SIDB18A/pdbseed/undotbs01.dbf BS Key Type LV Size Device Type Elapsed Time 終了時間 ------- ---- -- ---------- ----------- ------------ -------- 261 Full 18.89M DISK 00:00:00 18-09-14 BPキー: 261 ステータス: AVAILABLE 圧縮: NO タグ: TAG20180914T143330 ピース名: /u01/app/oracle/fast_recovery_area/SIDB18A/SIDB18A/autobackup/2018_09_14/o1_mf_s_986826810_fspl1bgv_.bkp SPFILEも含まれます: 修正時間: 18-09-08 SPFILE db_unique_name: SIDB18A 含まれている制御ファイル: Ckp SCN: 19281806 Ckp時間: 18-09-14   3 データファイル破損からのリストア/リカバリ 第6回のユーザー管理バックアップの時と同様に、データファイルを破損させ、RMANでリストア/リカバリしてみましょう。ファイルを破損させるのは、そのファイルのバックアップを取得した後であることに注意してください。   3.1 行の位置の特定とデータファイルの破壊 プラガブル・データベースのtab2という表にアクセスするSQLを想定します。 SQL> select col1 from tab2 where col1=1; COL1 ---------- 1 このtab2表のcol1=1を含む行のデータブロックを特定し、そこを破壊します。まず、ファイル番号とデータブロック番号を調べます。 SQL> select col1, 2 DBMS_ROWID.ROWID_RELATIVE_FNO(rowid) fno, 3 DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) bno 4 from tab2 where col1=1; COL1 FNO BNO ---------- ---------- ---------- 1 12 131 ファイル番号12のデータファイルの名前を調べます。 SQL> select file#,name from v$datafile where file#=12; FILE# NAME ---------- ------------------------------------------------------------ 12 /u01/app/oracle/oradata/SIDB18A/pdb/users201.dbf このデータファイルをddコマンドで上書きし、破壊します。 $ dd if=/dev/zero of=/u01/app/oracle/oradata/SIDB18A/pdb/users201.dbf bs=8k count=1 seek=131 1+0 レコード入力 1+0 レコード出力 8192 バイト (8.2 kB) コピーされました、 0.000641312 秒、 12.8 MB/秒 障害が検出されるのは、Oracleのプロセスが破損した領域にアクセスしたときです。該当データブロックがデータベース・バッファキャッシュにあると、SQLの実行はデータファイルにはアクセスしません。そのため、データベース・バッファキャッシュをフラッシュしてからこのデータブロックにアクセスするSQLを実行します。 SQL> ALTER SYSTEM FLUSH BUFFER_CACHE; システムが変更されました。 SQL> select col1 from tab2 where col1=1; select col1 from tab2 where col1=1 * 行1でエラーが発生しました。: ORA-01115: ファイル(ブロック番号)からの読取りI/Oエラーが発生しました。 ORA-01110: データファイル12: '/u01/app/oracle/oradata/SIDB18A/pdb/users201.dbf' ORA-27072: ファイルI/Oエラーが発生しました。 Additional information: 3 Additional information: 65664 tab2表のcol1=1にアクセスするSQLがデータファイルの破損を検出しました。この障害をRMANを使用してリストア/リカバリします。   3.2 RMANのデータ・リカバリ・アドバイザでリストア/リカバリ RMANでもユーザー管理バックアップの場合と同様に、破損したデータファイルを管理者が特定し、リストアとリカバリの操作を個別に発行します。しかし、RMANにはこれらの一連の操作を自動化するデータ・リカバリ・アドバイザという機能があります。RACはサポートしていないなど、必ずしもすべての構成で使用できるわけではないのですが、通常ならば人間の判断を必要とする障害個所の特定と復旧方法の決定を自動化できる非常に強力なツールです。   3.2.1 認識された障害の表示 RMANのlist failureコマンドで、認識されている障害の一覧が表示されます。 RMAN> list failure; リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています データベース・ロール: PRIMARY データベース障害のリスト ========================= 障害ID 優先度ステータス 検出時間 サマリー ------ -------- --------- -------- ------- 5902 HIGH OPEN 18-09-14 SYSTEM以外のデータファイルが1つ以上破損しています   3.2.2 修復オプションの決定 RMANのadvise failureコマンドで修復方法を分析してくれます。   RMAN> advise failure; データベース・ロール: PRIMARY データベース障害のリスト ========================= 障害ID 優先度ステータス 検出時間 サマリー ------ -------- --------- -------- ------- 5902 HIGH OPEN 18-09-14 SYSTEM以外のデータファイルが1つ以上破損しています 自動修復オプションを分析中です。これには少し時間がかかる場合があります チャネル: ORA_DISK_1が割り当てられました チャネルORA_DISK_1: SID=491 デバイス・タイプ=DISK 自動修復オプションの分析が完了しました 必須の手動アクション ======================== 使用可能な手動アクションがありません オプションの手動アクション ======================= 使用可能な手動アクションがありません 自動修復オプション ======================== オプション 修復 説明 ------------------------ 1 データファイル12をリストアおよびリカバリします 計画: 修復には、データが損失しない完全なメディア・リカバリが含まれます 修復スクリプト: /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/hm/reco_2307471035.hm 障害の内容によっては、自動修復するためのスクリプトが生成されます。このスクリプトの中身を見てみましょう。 $ cat /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/hm/reco_2307471035.hm # restore and recover datafile sql 'PDB' 'alter database datafile 12 offline'; restore ( datafile 12 ); recover datafile 12; sql 'PDB' 'alter database datafile 12 online'; データファイルのリストアとリカバリの個別の手順はユーザー管理バックアップの場合と同様ですが、データ・リカバリ・アドバイザはこの一連の手順を自動生成してくれます。   3.2.3 障害の修復 advise failureコマンドで生成された自動復旧手段をrepair failureコマンドで実行します。 RMAN> repair failure; 計画: 修復には、データが損失しない完全なメディア・リカバリが含まれます 修復スクリプト: /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/hm/reco_2307471035.hm 修復スクリプトの内容: # restore and recover datafile sql 'PDB' 'alter database datafile 12 offline'; restore ( datafile 12 ); recover datafile 12; sql 'PDB' 'alter database datafile 12 online'; この修復を実行しますか(YESまたはNOを入力してください)。 YES 修復スクリプトを実行しています SQL文: alter database datafile 12 offline restoreを18-09-14で開始しています チャネルORA_DISK_1の使用 チャネルORA_DISK_1: データファイル・バックアップ・セットのリストアを開始しています チャネルORA_DISK_1: バックアップ・セットからリストアするデータファイルを指定しています チャネルORA_DISK_1: データファイル00012を/u01/app/oracle/oradata/SIDB18A/pdb/users201.dbfにリストアしています チャネルORA_DISK_1: バックアップ・ピース/u01/app/oracle/fast_recovery_area/SIDB18A/SIDB18A/6BC0721F0F147426E0532E97B90AEFA0/backupset/2018_09_14/o1_mf_nnndf_TAG20180914T143236_fspl0fs4_.bkpから読取り中です チャネルORA_DISK_1: ピース・ハンドル=/u01/app/oracle/fast_recovery_area/SIDB18A/SIDB18A/6BC0721F0F147426E0532E97B90AEFA0/backupset/2018_09_14/o1_mf_nnndf_TAG20180914T143236_fspl0fs4_.bkp タグ=TAG20180914T143236 チャネルORA_DISK_1: バックアップ・ピース1がリストアされました チャネルORA_DISK_1: リストアが完了しました。経過時間: 00:00:07 restoreを18-09-14で終了しました recoverを18-09-14で開始しています チャネルORA_DISK_1の使用 メディア・リカバリを開始しています メディア・リカバリが完了しました。経過時間: 00:00:01 recoverを18-09-14で終了しました SQL文: alter database datafile 12 online 障害の修復が完了しました RMAN> 障害から復旧すると、該当データブロックにアクセスするSQLは実行可能です。 SQL> select col1 from tab2 where col1=1; COL1 ---------- 1   4 データファイル以外のファイルのバックアップ 前述したRMANのbackupコマンドでは、データファイル以外にも制御ファイルとSPFILEのバックアップも取得されていました。これはRMANのconfigure controlfile autobackupコマンドの設定によるもので、デフォルトでは制御ファイルとSPFILEのバックアップも取得されます。 RMAN> show all; db_unique_name SIDB18AのデータベースにおけるRMAN構成パラメータ: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; # default CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/18/dbhome_1/dbs/snapcf_sidb18a.f'; # default また、アーカイブREDOログのバックアップを取得することもできます。 RMAN> backup archivelog all; しかし、アーカイブREDOログだけのバックアップを取得するということはあまりありません。第6回で説明したように、データファイルのオンライン・バックアップを取得するのはその間に生成されたREDOログ情報でリカバリすることが前提です。そのため、データファイルとREDOログのバックアップはセットで考慮すべきです。RMANにはデータファイルとREDOログをセットでバックアップするコマンドが用意されています。 RMAN> backup database plus archivelog; このコマンドでバックアップを取得すると、データファイルのバックアップの後にオンラインREDOログがアーカイブされ、そのアーカイブREDOログもバックアップされます。 今回はRMANの最も基本的な使い方であるフルバックアップと、復旧方法を自動生成するデータ・リカバリ・アドバイザについて説明しました。次回はRMANでのバックアップ/リストア/リカバリの時間を短縮する機能について説明する予定です。   ページトップへ戻る▲    「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶

「基本からわかる!高性能×高可用性データベースシステムの作り方」indexページ▶▶   第6回ではオンライン・バックアップ/リカバリの仕組みと、ユーザー管理バックアップについて説明しました。今回は、物理バックアップのもう1つの選択肢であるRMAN(Recovery Manager)について解説します。RMANはOracle Databaseの構造を理解しているバックアップ・ツールであり、物理バックアッ...

イベント&セミナー

全国のOTNおすすめ技術者向けセミナー&イベント(2018年9月)

【東京】Autonomous Data Warehouse Cloud ハンズオン 2018年9月11日 2:00 PM - 5:00 PM @日本オラクル株式会社 本社(東京・外苑前) 「Oracle Autonomous Data Warehouse Cloud」は、自律型データベース初めてのサービスで、データベースの自動稼働、自動保護、自動復旧を実現する、新しいクラウド上のサービスです。 お客様のデータ分析をより簡単に使いやすくし、かつ自動チューニングによる高いパフォーマンスを実現しています。手間のかかるクラスタやBackupの方式検討をすることなく、すぐにデータ分析を開始することが可能となります。もちろん、Oracle Exadata 上の Oracle 18c によるこのサービスは、簡単、比類ないデータロードと分析性能を発揮し、かつお客様の要件に沿った規模にいつでも変更できます。 本セミナーでは、Autonomous Database Cloud のご紹介、特徴や活用法についてご紹介し、実際にサービスを利用し、起動からデータロード、分析まで一連の流れを体感いただけます。 【東京】Oracle Database Cloud Service ハンズオン 2018年9月13日 1:00 PM - 5:30 PM @日本オラクル株式会社 本社(東京・外苑前) 「Oracle Cloud Platform」は、業界で最も包括的なサービスのラインアップを揃えるPaaS/IaaSです。 オンプレミス環境とパブリッククラウドで同一のアーキテクチャと製品を提供し、双方向の可搬性・連携性に優れたハイブリッドなクラウド開発環境