Oracle TimesTen内存数据库 60版推荐编程实践.pdf

《Oracle TimesTen内存数据库 60版推荐编程实践.pdf》由会员分享，可在线阅读，更多相关《Oracle TimesTen内存数据库 60版推荐编程实践.pdf（29页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 Oracle TimesTenOracle TimesTenTMTM内存数据库 内存数据库 6.0 版推荐编程实践6.0 版推荐编程实践 性能和稳定性最佳的 TimesTen 应用程序的设计方法 内存数据库内存数据库 版权 1996、2005 归 Oracle 公司所有。未经允许不得以任何方式和手段进行复制和使用。附带的和光盘上的软件和文档（不管是硬拷贝形式还是电子形式）的使用和披露均应依据本许可协议。被许可方可印刷存储在光盘上的文档，但仅限内部使用。除上面提到的以外，未经 TimesTen 公司事先书面许可，不得以任何电子或机械形式或手段，包括影印、录制或通过任何信息存储和检索系统，复制或

2、传播本文档的任何部分（不管是硬拷贝形式还是电子形式）。Oracle、JD Edwards、PeopleSoft、Retek、TimesTen、TimesTen 标志、MicroLogging 和 Direct Data Access 是 Oracle 公司和/或其子公司的商标或注册商标。其他名称可能是其各自所有者的商标。程序（包括软件和文档）包含专有信息；是依据一份包含了使用和披露限制条款的许可协议而提供的，并受版权、专利其他知识产权和工业产权法的保护。除非法律有明确规定，或是为实现与其他独立开发的软件间的互操作性，否则不得对软件程序进行反向工程、反汇编或反编译。本文所含信息如有变动，恕不另行

3、通知。如果您在本文中发现任何错误，请书面通知我们。我们不保证本文没有错误。除非在您的许可协议中对此有明确许可，否则不得为任何目的，以任何电子或机械形式或手段复制或传播这些程序的任何部分。2005 年 8 月 19 日 在美国印刷。目录 1 概述 TimesTen 文档参考索引.1 术语.1 “TimesTen 应用程序”或“直连应用程序”.1 “TimesTen 客户机/服务器应用程序”.2 install_dir.2 C+用户：考虑使用 TTClasses.2 2 实现最佳性能 TimesTen 文档中的性能信息.4 有关最常见问题的（影响性能的因素）建议.4 运行对性能要求高的直连应用程序

4、.4 预先准备好所有 SQL 语句.5 控制磁盘写频率.6 为查询创建合适的索引.6 使用“showplan”验证是否使用了合适的索引来进行查询.8 关闭自动提交(autocommit)并定期提交.9 C/C+(ODBC)与 Java(JDBC)性能比较.9 通过在加载数据之后创建索引来加速（大批量）数据加载.10 使用 TTClasses，避免使用 OLEDB、ADO 和第三方中间件.10 多 CPU 性能调优.10 使用连接池.11 最大限度地提高数据库的并发性.11 及时关闭只读游标.11 避免大批量的删除语句.11 考虑使用“DELETE FIRST NumRows”.12 缩短不必要

5、的长期运行的事务.12 3 最大限度地提高稳定性 最大限度地提高稳定性.13 TimesTen 文档.13 TimesTen 架构和数据库恢复简明指南.13 避免应用程序的意外失败.14 必须断开 TimesTen 应用程序与数据库的连接.14 避免对 TimesTen 应用程序使用“kill 9”命令.14 备份.14 检查点.15 其他好的实践.15 检查所有 ODBC 函数的返回码，然后处理它们.15 处理数据库失效错误.16 处理死锁和锁超时错误.16 从一个已满磁盘恢复.17 4 复制和 XLA 复制.18 将 DSN 名用作文件名前缀.18 在进行duplicate 操作之前执行两

6、个检查点操作.19 复制配置应（手动）指定端口号.19 监控复制.20 SEQUENCE 与复制和故障恢复的相互影响.21 XLA.21 使用持久性 XLA.21 始终监控 XLA.22 最大限度地提高 XLA 性能.22 索引 1 Oracle TimesTen内存数据库推荐编程实践 1 概述 本文详细介绍了如何利用 TimesTen 开发具有最佳性能和强健性的应用程序。TimesTen 文档参考索引 TimesTen 文档参考索引 下表列出了本文引用的章节，以及它们在 TimesTen 6.0 文档中的位置。?TimesTen 内置程序:tt_ref.pdf?性能调优：C_dev.pdf;

