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. 实用程序指南
    

 

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

为服务器选择字符集 ‌ ‌ ‌

服务器中的所有数据都用特殊代码进行编码。例如，将字母“ a”编码 为十进制的“97”。字符集是字符（包括字母和数字字符、符号和非打 印控制字符）及为其指派的数字值或代码的特定集合。字符集通常包含 一个字母表中的字符，例如，英语中使用拉丁字母表，而诸如俄语、塞 尔维亚语和保加利亚语等语言使用古斯拉夫语之类的脚本。平台专用并 支持一组语言（如西欧语言）子集的字符集称为本地或国家字符集。除 了 Unicode UTF-8 之外，Adaptive Server 使用的所有字符集都是本地字 符集。

脚本 是一个书写系统，是具有某种人类语言（例如拉丁语、日语或阿拉 伯语）书写格式特征的所有元素的集合。根据字母表或脚本所支持语言 的不同，字符集可支持一种或多种语言。例如，拉丁字母表支持西欧语 言（请参见 第 300 页的表 10-1中的第 1 组）。另一方面，日语脚本仅支

持日语这一种语言。因此，组 1 中的字符集支持多种语言，而许多字符

集，如组 101 中的字符集，仅支持一种语言。

字符集所包含的一种或多种语言称为 语言组。语言组可包含多种语言或 仅一种语言，本地字符集是特定语言组的一种或多种语言字符的特定平 台编码。

在客户端/服务器网络中，如果所有语言都属于同一语言组（请参见

第 300 页的表 10-1），则您可以支持采用多种语言的数据处理。例如， 如果服务器中的数据用组 1 中的字符集编码，则同一数据库中可以有法

语、德语和意大利语数据以及任何其它在组 1 中的语言。然而，在同一

数据库中不可以存储来自其它语言组的数据。例如，不可以将日语数据 和法语或德语数据一起存储。

与刚刚介绍的本地字符集不同， Unicode 是支持世界上 650 多种语言（例 如日语、中文、俄语、法语和德语）的国际字符集。Unicode 允许在同 一服务器上混合使用不同语言组的不同语言，并与平台无关。有关详细 信息，请参见 第 301 页的“ Unicode ”。

由于所有字符集都支持拉丁语脚本，并且因而支持英语，所以一个字符 集总是至少支持两种语言，即英语和另外一种语言。

许多语言由超过一种的字符集所支持。为某种语言安装的字符集取决于 客户端平台和操作系统。

Adaptive Server 支持以下语言和字符集：

表 10-1：支持的语言和字符集

a. 除了 0x80-0x9F 码点在 CP 1252 中映射为字符以外，CP 1252 与 ISO 8859-1 完全相同。

b. CP 950 与 Big 5 相同。

注释 由于任何字符集的前 128（十进制）个字符都包含拉丁字母表（定 义为“ASCll-7”），因此所有字符集都支持英语。各字符集中前 128 个

字符之外的字符各不相同，用于支持不同的本地语言字符。例如，CP 932

和 CP 874 中的码点 0-127 都支持英语和拉丁字母表。但是，码点 128-255

在 CP 932 中支持日语字符，而在 CP 874 中支持泰语字符。

以下字符集支持欧洲货币符号“欧元”： CP 1252（西欧）、CP 1250

（东欧）、CP 1251（古斯拉夫语）、CP 1256（阿拉伯语）、CP 1253

（希腊语）、CP 1255（希伯来语）、CP 1254（土耳其语）、CP 874

（泰语）、iso15、roman9 和 CP858。Unicode UTF-8 还支持：

• Windows 和 Solaris 平台上的繁体中文

• Linux 平台上的阿拉伯语、希伯来语、泰语和俄语

注释 iso_1 和 ISO 8859-1 是同一字符集的不同名称。

若要混合使用不同语言组中的语言，您必须 使用 Unicode。如果服务器 字符集是 Unicode，则可在单一服务器上支持超过 650 种的语言，并且 可混合不同语言组中的语言。

Unicode ‌

Unicode 是第一个支持使用同一数据集对世界上的所有语言进行编码的 字符集。在引入 Unicode 之前，例如，如果要以中文存储数据，则必须 选择适合该语言的字符集，这样就将其它大多数语言排除在外。将不同 的字符集混合在一起，从而在同一数据集中使用多种语言是不可能或不 切实际的。 ‌

Sybase 支持以下三种数据类型的 Unicode：unichar、univarchar 和 unitext。 这些数据类型以 Unicode 的 UTF-16 编码方式存储数据。

在 UTF-16 编码方式中，Unicode 标量值用一个 16 位值表示（或者，在 少数情况下，用一对 16 位值表示）。这三种编码方式中的任一种都可用 于表示所有 Unicode 字符，从这方面来说，它们是等同的。之所以选择 使用 UTF-16 数据类型，而不使用 UTF-16 服务器缺省字符集，是为了实 现对现有数据库应用程序的简单、分步迁移。

