Click to give Water and Food

Saturday, October 25, 2014

Using JVM Diagnostics (JVMD) to help tune production JVMs

Using JVM Diagnostics (JVMD) to help tune production JVMs

Contributing Author: Shiraz Kanga, Consulting Member of Technical Staff, Oracle

Tuning a production JVM involves more than merely adding more RAM to it via the -Xmx parameter. It depends upon an understanding of how your application truly behaves in a production environment. Most JVM tuning is done by developers with a simulated load in their Development or QA environment. This is unlikely to be truly representative of the production load running on production hardware with regards to proper JVM tuning.

One of the tools that actually contains real-world production data is JVM Diagnostics (JVMD). Hence it is a good idea to use data collected by JVMD for tuning your production JVMs. Note that JVMD is a component of Oracle Enterprise Manager, licensed as part of both Weblogic Management Pack and the Non-oracle Middleware Management Pack.

Figure 1. Heap Utilization and Garbage Collections for a specific JVM

In this document we are primarily addressing the Hotspot JVM. There are several aspects of tuning this JVM that we will look into:

Tuning Heap Size

The main parameters needed to tune heap size are:
  • -Xms[g|m|k] is the initial and minimum size of the Java heap
  • -Xmx[g|m|k] is the maximum possible size that the Java heap can grow upto
Figure 2. Heap after GC and Garbage Collection Overhead for a specific JVM

The Java Heap size here refers to the total size of the young and the old generation spaces. To start, take a look at the Heap usage chart (Figure 1) of your production JVM under maximum load in the JVMD Performance Diagnostics page. You should see some patterns in the minimum and the maximum heap sizes over time. You can use this data as a rough guide for your choice of -Xms and -Xmx with a reasonable amount of padding. After setting these you should start monitoring the garbage collection charts of your production JVMs (Figure 2) in the JVMD Live Heap Analysis page. It is useful to look into the JVMD metric called "Heap use after GC" which provides a good reflection of the actual amount of heap memory being used by your application. Ideally this metric should remain relatively steady over time with only few full garbage collections occuring. If there are too many full garbage collections then performance of your production application is impacted since GC is done by blocking threads that take a while to scan the entire heap. You can monitor this metric with the JVM GC Overhead% chart on the same page of JVMD. Garbage collection overhead is the percentage of total time spent in garbage collection. Increasing -Xmx can help to make these happen less frequently but actually it is time to dig deeper into your tuning options.

The key questions that you need to answer are - How frequently does garbage collection take place, How long does each collection take and what is the actual memory used (i.e. heap after GC). Also be sure that you NEVER make the heap size larger than the available free RAM on your system as disk will decrease performance as RAM will start getting swapped to disk.

The Sun HotSpot JVM relies on generational garbage collection to achieve optimum performance. The -XX:SurvivorRatio command line parameter could further help in tuning garbage collection.

The Java heap has a young generation for newly created objects and an old generation for long lived objects. The young generation is further subdivided into the Eden space where new objects are allocated and the Survivor space where new objects that are still in use can survive their first few garbage collections before being promoted to old generations. The Survivor Ratio is the ratio of Eden to Survivor space in the young object area of the heap. Increasing this setting optimizes the JVM for applications with high object creation and low object preservation. In applications that generate more medium and long lived objects, this setting should be lowered from the default and vice versa.

For example, -XX:SurvivorRatio=10 sets the ratio between each survivor space and eden space to be 1:10. If survivor spaces are too small, they will overflow directly into the old generation. If survivor spaces are too large, they will be empty. At each GC, the JVM determines the number of times an object can be copied before it is tenured, called the tenure threshold. This threshold should be set to keep the survivor space half full.

Most tuning operations represent a trade-off of some type or another. In the case of garbage collection the trade-off usually involves the memory used v/s throughput and latency.
  • The throughput of a JVM is measured in terms of the time spent doing garbage collection vs. the time spent outside of garbage collection (referred to as application time). It is the inverse of GC overhead mentioned above and represents the amount of work done by an application as a ratio of time spent in GC. Throughput can be tuned with -XX:GCTimeRatio=99 where 99 is the default which represents a 1% GC overhead. 
  • Latency is the amount of time delay that is caused by garbage collection. Latency for GC pauses can be tuned by specifying rhe maximum pause time goal with the command line option -XX:MaxGCPauseMillis=. This is interpreted as a hint that pause times of milliseconds or less are desired. By default, there is no maximum pause time goal. If a pause time goal is specified, the heap size and other garbage collection related parameters are adjusted in an attempt to keep garbage collection pauses shorter than the specified value. Note that these adjustments may cause the garbage collector to reduce the overall throughput of the application and in some cases the desired pause time goal cannot be met.
