Concurrent Manager should share the ride with Applications Tier Van, or hop on to the Database Van

Numerous posts are flooded across the Internet detailing the benefits of Concurrent Managers hosted on the Database Tier, as compared to the same running on the Applications tier node with its other siblings, viz. Admin tier, Web Tier, Forms tier, etc. Indeed, it has been predominantly one of the most popular debates among industry DBAs to discuss the benefits of Concurrent Server hosted on the Database Tier, vs. Applications Tier

The results of this debate has never been unanimous, and despite numerous statistics indicating Concurrent Manager not benefitting significantly from being hosted on the Database Tier, there have been far more number of reported incidents where Concurrent Manager did get benefitted in terms of response time and throughput when hosted on the Database Tier. At last, Oracle decided to make it a standard recommendation to host the Concurrent Processing with the Database Tier in a multi-tier environment, if possible

This recommendation ruled the Oracle E-Business Suite Architecture platform for quite a while, but was pulled over for a fresh round of discussion when Rel 12 came in with a new architectural layout. The reason for pulling this item out of its grave was the way Applications tier components were re-organized in the new structural layout of Rel 12. In Rel 12 which comes with Unified Appl_Top that gets installed by default, the Applications components such as Concurrent Processing, Web tier, Admin tier, Forms tier, etc. is present on all of the Applications tier nodes. On the other hand, it was possible to separate the Applications tier components till 11.5.10.2, unlike Rel 12 where difference between nodes is solely dependent on the service groups activated on the Applications tier nodes. Few of the significant service groups worth considerations could be the Root services (OPMN), Web Entry Point services (Oracle HTTP Server), Web Applications Services (OC4J Components of OACORE, Forms and OAFM), Batch Processing Services (Applications TNS Listener, Concurrent Manager, Fulfillment Server), and other Service Groups (Oracle Forms Services, Oracle MWA Services), etc.

Conclusively, the recommendation of having Concurrent Manager share the ride with Database tier, is losing ground in Rel 12 and driving the industry-experts to recommend Concurrent Processing on its own separate tier, or with the rest of the Applications tier components. Another pseudo benefit of removing Concurrent Manager from the Database tier, is an increased efficiency in the regular manageability aspects and periodic maintenance activities like patching and cloning which would need to be performed on at least one less Applications tier node

Oracle has a dedicated Document detailing about this topic in My Oracle Support with Id 406558.1

Journey of Oracle Database : From Object-Oriented ... To Internet ... To Grid ... To Cloud ... To ...

Oracle is an organization I have always liked for being uber-audacious in implementing the latest and greatest in the technology arena, to revolutionize the database vertical. Despite being a product company, Oracle has always grabbed all possible avenues to reinvent the wheel whenever it got an opportunity

It all started in 1999, when Larry decided to break free from adding enhanced object-oriented features in its Database versioned 8. He planned to add features to enable the Database inter-operate with the Internet in a more efficient and resilient fashion, and captioned it as 8i which came with a native Java Virtual Machine known as Aurora. He went on to further solidify the foundation of Internet-Applications serviceable database in 9i, by adding around 500 new features

Oracle did an extreme analysis of its 8i and 9i versioned databases supporting thousands of Production instances across the globe, and decided the databases' computing and resource needs were so widespread and ever-growing in nature, it was next to impossible to scale them whenever required, in a traditional way. This requirement acted as the foundation stone to focus on scalability and resource allocation in a dynamic fashion. Oracle did everything to address this in its next reinvented version of database, under the flagship of 10g. The g stood for Grid Computing Architecture, and it was based on the concept of Electricity demands that originate from the source (a household) is provided without communicating the source from where it is being generated or transmitted. Similarly, the business applications in need of database computing resources, are served irrespective of the dynamic scale-up carried out behind the scene, if there was a surge in the resources' requirement

Another aspect worth notice in its 10g version was the stress put on the High-Availability of the Databases. Substantial %age of the databases servicing the Production Applications across the globe, were servicing some or other kind of mission-critical applications, and the possibility of database outages (if unscheduled) sounded scary enough to awaken the CIO from sweet-midnight dreams. In other words, the unscheduled outages were simply unaffordable owing to their catastrophic results. Oracle went all the extra miles to focus on High-Availability options to ensure Database survives the Mayan Doomsday of 12/12/12, if not a real Doomsday

This grid architecture backbone released in 10g, was further strengthened in 11g. Yet again based on the latest shifts shaping up in the Database and Computing World, the Cloud had started becoming the buzzword. Since the Applications had started taking the Cloud route, it was paramount to reinvent the wheel for making the Database Cloud-Ready. Oracle has taken the leap to make the next version of Database Cloud-ready by announcing for Database 12c

For those who are DBAs, there are plethora of interesting features wrapped in this new version of 12c. However, since the product is still in the Pandora's box, we need to wait till it gets out of it

Few of the salient features worth considering is the concept of Pluggable Databases, which means system metadata and data is kept in a section called Container Database (CDB) whereas the user metadata and data is kept in Pluggable Database (PDB). This segregation does not only provides better out-of-box manageability features, it also goes a long miles in regular maintenance activities like cloning by reducing the overall cloning time and related resource utilization, or periodic maintenance activities like database migration, where only PDB need to be plugged out and back in, e.g. from 12c Rel 1 to 12c Rel 2

Another feature worth considering is Oracle’s emphasis on achieving maximum performance gain from storage and I/O media, in an automated fashion. The term going to be used for this is Heat Map, which is an automated mechanism to identify the Hot Blocks of data (which means the data most frequently used by the applications), and re-organize them on storage media to achieve least access and I/O time

For customers running 10g and 11g DataGuard with TAF (Transparent Application Failover) feature, there isn’t any option to failover the in-flight Insert/Update/Deletes under-progress in the event of a database failover owing to a crash, which is tentatively fixed in this version, making it safer for organizations like banking institutions. However, like I said earlier, since the product is still behind the curtains, we need to wait till Larry pulls off the curtain and makes it public … Go Larry Go