ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout

ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout

KUP-11024: This external table can only be accessed from within a Data Pump job.

Alert Log details: 

Trace file details:

Cause:

The primary cause of this issue is that an external table existed at some point in time but does not now. However, the database still believes the table exists since the dictionary information about the object has not been modified to reflect the change. When DBMS_STATS is run against the table in question, it makes a call out to the external table which fails because the object is not there.

There are many reasons that an external table may not exist including:

• - Temporary Datapump external tables have not been cleaned up properly. The dictionary information should have been dropped when the DataPump jobs completed.
• - An OS file for an External table has been removed without clearing up the corresponding data dictionary information. 
• Solution:
• Essentially the solution to this issue is to clean up the orphaned dictionary entries.
• SELECT owner_name, job_name, operation, job_mode, state, attached_sessions FROM dba_datapump_jobs WHERE job_name NOT LIKE 'BIN$%' ORDER BY 1,2;
• or 
• select OWNER,OBJECT_NAME,OBJECT_TYPE, status,
  to_char(CREATED,'dd-mon-yyyy hh24:mi:ss') created
  ,to_char(LAST_DDL_TIME , 'dd-mon-yyyy hh24:mi:ss') last_ddl_time
  from dba_objects
  where object_name like 'ET$%'
  /
  
  select owner, TABLE_NAME, DEFAULT_DIRECTORY_NAME, ACCESS_TYPE
  from dba_external_tables
  order by 1,2
  /
• 
  Drop external temporary table
• 
  Ref. Doc: ID 1274653.1

How to get Scheduled jobs information in Oracle?

SQL> select TABLE_NAME from dict where table_name like 'DBA_SCHEDULER_JOB%';

DBA_SCHEDULER_JOBS
DBA_SCHEDULER_JOB_ARGS
DBA_SCHEDULER_JOB_CLASSES
DBA_SCHEDULER_JOB_DESTS
DBA_SCHEDULER_JOB_LOG
DBA_SCHEDULER_JOB_ROLES
DBA_SCHEDULER_JOB_RUN_DETAILS

SQL> select TABLE_NAME from dict where table_name like 'ALL_SCHEDULER_JOB%';

ALL_SCHEDULER_JOBS
ALL_SCHEDULER_JOB_ARGS
ALL_SCHEDULER_JOB_CLASSES
ALL_SCHEDULER_JOB_DESTS
ALL_SCHEDULER_JOB_LOG
ALL_SCHEDULER_JOB_RUN_DETAILS

To See All Scheduled Jobs

 select owner, job_name, state from all_scheduler_jobs;

To Check all scheduled jobs for a particular user

select owner, job_name, state from all_scheduler_jobs where owner ='XXX';

To See Job Run Details

 select LOG_ID, LOG_DATE, JOB_NAME, STATUS from ALL_SCHEDULER_JOB_RUN_DETAILS where job_name ='JOB_AUTOCLOSE_QUEUE';

Enable / Disable a job

BEGIN
  DBMS_SCHEDULER.ENABLE('myjob');
END;
BEGIN
  DBMS_SCHEDULER.DISABLE('myjob');
END;


The DBA views are restricted. So you won't be able to query them unless you're connected as a DBA or similarly privileged user.
The ALL views show you the information you're allowed to see. Normally that would be jobs you've submitted, unless you have additional privileges.

To extract DDL of Scheduled Job

select dbms_metadata.get_ddl('PROCOBJ', 'JOB_AUTOCLOSE_QUEUE') from dual;

Oracle User Privileges: How to See All Privileges for a User

Querying DBA/USER Privilege Views

A database administrator (DBA) for Oracle can simply execute a query to view the rows in DBA_SYS_PRIVS, DBA_TAB_PRIVS, and DBA_ROLE_PRIVS to retrieve information about user privileges related to the system, tables, and roles, respectively.

To view all system privileges granted to all users would issue the following query:

SELECT  * FROM  DBA_SYS_PRIVS;

The DBA_SYS_PRIVS view contains three columns of data:

GRANTEE is the name, role, or user that was assigned the privilege.
PRIVILEGE is the privilege that is assigned.
ADMIN_OPTION indicates if the granted privilege also includes the ADMIN option.

To determine which users have direct grant access to a table we’ll use the DBA_TAB_PRIVS view:

