Informix数据仓库解决方案数据库

Informix数据仓库解决方案数据库（精选6篇）

Informix数据仓库解决方案数据库 第1篇

根据Informix数据仓库系统实施方法学，我们可以将数据仓库的实施分为以下几个步骤： 1.业务需求分析 业务需求分析是数据仓库建设的基础，应该同用户进行充分沟通，了解用户的真实需求，避免理解的误差，同时，应该界定好项目 开发 范围， 在此阶段，主要工作

根据Informix数据仓库系统实施方法学，我们可以将数据仓库的实施分为以下几个步骤：

1.业务需求分析

业务需求分析是数据仓库建设的基础，应该同用户进行充分沟通，了解用户的真实需求，避免理解的误差，同时，应该界定好项目开发范围。

在此阶段，主要工作包括：

(1)设定可以达到的目标并明确所有需求

(2)确定系统体系结构

从实施的角度来看，设计数据仓库系统体系结构有多种方式：

构造部门级的数据集市DataMart

直接构造企业级的数据仓库DataWarehouse系统

先建立部门级数据集市，然后发展成企业级数据仓库系统

(3)确定数据源

列出向数据仓库提供数据的数据源清单。源数据的复杂性、规模、完整性对建立数据仓库的影响比其它因素要大。要格外注意哪些数据源的数据类型、粒度和内容是兼容的。

(4)容量规划

除了体系结构之外，硬件和软件资源对数据仓库也至关重要。作为需求定义的一部分，估计数据仓库将要存储的数据量以及将对数据进行的处理很重要。

(5)技术评价

在选择软件和硬件平台时，最好听取专家的建议，尤其是对与您相似的环境有经验的专家。InformixDecisionFrontier数据仓库实现套件，为用户提供了快速、集成、完整的数据仓库实现工具。

2.逻辑模型设计

逻辑模型设计主要是指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看，数据仓库的数据模型也许是整个项目最重要的方面。为数据仓库和数据集市定义数据模型是一项复杂的工作，需要领域专家的参与。

3.物理模型设计

在进行物理模型设计时，主要是将数据仓库的逻辑模型转换为在数据库中的物理表结构。在物理模型设计时，可以采用ERWin等辅助设计工具。

Informix采用ROLAP方式，数据仓库数据的存储主要采用InformixIDS(InformixDynamicServer)数据库，

InformixIDS数据库是业界领先的数据库引擎，它具有并发性、可伸缩性、多进程/多线索等特性，是Informix数据仓库应用的核心。

4.数据抽取、清洗、集成、装载等

数据抽取是数据仓库建立中的一个非常重要的步骤。它负责将分布在用户业务系统中的数据进行抽取、清洗、集成。

(1)定义数据载入和维护策略

(2)数据抽取/清洗/转换/装载

Informix提供了一系列工具访问存储在异构数据库中的业务系统数据。Informix还提供了数据复制产品，这样，系统会通过同步或异步方式自动将符合规则的数据定时进行传递，保证数据的完整性、一致性。

用户利用Informix的InfoMover可以轻松定义数据抽取、清洗、集成、装载过程，并可以对该过程进行定期调度，减轻数据增量装载的复杂度。同时，Informix数据装载策略支持第三方厂家丰富的工具，如Prism、Carleton、ETI等。

5.数据仓库的管理

数据仓库元数据的管理也是极为重要的环节。Informix的MetacubeWarehouseManager提供GUI，用户只须使用鼠标托拽方式即可对元数据进行管理。

6.数据的分析、报表、查询等数据的表现

用户分析、报表、查询工具是用户进行分析决策使用的工具。因此，其所有操作要非常简单，但提供的功能却要十分强大。Informix相应地提供了一套完善的工具。

此外，数据挖掘技术也是数据仓库系统中一个重要部分。Informix提供RedBrickDataMine以及第三方厂商产品，支持数据挖掘应用。

7.数据仓库性能优化及发布

数据仓库性能的好坏直接影响系统查询、分析响应速度。Informix提供MetaCube等工具支持汇总查询、抽样查询和后台查询，以提高数据仓库查询效率。

总之，Informix为用户数据仓库应用提供了一个快速、完整的解决方案。采用Informix数据仓库解决方案可以使您的数据仓库系统具有高性能、高可扩展性，高开放性，可以自己进行定制等特性，同时，Informix还提供专业数据仓库咨询服务，这将充分保证您的数据仓库系统建设快速、及时，保证它能真正发挥作用。

原文转自：www.ltesting.net

Informix数据仓库解决方案数据库 第2篇

大家都知道informix是需要日志的，但各日志都做什么用，各有什么意义等等，我们在下面做一个探讨：

首先需要说明的是informix的日志有两种：一种是物理日志，用来存放数据的前映象;另一种是逻辑日志，用来存放所有事物的操作过程。

