分类目录归档:Informix

Informix

rootdbs空间不足引起的备份失败

症状1:

Informix Dynamic Server 2000 Version 9.21.UC2 for LINUX

2011-02-15 09:49:55 17296 17294 /home/informix/bin/onbar_d -b -l
2011-02-15 09:49:55 17296 17294 Begin backup logical log 147643.
2011-02-15 09:49:55 17296 17294 Successfully connected to Storage Manager.
2011-02-15 09:49:55 17296 17294 SQL -271 Could not insert new row into the table.
2011-02-15 09:49:55 17296 17294 ISAM -131 ISAM error: no free disk space
逻辑备份出现问题
2011-02-17 09:14:37 11293 11291 /home/informix/bin/onbar_d -b -l
2011-02-17 09:14:38 11293 11291 Begin backup logical log 149938.
2011-02-17 09:14:38 11293 11291 Successfully connected to Storage Manager.
2011-02-17 09:14:38 11293 11291 The logical logs are full. ON-Bar may encounter errors writing to the sysutils database.
2011-02-17 09:14:38 11293 11291 SQL -691 Missing key in referenced table for referential constraint (informix.r102_11).
2011-02-17 09:14:38 11293 11291 ISAM -111 ISAM error: no record found.
2011-02-17 09:14:38 11293 11291 SQL -691 Missing key in referenced table for referential constraint (informix.r103_16).
2011-02-17 09:14:38 11293 11291 ISAM -111 ISAM error: no record found.
2011-02-17 09:14:38 11293 11291 The logical logs are full. ON-Bar may encounter errors writing to the sysutils database.
2011-02-17 09:14:38 11293 11291 SQL -691 Missing key in referenced table for referential constraint (informix.r102_11).
2011-02-17 09:14:38 11293 11291 ISAM -111 ISAM error: no record found.
2011-02-17 09:14:38 11293 11291 /home/informix/bin/onbar_d complete, returning 148 (0x94)

经onstat -d 查询,rootdbs空间不足,而rootdbs中有被人创建了其它库表索引(估计语句中没有指定dbspace导致),清理这些索引以增加剩余空间恢复正常备份或者为rootdbs添加chunk亦可 继续阅读

如何让informix数据库再次进入到恢复模式,来完成之前失败的数据备份恢复操作?

如何让informix数据库再次进入到恢复模式,来完成之前失败的数据备份恢复操作?
本文主要介绍,在对数据库的备份进行恢复操作失败的情况下,如何再次进入恢复模式,继续之前的恢复数据库操作,而不必重头再次做起。
通常情况下,数据库如果正在做备份的恢复工程中,如果把数据库停下来,则我们需要重头执行整个数据库恢复操作,这样会比较浪费客户的时间,有没有更好的方法呢?
如果数据库的物理恢复完成的情况下,我们中断了数据库的逻辑日志恢复阶段,则我们可以有以下机会跳过再次进行物理恢复数据的过程,而直接进入到未完成的逻辑日志恢复阶段。
步骤:
1. 首先检查online.log, bar_act.log确认数据库的物理恢复已经完成,如果数据物理恢复阶段没有完成的情况下,需要重头执行恢复命令。
2. onmode -ky把数据库停下来。
3. onbar -r , 或者 onbar -r -l 来继续恢复逻辑日志,并把数据库转换到静止模式。
用户可以使用以上步骤,而不必关心ONCONFIG中的RESTARTABLE_RESTORE参数配置。
RESTARTABLE_RESTORE该参数只使用于onbar -RESTART命令的执行,缺省值为ON.
更多信息可以参考 IBM Informix Backup & Restore Guide等资料。

The specified table (mon_syssqltrace) is not in the database

在informix 11.50中,tmp/online.log日志中出现如下错误信息:

09:15:01  SCHAPI: Error -206 The specified table (mon_syssqltrace) is not in the database.
09:15:01  SCHAPI: Type: SENSOR, Name: Save SQL Trace, Location: NULL.
09:15:01  SCHAPI: Error -111 ISAM error:  no record found.
09:15:01  SCHAPI: Type: SENSOR, Name: Save SQL Trace, Location: NULL. 继续阅读

在 IDS 9.4 中更高效地创建表和索引

简介

任何稍微了解 SQL(结构化查询语言)的人都知道如何在数据库中创建表和索引。但是就系统和数据库性能而言,如何才能更高效地创建表和索引呢?以下是在创建表和索引之前需要考虑的事项:

  • 数据库空间(Dbspace)
  • 区段大小(Extent size)
  • 锁模式
  • 约束键字

本文将仔细研究所有这些考虑事项,并通过工作环境中收集的实际例子进行说明。 继续阅读

Informix Dynamic Server维护手册

