从Oracle 11g迁移到12c之后,我们遇到了一个巨大的性能问题,例如使用以下select语句.同样的声明在11g中运行良好.
表和索引
-- Create table
create table PS_CS_ADRART_TB
(
cs_adressmandant VARCHAR2(5) not null,
cs_person_id VARCHAR2(20) not null,
cs_beziehung_id VARCHAR2(20) not null,
seqnum INTEGER not null,
effdt DATE,
eff_status VARCHAR2(1) not null,
cs_adrart_cd VARCHAR2(20) not null,
cs_adress_id VARCHAR2(20) not null,
cs_kdnr_as400 VARCHAR2(8) not null,
cs_plzgk VARCHAR2(11) not null,
cs_plz_pf VARCHAR2(15) not null,
cs_aendgr_cd VARCHAR2(20) not null,
cs_datasource_cd VARCHAR2(20) not null,
cs_betrag NUMBER(14,4) not null,
cs_belegdat DATE,
cs_adrtyp_xl VARCHAR2(2) not null,
cs_checked VARCHAR2(1) not null,
cs_journal_xl VARCHAR2(4) not null,
address2 VARCHAR2(55) …我们有一个非常简单的select语句访问具有唯一索引字段的数据.然而,优化器决定使用坏索引,选择大约需要4秒而不是0.0x秒.
oracle 11g不存在这个问题,但是使用oracle 12c.
表统计信息是最新的.
看来,糟糕计划的估计是错误的(见下文),我们如何避免这种情况？
我想通过添加字段统计或基线条目,但我希望有另一种解决方案.
提前致谢.
表定义
create table PS_CS_AKT_PROD_TB(business_unit VARCHAR2(5) not null,
ra_cmpgn_wave_id VARCHAR2(15) not null,
product_id VARCHAR2(18) not null,
cs_aboart_cd VARCHAR2(20) not null,
cs_einweis_id VARCHAR2(20) not null,
row_added_dttm TIMESTAMP(6),
row_added_oprid VARCHAR2(30) not null,
row_lastmant_dttm TIMESTAMP(6),
row_lastmant_oprid VARCHAR2(30) not null,
cs_recstat_xl VARCHAR2(4) not null,
/* ... further fields ... */
cs_kondition VARCHAR2(20) not null)
tablespace CS_APP pctfree 10 initrans 1
maxtrans 255 storage(initial 40K next 104K
minextents 1 maxextents unlimited);
索引
create unique index PS_CS_AKT_PROD_TB on PS_CS_AKT_PROD_TB( …