在初始化的配置中，物理日志和逻辑日志的不是存放在根的磁盘空间的。默认的大小物理日志2M，逻辑日志6个，每个日志文件2M。但在实际的生产环境中，这两个参数一般是需要调整的。

从informix的本身的建议来说，要求逻辑日志的大小一般是要求一天的业务量，逻辑日志滚一圈，物理日志/逻辑日志=1/3。但是有的数据量很大的业务系统，这样做是不可能的，要做适当的调整。

物理日志文件的个数仅为1，逻辑日志文件的个数最小为3，最大为32767。关于物理日志和逻辑日志的改变，我们可以使用onparams命令来完成。

C:Informix>onparams--

Usage:onparams-a-d[-s][-i]|

-d-l[-y]|

-p-s[-d][-y]

-a-Addalogicallogfile

-i-Insertaftercurrentlog

-d-Dropalogicallogfile

-p-Changephysicallogsizeandlocation

-y-Automaticallyresponds“yes”toallprompts

上面是onparams的帮助文件，下面我们首先来改变物理日志的位置和大小：

C:Informix>onparams-p-s40000-dphydbs-y

Shuttingdown,pleasewait...

Initializing,pleasewait...

Recovering,pleasewait...

可以通过onstatCl中的phybegin来查看物理日志当前存在了哪个chunk上。Physize来查看当前物理日志文件大大小，单位是页。在这之前我们创建了phydbs，并指定了他大小。我们在-s后指定物理日志文件的大小，在-d后指定物理日志文件的位置。接着我们来做逻辑日志位置和大小的改变：

C:Informix>onparams-a-dlogdbs-s30000-i

Logicallogsuclearcase/“ target=”_blank“ >ccessfullyadded.

然后用onstatCl来查看新加的逻辑日志：

C:Informix>onstat-l

IBMInformixDynamicServerVersion9.40.TC2E1--Quiescent--Up00:08:10--25728Kbytes

PhysicalLogging

Bufferbufusedbufsizenumpagesnumwritspages/io

P-108871.14

phybeginphysizephyposphyused%used

3:53100001200.00

LogicalLogging

Bufferbufusedbufsizenumrecsnumpagesnumwritsrecs/pagespages/io

L-3083714142.61.0

SubsystemnumrecsLogSpaceused

OLDRSAM372628

addressnumberflagsuniqidbeginsizeused%used

0CB37CA81U-B----11:763500500100.00

0CB37CE82U-B----21:1263500500100.00

0CB37D283U-B----31:1763500500100.00

0CB37D684U-B----41:2263500500100.00

0CB37DA85U-B----51:276350028456.80

0CB37DE86U---C-L61:326350031563.00

0CED8B9812A------02:37553750000.00

0CED8B5811A------02:30053750000.00

0CED8B1810A------02:22553750000.00

0CED8AD89A------02:15053750000.00

0CED8A988A------02:7553750000.00

0CED8A587A------02:53750000.00

12active,12total

可以发现新加的逻辑日志状态都是A,先做0级备份ontapeCsCL0之后用onstatCl可以发现所有日志的flag位都变成了F状态，

然后用onmodeCl切换逻辑日志到新加的逻辑日志，用onmodeCc强制做检查点操作。最后用onparamsCdCllog_file_numCy来删除原来的逻辑日志文件。这样就完成了informix日志的迁移。

在onstatCl中，flag位表示了逻辑日志的状态，

A表示新加了还不能使用的日志

F表示空闲的可以使用的日志，一般是在0级备份之后才有这样的状态

U表示已经使用的逻辑日志

L表示当前的日志文件包含一个检查点

C表示正在使用当前的日志文件

B表示已经备份的日志文件

一般在新增或删除日志文件之后都要做0级备份。

在onconfig文件中，LOGFILES指定了IDS逻辑日志的个数，LOGSIZE指定了逻辑日志的大小，PHYSDBS指定了物理日志的位置，PHYSFILE指定了物理日志大小。LTAPEDEV指定了逻辑日志备份的位置，LTAPEBLK指定了每个block块的大小，LTAPESIZE指定了备份文件的大小。

下面我们讨论数据库的日志模式：

无日志

无缓冲日志

缓冲日志

ansi模式

我们可以通过ontape来改变日志的模式

采用无日志的方式时，所有的DML语句都不写日志，也就是说此时，数据库不支持事物。当数据库恢复系统备份的时候，无日志的数据库不能完全恢复。因为在备份中只记录了备份时的状态，备份后的数据库的变化必须从逻辑日志中恢复，所以这些改变是不可恢复的。

缓冲日志：所有的DML语句都写入logbuffer,当logbuffer写满的时候，就开始写入磁盘。这样就可以大大减少磁盘的I/O，从而提高数据库的性能。但是在系统发生问题恢复的时候，缓冲区内的数据将丢失。这些数据是不可能恢复的。

