Showing posts with label oracle. Show all posts
Showing posts with label oracle. Show all posts

Wednesday, November 6, 2024

Unlocking Oracle 23c AI's JSON Relational Duality: Simplifying Data Handling for Modern Applications





Unlocking Oracle 23c AI's JSON Relational Duality: Simplifying Data Handling for Modern Applications


With the release of Oracle 23c AI, Oracle has introduced a suite of new features designed to empower DBAs and developers. One of the most revolutionary additions is JSON Relational Duality, which offers unprecedented flexibility in handling data by allowing users to access the same data as both relational and JSON, seamlessly switching between formats without duplication or additional processing.

This article explores JSON Relational Duality and demonstrates how it simplifies data management for applications that need to handle both structured and unstructured data. 


What Is JSON Relational Duality?

JSON Relational Duality in Oracle 23c AI allows the same data to be represented as both relational and JSON simultaneously. This feature is particularly valuable for applications where structured relational data needs to be accessed as unstructured JSON data—and vice versa. 

For example, a company with a traditional relational structure may want to integrate with a modern application that uses JSON-based APIs. JSON Relational Duality bridges this gap, enabling applications to leverage both formats without complex transformations or performance compromises.


Why JSON Relational Duality Matters

In the past, handling both relational and JSON data often meant duplicating data or creating intricate ETL processes to convert between formats. JSON Relational Duality eliminates these challenges by allowing a single, consistent view of data that works natively with both JSON and relational formats.


- Reduced Complexity: You avoid complex ETL processes when transforming data formats.

- Enhanced Flexibility: Developers can work with the format best suited to their application needs.

- Improved Performance: Access data in the format you need without extra processing, reducing load on the system.


Getting Started with JSON Relational Duality

To demonstrate JSON Relational Duality, let’s use an example of a user, 'user', who manages employee data in a relational structure but needs to provide a JSON format for API consumption.

Suppose we have a table 'employees' with the following schema:


SQL

CREATE TABLE employees (

    employee_id NUMBER PRIMARY KEY,

    first_name VARCHAR2(50),

    last_name VARCHAR2(50),

    department VARCHAR2(50),

    salary NUMBER

);



Step 1: Enabling JSON Relational Duality


With Oracle 23c AI, we can use a 'DUPLICATE JSON' clause to enable duality, allowing 'employees' to be queried as JSON without changing the schema.


SQL

ALTER TABLE employees ENABLE JSON RELATIONAL DUALITY;


Step 2: Querying Data in JSON Format

Now, 'user' can retrieve the same data in JSON format using a simple query:

SQL

SELECT JSON_OBJECT(*) 

FROM employees 

WHERE department = 'Sales';


The query above will output each row as a JSON object, making it compatible with any API or application that requires JSON.


Step 3: Using JSON Data with Relational Functions

JSON Relational Duality allows JSON data to be used in SQL operations as if it were relational. This means that the 'user' can join, filter, and manipulate JSON data using SQL.

For example, let’s filter employees by salary and project it as JSON:

SQL

SELECT JSON_OBJECT(*) 

FROM employees 

WHERE salary > 70000;



Use Case: Integrating Relational Data with a JSON-Based Application


Imagine the 'user' is tasked with integrating an Oracle database with a cloud-based application that consumes JSON via REST API. JSON Relational Duality simplifies this process. Instead of transforming data into JSON on the fly or storing duplicates, the 'user' can directly query relational data in JSON format and feed it into the API, streamlining integration.


Example API Call with JSON Duality Data

Using JSON output from Oracle, the 'user' can now make API calls without extra data transformation:


JSON:

{

    "employee_id": 101,

    "first_name": "John",

    "last_name": "Doe",

    "department": "Sales",

    "salary": 75000

}

 

JSON Relational Duality in Complex Queries

Let’s explore a more complex query in which the 'user' needs to get department-wise average salaries, outputting the results in JSON format.


SQL

SELECT JSON_OBJECT(

    'department' VALUE department,

    'average_salary' VALUE AVG(salary)

) AS department_summary

FROM employees

GROUP BY department;



This query enables a modern, JSON-based interface to summarize data traditionally stored in relational format, making it accessible to front-end applications that prefer JSON.


