Oracle Database側のOracle Big Data SQLのインストールまたはアップグレード

3 Oracle Database側のOracle Big Data SQLのインストールまたはアップグレード

Oracle Big Data SQLは、Hadoopクラスタ管理サーバーとOracle Databaseシステムの両方にインストールする必要があります。この項では、単一インスタンス・システムとRACシステムの両方でのOracle Big Data SQLのインストールについて説明します。

3.1 データベース側のインストールを開始する前に

インストールを開始する前に、この項のポイントを確認します。

Oracle Big Data SQLの現在のバージョンがOracle Databaseシステムにすでにインストールされており、既存の構成に変更を加えている場合は、インストール・プロセス全体を繰り返す必要はありません。「既存のOracle Big Data SQLインストールの再構成」を参照してください。

重要:

データベース所有者ユーザーとしてSQL*Plusへの匿名接続を使用してログインする場合は、ORACLE_HOMEおよびORACLE_SID環境変数が適切に設定されていることを最初に確認してください。グリッド・インフラストラクチャがシステムで実行されており、その場所がORACLE_HOMEに対して相対でない場合は、GI_HOMEも設定する必要があります。
マルチノード・データベース(Oracle RACシステムなど)の場合、このインストールをデータベースの各コンピュート・ノードで繰り返す必要があります。これを実行していない場合、Oracle Big Data SQLサービスを開始すると、RPC接続エラーが表示されます。
Gridが稼働中のデータベース・ノードのルートにはパスワードなしSSHを設定することをお薦めします。そうしないと、各ノードでインストール時に資格証明を指定する必要があります。
インストールの前にまだdiskmonプロセスが稼働していない場合、インストールを完了するためには、Gridインフラストラクチャの再起動が必要になります。
複数のHadoopクラスタから同じデータベースへのOracle Big Data SQL接続を設定する場合は、各接続の構成が同じであることを確認してください。インフィニバンドを使用する接続とイーサネットを使用する接続を設定しないでください。同様に、1つの構成でデータベース認証を有効にする場合は、異なるHadoopクラスタと同じデータベース間のすべてのOracle Big Data SQL接続でこの機能を有効にする必要があります。
データベース・システムがKerberosで保護されている場合、データベース所有者プリンシパルの認証を実行できるのは1つのKDCのみであることに留意してください。Oracle Big Data SQLは、現時点では複数のKerberosチケットをサポートしていません。複数のHadoopクラスタ接続が同じデータベース所有者によってインストールされる場合は、すべてが同じKDCを使用する必要があります。

KRB5_CONF環境変数は、1つの構成ファイルのみを指している必要があります。構成ファイルが存在している必要があり、変数自体はシステム起動時にデータベース所有者アカウントに対して設定されている必要があります。

各データベース・コンピュート・ノードにKerberosクライアントがインストールされていることを確認してください。

また、Hadoop側で使用されるプリンシパルがデータベース所有者のプリンシパルと同じでない場合は、データベース側のインストールを実行する前に、KDCからOracle Database側に正しいプリンシパルをコピーする必要があります。次に、インストーラを実行するとき、インストーラに正しいkeytabを指示するために、コマンドラインに--alternate-principalパラメータを含めます。bds-database-install.shのコマンドライン・パラメータ・リファレンスを参照してください
Oracle Grid Infrastructureの下で実行しているデータベースに、同じタイプの複数のネットワーク・インタフェース(2つ以上のEthernet、2つ以上のInfiniBandまたは2つ以上のEthernet-over-InfiniBandインタフェース)が存在していると、常に、インストールによってアルファベット順で最初になる名前のインタフェースが選択されます。

関連項目:

詳細は、「Grid Infrastructureのシステムに同じタイプの複数のネットワーク・インタフェースがある際の特別な考慮事項」を参照してください。

3.1.1必要なグリッド・パッチの確認

Oracle Big Data SQLで必要なOracle Grid Infrastructureのすべてのパッチがインストールされていることを確認します。

Oracle Big Data SQLマスター互換性マトリクス(My Oracle SupportのDoc ID 2119369.1)をチェックして、パッチ要件に関する最新情報を確認します。

3.1.2 グリッド・インフラストラクチャの再起動要件の可能性

特定のデータベース環境では、bds-database-install.shでcellinit.oraまたはcelliniteth.ora(あるいはその両方)を作成する必要があります。このような場合、スクリプトは同じような変更をGridインフラストラクチャ内のすべてのノードに伝播しようとします。このために、スクリプトではoracleとroot間にパスワードなしSSHを設定することが要求されるか、または実行時にノードごとにルートのパスワードが求められます。変更の性質によってGridインフラストラクチャの再起動が必要となる場合、スクリプトによってGridインフラストラクチャを手動で再起動する必要があることを示すメッセージも表示されます。再起動が必要な場合、Gridの資格証明なしではインストールを完了することはできないため、Gridのパスワードが手元にあることを確認してください。

3.1.2.1 いつグリッドまたはデータベースの再起動が必要であるかの判断

Oracle Big Data SQLのデータベース側では、diskmonプロセスはHadoopクラスタとの通信の役割を担うエージェントです。これはOracle Exadata Database Machine上の機能と同様、コンピュート・ノードとストレージ・ノード間の通信を管理します。

Grid環境では、diskmonはGridユーザーによって所有されます。Grid環境以外では、Oracle Databaseの所有者によって所有されます。

Oracle Big Data SQLでは、diskmon設定は、/etc/oracle/cell/network-config/ディレクトリ内のcellinit.oraおよびcelliniteth.oraファイル上に格納されます。クラスタの接続要件に従い、インストーラによってこれらのファイルは更新されます。

