Informix数据库系统维护及双机HDR疑难问题详解解析.docx

Informix数据库系统维护及双机HDR疑难问题详解解析.docx

《Informix数据库系统维护及双机HDR疑难问题详解解析.docx》由会员分享，可在线阅读，更多相关《Informix数据库系统维护及双机HDR疑难问题详解解析.docx（14页珍藏版）》请在冰豆网上搜索。

Informix数据库系统维护及双机HDR疑难问题详解解析

Informix数据库疑难问题解答

1、数据库日志模式

问：

一般informix做了双机，那么scp的数据库log用什么方式比较好啊？

一种是直接用log，一种用bufferlog。

答：

建议用unbufferedlogging的方式，（你们称之为直接用log），可以用onmonitor来确认数据库的日志模式。

事实上不论是双机还是单机，informix都推荐使用unbufferedlogging，这样可以保证数据库的可用性。

其他相关知识：

∙-NNoLogging没有日志

∙-UUnbufferedLogging非缓冲日志

∙-BBufferedLogging缓冲日志

∙-AUnbufferedLogging,ModeANSIANSI模式

NoLogging没有日志

----“没有日志”模式只向逻辑日志写很少的信息，它只记录执行的DDL语句，这些语句影响到的行并不被写入日志中，只记录命令本身以及返回的代码。

一个不带日志的数据库环境可以具有很高的吞吐率，但在发生严重的实例失败时没有能力重建对数据库的修改。

写到磁盘上的修改才是可以得到的全部信息。

对实例中不带日志数据库的恢复只能到最后一次创建的实例备份中进行。

UnbufferedLogging非缓冲日志

----使用“非缓冲日志”模式的数据库环境只要事务提交，就会将包含该事务信息的物理日志和逻辑日志缓冲区刷新到磁盘上。

----使用非缓冲日志，即使出现严重的实例错误，数据完整性和一致性也可以在事务级得到保证。

但是因为每一次提交事务都会导致缓冲区被刷新到磁盘上，所以增加了磁盘I/O。

另外，因为刷新是按照当前事务的进度将整个缓冲区内容都写到逻辑日志中，所以逻辑日志的页面中会有很多没有用的数据。

日志填充得很快，但其中包含的“真正”数据却比缓冲日志数据库环境少得多。

BufferedLogging缓冲日志

----使用“缓冲日志”模式的数据库环境将在逻辑日志和物理日志缓冲区中保留这些事务信息，直到该缓冲区填满，或者发生检查点操作，或者是当事务还没有被写往日志之前关闭了产生该事务的用户连接。

----有这样一种情况可以强迫缓冲日志数据库写出它的事务信息：

因为实例中只有一组逻辑日志缓冲区，当实例中的一个非缓冲日志数据库提交一个事务时，缓冲日志信息会随着非缓冲日志信息一起被写出到磁盘上。

----在“缓冲日志”数据库环境中，每个事务所造成的磁盘I/O大大降低，因此实例会运行得较快，但是因为事务信息存储在共享内存中，严重的实例错误就会很危险，当实例的共享内存被释放时，那些还没有写到磁盘上的事务信息就都丢失了。

＊非缓冲日志模式和缓冲日志模式的操作方式完全相同，其不同点在于何时将日志记录写到磁盘上，

UnbufferedLogging,ModeANSIANSI模式

----ANSI模式的操作与非缓冲日志一样，但它还强制与ANSI事务处理方式一致。

ANSI一致性包括这样一些特点和规则，如对引用表的唯一属主命名，表级权限的不同缺省值，游标读和更新能力的不同，以及character和decimal数据类型对数据类型越界或定义语句如何反应的不同。

＊OnLineDymanicServer在ANSI数据库环境中并不严格强制遵从所有的ANSI标准，如果你执行一条非ANSI的SQL语句，实例会产生一条警告信息，但仍然往下处理。

除非操作环境要求使用ANSI标准，否则使用ANSI模式不会得到任何好处。

如何改变日志模式

用onmonitor改变日志模式

onmonitor---Logical-Logs---Database

用ontpae改变日志模式

ontape–s–L0–Ncem2将数据库”cem2”从-U,-B,-A其中一种模式改变到-N模式，创建0级备份

