Sybase

2007/9/28更新

対応バージョン: 11.9.2

以下の手順でトランザクションログ領域を拡張する。

拡張用デバイス(物理ファイル、及び論理デバイス)を作成する。

まず、デバイスに割り当てるデバイス番号を調べる。

1> use master ← デバイス定義はmasterデータベース上に作成
2> go

1> select distinct low/16777216 from sysdevices order by low
2> go
 -----------
           0
           1
           :
          25
          26

上記の例では26までのデバイス番号が使用されているので27以降が使用可能である。

次に物理ファイルを作成し、それを論理デバイスに割り当てる。

1> disk init
2> name = "logdisk_02", ← デバイスの論理名
3> physname = "/db/logdisk_02.dat", ← デバイスの物理ファイル名
4> vdevno = 27, ← デバイス番号
5> size = 256000 ← サイズをページ(2KB/ページ)単位で指定
                    (*) この例では256000 * 2KB = 500MBを指定
6> go

1> sp_helpdevice logdisk_02
2> go
 device_name physical_name      description                    ...
 ----------- ------------------ ------------------------------ ...
 logdisk_02  /db/logdisk_02.dat special,physical disk,500.00MB ...

上記で作成したデバイスをログ領域に追加する。

ここでは作成デバイスのうち500MB(つまり全容量)をログ領域として追加する。

1> alter database <DB> log on logdisk_02 = 500
2> go

ログ領域が追加されたことを確認する。

1> sp_helpdb testdb
2> go
 name   db_size  owner dbid created      status
 ------ -------- ----- ---- ------------ -----------------------------
 testdb 2000.0MB sa       2 Mar 06, 2002 select into/bulkcopy/pllsort
        (1)

 device_fragments size      usage     free kbytes
 ---------------- --------- --------- -----------
 datadisk_01      1000.0 MB data only      612032
 logdisk_01        500.0 MB log only        11984
 logdisk_02        500.0 MB log only       512000 ← (2)

(1) 全体が2GBに増えた(この場合、元は1.5GB)

(2) 500MBの領域がログ領域(log only)に追加された

masterデータベースバックアップ

DB構成の変更情報はmasterデータベースに格納されるためバックアップしておいたほうがよい。

1> dump database master to "/var/tmp/master.dmp"
2> go

2007/9/28更新

対応バージョン: 11.9.2

以下の手順でトランザクションログを削除する。

現在のトランザクションログの使用状況を確認する。

1> use <DB>
2> go

1> sp_spaceused syslogs
2> go
 name    rowtotal   reserved data    index_size unused
 ------- ---------- -------- ------- ---------- ----------
 syslogs Not avail. 95904KB  95904KB 0KB        Not avail.

上記の例では96MB(reservedカラム)使用している。

この情報だけではあとどのくらい使用できるのか分からないので、さらに以下のSPを実行する。

1> sp_helpsegment logsegment
2> go
 segment name       status
 ------- ---------- ------
       2 logsegment      0

 device     size        free_pages
 ---------- ----------- ----------
 logdisk_01 100.0MB           3248

 table_name index_name  indid
 ---------- ----------- -----
 syslogs    syslogs         0

 total_size total_pages free_pages used_pages
 ---------- ----------- ---------- ----------
 100.0MB          51200       3248      47952
     (1)                       (3)        (2)

(1) 全体で100MBの領域があり、

(2) 現在96MB(47952ページ x 2KB/ページ)使用しているので、

(3) 使用可能領域が6.4MB(3248ページ x 2KB/ページ)残っている。

不要なトランザクションログを削除する。

1> dump transaction <DB> with truncate_only
2> go

(*) truncate_onlyオプションを使用した場合この操作そのものに対するトランザクションログも生成されるので、本当にログがいっぱいで上記コマンドが実行できない場合は以下のno_logオプションを使用する。

1> dump transaction <DB> with no_log
2> go

ログ領域が開放されたことを確認する。

1> sp_helpsegment logsegment
2> go
 segment name       status
 ------- ---------- ------
       2 logsegment      0

 device     size        free_pages
 ---------- ----------- ----------
 logdisk_01 100.0MB           3248

 table_name index_name  indid
 ---------- ----------- -----
 syslogs    syslogs         0

 total_size total_pages free_pages used_pages
 ---------- ----------- ---------- ----------
 100.0MB          51200      51192          8
                             (2)          (1)

(1) 使用領域が16KB(8ページ x 2KB/ページ)に減ったので、

(2) 使用可能領域が1023MB(51192ページ x 2KB/ページ)に増えた。

2007/8/25更新

対応バージョン: 11.9.2

ひとつのストアドプロシージャ内で同時に使えるテーブルは最大16であり、これは設定では変えられない。

プロシージャの構成を見直して以下のような対応が必要である。

テーブル数を減らす
プロシージャを複数に分割する

2008/5/2更新

対応バージョン: 11.9.2

sp_helptextを使用する。

1> sp_helptext <SP>
2> go
 # Lines of <SP>
 ---------------
               1
 <SP>
 -----------------------------------
 create procedure <SP> as ...
 :

通常のSPはユーザデータベース内に格納されているが、sp_whoなどのシステムプロシージャはsybsystemprocsデータベースに格納されている。

SPの一覧は以下のようにして得ることができる。

1> select name,crdate from sysobjects where type = 'P'
2> go
 name                  crdate
 --------------------- ------------------- 
 sp_unbindmsg          May 27 2002 12:46PM
 sp_altermessage       May 27 2002 12:46PM
:

またシステムプロシージャの定義文は以下のファイルに保存され、Sybaseインストール時に実行される。

$SYBASE/scripts/installmaster

2007/8/25更新

対応バージョン: 11.9.2

ストアドプロシージャ名にはマルチバイト文字を使用するかどうかに関係なくサイズの制限がある。

尚、この制約はデータベースの種類によって異なり、これ以上のサイズの名前をつけようとするとエラー103が発生する。

一般のデータベース

30バイト

tempdb

13バイト

2007/10/6更新

対応バージョン: 11.9.2

Adaptive Serverのセキュリティはサーバアクセス、データベースアクセス、データアクセスの3層に分かれたシステムに基づいている。

サーバアクセス用アカウント作成

サーバに接続するにはサーバに「ログイン」する必要があるので、まず該当サーバに対してログイン用のアカウントを作成する。

ここで注意したい点として、Adaptive Serverにログインしたからといってデータベースにアクセスできるわけではないということである。

作成したアカウントは単にAdaptive Serverに接続することができるようになっただけなので、データベースにアクセスするためにはさらに後述のデータベースアクセス用アカウントを登録する必要がある。

サーバアクセス用アカウントを作成するにはsp_addloginを実行する。

sp_addloginの構文は以下のとおりである。

sp_addlogin <アカウント名>, <パスワード>
  [, <該当アカウントのデフォルトデータベース>]
  [, <デフォルト言語> [, <アカウントのフルネーム>]]]

デフォルトデータベースとはAdaptive Serverに接続した際にデフォルトで選択するデータベースである。

デフォルトデータベースを指定しない場合は暗黙のうちにmasterデータベースが指定される。

例) fooアカウントを作成し、デフォルトデータベースをdb1に設定する

1> sp_addlogin foo,<パスワード>,db1
2> go
Password correctly set.
Account unlocked.
New login created.

作成したアカウント情報はmaster..sysloginsテーブルに格納される。

格納された情報を確認するにはsp_displayloginを使用する。

sp_displayloginの構文は以下のとおりである。

sp_displaylogin [アカウント名]

アカウント名を省略すると自分自身のアカウント情報が表示される。

例)

1> sp_displaylogin foo
 Suid: 5         
 Loginame: foo
 Fullname: 
 Default Database: db1
 Default Language: 
 Configured Authorization:
 Locked: NO                            
 Date of Last Password Change: Mar  6 2002  9:36PM 

データベースアクセス用グループ作成

システム管理者とデータベース所有者は個々のアカウントのほかにデータベースアカウントの「グループ」を作成できる。

グループはグループ名で識別され、複数のアカウントに対するパーミッションの付与や取り消しを1文で行うことができる。

例えば「managers」「payroll」といったグループを定義し、そのグループにアカウントを割り当てればそのグループ全体に権限を割り当てるだけでグループの全アカウントに対して同じ権限を割り当てることができる。

また、全てのデータベースアカウントが所属するシステム定義グループ「all」もある。

グループの作成にはsp_addgroupを使用する。

sp_addgroupの構文は以下のとおりである。

sp_addgroup グループ名

例)

1> use db1
2> go

1> sp_addgroup admin
2> go
New group added.

登録した情報は該当データベースのsysusersテーブルに格納される。

格納された情報を確認するにはsp_helpgroupを実行する。

sp_helpgroupの構文は以下のとおりである。

sp_helpgroup [グループ名]

グループ名を省略すると現在のデータベースの全てグループが表示される。

例)

1> sp_helpgroup
2> go
 Group_name Group_id 
 ---------- -------- 
 admin         16390 
 public            0 

データベースアクセス用アカウント登録

次にユーザがデータベースに接続できるようにするために、対象となるデータベースに対してsp_adduserを実行してアカウントを登録する。

sp_adduserの構文は以下のとおりである。

sp_adduser <アカウント名> [,<新しいアカウント名(Alias)> [, <所属グループ名>]]

新しいアカウント名(Alias)を付けずにログインアカウント名をそのままアカウント名として使用したい場合は第2引数に「null」を指定する。

所属グループ名を省略すると暗黙のうちにpublicグループが指定される。

所属グループ名を指定すると、所属グループは指定したグループ、及びpublicになる。

例)

1> use db1
2> go

1> sp_adduser foo,null,admin
2> go
New user added.

登録したアカウント情報は該当データベースのsysusersテーブルに格納される。

格納された情報を確認するにはsp_helpuserを使用する。

sp_helpuserの構文は以下のとおりである。

sp_helpuser [現在のデータベース内のアカウント名]

アカウント名を省略すると現在のデータベース内の全てのアカウント情報を表示する。

例)

1> sp_helpuser
2> go
 Users_name ID_in_db Group_name Login_name        
 ---------- -------- ---------- ---------- 
 dbo               1 public     sa                
 foo               3 admin      foo            

また、所属グループの状態を見ると該当アカウントが登録されているのが確認できる。

例)

1> sp_helpgroup admin
2> go
 Group_name Group_id Users_in_group Userid 
 ---------- -------- -------------- ------ 
 admin         16390 foo                 3 

データアクセス用パーミッション設定

ログインとアカウント名があれば個別にサーバやデータベースにアクセスできるが、テーブルやビューのデータの選択、テーブルのデータの修正、ストアドプロシージャの実行に対するパーミッションは自動的に与えられない。

データベースオブジェクトへのアクセスパーミッションをユーザに与えるにはシステム管理者またはデータベース所有者がユーザかユーザの所属するグループに対してオブジェクトへのアクセスパーミッションを明示的に付与する必要がある。

逆に、saユーザは全てのデータベースに対して無制限のアクセス権限を持つので適切なパーミッションをユーザに与えた後は使用不能(ロック)にしたほうがよい。

付与すべきパーミッションには以下のようなものがある。

sa_role

システム管理者

sso_role

セキュリティ担当者

oper_role

オペレータ

これらパーミッションをgrant roleにて適切なアカウントに付加する。

パーミッションを剥奪する場合はrevoke roleを使用する。

grant role、revoke roleの構文は以下のとおりである。

grant role <role名> to <アカウント>

revoke role <role名> from <アカウント>

2007/9/28更新

対応バージョン: 11.9.2

何らかの原因でバックアップサーバが停止している。

例えば以下のような場合が考えられる。

意図的にバックアップサーバを停止した。
リストア作業を中断した場合にバックアップサーバが停止してしまった。

対応としてはバックアップサーバを起動すればよいが、事前に前回停止時に以下の不要プロセスが残っていないか確認し、まだ動作していたら終了しておく。

バックアップサーバに接続したままのisqlや各種クライアントアプリ
リストア処理を行っていたサーバプロセスsybmultbuf

