GA of Oracle Database 20c Preview Release

The latest annual release of the world’s most popular database, Oracle Database 20c, is now available for preview on Oracle Cloud (Database Cloud Service Virtual Machine).

As with every new release, Oracle Database 20c introduces key new features and enhancements that further extend Oracle’s multi-model converged architecture with the introduction of Native Blockchain Tables, and more performance enhancements such as Automatic In-Memory (AIM) and a binary JSON datatype. For a quick introduction, watch Oracle EVP, Andy Mendelsohn discuss Oracle Database 20c during his last Openworld keynote.

For the complete list of new features in Oracle Database 20c, please refer to the new features guide in latest documentation set. To learn more about some of the key new features and enhancements in Oracle Database 20c, check out the following blog posts:

For availability of Oracle Database 20c on all other platforms on-premises (including Exadata) and in Oracle Cloud please refer to MyOracle Support (MOS) note 742060.1.

Related:

Autonomous Database – Dedicated : Getting Started with Operational Maintenance Policies

As many of you realize, Oracle Autonomous Database has two deployment choices; Serverless and Dedicated.

Autonomous Serverless is meant to get database users up and running quickly with zero interaction in anything related to administration. Serverless is in a sense traditional cloud, a multi-tenant database service using shared resources. In many respects, Serverless is the pinnacle of what Oracle means to “go Autonomous” with database in cloud, you simply get a secure connection and start using the database for your applications or data warehouses, there is minimal to zero interaction with the administrative side of running the database service.

On the other hand, Autonomous Dedicated deployments are a step beyond traditional cloud, designed to provide the ultimate in resource isolation, performance and allows database users a way thru policy controls to influence how Oracle’s Autonomous operations function.

With Autonomous Dedicated, at a macro level Fleet Administrators can budget dedicated resources to different work groups (LOBs, Project Teams) within a single tenant. Fleet Administrators then turn over access to the budgeted resources to the work group for a granular level of self-service, an experience that has a parallel to the experience of Oracle’s Autonomous Serverless. However, it’s not multi-tenanted, all IaaS resources are dedicated to the single tenant, yet in the same self-service format. Autonomous Dedicated brings the ultimate corporate level governance and regulatory capabilities while removing the red tap commonly known to reduce business agility.

Autonomous Dedicated policy controls make it possible to influence the level of resource isolation, database software versioning and lifecycle, over provisioning and peak usage of a database’s underlying resources. Let’s talk about database software versioning and lifecycle and get into an example of how to influence the Autonomous operations. In the next blog, we will then show an example of integrating notifications about autonomous operations into a Slack channel or other preferred methods of receiving service notifications.

With Serverless, Oracle sets all policies on software versioning and lifecycle. The exact software version, how and when it gets updated is completely opaque to the service consumers. With Dedicated, policy controls on software versioning and lifecycle make it possible for database service users to set policies so that mission critical applications can treat development and test separately from pre-production and production databases. For example, policies can influence Oracle Autonomous Database operations to update development and test with the very latest software versions, while pre-production uses a revision level update that applies 30 days before that same revision applies to production. Complex applications then have an ability to run regressions in pre-production and only apply validated revisions to the actual production. This only begins to touch on the way database users can influence how Autonomous operations run.

Lets take a quick walk thru of how to setup these software versioning lifecycles. This is easily done by setting up lifecycle defaults. Using the API, CLI, SDK or Console it’s easy to configure the defaults. Below is a series of screen shots from the console.

Btw – if you are completely unfamiliar with Oracle Cloud, you might want to check out a free trial here.

Head on over to one of the Autonomous Database workloads:

OCI Main Cloud Console

Once at the Autonomous Database resource page, you will notice 3 different Autonomous Database resources. Autonomous Exadata Infrastructure (AEI), Autonomous Container Database (ACD), Autonomous Database (ADB). The AEI and ACD are Autonomous Dedicated specific service resources and are where to setup the software version lifecycle. The ADB service resource is common for both Serverless and Dedicated.

Fleet Administrator sets up the default software version maintenance schedule at the AEI level during provisioning, although the defaults can be modified at any time for an existing AEI. Click on the Create Autonomous Exadata Infrastructure button.

Main Autonomous Database List Page

At the bottom of the AEI provisioning screen, you will see a Configure the Automatic Maintenance section, where you should click on the Modify Schedule button. If you do not customize the schedule, then it behaves like Serverless and Oracle will set a schedule.

Modify Schedules at Provisioning

Clicking that Modify Schedule button brings up a calendaring system to set maintenance window preferences. If desired, you can narrow the window down to a specific start time. The schedule is inherited from the AEI to the ACD and in a future release there will be a separation of schedule for the AEI and ACD.

Maintenance Scheduling Calendar

Similarly, a Fleet Administrator or a Database Admin sets up the software version policy at the ACD level during provisioning, although the defaults can be modified at any time for an existing ACD. Click on the Create Autonomous Container Database button.

Database Container List Page

At the bottom of the ACD provisioning screen, you will again see a Configure the Automatic Maintenance section, where you should click on the Modify Maintenance Type button. If you do not customize the Maintenance Type, Oracle will default to Release Update to keep you on the latest available software version. In a future release, you will be able to select an exact software version and Oracle will honor the implied strategy of applying the next Update or Revision based on your previous selection. Critical updates related to security or other service related issues will also appear in the same way, a unique version that can be selected, which will initially become available as a new custom scheduled update.

Database Container Provisioning

Modify Maintenance Type to your preference of Release Update or Update Revision, then click the Update Automatic Maintenance button to save your policy.

Database Container Software Version

Even though you’ve set all these defaults during provisioning, using the ACD resource list (which you can get to using the bread crumbs at the top of the Details page), you can Navigate to any given ACD details (below you would click on PrePRod or FLEET_ACD links), including maintenance where you can change your defaults and change timing and other aspects of scheduled maintenance.

Database Containers List Page

On the details page, you can find links to view your current settings, see maintenance that is currently scheduled to occur and view a history of maintenance actions.