Adaptive Server 支持在 SQL 查询中使用 Unicode 文字，并且支持 UTF-8

的多种排序顺序。

Adaptive Server 使用的字符集模型基于单个可配置的全服务器范围的字 符集。使用任一种“字符”数据类型（char、varchar、nchar、nvarchar 和 text）存储在 Adaptive Server 中的所有数据都被解释为在此字符集中。排 序顺序是用此字符集定义的，语言模型（翻译为本地语言的服务器消息 集合）也是。

在连接对话框期间，客户端应用程序声明其本地字符集和语言。如果配 置正确，服务器之后会尝试在自己的字符集和客户端的字符集之间转换 任何字符数据（字符数据包括存储在数据库中的任何数据，以及采用客 户端本机语言的服务器消息）。只要服务器和客户端的字符集兼容，这 就没有问题。但是，如果字符在另一字符集中未定义，就会出现问题。 例如，用于日语的字符集 SJIS、用于俄语的 KOI8 和其它古斯拉夫语言。 这种不兼容性就是引入 Unicode 的原因。我们可将 Unicode 看作一个超 字符集，它包括其它所有字符集中的字符的定义。

Unicode 数据类型 unichar、univarchar 和 unitext 完全独立于传统的字符集 模型。客户端单独发送和接收 Unicode 数据，与其发送和接收的任何其 它字符数据无关。

安装字符集

Adaptive Server 版本 12.5.1 和更高版本支持 4 个字节格式的 UTF-8，这 种格式用于表示在 UTF-16 中用 16 位值对（“代理对”）表示的少数特 殊 Unicode 字符。在 Adaptive Server 版本 12.5.1 之前，只支持 3 个字节 格式的 UTF-8。如果在 Adaptive Server 12.5.1 版之前的服务器上安装了 UTF-8 字符集，则应重新安装该字符集，以便能够使用 4 个字节格式的 UTF-8。

配置参数

Unicode 的 UTF-16 编码包括“代理对”，这些代理对是表示很少使用的 字符的 16 位值对。Adaptive Server 中内置了额外的检查机制，以确保代 理对的完整性。可以通过将配置参数“enable surrogate processing”设置 为 0 来关闭此检查机制。尽管这样做将不再确保代理对的完整性，但可 以使性能得到略微提高。

Unicode 还定义了“规范化”过程，通过这一过程，一个字符的所有可能 表示形式都将被转换为单一的表示形式。许多后面跟有混合变音标记的 基本字符与预先构成的字符等同，虽然它们的位模式并不相同。例如， 以下两个序列等同：

0x00E9 -- é (LATIN SMALL LETTER E WITH ACUTE)

0x00650301 -- e (LATIN SMALL LETTER E), ´ (COMBINING ACUTE ACCENT)

enable unicode normalization 配置参数控制 Adaptive Server 是否对传入的

Unicode 数据进行规范化。

如果将 default Unicode sortorder 设置为“binary”，并且 enable Unicode normalization 配置参数设置为 1，则可以大大提高性能。这个组合允许 Adaptive Server 对 Unicode 数据的性质进行几种假设，而且已实现了代 码来利用这些假设。

函数

所有接受 char 参数的函数均经过了过载设计，也可接受 unichar。对于具 有多个参数的函数，在使用至少一个 unichar 参数调用时，这些函数会 隐式地将所有非 unichar 参数转换为 unichar。

在 enable surrogate processing 设置为 1（缺省值）时，为确保代理对的完整 性，字符串函数不允许拆分代理对。位置会被调整到代理对的开头处。

添加了几个函数以完善对 unichar 的支持。其中包括 to_unichar() 和 uscalar()，这两个函数类似于 char() 和 ascii()。函数 uhighsurr() 和 ulowsurr() 可用于对用户代码中的代理对进行显式处理。

使用包含函数的 unitext 时，会有一些限制。有关信息，请参见每个函数 “用法”部分下的限制说明。

使用 unichar 列

使用 isql 或 bcp 实用程序时，Unicode 值将显示为十六进制形式，除非使 用 -Jutf8 标志，表明客户端的字符集为 UTF-8。在这种情况下，实用程 序会将它从服务器接收到的任何 Unicode 数据都转换为 UTF-8。例如：

% isql -Usa -P -Jiso_1

1> select unicode_name from people where unicode_name = 'Jones' 2> go

unicode_name

------------------------------------------------------------------| 0x004a006f006e00650073

(1 row affected)

但是：

% isql -Usa -P -Jutf8

1> select unicode_name from people where unicode_name = 'Jones' 2> go

