Sybase数据库技术,数据库恢复

 

随着Sybase被完全整合到SAP下，Sybase原来的支持网站被SAP Support Portal取代。
只有购买了SAP服务的用户才能使用账号登录SAP Support Portal进行介质下载、补丁升级、报Incident等。
目前，原Sybase所有产品（包括：Adaptive Server Enterprise、Sybase IQ、Replication Server、PowerDesigner等）的官方手册仍然可以从https://infocenter.sybase.com/help/index.jsp进行浏览或下载。暂不清楚该网站https://infocenter.sybase.com/help/index.jsp何时会被完全迁移到SAP Support上！
Sybase官方手册英文版有html和pdf两种格式，而中文版手册只有pdf一种格式。为了国内Sybase用户更方便、快捷地搜索Sybase常见产品的官方手册内容，特将中文版Sybase官方手册转为html格式！
Sybase产品官方手册中文版的html格式所有内容的版权归SAP公司所有！本博客站长是Sybase数据库的铁杆粉丝！

如有Sybase数据库技术问题需要咨询，请联系我！

  QQ :289965371
  Email:

以下官方手册为ASE 15.7 ESD#2中文版：

1. 新增功能公告 适用于 Windows、Linux 和 UNIX 的 Open Server 15.7 和 SDK 15.7
   
2. 新增功能摘要
   
3. 新增功能指南
   
4. ASE 15.7 发行公告
   
5. 配置指南（windows）
   
6. 安装指南（windows）
   
7. 参考手册：构件块
   
8. 参考手册：命令
   
9. 参考手册：过程
   
10. 参考手册：表
    
11. Transact-SQL® 用户指南
    
12. 系统管理指南，卷 1
    
13. 系统管理指南，卷 2
    
14. 性能和调优系列：基础知识
    
15. 性能和调优系列：锁定和并发控制
    
16. 性能和调优系列：监控表
    
17. 性能和调优系列：物理数据库调优
    
18. 性能和调优系列：查询处理和抽象计划
    
19. 性能和调优系列：使用 sp_sysmon 监控 Adaptive Server
    
20. 性能和调优系列：利用统计分析改进性能
    
21. 程序员参考 jConnect for JDBC 7.0.7
    
22. Adaptive Server Enterprise 中的 Java
    
23. 组件集成服务用户指南
    
24. Ribo 用户指南
    
25. 内存数据库用户指南
    
26. Sybase Control Center for Adaptive Server® Enterprise
    
27. 安全性管理指南
    
28. 实用程序指南
    

 

< 上一个 | 内容 | 下一步 >

查询优化程序 ‌ ‌

查询优化程序可提高联机事务处理 (OLTP) 和操作方面的决策支持系统

(DSS) 环境的速度和效率。您可以选择最适合所在查询环境的优化策略。

查询优化程序可进行自调优，它需要的干预比 Adaptive Server Enterprise 15.0 之前的版本少。查询优化程序很少依靠工作表在操作步骤间获得实 现；但如果它确定散列和合并操作更有效，则可以使用更多工作表。

15.0 版的查询优化程序中的一些主要功能包括以下支持：

• 增强查询性能的新优化技术和查询执行运算符支持，例如：

• 使用内存中排序和散列的即时分组和排序运算符支持，用于带

group by 和 order by 子句的查询

• 对高效 join 操作的 hash 和 merge join 运算符支持

• index union 和 index intersection 策略，用于对不同索引进行带谓 词的查询

第 4 页的表 1-1 是 Adaptive Server Enterprise 提供的优化技术和运算 符支持的列表。其中许多技术直接映射为查询执行支持的运算符。 请参见 第 18 页的 “ Lava 查询执行引擎 ”。

• 改进了索引选择，尤其是对使用 or 子句的连接，以及使用 and 搜索 参数 (SARG) 的数据类型不匹配但兼容）的连接

