Empress

2007/11/4更新

対応バージョン: 6.10

システムテーブル、及びtabzeroファイルを変更することにより可能である。

例えばユーザbeforeが所有するtestというDBをユーザafterにコピーする場合は以下のようにする。

DBを複製

DBの実体(~before/test)を別ディレクトリ(~before/tmp/test)にコピーする。

% whoami
before

% cd

% mkdir tmp

% cp -r test tmp

コピー先DBのシステムテーブルを変更

% whoami
before

% cd ~/tmp

% empcmd test "update sys_tables set tab_creator='after'"

% empcmd test "update sys_privs set priv_grantor='after' \
    where priv_grantor='before'"

% empcmd test "update sys_privs set priv_grantee='after' \
    where priv_grantee='before'"

% empcmd test "update sys_attr_privs set apriv_grantor='after' \
    where apriv_grantor='before'"

% empcmd test "update sys_attr_privs set apriv_grantee='after' \
    where apriv_grantee='before'"

同DBのtabzeroファイルを変更

% vi test/tabzero
:
MSDBADMINISTRATOR=after ← 変更後のユーザに変更

移行先アカウントにて同DBをディレクトリごとコピー

% su - after

% whoami
after

% cp -r ~before/tmp/test ~

システムテーブルの変更を有効化

% whoami
after

% empadm test recompile_all

関連資料・記事

2008/3/9更新

対応バージョン: 6.10

sys_dictionaryで管理されている対象テーブルの管理情報に不整合が生じたと思われるので、以下のコマンドにてsys_dictionary内の対象テーブルの管理情報を再構成する。

% empadm <DB> recompile <テーブル>

2008/2/6更新

対応バージョン: 6.10

Empressのdisplay dbコマンドでDB内のテーブル一覧を表示しようとすると以下のようなエラーが出る。

% ls -ld comdb
drwxr-xr-x ... 12月01日 06:00 comdb/

% ms comdb
  Empress V6.10
  (c) Copyright Empress Software Inc. 1983, 1997
1* display db ;

*** System Problem *** コーディネータ ファイルをオープンすることができません。

*** User Error *** '/foo/bar/comdb' は有効なデータベースではありません。

これは、DBの所有者以外のアカウントでdisplay dbを実行したか、あるいはコーディネータファイル(/cdinator)に更新権がない場合に発生する。

これに関連するEmpressの仕様を理解しておくとよい。

EmpressはデフォルトでDBの所有者以外からのアクセスを拒否する。
DBを参照するだけであってもリードロックが発生するのでロックファイル(/_lock配下に複数存在)に書き込みができないとDBアクセスエラーになる。

2007/11/18更新

対応バージョン: 6.10

SQL文で「display db」を発行する。

テーブル一覧

% empcmd testdb "display db"
****  Database: /foo/bar/testdb ****

table1
table2
table3

テーブルレイアウト

% empcmd testdb "display db all"
****  Database: /foo/bar/testdb ****

***  Table: table1  ***

     id         character(16,1)
     name       nlscharacter(30,1,0)
   :

2007/11/4更新

対応バージョン: 6.10

Empressではテーブルのフラグメント(断片化)状態を知る方法がない。

Empress DBのデータはUNIXのファイルシステム上に作られているのでファイルシステムとしては当然断片化されているが、それはカーネルやI/Oサブシステムなどがやっている作業であってDBエンジンとしてはそこまで関知していないので結果的にフラグメントの状態は調べられない。

2007/11/4更新

対応バージョン: 6.10

Empressは個々のデータベース毎にデータ辞書テーブルと呼ばれる以下の5つのシステムテーブルを持っており、テーブルの属性に関する情報をいろいろな形で管理している。

sys_tables

テーブルに関する情報

sys_attrs

属性に関する情報

sys_privs

テーブルアクセス特権に関する情報

sys_attr_privs

属性アクセス特権に関する情報

sys_dictionary

上記のテーブルのコンパイルされた全情報を持っている。

このうち、主にテーブルのアクセス権に関する情報はsys_tablesとsys_privsで管理しているので、以降はこの2つのテーブルについて説明する。

sys_tables

tab_name

テーブル名

tab_number

テーブル番号

この番号はテーブル名に対する実際のファイル名の割当となる。

例えばテーブル番号が1の場合テーブル情報が格納されているファイル名は$HOME//0001.relとなる。

tab_type

現在未使用

tab_numattrs

テーブル内の属性数

tab_lock

テーブルに設定されたロックレベル

・n : 未設定

・r : レコードロック ... Empress制御用テーブル(sys_*)はこのレベルで作成される。

・g : グループロック

・t : テーブルロック

tab_perms

テーブルに対応するファイルに設定されたOSのパーミッション

ファイルはUNIXアカウントのホームディレクトリ配下に作成されるのでそのアカウントのumaskが適用される。

tab_index

テーブル上に生成されたあらゆるインデックスに関する情報

tab_refer

テーブル上の全ての参照制約定義

tab_view

ビューの場合はビューを定義するselect文

tab_vwcomp

ビューを定義するコンパイルデータ

tab_location

リモートの場合はテーブル位置

tab_creator

テーブルを生成したUNIXアカウント名

tab_crtime

テーブルが生成された日付及び時間

tab_comment

create commentコマンドによって生成されたコメント

tab_param

Shared Memoryのパラメータ

sys_privs

1つのテーブルにつきgrantor/granteeのペアで計2レコード保持

