yumで標準以外のPostgreSQL環境を構築する
PostgreSQLはバージョンアップが早く、CentOSの標準リポジトリのみに依存していると、本家でEOLになっていって悲しいので、yumで新しいバージョンのPostgreSQL環境を構築するためのメモ。
ちなみに、CentOS 6ではv8.4.20、CentOS 7ではv9.2.24、CentOS 8ではv10.6が標準で入ります。
PostgreSQL公式のyumリポジトリ
PostgreSQLに関しては、本家がyumリポジトリを提供してくれています。
- PostgreSQL RPM Repository (with Yum)
こちらを参照して、まずはリポジトリを追加します。
# yum -y install ＜上記のURL＞
PostgreSQLパッケージの確認
まずは利用可能なバージョンを確認してみます。
- CentOS 6
# yum list 'postgresql*' | grep '^postgresql[0-9]*[.]' postgresql.x86_64 8.4.20-8.el6_9 @updates postgresql.i686 8.4.20-8.el6_9 base postgresql10.x86_64 10.13-1PGDG.rhel6 pgdg10 postgresql11.x86_64 11.8-1PGDG.rhel6 pgdg11 postgresql12.x86_64 12.3-1PGDG.rhel6 pgdg12 postgresql95.x86_64 9.5.22-1PGDG.rhel6 pgdg95 postgresql96.x86_64 9.6.18-1PGDG.rhel6 pgdg96
- CentOS 7
# yum list 'postgresql*' | grep '^postgresql[0-9]*[.]' postgresql.x86_64 9.2.24-1.el7_5 @updates postgresql.i686 9.2.24-4.el7_8 updates postgresql.x86_64 9.2.24-4.el7_8 updates postgresql10.x86_64 10.13-1PGDG.rhel7 pgdg10 postgresql11.x86_64 11.8-1PGDG.rhel7 pgdg11 postgresql12.x86_64 12.3-5PGDG.rhel7 pgdg12 postgresql95.x86_64 9.5.22-1PGDG.rhel7 pgdg95 postgresql96.x86_64 9.6.18-1PGDG.rhel7 pgdg96
- CentOS 8
# yum list 'postgresql*' | grep '^postgresql[0-9]*[.]' postgresql.x86_64 10.6-1.module_el8.0.0+15+f57f353b @AppStream
あれ、CentOS 8だけ、標準版以外が見つかりません。もう一度。
# less /etc/yum.repos.d/pgdg-redhat-all.repo # yum list --disablerepo='AppStream' --enablerepo='pgdg*' 'postgresql*' | grep '^postgresql[0-9]*[.]' postgresql.x86_64 10.6-1.module_el8.0.0+15+f57f353b @AppStream postgresql10.src 10.13-1PGDG.rhel8 pgdg10-source postgresql10.x86_64 10.13-1PGDG.rhel8 pgdg10 postgresql11.src 11.8-2PGDG.rhel8 pgdg11-source postgresql11.src 11.8-2PGDG.rhel8 pgdg11-source-updates-testing postgresql11.x86_64 11.8-2PGDG.rhel8 pgdg11 postgresql11.x86_64 11.8-2PGDG.rhel8 pgdg11-updates-testing postgresql12.src 12.3-5PGDG.rhel8 pgdg12-source postgresql12.src 12.3-5PGDG.rhel8 pgdg12-source-updates-testing postgresql12.x86_64 12.3-5PGDG.rhel8 pgdg12 postgresql12.x86_64 12.3-5PGDG.rhel8 pgdg12-updates-testing postgresql13.x86_64 13-beta1_2PGDG.rhel8 pgdg13-updates-testing postgresql94.src 9.4.26-1PGDG.rhel8 pgdg94-source postgresql94.x86_64 9.4.26-1PGDG.rhel8 pgdg94 postgresql95.src 9.5.22-1PGDG.rhel8 pgdg95-source postgresql95.x86_64 9.5.22-1PGDG.rhel8 pgdg95 postgresql96.src 9.6.18-1PGDG.rhel8 pgdg96-source postgresql96.x86_64 9.6.18-1PGDG.rhel8 pgdg96
あれ、「enabled=1」になっているんですけどね。
ちなみに、CentOS 6/7/8ともに、pgdg94は「enabled=0」になっています。念のため。
PostgreSQL環境のインストール
それでは、気を取り直して、PostgreSQL v12をインストールしてみます。
- CentOS 6/7
# yum -y install postgresql12-server
- CentOS 8
# yum -y install --disablerepo='AppStream' --enablerepo='pgdg12' postgresql12-server
ちなみに、CentOS 7でのインストール中に以下のようなエラーが出ますが、今回は無視します。標準版が入っているせいなので。
シンボリックリンク /usr/bin/psql -> /etc/alternatives/pgsql-psql の作成に失敗しました。 /usr/bin/psql がすでに存在しており、シンボリックリンクファイル ではありません。 ： ：
- CentOS 6/7/8
# /usr/pgsql-12/bin/psql --version psql (PostgreSQL) 12.3
とりあえずOKそうです。
環境設定
- CentOS 6
# service postgresql-12 initdb
データベースを初期化中: [ OK ]
# vim /var/lib/pgsql/12/data/postgresql.conf
# vim /var/lib/pgsql/12/data/pg_hba.conf
# service postgresql-12 start
postgresql-12 サービスを開始中: [ OK ]
# /usr/pgsql-12/bin/psql -U postgres
psql (12.3)
"help"でヘルプを表示します。
postgres=# \l
データベース一覧
名前 | 所有者 | エンコーディング | 照合順序 | Ctype(変換演算子) | アクセス権限
-----------+----------+------------------+-------------+-------------------+-----------------------
postgres | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 |
template0 | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
(3 行)
postgres=# \q
- CentOS 7/8
# /usr/pgsql-12/bin/postgresql-12-setup initdb
Initializing database ... OK
# vim /var/lib/pgsql/12/data/postgresql.conf
# vim /var/lib/pgsql/12/data/pg_hba.conf
# systemctl start postgresql-12
# /usr/pgsql-12/bin/psql -U postgres
psql (12.3)
"help"でヘルプを表示します。
postgres=# \l
データベース一覧
名前 | 所有者 | エンコーディング | 照合順序 | Ctype(変換演算子) | アクセス権限
-----------+----------+------------------+------------+-------------------+-----------------------
postgres | postgres | UTF8 | ja_JP.utf8 | ja_JP.utf8 |
template0 | postgres | UTF8 | ja_JP.utf8 | ja_JP.utf8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | ja_JP.utf8 | ja_JP.utf8 | =c/postgres +
| | | | | postgres=CTc/postgres
(3 行)
postgres=# \q
参考
- CentOS 6 に PostgreSQL 9.x を yum インストールする手順
yumでCentOSに標準以外のPHP実行環境を構築する
CentOSの標準リポジトリのみに依存していると、PHPのバージョンがどんどんEOLになっていって悲しいので、yumで任意のバージョンをインストールして使用するための手順のメモ。
ちなみに、標準リポジトリを使用する場合はCentOS 6ではPHP 5.3.3、CentOS 7ではPHP 5.4.16ですが、CentOS 8では一気にPHP 7.2.11まで飛びます。
Remiプロジェクト
『RedHat系LinuxにPHPの最新版を提供することをミッションとする』だそうです。
- Remi's RPM repository
ちなみに、多くの記事で「rpms.famillecollet.com」からインストールする例を見ましたが、2020年6月15日現在、ここではミラーされていないようで、本家へのリダイレクトになっています。
Remiリポジトリの追加
上記のサイトでミラーサイトを確認し、適当なところから選び出します。日本では「http://ftp.riken.jp/Linux/remi/」が提供されているので、今回はそこを利用します。
まず、EPELが必要となるので、その追加から。
CentOS 6 (今さらですが)
- 以下のページを見る
- 「epel-release-xxx.noarch」のリンク先URLをコピーする
- 以下のコマンドを叩く(URLは上記でコピーしたものに置き換え)
# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
- CentOS 7/8
こちらは標準リポジトリで提供されているので。
# yum -y install epel-release
続いてRemiリポジトリの追加。
- CentOS 6
# yum -y install http://ftp.riken.jp/Linux/remi/enterprise/remi-release-6.rpm
- CentOS 7
# yum -y install http://ftp.riken.jp/Linux/remi/enterprise/remi-release-7.rpm
- CentOS 8
# yum -y install http://ftp.riken.jp/Linux/remi/enterprise/remi-release-8.rpm
これで完了です。
利用可能なPHPバージョンの確認
以下を実行してみます。
$ yum list 'php*' | grep '^php[0-9]*[.]'
- CentOS 6
php.x86_64 5.3.3-50.el6_10 @updates php54.x86_64 2.1-4.el6.remi remi-safe php55.x86_64 2.1-5.el6.remi remi-safe php56.x86_64 3.0-1.el6.remi remi-safe php70.x86_64 2.0-1.el6.remi remi-safe php71.x86_64 2.0-1.el6.remi remi-safe php72.x86_64 2.0-1.el6.remi remi-safe php73.x86_64 2.0-1.el6.remi remi-safe
- CentOS 7
php.x86_64 5.4.16-46.1.el7_7 @updates php.x86_64 5.4.16-48.el7 base php54.x86_64 2.1-4.el7.remi remi-safe php55.x86_64 2.1-5.el7.remi remi-safe php56.x86_64 3.0-1.el7.remi remi-safe php70.x86_64 2.0-1.el7.remi remi-safe php71.x86_64 2.0-1.el7.remi remi-safe php72.x86_64 2.0-1.el7.remi remi-safe php73.x86_64 2.0-1.el7.remi remi-safe php74.x86_64 1.0-3.el7.remi remi-safe php80.x86_64 1.0-3.el7.remi remi-safe
- CentOS 8
php.x86_64 7.2.11-1.module_el8.0.0+56+d1ca79aa @AppStream php.x86_64 7.2.11-2.module_el8.1.0+209+03b9a8ff AppStream php56.x86_64 3.0-1.el8.remi remi-safe php70.x86_64 2.0-1.el8.remi remi-safe php71.x86_64 2.0-1.el8.remi remi-safe php72.x86_64 2.0-1.el8.remi remi-safe php73.x86_64 2.0-1.el8.remi remi-safe php74.x86_64 1.0-3.el8.remi remi-safe php80.x86_64 1.0-3.el8.remi remi-safe
とまぁ、こんな感じです。
PHP 5.6の導入
試しにということで、各環境にPHP 5.6を入れて、Apache httpdと連携させてみます。
# yum -y install php56 php56-php httpd
さて、CLIでバージョン番号を確かめてみます。
$ php -v
どのような出力が得られたでしょうか？
PHP 5.3.3 (cli) (built: Nov 1 2019 12:28:08) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
？
PHP 5.4.16 (cli) (built: Nov 1 2019 16:04:20) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
？
PHP 7.2.11 (cli) (built: Oct 9 2018 15:09:36) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
？
bash: php: コマンドが見つかりません
？
これ、実は実体が「/usr/bin/php56」なので、標準版のPHP環境が入っているとそのバージョン、入っていないとコマンドが見つからないとなります。
Apache httpdと連携する場合も注意が必要で、設定ファイルを確認すると以下のような状態になっています。
- CentOS 6/7/8
# ls -1 /etc/httpd/conf.d/php* /etc/httpd/conf.d/php.conf /etc/httpd/conf.d/php56-php.conf
- CentOS 7
# ls -1 /etc/httpd/conf.modules.d/*php* /etc/httpd/conf.modules.d/10-php.conf /etc/httpd/conf.modules.d/10-php56-php.conf
- CentOS 8
# ls -1 /etc/httpd/conf.modules.d/*php* /etc/httpd/conf.modules.d/10-php56-php.conf /etc/httpd/conf.modules.d/15-php.conf
CentOS 8では「10-php56-php.conf」のLoadModuleが先に実行されるのでPHP 5.6が走りますが、CentOS 6/7では標準版のLoadModuleが先に実行されるので、注意しておかないと、どれが実行されているのか分からなくなります。
最後に、php.ini の位置も確認しておきましょう。
# /usr/bin/php56 -i 2>/dev/null | grep 'php.ini$' Loaded Configuration File => /opt/remi/php56/root/etc/php.ini
参考
SSLサーバー証明書を無視するための対応方法
よりにもよって繁忙期に、以下のROOT証明書期限切れで接続不可になるというトラブルに見舞われ、なんじゃゴルァ！と叫びながら対応した記憶の記録。
- Knowledge: Sectigo AddTrust External CA Root Expiring May 30, 2020
状況としては、WinSCPだと（証明書のCNがホスト名と違うってエラーが出るけど（ボソッ））接続できるが、Javaプログラムやlftpコマンドだと証明書の期限切れだと怒られる事案。
ひとまず、以下の情報を頼りに証明書チェインの情報を取ってみた。
- lftpのSSL通信エラー解消方法 – 猫のプロトコル * https://protocol.nekono.tokyo/2016/07/06/lftp%E3%81%AEssl%E9%80%9A%E4%BF%A1%E3%82%A8%E3%83%A9%E3%83%BC%E8%A7%A3%E6%B6%88%E6%96%B9%E6%B3%95/
$ openssl s_client -connect xxxxx.com:21 -starttls ftp -showcerts < /dev/null > hoge.txt
hoge.txt の中にある証明書4つを分割して別ファイルに保存
$ openssl x509 -text -in 3.txt -noout
：
Validity
Not Before: May 30 10:48:38 2000 GMT
Not After : May 30 10:48:38 2020 GMT
Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
：
$ openssl x509 -text -in 4.txt -noout
：
Validity
Not Before: May 30 10:48:38 2000 GMT
Not After : May 30 10:48:38 2020 GMT
Subject: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
：
はい、というわけで。
使い古されているけどすぐに忘れてしまうコード断片のメモ。
FTPSClientの場合
- FTPSClient で SSL証明書を無視する設定 - 6VOX
import java.io.IOException; import java.security.cert.CertificateException; import java.security.cert.X509Certificate; import javax.net.ssl.TrustManager; import javax.net.ssl.X509TrustManager; import org.apache.commons.net.ftp.FTPSClient; public class Main { public static void main(String[] args) { FTPSClient client = new FTPSClient("TLS", false); TrustManager tm = new X509TrustManager() { public X509Certificate[] getAcceptedIssuers() { return null; } @Override public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { } @Override public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { } }; client.setTrustManager(tm); try { client.connect("example.com", 21); } catch (IOException e) { e.printStackTrace(); } } }
HttpsURLConnectionの場合
ついでに。
- Java HttpsURLConnectionで、証明書エラーを無視して接続する - Symfoware
import java.io.IOException; import java.net.MalformedURLException; import java.net.URL; import java.security.KeyManagementException; import java.security.NoSuchAlgorithmException; import java.security.cert.CertificateException; import java.security.cert.X509Certificate; import javax.net.ssl.HttpsURLConnection; import javax.net.ssl.SSLContext; import javax.net.ssl.TrustManager; import javax.net.ssl.X509TrustManager; public class Mail { public static void main(String[] args) { TrustManager[] tm = { new X509TrustManager() { public X509Certificate[] getAcceptedIssuers() { return null; } @Override public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { } @Override public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { } } }; try { SSLContext sslcontext = SSLContext.getInstance("SSL"); sslcontext.init(null, tm, null); URL connectUrl = new URL("https://exaple.com/"); HttpsURLConnection urlconn = (HttpsURLConnection) connectUrl.openConnection(); urlconn.setSSLSocketFactory(sslcontext.getSocketFactory()); urlconn.connect(); } catch (NoSuchAlgorithmException e) { e.printStackTrace(); } catch (KeyManagementException e) { e.printStackTrace(); } catch (MalformedURLException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } } }
lftpコマンドの場合
さらについで。 冒頭の方のサイトに書いてあるけど。
$ lftp -u uuuu,pppp -e 'set ssl:verify-certificate no' example.com
証明書ファイルなどを確認するコマンド諸々
歳を取ると、いろんな形式の証明書ファイルや、サーバーにアクセスしての証明書の検証方法など、コマンドをすぐに忘れて、そのたびにググるということを繰り返しているので、とりあえず思いついたものを整理しておくテスト。
用語などは適当かもですが、その辺はご容赦を・・・
PEM形式の証明書
以下のような形式のファイルです。
-----BEGIN CERTIFICATE----- ～～～ -----END CERTIFICATE-----
Let's Encryptのcertbotで生成した証明書の表示コマンド例。
openssl x509 -text -noout < /etc/letsencrypt/live/xxx/cert.pem openssl x509 -text -noout < /etc/letsencrypt/live/xxx/chain.pem
Javaのキーストアファイル
例えば「/etc/pki/java/cacerts」とか「/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232.b09-0.el7_7.x86_64/jre/lib/security/cacerts」に置いてあるファイルです。
keytool -storepass changeit -list -keystore /etc/pki/java/cacerts
PKCS12形式の証明書
Tomcatなんかで使いますね。そもそもTomcatをフロントエンド(略)
keytool -storepass changeit -list -v -storetype PKCS12 -keystore hoge.p12
openssl pkcs12 -in ssl/ks-lets202003.p12 -nodes -passin pass:changeit | openssl x509 -text
サーバー証明書チェインの確認
実際にサーバーにアクセスして、証明書チェインに問題がないかを確認する方法です。
cat /dev/null | openssl s_client -connect server_host_name:443 -showcerts cat /dev/null | openssl s_client -connect server_host_name:21 -starttls ftp -showcerts
Eclipse(PDT)でPHPのコードを書く時の不便さを解消する
そもそも、静的型付けでない言語は好きではないのですが、好き嫌いを言っていると仕事が無くなってしまうので・・
そんなわけで、Eclipse(PDT)でPHPのコードを書くわけですが、時にあるクラスのインスタンスの配列を関数／メソッドに渡す形にしたい時があります。
<?php class A { /** * ID * @var int */ public $id; /** * 名前 * @var string */ public $name; }
<?php function a0(array $a) { foreach ($a as $aa) { // A のインスタンスである保証がないし、 // Eclipseで変数名候補を表示させたりできない(重要!!) var_dump($aa->name); } }
この時、関数「a0」内の変数「$aa」が何であるかという保証は何もありませんので、何らかのチェックをする必要があります。
PHPにはtype hintingという機能があり、以下のように書ければいいのですが・・
<?php // 実際にはエラーになる function a0(A[] $a) { // ・・・ }
<?php // 実際にはエラーになる function a0(multitype:A $a) { // ・・・ }
<?php // 実際にはエラーになる function a0(array(A) $a) { // ・・・ }
そんなわけで、Eclipse(PDT)をだますために、ひと工夫したりします。
instanceofで判定する
<?php function a1(array $a) { foreach ($a as $aa) { if ($aa instanceof A) { var_dump($aa->name); } } }
こうすると、「$aa」はクラスAのインスタンスであることが保証されるので、Eclipse(PDT)がそれを解釈して「$aa」をクラスAのインスタンスとして変数名候補の列挙などをしてくれます。
フィルタ用の関数を作る
<?php function a2(array $a) { $a = filterA($a); foreach ($a as $aa) { var_dump($aa->name); } } /** * * @param array $a * @return multitype:A */ function filterA(array $a) { $res = array(); foreach ($a as $aa) { if ($aa instanceof A) { $res[] = $aa; } } return $res; }
ポイントは、関数「filterA」のdocument comment内の「@return multitype:A」です。 この関数を通してやることにより、戻り値がクラスAのインスタンスであることが一応保証されるので、Eclipse(PDT)をだますことができます。
実際のところ、皆さんはこの問題をどうやって乗り越えているんでしょうか・・
identity column定義を削除する
DB2のトランザクションログ領域が足りない場合の対処
プライベートでデータを蓄積しているDB2サーバーで、巨大なインデックスを作ろうとしたら、トランザクションログがいっぱいというエラーが発生しました。
db2inst1@ubuntu14.04:~$ db2 "CREATE INDEX idx_hoge_hogehoge ON hoge(hogehoge)" DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0964C The transaction log for the database is full. SQLSTATE=57011 db2inst1@ubuntu14.04:~$
なので、以下のサイトを参考に、設定を変更して、再実行し、無事に成功しました。
以下はその対応内容のログです。
まずは現状を確認します。
db2inst1@ubuntu14.04:~$ db2 get db cfg for HOGEHOGE | grep LOG Catalog cache size (4KB) (CATALOGCACHE_SZ) = 300 Log buffer size (4KB) (LOGBUFSZ) = 256 Log file size (4KB) (LOGFILSIZ) = 1024 Number of primary log files (LOGPRIMARY) = 13 Number of secondary log files (LOGSECOND) = 4 Changed path to log files (NEWLOGPATH) = Path to log files = /home/db2inst1/db2inst1/NODE0000/SQL00002/SQLOGDIR/ Overflow log path (OVERFLOWLOGPATH) = Mirror log path (MIRRORLOGPATH) = Block log on disk full (BLK_LOG_DSK_FUL) = NO Block non logged operations (BLOCKNONLOGGED) = NO Percent max primary log space by transaction (MAX_LOG) = 0 Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0 Log retain for recovery enabled (LOGRETAIN) = OFF First log archive method (LOGARCHMETH1) = OFF Options for logarchmeth1 (LOGARCHOPT1) = Second log archive method (LOGARCHMETH2) = OFF Options for logarchmeth2 (LOGARCHOPT2) = Log pages during index build (LOGINDEXBUILD) = OFF db2inst1@ubuntu14.04:~$
3～5行目が関連する設定項目ですね。
まずは、即時反映できるという「LOGSECOND」を弄ってみます。
db2inst1@ubuntu14.04:~$ db2 update db cfg for HOGEHOGE using LOGSECOND 4000 IMMEDIATE SQL5130N The value specified for the configuration parameter "logsecond" is not in the valid range of "0" to "254". db2inst1@ubuntu14.04:~$
「LOGSECOND」の値に制限があるようです。
db2inst1@ubuntu14.04:~$ db2 update db cfg for HOGEHOGE using LOGSECOND 254 IMMEDIATE SQL5153N The update cannot be completed because the following relationship would be violated: "logprimary + logsecond <= 256". db2inst1@ubuntu14.04:~$
更に「LOGPRIMARY + LOGSECOND」の値にも制限があるようです。
結局、インスタンスを再起動する前提で、以下のように設定しました（元に戻しやすいように、それぞれ元の値の8倍）。
db2inst1@ubuntu14.04:~$ db2 update db cfg for HOGEHOGE using LOGFILSIZ 8192 DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. SQL1363W One or more of the parameters submitted for immediate modification were not changed dynamically. For these configuration parameters, all applications must disconnect from this database before the changes become effective. db2inst1@ubuntu14.04:~$ db2 update db cfg for HOGEHOGE using LOGPRIMARY 104 DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. SQL1363W One or more of the parameters submitted for immediate modification were not changed dynamically. For these configuration parameters, all applications must disconnect from this database before the changes become effective. db2inst1@ubuntu14.04:~$ db2 update db cfg for HOGEHOGE using LOGSECOND 32 DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. db2inst1@ubuntu14.04:~$ db2stop SQL1025N The database manager was not stopped because databases are still active. db2inst1@ubuntu14.04:~$ db2stop force SQL1064N DB2STOP processing was successful. db2inst1@ubuntu14.04:~$ db2start SQL1063N DB2START processing was successful. db2inst1@ubuntu14.04:~$ db2 "CREATE INDEX idx_hoge_hogehoge ON hoge(hogehoge)" DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL1224N The database manager is not able to accept new requests, has terminated all requests in progress, or has terminated the specified request because of an error or a forced interrupt. SQLSTATE=55032 db2inst1@ubuntu14.04:~$ db2 "CREATE INDEX idx_hoge_hogehoge ON hoge(hogehoge)" DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL1024N A database connection does not exist. SQLSTATE=08003 db2inst1@ubuntu14.04:~$ db2 connect to HOGEHOGE Database Connection Information Database server = DB2/LINUXX8664 9.7.5 SQL authorization ID = DB2INST1 Local database alias = HOGEHOGE db2inst1@ubuntu14.04:~$ db2 "CREATE INDEX idx_hoge_hogehoge ON hoge(hogehoge)" echo 2020/02/07 08:07 ; date DB20000I The SQL command completed successfully. db2inst1@ubuntu14.04:~$
無事に作成できました。
