On 12.1.0.2 database, try to gather fixed table statistics with below command, it hangs at object “X$DURABLE_SHARDED_SUBS”. Also hangs at select couint(*) from X$DURABLE_SHARDED_SUBS.
SQL>EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS ()
SQL>select count(*) from X$DURABLE_SHARDED_SUBS;
CAUSES
It is a bug for this issue, it is supposed to be fixed in 12.2.0.X.
AWR report shows AUD$ table is the segment with the highest “Global Cache Buffer Busy” wait event:
CAUSE
With AUDIT_TRAIL set for database (AUDIT_TRAIL=db), and the AUD$ and FGA_LOG$ tables located in a dictionary segment space managed SYSTEM tablespace, “gc” wait events are sometimes observed during heavy periods of database logon activity.
SOLUTION
Move AUD$ and FGA_LOG$ tables onto an ASSM tablespace like SYSAUX. On production, make sure to run it during off peak hours.
set pagesize 120
set linesize 180
SELECT T.TABLE_NAME, TS.SEGMENT_SPACE_MANAGEMENT
FROM DBA_TABLES T, DBA_TABLESPACES TS
WHERE TS.TABLESPACE_NAME = T.TABLESPACE_NAME
AND T.TABLE_NAME = 'AUD$';
TABLE_NAME SEGMEN
---------- ------
AUD$ MANUAL
select TABLESPACE_NAME,SEGMENT_SPACE_MANAGEMENT
from DBA_TABLESPACES
where TABLESPACE_NAME='SYSAUX';
TABLESPACE_NAME SEGMEN
---------------- ------
SYSAUX AUTO
select TABLE_NAME,TABLESPACE_NAME,SEGMENT_NAME
from dba_lobs
where OWNER='SYS' and TABLE_NAME='AUD$';
TABLE_NAME TABLESPACE_NAME SEGMENT_NAME
---------- --------------- -------------------------
AUD$ SYSTEM SYS_LOB0000000384C00040$$
AUD$ SYSTEM SYS_LOB0000000384C00041$$
select SEGMENT_NAME,segment_type,tablespace_name
from dba_segments
where segment_name in (
select INDEX_NAME
from dba_indexes
where OWNER='SYS'
and TABLE_NAME='AUD$');
SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME
------------------------ ------------ ---------------
SYS_IL0000000384C00041$$ LOBINDEX SYSTEM
SYS_IL0000000384C00040$$ LOBINDEX SYSTEM
2) For 12.1, there are following options for 12.1 database. choose one suitable to your situation.
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE (
sql_id IN VARCHAR2,
plan_hash_value IN NUMBER := NULL,
sql_text IN CLOB,
fixed IN VARCHAR2 := 'NO',
enabled IN VARCHAR2 := 'YES')
RETURN PLS_INTEGER;
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE (
sql_id IN VARCHAR2,
plan_hash_value IN NUMBER := NULL,
sql_handle IN VARCHAR2,
fixed IN VARCHAR2 := 'NO',
enabled IN VARCHAR2 := 'YES')
RETURN PLS_INTEGER;
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE (
sql_id IN VARCHAR2,
plan_hash_value IN NUMBER := NULL,
fixed IN VARCHAR2 := 'NO',
enabled IN VARCHAR2 := 'YES')
RETURN PLS_INTEGER;
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE (
attribute_name IN VARCHAR2,
attribute_value IN VARCHAR2,
fixed IN VARCHAR2 := 'NO',
enabled IN VARCHAR2 := 'YES')
RETURN PLS_INTEGER;
3) Create a sql baseline for sql_id=’gjpdb42w841yt’ and PLAN_HASH_VALUE=3153495478 .
After database upgrading / Patching, or database is migrated onto new infrastructure, it is common to see database performance is degrading due to SOL execution plans changed.
What we can do is by creating SQL plan baselines from old database, then copied them on to new database.
1) Identify the SQL plan baseline(s) to be migrated from source database:
SQL> select sql_handle, plan_name, sql_text, enabled, accepted
from dba_sql_plan_baselines
where enabled='YES'
and accepted='YES'
and PLAN_NAME='SQL_PLAN_7ns0utmam6vc64a63fd18';
SQL_HANDLE PLAN_NAME SQL_TEXT ENA ACC
-------------------- ------------------------------ -------- --- ---
SQL_7a601accd5336d86 SQL_PLAN_7ns0utmam6vc64a63fd18 UPDATE . YES YES
7) Unpack the SQL plan baselines in staging table into target database:
SQL> var xx number;
begin
:xx := DBMS_SPM.UNPACK_STGTAB_BASELINE('SPM_TAB', 'TESTUSER');
end;
/
PL/SQL procedure successfully completed.
8) Verify the SQL plan baselines have been migrated onto target database:
SQL>select sql_handle, plan_name, sql_text, enabled, accepted, fixed
from dba_sql_plan_baselines
where SQL_HANDLE='SQL_7a601accd5336d86';
SQL_HANDLE PLAN_NAME SQL_TEXT ENA ACC FIX
-------------------- ------------------------------ ------- --- --- ---
SQL_7a601accd5336d86 SQL_PLAN_7ns0utmam6vc64a63fd18 UPDATE YES YES NO
9) Display execution plans for this SQL handle of a SQL plan baseline:
SQL> set linesize 120
SQL> set pagesize 2000
SQL> select * from TABLE(DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE( -
'SQL_7a601accd5336d86','SQL_PLAN_7ns0utmam6vc64a63fd18'));
Syntax:
DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE (
sql_handle IN VARCHAR2 := NULL,
plan_name IN VARCHAR2 := NULL,
format IN VARCHAR2 := 'TYPICAL')
RETURN dbms_xplan_type_table;
Parameter
Description
sql_handle
SQL statement handle. It identifies a SQL statement whose plan(s) are to be displayed.
plan_name
Plan name. It identifies a specific plan. Default NULL means all plans associated with identified SQL statement are explained and displayed.
format
Format string determines what information stored in the plan displayed. One of three format values (‘BASIC’, ‘TYPICAL’, ‘ALL’) can be used, each representing a common use case.
Background process SMON is using the temporary tablespace to be dropped with “enq: TS – contention” wait event.
After created a new temporary tablespace TEMPNEW as database default temporary tablespace, then try to drop the old temporary tablespace “TEMP”, it hangs up forever.
SQL> drop tablespace temp including contents and datafiles;