• 改进了开销计算，利用连接直方图来防止因连接列中存在数据倾斜而 可能导致的不准确性

• 连接排序和计划策略中基于开销的新清理和超时机制，针对大型、 多向连接，以及星型和雪花模式连接

• 支持数据和索引分区 （为并行的构件块）的新优化技术，对超大型 数据集尤其有用

• 改进了针对垂直和水平并行度的查询优化技术。请参见 第 5 章 “并 行查询处理”

• 通过以下途径改进了问题的诊断和解决：

• 可搜索的 XML 格式跟踪输出

• 来自新 set 命令的详细诊断输出。请参见 第 3 章 “显示查询优 化策略和估计值”

表 1-1：优化运算符支持‌

运算符 说明

hash join 确定查询优化程序是否可使用 hash join 算法。 hash join 可能会消耗更多运行时 资源，但如果连接列中没有有用的索引，或与连接表中行数的乘积相比较而 言，有大量的行符合 join 条件，则它非常有用。

hash union distinct 确定查询优化程序是否可使用 hash union distinct 算法，如果大部分行都不同， 则该算法的效率较低。

merge join 确定查询优化程序是否可使用 merge join 算法，该算法依赖已排序的输入。例 如，如果对合并键上的输入进行排序 （例如从索引扫描中），则 merge join 最 为有用。如果对输入进行排序要求使用排序运算符，则会降低 merge join 的有 用性。

merge union all 确定查询优化程序是否可对 union all 使用 merge 算法。merge union all 保留联合 输入的结果行的顺序。如果输入已经过排序且父运算符 （如 merge join）受益 于该排序，则 merge union all 尤其有用。否则， merge union all 可能需要排序运 算符，而这会降低效率。

merge union distinct 确定查询优化程序是否可对 union 使用 merge 算法。 merge union distinct 与 merge union all 类似，但它不保留重复行。merge union distinct 需要已排序的输入 并提供已排序的输出。

nested-loop-join nested-loop-join 算法是 join 方法最常用的类型，在不需要排序的简单 OLTP 查询 中最为有用。

append union all 确定查询优化程序是否可对 union all 使用 append 算法。

distinct hashing 确定查询优化程序是否可使用散列算法删除重复项，如果与行数相比不同值很 少，则该运算符非常有效。

distinct sorted 确定查询优化程序是否可使用单传算法来消除重复项。 distinct sorted 依赖已排 序的输入流，如果其输入未经过排序，则可能会增加 sort 运算符数。

group-sorted 确定查询优化程序是否可使用即时分组算法。 group-sorted 依赖分组列上排序 的输入流，并在其输出中保持该顺序。

distinct sorting 确定查询优化程序是否可使用排序算法来消除重复项。如果输入未经过排序

（例如，如果没有索引），并且排序算法生成的输出顺序可能有用，则 distinct sorting 会很有用；例如在合并连接中。

group hashing 确定查询优化程序是否可使用 group hashing 算法来处理集合。

方法 说明

multi table store ind 确定查询优化程序是否可对多个表 join 的结果进行重新格式化。使用 multi table store ind 可能会增加工作表的使用率。

opportunistic distinct view 确定查询优化程序能否在强制执行差别操作时使用更为灵活的算法。

index intersection 确定查询优化程序能否将多个索引扫描的交集用作搜索空间中查询计划的一 部分。

优化查询时分析的因素 ‌

查询计划包含检索策略和一组有序的执行步骤，可用来检索查询所需的 数据。制定查询计划时，查询优化程序将检查：

• 查询中每个表的大小 （按行和数据页计算），以及要读取的 OAM

页和分配页的数目。

• 查询中使用的表和列上存在的索引、索引类型以及每个索引的高 度、叶页数量和聚簇比。

• 查询的索引范围；也就是说，能否通过检索索引叶页中的数据来满 足查询而不用访问数据页。即使查询中不包括 where 子句，Adaptive Server 也可以使用将覆盖查询的索引。