Database Container Details - can modify maintenance

You will see details like the following, where you have controls to take various actions to change defaults, software versions, schedules, defer etc.

Scheduled Maintenance Activities and Defaults

OK, it’s that simple, now you know how to setup a software version lifecycle for a specific AEI / ACD and you can understand how different AEI / ACD can be given unique policies on how a development and test environment should be treated as opposed to pre-production and production instances. For example, schedules for production can be setup to mirror the pre-production schedule and version, but with a 1 month delay in the operation. If an issue arises in your application as a combination of your application changes and a particular software version update, it would be detected in your pre-production, you can then defer the production operation until the issue is resolved.

This flexibility in managing separation of software version, scheduling allows new adopters of Autonomous Database Services to mitigate any perceived risk in moving the most mission critical application databases to Oracle Cloud.

In my next blog, I will show you how easy it is to setup events and notifications on the operational maintenance cycles, so you can have asynchronous notices to monitoring channels like Slack when new updates become available according to your scheduling defaults.

If you would like more detail about the differences between Serverless and Dedicated, there is an excellent blog here by Julian Dontcheff.

Related:

Building Upon More Secure Databases with Oracle Autonomous Database

Author: Maywun Wong

My kids love Legos, those building blocks that click together to make taller and stronger structures. Many of the sets created a building, a ship, or a plane, and then my kids would add other Lego pieces to strengthen it such that they could play more with the toy. With each addition, the toy inherited new capabilities and reinforced the strength.

The same can be said for the strength of the Oracle database. In the past 40 years, as Oracle has released new databases which can support increasingly larger organizations with more complex security requirements, each following generation of Oracle databases inherit and build on the features of its predecessor.

Today, Oracle is a leader in the database market; we built upon that database legacy and have expanded to the cloud, applications, and infrastructure. We continue to sell our Oracle Database in many forms, including on-premises, Oracle Database Cloud Service, and in all of the forms of Exadata (on-premise, Cloud at Customer, and Cloud Service), and all of them have strong security built into their technology. Autonomous Database, both data warehouse and transaction processing, inherits many of the strengths of the rest of the Oracle databases and, with its name, adds autonomous capabilities extending to its security.

I had an opportunity to sit down in a podcast with Russ Lowenthal, Director of Product Management, to discuss security on the Autonomous Database in our recent podcast “How Can a Database Secure Itself?” During the podcast, he outlines the self-securing capabilities of the Autonomous Database and how Oracle has built upon its non-Autonomous Database, making it closer to a Software as a Service model. He shares what differentiates the security of the Autonomous Database from the non-Autonomous Database, including self-patching, automatic encryption, and the shared responsibility model between Oracle and our customers. All of these capabilities combined, along with many other security capabilities unique only to Autonomous Database, help build the next generation of databases for our customers.

I encourage you to download the latest podcast in the Autonomous Database podcast series, where you can learn more about the self-securing capabilities of the Autonomous Database as well as many other leading features which make Oracle’s latest offering unique.

Related:

Microsoft and Oracle to Interconnect Microsoft Azure and Oracle Cloud


Microsoft Corp. and Oracle Corp. on Wednesday announced a cloud interoperability partnership enabling customers to migrate and run mission-critical enterprise workloads across Microsoft Azure and Oracle Cloud. Enterprises can now seamlessly connect Azure services, to Oracle Cloud services. Today, a lot of enterprises already use a combination of Microsoft and Oracle to run their business. In addition, enterprises have invested heavily in both Oracle and Microsoft solutions for many years. Now for the first time, organizations can develop and leverage both Microsoft and Oracle cloud services simultaneously which enables easier migration of on-premises applications, the utilization of a broader range of tools, and the ability to take advantage of existing investments across both clouds.

As a result of this expanded partnership, the companies are today making available a new set of capabilities:

  • Connect Azure and Oracle Cloud seamlessly, allowing customers to extend their on-premises data centers to both clouds. This direct interconnect is available starting today in Ashburn (North America) and Azure US East, with plans to expand additional regions in the future.

  • Unified identity and access management, via a unified single sign-on experience and automated user provisioning, to manage resources across Azure and Oracle Cloud. Also available in early preview today, Oracle applications can use Azure Active Directory as the identity provider and for conditional access.

  • Supported deployment of custom applications and packaged Oracle applications (JD Edwards EnterpriseOne, E-Business Suite, PeopleSoft, Oracle Retail, Hyperion) on Azure with Oracle databases (RAC, Exadata, Autonomous Database) deployed in Oracle Cloud. The same Oracle applications will also be certified to run on Azure with Oracle databases in Oracle Cloud.

  • A collaborative support model to help IT organizations deploy these new capabilities while enabling them to leverage existing customer support relationships and processes.

  • Oracle Database will continue to be certified to run in Azure on various operating systems, including Windows Server and Oracle Linux.

More information about specific cross-cloud capabilities, use cases, business advantages, and more can be found here: https://blogs.oracle.com/cloud-infrastructure/oracle-microsoft-azure-alliance

Related:

Oracle Move – Successfully Migrate Your Data to the Oracle Cloud

The Oracle Database is enterprise-proven—it supports all types of workloads and various deployments as well as platforms on-premises and in the cloud. The question is, how can you migrate your Oracle Database into the cloud successfully, easily, and with virtually no downtime?

The answer to this question is Oracle Move: www.oracle.com/goto/move

Oracle Move provides the information and tools you need to determine the best strategy and methods to migrate your on-premises database to the Oracle Cloud and then helps you execute on the plan.

The Oracle Database in the Oracle Cloud Infrastructure (OCI) is available in several services and configurations, each one tailored to your business needs. Oracle Move therefore not only supports a variety of source database configurations, but also considers the managed Oracle Cloud database services you can choose from and be provided with the most efficient path into the Oracle Cloud. For example, Oracle Move supports the migration of an Oracle Database into the Exadata Cloud Service, Exadata Cloud at Customer, and of course, the Oracle Autonomous Data Warehouse and the Oracle Autonomous Transaction Processing services. In other words, Oracle Move is your one stop solution.

