第一次sybase的使用
项目需要,要用sybase数据库. 当作一次学习点点滴滴记下来.
sybase中字段缺省值查看以及修改
如果没有sybase central(或者由于字符集原因无法看到表的ddl语句的时候)或者rapid sql等工具的情况下
可以使用isql或者sql advantage登录.
sp_help table_name.看到某个字段的default_name
对应为"表名_数字"
select text from syscomments where id=数字(上述"表名_数字"中的数字.)
如果不是所要的,可以使用
alter table table_name replace 字段名 defualt defualt_value.即可.
1.总是日志满,要删除 (或许有别的方法,类似增大日志文件容量的方法,但我没找到,只能用下面的语句.)
dump tran master with no_log
还有一条语句
dump tran dbname with truncate_only
(2)设置字符集,使数据库支持中文.
(转至园友)
(这里SYBASE的安装路径为c:\sybase)
1.c:\>cd \sybase\charsets\cp936
2.c:\sybase\charsets\cp936> charset -U用户名 -P密码 -S数据库服务器名称 binary.srt cp936
更改默认字符集为cp936
3.在SQL环境中
1>select name,id from syscharsets(会列出字符集对应的id号)
2>go
找到name为cp936对应的id(假设为171)
.1>sp_configure "default character set id",171
2>go
5.重启server两次
（注:第一次启动后，server会自动宕掉，需要第二次重启后才能使用）
清空提交日志dump tran dbname with truncate_only
(3)12.5版的sybase不支持instead of触发器.有主外键关系时.因此级联删除只好用存储过程...毕竟触发器也是特殊的存储过程.
(4)有些基本的参考文件,适合人类观看.
https://files.cnblogs.com/gecko/sybase参考手册.rar
https://files.cnblogs.com/gecko/Sybase数据库系统管理指南.rar
https://files.cnblogs.com/gecko/sybasedoc.rar 官方文档
（5）自增跳号
跳号原因及影响：
在Sybase数据库中如果数据库在开启的情况下，因为非正常的原因（死机、断电）而导致数据库服务进程强制结束。
那么自动增长的字段将会产生跳号的情况，再往数据表里面插入记录时，自增字段会跳到一个相当大的值上面，以至于主键的自增值极有可能被用尽，或由于数值太大，应用程序中的数据类型如int型等已无法容下这么大的值，而无法在程序里面进行相关的操作。
解决办法：
如果还未发生过跳号情况，可按如下办法解决：
1.执行【 select 'sp_chgattribute ' + name + ', ''' + 'identity_gap' + '''' + ', 60 go'
from sysobjects
where type='U'】。其中的60是凭感觉给的一个值，一般来说这个值越大性能越好，但越大，再发生数据库服务进程非正常结束时，所跳的号也就越大。
2.对1执行的结果，拷贝到SQL编辑区域，再执行。
若已经发生跳号，需要将表中数据导出，再重建数据表，再执行1和2。再导入数据。
后话：
Sybase自增字段有个最大的问题是，再移植数据库时，如果是按自增主键进行关联的数据表，在数据重新导入后，可能出现主从表的外键无法关联的情况，我是开始时没预料到这样的情况，现木已成舟，没有办法了。 以后还是要慎用自增字段作为主键。
一. SYBASE 系统参数调整
1.内存
sp_configure "max memory",1500000 重启生效（设置为共享内存的75%）
sp_configure "allocate max shared mem",1 启动的时候自动分配max memory指定的最大内存
sp_cacheconfig "default data cache","1500m" 设置数据缓存（设置为max memory的一半）
sp_cacheconfig "default data cache","cache_partition=2" 是CPU数量的倍数,对数据缓冲区分区
sp_poolconfig "default data cache","64m","16k" 设置16K 数据缓存
sp_poolconfig "default data cache","128m","8k" 设置8K 数据缓存
sp_configure "procedure cache size",90000 存储过程数据缓存sp_cacheconfig 'tempdb_cache','200m','mixed' 创建命名高速缓存sp_bindcache 'tempdb_cache',tempdb 捆绑临时数据库到tempdb_cache高速缓存
2.cpu
sp_configure "max online engines",2 设置使用的CPU数量
sp_configure "number of engines at startup",2 启动时使用CPU数量
3. 网络
sp_configure "default network packet size",2048 设置网络传送包的大小(重启动生效)
sp_configure "max network packet size",2048
4. 其他资源使用
sp_configure "number of locks",100000 锁使用数量
sp_configure "number of open indexes",5000 打开索引
sp_configure "number of open objects",5000 打开对象
sp_configure "number of user connections",1000 用户连接数
sp_configure "number of device",100 新建设备最大数量
二. sybase 设备调整
数据设备与日志设备必须分开，添加临时数据库设备
1. 数据设备
sp_deviceattr devname,"dsync",true
2. 日志设备
sp_deviceattr devname,"dsync",false
3. 临时数据库设备
sp_deviceattr devname,"dsync",false
三. sybase 数据结构调整
1. 数据库对象表、索引。。
(1)对表新建合理的索引，定期分析表
update statistics tabname (不锁表)
(2)整理数据库空间 (锁表，剩余空间必须为最大表的1.2倍)
reorg rebuild tabname
recreate clustered index
(3)重新编译存储过程与触发器
sp_recompile usertable (与表相关联的存储过程和触发器)
四. sybase 数据库监控
1. 数据库死进程
select * from master..syslogshold
五. sybase 数据库启动参数
-T3607 master
-T3608 其他数据
-m 单
####################################################################################################################
ybase优化处理
所以tempdb的优化应该受到特别的关注。本篇文章目的在于使你掌握临时数据库的优化策略以及临时表的优化使用。本文中，你将以调整临时库的位置开始，
有步骤的完成临时数据库的优化，并在此过程中了解到优化临时数据库和临时表的一些方法和规则。实验环境的要求：你应具有系统管理员的权限，
系统中有auths和article表。步骤：第一步：调整临时库的位置 tempdb数据库缺省放在master设备上，将临时数据库发在分离的设备上是更可取的。
1）初始化一个用来存放临时数据库的设备 diskinit name="tempdb_dev", physname="d:\sybase\example\tempdb.dat", vdevno=13, size=15360
(注意：如果将tempdb数据库放在多个设备上，需初始化多个数据库设备)
2)将临时数据库扩展到该一个设备上 alterdatabasetempdbontempdb_dev=30
3)打开tempdb数据库，从段上删除master设备 sp_dropsegment"default",tempdb,master sp_dropsegmentlogsegment,tempdb,master
4)发出如下命令，检查default段中是否不再包含master设备 selectdbid,name,segmapfromsysusages,sysdevices where
sysdevices.low<=syusages.size+vstart andsysdevices.high>=sysusages.size+vstart-1
anddbid=2 and(status=2orstatus=3)
说明：若将临时数据库放在多个磁盘设备上，可以更好的利用并行查询特性来提高查询性能。
第二步：将临时数据库与高速缓冲进行绑定。 由于临时表的创建、使用，临时数据库会频繁地使用数据缓存，所以应为临时数据库创建高速缓存，
从而可以使其常驻内存并有助于分散I/O：
1、创建命名高速缓存 sp_cacheconfig“tempdb_cache”,”10m”,”mixed”
2、重新启动server
3、捆绑临时数据库到tempdb_cache高速缓存 sp_bindcache“tempdb_cache”,tempdb
4、若有大的I/O，配置内存池第三步：优化临时表大多数临时表的使用是简单的，很少需要优化。
但需要对临时表进行复杂的访问则应通过使用多个过程或批处理来把表的创建和索引分开。以下两种技术可以改善临时表的优化 slash;在临时表上创建索引
1）临时表必须存在
2）统计页必须存在（即不能在空表上创建索引） slash;把对临时表的复杂的使用分散到多个批处理或过程中，
以便为优化器提供信息下面的这个过程需要进行优化：
createprocbase_proc as select*into#huge_resultfromauths select*fromarticle,#huge_resultwherearticle.author_code= #huge_result.author_codeandsex=”0”
使用两个过程可以得到更好的性能
1）createprocbase_proc as select* into#huge_result fromauths execselect_proc
2)createprocselect_proc as select*fromarticle,#huge_result wherearticle.author_code=#huge_result.author_codeandsex=”0”
说明：在同一个存储过程或批处理中，创建并使用一个表时，查询优化器无法决定这个表的大小。
结论：通过本实验我们知道，临时数据库经过优化可以极大的提高系统性能。实际工作中，必须考虑具体应用的情况，需长时间经验的积累
环境: WIN2000 ADV , SYBASE12.5 中文版.
数据加工生产库, 白天上班应用,晚上关机.
问题描述: 今天早上开服务器,启动SYBASE服务时,感觉比平时慢了许多. 查看NT日志,有一条'
Sybase SQLServer _ YESKY 服务因 13 服务性错误而停止。 '
晕了,昨天晚上没有服务就关服务器了? 服务起来了,当时检查数据库也没发现什么问题..
上班了,有一道工序的员工反应应用程序出现: 'XX值超出最大范围,请与管理员联系' . 检查相应表里的数据,(该表里有一个字段为numeric,设为自动加1,字段定义为 test1
numeric(10,0) IDENTITY ,) 表现该字段最大值为5028502,而它下面比它小的那个字段值为28501,将值为5028502的这条记录删除,再来,最大值成了5028503.删了再来,5028504. 不
行了,看来出问题了....
经多方求教,问题已经得到解决,现写出对问题的分析及解决办法,共大家参考:
出现这个错误与SYBASE处理IDENTITY的策略有关.SYBASE在启动时会取出一段值放在内存中，IDENTITY是从内存中取的，在关机时，再写回到数据库中，如果非正常关机，则，
，，
分析原因:db-server服务器出现故障或用no wait关机。导致分配ID号码块被‘烧毁’，当db-server服务器再次运行时，它会以先前写入磁盘的块的最高号码为基础，开始为
下一号码块编号。依据出现故障前被指派到行中的已分配号码的多少，ID号可能会有很大的间隔。
解决方法： 在该表上加上 with identity_gap = number 参数即可.
with identity_gap 是为表指定标识间距。此值仅替换为此表设置的标识距。
执行
sp_chgattribute 'table_name','identity_gap',number
可用sp_help 查看表的identity_gap的设置
number的值不要设置的过低，会使性能降低
建议为50， 这样你的数据最大的数据间隔是50
结果: 执行
sp_chgattribute 'table_name','identity_gap',number
问题解决.
教训:一定要正常关机!
其实,这也是大家帮助我解决的,在些也对你们表示感谢!
本人菜鸟一只,但我一直在努力,学习也是一个过程....
发这个帖子的目的,在于抛砖引玉.
希望大家把平时遇到的问题,即使问题已经解决了,
也整理一下,贴出来,对于自己也是一个总结.
对于大家也是一个学习,交流的机会....
说不定对这个问题,还可以有更好的解决办法呢.