7、java_dev.pdf?TimesTen 查询优化器：operations.pdf?事务管理与恢复：operations.pdf?警告与错误：tt_ref.pdf?TimesTen 实用程序:tt_ref.pdf?TTClasses:ttclasses.pdf 术语 术语 下面是本文所使用的一些术语及其含意。“TimesTen 应用程序”或应用程序”或“直连应用程序”“直连应用程序”本术语指一个直接连接到 TimesTen 数据库的应用程序。C 和 C+应用程序显式地连接到下列共享库之一：?libtten.so(Solaris、Linux)?libtten.sl(HP-UX)?tten60.

8、lib(Windows)?等等 以“直连”模式使用 TimesTen 的 Java 应用程序以“jdbc:TimesTen:direct:.”的形式连接数据源。这些应用程序与它们所访问的 TimesTen 数据库驻留在同一台机器上。这样一来，再通过使用“直连”TimesTen 驱动程序，TimesTen 应用程序将可获得 2 Oracle TimesTen内存数据库推荐编程实践 最佳性能。“TimesTen 客户机客户机/服务器应用程序”服务器应用程序”该术语指一个使用 TimesTen 客户机/服务器接口来与数据库连接的应用程序即显式地连接到共享库中?libttclient.so(Solar

9、is、Linux)?libttclient.sl(HP-UX)?ttcl60.lib(Windows)?等等 以 客 户 机/服 务 器 模 式 使 用TimesTen的 Java应 用 程 序 以“jdbc:TimesTen:client:.”的形式连接数据源 客户机/服务器应用程序可与 TimesTen 数据库驻留在同一台机器上，也可驻留在其他机器上。客户机/服务器应用程序的运行速度要比直连应用程序慢很多。无论是直连应用程序还是客户机/服务器应用程序，提供给它们的 API 和功能都是一样的。install_dir 这是 TimesTen 的安装路径。参考 OracleTimesTen 内存

10、数据库安装指南了解更多信息。默认路径为：?/opt/TimesTen/InstanceName（UNIX;根用户安装的实例）?$HOME/TimesTen/InstanceName（UNIX;非根用户安装的实例）?C:TimesTentt60(Windows)注意：基于安全的考虑，我们推荐，如果可能的话，以非根用户的身份安装TimesTen。C+用户：考虑使用 TTClasses C+用户：考虑使用 TTClasses TimesTen C+接口类，即 TTClasses，编写它的目的是提供易用、高性能的TimesTen 接口。C+类库为大多数常见的 ODBC 功能提供了“封装”，包括SQL

11、查询执行、事件通知（XLA）和系统目录信息。此外，TTClasses 的设计采用了许多本文推荐的实践。TTClasses 类包含在 TimesTen 内存数据库中。与 TimesTen 一起提供的还有一些有用的示例应用程序，用于演示如何使用TTClasses 类。在示例程序中包含如下一些程序：示范如何监视和管理 TimesTen 3 Oracle TimesTen内存数据库推荐编程实践 数据库；如何使用 TimesTen 的 XLA 实施一个事件通知程序；如何估计数据库的大小；以及如何管理 XLA 书签。4 Oracle TimesTen内存数据库推荐编程实践 2 实现最佳性能 本章重点讨论如

12、何编写具有最佳性能的 TimesTen 应用程序。TimesTen 文档中的性能信息 TimesTen 文档中的性能信息 现有的 TimesTen 文档是学习关于如何调优应用程序性能的基础知识的首选资源。在阅读本章其余部分之前，请务必认真阅读 TimesTen 文档“性能调优”这一章。有关最常见问题的（影响性能的因素）建议 有关最常见问题的（影响性能的因素）建议 本章的其余部分将讲述那些客户经常遇到的问题。请注意，这些问题在TimesTen 文档中也有所描述。运行对性能要求高的直连应用程序运行对性能要求高的直连应用程序 通过使用 TimesTen 的“直连”ODBC 和 JDBC 驱动程序，并

13、在数据库所在的机器上运行应用程序，就很容易实现 TimesTen 的最佳性能。其他机器上的应用程序可通过客户机/服务器模式访问 TimesTen 数据库，但网络流量负载将极大地降低性能。通过利用 TimesTen 的 Replication 和 Cache Connect to Oracle 技术，通常可以在本地访问数据，而不会产生客户机/服务器模式的流量负载。注意：TimesTen 采用客户机/服务器架构模式运行虽然不如采用直接内存模式运行得快，但它还是很快的。TimesTen 客户机/服务器应用程序比连接到传统的客户机/服务器数据库的应用程序性能高；尤其是，与传统的数据库相比，TimesT

