Cognos Analytics アップロードデータをデータベースに保管する(12.0.2～)

## 概要
Cognos Analytics 12.0.2からExcelやCSV等のアップロードデータファイルをDb2データベースに保管可能となりました。
アップロードデータ参照時にCognosノードにかかっていた負荷が、DBノードに任せれる![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/e3b9e705-2564-57ee-a595-7c2c5678fbb2.png)
事になるのがメリットです。
実際に色々と触って検証してみて、いくつか知っておくべきポイントがわかりましたので共有します。

## 参考情報
**Db2 を使用して、アップロードされたファイルおよびデータ・セットにデータを保管する**
https://www.ibm.com/docs/en/cognos-analytics/12.0.0?topic=administration-using-db2-store-data-in-uploaded-files-data-sets

## セットアップ手順
**LinuxノードでDB作成**
保管するDb2ノードはWindows OSはサポートされていません。アップロード時に以下のようなエラーとなります。
UnixかLinuxノードをご選択ください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/11092a7c-f3eb-c5ca-0ca5-e5dbd42e810a.png)

今回はRedhatノードで試してみました。
DBはContent Storeと共用はNGで、カラムナー型のDBを使用する必要があります。
https://www.ibm.com/docs/en/db2/11.5?topic=to-creating-setting-up-your-database-configuration-analytic-workloads
https://www.ibm.com/docs/en/db2/11.5?topic=organization-enabling-parallel-processing-column-organized-tables

```html
db2 "CREATE DATABASE DB2COL ON /mnt/db2path USING CODESET UTF-8 TERRITORY JP COLLATE USING IDENTITY PAGESIZE 32 K"
```
インスタンス構成パラメーター変更
```html
db2 update dbm cfg using INTRA_PARALLEL YES
db2stop
db2start
```

データベース構成パラメーター変更
```html
db2 update db cfg using dft_table_org COLUMN
db2 update db cfg using dft_degree ANY
db2 update db cfg using dft_extent_sz 4
db2 update db cfg using sheapthres_shr 32768
db2 update db cfg using sortheap 1638
db2 update db cfg using auto_reorg ON
db2 ALTER THRESHOLD SYSDEFAULTCONCURRENT ENABLE
```

データ・サーバー接続作成(データ・セット保管)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/2cbd2e53-e45a-cdc5-30fa-101cd7566436.png)

名前を入力し、IBM Db2を選択し次へ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/41a6939f-222e-7fd1-0da9-f9a1d71e55ac.png)

URLを記載し次へ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/6e749efc-34aa-9f14-cf01-c2857c0f5d42.png)

サインオンを追加し接続のテスト
この時、接続に使用するユーザーは（Create tables (CREATEIN), Drop tables (DROPIN), INSERT (INSERTIN) and query (SELECTIN) )という強い権限が必要です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/54e7d18b-4c62-89fe-1085-fe7b28d74895.png)

問題なければ次へ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/9af6a784-ef52-5a4e-1b0e-ecb6819a0841.png)

作成する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/aafaae98-b0a1-1d29-8600-0c75bf38e791.png)

以下のような表示となります
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/c2308cd2-baed-9938-fbed-c090175147e2.png)

TestData01.xlsxをアップロードしてみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/b31d6f9e-af0c-81db-fd64-c91fd6ed5049.png)

DBにテーブルが自動的に作成されています
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/e1619cf4-e0c3-a141-c8fd-37556802c39f.png)

TestData02.xlsxをアップロード
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/f86e41f7-4f0c-e72a-4a0e-d2cbd9f79b04.png)

2個目のテーブルが作成されました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/438be133-586b-688f-d097-2881972e264c.png)

基本はこのような動作になります。

**ポイント**
Db2にデータ保管した場圧縮されるものの、ファイルとしてCognosサーバー上に保管するこれまでのやり方(Parquet)よりやや圧縮効率が良くないようなので、Db2側にはそれも考慮して表スペース領域用意しましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/4e36448f-fcff-e5ca-57e2-865d249adf76.png)

