Oracleの互換性検証(SI Web Shopping)

データベースから見たSI Web Shoppingの特徴には、下記が挙げられます。
・データベースのキャラクタセットはAL32UTF8であること。
・各国語キャラクタ・セット（AL16UTF16）を多く、使用していること。（※注１）

OracleとTibero両方のデータベースに接続してSI Web Shoppingインストールスクリプトを実行し、問題なくオブジェクトの作成ができるかどうか、画面にデータが正常に表示されるかどうかを確認します。また、OracleのスキーマとデータをTiberoに移行し、問題なく移行できるかどうか、移行したデータが正常に画面に表示されるかどうかを検証します。

※今回の検証では、非機能（性能、同時実行時の挙動、長期間動作させた際の安定性など）は対象にしていません。
※注１：NVARCHAR2（NATIONAL VHARCHAR2）は、Unicode文字データを格納するUnicodeデータ型でありながら可変長の文字列が格納されます。NCHARとNVARCHAR2データ型のキャラクタ・セットは、AL16UTF16またはUTF8のいずれかのみです。

ECサイト構築パッケージ「SI Web Shopping」の検証構成図

検証環境

環境構築の手順

1) DBMSのインストールおよびデータベース作成(Tibero、Oracle)

2) SI Web Shoppingアプリケーションの環境設定とインストール

・ Java実行環境JRE (Java Runtime Environment)のインストール

・ Apache Tomcatのインストールと環境設定

・ JDBCドライバ(tibero5-jdbc.jar)を$TOMCAT_HOME/common/libに配置

・ データベース接続先の設定xmlファイルを変更し、
TOMCAT_HOME%¥conf¥Catalina¥localhostに配置（Oracle、Tibero）

・ データベースのスキーマ、表領域の作成 (Oracle、Tibero)

・ インストールスクリプト(SQL、PL/SQL)を使用してスキーマ・オブジェクトと初期データの作成 (Oracle、Tibero)

検証の流れ（検証構成図）

1) SI Web Shoppingインストールスクリプト(SQL、PL/SQL)を実行する。

・ Oracle側でのスクリプト実行

Tibero側でのスクリプト実行

2) SI Web Shopping管理者画面でデータを更新・照会する。

・ Oracleを使用したSI Web Shopping管理者画面の商品管理

・ Oracleを使用したSI Web Shoppingの管理者画面の顧客管理

・ Tiberoを使用したSI Web Shoppingの商品管理

・ Tiberoを使用したSI Web Shoppingの管理者画面の顧客管理

3) tbMigratorツールを使用してOracleからTiberoへスキーマとデータを移行し、結果を確認する。

	1．両方のDBに接続 ・ソースDB：Oracle ・sysユーザー ・ターゲットDB：Tibero ・sysユーザー この際は、Tiberoの webshop、webshop_trackユーザーを”DROP USER ユーザー名CASCADE” SQL文で削除してから行います。
	2. スキーマの移行 OracleのWEBSHOP ユーザーとWEBSHOP_TRACKユーザーをTiberoに移行する。 移行オブジェクト ：テーブル、ビュー、プロシージャ、シーケンス、インデックス、データ、LOBなど
	3.移行後 WEBSHOPユーザー、WEBSHOP_TRACKユーザーがTibero側で作成されている。

検証結果

1）SI Web Shoppingインストールスクリプト(SQL、PL/SQL)をTiberoとOracle両方のデータベースに接続して実行する。
・ それぞれのデータベースで作成できたオブジェクト数は、次の通りです。

2）SI Web Shopping管理者画面でデータを更新・照会する。(Oracle、Tibero)

3）OracleからTiberoへのデータ移行

・ tbMigratorツールを使用してOracleのスキーマをTiberoに移行したところ、そのユーザーに対するパスワードを再設定する必要がありました。パスワードを設定しないと、Tiberoデータベースにログインできません。

・ それぞれのデータベースに作成できたオブジェクト数は、次の通りです。