SEO-Optimized Benefits of JSON Relational Duality


For DBAs, developers, and system architects, JSON Relational Duality in Oracle 23c AI is a keyword-rich feature that aligns with trends in hybrid database management and Oracle 23c AI JSON integration. It emphasizes dual-format data handling and native JSON support in relational databases, making it ideal for applications with mixed data needs. Key benefits like performance optimization, reduced data duplication, and simplified data management address frequently searched queries, ensuring that Oracle 23c AI remains at the forefront of modern database management.


Summary: Embracing the Duality Advantage in Oracle 23c AI

Oracle 23c AI’s JSON Relational Duality is a groundbreaking feature, particularly for DBAs like 'user', who must manage complex data structures efficiently. With JSON Relational Duality, Oracle offers flexibility without sacrificing performance, enabling seamless data integration for applications that demand both structured and unstructured data.

For anyone managing databases in hybrid environments, JSON Relational Duality is a powerful tool that reduces workload, enhances performance, and provides a competitive edge in the data-driven landscape.



Monday, August 19, 2024

Identify and Terminate Sessions in oracle

 

First, you have to identify the session to be killed with alter system kill session.

Step-by-Step Instructions to Identify and Terminate a Session:


Invoke SQL*Plus:

First, open SQL*Plus to begin the process.

Query V$SESSION to Identify the Session:

Use the following query to retrieve the session details. This will list all active sessions with their respective SID, SERIAL#, STATUS, SCHEMANAME, and PROGRAM.


SELECT SID, SERIAL#, STATUS, SCHEMANAME, PROGRAM FROM v$session;

The SID (Session Identifier) and SERIAL# values of the Oracle session to be killed can then be identified from this output.


Execute the ALTER SYSTEM Command:

Substitute the identified SID and SERIAL# values and issue the alter system kill session command.


ALTER SYSTEM KILL SESSION 'sid,serial#';

Handling Sessions Marked for Kill:

Sometimes, Oracle is not able to kill the session immediately with the alter system kill session command alone. Upon issuing the command, the session may be 'marked for kill' and will be terminated as soon as possible.


Forcing Session Termination:

In the case where a session is 'marked for kill' and not terminated immediately, you can force the termination by adding the immediate keyword:


ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;

Verify Termination:

To ensure that the session has been terminated, re-query the V$SESSION dynamic performance view:


SELECT SID, SERIAL#, STATUS, SCHEMANAME, PROGRAM FROM v$session WHERE SID = 'sid' AND SERIAL# = 'serial#';

The value of the STATUS column will be 'ACTIVE' when the session is making a SQL call and 'INACTIVE' if it is not.


Confirm PMON Cleanup:

After the Process Monitor (PMON) has cleaned up the session, the row will be removed from V$SESSION. Re-query to confirm:


SELECT SID, SERIAL#, STATUS, SCHEMANAME, PROGRAM FROM v$session WHERE SID = 'sid' AND SERIAL# = 'serial#';

Handling RAC Environments:

In a Real Application Clusters (RAC) environment, you can optionally specify the INST_ID, which is shown when querying the GV$SESSION view. This allows you to kill a session on a different RAC node.


ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id';

By following these detailed steps, you can efficiently identify and terminate a session using SQL*Plus, ensuring minimal disruption and maintaining database integrity.

Friday, April 19, 2024

Oracle Resource Manager: Granular Control for Managing Idle Sessions


Oracle Resource Manager: Granular Control for Managing Idle Sessions


In database management, efficiently handling idle sessions is essential to maintaining performance and resource availability. Oracle Resource Manager is a powerful tool, often underutilized, that offers granular control over how sessions consume resources. This post explores how to leverage Oracle Resource Manager to monitor and automatically terminate idle sessions, complete with in-depth, practical examples.


Why Use Oracle Resource Manager?


Oracle Resource Manager allows DBAs to define and enforce resource limits on user sessions based on specific conditions, such as idle time, CPU usage, and session priority. This level of control can be particularly useful in environments with high session volumes, such as transactional systems or shared database infrastructures, where idle sessions can prevent other active sessions from connecting.


Setting Up Resource Manager for Idle Session Management


