程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SyBase數據庫 >> SyBase綜合文章 >> Sybase中代理數據庫出現混亂的解決方法

Sybase中代理數據庫出現混亂的解決方法

編輯:SyBase綜合文章

問題描述:

在Sybase Central中查看數據庫時,在數據庫目錄下沒有找到某個用戶數據庫(名字:andkylee),但是用isql連上數據庫執行sp_helpdb能夠查詢到andkylee的確存在。在Sybase Central中找了一會兒,竟然在代理數據庫目錄下找到了數據庫andkylee。很是奇怪,怎麼跑到代理數據庫裡面了。數據庫andkylee就是一個普通的用戶數據庫而已。

專題:Sybase何處去?

繼續,依次展開代理數據庫裡面的andkylee庫的目錄,卻找不到任何的用戶表。代理表目錄空空的,也沒有用戶表目錄(真正的代理數據庫中沒有用戶表)。納悶了,andkylee庫裡的用戶表都跑到哪裡去了?

不過,用其它的數據庫客戶端工具是能夠查詢到andkylee庫裡面的用戶表數據的。比如:用isql連上數據庫,進入到andkylee庫裡。sp_help可以查看到所有的對象名稱。發現用戶表都在,執行select能夠查看到表的數據。其它的比如:PowerBuilder,dbartisan裡面都能夠在tables目錄下面找到andkylee庫裡的所有表。看來,用戶數據庫andkylee沒多少異常。是普通庫而不是代理數據庫。

分析原因:

一開始,我以為是andkylee庫裡的用戶沒有關聯上登陸賬號引起的。這個情況是比較常見的。

在master庫中執行:

  1. select suid ,name from syslogins where name='escourt4' 
  1. 1> select suid ,name from syslogins where name='escourt4'    
  2. 2> go     
  3.  suid        name     
  4.  ----------- ------------------------------     
  5.            5 escourt4     
  6. (1 row affected)    
  7. 1> select suid ,name from syslogins where name='escourt4' 
  8. 2> go  
  9.  suid        name  
  10.  ----------- ------------------------------  
  11.            5 escourt4  
  12. (1 row affected) 

登錄escourt4對應的suid為:5。

在進入到用戶庫andkylee裡面。

  1. 1> use andkylee     
  2. 2> go     
  3. 1> select suid,uid,name from sysusers where name='escourt4'    
  4. 2> go     
  5.  suid        uid         name     
  6.  ----------- ----------- ------------------------------     
  7.            5           3 escourt4     
  8. (1 row affected)    
  9. 1> use andkylee  
  10. 2> go  
  11. 1> select suid,uid,name from sysusers where name='escourt4' 
  12. 2> go  
  13.  suid        uid         name  
  14.  ----------- ----------- ------------------------------  
  15.            5           3 escourt4  
  16. (1 row affected) 

可以看出庫andkylee裡面的用戶escourt4的uid為:3,它的suid為:5,正是對應的登錄escourt4的suid。這沒有問題,是正常的!

這好像和用戶數據庫andkylee沒多少關系了,到master庫裡面找找是什麼原因!

先看master的系統表sysdatabases中都存儲了關於每個數據庫的什麼信息?