Moving your Databases to the Oracle Cloud starts from where you are today, taking into consideration your source database, whether it’s an Oracle Database or other databases hosted on a 3rd Party Cloud. Oracle Move offers a simple advisor that recommends the optimal migration solution based on your selection of the target and source database deployments.

Oracle Move offers simplicity and efficiency. Oracle automated tools make it seamless to move your database to the Oracle Cloud with virtually no downtime. Using the same technology and standards on-premises and in the Oracle Cloud, you can facilitate the same products and skills to manage your cloud-based Oracle Databases as you would on any other platform.

Oracle Move is flexible. You can directly migrate your Oracle Database to the Oracle Cloud from various source databases into different target cloud deployments depending on your requirements and business needs. Oracle Move provides a well-defined set of tools, giving you the flexibility to choose the method that best applies to your needs.

Oracle Move is cost effective. The same flexibility that lets you directly migrate your Oracle Database to the Oracle Cloud is applied to finding the most cost effective solution for the purpose and duration of the migration.

Oracle Move is highly available and scalable. The tight integration of all migration tools with the Oracle Database lets you maintain control and gain better efficiency when moving your databases into the Oracle Cloud, while the Maximum Availability Architecture (MAA)-approved tools as well as Oracle’s soon to be released Zero Downtime Migration (ZDM)-based migration ensure that your migration is handled as smoothly as possible. https://www.oracle.com/database/technologies/rac/zdm.html

The Oracle Zero Downtime Migration tool follows a simple single button approach, is fully MAA-compliant and scales to your fleet needs. Oracle ZDM leverages Oracle Data Guard in order to provide an automated migration for your on-premises database to the Oracle Cloud; all of this, with a five step process that analyzes both the source and target, prepares both databases, migrates your data, provides monitoring and then a controlled switchover of the application to your newly migrated database in the Oracle Cloud.

Oracle Move provides all the resources for Migrating OVEr to the Oracle Cloud. For more information, visit www.oracle.com/goto/move to find your best path to the Oracle Cloud.

Related:

Oracle Database 19c Now Available on Oracle Exadata

Oracle Database 19c is now available on Oracle Exadata!

Initially released on LiveSQL.oracle.com, Oracle Database 19c is the final and therefore ‘long term support’ release (previously referred to as a ‘terminal release’) of the Oracle Database 12c and 18c family of products. ‘Long term support’ means that Oracle Database 19c comes with 4 years of premium support (to end of January 2023) and at least 3 years of extended support (to end of January 2026). This extended support window is critical to many of our customers as they plan their upgrade strategy from prior releases. For the latest Oracle Support schedule see Document ID 742060.1 on My Oracle Support (login required).

Download the full Oracle Database 19c White Paper

Aims of Oracle Database 19c

Oracle Database 19c is the release that the majority of customers will target their upgrades towards, and Oracle has made stability the core aim of this release. In Oracle Database 19c, developers have focused on fixing known issues, rather than adding new functionality. This has resulted in hundreds of man years worth of testing and thousands of servers running tests 24 hours a day. This focus on stability goes further than just the core database; it also covers all aspects of the technology stack from the installer to the utilities and tools that make up the product offering. This approach, plus the changes we’ve made to the patching process will greatly reduce the burden on patching in the upcoming years for our customers.

All That’s Happened Before with Oracle Database

Before we discuss some of the changes in Oracle Database 19c, it’s important to remember that Oracle Database has been the cornerstone of enterprise systems for the last 40 years. Over that time, we’ve added a multitude of features under the guidance of our customer community; from row level locking and scalable read consistency, to the ability to logically break tables up into smaller partitions for scanning billions of rows a second using parallel query. Many of these features and their implementation are industry leading, and in many instances remain unique to Oracle Database.

Data is of little value to enterprise users when it’s not accessible, and Oracle Database has ensured that it always is. Whether it’s as simple as make sure the database is consistent on restart after an unexpected server outage. Or, by offering disaster recovery, Oracle Database can provide synchronous (or asynchronous) replication of data over large distances whilst making it available for reporting and backups. Oracle Real Application Clusters (RAC) has meant that Oracle Database is found in nearly every mission critical system where any server outage could have serious implications. RAC enables customers to scale their Oracle Databases to extraordinary levels of throughput and concurrency without having to change their applications.

Oracle Database is widely acknowledged one of the most secure repositories for data in the industry. No other database solution has the breath of capabilities or depth of implementation. Whether it’s our implementation of simple access controls or the classification of data down to the row level. We encrypt data throughout it’s life cycle be it at rest or in flight and we do it in the database itself ensuring that malicious access is minimized.

And More Recent Improvements of Oracle Database

Oracle Database 18c and the previously released Oracle Database 12c family introduced hundreds of new features and improvements. Some of the more significant include:

  • Multitenant Oracle’s strategic container architecture for the cloud introduced the concept of a pluggable database (PDB), enabling users to plug and unplug databases and move between containers, either locally or in the cloud. This architecture enables massive consolidation with the ability to efficiently share memory and processor resources and manage many databases as one (e.g. for backups, patching and upgrades).
  • JSON Support Provides developers with a more flexible approach to defining their persisted schema-less data model. As well as just being able to store JSON in the database, developers can use SQL and all of Oracle’s advanced analytical capabilities to query it. To ease the burden of processing large JSON data collections, Oracle Database also enables parallel scanning and or update. For developers looking to build applications and preferring to use a simple NoSQL API, Oracle Database provides SODA (Simple Object Data Access) APIs for C, Java, PL/SQL, Python, Node and REST.
  • Database In-Memory Enables users to perform lighting fast analytics against their operational databases without being forced to acquire new hardware or make compromises in processing their data. Oracle Database features a dual in-memory model where OLTP data is held both as rows, enabling it to be efficiently updated, and in a columnar form, enabling it to be scanned and aggregated much faster. Reports that used to take hours can now be executed in seconds. In addition, Oracle can store JSON documents in the in-memory column store for lightening fast analysis of semi structured data.
  • Sharding Provides OLTP scalability and fault isolation for customers that want to scale outside of the confines of a typical SMP server. It also supports use cases where data needs to be placed in geographic location because of performance or regularity reasons. Oracle Sharding provides superior run-time performance and simpler life-cycle management compared to home-grown deployments that use a similar approach to scalability. Users can automatically scale up the shards to reflect increases in workload making Oracle the one of the most capable and flexible approaches to web scale work loads for the enterprise today.