2008/1/5更新

対応バージョン: 11.9.2

UNION ALL対象のデータは全て同じ内容のデータを抽出する必要がある。

例えば以下のSQLの場合、2つめのSELECTの抽出結果に「c」が足りないので同エラーとなる。

SELECT a,b,c FROM t1

UNION ALL

SELECT a,b FROM t2

UNION ALL

SELECT a,b,c FROM t3

2007/10/6更新

対応バージョン: 11.9.2

既に同名のテーブルが存在する。

テーブルに限らず、SPやViewなどのオブジェクトについても同様である。

2007/10/6更新

対応バージョン: 11.9.2

対象となるテーブルが存在しない。

テーブルに限らず、SPやトリガなどのオブジェクトについても存在しないものをdropしようとするとこのエラーが出る。

また、該当のオブジェクトが存在しているにもかかわらずこのエラーが出る場合は、このオブジェクトについてシステムテーブルが不整合を起こしている可能性があるのでベンダサポートに問い合わせる。

2007/10/6更新

対応バージョン: 11.9.2

当該データベースにselect intoの権限がない。

sp_dboptionにて「select into/bulkcopy」を付与する(checkpointの実行を忘れずに)。

1> sp_dboption <DB>, "select into/bulkcopy/pllsort", true
2> go

1> use <DB>
2> go

1> checkpoint
2> go

尚、一時表や一部のストアドプロシージャ(sp_helpやsp_helpsortなど)はtempdbにselect intoするのでtempdbに同様のオプションを付与する必要がある。

2007/8/25更新

対応バージョン: 11.9.2

サーバの設定ファイル$SYBASE/<サーバ>.cfg中の「enable unicode conversions」パラメータを1に変更する。

2008/1/19更新

対応バージョン: 11.9.2

2つの日付の差分を計算するにはdatediff関数を使用する。

select datediff(<計算単位>, <日付1>, <日付2>)
<計算単位>に「year」(年)、「month」(月)などを指定すると、2つの日付の差分がその単位で取得できる。

例えば当資料作成日(2008/1/19)と2007/1/1の差分を取得するには以下のようなクエリを実行する。

declare @date1 datetime
declare @date2 datetime

select @date1 = '2007/01/01'
select @date2 = '2008/01/19'

select datediff(year, @date1, @date2) Year,
       datediff(month,@date1, @date2) Month,
       datediff(week, @date1, @date2) Week,
       datediff(day,  @date1, @date2) Day
go

=> Year  Month Week  Day         
=> ----- ----- ----- ----- 
=>     1    12    54   383 

その他に指定できる計算単位については以下を参照のこと。

関連資料・記事

2008/4/15更新

対応バージョン: 11.9.2

指定した日数を日付に加算するにはdateaddを使用する。

select dateadd(<日付要素>, <加算単位>, <日付>)
<日付要素>に「day」(日)、「month」(月)などを指定すると、その単位で日付の加算ができる。

例えば2008/4/15の1年後、1ヶ月後、1週間後、1日後の日付をそれぞれ求めるには以下のようなクエリを実行する。

declare @date1 datetime

select @date1 = '2008/4/15'

select dateadd(year, 1, @date1) Year
select dateadd(month,1, @date1) Month
select dateadd(week, 1, @date1) Week
select dateadd(day,  1, @date1) Day

go

=> Year                       
=> -------------------------- 
=>        Apr 15 2009 12:00AM 

=> Month                      
=> -------------------------- 
=>        May 15 2008 12:00AM 

=> Week                       
=> -------------------------- 
=>        Apr 22 2008 12:00AM 

=> Day                        
=> -------------------------- 
=>        Apr 16 2008 12:00AM 

その他に指定できる計算単位については以下を参照のこと。

関連資料・記事

2007/9/28更新

対応バージョン: 11.9.2

datepart関数を使用すると日付データから「年」「月」「日」といった任意の一部を取り出すことができる。

datepart(<取得要素>, <対象カラム>)

取得要素には以下のようなものがある(括弧内は省略形)。

year(yy)

1753 - 9999

(*) smalldatetimeの場合は1753 - 2079

quarter(qq) ... 四半期

1 - 4

month(mm)

1 - 12

week(wk)

1 - 54

day(dd)

1 - 31

dayofyear(dy) ... 当年中の通算日

1 - 366

weekday(dw)

1 - 7

(*) 1:日、7:土

hour(hh)

0 - 23

minute(mi)

0 - 59

second(ss)

0 - 59

millisecond(ms)

0 - 999

calweekofyear(cwk) ... 当年中の通算週

1-53

calyearofweek(cyr) ... その週が始まる年

1753 - 9999

caldayofweek(cdw) ... 当週中の曜日

1 - 7

例) 日付が「2007/6/30」の場合

1> select datepart(year, <日付カラム>) from <テーブル> ← 年
2> go

2007

1> select datepart(month, <日付カラム>) from <テーブル> ← 月
2> go

6

1> select datepart(day, <日付カラム>) from <テーブル> ← 日
2> go

30

関連資料・記事

2007/12/8更新

対応バージョン: 11.9.2

まだ存在しないテーブルに対してはselect intoを使用すればよいが、既存のテーブルにselect intoを実行すると以下のようなエラーになる。

1> select * into test_new from test_org
2> go
Msg 2714, Level 16, State 1:
Line 1:
There is already an object named 'test_new' in the database.

そこで、以下のようにして既存のテーブルにデータを挿入する。

1> insert into test_new select * from test_org
2> go

2007/12/8更新

対応バージョン: 11.9.2

システム情報を取得する組み込み関数(いわゆるシステム関数)には様々なものがあるが、ここではその一部を紹介する。

現在日時

1> select getdate()
2> go

 Dec 07 2007  7:54PM

現在DB、あるいは指定したDBのID

1> select db_id()
2> go

 14

1> select db_id("testdb")
2> go

 20

現在DB、あるいは指定したDBの名前

1> select db_name()
2> go

 foodb

1> select db_name("20")
2> go

 testdb

現在ホスト

1> select host_name()
2> go

 host_a

現在プロセスのPID

1> select host_id()
2> go

 15122

現在ユーザの名前

1> select user
2> go

 dbo

現在ユーザ、あるいは指定したユーザのID

1> select user_id()
2> go

 1

1> select user_id("foo")
2> go

 3

現在ユーザ、あるいは指定したユーザの名前

1> select user_name()
2> go

 dbo

1> select user_name(3)
2> go

 foo

現在ユーザの有効ロール(役割)

1> select show_role()
2> go

 sa_role sso_role oper_role replication_role

2007/9/11更新

対応バージョン: 11.9.2

同バージョンのSybaseではUnicode2.1をサポートする。

Unicode3.0はバージョン12.5以降でサポートする。

2007/8/25更新

対応バージョン: 11.9.2

利用状況によるライセンス

Adaptive Serverには「Base(基本)ライセンス」と「Cold Standbyライセンス」の2種類がある。

両者とも機能的には差異がないが、Cold Standbyライセンスは障害発生時にしか利用できないので価格が安くなっている。

尚、Cold Standby用のメディアは存在せずBaseライセンスのメディアを使用する。

アクセス状況によるライセンス

さらにこれらのライセンスはLAN内等で使用する「同時利用ユーザライセンス」とインターネットからの不特定多数のアクセスを想定した「Internet Accessライセンス」に分かれる。

同時利用ユーザライセンスには10ユーザ分、100ユーザ分といったライセンスパックは存在せず必要なユーザ数分のライセンスを購入する。

逆にInternet AccessライセンスはCPU毎の課金となる。

2007/9/28更新

対応バージョン: 11.9.2

sysprocesses、sysloginsシステムテーブルを以下のように参照することによって、Sybase内部で動作しているプロセスがどのOS上のプロセスと結び付いているか調べることができる。

1> select A.spid,A.status,A.suid,B.name,A.hostname,A.program_name,
2> A.hostprocess,A.cmd
3> from master..sysprocesses A, master..syslogins B
4> where A.suid = B.suid
5> go

 spid status  suid name   hostname program_name hostprocess cmd
 ---- ------- ---- ------ -------- ------------ ----------- ------
   16 running    1 sybase hostA    isql               15146 SELECT
spid

DBエンジン上のPID

status

状態(running,sleep等)

suid

実行ユーザのUID

name ... sysloginsテーブルより取得

実行ユーザ

hostname

実行ホスト

program_name

OS上の実行プログラム(isql等)

hostprocess

OS上のPID

cmd

DBエンジン上のコマンド(SELECT,UPDATE等)

2007/9/11更新

対応バージョン: 11.9.2

Adaptive Serverによって実行されているプロセスは通常のUNIXプロセスと同じくユニークなプロセスIDが割り当てられる。

これらのID番号および各プロセスについてのその他の情報は、master..sysprocessesに保管される。

sp_whoにてこれらの情報のほとんどを参照することができる。

1> sp_who
2> go
 fid spid status     loginame origname hostname blk dbname cmd              
 --- ---- ---------- -------- -------- -------- --- ------ ---------------- 
   0    1 running    sa       sa       hostA      0 master SELECT           
   0    2 sleeping   NULL     NULL                0 master NETWORK HANDLER  
   0    3 sleeping   NULL     NULL                0 master DEADLOCK TUNE    
   0    4 sleeping   NULL     NULL                0 master MIRROR HANDLER   
   0    5 sleeping   NULL     NULL                0 master CHECKPOINT SLEEP 
   0    6 sleeping   NULL     NULL                0 master HOUSEKEEPER      
   0    7 recv sleep user_1   user_1   hostB      0 db1    AWAITING COMMAND 
   0    8 recv sleep user_2   user_2   hostC      0 db2    AWAITING COMMAND 
   :

シングルエンジンのサーバ上でsp_whoを実行すると「実行中の」sp_whoプロセスおよび他の全ての「実行可能」またはスリープ状態にあるプロセスを確認できる。

マルチエンジンのサーバではエンジンごとに「実行中の」プロセスが存在する。

実行中のプロセスを強制終了するにはkillを使用する。

1> kill <spid>
2> go

プロセスを強制終了する必要がある状況としては、例えばプロセスが暴走している時やロックを確保したままでプロセスがハングアップしている時などである。

また、データベース接続を多数保持したままスリープしていて他のプロセスが新たに接続できなくなっている場合などもある。

システム管理者は次のようなプロセスを強制終了できる。

システムプロセスでないプロセス(*)
waitforコマンドなどでアラームを待っているプロセス
ネットワークの送信または受信を待っているプロセス
ロックを待っているプロセス
ファミリ内の他のプロセスからの同期メッセージを待っているプロセス
ほとんどの実行中または「実行可能な」プロセス

(*) 前述のsp_whoの結果の例でいうと、spid 2〜6のプロセスは強制終了できない。これらはログイン名がNULLであることとホスト名がないことからシステムプロセスであることがわかる。

Adaptive Serverでは終了していない全てのトランザクションを正常にロールバックしてプロセスが使用している全てのシステムリソースを解放できる場合にかぎりプロセスの強制終了を実行できる。

ファミリの一部であるプロセスではファミリ内の全てのプロセスを同時に強制終了する必要がある。

sp_whoで確認できるプロセスの状態と、各状態においてkillコマンドを実行した時の挙動を以下に示す。

recv sleep

状態

ネットワークの読み取り待ち

killコマンドの効果

即時

send sleep

状態

ネットワークの送信待ち

killコマンドの効果

即時

alarm sleep

状態

「waitfor delay "10:00"」などのアラーム待ち

killコマンドの効果

即時

lock sleep

状態

ロックの取得待ち

killコマンドの効果

即時

sync sleep

状態

ファミリ内の他のプロセスからの同期メッセージ待ち

killコマンドの効果

即時。ファミリ内の他のプロセスも強制終了可能な状態にする

sleeping

状態

ディスクI/Oまたはその他のリソース待ち

killコマンドの効果

通常「ウェイクアップ」すると直ちに強制終了される。スリープしているいくつかのプロセスはウェイクアップせず、クリアするためにサーバをリブートする

