．数据库不能恢复

数据库不能恢复或是恢复很慢，通常都是由于系统down机，或是在事务很忙时由于某种原因（如日志满）重新启动了数据库。如何处理数据库不能恢复的问题，如何加快数据库的恢复，如何删除不能恢复的数据库，下面就一些例子进行分析。

l        系统down机，数据库被标记为suspect

Database 'xx' cannot be opened - it has been marked SUSPECT by recover

Explanation

(1) 用ISQL 登录到ASE, 须 用SA 帐号

1>sp_configure "allow updates", 1

2>go

1>update master..sysdatabases

2>set status =-32768

3>Where name="database_name" database_name是你 的 数 据库 名

4>go

1>shutdown with nowait

2>go

(2)这 时 重 新 启动SQL Server, SA 帐 号 注册 到SQL Server.

1>update master..sysdatabases

2>set status=0

3>Where name="database_name" database_name 是 你 的 数据库

名

4>go

(3)重新启动Sybase

    注意：在做update时，一定要注意加上where 条件

l        当某一正常运行的大事务（例如：update、delete操作）被终止，且重新启动server后，运行该事务的数据库处于恢复状态，通常这种状态会持续很长时间，当在此恢复过程中没有出现任何异常时，建议用户耐心等待恢复过程完成。同时我们提供以下方法来终止此恢复过程，但请用户注意这些操作将带来数据的不一致性。必要时，希望用户用完整、可靠的数据库备份恢复此数据库。

　　 (1) 启动Backup Server, 后备master数据库

　　1>dump database master to "/usr/sybase/master.dup"
　　2>go

　　 (2) 用isql登录到SQL Server, 须用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

　　 (3)这时重新启动SQL Server, 再用sa帐号登录到SQL Server.

　　1>dump tran pubs2 with no_log
　　2>go
　　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

　　 (4) 如果你的数据库原来有dboption(例如"select into","trunc log on chkpt"等), 你需要重新设置这些option..

　　 (5) 当数据库已经恢复可使用状态后，运行dbcc命令检查数据库的一致性(参照"如何检查数据库中数据一致性"文章)

　　 (6) 后备用户数据库

例如：
　　1>dump database pubs2 to "/usr/sybase/pubs2.dup"
　　2>go

l        如果数据库始终不能恢复，但用户有备份，这时需要删除不能恢复的数据库。

如何删除坏的用户数据库(以pubs2为例)

　　当使用drop database无法删除数据库时，使用本文所示方法可以删除。

　　 (1)使用isql以sa注册SQL server

　　 (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

问题现象：用户通过dblibrary  调用存储过程，完成insert 操作，insert 效率很差，1000条数据需要3分钟以上。如果使用isql 进行插入操作则insert 效率很好，当insert 每行的实际插入字节长度较小的使用，效率很好，insert 每行的实际插入字节长度达到400byte 左右时，性能有很大的下降。

解决办法：

调用 dblibrary 中设置网络包大小的函数

 DBSETLPACKET(login, 1024)

LOGINREC      *login;

short         packet_size;

insert 速度恢复正常。

分析：

 该问题没有被及时发现主要是混淆了ASE的两个参数概念：

default network packet size ： 该参数我们通常叫做“默认网络包大小”。但实际上这个作用只是在ASE启动的时候，在内存池中为用户可以使用的默认网络包分配内存，并不指当用户申请连接的时候系统默认使用的网络包的大小，换句话说在用户连接时不指定网络包的大小，无论default network packet size如何调整，系统都将使用512 byte 作为一个网络包的大小。该参数的大小对占用内存的影响不仅和该参数本身有关，而且和系统所配置的用户连接数有关 （number of user connetion）,内存占用与 default network packet size * number of user connection 成正比。

Max network packet  size : 指定用户可以使用的最大网络包 。该参数的调整对于内存的影响很小。该参数必须大于等于 default network packet size

测试：针对于 default network packet size 、max network packet size 、isql –A

参数设置做了如下测试，供参考。

(1)  Default network packet size ＝ 1024  、Max network packet size =1024 、Isql –A  =2048  时