• 索引中键的密度和分配。

• 可用数据高速缓存的大小、高速缓存支持的 I/O 大小和将使用的高 速缓存策略。

• 物理读取和逻辑读取操作的开销；也就是说，从磁盘进行物理 I/O

页读取以及从主内存进行逻辑 I/O 读取的开销。

• join 子句 （具有最佳连接顺序和连接类型），考虑每个连接所需的 开销和扫描次数，以及索引在限制 I/O 方面的效果。

• 如果 join 中没有用于内部表的有用索引，那么使用连接列的索引建 立工作表 （内部临时表）的速度是否快于重复的表扫描。

• 查询是否包含可使用索引查找值而无需扫描表的 max 或 min 集合。

• 是必须重复使用数据或索引页以满足查询 （例如， join），还是可 以因为只需对这些页进行一次扫描而使用读取和放弃策略。

对于每个计划，查询优化程序通过计算逻辑和物理 I/O 以及 CPU 处理的 开销来确定总开销。如果存在代理表，还会估计额外的网络相关开销。 然后，查询优化程序会选择开销最低的计划。

Adaptive Server 15.0.2 及更高版本的查询处理器将对存储过程中的语句 的优化延迟到执行这些语句时进行。这有益于查询处理器，因为局部变 量的值可用于优化其各自的语句。

早期版本的 Adaptive Server 使用缺省猜口令对使用局部变量的谓词进行 选择性估计。

查询优化转换

在分析和预处理某个查询后，但在查询优化程序开始对其进行计划分析 之前，要对该查询进行转换，以增加可优化的子句数。优化程序所做的 这种转换更改是透明的，除非检查像 showplan、dbcc(200)、statistics io 或 set 命令这样的查询调优工具的输出。如果运行的查询通过添加经优化的 搜索参数得到了改善，则会看到添加的子句。在 showplan 输出中，对于 没有为其指定搜索参数或连接的表，该子句显示为 “Keys are”消息。

转换为等效参数的搜索参数

优化程序查找查询子句，以转换为可供搜索参数使用的形式。这些子句 在 表 1-2 中列出。

表 1-2：等效的搜索参数

子句 转换

between 转换为 >= 和 <= 子句。例如， between 10 and 20 被转换为

>= 10 and <= 20。

like 如果模式中的第一个字符是常量，则 like 子句可能被转换为 大于或小于查询。例如， like "sm%" 变为 >= "sm" and < "sn"。 如果第一个字符是一个通配符，则诸如 like "%x" 这样的子句 无法使用索引进行访问，但可以使用直方图值来估计匹配 行的数目。

in(values_list) 转换为 or 查询列表，也就是说，int_col in (1, 2, 3) 变为 int_col = 1 or int_col = 2 or int_col = 3。 in-list 中元素的最大 数量为 1025 个

适当应用搜索参数传递闭包

优化程序可将传递闭包应用于搜索参数。例如，以下查询在 title_id 上连 接 titles 和 titleauthor，并在 titles.title_id 上包括一个搜索参数：

select au_lname, title

from titles t, titleauthor ta, authors a where t.title_id = ta.title_id

and a.au_id = ta.au_id and t.title_id = “T81002”

此查询已优化，就好像它也在 titleauthor.title_id 上包括该搜索参数：

select au_lname, title

from titles t, titleauthor ta, authors a where t.title_id = ta.title_id

and a.au_id = ta.au_id and t.title_id = “T81002” and ta.title_id = “T81002”

通过这一附加子句，查询优化程序可以使用 titles.title_id 上的索引统计信 息来估计 titleauthor 表中匹配行的数目。更加精确的开销估计改善了索引 和连接顺序的选择。

equi-join 谓词传递闭包

在适用的情况下，应用优化程序可将传递闭包应用于常规 equi-join 的连 接列。以下查询指定 t1.c11 和 t2.c21 的 equi-join，以及 t2.c21 和 t3.c31 的 equi-join：