これは、いつGridまたはOracle Databaseを再起動する必要があるかどうかを判断するための方法です。

インストーラで旧版のcellinit.oraまたはcelliniteth.oraファイルが存在しないことが検出された場合、いずれのdiskmonプロセスも実行していないことを意味します。このような場合、環境にOracle Gridが含まれているのであれば、Gridを再起動する必要があります。環境にGridが含まれていない場合は、Oracle Databaseを再起動する必要があります。
旧版のcellinit.oraまたはcelliniteth.oraファイル(あるいはその両方)が存在する場合は、diskmonプロセスが実行していることを示します。この場合、インストーラでこれらのファイルに変更を加える必要がなければ、データベースのみを再起動する必要があります。
マルチノードのGrid環境では、diskmonはすべてのノード上で単一のコンポーネントとして機能し、cellinit.oraおよびcelliniteth.oraがすべてのノード上で同期化される必要があります。このタスクは、SSHを介して行われます。クラスタ上でパスワードなしSSHが設定されている場合は、ユーザーの操作は必要ありません。パスワードなしSSHが設定されていない場合は、スクリプトは一時停止し、すべてのノードに対してrootの資格証明を入力することが求められます。すべてのノード間のcellinit.oraおよびcelliniteth.oraファイルが同期化されている場合は、スクリプトは続行します。その後、スクリプトが完了し、この場合はGridインフラストラクチャを再起動する必要があります。

3.1.3 Grid Infrastructureのシステムに同じタイプの複数のネットワーク・インタフェースがある際の特別な考慮事項

こうした環境では、セルとの通信に間違ったIPアドレスが選択されることが原因で、Oracle Big Data SQLインストールやSmartScan操作が失敗する可能性があります。

Oracle Grid Infrastructure内にOracle Big Data SQLをインストールするときに、ノード上のOracle Big Data SQLセルとの通信用に特定のIPアドレスを選択するようにインストーラに指定できません。この環境では、ネットワーク・インタフェースの選択が自動的に判断されます。この判断は間違っていることがあり、データベース側のインストールに失敗するインスタンスが存在する場合や、SmartScanが機能していないことが後に判明する場合があります。

この問題は手動で解決できますが、まず、どのネットワーク・インタフェースがインストールで選択されるかを理解しておくことが役立ちます。

Grid Infrastructureのシステムにある同じタイプの複数のインタフェースからインストールが選択する方法

diskmonプロセスは、データベースではなくOracle Grid Infrastructureによって制御されます。Oracle Big Data SQLセルとの通信は、Gridによって管理されます。
このような場合は、Oracle Big Data SQLインストーラによってcellinit.oraとcelliniteth.oraが作成されることも、これらのファイルに保存されているセルの設定が更新されることもありません。こうした環境では、Gridによってタスクが処理されます(すべてのノード間で同期する必要があるクラスタ全体のタスクであるため)。
複数のネットワーク・インタフェースがある場合、セルに対するGrid管理の更新では、それぞれのノードで適切なタイプの最初のネットワーク・インタフェースが自動的に選択されます。その際、アルファベット順で最初になる名前の付いたインタフェースが選択されます。

次の例は、Grid Infrastructureのシステムを示しています。このシステムには、複数のInfiniBand、EthernetおよびEthernet over InfiniBand (bondeth*)ネットワーク・インタフェースがあります。インタフェースのリストは次のとおりです。

[root@mynode ~]# ip -o -f inet addr show
1: lo    inet 127.0.0.1/8 
2: eth0    inet 12.17.207.156/21 
3: eth1    inet 16.10.145.12/21 
19: bondeth0    inet 12.17.128.15/20 
20: bondeth2    inet 16.10.230.160/20 
21: bondeth4    inet 192.168.1.45/20 
30: bondib0    inet 192.168.31.178/21 
31: bondib1    inet 192.168.129.2/21 
32: bondib2    inet 192.168.199.205/21 
33: bondib3    inet 192.168.216.31/21 
34: bondib4    inet 192.168.249.129/21

このシステムでOracle Big Data SQLインストーラが実行されると、次に示すインタフェースが選択されます。

cellinit.oraで構成されたInfiniBand接続には、192.168.31.178/21が選択されます。

このシステムにあるInfiniBandインタフェースのうち、アルファベットの昇順ソートで最初になるインタフェース名はbondib0です。
celliniteth.oraで構成されたEthernet-over-InfniBand接続には、12.17.128.15/20が選択されます。

ノート:
この例では、標準イーサネットよりもEthernet over InfiniBandが優先されるという追加の選択要因が示されています。
この場合、bondeth0というインタフェース名が最初になります。

このような条件下でインストール(またはSmartScan)が失敗することがある理由

diskmonは、前述のロジックに従って選択されたネットワーク・インタフェースを通じてOracle Big Data SQLのセルに接続できない可能性があります。正しいサブネット(diskmonにアクセス可能なもの)は、アルファベット順で最初に表示されない場合があります。

問題を修正する方法

このIPアドレスは、cellinit.oraファイルとcelliniteth.oraファイルで手動で変更できます。これらのファイルは、各ノードの/etc/oracle/cell/network-configにあります。

CRSプロセスを停止します。(セルの編集前に必ず実行してください。実行していないと、diskmonがハングする可能性があります)。
cellinit.oraとcelliniteth.oraのどちらか(または両方)を編集します。IPアドレスを必要に応じて変更します。
CRSを再起動します。

3.2 データベース側のインストール・ディレクトリについて

インストールのデータベース側を開始するには、データベース側のインストール・バンドルを解凍し、含まれている実行ファイルを実行します。実行ファイルによって、$(orabasehome)/BDSJaguar-4.1.2の下にインストール・ディレクトリが作成されます。次に例を示します。