New in Oracle Database 19c

While stability is the focus of Oracle Database 19c, that’s not to say there aren’t some new few features and enhancements worth mentioning, such as:

  • Automatic Indexing Without the relevant experience, optimizing database performance can be a challenge for many customers. Figuring out what columns in a table require an index to benefit not just a single query but potentially thousands of variants requires a deep understanding of the data model, performance-related features of Oracle Databases and the underlying hardware. In Oracle Database 19c, we’re introducing Automatic indexing which continually evaluates the executing SQL and the underlying tables to determine which indexes to create and which ones to potentially remove. It does this via an expert system which verifies the improvements an index might make, and after it’s creation, validates the assumptions made. It then uses reinforcement learning to ensure it doesn’t make the same mistake again. Most importantly, Oracle Database 19c is able to adapt over time as the data model and access paths change.

  • Active Standby DMLRedirect A popular feature of Active Dataguard is its ability to make use of standby databases for reporting and backups. In most disaster recovery solutions the standby does nothing but continually recovering logging information shipped from a primary database. While the ability to ‘sweat’ the standby is a big improvement in fully utilizing an enterprises resource, many reporting applications require the ability to persist some data even if it is simply a users preferences. In Oracle Database 19c we now allow users to write to the standby. These writes are transparently redirected to the primary database and written their first (to ensure consistency) and then the changes shipped back to the standby. This approach allows applications to use the standby for moderate write workloads without requiring any application changes.

DML Redirect Image

  • Hybrid Partitioned Tables Breaking larger tables into smaller chunks or partitions makes them easier to manage and can improve performance by focusing operations on only the pieces of data they would be applicable to. Oracle Database supports multiple models for partitioning data as well as online operations for partition management. But, as enterprise data continues to inextricably increase in size and complexity and regulatory requirements mandate that it continues to always be online we need to look at new models for managing it. With Hybrid Partitioned Tables, DBAs can now break data into manageable partitions as before, however DBAs can now select which partitions should be held in the database for fast querying and updating, and which partitions can be made read only and stored in external partitions. These external partitions can be held on on-premises in standard files systems or on low cost HDFS. DBAs can also choose to place the data in cloud-based object stores, thereby ‘stretching’ tables to the cloud.

  • JSON Enhancements There are a number of incremental enhancement to JSON support in Oracle Database 19c, from the simplification of SQL functions to the ability to partially update a JSON document.
  • Memoptimized Rowstore This features enables fast data inserts into Oracle Database 19c from applications, such as Internet of Things (IoT), which ingest small, high volume transactions with a minimal amount of transactional overhead. The insert operations that use fast ingest functionality temporarily buffer the data in the large pool before writing it to disk in bulk in a deferred, asynchronous manner.
  • Quarantine SQL Statements Runaway SQL statements terminated by Resource Manager due to excessive consumption of processor and I/O resources can now be automatically quarantined. This prevents these runaway SQL statements from executing again, and thereby protects Oracle Database 19c from a common source of performance degradation.
  • Real Time Statistics Modern query optimizers require detailed statistics of the structure and make of data in tables to enable them to make the ‘optimal’ decision on how to execute complex queries. The problem with this is that statistic collection can be resource intensive and take some period of time. For most recent ‘always on’ applications, finding a window to run a batch process to collect this data is difficult. In Oracle Database 19c, statistics can now be collected as operations insert, update or delete data in real time. Now, there’s no need for customers to compromise between the quality of the statistics that the optimizer depends upon and finding the right time for statistics maintenance.

For the complete list of new features in Oracle Database 19c, check out the latest documentation set or try the new Database Feature Application Guide here.

For the latest Oracle Database 19c availability on other platforms, both on-premises and in Oracle Cloud (including Autonomous Database Cloud Services), check out Document ID 742060.1 on My Oracle Support (login required).

Related:

Oracle Autonomous Database at Openworld 2018

OpenWorld 2018—over 2500 sessions with customer and partner speakers from around the world, speaking about how they’ve found success—it’s the event of the year you don’t want to miss. But if you did, we’re providing a quick recap for you about Oracle Autonomous Database right here.

Autonomous Database Keynote

At the OpenWorld keynote, Oracle Executive Chairman and CTO Larry Ellison spoke about his vision for a second-generation cloud that is purpose-built for enterprise—and is more technologically advanced and secure than any other cloud on the market.

While many first-generation clouds are built on technology that’s already decades old, Oracle’s Gen 2 Cloud is built with the technology of today. Its unique architecture and capabilities deliver unmatched security, performance, and cost savings. It’s also the technology that’s used to build Oracle Autonomous Database, the industry’s first and only self-driving database.

He debuted a new ad, too. Sit back, relax—and take Oracle Autonomous Database for a spin.

Larry Ellison also talked about new deployment options, including dedicated Exadata Cloud Infrastructure and Cloud at Customer.

Dedicated Exadata

Ellison shared benchmark test results that highlighted the performance gap between Oracle and Amazon.

Database Performance Metrics

Larry Ellison said on stage, “We’re still 80 times faster than Amazon’s data warehouse.”

Autonomous Database Performance Metrics

And Andrew Mendelsohn, executive VP of Oracle Database said, “Oracle Autonomous Database has redefined data management. Our customers see significant advantages in using our cloud database services to take the complexity out of running a business-critical database while delivering unprecedented cost savings, security, and availability.”