14、en具有更高的吞吐能力。在下面这些情况下，应考虑以客户机/服务器模式连接 TimesTen 数据库。1)应用程序运行在一台主机上，TimesTen 数据库驻留在另一台主机上。2)一个 32 位的客户端应用程序必须连接到 64 位的 TimesTen 数据库，并且 32位的客户端应用程序无法重新编译为 64 位。如果应用程序与 TimesTen 数据库在同一台机器上，或能够被重新部署到该机器上，但是不能被重新编译为64 位模式，TimesTen 建议采用 TimesTen 共享内存进程间通信（SHMIPC）。5 Oracle TimesTen内存数据库推荐编程实践 对于客户机/服务器模式的数据库

15、连接而言，与 TCP/IP 连接相比，SHMIPC大幅提高了性能。需要有大量 TimesTen 客户机/服务器连接的系统设计应考虑到每一数据库连接均都会消耗服务器主机的操作系统资源。在服务器主机的规模设置和操作系统调优过程中应考虑这一因素。预先准备好所有预先准备好所有 SQL 语句语句 为实现最佳性能，应预先准备好那些执行不止一次的 SQL 语句。这一准则适用于所有关系数据库；但是对于 TimesTen 及其极高的事务处理速度来说，编译一条语句所耗费的时间实际上要比执行该语句所花的时间多好几倍；因此，未预先准备好语句的应用程序将使 TimesTen 的性能大打折扣。除了要预先准备好语句，那些语

16、句的输入参数和输出列也应预先绑定。欲了解有关语句准备的更多信息，请参考 TimesTen 文档“性能调优”一章标题为“预先准备语句”部分。ODBC 用户使用 SQLPrepare 函数预先准备语句。TTClasses 用户使用 TTCmd:Prepare()方法预先准备语句。JDBC 用户使用 PreparedStatement 类预先准备语句。TimesTen 查询优化器十分擅长选择最优的查询计划；然而，为了选择最优计划，它需要获得复杂查询所涉及到的表的更多信息。就查询优化器选择最优查询计划来说，数据库统计信息对其是很有帮助的。通过了解表的行数和列值数据分布，优化器更有可能选择出一个高效的表

17、查询计划。因此，通常一个好的做法是，在准备访问那些表的查询语句之前，先更新数据库中所有表的统计信息。注意，如果你在表包含行之前更新表的统计信息，那么将会以表没有包含行（或包含很少的行）为假定来对查询进行优化。如果你后来向表中添加了数百万行，然后执行查询，那么在表只包含极少数行的情况下工作良好的查询计划现在可能会变得很慢。因此，你应该在向表加载数据后，在准备查询语句之前，更新表的统计信息。欲了解关于更新统计信息的更多信息，请参考 TimesTen 文档“TimesTen 内 6 Oracle TimesTen内存数据库推荐编程实践 置程序”一章对 ttOptUpdateStats 和 ttOpt

18、EstimateStats 的描述。有关其他 ttOpt*内置程序的描述也包含在这一章之中，你可以借此了解更多有用信息。控制磁盘写频率控制磁盘写频率 多数应用程序都要求某种级别的数据库持久性；也就是说，如果系统崩溃（因某种类型的软硬件故障），应用程序要求最近对数据库所做的更新不会丢失。利用 DurableCommits 连接属性可以有多种方法来配置 TimesTen：?第一种方法是以连接属性 DurableCommits=1 来连接 TimesTen 数据库。在这种连接中，每一次事务提交都会将事务日志写入磁盘；因而，应用程序将拥有充分的持久性。然而，设置 DurableCommits=1，应用

19、程序的写性能将大大降低。注意：如果数据库中存在大量用户并发写库的情况，使用DurableCommits=1 仍能够获得很好的整体吞吐能力。?第二种方法是，内存事务缓冲区一旦变满（默认方式，即 DurableCommits=0），TimesTen 数据库就将缓冲区数据写入磁盘。该方法可实现最佳性能，因为只在确实有必要时，才执行磁盘写操作，事务处理永远不会因写磁盘而受阻；然而，采用这种方法的应用程序将无法确切知道其事务处理的持久性水平（毫无疑问它不会丢失比内存日志缓冲区能容纳的事务更多的数据）。对 于 使 用DurableCommits=0的 应 用 程 序，TimesTen内 置 程 序ttDu