SELECT  * FROM  DBA_TAB_PRIVS;

Important columns are:

GRANTEE is the name of the user with granted access.
TABLE_NAME is the name of the object.
PRIVILEGE is the privilege assigned to the GRANTEE for the associated object.
 
Finally, querying the DBA_ROLE_PRIVS view has much of the same information but applicable to roles instead, where the GRANTED_ROLE column specifies the role in question:

SELECT  * FROM  DBA_ROLE_PRIVS;
 
TO KNOW CURRENT USER’S PRIVILEGES

To view the privileges solely for the current user.

This is done by alternatively querying USER_ versions of the above DBA_ views. Thus, instead of looking at DBA_SYS_PRIVS we’d query USER_SYS_PRIVS, like so:

SELECT  * FROM  USER_SYS_PRIVS;

Since the USER_ privilege views are effectively the same as their DBA_ counterparts, but specific to the current user only, the type of returned data and column names are all identical to those when querying DBA_ views intead.

Which session is generating the redo ?

select username, sid, value, sql_id, prev_sql_id
from ( select username,s.sid, value, sql_id, prev_sql_id 
from v$session u, v$sesstat s, v$statname n
where n.name = 'redo size'
and s.statistic# = n.statistic#
and u.sid = s.sid order by value desc )
where rownum <= 10
order by value desc
/

User privilege for kill session

1) please create in sys ( login as sysdba)
-------------------------------------------------
create or replace procedure sys.kill_session
(
p_sid NUMBER
,p_serial# NUMBER
) AS
m_sql VARCHAR2(1000);
m_loginusername VARCHAR2(30);
m_killusername VARCHAR2(30);
m_schemaname varchar2(30);
BEGIN
SELECT a.USERNAME,
a.SCHEMANAME
INTO m_killusername,
m_schemaname
FROM v$session a
WHERE a.sid = p_sid
AND a.serial# = p_serial#;
select user
into m_loginusername
from dual;
IF m_loginusername = m_killusername AND
m_schemaname NOT IN ('SYS', 'SYSTEM')
THEN
m_sql := 'ALTER SYSTEM KILL SESSION ' || '''' || p_sid || ',' ||
p_serial# || '''' || ' IMMEDIATE';
EXECUTE IMMEDIATE m_sql;
dbms_output.put_line('Session Killed ');
ELSE
dbms_output.put_line(' Login User Name ' || m_loginusername ||
' User Session to Kill ' ||m_killusername);
dbms_output.put_line('Cannot kill session of other users or Admin users');
raise_application_error(-20101,'Cannot kill session of other users or Admin users or self');
END IF;
EXCEPTION
WHEN OTHERS THEN
dbms_output.put_line('Error in Kill Session.' ||SQLERRM(SQLCODE));
END kill_session;
------------------------------------------------------
2) grant execute on kill_seesion to suh;
3) grant select on v_$session to suh;
4) login as suh/suh
5) select a.sid, a.serial#
from v$session a
where username = 'SUH'
/
6) exec kill_session ( sid,serial#)
7) exec kill_session(18,3320);

Calculate UNDO_RETENTION for given UNDO Tabespace

UNDO_RETENTION is a parameter in the init.ora initialization parameters file that specifies the time period in seconds for which a system retains undo data for committed transactions. The flashback query can go upto the point of time specified as a value in the UNDO_RETENTION parameter.

Optimal Undo Retention =
           Actual Undo Size / (DB_BLOCK_SIZE × UNDO_BLOCK_REP_ESC)

Actual Undo Size

SELECT SUM(a.bytes) "UNDO_SIZE"
FROM v$datafile a,
       v$tablespace b,
       dba_tablespaces c
WHERE c.contents = 'UNDO'
   AND c.status = 'ONLINE'
   AND b.name = c.tablespace_name
   AND a.ts# = b.ts#;

Undo Blocks per Second

SELECT MAX(undoblks/((end_time-begin_time)*3600*24)) "UNDO_BLOCK_PER_SEC"
FROM v$undostat;

DB Block Size

SELECT TO_NUMBER(value) "DB_BLOCK_SIZE [KByte]"
FROM v$parameter
WHERE name = 'db_block_size';

