硬件成本低。单节点，硬件投入较低，满足非重要系统的需求。
安装配置简单。由于是单节点、单实例，所以安装配置比较简单。
管理维护成本低。单实例，维护成本低。
对应用设计的要求较低。由于是单实例，不存在集群应用设计时需要注意的事项，所以应用设计的要求较低。
可用性不高。由于是单服务器、单实例，所以服务器和实例的故障都会导致数据库不可用。
扩展性差。无法进行横向扩展，只能进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。
根据该模式的特点有如下要求：
1. 硬件配置方面预留扩展量。由于该模式无法进行横向扩展，所以在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。
2. 充分考虑该模式是否满足应用未来一段时间的需求。需要考虑应用在未来一段时间是否会发生变化，该模式是否满足应用变化的需求。

2.1.1.2. 双机热备模式 ¶

数据库服务器采用双机热备模式，可以满足对可用性有一定要求的应用，

具备以下特点：

需要冗余的服务器设备。该模式需要有冗余的服务器硬件，以满足一备一或者一备多的需求。硬件成本较高。
需要HA软件的支持。该模式需要配合HA软件才可以实现。
安装配置相对简单。该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤。
管理维护成本低。单实例，对维护人员的要求较低，维护成本低。
对应用设计的要求较低。由于是单实例，不存在RAC系统应用设计时需要注意的事项，所以应用设计的要求较低。
具备一定的高可用性。由于是多服务器、单实例，所以服务器和实例有故障时会发生实例在不同服务器上的切换，导致数据库的暂时不可用。无法满足对可用性有严格要求的应用类型。
扩展性差。无法进行横向扩展，只能进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。

根据该模式的特点有如下要求：

硬件配置方面预留扩展量。由于该模式无法进行横向扩展，所以在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。

充分考虑该模式是否满足应用未来一段时间的需求。需要考虑应用在未来一段时间是否会发生变化，该模式是否满足应用变化的需求。

2.1.1.3. 读写分离集群模式 ¶

数据库服务器采用读写分离集群模式，可以满足对可用性有特殊需求的应用，具备以下特点：

需要冗余的服务器设备。该模式需要有冗余的服务器硬件。硬件成本较高。
需要冗余的存储设备。主机和备机都需要同样的存储空间，成本较高。
安装配置比较简单。KingbaseES V8.6 提供了一键部署的工具。
具备容灾特性。当主机整个数据库系统不可用并短期内无法恢复时，可以把数据库系统切换到备机上，具备容灾的功能。主机和备机的切换支持实时同步和异步同步，其中实时同步，可以支持金融级的数据保护。
备机可以用作只读查询。备机可以切换到只读状态供报表之类的查询操作，减轻主机的压力。

根据该模式的特点，要求主机与备机在物理上要分开。为了实现容灾的特性，需要在物理上分割主机和备机。

2.1.1.4. 数据库运行模式选择 ¶

在设计数据库时必须考虑系统的可用性、业务连续性，针对系统所能容忍的最大业务中断时间（RTO）和最大数据丢失数量（RPO）需求，采用不同的数据库部署模式：

系统不能中断且不允许数据丢失的业务，建议数据库采用实时同步的集群模式，数据库单台设备故障时对业务没有影响，并考虑灾备系统的设计。

对于允许以分钟级别中断，数据不能丢失的系统，建议数据库采用双机热备的集群模式，设备故障时通过HA技术切换到备用设备，保证系统的可用性，对重要的系统要考虑灾备的设计。

对于允许以天为级别中断的业务系统，建议可采用双机热备模式，或单机。

对非关键系统、开发环境、测试环境，建议采用PC服务器、冷备或单机的模式。

2.1.2. 数据库环境规划 ¶

2.1.2.1. 运行环境规划 ¶

根据用户需求在业务系统前期的实施规划上，需要做好详细的规划设计，包括主机、网络和存储环境规划等，要将整个软硬件融为一体，充分考虑系统的安全性，可靠性，高可用性等因素，只有一个规划好的系统才能充分发挥其优于单节点的优势，同时也为后期的运维管理提供方便。

在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。理想情况下，应考虑下列要素：交易的复杂性、交易率、数据读/写比例、并发连接数、并发交易数、数据库最大表的大小、性能度量的目标。

本章节介绍了数据库运行的物理环境的配置规划。本章节包含以下内容：

2.1.2.1.1. 主机规划 ¶

主机规划主要需考虑服务器在不同的用户数量下，系统的响应时间和吞吐量，并得出当前服务器的各种资源的利用情况。在规划系统配置时要预留做系统管理时所消耗的资源，如在做备份、恢复、问题诊断、性能分析、系统维护时都会对系统资源带来额外的消耗，对重要资源要考虑为将来留下升级和可扩展的余地。

在进行服务器配置规划时，要注意以下几点：

1）CPU：要考虑业务高峰时处理器的能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。

2）内存：要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。

3）磁盘：评估业务的实际用户的数据量，以此推算出磁盘的最小个数，不要忘记选择备份设备（如磁带机）。

4）IO槽：尽量保留更多的IO槽，防止将来插更多的PCI卡。

5）网络：选择合适的网卡，保证网络不是系统的瓶颈。

数据库服务器优先考虑使用小型机和UNIX操作系统，但是当前用户大都选择PC服务器和Linux操作系统，推荐的数据库服务器配置如下：

处理器：各类CPU的主流PC服务器，核数尽量多一些。

内存：容量不低于128G。

存储：双盘，单盘容量不低于500GB，支持RAID。

网卡和HBA卡：2个千兆网口，2个万兆网口。网卡进行绑定。

操作系统：Linux。

2.1.2.1.2. 网络规划 ¶

网络规划的基本原则就是将业务生产网络、存储网络和管理网络分开，推荐在生产网络使用万兆网，存储使用SAN存储网络，管理网可使用千兆网。

对于数据库单机模式、以及集群模式的生产环境，符合网络规划的基本原则即可。