Oracleの互換性検証（SI Web Shopping）の検証結果のまとめ

I. データベース側の検証
SI WEB Shoppingをインストールするためには、データベースのユーザーと表領域を作成しなければならない前提条件があったので、OracleとTibero両方のデータベース側で同じDDL文を実行したところ、問題なく作成できました。
また、SI WEB ShoppingアプリケーションをインストールするためのSQLスクリプト（オブジェクト作成、PL/SQLプロシージャ作成、初期データ作成）も両方のデータベースにそのまま実行できました。

・実行中のエラーについて
エラーとは言えませんが、ツールの使い方の違いで発生したエラーです。
Tiberoに備わっているtbSQLというツールは、Oracle SQL*Plusに似ているので、インストールスクリプトはTiberoのtbSQLツールで実行しました。
tbSQLはスクリプトの実行が簡単にできて、SQLスクリプトを流して2分程度で終わりました（Oracleもその程度でした）。
ただし、SQL*PlusのStartコマンド(ファイル探索パス)である”@@”は、tbSQLでは認識できないコマンドでしたので、tbSQLのSETFILEPATHコマンドでパスを書き換え、実行しました。
※このエラーについては、Tibero5SP1でサポートする予定だそうです。

II. アプリケーション側の検証

SI WEB Shoppingアプリケーションでのデータベース接続先の設定は、Oracle接続用のものを次のように変更（DBコネクションコード）し、%TOMCAT_HOME%¥conf¥Catalina¥localhostに置けば終わりです。（back.xmlの例）

変更した部分は次の通りです。その以外はOracleのものと同じです。

1. driverClassName="com.tmax.tibero.jdbc.TbDriver"（JDBCドライバのクラス名）

2. url="jdbc:tibero:thin:@ 192.168.100.163:8629:tibero01"（接続URL）

・実行中のエラーについて
検索画面でコードだけ検索すれば、問題なくデータが表示されましたが、商品名と結合して検索すると、エラーが発生しました。
Tomcatログを調べたところ、次のようなエラーメッセージが見つかりました。

java.sql.SQLException: Missing right parenthesis. at line 1, column 144:
OM COMMODITY_HEADER CH WHERE 1 = 1 AND (CH.COMMODITY_NAME LIKEC ? ESCAPE'¥')

原因は、"LIKEC ? ESCAPE '¥'"の"LIKEC"でした。
LIKECは、Tiberoではサポートされない機能であることが分かりました。
LIKEC は、完全なUnicodeキャラクタを使用して文字列を算出するためのSQL文ですが、データベースの必須条件がUNICODEであることだったので、"LIKEC"ではなく、"LIKE"にしても大丈夫かと思います。

実際に、LIKEに変更し、SQL文を実行した結果は、OKでした。

アプリケーションで、LIKECをLIKEに変更することができるのであれば、Tiberoは、SI Web Shoppingのデータベースとして使えると思います。

サポートされないことで、必ず必要とする機能やアプリケーションに多くの修正が必要とする場合、韓国ティーマックスソフト本社に機能について依頼することができ、その機能が必要であれば使えるように必ずしてくれるそうです。（日本ティーマックスソフト社より）

検証した範囲ではLIKEC が使われる画面以外は正常に動作しました。アプリケーションを単体検証した限りではSI Web ShoppingのTibero ポータビリティは高いと言えます。

III. パッチ(Patch)
SI WEB Shoppingの検証は、一回で終了した訳ではありません。残念ながらTiberoにバグがあり、SI Web Shoppingのインストールスクリプトを実行する際にエラーが発生したことがありました。

エラーが発生したものは、次の通りです。

• SELECT ～FOR UPDATE句
  ２つのテーブルに対してFOR UPDATE句が処理された場合（JOINなど）は、エラーが発生しました。
• NVARCHAR2型列の日本語文字化け
  NVARCHAR2以外の列には問題なかったのですが、NVARCHAR2のみ日本語文字化け現象が発生しました。

