ORA-20010: DBMS_STATS INTERNAL ERROR in fill_cstats : both dmin/dmax and nmin/nmax are null for table SOA , column KEY , ssize 29892 - oracle

ORA-20010: DBMS_STATS INTERNAL ERROR in fill_cstats : both dmin/dmax and nmin/nmax are null for table SOA, column KEY , ssize 29892
ORA-06512: at "MOSTI", line 165
ORA-06512: at line 1
The above error occurred in production, can someone please explain why it has occurred and solution?

It seems due to an oracle internal bug.
ORA-20010: DBMS_STATS INTERNAL ERROR In Fill_cstat During Analyze A
Table (文档 ID 2247315.1)
Getting following error when gathering the table statistics:
EXEC DBMS_STATS.gather_table_stats(ownname => 'S', tabname => 'TEST',
estimate_percent => 100, cascade => TRUE, granularity=> 'ALL', degree
=> 2, no_invalidate=>FALSE);
* ERROR at line 1: ORA-20010: DBMS_STATS INTERNAL ERROR in fill_cstats : both dmin/dmax and nmin/nmax are null for table S.TEST , column
FIRST_NAME , ssize 430241 ORA-06512: at "SYS.DBMS_STATS", line 34757
ORA-06512: at line 1
The bug is fixed in 12.2
Workaround for the bug is to delete statistics and re-gather statistics
If the above workaround does not work, another potential workaround is using parallel degree of 1:
SYS#EXEC DBMS_STATS.gather_table_stats(ownname => 'SCOTT', tabname => 'TEST', estimate_percent => 100, cascade => TRUE, degree => 1);
but it matches oracle 12.1

Related

ORA-20024: REST enablement for maintained schema disallowed

I have set in ORDS without APEX when I try to enable the schema, I get an error. What am I doing wrong?
BEGIN
ORDS.ENABLE_SCHEMA(p_enabled => TRUE,
p_schema => 'DEVUSER',
p_url_mapping_type => 'BASE_PATH',
p_url_mapping_pattern => 'devuser',
p_auto_rest_auth => FALSE);
commit;
END;
Error report -
ORA-20024: REST enablement for maintained schema disallowed : DEVUSER
ORA-06512: на "ORDS_METADATA.ORDS", line 183
ORA-06512: на "ORDS_METADATA.ORDS_INTERNAL", line 281
ORA-06512: на "ORDS_METADATA.ORDS_INTERNAL", line 688
ORA-06512: на "ORDS_METADATA.ORDS_INTERNAL", line 640
ORA-06512: на "ORDS_METADATA.ORDS_INTERNAL", line 779
ORA-06512: на "ORDS_METADATA.ORDS", line 167
ORA-06512: на line 3
The most probable cause is because the schema has been created as an Oracle Maintained user. An Oracle Maintained user cannot be enabled for ORDS based REST services.
In order to correct this problem, you must delete and recreate the target schema.
1.To drop the user:
alter session set "_ORACLE_SCRIPT"=true;
drop user DEVUSER;
alter session set "_ORACLE_SCRIPT"=false;
2.Recreate the user:
create user DEVUSER identified by <PASSWORD>;
grant create session to <SCHEMA>;
Perform any other grants needed for this user. If you have data to save, export it first ( using Datapump, for example ) and import it back again.

ORA-01741 for DBMS_REDEFINITION with invisible fields and implicit constraints