runnable

状態

実行可能なプロセスのキュー内にある。

killコマンドの効果

即時

running

状態

サーバエンジンの1つでアクティブに実行されている。

killコマンドの効果

即時

infected

状態

サーバが重大なエラー状態を検出した。この状態はめったに発生しない。

killコマンドの効果

killコマンドは使用しないほうがよい。プロセスをクリアするためにサーバをリブートしなければならない可能性が高い

background

状態

ユーザプロセスではなくAdaptive Serverによって実行されるスレッショルドプロシージャのようなプロセス

killコマンドの効果

即時。細心の注意を払ってkillコマンドを実行する。慎重にsysprocessesをチェックしてからバックグラウンドプロセスを強制終了することをすすめる

log suspend

状態

プロセスがログのラストチャンススレッショルドに到達して中断された

killコマンドの効果

即時

2008/3/6更新

対応バージョン: 11.9.2

サーバ設定ファイル(.cfg)の「total memory」パラメータの値を増やしてデータベースサーバを起動しようとするとメモリ割当不足で起動できない。

ログファイルには以下のようなエラーが出力されている。

os_create_region: can't allocate XXXXX bytes
kbcreate: couldn't create kernel region.
kistartup: could not create shared memory

対処としては「total memory」パラメータの値を減らしてデータベースサーバに割り当てるメモリを減らすか、物理メモリを増設する。

2007/8/25更新

対応バージョン: 11.9.2

interfacesファイルで指定したListener用のポートを別のデータベースサーバが使用している可能性がある。

ポート番号はinterfacesファイル中に記述されている(以下の0x00021004...の「1004」の部分)。

<データベースサーバ名>
  master tli tcp /dev/tcp \x00021004c0a81e180000000000000000
  query tli tcp /dev/tcp \x00021004c0a81e180000000000000000

Adaptive ServerとBackup Serverのデフォルトのポートはそれぞれ4100(0x1004)、4200(0x1068)なので、他のサーバとポートが競合していないか確認し、競合していた場合は一意のポート番号に変更する。

尚、interfacesファイルの編集には専用のGUIツール「dsedit」が利用できるのでこれを使用してもよい。

2008/1/19更新

対応バージョン: jConnect-JDBC-4.2

IsqlApp.classが存在するディレクトリがCLASSPATH環境変数に含まれていない。

関連資料・記事

2007/11/16更新

対応バージョン: jConnect-JDBC-4.2

サーバ側にjConnect用テーブル/SPがインストールされていない。

関連資料・記事

2007/11/16更新

対応バージョン: jConnect-JDBC-4.2

サーバ側にjConnect用テーブル/SPがインストールされていない。

関連資料・記事

2007/11/2更新

対応バージョン: jConnect-JDBC-4.2

接続先のホスト名が解決できないため、通信ができない。

関連資料・記事

2007/11/2更新

対応バージョン: jConnect-JDBC-4.2

サーバ側でASEが起動していない。あるいは接続ポートが誤っている。

関連資料・記事

2007/11/2更新

対応バージョン: jConnect-JDBC-4.2

IsqlAppを使用する。

構文は以下のとおりである。

java IsqlApp -U<user> -P<pass> -S jdbc:sybase:Tds:<ホスト>:<ポート>[/<DB>]

(*) <ポート>はサーバのinterfacesファイルのqueryエントリで指定されているポート番

例) = sa、 = saadmin、<ホスト> = serv、<ポート> = 5100の場合

% java IsqlApp -Usa -Psaadmin -S jdbc:sybase:Tds:serv:5100

Enter a query:
1 > ← 接続OK

2007/9/11更新

対応バージョン: 11.9.2

ヘッダを出力しない方法

-bオプションを付けてisqlを起動する。

例)

% isql -U<user> -P<pass> -b
1> select * from job_master
2> go
01 高校生
02 大学生                        
03 専門学生                     
04 会社員
05 自営業
06 公務員
07 フリーター
08 主婦                         
09 その他
(9 rows affected)

レコード数を出力しない方法

SQL文の前にset nocount onを指定する。

例)

% isql -U<user> -P<pass>
1> set nocount on
2> select * from job_master
3> go
no type
-- ------------
01 高校生                       
02 大学生
03 専門学生                     
04 会社員
05 自営業
06 公務員
07 フリーター
08 主婦
09 その他

2007/9/11更新

対応バージョン: 11.9.2

isqlでselect文等のSQLコマンドを実行する場合通常は

% isql -U<user> -P<pass> -S<server>
1> select * from xxxxx
2> go  

のように専用のプロンプト上でコマンドを入力していくが、これだと毎回同じようなコマンドを入力する場合に面倒なので

% isql -U<user> -P<pass> -S<server> -i<file>

とすることでこのコマンドを中に書いておいてバッチ処理的に一度に実行することができる。

コマンドの実行結果は標準出力に出力されるのでリダイレクトを使って結果をファイルに保存したりパイプを使って他のコマンドの入力にしたりできる。

2007/10/6更新

対応バージョン: 11.9.2

sysdevicesシステムテーブルを参照する。

1> use master
2> go

1> select name,phyname from sysdevices
2> go
 name         phyname                                                
 ------------ -------------------------------
 master       d_master                                               
 sysprocsdev  /opt/DB/systemprocs.dat                                
 tapedump1    /dev/rmt4                                              
 tapedump2    /dev/rst0               

2007/9/28更新

対応バージョン: 11.9.2

トリガはデータベースオブジェクトとしてsysobjectsテーブルに格納されている。

sysobjectsテーブルのtypeカラムが"TR"となっているものがトリガである。

1> select * from sysobjects where type = "TR"
2> go
 name  id    uid type ...
 ----- ----- --- ---- ...
 trig1 63433   1 TR   ...
 :

各トリガのソースはsyscommentsに格納されている。

1> select * from syscomments
2> go
 id    number colid texttype language text                   colid2 status  
 ----- ------ ----- -------- -------- ---------------------- ------ ------
 63433      0     1        0        0 create trigger trig1        0 NULL
                                      on test
                                      for delete
                                      as
                                      begin
                                        rollback transaction
                                        print "can't delete record"
                                      end
 :

トリガのソースのみを表示したい場合はsp_helptextを使用する。

sp_helptext <トリガ>

sp_helpを使用するとトリガについてのレポートを取得できる。

1> sp_help delixderdef
2> go
 Name   Owner  Type
 ------ ------ ---------
 trig1  dbo    trigger

 Data_located_on_segment When_created
 ----------------------- -------------------
 not applicable          Mar 17 2000  9:22AM

テーブルに関連付けられているトリガの一覧を表示するにはchecktrigを使用する。

1> checktrig <テーブル>
2> go
 Trigger_name Owner
 ------------ ----- 
 trig1        dbo
 trig2        dbo
 trig3        dbo

また、逆にトリガに関連付けられているオブジェクトを表示するにはsp_dependsを使用する。

1> sp_depends <トリガ>
2> go
 Things the object references in the current database.
 object      type             updated selected
 ----------- ---------------- ------- ----------
 dbo.test    user table       no      no
 dbo.test2   user table       no      no
 dbo.sp_test stored procedure no      no

2007/9/28更新

対応バージョン: 11.9.2

sp_helpconstraintを使用する。

例) 外部キーとプライマリキーが定義されているtestというテーブルの場合

1> sp_helpconstraint test
 name      definition
 --------- ---------------------------------------------------------------
 test_fk1  test_info FOREIGN KEY (userid) REFERENCES test_org_info(userid)
 test_pk   PRIMARY KEY INDEX (userid) : CLUSTERED, FOREIGN REFERENCE

Total Number of Referential Constraints: 1

Details:
-- Number of references made by this table: 0
-- Number of references to this table: 1
-- Number of self references to this table: 0

Formula for Calculation:
Total Number of Referential Constraints
= Number of references made by this table
+ Number of references made to this table
- Number of self references within this table

2007/9/11更新

対応バージョン: 11.9.2

Sybaseではテーブル/View/トリガ/ストアドプロシージャなどはすべて「オブジェクト」として扱われており、テーブルやViewなどはオブジェクトの種別として区分けされる。

これらオブジェクトの一覧を参照するにはsp_helpを使用するか、sysobjectsテーブルを検索する。

sp_helpを使用する場合

引数なしで全てのオブジェクトが出力される。

1> sp_help
2> go
 Name                  Owner Object_type
 --------------------- ----- -----------
 spt_datatype_info     dbo   user table
 spt_datatype_info_ext dbo   user table
 :

引数にオブジェクト名を指定するとそのオブジェクトの詳細が出力される。

1> sp_help spt_datatype_info
2> go
 Name              Owner Type
 ----------------- ----- ----------
 spt_datatype_info dbo   user table

 Data_located_on_segment When_created               
 ----------------------- ------------------- 
 default                 May 27 2002 12:46PM 

 Column_name Type     Length Prec Scale Nulls Default_name Rule_name Identity
 ----------- -------  ------ ---- ----- ----- ------------ --------- --------
 ss_dtype    tinyint       1 NULL NULL      0 NULL         NULL             0 
 type_name   varchar      32 NULL NULL      0 NULL         NULL             0 
 data_type   smallint      2 NULL NULL      0 NULL         NULL             0 
 :

sysobjectsテーブルを検索する場合

1> select name,type from sysobjects
2> go
 name                           type
 ------------------------------ ----
 sysobjects                     S
 sysindexes                     S
 :
 sylimviolmargin_fk1            RI
 delfxblt_theta                 TR
 :

typeフィールドで検索対象を絞ることで種類別のオブジェクトが検索できる。

typeに指定できるオブジェクトタイプは以下の通り。

D

デフォルト

L

ログ

P

プロシージャ

PR

準備オブジェクト(動的SQLにより作成)

R

ルール

RI

参照制約

S

システムテーブル

TR

トリガ

U

ユーザテーブル

V

ビュー

XP

拡張ストアドプロシージャ

2007/9/11更新

対応バージョン: 11.9.2

sp_monitorconfigを使用する。

1> sp_monitorconfig "number of open indexes"
2> go

 Name                   # Free # Active % Active # Max Ever Used Re-used
 ---------------------- ------ -------- -------- --------------- -------
 number of open indexes 55758  4242     7.07     4975            No    

2007/9/11更新

対応バージョン: 11.9.2

sp_spaceusedを使用する。

引数なしの場合はデータベース全体の、引数にテーブル名を指定した場合は該当テーブルに関する使用状況がそれぞれ参照できる。

1> use <DB>
2> go

1> sp_spaceused
2> go
 database_name database_size
 ------------- -------------
 <DB>             12500.0 MB    
 reserved   data       index_size unused          
 ---------- ---------- ---------- -------- 
 2379832 KB 2070400 KB  233596 KB 75836 KB        

1> sp_spaceused <テーブル>
2> go
 name       rowtotal reserved data index_size unused
 ---------- -------- -------- ---- ---------- ------
 <テーブル> 7        64 KB    2 KB 6 KB       56 KB

2007/9/11更新

対応バージョン: 11.9.2

sysdatabasesシステムテーブルを参照するか、sp_helpdbを実行する。

1> select name,dbid,crdate,dumptrdate from sysdatabases
2> go
 name           dbid crdate              dumptrdate
 -------------- ---- ------------------- -------------------
 master            1 Jan  1 1900 12:00AM Mar  1 2002  6:12PM
 model             3 Jan  1 1900 12:00AM Mar  1 2002  6:13PM
 sybsystemprocs    4 Mar  1 2002  6:11PM Mar  1 2002  6:13PM
 tempdb            2 Mar  1 2002  6:11PM Mar  4 2002  1:51PM
 :

1> sp_helpdb
2> go
 name           db_size owner dbid created      status
 -------------- ------- ----- ---- ------------ ----------------------------
 master          5.0 MB sa       1 Jan 01, 1900 no options set
 model           2.0 MB sa       3 Jan 01, 1900 no options set
 sybsystemprocs 60.0 MB sa       4 Mar 01, 2002 no options set
 tempdb          2.0 MB sa       2 Mar 06, 2002 select into/bulkcopy/pllsort
 :

