6.1.3    TimesTen技术架构 接下来,我们就从应用形式、内部架构、连接方式、高可用形式四个方面来进行一个TimesTen技术架构的概述。 1.  应用形式 前面说到,TimesTen可以单独使用,也可以作为Oracle的缓存来使用,这里我们就先来介绍一下TimesTen内存数据库的使用形式,具体如下: q  TimesTen内存数据库(TimesTen In-Memory Datab […]

6.1.2 TimesTen应用场景 在谈论TimesTen内存数据库应用场景之前,我们先来介绍一下什么是内存数据库,及其工作原理吧。内存数据库,顾名思义就是将数据存放在内存中,并通过内存操作直接完成数据库相关操作。与磁盘相比,数据在内存中的读写速度要高出几个数量级,能够极大地提高应用程序的性能。同时,内存数据库抛弃了磁盘数据管理的传统方式,基于全部数据都在内存中,重新设计了体系结构,并且在数据缓 […]

6.1.1 TimesTen历史与定位 罗马不是一天建成的,TimesTen内存数据库虽然比不上Oracle数据库那样历史悠久,但也是经年地沉淀和积累造就的。 先来看一下TimesTen的发展历史的几个重大事件吧: q  1992年,TimesTen在HP美国总部第一个内存数据库的实验室诞生, 主要研究内存数据库技术在电信网络中的应用; q  1996年,TimesTen从HP实验室分离出来,成立 […]

第1章 大道至简 Page 4:Line 13: 原文: “与Oracle相比,MySQL只能作为一个数据容量来看待。” 修改为: “与Oracle相比,MySQL只能作为一个数据容器来看待。” 第2章 高效B树索引 Page 49:Line 1: 原文为: SQL> declare 2 seq number := 1; 3 begin 4 for i in 1 .. 100000 loop […]

2.5.4 废旧索引清理 索引这东西和表不一样,对于表来说往往可以很明确什么时候新建,什么时候下线。索引则不然,新建索引可以很明确,但在表没有下线的时候,我们往往会非常纠结索引是不是可以下线。如果将一个尚有业务使用的索引下线了,那将意味着一场灾难,由此而导致DBA们都不敢删除索引,结果就成了一个表上的索引越来越多。 那如何解决这个问题呢?简单来说就是严进严出,不轻易新建更不轻易删除。如前面章节介绍 […]

2.5.3 如何重建索引 对于重建索引来说,似乎没有太多的好办法,大致有索引重建和索引重组两种。而重组和重建都可分为在线操作和离线操作。 q  离线重组:alter index idx_alex_t05_id shrink space q  在线重组:alter index idx_alex_t05_id coalesce q  离线重建:alter index idx_alex_t05_id r […]

2.5.2 何时重建索引 索引需要定期重建来保证其使用的高效性,但是这个时间点不是那么容易把握的。不是什么时候心血来潮来就重建一下,也不是性能报警了才去考虑重建,它应该是有一些标准和阀值来控制的。下面我们将介绍一下如何判断一个索引是否到了需要考虑重建的时间点。 1.  判断标准 要判断也是需要有一个判断标准的。关于标准也是各有各的说法,不能说谁对谁错,只能说各有各的适应环境。这里我们也说一个普遍被 […]

2.5 索引维护 索引对于性能保障的重要性是不言而喻的,一个优质的索引是性能的润滑剂,相反,劣质的索引将是性能的“绞肉机”。通过2.4节的介绍,我们了解到了一个设计优良的索引,在经过日常业务应用,特别是OLTP的高并发“摧残”之后,将变得满目疮痍,原本优质的索引也可能转变为劣质的。 这就需要DBA的介入,找到劣质的索引,并恢复其优质的本相。索引的后期维护可能是DBA们日常维护工作中非常重要的一部分 […]

切换到手机版