ontape–s–L0–Ucem2将数据库”cem2”从-N改变到-U模式，创建0级备份

ontape–s–L0–Bcem2将数据库”cem2”从-N改变到-B模式，创建0级备份

ontape–s–L0–Acem2将数据库”cem2”从-N改变到-A模式，创建0级备份

＊ontape工具在-U,-B,-A三种模式中任何一种改变到另一种不需创建系统备份；

要完全从不带日志模式改成带日志模式，或者反过来，需要创建一个0级备份；

用ondblog改变日志模式：

ondblog工具只是设置一个标志，表示在下次0级备份之后将数据库日志模式改成什么。

ondblog工具的选项如下：

nolog将数据库改为不带日志模式

unbuf非缓冲日志

buf缓冲日志

ansiANSI日志模式

cancel取消前面作出的改变日志模式的请求

附加选项：

1.用空格相隔的一些数据库名，这些数据库的日志模式将被改变。

2.–f选项跟一个文件名，该文件中包含要改变日志模式的数据库名，这些数据库名在文件中单独列出，一个占一行。

＊如果没有–f加文件名，也没有列出用空格相隔的数据库名，ondblog工具在下一次0级备份之后将把实例中所有数据库都改成所要求的日志模式。

＊不管是使用ontape工具，还是使用ondblog和ontape的组合改变数据库的日志模式，该实例都不必处于quiescent状态，但是在试图改变日志模式的时候，不能有任何活动用户线索连接在该实例上。

否则的话，就会产生一个”-107”号错误。

＊如果ontape命令已经执行来改变数据库的日志模式，而中途又将其中断，则就用户连接来说，该数据库仍然是关闭的，直到创建一个完全的实例备份为止，不管是否要改变日志模式。

2、如何在HDR系统中修改参数配子文件（onconfig）？

首先把主从数据库都宕下来

然后分别修改，在重新启动数据库。

注意：

1）HDR中，主从数据库的参数一定要一致，否则就会出现启动或者同步等各种问题，这个问题已经在安徽工程中得到证实。

2）如果数据库已经因为修改参数出现问题，那么需要将以前的参数恢复过来，然后重新启动数据库，有时候需要重建HDR关系，根据具体情况看。

3、在select的时候，where条件是不是有限制？

在select的时候，where条件是不是有限制阿，就是条件不能大于18个？

我这里报了这个错误Identifiertoolong-maximumlengthis18？

答：

用where条件时一般没有什么限制，您说的这个报错是指对象名字所用的字符

长度超出了限制，象索引名、表名、列名和数据库名等等，它们的识别名在7.31的版

本里不得超过18个字符，在9版本的数据库里面已经扩大到128字符了。

4、关于INFORMIX的运行负荷进行度量的问题

问：

INFORMIX中有没有一些检查数值，可以用来对INFORMIX的运行负荷进行度量，尤其是数据的吞吐量和响应时间。

答：

关于性能的问题，有下面的方法可以试试看，有什么问题请反馈，希望把一些监控的信息放在反馈的附件中，便于分析问题，谢谢。

常用的监控informix的命令有：

onstat-gglo

onstat-giof

onstat-giov

常用的监控操作系统的命令有：

sar-d

sar-u

sar-q

onstat的数据必须取一个时段的差值才有意义。

在系统较忙时执行之。

比如取100秒进行分析，那么

onstat-gglo;sleep100;onstat-gglo

onstat-p;sleep100;onstat-p

然后将前后两组参数对应相减，得到过去100系统使用情况。

比如：

usercpu参数（用户使用cpu的时间，也就是cpu在过去100秒内共为用户提供服务的时间和）假设差值为75，syscpu＝20那么这意味着说明系统比较繁忙。

相反如果usercpu＝20，syscpu＝0.79，说明系统就相对轻松多了。

5、informix数据库主备切换的解决方法

问题描述

根据经验丰富的工程师多次实践，发现，在某些informix数据库版本的HDR结构中存在如下问题：

在主机数据库由于某些原因（宕机、关闭等）需要切换到原有的从机数据库的时候，原从机数据库变成主机数据库（Online－PRI），同时使用onstat–l的时候可以看到当前主机数据库中的一个逻辑日志状态变为“U----------”，如下图所示：

