Sybase Central中代理数据库分类出错的问题解决

---------------------------------------------------------------------------

---- 本文为andkylee个人原创，请在尊重作者劳动成果的前提下进行转载；

---- 转载务必注明原始出处 : http://blog.csdn.net/andkylee

--- 2010-07-02 15:18:00

---- 关键字： Sybase Central proxy database 代理表 代理数据库

----------------------------------------------------------------------------

问题描述：

在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)

登录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)

可以看出库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 留作将来使用

 

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>

用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)

初始化设备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)

代理数据库创建成功了！