2008/7/26更新

対応バージョン: 11.9.2

重要度の低いエラーはデフォルトではログファイルに出力されないが、sp_altermessageを用いて特定のエラー番号をログファイルに出力することができる。

例えばSPを実行しようとしてそのSPが存在しない場合、以下のエラーが出る。

1> foo
2> go
Msg 2812, Level 16, State 5:
Line 1:
Stored procedure 'foo' not found. Specify owner.objectname
or use sp_help to check whether the object exists (sp_help
may produce lots of output).

これをログファイルに出力させるには以下のようにする。

1> use master
2> go
1> sp_altermessage 2812,"with_log","true"
2> go
Message altered.

この設定はsysmessagesテーブルに格納された各エラー番号毎のデバッグレベル(dlevel)として扱われる。

1> select error,dlevel,description from sysmessages
2> where error = 2812
3> go
 error dlevel description
 ----- ------ ------------------------------------
  2812    130 Stored procedure '%.*s' not found...

with_logオプションによるデバッグレベルには以下の2種類がある。

130

ログ出力(true)

2

ログ未出力(false)

関連資料・記事

2007/10/6更新

対応バージョン: 11.9.2

バックアップサーバのエラーメッセージの形式は以下のようになっている。

MMM DD YYY: Backup Server:N.N.N.N: Message Text 

バックアップサーバのメッセージ番号はN.N.N.Nのようにピリオドで区切られた4つの整数で構成されている。

N.N.N.Nの形式のメッセージはOpen Serverによって送られる。

バックアップサーバのエラーメッセージの4つのコンポーネントは、major.minor.severity.stateである。

majorコンポーネント

majorコンポーネントは通常、エラーが発生したバックアップサーバコードの機能領域を示す。

1

システムエラー

2

Open Serverのイベントエラー

3

バックアップサーバのリモートプロシージャコールエラー

4

I/Oサービスレイヤエラー

5

ネットワークのデータ転送エラー

6

ボリューム処理エラー

7

オプションの解析エラー

majorエラーのカテゴリ1〜6の原因はバックアップサーバの内部エラーまたはさまざまなシステムの問題が考えられる。

カテゴリ7のメジャーエラーの原因はほとんど常にダンプコマンドまたはロードコマンドに指定したオプションの誤りである。

minorコンポーネント

minor番号はメジャーエラーのカテゴリの中で順番に割り当てられる。

severityコンポーネント

severityが取り得る値は以下のいずれかである。

1

情報。ユーザのアクションは不要である。

2、3

セッションに致命的な影響を与える可能性のある、予測しなかった状態が発生した。エラーは使用状況、環境、または内部論理のうちのいずれか、またはその全てによって発生した。

4

バックアップサーバの実行に致命的な影響を与える、予測しなかった状態が発生した。バックアップサーバをただちに終了すること。

stateコンポーネント

stateコードはコード内のエラーレポートのインスタンスに1対1で対応している。

バックアップサーバのエラーについてSybaseの保守契約を結んでいるサポートセンタに連絡する必要がある場合、stateコードはエラーの正確な原因を判断するのに役立つ。

2007/10/6更新

対応バージョン: 11.9.2

Adaptive Serverが出力するエラーにはその重大度によってレベル分けされている。

以下に、重大度レベルによるシステムへの影響度について説明する。

重大度レベル10〜18

重大度レベルが10〜16のエラーメッセージはユーザエラーが原因の問題によって生成される。

これらは常にユーザが解決できるエラーである。

重大度レベル17と18のエラーではユーザのセッションは停止されない。

重大度レベルが17以上のエラーメッセージはシステム管理者またはデータベース所有者に連絡すべきである。

重大度レベル10 : ステータス情報

重大度レベルが10のメッセージはエラーではない。

ある特定のコマンドの実行後に追加情報を提供するもので、通常はメッセージ番号や重大度レベルは表示されない。

たとえばcreate databaseコマンドを実行するとAdaptive Serverは要求された領域のどの程度が新しいデータベースに割り付けられたかを示すメッセージを表示する。

isqlでは重大度レベル10の(ステータスまたは情報)メッセージのメッセージ番号や重大度レベルは表示されない。

Open ClientアプリケーションではAdaptive Serverは重大度レベル10については0を返す。

重大度レベル11 : 指定されたデータベースオブジェクトが検出できない

重大度レベル11のメッセージはAdaptive Serverがコマンドで指定されたオブジェクトを見つけることができないことを示す。

主な原因にはデータベースオブジェクト名の入力ミス、オブジェクトの所有者名の指定洩れ、現在のデータベースの誤認などがある。

オブジェクト名が正しく入力されているかをチェックし、ユーザ自身または"dbo"がオブジェクトの所有者でない場合は所有者名を指定して正しいデータベースにいることを確認すること。

重大度レベル12 : 不正データ型の検出

重大度レベル12のメッセージはデータ型に問題があることを示す。

例えば、フィールドに正しくないデータ型の値を入力しようとした場合、または異なる(および互換性のない)データ型のフィールドを比較しようとした場合である。

比較の問題を訂正するにはselect文でconvert関数を使用する。

重大度レベル13 : ユーザトランザクションの構文エラー

重大度レベル13のメッセージは現在のユーザ定義トランザクションに問題があることを示す。

たとえばbegin transactionを発行しないでcommit transactionコマンドを実行したり、定義されていないセーブポイントにトランザクションをロールバックしようとした場合である(セーブポイント名の入力ミスの場合もある)。

重大度レベル13はデッドロックを示すこともある。

その場合にはデッドロックの原因となるプロセスはロールバックされる。

コマンドを再起動しなければならない。

重大度レベル14 : コマンド実行のパーミッションが不十分

重大度レベル14のメッセージはコマンドの実行やデータベースオブジェクトのアクセスに必要なパーミッションがないことを示す。

データベースオブジェクトの所有者、データベースの所有者、またはシステム管理者に連絡して問題のコマンドやオブジェクトの使用パーミッションを取得すること。

重大度レベル15 : SQL文の構文エラー

重大度レベル15のメッセージはコマンドの構文に誤りがあることを示す。

これらのエラーメッセージのテキストには間違いのある行番号およびその付近にある特定のワードが含まれている。

重大度レベル16 : その他のユーザエラー

重大度レベル16のエラーメッセージのほとんどは他のカテゴリに属さない致命的でない誤りがあったことを示す。

16以上の重大度レベルはソフトウェアまたはハードウェアのエラーも示す。

例えば、制約に違反する方法でビューを更新しようとした場合である。

また、あるフィールド名をもつテーブルを複数指定したコマンドの中でそのフィールド名を修飾しなかった場合である。

Adaptive Serverはユーザが意図するテーブルを判断することができないのでコマンドの構文と作業データベースのコンテキストをチェックして欲しい。

通常は重大度レベルが17以上のメッセージでもdbcc checktableまたはdbcc checkallocによって発生した場合は次のオブジェクトでもチェックが行われるように重大度レベル16と表示される。

dbccユーティリティを実行しているときに重大度レベル16のエラーメッセージが表示された場合は、2500〜2599のエラーメッセージを確認すること。

(*) システム管理者は重大度レベル17〜26までのエラーの発生をモニタすること。

重大度レベル17および18は通常はエラーログにレポートされない。ユーザには重大度レベル17および18のエラーが発生した場合にシステム管理者に連絡するよう指示を与えておくべきである。

重大度レベル17 : リソース不足

重大度レベル17のエラーメッセージはコマンドが原因でAdaptive Serverのリソース(通常はディスク上のデータベース用の領域)が不足したり、システム管理者が設定した制限を超えたことを示す。

実行中の作業を続行できるが実行できないコマンドもある。

システムの制限には同時にオープンできるデータベースの個数とAdaptive Serverに接続できる接続数などがある。

制限はシステムテーブルに保管され、sp_configureコマンドを使用してチェックできる。

領域が不足していることを示す重大度レベル17のエラーメッセージの場合、データベース所有者が訂正できる。

その他の重大度レベル17のエラーメッセージについては訂正するのはシステム管理者である。

重大度レベル18 : 致命的でない内部エラーが検出された

重大度レベル18のエラーメッセージはある種の内部ソフトウェアのバグを示す。

ただしコマンドは最後まで実行されAdaptive Serverとの接続は保たれる。

実行中の作業を続行できるが実行できないコマンドもある。

重大度レベル18になる状況には正当な理由もなく特定のクエリのためにアクセスパスが決定されたことをAdaptive Serverが検出した場合がある。

重大度レベル18のメッセージの原因になる問題ではユーザの作業は中断されないためユーザが問題を報告しない場合がある。

システム管理者が重大度レベル18の問題をレポートできるようにするため、重大度レベル18以上のエラーメッセージが発行された場合には必ずシステム管理者に報告するようにユーザに指示を与えたほうがよいだろう。

重大度レベル19〜

致命的な問題が起きると重大度レベル19以上のエラーメッセージが生成される。

この場合Adaptive Serverとユーザとの接続は切断される。

作業を続けるにはユーザはクライアントプログラムを再起動しなければならない。

致命的なエラーが発生するとプロセス(コマンドで指定したタスクを達成するために実行中のプログラムコード)は中止される。

プロセスは停止する前にいったん静止状態となり、発生した問題についての情報を記録する。

その後処理は強制終了され消滅する。

ユーザの接続が切断された場合はユーザは再接続して作業を再開できないこともある。

この範囲の重大度レベルの問題では1人のユーザおよび1つのプロセスだけに影響を与えるものと、データベースの全てのプロセスに影響を与えるものとがある。

場合によってはAdaptive Serverを再起動する必要がある。

これらの問題は必ずしもデータベースまたはそのオブジェクトに損傷を与えるわけではないが損傷を与える場合もある。

また、問題発生の原因が過去のデータベースまたはそのオブジェクトの損傷である場合もある。

ハードウェアの故障が原因の問題もある。

カーネルからの致命的エラーメッセージのバックトレースはエラーログファイルに送られる。

システム管理者はこのファイルを参照してエラーを見直すことができる。

重大度レベル19 : リソースでのAdaptive Serverの致命的なエラー

重大度レベル19のエラーメッセージは、設定可能でない内部制限値を超えたこと、およびAdaptive Serverが正しい順序でリカバリできないことを示す。

この場合はAdaptive Serverに再接続する必要がある。

このエラーメッセージを受け取った場合はシステム管理者に連絡すること。

重大度レベル20 : 現在のプロセスでのAdaptive Serverの致命的なエラー

重大度レベル20のエラーメッセージはAdaptive Serverがコマンドのなかにバグを検出したことを示する。

問題は現在のプロセス以外には影響を与えていない。

データベース自体が損傷した可能性はほとんどない。

dbcc診断を実行すること。

また、Adaptive Serverに再接続する必要がある。

このエラーメッセージを受け取った場合はシステム管理者に連絡すること。

重大度レベル21 : データベースプロセスでのAdaptive Serverの致命的エラー

重大度レベル21のエラーメッセージはAdaptive Serverが現在のデータベースでの全てのプロセスに影響を与えるバグを検出したことを示す。

ただしデータベース自体が損傷した可能性はほとんどない。

Adaptive Serverを再起動して、dbcc診断を実行して欲しい。

また、Adaptive Serverに再接続する必要がある。

このエラーメッセージを受け取った場合はシステム管理者に連絡すること。

重大度レベル22 : Adaptive Serverの致命的なエラー(テーブルの整合性の損傷)

重大度レベル22のエラーメッセージはメッセージに示されたテーブルまたはインデックスが以前にソフトウェアまたはハードウェアの問題によって損傷を受けたことを示する。

まずAdaptive Serverを再起動してデータベース内の他のオブジェクトも損傷を受けているかどうかを判断するためにdbccを実行する。

dbccから何かレポートされた場合は問題はディスク自体ではなくキャッシュ内だけであると考えられる。

その場合はAdaptive Serverを再起動すると問題が解決される。