对集群而言，分为数据网络和业务网络，内部数据传输一般和业务接入的网络分开。符合业务数据分离原则（但不强制）。

公有IP和虚拟IP

KingbaseES V8.6 集群模式下主节点有一个虚拟IP，简称VIP，与公网PUBLIC IP在同一个网段。VIP附属在public网口接口。

VIP和PUBLIC IP最主要的不同之处在于：VIP是浮动的，而PUBLIC IP是固定的。在所有节点都正常运行时， VIP会被分配到主节点的public NIC上；在linux下ifconfig查看，public网卡上是2个IP地址；如果一个主节点宕机，这个节点的VIP会被转移到成功提升为主的的节点上。

PUBLIC IP地址是一个双网卡绑定的公有地址，用户通过交换机来进行访问。

业务IP和数据IP

KingbaseES V8.6 集群模式在有业务网络和数据网络分开的环境下，数据IP指数据库内部数据传输，通信所在的IP网络；业务IP主要是用来应用访问，VIP和与业务IP的PUBLIC IP在一起。VIP随着数据库的高可用而做转移。

2.1.2.1.3. 存储规划 ¶

数据库一般使用磁盘阵列（RAID）保存数据，使用磁盘阵列有两个优点：首先，盘阵可以提供一个具有容错能力的I/O系统，当系统中某个磁盘驱动器出现故障时，可避免丢失数据，因此具有容错能力；其次，允许多个但磁盘驱动器配置成为一个大的虚拟磁盘驱动器，从而方便管理，提高性能。

盘阵RAID方式分为RAID0，RAID1，RAID10，RAID2，RAID3，RAID4，RAID5等，其逻辑和物理组合方式各有差异。

基于KingbaseES V8.6 数据库配置RAID系统，有以下几种解决方案：

最佳解决方案

对容错能力最好的解决方案就是最大限度地使用RAID1和RAID10，规划部署时遵循以下原则：

1）对操作系统和KingbaseES V8.6 程序使用RAID1；

2）对数据库重做日志文件使用RAID10，可以优化性能；

3）对归档日志文件使用RAID10，既能保护数据，又不会影响性能；

4）对数据文件使用RAID10，并使用多个磁盘驱动器以保证不超过单块盘的负载。
较好的解决方案

对于容错能力，较好的解决方案是混合使用RAID10和RAID5，遵循以下原则：

1）对操作系统和KingbaseES V8.6 程序使用RAID1；

2）对数据库WAL日志文件共享一个RAID1或RAID10；

3）对归档日志文件可使用RAID10或RAID5，这两种方式均可保护数据且不影响性能；

4）对数据文件使用RAID10，并使用过个磁盘驱动器以保证不超过单个磁盘负载。混合使用RAID10和RAID5可实现很好的性能，容错能力也很高。
经济型解决方案

对容错能力，此方案使用RAID1和RAID5，遵循以下原则：

1）对操作系统和KingbaseES V8.6 程序使用RAID1;

2）对重做日志文件使用RAID1;

3）对归档日志文件使用RAID10或RAID5;

4）对数据文件使用RAID5。

此方案提供的系统性能比前两个方案要低，其价格是优势。

在进行存储规划时，需要特别注意：

1）若系统没有使用容错功能，那么只要有一块磁盘驱动器发生故障，就必须恢复整个数据库；

2）容错磁盘不能替代数据库备份策略；

3）系统可能会发生变化，要紧跟用户的需求；

4）以上的解决方案都要考虑磁盘驱动器的数量，应具备足够数量的磁盘驱动器以防系统瓶颈的产生；

5）对于硬件的保护不仅仅是磁盘驱动器，还包括冗余电源，磁盘控制卡和风扇等等，如果存储系统没有冗余机制，则这其中任何一项故障都会导致业务系统停机和丢失数据等损失。

2.1.2.2. 数据库安装部署规划 ¶

2.1.2.2.1. 软件安装路径 ¶

KingbaseES软件的安装目录要和系统盘分开，建立单独的文件系统来安装数据库软件，且文件系统的mount点不要直接建立在根目录下。例如，规划安装路径为： /opt/Kingbase/ES/V8/

在Unix下，KingbaseES数据库系统的帐号和组的权限也要作相应设置。创建数据库管理员组(DBA)并分配root和KingbaseES软件拥有者的用户ID 给这个组。DBA 能执行的程序只有“710” 权限。在安装过程中SQL*DBA 系统权限命令被自动分配给DBA 组。

2.1.2.2.2. 数据库实例配置 ¶

对于KingbaseES各个版本的参数优化，随版本的区别而有所不同。但万变不离其宗，大部分的参数设置原理是相同的，其优化原则也一致。

数据库字符集的确定非常重要，如果选择不当，会给业务数据的保存带来麻烦。如在现实中，有的汉字保存到数据库时发生乱码，从而使客户的信息不能正常保存和显示。

数据库字符集在系统设计开发阶段就应当确定。在数据库系统上线后，再更改数据库字符集，代价会非常大。因为不同的字符集设置之间，存在转换操作，如果不兼容，只能逐条转换。一般选择原则是要适中，满足当前和未来业务数据的保存。既不要选择太大，也不要过小。现有支持汉字的字符集包括：

GBK：此字符包含了大部需要的汉字字符，由于目前已经有了新的国标GB18030-2005，而GB18030不是GBK的严格超集，部分字符编码有改动，如果要升级到GB18030只能是将库导出导入重建，因此不建议使用该字符集。

GB18030：此字符集是最新国家标准字符集，包含字符较全，如果系统将来不会有其他国家字符被使用，可以使用此字符集。

UTF8：此字符集是KingbaseES V8.6 推荐使用的字符集，对汉字支持也较好。如果系统可能会有其他国家字符录入，建议选用此字符集。

对于其他字符集的选择，请查询应用安装手册。

另外，是否需要大小写敏感 enable-ci，页面大小block-size，以及是否需要指定加密引擎，都是实例级的配置，需要事前确定。