Optimal Undo Retention Calculation

Formula:
Optimal Undo Retention = 
           Actual Undo Size / (DB_BLOCK_SIZE × UNDO_BLOCK_REP_ESC)

Using Inline Views, you can do all calculation in one query

SQL Code:
SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
    SUBSTR(e.value,1,25)    "UNDO RETENTION [Sec]",
    ROUND((d.undo_size / (to_number(f.value) *
    g.undo_block_per_sec)))"OPTIMAL UNDO RETENTION [Sec]"
  FROM (
       SELECT SUM(a.bytes) undo_size
          FROM v$datafile a,
               v$tablespace b,
               dba_tablespaces c
         WHERE c.contents = 'UNDO'
           AND c.status = 'ONLINE'
           AND b.name = c.tablespace_name
           AND a.ts# = b.ts#
       ) d,
       v$parameter e,
       v$parameter f,
       (
       SELECT MAX(undoblks/((end_time-begin_time)*3600*24))undo_block_per_sec
       FROM v$undostat
       ) g
WHERE e.name = 'undo_retention'
  AND f.name = 'db_block_size'

Calculate Needed UNDO Size for given Database Activity

If you are not limited by disk space, then it would be better to choose the UNDO_RETENTION time that is best for you (for FLASHBACK, etc.). Allocate the appropriate size to the UNDO tablespace according to the database activity:

Formula:
Undo Size = Optimal Undo Retention × DB_BLOCK_SIZE × UNDO_BLOCK_REP_ESC
Using Inline Views, you can do all calculation in one query

SQL Code:
SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
       SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
       (TO_NUMBER(e.value) * TO_NUMBER(f.value) *
       g.undo_block_per_sec) / (1024*1024)
      "NEEDED UNDO SIZE [MByte]"
  FROM (
       SELECT SUM(a.bytes) undo_size
         FROM v$datafile a,
              v$tablespace b,
              dba_tablespaces c
        WHERE c.contents = 'UNDO'
          AND c.status = 'ONLINE'
          AND b.name = c.tablespace_name
          AND a.ts# = b.ts#
       ) d,
      v$parameter e,
      v$parameter f,
       (
       SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
         undo_block_per_sec
         FROM v$undostat
       ) g
 WHERE e.name = 'undo_retention'
  AND f.name = 'db_block_size'

Top 99 Responsibilities of a DBA

Database Architecture Duties

1. Planning for the database's future storage requirements
2. Defining database availability and fault management architecture
3. Defining and creating environments for development and new release installation
4. Creating physical database storage structures after developers have designed an application
5. Constructing the database
6. Determining and setting the size and physical locations of datafiles
7. Evaluating new hardware and software purchase
8. Researching, testing, and recommending tools for Oracle development, modeling, database administration, and backup and recovery implementation, as well as planning for the future
9. Providing database design and implementation
10. Understanding and employing the optimal flexible architecture to ease administration, allow flexibility in managing I/O, and to increase the capability to scale the system
11. Working with application developers to determine and define proper partitioning

Backup and Recovery

12. Determining and implementing the backup/recovery plan for each database while in development and as the application moves through test and onto production
13. Establishing and maintaining sound backup and recovery policies and procedures
14. Having knowledge and practice of Oracle backup and recovery scenarios
15. Performing Oracle cold backups when the database is shut down to ensure consistency of the data
16. Performing Oracle hot backups while the database is operational
17. Performing Oracle import/export as a method of recovering data or individual objects
18. Providing retention of data to satisfy legal responsibilities of the company
19. Restoring database services for disaster recovery
20. Recovering the database in the event of a hardware or software failure
21. Using partitioning and transportable tablespaces to reduce downtime, when appropriate

Maintenance and Daily Tasks