addressnumberflagsuniqidbeginsizeused%used

2057480a01U-B----143323061dd2500025000100.00

2057480bc2U---C-L1433330c385250001611564.46

2057480d83U-B----1431631252d2500025000100.00

2057480f44U-B----143173186d52500025000100.00

2057481105U-B----1431831e87d2500025000100.00

20574812c6U-B----14319324a252500025000100.00

2057481487U-B----1432032abcd2500025000100.00

2057481648U-B----14321330d752500025000100.00

2057481809U-B----14322336f1d2500025000100.00

20574819c10U-B----1432333d0c52500025000100.00

2057481b811U-B----1432434326d2500025000100.00

2057481d412U-B----143253494152500025000100.00

2057481f013U-B----1432634f5bd2500025000100.00

20574820c14U-B----1432736de052500025000100.00

20574822815U-B----14328361ab52500025000100.00

20574824416U-B----143293000352500025000100.00

20574826017U------143303557652500010.00

20574827c18U-B----1433135b90d2500025000100.00

问题分析

该问题已经经informix售后技术支持确认并非informix的bug，而是在设计informix数据库时将onconfig文件的Ltapedev设置的参数设置为/dev/null，即不起动备份逻辑日志的功能的问题。

这样的设置是告诉informix该数据库系统不需要（手工）备份日志，于是系统会做假备份，使上面的视图中flags一列显示为UB状态（正常状态）。

但是，事实上，这样的设置不论在单机还是是在HDR系统中都存在一定的问题。

解决方案1（首推方案）

从宕机时间和informix技术的角度，首推下面的测试操作方案（该方案在其他用户已经得到成功解决问题的验证）：

  1、中断HDR关系，并对原主机上的数据库进行系统0级备份；

  2、将原主备机上数据库的配置文件中的LTAPEDEV由/dev/null改成非空的路径文件

名；

  3、如果系统不需要真正的逻辑日志备份，将2中所用的非空文件做一个链接指向

/dev/null；否则该文件为真正的可读写的磁带设备路径或熟文件。

  4、改动完成后重启数据库，并重新建立原主备机的HDR关系；

  5、对主备机进行切换操作，测试原问题是否存在，即确认当前日志是否会在切换

到下一个日志后自动备份，而不会出现只是“U”，没有“B”的状态。

另外，请测试当日

志文件使用完后是否会自动变成U-B----状态，如果未变化手动执行ontape-a是否可

以备份逻辑日志等。

  注：

A）若需要强行将当前使用的日志切换到下一个日志文件，可用onmode-l的命

令，并配合onmode-c来

         使用；

      B）请注意观察online.log日志中的记录有关逻辑日志使用和备份的内容；

      C）所有操作只需在当前的主机上进行。

这种解决方案的优点是，宕机时间短，因为不需要对应用系统的重新编译，所以实施风险小。

缺点是，按照上述方案测试成功后，需要每天给系统做手工备份（使用ontape–a命令），不过这个操作可以和数据库备份（如果每天对数据库做数据备份）合并在一起做。

解决方案2

升级数据库到对此类问题有所改善的版本，

如果有其他数据库版本发现此类问题，还需要单独评价。

这种方案的优点是，解决问题的手续简单（只需要升级数据库），缺点是对于新版本数据库带来的问题还不太确定，每个新的版本都会解决一些老问题，但同时不可避免得会有些新的问题，有些我们也许会碰到，有的也许应为应用的特殊性刚好不会碰到；另外，升级数据库后，需要对应用重新编译，由此带来的风险不能给出很好的评估。

故障解决

通常，单纯的解决在主机数据库由于某些原因（宕机、关闭等）需要切换到原有的从机数据库的时候，原从机数据库变成主机数据库（Online－PRI），同时使用onstat–l的时候可以看到当前主机数据库中的一个逻辑日志状态变为“U----------”的问题（在不发生其他问题的时候），我们可以使用下述方法，排除故障：

1，在切换后的主机（原来的备机）上作0级备份，以备修复操作有问题时可以恢复数据库

2，切到标准模式，即，使用命令onmode-dstand，这么做主要是为了切断HDR关系