大小写是否敏感，影响表的查找，以及text之类值的比较。

页面大小，默认是8k，大页（例如32k），适合每个原则的大小超过8k，可以更合理的使用每个页的空间，减少toast数据，从而提高性能。

2.1.2.2.3. 数据库参数设置 ¶

数据库参数的设置与业务应用密不可分。不同的业务类型，决定着关键参数的值，同时合理参数值也就决定着数据库系统的性能优劣。不仅如此，业务数据的需求也决定着数据库系统的设置。对于实例创建成功而不可更改的或者修改代价比较大的参数，必须慎重考虑，在充分调研各个方面的需求后，方可确定参数值，以满足业务的正常健康的运行。具体参见《服务器配置参数参考手册》。

2.1.2.2.4. 表空间设计 ¶

2.1.2.2.4.1. 业务数据量估算 ¶

估算所有业务对象下的所有表的尺寸。

数据量估算的前提：

1）数据库的物理表结构已经确定，并且设计已冻结。

2）用户方提供较为准确的估算依据，例如业务变动的频率、数据需要保存的周期等。

该表是一个示例，可根据业务的不同有所变化。

序号	表名	增长量（/小时/天/周）	增长量（/月/半年）	年数据量	数据库生命周期内的总计
1
2
3
4
5
合计

新上线或扩容时，对所申请的存储不得全部一次性挂上，应该预留出30％左右的空间用于追加，以防止出现业务发展和预期不一致时剩余空间多寡不均，调整困难。

操作系统上应该预先做好几个合适大小的逻辑卷备用，包括用于sys_global、sys_default等表空间的小尺寸的逻辑卷和用于数据表空间、索引表空间的大尺寸逻辑卷，这些逻辑卷要求在所有节点上都可见，避免单纯因为数据库增加数据文件而需要重新同步。

2.1.2.2.4.2. 表空间使用规则 ¶

目前多数数据库系统采用数据“大集中”原则，对数据库的性能要求较高。这就要求对数据库进行必要的优化配置。在表空间的配置上，应遵循以下原则：

最小化磁盘I/O。

在不同的物理磁盘设备上，分配数据。

尽可能使用本地管理表空间。

多数系统采用RAID1+0 或 RAID0+1，该技术很好的解决了最小化磁盘I/O。基本不必考虑在不同的物理磁盘设备上，分配数据的原则。

2.1.2.2.4.3. 表空间的类型 ¶

为了更好的管理表空间，同时提高KingbaseES V8.6 数据库系统性能，针对数据的业务功能，进一步对其加以分类。因此KingbaseES V8.6 数据库的表空间划分为基本表空间和应用表空间。如下表：

基本表空间：是指KingbaseES V8.6 数据库系统为其自身运行而使用的表空间。

应用表空间：是指业务应用数据保存在此类表空间中。它由DBA或相关的数据库规划设计人员创建和规划。

表空间类别	表空间名称	存储内容	说明
数据表空间	TABLES表空间	存储小数据表公用业务数据	由DBA设定—应用表空间
数据表空间	TABLES PARTITION表空间	存储巨型表数据	由DBA设定—应用表空间
数据表空间	INDEXS表空间	存储小数据表的索引	由DBA设定—应用表空间

2.1.2.2.4.4. 表空间相关概念 ¶

在规范表空间存储参数之前有必要澄清关于数据块（data block）、文件之间的概念及其之间的关系。

数据块（data block）：KingbaseES V8.6 存储数据最细粒度是数据块，它是操作系统文件块的整数倍（有时也称逻辑块，KingbaseES V8.6 块，或页）。一个数据块大小有4k、8k、32k等，并以此单位大小保存在物理磁盘中。

文件（file）：一个表/索引，对应着一个或者多个文件。每个文件由多个数据块组成。

表空间（tablespace）：每个表空间对应着一个目录。可以通过软连接的方式，扩展表空间在其他逻辑卷的大小。

2.1.2.2.4.5. 表空间的分配原则 ¶

对于小规模数据库，I/O不是主要的性能瓶颈，可以不考虑物理分布的问题。

对于中规模数据库及大规模数据库，应当考虑：

尽可能把应用数据表空间、应用的索引表空间以及相应得分区表空间分布在独立的物理卷上。

2.1.2.2.5. 表和索引设计 ¶

2.1.2.2.5.1. 表的参数设置 ¶

fillfactor

存储参数fillfactor ，在10和100之间。

对于主要操作为insert的数据对象，可以考虑设定较大的fillfactor 。

若对于有大量update操作的数据表，fillfactor 可以设置的更小些。
max_parallel_workers

表扫描中可以使用的并行进程个数。

2.1.2.2.5.2. 索引的使用原则 ¶

1.基本使用原则

1)当查询的行数占整个表总行数的比例<=5%时，建立b树索引效果比较明显。（普通索引就是b树索引）

2)在频繁进行排序或分组（即进行group By或order By操作）的列上建立索引。

3)在频繁使用distinct关键字进行查询的列上面建立索引。

4)进行表连接时，在连接字段上面建立索引。

5)对于键值频繁更新的索引，需要定期的进行重建。

2.复合索引的使用原则

一般情况下，对于经常同时使用多个数据项进行查询的对象可以创建复合索引，使用复合索引时特别要考虑的各个数据项在索引中的相对位置。

一般情况下，把最常用的列放在第一位而不太常用的列放在稍后面的位置。

在复合索引创建后，要求用户在查询数据的时候也遵循同样的方式来使用索引。

虽然目前的KingbaseES V8.6 数据库版本能够使用复合索引中的后面的数据项，但是按序使用复合索引可以带来较高的效率。

3.函数索引的使用原则

1)对于经常进行运算比较的一些列，可以考虑建立函数索引，但是也可以通过在表中使用原来的列的函数形式来实现

2)在OLTP系统中，一般情况下不建议使用函数索引。

2.1.3. 可扩展性设计 ¶