20、rableCommit 使应用程序开发人员能够精确确定 TimesTen 内存日志缓冲何时被写入磁盘，从而可将持久性和性能控制到合适水平。应用程序能够确定哪些事务会导致同步的磁盘写操作，哪些不会。通过这种方式，应用程序能够精细地平衡性能和数据持久性。对于某些应用程序，按设定的时间间隔调用ttDurableCommit 是很合理的，这样能保证一次仅会损失极少的，例如约 100 毫秒的未写入磁盘的日志缓冲区数据；对于其他应用程序，某些提交操作必须使数据库处于持久状态（例如，账户间的资金转移）。不管 DurableCommit 如何设置，TimeTen 复制和/或从 TimesTen 到 Oracl

21、e 的更新传播可被用来进一步提高事务持久性。为查询创建合适的索引为查询创建合适的索引 想要知道创建多少索引才能实现最佳数据库性能颇有难度。如果你创建的索引太少，那么某些经常性的数据库操作会比平常慢；如果你创建的索引太多，那么插入/更新/删除操作则会耗用太多的时间，因为需要额外的时间来更新索引。在设计 TimesTen 数据库表和索引模式时，有以下几个需要考虑的问题。?有两种类型的索引：哈希索引和 T 树索引。对于精确匹配查询，调优的哈希 7 Oracle TimesTen内存数据库推荐编程实践 索引要快于 T 树索引，但是哈希索引不能用于范围查询（T 树索引既可用于精确匹配查询，也可用于范围查

22、询，以及分类查询，如涉及 ORDER BY、GROUP BY 或 DISTINCT 子句的 SQL 查询）。?使用哈希索引为每个表的主键建立索引。?需要对哈希索引进行调优。应始终使用“CREATE TABLE”语句的“pages=”选项来指定表的期望大小（用 256 除以表的行数，即可得到你需要为哈希索引指定的页数）。为索引指定的页数太多将浪费不必要的空间；而指定的页数太少则会降低哈希索引的性能，因为此时哈希桶（buckets）会溢出。如果需要，可在其创建后使用 ALTER TABLE 语句来更改主键索引的大小。?通过引入一个 T 树索引（任何 T 树索引），可改进一个未包含 T 树索引的表的

23、全表扫描性能，即使对该表的扫描没有引用该索引的列。这虽然不太直观，却很容易证实。因此，你应该为应用程序的全表扫描所引用的每一个表建立至少一个 T 树索引。?一个哈希三列索引只能被用于三列全部精确匹配的查询。T 树索引列的任何前导前缀可被用于一个精确匹配查询。?在两者都可以使用的情况下，对于等式谓词，哈希索引的性能要优于 T 树索引。然而，哈希索引需要的空间比 T 树索引大。最后一条有些复杂，因此我们举例说明。考虑这样一条查询 SELECT FROM T1 WHERE COL1=?AND COL2=?情景#1:T1 表有两个索引：?哈希索引：(COL1,COL2)?T 树索引：(COL1,COL

24、2,COL3)在这种情况下，两种索引都能用于返回这一查询。此处可以使用哈希索引，因为 WHERE 子句的各列与哈希索引的各列完全匹配；T 树索引也可用于返回该查询，因为 WHERE 子句的列是该索引列的前导前缀（前两个）。TimesTen 优化器将选择哈希索引（因为它速度更快）。情景#2：T1 表有两个索引：?哈希索引：(COL1,COL2,COL3)?T 树索引：(COL1,COL2)在这种情况下，只有 T 树索引能被用于返回这一查询。此处不能使用哈希索引，因为 WHERE 查询子句中没有指定哈希索引列 8 Oracle TimesTen内存数据库推荐编程实践(COL3)。而 T 树索引的列

25、与 WHERE 查询子句中的列完全匹配。TimesTen 优化器将选择 T 树索引。情景#3：T1 表有两个索引：?哈希索引：(COL1)?T 树索引：(COL3,COL1,COL2)在这种情况下，只有哈希索引能被用于返回这一查询。可使用哈希索引，因为其所有的列均包含在 WHERE 查询子句之中；注意由于 WHERE 查询子句中有另外的列，所以在返回查询结果之前，从哈希索引读取的每一行都会应用“COL2=?”谓词。不能使用T树索引，因为T树首先使用COL3分类，而查询未涉及COL3。TimesTen 优化器将选择哈希索引。情景#4：T1 表有两个索引：?哈希索引：(COL1,COL2,COL3