## Export/Importで持ち運べるか実験
チームコンテンツにデータエントリーを移動
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/1c36bf46-5f29-0b06-13dd-7b2b18c538af.png)

**ケース1：データアップロードエントリーのあるフォルダのみExport/Import**
Export。該当のフォルダだけをエクスポート。「アップロードしたデータを含める」をチェック。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/9033fb4b-a4c4-5492-873c-5f9b1ffdc8c9.png)

ここはチェックなし
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/ce95b1f5-c562-c456-2991-f72539d5005b.png)

StoreDataフォルダを削除
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/7bda9e6a-f30c-73e1-7948-42b162e28c3b.png)

テーブルは消えない
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/83fb9f74-35cc-b722-a5cc-5232b5cab5bd.png)

※ポータルでアップロードデータのエントリー消すと、後からクリーナースレッドが発動してDB上のテーブルを削除してくれる。
デフォルト15分間隔だが、Query Serviceの詳細設定の以下のパラメーターで変更可能
```html
qs.dbdatasets.orphanedTablesCleanupInterval
```

DBごと再作成
```html
db2 drop db DB2COL
db2 "CREATE DATABASE DB2COL ON /mnt/db2path USING CODESET UTF-8 TERRITORY JP COLLATE USING IDENTITY PAGESIZE 32 K"
以下、前述の手順と同じ。
```

インポート
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/0eeda2a4-463c-442a-3de4-2d948a9aff1f.png)

以下のチェック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/0daea674-1b8b-a469-694a-1e369cb3363b.png)

データアップロードエントリーが復旧
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/ea0814c4-910d-4f4d-d1b8-2909eef02ac3.png)

テーブルも自動作成される
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/a41f0d1c-f5d1-1f3e-5671-4a78a152ebbb.png)

中身も問題なく見れる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/67de7b2b-fc08-96bf-09db-27a643dbcfc6.png)

**ケース2：データ・サーバー接続も含めてExport/Import**
同様にExport操作
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/ab719014-1d1d-8064-b989-049668ced1e6.png)

ここで「データ・ソースと接続を含める」をチェック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/7ce3f3e8-1d25-897b-48d1-710afd01ead5.png)

StoreDataフォルダを削除

データサーバー接続を削除
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/425e2acf-6b40-7852-69a0-c9d4a6e7a029.png)

DBごと再作成

インポート
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/2b50a07c-023e-21c8-27e8-53daab1598e6.png)

ここをチェック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/3fe93dd3-3255-f1a5-e9b5-fa3d62e4227f.png)

アップロードデータが復旧
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/0bcff4f1-e9e2-91d9-11be-720f9b91a7cb.png)

データサーバー接続も復旧
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/b5fbe03a-5673-a6e9-ad50-9c85d63f7d40.png)

テーブルも自動作成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/270b866c-53b6-e968-537d-3207b9ef92e7.png)

中身のデータも問題なし
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/6436346b-4d8c-945a-7510-97cdaebe3510.png)

**ケース3：Content Store全体のExport/Import**
ExportでContent Store全体
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/2408ba8a-59c2-6b79-599d-3990cdfe06f4.png)

StoreDataフォルダを削除

データサーバー接続削除

DB再作成

インポート
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/ed43cf19-a479-ef25-8dba-ea76c596d1f1.png)

アップロードデータ復旧
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/7aebb4ee-ab6b-21c1-d2b7-690ad8f71fe6.png)

データ・サーバー接続復旧
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/e91626a6-508c-ff7a-6ea5-a6992d834e6e.png)

テーブルも自動作成

中身のデータ参照も問題なし
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/1cf0bbeb-fab6-b28a-3037-5e28e952f558.png)

## DB側での処理について
サポートされるDB製品は以下4つ
```html
ORACLE
Db2 LUW ※Db2 Z、Db2 I、Big SQLは接続エラーとなる
SQL Server
Informix
```