$(orabasehome)/BDSJaguar-4.1.2/cdh510-6-node1.mycluster.<domain>.com

Oracle Big Data SQLのインストールは、このディレクトリの作成時には完了していません。ディレクトリは、データベース・ノードでインストールを完了するために必要なすべてのファイルが含まれているステージング領域です。

データベースと複数のHadoopクラスタ間にOracle Big Data SQL接続を確立できます。各接続は個別のデータベース側のインストールを介して確立されるため、個別のインストール・ディレクトリが作成されます。インストール・ディレクトリの名前に含まれるセグメントにより、この特定の接続でのHadoopクラスタを識別できます。

<Hadoop cluster name>-<Number nodes in the cluster>-<FQDN of the cluster management server node>

このディレクトリを保持する必要があります。これは、インストールの最新の状態を取得し、必要に応じてそれを使用してインストールを再生成できます。さらに、今後Hadoopクラスタの変更にあわせてインストールのデータベース側の調整が必要になった場合、Jaguarのreconfigureコマンドによって生成された更新がこのディレクトリに適用されます。

oracle (または他のデータベース所有者)以外のユーザーによってインストール・ディレクトリが変更または削除されないように、権限の適用を検討してください。

3.3 Oracle Databaseノードでのインストール・ステップ

Oracle Big Data SQLのデータベース側をインストールするには、Hadoopクラスタ管理サーバーに作成されたデータベース側のインストール・バンドルが含まれているzipファイルをコピーして、それを解凍し、含まれている実行ファイルを実行してから、インストーラを実行します。

データベース所有者(oracleなど)として、この項の手順を実行します。バンドルは一時ディレクトリにステージングしますが、バンドルを解凍し、含まれている実行ファイルを実行した後、インストール・パッケージは$(orabasehome)の下のサブディレクトリにインストールされます。たとえば、$(orabasehome)/BDSJaguar-4.1.2/cdh510-6-node1.mycluster.<domain>.comなどです。

開始する前に、ORACLE_HOMEおよびORACLE_SIDが正しく設定されていることを確認してください。また、bds-database-install.shのコマンドライン・パラメータ・リファレンスでスクリプト・パラメータを確認して、特定の環境のインストール・コマンドに含める必要があるパラメータを把握する必要があります。

インストールの実行回数

各データベースのインスタンスごとにインストールを実行する必要があります。たとえば、単一の2ノードRACに、非CBDデータベースおよびCBDデータベース(次の例ではそれぞれDBAおよびDBB)がある場合は、次のように両方のノードにOracle Big Data SQLをインストールします。

ノード1の場合

./bds-database-install.sh --db-resource=DBA1 --cdb=false   
./bds-database-install.sh --db-resource=DBB1 --cdb=true

ノード2の場合

./bds-database-install.sh --db-resource=DBA2 --cdb=false
./bds-database-install.sh --db-resource=DBB2 --cdb=true

コンポーネントのコピーおよびインストールの準備

ノード1からノードnまで順番に、各データベース・ノードにソフトウェアをコピーしてインストールします。

まだそうしていない場合は、希望の方法を使用して、Hadoopクラスタ管理サーバーからOracle Databaseサーバーにデータベース側のインストール・バンドルをコピーします。バンドルが複数ある場合は、Oracle Databaseに接続するクラスタに適切なバンドルを選択してください。一時ステージング領域として使用する任意のセキュアなディレクトリにバンドルをコピーします。
この例では、バンドルが/opt/tmpにコピーされます。
```
scp root@<hadoop node name>:/opt/oracle/BDSJaguar/db-bundles/bds-4.1.2-db-<Hadoop
    cluster>-200421.0517.zip /opt/tmp
```
データベース・リクエスト・キーを生成した場合は、そのキーもOracle Databaseサーバーにコピーします。
```
# scp root@<hadoop node name>:/opt/oracle/BDSJaguar/dbkeys/<database name or other name>.reqkey oracle@<database_node> /opt/tmp
```
次に、cdを使用して、ファイルをコピーしたディレクトリに移動します。
バンドルを解凍します。これには、単一の圧縮された実行ファイルが含まれています。
前提条件の環境変数($ORACLE_HOMEおよび$ORACLE_SID)が設定されていることを確認します。
バンドルを$(orabasehome)に解凍するには、このファイルを実行します。次に例を示します。
```
$ ./bds-4.1.2-db-cdh510-170309.1918.run
```
Oracle Databaseインスタンスと複数のHadoopクラスタの間に独立したOracle Big Data SQL接続を設定できるため、runコマンドにより$(orabasehome)/BDSJaguar-4.1.2の下のクラスタ固有ディレクトリにバンドルが解凍されます。次に例を示します。
```
$ ls $(orabasehome)/BDSJaguar-4.1.2
  cdh510-6-node1.mycluster.<domain>.com
  test1-3-node1.myothercluster.<domain>.com
```
BDSJaguar-4.1.2ディレクトリがまだ存在しない場合は、そのディレクトリも作成されます。
データベース・リクエスト・キーを生成した場合は、新しく作成したインストール・ディレクトリにそれをコピーします。たとえば:
```
$ cp /opt/tmp/mydb.reqkey $(orabasehome)/BDSJaguar-4.1.2/cdh510-6-node1.mycluster.<domain>.com
```
ヒント:

また、キー・ファイルを一時的な場所に置いておき、そのキー・ファイルが存在する場所をスクリプトに指示するためにインストール・コマンドで--reqkeyパラメータを使用することもできます。このパラメータでは、デフォルト以外のリクエスト・キーのファイル名またはパス、あるいはその両方を指定できます。

