数据库的日常维护
维护目的:
l 监测数据库的当前运行状况,保证数据库稳定运行。
l 做好数据库的日常的备份工作,减轻问题发生时的风险和责任
l 检测数据库的整体运行状况,对数据库的性能进行调整,保证数据库高效的运行。
l 可以减少紧急故障发生频率,减少对系统的影响。
l 尽早发现系统存在的潜在问题,使可能的故障消除在萌芽状态。
数据库日常维护的主要内容
l 监测数据库运行情况
l 监控CPU和I/O的使用情况
l 监控空间的使用情况
l 监控数据库的错误日志errorlog
l 制定一个合理的备份计划
l 检查数据库的一致性
l 数据库的排错
l 数据库性能调整
数据库日常维护的方法
数据库服务和备份服务的启动和关闭方法
数据库和备份服务的启动
$cd $SYBASE/ASE-12_*/install
$startserver –f RUN_Servername(Servername为你的数据库服务名)
$startserver –f RUN_Servername_back
数据库和备份服务的关闭
isql –Usa –Pxxx –Sservername
>shutdown SYB_BACKUP (关闭备份服务)
>go
>use dbname (用户库)
>go
>checkpoint
>go
>shutdown
>go
查看sybase用户的运行环境是否正常
$env
查看SYBASE,SYBASE_ASE,SYBASE_OCS等环境是否正常
查看数据库服务和备份服务进程是否运行正常
$ps –ef | grep dataserver
$ps –ef | grep backupserver
查看数据库的版本和补丁信息
$dataserver –v
或是
isql –Usa –Pxxx –Sservername
>select @@version
检查数据库的配置是否合理.
检查数据库内存分配、锁个数、存储过程缓冲、多CPU配置、用户连接配置、网络包尺寸等重要参数的设置。
命令:
sp_configure “total memory”(内存)
sp_configure “number of user”(用户)
sp_configure “number of lock”(锁数目)
sp_configure “number of engine”(CPU数目)
查看数据库的用户,数据库的锁状况
sp_who(用户)
sp_lock(锁)
查看最早进程
select * from master..syslogshold
其中对应的spid为最早的进程,如果最早的进程开始时间距离当前时间已经非常长(如2、3天),则可能该进程有问题,确认后,应该将其kill
查看CPU和I/O的使用
#sar
#iostat
#vmstat
查看Sybase的资源使用
sp_sysmon “00:10:00”
如果CPU或是I/O的使用率长期高于80%,则要看系统使用是否正常还是系统资源配置不够。
定期检查数据库日志使用的情况,定期清除数据库的日志
如果数据库日志满,则业务无法进行。
sp_helpdb dbname(用户库名)
发现数据库的日志空间不足,应立刻清除已经完成的事务,或是根据需要扩大日志空间。
定期清除日志:
dump tran dbname with truncate_only
可以将上述的命令放在crontab中。
定期检查磁盘空间的使用。 如果发现操作系统有磁盘分区使用达到100%,应尽快处理。
#df -k
定期检查数据库的错误日志(errorlog),如果错误日志中发现有数据库的严重错误,应立即处理。
有计划的截断数据库的错误日志。
数据库运行一定时间后,可以在数据库没有业务时,(下班或周末),将数据库stop后,将错误日志更名,然后重新启动数据库,产生一个新的数据库错误日志。
在错误日志中,以下的错误级别为不严重错误,通常是用户错误,如语法,读写权限空间不足等。
10 Status information
11 Specified database object not found
12 Wrong datatype encountered
13 User transaction syntax error
14 Insufficient permissions to execute commands
15 Syntax error in SQL statement
16 Miscellaneous user error
Hardware/software errors
17 Insufficient resources
18 Non-fatal internal error
在错误级别17中,要注意错误号1105,1105表示空间不足(数据库数据或是日志)。
在错误级别18中,最多的是1608,1608表示一个客户连接不是正常方式退出的,
这类错误不用关注。
以下错误级别为严重错误,通常是系统(数据库、磁盘损坏、操作系统)错误
19 Fatal error in resource
20 Fatal error in current process
21 Fatal error in database process
22 Fatal error: table integrity suspect
23 Fatal error: database integrity suspect
24 Hardware error or system table corruption
在错误日志中,可以按照"Sybase Technical Support"来搜索,
找到的错误通常是严重错误。
检查数据库的一致性
检测系统数据库、用户数据库的数据分配页物理可用性,检查数据库系统表和用户表的数据完整性,查看是否有表损坏(可能是逻辑也可能是物理的损坏,如磁盘错误可能导致数据库的表损坏)
做数据库的一致性通常需要单用户状态,并且都是一些耗时操作(如果数据库大的话),因此,这些检查可以考虑在系统检修时运行。
dbcc checkalloc(dbname)检查数据库的空间分配,必须在单用户下执行
checkcatalog(dbname) 检查系统表的一致性
dbcc checkdb(dbname) 检查用户数据库的数据库一致性(包括系统表和用户表)
dbcc checktable(tablename) 检查一张表的数据一致性。
数据库的备份
数据库的备份对于日常的维护来说十分重要,系统管理员一定要注意数据库每天都有成功备份。需要检查备份的介质(磁盘或是磁带)是否正常。
备份命令:
dump database to ‘/xx/xxx’ (设备名或是磁盘上的文件名)
用户可以规划一个备份的计划,然后将备份的命令放在crontab 中,让系统自动定时做数据库的备份。
数据库的排错
数据库通常的错误主要是以下几种
数据库服务无法启动
解决:查看数据库的错误日志,根据错误日志找到无法启动的原因,原因通常是内存配置过大,或是数据库设备的属性不对,sybase用户没有访问权限。
数据库不能恢复(recovery)
解决:查看数据库的错误日志,找到数据库不能恢复的原因,然后做相应的处理。通常是由于系统突然断电或是系统非正常关机。如果不能解决,需要与Sybase的技术支持工程师联系。
用户表不能访问
解决:查看数据库的错误日志,找到不能访问的原因。通常是由于访问权限或是表损坏,如果不能解决,需要与Sybase的技术支持工程师联系。
其他错误:
需要系统管理员自己了解数据库的管理,如果问题不能解决,可以与Sybase的技术支持工程师联系。
数据库的性能优化
查看数据库的配置,看能否有更优化的配置。
查看方法参考上一节查看数据库的配置。
更新数据库的统计信息
update statistics tablename
对行锁表回收空间
reorg rebuild tablename
做空间回收时需要在系统维护时做
通过DBXray来监测和发现数据库性能问题
监测数据库的运行,查看是否阻塞缩
sp_lock
sp_who
对数据库系统运行进行监测,发现可能引起性能差的因素
在系统运行忙或是性能不佳时运行
sp_sysmon “00:10:00”
sp_showplan spid,null,null,null
通过SQLExpert对SQL语句进行优化
通过sp_showplan或是dbxray发现导致性能差的sql语句或存储过程,通过SQLExpert来进行优化。