select *

from t1, t2, t3

where t1.c11 = t2.c21

and t2.c21 = t3.c31 and t3.c31 = 1

如果没有连接传递闭包，则只考虑以下连接顺序：( t1, t2, t3 )、( t2, t1, t3 )、 ( t2, t3, t1 ) 和 ( t3, t2, t1 )。通过在 t1.c11 = t3.31 上添加 join，查询处理器可扩 展 join 顺序列表，使其包括以下顺序：( t1, t3, t2 ) 和 ( t3, t1, t2 )。搜索参数 传递闭包能够将 t3.c31 = 1 指定的条件应用于 t1 和 t2 的 join 列。

类似地， equi-join 传递闭包还可应用于使用 or 谓词的 equi-joins，如下 所示：

select * from R,S

where R.a = S.a

and (R.a = 5 OR S.b = 6)

查询优化程序推断这等同于：

select * from R,S

where R.a = S.a

and (S.a = 5 or S.b = 6)

or 谓词可以在 S 扫描中求值，并且有可能用于 or 优化，从而有效地使用

S 的索引。

再如，连接传递闭包可应用于复杂 SARG，因此，下面这样的查询：

select * from R,S

where R.a = S.a and (R.a + S.b = 6)

被转换并推断为：

select * from R,S

where R.a = S.a and (S.a + S.b = 6)

复杂谓词可在 S 扫描中求值，从而因提前对结果集进行了过滤而使性能 显著提高。

传递闭包仅用于上述常规 equi-join。 join 传递闭包不能用于：

• 非 equi-join ；例如， t1.c1 > t2.c2

• 外连接；例如 t1.c11 *= t2.c2、 left join 或 right join

• 跨越子查询边界的连接

• 用于检查参照完整性或对视图执行 with check option 的连接

注释 自 Adaptive Server Enterprise 15.0 起，用来打开或关闭 join 传递闭 包和 sort merge join 的 sp_configure 选项已停用。在适用的情况下，始终 能够在 Adaptive Server Enterprise 15.0 及更高版本中应用 join 传递闭包。

为提供额外优化路径所进行的谓词转换和分解 ‌

谓词转换和分解增加了查询处理器可用的选择数。通过从用 or 链接的谓 词块中将子句提取到由 and 链接的子句中，可添加可优化的查询子句。 这些经过优化的附加子句表明有更多的访问路径可用于查询执行。最初 的 or 谓词仍然保留以确保查询的正确性。

在谓词转换过程中：

1 是每个 or 子句中的精确匹配的简单谓词 （连接、搜索参数和 in 列 表）被提取。在下面步骤 3 的查询中，该子句在每个块中精确匹配， 因此，它被提取出来：

t.pub_id = p.pub_id

between 子句在谓词转换前被转换为大于等于和小于等于子句。以上 查询示例在两个查询块 （尽管结束范围不同）中都使用了 between 15。以下等效子句由步骤 1 提取：

price >=15

2 同一表上的搜索参数被提取；在扩展过程中，引用同一个表的所有 术语都被视为一个单一谓词。 type 和 price 都是 titles 表中的列，因 此，提取的子句是：

(type = "travel" and price >=15 and price <= 30)

或者

(type = "business" and price >= 15 and price <= 50)

3 in 列表和 or 子句被提取。如果块内的一个表有多个 in 列表，则只提 取第一个列表。为查询示例提取的列表是：

p.pub_id in ("P220", "P583", "P780")

或者

p.pub_id in ("P651", "P066", "P629")

由于这些步骤可以重叠和提取同一子句，从而删除了重复项。

生成的每个术语都经过检查，以确定能否将其用作经过优化的搜索 参数或 join 子句。只保留那些对于查询优化有用的术语。

附加的子句被添加到用户指定的查询子句中。

例如，在下面的查询中，优化的所有子句都用括号括起来放在 or 子 句中：