22. Providing adjustment and configuration management of INIT.ORA
23. Adjusting extent size of rapidly growing tables and indexes
24. Administering database-management software and related utilities
25. Automating database startup and shutdown
26. Automating repetitive operations
27. Determining and setting critical thresholds for disk, tablespaces, extents, and fragmentation
28. Enrolling new users while maintaining system security
29. Filtering database alarm and alert information
30. Installing, configuring, and upgrading Oracle server software and related products installation
31. Logging Technical Action Reports (TARs); applying patches
32. Maintaining the "Database Administrator's Handbook"
33. Maintaining an ongoing configuration for database links to other databases
34. Maintaining archived Oracle data
35. Managing contractual agreements with providers of database-management software
36. Managing service level agreements with Oracle consultants or vendors
37. Monitoring and advising management on licensing issues while ensuring compliance with Oracle license agreements
38. Monitoring and coordinating the update of the database recovery plan with the site's disaster recovery plan
39. Monitoring and optimizing the performance of the database
40. Monitoring rollback segment and temporary tablespace use
41. Monitoring the status of database instances
42. Performing housekeeping tasks as required; purging old files from the Oracle database
43. Performing database troubleshooting
44. Performing modifications of the database structure from information provided by application developers
45. Performing monthly and annual performance reports for trend analysis and capacity planning
46. Installing new and maintaining existing client configurations
47. Performing ongoing configuration management
48. Performing ongoing Oracle security management
49. Performing routine audits of user and developer accounts
50. Performing translation of developer modeled designs for managing data into physical implementation
51. Performing correlation of database errors, alerts, and events
52. Planning and coordinating the testing of the new database, software, and application releases
53. Providing a focal point on calls to Oracle for technical support
54. Working as part of a team and providing 24x7 support when required

Methodology and Business Process

55. Coordinating and executing database upgrades
56. Coordinating upgrades of system software products to resolve any Oracle/operating system issues/conflicts
57. Creating error and alert processes and procedures
58. Creating standard entry formats for SQLNet files
59. Creating processes and procedures for functional and stress testing of database applications
60. Creating processes and procedures of application transport from DEV, to TEST, to PROD
61. Defining and maintaining database standards for the organization to ensure consistency in database creation
62. Defining database standards and procedures to cover the instance parameters, object sizing, storage, and naming. The procedures define the process for install/upgrade, corporate database requirements, security, backup/recovery, applications environment, source code control, change control, naming conventions, and table/index creation.
63. Defining the database service levels necessary for application availability
64. Defining methodology tasks for database software integration
65. Defining a methodology for developing and improving business applications
66. Creating a process to determine whether a new release is "stable" enough to be placed on the development system
67. Developing data-conversion processes for customization, testing, and production
68. Developing database test plans
69. Developing database administration procedures and responsibilities for production systems
70. Developing production migration procedures
71. Establishing and providing schema definitions, as well as tablespace, table, constraint, trigger, package, procedure, and index naming conventions
72. Facilitating design sessions for requirements gathering and defining system requirements
73. Providing database problem reporting, management, and resolution
74. Providing final approval for all technical architecture components that manage and exchange data, including database management software, serve hardware, data distribution management software, server hardware, data distribution management software, transaction processing monitors, and connecting client applications software
75. Providing processes for the setup of new database environments
76. Providing risk and impact analysis of maintenance or new releases of code
77. Providing standards and methods for database software purchasing
78. Providing standards and naming conventions
79. Handling multiple projects and deadlines

Education and Training

80. Attending training classes and user group conferences
81. Evaluating Oracle features and Oracle-related products
82. Understanding the Oracle database, related utilities, and tools
83. Understanding the underlying operating system as well as the design of the physical database
84. Understanding Oracle data integrity
85. Knowing the organization's applications and how they map to the business requirements
86. Knowing how Oracle acquires and manages resources
87. Knowing enough about the Oracle tool's normal functional behavior to be able to determine whether a problem lies with the tool or the database
88. Processing sound knowledge in database and system performance tuning
89. Providing in-house technical consulting and training
90. Staying abreast of the most current release of Oracle software and compatibility issues
91. Subscribing to database trade journals and web sources

Communication

92. Interfacing with vendors
93. Disseminating Oracle information to the developers, users, and staff
94. Training application developers to understand and use Oracle concepts, techniques, and tools that model and access managed data
95. Assisting developers with database design issues and problem resolutions, including how to run and understand the output from both TKProf and the Explain Plan utilities
96. Training interim DBAs and junior-level DBAs

Documentation

97. Creating and maintaining a database operations handbook for frequently performed tasks
98. Defining standards for database documentation
99. Creating documentation of the database environment

Source - http://appsdbaportal.blogspot.com/2009/04/top-99-responsibilities-of-dba.html