无缓冲日志模式：所有的DML语句在发生的时候是写到缓冲里的，但事物commit之后就立刻写回磁盘，这样在系统发生问题就保证了数据丢失的最少，但是增加了磁盘的I/O，所以数据库的性能会受到一定的影响。

Ansi模式：此模式和无缓冲日志模式具有相同的日志缓冲处理方法，但是此模式是不可逆的。

另外BLOB日志的处理也是十分特别的，他不需要物理日志，不写前映象。BLOB页是直接写磁盘的，不经过共享内存的处理。任何BLOB空闲映象的改变都将记录到逻辑日志中，所有的blobspaces数据刷新到硬盘上是随逻辑日志的的备份而写下去的。

Informix数据仓库解决方案数据库 第3篇

In formix数据库因其具有高性能、高可靠性、支持数据完整性定义和检查等特性而得到广泛应用。对于使用中的数据库, 数据备份的安全可靠性便成为人们关注的焦点。Informix一Online提供了几种有效的数据备份和恢复的方法, 在实践中如何应用这些方法, 以便最方便、最安全、最有效地备份和恢复数据, 需要数据库管理者根据系统的具体情况制订好计划, 在日常工作中执行。[1]

数据库备份策略在维护系统数据安全起着非同小可的作用, 好的备份策略应该考虑保证数据的安全, 并且操作较为方便。由于Informix多用于管理大型应用程序, 因此其数据的备份与恢复是数据库管理员的重要工作。[2]

2 Informix数据库备份的方案解析

Info rmix-Online数据库因其具有高性能、高可靠性、支持数据完整性定义和检查等特性而得到广泛应用。InformixOnline数据库常用的三种数据备份方式如下:

2.1 ontape工具

on tape工具具有如下功能:备份和恢复Online数据、备份和恢复逻辑日志、改变数据库日志状态等。在online处于联机或静止方式时, 根据备份方案安排进行0级、1级、2级备份。0级备份是对整个数据库的所有数据进行完整备份;1级备份是只对0级备份以后修改过的数据进行备份;2级备份只是对1级备份以后修改过的数据进行备份。ontape备份对online参数配置前后一致性要求较高, 如果需要将ontape备份的数据恢复到另一台服务器上时, 要求两台服务器机型、操作系统、Onconfig配置文件及非临时分配的Dbspace磁盘空间数量和大小必须一致, 否则数据不能正常恢复。备份采用交互方式进行。

2.2 dbexport命令

d b ex p o rt命令以ASCII码格式将数据写到文件或备份介质上 (如磁带) 。卸出的文件包括数据库模式文件和数据文件。它以独占方式 (exclusive mode) 占用数据库, 备份期间其他用户不能对数据库进行查询和修改及插入操作。用户可以使用d b e x p o r t/d b i m p o r t命令, 将I n f o r m i xonline和Informix-SE下的数据进行相互转换;也可以将数据在Informix-online的不同版本之间转换, 这种转换对数据库服务器的结构和online的配置没有特别要求;操作灵活。

2.3 Onunload命令

Onunload命令以页为单位, 使用二进制形式卸出数据, 备份效率比dbexport高。但它也有缺点:onunload/onload不能实现不同版本的online之间的数据转移;卸出和接受数据的计算机必须具有相同的磁盘页大小;onunload不保留初始表上定义的同义词。

2.4 Unload命令

该dbaccess下的命令可以倒出数据表包含的记录。需要对要备份的表进行逐一指定, 且不能同时备份表结构和索引信息。优点是备份出的文件容量小。

3 数据库备份方案的初步实施

目前对数据库批后备份每日进行, 首先根据配置文件倒出某些重要数据表的数据, 然后对数据库冗余数据进行清除 (库中至少保留7天的数据) , 再备份整个数据库 (dbexport) 和特定表数据文件到磁带设备中。具体实现过程如下:

由批量数据备份交易 (2603) 提示用户在主控台上运行/ap/c cb_b a nk/t oo ls/afterbak.sh文件, 该文件进行如下操作:

(1) 首先清理由交易产生的临时文件, 然后清理数据库备份目录/ap/dbback.af-t e r

(2) 接着调用/a p/c c b_b a n k/t o o l s/datacln清理数据库中的数据, 对应datacln命令的配置文件为datacln.cfg。可以在该配置文件中指定某些表数据在数据库中的保留期限, 以及是否要单独备份其数据。

Datacln根据配置文件备份某些表的数据, 生成重要数据文件, 放在/a p/db back up中, , 然后对数据库中的冗余数据进行清理。如果是提取日, 该命令还把重要数据文件拷贝到系统数据库备份目录/ap/dbback.after中 (该目录文件将被刻录到磁带中) 。