Compute Serviceを使ってクエリーが発行される。
それによりワークロードはCognosサーバーの負荷は小さくなり、DBノードに任せる事ができるのがメリット。
https://www.ibm.com/docs/en/cognos-analytics/12.0.0?topic=sets-configuring-compute-service

Content Managerのデフォルトサイズ制限(2GB)は適用されなくなり、DB製品側のサイズ制限が適用される事となる。
BLOBタイプ列に保管される。
https://www.ibm.com/docs/en/cognos-analytics/12.0.0?topic=SSEP7J_12.0.0/com.ibm.swg.ba.cognos.ca_new.doc/c_ca_nf_11_2_4_default_max_size.htm

Row size(列の合計長)32Kリミットに注意。
https://www.ibm.com/docs/en/db2/11.5?topic=sql-xml-limits
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/cd37ecf7-17a7-151b-3bb0-6f006fccb472.png)

**レポート上でフィルターした場合、フィルターがかかったSQLがDBに投げられるのか検証**
FMパッケージとCSVを結合したデータモジュールを作成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/f73e0de3-22c7-a38e-911e-7d321716c6bc.png)

CSVの製品ラインにフィルターをかけたレポートを実行。
保管DB側にwhere句の効いたSQLが投げられているので、全量とって来てしまうという事は無さそう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/f72fba8a-88a3-057a-3d7c-1b20abc7d980.png)

## バックアップ運用について
Export/Importで移行可能なのは便利だが、逆に言うとExport/Importが長時間化するので、バックアップはContent Storeと保管DBのDBバックアップ取得が良いのだろうかと考え検証してみた。
Content Storeと保管DBのリストアで回復可能だろうか

Content Store バックアップ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/96d5f0ea-ca31-7f78-3f4e-28cf446cfec4.png)

保管DBバックアップ
```html
$ db2 backup db db2col to .
```

フォルダ削除
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/d37b2c25-0d68-a244-7ef3-07c5b38239ce.png)

テーブルが削除されていることを確認。15分くらい待つと自動削除された。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/e13fbc8f-48a7-a1d8-a3c8-7b47beaec667.png)

Cognos停止
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/45eb0ca1-e5aa-473c-d308-fc7245038c7e.png)

Content Store リストア
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/4decb81b-21cc-9df7-7f7c-58622d30803b.png)

保管DBリストア
```html
$ db2 restore db DB2COL from . 
SQL2539W  The specified name of the backup image to restore is the same as the name of the target database.  Restoring to an existing database that is the same as the backup image database will cause the current database to be overwritten by the backup version.
Do you want to continue ? (y/n) y
DB20000I  The RESTORE DATABASE command completed successfully.
```

Cognos起動
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/ec3ba31c-15e9-4afc-1718-e14113bbb1cd.png)

データも復活
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/72cef305-d882-8abc-2181-d665f3320149.png)

レポートも実行可能
DBのバックアップを取得しておけば、復旧できる事が確認できた。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/53d78670-e753-7e69-d1c4-29c5713bb336.png)

## その他知っておくべき事
保管DBを複数使用した場合は、実行時に選択する事は不可でエラーになるので、各ユーザーがデータ・サーバーエントリー1個だけの権限を持つように権限設定をする。
データサーバーのプロパティーから権限設定。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/fa15c85e-a657-d54d-94cb-fddd07582652.png)

データが保管DBにあるか、ファイルとして保存されているかは、プロパティからわかる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/94d81299-427e-50c1-44f0-eb3d91941069.png)

「データの場所」がファイルだと「Content Manager」になる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147246/f6b897ab-6498-23ef-dfe0-fb7b68a7b36f.png)

## 結論
データアップロードのDBへの保管は、レポート上のフィルターのSQLのWhere句への付与もありパフォーマンス面での懸念なく、Cognosサーバー上からDBサーバーに負荷をオフロードできるメリットがある。
データの列長の合計など、DB側の制限を超えるアップロードデータを使用しないのであれば、DB側への保管機能は使用するのが良いかと思います。