select p.pub_id, price from publishers p, titles t where (

t.pub_id = p.pub_id and type = "travel"

and price between 15 and 30

and p.pub_id in ("P220", "P583", "P780")

)

or (

t.pub_id = p.pub_id and type = "business"

and price between 15 and 50

and p.pub_id in ("P651", "P066", "P629")

)

如上所示，谓词转换从用 or 链接的子句块中提取出用 and 链接的子句。 它只提取所有加了括号的块中出现的子句。如果上例中有一个子句位于 用 or 连接的某个块中，而它未出现在其它子句中，则不提取这个子句。

处理搜索参数和有用索引 ‌

必须区分可用于优化查询的 where 和 having 子句谓词，以及以后在查询 处理期间用于过滤返回的行的子句谓词。

当 where 子句中的某列与索引键匹配时，可以使用搜索参数来确定数据 行的访问路径。该索引可用于定位和检索匹配的数据行。一旦该行已定 位于数据高速缓存，或该行已从磁盘读入数据高速缓存，则会应用任何 剩余子句。

例如，如果 authors 表在 au_lname 上有一个索引，并且在 city 上有另一个 索引，则每个索引都可用于为此查询确定匹配行：

select au_lname, city, state from authors

where city = "Washington" and au_lname = "Catmull"

查询优化程序使用统计信息 （包括直方图、表中的行数、索引高度以 及索引和数据页的集群比）来确定哪个索引可提供开销最低的访问。选 择访问数据页的开销最低的索引并将其用于执行查询，并在访问数据行 后将另一个子句应用到这些数据行。

不等式运算符

不等式运算符 < > 和 != 属于特殊情况。查询优化程序检查在为列建立了 索引的情况下，是否应覆盖非聚簇索引，以及在索引覆盖查询时是否使 用非匹配索引扫描。但是，如果索引不覆盖查询，则在索引扫描期间， 将通过数据页的行 ID 查找来访问表。

搜索参数优化示例

以下为可完全优化的子句的示例。如果有这些列的统计信息，它们可用 于帮助估计查询将返回的行数。如果有列的索引，则可以使用这些索引 访问数据。

au_lname = "Bennett" price >= $12.00

advance > $10000 and advance < $20000 au_lname like "Ben%" and price > $12.00

不能优化这些搜索参数，除非在其上建立功能索引：

advance * 2 = 5000 /*expression on column side

not permitted */ substring(au_lname,1,3) = "Ben" /* function on

column name */

如果使用以下格式编写，就可对这两个子句进行优化：

advance = 5000/2 au_lname like "Ben%"

考虑以下查询，在 au_lname 上只有一个索引：

select au_lname, au_fname, phone from authors

where au_lname = "Gerland" and city = "San Francisco"

该子句限定为一个搜索参数：

au_lname = "Gerland"

• au_lname 上有一个索引。

• 对于列名没有函数或其它运算。

• 运算符是一个有效搜索参数运算符。

此子句符合除上述第一条外的所有条件； city 列上没有索引。在这种情 况下， au_lname 上的索引用于查询。带有匹配姓氏的所有数据页都被 调入高速缓存，并检查每个匹配行以查看 city 是否匹配搜索条件。

处理 join

查询优化程序处理连接谓词的方式与处理搜索参数的方式一样，它使用 统计信息、表中的行数、索引高度、索引与数据页的集群比来确定哪个 索引和连接方法可提供开销最低的访问。此外，查询优化程序还使用源 自连接直方图的连接密度估计，而连接直方图可对限定连接行和要在外 部和内部表中扫描的行进行准确估计。查询优化程序还必须决定最佳连 接顺序，以便生成最有效的查询计划。下面几节将介绍处理连接时使用 的主要技术。

连接密度和连接直方图

查询优化程序将开销模型用于使用连接属性的表规范化直方图的连接。 该技术给出了一个确切的倾斜值 （即频率计数），并使用每个直方图中 的域单元密度来估计相应域单元的单元计数。