可扩展性是数据库应用程序对负载变化的适应。数据库应用程序的可扩展性越高，添加或更改功能就越容易，而对现有功能的影响最小。为了最大限度地提高可扩展性，您必须提前设计应用架构，设计原则是允许在不对基础架构进行重大更改的情况下进行功能增加。

负载是数据量、用户数量和其他相关因素的组合。应用要适应负载的增加，必须使用有效的基准测试策略、适当的应用程序开发技术（如绑定变量）和合适的数据库架构特性。

2.1.4. 安全设计 ¶

数据库安全设计涉及以下方面：

用户管理

包括口令管理、角色和权限分配等。KingbaseES 的默认安装会建立很多缺省的用户名和密码，以及对应的默认权限。所以设计应用架构，需要提前规划好应用的用户分配。
提前考虑项目是否需要通过等保分保测试

包括密码复杂度，审计，敏感数据保护等策略的明确方案，从而在系统进行性能和稳定性测试时，同时考虑安全属性。特别是敏感数据保护，是采用函数加密，表空间透明加密，还是表加密。函数加密，需要应用程序负责数据的加密和解密。表空间的透明加密，若数据库的内存较大，基本等于数据量，那么采用透明加密是对性能影响最小的方案。

2.1.5. 可移植性设计 ¶

PL/SQL 在操作系统和语言之间具有高度可移植性。大多数编程语言都可以调用 PL/SQL，并且 PL/SQL 可以在支持 KingbaseES 数据库的不同平台上运行。如果您在一个平台上开发 PL/SQL 应用程序，可以直接移植到其他平台上运行。

PL/SQL 存储过程提供了跨多个数据库的一些应用程序可移植性。尽管使用以给定供应商的语言编写的存储过程在某种程度上似乎将您与该供应商联系在一起，但存储过程使应用程序逻辑具有可移植性。数据逻辑针对运行应用程序的数据库进行了最佳编码。由于数据逻辑隐藏在存储过程中，您可以使用扩展功能来优化数据层。

当在数据库上开发和部署时，应用程序逻辑保存在该数据库上。如果将应用程序移动到另一个数据库，应用程序逻辑可以独立于存储过程中的数据逻辑移动，从而简化了移植步骤。

2.1.6. 可诊断性设计 ¶

KingbaseES数据库包括一个故障诊断基础架构，用于预防、检测、诊断和解决数据库问题。问题包括代码错误、元数据损坏和客户数据损坏等。可诊断性基础架构的目标是主动检测问题，在检测到问题后限制损坏和中断，减少诊断和解决问题所需的时间。

2.1.7. 业务系统设计 ¶

业务系统处理数据的特点决定了设计人员规划和创建什么样的数据库，通常来说，业务分为两类：在线事务处理系统（OLTP）和在线分析系统（OLAP）或者DSS（决策支持系统）。这两类系统在数据库的设计上是不同的，比如OLTP系统强调数据库的内存效率，强调各种内存指标的命中率，强调绑定变量，强调并发操作：而OLAP系统则强调数据分析，强调SQL 执行时长，强调磁盘I/O，强调分区等。

2.1.7.1. 在线事务处理系统 ¶

通常OLTP（在线事务处理系统）的用户并发数很多，但只对数据库做很小的操作，数据库侧重于对用户操作的快速响应，这是对数据库最重要的性能要求。

对于一个OLTP系统来说，数据库内存设计非常重要，如果数据都可以在内存中处理，那么数据库的性能会提高很多。

内存的设计通常是通过调整KingbaseES V8.6 和内存相关的初始化参数来实现的，比较重要的几个是内存相关的参数，包括共享内存的大小（shared_buffers），session级内存大小（work_mem， maintenance_work_mem等）等，这些参数对一个OLTP系统是非常重要的。OLTP 系统是一个数据块更新非常频繁，SQL语句提交非常频繁的一个系统。对于数据块来说，应尽可能让数据块保存在内存当中，对于SQL来说，尽可能使用变量绑定技术来达到SQL的重用，减少物理I/O和重复的SQL解析，能极大的改善系统的性能。

2.1.7.2. 在线分析系统 ¶

OLAP（在线分析系统）数据库在内存上可优化的余地很小，但提升CPU 处理速度和磁盘I/O速度是最直接的提高数据库性能的方式。实际上，用户对OLAP系统性能的期望远远没有对OLTP 性能的期望那么高。

对于OLAP 系统，SQL的优化显得非常重要，如果一张表中只有几千行数据，无论执行全表扫描或是使用索引，对用户来说差异都很小，几乎感觉不出来，但是当数据量提升到几亿或者几十亿或者更多的时候，全表扫描，索引可能导致极大的性能差异，因此SQL语句的优化显得重要起来。

分区技术在OLAP数据库中很重要，这种重要主要是体现在数据管理上，比如数据加载，可以通过分区交换的方式实现，备份可以通过备份分区表空间，删除数据可以通过分区进行删除。

2.1.7.3. 数据库的规模 ¶

对于数据库的规模，仅从数据量来衡量其规模的大小。因为数据量的规模是反映数据库规模的主要指标。具体如下：

数据库业务数据量小于100GB 属小规模数据库
数据库业务数据量大于100GB小于1TB以内属中大规模数据库
数据库业务数据量大于1TB 属大规模数据库

2.1.8. 特殊场景特性 ¶

2.1.8.1. SQL 分析函数 ¶

SQL 分析函数基于一组行计算聚合值。 SQL 分析函数与聚合函数的不同之处在于它为每个组返回多行。对于每一行，定义了一个行窗口，确定用于对当前行执行计算的行范围。SQL 分析函数为面向集合的 SQL提供了在结果集上使用数组语义的功能。它们可以对原本繁琐复杂的逻辑进行简化、或者直接编码,提高了处理效率，并且可以在数据库层进行SQL调优。

KingbaseES可用的分析函数如下所示，函数详细信息和用法请参考 KingbaseES SQL语言参考手册。

