5. 災難恢復篇
5.1 數據庫服務不能啓動
5.1.1 如何查找數據庫啓動失敗原因
在實際環境中，數據庫Server無法啓動的原因很多，本文僅列出了幾種常見的情況，供您參考。
首先，應檢查Server的日誌文件。不同版本缺省的日誌文件如下（其中<server_name>爲Sybase Server的名稱：
UNIX:
11.0*: $SYBASE/install/errorlog
11.5* 或 11.9*: $SYBASE/install/<server_name>.log
12.0*:$SYBASE/ $SYBASE_ASE/install/<server_name>.log
NT:
11.0* 11.5* 或 11.9*: %SYBASE%\install\errorlog
12.0*: %SYBASE%\ASE-12_0\install\errorlog
? CASE 1:
basis_dlock: file '/sybase/master.dat' already in use by a SQL Server
kernel kdconfig: unable to read primary master device
kernel kiconfig: read of config block failed
檢查server是否已經啓動( showserver, ps -u sybase 或NT service )
? CASE 2:
dopen: open '/sybase/master.dat' failed, permission denied
kernel kdconfig: unable to read primary master device
kernel kiconfig: read of config block failed
檢查master設備文件的所有者及權限
? CASE 3:
ninit: All master network listeners have failed. Shutting down
檢查network ip 及 port配置 ( netstat -a )
? CASE 4:
kernel:kscsinit: connectivity library error. Operation: cs_ctx_alloc().
o 檢查操作系統參數是否已經修改並重新啓動操作系統 (參見安裝手冊)
若操作系統異常宕機，ASE未啓動而$SYBASE/<server_name>.krg已經存在, 刪除該文件
5.1.2 簡單故障及排除方法
? 服務器啓動失敗，報告不能創建共享內存（UNIX平臺）：
解決方法：
檢查Sybase主目錄下的文件，將所有文件的所有者改爲sybase帳戶。
編輯sybase主目錄下的名爲ServerName.cfg文件，找到total memory的一行，檢查其配置值是否過大。
重新啓動數據庫服務器。
? 服務器啓動失敗，報告不能建立網絡監聽（UNIX平臺）：
解決方法：
編輯Sybase主目錄下的名爲interfaces文件，檢查相應服務器的網絡端口是否和其它的服務器重複或使用的是系統已經使用的端口；
檢查/etc/hosts的主機名和IP地址，對照interfaces中的主機名，是否存在衝突。
重新啓動數據庫服務器。
? 服務器啓動失敗，報告不能打開master設備文件（UNIX平臺）：
解決方法：
檢查$SYBASE/$SYBASE_ASE/RUN_ServerName中的master設備文件的位置；
檢查master設備文件路徑及訪問權限；
重新啓動數據庫服務器。
5.1.3 master數據庫日誌滿了,server無法啓動,怎麼辦 (error 1105)
[ERROR]
Can't allocate space for object 'syslogs' in database 'master' because the 'system' segment is full.
If you ran out of space in syslogs, dump the transaction log. Otherwise, use ALTER DATABASE or sp_extendsegment
to increase the size of the segment.
[WORKAROUND]
1.在RUN_servername的文件中添加標識 : -T3607
(編輯RUN_servername文件,在文件末尾添加以上標識)
2.啓動ASE
(要直接運行文件RUN_servername,且該運行窗口在執行以下操作時不能關閉)
3.截斷日誌
1>dump tran master with no_log
2>go
4.停止ASE服務
1>shutdown
2>go
5.刪除RUN_servername文件末尾的標識 : -T3607
6.重新啓動ASE
5.1.4 SQL Server 10.x配置內存過大、Server不能啓動時怎麼辦？
SQL Server使用的內存與機器的內存總數有一定的比例關係。如果Server使用內存太小，影響到SQL Server的性能，但內存配置過大超過一定比例時，導致SQL Server不能啓動。
在ISQL中，用sp_configure “memory”可以看到你的Server現在使用的內存大小。這個數字單位爲Page，每一個Page爲2K。參數memory在啓動Server時被讀入內存。所以memory被修改之後，必須shutdown Server，再重新啓動Server，新的參數才生效。
1>sp_configure "memory",number_of_memory
2>go
1>reconfigure with override
2>go
1>shutdown with nowait
2>go
如果新的內存配置太大，SQL Server不能啓動，那麼必須修改Master設備上的內存配置參數。
在$SYBASE/install目錄下，使用buildmaster命令
$buildmaster -d/path/master.dat -y cmemsize = XXX
其中XXX爲內存頁數。如果新的內存大小合適，SQL Server可以啓動。
5.2 數據庫被掛起
5.2.1 如何解決數據庫被掛起的問題(error 926)
現象：Error 926
Severity Level 14
Error Message Text
Database 'xx' cannot be opened - it has been marked SUSPECT by recover Explanation
(1) 當你使用Transact_SQL命令操作這個數據庫的數據時, 出現這個信息, 這是一個嚴重的錯誤, 如果你要使用這個數據庫的數據, 必須改正這個錯誤.
(2) 啓動Backup Server, 後備master數據庫
1>dump database master to "/usr/sybase/master.dup"
2>go
(3) 用isql登錄到ASE, 須用sa帳號 (本文以pubs2數據庫爲例)
1>sp_configure "allow updates", 1
2>go
1>begin tran
2>go
1>use master
2>go
1>update sysdatabases
2>set status = -32768
3>Where name="pubs2"
4>go
如果得到(1 row affected),則
1>commit
2>go
否則
1>rollback
2>go
(4)重新啓動ASE.
注：ASE重新啓動之後，當發現數據庫本身存在不可恢復的問題時，如數據頁損壞等，且沒有完好的數據庫備份，一定要用bcp...out備份用戶數據庫數據。此時，以下步驟省略，並按照“如何刪除壞的用戶數據庫”文章刪除此數據庫。之後重建此數據庫，恢復備份。
否則，按以下步驟繼續操作：
用sa帳號註冊到ASE.
1>begin tran
2>go
1>use master
2>go
1>update sysdatabases
2>set status=0
3>Where name="pubs2"
4>go
如果得到(1 row affected),則
1>commit
2>go
否則
1>rollback
2>go
1>sp_configure "allow updates" ,0
2>go
(5)重新啓動ASE.
(6) 如果你的數據庫原來有dboption(例如"select into","trunc log on chkpt"等), 你需要重新設置這些option.
(7) 當數據庫已經恢復可使用狀態後，運行dbcc命令檢查數據庫的一致性(參照“如何檢查數據庫中數據一致性”文章)
(8) 備份用戶數據庫
例如：
1>dump database pubs2 to "/usr/sybase/pubs2.dup"
2>go
5.2.2 如何做 rebuild log
注意：這個過程可能會引起數據的不一致性。
(1)賦予sa用戶sybase_ts_role的角色
isql -Usa -P
1>sp_role "grant","sybase_ts_role",sa
2>go
1>quit
(2)將數據庫置爲"bypass recovery"狀態
isql -Usa -P
1>sp_configure "allow updates",1
2>go
1>use master
2>go
1>update sysdatabases set status=-32768
2>where name="database_name"
3>go
1>shutdown with nowait
2>go
(3)rebuild數據庫日誌
isql -Usa -P
1>use master
2>go
1>dbcc rebuild_log(database_name,1,1)
2>go
1>shutdown with nowait
2>go
(4)重啓ASE
1>use master
2>go
1>update sysdatabases set status=0 where name="database_name"
2>go
1>sp_configure "allow updates",0
2>go
1>shutdown with nowait
2>go
(5)在重啓ASE之後,如果數據庫恢復正常，rebuild log工作將會成功完成，否則要恢復數據庫備份，使用dump database或bcp命令。
5.3 數據庫恢復
5.3.1 如何刪除壞的用戶數據庫？(以pubs2爲例)
當使用drop database無法刪除數據庫時，使用本文所示方法可以刪除。
(1)使用isql以sa註冊ASE
(2)設置允許修改系統表
1>sp_configure "allow updates",1
2>go
(3)把 要刪除的用戶數據庫置爲"suspect"狀態
1>use master
2>go
1>begin tran
2>go
1>update sysdatabases set status=256
2>where name="pubs2"
3>go
如果得到(1 row affected),則
1>commit
2>go
否則
1>rollback
2>go
(4)重啓server,並用isql以sa註冊。
(5)刪除數據庫
1>dbcc dbrepair(pubs2,dropdb)
2>go
(6)恢復允許修改系統表
1>sp_configure "allow updates",0
2>go
(7)結束
5.3.2 如何做Rebuild Master
提示1：
如果有可能，在執行這個任務之前，請先做操作系統級SYBASE DEVICES的後備。UNIX操作系統可使用命令"dd"。因爲如果disk reinit使用了錯誤的信息，那麼，在執行了disk refit之後就會產生無法彌補的錯誤。倘若，存在一個SYBASE DEVICES的後備文件，將會給我們一個彌補的機會。例如：當disk reinit 使用了過小的size值，我們還可以重新恢復SYBASE DEVICES文件，重新做disk reint、disk refit。
提示2：
在使用disk reinit命令時，將覆蓋SYBASE DEVICE（請參照以下語法），安全的做法是size值使用裸分區或系統文件的大小的最大值。如果使用的是UNIX裸分區，即使你不能確認SYBASE DEVICE最初大小是不是最大值，都要使用裸分區大小的最大值。
步驟：
? 獲得將要被恢復的SYBASE DEVICE的信息。
這些信息被用來重建sysdevices,sysusages以及sysdatabases。
? 從error log的server啓動信息中獲得SYBASE DEVICE的設備名、指定路徑。
? 使用裸分區或系統文件的大小的最大值作爲SYBASE DEVICE的
大小。
? 以上信息也可以通過最近的sysdevices系統表的內容來獲得。如果
對此信息懷有疑問，還是使用以上的方法比較穩妥。
? 做操作系統級的SYBASE DEVICE後備。UNIX操作系統，使用"dd"命令實現。
? 配置一個新的ASE Server。在以後的步驟中會用到這個新的master。
? 如果需要，請再配置一個Backup Server。
? 用單用戶模式啓動Server。
? 運行disk reinit，用來重建sysdevices系統表，而沒有重新初始化SYBASE DEVICE。
語法如下：
disk reinit
name="device_name",
physname="physical_name",
vdevno=virtual_device_number,
size=number_of_blocks
完成後，請查看error log。
? 確認重建的sysdevices系統表中信息正確：
——select * from sysdevices
比較表中的信息是否與error log或者保留的sysdevices中的信息相同。
? 運行disk refit,用來重建sysdevices以及sysdatabases。
用法如下：
use master
go
disk refit
go
查看error log中是否有錯誤提示。
? 當disk refit完成後，會自動shut down ASE Server。
? 確認重建的系統表的信息是否正確：
——單用戶模式啓動ASE Server
——select * from sysusages、select * from sysdatabases
——sysusages系統表看起來是否正確？可以和以前保留的的信息進行比較。如果沒有這種可能，那麼應該保證不出現顯而易見的錯誤。例如：是否缺少dbid；是否缺行；是否對於一個數據庫來說只有segmap=4(表示爲日誌行)的行等等。
——sysdatabases系統表看起來是否正確？是不是沒有顯而易見的錯誤？
11、 啓動ASE Server，查看是否所有的數據庫都已經正常恢復。
? 對所有的庫做dbcc檢查。
? 對所有庫做後備。
請參考《Trouble Shooting Guide》
5.3.3 如何恢復master數據庫
ASE can't setup and has no valid dump of master
1、編輯RUN_servername
在命令行最後加入：-T3607
2、單用戶模式啓動ASE
$cd install
$startserver -f RUN_servername -m
3、bcp out系統表
$bcp master..sysdevices out /directory.spec/devs -Usa -P -c
$bcp master..sysdatabases out /directory.spec/dbs -Usa -P -c
$bcp master..sysusages out /directory.spec/usages -Usa -P -c
$bcp master..syslogins out /directory.spec/logins -Usa -P -c
$bcp master..sysconfigures out /directory.spec/configures -Usa -P -c
$bcp master..syscharsets out /directory.spec/charsets -Usa -P -c
4、shutdownASE
5、創建新master設備
$buildmaster -d<path_to_new_master_device> -s<new_master_device_size>
(new_master_device_size以2K爲單位)
6、編輯RUN_servername
將指定master設備指定爲新創建的master設備，並刪除在第1步中增加的參數。
7、刪除/directory.spec/dbs、/directory.spec/usages文件中有關master、tempdb、model的內容。
8、單用戶模式啓動ASE
$cd install
$startserver -f RUN_servername -m
9、 bcp in系統表
$ bcp master..sysdevices in /directory.spec/devs -Usa -P -b 1 -c
$bcp master..sysdatabases in /directory.spec/dbs -Usa -P -b 1 -c
$bcp master..sysusages in /directory.spec/usages -Usa -P -b 1 -c
$bcp master..syslogins in /directory.spec/logins -Usa -P -b 1 -c
$bcp master..sysconfigures in /directory.spec/configures -Usa -P -b 1 -c
$bcp master..syscharsets in /directory.spec/charsets -Usa -P -b 1 -c
10、shudown ASE
11、執行installmaster腳本
$isql -Usa -P < $SYBASE/scripts/installmaster
12、啓動ASE
5.3.4 如何移植master設備
以下步驟說明了如何將master設備移植到不同的磁盤上。在執行此項任務的同時，請參看SYBASE的相關文檔（Technical Documents#1324 entitled "Segment Remapping with Load database When Moving a Database"）。請注意，在執行buildmaster之前，要停止ASE的應用。
成功的關鍵在於，新建的sysusages系統表中每一行內容與舊的sysusages系統表內容相符。
? 對master庫做dbcc檢查，並後備master庫。
? 執行select * from table_name命令，並保留其輸出內容。其中，table_name包括：sysdevices、sysusages、sysdatabases。同樣，可以使用bcp命令來實現。
? 執行sp_configure命令，並保留其輸出內容。
? 拷貝$SYBASE/server_name.cfg文件，以做保留。
? Shut down SQL/ASE Server。
? 執行以下命令，創建一個新的master設備：
UNIX：buildmaster -d<master_device> -ssize
VMS：buildmaster /disk=<master_device> /size=size
(size以頁爲單位，1頁=2K)
? 編輯RUN_server_name文件,-d(UNIX)或/device(VMS)參數指向新建的設
備名。
? 單用戶模式啓動SQL/ASE Server：
UNIX：startserver -f RUN_sever_name -m
VMS：startserver /server=server_name /masterrecover
? 執行select * from sysdevices命令，並保留其輸出內容。
? 確認新建的sysusages系統表中每一行內容與舊的sysusages系統表內容相符，而且在配置好Server之後，沒有做過alter database，那麼系統表sysusages的內容是正確的。如果做過alter database,則要按原來的順序執行這些腳本，如果沒有腳本，就要到保存的sysusages系統表的信息中找到alter database的參數。
? Shutdown SQL/ASE Server，並用單用戶模式啓動Server，查看sysusages系統表內容是否正確。
? 如果所配置的Backup Server名稱不是SYB_BACKUP,則要執行：
1> sp_configure "allow updates",1
2> go
1> update sysservers set srvnetname="name in interfaces file"
where srvname="SYB_BACKUP"
2> go
? 裝載master庫。如果新master設備的大小與舊設備大小不同，則Server會Shut down。請注意新的系統表將會被重寫，而且你需要調整Sysdevices系統表中master設備的大小。請執行以下兩步：
? 用單用戶模式啓動Server.
? 如果新設備大小與舊設備大小不同，請執行：
1> sp_configure "allow updates",1
2> go
1> update sysdevices set high=nnnn where name="master"
2> go
其中nnnn是以頁（2K）爲單位的master設備的大小，此值可以從保留的sysdevices系統表的信息中找到。如果所建的設備比舊設備大，請執行：1）創建一個與master設備差不多大的數據庫，這樣做的目的是重新初始化分配頁，使得整個master設備可用。2）刪除這個數據庫。
? 重啓Server。
? 後備master數據庫。
注意：
? 在裝載master庫之前要確定ASE此時的字符集和語言模塊與後備master庫時的字符集和語言模塊相同。
? 在執行此任務之前和完成以後使用sp_helpsort查看字符集與語言模塊是否相同。
5.3.5 如何重建sybsystemprocs系統數據庫
依照以下步驟可以實現移動sybsystemprocs系統數據庫以及設備的任務。同時這個過程也可以用來擴建sybsystemprocs系統數據庫。
以下過程中所提到的語法結構，可以參看SYBASE相關資料。
SYBASE提醒您，在修改系統表時，ASE要以單用戶模式運行，同時要以"sa"用戶登錄。
? 保留駐留在sybsystemprocs系統數據庫中自定義的存儲過程腳本。
? 單用戶模式啓動ASE，執行：
1> sp_configure "allow updates",1
2> go
1> reconfigure with override(10.0版本以上，省略此步)
2> go
? 刪除sybsystemprocs系統數據庫:
1> use master
2> go
1> drop database sybsystemprocs
2> go
在重建sybsystemprocs系統數據庫之前，不要創建任何其他數據庫。
? 刪除sysdevices系統表中有關sybsystemprocs系統數據庫的信息：
1> begin tran
2> delete from sysdevices where name="sysprocsdev"
我們假定sysprocsdev是默認的sybsystemprocs系統數據庫設備名。
3> select * from sysdevices
確定刪除是否正確有效，如果正確，執行：
4> commit tran
否則，執行：
4>rollback
? 重啓ASE.
? 創建sybsystemprocs系統數據庫設備：
1> disk init name="sysprocsdev",physname="physical_path",vdevno=4,size=25600
2> go
其中size是以頁爲單位（512頁=1M）。
sybsystemprocs系統數據庫設備的vdevno應該是4，ASE在單用戶模式下4不能被重新利用，所以如果以上語句執行時出現問題，請重啓ASE。
? sybsystemprocs系統數據庫：
1> create database sybsystemprocs on sysorocsdev=50
2> go
在sysdatabases系統表中，sybsystemprocs系統數據庫的dbid=4，如果在重建
sybsystemprocs系統數據庫之前，沒有創建任何其他數據庫。
? 以多用戶模式啓動ASE,並執行：
1> sp_configure "allow updates",0
2> go
3> reconfigure with override(10.0版本以上，省略此步)
4> go
? 運行installmaster腳本：
%isql -Usa -Psa_password -Sserver_name -n -iinstallmaster -o< output_file
installmaster腳本在$SYBASE/scripts路徑下。
? 重建sybsystemprocs系統數據庫中的用戶自定義存儲過程 。
5.3.6 如何挽救 corrupt table 中的數據
[此文僅供參考]
*/設置數據庫隔離級別：
sp_setsuspect_granularity [dbname[,{"database"|"page"}[,"read_only"]]]
強制脫機數據庫/數據頁聯機：
sp_forceonline_db dbname,{"sa_on"|"sa_off"|"all_users"}
sp_forceonline_page dbname,pgid,{"sa_on"|"sa_off"|"all_users"}
獲取有關脫機數據庫/頁的信息：
sp_listsuspect_db
sp_listsuspect_page [dbname]
How to patch a corrupt table and save its data
platform: general product: ASE
written by: Hunter Liu
last update time : Dec.17,1998
(1) isql -Usa -P to log into sql server and enter following commands
1> sp_role "grant","sybase_ts_role",sa
2> go
1>quit
2>go
(2) relogin into sql server with sa
(3) enter these commands in isql:
1> use your_database
2 > go
1> select first ,root ,indid from sysindexes
2> where id=object_id("table_name")
3>go
choose a line from the output of which the indid is neither 0 nor 1,
and pick up the value of its root. this is the root page number
of this index btree,next we will use root_page_number
to represent it and indid for its index id.
(4) find a page number which is on the data pages chain
1>dbcc prtipage(database_name,table_name, indid,root_page_number)
2>go
(4.1) read the last line of this dbcc output ,it is like:
index row at offset XX points to page XXXX.
take the page number xxxx and issue above command again :
1>dbcc prtipage(database_name,table_name,indid,XXXX)
2>go
repeat this step until the dbcc output looks like this:
leaf row at offset xxxxx points to data page nnnnn,row number xxxx.
this meens that we reach the leaf-level pages of this index btree,
so you choose a line from its output and read out the
page number, which is a data page of this table.
(5) from the data page (nnnn), you walk along the data page chain of this table
until we get to the begin, the first page of its database chain.
1>dbcc pglinkage(supportdb,nnnn,0,2,0,0)
2>go
the last number of this page number list is the first
page of this table. make sure the object id displayed is correct.
(6) update the first column of this table in sysindexes
1>update sysindexes set first=new_first_page where id=object_id('table_name')
2> and indid=0
3>go
(7) use select count(*) from table_name to test our work.
(8) select * into new_table from table_name.
(9) drop the old corrupt table.
5.3.7 Recovering the master Database or Master Device under ASE 12.5
This TechNote describes the new procedure you need to use to load the master database, or recover from master database or device corruption in Adaptive Server Enterprise 12.5. The disaster recovery procedures differ from pre-12.5 servers.
Contents
1. Background
2. Before You Begin
3. Loading an Older Copy of master Database
4. Recreating the master Database
5. Recreating the Master Device
6. Manually Setting the Backup Server Name
Section 1. Background
Starting with Adaptive Server version 12.5, there is no buildmaster program to build the master device. Rather, this functionality has been incorporated into the dataserver (unix) and sqlsrvr (Windows) programs. The server now allows you to create master devices
and databases with 2K, 4K, 8K or 16K logical page sizes. Due to these and other changes, you cannot use the instructions provided in the ASE Troubleshooting and Error Messages Guide (EMTSG) for disaster recovery tasks like recovering the master database or
device.
This TechNote explains how to perform disaster recovery in the 12.5.x server. It is applicable to ASE 12.5.0.1 IR and higher versions.
Note:
The EMTSG instructions still apply to the pre-12.5 servers.
Section 2. Before You Begin
This document describes three key maintenance and disaster recovery tasks:
? Loading an older copy of your master database. This assumes that both the master device and master database are intact and free from corruption.
? Recovering from a corrupted master database. This assumes that the master device is intact.
? Recreating a master device and all its databases.
Some points to note before using this information:
? This material applies only to ASE 12.5.x and higher. It has been verified with ASE 12.5.0.1 Interim Release (IR), and it is recommended that you use the procedures with this release (or later). For 12.0 and prior versions, use the instructions provided in
the ASE Troubleshooting and Error Messages Guide, "System Database Recovery."
? This material assumes that your Adaptive Server was installed with your platform's default sort order. If you have installed a non-default sort order, you must ensure that your (restored) server uses the correct sort order and character set to reflect that
in the dump. Refer to the ASE Troubleshooting and Error Messages Guide, "System Database Recovery," section titled "Valid Dump with Non-Default Sort Order" for details; and note that in Step 3 of that section, the sybinit utility has been replaced by the dsedit/dscp
utilities.
? All SQL command examples in this document use Transact-SQL syntax. All command-line examples are unix commands; Windows users can find the equivalent NT syntax in ASE Utility Programs for Windows and Windows NT.
? Starting with 12.5, the dataserver command allows a space between option and parameter.
? The examples in this document assume that
- the dataserver binary is located in $SYBASE/bin/dataserver
- the master device is $SYBASE/d_master.dat
Replace this location and device name with those appropriate for your site.
? The server must be in single-user mode (that is, started with the -m flag) to load the master database. In this mode only the master database can be loaded.
? You can only load a dump of master that matches your server level. Loading an older version dump to a newer server is not permitted.
? You can use these procedures regardless of which version of the server you were using when you created your old master device. The server will find and correct any placement differences between the old and recreated databases.
? After the load completes but before shutting down, the server does some post-processing to reconcile the newly loaded sysdatabases and sysusages tables against the information in the master device. At this time the server may print a variety of error messages
regarding failures to use or find the master database, and/or attempts to insert duplicate keys or duplicate rows to sysusages. Ignore these messages; they occur only during the reconciliation phase, and will not affect the server's operation after it shuts
down and is restarted.
Section 3. Loading an older copy of master database
Use the following steps if your master database and the master device are intact, and you simply wish to load an older dump of your master database.
Note:
Be sure to read Section 2, Before You Begin.
Step 1: Put the Server in Single-user Mode
Shut down and restart the server with the -m flag, which places the server in single-user mode and sets up to load the master database:
% $SYBASE/bin/dataserver -d $SYBASE/d_master.dat -m
Step 2: Establish the Backup Server Name
This step is necessary to ensure that Adaptive Server has access to its backup server for dumps and loads. Follow the instructions detailed in Section 6, Manually Setting the Backup Server Name.
Step 3. Load the master Database
Issue the following isql command:
1> load database master from "master_db_dump"
2> go
Adaptive Server shuts itself down after the load is complete.
Section 4. Recreating the master Database
Use this procedure when the current master device is usable, but you are unable to use the server because of master database corruption. These steps enable you to create a new master database and reload it from backup.
Step 1. Create a New master Database
The approach to creating the new master database depends on the extent and nature of the corruption. Three different scenarios are possible:
? Basic recreation, which is sufficient if only the data in master was affected. The server reads the master device to determine page and device sizes.
? Recreating when the device's configuration area is corrupted. You will need to provide page and device sizing information.
? Recreating when the master database allocation pages are also corrupted. All corrupt or unallocated extents on the device are allocated to master.
Basic Recreation of master Database
This command instructs the server to read the device's configuration area to obtain page size and device size and determine where to place the master database:
% $SYBASE/bin/dataserver -d $SYBASE/d_master.dat -w master
The server creates a master of the same size, and in the same locations on disk, as the database it is replacing. It will NOT have the old database's data! Instead, it contains a default set of data that you will replace later via load database. The default
data includes information about any databases existing on the master device (but no other devices). It also has minimal system information, including a login for sa with a null password.
This process produces a large number of "upgrade" messages tracking the progress of database creation which are helpful in troubleshooting any problems. They are "upgrade" messages because the server creates a new master database by "upgrading" the device.
Note:
If the configuration area is corrupt or unavailable, this command returns the message: "The configuration area in device 'xxx' appears to be corrupt. The server needs this data to boot, and so cannot continue." If this occurs, continue with the instructions
below.
Recreation with a corrupt configuration area
The "Basic Recreation" process above may fail if the device's configuration area has become corrupt. If so, you must supply sizing information. You will need two parameters: the page size (you need to know what this was), and the device size, which you can
determine directly from the device:
% ls -l $SYBASE/d_master.dat
Divide the size shown by the page size (2048, say) to obtain the number of server pages, by 1024 to obtain KB, or by 1048576 to obtain MB.
Provide this information on the command line as follows:
% $SYBASE/bin/dataserver -d $SYBASE/d_master.dat -w master
-z page_size -b device_size
For example, if your page size is 2K and the device size is 51204 server pages (100 MB, plus 8K space for the configuration area), the command looks like this:
% $SYBASE/bin/dataserver -d $SYBASE/d_master.dat -w master -z 2k -b 51204
You may also specify the device size as Kb, Mb, or Gb; for example, "-b 100M".
Recreation when master database allocation pages are corrupted
If the above procedures for recreating the master database fail, the database's allocation pages are corrupt. (This may happen, for instance, if the database device was inadvertently written over by a completely different file.)
In this case, you can force the server to allocate all corrupted or unallocated extents to the master database:
% $SYBASE/bin/dataserver -d $SYBASE/d_master.dat -w master -f
This allocates ALL corrupted or otherwise unrecognizable extents to the master database. Depending on the extent of your master device corruption, and how much free space it originally had, this will probably leave master much larger than it needs to be, causing
it to occupy space that used to belong to other databases like model, tempdb, and sybsystemdb. We will consider recovering from that situation later.
Note:
You may combine the -f, -b, and -z options as necessary.
Step 2. Restart the Server in Single-user Mode
The server shuts down after recreating the master database. Restart it with the -m flag, which places the server in single-user mode and sets up to load the master database:
% $SYBASE/bin/dataserver -d $SYBASE/d_master.dat -m
Step 3: Account for Missing Databases (if you used the -f option)
Note:
You only need this step if you used the -f option in Step 1 to recreate the master database due to allocation page corruption. If you did not use -f, proceed to Step 4.
Recall that the -f command line option could make the new master larger than needed at the expense of other required databases on the master device. You will need to check for these databases before proceeding. This step has many possible permutations, so you
must know what databases should be on the master device to perform this step. For example, if you had moved tempdb to a different device, you will not need tempdb on the master device. If upgrading, you may well have created sybsystemdb on a device other
than master; if so, you will not need to account for sybsystemdb.
Log in as sa, and check the databases currently on the master device:
1> select name from sysdatabases
2> go
Do you see all the databases that should be on the master device? If so, skip the rest of this step. Otherwise, you will need to determine which databases are missing and how big they should be, then obtain the free space needed to recreate these databases.
The following isql script obtains the required space by removing it from the end of the master database. In order, it
? establishes how many logical pages the missing databases need
? subtracts that number from the pages that master occupies
? removes disk usage entries for parts of master above that limit
? restricts the highest logical chunk of master such that its total size leaves the required number of pages free.
You will need to provide the required space value, denoted as "@needed_mb".
Note:
This sample script is provided to assist you with the disaster recovery task. It is not officially supported by Sybase.
1> declare @needed_mb int, @needed_pages int, @master_end int,
2> @pgspermb int
3> select @pgspermb = (1048576 / @@maxpagesize)
4> select @needed_mb = 12 -- replace '12' with required space value
5> select @needed_pages = @needed_mb * @pgspermb
6> select @master_end = sum(size) - @needed_pages
7> from master.dbo.sysusages
8> where dbid = 1
9> if (@master_end > (6 * @pgspermb))
10> begin
11> delete master.dbo.sysusages
12> where lstart > @master_end
13> update master.dbo.sysusages
14> set size = @master_end - lstart
15> where dbid = 1
16> and lstart = (select max(lstart) from master.dbo.sysusages
17> where dbid = 1)
18> end
19> else
20> begin
21> print "Can't take enough space from the master database!"
22> print "Need to find %1! pages", @needed_pages
23> print "That would leave master with %1! pages", @master_end
24> print "Cannot continue."
25> end
26> go
Note:
If the procedure fails, your master device is not big enough to hold all the databases you are trying to create. Check the required MBs of space that you specified. If it is correct, it may be necessary to create a new master device using the instructions
in Section 5, Recreating the Master Device.
You now have enough space to recreate your required databases. Create them one at a time. For example:
1> create database model on default = 3
2> go
Repeat for each database. Then shut down the server, and restart it in single-user mode using step 2 above.
Step 4. Establish the Backup Server Name
This step is necessary to ensure that Adaptive Server has access to its backup server for dumps and loads. Follow the instructions detailed in Section 6, Manually Setting the Backup Server Name.
Step 5. Load the master Database
Issue the following isql command:
1> load database master from "master_db_dump"
2> go
Unlike during a normal database load, the server may need to perform a lot of extra work, because master contains information about the identity and location of your other databases; that information may have changed for this master device, and the server must
check and update it as necessary.
At the end of this step, the server contains correct disk usage information about the master device. This may differ from the information in sysusages in the dump, so the server will find and correct both the size and location information for the databases.
Any entries for parts of databases that don't actually exist on master will be removed.
During post-processing from the load, you may see one or more errors from the server. Read Section 1, Before You Begin, for more information about these errors.
After checks and validations are complete, the server will shut down. You may now restart it normally.
Step 6. Did you recreate any databases in step 3 above?
If you recreated databases using the procedure in step 3 above, load those databases. You must restart the server without the -m flag in order to accomplish this.
Section 5. Recreating the Master Device
Use these steps when the disk that used to contain your master device is not accessible, and you need to start over with a new device.
This situation is somewhat similar to the scenario in Section 4 above in which the master device becomes so corrupt that you need to use the -f option, because you will need to know what databases used to be on your master device and how big they were so you
can validate and recreate them as necessary.
Step 1. Create your new master device
When creating the new master device, make sure you use the same page size as your old master device and make the new device at least as large as the old one. The following example creates a device with a 2048-byte logical page size, and total size 100 Megabytes
+ 8 Kilobytes (the 8 KB is extra space for the configuration area.)
% $SYBASE/bin/dataserver -d $SYBASE/d_master.dat -z 2k -b 51204
Use the -s option with this command to specify the server name. You can also specify the "-b" size in Kb, Mb, or Gb. In the above example you would use "-b 100.00782M". Without one of the K, M, or G modifiers, the default device size is expressed in server
virtual pages, 2048 bytes each.
At device creation, the server issues large numbers of "upgrade" messages tracking its progress; these messages help troubleshoot any problems. They are upgrade messages because the server creates a new installation by doing an "upgrade" of a device that it
has just created.
When finished, the server shuts down. You now have a master database containing minimal system information, including an sa login whose password is null, and minimally sized master, model, tempdb, and sybsystemdb databases.
Step 2. Put the Server in Single-user Mode
Shut down and restart the server with the -m flag, which places the server in single-user mode and sets up to load the master database:
% $SYBASE/bin/dataserver -d $SYBASE/d_master.dat -m
Step 3. Establish the Backup Server Name
This step is necessary to ensure that Adaptive Server has access to its backup server for dumps and loads. The new master database contains a default Backup Server entry of SYB_BACKUP for srvnetname, which is probably wrong. Since the sp_addserver procedure
is not available at this time, log in to the server as sa and update sysservers directly:
1> update master.dbo.sysservers
2> set srvnetname = "backup_server_name"
3> where srvname = "SYB_BACKUP"
4> go
(1 row affected)
Step 4. Load the master Database
Issue the following isql command:
1> load database master from "master_db_dump"
2> go
The server inspects the master device and makes any corrections needed in the newly loaded sysdatabases and sysusages. These corrections affect only the master device, since that is the only device that changed -- the server assumes that all your other devices
are undamaged and need not be inspected.
After this step, it is possible that your new master device contains database entries for databases that also exist on other devices in your system. This may happen if you moved tempdb to a different device, or created sybsystemdb on a different device. The
server recognizes and handles this situation: if it finds pre-existing entries for those databases on other devices, it presumes that the existing entries are correct and does not change them.
During post-processing from the load, you may see one or more errors from the server. Please read Section 2, Before You Begin, for more information about these errors.
After the checks and validations are complete the server shuts down. You may now restart it normally.
Step 5. Check that the Databases on Master Device Are Correct
When you created a new master device in step 1 above, the server created only its default set of databases, with minimal data. You will almost certainly need to load dumps of the databases (notably model) that used to be there.
Are the databases on your new master device large enough to hold the dumps you will be loading into them? Are all the necessary databases present? Is there any obsolete data that you need to clean up?
Log in as sa and inspect the databases on your system:
1> declare @pgspermb int
2> select @pgspermb = 1048576 / @@maxpagesize
3> select "db name"=db_name(dbid), dbid, "size"=sum(size) / @pgspermb
4> from master.dbo.sysusages
5> group by dbid
6> go
This command shows you all the databases present on your system, and their total size. Note that the size column in the output is expressed in Megabytes.
Does this list contain any entries where database name is null? These sysusages entries don't have any matching entries in sysdatabases; they are unnecessary and should be deleted. (You may be specially susceptible to this if you upgraded from pre-12.0 versions,
and created sybsystemdb on the older version; sybsystemdb will have a different dbid than the default dbid.) To remove these entries, use a script like the following:
1> exec sp_configure "allow updates", 1
2> go
1> delete sysusages
2> where db_name(dbid) is null
3> go
1> exec sp_configure "allow updates", 0
2> go
Are any databases missing? Create those databases. Are the databases large enough? If not, alter them to be at least large enough to hold the dumps. (It is okay if they are too large; the server simply clears the excess space.)
Section 6. Manually Setting the Backup Server Name
This procedure updates the sysservers table and is needed to ensure that Adaptive Server can access the correct backup server to carry out dumps and loads. Use it with the instructions for Sections 3 and 4.
Execute the following isql commands in Adaptive Server:
1> use master
2> go
1> select srvname, srvnetname from sysservers
2> where srvname = "SYB_BACKUP"
3> go
There are three possible outcomes to this query. Take the appropriate action below depending on the outcome:
Outcome Action
ASE returns a single row and
srvnetname contains the correct
Backup Server name No action is needed.
ASE returns a single row
but the srvnetname is not the
correct Backup Server name Issue the following isql command:
1> update sysservers
2> set srvnetname = "backup_server_name"
3> where srvname = "SYB_BACKUP"
4> go
where backup_server_name is the name of the Backup Server
as it appears in the interfaces file.
ASE returns 0 rows Issue the following isql command:
1> sp_addserver SYB_BACKUP, null,
2> backup_server_name
3> go
5.3.8 如何只用數據庫設備文件生成新的數據庫服務器
本例的環境：
OS: Win2000 professional (中文)
ASE: Adaptive Server Enterprise 12.0 for NT(中文)
原有數據庫服務器： PDS_CJ
數據設備文件：c:\sybase\data\master_RDS_CJ.dat 30M
c:\sybase\data\sybprocs_RDS_CJ.dat 80M
目的：
將通過現有的2個數據庫設備在相同的平臺下的其他的機器上創建數據庫服務器，而不用syconfig.exe(服務器配置)程序來創建服務器。
新建服務器名稱：RDS_CJ
步驟：
一、配置新的數據庫服務器：
1。拷貝原有數據庫設備文件到新的機器上：
copy master_PDS_CJ.dat 爲 master_RDS_CJ.dat
copy master_PDS_CJ.dat 爲 master_RDS_CJ.dat
2。拷貝或新建RUN文件：
copy RUN_PDS_CJ.bat > RUN_RDS_CJ.bat
編輯 RUN_RDS_CJ.bat 將所有 PDS_CJ 替換爲 RDS_CJ（指定MASTER設備和SERVER名）
RUN文件樣本：
rem
rem Adaptive Server Information:
rem name: PDS_CJ
rem master device: c:\sybase\data\master_PDS_CJ.dat
rem master device size: 15360
rem errorlog: c:\sybase\ASE-12_0\install\errorlog_PDS_CJ
rem interfaces: c:\sybase\ini
rem
c:\sybase\ASE-12_0\bin\sqlsrvr.exe
-dc:\sybase\data\master_PDS_CJ.dat
-sPDS_CJ
-ec:\sybase\ASE-12_0\install\errorlog_PDS_CJ
-ic:\sybase\ini -Mc:\sybase\ASE-12_0
3。添加ASE的服務器明：
用dsedit工具添加接口（interfaces）文件的條目
4。啓動新配的服務器：（此時系統存儲過程庫仍無法使用）
通過執行RUN文件的方式啓動服務器。(-T3604)
5。修改數據庫中的信息：
1> select * from sysdevices where name="sysprocsdev"
2> go
low high status cntrltype name phyname mirrorname
-----------------------------------------------------------------------------------------
16777216 16818175 16386 0 sysprocsdev c:\sybase\data\sybprocs_PDS_CJ.dat NULL
1> sp_configure "allow update",1
2> go
1> update sysdevices set phyname="c:\sybase\data\sybprocs_RDS_CJ.dat" where name="sysprocsdev"
2> go
(1 row affected)
1> update sysservers set srvname="RDS_CJ" where srvname="PDS_CJ"
2> go
1> shutdown
2> go
6． 啓動服務器
通過執行RUN文件的方式啓動服務器(不加 -T3604了)，新服務器配置完成。
二、將數據庫服務器註冊到註冊表中：
1。編輯Server(PDS_CJ).reg文件，將所有的PDS_CJ替換成RDS_CJ
執行即在 HKEY_LOCAL_MACHINE\SOFTWARE\SYBASE\Server中註冊了名爲RDS_CJ的服務器；
2。編輯Serv(PDS_CJ).reg文件，將所有的PDS_CJ替換成RDS_CJ
執行即在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services中註冊了名爲SYBSQL_RDS_CJ的服務；
3。編輯Serv(PDS_CJ).reg文件，將所有的PDS_CJ替換成RDS_CJ
執行即在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application中註冊了名爲RDS_CJ的項目，
其作用是將SYBSQL_RDS_CJ 服務的事件信息和錯誤記錄在Win2000的事件查看器的應用日誌中，
前兩步是必需的，第3步可以不添加。
以上的註冊表文件修改並執行後，不要馬上重新啓動Win2000。
請運行regedit
將HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SYBSQL_RDS_CJ中ImagePath 的數值數據，
由c:\sybase\ASE-12_0\bin\sqlsrvr.exe -sPDS_CJ -C
該爲：
c:\sybase\ASE-12_0\bin\sqlsrvr.exe -sRDS_CJ -C
4。重新啓動Win2000，讓註冊表中新添加的項目生效。
僅供參考：
WIN NT 4.0 和 WIN2000的註冊表的格式不同，因此不能夠將這2個平臺的註冊表文件相互遷移。
5.3.9如何單獨在備份機上啓動Sybase ASE12.5 (ASE HA)
一． 如何單獨在備份機上啓動Sybase ASE12.5
1. 1. 停止HACMP的服務進程
1. 2. 在備機上將卷組激活
# varyonvg datavg
1. 3. 修改standby地址爲主機的service地址
# smitty tcpip à en2
修改10.61.2.102à10.61.1.100
1. 4. 登錄到sybase用戶
# su - Sybase
$
1. 5. 編輯interfaces文件
將sdcp_bak_srv 改爲sdcp_pri_srv
1. 6. 啓動ASE
$ cd /sybase/ASE-12_5/install
$ startserver –f RUN_sybase_bak
1. 7. 執行如下命令
$isql –Usa –P –Ssybase_bak
1> dbcc takeover
2> go
二． 恢復到正常狀態
2． 1． 行如下命令
$isql –Usa –P –Ssybase_bak
1> dbcc ha_admin(‘’,rollback_failover)
2> 2> go
2． 2． 停止sybase_bak
$isql –Usa –P –Ssybase_bak
1> 1> shutdown
2> 2> go
3．將interfaces文件中的地址改回爲原來的sdcp_bak_srv
4．退回到root用戶
5．將地址10.61.1.100修改回10.61.2.102
6．中斷對卷組datavg的激活
# varyoffvg datavg
7．啓動HACMP
5.4 數據庫恢復以後的工作
5.4.1 如何檢查數據庫中數據的一致性
數據庫一致性檢查(dbcc)提供了一些命令用於檢查數據庫的邏輯和物理一致性。Dbcc主要有兩個功能：
? 使用checkstorage 或 checktable 及 checkdb 在頁一級和行一級檢查頁鏈及數據指針。
? 使用checkstorage, checkalloc, 或 checkverify, tablealloc, 及indexalloc 檢查頁分配。
在下列情況中需要使用 dbcc 命令：
? 作爲數據庫日常維護工作的一部分, 數據庫內部結構的完整性決定於sa 或dbo 定期地運行 dbcc 檢查。
? 在系統報錯以後, 確定數據庫是否有損壞。
? 在備份數據庫之前, 確保備份的完整性。
? 如果懷疑數據庫有損壞時, 例如, 使用某個表時報出表損壞的信息, 可以使dbcc 確定數據庫中其他表是否也有損壞。
下面是dbcc的簡單用法：
? dbcc checktable (table_name)
檢查指定的表, 檢查索引和數據頁是否正確鏈接, 索引是否正確排序, 所有指針是否一致, 每頁的數據信息是否合理, 頁偏移是否合理。
? dbcc checkdb (database_name)
對指定數據庫的所有表做和checktable 一樣的檢查。
? dbcc checkalloc (database_name,fix|nofix)
檢查指定數據庫, 是否所有頁面被正確分配, 是否被分配的頁面沒被使用。當使用"fix"選項時，在檢查數據庫的同時會自動修復有問題的頁面。（若數據庫數據量很大，則該過程會持續很長時間。）
? dbcc tablealloc (table_name,fix|nofix)
檢查指定的表, 是否所有頁面被正確分配, 是否被分配的頁面沒被使用。是 checkalloc 的縮小版本, 對指定的表做完整性檢查。當使用"fix"選項時，在檢查數據表的同時會自動修復數據表中有問題的頁面。
關於上述命令的其它選項及詳細使用方法和checkstorage, checkverify, indexalloc 的詳細使用方法, 請參閱3.11 DBCC或Sybase命令手冊。
舉例1： Unix平臺檢查pubs2數據庫的一致性
? 單用戶模式啓動Server：
$SYBASE/install startserver -f RUN_server_name -m
? vi dbcc_db.sql
use master
go
sp_dboption pubs2,"single user",true
go
use pubs2
go
checkpoint
go
dbcc checkdb(pubs2)
go
dbcc checkalloc(pubs2,fix)
go
dbcc checkcatalog(pubs2)
go
use master
go
sp_dboption pubs2,"single user",false
go
use pubs2
go
checkpoint
go
quit
go
? isql -Usa -Pxxxxxx -SSYBASE <dbcc_db.sql >dbcc_db.out
? grep Msg dbcc_db.out
舉例2： Unix平臺檢查pubs2數據庫中titles表的一致性
? vi dbcc_table.sql
use pubs2
go
dbcc checktable(titles)
go
dbcc tablealloc(titles)
go
? isql -Usa -Pxxxxxx -SSYBASE < dbcc_table.sql > dbcc_table.out
grep Msg dbcc_table.out
換一張
