There seem to be a lot of interest (at least on Twitter and at OUG conferences) about Oracle recommendation to install a couple patches on top of 12.1.0.2, in order to emulate 12.2 behavior when it comes to SQL Plan Directives (details here, need MOS account).
One of the things SQL Plan Directives do is trigger column groups (CG) creation.
Column groups are virtual columns representing a hash (SYS_OP_COMBINED_HASH) of the multiple table columns they are defined on (that’s why only equality conditions can be satisfied by CG) and they have an ugly long system-generated name. According to the DECODE in ALL_STAT_EXTENSIONS user-generated GC get a SYS_STU prefix in the name while system-generated one get SYS_STS. As far as I could tell only SPD-triggered CGs are named SYS_STS%(corrections are very welcome here), even those created as consequence of using DBMS_STATS.SEED_COL_USAGE have SYS_STU% name.
The other day somebody asked how to remove those CG in case one wanted to “start fresh” after applying the mentioned 12.1.0.2 patches. I wrote a little script that was by no mean intended to be exhaustive (or fully tested) but was good way to get started removing SPD-triggered CGs so I figured I would share, the script starts from the assumption only SPD-triggered CGs have a SYS_STS% name.
The script does NOT remove the CGs by itself, it just creates another script that include the DROP in there so that you can read, digest and only then execute it manually. Also another script is created, just to put the CG back in place (just the definition, no stats are gathered) in case some are indeed needed. Little side effect is since you put them in place manually then the names become SYS_STU% and not SYS_STS%.
Code below
PRO PRO usage @drop_extended_stats.sql connected as the user that owns the table PRO and pass the table name when requested. PRO DEF current_table = '&&table_name.' SET SERVEROUTPUT ON VERI OFF FEED OFF TIMING OFF SPO drop_extended_stats_&¤t_table._driver.sql BEGIN FOR i IN (SELECT extension_name, extension FROM user_stat_extensions WHERE table_name = UPPER('&¤t_table.') AND extension_name LIKE 'SYS_STS%' -- SYS_STS are system generated from the DECODE in ALL_STAT_EXTENSIONS ) LOOP DBMS_OUTPUT.PUT_LINE('-- Dropping extension on '||i.extension); DBMS_OUTPUT.PUT_LINE('exec DBMS_STATS.DROP_EXTENDED_STATS(user, ''&¤t_table.'', '''||i.extension||''');'); END LOOP; END; / SPO OFF SPO create_extended_stats_&¤t_table._driver.sql BEGIN FOR i IN (SELECT extension_name, extension FROM user_stat_extensions WHERE table_name = UPPER('&¤t_table.') AND extension_name LIKE 'SYS_STS%' -- SYS_STS are system generated from the DECODE in ALL_STAT_EXTENSIONS ) LOOP DBMS_OUTPUT.PUT_LINE('-- Dropping extension on '||i.extension); DBMS_OUTPUT.PUT_LINE('SELECT DBMS_STATS.CREATE_EXTENDED_STATS(user, ''&¤t_table.'', '''||i.extension||''') FROM dual;'); END LOOP; END; / SPO OFF SET SERVEROUTPUT OFF VERI ON FEED ON TIMING ON
UPDATE: just learned about this MOS note
April 27, 2017 at 7:00 pm
Thanks Mauro, will be really useful as today we encountered this nasty bug : ORA-28113 & ORA-00904 On A 12c Database with VPD, FGA And Extended Statistics(Virtual Columns) (Doc ID 2199556.1)
Hope to see you one day again eventhough I don’t do much Oracle stuff anymore.. 😦
LikeLike
April 27, 2017 at 7:04 pm
Glad to hear that (about the post usefulness) and sure hope to see you soon!!
LikeLike
April 28, 2017 at 2:17 pm
What about using the dba_stat_extensions.creator column to determine if the stats extension was created by a user vs the system?
LikeLike
April 28, 2017 at 2:18 pm
What about using the dba_stat_extensions.creator column to determine if the stats extension was created by a user vs the system?
LikeLike
April 28, 2017 at 2:23 pm
I like your recommendation better, seems like “everything not user (SYS_STU) is system” so no need to restrict to just SYS_STS. Question: have you seen CGs created with something different than SYS_STS prefix? Asking out of curiosity 🙂
LikeLike
April 28, 2017 at 4:30 pm
Haven’t looked into this enough to provide a meaningful response.
LikeLiked by 1 person
Pingback: Adaptive mayhem | Oracle Scratchpad