AVG
CORR
COUNT
COVAR_POP
COVAR_SAMP
CUME_DIST
DENSE_RANK
FIRST
FIRST_VALUE
LAG
LAST
LAST_VALUE
LEAD
LISTAGG
MAX
MIN
NTH_VALUE
NTILE
PERCENT_RANK
PERCENTILE_CONT
PERCENTILE_DISC
RANK
RATIO_TO_REPORT
ROW_NUMBER
STDDEV
STDDEV_POP
STDDEV_SAMP
SUM
VAR_POP
VAR_SAMP
VARIANCE

2.1.8.2. 物化视图 ¶

物化视图是已存为架构对象的查询结果，用于汇总、计算、复制和分发数据。用户可以查询物化视图，而不是单独聚合详细信息记录。物化视图使用于复制数据和移动计算等场景。

虽然物化视图需要时间来创建和更新，并占用一定的磁盘空间，但可以高效的提升查询速度。在这些方面，物化视图类似于索引，它们被称为“数据仓库的索引”。与索引不同，物化视图可以直接查询，有时可以使用 DML 语句进行更新。

2.1.8.3. 分区 ¶

分区技术是为解决数据库中巨大的表或索引读写速度过慢而提出的解决方案。分区技术是利用物理上和逻辑上对数据进行分割来提高处理速度的。

同时，合理的分区也提高了数据库数据的可管理性。

Partition表和索引考虑使用分区的条件：

数据损坏的故障隔离；
支持在线增加、删除；
特定分区上的批处理；
按分区备份；
维护时可访问正常分区；
恢复最关键的数据分区。

2.1.8.3.1. 逻辑分割 ¶

根据分区策略，一张表的数据可以逻辑上分布于多个分区、子分区中，对数据的查询如果利用分区策略就可以缩小访问的范围，在一定量级上提高查询速度。

同样，对于索引分区也是一样的，从逻辑上分割表，缩小处理中的范围，能够极大地提高KingbaseES V8.6 本身的处理速度。

2.1.8.3.2. 物理分割 ¶

对于逻辑分割后的分区，可以通过策略分布到不同的表空间中，从而分布到不同的数据文件中，而数据文件又可以分配到不同的存储介质空间中，这样就可以充分利用操作系统的并行访问，同时也利用存储介质的并行访问，极大地同时提高写入和读取速度。

同样，对于索引分区也是一样的机制。

2.1.8.3.3. 数据分区的优缺点 ¶

数据库进行分区，一般有以下优点：

分区允许数据库管理员进行数据管理操作：数据装载，索引的创建和重建，在分区级别的备份与恢复。因此可节省数据库管理员大量的操作时间。
分区可大幅度减少因维护引起的业务停止时间。分区的独立性使数据库管理员对同一表或索引的各个分区进行并发的维护管理操作；也可对分区表并行的执行SELECT和DML操作。
分区可增加数据库的可用性。减少维护窗口，恢复次数以及系统失效的影响。
分区不要求修改任何应用程序。如，数据库管理员可把非分区表转换为分区表，而不必修改或重写SELECT语句或DML语句。同时也不必重写前端的应用程序代码。

但是数据分区带来了数据库创建方面的复杂度。即维护操作原来是面向一个表或索引对象，现在则要面向几十至上百个分区。所以需要提前计算成本，如果后台工作复杂度的加大换来了前台数据操作的效率提高，也是值得的。

2.1.8.3.4. KINGBASEES 分区技术 ¶

KingbaseES支持的分区类型如下所示：

范围分区

范围分区是对某个可度量的字段在可以预见的范围内进行划分的分区方式，例如：日期字段。
list分区

list分区是对某个可列举确定值的字段按照不同值进行划分的分区方式，例如：区县代码字段。
散列分区

散列分区是对某个离散性很大的字段按照根据散列算法计算出的散列值进行分区，例如：证件号码。
间隔分区

间隔分区是对分区键按照指定间隔，服务器自动创建新的分区。
组合范围-散列分区

组合范围-枚举值分区是按照范围做主分区，在主分区的基础上再次进行按照枚举值分区的组合分区。例如：日期-区县。
组合枚举-散列分区

组合范围-散列分区是按照范围做主分区，在主分区的基础上再次进行按照散列分区的组合分区。例如：日期-证件号码。

2.1.8.3.5. 分区索引 ¶

KingbaseES支持分区索引包括全局索引和本地索引，如下所示：

全局索引(GLOBAL index )
一个索引可以指向多个分区的数据，对单个或少量记录的访问比较有效，但管理维护上有额外成本。主要特点如下：
1. 指向任何一个分区中的记录
2. 表可以被分区或不分区
3. 分区键值可以是有前缀后没有前缀
本地索引(LOCAL index)
每个表分区都有一个索引分区，而且只索引该表分区的数据。一个给定索引分区中的所有条目都指向一个表分区，表分区中的所有行都表示在一个索引分区中。适合并行索引扫描，但对少量记录查询相对效率不高。
1. 每个本地索引分区只包含本分区的记录
2. 二种类型的本地索引
  
  前缀(prefixed)：唯一或非唯一列，可有效的使用分区消除，适于索引并行查询，适用于OLTP
  
  非前缀(non-prefixed)：适合于索引并行查询，可有效的使用分区消除，唯一索引受限，适用于DSS
3. 分区键值可以与索引键值不同

2.1.8.3.6. 分区使用建议 ¶

如果数据按照某个（某些）值分区，那么range分区就最合适，比如按照“销售定额”、“财务年度”、“月份”等等，在这种情况下，range分区可以利用分区消除，这包括应用中使用“＝”、“>”、“<”等作为条件。

如果不能找到其他合适的自然条件进行分区，那么HASH分区就比较合适，这里建议选择唯一列或者几乎唯一的列作为分区键值。这种情况下，分区数据是均匀的，使用分区键值“＝”或者in(value1,value2…)时，hash分区可以利用分区消除，但是使用其他条件时，hash无法利用分区消除。

如果分区后，每个分区的数据量还是很大，建议使用组合分区，例如，首先按照自然条件做range分区，之后，对分区再进行分区。