(3) 用d b e x p o r t倒出数据库到/a p/d b b ack u p.aft er目录, 并把该目录文件打包备份到磁带。

(4) 更新数据库索引。以上这种设计原则上要求平时轮流使用一组磁带进行每日备份, 每周一个循环, 每个磁带保留一周数据, 要求每周一个永久备份。根据/ap/c c b_b a n k/t o o l s/d a t a c l n.c f g文件中配置, 在重要数据文件的提取日, 这些重要文件将和每日数据库完全备份数据一起倒入到磁带中。

4 数据库备份方案的优化

(1) 扩充/a p文件系统到5 G, 以避免系统经常出现的文件系统空间不够的现象。 (SCO不必执行本步骤)

ch fs-a s iz e='22 34 777 6'/ap

(2) 在A P主机上, 另开辟文件系统/backup, 空间20G, 用于数据和日志的备份, 并建立两个目录/b a c ku p/d b和/b ac k u p/l o g, in fo r mix用户具有读写权限 (#chmod-R 777/backup) 。其中:

/b a c k u p/d b/中保留数据库备份

/b a c k u p/l o g/中保留日志备份

对于SCO, 只需创建/backup/db和/b a ck u p/lo g目录即可。

对于AIX, 如果DB和AP主机是分开的, 需要在DB主机上mount。

在AP上执行:

(1) mklv-y'lvbak'havg2 320

(2) crfs-v jfs-d'lvbak'-m'/

(4) 在DB上mount AP主机的/backup目录

(5) 宕数据库, 修改$ONCONFIG指定文件中的参数

(6) 每周依然用7盘磁带做当日的数据库和日志的备份。每月底要进行月度备份 (保留本月每天的ontape备份数据) 。每年底, 将每月的备份磁带刻到光盘上。

5 数据库备份方案的执行

(1) 实现第三项中指定的优化方案环境修改;并安装新备份方案的补丁盘。

(2) 在每天日终备份时, 首先在DB主机上用informix执行sh/ap/ccb_bank t o o l s/d b o n t a p e.s h, 该步骤将数据库用o n ta p e命令备份到/b a ck u p/d b目录下。

(3) 准备每天备份的磁带。

(4) 在A P主机上用r o o t执行s h/a p/c cb_b a n k/t o o ls/af t er b ak.sh, 该步骤首先清理/a p文件系统, 然后压缩/a p/c c b_b a n k/l o g到/b a c k u p/l o g目录中;再把/b a c k u p/l o g和步骤2中产生的/b ack u p/d b内容, 备份到轮换磁带中。最后清理数据库表中数据。如果在清理数据库表中数据时, 由于某些表数据太多无法清除, 则先用informix用户执行sh/ap/c c b_b a n k/to o l s/r ec r e a t e.s h, 然后重新用ro o t执行sh/ap/ccb_b an k/to o ls/afterb ak s h。

(5) 每月底, 准备好一个40G的磁带, 用r o o t执行s h/a p/c c b_b a n k/t o o l s/a l l b a k sh, 该步骤备份每天放到/b ack u p/d b和/b a ck u p/lo g中的数据。

6 数据库备份方案的简析

(1) 该方案在实施过程中得出的结论是:使用ontape方法, 进行数据库备份和恢复。这种方法不需要重起服务和数据库。 (2) 按照该方案进行初步实施优点是:现方案基本能满足数据库备份的要求, 而且操作简单。缺点是没有日志的备份;日终备份需要重起数据库和服务。 (3) 该方案在执行中应注意的问题是:如果数据库损坏, 必须有专人知道进行恢复, 并记录恢复的过程, 切不可自行恢复。

摘要：本文通过对Informix数据库备份实施过程进行分析, 介绍了Informix-Online提供的数据库备份方法、优化方法和执行方案, 并对该方案进行了简析。

关键词：Informix,数据库,备份

参考文献

[1]李毅之.综合业务网中Informix数据库的备份策略, 电脑与信息技术, 1998年05期.

数据仓库与数据挖掘技术 第4篇

Informix数据仓库解决方案数据库 第5篇

一、磁盘数据组织结构

在INFORMIX-OnLine的磁盘数据组织结构中的最上层为逻辑概念上的数据库空间dbspace,每一个数据库空间都有一个或若干个物理单位数据存储块chunk组成，镜像数据存储块mirror保证当根数据存储块故障时，OnLine能够继续工作。每一个数据存储块都有若干个数据页page组成，为了提高输入和输出效率，若干个连续的数据页组成数据连续页extent。用户的数据库database和数据表table存储在缺省的或者指定的数据库空间中，数据表的逻辑概念上的存储空间数据表空间tblspace有一个或若个安数据连续页extent组成，数据记录row存放在数据页page中。

为更好的的支持多媒体应用，多媒体数据可以存放在二进制大对象数据页Blobpage中，若干个二进制大对象数据页在此二进制大对象空间Blobspace。 OnLine使用逻辑日志Logicallog、物理日志Physicallog来管理数据库日志操作。

1.数据存储块chunk

INFORMIX-OnLine的数据存放在物理上连续的数据存储块chunk中，数据存储块是OnLine数据存储的最大的物理单位。数据存储块可以有两种构造方法，其一是直接构造在系统的物理磁盘上，其二是构造在操作系统的文件或者卷上。

在第一种情况下，在操作系统上仅仅定义了这个(块)磁盘但没有格式化这个(块)磁盘，因此在这上面的所有数据操作都有OnLine来完成，操作系统对它不存在任何管理，数据空间在物理磁盘上连续，这种数据的存储空间称为原始空间rawspace。

而在第二种情况下，操作系统不仅定义了这个数据存储空间(文件)，还管理这个数据存储空间(文件)，数据文件操作时的内存缓冲、输入与输出。数据空间的建立受操作系统的制约，在物理存储上不连续。我们称这种数据存储空间为非原始空间cookedspace。

比较这两种数据的存储空间，原始空间在磁盘上连续，没有操作系统的缓存和制约，非原始空间在磁盘上不连续，存在着操作系统的缓存和操作系统的输入/输出的制约，因此在实际应用中，采用原始空间效率高于非原始空间，由于原始空间与系统设备有关，同时不同操作系统对设备的定义的不一致性，定义非原始空间比定义原始空间来得简单。我们将原始空间所对应的磁盘称原始设备rawdevice，而将非原始空间所对应的操作系统文件称操作系统文件cookedfile。

为了进一步提高数据库运行的效率，我们通常选用字符设备作为存放实际的原始设备，这样在我们输入/输出数据时，可以充分发挥系统的DMA能力。当我们使用原始设备时，可以在同一个原始设备上建立多个数据存储块。通过对数据存储块的参数OFFSET和SIZE的定义，其单位为KB，我们可以定义多个数据存储块在同一个磁盘或磁盘块上，参数OFFSET定义数据存储块的起始位置，参数SIZE定义数据存储块的大小，用户在设置参数OFFSET和SIZE时必须保证在物理磁盘上没有相互覆盖。

在原始设备/dev/rdsk/c0t1d1s0上建立三个数据存储块chunk1、chunk2和chunk3，它们的大小分别为50MB、30MB和50MB，由于chunk的SIZE单位为KB，因此chunk1、chunk2和chunk3的SIZE分别为50000、30000和50000。在通常情况下,第一个数据存储块chunk1的OFFSET为0，这样第二个数据存储块chunk2的OFFSET应为第一个数据存储块chunk1的SIZE，而第三个数据存储块chunk3的OFFSET则为第二个数据存储块chunk2的OFFSET加上第二个数据存储块chunk2的SIZE。为保证在两个数据存储块的相邻边界处不发生重叠，可以将后一个数据存储块的起始位置稍微挪后一点。如果采用操作系统文件作为数据存储空间时，一般不在一个文件中建立多个数据存储块。一个文件中建立多个数据存储块，操作系统对文件中数据的定位时间将更长。

不管是原始设备还是非原始设备，OnLine的概念是一致的。在实际应用中，可以一部分数据存储块用原始设备而另一部分用非原始设备，只是原始设备采用OnLine的管理的I/O机制，而非原始设备采用操作系统unix的I/O机制。

2.数据页page

INFORMIX-OnLine在数据存储块中以数据页page为单位来组织存放数据，并以数据页为单位来输入输出数据，它的大小与数据在共享内存中数据缓冲区相一致，所以OnLine的数据页的大小是不可以改变的。数据页是OnLine组织存放数据的最小的物理单位。

根据不同从操作系统，OnLine的数据页的大小是不同的。例如在SCO、AT&T、UNISYS和HP等操作系统平台上，每一个数据页的大小为2KB，而在IBM和SEQUENT等操作系统平台上，每一个数据页的大小则为4KB。同时数据在共享内存中的缓冲区的大小也是根据操作系统的不同而不同，其值与数据页的大小一致。

3.数据连续页extent

为提高数据操作的效率，OnLine将若干个在物理磁盘上连续的数据页组成一个数据连续页extent。当用户创建一个数据表时，OnLine以数据连续页为单位在数据存储块中分配一块连续的空间，当用户的数据写满了这个数据连续页后，OnLine将以数据连续页为单位在数据存储块中申请一块连续空间，以存放更多的用户数据。在缺省情况下，初始化时第一个数据连续页为8个数据页。

数据连续页不能跨越数据存储块，当OnLine需要申请较多的数据页构成数据连续页时，如果OnLine找不到如数的在物理设备上连续的数据页时，OnLine将放弃这些不够构成一个数据连续页的数据页，OnLine将去下一个数据存储块去申请如数的在物理设备上连续的数据页。因此在实际系统中，过小的数据存储块将不利于数据操作性能和数据存取效率。

4.数据库空间dbspace

在INFORMIX-OnLine的磁盘数据组织中，数据库空间dbspace处于一个比较上层的位置。数据库空间是数据库在逻辑概念上的存储空间，一个或若干个数据库空间组成OnLine数据实体。在物理磁盘上，每一个数据库空间总对应于一个或几个数据存储块，在这些与数据库空间对应的数据存储块中，一定有一个数据存储块是根数据存储块，而其它的则是后继数据存储块。从功能上来看，根数据存储块除了具有后继数据存储块能够存储用户数据外，它还具有管理本数据库空间的功能;从数据存储块的保留页来看，根数据存储块具有56个保留页，而后继数据存储块仅有3个保留页。当然不同版本的OnLine在主、后继数据存储块的保留页的数量可能不同，但是根数据存储块需要更多的保留页来保存本数据库空间的定义。

在OnLine初始化后有一个称为根数据库空间rootdbs的数据库空间，它是OnLine系统的第一个数据库空间。当建立根数据库空间时，它的根数据存储块将被建立，所有数据库的日志和所有的定义信息都必须存放在该数据存储块中，它比所有其它根数据存储块的保留页更多。由于数据库日志定义的需要，因此对根数据库空间的根数据存储块的定义尤其重要，关于如何正确地定义根数据库空间的根数据存储块将在后面详细介绍，

为了提高数据库系统运行的效率，INFORMIX新的动态服务器OnLineDynamicServer7.1中引入了临时数据库空间的概念。在没有临时数据库空间的系统中，临时数据将建立的缺省的根数据库空间中，由于临时数据操作需要频繁的增加、删除，会给根数据库空间的数据存储块中造成很多碎片，将导致数据库操作效率的降低;另外当数据库备份时，那些临时数据也一起作备份，从而增加了数据备份量，降低了数据备份的效率。引入临时数据库空间后，用户的临时数据或者数据操作的中间结果将被存放在临时数据库空间中，同时当数据备份时临时数据库空间将不再被备份。

5.数据存储块镜像mirror

为提高OnLine运行时的数据高可靠性，OnLine在数据存储上引入了数据存储块镜像的机制。OnLine数据存储的镜像是对数据存储块而言的，但是其定义是对数据库空间的。当一个数据库空间被定义为镜像时，它下面的所有数据存储块全部镜像;当一个数据库空间被定义成没有镜像的时候，它下面的所有数据存储块全部没有镜像。

当OnLine在运行时，一旦数据存储块所在的物理磁盘发生读写故障，对于没有数据库空间没有镜像的系统，OnLine将自动关闭，并等待恢复。而对于具有镜像的数据库空间，OnLine将把存在读写故障的数据存储块标识为Down，同时OnLine将继续运行，用户完全可以根据需要，在适当的时候，恢复存在读写故障的数据存储块所在的磁盘，然后重构继续。因此一个具有镜像的数据库空间，其运行时的可靠性将大大高于不具有镜像的数据库空间。

6.数据表空间tblspace

在逻辑上，数据库存放在数据库空间dbspace中，数据表存放在数据表空间tblspace中。数据库空间是由数据存储块组成，数据表存在于这些数据存储块中，数据表空间是由连续存放该数据表记录的数据连续页组成。

二、共享内存数据组织结构

OnLine能高效地执行联机事务处理的第二个机制是数据库服务器系统的共享内存。在一些不使用共享内存的数据管理系统中，管理进程只能在需要数据的时候，将该记录和索引的最新值读入该进程所占有的私用数据缓存中进行操作，由于频繁的磁盘I/O，使系统的运行效率降低，同时由于那些管理进程都各占一份数据缓存，使得系统内存的有效使用率降低。因此使用共享内存会有以下三方面的好处：

(1)数据缓存不再属于某个进程，所有的数据库进程均共享这块内存，降低了磁盘的I/O;

(2)所有数据库进程访问相同的访问，它们的值和索引在内存中只有一份拷贝，提高了内存的有效使用率;

(3)操作的相关记录被预读进共享内存中，由于内存的I/O效率极高，因而系统并发除了数据的能力得到提高。

随着OnLine功能和性能的不断提高，OnLine的共享内存也有所不同。尤其是INFORMIX的动态服务器OnLineDynamicServer(ODS)在其共享内存的结构上增加了两个功能模块。在OnLine5中，其共享内存仅有一个区域，驻留区Residentportion;动态服务器ODS7.1除了驻留区Residentportion外还增加了虚拟区Virtualportion和通讯区Communicationportion。

1、操作系统参数对数据库服务器共享内存的影响

操作系统的共享内存参数对数据库服务器的共享内存的定义和建立会产生极大的影响。对INFORMIX来说，数据库服务器的共享内存绝对不能超过操作系统共享内存定义的允许范围。一个OnLine动态服务器7.1的共享内存不能超过操作系统所定义的一个UNIX进程所允许访问共享内存的极大值，由于操作系统对共享内存的定义往往不能满足OnLine动态服务器7.1的需要，因此，数据库管理员通常需要在建立其数据库应用系统以前，首先调谐操作系统的共享内存参数。

对于OnLine动态服务器7.1来说，操作系统的参数对它们的影响，在共享内存锁资源管理方面和虚拟处理器对共享内存访问操作方面是不全部相同的。它们对操作系统参数的要求也是不一样的，因此需要数据库管理员根据产品来决定操作系统的参数，在决定这些操作系统的参数前，请先阅读产品说明文件。例如OnLine动态服务器7.1的$INFORMIXDIR/release/ONLINE_7.1，在这个文件中它向数据库管理员阐述该INFORMIX产品在该机器平台上对操作系统参数的要求。同一种产品在不同的平台上，对该平台操作系统参数的要求非常有可能是不一样的;在同一平台上，同一产品的不同版本对操作系统参数也很有可能是不同的。

2、处理器资源组织结构

OnLine动态服务器7.1采用多进程Multi-processes多线索Multi-treads的数据库服务器机制，将每一个服务器进程根据用户定义分解成若干个线索，每一个线索响应一个用户的设计访问的请求。INFORMIX将每一个进程称作一个虚拟处理器Virtualprocess。

在以前的多处理器系统中，往往将用户的应用程序和系统的处理器CPU对应起来，每一个处理器都分别处理一个用户的应用程序;当应用程序数量多于处理器数目时，应用程序为争夺处理器资源CPU，而引起应用程序在运行时间上的不平衡;同时当应用程序的数量少于处理器数目时，由于一些处理器资源得不到运用而空闲，导致处理器资源运用上的不平衡。一种比较好的方法是将处理器与应用所需要的处理器分离开来，然后由数据库系统来平衡这种需求。在INFORMIX动态服务器中，用户应用程序发出的数据操作请求被称作虚拟处理器的服务器进程所接收，然后OnLine均匀地将这些服务器进程分配到系统实际的处理器CPU上。这样就较好地解决了上面所提到的两种不平衡状态。

在ODS7.1中每一个数据库服务器进程都称作一个虚拟处理器Virtualprocess，简称VP。若干个相同功能的虚拟处理器组成一个虚拟处理器类VirtualprocessClass，简称VPClass，每一个VPClass都表示一种功能的虚拟处理器。OnLine一共有七种虚拟处理器，它们是：

处理器虚拟处理器CPUVP，响应所有用户和OnLine系统对CPU资源的操作和协调。

磁盘输入输出虚拟处理器DiskI/OVP，响应用户和OnLine系统的磁盘输入输出请求，磁盘输入输出处理器分三种，异步输入输出AsynchronousI/O、物理日志输入输出Physical-logI/O和逻辑日志输入输出Logical-logI/O。

网络通讯虚拟处理器NetworkVP，响应用户的网络联接的请求。ODS的网络虚拟处理器有三种，它们分别用于管理tli、soc和ipc三种网络通讯接口。

系统管理虚拟处理器AdminstrationVP，运行OnLine系统管理程序和一些专职程序。

光盘虚拟处理器OpticalVP，当用户运行OnLine/Optical时管理光盘系统的运转。

审计虚拟处理器AuditVP，当用户系统需要一定的运行时数据安全性的时候，审计虚拟处理器在后台帮助检查每一个用户操作的合法性。

杂项管理虚拟处理器MiscellaneousVP，用于管理所有以上虚拟处理器不作的工作。

共5页: 1 [2] [3] [4] [5] 下一页

Informix数据仓库解决方案数据库 第6篇

监控ONLINE系统后动情况的工具主要有以下三类： 系统监控接口（SMI）、tbstat和tbcheck。

一、系统监控接口（SMI）

我们主要通过SQL命令操作online的内部数据库sysmaster中的内部表/结构，来获取有关的维护信息。Sysmaster是在online初次初始化时，系统自动创建的。它实际主要存储了一些数据结构，而不是真正的表。使用SMI有如下限制：

 不能对SMI中的表加锁或使用隔离级别。

 不允许使用insert，delete，update等语句（只读）

 不能使用dbschema，dbexport等命令

 使用select rowid语句将会产生不可预料的结果

主要的SMI表有：

sysdatabases：online中的数据库信息

systabnames：某数据库中所有表的信息

syslogs：逻辑日志信息

sysdbspaces：数据库信息

syschunks，syslocks等

例1：显示处于脱机（offline）状态的chunk的序号和所在数据库空间

Select chknum，dbsnum from syschunks where is_offline=1 or misline=!

例二：显示满chunk的信息

Select chknum，dbsnum from syschunks where nfree=0

二、TBSTAT

 列出当前时刻的信息（实际也是读取SMI表）

 不需要磁盘I/O

 不需要锁等系统资源，因此不会影响系统性能

用法： tbstat [-abcdklmpstuzBDFPRX] [-r seconds] [-o file] [infile]

-a print all info (options: bcdklmpstu)

-b print buffers（缓冲区）

-c print configuration file（配置文件）

-d print dbspaces and chunks（dbspace和chunk）

-k print locks（锁）

-l print logging（日志）

-m print message log（消息日志）

-p print profile（profile文件）

-s print latches（门闸）

-t print tblspaces（表空间）

-u print users（用户）

-z zero profile counts

-B print all buffers

-D print dbspaces and detailed chunk stats

-F print page flushers（页刷新进程）

-P print profile, including BIGreads

-R printLRU queues（LRU队列）

-X print entire list of sharers and waiters for buffers

-r repeat options every n seconds (default: 5)

-o put shared memory into specified file (default: tbstat.out)

infile use infile to obtain shared memory information

三、几个常用的tbstat选项

tbstat -m ：显示消息日志的最后20行. 消息日志的内容包括：

1）、检查点信息

2）、读写错误信息

3）、ONLINE模式转换信息

4）、长事务

5）、日志文件满(LOG FILE FULL )

若想显示完整信息,可直接编译消息日志文件.

Tbstat -d：磁盘空间的使用情况，包括DBSPACE和CHUNK的信息

例：RSAM Version 5.03.UC1 -- On-Line -- Up 09:45:41 -- 816 Kbytes

Dbspaces

address number flagsfchunk nchunks flags ownername

8040a244 1111 N informix rootdbs

1 active, 8 total

Chunks

address chk/dbs offset size free bpages flags pathname

80409d84 1 1 0 300000 231871PO- /dev/rdata

1 active, 8 total

其中的FREE项，显示了该CHUNK的空闲空间大小(Kbytes).

 Tbstat -l ：日志文件情况

Physical Logging

Buffer bufused bufsize numpages numwrits pages/io

P-2 016 000.00

phybegin physize phypos phyused %used

101782 15000960 00.00

Logical Logging

Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io

L-2 016 1111.01.0

address number flagsuniqid beginsize used%used

8042de94 1U---C-L 110521a 7500 630 8.40

8042deb0 2F------ 0106f66 75000 0.00

8042declearcase/“ target=”_blank" >cc3F------ 0108cb2 75000 0.00

8042dee8 4F------ 010a9fe 75000 0.00

8042df04 5F------ 010c74a 75000 0.00

8042df20 6F------ 010e496 75000 0.00

其中：%USED： 使用百分比

FLAGS字段的含义:

F: 空闲 B:已备份 C: 正在接收事物记录

U: 正在使用 A: 新增日志 L: 包含最后一个检查点

 Tbstat - u：ONLINE的用户情况

Users

address flags pid user tty waittout locks nreads nwrites

804019f4 ------D 329 root console 0 00 179 2

80401a64 ------D 0 root console 0 00 00

80401ad4 ------F 330 root 0 00 00

3 active, 20 total

Transactions

address flags user locks log begin isolation retrys coordinator

804022b4 A---- 804019f4 0 0 NOTRANS 0

804028d8 A---- 80401a64 0 0 NOTRANS 0

2 active, 20 total

其中：flages字段的含义:

第一列：（S：等待mutex；Y：等待条件；L：等待锁；B：等待缓冲区；

C：等待检查点；X：长事务清理；G：等待长缓冲写；T：等待事务）

第二列：（*：事务执行时，发生I/O错误）

第三列：（A：正在备份；B：操作已被记录在日志中；P：分布处理已准备好；

C：正在提交；R：正在回滚）

第四列：（P：会话的主线索）

第五列：（R：在read rsam 调用中；X：进程在关键分区）

第七列：（M：特殊监控；D：特殊线索；C：清理线索；F：特殊清页进程；

B：特殊B+树清页线索）

Tbstat -k ：用户持有锁的情况

锁按照粒度分为6种: 库锁、表锁、页锁、行锁、字节锁、键锁

字节锁：更新包含有VARCHAR类型的行时，加在该行上的锁，

键锁：用于索引树上的锁。一般在相应字节上加删除标志。

这几种锁的识别如下：

TYPETBLSNUM ROWID SIZE

库锁 HDR+X 1000002 205 0

表锁 100000e 00

页锁 100 0

行锁 101

字节锁HDR+B 909

键锁 很大的16进制数

锁的生命期：1、不使用事务时，操作完成即会释放对应的锁；

共2页: 1 [2] 下一页