3，将切换后的主机（原来的备机）数据库的配置文件中的LTAPEDEV由/dev/null改成非空的路径文件名。

4，设置LTAPEDEV参数时，如果系统不需要真正的逻辑日志备份，将3中所用的非空文件做一个链接指向/dev/null；否则该文件为真正的可读写的磁带设备路径或熟文件。

5，改动完成后重启数据库，重新启动数据库，做逻辑日志的备份，ontape-a（该状态为UB）

6，再down数据库，然后重起，做0级备份，重建HDR关系

6、数据库（OnLine）的启动和关闭

OnLine共有六种运行模式（Mode）：

Off-Line,Quiescent,On-Line,Read-Only,Recovery和Shutdown。

∙Off-Line模式：

表示OnLine没有运行。

∙Quiescent模式：

相当于UNIX操作系统的单用户状态，此时不能进行数据访问，只能进行备份、增删日志文件等管理活动。

∙On-Line模式：

表示OnLine处于正常工作（在线）状态，能够向用户提供数据访问服务。

∙Read-Only模式：

表示当前OnLine处于只读状态，当使用Informix的数据复制（DataReplication）功能时，从服务器（SecondaryServer）会处于这种状态。

∙Recovery模式：

是一种短时间的临时状态。

它发生在OnLine从Off-Line向Quiescent模式转移的过程中，在这种模式下，主要完成数据库的快速恢复。

∙Shutdown模式：

是一种短时间的临时状态。

它发生在OnLine从On-Line向Quiescent模式或从On-Line（或Quiescent）向Off-Line模式转移的过程中。

最常用的模式转换命令有两个：

∙从Off-Line模式到On-Line模式，即数据库的启动。

Oninit

∙从On-Line模式到Off-Line模式，即数据库的关闭。

onmode-ky

上面的选项y表示当仍有用户连在Server上时，不再要求确认，直接断开连接。

完整的模式转换命令如下图所示：

∙如果需要查询当前Server所处的模式，可以用以下命令：

onstat-

∙如果当前Server处于Off-Line模式，会显示：

sharedmemorynotinitializedforINFORMIXSERVER'xxx'

∙在其它模式下，会显示出所处的模式，例如：

INFORMIX-OnLineVersion7.24.FC5--On-Line--Up02:

59:

21--14040Kbytes

7、数据库（OnLine）的状态查询

onstat通过读取OnLine的共享内存结构，来提供关于OnLine的各种统计信息。

这些统计信息也可以通过直接访问sysmaster数据库中的SMI（SystemMonitoringInterface）表来得到，但是用onstat命令更加直观，这也是Informix的一个优点。

onstat命令的选项非常复杂，这里只介绍最常用的。

∙onstat--

列出onstat所有选项的简要说明。

∙onstat–i

进入交互式状态，用命令q退出。

∙onstat–r[<秒数>]<其它选项>

每隔<秒数>重复执行<其它选项>一次，直至用interruptkey（一般为^C）强行中断。

<秒数>缺省为5。

∙onstat–

显示当前server的版本号、所处的模式、连续运行时间和共享内存的大小。

∙onstat–V

显示当前server的版本信息和产品号。

∙onstat–c

显示当前server启动时使用的配置文件内容。

因为在server启动后，配置文件$ONCONFIG可能被修改，因此可能和这里显示的内容不同。

∙onstat–m

显示消息日志文件online.log的最后20行。

∙onstat–u

显示当前用户的情况。

∙onstat–d

显示所有dbspace和chunk的基本情况。

包括每个dbspace的名字、由哪些chunk组成、每个chunk的大小、可用空间、是否镜像等等。

∙onstat–b

显示当前buffer区的使用情况。

在该命令输出信息的最后，会有

’XXXXbuffersize’的字样，这就是OnLine中page的大小（即配置文件中BUFFERS参数的单位）。

∙onstat–p

显示一些统计信息。

如一共进行了多少次读写操作，cache的命中率，消耗的CPU资源等。

∙onstat–l

查看逻辑日志和物理日志的大小，使用情况。

8、数据库（OnLine）的空间管理

Online初始化时，自动建立了一个名为rootdbs的dbspace。