2.2. 数据库应用程序的连接策略 ¶

数据库连接是客户端进程和数据库实例之间的物理通信路径。数据库会话是数据库后台的一个服务进程，它表示当前登录到数据库的用户的状态。从用户通过数据库进行身份验证开始，会话一直持续到用户断开连接或退出数据库应用程序为止。一个连接对应一个会话。

2.2.1. 连接池设计准则 ¶

连接池是应用程序可以使用的 KingbaseES 数据库连接的缓存。

在运行时，应用程序从池中请求连接。如果池中包含一个可以满足请求的连接，那么它将返回给应用程序。应用程序使用该连接在数据库上执行工作，工作完成后，释放连接，将该连接返回给池，释放的连接随后可用于下一个连接请求。

在静态连接池中，连接池的连接数是固定的，无法创建更多的连接来满足需求。因此，如果连接池池找不到空闲连接来满足新的应用程序请求，则请求将排队或返回错误。但是，在动态连接池中，该池创建一个新的连接，然后将其返回给应用程序。从理论上讲，动态连接池能够增加或减少连接池中连接的数量，从而节省系统资源，以免在维再维护不必要的连接时丢失资源。然而，在实践中，动态连接池策略允许潜在的连接风暴和过度的订阅问题。

连接风暴

连接风暴是一种竞争状态，在这种情况下，应用服务器发起的连接请求数量不断增加，但数据库服务器CPU无法立即调度它们，这将导致应用服务器创建更多的连接。

在一次连接风暴中，数据库连接的数量可以在不到一分钟的时间内从百个猛增到数千个。

动态连接池特别容易发生连接风暴。随着连接请求数量的增加，相对于CPU核的数量，数据库服务器会超额订阅。在任何给定的时间，一个CPU核心上只能运行一个进程。因此，如果服务器上存在32个核，那么一次只能有32个进程在工作。如果应用服务器创建数百或数千个连接，那么CPU就会因为试图跟上系统上争夺时间的进程数量而变得繁忙。

在数据库内部，等待活动随着活动会话数量的增加而增加。您可以通过查看KSH或KWR报告中的等待事件来观察这个活动。典型的等待事件包括队列的锁、行缓存对象、锁空闲、enq：TX索引争用和缓冲区繁忙等待。随着等待事件的增加，事务吞吐量降低，因为会话无法执行工作。由于服务器计算机超额使用，监控工具进程必须在CPU上争取时间。在最极端的情况下，使用键盘就变成了不可能，使调试变得困难。
防止连接风暴的准则：使用静态池

我们建议您使用静态连接池而不是动态连接池。在对连接风暴多年诊断的过程中，我们发现，动态连接池经常使用太多的进程来完成必要的工作负载。一个普遍的误区是，动态连接池根据需要创建连接，并在不需要时减少它们。实际上，当连接池耗尽时，应用服务器会允许数据库连接池的大小迅速增加。当所有会话都处于活动状态时，会导致性能问题。

由于动态连接池会迅速破坏系统的稳定，我们建议您使用静态连接池而不是动态连接池。

减少连接的数量可以减少了CPU的压力，从而获得更快的响应时间和更高的吞吐量，这一结果似乎是自相矛盾的，性能提高的原因如下：

较少的连接意味着数据库中与争用相关的等待事件更少。在减少连接之后，以前在缓存区锁定和缓存区分配上消耗的CPU时间周期可以更多的花费在处理数据库事务上。

随着连接数量的减少，连接在CPU上的调度时间可能会延长。因此，所有与这些进程相关的内存页都驻留在CPU缓存中。它们在调度上变得越来越高效，在内存中的停留的次数也越来越少。

根据性能调优经验，我们建议用户对系统CPU的利用率为10%-90%，并且在数据库服务器上平均每个CPU核心不超过10个进程，连接的数量应根据CPU的内核数而不是CPU内核线程的数量。例如，假设一台服务器有2个CPU，每个CPU有18个核心，每个CPU核心有2个线程，根据性能调优指南，应用程序可以有36到360个到数据库实例的连接。

2.2.2. 登录策略 ¶

所有数据库开发人员面临的一个问题是应用程序如何以及何时登录到数据库来启动事务。

在此次优设计中，数据库应用程序对每个SQL请求执行以下步骤：

登录数据库.
发出SQL请求，例如插入或更新语句。
退出数据库。

使用登录/注销策略的应用程序可能满足功能需求。此外，当每秒事务数较低时，它们可能会执行的很好。但是，登录和退出数据库是一个非常占用数据库资源的操作。我们发现，使用此类算法的应用程序不能很好地扩展，并且可能导致严重的性能问题，特别是当与动态连接池一起使用时，登录/注销策略通常不使用连接池。

如果应用程序使用登录/注销设计，如果DBA和开发人员没有意识到问题的根源，那么第一个症状可能是数据库吞吐量低和不稳定、过高的响应时间。对数据库的诊断调查可能会显示，当资源争用较低时，活动的会话相对较少。

性能欠佳的迹象是，每秒的登录数接近每秒的事务数。当使用每个事务登录/退出策略时，数据库实例和操作系统在幕后执行大量工作，以创建新进程、数据库连接和相关内的存区域。这些步骤中的许多都是序列化的，导致低CPU利用率与低事务吞吐量。

出于上述原因，我们强烈建议，对于任何必须扩展到支持大量事务的应用程序，不要采用登录/注销设计。

2.2.3. 防止程序会话泄漏 ¶

当程序失去连接，但其会话在数据库实例中仍然处于活动状态时，就会发生会话泄漏。泄漏的会话以编程方式丢失到应用程序中。

优化设计的应用程序可以防止会话泄漏。通常，会话泄漏是由于应用程序捕获的异常而发生的。如果应用程序不能正确处理异常，则它可能在不执行提交或回滚的情况下终止连接，从而泄漏会话。

会话泄漏可能会导致严重的数据库性能和数据完整性问题。典型的问题有以下几种形式：