Autonomous Database Truly Elastic

Autonomous Database in the Media

During OpenWorld, Monica Kumar, Oracle’s VP of Product Marketing for Database, also gave an interview with John Furrier of CUBEConversation about Autonomous Database. She highlighted how machine learning makes data management smarter in the cloud, and how companies can use that to get more value from their data with Oracle Autonomous Database.

Autonomous Database Customers and Awards

At the Oracle Excellence Awards, we presented awards to an extraordinary set of customers and partners who are using Oracle solutions to accelerate innovation and drive business transformation.

We heard from customers that are using Oracle Autonomous Database to increase agility, lower costs, and reduce IT complexity. These companies used Autonomous Database to speed access to data for business analysts and data scientists, and to take the load off their database administrators. Many of them are focusing on automation to improve their future capabilities.

For a leading oil and gas company, for example, their 24/7 business means that patching is difficult. But a self-patching system like Autonomous Database makes their processes drastically simpler, and they save costs too by not having to pay when they’re not using compute. They told us, “The elasticity is brilliant.”

A large newspaper company in Argentina is using Autonomous Database to improve their access to analytics. They moved to Oracle Autonomous Database so their line of business could control the analytics better, and get faster access to it.

Here was the full lineup of winners:

Data Warehouse and Big Data Leader of the Year

  • Cheolki Kim of Hyundai Home Shopping
  • Conny Björling of Skanska AB
  • Vicente Alencar Junior of Nextel
  • Benjamin Arnulf of The Hertz Corporation

Cloud Architect of the Year

  • Steven Chang of Kingold Group Co., Ltd
  • Erik Dvergsnes of AkerBP
  • Leonardo Simoes of UHG United Health Group
  • Dave Magnell of Sabre

CDO of the Year

  • V. Kalyana Rama of CONCOR
  • Luis Esteban of CaixaBank
  • Pablo Giudici of AGEA – Grupo Clarin
  • Steve Chamberlin of QMP Health

Conclusion

We’re committed to making Oracle Autonomous Database the best cloud database on the market. So far, we’re succeeding. In the next few weeks, we’ll continue to highlight Oracle Autonomous Database, Autonomous Data Warehouse, and what DBAs should know about our exciting product lineup.

Related:

What to Expect from Oracle Autonomous Transaction Processing

Today Larry Ellison announced the general availability of Oracle Autonomous Transaction Processing Cloud Service, the newest member of the Oracle Autonomous Database family, combining the flexibility of cloud with the power of machine learning to deliver data management as a service.

Traditionally, creating a database management system required a team of experts to custom build and manually maintain a complex hardware and software stack. With each system being unique, this approach led to poor economies of scale and a lack of the agility typically needed to give the business a competitive edge.

Try Autonomous Transaction Processing—Sign up for the trial

Autonomous Transaction Processing enables businesses to safely run a complex mix of high-performance transactions, reporting, and batch processing using the most secure, available, performant, and proven platform – Oracle Database on Exadata in the cloud. Unlike manually managed transaction processing databases, Autonomous Transaction Processing provides instant, elastic compute and storage, so only the required resources are provisioned at any given time, greatly decreasing runtime costs.

But What Does the Autonomous in Autonomous Transaction Processing Really Mean?

Self-Driving

Autonomous Transaction Processing is a self-driving database, meaning it eliminates the human labor needed to provision, secure, update, monitor, backup, and troubleshoot a database. This reduction in database maintenance tasks reduces costs and frees scarce administrator resources to work on higher-value tasks.

When an Autonomous Transaction Processing database is requested, an Oracle Real-Application-Cluster (RAC) database is automatically provisioned on Exadata Cloud Infrastructure. This high-availability configuration automatically benefits from many of the performance-enhancing Exadata features such as smart flash cache, Exafusion communication over a super-fast InfiniBand network, and automatic storage indexes.

In addition, when it comes time to update Autonomous Transaction Processing, patches are applied in a rolling fashion across the nodes of the cluster, eliminating unnecessary down time. Oracle automatically applies all clusterware, OS, VM, hypervisor, and firmware patches as well.

In Autonomous Transaction Processing the user does not get OS login privileges or SYSDBA privileges, so even if you want to do the maintenance tasks yourself, you cannot. It is like a car with the hood welded shut so you cannot change the oil or add coolant or perform any other maintenance yourself.

Many customers want to move to the cloud because of the elasticity it can offer. The ability to scale both in terms of compute and storage only when needed, allows people to truly pay per use. Autonomous Transaction Processing not only allows you to scale compute and storage resources, but it also allows you to do it independently online (no application downtime required).

Self-Securing

Autonomous Transaction Processing is also self-securing, as it protects itself from both external attacks and malicious internal users. Security patches are automatically applied every quarter. This is much sooner than most manually operated databases, narrowing an unnecessary window of vulnerability. Patching can also occur off-cycle if a zero-day exploit is discovered. Again, these patches are applied in a rolling fashion across the nodes of the cluster, avoiding application downtime.

But patching is just part of the picture. Autonomous Transaction Processing also protects itself with always-on encryption. This means data is encrypted at rest but also during any communication with the database. Customers control their own encryption keys to further improve security.

Autonomous Transaction Processing also secures itself from Oracle cloud administrators using Oracle Database Vault. Database Vault uniquely allows Oracle’s cloud administrators to do their jobs but prevents them from being able to see any customer data store in Autonomous Transaction Processing.

Finally, customers are not given access to either the operating system or the SYSDBA privilege to prevent security breaches from malicious internal users or from stolen administrator credentials via a phishing attack.

Self-Repairing

Autonomous Transaction Processing automatically recovers from any failures without downtime. The service is deployed on our Exadata cloud infrastructure, which has redundancy built-in at every level of the hardware configuration to protect against any server, storage, or network failures.

Autonomous Transaction Processing automatically backs up the database nightly and gives the ability to restore the database from any of the backups in the archive. It also has the ability to rewind data to a point in time in the past to back out any user errors using Oracle’s unique Flashback Database capabilities.

