AT ORACLE: Interview
C Is for Cloud, Consolidation, and CustomersBy Tom Haunert
Oracle customers drive the genesis and marquee features of Oracle Database 12c.
Andy Mendelsohn, senior vice president of database server technologies at Oracle, sat down with Tom Haunert, Oracle Magazine editor in chief, to talk about the new customer-driven technologies and innovations in Oracle Database 12c. The following is an excerpt from that interview. Listen to a podcast of the full interview at oracle.com/magcasts.
Oracle Magazine: Oracle Database 12c was released in June and launched in July, and the product release numbering has gone from 11 to 12. And the g that stood for grid in 11g is now c, for cloud. What drove the change?
Mendelsohn: Five years ago, when we started designing Oracle Database 12c, our customers wanted a different c: consolidation. They wanted to make it possible to lower the total cost of ownership for running their databases.
Another marquee feature in Oracle Database 12c is for analytics for big data and data warehousing: SQL Pattern Matching.
Senior Vice President, Database Server Technologies, Oracle
And to do that, they wanted to get the kind of benefits people get from virtualization—to reduce the number of servers running their databases—but they also wanted to reduce the total number of databases they had to manage, which was not something they were getting from virtualization.
Our customers asked for consolidation, so we created the multitenant architecture, which enables them to consolidate hundreds of their databases into one physical Oracle Database instance.
This new architecture supports both lower capital expenditures and lower operational costs. So in the original design, the c behind Oracle Database 12c was for consolidation.
Oracle Magazine: Oracle Database 12c includes more than 500 new features. What are some of the categories or focus areas of these new features?
Mendelsohn: From a planning standpoint, cloud and consolidation were a major focus, and that’s where the multitenant architecture came from. But we also continued to focus on traditional key database development areas: high availability, data warehousing and big data analytics, compression and data optimization, performance and scalability, security and compliance.
Oracle Magazine: Tell us more about the multitenant architecture, and what it means for developers, DBAs, and businesses.
Mendelsohn: You can most easily understand the new architecture by comparing it to server virtualization. When you take a piece of hardware and virtualize it, you create logical servers called virtual machines, and those virtual machines look and feel like real hardware servers to applications. Your applications can run on them and not know that they’re running on a virtual machine as opposed to a physical machine. And you do this to consolidate—to take hundreds of servers and consolidate them into hundreds of VMs on just one or two servers.
With Oracle Database 12c, we’re doing something very similar for the database. We’re taking a database instance—which we now call a container database—and we’re virtualizing it. That container can now contain as many as 252 virtual databases, which we call pluggable databases.
So now you can take hundreds of separate databases that could be on 100 separate servers today and consolidate them into one container database. You can move each of these separate Oracle Database 11g or Oracle Database 10g database instances into this one container. Each of the old instances now runs in its own pluggable database, which is essentially a virtual database.
And after you move your schema and your data into this pluggable database, your application runs against the pluggable database as though it were a physical database. The pluggable database looks and feels like a physical Oracle Database instance, so you don’t have to rewrite your application to run in this environment.
Everything just works; the only line of code you have to change is the connect string. Everything else is unchanged. It’s virtualization for databases.
We understand that a lot of customers have initiatives to implement virtualization of their hardware servers. The good news is that hardware virtualization and multitenant container databases are complementary: the customers can simply create the container database in a VM.
And with pluggable databases, they also get much denser consolidation than they had before, because instead of hundreds of database instances—with all their separate shared memory and background processes and so on—now they just have one container database with one shared memory area and one set of background processes. A container database also enables DBAs to manage many as one: a single command at the container database level can back up, recover, and create a standby for all the pluggable databases in the container. This greatly lowers the costs of managing the databases.
Oracle Magazine: What is your top-feature list for Oracle Database 12c?
Mendelsohn: When we designed Oracle Database 12c, we identified what we thought would be the marquee features of the release. Multitenancy—the multitenant architecture—was by far the #1 feature of the release. The development project to design and build the new multitenant architecture was huge. We had to modify virtually all the components of the database product to support it.
As part of the project to support multitenancy, we also enhanced Oracle Real Application Testing, so that now you can do consolidated replays in Oracle Database 12c. You can take multiple database workloads that you want to consolidate into a single database, and you can capture and replay those workloads all together. This enables you to predict how those workloads will behave when they’re all running together in a consolidated environment. It’s important to note that multitenancy also makes it very easy to implement database as a service and software as a service.
Another marquee feature in Oracle Database 12c is for analytics for big data and data warehousing: SQL Pattern Matching. With SQL Pattern Matching, we’ve extended SQL so that you now can very easily express queries on time-ordered data to look for patterns in the data. Also, we implemented high-performance algorithms to do this pattern matching.
For example, let’s say you’re looking at stock trading data patterns. You can look for the classic W pattern—where the stock price peaks, then goes down for a short-term low, and peaks again. SQL Pattern Matching can be applied to web log analysis, financial analysis, data analysis, and telecommunications data analysis. Before SQL Pattern Matching, this type of analysis required thousands of lines of code to implement—now you can do it in a few lines of SQL.
For high availability in Oracle Database 12c, we added a marquee feature called Active Data Guard Far Sync.
In the past, if you had a standby database more than, say, 100 kilometers [60 miles] away from the primary, you had to use an asynchronous Data Guard configuration, for performance reasons, which meant that if the primary database went down, the standby database potentially could lose the last few seconds’ or minutes’ worth of transactions.
Now, with Oracle Database 12c and Active Data Guard Far Sync, you can have the standby database across continents, across oceans—thousands of miles apart—and still ensure that there’s zero data loss if the primary database goes down. All the transactions will be available on the standby database.
Storage optimization is another big feature area. In Oracle Database 11g, we introduced advanced compression, and this has been a very popular option for Oracle Database 11g customers. The storage optimization feature customers asked for next was better data lifecycle management.
Let’s say there’s an order processing system and the data starts out really hot: it’s being inserted and updated. The orders are hot for the first couple of weeks, then they start cooling off, and then they’re read-only. And then after a year, they become very rarely accessed and are retained for compliance reasons only.
In Oracle Database 12c, to understand this data lifecycle, we’ve introduced the notion of a heat map, where we capture the last time data was read or written in a block or a partition. Based on that data, DBAs can now set up policies that say things like “After the data hasn’t been updated for a month, compress the data, using row compression. Or if you’re on Oracle Exadata, go compress the data, using columnar compression.” And then maybe after the data hasn’t been read for six months, you can have a policy that says, “Automatically move that data to a low-cost storage tier.”
Or if you’re on Oracle Exadata, you can set up a policy that says, “Automatically compress that data, using archive compression” to get much denser compression. And so this whole storage optimization capability is another marquee feature in Oracle Database 12c.
The last marquee features I’ll mention are for data security. We added two very powerful data security features to Oracle Database 12c: the first is something we call “data redaction.” Data redaction is a capability that lets a DBA introduce rules into the database that let customers deal with compliance issues.
For example, let’s say a call center operator is able to look at the personal information of customers. Then an auditor comes along and finds this out and says, “No, you’ve got to fix that immediately.” In the past, that was a change to an application, to make sure the call center operator couldn’t see that data.
In Oracle Database 12c, the DBA can now institute a rule that says, “If somebody with the call center role is looking at this data, always mask the data before you present it as a result of a SQL query.” That’s data redaction in Oracle Database 12c.
We also added privilege analysis to Oracle Database 12c. Privilege analysis lets us track what kinds of privileges different users of the database need in order to get their jobs done.
There’s this notion of the principle of least privilege: always make sure your database users get the least privileges necessary to do their jobs. And with privilege analysis in Oracle Database 12c, we can now see exactly what privileges all the different users are exercising, and then we can, at the push of a button, help DBAs remove privileges that are not needed in the everyday work life of a user.
Tom Haunert, Editor in Chief
Send us your comments