To illustrate, let's walk through a scenario where we have a transactional database with frequent user connections. Our goal is to manage idle sessions, terminating any session that remains idle for over an hour. 


Step 1: Creating a Resource Plan


A resource plan acts as a blueprint, defining how Oracle should handle session resources. We’ll create a resource plan named `Session_Management_Plan` to automatically switch idle sessions to a termination state.


SQL:

BEGIN

    DBMS_RESOURCE_MANAGER.create_pending_area();


    DBMS_RESOURCE_MANAGER.create_plan(

        plan    => 'Session_Management_Plan',

        comment => 'Resource Plan to handle idle sessions exceeding 1 hour'

    );


    DBMS_RESOURCE_MANAGER.submit_pending_area();

END;

/



Here, we set up a simple resource plan structure to act as a container for directives. The `create_pending_area` function places the configuration in a pending state until it is finalized and submitted.


Step 2: Defining Consumer Groups


In Oracle Resource Manager, consumer groups classify sessions based on their resource needs. Here, we create two consumer groups: `ACTIVE_SESSIONS` for sessions with standard activity and `IDLE_TERMINATION` for sessions that exceed the idle limit.


SQL:

BEGIN

    DBMS_RESOURCE_MANAGER.create_pending_area();


    DBMS_RESOURCE_MANAGER.create_consumer_group(

        consumer_group => 'ACTIVE_SESSIONS',

        comment        => 'Group for actively monitored sessions'

    );


    DBMS_RESOURCE_MANAGER.create_consumer_group(

        consumer_group => 'IDLE_TERMINATION',

        comment        => 'Group for sessions to be terminated if idle too long'

    );


    DBMS_RESOURCE_MANAGER.submit_pending_area();

END;

/



These consumer groups allow us to specify different rules and behaviors based on session status.


Step 3: Creating Plan Directives


Directives define the rules for each consumer group within a plan. We’ll set a directive to monitor sessions within `ACTIVE_SESSIONS`, moving idle sessions to the `IDLE_TERMINATION` group if they remain idle for over an hour.


SQL:

BEGIN

    DBMS_RESOURCE_MANAGER.create_pending_area();


    DBMS_RESOURCE_MANAGER.create_plan_directive(

        plan             => 'Session_Management_Plan',

        group_or_subplan => 'ACTIVE_SESSIONS',

        comment          => 'Standard sessions with monitoring for idle state',

        switch_time      => 3600, -- 1 hour idle limit (3600 seconds)

        switch_group     => 'IDLE_TERMINATION'

    );


    DBMS_RESOURCE_MANAGER.create_plan_directive(

        plan             => 'Session_Management_Plan',

        group_or_subplan => 'IDLE_TERMINATION',

        comment          => 'Group for terminating sessions idle over 1 hour',

        cpu_p1           => 0, -- No CPU allocation as sessions are idle

        max_idle_blocker_time => 3600 -- Terminate after one hour idle

    );


    DBMS_RESOURCE_MANAGER.submit_pending_area();

END;

/



In this configuration:

- `switch_time` specifies the idle duration threshold (3600 seconds or 1 hour).

- `switch_group` moves sessions from `ACTIVE_SESSIONS` to `IDLE_TERMINATION` once they exceed the idle time.

- `cpu_p1` is set to zero for `IDLE_TERMINATION` to prevent idle sessions from consuming CPU.

- `max_idle_blocker_time` limits the maximum time for idle sessions in the `IDLE_TERMINATION` group, ensuring termination.


Step 4: Activating the Resource Plan

With the resource plan and directives set, we activate `Session_Management_Plan` to enforce these rules on the database.


SQL:

ALTER SYSTEM SET resource_manager_plan = 'Session_Management_Plan';

 

By activating this plan, Oracle will apply our specified rules for monitoring idle sessions and automatically terminate them after an hour of inactivity.


Step 5: Verifying and Monitoring Session Status

To ensure the plan is working as expected, monitor session activity by checking which sessions are in `ACTIVE_SESSIONS` versus `IDLE_TERMINATION`.


SQL:

SELECT username, 

       session_id, 

       status, 

       last_call_et AS idle_seconds, 

       consumer_group

FROM   v$session

WHERE  consumer_group IN ('ACTIVE_SESSIONS', 'IDLE_TERMINATION')

ORDER BY idle_seconds DESC;



The `last_call_et` column shows idle time in seconds, while the `consumer_group` column lets you see whether the session is active or set for termination. This query provides visibility into session status, letting you track how effectively idle sessions are managed.


Additional Tips for Using Oracle Resource Manager


1. Testing in Non-Production: Resource Manager settings should be tested in non-production environments first to ensure they align with your workload and that CPU or memory-intensive processes are unaffected by idle session policies.

2. Avoid Overly Aggressive Termination Policies: While terminating idle sessions frees up resources, be cautious with overly aggressive thresholds that could disrupt user sessions critical for business operations.

3. Regularly Review Session Activity: Use `DBA_HIST_ACTIVE_SESS_HISTORY` or `DBA_HIST_RESOURCE_PLAN_DIRECTIVE` views to analyze historical session activity and refine thresholds as needed.


Conclusion:

Oracle Resource Manager offers a structured, policy-based way to manage session resources, making it easier for DBAs to maintain optimal database performance. By automatically handling idle sessions, DBAs can prevent resource bottlenecks and maximize availability for active sessions. With careful setup and monitoring, Resource Manager becomes an invaluable tool in any Oracle DBA’s toolkit.


References: Oracle Database Administrator’s Guide, Oracle 19c Documentation, Oracle Database Resource Manager Concepts and Usage.


Friday, September 13, 2019

import a single table from a full export backup in oracle


import a single table from a full export backup and remap it


impdp USERNAME/PASSWORD tables=SCHEMA.TABLE_NAME directory=DPUMP dumpfile=DUMPFILE_%U.dmp
remap_schema=SOURCE:TARGET 
REMAP_TABLE=TABLE_NAME:TABLE_NAME_NEW


Optional things above :

  1. Remove remap if you don't want.
  2. Add ENCRYPTION_PASSWORD=IF_ANY

Thursday, December 8, 2016

bash: /bin/install/.oui: No such file or directory


 Problem:

[oracle@linux5 database]$ . runInstaller
bash: /bin/install/.oui: No such file or directory
[oracle@linux5 database]$ uname -a
Linux linux5 3.8.13-16.2.1.el6uek.x86_64 #1 SMP Thu Nov 7 17:01:44 PST 2013 x86_64 x86_64 x86_64 GNU/Linux


Solution:



[oracle@linux5 database]$ ./runInstaller
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 120 MB.   Actual 20461 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 4031 MB    Passed
Checking monitor: must be configured to display at least 256 colors.    Actual 16777216    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2016-11-22_09-46-02AM. Please wait ...[oracle@linux5 database]$

Monday, November 14, 2016

Is it safe to move/recreate alertlog while the database is up and running



 Is it safe to move/recreate alertlog while the database is up and running??


It is totally safe to "mv" or rename it while we are running. Since chopping part of it out would be lengthly process, there is a good chance we would write to it while you are editing it so I would not advise trying to "chop" part off -- just mv the whole thing and we'll start anew in another file.

If you want to keep the last N lines "online", after you mv the file, tail the last 100 lines to "alert_also.log" or something before you archive off the rest.



[oracle@Linux03 trace]$ ls -ll alert_*
-rw-r-----. 1 oracle oracle   
488012 Nov 14 10:23 alert_orcl.log

I will rename the existing alertlog file to something
 
[oracle@Linux03 trace]$ mv alert_orcl.log alert_orcl_Pre_14Nov2016.log

[oracle@Linux03 trace]$ ls -ll alert_*
-rw-r-----. 1 oracle oracle 488012 Nov 14 15:42 alert_orcl_Pre_14Nov2016.log
[oracle@Linux03 trace]$ ls -ll alert_*


Now let's create some activity that will need to update the alertlog.

[oracle@Linux03 bin]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Mon Nov 14 16:23:02 2016

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> alter system switch logfile;

System altered.

SQL> /

lets see if the new alertlog file has been created.