26、)?T 树索引：(COL3,COL1,COL2)在这种情况下，两种索引都无法有效地返回查询结果（尽管 T 树索引可用于全表扫描）。出于上述情景#2 中同样的原因，哈希索引无法使用。不能使用 T 树索引，因为查询的列（COL1,COL2）不是索引的前导前缀。由于两种索引都不能使用，数据库将不得不执行一次表扫描以返回查询结果（或可能建立一个临时索引），这样查询性能将十分糟糕。从这四个例子你不难看出，你必须基于计划查询数据库的最频繁的查询来审慎选择你所创建的索引。欲了解创建合适索引的更多信息，参见 TimesTen 文档“性能调优”一章标题为“调优语句和使用索引”和“适当选择哈希索引或 T 树索引”

27、的这两部分。使用“使用“showplan”验证是否使用了合适的索引来进行查询”验证是否使用了合适的索引来进行查询 如果你发现某一特定查询进行得比预期的慢，可能是 TimesTen 优化器没有选择最优的查询计划来返回该查询。如何了解你的查询计划？在 TimesTen 文档的“TimesTen 查询优化器”一章中的“审视查询计划”部分对这个问题有深入的阐述。9 Oracle TimesTen内存数据库推荐编程实践 关闭自动提交关闭自动提交(autocommit)并定期提交并定期提交 在 ODBC 和 JDBC 中，默认情况下，与数据库的所有连接都会设为自动提交开启状态。这意味着每一独立的 SQL

28、语句都在其自己的事务中被提交。通过关闭自动提交，并在一次事务处理中明确提交多个 SQL 语句，将会极大地提高应用程序的性能。这对大批量操作尤其有意义，如大批量插入或大批量删除。（TTClasses 用户会注意到自动提交在默认情况下是关闭状态。）然而，这可能会在一次事务处理中集中了过多操作（这会降低系统整体并发性，因为锁定的时间过长）。一般来说，大批量插入/更新/删除操作在你每次提交几千行时的工作效率是最高的。C/C+(ODBC)与与 Java(JDBC)性能比较性能比较 TimesTen 的本机 API 是 ODBC。TimesTen Java JDBC 驱动程序是构建在TimesTen OD

29、BC 驱动程序之上的 II 型驱动程序。因此，使用 TimesTen ODBC 驱动程序的 C/C+应用程序的性能要稍优于使用 TimesTen JDBC 驱动程序的 Java应用程序。对性能要求极高的应用程序应使用 TimesTen ODBC 驱动程序进行开发。注意：TimesTen JDBC 驱动程序速度非常快。TimesTen JDBC 性能大大优于其他数据库的 JDBC 性能。TimesTen JDBC 驱动程序仅比 TimesTen ODBC 驱动程序慢一点点；而且差别是可测的。ODBC 与 JDBC 间预计的性能差异受执行的查询类型(SELECT 与 UPDATE/INSERT/D

30、ELETE)和事务组合（读到写）的影响。影响性能的因素包括：1)为预先准备的语句绑定的参数的数量增加绑定参数的数量会降低 Java应用程序的性能。2)SELECT语句返回的列的数量增加SELECT语句返回的列的数量会降低Java 应用程序的性能。3)参数和列的类型在 JDBC 中，包含大量字节的数据类型通常会比较慢。基本上，随着在应用程序和数据库间传输的数据量的增加，Java 应用程序的性能将会降低。欲了解 ODBC 与 JDBC 间预计的性能差异的详细信息，请与TimesTen 技术支持或你的 TimesTen 客户团队联系。Java 固有的一些其他问题也会影响 Java 应用程序的性能：1

31、)JVM 垃圾回收在 JVM 垃圾回收期间，Java 应用程序的响应将会极慢。对高性能的“实时”应用程序来说，这种垃圾回收将难以保证一致的性能。精心调优 JVM 垃圾回收对最大程度地降低或消除这些性能骤降是很有必要的。10 Oracle TimesTen内存数据库推荐编程实践 2)Java 运行时内存管理Java 运行时内存管理子系统通常会导致隐性数据拷贝，对于字符串对象情况更是如此。3)高度多线程化的 Java 应用程序的扩展性就 TimesTen 而言，我们的经验是：高度多线程化的 Java 应用程序的扩展性没有预期的那样好。这部分是由于 JVM 线程调度程序与操作系统的线程调度程序的设计