再起動しても問題が解決できない場合、問題はディスクにも存在する。

エラーメッセージに示されたオブジェクトを削除すると問題が解決できる場合がある。

例えばAdaptive Serverがノンクラスタードインデックスの中に長さ0のローを見つけたことをメッセージが示す場合はテーブル所有者はインデックスを削除して作り直すことができる。

Adaptive Serverに再接続する必要がある。

このエラーメッセージを受け取った場合はシステム管理者に連絡すること。

重大度レベル23 : 致命的なエラー(データベースの整合性の損傷)

重大度レベル23のエラーメッセージは以前にソフトウェアまたはハードウェアの問題によって発生した損傷が原因でデータベース全体の整合性が失われた可能性があることを示す。

Adaptive Serverを再起動してdbcc診断を実行すること。

データベース全体に問題の可能性がある場合でも実際にはキャッシュだけの損傷で、ディスク自体には問題がないことがある。

その場合にはstartserverを使用してAdaptive Serverを再起動すると問題が解決される。

重大度レベル24 : ハードウェアエラーまたはシステムテーブルの損傷

重大度レベル24のエラーメッセージはある種のメディア障害または(まれに)sysusagesの矛盾を示す。

この場合システム管理者がデータベースを再ロードする必要がある。

またハードウェアの購入元に連絡する必要がある場合もある。

重大度レベル26 : ルールエラー

重大度レベル26のエラーメッセージは内部ロックまたは同期ルールが破損していることを示す。

Adaptive Serverをいったん停止して再起動する必要がある。

2008/1/5更新

対応バージョン: 11.9.2

複数ファイルにバックアップファイルが分割されている状況において、load databaseで分割ファイルの指定が足りないとこのようなエラーになる。

エラー例) 3つの分割ファイルからload databaseにてDBを復旧する場合に2ファイルしか指定していない

load database foo
     from "/db/dmp/foo_01.dmp"
stripe on "/db/dmp/foo_02.dmp"
go

2007/12/8更新

対応バージョン: 11.9.2

isqlやbcpなどのツール上からデータベースを操作していた場合、このプロセスを中断してもSybase内部のプロセスが中断されずに残っている場合がある。

このような場合は別途Sybase内部のプロセスを強制終了させる必要がある。

例) bcpを中断したがSybase内部にプロセスが残っている場合

1> select * from master..sysprocesses where program_name = "bcp"
2> go
 spid kpid  .. program_name .. cmd         .. tran_name   ..
 ---- -----    ------------    -----------    -----------
   14 29110    bcp             LOG SUSPEND    foodb..test

1> kill 14
2> go

関連資料・記事

2007/9/28更新

対応バージョン: 11.9.2

これは当該DBのトランザクションログがいっぱいになって同ログがダンプあるいは領域拡張されて空き領域が確保されるまで処理が停止(サスペンド)している状態なので、以下のいずれかの対応を行う。

トランザクションログをダンプする。

不要なトランザクションログを削除する。

関連資料・記事

一つのトランザクションでログ領域を全て使いきってしまうような場合は上記の対処ができないので以下のいずれかの対処を行う。

可能であれば、一度に大量のログを発生させないようにプログラムを修正する。
そのログの出力量が妥当なのであればログ領域を拡張する。

関連資料・記事

2007/9/28更新

対応バージョン: 11.9.2

masterデータベース中のトランザクションログがいっぱいになった。

他のトランザクションの終了を待って再度実行するか、不要なトランザクションログを削除する。

関連資料・記事

2007/8/25更新

対応バージョン: 11.9.2

データベースサーバが使用しているリソースが限界に達している可能性があるので、以下のリソースの使用状況を調べる。

オープンしているデータベースの状態

1> sp_monitorconfig "number of open databases"
2> go
 Name                     # Free # Active % Active # Max Ever Used Re-used
 ------------------------ ------ -------- -------- --------------- -------
 number of open databases     40       24    37.50              24 No

オープンしているインデックスの状態

1> sp_monitorconfig "number of open indexes"
2> go
 Name                   # Free # Active % Active # Max Ever Used Re-used
 ---------------------- ------ -------- -------- --------------- -------
 number of open indexes      1     9999    99.99           10000 Yes

オープンしているオブジェクトの状態

1> sp_monitorconfig "number of open objects"
2> go
 Name                   # Free # Active % Active # Max Ever Used Re-used
 ---------------------- ------ -------- -------- --------------- -------
 number of open objects      1     9999    99.99           10000 Yes

その他、実行されているSQLの数、オープンされているカーソルの数等

オープンしているデータベースやカーソルをクローズする等、使用しているリソースを少し開放すれば同エラーが出なくなる可能性がある。

それでも同エラーが出る場合はsp_configure等でシステムパラメータを調整する必要がある。

2007/9/28更新

対応バージョン: 11.9.2

前回データベースオフライン時に何らかの理由で異常な状態のままオフラインになったため、当該データベースにサスペクト(suspect)フラグが立っている。

異常の原因が既に取り除かれているのであれば、システムテーブルのサスペクトフラグをクリアすることによってオンラインにできる。

以下の作業を行った後にAdaptive Serverを起動する。尚、作業は全てmasterデータベース上で行う。

Adaptive Serverの設定を変更可にする。
1> sp_configure "allow updates", 1
2> go
サスペクトフラグをクリアする。
1> begin transaction
2> go

1> update sysdatabases
2> set status = status & ~256
3> where name = '<DB名>'
4> go

ここで、影響を受けたローが1つだけの場合は次へ、2つ以上ならトランザクションをロールバックして他のローが影響を受けた原因を調べる。

1> commit transaction
2> go
Adaptive Serverの設定を変更不可にする。
1> sp_configure "allow updates", 0
2> go

1> checkpoint
2> go
バックアップサーバを終了する。
1> shutdown SYB_BACKUP
2> go
Adaptive Serverを終了する。
1> shutdown
2> go

2007/8/25更新

対応バージョン: 11.9.2

データベースになんらかの障害が起き、データベースそのものの整合性が取れなくなった。

このエラーを復旧するにはデータベース再作成しかないが、drop databaseによる通常のデータベース削除もできないので、dbcc dbrepairコマンドにより強制的に削除して再作成する。

1> dbcc dbrepair(<DB>,dropdb)
2> go

このエラーが起きる原因として例えば以下のような場合がある。

トランザクション中に当該セッションを強制的に切断した。
データベースサーバをOSのコマンドなどで強制終了した。
データベースへのアクセス中に突然マシンが落ちた。

2007/8/25更新

対応バージョン: 11.9.2

データベースサーバの再起動が必要ななんらかのデータベース修復作業を行ったが、まだデータベースサーバを再起動していない。

2007/8/25更新

対応バージョン: 11.9.2

sp_foreignkey(設定)、sp_dropkey foreign(削除)にて行う。

外部キー設定

sp_foreignkey <対象テーブル>, <被リンクテーブル>, <被リンクテーブル対象カラム>

例) testテーブルの外部キーとしてdataテーブルのitemカラムを設定する。

sp_foreignkey test, data, item

外部キー削除

sp_dropkey foreign, <対象テーブル>, <被リンクテーブル>

例) testテーブルに設定されているdataテーブルへの外部キーを削除する。

sp_dropkey foreign, test, data

2007/8/25更新

対応バージョン: 11.9.2

デバイス番号の省略はできない。

以下の手順で現在使用中のデバイス番号を調べて、空いている番号をデバイス番号として使用する。

1> select distinct low/16777216 from sysdevices order by low
2> go
 -----
     0
     1
     2
     3
     4
     5

上記の例の場合は0〜5までのデバイス番号が使用されているので6番以降が使用できる。

デバイス番号には上限値がありデフォルトでは1データベースサーバあたり10となっている。

この値は"number of devices"パラメータにて変更できる(最大は255)。

例えばデバイス番号の上限値を255にする場合、以下の手順で変更する。

現在値の確認

1> sp_configure "number of devices"
2> go
 Parameter name    Default Memory Used Config Value Run Value
 ----------------- ------- ----------- ------------ ---------
 number of devices      10           0           10        10

設定変更

1> sp_configure "number of devices",255
2> go

2007/8/25更新

対応バージョン: 11.9.2

以下の手順で作業する。

masterデータベースにログイン

% isql -Usa -P<pass> -Dmaster

削除対象のデバイス上に存在するデータベースを全て削除

1> drop database <DB>
2> go

論理デバイスを削除

1> sp_dropdevice <論理デバイス名>
2> go
Device dropped.

rmコマンドにより物理ファイルを削除

# rm <物理ファイル>

該当データベース上にアカウントを作成していた場合はmasterデータベースからアカウントを削除

1> sp_droplogin <アカウント>
2> go
Account locked.
Login dropped.

2007/8/25更新

対応バージョン: 11.9.2

データベースの作成にはまず物理ファイルをSybase用の論理デバイスとして割り当てて、それを1ファイル、あるいは複数ファイル組み合わせてデータベースとして構成する。

以下、順を追って説明する。

構成検討

まずデータベースの構成を検討する。

Sybaseのデータベースはデータ用の領域とログ用の領域の2種類に分けられるので、ここでは以下の構成と仮定して説明する。

データ領域1 : 1GB
データ領域2 : 2GB
ログ領域  : 500MB

論理デバイス割り当て

物理ファイルを作成し、それに論理デバイスを結びつける作業を行う。

論理デバイスはSybase内部で一意の番号で扱われるので、まず未使用のデバイス番号を調べる。

尚、今後の作業は全てmasterデータベース上で行う。

1> select distinct low/16777216 from sysdevices order by low
2> go

-----------
          :
         24

上記の例では24番まで使用していることが分かるので新たに25番を使用することとする。

次にデバイス(物理ファイル)を作成する。

データ領域1 (1GB)
1> disk init 
2> name = "datadisk1", ← 論理デバイス名
3> physname = "/tmp/datadisk1.dat", ← デバイスの物理ファイル名
4> vdevno = 25, ← 論理デバイス番号
5> size = 512000 ← デバイスサイズを2Kブロック単位で指定(512000ブロック * 2KB = 1GB)
6> go
データ領域2 (2GB)
1> disk init 
2> name = "datadisk2",
3> physname = "/tmp/datadisk2.dat",
4> vdevno = 26,
5> size = 1024000 ← 1024000ブロック * 2KB = 2GB
6> go
ログ領域 (0.5GB)
1> disk init
2> name = "logdisk_01", 
3> physname = "/tmp/logdisk1.dat", 
4> vdevno = 27, 
5> size = 256000 ← 256000ブロック * 2KB = 0.5GB
6> go

データベース作成

上記で作成した論理デバイスを使用してデータベースを作成する。

1> create database db1 on ← データベース「db1」作成開始
2> datadisk1 = 1000 ← データ領域として「datadisk1」を割り当て
3> log on logdisk1 = 500 ← ログ領域として「logdisk1」を割り当て
4> for load ← Exportファイルからのロード用指定
5> go

1> alter database db1 on datadisk2 = 2000 ← データ領域として「datadisk2」を追加割り当て
2> go

データベースの状態チェック

作成したデータベースの状態はsp_helpdbによって確認できる。

「for load」オプション付でデータベースを作成したのでstatus欄が「don't recover(リカバリ禁止)」になっている。

1> sp_helpdb db1
2> go
 name db_size   owner dbid created      status
 ---- --------- ----- ---- ------------ -------------
 db1  3500.0 MB sa       5 Feb 13, 2002 don't recover

 device_fragments size      usage       free kbytes
 ---------------- --------- ----------- -----------
 datadisk1        1000.0 MB  data only      1022016
 datadisk2        2000.0 MB  data only      2012342
 logdisk1          500.0 MB  log only         51124

データImport

あらかじめ用意しておいたExportファイルからデータをImportする。

ここでは2つのファイルからImportするものとする。

1> load database db1
2>      from "/tmp/data1.dmp"
3> stripe on "/tmp/data2.dmp"
4> go

データベースオンライン

データをImportしただけではデータベースは使用できないので、明示的にオンラインにする。