Since users don’t have access to the OS, Oracle is on the hook to diagnose any problems that may occur. Machine learning is used to detect and diagnose any anomalies. If the database detects an impending error, it gathers statistics and feeds them to AI diagnostics to determine the root cause. If it’s a known issue, the fix is quickly applied. If it’s a new issue a service request will be automatically opened with Oracle support.

How Does Autonomous Transaction Processing Differ from the Autonomous Data Warehouse?

Up until now, all of the functionality I have described is shared between both Autonomous Data Warehouse and Autonomous Transaction Processing. Where the two services differ is actually inside the database itself. Although both services use Oracle Database 18c, they have been optimized differently to support two very different but complementary workloads. The primary goal of the Autonomous Data Warehouse is to achieve fast complex analytics, while Autonomous Transaction Processing has been designed to efficiently execute a high volume of simple transactions.

Configuration

The differences in the two services begin with how we configure them. In Autonomous Data Warehouse, the majority of the memory is allocated to the PGA to allow parallel joins and complex aggregations to occur in-memory, rather than spilling to disk. While on Autonomous Transaction Processing, the majority of the memory is allocated to the SGA to ensure the critical working set can be cached to avoid IO.

Data Formats

We also store the data differently in each service. In the Autonomous Data Warehouse, data is stored in a columnar format as that’s the best format for analytics processing. While in Autonomous Transaction Processing, data is stored in a row format. The row format is ideal for transaction processing, as it allows quick access and updates to all of the columns in an individual record since all of the data for a given record is stored together in-memory and on-storage.

Statistics Gathering

Regardless of which type of autonomous database service you use, optimizer statistics will be automatically maintained. On the Autonomous Data Warehouse, statistics (including histograms) are automatically maintained as part of all bulk-load activities. With Autonomous Transaction Processing, data is added using more traditional insert statements, so statistics are automatically gathered when the volume of data changes significantly enough to make a difference to the statistics.

Query Optimization

Queries executed on the Autonomous Data Warehouse are automatically parallelized, as they tend to access large volumes of data in order to answer the business question. While indexes are used on Autonomous Transaction Processing to access only the specific rows of interest. We also use RDMA on Autonomous Transaction Processing to provide low response time direct access to data stored in-memory on other servers in the cluster.

Resource Management

Both Autonomous Data Warehouse and Autonomous Transaction Processing offer multiple database “services” to make it easy for users to control the priority and parallelism used by each session. The services predefine three priority levels: Low, Medium, and High. Users can just choose the best priority for each aspect of their workload. For each database service you have the ability to define the criteria of a runaway SQL statement. Any SQL statement that excesses these parameters either in terms of elapse time or IO will be automatically terminated. On Autonomous Data Warehouse only one service (LOW) automatically runs SQL statements serially. While on Autonomous Transaction Processing, only one service (PARALLEL) automatically runs SQL statements with parallel execution. You can also use the Medium priority service by default which allows the Low priority service to be used for requests such as reporting and batch to prevent them from interfering with mainstream transaction processing. The High priority level can be used for more important users or actions.

Can I Use Autonomous Transaction Processing to Develop New Applications?

Autonomous Transaction Processing is the ideal platform for new application development. Developers no longer have to wait on others to provision hardware, install software, and create a database for them. With Autonomous Transaction Processing, developers can easily deploy an Oracle database in a matter of minutes, without worrying about manual tuning or capacity planning.

Autonomous Transaction Processing also has the most advanced SQL and PL/SQL support accelerating developer productivity by minimizing the amount of application code required to implement complex business logic. It also has a complete set of integrated Machine Learning algorithms, simplifying the development of applications that perform real-time predictions such as personalized shopping recommendations, customer churn rates, and fraud detection.

Where Can I Get More Information and Get My Hands on Autonomous Transaction Processing?

The first place to visit is the Autonomous Transaction Processing Documentation. There you will find details on exactly what you can expect from the service.

We also have a great program that lets you get started with Oracle Cloud with $300 in free credits, which last much longer than you would expect since the trial service has very low pricing. Using your credits (which will probably last you around 30 days depending on how you configure Autonomous Transaction Processing) you will be able to get valuable hands-on time to try loading some your own workloads. Below is a quick video to help you get started.

Related:

Transaction Processing from Oracle is Now Autonomous

Today Larry Ellison announced the general availability of Oracle Autonomous Transaction Processing Cloud Service, the newest member of the Oracle Autonomous Database family, combining the flexibility of cloud with the power of machine learning to deliver data management as a service.

Traditionally, creating a database management system required a team of experts to custom build and manually maintain a complex hardware and software stack. With each system being unique, this approach led to poor economies of scale and a lack of the agility typically needed to give the business a competitive edge.

Try Autonomous Transaction Processing—Sign up for the trial

Autonomous Transaction Processing enables businesses to safely run a complex mix of high-performance transactions, reporting, and batch processing using the most secure, available, performant, and proven platform – Oracle Database on Exadata in the cloud. Unlike manually managed transaction processing databases, Autonomous Transaction Processing provides instant, elastic compute and storage, so only the required resources are provisioned at any given time, greatly decreasing runtime costs.

But What Does the Autonomous in Autonomous Transaction Processing Really Mean?

Self-Driving

Autonomous Transaction Processing is a self-driving database, meaning it eliminates the human labor needed to provision, secure, update, monitor, backup, and troubleshoot a database. This reduction in database maintenance tasks reduces costs and frees scarce administrator resources to work on higher-value tasks.

When an Autonomous Transaction Processing database is requested, an Oracle Real-Application-Cluster (RAC) database is automatically provisioned on Exadata Cloud Infrastructure. This high-availability configuration automatically benefits from many of the performance-enhancing Exadata features such as smart flash cache, Exafusion communication over a super-fast InfiniBand network, and automatic storage indexes.

In addition, when it comes time to update Autonomous Transaction Processing, patches are applied in a rolling fashion across the nodes of the cluster, eliminating unnecessary down time. Oracle automatically applies all clusterware, OS, VM, hypervisor, and firmware patches as well.