I recently noticed an odd failure pattern recently in one database (12cR1) when using DBMS_REDEFINITION. CAN_REDEF_TABLE completes fine, as does START_REDEF_TABLE, but COPY_TABLE_DEPENDENTS fails with a bewildering:
ORA-01741: illegal zero-length identifier
After some debugging, the exception appears to be related to the ORIG_TABLE carrying both INVISIBLE column(s) and implicit system-named constraints. I'll include an example below to demonstrate the problem, but I hoped to gain some understanding of the behavior, and didn't see anything notable about INVISIBLE called out in the docs.
It seems there is some nuance to the creation of system-generated constraints I'd like to understand better. Apologies for the "why" question, but, Why do implicit system constraints behave any differently than explicitly-defined constraints during redefinition? I had thought that after being assigned a system-generated name, a constraint was just a constraint. Are system-generated objects different in other ways from client-named constraints beyond their names?
I also hoped to see if anyone has another workaround to recommend beyond just renaming implicit constraints or un-hiding the columns before the redifinition.
Thanks
Example:
Below are three versions of the same ORIG_TABLE for redefinition. The first two both undergo the far-below redefinition ok with the given INT_TABLE, but the third throws the ORA-01741 during COPY_TABLE_DEPENDENTS.
Version 1: All columns visible, implicit system-generated constraints:
CREATE TABLE REDEF_TARGET (
THE_KEY INTEGER NOT NULL PRIMARY KEY ,
THE_DATE DATE NOT NULL
);
Version 2: INVISIBLE column present, explicit constraint (given an absurd name here to poke at if DBMS_REDEFINITION is instrumenting existing names)
CREATE TABLE REDEF_TARGET (
THE_KEY INTEGER NOT NULL PRIMARY KEY ,
THE_DATE DATE INVISIBLE ,
CONSTRAINT SYS_C02583271 CHECK (THE_DATE IS NOT NULL)
);
Version 3: INVISIBLE column and implicit constraint both present
CREATE TABLE REDEF_TARGET (
THE_KEY INTEGER NOT NULL PRIMARY KEY ,
THE_DATE DATE INVISIBLE NOT NULL
);
Running either of the first against the below will work, while the third will fail during copy-deps.
CREATE TABLE REDEFINER (
THE_KEY INTEGER ,
THE_DATE DATE
);
DECLARE
V_NUM INTEGER;
BEGIN
DBMS_REDEFINITION.CAN_REDEF_TABLE(UNAME => USER , TNAME => 'REDEF_TARGET');
DBMS_REDEFINITION.START_REDEF_TABLE(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER');
DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER' , NUM_ERRORS => V_NUM);
DBMS_REDEFINITION.FINISH_REDEF_TABLE(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER');
END;
/
First of all you do not need to use NOT NULL with PRIMARY KEY clause. Get rid of such NOT NULLs.
Let's run your statement for version 3 on DB version 12cR1 as in your case :
Connected to Oracle Database 12c Enterprise Edition Release 12.1.0.2.0
Connected as hr
SQL> CREATE TABLE REDEF_TARGET (
2 THE_KEY INTEGER PRIMARY KEY ,
3 THE_DATE DATE INVISIBLE NOT NULL
4 );
Table created
SQL> CREATE TABLE REDEFINER(
2 THE_KEY INTEGER,
3 THE_DATE DATE
4 );
Table created
SQL> DECLARE
2 V_NUM INTEGER;
3 BEGIN
4 DBMS_REDEFINITION.CAN_REDEF_TABLE(UNAME => USER , TNAME => 'REDEF_TARGET');
5 DBMS_REDEFINITION.START_REDEF_TABLE(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER');
6 DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER' , NUM_ERRORS => V_NUM);
7 DBMS_REDEFINITION.FINISH_REDEF_TABLE(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER');
8 END;
9 /
ORA-01741: illegal zero-length identifier
ORA-06512: at "SYS.DBMS_REDEFINITION", line 1646
ORA-06512: at "SYS.DBMS_REDEFINITION", line 2502
ORA-06512: at "SYS.DBMS_REDEFINITION", line 3803
ORA-06512: at line 7
SQL> DROP TABLE REDEF_TARGET;
Table dropped
SQL> DROP TABLE REDEFINER;
DROP TABLE REDEFINER
ORA-12083: must use DROP MATERIALIZED VIEW to drop "HR"."REDEFINER"
SQL> DROP MATERIALIZED VIEW REDEFINER;
Materialized view dropped
SQL> DROP TABLE REDEFINER;
Table dropped
SQL> CREATE TABLE REDEF_TARGET (
2 THE_KEY INTEGER PRIMARY KEY ,
3 THE_DATE DATE INVISIBLE NOT NULL
4 );
Table created
SQL> CREATE TABLE REDEFINER(
2 THE_KEY INTEGER,
3 THE_DATE DATE INVISIBLE
4 );
Table created
SQL> DECLARE
2 V_NUM INTEGER;
3 BEGIN
4 DBMS_REDEFINITION.CAN_REDEF_TABLE(UNAME => USER , TNAME => 'REDEF_TARGET');
5 DBMS_REDEFINITION.START_REDEF_TABLE(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER');
6 DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER' , NUM_ERRORS => V_NUM);
7 DBMS_REDEFINITION.FINISH_REDEF_TABLE(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER');
8 END;
9 /
ORA-01741: illegal zero-length identifier
ORA-06512: at "SYS.DBMS_REDEFINITION", line 1646
ORA-06512: at "SYS.DBMS_REDEFINITION", line 2502
ORA-06512: at "SYS.DBMS_REDEFINITION", line 3803
ORA-06512: at line 7
and DB version 12cR2 :
Connected to Oracle Database 12c Enterprise Edition Release 12.2.0.1.0
Connected as hr
SQL> CREATE TABLE REDEF_TARGET (
2 THE_KEY INTEGER PRIMARY KEY ,
3 THE_DATE DATE INVISIBLE NOT NULL
4 );
Table created
SQL> CREATE TABLE REDEFINER(
2 THE_KEY INTEGER,
3 THE_DATE DATE
4 );
Table created
SQL> DECLARE
2 V_NUM INTEGER;
3 BEGIN
4 DBMS_REDEFINITION.CAN_REDEF_TABLE(UNAME => USER , TNAME => 'REDEF_TARGET');
5 DBMS_REDEFINITION.START_REDEF_TABLE(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER');
6 DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER' , NUM_ERRORS => V_NUM);
7 DBMS_REDEFINITION.FINISH_REDEF_TABLE(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER');
8 END;
9 /
ORA-042067: invalid column mapping with invisible columns on original or interim table
ORA-06512: at "SYS.DBMS_REDEFINITION", line 109
ORA-06512: at "SYS.DBMS_REDEFINITION", line 3887
ORA-06512: at "SYS.DBMS_REDEFINITION", line 5208
ORA-06512: at line 5
SQL> DROP TABLE REDEF_TARGET;
Table dropped
SQL> DROP TABLE REDEFINER;
Table dropped
SQL> CREATE TABLE REDEF_TARGET (
2 THE_KEY INTEGER PRIMARY KEY ,
3 THE_DATE DATE INVISIBLE NOT NULL
4 );
Table created
SQL> CREATE TABLE REDEFINER(
2 THE_KEY INTEGER,
3 THE_DATE DATE INVISIBLE
4 );
Table created
SQL> DECLARE
2 V_NUM INTEGER;
3 BEGIN
4 DBMS_REDEFINITION.CAN_REDEF_TABLE(UNAME => USER , TNAME => 'REDEF_TARGET');
5 DBMS_REDEFINITION.START_REDEF_TABLE(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER');
6 DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER' , NUM_ERRORS => V_NUM);
7 DBMS_REDEFINITION.FINISH_REDEF_TABLE(UNAME => USER , ORIG_TABLE => 'REDEF_TARGET' , INT_TABLE => 'REDEFINER');
8 END;
9 /
PL/SQL procedure successfully completed.
So, Results follow :
Version 12c Release 1 suppresses the main problem of being
ORA-042067 instead of ORA-01741. So, INVISIBLE option needed to be added for THE_DATE (DATE) column of REDEFINER table for true column mappings between original and interim tables.
Even if INVISIBLE option added for above mentioned column, you'll
get still the same error code ( ORA-01741 ) for version R1, while
you'll be successful for version R2. So, upgrade seems to be
necessary.
By the way every time we try to drop REDEFINER table, materialized
view needed to be dropped for R1, but no for R2. Interesting, might be a bug ...
it seems due to oracle bug.the bug is fixed on oracle 12.2.
the following is some key information:
Bug 17871192 : ILM POLICY FAILS WITH ORA-01741 ON TABLE WITH INVISIBLE COLUMN
PROBLEM:
An ADO Policy on a table with added invisible not null default column fails
with the following message:
ORA-12012: error on auto execute of job "SYS"."ILMJOB2628"
ORA-1741: illegal zero-length identifier
ORA-6512: at "SYS.DBMS_REDEFINITION", line 2525
DIAGNOSTIC ANALYSIS:
To reproduce, you need a table which had a column with the following command
added:
alter table "ILMT3" add "C4" varchar2 (10) invisible default ' ' not null;
All three attributes are needed to reproduce.
WORKAROUND:
Dont use one of the attributes
RELEASE NOTES:
]] INVISIBLE COLUMN metadata is missing.
REDISCOVERY INFORMATION:
In INVISIBLE COLUMN column name is missing then you are hitting this issue.

How to analyze a table using DBMS_STATS package in PL/SQL?

Here's the code I'm working on:
begin
DBMS_STATS.GATHER_TABLE_STATS (ownname => 'appdata' ,
tabname => 'TRANSACTIONS',
cascade => true,
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
method_opt=>'for all indexed columns size 1',
granularity => 'ALL',
degree => 1);
end;
After executing the code, PL/SQL procedure successfully completed is displayed.
How to view the statistics for the particular table, analyzed by DBMS_STATS ?
You may see information in DBA_TABLES
SELECT *
FROM DBA_TABLES where table_name='TRANSACTIONS';
e.g. Column LAST_ANALYZED shows when it was last analyzed.
There are also information column by column in
SELECT * FROM all_tab_columns where table_name='TRANSACTIONS';
where you could find min value, max value, etc.

Can not delete Metadata entry in Spatial DB

I am trying to a spatial data table in my db using :
CREATE TABLE building (buildid VARCHAR(15) PRIMARY KEY, buildname VARCHAR(50),numpoint NUMBER,points SDO_GEOMETRY);
CREATE INDEX building_spatial_idx ON building(points) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
INSERT INTO USER_SDO_GEOM_METADATA(TABLE_NAME,COLUMN_NAME,DIMINFO,SRID)
VALUES (
'building',
'points',
SDO_DIM_ARRAY( --820*580 grid
SDO_DIM_ELEMENT('X', 0, 820, 1),
SDO_DIM_ELEMENT('Y', 0, 580, 1)
),
NULL --SRID
);
When I executed it for the first time it did not give any errors but afterwords it is giving error
insert into user_sdo_geom_metadata values
*
ERROR at line 1:
ORA-00001: unique constraint (MDSYS.UNIQUE_LAYERS) violated
ORA-06512: at "MDSYS.SDO_GEOM_TRIG_INS1", line 27
ORA-04088: error during execution of trigger 'MDSYS.SDO_GEOM_TRIG_INS1'
Is it happening because am trying to give meta-data for same table again.
Or is there any other reason. How can i delete all the index,metadata,table at a single go and remove this error.
A new Schema creation solved the problem,

Associating job with job class

I'm attempting to create a job using DBMS_SCHEDULER in an Oracle 11g DB but having some trouble setting the job class attribute. I have already looked in the SYS schema and there is a job class named "SCHED$_LOG_ON_ERRORS_CLASS" that only outputs to the log if a job fails, which is what I want instead of having it log every time the job succeeds. Here is the script I am using to create the job:
BEGIN
DBMS_SCHEDULER.CREATE_JOB(
job_name => 'DIRXML.CHECK_EVENTLOG',
job_type => 'STORED_PROCEDURE',
job_action => 'DIRXML.P_Check_Eventlog',
job_class => 'DIRXML.SCHED$_LOG_ON_ERRORS_CLASS',
repeat_interval => 'FREQ=SECONDLY;INTERVAL=30',
enabled => TRUE
);
END;
/
The script will execute without errors if I remove the job_class attribute but when I add it I get the following error:
ORA-27476: "SYS.SCHED$_LOG_ON_ERRORS_CLASS" does not exist ORA-06512:
at "SYS.DBMS_ISCHED", line 124 ORA-06512: at "SYS.DBMS_SCHEDULER",
line 271 ORA-06512: at line 2
The only thing I could think of is that permissions aren't set up correctly for my user?
It looks like there wasn't a public execute grant on that specific job class, which explains why it wasn't finding it.

Resources