ただし、インストール・スクリプトがインストール・ディレクトリ内のキーを検出するのは、キー・ファイル名がデータベース名と同じ場合のみです。それ以外の場合、キーがローカルであっても、異なる名前をキーに付けた場合には、インストール・スクリプトが識別できるように引き続き--reqkeyを使用する必要があります。
Hadoop側で使用されるKerberosプリンシパルとは異なるKerberosプリンシパルで認証する場合は、プリンシパルのkeytabをインストール・ディレクトリにコピーします。
インストールの両側で同じプリンシパルを使用する場合は、このステップをスキップしてください。Hadoopクラスタで認証に使用されたkeytabのコピーは、すでにインストール・ディレクトリにあります。

クラスタのインストール・ディレクトリを用意したら、Oracle Big Data SQLのデータベース側をインストールするための準備は完了です。

Oracle DatabaseノードでのOracle Big Data SQLのインストール

重要:

インストールの最後に、次のいずれかまたは両方の条件においてOracle Databaseの再起動が1回必要になることがあります。

Oracle DatabaseにOracle Grid Infrastructureが含まれていない場合。この場合、diskmonのスタンドアロン操作をサポートするために、インストール・スクリプトによってpfileまたはspfile構成ファイルが変更されます。
cellinit.oraに記録されているIPアドレスおよび通信プロトコルに変更がある場合。これらのパラメータは、Hadoopクラスタ上のセルへの接続を定義します。たとえば、これが再インストールで、Hadoop/Oracle Database接続のIPアドレスがイーサネット・アドレスからインフィニバンド・アドレスに変更されるか、プロトコルが(TCPとUDP間で)変更されるか、またはその両方の場合、データベースを再起動する必要があります。

データベースが実行中でない場合には起動します。
Oracle Databaseノードにデータベース所有者としてログオンし、ディレクトリを、$(orabasehome)/BDSJaguar-4.1.2の下のクラスタ固有インストール・ディレクトリに移動します。次に例を示します。
```
$ cd $(orabasehome)/BDSJaguar-4.1.2/cdh510-6-node1.my.<domain>.com 
```
データベース側のOracle Big Data SQLインストーラであるbds-database-install.shを実行します。オプションのパラメータをいくつか含める必要がある場合があります。
```
$ ./bds-database-install.sh [options]
```
データベースを再起動します(オプション)。

3.3.1 bds-database-install.shのコマンドライン・パラメータ・リファレンス

bds-database-install.shスクリプトには、多数のコマンドライン・パラメータを使用できます。各パラメータはオプションですが、このスクリプトには少なくとも1つのパラメータが必要です。

表3-1 bds-database-install.shのパラメータ