连接池排空
锁泄漏
逻辑混乱
连接池排空

设计缺陷会导致连接池排空。

例如，假设应用程序设计缺陷导致它一致地泄漏会话。即使泄漏率很低，动态连接池也会导致越来越多的会话在编程上变得无法使用。

其效果是减少可用的连接池，并导致剩余的连接无法跟上工作负载。不可用会话的数量不断的攀升，直到池中没有可用的连接。
锁泄漏

锁泄漏通常是会话泄漏的副作用。

例如，正在进行批处理更新的泄漏会话可能持有表中多行的锁。如果泄漏的会话持有锁，那么希望获取锁的会话将在泄漏的会话后面形成一个队列。

持有该锁的程序正在等待来自客户端的交互以释放该锁，但由于连接以编程方式丢失了，消息将不会被发送。因此，数据库无法提交或回滚会话中任何活动的事务。
逻辑混乱

泄漏的会话可能包含对数据库未提交的更改。例如，当数据库连接意外释放时，事务正在工作中。

这种情况可能导致以下问题：
- 应用程序向UI报告一个错误。在这种情况下，用户可能会抱怨他们失去了工作数据，例如商务订单或航班时间表。
- 即使没有发生提交或回滚，UI也会收到提交消息。这是最糟糕的情况，因为后续事务可能同时提交自己的工作和泄漏会话中一半的事务。在这种情况下，数据库在逻辑上已经损坏。
查看会话泄漏

会话泄漏是由于应用程序或应用服务中的问题而发生的，无法在数据库中解决。这个问题需要在应用程序或应用服务器中解决。检查会话泄漏的一种简单方法是修改连接池以使用一个数据库连接测试应用程序。只使用一个连接进行测试可以更容易地在应用程序中找到问题的根本原因。

2.3. 安全 ¶

2.3.1. 用户设计 ¶

2.3.1.1. 用户权限管理 ¶

业务功能的安全分配是指开发团队定义的用户、角色、特权，它是面向应用程序和开发的。数据库用户安全分配往往取自前台应用设计开发团队的交付生产时的定义。这种安全定义了用户、角色、系统特权、对象特权分配等等。它往往是面向开发的，没有细致考虑用户权限的控制。在数据库系统上线时，才发现有不妥之处。而这种用户安全分配多数情况下不能修改，否则对前台应用造成运行错误。

但在交付生产时，投产方和用户方必须对其安全性进行审计。因为这时提供的用户安全往往是面向开发的，而不是面向末端用户的。主要检查一下几个方面：

每个业务用户不得授予DBA角色。

取消一些系统特权。但取消之前必须征询开发者的意见，否则可能对前台应用运行带来不可预测的错误。

坚持最小化特权原则。

对象（如:表、索引、触发器、过程等）管理权限归数据中心，应用（创建临时表权限）权限归项目组。

对于一个软件项目，在应用系统开发过程中，就开始对数据库用户权限进行严格的控制。即按照该系统未来生产时的方式进行分配，尽管此时数据库还处在开发服务器之中，尽管给开发项目的控制带来更多的工作，但数据库的安全性大大提高了。

对数据库用户（user）的授权，应通过数据库角色（role）进行分配。而不要把对象特权和系统特权直接授权给数据库用户。

2.3.1.2. 用户安全实现 ¶

KingbaseES V8.6 数据库是通过权限（Privilege）这个概念来实现数据安全的。所谓权限指用一种指定的方式访问数据库数据对象的一个许可，如查询一个数据表的许可等。这个特权能够被授予某个实体，因此这个授予实体权限（privilege）的过程，称之为“授权”（Grant）。

涉及KingbaseES V8.6 数据库系统安全的实体有两个，分别是系统权限（System Privileges）和对象权限（Object Privileges）。

系统权限

系统权限是指登录到KingbaseES V8.6 数据库系统的用户，执行数据库系统级别的某种操作或者是某一数据库对象的创建、修改、删除。在KingbaseES V8.6 数据库系统中有一系列的系统内置预定义特权，系统用这些特权去控制数据的安全。

不得授予普通用户额外的全局权限，如select any/delete any/execute any等，应用有特殊需求的除外。
对象权限

对象权限是指登录到KingbaseES V8.6 数据库系统的用户，有权执行数据库对象级别的某种操作。例如表的INSERT，DELETE，UPDATE操作等。同样，在KingbaseES V8.6 数据库系统中有一系列的对象内置预定义权限，系统用这些特权去控制数据的安全。

由于KingbaseES V8.6 数据库系统业务处理的复杂性，对KingbaseES V8.6 数据库的系统权限和对象权限的分配也就变得十分复杂。因此，为了方便管理系统权限和对象权限，需要引入角色这个基本概念。

所谓角色是指系统权限和对象权限的集合。通过对角色的管理，使得KingbaseES V8.6 数据库的系统权限和对象权限管理变得更加方便和容易。

基于角色的安全管理主要有以下几点优势：

减少授权工作量：可以通过授权给与一组用户相关联的角色，再由该角色授权给该用户组的成员用户。

动态权限管理：如果授权给某个用户的权限需要改变，只须修改相关角色的授权，那么与这个角色相关的用户的权限会自动改变，不须修改授权给用户特权。

设置权限的可用性：当某个被授予用户的角色，需要取消，只须对相应的角色设置禁用（DISABLED）。因此，在任何特定的情况下，都可对用户的授权进行必要的控制。

应用程序级的设置可用性：前台应用程序在试图以某个数据库用户的身份与后台数据库相连接时，可以对角色设置可用性。这种做法可以把非应用程序例如ksql，屏蔽在数据库系统之外，以保证数据库的安全。

角色可以根据业务的需求自由定义，系统权限和对象权限可以授权给角色，角色也可授权给另外的角色，角色也可授权给用户。基于上面描述的角色安全管理的优点和特点，KingbaseES V8.6 数据库系统选择角色来实施数据库用户的授权管理，并根据KingbaseES V8.6 的业务需求从不同的角度实现业务的权限分配。

