首次使用job scheduler的时候需要重建一个表的索引
在使用ASE15.0.3或者ASE15.5这两个版本的job scheduler的时候，都遇到了需要重建一个表的索引的情况。 这个情况我不止在一台机器上遇到了。
下面是在用ASE15.5自带的Sybase Central中建立日程表的时候出现的错误：
用isql登录数据库，查看一下object_id：1792006384是哪张表，这张表的哪个索引坏了？
通过select object_name(1792006384)查询出来表名为：js_keys
查询表js_keys内数据的时候，报索引损坏的错误：
1> select count(*) from js_keys
2> go
Index id 2 on table id 1792006384 cannot be used in the optimization of a query
as it is SUSPECT. Please have the SA run DBCC REINDEX on the specified table.
-----------
5
(1 row affected)
通过上面给出的提示信息，可以看出表js_keys的indid=2的索引坏了。需要重建该表的索引。
使用reindex命令来修复表js_keys的损坏的索引：
dbcc traceon(3604)
go
dbcc reindex(js_keys)
go
反馈信息为：
1> dbcc traceon(3604)
2> go
DBCC execution completed. If DBCC printed error messages, contact a user with
System Administrator (SA) role.
1> dbcc reindex(js_keys)
2> go
Checking table 'js_keys' (object ID 1792006384): Logical page size is 4096
bytes.
Checking partition 'js_keys_1792006384' (partition ID 1792006384) of table
'js_keys'. The logical page size of this table is 4096 bytes.
The sortorder and character set ID's for index 2 on this table were 50:1 in
sysindexes. They have been corrected to 101:190.
The indexes for 'js_keys' are already correct. They will not be rebuilt.
DBCC execution completed. If DBCC printed error messages, contact a user with
System Administrator (SA) role.
用checktable命令检查一下表js_keys
1> dbcc checktable(js_keys)
2> go
Checking table 'js_keys' (object ID 1792006384): Logical page size is 4096
bytes.
Checking partition 'js_keys_1792006384' (partition ID 1792006384) of table
'js_keys'. The logical page size of this table is 4096 bytes.
The total number of data pages in partition 'js_keys_1792006384' (partition ID
1792006384) is 1.
Partition 'js_keys_1792006384' (partition ID 1792006384) has 5 data rows.
The total number of empty pages (with all deleted rows) in partition
'js_keys_1792006384' (partition ID 1792006384) is 0.
The total number of pages in partition 'js_keys_1792006384' (partition ID
1792006384) which could be garbage collected to free up some space is 0.
The total number of deleted rows in partition 'js_keys_1792006384' (partition ID
1792006384) is 0.
The total number of pages in partition 'js_keys_1792006384' (partition ID
1792006384) with more than 50 percent garbage is 0.
The total number of pages in partition 'js_keys_1792006384' (partition ID
1792006384) with more than 50 percent insert free space is 1.
The total number of data pages in this table is 1.
The total number of pages with more than 50 percent insert free space is 1.
Table has 5 data rows.
DBCC execution completed. If DBCC printed error messages, contact a user with
System Administrator (SA) role.
1>
至此，表js_keys索引已修复完成，一致性检查没有问题了。
上面的日程表也添加了一条记录：aaaa
另外感觉很奇怪的是：
在重建表js_keys损坏的索引时，报：
The sortorder and character set ID's for index 2 on this table were 50:1 in
sysindexes. They have been corrected to 101:190.
在Solaris平台上ASE默认的字符集为：iso_1,排序顺序为：bin_iso_1。安装完服务后，字符集给调成了utf8，排序顺序为不区分大小写：utf8_nocase
job scheduler数据库是在安装服务的时候安装的，而字符集调整为utf8的操作在后面进行的。
为什么表js_keys索引indid=2的字符集没有被调整成utf8呢？
索引页有信息标志使用的字符集？