In Autonomous Transaction Processing the user does not get OS login privileges or SYSDBA privileges, so even if you want to do the maintenance tasks yourself, you cannot. It is like a car with the hood welded shut so you cannot change the oil or add coolant or perform any other maintenance yourself.

Many customers want to move to the cloud because of the elasticity it can offer. The ability to scale both in terms of compute and storage only when needed, allows people to truly pay per use. Autonomous Transaction Processing not only allows you to scale compute and storage resources, but it also allows you to do it independently online (no application downtime required).

Self-Securing

Autonomous Transaction Processing is also self-securing, as it protects itself from both external attacks and malicious internal users. Security patches are automatically applied every quarter. This is much sooner than most manually operated databases, narrowing an unnecessary window of vulnerability. Patching can also occur off-cycle if a zero-day exploit is discovered. Again, these patches are applied in a rolling fashion across the nodes of the cluster, avoiding application downtime.

But patching is just part of the picture. Autonomous Transaction Processing also protects itself with always-on encryption. This means data is encrypted at rest but also during any communication with the database. Customers control their own encryption keys to further improve security.

Autonomous Transaction Processing also secures itself from Oracle cloud administrators using Oracle Database Vault. Database Vault uniquely allows Oracle’s cloud administrators to do their jobs but prevents them from being able to see any customer data store in Autonomous Transaction Processing.

Finally, customers are not given access to either the operating system or the SYSDBA privilege to prevent security breaches from malicious internal users or from stolen administrator credentials via a phishing attack.

Self-Repairing

Autonomous Transaction Processing automatically recovers from any failures without downtime. The service is deployed on our Exadata cloud infrastructure, which has redundancy built-in at every level of the hardware configuration to protect against any server, storage, or network failures.

Autonomous Transaction Processing automatically backs up the database nightly and gives the ability to restore the database from any of the backups in the archive. It also has the ability to rewind data to a point in time in the past to back out any user errors using Oracle’s unique Flashback Database capabilities.

Since users don’t have access to the OS, Oracle is on the hook to diagnose any problems that may occur. Machine learning is used to detect and diagnose any anomalies. If the database detects an impending error, it gathers statistics and feeds them to AI diagnostics to determine the root cause. If it’s a known issue, the fix is quickly applied. If it’s a new issue a service request will be automatically opened with Oracle support.

How Does Autonomous Transaction Processing Differ from the Autonomous Data Warehouse?

Up until now, all of the functionality I have described is shared between both Autonomous Data Warehouse and Autonomous Transaction Processing. Where the two services differ is actually inside the database itself. Although both services use Oracle Database 18c, they have been optimized differently to support two very different but complementary workloads. The primary goal of the Autonomous Data Warehouse is to achieve fast complex analytics, while Autonomous Transaction Processing has been designed to efficiently execute a high volume of simple transactions.

Configuration

The differences in the two services begin with how we configure them. In Autonomous Data Warehouse, the majority of the memory is allocated to the PGA to allow parallel joins and complex aggregations to occur in-memory, rather than spilling to disk. While on Autonomous Transaction Processing, the majority of the memory is allocated to the SGA to ensure the critical working set can be cached to avoid IO.

Data Formats

We also store the data differently in each service. In the Autonomous Data Warehouse, data is stored in a columnar format as that’s the best format for analytics processing. While in Autonomous Transaction Processing, data is stored in a row format. The row format is ideal for transaction processing, as it allows quick access and updates to all of the columns in an individual record since all of the data for a given record is stored together in-memory and on-storage.

Statistics Gathering

Regardless of which type of autonomous database service you use, optimizer statistics will be automatically maintained. On the Autonomous Data Warehouse, statistics (including histograms) are automatically maintained as part of all bulk-load activities. With Autonomous Transaction Processing, data is added using more traditional insert statements, so statistics are automatically gathered when the volume of data changes significantly enough to make a difference to the statistics.

Query Optimization

Queries executed on the Autonomous Data Warehouse are automatically parallelized, as they tend to access large volumes of data in order to answer the business question. While indexes are used on Autonomous Transaction Processing to access only the specific rows of interest. We also use RDMA on Autonomous Transaction Processing to provide low response time direct access to data stored in-memory on other servers in the cluster.

Resource Management

Both Autonomous Data Warehouse and Autonomous Transaction Processing offer multiple database “services” to make it easy for users to control the priority and parallelism used by each session. The services predefine three priority levels: Low, Medium, and High. Users can just choose the best priority for each aspect of their workload. For each database service you have the ability to define the criteria of a runaway SQL statement. Any SQL statement that excesses these parameters either in terms of elapse time or IO will be automatically terminated. On Autonomous Data Warehouse only one service (LOW) automatically runs SQL statements serially. While on Autonomous Transaction Processing, only one service (PARALLEL) automatically runs SQL statements with parallel execution. You can also use the Medium priority service by default which allows the Low priority service to be used for requests such as reporting and batch to prevent them from interfering with mainstream transaction processing. The High priority level can be used for more important users or actions.

Can I Use Autonomous Transaction Processing to Develop New Applications?

Autonomous Transaction Processing is the ideal platform for new application development. Developers no longer have to wait on others to provision hardware, install software, and create a database for them. With Autonomous Transaction Processing, developers can easily deploy an Oracle database in a matter of minutes, without worrying about manual tuning or capacity planning.

Autonomous Transaction Processing also has the most advanced SQL and PL/SQL support accelerating developer productivity by minimizing the amount of application code required to implement complex business logic. It also has a complete set of integrated Machine Learning algorithms, simplifying the development of applications that perform real-time predictions such as personalized shopping recommendations, customer churn rates, and fraud detection.

Where Can I Get More Information and Get My Hands on Autonomous Transaction Processing?

The first place to visit is the Autonomous Transaction Processing Documentation. There you will find details on exactly what you can expect from the service.

