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やトリガなどのオブジェクトについても存在しないものを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
サーバ設定ファイル(
ログファイルには以下のようなエラーが出力されている。
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エントリで指定されているポート番
号
例)
% 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
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が正しい値に設定されていない。
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