1> online database db1
2> go
  Database 'db1' is now online.

再度データベースの状態を確認すると、status欄が「no options set(オプションなし)」に変化して、データベースの残り容量が若干減っているのが分かる。

1> sp_helpdb db1
2> go
 name db_size   owner dbid created      status
 ---- --------- ----- ---- ------------ --------------
 db1  3500.0 MB sa       5 Feb 13, 2002 no options set

 device_fragments size      usage       free kbytes
 ---------------- --------- ----------- -----------
 datadisk1        1000.0 MB  data only       982016 ← 残り容量が微減
 datadisk2        2000.0 MB  data only      2012342
 logdisk1          500.0 MB  log only         51124

2007/8/25更新

対応バージョン: 11.9.2

クライアントのCharacter Setがja_JP.UTF-8だが、Character Set定義ファイル($SYBASE/locales/locales.dat)に存在しない。

同ファイルにCharacter Setを追加することで解決する。

例えばプラットフォームがSolaris/SPARCの場合、同ファイルを以下のように修正する。

(修正前)

  344      locale = en_US, us_english, iso_1

(修正後)

  344 ;    locale = en_US, us_english, iso_1 ← コメントアウト
  345      locale = en_US.UTF-8, us_english, utf8 ← 追加
  346      locale = ja_JP.UTF-8, us_english, utf8 ← 追加

2007/8/25更新

対応バージョン: 11.9.2

クライアントのCharacter Setが`iso_1'(C)なのにも関わらずサーバ側のそれが`eucjis'(ja)のため文字コード変換ができない。

両者のCharacter Setを揃えることで解決する。

上記の場合は例えばクライアントのCharacter Setを`eucjis'にする(LANG環境変数を`ja'にする)ことで解決する。

2007/8/25更新

対応バージョン: 11.9.2

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

データベースサーバが起動していない。
環境変数DSQUERYが正しい値に設定されていない。
環境変数SYBASEが正しい値に設定されていない。

2007/8/25更新

対応バージョン: 11.9.2

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

該当のユーザが存在しない。
パスワードが間違っている。

2009/1/14更新

対応バージョン: 11.9.2

名前付データキャッシュを使用するには以下のように設定する。

[Named Cache:limits_cache]
cache size = 15M
cache status = mixed cache
cache replacement policy = relaxed LRU replacement

cache status(キャッシュ使用目的)には以下のいずれかが指定できる。

DEFAULT

(デフォルトキャッシュでのみ指定)

mixed cache

データ & ログ共用

logonly

ログ専用

cache replacement policy(キャッシュ置換方式)には以下のいずれかが指定できる。

relaxed LRU replacement

MRU/LRU順に並んだページを保持しない。これによりキャッシュがテーブル又はインデックス専用でシステムが安定状態になったときにバッファの置換がほとんど発生しない、あるいは全く発生しない場合にパフォーマンスが向上する。

strict LRU replacement

ページがアクセスされる度にMRU/LRUチェーンの先頭に位置付けられる。

2009/1/14更新

対応バージョン: 11.9.2

Adaptive Serverはデフォルトで2Kのバッファプールを作成するが、それ以外に4K/8K/16Kのバッファプールを明示的に指定することができる。

[4K I/O Buffer Pool]
pool size = 20.0000M
wash size = DEFAULT
local async prefetch limit = DEFAULT

[8K I/O Buffer Pool]
pool size = 20.0000M
wash size = DEFAULT
local async prefetch limit = DEFAULT

[16K I/O Buffer Pool]
pool size = 20.0000M
wash size = DEFAULT
local async prefetch limit = DEFAULT

2007/9/11更新

対応バージョン: 11.9.2

以下の手順で設定する。作業は全てsybaseアカウントで行う。

UTF-8のSort Orderファイルを読み込む。

% charset -Usa -P<pass> binary.srt utf8
Loading file 'binary.srt'.

Found a [sortorder] section.

This is Class-1 sort order.

Finished loading the Character Set Definition.

Finished loading file 'binary.srt'.

1 sort order loaded successfully

(*) binary.srtファイルは$SYBASE/charsets/utf8/binary.srtが使われる。

システムパラメータ「default character set id」に190(UTF-8)を設定する。

% isql -Usa -P<pass>
1> sp_configure "default character set id", 190
2> go

各DBのシステムテーブルのSort Orderを変更するためDBサーバを再起動する。

DBサーバ停止
1> shutdown
2> go

$DSQUERY.logには以下のようなログが出力される。

Now loading SQL Server's new default sort order and character set
Default Sort Order success fully changed.
DBサーバ起動
% cd $SYBASE/install

% ./startserver -f RUN_$DSQUERY

$DSQUERY.logには以下のようなログが出力される。

SQL Server's default sort order is: 'bin_utf8' (ID = 50)
on top of default character set: 'utf8' (ID = 190).

2007/9/11更新

対応バージョン: 11.9.2

$SYBASE/interfacesファイルに記述されているホスト名/IPアドレスを変更する。

作業はsybaseアカウントで行なうが、直接interfacesファイルを編集するよりも専用のツールdseditを使用して設定を変更したほうがミスが少ない。

変更箇所はDBサーバとバックアップサーバの2箇所である。

また、待ち受けポートを変える場合にもinterfacesファイルを変更する。

2007/8/25更新

対応バージョン: 11.9.2

以下のファイルから該当サーバのエントリを削除

$SYBASE/interfaces
/etc/init.d配下等に置いてあるinitスクリプト

以下のファイルを削除

$SYBASE/install/RUN_<該当サーバ>
$SYBASE/<該当サーバ>.*
デバイスファイルの実体

srvbuild等で通常のサーバ作成を行う

関連資料・記事

2007/8/25更新

対応バージョン: 11.9.2

これはSybaseの問題というよりOSの問題であるが、例えばSolaris 8のように一つのファイルの最大サイズが2GBに制限されているようなOSの場合にこのエラーが出る。

しかし、bcpはテーブルの一部分を抜き出すことができないので、以下のような方法で対応する。

対象テーブル内の不要データを削除して出力ファイルサイズが2GB以内に収まるようにする。
対象テーブルと同じレイアウトのテーブルを複数作成して2GB以内ずつデータを分け、それを個別にbcp outする。

2007/8/25更新

対応バージョン: 11.9.2

デーベースサーバの設定で文字コード変換を不許可にしていないか確認し、必要に応じて許可する。

1> select @@char_convert
2> go
 ---
   0 ← 0:不許可 1:許可

上記設定は"disable character set conversions"にて設定するのでまず現状を確認して、1(不許可)になっていた場合0(許可)に変更する。

1> sp_configure "disable character set conversions"
2> go
 Parameter Name                 Default Memory Used Config Value Run Value
 ------------------------------ ------- ----------- ------------ ---------
 disable character set conversi       0           0            1         1

1> sp_configure "disable character set conversions", 0
2> go

設定変更後、データベースサーバの再起動を行う。

2007/8/25更新

対応バージョン: 11.9.2

該当テーブルにidentity属性付きのカラムが存在しないので-Eオプションを付ける必要はない。

関連資料・記事

2008/6/12更新

対応バージョン: 11.9.2

bcp inでファイルからDBにデータを挿入する場合、高速モードと低速モードの2種類が利用できる。

高速モードはトランザクションログが記録されないので安全性では低速モードには劣るがパフォーマンスが高い。

もしエラー発生時にロールバックの必要がなく、途中までINSERTに成功したデータをいったん削除して再度bcp inを行えるのであれば高速モードが利用できる。

ただしモードを明示的に指定することはできず、以下の条件を全て満たした時のみ自動的に高速モードが選択される。

テーブルにインデックス、トリガーがない

データベースに「select into/bulkcopy/pllsort」オプションが設定されている

尚、高速モード実行後はトランザクションログのdumpができなくなるためデータベースのdumpを取得したほうがよい。

2007/10/6更新

対応バージョン: 11.9.2

-Eオプションを付ける。

このオプションを付けないと、bcpで指定したファイル中のデータのうち挿入先のカラムにidentity属性が付いているカラムについてはファイル中のデータが使われずにAdaptive Serverが自動的にそのカラムにデータを挿入する。

bcp <DB>..<テーブル> in <挿入データファイル> -E -U<ユーザ> -P<パスワード> -c -t'|'

-c、-tオプションの意味は以下のとおり。

-c

データをキャラクタとして扱う。

-t <デリミタ>

挿入データファイル中の各カラムの区切り文字

関連資料・記事

2007/9/11更新

対応バージョン: 11.9.2

当バージョンのSybaseで扱えるファイルサイズは最大2GBなので、dumpコマンドのstripe onオプションを使用して複数のファイルにバックアップする。

例) 5GBのDBを3つのファイルに分割バックアップする

1> dump database <DB>
2>        to "/tmp/bkup_01.dmp"
3> stripe on "/tmp/bkup_02.dmp"
4> stripe on "/tmp/bkup_03.dmp"
5> go

リストア時にも同様に、loadコマンドのstripe onオプションを使用する。

1> load database <DB>
2>      from "/tmp/bkup_01.dmp"
3> stripe on "/tmp/bkup_02.dmp"
4> stripe on "/tmp/bkup_03.dmp"
5> go

2007/8/25更新

対応バージョン: 11.9.2

このメッセージはパスワードの有効期限が近付いたことを利用者に知らせるもので、上記メッセージはあと4.1日でパスワードの有効期限が切れることを示している。

期限が切れる前にパスワードを変更する。

関連資料・記事

2007/8/25更新

対応バージョン: 11.9.2

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

どこかのデータベース上にそのユーザ(alias含む)がまだ存在している。

この場合、まずそのデータベース上でsp_dropuserにてユーザを削除してからsp_droploginを実行する。

そのユーザがどこかのデータベースのオーナーになっている。

この場合、sp_changedbownerにて該当データベースのオーナーを別のユーザに変更してからsp_droploginを実行する。

2007/8/25更新

対応バージョン: 11.9.2

sp_modifyloginを使用する。

1> sp_modifylogin <対象ユーザ>,defdb,<変更先DB>
2> go

2007/11/2更新

対応バージョン: 11.9.2

システムパラメータ「password expiration interval」に有効期限(日数)を設定する。

% isql -Usa -P<pass>
1> sp_configure "password expiration interval", <有効期限>
2> go

0を指定すると無期限となる。

2007/8/25更新

対応バージョン: 11.9.2

sp_passwordを使用する。

1> sp_password <ユーザのパスワード(*)>,<新しいパスワード>,<対象ユーザ>
2> go
Password correctly set.

(*) ユーザのパスワードとはパスワード変更ユーザのパスワードではなく、isql等でAdaptiveServerに接続したユーザのパスワードである。

2007/8/25更新

対応バージョン: 11.9.2

sp_changegroupを使用する。

1> sp_changegroup <変更後グループ>, <対象ユーザ>
2> go

また、単に所属グループから脱退したい場合は<変更後グループ>に"public"を指定すればよい。

1> sp_changegroup "public", <対象ユーザ>
2> go

(*) publicは予約語なので引用符で囲む必要がある。

2008/1/19更新

対応バージョン: 4.2

準備

あらかじめインストールしておくもの

Sybase Adaptive Server Enterprise

関連資料・記事

導入に必要なもの

製品CD-ROM

導入OS

Solaris 8

環境変数設定(root、及び利用者毎)

<新規>
JDBC_HOME

/opt/sybase/jconnect-4_2

<既存の設定に追加>
CLASSPATH

$JDBC_HOME/classes

インストール

インストール

# mkdir -p $JDBC_HOME
# cd $JDBC_HOME
# unzip <CD-ROM>/jConnect42.zip

関連テーブル/ストアドプロシージャインストール

% java IsqlApp -U sa -P <パスワード> -S jdbc:sybase:Tds:<接続先ホスト>:<ポート> \
-I $JDBC_HOME/sp/sql_server.sql -c go

インストール物 (man,infoは除く)

