3 Oracle Database側のOracle Big Data SQLのインストールまたはアップグレード
Oracle Big Data SQLは、Hadoopクラスタ管理サーバーとOracle Databaseサーバーの両方にインストールする必要があります。この項では、単一ノード・システム、RACシステムなどOracle DatabaseシステムでのOracle Big Data SQL のインストールについて説明します。
3.1 データベース側のインストールを開始する前に
インストールを開始する前に、この項のポイントを確認します。
Oracle Big Data SQLの現在のバージョンがOracle Databaseシステムにすでにインストールされており、既存の構成に変更を加えている場合は、インストール・プロセス全体を繰り返す必要はありません。「既存のOracle Big Data SQLインストールの再構成」を参照してください。
重要:
-
マルチノード・データベース(Oracle RACシステムなど)の場合、このインストールをデータベースの各コンピュート・ノードで繰り返す必要があります。これを実行していない場合、Oracle Big Data SQLサービスを開始すると、RPC接続エラーが表示されます。
インストーラの実行時に、オプションの
--ip-cellコマンドライン・パラメータを含めて、そのノードの正しいネットワーク・インタフェース・アドレスを渡すことで、同じインストール・バンドルを各データベース・ノードで再利用できます。このパラメータが使用されていない場合、インストーラがそれを検索して選択します。 -
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つの構成ファイルのみを指している必要があります。構成ファイルが存在している必要があり、変数自体はシステム起動時にデータベース所有者アカウントに対して設定されている必要があります。 -
Oracle Grid Infrastructureの下で実行しているデータベースに、同じタイプの複数のネットワーク・インタフェース(2つ以上のEthernet、2つ以上のInfiniBandまたは2つ以上のEthernet-over-InfiniBandインタフェース)が存在していると、常に、インストールによってアルファベット順で最初になる名前のインタフェースが選択されます。
関連項目:
詳細は、「Grid Infrastructureのシステムに同じタイプの複数のネットワーク・インタフェースがある際の特別な考慮事項」を参照してください。
3.1.1 bds-validate-grid-patches.shによる必要なグリッド・パッチの確認
スクリプトbds-validate-grid-patches.shは、Oracle Big Data SQLに必要なOracle Grid Infrastructureのパッチがインストールされているかどうかを確認します。
注意:
このスクリプトを実行する場合は、Oracle Big Data SQLをデータベース・ノードにインストールする前に実行してください。- ORACLE_HOMEをGridホームに設定する必要があります。
$ echo $ORACLE_HOME /u01/app/18c/gridhome - HadoopクラスタのOracle Big Data SQLインストール・ディレクトリから、データベース・ノードで
bds-validate-grid-patches.shを実行するのと同じディレクトリに、bdsql_db_patchesファイルをコピーします。このスクリプトはbdsql_db_patchesを使用して、現在インストールされているOracle DatabaseリリースのOrace Big Data SQLのこのリリースに必要なグリッド・パッチが存在するかどうかを判断します。bdsql_db_patchesは、インストールの対象となる側を実行したHadoopクラスタ・ノードの次の場所にあります。
デフォルトでは、Hadoopクラスタのインストール・ディレクトリは<Oracle Big Data SQL installation directory>/BDSJaguar/bdsrepo/db/bdsql_db_patches>/opt/oracleです。 - このスクリプトは、Oracle Grid Infrastructureインストール所有者(Gridユーザー)として実行する必要があります。
関連項目:
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管理の更新では、それぞれのノードで適切なタイプの最初のネットワーク・インタフェースが自動的に選択されます。その際、アルファベット順で最初になる名前の付いたインタフェースが選択されます。その他の環境(Exadata Database Machineシステムを除く)では、インストーラに
--ip-cellコマンドライン・パラメータを使用することで、特定のネットワーク・インタフェースを選択できます。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 データベース側のインストール・ディレクトリについて
インストールのデータベース側を開始するには、データベース側のインストール・バンドルを解凍し、含まれている実行ファイルを実行します。実行ファイルによって、$ORACLE_HOME/BDSJaguar-4.0.0の下にインストール・ディレクトリが作成されます。次に例を示します。
$ORACLE_HOME/BDSJaguar-4.0.0/cdh510-6-node1.mycluster.mydomain.comOracle 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など)として、この項の手順を実行します。バンドルは一時ディレクトリにステージングしますが、バンドルを解凍し、含まれている実行ファイルを実行した後、インストール・パッケージは$ORACLE_HOMEの下のサブディレクトリにインストールされます。例: $ORACLE_HOME/BDSJaguar-4.0.0/cdh510-6-node1.mycluster.mydomain.com。
開始する前に、ORACLE_HOMEおよびORACLE_SIDが正しく設定されていることを確認してください。
インストールの実行回数
各データベースのインスタンスごとにインストールを実行する必要があります。たとえば、単一の2ノードRACに、非CBDデータベースおよびCBDデータベース(次の例ではそれぞれDBAおよびDBB)がある場合は、次のように両方のノードにOracle Big Data SQLをインストールします。
- ノード1の場合
./bds-database-install.sh --ip-cell=<address> --db-resource=DBA1 --cdb=false ./bds-database-install.sh --ip-cell=<address> --db-resource=DBB1 --cdb=true - ノード2の場合
./bds-database-install.sh --ip-cell=<address> --db-resource=DBA2 --cdb=false ./bds-database-install.sh --ip-cell=<address> --db-resource=DBB2 --cdb=true
コンポーネントのコピーおよびインストールの準備
ノード1からノードnまで順番に、各データベース・ノードにソフトウェアをコピーしてインストールします。
-
まだそうしていない場合は、希望の方法を使用して、Hadoopクラスタ管理サーバーからOracle Databaseサーバーにデータベース側のインストール・バンドルをコピーします。バンドルが複数ある場合は、Oracle Databaseに接続するクラスタに適切なバンドルを選択してください。一時的なステージング領域として使用する任意の場所にそれをコピーします。コピー操作を実行する場合、Hadoopクラスタ管理サーバーに
rootとしてログオンし、Oracle Big Data SQLインストール・ディレクトリ内のバンドルの場所に移動し、バンドルをデータベース・サーバーにプッシュする方法が簡単です。データベース側でのリモート・ログオンにデータベース所有者アカウント(通常はoracle)を使用します。この例では、バンドルが/opt/tmpにコピーされます。このバンドルはセキュアなディレクトリにコピーできますが、まず、ディレクトリが存在していることを確認してください。# cd <Big Data SQL Install Directory>/BDSjaguar-4.0.0/db-bundles # scp bds-4.0.0-db-<cluster>-<yymmdd.hhmi>.zip oracle@<database_node>:/opt/tmp -
データベース・リクエスト・キーを生成した場合は、そのキーもOracle Databaseサーバーにコピーします。
# cd <Big Data SQL Install Directory>/BDSjaguar-4.0.0/dbkeys # scp <database name or other name>.reqkey oracle@<database_node>:/opt/tmp -
データベース・サーバー・ホストに
oracle(またはデータベース所有者であるユーザー)としてログオンし、cdを使用して1つ以上のファイルをコピーしたディレクトリに移動します。 -
バンドルを解凍します。これには、単一の圧縮された実行ファイルが含まれています。
-
前提条件の環境変数(
$ORACLE_HOMEおよび$ORACLE_SID)が設定されていることを確認します。 -
バンドルを
$ORACLE_HOMEに解凍するためにファイルを実行します。次に例を示します。$ ./bds-4.0.0-db-cdh510-170309.1918.runOracle Databaseインスタンスと複数のHadoopクラスタの間に独立したOracle Big Data SQL接続を設定できるため、
runコマンドは$ORACLE_HOME/BDSJaguar-4.0.0の下のクラスタ固有のディレクトリにバンドルを解凍します。次に例を示します。$ ls $ORACLE_HOME/BDSJaguar-4.0.0 cdh510-6-node1.mycluster.mydomain.com test1-3-node1.myothercluster.mydomain.comBDSJaguar-4.0.0ディレクトリがまだ存在しない場合は、そのディレクトリも作成されます。 -
データベース・リクエスト・キーを生成した場合は、新しく作成したインストール・ディレクトリにそれをコピーします。次に例を示します。
$ cp /opt/tmp/mydb.reqkey $ORACLE_HOME/BDSJaguar-4.0.0/cdh510-6-node1.mycluster.mydomain.comヒント:
また、キー・ファイルを一時的な場所に置いておき、そのキー・ファイルが存在する場所をスクリプトに指示するためにインストール・コマンドで
--reqkeyパラメータを使用することもできます。このパラメータでは、デフォルト以外のリクエスト・キーのファイル名またはパス、あるいはその両方を指定できます。ただし、インストール・スクリプトがインストール・ディレクトリ内のキーを検出するのは、キー・ファイル名がデータベース名と同じ場合のみです。それ以外の場合、キーがローカルであっても、異なる名前をキーに付けた場合には、インストール・スクリプトが識別できるように引き続き
--reqkeyを使用する必要があります。
クラスタのインストール・ディレクトリを用意したら、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ノードに
oracleとしてログオンし、ディレクトリを$ORACLE_HOME/BDSJaguar-4.0.0の下のクラスタ固有のインストール・ディレクトリに変更します。次に例を示します。$ cd $ORACLE_HOME/BDSJaguar-4.0.0/cdh510-6-node1.my.domain.com -
データベース側のOracle Big Data SQLインストーラである
bds-database-install.shを実行します。オプションのパラメータをいくつか含める必要がある場合があります。$ ./bds-database-install.sh [options]複数のネットワーク・インタフェースがある場合は、--ip-cellパラメータを含めて、ネットワーク・インタフェースを指定する必要があります。次に例を示します。$ ./bds-database-install.sh --ip-cell=102.0.0.1/16 [other options] -
データベースを再起動します(オプション)。
関連項目:
bds-database-install.shインストーラ・コマンドは、通常はオプションですが構成によっては必須になるパラメータをサポートしています。「bds-database-install.shのコマンドライン・パラメータ・リファレンス」を参照してください
データベース認証またはHadoop Secure Impersonationを有効にした場合の追加のステップ
-
このインストール・バンドルの作成に使用される構成ファイルで
database_auth_enabledまたはimpersonation_enabledがtrueに設定されている場合、データベース側のインストーラによって生成されたZIPファイルをHadoopクラスタ管理サーバーにコピーし、Jaguarのデータベース確認応答操作を実行します。これで、HadoopクラスタとOracle Databaseの間のログイン認証の設定が完了します。インストール・ディレクトリでGUIDキー・ペアが含まれているzipファイルを探します。このファイルには、次の形式に従った名前が付けられています。
次に例を示します。<name of the Hadoop cluster>-<number nodes in the cluster>-<FQDN of the node where the cluster management server is running>-<FQDN of this database node>.zip$ ls $ORACLE_HOME/BDSJaguar-4.0.0/cdh510-6-node1.my.domain.com/*.zip $ mycluster1-18-mycluster1node03.mydomain.com-myoradb1.mydomain.com.zip-
ZIPファイルをHadoopクラスタ管理サーバーの
/opt/oracle/DM/databases/confにコピーします。 -
クラスタ管理サーバーに
rootとしてログオンし、Oracle Big Data SQLがインストールされたディレクトリの下の/BDSjaguar-4.0.0に移動し、databaseack(Jaguarのデータベース確認応答ルーチン)を実行します。インストール・バンドルの生成に使用された構成ファイル(bds-config.jsonなど)を渡します。# cd <Big Data SQL Install Directory>/BDSjaguar-4.0.0 # ./jaguar databaseack bds-config.json
-
3.3.1 bds-database-install.shのコマンドライン・パラメータ・リファレンス
bds-database-install.shスクリプトには、多数のコマンドライン・パラメータを使用できます。各パラメータはオプションですが、このスクリプトには少なくとも1つのパラメータが必要です。
表3-1 bds-database-install.shのパラメータ
| パラメータ | 機能 |
|---|---|
--install |
このクラスタへのOracle Big Data SQL接続をインストールします。 注意: 操作の途中で、このスクリプトは一時停止し、2番目のスクリプトをルートとして実行するように要求します。 Rootとして、2番目の端末のセッションを開き、そこでスクリプトを実行します。そのスクリプトが完了したら、元の端末に戻り、[Enter]を押して Oracle Big Data SQLは一般ユーザー(スーパーユーザー以外)としてデータベース側にインストールしているため、rootユーザーまたはGridユーザー、あるいはその両方としてタスクを実行する必要がある場合には、 以前の一部のリリースでは、その他のパラメータが指定されていない場合、 |
--version |
bds-database-install.shスクリプトのバージョンを示します。
|
--info |
クラスタ名、クラスタ管理サーバー・ホスト、Webサーバーなど、クラスタに関する情報を表示します。 |
--grid-home |
Oracle Gridホーム・ディレクトリを指定します。 |
--crs |
Oracle Big Data SQL MTA extprocを設定するには、 インストーラは、Gridが実行されているかどうかを常に検証します。Gridが実行されていない場合、インストーラはGridがインストールされておらず、データベースが単一インスタンスであると見なします。次に、
|
--cdb |
CDBデータベースのすべてのPDBにデータベース・オブジェクトを作成します。 |
--ip-cell |
複数のネットワーク・インタフェースがある単一インスタンス・データベース環境でdiskmonプロセスによって使用されるIPアドレス。 Oracle Exadata Database Machineでは無視されます。 |
--db-resource |
非推奨。 Oracle Big Data SQLスクリプトは、 |
--db-name |
非推奨。 Oracle Big Data SQLスクリプトは、 |
--reqkey |
このパラメータは、リクエスト・キー・ファイルの名前と場所をインストーラに伝えます。データベース認証は、構成でデフォルトで有効になっています。この機能を有効にしない場合を除き、構成を完了するステップの1つとして、
リクエスト・キー・ファイル名をパスなしで指定した場合、キー・ファイルはインストール・ディレクトリにあるものと見なされます。ファイル名がデータベース名と同じである場合、インストーラはキーを探します。 たとえば、この場合、リクエスト・キー・ファイルはインストール・ディレクトリにあり、名前はデータベース名と同じです。 このファイルは、最初のHadoopクラスタをデータベースに接続するためにデータベース側で1回のみ使用されます。同じデータベースに接続する後続のクラスタ・インストールでは、この構成されたキーが使用されます。 |
--uninstall |
このクラスタへのOracle Big Data SQL接続をアンインストールします。 |
--reconfigure |
bd_cellネットワーク・パラメータ、Hadoop構成ファイルおよびBig Data SQLパラメータを再構成します。 このクラスタに接続するためのOracle Big Data SQLインストールがすでに存在している必要があります。 Hadoopクラスタ側で変更(DataNodeインベントリの変更など)が行われた場合は、reconfigureを実行します。 |
--databaseack-only |
データベース確認応答zipファイルを作成します。(その後、Hadoopクラスタ管理サーバー上の |
--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-script |
起動rootスクリプトの実行を有効または無効にします。
|
--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 |
パッチ検証をスキップするには、インストーラの実行時にこのパラメータを追加します。
デフォルトでは、 |
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;関連項目:
Hadoopデータへのアクセスをユーザーに間接的に提供するには、Oracle Big Data SQLユーザーズ・ガイドのDBMS_BDSQL PL/SQLパッケージを使用します。このパッケージが実装しているマルチユーザー認可機能は、Hadoop Secure Impersonationを使用して、oracleアカウントを有効にし、他の指定のユーザーのかわりにタスクを実行できるようにします。
3.5 オブジェクト・ストアへのアクセスの有効化
Oracle Big Data SQLを使用してオブジェクト・ストアを問い合せる場合は、インストールのOracle Database側で特定のデータベース・プロパティおよびネットワークACLの値を設定する必要があります。このインストールには、これを行うために使用できる2つのSQLスクリプトが用意されています。
Oracle Big Data SQL 4.0以降では、ORACLE_BIGDATAドライバを使用して、クラウドのオブジェクト・ストア内のデータに対して外部表を作成できます。現在、Oracle Object StoreおよびAmazon S3がサポートされています。これらのストアのParquetファイル、Avroファイルおよびテキスト・ファイルを介して外部表を作成できます。最初のステップでは、次のようにオブジェクト・ストアへのアクセスを設定します。
set_parameters_cdb.sqlおよびallow_proxy_pdb.sqlを実行してオブジェクト・ストアへのアクセスを有効化
bds-database-install.shを実行してデータベース側のインストールを実行した後、$ORACLE_HOMEの下の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 WebLogic Serverの維持
WebLogic Serverは、Oracle Big Data SQLのコンポーネントとして含まれています。WebLogic Serverを、Oracleが提供する公式のセキュリティ・パッチで最新の状態に保つために、ここで説明したパッチ適用ツールをダウンロードして実行します。
WebLogic Serverは、Big Data SQLがインストールされているすべてのDataNodesにデプロイされます。これらのノードで実行されるbd_cells (Big Data SQL処理セル)に埋め込まれています。Big Data SQL 4.0リリースの時点で、WebLogic Server 10.3.6コンポーネントは2019年4月のPSUで最新の状態です。WebLogic Serverを維持するには、Big Data SQLのインストール後にパッチ適用ツールを実行し、その後、新しいPSUが使用可能になったときに再度実行する必要があります。
パッチ適用ツールは、My Oracle Supportでパッチ31188867として使用できます。「Patches and Updates」タブをクリックし、「search」フィールドに"31188867"と入力します。インストール手順が、パッチで提供されるreadmeファイルに記載されています。ただし、My Oracle Supportのドキュメント2662568.1も確認してください。readmeファイルにない情報が提供されています。