32、差异。在多数情况下，使用多个 JVM 执行多个线程的整体性能要好于只使用单个 JVM 的情况。我们还发现某些 JVM 要比另外一些 JVM 速度更快。请审慎评估你的选择。通过在加载数据之后创建索引来加速（大批量）数据加载通过在加载数据之后创建索引来加速（大批量）数据加载 如果应用程序的设计允许，你可以通过在加载数据后创建 T 树索引来最大限度地缩短加载数据所需的时间。在这种情况下，操作顺序为：1)数据加载到表（在表加载操作进行期间，禁用日志和/或使用数据库级锁将可提供更优的性能）2)创建 T 树索引 3)更新统计信息 4)准备查询语句 注意这只适用于极大批量的数据加载操作（例如，数百万行）。使

33、用使用 TTClasses，避免使用，避免使用 OLEDB、ADO 和第三方中间件和第三方中间件 许多第三方数据库接口软件包会降低数据库的性能。如果性能对某一特定应用程序不是特别重要，则可以使用这些接口程序，但用户应该明白此时性能会有所降低。由于这些第三方软件包速度较慢，TimesTen 开发了自己的名为 TTClasses的 C+ODBC 封装类，它已包含在 TimesTen 数据库中。欲了解关于 TTClasses的更多信息，请参见第 1 页的“TimesTen 文档参考索引”。多 CPU 性能调优 多 CPU 性能调优 要实现最佳的 SMP（对称多处理）性能，还有许多其他事情要对应用程序

34、正确加以处理。这一部分专门讨论在多 CPU 机器上实现最佳性能还需要做哪些事情。11 Oracle TimesTen内存数据库推荐编程实践 使用连接池使用连接池 如果你的 TimesTen 应用程序是多线程的，并且打开了到同一数据库的多个连接，你一定要谨慎管理你的这些连接。一般来说，如果同时连接到数据库的激活连接数多于 CPU 数目时将难以获得最佳性能；事实上，多个 TimesTen 并发连接（连接到同一数据库）会极大地降低数据库的整体吞吐能力。避免这一问题的一个方法就是使用连接池。连接池的一个很好的例子就是TTClasses 中的 TTConnectionPool 类。欲了解关于 TTCla

35、sses 的更多信息，请参见第 1 页的“TimesTen 文档参考索引”。最大限度地提高数据库的并发性 最大限度地提高数据库的并发性 对任何数据库系统来说，如果一些用户占用了太多的系统资源，就会影响到其他用户的使用性能。下面是一些常见的例子和简单的解决方案。及时关闭只读游标及时关闭只读游标 与 Oracle 类似，TimesTen 只读事务无须提交。然而，为了释放一个只读 SQL查询所占用的所有资源（如分类所占用的临时空间），及时关闭只读游标就显得非常重要了。下面是关闭 SQL 游标的方法：?ODBC SQLFreeStmt(SQL_CLOSE)?TTClasses TTCmd:Close(

36、)JDBC PreparedStatement.close()避免大批量的删除语句避免大批量的删除语句 避免使用“DELETE FROM”语句 如果一个表有许多行（10 万行或更多），试图在一个单一 SQL 语句（在一次事务）中删除它们是有问题的。首先，这种方法速度较慢。TimesTen 将删除的每一行都记入日志，以防万一操作需要回滚；写入所有这些日志记录会非常耗时（因为要对磁盘进行写操作）。这种大批量的删除操作还存在另一个问题，那就是在发生写密集型删除事务时，其他数据库操作将会变慢。在单次事务中删除数百万行需要好几分钟才能完成。12 Oracle TimesTen内存数据库推荐编程实践 当对

37、表进行复制时，一次删除数百万行就会遇到第三个问题。由于复制仅传输已提交的事务，传输一个单一的几百 MB（或 GB）的事务会使复制代理的速度变慢。TimesTen 的复制被优化为许多小型事务，在一次事务中删除数百万行将会使其速度变慢。首选“TRUNCATE TABLE”语句 考虑采用 TRUNCATE TABLE 语句，而不采用删除表中的所有行的方法。执行该语句的最终效果与执行不带 WHERE 子句的 DELETE 语句相同，这极大地减少了日志记录。此外，在使用复制时，TRUNCATE 操作是作为一个单一操作被复制给任何其他数据库的，而不是每删除一行就视为发生一个操作。考虑使用考虑使用“DELE