Some lesser-known options are about permanent generation space which is used by the JVM itself to hold metadata, classes structures and so on:
  • -XX:PermSize=[g|m|k] is the initial and minimum size of the permanent generation space. 
  • -XX:MaxPermSize=[g|m|k] is the maximum size of the permanent generation space. If you ever get the message java.lang.OutOfMemoryError: PermGen space then it means that your application is loading a very large number of classes and this should be raised.
  • -Xss=[g|m|k]is the size of the thread stack. Each thread in a Java application has its own stack. The stack is used to hold return addresses, arguments to functions and method calls, and so on. The default stack size setting for a thread in Java is 1MB. In a highly multi-threaded system, like an application server at any given point in time there are multiple thread pools and threads that are in use so this may need to be reduced. Since stack size has to be allocated in contiguous blocks and if the machine is being used actively and there are many threads running in the system you may encounter an OutOfMemory error even when you have sufficient heap space. Recursive code can quickly exhaust the stack and if you use such code then you may need to increase the -Xss setting. However, if you see java.lang.OutOfMemoryError: unable to create new native thread then you may have too many threads, or each thread has a large stack; so you may need to decrease it.

Tuning Garbage Collection Algorithm

Garbage collection is expensive. Generational garbage collectors have the JVM  memory divided into several spaces.
  • Eden space: All objects are placed here when first created
  • Survivor spaces: One or more regions where objects mature
  • Tenured space: Where long lived objects are stored
  • Permanent generation: This area is only used by the JVM itself to hold metadata, such as data structures for classes, methods, interned strings
One thing that people often forget to try, is to lower the amount of garbage being created in the first place. There are a lot of ways to do this which are specific to the application/code that is being written. This often involves techniques such as using StringBuilder/StringBuffer instead of Strings, lowering the amount of logging, etc.

There are several GC algorithms which are available to be used in a Java VM. The following command line options allow to use a specific GC algorithm:
  • -XX:+UseSerialGC uses a single threaded, young generation, and old generation garbage collector (Normally this is a poor choice and should be used only for small Java heap sizes such as -Xmx256m or smaller)
  • -XX:+UseParallelGC utilizes a multithreaded (parallel) garbage collector for the young generation and a single-threaded garbage collector for the old generation space in parallel.
  • -XX:+UseParallelOldGC uses a multithread garbage collector for both the young and old generations.
  • -XX:+UseParNewGC -> enables a multithreaded, young generation garbage collector
  • -XX:+UseConcMarkSweepGC -> enables the VM’s mostly concurrent garbage collector. It also auto-enables -XX:+UseParNewGC (use if If you are not able to meet your application’s worst case latency requirements due to full garbage collection duration being too long)
  • -XX:+UseG1GC -> garbage first collector (default in java 7, can be also used in latest releases of Java 6)
In practice, the default in Java 6 is ParallelGC and in Java 7 it is the G1GC. Changing the algorithm requires detailed analysis of the application behavior. If you see a nice regular sawtooth chart in the heap usage you may not need any changes at all. If not, we recommend trying out each GC algorithm under a realistic load and then comparing it to the default algorithm's behavior under the same load. Usually you will find that the default algorithm outperforms the new setting and that there is no reason to change it.

As you can see, tuning the JVM and it's garbage collectors is largely a trade-off between space and time. If you had infinite heap space then you would never need to collect garbage. Inversely, if you could tolerate infinite time delays, then you could run a cleanup as frequently as you like and keep the heap compact. Clearly, both those situations are impossible. Finding the right middle ground that is right for you requires careful balancing act based on understanding how GC works and what the application requires.
References:
Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

Thursday, October 23, 2014

Oct 2014 Oracle Enterprise Manager Base Platform PSU patches have been Released

Oct 2014  Oracle Enterprise Manager Base Platform PSU patches have been Released
Oct 2014 Oracle Enterprise Manager Base Platform PSU patches were released on Oct 14, 2014. This includes:
  • Enterprise Manager Base Platform - Grid Control (OMS)  10.2.0.5.10 PSU.
  • Enterprise Manager Base Platform - Grid Control (OMS)  11.1.0.1.11 PSU.
  • Enterprise Manager Base Platform - Cloud Control (OMS) 12.1.0.4.1 PSU.