连接密度是根据 “连接直方图”经过动态计算得出的，其中考虑了来 自连接运算符两侧的直方图的连接。第一个直方图连接通常发生在两个 基表之间以及两个属性都具有直方图时。每个直方图连接都在父连接投 影的相应属性上创建一个新的直方图。

即便连接列的数据分配倾斜，也可以使用连接直方图技术进行准确的选 择性估计，从而获得最佳连接顺序和性能。

表达式直方图选择性估计

Adaptive Server 15.0.2 之前的版本使用缺省 “猜口令”进行选择性估计。

Adaptive Server 15.0.2 及更高版本将直方图估计应用于单列谓词 （如果 该列上存在直方图）。这样可使行估计更精确，并改进了查询计划的连 接次序选择。

在此示列中，如果表达式的选择性非常大，最好还是将表 t1 放在连接顺 序的开头：

select * from t1,t2 where substring(t1.charcol, 1, 3)

= "LMC" and t1.a1 = t2.b

具有混合数据类型的连接

一个基本要求是，尽可能为索引查找建立键，而不考虑任何连接谓词与 索引键的混合数据类型。考虑以下查询：

create table T1 (c1 int, c2 int) create table T2 (c1 int, c2 float) create index i1 on T1(c2)

create index i1 on T2(c2)

select * from T1, T2 where T1.c2=T2.c2

假定 T1.c2 属于 int 类型并且它上面有一个索引， T2.c2 属于 float 类型并 且具有一个索引。

只要数据类型可隐式转换，查询优化程序就可以使用索引扫描来处理连 接。换句话说，即使外部表中查找值的数据类型不同于内部表的相应索 引属性，查询优化程序也使用外部表中的列值在内部表上定位索引扫描。

使用表达式和 or 谓词的连接

请参见 第 8 页的 “为提供额外优化路径所进行的谓词转换和分解 ”，其 中介绍了查询优化程序如何处理使用表达式和 or 谓词的连接。

join 顺序

查询优化程序的主要任务之一是为 join 查询生成查询计划，以使查询执 行期间所处理的连接中的关系顺序为最佳。这需要使用将消耗大量时间 和内存的详细的计划搜索策略。查询优化程序通过几种有效的技术来获 得最佳连接顺序。主要技术包括：

• 利用模糊策略获得一个较好的初始顺序，并以此作为排除其它后续 连接顺序的上限。该模糊策略使用连接行估计和嵌套循环连接方法 来获得初始顺序。

• 在模糊策略后采用详尽的顺序策略。在这种策略中，可能更好的连 接顺序取代了在模糊策略中获得的连接顺序。这种顺序可使用任何 join 方法。

• 利用广泛采用的、基于开销和规则的清理技术排除不需要的连接顺 序。清理技术的主要特点是，它始终可以将部分连接顺序 （可能连 接顺序的前缀）与最佳完整连接顺序相比较，从而确定是否继续使 用给定前缀。这将显著缩短确定最佳连接顺序所需的时间。

• 查询优化程序可识别和处理星型模式或雪花模式连接，并能够以最 有效的方式处理其连接顺序。典型的星型模式 join 包含一个大型 Fact 表，该表具有 equi-join 谓词，通过这些谓词，该表与几个 Dimension 表连接。 Dimension 表不具有使它们彼此相连的 join 谓词；也就是说， Dimension 表本身之间没有连接，但在 Dimension 表和 Fact 表之间有 join 谓词。查询优化程序可使用特殊的 join 顺序技术，通过运用这种 技术，大型 Fact 表被推至连接顺序的末尾，而 Dimension 表则被拉 到前面，从而生成高效查询计划。但是，如果星型模式连接包含子 查询、外连接或 or 谓词，则查询优化程序则不会使用该技术。

< 上一个 | 内容 | 下一步 >