该rootdbs存储Online的管理信息，包括物理日志、逻辑日志等。

当你建立一个数据库或表时，如果不指定dbspace，作为缺省，该库或表建立在rootdbs中。

所以，如果你想将库或表建立在某个dbspace中，则必须在SQL语句中指定dbspace名字。

如数据库名为‘stores’,我们将这个数据库建立在‘workdbs’dbspace中，SQL语句如下：

createdatabasestoresinworkdbs;

另外，建chunk或dbspace时，要指定原始磁盘设备名路径，所需磁盘空间大小，以及该块磁盘空间在原始磁盘设备中的偏移量。

其中，偏移量非常关键，要小心设置，否则容易造成chunk块之间空间上的重叠与覆盖。

例如：

假定原始磁盘设备/informixdbs1有500M空间，其中rootdbs用去前100M,如果要在/informixdbs1中建立一个新的chunk，偏移量应大于100M。

1）用onspaces命令建立dbspace

$onspaces-c-ddbspace名字-p磁盘设备-o偏移量-s尺寸

其中：

-c:

表示建立新的dbspace

-d:

dbspace名字

-p:

原始磁盘设备全路径名，如/informixdbs1

-o:

偏移量，以K字节为单位

-s:

dbspace中第一个chunk尺寸，以K字节为单位

2）用onspaces命令增加chunk

$onspaces-adbspace名字-p原始磁盘设备-o偏移量-s尺寸

其中：

-a:

表示为某个dbspace增加一个chunk,后跟dbspace名字

-p:

原始磁盘设备全路径名，如/informixdbs1

-o:

偏移量，以K字节为单位

-s:

chunk的尺寸，以K字节为单位

例如某数据库系统，在原始磁盘设备/informixdbs1上建立三个DBSPACE：

rootdbs：

Online初始化时缺省建立，第一个chunk尺寸为100M，偏移量为0;

workdbs：

存放应用数据库数据，第一个chunk尺寸为100M，偏移量为100M；

tmpdbs：

存放系统临时文件数据，第一个chunk尺寸为50M，偏移量为200M；

*tmpdbs必须在online初始化之前建立；

建立命令如下：

$onspaces-c-dworkdbs-p/informixdbs1-o100000-s100000;

$onspaces-c-dtmpdbs-p/informixdbs1-o200000-s50000;

9、数据库（OnLine）的日志管理

数据库日志方式

∙无日志方式（对应非事物性应用）

∙无缓冲区日志方式

∙带缓冲区日志方式

∙符合ANSI标准日志方式

可使用ontape命令修改数据库日志方式

∙用ontape打开事务日志：

$ontape-s-Ustores;打开数据库stores日志，日志方式为无缓冲区日志；

∙用ontape结束日志：

$ontape-Nlifeins;将数据库lifeins改为无日志方式。

物理日志的管理

物理日志保存数据被修改前的映象。

物理日志的位置和大小可以改变。

使用onparams命令改变物理日志的位置和大小，在Online进入静态方式后执行：

$onparams-p-ssize-ddbspace-y

其中-p:

表示物理日志

-s:

新的尺寸，后跟以K字节为单位的物理日志的大小

-d:

说明存放物理日志的dbspace名字

-y:

对所有的提问以“Yes”回答

注意：

分配给物理日志的空间必须是连续的，因此，改变之前要确认dbspace有足够的空间来存放物理日志。

逻辑日志的管理

逻辑日志保存数据在修改后的映象，逻辑日志空间的尺寸为逻辑日志文件尺寸与逻辑日志文件个数的乘积。

Online初始化后，已有逻辑日志文件的尺寸不可修改，要改变逻辑日志空间大小，只能修改逻辑日志文件个数，新增加的逻辑日志文件尺寸可以设为新的值，逻辑日志文件个数不得少于3个。

（1）、用onparams增加逻辑日志文件

$onparams-a-drootdbs

新增加的逻辑文件状态是A（A表示新增加的意思）。

必须建立rootdbs的0级备份后，新增加的逻辑日志文件才可使用。

（2）、增加一个具有新的尺寸的逻辑日志文件

$onparams-a-drootdbs-s新的日志尺