informix数据库手册.docx
《informix数据库手册.docx》由会员分享，可在线阅读，更多相关《informix数据库手册.docx（99页珍藏版）》请在冰豆网上搜索。
informix数据库手册
Informix数据库手册
上海欣方智能系统有限公司
版权声明
本书版权属欣方智能系统有限公司。
任何单位或个人未经本公司书面许可，不得将本书的部分或全部内容进行任何形式的节录、增删、印刷、复制、翻译，或以任何形式进行传播。
版权所有，XX。
ThecopyrightofthisbookbelongstoCINtelIntelligentNetworkCo.,Ltd.Nopartofthisbookmaybeextracted,added,deleted,pressed,copied,translatedortransmitedinanyformorbyanymeans,withoutexpresswrittenpermissionfromCINtelIntelligentNetworkSystemCo.Ltd.
Copyright©byCINtelIntelligentNetworkSystemCo.,Ltd.
1．基础知识和概念
1.1Informix动态服务器的基本术语
1.1.1chunk
在online系统中并不使用UNIX的文件系统管理磁盘空间，而是有它自己的一套机制，称之为“原始顺序访问方法”（RSAM）。
对数据库管理而言，RASM比UNIX文件系统效果更好。
在这套机制中，用以指定给online系统的有效物理磁盘空间单元被称做chunk。
一个chunk是一片连续的空间单元，online数据最终存放于此，因此chunk是online的物理存储实体，online系统所做的空间管理工作都是在chunk中进行的。
一个典型的chunk可能是UNIX的一个原始设备（rawdevice），也可能是一个UNIX文件。
1.1.2dbspace数据库空间
dbspace是一个逻辑上的概念，一个dbspace是若干chunk的集合，每个bspace至少有一个chunk，最先指定给他的chunk称为基本chunk。
若有必要可以给一个dbspace指定多个chunk。
若某一个dbspace的空间耗尽了（即所有指定给他的chunk都满了），您可另外再指定chunk给他。
数据库和表可以建立在特定的dbspace上，这也就决定了数据库和表最大只能增长到他所在的dbspace空间那么大。
你不能决定你所建的库和表究竟处于该dbspace上的哪个chunk上，但你可以把库和表创建在一个指定的物理设备上（先把位于某个设备上的chunk指定给一个dbspace，然后再把库和表建立在该dbspace上）。
每个online系统至少有一个dbspace（根dbspace，rootdbspace），所有控制online系统的系统信息都被置于其上。
1.1.3page数据页
当指定给online系统一个chunk后，该chunk就会被划分为一些更小的称为页（page）的单位。
页是online系统的基本I/O单位，所有存储在online系统中的数据实际都存储在页上。
例如，如果你想为一个数据库表存储一行，该行的内容就会存储在一个页中；如果您想从数据库中读取一行，存储该行内容的整个页都会被读取到共享内存的缓冲区中。
当某个特定的机器/操作系统确定后，online系统的页大小也就确定了。
最常用的页大小为2K，也有的系统使用4K的页。
Online系统中页的大小是不可改变的。
1.1.4tblspace
一个tblspace是只分配给一个特定表的所有页的集合（一个tblspace是一个数据库表的所有数据页的集合，因此一个tblspace=一张表）。
一个tblspace必须处在唯一的dbspace上。
1.1.5extent
为表分配磁盘空间是以extent为单元进行的。
一个extent就是在创建表时确定好的连续的磁盘空间大小（固定的几个属性所占据的空间的大小）。
每个表都涉及两个extent大小：
extentsize为表初次分配的extent大小，在创建表后就分配了；nextextent依次追加到该表上的extent大小。
注：
一个dbspace可看作物理chunk的一个逻辑组，这些chunk可能分布在不同的磁盘上，尽管他们都来自同一个dbspace；一个tblspace可看作extent的一个逻辑组，来自同一个tblspace的extent可能分布在不同的chunk上。
1.1.6物理日志
物理日志保存数据被修改前的映象。
主要用于fastrecovery和backup。
1.1.7逻辑日志
逻辑日志保存数据在修改后的映象，保存数据库从上一次备份后的操作记录。
比较有用。
1.2常用的数据库概念基础
1.2.1数据库（Database）
CreateDatabaseDatabaseName[InDbspace][With{[Bufferd]Log|LogModAnsi}]当不指定数据空间时，数据字典系统表建立在Root数据空间（RootDBSpace）上，并且在这个库上建其它表时，数据字典所在的表空间为缺省表空间，而建立临时表时，缺省数据空间为环境变量DBSPACETEMP，但使用Fragment语句可以使表空间分布在多个数据空间上。
我们可以使用Ontape–s[-B|-A|-U|-N]DatabaseList改变数据库的日志状态。
Oninit–p初始化时将不操作临时表空间。
*注意在HDR系统里改变数据库的日志状态后，需要从新做主从机。
1.2.2数据表（Table）
Create{TableTableName（ColumnDefinition[ConstraintDefinition]）|
tmpTableClause}[WithRowIds][StorageOption][LockOption]
使用适时变量行锁可以提高事务的并行性，甚至可以申请多于设置的最大锁数，但锁的开销将很大。
对于需要成块操作的聚族索引表，设置成行锁是一个极好的方案。
它不仅可以减少锁的开销，而且大大提高数据的访问速度。
1.2.3索引（Index）
Create[Unique|Distinct][Cluster]IndexIndexNameOn{TableName|Synonym}
（ColumnNameListWithAscOrDesc）FillFactorpercent[InDBSpace|FragmentClause]
当在一个表上某列已建立UniqueConstraint时，便已在该表上建立对应该列的UniqueAscIndex，所以再次在该列上建立Asc索引将失败。
我们可以在一个表上建立对应某些列的多个索引，单要求某列的索引顺序只有一种。
Cluster指定索引的聚族属性，具有聚族索引属性表的物理存储顺序将重新安排与其索引一致。
它将加速表的查询与修改，但对表的插入和删除将需要更大的开销。
并且索引的聚族属性对应单位为DBSpace，而非整个表。
一个表最多只能有一个聚族索引，但AlterIndexIndexNameTo[Not]Cluster语句可以将聚族属性移到另外一个索引上。
FillFactor的缺省值为90，它确定了索引数据结构（B+树，Hash桶）的紧凑程度，低紧凑度的索引将使数据的插入操作变的非常的快。
而高紧凑度的索引将使数据的查询性能大大提高。
但需要注意的是，装填因子只有在表的记录数超过5,000条并且占用空间超过100页时才发生效用，再分段表上建立索引或建立分段索引时，FillFactor的缺省值也可以设置在Onconfig配置文件的FILLFACTOR上。
当不指定DBSpace时，其存储位置与表的数据空间安排方案一致，Fragment也可以重新安排表的存储数据空间。
1.2.4视图（View）
CreateViewName（ColumnName）AsSelectClause[WithCheckOption]
在查询子句中，OrderBy,IntoTemp,Union操作是不容许的，并且不能使用列显示标志，它们为相应表的列名。
WithCheckOption子句是我们不能通过视图对相应表不可视的记录进行访问，也不能插入不符合视图定义的记录。
建立视图主要基于以下三个原因：
1.防止机密数据泄密保护数据安全。
2.建立有效的查询,简化数据查询方式。
3.名称变化而需保证程序不会随着数据的位置变化,保持数据的独立性。
1.2.5查询（Query）
Select[All|Unique|Distinct]{ExpressionAsShowLabel|ColumnName,…}
FromClause[WhereClause][HavingClause][GroupByClause][OrderByClause]
[IntoTempTableName[WithNoLog]][Union[All]SelectClause]
Union操作要求每个查询中的查询项目数相同，并且对应项目的数据类型相兼容。
如果没有All属性，相同的记录将合并为一个。
外（Outer）查询保证即使第二个表或视图中没有符合条件的记录，它也能以空值与第一个表中相应的记录结合生成一条查询结果。
在WhereClause中，数据库系统先扫描前面的表，再扫描后面的表，所以一般将数据量较少的表或视图放在前面，因为这样设计可以减少时间和内存开销（SetExplainOn跟踪报告）。
1.2.6存储过程（Procedure）
Create[dba]ProcedureProcedureName（ParameterList）[ReturningClause]
[OnExceptionProcess][MainStatementBlock]EndProcedure;
带有dba属性时，存储过程对象便具有dba（DatabaseAmphitryon）（dba_privilege）属性，否则，它为主人特权（owner_privilege）属性。
OnExceptionProcess处理意外事件。
ReturnVariableList[WithResume]将结果返回，WithResume标识使存储过程返回后再次跳到返回点执行后面的语句，所以Informix存储过程有返回多行结果的特性，它可以作为数据窗口的数据源，在各种数据库开发工具中，我们可以使用游标来取得它的多行返回结果。
Informix的存储过程中在定义变量时没有进行初始化工作，后面的语句如果访问未初始化的变量会发生例外错，如不对它进行处理，执行便会终止返回。
变量的类型会最可能地根据使用的方式不同而自动转换，转换失败同样回触发意外错。
SetDebugeFileTopathname可以设置存储过程执行中的踪迹文件，利用它可调试存储过程，但已调试好的存储过程应将跟踪语句去掉，因为它会大大增加执行时的开销，TraceOn打开跟踪，Traceoff关闭跟踪。
存储过程定义举例1：
createdbaProceduresel_stu（）
ReturningVarchar（20）;
Definetmp_nameVarchar（20）;
SetDebugFileTo"/opt/informix/sel_stu.trace";
TraceOn;
Lettmp_name="";
Foreachsel_stuForselectnameIntotmp_name
Fromstudent
Returntmp_nameWithResume;
EndForeach;
Return"mamamama";
Return"babababa";
Traceoff;
EndProcedure
1.2.7触发器（Tigger）
CreateTriggerTriggerName[Operation]On[TableName]{ActionClause|[ReferencingClause][ActionClauseReferencing]}ActionClause
触发器可用于保证数据的逻辑一致性，使程序员在每一次对数据进行修改操作（Update,Insert,Delete）时，能截取相应的操作参数，并可执行相应的处理，大大简化数据库程序设计的难度。
值得注意的是，再对触发器的处理中，不应再执行触发触发器自身的操作，这用会造成死循环，其次触发器中要特别谨慎执行引起事务提交的动作，这样易造成事务的不完整性。
在触发器或触发的存储过程中，我们可以访问这次会话所定义的全局变量，这样一次会话中各执行单元的联系变得非常容易。
1.2.8事务Transaction
这种约束条件就是一致性约束。
数据库中存在的信息是对客观世界的反映，这就要求数据库系统中所用的运算都应保持数据的逻辑完整性，既要求数据库的任何状态变化都要能反映客观世界的某种真实存在的合理状态。
客观世界要保持合理状态的存在，总是有一定规则的，这种客观的规则反映到数据库中就是数据库中的数据要满足一定的约束条件。
我们不要求在每一个简单的修改后就去验证一致性约束，这就是事务。
因此说它将数据库从一致性状态转化成新的一每个事务结束时系统都要检查一致性。
例如银行中，有笔钱款要从甲账号转到乙账号下那么发生的动作就是这一加一减操作是密不可分的。
同时事务具有以下特点：
原子性：
一个事物或者成功的结束或者对数据库不产生任何影响。
一致性：
满足一切完整性约束，一个成功的事物保持数据库的数据完整性。
隔离性：
事物内部的操作及使用的数据对并发的其他事务是隔离的，其他事务访问到的数据还是该事务发生前的状态。
单个事物未完成之前，永久性随后的任何故障及错误操作都不会改变其结果。
1.2.9数据的完整性控制
数据的完整性是指数据的正确性有效性与相容性保证数据库中的数据在输入修改过程中始终符合原来的定义。
例如：
职工性别是男或女，职工年龄是大于0小于70的职工，所在的部门号必须是在的有效的部门号等。
1.2.10并发控制
修改数据库时可能会发生互相干扰，而使得当多个用户的并发进程同时存取数据库，并使数据库的完整性遭到破坏，因此必须对多用户的并发性，导致错误的结果协调加以控制。
2．数据库的安装与配置
2.1单机数据库的安装
2.1.1简介
INFORMIX的数据库服务器（DatabaseServer）产品目前分为三个系列，从产品的版本号上可以把他们区分开来。
版本7.x是传统的单机数据库系列，称为动态服务器IDS（Informix-OnLineDynamicServer），它采用了INFORMIX独有的动态可伸缩体系结构DSA（DynamicScalableArchitecture），适用于单机系统，包括SMP结构的机器。
版本8.x是并行数据库系列，称为扩展并行服务器XPS（ExtendedParallelServer），适用于Cluster和MPP体系结构的机群系统。
版本9.x是对象关系数据库（ORDBMS）系列，称为通用服务器（InformixUniversalServer），主要用于比较新的数据库应用领域，如web应用以及一些数据类型及其操作都比较复杂的应用。
我们的智能网产品中使用了7.x版的INFORMIX-OnLineDatabaseServer（以下简称OnLine）和INFORMIXEMBEDDEDSQLforC（以下简称ESQL/C）两种产品。
Informix的每个产品都有详尽的针对具体机型的安装手册，为了保证安装过程的顺利进行，同时还要求安装人员有一定的UNIX系统管理经验。
这些都要花费比较长的时间才能掌握。
为了使一般的工程技术人员也可以进行INFORMIX产品的安装，下面对INFORMIX的基本安装和配置过程进行了简单介绍。
因为UNIX系统的复杂性和不同机型之间的差异，如果遇到不能解决的特殊情况，请及时与INFORMIX和UNIX的技术人员联系。
2.1.2准备Informix所需的硬盘空间
在正式开始安装之前，首先要对Informix所需的硬盘空间的大小和位置进行规划。
Informix所需的硬盘空间包括两部分：
软件所需的空间和数据所需的空间。
7.2x版的OnLine和ESQL/C软件安装后大约占50MB左右的硬盘空间。
数据所需的空间的大小和位置是由用户应用需求和硬件配置来决定的，下面主要讨论怎样规划初始的数据空间。
在一些简单的DBServer产品（包括InformixSE）中，往往借助于操作系统中的树型文件系统来管理数据库的存储空间。
具体做法是，为每个database在文件系统中创建一个目录，该database中的每个table作为该目录下的一个文件，Server只负责table文件内部的管理，table文件和该文件系统下的其它文件共享存储空间。
这样只要在创建database时指定了它的目录名，以后存储空间的管理都由文件系统来完成。
这种做法实现起来比较简单，但是效率比较低，灵活性和可靠性也差。
OnLine不借助文件系统，而是自己来管理database内部的存储结构。
OnLine的数据存储空间的组织采用两级结构。
首先整个数据存储空间分成多个dbspace。
然后，每个dbspace又由多个chunk组成。
每个chunk是一个UNIX的普通文件或块设备，其大小在创建时就确定了，以后不能改变。
每个dbspace创建时至少要包含一个chunk，以后可以根据需要随时增加chunk，但是不能删除已有的非空chunk。
每个OnLine实例（Instance）至少要有一个rootdbspace。
数据库管理员（DBA）和数据库（database）和表（table）的创建者可以指定自己的数据存放在那个dbspace上，但是不能控制具体是存放在该dbspace的那个chunk上，这是由OnLine来决定的。
Dbspace和chunk之间的关系类似于大多数UNIX系统中的逻辑卷（Volume）和物理分区（Sub-disk）之间的关系，往dbspace上增加chunk类似于卷的动态扩容。
数据空间的规划包括两部分工作：
1．确定需要创建几个dbspace以及每个dbspace的用途。
2．确定每个dbspace的初始空间大小和位置，据此创建chunk。
这两部分工作是相互关联的。
数据空间的规划主要有以下作用：
1．提高关键数据的可靠性。
rootdbspace、日志文件和其他关键数据所在的chunk可以建在采用RAID技术进行容错的磁盘阵列上或进行软件镜像。
2．提高I/O性能。
在有多个硬盘和控制器的情况下，尽量将I/O操作均衡地分布到各个硬盘上。
在多个硬盘的性能有差异的情况下，将最频繁存取的数据放在性能最高的硬盘和分区上。
3．方便备份和恢复工作。
因为备份和恢复都是以dbspace为最小单位的。
因此将不同用途的数据放到不同的dbspace上可以减轻备份和恢复的工作量。
一般说来，至少要创建4个dbspace，分工如下：
rootdbs：
存放系统数据和物理日志。
（在oninit–i时逻辑日志和物理日志都是放在rootdbs中的，一定要把逻辑日志放在logdbs上）
tempdbs：
存放临时表。
logdbs：
存放逻辑日志。
userdbs：
存放用户数据。
每个dbspace的初始chunk的大小没有必要开得很大，非要把所有的硬盘空间都用完，只要够用就可以了。
因为chunk增加容易删除难，把暂时不用的硬盘空间预留起来更加灵活。
chunk有两种类型，一种是采用块设备作为chunk，称为rawdisk方式；另一种是采用普通文件作为chunk，称为cookedfile方式。
不难理解，rawdisk方式要比cookedfile方式效率高。
为了提高性能，应该尽可能采用rawdisk方式的chunk。
创建rawdisk方式的chunk时要注意以下几点：
目前的OnLine版本，每个chunk最大只能到2GB，因此创建rawdisk时大小不要超过2GB，否则超过2GB的部分就浪费了。
如果dbspace需要2GB以上的空间，必须创建多个chunk。
一些版本的UNIX，都把volume的最后几K空间作为保留区。
因此，如果你想创建一个1000MB的chunk，在创建volume时，最好建1001MB，以免nformix初始化时失败。
如果要创建cookedfile方式的chunk，只要在相应文件系统中你想要放置chunk的位置创建一个空文件。
命令为：
$cat/dev/null<想创建的空文件名>
在OnLine初始化时，会将该文件增大到你设定的chunk大小。
注意要保证该文件系统中有足够的空间创建chunk。
2.1.3创建informix组和用户（开始）
1.为informix选择一个home目录，要保证该目录所在的文件系统有足够的空间安装Informix软件。
查看文件系统的剩余空间用df命令。
假设选定的informix的home目录名为/home/informix。
2.用图形界面的管理工具或以下命令创建informix组和用户。
#groupaddinformix
#useradd–ginformix–m–d/usr/informix–s/usr/bin/kshinformix
举例：
useradd–ginformix–m–d/usr/lscp–s/usr/bin/kshlscp
useradd–ginformix–m–d/usr/smp–s/usr/bin/cshsmp
useradd–ginformix–m–d/usr/ss7–s/usr/bin/kshss7
修改informix的口令
#passwdinformix
修改/home/informix/.profile,增加以下几行：
INFORMIXDIR=/usr/informix
INFORMIXSERVER=fepdb1
ONCONFIG=onconfig
CLIENT_LOCALE=zh_cn.gb
DB_LOCALE=zh_cn.gb
PS1=[`whoami`@`hostname`:
`tty`]'$PWD$'
exportPS1
PATH=$PATH:
$INFORMIXDIR/bin
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:
$INFORMIXDIR/lib:
$INFORMIXDIR/lib/esql
exportINFORMIXDIRINFORMIXSERVERONCONFIGPATH
解释：
fepdb1为数据库server名称
onconfig为informixonline运行的配置方案。
LD_LIBRARY_PATH为informix所需要的环境变量.
CLIENT_LOCALE=zh_cn.gb
DB_LOCALE=zh_cn.gb
exportCLIENT_LOCALEDB_LOCALE
2.1.4安装informix产品
1.将要安装的INFORMIX产品（OnLine和ESQL/C）从安装介质（磁带或光盘）展开到informix用户的HOME目录下。
假设安装介质为光盘，如果光驱的设备名为/dev/disk/cdrom0a，则过程可能为：
如果需要开发环境需要装esql。
需要把clinetsdk那张光盘先行展开并安装。
#mkdir/mnt
#mount–r/dev/disk/cdrom0a/mn
升级会员 