unicode_name

-- ---------- ---------- ---------- --------- ---------- ---------- -----

Jones

(1 row affected)

这简化了即席查询。并非所有终端窗口都能显示全部的 Unicode 字符， 但涉及 ASCII 字符的简单测试得到了大大地简化。

使用 unitext

可变长度的 unitext 数据类型最多可容纳 1,073,741,823 个 Unicode 字符

（2,147,483,646 字节）。可以在使用 text 数据类型的任何位置，使用具 有相同语义的 unitext。无论 Adaptive Server 的缺省字符集是什么，unitext 列都采用 UTF-16 编码存储。

Open Client 互用性

Open Client 库支持数据类型 cs_unichar，该数据类型可以绑定到声明为 短整型数组的用户变量。此 Open Client 数据类型直接与服务器的 unichar、 unitext 和 univarchar 交互。

Java 互用性

内部 JDBC 驱动程序可高效地在 SQL 和 Java 环境之间传送 unichar 数据。

从 SQL 向 Java 传送数据时，java.sql.ResultSet 类提供了大量“获取”方 法用于从结果集的列中检索数据。其中的任何一种获取方法都可使用定 义为 unichar、unitext 或 univarchar 的列。getString() 方法尤其高效，因为 无需执行任何转换。

使用 java.sql.PreparedStatement 类的 setString() 方法从 Java 向 SQL 传送数 据。内部 JDBC 驱动程序会将 Java 字符串数据直接复制到定义为 unichar、 unitext 或 univarchar 的 SQL 参数中。

外部 JDBC 驱动程序 (jConnect) 已进行了修改，可支持与内部驱动程序 相同的无缝接口。

限制

由于 Adaptive Server 的早期版本未包括基于 Unicode 的语言分析程序， 因此使用新的 Unicode 数据类型会受到限制。若要使用新的数据类型， 需要将服务器的缺省字符集配置为 UTF-8。Adaptive Server 12.5.1 版及 更高版本中已经没有这个限制。无论服务器的缺省字符集是什么，都可 以使用 Unicode 数据类型。

选择服务器缺省字符集

配置服务器时，必须为服务器指定缺省字符集。缺省字符集是服务器用 来存储和处理数据的字符集。每个服务器只能有一个缺省字符集。

缺省情况下，安装工具假定平台操作系统的本地字符集是服务器的缺省 字符集。但是，也可选择任何 Adaptive Server 支持的字符集作为服务器 的缺省字符集（请参见 第 300 页的表 10-1）。

例如，如果在运行 AIX 的 IBM RS/6000 上安装服务器，并选择安装一种 西欧语言，则安装工具假定缺省字符集为 ISO 8859-1。

如果要安装 Unicode 服务器，请选择 UTF-8 作为缺省字符集。

对于非 Unicode 服务器，请确定大多数客户端系统使用的平台，并使用 此平台的字符集作为服务器的缺省字符集。

这有两个优点：

• 字符集间不可映射字符数量得到减少。

由于通常在两个字符集的字符间没有完全一对一的映射，因此有可 能造成部分数据丢失。这通常很少发生，因为大多数的未转换字符 是不常用的特殊符号，或是某一平台专有的。

• 这将所需的字符集转换减至最少。

当客户端系统的字符集与服务器缺省字符集不同时，必须转换数据 以确保数据完整性。虽然字符集转换所导致的性能降低是微不足道 的，但最好选择引起转换最少的字符集。

例如，如果大多数客户端使用 CP 850，就应在服务器上指定 CP 850 为 缺省字符集。即使服务器是在 HP-UX 系统（其组 1 的语言的本地字符 集是 ROMAN8）上也可这样做。

注释 Sybase 强烈建议在创建任何数据库或对 Sybase 所提供的数据库 进行任何更改之前决定要使用何种字符集作为缺省字符集。

在下面的示例（ 图 10-2 ）中，175 个客户端都访问同一个 Adaptive Server。客户端在不同的平台上，并使用不同的字符集。允许这些客户 端一起运行的关键因素是，客户端/服务器系统中的所有 字符集都属于 同一语言组（请参见 第 300 页的表 10-1）。Adaptive Server 的缺省语言 是 CP 850，它是大多数客户端使用的字符集。这使得服务器最有效地工 作，所需字符集转换也最少。

图 10-2：使用同一语言组中不同字符集的客户端

CP 850

100 个客户端

ASE CP 850

ISO 8859-1

50 个客户端

Macintosh 罗马语

25 个客户端

为帮助选择服务器缺省字符集，下表按平台和语言列出了最常用的字 符集。

表 10-2：流行的西欧语言客户端平台

表 10-3：流行的日语客户端平台

表 10-4：流行的中文客户端平台

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