38、TE FIRST NumRows”当必须删除大量的行而 TRUNCATE 语句又不适用时，考虑使用“FIRST NumRows”子句从一个表中批量删除行。“FIRST NumRows”句法使你能够将“DELETE FROM TableName WHERE.”语句变成一系列“DELETE FIRST 10000 FROM TableName WHERE.”操作。通过将大量删除操作分割成一批小型操作，行删除速度会快得多，系统的整体并发性和复制性能也不会受影响。缩短不必要的长期运行的事务缩短不必要的长期运行的事务 如第 18 页“处理死锁和锁超时错误”所述，一个长期运行的事务会使其他数据库操作因锁超

39、时错误而失败。一般而言，长期运行的事务会降低系统的整体并发性，这是由于资源在很长的时间内保持锁定状态。因此，长期运行的事务会影响系统整体稳定性和整体性能。13 Oracle TimesTen内存数据库推荐编程实践 3 最大限度地提高稳定性 最大限度地提高稳定性 最大限度地提高稳定性 本章重点讨论如何编写强健性和稳定性俱佳的应用程序，也就是编写尽可能长时间与数据库保持连接的应用程序。TimesTen 文档文档 TimesTen 现有的文档含有关于开发容错性强的应用程序的大量信息。感兴趣的读者可以参考 TimesTen 文档的“事务管理和恢复”、“TimesTen 内置程序”和“诊断、错误和警告”

40、这三章。TimesTen 架构和数据库恢复简明指南 TimesTen 架构和数据库恢复简明指南 TimesTen使用一个共享的内存段来在内存中存储TimesTen数据库的部分内容。当一个应用程序连接到 TimesTen 数据库时，它会将该数据库的共享内存段映射到它的地址空间。共享内存的使用使多个进程连接到一个单一的数据库映像。在使用共享内存的传统应用程序中，每一个连接到共享内存的应用程序进程的稳定性会极易影响共享内存的结构。一个不稳定的应用程序常常会导致共享内存错误和应用程序失败。当应用程序正在更新共享内存时必然被（例如，由“kill-9”命令）终止，就会发生这种情况。这会使共享内存处于一种不

41、一致的状态，数据结构仅得到部分更新。TimesTen 通过使用 Micrologging技术来防止某个应用程序的意外失败对其他应用程序的损害，从而避免此类问题的发生，即使是在使用共享内存的情况下。如果某个应用程序在修改 TimesTen 共享内存时失败，TimesTen 能够检测到这种情况并能够使共享内存回滚到一致、正确的状态。尽管 TimesTen 能够从应用程序的意外失败中恢复，然而这么做会占用本来能够更好地用于运行应用程序的资源。避免这种开销其实很容易，只需在应用程序开发过程中遵循以下几个简单步骤。14 Oracle TimesTen内存数据库推荐编程实践 避免应用程序的意外失败 避免应

42、用程序的意外失败 以下建议对设计 TimesTen 应用程序会很有帮助。必须断开必须断开 TimesTen 应用程序与数据库的连接应用程序与数据库的连接 有许多方法可以用来终止应用程序。一种方法是调用 exit()函数或 abort()函数或到达 main()函数的结尾处；另一种方法是收到一个信号。如果进程接收到一个不能捕获的信号，它就会终止，而且可能使数据库失效。在终止之前，应用程序应回滚任何正在处理中的事务，并断开与 TimesTen数据库的连接。因此，使用 TimesTen 的 C 和 C+应用程序应实施一个信号处理器，该信号处理器捕捉其他进程可能发给该应用程序的所有信号。最好的方法就是

43、通过一个特定的信号处理线程来做这件事。某些应用程序把信号用于进程间通信；这样接收到一个信号未必就意味着要终止进程。对于 Java 应用程序，可使用“shutdown hooks”来达到同样的目的。一般来说，与 TimesTen 一起提供的示例说明了如何恰当地使用信号。可以看一下“ttCGmonitor”(monitor.cpp)，它是一个很好的例子。对于 Java 应用程序，“Tutorial”目录下的示例说明了如何恰当地使用“shutdown hooks”。避免对避免对 TimesTen 应用程序使用“应用程序使用“kill 9”命令”命令 SIGKILL 信号（这相当于在 Windows

44、平台上使用任务管理器中的“结束进程”）不能被进程捕获。“kill 9”强行终止目标进程，在此之前目标进程无法做任何反应。因此，我们不主张对 TimesTen 应用程序执行“kill 9”命令。你应该这样设计你的应用程序和系统，那就是在生产环境中永远没有必要使用“kill 9”命令。这是一个很好的主意。备份 备份 对于任何数据库而言，定期进行备份对保证数据完整性是很有必要的。备份数据库并将这些备份存储在可移动介质或另一组永久性挂载介质上，将降低 15 Oracle TimesTen内存数据库推荐编程实践 由于数据库硬件（如，磁盘驱动器）故障导致数据丢失的可能性。TimesTen 的 ttBack

