Sybase ASE数据库不能恢复的解决办法及分析

数据库不能恢复或是恢复很慢，通常都是由于系统down机，或是在事务很忙时由于某种原因（如日志满）重新启动了数据库。如何处理数据库不能恢复的问题，如何加快数据库的恢复，如何删除不能恢复的数据库，下面就一些例子进行分析。 系统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 条件 当某一正常运行的大事务（例如：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  如果数据库始终不能恢复，但用户有备份，这时需要删除不能恢复的数据库。如何删除坏的用户数据库(以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 时 连接不能建立 （2）Default network packet size ＝ 1024 、Max network packet size =4096 、Isql –A =2048 连接可以建立，但使用的网络包大小不确定。所使用的网络包大小 总是大于等于default network packet size 的值（测试时有时会使用1536 或者1024）。 结论： 由于用户申请连接的时候并不能使用默认的 default network packet size 值作为网络包的大小，而需要显示的指定。在我们工作中遇到需要调整网络包大小的问题，不仅需要修改max network packet size && default network packet size 的参数值，还需要更改用户的连接语句： 1. 对于isql 或者 bcp 使用－A 参数，对于isql 或者bcp 的脚本文件则需要修改原有脚本； 2. 对于Dblibrary 程序，需要在连接申请的时候加入DBSETLPACKET(login, packsize) ，或者修改原有语句中“size”的值； 3. 对于Ctlibrary 程序，需要在连接申请的时候加入CS_PACKETSIZE=size ，或者修改原有语句中“size”的值； 对于2 & 3 需要修改后重新编译程序。 4．对于ODBC 需要调整客户端的packet size 选项。 5．对于Borland BDE 引擎需要调整客户端 TDS pack size 选项 （for sybase）