パッチ後、バグがFIXされ、問題なくスクリプトを実行することができ、すべてのオブジェクト作成ができました。エラーが発生した5月30日（水曜日）時点から～6月5日（火曜日）まで、6日間パッチを作っていただきました。土日を引くと、4日間で作って頂きました。

Oracleの互換性検証(Performance Analyzer 4)

Performance Analyzer 4（以下、PA4）は、Oracleデータベースのパフォーマンス分析診断・監視ツールです。データベースから見たPA4の特徴については、下記が挙げられます。
・Oracle JDBCドライバ(Thin、OCI)の機能を拡張実装しているアプリケーションである。（※注１）
・PA4のリポジトリデータベースとしてOracleデータベースとTiberoデータベースを使う。

今回の検証では、ターゲットデータベースの性能情報が両方のリポジトリデータベースに問題なく格納されるかどうか、両方のリポジトリデータベースから性能情報を取得してレポートを作成することができるかどうかを検証します。（データベース性能などの検証は、対象にしていません）

※注１：JDBC Thinドライバは、クライアント側で使用されるPure Javaドライバで、プラットフォームに依存せず、Oracleクライアントのインストールは必要ありません。
JDBC Oracle Call Interface（OCI）ドライバは、クライアント側で使用されるドライバで、Oracleクライアントのインストールが必要であるためOracleプラットフォーム固有です。

Performance Analyzer 4の検証構成図

検証環境

環境構築の手順

1) 監視用DBMSのインストールおよびデータベースの作成(Oracle)

2) リポジトリ用DBMSのインストールおよびデータベース作成(Tibero、Oracle)

3) 各クライアントPCに性能チューニング・監視のツール(PA4)をインストール

4) 各クライアントPCにTiberoJDBCドライバ(tibero5-jdbc.jar)を%PA_HOME%¥libに配置

5) PA4を起動してデータベースのスキーマを作成(Tibero、Oracle)

検証の流れ（検証構成図）

1) PA4でOracleリポジトリデータベースのスキーマを作成(PASYSTEM、PS4USER)し、PAのロギングとSQLトレース機能でOracleターゲットデータベースのログと性能情報を取得する。

2) PA4でTiberoリポジトリデータベースのスキーマを作成(PASYSTEM、PS4USER)し、PAのロギングとSQLトレース機能でOracleターゲットデータベースのログと性能情報を取得する。

3) OracleリポジトリデータベースのロギングとSQLトレースの統計情報に基づいてレポートする。

4) TiberoリポジトリデータベースのロギングとSQLトレースの統計情報に基づいてレポートする。

検証結果

1）リポジトリデータベースのスキーマの作成後、作成できたオブジェクト数は、次の通りです。

2）SQLトレースのレポート結果
20分間、監視ターゲットデータベースにランダムSQLを継続実行し、両方のリポジトリデータベースに収集したSQLをすべて取得し、そのSQLをレポート出力することまで出来ました。SQL件数はデータベースの共有メモリの使用頻度と、取得しようとする対象項目により異なる場合があります。

3）ロギングのレポート結果

20分間、監視ターゲットデータベースにランダムSQLを継続実行し、両方のリポジトリデータベースに収集したデータベースやOSの性能統計情報をすべて取得し、その情報に基づいた統計量リストのグラフを表示することができました。

Oracleの互換性検証（Performance Analyzer 4）検証結果のまとめ

I. データベース側の検証
PA4で両方のリポジトリデータベースのスキーマを作成することができ、監視ターゲットデータベースから性能・ログ情報を取得して両方のリポジトリデータベースにデータを格納することができました。

II. アプリケーション側の検証

アクアシステムズのPA4は、Java言語で開発されました。
Oracle JDBCドライバを使用しているソースコードの中、DB Connection部分だけ修正すれば動けると思ったのですが、そのまま利用できず、DB Connection以外のソースコードも修正する必要がありました。その結果、監視がーゲットデータベースの性能・ログ情報を取得することができ、その統計情報に基づいてレポートまで検証することができました。