45、up 程序使数据库备份非常容易进行。备份可在后台进行，而同时可继续执行正常的数据库操作。备份不会锁定数据库，因此这是一个高效的过程。检查点 检查点 周期性地进行检查点操作对 TimesTen 数据库的运行非常重要。调整检查点频率会对某些应用程序有益。TimesTen 在磁盘上维护了每个数据库的内容的两个完整的镜像。这些镜像称为“检查点”。TimesTen 定期自动更新磁盘上的这些检查点，使它们与当前的数据库内容保持同步。这些同步操作是在后台异步进行的，因此不会涉及到应用程序。这些周期性的检查点操作之所以重要，有两个主要原因。(1)检查点操作使 TimesTen 能够释放事务日志的空间。通过删除

46、旧的事务日志文件，磁盘就不会占满，并保持 TimesTen 继续顺畅运行（参见第 19页“从一个已满的磁盘恢复”，了解监视磁盘空间的重要性）。(2)删除日志文件还可减少在系统失败时恢复数据库的时间。这是因为Timesten 将数据库加载到内存所需的时间与磁盘上日志文件的数量成正比。默认情况下，TimesTen 每隔 600 秒（10 分钟）或每当写满 64MB 日志数据时，对数据库进行一次检查点操作。上述任一种条件满足时，TimesTen 就进行这种操作。如果需要，可以使用 CkptFrequency 和 CkptLogVolume 数据库属性来改变这种行为方式。其他好的实践 其他好的实践 检

47、查所有检查所有 ODBC 函数的返回码，然后处理它们函数的返回码，然后处理它们 在使用 ODBC 时，有必要检查所有 ODBC 函数的返回码。如果检测到警报或错误，你的应用程序应恰当地处理它们。接下来的两部分将描述将会出现的一些最重要的错误。想要查看全部错误码和 TimesTen 用于描述这些错误码的助记符，请参见文件：install_dir/include/tt_errCode.h。关于应用程序通常如何处理错误的简单描述，请参考“事务管理和恢复”一章标题为“处理应用程序中的 TimesTen 错误和恢复”的部分。16 Oracle TimesTen内存数据库推荐编程实践 当使用JDBC(Ja

48、va)和TTClasses(C+)时，如果发生了与数据库有关的错误，在大多数情况下异常会被“扔出”。这些错误必须使用适当的 try/catch 块来加以处理。处理数据库失效错误处理数据库失效错误 同任何数据库一样，TimesTen 数据库也有可能会失效。当应用程序所连接的数据库意外“宕机”时，应用程序必须处理这种情况。有许多原因会导致数据库失效。可能是管理员终止了 TimesTen 实例。也可能是一个重大的硬件错误影响了数据库。或者，TimesTen 无法使用 Micro Logging回滚一个失败的应用程序提交的改变，这种情况比较少见。如果发生这种情况，TimesTen 将使数据库“失效”，

49、并要求所有应用程序停止使用数据库。有两个 TimesTen 错误码用于指示应用程序连接到了一个失效的数据库：846(tt_ErrBadConnect)和 994(tt_ErrDrtyByte)。当应用程序接收到这两个错误码中的任何一个时，应用程序必须回滚它们已经开始处理的所有事务，在继续处理之前必须断开与数据库的连接并重新进行连接。一个简单有效的处理数据库失效错误的方法可在 ttMonitor 的 C+源码中找到（文件名：monitor.cpp），该文件与 TimesTen 一起提供。处理死锁和锁超时错误处理死锁和锁超时错误 通常采用同样的方法处理死锁和锁超时，尽管它们通常是由不同的原因引起的

50、。当数据库中两个并发的事务争用相同的资源，并且每个事务都占用了另一事务继续进行所必需的资源时，就会发生死锁错误。死锁发生后，要使事务处理得以继续，唯一的方法就是由数据库选择一个“牺牲品”，并向该事务发送死锁错误。TimesTen 死锁错误码为 6002(tt_ErrDeadlockVictim)。当数据库中两个并发的事务争用相同的资源，而其中一个事务未能在给定的时间内获得该资源时，就会发生锁超时。通常这种情况的发生是由于一个事务长期运行而不进行提交（从而长时间占用锁），进而妨碍其他事务锁定长期运行事务已锁定的资源。无法获得锁的事务将收到 TimesTen 错误码 6003(tt_ErrTime