パラメータ	機能
`--install`	このクラスタへのOracle Big Data SQL接続をインストールします。ノート: 操作の途中で、このスクリプトは一時停止し、2番目のスクリプトをルートとして実行するように要求します。 `bds-database-install: root shell script /u03/app/masha/12.1.0/ dbhome_mydb/install/bds-database-install-10657-root-scriptclust1.sh please run as root: <enter> to continue checking.. q<enter> to quit bds-database-install: root` Rootとして、2番目の端末のセッションを開き、そこでスクリプトを実行します。そのスクリプトが完了したら、元の端末に戻り、[Enter]を押して`bds-database-install.sh`セッションを再開します。 Oracle Big Data SQLは一般ユーザー(スーパーユーザー以外)としてデータベース側にインストールしているため、rootユーザーまたはGridユーザー、あるいはその両方としてタスクを実行する必要がある場合には、`bds-database-install.sh`が一時停止している間に、インストーラがそれらのアカウントの下で他のスクリプトを実行できるようにシェルを生成する必要があります。以前の一部のリリースでは、その他のパラメータが指定されていない場合、`--install`パラメータが暗黙的に選択されました。現在、インストールを行うには、このパラメータを明示的に含める必要があります。
`--version`	`bds-database-install.sh`スクリプトのバージョンを示します。
`--info`	クラスタ名、クラスタ管理サーバー・ホスト、Webサーバーなど、クラスタに関する情報を表示します。
`--grid-home`	Oracle Gridホーム・ディレクトリを指定します。
`--crs`	Oracle Big Data SQL MTA extprocを設定するには、`crsctl`を使用します。Grid以外の環境では無視されます。 `--crs={true\|false}` インストーラは、Gridが実行されているかどうかを常に検証します。Gridが実行されていない場合、インストーラはGridがインストールされておらず、データベースが単一インスタンスであると見なします。次に、`crs`フラグを`false`に自動的に設定します。 `--crs=true`が明示的に設定されておらず、Gridが見つからない場合、インストーラは`GI_HOME`を設定する必要があることを通知するエラー・メッセージで終了します。
`--alternate-principal`	このオプション・パラメータでは、データベース所有者以外のKerberosプリンシパルを指定できます。`--install`、`--reconfigure`および`--uninstall`パラメータと組み合せて使用できます。詳細は、後述のデータベース側での代替Kerberosプリンシパルの使用についてを参照してください。
`--alternate-repo`	CDH 6は、クライアント・インストールにyumを使用します。`--alternate-repo`パラメータを使用すると、インストーラがデータベース側でBig Data SQLのインストールを完了するために必要なHadoop、HiveおよびHBase RPMを取得するための任意のyumリポジトリを指定できます。(インストールのHadoop側の`bds-config.json`構成ファイルにあるオプションの`url`および`dir`パラメータも、リポジトリへのポインタを作成するためのものですが、これらのパラメータはCDH 6システムでは無視されます。) 6.3.3より前のCDH 6.xの場合、`--alternate-repo`はオプションです。インターネット・アクセスが開いている場合、Hadoop側のJaguarインストーラは、デフォルトで、公開Clouderaリポジトリからクライアントをダウンロードし、生成するデータベース側のインストール・バンドルに統合できます。インターネットにアクセスできない場合、またはクライアントを別のローカルまたはリモート・リポジトリからダウンロードする場合は、`--alternate-repo`を使用します。インストーラがClouderaリポジトリ(または他の場所)から直接ダウンロードできるようにするには、このCDH 6.2.1の例のように、URLを渡します。 `# ./bds-database-install.sh --alternate-repo="https://archive.cloudera.com/cdh6/6.2.1/<Red Hat OS version>/yum/" <other parameters>` CDH 6.3.3以降の場合は、これらのリリースのファイルをClouderaからダウンロードするためにClouderaのログイン資格証明を指定する必要があるため、`--alternate-repo`が必要です。Big Data SQLインストーラは、CDH 6.3.3以降のファイルを公開リポジトリから自動的にダウンロードできません。これらのリリースでは、次の例のように、Clouderaのユーザー・アカウントとパスワードを追加します。 `# ./bds-database-install.sh --alternate-repo="https://<Cloudera account name>:<Cloudera password>@archive.cloudera.com/p/cdh6/6.3.3/<Red Hat OS version>/yum/" <other parameters>` ノート: 適切なバージョンのHDFS、HiveおよびHBaseクライアントを含むローカルyumリポジトリを設定し、Cloudera公開リポジトリのかわりにそのローカル・リポジトリをポイントできます。 `# ./bds-database-install.sh --alternate-repo="<valid yum repository baseurl>" <other parameters>` ローカル・パッケージ・リポジトリの構成に関するClouderaの手順を参照してください。データベース・システムでHTTPが使用できない場合は、いくつかのオプションがあります。前述のURLにあるClouderaの記事で説明されているように、軽量HTTPサーバーを一時的にインストールしてから、Big Data SQLのインストール後に削除します。 HTTPを選択できない場合、インターネット・アクセスがあるマシン上でClouderaリポジトリのローカル・ミラーを作成し(記事でも説明)、ファイルをデータベース・サーバーからアクセスできるディレクトリに移動します。これは、データベース・マシン自体のローカル・ディレクトリまたは他の場所のNFS共有の場合があります。次に、createrepoなどのツールを使用して、ディレクトリをyumリポジトリとして設定します。これにより、次のように、`--alternate-repo`に渡されるbaseurlにFILE:///プロトコルを使用できます。 `# ./bds-database-install.sh --alternate-repo="file:///path/to/local/repo" <other parameters>` --alternate-repoパラメータは、CDH 6.3.3以降では必須、6.3.3より前のCDH 6.xではオプション、CDH 5およびHDPシステムでは使用できません。
`--cdb`	CDBデータベースのすべてのPDBにデータベース・オブジェクトを作成します。 `--cdb={true\|false}`
`--reqkey`	このパラメータは、リクエスト・キー・ファイルの名前と場所をインストーラに伝えます。データベース認証は、構成でデフォルトで有効になっています。この機能を有効にしない場合を除き、構成を完了するステップの1つとして、`--reqkey`を使用する必要があります。キー・ファイルがローカル・ディレクトリ内にない場合にキー・ファイル名およびパスを指定するには、次のようにします。 `$ ./bds-database-install.sh --reqkey=/opt/tmp/some_name.reqkey --install` ファイルはローカルであるもののファイル名がデータベース名とは異なる場合に、キー・ファイル名を指定するには、次のようにします。 `$ ./bds-database-install.sh --reqkey=some_name.reqkey --install` リクエスト・キー・ファイル名をパスなしで指定した場合、キー・ファイルはインストール・ディレクトリにあるものと見なされます。ファイル名がデータベース名と同じである場合、インストーラはキーを探します。たとえば、この場合、リクエスト・キー・ファイルはインストール・ディレクトリにあり、名前はデータベース名と同じです。 `$ ./bds-database-install.sh --install` このファイルは、最初のHadoopクラスタをデータベースに接続するためにデータベース側で1回のみ使用されます。同じデータベースに接続する後続のクラスタ・インストールでは、この構成されたキーが使用されます。`.reqkey`ファイルを再送信する必要はありません。
`--uninstall`	このクラスタへのOracle Big Data SQL接続をアンインストールします。`--alternate-principal`パラメータを使用してインストールした場合は、アンインストール時にこのパラメータも含めます。 `./bds-database-install --uninstall --alternateprincipal="<primary>/<instance>@<REALM>"` 詳細は、この表の`--alternate-principal`を参照してください。
`--reconfigure`	bd_cellネットワーク・パラメータ、Hadoop構成ファイルおよびBig Data SQLパラメータを再構成します。このクラスタに接続するためのOracle Big Data SQLインストールがすでに存在している必要があります。 Hadoopクラスタ側で変更(DataNodeインベントリの変更など)が行われた場合は、reconfigureを実行します。
`--databaseack-only`	データベース確認応答zipファイルを作成します。(その後、Hadoopクラスタ管理サーバー上の`/opt/oracle/DM/databases/conf`にzipファイルをコピーし、`./jaguar databaseack <configuration file>`を実行する必要があります。)
`--mta-restart`	MTA extprocが再起動します。(Oracle Big Data SQLがすでにデータベース・サーバーにインストールされている必要があります。)
`--mta-setup`	他に変更を加えることなく、MTA extprocを設定します。(Oracle Big Data SQLがすでにデータベース・サーバーにインストールされている必要があります。)
`--mta-destroy`	MTA extprocを破棄し、他に変更は加えません。(Oracle Big Data SQLがすでにデータベース・サーバーにインストールされている必要があります。)
`--aux-run-mode`	Oracle Big Data SQLは一般ユーザー(スーパーユーザー以外)としてデータベース側にインストールしているため、`root`ユーザーまたはGridユーザー、あるいはその両方としてタスクを実行する必要がある場合には、`bds-database-install.sh`が一時停止している間に、インストーラがそれらのアカウントの下で他のスクリプトを実行できるようにシェルを生成する必要があります。 `--aux-run-mode`パラメータでは、これらの補助スクリプトを実行するモードを指定します。 `--aux-run-mode=<mode>` モードのオプションは次のとおりです。 `session` - 生成されたセッションを使用します。 `su` - 代替ユーザーとして実行します。 `sudo` - sudoを使用します。 `ssh` - セキュア・シェルを使用します。
`--root-script`	起動rootスクリプトの実行を有効または無効にします。 `--root-script={true\|false}`
`--no-root-script`	rootスクリプトの作成および実行をスキップします。
`--root-script-name`	rootスクリプトの名前を設定します(デフォルト名はPIDに基づいています)。
`--pdb-list-to-install`	コンテナ・タイプのデータベースの場合、Oracle Big Data SQLは、オープンしているすべてのPDBにデフォルトで設定されます。このパラメータは、指定されたPDBのリストに設定を制限します。
`--restart-db`	データベースの再起動が必要な場合、デフォルトでは、インストール・スクリプトによって、すぐに再起動するか後で再起動するかを選択するようユーザーにプロンプトが表示されます。`--restart-db=yes`を設定すると、ユーザーにプロンプトを表示することなく必要な再起動を続行するようにスクリプトに事前に指示します。`--restart-db=no`を設定するとプロンプトが表示され、インストールは応答を待機します。これは、自動実行に役立ちます。
`--skip-db-patches-check`	パッチ検証をスキップするには、インストーラの実行時にこのパラメータを追加します。 `./bds-database-install.sh --skip-db-patches-check` デフォルトでは、`./bds-database-install.sh`を実行すると、データベース・パッチの要件がチェックされます。パッチの検証に失敗すると、インストーラは警告メッセージを表示したプロンプトを返し、欠落しているパッチがあることを示します。警告後もインストールは続行されます。
`--set-default-cluster`	マルチクラスタ・インストールでデフォルトのクラスタを現在のクラスタに設定するには、インストーラの実行時に次のパラメータを追加します。 `./bds-database-install.sh --set-default-cluster` マルチクラスタ・インストールでは、最初にインストールされたクラスタがデフォルトのクラスタとみなされます。追加のクラスタがインストールされた場合、問合せを受信する実際のクラスタのバージョンに関係なく、デフォルトのクラスタによって提供されるjavaクライアントがすべての問合せで使用されます。場合によっては、新しいjavaクライアントを使用するなど、デフォルトの変更が必要になることがあります。このパラメータを渡すと、現在のクラスタがデフォルトとして設定されます。必要なデータベース・リンクおよびファイル・システム・リンクが適宜再生成され、既存のマルチスレッド・エージェントが再起動されます。
`--force-incompatible`	異なるバージョンのHadoopを許可するには、インストーラの実行時に次のパラメータを設定します。 `./bds-database-install.sh --force-incompatibble` このパラメータを指定しない場合、インストーラは、異なるメジャーまたはマイナーのHadoopバージョンを持つクラスタのインストールを防止します。たとえば、Hadoop 2.6クラスタがインストールされてからHadoop 3.0がインストールされる場合、このスクリプトでは2回目のインストールが許可されません。この動作により、Hadoopバージョンの潜在的な非互換性が回避されます。ただし、このパラメータを使用すると、この動作をオーバーライドできます。force-incompatibleパラメータが使用されていて、異なるHadoopバージョンの2つのクラスタが検出されると、ユーザーには単に警告が表示されます。