priv_grantor

特権を与える人

priv_grantee

特権を受ける人(UNIXアカウント)

priv_tabnum

特権が適用されるテーブルの識別番号(= tab_number@sys_tables)

priv_updattr

テーブル及びビューにおける個別の属性更新特権を設定するテーブルであるsys_attr_privs内にレコードがあるかどうかを`y'か`n'で表示する。

grantorがテーブル内の少なくとも1つの属性(但し全ての属性ではない)に関する更新特権をgranteeに与えた場合はsys_attr_privs内にレコードが存在する。

priv_delete

テーブルからレコードを削除(delete)する特権

・n : delete特権がない。

・y : delete特権は有するが、この特権を他に与える権限はない。

・g : delete特権を有し、さらにこの特権を他に与える権限も有する。

priv_insert

テーブルにレコードを挿入(insert)する特権

・n : insert特権がない。

・y : insert特権は有するが、この特権を他に与える権限はない。

・g : insert特権を有し、さらにこの特権を他に与える権限も有する。

priv_select

テーブルからレコードを読み込む(select)する特権

・n : select特権がない。

・y : select特権は有するが、この特権を他に与える権限はない。

・g : select特権を有し、さらにこの特権を他に与える権限も有する。

priv_update

テーブルの全属性を更新(update)する特権

・n : update特権、またはpartial update特権(*)がない。

・y : update特権は有するが、この特権を他に与える能力がないfull update特権。

・g : update 特権を有し、さらにこの特権を他に与える能力があるfull update特権。