III. ソースプログラムのポーティング

今回の検証のため、Tiberoデータベースをリポジトリデータベースとして使えるように既存のプログラムを修正しました。その時、開発者にソース改変作業で難しかったと感じたことなど、開発観点からの意見をお伺いしました。

TiberoとOracleでは、Error/Exception発生時のError Numberが異なる。

►PL/SQLにおいて、Error発生時、Error Numberによってその後の処理が変わるようなProgram構造は、非常に一般的です。このような箇所では、Error番号によって処理を振り分けるので、下記のような構造を取っている場合がふつうです。

switch (errorNumber) {
case 1: // Error Number '1' の場合の処理
break;
case 2: // Error Number '2' の場合の処理
break;
:
:
}

上記のエラーを避けるためには、以下のような方法をお勧めします。

・方法１：例外処理する。

WHEN ZERO_DIVIDE THEN
DBMS_OUTPUT.PUT_LINE('ORA-01476(SQL CODE : -1476)');
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('ORA-01403( SQL CODE : +100 )');
WHEN TOO_MANY_ROWS THEN
DBMS_OUTPUT.PUT_LINE('ORA-01422(SQL CODE : -1422)');
WHEN DUP_VAL_ON_INDEX THEN
DBMS_OUTPUT.PUT_LINE('ORA-00001(SQL CODE : -1)');
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('OTHERS Error');

・方法２：OracleのエラーコードをTiberoのエラーコードに合わせる。

switch (Tiberoのエラーコード) {
case 1: // Error Number '1' の場合の処理
break;
case 2: // Error Number '2' の場合の処理
break;
:
:
}

それ以外、直接にError Numberで判断するPL/SQLプログラムを実行した場合、上記のエラーが発生する可能性がありますので、ご注意ください。

静的データ・ディクショナリ・ビュー(DBA_xxx)、動的パフォーマンス・ビュー(V$xxxx)の数と項目が少ない

►dba_users とか、v$session と言ったTableがTiberoにもありますが、Oracle側のdba_xxxxにあるColumnがTiberoには無かったり、同名のColumnがあっても内容（の意味）が異なっていたりしました。

実際に静的データ・ディクショナリ・ビュー(DBA_xxx)、動的パフォーマンス・ビュー(V$xxxx)などを使うアプリケーションは少ない、データベースの性能分析ツールやデータベースの管理・開発ツールのみで使われると思います。この件について、今後のパッチで改善する予定があるそうです。

その他のアプリケーションの検証結果（3種類）

複雑で高度な技術を求めるアプリケーションだけではなく、データのやり取りで済むアプリケーションも検証対象にしました。Tibero JDBCドライバやODBCデータソースアドミニストレータでデータベースと連携し、Oracleアプリケーションのソースコードを変更することなく、そのままに利用できるかどうかを検証します。

Tibero JDBCドライバを使用したアプリケーション

Tibero JDBCドライバを使用したアプリケーションの検証結果

１）JFree Chartプログラムは、Oracle JDBCドライバの代わりにTibero JDBCドライバを入れ替えるだけで済みました。データを更新し、グラプ確認すると、グラプの分布も変わりました。
２）OpenOfficeは、Oracle JDBCドライバの代わりにTibero JDBCドライバを入れ替えるだけで済みました。DML文、DDL文問題なく動作し、オブジェクトとデータが画面を通して確認できました。

Tiberoの ODBCデータソースアドミニストレータを連携したアプリケーション

Tiberoの ODBCデータソースアドミニストレータを連携したアプリケーションの検証結果

Tibero 5 ODBCドライバ（odbc_driver_install.exe、libtbcli.dll）は、正常にインストールができ、A5:SQLツールとの連携も問題なくTiberoデータベースに接続することができました。
テーブル一覧などが問題なく表示され、SQL文も問題なく実行できました。