问题描述：
在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，等）等，本人都有相应的处理办法。
原文标题： Sybase Central中代理数据库分类出错的问题解决
链接：http://blog.csdn.net/andkylee/archive/2010/07/02/5709340.aspx
【编辑推荐】
