Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

29

积分

187

好友

71

主题
1#
发表于 2017-7-13 13:39:56 | 查看: 4817| 回复: 3
刘大 and 各位 大神    问个问题  ogg里面 提示错误如下
ERROR   OGG-01028  Oracle GoldenGate Capture for Oracle, ext1.prm:  Object with object number 117751 is compressed.
根据查询返现 对应的对象为

这个已经 exclude掉了  但是想问 这样的表是干啥的  mos里也没有找到信息

CMP3$104374             TABLE                  DROP
CMP4$104374             TABLE                  DROP
CMP4$104374             TABLE                  DROP
CMP4$104374             TABLE                  DROP
CMP4$104374             TABLE                  DROP
CMP4$104374             TABLE                  DROP
CMP3$104374             TABLE                  DROP
CMP3$104374             TABLE                  DROP


answer:

Support confirmed that these Compression Advisor tables CMP<x>$<object_id> will automatically dropped over a period of time and should not be dropped manually.
下载专业ORACLE数据库恢复工具PRM-DUL  For Oracle http://www.parnassusdata.com/zh-hans/emergency-services

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638  QQ: 47079569   
2#
发表于 2017-7-13 13:41:32

Click to add to Favorites                Is Table SCHEMA.CMP4$222224 Or Similar Related To Compression Advisor?
APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.4 and later
Information in this document applies to any platform.
< currency check done on 03 Nov16 >
GOAL

The database is at Oracle 11.2.0.4 BP1 or higher.

After applying this patch, we are starting to see tables with names that include "CMP", ie CMP4$222224.
Is this related to the compression advisor?


SOLUTION

Yes, the tables with "CMP" in their name are related to Compression Advisor.

The following test confirms the change in behavior from 11.2.0.3 to 11.2.0.4


drop table foo;

CREATE TABLE FOO
  PARTITION BY RANGE(object_id)
  (PARTITION k1 VALUES LESS THAN(10000),
  PARTITION k2 VALUES LESS THAN(20000),
  PARTITION k3 VALUES LESS THAN(30000),
  PARTITION k4 VALUES LESS THAN(40000),
  PARTITION k5 VALUES LESS THAN(50000),
  PARTITION maxpart VALUES LESS THAN(maxvalue)
  ) storage (initial 64k next 1k)
as select * from dba_objects;

alter session set tracefile_identifier = 'CompTest';
alter session set events '10046 trace name context forever, level 12';
set serveroutput on
DECLARE
blkcnt_cmp pls_integer;
blkcnt_uncmp pls_integer;
row_cmp pls_integer;
row_uncmp pls_integer;
cmp_ratio pls_integer;
comptype_str varchar2(100);
BEGIN
DBMS_COMPRESSION.GET_COMPRESSION_RATIO ('USERS', 'STEVE', 'FOO', NULL, DBMS_COMPRESSION.COMP_FOR_OLTP, blkcnt_cmp, blkcnt_uncmp, row_cmp, row_uncmp, cmp_ratio, comptype_str);
DBMS_OUTPUT.PUT_LINE('Block count compressed = ' || blkcnt_cmp);
DBMS_OUTPUT.PUT_LINE('Block count uncompressed = ' || blkcnt_uncmp);
DBMS_OUTPUT.PUT_LINE('Row count per block compressed = ' || row_cmp);
DBMS_OUTPUT.PUT_LINE('Row count per block uncompressed = ' || row_uncmp);
DBMS_OUTPUT.PUT_LINE('Compression type = ' || comptype_str);
DBMS_OUTPUT.PUT_LINE('Compression ratio = '||blkcnt_uncmp/blkcnt_cmp||' to 1');
DBMS_OUTPUT.PUT_LINE('Compression ratio org= '||cmp_ratio);
END;
/

exit


In 11.2.0.3, you will see the following in the file generated by the 10046 tracing.  The trace file will be located in user_dump_dest.


create table "STEVE".DBMS_TABCOMP_TEMP_UNCMP tablespace "USERS" nologging as
  select /*+ DYNAMIC_SAMPLING(0) FULL("STEVE"."FOO") */ * from "STEVE"."FOO"
  partition("K4") sample block( 99) mytab



create table "STEVE".DBMS_TABCOMP_TEMP_CMP organization heap tablespace
  "USERS" compress for all operations nologging as select /*+
  DYNAMIC_SAMPLING(0) */ * from "STEVE".DBMS_TABCOMP_TEMP_UNCMP mytab



In 11.2.0.4 you will see the following (extracted using logminer).  The 10046 did not show the complete table ddl.


create table "STEVE".CMP3$88493 tablespace "USERS" nologging as select /*+ DYNAMIC_SAMPLING(0) FULL("STEVE"."FOO") */ * from " STEVE"."FOO" sample block( 99)
mytab ;

create table "STEVE".CMP4$88493 organization heap tablespace "USERS" compress for all operations nologging as select /*+ DYNAMIC_SAMPLING(0) */ * from "STEVE".CMP3$88493 mytab;


The reason for the change in the naming of the interim tables is to allow concurrent sessions to execute the above procedure (the compression advisor) e.g. for different objects of the same schema (e.g. for different tables of the same schema or for different partitions of the same table). The name of the interim table is now constructed by using the object_id of the object that the above procedure (the compression advisor) is called for.

If you see tables with names like CMP3$xxxxxx or CMP4$xxxxxx (where xxxxxx is a number) left over after running Compression Advisor, it is likely because Compression Advisor failed at some point.  These are interim tables created/used by Compression Advisor, which are normally dropped when it completes.   You can safely drop those tables.

回复 只看该作者 道具 举报

3#
发表于 2017-7-13 13:42:42
11gR2 Compression Advisor = Evil

I recently upgraded to 11.2.0.2 from 11.1.0.7. Immediately after the upgrade, I noticed a spike in our redo generation. I also noticed tables with names like DBMS_TABCOMP_TEMP_UNCMP and DBMS_TABCOMP_TEMP_CMP. What are those tables doing in my production schemas and how did they get there? After digging, I was able to find out that these are created by the new 11gR2 Compression Advisor. During the nightly maintenance window, a scheduled job will look at your tables and take a subset of data and load into an uncompressed table (UNCMP). It will then compress your data (CMP) and determine the compression ratio based on your actual data. If the compression ratio is above a certain threshold, the advisor recommends the table for compression. After the Compression Advisor is done, the tables are deleted.
The problem is that the Compression Advisor generates a ton of redo! This has been noted as unpublished bug 8896202. More information can be found on Metalink Note 1284972.1 if you are interested.
I won’t be using the Compression Advisor so I’d like to turn off the nightly job. Unfortunately, the job is part of the Space Advisor and I cannot turn off the Compression Advisor on its own. Well the redo generation rate is simply too high and I guess I can live without the Space Advisor too, so off it goes:
SQL> exec dbms_auto_task_admin.disable(client_name=>'auto space advisor',operation=>null,window_name=>null);

PL/SQL procedure successfully completed.
I see that an enhancement request has been filed to decouple the Compression Advisor from the Space Advisor.

回复 只看该作者 道具 举报

4#
发表于 2017-7-13 13:43:33
cmp$是 压缩建议compression advisor组件生成的表,若你经常看到 说明该组件工作有问题。 可以关闭
exec dbms_auto_task_admin.disable(client_name=>'auto space advisor',operation=>null,window_name=>null);

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-5-20 07:49 , Processed in 0.046704 second(s), 20 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569