removing oracle datapump job

you may run into situations where you need to stop an expdp or impdp job from running. killing the datapump process from the Operating System level won’t stop the job , infact if you use the below query you may still see it in “RUNNING” state.

SQL> select * from dba_datapump_jobs;

SOOOOOO you need to kill the datapump job from database-level as follows:

$ORACLE_HOME/bin/expdp “‘/as sysdba'” attach=SYS.”‘EXPORT_TABLE_NAME‘”

Export> KILL_JOB

Are you sure you wish to stop this job ([yes]/no): yes

Check it again :

select job_name,owner_name,state from dba_datapump_jobs;

Remark: EXPORT_TABLE_NAME is the table name resulted in the query unser SYS account.

SELECT ANY DICTIONARY in Oracle 12c

As part of new Oracle 12c Database security implementation, they have stripped the system privilege ” SELECT ANY DICTIONARY ” from accessing the following SYS tables: USER$, ENC$,DEFAULT_PWD$, LINK$, USER_HISTORY$, CDB_LOCAL_ADMINAUTH$, XS$VERIFIERS.

The reason they removed access from these tables, is just in case you grant “select any dictionary” to a non-dba account, this account wont be able to see the “hashed passwords”. Only the SYS account will be able to query these tables.

in 12c if you simulate that:

sqlplus

SQL> grant select any dictionary to account1;

exit

sqlplus account1/password@DB1

SQL> select * from SYS.USER$;

ORA-01031: insufficient privileges

Bingo……..you can’t query USER$ table although you are granted the “select any dictionary” privilege.

TOAD ORA-01031: insufficient privileges when connecting to Oracle 12c

An issue  faced is that when we try to connect from TOAD (version: 11.6 ) to a newly upgraded Oracle database 12c we faced the error:

ORA-01031: insufficient privileges

TOAD Error Message ORA-01031

The reason we are facing this problem, is the newly security implementation by Oracle in 12c for the system privilege SELECT ANY DICTIONARY. They have stripped this system privilege from accessing the following tables:USER$, ENC$,DEFAULT_PWD$, LINK$, USER_HISTORY$, CDB_LOCAL_ADMINAUTH$, XS$VERIFIERS

The current TOAD version checks the old (SELECT ANY DICTIONARY) which already has this table SYS.USER$ part of its permission when it can’t access this table, it throws the error message:  ORA-01031

The reason in 12c they stripped those tables from “SELECT ANY DICTIONARY” is to protect the passwords in case this privilege is granted to non-DBA account , so the hashed passwords are not exposed (ONLY SYS account can query those tables).

So, to let the current version of TOAD works for 12c execute the following sql query:

SQL> grant select on sys.user$ to database_account;

Hope This Helps 😉

thumps_up

ORA-00604: error occurred at recursive SQL level 4 ORA-12751: cpu time or run time policy violation

while checking my database, i noticed there is a performance issue. So, to investigate further i have checked the alert log file.

(Remark: you can check the location of your alert log file using the query: select * from v$diag_info; )

the below is the contents of the log file

****************************************************************************************************

ORA-00604: error occurred at recursive SQL level 4
ORA-12751: cpu time or run time policy violation
Mon Jan 26 02:52:36 2015
Suspending MMON slave action ketbgac2_ for 82800 seconds
Mon Jan 26 03:02:37 2015
Suspending MMON slave action ketbgac1_ for 82800 seconds
Mon Jan 26 05:01:38 2015
Suspending MMON slave action kdilmclnslv_ for 82800 seconds
Mon Jan 26 06:23:43 2015
Errors in file /oraclex/oradbp61/diag/rdbms/oradbp61/oradbp61/trace/oradbp61_m00b_44433466.trc:
ORA-00604: error occurred at recursive SQL level 4
ORA-12751: cpu time or run time policy violation
Mon Jan 26 06:49:41 2015

************************************************************************************************

To Resolve this:

you need to monitor and check the performance of the server where database is hosted in.

also, you can try to figure out the SQL statement that is taking a long time to process.

in my situation, when trying to establish sqlplus from within the server the, sqlplus was in state of “hanging ”

so the only solution was to forcefully shutdown the database by killing the core Oracle Process.

Unix Command:

ps –ef | grep smon

Oracle 12c EXPDP eror ORA-21700 ORA-06512 ORA-06512

while upgrading Oracle database from version 11.2.0.3 to 12.1.0.1 successfully, i found out the below errors while performing a full database export for the new upgraded 12cR1 database:

ERROR at line 1:

ORA-21700: object does not exist or is marked for delete

ORA-06512: at “SYS.ANYDATA”, line 174

ORA-06512: at “SYS.DBMS_SCHEDULER”, line 3583

why is this happening 😐  ??!

The reason i am facing this error is that Oracle Data Mining Modules (ODM) are not hosted in a separate schema “DMSYS” anymore when upgrading from 11.2.0.x to 11.2.0.3 or even from 10g  !! (which should have been dropped while upgrading  My Mistake 😦   )

Remark: Data Mining models are implemented as data dictionary objects in the SYS schema

To Correct this , you have either 2 ways:

********* First solutions:

Drop the DMSYS schema in the 11g database.

SQL> CONNECT / AS SYSDBA;
SQL> DROP USER DMSYS CASCADE;
SQL> DELETE FROM SYS.EXPPKGACT$ WHERE SCHEMA = ‘DMSYS’;
SQL> SELECT COUNT(*) FROM DBA_SYNONYMS WHERE TABLE_OWNER = ‘DMSYS’;