以前のリリースからの--root-script-onlyパラメータは廃止されています。

3.3.2 データベース側での代替Kerberosプリンシパルの使用について

Oracle Database所有者を表すKerberosプリンシパルがデフォルトですが、Oracle DatabaseでのOracle Big Data SQL認証に別のプリンシパルを選択することもできます。

次の図は、インストールで代替プリンシパルがどのように処理されるかを示しています。インストールのHadoop側で、BDS-config.jsonファイルに指定されているKerberosプリンシパルとkeytabを使用して、HadoopクラスタでBig Data SQLのKerberos認証を設定します。データベース側で解凍するインストール・バンドルには、同じkeytabが含まれています。データベース側でバンドルを解凍してインストーラを実行する場合、Kerberos認証を設定するための選択肢が3つあります。

a.インストール・バンドルで提供されるプリンシパルとkeytabを無視し、データベース所有者プリンシパルを使用します。

b.インストール・バンドルで提供されるプリンシパルとkeytabを使用します。

c.別のプリンシパルを指定します。

図3-1 bds-database-install.shでの--alternate-principalパラメータの使用

「図3-1 bds-database-install.shでの--alternate-principalパラメータの使用」の説明

上の図のオプションa、b、cの説明です。

オプションa: Kerberos認証にデータベース所有者プリンシパルを使用します。

データベース所有者プリンシパルのkeytabがステージング・ディレクトリ内に存在し、そのプリンシパルを使用する場合は、インストーラの起動時に--alternate-principalパラメータを含めないでください。デフォルトでは、インストーラはデータベース所有者プリンシパルを使用します。

# ./bds-datbase-install.sh --install <other parameters, except --alternate-principal>

オプションb: 認証にインストール・バンドルに含まれているプリンシパルを使用します。

