SYBASE数据库常见的问题总结
SYBASE 数据库常见问题总结
SY BASE数据库常见问题总结 (1)
1. SY SLOGS日志满了进不了系统，如何清除日志启动系统 (1)
2. 数据库日志损坏时重建日志启动数据库的解决办法 (4)
3. 数据库处于可疑状态的解决方法 (6)
4．Sybase 系统崩溃了，没有备份，但设备文件还存在，如何恢复数据库？ (9)
5．不小心直接删除了日志的设备文件，如何恢复数据库？. 15 6．sa 密码忘记了导致isql -Usa -P****** 进不去怎么办？16 7．关于sybase 的配置－（数据库慢的请留意） (17)
8．设备路径更改的方法 (22)
9．dump 文件load 后数据库访问不了解决办法 (23)
1 0．sybase 数据库备份方案 (23)
1 1 ．master 数据库状态被置为-32768 后的处理方法 (30)
1. SY SLOGS日志满了进不了系统，如何清除日志启动系统业务系统数据库不能正常启动，对于这一类问题，我们按照如下步骤解决：
第一步，启用allow updates to system tables ，这样可以使具有系统管理员角色的用户能够改变系统表并可创建和修改系统表的存储过程，其中系统表包括master 数据库中所有Sybase 提供的表以及用户数据库中所有以“sys”开头的表和在sysobjects 表中其ID 值小于或等于100 的表。系统表的不正确变更会导致数据库损坏和数据丢失，修改系统表时务
必要使用begin transaction 来保护数据库不受可能损坏数据库的错误影响，完成修改后应立即禁用allow updates to system tables 。
1>sp_configure "allow update",1
2>go
第二步，Adaptive Server 中的每个数据库在sysdatabases 中都有相应的一行，安装Adaptive Server 后，master 数据库、model 数据库、sybsystemprocs 和 tempdb数据库在sysdatabases 中都将有相应的条目，如果已经安装审计功能，sybsecurity 数据库也将在其中有相应的条目。修改sysdatabases 表，将testdb 的状态修改为-32768 ，然后在关闭Adaptive Server 后重新启动Adaptive Server 。
1> update sysdatabases set status=-32768 where name = "testdb"
2>go
1>shutdown
2>go
第三步，由于事务日志已经很满，不能使用常规方法转储此事务日志，如果使用了dumptransaction 或dumptransaction with truncate_only 命令，而命令又由于日志空间不足失败时，可以使用dump transaction 的特殊选项with no_log ，此选项可截断事务日志而不记录转储事务事件。所有dumptran with no_log 都将在Adaptive Server 错误日志中进行报告，这些消息包括执行此命令的用户ID 、指示成功或失败的消息，no_log 是唯一生成错误日志消息的转储选项。但是这个选项（包括with truncate_only ）没有提供任何方法可恢复自从上次例行转储后提交
的事务。1>use testdb 2>go
1> dump tran testdb with no_log
2>go
第四步，修改sysdatabases 表，将testdb 的状态恢复为0，然后禁用allow updates to system tables 。
1>use master
2>go
1> update sysdatabases set status = 0 where name= "testdb" 2>go
1> sp_configure "allow update",0
2>go
2. 数据库日志损坏时重建日志启动数据库的解决办法首先判断错误为页
损坏或者索引损坏，根据
Adaptive Server failed to retrieve a row via its RID in database
'escourt5' because the requested RID has a higher number than the last RID on the page. Rid pageid = 0x1c88a8; row num= 0x27. Page pointer = 0x261CA000, pageno = 1869992, status = 0x1, objectid = 8, indexid = 0, level = 0.
判断其中:objectid = 8 表示日志段有问题
解决方法一：截断日志
先把sysdatabases 的status 修改成-32768 然后重新启动数据库
1>update sysdatabases set status = -32768 where name = "escourt5"
4>go
登陆数据库
1> dump transaction escourt5 with truncate_only
2> go
Msg 921, Level 14, State 1:
Line 1:
Database 'escourt5' has not been recovered yet - please wait and try again.
1> dump transaction escourt5 with no_log
2> go
Msg 921, Level 14, State 1:
Line 1:
Database 'escourt5' has not been recovered yet - please wait and try again.
说明这种发不起作用解决方法二: 重做日志
1> sp_role "grant","sybase_ts_role",sa
2> go
All the roles specified to be granted in the grant role statement have already been granted to grantee 'sa'.
Authorization updated.
(return status = 0)
1> use master
2> go
1> dbcc rebuild_log(escourt5,1,1)
2> go
DBCC execution completed. If DBCC printed error
messages, contact a user with
System Administrator (SA) role.
1> shutdown with nowait
2> go
Server SHUTDOWN by request.
The SQL Server is terminating this process. 重启服务后把status 修改成0 后再重启服务。服务启动正常最好是通过dbcc
checkdb(databasename) 检查一下数据一致性。
3. 数据库处于可疑状态的解决方法如何解决数据库被挂起的问题
现象：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 登录到SQL Server, 须用sa 帐号( 本文以escourt5 数据库为例)
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="escourt5"
4>go
如果得到(1 row affected), 则
1>commit
2>go
否则
1>rollback
2>go
(4) 重新启动SQL Server.
注：SQL Server 重新启动之后，当发现数据库本身存在不可恢复的问题时，如数据页损坏等，且没有完好的数据库备份，