Monday, February 29, 2016

Oracle Error Codes

Oracle Error Codes




















































ORA-01436

Exception
ORA-01436: CONNECT BY loop in user data

Reason
An infinite loop was created by the condition specified in the CONNECT BY clause.
Resolution
Check the SQL and confirm is there any connect by result will cause infinite loops.



Thursday, February 25, 2016

Solving Maximum Open Cursors in Oracle


o   Exception
java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
ORA-01000: maximum open cursors exceeded ORA-00604: error occurred at recursive SQL level 1

o    Introduction
For every SQL statement execution in Oracle Database, certain area in the memory is allocated. Oracle PL/SQL allows you to name this area. This private SQL area is called context area or cursor. These cursors take up space in the shared pool, which is essential memory component of Oracle Database, specifically in the library cache. To keep a renegade session from filling up the library cache or clogging the CPU with millions of parse requests, the OPEN_CURSORS database parameter must be set to limit the cursors.
The OPEN_CURSORS parameter sets the maximum number of cursors that each session can have open, per session. For example, if the value of OPEN_CURSORS is set to 1000, then each session can have up to 1000 cursors open at one time.

o    Troubleshooting 
1.    Get the session id having high number of open cursors count using following SQL.
  SELECT s.username,
         s.sid,
         s.serial#,
         a.VALUE open_cursor_count
    FROM v$sesstat a, v$statname b, v$session s
   WHERE a.statistic# = b.statistic# AND s.sid = a.sid AND b.name = 'opened cursors current' AND s.username IS NOT NULL
ORDER BY a.VALUE DESC;

2.    Get the SQL which opens most cursors for the top session in above query.
  SELECT a.sql_id, b.sql_fulltext, a.open_cursors
    FROM (  SELECT sql_id, COUNT (1) open_cursors
              FROM v$open_cursor
             WHERE sid = 913
          GROUP BY sql_id) a,
         gv$sqlarea b
   WHERE a.sql_id = b.sql_id
ORDER BY a.open_cursors DESC;
            We will get the top queries which are opened but not closed. Usually implicit cursors are closed immediately by Oracle itself. But the cursors which are opened explicitly through PL/SQL or java Statement object should be closed by program itself. So we need to verify that we are closing the SQL statements from the above query output properly.

3.    Also monitor the current higher value and configured value through following query.
    SELECT MAX (a.VALUE) AS highest_open_cur, p.VALUE AS max_open_cur
    FROM v$sesstat a, v$statname b, v$parameter p
   WHERE a.statistic# = b.statistic# AND b.name = 'opened cursors current' AND p.name = 'open_cursors'
GROUP BY p.VALUE;
                If the configured value is not adequate then increase the open_cursor_count with following SQL statement.

ALTER SYSTEM SET open_cursors=1500;

Tuesday, February 9, 2016

Materialized Views in Oracle


Materialized views are used to refresh the contents of a source table data in regular interval or on-demand. It's previously known as snapshot.

Basic Syntax
CREATE MATERIALIZED VIEW <view-name>

BUILD [IMMEDIATE | DEFERRED]

REFRESH [FAST | COMPLETE | FORCE ]

ON [COMMIT | DEMAND ]
[[ENABLE | DISABLE] QUERY REWRITE]
[ON PREBUILT TABLE]
AS
SELECT ...;
The BUILD clause options are given below. This option is used when you try to create a materialized view.
  • IMMEDIATE - The materialized view is created immediately on CREATE MATERIALIZED view statement.
  • DEFERRED - Materialized view is not populated while creating it, instead it will populate at the first requested refresh.
The REFRESH clause options are given below. This controls how the data in materialized views to be refreshed.
  • FAST - Materialized view refreshed quickly using materialized view logs from base table. If materialized view logs not found then refresh will throw error.
SQL> CREATE MATERIALIZED VIEW APP_INSTANCE_MW
  2  BUILD IMMEDIATE
  3  REFRESH FAST
  4  AS SELECT APPLICATION_INSTANCE_ID FROM APP_INSTANCE;
AS SELECT APPLICATION_INSTANCE_ID FROM APP_INSTANCE
                                       *
ERROR at line 4:
ORA-23413: table "DEV_DB_4"."APP_INSTANCE" does not have a materialized view log

SQL> CREATE MATERIALIZED VIEW LOG ON APP_INSTANCE
  2  TABLESPACE NEON_1M
  3  WITH PRIMARY KEY
  4  INCLUDING NEW VALUES;

Materialized view log created.

SQL> CREATE MATERIALIZED VIEW APP_INSTANCE_MW
  2  BUILD IMMEDIATE
  3  REFRESH FAST
  4  AS SELECT APPLICATION_INSTANCE_ID FROM APP_INSTANCE;

Materialized view created.
  • COMPLETE - Materialized view segment is truncated and re-populated using base query. This refresh takes lot of time to complete. 
  • FORCE - On force refresh, first it will attempt a FAST refresh using materialized view logs from source table. If it is not found then a COMPLETE refresh used.
Two types of refresh are available. 
  • COMMIT - Refresh is triggered if one of underlying table of materialized view is committed with new changes.
  • DEMAND - This can be triggered manually or using an automated materialized view refresher.
The ON PREBUILT TABLE clause used to create a materialized view using a pre-built table which have the same name as materialized view. I am creating a materialized view app_instance_mw here from a pre-built table app_instance_mw.

Materialized View Logs
Complete refresh requires lot of time to complete because it truncates the original segment and re-populates using underlying query. So it's best to generate materialized view logs from source table. This logs can be used to refresh materialized view very quickly. 
SQL> SELECT LOG_TABLE,
  2         MASTER,
  3         LAST_PURGE_DATE,
  4         B.BYTES
  5    FROM USER_MVIEW_LOGS A, USER_SEGMENTS B
  6   WHERE A.LOG_TABLE = B.SEGMENT_NAME;

LOG_TABLE            MASTER               LAST_PURG      BYTES
-------------------- -------------------- --------- ----------
MLOG$_APP_INSTANCE   APP_INSTANCE         09-FEB-16      65536