インストール・コマンドに--alternate-principalを含めますが、このパラメータの値は指定しません。これにより、インストールのHadoop側にあるJaguar bds-config.json構成ファイルで指定されたプリンシパルを使用するようにインストーラに指示します。このプリンシパルはデータベース側のインストール・バンドルに含まれており、ステージング・ディレクトリにすでに存在します。これは、インストール実行ファイルが生成したディレクトリです。特定のHadoopクラスタおよびノードに接続するためのインストール・ファイルが含まれています。たとえば、$(orabasehome)/BDSJaguar-4.1.2/cdh510-6-node1.mycluster.mydomain.comなどです。

# ./bds-datbase-install.sh --install --alternate-principal <other parameters>

オプションc: 認証に別のプリンシパルを使用します。

コマンドラインに--alternate-principalを含め、プリンシパルを値として渡します。

この最後のケースでは、bds-database-install.shを実行する前に2つの追加ステップが必要です。データベース側のインストール・バンドルを解凍した実行ファイルを実行したときに、データベース側のインストール・ディレクトリが作成されました。代替keytabファイルをこのディレクトリにコピーします。次に、プリンシパルに接頭辞bds_を付けてファイルの名前を変更します。接頭辞は、このkeytabファイルのプリンシパルを検索するようインストーラに指示します。その後、次のようにコマンドを実行できます。

./bds-database-install.sh --reconfigure --alternate-principal=<primary>/<instance>@<REALM>

ノート:

--alternate-principalパラメータを含むbds-database-install.sh操作は、ルートとして実行する必要があるスクリプトを生成します。このスクリプトを実行し、[Enter]を押して操作を続行し、完了することを求めるプロンプトが表示されます。たとえば:

bds-database-install: root shell script : /home/oracle/db_home2/install/bds-database-install-28651-root-script-scaj42.sh
please run as root:
/home/oracle/db_home2/install/bds-database-install-28651-root-script-<cluster name>.sh
waiting for root script to complete, press <enter> to continue checking.. q<enter> to quit

Kerberosプリンシパルのリリース後の変更

再構成操作を使用して、別のプリンシパルに切り替えることができます。

./bds-database-install --reconfigure --alternate-principal="<other_primary>/<instance>@<REALM>"

重要:

インストーラがデータベース所有者プリンシパルのkeytabをステージング・ディレクトリ(実行ファイルがインストーラ・ファイルを解凍したディレクトリ)で見つけた場合は、データベース所有者プリンシパルが使用され、--alternate-principalパラメータは無視されます。

Big Data SQLのアンインストール時のKerberosプリンシパルおよびkeytabの削除

Big Data SQLのインストール時に代替原則を指定した場合、後でBig Data SQLをアンインストールする際、同じ--alternate-principleパラメータと値を含めて、アンインストール操作によってシステムからプリンシパルとkeytabが削除されるようにします。

./bds-database-install --uninstall --alternate-principal="bds_<primary>/<instance>@<REALM>"

3.4 ユーザーへのOracle Big Data SQLへのアクセス権の付与

3.1以前のOracle Big Data SQLリリースでは、アクセスはPUBLICユーザー・グループに付与されます。現在のリリースでは、Oracle Big Data SQLにアクセスする必要があるユーザーごとに次の処理を実行する必要があります。

BDSQL_USERロールを付与します。
BigDataSQL構成ディレクトリ・オブジェクトの読取り権限を付与します。
偽装を有効にするには、マルチユーザー認可セキュリティ表に読取り権限を付与します。

たとえば、user1にアクセスを付与するには、次のようにします。

SQL> grant BDSQL_USER to user1; 
SQL> grant read on directory ORACLE_BIGDATA_CONFIG to user1;
SQL> grant read on BDSQL_USER_MAP to user1;

3.5 オブジェクト・ストアへのアクセスの有効化

Oracle Big Data SQLを使用してオブジェクト・ストアを問い合せる場合は、インストールのOracle Database側で特定のデータベース・プロパティおよびネットワークACLの値を設定する必要があります。このインストールには、これを行うために使用できる2つのSQLスクリプトが用意されています。

ORACLE_BIGDATAドライバを使用すると、クラウドのオブジェクト・ストア内のデータに対して外部表を作成できます。現在、Oracle Object Store、Microsoft AzureおよびAmazon S3がサポートされています。これらのストアのParquetファイル、Avroファイルおよびテキスト・ファイルを介して外部表を作成できます。最初のステップでは、次のようにオブジェクト・ストアへのアクセスを設定します。

set_parameters_cdb.sqlおよびallow_proxy_pdb.sqlを実行してオブジェクト・ストアへのアクセスを有効化

bds-database-install.shを実行してデータベース側のインストールを実行した後、$(orabasehome)の下のBDSJaguarディレクトリにあるクラスタ・サブディレクトリ内で次の2つのSQLスクリプト・ファイルを探します。
```
set_parameters_cdb.sql
allow_proxy_pdb.sql
```
これらの各ファイルを開いて確認します。構成が正しいことを確認します。

重要:
セキュリティに影響するため、HTTPサーバーの設定およびその他の設定が正しいことを慎重に確認してください。
CBD ROOTで、set_parameters_cdb.sqlを実行します。
オブジェクト・ストアにアクセスする必要がある各PDBで、allow_proxy_pdb.sqlを実行します。

RACデータベースでは、データベースの1つのインスタンスでこれらのスクリプトを実行するだけで済みます。

3.6 Hiveのトランザクション・ノード表の有効化

Hiveでトランザクション・ノード表のサポートを有効にする場合は、Cloudera構成ファイルの<configuration> xmlタグ内にパラメータを手動で追加する必要があります。