sysdatabases中的各個字段的信息如下:

  1. 名稱  數據類型    說明     
  2. name    sysname     數據庫的名稱     
  3. dbid    smallint    數據庫 ID      
  4. suid    int     數據庫所有者的服務器用戶 ID      
  5. status  smallint    控制位;表1-6 中列出了用戶可以用sp_dboption 設置的控制位     
  6. version     smallint    未使用     
  7. logptr  int     指向事務日志的指針     
  8. crdate  datetime    創建日期     
  9. dumptrdate  datetime    上次執行dump transaction 時的日期     
  10. status2     smallint null   附加控制位(請參見第27 頁的表1-7)      
  11. audflags    int null    數據庫的審計設置     
  12. deftabaud   int null    為表定義缺省審計設置的位屏蔽     
  13. defvwaud    int null    為視圖定義缺省審計設置的位屏蔽     
  14. defpraud    int null    為存儲過程定義缺省審計設置的位屏蔽     
  15. def_remote_type     smallint null   在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下,指定要用於遠程表的缺省對象類型     
  16. def_remote_loc  varchar(349) null   在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下,指定要用於遠程表的缺省存儲位置     
  17. status3     int null    附加控制位     
  18. status4     int null    附加控制位     
  19. audflags2   varbinary(16) null  留作將來使用    
  20. 名稱 數據類型 說明  
  21. name  sysname  數據庫的名稱  
  22. dbid  smallint  數據庫 ID   
  23. suid  int  數據庫所有者的服務器用戶 ID   
  24. status  smallint  控制位;表1-6 中列出了用戶可以用sp_dboption 設置的控制位  
  25. version  smallint  未使用  
  26. logptr  int  指向事務日志的指針  
  27. crdate  datetime  創建日期  
  28. dumptrdate  datetime  上次執行dump transaction 時的日期  
  29. status2  smallint null  附加控制位(請參見第27 頁的表1-7)   
  30. audflags  int null  數據庫的審計設置  
  31. deftabaud  int null  為表定義缺省審計設置的位屏蔽  
  32. defvwaud  int null  為視圖定義缺省審計設置的位屏蔽  
  33. defpraud  int null  為存儲過程定義缺省審計設置的位屏蔽  
  34. def_remote_type  smallint null  在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下,指定要用於遠程表的缺省對象類型  
  35. def_remote_loc  varchar(349) null  在沒有通過存儲過程sp_addobjectdef 提供存儲位置的情況下,指定要用於遠程表的缺省存儲位置  
  36. status3  int null  附加控制位  
  37. status4  int null  附加控制位  
  38. 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. 1> use master     
  2. 2> go     
  3. 1> update sysdatabases     
  4. 2> set def_remote_locnull    
  5. 3> where dbid = db_id('andkylee')     
  6. 4> go     
  7. (1 row affected)     
  8. 1>    
  9. 1> use master  
  10. 2> go  
  11. 1> update sysdatabases  
  12. 2> set def_remote_locnull 
  13. 3> where dbid = db_id('andkylee')  
  14. 4> go  
  15. (1 row affected)  
  16. 1> 

用Sybase Central重新連接數據庫。發現用戶庫andkylee已經不在代理數據庫裡面了。問題解決了!

此問題和Sybase中的代理數據庫有關。

那麼試驗一下ASE中的代理數據庫吧!

目的:建立一個代理數據庫proxydb,引用同一ASE上另外一個用戶數據庫andkylee的用戶escourt4下所有對象。

  1. 1> disk init     
  2. 2> name='proxydb_dat',     
  3. 3> physname='d:\syb_data\proxydb_dat.dat',     
  4. 4> size='20m'    
  5. 5> go     
  6. 1> disk init     
  7. 2> name='proxydb_log',     
  8. 3> physname='d:\syb_data\proxydb_log.dat',     
  9. 4> size='10m'    
  10. 5> go     
  11. 1> create database proxydb     
  12. 2> on proxydb_dat='20m' log on proxydb_log='10m'    
  13. 3> with default_location "local.andkylee.escourt4."    
  14. 4> for proxy_update     
  15. 5> go    

  1. CREATE DATABASE: allocating 5120 logical pages (20.0 megabytes) on disk     
  2. 'proxydb_dat'.     
  3. CREATE DATABASE: allocating 2560 logical pages (10.0 megabytes) on disk     
  4. 'proxydb_log'.     
  5. Database 'proxydb' is now online.     
  6. New user added.     
  7. (1 row affected)    
  8. 1> disk init  
  9. 2> name='proxydb_dat',  
  10. 3> physname='d:\syb_data\proxydb_dat.dat',  
  11. 4> size='20m' 
  12. 5> go  
  13. 1> disk init  
  14. 2> name='proxydb_log',  
  15. 3> physname='d:\syb_data\proxydb_log.dat',  
  16. 4> size='10m' 
  17. 5> go  
  18. 1> create database proxydb  
  19. 2> on proxydb_dat='20m' log on proxydb_log='10m' 
  20. 3> with default_location "local.andkylee.escourt4." 
  21. 4> for proxy_update  
  22. 5> go  
  23. CREATE DATABASE: allocating 5120 logical pages (20.0 megabytes) on disk  
  24. 'proxydb_dat'.  
  25. CREATE DATABASE: allocating 2560 logical pages (10.0 megabytes) on disk  
  26. 'proxydb_log'.  
  27. Database 'proxydb' is now online.  
  28. New user added.  
  29. (1 row affected) 