根据需求，设置不同级别的角色，某一级别体现对某一项业务的特权。各角色级别之间或是子集关系，或是交集关系；同一级别的角色之间，或是交集，或是互为独立集合的关系。随着对业务需求的增加或变化，不断增加、完善访问控制的粒度，并坚持最小化特权原则。如下图：

通过存储过程管理权限（stored procedures）

使用存储过程（stored procedures）来限制数据库的操作，客户端用户只需有权执行存储过程，并通过存储过程来实现对数据库表的访问。因而就屏蔽了用户直接对数据库表的操作。
通过视图（VIEWS）管理权限

通过视图（VIEWS）来控制KingbaseES V8.6 数据库系统的安全。即只分配给用户查询视图的权限，而对基表（定义视图的相关的数据表）则进行屏蔽，禁止对数据表的直接操作。

视图可以实现以下两种安全级别：
1. 使用视图可以限制对数据表中的特定的列的访问。
2. 使用视图可以限制对数据表中的特定的行的访问。
如：对于某一基表，要求只显示部分行，则可通过创建实体的WHERE子句来控制行的显示。

2.3.1.3. 用户类型及角色命名规范 ¶

可以用SQL语句GRANT来授予系统权限和角色给其它角色和用户。有GRANT ANY ROLE系统权限的任何用户可以授予数据库里的任何角色。

下面的语句授予了对应EMP表所有列的SELECT，INSERT和DELETE的对象权限给用户JFEE和TSMITH：

SQL>GRANT SELECT, INSERT, DELETE ON EMP TO JFEE, TSMITH;

要授予只对应EMP表的ENAME列和JOB列的INSERT的对象权限给用户JFEE和TSMITH，声明下面的句子：

GRANT INSERT (ENAME, JOB) ON EMP TO JFEE, TSMITH;

要把对应于SALARY视图的所有对象权限给用户JFEE，要使用ALL关键字，例子如下所示：

GRANT ALL ON SALARY TO JFEE;

把ACCOUNTS表的ACCT_NO列的INSERT权限授予给用户S：

GRANT INSERT (ACCT_NO) ON ACCOUNTS TO S;

除了system用户，其他KingbaseES V8.6 默认用户都应该置为expire或lock状态，除非有特殊需求;

数据库所有活动状态用户的密码不得设置为已知的默认密码；

数据库用户的密码应该定期修改。

2.3.2. 数据访问控制 ¶

可以通过数据脱敏、强访问控制和透明加密等功能控制用户对应用程序中的数据访问级别。

2.3.2.1. 数据脱敏 ¶

数据脱敏功能可以让用户访问数据时对数据进行一定规则的屏蔽。对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。KingbaseES的数据脱敏支持以下策略：

完整脱敏，对所有数据都进行脱敏处理
部分脱敏，对部分数据进行脱敏输出
随机脱敏，通过将整个值替换成随机值来实现数据脱敏
邮件数据脱敏，KingbaseES支持邮件格式字符串专用脱敏函数email_mask，将email字符数据最后一个符号.之前的所有字符都将用符号 * 进行脱敏。

2.3.2.2. 标记和强访问控制 ¶

KingbaseES支持标记和强制访问控制，保护用户数据，防止非法窃取。强制访问控制为所控制的主体和客体指派安全标记，然后依据这些标记进行访问仲裁。并且，只有主体标记能支配客体标记时才允许主体访问。设置标记可以在行级别保护数据库，并且对不同行设置不同的安全级别。

2.3.2.3. 透明加密 ¶

透明存储加密能够加密存储在表和表空间中的敏感数据。加密数据后，当授权用户或应用程序访问此数据时，将以透明方式解密此数据。KingbaseES 实现了数据在写到磁盘上时对其进行加密，当授权用户重新读取数据时再对其进行解密。无需对应用程序进行修改，授权用户甚至不会注意到数据已经在存储介质上加密，加密解密过程对用户和应用程序都是透明的。

2.3.3. 数据库审计 ¶

KingbaseES支持创建审计策略来审核数据库中的操作。并且将用户对数据库的所有操作自动记录下来放入审计日志中，审计员（sao）可以通过对审计日志的分析，对潜在的威胁提前采取有效地措施加以防范。KingbaseES数据库提供了一套完整的审计机制，用来保证对数据库中的各种行为进行监控，进而为数据库的安全、可靠和有效提供有力的保障。针对不同的应用系统，您可以创建不同的审计策略来满意业务的安全性需求。

2.4. PLSQL的高级特性 ¶

本章介绍了PL/SQL 高级特性，有关详细信息，请参阅其他章节或文档。

本章节包含以下内容：

也可以看看：

PL/SQL Language Reference 了解 PL/SQL 的完整描述

2.4.1. PLSQL数据类型 ¶

PL/SQL 数据类型包括 SQL 数据类型、附加标量数据类型和复合数据类型。您还可以定义复合数据类型以及标量数据类型的子类型。

也可以看看：

PL/SQL 数据类型

2.4.2. 动态SQL ¶

动态 SQL是一种用于在运行时生成和运行 SQL 语句的编程方法。在编写诸如动态查询系统之类的通用且灵活的程序时，在编写必须运行数据库定义语言 (DDL) 语句的程序时，或者当您在编译时不知道 SQL 语句的全文或编号或编号，或其输入和输出变量的数据类型时，它很有用。

也可以看看：

PL/SQL 动态 SQL

2.4.3. 异常处理 ¶

异常（PL/SQL 运行时错误）可能来自设计错误、编码错误、硬件故障和许多其他来源。您无法预料所有可能的异常，但您可以编写异常处理程序，让您的程序在它们存在的情况下继续运行。

也可以看看：

PL/SQL 语言参考

2.4.4. 批量绑定 ¶

批量绑定将 PL/SQL 与 SQL 之间通信的性能开销降到最低，可以大大提高性能。

也可以看看：

批量绑定概述。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家小花儿/article/detail/523791