テーブル
master..spt_jdbc_table_types       (3レコード)
master..spt_mda                    (175レコード)
master..spt_jtext                  (1レコード)
master..spt_jdbc_conversion        (20レコード)
sybsystemprocs..spt_jdatatype_info (23レコード)
ストアドプロシージャ
sybsystemprocs..sp_default_charset
sybsystemprocs..sp_jdbc_columns
sybsystemprocs..sp_jdbc_convert_datatype
sybsystemprocs..sp_jdbc_datatype_info
sybsystemprocs..sp_jdbc_escapeliteralforlike
sybsystemprocs..sp_jdbc_exportkey
sybsystemprocs..sp_jdbc_fkeys
sybsystemprocs..sp_jdbc_function_escapes
sybsystemprocs..sp_jdbc_getbestrowidentifier
sybsystemprocs..sp_jdbc_getcatalogs
sybsystemprocs..sp_jdbc_getcolumnprivileges
sybsystemprocs..sp_jdbc_getcrossreferences
sybsystemprocs..sp_jdbc_getindexinfo
sybsystemprocs..sp_jdbc_getisolationlevels
sybsystemprocs..sp_jdbc_getprocedurecolumns
sybsystemprocs..sp_jdbc_getschemas
sybsystemprocs..sp_jdbc_gettableprivileges
sybsystemprocs..sp_jdbc_getudts
sybsystemprocs..sp_jdbc_getversioncolumns
sybsystemprocs..sp_jdbc_getxacoordinator
sybsystemprocs..sp_jdbc_importkey
sybsystemprocs..sp_jdbc_primarykey
sybsystemprocs..sp_jdbc_stored_procedures
sybsystemprocs..sp_jdbc_tables
sybsystemprocs..sp_mda
sybsystemprocs..sp_sql_type_name

2007/8/25更新

対応バージョン: 11.9.2

準備

導入に必要なもの

製品CD-ROM

導入OS

Solaris8

製品構成

デフォルトでインストールされる製品

Adaptive Server

データベースサーバ本体

Backup Server

バックアップ&リストアを管理するOpen Serverアプリケーション。

(*) Open ServerアプリケーションとはAdaptive ServerにアクセスするためのAPIを利用したサーバ側アプリケーションのことで、同様にクライアント側のアプリケーションをOpen Clientアプリケーションという。

Adaptive Server Enterprise Monitor (= Monitor Server)

Adaptive Serverのパフォーマンス統計を取得してMonitor Serverのクライアントから利用できるようにするOpen Serverアプリケーション。この製品には以下のものが含まれる。

・Monitor Server for Adaptive Server Enterprise 11.9.x

Monitor Server本体。

・Monitor Historical Server

Adaptive Serverのパフォーマンス統計を取得し、このデータを指定されたファイルに記録するOpen Serverアプリケーション。

・Monitor Client Library

Adaptive Serverのパフォーマンスデータへのアクセスを提供するAPI。

・XP Server

Adaptive Server内から拡張ストアドプロシージャ(ESP)を管理し、実行するOpen Serverアプリケーション。

・Adaptive Serverユーティリティ

スクリプトと設定ファイル

別途追加インストールする製品

言語モジュール (Server)

アプリケーションのローカライズに使用するシステムメッセージと日付/時刻のフォーマットを提供する。

言語モジュール (Clientコネクティビティ)

Open Clientアプリケーションの実行に使用するメッセージとサポートファイルをさまざまな言語で提供する。

Open Client

Open Clientアプリケーションの開発に使用するライブラリとユーティリティ。

ODBC ドライバ

WindowsのODBCクライアントからの接続サービスを提供する。

SQL Advantage

Adaptive Server用GUIツール。

Adaptive Server Plug-In for Sybase Central

Monitor ServerからAdaptive Serverのパフォーマンス統計を取得してリアルタイムで表やグラフに出力するWindows用プラグイン。尚、Sybase Centralはサーバを管理する共通フレームワークである。

Adaptive Serverで使用するデバイス

必須のデバイス

マスタデバイス

システムデータベースを格納する。マスタデバイスには以下のデータベースが入る。

・master

Adaptive Server全体のオペレーションを制御し、全てのユーザデータベース、デバイス、オブジェクト、システムテーブル等の管理情報が保管される。

・model

新しいユーザデータベースにテンプレートを提供する。

・tempdb

Adaptive Serverの作業領域。Adaptive Serverが起動する度にtempdbデータベースはクリアされ、modelデータベースから再構築される。tempdbの領域はサーバの全てのデータベースの全てのユーザの間で共有される。

sysprocsdevデバイス

システムプロシージャを格納する。システムプロシージャのデータベース名はsybsystemprocsである。 システムプロシージャ名は"sp_"で始まる。

(*) 困難なリカバリ状況下で必要となるシステムプロシージャはsybsystemprocsデータベース内ではなくmasterデータベース内に格納されている。

オプションのデバイスとデータベース

sybsecurityデバイスとデータベース

sybsecurityデバイスはsybsecurityデータベースとシステムの監査に使用する監査システムプロシージャを格納する。以下にデータベースの構成を示す。

・監査証跡を含むシステムテーブルsysaudits_01、sysaudits_02、 ... sysaudits_08

・グローバルな監査オプションを記述したロー(行)を含むsysauditoptionsテーブル

・modelから取り出されたその他の全てのデフォルトシステムテーブル

sybsystemdbデバイスとデータベース

sybsystemdbデバイスはsybsystemdbデータベースを格納する。このデータベースには2フェーズコミットトランザクションの情報が保管される。トランザクションの完了ステータスを追跡するテーブルはspt_committabである。

サンプルデータベース
pubs2及びpubs3データベース

学習ツールとして提供されるサンプルデータベース。

interpubs

フランス語とドイツ語のデータが含まれている。

jpubs

日本語のデータが含まれている。

sybsyntaxデータベース

構文データベースであるsybsyntaxにはTransact-SQLコマンド、Sybaseシステムプロシージャ、Adaptive Serverユーティリティ、及び一部のOpen Clientルーチンの構文ヘルプが格納される。この情報はシステムプロシージャsp_syntaxを使って検索できる。

dbccdbデータベース

データベース一貫性チェッカ(dbcc)はデータベースの論理的/物理的一貫性をチェックするコマンドを提供する。dbccdbデータベースにはdbcc checkstorageコマンドを使用したときのdbccの結果が格納される。

dbcc checkstorageは「ターゲットデータベース」の設定情報、オペレーションアクティビティ、そのオペレーションの結果をdbccdbデータベースに記録する。

dbccdbデータベースにはdbccdbの作成と管理を行ったりdbcc checkstorageオペレーションの結果についてのレポートを作成したりするdbccストアードプロシージャが格納されている。

インストール準備

sybaseアカウント作成

アカウント (UID)

sybase (任意)

グループ (GID)

sybase (任意)

ホームディレクトリ

/opt/sybase

ログインシェル

/bin/csh

環境変数設定(利用者毎)

<新規>
SYBASE

/opt/sybase

<既存の設定に追加>
PATH

${SYBASE}/bin

LD_LIBRARY_PATH

${SYBASE}/lib

インストール(GUI)

インストールにはGUIとCUIの2通りの方法があるが、それぞれの方法についてインストール手順を示す。

作業は全てsybaseアカウントでsybsetupを実行して行う。

sybsetup起動

% /cdrom/cdrom0/sybsetup

→ セットアップ画面が表示される。

CD-ROMから製品をアンロード

セットアップ画面から[Unload Sybase Products]を選択。

→ [Installation Destination]画面が表示される。

インストールディレクトリ設定

Sybaseをインストールするディレクトリを指定して[continue]を押す。

デフォルトで環境変数SYBASEの内容が表示されているので通常はそのままでよい。

→ [Installation Source]画面が表示される。この際「msg:47 -WARNING-」画面が表示される場合があるがそのまま続けて問題ない。

デバイスメディア、及びイメージファイル名指定

[CD-ROM]を選択してCDイメージファイル名を/cdrom/cdrom0/sybimageとして指定する。

[Local]を選択して[continue] を押す。

→ [Product Selection]画面が表示される。

設定確認、及びインストール製品選択

[Product Selection]画面上部に今までの設定内容が表示されているので確認し、問題なければインストールする製品を選択する。

インストールする製品を選択する度に[Disk Space Available]フィールドにインストールディレクトリ内の使用可能な領域残量が示される。

尚、デフォルトでインストールされる言語セットは英語といくつかの言語なので日本語も忘れずに選択する。

インストール

[continue]を押すと[Install Products?]ダイアログが表示されるので[OK]を押して製品をインストールする。

→ [Installation Status]画面が表示され、アンロードの状況が表示される。

sybsetupプログラムインストール確認

製品インストールの最後に[Install sybsetup?]画面が表示される。

これはsybsetupプログラム自体を${SYBASE}/binにインストールするかどうかを指定するので必要に応じてsybsetupをインストールする。

sybsetupをインストールしておくと、次回sybsetup実行時にCD-ROMが必要なくなる。

→ [Success]画面が表示される。

インストール(CUI)

作業は全てsybaseアカウントでsybloadを実行して行う。

sybload起動

% cd $SYBASE
% /cdrom/cdrom0/sybload -D

→ セットアップ画面が表示される。

インストールディレクトリ指定

Current directory is "/opt/sybase".

Is this the correct directory for installation?

If so, please enter 'y' or 'Y':  ■

Sybaseをインストールするディレクトリを指定する。

デフォルトで環境変数SYBASEの内容が表示されているので通常はそのままでよい。

インストール方法指定(ローカル/リモート)

Is this a Local or Remote installation, as defined in your Installation Guide?

Please enter L for Local or R for Remote.

> ■ ← ローカルなら「L」、リモートなら「R」

ロード対象イメージファイル名指定

Please enter the full name of the disk file of the global archive:

> ■ ← /cdrom/cdrom0/sybimage

ロード対象となるイメージファイル名を指定する。

通常は/cdrom/cdrom0/sybimageでよい。

CAS(Customer Authorization String)指定

Please enter your Customer Authorization String, letters only:

> ■ ← CD-ROMの/cdrom/cdrom0/install/CASに記載されているCAS情報を入力

アンロード製品選択

Sybase Products available for installation:

  Product No.  1:  Adaptive Server Enterprise, Sun4_SVR4, 11.9.2
  Product No.  2:  Monitor Server for 11.9.2 ASE, Sun4_SVR4, 11.9.2
  Product No.  3:  Monitor Server for 11.0.x SQL Server, Sun4_SVR4, 11.5.1
  Product No.  4:  Monitor Client Library, Sun4_SVR4, 11.9.2
  Product No.  5:  Historical Server, Sun4_SVR4, 11.9.2
  Product No.  6:  Language Modules for Brazilian Portuguese, Sun4_SVR4, 11.9
  Product No.  7:  Language Modules for Chinese, Sun4_SVR4, 11.9
  Product No.  8:  Language Modules for French, Sun4_SVR4, 11.9
  Product No.  9:  Language Modules for German, Sun4_SVR4, 11.9
  Product No. 10:  Language Modules for Japanese, Sun4_SVR4, 11.9
  Product No. 11:  Language Modules for Korean, Sun4_SVR4, 11.9
  Product No. 12:  Language Modules for Spanish, Sun4_SVR4, 11.9

Please enter the Product Numbers that you wish to install, one per line.

Terminate your entries with a blank line.

> 1 (必須)
> 10 (必須)
> ■ ← その他、必要な製品を選択
  :
> ← 最後にリターン

The following products were chosen for installation:

  Choice No.  1:  Adaptive Server Enterprise, Sun4_SVR4, 11.9.2
  Choice No.  2:  Language Modules for Japanese, Sun4_SVR4, 11.9
   :

If this list is correct as shown,

please enter 'y' or 'Y' to continue, 'q' or 'Q' to quit,
or any other character to make another set of choices: ■ ← この製品でよければy

インストール開始

x ./bin/backupserver, 891475 bytes, 1742 tape blocks
x ./bin/bcp, 708466 bytes, 1384 tape blocks
:
x ./scripts/eucjis/installjpubs, 23036 bytes, 45 tape blocks
x ./scripts/sjis/installjpubs, 23106 bytes, 46 tape blocks

