問題描述:
在Sybase Central中查看數據庫時,在數據庫目錄下沒有找到某個用戶數據庫(名字:andkylee),但是用isql連上數據庫執行sp_helpdb能夠查詢到andkylee的確存在。在Sybase Central中找了一會兒,竟然在代理數據庫目錄下找到了數據庫andkylee。很是奇怪,怎麼跑到代理數據庫裡面了。數據庫andkylee就是一個普通的用戶數據庫而已。
繼續,依次展開代理數據庫裡面的andkylee庫的目錄,卻找不到任何的用戶表。代理表目錄空空的,也沒有用戶表目錄(真正的代理數據庫中沒有用戶表)。納悶了,andkylee庫裡的用戶表都跑到哪裡去了?
不過,用其它的數據庫客戶端工具是能夠查詢到andkylee庫裡面的用戶表數據的。比如:用isql連上數據庫,進入到andkylee庫裡。sp_help可以查看到所有的對象名稱。發現用戶表都在,執行select能夠查看到表的數據。其它的比如:PowerBuilder,dbartisan裡面都能夠在tables目錄下面找到andkylee庫裡的所有表。看來,用戶數據庫andkylee沒多少異常。是普通庫而不是代理數據庫。
分析原因:
一開始,我以為是andkylee庫裡的用戶沒有關聯上登陸賬號引起的。這個情況是比較常見的。
在master庫中執行:
- select suid ,name from syslogins where name='escourt4'
- 1> select suid ,name from syslogins where name='escourt4'
- 2> go
- suid name
- ----------- ------------------------------
- 5 escourt4
- (1 row affected)
- 1> select suid ,name from syslogins where name='escourt4'
- 2> go
- suid name
- ----------- ------------------------------
- 5 escourt4
- (1 row affected)
登錄escourt4對應的suid為:5。
在進入到用戶庫andkylee裡面。
- 1> use andkylee
- 2> go
- 1> select suid,uid,name from sysusers where name='escourt4'
- 2> go
- suid uid name
- ----------- ----------- ------------------------------
- 5 3 escourt4
- (1 row affected)
- 1> use andkylee
- 2> go
- 1> select suid,uid,name from sysusers where name='escourt4'
- 2> go
- suid uid name
- ----------- ----------- ------------------------------
- 5 3 escourt4
- (1 row affected)
可以看出庫andkylee裡面的用戶escourt4的uid為:3,它的suid為:5,正是對應的登錄escourt4的suid。這沒有問題,是正常的!
這好像和用戶數據庫andkylee沒多少關系了,到master庫裡面找找是什麼原因!
先看master的系統表sysdatabases中都存儲了關於每個數據庫的什麼信息?
sysdatabases中的各個字段的信息如下:
- 名稱 數據類型 說明
- name sysname 數據庫的名稱
- dbid smallint 數據庫 ID
- suid int 數據庫所有者的服務器用戶 ID
- status smallint 控制位;表1-6 中列出了用戶可以用sp_dboption 設置的控制位
- version smallint 未使用
- logptr int 指向事務日志的指針
- crdate datetime 創建日期
- dumptrdate datetime 上次執行dump transaction 時的日期
- status2 smallint null 附加控制位(請參見第27 頁的表1-7)
- audflags int null 數據庫的審計設置
- deftabaud int null 為表定義缺省審計設置的位屏蔽
- defvwaud int null 為視圖定義缺省審計設置的位屏蔽
- defpraud int null 為存儲過程定義缺省審計設置的位屏蔽
- def_remote_type smallint null 在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下,指定要用於遠程表的缺省對象類型
- def_remote_loc varchar(349) null 在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下,指定要用於遠程表的缺省存儲位置
- status3 int null 附加控制位
- status4 int null 附加控制位
- audflags2 varbinary(16) null 留作將來使用
- 名稱 數據類型 說明
- name sysname 數據庫的名稱
- dbid smallint 數據庫 ID
- suid int 數據庫所有者的服務器用戶 ID
- status smallint 控制位;表1-6 中列出了用戶可以用sp_dboption 設置的控制位
- version smallint 未使用
- logptr int 指向事務日志的指針
- crdate datetime 創建日期
- dumptrdate datetime 上次執行dump transaction 時的日期
- status2 smallint null 附加控制位(請參見第27 頁的表1-7)
- audflags int null 數據庫的審計設置
- deftabaud int null 為表定義缺省審計設置的位屏蔽
- defvwaud int null 為視圖定義缺省審計設置的位屏蔽
- defpraud int null 為存儲過程定義缺省審計設置的位屏蔽
- def_remote_type smallint null 在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下,指定要用於遠程表的缺省對象類型
- def_remote_loc varchar(349) null 在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下,指定要用於遠程表的缺省存儲位置
- status3 int null 附加控制位
- status4 int null 附加控制位
- audflags2 varbinary(16) null 留作將來使用
def_remote_loc存儲著遠程表的默認存儲位置。
用Interactive SQL查看系統表sysdatabases的數據(不用PowerBuilder的原因是:查詢結果中區分不了null和空串)。
仔細比較sysdatabases中各個數據庫的信息。發現andkylee對應的ref_remote_loc值非null,而其它庫對應的ref_remote_loc值都為null。
難道原因在這裡?
解決辦法:
將庫andkylee在sysdatabases表中對應的ref_remote_loc的值改為:null。
- 1> use master
- 2> go
- 1> update sysdatabases
- 2> set def_remote_loc= null
- 3> where dbid = db_id('andkylee')
- 4> go
- (1 row affected)
- 1>
- 1> use master
- 2> go
- 1> update sysdatabases
- 2> set def_remote_loc= null
- 3> where dbid = db_id('andkylee')
- 4> go
- (1 row affected)
- 1>
用Sybase Central重新連接數據庫。發現用戶庫andkylee已經不在代理數據庫裡面了。問題解決了!
此問題和Sybase中的代理數據庫有關。
那麼試驗一下ASE中的代理數據庫吧!
目的:建立一個代理數據庫proxydb,引用同一ASE上另外一個用戶數據庫andkylee的用戶escourt4下所有對象。
- 1> disk init
- 2> name='proxydb_dat',
- 3> physname='d:\syb_data\proxydb_dat.dat',
- 4> size='20m'
- 5> go
- 1> disk init
- 2> name='proxydb_log',
- 3> physname='d:\syb_data\proxydb_log.dat',
- 4> size='10m'
- 5> go
- 1> create database proxydb
- 2> on proxydb_dat='20m' log on proxydb_log='10m'
- 3> with default_location "local.andkylee.escourt4."
- 4> for proxy_update
- 5> go
- CREATE DATABASE: allocating 5120 logical pages (20.0 megabytes) on disk
- 'proxydb_dat'.
- CREATE DATABASE: allocating 2560 logical pages (10.0 megabytes) on disk
- 'proxydb_log'.
- Database 'proxydb' is now online.
- New user added.
- (1 row affected)
- 1> disk init
- 2> name='proxydb_dat',
- 3> physname='d:\syb_data\proxydb_dat.dat',
- 4> size='20m'
- 5> go
- 1> disk init
- 2> name='proxydb_log',
- 3> physname='d:\syb_data\proxydb_log.dat',
- 4> size='10m'
- 5> go
- 1> create database proxydb
- 2> on proxydb_dat='20m' log on proxydb_log='10m'
- 3> with default_location "local.andkylee.escourt4."
- 4> for proxy_update
- 5> go
- CREATE DATABASE: allocating 5120 logical pages (20.0 megabytes) on disk
- 'proxydb_dat'.
- CREATE DATABASE: allocating 2560 logical pages (10.0 megabytes) on disk
- 'proxydb_log'.
- Database 'proxydb' is now online.
- New user added.
- (1 row affected)
初始化設備proxydb_dat,proxydb_log兩個設備,並建立代理數據庫proxydb。 在proxydb裡面建立指向local.andkylee.escourt4.的所有對象的代理表。
查看代理數據庫proxydb裡面的代理表的數據:
- 1> use proxydb
- 2> go
- 1> select top 10 id,name,user_name(uid) as user_name from proxydb..sysobjects
- 2> where type='U'
- 3> order by name
- 4> go
- id name
- ----------- ----------------------------------------------------------------------------------
- 800002850 AIX_PAGENOS
- 832002964 AIX_PAGENO_RANGE
- 864003078 AIX_SYS_syscolumns
- 896003192 AIX_SYS_sysindexes
- 928003306 AIX_SYS_sysobjects
- 960003420 AJDACG
- 992003534 AJDAJY
- 1024003648 AJGDB
- 1104003933 AJGDB1
- 1168004161 AJGDB_BAKUP
- (10 rows affected)
- 1> select count(*) from escourt4.AJGDB1
- 2> GO
- -----------
- 123611
- (1 row affected)
- 1> use proxydb
- 2> go
- 1> select top 10 id,name,user_name(uid) as user_name from proxydb..sysobjects
- 2> where type='U'
- 3> order by name
- 4> go
- id name
- ----------- ----------------------------------------------------------------------------------
- 800002850 AIX_PAGENOS
- 832002964 AIX_PAGENO_RANGE
- 864003078 AIX_SYS_syscolumns
- 896003192 AIX_SYS_sysindexes
- 928003306 AIX_SYS_sysobjects
- 960003420 AJDACG
- 992003534 AJDAJY
- 1024003648 AJGDB
- 1104003933 AJGDB1
- 1168004161 AJGDB_BAKUP
- (10 rows affected)
- 1> select count(*) from escourt4.AJGDB1
- 2> GO
- -----------
- 123611
- (1 row affected)
代理數據庫創建成功了!
作者簡介:andkylee,5年Sybase管理、維護經驗。現任職於北京一IT運維管理公司,Sybase DBA。熟悉Sybase的安裝、配置、調優、監控與排錯,尤其精通Sybase數據庫的災難恢復。自己深入研究Sybase數據庫的內部物理存儲結構,開發了能夠從Sybase數據庫設備文件中提取數據的工具;還編寫了一個能夠分析Sybase日志文件內容,反解析出相應SQL語句的程序。可以提供Sybase數據庫非常規恢復技術支持。Sybase非常規數據庫恢復包括:設備文件故障(如:頁面邏輯損壞,頁面物理損壞等,605、692錯誤等等),誤操作(包括:誤更新update,誤刪除drop table,誤清空數據truncate table,等)等,本人都有相應的處理辦法。