Informix Dynamic Server维护手册

版本信息

Version Date Author Remark
V0.5 2004-7-1 HenryCheung Finished Chapter 1- Chapter 4
V0.6 2004-7-22 Henry Modify Chapter1

Add new content into Chapter3, Chaper4

V1.0 2004-7-29 Henry Zhang Modify Chapter3,Chapter4

Rename

V1.1 2004-8-18 Henry Zhang Add Chapter5

Rename

 

 

文档说明

本手册由Henry Cheung参考IBM Informix红皮书,以及internet上Informix相关资源(详见附录A参考资料),结合个人经验编写。有相关Informix的技术交流欢迎通过zhangjij@cn.ibm.com和作者联系。 继续阅读

调优 Informix SQL

SQL 查询构成了 Informix® 数据库应用程序的主干。本文将讨论 Informix 的 SQL 查询调优指导原则,查看调优 SQL 查询时需要考虑的因素,同时还将探讨作者本人体验过的一些调优示例。第二部分将讨论访问方法、子查询以及区段管理对于性能的影响,解释如何可以通过理解索引层次、惟一性、分段和 PDQ 优先级来影响性能。并举例说明如何可以应用这些原则

简介

通常认为 SQL 查询的调优是程序员和开发人员的主要责任,但是数据库管理员也应积极参与该过程。数据库管理员参与 SQL 查询调优的主要好处之一是,他们可以提出不同的观点。程序员是从应用程序性能的角度来考虑问题的,而 DBA 考虑问题时理解了数据库本身,从而可以对数据库的布局、表和索引的安排,以及 Informix 和系统资源(包括数据分段、PDQ 优先级、CPU 时间、内存利用率和数据存储)的有效使用提出意见和建议。有时,程序员和开发人员就性能而言仅仅需要获取不同的查询视图,因此他们可以修改该查询,以获得更高的效率。 继续阅读

通过 UPDATE STATISTICS 充分利用 Informix Dynamic Server 优化器

简介(http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0803changappa/)

UPDATE STATISTICS 是一个专用 Informix SQL 命令,它通过分析数据并将该信息存储在系统编目中,更新关于每个表以及它的列的实际信息,这些信息可用于估计随后查询的成本。要真正理解 UPDATE STATISTICS 的重要性,您需要理解当用户输入一个要执行的 SQL 查询时,到底会发生什么事情。输入的每个 SQL 查询都必须被解析、优化和执行。

优化器是用于准备查询计划的组件。理想情况下,查询计划是执行给定查询的最佳计划 — 也就是说,它会确定抓取数据的最佳方式。为此,它使用一个统计数据集合;然而,这种统计数据并不一定是准确的。这种数据的准确性取决于很多因素,例如采用的抽样算法的类型、抽样的数量和数据的歪斜情况。

查询优化器不会自动重新计算表的配置文件。在某些情况下,收集统计信息需要的时间可能比执行查询的时间更长。为确保优化器选择的查询计划能够最好地反映表的当前状态,应定期运行 UPDATE STATISTICS。 继续阅读

IBM Informix Dynamic Server 优化器概述

简介

IBM® Informix®Dynamic Server 优化器组件的作用是对可能的查询执行计划进行评估,然后根据试探性规则以及成本来确定最好的计划。

优化器用“智能猜测”来确定首先扫描哪个表,这种猜测基于查询中出现的表的行数,以及这些表的索引的可用性。然后,它从余下可能的表中确定哪一个将与第一个表连接(join),接下来将哪个表与这两个表连接,依此类推,直到每个表的连接顺序都已确定为止。 继续阅读

Informix 11.5 SQL 语句性能监控方法及实现

本文主要介绍 Informix 11.5 中 SQL 语句性能监控的基本方法及实现,希望能够使大家有一个比较全面的了解。

我们知道,在数据库应用系统中,SQL 语句的性能好坏至关重要。如果 SQL 语句性能很差,可能会导致整个数据库应用系统的性能也非常差。那么,如何监控数据库系统中 SQL 语句的性能,导致 SQL 语句性能差的原因是什么? SQL 语句运行过程中对系统资源的使用情况如何?系统资源存在哪些瓶颈?在 Informix 11.5 中,主要提供了两个工具来解决上述问题。一个是 set explain 命令,我们可以通过查看数据库的查询计划来分析导致 SQL 语句性能差的原因并给予相应的调整,另一个是 SQL 下钻查询特性,通过它,我们可以分析系统中哪些 SQL 语句执行比较慢、SQL 语句执行的时间是多少、SQL 语句运行时对资源的占用情况及系统存在的瓶颈是什么并及时进行相应的调整。下面,我们具体来看一下这两种监控工具的具体使用方法,希望对大家能有所帮助。 继续阅读