The following products have been distributed from tape:

      Adaptive Server Enterprise, Sun4_SVR4, 11.9.2
      Language Modules for Japanese, Sun4_SVR4, 11.9

This concludes the tape distribution portion of the Sybase Installation.

Please consult your Installation Guide for further installation instructions.

更新パッケージ(パッチ)適用

更新パッケージとはSybaseのパッチのことである。

なるべく最新の更新パッケージを適用するようにしたい。

更新パッケージには特にインストーラはなく、単にCDの中身を$SYBASEに展開するだけでよい。

尚、作業は全てsybaseアカウントで行い、どのパッケージも以下の手順で作業する。

sybase ユーザでログイン

CDの内容を$SYBASEディレクトリにコピーする。

% cd $SYBASE
% /bin/cp -rfp /cdrom/cdrom0/* .

OS設定変更

共有メモリパラメータ変更(/etc/system)

共有メモリの最大サイズをASEが使用する最低限のサイズに変更

例) デフォルトの1,048,576(1MB)を268,435,456(256MB)に変更する場合

set shmsys:shminfo_shmmax = 268435456

(*) 268,435,456 = 256 x 1,024 x 1,024

Backup Serverの同時実行数をデフォルトの6より増やす場合は共有メモリセグメントを増やす

set shmsys:shminfo_shmseg = <セグメント数>

リブート後、上記内容の確認

# sysdef | egrep '(SHMMAX|SHMSEG)'
268435456      max shared memory segment size (SHMMAX)
6  max attached shm segments per process (SHMSEG)

初期データベース作成

初期データベースの設計

master ... システムデータベースを格納

最小サイズ:25MB

推奨サイズ:30MB

sysprocsdev (またはsybsystemprocs) ... sybsystemprocsデータベースを格納

最小サイズ:45MB

推奨サイズ:60MB (*)

(*) この値に、作成したストアドプロシジャを保持するための領域を追加する。

sybsystemdb (オプション) ... 2 フェーズコミットで必要

最小サイズ:5MB

推奨サイズ:5MB

sybsecurity (オプション) ... 監査に必要

最小サイズ:0〜5MB

推奨サイズ:7MB(*)

(*) 特別な監査の場合はそれ以上。

初期データベース作成

データベース作成用ディレクトリ作成

データベースを作成するためのディレクトリをあらかじめ作っておく。

% su
# mkdir <データベース作成ディレクトリ>
# chown sybase:sybase <データベース作成ディレクトリ>
# exit
セットアップツール起動
% srvbuild

→ セットアップ画面が表示される。

<<< Adaptive Server >>>
[Adaptive Server]を押すと右側のフォームが開いてデータベース名を指定するが、デフォルトではホスト名と同じ名前が設定されているので適宜目的に合わせて変更し、[OK]を押す。

→ 設定画面が表示される。

必要な情報を設定してデータベースを作成する。
* Master device path:                xxx ← マスターデバイスのパス
* Master device size (MB):           30  ← 適宜変更する
* Master database size (MB):         5   ← 適宜変更する (*)

(*) Languageキットを導入する場合、文字コードテーブル等がここに
    格納されるので10MB程度確保するのがよい

* Sybsystemprocs device path:        xxx ← sybsystemprocs デバイスのパス
* Sybsystemprocs device size (MB):   60  ← 適宜変更する
* Sybsystemprocs database size (MB): 60  ← 適宜変更する
* Error log path:                    xxx ← ログファイルのパス

* Interfaces file entry:

Transport type   Host name     Port number
+------------+  +----------+  +-----------+
|  tli  tcp  |  | xxxxxxxx |  | 4100      | ← 適宜変更する
+------------+  +----------+  +-----------+

→ 設定が終ったら[Build Server!]を押す。

→ デバイスパスにファイルシステムを指定していると警告が出る(Sybaseはデバイスパスにローデバイスを推奨)が、このままでよい場合は[OK]を押す。

→ サーバ構築が終ったら[OK]を押す。

→ ローカライズをするかどうかのダイアログが出る。

+-------------------------------+
|Would you like to localize your|
|Adaptive Server now?           |
+-------------------------------+
ローカライズをする場合、以下の作業を行う。

→ [Yes]を押す。

→ デフォルト言語の指定画面が表示されるので以下の変更を行う。

Choose a default language...
→ [US English]を[Japanese]に変更

Choose a default character set...
→ [DEC Kanji]を[EUC-JIS]に変更

Choose a sort order...
→ 選択肢は1つしかないのでこのまま

→ 変更が終ったら[OK]を押す。

→ 設定変更が始まる。

→ Add and Remove Languages画面が表示されるのでAdd language to Adaptive ServerのJapanese欄にチェックが入っているのを確認して[OK]を押す。

→ ローカライズダイアログに戻るので[OK]を押す。

→ 設定が継続する。

<<< Backup Server >>>
[Backup Server]を押すと右側のフォームが開いてBackup Server名を指定するが、デフォルトで「Adaptive Server名 + _back」が設定されているので適宜目的に合わせて変更し、[OK]を押す。

→ 設定画面が表示される。

必要な情報を設定してデータベースを作成する。
* Related Adaptive Server name: xxx ← Adaptive Server名
* Adaptive Server SA user name: sa  ← SAアカウントのユーザ名
* Adaptive Server SA password:  xxx ← SAアカウントのパスワード
                                       (この時点ではまだ未設定なので`空')
* Error log path:               xxx ← ログファイルのパス
  Tape configuration file:      ___ ← 適宜設定する(とりあえず`空'でも可)
  Language:                     ___ ← 適宜設定する(とりあえず`空'でも可)
  Character set:                ___ ← 適宜設定する(とりあえず`空'でも可)
  Maximum number of network connections: xxx ← 適宜設定する
  Maximum number of server connections: xxx  ← 適宜設定する

* Interfaces file entry:

Transport type   Host name     Port number
+------------+  +----------+  +-----------+
|  tli  tcp  |  | xxxxxxxx |  | 4200      | ← 適宜設定する
+------------+  +----------+  +-----------+

→ 設定が終ったら[Build Server!]を押す。

→ 作成が始まる。

→ 画面にDoneと表示されたら[OK]を押す。

データベースの動作チェック

isqlによるチェック

各サーバについてisqlコマンドを入力し、以下のようにプロンプトが表示されればよい。

% isql -Usa -P -S<Adaptive Server名>
1> quit

% isql -Usa -P -S<Backup Server名>
1> quit
showserverによるチェック

またshowserverコマンドによっても動作を確認できる。

% $SYBASE/install/showserver
   UID ... CMD
sybase /opt/sybase/bin/backupserver -S<Backup Server名> ...
sybase /opt/sybase/bin/dataserver -s<Adaptive Server名> ...

Sybaseシステム管理者パスワードの設定

Sybaseインストール時に「sa」と呼ばれるSybaseアカウント(UNIXアカウントではない)がシステム管理者用に作成される。

「sa」でログインしたユーザはmasterデータベースを含むAdaptive Server上の全てのデータベースを完全な権限で使用できる。

新規にSybaseをインストールした場合は「sa」アカウントにパスワードが設定されていないのでここでパスワードを設定する。

% isql -Usa -P -S<Adaptive Server名>
1> sp_password null, <新規パスワード>
2> go
Password correctly set.

サーバ停止&開始確認

サーバ停止

サーバ停止はisqlコマンドを使って行う。

停止はBackup Server > Adaptive Serverの順で行う。

% isql -Usa -SAdaptive Server 名
Password: 
1> shutdown SYB_BACKUP ← Backup Server停止
2> go
Backup Server: 3.48.1.1: The Backup Server will go down immediately. 
Terminating sessions.

1> shutdown with wait ← Adaptive Server停止
2> go
Server SHUTDOWN by request.
The SQL Server is terminating this process.

shutdownコマンドを実行するとAdaptive Serverは以下の処理を行う。

システム管理者以外の(Adaptive Serverへの)ログインを無効にする。
個々のデータベースでチェックポイントを実行してメモリからディスクに移されたページをフラッシュする。
現在実行中のSQL文またはプロシージャの終了を待つ。

このようにしてshutdownはAdaptive Serverの再起動時に自動リカバリが行わなければならない作業量を最小にする。

with no_waitオプションではAdaptive Serverはただちに停止される。

ユーザプロセスはアボートされshutdown with nowaitのあとのリカバリは多少時間がかかる。

shutdown with nowaitコマンドを発行する前にcheckpointコマンドを発行するとリカバリ時間を短縮するのに役立つ。

デフォルトはwith waitであるため、進行中の全てのダンプやロードが終了してからBackup Serverのプロセスが停止する。

shutdownコマンドが発行されるとそのBackup Serverで新しいダンプセッションやロードセッションは起動できない。

使用しているAdaptive ServerからアクセスできるBackup Serverの名前を見るにはsp_helpserverを実行する。

shutdownコマンドのnameフィールドにある値を使用すること。

Backup Serverは以下の状態のときにだけ停止できる。

使用しているAdaptive Serverのsysserversにリストされている
ローカルなinterfacesファイルにリストされている

Backup Serverをsysserversに追加するにはsp_addserverコマンドを使用する。

サーバ開始

データベース初期化時にサーバ開始用スクリプトも自動生成されるのでサーバ開始にはこれを使用する。

% cd $SYBASE/install
% ./startserver -f ./RUN_<Adaptive Server名> ← Adaptive Server開始
% ./startserver -f ./RUN_<Backup Server名> ← Backup Server開始

initスクリプト設置

スクリプト作成

/etc/init.d/sybaseを作成する。

ここでは$SYBASE/installディレクトリ配下のRUN_*スクリプトを全て実行するようなスクリプトを作成する。

ただしここに示したスクリプトの場合、データベースサーバ名に`_'が含まれている場合やバックアップサーバ名に`_back'が含まれていない場合はうまく動作しないので適宜修正すること。

#!/bin/sh

SYBASE=/opt/sybase

AS_START=${SYBASE}/install/startserver

AS_LOG=${SYBASE}/install/boot_dataserver.log
AS_BKUP_LOG=${SYBASE}/install/boot_backupserver.log

DB_SERVER_LIST=`(cd ${SYBASE}/install;/bin/ls RUN_*)|grep -v _back|nawk -F'RUN_' '{print $2}'|uniq`

case "$1" in
'start')
  if [ -x ${AS_START} ]; then
    /usr/ucb/echo -n ' sybase'

    cp /dev/null ${AS_LOG}
    cp /dev/null ${AS_BKUP_LOG}

    for DB_SERVER in `echo ${DB_SERVER_LIST}`
    do
      /usr/ucb/echo -n ' <'${DB_SERVER}'>'

      AS_CONF=${SYBASE}/install/RUN_${DB_SERVER}
      AS_BKUP_CONF=${SYBASE}/install/RUN_${DB_SERVER}_back

      su - sybase -c "${AS_START} -f ${AS_CONF}" >> ${AS_LOG} 2>&1
      su - sybase -c "${AS_START} -f ${AS_BKUP_CONF}" >> ${AS_BKUP_LOG} 2>&1
    done
    echo
  fi
  ;;

'stop')
  if [ -x ${AS_START} ]; then
    /usr/ucb/echo -n ' sybase'

    for DB_SERVER in `echo ${DB_SERVER_LIST}`
    do
      /usr/ucb/echo -n ' <'${DB_SERVER}'>'
      su - sybase -c "isql -Usa -Psaadmin -S${DB_SERVER}" < /dev/null 2>&1
shutdown SYB_BACKUP
go
shutdown with wait
go
EOF
    done
    echo
  fi
  ;;

*)
  /usr/ucb/echo "Usage: `basename $0` {start|stop}" >&2
  exit 64
  ;;

esac

exit 0

スクリプト配置

# cd /etc/rc2.d
# ln -s ../init.d/sybase S77sybase

# cd /etc/rc0.d
# ln -s ../init.d/sybase K77sybase