初始化設備proxydb_dat,proxydb_log兩個設備,並建立代理數據庫proxydb。 在proxydb裡面建立指向local.andkylee.escourt4.的所有對象的代理表。

查看代理數據庫proxydb裡面的代理表的數據:

  1.  
  2. 1> use proxydb     
  3. 2> go     
  4. 1> select top 10 id,name,user_name(uid) as user_name from proxydb..sysobjects     
  5. 2> where type='U'    
  6. 3> order by name     
  7. 4> go     
  8.  id          name     
  9.  ----------- ----------------------------------------------------------------------------------     
  10.    800002850 AIX_PAGENOS     
  11.    832002964 AIX_PAGENO_RANGE     
  12.    864003078 AIX_SYS_syscolumns     
  13.    896003192 AIX_SYS_sysindexes     
  14.    928003306 AIX_SYS_sysobjects     
  15.    960003420 AJDACG     
  16.    992003534 AJDAJY     
  17.   1024003648 AJGDB     
  18.   1104003933 AJGDB1     
  19.   1168004161 AJGDB_BAKUP     
  20. (10 rows affected)     
  21. 1> select count(*) from escourt4.AJGDB1     
  22. 2> GO     
  23.  -----------     
  24.       123611     
  25. (1 row affected)    
  26. 1> use proxydb  
  27. 2> go  
  28. 1> select top 10 id,name,user_name(uid) as user_name from proxydb..sysobjects  
  29. 2> where type='U' 
  30. 3> order by name 
  31. 4> go  
  32.  id          name 
  33.  ----------- ----------------------------------------------------------------------------------  
  34.    800002850 AIX_PAGENOS  
  35.    832002964 AIX_PAGENO_RANGE  
  36.    864003078 AIX_SYS_syscolumns  
  37.    896003192 AIX_SYS_sysindexes  
  38.    928003306 AIX_SYS_sysobjects  
  39.    960003420 AJDACG  
  40.    992003534 AJDAJY  
  41.   1024003648 AJGDB  
  42.   1104003933 AJGDB1  
  43.   1168004161 AJGDB_BAKUP  
  44. (10 rows affected)  
  45. 1> select count(*) from escourt4.AJGDB1  
  46. 2> GO  
  47.  -----------  
  48.       123611  
  49. (1 row affected) 

代理數據庫創建成功了!

作者簡介:andkylee,5年Sybase管理、維護經驗。現任職於北京一IT運維管理公司,Sybase DBA。熟悉Sybase的安裝、配置、調優、監控與排錯,尤其精通Sybase數據庫的災難恢復。自己深入研究Sybase數據庫的內部物理存儲結構,開發了能夠從Sybase數據庫設備文件中提取數據的工具;還編寫了一個能夠分析Sybase日志文件內容,反解析出相應SQL語句的程序。可以提供Sybase數據庫非常規恢復技術支持。Sybase非常規數據庫恢復包括:設備文件故障(如:頁面邏輯損壞,頁面物理損壞等,605、692錯誤等等),誤操作(包括:誤更新update,誤刪除drop table,誤清空數據truncate table,等)等,本人都有相應的處理辦法。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved