SYBASE数据库常见的问题总结

SYBASE 数据库常见问总结 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。 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 第三步，由于事务日志已经很满，不能使用常规方法转储此事务日志，如果使用了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）没有提供任何方法可恢复自从上次例行转储后提交的事务。 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重新启动之后，当发现数据库本身存在不可恢复的问题时，如数据页损坏等，且没有完好的数据库备份，一定要用bcp...out备份用户数据库数据。此时，以下步骤省略，并按照“如何删除坏的用户数据库”文章删除此数据库。之后重建此数据库，恢复备份。  否则，按以下步骤继续操作：  用sa帐号注册到SQL  Server.    1>begin  tran    2>go    1>use  master  2>go  1>update  sysdatabases    2>set  status=0    3>Where  name="escourt5"    4>go    如果得到(1  row  affected),则  1>commit  2>go  否则  1>rollback  2>go  1>sp_configure  "allow  updates"  ,0  2>go    (5)重新启动SQL  Server.  (6)  如果你的数据库原来有dboption(例如"select  into","trunc  log  on  chkpt"等),  你需要重新设置这些option.  (7)  当数据库已经恢复可使用状态后，运行dbcc命令检查数据库的一致性(参照“如何检查数据库中数据一致性”文章)    (8)  备份用户数据库  例如：  1>dump  database  escourt5  to  "/usr/sybase/pubs2.dup"  2>go  4．Sybase系统崩溃了，没有备份，但设备文件还存在，如何恢复数据库？ 有的时候，系统崩溃了，手上也没有数据库的备份或者是备份太旧了，但侥幸的是设备还在，并且是完整的，这时可以通过文件COPY的方式恢复数据库。 情况一、所有设备，包括 master ，均是完整的： 这种情况是最简单的，只需要先备份设备文件（包括master，copy 到安全的地方），然后重新安装系统，建服务（保持页面大小、编码和排序与以前一样），然后停止服务，按原目录将所有设备文件拷贝回来，再重启服务即可。新建的服务名可与旧服务不同。建议把 服务名.cfg也复制过来，省掉参数配置。 情况二、应用的设备是完整的，但没有master了： 方法一、 这种情况下要恢复数据库就需要原来的设备使用情况表了。重新安装系统，建服务，然后按原设备情况建设备（大小、位置保持和原来一致），接下来根据记录下来的设备使用情况建库，顺序以及占用的空间要和以前的一致。然后停服务，将应用的数据库设备复制回来，重启服务即可。请参考Sybase ASE 系统管理员日常维护的建议，定期备份 master 数据库。 方法二、 1. 重新创建 master 设备 本实验描述了如何在master数据库毁坏的情况下，如何重建主设备，恢复master数据库，得以重新恢复系统。 这里假定： l Master数据库已损坏，或主设备已损坏。 l有系统表的最新打印输出。 l主设备只包括master数据库、tempdb和model l有master数据库的最新备份，且上次转储master数据库后没有初始化任何设备或创建、变更任何数据库。 关于恢复过程 l将主设备重建为第一次安装服务器时的缺省状态； l将master数据库恢复为缺省状态； l将master数据库恢复为上次备份时的状态； 注意：在恢复master数据库的早期阶段，不能使用系统存储过程。 恢复步骤 步骤1：查找系统表 查找已保存到文件的系统表sysdatabases、sysdevices、sysusages、sysloginroles和syslogins的副本。用这些副本可以保证在此过程结束时系统已经全部恢复。 步骤2：建立新的主设备 如果Adaptive Server正在运行，关闭它，然后重建主设备。重建主设备时，必须指定设备大小。开始重建前，记住以下几点： l保留旧设备，以防遇到问题，旧设备可提供至关重要的信息。 l使用buildmaster命令之前应关闭Adaptive Server。 l不同操作系统上创建主设备的命令有所不同，如：buildmast（unix）、bldmaster（windows NT），并安装通用master数据库的副本。 l命令中给出主设备的全名和大小。 示例：重建一个30兆（15360个2k的页） 在Window NT上： bldmastr －d d:\devices\master.dat –s15360 步骤3：以主恢复方式启动Adaptive Server 使用-m选项以主恢复方式启动Adaptive Server。在Window NT上，使用sqlsrvr命令从命令行启动Aadaptive Server。 Sqlsrvr.exe –d:\devices\master.dat –sserver_name –ed:\sybase\install\errorlog –id:\sybase\ini –MD:\sybase –m 说明：以主恢复方式启动Adaptive Server时，只允许一个用户（系统管理员）登录。 步骤4：重建master的设备分配 检查sysusages系统表的书面副本，如果有多行dbid＝1的记录，则需要增加master的大小以便装载转储。最简单情况下，对master进行额外分配只需要使用alter database即可。复杂情况，必须为其它数据库分配空间，以便重新构造恢复master所需的正确的vstart值。 示例： alter datbase master on master=2 步骤5：检查Backup Server和sysservers系统表信息。 使用空口令以“sa“用户登录服务器（如果Backup Server的网络名不是SYB_BACKUP，则必须更新sysservers以便Adaptive Server可以与其Backup Server通信）。 l检查interfaces文件中Backup Server的名称； l并发出下面的命令： select * from sysservers where srvname=”SYB_BACKUP” l检查此命令中输出结果的srvnetname。是否与服务器的backup Server的interfaces文件条目匹配，若匹配跳过步骤5； l如不同，则必须更新sysservers 示例： begin tranaction updata sysserver set srvnetname=”backupserver_name” where srvname=”SYB_BACKUP” l核实该命令，如果updata修改了多行，或者修改了不应修改的行，则发出rollback tranaction命令，然后尝试再次更新。 如果该命令正确修改了Backup Server的行，则发出commit transaction命令。 步骤6：核实Backup Server正在运行 Window NT平台上，本地安装的Sybase Central和服务管理器可以显示Backup Server是否正在运行。 步骤7：装载master数据库的备份 在Window NT上： load database master from “d:\device\master.bck” 在load database成功完成后，Adaptive Server将关闭。 步骤8：更新number of devices配置参数 仅当使用的数据库设备比缺省值多时才执行此步骤。 步骤9：以主恢复方式方式重新启动Adaptive Server Sqlsrvr.exe –d:\devices\master.dat –sserver_name –ed:\sybase\install\errorlog –id:\sybase\ini –MD:\sybase –m 注意：装载master的备份将使“sa”帐号恢复到以前的状态。如果sa帐号有口令，则口令恢复。 步骤10：检查系统表以检验master的当前备份 l如果发出最新的disk init、create database或alter database命令以后已备份了master数据库，则sysusages、sysdatabases、和sysdevice的内容将与书面副本匹配。 l如果副本中的任何设备未包含在已恢复的sysdevices中，则上次备份以后已添加了设备，必须运行disk reinit和disk refit。 步骤11：重新启动Adaptive Server 以常规（多用户）模式重新启动Adaptive Server 步骤12：检查Adaptive server l将sysusages的书面副本与新联机版本比较 l将sysdatabase的书面副本与新联机版本比较 l在每个数据库上运行dbcc checkalloc l检查每个数据库中重要的表 完全恢复master数据库并运行全部的dbcc完整性检查后，使用常规转储命令备份此数据库。 5．不小心直接删除了日志的设备文件，如何恢复数据库？ 首先，应尽可能从操作系统中恢复被误删除的设备文件；如果不能恢复，可创建一个和被删除设备文件大小相同的新设备文件，然后运行 dbcc rebuild_log。  下面给出一个具体的测试用例： -- 创建测试数据库 test use master go disk init name='test_dat_dev',physname='/opt/sybase/data/test_dat_dev.dat',size='50M' go disk init name='test_log1_dev',physname='/opt/sybase/data/test_log_dev1.dat',size='10M' go disk init name='test_log2_dev',physname='/opt/sybase/data/test_log_dev2.dat',size='10M' go create database test on test_dat_dev='40M' log on test_log1_dev='5M', test_log2_dev='2M' go -- 产生一些日志 use test go create table test ( id int not null, name char(20) not null ) go insert into test values(1,'aaaaaaa') insert into test values(2,'bbbbbbb') insert into test values(3,'ccccccc') insert into test values(4,'ddddddd') go 6．sa密码忘记了导致isql -Usa -P******进不去怎么办？ 1、在sybase目录的install子目录的启动server文件 RUN_server名，编辑该文件，在末尾增加-psa，保存该文件。 2、如果服务器已经启动，先停止之。 3、执行第1步批处理文件以启动server，在启动最后显示信息出现sa的新口令，记录之。 4、切换到SQL Advangtage以sa帐号登录，口令为新记录之口令。 5、进入server以后，用命令sp_password修改sa口令, sp_password '原密码','新密码','用户名' 新密码的位数一定要大于6位，否则不能够更改成功。 6、回到第1步，去掉增加的选项-psa，保存退出。 7．关于sybase的配置－（数据库慢的请留意） 说明：数据库性能慢的主要原因有两个 1）数据库服务配置不合理 2）应用程序不合理 遇到数据库性能下降时通常先检查数据库服务配置方面有没有可以改善的，修改之后再观察一段时间，如果性能没有改善的话就要应用程序上有没有可以调整的地方：索引是否合理，sql语句是否优化等。 本篇主要分析数据库服务的配置： 问题分析： 小型机硬件：rp2470双机、CPU700M*2、内存512M*6 以下是现场发过来的主要配置情况： lock scheme                datapages  //datapages锁模式是性能最差的锁，一般不用 number of locks                300000  //通常不需要配置太多的锁10万就够了 max memory                    500000  //物理内存3G，配给sybase的为1G明显不合理                                  （内存*1024*1024*0.5*60%） number of open indexes          4000  //通常2000        number of open objects          4000  //通常2000 number of user connections        300  // number of worker processes          0  //多cpu要打开相应工作进程数 procedure cache size          154800  //存储过程缓存不要超过100M total data cache size          453699  //明显该值太小 allocate max shared memory          0  //打开sybase占用内存的开关 max online engines                  2          number of engines at startup        2            问题处理： 建议先调整以下配置 sp_configure "max memory",1150000              //sybase占用2.3G内存 sp_configure "allocate max shared memory",1 sp_configure "user log cache size",4096        //用户日志缓存用来缓存客户段信息  sp_configure "procedure cache size",50000      //100M存储过程缓存 sp_configure "number of worker processes",2 备份sybase主目录下的***.cfg sp_cacheconfig "default data cache","1G"      //配置缺省数据缓存1G sp_cacheconfig "default data cache", "cache_partition = 2" reboot sybase服务 备份sybase主目录下的***.cfg sp_cacheconfig "tempdb_cache","400M"    //由于内存较充裕，通常会分配一部分内存给tempdb，提高查询的速度 sp_bindcache "tempdb_cache","tempdb"    //绑定400M的内存给tempdb reboot sybase服务 上述操作如无法启动sybase服务则可以将备份的***.cfg替换当前的配置文件，重新boot sybase服务 总结： sybase 11.9.2 & 12.0 & 早期版本的配置通常为以下几项： total memory                  //定义sybase 服务能够使用的物理内存 number of lock                //定义锁的数目 number of open database        //打开的数据库个数，缺省是12个，数据库数目超过12个时要调整该值 number of devices              //数据库的设备数，缺省是10，通常是不够的，需要调整 number of user connections    //用户连接数，根据需要设置，通常一个用户数消耗100K的内存 这个版本的数据库缓存、日志缓存、过程缓存是不用手工配置的 sybase 12.5版本的配置通常为以下几项： lock scheme                  //锁模式，sybase推荐使用缺省（allpages），但是一些并发操作多的表（temp_telebill）要使用行锁（datarows），减少被锁现象 number of locks              //通常不需要配置太多的锁10万就够了 max memory                  //sybase服务能够使用的物理内存，通常配置成物理内存的70％～80％，上例内存是3G，配给sybase的为1G明显不合理 allocate max shared memory  //打开sybase占用内存的开关 number of open indexes      //通常2000，该值配置过低时会在日志中报该值不够，最终导致性能缓慢        number of open objects      //通常2000，该值配置过低时会在日志中报该值不够，最终导致性能缓慢 number of user connections  //用户连接数，根据实际需求来配置，盲目多配会浪费内存 procedure cache size        //存储过程缓存不要超过100M，用来缓存过程的编译代码。 number of open database      //打开的数据库个数，缺省是12个，数据库数目超过12个时要调整该值 number of devices            //数据库的设备数，缺省是10，通常是不够的，需要调整 user log cache size          //日志缓存用来保留客户端连接信息的，每个连接都会生成一个user log cache size大小的cache，该值缺省为2K，主机内存充裕时可以配成4K。 在12.5及以后的版本中都要手工的配置default data cache，缺省为8M，几乎所有的用户操作都是在这个缓存中进行的，如果不优化的话严重影响数据库性能。 优化的方法是把尽可能多的内存配置给default data cache ，即：'max memory'-'所有其他内存消耗（用户数，锁数等）'-‘少许预留内存’＝default data cache。 sp_cacheconfig "default data cache","1G"      //配置缺省数据缓存1G sp_cacheconfig "default data cache", "cache_partition = 2" 关于cpu的配置 max online engines            //sybase 使用的cpu的个数        number of engines at startup  //激活cpu的个数  number of worker processes  //多cpu要打开相应工作进程数 8．设备路径更改的方法 1.关闭服务 2.设为单用户模式 C:\Sybase\ASE-12_5\install  RUN_jianxin.bat  加上-m  3.修改设备路径 isql -Usa -P -Sjianxin(服务名) user master go select * from sysdevices go update sysdevices set phyname='新的路径' where name='更改的设备名' go 4.逐个修改 5.将C:\Sybase\ASE-12_5\install  RUN_jianxin.bat  加上-m  的-m去掉 9． dump文件load后数据库访问不了解决办法 原因：userid不对应 1.连接master，查看syslogins的suid 2.查看sysusers的suid