SYBASE数据库常见的问题总结.doc

SYBASE 数据库常见问题总结 TOC \o 1-3 \h \z \u SYBASE 数据库常见问题总结 1 1. SYSLOGS日志满了进不了系统，如何清除日志启动系统 1 2. 数据库日志损坏时重建日志启动数据库的解决办法 2 3. 数据库处于可疑状态的解决方法 3 4．Sybase系统崩溃了，没有备份，但设备文件还存在，如何恢复数据库？ 4 5．不小心直接删除了日志的设备文件，如何恢复数据库？ 6 6．sa密码忘记了导致isql -Usa -P******进不去怎么办？ 7 7．关于sybase的配置－（数据库慢的请留意） 7 8．设备路径更改的方法 9 9． dump文件load后数据库访问不了解决办法 10 10．sybase数据库备份方案 10 11．master数据库状态被置为-32768后的处理方法 13 1. SYSLOGS日志满了进不了系统，如何清除日志启动系统 业务系统数据库不能正常启动，对于这一类问题，我们按照如下步骤解决： 第一步，启用allow updates to system tables，这样可以使具有系统管理员角色的用户能够改变系统表并可创建和修改系统表的存储过程，其中系统表包括master数据库中所有Sybase提供的表以及用户数据库中所有以“sys”开头的表和在sysobjects表中其ID值小于或等于100的表。系统表的不正确变更会导致数据库损坏和数据丢失，修改系统表时务必要使用begin transaction来保护数据库不受可能损坏数据库的错误影响，完成修改后应立即禁用allow updates to system tables。 1sp_configure allow update,1 2go 第二步，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 2go shutdown go 第三步，由于事务日志已经很满，不能使用常规方法转储此事务日志，如果使用了dump transaction或dump transaction with truncate_only命令，而命令又由于日志空间不足失败时，可以使用dump transaction的特殊选项with no_log，此选项可截断事务日志而不记录转储事务事件。所有dump tran with no_log都将在Adaptive Server错误日志中进行报告，这些消息包括执行此命令的用户ID、指示成功或失败的消息，no_log是唯一生成错误日志消息的转储选项。但是这个选项（包括with truncate_only）没有提供任何方法可恢复自从上次例行转储后提交的事务。 use testdb go dump tran testdb with no_log go 第四步，修改sysdatabases表，将testdb的状态恢复为0，然后禁用allow updates to system tables。 use master go update sysdatabases set status = 0 where name = testdb go sp_configure allow update,0 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 判断其中:objectid = 8 表示日志段有问题 解决方法一：截断日志 先