We also have a great program that lets you get started with Oracle Cloud with $300 in free credits, which last much longer than you would expect since the trial service has very low pricing. Using your credits (which will probably last you around 30 days depending on how you configure Autonomous Transaction Processing) you will be able to get valuable hands-on time to try loading some your own workloads. Below is a quick video to help you get started.

Related:

Autonomous Database: What Does That Mean for You?

We’re living in a new age of the database.

Oracle sparked the first revolution, with the relational database.

Now we’re back again with the second revolution. It’s truly—well, revolutionary. And we’re calling the Autonomous Database.

Try Autonomous Transaction Processing—Sign up for the trial

Today we’re here to break it down for you, tell you what it is, and why we think you should care.

Why a Self-Driving Database Is the Future

It’s not just a revolution in databases that’s happening right now. We’re seeing the rise of the cloud, an explosion of data, and true promise for valuable machine learning. Everywhere you turn, you face challenges to the old way of doing things—and dazzling potential for the future.

Here’s what most companies are trying to do:

  • Transform to the modern cloud model
  • Ensure data safety
  • And do more with less

At Oracle, we argue that we’re uniquely positioned to help you through these challenges with our new kind of database, and here’s why.

Oracle has invested literally thousands of engineering years automating and optimizing the database. We’ve introduced and matured many sophisticated automation capabilities from memory management to workload monitoring and tuning—all of which are used in the Autonomous Database. We’ve arguably created an unmatched on-premise database, and that’s precisely what puts us in a unique position as we seek to create the cloud’s best database to help you with all of your new goals.

Here’s our dream: an autonomous, self-driving database that will automatically take care of all database and infrastructure management, as well as monitoring and tuning.

In our vision for the future, this Autonomous Database will:

  • Reduce costs and improve productivity because it automates the mundane tasks of having to provision, patch, and backup databases
  • Free up IT teams to focus on tasks that will bring value to the business
  • Be self-securing to protect itself from both external attacks and any malicious internal users
  • Automatically encrypt all data whether it’s at rest or in flight and automatically apply security updates with no downtime
  • Be self-repairing, and automatically recover from any failure
  • Minimize all kinds of downtime including plan maintenance

Wait a minute though—that’s not a vision for the future.

It’s what’s happening now.

Today, we’re announcing the launch of Autonomous Transaction Processing Cloud Service, which together with the Autonomous Data Warehouse that we released earlier this year, completely changes the way people look at and use a database.

We call this, “The Last Upgrade You’ll Ever Do.”

We are so proud of this. The Autonomous Database is the culmination of that database journey we started over 40 years ago. It brings full automation to every layer of database deployment, from optimization to operations to infrastructure.

In both Autonomous Transaction Processing and the Autonomous Data Warehouse, autonomous intelligence drives infrastructure and database operations for you, while also providing the ability to automatically tune internal database structures to optimize your application workload’s SQL as data changes over time.

We’ve made it easy, so easy.

You can create a highly available, mission-critical database deployment with the click of a button. Define your application schemas, load data using familiar tools, and get started processing your business transactions while leaving the mundane, time-consuming database operations to us.

The Autonomous Database—Optimized by Workload

Right now, there are two workloads we’ve optimized for the Autonomous Database. Of course we don’t plan to stop here. But here’s what we have that’s currently available, ready for you to purchase.

Autonomous Transaction Processing is what we’ve launched today, and we’ve been waiting to show it to you. It’s a database solution we created for general purpose transaction processing and mixed workload applications. Think of it as your database solution for transaction, batch, IoT, and reporting associated with those use cases.

We released the Autonomous Data Warehouse back in March. ADW is best for all analytic workloads. Think of it as your replacement for a data warehouse, data mart or data lake. It’s great for machine learning too.

Both Autonomous Transaction Processing and Autonomous Data Warehouse share the Autonomous Database platform of Oracle Database 18c on our Exadata Cloud infrastructure. The difference is how the services have been optimized within the database.

Here’s the breakdown:

How Can You Deploy the Autonomous Database?

So you know which flavor of the Autonomous Database you want. Or perhaps you know you want both. When it comes to deployment, you can choose between serverless Autonomous Data Warehouse or Autonomous Transaction Processing databases.

Or, very soon, you’ll be able to deploy on dedicated Exadata Cloud Infrastructure for the highest isolation. The complete hardware stack is isolated from other tenants and will provide a unique, fully isolated cloud within the public cloud.

For those who are a fan of Cloud at Customer, don’t worry. We plan to provide this option very soon.

Why Should You Want the Autonomous Database?

We could talk about the benefits of the Autonomous Database endlessly—and we will, in a future article. But here are the top benefits, boiled down as succinctly as we could make it.

The Autonomous Database enables:

  1. More IT innovation for less money
  2. More developer Innovation for less
  3. Fewer security breaches
  4. High availability due to built-in redundancy
  5. Easy upgrade to cloud
  6. Guaranteed lower cost

But don’t just take our word for it:

Don’t forget to take a look at our reviews on Gartner Peer Insights:

“We have also started with the Oracle Autonomous Data Warehouse Cloud and that was exceptionally impressive from start to finish – very easy to use – uploading of data easy and fast and the compression reduced the amount of storage needed 4 times.”

See the full review.

The people who are using Autonomous Database every day, the ones who are able to see how thoroughly it streamlines their work, are already talking about it and what they’re saying is good.

How to Get Started With the Autonomous Database

We can’t wait to show you the Autonomous Database too. And that’s why we’ve put together a free trial experience, so you can see if the Autonomous Database is truly as much of a gamechanger as we say. (Hint: It is)

Here’s what we’re giving you:

3338 hours, 2 TB of Exadata storage—what are you waiting for?

You’ll be able to:

  1. Provision an Autonomous Transaction Processing or Autonomous Data Warehouse instance
  2. Connect SQL Developer to the new database instance
  3. Load data files if needed and go!

You have nothing to lose, right?

Experience a new kind of database with Oracle’s Autonomous Database. Sign up today.

Related: