Benefits of Cloning PDB in Oracle Container Database

 

Benefits of Cloning PDB in Oracle Container Database

1. Reduced Downtime

+ Cloning PDB allows administrators to create a copy of the database while the original one remains fully operational.

+ This eliminates the need for downtime during the cloning process, ensuring continuous access to data and minimal disruption to business operations.

2. Testing and Development

+ Cloning PDB provides a safe environment for testing new applications, making changes, and running experiments without impacting the production database.

+ Developers can work on clones of the database, ensuring that any changes made will not affect the live system until they are thoroughly tested and approved.

3. Backup and Recovery

+ Cloning PDB serves as a reliable backup strategy, allowing administrators to quickly restore data in case of any database failures.

+ By creating clones regularly, organizations can ensure they have up-to-date backups that can be easily recovered in times of need.

4. Resource Optimization

+ Cloning PDB enables efficient utilization of resources by allowing administrators to create multiple copies of the database without duplicating data.

+ This helps in resource allocation, capacity planning, and overall optimization of database performance.

5. Scalability

+ With Cloning PDB, organizations can easily scale their databases by cloning existing PDBs and adding them to the Oracle Container Database.

+ This flexibility in scaling up or down based on business requirements ensures optimal performance and resource management.

Conclusion

Understanding the benefits of Cloning PDB in Oracle Container Database is crucial for database administrators seeking to improve efficiency and productivity. By leveraging the advantages of this process, organizations can enhance data management, reduce downtime, and optimize resource allocation. Embracing Cloning PDB as a part of database administration practices can lead to a more resilient and agile IT infrastructure.

Why is Cloning PDB important in database management?

 

Cloning Pluggable Databases (PDBs) within an Oracle Container Database (CDB) is a crucial aspect of database management that offers numerous benefits and plays a pivotal role in ensuring smooth operations and disaster recovery processes. Let's delve deeper into why cloning PDB is essential in the realm of database management.

1. Facilitates testing and development

• Cloning PDB allows for the creation of identical copies of a database, providing a safe environment for testing new applications or implementing changes without impacting the production database.

• Development teams can work on cloned PDBs to test upgrades, patches, or new functionalities before deploying them to the live environment, ensuring minimal disruptions and errors.

2. Streamlines disaster recovery

• In the event of a database failure or data corruption, cloned PDBs serve as valuable backups that can be quickly activated to restore critical information and minimize downtime.

• By regularly cloning PDBs and keeping them updated, organizations can enhance their disaster recovery strategies and ensure business continuity in the face of unexpected disasters.

3. Enhances scalability and flexibility

• Cloning PDBs enables organizations to easily scale their database infrastructure by creating additional copies of existing databases to cater to increased workload demands.

• With cloned PDBs, enterprises have the flexibility to quickly provision new databases for specific projects or departments, optimizing resource allocation and improving efficiency.

4. Optimizes resource utilization

• By cloning PDBs instead of creating new databases from scratch, organizations can save time and resources by leveraging existing configurations, data, and structures.

• This efficient utilization of resources not only reduces costs but also enhances productivity by eliminating repetitive setup tasks and ensuring consistency across databases.

In conclusion,

Cloning PDB in Oracle Container Database is a valuable practice that offers a myriad of benefits, including facilitating testing and development, streamlining disaster recovery, enhancing scalability and flexibility, and optimizing resource utilization. By incorporating cloning PDB into their database management strategies, organizations can improve operational efficiency, mitigate risks, and bolster their overall resilience in the face of challenges. Embracing this practice is not just a best practice but a necessity in the ever-evolving landscape of database management.

What is Cloning PDB in Oracle Container Database?

 

What is Cloning PDB in Oracle Container Database?

Cloning Pluggable Database (PDB) in an Oracle Container Database (CDB) involves creating an identical copy of a specific PDB within the same CDB or on a different CDB. This process allows for easy replication of data, testing of changes, and backup purposes without affecting the original database. Let's dive into the details of cloning PDB in Oracle Container Database:

Benefits of Cloning PDB

• Facilitates Testing: Cloning a PDB enables developers to test new applications or features without impacting the production environment.

• Disaster Recovery: In case of data loss or corruption, a cloned PDB serves as a backup to quickly restore the database.

• Resource Optimization: Cloning helps in distributing workloads across multiple PDBs, optimizing resource utilization.

• Time Efficiency: Instead of setting up a new database from scratch, cloning saves time by replicating an existing PDB.

Steps to Clone PDB

1. Connect to CDB: Log in to the CDB as a privileged user using SQL Developer or SQL*Plus.

2. Ensure Resource Availability: Check for sufficient space, memory, and CPU resources for the cloning process.

3. Create a New PDB: Use the CREATE PLUGGABLE DATABASE command to create a new PDB where the cloned data will reside.

4. Open Source PDB in Read-Only Mode: Ensure the source PDB is in read-only mode to avoid data inconsistency during cloning.

5. Clone PDB: Execute the CREATE PLUGGABLE DATABASE...FROM command to clone the source PDB to the target PDB.

6. Modify the Cloned PDB: Make any necessary alterations to the cloned PDB configuration, such as tablespace allocation or user roles.

Best Practices for Cloning PDB

• Regular Backups: Before initiating the cloning process, ensure regular backups of the source PDB to avoid data loss.

• Monitor Cloning Progress: Keep track of the cloning progress and resolve any errors or issues promptly.

• Test Cloned PDB: After cloning, perform thorough testing to ensure data integrity and application functionality.

• Security Measures: Implement security measures such as encryption and access controls for the cloned PDB.

Conclusion

Cloning PDB in Oracle Container Database is a valuable tool for database administrators and developers to streamline processes, enhance disaster recovery capabilities, and improve resource management. By following the outlined steps and best practices, users can effectively clone PDBs while maintaining data integrity and security. Embrace the power of cloning to unlock new possibilities in your Oracle database management journey!

DGMGRL SWITCHOVER fails with ORA-01017: invalid username/password; logon denied

While performing the Data Guard switchover activity for one of the container 2 node RAC primary and standby database (12.1.0.2) by Data Guard Broker (DGMGRL), it failed with error - ORA-01017: invalid username/password; logon denied.



Connect to DGMGRL:

DGMGRL> connect /
Connected as SYSDG.


DGMGRL>

View the details of current Data Guard Configuration:

DGMGRL> show configuration

Configuration - CDB_CONFIG

  Protection Mode: MaxPerformance
  Members:
  cdbad - Primary database
    cdb1  - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 30 seconds ago)

DGMGRL>




Let's validate if the primary and standby databases are ready for  switchover operation.

DGMGRL> validate database cdbad

  Database Role:     Physical standby database
  Primary Database:  cdb1

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    cdb1:   Off
    cdbad:  Off

DGMGRL>

DGMGRL> validate database cdb1

  Database Role:    Primary database

  Ready for Switchover:  Yes

  Flashback Database Status:
    cdb1:  Off

DGMGRL>

Above you see that both the primary and standby databases are ready for the switchover.

Let's try to perform the switchover to standby as follows:

DGMGRL> switchover to cdb1
Performing switchover NOW, please wait...
Operation requires a connection to instance "CDB1" on database "cdb1"
Connecting to instance "CDB1"...
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

        connect to instance "CDB1" of database "cdb1"

DGMGRL> 

Oooops !! it failed, I validated the connection from primary to standby and vice versa and things look cool out there.... no issues with connectivity in either ways.

then I realized that when we connect to dgmgrl as "DGMGRL>connect /" then it connects with SYSDG user not with SYS user.

I tried to validate if SYSDG user is using the password file for remote authentication but..... this user is not assigned to password file to do the remote password file authentication. Only SYS user is there in the password file.

SQL> select * from v$pwfile_users;

USERNAME                       SYSDB SYSOP SYSAS SYSBA SYSDG SYSKM     CON_ID
------------------------------ ----- ----- ----- ----- ----- ----- ----------
SYS                            TRUE  TRUE  FALSE FALSE FALSE FALSE          0

Resolution : In this case, try to connect with SYS user at DGMGRL as below and perform the switchover operation since SYS user is already added in the password file and its connectivity is fine from both primary and standby directions.

DGMGRL> connect sys
Password:*******
Connected as SYSDG.
DGMGRL>




DGMGRL> switchover to cdb1
Performing switchover NOW, please wait...
Operation requires a connection to instance "CDB1" on database "cdb1"
Connecting to instance "CDB1"...
Connected as SYSDBA.
New primary database "cdb1" is opening...
Oracle Clusterware is restarting database "cdbad" ...
Switchover succeeded, new primary is "cdb1"
DGMGRL>

Great.....!! switchover operation successful now !!

Why?

because we connected as SYS user and it is using the password file for remote authentication !!

DGMGRL> show configuration

Configuration - CDB_CONFIG

  Protection Mode: MaxPerformance
  Members:
  cdb1  - Primary database
    cdbad - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 61 seconds ago)

DGMGRL>

DGMGRL> show database cdb1

Database - cdb1

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    CDB1
    CDB2

Database Status:
SUCCESS

DGMGRL>

New container standby is in sync...

DGMGRL> show database cdbad

Database - cdbad

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          0 seconds (computed 0 seconds ago)
  Average Apply Rate: 6.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    cdbad1
    cdbad2 (apply instance)

Database Status:
SUCCESS

DGMGRL>

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       MOUNTED
         3 PDB1                           MOUNTED
         5 PDB3                           MOUNTED
SQL>




Hope it helps, subscribe to this blog to stay updated on latest Oracle Technologies and new articles.

Twitter : https://twitter.com/rajsoft8899
Linkedin : https://www.linkedin.com/in/raj-kumar-kushwaha-5a289219/

Warning: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE has been deprecated

You would see this warning message in the alert log file starting 12.1.0.2 Oracle Standby Databases when starting the MRP process using below command for real-time apply.

SQL> recover managed standby database using current logfile disconnect from session;
Media recovery complete.
SQL>




From alert log:

Warning: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE has been deprecated.
Warning: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE has been deprecated.
ALTER DATABASE RECOVER  managed standby database using current logfile disconnect from session




Instead, you should now being using the below command in 12c.

SQL> recover managed standby database cancel;
Media recovery complete.
SQL>

SQL> alter database recover managed standby database disconnect nodelay;

Database altered.

SQL>

NAME      INSTANCE_NAME    STATUS       OPEN_MODE            DATABASE_ROLE
 --------- ---------------- ------------ -------------------- ----------------
 CDB1      cdbad1           OPEN         READ ONLY WITH APPLY PHYSICAL STANDBY
 CDB1      cdbad2           OPEN         READ ONLY WITH APPLY PHYSICAL STANDBY

Hope it helps, subscribe to this blog to stay updated on latest Oracle Technologies and new articles.

Twitter : @rajsoft8899
Linkedin : https://www.linkedin.com/in/raj-kumar-kushwaha-5a289219/

DROP Pluggable Database

Theory from Oracle Doc:


Drop a PDB when you want to move the PDB to a new CDB or when you no longer need it. When you drop a PDB, the control file of the CDB is modified to eliminate all references to the dropped PDB. Archived redo log files and backups associated with the PDB are not removed, but you can use Oracle Recovery Manager (RMAN) to remove them.

When dropping a PDB, you can either keep or delete the PDB's data files by using one of the following clauses of the DROP PLUGGABLE DATABASE statement:

• KEEP DATAFILES, the default, retains the data files. The PDB temp file is removed even when KEEP DATAFILES is specified because the temp file is no longer needed. When KEEP DATAFILES is specified, the PDB must be unplugged.

• INCLUDING DATAFILES removes the data files from disk. If a PDB was created with the SNAPSHOT COPY clause, then you must specify INCLUDING DATAFILES when you drop the PDB.


Prerequisites

The following prerequisites must be met:

• The PDB must be in mounted mode, or it must be unplugged.
• The current user must have SYSDBA or SYSOPER administrative privilege, and the privilege must be either commonly granted or locally granted in the PDB. The user must exercise the privilege using AS SYSDBA or AS SYSOPER at connect time.



To drop a PDB:

1 - In SQL*Plus, ensure that the current container is the CDB root, or, for an application PDB, the application root that contains the application PDB. If the PDB is plugged into the CDB root, then the current container must be the CDB root. If the PDB is plugged into an application root, then the current container must be that application root or the CDB root. If you are dropping an application container, then the current container must be the CDB root, and the application container must not have any application PDBs plugged into it.

2 - Run the DROP PLUGGABLE DATABASE statement and specify the PDB to drop.

Example : Dropping PDB salespdb While Keeping Its Data Files

SQL> DROP PLUGGABLE DATABASE pdb_name KEEP DATAFILES;

Example : Dropping PDB salespdb and Its Data Files

SQL> DROP PLUGGABLE DATABASE pdb_name INCLUDING DATAFILES;

Demonstration: 

We many DEV Pluggable databases that we created in the previous article - Click here to read how to create many PDBs in bulk using OEM.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 PDB_DEV2                       READ WRITE NO
         6 PDB_DEV3                       READ WRITE NO
         7 PDB_DEV4                       READ WRITE NO
         8 PDB_DEV5                       READ WRITE NO
        10 PDB_DEV1                       READ WRITE NO




Closing/shutting down all PDBs that needs to be dropped:

SQL> alter pluggable database PDB_DEV1 close;

Pluggable database altered.

SQL> alter pluggable database PDB_DEV2 close;

Pluggable database altered.

SQL> alter pluggable database PDB_DEV3 close;

Pluggable database altered.

SQL> alter pluggable database PDB_DEV4 close;

Pluggable database altered.

SQL> alter pluggable database PDB_DEV5 close;

Pluggable database altered.

Validate if all are in MOUNTED state now.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 PDB_DEV2                       MOUNTED
         6 PDB_DEV3                       MOUNTED
         7 PDB_DEV4                       MOUNTED
         8 PDB_DEV5                       MOUNTED
        10 PDB_DEV1                       MOUNTED




Drop the PDBs with clause "including datafiles"

SQL> drop pluggable database PDB_DEV1 including datafiles;

Pluggable database dropped.

SQL> drop pluggable database PDB_DEV2 including datafiles;

Pluggable database dropped.

SQL> drop pluggable database PDB_DEV3 including datafiles;

Pluggable database dropped.

SQL> drop pluggable database PDB_DEV4 including datafiles;

Pluggable database dropped.

SQL> drop pluggable database PDB_DEV5 including datafiles;

Pluggable database dropped.

Validate if PDBs are dropped and gone successfully.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
SQL>




Hope it helps, subscribe to this blog to stay updated on latest Oracle Technologies and new articles.

Twitter : @rajsoft8899
Linkedin : https://www.linkedin.com/in/raj-kumar-kushwaha-5a289219/

PDB Cloning in same CDB

In this article, I would explain how to clone an existing Pluggable Database into a new PDB or you can say - create a new PDB from an existing PDB in the same container database.


In this demo, we would be cloning PDB3 as a new Pluggable Database named PDB4.

1 - Let's see the existing list of PDBs currently we have using "show pdbs" command.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 PDB3                           READ WRITE NO
SQL>




2 - Review the GUID for the individual PDBs

SQL> select con_id, guid, name, open_mode from v$pdbs;

    CON_ID GUID                             NAME                           OPEN_MODE
---------- -------------------------------- ------------------------------ ----------
         2 8FA8EFE7EE287653E0537C17800A501C PDB$SEED                       READ ONLY
         3 90C13D2FC47D70F9E0537C17800ACC04 PDB1                           READ WRITE
         4 91AC92BB3457B533E0537C17800AF412 PDB2                           READ WRITE
         5 91C3038EF67B5702E0537C17800A84C6 PDB3                           READ WRITE




3 - Here I am going to create a new tablespace into the PDB3 so that when we clone this as PDB4 so difference be visible.

SQL> alter session set container = pdb3;

Session altered.

SQL> show con_name

CON_NAME
------------------------------
PDB3
SQL>

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
+DATAC1/CDB1/DATAFILE/undotbs1.11084.1015822335
+DATAC1/CDB1/91C3038EF67B5702E0537C17800A84C6/DATAFILE/system.9073.1018133353
+DATAC1/CDB1/91C3038EF67B5702E0537C17800A84C6/DATAFILE/sysaux.3022.1018133353
+DATAC1/CDB1/91C3038EF67B5702E0537C17800A84C6/DATAFILE/users.3693.1018133353

SQL>

SQL> create tablespace tbs1 datafile '+DATAC1' size 100m;

Tablespace created.

SQL> select name from v$datafile;


NAME
--------------------------------------------------------------------------------
+DATAC1/CDB1/DATAFILE/undotbs1.11084.1015822335
+DATAC1/CDB1/91C3038EF67B5702E0537C17800A84C6/DATAFILE/system.9073.1018133353
+DATAC1/CDB1/91C3038EF67B5702E0537C17800A84C6/DATAFILE/sysaux.3022.1018133353
+DATAC1/CDB1/91C3038EF67B5702E0537C17800A84C6/DATAFILE/users.3693.1018133353
+DATAC1/CDB1/91C3038EF67B5702E0537C17800A84C6/DATAFILE/tbs1.3023.1018133807

SQL>

4 - Here now we create PDB4 from the existing PDB3 using the below simple command. This is how simple it is to clone a PDB into Oracle Multi-tenant Architecture.

SQL> create pluggable database pdb4 from pdb3;

Pluggable database created.

5 - You can list all the PDBs in the CDB using the "show pdbs" command and you can see that new PDB4 is created now. By default, new PDB be in MOUNT state when gets created.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 PDB3                           READ WRITE NO
         6 PDB4                           MOUNTED

6 - Open the Pluggable Database using below command.

SQL> alter pluggable database pdb4 open;

Pluggable database altered.




7 - Validate the PDB open status now.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 PDB3                           READ WRITE NO
         6 PDB4                           READ WRITE NO




8 - Validate new PDB details.

SQL> alter session set container = pdb4;

Session altered.

SQL> show con_name

CON_NAME
------------------------------
PDB4
SQL>

Each PDB has its own GUID named directory under the parent Container Database directory where individual PDBs store its local tablespace/datafiles in there.

SQL> select con_id, guid, name, open_mode from v$pdbs;

    CON_ID GUID                             NAME                           OPEN_MODE
---------- -------------------------------- ------------------------------ ----------
         2 8FA8EFE7EE287653E0537C17800A501C PDB$SEED                       READ ONLY
         3 90C13D2FC47D70F9E0537C17800ACC04 PDB1                           READ WRITE
         4 91AC92BB3457B533E0537C17800AF412 PDB2                           READ WRITE
         5 91C3038EF67B5702E0537C17800A84C6 PDB3                           READ WRITE
         6 91C324409E5776D8E0537C17800A746B PDB4                           READ WRITE




Cloned PDB4 has all tablespaces as it was in PDB3 under its own GUID directory path.

SQL> select name from v$datafile;

NAME
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+DATAC1/CDB1/DATAFILE/undotbs1.11084.1015822335
+DATAC1/CDB1/91C324409E5776D8E0537C17800A746B/DATAFILE/system.3134.1018133901
+DATAC1/CDB1/91C324409E5776D8E0537C17800A746B/DATAFILE/sysaux.663.1018133901
+DATAC1/CDB1/91C324409E5776D8E0537C17800A746B/DATAFILE/users.7266.1018133901
+DATAC1/CDB1/91C324409E5776D8E0537C17800A746B/DATAFILE/tbs1.7233.1018133901

Hope it helps, subscribe to this blog to stay updated on latest Oracle Technologies and new articles.

Twitter : @rajsoft8899
Linkedin : https://www.linkedin.com/in/raj-kumar-kushwaha-5a289219/

Creating Multiple PDBs in one Go using OEM

Here in this article, I would demonstrate the process steps to create multiple Pluggable Databases in just one Go using Oracle Enterprise Manager 13c.

1 - You need to make sure the underline Container Database is registered in the OEM and it is up.
2 - You need to have Oracle RDBMS software owner and password in hand.
3 - Get ASM diskgroup name handy from the ASM cluster running on the underline database server.




Let's now begin by logging into the OEM and go the Container Database target home page.

Click on the Target Home drop down option and navigate to "Provisioning" then click on "Provision Pluggable Databases"

Provision Pluggable Databases page opens > Select the option "Create New Pluggable Databases" and click on "Launch"

Select "Create a New PDB" option and provide named credentials for Oracle Software owner and its password. Click on Next.

Provide "PDB Name" that you want per the naming convention and Tick the "Create Multiple Copies" option to create the number of Pluggable Databases you want, provide PDB Administrator username/password. In my case, I am creating 5 pluggable database in one Go!

Click on Next.

Since my container database is using "+DATAC1" diskgroup for database files storage so it is selected already, click on Next.

It checks for /tmp directory location on the underline database server.

Click on Next.

Finally you can review the summary of "Create Pluggable Database" selections and click on "Submit" to start the job to create PDBs.

Click on "View Execution Details" tab to go to provisioning job details page to monitor the job steps progress.

Job is running >

Job is "Succedded" in just 11 minutes, 57 seconds - so five PDBs created this fast.

Now if you go back to Container Database home page then you would see there are 7 Pluggable databases now, earlier it was only 2.

Click on the "Pluggable Databases" to view the names of all PDBs and its target names:

You can see below, five Pluggable Databases are created per the naming convention we provided with one number incremental number appended to its name.

You can validate the same by logging into the SQLPLUS, using the SQL>show pdbs command, as below:

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 PDB_DEV2                       READ WRITE NO
         6 PDB_DEV3                       READ WRITE NO
         7 PDB_DEV4                       READ WRITE NO
         8 PDB_DEV5                       READ WRITE NO
        10 PDB_DEV1                       READ WRITE NO
SQL>







Hope it helps, subscribe to this blog to stay updated on latest Oracle Technologies and new articles.

Twitter : @rajsoft8899
Linkedin : https://www.linkedin.com/in/raj-kumar-kushwaha-5a289219/