(*) partial update特権は一部の属性が更新された場合のみ発生する。この場合、attr_privs属性は`y'の値を持ちsys_attr_privsテーブルに注目する。

priv_display

テーブルを表示(display)する特権

・n : display特権がない。

・y : display特権は有するが、この特権を他に与える権限はない。

・g : display特権を有し、さらにこの特権を他に与える権限も有する。

priv_alter

テーブルを変更(alter)する特権

・n : alter特権がない。

・y : alter特権は有するが、この特権を他に与える権限はない。

・g : alter特権を有し、さらにこの特権を他に与える権限も有する。

priv_drop

テーブルを削除(drop)する特権

・n : drop特権がない。

・y : drop特権は有するが、この特権を他に与える権限はない。

・g : drop特権を有し、さらにこの特権を他に与える権限も有する。

priv_empty

テーブルを空(empty)にする特権

・n : empty特権がない。

・y : empty特権は有するが、この特権を他に与える権限はない。

・g : empty特権を有し、さらにこの特権を他に与える権限も有する。

priv_index

テーブル上にインデックスを生成(index)する特権

・n : index特権がない。

・y : index特権は有するが、この特権を他に与える権限はない。

・g : index特権を有し、さらにこの特権を他に与える権限も有する。

priv_sort

テーブルをソート(sort)する特権

・n : sort特権がない。

・y : sort特権は有するが、この特権を他に与える権限はない。

・g : sort特権を有し、さらにこの特権を他に与える権限も有する。

2007/12/15更新

対応バージョン: 6.10

Empressのセキュリティは以下の2点によって保たれている。

1. UNIXファイルシステム上のアクセス権限

2. Empress管理上のアクセス権限

以下、それぞれについて説明する。

UNIXファイルシステム上のアクセス権限

EmpressデータベースはUNIXファイルシステムのディレクトリ及びファイルで構成されているので基本的にそれらへのアクセス権限はUNIXファイルシステム上のアクセス権に従う。

Empressデータベースに設定されるUNIXファイルシステム上のアクセス権限の設定は以下のパラメータによって設定される。

UNIX上のumask値
Empress管理変数MSDBPERMSの設定値 (custom/tabzero内)
Empressシステム変数MSPERMSの設定値 (custom/initfile内)

Empress管理変数MSDBPERMS及びシステム変数MSPERMSの設定はEmpressデータベース上のumask値と考えてよい。

MSDBPERMS = RWX, RWX, RWX

権限の適用範囲は左から順に

所有者
グループ所属者
上記以外の全ユーザ

となっており、権限種別は以下のようになっている。

R : 読み取りアクセス権
W : 書き込みアクセス権
X : 検索/実行アクセス権

アクセス権を与えない場合は与えない権限種別を設定に記述しない。

例) 書き込み権は所有者のみ、グループ所属者およびその他のユーザは読み込みのみ可能。

MSDBPERMS=RW,R,R

ここで、ファイルへのアクセス権限を決定する際どの設定が優先されるかについて記す。

管理変数MSDBPERMSは/tabzeroに記述されていて、データベース内に新規に作成されるテーブルのファイルアクセス権限を無条件にこの変数の設定で与える(UNIX上のumask値やMSPERMSの設定は無視される)。

MSDBPERMSに設定が無い場合はUNIXのumask値やMSPERMSの設定が使われる。

新規に作成するデータベースのシステムテーブルに対してMSDBPERMSの設定を有効にする為にはcustom/tabzeroファイルに記述されているMSDBPERMSを変更する。

但し、新規にデータベースを作成しようとする全てのユーザに対してこの設定が有効になってしまうので、注意が必要である。

さて、次に有効となる設定はUNIXのumask値とMSPERMSの設定値の掛け合わせによる設定値がそれである。

この設定値は個々の設定では意味を持たず、両方の値の「所有者」、「グループ」、「その他」でそれぞれ権限を比較し両方に設定のある権限が有効になる。

また、前述の通りMSDBPERMSが設定されていない場合に有効になる。

個々のデータベース毎、データベース内の個々のテーブル毎にアクセス権限を設定したい場合はこの方法が有効である。

但し、Export/Import時などはファイルのアクセス権限はImport時の環境に左右され、自動的に元の設定にはならないので注意が必要である(Import時にファイルアクセス権に関して再設定をするしくみをシェルスクリプトなどのバッチ処理にして組み込む必要がある)。

Empress管理上のアクセス権限

Empress管理上のアクセス権限は

1. データベース作成時の管理変数MSDBDBAPRIVSの設定値

2. テーブルの作成時の管理変数MSDBPRIVSの設定値

3. SQLのgrantコマンドによる設定値

で与えられる。

1.と2.の設定値は作成時のデフォルト値として使用され、作成後個々のテーブルに対してアクセス権限を与えるために3.の方法がとられる。

MSDBDBAPRIVSはcustom/tabzeroの設定のみ有効でEmpressを使用する全てのユーザに対して設定値が使用される。

この設定値はデータベースのシステムテーブルに対して適用される。

MSDBPRIVSはDATABASE/tabzeroの設定が使用され、変更後に新規で作成されるテーブルに対して有効になる。

SQLのgrantコマンドによるアクセス権限の設定は基本的にはテーブルの作成者(Creator)が行うのが一般的であるが、該当テーブルに対してgrant権限を持っていれば権限委譲可能である。

但し、grantコマンドを実行する為にはシステムテーブルに前述の「UNIXファイルシステム上のアクセス権限」で説明したファイルアクセス権限がgrantを実行するユーザに対してある事が必要であり、かつgrantを実行するユーザに対してシステムテーブルにselect、updateの権限が、該当テーブルには実行ユーザに対してgrantオプション付きの該当権限がなければならない。

補足

empimptでテーブルあるいはデータベースをインポートする場合にempimptのオプションで-pを使用し、全てのユーザに対してdisplay及びselect特権を与える事ができる。

2007/11/18更新

対応バージョン: 6.10

empimptコマンドでインデックス情報以外のImportを全て抑制する。

% empimpt -d -k -l -r -t -v <exportファイル> <DB> [<テーブル>]
-d

データimport抑制

-k

参照整合性制約情報のimport抑制

-l

ロックレベルimpot抑制

-r

範囲チェック情報import抑制

-t

テーブル作成抑制

-v

冗長モード

-gなし

grant特権情報import抑制

関連資料・記事

2007/11/4更新

対応バージョン: 6.10

このエラーはサーバプロセスが異常な状態にある時にクライアントから接続があり、セッションを張れず終了した場合などに出力される。

原因としては以下のようなものが考えられる。

/tmpのODBCサーバ関係ディレクトリ及びファイルの削除

ODBCサーバは起動時に/tmp/.EmpODBC-unixディレクトリを作成しその中にロックファイルなどを作成する。

このファイルやディレクトリが削除されるとサーバがダウンする。

削除例)

cronで一定時間毎に/tmpをクリーンアップしている。
手動で/tmp配下を削除した。

ODBCサーバ関係の共有メモリの削除

ODBCサーバは専用の共有メモリも使用するのでそれが削除された可能性がある。

削除例)

ipcrmコマンドなどで削除した。

2007/11/4更新

対応バージョン: 6.10

前回サーバが正常に終了していないためロックファイル/tmp/.EmpODBC-unix/.private/.lockが残っている。

同ファイルを削除してから再度サーバを起動する。

2007/11/4更新

対応バージョン: 6.10

Tru64 UNIXのrootのデフォルトのcron設定で毎日4:20に以下の処理を行っているのが原因。

20 4 * * * find /tmp/ -mount -type f -atime +2 -exec rm -f {} ¥;

この処理で削除対象となるファイルのうちODBCサーバのロックファイルである/tmp/.EmpODBC-unix/.private/.lockは同サーバが動いている間存在している必要がある。

しかしcronにて「2日以上アクセスされていない」ファイルは削除対象となるため、ODBCサーバを起動してから2日以上経つと4:20に削除されてしまう。

このような状態でODBCクライアントからサーバに接続があると、ODBCサーバ設定パラメータのEMPODBC_LOGFILEで指定したログファイルに「Lock Unmatched」というメッセージが出力され、クライアントからの接続要求が失敗する。

つまり、クライアントから見るとODBCサーバが落ちたように見える。

毎日ODBCサーバを再起動していればこの事象は起きないが、cronの設定を以下のように変更することでも対応できる。

20 4 * * * find /tmp/ -mount -type f -atime +2 -a ! -name ".*" -exec rm -f {} ¥;
ファイル名の先頭が「.」のものは削除しないようにするため、削除条件に「! -name ".*"」を追加

2007/11/4更新

対応バージョン: 6.10

ODBCサーバの管理コマンドはempoadmコマンドのサブコマンドとして実装されている。

以下、準備とそれぞれのサブコマンドについて説明する。

準備

% su
# setenv MSLANG japanese
# setenv MSPATH /usr/users/ms32/v6.10
# setenv PATH ${PATH}:${MSPATH}/bin

状態チェック

# empoadm svinfo

==============================
Daemon   PID : 300144
Real   owner : root (system PRIVILEGED account)
Effect owner : root (system PRIVILEGED account)
Interface IP : *
Service Name :
Service Port : 6322/tcp
Listen  qlen : 5
Working Dir. : /usr/users/ms32/ODBC/work
Log     file : /usr/users/ms32/ODBC/tmp/log.txt
Account file : /usr/users/ms32/ODBC/tmp/account
Passwd  file : /usr/users/ms32/ODBC/odbc.pwd
Idle timelim : 1800(sec)
Blocking lim : 120(sec)
Clients  lim : 30
Clients  num : 1 ← 接続中のクライアント数
Recv bufsize : 52000
Send bufsize : 10000
Query Timeout: 300
Max Rows     : 65536
Start   Time : 17:32:59 Jan/31
Config  Time : 17:32:59 Jan/31
==============================

ログファイル表示

# empoadm loginfo

クライアントの接続状況

# empoadm showclient
USER.. ..PID ADDRESS........... START.... STAT. STAT_TIME
foo    ***** 10.197.10.188.1721 17:18 Wed Idle  00:00:13

利用可能なポート番号の確認

# empoadm chkport

The default Empress ODBC Server port is 6322.

*************** The port 6322 is already in use.
***************
*** Warning *** Empress highly recommends that port id 6322 be used for
*************** the Empress ODBC server. If this port id is used by a
*************** a program other than Empress ODBC server, please adjust
*************** the other program to use other port id if possible.


The other port ids which are available are:

6323 6324 6325 6326 6327 6328 6329 6330

→ 6322は使用中なのでその次から利用可能なポート番号がリストアップされる。

クライアントの接続解除(接続中断)

# empoadm rmclient foo ← empoadm showclientで表示される<USER>を指定

サービスポートクローズ&サービスセッション終了

# empoadm svclose
Empress ODBC server daemon listen port 6322 closed.
Daemon will exit after all 1 clients terminate

# empoadm svinfo
==============================
Daemon   PID : 300144
Real   owner : root (system PRIVILEGED account)
Effect owner : root (system PRIVILEGED account)
Service Port : Closed ← クローズ
Working Dir. : /usr/users/ms32/ODBC/work
Log     file : /usr/users/ms32/ODBC/tmp/log.txt
Account file : /usr/users/ms32/ODBC/tmp/account
Passwd  file : /usr/users/ms32/ODBC/odbc.pwd
Idle timelim : 1800(sec)
Blocking lim : 120(sec)
Clients  lim : 30
Clients  num : 1
Recv bufsize : 52000
Send bufsize : 10000
Query Timeout: 300
Max Rows     : 65536
Start   Time : 17:32:59 Jan/31
Config  Time : 17:32:59 Jan/31
==============================

シャットダウン

# empoadm svshut

接続ユーザがいると以下の警告が表示される。

************** Warning ***************
1 service process(es) still running !!
Do you want to shut down Empress ODBC server? (Yes/No) : ← 強制終了の確認

Sending TERM signal to ODBC server ...
.
Cleaning up ...
Done

2007/11/4更新

対応バージョン: 6.10

対象テーブルにインデックスが張ってあるにもかかわらず、そのインデックスに名前が付けられていないとリンクができない。

2007/11/4更新

対応バージョン: 6.10

以下のような原因が考えられる。

ODBCサーバが起動していない。
Windows側の[コントロールパネル] > [ODBCデータソース]で設定するDSNの設定で、接続ユーザとして指定しているUNIXアカウントがODBCサーバ側のユーザ認証ファイルに登録されていない。

2007/11/4更新

対応バージョン: 6.10

empcleanでも稀にロックが解除できないケースがあるのでその場合は以下の方法でロックを解除する。

ロック情報表示

% empadm <DB> lockinfo

不正ロッククリア

% empadm <DB> lockclear

参考までに、不正コーディネータ情報をクリアする手順も示す。

コーディネータ情報表示

% empadm <DB> coordinfo

不正コーディネータ情報クリア

% empadm <DB> coordclear

2007/11/4更新

対応バージョン: 6.10

empcleanコマンドを使用する。

% empclean <DB> [temp]

tempを付けると/tmp配下のテンポラリファイル(EMP_*)も削除対象となる。

実行例)

% empclean testdb temp

EMPCLEAN バージョン 6.10 r1
         foo により開始 : 30 -2125980416  **:16:34
  次段階 : テンポラリファイルに対するディレクトリをチェックします。
Removing /tmp/EMP_15221_e1ba
Removing /tmp/EMP_4637_50d3
  データベースをチェック中です。: testdb
    次段階 : 必要なシェアードメモリを検索中です。
    次段階 : 不適切に終了したすべてのクライアントを発見しました。
ホストのチェック中です。: 'host-a'
foo       クライアント ID:       1115430533   PID:    15213
foo       クライアント ID:        841899680   PID:    38241
     次段階 : セマフォをチェックします。
     次段階 : トランザクションを解決します。
     次段階 : ダングリングサーバクライアントを削除します。
    次段階 : ロックを解除します。
クライアント 1115430533 に対してロックをクリアー中です。
クライアント 841899680 に対してロックをクリアー中です。
    次段階 : コーディネータをチェックします。
コーディネーターからクライアント 1115430533 を削除中です。
コーディネーターからクライアント 841899680 を削除中です。
EMPCLEAN 終了 : 30 Sep 2005  16:34:57

参考までに、empcleanが修復するEmpress DBの不整合について以下に示す。

消滅したサーバの再起動

何らかの原因によって消滅してしまったサーバを再起動する。

トランザクションの整合性

トランザクション中にサーバまたはクライアントが予期せぬ消滅をした場合、進行中のトランザクションはそのまま放置されるのでこれらのトランザクションのうち完了しているものについてはcommitを行い、未完了のものについてはrollbackを行う。

ロックの整合性

消滅したクライアントによる共有メモリとファイルロックはクリーンアップされないので不必要な共有メモリとロックはクリアする。

データディクショナリ

存在しないテーブルに関するデータディクショナリの登録を除去する。

また、データベースディレクトリ内に存在するデータベースファイルと無関係なファイルを削除する。

データベースファイル

メインレコードデータ(.relファイル)とオーバーフローデータ(.dtfファイル)を構成するファイルについてレコードカウンタの不整合やフリーリストの修復を行う。

テンポラリファイル

オプションtemp付で起動した場合に、クライアントが予期せぬ終了をした場合にそのクライアントが使用していたテンポラリファイルを削除する。

その他さまざまな目的で使用されるテンポラリファイルについてもそれぞれクリーンアップを行う。

2008/1/22更新

対応バージョン: 6.10

カラム数が多すぎるテーブルの定義は単純にexportファイルからimportできないので、以下の手順でimportする。

いったん既存のテーブルからテーブル定義をdumpしておく。

% empcmd <DB> "display <テーブル> dump into <ファイル>"

上記dumpファイルを利用してcreate tableを行う。

% empcmd <DB> "create table <テーブル> from <dumpファイル>"

参考までに通常のテーブル定義のimport方法も以下に示す。

% empimpt -d -gv <exportファイル> <DB> <テーブル>

関連資料・記事

2007/11/18更新

対応バージョン: 6.10

empexpt/empimptを使用する。

empexpt (Export)

empexptではテーブルの所有者情報を除いてテーブル構成や特権情報、テーブルに格納されたデータをファイルにexportできる。

テーブル名を指定しなければ指定したDBの全テーブルがexport対象となる。

% empexpt -hv <出力ファイル> <対象DB> [<対象テーブル> <対象テーブル> ...]
  EXPORT V6.10
  (c) Copyright Empress Software Inc. 1983, 1997
sys_attr_privs
sys_attrs
sys_dictionary
sys_privs
sys_tables

↑システムテーブル
↓ユーザ定義テーブル

table1
table2
table3
:

主なオプションは以下のとおり。

-h

empimptする際に画面に表示するための制御情報を出力ファイルに埋め込む。

empimpt以外では使用されない。

-v

冗長モード

-d

データをexportをしない。

データ以外の情報(テーブル定義、コメント、ロックレベル、インデックス、範囲チェック)をexportする場合に使用する。

empimpt (Import)

empimptではempexptによって作成されたDBデータのうち、「テーブル構成のみimport」「テーブル構成とデータはimportするが特権情報はimportしない」といったような指定により必要な情報を個別にimportできる。

import先の環境にてまずDBの外枠だけ作成する。

% empmkdb <対象DB>

次にempimptにてデータをimportする。

テーブルの所有者は元のテーブルの所有者ではなくempimptを実行したユーザになる。

% empimpt -gv <出力ファイル> <対象DB> [<対象テーブル> <対象テーブル> ...]
  IMPORT V6.10
  (c) Copyright Empress Software Inc. 1983, 1997

**  sys_attr_privs  **
    テーブル特権を授与中。...
    テーブル特権を授与中。...
    テーブルにロックレベルを設定中。...

**  sys_attrs  **
    テーブル特権を授与中。...
    テーブル特権を授与中。...
    テーブルにロックレベルを設定中。...
:
*** インポート終了 ***

主なオプションは以下のとおり。

-g

grant特権情報をimportする。

デフォルトではgrant特権はimportされない。

ただし、テーブル構成とデータはデフォルトでimportされる。

-v

冗長モード

-d

テーブル情報のみをimportし、データをimportしない。

デフォルトではデータもimportするようになっている。

-t

テーブルを作成しない。

テーブルがimportするデータベースに既に存在する場合に使用される。

デフォルトではテーブルは作成される。

そしてもしテーブルが既に存在する場合にはデータのみがimportされる。

-i

インデックスのimportを抑止する。

-k

参照整合性制約情報のimportを抑止する。

-l

ロックレベルのimportを抑止する。

-r

範囲チェック情報のimportを抑止する。

-h

入力中のテーブルに関する名前とレコード数を表示する。

viewは「VIEW」という名で示される。

このオプションが指定された場合はデータはimportされない。

本オプションを使用する場合はデータベース指定は必要ない。

2007/11/18更新

対応バージョン: 6.10

empsdump/empsldvを使用する。

デフォルトのセパレータは「^V ([Ctrl]+[v])」であるが、環境変数MSVALSEPでセパレータを変更できるので、例えばCSV形式で出力する場合は以下のようにする。

% setenv MSVALSEP ","
% empsdump <出力ファイル名> <DB名> <テーブル名>

参考までに、DBの全テーブルのunloadファイルを作成したい場合は以下のようなスクリプトを作っておくと便利である。

#!/bin/sh

if [ $# != 1 ]; then
  echo "usage: "`basename $0`" DB"
  exit
fi

MSVALSEP=","                         # セパレータ
export MSVALSEP

Sub=`date +"%Y%m%d%H%M%S"`

DB=$1
TableList=`empcmd ${HOME}/${DB} "display db" | grep -v '*'`

for Table in $TableList
do
  echo "unload : "${Table}
  empsdump ${Table}.csv.${Sub} ${HOME}/${DB} ${Table}
done

また、同様にCSVファイルからDBにデータを取り込むには以下のようにする。

% setenv MSVALSEP ","
% empsldv <入力ファイル名> <DB名> <テーブル名>

関連資料・記事

2007/11/4更新

対応バージョン: 6.10

empadmコマンドのcoordinfoオプションを使用する。

% empadm <DB> coordinfo
Database - <DB>
   
Header
  Max clients   Number of clients 
          128             8

On-line Backup Status    Recovery Log
  Inactive
  Recovery Log Version Number = 0

Process Information Blocks
  User Name  Client ID  Proc ID  Machine ID  Status
       xnet  841899680   38241   172.20.1.2  Inactive
       xnet  672716309   37853   172.20.1.4  Inactive
       xnet  177442907   37891   172.20.1.2  Inactive
       xnet  479605012   38004   172.20.1.2  Inactive

2008/3/9更新

対応バージョン: 6.10

EmpressではDBアクセス時に一時ファイルが作成されるが、デフォルトで/tmpが使われるので/tmpの容量が少ないと上記のエラーが発生する。

この一時ファイルの作成場所は環境変数MSTMPDIRで指定できるので、容量の大きい場所を指定すればよい。

関連資料・記事

2008/2/6更新

対応バージョン: 6.10

empmkdbコマンドでDBを作成しようとすると以下のようなエラーが出てDBが作成できない。

% empmkdb foo
*** User Error *** index 特権が、テーブル 'sys_dictionary' に対してありません
*** User Error *** index 特権が、テーブル 'sys_tables' に対してありません。
*** User Error *** index 特権が、テーブル 'sys_attrs' に対してありません。
*** User Error *** index 特権が、テーブル 'sys_privs' に対してありません。
*** User Error *** index 特権が、テーブル 'sys_attr_privs' に対してありません
*** User Error *** alter 特権が、テーブル 'sys_dictionary' に対してありません
*** User Error *** alter 特権が、テーブル 'sys_tables' に対してありません。
*** User Error *** alter 特権が、テーブル 'sys_attrs' に対してありません。
*** User Error *** alter 特権が、テーブル 'sys_privs' に対してありません。
*** User Error *** alter 特権が、テーブル 'sys_attr_privs' に対してありません

これは、empmkdbを実行するアカウントのアカウント名が8文字を超えていることが原因だが(Empressの制約)、以下の資料を参考にしてこの事象に対応可能である。

関連資料・記事

2007/11/4更新

対応バージョン: 6.10

Empressの制約によりDBを作成するアカウントのアカウント名は8文字以内である必要があるが、あらかじめ8文字以内に収まるアカウントを用意しておき、そのアカウントでいったんDBを作成した後にシステムテーブル中のアカウント情報を変更すればこの制限を回避することができる。

以下に手順を示す。

ここでは例として変更前/後のアカウントをそれぞれ「under8」(6文字)、「over8char」(9文字)として説明する。

1. under8アカウントでDBを作成する。

2. DB作成後、以下のようにDBの権限を変更する。これをDBの数分繰り返す。

% empcmd <DB> "update sys_tables set tab_creator='over8char'"

% empcmd <DB> "update sys_privs set priv_grantor='over8char' \
  where priv_grantor='under8'"

% empcmd <DB> "update sys_privs set priv_grantee='over8char' \
  where priv_grantee='under8'"

% empcmd <DB> "update sys_attr_privs set apriv_grantor='over8char' \
  where apriv_grantor='under8'"

% empcmd <DB> "update sys_attr_privs set apriv_grantee='over8char' \
  where apriv_grantee='under8'"

% vi <DB>/tabzero

(変更前)
MSDBADMINISTRATOR=under8

(変更後)
MSDBADMINISTRATOR=over8char

3. /etc/passwdを編集する等により、under8のアカウント名をover8charに変更する。

4. over8charアカウントで先程のDBの権限変更を有効にする。これをDBの数分繰り返す。

% empadm <DB> recompile_all

2007/11/4更新

対応バージョン: 6.10

以下の種類がある。

/XXXX.rel

データベース主部

/XXXXXXXX.dtf

データベース可変長あふれ部

/XXXXX.ix

インデックス主部

/XXXXX.ixl

インデックスあふれ部

msXXXXXXXX (環境変数MSTMPDIRで指定)

作業用一時ファイル

/_trn/XXXXX.trn

トランザクション情報ファイル

/_lock/XXXX.lck

ロック情報ファイル

/cdinator

コーディネータファイル

/tabzero

環境設定ファイル

/_trn/_keep_me

環境設定ファイル(トランザクション)

/_lock/_keep_me

環境設定ファイル(ロック)

2008/1/22更新

対応バージョン: 6.10

Empressのオンラインマニュアルは以下の2種類が用意されている。

主に管理用コマンド(emXXXX)のマニュアル(いわゆるmanファイル)

/usr/users/ms32/v6.10/man

6割程度が日本語で残りは英語。

SQL文等、開発に必要なドキュメント(テキスト)

/usr/users/ms32/v6.10/help/ja

2008/1/22更新

対応バージョン: 6.10

Empressの特性を決定する変数には「管理変数」と「システム変数」がある。

「管理変数」はファイルtabzeroの中に記述され、この中の設定だけが有効となる。

一方「システム変数」はサーバの設定ファイル~ms32/v6.10/custom/initfileに記述されシステム内で共有するが、いくつかの変数はユーザあるいはジョブ単位毎に変更できれば都合の良い場合もある。

この場合はUNIXの環境変数に設定したい値を定義する。

環境変数に定義がある場合はinitfileに記述された定義を上書きしてEmpressのプロセスに取り込む。

2007/12/15更新

対応バージョン: 6.10

以下のファイルをバックアップしておけばよい。

/usr/users/ms32/v6.10配下すべて
/usr/xnet/shlib/libms.so

関連資料・記事

2007/12/15更新

対応バージョン: 6.10

empversコマンドを使用する。

Patch Info欄に表示されている番号がパッチ番号である。

% empvers
Empress Version 6.10
(c) Copyright   Empress Software Inc.   1983, 1997
for ALPHA Station 255 running Digital UNIX 4.0D (single/multi processor)
 Port Code : RDBM-06.10-B-13-S-JPN
Patch Info.: 19
  Tape No. : DM-808
インストール先: /usr/users/ms32/v6.10

2007/11/4更新

対応バージョン: 6.10

準備

導入に必要なもの

製品CD-ROM

導入OS

Tru64 UNIX 5.0A

サーバ起動パラメータの定義

サーバ側の起動ファイルには以下のパラメータの設定が必要になる(設定値はデフォルト値)。

 1. EMPODBC_NETINTERFACE = 0
 2. EMPODBC_SERVICENAME  = empodbc
 3. EMPODBC_SERVICEPORT  = 6322
 4. EMPODBC_LISTENQLEN   = 5
 5. EMPODBC_WORKINGDIR   = <接続ユーザの$HOME>
 6. EMPODBC_LOGFILE      = /tmp/.EmpODBC-unix/server.log
 7. EMPODBC_ACCOUNTFILE  = /tmp/.EmpODBC-unix/account
 8. EMPODBC_PASSWDFILE   = /etc/passwd
 9. EMPODBC_CLIENTNUMLIM = <サーバへの同時アクセス上限数>
10. EMPODBC_RCVBUFSIZE   = 52000
11. EMPODBC_SNDBUFSIZE   = 52000
12. EMPODBC_IDLETIMELIM  = 720
13. EMPODBC_BLOCKTIMELIM = 60

各パラメータの意味は以下のとおり。

1. EMPODBC_NETINTERFACE

このパラメータはサーバがゲートウェイとして動作している場合にどのネットワークインタフェースを使用するかをIPアドレスで指定する。

全てのインタフェースを使用する場合はデフォルトの0のままでよい。

この場合はempodbcコマンド出力結果の「Interface IP」には「*」が出力される。

2. EMPODBC_SERVICENAME

3. EMPODBC_SERVICEPORT

両パラメータのどちらかにODBCサーバが使用するポートのサービス名/ポート番号を指定する。

両方指定した場合は後から指定した設定が優先される。

但しEMPODBC_SERVICENAMEがシステム定義(/etc/services等)に見つからなかった場合はEMPODBC_SERVICEPORTが使用される。

もし両方の定義に設定値がなかったりEMPODBC_SERVICENAMEが無効な設定値であった場合は、まずデフォルト値であるサービス名empodbcがシステムから検索され、サービス名がシステム定義にない場合にはポート番号のデフォルト値である6322が使用される。

4. EMPODBC_LISTENQLEN

このパラメータはクライアントからの接続数の上限を指定する。

クライアントからの接続数が既にこの値に達している場合は新たな接続要求は拒否される。

5. EMPODBC_WORKINGDIR

このパラメータはパスワードファイルにホームディレクトリの指定がない場合に相対パス指定時の現在ディレクトリを設定する。

クライアントからのデータベース指定が相対パスであった場合、ログインユーザのホームディレクトリからの相対パスでデータベースが検索されるか、あるいはログインユーザにホームディレクトリの設定がない場合はODBCサーバ起動時の本項のパラメータに設定されたディレクトリからの相対パスでデータベースが検索される。

6. EMPODBC_LOGFILE

サーバが出力するログファイルを指定する。

デフォルトの設定を使用した場合、ファイルはパイプとして使用され、サーバが終了すると消去される。

さらにパイプはサイズが制限される(サイズはシステムによって異なる)。

ログファイルを通常のファイルとして扱いたい場合はデフォルト設定以外のファイルを指定する。

この場合はサーバが終了してもファイルは削除されない。

7. EMPODBC_ACCOUNTFILE

このパラメータは現在使用されていない。

8. EMPODBC_PASSWDFILE

このパラメータは必ず設定しなければならない。

システムで用意されている/etc/passwdファイルを使用することもできるがshadowファイルなどによりパスワードが別ファイルに格納されている場合は/etc/passwdファイルが使用できない場合がある。

また、/etc/passwdにはODBC接続とは関係ないユーザの情報も格納されているので別途専用のパスワードファイルを用意することを推奨する。

専用のパスワードファイルを使用する場合、まず「empoadm adduser <パスワードファイル>」コマンドを使用してパスワードファイルを作成し、本パラメータでその絶対パスを指定する。

ところでODBC接続時に使用するパスワードファイルをUNIXデフォルトではなくEmpress側で作成して利用する目的はもう一つある。

/etc/passwdを使用する場合、UNIXサーバに対しODBC接続の為に新たなユーザを登録するか、あるいは登録されているユーザで接続しなければならない。

Empress ODBCサーバで使用するパスワードファイルをEmpressで作成したものにすることによって接続ユーザをUNIXに対しては架空ユーザ(実在しないユーザ)でアクセスする事が可能になる。

詳しくは後述の「ODBCにおけるセキュリティ」の項を参照のこと。

9. EMPODBC_CLIENTNUMLIM

このパラメータはサーバへ同時に接続するクライアント数の上限を指定する。

デフォルト値はEmpressのライセンス数で、ライセンス数以上、あるいは1未満の設定は無視される。

10. EMPODBC_RCVBUFSIZE

このパラメータは接続時の受信バッファサイズを指定する。

設定可能な値は4096〜52000(バイト)。

11. EMPODBC_SNDBUFSIZE

このパラメータは接続時の送信バッファサイズを指定する。

設定可能な値は4096〜52000(バイト)。

12. EMPODBC_IDLETIMELIM

このパラメータはクライアントからサーバに対して何もアクションが無い場合の待ち時間の長さを指定する。

その時間が過ぎてクライアントからのアクションが無い場合にはサーバのセッションは強制的にクローズされ、セッションに対応するサーバプロセスは終了する。

このような状態になった場合、クライアントはアプリケーションを一度終了して再起動(クライアントとしてセッションを終了して再度セッションを開始)しなければならない。

待ち時間を無限にする為には設定値をInfにすれば良いが、クライアントが電源断あるいはハングアップなどで異常終了した場合はその検知ができず、セッション中のサーバはデータベースに対してアクセス中の状態のままシステムリミット(7200秒 = 2時間)がくるまでシステムに常駐する事になるので注意が必要である。

13. EMPODBC_BLOCKTIMELIM

このパラメータはサービスセッションが内部の送受信状態をどの程度の間ブロックできるかを指定する。

この値は無制限にはできない。

尚、この値の変更には細心の注意が必要であり、ベンダのサポートなしでは変更しないほうがよい。

サーバコンフィグレーションファイルの指定

環境変数MSODBCSRVCFGFILEにサーバコンフィグレーションファイルの絶対パスを設定する。

例)

export MSODBCSRVCFGFILE=/usr/users/ms32/ODBC/odbc.conf

ODBC経由でアクセスするユーザの登録(パスワードファイルの作成)

empoadmコマンドでユーザを登録する。

% empoadm adduser <専用パスワードファイル>

作成ユーザの仕様を以下に示す。

登録ユーザはシステム(OS)上で登録されていてもいなくても構わない。

但し、システム運用におけるユーザ管理を考えればシステム上と同一にしておくほうが管理の煩雑さがなくなる利点はある。

ただ、外部からのログインを許してしまう可能性のある入り口を増やしてしまう欠点もあり検討が必要である。

登録ユーザのパスワードは登録ユーザ名がシステムのユーザ名と同一の場合でもシステムと同一のパスワードである必要はない。

ここで設定されるパスワードはODBC接続の為にだけ利用される。

ホームディレクトリの設定はシステム設定(/etc/passwd)と同一にする必要はない。

もし設定がある場合、前述のとおり相対パス指定時の現在ディレクトリがここで定義するホームディレクトリになる。

また、ホームディレクトリの設定がない場合はODBCサーバの設定ファイルのWORKINGDIRで指定したディレクトリがカレントディレクトリになる。

サーバ起動

上記の設定がすべて済んだらempodbcコマンドでサーバの起動が可能になる。

サーバの起動ユーザがデータベースへの実アクセスユーザになるので、後述の「ODBCにおけるセキュリティ」の項を参照して起動ユーザの検討、およびデータベースへの特権付与を設計しておく必要がある。

# empodbc

ODBCにおけるセキュリティ

UNIXシステム上でEmpressデータベースをアクセスする際のセキュリティについてはここでは説明しない。

本項ではUNIX上でのセキュリティ、Empress管理上でのセキュリティに関しての知識があるものとして説明する。

ODBC接続を使用し、クライアントからサーバにあるデータベースにアクセスする時はUNIX上での実行ユーザはODBCサーバを起動したユーザになる。

従って、アクセスする種別(参照か更新か)によりデータベースのファイルにODBC起動ユーザに対するUNIXファイルシステム上のアクセス権がなければならない。

逆に変更禁止でODBC接続を実現させる場合、UNIX上での権限を落としておくことにより書き込みに関するプロテクトが強化されることになる。

データベースに対するEmpress管理上のセキュリティは他のインタフェース(例えば対話型SQL)と同様のセキュリティがログインされるユーザ名によって保たれる。

つまりCREATOR、DBA、PUBLIC、ユーザ名に対してアクセス権限がそれぞれ限定(設定)できる(これらの権限に関してはgrantコマンドを参照されたい)。

補足

ODBCサーバの起動ユーザをrootにした場合、データベースの各ファイルに対してUNIX上のアクセス権の保護は皆無に等しい事になる。

UNIX上におけるセキュリティはなくなり、Empress管理上のセキュリティのみになる。

従って、ODBCサーバ立ち上げユーザはroot以外のユーザである方が好ましいことになる。

例として、データベースのファイルにリードオンリーのファイルアクセス権を付与している場合を考える。

この場合、一般ユーザであれば書き込み権が無い場合はファイルアクセス時にエラーになり更新系の処理は一切できない。

しかしrootがアクセスした場合、例えリードオンリーの権限が付与されていたとしてもそれら権限を一切無視して書き込みが行われてしまう。