如何在 Informix 上测量查询性能？

Posted 2023-04-19

【中文标题】如何在 Informix 上测量查询性能？

【英文标题】：How do I measure query performance on Informix?

【发布时间】：2013-10-07 07:30:41

【问题描述】：

我在使用 Informix 查询时遇到了一些性能问题。如何分析这些查询以缩小问题的根源？

【问题讨论】：

ibm.com/developerworks/data/library/techarticle/dm-0409fan

【参考方案1】：

select  der.session_id,
der.blocking_session_id, 
der.wait_type, 
der.wait_time,
der.start_time, 
DATEDIFF(second,der.start_time,GETDATE())/60.0 AS executeTime_Minutes,
percent_complete,
der.status as requestStatus, 
des.login_name, 
cast(db_name(der.database_id) as varchar(30)) as databaseName,
 des.program_name,
 der.command as commandType,
der.percent_complete,
case des.transaction_isolation_level
 when 0 then 'Unspecified' when 1 then 'ReadUncomitted'
 when 2 then 'ReadCommitted' when 3 then 'Repeatable'
 when 4 then 'Serializable' when 5 then 'Snapshot'
 end as transaction_isolation_level,
char(13) + char(10) + Current Command + char(13) + char(10) + 
case when der.statement_end_offset = -1 then 

--见objectText-- 否则 SUBSTRING(execText.textder.statement_start_offset/2, (der.statement_end_offset - der.statement_start_offset)/2) end + char(13) + char(10) + '--------完整对象------------' AS currentExecutingCommand, execText.text 作为 objectText 来自 sys.dm_exec_sessions des --返回有关 SQL Server 实例上每个用户和内部系统会话的信息，包括会话设置、安全性和累积 CPU、内存和 I/O 使用情况 以 der 身份加入 sys.dm_exec_requests -- sys.dm_exec_requests DMV 向我们展示了当前正在运行的内容 关于 der.session_id = des.session_id -- 在 SQL Server 实例上，它对内存、CPU、磁盘和缓存的影响。 外部应用 sys.dm_exec_sql_text(der.sql_handle) 作为 execText 其中 --des.session_id @@spid 和 des.session_id > 40;

【讨论】：

很抱歉没有澄清，但这将是活跃的查询和进程。我假设一个工具是用于比较不同版本的统计输出。

【参考方案2】：

来自here:-

Informix 提供的最全面的收集工具 详细的 SQL 查询计划和执行统计信息是 SET EXPLAIN 效用。该实用程序将生成一个名为 sqexplain.out 的文件，并且 详细记录查询执行的每一步。另外它 提供查询的估计成本并估计查询 结果。通过检查 SET EXPLAIN 输出文件，您可以确定 如果可以采取措施来提高查询的性能。这 以下示例显示了一个非常复杂的 set explain 输出 查询：

SELECT --+AVOID_FULL(omchn)+AVOID_FULL(daphn)
                omchn.omc_hn_uanc,
                nvl(daphn.gtt_version,"0000000000000000000"),
                nvl(idachn.egt4_version,"0000000000000000000"),
                nvl(ihlrhn.hlr_timestamp,"00000000000000"),
                vsgw_hn.hn_igw_uanc,
                nvl(vsgw_hn.hn_igw_version, "00000000000000")
           FROM omchn, daphn, idachn, ihlrhn, vsgw_hn
          WHERE daphn.dap_hn_inst  = omchn.omc_hn_inst
            AND idachn.idac_hn_inst = omchn.omc_hn_inst
            AND ihlrhn.hlr_hn_inst = omchn.omc_hn_inst
            AND vsgw_hn.vsgw_hn_inst = omchn.omc_hn_inst

DIRECTIVES FOLLOWED:
AVOID_FULL ( omchn )
AVOID_FULL ( daphn )
DIRECTIVES NOT FOLLOWED:

Estimated Cost: 8
Estimated # of Rows Returned: 1

  1) root.idachn: SEQUENTIAL SCAN

  2) root.daphn: INDEX PATH

    (1) Index Keys: dap_hn_inst   (Serial, fragments: ALL)
        Lower Index Filter: root.daphn.dap_hn_inst = root.idachn.idac_hn_inst
NESTED LOOP JOIN

  3) root.vsgw_hn: SEQUENTIAL SCAN
NESTED LOOP JOIN

  4) root.omchn: INDEX PATH

                Filters: root.vsgw_hn.vsgw_hn_inst = root.omchn.omc_hn_inst
            (1) Index Keys: omc_hn_inst   (Serial, fragments: ALL)
      Lower Index Filter: root.idachn.idac_hn_inst = oot.omchn.omc_hn_inst
NESTED LOOP JOIN

     5) root.ihlrhn: INDEX PATH

            (1) Index Keys: hlr_hn_inst   (Serial, fragments: ALL)
      Lower Index Filter: root.ihlrhn.hlr_hn_inst = root.omchn.omc_hn_inst
NESTED LOOP JOIN