* if the previous query returns results then perform the following:

SQL> SET HEAD OFF
SQL> SPOOL dir_path/DROP_DMSYS_SYNONYMS.SQL
SQL> SELECT ‘Drop public synonym ‘ ||'”‘||SYNONYM_NAME||'”;’ FROM DBA_SYNONYMS
WHERE TABLE_OWNER = ‘DMSYS’;
SQL> SPOOL OFF
SQL> @dir_path/DROP_DMSYS_SYNONYMS.SQL
SQL> EXIT;

*********  Second Solution:

perform the following in the upgraded 12c database.

connect / as sysdba
exec dbms_scheduler.drop_program(‘JDM_BUILD_PROGRAM’);
exec dbms_scheduler.drop_program(‘JDM_EXPLAIN_PROGRAM’);
exec dbms_scheduler.drop_program(‘JDM_EXPORT_PROGRAM’);
exec dbms_scheduler.drop_program(‘JDM_IMPORT_PROGRAM’);
exec dbms_scheduler.drop_program(‘JDM_PREDICT_PROGRAM’);
exec dbms_scheduler.drop_program(‘JDM_PROFILE_PROGRAM’);
exec dbms_scheduler.drop_program(‘JDM_SQL_APPLY_PROGRAM’);
exec dbms_scheduler.drop_program(‘JDM_TEST_PROGRAM’);
exec dbms_scheduler.drop_program(‘JDM_XFORM_PROGRAM’);
exec dbms_scheduler.drop_program(‘JDM_XFORM_SEQ_PROGRAM’);

ORA-04031: unable to allocate 3896 bytes of shared memory

I have faced the below error in Oracle 11gR2 (11.2.0.3) release.

ORA-04031: unable to allocate 3896 bytes of shared memory (“shared pool”,”ALTER

DATABASE CLOSE NORMAL”,”sga heap(1,0)”,”kglsim object batch”)

this error indicates that you need to re-adjust your SGA memory in your database.

To Resolve this problem:

You need to increase the size of the shared_pool_size &  java_pool_size in your init.ora file

Then you need to reboot your database after changing the parameters.

Hope This Helps

In-Memory Database Management Certificate (Open HPI)

I am please to announce that i have taken the Open HPI course and passed the quizzes + Final Exam and rewarded with ‘Record of Achievement’ .

openHPI is a platform for massive open online courses (MOOC) in the field of computer science and information technology. It is hosted at the Hasso Plattner Institute (HPI) in Potsdam, Germany. openHPI is open for everyone, participation is free of costs. Everybody can register and enroll for courses without any prerequisites. openHPI’s courses are derived from HPI’s bachelor and master programs in IT-Systems Engineering and cover both, foundations of information technology as well as highly topical innovations.

The Course was  taught by Prof. Hasso Plattner ( He is the Co-founder of SAP-AG Company and currently Chairman of the company), he is the person who envisioned SAP HANA and saw the importance of in-memory database in Enterprise Systems. He is an AMAZING pioneer & very well in teaching !!

My Certificate:

OpenHPI Certificate - In-Memory Data Management Implications on Enterprise Systems
OpenHPI Certificate – In-Memory Data Management Implications on Enterprise Systems

For certificate verification and authentication:

https://open.hpi.de/verify/xuhip-luvum-setin-lyheh-garop

The Course is amazing and beneficial for DBA’s, IT Professionals, Project Managers, Enterprise System Architects.

Cheers.

🙂

EXPDP ORA-31693 ORA-02354 ORA-01555

while taking an export  (my Oracle Release is 11.2.0.3), i have faced with the below errors in the log file:

Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
ORA-31693: Table data object “TESTSCHMA”.”VALUE_TABLE” failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old: rollback segment number 9 with name “_SYSSMU9_2795927347$” too small

To Resolve this problem perform the following:

sqlplus

SQL>set pages 1000
SQL>set lines 300
SQL> show parameter undo;

NAME TYPE VALUE
———————————— ———– ——————————
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
increase the undo_retention size:

SQL> alter system set undo_retention = 16500 scope = BOTH;

The LOB “retention” will not change automatically for LOB segements to verify this use the below query:

select table_name, column_name, nvl(retention, 0) retention, pctversion from dba_lobs where OWNER=’TESTSCHMA’;

To find all columns that have lobs use the following query:

select table_name, column_name from dba_lobs where OWNER=’TESTSCHMA’;

Then, use the “alter” command to change invidually each lob:

SQL> alter table TESTSCHMA.GRID_TABLE modify lob (SQLSTATEMENT) (retention);

Oracle Patch Update for October 2014 and ArcSDE Geodatabase

if you have applied the latest Oracle Security Patches released in October 2014 to your enterprise database. You need to roll back the patch OR grant elevated permissions.

for myself, i have granted each geodatabase user the “select” permission to the view “v_$parameter” and it fixed the problem. Of course, this is a workaround but not advisable implementation from security perspective since the normal oracle/geodaabase account should not have permission on this view.

The Bug ID Number is: BUG-000082555

ESRI Link for this issue: http://support.esri.com/en/knowledgebase/techarticles/detail/43293/

i will update my blog  whenever esri provides a permanent fix.

Update **** 11 November 2014 ****

Esri Provided a patch fixing the issue for multiple ArcGIS Versions:

http://support.esri.com/en/downloads/patches-servicepacks/view/productid/67/metaid/2143

Good Luck,