[oracle@Linux03 trace]$ ls -ll alert_*
-rw-r-----. 1 oracle oracle    249 Nov 14 16:23 alert_orcl.log
-rw-r-----. 1 oracle oracle 488012 Nov 14 15:42 alert_orcl_Pre_14Nov2016.log

Tuesday, October 11, 2016

expdp content=data_only

[oracle@oracle1 dpump]$ expdp atest/password directory=dpump dumpfile=test_tab1.dmp content=data_only tables=test_tab1 logfile=test_tab1.log

Export: Release 11.2.0.1.0 - Production on Wed Feb 11 10:58:23 2015

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "ATEST"."SYS_EXPORT_TABLE_01":  atest/******** directory=dpump dumpfile=test_tab1.dmp content=data_only tables=test_tab1 logfile=test_tab1.log
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 64 KB
. . exported "ATEST"."TEST_TAB1"                         5.937 KB      11 rows
Master table "ATEST"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for ATEST.SYS_EXPORT_TABLE_01 is:
  /u01/app/oracle/dpump/test_tab1.dmp
Job "ATEST"."SYS_EXPORT_TABLE_01" successfully completed at 10:58:26

[oracle@oracle1 dpump]$ clear
[oracle@oracle1 dpump]$ impdp atest2/password directory=dpump dumpfile=test_tab1.dmp content=data_only logfile=test_tab1_imp.log TABLE_EXISTS_ACTION=truncate remap_schema=atest:atest2

Import: Release 11.2.0.1.0 - Production on Wed Feb 11 10:58:50 2015

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "ATEST2"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "ATEST2"."SYS_IMPORT_FULL_01":  atest2/******** directory=dpump dumpfile=test_tab1.dmp content=data_only logfile=test_tab1_imp.log TABLE_EXISTS_ACTION=truncate remap_schema=atest:atest2
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "ATEST2"."TEST_TAB1"                        5.937 KB      11 rows
Job "ATEST2"."SYS_IMPORT_FULL_01" successfully completed at 10:58:52

Wednesday, June 29, 2016

passing variables in sqlplus scripts

The script snippet you provided is an SQL*Plus script used to interactively accept parameters and execute a stored procedure with those parameters. Here’s a detailed breakdown of each component and how it works:

Explanation of the Script:

  1. SET VERIFY OFF

    • This command disables the verification of substitution variables in SQLPlus. When VERIFY is set to OFF, SQLPlus does not display the text of substituted variables, which can make the output cleaner.
  2. ACCEPT par1 prompt "ENTER PARAMETER #1: "

    • The ACCEPT command is used to prompt the user for input. In this case, it asks the user to enter a value  par1 and displays the prompt message "ENTER PARAMETER #1: ". The value entered by the user is stored in the variable par1.
  3. ACCEPT par2 prompt "ENTER PARAMETER #2: "

    • Similarly, this command prompts the user to enter a value for par2, with the prompt message "ENTER PARAMETER #2: ". The value entered by the user is stored in the variable par2.
  4. execute pkg_TEST_VARIABLES.TEST_PASS_VARIABLES ( &&par1, &&par2);

    • This line executes a stored procedure TEST_PASS_VARIABLES from the package pkg_TEST_VARIABLES. The && notation is used to reference the variables par1 and par2 which were previously set by the ACCEPT commands. The double & notation ensures that the variables are resolved at runtime.

Putting It All Together:

When you run this SQL*Plus script, the following sequence of actions occurs:

  1. Prompting for Input:

    • The script first prompts you to enter two parameters: par1 and par2.
  2. Executing the Procedure:

    • After you enter the parameters, the script executes the procedure TEST_PASS_VARIABLES from the package pkg_TEST_VARIABLES, passing the entered parameters to the procedure.

Example Execution:

Assuming you have a stored procedure defined as follows:

sql

CREATE OR REPLACE PACKAGE pkg_TEST_VARIABLES AS PROCEDURE TEST_PASS_VARIABLES(p1 IN VARCHAR2, p2 IN VARCHAR2); END pkg_TEST_VARIABLES; / CREATE OR REPLACE PACKAGE BODY pkg_TEST_VARIABLES AS PROCEDURE TEST_PASS_VARIABLES(p1 IN VARCHAR2, p2 IN VARCHAR2) IS BEGIN -- Procedure logic here DBMS_OUTPUT.PUT_LINE('Parameter 1: ' || p1); DBMS_OUTPUT.PUT_LINE('Parameter 2: ' || p2); END TEST_PASS_VARIABLES; END pkg_TEST_VARIABLES; /

Running the script will prompt for input:



ENTER PARAMETER #1: value1 ENTER PARAMETER #2: value2

After providing the values, the procedure will be executed, and you will see the output:


Parameter 1: value1 Parameter 2: value2

Summary:

  • SET VERIFY OFF: Clean output by turning off variable verification.
  • ACCEPT: Prompts for user input and stores it in variables.
  • execute: Executes a stored procedure with the provided parameters.

This script is useful for testing stored procedures interactively or running scripts that require user inputs.

Tuesday, April 19, 2016

USING SELECT 'X' in query/subqueries.

 
USING SELECT 'X' in query/sub-queries.



--------------------------------------------------------
--  DDL for Table TAB1
--------------------------------------------------------

  CREATE TABLE "ATEST"."TAB1"
   (    "ID" NUMBER,
    "NAME" VARCHAR2(20 BYTE)
   ) ;

Insert into ATEST.TAB1 (ID,NAME) values (1,'AAA');
Insert into ATEST.TAB1 (ID,NAME) values (2,'BBB');
Insert into ATEST.TAB1 (ID,NAME) values (3,'EEE');
Insert into ATEST.TAB1 (ID,NAME) values (4,'FFF');


--------------------------------------------------------
--  DDL for Table TAB2
--------------------------------------------------------

  CREATE TABLE "ATEST"."TAB2"
   (    "ID" NUMBER,
    "NAME" VARCHAR2(20 BYTE)
   ) ;

Insert into ATEST.TAB2 (ID,NAME) values (1,'CCC');
Insert into ATEST.TAB2 (ID,NAME) values (2,'DDD');


Get records that exits in TAB1 and not in TAB2 using select 'X' :


select * from TAB1 f where not exists (select 'X' from TAB2 where id=f.id);
ID    NAME
--    ---- 
4    FFF
3    EEE

IN the above query we get output of all the records from TAB1 that doesnt match with TAB2 ID's.
Hence we do not get the records with ID's 1 & 2 as they only exits in TAB1.
This is just like using "select * from TAB1 f where not exists (select ID from TAB2 where id=f.id);"


Get records that exits in TAB1 and in TAB2 using select 'X' :


select * from TAB1 f where exists (select 'X' from TAB2 where id=f.id);

ID    NAME
--    ---- 
1    AAA
2    BBB

IN the above query we get output of all the records from TAB1 that exist with same ID in TAB2 .
Hence we get only records with ID 1 & 2 as they exists in both TABLES.
This is just like using "select * from TAB1 f where exists (select ID from TAB2 where id=f.id);"

Friday, April 1, 2016

sql for first day of month and last day of month


select SYSDATE ,
last_day(sysdate) as LAST_DATE_CURR_MNTH,
ADD_MONTHS(last_day(sysdate),-1) as PREVIOUS_MON_LAST_DATE,
last_day(sysdate)+1 as NEXT_MON_FIRST_DATE,
ADD_MONTHS(last_day(sysdate),+1) as NEXT_MON_LAST_DATE,
ADD_MONTHS(last_day(sysdate),+5) as LAST_DATE_OF_5TH_MON,
ADD_MONTHS(last_day(sysdate),+5) +1 as FIRST_DATE_IN_6TH_MON_AFTR_NOW  
from dual;

"SYSDATE"    "LAST_DATE_CURR_MNTH"    "PREVIOUS_MON_LAST_DATE"    "NEXT_MON_FIRST_DATE"    "NEXT_MON_LAST_DATE"    "LAST_DATE_OF_5TH_MON"   
-----------  ---------------------   ------------------------    ---------------------   --------------------    -----------------------
"FIRST_DATE_IN_6TH_MON_AFTR_NOW"
-----------------------

01-APR-16        30-APR-16                31-MAR-16                    01-MAY-16                31-MAY-16            30-SEP-16   
-----------------------
01-OCT-16