$ORACLE_HOME/bigdatasql/clusters/<your cluster name>/config/hive-site.xmlファイルに次のエントリを追加する必要があります。

<property>
  <name>hive.exec.dynamic.partition.mode</name>
  <value>nonstrict</value>
</property>
<property>
  <name>hive.txn.manager</name>
  <value>org.apache.hadoop.hive.ql.lockmgr.DbTxnManager</value>
</property>

3.7 Oracle SQL Access to Kafkaのインストールおよび構成

Apache KafkaクラスタおよびOracle Databaseを使用して作業する場合、Oracle SQL Access to Kafka (OSAK)を使用すると、Oracle SQLを介してKafkaブローカにアクセスできます。その後、Kafkaレコードのデータを問い合せ、KafkaデータをOracle Database表のデータと結合することもできます。

Oracle Big Data SQLインストールのOracle Database側を完了したら、KafkaクラスタへのOSAK接続を構成できます。

インストール要件

Apache Kafkaを実行しているクラスタ。Oracle Big Data Applianceで実行されるKafkaのすべてのバージョンと同様に、Kafkaバージョン2.3.0がサポートされています。
12.2から19cまでのバージョンのOracle Database。

ノート:
Big Data SQLはOracle Database 12.1をサポートしていますが、OSAKはサポートしていません。

Oracle Big Data SQLインストーラによって実行されるステップ

OSAKは、データベース側のインストール・バンドルに含まれています。インストールの一部として、このガイドの前の項で説明したbds-database-install.shインストーラによって次の処理が実行されます。

OSAKキットをBig Data SQLディレクトリ($(orabasehome)/bigdatasql/)にコピーし、解凍して、キットの内容を確認します。
抽出されたOSAKディレクトリにリンクする、symlink $(orabasehome)/bigdatasql/orakafkaを作成します。
OSAKのJAVA_HOMEを$(orabasehome)/bigdatasql/jdkに設定します。

bds-database-install.shの出力でOSAKインストール・ステップを確認できます。この例は、Oracle Database 19cシステムに基づいています。shiphomeパスを除いて、以前のデータベース・リリースと同じです。

 ...
 bds-database-setup: installing orakafka kit
 
 Step1: Check for valid JAVA_HOME
 --------------------------------------------------------------
 Found /u03/app/oracle/19.1.0/dbhome_orcl/shiphome/database/bigdatasql/jdk/bin/java, \
JAVA_HOME path is valid.
 Step1 succeeded.
 
 Step2: JAVA version check
 --------------------------------------------------------------
 java version "1.8.0_171"
 Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
 Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)
 Java version >= 1.8
 Step2 succeeded.
 
 Step3: Creating configure_java.sh script
 --------------------------------------------------------------
 Wrote to /u03/app/oracle/19.1.0/dbhome_orcl/shiphome/database/bigdatasql/orakafka-1.1.0\
/bin/scripts/configure_java.sh
 Step3 succeeded.
 
 Successfully configured JAVA_HOME in /u03/app/oracle/19.1.0/dbhome_orcl/shiphome/database\
/bigdatasql/orakafka-1.1.0/bin/scripts/configure_java.sh
 
 The above information is written to /u03/app/oracle/19.1.0/dbhome_orcl/shiphome/database\
/bigdatasql/orakafka-1.1.0/logs/set_java_home.log.2020.02.20-17.40.23
...

OSAKのインストールおよび構成を完了するために実行する必要があるステップ

インストールおよび構成を実施するには、$(orabasehome)/bigdatasql/orakafka/docにある、Oracle SQL Access to KafkaのREADME_INSTALLファイル内の手順を参照してください。README_INSTALLファイルには、orakafka.shの使用方法が記載されています。このスクリプトは、残りの構成ステップの実行に役立つ場合があります。

$(orabasehome)/bigdatasql/orakafka/clusters/.の下に新しいKafkaクラスタ構成ディレクトリを追加します。
データベース・ユーザーがKafkaクラスタにアクセスできるようにします。
ORA_KAFKA PL/SQLパッケージをユーザー・スキーマにインストールし、必要なデータベース・ディレクトリを作成します。

重要:

保護されたKafkaクラスタへのアクセスを設定する場合、クラスタ・ディレクトリの生成後、このプロパティ・ファイルで適切なプロパティも設定する必要があります。

$(orabasehome)/bigdatasql/orakafka/clusters/<cluster_name>/conf/orakafka.properties

プロパティ・ファイルには、可能なセキュリティ構成のテスト済サブセットが含まれています。Kafkaのセキュリティに関する一般的な情報は、https://kafka.apache.org/documentation/#securityでApache Kafkaのドキュメントを参照してください

Oracle Cloud Infrastructure Streaming Serviceの使用

Oracle Cloud Infrastructure Streaming Serviceを使用するには、クラスタ構成プロパティのファイル内で次のプロパティをコメント解除し設定する必要があります。

<app_data_home>/clusters/<cluster_name>/conf/orakafka.properties
    security.protocol=SASL_SSL

    sasl.mechanism=PLAIN

    #Parameters for JAAS config (Authentication using SASL/PLAIN)
    sasl.plain.username=<tenancyName/<username>/<streamPoolId>
    sasl.plain.password=<user auth_token>

    #Uncomment the following for SASL/PLAIN authentication
    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username=\"${sasl.plain.username}\" password=\"${sasl.plain.password}\";

KafkaとOracle Cloud Infrastructure Streaming Serviceとの互換性の詳細は、Apache Kafkaでのストリーミングの使用を参照してください。

構成が完了したら、次のステップではKafkaクラスタを登録します。クラスタを登録したら、Oracle SQL Access to Kafkaの使用を開始して、Kafkaトピックに対するビューを作成し、データを問い合せることができます。