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