掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
問題描述：
成都創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供和靜網(wǎng)站建設(shè)、和靜做網(wǎng)站、和靜網(wǎng)站設(shè)計、和靜網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、和靜企業(yè)網(wǎng)站模板建站服務(wù)，十余年和靜做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
在Sybase Central中查看數(shù)據(jù)庫時，在數(shù)據(jù)庫目錄下沒有找到某個用戶數(shù)據(jù)庫（名字：andkylee），但是用isql連上數(shù)據(jù)庫執(zhí)行sp_helpdb能夠查詢到andkylee的確存在。在Sybase Central中找了一會兒，竟然在代理數(shù)據(jù)庫目錄下找到了數(shù)據(jù)庫andkylee。很是奇怪，怎么跑到代理數(shù)據(jù)庫里面了。數(shù)據(jù)庫andkylee就是一個普通的用戶數(shù)據(jù)庫而已。
繼續(xù)，依次展開代理數(shù)據(jù)庫里面的andkylee庫的目錄，卻找不到任何的用戶表。代理表目錄空空的，也沒有用戶表目錄（真正的代理數(shù)據(jù)庫中沒有用戶表）。納悶了，andkylee庫里的用戶表都跑到哪里去了？
不過，用其它的數(shù)據(jù)庫客戶端工具是能夠查詢到andkylee庫里面的用戶表數(shù)據(jù)的。比如：用isql連上數(shù)據(jù)庫，進(jìn)入到andkylee庫里。sp_help可以查看到所有的對象名稱。發(fā)現(xiàn)用戶表都在，執(zhí)行select能夠查看到表的數(shù)據(jù)。其它的比如：powerbuilder，dbartisan里面都能夠在tables目錄下面找到andkylee庫里的所有表?？磥?，用戶數(shù)據(jù)庫andkylee沒多少異常。是普通庫而不是代理數(shù)據(jù)庫。
分析原因：
一開始，我以為是andkylee庫里的用戶沒有關(guān)聯(lián)上登陸賬號引起的。這個情況是比較常見的。
在master庫中執(zhí)行：
- 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對應(yīng)的suid為：5。
在進(jìn)入到用戶庫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，正是對應(yīng)的登錄escourt4的suid。這沒有問題，是正常的！
這好像和用戶數(shù)據(jù)庫andkylee沒多少關(guān)系了，到master庫里面找找是什么原因!
先看master的系統(tǒng)表sysdatabases中都存儲了關(guān)于每個數(shù)據(jù)庫的什么信息？
sysdatabases中的各個字段的信息如下：
- 名稱 數(shù)據(jù)類型 說明
- name sysname 數(shù)據(jù)庫的名稱
- dbid smallint 數(shù)據(jù)庫 ID
- suid int 數(shù)據(jù)庫所有者的服務(wù)器用戶 ID
- status smallint 控制位；表1-6 中列出了用戶可以用sp_dboption 設(shè)置的控制位
- version smallint 未使用
- logptr int 指向事務(wù)日志的指針
- crdate datetime 創(chuàng)建日期
- dumptrdate datetime 上次執(zhí)行dump transaction 時的日期
- status2 smallint null 附加控制位（請參見第27 頁的表1-7）
- audflags int null 數(shù)據(jù)庫的審計設(shè)置
- deftabaud int null 為表定義缺省審計設(shè)置的位屏蔽
- defvwaud int null 為視圖定義缺省審計設(shè)置的位屏蔽
- defpraud int null 為存儲過程定義缺省審計設(shè)置的位屏蔽
- def_remote_type smallint null 在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下，指定要用于遠(yuǎn)程表的缺省對象類型
- def_remote_loc varchar(349) null 在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下，指定要用于遠(yuǎn)程表的缺省存儲位置
- status3 int null 附加控制位
- status4 int null 附加控制位
- audflags2 varbinary(16) null 留作將來使用
- 名稱 數(shù)據(jù)類型 說明
- name sysname 數(shù)據(jù)庫的名稱
- dbid smallint 數(shù)據(jù)庫 ID
- suid int 數(shù)據(jù)庫所有者的服務(wù)器用戶 ID
- status smallint 控制位；表1-6 中列出了用戶可以用sp_dboption 設(shè)置的控制位
- version smallint 未使用
- logptr int 指向事務(wù)日志的指針
- crdate datetime 創(chuàng)建日期
- dumptrdate datetime 上次執(zhí)行dump transaction 時的日期
- status2 smallint null 附加控制位（請參見第27 頁的表1-7）
- audflags int null 數(shù)據(jù)庫的審計設(shè)置
- deftabaud int null 為表定義缺省審計設(shè)置的位屏蔽
- defvwaud int null 為視圖定義缺省審計設(shè)置的位屏蔽
- defpraud int null 為存儲過程定義缺省審計設(shè)置的位屏蔽
- def_remote_type smallint null 在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下，指定要用于遠(yuǎn)程表的缺省對象類型
- def_remote_loc varchar(349) null 在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下，指定要用于遠(yuǎn)程表的缺省存儲位置
- status3 int null 附加控制位
- status4 int null 附加控制位
- audflags2 varbinary(16) null 留作將來使用
def_remote_loc存儲著遠(yuǎn)程表的默認(rèn)存儲位置。
用Interactive SQL查看系統(tǒng)表sysdatabases的數(shù)據(jù)（不用PowerBuilder的原因是：查詢結(jié)果中區(qū)分不了null和空串）。
仔細(xì)比較sysdatabases中各個數(shù)據(jù)庫的信息。發(fā)現(xiàn)andkylee對應(yīng)的ref_remote_loc值非null，而其它庫對應(yīng)的ref_remote_loc值都為null。
難道原因在這里？
解決辦法：
將庫andkylee在sysdatabases表中對應(yīng)的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重新連接數(shù)據(jù)庫。發(fā)現(xiàn)用戶庫andkylee已經(jīng)不在代理數(shù)據(jù)庫里面了。問題解決了！
此問題和sybase中的代理數(shù)據(jù)庫有關(guān)。
那么試驗一下ASE中的代理數(shù)據(jù)庫吧！
目的：建立一個代理數(shù)據(jù)庫proxydb，引用同一ASE上另外一個用戶數(shù)據(jù)庫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)
初始化設(shè)備proxydb_dat,proxydb_log兩個設(shè)備，并建立代理數(shù)據(jù)庫proxydb。 在proxydb里面建立指向local.andkylee.escourt4.的所有對象的代理表。
查看代理數(shù)據(jù)庫proxydb里面的代理表的數(shù)據(jù)：
- 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)
代理數(shù)據(jù)庫創(chuàng)建成功了！
作者簡介：andkylee,5年Sybase管理、維護(hù)經(jīng)驗。現(xiàn)任職于北京一IT運維管理公司，Sybase DBA。熟悉Sybase的安裝、配置、調(diào)優(yōu)、監(jiān)控與排錯，尤其精通Sybase數(shù)據(jù)庫的災(zāi)難恢復(fù)。自己深入研究Sybase數(shù)據(jù)庫的內(nèi)部物理存儲結(jié)構(gòu)，開發(fā)了能夠從Sybase數(shù)據(jù)庫設(shè)備文件中提取數(shù)據(jù)的工具；還編寫了一個能夠分析Sybase日志文件內(nèi)容，反解析出相應(yīng)SQL語句的程序。可以提供Sybase數(shù)據(jù)庫非常規(guī)恢復(fù)技術(shù)支持。Sybase非常規(guī)數(shù)據(jù)庫恢復(fù)包括：設(shè)備文件故障（如：頁面邏輯損壞，頁面物理損壞等，605、692錯誤等等），誤操作（包括：誤更新update，誤刪除drop table，誤清空數(shù)據(jù)truncate table，等）等，本人都有相應(yīng)的處理辦法。
鏈接：http://blog.csdn.net/andkylee/archive/2010/07/02/5709340.aspx
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動版官網(wǎng)