Here is the related information:


Sunday, September 7, 2014

Latest Bundle Patch for EM12c and White paper for reducing downtime when patching the OMS

Friends,
Enterprise Manager 12.1.0.4 was released in June 2014, and the 12.1.0.4 OMS Bundle patches  have also been released in July 2014. If you have recently upgraded your Enterprise Manager OMS  to 12.1.0.4, it is recommended to apply the latest available bundle patch to your 12.1.0.4 OMS.
For the list of the available Bundle patches or System patches, please refer to the My Oracle Support note “Enterprise Manager 12.1.0.4.0 (PS3) Master Bundle Patch List” (Doc ID 1900943.1). As per this document, the latest bundle patch was released on July 31st 2014 and is System Patch 12.1.0.4.2 which is Patch Number 19176910.
This is a single System patch that includes all the OMS-Side Plug-in Bundles released in July 2014 (Cloud, DB, FMW, Fusion Applications Plug-in (FA), Siebel, Storage Management Plug-in (SMF), Oracle Virtual Infrastructure Plug-in (OVI), and Virtualization Plug-in (VT)).
The previous bundle patch was 12.1.0.4.1 (released on July 2, 2014) which was Patch Number 18945232. This is now superseded by the latest bundle patch 12.1.0.4.2 i.e. Patch Number 19176910 as stated above.
Downtime on the Enterprise Manager OMS will be needed when applying the bundle patch. However, if you have multiple OMS servers (recommended for a large enterprise), then it is possible to reduce the downtime.
You can refer to the new whitepaper on OTN “Reducing Downtime while patching Multi-OMS Environments” for the steps you can take to reduce downtime.  The opatchauto command is used to generate scripts to automate the steps that are required to patch such a scenario.
This blog post was originally published at this link.
Regards,
Porus.

Sunday, August 3, 2014

Enhancements to Monitoring in EM12c Release 4

Dear Readers,
What are the enhancements to the Enterprise Monitoring Framework in EM12c Release 4? This is the framework that controls the monitoring of enterprise targets.
1.
Improvement - The “Target Down” status is detected by Enterprise Manager within seconds of its occurrence. This applies to the Database, Weblogic Server, Host, Agent as well as deployed applications. This kind of ability is very important for enterprise-level monitoring.
The Host level monitoring has also been improved. There is a new “Host Down” event, and a new “Host Up (Unmonitored)” status. This covers the situation where a host can be up but the agent is not running, rather than the situation in earlier releases where it was difficult to distinguish if the host was really up or down if the target showed as down.
These kinds of enhancements improve higher target availability, compliance with SLA goals, and diagnosability in the case of the agent unreachable event. See here for the documentation.
2.
Improvement - Thresholds are now more flexible, with the introduction of Time-based Static thresholds and Adaptive thresholds.
In the case of time-based static thresholds, different thresholds can be set up for different times of the day or night, since the workload will be different during the day and night. Or, different thresholds for the weekend as opposed to weekdays as in the following example.
Adaptive Thresholds are also available; these are thresholds auto-calculated on a percentage deviation from the norm. The norm is determined by a baseline behavior built from collected historical data. This helps us to be alerted on abnormal behavior. See here for the details.
3.
Improvement - SNMP Version 3 is now supported by Enterprise Manager; this version is more secure than the previous version. Notifications on events can be sent using SNMPv3 traps.
Security enhancements in Version 3 include authentication, that the message is from a valid source, and message integrity and encryption, that ensures the packet sent has not been tampered with. This enables Data Centers to comply with security best practices when sending event information from Enterprise Manager to third party monitoring systems.
This blog post was originally posted at this link.
Regards,
Porus.

Friday, August 1, 2014

Enterprise Manager Agent Deployment gets better on Windows

Dear Readers,
In Enterprise Manager 12c Release 4, released in June 2014, agent deployment on Windows just got better. In earlier versions, Cygwin was often used as the mechanism for an EM agent install on Windows target servers via a Push from the Oracle Management Service (OMS). This is no longer necessary.
The Push method is the most popular method for EM agent install, and uses standard protocols like SSH1 or SSH2 (offered by OpenSSH) on Unix systems.  However, for the Windows platform, the Push method used the capabilities of Cygwin. This software had to be installed separately, and was often a bone of contention with Windows administrators who did not prefer this Linux-like software to be installed on their Windows systems.
In EM12c Release 4, there is now an alternative. The PSExec software can be used for EM Agent pushes. This is a light-weight telnet replacement and is a part of Microsoft Windows Sysinternals software – have a look at this Microsoft link.
If your central EM12c OMS is already on Windows, then you can deploy the PSExec software on the OMS server itself, it takes less than a few minutes to deploy. If your OMS is not on Windows and you want to deploy the Windows EM agent to multiple Windows targets, then you need a staging Windows server on which PSExec can be deployed.  This deployment is a one-time activity. The PSExec software is not required on any target Windows server.
The step-by-step instructions for both these scenarios can be found in the EM Basic Installation guide at this link. A script to deploy agents using PSExec (agentDeployPsExec.bat) has also been made available, see MOS Note 1636851.1 . As per the note, this agentDeployPsExec.bat file works for both 12.1.0.3 /12.1.0.4 OMS. A response file is used along with this script for automatically inputting the information for agent installation, such as the host name, agent base directory, and so on.
In this way, EM agents can be installed seamlessly on multiple Windows targets, and in considerably lesser time than the time that was required for Cygwin setup and agent deployment. And it also makes a lot of Windows administrators happy, that they do not have to install Cygwin if they use the PSExec approach. This looks like another great enhancement in EM12c Release 4 by Oracle.

This blog post was originally posted at this link.
Regards,
Porus.

Database Cloud gets better in Enterprise Manager 12c Release 4

There are a number of great improvements to the Database-as-a-Service (DBaaS) capability in Enterprise Manager 12c Release 4.
As a recap, in earlier releases it was possible to set up a private database cloud very easily, so that developers, testers or project managers/business users could self-service the creation of new databases, schemas or pluggable databases (PDBs) as per a pre-defined quota,  and then have those databases, schemas or PDBs metered and used for dollar chargeback, so that each department knew exactly how much it was spending on IT services.
This was done through the set up of a pre-defined “Service Catalog” which defined small, medium, large, and other types of databases or schemas or PDBs., that did or did not have data from a gold copy.
In EM12c Release 4, the database service catalog is enhanced with the ability to create Oracle standby databases (usingOracle Data Guard) along with the main self-service database.  This is seen in the following screenshot where a service catalog is being used to create a new database, and two standby databases are being created at the same time in the self-service request.
Both single-instance and RAC standby databases can be created, with the ability to specify multiple standby environments. The versions of the database supported are Oracle Database 10.2.0.5, 11.1.0.7, 11.2.x, and 12.1 so far.Oracle Active Data Guard standby databases can also be set up, this gives the ability to have the standby database open in read only mode at the same time the redo logs are being applied to the Active Data Guard standby.
The ability to include SI, RAC and Active Data Guard standbys during self-service database creation makes the service catalog offering more robust, and the database as a service capability enterprise-grade, since it now allows the offering of Oracle Maximum Availability Architecture (MAA)-compliant databases to be created by the self-service DBaaS user.
This blog post was originally posted at this link.

Regards,
Porus.

Saturday, June 7, 2014

EM12c Release 4: Database as a Service Enhancements


Oracle Enterprise Manager 12.1.0.4 (or simply put EM12c R4) is the latest update to the product. As previous versions, this release provides tons of enhancements and bug fixes, attributing to improved stability and quality. One of the areas that is most exciting and has seen tremendous growth in the last few years is that of Database as a Service. EM12c R4 provides a significant update to Database as a Service. The key themes are:
  1. Comprehensive Database Service Catalog (includes single instance, RAC, and Data Guard)
  2. Additional Storage Options for Snap Clone (includes support for Database feature CloneDB)
  3. Improved Rapid Start Kits
  4. Extensible Metering and Chargeback
  5. Miscellaneous Enhancements

    1. Comprehensive Database Service Catalog
    Before we get deep into implementation of a service catalog, lets first understand what it is and what benefits it provides. Per ITIL, a service catalog is an exhaustive list of IT services that an organization provides or offers to its employees or customers. Service catalogs have been widely popular in the space of cloud computing, primarily as the medium to provide standardized and pre-approved service definitions. There is already some good collateral out there that talks about Oracle database service catalogs. The two whitepapers i recommend reading are:
    EM12c comes with an out-of-the-box service catalog and self service portal since release 1. For the customers, it provides the following benefits:
    • Present a collection of standardized database service definitions,
    • Define standardized pools of hardware and software for provisioning,
    • Role based access to cater to different class of users,
    • Automated procedures to provision the predefined database definitions,
    • Setup chargeback plans based on service tiers and database configuration sizes, etc
    Starting Release 4, the scope of services offered via the service catalog has been expanded to include databases with varying levels of availability - Single Instance (SI) or Real Application Clusters (RAC) databases with multiple data guard based standby databases. Some salient points of the data guard integration:
    • Standby pools can now be defined across different datacenters or within the same datacenter as the primary (this helps in modelling the concept of near and far DR sites)
    • The standby databases can be single instance, RAC, or RAC One Node databases
    • Multiple standby databases can be provisioned, where the maximum limit is determined by the version of database software
    • The standby databases can be in either mount or read only (requires active data guard option) mode
    • All database versions 10g to 12c supported (as certified with EM 12c)
    • All 3 protection modes can be used - Maximum availability, performance, security
    • Log apply can be set to sync or async along with the required apply lag
    The different service levels or service tiers are popularly represented using metals - Platinum, Gold, Silver, Bronze, and so on. The Oracle MAA whitepaper (referenced above) calls out the various service tiers as defined by Oracle's best practices, but customers can choose any logical combinations from the table below:
     Primary Standby [1 or more] EM 12cR4
     SI - 
     SI SI
     RAC-
     RACSI
     RACRAC
     RON-
     RONRON
    where RON = RAC One Node is supported via custom post-scripts in the service template
    sample service catalog would look like the image below. Here we have defined 4 service levels, which have been deployed across 2 data centers, and have 3 standardized sizes. Again, it is important to note that this is just an example to get the creative juices flowing. I imagine each customer would come up with their own catalog based on the application requirements, their RTO/RPO goals, and the product licenses they own. In the screenwatch titled 'Build Service Catalog using EM12c DBaaS', I walk through the complete steps required to setup this sample service catalog in EM12c.

    2. Additional Storage Options for Snap Clone
    In my previous blog posts, i have described the snap clone feature in detail. Essentially, it provides a storage agnostic, self service, rapid, and space efficient approach to solving your data cloning problems. The net benefit is that you get incredible amounts of storage savings (on average 90%) all while cloning databases in a matter of minutes. Space and Time, two things enterprises would love to save on. This feature has been designed with the goal of providing data cloning capabilities while protecting your existing investments in server, storage, and software. With this in mind, we have pursued with the dual solution approach of Hardware and Software. In the hardware approach, we connect directly to your storage appliances and perform all low level actions required to rapidly clone your databases. While in the software approach, we use an intermediate software layer to talk to any storage vendor or any storage configuration to perform the same low level actions. Thus delivering the benefits of database thin cloning, without requiring you to drastically changing the infrastructure or IT's operating style.
    In release 4, we expand the scope of options supported by snap clone with the addition of database CloneDB. While CloneDB is not a new feature, it was first introduced in 11.2.0.2 patchset, it has over the years become more stable and mature. CloneDB leverages a combination of Direct NFS (or dNFS) feature of the database, RMAN image copies, sparse files, and copy-on-write technology to create thin clones of databases from existing backups in a matter of minutes. It essentially has all the traits that we want to present to our customers via the snap clone feature. For more information on cloneDB, i highly recommend reading the following sources:
    The advantages of the new CloneDB integration with EM12c Snap Clone are:
    • Space and time savings 
    • Ease of setup - no additional software is required other than the Oracle database binary
    • Works on all platforms
    • Reduce the dependence on storage administrators
    • Cloning process fully orchestrated by EM12c, and delivered to developers/DBAs/QA Testers via the self service portal
    • Uses dNFS to delivers better performance, availability, and scalability over kernel NFS
    • Complete lifecycle of the clones managed by EM12c - performance, configuration, etc

      3. Improved Rapid Start Kits
      DBaaS deployments tend to be complex and its setup requires a series of steps. These steps are typically performed across different users and different UIs. The Rapid Start Kit provides a single command solution to setup Database as a Service (DBaaS) and Pluggable Database as a Service (PDBaaS). One command creates all the Cloud artifacts like Roles, Administrators, Credentials, Database Profiles, PaaS Infrastructure Zone, Database Pools and Service Templates. Once the Rapid Start Kit has been successfully executed, requests can be made to provision databases and PDBs from the self service portal. Rapid start kit can create complex topologies involving multiple zones, pools and service templates. It also supports standby databases and use of RMAN image backups. 
      The Rapid Start Kit in reality is a simple emcli script which takes a bunch of xml files as input and executes the complete automation in a matter of seconds. On a full rack Exadata, it took only 40 seconds to setup PDBaaS end-to-end. This kit works for both Oracle's engineered systems like Exadata, SuperCluster, etc and also on commodity hardware. One can draw parallel to the Exadata One Command script, which again takes a bunch of inputs from the administrators and then runs a simple script that configures everything from network to provisioning the DB software.
      Steps to use the kit: 
      • The kit can be found under the SSA plug-in directory on the OMS:EM_BASE/oracle/MW/plugins/oracle.sysman.ssa.oms.plugin_12.1.0.8.0/dbaas/setup 
      • It can be run from this default location or from any server which has emcli client installed
      • For most scenarios, you would use the script dbaas/setup/database_cloud_setup.py 
      • For Exadata, special integration is provided to reduce the number of inputs even further. The script to use for this scenario would be dbaas/setup/exadata_cloud_setup.py
      • The database_cloud_setup.py script takes two inputs:
        • Cloud boundary xml: This file defines the cloud topology in terms of the zones and pools along with host names, oracle home locations or container database names that would be used as infrastructure for provisioning database services. This file is optional in case of Exadata, as the boundary is well know via the Exadata system target available in EM.
        • Input xml: This file captures inputs for users, roles, profiles, service templates, etc. Essentially, all inputs required to define the DB services and other settings of the self service portal.
      • Once all the xml files have been prepared, invoke the script as follows for PDBaaS:
        emcli @database_cloud_setup.py -pdbaas 
              -cloud_boundary=/tmp/my_boundary.xml 
              -cloud_input=/tmp/pdb_inputs.xml
               The script will prompt for passwords a few times for key users like sysman, cloud admin, SSA admin, etc. Once complete, you can simply log into EM as the self service user and request for databases from the portal.
      More information available in the Rapid Start Kit chapter in Cloud Administration Guide

      4. Extensible Metering and Chargeback
       Last but not the least, Metering and Chargeback in release 4 has been made extensible in all possible regards. The new extensibility features allow customer, partners, system integrators, etc to :
      • Extend chargeback to any target type managed in EM
      • Promote any metric in EM as a chargeback entity
      • Extend list of charge items via metric or configuration extensions
      • Model abstract entities like no. of backup requests, job executions, support requests, etc
       A slew of emcli verbs have also been added that allows administrators to create, edit, delete, import/export charge plans, and assign cost centers all via the command line.
      More information available in the Chargeback API chapter in Cloud Administration Guide.

      5. Miscellaneous Enhancements
      There are other miscellaneous, yet important, enhancements that are worth a mention. These mostly have been asked by customers like you. These are:
      • Custom naming of DB Services
        • Self service users can provide custom names for DB SID, DB service, schemas, and tablespaces
        • Every custom name is validated for uniqueness in EM
      • 'Create like' of Service Templates
        • Now creating variants of a service template is only a click away. This would be vital when you publish service templates to represent different database sizes or service levels.
      • Profile viewer
        • View the details of a profile like datafile, control files, snapshot ids, export/import files, etc prior to its selection in the service template
      • Cleanup automation - for failed and successful requests
        • Single emcli command to cleanup all remnant artifacts of a failed request
        • Cleanup can be performed on a per request bases or by the entire pool
        • As an extension, you can also delete successful requests
      • Improved delete user workflow
        • Allows administrators to reassign cloud resources to another user or delete all of them
      • Support for multiple tablespaces for schema as a service
        • In addition to multiple schemas, user can also specify multiple tablespaces per request
      I hope this was a good introduction to the new Database as a Service enhancements in EM12c R4. I encourage you to explore many of these new and existing features and give us feedback.
      Good luck!
      References:
      -- Adeesh Fulay (@adeeshf)

      Disclaimer

      Opinions expressed in this blog are entirely the opinions of the writers of this blog, and do not reflect the position of Oracle corporation. No responsiblity will be taken for any resulting effects if any of the instructions or notes in the blog are followed. It is at the reader's own risk and liability.